Inquiry List
What is MQTT and why is it needed in IIoT? MQTT protocol description
What is MQTT and why is it needed in IIoT? MQTT protocol description 
Contents:
- What is MQTT?
- Characteristics of MQTT protocol, description of MQTT
- Semantics of topics
- Structure of messages
- Quality of Service (QoS) in MQTT protocol
- Protection of data transfer process
- Hardware for IIoT with MQTT support
Thanks to the development of the industry, the number of devices that need to be monitored and require the acquisition of various data is increasing. The concept of the Internet of Things ( IoT) was created to solve the problems of interaction between a large number of devices and the problems of connecting devices in one network, so that devices are connected in one network for any reason, and then several similar networks are connected to another large network merges and so on.
Devices in such networks interact with each other through various data transfer interfaces and protocols. Since the issue concerns the application of the IoT concept in industry, where industrial equipment with its own protocols and hardware should be used, we move to the IIoT ( Industrial Internet of Things ) concept.
Industrial Internet of Things (IIoT) is a new step in the development of industrial automation.
Devices use various industry protocols to communicate with each other, and one popular protocol that serves this purpose is MQTT .
What is MQTT?
MQTT or Message Queue Telemetry Transport is a lightweight, compact, and open data exchange protocol designed to transmit data to remote locations where small code size is required and bandwidth limitations exist. The advantages listed above allow it to be used in M2M (Machine to Machine) and IIoT (Industrial Internet of Things) systems.
There is also a version of the protocol: MQTT-SN (MQTT for Sensor Networks), formerly known as MQTT-S, designed for embedded wireless devices that do not have TCP/IP network support, such as Zigbee.
Features of MQTT Protocol
The main features of the MQTT protocol:
- Asynchronous protocol
- Compact messages
- Working in conditions of unstable communication on the data line
- Support for multi-level quality of service (QoS)
- Easy integration of new devices
The MQTT protocol runs at the application layer over TCP/IP and uses port 1883 (8883 when connecting via SSL) by default.
Messages in the MQTT protocol are exchanged between a client (client) and a broker (for example, Mosquitto MQTT), which can be a publication server or a subscriber (publisher/subscriber) of messages.
The publication server sends information to the MQTT broker, a specific topic is indicated in the message. Subscribers may receive different information from multiple publication servers depending on their subscription to the respective topics.
MQTT devices use certain types of messages to communicate with the broker, the main ones are listed below:
- Connect - creates a connection with the broker
- Disconnect - disconnects from the broker
- Publish – publishes data to a topic on the broker
- Subscribe - subscribes to a topic on the broker
- Unsubscribe - unsubscribes from the topic
A simplified diagram of the interaction between the subscriber, the publication server and the broker
Semantics of the topic
Contains UTF-8 characters. The hierarchical structure of topics has a "tree" format, which facilitates their organization and access to information. Topics consist of one or more levels separated by the «/» character. An example of a topic where a temperature sensor located in a bedroom publishes information to a broker:
/home/living-space/living-room1/temperature
A subscriber can receive information from several topics at the same time, for this there is a wildcard . They are of two types: single-level and multi-level. For easier understanding, let's look at examples of each of them:
- A single level wildcard. Use the « + » symbol to use it.
For example, we need to get temperature data for all bedrooms:
/home/living-space/ + /temperature
As a result, we get information from topics:
/home/living-space/living-room1/temperature
/home/living-space/living-room2/temperature
/home/living-space/living-room3/temperature
- Multilevel wildcard. To use it, use the « # » symbol
For example, to get information from different sensors of all the bedrooms in the house:
/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 the message
An MQTT message consists of several parts:
- Fixed header (available for all messages)
- Variable header (only available in certain messages)
- Data, "upload" (only available in certain messages)
Fixed title
Message Type – this is the message type, for example: CONNECT, SUBSCRIBE, PUBLISH, etc.
Flags specific to each MQTT packet – this is reserved for 4-bit auxiliary flags, the availability and state of which depends on the message type.
Remaining Length – reflects the length of the current message (variable header + data), can be between 1 and 4 bytes.
In total, there are 15 types of messages in the MQTT protocol:
|
Message type |
Price |
Transmission direction |
Description |
|
Reserved |
0000 (0) |
no |
Saved for backup |
|
CONNECT |
0001 (1) |
К* -> С** |
A request from a client to connect to a server |
|
CONNACK |
0010 (2) |
К <- С |
Successful connection confirmed |
|
PUBLISH |
0011 (3) |
К <- С, К -> С |
Publication of the message |
|
PUBACK |
0100 (4) |
К <- С, К -> С |
Confirmation of publication |
|
PUBREC |
0101 (5) |
К <- С, К -> С |
Publication accepted |
|
PUBREL |
0110 (6) |
К <- С, К -> С |
Permission to delete message |
|
PUBCOMP |
0111 (7) |
К <- С, К -> С |
The publication is complete |
|
SUBSCRIBE |
1000 (8) |
К -> С |
Request for subscription |
|
SUBACK |
1001 (9) |
К <- С |
Subscription request accepted |
|
UNSUBSCRIBE |
1010 (10) |
К -> С |
Request for subscription |
|
UNSUBACK |
1011 (11) |
К <- С |
Unsubscribe request accepted |
|
PINGREQ |
1100 (12) |
К -> С |
PING request |
|
PINGRESP |
1101 (13) |
К <- С |
PING response |
|
DISCONNECT |
1110 (14) |
К -> С |
Server disconnection message |
|
Reserved |
1111 (15) |
Saved for backup |
*К – client, **С – server
Flags
The four most significant bits of the first byte of the fixed header are reserved for special flags:
DUP – the duplicate flag is set when the client or MQTT broker resends the packet (used in PUBLISH, SUBSCRIBE, UNSUBSCRIBE, PUBREL types). When the flag is set, the Message ID variable header must contain the message identifier.
QoS - quality of service (0,1,2)
RETAIN – when publishing data with the retain flag set, the broker will retain it in memory. The next time you subscribe to this topic, the broker will immediately send a message with this flag. Used only in PUBLISH type messages.
Variable title
Some titles have a variable title.
It contains the following information:
- Packet identifier – packet identifier is present in all message types except: CONNECT, CONNACK, PUBLISH(с QoS <1), PINGREQ, PINGRESP, DISCONNECT
- Protocol name – protocol name (only in CONNECT type messages)
- Protocol version – protocol version (only in CONNECT type messages)
- Connect flags - flags that indicate the behavior of the client during connection
User name – if this flag is present, the user name must be specified in the payload (used for client authentication)
Password – if this flag is on "load", password must be specified (used for client authentication)
Will Retain – When set to 1, the broker retains the Will Message.
Will QoS - Quality of service for Will Message, Will QoS and Will retain are required when the Will Flag flag is set.
Will Flag - if the flag is set, after the client disconnects from the broker without sending the DISCONNECT command (in case of unexpected crashes, etc.), the broker will inform all connected clients about this via a message called Will Message.
Clean Session - clean the session. If set to "0", the broker will save the session, all client subscriptions, and also forward all messages with QoS1 and QoS2 received by the broker when the client disconnects the next time it connects. Accordingly, when set to "1", the client must resubscribe to topics when reconnecting.
- Session Present – Used in a CONNACK type message. If the broker accepts a Clean Session = 1 connection, then it must set the Session Present(SP) bit to "0". If Clean Session accepts a connection = 0, then the value of the SP bit depends on whether the broker has previously cached a session with this client (if so, SP is set to 1, and vice versa). Thus, this parameter allows the client to determine whether the previous session is saved by the broker.
- Connect Return code – if the broker cannot receive a properly formed CONNECT packet from the client for any reason, then it must set the appropriate value from the following list in the second byte of the CONNACK packet:
|
Price |
Return price |
Description |
|
0 |
0x00 Connection Accepted |
Communication connection accepted |
|
1 |
0x01 Connection Refused, unacceptable protocol version |
The broker does not support the protocol version used by the client |
|
2 |
0x02 Connection Refused, identifier rejected |
The Client ID of the connected client is not in the allowed list |
|
3 |
0x03 Connection Refused, Server unavailable |
A communication connection has been established, but the MQTT service is not available |
|
4 |
0x04 Connection Refused, bad username or password |
Incorrect login or password |
|
5 |
0x05 Connection Refused, not authorized |
The communication link was refused |
|
6-255 |
Saved for backup |
- Topic Name – the name of the topic
Data, cargo
The content and format of the data transmitted in MQTT messages are defined in the application. Data size can be calculated by subtracting the variable header length from the Remaining Length.
Quality of Service (QoS) in MQTT protocol
MQTT supports three levels of quality of service (QoS) for message transmission.
QoS 0 At most once. At this level, the publication server sends a message to the broker once and does not wait for confirmation from it, i.e. send and forget.
QoS 1 At least once. This level guarantees that the message will definitely be delivered to the broker, but there is a possibility that there will be duplicate messages from the publishing server. After receiving a duplicate message, the broker resends this message to subscribers, and the publication server again sends a notification of receipt of the message. If the publication server has not received a PUBACK message from the broker, it resends the packet with DUP set to "1".
QoS 2 Exactly once. At this level, the delivery of messages to the subscriber is guaranteed, and the possibility of repeating the sent messages is excluded.
The publications server sends a message to the broker. This message specifies a unique Packet ID, QoS=2 and DUP=0. The publications server caches the message as unreceived until it receives a PUBREC response from the broker. The broker responds with a PUBREC message carrying the same Packet ID. After receiving it, the publication server sends PUBREL with the same Packet ID. The broker must retain a copy of the message before accepting the PUBREL. After receiving PUBREL, it deletes the copy of the message and sends a PUBCOMP message to the publication server, indicating that the operation is complete.
Protection of data transmission
The following protection methods are implemented to ensure security in the MQTT protocol:
- Customer authentication. A CONNECT packet can contain USERNAME and PASSWORD fields. When implementing a broker, you can use these fields to authenticate the client
- Client access control via Client ID
- Connecting to the broker via TLS/SSL
IIoT hardware with MQTT support
Special devices are used for the construction of Industrial Internet of Things systems, as well as for the integration of existing equipment into cloud systems.
- Web-programmable IIoT controllers
- IIoT modules with remote I/O
- IIoT gateways
- IIoT platforms, MQTT servers
- CO, CO 2, temperature and humidity meters
The Industrial Internet of Things (IIoT) is a new step in the development of industrial automation. Learn more about the solutions offered by AaBaCuS in the field of IIoT.