What is MQTT?
The Internet of Things (IoT) and it’s corresponding energy and manufacturing sector equivalent, the Industrial Internet of Things (IIoT), are two common buzzwords often heard in engineering and technology. These relatively new paradigms elegantly propose a web of interconnected devices that can communicate real time data from device to device and their human counterparts. However, the details and complexities of implementing such a network of devices are often overlooked. The obscured “how” lies heavily in the underlying glue of the communication protocol.
One of the primary protocols that has gained widespread adoption is MQTT or MQ Telemetry Transport. The protocol was originally developed in 1999 as a solution for obtaining data from remote oil pipelines via satellite network. These remote locations were harsh environments for traditional networks offering low bandwidth and high latency. Furthermore, the simple hardware deployed at these “edge of network” locations lacked large computational and storage capabilities. The solution was MQTT due to it’s simplicity, robustness, and low overhead requirements.
MQTT relies on a scalable publish/subscribe architecture centralized around an MQTT broker. The broker is also referred to as a centralized server or IoT hub that receives or publishes messages from numerous MQTT clients or agents. The term “client” can be somewhat confusing in that MQTT clients can be both edge devices publishing data and traditional devices subscribing to view that published data. In other words, a client can be both a remote PLC connected to a sensor and an application launched on a desktop used to view that sensor’s value.
The simplicity of MQTT is further complimented in the form of the messages between clients and the broker. Messages have a topic and a payload, which can be both published and subscribed to by the clients. Topics are usually hierarchal categories (i.e. Texas/Region_1/Pipeline_1) that provide context to the data contained in the payload. The payload can be of numerous formats, but one of the more ubiquitous is JSON (JavaScript Object Notation).
The messages may be accompanied by a quality of service level (QoS). This simply describes the confirmation of messages sent from a client to the broker or from the broker to a client. The levels are below:
- QoS 0: At most once delivery — Message is fired once and forgotten, no confirmation. Thus, there is potential that the message may not get to the destination.
- QoS 1: At least once delivery — Message is fired, and until a confirmation is received, may continue to fire to the destination. Thus, duplicate messages may be sent.
- QoS 2: Exactly one delivery — No message loss or duplication at destination.
MQTT is also a secure protocol. The topic of security can be overwhelming due to the complexity. Therefore, the focus will be strictly on the solutions indicated by the OASIS documentation for the MQTT protocol. Security can be boiled down into three main categories:
- Authentication — Clients have the option to be identified with a username and password in order to connect to the broker.
- Authorization — The broker can restrict topics that certain clients can publish or subscribe to. A “need to know” basis if you will, preventing any one client from accessing all topics facilitated by the broker.
- Integrity & Privacy — The protocol recommends TLS encryption if supported and the use of a virtual private network (VPN)
Depending on the broker you choose, you may see either port 8883 or 1883 specified. The difference is that port 8883 is the default port for TLS encryption, whereas 1883 is not encrypted.
Although MQTT is not a relatively new technology having been founded in the late 90’s, it is certainly contributing to further innovations in the IoT sector.
Please follow me if you found this content informative. It will support my ability to provide continued quality content.
