Lightweight MQTT Protocol

What is MQTT?

Message Queuing Telemetry Transport is a simple, light-weight & open source message queuing protocol. Sharing Internet of Things (IoT) data between several devices with limited bandwidth is its purpose. To run, it relies on TCP/IP . Clients of this publish and subscribe system can receive and transmit messages. The use of real time connections speeds up the data transfer.

MQTT Specifications

The Message Queuing Telemetry Transport Protocol is an OASIS standard. All specifications are overseen by the OASIS Technical Committee .

• MQTT Version 5.0 Specification – It is an OASIS Standard
• MQTT Version 3.1.1 Specification – It is an older and OASIS standard
• MQTT Version 3.1 Specification – It is an OASIS standard
• MQTT SN – Formerly referred as MQTT -S

How it works?

It operates as a specific kind of client-server message transmission protocol. It makes use of TCP/IP. It's publish-subscribe functionality enables the transfer of data between various devices. Both the client and the broker are subjects of this protocol. The server is the broker, while the connected devices are the clients. It is a lightweight protocol. It has minimal code footprint and lack direct connection between the clients. It’s known as ‘publish’ when the customer wishes to publish data to a broker. The broker uses the term ‘subscribe’ to describe the process of sending data to a client.

Clients don’t transfer data to other clients directly; instead, they send messages on a topic. A receiver client subscribe to topics to receive messages from the publisher client. The broker handles the subscription of subjects. The publisher can send a “Last Will Message” if it's enabled and sends a cached message containing the publishers’ instructions to the subscribing clients in the event of network problems or other factors that prevent it from sending messages. However, if there is a problem with the connection between the broker and the subscriber, the broker will store messages and send them to the subscriber once the connection is restored.

MQTT clients are both publishers, who send messages & subscribers, who receive them.

Types of MQTT Messages

MQ Telemetry Transport defines several types of messages that are used for communication between MQTT clients & brokers. These message types serve different purposes in the MQTT protocol. Amidst numerous types of messages, the three main message types are as follows :

CONNECT : The CONNECT message is sent by a client to establish a connection with the MQTT broker. It contains information such as Client ID, connection options and credentials.

PUBLISH : The PUBLISH message is used for publishing data to a specific topic. It carries the payload which is the actual data & includes metadata such as the topic name, Quality of Service levels, & whether the message should be retained by the broker.

DISCONNECT : A client will send a DISCONNECT message to terminate the MQTT connection.

Why you need MQ Telemetry Transport?

It is suitable for M2M communication as it decreases the need for network bandwidth. Also it accommodates unstable networks, and requires less development effort. The protocol serves to exchange data between controlled devices and server applications. A system that uses the Internet of Things (IoT) is a collection of interconnected objects that can communicate with one another. For this concept, Message Queuing Telemetry Transport works well. Some justifications are as follows:

• It is possible for device to cloud communication to go both ways. This capability makes it simple to broadcast messages to large groups of objects. Also it facilitates the efficient transfer of data.
• Since it uses the ISO standard for messages, it can connect to a huge number of IoT devices.
• As reliability is important, it has three levels of Quality of Service (QoS) settings that can be employed to ensure delivery.
• Clients are portable, use the least amount of hardware resources, and can be set up on tiny microcomputers.
• Even if the client disconnects from the network, it supports persistent sessions. It is to guarantee that the client is rejoined as quickly as feasible.

Benefits of MQTT

Some benefits of MQTT are as follows :

• It requires only minimal bandwidth and computational resources. This makes it ideal for resource-constrained devices with limited processing power & low bandwidth connections.
• Its publish / subscribe architecture model allows for efficient data distribution. It enables scalable as well as flexible communication between devices.
• It minimizes network bandwidth usage by employing techniques. The techniques include message compression, small packet size, and binary payload.
• Its lightweight design and efficient communication patterns contribute to low power consumption. This is important for battery-operated devices. It is because it helps prolong battery life and enables energy-efficient IoT deployments.
• It ensures reliable message delivery through the acknowledgement mechanism provided by the QoS levels. This feature is crucial in applications where data integrity and reliability are paramount.

MQTT Components

MQTT Clients and MQTT Broker/Server are the two main components. An ongoing Message Queuing Telemetry Transport connection connects the clients and the broker. There is no direct connection between the clients. So the broker serves as an intermediary between them. Let’s examine the two important elements described above in more detail.

MQTT Clients

An MQTT client is a device that connects to the broker across a network using a TCP or IP stack that supports this protocol to speak. Clients that runs an MQTT library have the option of being subscribers or publishers. The publisher label shows that the client is currently sending messages. While the subscriber label shows that the client is currently receiving messages. It is possible to incorporate the publish and subscribe features into one client. In the MQ Telemetry Transport infrastructure, every device or edge application needs a client. the need for client is to read and transmit edge data obtained from sensors.

When a connection is made with the server, the client is given the option to subscribe to subjects of interest. It also have the option to post messages to other clients. Broker acts as a connection point between clients. It is because they are unable to communicate directly with one another. Each client functions both as a transmitter and a receiver. This protocol has a very simple and efficient client implementation.

MQTT Broker

The core of MQTT publish/subscribe protocol is the MQTT Broker , which is the client’s equivalent. It serves as a data warehouse for all messages exchanged via this protocol between clients and devices. Following are the tasks that fall under the broker's authority :

• Receiving messages
• Filtering the received messages
• Figuring out who has subscribed to each message
• forwarding the message to the clients who have subscribed to that topic

To subscribe to the topics that the broker requires messages for, clients need to establish a connection. As soon as a sensor-related event occurs, edge clients are able to broadcast data.

All clients with persistent sessions have access to the broker’s session data. Broker’s session data contains subscription and missed message information. Another important duty of the broker is the authentication & authorisation of the clients. The broker always keeps track of subscriptions and recently published MQTT messages. The broker delivers data based on :

• Quality of Service (QoS) Levels
• Retention definition
• Clean sessions specified by the customers

MQTT 5 Specification specifies how the broker should handle shared subscriptions & client disconnections.

In a nutshell, broker acts as the hub through which all messages must travel.

MQTT Devices

There is no distinction between apps and devices in terms of the broker. So the term “Things” applies to both in a Message Queuing Telemetry Transport network. Devices & apps allow publishing on & subscribing to the subjects that the broker controls. Today, there are many different kinds of MQTT-capable devices. Current mission-critical commercial, industrial, and smart home applications use a variety of devices, from straightforward Arduino-based models to more sophisticated ones. There are many smart homes and businesses using connected gadgets nowadays.

IoT Applications Development

Using this, there are two ways to create an IoT application.

Application Over MQTT Broker

The collection of data from multiple sources accounts for 90% of today’s application requirements. As the data gets collected, it gets transferred to the central broker. As a result, it’s preferable to design the application just behind the Broker, where we’ll acquire the most meta data about the data. We reduce the flow of data from the broker to the application client by building the application over the MQTT broker. The Broker got transformed into an IoT Application Framework that performed the same process. Currently building IoT products and applications can take place over MQTT broker. Broker that supports MQTT version 3.1.1 & version 5.0 and may be easily extended to create a complete application.

Application behind MQTT Client

There will be a master client in this approach of IoT Application development. That client will subscribe to all the subjects either one by one or using the # subscription. The subscribed clients will receive all data sent to the broker. The client will have a framework in place to store data, process it, analyse it, and offer it to the client as needed. However, if the number of real time data providers grows, data flow to this client will increase. To avoid data overloading, use version 5.0 shared subscription.

IoT Edge Development

Installation of MQTT clients & brokers is possible on IoT gateways and specialised devices. To publish messages to a central broker, deploy a MQTT client on the device edge. The device can perform more autonomous data processing & coordination among its sensors. It is feasible by deploying a MQTT Broker to the device's edge. A broker, for example, maybe deployed in an auto-mobile to coordinate messaging between the various components. The processing power of edge devices is often insufficient to facilitate clustering. As a result, deploying a single instance of the MQTT broker takes place.

MQTT Gateway

In general, it is possible to consider the MQTT gateway as an intermediary between any IoT platform and sensors. It operates by converting data from these sensors or smart devices into MQ Telemetry Transport messages. It collects messages, gets data from edge sensors, turns it to messages, & sends it to IoT apps or the MQTT platform . Between the sensors and the server, the gateway serves as a middle ware broker. This gateway includes a feature that detects all available sensors on the network that surrounds it. Central IoT platform gives permission to sensors & device to connect with one another. Also it manages them.The self-advertising of sensors and devices helps to find the client’s gateway. Consideration of gateway as an IoT edge device happens in this framework.

How is MQTT superior compared to all other IoT Protocols?

MQTT vs HTTP :

Hyper Text Transfer Protocol (HTTP) is a web protocol. It frequently works in conjunction with HTML to communicate with web apps. It is an open standard protocol.

MQ Telemetry Transport is data-centric, whereas HTTP is document-centric. It uses less memory and power when compared to HTTP and other lightweight protocols. The former offers three levels of Quality of Service. While the later only relies on TCP as a guarantee of message delivery. HTTP lacks other services or Quality of Service. Metrics on 3G networks show that MQTT’s performance is 93 times quicker than HTTP’s.

This protocol has choices for Last Will & Testament and Retained messages. But neither of these capabilities are accessible with the HTTP standard. When comparing the requirements, HTTP specifications are significantly lengthier. When compared to HTTP, this protocol is more simpler to use. Although HTTP is valuable and extensible, MQTT is best suited for Internet of Things development.

When compared, HTTP has a higher level of complexity. In contrast to MQTT, HTTP does not disclose device connection status. This protocol encrypts data prior to transmission; the HTTP protocol does not. HTTP has more protocol overhead compared to Message Queuing Telemetry Transport. MQ Telemetry Transport is commonly used in IoT applications. Whereas, HTTP is widely used in web application, APIs, and browser-based interactions.

MQTT vs CoAP :

The IETF developed the binary Constrained Application Protocol (CoAP). It is an open standard protocol. CoAP is widely accessible. In contrast to MQTT, which provides a Quality of Service, CoAP uses UDP, which has no guarantee of delivery. CoAP adopts a request / response messaging similar to HTTP. It's designed to be lightweight and suitable for resource-constrained devices. It supports client-server communication model. Also it can handle a significant number of clients connecting to CoAP servers.

CoAP is generally a one-to-one protocol that connects server and client to convey data. MQTT, on the other hand, uses a central broker to route messages between several clients. CoAP is less developed and is less stable. In comparison to CoAP, MQ Telemetry Transport has a greater packet size. CoAP only permits 4 message kinds, but MQTT supports 16 different message types. There are 3 levels of application reliability for MQTT whereas, CoAP has only 2 levels. CoAP lacks persistence support, but MQTT offers.

MQTT vs AMQP :

AMQP stands for Advanced Message Queuing Protocol. AMQP is an open messaging and standard protocol for financial systems. It is binary TCP-based. It claims to support both the publish/subscribe and request/response patterns.

MQTT offers three Quality of service (QOS) levels, whereas AMQP only provides two. Additionally, AMQP does not have the “last will & testament” capability that MQTT does. It guarantees that the client will receive a message in the event of a disconnect. AMQP protocol does not reveal the connection status. Whereas it is clearly known in the Message Queuing Telemetry Transport protocol.

AMQP is a general-purpose message queuing protocol that is more complex than MQTT. MQTT has a higher degree of scalability than AMQP. MQTT is easier to set up than AMQP since it is a shorter, simpler protocol. When compared to AMQP, MQTT has a quicker response time

MQTT vs XMPP :

Extensible Messaging and Presence Protocol (XMPP) is an instant communication protocol. is an instant communication protocol. It's based on a decentralized client-server architecture. It's designed for use-cases involving instant messaging, chat applications, and presence-based services. It uses massive, complex messages that rely on Extensible Markup Language (XML). XMPP is more feature-rich and flexible. But it has a higher protocol overhead compared to Message Queuing Telemetry Transport. The later protocol offers 3 levels of QoS to ensure reliable message transport. And the former protocol lacks.

MQTT vs DDS :

Data Distribution Service (DDS) is broker free protocol for machine-to-machine communication. It has the capacity to ease data interchange using publish/subscribe methodologies. Unlike MQTT, DDS is not compatible with embedded systems. It is because it's a heavyweight protocol. DDS uses twice as much bandwidth as the MQ Telemetry Transport protocol does. QoS features are only used in stringent DDS environments.

All of these factors combine to make MQTT a good choice for your IoT device. Refer this blog to know about MQTT vs REST from IoT implementation perspective.

Common Questions on MQTT