MQTT: an open network protocol and its importance in the IoT

Remember the name MQTT, since it is a network communication protocol type M2M (Machine to Machine) that is going to sound quite a bit. It is becoming quite popular thanks to the new era of the Internet of Things or IoT (Internet of Things) for its acronym in English. In addition, it is an open protocol, which gives many advantages.

In fact, it has become one of the central pillars of the IoT, as it is quite good on devices with some transmission limitations like these. The acronym MQTT comes from Message Queuing Telemetry Transport, an open standard from OASIS and ISO (ISO / IEC 20922) for network communications and that generally runs on the famous TCP / IP.

Network protocols

The communication protocols They are rules that allow two or more devices or systems to communicate with each other. That is, it is a protocol to transmit information through various means and with a defined format, whether implemented by software and hardware (or both).

El standard of the protocol defines a multitude of communication characteristics. It can go from the rules of synchronization, semantics, syntax, packet format, etc. And the truth is that they are not something negligible, since thanks to these protocols today we can use the Internet and other communication networks ...

And of course, there is not only one protocol, but many. For example, the famous DNS, FTP, MQTT, HTTP and HTTPS, IMAP, LDAP, NTP, DHCP, SSH, Telnet, SNMP, SMTP, etc., for the application layer. While in the transport layer you can find some as famous as TCP, UDP, etc., as well as those of the Internet layer such as IPv4, or IPv6 (the one that has made possible the largest number of available IPs and the arrival of the IoT) , IPSec, etc., and others from the link layer such as DSL, Ethernet, WiFi, ARP, etc.

About IoT protocols

Of course, there are specific communication protocols or that can be applied to the IoT. That is to say, considering the previous section, they would be a series of defined standards so that two or more IoT devices can communicate and understand each other, and they are usually M2M, that is, machine-to-machine communication. there are many IoT devices connected and sharing information from sensors or other sources.

Due to the large number of IoT devices, these protocols must meet requirements beyond the limitations of bandwidth, speed, etc. (note that many devices are embedded and cheap), which is usually in some devices. And I mean the fact that must be scalable, to be able to add more connected devices if necessary and without affecting the global system.

Also, they have to have a low dependency coupling between devices, so that problems are not generated if a device is removed. And of course, at the same time, a high interoperability is sought so that it works with a large number of devices and very varied systems, since the world of IoT is quite heterogeneous.

Other useful features would be the ease of implementing them, safety, etc. Keep in mind that the IoT is creating great challenges in the security aspect. Even more so when many of the connected devices are usually critical in certain cases ... for example, toys for minors.

Important concepts

That said, it must be said that solutions for the IoT use a centralized server to receive the messages from all the connected devices that emit and distribute them to all the connected IoT devices that are listening. That server is what is known as router or broker. Something that is far from the conventional client-server relationship in some ways.

On the other hand, the methodologies that you can find in these communication protocols for IoT are:

• PubSub: Publish / Susbcribe is a messaging pattern where a device (Sub) informs the broker that it wants to receive a message, while another device (Pub) publishes messages for the broker to distribute to the other device / s waiting for them.
• rRPC: Router Remoder Procedure Calls is another pattern of remote process execution. In it, a device (Callee) informs the broker that it will carry out a certain procedure and the broker distributes it to another device (Caller) on which said process is executed.

Now, to carry out these methodologies or patterns, a messaging infrastructure. And in this sense two can be distinguished:

• messagequeue: messaging service where a single message queue is generated for all clients that initiate a subscription to the broker. The latter will keep the messages stored until they are delivered to the client. If the client or recipient is not connected, it is maintained until connected. These types of services are like those used in instant messaging apps such as Telegra, WhatsApp, Messenger, etc.
• message service: it is another service in which the broker sends the messages to the connected recipient client, filtering by the type of message. If the client or receiving device is disconnected, then the messages are lost (although it may have some logging system).

IoT protocols

Having seen the above, now let's take a closer look IoT protocols that are better known. Among the most prominent of M2M are:

• AMQP (Advanced Message Queuing Protocol): is a PubSub type protocol of Message Queue. Designed to have good interoperability and ensure reliability. Special for corporate applications, high performance, high latency networks, critical, etc.
• WAMP (Web Application Messaging Protocol): It is another open protocol of type PubSub like rRPC, and it runs on WebSockets.
• Constrained Application Protocol (CoAP): is a protocol specially designed for low capacity applications.
• TOMP (Streaming Text Oriented Messaging Protocol): very simple protocol and to achieve maximum interoperability. HTTP is used to transmit text messages.
• XMPP (eXtensible Messaging and Presence Protocol): another protocol used in IoT for instant messaging apps and based on XML. Jan this case is also open.
• WMQ (WebSphere Message Queuing): protocol developed by IBM. It is of the Message Queue type, as its name suggests, and is message-oriented.
• MQTT: (see next section)

All about MQTT

El MQTT protocol It is a Message Queue communication protocol, which follows a PubSub pattern, and of the M2M type as I have already commented previously. It is widely used in the IoT, and is based on the TCP / IP stack used on the Internet.

In the case of MQTT, every connection is kept open and it is reused in every necessary communication. Something different from what happens in other known protocols, that each communication takes place requires a new connection.

Advantages

The advantages of the MQTT protocol are quite evident in terms of M2M communications for IoT. In addition to everything said above, it is a protocol that provides:

• Scalability, to connect more and more customers.
• Decoupling between clients, for less dependency.
• Asynchronism.
• Simplicity.
• Lightness so as not to consume too many resources (although with TLS / SSL security it goes up).
• Energy efficient for devices that depend on battery or work 24/7, it does not need a large bandwidth (ideal for slow connections, such as some wireless ones).
• Security and quality, for greater reliability and robustness in communications.

History

MQTT was created in the 90s, with an early version of the protocol in 1999. It was created by Dr. Andy Stanford-Clark of IBM and Arlen Nipper of Cirrus Link (formerly Eurotech).

La initial idea was to create a protocol to monitor a pipeline that traveled through the desert, with an efficient communication protocol (low bandwidth consumption), light, and that a low energy consumption. At the time it was very expensive, but now it has become a cheap and open protocol.

The initial protocol was improved with the appearance of new versions, such as MQTT v3.1 (2013) under the OASIS (Organization for the Advancement of Structured Information Standards) specification, etc. You should know that at the beginning it was a proprietary IBM protocol, but that it would be released in 2010, and it ended up becoming a standard in OASIS ...

How the MQTT connection works

The MQTT protocol uses a filter, for the messages that are sent to each client, based on topics or topics that are organized hierarchically. In this way, a customer can post a message on a specific topic. In this way, all those clients or connected devices that subscribe to the topic will receive messages through the broker.

As is MQ, messages will remain in the queue and they are not lost until the client has received that message.

The connections, as I also indicated, are made via TCP / IP, and the server or broker will keep a record of the connected clients. By default, the devices will use communication ports number 1883, although you may also find a port 8883 if you are using SSL / TLS for added security.

For the connection to be possible, not only clients, servers and ports are needed. Also others packages or messages sent for communication to take place:

• Establish connection: CONNECT message / packet sent by the client with all the necessary information. That information includes the customer ID, username, password, etc. The broker or server responds with a CONNACK packet that will inform the client that the connection was accepted, rejected, etc.
• Send and receive messages: once the connection is established, PUBLISH packages or messages are used with the topic and the payload of the message sent to the broker. On the other hand, the interested client or clients use SUBSCRIBE and UNSUSCRIBE packages to subscribe or withdraw their subscription respectively. The broker will also respond with a SUBACK and UNSUBACK package respectively to report the success of the operation requested by the client.
• Maintaining the connection: to guarantee that the connection remains open, clients can periodically send a PINGREQ packet that will be matched with a PINGRESP packet from the server.
• End connection: when a client disconnects it sends a DISCONNECT packet to report that event.

Those messages or packages The ones I have talked about have the same structure as other packets of other network protocols:

• Header or fixed header: is a fixed part that occupies between 2-5 bytes. It contains a control code, ID of the type of message sent, and its length. Between 1-4 bytes are used to encode the length, using the first 7 bits of each octet as data for the length and an additional bit of continuity to determine that there is more than one byte that makes up the length of the message.
• Variable header: is not always mandatory, but optional. It is only contained in some packages in certain situations or specific messages.
• Content or data: the packet data is what actually contains the message to be sent. It can be from a few kB up to a 256 MB limit.

If you are interested in knowing the corresponding code in hexadecimal for the types of messages sent are:

Quality and security of communications

Another important detail of the messages by MQTT is the quality of service or QoS, and security. The robustness of the communication system in the event of failures and its safety will depend on this.

Regarding its quality, it can be determined 3 different levels:

• QoS 0 (unacknowledged)- The message is only sent once, and in case of failure it would not be delivered. It is used when it is not critical.
• QoS 1 (acknowledgment): the message will be sent as many times as needed to guarantee delivery to the customer. The downside is that the client could receive the same message several times.
• QoS 2 (assured)- Similar to above, but guaranteed to be delivered only once. It is often used for more critical systems where greater reliability is needed.

On the other hand, as for MQTT security, various measures can be used to ensure its strength in this regard. As I have already commented before, the authentication of the user and password, like many other protocols, can be ensured by means of SSL / TLS. Although many IoT devices with low capacities, or resources, could have problems with the overload of work when using this type of secure communication ...

For this reason, many IoT devices that use MQTT use passwords and users in plane text, which could make someone sniffing network traffic to get them very easily. And if that is not enough, the broker can also be configured to accept anonymous connections, which would allow any user to establish communications, involving greater risk.

Using MQTT with Arduino

Of course, you can use the MQTT protocol with Arduino and other development boards, as well as the Rapsberry Pi, etc. To do this, you must provide your Arduino board with connectivity, if it does not have it. Also, the library Arduino Client for MQTT it will help you in these tasks. This library is compatible with:

• ArduinoYUN
• Arduino Wi-Fi (shield)
• Arduino Ethernet (shield)
• ESP8266 module
• Intel Galileo / Edison
• Raspberry Pi
• ...

As soon as to the code to use MQTT in some application, the truth is that it is simple. In the Fritzing image you can see a plaque Arduino UNO to which connectivity by Arduino Ethernet has been added and it has also been connected a DHT22 humidity and temperature sensor, although it could have been anything else ...

Ok, with that said, for the code you have to generate in Arduino IDE To work with the MQTT protocol on Arduino, it's that simple:

• For send messages MQTT

#include <SPI.h>
#include <Ethernet.h>
#include <PubSubClient.h>
#include <DHT.h>

#define DHTPIN 2
#define DHTTYPE DHT22

// Direccion MAC del adaptador Ethernet
byte mac[] = { 0xCE, 0xAB, 0x0E, 0x3F, 0xFE, 0xD4 };

// IP del servidor (broker)
IPAddress mqtt_server(192, 168, 1, 4);

// Topic o tema con el que se trabaja
const char* topicName = "test";

DHT dht(DHTPIN, DHTTYPE);
EthernetClient ethClient;
PubSubClient client(ethClient);

void setup()
{
  Serial.begin(9600);
  if (Ethernet.begin(mac) == 0) {
    Serial.println("Fallo en Ethernet usando DHCP");
  }
// Puerto 1883 de comunicación
  client.setServer(mqtt_server, 1883);
  dht.begin();
}

void loop()
{
  if (!client.connected()) {
    Serial.print("Conectando ...\n");
    client.connect("Cliente Arduino");
  }
  else {
    // Envío de informacion del sensor de temperatura y humedad
    float temp = dht.readTemperature();
    char buffer[10];
    dtostrf(temp,0, 0, buffer);
    client.publish(topicName, buffer);
  }
  // Tiempo entre envíos en ms (cada 10 segundos)
  delay(10000);
}

• For receive messages by MQTT you only need the plate Arduino UNO and connection, with Arduino Ethernet or any other element. As for the code, an example would be:

#include <SPI.h>
#include <Ethernet.h>
#include <PubSubClient.h>

// Direccion MAC del adaptador Ethernet
byte mac[] = { 0xCE, 0xAB, 0x0E, 0x3F, 0xFE, 0xD4 };

// IP del servidor (broker)
IPAddress mqtt_server(192, 168, 1, 4);

// Topic o tema con el que trabajr
const char* topicName = "test";

EthernetClient ethClient;
PubSubClient client(ethClient);

void callback(char* topic, byte* payload, unsigned int length) {
  Serial.print("El mensaje ha llegado [");
  Serial.print(topic);
  Serial.print("] ");
  int i=0;
  for (i=0;i<length;i++) {
    Serial.print((char)payload[i]);
  }
  Serial.println();
}

void setup()
{
  Serial.begin(9600);
  if (Ethernet.begin(mac) == 0) {
    Serial.println("Fallo en Ethernet al usar configuración DHCP");
  }
  client.setServer(mqtt_server, 1883);
  client.setCallback(callback)
}

void loop()
{
  if (!client.connected()) {
      Serial.print("Conectando ...");
      if (client.connect("rece_arduino")) {
        Serial.println("conectado");
        client.subscribe(topicName);
      } else {
        delay(10000);
      }
  }
  // Cliente a la escucha
  client.loop();
}

For more information, you can download for free of our PDF manual with the Arduino IDE course to start programming.