Connecting millions of devices and exchanging information among them is the main challenge of IoT. As most IoT devices don’t have enough processing resources, IoT developers always looking for lightweight and low-power connecting protocols. MQTT is one of the most popular IoT messaging protocols. MQTT stands for Message Queue Telemetry Transport. But why developers prefer MQTT over other protocols? In this article, I’ll write about 7 Benefits of MQTT protocol that make this protocol great for IoT devices.
#1 MQTT is a Publish/Subscribe protocol
While Request/Response is the most typical model for communication on networks used by protocols like HTTP, MQTT uses another model called pub-sub. The server/client architecture is the base of the Req/Res model. In this model, clients start the connection by sending a request to a specific server. Then the server provides requested data or service to the client as a response. In this model, the client should send a request directly to a specified server.Req/Res model is great for web or mobile applications that use one or more powerful servers to serve client requests.
Publish/Subscribe model has data providers and data consumers instead of server/client. Unlike the Req/Res, we don’t have direct connections between data providers and data consumers. In other words, data providers and consumers don’t know which device provides data for them or consumes their provided data.
In the Pub-Sub model, we have a centralized message broker that distributes data between all devices. Each device can be publisher or subscriber or both of them at the same time. In the Pub-Sub model, each device only connects to the broker and doesn’t know about other present devices on the network. The broker increases network performance in uncertain conditions.
#2 MQTT is a lightweight protocol
MQTT invented and developed by IBM for monitoring oil pipelines in deserts through satellite connection. At the time this protocol invented, satellite connection was so expensive and didn’t provide too much bandwidth. Certain conditions of the project led to developing a lightweight protocol. While the size of HTTP protocol headers is about 8000 Bytes, the MQTT protocol header size is only 2 Bytes. It means MQTT protocol packets are smaller thousands of times compared to HTTP packets.
As forecasted by researchers, the number of IoT devices will exceed 50 billion in the next years. This matter makes IoT developers employ lightweight protocols for connecting things due to prevent overload on the network as each IoT device needs to send or receive data multiple times an hour on average.
Another advantage of this lightweight protocol is the usability on small devices with low memory and low processing power. As most IoT devices don’t have powerfull memory and processors, this protocol is well-suited for these devices.
IBM developed this protocol to monitor oil pipelines in 1990. After years they found out inadvertently they developed a perfectly suited protocol for IoT.
#3 MQTT is a battery friendly protocol
IBM developed MQTT to monitor pipelines in outback deserts. As they don’t have access to electricity grids, they must develop a protocol with the lowest possible energy consumption for satellite communications.
Today most IoT devices connected trough wireless connections and powered by Li-ion batteries. Researchers compare MQTT and HTTP on battery-powered devices. As a result, MQTT consumes 170 times less energy on 3G Networks and 47 times less energy on WiFi networks compared to HTTP. MQTT empowers IoT developers to build devices that stay connected for +10 years using a battery.
#4 MQTT Security
Whenever we talk about network protocols, security will be the most important thing. An unsecured network is nothing more than a bunch of wires, circuits, and devices that ruin humans life. IoT invented to create a better life experience for humans. But without security, IoT creates an awful experience. MQTT supports TLS/SSL for encrypting connections between devices and The broker.
On the other hand, the broker can control the access of each device. Previously I tell you about the Pub/Sub model. In this model, each device can provide or consume data. In MQTT networks, “Topics” are essential to organize exchanging information. Topics organize messages in the same way directories organize files. The broker can block the access of unpermitted devices to restricted Topics. It means you can set permission for each topic to limit different devices’ access.
#5 Works on Both TCP/IP and non-TCP/IP networks
The Internet protocol suite is commonly known as TCP/IP. MQTT usually runs over TCP/IP networks. However, any protocol that provides ordered, loseless, and bi-directional connections can support MQTT.
Some IoT networks like Zigbee is not TCP/IP networks or maybe some networks using not-ordered protocols like UDP. MQTT-SN is a version of MQTT perfectly suited for these networks. MQTT-SN stands for MQTT for Sensor Networks. This protocol previously was known as MQTT-S.
#6 Ensure message delivery
As some of IoT devices are movable objects, and some are battery-powered devices, IoT connections will be unstable some times for some purposes. Sometimes we want to ensure the provided data received by the receiver, and sometimes it doesn’t matter.
In some complex scenarios like IIoT as reliability is a critical factor. Data loss or Duplication is not allowed In these scenarios since it will cause failure. As MQTT origin is the Oil industry, it developed in a way that provides the highest reliability in worst network conditions.
MQTT protocol provides more reliability by adding some flags. QoS (Quality of Service) will guaranty message delivery for you. QoS has 3 possible levels.
QoS 0: At most once delivery
QoS 1: At least once delivery
QoS 2: Exactly once delivery
The default QoS level is QoS 0. This level is suitable for Reliable network conditions if data loss is acceptable by the scenario. For example, ambient sensors send data frequently in smart home projects. Nothing will fail if you lose some data in such cases. QoS 0 provides the highest possible speed and needs the lowest viable network traffic. This QoS level also called “Fire and Forget”.
The other QoS level is QoS1. The broker ensures the message received by data consumers at least once at this QoS level. QoS 1 used if the message delivery guaranty requested and receiving duplicate messages allowed.
QoS 2 Delivers the highest messaging quality. QoS 2 is suitable for critical scenarios that require the message delivery guaranty and additionally duplicate messages not acceptable. QoS 2 provides the most reliable also slowest in comparison to previous levels.
#7 n2n, n21, 12n, 121 ALL Supported!
Each MQTT network has a Broker and one or more Topics. Any connected device can subscribe to each topic if interested in that topic. The broker will send all the published data on a specific topic to all of that topic subscribers. Each permitted device can publish data to a topic, or subscribe to it. This architecture makes it possible to 1-to-1, 1-to-Many, Many-to-1, or Many-to-Many messaging for each Topic.
