MQTT-SN es una variante de MQTT diseñada para redes de sensores en las que TCP es demasiado pesado o directamente no está disponible. En este artículo aprenderás en qué se diferencia MQTT-SN del MQTT convencional, qué son los topic IDs, los gateways y los clientes dormidos, y cómo reenviar los dispositivos MQTT-SN a un broker estándar para que el resto de tu stack ni siquiera tenga que saber que existen.
¿Qué es MQTT-SN?
MQTT-SN significa MQTT for Sensor Networks (MQTT para redes de sensores). Lo publicaron originalmente investigadores de IBM a finales de la década de 2000 (primero como MQTT-S) para llevar el modelo publish/subscribe a redes de sensores inalámbricas como Zigbee, cuyos nodos tienen radios diminutas, baterías diminutas y ninguna pila TCP/IP. La versión más implementada es MQTT-SN 1.2; desde entonces, OASIS ha trabajado en un sucesor estandarizado.
El objetivo de diseño es sencillo: conservar el modelo de programación de MQTT (topics, publicar, suscribirse, QoS) pero eliminar todo lo que resulta caro en un enlace limitado. MQTT-SN no requiere un transporte orientado a conexión. Funciona sobre UDP y sobre redes de datagramas no IP, como Zigbee o capas mesh basadas en BLE, siempre que la red pueda entregar datagramas con dirección.
La consecuencia importante: un cliente MQTT-SN no puede hablar directamente con un broker MQTT normal. Necesita un gateway que hable MQTT-SN por un lado y MQTT sobre TCP por el otro.
MQTT-SN vs. MQTT de un vistazo
| Característica | MQTT (3.1.1 / 5.0) | MQTT-SN 1.2 |
|---|---|---|
| Transporte | TCP, TLS, WebSocket | UDP u otras redes de datagramas |
| Topic en PUBLISH | Cadena UTF-8 completa | Topic ID de 2 bytes o nombre corto de 2 caracteres |
| Descubrimiento de gateway | No aplica | ADVERTISE, SEARCHGW, GWINFO |
| Clientes dormidos | No incluido | Estados ASLEEP y AWAKE con buffer |
| Niveles de QoS | 0, 1, 2 | 0, 1, 2 y QoS -1 (publicar sin conectarse) |
| Configuración del mensaje Will | Dentro de CONNECT | Intercambios separados WILLTOPIC y WILLMSG |
| Seguridad | TLS y autenticación | Se delega en la capa de red o en DTLS |
Topic IDs: ahorrar bytes en cada publicación
Un topic como factory/izmir/hall2/line4/temperature cuesta decenas de bytes en cada paquete PUBLISH. En un enlace donde una trama entera puede transportar unos cien bytes, eso es inaceptable. MQTT-SN sustituye la cadena por un número de dos bytes.
Hay tres formas de obtenerlo:
- Topic IDs registrados. El cliente envía
REGISTERcon el nombre completo del topic; el gateway responde conREGACK, que contiene un ID. A partir de ahí, el cliente publica con ese ID. Las asignaciones duran lo que dura la sesión. - Topic IDs predefinidos. El cliente y el gateway acuerdan los IDs de antemano mediante configuración, así que no hace falta registro. Es la opción más eficiente para firmware fijo.
- Nombres de topic cortos. Exactamente dos caracteres, como
t1, transportados directamente en el campo del ID.
Cuando un cliente se suscribe con un nombre de topic completo, el gateway le devuelve el ID que usará al reenviarle los mensajes que coincidan. Se admiten suscripciones con comodines, pero entonces el gateway tiene que registrar cada topic concreto con el cliente antes de entregarlo, lo que añade viajes de ida y vuelta.
Gateways y forwarders
El gateway es el corazón de cualquier despliegue MQTT-SN. La especificación describe dos estilos:
- Gateway transparente. Por cada cliente MQTT-SN, el gateway abre una conexión MQTT independiente con el broker. Es sencillo y respeta la semántica por cliente, pero el broker ve tantas conexiones como sensores tengas.
- Gateway agregador. El gateway mantiene una única conexión MQTT con el broker y multiplexa sobre ella todo el tráfico de los sensores. Menos conexiones en el broker, más lógica en el gateway.
Un forwarder es un nodo aún más simple que se limita a encapsular los mensajes MQTT-SN y retransmitirlos entre los clientes y un gateway sin interpretarlos; resulta útil cuando los clientes están a varios saltos de radio.
Los gateways se anuncian con mensajes ADVERTISE periódicos. Un cliente que no haya recibido ninguno puede difundir SEARCHGW, y los gateways (u otros clientes que conozcan uno) responden con GWINFO.
Clientes dormidos
Los sensores alimentados por batería pasan la mayor parte de su vida con la radio apagada. MQTT-SN lo modela de forma explícita:
- El cliente envía
DISCONNECTcon una duración de sueño y entra en el estado dormido. - Mientras duerme, el gateway almacena en buffer los mensajes dirigidos a él.
- El cliente se despierta, envía
PINGREQcon su client ID, recibe los mensajes almacenados y obtienePINGRESPcuando el buffer queda vacío. - Vuelve a dormirse.
MQTT convencional no tiene nada equivalente: un dispositivo que pierde su conexión TCP simplemente está offline, y solo las sesiones persistentes en el broker pueden guardarle mensajes.
QoS -1: publicar sin conexión
MQTT-SN añade un nivel que a veces se escribe como QoS -1 (o QoS 3 en borradores posteriores). Un cliente puede enviar un PUBLISH a la dirección de un gateway conocido usando un topic ID predefinido o un nombre corto sin llegar a conectarse nunca. No hay confirmación ni sesión. Es ideal para balizas muy sencillas que se limitan a emitir un valor cada pocos minutos.
Reenviar MQTT-SN a un broker MQTT estándar
Como el gateway convierte MQTT-SN en MQTT convencional, en el lado de la nube puede haber cualquier broker que cumpla el estándar. Una opción open source habitual es el Eclipse Paho MQTT-SN Gateway (del proyecto paho.mqtt-sn.embedded-c), que se ejecuta en Linux, escucha MQTT-SN por UDP y se conecta a un broker superior.
Una configuración que apunta el gateway a un broker MQTT gestionado como ConnectMQ tiene más o menos este aspecto. Los nombres de las claves proceden del gateway.conf de ejemplo del gateway; revisa el README de la versión que compiles, porque las opciones cambian entre versiones.
# gateway.conf (Paho MQTT-SN Gateway, extracto)
GatewayID=1
GatewayName=site1-mqttsn-gw
KeepAlive=60
# Broker MQTT superior (ConnectMQ, TLS)
BrokerName=broker.connectmq.com
BrokerPortNo=1883
BrokerSecurePortNo=8883
LoginID=YOUR_USERNAME
Password=YOUR_PASSWORD
# Una sola conexión TLS para todos los sensores
AggregatingGateway=YES
TransparentGateway=NO
# Lado MQTT-SN: listener UDP para los sensores
GatewayPortNo=10000
MulticastIP=225.1.1.1
MulticastPortNo=1883
Hay dos cosas a vigilar específicamente en ConnectMQ:
- Los client IDs están vinculados a las credenciales. Cada conjunto de credenciales del broker incluye su propio client ID, así que un gateway transparente que abre una conexión superior por sensor necesita un conjunto de credenciales por sensor. Un gateway agregador con una única identidad superior suele encajar mejor.
- Cuotas de conexiones. El plan Serverless gratuito permite hasta 25 conexiones y el plan Serverless de pago hasta 1.000. La agregación te mantiene holgadamente dentro de esos límites incluso con grandes redes de sensores.
Verifica el lado de la nube
Con el gateway en marcha, suscríbete desde un portátil para ver cómo llegan los datos de los sensores como MQTT normal. Durante una prueba de concepto puedes apuntar el gateway al servidor MQTT público gratuito (anónimo, puerto 1883, prefijo de topic único):
mosquitto_sub -h broker.connectmq.com -p 1883 -i mqttsn-check-4d1e \
-t "connectmq/demo/4d1e/#" -v
Con credenciales de producción, añade -p 8883 --capath /etc/ssl/certs -u YOUR_USERNAME -P YOUR_PASSWORD y el client ID del portal. Todo lo que hay aguas abajo (dashboards, flujos de Node-RED, historians) consume los datos exactamente igual que si los sensores hablaran MQTT de forma nativa.
Cuándo elegir MQTT-SN (y cuándo no)
Repasa esta lista antes de comprometerte:
- ¿El dispositivo tiene una pila IP con TCP? Si tiene Wi-Fi o conectividad celular con TCP, MQTT sobre TLS es más sencillo y tiene mejor soporte. El tutorial de MQTT con ESP32 es un buen ejemplo.
- ¿La radio solo admite datagramas? Zigbee, 6LoWPAN, enlaces en bruto tipo LoRa o radios sub-GHz propias son terreno natural para MQTT-SN.
- ¿La duración de la batería es la principal limitación? Los clientes dormidos y los topic IDs compensan cuando cada byte transmitido cuesta energía.
- ¿Puedes operar y asegurar un gateway? El gateway se convierte en un componente crítico. Planifica su monitorización, sus reinicios y sus credenciales superiores.
- ¿Y la seguridad? MQTT-SN no incluye cifrado. Recurre a la seguridad de la capa de enlace o a DTLS en el lado de los sensores, y a TLS en el tramo del gateway al broker.
- Disponibilidad de bibliotecas. Existen bibliotecas cliente para C y plataformas embebidas, pero el ecosistema es mucho más pequeño que el de MQTT.
En muchos proyectos lo mejor es un enfoque híbrido: los nodos limitados hablan MQTT-SN con un gateway local, mientras que todo lo demás, incluido el enlace superior del gateway, habla MQTT estándar. Si todavía estás aprendiendo el protocolo base, empieza por el tutorial de MQTT y la explicación de si MQTT usa TCP o UDP.
Errores habituales con MQTT-SN
- Desfase de topic IDs. Los IDs registrados son por sesión. Tras reiniciarse el gateway, los clientes deben volver a registrarse o publicarán en el topic equivocado. Los IDs predefinidos evitan esto, pero hay que mantenerlos sincronizados entre el firmware y la configuración del gateway.
- Pérdida de paquetes UDP. QoS 0 sobre UDP puede perder datos de verdad. Usa QoS 1 para todo lo que importe y ajusta los temporizadores de reintento a tu radio.
- Fragmentación. Mantén los payloads pequeños; los mensajes MQTT-SN están pensados para caber en una sola trama de red.
- El gateway como punto único de fallo. Si el gateway cae, los sensores no almacenan nada. Diséñalo para reinicios rápidos y con alertas.
Lleva tu red de sensores a ConnectMQ
El gateway es tuyo; el broker no tiene por qué serlo. ConnectMQ ofrece a tu gateway MQTT-SN un endpoint TLS en el 8883, soporte para MQTT 3.1.1 y 5.0 y un explorador de topics en vivo para confirmar que los datos fluyen. Crea un broker Serverless gratuito en app.connectmq.com sin tarjeta de crédito, copia las credenciales generadas en la configuración de tu gateway y tus sensores estarán en la nube.
Preguntas frecuentes
¿Puede un cliente MQTT-SN conectarse directamente a un broker MQTT?
No a uno estándar. MQTT-SN usa un formato de paquete y un transporte distintos, así que un gateway debe traducirlo a MQTT sobre TCP para el broker.
¿MQTT-SN admite QoS 2?
Sí. MQTT-SN 1.2 admite QoS 0, 1 y 2, además del modo QoS -1 sin conexión para publicadores sencillos.
¿Es seguro MQTT-SN?
El protocolo en sí no incluye cifrado. Usa seguridad de capa de enlace o DTLS entre los sensores y el gateway, y TLS entre el gateway y el broker.
¿Qué puerto usa MQTT-SN?
No hay un único puerto registrado; depende de la configuración del gateway. Muchos ejemplos usan un puerto UDP como el 10000 o reutilizan el 1883 sobre UDP.
