What is MQTT? Its importance as an IoT protocol

In this post we are going to see MQTT, the Machine to Machine (M2M) communication protocol that is gaining so much popularity for communication between IoT devices.

In the previous post about IoT we saw the main communication protocols for IoT. There we saw the concepts of pub-sub, message queue, and message service. We will use these concepts so if you have any doubts, you should stop by and take a look.

The MQTT protocol has become one of the main pillars of IoT due to its simplicity and lightness. Both are important conditions given that IoT devices often have limitations of power, consumption, and bandwidth.

In this post we will see this interesting protocol, and in the next posts we will delve into the creation of IoT systems with devices such as the ESP8266 or Raspberry Pi.

What is MQTT?

MQTT stands for MQ Telemetry Transport, although it was first known as Message Queing Telemetry Transport. It is a machine-to-machine (M2M) communication protocol of the message queue type.

It is based on the TCP/IP stack as a basis for communication. In the case of MQTT, each connection remains open and is “reused” in each communication. This is a difference, for example, from an HTTP 1.0 request where each transmission is made over a connection.

MQTT was created by Dr. Andy Stanford-Clark of IBM and Arlen Nipper of Arcom (now Eurotech) in 1999 as a mechanism to connect devices used in the oil industry.

Although initially it was a proprietary format, in 2010 it was released and became a standard in 2014 according to OASIS (Organization for the Advancement of Structured Information Standards).

How does MQTT work?

The operation of MQTT is a push messaging service with a publisher/subscriber (pub-sub) pattern. As we saw in the previous post, in these types of infrastructures, clients connect to a central server called a broker.

To filter the messages that are sent to each client the messages are arranged in hierarchically organized topics. A client can publish a message on a certain topic. Other clients can subscribe to this topic, and the broker will deliver the subscribed messages to them.

Clients initiate a TCP/IP connection with the broker, which keeps a record of the connected clients. This connection remains open until the client terminates it. By default, MQTT uses port 1883 and 8883 when running over TLS.

For this, the client sends a CONNECT message containing necessary information (username, password, client-id…). The broker responds with a CONNACK message, which contains the result of the connection (accepted, rejected, etc).

To send messages, the client uses PUBLISH messages, which contain the topic and payload.

To subscribe and unsubscribe, SUBSCRIBE and UNSUBSCRIBE messages are used, to which the server responds with SUBACK and UNSUBACK.

On the other hand, to ensure that the connection is active, clients periodically send a PINGREQ message that is responded to by the server with a PINGRESP. Finally, the client disconnects by sending a DISCONNECT message.

Structure of an MQTT message

One of the most important components of the MQTT protocol is the definition and typology of the messages, since they are one of the foundations of the agility on which its strength lies. Each message consists of 3 parts:

• Fixed header. Occupies 2 to 5 bytes, mandatory. It consists of a control code, which identifies the type of message sent, and the length of the message. The length is encoded in 1 to 4 bytes, of which the first 7 bits are used, and the last one is a continuity bit.
• Variable header. Optional, contains additional information that is necessary in certain messages or situations.
• Content (payload). This is the actual content of the message. It can have a maximum of 256 Mb although in real implementations the maximum is 2 to 4 kB.

The types of messages and control codes sent in the MQTT protocol are as follows.

Quality of Service (QoS)

MQTT has a quality of service (QoS) mechanism, understood as the way to manage the robustness of message delivery to the client in the event of failures (for example, connectivity issues).

MQTT has three possible QoS levels.

• QoS 0 unacknowledged (at most one): The message is sent only once. In case of failure, it may not be delivered.
• QoS 1 acknowledged (at least one): The message is sent until delivery is guaranteed. In case of failure, the subscriber may receive some duplicate messages.
• QoS 2 assured (exactly one). It is guaranteed that each message is delivered to the subscriber, and only once.

Using one level or another depends on the characteristics and reliability needs of our system. Logically, a higher QoS level requires a greater exchange of verification messages with the client and, therefore, a greater burden on the system.

Security in MQTT

Security should always be an important factor to consider in any M2M communication system. The MQTT protocol has various security measures that we can adopt to protect communications.

This includes SSL/TLS transport and user authentication by username and password or by certificate. However, it should be noted that many IoT devices have limited capacity, so SSL/TLS can be a significant processing burden.

In many cases, authentication consists of a username and password that are sent as plain text. Finally, it is also possible to configure the broker to accept anonymous connections.

All of this must be taken into account when configuring an MQTT system, and understanding the risks of each of them, as well as their impact on system efficiency.

Advantages of MQTT

There are several advantages of the MQTT protocol as a machine-to-machine communication system. On the one hand, we have all the advantages of the pub/sub pattern that we saw in the previous post, such as scalability, asynchrony, and decoupling between clients.

In addition, MQTT brings a series of characteristics that have made it stand out over other competitors. The main one, as we mentioned, is its simplicity and lightness. This makes it suitable for IoT applications, where frequently devices with limited power are used.

Furthermore, this lower resource requirement translates into lower energy consumption, which is interesting in devices that operate 24/7 and especially in battery-powered devices.

Another consequence of the lightness of the MQTT protocol is that it requires minimal bandwidth, which is important in wireless networks, or connections with possible quality problems.

Finally, MQTT has important additional measures, such as security and quality of service (QoS). Finally, it is a long-tested and consolidated solution, which provides robustness and reliability.

Conclusion

In summary, we have seen some glimpses of MQTT, a very interesting protocol for IoT (although we already saw that it is not the only one). MQTT has the advantages of a pub/sub pattern, and stands out for the simplicity of communication.

The MQTT protocol has emerged as one of the standards for IoT applications both commercially and in the maker field. Of course, there are many more aspects that we could talk much more about MQTT, such as advanced security functions, message persistence in the broker, configuration of various brokers.

In the next posts, we will continue to delve into MQTT, seeing how to properly organize the topics, the main brokers, and we will use it in practical cases on devices like Raspberry Pi, ESP8266. See you soon!