Servidor de red LoRaWAN: qué hace y cómo elegir el tuyo

Un servidor de red LoRaWANProtocoloLoRaWANLPWAN abierta de largo alcance y bajo consumoVer perfil gestiona cada mensaje de tus sensores, y el que elijas decide los costes, quién guarda las claves y hasta dónde puede crecer la red.

Pongamos el caso de Marta, que dirige una pequeña empresa integradora. Un ayuntamiento le encarga 400 contadores de agua con radio LoRaWAN que envían una lectura cada 15 minutos. El piloto funciona sobre una red comunitaria gratuita y va bien durante tres meses. Después el ayuntamiento añade contadores en el casco antiguo, donde la cobertura es débil, y empiezan a faltar lecturas.

Las lecturas se pierden por el servidor de red (network server), la pieza de la que nadie habló al principio. Una red comunitaria reparte su capacidad entre miles de usuarios y por eso limita el tiempo de emisión de cada equipo. Los contadores del borde de la cobertura necesitan transmisiones más largas y gastan ese cupo antes de mediodía.

Esta guía explica qué hace un servidor de red LoRaWAN (LNS, por sus siglas en inglés), cómo gestiona las claves y los gateways, las cinco formas de operarlo y qué preguntar antes de elegir. Está pensada para integradores y fabricantes de equipos que llevan proyectos LoRaWAN a sus clientes. Si antes quieres repasar el protocolo, empieza por qué es LoRaWAN y cómo funciona.

Qué hace un servidor de red LoRaWAN

LoRaWAN usa lo que la LoRa Alliance describe como una topología en estrella de estrellas. Los dispositivos transmiten por radio, cualquier gateway que esté al alcance recoge el mensaje y todos los gateways reenvían lo que oyen a un único servidor central por una conexión IP. Ningún dispositivo depende de un gateway concreto.

Ese diseño mantiene sencillos los dispositivos y los gateways, y concentra la inteligencia en el servidor de red. Además, el protocolo es un estándar internacional: la UIT lo aprobó en noviembre de 2021 como Recomendación ITU-T Y.4480.

Una red LoRaWAN completa tiene cinco piezas:

El trabajo detrás de cada mensaje de subida

Cuando un sensor envía una lectura, pueden oírla tres gateways. El servidor de red recibe tres copias y se queda con una. La guía de arquitectura de The Things Network lo llama deduplicación de mensajes, y es solo la primera tarea. Con cada mensaje, el LNS también:

• Comprueba el código de integridad del mensaje, para descartar tramas falsificadas o corruptas.
• Comprueba el contador de tramas, para rechazar un mensaje antiguo que alguien reenvíe.
• Registra la calidad de señal de cada gateway que oyó al dispositivo.
• Ajusta la velocidad de datos y la potencia de emisión del dispositivo mediante ADR (adaptive data rate). Un sensor cerca de un gateway puede pasar a un factor de dispersión más rápido y ahorrar batería.
• Entrega la carga útil al servidor de aplicación.

Los mensajes de bajada escasean

Enviar un mensaje a un dispositivo cuesta más que recibirlo. Un dispositivo de clase A solo escucha durante un momento después de transmitir: la primera ventana de recepción se abre alrededor de un segundo después de terminar el envío, y la segunda, un segundo más tarde. El servidor de red tiene que elegir el mejor gateway, construir la trama y entregarla dentro de esa ventana.

También tiene que respetar la normativa de radio. En Europa, la norma ETSI EN 300 220 fija límites de ciclo de trabajo por subbanda. La mayoría de los canales de 868 MHz permiten que un transmisor esté activo el 1 % del tiempo, como explica la guía sobre ciclo de trabajo. El límite también se aplica a los gateways. Un gateway que envía muchos mensajes de bajada se queda sin tiempo de emisión, así que los diseños que necesitan confirmaciones u órdenes frecuentes escalan mal en LoRaWAN.

Claves, activación y quién puede leer tus datos

El modelo de seguridad es lo más difícil de cambiar después de elegir un servidor de red LoRaWAN, así que conviene decidirlo antes de enviar el primer equipo.

Dos formas de activar un dispositivo

Un dispositivo puede entrar en la red de dos maneras:

• Activación por el aire (OTAA). El dispositivo envía una petición de unión con su DevEUI y su JoinEUI. El servidor de unión la contrasta con la clave raíz guardada para ese equipo y genera claves de sesión nuevas. Es el método recomendado.
• Activación por personalización (ABP). Las claves de sesión se graban en el dispositivo en fábrica y no hay unión. Es más sencillo, pero las claves no cambian nunca y los contadores de tramas dan problemas cuando el equipo se reinicia.

En cualquier despliegue que tenga que durar años, usa OTAA.

Las claves de sesión separan la red de los datos

Tras la unión, el dispositivo tiene dos tipos de claves de sesión. La clave de sesión de red protege la integridad de los mensajes, y la usa el servidor de red. La clave de sesión de aplicación cifra la carga útil con AES-128, y solo la tiene el lado de la aplicación.

En la práctica, quien opera el servidor de red ve los metadatos (qué equipo, cuándo, por qué gateway y con qué señal), pero no puede leer el contenido si la clave de aplicación está en otro sitio. LoRaWAN 1.1 divide todavía más las claves de red y lleva la gestión de claves raíz a un servidor de unión independiente, algo que LoRaWAN 1.0.4 también admite.

Por qué la custodia de claves afecta a tu negocio

Hazte una pregunta antes de registrar el primer dispositivo: ¿quién guarda las claves raíz? Si solo están dentro del servidor de unión de un proveedor, llevar la flota a otro servidor de red obligará a pedirle que las exporte o a reprovisionar cada equipo.

Guarda una copia de cada DevEUI, JoinEUI y clave raíz en tus propios registros, con control de acceso. Ese fichero es lo que convierte una futura migración en un cambio de configuración y no en una visita de campo. La guía de migración de plataforma IoT aplica el mismo principio a la capa de aplicación.

Cómo se comunican los gateways con el servidor de red

Un gateway es un receptor de radio con un packet forwarder: el software que pasa las tramas de radio al servidor de red por IP. Dominan dos protocolos.

El antiguo packet forwarder UDP de Semtech es sencillo y lo admite casi cualquier gateway. Envía las tramas por UDP sin autenticación ni cifrado, así que cualquiera que conozca la dirección del servidor puede hacerse pasar por un gateway. Todavía es habitual en instalaciones antiguas.

LoRa Basics Station es la opción más reciente. El gateway abre una conexión WebSocket segura con el servidor, se autentica con un certificado o un token y nunca necesita un puerto de entrada. Un protocolo complementario, CUPS, permite que el servidor envíe configuración y actualizaciones de firmware al gateway.

En despliegues nuevos, elige gateways y servidor de red que admitan Basics Station u otro protocolo autenticado. También facilita el trabajo al equipo de TI que tiene que aprobar el gateway en una red corporativa.

Planifica la conexión de salida del gateway con el mismo cuidado. Puede ir por Ethernet, red móvil, wifi o fibra. Un gateway con 4G necesita una tarifa de datos acorde con su tráfico y una alarma que avise cuando deja de reportar. Para recomendaciones de despliegue en España, consulta la guía de gateways LoRaWAN en España.

Cinco formas de operar un servidor de red LoRaWAN

Ninguna opción sirve para todos los proyectos. Deciden el tamaño, la propiedad de los datos y cuánto trabajo de operación puede asumir tu equipo.

Redes comunitarias y de operador

Las redes comunitarias son un buen sitio para aprender y probar un dispositivo, pero no están pensadas para dar un servicio comercial. La más conocida publica una política de uso justo que limita cada equipo a 30 segundos de emisión de subida y 10 mensajes de bajada al día.

Volvamos con Marta. Una lectura de 20 bytes con SF7 ocupa unos 70 milisegundos en el aire, así que un contador que envía 96 lecturas al día gasta unos siete segundos. La misma lectura con SF12, que puede necesitar un contador en el borde de la cobertura, ocupa unos 1,8 segundos. Con 96 lecturas, suma cerca de tres minutos al día, casi seis veces el cupo.

Las redes de operador dan una cobertura que no tienes que construir y tienen sentido para activos repartidos por una región. Contrasta su mapa de cobertura con tus emplazamientos reales y pregunta qué pasa cuando un equipo está en interior o bajo tierra.

LNS privado gestionado

Un LNS privado gestionado es la opción habitual en proyectos comerciales. Tú compras y colocas los gateways, y un proveedor aloja el servidor de red con un SLA. Marta pasó sus contadores a este modelo, añadió dos gateways en el casco antiguo y en una semana dejaron de faltar lecturas.

LNS propio o integrado en el gateway

Operar tu propio servidor de red, en tus servidores o en tu cuenta de nube, te da el control total de los datos y las claves. Proyectos de código abierto como ChirpStackCTérminoChirpStackChirpStack es un Network Server LoRaWAN open source para desplegar y gestionar redes LoRaWAN privadas de extremo a extremo.Ver perfil lo permiten sin pagar licencias. El coste se desplaza a la operación: parches de seguridad, copias de la base de datos, renovación de certificados y alguien que responda cuando falle de madrugada. La comparativa entre plataforma IoT on-premise y cloud también sirve aquí.

Muchos gateways traen un pequeño servidor de red dentro. Para un edificio o una finca con unas decenas de sensores, es un buen punto de partida. El límite aparece al añadir un segundo gateway, porque cada LNS integrado gestiona sus propios equipos y los dos no pueden compartirlos.

Cómo elegir un servidor de red LoRaWAN: ocho preguntas

Lleva estas preguntas a cada proveedor o proyecto de código abierto que evalúes. Anota las respuestas, porque acabarán formando parte de tu propuesta al cliente.

1. Escala. ¿Cuántos dispositivos y gateways gestiona hoy y qué hace falta para duplicarlos?
2. Versiones y regiones. ¿Qué versiones de LoRaWAN admite (1.0.2, 1.0.3, 1.0.4, 1.1) y qué planes regionales? En Europa eso significa EU868, tal como lo define el documento de parámetros regionales de la LoRa Alliance, publicado junto al resto de especificaciones técnicas de LoRaWAN.
3. Clases de dispositivo y actualizaciones de firmware. ¿Admite las clases B y C? ¿Implementa los paquetes de la LoRa Alliance para multidifusión y transporte fragmentado de datos, de los que dependen las actualizaciones de firmware por el aire (FUOTA)?
4. Custodia de claves. ¿Puedes importar y exportar las claves raíz? ¿Hay un servidor de unión independiente y quién lo opera?
5. Integraciones. ¿Cómo salen los datos del LNS: webhooks HTTP, MQTTProtocoloMQTTEl protocolo pub/sub estándar del IoTVer perfil o una API? ¿Puedes enviar mensajes de bajada por el mismo canal?
6. Multi-tenant. ¿Puedes separar clientes de forma que ninguno vea los equipos o gateways de otro?
7. Operación. ¿Qué cubre el SLA? ¿Hay supervisión de gateways con alertas cuando uno deja de reportar?
8. Coste y salida. ¿El precio va por dispositivo, por gateway o por mensaje? ¿Cuánto cuesta irse y en qué formato te entregan los datos y las claves?

La sexta pregunta es la que más pesa para un integrador. Si piensas atender a varios clientes desde una misma red, el aislamiento tiene que existir en el servidor de red y otra vez en la plataforma de aplicación. La guía de plataforma IoT white-label explica dónde suele romperse el multi-tenant.

¿Preparas un despliegue LoRaWAN para un cliente? La página de LoRaWAN muestra cómo la plataforma gestiona dispositivos, gateways y alarmas con tu propia marca.

Conectar el servidor de red LoRaWAN con tu plataforma IoT

El LNS mueve mensajes. Los paneles, las alarmas, los informes y la gestión de usuarios están en la plataforma de aplicación, así que la conexión entre ambos necesita su propio diseño.

Subidas, decodificadores y bajadas

La mayoría de servidores de red entregan los mensajes de subida de una de dos formas. Con un webhook HTTP, el LNS envía cada mensaje a una URL de la plataforma. Con una integración MQTT, la plataforma se suscribe a un tópico del broker del LNS. Si tu equipo no conoce MQTT, la guía sobre qué es un broker MQTT explica el modelo.

En los dos casos, el mensaje trae el DevEUI, el puerto, la carga útil en bytes y los metadatos de cada gateway. Decide dónde se decodifica la carga útil y hazlo en un solo sitio. Si se decodifica en el LNS y también en la plataforma, cuando cambie el firmware de un equipo tendrás dos versiones de la verdad.

Los mensajes de bajada hacen el camino inverso: la plataforma llama a la API del LNS con el DevEUI, el puerto y la carga útil, y el LNS pone el mensaje en cola para la siguiente ventana de recepción.

Un fabricante con clientes en redes distintas

La empresa de Javier fabrica sondas de humedad de suelo para explotaciones agrícolas. Sus clientes ya tienen red: una cooperativa usa un LNS gestionado, una finca grande opera su propio servidor y un distribuidor en Portugal depende de una red de operador. Pedir a cada cliente que cambie le costaría la venta.

La plataforma que eligió su equipo se conecta a varios servidores de red a la vez. Cada sonda se registra una sola vez por su DevEUI, llegue por la red que llegue. El decodificador vive en la plantilla del dispositivo, así que una actualización de firmware obliga a cambiar un solo script. Para los agrónomos, todas las sondas se ven igual en el panel.

Cómo se conecta Cloud Studio IoT

Cloud Studio IoTITérminoIoT (Internet de las cosas)El IoT (Internet of Things) es la red de objetos físicos con sensores, software y conectividad que recogen e intercambian datos y actúan de forma autónoma.Ver perfil trae integraciones listas con los servidores de red más habituales, entre ellos The Things Stack, Actility ThingPark, LORIOT, ChirpStack y Helium. La plataforma puede recibir datos de varios a la vez. Cuando más de un gateway oye a un dispositivo, registra la mejor lectura de señal, lo que ayuda a detectar problemas de cobertura. Las cargas útiles se decodifican con drivers incluidos o con scripts que puedes escribir para cualquier equipo, y los mensajes de bajada vuelven por la misma integración. Para ver qué sensores y protocolos IoT encajan en cada caso, o cómo es una red completa en una ciudad, lee la guía de LoRaWAN para ciudades inteligentes.

Lo que conviene recordar

• Un servidor de red LoRaWAN deduplica mensajes, comprueba su integridad, gestiona las velocidades de datos y programa los mensajes de bajada dentro de límites estrictos de tiempo y de ciclo de trabajo.
• La custodia de claves es la decisión más difícil de deshacer. Usa OTAA, guarda tus propios registros de identificadores y claves raíz, y pregunta cómo se exportan.
• Prefiere gateways y servidores que admitan Basics Station u otro protocolo autenticado antes que el antiguo forwarder UDP.
• Las redes comunitarias sirven para aprender y para pilotos. La mayoría de proyectos comerciales funcionan con un LNS privado gestionado, y las flotas grandes con reglas de datos estrictas pueden justificar uno propio.
• La conexión entre el LNS y la plataforma de aplicación merece su propio diseño: un solo sitio para decodificar, un camino claro para las bajadas y soporte para más de una red.

El servidor de red es solo una parte del proyecto LoRaWAN. El resto es lo que tu cliente ve cada día: paneles, alarmas, informes y una app móvil, todo con tu marca. Si tienes un proyecto LoRaWAN encima de la mesa, habla con el equipo y trae tu lista de equipos y tu plan de red. Para las opciones de colaboración, visita el programa de partners.