In an earlier post, I shared examples of how organizations can benefit from edge computing – from enabling autonomous vehicles in transportation and preventive maintenance in manufacturing to streamlining compliance for utilities. I also recently shared examples on where the edge really is in edge computing. For operational leaders, edge compute use cases offer compelling business advantages. For IT leaders, such use cases require reliable protocols for enabling processing and transfer of data between applications and a host of IoT sensors and other devices. In this post, I’d like to explore MQ Telemetry Transport (MQTT) and why it has emerged as the best protocol for IoT communications in edge computing.
What is MQTT?
MQTT is the dominant standard used in IoT communications. It allows assets/sensors to publish data, for example, a weather sensor can publish the current temperature, wind metrics, etc. MQTT also defines how consumers can receive that data. For example, an application can listen to the published weather information and take local actions, like starting a watering system.
Why is MQTT ideal for edge computing?
There are three primary reasons for using this lightweight, open-source protocol at the edge. Because of its simplicity, MQTT doesn’t require much processing or battery power from devices. With the ability to use very small message headers, MQTT doesn’t demand much bandwidth, either. MQTT also makes it possible to define different quality of service levels for messages – enabling control over how many times messages are sent and what kind of handshakes are required to complete them.
How does MQTT work?
The core of the MQTT protocol are clients and servers that send many-to-many communications between multiple clients using the following:
- Topics provide a way of categorizing the types of message that may be sent. As one example, if a sensor measures temperature, the topic might be defined as “TEMP” and the sensor sends messages labeled “TEMP.”
- Publishers include the sensors that are configured to send out messages containing data. In the “TEMP” example, the sensor would be considered the publisher.
- In addition to transmitting data, IoT devices can be configured as subscribers that receive data related to pre-defined topics. Devices can subscribe to multiple topics.
- The broker is the server at the center of it all, transmitting published messages to servers or clients that have subscribed to specific topics.
Why choose MQTT over other protocols?
HTTP, Advanced Message Queuing Protocol (AMQP) and Constrained Application Protocol (CoAP) are other potential options at the edge. Although I could write extensively on each, for the purposes of this blog, I would like to share some comparative highlights.
A decade ago, HTTP would have seemed the obvious choice. However, it is not well suited to IoT use cases, which are driven by trigger events or statuses. HTTP would need to poll a device continuously to check for those triggers – an approach that is inefficient and requires extra processing and battery power. With MQTT, the subscribed device merely “listens” for the message without the need for continuous polling.
The choice between AMQP and MQTT boils down to the requirements in a specific environment or implementation. AMQP offers greater scalability and flexibility but is more verbose; while MQTT provides simplicity, AMQP requires multiple steps to publish a message to a node. There are some cases where it will make sense to use AMQP at the edge. Even then, however, MQTT will likely be needed for areas demanding a lightweight, low-footprint option.
Finally, like MQTT, CoAP offers a low footprint. But unlike the many-to-many communication of MQTT, CoAP is a one-to-one protocol. What’s more, it’s best suited to a state transfer model – not the event-based model commonly required for IoT edge compute.
These are among the reasons Cisco has adopted MQTT as the standard protocol for one of our imminent product launches. Stay tuned for more information about the product – and the ways it enables effective computing at the IoT edge.
If you want to learn more about it, I recommend taking a look at our DevNet IoT Sandboxes and Learning Labs. We cover, for example, MQTT in a learning lab here as well.
I also want to thank Naveen Manicka for providing some of the details described above!
And in case you missed it, check out my piece on where the edge is in edge computing.
Great clear, concise explanation, Mirko. Thanks!