Les serveurs réseau LoRaWAN simplifiés

Résumé

Chaque déploiement LoRaWAN s'appuie sur un serveur réseau LoRaWAN (LNS) pour gérer le flux de données entre les passerelles et les applications. Le choix entre un LNS hébergé dans le cloud et un LNS intégré à la passerelle peut avoir une incidence significative sur le coût, la fiabilité, l'évolutivité et la valeur commerciale à long terme .

Un LNS hébergé dans le cloud exploite des plateformes à grande échelle telles qu'AWS, Azure ou Google Cloud pour fournir des services multi-locataires résilients, dotés de solides capacités de gestion centralisée et d'itinérance réseau. À l'inverse, un LNS intégré offre un contrôle local, des coûts de données cellulaires réduits et des déploiements plus simples pour les petits réseaux localisés, mais avec une évolutivité et une résilience limitées.

Ce livre blanc explore les compromis entre les deux approches, offrant ainsi plus de clarté aux entreprises qui conçoivent des solutions LoRaWAN. Robustel fournit les deux modèles et l'expertise consultative nécessaires pour aider les organisations à choisir la voie la mieux adaptée à leur application.


Ce que vous apprendrez
  • Le rôle architectural du serveur réseau LoRaWAN (LNS) dans la gestion des communications entre les passerelles et les capteurs .
  • Les différences entre les modèles LNS hébergés dans le cloud et intégrés, notamment en termes de coûts liés aux données, de résilience, de puissance de calcul et de frais récurrents.
  • Comment les coûts de liaison cellulaire peuvent exploser sans filtrage local des données — et comment le LNS intégré peut réduire ce risque.
  • Pourquoi les serveurs hébergés dans le cloud excellent en matière de gestion centralisée, d'évolutivité et de prise en charge de l'itinérance.
  • Quand un LNS intégré est pertinent (par exemple, petits réseaux privés avec un nombre limité de capteurs) et quand l'hébergement dans le cloud est indispensable (par exemple, déploiements à grande échelle ou multi-locataires).
  • Comment les passerelles Robustel prennent en charge les deux modèles, offrant aux entreprises la flexibilité et les conseils nécessaires pour adopter la solution adéquate dès le départ.

Cet article est destiné à aider ceux qui se lancent dans une nouvelle entreprise ou un nouveau concept utilisant la technologie LoRaWAN à comprendre les options et l'impact du choix du type de serveur réseau LoRaWAN.

Cet article suppose une connaissance de base de LoRa et des réseaux LPWAN et offre au lecteur des éclaircissements sur les architectures possibles disponibles grâce à différentes implémentations du serveur réseau LoRaWAN.

Architecture réseau LoRaWAN

LoRaWAN définit lui-même une solution de transmission de données de bout en bout, comme illustré dans la figure 1.1 ci-dessous.

Les terminaux sont principalement divers types de capteurs qui communiquent avec les passerelles LoRaWAN à l'aide du protocole de couche physique LoRa, principalement sur des bandes sans licence sub-GHz telles que 868 MHz dans l'UE, 915 MHz aux États-Unis et 470 MHz en Chine.

Figure 1.1 – Architecture classique de la solution LoRaWAN

LoRaWAN nécessite un « serveur réseau LoRaWAN » ainsi qu'un serveur d'application, ce qui peut initialement prêter à confusion. L'une des raisons pour lesquelles un serveur réseau est nécessaire est que les passerelles peuvent être considérées comme « stupides » : elles transmettent toutes les données des capteurs sans appliquer ou presque aucune intelligence à ce qui est transmis.

La définition des passerelles LoRaWAN comme « une antenne distribuée, commune à tous les réseaux » renforce le rôle de la passerelle en tant que dispositif de couche physique jouant un rôle passif dans l'ensemble du réseau. Bien que cela ne soit pas tout à fait correct d'un point de vue technique, d'un point de vue conceptuel, cela permet de comprendre pourquoi un serveur réseau fonctionnant comme un orchestrateur/maître de réseau est un élément clé de toute pile LoRaWAN.

Il existe deux types fondamentaux de LNS que les intégrateurs de systèmes doivent prendre en considération : « hébergé dans le cloud » et « intégré ».

LNS hébergé dans le cloud


Un serveur hébergé dans le cloud utilise généralement les capacités des centres de données d'entreprises telles que Microsoft, Amazon ou Google pour fournir un service multi-locataires hautement « disponible » sur Internet, avec plusieurs instances par région géographique.

LNS intégré

Un LNS intégré est un LNS qui fonctionne sur la même plateforme matérielle que la passerelle LoRaWAN elle-même, ce qui permet de réaliser des économies dans les déploiements individuels et de réduire la dépendance vis-à-vis des fournisseurs de services LNS tiers.

Pour être complet, il est important de noter qu'un LNS peut également être hébergé localement sur un réseau local Ethernet à l'aide d'un appareil distinct, tel qu'un PC intégré. Un tel PC peut être sélectionné pour offrir le rapport calcul/prix idéal et servir de LNS pour plusieurs passerelles indépendantes. Conceptuellement, cela revient au même qu'un LNS intégré, à une petite modification près dans l'architecture réseau.

Pour simplifier, cet article se concentre uniquement sur les deux options les plus extrêmes et distinctes : un LNS basé sur le cloud par opposition à un LNS entièrement intégré.

Lorsqu'il s'agit de choisir entre un LNS intégré ou un LNS hébergé dans le cloud (disponible auprès de fournisseurs de services tels que TTN ou Loriot), il est important de prendre en compte les forces et les faiblesses relatives de chaque solution. En général, si l'application ne nécessite qu'un petit nombre de capteurs dans un environnement localisé, un LNS intégré peut être une bonne solution. Cependant, la gestion et l'évolutivité d'une telle solution seront toujours plus limitées que celles d'un réseau (ou d'un réseau de réseaux) orchestré à partir du cloud.

Fonctionnalité

LNS intégré

LNS hébergé dans le cloud

Coût absolu des données 4G

Faible

Supérieur

Risque lié au coût des données 4G

Faible

Supérieur

Résilience des serveurs

Faible

Élevé

Gestion centralisée du réseau

Indisponible sans « solutions de contournement »

Très granulaire

Coût récurrent

Généralement gratuit

Généralement facturable

Puissance de calcul

Généralement gratuit

Très élevé

Itinérance réseau

Non disponible

Possible

Capacité à « revendre » des services réseau

Faible

Élevé

Vous trouverez ci-dessous une explication plus détaillée des fonctionnalités mises en évidence dans le tableau ci-dessus :

Données 4G – Coût et risque

Trop souvent, les considérations détaillées relatives à l'utilisation d'un réseau cellulaire pour le backhaul plutôt qu'une connexion « filaire » ou « haut débit » ne sont pas pleinement prises en compte avant le déploiement, ni clairement expliquées par les fournisseurs de solutions.

Le backhaul cellulaire sans fil vers Internet offre une flexibilité de déploiement inégalée et constitue un outil essentiel pour de nombreux réseaux, mais le fait qu'il soit fondamentalement moins fiable et potentiellement beaucoup plus coûteux qu'une connexion Internet haut débit est souvent négligé ou sous-estimé.

L'intégration d'un LNS dans la passerelle ne devrait pas améliorer la fiabilité du réseau de raccordement, mais elle permettra certainement de réduire les coûts et les risques. En mettant sur liste blanche uniquement les capteurs autorisés localement et en ne transmettant que les données d'application (et non toutes les données de gestion LoRa), le trafic cellulaire peut être considérablement réduit par rapport à une implémentation basée sur le cloud.

Cela revêt une importance commerciale considérable si des cartes SIM itinérantes* (ou multi-réseaux) sont utilisées dans l'application, car le coût par Go de données transférées peut être relativement très élevé.

Il est également important de tenir compte du fait qu'une passerelle LoRa ou un ensemble de passerelles agit comme une antenne distribuée qui transmet des paquets de données provenant de capteurs qui n'ont rien à voir avec l'application principale. Rien n'empêche qu'un, cent ou mille capteurs soient déployés dans la portée RF de la ou des passerelles au cours des mois ou des années à venir, ce qui entraînera une augmentation du trafic de données cellulaires.

Certains considèrent cela comme un « risque incontrôlable », et estiment que seule une liste blanche localisée et un LNS intégré constituent une option viable pour éliminer complètement ce risque. De bons outils de surveillance du réseau et des tests de validation approfondis contribuent à atténuer le risque lié à l'utilisation des données dans toutes les applications basées sur les communications cellulaires.

Résilience des serveurs

La redondance peut être facilement obtenue pour un LNS hébergé dans le cloud en utilisant des techniques de réseau/informatique standard déjà largement utilisées pour d'autres types de services en ligne. La qualité de la redondance peut être facilement évaluée en demandant des détails à votre fournisseur LNS. L'étendue du SLA proposé par le fournisseur est un bon indicateur de la confiance qu'il accorde à son propre système.

Un LNS intégré existera généralement sous la forme d'une instance unique d'un service LNS sur un moteur de calcul relativement peu puissant dans la passerelle LoRa elle-même. Cela signifie que la marge de manœuvre en matière de « résilience » est très limitée, au-delà de la nécessité de s'assurer que la plate-forme matérielle et logicielle choisie est aussi stable et fiable que possible. Les tests d'endurance approfondis sont l'un des rares moyens concrets de vérifier la fiabilité des passerelles LoRaWAN avec LNS intégré.

Vérifier le nombre prévu de mises à jour du micrologiciel par an ou demander des preuves du nombre de mises à jour effectuées l'année précédente peut vous donner une indication sur le type d'appareil qui vous est proposé.

Gestion centralisée du réseau

Lorsqu'on utilise un LNS intégré, la gestion centralisée est nettement moins facile à réaliser sans recourir à des solutions de contournement ou à des logiciels supplémentaires qui reviennent en fait à « réinventer la roue ».

Un LNS basé sur le cloud peut fournir une vue d'ensemble claire du réseau, des métadonnées complètes, des informations détaillées sur les communications radio et des alertes sur les passerelles. C'est sans doute le seul moyen de gérer à grande échelle des réseaux importants ou multi-locataires.

Coût récurrent

Certaines applications commerciales de l'IoT reposent sur la réduction au minimum des coûts mensuels récurrents afin de fournir un service que les clients considèrent comme « rentable » ou « abordable ». Dans ce cas, la suppression des frais payables à des fournisseurs LNS tiers peut être un moyen de réduire les coûts et, par conséquent, d'atteindre les objectifs requis pour la réussite d'une entreprise. En fin de compte, cela revient à un argument classique de « faire ou acheter », avec les risques et les coûts initiaux associés si vous choisissez de « le faire vous-même ».

Puissance de calcul

Grâce aux techniques modernes de cloud computing, la puissance de calcul d'un LNS en ligne n'est plus limitée par la capacité de traitement du matériel serveur lui-même. Cependant, il s'agit d'un élément très important à prendre en compte lors de l'utilisation d'une passerelle LoRaWAN avec un LNS intégré, car ces plateformes doivent être conçues en fonction d'un budget et utilisent donc des processeurs à faible coût. La mémoire RAM et la mémoire Flash disponibles peuvent également être limitées. Cela signifie que les performances du service LNS peuvent être limitées, ce qui se traduit concrètement par une capacité de traitement des paquets LoRa restreinte.

Les fournisseurs de passerelles évaluent souvent la portée de leur capacité LNS intégrée en précisant le nombre de capteurs que la passerelle + LNS peut gérer efficacement. Le chiffre typique se situe dans la dizaine de capteurs, ce qui représente une limitation importante, mais signifie néanmoins qu'un LNS intégré peut être applicable à un grand nombre d'applications LPWAN différentes dans les réseaux LoRaWAN privés.

Itinérance réseau

Par définition, l'itinérance réseau ne peut être gérée que lorsque le LNS existe dans le cloud.

Capacité à revendre des services réseau

L'un des principaux avantages liés au déploiement des réseaux LoRa est la possibilité de permettre à d'autres d'utiliser un réseau que vous avez construit pour vos propres besoins.

Par exemple, un réseau déployé sur un campus à des fins de surveillance environnementale pourrait être mis à la disposition d'un tiers responsable d'autres actifs sur le même campus, tels que l'éclairage public ou les poubelles. Cela permettrait à ce tiers d'économiser le coût de solutions GSM ou câblées plus onéreuses et/ou de gagner en efficacité dans son fonctionnement.

Le concept de « réseau partagé » peut être mis en œuvre avec un LNS intégré, mais un LNS basé sur le cloud est beaucoup plus adapté à ce type d'implémentation, car il facilite la gestion à long terme et l'évolutivité tout en réduisant les coûts, en particulier lorsque le nombre de passerelles augmente.

Comme l'illustre cet article, il existe plusieurs méthodologies de mise en œuvre LoRaWAN et, bien que ce soit un sujet assez complexe, l'emplacement du LNS est très important car il peut modifier considérablement la dynamique technique et commerciale d'une proposition IoT basée sur LoRa.
Robustel est un fabricant de passerelles LoRaWAN qui peut proposer les deux types de solutions en fonction des exigences de l'application concernée. Plus important encore, Robustel peut offrir des services de conseil et d'assistance pour aider à choisir la solution appropriée et à la configurer correctement dès le départ.


Le succès de votre déploiement LoRaWAN dépend du choix du bon serveur réseau. Robustel combine un matériel de passerelle éprouvé avec une expertise dans les modèles LNS hébergés dans le cloud et intégrés, vous aidant ainsi à trouver le juste équilibre entre coût, fiabilité et évolutivité. Collaborez dès aujourd'hui avec Robustel pour concevoir une solution LoRaWAN qui répond à vos besoins actuels et qui évoluera avec vous demain.