What's New in MQTT 5 and Advantages over version 3.1
by Ponlakshmi
MQTT has become the most widely used and accepted TCP/IP protocol for IoT M2M communication. Its widespread adoption has led to increasing demand for enhancements to the MQTT specification, giving rise to MQTT 5. This new version is designed to meet the needs of modern IoT applications, especially in manufacturing systems, logistics, smart homes, enterprise IoT, and mobile applications, where MQTT 5's features improve scalability, performance, and reliability.
MQTT 5 Features - Functional Overview
Even though the MQTT protocol has not much say on the implementation, MQTT 5 has been carefully designed to help the solution providers scale their solutions better. The new features in MQTT version 5 are intended to accomplish the following objectives:
Building large Scale Applications: The flow control of the data between the MQTT Broker and the clients are largely streamlined with the enhancements in the Protocol. Flow control, Shared Subscription, and Session handling help build large-scale IoT applications.
Better Error Reporting: MQTT 5 Protocol has added strong return codes for the errors that happen during the communication. Almost all the MQTT Packets has the return code in a Single byte of the header. The value of the byte indicates a wider range of failures for better implementation.
Well Defined M2M Communication: MQTT 3 does not support how the topics and the messages need to be defined inside. MQTT 5 has added ways in which the MQTT clients communicate with each other. The MQTT Request and Response flow helps define how the edge devices communicate at the application layer.
Extend the MQTT Specifications: Custom properties can be added to the MQTT Packets and the payload. The custom properties will help extend the protocol as required for the implementation. All the Control and the Data packets support Properties except PINGREQ and PINGRESP.
MQTT 5 vs MQTT 3 - Differences & Advantages
MQTT v5.0 differs from MQTT 3 in various aspects, showcasing advancements in communication protocols and fundamental changes in the way sessions, message transmission, and subscription management are handled. These distinctions contribute to a more evolved and versatile messaging protocol compared to its predecessor.
Below are the advancements in MQTT 5 :
- It introduces the session expiry interval. This allows the clients to set a maximum allowable time for a session, enhancing session management capabilities.
- The will delay interval feature enables clients to specify a time delay before sending the last will & testament message. This provides more nuanced control over message transmission timing.
- Unlike MQTT v3.1, MQTT 5 offers a message expiry interval feature. This allows clients to manage the life-span of messages by setting specific time limits for their relevance.
- The payload format indicator enables clients to specify payload structure, fostering standardized data interpretation. Concurrently, the introduction of a "content type" attribute enhances information clarity, distinguishing it from MQTT 3.1.
- Topic aliases in MQTT 5 streamline communication. Clients can use concise aliases instead of full topic strings, minimizing data overhead.
- The Response topic feature enables a structured request-response model. Clients can expect replies on specified topics, enhancing communication flexibility.
- Using non-local publishing, the clients can choose not to receive the messages they publish.
- Clients enhance retained message control by specifying when & how to send or update retained messages.
- The subscription identifier serves the purpose of allowing the server to identify subscriptions. It also helps in tracking these subscriptions.
- Shared subscriptions provide increased flexibility. They do so through the incorporation of additional symbols and filtering features.
- Reason codes on all ACK messages in MQTT 5 provide clear indicators for message acknowledgment or rejection. This enhances communication transparency and error handling. It stands in contrast to previous versions.
- In MQTT 5.0, packets concerning disconnections can be sent from both the client & server sides, a capability absent in version 3.1.
- User properties in MQTT 5 allow the storage of values for various properties using keys.
- Both the MQTT client and server impose restrictions. These limitations include constraints on maximum packet size (number of bytes to broadcast) & maximum messages to be sent simultaneously. These restrictions apply either on the client or server side.
- Server redirect/reference are attributes facilitating the transfer of MQTT packets between brokers/servers.
MQTT 5 - Technical Drill Down of Features
Session Expiry
Detach the Clean Session flag into a Clean Start flag, which indicates that the session should begin without using an existing session, and a Session Expiry interval, which specifies how long the session should be retained after a disconnect. At disconnect, the session expiry interval can be changed. In MQTT v3.1, setting Clean Start to 1 and Session Expiry Interval to 0 is equivalent to setting Clean Session to 1.
Message Expiry
Message expiry is an optional component of the PUBLISH control packet. The Message Expiry Interval in the PUBLISH packet delivered by the Server to a Client must be set to the received value excluding the time the message has been waiting in the Server. The Publish Expiry Interval, which applies to both online and queued messages, is the duration of the publication in seconds. Allow for the setting of an expiry interval when a message is published.
Reason Code and Reason String
Include a reason code in all response packets. CONNACK, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK, DISCONNECT, and AUTH are some examples. This allows the invoker to check whether the requested function was completed successfully. Most packets containing a reason code should now allow for an optional reason string as well. This is intended to be used for problem identification rather than parsing by the receiver.
Topic Alias
Topic alias in MQTT v5 allows you to use the pub-sub messaging model in a more flexible way. Topic aliases can effectively save both network and processing resources for messages repeatedly published to a finite collection of topics, especially at big volumes. It allows the topic name to be abbreviated to a small integer to reduce the size of the MQTT packet overhead. The Client and Server each specify the maximum number of topic aliases they will accept.
Server Disconnect
The server can send a disconnect message to the client along with a reason code in MQTT 5. Unlike MQTT 3.1, MQTT 5.0 allows messages about disconnections to be sent from both the client and the server. Allow the Server to send DISCONNECT to specify why the connection is being closed. If there were any issues with the server, it would just terminate the session.
Payload Format & Content type
When sending a PUBLISH message, another identifier/value pair is available. This is the indicator for the Payload Format. When a message is published, allow the payload format (binary, text) and a MIME style content type to be specified. These are forwarded to the message’s recipient.
Request / Response Configuration
Request/Response pattern provides the Response Topic and Correlation Data features in MQTT to allow response messages to be routed back to the request’s publisher. Also, give the Client the ability to get configuration information from the Server about how to build the response topics. This mechanism enables the implementation of a “business acknowledgement” functionality that is extensible, dynamic, and transparent.
Shared Subscriptions
With standard MQTT protocols, shared subscriptions are a wonderful way to distribute messages among several MQTT subscribers. In version 5, support for shared subscriptions was added, allowing for load-balanced subscription consumers. A reserved topic root named $share and a share name are used to group subscribers in shared subscriptions.
Subscription Identifiers
When subscribing, the client might specify a subscription identifier. When you successfully create or edit a subscription, the MQTT Server will generate and store the mapping relationship between this subscription and the subscription identifier. Allows a numeric subscription identifier to be given on a SUBSCRIBE and returned when the message is delivered. This enables the Client to determine which subscription or subscriptions were responsible for the delivery of the message.
Subscription Options
Subscription options should be defined primarily for message gateway applications. There’s also a noLocal option for not sending messages from this Client, as well as options for how to handle retained messages on subscription. To customize the server behaviour, you can use more subscription options in MQTT v5.
Flow Control
Allow the Client and Server to select the amount of outstanding reliable messages for MQTT QoS Levels except QoS 0 that they will accept separately. To stay within this quota, the sender pauses sending such messages. This is used to limit the rate at which reliable communications are sent and the number of messages in flight at any given time.
User Properties
Most packets should have User Properties. Client applications define the user properties on PUBLISH, which are included with the message. The Server sends the user properties on PUBLISH and Will Properties to the message receiver. The Server implementation defines the user properties on the CONNECT, SUBSCRIBE, and UNSUBSCRIBE packets. The sender defines the user characteristics on CONNACK, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK, and AUTH packets, and each sender implementation is unique. MQTT does not define the meaning of user properties.
Maximum Packet Size
Allow the Client and Server to declare the maximum packet size they can support independently. Sending a larger packet by the session partner is an error. This property must not be sent if it will raise the size of the PUBACK packet over the receiver’s Maximum Packet Size.
Optional server feature availability
Define a set of features that the Server does not allow, and give the Server a reason to determine the Client about them. Maximum MQTT Quality of Service, Retain Available, Wild card Subscription Available, Subscription Identifier Available, and Shared Subscription Available are some of the characteristics that can be specified this way. Using features that the Server has indicated are not available is an error for the Client.
In previous versions , a Server could refuse to implement a feature by declaring that the Client is not authorized to use it. When the Client utilises one of these features anyhow, this feature allows such optional behaviour to be declared and adds corresponding Reason Codes.
Will Delay
Allow for a time delay between the end of the connection and the transmission of the will message. This is done so that the will message is not sent if the connection to the session is re-established. This allows for minor interruptions of the connection to occur without others being notified.
Server Keep Alive
Keep alive ensures that the broker-client connection is still active and that both the broker and the client are aware that they are linked. It allows the Server to provide the keep alive value the Client should use. This allows the Server to define a maximum keep alive time while still having the Client respect it.
Server Reference
The Client can utilise the Server reference to find another server to use. It allows the Server to specify a different server for CONNACK and DISCONNECT. This can be used to redirect or to perform provisioning.
Assigned Client Identifiers
Allows the Broker to assign Client IDs to clients in a consistent manner. Return the assigned ClientID in situations where the ClientID is assigned by the Server. The restriction that Server-assigned ClientIDs could only be used with Clean Session=1 connections is also lifted.
MQTT 5 helps you Innovate
For most IoT use cases, the MQTT 5 specification has become the logical choice due to its advancements in security, reliability, flexibility, and performance. MQTT 5 not only overcomes the limitations of its predecessor but also lays the groundwork for future innovations. The adoption of MQTT 5 will help you understand and on board your complete Data exchange over it. We anticipate the adoption to sky-rocket in the upcoming years across all sectors.
To Learn more about the protocol,
Don't miss the wave
Get Started with MQTT 5 Today!
Spare 30 mins to get started.
