MQTT stands for MQ Telemetry Transport. It is a publish/subscribe, extremely simple and lightweight messaging protocol, designed for constrained devices and low-bandwidth, high-latency or unreliable networks. The design principles are to minimise network bandwidth and device resource requirements whilst also attempting to ensure reliability and some degree of assurance of delivery. These principles also turn out to make the protocol ideal of the emerging “machine-to-machine” (M2M) or “Internet of Things” world of connected devices, and for mobile applications where bandwidth and battery power are at a premium. The MQTT protocol was developed around 1999. MQTT was invented by Dr Andy Stanford-Clark of IBM, and Arlen Nipper of Arcom (now Eurotech). The main goal of this protocol was to create a protocol very efficient from the bandwidth point of view. Moreover, it is very power-saving protocol. For all these reasons, it is suitable for IoT.
Architecture of MQTT
MQTT working operation and MQTT use cases including message flow. It mentions link to difference between MQTT, REST and HTTP. It is used in IoT wireless technologies such as zigbee, LoRaWAN etc.
As mentioned MQTT is broker based protocol. In this end devices (i.e. clients) communicate via broker. The broker is a server which can be installed on any machine in the cloud. There are different types of brokers such as HiveMQ, Mosquitto etc. The single client and broker can also communicate with each other. As MQTT runs above TCP/IP layer, it is also connection oriented protocol. The client establishes connection with the broker (i.e. server) before the communication. MQTT is a publish-subscribe protocol. Here both client and server publish about any information (i.e. parameter such as temperature, humidity, event (ON/OFF) etc.) to each other using “PUBLISH” message. Any number of clients or end devices can subscribe for event with the broker. Due to this subscription, when there is a change in any event or parameter, broker will intimate to the subscribed clients about the change in event or parameter (i.e. temperature, humidity etc.
How to use MQTT protocol
An MQTT session is divided into four stages: connection, authentication, communication and termination. A client starts by creating a TCP/IP connection to the broker by either using a standard port or a custom port defined by the broker’s operators. When connecting, it is important to recognize that the server might continue an old session if provided with a re-used client identity.The standard ports are 1883 for non-encrypted communication and 8883 for encrypted communication using SSL/TLS. During the SSL/TLS handshake, the client validates the server certificate to authenticate the server. The client may also provide a client certificate to the broker during the handshake which the broker can use to authenticate the client. While not specifically part of the MQTT specification, it has become customary for brokers to support client authentication with SSL/TLS client-side certificates.There are several implementations of MQTT, in this example, we will use Mosquitto, an implementation developed by Eclipse. The first step is installing the MQTT broker. We will install it on Raspberry PI. To install Mosquitto, we have to add the repository that holds the application, so that we can download it. Before adding the repository it is necessary to add the key to verify that the download package is valid
MQTT clients exchange messages via the broker node. The broker is not identical to a typical server, as apart from message reception and delivery, it has little functionality. For additional functionality like logging, message persistence, visualisation, analytics, Web integration, etc, one should consider additional subscribers or develop plugins for the broker.Mosquitto is an Eclipse IOT project, lightweight broker implementation written in C and it supports MQTT protocol versions 3.1 and 3.1.1. For building Mosquitto, install the dependency libcares-devel.You can run the broker using the command mosquitto located in /usr/local/sbin, which is copied from build/src during installation. It runs on TCP Port 1883, by default.
Other open source implementations of the MQTT broker are:
- Emqttd, Vernemq written in Erlang
- Mosca in Nodejs (npm package)
- Surgemq in Go language
- Moquette, Vertx-mqtt-broker in Java
- HBMQTT in Python
Apache ActiveMQ, ApacheApollo and RabitMQ also support the protocol through their plugins.A majority of these brokers target the latest version 3.1.1, but some still support v3.1 (IBM version) for backward compatibility.Many cloud platforms support connectivity through MQTT with certain topic patterns and payloads in plain text or JSON format. A few such platforms are listed below. Apart from hosting brokers, they offer features like dashboards with graph plotting, Web integration and interoperability with other protocols, etc.
- IBM Bluemix IOT App
- AWS IOT
IOT MQTT Quality of Service Levels
Quality of Service (QoS) in MQTT messaging is an agreement between sender and receiver on the guarantee of delivering a message.
MQTT supports three quality of service levels
- Delivered at most once (Fire and forget) which means no confirmation
- Delivered at least once, which means confirmation required
- Delivered exactly once, which means a 4 step handshake is done
The QoS defines how hard the broker/client will work or attempt to ensure that a message is received. Messages can be sent at any QoS level, and clients may attempt to subscribe to topics at any QoS level, which means that the client chooses the maximum QoS level they will receive. For example, if a message is published at QoS 2 and a client is subscribed with QoS 0, the message will be delivered to that client with QoS 0. If a second client is also subscribed to the same topic, but with QoS 2, then it will receive the same message but with QoS 2.
Let’s look at what the three levels mean in more detail.
QoS Level 0 – at most once
This is the simplest, lowest-overhead method of sending a message. The client simply publishes the message, and there is no acknowledgement by the broker.
QoS Level 1 – at least once
This method guarantees that the message will be transferred successfully to the broker.The broker sends an acknowledgement back to the sender, but in the event that that the acknowledgement is lost the sender won’t realise the message has got through, so will send the message again. The client will re-send until it gets the broker’s acknowledgement.This means that sending is guaranteed, although the message may reach the broker more than once.
QoS Level 2 – exactly once
This is the highest level of service, in which there is a sequence of four messages between the sender and the receiver, a kind of handshake to confirm that the main message has been sent and that the acknowledgement has been received. When the handshake has been completed, both sender and receiver are sure that the message was sent exactly once.
MQTT is a plain protocol. All the information exchanged is in plain-text format. In other words, anyone could access to this message and read the payload. Of course, there are several use cases where we want to keep information private and guarantee that it cannot be read or modified during the transmitting process. In this case, there are several approaches we can use to face the MQTT security problem:
- Create a VPN between the clients and the server.
- Use MQTT over SSL/TSL to encrypt and secure the information between the MQTT clients and MQTT broker.
We will focus our attention on how to create an MQTT over SSL. To make MQTT a secure protocol, we have to follow these steps:
- Create a private key (CA Key).
- Generate a certificate using the private key (CA cert).
- Create a certificate for Mosquitto MQTT server with the key.
Advantages to MQTT
Even though MQTT messaging uses an unsecured TCP, we can be able to encrypt data with TLS/SSL Internet security to make it robust, when implementing for the mission critical business. We can have partial and complete encryption based on the resourcefulness of the system and security mandate.
We may be getting billions of devices on the Internet over the next 5 to 10 years. Broker which can act as a server can effectively reduce the number of packets that fall into the internet and also the amount of processing the individual memory needed for the clients. We should be able to build a grid of highly interoperable brokers across different vendors.
Last WILL & Retained Message
Last WILL helps in knowing whether the particular client is available or not. It is not worth waiting for something that won’t happen. The listeners can be put on the power saver mode with interval based wake up to check the publisher availability.
Retained messages will help subscribers receive messages that were published some time before.These messages highly decouple both the publisher and the subscriber to work independent of each device.
Flexible Subscription pattern
A Particular client can subscribe to all the topics published based on a pattern. For example, a smaller monitor for kitchen can listen to all topics on kitchen by subscribing to
Disadvantages to MQTT
- It operates over TCP: TCP was designed for devices that had more memory and processing power than many of the lightweight, power constrained IoT devices have available to them. TCP requires more handshaking to set up communication links before any messages can be exchanged. This increases wake-up and communication times, which affects the long-term battery consumption. TCP connected devices tend to keep sockets open for each other with a persistent session. This adds to power and memory requirements.
- Centralized broker can limit scale: The broker can affect scalability as there is additional overhead for each device connected to it. The network can only grow as large as the local broker hub can support it
If you have any questions on MQTT then please feel free to post your questions on out discussion forum. We will try to help you with best of our knowledge.