Message queuing telemetry transport — commonly referred to as MQTT — is a machine-to-machine (M2M) messaging protocol that is extremely well-suited for devices that have low or unreliable network bandwidth. Although it was originally developed in the late 1990s for the oil and gas industry to address equipment in remote locations, MQTT has been an enabling technology for the rise of the Internet of Things (IoT) and the Industrial Internet of Things (IIoT).
Despite the name message queuing telemetry transport, MQTT’s communication method doesn’t involve message queuing.
MQTT is often described as a “lightweight” protocol, meaning that it uses less bandwidth to send messages than other protocols. This low-bandwidth usage is thanks to MQTT’s publish-subscribe, or “pub-sub,” communication method — operating on top of TCP/IP — that minimizes the payload on the network. Here’s how it works:
The MQTT protocol specifies two types of systems: clients and brokers (servers). A client can be a publisher, a subscriber, or both. Brokers manage traffic between publishers and subscribers.
Messages sent by publishers are categorized into hierarchies, or topics, that resemble a file structure. When — and only when — there is new or updated information, the publisher sends a message to the broker, and the broker forwards the message to all the clients who subscribe to that topic — a communication method referred to as “reporting by exception.” Because messages are routed through and managed by the broker — also known as one-to-many communication — MQTT uses significantly less bandwidth than other protocols that rely on a one-to-one communication model.
A client can subscribe to messages at any level of the hierarchy — for example, in the hierarchy “axis3/gripper1/status” the client can subscribe to the main topic, “axis3,” or to either of the subtopics, “status” or “gripper1.” If the client subscribes, for example, to the topic “axis3,” it will receive all messages that fall under the “axis3” topic and all of its subtopics. So if there is a subtopic of “axis3/gripper2,” the client will receive those messages as well as messages that fall under the subtopic “axis3/gripper1.”
MQTT also provides state awareness, so subscribers always know if publishers are online. If a client (subscriber or publisher) sends a disconnect message to the broker, that client can reconnect to the broker at a later time using the same identity. This is sometimes referred to as a “graceful shutdown.”
However, if a publisher disconnects without sending a disconnect message to the broker, a “last will and testament” message will be sent by the broker to that publisher’s subscribers, identifying the disconnected publisher and notifying the subscribers of what to do. Although messages are generally not retained, MQTT allows the broker (if specified in the publisher’s configuration) to retain the last message sent by a publisher, so that new or returning subscribers can ensure their subscription is active and that they receive the latest information.
MQTT allows usernames and passwords to be implemented for clients when establishing connections with brokers — but those usernames and passwords are delivered in clear text. Because MQTT is an application-level protocol that operates on top of TCP/IP, a common solution to ensure data encryption and security in IoT and IIoT applications is to use TLS/SSL.
The MQTT protocol is the standard for all major cloud platforms, including Microsoft Azure, IBM Cloud, and Amazon Web Services. Facebook even uses MQTT for its Facebook Messenger and Instagram apps. For industrial applications, MQTT is especially well-suited for remote monitoring, and its lightweight properties make MQTT one of the most widely used protocols for IoT and IIoT applications.
It’s important to note that for many industrial automation applications, MQTT is implemented with the Sparkplug B software specification, which defines the topic namespace and the payload definition, and describes how state management works and how to use it in SCADA systems.