LoRaWAN

Un article de Wikipédia, l'encyclopédie libre.
Sauter à la navigation Sauter à la recherche

LoRaWAN est un protocole de télécommunication permettant la communication à bas débit, par radio, d'objets à faible consommation électrique communiquant selon la technologie LoRa et connectés à l'Internet via des passerelles, participant ainsi à l'Internet des objets. Ce protocole est utilisé dans le cadre des villes intelligentes, le monitoring industriel ou encore l'agriculture. La technologie de modulation liée à LoRaWAN est LoRa, crée en 2009 par la startup grenobloise Cycléo et racheté par Semtech en 2012. Semtech promeut sa plateforme LoRa grâce à la LoRa Alliance, dont elle fait partie. Le protocole LoRaWAN sur la couche physique LoRa permet de connecter des capteurs ou des objets nécessitant une longue autonomie de batterie (comptée en années), dans un volume (taille d'une boite d'allumettes ou d'un paquet de cigarettes) et un coût réduits.

LoRaWAN est l'acronyme de Long Range Wide-area network que l'on peut traduire par « réseau étendu à longue portée ».

Description générale[modifier | modifier le code]

Le protocole LoRaWAN est un protocole de communication pour l'internet des objets qui utilise une technique de modulation par étalement de spectre de type Chirp spread spectrum (en) propriétaire appelée LoRa. Ce protocole se veut simple, peu coûteux à implémenter et économe en énergie plutôt que permettant des débits élevés. La cible de LoRaWAN est clairement les communications longues portées à bas coût et basse consommation plutôt que les communications à débit élevé qui sont plus consommatrices en ressource CPU et en énergie. En effet, les défis concernant l'interconnexion des objets résident dans leur coût, leur autonomie ainsi que leur nombre d'un point de vue réseau. Ce faible coût est obtenu par l'utilisation d'une architecture en étoile (plus simple qu'une architecture maillée), une technique de modulation plus simple à implémenter que celle des réseaux cellulaires classiques ce qui réduit le coût des composants électroniques qui lui sont dédiés ainsi que l'utilisation de bandes de fréquences libres (ne nécessitant pas de payer pour leurs utilisations)[1]. Les équipements terminaux utilisés sont majoritairement peu coûteux (1 à 5 $) afin de pouvoir être déployés en grand nombre[2].

L'utilisation de fréquences libres permet aussi la création de réseaux LoRa "privés", c'est-à-dire n'ayant pas de liens avec un opérateur, pouvant couvrir un immeuble, un champ comme une ville sans devoir payer des abonnements.

Architecture[modifier | modifier le code]

Schéma illustrant une architecture LoRaWAN

Un réseau LoRaWAN est constitué d'équipements sans-fils basse consommation qui communiquent avec des serveurs applicatifs au travers de passerelles. La technique de modulation utilisée entre les équipements et les passerelles est LoRa. La communication entre les passerelles et les serveurs est établie via le protocole IP au moyen d'un réseau de collecte Ethernet ou 3G.

La topologie réseau LoRaWAN est dite en étoile d'étoiles (star-of-stars) car un serveur applicatif est connecté à une multitude de passerelles elles-mêmes connectées à une multitude d'équipements terminaux[3].

Au sens réseau, les équipements ne sont pas connectés aux passerelles, elles leur servent uniquement de relais pour joindre le serveur gérant le réseau, lui-même connecté à un ou plusieurs serveurs applicatifs. Les paquets envoyés par les équipements sont retransmis par les passerelles après y avoir uniquement ajouté des informations concernant la qualité du signal reçu[3].

Si la couverture radio le permet, plusieurs passerelles peuvent retransmettre le même message d'un équipement, il est alors dupliqué dans le réseau de collecte, c'est le serveur hébergeant l'application qui assure le dédoublement des paquets[3]. Cette particularité permet notamment la localisation des équipements via la comparaison des différents temps d'arrivée pour un même paquet dupliqué[4].

Lorsqu'une réponse doit être émise par le serveur, il utilise les informations ajoutées par les passerelles concernant la qualité de signal afin de choisir celle vers laquelle envoyer le paquet de réponse[5].

LoRaWAN ne permet pas le dialogue direct entre deux objets connectés. Si un tel dialogue doit avoir lieu il se fait au travers du serveur applicatif[5].

Modulation LoRa[modifier | modifier le code]

LoraWAN utilise une modulation à étalement de spectre de type Chirp spread spectrum (en) propriétaire appelée LoRa. Cette modulation s’effectue principalement sur les bandes radios ISM 868 MHz en Europe et 915 MHz en Amérique du Nord. L’utilisation de la modulation CSS pour l’internet des objets a été brevetée par Cycléo, une compagnie Française ayant été rachetée par Semtech en 2012[6]. Cette modulation permet en moyenne une distance entre une passerelle et un équipement jusqu'à 5 km en zone urbaine et 15 km en zone rurale[7] .

Les techniques de modulation par étalement du spectre comme LoRa utilisent une bande passante plus grande que ce qui est idéalement nécessaire pour un débit donné mais profitent de cet étalement en fréquence pour fonctionner avec un signal faible ou fortement bruité[6]. L'étalement du spectre consiste à répéter plusieurs fois le message transmis à des fréquences différentes. La variation de fréquence effectuée par LoRa est linéaire ce qui permet aux récepteurs d’éliminer simplement les décalages de fréquences et effets Doppler inhérents à la transmission du signal. Ce fonctionnement permet aux transmetteurs LoRa d’être produits à faible coût[8]. Cette technique d'étalement de spectre permet aussi au capteurs d'etres moins sensible aux messages envoyé en déplacement (sur un TGV en mouvement par exemple) et donc à l'effet Doppler. Une étude de 2017 a mesuré cet effet grâce à un équipement installé sur une moto[9].

Le facteur d'étalement est généralement fixé par le serveur lors de la connexion au réseau d'un équipement terminal, via l'envoi d'une demande de mesure du rapport signal sur bruit[10].

LoRa définit le facteur d'étalement du spectre (SF) par la formule[3] : avec Rc étant le débit du message transmis (Chirp) et Rs le débit du symbole à transmettre. L'augmentation du Spreading Factor permet de couvrir une distance plus grande entre l'équipement et la passerelle au détriment de la bande passante disponible[7].

Les différents SF sont orthogonaux, ce qui signifie que plusieurs trames peuvent être reçues en même temps sur le même canal à condition qu'elles utilisent un SF différent. Si deux trames sont reçues en même temps par une passerelle avec une différence de moins de 6 dB sur le même canal et avec le même SF elles seront perdues car impossible à différencier[10].

Les bandes passantes possibles à configurer pour un canal sont 125, 250 et 500 kHz pour la bande 868 MHz, ce qui permet d'atteindre un débit maximum de 27 kbit/s avec une bande passante de 500 kHz et un Spreading Factor de 7[11].

L'utilisation de fréquences libres impose de respecter un temps d'occupation maximum du canal radio (duty-cycle (en)). L'occupation maximum du canal est de 1 % en Europe sur la bande 868 MHz[7]. Sur la bande 868 MHz, la spécification LoRa impose initialement 3 canaux d’une largeur de 125 kHz communs à tous les équipements 868,10 MHz, 868,30 MHz et 868,50 MHz[3] pour que le message d'activation puisse être reçu par le serveur. Ce paramètre peut ensuite être modifié par le réseau et permettre au capteur de répartir ses messages sur un nombre de canaux plus important. Les équipements peuvent donc aléatoirement répartir leurs émissions sur chacune de ces bandes en respectant le temps d'occupation réglementaire.

LoRa permet de fixer les principaux paramètres radio à l'aide du paramètre Data Rate. Le Data Rate est défini par une valeur de 0 à 15 et fixe le type de modulation, le spreading factor ainsi que la bande passante utilisée.

Data Rates pour la bande 863-70 MHz[12] :

Data Rate (DR) Modulation Spreading Factor (SF) Bande Passante Débit Physique (bit/s)
0 LoRa SF12 125 kHz 250
1 LoRa SF11 125 kHz 440
2 LoRa SF10 125 kHz 980
3 LoRa SF9 125 kHz 1 760
4 LoRa SF8 125 kHz 3 125
5 LoRa SF7 125 kHz 5 470
6 LoRa SF7 250 kHz 11 000
7 FSCK 50kbit/s 50 000
8 Réservé pour utilisation future

La trame physique LoRa se compose d'un préambule, un en-tête, les données puis un contrôle d'erreurs[3].

Format d'une trame physique LoRa
  • L'en-tête est présent dans le mode de transmission par défaut (explicite), il est transmis avec un taux de code de 4/8. Il indique la taille des données, le taux de code pour le reste de la trame et il précise également si un CRC est présent. Un CRC est présent dans l'en-tête afin de permettre au récepteur de détecter s'il est altéré[13].
  • La taille maximale des données se situe entre 51 et 222 octets selon le facteur d'étalement utilisé (plus le SF est grand plus la taille des données est faible)[11].
  • Le code rate pour le reste de la trame peut être paramétré de 4/5 à 4/8[13], le taux 4/5 étant le plus utilisé[14].

D'après ces paramètres, il est donc possible de définir le débit utile Rb par la formule mathématique : [13]

Le protocole LoRaWAN[modifier | modifier le code]

Articles connexes : Contrôle d'accès au support et ALOHAnet.

LoRaWAN est un protocole de type contrôle d'accès au support. Son fonctionnement est plus simple que celui des technologies cellulaires qui reposent sur des équipements terminaux puissants et donc plus coûteux que ceux utilisés dans l'internet des objets.

Le protocole n'est pas symétrique, et il y a des différences entre les messages montant (uplink) provenant des objets et les messages descendant (downlink) provenant de l'applicatif et à destination des objets.

Il repose sur un fonctionnement de type ALOHA pour l'envoi des messages, ainsi lorsqu'un équipement doit envoyer des données il le fait sans contrôler si le canal qu'il va utiliser est disponible, et répète cet envoi sur différent canaux sans savoir si ce message a été correctement reçu[2]. Un message d'acquittement peut être demandé par l'objet, celui ci pouvant répéter automatiquement l'envoi si ce message n'a pas été reçu.

Les messages descendants (downlink) émis par la Gateway ont un cout réseau plus fort, car si la gateway émet un message, elle ne peut plus pendant ce temps écouter les autres messages envoyés.


Le protocole définit 3 classes d'équipements (A, B et C). La classe A doit être implémentée dans tous les équipements par souci de compatibilité. Un équipement peut changer de classe en cours de fonctionnement[7].

  • Classe A : Cette classe a la consommation énergétique la plus faible[5]. Lorsque l'équipement a des données à envoyer il le fait sans contrôle puis il ouvre 2 fenêtres d'écoute successives pour des éventuels messages provenant du serveur, les durées recommandées sont de 1 puis 2 secondes. Ces 2 fenêtres sont les seules durant lesquelles le serveur peut envoyer à l'équipement les données qu'il a précédemment stockées à son attention[7].
Fenêtres de réception pour un équipement de classe A
  • Classe B : Cette classe permet un compromis entre la consommation énergétique et le besoin en communication bi-directionnelle[7]. Ces équipements ouvrent des fenêtres de réception à des intervalles programmés par des messages périodique envoyés par le serveur[5].
  • Classe C : Cette classe a la plus forte consommation énergétique mais permet des communications bi-directionnelles n'étant pas programmées. Les équipements ont une fenêtre d'écoute permanente[5].

Le format des paquets LoRaWAN est décrit dans le schéma ci-dessous. Les tailles des champs sont indiquées en bits[15].

Format des paquets LoRaWAN

Voici la définition des différents champs contenus dans un paquet LoRaWAN[15] :

Mtype 
Ce champ indique le type du message (montant ou descendant).
RFU 
Ce champ est réservé pour usage futur.
Major 
Ce champ indique la version du protocole utilisée.
MIC 
Ce champ permet le calcul d'intégrité du paquet afin de détecter s'il a été altéré durant son transport.
DevAddr 
Ce champ contient l'adresse de l'équipement.
FCtrl 
Ce champ permet l'adaptation du débit et les acquittements. Il indique la présence de paquets supplémentaires ainsi que la longueur du champ FOpts.
FCnt 
Ce champ est un compteur de trame (incrément à chaque envoi).
FOpts 
Ce champ permet de passer des commandes MAC (contrôle de connectivité par un équipement par exemple).
FPort 
Ce champ contient le port de l'application ou du service auquel est adressé le paquet.

Afin de pouvoir fonctionner sur le réseau, un équipement doit avoir été activé. Deux procédures d'activation sont possibles[15] :

  • Activation By Personalization (ABP) : Les clefs de chiffrement sont stockées dans les équipements;
  • Over The Air (OTAA) : Les clefs de chiffrement sont obtenues par un échange avec le réseau.

Le tableau ci-dessous synthétise les informations transmises par l’équipement d’extrémité durant la procédure d'activation[16].

Identifiant Propriété Obtention
DevAddr Identité de l’équipement d’extrémité (32bits) Générée en OTAA, configurée en ABP
DevEUI Identité de l’équipement d’extrémité (64bits) Configurée
AppEUI Identité de l'application (rend unique le propriétaire de l’équipement d’extrémité) Configurée
NwkSKey Clef utilisée par le serveur et l’équipement d’extrémité pour calculer et vérifier le champ MIC Générée en OTAA, configurée en ABP
AppSKey Clef utilisée par le serveur et l’équipement d’extrémité pour chiffrer et dechiffrer les données des paquets Générée en OTAA, configurée en ABP
AppKey Clef utilisée par l’équipement d’extrémité lors de la procédure OTAA Générée en OTAA* , inexistant en ABP

*Générée en OTAA pour les équipements d’extrémité en version LoRaWAN 1.1, pour les versions antérieurs (LoRaWAN 1.0), la clef est configurée.

Le champ FOpts présent dans les paquets LoRaWAN permet aux équipements d'envoyer des commandes réseau. La commande LinkCheckReq permet à un équipement d'extrémité de tester sa connectivité. Le reste des commandes est utilisé par le serveur pour fixer les paramètres radio des équipements terminaux comme le Data Rate ou le canal par exemple. D'autres commandes permettent de contrôler leur niveau de batterie ou leur qualité de réception[15].

Consommation énergétique[modifier | modifier le code]

LoRaWAN consomme peu d'énergie. Il utilise une version simplifiée du protocole ALOHA pour la couche MAC, une topologie en étoile, une transmission cyclique dans chaque sous-bande et a défini trois classes d'appareils finaux pour déplacer autant que possible la complexité vers la station de base[17].

  • Les paramètres pour l'optimisation de l'énergie utilisés pour le cycle émission réception reposent sur l'utilisation des modes (émission, réception, attente et sommeil), la stratégie de transmission des informations et la puissance d'émission.

La consommation d'énergie des objets (équipements d’extrémité) dans le réseau LoraWan s'appuie sur l'utilisation des quatre principaux modes (émission, réception, attente et sommeil) et du temps passé dans chaque mode. L’étude[18] de Kurtoglu en 2017 a modélisé la consommation de l’énergie à partir de ces quatre modes, afin de comparer la consommation d'un réseau de capteurs sans fil linéaires à longue portée conçu par ZigBee ou LoraWan. La comparaison est effectuée à partir de la consommation des composants (pour LoRaWan RN2903, Zigbee MRF24j40MD)[18] :

Équipement Tension (V) Intensité émission (mA) Intensité réception (mA) Intensité attente (mA) Intensité sommeil (mA)
LoraWan RN2903 3,3 124,4 13,5 2,7 2
Zigbee MRF24J40MD 3,3 140,0 25,0 - 10

La consommation de la batterie dépend principalement de plusieurs facteurs: la quantité de donnée transféré (en nombre de messages et/ou taille des messages), ainsi que la puissance d’émission nécessaire pour émettre ces données, et le facteur d'étalement de spectre (SF)

Afin d'optimiser la consommation, le protocole LoRaWan permet l'adaptation du SF et de le diminuer afin d’économiser la puissance des périphériques, ainsi que de libérer de la bande passante radio et donc de limiter les collisions.

Plusieurs expérimentations on étudié plus en détails l'impact de ces différents paramètres [19],[20].

Geolocalisation[modifier | modifier le code]

Une des spécificités du réseau LoRaWan, est la possibilité de géolocaliser les objets grâce à une technique de type TDOA (Time Difference Of Arrival) ou Trilateration. Les différentes Gateway qui reçoivent les mêmes message d'un objet horodatent de manière très précise l'heure de réception de ce message. La distance entre l'objet et l'antenne étant proportionnelle au temps que met le message pour être reçu par l'antenne, la résolution d'une équation à plusieurs inconnus permet d'en déduire la position de l'objet à condition que les messages de celui ci ci soit reçu par au moins trois antennes différente

Aspect capacitaire[modifier | modifier le code]

Le temps maximum d'occupation du canal radio (duty-cycle) imposé par l'utilisation de fréquences libres est un facteur limitant le nombre de paquets pouvant être émis par un équipement. Par exemple, le résultat de la limitation à 1 % sur la bande 868 MHz est un temps de transmission de 36 secondes par heure et par canal pour chaque terminal[11].

L'utilisation de ce temps de transmission est variable selon le facteur d'étalement choisi. En effet, plus le facteur d'étalement est grand plus le temps pour transmettre un paquet sera élevé. Par ailleurs les facteurs d'étalement élevés sont plus souvent utilisés que les facteurs courts dans un réseau typique. Le tableau ci-dessous fournit plusieurs exemples[11] :

Taille des données Spreading Factor Temps de transmission
20 octets 10 0,4 sec
20 octets 12 1,5 sec
40 octets 10 0,5 sec
40 octets 12 1,8 sec


Une étude menée en 2017 par Ferran Adelantado montre l'évolution du taux de paquets reçus avec succès selon le nombre d'équipements connectés à une passerelle en utilisant 3 canaux. Logiquement, le nombre de paquets reçus diminue à cause des collisions car la probabilité que plusieurs équipements utilisent le même SF simultanément sur le même canal augmente [11].

De manière générale, la perte de donnée inhérente à l'utilisation de protocole sur des fréquences libres peut être résolu de deux manières:

- avec un acquittement des données, et une répétition si le paquet n'a pas été reçu, et donc non acquitté. Cette garantie de réception entraine non seulement un cout plus important du a l'utilisation de message "downlink" ainsi qu'une occupation potentiellement plus importante du spectre radio.

- par une redondance des données lors des messages suivant. Par exemple, un capteur peut fournir la donnée courante qu'il mesure, ainsi que les données précédentes afin de permettre une continuité dans les données

Le choix de l'une ou l'autre des méthodes dépend des cas d'usage.

Un autre moyen d'augmenter la capacité d'un réseau LoRaWan est d'augmenter la densité des antennes, permettant ainsi de réduire le facteur d'étalement des capteurs et donc de libérer de la bande passante.


Exemples d'utilisation[modifier | modifier le code]

Articles connexes : Agriculture et Ville intelligente.

Smart City[modifier | modifier le code]

Une expérimentation d'un réseau privé LoRa a été réalisée dans un bâtiment (19 étages) dans le nord de l'Italie. L'objectif de cette installation est de surveiller et de contrôler la température et l'humidité de différentes pièces, dans le but de réduire les coûts liés au chauffage, à la ventilation et à la climatisation. L'expérimentation de Marco Centaro remonte à 2016. L'installation comprenant une passerelle, 32 capteurs et le serveur de collecte, est toujours opérationnelle et est considérée comme la solution technologique la plus adaptée pour plusieurs autres bâtiments[21].

Une étude a été réalisée par Fanghao Yu en 2017 sur le déploiement d'un réseau LoRaWAN pour la région du Grand Londres permettant de remonter la qualité de l'air et la surveillance de la congestion du trafic routier. La conception du réseau a montré qu'il était nécessaire d'installer 19 petites cellules pour le centre de Londres et 28 plus grandes cellules pour la grande périphérie de Londres. 11681 terminaux sont inclus dans les 47 cellules hexagonales. L'estimation du coût du matériel pour la qualité de l'air est de 83,7 k£[22].

Monitoring industriel[modifier | modifier le code]

La simulation de Kurtoglu en 2017 montre que LoRaWAN a un avantage énergétique important par rapport à ZigBee pour les réseaux de capteurs sans fil linéaires à longue portée, comme cela serait nécessaire pour surveiller certains types d'infrastructures telles que les lignes de transport et les pipelines. De plus, l'énergie requise pour limiter le point de consommation d'énergie le plus élevé du réseau, moins de 6 Joules par jour, est suffisamment faible pour rendre possible l'alimentation du réseau proposé en utilisant des sources d'énergie renouvelables telles que l'énergie solaire[18].

L'évaluation en 2016 par Petäjäjärvi de LoraWAN sur un cas réel d'usage d’équipement de santé Lora montre que les paquets sont reçus à 96,7 %, sur tout le campus d'Oulu en Finlande. Le campus recouvre une surface de 570 mètres sur 320 mètres, essentiellement à l'intérieur des bâtiments. Le résultat de l'étude montre que LoRa est une technologie attractive pour la surveillance des patients, la gestion du personnel dans les hôpitaux, la surveillance du bien-être du personnel sur le lieu de travail, ainsi que le suivi de la santé et la sécurité des personnes en extérieur[23].

Agriculture[modifier | modifier le code]

L'étude menée par Bellini sur l’activité des bovins permet de connaitre leur température et donc leur état de santé, avec un capteur accéléromètre pour connaitre leur activité. Chaque animal possède un collier avec un accéléromètre et une connectivité sans fil avec un équipement LoRa utilisant le réseau LoRaWAN. La batterie de 400 mAh avec une transmission toutes les heures des informations de l'accéléromètre sur une distance de plus de 10 km, a une durée de vie de 5 ans. Le coût du matériel revient à 25 dollars pour 100 unités[19].

Aspect sécurité[modifier | modifier le code]

Protocoles de sécurité utilisés[modifier | modifier le code]

LoRaWAN implémente plusieurs clefs, propres à chaque équipement terminal, afin d'assurer la sécurité des échanges au niveau réseau et applicatif.

Une clef AES d'une longueur de 128 bits appelée Appkey est utilisée pour générer les clefs NwkSKey et AppSKey[24].

La clef NwkSKey est utilisée par le serveur et l'équipement d'extrémité pour générer le champ d'intégrité MIC présent dans les paquets. Ce champ permet d'assurer que le paquet n'a pas été modifié en cours de transfert par un équipement malveillant. Cette clef est également utilisée pour chiffrer le contenu des messages contenant uniquement des commandes MAC[3].

La clef AppSKey est utilisée pour chiffrer les données applicatives présentes dans le paquet. Cette clef assure seulement la confidentialité du contenu du message mais pas son intégrité, ce qui signifie que si les serveurs réseau et applicatifs sont distincts, le serveur réseau est capable de modifier le contenu du message. De ce fait, la spécification LoRaWAN recommande d'utiliser des méthodes de protections de bout en bout supplémentaires pour les applications qui nécessiteraient un degré de sécurité supérieur[3].

Afin d'assurer de façon unique l'identité des équipements d'extrémité et des applications, le protocole définit également les champs DevEUI et AppEUI chacun d'une longueur de 64 bits. DevEUI permet d'identifier l'équipement et AppEUI permet quant à lui d'identifier l'application qui traitera sa demande d'accès au réseau. Ces champs sont configurés dans les équipements[3]. Lors de la procédure d'activation OTAA, l'équipement envoie en clair une requête non-chiffrée au serveur contenant les champs DevEUI, AppEUI ainsi qu'un nombre aléatoire de 16 bits. Le serveur vérifie si l'équipement a utilisé précédemment le nombre aléatoire avant d'accepter sa requête. Si le nombre a été précédemment utilisé par l'équipement, le serveur peut implémenter 2 comportements :

  • Il ne traite pas la demande et traite la requête suivante si elle dispose d'un nombre valide;
  • Il ne traite pas la demande et exclut de manière permanente d'équipement du réseau[25].

Problématiques de sécurité[modifier | modifier le code]

  • Attaque par la procédure d'activation

La procédure d'activation dite Over the Air est initialisée par un échange de messages : JOIN REQUEST, JOIN ACCEPT entre l’équipement et le serveur. Les informations du JOIN MESSAGE (AppEUI (8 octets), DevEUI (8 octets), and DevNonce (2 octets)) sont transmises en clair. Cette vulnérabilité peut être exploitée[26].

Taille(bytes) 8 8 2
message d'activation

Join Request

AppEUI DevEUI DevNonce

-Dans le cas ou un équipement devant effectuer régulièrement des procédures de JOIN du réseau, l’étude[27] de SeungJae Na montre qu'un attaquant peut utiliser une faille de sécurité dans la requête d’accès au réseau et ainsi empêcher des équipements d'utiliser le réseau LoraWAN. Pour cela l'attaquant écoute et collecte toutes les requêtes de demande d’accès (JOIN REQUEST) transmises en clair, analyse et envoie avant l’équipement la demande d'activation. Le serveur ayant répondu à la demande JOIN REQUEST de l'attaquant, lorsque l’équipement veut rejoindre le réseau, le serveur le refusera.

-Le champ DevNonce est une valeur aléatoire générée par l’équipement. Ce champ est utilisé par le serveur pour distinguer la duplication de message d'activation. Si le serveur a déjà reçu la demande d'activation, il peut soit supprimer la demande et attendre une nouvelle demande avec un autre DevOnce, soit le serveur exclut définitivement l’équipement du réseau. Bien que le protocole préconise l'utilisation de la première option, certains constructeurs ont implémenté la deuxième. L’étude de Tomasin en 2017 montre la probabilité d'une Attaque par déni de service même sans la présence d'un attaquant, en raison de la régénération d'un DevNonce déjà utilisé par l'objet, mais aussi la possibilité de générer des nombres aléatoires afin d'effectuer une attaque par déni de service d'un objet[26].

L’étude de JungWoon Lee en 2017 montre la possibilité de changer un champ particulier sans décrypter le message sur le réseau LoRaWAN. La méthode de Bit-Flipping Bit-flipping_attack (en) peut être utilisée car sur le réseau LoraWAN le texte chiffre est prévisible. JungWoon Lee propose une solution de contournement en changeant l'emplacement des octets dans les trames[28].

Déploiements[modifier | modifier le code]

La LoRa Alliance annonce 62 réseaux publics d'opérateurs en service en décembre 2017 ainsi que plus de 100 pays avec un service LoRaWAN disponible[29].

Comparatif technologique[modifier | modifier le code]

LoRaWAN fait partie des réseaux étendus à faible consommation énergétique, définis par le terme anglais : LPWAN (Low Power Wide Area Network) Pour comparer les technologies présentes dans le Réseau LPWAN, il est important de distinguer la période précédent l'arrivée de ce réseau dans un premier temps (Pré LPWAN), de voir l'arrivée des différents réseaux ou protocoles LPWAN et enfin de les comparer.

Pré LPWAN[modifier | modifier le code]

Le réseau LoraWan fait partie des réseaux LPWAN et des réseaux longues distances WWAN.

Les deux principales méthodes d'accès aux données reposaient soit sur des réseaux maillés utilisant des technologies de communication à courte portée (WPAN, WLAN) dans le spectre sans licence, soit sur des technologies cellulaires à longue portée, principalement 2G/GSM/GPRS.

Les technologies de transmission à courte portée multi-sauts, telles que ZigBee et Bluetooth, ont été considérées comme un moyen viable de mettre en œuvre l'Internet des objets (Internet of Things ou IOT). Bien que ces technologies impliquent une très faible consommation d'énergie, la couverture très limitée constitue un obstacle majeur, en particulier lorsque les applications nécessitent une couverture urbaine. Ces types de réseau sont plus détaillés dans l'article Liaison sans fil à faible consommation énergétique.

Les réseaux cellulaires sans fil (2G/GSM/GPRS) sont capables de fournir une couverture omniprésente et peuvent jouer un rôle fondamental dans la propagation de l'Internet des objets (Internet of Things IoT). Cependant, les normes (2G/GSM/GPRS) du réseau cellulaire n'ont pas été conçues pour fournir des services de type M2M à un grand nombre d'appareils[38]. De plus, les modems de ces appareils gaspillent une quantité importante d'énergie due à une écoute permanente et à un fort besoin de puissance d’émission réception[39].

LPWAN[modifier | modifier le code]

Le développement des technologies LPWAN (Low Power Wide Area Network) doit permettre une couverture à longue portée de quelques kilomètres à quelques dizaines de kilomètres, consommer une puissance de fonctionnement ultra-faible et avoir la capacité de supporter un ensemble varié d'applications avec des exigences de transmission de données variées. Sur le plan commercial, un LPWAN doit avoir le mérite d'avoir un faible coût en termes de dispositifs, d'infrastructure et en spectre de fréquences[38].

2008
On-Ramp Wireless est fondée en 2008, renommé Ingenu (en) en septembre 2015. Ingenu de On-Ramp Wireless a été le pionnier de la norme 802.15.4k. La société a développé et détient les droits de la technologie brevetée appelée RPMA (Random Phase Multiple Access). Contrairement aux autres solutions LPWAN, cette technologie fonctionne dans la bande des 2,4 GHz mais, grâce à une conception de couche physique robuste, elle peut toujours fonctionner sur des liaisons sans fil à longue portée et dans les environnements RF les plus difficiles[40].
2009
SIGFOX, la première technologie LPWAN proposée sur le marché de l'internet des objets, a été fondée en 2009. La couche physique SIGFOX utilise la modulation sans fil à bande ultra étroite (UNB), et le protocole réseau est propriétaire SIGFOX. Le business model SIGFOX est celui d'un opérateur pour les services IoT, qui n'a donc pas besoin d'ouvrir les spécifications de ses modules internes. Les premières versions de la technologie supportaient uniquement une communication unidirectionnelle ascendante, la communication bidirectionnelle est supportée depuis 2014[40],[41],[42].
2012
Acquisition de la société Grenobloise Cycleo, inventeur de LoRaWan, par la société americaine Semtech[43]
2013
Weightless (en) a développé trois standards ouverts pour LPWAN: Weightless-W, Weightless-N, et Weightless -P[41] :
  1. Weightless-W Standard publié en 2013, fonctionne dans les espaces blancs (non utilisés) de la télévision (470 -790 MHz).
  2. Weightless-N standard publié en 2015, étend la portée de Weightless-W et réduit sa consommation.
2015
Entrée sur le marché de l'IoT des solutions industrielles Sigfox et OnRamp Wireless et LoRaWAN, et élaborations de norme coté ETSI et IEEE[43].
2015-2016
3GPP : les technologies d'accès radio cellulaire ; 3GPP a développé trois nouvelles technologies pour le support de l'internet des objets :
  1. eMTC (LTE Cat.M) : eMTC est une évolution des travaux développés dans la version 12 des normes 3GPP 36.xxx, il fonctionne dans les bandes LTE.
  2. NB-IoT : Internet des objets à bande étroite (les spécifications de base ont été achevées en juin 2016).
  3. EC-GSM-IoT : Couverture étendue à l'Internet des objets du GSM ; c'est une évolution du service de radiocommunication par paquets général évolué (EGPRS) vers l'Internet des objets[41].

2017

Création de la technologie Wize, une technologie LPWAN dérivée du standard Européen Wireless MBus EN13757 [44]et utilisant la fréquence 169 MHz. Le protocol Wize a été créé par les entreprises françaises GRDF, Suez et Sagemcom. La technologie Wize est régie par la Wize Alliance.[45]

Comparatif technique[modifier | modifier le code]

Bardyn en 2016 a comparé différentes solutions pour répondre aux exigences des objets dédiés au segment LPWAN de l'internet des objets. Les marchés cibles des différentes solutions LPWAN sont majoritairement différents ; l'exploitation des bandes sous licence est plus avantageuse pour certains services ayant besoin de QoS et d'une latence garantie et les bandes sans licence offrent généralement une meilleure couverture, un coût moindre et nécessitent une puissance plus faible[46].

Dans sa comparaison en 2017 entre LoRa et NB-IoT, Yang montre que les deux types de réseau ont leur place sur le marché de l'internet des objets. LoRa se concentre sur les applications à faible coût. Alors que NB-IoT est orienté vers les applications qui requièrent une QoS élevée et une faible latence[47].

Tableau comparatif[48],[49]
Standard / Propriétaire Global Standard Modulation Bande fréquence Débit (montant/descendant) Distance Nomb. de canaux
UL : montant
DL : descendant / signaux orthogonaux
Topologie Fonction de débit adaptatif Authentification & chiffrement
LoRa Alliance LoRaWAN CSS Sub-GHz ISM band : EU (433 MHz, 868 MHz), US (915 MHz), Asia (430 MHz) 0,3-37,5 kb/s (Lora)
50 kb/s (FSK)
km (urbain), 15 km (rural) 10 en EU, 64+8 (UL) et 8 (DL) aux États-Unis plus multiple SFs Réseau en étoile oui AES 128b
Propriétaire Sigfox UNB DBPSK (UL), GFSK (DL) Sub-GHz ISM band : EU (868 MHz), US (902 MHz) 100 b/s (UL)
600 b/s (DL)
10 km (urbain), 50 km (rural) 360 canaux Réseau en étoile non encryption non supportée
Propriétaire Ingenu (en) RPMA RPMA-DSSS (UL), CDMA (DL) ISM band 2,4 GHz 78 kb/s (UL)
19,5 kb/s (DL)
15 km (urbain) 40 canaux 1 MHz, jusqu'à Modèle:Formanum:1200 signaux par canal Réseau en étoile, Réseau hiérarchique oui 16B hash, AES 256b
3GPP LTE-Cat M (eMTC) Release 12 UL : SC-FDMA DL : OFDMA licence UL : 1 Mb/s
DL : 1 Mb/s
11 km
LTE-Cat NB1 (NB-IoT) Release 13 UL : SC-FDMA DL : OFDMA licence UL : 20 kbit/s (single-tone)
250 kbit/s (multi-tone)
DL : 250 kbit/s
1,5 km urbain, 20-40 km rural
EC-GSM, extended coverage GSM 8 PSK, GMSK licence 240 kb/s 1,5 km urbain, 20-40 km rural
Weightless-SIG (en) Weightless-W 16-QAM, BPSK, QPSK, DBPSK 470-790 MHz 1 kb/s-10 Mb/s km (urbain) 16 ou 24 canaux (UL) Réseau en étoile AES 128b
Weightless-N UNB DBPSK Sub-GHz ISM band EU (868 MHz), US (915 MHz) 30 kb/s-100 kb/s km (urbain) plusieurs canaux 200 Hz Réseau en étoile AES 128b
Weightless-P GMSK, offset-QPSK Sub-GHz ISM band ou licensed 200 b/s-100 kb/s km (urbain) plusieurs canaux 12,5 kHz Réseau en étoile AES 128/256b
DASH7 Alliance DASH7 Alliance Protocol 1.x GFSK Sub-GHz 433 MHz, 868 MHz, 915 MHz 9,6 - 55,6 - 166,7 kb/s 0-5 km (urbain) 3 différents types de canaux (le nombre dépend du type et de la région) Réseau en étoile, Réseau hiérarchique AES 128b
IEEE IEEE 802.15.4k DSSS, FSK Sub-GHz ISM band & 2,4 GHz 1,5 b/s - 128 kb/s km (urbain) plusieurs canaux. Le nombre dépend du canal et de la modulation Réseau en étoile AES128b

Lora Alliance[modifier | modifier le code]

La LoRa Alliance est une association à but non lucratif dont le but est de standardiser le réseau LoRaWAN pour apporter un moyen fiable à l'internet des objets (IoT) pour se connecter à Internet. Cette association a été créée par Semtech et de nombreux acteurs industriels font partie de la LoRa Alliance pour garantir l’interopérabilité et la standardisation de la technologie LoRa[50],[51],[52].

Références[modifier | modifier le code]

  1. Raza 2017, p. 859
  2. a et b Raza 2017, p. 858
  3. a b c d e f g h et i LoRa Alliance 2016
  4. Raza 2017, p. 862
  5. a b c d et e Augustin 2016, p. 10
  6. a et b Goursaud 2015, p. 4
  7. a b c d e et f Adelantado2017 2017, p. 2
  8. Augustin 2016, p. 4
  9. Marcelis 2017, p. 101
  10. a et b Georgiou 2017, p. 163
  11. a b c d et e Adelantado2017 2017, p. 3
  12. Casals 2017, p. 5
  13. a b et c Augustin 2016, p. 6
  14. Mikhaylov 2017, p. 3
  15. a b c et d Augustin 2016, p. 11
  16. Oniga 2017, p. 422
  17. Yu 2017, p. 335
  18. a b et c Kurtoglu 2017, p. 1166
  19. a et b Bellini 2017, p. 4
  20. Petäjäjärvi 2017, p. 162
  21. Centenaro 2016, p. 65
  22. Yu 2017, p. 339
  23. Petäjäjärvi 2016, p. 5
  24. Aras 2017, p. 3
  25. Tomasin 2017
  26. a et b Tomasin 2017, p. 2
  27. Na 2017, p. 718
  28. Lee 2017, p. 551
  29. loraAllianceHome 2017
  30. Bouygues 2015
  31. 01net 2015
  32. kpn 2015
  33. swisscom 2015
  34. geko2015 2015
  35. fastnet 2015
  36. a et b TheThingNetwork 2017
  37. TheThingNetwork, 2017 et id 2015
  38. a et b Yu 2017, p. 334
  39. Centenaro 2016
  40. a et b Centenaro 2016, p. 63
  41. a b et c Adelantado 2017, p. 34
  42. Raza 2017, p. 6
  43. a et b Margelis 2015, p. 1
  44. (en-GB) Smart Energy International, « Wireless M-Bus breaking new ground in metering & industrial applications », sur Smart Energy International, (consulté le 26 juillet 2019)
  45. « Wize, le standard IoT qui transperce les murs et sous-sols », sur www.journaldunet.fr (consulté le 26 juillet 2019)
  46. Bardyn 2016, p. 30
  47. Yang 2017, p. 144-145
  48. Raza 2017, p. 861
  49. Raza 2017, p. 863
  50. lemagit 2016
  51. Lora Alliance Home 2016
  52. Business Wire 2016

Bibliographie[modifier | modifier le code]

Spécifications[modifier | modifier le code]

  • (en) LoRa Alliance, LoRaWAN Specification, , 70 p. (lire en ligne). 

Publication à comité de relecture[modifier | modifier le code]

  • (en) Ferran Adelantado, Xavier Vilajosana, Pere Tuset-Peiro, Borja Martinez et Joan Melia-Segui, « Understanding the Limits of LoRaWAN », IEEE Communications Magazine, vol. 55, no 9,‎ , p. 34-40 (ISSN 0163-6804, DOI 10.1109/MCOM.2017.1600613). 
  • (en) Usman Raza, Parag Kulkarni et Mahesh Sooriyabandara, « Low Power Wide Area Networks: An Overview », IEEE Communications Surveys & Tutorials, vol. 19, no 2,‎ , p. 855-873 (ISSN 1553-877X, DOI 10.1109/COMST.2017.2652320). 
  • (en) Konstantin Mikhaylov, Juha Petäjäjärvi et Jussi Haapola, « D2D communications in LoRaWAN Low Power Wide Area Network: From idea to empirical validation », 2017 IEEE International Conference on Communications Workshops (ICC Workshops),‎ (ISSN 2474-9133, DOI 10.1109/ICCW.2017.7962746)
  • (en) Paul J. Marcelis, Vijay S. Rao et R. Venkatesha Prasad, « DaRe: Data Recovery through Application Layer Coding for LoRaWAN », 2017 IEEE/ACM Second International Conference on Internet-of-Things Design and Implementation (IoTDI),‎ (DOI 10.1145/3054977.3054978). 
  • (en) Aloÿs Augustin, Jiazi Yi et Thomas Clausen, « A Study of LoRa: Long Range & Low Power Networks for the Internet of Things », Sensors Special Issue Enabling the Move from Wireless Sensor Networks to Internet of Things and Cyber-Physical Systems,‎ (DOI 10.3390/s16091466). 
  • (en) Georges Margelis, Robert Piechocki et Dritan Kaleshi, « Low Throughput Networks for the IoT: Lessons learned from industrial implementations », 2015 IEEE 2nd World Forum on Internet of Things (WF-IoT),‎ (ISBN 978-1-5090-0366-2, DOI 10.1109/WF-IoT.2015.7389049). 
  • (en) Valentin Alexandru Stan, Radu Serban Timnea et Razvan Andrei Gheorghiu, « Overview of high reliable radio data infrastructures for public automation applications: LoRa networks », 2016 8th International Conference on Electronics, Computers and Artificial Intelligence (ECAI),‎ (ISBN 978-1-5090-2047-8, DOI 10.1109/ECAI.2016.7861130)
  • (en) Georgiou Orestis et Raza Usman, « Low Power Wide Area Network Analysis: Can LoRa Scale? », IEEE Wireless Communications Letters, vol. 6, no 2,‎ , p. 162-165 (ISSN 2162-2337, DOI 10.1109/LWC.2016.2647247). 
  • (en) Sarra Naoui, Mohamed Elhoucine Elhdhili et Leila Azouz Saidane, « Enhancing the security of the IoT LoraWAN architecture », 2016 International Conference on Performance Evaluation and Modeling in Wired and Wireless Networks (PEMWN),‎ (ISBN 978-1-5090-2670-8, DOI 10.1109/PEMWN.2016.7842904)
  • (en) Stefano Tomasin, Simone Zulian et Lorenzo Vangelista, « Security Analysis of LoRaWAN Join Procedure for Internet of Things Networks », Wireless Communications and Networking Conference Workshops (WCNCW), 2017 IEEE,‎ (ISBN 978-1-5090-5908-9, DOI 10.1109/WCNCW.2017.7919091). 
  • (en) Martin Bor, John Vilder et Utz Roedig, « LoRa for the Internet of Things », EWSN '16 Proceedings of the 2016 International Conference on Embedded Wireless Systems and Networks,‎ , p. 361-366 (ISBN 978-0-9949886-0-7, DOI 10.1109/WF-IoT.2015.7389049)
  • (en) Martin Bor, Utz Roedig, Thiemo Voigt et Juan M.Alonso, « Do LoRa Low-Power Wide-Area Networks Scale? », MSWiM '16 Proceedings of the 19th ACM International Conference on Modeling, Analysis and Simulation of Wireless and Mobile Systems,‎ , p. 59-67 (ISBN 978-1-4503-4502-6, DOI 10.1145/2988287.2989163)
  • (en) Valery Tikhvinskiy, Pavel Korchagin, Grigory Bochechka, Andrey Gryazev et Altay Aytmagambetov, « Spectrum sharing in 800 MHz band: Experimental, estimation of LoRa networks and air traffic control radars co-existence », 2017 International Symposium on Electromagnetic Compatibility - EMC EUROPE,‎ (ISBN 978-1-5386-0689-6, DOI 10.1109/EMCEurope.2017.8094705)
  • (en) Lorenzo Vangelista, « Frequency Shift Chirp Modulation: The LoRa Modulation », IEEE Signal Processing Letters, vol. 24, no 12,‎ , p. 1818-1821 (ISSN 1558-2361, DOI 10.1109/LSP.2017.2762960)
  • (en) L. Angrisani, P. Arpaia, F. Bonavolontà, M. Conti et A. Liccardo, « LoRa protocol performance assessment in critical noise conditions », 2017 IEEE 3rd International Forum on Research and Technologies for Society and Industry (RTSI),‎ (ISBN 978-1-5386-3906-1, DOI 10.1109/RTSI.2017.8065952)
  • (en) Claire Goursaud et Jean Marie Gorce, « Dedicated networks for IoT : PHY / MAC state of the art and challenges », EAI endorsed transactions on Internet of Things, 2015,‎ (DOI 10.4108/eai.26-10-2015.150597). 
  • (en) A Kurtoglu, J Carletta et K.S. Lee, « Energy consumption in long-range linear wireless sensor networks using LoRaWan and ZigBee », 2017 IEEE 60th International Midwest Symposium on Circuits and Systems (MWSCAS),‎ (DOI 10.1109/MWSCAS.2017.8053135). 
  • (en) Juha Petäjäjärvi, Konstantin Mikhaylov et Matti Hämäläinen, « Evaluation of LoRa LPWAN technology for remote health and wellbeing monitoring », IEEE,‎ (ISSN 2326-8301, DOI 10.1109/ISMICT.2016.7498898)
  • (en) Juha Petäjäjärvi, Konstantin Mikhaylov et Matti Hämäläinen, « Evaluation of LoRa LPWAN Technology for Indoor Remote Health and Wellbeing Monitoring », Springer US, vol. 24, no 2,‎ , p. 153–16 (ISSN 1068-9605, DOI 10.1007/s10776-017-0341-8). 
  • (en) Lluís Casals, Bernat Mir, Rafael Vidal et Carles Gomez, « Modeling the Energy Performance of LoRaWAN », Sensors,‎ (DOI 10.3390/s17102364). 
  • (en) Pierre Neumann, Julien Montavont et Thomas Noël, « Indoor deployment of low-power wide area networks (LPWAN): A LoRaWAN case study », IEEE,‎ (DOI 10.1109/WiMOB.2016.7763213)
  • (en) Bogdan Oniga, Vasile Dadarlat et Eli De Poorter, « Analysis, design and implementation of secure LoRaWAN sensor networks », IEEE,‎ (DOI 10.1109/ICCP.2017.8117042)
  • (en) Bernat Carbonés Fargas et Martin Nordal Petersen, « GPS-free geolocation using LoRa in low-power WANs », IEEE,‎ (DOI 10.1109/GIOTS.2017.8016251). 
  • (en) Brecht Reynders, Wannes Meert et Sofie Pollin, « Power and Spreading Factor Control in Low Power Wide Area Networks », IEEE,‎ (ISSN 1938-1883, DOI 10.1109/ICC.2017.7996380)
  • (en) Bruno Bellini et Alfredo Amaud, « A 5μΑ wireless platform for cattle heat detection », IEEE,‎ (ISSN 2473-4667, DOI 10.1109/LASCAS.2017.7948089). 
  • (en) SeungJae Na, DongYeop Hwang et WoonSeob Shin, « Scenario and countermeasure for replay attack using join request messages in LoRaWAN », IEEE,‎ (DOI 10.1109/ICOIN.2017.7899580). 
  • (en) JungWoon Lee, DongYeop Hwang et JiHong Park, « Risk Analysis and Countermeasure for Bit-Flipping Attack in LoRaWAN », IEEE,‎ (DOI 10.1109/ICOIN.2017.7899554). 
  • (en) Marco Centenaro, Lorenzo Vangelista et Andrea Zanella, « Long-range communications in unlicensed bands: The rising stars in the IoT and smart city scenarios », IEEE,‎ (DOI 10.1109/MWC.2016.7721743). 
  • (en) Nikoleta Andreadou, Miguel Olariaga Guardiola et Gianluca Fulli, « Telecommunication Technologies for Smart Grid Projects with Focus on Smart Metering Applications », energies,‎ (DOI 10.3390/en9050375). 
  • (en) Fanghao Yu, Ziming Zhu et Zhong Fan, « Study on the feasibility of LoRaWAN for smart city applications », IEEE,‎ , p. 34-40 (DOI 10.1109/WiMOB.2017.8115748). 
  • (en) Emekcan Aras, Gowri Sankar Ramachandran, Piers Lawrence et Danny Hughes, « Exploring The Security Vulnerabilities of LoRa », 2017 3rd IEEE International Conference on Cybernetics,‎ (DOI 10.1109/CYBConf.2017.7985777). 
  • (en) Jean-Paul Bardyn, Thierry Melly et Olivier Seller, « IoT: The era of LPWAN is starting now », IEEE,‎ (DOI 10.1109/ESSCIRC.2016.7598235). 
  • (en) Wenjie Yang, Mao Wang et Jingjing Zhang, « Narrowband Wireless Access for Low-Power Massive Internet of Things: A Bandwidth Perspective », IEEE,‎ , p. 138-145 (DOI 10.1109/MWC.2017.1600298). 

Publications diverses[modifier | modifier le code]

Voir aussi[modifier | modifier le code]

Articles connexes[modifier | modifier le code]