Re-Energy

MQTT
Uno de esos protocolos que están estrechamente ligados a Internet de las Cosas y que resuena
con fuerza es el protocolo MQTT.

De forma rápida y resumida, MQTT (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 la que se va a tratar.

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.

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

IoT

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

 Es open source, con lo cual es fácilmente integrable a las 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.

Julio Donadello
Re-Energy

 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).

Funcionamiento

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 es 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).

Julio Donadello
Re-Energy

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.

Actores principales

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, como se ve en la siguiente figura:

Julio Donadello
Re-Energy

Topics

Un topic se refiere a tema o asunto concreto. Es un identificador que define el contenido del
mensaje o el ámbito de influencia del mensaje (contexto). Con esto se clasifican y discriminan 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.

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.

Imagine 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.

Julio Donadello
Re-Energy

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.

Julio Donadello
Re-Energy

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

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 software de la capa de Aplicación y además, el número de sensores se 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

Similar al anterior, con la excepción de que se incluye un gateway que puede gestionar la subred
de sensores y la comunicación entre ellos. Es un intermediario adicional útil que 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.

Julio Donadello