A Brief Description of MQTT and it Benefits in IoT - ECE-180D-WS-2023/Knowledge-Base-Wiki GitHub Wiki
Introduction
Word Count: 2,342
IoT (Internet of Things) technology has grown significantly in the past few years with new devices entering the market for many applications. The percentage of businesses using IoT devices increased from 13% to 25% between 2014 and 2019 [1]. According to Fortune Business Insights, by 2029 the IoT market will grow to $2,465.26 billion, an increase of $1,986.9 billion from 2022 [2]. Across a wide array of industries, multitudes of connected devices such as sensors, smartphones, and more are sending data back and forth. Often IoT devices are required to perform reliably in tight places and remote locations where battery and computational power are limited. In addition, many such edge devices are designed to be low-cost in terms of hardware and development costs to undercut their competitors. Finally, some IoT devices carry sensitive data that IoT customers may not want public, while other devices that transmit less sensitive data must prioritize power consumption. As a result, a protocol must be computationally inexpensive, easy to implement, and have optional, low-overhead security features to satisfy the stringent requirements of IoT communication. The MQTT protocol is one such protocol that meets the above specifications and is widely used in the IoT industry.
A Brief Communications Model Background
Before we explain why MQTT is a good protocol, we must understand what makes a network protocol. A network protocol is a set of rules that devices follow during the communication of data and governs things like syntax, formatting, error correction, and more [3]. For two devices to communicate over the internet, there are typically multiple protocols that are used between different layers of the network. These protocols are usually agreed upon by both parties before data is sent.
Source:
networkhope.in
There are different models to abstract communication across a network, but for the sake of MQTT, it can be viewed from the TCP(Transmission Control Protocol)/IP model in which there are 4 Layers in the order of the Application, Transport, Internet, and Network Access/Physical layers. Each layer sends requests for services in the form of control information and messages to be sent to the layer below it. The Network Access(Link)/Physical Layers deal with the physical hardware involved with transmitting data, a series of binary bits called packets, across a single connection. This often involves some form of modulation, where depending on the scheme a certain series of bits is converted into an electromagnetic signal to be sent across a medium. The physical layer only knows the address of the next-hop router along that path to the desired receiving computer. During communications across the network, there are a series of routers between end destinations. These typically only contain this layer and the one above it to shuffle messages along.
The Internet Layer is typically responsible for routing packets along the best path in the network to get to the desired destination. It's the only layer that has an understanding of the large-scale structure of the routers in a network and how to best navigate it. The Transport layer controls and negotiates things such as reliability, error correction/detection between the two entities communicating, as well as converting Application Layer messages into potentially multiple packets to be sent. TCP is one such protocol at this level; specifically, it is a connection-oriented protocol, meaning that a connection between two end users is established before the communication of data. As opposed to the connectionless oriented UDP(User Datagram Protocol), TCP is generally more reliable as packets do not arrive out of order, making it suitable for the unreliable networks MQTT was designed for.
The Application Layer is the highest and closest to the user. It includes applications that connect the user to communication networks and sends a request for transmission to the Transport Layer. Each layer sends requests for services to the layer below it.
What is MQTT?
MQTT is a protocol developed in 1999 by Andy Stanford-Clark and Arlen Nipper to connect sensors on oil pipelines with satellites. They set out to design a protocol that could be used be used to communicate between multiple devices over unreliable satellite internet with limited bandwidth. It was designed to be open-source, easy to implement, and lightweight. As the IoT industry grew, the original design specifications of MQTT made it a perfect option for IoT communications. Eventually, it became an OASIS standard. Note that MQTT, while it used to be an acronym for Message Queuing Telemetry Transport, was changed to simply being called MQTT with no meaning.
Source: segger.com
MQTT is based on a client-server publish/subscribe model in which there are two types of entities, brokers and clients. Under this architecture, clients, which can be any device such as a sensor or computer, connect to a broker using a TCP connection. The broker is a server that handles all messages from all clients connected to it. Clients take two forms, a publisher and a subscriber. A publisher publishes messages to the broker under a given topic. Topics are labels for the given messages and they determine who receives the message. They are typically written in the form “section1/section1.1/section 1.1.1”, where the slashes provide some kind of detail as the structure of the network. A subscriber informs the broker which topics they are subscribed to and receives any messages published on that topic by the broker. A client device can act as both a publisher and a subscriber, allowing for two-way communication via the broker.
With this paradigm, the broker sends messages to all the clients subscribed to the topic, and the publisher does not need to keep track of the addresses of all their subscribers. Thus the publisher does not need to spend as much power to communicate with many entities. Generally, the broker does not hold onto messages, though there are a few situations where it does. When subscribers connect to a broker they can choose to have a session be persistent, meaning that any messages sent to a topic that a client is subscribed to while they are offline can be received once they reconnect, depending on the quality of service(QoS) chosen by the subscriber. In addition, communication with clients is only done when there are new messages to be sent with a given topic. Thus the subscriber does not need to spend much energy asking if a message has been received.
MQTT has three levels of service:
- level 0: at most once
- At QoS level 0, the publisher guarantees to only attempt to send a message to the broker once, regardless of whether or not the message was received.
- level 1: at least once
- At QoS level 1, it is guaranteed that a message sent by a publisher is received by the broker. If the publisher does not receive an acknowledgment, the message will be repeatedly sent until the broker sends one.
- level 2: exactly once
These can simply be specified by one addition integer argument to a publish call. At QoS level 0, the publisher guarantees to only attempt to send a message to the broker once, regardless of whether or not the message was received. At QoS level 1, it is guaranteed that a message sent by a publisher is received by the broker. If the publisher does not receive an acknowledgment, the message will be repeatedly sent until the broker sends one.
The first two QoSs also apply to messages between brokers and subscribers. For example, under QoS 1, the broker will continue to send the message until it receives an acknowledgment from the subscriber. The QoS for messages between brokers and subscribers is determined by the client during the connection. This choice in QoS supersedes any QoS determined by the publisher. This means that a message could have been sent to the broker with a QoS of 1, but only with a QoS of 0 between the broker and the subscriber. Finally, under QOS level 2, messages sent by the publisher are guaranteed to be received by the subscriber-only once. The various levels of service and the ease with which they can be set allow MQTT to work on less reliable networks.
Note that as the QoS increases, the time between sending a message and sending another message increases. This is due to the overhead required for acknowledgment and repeated sending of messages.
There are two final key features in the MQTT protocol, and they have to do with the beginning and end of the communication. MQTT allows publishers to a topic to assign a retained message, which is a message that will get sent to all new subscribers regardless of how long ago the message was sent by the publisher. This supersedes the idea of a persistent session since a retained message will be sent matter whether the client has a persistent session or not. The final feature is called "last will and testament", and it has to do with sudden disconnections from the network. When a publisher client disconnects unexpectedly from the network, they can have the broker send a pre-designated message to all subscribers. This is ideal for unreliable networks because a subscriber can exit safely if another client unexpectedly disconnects.
Why MQTT?
MQTT is a standard for IoT communication because of the principles it was originally designed on and has many benefits. It is lightweight, easy to implement, and easy to understand. The protocol is less taxing on embedded IoT devices that often lack computational power. In fact, MQTT consumes on average 170 times less energy on 3G networks compared to HTTP [12]. Since messages are only sent when a publisher publishes a message (ignoring the specific cases described above), there is no unnecessary communication between clients and brokers. Furthermore, the transport overhead, which is the part of the message that is sent that controls information used by the broker and client to facilitate communication, is only 2 bytes. There are very few bytes spent on overhead. This means the effective bandwidth is higher compared to a protocol with higher overhead. This is ideal for IoT as fewer messages and less overhead means less battery and computational power used. MQTT is also good for IoT systems because of the scalability of the protocol. New devices can be added to an existing network with ease, as long as they are subscribed to the right topics, and devices once again do not need to know the address of all other client devices. Bidirectional communication is easy as well with MQTT, as clients need only need to be subscribed to the correct corresponding topics to communicate with each other. Additionally, MQTT is open source with ready-made implementations in multitudes of languages. This along with publicly available brokers make setting up communication between different devices and applications quickly.
Another great aspect of MQTT is the topic system. The hierarchical structure of
topics allows publishers to publish to a very specific 'topic branch' and
subscribers to subscribe to the higher level and still receive the messages from
the more specific sub-topics. For example, in the case of a smart home with
multiple lightbulbs, each light bulb can publish to a topic
mysmarthome/[ROOM]/lights/[NUMBER] where [ROOM] and [NUMBER] is unique for
each light bulb. If the subscriber wants to know the status of all the lights
in, say, the living room, it would just have to subscribe to
mysmarthome/living_room/lights/+ which will listen to all lights from the
living room. This hierarchical topic system helps ease the burden of the user of
the protocol since they do not need to subscribe to an arbitrary number of
topics without knowing if they exist or not. However, MQTT does support the use
of TSL/SSL for encrypting connections, but it does not protect the application
layer.
Why Not MQTT?
Although MQTT is a powerful, low-power protocol, there are some tradeoffs that have been taken to get the performance. For example, in order to implement the QoS system, MQTT must have a higher latency than other protocols. In addition, all data that a client publishes must first be sent to a broker server before a subscriber can see it, adding to the latency. If one is looking to transmit data with low latency, MQTT is not the correct choice. Another reason to not use MQTT is that it requires a different way of thinking about communication from the standard HTTP's request/response protocol. If there is an existing network in place that uses a request/response protocol format instead of a publisher/subscriber format, it may be worthwhile to evaluate other low-power IoT communication protocols like CoAP. Finally, a major issue with MQTT is that it not is designed with privacy and security in mind. There are ways to build security into and on top of MQTT, such as performing client authentication and providing certificates, but this is rarely done for most projects. In Addition, an MQTT message payload is not encrypted, so it should never be used to transmit sensitive data unless it is certain the device performs encryption before sending a sensitive payload. This, again, was a deliberate tradeoff in the protocol because payload encryption would cause more power draw. Furthermore, in the basic IoT security framework, it was assumed that most edge devices (acting as publishers) would not have sensitive data to transmit. If there is a need for an edge device to send secret info, it should be handled on a device-by-device basis.
Conclusion
As the IoT market continues to grow, the need for low-computation, low-energy communication that can work across unreliable networks is only more prominent. MQTT fills this niche well, as its simple, scalable, and widely available implementations make product development easy. We learned the basics of MQTT, where it sits in the communications pipelines and its key features that make it a prime choice for IoT protocols. Furthermore, we learned the key pros and cons of MQTT. Using this knowledge can help quicken the evaluation and integration of IoT systems with a communication network in future projects. Potential areas of further research like the specifics of how brokers are set up, other IoT communication protocols, and in-depth discussion on security were not covered but can be useful in initializing MQTT for specific projects.
References
[1] McKinsey: Growing Opportunities of The Internet of Things
[3] Cloudflare: What is a Protocol
[4] Integra Sources
[5] Spiceworks
[7] IBM: IOT MQTT Why Good for IOT
[8] IES Solutions
[9] Airtel
[10] https://cedalo.com/blog/http-vs-mqtt-for-iot/
[13] https://blog.paessler.com/a-brief-history-of-mqtt
[14] https://www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt/
[15] https://thenewstack.io/mqtt-protocol-iot/
[16] https://nordicapis.com/the-difference-between-client-server-and-publisher-subscriber/#:~:text=Whereas%20the%20client%2Dserver%20relationship,upon%20a%20set%20of%20circumstances. https://www.u-blox.com/en/blogs/insights/mqtt-beginners-guide
[17] https://www.networxsecurity.org/members-area/glossary/c/communications-protocol.html
[18] https://developer.ibm.com/articles/iot-lp101-connectivity-network-protocols/
[19] https://www.avg.com/en/signal/what-is-tcp-ip#
[20] https://www.geeksforgeeks.org/tcp-ip-model/
[22] https://cedalo.com/blog/understanding-mqtt-qos/
[23] https://assetwolf.com/learn/mqtt-qos-understanding-quality-of-service
[24] https://www.segger.com/products/security-iot/emmqtt/
[25] https://www.concurrency.com/blog/june-2019/introduction-to-mqtt-protocol-for-iot-applications