What is MQTT?

Eric Olson | July 23, 2019

Message Queuing Telemetry Transport (MQTT) is a lightweight messaging protocol for the efficient transfer of telemetry data. MQTT was designed to reliably transport messages while minimizing the size of data packets, the footprint of software code and data transmission power consumption. Although it can operate in near-real-time, MQTT also functions over networks with high latency and low bandwidth. These qualities make the protocol ideal for machine-to-machine (M2M) and industrial internet of things (IIoT) applications.

[Read about how an IIoT system uses MQTT to enable remote monitoring of factory processes.]

MQTT was invented in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom Control Systems). A royalty-free version was released by IBM in 2010, and in 2013 a technical committee at the Organization for the Advancement of Structured Information Standards (OASIS) was formed to cultivate MQTT as an open, standard protocol. MQTT v3.1.1 is described in the ISO/IEC 20922:2016 standard.

The MQTT messaging transport protocol is based on a client/server, publish/subscribe model that transmits data over Transmission Control Protocol/Internet Protocol (TCP/IP), the set of protocols that enables communications over the internet.

Publish/subscribe model

MQTT clients consist of publishing clients (e.g., programmable logic controllers) as sources of data and subscribing clients (e.g., mobile devices) as receivers of data. A broker (i.e., server) acts as an intermediary, managing the flow of data, receiving messages from publishers and sending messages to subscribers.

[Search Programmable Logic Controllers (PLCs) by specification on Engineering360.]

The publisher/subscriber model decouples publishers from subscribers. Under the publish/subscribe model, publishers do not need to have knowledge of subscribers, nor do subscribers need to have knowledge of publishers. Publishers and subscribers need only know the IP address of the broker.

Publishers send messages assigned to topics to the broker, while subscribers sign up for the topics they are interested in. The broker sends messages to subscribers based on a filter that excludes data assigned to topics not included in subscriptions. MQTT allows publishers and subscribers to send and receive messages asynchronously; their operations do not have to run concurrently.

The MQTT messaging protocol consists of a publish/subscribe model with a broker in the middle. In this case, the broker is HiveMQ. But the broker could also be part of a cloud service like Amazon’s AWS IoT or Microsoft Azure IoT Hub. Source: HiveMQ

When a client connects to a broker, the session can be either persistent or clean. Persistent sessions save information about a session (e.g., topic subscriptions) between client disconnects and reconnects. Clean sessions, on the other hand, wipe this information between connections, requiring, for example, that the client resubscribes to topics every time it connects to the broker following connection interruptions.

MQTT topics

MQTT topics are arranged as hierarchically structured strings, using forward slashes as delimiters. For instance, a typical IIoT topic might contain the following elements.

For example, data sent from pressure sensor 1 on valve 2 in fluid dispenser 3 within manufacturing cell 7 in factory building 2 would be assigned the following topic string.

building2/cell7/dispenser3/valve2/pressure1

Subscribers can subscribe to multiple topics at once using wildcards. For example, to receive all messages from all sensors in all machine elements in every piece of equipment in manufacturing cell 7 in building 2, a subscriber would sign up for:

building2/cell7/#

Quality of service

MQTT contains a quality of service (QoS) feature that allows publishers and subscribers to agree on a level of guarantee for message delivery. There are three levels of QoS available in the protocol:

QoS 0: Messages are received once, at most, with no guarantee of delivery. The sender transmits a message once and does not re-transmit.
QoS 1: Messages are received at least once, with guaranteed delivery. The sender transmits a message once and continues to re-transmit until it receives an acknowledgment of message receipt from the receiver.
QoS 2: Messages are received exactly once, with guaranteed delivery. A four-part handshake occurs between the sender and receiver to guarantee and confirm delivery of a message. This is the safest and slowest method.