What is MQTT?

Behind every smart home application, smart grid system, smart city, IoT-based industrial automation, and other smart systems is a messaging technology that works behind the scenes, making things happen. It enables computers, smartphones, cars, refrigerators, thermostats, wearables, remote sensors, and other smart devices and machines to talk to each other and exchange information. This technology is referred to as  Message Queuing Telemetry Transport (MQTT).

What is MQTT?

MQTT is a lightweight open-source messaging network protocol that transports messages between devices. It employs a publish/subscribe communication model to provide resource-constrained network clients with a simple way to distribute telemetry information in low-bandwidth environments.

MQTT was designed for connections with devices in remote locations where a “small code footprint” is required or the network bandwidth is limited. It is a good choice for wireless networks that experience varying levels of latency due to occasional bandwidth limitations or unreliable connections.

MQTT started as an IBM proprietary protocol used to communicate with SCADA systems in the Oil and Gas industry. It is now an open-source protocol that is overseen by the Organization for the Advancement of Structured Information Standards (OASIS). The MQ in MQTT stands for “Message Queuing”; however, there is no message queuing in MQTT communication anymore. The protocol now provides publish-and-subscribe messaging and has become popular with smart automation systems. Today, MQTT is one of the leading open-source protocols used in fog and edge computing, and for connecting the Internet of Things (IoT). In addition to MQTT, there are other popular messaging protocols that support IoT applications. These include Advanced Message Queuing Protocol (AMQP), Constrained Application Protocol (CoAP), Extensible Messaging and Presence Protocol (XMPP), Data Distribution Service (DDS), ZigBee, and Z-Wave.

In this article, we will take a look at the MQTT protocol and its architecture, how it works and how it’s used in IoT, including some real-world applications.

MQTT architecture and protocol overview

MQTT is a very simple publish/subscribe protocol designed for lightweight machine-to-machine (M2M) communications. The MQTT architecture is made up of the following key parts: MQTT broker and MQTT client.

MQTT broker (server): An MQTT broker or server is software running on a computer that receives messages from external sources–publishers, and then routes them to the appropriate destination-–subscribers. The computer can be a Raspberry Pi, an on-premise desktop PC, or a cloud-based server running open-source or proprietary software. One of the most popular open-source message brokers is the Mosquito broker. You can have your own instance of Mosquito running on your own PC. But rather than using the Mosquito on a local PC, there are readily available cloud-based servers such as Eclipse IoT, ThingMQ, CloudMQTT, and Heroku that implement the Mosquito broker. They’re particularly useful in situations where you want your IoT projects to be controllable over the Internet.

Depending on the implementation, a broker can manage up to thousands of simultaneously connected MQTT clients. Therefore when choosing an MQTT broker, you should consider factors such as scalability and integration. In addition to receiving and routing messages to clients, the broker also delivers other capabilities such as:

• Quality of Service (QoS): The QoS feature allows the MQTT protocol to provide additional messaging qualities of service that ensure that the message in transit is delivered as required by the service.
• Store and Forward: Just as the name implies, MQTT provides support for storing persistent messages on the broker.
• Security: MQTT broker may require username and password authentication from clients to connect for security. To ensure the privacy of messages in transit, the TCP connection may be encrypted with SSL/TLS.

MQTT client (publishers and subscribers): MQTT clients can be any device or application ranging from a simple Arduino microcontroller to a full cloud-hosted application server that runs an MQTT library and connects to an MQTT broker over a network. MQTT clients can be either a publisher, a subscriber, or both. These two functions can be implemented in the same MQTT client.

During the communication phase, a client can perform connect, publish, subscribe, unsubscribe and disconnect operations as the case may be. There are fourteen defined message types used to connect and disconnect a client from a broker, to publish data, to acknowledge receipt of data, and to supervise the connection between client and server. Table 1.0 below is a breakdown of the various message types.

Table 1.0 | MQTT message types and descriptions

MQTT relies mostly on the TCP protocol for data transmission between clients and the broker, which makes the communication reliable. Connection credentials are sent in plain text format. However, SSL/TLS can be used to encrypt and protect data in transit. The default unencrypted MQTT port is 1883, while the encrypted port is 8883.

How MQTT publish-subscribe model works

MQTT’s communication model avoids direct connections between devices by relaying data through a central server called the broker. This is really desirable in IoT because it’s easy to add new devices without touching the existing infrastructure, and since new devices only need to communicate with the broker, they don’t actually need to be compatible with the other clients.

When a device (or client) wants to send data to a server (or broker) it is called a publish. When the operation is reversed, it is called a subscribe. Multiple clients can connect to the broker and subscribe to topics that they are interested in. Clients can also publish messages to specific topics of their interest through the broker. The broker is a common interface for devices to connect to, and exchange, data.

The publish/subscribe messaging model works somewhat like a TV station. A TV station broadcasts a TV program using a specific channel and a viewer tunes into that channel to view the broadcast. There is no direct connection between the broadcast station and the viewer.

Another useful analogy is the post office, where instead of a device sending messages directly to the recipient device(s) as in a peer-peer connection, they are sent to the post office (the broker), and the broker forwards it to everyone that needs that message. The big difference is that MQTT doesn’t use the address of the intended recipient, rather it uses a subject line called the ‘topic”. If anyone wants a copy of that message, all they need do is to subscribe to that topic. And if a broker receives a message on a topic for which there are no current subscribers, the broker discards the message unless the publisher of the message designated the message as a retained message.

You can have as many topics as you want, with each one having different clients on either end. This can be one-to-one, many-to-many, or any combination. The publish/subscribe architecture is very flexible and scalable, making it great for IoT applications.

For example, let’s say you have a setup where a humidity sensor needs to send its readings to the broker. And on the other end, a computer and a mobile device need to receive this humidity value. In order to get the readings across to the receiving devices, the MQTT publish/subscribe data flow process goes through the following steps:

• Firstly, the humidity sensor defines the topic it wants to publish on, in this case, “Humidity”. Then, it publishes the message “humidity value”.
• Secondly, the computer and mobile device at the receiving end subscribes to the topic “Humidity”. This enables them to receive the message that the humidity sensor has published–humidity value.

As stated earlier, the role of the broker here is to take the message “humidity value” and deliver it to the receiving computer and mobile device.

Why HTTP is not suitable for IoT applications

The HTTP (Hypertext Transfer Protocol) is a well-known web standard and one of the primary means of accessing the Internet. Based on its popularity and worldwide acceptability, one would expect that it would be the defacto standard for sending and receiving messages within the IoT network? Unfortunately, that’s not the case. When it comes to the IoT, HTTP tends to perform poorly, mainly because it was not designed to work with networks that have bandwidth limitations or unreliable connections. HTTP was designed to be a heavy-weight protocol for the World Wide Web. It is based on a request/response model which is one of the reasons why it does not fulfill the needs of IoT applications. This request/response model has some serious limitations when it comes to IoT applications, some of which include:

• HTTP is a Synchronization Protocol: The synchronous request/response process of the HTTP protocol places demand on computing resources such as memory, threads, CPU cycles, etc. on both the client and the server-side. Unfortunately, IoT devices have very limited computing resources and will struggle to cope in such an environment. Therefore they cannot work efficiently with an asynchronous protocol such as HTTP. IoT devices perform better with asynchronous protocols like MQTT.
• HTTP is Unidirectional: In HTTP, only one device (client or server) can send a message to the other at any point in time (unidirectional). However, this doesn’t sit well with IoT applications, because it may be required to send data in both directions simultaneously.
• One-to-One Communication: HTTP does not fulfill the need for one-to-many communication between clients and the server. Rather, it is designed for one-to-one communication (one at a time) between the client and the server. While this works fine for requesting resources from the web as a user, it doesn’t fulfill the needs of IoT networks where a large number of IoT devices want to simultaneously transmit data to the server.
• High Power and System Resource Consumption: HTTP connections utilize high system resources, which then leads to heavy power consumption. This puts a lot of pressure on the tiny IoT resources. Unfortunately, IoT applications are unable to put up with those heavy demands.

Table 2.0 | A comparison of  MQTT and HTTP protocol

MQTT real-world applications and use cases

MQTT is one of the most commonly used protocols in IoT and IIoT infrastructure such as process plants, smart homes, digital health, among others, because of its support for devices that require minimal resources and network bandwidth, as well as its ability to connect millions of IoT devices. Some of the popular MQTT-supported platforms designed for the Industrial Internet of Things (IIoT) include ThingWorx, IBM Watson IoT Platform, AWS IoT, Fogwing, Braincube, among others. These platforms provide MQTT extension to enable connectivity for IoT and  IIoT infrastructure.

Notable examples and use cases for MQTT technology in the IoT or IIoT infrastructure include:

• Facebook Messenger: In order to solve problems of limited battery life and internet bandwidth associated with smartphone use, Facebook innovatively deployed MQTT for its messenger and Instagram chats that would enable it to function effectively even with the varying internet connections available across the world. Chats are associated with an MQTT topic, and all members of a chat group subscribe and publish to that topic. A “Topic Director” steers the MQTT chat packets to the different brokers that forward them to the appropriate destination-–subscribers.
• Wearables: MQTT protocol is commonly used to enable low-power IoT wearables. The lightweight nature of the MQTT protocol makes it suitable for wearable devices due to its limited memory and bandwidth capacity. Data is published when it is pushed from the wearable device to the server and the receiving devices subscribe to data pushed to the server. Because the size of the data being sent over MQTT is small by design, messages can be sent quickly, making the hardware very responsive.
• Home Automation: MQTT is used as the underlying communication protocol in most smart home automation systems. For instance, Mark Zuckerberg’s self-built smart home system–Jarvis (modeled after Jarvis from Iron Man) allows him to control his home-by- voice or text from his iPhone. The device can interface with MQTT to enable it to respond to commands by publishing MQTT messages to a broker. This opens up the possibilities for interacting with any device supporting the MQTT protocol.
• Smart Farming: The use of smart technology in the agricultural sector has the potential to increase overall yield and enhance the efficiency of the farming systems by providing continuous monitoring and reporting of the weather and soil conditions such as soil pH, soil temperature and moisture, air temperature, humidity, and sunlight availability.  MQTT protocol and IoT sensors for agriculture enable seamless data collection and availability to cloud servers (broker) even for a challenged Internet connection.
• Smart Metering: In the energy and utility industry, smart meters collect more detail about energy consumption than traditional meters. An MQTT client can be embedded in the software deployed with the meter, which can then be used to transmit (publish) data with guaranteed message delivery to provide accurate meter readings in real-time. Homeowners can also implement MQTT technology in their homes to control energy consumption by household appliances. This helps effectively manage energy consumption and make billing more accurate.
• Remote Sensing: Sensors used in monitoring remote environments are often low-power devices operating in locations with a poor internet connection. MQTT is a suitable protocol for communicating with such devices because of the ability to support IoT sensors with lower-priority data transmission needs.

MQTT FAQs