Introduction to MQTT protocol for IOT applications.

In my previous blog post, I explained why the widely used application-layer protocol HTTP is not suitable for the IOT applications. There are a number of application-layer protocols developed to serve the purpose of IOT like MQTT, AMQP, CoAP, XMPP, STOMP etc. In this blog post, I will provide an introduction to MQTT protocol, its design, architecture and use-case examples.

Introduction to MQTT

Message Queuing Telemetry Transport (MQTT) is a lightweight application-layer messaging protocol based on the publish/subscribe (pub/sub) model. Remember HTTP is based on request-response model which is one of the reasons why it does not fulfil the needs of IOT applications. In the pub/sub model, multiple clients (sensors) can connect to a central server called a broker and subscribe to topics that they are interested in. Clients can also publish messages to specific topics of their interest through the broker. The broker is a common interface for sensor devices to connect to and exchange data. Another important point to note about MQTT is that it utilizes TCP connection on the transport layer for connections between sensors and broker which makes the communication reliable.

Messages in MQTT are always published on topics, which basically represents the destination address for that message. A client may subscribe as well as publish to multiple topics. Every client subscribed to a topic receives all the messages published to that topic. As a standard practice, topics should follow a hierarchy using a slash (/) as a separator. This allows for logical grouping/arrangement for a network of sensors. For example, a topic “kitchen/oven/temperature” clearly conveys the hierarchy of temperature sensor of oven in the kitchen. An IOT sensor network in a modern kitchen may have multiple devices each of which having multiple sensors. Hence, topics follow this hierarchical arrangement for easy understanding and logical arrangement of sensor variables.

An example of an office lamp being controlled using MQTT and demonstrating above terms is shown below:

High-Level MQTT Architecture

Other than acting as a router for routing the messages, the Broker has some additional responsibilities which are discussed briefly below:

• Quality of Service: The Quality of Service (QoS) feature allows the MQTT protocol to provide additional messaging qualities of service depending on the requirement (severity level) of the data or application. The QoS feature ensures that the message in transit is delivered as required by the service. There are 3 QoS levels available namely: “Fire and forget” or 0, “Delivered at least once” or 1, “Delivered exactly once” or 2. Higher levels of QoS are more reliable, but involve higher latency and have higher bandwidth requirements. The application developers have to think about what is the importance of the data being carried and chose this level accordingly.
   
• Store and Forward: MQTT provides support for storing persistent messages on the broker. When publishing messages, clients may request that the broker persists the message. When a client subscribes to a topic, any persisted message will be sent to the client when this feature is used. Only the most recent persistent message is stored. However, unlike the traditional messaging queues, MQTT broker does not allow these persisted messages to back up inside the server.
   
• Security: MQTT broker may require username and password authentication from clients to connect for security. To ensure privacy of messages in transit, the TCP connection may be encrypted with SSL/TLS.

Conclusion

MQTT is a many-to-many communication protocol for passing messages between multiple clients through a central broker. It decouples producer and consumer by letting clients publish and having the broker decide where to route and copy messages. While MQTT has some support for persistence, it does best as a communications bus for live data. MQTT clients make a long-lived outgoing TCP connection to a broker. This usually presents no problem for most of the IOT requirements. However, if need be, there are other protocols that rely on UDP for lower bandwidth and system resources.