Chirpstack
Chirpstack (anciennement LoRa Server) est un network server LoRaWAN open source distribué sous licence MIT.
Ecrit en Rust depuis sa version 4, il est un des outils les plus robustes et les plus utilisés du marché.
Architecture
Chirpstack fonctionne avec plusieurs composants, ce qui permet de l'installer sous forme d'une architecture micro-services, et donc de faire de la scalaibilité horizontale.
Les composants principaux du systèmes sont les suivants :
- Chirpstack en lui-même.
- Une base de données PostegreSQL permettant de stocker les données du parc, des tenants, des utilisateurs et des applications.
- Une base de données à faible latence REDIS, où sont notamment stockées les clefs de sessions, utilisées pour décrypter chaque message reçu.
- Un broker MQTT (par défaut Mosquitto).
- Des agents (appelés gateway bridge ou MQTT Packet Forwarder) , installés sur les gateways selon les marques et modèles, ou sur le serveur.
Organisation des données dans Chirpstack
Chirpstack est multi-tenant, c'est à dire qu'il permet de créer des espaces séparés avec chacun leurs propres gateways, utilisateurs, applications et capteurs.
Les capteurs et objets sont regroupés dans des applications. Tous les objets placés dans une même application partagent les mêmes intégrations.
Chaque capteur est associé à un device type, qui inclut notamment les caractéristiques de ce type de capteur (version MAC, paramètres régionaux...) mais aussi le décodeur (facultatif).
Communication avec les gateways
Plusieurs modes de communication permettent aux gateway de dialoguer avec le network server.
Communication UDP, agent installé côté serveur
Le gateway bridge ou le MQTT Packer Forwarder est installé côté serveur. L'ensemble des gateways envoie alors ses données au travers du protocole UDP (Semtech Packer Forwarder ou Basic Station) jusqu'au serveur, puis l'agent envoie les données au network server à travers MQTT (si l'agent est installé sur le même serveur que le network server, TLS n'est pas requis).
Avantages
Cette configuration ne nécessite pas l'installation de l'agent sur les gateways. Elle est très simple à mettre en oeuvre, il suffit simplement de faire pointer l'url du Packet Forwarder vers le serveur.
Inconvénients
La communication UDP n'est pas entièrement sécurisée. Bien que les packets soient nativement cryptés en AES128, comme tous les messages LoRaWAN, certaines informations seront visibles, ouvrant ainsi la porte à du spoofing de gateways. C'est pourquoi cette configuration est déconseillée en production.
Communication MQTT, agent installé côté gateway
Le gateway bridge ou le MQTT Packer Forwarder est installé sur les gateways. La communication entre les gateways et le network server est alors effectué à travers le protocole MQTT. Il est impératif de configurer MQTT sur TLS, afin d'assurer l'intégrité et la sécurité des données. L'authentification se fait par certificats, qui sont générés dans le menu gateway de l'interface de Chirpstack.
Avantages
Cette configuration est la plus adaptée à la production :
- Elle permet un contrôle fin des données envoyées, notamment grâce au filtrage par NetID ou DevId des paquets, qui peut limiter la consommation de données, notamment lorsqu'une liaison 3/4/5G ou LTE-M est utilisée.
- Elle offre un niveau de sécurité important pour la communication entre les gateways et le network server.
Inconvénients
La configuration et l'installation des agents sur les gateways est un travail d'expert qui peut être également très consommateur de temps s'il n'est pas automatisé.
Communication mixte
Il est possible de créer des réseaux mixtes, où certaines Gateway utilisent leur propre agent, et où d'autres communiquent en UDP.
Intégration avec des services tiers
Chirpstack offre plusieurs possibilités pour pousser les données vers des systèmes tiers (on parle parfois de serveurs applicatifs).
Push HTTP (webhook)
Les données sont poussées vers une ou plusieurs URL configurable dans l'interface. Il est également possible de définir un header personnalisé, par exemple pour entrer une clef API.
MQTTS
Les systèmes tiers peuvent se connecter à Chirpstack à l'aide d'un client MQTT. Pour se faire, il faut télécharger les certificats/clefs dans l'interface, puis les saisir dans le système qui souhaite se connecter. Un certificat/clef est valable uniquement pour une Application donnée.
Pour configurer le client MQTT :
- Serveur : url ou adresse IP
- Port : 8883 (MQTT over TLS)
- Topic : application/xxx/device/+/event/up, xxx étant l'id de l'application.
AWS SNS
Service Pub/Sub proposé par AWS (Amazon).
Azure Service-Bus
Service Pub/Sub proposé sur Azure (Microsoft).
GCP Pub/Sub
Service Pub/Sub proposé par Google Cloud.
IFTTT
InfluxDB
myDevices
Pilot Things
Semtech LoRa Cloud™
ThingsBoard
Thingsboard est une plateforme IoT qui existe en version Open Source et professionnelle.
API gRPC
Chirpstack expose une API gRPC qui lui permet d'être piloté par des systèmes tiers sans passer par l'interface. Un wrapper REST est disponible, mais il est conseillé de passer directement par gRPC.
Limitations de Chirpstack
Chirpstack offre toutes les fonctionnalités nécessaires à l'exploitation d'un réseau privé LoRaWAN à grande échelle. Il n'est pas limité en capacité.
Cependant, son interface web comporte des limitations :
- L'import en masse des capteurs / objet et gateways n'est pas possible dans l'interface.
- La modification en masse n'est pas disponible, tout comme l'envoi en masse de downlinks à un ensemble d'objets (à ne pas confondre avec un multicat group).
- Il n'existe pas nativement de système de monitoring intégré, permettant par exemple d'informer l'utilisateur lorsqu'une gateway n'a pas communiquée depuis un certain temps.
Ces fonctionnalités sont pourtant indispensables lorsqu'on souhaite exploiter un réseau LoRaWAN professionnel de grande taille.
Ces limitations peuvent être contournées en utilsant des scripts basés sur la puissante API gRPC de Chirpstack.