EMQX Dedicated New Feature: Event History is available for private beta test. →

MQTT 5.0: 7 New Features and a Migration Checklist

Zibo Zhou
Oct 25, 2023
MQTT 5.0: 7 New Features and a Migration Checklist

MQTT, which stands for Message Queuing Telemetry Transport, is a lightweight messaging protocol designed for constrained devices and low-bandwidth, high-latency networks. It is particularly useful for remote connections where a small code footprint is required or network bandwidth is limited.

MQTT 5.0 is the latest version of the protocol, offering many improvements over its predecessors. New features include reason codes, session expiry intervals, topic aliases, user properties, subscription options, request/response feature, and shared subscriptions. We’ll explore these new features, explain how popular brokers and client SDKs are supporting MQTT 5.0, and some key considerations when migrating from MQTT 3.1.1 to MQTT 5.0.

Brief History and Evolution of MQTT 5.0

MQTT was first developed in the late 1990s by Dr. Andy Stanford-Clark of IBM and Arlen Nipper of Arcom (now Eurotech), to monitor oil pipelines over satellite networks. The initial version, MQTT v3.1, was designed to be lightweight and easy to implement, making it suitable for many IoT devices.

MQTT 3.1.1, an OASIS standard, was released in 2014, which included minor changes to the protocol to improve its clarity and interoperability. Its simplicity and efficiency in delivering messages over networks with limited resources led to its widespread adoption in IoT applications.

However, as the IoT industry evolved, so did the needs of its applications. This led to the development of MQTT 5.0, released in 2019, which introduced new features to address these changing needs. With its enhanced features, MQTT 5.0 is better equipped to handle the complex requirements of modern IoT applications.

7 New Features in MQTT v5

1. Reason Codes: Understanding Disconnections or Failures

Unlike its predecessors, MQTT 5.0 can provide a reason code for every acknowledgement packet, giving us a better understanding of why a disconnection or failure occurred.

This improvement aids in troubleshooting and allows for more precise error handling. For instance, if a client fails to connect to the server, the server will return a reason code explaining why the connection was unsuccessful. This could be due to a range of issues, from incorrect login credentials to a server being unavailable.

Learn more in our detailed guide to MQTT Reason Codes.

2. Session Expiry Intervals: Managing Session Lifetimes

This feature allows the client to specify how long the server should maintain its session after the client disconnects. In previous MQTT versions, a session either ended immediately upon disconnection or continued indefinitely. With MQTT 5.0, you can define a specific time period for which the session should be kept alive after disconnection. This provides greater flexibility in managing session lifetimes and conserves resources on the server.

Learn more in our detailed guide to MQTT Session Expiry Intervals.

3. Topic Aliases: Reducing Overhead in Message Headers

MQTT 5.0 introduces topic aliases to reduce the overhead in message headers. In previous versions, the topic name needed to be included in every message, leading to larger packet sizes.

With topic aliases, a short numeric alias can be assigned to a topic. This alias can be used in place of the full topic name in subsequent messages, significantly reducing the size of the MQTT header and conserving network bandwidth.

Learn more in our detailed guide to MQTT Topic Aliases.

4. User Properties: Custom Metadata in MQTT Headers

This feature allows users to include custom metadata in the headers of MQTT packets. This can be particularly useful for applications that need to send additional information with their MQTT messages, such as the message's timestamp, device location, or other application-specific data User properties provide greater flexibility and control over MQTT messaging.

Learn more in our detailed guide to MQTT User Properties.

5. Subscription Options: Granular Subscription Controls

MQTT 5.0 allows clients to specify how they want to receive messages for each subscribed topic. For instance, clients can now specify whether they want to receive retained messages for a particular subscription, or whether they want to receive messages even if they have the same QoS (Quality of Service) level as the subscription.

Learn more in our detailed guide to MQTT Subscription Options.

6. Request/Response: Allowing Clients to Reply to a Specified Topic

The request/response feature allows a client to specify a topic that the server can use to send a direct reply.

In earlier versions of MQTT, if a client wanted to send a response to a message, it had to publish the response to a topic, and the original sender had to be subscribed to that topic to receive the response. With MQTT 5.0's request/response feature, communication between clients and servers becomes much more efficient and straightforward.

Learn more in our detailed guide to MQTT Request/Response.

7. Shared Subscription: Load-Balancing Function for Subscribers

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, effectively load balancing the messages.

This feature is particularly useful in scenarios where you have multiple instances of a service running, and you want to distribute the workload evenly among them.

Learn more in our detailed guide to MQTT Shared Subscription.

Current Support of Broker and Client SDKs in MQTT 5.0

The MQTT 5.0 protocol has been well received by the IoT community, and numerous MQTT brokers and client Software Development Kits (SDKs) have added support for it. Major MQTT brokers, like EMQX, Mosquitto and NanoMQ, have already implemented MQTT 5.0 features in their platforms, allowing users to leverage the new protocol's benefits.

On the client SDK front, libraries like Paho, which have a broad user base, have added support for MQTT 5.0. This means developers can now utilize MQTT 5.0 features in their IoT applications. Other examples of client SDKs that support MQTT 5.0 are MQTT.js and MQTTnet.

Checklist for Migrating from MQTT 3.1.1 to MQTT 5.0

If you are currently using MQTT 3.1.1, it’s probably time to upgrade to MQTT 5.0. Here are some of the main things you should consider when making the move.

1. Update MQTT Brokers

Once you've evaluated your current infrastructure and decided to go ahead with the migration, the next step is to update your MQTT brokers. This involves installing the latest version of your MQTT broker that supports MQTT 5.0.

Upgrading your broker should be done with care, as it impacts all your MQTT clients. It's advisable to first test the new broker in a non-production environment before rolling it out in production. Also, ensure that your broker's configuration is updated as necessary to support the new features introduced in MQTT 5.0.

Try EMQX Cloud for Free
A fully managed MQTT service for IoT
Get Started →

2. Update Client Libraries

After updating your MQTT brokers, the next step is to update your MQTT client libraries. Just like the broker update, you should perform this update in a non-production environment first. Also, ensure that your application code is updated to handle the new MQTT 5.0 features. Take into account that this might involve some code refactoring.

3. Address Security

While MQTT 5.0 brings several improvements, it also introduces new security considerations. For example, with the new user property feature, clients can now send custom data to the broker. While this is a powerful feature, it can be exploited if not used correctly. Therefore, it's important to assess all the new features from a security perspective.

Some of the steps you can take to address security include using the new enhanced authentication feature for stronger security, limiting the user properties that clients can send to only what's necessary, and continuously monitoring for any suspicious activities.

Learn more in our detailed guide to MQTT security.

4. Monitor after Migration

Finally, after you've migrated to MQTT 5.0 and implemented its features, it's important to continuously monitor your system. Monitoring should not just be limited to technical aspects like message delivery or client connections. You should also monitor the usage of the new MQTT 5.0 features in your applications. This will give you insights into how these features are enhancing your applications and where further improvements can be made.

Embracing MQTT 5.0 with EMQX

As the world's most scalable open source MQTT Broker, EMQX fully supports all features of MQTT 5.0. Devices with any MQTT protocol version can directly access EMQX and communicate with each other.

EMQX has a complete authentication and authorization mechanism and full support for SSL/TLS, which provides secure communication. The SQL-based rule engine with data bridging enables one-stop IoT data extraction, filtering, transformation, storage and processing without writing code.

EMQX also provides high performance, with a single cluster of EMQX 5.0 supporting up to 100 million MQTT concurrent connections. A single EMQX server can reach message throughput of millions per second.

We have built extensive features around our MQTT broker to help you use the protocol more easily, such as the cross-platform MQTT client tool, MQTTX, the ultra-lightweight MQTT Broker for the IoT edge, NanoMQ, and the fully managed MQTT cloud service, EMQX Cloud. All these tools fully support MQTT 5.0.

Learn more about EMQX Enterprise and EMQX Cloud.

Talk to an Expert
Contact Us →

Related Posts