Content:
- What is MQTT?
- Features of MQTT protocol, description of MQTT
- Semantics of topics
- Structure of messages
- Quality of service (QoS) in MQTT protocol
Alongside with rapid industry development, there grows the number of devices required for data management and receipt. To solve a problem of communication among numerous devices, as well as a problem with combination of devices in a single network there has been created a concept of Internet of Things (IoT) – combination of devices in a single network on the basis of some feature or characteristic, with this network further combined with similar ones, thus, creating a bigger network, and so on.
In such networks, devices interact with each other by means of various interfaces and communication protocols. As we are considering the industrial implementation of IoT concept, in which the industrial equipment with its own protocols and hardware should be used, let us get down to the IIoT concept (Industrial Internet of Things).
For their communication, devices can use various industrial protocols. For this purpose, MQTT is among the popular.
What is MQTT?
MQTT or Message Queue Telemetry Transport is a light compact open messaging protocol for data transfer at remote locations where a "small code footprint" is required or the network bandwidth is limited. These advantages allow implementing this protocol in M2M Systems (machine-to-machine) and IIoT Systems (Industrial Internet of Things).
There also exist a protocol variation MQTT-SN (MQTT for Sensor Networks), formerly known as MQTT-S, which is designed for embedded wireless devices without TCP/IP networks support, for instance, ZigBee.
Features of MQTT protocol
Major features of MQTT protocol:
- Asynchronous protocol
- Compact messages
- Operation in conditions of unstable connection of the data transmission line
- Support of several Quality of Service (QoS) levels
- Easy integration of new devices
On application layer, MQTT protocol works on top of TCP/IP protocol and uses port 1883 (8883 if connecting through SSL) as default.
In MQTT protocol, the message exchange goes between a Client, that might be a message Publisher or a message Subscriber, and a message Broker (e.g. Mosquitto MQTT).
The Publisher sends data on the MQTT Broker specifying a definite topic in a message. The Subscribers can receive various data from multiple Publishers depending on subscription to correspondent topics.
MQTT devices use definite type of messages for their communication with the Broker. Here are the main types:
- Connect – establish the connection to the message Broker
- Disconnect – break the connection to the message Broker
- Publish – publish data on a topic within the message Broker
- Subscribe – subscribe to a topic on the message Broker
- Unsubscribe – unsubscribe the topic
Scheme of simple communication of Subscriber, Publisher and Broker
Semantics of topics
Topics are characters with UTF-8 encoding. Topics hierarchy has a tree form, thus, facilitating their organization and data access. Topics can consist of one or more levels divided by «/» sign.
Here is an example of a topic, in which a temperature sensor located in the sleeping room publishes data for the Broker:
/home/living-space/living-room1/temperature
Subscriber can also receive data from several topics simultaneously. For these purposes, wildcards have been developed. There are two types of wildcards: single level and multilevel. To understand them better, let us consider the examples of each of them:
-
Single level wildcard. The plus sign «+» is used to construct
For example, we need to obtain data on temperature in all sleeping rooms:
/home/living-space/+/temperature
As a result, we receive data from topics:
/home/living-space/living-room1/temperature
/home/living-space/living-room2/temperature
/home/living-space/living-room3/temperature
-
• Multilevel wildcard. The number sign «#» is used to construct
For example, we need to obtain data from various sensors in all sleeping rooms of the house:
/home/living-space/#
As a result, we receive data from topics:
/home/living-space/living-room1/temperature
/home/living-space/living-room1/light1
/home/living-space/living-room1/light2
/home/living-space/living-room1/humidity
/home/living-space/living-room2/temperature
/home/living-space/living-room2/light1
…
Structure of messages
MQTT message consists of several parts:
- Fixed header (present in all messages)
- Variable header (present in some messages)
- Data, payload (present in some messages)
Fixed header
Message Type – for example: CONNECT, SUBSCRIBE, PUBLISH, etc.
Flags specific to each MQTT packet – these 4 bits are used for auxiliary flags, the presence and status of which depend on a message type.
Remaining Length – current message length (variable header + data), the size is from 1 to 4 bytes.
Overall, there are 15 message types in MQTT protocol:
| Message Type | Value | Direction of flow | Description |
|---|---|---|---|
| Reserved | 0000 (0) | forbidden | Reserved |
| CONNECT | 0001 (1) | C* -> S** | Client request to connect to server |
| CONNACK | 0010 (2) | C <- S | Connect acknowledgment |
| PUBLISH | 0011 (3) | C <- S, C -> S | Publish message |
| PUBACK | 0100 (4) | C <- S, C -> S | Publish acknowledgment |
| PUBREC | 0101 (5) | C <- S, C -> S | Publish received |
| PUBREL | 0110 (6) | C <- S, C -> S | Publish release |
| PUBCOMP | 0111 (7) | C <- S, C -> S | Publish complete |
| SUBSCRIBE | 1000 (8) | C -> S | Client subscribe request |
| SUBACK | 1001 (9) | C <- S | Subscribe acknowledgment |
| UNSUBSCRIBE | 1010 (10) | C -> S | Unsubscribe request |
| UNSUBACK | 1011 (11) | C <- S | Unsubscribe acknowledgment |
| PINGREQ | 1100 (12) | C -> S | PING request |
| PINGRESP | 1101 (13) | C <- S | PING response |
| DISCONNECT | 1110 (14) | C -> S | Client is disconnecting |
| Reserved | 1111 (15) | Forbidden | Reserved |
*C – Client, **S – Server
Flags
The first 4 most significant bits of the fixed header are used as specific flags:
DUP – Duplicate is set when a client or the MQTT Broker commits a Packet resent (used in PUBLISH, SUBSCRIBE, UNSUBSCRIBE, PUBREL). If the flag is set, the variable header must contain Message ID (Message Identifier).
QoS – Quality of Service (0,1,2)
RETAIN – when publishing data with Retain flag set, the Broker will store it. When a new subscription to this topic is established, the Broker will immediately send a message with this flag. It is used in PUBISH type messages only.
Variable header
Variable header is present in some headers.
It contains the following data:
- Packet identifier – present in all types of messages, except for as follows: CONNECT, CONNACK, PUBLISH(с QoS <1), PINGREQ, PINGRESP, DISCONNECT
- Protocol name – present only in CONNECT message type
- Protocol version – present only in CONNECT message type
- Connect flags – flags that specify the behaviour of a client during connection
User name – if the flag is set, a user name must be present in the payload (used for client authentication purposes)
Password – if the flag is set, a password must be present in the payload (used for client authentication purposes)
Will Retain – if the flag is set to 1, the Broker stores a Will Message.
Will QoS– Quality of Service for Will Message. If the Will Flag is set, Will QoS and Will retain must be present.
Will Flag - if the flag is set, then after a Client disconnects the Broker without sending a DISCONNECT command (in case of unpredictable shutdown, failure, etc.), the Broker will inform all connected Clients through the so-called Will Message.
Clean Session – if the flag is set to 0, the Broker stores a session, all Client subscriptions, and, by the Client’s next connection, will send all messages from QoS1 and QoS2 that were received by the Broker while a Client was disconnected. Accordingly, if the flag is set to 1, then by the next connection, a Client must subscribe to all topics again.
- Session Present – is applied in a CONNACK type of messages. If the Broker accepts a connection with Clean Session set to 1, it must set Session Present (SP) to 0. If the Broker accepts a connection with Clean Session set to 0, the value set in SP depends on whether the Broker has already stored Session state for this Client (if so, then SP must be set to 1, and vice versa). The Session Present flag enables a Client to establish whether there is already stored Session state.
-
Connect Return code – if for some reason the Broker is unable to receive a well formed CONNACK Packet from a Client, then in the second byte of CONNACK Packet it must set the appropriate value from the table below:
Value Return Code Response Description 0 0x00 Connection Accepted Connection accepted 1 0x01 Connection Refused, unacceptable protocol version The Broker does not support the version of protocol requested by the Client 2 0x02 Connection Refused, identifier rejected Client ID of the Client for connection is not in the list with allowed IDs 3 0x03 Connection Refused, Server unavailable The Network Connection has been made but the MQTT service is unavailable 4 0x04 Connection Refused, bad user name or password The data in the user name or password is malformed 5 0x05 Connection Refused, not authorized The Client is not authorized to connect 6-255 Reserved for future use - Topic Name – Name of a topic
Data, payload
Content and format of the data transmitted through MQTT messages are defined in the device. The data size can be calculated by subtracting the length of the variable header from the Remaining Length.
Quality of service in MQTT protocol (QoS)
MQTT supports three levels of Quality of Service (QoS) when sending messages.
QoS 0 At most once. On this level the Publisher sends a message to the Broker once and does not wait for any response, i.e. sends and forgets about it.
QoS 1 At least once. This level guarantees the message delivery to the Broker, however, the duplication of messages from the Publisher is possible. Once a duplicate copy is received, the Broker sends out this message to the Subscribers again, and forwards the message receipt acknowledgment to the Publisher. If the Publisher does not get PUBACK message from the Broker, it will attempt to re-deliver this Packet, setting DUP to 1.
QoS 2 Exactly once. On this level the message delivery to a Client is guaranteed, with no duplication copies possible.
The Publisher sends a message to the Broker. The message contains the unique Packet ID, QoS=2 and DUP=0. The Publisher stores the message unacknowledged unless it gets a PUBREC response from the Broker. The Broker replies with the PUBREC message containing the same Packet ID. After receiving this message, the Publisher sends PUBREL with the same Packet ID. The Broker must store the message copy until it gets PUBREL. Once the Broker receives PUBREL, it deletes the message copy and sends to the Publisher the PUBCOMP message about the completed transaction.
If you have any questions, please send an email at: sales@ipc2u.com
