¿QUÉ ES MQTT?

Uno de esos protocolos que están estrechamente ligados a Internet de las Cosas y que resuena con fuerza casi en cada artículo, conferencia o nueva aplicación que sale sobre este mundillo es el protocolo MQTT.

De forma rápida y resumida, MQTT (ojo, oficialmente ya no tiene acrónimo pero sus orígenes parten de MQ Telemetry Transport) es un protocolo simple y muy ligero para la transmisión de mensajes cortos de telemetría y de control,  desde/hacía una red de sensores/actuadores, que tenga limitaciones evidentes en cuanto al consumo, velocidad de transmisión y procesamiento.

No es una invención de IBM, pero sí fue esta empresa la que ha contribuido en su impulso definitivo, sacando en 2010 la versión 3.1 open source. Desde 2014, existe un estándar MQTT a cargo del organismo OASIS. La versión más actual es 3.1.1 que supone pequeños cambios a la anterior y es sobre la que voy a hablar en esta serie de publicaciones.

¿Dónde se sitúa el protocolo MQTT dentro del modelo OSI?

El protocolo MQTT se localiza en las capas superiores de OSI, y normalmente se apoya en TCP/IP. Esto significa que los participantes de una aplicación MQTT deben tener una pila TCP/IP.

¿Qué aporta este protocolo a Internet de las Cosas?

El protocolo MQTT presenta una serie de características que lo hacen especialmente atractivo para el mundo Internet de las Cosas:

• Es open source, con lo cual es fácilmente integrable al variopinto universo de tecnologías, protocolos y aplicaciones de Internet de las Cosas.
• Puesto que se basa en la publicación-subscripción de mensajes, no se necesita saber para quien van los mensajes o de donde vienen, reduciendo mucho la complejidad de la red.
• Gracias al punto anterior, es un protocolo ligero (cabeceras muy reducidas, comunicación bajo demanda, etc), con lo que se ajusta a redes y dispositivos con pocos recursos y baja velocidad de transmisión, como una típica red de sensores.
• Se basa en comandos muy sencillos y varios modos de gestión de mensajes, y además, no necesita que el contenido del mensaje esté en un formato específico.
• Tiene mecanismos para garantizar una comunicación fiable, retransmitiendo o guardando para más tarde los mensajes cuando se pierda la conexión entre servidor y cliente. Para esto implementa hasta tres niveles de QoS, lo que permite garantizar la entrega de los mensajes más importantes.
• Permite unir fácilmente el mundo del Business Intelligence y el Big Data con las fuentes de datos, pero también es ideal para la conexión machine-to-machine (M2M).

Al grano, ¿cómo funciona esto?

La característica principal del protocolo MQTT es que está basado en el modelo de comunicación productor – consumidor.

Es decir, su estrategia de comunicación se basa en la publicación de mensajes de tipos específicos (topics) y la subscripción a esos mensajes. Los mensajes que se publican en la red se clasifican según diferentes tipos y los clientes MQTT (nodos) reciben sólo aquellos tipos a los que están subscritos. Del mismo modo, los nodos pueden también publicar mensajes de los tipos que manejan y comunicarse así con otros nodos o aplicaciones que gestionan esos mensajes.

En el protocolo MQTT, un mensaje no es otra cosa que una trama de datos con un payload que contiene la información real para el servidor o para el resto de los nodos. En una red de sensores por ejemplo, esa información habitualmente son valores medidos por los sensores, tales como temperatura, humedad, abierto, cerrado, etc…

Nota: La principal ventaja que aporta este modelo de comunicación es el desacoplo que se produce entre el transmisor y el receptor, gracias a la intermediación del broker de mensajes (un intermediario que gestiona el tránsito de los mensajes, pero ten paciencia porque hablo de este personaje más abajo).

Este desacoplo se produce en varios niveles:

• La aplicación o el nodo que publica un mensaje no necesita saber nada acerca de la existencia de la aplicación o nodo que va a consumir ese mensaje, al contrario de lo que sucede en redes punto a punto,  donde como mínimo necesitas conocer las direcciones IP de origen y destino o el puerto utilizado. Con el protocolo MQTT, la única dirección IP y puerto que se necesitan saber es la del broker de mensajes.
• El que publica y el que recibe no necesitan estar conectados a la vez. El broker puede almacenar mensajes para clientes que no están actualmente conectados, aunque en la mayoría de los casos, los mensajes se consumen en tiempo real.
• El que publica y el que recibe no necesitan estar sincronizados ni esperando el uno al otro, aunque es posible utilizar librerías de sincronización específicas si se necesita esto en alguna aplicación.

Resumiendo, el protocolo MQTT se basa en que alguien publica un mensaje con el identificador de un topic específico (no te preocupes porque veremos los topics con más detalle). El broker distribuye el mensaje a todos los clientes (aplicaciones o dispositivos) que le constan como subscritos a ese topic. Esos clientes reciben y consumen los datos de esos mensajes.

Los actores principales del protocolo MQTT

El protocolo MQTT clasifica los actores que participan en la red en clientes y servidores. A estos últimos los denomina brokers.

Los clientes MQTT

Los clientes MQTT pueden abarcar un amplio rango de formatos. Pueden ser clientes MQTT que recolectan información del medio (sensores y sistemas embebidos) o aplicaciones ejecutando alguna librería MQTT y que de alguna forma interactúen con los datos.

Pueden ser divulgadores (publicadores) y subscriptores de mensajes y además, pueden controlar y configurar los sensores a su cargo mediante comandos, si es que son nodos de sensores.

Estos siempre se conectan a un tercer participante, denominado broker de mensajes.

El bróker MQTT

El broker MQTT es un servicio (software) que implementa el protocolo MQTT y que establece la comunicación, a nivel de aplicación, entre los diferentes clientes. Hace de intermediario entre los productores y  los consumidores. Es el responsable de recibir los mensajes, filtrarlos y rutarlos a los clientes subscritos según su topic.

Otra tarea importante del brokers es autorizar el acceso e identificar los clientes.

Puede haber varios brokers en una misma red.

Turno de topics. ¿Qué son los topics en el protocolo MQTT?

Un topic se refiere a tema o asunto concreto. Al final, es un identificador que define el contenido del mensaje o el ámbito de influencia del mensaje (contexto). Con esto se clasifican y discriminar unos mensajes de otros y por extensión, unos nodos de otros.

Todo aquel que quiera publicar un mensaje MQTT, es responsable de clasificarlo en un topic concreto y los clientes subscritos a es topic, recibirán esos mensajes.

Las subscripciones pueden ser explícitas, con lo que el nodo sólo recibe mensajes de un topic concreto o puede recibir mensajes de varios topics si la subscripción se hace a través de algún identificador común a varios topics (es decir, utilizando lo que en inglés se conoce como wildcards, # y +).

Los topics en el protocolo MQTT se organizan según una estructura jerárquica en árbol (topic tree), utilizando el carácter “/” para formar un topic de varios niveles. Similar a la ruta a un directorio de carpetas típico de tu ordenador.

Entonces, el topic string es una cadena de caracteres que identifica el topic final del mensaje. Estas cadenas pueden ser:

• Multinivel: Se utiliza el carácter (wildcard) # para admitir cualquier nivel por debajo del nivel mostrado en la cadena.
• Simple: Se utiliza el carácter (wildcard) + para admitir sólo hasta el nivel mostrado en la cadena

Ejemplo de topics.

Creo que con un ejemplo se ve todo esto de los topics mucho más claro.

Imagina una aplicación de Internet de las Cosas para gestionar un jardín de forma inteligente mediante el protocolo MQTT. El jardín está dividido en varias parcelas, cada parcela con diferentes plantas, árboles y características de riego.

El topic raíz podría ser:

• Topic más simple = “jardín”

Algunos subniveles podrían ser:

• jardín/césped
• jardín/frutales/manzanos/temperatura
• jardín/rosales/humedad

Utilizando los caracteres comodín (wildcards):

• jardín/frutales/#

En este caso, los subscriptores a esta cadena (string topic) recibirán todos los mensajes identificados con los topics jardín/frutales y todos los de niveles inferiores, como por ejemplo jardín/frutales/manzanos.

• jardín/+

En este caso, los subscriptores a esta cadena recibirán los mensajes de ese nivel, por ejemplo mensajes del tipo jardín/rosales, pero no recibirán los mensajes jardín/rosales/humedad.

Garantía de entrega de mensajes

Lógicamente, el modelo publisher/subscriber sobre el que se basa el protocolo MQTT no es perfecto. El desacoplo que se produce entre el productor y consumidor trae algunos contratiempos. Cuando el filtro de mensajes se hace por topics, el más evidente de los problemas es que ambos actores tienen que saber de antemano el conjunto de topics que se utilizan.

Otro aspecto importante es que el productor del mensaje no se entera de si los subscriptores están leyendo sus mensajes o no.

Para solventar todo esto, el protocolo MQTT implementa hasta tres niveles de QoS (Quality of Service) para garantizar que los mensajes son entregados de forma correcta a los nodos. Cuanto más alto el nivel, más fiable es la transmisión, pero también supone un mayor consumo de ancho de banda o una mayor latencia.

Además, el servidor es capaz de mantener el mensaje incluso después de ser enviado a los nodos subscritos, de manera que si se producen nuevas subscripciones a los topics de los mensajes retenidos, estos se envían a los nuevos clientes.

Topologías típicas del protocolo MQT

Las dos topologías más típicas que se utilizan para el protocolo MQTT son las que pongo a continuación, siempre teniendo en cuenta que es un protocolo de la capa de aplicación del modelo OSI:

• Clientes que se conectan directamente al servidor final

Este patrón es útil cuando los nodos de la red disponen de recursos suficientes (memoria y CPU) como para poder ejecutar un cliente MQTT (software embebido grabado en su memoria), considerado, como ya he comentado, software de la capa de Aplicación y además, el número de sensores de limita a unos cuantos miles.

• Business Application: este tipo de aplicaciones son consideradas también clientes MQTT ya que son productores y consumidores de mensajes y suelen ser aplicaciones de monitorización, análisis y procesamiento de los datos procedentes de los sensores.
• Enterprise Integration Layer (ESB): es el servidor que actúa como catalizador y distribuidor de mensajes entre otras muchas funciones.
• Devices: sensores o aplicaciones remotas que recolectan información o cumplen con determinadas tareas y tienen capacidad de conexión con el sistema central.

• Clientes que se conectan al servidor final a través de un gateway

Este patrón es igual que el anterior salvo que se incluye un gateway que puede gestionar la subred de sensores y la comunicación entre ellos. Es un intermediario adicional útil en los casos en los que el servidor final no puede soportar un número elevado de nodos.

El gateway hace de enlace entre el servidor central y los nodos, gestiona la subred de nodos a su cargo y puede ejecutar directamente cierto software de procesamiento, como alarmas, notificaciones, etc.., sin pasar por el servidor central.

Saludos.