Tutorial: An overview of MQTT for IoT
01 June 2022
Communication is integral to the IoT – and different applications have unique communication needs, which dictate their networking requirements. Production line equipment in an Industry 4.0 factory, for instance, may need to respond in real-time to commands from a central controller, requiring very low network latencies. Battery-powered remote sensors monitoring soil conditions, on the other hand, may remain in standby mode for large periods of time, waking up only to send short packets of data..
This tutorial was originally featured in EPDT's 2022 IoT & Industry 4.0 supplement in the June 2022 issue of EPDT magazine [read the digital issue]. And sign up to receive your own copy each month.
Applications use a wide spectrum of connectivity, including cellular networks, wireless technologies such as Wi-Fi and Bluetooth, cabled Ethernet, and even satellite. As Eric Heiser, Senior Vice President & Head of Product Center Services at positioning & wireless communication technologies expert, u-blox tells us here, communication protocols are a key element of the IoT (Internet of Things) technology stack of any device, enabling the structured exchange of data between IoT devices, or “things”, and their related applications over the chosen transport media…
Various protocols have been developed to meet the needs of different classes of IoT applications, including CoAP (Constrained Application Protocol), XMPP (Extensible Messaging & Presence Protocol) and DDS (Data Distribution Service). Message Queuing Telemetry Transport, (MQTT) and its derivative, MQTT-SN (MQTT for sensor networks), are among the most widely adopted for the growing category of low-power wide-area networks (LPWANs).
The MQTT protocol
Figure 1. What is MQTT? (source: MQTT Org)
As a lightweight protocol, MQTT’s simple architecture and small code footprint are well-suited to the growing numbers of low-cost, low-power microcontroller devices used in IoT applications. MQTT runs over TCP/IP (Transmission Control Protocol/Internet Protocol), and has been specifically designed for poor quality networks, where latencies can be high. The protocol is ideally suited to applications with the following communication needs:
• Minimal bandwidth use
• Wireless network connectivity
• Low power consumption
• High reliability, if necessary
• Minimal demand on processing and memory resources
MQTT is therefore popular in IoT applications such as smart meters, asset trackers and connected sensors for industrial equipment. Its efficient use of bandwidth makes it ideal for scenarios where network costs are high and power consumption is critical, for example, where remote sensor arrays need to operate autonomously for years in the field without servicing. It is also ideal for mobile applications, because of its small code footprint and its efficiency in distributing information to one or many subscribers.
Functional overview of MQTT
MQTT operates on a ‘publish and subscribe’ basis, as opposed to a client-server model, with two functional entities: the MQTT broker and the MQTT client. Any “thing”, whether device or application, on an IoT network can become an MQTT client. Clients either publish or subscribe to messages, not directly to each other, but to “topics”, which are managed by the MQTT broker. The topics are analogous to email inboxes; a client publishes a message to a topic, and any other client which has 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 QoS levels, (see below). The broker also authenticates all IoT devices on the network, and manages connections, sessions and subscriptions.
MQTT-SN is an optimised version of MQTT, designed specifically for large-scale wireless sensor networks requiring additional 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 enabling these shortened IDs to be programmed into both client and broker.
A keep-alive procedure within MQTT-SN also enables devices to enter sleep mode and retrieve any queued messages when they wake up.
Along with the broker and client entities, the following concepts are core to the operation of MQTT and MQTT-SN:
Figure 2. MQTT topics (source: u-blox)
Topics are fundamental to MQTT’s efficient use of bandwidth and have a multi-level structure (Figure 2). MQTT clients subscribe only to the topics in which they are interested, and can use wildcard entries to access multiple topics.
MQTT topics facilitate efficient organisation of data flows through the IoT network, enabling massive scaling, since devices only receive data from the topics to which they have subscribed.
MQTT clients must establish a connection with the broker to publish or subscribe to messages. The client will provide its ClientID, username and password when sending a CONNECT request, which will be acknowledged by the broker. Connection requests can be qualified with the following parameters:
Clean Session – enables a connect request to also purge any stored messages from the subscriber queue.
Keep Alive – supports battery-operated devices in sleep mode by defining the longest period for a connection to stay active when no messages have been sent by broker or client. Any messages for the client during this period are stored by the broker until the end of the specified time window.
Sleep (MQTT-SN only) – when a device tells the broker that it is entering sleep mode, the broker queues all subscribed messages for the advised period. The main difference between this and the Keep Alive mode is that the broker stores all messages, regardless of QoS level, whereas, in Keep Alive, only QoS 1 and QoS 2 messages are stored. Sleep mode also enables the client to flush its message queue, without needing to wake up.
Figure 3a. Single-level wildcard
SUBSCRIBE requests are used by clients to subscribe to one or multiple topics and can use one of two different wildcard settings, as shown in Figures 3a and 3b.
The single-level (+) wildcard replaces one topic level, and so “sensors/+/out” would subscribe to the following topics:
Figure 3b. Multi-level wildcard
Multi-level (#) wildcards replace multiple topic levels, so this wildcard would subscribe to the following topics:
Table 1. MQTT Quality of Service (QoS) modes
MQTT and MQTT-SN use Quality of Service (QoS) modes to enable the publisher to define the quality of its message. Table 1 summarises these modes and how they can be used according to the constraints of a particular application.
Subscriptions also have an associated QoS setting, which can be used to downgrade the QoS of the published message, with the message always being published at the lower QoS setting.
MQTT is used in applications across multiple sectors, including automotive, oil & gas, manufacturing and telecommunications. The protocol is widely supported within the IoT community and many tools, including brokers and client libraries, are available to help the developer get started.
Figure 4. The u-blox IoT Communication-as-a-Service portfolio
Communication is so much more than connectivity. With the IoT Communication-as-a-Service portfolio from u-blox, for example (Figure 4), getting data from IoT devices anywhere in the world to the enterprise is simplified through the availability of three complementary products: MQTT Anywhere; MQTT Here; and MQTT Now. These products are built on top of the foundation of a scalable, high-performance MQTT broker and powerful Data Flow Manager, allowing simple processing, transformation and integration of messages into the enterprise.
In today’s highly competitive market, shorter development cycles are crucial and, with this platform, u-blox is leveraging the advantages of MQTT to make it simple to communicate data between IoT devices and the enterprise.
Contact Details and Archive...