13 mar 21 Despliegue de un servidor LoRaWAN libre con Chirpstack basado en contenedores

Estas semanas (en parte por afición y en parte por trabajo) he seguido avanzando con mis investigaciones con tecnología IoT basada en LoRaWAN. Ya había hablado anteriormente de comunicaciones básicas LoRa, uso de una red abierta LoRaWAN como es la red TTN, pero no había tocado el tema de disponer de un servidor LoRaWAN privado. Y es aquí donde entra en acción Chirpstack. Éste es un diseño basado en software libre que proporciona la capacidad de conectar dispositivos de campo LoRa y junto con los Gateway LoRaWAN permite constituir una red privada LoRaWAN. En este contexto, ChirpStack una solución que mediante una interfaz de usuario amigable permite gestionar dispositivos, usuarios, gateways, y que proporciona una interfaz de integración que permite interactuar con terceros sistemas.

ChirpStack proporciona una serie de componentes que interactúan entre sí para proporcionar la infraestructura necesaria para recibir información de dispositivos y gateways LoRa, con el objeto de proporcionar capacidades de gestión de dichos dispositivos (por un lado) y de poner la información que envían los dispositivos a disposición de terceros sistemas para que la consuman. Esto se articula en base a los siguientes componentes:

• Dispositivos LoRa: Dispositivos de campo que envían por LoRa información de los sistemas que controlan (final de carrera, sensor de temperatura, el propio estado del dispositivo, etc…) a un Gateway, o bien que reciben información de este Gateway para realizar una acción (activar un relé, encender un led…).
• Gateway LoRaWAN: Elemento que recibe información de los dispositivos, y transforma un paquete LoRa en un paquete IP (bien TCP o UDP, aunque lo más común es lo primero), transfiriendo la información que proporciona el dispositivo hacia un servidor donde esta información es procesada. También tiene capacidad de enviar información o solicitud de acciones a los dispositivos por parte de este servidor. Junto con los dispositivos LoRa, constituyen los elementos de campo, y aunque no forman parte estrictamente hablando de ChirpStack, sí tienen una interacción muy cercana con él.
• Gateway Bridge: Es el primero de los componentes de ChirpStack, si seguimos el flujo de datos desde los dispositivos de campo hasta los servidores de computación. Su función es recibir la información de los gateways y procesarla, volcándola en un servidor MQTT de mensajería. Este bridge puede residir en el servidor donde se despliegue ChirpStack, en los propios gateways LoRa o estar instalado en un tercer componente aparte. Su función primordial, en pocas palabras, es volcar la información proveniente de la red LoRaWAN en el sistema de mensajería MQTT, donde será consumida por el resto de servicios de ChirpStack.
• Network Server: Segundo de los componentes de ChirpStack. Es el servidor de red LoRaWAN propiamente dicho. Se encarga de monitorizar el estado de la red, los dispositivos conectados a la misma, y administrar el acceso de nuevos dispositivos a la red. También se encarga, en el caso de redes con múltiples gateways, de resolver duplicidades de dispositivos (dado que un paquete enviado por un dispositivo puede ser recibido y procesado por más de un Gateway), consolidar la información, y ponerla a disposición del servidor de aplicaciones de ChirpStack. También se encarga de las siguientes funcionalidades: Autenticación de dispositivos; gestión de la capa mac LoRaWAN; gestionar el envío de mensajes desde ChirpStack a los dispositivos, haciendo uso del canal descendiente de comunicaciones.
• Application Server: Tercer componente de ChirpStack. Es corazón de la arquitectura. Permite crear “aplicaciones”, que en este contexto son grupos de dispositivos que envían una información del mismo tipo. Relaciona la información enviada por uno o varios dispositivos, almacenando un histórico, y la pone a disposición de terceros sistemas mediante diversos métodos de integración.
• Geolocation server: Componente opcional que permite dotar de mayores capacidades de geolocalización de los dispositivos, en caso de que el Gateway no proporcione esta información, o en el que queramos hacer un tratamiento personalizado de la misma.
• Broker MQTT: Utilizado como sistema de mensajería interna para el resto de componentes de ChirpStack y la comunicación con los gateways.
• Redis: Motor de base de datos en memoria, que gestiona la información que se intercambia entre los dispositivos y aplicaciones creadas en ChirpStack.
• Base de datos PostgreSQL: Almacena información de configuración de ChirpStack, organizaciones, aplicaciones, usuarios, etc… además de información histórica enviada por los dispositivos. Existen diversos mecanismos (HTTP, MQTT, InfluxDB, RabbitMQ, PostgreSQL, Azure Service Bus, AWS SNS, API REST).

El aspecto clave de ChirpStack hace referencia al modo en el que se procesa la información. ChirpStack hace uso de los componentes anteriores para componer y almacenar información estructurada proveniente de los dispositivos de campo, en un formato similar al siguiente:

{
“applicationID”: “123″,
“applicationName”: “temperature-sensor”,
“deviceName”: “garden-sensor”,
“devEUI”: “0202020202020202″,
“rxInfo”: [
{
"gatewayID": "0303030303030303",
"name": "rooftop-gateway",
"time": "2016-11-25T16:24:37.295915988Z",
"rssi": -57,
"loRaSNR": 10,
"location": {
"latitude": 52.3740364,
"longitude": 4.9144401,
"altitude": 10.5
}
}
],
“txInfo”: {
“frequency”: 868100000,
“dr”: 5
},
“adr”: false,
“fCnt”: 10,
“fPort”: 5,
“data”: “…”,
“object”: {
“temperatureSensor”: {“1″: 25},
“humiditySensor”: {“1″: 32}
},
“tags”: {
“key”: “value”
}
}

Otro aspecto interesante es que Chirpstack se puede desplegar de muy diversas maneras, al estar estructurado en una serie de componentes bien definidos que se comunican entre ellos mediante puertos e interfaces estandarizados. Permite tanto realizar un despliegue convencional en un único servidor, a desplegarse en un modelo de microservicios en un entorno Docker o Kubernetes. Para el caso en el que estoy trabajando, he optado por hacer un despliegue basado en contenedores Docker en una máquina virtual, aunque he realizado algunas pruebas con un despliegue más monolítico, y en el ámbito laboral estoy haciendo uso de un entorno Kubernetes.

El despliegue mediante Docker es tremendamente sencillo, ya que los propios desarrolladores de Chirpstack proporcionan una configuración de ejemplo con todos los elementos necesarios. Y una vez desplegado, es bastante sencillo añadir los componentes necesarios. En mi caso, he integrado un gateway Dragino LG308. La integración es tan sencilla como apuntar el servicio LoRaWAN del gateway al puerto 1700/UDP del servidor donde se encuentre levantado el componente Network de Chirpstack. Es posible desplegar un paquete software en el gateway Dragino para convertirlo en un Gateway Bridge de Chirpstack, pero si tenemos éste desplegado en otro sitio, no es necesario realizarlo.

Y en cuanto al registro de los dispositivos, tampoco supone mayor inconveniente. Es necesario definir de manera previa unos perfiles de configuración de dispositivos y la aplicación donde registramos estos últimos, y a partir de ahí, se puede crear la propia aplicación, y registrar los dispositivos, bien por OTAA o ABP, en función de nuestras preferencias. Con todo ello, se tiene una red privada LoRaWAN perfectamente funcional.

Etiquetas: chirpstack, contenedor, docker, dragino, kubernetes, lora, lorawan, microservicio