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, née à la suite de l'acquisition de la startup grenobloise Cycléo 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].

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 leur application. 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]. Cependant une étude de 2017 menée par Konstantin Mikhaylov montre que son activation, si les équipements terminaux sont suffisamment proches, permet d'améliorer leur consommation énergétique en réduisant le facteur d'étalement (spreading factor) nécessaire à la réception des données (voir partie consommation énergétique)[6].

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[7]. Cette modulation permet une distance entre une passerelle et un équipement jusqu'à 5 km en zone urbaine et 15 km en zone rurale[8].

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 profite de cet étalement en fréquence pour fonctionner avec un signal faible ou fortement bruité[7]. 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[9]. Une étude de 2017 a montré que la résistance à l'effet Doppler de la modulation LoRa est avérée en comparant le taux de réception de paquets entre une passerelle et un équipement installé sur une moto[10].

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[11].

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[8].

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[11].

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[12].

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[8]. Sur la bande 868 MHz, la spécification LoRa impose 3 canaux d’une largeur de 125 kHz communs à tous les équipements 868,10 MHz, 868,30 MHz et 868,50 MHz[3]. 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 un chiffre 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[13] :

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é[14].
  • 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)[12].
  • Le code rate pour le reste de la trame peut être paramétré de 4/5 à 4/8[14], le taux 4/5 étant le plus utilisé[15].

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

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. Il repose sur un fonctionnement de type ALOHA, 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 retransmet le message après un temps aléatoire s'il a été perdu[2].


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[8].

  • 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[8].
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[8]. 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[16].

Format des paquets LoRaWAN

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

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[16] :

  • 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[17].

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

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[16].

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[18].

  • 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[19] 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)[19] :

é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

L’étude de Bellini en 2017 montre que la consommation de la batterie dépend essentiellement de la stratégie de transmission des informations. Son système pour l’étude sur l’activité des bovins dans une grande ferme de l'Uruguay avec un capteur accéléromètre et un émetteur Semtech SX1276 a fonctionné comme espéré avec une distance maximum de 11,4 km. Après avoir mesuré la durée de vie de la batterie en fonction de différentes combinaisons de configuration du réseau LoRa : fréquence, facteur d'étalement du spectre (SF : Spread Factor), correction d'erreur (CR : error Correction Rate), le système consomme en moyenne 5 µA ce qui correspond à une durée de vie de 5 années pour une batterie de 400 mA, en envoyant des données toutes les heures[20]. L’étude de Petäjäjärvi en 2017[21] montre le rôle majeur de la puissance d'émission sur la consommation d'énergie. Les quantités d'énergie consommées pour le même paquet envoyé avec la puissance d'émission minimale et maximale diffèrent de plus de 50 %. Ces mesures ont été faites sur le module LoraMicrochip's RN2483 avec les caractéristiques ci-dessous :

équipement Émission(mA) Reception(mA) attente
LoraWan SX1272 Min : 18 mA (7dBm)

Max : 125 mA (20dBm)

10,5 ou 11,2 0,1 uA
LoraWan RN2483 Min : 17,3 mA (-4.0dBm)

Max : 38,9 mA (14.1dBm)

14,2 100-150 uA
  • L'optimisation de la consommation d’énergie en déportant la complexité du réseau au serveur est en autre mise en application en utilisant le débit adaptatif et la fonction GPS.

Pour optimiser le débit et la puissance d'émission pour les équipements, l’étude de Petäjäjärvi en 2017[21] souligne l'importance de la sélection du mode de fonctionnement de la radio et de l'utilisation de la fonction de débit adaptatif pour optimiser le débit et la puissance d'émission pour les équipements. Cette fonction permet au serveur de détecter la puissance d'un paquet en réception. Si le paquet a assez de puissance le serveur commande à l’équipement de basculer sur un facteur d'étalement du spectre (Spread Factor) plus petit.

L'étude de Carbonés en 2017 montre que la consommation de l’équipement pour avoir une position est de 12,9 mA avec LoRaWAN, alors qu'en GSM + GPS la consommation est de 400-600 mA[22]. La fonction de GPS dans le réseau LoRaWAN consiste à l'envoi par l’équipement de données vers les passerelles. Les passerelles horodatent les informations et les retransmettent par un message MQTT Message Queue Telemetry Transport vers le serveur. L’algorithme sur le serveur nécessite qu'au moins 4 passerelles retransmettent le message horodaté pour calculer la position. Les deux algorithmes utilisés dans l'étude montrent qu'il est possible de localiser un objet avec une approximation de 100 mètres. Cette précision peut être améliorée car les ressources nécessaires sont sur le serveur.

Dans son article, Casals[23] a modélisé la consommation des équipements LoRa de classe A en prenant en compte l'impact des transmissions non acquittées et acquittées, des débits de données (DR), de la taille de la charge utile des trames et du taux d'erreur sur les bits (BER : Bit error ratio).

  • Il montre que pour un taux d'erreur sur les bits : BER = 0, la transmission acquittée réduit la consommation moyenne de l'appareil final LoRaWAN. Cela se produit parce qu'un accusé de réception peut être envoyé dans la première fenêtre de réception, alors qu'une transmission sans accusé de réception implique deux fenêtres de réception et une consommation de courant moyenne plus grande qu'un accusé de réception de transmission dans la première fenêtre de réception.
  • En revanche, pour un taux d'erreur sur les bits (BER) non négligeable, la transmission acquittée entraîne une consommation de courant supérieure à la transmission non acquittée, du fait des tentatives de ré-envoi des messages.
  • Un terminal fonctionnant sur une batterie de 2 400 mAh et envoyant un message toutes les 5 minutes peut atteindre une durée de vie de 1 an. À mesure que la période des notifications augmente, la durée de vie théorique du dispositif final tend asymptotiquement vers environ 6 ans dans les conditions considérées.

Aspect capacitaire[modifier | modifier le code]

Plusieurs études se sont intéressées à l'aspect capacitaire de LoRaWAN, cet aspect étant particulièrement important pour un protocole dédié à l'internet des objets. En 2016, une étude de Martin Bor estime la limite d'un réseau LoRaWAN typique à 120 équipements terminaux pour 3,8 hectares ce qui est trop peu pour un environnement urbain[24]. Une autre étude menée en 2017 par Orestis Georgiou et Usman Raza montre que la couverture dans un réseau LoRaWAN diminue exponentiellement avec l'augmentation du nombre d'équipements terminaux connectés à cause des interférences auto-générées[11].

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[12].

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[12] :

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. Le nombre de paquets reçus diminue à cause des collisions car la probabilité que plusieurs équipements utilisent le même SF sur le même canal augmente et cela malgré le respect du duty-cycle de la bande 868 MHz[12].

Taille des données Nombre d'équipements Nombre de paquets par heure reçus
10 octets 250 400
10 octets 500 200
10 octets 750 100

Le réseau The Things Network a défini une manière simple de diminuer l'effet limitant du duty-cycle dans un réseau LoRaWAN d'envergure avec une politique nommée «TTN Fair Access Policy»[25]. Cette politique limite, pour un équipement d'extrémité, le temps d'émission montant à 30 secondes par jour et les messages descendants à 10 par jour[26].

Une étude de 2017 menée par Paul Marcelis montre que s'il n'est pas complètement possible dans un réseau LoRaWAN d'empêcher la perte de paquets due aux collisions il en revanche possible d'obtenir un fonctionnement applicatif normal en implémentant un algorithme de codage performant au niveau applicatif. La méthode de codage DaRe «Data Recovery through Application Layer Coding for LoRaWAN» permet via l'utilisation de codes fontaines (en) sur une fenêtre glissante d'aboutir à une récupération des données de 99% sur un réseau où la probabilité de perte d'un paquet est de 40%. Comparativement à une simple réémission des messages perdus, cette méthode permet également de réduire la consommation énergétique des équipements de 42%[27].

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érationnel et est considérée comme la solution technologique la plus adaptée pour plusieurs autres bâtiments[28].

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.Le design du réseau remonte la nécessité 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£[29].

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 maintenir 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[19].

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 délivrés à 96,7 %, sur tout le campus d'Oulu en Finlande. Le campus recouvre une surface de 570 mètres sur 320 mètres, essentiellement en bâtiment intérieur. 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[30].

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, en 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 à une durée de vie de 5 ans. Le coût du matériel revient à 25 dollars pour 100 unités[20].

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[31].

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[32].

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[33].

Taille(bytes) 8 8 2
message d'activation

Join Request

AppEUI DevEUI DevNonce

-Dans le cas ou un équipement s’éteint et s'allume régulièrement, l’étude[34] 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[33].

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[35].

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[36].

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 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[45]. 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[46].

LPWAN[modifier | modifier le code]

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

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[47].
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[47],[48],[49].
2012
LoraWan[50]
2013
Weightless (en) a développé trois standards ouverts pour LPWAN: Weightless-W, Weightless-N, et Weightless -P[48] :
  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
dans son étude Margelis constate l'entrée sur le marché de l'IoT des solutions industrielles Sigfox et OnRamp Wireless et LoRaWAN, et des élaborations de norme en cours coté ETSI et IEEE[50].
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[48].

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[51].

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[52].

Tableau comparatif[53],[54]
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 kbps(Lora)
50 kbps(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 AES128b
Propriétaire Sigfox UNB DBPSK(UL), GFSK(DL) Sub-GHz ISM band: EU(868 MHz), US(902 MHz) 100 bps(UL)
600 bps(DL)
10 km(urbain), 50 km(rural) 360 canaux Réseau en étoile non encryption non supporte
Propriétaire Ingenu (en) RPMA RPMA-DSSS(UL), CDMA(DL) ISM band 2,4 GHz 78 kbps(UL)
19,5 kbps(DL)
15 km(urbain) 40 canaux 1 MHz, jusqu'à 1200 signaux par canal Réseau en étoile, Réseau hiérarchique oui 16B hash, AES256b
3GPP LTE-Cat M (eMTC) Release 12 UL: SC-FDMA DL: OFDMA licence UL: 1 Mbps
DL: 1 Mbps
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 8PSK, GMSK licence 240 kbps 1,5 km urbain, 20-40 km rural
Weightless-SIG (en) Weightless-W 16-QAM, BPSK, QPSK, DBPSK 470-790 MHz 1 kbps-10 Mbps km(urbain) 16 ou 24 canaux(UL) Réseau en étoile AES128b
Weightless-N UNB DBPSK Sub-GHz ISM band EU(868 MHz), US(915 MHz) 30 kbps-100 kbps km(urbain) plusieurs canaux 200 Hz Réseau en étoile AES 128b
Weightless-P GMSK, offset-QPSK Sub-GHz ISM band ou licensed 200bps-100kbps km(urbain) plusieurs canaux 12,5 kHz Réseau en étoile AES128/256b
DASH7 Alliance DASH7 Alliance Protocol 1.x GFSK Sub-GHz 433 MHz, 868 MHz, 915 MHz 9,6 - 55,6 - 166,7 kbps 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 AES128b
IEEE IEEE 802.15.4k DSSS, FSK Sub-GHz ISM band & 2,4 GHz 1,5 bps - 128 kbps 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[55],[56],[57].

Liste des membres[modifier | modifier le code]

La pertinence de cette section est remise en cause. Considérez son contenu avec précaution. Améliorez-le ou discutez-en. (janvier 2018)

La LoRa Alliance propose 4 niveaux d'adhésion. La liste des membres est consultable sur le site internet de l'alliance[58].

Membres sponsors[modifier | modifier le code]

Membres contributeurs[modifier | modifier le code]

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. Mikhaylov 2017
  7. a et b Goursaud 2015, p. 4
  8. a, b, c, d, e et f Adelantado2017 2017, p. 2
  9. Augustin 2016, p. 4
  10. Marcelis 2017, p. 101
  11. a, b et c Georgiou 2017, p. 163
  12. a, b, c, d et e Adelantado2017 2017, p. 3
  13. Casals 2017, p. 5
  14. a, b et c Augustin 2016, p. 6
  15. Mikhaylov 2017, p. 3
  16. a, b, c et d Augustin 2016, p. 11
  17. Oniga 2017, p. 422
  18. Yu 2017, p. 335
  19. a, b et c Kurtoglu 2017, p. 1166
  20. a et b Bellini 2017, p. 4
  21. a et b Petäjäjärvi 2017, p. 162
  22. Carbonés 2017, p. 1165
  23. Casals 2017, p. 27-28
  24. Bor 2016
  25. Adelantado2017 2017, p. 5
  26. The Things Network 2017
  27. Marcelis 2017
  28. Centenaro 2016, p. 65
  29. Yu 2017, p. 339
  30. Petäjäjärvi 2016, p. 5
  31. Aras 2017, p. 3
  32. Tomasin 2017
  33. a et b Tomasin 2017, p. 2
  34. Na 2017, p. 718
  35. Lee 2017, p. 551
  36. loraAllianceHome 2017
  37. Bouygues 2015
  38. 01net 2015
  39. kpn 2015
  40. swisscom 2015
  41. geko2015 2015
  42. fastnet 2015
  43. a et b TheThingNetwork 2017
  44. TheThingNetwork, 2017 et id 2015
  45. a et b Yu 2017, p. 334
  46. Centenaro 2016
  47. a et b Centenaro 2016, p. 63
  48. a, b et c Adelantado 2017, p. 34
  49. Raza 2017, p. 6
  50. a et b Margelis 2015, p. 1
  51. Bardyn 2016, p. 30
  52. Yang 2017, p. 144-145
  53. Raza 2017, p. 861
  54. Raza 2017, p. 863
  55. lemagit 2016
  56. Lora Alliance Home 2016
  57. Business Wire 2016
  58. loraAllianceMembers 2017

Bibliographie[modifier | modifier le code]

Spécifications[modifier | modifier le code]

  • (en) LoRa Alliance, LoRaWAN Specification, 2016, 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]