The growing spread of devices capable of acquiring data and connecting to the network for sharing and receiving information with/from other connected devices, led in recent years to a dramatic increase in the number of IoT (Internet of Things) applications. The connectivity applied to disparate types of objects, combined with their ability to collect large amounts of data to be analyzed and used in a wide range of both industrial and domestic applications, can be considered one of the greatest technological revolutions of our times.
As a natural consequence, the need to develop new technological solutions able to efficiently exploit these potentials, by taking into account the limitations and the physical constraints imposed by the characteristics of the objects themselves, was quickly revealed. Connected objects are represented, in most cases, by embedded devices, sensors, actuators and mobile devices, including smartphones and tablets.
In this context, the MQTT protocol (MQ Telemetry Transport protocol) has emerged as one of the most widespread communication protocols for IoT and M2M (Machine-2-Machine) applications.
Strengths of the MQTT protocol
The success and the resulting pervasive adoption of the MQTT protocol in the IoT / M2M field, is linked to the ease of use and a combination of other important functional and non-functional features.
MQTT is a lightweight communication protocol. It uses TCP as the underlying transport layer and an efficient binary encoding for messages serialization. The size of the fixed part of the MQTT message header is just 2 bytes, resulting in a very low overhead which makes it ideal for exchanging large amounts of data in small packages on poorly performing networks.
MQTT is agnostic with respect to the type and format of the exchanged data and is designed primarily for almost real-time communications between heterogeneous, often battery powered devices with limited computational capabilities, on high-latency networks and in application scenarios where the available bandwidth is often limited or expensive. The latter is the case, for example, of most tariff plans applied to M2M applications, where the cost per quantity of data transferred stays, to date, quite relevant.
An event-oriented communication model
The MQTT protocol uses a Publish / Subscribe, event-oriented communication pattern. In contrast to the Request / Response pattern on which the HTTP protocol is based, which resulted in its great success for the development of the Internet and internet related applications, the Publish / Subscribe pattern does not require clients to poll the server to check for new or updated information.
In a typical MQTT application the data sources, called publishers, publish messages on a specific topic towards a central entity, the Message Broker. All recipients interested in the consumption of certain types of data, called subscribers, subscribe to the topics of interest once again using the Message Broker. Whenever new data is made available on a given topic, the Message Broker take care of the “one-to-many” distribution to all subscribers, in push mode. The Publish / Subscribe communication pattern is therefore particularly suitable for event-oriented or event-driven applications: data collected and immediately shared by the publisher, is transferred in almost real-time to all subscribers, who are waiting to be “woken up” in case of events they are interested in. In the specific case, events may be the availability of new data, as well as a command dispatched to an actuator to order the execution of specific actions.
Thanks to the use of the Message Broker as a centralized distribution entity, the MQTT protocol guarantees a complete decoupling between those devices who publish and those who consume information, supporting both “always-connected” and “sometimes-connected” use cases. The latter being represented by a scenario where clients can disconnect and reconnect continuously due to the unreliability of the underlying network.
A typical example of an architectural “ecosystem” in which the MQTT protocol fits very well, is shown in the picture below:
Quality of Service
Another interesting, technologically relevant aspect offered by MQTT, is the possibility of using three different QoS (Quality of Service) levels, which publishers and subscribers can negotiate through the Broker during the connection phase, depending on the specific application needs:
- At most once, provides the lowest quality of service level. The message is sent only once without any acknowledgement, therefore relying on what the underlying TCP / IP network can offer at a given time (best-effort)
- At least once, the message is sent several times until a receipt confirmation is received back. This QoS level does not exclude the possibility that the message can be received more than once by some recipients, due to the retransmissions
- Exactly once, the message is sent once and only once with confirmation of receipt.
Security
Although security has not been considered “by design” in the MQTT protocol specification, it is possible to include authentication mechanisms, by carrying usernames and passwords within the transmitted messages. Security may also be added by leveraging other mechanisms, such as communication encryption through the simultaneous use of TLS (Transport Layer Security) connections, or through the use of upstream and downstream encryption.
Applications
The Publish / Subscribe communication pattern and the adoption of a data agnostic, binary serialization of the message payload, makes MQTT suitable for practically all event-oriented applications, with the IoT / M2M representing a specific, yet tremendously significant, field of application.
MQTT is already widely used in various types of embedded devices, sensors and actuators, for the acquisition and sharing of positioning data (devices tracking), for environmental monitoring, in the industrial sector and in SCADA (Supervisory Control and Data Acquisition) environments for the purpose of measurements’ acquisition, implementation of commands for actuators and critical infrastructures monitoring. And, not least, for home automation scenarios.
The standardization process
Developed in 1999 by IBM for internal needs, MQTT was released under an open source and royalty-free license in 2010. Subsequently, it was first adopted by the OASIS (Organization for the Advancement of Structured Information Standards) which released the version 3.1.1 specifications as an OASIS standard and, in turn, approved by the technical committees of ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission), under the name of ISO / IEC 20922. In April 2019, version 5.0 of the MQTT standard was released by OASIS.
MQTT in the IES portfolio
- tracking of assets, resources and vehicles
- environmental monitoring and analysis through reception of data from sensors
- dispatching of alarms, early warnings and commands to command and control systems, mobile apps, alerting devices and actuators