Messaging Protocol for IoT (Part-1) – MQTT
In my previous post on Building Blocks of an IoT Product, I discussed about 3 major building blocks – The IoT hardware, Communication Channel and Cloud Service. IoT devices use various communication channel and messaging protocols. While developing an IoT device, the selection of the protocol largely depends on the type, layer and function to be performed by the device. MQTT, XMPP, DDS, AMQP, and CoAP are a few of the widely used communication protocols for the IoT application layer. In this series of post under “Messaging Protocol for IoT”, I will be discussing each and every protocol in detail starting with MQTT.
The usage of a particular protocol is based on the type and nature of the application and its functionality. The two major deciding factor in choosing a protocol is – first, the distance range for the communication of the IoT devices i.e. in inches or meters or miles and second is the power consumption of the communication module and method used.
When it comes to selecting a protocol for the application layer of the IoT system, the most common types of IoT application protocols include, MQTT, CoAP, DDS, AMQP, and XMPP. We use HTTP also, but HTTP is really not meant for IoT devices because of large header size and stateless nature of the protocol.
MQTT (Message Queue Telemetry Transport)
MQTT is a machine-to-machine (M2M) connectivity protocol. It is as an extremely lightweight publish/subscribe messaging transport. It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium. For example, it has been used in sensors communicating to a broker, and in a range of home automation and small device scenarios. It is also ideal for mobile applications because of its small size, low power usage, minimised data packets, and efficient distribution of information to one or many receivers.
MQTT enables resource-constrained IoT devices to send, or publish, information about a given topic to a server that functions as an MQTT message broker. The broker then pushes the information out to those clients that have previously subscribed to the client’s topic. To a human, a topic looks like a hierarchical file path. Clients can subscribe to a specific level of a topic’s hierarchy or use a wild-card character to subscribe to multiple levels.
An MQTT control packet is formed as shown in the figure below.
It should be noted that not all control packets have the variable headers and payload. Each message consists of a fixed header of 2 bytes, an optional variable header, a message payload that is limited to 256 MB of information and a quality of service (QoS) level.
The three different quality of service levels determine how the content is managed by the MQTT protocol. Although higher levels of QoS are more reliable, they have more latency and bandwidth requirements, so subscribing clients can specify the highest QoS level they would like to receive.
The simplest QoS level is unacknowledged service. This QoS level uses a PUBLISH packet sequence; the publisher sends a message to the broker one time and the broker passes the message to subscribers one time. There is no mechanism in place to make sure the message has been received correctly, and the broker does not save the message. This QoS level may also be referred to as at most once, QoS0, or fire and forget.
The second QoS level is acknowledged service. This QoS level uses a PUBLISH/PUBACK packet sequence between the publisher and its broker, as well as between the broker and subscribers. An acknowledgement packet verifies that content has been received and a retry mechanism will send the original content again if an acknowledgement is not received in a timely manner. This may result in the subscriber receiving multiple copies of the same message. This QoS level may also be referred to as at least once or QoS1.
The third QoS level is assured service. This QoS level delivers the message with two pairs of packets. The first pair is called PUBLISH/PUBREC, and the second pair is called PUBREL/PUBCOMP. The two pairs ensure that, regardless of the number of retries, the message will only be delivered once. This QoS level may also be referred to as exactly once or QoS2.
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 using either a standard port or a custom port defined by the broker’s operators. When creating the connection, it is important to recognize that the server might continue an old session if it is provided with a reused 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.
Because the MQTT protocol aims to be a protocol for resource-constrained and IoT devices, SSL/TLS might not always be an option and, in some cases, might not be desired. In such cases, authentication is presented as a clear-text username and password that is sent by the client to the server as part of the CONNECT/CONNACK packet sequence. Some brokers, especially open brokers published on the internet, will accept anonymous clients. In such cases, the username and password are simply left blank.
Despite being lightweight and network constrained and flexibility to choose Quality of Services with the given functionality. MQTT suffers from high power consumption due to the TCP-based connection and lack of encryption and hence considered not very secure. MQTT has minimal authentication features built into the protocol. Username and passwords are sent in clear text and any form of secure use of MQTT must employ SSL/TLS, which, unfortunately, is not a lightweight protocol.
Another negative aspect of MQTT is its lack of interoperability. Because message payloads are binary, with no information as to how they are encoded, problems can arise — especially in open architectures where different applications from different manufacturers are supposed to work seamlessly with each other.
Authenticating clients with client-side certificates is not a simple process, and there’s no way in MQTT, except using proprietary out-of-band means, to control who owns a topic and who can publish information on it. This makes it very easy to inject harmful messages, either will-fully or by mistake, into the network.
Furthermore, there’s no way for the message receiver to know who sent the original message unless that information is contained in the actual message. Security features that have to be implemented on top of MQTT in a proprietary fashion increase the code footprint and make implementations more difficult.
In the next post of this series “Messaging Protocol for IoT”. We will discuss and compare CoAP protocol. Stay tuned.