Introduction to MQTT 5

The MQTT protocol is the most popular and best received Internet of Things protocol in the world today (take a look at the Google trends chart). Since its introduction, MQTT has successfully connected countless numbers of constrained devices in deployments of all sizes.

Popular use cases range from connected cars, manufacturing systems, logistics, and the military to enterprise chat applications, and mobile apps. It’s no surprise that such widespread adoption of the protocol has fueled high demand for further advancement of the MQTT specification. MQTT v5 seeks to meet that demand.

MQTT Essentials

MQTT 5 is the most extensive and feature-rich update to the MQTT specification ever. In our new MQTT 5 Essentials blog-post series, we want to uncover all the hidden gems and useful new features the MQTT 5 specification has to offer. Our goal is to explore the new protocol features with plenty of use-case discussions and background information - individually - one blog post at a time.

TIP: It’s a good idea to read the first MQTT Essentials series before you jump into the new MQTT 5 Essentials. We plan to highlight the key changes and improvements that MQTT 5 introduces. To get the most out of the new series, it’s important to have a basic understanding of the MQTT 3.1.1 protocol.

At the end of this blog post, we have a video on the same topic that complements this blog post. We recommend you to read the blog post and watch the video for further information.

MQTT History

In the late 1990’s, Andy Stanford-Clark (IBM) and Arlen Nipper (Cirrus Link) invented MQTT to monitor oil and gas pipelines over satellite networks. They designed the MQTT protocol to be open, simple, and easy to implement. The result is an extremely lightweight protocol that minimizes network bandwidth and device resource requirements with some assurance of reliable delivery. The design allowed thousands of small devices to be supported from a single server. These characteristics make MQTT ideal for use in constrained environments and low-bandwidth networks that have limited processing capability, low memory capacity, and high latency such as the Internet of Things (IoT).

MQTT Timeline

Although the MQTT protocol was invented in 1999, its rapid rise began years later. Open source combined with open standard made a winning combination and the MQTT community grew quickly. Five years after MQTT 3.1.1 was released as an OASIS and ISO standard, MQTT 5 followed. In March, 2019, MQTT 5 took its place as the newly approved OASIS and ISO standard.

MQTT 5 Design Goals

The OASIS technical committee (TC) that is responsible for specifying and standardizing MQTT faced a complex balancing act:

• Add features that long term users want without increasing overhead or decreasing ease of use.
• Improve performance and scalability without adding unnecessary complexity.

The TC decided on the following functional objectives for the MQTT 5 specification:

• Enhancement for scalability and large scale systems
• Improved error reporting
• Formalize common patterns including capability discovery and request response
• Extensibility mechanisms including user properties
• Performance improvements and support for small clients

Based on these objectives and the needs of existing MQTT deployments, the TC managed to specify several extremely useful new features. Sophisticated MQTT brokers like the HiveMQ Enterprise MQTT Broker already implemented features such as Shared Subscriptions and Time to Live for messages and client sessions in MQTT 3.1.1. With the release of MQTT 5, these popular features became part of the official standard.

A key goal of the new specification is enhancement for scalability and large scale systems. MQTT 3.1.1 proved that MQTT is a uniquely scalable and stateful IoT protocol. (For example, the HiveMQ enterprise MQTT broker achieved benchmarking 10.000.000 MQTT simultaneous connections on cloud infrastructure for a single MQTT broker cluster. The design of MQTT 5 aims to make it even easier for an MQTT broker to scale to immense numbers of concurrently-connected clients. In this series, we’ll examine how the new version handles a broad spectrum of IoT use cases and large-scale deployments of MQTT.

Trivia: What Happened to Four?

You might be curious why the successor to MQTT 3.1.1 is MQTT 5.

The answer is surprisingly simple: The MQTT protocol defines a fixed header in the CONNECT packet. This header contains a single byte value for the protocol version.

If you inspect a few CONNECT packets on the wire, you’ll notice something interesting: MQTT 3.1 has the value "3" as protocol version and MQTT 3.1.1 has the value "4". To synchronize the protocol version value on the wire with the official protocol version name, the new MQTT version gets to use "5" for both the protocol name and value.

Why Five?

If you are still wondering whether MQTT 5 is worth your while, stay with us as we tackle this question. In our next MQTT 5 Essentials post, we’ll establish a clear overview of the foundational changes that MQTT 5 introduces. In part three, we’ll examine the top reasons existing MQTT users have decided to upgrade to MQTT 5.

We hope you enjoyed this first part of our new series. Please use the comments to let us know what you think and what you would like to see in future blog posts.

Learn more about MQTT v5

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

About Mary Brickenstein Hofschen

Mary is a technical writer at HiveMQ. She loves to create clear content for our users.

contact us