Using MQTT for Integrating IoT Telemetry Data

As many companies in industries such as manufacturing, oil & gas, energy & utilities, and transportation & logistics implement “smart” network-aware devices, the desire to remotely monitor and manage these devices has grown. There is immense business value in the enhanced control, awareness, and automation these Internet of Things (IoT) solutions offer.

However, navigating the continuous communications of these devices across unreliable networks in a way that performs and scales efficiently presents a big challenge. Over the last few years, Message Queuing Telemetry Transport (MQTT) has emerged as the leading standard for IoT communications. Created at IBM over twenty years ago, it was officially submitted to OASIS as a standard around 2013. Since then, it has risen to be the leading messaging protocol for IoT solutions due to several benefits:

• A strong, asynchronous publish/subscribe capability that works over unreliable network connections.
• An extremely lightweight message structure (minimum packet header of only 2 bytes).
• Multiple Quality of Service (QoS) options for maintaining communication integrity.

Given these benefits, let’s look at how MQTT works and where it fits into a typical IoT solution.

Components of MQTT

In Figure 1, you can see a high-level view of a typical industrial IoT solution.

Figure 1 – Typical Industrial IoT Architecture

Starting from the left, you can see the edge location where one or more devices are in operation. In our diagram we have a separate Programmable Logic controller (PLC) for controlling the devices and acting as the point of contact for the central IoT solution. Many devices are emerging with these PLC capabilities built in, eliminating the need for a separate controller. But for our discussion, let’s consider them separate. This PLC communicates where data is processed to the central IoT solution; this communication is where MQTT fits in.

(There are more advanced IoT architectures where data processing happens on the edge, but for this discussion we’ll keep things as simple as possible.)

Once data is transmitted to the cloud platform, the streams can be processed, aggregated, and stored for use by user applications, as well as analyzed by A.I. and Machine Learning platforms to drive automation. (We’ll cover those components in a separate article.)

Now let’s look at specific aspects of MQTT and see how they fit within our example architecture.

MQTT Broker
The broker acts similar to a standard messaging broker you’d find in other publish/subscribe models. It is responsible for managing client connectivity, security (authentication and authorization), topics, and message receipt/delivery for thousands (or even millions) of client connections.

In our architecture, the MQTT broker plays the part of the Cloud Gateway. It takes the data from the edge locations and streams it into the data processing component.

MQTT Client
The client is the individual endpoint in the architecture. In our example, it’s the edge PLC device. This device connects to the MQTT broker (“Gateway”) using whatever security is required. Often this connection is secured via specific credentials and runs over TLS for network data encryption. The broker then controls the permissions for each connected client–limiting which topics it can subscribe and/or publish to.

Last Will & Testament (LWT)
This is a message the client provides the broker upon connection. It provides information to subscribers in the event the client becomes unexpectedly disconnected from the broker.

Quality of Service (QoS)
MQTT supports multiple QoS options within the standard:

• QoS 0 – Single delivery at most (“fire and forget”). This is used for situations where it’s OK to lose messages. It’s the most lightweight approach and maximizes data transmission.
• QoS 1 – At least once delivery. Use this when each message must be received but you’re not concerned about duplicate messages. This requires a response from the broker to client to acknowledge receipt of the message and therefore slows the data transmission rate.
• QoS 2 – Exactly Once delivery. Use this when each message much be delivered once and only once (no duplicates). This is the heaviest of the QoS options and can have significant impact on data transmission.

MQTT Support in IoT Platforms

There are many options when choosing platforms that support the MQTT standard. On the edge, many smart devices and PLCs are capable of communicating via MQTT. However, the standard has evolved and not every device or PLC will have full support of all MQTT capabilities. (For example, some PLCs might not support QoS 2.) Also, there are multiple versions of MQTT in use so it’s important to look closely at any vendor’s specific MQTT support. The most current version is v5, however, typically any support level over v3.11 will be compatible.

On the cloud side, all leading IoT platforms (e.g., Azure IoT Hub, AWS IoT Core) support MQTT. However, although they support the MQTT protocol, they are not full-featured MQTT brokers. Often, they lack the specific requirements around QoS and LWT capabilities. In many cases this does not prevent the use of these platforms in an IoT solution using MQTT. If you feel your solution needs those broker capabilities, alternative platforms are available—both open source (e.g., Mosquitto) and vendor licensed (e.g., Hive MQ). Additionally, many messaging platforms, such as Confluent Kafka and Rabbit MQ, have MQTT extensions that may be added to facilitate use of the standard.

If you’re considering designing an IoT solution but are unsure which platforms and standards (such as MQTT) best fit your needs, Anexinet is here to help. Please feel free to reach out to us at any time. We’ve architected and implemented countless IoT solutions for clients and can help you design the ideal solution for you and your company.