Tech Insights

Network server LoRaWAN vs plataforma de aplicaciones IoT: qué hace cada uno en realidad

Un network server LoRaWAN mueve paquetes; una plataforma de aplicaciones IoT los convierte en dashboards, alertas, predicciones y aplicaciones. Qué hace cada capa, por qué necesitas las dos y cómo se conectan.

Thiago Lima ·
Network server LoRaWAN vs plataforma de aplicaciones IoT: qué hace cada uno en realidad

Todo proyecto LoRaWAN se topa con la misma confusión en la primera semana. El equipo levanta un network server, ve llegar los datos del dispositivo y pregunta por qué sigue necesitando otra plataforma. O bien contrata una plataforma de aplicaciones, registra un sensor y pregunta por qué no aparece nada. Las dos preguntas tienen la misma respuesta: los despliegues LoRaWAN corren sobre dos capas distintas que a menudo se confunden con una sola, y cada una hace un trabajo que la otra deliberadamente no hace.

Acertar con ese reparto ahorra semanas. Lo que sigue es qué posee cada capa, dónde está la frontera y cómo se conectan las dos en la práctica.

La pila LoRaWAN de dos capas, con el network server abajo y la plataforma de aplicaciones arriba

Qué posee el network server

Un network server LoRaWAN (LNS) es gestión de infraestructura de radio. Autentica dispositivos cuando se unen a la red, elimina duplicados del mismo paquete que llega por varios gateways, programa los downlinks por el mejor gateway, gestiona la tasa de datos adaptativa para conservar batería y aplica la capa MAC de LoRaWAN. ChirpStack, The Things Stack y los servidores operados por operadoras como Actility viven todos aquí, y comparamos las opciones públicas y privadas en redes LoRaWAN privadas vs públicas.

Lo que el LNS te entrega al final de todo ese trabajo es un payload descifrado: unas cuantas decenas de bytes binarios, más metadatos de radio. Sin dashboards, sin usuarios, sin alertas, sin un histórico que merezca consultarse. Eso no es una carencia del producto. Es su diseño.

Qué posee la plataforma de aplicaciones

Una plataforma de aplicaciones IoT empieza donde el paquete deja de importar y empiezan los datos. Decodifica el payload binario en variables con nombre, las almacena como series temporales consultables y las convierte en lo que la gente compra de verdad: dashboards, alertas, cuentas de usuario con permisos, informes e integraciones con el resto del negocio.

La capa que cada vez más separa a unas plataformas de aplicaciones de otras es la inteligencia. Guardar una lectura de temperatura es lo mínimo. Predecir dónde estará en seis horas, señalar que un sensor empezó a desviarse dos días antes de fallar y convertir una predicción en una orden de trabajo: ahí se concentra el valor. TagoIO lo hace con scripts de Analysis y Analytics e IA integrados, así que predicciones, marcas de anomalía y recomendaciones aparecen dentro de la misma interfaz que los datos en vivo, en lugar de en una herramienta de BI aparte que alguien tiene que acordarse de abrir.

Una vista solo con dashboard junto a otra donde la capa de analytics añade predicciones, marcas de anomalía y recomendaciones

La frontera en una frase

El network server se asegura de que el paquete llegue una vez, de forma segura y eficiente. La plataforma de aplicaciones hace que el paquete signifique algo para una persona u otro sistema. Si una tarea implica radio, alta en la red, gateways o factores de dispersión, pertenece al LNS. Si implica un usuario, un gráfico, un umbral, una predicción o un ERP, pertenece a la plataforma de aplicaciones.

Confundir las capas cuesta tiempo real. Los equipos intentan construir alertas dentro de un LNS con webhooks y scripts, y acaban manteniendo una plataforma de aplicaciones frágil que nunca pretendieron escribir. O esperan que una plataforma de aplicaciones diagnostique la cobertura de los gateways, que no puede ver. Cada capa es deliberadamente ciega al trabajo de la otra.

Cómo se conectan las dos

En la práctica, la integración es un puente de datos. El LNS empuja cada uplink decodificado a la plataforma de aplicaciones por HTTPS o MQTT, y los downlinks vuelven por el mismo camino. TagoIO incluye integraciones listas para los principales network servers, entre ellos The Things Network, ChirpStack y redes de operadoras, además de una biblioteca de conectores con cientos de sensores, de modo que decodificar el payload es configuración y no código.

Una pila de producción típica acaba así: sensores, gateways, un LNS (red pública o ChirpStack privado) y TagoIO encima para todo lo que ve el cliente. La elección del LNS y la de la plataforma son decisiones independientes, lo cual es sano: puedes cambiar de operadora de red sin reconstruir tu aplicación, y al contrario.

¿Alguna vez necesitas solo una?

A veces. Un estudio puro de cobertura puede vivir solo en el LNS. Un despliegue celular o Wi-Fi se salta el LNS por completo y habla directamente con la plataforma de aplicaciones. Pero si el proyecto incluye sensores LoRaWAN y alguien que no sea un ingeniero va a mirar los datos, necesitas las dos capas, y el presupuesto honesto incluye las dos desde el principio.

Si ya tienes un LNS funcionando y quieres ver la capa de aplicaciones trabajando sobre él, TagoIO se conecta en minutos. Agenda una demo o empieza gratis.