The Message Queuing Telemetry Transport, popularly known as the MQTT is the best messaging protocol for connecting the Internet of Things devices to the cloud. In 1999, MQTT was initially developed by the engineers for monitoring the oil and gas pipelines via satellite networks. There was a necessity for a protocol to manage the devices from a remote location over a limited network bandwidth. The remarkable information is – there was not a thing called IoT or Cloud Computing at that time. The MQTT is an ISO standard protocol and works top of the TCP/IP. It is a publish-subscribe protocol which needs a message broker.
To understand what this publish-subscribe protocol is, imagine you have already subscribed to your favourite You-Tube channel. Every week, the channel delivers a content, when you already subscribed to that channel, you will get a notification on your mobile whenever new content is uploaded. Here, the subscriber is you, and the publisher is your favourite channel.
Timeline
In 2010 MQTT version 3.1 was released to the public.
In 2014, MQTT 3.1.1 was released by the OASIS Technical Community. The ISO released it in 2016. After five years, MQTT 5 was delivered in March 2019 by the Technical Committee.
Then MQTT v3.1.1 and now v5.0? Why there is no next release v4.0?
The explanation signifies in the fixed header of the MQTT CONNECT Control Packet. This header carries a singular byte value for the protocol version. If you examine some CONNECT packets on the wire, MQTT 3.1 holds the value “3” as protocol version. Also, for MQTT 3.1.1, the protocol version is “4”. To match the official MQTT version with the protocol version name, the TC had decided to name the latest version as MQTT v5. The new version gets to have the same number for both the protocol version name (0x05) as well as the official version name (MQTT v5).
MQTT v5
MQTT 5 is the most widespread and feature-rich update to the MQTT specification ever. These latest updates mainly help the developers to overcome the complexity in their projects and focus on increasing the productivity and the scalability. The MQTT 5 spec has enhanced the clear choice for most IoT use cases.
The objective of MQTT 5 Specifications done by the Technical Committee:
- Progress error reporting
- Add specialities that long term users want without increasing overhead or decreasing ease of use.
- Greater flexibility and easier implementation.
- Shared Subscriptions
- Negative Acknowledgements
- Payload Format Indicators
- User Properties Identifiers
- Topic Aliases
- Session and Message Expiry
MQTT v5 is an indispensable update for the messaging protocols available; the standards satisfy all the features required for the modern applications of IoT.
Features of MQTT v5
These new features particularly befit for applications like cloud computing, reliable error handling to implement mission-critical messaging and seek easier integration of MQTT messages into their existing computing infrastructure.
Session and Message Expiry
MQTT v5 has an exciting feature which improves the error checking between the client and the broker. This feature is a session and message expiry, which allows the user to set a time limit for each message to send and receive. If the message is not delivered at a certain period, then it is deleted or expired. Suppose the user sets a message delivery point to start a machine at a particular time. In that case, if that message does not deliver at a specific time, it will be automatically deleted, and the machine does not start at all. Due to critical safety systems, there should be no machine start at all.
Negative Acknowledgements
Version 5 also introduced negative acknowledgements, which makes the messages secure for the client. Under predefined restrictions, the message broker can send an acknowledgement to reject particular messages. Those messages can be of maximum payload, maximum QoS (Quality of Service) or any unsupported features. This update can save the client-side from malicious attacks or erroneous activities.
Shared Subscriptions
Shared Subscription is the other new feature where multiple MQTT clients share the same topic subscriptions from an MQTT broker. This feature makes the system highly scalable and available. The clients share the same subscriptions can deploy from different cloud cluster sensor nodes. This feature is useful when the messages stored in the back-end database and later used for the system integration or statistical analysis.
Topic Alias
Another impressive feature is the topic alias. Imagine you have millions of devices transmitting billions of messages in the system. A very long topic string makes the demands for the network. Topic Alias can implement to replace the string with an integer. Topic Aliases substitute UTF-8 String topic names with an integer. Supporting this feature is an option for both broker and the clients. But, the broker and client which is used should support this new feature.
For instance, if the topic name is data/india/southindia/tamilnadu/chennai/ambattur/pudur/box-32543y/junction/damage/power describes the power consumption in a particular junction box in a particular location in India. We can notice that sometimes the size of the topic name is more than that of the payload. So, the topic name can be replaced with a single integer. When you want to send many small messages in real-time with long topic names, the Topic Alias feature helps to increase performance.
User Properties
The MQTT v5 adds another feature User Properties, which include a key-value property to the message header of an MQTT message. This feature allows you to add the meta-information to the header of the message which is a version number of the component use or the software version of the device that the user from the client-side can use to process the information and perform analysis.
Payload Format Indicators and Content-Type
To process the information or message easier, the payload format indicators and the Content-type have been introduced in this version. It is a binary or text form which adds to the information. The Payload Format Indicator determines whether a payload is an undefined array of bytes or a UTF-8 encoded message. In the case of UTF-8 encoded messages, the sender can use the content type to define the specifics of the payload.
So what does the indicator do? This indicator is any part of the MQTT packet that contains the payload. For example, the control system for a biometric system might send metrics to need to process by image recognition software. At the same time, other messages might require a different style of processing. The indicator is a byte value. A value of 0 symbolises an “unspecified byte stream”. A value of 1 means a “UTF-8 encoded payload”. If neither Payload Format Indicator provides, the default value is 0.
Conclusion
The latest MQTT 5 features favourably address the constraints of MQTT 3 and open the way for coming innovation. Over the following few years, we expect to see enormous growth in MQTT choosing across all industries, including manufacturing, automotive, critical infrastructure, logistics, smart cities, etc. MQTT is on the edge of growing the standard for all IoT.
