What is MQTT and How it works?

What is MQTT and How it works?

“Ever wondered how does a IoT network work smoothly despite the amount of data thrown around…”

The term MQTT stands for Message Queue Telemetry Transport. This seems very technical in its expanded form, so let us try and unravel it. In simple terms, it is a communication and messaging protocol used by devices that help transmit and receive messages using a queue mechanism.

With the advent of the Internet of Things (IoT), MQTT has become a de facto standard used by many IoT platforms. Typically the MQTT server is hosted on the cloud with the devices communicating connected to the internet. Nevertheless, it can also work on the In-Premise server.

HOW DOES MQTT WORK?

The whole mechanism works using a Client/Broker architecture. The communication is orchestrated with the help of a central MQTT Message Broker. MQTT protocol works like a post office.

The post that is sent to a particular address, is actually sent to the post office instead of the intended destination and the post office delivers the post to the respective destinations. The MQTT broker plays the role of a postman by accepting messages from the MQTT clients and then delivering the correct messages to the intended destination.

Technically the way it works is by using a model called the “Publish and Subscribe model” also known as the Pub-Sub model. Here the clients publish data on different topics which are picked by the broker. The data published on topics is maintained and then delivered to the clients who have subscribed to the topic by the broker.

PUBLISH SUBSCRIBE MODEL

In this model, the device wanting to send a message connects to the broker. Once the connection is established then it publishes the message. Every message has defined Topics associated with them.

In the figure, we have the humidity sensor publishing the humidity percentage on the topic “Humidity”. This data is picked up by the MQTT broker and stored under the topic “Humidity” along with additional parameters like from which sensor was it received and at what time was it received.

All the messages on a given Topic are queued in a First In First Out (FIFO) sequence by the MQTT broker. The data collected is stored in a database. In this case, the humidity percentages which are received from the Humidity Sensor device get stored in a message queue. Especially in the case of IoT devices, the frequency of the data sent would be a lot more when the tracking and position data is being sent.

The broker then checks which devices are subscribed to the topic of Humidity. These messages queued up are then sent by the broker to all the devices that are subscribed to the Humidity topic. In this case, the humidity controller and the temperature controller both receive the humidity data since they are both subscribed to the topic of humidity. As temperature increases the relative humidity increases hence these two controllers need to work in tandem to ensure optimum humidity control.

ADVANTAGES OF THE PUBLISH-SUBSCRIBE MODEL

The Pub Sub model has several advantages because of the way it works like:

It ensures that there are no insecure connections between two devices since the entire communication happens with the help of a broker. Thus ensuring that the devices are decoupled and the communication happens asynchronously.
With the advent of IoT, the number of devices is increasing so is the amount of data that needs to be exchanged between them. The model by separating the data storage and data communication makes it easier to scale up without loss of data or consistency.
It also manages and maintains the connectivity states of the devices including security, credentials, and certificates.
It also does this without putting strain on the network used and does it without compromising the security of the network.
As it is a topic-based subscription, thus making one-to-many and many-to-one messaging possible. As a result, a single message can be sent to multiple devices as well as multiple messages to a single device thus reducing the quantum of data and connections involved.
The same device can publish as well as consume data at the same time as it is a bidirectional protocol. Thus this acts like two-channel communication.

MQTT FACTS

History

They say necessity is the mother of invention. This is so much true in the case of MQTT. Dr. Andy Stanford-Clark of IBM®, and Arlen Nipper of Arcom (now Eurotech), together invented MQTT way back in 1999. They had a task at hand of connecting oil pipelines over satellite networks.

In those days SCADA (Supervisory Control and Data Acquisition) systems used telemetry to remotely connect and control the oil refinery infrastructure. These telemetry methods were proprietary in those days causing a lot of compatibility issues. Andy and Arlen decided to build an open-source solution that would remove the issue of compatibility. Thus MQTT got created.

Soon they realized that MQTT’s use was not limited to controlling these pipelines via the satellite network. It was such a good solution that it found uses beyond the original scope. In the 21st century, the traction for IoT took an upward trajectory.

In 2008 the open-source MQTT broker Mosquitto was released. This increased the adoption rate of MQTT. 2014 saw the MQTT becoming an OASIS standard followed by becoming an ISO standard in 2016. Today all the major IoT platforms have embraced MQTT.

Generalia

The three goals that the founders of MQTT targeted were: 1) that it be compact, 2) it should be easy-to-use, and 3) it is easy-to-implement. 4) Provide quality service

The verbs or actions needed for the working of the protocol are also limited and few. It can support a wide variety of servers and clients with the smallest packet size of 2 Bytes supported. It has reduced the complexity of footprints to the range of 30kb. The protocol supports the loss of connection between the client and server allowing a resend of a data packet.

Another advantage of the MQTT server is that it can communicate with even the traditional system as the connections are TCP/IP. Thus it can send out messages, and alerts to even a regular web application so that it can further process and display the same.

Quality of Service

The quality of any connection offered by a network to the connected devices is talked about in terms of Quality of Service (QoS). The Quality of Service (QoS) level is essentially an agreement between the sender of a message and the receiver of a message. It defines the guarantee of delivery for any message being sent on a connection in a network.

MQTT offers 3 levels of Quality of Services viz At most once – QoS 0, At least once – QoS 1 and Exactly once – QoS 2. The device or client publishing defines when sending data to the broker. Similarly, the client also defines the level when subscribing from a broker.

MQTT 5

The current version of the standard is version 5.0. This version is the successor to the 3.1.1 version. There was no ver 4.0 released. This was done to synch with the single byte header version data which was 4 for ver 3.1.1. They moved both to version 5 to fix this mismatch.

Some of the new additions or changes in the new version are:

Increased scalability and support for larger scales
The error reporting is improved with the Reason Code & Reason String
Common patterns have become formalized
It has become more extensible with the inclusion of user properties, payload format, and content type
there have been improvements to the performance
There is more improved support for small clients

Looking Ahead

With the additions and newer versions, MQTT is going to be geared to be the de facto standard for all kinds of device-to-device communications hence something of standard with more and more relevance in the future.