MQTT 5.0: 7 New Features and Migration Considerations

The MQTT protocol (Message Queuing Telemetry Transport) is a lightweight messaging protocol designed for resource-constrained devices and low-bandwidth, high-latency networks. It is particularly suitable for remote connections that require minimal code footprint or limited network bandwidth.

MQTT 5.0 is the latest version of this protocol, featuring numerous improvements over previous versions. New functionalities include: reason codes, session expiry intervals, topic aliases, user properties, subscription options, request/response capabilities, and shared subscriptions. This article will explore these new features, discuss the support for the MQTT 5.0 protocol by mainstream MQTT Brokers and client SDKs, and highlight some key considerations for migrating from MQTT 3.1.1 to MQTT 5.0.

The Development of MQTT 5.0

MQTT was developed in 1999 by Dr. Andy Stanford-Clark of IBM and Arlen Nipper of Arcom (now Eurotech) for the oil and gas industry. At that time, engineers needed a protocol to enable low bandwidth and low battery consumption for monitoring oil pipelines via satellite networks. The original MQTT 3.1 version was very lightweight and easy to implement, making it suitable for various IoT devices.

MQTT 3.1.1 was released in 2014 and is maintained by the international standards organization OASIS. This update included some refinements that enhanced clarity and interoperability.

Due to its ability to efficiently transmit messages over resource-constrained networks, the MQTT protocol has gained widespread popularity in IoT applications. As the IoT industry has evolved, the demands of IoT applications have also changed. OASIS released MQTT 5.0 in 2019, adding new features to better meet the complex needs of modern IoT applications.

7 New Features of MQTT 5.0

1. Reason Codes: Understanding Disconnection or Failure Reasons

Unlike previous versions, MQTT 5.0 can provide a reason code for each acknowledgment message, helping us understand the reasons for disconnection or failure.

This improvement aids in troubleshooting and more granular error handling. For example, if a client fails to connect to the server, the server will return a reason code explaining the failure. This could be due to various reasons, such as incorrect login credentials or the server being offline. (Refer to MQTT 5.0 Reason Code Introduction and Quick Reference: https://www.emqx.com/en/blog/mqtt5-new-features-reason-code-and-ack)

2. Session Expiry Interval: Managing Session Lifecycles

This feature allows clients to specify how long the server should retain the session after the client disconnects. In previous MQTT versions, sessions either ended immediately upon disconnection or were retained indefinitely. With MQTT 5.0, you can specify a specific time period during which the session remains valid after disconnection, allowing for more flexible session lifecycle management and resource savings on the server.

3. Topic Aliases: Reducing Message Header Overhead

MQTT 5.0 introduces topic aliases to reduce message header overhead. In previous versions, each message needed to include the topic name, leading to larger packet sizes.

With topic aliases, a short numeric alias can be assigned to a topic. This alias can replace the full topic name in subsequent messages, significantly reducing the size of MQTT headers and saving network bandwidth. (Refer to Topic Alias Explanation: https://www.emqx.com/en/blog/mqtt5-topic-alias)

4. User Properties: Custom Metadata in MQTT Headers

This feature allows users to add custom metadata to the headers of MQTT messages. This is very useful for applications that need to carry additional information in MQTT messages, such as timestamps, device locations, or other application-related data. User properties enhance the flexibility and control of MQTT message transmission. (User Properties Explanation: https://www.emqx.com/en/blog/mqtt5-user-properties)

5. Subscription Options: Enhanced Subscription Control

MQTT 5.0 allows clients to specify how they receive messages for each subscribed topic. For example, clients can specify whether they receive retained messages for a subscription or whether they receive messages with the same QoS (Quality of Service) level as the subscription.

6. Request/Response: Allowing Clients to Reply to Specified Topics

The request/response feature allows clients to specify a topic for the server to reply directly. In earlier MQTT versions, if a client wanted to reply to a message, it had to publish the reply to a topic, and the original sender had to subscribe to that topic to receive the reply.With the request/response feature of MQTT 5.0, communication between clients and servers becomes more efficient and concise.

7. Shared Subscriptions: Subscriber Load Balancing Feature

This feature allows multiple clients to share a subscription. When a message is published to a shared topic, the server distributes the message to one of the clients in the shared subscription, achieving message load balancing.This feature is particularly useful in scenarios where multiple service instances are running and want to evenly distribute the workload.

Support for MQTT 5.0 Protocol by Existing Brokers and Client SDKs

The MQTT 5.0 protocol has been widely welcomed by the IoT community, with many MQTT Brokers and client software development kits (SDKs) supporting this new version. Mainstream MQTT Brokers such as EMQX, Mosquitto, and NanoMQ have integrated MQTT 5.0 features into their platforms, allowing users to fully leverage the advantages of the new protocol.

In terms of client SDKs, libraries like Paho, which have a large user base, also support MQTT 5.0, helping developers utilize the new features of MQTT 5.0 in IoT applications. Other client SDKs that support MQTT 5.0 include MQTT.js and MQTTnet.

Considerations for Migrating from MQTT 3.1.1 to MQTT 5.0

If you are currently using MQTT 3.1.1, you may consider upgrading to MQTT 5.0. Before migrating, consider the following points.

1. Update MQTT Broker

After evaluating the existing infrastructure and deciding to migrate, the next step is to update the MQTT Broker. This means installing the latest version of the MQTT Broker that supports MQTT 5.0.

Upgrading the Broker should be done cautiously, as it will affect all MQTT clients. It is recommended to test the new Broker in a non-production environment before deploying it in production. Additionally, ensure that necessary updates are made to the Broker’s configuration to support the new features introduced in MQTT 5.0.

2. Update Client Libraries

After updating the MQTT Broker, you also need to update the MQTT client libraries. Similar to updating the Broker, the new client libraries should be tested in a testing environment first. Also, ensure that the application code can accommodate the new features of MQTT 5.0. Note that updating may require some code refactoring.

3. Address Security Issues

While MQTT 5.0 brings several improvements, it also introduces some new security risks. For example, with the new user properties feature, clients can send custom data to the Broker. This is a powerful feature, but if misused, it can lead to issues. Therefore, it is essential to review all new features from a security perspective.

Measures to enhance security include: using the new enhanced authentication features to strengthen security, restricting clients to send only necessary user properties, and continuously monitoring for any suspicious activity.

4. Post-Migration Monitoring

After migrating to MQTT 5.0 and utilizing its features, continuous monitoring of your system is still necessary. Monitoring should not only focus on technical aspects, such as message transmission or client connections, but also on the effectiveness of the new MQTT 5.0 features in the application. This way, you can understand how these features optimize your application and identify areas for further improvement.

Embrace MQTT 5.0 with EMQX

EMQX is the world’s most scalable open-source MQTT Broker, fully compatible with all features of MQTT 5.0. Any device using any version of the MQTT protocol can connect directly to EMQX and communicate.

EMQX has a comprehensive authentication and authorization mechanism, along with full support for SSL/TLS, ensuring secure communication. The SQL-based rules engine has data bridging capabilities, allowing for one-stop IoT data extraction, filtering, transformation, storage, and processing without the need for coding.

EMQX also boasts high performance, with a single EMQX 5.0 cluster capable of supporting up to 100 million concurrent MQTT connections. A single EMQX server can achieve throughput of millions of messages per second.

We have built a rich set of features around the MQTT Broker to help you easily utilize the protocol, such as MQTTX (a cross-platform MQTT client tool), NanoMQ (a lightweight MQTT Broker for IoT edge), and EMQX Cloud (a fully managed MQTT cloud service). All these tools fully support MQTT 5.0.

MQTT 5.0: 7 New Features and Migration Considerations

MQTT 5.0: 7 New Features and Migration Considerations

Click “Read More” to learn more

Leave a Comment