Tarea Obligatoria – Redes de Datos

Internet of Things –
Protocolo MQTT

Integrantes: Andrés Arancio, Mauricio Gómez

Primer semestre 2018
Internet of Things: Protocolo MQTT

Introducción a Internet of Things

Si bien la idea es usada de forma relativamente vaga y poco específica, Internet of Things
es, fundamentalmente, un modelo de desarrollo orientado a la automatización para
diferentes tecnologías. El hecho de quitar intervención humana a los procesos no solo
intenta garantizar la eficiencia industrial, sino que también altera profundamente la vida
cotidiana de la persona común.

Este modelo trabaja, principalmente, con sensores, actuadores y otros periféricos que
demandan escasos recursos, por lo que una de las mayores necesidades para construirlo
es poseer una comunicación efectiva y de bajo consumo entre máquinas a través de la
red. Dicha necesidad y todas las soluciones generadas para satisfacerla (protocolos,
sistemas, nuevos modelos) se han vuelto prácticamente inseparables del Internet of
Things.

Dado que tiene algunas diferencias básicas con las redes de información más comunes,
IoT requiere otro modelo de capas. Sin embargo, debido a las variadas necesidades y
aplicaciones que presenta, existen múltiples modelos propuestos que pueden adaptarse
a diferentes áreas. En particular, es relevante el modelo usado para sensores, apodado
PNA (Perception Network Application), que se focaliza en la transmisión de datos desde
dispositivos físicos hacia un centro de procesamiento. También se debe mencionar la
modificación del modelo TCP/IP Suite, que colapsa la capa física y de enlace en una misma
“capa física y capa MAC”, y agrega una capa de adaptación dedicada a traducir paquetes
de IPv6 a IPv4 o 6LoWPAN, acordes con las necesidades.
Protocolo Message Queuing Telemetry Transport
El común de la gente tiende a considerar IoT como un concepto nuevo, pero ha sido
teorizado por ingenieros durante mucho tiempo. Algunos de los protocolos que hoy en
día se utilizan, sobre todo, para este modelo, se remontan hasta dos décadas atrás; es el
caso del Message Queuing Telemetry Transport, que fue diseñado en 1999. Este
protocolo, generalmente referido como MQTT, es un protocolo de mensajería liviano del
tipo publicar/subscribir, diseñado para trabajar con aparatos de poco ancho de banda,
alta latencia y redes poco confiables. Sus principios básicos tienden a minimizar el
consumo ancho de banda de la red y los recursos requeridos por el aparato, mientras
provee un servicio de entrega confiable y robusto. Estos principios son lo que lo hacen
ideal para comunicación M2M (“machine to machine”) y, por lo tanto, para trabajar en
conjunto con otros protocolos en IoT.

Debido a su enfoque a comunicación M2M (y, en particular, a su eficiente uso de

recursos), MQTT es muy utilizado para sensores y tecnología celular, ya que otros
protocolos más verbosos o menos simplificados tienen una mayor demanda de banda y
energía, que pequeños dispositivos no siempre son capaces de darse el lujo de consumir.

Si bien el protocolo recibió el título de estándar de OASIS en 2014 y fue publicado como
un open source con licencia libre de regalías, desde 2005 y 2006 ha tenido una constante
presencia en el desarrollo de tecnologías. Algunos proyectos se enfocaron en aprovechar
las ventajas inherentes del MQTT, para hacer posibles ideas como clasificar información
basada en los intereses y ubicaciones de los usuarios, traducir texto hablado a lenguaje
de señas, crear edificios inteligentes y más.

Desde entonces, el MQTT se ha convertido en uno de los protocolos más usados en IoT,
siendo la elección obvia al trabajar con tecnologías de automatización y compitiendo con
otros gigantes como XMPP, Rest API y CoAP. Su orientación al trabajo con sistemas
limitados o riesgosos generó la eventual evolución del protocolo en MQTT-S,
espacialmente diseñado para sistemas de sensores que pasan una gran cantidad de
tiempo desactivados.

Funcionamiento general del protocolo MQTT

El protocolo MQTT actúa a nivel de capa de aplicación y basa su funcionamiento en los
protocolos TCP e IP de capas inferiores. Ofrece servicios tanto de conexión como de
desconexión, lo que es intuitivo, al estar basado en un protocolo orientado a la conexión.
A la vez, ofrece Quality of Service de tres niveles, desde “fire and forget” hasta “assured
delivery”. MQTT también dispone del servicio de publicación, que tiene que ver con su
patrón de funcionamiento publicar/suscribir, que será explicado a continuación.

Un patrón publicar/suscribir requiere que el protocolo sea capaz de enviar mensajes sin
un receptor definido, lo que les otorga cierta atemporalidad. El emisor envía un mensaje
sin un receptor particular o, lo que es lo mismo, lo “publica” y los receptores deben estar
vinculados con el emisor para recibir el contenido, es decir, se “suscriben” a él. Para
obtener una mejor organización, el MQTT crea “temas”, o sea, clasificaciones de mensajes
que permiten a un cliente decidir qué contenido recibir.

Para realizar esto, el protocolo designa dos entidades en la red: un broker de mensajes y
un cierto número de clientes. El broker actúa como un nodo de una red conectada en
forma de estrella; los clientes definidos como divulgadores emiten mensajes al broker,
que luego compara el tema del mensaje con sus archivos, para ver qué equipo debe
recibirlo, y lo deriva a los clientes que están suscritos a dicho tema. Ya que el MQTT es
liviano y de simple topología, el broker puede manejar fácilmente grandes cantidades de
clientes, con un máximo recomendado que, por lo general, ronda los diez mil.

ILUSTRACIÓN 1 DIAGRAMA DE TOPOLOGÍA UTILIZADA POR MQTT (EXTRAÍDO DE WEB OFICIAL DE IBM)
1

Estructura de los mensajes

Los mensajes enviados por el protocolo MQTT son binarios, es decir que usan como
elementos de control bits de datos en lugar de strings de texto. Existen algunas
excepciones que serán explicadas más adelante.

Todos los mensajes para cada comando MQTT tienen un encabezado fijo, de dos a cinco
bytes de largo, y pueden disponer o no de un encabezado variable y un payload de hasta

1 Diagrama de topología del protocolo MQTT

256 MB. El payload de los mensajes varía según los tipos de mensaje, siendo procesado
como un string de datos codificado en UFP para mensajes internos del protocolo, y
tratado como un blob de información para publicaciones que serán enviadas como
contenido a los usuarios.

Encabezado fijo
El encabezado fijo de un mensaje MQTT puede ser dividido en dos partes: el byte de
control y los bytes de longitud restante de paquete. El byte de control es un único byte
que contiene el tipo de mensaje, el nivel de Quality of Service y los flags necesarios para
todo mensaje. El campo de longitud restante de paquete puede tener desde uno a cuatro
bytes y, como el nombre indica, define qué tan largo es el paquete en cuestión. Debido a
que estos dos campos son los únicos elementos siempre presentes en el mensaje, los
comandos más pequeños de MQTT son solamente dos bytes: uno de control y uno de
longitud de paquete.

7 6 5 4 3 2 1 0
bit

byte 1 Tipo de Mensaje DUP flag Nivel de QoS flag RETAIN flag

byte 2 Longitud de Paquete

TABLA 1 FORMATO DE ENCABEZADO FIJO DE PAQUETE MQTT

Tipo de Mensaje
Posición: Byte 1, bits 7 a 4
Valor de 4 bits que determina cuál de los 14 posibles tipos de mensaje disponibles se
está enviando. (Ver tabla en anexo)

Flags
Posición: Byte 1, bits 3 a 0
Valor de cuatro bits que contiene los campos de los flags DUP, QoS y RETAIN.

El campo DUP obtiene su nombre de acortar la palabra “duplicate”; se encuentra en el

cuarto bit desde la derecha, en la posición tres del primer byte. En caso de estar en alto,
este informa al servidor si el mensaje ya ha sido enviado previamente. No se debe
confundir esto con un indicador de duplicados, ya que el mensaje original pudo haberse
perdido antes de llegar a destino. En el caso de que un acknowledgement del servidor no
llegue a su destino a tiempo, el cliente envía el mensaje de nuevo, esta vez con el flag DUP
en alto.
El campo QoS se compone de dos bits ubicados en las posiciones dos y uno del primer
byte. Describe el nivel de Quality of Service con el que el mensaje debe de ser tratado,
variando desde cero a dos; el valor tres es reservado. Quality of Service es uno de los
elementos más interesantes del MQTT, ya que no muchos protocolos alternativos lo
poseen; será descrito en detalle más adelante.

Finalmente, el campo RETAIN se ubica en la posición cero del primer byte e informa al
servidor si un mensaje debe de ser guardado en su memoria. Solo es usado en mensajes
de tipo PUBLISH, los cuales, de tener este flag en alto, deben ser almacenados luego de
que el servidor dirige el mensaje a los suscriptores. Cuando un cliente se suscribe a un
tema con mensajes retenidos, el servidor envía la última publicación con RETAIN alto que
tenía guardada. Se puede eliminar este último mensaje enviando un PUBLISH a dicho
tema con RETAIN alto y payload cero.

Longitud Restante del Paquete

Posición: Byte 2 a 4
El campo Longitud Restante del Paquete determina el tamaño del encabezado variable y
el payload. El protocolo reconoce el tamaño del campo, debido a que se encuentra
codificado con un patrón de largo variable que representa hasta un valor de 127 con un
byte, utilizando un bit como continuación para el siguiente byte, con un máximo de cuatro
bytes.

Encabezado Variable
Posición: Byte 3 o 5 a X
El encabezado variable es un campo directamente a continuación del encabezado fijo, y
su tamaño es dependiente del tipo de mensaje que se está enviando. Algunos comandos,
como DISCONNECT, por ejemplo, no poseen encabezados variables, mientras que otros,
como el PUBLISH, lo necesitan para conocer información como tema de destino o
identificador del cliente emisor.

Payload
Posición: Byte X a Y
Algunos paquetes de control MQTT contienen un payload al final del mensaje.
Dependiendo del tamaño del encabezado variable, los mensajes pueden ser de hasta
256 MB de largo.
Ver tabla de mensajes con payload requerido en Anexo.

Comportamiento Operacional
Guardar estado

Si es necesario, el cliente y el servidor pueden almacenar el estado de su interacción con

el objetivo de asegurar su Quality of Service. Mensajes guardados por el flag Retain no
son guardados de esta forma, ya que no se pierden en caso de que haya una caída de la
conexión.

Conexión de red
Debido a su diseño, MQTT requiere funcionar en un sistema de transporte de capas
inferiores que garantice un stream de bytes ordenado y sin pérdidas, de cliente a servidor
y viceversa. Es por esto que la mayoría de las versiones del protocolo funciona con
TCP/IP, lo que proporciona los servicios de capa superior que necesita, con TLS y
Websocket como opciones alternativas. Por estándar, los registrados por IANA para
MQTT son los puertos 8883 para comunicación TLS y 1883 para otros.

Niveles de Quality of Service y flujo de mensajes del protocolo

El MQTT envía mensajes de diferente forma, dependiendo del nivel de Quality of Service,
que está definido en tres niveles, de menor a mayor fidelidad y consumo de recursos.

El nivel cero: “At Most Once Delivery”, se basa en el best effort del protocolo TCP/IP sobre
el que se encuentra implementado; por lo tanto, no garantiza que el mensaje llegue al
servidor. Es por esto que se le denomina con el término Fire and Forget, puesto que la
entidad envía el mensaje y no espera respuesta al respecto.

El nivel uno, “At Least Once Delivery”, utiliza un sistema de reconocimiento para
garantizar la llegada de los mensajes. Todo mensaje con QoS igual a uno espera recibir un
acknowledge del receptor, por lo que se le conoce como Acknowledged Delivery. Con este
sistema es posible que el receptor reciba múltiples mensajes, debido a que el
acknowledge se pierda en el camino o demore demasiado en llegar a destino.

El máximo nivel de Quality of Service, “Exactly Once Delivery”, no solo garantiza que el
mensaje llegue a destino, sino que asegura que no existan duplicados. Esto solo es usado
para mensajes en los que resulta indeseado tener copias recibidas; consume una gran
cantidad de ancho de banda, ya que no utiliza una, sino cuatro comunicaciones diferentes
para enviar un solo mensaje, y tres de ellas funcionan como acknowledgement, para
garantizar la llegada de los paquetes. Por esto, a este tipo de QoS se les denomina
“Assured Delivery”.

Comparación del MQTT con protocolos alternativos

MQTT vs XMPP
El Extensible Messaging and Presence Protocol (XMPP) también fue desarrollado en
1999, y es considerado la principal competencia del MQTT, siendo ambos los principales
protocolos de comunicación utilizados en IoT. Debido a su larga historia y al hecho de
que, mientras el MQTT comenzó verdaderamente su invasión en el mercado a finales de
los años 2000 y principios de los 2010, el XMPP ha sido siempre un elemento importante
en desarrollo, puesto que el protocolo posee una gran cantidad de librerías y un rico
ambiente de apoyo. Sin embargo, el XMPP tiene la desventaja de sus raíces en XML, un
lenguaje relativamente primitivo y poco eficiente en el manejo de recursos.

MQTT presenta la ventaja fundamental de ser mucho más ligero que XMPP, sin mencionar
que su formato publicación-suscripción es mucho más práctico para ciertos usos que la
comunicación directa que utiliza XMPP. Esto vuelve al MQTT el protocolo estrella para
comunicación M2M (machine-to-machine), aunque en otras situaciones el XMPP posee
algunas ventajas, como su escalabilidad y su capacidad de definir formato de mensajes.
Sin embargo, XMPP no es capaz de flexibilizar su QoS, cosa que MQTT puede hacer
fácilmente.

En conclusión, si bien el XMPP es muy efectivo en varias áreas, en particular, cuando se

requiere gran escalabilidad, tráfico masivo y complejo o confidencialidad en la
comunicación, la velocidad y eficiencia del MQTT lo hace la opción superior al trabajar en
comunicaciones M2M.

MQTT vs HTTP
Aunque HTTP ha sido el protocolo más usado para conexiones de red, se ve opacado
cuando se compara con el MQTT en IoT. El protocolo HTTP es extremadamente verboso
y denso, no siendo muy efectivo al trabajar con dispositivos de pocos recursos, sin
mencionar que el patrón request-response para interacciones entre cliente y servidor del
HTTP no se encuentra optimizado para tecnología móvil que es parte de la base de IoT
moderno.

Con respecto a velocidad, de acuerdo con medidas realizadas en redes 3G, el protocolo
MQTT es hasta noventa y tres veces más rápido que el HTTP, debido a sus pequeños
encabezados. Además, el MQTT ofrece varios niveles de Quality of Service y la capacidad
de retener mensajes luego de enviarlos, cualidades que el HTTP carece.

Por lo expuesto, el protocolo MQTT es la opción superior en utilidades específicas, sobre

todo, cuando la velocidad y la eficiencia del uso de datos son más prioritarias que la
facilidad de uso para los desarrolladores. Por lo tanto, resulta bastante claro que es la
opción correcta al trabajar con IoT.
Referencias
• http://mqtt.org/documentation
• https://www.hindawi.com/journals/jece/2017/9324035/
• https://www.ibm.com/internet-of-things
Anexos:
Tabla de tipo de mensajes MQTT

Mnemónico Enumeración Valor Flujo de Descripción

decimal datos

Reservado 0 0 Prohibido Reservado

CONNECT 1 16 Cliente- Request para conectarse al

Servidor servidor.

CONNACK 2 32 Servidor- Reply reconociendo la

Cliente conexión.

PUBLISH 3 48 Servidor- Request para publicar mensaje.

Cliente
Cliente-
Servidor

PUBACK 4 64 Servidor- Reply reconociendo la

Cliente publicación.
Cliente-
Servidor

PUBREC 5 80 Servidor- Reply reconociendo la llegada

Cliente del request para publicar (solo
Cliente- usado en QoS nivel 2).
Servidor

PUBREL 6 96 Servidor- Request para enviar la

Cliente publicación a los suscriptores
Cliente- (solo usado en QoS nivel 2).
Servidor

PUBCON 7 112 Servidor- Reply informando de la emisión

Cliente de la publicación a los
Cliente- suscriptores (solo usado en
Servidor QoS nivel 2).

SUBSCRIBE 8 128 Cliente- Request para suscribirse a un

Servidor tema.

SUBACK 9 144 Servidor- Reply reconociendo la

Cliente suscripción a un tema.

UNSUBSCRIBE 10 160 Cliente- Request para darse de baja de

Servidor un tema.
UNSUBACK 11 176 Servidor- Reply reconociendo el darse de
Cliente baja de un tema.

PINGREQ 12 192 Cliente- Request para enviar un ping.

Servidor

PINGRESP 13 208 Servidor- Respuesta de un ping.

Cliente

DISCONNECT 14 224 Cliente- Request para desconectarse del

Servidor servidor.

Reservado 15 240 Prohibido Reservado

Mensajes que requieren Payload

Comando Payload

CONNECT Requerido

CONNACK Ninguno

PUBLISH Opcional

PUBACK Ninguno

PUBREC Ninguno

PUBREL Ninguno

PUBCOMP Ninguno

SUBSCRIBE Requerido

SUBACK Requerido

UNSUBSCRIBE Requerido

UNSUBACK Ninguno

PINGREQ Ninguno
 PINGRESP Ninguno

DISCONNECT Ninguno

Flags correspondientes a los paquetes MQTT

Control Packet Fixed header flags Bit 3 Bit 2 Bit 1 Bit 0

CONNECT Reserved 0 0 0 0

CONNACK Reserved 0 0 0 0

PUBLISH Used in MQTT 3.1.1 DUP1 QoS2 QoS2 RETAIN3

PUBACK Reserved 0 0 0 0

PUBREC Reserved 0 0 0 0

PUBREL Reserved 0 0 1 0

PUBCOMP Reserved 0 0 0 0

SUBSCRIBE Reserved 0 0 1 0

SUBACK Reserved 0 0 0 0

UNSUBSCRIBE Reserved 0 0 1 0

UNSUBACK Reserved 0 0 0 0

PINGREQ Reserved 0 0 0 0

PINGRESP Reserved 0 0 0 0

DISCONNECT Reserved 0 0 0 0