De la technologie LoRa au réseau LoRaWAN

Comment connecter les milliards de capteurs qui seront potentiellement déployés dans le monde et qui participeront à la construction des villes intelligentes, de la mobilité et de l’industrie du futur ?

Il n’y a évidemment pas qu’une seule réponse mais une d’entre elles se trouve assurément du côté des LPWAN.

Les LPWAN sont des réseaux sans fils basse consommation, bas débit et longue portée, optimisés pour les équipements aux ressources limitées pour lesquels une autonomie de plusieurs années est requise. Ces réseaux conviennent particulièrement aux applications de l’Internet des Objets qui n’exigent pas un débit élevé.

Je vous avais présenté dans mon précédent article sur le sujet, plusieurs réseaux LPWAN parmi lesquels le réseau LoRaWAN. Je manquais alors d’expérience pratique pour juger des performances réelles de ce réseau. Après quelques mois de prototypage et surtout après le développement de mon propre réseau LoRaWAN, je vous propose de vous présenter, plus en détail, ce réseau qui prend de plus en plus de place dans le paysage de l’Internet des Objets.

La modulation LoRa et le protocole LoRaWAN

Pour rappel, LoRaWAN (Long Range Radio Wide Area Network), est un protocole réseau bas débit et longue portée basé sur la technologie radio LoRa.

La technologie LoRa opère dans les bandes de fréquences ISM (autour de 868 MHz pour l’Europe) et utilise une modulation à étalement de spectre – une variante de la modulation chirp spread spectrum pour être plus précis. L’utilisation de cette modulation offre des performances optimisées en terme de portée, en augmentant significativement la robustesse du signal et la sensibilité du récepteur tout en conservant une faible consommation d’énergie.

Utilisée auparavant pour les communications spatiales et militaires, cette modulation est particulièrement performante pour les communications longue portée et bas débit.

La portée d’une communication LoRa est déterminée par sa bande passante, la puissance de sortie du signal ainsi que par le facteur d’étalement utilisé – Spreading Factor (SF).  L’étalement du signal augmente sa portée, au détriment du débit car il est transmis sur une plus longue période. Au détriment également de l’autonomie de l’équipement car la communication radio est énergivore ! Par conséquent une communication plus longue implique une consommation d’énergie plus importante. Je vous propose ci-dessous un schéma illustrant l’impact de l’étalement du signal sur la portée et sur le débit d’une communication LoRa (pour la bande 868 MHz).

 

Un réseau LoRaWAN, s’appuyant une modulation LoRa dans la bande de fréquence 868 MHz, supporte 6 facteurs d’étalement (SF7, SF8, SF9, SF10, SF11, SF12) comme le montre le schéma ci-dessus. Sachez que l’orthogonalité des SF permet la réception de plusieurs signaux en parallèle sur le même canal. Par défaut, le réseau doit au minimum supporter les trois canaux suivants (de 125 KHz de bande passante chacun) : 868,10 ; 868,30 et 868,50 MHz.

À ce propos, Semtech propose un outil qui calcule les performances estimées d’une communication LoRa en fonction des différents paramètres (SF, bande passante, fréquence, etc.).

D’autres mécanismes, comme la variation de la fréquence à chaque émission, contribuent également à la robustesse d’une communication LoRa. Si vous souhaitez creuser le sujet de la modulation LoRa, je vous invite à consulter ce document.

Pour reprendre la terminologie du modèle OSI, la technologie LoRa représente donc la couche physique d’un réseau LoRaWAN, définissant le lien radio entre les équipements et les concentrateurs appelés respectivement les end-devices et les gateways dans les spécifications LoRaWAN.

A ce sujet, je vous présenterai, plus loin dans l’article, un schéma illustrant l’architecture d’un réseau LoraWAN. Avant cela, ci-dessous, je vous livre un schéma illustrant les différentes couches d’un réseau LoRaWAN.

Deux équipements LoRa peuvent communiquer en P2P sans nécessairement passer par un réseau. Cependant, pour que ces équipements communiquent à travers un réseau, l’implémentation de la seule couche physique n’est plus suffisante. C’est ainsi que LoRaWAN définit le protocole réseau (LoRa MAC), pour une communication d’équipements LoRa à travers un réseau.

En s’appuyant sur les performances de la modulation LoRA, le protocole LoRaWAN assure des communications bidirectionnelles et définit ainsi trois classes d’équipements : Classe A, B et C. La différence entre ces classes réside essentiellement dans le nombre de fenêtres allouées par l’équipement pour la réception des messages envoyés par le réseau.

Chaque équipement LoRaWAN est au minimum compatible avec la classe A ; le support des autres classes est optionnel. Pour une description détaillée de ces classes, je vous renvoie à mon article sur les LPWAN.

Afin d’optimiser davantage la capacité du réseau, le protocole LoRAWAN prévoit un débit adaptatif – ADR – compris entre 0,3 et 50 kbits par seconde. En fait, le réseau est en mesure d’ajuster le débit des communications et la puissance de sortie de chaque équipement en fonction de sa couverture radio, assurant de ce fait une gestion optimisée des ressources et de la capacité du réseau.

Architecture d’un réseau LoRaWAN

La topologie d’un réseau LoRaWan est en étoile : les équipements – appelés end-devices – communiquent en LoRa avec des concentrateurs – appelés gateways. Ces concentrateurs centralisent les messages pour les transmettre au serveur de gestion du réseau. La liaison entre les concentrateurs et le serveur de gestion du réseau s’appuie sur des technologies très haut débit (Ethernet, 4G,…).

Toute l’intelligence, à savoir la gestion du débit adaptatif, de la sécurité des données ou encore de la redondance des données reçues, est assurée par le serveur du réseau. Enfin, ce dernier communique avec un ou plusieurs serveurs applicatifs au travers desquels les fournisseurs d’applications exploitent les données de leur(s) équipement(s).

Car en effet, une des particularités d’un réseau LoRaWAN, est qu’un équipement ne communique pas exclusivement à travers un concentrateur. Tous les concentrateurs couvrant l’équipement peuvent recevoir les données transmises par ce dernier.

Cela facilite grandement la communication avec les équipements en mobilité en dispensant le réseau de mécanismes de hand-over (passage d’un concentrateur à un autre) qui auraient pour effet de complexifier sa gestion et très probablement de réduire ses performances. Par contre, lorsque le serveur envoie un message à destination d’un équipement, c’est par le biais d’un seul concentrateur. C’est le cas en particulier des messages requérant un acquittement par le serveur.

La sécurité d’un réseau LoRaWAN

Maintenant que nous connaissons l’architecture d’un réseau LoRaWAN, une question essentielle reste à traiter : celle de la sécurité. Que ce soit pour assurer la sécurité du réseau ou pour garantir la confidentialité et la sécurité des données, la question de la sécurité est extrêmement importante. Une question qui, soit dit en passant, concerne l’Internet des Objets dans son ensemble.

Pour assurer la sécurité du réseau et des données, le réseau LoRaWAN a recours à deux chiffrements AES-128. Le premier via la clé de session réseau – Network Session Key (NwkSKey) – assure l’authenticité des équipements sur le réseau ; quant au deuxième chiffrement, il assure via la clé de session applicative – Application Session Key (AppSKey) – la sécurité et la confidentialité des données transmises à travers le réseau.

En d’autre termes, la clé réseau permet à l’opérateur de sécuriser son réseau alors que la clé applicative permet au fournisseur de l’application de sécuriser les données qui transitent à travers le réseau.

Les données utiles que souhaite transmettre l’équipement sont tout d’abord chiffrées via la clé de session applicative. Un en-tête, contenant entre autres l’adresse de l’équipement, est ensuite ajouté aux données chiffrées. À partir de cette concaténation, le MIC – Message Integrity Code – est calculé via la clé de session réseau. Le MIC permet au réseau de vérifier l’intégrité des données et de l’équipement sur le réseau. Enfin, le MIC est ajouté au message contenant l’en-tête et les données chiffrées avant transmission.

À réception du message par le serveur de gestion du réseau, ce dernier pourra vérifier l’intégrité des données grâce au MIC tout en préservant la confidentialité des données (chiffrées par la clé de session applicative).

Pour illustrer cela, je vous ai préparé un petit schéma :

Logiquement, la clé applicative n’est connue que du fournisseur de l’application en question,  évitant ainsi qu’un tiers – l’opérateur compris – puisse consulter les données. La clé réseau, pour sa part, est communiquée par l’opérateur du réseau aux fournisseurs d’applications autorisés.

Ces clés permettent de sécuriser les données transmises par les équipements à travers le réseau mais elles sont également indispensables à leur activation sur le réseau.

Activation d’un équipement LoRaWAN

Avant toute communication à travers un réseau LoRaWAN, les équipements doivent obtenir les clés de session, en suivant une procédure d’activation au choix parmi deux méthodes : Over-The-Air Activation (OTAA) ou Activation By Personalization (APB).

Activation par la méthode OTAA

Pour activer un équipement sur le réseau par la méthode OTAA, l’équipement doit transmettre au réseau une demande d’accès : join request. Pour ce faire, celui-ci doit être en possession de trois paramètres :

• Le DevEUI, identifiant unique (de type EUI 64) de l’équipement (fourni par l’équipementier).
• AppEUI, identifiant du fournisseur de l’application (EUI 64).
• AppKey, clé AES 128 déterminée par le fournisseur de l’application.

L’équipement envoie, à travers le réseau, la requête join request, contenant DevEUI, AppEUI ainsi qu’un MIC calculé via la clé AppKey. Cette requête est transmise au serveur d’enregistrement qui vérifie le MIC via la clé AppKey (qui lui a été communiquée au préalable). Si l’équipement est autorisé par le serveur d’enregistrement, la requête join accept est transmise en réponse à l’équipement.

Cette réponse contient des données à partir desquelles l’équipement va pouvoir calculer les clés de session (réseau et applicative). Parmi les données contenues dans cette réponse, se trouve également l’adresse – Device Adress (DevAddr) sur 32 bits – qu’utilisera l’équipement pour communiquer sur le réseau.

A chaque nouvelle session, les clés de session sont renouvelées.

Je vous rappelle que tous ces mécanismes sont gérés par les serveurs de gestion et d’enregistrement. Les concentrateurs, pour leur part, relaient toutes les données transmises par les équipements présents dans leur zone de couverture, qu’ils soient activés ou non.

Activation par la méthode APB

Pour la seconde méthode, APB, les clés de session NwkSKey et AppSKey ainsi que l’adresse de l’équipement (DevAddr) sont directement inscrits dans l’équipement LoRaWAN. Ainsi, l’équipement n’a plus besoin d’envoyer de requête avant de communiquer sur le réseau. L’utilisation de cette méthode implique que les équipements communiquent avec un réseau spécifique car les clés de session sont connues par avance. Et contrairement à la méthode OTAA, les clés de session sont statiques.

En résumé, la méthode OTAA est plus complexe à implémenter que la méthode APB mais offre un niveau de sécurité supérieur. Dans le cas d’un prototypage ou pour une utilisation sur un réseau connu, la méthode APB suffit largement. Par contre, lorsqu’un déploiement à plus grande échelle est envisagé, il est conseillé d’utiliser la méthode OTAA, plus sécurisée et plus agile.

Réseaux publics VS réseaux privés

Vous pouvez, moyennant le paiement d’un abonnement, connecter vos équipements à un réseau LoRaWAN dit public ; traditionnellement proposé par les opérateurs de téléphonie mobile. À ce jour en France, Orange et Bouygues Telecom proposent tous deux une offre pour l’utilisation de leur réseau LoRaWAN avec l’accès à une plateforme pour la récupération des données.

Même si des opérateurs télécom déploient des réseaux LoRaWAN, il est tout à fait possible pour un particulier, une entreprise ou même une ville, de déployer son propre réseau LoRaWAN. Et détrompez vous, cela n’a rien d’insurmontable.

Tout d’abord, contrairement aux réseaux mobiles, les bandes de fréquences sont libres. Toutefois, elles sont régulées : vous devez notamment respecter un certain temps d’occupation des canaux spectraux (duty cycle). Autrement dit, vous ne pouvez pas communiquer sans interruption ou à très haute fréquence des données.

Ensuite le coût d’infrastructure est plutôt abordable. Bien sûr, il ne s’agit pas de couvrir tout le pays avec son réseau LoRaWAN mais deux concentrateurs peuvent largement suffire à couvrir quelques kilomètres. Le prix d’un concentrateur peut varier de 200 à 2000$ selon les options et les fonctionnalités qu’il propose.

Enfin, en ce qui concerne le serveur applicatif, vous pouvez développer le vôtre ou utiliser celui d’un tiers. Bien entendu, déployer son propre réseau pour y connecter une dizaine d’équipements ne sera pas une opération rentable…

Les applications LoRaWAN

Compte tenu de ses performances en termes de portée et d’autonomie des équipements, le réseau LoRaWAN permet le déploiement et la remontée de données de capteurs en tout genre (qualité de l’air, remplissage des poubelles, détecteur de présence, …). L’exploitation de ces données ouvre des perspectives considérables dans de nombreux domaines que ce soit pour la gestion des ressources, pour l’optimisation des déplacements ou encore pour l’augmentation de la productivité.

Par exemple, un simple détecteur de présence, qui remonterait l’information d’occupation d’une salle permettrait aux gestionnaires de bâtiments qu’ils soient privés (ruche d’entreprises) ou publics (équipements sportifs) d’optimiser l’utilisation de leurs ressources. Autre exemple, avoir l’information du remplissage des bennes à ordures permettrait le développement d’applicatif d’optimisation des tournées de récolte avec la possibilité d’adapter les véhicules selon les itinéraires de récolte.

Je pourrais encore vous énoncer de nombreux exemples d’applications potentielles pour la maintenance prédictive, la mobilité intelligente, etc. pour lesquelles les réseaux LoRaWAN conviennent parfaitement (à la condition que celles-ci ne nécessitent pas une communication haut débit ou trop fréquente) ; mais j’espère que la lecture de cet article vous a donné l’envie de développer des solutions encore plus novatrices !

Vous trouverez en vous rendant sur ce lien, un panel de fournisseurs d’équipements LoRaWAN pour développer vos prototypes.

À ce propos, pour les prototypeurs basés à Lille, une plateforme de test et d’expérimentation LoRaWAN est ouverte et accessible à toutes les entreprises de l’écosystème d’EuraTechnologies.

Comme d’habitude, si des erreurs se sont glissées dans l’article, n’hésitez pas à nous en faire part.

Pour être informé des prochains articles, rendez-vous sur Twitter.

Merci, et à très bientôt sur Frugal Prototype