Cours Lora Lorawan
Cours Lora Lorawan
Cours Lora Lorawan
pour
l'Internet des Objets
Version du cours : 10
Avril 2021
Sylvain MONTAGNY
www.linkedin.com/in/sylvainmontagny
sylvain.montagny@univ-smb.fr
Livre
Cette version PDF du livre est mise à disposition pour la communauté et peut être diffusée en l'état.
Toutes remarques / modifications / améliorations / corrections peuvent être proposées à l'auteur
via le lien suivant : https://cutt.ly/erreurs. L’auteur vous remercie par avance pour votre contribution.
Ce livre sur l’Internet des Objets et les protocoles LoRa / LoRaWAN est mis à jour régulièrement. Il
fait partie d’une formation LoRa proposée par l’Université de Savoie Mont Blanc dans le cadre du
Master Electronique Systèmes Embarqués et Télécommunications.
Cette formation est composée de 120 capsules vidéo d'une moyenne de 4mins. Elle reprend les
chapitres du livre avec en plus:
■ Des démonstrations.
■ Des explications supplémentaires qu'il est plus opportun de faire en vidéo.
■ Des détails sur les mises en ouvres et la configuration des Devices, Gateways et Serveurs.
Vous pouvez poser vos questions sur la plateforme, les formateurs vous répondront.
Matériel fourni : Nous vous envoyons Device et Gateway afin de mettre en œuvre un réseau
LoRaWAN. Vous conservez l'ensemble du matériel à l'issu de la formation.
Suivi personnalisé : Nous sommes à votre disposition tout au long de la formation, et nous
restons disponible à l'issu de celle-ci, pour répondre à vos éventuelles questions et besoins.
Homologuée OPCO : La formation peut être prise en charge par vos organismes de
formation professionnelle.
Avant la formation
Pendant la formation
■ Accompagnement.
■ Mise en œuvre pratique du LoRa.
■ Test des paramètres de transmission (Bandwidth, canaux, Spreading Factor).
■ Configuration de votre Gateway, utilisation d'un serveur LoRaWAN, création d'application
et enregistrement de Devices.
■ Test des différents modes d'activation (ABP et OTAA).
■ Test et spécificité des Devices classe A, transfert en Uplink, Downlink, confirmé ou non.
■ Test de l'Adaptive Data Rate (ADR).
■ Récupération des données (HTTP et MQTT).
■ Création de son propre Serveur LoRaWAN (TheThingsStack et Chirpstack).
■ Création de sa propre Application avec Dashboard.
Vos formateurs
Sylvain MONTAGNY
Florent Lorne
Cette formation est réalisée en partenariat avec ChipSelect, représentant de SEMTECH (France et
Bénélux). La formation a été présentée lors du Webinaire (janvier 2021) et peut être vue en Replay.
Légendes
Informations importantes
Exercices
Comparés aux autres systèmes électroniques, les systèmes embarqués utilisés dans l’IoT possèdent
donc :
WIFI 4G
3G
Bluetooth
2G
Zigbee
LoRa / SIGFOX
NFC NB-IOT / LTE-M
Portée (Range)
Dans ce cours, nous nous intéressons aux protocoles longue portée, faible débit et très faible
consommation. L’ensemble de ces réseaux sont dénommés LPWAN : Low Power Wide Area
Network.
Ce graphique ne montre pas la consommation pour lesquelles les deux protocoles LoRa et Sigfox
sont sans contestation les plus performants.
On remarque qu'en Europe, le LoRa peut utiliser la bande des 433 MHz ou des 868 MHz.
■ FDM (Frequency Division Multiplexing) : Les Devices utilisent des canaux fréquentiels pour
séparer leurs transmissions. Le LoRa utilise ce mode de partage, c’est-à-dire que la bande
libre des 868 MHz est découpée en plusieurs canaux où chaque Device peut dialoguer.
1 canal
■ TDM (Time Division Multiplexing). Dans ce mode de transmission, les Devices transmettent
par intermittence afin de laisser libre le canal à tour de rôle. Le LoRa utilise ce mode de
partage. En revanche les Devices ne sont pas synchronisés, donc des collisions peuvent
survenir.
■ CDMA (Code Division Multiple Access) : Dans ce mode de transmission, les Devices
transmettent en même temps, sur le même canal. La conséquence de ce type de
transmission est appelée "étalement du spectre". Le LoRa utile un mode de transmission
dont les propriétés sont assez similaires au CDMA.
1 canal
DEV 4
DEV 3 DEV 10
DEV 2 DEV 7 DEV 9
DEV 1 DEV 6 DEV 8
Les Devices LoRa ont le choix entre plusieurs canaux pour émettre. Sur un canal choisi, ils peuvent
transmettre à plusieurs, en même temps. Le protocole LoRa utilise une modulation très similaire à
la méthode de partage CDMA (pour autant, on ne pourra pas dire que le LoRa utilise le CDMA). Afin
de comprendre la pertinence de ce mode de partage du support, nous allons valider le
fonctionnement du mode CDMA dans le prochain paragraphe. Au chapitre 3, nous expliquerons
dans le détails la modulation LoRa.
La méthode consiste à utiliser des codes qui ont des propriétés mathématiques adaptées à notre
objectif : transmettre en même temps sur la même bande de fréquence. La matrice ci-dessous
donne par exemple 4 codes d’étalement (1 par ligne).
A l’émission :
■ Chaque bit du message est multiplié par un code d’étalement (une ligne de la matrice).
■ Le résultat de la multiplication est transmis.
A la réception :
1 Message User 1 1 0 1 0
2 Utilisation code orthogonal User 1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1
3 Symboles transmis User 1 = (1) x (2) 1 -1 1 -1 0 0 0 0 1 -1 1 -1 0 0 0 0
… transmission …
4 Utilisation code orthogonal User 1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1
5 Décodage = (3) x (4) 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0
6 Message reçu (∑ (5) / nbr_bits) 1 0 1 0
Les dernières colonnes des tableaux suivants sont laissées libres pour que vous puissiez tester les
calculs par vous-même.
Dans l’air :
■ On additionne les symboles transmis par tous les User (1, 2, 3). On additionne donc les lignes
suivantes :
Pour la réception :
Exercice : Le Talkie-Walkie a une puissance d’émission de 2W. Quelle est la puissance d’émission
exprimées en dBm ?
Réponse :
1 mW x 10 x 10 x 10 x 2 = 2 W
0 dBm + 10 + 10 + 10 + 3 = 33dBm
PR : Puissance Reçue
+
PB : Puissance du Bruit
PE : Puissance Emise
Bruit
L'émetteur transmet un signal (PE). Le récepteur récupère une fraction de ce signal (PR) à cause des
pertes, ainsi que du bruit PB qui vient se rajouter.
Toutes ces valeurs (RSSI, Sensibilité, SNR, …) sont données en décibel. Un signal pourra être reçu
convenablement si les deux conditions suivantes sont remplies :
Exercice : Un émetteur transmet à une puissance de 13dBm en utilisant une antenne dont le gain
est de 2dB. Les pertes dans l’air sont de 60 dB. L’antenne réceptrice qui possède un gain de 2dB est
reliée à un récepteur dont la sensibilité est de -80 dBm. Le signal pourra-t-il être reçu ?
Réponse :
-43 > -80 (sensibilité) Donc oui, le signal pourra être reçu
La figure ci-dessous donne un exemple de RSSI et de SNR relevés sur une Gateway lors d'une
transmission de donnée en LoRa. Les valeurs "rssi": -13 et "snr": 9.5 montre que dans cet exemple
le signal reçu arrive avec une forte puissance et avec un très bon rapport signal sur bruit.
Comment puis-je améliorer mon bilan de transmission? La première idée serait d'émettre plus fort
(augmenter PE). Ceci est possible dans une certaine mesure, car les puissances d'émission sont
limitées. En LoRa, la puissance d'émission maximum sur la bande 868 MHz est de 14 dBm (25 mW).
La seconde possibilité est d'améliorer la sensibilité du récepteur. Les concepteurs de modules LoRa
s'efforcent de l'améliorer jusqu'aux limites technologiques actuelles. Au final, ce qui compte, c'est
surtout la différence entre la puissance PE et la sensibilité du récepteur. C'est ce qu'on appelle le
Link Budget. Dans l’exemple précédent, le budget que nous avons à disposition est de 93dB.
𝐴𝑡𝑡é𝑛𝑢𝑎𝑡𝑖𝑜𝑛
)
10 10
𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 = √
1755. 𝑓𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑒 2
Le link Budget étant l'atténuation maximale que peut supporter une transmission, nous pouvons en
déduire la distance en remplaçant l'atténuation par le link budget :
𝐿𝑖𝑛𝑘 𝐵𝑢𝑑𝑔𝑒𝑡
)
10 10
Soit 𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 = √
1755.𝑓𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑒 2
■ Le transceiver LoRa SX1272 (Link Budget de 157 dB), cela nous donne une distance
théorique de 1940 km.
■ Le transceiver LoRa SX1276 (Link Budget de 168 dB), cela nous donne une distance
théorique de 6907 km.
En avril 2020, le record du monde de distance en transmission LoRa a été battu. Il est de 832 km
pour une puissance de 25 mW / 14 dBm (puissance maximale autorisée en Europe).
En reprenant la définition du Link Budget (PE moins la sensibilité du récepteur), on retrouve les 157
dB annoncés dans cette documentation (20 dBm + 137 dBm).
En LoRa, plus le code d’étalement est grand, plus on est capable d’émettre dans un milieu bruité. La
Figure 7 présente les rapports signal sur bruit avec lesquels nous seront capables de réaliser une
transmission, en fonction des Spreading Factor utilisés.
On remarque que pour un SF8, nous sommes capables d’émettre avec un SNR de -10 dB : on pourra
transmettre malgré le fait que le bruit est 10 fois supérieur au signal.
On remarque que pour un SF12, nous sommes capables d’émettre avec un SNR de -20 dB : on pourra
transmettre malgré le fait que le bruit est 100 fois supérieur au signal !
Cependant, on remarque aussi que l’utilisation d’un Spreading Factor plus élevé, augmente
considérablement le nombre de symbole émis (2ème colonne du tableau). Comme nous le verrons
plus tard, cela impactera évidement le temps de transmission.
La fréquence de départ est la fréquence centrale du canal moins la Bande Passante divisée par deux.
La fréquence de fin est la fréquence centrale du canal plus la Bande Passante divisée par deux :
Exercice : On considère une émission sur la fréquence centrale 868 MHz avec une Bande Passante
de 125 kHz. Donner la fréquence de début et la fréquence de fin du sweep.
Réponse :
En LoRa, chaque symbole représente un certain nombre de bits transmis. La règle est la suivante :
Par exemple, si la transmission utilise un Spreading Factor de 10 (SF10), alors un symbole représente
10 bits.
C’est-à-dire qu’à l’émission, les bits sont regroupés par paquet de SF bits, puis chaque paquet est
représenté par un symbole particulier parmi 2𝑆𝐹 formes de symboles possibles.
Sur la figure suivante, voici un exemple théorique d’une modulation en SF2 à 868 MHz, sur une
bande passante de 125 kHz. Chaque symbole représente donc 2 bits.
Exemple :
Nous regroupons donc les bits par paquet de 10. Chaque paquet de 10 bits sera représenté par un
symbole (sweep) particulier. Il y a 1024 symboles différents pour coder les 1024 combinaisons
binaires possibles (210).
Avec un outil d’analyse spectrale actif pendant l’émission LoRa d’un Device, on peut afficher les
successions de symboles qui sont envoyées. Cet oscillogramme a été réalisé à l’aide d’un SDR
(Software Digital Radio).
Figure 12 : Visualisation des Chirps LoRa réellement émis pendant une transmission
SF9
SF10
Fréquence centrale
SF11
SF12
Fréquence basse
Temps
Le temps d’émission d’un symbole (Tsymbole) est inversement proportionnel à la bande passante :
2𝑆𝐹
𝑇𝑠𝑦𝑚𝑏𝑜𝑙𝑒 = 𝐵𝑎𝑛𝑑𝑤𝑖𝑑𝑡ℎ. A titre d'exemple, le Tableau 5 représente le temps d'émission d'un symbole
pour une bande passante de 125 KHz.
Plus le Spreading Factor sera élevé, plus le débit binaire sera faible.
Plus la Bande Passante sera élevée, plus le débit binaire sera élevé.
Exercice : On considère les deux cas suivants : cas 1 (SF7, 125 kHz) et cas 2 (SF12, 125 kHz). Donner
le débit binaire correspondant.
Réponse :
Exercice : On reprend les deux cas précédents avec un CR de 4 / 5. Donner le débit binaire
correspondant.
Réponse :
■ Cas 1 : Pour SF7, 125 kHz et CR4/5 > Débit = 6.836 kbps / 1.25 = 5469 bps
■ Cas 2 : Pour SF12, 125 kHz et CR4/5 > Débit = 366 bps / 1.25 = 293 bps
La documentation d'un transceiver LoRa donne les débits en fonction du Spreading Factor,
la Bande Passante et le Coding Rate. Vérifier la cohérence du résultat avec votre calcul
précédent.
Exercice : En reprenant l’exemple des deux cas précédents [SF7, 125 kHz, CR 4/5] et [SF12, 125 kHz,
CR 4/5], vérifier les calculs du "Equivalent Bitrate" avec le logiciel LoRa Calculator.
Réponse :
■ Cas 1 : Pour SF7, 125 kHz et CR4/5 > Débit = 5468,75 bps
■ Cas 2 : Pour SF12, 125 kHz et CR4/5 > Débit = 292,97 bps
Les données du protocole LoRa sont appelées PHY Payload (données de la couche physique) et la
trame complète est représentée par la Figure 17.
Nous verrons plus tard au paragraphe 6.1.3, la représentation détaillée d'une trame LoRa. Dans
l'immédiat, nous allons utiliser le LoRa Calculator pour estimer le temps d'émission de la trame. Ce
temps d'émission est appelé Time On Air (ou Airtime). La simulation pour SF7, BW125, CR4/5 et un
octet de Payload est donnée Figure 18.
Exercice : Donner le Time On Air pour l'envoi d'1 octet en SF7 et en SF12. En déduire En déduire le
débit utile de cette transmission dans les deux cas.
Réponse :
■ L'envoi d'un octet (Payload Length) en SF7 donne un Time On Air de 25,85 ms
■ L'envoi d'un octet (Payload Length) en SF12 donne un Time On Air de 827,39 ms
■ Cas 1 : Pour SF7, 125 kHz et CR4/5 > Débitutile_LoRa = 8 / 25,85 ms = 309,3 bps
■ Cas 2 : Pour SF12, 125 kHz et CR4/5 > Débitutile_LoRa = 8 / 827.39 ms = 9,6 bps
La Figure 19 représente une trame LoRaWAN simplifiée. On retrouve l'entête du protocole LoRa et
un entête LoRaWAN a été ajouté. Cet entête LoRaWAN doit être transmis et augmente donc le
temps de transmission alors que le nombre de bits utiles est le même. Cela réduit donc le débit utile
de la transmission.
Données utilisateurs
Entête LoRa Entête LoRaWan CRC
N octets
Données utilisateur
Trame LoRaWAN complète
Nous pourrions simuler ce débit utile de la même façon que nous l'avions fait avec le LoRa calculator.
Mais cette fois ci, je vous propose de le vérifier par l'intermédiaire d'une trame réelle envoyée
depuis un Device LoRa à une Gateway. Dans cette application, nous transmettons un seul octet (une
température). Un des rôle d'une Gateway est de nous fournir les informations sur la transmission.
Nous recueillons les valeurs suivantes sur la Gateway pour un envoi en SF7, puis pour SF12. Nous
nous intéressons à la colonne airtime (ms).
On remarque que :
Exercice : En déduire le débit utile de cette transmission pour les deux cas [SF7, 125 kHz, CR 4/5] et
[SF12, 125 kHz, CR 4/5].
Réponse :
■ Cas 1 : Pour SF7, 125 kHz et CR4/5 > Débitutile_LoRaWAN = 8 / 46.3 ms = 172.7 bps
■ Cas 2 : Pour SF12, 125 kHz et CR4/5 > Débitutile_LoRaWAN = 8/ 1155.1 ms = 6,9 bps
Exemple : A la Figure 20, dans le cas du SF7, le Time On Air est de 46,3 ms. Le Device LoRa ne doit
donc plus émettre pendant 99 x 46,3ms = 4,58 secondes.
Exercice : En reprenant les exemples précédents [SF7, 125 kHz, CR 4/5] et [SF12, 125 kHz, CR 4/5],
quels sont les débits moyens si on prend en compte le « Time On Air » et le Duty-Cycle de 1% de la
norme LoRaWAN?
Réponse :
■ Cas 1 : Pour SF7, 125 kHz et CR4/5 > Débitfinal = 172.7 bps / 100 = 1,73 bps
■ Cas 2 : Pour SF12, 125 kHz et CR4/5 > Débitfinal = 6,9 bps /100 = 0,07 bps
■ Protocole LoRa : Type de modulation (Chirp Spread Spectrum) permettant d'envoyer des
données entre un émetteur et un récepteur.
■ Protocole LoRaWAN : Architecture du réseau (Device, Gateway, Serveurs) et format de
trame spécifique permettant à un Device LoRaWAN de transmettre des données à un
serveur LoRaWAN.
On remarque que très tôt une version 1.1 a été écrite, mais elle n'a pas été adoptée par les
industriels. La LoRa Alliance a alors poursuivi la clarification de la version 1.0.X en ajoutant la version
1.0.3 et la version 1.0.4 qui est doit être la dernière de la série.
Sauf si cela est clairement spécifié, ce document traite essentiellement de la version 1.0.X
du protocole LoRaWAN.
Application
utilisateur
Internet Internet
Network Application
Server Server
Devices Gateways
LoRa
Utilisateur
Figure 21 : Structure globale d'un réseau LORAWAN
Ils possèdent une radio LoRa permettant de joindre les Gateways. Les Gateways ne sont pas
adressées spécifiquement : toutes celles présentes dans la zone de couverture reçoivent les
messages et les traitent.
Elle joue donc le rôle de passerelle entre une modulation LoRa, et une communication IP.
Gateway
Application Application
LoRaWAN
LoRaWAN
LoRa MAC Passerelle LoRa / Internet LoRa MAC
LoRa
Transmission Radio
Chaque Gateway LoRa possède un identifiant unique (EUI sur 64 bits). Cet identifiant est utile pour
enregistrer et activer une Gateway sur un Network Server.
Internet
Network
Devices Gateways
Server
Network Session Key (NwkSKey)
Authentification
Figure 23 : Authentification entre le Device LoRa et le Network Server
Internet
Network Application
Devices Gateways Server Server
Chiffrement
grâce à une clé AES 128 bits appelée Application Session Key : AppSKey. Contrairement au NwkSKey
(Network Session Key), il s'agit bien ici d'un chiffrement comme nous le verrons au paragraphe 4.2.7.
Internet
Network Application
Devices Gateways Server Server
Protocole
MQTT ou HTTP Application
Server Web
Flux Uplink
Flux Downlink
Utilisateur
Network Application
Server Server
D’autre part, l’application mettra à disposition les données aux utilisateurs sous forme d'un tableau
de bord par exemple.
NwkSKey x
Données x chiffrées NwkSKey x
MIC généré Réception
Données x chiffrées MIC généré Emission Données x chiffrées MIC généré Emission
Trame émise Trame reçue
Dans le schéma de la Figure 27, on parle de "Données x chiffrées". En effet, ces données ont au
préalable été chiffrées par l'AppSKey avant de passer par le processus d'authentification décrit ici.
AppSKey AppSKey
AppSKey
NwkSKey
Uplink Uplink
Downlink
éventuels
Uplink Uplink
Message Message
RX1 RX2 RX1
1s
Device 2s Temps
Lora
La durée des fenêtres doit être au minimum la durée de réception d’un préambule. Un préambule
dure 12.25 Tsymbole et dépend donc du Data Rate (DR : voir paragraphe 4.6 pour plus d’information
sur le DR) . Lorsque qu’un préambule est détecté, le récepteur doit rester actif jusqu’à la fin de la
transmission. Si la trame reçue pendant la première fenêtre de réception était bien à destination du
Device LoRa, alors la deuxième fenêtre n’est pas ouverte.
■ Le Slot RX1 est programmé par défaut à 1 seconde +/ 20 µs après la fin de l’émission Uplink.
■ La fréquence et le Data Rate (DR) sont les mêmes que ceux choisis lors de la phase
d’émission (Uplink).
■ Le Slot RX2 est programmé par défaut à 2 secondes +/ 20 µs après la fin de l’émission Uplink.
■ La fréquence et le Data Rate (DR) sont configurables mais fixes.
Un Device LoRa qui est uniquement de classe A ne peut pas recevoir s’il n’a pas émis. Il
n’est donc pas joignable facilement.
Uplink Uplink
Downlink
éventuels
Uplink Uplink
Beacon
Beacon
Message Message
RX1 RX2 RX RX RX RX1
1s
Device 2s Temps
Lora Balises transmises par la Gateway
Un Device LoRa de classe B est joignable régulièrement sans qu’il soit nécessairement
obligé d’émettre. En revanche, il consomme plus qu’un Device de classe A.
Mise en veille
du Device LoRa
Uplink Uplink
Downlink
éventuels
Uplink Uplink
Message Message
RX RX1 RX2 RX RX1
1s
Device 2s
Temps
Lora
Toutes les zones RX sont sur les même paramètres (canal et Spreading Factor) que RX2.
Consommation
Classe C
Classe B
Classe A
Dans le cas où l’utilisateur transmet des informations au Device LoRa (flux Downlink), on peut se
demander quelle Gateway sera choisie pour transférer les données au Device LoRa. En effet,
l’endroit où est situé le Device LoRa n’est pas nécessairement connu à l’avance.
La Gateway utilisée pour le Downlink est celle qui a reçu le dernier message du Device
LoRa. Un message ne pourra jamais arriver à destination d’un Device LoRa si celui-ci n’a
jamais transmis, quel que soit sa classe A, B ou C.
En ABP, toutes les informations nécessaires à la communication sont déjà connues par le
Device LoRa, par le Network Server et par l'Application Server.
Devices 1
DevAddr 1
NwkSKey 1
AppSKey 1
Network Server
Application Server
Devices 2 DevAddr 1 DevAddr 2
DevAddr 2 NwkSKey 1 NwkSKey 2
NwkSKey 2 AppSKey 1 AppSKey 2
AppSKey 2
Paramètres stockés sur le serveur
Paramètres programmés
dans le composant
Au préalable, le Device LoRa doit connaitre : le DevEUI, l’AppEUI, et l’Appkey. Le Network Server
doit, lui, connaitre le DevEUI, l’AppEUI, et l’Appkey.
C'est donc uniquement grâce à ces informations de départ et à la négociation avec le Network Server
(Join-Request) que le Device LoRa et le serveur vont générer les informations essentielles : DevAddr,
NwkSKey et AppSKey.
DevEUI DevEUI
AppEUI AppEUI
AppKey AppKey
Lorsque le Join-Request a eu lieu, alors les paramètres générés (DevAddr, NwkSKey et AppSKey)
sont stockés dans le Device LoRa et dans les serveurs.
DevAddr 1 DevAddr 1
NwkSKey 1 NwkSKey 1
AppSKey 1 AppSKey 1
■ DevEUI : Unique Identifier pour le device LoRa (Equivalent à une @MAC sur Ethernet).
Certains Device LoRa ont déjà un DevEUI fourni en usine.
■ AppEUI : Unique Identifier pour l’application server.
■ AppKey : AES 128 clé utilisée pour générer le MIC (Message Code Integrity) lors de la Join
Resquest. Il est partagé avec le Network server.
4 3
1. Le Device LoRa émet un Join-Request à l'aide des informations DevEUI, AppEUI et AppKey
qu'il possède.
2. Le Network Server authentifie le Join-Request et le valide. Il génère alors une NwkSKey, une
AppSKey, et un DevAddr.
3. Le Network Server retourne le DevAddr, ainsi qu'une série de paramètres.
4. Les paramètres fournis lors du Join-Accept, associés à l'AppKey, permettent au Device LoRa
de générer le même NwkSKey et le même AppSKey qui avaient été initialement générés sur
le Network Server.
4.5.1 Sécurité
D'un point de vue de l'authentification et du chiffrement, les méthodes d'activation ABP et OTAA
sont équivalentes. Le point faible de chacune des méthodes sont les clés stockées en permanence
dans le Device LoRa:
AppSKey
Mémoire sécurisée
Néanmoins, comme la méthode ABP conserve les clés de session éternellement, il y a plus de
chances de se les faire voler par force brute, notamment si le Device rejoue les mêmes séquences
de nombreuses fois. De plus, la manipulation des clés de session en ABP (si on veut par exemple
changer de réseau LoRaWAN) donne plus d'opportunités d'exposer les clés et donc de les rendre
visibles.
Devices LoRa
NwkSKey
AppSKey Network Server
Application Server
(1) (2)
NwkSKey
Hacker AppSKey
(1) Ecoute
(2) Réémission
Figure 40 : Utilisation d'un "Frame Counter" pour éviter l'attaque par Replay
Cette sécurité implémentée par les Frame Counter est intéressante pour s’affranchir d’une attaque
par REPLAY, mais dans nos tests cela peut poser problème. En effet, à chaque fois que nous
redémarrons le microcontrôleur, notre Frame Counter revient à zéro, alors que celui de l’Application
Server continue de s’incrémenter. Cela peut être résolue par différentes manières :
1. Désactivation du "Frame Counter Check" : dans certains Application Server, cette option
peut être proposée. Bien sûr, il faudra garder en tête la faille de sécurité que cela engendre.
2. Utiliser l'activation par OTAA au lieu de ABP. En effet, à chaque ouverture de session en
OTAA, le Frame Counter est réinitialisé coté serveur.
3. Conserver la valeur du Frame Counter dans une mémoire non volatile et récupérer sa valeur
au démarrage du Device LoRa.
A noter qu'un Hacker peut aussi utiliser une attaque par Replay pendant le transfert du Join-Request
en OTAA. Un compteur dont le nom est "DevNonce" est donc aussi utilisé pendant cette phase.
Depuis la version 1.0.4 de la spécification LoRaWAN, un Device en OTAA devra donc lui aussi faire
une sauvegarde dans une mémoire non volatile de ce compteur.
Si vous avez choisi le mode OTAA : Il faut que le Device LoRa réémette un Join-Request au server
pour se voir attribuer un nouveau jeu de paramètres (DevAddr, NwSKey, AppSKey). Une nouvelle
adresse DevAddr sera donc disponible et le Device pourra continuer à fonctionner.
Si vous fonctionnez en ABP : Ce cas est problématique car vous avez le DevAddr fixé de façon
permanente au Device LoRa. La seule solution est donc de reprogrammer le firmware du Device, ce
qui peut être très compliqué si la flotte de Device est déjà en service.
En plus de ces éléments que nous avons déjà vus, le Join-Accept comporte
■ Un champ RX Delay.
■ Un champ CFList.
Le RX Delay permet de modifier le temps entre la fin de l'émission (Uplink) et le début de la fenêtre
de réception (Downlink). RX Delay est de 1s par défaut.
RX
Uplink Delay
Message
RX1 RX2
1s
Device 2s
Lora
Figure 42 : Le RX Delay
CFList est une liste permettant de spécifier au Device LoRa les canaux disponibles pour ce réseau en
plus des canaux 0 à 2 (qui ne sont pas modifiables) : 868.1 MHz, 868.3 MHz et 868.5 MHz. Les autres
canaux peuvent être préprogrammés dans le Device LoRa ou Ils peuvent être redéfinis dans la trame
Join-Accept (canaux 3 à 7) comme le montre la Figure 43.
4.5.6 Résumé
Nous pouvons donc résumer les deux méthodes d'activation dans le Tableau 6.
ABP OTAA
Stockage en mémoire sécurisée : Stockage en mémoire sécurisée :
Sécurité globale
NwSkey et AppSKey AppKey
Changement
Pas possible Pris en charge par l'OTAA
de Network
Modification
Pas possible Prise en charge par l'OTAA
du RX Delay
Pour écouter tout le flux Uplink d'un Device enregistré sur TTN, une Gateway LoRa doit
écouter sur 8 canaux simultanément avec les 6 Spreading Factor différents, soit 48
combinaisons possibles.
■ Le "Time On Air" (voir chapitre 3.4). En effet, plus le message est long à être envoyé, plus la
radio sera alimentée pendant un long moment.
■ La puissance d'émission (PE)Tableau 9
Une solution simple pour réduire le "Time On Air" est de réduire le SF (Spreading Factor). En effet,
lorsqu'on réduit le SF de 1, le "Time On Air" est divisé par deux (voir chapitre 3.1.2). Pour la puissance
d'émission (PE), on peut la réduire directement dans la configuration du Transceiver. Bien sûr, ces
modifications ont des conséquences, et il faut donc les ajuster avec cohérence. Le Tableau 10
Emetteur Récepteur
Spreading Factor Sensibilité SNR minimum
7 -123 dBm -7.5 dB
8 -126 dBm -10 dB
9 -129 dBm -12.5 dB
10 -132 dBm -15 dB
11 -134.5 dBm -17.5 dB
12 -137 dBm -20 dB
Tableau 10 : Sensibilité et SNR acceptables en fonction du Spreading Factor
Le choix du SF et de la puissance d'émission n'est pas simple, et c'est souvent par une méthode
empirique que nous déterminons leur valeur. Il faut sans cesse vérifier la bonne réception des
trames, et s'assurer que les marges sur le SNR et sur le RSSI sont suffisantes pour les trames reçues
par les Gateways.
Pour pallier à cette difficulté, une méthode d'ajustement automatique a été mise en place par le
protocole LoRaWAN : c'est l'Adaptive Data Rate (ADR). L'idée est de faire en sorte que le Network
Server soit lui-même à l'initiative du meilleur choix combiné du SF et de PE.
La vérification n'est pas faite uniquement sur une seule trame mais sur plusieurs en faisant une
moyenne. On peut appliquer la démarche suivante :
oui
oui Diminution de PE
RSSI > Sensibilité + Marge ?
jusqu'à PE mini
non
Augmentation de PE
Dans tous les cas, le Device LoRa doit se configurer en mode ADR pour pouvoir utiliser
cette fonctionnalité.
1. Le Network Server transmet lui-même les informations au Device LoRa via une commande
appellée LinkADRReq en profitant d'une trame Downlink existante.
2. Le Network Server n'a pas pu profiter d'une trame Downlink pour envoyer la commande
LinkADRReq. Dans la prochaine trame Uplink, le Device LoRa va donc envoyer une option
appelée ADRACKReq afin de faire une demande explicite au Network Server. Le Server
générera une trame LinkADRReq.
Le Device LoRa émet des trames en Uplink en direction du serveur. Après un certain nombre de
trames reçues et lorsque celui-ci considère que la marge sur le SNR et sa sensibilité est suffisante, il
va insérer dans une trame de donnée en Downlink une commande LinkADRReq au Device (requête
de changement de SF / PE). Dès que le Device la reçoit, il va modifier sa configuration en
conséquence comme le montre la Figure 45.
La trame linkADRReq n'est pas envoyée seule. Elle est mutualisée avec une trame de données en
Downlink. S'il n'y a pas de trame de données Downlink disponible alors le Network Serveur attendra
avant d'envoyer cette commande.
Lorsque le Device LoRa n'a pas reçu de trame Downlink, il sait que le Network Server n'a pas eu
d'opportunité de lui transmettre sa commande linkADRReq. Il va donc explicitement lui faire une
demande de linkADRReq en utilisant l'option ADRACKReq dans sa trame. S'il n'obtient pas de
réponse dans un temps imparti, alors la communication avec le serveur est considérée comme
perdue et le Device LoRa va incrémenter SF / PE, jusqu'à rétablir la communication avec le serveur
comme le montre la Figure 46.
■ En utilisant les réseaux LoRaWAN opérés proposés par les opérateurs de télécoms.
■ En utilisant votre propre réseau LoRaWAN privé.
■ En utilisant une infrastructure intermédiaire appelée réseau dédié.
Devices Internet
LoRa Gateways Internet
Network Application
Server Server
A titre d'exemple, voici en 2020 les abonnements proposés par Bouygues et Orange pour avoir accès
à leur réseau LoRaWAN :
Orange :
Bouygues Objenious :
Devices Internet
LoRa Gateways Internet
Network Application
Server Server
Gateways gérées
Serveurs gérés par un prestataire
en privé Application
Server Web
Devices Internet
LoRa Internet
Gateways
Network Application
Server Server
Network Server et Application Server en ligne : De très nombreux Network Server et d’Application
Server sont proposés. Ce sont des services payants ou avec des contreparties :
■ Actility [ www.actility.com ]
Dans le cadre de ce cours, la plupart du temps, nous sommes dans le cas d'un réseau dédié. En
effet, nous utilisons nos propres Gateways que nous associons à des serveurs LoRaWAN (TTN,
Chirpstack, LORIOT, LoRa Cloud…).
Pour connaitre la zone de couverture de notre Gateway utilisée avec TTN, nous pouvons utiliser
l’application TTN Mapper. L’idée est de promener son Device LoRa associé à un GPS dans la zone de
couverture des Gateways qui nous entourent. A chaque trame reçue par le Serveur, on note les
coordonnées GPS du Device LoRa ainsi que la Gateway qui a transmis le message. Toutes ces
informations sont alors retranscrites sur une carte.
IP
Network Application
Devices Gateways Server Server
Il existe de très nombreux autres Serveurs LoRaWAN. Vous retrouvez dans les annexes de ce cours
quelques-uns d'entre eux avec leurs adresses ainsi que les principales configurations qui leur sont
spécifiques.
■ Le type de Packet Forwarder : Le Packet Forwarder est le logiciel interne qui déterminera
aussi le protocole avec lequel la Gateway communiquera avec le Network Server. Nous
donnerons plus d'information à ce sujet au chapitre 9.1.2.
■ L'adresse IP du Network Server : La Gateway doit connaitre l'adresse IP vers laquelle la
Gateway dirigera les données LoRa.
■ Le numéro de port Uplink distant : La Gateway joindra le Network Server sur un numéro de
port spécifique qui doit être connu.
■ Le numéro de port Downlink : C'est le numéro de port source utilisé par le Network Server
pour les trames Downlink à destination de la Gateway.
Par exemple, les Gateways LoRa (Marque ATIM, Modèle A-Gate) que nous avons à l'Université
Savoie Mont Blanc ont la configuration suivante :
Les deux Gateway écoutent sur tous les canaux et sur tous les Spreading Factor (de SF7 à SF12).
Les Applications : Avant d'enregistrer des Devices, il faut créer une application au sein de
l'Application Server. C'est là que seront stockées toutes les AppSKey de tous les Devices.
Les Devices : Chaque Device LoRa doit être enregistré au sein d'une application. Pour chaque Device
on renseignera la version du protocole LoRaWAN, le DevEUI, ainsi que les clés en fonction du mode
d'activation ABP ou OTAA qui est utilisé.
Une demande de confirmation peut être demandée au Device LoRa pour qu’il précise s’il a bien reçu
les données. L’option "confirmed" permet donc de spécifier le type de trame dans le MAC Header
(voir paragraphe 6.1.2) : "Confirmed Data Down" ou "Unconfirmed Data Down".
Chaque couche rajoute un service. Lors de l’envoi de la trame, les données utilisateurs sont donc
encapsulées dans chaque couche inférieure jusqu’à la transmission. Le détail de l’ensemble de la
trame LoRaWAN par couche est décrit sur la Figure 55 :
AppSKey
Couche Device Address Frame Control Frame Counter Frame Option Frame Port Frame Payload
Application 4 octets 1 octet 2 octets 0 à 15 octets 1 octet N octets
AppSKey
Couche Device Address Frame Control Frame Counter Frame Option Frame Port Frame Payload
Application 4 octets 1 octet 2 octets 0 à 15 octets 1 octet N octets
Frame Header
Un ensemble de champs nommé Frame Header permet de spécifier le DevAddr, le Frame Control,
le Frame Counter, et le Frame Option.
Le Frame Payload contient les données chiffrées à transmettre. Le nombre d’octets maximum
pouvant être transmis (N octets) est donné dans le tableau suivant :
Le Préambule est représenté par 8 symboles + 4.25. Le temps du Préambule est donc de 12.25
Tsymbole (voir chapitre 3.1 pour rappel de la définition d'un symbole).
L'entête (Header optionnel) est seulement présent dans le mode de transmission par défaut
(explicite). Il est transmis avec un Coding Rate de 4/8. Il indique la taille des données, le Coding Rate
pour le reste de la trame et il précise également si un CRC sera présent en fin de trame.
Gateway
Modulation Internet
Network Server
LoRa UDP / IP
Coté interface Radio : La Gateway réceptionne une trame LoRaWAN et extrait le PHY Payload. Elle
va coder ce PHY Payload en format ASCII en base 64 (voir le paragraphe 6.3.2). La Gateway extrait
aussi toutes les informations utiles sur les caractéristiques de la réception qui a eu lieu : SF,
Bandwidth, RSSI, Time On Air…etc…
Coté interface réseau IP : La Gateway transmet l’ensemble de ces informations dans un paquet IP
(UDP) au Network Server. Les données transmises sont du texte en format JSON (voir paragraphe
6.3). La Gateway a donc bien un rôle de passerelle entre le protocole LoRa d’un côté et un réseau IP
de l’autre.
Quelles sont les méthodes à notre disposition pour représenter les données binaires ?
La méthode binaire (base 2): La façon la plus simple et de représenter chacun des éléments qui
constitue la trame avec les caractères 0 et 1. Cette méthode est simple, mais elle a un très gros
inconvénient : La représentation est visuellement complexe à lire car le nombre d'élément est
considérable. Si on souhaite représenter un trame LoRa de 50 octets, il faudrait écrire 400 éléments
'0' ou '1'.
La méthode hexadécimal (base 16): On regroupe les bits par 4, ce qui fait 16 combinaisons possibles.
Les 16 caractères utilisés sont 0, 1, 2, …, 8, 9, A, B, …, E, F. Cette méthode a l'avantage d'être 4 fois
plus compacte que la représentation binaire. Peut-on faire mieux ?
La base 64 : On regroupe les bits par 6, ce qui fait 64 combinaisons possibles. Les 64 caractères
utilisés sont celle du tableau suivant :
Cette méthode a l'avantage d'être 6 fois plus compacte que la représentation binaire. Peut-on faire
mieux ?
La base 256 (ASCII) : On regroupe les bits par 8, ce qui fait 256 combinaisons possibles. Les 256
caractères utilisés sont ceux de la table ASCII que vous retrouverez facilement sur le web. Cette
méthode à l'avantage d'être 8 fois plus compacte que la représentation binaire. Mais cette
représentation a un énorme inconvénient : de très nombreux caractères de cette représentation
sont des caractères non imprimables (retour à ligne, espace, EOF, …) et donc ne sont pas visibles.
Cette représentation est donc utile pour le codage de texte, mais inutilisable si on souhaite
représenter des données binaires.
2. On regroupe les éléments binaires par des blocs de 6 bits. Le nombre de bloc de 6 bits doit
être un multiple de 4 (minimum 4 blocs). S’il manque des bits pour constituer un groupe de
6 bits, on rajoute des zéros.
Bloc de 6 bits
3. S’il manque des blocs pour faire un minimum de 4 blocs, des caractères spéciaux seront
ajoutés.
4. Chaque groupe de 6 bits est traduit par le tableau suivant. (Source Wikipédia)
S G k
5. Si un bloc de 6 bits manque (ils doivent être un multiple de 4), on rajoute un ou plusieurs
compléments (caractère " = " )
S G k =
Imaginons que la trame IP reçue par le Network Server de TTN est la suivante :
{
"gw_id": "eui-b827ebfffeae26f6",
"payload": "QNMaASYABwAP1obuUHQ=",
"f_cnt": 7,
"lora": {
"spreading_factor": 7,
"bandwidth": 125,
"air_time": 46336000
},
"coding_rate": "4/5",
"timestamp": "2019-03-05T14:00:42.448Z",
"rssi": -82,
"snr": 9,
"dev_addr": "26011AD3",
"frequency": 867300000
}
D’autres information proviennent de l’analyse du Payload. Le Payload inscrit ici est le PHY Payload.
Il y a donc une partie chiffrée (Frame Payload), mais les entêtes sont en clairs (voir paragraphe 6.1).
Ce PHY Payload est « QNMaASYABwAP1obuUHQ= ». Lorsque celui-ci est exprimé en hexadécimal
au lieu de la base 64, il vaut : « 40D31A01260007000FD686EE5074 », comme le montre le Network
Server de TTN.
Sa taille est bien de 14 octets (en hexadécimal) comme précisé sur la Figure 62.
Nous reprenons le format de la trame LoRaWAN vu à la. Nous pouvons alors retrouver tous les
champs de toute la trame :
PHYPayload = 40D31A01260007000FD686EE5074
Vous pouvez vérifier l’ensemble de ces informations grâce au décodeur de trame LoRaWAN
(LoRaWAN packet decoder).
■ NwkSKey : E3D90AFBC36AD479552EFEA2CDA937B9
■ AppSKey : F0BC25E9E554B9646F208E1A8E3C7B24
FramePayload = D6
D6 est le contenu chiffré. Lorsqu’il est déchiffré avec l’AppSKey, on trouve 01. Vous pouvez vérifier
l’ensemble de ces informations grâce au décodeur de trame LoRaWAN.
A noter que l’Application Server recevra les données chiffrées seulement si le Device LoRa a bien
été enregistré. On peut aussi vérifier ci-dessous que l’Application Serveur de TTN nous retourne bien
un payload (Frame Payload) de 01.
{
"time": "2019-03-05T14:00:42.379279991Z",
"frequency": 867.3,
"modulation": "LORA",
"data_rate": "SF7BW125",
"coding_rate": "4/5",
"gateways": [
{
"gtw_id": "eui-b827ebfffeae26f6",
"timestamp": 2447508531,
"time": "",
"channel": 4,
"rssi": -82,
"snr": 9,
"latitude": 45.63647,
"longitude": 5.8721523,
"location_source": "registry"
}
]
Toute cette partie est totalement indépendante du protocole LoRa et LoRaWAN que nous avons
étudié jusqu’ici, et n’a donc aucun lien avec celui-ci. Les explications qui viendront peuvent donc
être aisément transposées à tout autre protocole lié à l’Internet des Objets. On a donc d’un côté la
communication entre le Device LoRa et les serveurs LoRaWAN (par l’intermédiaire des Gateways).
Et de l’autre côté, on a la communication entre les Serveur LoRaWAN et notre Application. Notre
Application fera le lien avec l'utilisateur. Elle devra donc réaliser les actions suivantes :
■ Recevoir des données en provenance des Devices LoRa (via le Serveurs LoRaWAN).
■ Transmettre des données à destination des Devices LoRa (via le Serveur LoRaWAN).
Serveurs LoRaWAN
Application
HTTP
MQTT
Internet
Network Application
Server Server
Devices Gateways
LORA
Utilisateur
Figure 66 : Structure globale d’un réseau LORAWAN
Attention, les termes utilisés ici sont très proches malgré le fait qu'ils désignent des entités
complétement différentes :
■ On parle d'Application Server lorsque que nous parlons du serveur Application LoRaWAN.
Ce terme est défini dans la spécification du protocole LoRaWAN.
■ On parle d'Application lorsqu'on définit le serveur coté utilisateur. Ce serveur n'a aucun lien
avec le protocole LoRaWAN.
1. Récupération
Serveurs LoRaWAN 2. Stockage (sauvegarde)
3. Mise en forme
4. Interface utilisateur
HTTP
Application
MQTT
Dans ce chapitre, nous traiterons seulement les deux éléments en gras de la liste précédente, c’est-
à-dire : "Gérer la récupération des données (Uplink)" et "Envoyer la requête au Serveur LoRaWAN
(Downlink)".
Nous allons voir deux méthodes pour communiquer entre notre Application et TTN : le protocole
HTTP et le protocole MQTT.
Pour les explications de ce chapitre, nous utiliserons à nouveau le Network Server et Application
Server de "The Things Network".
La Figure 68 représente un client, un serveur et les deux types de trame qui circulent entre eux : les
requêtes et les réponses. Il est très important de savoir qui va jouer le rôle du client et qui va jouer
le rôle du serveur. En effet, il faudra affecter un rôle (client ou serveur) au serveur LoRaWAN (TTN
dans notre cas) et à notre Application.
Client
Requêtes Réponses
Serveur
Application
Nous allons maintenant étudier les deux situations qui sont le flux Uplink et le flux Downlink
représenter sur la Figure 70.
Commençons par la situation la plus courante qui est celle du flux Uplink : nous cherchons à
récupérer sur notre Application, les données du serveur LoRaWAN (TTN). La première idée, c’est de
faire depuis notre Application une requête (1) à TTN pour qu’il nous fournisse ces données. Cette
requête du protocole HTTP s’appelle une requête HTTP GET. Quand vous faites une requête HTTP
GET à un serveur Web, il vous retourne le contenu de la page HTML qu’il contient. Ici, TTN qui aura
donc le rôle de serveur retournera les données LoRa (2). Nous avons donc dans ce cas, TTN qui joue
le rôle du serveur et notre Application qui joue le rôle du client.
On parle maintenant du flux Downlink : nous cherchons à récupérer sur le serveur LoRaWAN les
données que l'utilisateur souhaite envoyer au Device LoRa. Nous allons faire en sorte que le serveur
LoRaWAN fasse des requêtes HTTP GET (3) à notre Application pour qu’elle nous fournisse ces
données lors de la réponse (4). Nous avons dans ce cas, le serveur LoRaWAN qui joue le rôle du
client et notre Application qui joue le rôle de serveur.
Nous commençons par la mise en place du serveur HTTP sur TTN. Pour cela, nous devons nous
rendre dans notre console TTN. TTN > Applications > Nom de l'Application > Intégration > Data
Storage. Le serveur est alors disponible ainsi qu'une sauvegarde temporaire des données pendant
7 jours.
Pour prendre connaissance de l'API disponible pour récupérer les données, cliquer sur "go to
platform" comme indiqué sur la Figure 71. La Figure 72 présente l'ensemble des APIs, qui rendent
les requêtes simples et intuitives.
Nous allons donc maintenant générer les requêtes en suivant la documentation de l'API disponible
pour récupérer les éléments souhaités. Cela est possible de plusieurs façons. Nous pouvons faire un
La deuxième méthode est un peu plus complexe à mettre en œuvre, mais est beaucoup plus
générique et nous servira dans de nombreux cas; c'est donc celle que j'expliquerai plus en détail.
Pour cela nous allons utiliser un logiciel nommé POSTMAN qui permet de généré toutes sortes de
requête HTTP. Il nous suffira de nous référer à la documentation pour choisir les bons formats. En
résumé, nous avons mis en place la structure présentée à la Figure 73 :
Requête (1 ) Réponse (2 )
HTTP GET
[ Flux Uplink ]
Client Application
Dans POSTMAN, nous allons maintenant réaliser la requête HTTP GET. Nous nous intéressons à la
requête /api/v2/query permettant de connaitre les données reçues par tous les Devices de
l'application. Vérifier que vos Devices LoRa émettent bien et générer la requête suivante avec
POSTMAN :
POSTMAN > Import > Raw Text > Mettre la commande Curl
Vous devriez avoir la réponse à votre requête au format JSON. Dans la réponse suivante, le Device
"Arduino0" de mon application à reçu 0x01 ( AQ== en Base64 ) à l'heure indiquée.
{
"device_id": "arduino0",
"raw": "AQ==",
"time": "2020-08-24T11:26:43.140932111Z"
}
Le premier inconvénient est que nous avons travaillé uniquement sur le flux Uplink. La partie de
droite de la Figure 70 n'a pas pu être implémentée car il n'y a pas de façon simple d'installer un
client HTTP générant des requêtes GET sur TTN.
Le deuxième inconvénient est que pour le flux Uplink, nous passons notre temps à demander des
données qui n’existent potentiellement pas. En effet, nous faisons des requêtes pour des données
sans savoir si elles sont vraiment arrivées. Si un capteur émet de façon non régulière des valeurs,
alors nous devrons faire des requêtes périodiques avec une forte chance d'avoir des réponses vides
(car le Device n'aura rien émis).
Pour le flux Downlink, si nous avions pu installer le client sur TTN, le problème serait le même. Nous
passerions notre temps à demander des commandes alors qu’il y a de fortes chance que l’utilisateur
n’en ait passé aucune.
On voit bien qu’on a ici des objectifs contradictoires. on aimerait avoir une réception des données
rapides sur notre Application, mais cette exigence impose de faire des demandes très fréquentes au
serveur et donc d’augmenter considérablement la charge réseau.
La solution est donc de réorganiser les clients, les serveurs et les requêtes pour essayer d’optimiser
la façon dont on transfère les données entre le serveur LoRaWAN et notre Application. Cela sera
permis grâce aux requêtes HTTP POST.
Pour le flux Uplink, nous allons répartir les rôles de façon différentes en imaginant que l'Application
ne va pas demander au serveur LoRaWAN les informations, mais que le serveur LoRaWAN va plutôt
les fournir elle-même à l'Application. Le serveur LoRaWAN va donc transmettre à l'Application une
requête qui s'appelle HTTP POST (1) pour "poster" les données. La réponse (2) est un simple
acquittement et ne contient pas de données. Donc, ici, TTN jouera le rôle de client et notre
application, le rôle de serveur.
Nous commençons par la mise en place du serveur. Nous utiliserons un serveur HTTP disponible sur
le web, gérant les requêtes HTTP POST [ https://rbaskets.in/ ] ou [ https://beeceptor.com/ ] par
exemple.
Conserver le token si vous souhaitez revenir sur ce même serveur plus tard et cliquer sur
"Open Basket".
L'adresse vers laquelle vous devez envoyer vos requêtes est alors précisée. Conservez-là.
Elle nous servira lorsque nous configurerons le client.
Vous êtes donc dans l'attente de données, votre basket est vide et les requêtes que vous
recevrez apparaitront ici.
Dans les deux cas, voici un exemple de requête POST reçue sur notre serveur HTTP :
{
"app_id": "test_app_lorawan_sylvainmontagny" ,
"dev_id": "stm32lorawan_1",
"hardware_serial": "0056A......F49877",
"port": 1,
"counter": 0,
"payload_raw": "qg==",
"metadata": {
"time": "2019-01-24T15:24:37.03499298Z"
},
"downlink_url":"https://integrations.thethingsnetwork.org/ttn-
eu/api/v2/down/test_app_lorawan_sylvainmontagny/rbaskets?key=ttn-account-
v2.........................8ypjj7ZnL3KieQ"
}
Comme nous pouvons le voir, le contenu fourni à notre serveur est formaté en JSON (voir
paragraphe 6.3). Voici quelques compléments d’information :
Nous récupérerons alors les données de nos capteurs au format JSON sur notre serveur POST. Reste
à les traiter, les stocker (BDD, etc…), et les mettre à disposition d'un utilisateur comme nous le
verrons au chapitre 10 lors de la création complète de notre propre Application.
Nous commençons par la mise en place du serveur. C'est très simple puisqu'il existe déjà dans TTN
et a été installé en même temps que le client au paragraphe précédent. Il n'y a donc rien de plus à
faire pour la mise en place du serveur.
Pour le client, nous utiliserons à nouveau POSTMAN et nous allons générer une requête HTTP POST
:
"downlink_url":"https://integrations.thethingsnetwork.org/ttn-
eu/api/v2/down/test_app_lorawan_sylvainmontagny/rbaskets?key=ttn-account-
v2.........................8ypjj7ZnL3KieQ"
{
"dev_id": "YourDeviceID",
"payload_raw": "aGVsbG8=",
"port": 1,
"confirmed": false
}
Vous devez envoyer le texte (payload_raw) en base 64. Dans l’exemple ci-dessus « aGVsbG8= »
correspond à la chaine de caractère « hello ». Vous pouvez utiliser les nombreux
encodeur/décodeur en ligne pour vous aider. Le texte doit s’afficher sur votre moniteur série de
votre Device LoRa.
En résumé, l'Application que nous avons mise en place est conforme à la Figure 76 ci-dessous. Sur
notre serveur LoRaWAN, c'est l'intégration du service "HTTP Intégration" qui joue le rôle de client
https://rbaskets.in/
Client Topic
Publisher 1 Température
Pour recevoir les données appartenant à un Topic, un Subscriber doit souscrire (comme son nom
l'indique) au préalable sur ce Topic.
MQTT est un protocole qui repose sur TCP. L'encapsulation des trames sur le réseau est donc la
suivante :
On peut noter que le port TCP utilisé pour le protocole MQTT (non chiffré) est le 1883.
keepAlive : C'est la période la plus longue pendant laquelle le client Publisher ou Subscriber pourra
rester silencieux. Au-delà, il sera considéré comme déconnecté.
■ Si la connexion était non persistante (cleanSession = True) alors les messages non transmis
sont perdus quel que soit le niveau de QoS (Quality of Service).
■ Si la connexion était persistante (cleanSession = False) alors les messages non transmis
seront éventuellement réémis, en fonction du niveau de QoS. Voir le chapitre 7.4.4.
Lors d'une même connexion la Qualité de Service (QoS) qui est mise en œuvre dépend uniquement
de la valeur du QoS selon les valeurs suivantes :
QoS 0 ''At most once'' (au plus une fois). : Le premier niveau de qualité est "sans acquittement". Le
Publisher envoie un message une seule fois au Broker et le Broker ne transmet ce message qu'une
seule fois aux Subscribers. Ce mécanisme ne garantit pas la bonne réception des messages MQTT.
QoS 1 ''At least once'' (au moins une fois) : Le deuxième niveau de qualité est "avec acquittement".
Le Publisher envoie un message au Broker et attend sa confirmation. De la même façon, le Broker
envoie un message à ces Subscribers et attend leur confirmation. Ce mécanisme garantit la
réception des message MQTT.
Cependant, si les acquittements n’arrivent pas en temps voulu, ou s’ils se perdent, la réémission du
message d'origine peut engendrer une duplication du message. Il peut donc être reçu plusieurs fois.
QoS 2 ''Exactly once'' (exactement une fois) : Le troisième niveau de qualité est "garanti une seule
fois". Le Publisher envoie un message au Broker et attend sa confirmation. Le Publisher donne alors
l’ordre de diffuser le message et attend une confirmation. Ce mécanisme garantit que quel que soit
le nombre de tentatives de réémission, le message ne sera délivré qu'une seule fois.
La figure ci-dessous montre les trames émises pour chaque niveau de QoS.
PUBLISH Ack
Message enregistré
Message enregistré Survie à une perte de connexion
Survie à une perte de connexion Pas de duplication
Duplications possibles
La Figure 81 représentes les 3 captures de trames sur Wireshark représentant les 3 QoS (1, 2 et 3)
que nous venons d'expliquer.
Niveau 1 Maison
Niveau 1 Maison
■ Le signe plus "+" remplace n'importe quelles chaines de caractères sur le niveau où il est
placé.
■ Le dièse "#" remplace n'importe quelles chaines de caractères sur tous les niveaux suivants.
Il est obligatoirement placé à la fin.
■ Un Broker : Mosquitto
■ Un client Publisher : MQTT Box sur Windows
■ Un client Subscriber : MQTT Box sur Windows
Publish
BROKER
Subscribe
Le Broker MQTT est commun à tout le monde. Nous pouvons soit le réaliser nous-même, soit utiliser
un Broker MQTT public de test. Nous utiliserons le Broker de test de Mosquitto..
Si nous décidions de le réaliser nous-même à l’aide d’une Raspberry Pi (par exemple), l’installation
se ferait en deux lignes de commande :
Il est nécessaire d’installer mosquitto-clients si on souhaite que le Raspberry PI joue aussi le rôle de
client, ce qui n’est pas notre cas.
Nous pouvons donc représenter l’application globale par la Figure 85. Nos explications feront
référence à la trame (1).
Topic Topic
[Données] Flux Uplink
BROKER [Données] Flux Downlink
<AppID>/devices/<DevID>/up <AppID>/devices/<DevID>/down
Le BROKER est déjà intégré dans TTN, c'est d'ailleurs le cas dans tous les serveurs LoRaWAN
existants. Il nous reste à configurer le client Subscriber pour gérer le flux Uplink. Nous utiliserons à
nouveau MQTT Box mais cette fois avec la configuration suivante :
Le client MQTT étant configuré, il est maintenant capable de se connecter au Broker. Il reste donc à
définir le fait que le client sera Subscriber. Les informations que recevra le Subscriber dépendent du
Topic auquel nous souscrivons. Voici les Topic disponibles sur le Broker de TTN :
Dans un premier temps nous souscrivons au Topic : +/devices/+/up. Cela signifie que nous
souscrivons à tous les Devices LoRa de toutes nos applications pour le flux Uplink.
Les éléments émis par le Broker seront alors affichés dans MQTTBox.
Ces données sont écrites en JSON. Nous pouvons les remettre en forme :
{
"applicationID":"3",
"applicationName":"myApplication",
"deviceName":"arduino0",
"devEUI":"0056xxxxxxxxx877",
"txInfo": {
"frequency":868500000,
"dr":5
},
"adr":false,
"fCnt":792,
"fPort":15,
"data":"SGVsbG8="
}
Le "Frame Payload" déchiffré est fourni dans le champ "data" en base 64. La valeur fournie par
"data":"SGVsbG8=" correspond bien à la chaine de caractères "hello" que nous avons émise avec le
Device LoRa.
Le BROKER étant toujours réalisé par TTN, il est déjà configuré. Il nous reste à configurer le client
Subscriber. Nous utiliserons à nouveau MQTT Box. Le rôle de client dans MQTT Box a été faite au
paragraphe 7.4.8. Il nous reste simplement à ajouter le rôle de Publisher. La configuration est la
suivante :
{
"dev_id": "arduino0",
Vous devriez voir les données arriver sur votre Device LoRA.
A partir de là, on peut imaginer plusieurs architectures qui possèdent chacune des avantages et des
inconvénients. Nous allons les étudier puis nous les résumerons dans le Tableau 19 à la fin de ce
chapitre.
Stack
Liaison SPI
Application
Ce choix-là est assez abouti et optimisé en terme de consommation, car il n'y a qu'un seul
microcontrôleur qui gère tout. En revanche, c’est une solution beaucoup plus complexe en ce qui
concerne la partie logicielle. En effet, il faudra se plonger dans la Stack. Même si la partie Application
est bien différenciée, il peut être assez compliqué de réaliser un système très modulaire car la stack
LoRaWAN et l'application se déroulent en même temps. Il faut en permanence faire très attention
à ne pas se supprimer des ressources mutuellement.
Dans ce module, il y a donc plusieurs composants. Le Transceiver n'est pas intégré dans le
microcontrôleur comme nous le verrons au paragraphe 8.4, mais du point de vue du programmeur,
c'est presque la même chose.
Stack
Liaison SPI
Application
Stack
Liaison série
Module LoRaWAN
Application
Nous pouvons choisir n’importe quel µC 32 bits (ou même 8 bits). La stack LoRaWAN qui prend
beaucoup de ressource est intégrée au module.
■ Microchip : RN2483.
■ Murata : CMWX1ZZABZ : Il s'agit du même module que celui vu au paragraphe 8.2, mais le
Firmware est différent. Il est ici configuré pour répondre à des commandes d'un maître en
liaison série au niveau applicatif, alors que dans l'exemple du paragraphe 8.2, il fonctionne
en spi au niveau LoRa MAC.
Ces modules se pilotent à l’aide d’un jeu de commande AT sur une liaison série. Il existe des librairies
pour Arduino pour ces deux modules. ST propose aussi une librairie de gestion des commandes AT
pour le CMWX1ZZABZ. En effet, le CMWX1ZZABZ est en réalité une combinaison d’un STM32L0 et
d’un SX1276.
Ce choix-là possède l'avantage considérable de sa simplicité. Vous n'avez rien à gérer sur le
protocole LoRa/LoRaWAN car tout est fait dans le module. Le fait d'envoyer des commandes
applicatives simples permet au concepteur du Device LoRa de se focaliser sur son application.
La contrepartie est évidement le fait que le système global possède 2 microcontrôleurs : un pour le
Firmware de l'application et un pour la gestion de la stack LoRaWAN. Cela aura des influences sur le
prix de l'ensemble, et bien sûr, sa consommation.
Il faut savoir que seul le module RN2483 peut être soudé simplement avec des solutions "amateurs",
l’empreinte du CMWX1ZZABZ n’étant pas adaptée.
■ SEMTECH propose sa propre stack appelée "LoRa MAC Node" pour l’ensemble des
microcontrôleurs.
■ ST propose sa propre stack, qui reprend la "LoRa MAC Node" de SEMTECH, mais qui a été
améliorée pour mieux correspondre aux spécificités des microcontrôleurs STM32.
■ La stack "LMIC" est celle qui est utilisée lorsqu’on utilise des Arduino :
Nous verrons dans ce document l'installation d'un Network Server et d'un Application Server appelé
ChirpStack. Dans le cours LoRa - LoRaWAN proposé en vidéo vous verrez aussi l'installation de The
Things Stack qui est le serveur LoRaWAN de The Things Network.
Devices Packet
LoRa Gateways Internet
Forwarder
Network Application
Server Server
Figure 101 : Infrastructure d'un réseau LoRaWAN privé avec ChirpStack ou The Things Stack
Network Server
Gateway
Application Server
En fonction du Packet Forwarder qui sera utilisé, le protocole de communication entre la Gateway
et le Serveur LoRaWAN sera différent. Il faut donc obligatoirement vérifier la prise en charge du
Packet Forwarder sur la Gateway par le Serveur LoRaWAN. Il existe plusieurs Packet Forwarder
disponibles dont deux d'entre eux ont été développés par SEMTECH :
■ UDP Packet Forwarder : C'est le Packet Forwarder qui est le plus utilisé et tous les Serveurs
LoRaWAN le supportent. Il est aussi disponible (à ma connaissance) dans toutes les
Gateways. Il est simple et léger mais possède de nombreux défauts notamment du point de
vue de la sécurité et du manque de fonctionnalité.
■ Basic Station : Basic Station est le nouveau Packet Forwarder fourni par SEMTECH. Il offre
de nombreuses fonctionnalités supplémentaires : TLS, mise à jour logiciel de la Gateway,
synchronisation du temps, gestion des Gateways, etc…
D'autres Packet Forwarder sont aussi disponibles comme par exemple LORIOT Gateway Software
ou TTN Packet Forwarder. Malgré les défauts de UDP Packet Forwarder, son utilisation lors d'une
phase de développement d'un projet ne pose aucun problème. A titre pédagogique, sa simplicité
nous permettra de faire de l'analyse de trames échangées entre la Gateway et le Serveur LoRaWAN.
C'est ce que nous verrons au paragraphe 9.1.
Si vous utilisez une Raspberry PI, ChirpStack propose une image appelée chirpstack-gateway-os-
full. Cette image est prête à fonctionner et intègre les services Gateway Bridge, le Network Server
et l'Application Server qui se lanceront au démarrage de la RPI. Si vous avez choisi cette méthode
d'installation, vous pouvez directement passer à sa configuration que nous allons expliquer au
chapitre 9.4.
Dans tous les autres cas, nous utiliserons le système Docker et Docker Compose pour l'installation
de notre serveur. Docker nous permettra de réaliser des installations de façon extrêmement simple,
sans avoir à gérer les dépendances et librairies spécifiques à chacun des systèmes d'exploitation
(Windows, Linux, MacOS) et des processeurs utilisés (ARM, X86). Il agira comme une couche
d'abstraction qui isolera le service installé du reste du système.
Container Container
ChirpStack ChirpStack
Network Server App Server . . .
Libs Deps Libs Deps
DOCKER
Figure 103 : Utilisation de Docker et Docker Compose pour l'installation des Serveurs LoRaWAN
Nous nous servirons à nouveau de Docker et Docker Compose plus tard dans le cours lorsque nous
créerons notre propre Application, mais pour l'instant nous créerons uniquement les containers
nécessaires à ChirpStack.
ChirpStack est constitué d'un Network Server et d'un Application Server dont nous avons déjà
détaillé les rôles. Il est aussi constitué d'une entité appelée Gateway Bridge.
ChirpStack Gateway Bridge peut s'interfacer avec le UDP Packet Forwarder ou Basic Station.
Comme nous l'avons vu au chapitre 4.2.5, l'Application ne fait pas partie du Serveur LoRaWAN, et
ne fait donc pas partie du projet ChirpStack. C’est donc bien toujours à nous de la réaliser comme
nous le ferons au chapitre 10. Les protocoles utilisés pour communiquer avec notre Application
sont multiples, notamment ceux que nous avons déjà étudiés au chapitre 7.3 (HTTP POST ) et au
chapitre 7.4 (MQTT).
■ Le Gateway Bridge.
■ Le Network Server.
■ L'Application Server.
La figure représente les services (containeur Docker) générés avec Docker Desktop sous Windows.
Figure 105 : Containers Docker des 3 services principaux de ChirpStack sous Windows
La figure représente les services (containeur Docker) générés avec Docker Desktop sous Linux avec
la commande : docker ps
Dans les deux cas, les informations sont similaires et nous montre que les 3 services sont actifs.
Figure 106 : Containers Docker des 3 services principaux de ChirpStack sous Linux
Nous pouvons remarquer que deux containers écoutent sur des ports :
■ Le service Gateway Bridge écoute sur le port 1700/udp. C'est donc vers ce port qu'il faudra
que notre Gateway transmette ses informations.
Configuration de
ChirpStack
Listen Port
8080/tcp
Listen Port
1700/udp
■ Username: admin
■ Password: admin
Pour enregistrer une nouvelle Application : Applications > Create. Puis entrer les configurations
suivantes :
Onglet GENERAL :
Vous pouvez préciser ici si vous souhaitez travailler en APB ou en OTAA. Cliquer sur "Device supports
OTAA" puisque nous faisons l'essai en OTAA.
On poursuit la configuration dans Application > myApplication > Devices > myDevice > KEY(OTAA).
Il faut alors préciser la clé AppKey.
En allant dans Application > myApplication > Devices > myDevice > DEVICE DATA, on peut voir la
liste des trames reçues ainsi que les données applicatives déchiffrées (Frame Payload).
Dans l’onglet Application > myApplication > Devices > myDevice > LORAWAN FRAMES, nous
pouvons voir les trames LORAWAN, et si besoin, étudier le contenu de ce qu’elles contiennent. En
revanche, les données applicatives sont ici chiffrées.
Enfin, si vos trames n'arrivent pas à votre Application Server, vous pouvez vérifier qu'elles arrivent
à votre Gateway : Gateway > myGateway > LIVE LORAWAN FRAMES
■ Payload marshaler : Le format utilisé pour transférer les données (JSON est un bon choix).
■ EndPoint : L'URL de votre serveur HTTP POST.
On remarque que les paquets sont envoyés en UDP au Network Server dans une trame appelée
PUSH_DATA . Cette trame est acquittée par le Network Server par une trame appelée PUSH_ACK.
Sur notre Network Server, nous pouvons réaliser une capture de trame pour vérifier si le protocole
est bien celui présenté dans le document :
D’après la capture précédente, on remarque que le Packet Forwarder fonctionne bien avec UDP sur
le port 1700.
Le contenu des données (champ Data) est détaillé dans le tableau suivant :
Champ [2]
Champ [3]
Champ [4]
0000 02 f9 30 00 b8 27 eb ff fe ae 26 f5 7b 22 72 78 ..0..'....&.{"rx
0010 70 6b 22 3a 5b 7b 22 74 6d 73 74 22 3a 33 37 35 pk":[{"tmst":375
0020 35 30 30 35 38 31 39 2c 22 63 68 61 6e 22 3a 32 5005819,"chan":2
0030 2c 22 72 66 63 68 22 3a 31 2c 22 66 72 65 71 22 ,"rfch":1,"freq"
0040 3a 38 36 38 2e 35 30 30 30 30 30 2c 22 73 74 61 :868.500000,"sta
0050 74 22 3a 31 2c 22 6d 6f 64 75 22 3a 22 4c 4f 52 t":1,"modu":"LOR
0060 41 22 2c 22 64 61 74 72 22 3a 22 53 46 37 42 57 A","datr":"SF7BW
0070 31 32 35 22 2c 22 63 6f 64 72 22 3a 22 34 2f 35 125","codr":"4/5
0080 22 2c 22 6c 73 6e 72 22 3a 36 2e 35 2c 22 72 73 ","lsnr":6.5,"rs
0090 73 69 22 3a 2d 31 2c 22 73 69 7a 65 22 3a 31 38 si":-1,"size":18
00a0 2c 22 64 61 74 61 22 3a 22 51 4e 4d 61 41 53 59 ,"data":"QNMaASY
00b0 41 41 51 41 50 70 79 50 5a 39 35 35 2b 53 6d 59 AAQAPpyPZ955+SmY
00c0 2f 22 7d 5d 7d /"}]}
Figure 115 : Trame capturée par Wireshark lors de l’acquittement d’un Uplink
C'est pourquoi dans le cadre de ce cours, nous utiliserons Node-RED pour mettre en place ces
fonctionnalités. Node-RED est un outil de programmation graphique qui permet de faire
communiquer les périphériques matériels d’un système sans écrire de code. De nombreux
protocoles sont aussi pris en charge au travers de bloc (Node) qu’il suffit de connecter entre eux
pour réaliser simplement une application. Il peut s’exécuter localement sur un PC ou sur des cibles
embarquées telle qu’une Raspberry PI (RPI).
Dans les vidéos, la notion de cloud IOT comme AWS (Amazon Web Service) ou Microsoft Azure sera
aussi présentée.
Solution de monitoring
Gestion de l'affichage des données :
complète, librairies pour
Courbes, histogrammes, tableaux,
Dashboard…
jauges, etc…
Base de données
Sauvegarde des données
Fichier texte
Endpoint HTTP
Récupération des données
Subscriber ou Publisher MQTT HTTP / MQTT
Nous devons maintenant récupérer les scripts de création des containers sur GitHub.
Télécharger https://github.com/SylvainMontagny/dashboard-lorawan/
Pour vérifier que le service Node-RED est bien actif, vous devez pouvoir faire le test suivant :
Dans votre navigateur web, le lien http://@IP_Serveur:1880/ doit ouvrir Node-RED [ login :
admin / Password : lorawan ].
La version de Node-RED que nous vous proposons ici est la version de base à laquelle ont été ajouté
les librairies :
■ The Things Network
■ InfluxDB
■ Dashboard
Le service Node-RED doit s'ouvrir avec un flow préconfiguré. Si ce flow n'apparait pas, vous pouvez
l'importer facilement : Menu (en haut à droite) > import > coller le contenu du fichier
nodered/flow.json qui se trouve dans les documents que vous venez de télécharger. Il s'agit de la
solution que nous allons mettre en place pas à pas dans les prochains chapitres. Si vous souhaitez
partir de zéro et refaire la démarche, alors vous pouvez supprimer ce flow. Si vous souhaitez
rapidement faire fonctionner ce flow, il reste uniquement la configuration du node "ttn Uplink" qui
est expliquée au paragraphe suivant.
Pour notre cas d'étude, nous nous placerons dans un cas simple qui est l'envoi d'une température
sur un octet par un capteur. Nous souhaitons :
Node 1 : Node 2 :
Récupération de données en Stockage de cette donnée
provenance de TTN (MQTT) dans une BDD influxDB
Node 3 :
Affichage des courbes, et
service web
Nous allons gérer le flux Uplink. Apportez sur votre schéma un node ''ttn uplink" et un Node "Debug"
puis reliez-les. Le Node "ttn uplink" nous permettra de configurer la communication avec TTN en
MQTT. Le Node "debug" écrira sur le terminal les informations brutes qui seront reçues par le Node
"ttn uplink".
Double cliquer sur le Node "ttn uplink" pour le configurer comme sur la Figure 119 :
Le champ "Name" sera le nom du node sur votre schéma. Le champ Device ID est le Device LoRa
concerné dans votre application. De plus, il faut entrer les caractéristiques de votre application (Add
new ttn app) pour que Node-RED puisse s'y connecter.
Le node "ttn uplink" doit maintenant avoir le nom que vous avez configuré. Cliquer sur Deploy pour
lancer votre projet. Le bloc "ttn uplink" doit maintenant être connecté à TTN. Cela est spécifié
"connected" sous le bloc.
Vous pouvez alors vérifier que le message arrive bien dans la fenêtre de Debug à chaque réception
d'une donnée en provenance du Device LoRa.
Pour que node-RED montre l'ensemble des propriétés de l'objet dans la fenêtre de debug,
il faut modifier les propriétés du node Debug : Output > Complete msg Object
On remarque que le msg.payload fourni par TTN est bien un buffer, alors que celui que nous
souhaitons est un nombre. Nous devons donc réaliser l'affectation suivante :
Cette transformation peut être réalisée de plusieurs façon dans node-RED. La plus simple est
d'utiliser le node "change" et de lui affecter la configuration suivante :
L'URL pour joindre l'interface graphique de votre site web est disponible sur l'adresse
http://@IP_Serveur:1880/ui .
Émettez une donnée en LoRa, ou faites une simulation d'Uplink (comme nous l'avons vu au
paragraphe 5.2.5). L'interface graphique devrait se mettre à jour automatiquement.
Les écritures dans la BDD se font grâce au protocole LINE. Dans notre cas, nous définirons un
"measurement" appelé "temperatures" et les champs (fields) seront appelés "values".
La BDD étant déjà installée d'après la mise en place de l'environnement de travail que nous avons
vu au paragraphe 10.1, nous pouvons donc directement commencer à travailler. La BDD a été
configurée avec une base appelée "maBase". Nous allons tout d'abord vérifier que nous pouvons
bien nous connecter et lire des valeurs dans cette BDD. Pour cela nous allons ouvrir un terminal
dans le conteneur docker contenant la BDD InfluxDB, en tapant la commande suivante dans le
terminal de la machine contenant votre BDD :
docker exec -it influxdb /bin/bash
Nous sommes maintenant dans le conteneur docker influxdb. Les manipulations suivantes vont :
root@7bab25790b83:/# influx
Connected to http://localhost:8086 version 1.8.0
InfluxDB shell version: 1.8.0
> SHOW DATABASES
maBase
_internal
> USE maBase
Using database maBase
> INSERT temperatures value=25
> SHOW MEASUREMENTS
name: measurements
temperatures
> SELECT * FROM temperatures
name: temperatures
time value
---- -----
1589491733559187535 25
Nous allons maintenant placer les données reçues par TTN dans notre BDD. Il suffit de les donner à
un "node influxdb out" comme le montre la Figure 127.
On peut alors vérifier que les données sont bien stockées convenablement dans la BDD à chaque
fois que TTN transfère une mise à jour de température.
Le mode d'activation ABP fourni directement ces clés au Device. Cela simplifie le processus au
détriment de la sécurité globale. Le mode d'activation recommandé est donc OTAA afin qu'un
nouveau jeu de clés NwSKey et AppSKey soit généré à chaque nouvelle session grâce au Join-
Request émit par le Device. Mais qui exactement gère ce Join-Request? Jusqu'à maintenant, nous
avions considéré que cette phase d'activation était traitée par le Network Server. En réalité, c'est
une entité spécifique qui s'appelle le Join Server qui s'en charge. Le Join Server est directement
connecté à la fois au Network Server et à l'Application Server et possède un identifiant unique sur 8
octets (EUI) appelé le JoinEUI. Lors d'un Join-Request, le JoinEUI doit être émis pour spécifier quel
Join Server sera utilisé pour traiter la phase d'activation.
Network Application
Server Server
Join
Server
Depuis la version du protocole LoRaWAN 1.0.4, le JoinEUI Remplace l'AppEUI. Lorsque vous
configurer un Device LoRa il faut donc connaitre la version du protocole qui est géré par la stack
LoRaWAN. De plus, lorsque vous renseignez les informations sur le Serveur LoRaWAN, il faut
préciser la version du protocole utilisé. Sur la Figure 129, nous avons représenté sur la première
Le DevNonce est une valeur importante pour le Join-Request car il permet de protéger des attaques
par REPLAY exactement comme nous l'avons vu pour le Frame Counter au chapitre 4.5.2 : Un
DevNonce ne peut pas être utilisé deux fois pour un Device. Le nombre de Join-Request maximum
est donc de 65536, ce qui ne devrait bien sur jamais arriver car dans un fonctionnement normal, un
Device LoRa générera une demande d'activation (Join-Request) rarement. La spécification
LoRaWAN propose une gestion différente du DevNonce en fonction de la norme LoRaWAN avec
laquelle on travaille :
Lorsque le Join-Request est accepté, le Serveur LoRaWAN retourne un Join-Accept avec les
informations représentées Figure 131. Parmi celles-ci se trouvent le DevAddr, des informations de
configuration du réseau, ainsi que tout ce que le Device a besoin pour générer de son côté le
NwkSKey et l'AppSKey.
On peut se demander l'intérêt d'une telle structure, car la gestion des clés est alors simplement
déportée sur un autre serveur. Pour répondre à cette question, il faut reprendre et améliorer la
Figure 128. En effet, le Join Server n'est pas destiné à être un service interne et enfermé dans le
Serveur LoRaWAN et connecté à un unique Network Server et Application Server.
Devices Gateways
Serveur JOIN
LoRaWAN Server
1 1
Serveur JOIN
LoRaWAN Server
2 2
Serveur
LoRaWAN
3
Figure 132 : Interconnexion des Join Server avec les Serveurs LoRaWAN
Une telle structure sera donc très avantageuse d'un point de vue de la sécurité et de
l'interopérabilité des Devices au sein de différent réseaux.
Avant qu'un réseau LoRaWAN puisse fonctionner, un certains nombres d'échanges doivent être
réalisés entre le concepteur du Device (Device Maker), l'utilisateur final (End User) et le Join Server
comme le montre la Figure 133.
Network Application
Server Server
Figure 133 : Echanges entre le Device Maker, l'utilisateur final et le Join Server
1. Lors de l'industrialisation, le Device Maker va les provisionner les Devices avec les clés
(AppKey en LoRaWAN 1.0.x) ainsi que le JoinEUI et le DevEUI. Le DevEUI et l'AppKey doivent
aussi être stockés sur le Join Server. Il faut donc qu'ils se mettent d'accord d'un moyen
sécurisé pour que les clés ne soient pas exposées. Cette échange de clés est décrit par le
symbole (1) sur la Figure 133. Il faudra ensuite que ces clés sont enregistrées de façon très
sécurisée sur les deux entités.
2. Une fois le Device construit, il est vendu à l'utilisateur final. Cette action est décrite par le
symbole (2) sur la Figure 133.
3. Enfin, l'utilisateur final doit prouver la propriété du Device en le réclamant sur le Join Server.
Cette action permettra de définir les Network Server et Application Server lié au Join Server
et autorisera la création des clés de Sessions (NwSKey et AppSKey) lors de l'activation du
Device (Join Request). Cette action est décrite par le symbole (3) sur la Figure 133 .
Les points (1) et (3) vont être décrits dans les prochains chapitres.
■ Comment place-t-on les même clés "root keys" dans le Device et dans le Join Server sans
les exposer? Cette opération est délicate car la programmation du Device LoRa est faite
chez un industriel qui n'est pas forcément quelqu'un de confiance, donc vous ne pouvez pas
nécessairement lui fournir la liste des clés à intégrer dans vos composants sans précaution.
■ Comment éviter l'accès aux clés (NwSKey, AppSKey et AppKey) malgré les tentatives
d'intrusion matériel ? L'accès physique aux mémoires stockant les clés doit être le plus
limité possible. Un détection d'intrusion doit amener à l'autodestruction des clés.
■ Comment utiliser les clés sans laisser d'indice permettant d'aider à les retrouver? Les
calculs réalisée pendant le chiffrement ne doivent pas laisser de trace, comme par exemple
Pour sécuriser le stockage de ces clés et pour réaliser toutes les opérations de cryptographie, des
modules matériels spécifiques à la fois coté Device et coté Serveur sont donc nécessaires.
■ On parle de SE (Secure Element) coté Device. Ce sont des tout petit composants proche du
microcontrôleur. Ils sont même parfois intégrés au microcontrôleur.
Par exemple le composant ATECC608B-TNGACT possède toutes ces caractéristiques, et est en plus
déjà provisionné, c’est-à-dire qu'il contient déjà les "root keys" pour le serveur LoRaWAN ACTILITY.
■ On parle de HSM (Hardware Security Module) coté serveur. Ils ont les mêmes
caractéristiques, mais avec plus de puissance et de fonctionnalités.
Version initiale.
Modification : Le paragraphe "La Trame LoRa / LoRaWAN" est maintenant un chapitre entier.
Modification : Le chapitre "Mise en œuvre" d'un réseau LoRa est intégré au chapitre sur le
LoRaWAN.
Modification : Séparation des paragraphes sur le DR, les canaux.
Ajout : Paragraphe sur le ADR (Adaptive Data Rate)
Modification : Nouveau chapitre "Les réseaux et serveurs LoRaWAN"
Ajout : Coût abonnement des réseaux LoRaWAN Bouygues et Orange (Juillet 2020)
Ajout : Tableau de choix entre réseau privé et opéré
Ajout : Les réseaux LoRaWAN dédiés
Ajout : Mise en ligne de la formation LoRaWAN sur UDEMY
Udemy : Ajout des vidéos sur la création de notre propre Network Server et Application Server.
Modification : Mise à jour du chapitre sur la configuration de la Gateway
Modification : Mise à jour complète de la création de notre propre Network Server et
Application Server. Passage de LoRaServer à ChirpStack
Modification : Les énoncés des manipulations sont dans un document "élève" à part.
Modification : Les corrections des exemples et exercices sont systématiquement fournies.
Correction : Très nombreuses corrections (orthographe) grâce à l'œil attentif d'Albert.
Ajout : Liste des acronymes complétés.
Information : Le flux Downlink en HTTP POST et en MQTT sur Chirpstack est seulement traité
en vidéo sur UDEMY.
Modification : Refonte complète du chapitre sur la création de notre propre Application
Ajout : Incitation à la collaboration et signalement des erreurs.
Udemy : Ajout du chapitre sur l'installation et la configuration de "The Things Stack"
Udemy : Réparation de la vidéo de l'adaptive Data Rate
Modification : Le site thethingsstack.io devient thethingsindustries.com/docs
Ajout : Présentation de la formation LoRa LoRaWAN en ligne sur 2 jours
Toutes remarques, modifications, améliorations, corrections peuvent être proposées par email :
sylvain.montagny@univ-smb.fr ou par le formulaire suivant : https://cutt.ly/erreurs.
TTN v3
LORIOT
LoRa Cloud
"downlink_url":"https://integrations.thethingsnetwork.org/ttn-
eu/........................8ypjj7ZnL3KieQ"
{
"dev_id": "YourDeviceID",
"payload_raw": "aGVsbG8=",
"port": 1,
"confirmed": false
}
Rajouter le champs JSON : POSTMAN > Body > Pretty > JSON :
{"downlinks":[{"frm_payload":"aGVsbG8=","f_port":15,"priority":
"NORMAL"}]}
■ <API TOKEN> : ChirpStack > API Key > Create API Key
■ http://localhost : Mettre l'adresse http://xxxxx.master-stic.fr ou https://ns.loracloud.com
■ 0101010101010101 : Mettre le DevEUI
Pour LORIOT :
[ https://docs.loriot.io/display/LNS/Send+Downlinks+via+API ]
Pour TTN v3 :
Pour ChirpStack :
[ Documentation : https://www.chirpstack.io/application-server/integrations/mqtt/ ]
■ Payload JSON :
{
"dev_id": "<DevID>",
"payload_raw": "aGVsbG8=",
"port": 1
}
Pour TTN v3 :
■ Payload JSON :
{
"downlinks": [{
"f_port": 15,
"frm_payload": "aGVsbG8=",
"priority": "NORMAL"
}]
}
Pour ChirpStack :
[ Documentation : https://www.chirpstack.io/application-server/integrations/mqtt/ ]
■ Payload JSON :
{
"confirmed": false,
"fPort": 10,
"data": "aGVsbG8="
}
■ Payload JSON :
{
"downlinks": [{
"f_port": 15,
"frm_payload": "aGVsbG8="
}]
}