https://ipc2u.com/articles/knowledge-base/what-is-mqtt-and-why-do-we-need-it-in-iiot-description-of-mqtt-protocol/
01:21 26.04.2018
+49 511 807 259-0, sales@ipc2u.com
Cart
Price on request
Discount -
Total:
Favorite products
Call
Authorization
Login:
Password:


Forgot your password? Registration
Forgot your password?
e-Mail::
Forgot your password?
+49 511 807 259-0, sales@ipc2u.com

What is MQTT and why do we need it in IIoT? Description of MQTT protocol


Content:

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.

Back to content

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


Back to content

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

Back to content

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 TypeValueDirection of flow Description
Reserved0000 (0)forbiddenReserved
CONNECT0001 (1)C* -> S**Client request to connect to server
CONNACK0010 (2)C <- SConnect acknowledgment
PUBLISH0011 (3)C <- S, C -> SPublish message
PUBACK0100 (4)C <- S, C -> SPublish acknowledgment
PUBREC0101 (5)C <- S, C -> SPublish received
PUBREL0110 (6)C <- S, C -> SPublish release
PUBCOMP0111 (7)C <- S, C -> SPublish complete
SUBSCRIBE1000 (8)C -> SClient subscribe request
SUBACK1001 (9)C <- SSubscribe acknowledgment
UNSUBSCRIBE1010 (10)C -> SUnsubscribe request
UNSUBACK1011 (11)C <- SUnsubscribe acknowledgment
PINGREQ1100 (12)C -> SPING request
PINGRESP1101 (13)C <- SPING response
DISCONNECT1110 (14)C -> SClient is disconnecting
Reserved1111 (15)ForbiddenReserved

*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:

    ValueReturn Code ResponseDescription
    00x00 Connection AcceptedConnection accepted
    10x01 Connection Refused, unacceptable protocol versionThe Broker does not support the version of protocol requested by the Client
    20x02 Connection Refused, identifier rejectedClient ID of the Client for connection is not in the list with allowed IDs
    30x03 Connection Refused, Server unavailableThe Network Connection has been made but the MQTT service is unavailable
    40x04 Connection Refused, bad user name or passwordThe data in the user name or password is malformed
    50x05 Connection Refused, not authorizedThe Client is not authorized to connect
    6-255Reserved 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.

Back to content

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.

Back to content


If you have any questions, please send an email at: sales@ipc2u.com

Related


Related products


MQ-7244M MQ-7244M


MQTT I/O Module with 2-port Ethernet Switch, with 8-ch DI and 8-ch DO

MQ-7251M MQ-7251M


MQTT I/O Module with 2-port Ethernet Switch, with 16-ch DI

MQ-7252M MQ-7252M


MQTT I/O Module with 2-port Ethernet Switch, with 8-ch DI and 8-ch DO

MQ-7253M MQ-7253M


MQTT I/O Module with 2-port Ethernet Switch, with 16-ch DI

MQ-7255M MQ-7255M


MQTT I/O Module with 2-port Ethernet Switch, with 8-ch DI and 8-ch DO

UA-5231 UA-5231


IoT Communication Server, with ARM 1 GHz, 512Mb DDR3, 512Mb Flash, 1xE...

https://ipc2u.com/articles/knowledge-base/what-is-mqtt-and-why-do-we-need-it-in-iiot-description-of-mqtt-protocol/
01:21 26.04.2018