MQTT also known as MQ Telemetry Transport, was originally called Message Queing Telemetry Transport. It's a message queue class machine-to-machine communication protocol. Invented by Dr. Andy Stanford-Clark of IBM and Arlen Nipper of Eurotech.
Se based on the TCP/IP protocol. In the case of MQTT each connection is kept open and is reused in each communication.
Communication is part of the Internet of Things (IoT), and different applications have their specific communication needs, which determine their network requirements. Production line equipment in an Industry 4.0 factory may need to respond in real time to a command from a central controller, requiring very low network latencies. In addition, battery-powered remote sensors that monitor ground conditions can be idle for long periods of time and wake up only to send short packets of data.
The applications use a wide spectrum of connectivity, including cellular networks, wireless technologies such as Wi-Fi and Bluetooth, wired Ethernet, and even satellite. Communication protocols are a key element of the IoT technology stack of any device, as they enable the structured exchange of data between IoT devices or “things” and their related applications, over the chosen transport medium.
Various protocols have been developed to meet the needs of different classes of IoT applications, including CoAP, XMPP, and DDS. Among them, Message Queuing Telemetry Transport (MQTT) and its derivative MQTT-SN are some of the most widely adopted applications for the growing category of Low Power Long Range (LPWA) networks.
The MQTT protocol
As a lightweight protocol, MQTT's simple architecture and small code design make it ideal for the growing number of low-cost, low-power microcontroller devices used in IoT applications. MQTT runs over the TCP/IP protocol and is specifically designed for low-quality networks where latencies can be high. The protocol is ideal for applications with the following communication needs:
- Minimal Bandwidth Usage
- Wireless network connectivity
- Low energy consumption
- High reliability when needed
- Minimum demand on processing and memory resources
MQTT enjoys great popularity in IoT applications such as smart meters, asset trackers, and connected sensors for industrial equipment. Due to its efficient use of bandwidth, it is ideal for situations with high network costs and critical power consumption, for example, when remote sensor arrays must function autonomously for years without the need for maintenance. It also lends itself very well to mobile applications, due to its reduced code design and its efficiency in distributing information to one or several subscribers.
Functional overview of MQTT
MQTT works on a publish-subscribe basis, as opposed to a client-server model, with two functional entities: the MQTT broker and the MQTT client. Any “thing”, be it a device or an application, on an IoT network can become an MQTT client. Clients publish or subscribe messages, not directly to each other, but to "Topics" managed by the MQTT broker. Topics are similar to email inboxes: a customer posts a message to a topic, and any other customers subscribed to that topic will receive the message.
The MQTT broker is responsible for receiving all published messages and ensuring their delivery to all subscribed clients. Messages are published according to a number of agreed quality of service levels (see below). The broker also authenticates all IoT devices on the network and manages connections, sessions, and subscriptions.
MQTT-SN
MQTT-SN is an optimized version of MQTT, specifically designed for large-scale wireless sensor networks that require higher efficiencies in data transmission and power consumption. MQTT-SN improves data transmission efficiency by shortening the length of topic IDs. Control messaging is also reduced by allowing such shortened IDs to be programmed at both the client and broker.
A maintenance procedure in MQTT-SN also allows devices to go to sleep and retrieve any queued messages when they wake up.
MQTT Concepts
With the broker and client entities, the following concepts are essential for the operation of MQTT and MQTT-SN
MQTT Topics
Topics are fundamental to MQTT's efficient use of bandwidth and a multi-tiered structure, Figure 2. MQTT clients only subscribe to the topics they are interested in and can use wildcard entries to access multiple topics.
MQTT topics facilitate efficient orchestration of data flows across the IoT network, enabling massive scaling as devices only receive data from subscribed topics.
Local
MQTT clients must establish a connection to the broker to publish or subscribe to messages. The client will provide their ClientID, username and password when submitting a CONNECT request, which will be confirmed by the broker. Connection requests can be qualified with the following parameters:
session deletion: allows a connection request to also purge any stored messages from the subscriber queue
active maintenance: Support for battery-powered devices in standby by defining the longest period for a connection to remain active when neither the broker nor the client have sent messages. The broker stores any messages for the client during this period until the end of the specified time.
Idle (MQTT-SN only): When a device tells the broker to go to sleep, the broker queues all subscribed messages for the recommended period. The main difference with Keep-Alive mode is that the broker stores all messages, regardless of the QoS level, while in Keep-Alive, only QoS 1 and QoS 2 messages are stored. Idle mode also allows the client to empty its message queue without the need for activation.
Subscriptions
Clients use SUBSCRIPTION requests to subscribe to one or more topics and can use one of two different wildcard configurations, as shown in Figures 3a and 3b.
The one-level wildcard (+) substitutes one topic level, so "sensors/+/output" would subscribe to the following topics:
- sensors/ground/exit
- sensors/water/outlet
- sensors/light/output
Multi-level wildcards (#) substitute for multiple levels of topics, so this wildcard would subscribe to the following topics:
- sensors/ground/exit
- sensors/ground/input
- sensors/temperature/input
QoS
MQTT and MQTT-SN use Quality of Service (QoS) modes to allow the publisher to define the quality of their message. Table 1 summarizes these modes and how they can be used within the limitations of a given application.
| QoS mode | Description | Features
|
Uses |
| QoS – 1 (activate and forget) | MQTT-SN only
Message is sent but no acknowledgment is received, no MQTT connection required
|
no confirmation
No retries |
· Non-critical messages
Reduce network time for low power devices Reduce messaging costs
|
| QoS0 (one time maximum) | The message is sent, but no confirmation is received
|
best efforts
No retries · No queues for offline customers |
· Non-critical messages
Reduce network time for low power devices Reduce messaging costs
|
| QoS1 (at least once) | Messages are delivered at least once, but duplicate receipt is not prevented | Guaranteed delivery
Retries until confirmation
|
· Critical messages
The receiving client can manage the duplication Messages should be stored for offline clients |
| QoS2 (exactly once) | Duplicates are checked to ensure that the message is delivered only once | Higher overload
4-part joins are used to ensure there are no duplicates
|
· Critical messages
Duplicates can cause problems |
Subscriptions also have associated QoS settings, which can be used to lower the QoS of the published message, and the message is always published with the lowest QoS setting.
Conclusion
MQTT is used in applications across multiple industries, including automotive, oil and gas, industrial, and telecommunications. The protocol enjoys wide support within the IoT community and many tools, including client libraries and brokers, exist to help the developer get started.
In this way, communication is much more than connectivity. For example, the u-blox IoT Communication-as-a-Service catalog (Figure 4) makes it simple for the enterprise to get data from IoT devices anywhere in the world, thanks to the availability of three complementary products: MQTT Anywhere, MQTT Here and MQTT Now. These products are built on the basis of a high-performance, scalable MQTT broker and a powerful data flow manager, making it easy to process, transform, and integrate messages across the enterprise.
In today's competitive marketplace, shortened development cycles are crucial, and with this platform, u-blox takes advantage of MQTT to facilitate data communication between IoT devices and the business.
By Eric Heiser, SVP, Director of Product Center Services at u-blox
