A medida que el sector se desarrolla rápidamente, también aumenta el número de dispositivos necesarios para la gestión y la recepción de datos. Para resolver el problema de la comunicación entre numerosos dispositivos y el de su integración en una única red, se ha creado el concepto de Internet de las cosas (IoT): una combinación de dispositivos con características comunes en una única red basada en determinadas funciones. Esta red se integra a su vez con otras redes similares, creando así una red más amplia, y así sucesivamente.
En una red de este tipo, los dispositivos interactúan entre sí a través de diversas interfaces y protocolos de comunicación. Dado que estamos analizando la aplicación industrial del concepto del IoT, que debería utilizar equipos industriales con sus propios protocolos y hardware, comencemos a explorar el concepto del IIoT (Internet industrial de las cosas).
Para comunicarse, los dispositivos pueden utilizar diversos protocolos industriales. En este sentido, MQTT es muy utilizado.
¿Qué es MQTT?
MQTT (Message Queuing Telemetry Transport) es un protocolo de mensajería ligero y abierto que se utiliza para la transferencia de datos en ubicaciones remotas en las que se requiere un “código de tamaño reducido” o en las que el ancho de banda de la red es limitado. Estas ventajas permiten la implementación de este protocolo en sistemas M2M (máquina a máquina) y en sistemas IIoT (Internet de las cosas industrial).
También existe una variante del protocolo denominada MQTT-SN (MQTT para redes de sensores), anteriormente conocida como MQTT-S, que está diseñada para su uso con dispositivos inalámbricos integrados que no son compatibles con redes TCP/IP, como ZigBee.
Funciones del protocolo MQTT
Las principales funciones del protocolo MQTT:
● Protocolo asíncrono
● Mensajes breves
● Funciona cuando la conexión de la línea de transmisión de datos es inestable
● Admite varios niveles de calidad de servicio (QoS)
● Integra fácilmente nuevos dispositivos
En la capa de aplicación, el protocolo MQTT funciona sobre el Protocolo TCP/IP y utiliza el puerto 1883 por defecto (el puerto 8883 si la conexión se realiza a través de SSL).
En el protocolo MQTT, el intercambio de mensajes tiene lugar entre un cliente (que puede ser un emisor o un receptor de mensajes) y un servidor de mensajes (como Mosquitto MQTT).
La editorial envía datos sobre el Corredor MQTT con un tema específico indicado en el mensaje. Los suscriptores pueden recibir diversos datos de múltiples emisores en función de sus suscripciones a los temas correspondientes.
Los dispositivos MQTT utilizan determinados tipos de mensajes para comunicarse con los brokers. Los principales tipos son los siguientes:
● Conexión: establecer una conexión con Message Broker
● Desconectar: desconectarse del gestor de mensajes
● Publicar: publicar datos sobre un tema en Message Broker
● Suscripción: suscribirse a un tema en el intermediario de mensajes
● Cancelar suscripción: dejar de recibir mensajes sobre este tema
La estructura del mensaje
Los mensajes MQTT contienen las siguientes partes:
● Encabezado fijo (aparece en todos los mensajes)
● Encabezados variables (aparecen en algunos mensajes)
● Datos, carga útil (presente en algunos mensajes)
1. Cabezal fijo
Tipo de mensaje – p. ej.: CONNECT, SUBSCRIBE, PUBLISH, etc.
Indicadores propios de cada paquete MQTT – Estos 4 bits se utilizan para indicadores auxiliares, cuya presencia y estado dependen del tipo de mensaje.
Longitud restante – Longitud actual del mensaje (datos variables de la cabecera), de 1 a 4 bytes.
En total, hay 15 tipos de mensajes en el protocolo MQTT:
| Tipo de mensaje | Valor | Dirección | Descripción |
|---|---|---|---|
| Reservado | 0000 (0) | Prohibido | Reservado |
| CONECTAR | 0001 (1) | C → S | Solicitud del cliente para establecer una conexión |
| CONNACK | 0010 (2) | S → C | Confirmación de conexión |
| PUBLICAR | 0011 (3) | C ↔ S | Publicar mensaje |
| PUBACK | 0100 (4) | C ↔ S | Agradecimientos de la publicación |
| PUBREC | 0101 (5) | C ↔ S | Publicar recibido (QoS 2, paso 1) |
| PUBREL | 0110 (6) | C ↔ S | Publicar la versión (QoS 2, paso 2) |
| PUBCOMP | 0111 (7) | C ↔ S | Publicación completada (QoS 2, paso 3) |
| SUSCRÍBETE | 1000 (8) | C → S | Solicitud de suscripción del cliente |
| SUBACK | 1001 (9) | S → C | Confirmación de suscripción |
| DARSE DE BAJA | 1010 (10) | C → S | Solicitud de baja |
| UNSUBACK | 1011 (11) | S → C | Confirmación de baja |
| PINGREQ | 1100 (12) | C → S | Solicitud de ping |
| PINGRESP | 1101 (13) | S → C | Respuesta de ping |
| DESCONECTAR | 1110 (14) | C → S | Solicitud del cliente para dar de baja el servicio |
| Reservado | 1111 (15) | Prohibido | Reservado |
Los cuatro primeros bits más significativos de la cabecera fija se utilizan como indicadores específicos:
DUP – La opción «Duplicate» se activa cuando un cliente o un broker MQTT envía un paquete retransmitido (utilizado en PUBLISH, SUBSCRIBE, UNSUBSCRIBE y PUBREL). Si se activa esta opción, el encabezado «variable» debe contener el ID del mensaje (identificador del mensaje).
QoS – Calidad del servicio (0, 1, 2)
Retención – Cuando los datos se publican con el indicador de retención, el broker los almacenará. El broker enviará un mensaje con este indicador tan pronto como se establezca una nueva suscripción al tema. Solo se utiliza en mensajes de tipo PUBISH.
2. Título de la variable
En algunas cabeceras hay cabeceras variables. Contienen los siguientes datos:
● Identificador de paquete: presente en todos los tipos de mensaje excepto en: CONNECT, CONNACK, PUBLISH (con QoS <1), PINGREQ, PINGRESP y DISCONNECT
● Nombre del protocolo: solo se muestra en el tipo de mensaje CONNECT
● Versión del protocolo: solo existe en el tipo de mensaje CONNECT
● indicadores de conexión: indicadores que especifican el comportamiento del cliente durante una conexión
Nombre de usuario – Si se activa esta opción, debe figurar un nombre de usuario en la carga útil (para la autenticación del cliente)
Contraseña – Si se activa esta opción, la contraseña debe figurar en la carga útil (utilizada para la autenticación del cliente)
Se mantendrá – Si este indicador se establece en 1, el broker almacenará un mensaje «Will».
¿Será QoS? – Calidad de servicio de «Message». Si se activa el indicador «Will», deben estar presentes «Will QoS» y «Will Reservation».
Se señalará – Si se activa este indicador, cuando un cliente se desconecte del broker sin enviar un comando DISCONNECT (en caso de apagado imprevisto, fallo, etc.), el broker notificará a todos los clientes conectados mediante lo que se conoce como «mensaje de voluntad».
Sesión limpia – Si este indicador se establece en 0, el broker almacena una sesión; todas las suscripciones del cliente se enviarán en la siguiente conexión de este y, cuando el cliente se desconecte, el broker recibirá todos los mensajes de QoS1 y QoS2. Por lo tanto, si este indicador se establece en 1, en la siguiente conexión, el cliente deberá suscribirse de nuevo a todos los temas.
● Existencia de sesión: se aplica en mensajes de tipo CONNACK. Si el Broker acepta conexiones con «Clean Session» establecido en 1, «Session Present» (SP) debe establecerse en 0. Si el Broker acepta una conexión con «Clean Session» establecido en 0, el valor de «Session Present» (SP) dependerá de si el Broker ha almacenado el estado de la sesión para este cliente (en tal caso, SP debe establecerse en 1, y viceversa). El indicador de existencia de la sesión permite al cliente determinar si se ha almacenado el estado de la sesión.
● Código de respuesta de conexión: si, por cualquier motivo, el proxy no puede recibir un paquete CONNACK correctamente formado del cliente, debe establecer el valor adecuado en el segundo byte del paquete CONNACK, según se indica en la siguiente tabla:
| Valor | Respuesta con código de retorno | Descripción |
|---|---|---|
| 0 | 0x00 – Conexión aceptada | Conexión establecida con éxito |
| 1 | 0x01 – Conexión rechazada: versión de protocolo no válida | El servidor no admite la versión del protocolo solicitada |
| 2 | 0x02 – Conexión denegada: identificador rechazado | El ID de cliente no es válido o no está permitido |
| 3 | 0x03 – Conexión rechazada: servidor no disponible | El agente no está disponible |
| 4 | 0x04 – Conexión rechazada: nombre de usuario o contraseña incorrectos | El nombre de usuario o la contraseña son incorrectos |
| 5 | 0x05 – Conexión rechazada: sin autorización | El cliente no está autorizado a conectarse |
| 6–255 | Reservado para uso futuro |
El contenido y el formato de los datos transmitidos a través de mensajes MQTT se definen en el dispositivo. El tamaño de los datos se puede calcular restando la longitud de la cabecera variable de la longitud restante.
3.Datos, carga útil
La carga útil es la información a nivel de aplicación que se transmite dentro de un mensaje MQTT. Solo se incluye en determinados tipos de mensajes, como PUBLISH, CONNECT (campos de autenticación) y los mensajes «Will». El estándar MQTT no define una estructura fija para la carga útil: el contenido y el formato los determina el dispositivo o la aplicación.
Dependiendo del caso de uso, la carga útil puede contener datos de sensores, objetos JSON, telemetría binaria, valores de comando o información de autenticación, como el nombre de usuario, la contraseña o el mensaje «Will». La longitud de la carga útil se calcula restando el tamaño de la cabecera variable del campo «Longitud restante» de la cabecera fija.
Calidad de servicio en el protocolo MQTT (QoS)
MQTT admite tres niveles de calidad de servicio (QoS) al enviar mensajes.
QoS 0: como máximo una vez. En este nivel, el emisor envía un mensaje cada vez al intermediario y no espera ninguna respuesta; es decir, lo envía y se olvida de él.
QoS 1 al menos una vez. Este nivel garantiza que los mensajes se entreguen al broker, pero los mensajes pueden copiarse desde el editor. Una vez recibida la copia, el broker envía de nuevo el mensaje al suscriptor y reenvía el acuse de recibo del mensaje al editor. Si el editor no recibe un mensaje PUBACK del broker, intentará volver a entregar este paquete, estableciendo DUP en 1.
QoS 2: «exactamente una vez». En este nivel, se garantiza la entrega del mensaje al cliente y no es posible que se produzcan duplicados.
El editor envía un mensaje al intermediario. El mensaje contiene un identificador de paquete único, QoS=2 y DUP=0. El editor almacena los mensajes sin confirmar a menos que reciba una respuesta PUBREC del intermediario. El proxy responde con un mensaje PUBREC que contiene el mismo identificador de grupo. Tras recibir este mensaje, el editor envía un PUBREL con el mismo identificador de paquete. El intermediario debe almacenar una copia del mensaje hasta que obtenga un PUBREL. Una vez que el intermediario recibe el PUBREL, elimina la copia del mensaje y envía al editor un mensaje PUBCOMP indicando que la transacción se ha completado.
