Un gateway LoRaWAN recibe la señal de radio de un nodo, pero no sabe qué hacer con ella: no valida si el paquete es legítimo, no sabe a qué aplicación pertenece ni puede decidir si el dispositivo necesita cambiar su velocidad de transmisión. Esa inteligencia vive en el network server, la pieza de software que convierte tramas LoRa crudas en datos utilizables y que la mayoría de despliegues en Ecuador delega en una de dos opciones: ChirpStack, autoalojado, o The Things Stack (TTN), en la nube.
Qué hace exactamente un network server
En la arquitectura LoRaWAN, los gateways actúan como puentes transparentes: escuchan todas las tramas en su radio y las reenvían por IP (normalmente vía MQTT, sobre el protocolo Semtech UDP Packet Forwarder o Basics Station) al network server, sin decidir nada sobre su contenido. El network server es quien:
- Deduplica la trama cuando varios gateways cercanos la reciben a la vez, y decide con cuál responder en el downlink según la mejor relación señal-ruido (RSSI/SNR).
- Verifica el MIC (Message Integrity Code) de 4 bytes de cada paquete contra la NwkSKey del dispositivo, descartando tramas corruptas o falsificadas.
- Gestiona el proceso de join cuando un nodo se activa por OTAA, validando el DevNonce y coordinando con el join server la entrega del DevAddr.
- Aplica ADR (Adaptive Data Rate): ajusta automáticamente el spreading factor y la potencia de transmisión de cada nodo fijo según la calidad de enlace reportada, para maximizar batería sin sacrificar cobertura.
- Controla el duty cycle y las ventanas de recepción RX1/RX2, y encola los downlinks respetando esos tiempos.
La especificación LoRaWAN separa conceptualmente tres roles —network server, join server y application server, definidos en el LoRaWAN Backend Interfaces—, pero en la práctica casi ninguna plataforma los expone como tres servicios independientes para un usuario final. ChirpStack v4, por ejemplo, fusionó network server y application server en un solo componente, dejando el join server como pieza separable solo si se necesita interoperar con múltiples backends.
ChirpStack: la opción autoalojada
ChirpStack es una suite open source (licencia MIT) que se instala en un servidor propio —una VM en la nube, un servidor en sitio o incluso un Raspberry Pi para despliegues pequeños. Su arquitectura típica tiene tres piezas:
- ChirpStack Gateway Bridge: corre en el gateway o en un servidor intermedio, y traduce el protocolo del packet forwarder (UDP o Basics Station) a un formato común que publica por MQTT.
- ChirpStack (network server + application server): se suscribe a ese MQTT, procesa las tramas, gestiona los dispositivos, aplica ADR y publica los datos decodificados a las integraciones configuradas (MQTT, HTTP, InfluxDB, etc.).
- PostgreSQL + Redis: almacenan el estado de la red (dispositivos, sesiones, contadores de trama) y las colas internas.
La ventaja central de ChirpStack es el control total: no hay límites de mensajes por día, los datos nunca salen de la infraestructura del operador (relevante para camaroneras o fincas con requisitos de privacidad de datos operativos) y se puede correr en la misma región donde está el despliegue, reduciendo latencia. El costo es operativo: alguien tiene que mantener el servidor, aplicar actualizaciones y monitorear que el servicio no se caiga, porque si el network server está abajo, los nodos siguen transmitiendo pero nadie procesa esos datos.
The Things Stack (TTN): la opción gestionada
The Things Stack es la plataforma detrás de The Things Network (TTN), la red comunitaria de gateways más grande del mundo, y también existe como producto empresarial (“The Things Stack Enterprise” / Cloud) con SLA y soporte. En la capa comunitaria gratuita (TTN Community Network / Sandbox), el uso está limitado por una política de uso justo: hasta 30 segundos de tiempo de aire de uplink por dispositivo cada 24 horas y un máximo de 10 mensajes de downlink diarios, incluyendo los ACK de confirmaciones. Esos límites no aplican si se opera una red privada propia sobre The Things Stack, solo a la infraestructura comunitaria compartida.
Para un proyecto piloto o un solo gateway de prueba, TTN Community elimina por completo la necesidad de mantener servidores: se registra el gateway, se registra el dispositivo con su DevEUI/AppKey, y los datos empiezan a fluir a los pocos minutos por MQTT o webhook. El límite aparece cuando el despliegue crece: decenas de nodos con lecturas cada 5 o 10 minutos pueden acercarse al tope de tiempo de aire si se usan spreading factors altos (SF10-SF12), y ahí conviene migrar a una instancia dedicada (propia o de pago) o a ChirpStack.
Comparación rápida
| ChirpStack | The Things Stack (TTN Community) | |
|---|---|---|
| Modelo | Self-hosted, open source (MIT) | Gestionado en la nube (gratis con límites o de pago) |
| Límite de mensajes | Ninguno, depende de tu infraestructura | 30 s uplink / 10 downlink por dispositivo al día (capa gratuita) |
| Dónde viven los datos | En tu propio servidor | En la infraestructura de The Things Industries (o tu instancia propia en el plan pago) |
| Esfuerzo operativo | Alto: mantener VM, DB, actualizaciones | Bajo en capa gratuita; medio en plan empresarial propio |
| Ideal para | Producción a escala, datos sensibles, sin límites de mensajes | Pilotos, pruebas de concepto, comunidad, migración rápida |
Cómo se conecta un despliegue real de campo
En un despliegue típico de Yubox —por ejemplo, monitoreo de oxígeno disuelto en camaroneras o humedad de suelo en fincas bananeras—, el flujo es: nodo con Sensor HUB transmite en la banda AU915 (la que corresponde a Ecuador y el resto de Sudamérica, no US915), el gateway reenvía la trama por Basics Station o Semtech UDP hacia el network server elegido, y este entrega el payload decodificado a Yubox Cloud vía MQTT o HTTP para graficarlo y disparar alarmas. La elección de ChirpStack o TTN es, en ese flujo, prácticamente transparente para el usuario final del dashboard: lo que cambia es quién opera esa pieza intermedia y bajo qué límites.
Para volúmenes de producción —redes con decenas de gateways y cientos de nodos reportando cada pocos minutos— la recomendación práctica es una instancia dedicada (ChirpStack propio o The Things Stack de pago), porque el tope de 30 segundos diarios de la capa gratuita de TTN se agota rápido con varios nodos por SF10 o superior. Para un piloto de un gateway y unos pocos nodos, TTN Community sigue siendo la vía más rápida para validar un caso de uso antes de invertir en infraestructura propia.
Conclusión
El network server es la pieza que nadie ve en un despliegue LoRaWAN, pero sin ella los gateways solo acumulan ruido de radio sin sentido: es quien valida, deduplica, gestiona el join y ajusta el data rate de cada nodo. ChirpStack da control total sin límites de mensajes a cambio de mantenimiento propio; The Things Stack ofrece una vía gestionada, gratuita para pilotos y de pago para producción, a cambio de límites de uso justo en su capa comunitaria. La decisión correcta depende del tamaño del despliegue y de cuánta infraestructura está dispuesto a operar su equipo.
¿Está diseñando una red LoRaWAN y no sabe si conviene un network server propio o gestionado? Escríbanos: evaluamos el tamaño de su despliegue y le recomendamos la arquitectura correcta desde el primer gateway.