An era of IoT — M2M communication protocols — MQTT
Message Queuing Telemetry Transport (MQTT) is a M2M and IoT connectivity protocol. It is an open protocol specified by IBM and Eurotech, and recently it is used by the Eclipse foundation in M2M applications.
It is an application layer protocol that follows topic based Publish-Subscribe communication pattern. It is a relatively simple and lightweight messaging protocol, designed for constrained devices with limited battery, processor, and/or memory resources.
MQTT is based on TCP/IP, but in contrast, its overhead is considerably smaller. The small transport overhead (fixed length of 2 bytes) makes the MQTT an interesting solution for unreliable networks with restricted resources, such as low bandwidth and high latency.
MQTT is also used by Facebook in implementing a fast lightweight asynchronous messaging protocol.
MQTT Message
MQTT message contains an imperative 2-bytes fixed-length header and an optional message related variable length header and payload. In first byte of fixed 2-bytes header, contain 4 bits of Message type that indicates a variety of messages including CONNECT, PUBLISH, SUBSCRIBE and remaining 4 bits contains packet specific control flags including QoS Level for delivery assurance of Publish messages, DUP and RETAIN. From the second byte starts the remaining packet length.
However, MQTT is optimized for bandwidth constrained and unreliable networks.
Features of MQTT
1. Publish-Subscribe communication
2. Quality of Service (QoS)
3. Retention of messages
4. Last Will and Testament
Publish-Subscribe
The Publish-Subscribe based architecture of the MQTT communication can be seen in the following figure, where
- “Broker” acts as an intermediary for messages sent from a publisher to subscriber, providing one-to-many message distribution and decoupling of use case application.
- When a “MQTT Publisher” publishes a message “data” to a particular “topic”, then all those “MQTT Subscriber” subscribed to the “topic” will receive the message “data”.
Communication sequence diagram
Initially, the TCP connection created between client and broker/server.
There are 16 types of messages over which MQTT client-broker relies on sending and receiving messages and acknowledgements.
The figure shows connection establishment, session management and termination of the communication channel.
Quality of Services (QoS)
MQTT provides another layer of reliability using three levels of QoS named as QoS level 0, QoS level 1 and QoS level 2.
QoS 0: At most once (fire and forget): A simple request is sent without expecting the response, leaving the assurance of delivery to TCP.
QoS 1: At least once: At QoS level 1, the message is followed by a similar ACK response. In case of missing ACK, the message will be sent again.
QoS 2: Exactly once: At QoS level 2, a four-way handshake is to be established to ensure the message delivery only once.
Retention of messages
The MQTT server has the option to retain the last message in a topic, which is sent to a new subscriber. This characteristic of the MQTT protocol allows the server to act as a “scoreboard” which will only display the last updated value of a particular sensor reading if it is declared as a topic.
Last Will and Testament
The protocol also has a mechanism of wills, where clients can send a message to the broker that will only be sent to subscribers when the client is disconnected. An unexpected disconnection from a client results in the publishing of a message known as the last will, which indicates an unexpected shutdown. This functionality makes error detection an easier job by broadcasting it and allowing clients to run their error routines simultaneously, putting a load of detection on the protocol rather than the servers or clients.
