The future of automation is characterized by terms such as Industry 4.0, IIoT, smart factories and smart devices. At the heart of this new technological era is connectivity—rigid, hierarchical automation pyramids with dividing layers are increasingly being replaced by larger network structures where individual nodes are interconnected and exchange data. For this smart networking, the devices must be IIoT-capable—in other words, standardized, scalable, IT- and OT-capable, and interoperable. In addition, they must be able to communicate securely. Various communication protocols are available for implementing this smart communication, such as MQTT, OPC UA, AMQP, and REST API. In our multi-part series of blog articles, you can find out which properties characterize these IIoT communication protocols and for which applications they are particularly suitable. The first article in the series is about MQTT.

What is MQTT and how does it work?

MQTT (Message Queuing Telemetry Transport) is a compact, binary, open, and easy-to-implement publish/subscribe messaging protocol. It is a certified OASIS and ISO standard (ISO/IEC 20922:2016) managed by the OASIS Technical Committee. MQTT first emerged in 1999 as a technical solution to the problem of bandwidth and battery energy-efficient monitoring of oil pipelines. Fourteen years later, in 2013, IBM submitted MQTT to the OASIS Specification Board, after which it was published as an OASIS standard in 2014. Since then, it has been conquering the industrial market, especially in areas where restrictions such as lean code, minimal overhead, and limited network traffic are high on the agenda. The basic features of MQTT are outlined in the graphic below (Figure 1). The MQTT clients (both publisher and subscriber) connect to the MQTT broker. Some MQTT clients subscribe to a specific topic, in this case the temperature value. As soon as the publishing MQTT client sends data to the broker, the broker remembers that it must send this message to all subscribed MQTT clients. The significant advantage of this type of topology is the decoupling of publishers and subscribers. Instead of making numerous connections between them, the broker is responsible for transporting the data from one end to the other.

Fig.1: How MQTT works—A typical MQTT application

The MQTT specification contains several notable features:

Topic:
A basic element in the MQTT protocol. Each message sent over the network consists of a topic and a payload, in addition to the header information. The topic is the information that the broker can use to filter messages and that subscribers subscribe to. Topics can include several levels, for example “home/sensor1/identification” consists of three topic levels and “home/sensor1/data/temperature” consists of four topic levels. Each topic level is separated by a slash and the topic structure is case-sensitive. Topics can also contain placeholders on one or more levels. The use of a placeholder at a single level is implemented by using the plus sign and could look like this: “home/+/data/temperature”. For this purpose, all temperature values are recorded by all in-house sensors and published on subscribed MQTT clients. The second type of placeholder is the multi-level placeholder that uses the hashtag icon. An example would be “home/sensor1/#”, which transfers all data published by sensor1 to the subscribed MQTT clients.

Quality of service:
Use this function to set the delivery security for each message. The purpose of this function is to define different levels of security to ensure that the message arrives at the subscriber side. These levels are: QoS 0 (at most once), QoS 1 (at least once), and QoS 2 (exactly once). QoS 2 is the highest level of quality and requires most communication confirmations and implementation measures.

Session awareness:
There are several mechanisms in MQTT to ensure that the connection between the broker and the publisher/subscriber remains intact. The most basic mechanism is the keep-alive message. From time to time, the client sends a keep-alive message to confirm to the broker that the connection is still in place. This allows the broker to see if the client has gone offline. In addition, the client provides the broker with a “last will and testament” statement (LWT) during the initial connection process. After the client goes offline, this message is sent by the broker to the other clients on the network to inform them of the client’s absence.

Persistent session:
When a persistent session is established between the broker and a subscriber, the broker stores the messages until the subscriber is ready to receive them. This feature is particularly useful for unstable networks.

Interoperability of MQTT

MQTT is the most compact of all protocols and does not define any levels of standardization. The payload (message) is sent to a specific topic and the incorrect spelling of a topic or the sending of data in a format other than the desired one is not considered an error. Since MQTT 5, metadata can be sent in the headers. However, individual devices are not prevented from having a completely different naming convention and different metadata information. As a result, MQTT is inadequate for machine-to-machine interaction unless all topics and messages are defined by humans. For interaction between man and machine, the human should first investigate to determine which topics are available and how their data is structured before interacting with the machine. The machine cannot determine the topics to which users can subscribe.

Real-time behavior of MQTT

Due to the low overhead, MQTT achieves short transport times. If there is no delay between the publisher and the broker, and the subscriber is connected to the broker and actively listens, the promised “near real-time” and “delay-free” responsiveness can be achieved in theory.

Security of MQTT

MQTT delivers the ability to authenticate with a user name and password during the connection initialization phase. Since MQTT 5, only the password field can be used for a token transfer and additional security mechanisms are required, such as challenge response authentication.

Implementation of MQTT

MQTT is the most compact of all protocols. It requires minimal work on implementation and system resources such as storage space, computing power, and transmission capacity are significantly reduced during the runtime, as compared to all other protocols. Only additional security measures may increase the work involved.

MQTT Applications

MQTT is perfect for example when a simple, compact solution is all that is required. This is the case when data is collected from multiple sensors or the same information is sent to many sensors of the same type at the same time, or when low power consumption and very low memory requirements are needed. MQTT is implemented in various scenarios such as connected automobiles, military applications, industrial equipment networks, drone control, etc.