Backhaul LoRaWAN: comparación de UDP, MQTT y Basic Station

Nota de la serie: esta es la parte 9 de la serie de análisis técnico profundo de LoRaWAN de ManThink. Leer las ocho partes anteriores en orden le dará el contexto más completo.

Por qué importa la última milla

En cualquier despliegue de LoRaWAN, la pieza que más fácilmente se pasa por alto es la "última milla" entre la puerta de enlace LoRaWAN y el Servidor de Red LoRaWAN (LNS / NS).

El lado de radio acapara toda la atención: hemos dedicado varios artículos a los canales paralelos 16 de SX1302, a la sincronización temporal TDOA y a las ventanas de recepción RX de Clase A. Mientras tanto, la parte que realmente mueve la trama LoRaWAN desde la puerta de enlace hasta el servidor a menudo se despacha con un casual "usa el packet forwarder". Pero una vez que su despliegue escala a cientos de dispositivos, cruza una red pública o se enfrenta a requisitos de cumplimiento de seguridad, esta "última milla" se convierte en el segmento que merece el mayor escrutinio.

Este artículo pone lado a lado los tres protocolos comunes de backhaul entre puerta de enlace LoRaWAN y servidor:

• Semtech UDP Packet Forwarder — estándar de facto de primera generación, UDP sin conexión, JSON en claro
• ThinkLink MQTT Bridge — puente basado en MQTT, estilo bus de mensajes
• LoRa Basics Station — el enfoque moderno de la LoRa Alliance, WebSocket + TLS + doble canal (CUPS/LNS)

Después explicamos cuál admite una puerta de enlace de código abierto predeterminada como la ManThink GD6, por qué el "menú de protocolos" se ve distinto entre ThinkLink, ChirpStack y TTN, y cómo tomar la decisión de ingeniería correcta.

1. De dónde vino cada protocolo

1.1 Semtech UDP Packet Forwarder (2014 – presente)

Esta es la implementación de referencia de Semtech de la era SX1301. Ejecuta un demonio como poly_pkt_fwd / lora_pkt_fwd en un host Linux, enviando tramas JSON de uplink (rxpk) recibidas por el chip SX130x al LNS, y escribiendo las tramas JSON de downlink (dnmsg) devueltas por el LNS en la cola del concentrador.

• Transporte: UDP, sin conexión
• Capa de aplicación: JSON artesanal
• Puertos predeterminados: 1700 (ambas direcciones)
• Autenticación: ninguna. La implementación de referencia de Semtech no incluye TLS ni verificación de identidad de la puerta de enlace.

Su fortaleza es la simplicidad — bastan decenas de KB de RAM; se puede portar a una plataforma no estándar en horas. Para una intranet o un banco de pruebas privado, sigue siendo la solución más directa después de veinte años.

Pero los defectos son igual de fatales:

• En una red pública, el material derivado de DevAddr y NwkSKey en el paquete UDP puede ser interceptado, manipulado y reenviado.
• El servidor no puede saber si la puerta de enlace es "real". Un paquete JSON falsificado puede suplantar a cualquier puerta de enlace.
• No hay semántica de estado del enlace. Si la puerta de enlace remota está en línea, o poly_pkt_fwd está caída, solo puede deducirse a partir de marcas de tiempo de la capa de aplicación.

El repositorio oficial de Semtech lora_gateway fue el estándar de facto durante la era SX1301, pero con SX1302/SX1303 se ha marcado como NRND (Not Recommended for New Designs), y las puertas de enlace de nueva generación generalmente migran a Basic Station. ThinkLink gwTool6 Configuration Guide también marca UDP Packet Forwarder como algo "que debe usarse solo en una red controlada o con protección de red adicional".

Dato clave: UDP Packet Forwarder es no cifrado, no autenticado y sin monitoreo de estado del enlace integrado.

1.2 ThinkLink MQTT Bridge — modo bus de mensajes

MQTT Bridge no es un protocolo estándar definido por la LoRa Alliance. En cambio, es un modo de transporte entre puerta de enlace y servidor que usa temas MQTT para transportar tramas de uplink y downlink de LoRaWAN. Los mensajes LoRaWAN se asignan a mensajes MQTT, enrutados por un Broker.

En la línea de productos de ManThink, MQTT Bridge sirve principalmente a la plataforma ThinkLink. La sección 5.2 del gd6-configuration-guide lo deja explícito: ThinkLink MQTT solo está disponible con la combinación de proveedor ThinkLink, y se compone de los siguientes elementos:

¿Por qué existe esto? Porque fuera de LoRa, MQTT es la "puerta de enlace de protocolo de dispositivo" de facto — dispositivo → Broker MQTT → sistema de negocio — toda la cadena usa el mismo bus de mensajes. Trasladar este patrón a una puerta de enlace LoRaWAN significa que los equipos de ingeniería pueden usar un clúster de Broker familiar para gestionar tanto dispositivos finales LoRa como dispositivos Wi-Fi / 4G — la arquitectura se vuelve más uniforme.

Características clave de MQTT Bridge:

• Pub/Sub nativo: el uplink es un mensaje en un tema, el downlink es un mensaje en otro tema; el backhaul y los datos de negocio comparten la misma tubería.
• TLS opcional: el cifrado depende de la configuración TLS del Broker.
• Autenticación configurable: depende del mecanismo de usuario/contraseña del Broker.
• Los eventos de ciclo de vida van al bus: Device Provisioning, Status / Statistics se convierten en mensajes MQTT que los suscriptores del lado de negocio simplemente consumen.

Una nota crítica: MQTT Bridge y el canal de "configuración remota" son dos conexiones independientes. gwTool6 dedica una sección aparte a la "configuración remota", que requiere su propio Broker, Client ID, Topic y credenciales TLS, y advierte explícitamente no confundir las credenciales MQTT del canal LoRaWAN con las de configuración remota — un error común de diagnóstico en sitio.

Dato clave: MQTT Bridge es un modo de transporte, no una especificación de LoRa Alliance. Está impulsado por la plataforma del lado de ThinkLink y sirve principalmente a equipos de ingeniería que ya hablan MQTT.

1.3 LoRa Basics Station (2019 – Presente)

LoRa Basics Station fue introducido conjuntamente por Semtech y la LoRa Alliance como el "reemplazo" oficial del UDP Packet Forwarder. Lo de "Basics" en el nombre se refiere al hecho de que especifica tanto el protocolo de conexión como la implementación de referencia como una base de código abierto.

Su arquitectura consta de dos interfaces WebSocket / HTTPS separadas:

• Interfaz LNS (LoRaWAN Network Server): gestiona la transmisión de datos de negocio. La URI suele ser wss://<server-address>:8887. Todas las tramas LoRaWAN de enlace ascendente y las tramas de enlace descendente en cola fluyen a través de ella.
• Interfaz CUPS (Configuration and Update Server): gestiona la configuración y la actualización de firmware. La URI suele ser https://<server-address>:443. CUPS envía a la puerta de enlace la URI de LNS, la cadena de confianza y las credenciales de LNS — es decir, a qué NS conectarse, qué certificado usar y con qué clave de API autenticarse pueden ser controlados remotamente por el servidor.

Separar el canal de datos del canal de gestión aporta tres beneficios de ingeniería:

1. La configuración puede rotarse remotamente: sin visitas presenciales para cambiar los ajustes de la puerta de enlace;
2. Despliegue sin intervención: desde el envío de fábrica hasta la conexión a la corriente, la puerta de enlace se conecta automáticamente a CUPS y recibe automáticamente las credenciales de LNS;
3. Gestión unificada de grandes flotas de puertas de enlace: miles de puertas de enlace comparten las mismas credenciales y el mismo plan de canales.

Fundamentos de la pila de protocolos:

• Transporte: conexión persistente WebSocket; heartbeat nativo del protocolo y reconexión automática;
• Cifrado: TLS 1.2 / 1.3 (según la configuración del servidor), con soporte para TLS mutuo (mTLS);
• Modos de autenticación: certificado raíz del servidor (confianza) + token de clave de API + certificado de cliente opcional;
• Mensajes de aplicación: JSON (similar al UDP PF en algunos aspectos, pero bidireccional, con marca de tiempo y con capacidad de enviar configuración de forma activa).

Las dos referencias autorizadas:

• LoRa Basics Station LNS (oficial de TTN)
• LoRa Basics Station CUPS (oficial de TTN)

El documento práctico GW-AN08 resume perfectamente las cuatro ventajas principales: Basic Station ofrece una comunicación basada en WebSocket más eficiente, admite actualizaciones dinámicas de frecuencia (CUPS), incorpora transporte cifrado (TLS) y proporciona capacidades superiores de gestión de red y configuración remota en comparación con el tradicional UDP Packet Forwarder.

Dato clave: Basic Station es el protocolo de backhaul "moderno" recomendado por la LoRa Alliance, con WebSocket + TLS + doble canal (LNS para datos + CUPS para gestión) como núcleo.

Lleva esta guía a tu proyecto

ManThink ofrece productos IoT para conectar dispositivos, desplegar redes y trabajar con datos. Consulta estos recursos de producto junto con las recomendaciones técnicas del artículo:

GD61 Gateway LoRaWAN para interiores · ThinkLink

Conoce los productos de ManThink y consulta tu proyecto →

2. Tabla comparativa de ingeniería

Poniendo los tres protocolos uno al lado del otro, punto por punto (sintetizado a partir de recursos oficiales de Yibyte, Kerlink y la LoRa Alliance):

Nota: GD6 (gwTool6 v1.0.3) usa por defecto BasicStation CUPS bajo el proveedor TTN; Semtech UDP bajo el proveedor ChirpStack (reemplazado por BasicStation LNS); y ThinkLink MQTT o una opción determinada por la entrega bajo el proveedor ThinkLink.

3. La matriz de soporte predeterminado de las tres plataformas: una guía de campo de GD6

La página de NS de LoRaWAN en GD6 (gwTool6 v1.0.3) presenta directamente las combinaciones "proveedor × protocolo". Esta tabla es lo primero que hay que memorizar del lado de ingeniería:

Algunas reglas ocultas en esta matriz:

1. Los controladores son mutuamente excluyentes: Semtech UDP se ejecuta sobre el controlador Packet Forwarder; Basic Station LNS / CUPS se ejecuta sobre el controlador Basic Station. Ambos se almacenan en el mismo archivo de configuración. Cambiar de controlador al guardar provoca un reinicio en frío del reenvío LoRa de ~30–60 segundos. Por lo tanto, debe evitar las ventanas de OTA, de escritura de configuración y de downlink crítico.
2. ChirpStack no admite CUPS: la documentación de MCP indica explícitamente que el basicstation gateway bridge de ChirpStack solo admite basicstation-lns, no basicstation-cups. Al elegir Basic Station, solo puede seleccionar LNS.
3. CUPS anula la configuración local: el URI de LNS y las credenciales devueltas por CUPS tienen prioridad sobre lo que haya completado localmente. Al volver de CUPS a LNS directo, debe borrarse el URI de CUPS antiguo, o la puerta de enlace seguirá pasando silenciosamente por CUPS.
4. La API Key de CUPS y la API Key de LNS tienen permisos diferentes: no se pueden intercambiar en la consola de TTN.
5. Interacción entre controlador y plan de canales: en modo Basic Station, la configuración local de canales en la página "Radio Parameters" efectivamente no se aplica — el plan de canales lo envía LNS / CUPS. Solo al volver a Packet Forwarder vuelven a tener efecto los ajustes locales de canales.
6. mTLS solo cuando se requiere explícitamente: la mayoría de los despliegues en la nube de TTN usan solo TLS de servidor + API Key, sin necesidad de certificado de cliente.

Dato clave: el menú de protocolos y el comportamiento predeterminado difieren entre las tres plataformas en GD6 — esta es la trampa en sitio que reitera cada documento de integración.

4. Árbol de decisión de selección

Un flujo de decisión de "tres pasos" que puede recorrer:

Paso 1: Determinar la escala de despliegue y la exposición

• Exposición a red pública → excluir UDP PF; preferir Basic Station (TLS); MQTT Broker también puede servir (según la configuración de TLS).
• Intranet total / pocos dispositivos en sitio → UDP PF sigue funcionando, costo más bajo.
• Miles de puertas de enlace bajo gestión unificada → preferir firmemente Basic Station + CUPS.

Paso 2: Verificar el soporte de la plataforma

• TTN / The Things Stack → recomendar Basic Station (CUPS preferido, LNS como alternativa).
• ChirpStack → recomendar Basic Station LNS (CUPS no disponible, aplica a todas las versiones).
• Plataforma ThinkLink / clúster privado sobre MQTT → MQTT Bridge es una opción más "a medida".
• Coexistencia multiplataforma / NS heterogéneo → tener en cuenta la exclusión mutua de controladores: GD6 solo puede ejecutar un controlador a la vez. El cambio necesita una ventana de reinicio en frío de 30–60 segundos.

Paso 3: Considerar operaciones y cumplimiento

• Se requiere auditoría de cumplimiento → Basic Station o MQTT con mTLS es obligatorio.
• Se requiere aprovisionamiento masivo sin intervención → Basic Station + CUPS es esencialmente la única opción.
• El equipo de operaciones está familiarizado con el ecosistema MQTT → MQTT Bridge es natural.
• Desea conservar la experiencia de depuración "antigua" (dependencias mínimas, transparente) → UDP PF sigue funcionando, pero nunca lo exponga a la red pública.

Regla mnemotécnica rápida:

¿Pruebas en intranet? UDP. ¿Despliegue en producción? Basic Station. ¿La plataforma consume MQTT? Bridge.

5. Detalles de ingeniería de Basic Station: 5 Cosas que debe saber

Si finalmente elige Basic Station, los siguientes cinco puntos son trampas que casi con certeza encontrará.

5.1 wss, no ws

El URI del LNS debe comenzar por wss:// (producción); el URI del CUPS debe comenzar por https://. Esto significa:

• El certificado raíz del servidor (trust) debe coincidir con el nombre de dominio — los certificados públicos como Let's Encrypt pueden omitir la autoconfianza.
• La hora del sistema de la puerta de enlace debe ser fiable — el handshake TLS valida el periodo de validez del certificado. Con unas horas de desfase, todo falla.
• El DNS debe poder resolver la Server Address.

5.2 API Key + CRLF es obligatorio

El campo trust y el campo Token Key en gwTool6 se almacenan por separado. El Token Key debe ensamblarse en una línea HTTP completa Authorization línea, terminada con CRLF (\r\n) — si falta un retorno de carro, TLS pasa pero 401 persiste.

Las dos claves para CUPS y LNS tienen permisos diferentes y no se pueden intercambiar:

• LNS Key: solo concede Link as Gateway to a Gateway Server for traffic exchange.
• CUPS Key: requiere permisos para ver la información de la puerta de enlace, editar la configuración básica de la puerta de enlace y leer el Secret.

5.3 CUPS "sobrescribirá" la configuración local

Una vez que CUPS se conecta correctamente, el URI del LNS + las credenciales + el plan de canales que envía sobrescriben los valores que guardó localmente. Al volver de CUPS a LNS, el URI antiguo de CUPS debe borrarse activamente — esta es la causa raíz de la trampa "cambiar a LNS directo pero seguir pasando por CUPS" advertida explícitamente en la documentación de gwTool6.

5.4 mTLS solo cuando sea realmente necesario

mTLS (TLS mutuo) significa que cada puerta de enlace necesita:

• Un certificado de cliente firmado para ella;
• La clave privada del cliente importada en la puerta de enlace (CN establecido al EUI de la puerta de enlace en hexadecimal);
• Que el servidor confíe en la misma CA y valide el ID del certificado de cliente.

Uso adecuado: en una red industrial altamente controlada o en plataformas que exigen mTLS (p. ej., AWS IoT Core for LoRaWAN). La mayoría de los despliegues públicos de TTN / ChirpStack usan solo TLS simple + Token. No habilite mTLS solo "por parecer más seguro" — solo añade coste operativo; no hace que los datos en sí sean más confidenciales.

5.5 El cambio de driver es un reinicio en frío

Tras guardar la elección de protocolo, gwTool6 realiza un reinicio en frío del reenvío LoRa durante ~30–60 segundos. Esto significa:

• No cambie durante ventanas de OTA / downlink críticas.
• Tras el cambio, vuelva a leer la configuración para confirmar que surtió efecto (capturas de pantalla / registros, ambos sirven). No confíe solo en que la página muestre "guardado correctamente".
• Si ve "configuración aplicada pero cero uplinks", espere 60 segundos antes de seguir solucionando problemas.

6. Experiencia de campo con MQTT Bridge

MQTT Bridge, a diferencia de Basic Station, no está tan "estandarizado", pero si despliega la plataforma ThinkLink, no puede evitarlo. Algunos principios:

• El Topic es el contrato. Cada puerta de enlace / cada aplicación tiene su prefijo de Topic acordado. Cambiar las rutas de Topic arbitrariamente envía mensajes al vacío.
• El material TLS es un conjunto. CA, certificado de cliente y clave de cliente — los tres deben coincidir; si falta uno, el Broker rechaza la conexión.
• La configuración remota es una línea distinta. "Configuración remota" y "datos LoRaWAN" usan dos Brokers, Client IDs, Topics y credenciales TLS separados. No comparta credenciales por comodidad, o un mal envío de configuración remota afectará al negocio LoRa.
• El Client ID debe ser único a nivel global. Los Client IDs duplicados provocan la expulsión por parte del Broker, causando el bucle ocasional de "latido-perder conexión-reconectar-expulsado de nuevo".
• Elección de QoS: Uplink / Downlink usan QoS 1 o 2; Status usa QoS 0 — poner todo en QoS 2 eleva significativamente la carga del Broker.

7. ¿Sigue siendo útil UDP Packet Forwarder?

Sí, en escenarios limitados:

• Red controlada / banco de pruebas: laboratorio, línea de producción, entorno de I+D.
• Plataformas existentes que solo aceptan UDP: NS heredados / lastre histórico de plataformas propietarias.
• Recursos extremadamente limitados: puertas de enlace a batería, puertas de enlace pequeñas del lado del sensor a escala reducida con reenvío Wi-Fi/4G.

No recomendado para:

• Cualquier despliegue que cruce una red pública, NAT o red multiinquilino.
• Cualquier despliegue que implique cargas de trabajo reales de negocio (especialmente con requisitos de facturación / cumplimiento / auditoría).
• Despliegues que carezcan de mecanismos de verificación de identidad de la puerta de enlace.

GD6 aún conserva la opción UDP PF, principalmente para: integración con plataformas heredadas, integración con NS propietarios de desarrollo propio, integración con escenarios de enseñanza / demostración.

Dato clave: UDP PF ha degenerado ahora en un "protocolo de reserva para intranet" — el despliegue en producción usa por defecto Basic Station (red pública) o MQTT Bridge (ecosistema ThinkLink).

8. Ruta de migración: de UDP PF a Basic Station

Si su red heredada aún usa UDP PF, la ruta de migración recomendada es:

1. Fase de coexistencia: primero deshabilite todo downlink en GD6 y habilite solo pruebas de uplink. Basic Station y UDP PF son mutuamente excluyentes a nivel de driver en GD6, así que solo puede "cambiar y luego volver a cambiar".
2. Paralelismo de doble protocolo: típico de ChirpStack — UDP PF para enlaces heredados, Basic Station LNS para enlaces nuevos, dos Bridges coexistiendo.
3. CUPS asume la configuración masiva: tras pasar a Basic Station, no dejes que el personal de operaciones rellene el URI del LNS uno por uno manualmente — configura CUPS y deja que el servidor lo empuje todo automáticamente.
4. Plan de rotación de credenciales: establece periodos de validez para las API Keys / certificados de cliente del LNS y rótalos con regularidad.
5. Plan de respaldo: mantén 1–2 gateways de respaldo con UDP PF, por si falla Basic Station.

Toda la migración suele llevar de 1 a 2 semanas — siempre que ya hayas preparado las «ventanas de mantenimiento» y la «gestión de credenciales».

9. Guía rápida de selección

10. Conceptos erróneos habituales

Por último, aquí van varias afirmaciones «dadas por sentadas» que reaparecen en los sitios de ingeniería:

1. «Basic Station no va cifrado» — Falso. Basic Station usa TLS por defecto. Que esté cifrado depende de si el URI usa wss:// o ws://, y de que el lado del servidor LNS lo imponga.
2. «UDP Packet Forwarder no tiene usuarios en 2026» — También falso. La docencia, el I+D y los despliegues en intranet lo siguen usando a escala.
3. «MQTT Bridge es solo trastear con Topics» — Eso es solo la punta del iceberg. MQTT Bridge en ThinkLink incluye TLS, credenciales y enrutamiento multi-Topic — un modo de integración completo de nivel ingeniería.
4. «CUPS parece complejo, así que sáltalo a pequeña escala» — CUPS realmente no es necesario por debajo de 5 gateways. Pero cuando operaciones empieza a quejarse de «por qué tengo que configurar manualmente cada gateway nuevo», es momento de incorporar CUPS.
5. «Basic Station equivale a la versión gratuita» — Falso. Basic Station es una especificación de protocolo introducida por la LoRa Alliance, con Semtech proporcionando una implementación de referencia de código abierto. TTN, ChirpStack, AWS IoT Core for LoRaWAN, etc. implementan todos la especificación en su lado servidor.
6. «Cambiar de protocolo es solo cambiar un desplegable» — Falso. En GD6, cambiar de protocolo provoca un reinicio en frío del reenvío LoRa de 30–60 segundos. No cambies durante ventanas de negocio críticas.

Reflexiones finales

Diseñar correctamente el protocolo de «última milla» entre el gateway y el LNS determina la operabilidad y la escalabilidad de toda la red LoRaWAN. Semtech UDP PF es el «de menor coste», MQTT Bridge es el «adaptado a la plataforma» y Basic Station es el «a largo plazo» — los tres son respuestas razonables en sus respectivos escenarios.

El gateway de código abierto GD6 admite los tres protocolos de forma nativa, y el menú de protocolos de gwTool6 recomienda automáticamente una combinación por plataforma. Los proyectos nuevos deberían seguir el patrón de Basic Station + LNS (producción) + UDP PF (experimentación) desde el primer día; los proyectos heredados deberían migrar de forma constante usando el patrón de «coexistir → cambiar → retirar».

Documentación de referencia

• ManThink · Guía de configuración de gwTool6
• ManThink · Conexión de gateways gwTool6 a TTN mediante Basic Station
• ManThink · Conexión de gateways gwTool6 a ChirpStack mediante Basic Station
• LoRa Alliance · LoRa Basics Station Specification (referenciada a través de la documentación oficial de TTN)
• The Things Stack · Referencia de LNS
• The Things Stack · Referencia de CUPS
• Kerlink · Documentación de Basic Station Packet Forwarder

Lecturas de la serie

1. Unión de dispositivos LoRaWAN: OTAA vs ABP — ¿Cómo elegir?
2. Entender el mecanismo ADR de LoRaWAN: quién controla la tasa de datos
3. Parámetros regionales de LoRaWAN: por qué CN470 y EU868 tienen distinto número de canales
4. Parámetros de la capa física LoRa: cómo SF, BW y CR afectan al alcance y al rendimiento
5. Clases de dispositivo LoRaWAN (Class A / B / C) comparadas: compensaciones y casos de uso
6. Semtech SX1301 vs SX1302 vs SX1303: la evolución del chip concentrador
7. ESP32-S3 en gateways IoT: por qué lo elegimos frente a STM32
8. Fundamentos de geolocalización LoRa: TDOA vs RSSI comparados
9. Este artículo: Protocolos de backhaul de gateways LoRaWAN: Semtech UDP / MQTT Bridge / Basic Station comparados

Esta serie está elaborada por el equipo de ManThink a partir de gwTool6 v1.0.3 + LoRa Alliance + recursos oficiales de Semtech.