Data created by humans found on the Internet and on computers isn’t always accurate. Typing, scanning, taking pictures, or recording done by humans aren’t always reliable. But what if there are sensors on machines that collect data and are capable of communicating with other machines? What if there’s some kind of protocol that makes medical and personal gadgets, appliances, and other electronics send and receive data from each other?
Such a system would mean people can, for example, accurately track what’s in their inventory. Or what part or item in their shop needs to be replaced, replenished, or repaired. As the sensors in the devices collect the data, it means the data is more accurate and more reliable.
This system was made possible with the arrival of the Fourth Industrial Revolution. It brought with it the Internet of Things (IoT), robotics, artificial intelligence, and other emerging disruptive technologies.
An Overview Of MQTT
Smart TVs, smartwatches, and other ‘smart’ appliances and gadgets that can send and receive messages with each other are now as common as cookies on websites. Collectively, these intelligent devices that can collect data through sensors and send them to other devices are known as the Internet of Things (IoT).
How do devices do this? Their ability to communicate with each other is made possible by a messaging technology called Message Queueing Telemetry Transport (MQTT). It’s an IP-based lightweight messaging system that provides support to IoT. It enables controllers, sensors, and other gadgets or devices to ‘talk’ with each other. Additionally, it supports equipment that isn’t always online, like automated devices equipped with microcontrollers.
The MQTT messaging protocol was created in 1999 by IBM’s Andy Clark and Eurotech’s Arlen Nipper. It started as a proprietary protocol used primarily in the oil and gas industry that later became an open-source protocol. The MQTT is designed to work in low-bandwidth networks. This characteristic is ideal for machine-to-machine communication and IoT devices with a small digital footprint. It works not only in low bandwidth networks but also in high latency environments.
The MQTT is used in various industries, like manufacturing, health, telecommunications, automotive, and others. It’s now recognized as the standard for IoT messaging. This messaging system, working on the publisher/subscriber principle, is operated using an MQTT server. Both the sender and receiver don’t need to be connected directly to one another.
Data from sources are published and received by clients subscribed to receive such data. The publishers and subscribers’ relationship works like this:
- Publisher (data source) transmits data or message on a Topic.
- Client subscribes to a Topic to receive messages.
- The server matches publishers to subscribers.
- The message is discarded if no matches are found.
This arrangement is similar to a radio or TV broadcast—you can only view the transmission from the channel you’re tuned in to. In MQTT, data sources ‘publish’ the data, and recipients get it because they’re registered subscribers.
MQTT Architecture And Data Transmission Protocol
Designed to be a simple publish / subscribe protocol for lightweight devices, MQTT is composed of two primary components: the broker / server and the client.
1. MQTT Broker/Server
The computer running the piece of software that receives messages from data sources or publishers is called the broker or server. The server/broker then sends data from the sources to its correct destination, the subscribers. The software can be installed on a cloud-based broker / server using proprietary or open-source software, an on-site desktop PC, or a Raspberry Pi. But if you’re working with IoT projects that you can control over the Internet, using a cloud-based server is more suitable.
A server can manage MQTT clients of up to thousands connected simultaneously, depending on the implementation. Scalability and integration are, therefore, essential considerations when selecting an MQTT server. A server also has other capabilities besides receiving and sending messages, such as the following:
An MQTT needs to be secured. It should require robust usernames and passwords from its clients. In addition, the transmission control protocol connection should be encrypted with Secure Sockets Layer (SSL) and Transport Layer Security (TLS). These security measures should ensure the message’s security and privacy during transit.
- Quality of Service (QoS) Level
Quality of Service (QoS) Level is an agreement between the source of messages and the intended receiver. This agreement defines a specific message’s guarantee of delivery. There are three levels of QoS in MQ Telemetry Transport:
- At most once (0)
At this level, delivery isn’t guaranteed. What this level guarantees, at most, is ‘best-effort’ delivery. The message is neither stored nor re-sent, and recipients send no acknowledgment of receipt. This Quality of Service level is used when the Internet is reliable and data needs to be quickly delivered.
The message is guaranteed to be delivered to the subscribers at least once. The publisher stores the message until the recipient sends an acknowledgment of receipt. The server also acknowledges the message sent by the publisher, letting the client know that the message was received. The message will be sent again if the client doesn’t receive an acknowledgment.
The acknowledgment tells the subscriber-client that all messages pertaining to the topic to which the client is subscribed had been published. While messages being received are guaranteed at this level, duplicate messages can happen if the acknowledgment of receipt isn’t received on time.
Level 2 is used if the client needs to receive all messages on a subscribed topic. However, many commercial servers don’t support Level 2 because it’s comparatively slow and a resource hog.
Level 2 is the highest Quality of Service level in MQ Telemetry Transport. Each message is guaranteed to be received once by the subscriber. It’s also the safest, albeit slowest, of the three QoS levels. While Level 1 can cause duplication of messages, Level 2 guarantees that data is received only once.
This guarantee is provided by two (at least) ‘request and response’ flows between the publisher and subscriber, which indicates that message is received. Once the subscriber confirms that the message is received, the publisher can discard the data packet. If the publisher fails to receive a ‘message received’ signal from the subscriber, the message will continue to be sent until the message is acknowledged.
High QoS levels are more reliable but involve high bandwidth requirements and higher latency, which can slow down data transmissions. This level is used when quick message delivery isn’t necessary and if duplicate messages can cause issues.
There are two sides to message delivery when it comes to QoS: from the publisher to the server and from the server to the subscriber. The source / publisher of the data or message sets the data’s QoS level every time data is sent to the server. The server then sends the data to the subscriber clients according to the clients’ QoS level, which was set at the start of the subscription process. If the client’s QoS is set lower than the publishing client, the server will send the data with the lower QoS.
This characteristic allows MQTT to provide added messaging qualities of service, ensuring that the data is sent according to the client’s requirements.
Certain MQTT messages can be stored and forwarded to subscribers even when a subscriber- client isn’t available to receive the messages. These messages are called ‘Store and Forward Topics’ to which clients can subscribe. A client subscribed to the Store and Forward feature can receive the stored data when the subscriber becomes available to receive the messages.
For this feature to function efficiently, the MQTT server needs to do the following:
- Track each subscriber’s Client ID
- Track the identifiers of the last message sent successfully to each client.
The MQTT broker automatically deletes expired messages unless configured to retain them. The broker stores configured topics in case future clients subscribe to them. The messages will then be delivered to subscribers in the order that the messages were received originally.
2. MQTT Clients
The MQTT clients can be publishers and subscribers. The labels ‘publisher’ and ‘subscriber’ refer to clients that publish messages or subscribed to receive messages. In MQTT, the publish / subscribe functionalities can be implemented in the same client. Clients can perform different functions like subscribe, unsubscribe, publish, connect, and disconnect at the communication stage.
Moreover, these clients can be any device or app, ranging from a microcomputer to a full-pledged cloud-based broker / server equipped with various bells and whistles. The client can be a compact device with a bare minimum library and limited resources and connects using a wireless network.
Suffice it to say, any device capable of running MQTT through a TCP/IP stack can be a client. The MQTT’s implementation is streamlined and straightforward, traits that make MQTT ideally suited for small devices that use minimal resources.
Conclusion
Message Queuing Telemetry Transport (MQTT) is the technology that makes smart home appliances, smart gadgets, and other Internet of Things (IoT) devices ‘talk’ and share information with other machines or systems. This messaging technology makes your smartphone, refrigerator, wearables, thermostats, remote sensors, and other intelligent gadgets exchange data with each other.
Data flow in MQTT works via a simple publisher / subscriber system with the help of a server / broker. A publisher transmits data on a Topic through the server; the server then transmits data to clients subscribed to that Topic.
Photo 39533964 © Maxkabakov | Dreamstime.com