MQTT is the de facto protocol of the Internet of Things (IoT). Today, all major IoT platform providers and practically all suppliers of edge computing hardware support MQTT. The lightweight and open MQTT protocol has truly become the most preferred protocol for connecting things to the Internet.

The history of MQTT starts in the late 1990’s when Andy Stanford-Clark and Arlen Nipper invented MQTT to monitor oil and gas pipelines over satellite networks. They needed a protocol that minimized network bandwidth and device resource requirements, was simple to implement, and suitable for unreliable networks. At the time, cloud computing, massive numbers of connected devices, and diverse IoT use cases for MQTT were not a consideration.

In 2013, MQTT was submitted as a standard to the OASIS standard group. The first published release was version 3.1.1. It wasn’t until the end of 2015 that work began on a major update of the MQTT standard, called MQTT 5, to tackle the complexities of the modern computing environment. After much deliberation, MQTT 5 became a standard in March 2019.

MQTT v5 is a significant update of the MQTT protocol. In response to the feedback from MQTT users, MQTT 5 adds the features that modern IoT applications need. These new features are specifically suited for applications that are deployed to the cloud, require robustness and reliable error handling to implement mission-critical messaging, and seek easier integration of MQTT messages into their existing computing infrastructure.

Better Error Handling for More Robust Systems

To create a more robust overall system, MQTT 5 adds a number of new features that improve error checking between the client and broker. A new session and message expiry feature allows you to set a time limit for each message and session. If a message is not delivered within a predefined time period, the message is deleted. For example, let’s say that you send an MQTT message to start a safety-critical machine on your factory floor. If the message does not arrive within a certain time period, you can set the message to be automatically deleted. This ensures that the message is delivered only within the period of time that it is safe to start the machine and is never delivered with a delay due to network latency or outages.

MQTT 5 also introduces the concept of negative acknowledgements. Based on predefined restrictions, the broker can send an acknowledgement to reject particular messages. Restrictions can be based on maximum message size, maximum quality of service (QoS), unsupported features, etc. The ability to reject messages that exceed a preset maximum guards against MQTT clients that might start sending erroneous messages. If a client gets into an unstable state or a malicious client attempts a denial of service attack (DoS), the broker can automatically reject these oversized messages.

More Scalability for Cloud Native Computing

MQTT v5 standardizes the concept of shared subscriptions. (As an aside, HiveMQ has implemented shared subscriptions even before the idea was standardized into MQTT 5.) Shared subscriptions allow multiple MQTT client instances to share the same subscription on the broker. This feature makes it possible to load balance MQTT clients that are deployed on a cloud cluster. This is useful when you use MQTT clients to store and forward MQTT messages into back-end enterprise systems such as a database or Enterprise Service Bus (ESB).

Topic aliases are another useful addition to the MQTT 5 specification. For large systems that have complex topic structures, topic strings can get very long. If you have thousands or millions of devices transmitting billions of messages, a very long topic string creates higher demand on the network. To provide more efficiency and better performance on very large systems, topic aliases let you substitute topic strings with an integer.

Greater Flexibility and Easier Integration

MQTT 5 introduces User Properties that add a key-value property to the message header of an MQTT message. These properties allow you to add application-specific information to each message that can be used in processing the message. For example, add a meta-tag to the header of an MQTT message that includes the unique identifier of the sending client or in the sending client, add the firmware version of the device platform that the receiver can use for analysis and processing.

To make message processing easier for the receiver, Payload format indicators (binary or text), including a MIME style content type, have been added to MQTT v5. These format descriptions are useful for a wide range of use cases. For example, the control system for a toll road might send pictures of license plates that need to be processed by image recognition software while other messages might include location coordinates that require a different style of processing.

The Rise of a Single IoT Standard

The MQTT 5 specification has become the obvious choice for most IoT use cases. The new MQTT 5 features successfully address the limitations of MQTT 3 and open the way for future innovation. Over the next few years, we expect to see a massive growth in MQTT adoption across all industries, including manufacturing, automotive, critical infrastructure, logistics, smart cities, etc. MQTT is on the verge of becoming the standard for all IoT.

HiveMQ and MQTT v5

HiveMQ has been intimately involved in the MQTT 5 standardization process and has already implemented one of the first 100% MQTT 5-compliant brokers and clients. HiveMQ 4 can simultaneously support all MQTT 5, MQTT 3.1, and MQTT 3.1.1 features. HiveMQ customers can deploy a mix of MQTT 3 and MQTT 5 clients to support heterogeneous deployments and migrations to MQTT 5. With HiveMQ 4, you can benefit from all new MQTT features and integrate them into your existing IoT deployments.

Learn more about MQTT 5

Over the next few weeks, we are going to take a technical deep dive into the new MQTT 5 features. In Part 4 of this series we will be talking about Session & Message Expiry Intervals. If you would like to join us, sign up for our newsletter to get regular updates and ensure that you don’t miss a post.

About Ian Skerrett and Florian Raschbichler

Florian serves as the head of the HiveMQ support team with years of first hand experience overcoming challenges in achieving reliable, scalable, and secure IoT messaging for enterprise customers.
Contact Florian

About Ian Skerrett and Florian Raschbichler

Ian was Vice President of Marketing for HiveMQ until September 2022.