In this post, we are going to look at 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 go 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 factors given that IoT devices often have limitations in power, consumption, and bandwidth.
In this post, we will see this interesting protocol, and in upcoming posts, we will delve deeper into creating IoT systems with devices like the ESP8266 or Raspberry Pi.
What is MQTT?
MQTT stands for MQ Telemetry Transport, although it was first known as Message Queuing Telemetry Transport. It is a message queue type M2M (machine-to-machine) communication protocol.
It is based on the TCP/IP stack as the foundation for communication. In the case of MQTT, each connection is kept open and “reused” in each communication. This is a difference, for example, from an HTTP 1.0 request where each transmission is done through 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 a proprietary format, it was released in 2010 and became a standard in 2014 by 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 this type of infrastructure, clients connect to a central server called a broker.
To filter the messages sent to each client, messages are arranged in topics organized hierarchically. A client can publish a message on a specific 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 connected clients. This connection remains open until the client terminates it. By default, MQTT uses port 1883 and port 8883 when running over TLS.
To do this, the client sends a CONNECT message containing necessary information (username, password, client-id…). The broker responds with a CONNACK message, containing the connection result (accepted, rejected, etc.).
To send messages, the client uses PUBLISH messages, which contain the topic and the payload.
To subscribe and unsubscribe, SUBSCRIBE and UNSUBSCRIBE messages are used, which the server responds to with SUBACK and UNSUBACK.
On the other hand, to ensure the connection is active, clients periodically send a PINGREQ message, which 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 messages, as they are one of the foundations of the agility that is its strength. 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 being sent, and the message length. The length is encoded in 1 to 4 bytes, of which the first 7 bits are used, and the last is a continuation bit.
- Variable Header. Optional, contains additional information needed 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.
| Message | Code |
|---|---|
| CONNECT | 0x10 |
| CONNACK | 0x20 |
| PUBLISH | 0x30 |
| PUBACK | 0x40 |
| PUBREC | 0x50 |
| PUBREL | 0x60 |
| PUBCOMP | 0x70 |
| SUBSCRIBE | 0x80 |
| SUBACK | 0x90 |
| UNSUBSCRIBE | 0xA0 |
| UNSUBACK | 0xB0 |
| PINGREQ | 0xC0 |
| PINGRESP | 0xD0 |
| DISCONNECT | 0xE0 |
Quality of Service (QoS)
MQTT has a quality of service or QoS mechanism, understood as the way to manage the robustness of message delivery to the client in case of failures (e.g., connectivity).
MQTT has three possible QoS levels.
- QoS 0 unacknowledged (at most one): The message is sent only once. In case of failure, some 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 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 higher load 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 authentication by username and password or via certificate. However, it must be taken into account that many IoT devices have limited capacity, so SSL/TLS can represent a significant processing load.
In many cases, authentication consists of a password and username sent as plain text. Finally, it is also possible to configure the broker to accept anonymous connections.
All of this must be considered when configuring an MQTT system, understanding the risks of each one, as well as their impact on system efficiency.
Advantages of MQTT
There are several advantages of the MQTT protocol as an M2M communication system. On one hand, we have all the advantages of the pub/sub pattern that we saw in the previous post, such as scalability, asynchronicity, decoupling between clients.
Furthermore, MQTT adds a series of features that have made it stand out over other competitors. The main one, as mentioned, is its simplicity and lightness. This makes it suitable for IoT applications, where low-power devices are frequently used.
Moreover, this lower resource requirement translates into lower energy consumption, which is interesting for devices that operate 24/7 and especially for 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 potential quality issues.
Finally, MQTT has important additional measures, such as security and quality of service (QoS). Lastly, it is a long-tested and consolidated solution that provides robustness and reliability.
Conclusion
In summary, we have seen some highlights of MQTT, a very interesting protocol for IoT (although we already saw it’s not the only one). MQTT has the advantages of a pub/sub pattern, standing out for the simplicity of communication.
The MQTT protocol has emerged as one of the standards for IoT applications, both commercial and in the maker sphere. Of course, there are many more aspects we could talk about regarding MQTT, such as advanced security features, message persistence in the broker, configuration of multiple brokers.
In future posts, we will continue to delve deeper into MQTT, seeing how to correctly organize topics, the main brokers, and we will use it in practical cases on devices like Raspberry Pi, ESP8266. See you soon!
