PricingLog inGet startedAsk Navixy AI

Fundamentos de MQTT

El protocolo Message Queuing Telemetry Transport (MQTT) se ha utilizado durante muchos años, pero ahora es especialmente relevante debido al crecimiento explosivo del IoT: tanto los dispositivos de consumo como los industriales están implementando redes distribuidas y computación en el borde, y los dispositivos con transmisión constante de datos están convirtiéndose en parte de la vida diaria. Este crecimiento tan intensivo obliga a buscar formas de transferir datos de manera eficiente.

Qué es MQTT

Andy Stanford-Clark (IBM) y Arlen Nipper (entonces trabajando para Eurotech, Inc.) autorizaron la primera versión del protocolo en 1999. Se utilizó para supervisar oleoductos dentro del marco SCADA. El objetivo era disponer de un protocolo eficiente en el uso del ancho de banda, ligero y de bajo consumo de batería, porque los dispositivos estaban conectados mediante enlace satelital que, en ese momento, era extremadamente caro. En la actualidad, la mayoría de los dispositivos usan la versión 5.0.

El Message Queuing Telemetry Transport (MQTT) es un protocolo de red liviano de publicación/suscripción que transporta mensajes entre dispositivos. El protocolo normalmente se ejecuta sobre TCP/IP; sin embargo, cualquier protocolo de red que proporcione conexiones ordenadas, sin pérdidas y bidireccionales puede soportar MQTT. Está diseñado para conexiones con ubicaciones remotas donde se requiere una "huella de código pequeña" o el ancho de banda de la red es limitado. El protocolo es un estándar abierto de OASIS y una recomendación ISO (ISO/IEC 20922).

Dadas las condiciones de operación, el protocolo se ha diseñado pequeño y ligero. Es ideal para dispositivos con bajo consumo de energía y vida útil de batería limitada. Ahora, esto incluye teléfonos inteligentes, así como un número cada vez mayor de sensores y dispositivos conectados.

Por lo tanto, MQTT se ha convertido en un protocolo para transmitir datos entre dispositivos con potencia de CPU limitada y/o vida de batería reducida, así como para redes con ancho de banda caro o bajo, estabilidad impredecible o alta latencia. Por eso MQTT es conocido como el protocolo ideal para IoT. Se basa en el protocolo TCP/IP, pero existe una rama MQTT-SN para trabajar sobre Bluetooth, UDP, ZigBee y en otras redes IoT distintas de TCP/IP.

Cómo funciona

El modelo publicar y suscribirse

Hay 2 definiciones principales en MQTT: MQTT Broker y cliente MQTT.

Un MQTT broker es un servidor que recibe todos los mensajes de los clientes y luego enruta los mensajes a los clientes de destino apropiados. En palabras simples, el broker actúa como una oficina de correos: MQTT no utiliza la dirección del destinatario previsto sino que usa la línea de asunto llamada “Topic”, y cualquiera que quiera una copia de ese mensaje se suscribirá a ese topic. Varios clientes pueden recibir el mensaje de un solo broker (capacidades de uno a muchos). De manera similar, múltiples publicadores pueden publicar topics para un solo suscriptor (muchos a uno).

Un cliente MQTT es cualquier dispositivo (desde un microcontrolador hasta un servidor completo) que ejecuta una biblioteca MQTT y se conecta a un MQTT broker a través de una red.

  • El cliente se conecta al broker. Puede suscribirse a cualquier “topic” de mensajes en el broker. Esta conexión puede ser una conexión TCP/IP simple o una conexión TLS cifrada para mensajes sensibles.

  • El cliente publica mensajes bajo un topic enviando el mensaje y el topic al broker.

  • El broker luego reenvía el mensaje a todos los clientes que se suscriben a ese topic.

Dado que los mensajes MQTT están organizados por topics, el desarrollador de la aplicación tiene la flexibilidad de especificar que ciertos clientes solo puedan interactuar con determinados mensajes. Por ejemplo, los sensores publicarán sus lecturas bajo el topic “sensor_data” y se suscribirán al topic “config_change”. Las aplicaciones de procesamiento de datos que guardan los datos de sensores en una base de datos back-end se suscribirán al topic “sensor_data”. Una aplicación de consola de administración podría recibir comandos del administrador del sistema para ajustar las configuraciones de los sensores, como la sensibilidad y la frecuencia de muestreo, y publicar esos cambios en el topic “config_change”.

Tipos de mensajes MQTT

Una sesión MQTT se divide en cuatro etapas: conexión, autenticación, comunicación y terminación. Un cliente comienza creando una conexión Transmission Control Protocol/Internet Protocol (TCP/IP) al broker usando ya sea un puerto estándar o un puerto personalizado definido por los operadores del broker. Al crear la conexión, es importante reconocer que el servidor podría continuar una sesión antigua si se le proporciona una identidad de cliente reutilizada.

Los puertos estándar son 1883 para comunicación no cifrada y 8883 para comunicación cifrada -- usando Secure Sockets Layer (SSL)/Transport Layer Security (TLS). Durante el apretón de manos SSL/TLS, el cliente valida el certificado del servidor y autentica al servidor. El cliente también puede proporcionar un certificado de cliente al broker durante el apretón de manos. El broker puede usar esto para autenticar al cliente. Aunque no forma parte específicamente de la especificación MQTT, se ha vuelto habitual que los brokers admitan la autenticación de clientes con certificados de cliente SSL/TLS.

Debido a que el protocolo MQTT está destinado a ser un protocolo para dispositivos con recursos limitados y dispositivos IoT, SSL/TLS no siempre puede ser una opción y, en algunos casos, puede no ser deseado. En tales ocasiones, la autenticación se presenta como un nombre de usuario y contraseña en texto claro, que son enviados por el cliente al servidor - esto, como parte de la secuencia de paquetes CONNECT/CONNACK. Además, algunos brokers, especialmente brokers abiertos publicados en internet, aceptarán clientes anónimos. En esos casos, el nombre de usuario y la contraseña simplemente se dejan en blanco.

Formato del mensaje MQTT

MQTT se considera un protocolo liviano porque todos sus mensajes tienen una pequeña huella de código. El paquete consiste en un encabezado fijo de 2 bytes + un encabezado variable y una carga útil. En estos primeros 2 bytes, el encabezado fijo siempre estará presente en todos los paquetes y los otros dos, encabezado variable y carga útil, no siempre están presentes.

Formato del mensaje MQTT

De los dos bytes del encabezado fijo, el primer byte es el campo de control. Este campo de control de 8 bits está dividido en dos campos de 4 bits. Los primeros 4 bits más significativos son el campo de tipo de comando. Este tipo determina la acción que se realizará: el cliente quiere suscribirse al topic, se publica un nuevo mensaje para suscriptores y otros.

Los siguientes 4 bits son los bits de bandera de control y se utilizan en el comando publish; para el resto de los comandos están reservados y su valor será 0.

El segundo byte del encabezado fijo contiene la longitud restante que es, la longitud del encabezado variable + la longitud de la carga útil.

Un encabezado variable no está presente en todos los paquetes MQTT. Algunos comandos o mensajes MQTT usan este campo para proporcionar información adicional o banderas y varían según el tipo de paquete. Un identificador de paquete es común en la mayoría de los tipos de paquete.

Al final, el paquete puede contener una carga útil. Incluso la carga útil es opcional y varía según el tipo de paquete. Este campo generalmente contiene los datos que se están enviando. Por ejemplo: para los paquetes CONNECT, la carga útil es el ID del cliente y el ‘nombre de usuario y contraseña’ si están presentes. Y para el paquete PUBLISH, es el mensaje que se va a publicar.

Calidad de Servicio

QoS se refiere a un acuerdo entre el remitente de un mensaje y el destinatario del mensaje. Actúa como una característica clave en MQTT, dando al cliente la capacidad de elegir entre tres niveles de servicio.

Los tres niveles diferentes de QoS determinan cómo se gestiona el contenido por el protocolo MQTT. Aunque los niveles más altos de QoS son más confiables, tienen más requisitos de latencia y ancho de banda, por lo que los clientes suscriptores pueden especificar el nivel de QoS más alto que deseen recibir.

  • El nivel de QoS más simple es un servicio sin acuse de recibo. Este nivel de QoS utiliza una secuencia de paquetes PUBLISH; el publicador envía un mensaje al broker una sola vez, y el broker transmite el mensaje a los suscriptores una sola vez. No existe un mecanismo para asegurarse de que el mensaje se haya recibido correctamente, y el broker no guarda el mensaje. Este nivel de QoS también puede referirse como como máximo una vez, QoS0 o 'fire and forget'.

  • El segundo nivel de QoS es el servicio con acuse de recibo. Este nivel de QoS utiliza una secuencia de paquetes PUBLISH/PUBACK entre el publicador y su broker, así como entre el broker y los suscriptores. Un paquete de acuse de recibo verifica que el contenido ha sido recibido, y un mecanismo de reintento enviará el contenido original de nuevo si no se recibe un acuse de recibo en el tiempo oportuno. Esto puede resultar en que el suscriptor reciba múltiples copias del mismo mensaje. Este nivel de QoS también puede referirse como al menos una vez o QoS1.

  • El tercer nivel de QoS es el servicio asegurado. Este nivel de QoS entrega el mensaje con dos pares de paquetes. El primer par se llama PUBLISH/PUBREC, y el segundo par se llama PUBREL/PUBCOMP. Los dos pares garantizan que, independientemente del número de reintentos, el mensaje solo se entregará una vez. Este nivel de QoS también puede referirse como exactamente una vez o QoS2.

QoS MQTT

Ventajas y desventajas

Ventajas:

  • MQTT es agnóstico respecto al paquete. La carga útil del protocolo MQTT puede transportar cualquier tipo de datos, como binarios, texto ASCII, etc. El receptor necesita interpretar y decodificar según el formato utilizado por el transmisor.

  • Utiliza paquetes de pequeño tamaño y puede usarse para aplicaciones de bajo ancho de banda.

  • Ofrece menor consumo de energía de la batería.

  • Es un protocolo fiable ya que utiliza opciones de QoS para proporcionar entrega garantizada.

  • Debido a su modelo de publicar/suscribirse, es escalable.

  • Ofrece un diseño desacoplado, ya que es fácil desacoplar el dispositivo y el servidor. Ideal para comunicaciones distribuidas de uno a muchos y aplicaciones separadas.

  • Un dispositivo publicador puede enviar datos al servidor en cualquier momento independientemente de su estado.

  • Equipado con la función LWT (Last Will and Testament) para notificar a las partes sobre una desconexión anormal del cliente.

  • Se apoya en TCP/IP para tareas básicas de comunicación.

  • Diseñado para entregar mensajes según las plantillas "máximo una vez", "mínimo una vez" y "exactamente una vez".

Desventajas:

  • MQTT no puede soportar la transmisión de vídeo.

  • Problemas con la latencia.

  • La seguridad no está integrada. MQTT no está cifrado. En su lugar, utiliza TLS/SSL (Transport Layer Security/Secure Sockets Layer) para el cifrado de seguridad.

  • Un broker centralizado puede ser un punto de fallo ya que las conexiones de los clientes con los brokers están abiertas todo el tiempo.

  • No soporta funciones avanzadas como el control de flujo.

Dónde se puede usar MQTT

Como las aplicaciones IoT ahora se están implementando a gran escala, MQTT ha llegado al primer plano como una forma abierta, sencilla y escalable de desplegar computación distribuida y funcionalidad IoT a una base de usuarios más amplia — tanto en los mercados de consumo como en los industriales.

  • Gestión de flotas. Las organizaciones están utilizando MQTT para construir sistemas de gestión de flotas más inteligentes que mejoren la optimización de la flota, la seguridad del conductor y reduzcan los costos de combustible. Nuevos modos de transporte que emplean drones también están cambiando la forma en que movemos mercancías. La conectividad entre un dispositivo móvil usado por el operador, la telemetría directa desde el vehículo y la integración en sistemas back-end de programación y enrutamiento proporciona la visibilidad requerida para mejorar la operación general de la flota.

  • Datos de sensores ambientales. MQTT admite el modelo de entrega de mensajes "no más de una vez". En redes con cobertura parcial del territorio o alta latencia, esto significa que la información puede perderse o duplicarse. En áreas donde los sensores remotos registran y transmiten datos a intervalos especificados, esto no es un problema, ya que se reciben nuevas lecturas de forma regular. Los sensores en entornos remotos suelen ser dispositivos de baja potencia, lo que convierte a MQTT en una solución ideal para sensores IoT con una prioridad de transferencia de datos relativamente baja.

  • Datos de salud de la máquina: para responder rápidamente a problemas emergentes y prevenir tiempos de inactividad. Por ejemplo, para una planta eólica, se necesita la entrega garantizada de los indicadores de rendimiento actuales a los equipos locales incluso antes de que esta información llegue al centro de procesamiento de datos. En tales situaciones, la entrega de mensajes "al menos una vez" garantiza que las banderas apropiadas serán detectadas por los especialistas necesarios de manera oportuna, incluso si llegan como duplicados. Esto es importante para la comunicación máquina a máquina con mayor prioridad.

  • Sistemas de facturación: existen mensajes aún más prioritarios y precisos que deben manejarse correctamente. En situaciones empresariales donde la duplicación de registros es inaceptable, incluso en sistemas de facturación, la bandera QoS de transmisión "exactamente una vez" es útil. Esto elimina la duplicación o pérdida de paquetes en facturación o sistemas de cobro, reduce el número de anomalías y contradicciones innecesarias en el acuerdo.

  • Aplicaciones de mensajería basadas en texto para comunicación en tiempo real que aprovechan el bajo uso de datos y energía de MQTT. Por ejemplo, Facebook usa MQTT para su aplicación Messenger, no solo porque el protocolo conserva la batería durante la mensajería de teléfono a teléfono, sino también porque el protocolo permite que los mensajes se entreguen de manera eficiente en milisegundos, a pesar de conexiones a internet inconsistentes en todo el mundo.

Dispositivos MQTT compatibles con Navixy

  • Xirgo Global FMS500 Light MQTT (IOTM

  • Xirgo Global FMS500 Light+ MQTT (IOTM)

  • Xirgo Global FMS500 StCAN MQTT (IOTM)

  • BCE FMS500 Light MQTT (IOTM)

  • BCE FMS500 Light+ MQTT (IOTM)

  • BCE FMS500 StCAN MQTT (IOTM)

  • GlobalmatiX xTCU

Cómo configurar dispositivos MQTT para trabajar con Navixy

Configuración de dispositivos Xirgo & BCE MQTT

Para configurar el dispositivo Xirgo & BCE para trabajar con MQTT:

  • Dentro de FMSET: elija Conectividad → Telemetry server → MQTT broker address settings) especifique host: mqtt.eu.navixy.com para servidor EU y mqtt.us.navixy.com para servidor US, puerto 1883.

  • Y agregue el usuario predeterminado en MQTT Security -> Authorization MQTT device configuration

Configuración del dispositivo Globalmatix MQTT

Para configurar el dispositivo Globalmatix para trabajar con MQTT:

Para configurar el dispositivo Globalmatix para trabajar con MQTTS:

AnteriorConectividadSiguienteSensores del vehículo

Última actualización

¿Te fue útil?