cours - formation lora / lorawan
TRANSCRIPT
Cours - Formation LoRa LoRaWAN
Version du cours 40
Mars 2019
Sylvain MONTAGNY
sylvainmontagnyuniv-smbfr
Universiteacute Savoie Mont Blanc
| 2
Preacutesentation du document
Ce cours sur lrsquointernet des Objets et les protocoles LoRa LoRaWAN est le support drsquoune formation
proposeacutee par lrsquoUniversiteacute de Savoie Mont Blanc (USMB) Elle est reacutealiseacutee
Aux eacutetudiants du Master ESET (Electronique des Systegravemes Embarqueacutes et Teacuteleacutecoms) Site web
de la formation [ wwwmaster-electroniquecom ]
Aux entreprises qui en font la demande (1 ou 2 journeacutees) sylvainmontagnyuniv-smbfr
Ce cours est mis agrave disposition sur internet et est libre drsquoutilisation Toutes personnes
souhaitant apporter des modifications ameacuteliorations corrections peut le faire sur
lrsquoadresse mail sylvainmontagnyuniv-smbfr Lrsquoauteur vous remercie par avance pour
votre contribution
Sigles et Acronymes
LoRa Long Range
LoRaWAN Long Rang Wide Area Network
LPWAN Low Power Wide Area Network
TTN The Things Network
MQTT Message Queuing Telemetry Transport
QoS Quality of Service
HTTP HyperText Transfer Protocol
IoT Internet Of Things
LTE-M Long Term Evolution Cat M1
NB-IoT NarrowBand Internet of Things
FDM Frequency Division Multiplexing
TDM Time Division Multiplexing
CDMA Code Division Multiple Access
RSSI Received Signal Strength Indication
SNR Signal Over Noise Ratio
SF Spreading Factor
CR Coding Rate
CHIRP Compressed High Intensity Radar Pulse
JSON JavaScript Object Notation
SDR Software Digital Radio
| 3
Sommaire 1 LES SYSTEMES EMBARQUES ET LrsquoIOT 6
11 LINTERNET DES OBJETS ( INTERNET OF THINGS IOT ) 6 111 Les systegravemes embarqueacutes dans lrsquoIoT 6 112 Diffeacuterents protocoles dans lrsquoIoT 6 113 Bande de freacutequence utiliseacutees 7
12 MODES DE PARTAGE DU SUPPORT 7 13 NOTION DrsquoETALEMENT DE SPECTRE 8
131 Transmissions successives 8 132 Transmissions simultaneacutees 9 133 Cas du protocole LoRa 9
2 TRANSMISSION RADIO ET PROPAGATION 10
21 LES UNITES ET DEFINITIONS 10 22 ETUDE DE LA DOCUMENTATION DrsquoUN COMPOSANT LORA 11
3 LA COUCHE PHYSIQUE LORA 13
31 LA MODULATION LORA 13 311 La forme du symbole (Chirp) 13 312 Dureacutee drsquoeacutemission drsquoun symbole 15
32 CODING RATE 16 33 UTILISATION DU LORA CALCULATOR 17 34 TIME ON AIR 18 35 MISE EN ŒUVRE LORA EN POINT A POINT 19
351 Utilisation de lrsquoIDE Arduino 19 352 Validation du fonctionnement 20 353 Mise en valeur du Spreading Factor 20
4 LE PROTOCOLE LORAWAN 21
41 STRUCTURE DrsquoUN RESEAU LORAWAN 21 411 Les Devices LoRa 21 412 Les Gateways LoRa 21 413 Le Network Server 22 414 Application Server 22 415 Application Web Serveur 24 416 Authentification avec le Network Server 25 417 Chiffrement des donneacutees vers lrsquoApplication Server 25 418 Combinaison de lrsquoauthentification et du chiffrement 26
42 CLASSES DES DEVICES LORAWAN 26 421 Classe A (All) Minimal power Application 26 422 Classe B (Beacon) Scheduled Receive Slot 27 423 Classe C (Continuous) Continuously Listening 28 424 Quelle Gateway pour les flux Downlink 29
43 ACTIVATION DES DEVICES LORA ET SECURITE 29 431 ABP Activation By Personalization 29 432 OTAA Over The Air Activation 30 433 Seacutecuriteacute 31
44 LA TRAME LORA LORAWAN 32 441 Les couches du protocole LoRaWAN 32 442 Couche Application 33 443 Couche LoRa MAC 34
| 4
444 Couche physique Modulation LoRa 34 445 Canaux et bandes de freacutequences et Data Rate (DR) 35 446 Trame reccedilue et transmise par la Gateway LoRaWAN 36 447 Le format JSON 37
5 MISE EN ŒUVRE DrsquoUN RESEAU LORAWAN 38
51 LES DIFFERENTS TYPES DE RESEAUX 38 511 Les reacuteseaux LoRaWAN opeacutereacutes 38 512 Les reacuteseaux LoRaWAN priveacutes 38 513 Les zones de couvertures 38
52 THE THINGS NETWORK (TTN) 39 521 Preacutesentation de TTN 39 522 Configuration de la Gateway 39 523 Enregistrement des Gateways Appplication et Devices 39 524 Configuration des Devices LoRa 40
53 MISE EN APPLICATION 41 54 ANALYSE DES TRAMES ECHANGEES 41
541 Utilisation de la base 64 41 542 Inteacuterecirct et inconveacutenient de la base 64 43 543 Uplink Du Device LoRa au Network Server 43 544 Uplink Du Network Server agrave lrsquoApplication Server 45 545 Simulation drsquoUplink dans lrsquoApplication Server 46 546 Downlink De lrsquoApplication Server au Device LoRa 46
6 LA RECUPERATION DES DONNEES SUR NOTRE PROPRE APPLICATION 47
61 RECUPERATION DES DONNEES EN HTTP POST DANS LrsquoAPPLICATION 47 611 Preacutesentation du protocole HTTP 47 612 Fonctionnement drsquoun client et drsquoun serveur HTTP POST 48 613 Test du serveur HTTP POST 49 614 Test du client HTTP POST 49 615 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST 49 611 Envoyer des donneacutees depuis notre Application avec HTTP POST 51
62 RECUPERATION DES DONNEES AVEC MQTT DANS LrsquoAPPLICATION 52 621 Preacutesentation du protocole MQTT 52 622 Connexion au Broker MQTT 53 623 Qualiteacute de Service au cours dune mecircme connexion 53 624 Qualiteacute de Service apregraves une reconnexion 55 625 Les Topics du protocole MQTT 55 626 Mise en place drsquoun Broker MQTT 56 627 Mise en place drsquoun Publisher et drsquoun Subscriber MQTT 57 628 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT 57 629 Envoyer des donneacutees depuis notre Application avec MQTT 60
7 CREATION DE NOTRE PROPRE NETWORK ET APPLICATION SERVER 63
711 Objectifs 63 712 Preacutesentation de LoRaServer 63 713 Le laquo Packet Forwarder raquo (Gateway) 64 714 LoRa Gateway Bridge 66 715 LoRa Server (Network Server) 66 716 LoRa App Server (Application Server) 67 717 LoRa Geo Server 67 718 Application 67
72 INSTALLATION DE LORASERVER 67
| 5
721 Mise en place de lrsquoenvironnement 67 722 Installation sur la Raspberry PI 68
71 CONFIGURATION DE LORA SERVER POUR LUPLINK 69 711 Enregistrement drsquoune nouvelle Organisation 69 712 Enregistrement drsquoune instance du Network Server 69 713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) 70 714 Enregistrement des Devices LoRa 71 715 Visualisation des trames reccedilues 72
72 CONFIGURATION DE LORASERVER POUR LINTEGRATION DAPPLICATION 74 721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST 74 722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT 74
8 CREATION DE NOTRE PROPRE APPLICATION 76
81 UTILISATION DE NODE-RED 76 811 Preacutesentation 76 812 Mise en place de lrsquoenvironnement 76 813 Creacuteer une Application speacutecifique pour TTN 77 814 Creacuteation drsquoun Dashboard 79
82 PROGRAMMATION EN PHP 80
9 VERSIONS DU DOCUMENT 82
| 6
1 Les systegravemes embarqueacutes et lrsquoIoT
11 LInternet des Objets ( Internet of Things IoT )
111 Les systegravemes embarqueacutes dans lrsquoIoT Drsquoune faccedilon geacuteneacuterale les systegravemes eacutelectroniques peuvent ecirctre caracteacuteriseacutes par leur consommation
leur puissance de calcul leur taille et leur prix Dans le cas speacutecifique des systegravemes embarqueacutes
utiliseacutes dans lrsquoIoT nous pouvons affecter le poids suivant agrave chacune des caracteacuteristiques
Figure 1 Consommation Puissance Taille et Prix des objets connecteacutes
Compareacutes aux autres systegravemes eacutelectroniques les systegravemes embarqueacutes utiliseacutes dans lrsquoIoT possegravedent
donc
Une faible consommation
Une faible puissance de calcul
Une petite taille
Un prix faible
112 Diffeacuterents protocoles dans lrsquoIoT
Citez les diffeacuterents protocoles que vous connaissez dans le mode de lrsquoIoT (Internet Of
Things) et reportez-les dans le graphique ci-dessous en fonction de leur bande passante
et de leur porteacutee
Figure 2 Protocoles utiliseacutes dans lIoT en fonction du deacutebit et de la porteacutee
Dans lrsquoIoT les protocoles utiliseacutes possegravedent une grande porteacutee et des deacutebits faibles
Lrsquoensemble de ces reacuteseaux sont deacutenommeacutes LPWAN Low Power Wide Area Network
113 Bande de freacutequence utiliseacutees En Europe les bandes de freacutequences libres (sans licence) sont
13 Mhz (RFID) 169 Mhz 434 Mhz 868 Mhz 24Ghz 5 Ghz et 24 Ghz (Faisceau Hertzien) Parmi ces
freacutequences seul le 433 MHz et 868 MHz sont utilisables en LoRa
12 Modes de partage du support Quel que soit le protocole utiliseacute le support de transfert de lrsquoinformation est lrsquoair car tous les
protocoles de lrsquoIoT sont Wireless Le support doit ecirctre partageacute entre tous les utilisateurs de telle
faccedilon que chacun des dispositifs Wireless ne perturbe pas les autres Pour cela une bande de
freacutequence est alloueacutee Par exemple pour la radio FM la bande de freacutequence va de 875 Mhz agrave 108
Mhz
Dans leur bande de freacutequence les dispositifs peuvent se partager le support de diffeacuterentes
maniegraveres
FDM (Frequency Division Multiplexing) Ce mode utilise une partie du spectre (bande de
freacutequence) en permanence Exemple Radio FM
TDM (Time Division Multiplexing) Ce mode utilise tout le spectre (bande de freacutequence) par
intermittence Exemple GSM on a laquo 8 time slots raquo par canal
CDMA (Code Division Multiple Access) Ce mode utilise tout le spectre tout le temps
Porteacutee (Range)
Deacutebit (Bandwidth)
| 8
Les Devices LoRa sont capables drsquoeacutemettre sur un mecircme canal en mecircme temps Le protocole LoRa
utilise une modulation tregraves similaire agrave la meacutethode 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 Plus
tard dans le cours nous expliquerons les diffeacuterences de la modulation LoRa
13 Notion drsquo eacutetalement de spectre utiliseacutee en LoRa Nous allons voir au travers drsquoun exercice comment il est possible drsquoutiliser tout le spectre en
permanence tout en eacutetant capable drsquoeffectuer plusieurs transactions simultaneacutees entre diffeacuterents
eacutemetteursreacutecepteurs Cette meacutethode est souvent appeleacutee laquo eacutetalement de spectre raquo car comme
son nom lrsquoindique elle a pour conseacutequence drsquoeacutetaler le spectre du signal transmis
La meacutethode consiste agrave utiliser des codes qui ont des proprieacuteteacutes matheacutematiques adapteacutees agrave notre
objectif Transmettre en mecircme temps sur la mecircme bande de freacutequence La matrice ci-dessous
donne par exemple 4 codes drsquoeacutetalement (1 par ligne)
Code Orthogonal User 0 1 1 1 1
Code Orthogonal User 1 1 -1 1 -1
Code Orthogonal User 2 1 1 -1 -1
Code Orthogonal User 3 1 -1 -1 1
Tableau 1 Matrice de Hadamart (matheacutematicien) dordre 4
Les proprieacuteteacutes de ces codes (1 1 1 1 1 -1 1 -1 1 1 -1 -1 1 -1 -1 1) ne sont pas expliqueacutees ici Nous
nous conterons de veacuterifier leur bon fonctionnement
131 Transmissions successives Chaque tableau ci-dessous repreacutesente une transmission qui est indeacutependante des autres elles ne
se deacuteroulent pas en mecircme temps On veacuterifie qursquoavec la mise en œuvre de laquo lrsquoeacutetalement de spectre raquo
chaque transmission arrive bien agrave destination avec le message qui avait eacuteteacute transmis Le premier
tableau est deacutejagrave rempli en guise drsquoexemple La meacutethode est la suivante
A lrsquoeacutemission
Chaque bit du message est multiplieacute par un code drsquoeacutetalement (une ligne de la matrice)
Le reacutesultat de la multiplication est transmis
A la reacuteception
Chaque symbole reccedilu est multiplieacute par le mecircme code drsquoeacutetalement
Le message reccedilu est eacutegal agrave la somme des symboles diviseacute par le nombre de symbole
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
hellip transmission hellip
4 Utilisation code orthogonal User 1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1
5 Deacutecodage = (3) x (4) 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0
6 Message reccedilu (sum (5) nbr_bits) 1 0 1 0
Reacutealiser la transmission du message du User 2 et du User 3 dans les tableaux suivants
| 9
1rsquo Message User 2 0 1 0 1
2rsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
3rsquo Symboles transmis User 2 = (1rsquo) x (2rsquo) 0 0 0 0
hellip transmission hellip
4rsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
5rsquo Deacutecodage = (3rsquo) x (4rsquo) 0 0 0 0
6rsquo Message reccedilu (sum (5rsquo) nbr_bits) 0
1rsquorsquo Message User 3 1 1 0 0
2rsquorsquo Utilisation code orthogonal User 3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
3rsquorsquo Symboles transmis User 3 = (1rsquorsquo) x (2rsquorsquo) 1 -1 -1 1
hellip transmission hellip
4rsquorsquo Utilisation code orthogonal User3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
5rsquorsquo Deacutecodage = (3rsquorsquo) x (4rsquorsquo) 1 1 1 1
6rsquorsquo Message reccedilu (sum (5rsquorsquo) nbr_bits) 1
132 Transmissions simultaneacutees
Les transmissions se deacuteroulent maintenant simultaneacutement les messages des User 1 User 2 et User
3 sont envoyeacutes en mecircme temps sur la mecircme bande de freacutequence La premiegravere colonne du User 1
est deacutejagrave remplie en guise drsquoexemple La meacutethode est la suivante
Dans lrsquoair
On additionne les symboles transmis par tous les User (1 2 3) ligne 1rsquorsquorsquo
Pour la reacuteception
Chaque symbole reccedilu est multiplieacute par le code drsquoeacutetalement du User
Le message reccedilu est eacutegal agrave la somme des symboles diviseacute par le nombre de symbole
Valider le fonctionnement pour la reacuteception des messages
1rsquorsquorsquo sum des symboles transmis ( 3 + 3rsquo + 3rsquorsquo ) 2 -2 0 0
2rsquorsquorsquo Utilisation code orthogonal User 1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 2 0 0
4rsquorsquorsquo Message reccedilu User 1 (sum (3rsquorsquorsquo) nbr_bits) 1
2rsquorsquorsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 -2 0 0
4rsquorsquorsquo Message reccedilu User 2 (sum (3rsquorsquorsquo) nbr_bits) 0
2rsquorsquorsquo Utilisation code orthogonal User 3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 2 0 0
4rsquorsquorsquo Message reccedilu User 3 (sum (3rsquorsquorsquo) nbr_bits) 1
133 Cas du protocole LoRa Le LoRa utilise une meacutethode drsquoeacutetalement de spectre qui nrsquoest pas exactement celle que nous venons
drsquoeacutetudier La finaliteacute est cependant la mecircme Pouvoir transmettre en mecircme temps sur le mecircme
canal Le protocole LoRa utilise sept laquo codes drsquoeacutetalement raquo appeleacutes Spreading Factor [ SF6 SF7 SF8
SF9 SF10 SF11 et SF12 ] qui lui permet drsquoavoir sept transmissions simultaneacutees sur un mecircme canal
| 10
2 Transmission radio et propagation
21 Les uniteacutes et deacutefinitions dB Rapport entre deux puissances Une atteacutenuation est repreacutesenteacutee par un nombre
neacutegatif (-) Un gain est repreacutesenteacute par un nombre positif (+)
Rapport de puissances en dB Rapport de puissance
+ 3 dB Multiplication par 2
- 3 dB Division par 2
0 dB Egaliteacute
+ 10 dB Multiplication par 10
- 10 dB Division par 10
Tableau 2 Comparaison entre les gains en dB et en proportion
dBi Gain theacuteorique drsquoune antenne
dBm Puissance rameneacutee agrave 1mW 0 dBm correspond agrave 1 mW
En reprenant la deacutefinition des dB remplir le tableau suivant
Puissance en dBm Puissance en mW
+ 3 dBm
- 3 dBm
+ 10 dBm
- 10 dBm
Tableau 3 Comparaison entre les puissances en dB et en mW
Le Talkie-Walkie a une puissance drsquoeacutemission de 2W Quelle est la puissance drsquoeacutemission
exprimeacutees en dBm
Sensibiliteacute Puissance minimale qursquoest capable de deacutetecter un reacutecepteur
RSSI Received Signal Strength Indication
SNR Signal over Noise Ratio
Un eacutemetteur transmet agrave une puissance de 13dBm en utilisant une antenne dont le gain
est de 2dBi Les pertes dans lrsquoair sont de 60 dB Lrsquoantenne reacuteceptrice qui possegravede un gain
de 2dBi est relieacutee agrave un reacutecepteur dont la sensibiliteacute est de -80 dBm Le signal pourra-t-il
ecirctre reccedilu
Le link Budget Crsquoest la quantiteacute de puissance que nous pouvons perdre avant drsquoarriver au
reacutecepteur tout en conservant une transmission fonctionnelle Autrement dit crsquoest la
puissance de lrsquoeacutemetteur moins la sensibiliteacute du reacutecepteur Dans lrsquoexemple preacuteceacutedent le
budget que nous avons agrave disposition est de 93dB
| 11
En LoRa nous avons un Link Budget de 157 dB
En LTE (4G) nous avons un Link Budget de 130 dB
Etude de la documentation drsquoun composant LoRa Le RN2483 est le composant radiofreacutequence que nous utiliserons dans notre transmission LoRa
Voici quelques une de ses caracteacuteristiques
Figure 3 Caracteacuteristiques principales du composant radiofreacutequence utiliseacute
Reprenez la deacutefinition du Link Budget et retrouver les 157 dB annonceacute dans cette
documentation
En LoRa plus le code drsquoeacutetalement est grand plus on est capable drsquoeacutemettre dans un milieu bruiteacute La
figure ci-dessous preacutesente les rapports signal sur bruit avec lesquels nous seront capable de reacutealiser
une transmission en fonction des Spreading Factor utiliseacutes
Figure 4 Influence du Spreading Factor sur le SNR acceptable
On remarque que pour un SF8 nous sommes capables drsquoeacutemettre avec un SNR de -10 dB On pourra
transmettre malgreacute le fait que le bruit est 10 fois supeacuterieur au signal
On remarque que pour un SF12 nous sommes capables drsquoeacutemettre avec un SNR de -20 dB On
pourra transmettre malgreacute le fait que le bruit est 100 fois supeacuterieur au signal
| 12
Cependant on remarque aussi que lrsquoutilisation drsquoun Spreading Factor plus eacuteleveacute augmente
consideacuterablement le nombre de symbole eacutemis (2egraveme colonne du tableau) Comme nous le verrons
plus tard cela impactera eacutevidement le temps de transmission
| 13
3 La couche physique LoRa
31 La modulation LoRa Comme nous lrsquoavons expliqueacute plus tocirct la modulation LoRa utilise lrsquoeacutetalement de spectre pour
transmettre ces informations Mais au lieu drsquoutiliser des codes drsquoeacutetalement (CDMA) elle utilise une
meacutethode appeleacutee Chirp Spread Spectrum La finaliteacute est toujours la mecircme Avoir plusieurs
transmissions dans le mecircme canal La conseacutequence sur le spectre est aussi la mecircme cela provoque
un eacutetalement du spectre
311 La forme du symbole (Chirp) Le signal eacutemis par la modulation LoRa est un symbole dont la forme de base est repreacutesenteacutee ci-
dessous Son nom (Chirp) vient du fait que ce symbole est utiliseacute dans la technologie Radar (Chirp
Compressed High Intensity Radar Pulse)
Figure 5 Symbole de la modulation LoRa (source Wikipeacutedia)
La freacutequence de deacutepart est la freacutequence centrale du canal moins la Bande Passante diviseacutee par deux
La freacutequence de fin est la freacutequence centrale plus la Bande Passante diviseacutee par deux
La freacutequence centrale est appeleacutee le canal
La bande passante est la largeur de bande occupeacutee autour du canal
On considegravere une eacutemission sur la freacutequence centrale 868 Mhz avec une Bande Passante
de 125 kHz Donner la freacutequence de deacutebut et la freacutequence de fin du sweep
Freacutequence de deacutebut
Freacutequence de fin
Pour faciliter la repreacutesentation de ce symbole on utilise plutocirct un graphique TempsFreacutequence de
la forme suivante
| 14
Figure 6 Forme du symbole de base (CHIRP)
En LoRa chaque symbole repreacutesente un certain nombre de bits transmis La regravegle est la suivante
Nombre de bits transmis dans un symbole = Spreading Factor
Par exemple si la transmission utilise un Spreading Factor de 10 (SF10) alors un symbole repreacutesente
10 bits
Crsquoest-agrave-dire qursquoagrave lrsquoeacutemission les bits sont regroupeacutes par paquet de SF bits puis chaque paquet est
repreacutesenteacute par un symbole particulier parmi 2119878119865formes de symboles possibles
Sur la figure suivante voici un exemple theacuteorique drsquoune modulation en SF2 agrave 868 Mhz sur une
bande passante de 125 kHz Chaque symbole repreacutesente donc 2 bits
Figure 7 Symboles eacutemis en Modulation LoRa (Cas theacuteorique en SF2)
Exemple
On considegravere la suite binaire suivante 0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Le Spreading Factor utiliseacute est SF10
Nous regroupons donc les bits par paquet de 10 Chaque paquet de 10 bits sera repreacutesenteacute par un
symbole (sweep) particulier Il y a 1024 symboles diffeacuterents pour coder les 1024 combinaisons
binaires possibles (210)
Freacutequence
Temps
868 000 000 Hz
868 062 500 Hz
Un symbole Un symbole
867 937 500 Hz
Temps
868 000 000 Hz
867 937 500 Hz
Symbole 0
Bits laquo 00 raquo
Symbole 1
Bits laquo 01 raquo
Symbole 2
Bits laquo 10 raquo Symbole 3
Bits laquo 11 raquo
12
5 k
Hz
868 062 500 Hz
| 15
Figure 8 Emission des Chirp en LoRa
Avec un outils drsquoanalyse spectrale actif pendant lrsquoeacutemission LoRa drsquoun Device on peut afficher les
successions de symbole qui sont envoyeacutes Cette oscillogramme a eacuteteacute reacutealiseacute agrave lrsquoaide drsquoun SDR
(Software Digital Radio)
Figure 9 Visualisation des Chirps LoRa reacuteellement eacutemis pendant une transmission
312 Dureacutee drsquoeacutemission drsquoun symbole En LoRa la dureacutee drsquoeacutemission de chaque symbole (Chirp) deacutepend du Spreading Factor utiliseacute Plus le
SF est grand et plus le temps drsquoeacutemission sera long Pour une mecircme bande passante le temps
drsquoeacutemission drsquoun symbole en SF8 est deux fois plus long que le temps drsquoeacutemission drsquoun symbole en
SF7 Ainsi de suite jusqursquoagrave SF12
0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Envoi de 1 Chirp Envoi de 1 Chirp Envoi de 1 Chirp
Transmission Transmission Transmission
| 16
Figure 10 Temps drsquoeacutemission drsquoun symbole (Chirp) en fonction du SF
En revanche le temps drsquoeacutemission drsquoun symbole est inversement proportionnel agrave la bande passante
119879119904 =2119878119865
119861119886119899119889119908119894119889119905ℎ Le deacutebit des symboles est donc de
1
119879119878= 119865119904 =
119861119886119899119889119908119894119889119905ℎ
2119878119865 En toute logique plus la
bande passant est eacuteleveacute plus le deacutebit des symboles sera eacuteleveacute Comme chaque symbole comprend
SF bit on retrouve alors le deacutebit binaire
119863119887 = 119878119865119861119886119899119889119908119894119889119905ℎ
2119878119865
Plus le Spreading Factor sera eacuteleveacute plus le deacutebit binaire sera faible
Plus la Bande Passante sera eacuteleveacutee plus le deacutebit binaire sera fort
Exemple Drsquoapregraves la formule du deacutebit binaire trouver le deacutebit pour les deux cas suivants
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
32 Coding Rate Le Coding Rate est un ratio qui augmentera le nombre de bits agrave transmettre afin de reacutealiser de la
deacutetection correction drsquoerreur Dans le cas drsquoun CR = 4 8 il y aura 8 bits transmis reacuteellement agrave
chaque fois que nous souhaitons transmettre 4 bits Dans cette exemple cela provoque une
transmission drsquoun nombre de bit multiplieacute par 2
SF7
Freacutequence
Temps
Freacutequence centrale
Freacutequence haute
Temps drsquoun symbole eacutemit en SF 12
Freacutequence basse
SF8
SF9
SF10
SF11
SF12
Temps drsquoun symbole eacutemit en SF 11
| 17
Figure 11 Influence du Coding Rate sur le nombre de bits ajouteacute
Si on reprend lrsquoexemple preacuteceacutedent avec un CR de 4 5 nous avons une augmentation de 125 du
nombre de bits agrave transmettre Redonner la deacutebit en prenant en compte le CR
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
La documentation du composant RN2483 donne les deacutebits en fonction du Spreading Factor
la Bande Passante et le Coding Rate Veacuterifier la coheacuterence du reacutesultat avec votre calcul
preacuteceacutedent
Figure 12 Deacutebit en fonction des paramegravetres de la transmission LoRa
33 Utilisation du LoRa Calculator Le logiciel laquo LoRa Calculator raquo est un petit exeacutecutable permettant de simuler une transmission LoRa
en fonction des caracteacuteristiques saisies Canal SF CR etchellip Il est teacuteleacutechargeable agrave lrsquoadresse
suivante httpsbitly2TyloAh
| 18
Figure 13 Le logiciel LoRa Calculator
En reprenant lrsquoexemple preacuteceacutedent (SF7 Bande Passante 125 kHz CR 45) veacuterifier les
calculs du laquo Equivalent Bitrate raquo
34 Time On Air La norme LoRaWAN impose qursquoun Device LoRa ne transmette pas plus de 1 du temps Cela est
repreacutesenteacute par un Duty Cycle Par exemple un Duty Cycle de 1 signifie que si jrsquoeacutemet pendant 1 je
ne dois plus eacutemettre pendant 99 quel que soit lrsquouniteacute de temps utiliseacutee
En reprenant les exemples preacuteceacutedents quels sont les deacutebits moyens si on prend en compte
le laquo Time On Air raquo
Cas 1 Pour SF7 et 125 khz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
Dans le logiciel laquo LoRa Calculator raquo (onglet laquo Energy Profile raquo) nous pouvons estimer la
dureacutee de vie drsquoune batterie Nous prenons lrsquoexemple drsquoun releveacute de tempeacuterature dans un
bacirctiment avec les caracteacuteristiques suivantes
| 19
SF CR Bande Passante etc Nous nous placcedilons dans le cas 1 des exemples preacuteceacutedents
Le releveacute de tempeacuterature se fera toutes les 15 mins
La batterie est constitueacute de 3 petites piles bacirctons [ AAA LR03 ] 12V en seacuterie Soit 36 V
1000 mAh
35 Mise en œuvre LoRa en point agrave point Ce test sera reacutealiseacute avec des modules LoRa RN2483 (Microchip) et une carte microcontrocircleur
ARDUINO
Figure 14 Communication LoRa en Point agrave Point
Reacutealiser le cacircblage de votre module RN2483 suivant le tableau suivant
Connecteur Arduino Click Board RN2483
5V 5V
GND GND
11 RX
10 TX
Tableau 4 Cacircblage de lrsquoARDUINO et de la click Board RN2483
351 Utilisation de lrsquoIDE Arduino Lrsquoenvironnement Arduino est tregraves simple Nous allons reacutealiser un programme pour montrer son
fonctionnement
La connexion de la carte est effectueacutee agrave lrsquoaide drsquoun port USB qui eacutemule une liaison seacuterie
RS232 Il faut donc choisir le bon port Arduino IDE gt Outils gt Port
Pour creacuteer un nouveau programme (sketch) Arduino IDE gt Fichier gt Nouveau
Il y a deux parties dans un sketch
Une fonction setup() qui sera exeacutecuteacutee qursquoune seule fois au deacutemarrage
Une fonction loop() qui sera exeacutecuteacutee en boucle
Ecrire le code suivant
Emetteur
Reacutecepteur
UA
RT
UA
RT
| 20
void setup()
Serialbegin(9600)
void loop()
Serialprintln(hello word)
Compiler et Teacuteleacuteverser Croquis gt Teacuteleacuteverser
Voir la sortie sur la liaison seacuterie Outils gt Moniteur Seacuterie gt Choisir la vitesse de
transmission ici 9600 bauds (en bas agrave droite)
352 Validation du fonctionnement Deux binocircmes joueront le rocircle drsquoeacutemetteur tous les autres binocircmes seront en reacutecepteur
Reacutecupeacuterer les programmes dans Moodle dans le dossier laquo RN2483-Arduino-Point2Point raquo
Installer la librairie RN2483 Arduino IDE gt Croquis gt Inclure une bibliothegraveque gt Ajouter la
bibliothegraveque zip
Reacutepartissez les rocircles Emetteurs Reacutecepteurs et reacutecupeacuterer le programme LoraBlinkerRX ou
LoraBlinkerTX en fonction Les 2 binocircmes en eacutemission devront modifier le code du sketch
Arduino pour transmettre des donneacutees speacutecifiques afin de les diffeacuterencier [
loraSerialprintln(radio tx 30) ]
Validez la reacuteception des donneacutees eacutemises par les deux binocircmes qui transmettent des
donneacutees Ces donneacutees reccedilues sont eacutecrite agrave 57600 bauds sur le moniteur seacuterie de lrsquoArduino
353 Mise en valeur du Spreading Factor On srsquoaperccediloit dans la manipulation preacuteceacutedente que les Devices LoRa reccediloivent les donneacutees des deux
eacutemetteurs Nous allons conserver le mecircme canal drsquoeacutemission (8691 Mhz) mais un des deux
eacutemetteurs va modifier son laquo Spreading Factor raquo La salle sera donc seacutepareacutee en deux groupes
1er groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF7
2egraveme groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF8
Validez la reacuteception des donneacutees eacutemises seulement pour le Spreading Factor que vous
utilisez
| 21
4 Le protocole LoRaWAN
Le LoRa est le type de modulation utiliseacute entre deux Devices ou entre un Device et une Gateway
Lorsque nous parlons de lrsquoensemble de la chaine de communication (Device Gateway Serveur) alors
nous parlons de communication LoRaWAN Nous allons voir lrsquoarchitecture drsquoun reacuteseau LoRaWAN
ainsi que les regravegles de ce protocole
41 Structure drsquoun reacuteseau LoRaWAN Nous retrouvons drsquoun cocircteacute le Device LoRa qui transmet une donneacutee Elle est reacuteceptionneacutee agrave lrsquoautre
extreacutemiteacute du reacuteseau par un Utilisateur La structure globale du reacuteseau LoRaWAN peut ecirctre
repreacutesenteacutee par la figure suivante
411 Les Devices LoRa Les Devices LoRa sont des systegravemes eacutelectroniques appartenant au monde de lrsquoIoT Faible
consommation faible taille faible puissance et faible taille
Ils possegravedent une radio LoRa permettant de joindre les Gateways Les Gateways ne sont pas
adresseacutees speacutecifiquement toutes celles preacutesentes dans la zone de couverture reccediloivent les
messages et les traitent
412 Les Gateways LoRa Elles eacutecoutent sur tous les canaux et sur tous les Spreading Factor Lorsqursquoune trame LoRa est reccedilue
elle transmet son contenu sur internet agrave destination du Network Server qui a eacuteteacute configureacute dans la
Gateway au preacutealable
Elle joue donc le rocircle de passerelle entre une modulation LoRa et une communication IP
Devices
LoRa Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
Internet Internet
Figure 15 Structure globale dun reacuteseau LORAWAN
| 22
Chaque Gateway LoRa possegravede un identifiant unique (EUI sur 64 bits)
413 Le Network Server
Le Network Server reccediloit les messages transmis par les Gateways et supprime les doublons
(plusieurs Gateway peuvent avoir reccedilu le mecircme message) Les informations transmises au Network
Server depuis les Devices LoRa sont authentifieacutes gracircce agrave une cleacute AES 128 bits appeleacutee Network
Session Key NwkSKey Nous parlons bien ici drsquoauthentification et non pas de chiffrement comme
nous le verrons plus tard
414 Application Server Il est souvent sur le mecircme support physique que le Network Server Il permet de dissocier les
applications les unes des autres Chaque application enregistre des Devices LoRa qui auront le droit
Devices Gateways Network
Server
Internet
Network Session Key (NwkSKey)
Authentification
Figure 17 Authentification entre le Device LoRa et le Network Server
Internet
UDP IP
Modulation
LoRa
Device LoRa
Gateway
Network Server
LoRaWAN
Modulation
LoRa
Passerelle LoRa Internet
Internet
UDP IP
LoRaWAN
Transmission Radio
Application Application
Figure 16 Le rocircle de la Gateway LoRa
| 23
de stocker leurs donneacutees (Frame Payload) Les message transmis agrave lrsquoapplication server sont chiffreacutes
gracircce agrave une cleacute AES 128 bits appeleacutee Application Session Key AppSKey
Le scheacutema suivant reacutesume lrsquoutilisation
De la Network Session Key (NwkSKey) pour lrsquoauthentification entre le Device LoRa et le
Network Server
De lrsquoApplication Session Key (AppSKey) pour le chiffrement entre le Device LoRa et
lrsquoApplication Server
Devices Gateways Network
Server Application
Server
Internet
Application Session Key (AppSKey)
Chiffrement
Figure 18 Chiffrement entre le Device LORA et lrsquoApplication Server
| 24
415 Application Web Serveur Cette application doit drsquoune part reacutecupeacuterer les donneacutees de lrsquoApplication Serveur Dans le cadre de
ce cours cela sera fait de deux faccedilons
Avec le protocole HTTP
Avec le protocole MQTT
Figure 20 Application Web Server
Figure 19 Authentification et chiffrement en LoRaWan
Devices Gateways
Network
Server Application
Server
Internet
Network Session Key
Application Session Key
Network
Server Application
Server
Application
Server Web
Utilisateur
Protocole
MQTT ou HTTP
Flux Uplink
Flux Downlink
| 25
Le flux habituel dans lrsquoIoT est le flux Uplink (flux montant) crsquoest-agrave-dire lrsquoeacutemission de donneacutees des
objets vers le serveur Comme nous lrsquoexpliquerons plus loin en LoRaWAN il est aussi possible de
transfeacuterer des donneacutees aux Device LoRa par un flux Downlink (flux descendant)
Drsquoautre part lrsquoapplication mettra agrave disposition les donneacutees aux utilisateurs sous forme par exemple
drsquoun serveur web drsquoune base de donneacutees et drsquoune visualisation graphique
416 Authentification avec le Network Server La Network Session Key (NwkSKey) sert agrave lrsquoauthentification entre le Device LoRa e le Network Server
Afin de reacutealiser cette authentification entre le Device et le Network Server un champ MIC (Message
Integrity Control) est rajouteacute agrave la trame Il est calculeacute en fonction des donneacutees transmises et du
NwkSkey A la reacuteception le mecircme calcul est effectueacute Si les cleacutes sont eacutequivalentes dans le Device et
dans le Network Server alors les deux MIC calculeacutes doivent correspondre
417 Chiffrement des donneacutees vers lrsquoApplication Server
LrsquoApplication Session Key (AppSKey) sert pour le chiffrement entre le Device LoRa et lrsquoApplication
Server Les donneacutees chiffreacutees seront alors deacutecodeacutees agrave la reacuteception sur lrsquoApplication Server srsquoil
possegravede la mecircme cleacute Si on reprend le scheacutema preacuteceacutedent les laquo donneacutees x raquo sont chiffreacutees
deacutechiffreacutees par le processus suivant
Donneacutees x chiffreacutees NwkSkey x
MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees
NwkSkey x
Trame eacutemise Trame reccedilue
Device LoRa Network Server
Si =
Alors la trame est authentifieacutee
MIC geacuteneacutereacute Emission MIC geacuteneacutereacute Reacuteception
MIC geacuteneacutereacute Reacuteception
Figure 21 Authentification dun Device LoRa par le Network Server
| 26
Figure 22 Chiffrement des donneacutees par lApplication Session Key
418 Combinaison de lrsquoauthentification et du chiffrement On peut maintenant repreacutesenter sur le mecircme scheacutema la construction de la trame LoRaWAN avec
drsquoune part lrsquoauthentification et drsquoautre part le chiffrement
Figure 23 Chiffrement puis Authentification
42 Classes des Devices LoRaWAN Les Devices LoRa sont classeacutes en 3 cateacutegories (A B C) en fonction de leur consommation et de leur
accessibiliteacute en Downlink crsquoest-agrave-dire la faciliteacute qursquoun utilisateur aura agrave transmettre une trame au
Device LoRa
421 Classe A (All) Minimal power Application Tous les Devices LoRaWAN sont de classe A Chaque Device peut transmettre (Uplink) agrave la Gateway
sans veacuterification de la disponibiliteacute du reacutecepteur Si la transmission eacutechoue elle sera reacuteeacutemise apregraves
un certain temps Cette transmission est suivie de 2 fenecirctres de reacuteception tregraves courtes La Gateway
peut alors transmettre pendant le laquo RX Slot 1 raquo ou le laquo RX Slot 2 raquo mais pas les deux
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Device LoRa
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Application Server
Donneacutees non chiffreacutees
AppSKey
Donneacutees chiffreacutees Entecircte
NwkSKey
MIC geacuteneacutereacute en eacutemission Trame transmise =
| 27
Figure 24 Slots de reacuteception pour un Device LoRa de classe A
Source de lrsquoimage httpszakelijkforumkpncom
La dureacutee des fenecirctres doit ecirctre au minimum la dureacutee de reacuteception drsquoun preacuteambule Un preacuteambule
dure 1225 Tsymbole et deacutepend donc du Data Rate (DR voir paragraphe 445 pour plus drsquoinformation
sur le DR) Lorsque qursquoun preacuteambule est deacutetecteacute le reacutecepteur doit rester actif jusqursquoagrave la fin de la
transmission Si la trame reccedilue pendant la premiegravere fenecirctre de reacuteception eacutetait bien agrave destination du
Device LoRa alors la deuxiegraveme fenecirctre nrsquoest pas ouverte
Premiegravere fenecirctre de reacuteception
Le Slot RX1 est programmeacute par deacutefaut agrave 1 seconde + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont les mecircme que ceux choisis lors de la phase drsquoeacutemission
(Uplink)
Seconde fenecirctre de reacuteception
Le Slot RX2 est programmeacute par deacutefaut agrave 2 secondes + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont configurables mais fixes
Un Device LoRa qui est uniquement de classe A ne peut pas recevoir srsquoil nrsquoa pas eacutemis Il
nrsquoest donc pas joignable facilement
422 Classe B (Beacon) Scheduled Receive Slot Les Devices de classe B ont le mecircme comportement que les Devices de classe A mais drsquoautres
fenecirctres de reacuteceptions sont programmeacutees agrave des peacuteriodes preacutecises Afin de synchroniser les fenecirctres
de reacuteception du Device LoRa la Gateway doit transmettre des balises (Beacons) de faccedilon reacuteguliegravere
| 28
Figure 25 Slots de reacuteception pour un Device LoRa de classe B
Source de lrsquoimage httpszakelijkforumkpncom
Un Device LoRa de classe B est joignable reacuteguliegraverement sans qursquoil soit neacutecessairement
obligeacute drsquoeacutemettre En revanche il consomme plus qursquoun Device de classe A
423 Classe C (Continuous) Continuously Listening Les Devices de classe C ont des fenecirctres de reacuteception constamment ouvertes entre 2 Uplinks Ces
Devices consomment donc beaucoup plus
Figure 26 Slots de reacuteception pour un Device LoRa de classe C
Source de lrsquoimage httpszakelijkforumkpncom
| 29
Un Device LoRa de classe C est joignable en permanence En revanche crsquoest la classe de
Device qui est la plus eacutenergivore
424 Quelle Gateway pour les flux Downlink
Nous avons donc vu que le fonctionnement classique du protocole LoRaWAN eacutetait de reacutecupeacuterer de
lrsquoinformation depuis le Device LoRa Crsquoest le flux Uplink
Dans le cas ougrave lrsquoutilisateur transmet des informations au Device LoRa (flux Downlink) on peut se
demander quelle Gateway sera choisie pour transfeacuterer les donneacutees au Device LoRa En effet
lrsquoendroit ougrave est situeacute le Device LoRa nrsquoest pas neacutecessairement connu agrave lrsquoavance
La Gateway utiliseacutee pour le Downlink est celle qui a reccedilu le dernier message du Device
LoRa Un message ne pourra jamais arriver agrave destination drsquoun Device LoRa si celui-ci nrsquoa
jamais transmis quel que soit sa classe A B ou C
43 Activation des Devices LoRa et seacutecuriteacute En LoRaWAN les trois eacuteleacutements indispensables pour la communication sont le DevAddr pour
lrsquoindentification du Device ainsi que deux cleacutes le NwkSKey pour lrsquoauthentification et lrsquoAppSKey
pour le chiffrement Deux meacutethodes sont possibles pour fournir ces informations agrave la fois au Device
LoRa et au serveur
Activation By Personalization APB
Over The Air Activation
431 ABP Activation By Personalization Crsquoest la plus simple des meacutethodes Crsquoest donc peut ecirctre celle que nous avons tendance agrave utiliser lors
drsquoun test de prototype et drsquoune mise en place de communication LoRaWAN
Le Device LoRa possegravede deacutejagrave le DevAddr lrsquoAppSKey et le NwkSKey
Le Network server possegravede deacutejagrave le DevAddr et le NwkSKey
Lrsquoapplication serveur possegravede deacutejagrave le DevAddr et le AppSKey
En ABP toutes les informations neacutecessaires agrave la communication sont deacutejagrave connues par le
Device LoRa et par le Serveur
| 30
432 OTAA Over The Air Activation Crsquoest la meacutethode qursquoil faut privileacutegier car crsquoest celle qui est la plus seacutecuriseacutee Le Device LoRa doit
connaitre le DevEUI lrsquoAppEUI et lrsquoAppkey Le Network Server doit lui connaitre la mecircme Appkey
Tous les eacuteleacutements noteacutes EUI (Extended Unique Identifier) sont toujours sur une taille de
64 bits
Gracircce agrave ces informations de deacutepart et une neacutegociation avec le Network Server (Join Request) le
Device LoRa et le serveur vont geacuteneacuterer les informations essentielles DevAddr NwkSKey et
AppSKey
Figure 28 Obtention du DevAddr NwkSKey et AppSKey en OTAA
DevEUI Unique Identifier pour le device LoRa (Equivalent agrave une MAC sur Ethernet)
Certains Device LoRa ont deacutejagrave un DevEUI fourni en usine
AppEUI Unique Identifier pour lrsquoapplication server
DevEUI
AppEUI
AppKey
Join
Request
DevAddr
NwkSKey
AppSKey
Network Server
Application Server
Devices 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 2
NwkSkey 2
AppSKey 2
Devices 2
DevAddr 2
NwkSkey 2
AppSKey 2
Paramegravetres stockeacutes sur le serveur
Paramegravetres programmeacutes
dans le composant
Figure 27 Parameacutetrage de DevAddr NwkSKey et AppSKey
| 31
AppKey AES 128 cleacute utiliseacutee pour geacuteneacuterer le MIC (Message Code Integrity) lors de la Join
Resquest Il est partageacute avec le Network server
NwkSKey Utiliseacute pour lrsquoauthentification avec le Network Server
AppSKey Utiliseacute pour le chiffrement des donneacutees
433 Seacutecuriteacute Les cleacutes AES 128 bits permettent le chiffrement des informations transmises en LoRaWAN Malgreacute
ce chiffrement une attaque connue en Wireless est celle du REPLAY Crsquoest-agrave-dire que le Hacker
enregistre des trames chiffreacutees circulant sur le reacuteseau LoRa pour les reacuteeacutemettre plus tard Mecircme si
le Hacker ne comprend pas le contenu (les trames sont chiffreacutees) les donneacutees qui sont transporteacutees
sont elles bien comprises par lrsquoApplication Server Des actions peuvent donc ecirctre reacutealiseacutees
simplement par mimeacutetisme
Pour eacuteviter cela la trame LoRaWAN integravegre un champ variable appeleacute laquo Frame Counter raquo Il srsquoagit
drsquoun nombre numeacuterotant la trame sur 16 ou 32 bits LrsquoApplication Server acceptera une trame
uniquement si le laquo Frame Counter raquo reccedilu est supeacuterieur au laquoFrame Counter raquo preacuteceacutedemment Donc
si le Hacker retransmet la trame telle qursquoelle le laquo Frame Counter raquo sera eacutequivalent donc la trame
sera refuseacutee Et comme la trame est chiffreacutee le Hacker nrsquoa pas moyen de savoir comment modifier
un champ de cette trame
Cette seacutecuriteacute impleacutementeacutee par les laquo Frame Counter raquo est inteacuteressante pour srsquoaffranchir drsquoune
attaque par REPLAY mais dans nos tests cela peut poser problegraveme En effet agrave chaque fois que nous
redeacutemarrons le microcontrocircleur notre laquo Frame Counter raquo revient agrave zeacutero alors que celui de
lrsquoApplication Server continue de srsquoincreacutementer Cela peut ecirctre reacutesolue par diffeacuterentes maniegraveres
1 Deacutesactivation du laquo Frame Counter Check raquo Dans certain Application Server cette option
peut ecirctre proposeacutee Bien sucircr il faudra garder en tecircte la faille de seacutecuriteacute que cela engendre
Network Server
Application Server
Devices LoRa
NwkSkey
AppSKey
NwkSkey
AppSKey Hacker
(1) (2)
(1) Ecoute
(2) Reacuteeacutemission
Figure 29 Attaque par REPLAY
| 32
Figure 30 Deacutesactivation du Frame Counter Check dans TTN
2 Utiliser lrsquoauthentification par OTAA au lieu de ABP En effet agrave chaque ouverture de session
en OTAA le laquo Frame Counter raquo est reacuteinitialiseacute coteacute serveur
3 Conserver la valeur du laquo Frame Counter raquo dans une meacutemoire non volatile et reacutecupeacuterer sa
valeur au deacutemarrage du Device LoRa
44 La Trame LoRa LoRaWAN
441 Les couches du protocole LoRaWAN
Lorsque nous avons fait une communication en Point agrave Point nous avons simplement utiliseacute la
couche physique de la modulation LoRa Lorsque nous souhaitons utiliser le protocole LoRaWAN
des couches protocolaires suppleacutementaires se rajoutent
Figure 31 Les couches protocolaires du LoRaWAN
Chaque couche rajoute un service Lors de lrsquoenvoi de la trame les donneacutees utilisateurs sont donc
encapsuleacutees dans chaque couche infeacuterieure jusqursquoagrave la transmission Le deacutetail de lrsquoensemble de la
trame LoRaWAN par couche est deacutecrit sur la figure Figure 32
LoRa Modulation
LoRa Mac
Application
Couche Physique
Couche Mac
Couche Application
| 33
442 Couche Application La couche Application accueille les donneacutees de lrsquoutilisateur Avant de les encapsuler elles sont
chiffreacutees avec lrsquoAppSKey afin de seacutecuriser la transaction
Un ensemble de champs nommeacute Frame Header permet de speacutecifier le DevAddr le Frame Control
le Frame Counter et le Frame Option
Le Frame Port deacutepend du type drsquoapplication et sera choisi par lrsquoutilisateur
Le Frame Payload sont les donneacutees chiffreacutees agrave transmettre Le nombre drsquooctets maximum pouvant
ecirctre transmis (N octets) est donneacute dans le tableau suivant
PHY Payload
P octets Couche
Physique
Couche
Mac
Couche
Application
CRC
2 octets Header + Header CRC
20 bits Preamble
MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Figure 32 Trame LORAWAN complegravete par couche protocolaire
Couche
Application Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Frame Header
Figure 33 Trame LORA couche Applicative
| 34
Data Rate Spreading Factor Bandwidth Max Frame Payload (Nombre N) DR 0 SF12 125 KHz 51 octets
DR 1 SF11 125 KHz 51 octets
DR 2 SF10 125 KHz 51 octets
DR 3 SF9 125 KHz 115 octets
DR 4 SF8 125 KHz 222 octets
DR 5 SF7 125 KHz 222 octets
DR 6 SF7 250 KHz 222 octets
Tableau 5 Taille maximum du Frame Payload en fonction du Data Rate
443 Couche LoRa MAC Cette trame est destineacutee au Network Server Elle est authentifieacutee gracircce au champ MIC (Message
Integrity Protocol) selon la meacutethode expliqueacutee au paragraphe 416
Le protocole LoRa MAC est composeacute de
1 MAC Header Version de protocole et type de message
Type de Message Description 000 Join-Request
001 Join-Accept
010 Unconfirmed Data Up
011 Unconfirmed Data Down
100 Confirmed Data Up
101 Confirmed Data Down
110 Rejoin-request
111 Proprietary
Tableau 6 Les types de messages transmis en LoRaWAN
2 MAC Payload Contient tout le protocole applicatif
3 MIC Message Integrity Code pour lrsquoauthentification de la trame
444 Couche physique Modulation LoRa
Le choix du moment drsquoeacutemission des Devices LoRa se fait de faccedilon simple Lorsqursquoun eacutequipement
doit eacutemettre il le fait sans controcircle et ne cherche pas agrave savoir si le canal est libre Si le paquet a eacuteteacute
perdu il le retransmettra simplement au bout drsquoun temps aleacuteatoire La couche physique est
repreacutesenteacutee par lrsquoeacutemission de la trame suivante
Couche
Mac MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Figure 34 Trame LORA couche LORA MAC
| 35
Le Preacuteambule est repreacutesenteacute par 8 symboles + 425 Le temps du Preacuteambule est donc de 1225
Tsymbole
Len-tecircte (Header optionnel) est seulement preacutesent dans le mode de transmission par deacutefaut
(explicite) il est transmis avec un Coding Rate de 48 Il indique la taille des donneacutees le Coding Rate
pour le reste de la trame et il preacutecise eacutegalement si un CRC sera preacutesent en fin de trame
Le PHY Payload contient toutes les informations de la Couche LoRa MAC
Le CRC sert agrave la deacutetection drsquoerreur de la trame LoRa
445 Canaux et bandes de freacutequences et Data Rate (DR) Le LoRa utilise des bandes de freacutequences diffeacuterentes suivant les reacutegions du monde En Europe la
bande utiliseacutee est celle des 868 Mhz [ De 863 Mhz agrave 870 Mhz ] Le LoRaWAN deacutefinie les 8 canaux agrave
utiliser pour communiquer avec une Gateway suivant le tableau suivant
Canaux Spreading Factor Bandwidth 8681 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz SF7 250 kHz
8685 Mhz De SF7 agrave SF12 125 kHz
8671 Mhz De SF7 agrave SF12 125 kHz
8673 Mhz De SF7 agrave SF12 125 kHz
8675 Mhz De SF7 agrave SF12 125 kHz
8677 Mhz De SF7 agrave SF12 125 kHz
8679 Mhz De SF7 agrave SF12 125 kHz
Tableau 7 Canaux SF et Bandwidth de notre Gateway LoRaWAN
Une Gateway LoRa eacutecoute donc sur 8 canaux simultaneacutement avec les 6 Spreading Factor
diffeacuterents soit 48 combinaisons possibles
Comme nous lrsquoavons vu le Spreading Factor a des conseacutequences sur le deacutebit de la transmission Ces
deacutebits sont noteacutes DR (Data Rate) et sont normaliseacutes de DR0 agrave DR6
PHY Payload
P octets Couche
Physique CRC
2 octets Header + Header CRC
( Optionnel ) 20 bits Preamble
Figure 35 Trame LORA couche Physique
| 36
Data Rate Spreading Factor Bandwidth DR 0 SF12 125 KHz
DR 1 SF11 125 KHz
DR 2 SF10 125 KHz
DR 3 SF9 125 KHz
DR 4 SF8 125 KHz
DR 5 SF7 125 KHz
DR 6 SF7 250 KHz
Tableau 8 Deacutenomination DR en fonction du SF et de la Bande Passante
446 Trame reccedilue et transmise par la Gateway LoRaWAN La Gateway reccediloit drsquoun cocircteacute un message radio moduleacute en LoRa et transmet de lrsquoautre cocircteacute une trame
IP agrave destination du Network Server
Coteacute interface Radio La Gateway reacuteceptionne une trame LoRaWAN et extrait le PHY Payload Celui-
ci est codeacute au format ASCII en base 64 (voir le paragraphe 541) La Gateway extrait aussi toutes les
informations utiles sur les caracteacuteristiques de la reacuteception qui a eu lieu SF Bandwidth RSSI Time
On Airhellipetchellip
Coteacute interface reacuteseau IP La Gateway transmet lrsquoensemble de ces informations dans un paquet IP
(UDP) au Network Server Les donneacutees transmises sont du texte en format JSON (voir paragraphe
447) La Gateway a donc bien un rocircle de passerelle entre le protocole LoRa drsquoun cocircteacute et un reacuteseau
IP de lrsquoautre
Internet
UDP IP
Device LoRa
Gateway
Network Server Modulation
LoRa
Passerelle LoRa Internet
Transmission Radio Internet
Figure 36 Rocircle de la Gateway LoRa
| 37
447 Le format JSON Le format JSON est un format texte composeacute drsquoune succession de couple nomvaleur Dans
lrsquoexemple de la figure preacuteceacutedente gw_id est un nom et eui-b827ebfffeae26f5 est la valeur
associeacutee Dans cette exemple la valeur est un string Les objets sont deacutelimiteacutes par un des accolades
et
Une valeur peut ecirctre
Un string exemple coding_rate 45
Un nombre exemple spreading_factor 12
Un objet exemple lora spreading_factor 12 air_time 2465792000
Un Boolean
Ethernet
Gateway
Modulation
LORA
Reacutecupeacuteration du PHY PAYLOAD en base 64
Reacutecupeacuteration des caracteacuteristiques de la transmission Canal SF CR hellip
IP (IP dest routereuthethingsnetwork)
UDP (Port dest 1700 Port source 1700)
Donneacutees applicatives (format JSON)
gw_id eui-b827ebfffeae26f5
payload QNAPvA6Ax3ECqHk4C8hfzuA==
lora
spreading_factor 12
bandwidth 125
air_time 2465792000
coding_rate 45
timestamp 2019-01-20T133746017Z
rssi -105
snr -162
dev_addr 0EBC0FD0
frequency 867100000
Internet Transmission Radio LORA
Figure 37 Passerelle (Gateway) LORAWAN
| 38
5 Mise en œuvre drsquoun reacuteseau LoRaWAN
51 Les diffeacuterents types de reacuteseaux Les reacuteseaux LoRaWAN peuvent ecirctre utiliseacute suivant deux meacutethodes
En utilisant les reacuteseaux LoRaWAN opeacutereacutes proposeacutes par les opeacuterateurs de teacuteleacutecoms
En utilisant votre propre reacuteseau LoRaWAN priveacute
511 Les reacuteseaux LoRaWAN opeacutereacutes Ce sont des reacuteseaux LoRaWAN proposeacutes par les opeacuterateurs Par exemple Objenious (filiale de
Bouyges) ou encore Orange Dans le cas de lrsquoutilisation des reacuteseaux opeacutereacutes lrsquoutilisateur a juste
besoin de srsquooccuper des Devices LoRa Les Gateways le Network Server et lrsquoApplication Server sont
geacutereacutes par lrsquoopeacuterateur
512 Les reacuteseaux LoRaWAN priveacutes Chacun est libre de reacutealiser son propre reacuteseau priveacute en impleacutementant sa propre Gateway pour
communiquer avec ses Devices LoRa Lrsquoimpleacutementation du Network Server et de lrsquoApplication Server
peuvent alors ecirctre envisageacutes de diffeacuterentes faccedilons
Network Server et Application serveur priveacutees Crsquoest le deacuteveloppeur qui les mets en place Dans
certaines Gateways une impleacutementation de ces deux serveurs est deacutejagrave proposeacutee Sinon il est
possible de la mettre en place Il existe des serveurs (Network et Application) open source crsquoest le
cas par exemple de LoRa Serveur [ wwwloraserverio ]
Une autre alternantive est httpsgithubcomgotthardplorawan-server
LoRaServer et lorawan-server sont deux applications Open Source
Network Server et Application Server en ligne Un certain nombre de Network Server et
drsquoApplication Server sont proposeacutes Ce sont des services payants ou avec des contreparties
Loriot [ wwwloriotio ]
ResIoT [ wwwresiotio ]
The Things Network [ wwwthethingsnetworkorg ] Crsquoest la solution que nous utiliserons
513 Les zones de couvertures
Les zones de couvertures des reacuteseaux opeacutereacutes sont mise agrave jour par les opeacuterateurs celle drsquoobjenious
est par exemple disponible ici httpsobjeniouscomreseau
Pour connaitre la zone de couverture de notre Gateway utiliseacutee avec TTN nous pouvons utiliser
lrsquoapplication TTN Mapper httpsttnmapperorg Lrsquoideacutee est de promener son Device LoRa associeacute
agrave un GPS dans la zone de couverture des Gateway qui nous entourent A chaque trame reccedilue par le
| 39
Serveur on note les coordonneacutees GPS du Device LoRa ainsi que la Gateway qui a transmis le
message Toutes ces informations sont alors retranscrites sur une carte
52 The Things Network (TTN)
521 Preacutesentation de TTN
Pour la suite nous utiliserons le Network Server et lrsquoApplication Server fourni par TTN
[wwwthethingsnetworkorg]
TTN est gratuit et Open Source En revanche le fait drsquoutiliser TTN impose agrave ceux qui enregistrent
des Gateways de les mettre agrave disposition agrave tous les autres utilisateurs de TTN Lrsquoobjectif est de
reacutealiser un reacuteseau global ouvert
522 Configuration de la Gateway A lrsquouniversiteacute nous avons deux Gateways LoRa (Marque EBDS) Elles sont toutes les deux situeacutees sur
le Campus de Technolac Une Gateway est agrave lrsquointeacuterieur du bacirctiment ISERAN et sert essentiellement
pour les Travaux Pratiques et formations Lrsquoautre est sur le toit du bacirctiment Chablais et est mise agrave
disposition du public via le service de TTN
Les deux Gateway eacutecoutent sur tous les canaux et sur tous les Spreading Factor SF7 gt SF12
Lrsquo IP de la Gateway LoRa agrave lrsquouniversiteacute (bacirctiment ISERAN) est 192168140196
Serveur DNS 1934812032 19348129137
Network Server (TTN) 137616868 routereuthethingsnetwork
Port Upstream 1700 Port Downstream 1700
523 Enregistrement des Gateways Appplication et Devices La configuration de TTN se fait en ligne La premiegravere opeacuteration agrave reacutealiser lorsqursquoune nouvelle
Gateway est deacuteployeacutee crsquoest de lrsquoenregistrer dans TTN
Enregistrement drsquoune Gateway LoRa TTN gt Console gt Gateway gt register gateway
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Figure 38 Scheacutema de notre application
| 40
Figure 39 Enregistrement dune Gateway LoRa sur TTN
Enregistrement drsquoune application TTN gt Console gt Application gt add application
Figure 40 Enregistrement dune application sur TTN
Enregistrement des Devices LoRa dans lrsquoapplication Nom de lrsquoapplication gt register device
Figure 41 Enregistrement des Devices LoRa dans une application
524 Configuration des Devices LoRa Lorsque nous avons enregistreacute des Devices LoRa dans TTN nous devons choisir entre les deux modes
drsquoauthentification Dans un premier temps nous utiliserons le mode le plus simple qui est ABP Nous
geacuteneacuterons dans TTN les DevAddr NetwkSKey et AppSKey
| 41
Figure 42 Configuration des Devices LoRa en ABP dans TTN
53 Mise en application Nous avons dans notre application 10 Devices LoRa drsquoenregistreacutes aduino0 agrave arduino9 Ils sont tous
configureacutes en ABP Les configurations des 10 Devices (DevAddr NetwkSKey et AppSKey) sont noteacutes
en commentaire dans le code de vous allez reacutecupeacuterer
Reacutecupeacuterer le code Arduino laquo RN2483-Arduino-LORAWANino raquo dans Moodle
Modifier votre configuration (DevAddr NetwkSKey et AppSKey) en fonction de votre
numeacutero de binocircme
Veacuterifier que votre Device LoRa arrive bien agrave transmettre des informations (Uplink) vers la
Gateway puis vers le Network Serveur de TTN (The Things Network)
54 Analyse des trames eacutechangeacutees
541 Utilisation de la base 64 Notre Gateway nous preacutesente le Payload PHY en base64 Lrsquoexplication de la meacutethode de
repreacutesentation en base 64 est fourni au travers drsquoun exemple Le code hexadeacutecimal 0x4869
repreacutesente nos donneacutees binaires que nous souhaitons transmettre en base 64
1 On eacutecrit les donneacutees agrave transmettre en binaire
2 On regroupe les eacuteleacutements binaires par des blocs de 6 bits Le nombre de bloc de 6 bits doit
ecirctre un multiple de 4 (minimum 4 blocs) Srsquoil manque des bits pour constituer un groupe de
6 bits on rajoute des zeacuteros
0x4869 = 0100 1000 0110 1001
| 42
3 Srsquoil manque des blocs pour faire un minimum de 4 blocs des caractegraveres speacuteciaux seront
ajouteacutes
4 Chaque groupe de 6 bits est traduit par le tableau suivant (Source Wikipeacutedia)
Figure 43 Codage en base 64
5 Si un bloc de 6 bits manque (ils doivent ecirctre un multiple de 4) on rajoute un ou plusieurs
compleacutements (caractegravere laquo = raquo )
Reacutesultat Le codage de 0x4869 en base 64 est laquo SGk= raquo
010010 000110 100100
On ajoute 00 pour avoir
6 bits dans le groupe
Bloc de 6 bits
010010 000110 100100
S G k
010010 000110 100100
S G k =
1er Bloc
2egraveme Bloc
3egraveme Bloc
4egraveme Bloc
| 43
542 Inteacuterecirct et inconveacutenient de la base 64 Lrsquoutilisation de la base 64 est un choix qui a eacuteteacute fait pour le protocole LoRa LoRaWAN afin de rendre
les donneacutees binaires lisibles Le problegraveme du code ASCII crsquoest qursquoil est composeacute drsquoun certain nombre
de caractegraveres non imprimables (EOF CR LFhellip) Pour eacuteviter ces soucis la base 64 ne comporte que
64 caractegraveres imprimables (voir tableau ci-dessus)
La restriction agrave 64 caractegraveres a cependant un inconveacutenient crsquoest que nous ne pouvons coder que 6
bits (26=64) au lieu de 8 La base 64 est donc moins efficace drsquoune faccedilon geacuteneacuterale
Nous cherchons agrave coder le code ASCII laquo AA raquo en base 64 Retrouver la deacutemarche en
montrant que le reacutesultat en base 64 est laquo QUE= raquo
543 Uplink Du Device LoRa au Network Server Le Network Server de TTN reccediloit des trames IP en provenance de la Gateway Comme nous lrsquoavons
vu preacuteceacutedemment un certain nombre drsquoinformations peuvent ecirctre retrouveacutees avec cette trame
(DevAddr SF Bandwidth etchellip) mais les donneacutees Applicatives sont bien sucircr chiffreacutees (avec
lrsquoAppkSKey) A ce niveau de reacuteception (sans connaitre lrsquoAppSKey) il nrsquoest donc pas possible de
comprendre la totaliteacute du message reccedilu
Imaginons que la trame IP reccedilue 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 45
timestamp 2019-03-05T140042448Z
rssi -82
snr 9
dev_addr 26011AD3
frequency 867300000
Le Network Server affiche donc les informations de la faccedilon suivante
Figure 44 Trame reacutecupeacutereacutee sur le laquo Network Server raquo de TTN
Nous retrouvons bien les valeurs fournies par la Gateway
timestamp ( agrave 1 heure pregraves en fonction du fuseau horaire)
| 44
frequency 8673 Mhz
modulation Lora
Coding Rate 45
data Rate SF 7 125 kHz (DR5)
air time 463 ms
Drsquoautres information proviennent de lrsquoanalyse du Payload Le Payload inscrit ici est le PHY Payload
Il y a donc une partie chiffreacutee (Frame Payload) mais les entecirctes sont en claires (voir paragraphe
441) Ce PHY Payload est laquo QNMaASYABwAP1obuUHQ= raquo Lorsque celui-ci est exprimeacute en
hexadeacutecimal au lieu de la base 64 il vaut laquo 40D31A01260007000FD686EE5074 raquo comme le montre
le Network Server de TTN
Figure 45 PHY Payload preacutesenteacute dans notre Network Server
Sa taille est bien de 14 octets (en hexadeacutecimal) comme preacuteciseacute sur la Figure 44
Nous reprenons le format de la trame LoRaWAN vu agrave la Figure 32 Nous pouvons alors retrouver
tous les champs de toute la trame
PHYPayload = 40D31A01260007000FD686EE5074
PHYPayload = MAC Header[1 octet] | MACPayload[] | MIC[4 octets]
MAC Header = 40 (Unconfirmed data up)
MACPayload = D31A01260007000FD6
Message Integrity Code = 86EE5074
MACPayload = Frame Header | Frame Port | FramePayload )
Frame Header = D31A0126000700
FPort = 0F
FramePayload = D6
Frame Header = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[015]
DevAddr = 26011AD3 (Big Endian)
FCtrl (Frame Control) = 00 (No ACK No ADR)
FCnt (Frame Counter) = 0007 (Big Endian)
FOpts (Frame Option) =
Vous pouvez veacuterifier lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN
(LoRaWAN packet decoder) httpsbitly2szdXtv
| 45
Figure 46 LoRaWAN packet decoder
544 Uplink Du Network Server agrave lrsquoApplication Server
Nous reprenons lrsquoexemple de la trame ci-dessus (Figure 45) Pour information les cleacutes NwkSKey et
AppSKey suivantes ont eacuteteacute utiliseacutee
NwkSKey E3D90AFBC36AD479552EFEA2CDA937B9
AppSKey F0BC25E9E554B9646F208E1A8E3C7B24
Le Network Server a deacutecodeacute lrsquoensemble de la trame Si le MIC est correct (authentification de la
trame par le NwkSKey) alors le Network Server va passer le contenu du message chiffreacute (Frame
Payload) agrave lrsquoApplication Server Dans notre cas le Frame Payload est (drsquoapregraves le deacutecodage effectueacute
au chapitre preacuteceacutedent)
FramePayload = D6
D6 est le contenu chiffreacute lorsqursquoil est deacutechiffreacute avec lrsquoAppSkey on trouve 01 Vous pouvez veacuterifier
lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN httpsbitly2szdXtv
A noter que lrsquoApplication Server recevra les donneacutees chiffreacutees seulement si le Device LoRa a bien
eacuteteacute enregistreacute On peut aussi veacuterifier ci-dessous que lrsquoApplication Serveur de TTN nous retourne bien
un payload (Frame Payload) de 01
Figure 47 Trame reacutecupeacutereacutee sur lrsquoApplication Server de TTN
time 2019-03-05T140042379279991Z
frequency 8673
modulation LORA
data_rate SF7BW125
coding_rate 45
gateways [
gtw_id eui-b827ebfffeae26f6
timestamp 2447508531
time
channel 4
rssi -82
snr 9
latitude 4563647
longitude 58721523
| 46
location_source registry
]
545 Simulation drsquoUplink dans lrsquoApplication Server
Dans beaucoup de situations nous souhaitons valider le fonctionnement de lrsquoApplication Server de
TTN ouet de notre propre Application Il est donc tregraves utile de pouvoir simuler lrsquoenvoi drsquoune trame
LoRa sur lrsquoApplication Server sans que celle-ci soit reacuteellement eacutemise par un Device LoRa Pour cela
un outil existe dans les Settings de chaque Device enregistreacute dans TTN Nous avons juste besoin de
speacutecifier le Frame Payload en clair en hexadeacutecimal et le numeacutero de Port
Figure 48 Simulation drsquoune trame envoyeacutee par un Device LoRa
546 Downlink De lrsquoApplication Server au Device LoRa La communication LoRa est bidirectionnelle Des donneacutees peuvent ecirctre transmis au Device LoRa
depuis lrsquoApplication Server Depuis TTN un outil existe dans les Settings de chaque Device
enregistreacute Lrsquointerface est repreacutesenteacutee ci-dessous
Figure 49 Transmission de donneacutees de lrsquo laquo Application Server raquo jusqursquoau Device LoRa
Replace scheduling Mode Par deacutefaut le Frame Payload transmis remplacera le Frame
Payload en attente (si il existe) Dans ce mode un seul Frame Payload est planifieacute
First scheduling Mode Le Frame Payload est mis en file drsquoattente en premiegravere position
Last scheduling Mode Le Payload est mis en file drsquoattente en derniegravere position
Une demande de confirmation peut ecirctre demandeacutee au Device LoRa pour qursquoil preacutecise srsquoil a bien reccedilu
les donneacutees Lrsquooption laquo confirmed raquo permet donc de speacutecifier le type de trame dans le MAC Header
(voir paragraphe 443) laquo Confirmed Data Down raquo ou laquo Unconfirmed Data Down raquo dans notre cas
| 47
6 La reacutecupeacuteration des donneacutees sur notre propre Application
Nous utiliserons agrave nouveau le Network Server et Application Server de The Things Network Jusqursquoici
nous nous sommes contenteacute de veacuterifier que les donneacutees de lrsquoutilisateur (Frame Payload) soient bien
arriveacutees agrave destination dans lrsquoApplication Server Il faut maintenant les reacutecupeacuterer avec notre propre
Application qui aura pour rocircle
De stocker et traiter les donneacutees
De les mettre agrave disposition de lrsquoutilisateur (Serveur Web par exemple)
Drsquoenvoyer des commandes de lrsquoutilisateur aux Devices LoRa si besoin (Flux Downlink)
Nous allons voir deux meacutethodes pour communiquer entre notre application et TTN
Le protocole HTTP POST
Le protocole MQTT
61 Reacutecupeacuteration des donneacutees en HTTP POST dans lrsquoApplication
611 Preacutesentation du protocole HTTP
Dans le monde de lrsquointernet le protocole HTTP est tregraves utiliseacute pour le dialogue entre un client et un
serveur web Classiquement le client (un navigateur web par exemple) fait une requecircte HTTP GET
et le serveur lui retourne le contenu de la page web demandeacutee
Dans notre cas la probleacutematique est diffeacuterente car le client doit modifier le contenu du serveur
avec les donneacutees envoyeacutees par le Device LORA La requecircte srsquoappelle HTTP POST Son nom indique
que le client va poster (et on pas reacutecupeacuterer) des donneacutees
Lrsquoutilisateur qui souhaite reacuteceptionner des donneacutees sur son serveur doit donc concevoir un serveur
HTTP capable de traiter des requecirctes HTTP POST [ requecircte noteacutee (1) sur la Figure 51 ] fournies par
TTN Dans cette configuration TTN jouera le rocircle de client et notre application le rocircle de serveur
Devices
LORA Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
HTTP POST
MQTT Internet
Figure 50 Structure globale drsquoun reacuteseau LORAWAN
| 48
Figure 51 Communication bidirectionnelle entre TTN et notre Application
A lrsquoinverse lrsquoutilisateur qui souhaite transmettre des donneacutees agrave destination du Device LoRa
(Downlink) doit ecirctre capable de fournir une requecircte HTTP POST [ requecircte noteacutee (2) sur la Figure 51
] vers TTN Dans cette configuration TTN jouera le rocircle de Serveur et notre application le rocircle de
client
612 Fonctionnement drsquoun client et drsquoun serveur HTTP POST Afin de bien comprendre le fonctionnement des requecirctes HTTP POST nous allons proceacuteder par
eacutetape Le premier test que nous effectuerons sera decorreacuteleacute de TTN Le principe est le suivant
Utilisation drsquoun serveur HTTP disponible sur le web geacuterant les requecirctes HTTP POST [
httpsrbasketsin ] ou [ httpsbeeceptorcom ] par exemple
Utilisation drsquoun client HTTP eacutemettant des requecirctes HTTP POST commande curl sous linux
ou logiciel Postman [ wwwgetpostmancom ] sous windows par exemple
Ce test nous permet de valider le fonctionnement drsquoun serveur HTTP POST et drsquoun client HTTP POST
Une fois que nous serons sucircr de leur fonctionnement nous les utiliserons avec TTN
The Things Network
Application
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 49
Figure 52 Validation dun server HTTP POST et drsquoun client HTTP POST
613 Test du serveur HTTP POST Nous utiliserons un serveur web proposeacute par httpsrbasketsin
Aller sur le site httpsrbasketsin et creacuteer un nouveau laquo Basket raquo Zone ougrave vous pourrez
visualiser les requecirctes qui ont eacuteteacute eacutemises vers votre serveur
A partir de maintenant toutes les requecirctes dirigeacutees vers lrsquoadresse creacuteeacute seront traiteacutees et
srsquoafficheront Dans le menu de configuration il est aussi possible de deacutefinir le contenu de la reacuteponse
qui sera fournie
Deacutefinir un format de reacuteponse pour les requecirctes HTTP POST avec un body personnaliseacute
614 Test du client HTTP POST On peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande (la commande cURL
srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN sous Windows
Commande cURL curl ndashX POST ndashd lsquorsquodonneacutees agrave envoyerrsquorsquo DuServeurHTTP
Logiciel Postman New gt Request gt Creacuteer une requecircte HTTP POST gt Send
Veacuterifier que les requecirctes HTTP POST sont bien reacutecupeacutereacutees sur votre serveur creacutee preacuteceacutedemment
615 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST
Maintenant que nous avons un serveur HTTP (POST) fonctionnel nous allons configurer TTN pour
jouer le rocircle du client et pour qursquoil envoie des requecirctes HTTP POST vers notre Serveur degraves qursquoune
donneacutee drsquoun Device LoRa est disponible Nous geacuterons donc ici le flux Uplink
Requecircte
HTTP POST
Reacuteponse
(contenu parameacutetrable)
Client HTTP (POST)
Server HTTP (POST) [ httpsrbasketsin ]
| 50
Figure 53 Reacutecupeacuteration des donneacutees sur notre Application
Dans TTN nous inteacutegrons un bloc appeleacute laquo HTTP Integration raquo permettant de jouer le rocircle de client
crsquoest-agrave-dire drsquoenvoyer des requecirctes HTTP POST agrave destination de notre nouveau Serveur HTTP
Lrsquointeacutegration se faire agrave partir de TTN gt Console gt Application gt Nom_de_votre_application gt
Integration
Figure 54 Ajout dun client HTTP POST dans TTN
Pour valider le fonctionnement de notre architecture nous pouvons soit
Envoyer une trame depuis un Device LoRa vers TTN
Simuler lrsquoenvoi drsquoune trame drsquoun Device LoRa vers TTN (gracircce agrave lrsquooutil proposeacute par TTN vu
paragraphe 545)
Dans les deux cas voici un exemple de requecircte POST reccedilue sur notre serveur HTTP
app_id test_app_lorawan_sylvainmontagny
dev_id stm32lorawan_1
hardware_serial 0056AF49877
port 1
counter 0
payload_raw qg==
metadata
Requecircte
HTTP POST
Server HTTP (POST) [ httpsrbasketsin ]
The Things Network (Client)
La requecircte contient le Frame Payload deacutechiffreacutee
agrave transmettre agrave lrsquoApplication
| 51
time 2019-01-24T15243703499298Z
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Comme nous pouvons le voir le contenu fourni agrave notre serveur est formateacute en JSON (voir
paragraphe 0) Voici quelques compleacutements drsquoinformation
payload_raw Frame Payload deacutechiffreacute crsquoest donc les donneacutees en clairs dans la base 64
downlink_url URL du serveur HTTP POST qui serviront agrave transmettre des donneacutees au Device
LoRa (flux Downlink)
611 Envoyer des donneacutees depuis notre Application avec HTTP POST
Lorsque nous avons ajouteacute le bloc laquo HTTP Integration raquo au paragraphe preacuteceacutedent nous avons aussi
implicitement activeacute la fonctionnaliteacute que TTN soit precirct agrave recevoir et agrave traiter les requecirctes HTTP
POST La seule information qursquoil nous manque est lrsquoadresse du server HTTP vers lequel il faut eacutemettre
les requecirctes Si on observe la trame reccedilue preacuteceacutedemment en provenance de TTN on srsquoaperccediloit que
dans la trame JSON reccedilu une URL (downlink_url) est speacutecifieacutee
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Crsquoest cette URL que nous devrons utiliser Nous allons nous placer dans la configuration suivante
Figure 55 Envoi de donneacutees agrave partir de notre Application
Comme preacuteceacutedemment on peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande
(la commande cURL srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN
Commande cURL curl ndashX POST ndashdata lsquo dev_id Identidiant_De_Votre_Device
payload_raw AQE= rsquo DuServeurHTTP
Logiciel Postman New gt Request gt HTTP POST puis Body gt Raw gt JSON
Requecircte HTTP POST vers serveur TTN laquo downlink_url raquo httpsintegrationsthethingsnetworUaeb8ypKieQ
Contenu de la requecircte
dev_id Identidiant_De_Votre_Device
payload_raw aGVsbG8=
The Things Network (Serveur)
POSTMAN (Client HTTP POST)
| 52
dev_id YourDeviceID
payload_raw aGVsbG8=
Vous devez envoyer le texte (payload_raw) en base 64 Dans lrsquoexemple ci-dessus laquo aGVsbG8= raquo
correspond agrave la chaine de caractegravere laquo hello raquo Vous pouvez utiliser les nombreux encodeurdecodeur
en ligne pour vous aider Le texte doit srsquoafficher sur votre moniteur seacuterie Arduino dans le cadre de
notre deacutemonstrateur sur Arduino
62 Reacutecupeacuteration des donneacutees avec MQTT dans lrsquoApplication
621 Preacutesentation du protocole MQTT
MQTT est un protocole leacuteger qui permet de srsquoabonner agrave des flux de donneacutees Plutocirct que
lrsquoarchitecture Client Serveur classique qui fonctionne avec des Requecirctes Reacuteponses MQTT est
baseacute sur un modegravele Publisher Subscriber La diffeacuterence est importante car cela eacutevite davoir agrave
demander (Requecircte) des donneacutees dont on na aucune ideacutee du moment ougrave elles vont arriver Une
donneacutee sera donc directement transmise au Subscriber degraves lors que celle-ci a eacuteteacute reccedilue dans le
Broker (serveur central)
Figure 56 Modegravele Publisher Subscriber du protocole MQTT
Pour recevoir les donneacutees appartenant agrave un Topic un Subscriber doit souscrire (comme son nom
lindique) au preacutealable sur ce Topic
MQTT est un protocole qui repose sur TCP Lencapsulation des trames sur le reacuteseau est donc la
suivante
Broker
Client
Publisher 1
Client
Publisher 2
Client
Subscriber
Topic
Tempeacuterature
Topic
Humiditeacute
| 53
Figure 57 Protocoles utiliseacutes pour la communication avec MQTT
On peut le veacuterifier par une capture de trame sur Wireshark
Figure 58 Capture dune trame MQTT avec Wireshark
On peut noter que le port TCP utiliseacute pour le protocole MQTT (non chiffreacute) est le 1883
Les Publishers et les Subscribers nrsquoont pas besoin de se connaitre
Les Publishers et les Subscribers ne sont pas obligeacute de srsquoexeacutecuter en mecircme temps
622 Connexion au Broker MQTT Nous nous inteacuteresserons essentiellement aux options de connexion qui permettront de geacuterer la
Qualiteacute de Service (QoS) Pour se connecter un client MQTT envoie deux informations importantes
au Broker
keepAlive Cest la peacuteriode la plus longue pendant laquelle le client Publisher ou Subscriber pourra
rester silencieux Au-delagrave il sera consideacutereacute comme deacuteconnecteacute
cleanSession Lorsque le Client et le Broker sont momentaneacutement deacuteconnecteacutes (au-delagrave du
keepAlive annonceacute) on peut donc se poser la question de savoir ce quil se passera lorsque le client
sera agrave nouveau connecteacute
Si la connexion eacutetait non persistante (cleanSession = True) alors les messages non transmis
sont perdus Quel que soit le niveau de QoS (Quality of Service)
Si la connexion eacutetait persistante (cleanSession = False) alors les messages non transmis
seront eacuteventuellement reacuteeacutemis en fonction du niveau de QoS Voir le chapitre 624
623 Qualiteacute de Service au cours dune mecircme connexion
A partir du moment ougrave le Client se connecte au Broker il est possible de choisir un niveau de fiabiliteacute
des transactions Le Publisher fiabilise leacutemission de ces messages vers le Broker et le Subscriber
fiabilise la reacuteception des messages en provenance du Broker Une parle ici du cas dune mecircme
connexion crsquoest-agrave-dire entre le moment ou le Client se connecte et le moment ougrave
Soit il se deacuteconnecte explicitement (Close connexion)
Soit il na rien eacutemis ni fait signe de vie pendant le temps keepAlive
TCP
MQTT
Reacuteseau
Transport
Couche Application
IP
| 54
Lors dune mecircme connexion la Qualiteacute de Service (QoS) qui est mise en œuvre deacutepend uniquement
de la valeur du QoS selon les valeurs suivantes
QoS 0 At most once (au plus une fois) Le premier niveau de qualiteacute est sans acquittement Le
Publisher envoie un message une seule fois au Broker et le Broker ne transmet ce message quune
seule fois aux Subscribers Ce meacutecanise ne garantit pas la bonne reacuteception des messages MQTT
QoS 1 At least once (au moins une fois) Le deuxiegraveme niveau de qualiteacute est avec acquittement
Le Publisher envoie un message au Broker et attends sa confirmation De la mecircme faccedilon le Broker
envoie un message agrave ces Subscriber et attends leurs confirmations Ce meacutecanisme garantit la
reacuteception des message MQTT
Cependant si les acquittements nrsquoarrivent pas en temps voulu ou srsquoils se perdent la reacuteeacutemission du
message dorigine peut engendrer une duplication du message Il peut donc ecirctre reccedilu plusieurs fois
QoS 2 Exactly once (exactement une fois) Le troisiegraveme niveau de qualiteacute est garanti une seule
fois Le Publisher envoie un message au Broker et attends sa confirmation Le Publisher donne alors
lrsquoordre de diffuser le message et attends une confirmation Ce meacutecanisme garantit que quel que
soit le nombre de tentatives de reacuteemission le message ne sera deacutelivreacute quune seule fois
La Figure 59 montre les trames eacutemises pour chaque niveau de QoS
Figure 59 Qualiteacute de Service en MQTT
La Figure 60 repreacutesentes les 3 captures de trames sur Wireshark repreacutesentant les 3 QoS (1 2 et 3)
que nous venons dexpliquer
Broker
QoS 0
Au plus une fois
Message supprimeacute apregraves envoi
PUBLISH
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Duplications possibles
PUBLISH
PUBLICH Ack
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Pas de duplication
PUBLISH
PUBLISH Receive
PUBLISH Release
PUBLISH Complete
| 55
Figure 60 Capture de trame avec QoS = 0 puis QoS = 1 puis QoS = 2
624 Qualiteacute de Service apregraves une reconnexion
La question que nous nous posons et de savoir ce que deviennent les messages publieacutes sur le Broker
lorsquun ou plusieurs Subscribers sont momentaneacutement injoignables Il est possible de conserver
les messages qui ont eacuteteacute publieacutes sur le Broker afin de les retransmettre lors de la prochaine
connexion Cette possibiliteacute de sauvegarde doit ecirctre activeacutee agrave louverture de connexion gracircce au flag
cleanSession = 0 La connexion sera alors persistante crsquoest-agrave-dire que le Broker enregistre tous les
messages quil na pas reacuteussi agrave diffuser au Subscriber
Le Tableau 9 reacutesume leffet du flag cleanSession et du QoS
Clean Session Flag Subscriber QoS Publisher QoS Comportement True ( = 1) 0 1 2 0 1 2 Messages perdus
False ( = 0 ) 0 0 1 2 Messages perdus
False (= 0 ) 0 1 2 0 Messages perdus
False (= 0 ) 1 2 1 2 Tous les messages sont retransmis
Tableau 9 Qualiteacute de Service en fonction de la valeur du QoS et du flag cleanSession
625 Les Topics du protocole MQTT Les chaicircnes deacutecrivant un sujet forment une arborescence en utilisant la barre oblique comme
caractegravere de seacuteparation La Figure 61 et le Tableau 10 donne un exemple dorganisation de Topic
Figure 61 Exemple de hieacuterarchie de Topic MQTT
Niveau 3
Niveau 2
Niveau 1 Maison
Chambre
Temperature Humidite Bruit
Salon
Temperature
| 56
Nom du Topic Deacutetail du Topic MaisonChambreTemperature La tempeacuterature de la chambre de la maison
MaisonChambreBruit Le bruit de la chambre de la maison
MaisonSalonTemperature La tempeacuterature du Salon de la maison
Tableau 10 Exemple de Topic
Un client peut sabonner (ou se deacutesabonner) agrave plusieurs branches de larborescence agrave laide de
jokers englobant plusieurs Topics Deux caractegraveres jokers existent
Le signe plus + remplace nimporte quelle chaine de caractegravere sur le niveau ougrave il est placeacute
Le diegravese remplace nimporte quelle chaine de caractegravere sur tous les niveaux suivants Il
est obligatoirement placeacute agrave la fin
Nom du Topic Deacutetail du Topic Maison+Temperature Les tempeacuteratures de toutes les piegraveces de la maison
MaisonChambre La tempeacuterature lhumiditeacute et le bruit de la chambre de la maison
Tableau 11 Exemple de Topic
626 Mise en place drsquoun Broker MQTT Afin de bien comprendre le fonctionnement du protocole de MQTT on reacutealise des tests
indeacutependamment de TTN Nous allons mettre en place
Un Broker Mosquitto httpstestmosquittoorg
Un client Publisher MQTT Box sur Windows
Un client Subscriber MQTT Box sur Windows
Figure 62 Test du protocole MQTT
MQTT Client (Subscriber)
MQTT Client (Publisher)
Publish
Subscribe
BROKER (Mosquitto)
| 57
Le Broker MQTT est commun agrave tout le monde Nous pouvons soit le reacutealiser nous-mecircme soit utiliser
un Broker MQTT public de test Nous utiliserons le Broker de test de Mosquitto disponible sur
httpstestmosquittoorg Drsquoautres sont eacuteventuellement disponibles en cas de problegraveme par
exemple httpwwwmqtt-dashboardcom
Si nous deacutecidions de le reacutealiser nous-mecircme agrave lrsquoaide drsquoune Raspberry Pi (par exemple) Lrsquoinstallation
se ferait en deux lignes de commande
apt-get install mosquito Installation
sudo systemctl start mosquittoservice Lancement du service
Il est neacutecessaire drsquoinstaller mosquitto-clients si on souhaite que le Raspberry PI joue aussi le rocircle de
client ce qui nrsquoest pas notre cas
627 Mise en place drsquoun Publisher et drsquoun Subscriber MQTT Lancer le logiciel MQTTBox
MQTTBox gt Create MQTT Client
Dans ce client les seuls champs indispensables sont
Protocol MQTT TCP
Host testmosquittoorg
Figure 63 Configuration dun Client MQTT dans MQTT Box
Tester lrsquoenvoi et la reacuteception sur les Topics de votre choix
628 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT La reacutecupeacuteration des donneacutees fait reacutefeacuterence au flux Uplink Dans ce cas
TTN joue le rocircle de client Publisher
TTN joue aussi le rocircle de Broker
Notre application joue le rocircle de Subscriber
Nous pouvons donc repreacutesenter lrsquoapplication globale par le scheacutema suivant
| 58
Figure 64 Publisher et Subscriber dans en MQTT avec TTN
La publication est repreacutesenteacutee par la trame MQTT (1)
La souscription est repreacutesenteacutee par la trame MQTT (2)
Le client Publisher eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box mais cette fois avec la configuration suivante
Protocol mqtt tcp
Host Crsquoest lrsquoIP du Broker vers lequel il faut se connecter Dans notre cas il srsquoagit de celui
de TTN dont lrsquoadresse est euthethingsnetwork
Username La connexion vers le broker MQTT est soumis agrave une authentification Username
Password Dans notre cas le Username correspond au nom de notre application crsquoest-agrave-
dire seminaire_lorawan Si vous avez choisi une autre applicationil faut bien mettre la
votre
Password Le Password est nommeacute laquo Access Key raquo par TTN Elle vous sera donneacutee par
lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application vous
trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt Overview
Figure 65 Access Keys de lapplication dans TTN
The Things Network (Application Server)
BROKER
Application
The Things Network (Network Server)
Publish (1 )
[ Flux Uplink ]
Subscribe (2 )
[ Flux Uplink ]
| 59
Figure 66 Configuration du Client dans MQTT Box
Le client MQTT eacutetant configureacute il est maintenant capable de se connecter au Broker Il reste donc agrave
deacutefinir le fait que le client sera Subscriber Les informations que recevra le Subscriber deacutependent du
Topic auquel nous souscrivons Voici les Topic disponibles sur le Broker de TTN
ltAppIDgt correspond au nom de votre Application
ltDevIDgt correspond au nom de votre Device LoRa
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink ltAppIDgtdevicesltDevIDgtup
[Donneacutees] Flux Downlink ltAppIDgtdevicesltDevIDgtdown
[Activation Events] Activation dun Device ltAppIDgtdevicesltDevIDgteventsactivations
[Management Events] Creacuteation dun Device ltAppIDgtdevicesltDevIDgteventscreate
[Management Events] Update dun Device ltAppIDgtdevicesltDevIDgteventsupdate
[Management Events] Suppression dun Device ltAppIDgtdevicesltDevIDgteventsdelete
[Downlink Events ] Message programmeacute ltAppIDgtdevicesltDevIDgteventsdownscheduled
[Downlink Events ] Message envoyeacute ltAppIDgtdevicesltDevIDgteventsdownsent
[Erreurs] Uplink erreurs ltAppIDgtdevicesltDevIDgteventsuperrors
[Erreurs] Downlink erreurs ltAppIDgtdevicesltDevIDgteventsdownerrors
[Erreurs] Activations erreurs ltAppIDgtdevicesltDevIDgteventsactivationserrors
Tableau 12 Topics enregistreacutes dans TTN
Dans un premier temps nous souscrivons au Topic +devices+up Cela signifie que nous
souscrivons agrave tous les Devices LoRa de toutes nos applications pour le flux Uplink
Figure 67 Configuration du Subscriber
Les eacuteleacutements eacutemis par le Broker seront alors afficheacutes dans MQTTBox La
| 60
Figure 68 Trame LoRaWAN reccedilu sur le Subscriber MQTT
Ces donneacutees sont eacutecrites en JSON nous pouvons les remettre en forme
applicationID3
applicationNamemyApplication
deviceNamearduino0
devEUI0056xxxxxxxxx877
txInfo
frequency868500000
dr5
adrfalse
fCnt792
fPort15
dataSGVsbG8=
Le Frame Payload deacutechiffreacute est fourni dans le champ data en base 64 La valeur fournie par
dataSGVsbG8= correspond bien agrave la chaine de caractegravere hello que nous avons eacutemise avec le
Device LoRa
629 Envoyer des donneacutees depuis notre Application avec MQTT
Lrsquoenvoi des donneacutees fait reacutefeacuterence au flux Downlink Dans ce cas
Notre application joue le rocircle de Publisher
TTN joue le rocircle de Broker
TTN joue aussi le rocircle de client Subscriber
| 61
La publication est repreacutesenteacutee par la trame MQTT (3)
La souscription est repreacutesenteacutee par la trame MQTT (4)
Le client Subscriber eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box Le rocircle de client dans MQTT Box a eacuteteacute faite au
paragraphe 628 Il nous reste simplement agrave ajouter le rocircle de Publisher La configuration est la
suivante
Topic du Subscriber seminaire_lorawandevicesarduino0down ougrave seminaire_lorawan
est agrave remplacer par le nom de votre application et arduino0 par le nom du Device LoRa vers
lequel vous souhaitez envoyeacute une donneacutee (Voir chapitre 628 pour comprendre les Topics)
Le Payload doit ecirctre au format JSON Lrsquoexemple suivant envoie laquohello raquo
payload_raw aGVsbG8=
The Things Network (Application Server)
BROKER
Application
Publish (3)
[ Flux Downlink ]
The Things Network (Network Server)
Subscribe (4)
[ Flux Downlink ]
| 62
Figure 69 Configuration du Publisher
Vous devriez voir les donneacutees arriver sur votre Device LoRA
| 63
7 Creacuteation de notre propre Network et Application Server
711 Objectifs Lors de la mise en œuvre du reacuteseau LoRaWAN au chapitre 52 nous avons utiliseacute TTN (The Things
Network) pour jouer le rocircle de Network Server et drsquoApplication Server Pour de multiples raisons
Seacutecuriteacute autonomie coucircthellipil peut ecirctre inteacuteressant de monter soi-mecircme un Network Server et un
Application Server Cela est possible seulement si vous posseacutedez vos propres Gateway puisque
celles-ci devront forwarder leur paquet agrave destination preacutecise Il faudra donc les reconfigurer pour
qursquoelles pointent vers votre nouvelle architecture
712 Preacutesentation de LoRaServer LoRaServer [ wwwloraserverio ] est un projet Open-Source reacutepondant exactement au besoin que
nous avons Nous lrsquoutiliserons sur une cible Raspberry PI En reacutealiteacute il peut souvent ecirctre mise en
place dans le mecircme systegraveme que la Gateway surtout si celle-ci est elle-mecircme agrave base de RPI Les
Gateway EBDS que nous posseacutedons possegravedent drsquoailleurs un Network Server et un Application Server
que nous aurions pu utiliser Neacuteanmoins pour des raisons peacutedagogiques il est inteacuteressant de
seacuteparer les systegravemes pour bien diffeacuterencier les probleacutematiques
Attention il y a une ambiguiumlteacute dans la deacutenomination des entiteacutes logiciels de LoRaServer
LoRaServer (sans espace entre le mot LoRa et Server) est le nom du projet global En
revanche LoRa Server (avec un espace) est le nom du service qui joue le rocircle du Network
Server
Lrsquoarchitecture et le fonctionnement de LoRaServer est preacutesenteacutee dans sa documentation par le
scheacutema suivant
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Raspberry PI
Figure 70 Architecture globale de notre reacuteseau loRaWAN
| 64
Figure 71 Architecture deacutetailleacutee de LoRaServer
On srsquoattends agrave voir uniquement un Network Server (LoRa Server) et un Application Server (LoRa App
Server) mais ce scheacutema est plus complexe Il demande un certain nombre drsquoexplications pour bien
comprendre ce que nous allons installer et la faccedilon dont nous lrsquoutiliserons par la suite
713 Le laquo Packet Forwarder raquo (Gateway) Comme nous lrsquoavons vu au chapitre 412 les Gateways LoRa sont des passerelles entre la
modulation LoRa et un reacuteseau IP Pour reacutealiser cette passerelle un service nommeacute laquo UDP Packet
Forwarder raquo a eacuteteacute deacuteveloppeacute par Semtech httpsgithubcomLora-netpacket_forwarder Dans
ce dossier github un fichier nommeacute PROTOCOLTXT explique parfaitement ce protocole applicatif
qui travaille au-dessus de UDP
Figure 72 Protocole Uplink (PUSH_DATA du Packet Forwarder)
| 65
On remarque que les paquets sont envoyeacutes en UDP au Network Server dans une trame appeleacutee
PUSH_DATA Cette trame est acquitteacutee par le Network Server par une trame appeleacutee PUSH_ACK
Sur notre Network Server nous pouvons reacutealiser une capture de trame pour veacuterifier si le protocole
est bien celui preacutesenteacute dans le document
Figure 73 Trame captureacutee par Wireshark lors dun Uplink
Drsquoapregraves la capture preacuteceacutedente on remarque que le Packet Forwarder fonctionne bien avec UDP sur
le port 1700
Le contenu des donneacutees (champ Data) est deacutetailleacute dans le tableau suivant
Champ | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | random token
[3] | 3 | PUSH_DATA identifier = 0x00
[4] | 4-11 | Gateway unique identifier (MAC address)
[5] | 12-end | JSON object starting with ending with
Lrsquoobjet JSON de la transmission reacuteeacutecrit plus proprement est celui-ci
Figure 74 Analyse du champ Donneacutees du protocole laquo Packet Forwarder raquo
0000 02 f9 30 00 b8 27 eb ff fe ae 26 f5 7b 22 72 78 0amprx 0010 70 6b 22 3a 5b 7b 22 74 6d 73 74 22 3a 33 37 35 pk[tmst375 0020 35 30 30 35 38 31 39 2c 22 63 68 61 6e 22 3a 32 5005819chan2 0030 2c 22 72 66 63 68 22 3a 31 2c 22 66 72 65 71 22 rfch1freq 0040 3a 38 36 38 2e 35 30 30 30 30 30 2c 22 73 74 61 868500000sta 0050 74 22 3a 31 2c 22 6d 6f 64 75 22 3a 22 4c 4f 52 t1moduLOR 0060 41 22 2c 22 64 61 74 72 22 3a 22 53 46 37 42 57 AdatrSF7BW 0070 31 32 35 22 2c 22 63 6f 64 72 22 3a 22 34 2f 35 125codr45 0080 22 2c 22 6c 73 6e 72 22 3a 36 2e 35 2c 22 72 73 lsnr65rs 0090 73 69 22 3a 2d 31 2c 22 73 69 7a 65 22 3a 31 38 si-1size18 00a0 2c 22 64 61 74 61 22 3a 22 51 4e 4d 61 41 53 59 dataQNMaASY 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 ]
Ch
amp
[1
]
Ch
amp
[2
]
Ch
amp
[3
]
Ch
amp
[4
]
| 66
rxpk[ tmst3755005819
chan2
rfch1
freq868500000
stat1
moduLORA
datrSF7BW125
codr45
lsnr65
rssi-1
size18
dataQNMaASYAAQAPpyPZ955+SmY
]
Le champ data correspond au PHY Payload
De la mecircme faccedilon on retrouve la Trame drsquoacquittement
Figure 75 Trame captureacutee par Wireshark lors de lrsquoacquittement drsquoun Uplink
Champs | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | same token as the PUSH_DATA to acknowledge
[3] | 3 | PUSH_ACK identifier = 0x01
Nous retrouvons bien tous ces champs dans la trame Wireshark
714 LoRa Gateway Bridge Nous avons deacutecrit au chapitre preacuteceacutedent (713) le fonctionnement du Packet Forwarder Le
Network Server(Lora Server) que nous allons mettre en place aurait tregraves bien pu srsquointerfacer
directement agrave ce protocole Mais cela aurait plusieurs impacts dont un qui est important dans la
conception de logiciel Si le Packet Forwarder change ou si un autre type de Forwarder est utiliseacute
alors lrsquoutilisation du LoRa Server devient impossible Il a donc eacuteteacute choisi de creacuteer une eacutetape
intermeacutediaire Le Network Server que nous mettrons en plus utilisera le protocole MQTT plutocirct que
le protocole UDP packet Forwarder
En drsquoautres termes le LoRa Gateway Bridge est un service qui fera abstraction du Packet Forwarder
pour srsquointerfacer plus simplement avec le Network Server
715 LoRa Server (Network Server) Il srsquoagit de notre Network Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
413 Cependant il srsquointerfacera au protocole MQTT en recevant les informations agrave partir du
Broker au lieu de recevoir directement les trames en provenance de la Gateway
| 67
716 LoRa App Server (Application Server) Il srsquogit de notre Application Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
414
717 LoRa Geo Server Il srsquoagit drsquoun service qui permet drsquoutiliser certaines proprieacuteteacutes du protocole LoRa pour proposer un
service de geacuteolocalisation des Devices LoRa Nous ne lrsquoutiliserons pas dans notre cas
718 Application Il srsquoagit de notre Application qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre 415
Elle ne fait pas partie du projet LoRaServer crsquoest donc bien toujours agrave nous de proposer notre propre
Application
Figure 76 Les interfaces possibles entre LoRaServer et lrsquoApplication utilisateur
Comme nous pouvons le voir sur la figure preacuteceacutedente deux possibiliteacutes sont offertes pour interfacer
notre application JSON REST (incluant HTTP POST) et via un Broker MQTT Ces deux meacutethodes ont
deacutejagrave eacuteteacute traiteacutee au chapitre 61 (HTTP POST ) et au chapitre 62 (MQTT) Nous verrons aussi drsquoautres
possibiliteacutes pour personnaliser notre application au chapitre 7
72 Installation de LoRaServer
721 Mise en place de lrsquoenvironnement
Nous allons installer une carte SD avec la derniegravere version de Raspbian Nous ne deacutetaillerons pas la
deacutemarche pour cela car elles sont largement documenteacutees et mises agrave jour sur le site
wwwraspberrypiorg
Installer un carte SD avec la derniegravere version de Raspbian
Plutocirct que de fonctionner avec un clavier et une souris nous preacuteconisons de travailler agrave distance
avec la RPI via une connexion SSH Depuis quelques anneacutees Raspbian a supprimeacute le deacutemarrage du
service SSH au boot Heureusement il est possible de le reacuteactiver par la meacutethode suivante
Avec Windows ou Linux ouvrir la partition BOOT de votre carte SD et placer un fichier agrave la
racine nommeacute sshtxt (ou ssh)
Mettre la carte SD dans votre RPI et la deacutemarrer
| 68
Pour acceacuteder agrave la RPI en SSH depuis Windows nous utiliserons de preacutefeacuterence le logiciel
client MobaXterm mais tout autre client SSH est valable
Installer MobaXterm sur votre PC et connectez-vous agrave votre Raspberry PI
Lrsquoutilisation drsquoun espion de reacuteseau type Wireshark peut ecirctre inteacuteressant pour eacutetudier les trames qui
sont reccedilues et qui sont eacutemises Cela nous permettra de valider le fonctionnement des diffeacuterents
protocoles reacuteseau qui permettent de communiquer agrave la Gateway drsquoune part et agrave lrsquoApplication
drsquoautre part Nous utiliserons tshark
apt-get install tshark installation
tshark ndashn -i eth0 Exemple drsquoune analyse sur lrsquointerface wlan0
722 Installation sur la Raspberry PI La meacutethode drsquoinstallation de LoRaServer est documenteacutee sur le site web agrave lrsquoadresse suivante
[ httpswwwloraserverioguidesdebian-ubuntu ] Nous installerons le LoRa Gateway Bridge
le LoRa Server et le LoRa App Server
Apregraves lrsquoinstallation la configuration se fait par une interface graphique accessible par le reacuteseau sur
le port 8080
Si vous travaillez sur la RPI connectez-vous sur httplocalhost8080
Si vous travaillez agrave distance (SSH) connectez-vous sur httpIP_RPI8080
Les Usernames et Password par deacutefaut sont
Username admin
Password admin
Lrsquoeacutecran drsquoaccueil sera donc le suivant
Figure 77 Architecture globale apregraves installation de LoRaServer
Devices
Gateways LoRa
UDP Packet Forwarder
Application Server
LoRa App Server
Internet
Network Server
LoRa Server
LoRa Gateway Bridge
| 69
Figure 78 Ecran daccueil de LoRaServer apregraves authentification
71 Configuration de LoRa Server pour lUplink
711 Enregistrement drsquoune nouvelle Organisation
Pour enregistrer une nouvelle Organizations Organizations gt Create Puis entrer les configurations
suivantes
Figure 79 Enregistrement dun nouvelle Organisation
712 Enregistrement drsquoune instance du Network Server Pour enregistrer une nouvelle instance du Network Server Network Server gt Create Puis entrer
les configurations suivantes
| 70
Figure 80 Enregistrement dun nouveau Network Server
Dans lrsquoonglet Gateway Discovery il est possible drsquoactiver une option de deacutecouverte de Gateway aux
alentours Lorsqursquoelle est configureacutee le Network Server va envoyer une trame Downlink de
configuration de la Gateway lui ordonnant de reacutealiser des PING en LoRa La configuration du
Gateway Discovery preacutevoit de speacutecifier
Le nombre de fois par jour que les PING LoRa sont envoyeacutes
Le canal drsquoeacutemission
Le Data Rate (Voir paragraphe 445)
Un PING LoRa reccedilu sur une Gateway sera retransmis sur le Network Server (Lora Server) et une carte
sera afficheacutee
Lrsquoonglet TLS Certificates ne sera pas utiliseacute dans le cadre de notre deacutemonstration
713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) Il faut tout drsquoabord faire un enregistrement drsquoun laquo service-profile raquo Un laquo service profile permet de
faire la connexion entre le Network Server et les Applications que nous enregistrerons dans notre
Organisation Service-profiles gt Create
Service-profile name myServiceProfile
Network-server myNetworkServer
On laissera par deacutefaut toutes les autres options
Pour enregistrer une nouvelle Application Applications gt Create Puis entrer les configurations
suivantes
| 71
Figure 81 Enregistrement dune nouvelle Application
714 Enregistrement des Devices LoRa Il faut tout drsquoabord faire lrsquoenregistrement drsquoun Device-profile pour les Devices LoRa que vous
souhaitez connecter Dans notre cas nous ferons un premier test en speacutecifiant que nous utilisons
seulement le mode drsquoauthentification ABP (voir chapitre 431) Devices profile gt Create
Figure 82 Enregistrement dun laquo Device profile raquo
Nous pouvons alors creacuteer dans notre Application des nouveaux Devices Application gt
myApplication gt Create
| 72
Figure 83 Enregistrement dun nouveau Device LoRa
Dans la fenecirctre Activation on va alors configurer les 3 eacuteleacutements indispensables agrave une
authentification en APB Le DevAddr le NwkSKey et lrsquoAppSKey
Figure 84 Configuration de lenregistrement du Device LoRa (en ABP)
La configuration minimale de LoRaServer est maintenant termineacutee Nous pouvons donc brancher
un Device LoRa qui possegravede les les attribus (DevAddr NwkSKey et AppSKey) que nous avons
enregistreacute dans LoRaServer et le faire eacutemettre
715 Visualisation des trames reccedilues Les trames eacutemises par le Device LoRa vont donc parcourir le cheminement suivant
| 73
Figure 85 Reacutesumeacute du cheminement des trames LoRaWan en Uplink avec LoRaServer
En allant dans le Live Device Data (Application gt Nom_du_Device gt Live Device Data) on peut voir la
liste des trames reccedilues ainsi que les donneacutees applicatives deacutechiffreacutees
Figure 86 Reacuteception des trames des Devices LoRa
Figure 87 Analyse des trames des Devices LoRa
Dans lrsquoonglet LIVE LORAWAN FRAME nous pouvons voir les trames LORAWAN et si besoin eacutetudier
le contenu de ce qursquoelles contiennent En revanche les donneacutees applicatives sont ici chiffreacutees
UDP
Packet Forwarder
LoRa Bridge
Gateway LoRa Server LoRa App Server
Gateway
Server
Internet
| 74
Figure 88 Reacuteception des Trames LoRaWAN
72 Configuration de LoRaServer pour linteacutegration dApplication Nous avons vu dans le chapitre 718 que linterface entre LoRaServer et notre Application pouvait
ecirctre reacutealiseacutee soit par MQTT soit par les meacutethodes REST (HTTP POST) Nous avons deacutejagrave impleacutementeacute
et expliqueacute ces protocoles dans le cadre de son utilisation avec TTN Nous allons donc juste
configurer LoRaServer pour tester ces deux meacutethodes
721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST Nous utiliserons exactement la mecircme meacutethode que celle que nous avons utiliseacute avec TTN au
chapitre 615 Les diffeacuterentes Clients et Serveurs disponibles pour ces tests sont expliqueacutes au
paragraphe 612
Dans LoRaServer ajouter une inteacutegration HTTP LoRaServer gt Applications gt myApplication gt
Integrations gt Create gt HTTP Integration et la configurer comme le montre la Figure 89 Vous
remplacerez eacutevidement le lien par votre propre Endpoints
Figure 89 Configuration de linteacutegration HTTP POST dans LoRaServer
En envoyant des trames LoRa depuis votre Device vous devriez voir les contenus JSON sur votre
Endpoint
722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT Nous allons nous connecter au Broker MQTT de LoRaServer Pour cela nous utiliserons la mecircme
meacutethode que celle que nous avons utiliseacute avec TTN au chapitre 628 Nous utiliserons MQTTBox
comme nous lavons deacutejagrave fait au paragraphe 627
Le Broker de LoRaServer a enregistreacute les Topics suivant
[applicationID] correspond au nom de votre Application
[devEUI] correspond au nom de votre Device LoRa
| 75
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink application[applicationID]device[devEUI]rx
[Donneacutees] Flux Downlink application[applicationID]device[devEUI]tx
[Status] Statut dun Device application[applicationID]device[devEUI]status
[Ack] Acquittement des messages application[applicationID]device[devEUI]ack
[Erreurs] Erreurs application[applicationID]device[devEUI]error
Tableau 13 Topics enregistreacutes dans LoRaServer
| 76
8 Creacuteation de notre propre Application
81 Utilisation de Node-RED
811 Preacutesentation Node-RED est un outil de programmation graphique qui permet de faire communiquer les
peacuteripheacuteriques mateacuteriels drsquoun systegraveme sans eacutecrire de code De nombreux protocoles sont aussi pris
en charge au travers de bloc ( Node) qursquoil suffit de connecter entre eux pour reacutealiser simplement
une application Il peut srsquoexeacutecuter localement sur un PC ou sur des cibles embarqueacutees telle qursquoune
Raspberry PI (RPI)
Dans les deacutemonstrations que nous mettrons en œuvre nous utiliserons une RPI Par soucis de
simpliciteacute nous utiliserons les derniegraveres versions de Raspbian (systegraveme drsquoexploitation de la RPI) qui
integravegre drsquoorigine Node-RED Il nrsquoy a donc tregraves peu de chose agrave mettre en place pour arriver agrave mettre
en place une Application Nous pouvons travailler soit directement sur la RPI agrave lrsquoaide drsquoune souris-
clavier mais il est recommandeacute de travailler agrave distance avec une connexion SSH
812 Mise en place de lrsquoenvironnement La mise en place de la RPI avec le systegraveme drsquoexploitation Raspbian a eacuteteacute preacutesenteacute au chapitre 721
Vous pouvez reprendre la mecircme installation ou repartir sur une nouvelle
Il est possible de faire en sorte que Node-RED se lance directement au deacutemarrage gracircce agrave la
commande sudo systemctl enable noderedservice
Sil nest pas actif lancer Node-RED sur votre RPI node-red-start
Nous nous connectons au Node-RED de la RPI via un navigateur web sur le port 1880 en tapant dans
la barre dURL httpIP_Raspeberry_PI1880 Ce nous permet darriver agrave la fenecirctre suivante
Figure 90 Page daccueil de Node-RED
Il est possible de sinterfacer avec TTN avec les Nodes deacutejagrave disponibles gracircce au protocole HTTP
POST ou MQTT Neacuteanmoins nous pouvons avantageusement installer deux librairies speacutecifiques
Une qui facilite linterfaccedilage avec TTN
Une qui facilite la mise en place dinterface graphique
Installation des Nodes TTN
cd $HOMEnode-red
npm install node-red-contrib-ttn
Installation de Dashboard (interface graphique)
| 77
cd $HOMEnode-red
npm install node-red-dashboard
Il peut ecirctre necessaire de redeacutemarrer Node-RED pour prendre en compte linstallation de nos deux
Nodes
-----------------------------------
sudo apt-get install npm
sudo npm install -g npm
hash -r
cd ~node-red
npm install node-red-example node name
------------------------------------
813 Creacuteer une Application speacutecifique pour TTN Nous allons commencer par geacuterer le flux Uplink Apporter sur votre scheacutema un Node ttn uplink et
un Node Debug puis relier les Le Node ttn uplink nous permettra de configurer la
communication avec TTN en MQTT Le Node debug eacutecrira sur le terminal les informations brutes
qui seront reccedilu par le Node ttn uplink
Figure 91 Visualisation des trame publieacutees par TTN sur notre client MQTT
Double cliquer sur le Node ttn uplink pour le configurer comme la figure suivante
Le champ Name sera le nom du Node sur votre scheacutema Le champ Device ID est le device LoRa
concerneacute dans votre application De plus il faut entrer les caracteacuteristiques de votre application (Add
new ttn app) pour que Node-RED puisse sy connecter
Figure 92 Configuration du node ttn uplink
Configuration de votre nouvelle application
| 78
Figure 93 Identifiant et mot de passe de notre application
AppID Nom de votre application Dans notre cas seminaire_lorawan
Access Key Comme nous lavons deacutejagrave expliqueacute plus tocirct l Access Key vous sera donneacutee
par lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application
vous trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt
Overview
Le Node ttn uplink doit maintenant avoir le nom que vous avez configureacute Cliquer sur Deploy pour
lancer votre projet Le bloc ttn uplink doit maintenant ecirctre connecteacute agrave TTN Cela est speacutecifieacute
connected sous le bloc
Figure 94 Utilisation du Node TTN Uplink
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
Figure 95 Simulation de Uplink dans TTN
Vous devriez voir le reacutesultat dans la fenecirctre de Debug Par exemple pour le test denvoi de 31 32
correspondant au code ASCII des chiffres 1 et 2 vous devriez avoir la fenecirctre de Debug suivante
| 79
Figure 96 Reacutesultats obtenu dans la fenecirctre Debug apregraves la simulation dUplink
814 Creacuteation drsquoun Dashboard
Dans la mise en place de lenvironnement (chapitre 812) nous avons installeacute des Nodes
Dashboard qui vont nous permettre de reacutealiser une interface graphique tregraves simple et de la mettre
agrave disposition des utilisateurs via un des graphiques histogramme gauges afficheurshellip
Figure 97 Impleacutementation dune interface graphique dans Node RED
Linterface graphique que nous allons creacuteer sera constitueacutee donglet (tab) La mise en place des
composant se fait de la faccedilon suivante
Chaque eacuteleacutement graphique doit appartenir agrave un groupe de composant quil va falloir creacuteer
Chaque groupe de composant doit appartenir agrave un onglet (tab) quil va falloir creacuteer
Figure 98 Creacuteation dun groupe de composant
Figure 99 Creacuteation dun nouvel onglet dans le site web
Cliquer sur Deploy pour activer votre application
LURL pour joindre linterface graphique de votre site web est disponible sur ladresse
httpIP_Raspeberry_PI1880ui
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
| 80
Figure 100 Interface graphique du site web avec Node-RED
82 Programmation en PHP Maintenant que nous avons testeacute toute lrsquoarchitecture nous pouvons mettre en place une
application qui jouera deux rocircles
Un rocircle de Serveur HTTP POST reacutecupeacuterant les donneacutees en provenance de TTN
Un rocircle de Client HTTP POST qui geacuteneacuterera les requecirctes vers TTN
Un serveur web apache sur RPI heacuteberge cette application Linterface graphique du site web est
reacutealiseacute avec le template CSS proposeacute par Bootstrap [ httpsgetbootstrapcom ]
Figure 101 Architecture de notre application en PHP sur RPI
The Things Network
Notre Application
[ Serveur Apache sur Raspberry Pi ]
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 81
Nous allons lrsquoutiliser telle quelle Elle est juste proposeacutee agrave titre dexemple Lrsquoobjectif de cette
application est de geacuteneacuterer une ouverture fermeture de ruche agrave distance dans le cadre de projets
eacutetudiants du Master Electronique et Systegravemes Embarqueacutes de lUSMB [ httpscem-esetuniv-
smbfr ]
Figure 102 Application permettant de recevoir et deacutemettre des requecirctes HTTP POST
Configurer TTN pour pointer vers votre nouveau serveur et tester le flux montant et
descendant
| 82
9 Versions du document
Version 10 02022019
Version initiale
Version 20 23022019
Ajout drsquoun paragraphe Les systegravemes embarqueacutes dans lrsquoIoT En introduction
Compleacutement et ameacutelioration Ameacutelioration exercice eacutetalement de spectre
Correction Cacircblage Arduino
Ajout drsquoun paragraphe Fonctionnement de lrsquoArduino et ajout de librairies
Compleacutement et ameacutelioration Couche physique LoRa Ajout de 4 figures pour lrsquoexplication
de la modulation Chirp
Ajout drsquoun paragraphe sur les acronymes utiliseacutes au deacutebut du cours TTN LoRa MQTThellip
Compleacutement drsquoinformations sur les dB et dBm
Ajout LoRa Calculator
Version 30 8032019
Ajout de figure sur le rocircle de la Gateway LoRa
Ajout de paragraphe authentification avec le Network Server
Ajout de paragraphe sur le chiffrement avec lrsquoApplication Server
Ajout drsquoun sommaire en deacutebut de cours
Ajout de 2 scheacutemas ABP et OTAA
Retrait explication du deacutetail de la laquo Join Request raquo en OTAA Trop complexe attente de
reacutealisation drsquoun scheacutema plus explicite
Ajout drsquoun scheacutema sur lrsquoattaque par REPLAY
Ajout de paragraphe des diffeacuterents reacuteseaux LoRaWAN existants Opeacutereacutes et Priveacutes
Ajout des scheacutemas des trames LoRaWAN Physique LoRa MAC Application
Compleacutement drsquoinformation sur les Classes de Devices
Ajout drsquoun paragraphe sur la Gateway utiliseacutee pour le Downlink
Ajout drsquoun paragraphe sur le JSON
Compleacutement drsquoinformation sur le codage en Base64
Ajout drsquoinformation dans le deacutecodage des trames LoRaWAN
Restructuration des explications sur lrsquoenvoi et la reacutecupeacuteration des donneacutees en HTTPMQTT
Version 40 8032019
Ajout drsquoun chapitre Creacuteation de notre propre Application
Ajout drsquoun chapitre Creacuteation de notre propre Network et Application Server
Ajout drsquoune figure Visualisation des Chirps LoRa par SDR (Radio Logicielle)
Compleacutements drsquoinformation sur MQTT
Compleacutements dinformation sur les Topics de TTN en MQTT
| 2
Preacutesentation du document
Ce cours sur lrsquointernet des Objets et les protocoles LoRa LoRaWAN est le support drsquoune formation
proposeacutee par lrsquoUniversiteacute de Savoie Mont Blanc (USMB) Elle est reacutealiseacutee
Aux eacutetudiants du Master ESET (Electronique des Systegravemes Embarqueacutes et Teacuteleacutecoms) Site web
de la formation [ wwwmaster-electroniquecom ]
Aux entreprises qui en font la demande (1 ou 2 journeacutees) sylvainmontagnyuniv-smbfr
Ce cours est mis agrave disposition sur internet et est libre drsquoutilisation Toutes personnes
souhaitant apporter des modifications ameacuteliorations corrections peut le faire sur
lrsquoadresse mail sylvainmontagnyuniv-smbfr Lrsquoauteur vous remercie par avance pour
votre contribution
Sigles et Acronymes
LoRa Long Range
LoRaWAN Long Rang Wide Area Network
LPWAN Low Power Wide Area Network
TTN The Things Network
MQTT Message Queuing Telemetry Transport
QoS Quality of Service
HTTP HyperText Transfer Protocol
IoT Internet Of Things
LTE-M Long Term Evolution Cat M1
NB-IoT NarrowBand Internet of Things
FDM Frequency Division Multiplexing
TDM Time Division Multiplexing
CDMA Code Division Multiple Access
RSSI Received Signal Strength Indication
SNR Signal Over Noise Ratio
SF Spreading Factor
CR Coding Rate
CHIRP Compressed High Intensity Radar Pulse
JSON JavaScript Object Notation
SDR Software Digital Radio
| 3
Sommaire 1 LES SYSTEMES EMBARQUES ET LrsquoIOT 6
11 LINTERNET DES OBJETS ( INTERNET OF THINGS IOT ) 6 111 Les systegravemes embarqueacutes dans lrsquoIoT 6 112 Diffeacuterents protocoles dans lrsquoIoT 6 113 Bande de freacutequence utiliseacutees 7
12 MODES DE PARTAGE DU SUPPORT 7 13 NOTION DrsquoETALEMENT DE SPECTRE 8
131 Transmissions successives 8 132 Transmissions simultaneacutees 9 133 Cas du protocole LoRa 9
2 TRANSMISSION RADIO ET PROPAGATION 10
21 LES UNITES ET DEFINITIONS 10 22 ETUDE DE LA DOCUMENTATION DrsquoUN COMPOSANT LORA 11
3 LA COUCHE PHYSIQUE LORA 13
31 LA MODULATION LORA 13 311 La forme du symbole (Chirp) 13 312 Dureacutee drsquoeacutemission drsquoun symbole 15
32 CODING RATE 16 33 UTILISATION DU LORA CALCULATOR 17 34 TIME ON AIR 18 35 MISE EN ŒUVRE LORA EN POINT A POINT 19
351 Utilisation de lrsquoIDE Arduino 19 352 Validation du fonctionnement 20 353 Mise en valeur du Spreading Factor 20
4 LE PROTOCOLE LORAWAN 21
41 STRUCTURE DrsquoUN RESEAU LORAWAN 21 411 Les Devices LoRa 21 412 Les Gateways LoRa 21 413 Le Network Server 22 414 Application Server 22 415 Application Web Serveur 24 416 Authentification avec le Network Server 25 417 Chiffrement des donneacutees vers lrsquoApplication Server 25 418 Combinaison de lrsquoauthentification et du chiffrement 26
42 CLASSES DES DEVICES LORAWAN 26 421 Classe A (All) Minimal power Application 26 422 Classe B (Beacon) Scheduled Receive Slot 27 423 Classe C (Continuous) Continuously Listening 28 424 Quelle Gateway pour les flux Downlink 29
43 ACTIVATION DES DEVICES LORA ET SECURITE 29 431 ABP Activation By Personalization 29 432 OTAA Over The Air Activation 30 433 Seacutecuriteacute 31
44 LA TRAME LORA LORAWAN 32 441 Les couches du protocole LoRaWAN 32 442 Couche Application 33 443 Couche LoRa MAC 34
| 4
444 Couche physique Modulation LoRa 34 445 Canaux et bandes de freacutequences et Data Rate (DR) 35 446 Trame reccedilue et transmise par la Gateway LoRaWAN 36 447 Le format JSON 37
5 MISE EN ŒUVRE DrsquoUN RESEAU LORAWAN 38
51 LES DIFFERENTS TYPES DE RESEAUX 38 511 Les reacuteseaux LoRaWAN opeacutereacutes 38 512 Les reacuteseaux LoRaWAN priveacutes 38 513 Les zones de couvertures 38
52 THE THINGS NETWORK (TTN) 39 521 Preacutesentation de TTN 39 522 Configuration de la Gateway 39 523 Enregistrement des Gateways Appplication et Devices 39 524 Configuration des Devices LoRa 40
53 MISE EN APPLICATION 41 54 ANALYSE DES TRAMES ECHANGEES 41
541 Utilisation de la base 64 41 542 Inteacuterecirct et inconveacutenient de la base 64 43 543 Uplink Du Device LoRa au Network Server 43 544 Uplink Du Network Server agrave lrsquoApplication Server 45 545 Simulation drsquoUplink dans lrsquoApplication Server 46 546 Downlink De lrsquoApplication Server au Device LoRa 46
6 LA RECUPERATION DES DONNEES SUR NOTRE PROPRE APPLICATION 47
61 RECUPERATION DES DONNEES EN HTTP POST DANS LrsquoAPPLICATION 47 611 Preacutesentation du protocole HTTP 47 612 Fonctionnement drsquoun client et drsquoun serveur HTTP POST 48 613 Test du serveur HTTP POST 49 614 Test du client HTTP POST 49 615 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST 49 611 Envoyer des donneacutees depuis notre Application avec HTTP POST 51
62 RECUPERATION DES DONNEES AVEC MQTT DANS LrsquoAPPLICATION 52 621 Preacutesentation du protocole MQTT 52 622 Connexion au Broker MQTT 53 623 Qualiteacute de Service au cours dune mecircme connexion 53 624 Qualiteacute de Service apregraves une reconnexion 55 625 Les Topics du protocole MQTT 55 626 Mise en place drsquoun Broker MQTT 56 627 Mise en place drsquoun Publisher et drsquoun Subscriber MQTT 57 628 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT 57 629 Envoyer des donneacutees depuis notre Application avec MQTT 60
7 CREATION DE NOTRE PROPRE NETWORK ET APPLICATION SERVER 63
711 Objectifs 63 712 Preacutesentation de LoRaServer 63 713 Le laquo Packet Forwarder raquo (Gateway) 64 714 LoRa Gateway Bridge 66 715 LoRa Server (Network Server) 66 716 LoRa App Server (Application Server) 67 717 LoRa Geo Server 67 718 Application 67
72 INSTALLATION DE LORASERVER 67
| 5
721 Mise en place de lrsquoenvironnement 67 722 Installation sur la Raspberry PI 68
71 CONFIGURATION DE LORA SERVER POUR LUPLINK 69 711 Enregistrement drsquoune nouvelle Organisation 69 712 Enregistrement drsquoune instance du Network Server 69 713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) 70 714 Enregistrement des Devices LoRa 71 715 Visualisation des trames reccedilues 72
72 CONFIGURATION DE LORASERVER POUR LINTEGRATION DAPPLICATION 74 721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST 74 722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT 74
8 CREATION DE NOTRE PROPRE APPLICATION 76
81 UTILISATION DE NODE-RED 76 811 Preacutesentation 76 812 Mise en place de lrsquoenvironnement 76 813 Creacuteer une Application speacutecifique pour TTN 77 814 Creacuteation drsquoun Dashboard 79
82 PROGRAMMATION EN PHP 80
9 VERSIONS DU DOCUMENT 82
| 6
1 Les systegravemes embarqueacutes et lrsquoIoT
11 LInternet des Objets ( Internet of Things IoT )
111 Les systegravemes embarqueacutes dans lrsquoIoT Drsquoune faccedilon geacuteneacuterale les systegravemes eacutelectroniques peuvent ecirctre caracteacuteriseacutes par leur consommation
leur puissance de calcul leur taille et leur prix Dans le cas speacutecifique des systegravemes embarqueacutes
utiliseacutes dans lrsquoIoT nous pouvons affecter le poids suivant agrave chacune des caracteacuteristiques
Figure 1 Consommation Puissance Taille et Prix des objets connecteacutes
Compareacutes aux autres systegravemes eacutelectroniques les systegravemes embarqueacutes utiliseacutes dans lrsquoIoT possegravedent
donc
Une faible consommation
Une faible puissance de calcul
Une petite taille
Un prix faible
112 Diffeacuterents protocoles dans lrsquoIoT
Citez les diffeacuterents protocoles que vous connaissez dans le mode de lrsquoIoT (Internet Of
Things) et reportez-les dans le graphique ci-dessous en fonction de leur bande passante
et de leur porteacutee
Figure 2 Protocoles utiliseacutes dans lIoT en fonction du deacutebit et de la porteacutee
Dans lrsquoIoT les protocoles utiliseacutes possegravedent une grande porteacutee et des deacutebits faibles
Lrsquoensemble de ces reacuteseaux sont deacutenommeacutes LPWAN Low Power Wide Area Network
113 Bande de freacutequence utiliseacutees En Europe les bandes de freacutequences libres (sans licence) sont
13 Mhz (RFID) 169 Mhz 434 Mhz 868 Mhz 24Ghz 5 Ghz et 24 Ghz (Faisceau Hertzien) Parmi ces
freacutequences seul le 433 MHz et 868 MHz sont utilisables en LoRa
12 Modes de partage du support Quel que soit le protocole utiliseacute le support de transfert de lrsquoinformation est lrsquoair car tous les
protocoles de lrsquoIoT sont Wireless Le support doit ecirctre partageacute entre tous les utilisateurs de telle
faccedilon que chacun des dispositifs Wireless ne perturbe pas les autres Pour cela une bande de
freacutequence est alloueacutee Par exemple pour la radio FM la bande de freacutequence va de 875 Mhz agrave 108
Mhz
Dans leur bande de freacutequence les dispositifs peuvent se partager le support de diffeacuterentes
maniegraveres
FDM (Frequency Division Multiplexing) Ce mode utilise une partie du spectre (bande de
freacutequence) en permanence Exemple Radio FM
TDM (Time Division Multiplexing) Ce mode utilise tout le spectre (bande de freacutequence) par
intermittence Exemple GSM on a laquo 8 time slots raquo par canal
CDMA (Code Division Multiple Access) Ce mode utilise tout le spectre tout le temps
Porteacutee (Range)
Deacutebit (Bandwidth)
| 8
Les Devices LoRa sont capables drsquoeacutemettre sur un mecircme canal en mecircme temps Le protocole LoRa
utilise une modulation tregraves similaire agrave la meacutethode 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 Plus
tard dans le cours nous expliquerons les diffeacuterences de la modulation LoRa
13 Notion drsquo eacutetalement de spectre utiliseacutee en LoRa Nous allons voir au travers drsquoun exercice comment il est possible drsquoutiliser tout le spectre en
permanence tout en eacutetant capable drsquoeffectuer plusieurs transactions simultaneacutees entre diffeacuterents
eacutemetteursreacutecepteurs Cette meacutethode est souvent appeleacutee laquo eacutetalement de spectre raquo car comme
son nom lrsquoindique elle a pour conseacutequence drsquoeacutetaler le spectre du signal transmis
La meacutethode consiste agrave utiliser des codes qui ont des proprieacuteteacutes matheacutematiques adapteacutees agrave notre
objectif Transmettre en mecircme temps sur la mecircme bande de freacutequence La matrice ci-dessous
donne par exemple 4 codes drsquoeacutetalement (1 par ligne)
Code Orthogonal User 0 1 1 1 1
Code Orthogonal User 1 1 -1 1 -1
Code Orthogonal User 2 1 1 -1 -1
Code Orthogonal User 3 1 -1 -1 1
Tableau 1 Matrice de Hadamart (matheacutematicien) dordre 4
Les proprieacuteteacutes de ces codes (1 1 1 1 1 -1 1 -1 1 1 -1 -1 1 -1 -1 1) ne sont pas expliqueacutees ici Nous
nous conterons de veacuterifier leur bon fonctionnement
131 Transmissions successives Chaque tableau ci-dessous repreacutesente une transmission qui est indeacutependante des autres elles ne
se deacuteroulent pas en mecircme temps On veacuterifie qursquoavec la mise en œuvre de laquo lrsquoeacutetalement de spectre raquo
chaque transmission arrive bien agrave destination avec le message qui avait eacuteteacute transmis Le premier
tableau est deacutejagrave rempli en guise drsquoexemple La meacutethode est la suivante
A lrsquoeacutemission
Chaque bit du message est multiplieacute par un code drsquoeacutetalement (une ligne de la matrice)
Le reacutesultat de la multiplication est transmis
A la reacuteception
Chaque symbole reccedilu est multiplieacute par le mecircme code drsquoeacutetalement
Le message reccedilu est eacutegal agrave la somme des symboles diviseacute par le nombre de symbole
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
hellip transmission hellip
4 Utilisation code orthogonal User 1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1
5 Deacutecodage = (3) x (4) 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0
6 Message reccedilu (sum (5) nbr_bits) 1 0 1 0
Reacutealiser la transmission du message du User 2 et du User 3 dans les tableaux suivants
| 9
1rsquo Message User 2 0 1 0 1
2rsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
3rsquo Symboles transmis User 2 = (1rsquo) x (2rsquo) 0 0 0 0
hellip transmission hellip
4rsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
5rsquo Deacutecodage = (3rsquo) x (4rsquo) 0 0 0 0
6rsquo Message reccedilu (sum (5rsquo) nbr_bits) 0
1rsquorsquo Message User 3 1 1 0 0
2rsquorsquo Utilisation code orthogonal User 3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
3rsquorsquo Symboles transmis User 3 = (1rsquorsquo) x (2rsquorsquo) 1 -1 -1 1
hellip transmission hellip
4rsquorsquo Utilisation code orthogonal User3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
5rsquorsquo Deacutecodage = (3rsquorsquo) x (4rsquorsquo) 1 1 1 1
6rsquorsquo Message reccedilu (sum (5rsquorsquo) nbr_bits) 1
132 Transmissions simultaneacutees
Les transmissions se deacuteroulent maintenant simultaneacutement les messages des User 1 User 2 et User
3 sont envoyeacutes en mecircme temps sur la mecircme bande de freacutequence La premiegravere colonne du User 1
est deacutejagrave remplie en guise drsquoexemple La meacutethode est la suivante
Dans lrsquoair
On additionne les symboles transmis par tous les User (1 2 3) ligne 1rsquorsquorsquo
Pour la reacuteception
Chaque symbole reccedilu est multiplieacute par le code drsquoeacutetalement du User
Le message reccedilu est eacutegal agrave la somme des symboles diviseacute par le nombre de symbole
Valider le fonctionnement pour la reacuteception des messages
1rsquorsquorsquo sum des symboles transmis ( 3 + 3rsquo + 3rsquorsquo ) 2 -2 0 0
2rsquorsquorsquo Utilisation code orthogonal User 1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 2 0 0
4rsquorsquorsquo Message reccedilu User 1 (sum (3rsquorsquorsquo) nbr_bits) 1
2rsquorsquorsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 -2 0 0
4rsquorsquorsquo Message reccedilu User 2 (sum (3rsquorsquorsquo) nbr_bits) 0
2rsquorsquorsquo Utilisation code orthogonal User 3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 2 0 0
4rsquorsquorsquo Message reccedilu User 3 (sum (3rsquorsquorsquo) nbr_bits) 1
133 Cas du protocole LoRa Le LoRa utilise une meacutethode drsquoeacutetalement de spectre qui nrsquoest pas exactement celle que nous venons
drsquoeacutetudier La finaliteacute est cependant la mecircme Pouvoir transmettre en mecircme temps sur le mecircme
canal Le protocole LoRa utilise sept laquo codes drsquoeacutetalement raquo appeleacutes Spreading Factor [ SF6 SF7 SF8
SF9 SF10 SF11 et SF12 ] qui lui permet drsquoavoir sept transmissions simultaneacutees sur un mecircme canal
| 10
2 Transmission radio et propagation
21 Les uniteacutes et deacutefinitions dB Rapport entre deux puissances Une atteacutenuation est repreacutesenteacutee par un nombre
neacutegatif (-) Un gain est repreacutesenteacute par un nombre positif (+)
Rapport de puissances en dB Rapport de puissance
+ 3 dB Multiplication par 2
- 3 dB Division par 2
0 dB Egaliteacute
+ 10 dB Multiplication par 10
- 10 dB Division par 10
Tableau 2 Comparaison entre les gains en dB et en proportion
dBi Gain theacuteorique drsquoune antenne
dBm Puissance rameneacutee agrave 1mW 0 dBm correspond agrave 1 mW
En reprenant la deacutefinition des dB remplir le tableau suivant
Puissance en dBm Puissance en mW
+ 3 dBm
- 3 dBm
+ 10 dBm
- 10 dBm
Tableau 3 Comparaison entre les puissances en dB et en mW
Le Talkie-Walkie a une puissance drsquoeacutemission de 2W Quelle est la puissance drsquoeacutemission
exprimeacutees en dBm
Sensibiliteacute Puissance minimale qursquoest capable de deacutetecter un reacutecepteur
RSSI Received Signal Strength Indication
SNR Signal over Noise Ratio
Un eacutemetteur transmet agrave une puissance de 13dBm en utilisant une antenne dont le gain
est de 2dBi Les pertes dans lrsquoair sont de 60 dB Lrsquoantenne reacuteceptrice qui possegravede un gain
de 2dBi est relieacutee agrave un reacutecepteur dont la sensibiliteacute est de -80 dBm Le signal pourra-t-il
ecirctre reccedilu
Le link Budget Crsquoest la quantiteacute de puissance que nous pouvons perdre avant drsquoarriver au
reacutecepteur tout en conservant une transmission fonctionnelle Autrement dit crsquoest la
puissance de lrsquoeacutemetteur moins la sensibiliteacute du reacutecepteur Dans lrsquoexemple preacuteceacutedent le
budget que nous avons agrave disposition est de 93dB
| 11
En LoRa nous avons un Link Budget de 157 dB
En LTE (4G) nous avons un Link Budget de 130 dB
Etude de la documentation drsquoun composant LoRa Le RN2483 est le composant radiofreacutequence que nous utiliserons dans notre transmission LoRa
Voici quelques une de ses caracteacuteristiques
Figure 3 Caracteacuteristiques principales du composant radiofreacutequence utiliseacute
Reprenez la deacutefinition du Link Budget et retrouver les 157 dB annonceacute dans cette
documentation
En LoRa plus le code drsquoeacutetalement est grand plus on est capable drsquoeacutemettre dans un milieu bruiteacute La
figure ci-dessous preacutesente les rapports signal sur bruit avec lesquels nous seront capable de reacutealiser
une transmission en fonction des Spreading Factor utiliseacutes
Figure 4 Influence du Spreading Factor sur le SNR acceptable
On remarque que pour un SF8 nous sommes capables drsquoeacutemettre avec un SNR de -10 dB On pourra
transmettre malgreacute le fait que le bruit est 10 fois supeacuterieur au signal
On remarque que pour un SF12 nous sommes capables drsquoeacutemettre avec un SNR de -20 dB On
pourra transmettre malgreacute le fait que le bruit est 100 fois supeacuterieur au signal
| 12
Cependant on remarque aussi que lrsquoutilisation drsquoun Spreading Factor plus eacuteleveacute augmente
consideacuterablement le nombre de symbole eacutemis (2egraveme colonne du tableau) Comme nous le verrons
plus tard cela impactera eacutevidement le temps de transmission
| 13
3 La couche physique LoRa
31 La modulation LoRa Comme nous lrsquoavons expliqueacute plus tocirct la modulation LoRa utilise lrsquoeacutetalement de spectre pour
transmettre ces informations Mais au lieu drsquoutiliser des codes drsquoeacutetalement (CDMA) elle utilise une
meacutethode appeleacutee Chirp Spread Spectrum La finaliteacute est toujours la mecircme Avoir plusieurs
transmissions dans le mecircme canal La conseacutequence sur le spectre est aussi la mecircme cela provoque
un eacutetalement du spectre
311 La forme du symbole (Chirp) Le signal eacutemis par la modulation LoRa est un symbole dont la forme de base est repreacutesenteacutee ci-
dessous Son nom (Chirp) vient du fait que ce symbole est utiliseacute dans la technologie Radar (Chirp
Compressed High Intensity Radar Pulse)
Figure 5 Symbole de la modulation LoRa (source Wikipeacutedia)
La freacutequence de deacutepart est la freacutequence centrale du canal moins la Bande Passante diviseacutee par deux
La freacutequence de fin est la freacutequence centrale plus la Bande Passante diviseacutee par deux
La freacutequence centrale est appeleacutee le canal
La bande passante est la largeur de bande occupeacutee autour du canal
On considegravere une eacutemission sur la freacutequence centrale 868 Mhz avec une Bande Passante
de 125 kHz Donner la freacutequence de deacutebut et la freacutequence de fin du sweep
Freacutequence de deacutebut
Freacutequence de fin
Pour faciliter la repreacutesentation de ce symbole on utilise plutocirct un graphique TempsFreacutequence de
la forme suivante
| 14
Figure 6 Forme du symbole de base (CHIRP)
En LoRa chaque symbole repreacutesente un certain nombre de bits transmis La regravegle est la suivante
Nombre de bits transmis dans un symbole = Spreading Factor
Par exemple si la transmission utilise un Spreading Factor de 10 (SF10) alors un symbole repreacutesente
10 bits
Crsquoest-agrave-dire qursquoagrave lrsquoeacutemission les bits sont regroupeacutes par paquet de SF bits puis chaque paquet est
repreacutesenteacute par un symbole particulier parmi 2119878119865formes de symboles possibles
Sur la figure suivante voici un exemple theacuteorique drsquoune modulation en SF2 agrave 868 Mhz sur une
bande passante de 125 kHz Chaque symbole repreacutesente donc 2 bits
Figure 7 Symboles eacutemis en Modulation LoRa (Cas theacuteorique en SF2)
Exemple
On considegravere la suite binaire suivante 0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Le Spreading Factor utiliseacute est SF10
Nous regroupons donc les bits par paquet de 10 Chaque paquet de 10 bits sera repreacutesenteacute par un
symbole (sweep) particulier Il y a 1024 symboles diffeacuterents pour coder les 1024 combinaisons
binaires possibles (210)
Freacutequence
Temps
868 000 000 Hz
868 062 500 Hz
Un symbole Un symbole
867 937 500 Hz
Temps
868 000 000 Hz
867 937 500 Hz
Symbole 0
Bits laquo 00 raquo
Symbole 1
Bits laquo 01 raquo
Symbole 2
Bits laquo 10 raquo Symbole 3
Bits laquo 11 raquo
12
5 k
Hz
868 062 500 Hz
| 15
Figure 8 Emission des Chirp en LoRa
Avec un outils drsquoanalyse spectrale actif pendant lrsquoeacutemission LoRa drsquoun Device on peut afficher les
successions de symbole qui sont envoyeacutes Cette oscillogramme a eacuteteacute reacutealiseacute agrave lrsquoaide drsquoun SDR
(Software Digital Radio)
Figure 9 Visualisation des Chirps LoRa reacuteellement eacutemis pendant une transmission
312 Dureacutee drsquoeacutemission drsquoun symbole En LoRa la dureacutee drsquoeacutemission de chaque symbole (Chirp) deacutepend du Spreading Factor utiliseacute Plus le
SF est grand et plus le temps drsquoeacutemission sera long Pour une mecircme bande passante le temps
drsquoeacutemission drsquoun symbole en SF8 est deux fois plus long que le temps drsquoeacutemission drsquoun symbole en
SF7 Ainsi de suite jusqursquoagrave SF12
0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Envoi de 1 Chirp Envoi de 1 Chirp Envoi de 1 Chirp
Transmission Transmission Transmission
| 16
Figure 10 Temps drsquoeacutemission drsquoun symbole (Chirp) en fonction du SF
En revanche le temps drsquoeacutemission drsquoun symbole est inversement proportionnel agrave la bande passante
119879119904 =2119878119865
119861119886119899119889119908119894119889119905ℎ Le deacutebit des symboles est donc de
1
119879119878= 119865119904 =
119861119886119899119889119908119894119889119905ℎ
2119878119865 En toute logique plus la
bande passant est eacuteleveacute plus le deacutebit des symboles sera eacuteleveacute Comme chaque symbole comprend
SF bit on retrouve alors le deacutebit binaire
119863119887 = 119878119865119861119886119899119889119908119894119889119905ℎ
2119878119865
Plus le Spreading Factor sera eacuteleveacute plus le deacutebit binaire sera faible
Plus la Bande Passante sera eacuteleveacutee plus le deacutebit binaire sera fort
Exemple Drsquoapregraves la formule du deacutebit binaire trouver le deacutebit pour les deux cas suivants
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
32 Coding Rate Le Coding Rate est un ratio qui augmentera le nombre de bits agrave transmettre afin de reacutealiser de la
deacutetection correction drsquoerreur Dans le cas drsquoun CR = 4 8 il y aura 8 bits transmis reacuteellement agrave
chaque fois que nous souhaitons transmettre 4 bits Dans cette exemple cela provoque une
transmission drsquoun nombre de bit multiplieacute par 2
SF7
Freacutequence
Temps
Freacutequence centrale
Freacutequence haute
Temps drsquoun symbole eacutemit en SF 12
Freacutequence basse
SF8
SF9
SF10
SF11
SF12
Temps drsquoun symbole eacutemit en SF 11
| 17
Figure 11 Influence du Coding Rate sur le nombre de bits ajouteacute
Si on reprend lrsquoexemple preacuteceacutedent avec un CR de 4 5 nous avons une augmentation de 125 du
nombre de bits agrave transmettre Redonner la deacutebit en prenant en compte le CR
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
La documentation du composant RN2483 donne les deacutebits en fonction du Spreading Factor
la Bande Passante et le Coding Rate Veacuterifier la coheacuterence du reacutesultat avec votre calcul
preacuteceacutedent
Figure 12 Deacutebit en fonction des paramegravetres de la transmission LoRa
33 Utilisation du LoRa Calculator Le logiciel laquo LoRa Calculator raquo est un petit exeacutecutable permettant de simuler une transmission LoRa
en fonction des caracteacuteristiques saisies Canal SF CR etchellip Il est teacuteleacutechargeable agrave lrsquoadresse
suivante httpsbitly2TyloAh
| 18
Figure 13 Le logiciel LoRa Calculator
En reprenant lrsquoexemple preacuteceacutedent (SF7 Bande Passante 125 kHz CR 45) veacuterifier les
calculs du laquo Equivalent Bitrate raquo
34 Time On Air La norme LoRaWAN impose qursquoun Device LoRa ne transmette pas plus de 1 du temps Cela est
repreacutesenteacute par un Duty Cycle Par exemple un Duty Cycle de 1 signifie que si jrsquoeacutemet pendant 1 je
ne dois plus eacutemettre pendant 99 quel que soit lrsquouniteacute de temps utiliseacutee
En reprenant les exemples preacuteceacutedents quels sont les deacutebits moyens si on prend en compte
le laquo Time On Air raquo
Cas 1 Pour SF7 et 125 khz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
Dans le logiciel laquo LoRa Calculator raquo (onglet laquo Energy Profile raquo) nous pouvons estimer la
dureacutee de vie drsquoune batterie Nous prenons lrsquoexemple drsquoun releveacute de tempeacuterature dans un
bacirctiment avec les caracteacuteristiques suivantes
| 19
SF CR Bande Passante etc Nous nous placcedilons dans le cas 1 des exemples preacuteceacutedents
Le releveacute de tempeacuterature se fera toutes les 15 mins
La batterie est constitueacute de 3 petites piles bacirctons [ AAA LR03 ] 12V en seacuterie Soit 36 V
1000 mAh
35 Mise en œuvre LoRa en point agrave point Ce test sera reacutealiseacute avec des modules LoRa RN2483 (Microchip) et une carte microcontrocircleur
ARDUINO
Figure 14 Communication LoRa en Point agrave Point
Reacutealiser le cacircblage de votre module RN2483 suivant le tableau suivant
Connecteur Arduino Click Board RN2483
5V 5V
GND GND
11 RX
10 TX
Tableau 4 Cacircblage de lrsquoARDUINO et de la click Board RN2483
351 Utilisation de lrsquoIDE Arduino Lrsquoenvironnement Arduino est tregraves simple Nous allons reacutealiser un programme pour montrer son
fonctionnement
La connexion de la carte est effectueacutee agrave lrsquoaide drsquoun port USB qui eacutemule une liaison seacuterie
RS232 Il faut donc choisir le bon port Arduino IDE gt Outils gt Port
Pour creacuteer un nouveau programme (sketch) Arduino IDE gt Fichier gt Nouveau
Il y a deux parties dans un sketch
Une fonction setup() qui sera exeacutecuteacutee qursquoune seule fois au deacutemarrage
Une fonction loop() qui sera exeacutecuteacutee en boucle
Ecrire le code suivant
Emetteur
Reacutecepteur
UA
RT
UA
RT
| 20
void setup()
Serialbegin(9600)
void loop()
Serialprintln(hello word)
Compiler et Teacuteleacuteverser Croquis gt Teacuteleacuteverser
Voir la sortie sur la liaison seacuterie Outils gt Moniteur Seacuterie gt Choisir la vitesse de
transmission ici 9600 bauds (en bas agrave droite)
352 Validation du fonctionnement Deux binocircmes joueront le rocircle drsquoeacutemetteur tous les autres binocircmes seront en reacutecepteur
Reacutecupeacuterer les programmes dans Moodle dans le dossier laquo RN2483-Arduino-Point2Point raquo
Installer la librairie RN2483 Arduino IDE gt Croquis gt Inclure une bibliothegraveque gt Ajouter la
bibliothegraveque zip
Reacutepartissez les rocircles Emetteurs Reacutecepteurs et reacutecupeacuterer le programme LoraBlinkerRX ou
LoraBlinkerTX en fonction Les 2 binocircmes en eacutemission devront modifier le code du sketch
Arduino pour transmettre des donneacutees speacutecifiques afin de les diffeacuterencier [
loraSerialprintln(radio tx 30) ]
Validez la reacuteception des donneacutees eacutemises par les deux binocircmes qui transmettent des
donneacutees Ces donneacutees reccedilues sont eacutecrite agrave 57600 bauds sur le moniteur seacuterie de lrsquoArduino
353 Mise en valeur du Spreading Factor On srsquoaperccediloit dans la manipulation preacuteceacutedente que les Devices LoRa reccediloivent les donneacutees des deux
eacutemetteurs Nous allons conserver le mecircme canal drsquoeacutemission (8691 Mhz) mais un des deux
eacutemetteurs va modifier son laquo Spreading Factor raquo La salle sera donc seacutepareacutee en deux groupes
1er groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF7
2egraveme groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF8
Validez la reacuteception des donneacutees eacutemises seulement pour le Spreading Factor que vous
utilisez
| 21
4 Le protocole LoRaWAN
Le LoRa est le type de modulation utiliseacute entre deux Devices ou entre un Device et une Gateway
Lorsque nous parlons de lrsquoensemble de la chaine de communication (Device Gateway Serveur) alors
nous parlons de communication LoRaWAN Nous allons voir lrsquoarchitecture drsquoun reacuteseau LoRaWAN
ainsi que les regravegles de ce protocole
41 Structure drsquoun reacuteseau LoRaWAN Nous retrouvons drsquoun cocircteacute le Device LoRa qui transmet une donneacutee Elle est reacuteceptionneacutee agrave lrsquoautre
extreacutemiteacute du reacuteseau par un Utilisateur La structure globale du reacuteseau LoRaWAN peut ecirctre
repreacutesenteacutee par la figure suivante
411 Les Devices LoRa Les Devices LoRa sont des systegravemes eacutelectroniques appartenant au monde de lrsquoIoT Faible
consommation faible taille faible puissance et faible taille
Ils possegravedent une radio LoRa permettant de joindre les Gateways Les Gateways ne sont pas
adresseacutees speacutecifiquement toutes celles preacutesentes dans la zone de couverture reccediloivent les
messages et les traitent
412 Les Gateways LoRa Elles eacutecoutent sur tous les canaux et sur tous les Spreading Factor Lorsqursquoune trame LoRa est reccedilue
elle transmet son contenu sur internet agrave destination du Network Server qui a eacuteteacute configureacute dans la
Gateway au preacutealable
Elle joue donc le rocircle de passerelle entre une modulation LoRa et une communication IP
Devices
LoRa Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
Internet Internet
Figure 15 Structure globale dun reacuteseau LORAWAN
| 22
Chaque Gateway LoRa possegravede un identifiant unique (EUI sur 64 bits)
413 Le Network Server
Le Network Server reccediloit les messages transmis par les Gateways et supprime les doublons
(plusieurs Gateway peuvent avoir reccedilu le mecircme message) Les informations transmises au Network
Server depuis les Devices LoRa sont authentifieacutes gracircce agrave une cleacute AES 128 bits appeleacutee Network
Session Key NwkSKey Nous parlons bien ici drsquoauthentification et non pas de chiffrement comme
nous le verrons plus tard
414 Application Server Il est souvent sur le mecircme support physique que le Network Server Il permet de dissocier les
applications les unes des autres Chaque application enregistre des Devices LoRa qui auront le droit
Devices Gateways Network
Server
Internet
Network Session Key (NwkSKey)
Authentification
Figure 17 Authentification entre le Device LoRa et le Network Server
Internet
UDP IP
Modulation
LoRa
Device LoRa
Gateway
Network Server
LoRaWAN
Modulation
LoRa
Passerelle LoRa Internet
Internet
UDP IP
LoRaWAN
Transmission Radio
Application Application
Figure 16 Le rocircle de la Gateway LoRa
| 23
de stocker leurs donneacutees (Frame Payload) Les message transmis agrave lrsquoapplication server sont chiffreacutes
gracircce agrave une cleacute AES 128 bits appeleacutee Application Session Key AppSKey
Le scheacutema suivant reacutesume lrsquoutilisation
De la Network Session Key (NwkSKey) pour lrsquoauthentification entre le Device LoRa et le
Network Server
De lrsquoApplication Session Key (AppSKey) pour le chiffrement entre le Device LoRa et
lrsquoApplication Server
Devices Gateways Network
Server Application
Server
Internet
Application Session Key (AppSKey)
Chiffrement
Figure 18 Chiffrement entre le Device LORA et lrsquoApplication Server
| 24
415 Application Web Serveur Cette application doit drsquoune part reacutecupeacuterer les donneacutees de lrsquoApplication Serveur Dans le cadre de
ce cours cela sera fait de deux faccedilons
Avec le protocole HTTP
Avec le protocole MQTT
Figure 20 Application Web Server
Figure 19 Authentification et chiffrement en LoRaWan
Devices Gateways
Network
Server Application
Server
Internet
Network Session Key
Application Session Key
Network
Server Application
Server
Application
Server Web
Utilisateur
Protocole
MQTT ou HTTP
Flux Uplink
Flux Downlink
| 25
Le flux habituel dans lrsquoIoT est le flux Uplink (flux montant) crsquoest-agrave-dire lrsquoeacutemission de donneacutees des
objets vers le serveur Comme nous lrsquoexpliquerons plus loin en LoRaWAN il est aussi possible de
transfeacuterer des donneacutees aux Device LoRa par un flux Downlink (flux descendant)
Drsquoautre part lrsquoapplication mettra agrave disposition les donneacutees aux utilisateurs sous forme par exemple
drsquoun serveur web drsquoune base de donneacutees et drsquoune visualisation graphique
416 Authentification avec le Network Server La Network Session Key (NwkSKey) sert agrave lrsquoauthentification entre le Device LoRa e le Network Server
Afin de reacutealiser cette authentification entre le Device et le Network Server un champ MIC (Message
Integrity Control) est rajouteacute agrave la trame Il est calculeacute en fonction des donneacutees transmises et du
NwkSkey A la reacuteception le mecircme calcul est effectueacute Si les cleacutes sont eacutequivalentes dans le Device et
dans le Network Server alors les deux MIC calculeacutes doivent correspondre
417 Chiffrement des donneacutees vers lrsquoApplication Server
LrsquoApplication Session Key (AppSKey) sert pour le chiffrement entre le Device LoRa et lrsquoApplication
Server Les donneacutees chiffreacutees seront alors deacutecodeacutees agrave la reacuteception sur lrsquoApplication Server srsquoil
possegravede la mecircme cleacute Si on reprend le scheacutema preacuteceacutedent les laquo donneacutees x raquo sont chiffreacutees
deacutechiffreacutees par le processus suivant
Donneacutees x chiffreacutees NwkSkey x
MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees
NwkSkey x
Trame eacutemise Trame reccedilue
Device LoRa Network Server
Si =
Alors la trame est authentifieacutee
MIC geacuteneacutereacute Emission MIC geacuteneacutereacute Reacuteception
MIC geacuteneacutereacute Reacuteception
Figure 21 Authentification dun Device LoRa par le Network Server
| 26
Figure 22 Chiffrement des donneacutees par lApplication Session Key
418 Combinaison de lrsquoauthentification et du chiffrement On peut maintenant repreacutesenter sur le mecircme scheacutema la construction de la trame LoRaWAN avec
drsquoune part lrsquoauthentification et drsquoautre part le chiffrement
Figure 23 Chiffrement puis Authentification
42 Classes des Devices LoRaWAN Les Devices LoRa sont classeacutes en 3 cateacutegories (A B C) en fonction de leur consommation et de leur
accessibiliteacute en Downlink crsquoest-agrave-dire la faciliteacute qursquoun utilisateur aura agrave transmettre une trame au
Device LoRa
421 Classe A (All) Minimal power Application Tous les Devices LoRaWAN sont de classe A Chaque Device peut transmettre (Uplink) agrave la Gateway
sans veacuterification de la disponibiliteacute du reacutecepteur Si la transmission eacutechoue elle sera reacuteeacutemise apregraves
un certain temps Cette transmission est suivie de 2 fenecirctres de reacuteception tregraves courtes La Gateway
peut alors transmettre pendant le laquo RX Slot 1 raquo ou le laquo RX Slot 2 raquo mais pas les deux
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Device LoRa
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Application Server
Donneacutees non chiffreacutees
AppSKey
Donneacutees chiffreacutees Entecircte
NwkSKey
MIC geacuteneacutereacute en eacutemission Trame transmise =
| 27
Figure 24 Slots de reacuteception pour un Device LoRa de classe A
Source de lrsquoimage httpszakelijkforumkpncom
La dureacutee des fenecirctres doit ecirctre au minimum la dureacutee de reacuteception drsquoun preacuteambule Un preacuteambule
dure 1225 Tsymbole et deacutepend donc du Data Rate (DR voir paragraphe 445 pour plus drsquoinformation
sur le DR) Lorsque qursquoun preacuteambule est deacutetecteacute le reacutecepteur doit rester actif jusqursquoagrave la fin de la
transmission Si la trame reccedilue pendant la premiegravere fenecirctre de reacuteception eacutetait bien agrave destination du
Device LoRa alors la deuxiegraveme fenecirctre nrsquoest pas ouverte
Premiegravere fenecirctre de reacuteception
Le Slot RX1 est programmeacute par deacutefaut agrave 1 seconde + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont les mecircme que ceux choisis lors de la phase drsquoeacutemission
(Uplink)
Seconde fenecirctre de reacuteception
Le Slot RX2 est programmeacute par deacutefaut agrave 2 secondes + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont configurables mais fixes
Un Device LoRa qui est uniquement de classe A ne peut pas recevoir srsquoil nrsquoa pas eacutemis Il
nrsquoest donc pas joignable facilement
422 Classe B (Beacon) Scheduled Receive Slot Les Devices de classe B ont le mecircme comportement que les Devices de classe A mais drsquoautres
fenecirctres de reacuteceptions sont programmeacutees agrave des peacuteriodes preacutecises Afin de synchroniser les fenecirctres
de reacuteception du Device LoRa la Gateway doit transmettre des balises (Beacons) de faccedilon reacuteguliegravere
| 28
Figure 25 Slots de reacuteception pour un Device LoRa de classe B
Source de lrsquoimage httpszakelijkforumkpncom
Un Device LoRa de classe B est joignable reacuteguliegraverement sans qursquoil soit neacutecessairement
obligeacute drsquoeacutemettre En revanche il consomme plus qursquoun Device de classe A
423 Classe C (Continuous) Continuously Listening Les Devices de classe C ont des fenecirctres de reacuteception constamment ouvertes entre 2 Uplinks Ces
Devices consomment donc beaucoup plus
Figure 26 Slots de reacuteception pour un Device LoRa de classe C
Source de lrsquoimage httpszakelijkforumkpncom
| 29
Un Device LoRa de classe C est joignable en permanence En revanche crsquoest la classe de
Device qui est la plus eacutenergivore
424 Quelle Gateway pour les flux Downlink
Nous avons donc vu que le fonctionnement classique du protocole LoRaWAN eacutetait de reacutecupeacuterer de
lrsquoinformation depuis le Device LoRa Crsquoest le flux Uplink
Dans le cas ougrave lrsquoutilisateur transmet des informations au Device LoRa (flux Downlink) on peut se
demander quelle Gateway sera choisie pour transfeacuterer les donneacutees au Device LoRa En effet
lrsquoendroit ougrave est situeacute le Device LoRa nrsquoest pas neacutecessairement connu agrave lrsquoavance
La Gateway utiliseacutee pour le Downlink est celle qui a reccedilu le dernier message du Device
LoRa Un message ne pourra jamais arriver agrave destination drsquoun Device LoRa si celui-ci nrsquoa
jamais transmis quel que soit sa classe A B ou C
43 Activation des Devices LoRa et seacutecuriteacute En LoRaWAN les trois eacuteleacutements indispensables pour la communication sont le DevAddr pour
lrsquoindentification du Device ainsi que deux cleacutes le NwkSKey pour lrsquoauthentification et lrsquoAppSKey
pour le chiffrement Deux meacutethodes sont possibles pour fournir ces informations agrave la fois au Device
LoRa et au serveur
Activation By Personalization APB
Over The Air Activation
431 ABP Activation By Personalization Crsquoest la plus simple des meacutethodes Crsquoest donc peut ecirctre celle que nous avons tendance agrave utiliser lors
drsquoun test de prototype et drsquoune mise en place de communication LoRaWAN
Le Device LoRa possegravede deacutejagrave le DevAddr lrsquoAppSKey et le NwkSKey
Le Network server possegravede deacutejagrave le DevAddr et le NwkSKey
Lrsquoapplication serveur possegravede deacutejagrave le DevAddr et le AppSKey
En ABP toutes les informations neacutecessaires agrave la communication sont deacutejagrave connues par le
Device LoRa et par le Serveur
| 30
432 OTAA Over The Air Activation Crsquoest la meacutethode qursquoil faut privileacutegier car crsquoest celle qui est la plus seacutecuriseacutee Le Device LoRa doit
connaitre le DevEUI lrsquoAppEUI et lrsquoAppkey Le Network Server doit lui connaitre la mecircme Appkey
Tous les eacuteleacutements noteacutes EUI (Extended Unique Identifier) sont toujours sur une taille de
64 bits
Gracircce agrave ces informations de deacutepart et une neacutegociation avec le Network Server (Join Request) le
Device LoRa et le serveur vont geacuteneacuterer les informations essentielles DevAddr NwkSKey et
AppSKey
Figure 28 Obtention du DevAddr NwkSKey et AppSKey en OTAA
DevEUI Unique Identifier pour le device LoRa (Equivalent agrave une MAC sur Ethernet)
Certains Device LoRa ont deacutejagrave un DevEUI fourni en usine
AppEUI Unique Identifier pour lrsquoapplication server
DevEUI
AppEUI
AppKey
Join
Request
DevAddr
NwkSKey
AppSKey
Network Server
Application Server
Devices 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 2
NwkSkey 2
AppSKey 2
Devices 2
DevAddr 2
NwkSkey 2
AppSKey 2
Paramegravetres stockeacutes sur le serveur
Paramegravetres programmeacutes
dans le composant
Figure 27 Parameacutetrage de DevAddr NwkSKey et AppSKey
| 31
AppKey AES 128 cleacute utiliseacutee pour geacuteneacuterer le MIC (Message Code Integrity) lors de la Join
Resquest Il est partageacute avec le Network server
NwkSKey Utiliseacute pour lrsquoauthentification avec le Network Server
AppSKey Utiliseacute pour le chiffrement des donneacutees
433 Seacutecuriteacute Les cleacutes AES 128 bits permettent le chiffrement des informations transmises en LoRaWAN Malgreacute
ce chiffrement une attaque connue en Wireless est celle du REPLAY Crsquoest-agrave-dire que le Hacker
enregistre des trames chiffreacutees circulant sur le reacuteseau LoRa pour les reacuteeacutemettre plus tard Mecircme si
le Hacker ne comprend pas le contenu (les trames sont chiffreacutees) les donneacutees qui sont transporteacutees
sont elles bien comprises par lrsquoApplication Server Des actions peuvent donc ecirctre reacutealiseacutees
simplement par mimeacutetisme
Pour eacuteviter cela la trame LoRaWAN integravegre un champ variable appeleacute laquo Frame Counter raquo Il srsquoagit
drsquoun nombre numeacuterotant la trame sur 16 ou 32 bits LrsquoApplication Server acceptera une trame
uniquement si le laquo Frame Counter raquo reccedilu est supeacuterieur au laquoFrame Counter raquo preacuteceacutedemment Donc
si le Hacker retransmet la trame telle qursquoelle le laquo Frame Counter raquo sera eacutequivalent donc la trame
sera refuseacutee Et comme la trame est chiffreacutee le Hacker nrsquoa pas moyen de savoir comment modifier
un champ de cette trame
Cette seacutecuriteacute impleacutementeacutee par les laquo Frame Counter raquo est inteacuteressante pour srsquoaffranchir drsquoune
attaque par REPLAY mais dans nos tests cela peut poser problegraveme En effet agrave chaque fois que nous
redeacutemarrons le microcontrocircleur notre laquo Frame Counter raquo revient agrave zeacutero alors que celui de
lrsquoApplication Server continue de srsquoincreacutementer Cela peut ecirctre reacutesolue par diffeacuterentes maniegraveres
1 Deacutesactivation du laquo Frame Counter Check raquo Dans certain Application Server cette option
peut ecirctre proposeacutee Bien sucircr il faudra garder en tecircte la faille de seacutecuriteacute que cela engendre
Network Server
Application Server
Devices LoRa
NwkSkey
AppSKey
NwkSkey
AppSKey Hacker
(1) (2)
(1) Ecoute
(2) Reacuteeacutemission
Figure 29 Attaque par REPLAY
| 32
Figure 30 Deacutesactivation du Frame Counter Check dans TTN
2 Utiliser lrsquoauthentification par OTAA au lieu de ABP En effet agrave chaque ouverture de session
en OTAA le laquo Frame Counter raquo est reacuteinitialiseacute coteacute serveur
3 Conserver la valeur du laquo Frame Counter raquo dans une meacutemoire non volatile et reacutecupeacuterer sa
valeur au deacutemarrage du Device LoRa
44 La Trame LoRa LoRaWAN
441 Les couches du protocole LoRaWAN
Lorsque nous avons fait une communication en Point agrave Point nous avons simplement utiliseacute la
couche physique de la modulation LoRa Lorsque nous souhaitons utiliser le protocole LoRaWAN
des couches protocolaires suppleacutementaires se rajoutent
Figure 31 Les couches protocolaires du LoRaWAN
Chaque couche rajoute un service Lors de lrsquoenvoi de la trame les donneacutees utilisateurs sont donc
encapsuleacutees dans chaque couche infeacuterieure jusqursquoagrave la transmission Le deacutetail de lrsquoensemble de la
trame LoRaWAN par couche est deacutecrit sur la figure Figure 32
LoRa Modulation
LoRa Mac
Application
Couche Physique
Couche Mac
Couche Application
| 33
442 Couche Application La couche Application accueille les donneacutees de lrsquoutilisateur Avant de les encapsuler elles sont
chiffreacutees avec lrsquoAppSKey afin de seacutecuriser la transaction
Un ensemble de champs nommeacute Frame Header permet de speacutecifier le DevAddr le Frame Control
le Frame Counter et le Frame Option
Le Frame Port deacutepend du type drsquoapplication et sera choisi par lrsquoutilisateur
Le Frame Payload sont les donneacutees chiffreacutees agrave transmettre Le nombre drsquooctets maximum pouvant
ecirctre transmis (N octets) est donneacute dans le tableau suivant
PHY Payload
P octets Couche
Physique
Couche
Mac
Couche
Application
CRC
2 octets Header + Header CRC
20 bits Preamble
MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Figure 32 Trame LORAWAN complegravete par couche protocolaire
Couche
Application Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Frame Header
Figure 33 Trame LORA couche Applicative
| 34
Data Rate Spreading Factor Bandwidth Max Frame Payload (Nombre N) DR 0 SF12 125 KHz 51 octets
DR 1 SF11 125 KHz 51 octets
DR 2 SF10 125 KHz 51 octets
DR 3 SF9 125 KHz 115 octets
DR 4 SF8 125 KHz 222 octets
DR 5 SF7 125 KHz 222 octets
DR 6 SF7 250 KHz 222 octets
Tableau 5 Taille maximum du Frame Payload en fonction du Data Rate
443 Couche LoRa MAC Cette trame est destineacutee au Network Server Elle est authentifieacutee gracircce au champ MIC (Message
Integrity Protocol) selon la meacutethode expliqueacutee au paragraphe 416
Le protocole LoRa MAC est composeacute de
1 MAC Header Version de protocole et type de message
Type de Message Description 000 Join-Request
001 Join-Accept
010 Unconfirmed Data Up
011 Unconfirmed Data Down
100 Confirmed Data Up
101 Confirmed Data Down
110 Rejoin-request
111 Proprietary
Tableau 6 Les types de messages transmis en LoRaWAN
2 MAC Payload Contient tout le protocole applicatif
3 MIC Message Integrity Code pour lrsquoauthentification de la trame
444 Couche physique Modulation LoRa
Le choix du moment drsquoeacutemission des Devices LoRa se fait de faccedilon simple Lorsqursquoun eacutequipement
doit eacutemettre il le fait sans controcircle et ne cherche pas agrave savoir si le canal est libre Si le paquet a eacuteteacute
perdu il le retransmettra simplement au bout drsquoun temps aleacuteatoire La couche physique est
repreacutesenteacutee par lrsquoeacutemission de la trame suivante
Couche
Mac MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Figure 34 Trame LORA couche LORA MAC
| 35
Le Preacuteambule est repreacutesenteacute par 8 symboles + 425 Le temps du Preacuteambule est donc de 1225
Tsymbole
Len-tecircte (Header optionnel) est seulement preacutesent dans le mode de transmission par deacutefaut
(explicite) il est transmis avec un Coding Rate de 48 Il indique la taille des donneacutees le Coding Rate
pour le reste de la trame et il preacutecise eacutegalement si un CRC sera preacutesent en fin de trame
Le PHY Payload contient toutes les informations de la Couche LoRa MAC
Le CRC sert agrave la deacutetection drsquoerreur de la trame LoRa
445 Canaux et bandes de freacutequences et Data Rate (DR) Le LoRa utilise des bandes de freacutequences diffeacuterentes suivant les reacutegions du monde En Europe la
bande utiliseacutee est celle des 868 Mhz [ De 863 Mhz agrave 870 Mhz ] Le LoRaWAN deacutefinie les 8 canaux agrave
utiliser pour communiquer avec une Gateway suivant le tableau suivant
Canaux Spreading Factor Bandwidth 8681 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz SF7 250 kHz
8685 Mhz De SF7 agrave SF12 125 kHz
8671 Mhz De SF7 agrave SF12 125 kHz
8673 Mhz De SF7 agrave SF12 125 kHz
8675 Mhz De SF7 agrave SF12 125 kHz
8677 Mhz De SF7 agrave SF12 125 kHz
8679 Mhz De SF7 agrave SF12 125 kHz
Tableau 7 Canaux SF et Bandwidth de notre Gateway LoRaWAN
Une Gateway LoRa eacutecoute donc sur 8 canaux simultaneacutement avec les 6 Spreading Factor
diffeacuterents soit 48 combinaisons possibles
Comme nous lrsquoavons vu le Spreading Factor a des conseacutequences sur le deacutebit de la transmission Ces
deacutebits sont noteacutes DR (Data Rate) et sont normaliseacutes de DR0 agrave DR6
PHY Payload
P octets Couche
Physique CRC
2 octets Header + Header CRC
( Optionnel ) 20 bits Preamble
Figure 35 Trame LORA couche Physique
| 36
Data Rate Spreading Factor Bandwidth DR 0 SF12 125 KHz
DR 1 SF11 125 KHz
DR 2 SF10 125 KHz
DR 3 SF9 125 KHz
DR 4 SF8 125 KHz
DR 5 SF7 125 KHz
DR 6 SF7 250 KHz
Tableau 8 Deacutenomination DR en fonction du SF et de la Bande Passante
446 Trame reccedilue et transmise par la Gateway LoRaWAN La Gateway reccediloit drsquoun cocircteacute un message radio moduleacute en LoRa et transmet de lrsquoautre cocircteacute une trame
IP agrave destination du Network Server
Coteacute interface Radio La Gateway reacuteceptionne une trame LoRaWAN et extrait le PHY Payload Celui-
ci est codeacute au format ASCII en base 64 (voir le paragraphe 541) La Gateway extrait aussi toutes les
informations utiles sur les caracteacuteristiques de la reacuteception qui a eu lieu SF Bandwidth RSSI Time
On Airhellipetchellip
Coteacute interface reacuteseau IP La Gateway transmet lrsquoensemble de ces informations dans un paquet IP
(UDP) au Network Server Les donneacutees transmises sont du texte en format JSON (voir paragraphe
447) La Gateway a donc bien un rocircle de passerelle entre le protocole LoRa drsquoun cocircteacute et un reacuteseau
IP de lrsquoautre
Internet
UDP IP
Device LoRa
Gateway
Network Server Modulation
LoRa
Passerelle LoRa Internet
Transmission Radio Internet
Figure 36 Rocircle de la Gateway LoRa
| 37
447 Le format JSON Le format JSON est un format texte composeacute drsquoune succession de couple nomvaleur Dans
lrsquoexemple de la figure preacuteceacutedente gw_id est un nom et eui-b827ebfffeae26f5 est la valeur
associeacutee Dans cette exemple la valeur est un string Les objets sont deacutelimiteacutes par un des accolades
et
Une valeur peut ecirctre
Un string exemple coding_rate 45
Un nombre exemple spreading_factor 12
Un objet exemple lora spreading_factor 12 air_time 2465792000
Un Boolean
Ethernet
Gateway
Modulation
LORA
Reacutecupeacuteration du PHY PAYLOAD en base 64
Reacutecupeacuteration des caracteacuteristiques de la transmission Canal SF CR hellip
IP (IP dest routereuthethingsnetwork)
UDP (Port dest 1700 Port source 1700)
Donneacutees applicatives (format JSON)
gw_id eui-b827ebfffeae26f5
payload QNAPvA6Ax3ECqHk4C8hfzuA==
lora
spreading_factor 12
bandwidth 125
air_time 2465792000
coding_rate 45
timestamp 2019-01-20T133746017Z
rssi -105
snr -162
dev_addr 0EBC0FD0
frequency 867100000
Internet Transmission Radio LORA
Figure 37 Passerelle (Gateway) LORAWAN
| 38
5 Mise en œuvre drsquoun reacuteseau LoRaWAN
51 Les diffeacuterents types de reacuteseaux Les reacuteseaux LoRaWAN peuvent ecirctre utiliseacute suivant deux meacutethodes
En utilisant les reacuteseaux LoRaWAN opeacutereacutes proposeacutes par les opeacuterateurs de teacuteleacutecoms
En utilisant votre propre reacuteseau LoRaWAN priveacute
511 Les reacuteseaux LoRaWAN opeacutereacutes Ce sont des reacuteseaux LoRaWAN proposeacutes par les opeacuterateurs Par exemple Objenious (filiale de
Bouyges) ou encore Orange Dans le cas de lrsquoutilisation des reacuteseaux opeacutereacutes lrsquoutilisateur a juste
besoin de srsquooccuper des Devices LoRa Les Gateways le Network Server et lrsquoApplication Server sont
geacutereacutes par lrsquoopeacuterateur
512 Les reacuteseaux LoRaWAN priveacutes Chacun est libre de reacutealiser son propre reacuteseau priveacute en impleacutementant sa propre Gateway pour
communiquer avec ses Devices LoRa Lrsquoimpleacutementation du Network Server et de lrsquoApplication Server
peuvent alors ecirctre envisageacutes de diffeacuterentes faccedilons
Network Server et Application serveur priveacutees Crsquoest le deacuteveloppeur qui les mets en place Dans
certaines Gateways une impleacutementation de ces deux serveurs est deacutejagrave proposeacutee Sinon il est
possible de la mettre en place Il existe des serveurs (Network et Application) open source crsquoest le
cas par exemple de LoRa Serveur [ wwwloraserverio ]
Une autre alternantive est httpsgithubcomgotthardplorawan-server
LoRaServer et lorawan-server sont deux applications Open Source
Network Server et Application Server en ligne Un certain nombre de Network Server et
drsquoApplication Server sont proposeacutes Ce sont des services payants ou avec des contreparties
Loriot [ wwwloriotio ]
ResIoT [ wwwresiotio ]
The Things Network [ wwwthethingsnetworkorg ] Crsquoest la solution que nous utiliserons
513 Les zones de couvertures
Les zones de couvertures des reacuteseaux opeacutereacutes sont mise agrave jour par les opeacuterateurs celle drsquoobjenious
est par exemple disponible ici httpsobjeniouscomreseau
Pour connaitre la zone de couverture de notre Gateway utiliseacutee avec TTN nous pouvons utiliser
lrsquoapplication TTN Mapper httpsttnmapperorg Lrsquoideacutee est de promener son Device LoRa associeacute
agrave un GPS dans la zone de couverture des Gateway qui nous entourent A chaque trame reccedilue par le
| 39
Serveur on note les coordonneacutees GPS du Device LoRa ainsi que la Gateway qui a transmis le
message Toutes ces informations sont alors retranscrites sur une carte
52 The Things Network (TTN)
521 Preacutesentation de TTN
Pour la suite nous utiliserons le Network Server et lrsquoApplication Server fourni par TTN
[wwwthethingsnetworkorg]
TTN est gratuit et Open Source En revanche le fait drsquoutiliser TTN impose agrave ceux qui enregistrent
des Gateways de les mettre agrave disposition agrave tous les autres utilisateurs de TTN Lrsquoobjectif est de
reacutealiser un reacuteseau global ouvert
522 Configuration de la Gateway A lrsquouniversiteacute nous avons deux Gateways LoRa (Marque EBDS) Elles sont toutes les deux situeacutees sur
le Campus de Technolac Une Gateway est agrave lrsquointeacuterieur du bacirctiment ISERAN et sert essentiellement
pour les Travaux Pratiques et formations Lrsquoautre est sur le toit du bacirctiment Chablais et est mise agrave
disposition du public via le service de TTN
Les deux Gateway eacutecoutent sur tous les canaux et sur tous les Spreading Factor SF7 gt SF12
Lrsquo IP de la Gateway LoRa agrave lrsquouniversiteacute (bacirctiment ISERAN) est 192168140196
Serveur DNS 1934812032 19348129137
Network Server (TTN) 137616868 routereuthethingsnetwork
Port Upstream 1700 Port Downstream 1700
523 Enregistrement des Gateways Appplication et Devices La configuration de TTN se fait en ligne La premiegravere opeacuteration agrave reacutealiser lorsqursquoune nouvelle
Gateway est deacuteployeacutee crsquoest de lrsquoenregistrer dans TTN
Enregistrement drsquoune Gateway LoRa TTN gt Console gt Gateway gt register gateway
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Figure 38 Scheacutema de notre application
| 40
Figure 39 Enregistrement dune Gateway LoRa sur TTN
Enregistrement drsquoune application TTN gt Console gt Application gt add application
Figure 40 Enregistrement dune application sur TTN
Enregistrement des Devices LoRa dans lrsquoapplication Nom de lrsquoapplication gt register device
Figure 41 Enregistrement des Devices LoRa dans une application
524 Configuration des Devices LoRa Lorsque nous avons enregistreacute des Devices LoRa dans TTN nous devons choisir entre les deux modes
drsquoauthentification Dans un premier temps nous utiliserons le mode le plus simple qui est ABP Nous
geacuteneacuterons dans TTN les DevAddr NetwkSKey et AppSKey
| 41
Figure 42 Configuration des Devices LoRa en ABP dans TTN
53 Mise en application Nous avons dans notre application 10 Devices LoRa drsquoenregistreacutes aduino0 agrave arduino9 Ils sont tous
configureacutes en ABP Les configurations des 10 Devices (DevAddr NetwkSKey et AppSKey) sont noteacutes
en commentaire dans le code de vous allez reacutecupeacuterer
Reacutecupeacuterer le code Arduino laquo RN2483-Arduino-LORAWANino raquo dans Moodle
Modifier votre configuration (DevAddr NetwkSKey et AppSKey) en fonction de votre
numeacutero de binocircme
Veacuterifier que votre Device LoRa arrive bien agrave transmettre des informations (Uplink) vers la
Gateway puis vers le Network Serveur de TTN (The Things Network)
54 Analyse des trames eacutechangeacutees
541 Utilisation de la base 64 Notre Gateway nous preacutesente le Payload PHY en base64 Lrsquoexplication de la meacutethode de
repreacutesentation en base 64 est fourni au travers drsquoun exemple Le code hexadeacutecimal 0x4869
repreacutesente nos donneacutees binaires que nous souhaitons transmettre en base 64
1 On eacutecrit les donneacutees agrave transmettre en binaire
2 On regroupe les eacuteleacutements binaires par des blocs de 6 bits Le nombre de bloc de 6 bits doit
ecirctre un multiple de 4 (minimum 4 blocs) Srsquoil manque des bits pour constituer un groupe de
6 bits on rajoute des zeacuteros
0x4869 = 0100 1000 0110 1001
| 42
3 Srsquoil manque des blocs pour faire un minimum de 4 blocs des caractegraveres speacuteciaux seront
ajouteacutes
4 Chaque groupe de 6 bits est traduit par le tableau suivant (Source Wikipeacutedia)
Figure 43 Codage en base 64
5 Si un bloc de 6 bits manque (ils doivent ecirctre un multiple de 4) on rajoute un ou plusieurs
compleacutements (caractegravere laquo = raquo )
Reacutesultat Le codage de 0x4869 en base 64 est laquo SGk= raquo
010010 000110 100100
On ajoute 00 pour avoir
6 bits dans le groupe
Bloc de 6 bits
010010 000110 100100
S G k
010010 000110 100100
S G k =
1er Bloc
2egraveme Bloc
3egraveme Bloc
4egraveme Bloc
| 43
542 Inteacuterecirct et inconveacutenient de la base 64 Lrsquoutilisation de la base 64 est un choix qui a eacuteteacute fait pour le protocole LoRa LoRaWAN afin de rendre
les donneacutees binaires lisibles Le problegraveme du code ASCII crsquoest qursquoil est composeacute drsquoun certain nombre
de caractegraveres non imprimables (EOF CR LFhellip) Pour eacuteviter ces soucis la base 64 ne comporte que
64 caractegraveres imprimables (voir tableau ci-dessus)
La restriction agrave 64 caractegraveres a cependant un inconveacutenient crsquoest que nous ne pouvons coder que 6
bits (26=64) au lieu de 8 La base 64 est donc moins efficace drsquoune faccedilon geacuteneacuterale
Nous cherchons agrave coder le code ASCII laquo AA raquo en base 64 Retrouver la deacutemarche en
montrant que le reacutesultat en base 64 est laquo QUE= raquo
543 Uplink Du Device LoRa au Network Server Le Network Server de TTN reccediloit des trames IP en provenance de la Gateway Comme nous lrsquoavons
vu preacuteceacutedemment un certain nombre drsquoinformations peuvent ecirctre retrouveacutees avec cette trame
(DevAddr SF Bandwidth etchellip) mais les donneacutees Applicatives sont bien sucircr chiffreacutees (avec
lrsquoAppkSKey) A ce niveau de reacuteception (sans connaitre lrsquoAppSKey) il nrsquoest donc pas possible de
comprendre la totaliteacute du message reccedilu
Imaginons que la trame IP reccedilue 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 45
timestamp 2019-03-05T140042448Z
rssi -82
snr 9
dev_addr 26011AD3
frequency 867300000
Le Network Server affiche donc les informations de la faccedilon suivante
Figure 44 Trame reacutecupeacutereacutee sur le laquo Network Server raquo de TTN
Nous retrouvons bien les valeurs fournies par la Gateway
timestamp ( agrave 1 heure pregraves en fonction du fuseau horaire)
| 44
frequency 8673 Mhz
modulation Lora
Coding Rate 45
data Rate SF 7 125 kHz (DR5)
air time 463 ms
Drsquoautres information proviennent de lrsquoanalyse du Payload Le Payload inscrit ici est le PHY Payload
Il y a donc une partie chiffreacutee (Frame Payload) mais les entecirctes sont en claires (voir paragraphe
441) Ce PHY Payload est laquo QNMaASYABwAP1obuUHQ= raquo Lorsque celui-ci est exprimeacute en
hexadeacutecimal au lieu de la base 64 il vaut laquo 40D31A01260007000FD686EE5074 raquo comme le montre
le Network Server de TTN
Figure 45 PHY Payload preacutesenteacute dans notre Network Server
Sa taille est bien de 14 octets (en hexadeacutecimal) comme preacuteciseacute sur la Figure 44
Nous reprenons le format de la trame LoRaWAN vu agrave la Figure 32 Nous pouvons alors retrouver
tous les champs de toute la trame
PHYPayload = 40D31A01260007000FD686EE5074
PHYPayload = MAC Header[1 octet] | MACPayload[] | MIC[4 octets]
MAC Header = 40 (Unconfirmed data up)
MACPayload = D31A01260007000FD6
Message Integrity Code = 86EE5074
MACPayload = Frame Header | Frame Port | FramePayload )
Frame Header = D31A0126000700
FPort = 0F
FramePayload = D6
Frame Header = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[015]
DevAddr = 26011AD3 (Big Endian)
FCtrl (Frame Control) = 00 (No ACK No ADR)
FCnt (Frame Counter) = 0007 (Big Endian)
FOpts (Frame Option) =
Vous pouvez veacuterifier lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN
(LoRaWAN packet decoder) httpsbitly2szdXtv
| 45
Figure 46 LoRaWAN packet decoder
544 Uplink Du Network Server agrave lrsquoApplication Server
Nous reprenons lrsquoexemple de la trame ci-dessus (Figure 45) Pour information les cleacutes NwkSKey et
AppSKey suivantes ont eacuteteacute utiliseacutee
NwkSKey E3D90AFBC36AD479552EFEA2CDA937B9
AppSKey F0BC25E9E554B9646F208E1A8E3C7B24
Le Network Server a deacutecodeacute lrsquoensemble de la trame Si le MIC est correct (authentification de la
trame par le NwkSKey) alors le Network Server va passer le contenu du message chiffreacute (Frame
Payload) agrave lrsquoApplication Server Dans notre cas le Frame Payload est (drsquoapregraves le deacutecodage effectueacute
au chapitre preacuteceacutedent)
FramePayload = D6
D6 est le contenu chiffreacute lorsqursquoil est deacutechiffreacute avec lrsquoAppSkey on trouve 01 Vous pouvez veacuterifier
lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN httpsbitly2szdXtv
A noter que lrsquoApplication Server recevra les donneacutees chiffreacutees seulement si le Device LoRa a bien
eacuteteacute enregistreacute On peut aussi veacuterifier ci-dessous que lrsquoApplication Serveur de TTN nous retourne bien
un payload (Frame Payload) de 01
Figure 47 Trame reacutecupeacutereacutee sur lrsquoApplication Server de TTN
time 2019-03-05T140042379279991Z
frequency 8673
modulation LORA
data_rate SF7BW125
coding_rate 45
gateways [
gtw_id eui-b827ebfffeae26f6
timestamp 2447508531
time
channel 4
rssi -82
snr 9
latitude 4563647
longitude 58721523
| 46
location_source registry
]
545 Simulation drsquoUplink dans lrsquoApplication Server
Dans beaucoup de situations nous souhaitons valider le fonctionnement de lrsquoApplication Server de
TTN ouet de notre propre Application Il est donc tregraves utile de pouvoir simuler lrsquoenvoi drsquoune trame
LoRa sur lrsquoApplication Server sans que celle-ci soit reacuteellement eacutemise par un Device LoRa Pour cela
un outil existe dans les Settings de chaque Device enregistreacute dans TTN Nous avons juste besoin de
speacutecifier le Frame Payload en clair en hexadeacutecimal et le numeacutero de Port
Figure 48 Simulation drsquoune trame envoyeacutee par un Device LoRa
546 Downlink De lrsquoApplication Server au Device LoRa La communication LoRa est bidirectionnelle Des donneacutees peuvent ecirctre transmis au Device LoRa
depuis lrsquoApplication Server Depuis TTN un outil existe dans les Settings de chaque Device
enregistreacute Lrsquointerface est repreacutesenteacutee ci-dessous
Figure 49 Transmission de donneacutees de lrsquo laquo Application Server raquo jusqursquoau Device LoRa
Replace scheduling Mode Par deacutefaut le Frame Payload transmis remplacera le Frame
Payload en attente (si il existe) Dans ce mode un seul Frame Payload est planifieacute
First scheduling Mode Le Frame Payload est mis en file drsquoattente en premiegravere position
Last scheduling Mode Le Payload est mis en file drsquoattente en derniegravere position
Une demande de confirmation peut ecirctre demandeacutee au Device LoRa pour qursquoil preacutecise srsquoil a bien reccedilu
les donneacutees Lrsquooption laquo confirmed raquo permet donc de speacutecifier le type de trame dans le MAC Header
(voir paragraphe 443) laquo Confirmed Data Down raquo ou laquo Unconfirmed Data Down raquo dans notre cas
| 47
6 La reacutecupeacuteration des donneacutees sur notre propre Application
Nous utiliserons agrave nouveau le Network Server et Application Server de The Things Network Jusqursquoici
nous nous sommes contenteacute de veacuterifier que les donneacutees de lrsquoutilisateur (Frame Payload) soient bien
arriveacutees agrave destination dans lrsquoApplication Server Il faut maintenant les reacutecupeacuterer avec notre propre
Application qui aura pour rocircle
De stocker et traiter les donneacutees
De les mettre agrave disposition de lrsquoutilisateur (Serveur Web par exemple)
Drsquoenvoyer des commandes de lrsquoutilisateur aux Devices LoRa si besoin (Flux Downlink)
Nous allons voir deux meacutethodes pour communiquer entre notre application et TTN
Le protocole HTTP POST
Le protocole MQTT
61 Reacutecupeacuteration des donneacutees en HTTP POST dans lrsquoApplication
611 Preacutesentation du protocole HTTP
Dans le monde de lrsquointernet le protocole HTTP est tregraves utiliseacute pour le dialogue entre un client et un
serveur web Classiquement le client (un navigateur web par exemple) fait une requecircte HTTP GET
et le serveur lui retourne le contenu de la page web demandeacutee
Dans notre cas la probleacutematique est diffeacuterente car le client doit modifier le contenu du serveur
avec les donneacutees envoyeacutees par le Device LORA La requecircte srsquoappelle HTTP POST Son nom indique
que le client va poster (et on pas reacutecupeacuterer) des donneacutees
Lrsquoutilisateur qui souhaite reacuteceptionner des donneacutees sur son serveur doit donc concevoir un serveur
HTTP capable de traiter des requecirctes HTTP POST [ requecircte noteacutee (1) sur la Figure 51 ] fournies par
TTN Dans cette configuration TTN jouera le rocircle de client et notre application le rocircle de serveur
Devices
LORA Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
HTTP POST
MQTT Internet
Figure 50 Structure globale drsquoun reacuteseau LORAWAN
| 48
Figure 51 Communication bidirectionnelle entre TTN et notre Application
A lrsquoinverse lrsquoutilisateur qui souhaite transmettre des donneacutees agrave destination du Device LoRa
(Downlink) doit ecirctre capable de fournir une requecircte HTTP POST [ requecircte noteacutee (2) sur la Figure 51
] vers TTN Dans cette configuration TTN jouera le rocircle de Serveur et notre application le rocircle de
client
612 Fonctionnement drsquoun client et drsquoun serveur HTTP POST Afin de bien comprendre le fonctionnement des requecirctes HTTP POST nous allons proceacuteder par
eacutetape Le premier test que nous effectuerons sera decorreacuteleacute de TTN Le principe est le suivant
Utilisation drsquoun serveur HTTP disponible sur le web geacuterant les requecirctes HTTP POST [
httpsrbasketsin ] ou [ httpsbeeceptorcom ] par exemple
Utilisation drsquoun client HTTP eacutemettant des requecirctes HTTP POST commande curl sous linux
ou logiciel Postman [ wwwgetpostmancom ] sous windows par exemple
Ce test nous permet de valider le fonctionnement drsquoun serveur HTTP POST et drsquoun client HTTP POST
Une fois que nous serons sucircr de leur fonctionnement nous les utiliserons avec TTN
The Things Network
Application
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 49
Figure 52 Validation dun server HTTP POST et drsquoun client HTTP POST
613 Test du serveur HTTP POST Nous utiliserons un serveur web proposeacute par httpsrbasketsin
Aller sur le site httpsrbasketsin et creacuteer un nouveau laquo Basket raquo Zone ougrave vous pourrez
visualiser les requecirctes qui ont eacuteteacute eacutemises vers votre serveur
A partir de maintenant toutes les requecirctes dirigeacutees vers lrsquoadresse creacuteeacute seront traiteacutees et
srsquoafficheront Dans le menu de configuration il est aussi possible de deacutefinir le contenu de la reacuteponse
qui sera fournie
Deacutefinir un format de reacuteponse pour les requecirctes HTTP POST avec un body personnaliseacute
614 Test du client HTTP POST On peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande (la commande cURL
srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN sous Windows
Commande cURL curl ndashX POST ndashd lsquorsquodonneacutees agrave envoyerrsquorsquo DuServeurHTTP
Logiciel Postman New gt Request gt Creacuteer une requecircte HTTP POST gt Send
Veacuterifier que les requecirctes HTTP POST sont bien reacutecupeacutereacutees sur votre serveur creacutee preacuteceacutedemment
615 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST
Maintenant que nous avons un serveur HTTP (POST) fonctionnel nous allons configurer TTN pour
jouer le rocircle du client et pour qursquoil envoie des requecirctes HTTP POST vers notre Serveur degraves qursquoune
donneacutee drsquoun Device LoRa est disponible Nous geacuterons donc ici le flux Uplink
Requecircte
HTTP POST
Reacuteponse
(contenu parameacutetrable)
Client HTTP (POST)
Server HTTP (POST) [ httpsrbasketsin ]
| 50
Figure 53 Reacutecupeacuteration des donneacutees sur notre Application
Dans TTN nous inteacutegrons un bloc appeleacute laquo HTTP Integration raquo permettant de jouer le rocircle de client
crsquoest-agrave-dire drsquoenvoyer des requecirctes HTTP POST agrave destination de notre nouveau Serveur HTTP
Lrsquointeacutegration se faire agrave partir de TTN gt Console gt Application gt Nom_de_votre_application gt
Integration
Figure 54 Ajout dun client HTTP POST dans TTN
Pour valider le fonctionnement de notre architecture nous pouvons soit
Envoyer une trame depuis un Device LoRa vers TTN
Simuler lrsquoenvoi drsquoune trame drsquoun Device LoRa vers TTN (gracircce agrave lrsquooutil proposeacute par TTN vu
paragraphe 545)
Dans les deux cas voici un exemple de requecircte POST reccedilue sur notre serveur HTTP
app_id test_app_lorawan_sylvainmontagny
dev_id stm32lorawan_1
hardware_serial 0056AF49877
port 1
counter 0
payload_raw qg==
metadata
Requecircte
HTTP POST
Server HTTP (POST) [ httpsrbasketsin ]
The Things Network (Client)
La requecircte contient le Frame Payload deacutechiffreacutee
agrave transmettre agrave lrsquoApplication
| 51
time 2019-01-24T15243703499298Z
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Comme nous pouvons le voir le contenu fourni agrave notre serveur est formateacute en JSON (voir
paragraphe 0) Voici quelques compleacutements drsquoinformation
payload_raw Frame Payload deacutechiffreacute crsquoest donc les donneacutees en clairs dans la base 64
downlink_url URL du serveur HTTP POST qui serviront agrave transmettre des donneacutees au Device
LoRa (flux Downlink)
611 Envoyer des donneacutees depuis notre Application avec HTTP POST
Lorsque nous avons ajouteacute le bloc laquo HTTP Integration raquo au paragraphe preacuteceacutedent nous avons aussi
implicitement activeacute la fonctionnaliteacute que TTN soit precirct agrave recevoir et agrave traiter les requecirctes HTTP
POST La seule information qursquoil nous manque est lrsquoadresse du server HTTP vers lequel il faut eacutemettre
les requecirctes Si on observe la trame reccedilue preacuteceacutedemment en provenance de TTN on srsquoaperccediloit que
dans la trame JSON reccedilu une URL (downlink_url) est speacutecifieacutee
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Crsquoest cette URL que nous devrons utiliser Nous allons nous placer dans la configuration suivante
Figure 55 Envoi de donneacutees agrave partir de notre Application
Comme preacuteceacutedemment on peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande
(la commande cURL srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN
Commande cURL curl ndashX POST ndashdata lsquo dev_id Identidiant_De_Votre_Device
payload_raw AQE= rsquo DuServeurHTTP
Logiciel Postman New gt Request gt HTTP POST puis Body gt Raw gt JSON
Requecircte HTTP POST vers serveur TTN laquo downlink_url raquo httpsintegrationsthethingsnetworUaeb8ypKieQ
Contenu de la requecircte
dev_id Identidiant_De_Votre_Device
payload_raw aGVsbG8=
The Things Network (Serveur)
POSTMAN (Client HTTP POST)
| 52
dev_id YourDeviceID
payload_raw aGVsbG8=
Vous devez envoyer le texte (payload_raw) en base 64 Dans lrsquoexemple ci-dessus laquo aGVsbG8= raquo
correspond agrave la chaine de caractegravere laquo hello raquo Vous pouvez utiliser les nombreux encodeurdecodeur
en ligne pour vous aider Le texte doit srsquoafficher sur votre moniteur seacuterie Arduino dans le cadre de
notre deacutemonstrateur sur Arduino
62 Reacutecupeacuteration des donneacutees avec MQTT dans lrsquoApplication
621 Preacutesentation du protocole MQTT
MQTT est un protocole leacuteger qui permet de srsquoabonner agrave des flux de donneacutees Plutocirct que
lrsquoarchitecture Client Serveur classique qui fonctionne avec des Requecirctes Reacuteponses MQTT est
baseacute sur un modegravele Publisher Subscriber La diffeacuterence est importante car cela eacutevite davoir agrave
demander (Requecircte) des donneacutees dont on na aucune ideacutee du moment ougrave elles vont arriver Une
donneacutee sera donc directement transmise au Subscriber degraves lors que celle-ci a eacuteteacute reccedilue dans le
Broker (serveur central)
Figure 56 Modegravele Publisher Subscriber du protocole MQTT
Pour recevoir les donneacutees appartenant agrave un Topic un Subscriber doit souscrire (comme son nom
lindique) au preacutealable sur ce Topic
MQTT est un protocole qui repose sur TCP Lencapsulation des trames sur le reacuteseau est donc la
suivante
Broker
Client
Publisher 1
Client
Publisher 2
Client
Subscriber
Topic
Tempeacuterature
Topic
Humiditeacute
| 53
Figure 57 Protocoles utiliseacutes pour la communication avec MQTT
On peut le veacuterifier par une capture de trame sur Wireshark
Figure 58 Capture dune trame MQTT avec Wireshark
On peut noter que le port TCP utiliseacute pour le protocole MQTT (non chiffreacute) est le 1883
Les Publishers et les Subscribers nrsquoont pas besoin de se connaitre
Les Publishers et les Subscribers ne sont pas obligeacute de srsquoexeacutecuter en mecircme temps
622 Connexion au Broker MQTT Nous nous inteacuteresserons essentiellement aux options de connexion qui permettront de geacuterer la
Qualiteacute de Service (QoS) Pour se connecter un client MQTT envoie deux informations importantes
au Broker
keepAlive Cest la peacuteriode la plus longue pendant laquelle le client Publisher ou Subscriber pourra
rester silencieux Au-delagrave il sera consideacutereacute comme deacuteconnecteacute
cleanSession Lorsque le Client et le Broker sont momentaneacutement deacuteconnecteacutes (au-delagrave du
keepAlive annonceacute) on peut donc se poser la question de savoir ce quil se passera lorsque le client
sera agrave nouveau connecteacute
Si la connexion eacutetait non persistante (cleanSession = True) alors les messages non transmis
sont perdus Quel que soit le niveau de QoS (Quality of Service)
Si la connexion eacutetait persistante (cleanSession = False) alors les messages non transmis
seront eacuteventuellement reacuteeacutemis en fonction du niveau de QoS Voir le chapitre 624
623 Qualiteacute de Service au cours dune mecircme connexion
A partir du moment ougrave le Client se connecte au Broker il est possible de choisir un niveau de fiabiliteacute
des transactions Le Publisher fiabilise leacutemission de ces messages vers le Broker et le Subscriber
fiabilise la reacuteception des messages en provenance du Broker Une parle ici du cas dune mecircme
connexion crsquoest-agrave-dire entre le moment ou le Client se connecte et le moment ougrave
Soit il se deacuteconnecte explicitement (Close connexion)
Soit il na rien eacutemis ni fait signe de vie pendant le temps keepAlive
TCP
MQTT
Reacuteseau
Transport
Couche Application
IP
| 54
Lors dune mecircme connexion la Qualiteacute de Service (QoS) qui est mise en œuvre deacutepend uniquement
de la valeur du QoS selon les valeurs suivantes
QoS 0 At most once (au plus une fois) Le premier niveau de qualiteacute est sans acquittement Le
Publisher envoie un message une seule fois au Broker et le Broker ne transmet ce message quune
seule fois aux Subscribers Ce meacutecanise ne garantit pas la bonne reacuteception des messages MQTT
QoS 1 At least once (au moins une fois) Le deuxiegraveme niveau de qualiteacute est avec acquittement
Le Publisher envoie un message au Broker et attends sa confirmation De la mecircme faccedilon le Broker
envoie un message agrave ces Subscriber et attends leurs confirmations Ce meacutecanisme garantit la
reacuteception des message MQTT
Cependant si les acquittements nrsquoarrivent pas en temps voulu ou srsquoils se perdent la reacuteeacutemission du
message dorigine peut engendrer une duplication du message Il peut donc ecirctre reccedilu plusieurs fois
QoS 2 Exactly once (exactement une fois) Le troisiegraveme niveau de qualiteacute est garanti une seule
fois Le Publisher envoie un message au Broker et attends sa confirmation Le Publisher donne alors
lrsquoordre de diffuser le message et attends une confirmation Ce meacutecanisme garantit que quel que
soit le nombre de tentatives de reacuteemission le message ne sera deacutelivreacute quune seule fois
La Figure 59 montre les trames eacutemises pour chaque niveau de QoS
Figure 59 Qualiteacute de Service en MQTT
La Figure 60 repreacutesentes les 3 captures de trames sur Wireshark repreacutesentant les 3 QoS (1 2 et 3)
que nous venons dexpliquer
Broker
QoS 0
Au plus une fois
Message supprimeacute apregraves envoi
PUBLISH
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Duplications possibles
PUBLISH
PUBLICH Ack
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Pas de duplication
PUBLISH
PUBLISH Receive
PUBLISH Release
PUBLISH Complete
| 55
Figure 60 Capture de trame avec QoS = 0 puis QoS = 1 puis QoS = 2
624 Qualiteacute de Service apregraves une reconnexion
La question que nous nous posons et de savoir ce que deviennent les messages publieacutes sur le Broker
lorsquun ou plusieurs Subscribers sont momentaneacutement injoignables Il est possible de conserver
les messages qui ont eacuteteacute publieacutes sur le Broker afin de les retransmettre lors de la prochaine
connexion Cette possibiliteacute de sauvegarde doit ecirctre activeacutee agrave louverture de connexion gracircce au flag
cleanSession = 0 La connexion sera alors persistante crsquoest-agrave-dire que le Broker enregistre tous les
messages quil na pas reacuteussi agrave diffuser au Subscriber
Le Tableau 9 reacutesume leffet du flag cleanSession et du QoS
Clean Session Flag Subscriber QoS Publisher QoS Comportement True ( = 1) 0 1 2 0 1 2 Messages perdus
False ( = 0 ) 0 0 1 2 Messages perdus
False (= 0 ) 0 1 2 0 Messages perdus
False (= 0 ) 1 2 1 2 Tous les messages sont retransmis
Tableau 9 Qualiteacute de Service en fonction de la valeur du QoS et du flag cleanSession
625 Les Topics du protocole MQTT Les chaicircnes deacutecrivant un sujet forment une arborescence en utilisant la barre oblique comme
caractegravere de seacuteparation La Figure 61 et le Tableau 10 donne un exemple dorganisation de Topic
Figure 61 Exemple de hieacuterarchie de Topic MQTT
Niveau 3
Niveau 2
Niveau 1 Maison
Chambre
Temperature Humidite Bruit
Salon
Temperature
| 56
Nom du Topic Deacutetail du Topic MaisonChambreTemperature La tempeacuterature de la chambre de la maison
MaisonChambreBruit Le bruit de la chambre de la maison
MaisonSalonTemperature La tempeacuterature du Salon de la maison
Tableau 10 Exemple de Topic
Un client peut sabonner (ou se deacutesabonner) agrave plusieurs branches de larborescence agrave laide de
jokers englobant plusieurs Topics Deux caractegraveres jokers existent
Le signe plus + remplace nimporte quelle chaine de caractegravere sur le niveau ougrave il est placeacute
Le diegravese remplace nimporte quelle chaine de caractegravere sur tous les niveaux suivants Il
est obligatoirement placeacute agrave la fin
Nom du Topic Deacutetail du Topic Maison+Temperature Les tempeacuteratures de toutes les piegraveces de la maison
MaisonChambre La tempeacuterature lhumiditeacute et le bruit de la chambre de la maison
Tableau 11 Exemple de Topic
626 Mise en place drsquoun Broker MQTT Afin de bien comprendre le fonctionnement du protocole de MQTT on reacutealise des tests
indeacutependamment de TTN Nous allons mettre en place
Un Broker Mosquitto httpstestmosquittoorg
Un client Publisher MQTT Box sur Windows
Un client Subscriber MQTT Box sur Windows
Figure 62 Test du protocole MQTT
MQTT Client (Subscriber)
MQTT Client (Publisher)
Publish
Subscribe
BROKER (Mosquitto)
| 57
Le Broker MQTT est commun agrave tout le monde Nous pouvons soit le reacutealiser nous-mecircme soit utiliser
un Broker MQTT public de test Nous utiliserons le Broker de test de Mosquitto disponible sur
httpstestmosquittoorg Drsquoautres sont eacuteventuellement disponibles en cas de problegraveme par
exemple httpwwwmqtt-dashboardcom
Si nous deacutecidions de le reacutealiser nous-mecircme agrave lrsquoaide drsquoune Raspberry Pi (par exemple) Lrsquoinstallation
se ferait en deux lignes de commande
apt-get install mosquito Installation
sudo systemctl start mosquittoservice Lancement du service
Il est neacutecessaire drsquoinstaller mosquitto-clients si on souhaite que le Raspberry PI joue aussi le rocircle de
client ce qui nrsquoest pas notre cas
627 Mise en place drsquoun Publisher et drsquoun Subscriber MQTT Lancer le logiciel MQTTBox
MQTTBox gt Create MQTT Client
Dans ce client les seuls champs indispensables sont
Protocol MQTT TCP
Host testmosquittoorg
Figure 63 Configuration dun Client MQTT dans MQTT Box
Tester lrsquoenvoi et la reacuteception sur les Topics de votre choix
628 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT La reacutecupeacuteration des donneacutees fait reacutefeacuterence au flux Uplink Dans ce cas
TTN joue le rocircle de client Publisher
TTN joue aussi le rocircle de Broker
Notre application joue le rocircle de Subscriber
Nous pouvons donc repreacutesenter lrsquoapplication globale par le scheacutema suivant
| 58
Figure 64 Publisher et Subscriber dans en MQTT avec TTN
La publication est repreacutesenteacutee par la trame MQTT (1)
La souscription est repreacutesenteacutee par la trame MQTT (2)
Le client Publisher eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box mais cette fois avec la configuration suivante
Protocol mqtt tcp
Host Crsquoest lrsquoIP du Broker vers lequel il faut se connecter Dans notre cas il srsquoagit de celui
de TTN dont lrsquoadresse est euthethingsnetwork
Username La connexion vers le broker MQTT est soumis agrave une authentification Username
Password Dans notre cas le Username correspond au nom de notre application crsquoest-agrave-
dire seminaire_lorawan Si vous avez choisi une autre applicationil faut bien mettre la
votre
Password Le Password est nommeacute laquo Access Key raquo par TTN Elle vous sera donneacutee par
lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application vous
trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt Overview
Figure 65 Access Keys de lapplication dans TTN
The Things Network (Application Server)
BROKER
Application
The Things Network (Network Server)
Publish (1 )
[ Flux Uplink ]
Subscribe (2 )
[ Flux Uplink ]
| 59
Figure 66 Configuration du Client dans MQTT Box
Le client MQTT eacutetant configureacute il est maintenant capable de se connecter au Broker Il reste donc agrave
deacutefinir le fait que le client sera Subscriber Les informations que recevra le Subscriber deacutependent du
Topic auquel nous souscrivons Voici les Topic disponibles sur le Broker de TTN
ltAppIDgt correspond au nom de votre Application
ltDevIDgt correspond au nom de votre Device LoRa
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink ltAppIDgtdevicesltDevIDgtup
[Donneacutees] Flux Downlink ltAppIDgtdevicesltDevIDgtdown
[Activation Events] Activation dun Device ltAppIDgtdevicesltDevIDgteventsactivations
[Management Events] Creacuteation dun Device ltAppIDgtdevicesltDevIDgteventscreate
[Management Events] Update dun Device ltAppIDgtdevicesltDevIDgteventsupdate
[Management Events] Suppression dun Device ltAppIDgtdevicesltDevIDgteventsdelete
[Downlink Events ] Message programmeacute ltAppIDgtdevicesltDevIDgteventsdownscheduled
[Downlink Events ] Message envoyeacute ltAppIDgtdevicesltDevIDgteventsdownsent
[Erreurs] Uplink erreurs ltAppIDgtdevicesltDevIDgteventsuperrors
[Erreurs] Downlink erreurs ltAppIDgtdevicesltDevIDgteventsdownerrors
[Erreurs] Activations erreurs ltAppIDgtdevicesltDevIDgteventsactivationserrors
Tableau 12 Topics enregistreacutes dans TTN
Dans un premier temps nous souscrivons au Topic +devices+up Cela signifie que nous
souscrivons agrave tous les Devices LoRa de toutes nos applications pour le flux Uplink
Figure 67 Configuration du Subscriber
Les eacuteleacutements eacutemis par le Broker seront alors afficheacutes dans MQTTBox La
| 60
Figure 68 Trame LoRaWAN reccedilu sur le Subscriber MQTT
Ces donneacutees sont eacutecrites en JSON nous pouvons les remettre en forme
applicationID3
applicationNamemyApplication
deviceNamearduino0
devEUI0056xxxxxxxxx877
txInfo
frequency868500000
dr5
adrfalse
fCnt792
fPort15
dataSGVsbG8=
Le Frame Payload deacutechiffreacute est fourni dans le champ data en base 64 La valeur fournie par
dataSGVsbG8= correspond bien agrave la chaine de caractegravere hello que nous avons eacutemise avec le
Device LoRa
629 Envoyer des donneacutees depuis notre Application avec MQTT
Lrsquoenvoi des donneacutees fait reacutefeacuterence au flux Downlink Dans ce cas
Notre application joue le rocircle de Publisher
TTN joue le rocircle de Broker
TTN joue aussi le rocircle de client Subscriber
| 61
La publication est repreacutesenteacutee par la trame MQTT (3)
La souscription est repreacutesenteacutee par la trame MQTT (4)
Le client Subscriber eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box Le rocircle de client dans MQTT Box a eacuteteacute faite au
paragraphe 628 Il nous reste simplement agrave ajouter le rocircle de Publisher La configuration est la
suivante
Topic du Subscriber seminaire_lorawandevicesarduino0down ougrave seminaire_lorawan
est agrave remplacer par le nom de votre application et arduino0 par le nom du Device LoRa vers
lequel vous souhaitez envoyeacute une donneacutee (Voir chapitre 628 pour comprendre les Topics)
Le Payload doit ecirctre au format JSON Lrsquoexemple suivant envoie laquohello raquo
payload_raw aGVsbG8=
The Things Network (Application Server)
BROKER
Application
Publish (3)
[ Flux Downlink ]
The Things Network (Network Server)
Subscribe (4)
[ Flux Downlink ]
| 62
Figure 69 Configuration du Publisher
Vous devriez voir les donneacutees arriver sur votre Device LoRA
| 63
7 Creacuteation de notre propre Network et Application Server
711 Objectifs Lors de la mise en œuvre du reacuteseau LoRaWAN au chapitre 52 nous avons utiliseacute TTN (The Things
Network) pour jouer le rocircle de Network Server et drsquoApplication Server Pour de multiples raisons
Seacutecuriteacute autonomie coucircthellipil peut ecirctre inteacuteressant de monter soi-mecircme un Network Server et un
Application Server Cela est possible seulement si vous posseacutedez vos propres Gateway puisque
celles-ci devront forwarder leur paquet agrave destination preacutecise Il faudra donc les reconfigurer pour
qursquoelles pointent vers votre nouvelle architecture
712 Preacutesentation de LoRaServer LoRaServer [ wwwloraserverio ] est un projet Open-Source reacutepondant exactement au besoin que
nous avons Nous lrsquoutiliserons sur une cible Raspberry PI En reacutealiteacute il peut souvent ecirctre mise en
place dans le mecircme systegraveme que la Gateway surtout si celle-ci est elle-mecircme agrave base de RPI Les
Gateway EBDS que nous posseacutedons possegravedent drsquoailleurs un Network Server et un Application Server
que nous aurions pu utiliser Neacuteanmoins pour des raisons peacutedagogiques il est inteacuteressant de
seacuteparer les systegravemes pour bien diffeacuterencier les probleacutematiques
Attention il y a une ambiguiumlteacute dans la deacutenomination des entiteacutes logiciels de LoRaServer
LoRaServer (sans espace entre le mot LoRa et Server) est le nom du projet global En
revanche LoRa Server (avec un espace) est le nom du service qui joue le rocircle du Network
Server
Lrsquoarchitecture et le fonctionnement de LoRaServer est preacutesenteacutee dans sa documentation par le
scheacutema suivant
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Raspberry PI
Figure 70 Architecture globale de notre reacuteseau loRaWAN
| 64
Figure 71 Architecture deacutetailleacutee de LoRaServer
On srsquoattends agrave voir uniquement un Network Server (LoRa Server) et un Application Server (LoRa App
Server) mais ce scheacutema est plus complexe Il demande un certain nombre drsquoexplications pour bien
comprendre ce que nous allons installer et la faccedilon dont nous lrsquoutiliserons par la suite
713 Le laquo Packet Forwarder raquo (Gateway) Comme nous lrsquoavons vu au chapitre 412 les Gateways LoRa sont des passerelles entre la
modulation LoRa et un reacuteseau IP Pour reacutealiser cette passerelle un service nommeacute laquo UDP Packet
Forwarder raquo a eacuteteacute deacuteveloppeacute par Semtech httpsgithubcomLora-netpacket_forwarder Dans
ce dossier github un fichier nommeacute PROTOCOLTXT explique parfaitement ce protocole applicatif
qui travaille au-dessus de UDP
Figure 72 Protocole Uplink (PUSH_DATA du Packet Forwarder)
| 65
On remarque que les paquets sont envoyeacutes en UDP au Network Server dans une trame appeleacutee
PUSH_DATA Cette trame est acquitteacutee par le Network Server par une trame appeleacutee PUSH_ACK
Sur notre Network Server nous pouvons reacutealiser une capture de trame pour veacuterifier si le protocole
est bien celui preacutesenteacute dans le document
Figure 73 Trame captureacutee par Wireshark lors dun Uplink
Drsquoapregraves la capture preacuteceacutedente on remarque que le Packet Forwarder fonctionne bien avec UDP sur
le port 1700
Le contenu des donneacutees (champ Data) est deacutetailleacute dans le tableau suivant
Champ | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | random token
[3] | 3 | PUSH_DATA identifier = 0x00
[4] | 4-11 | Gateway unique identifier (MAC address)
[5] | 12-end | JSON object starting with ending with
Lrsquoobjet JSON de la transmission reacuteeacutecrit plus proprement est celui-ci
Figure 74 Analyse du champ Donneacutees du protocole laquo Packet Forwarder raquo
0000 02 f9 30 00 b8 27 eb ff fe ae 26 f5 7b 22 72 78 0amprx 0010 70 6b 22 3a 5b 7b 22 74 6d 73 74 22 3a 33 37 35 pk[tmst375 0020 35 30 30 35 38 31 39 2c 22 63 68 61 6e 22 3a 32 5005819chan2 0030 2c 22 72 66 63 68 22 3a 31 2c 22 66 72 65 71 22 rfch1freq 0040 3a 38 36 38 2e 35 30 30 30 30 30 2c 22 73 74 61 868500000sta 0050 74 22 3a 31 2c 22 6d 6f 64 75 22 3a 22 4c 4f 52 t1moduLOR 0060 41 22 2c 22 64 61 74 72 22 3a 22 53 46 37 42 57 AdatrSF7BW 0070 31 32 35 22 2c 22 63 6f 64 72 22 3a 22 34 2f 35 125codr45 0080 22 2c 22 6c 73 6e 72 22 3a 36 2e 35 2c 22 72 73 lsnr65rs 0090 73 69 22 3a 2d 31 2c 22 73 69 7a 65 22 3a 31 38 si-1size18 00a0 2c 22 64 61 74 61 22 3a 22 51 4e 4d 61 41 53 59 dataQNMaASY 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 ]
Ch
amp
[1
]
Ch
amp
[2
]
Ch
amp
[3
]
Ch
amp
[4
]
| 66
rxpk[ tmst3755005819
chan2
rfch1
freq868500000
stat1
moduLORA
datrSF7BW125
codr45
lsnr65
rssi-1
size18
dataQNMaASYAAQAPpyPZ955+SmY
]
Le champ data correspond au PHY Payload
De la mecircme faccedilon on retrouve la Trame drsquoacquittement
Figure 75 Trame captureacutee par Wireshark lors de lrsquoacquittement drsquoun Uplink
Champs | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | same token as the PUSH_DATA to acknowledge
[3] | 3 | PUSH_ACK identifier = 0x01
Nous retrouvons bien tous ces champs dans la trame Wireshark
714 LoRa Gateway Bridge Nous avons deacutecrit au chapitre preacuteceacutedent (713) le fonctionnement du Packet Forwarder Le
Network Server(Lora Server) que nous allons mettre en place aurait tregraves bien pu srsquointerfacer
directement agrave ce protocole Mais cela aurait plusieurs impacts dont un qui est important dans la
conception de logiciel Si le Packet Forwarder change ou si un autre type de Forwarder est utiliseacute
alors lrsquoutilisation du LoRa Server devient impossible Il a donc eacuteteacute choisi de creacuteer une eacutetape
intermeacutediaire Le Network Server que nous mettrons en plus utilisera le protocole MQTT plutocirct que
le protocole UDP packet Forwarder
En drsquoautres termes le LoRa Gateway Bridge est un service qui fera abstraction du Packet Forwarder
pour srsquointerfacer plus simplement avec le Network Server
715 LoRa Server (Network Server) Il srsquoagit de notre Network Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
413 Cependant il srsquointerfacera au protocole MQTT en recevant les informations agrave partir du
Broker au lieu de recevoir directement les trames en provenance de la Gateway
| 67
716 LoRa App Server (Application Server) Il srsquogit de notre Application Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
414
717 LoRa Geo Server Il srsquoagit drsquoun service qui permet drsquoutiliser certaines proprieacuteteacutes du protocole LoRa pour proposer un
service de geacuteolocalisation des Devices LoRa Nous ne lrsquoutiliserons pas dans notre cas
718 Application Il srsquoagit de notre Application qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre 415
Elle ne fait pas partie du projet LoRaServer crsquoest donc bien toujours agrave nous de proposer notre propre
Application
Figure 76 Les interfaces possibles entre LoRaServer et lrsquoApplication utilisateur
Comme nous pouvons le voir sur la figure preacuteceacutedente deux possibiliteacutes sont offertes pour interfacer
notre application JSON REST (incluant HTTP POST) et via un Broker MQTT Ces deux meacutethodes ont
deacutejagrave eacuteteacute traiteacutee au chapitre 61 (HTTP POST ) et au chapitre 62 (MQTT) Nous verrons aussi drsquoautres
possibiliteacutes pour personnaliser notre application au chapitre 7
72 Installation de LoRaServer
721 Mise en place de lrsquoenvironnement
Nous allons installer une carte SD avec la derniegravere version de Raspbian Nous ne deacutetaillerons pas la
deacutemarche pour cela car elles sont largement documenteacutees et mises agrave jour sur le site
wwwraspberrypiorg
Installer un carte SD avec la derniegravere version de Raspbian
Plutocirct que de fonctionner avec un clavier et une souris nous preacuteconisons de travailler agrave distance
avec la RPI via une connexion SSH Depuis quelques anneacutees Raspbian a supprimeacute le deacutemarrage du
service SSH au boot Heureusement il est possible de le reacuteactiver par la meacutethode suivante
Avec Windows ou Linux ouvrir la partition BOOT de votre carte SD et placer un fichier agrave la
racine nommeacute sshtxt (ou ssh)
Mettre la carte SD dans votre RPI et la deacutemarrer
| 68
Pour acceacuteder agrave la RPI en SSH depuis Windows nous utiliserons de preacutefeacuterence le logiciel
client MobaXterm mais tout autre client SSH est valable
Installer MobaXterm sur votre PC et connectez-vous agrave votre Raspberry PI
Lrsquoutilisation drsquoun espion de reacuteseau type Wireshark peut ecirctre inteacuteressant pour eacutetudier les trames qui
sont reccedilues et qui sont eacutemises Cela nous permettra de valider le fonctionnement des diffeacuterents
protocoles reacuteseau qui permettent de communiquer agrave la Gateway drsquoune part et agrave lrsquoApplication
drsquoautre part Nous utiliserons tshark
apt-get install tshark installation
tshark ndashn -i eth0 Exemple drsquoune analyse sur lrsquointerface wlan0
722 Installation sur la Raspberry PI La meacutethode drsquoinstallation de LoRaServer est documenteacutee sur le site web agrave lrsquoadresse suivante
[ httpswwwloraserverioguidesdebian-ubuntu ] Nous installerons le LoRa Gateway Bridge
le LoRa Server et le LoRa App Server
Apregraves lrsquoinstallation la configuration se fait par une interface graphique accessible par le reacuteseau sur
le port 8080
Si vous travaillez sur la RPI connectez-vous sur httplocalhost8080
Si vous travaillez agrave distance (SSH) connectez-vous sur httpIP_RPI8080
Les Usernames et Password par deacutefaut sont
Username admin
Password admin
Lrsquoeacutecran drsquoaccueil sera donc le suivant
Figure 77 Architecture globale apregraves installation de LoRaServer
Devices
Gateways LoRa
UDP Packet Forwarder
Application Server
LoRa App Server
Internet
Network Server
LoRa Server
LoRa Gateway Bridge
| 69
Figure 78 Ecran daccueil de LoRaServer apregraves authentification
71 Configuration de LoRa Server pour lUplink
711 Enregistrement drsquoune nouvelle Organisation
Pour enregistrer une nouvelle Organizations Organizations gt Create Puis entrer les configurations
suivantes
Figure 79 Enregistrement dun nouvelle Organisation
712 Enregistrement drsquoune instance du Network Server Pour enregistrer une nouvelle instance du Network Server Network Server gt Create Puis entrer
les configurations suivantes
| 70
Figure 80 Enregistrement dun nouveau Network Server
Dans lrsquoonglet Gateway Discovery il est possible drsquoactiver une option de deacutecouverte de Gateway aux
alentours Lorsqursquoelle est configureacutee le Network Server va envoyer une trame Downlink de
configuration de la Gateway lui ordonnant de reacutealiser des PING en LoRa La configuration du
Gateway Discovery preacutevoit de speacutecifier
Le nombre de fois par jour que les PING LoRa sont envoyeacutes
Le canal drsquoeacutemission
Le Data Rate (Voir paragraphe 445)
Un PING LoRa reccedilu sur une Gateway sera retransmis sur le Network Server (Lora Server) et une carte
sera afficheacutee
Lrsquoonglet TLS Certificates ne sera pas utiliseacute dans le cadre de notre deacutemonstration
713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) Il faut tout drsquoabord faire un enregistrement drsquoun laquo service-profile raquo Un laquo service profile permet de
faire la connexion entre le Network Server et les Applications que nous enregistrerons dans notre
Organisation Service-profiles gt Create
Service-profile name myServiceProfile
Network-server myNetworkServer
On laissera par deacutefaut toutes les autres options
Pour enregistrer une nouvelle Application Applications gt Create Puis entrer les configurations
suivantes
| 71
Figure 81 Enregistrement dune nouvelle Application
714 Enregistrement des Devices LoRa Il faut tout drsquoabord faire lrsquoenregistrement drsquoun Device-profile pour les Devices LoRa que vous
souhaitez connecter Dans notre cas nous ferons un premier test en speacutecifiant que nous utilisons
seulement le mode drsquoauthentification ABP (voir chapitre 431) Devices profile gt Create
Figure 82 Enregistrement dun laquo Device profile raquo
Nous pouvons alors creacuteer dans notre Application des nouveaux Devices Application gt
myApplication gt Create
| 72
Figure 83 Enregistrement dun nouveau Device LoRa
Dans la fenecirctre Activation on va alors configurer les 3 eacuteleacutements indispensables agrave une
authentification en APB Le DevAddr le NwkSKey et lrsquoAppSKey
Figure 84 Configuration de lenregistrement du Device LoRa (en ABP)
La configuration minimale de LoRaServer est maintenant termineacutee Nous pouvons donc brancher
un Device LoRa qui possegravede les les attribus (DevAddr NwkSKey et AppSKey) que nous avons
enregistreacute dans LoRaServer et le faire eacutemettre
715 Visualisation des trames reccedilues Les trames eacutemises par le Device LoRa vont donc parcourir le cheminement suivant
| 73
Figure 85 Reacutesumeacute du cheminement des trames LoRaWan en Uplink avec LoRaServer
En allant dans le Live Device Data (Application gt Nom_du_Device gt Live Device Data) on peut voir la
liste des trames reccedilues ainsi que les donneacutees applicatives deacutechiffreacutees
Figure 86 Reacuteception des trames des Devices LoRa
Figure 87 Analyse des trames des Devices LoRa
Dans lrsquoonglet LIVE LORAWAN FRAME nous pouvons voir les trames LORAWAN et si besoin eacutetudier
le contenu de ce qursquoelles contiennent En revanche les donneacutees applicatives sont ici chiffreacutees
UDP
Packet Forwarder
LoRa Bridge
Gateway LoRa Server LoRa App Server
Gateway
Server
Internet
| 74
Figure 88 Reacuteception des Trames LoRaWAN
72 Configuration de LoRaServer pour linteacutegration dApplication Nous avons vu dans le chapitre 718 que linterface entre LoRaServer et notre Application pouvait
ecirctre reacutealiseacutee soit par MQTT soit par les meacutethodes REST (HTTP POST) Nous avons deacutejagrave impleacutementeacute
et expliqueacute ces protocoles dans le cadre de son utilisation avec TTN Nous allons donc juste
configurer LoRaServer pour tester ces deux meacutethodes
721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST Nous utiliserons exactement la mecircme meacutethode que celle que nous avons utiliseacute avec TTN au
chapitre 615 Les diffeacuterentes Clients et Serveurs disponibles pour ces tests sont expliqueacutes au
paragraphe 612
Dans LoRaServer ajouter une inteacutegration HTTP LoRaServer gt Applications gt myApplication gt
Integrations gt Create gt HTTP Integration et la configurer comme le montre la Figure 89 Vous
remplacerez eacutevidement le lien par votre propre Endpoints
Figure 89 Configuration de linteacutegration HTTP POST dans LoRaServer
En envoyant des trames LoRa depuis votre Device vous devriez voir les contenus JSON sur votre
Endpoint
722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT Nous allons nous connecter au Broker MQTT de LoRaServer Pour cela nous utiliserons la mecircme
meacutethode que celle que nous avons utiliseacute avec TTN au chapitre 628 Nous utiliserons MQTTBox
comme nous lavons deacutejagrave fait au paragraphe 627
Le Broker de LoRaServer a enregistreacute les Topics suivant
[applicationID] correspond au nom de votre Application
[devEUI] correspond au nom de votre Device LoRa
| 75
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink application[applicationID]device[devEUI]rx
[Donneacutees] Flux Downlink application[applicationID]device[devEUI]tx
[Status] Statut dun Device application[applicationID]device[devEUI]status
[Ack] Acquittement des messages application[applicationID]device[devEUI]ack
[Erreurs] Erreurs application[applicationID]device[devEUI]error
Tableau 13 Topics enregistreacutes dans LoRaServer
| 76
8 Creacuteation de notre propre Application
81 Utilisation de Node-RED
811 Preacutesentation Node-RED est un outil de programmation graphique qui permet de faire communiquer les
peacuteripheacuteriques mateacuteriels drsquoun systegraveme sans eacutecrire de code De nombreux protocoles sont aussi pris
en charge au travers de bloc ( Node) qursquoil suffit de connecter entre eux pour reacutealiser simplement
une application Il peut srsquoexeacutecuter localement sur un PC ou sur des cibles embarqueacutees telle qursquoune
Raspberry PI (RPI)
Dans les deacutemonstrations que nous mettrons en œuvre nous utiliserons une RPI Par soucis de
simpliciteacute nous utiliserons les derniegraveres versions de Raspbian (systegraveme drsquoexploitation de la RPI) qui
integravegre drsquoorigine Node-RED Il nrsquoy a donc tregraves peu de chose agrave mettre en place pour arriver agrave mettre
en place une Application Nous pouvons travailler soit directement sur la RPI agrave lrsquoaide drsquoune souris-
clavier mais il est recommandeacute de travailler agrave distance avec une connexion SSH
812 Mise en place de lrsquoenvironnement La mise en place de la RPI avec le systegraveme drsquoexploitation Raspbian a eacuteteacute preacutesenteacute au chapitre 721
Vous pouvez reprendre la mecircme installation ou repartir sur une nouvelle
Il est possible de faire en sorte que Node-RED se lance directement au deacutemarrage gracircce agrave la
commande sudo systemctl enable noderedservice
Sil nest pas actif lancer Node-RED sur votre RPI node-red-start
Nous nous connectons au Node-RED de la RPI via un navigateur web sur le port 1880 en tapant dans
la barre dURL httpIP_Raspeberry_PI1880 Ce nous permet darriver agrave la fenecirctre suivante
Figure 90 Page daccueil de Node-RED
Il est possible de sinterfacer avec TTN avec les Nodes deacutejagrave disponibles gracircce au protocole HTTP
POST ou MQTT Neacuteanmoins nous pouvons avantageusement installer deux librairies speacutecifiques
Une qui facilite linterfaccedilage avec TTN
Une qui facilite la mise en place dinterface graphique
Installation des Nodes TTN
cd $HOMEnode-red
npm install node-red-contrib-ttn
Installation de Dashboard (interface graphique)
| 77
cd $HOMEnode-red
npm install node-red-dashboard
Il peut ecirctre necessaire de redeacutemarrer Node-RED pour prendre en compte linstallation de nos deux
Nodes
-----------------------------------
sudo apt-get install npm
sudo npm install -g npm
hash -r
cd ~node-red
npm install node-red-example node name
------------------------------------
813 Creacuteer une Application speacutecifique pour TTN Nous allons commencer par geacuterer le flux Uplink Apporter sur votre scheacutema un Node ttn uplink et
un Node Debug puis relier les Le Node ttn uplink nous permettra de configurer la
communication avec TTN en MQTT Le Node debug eacutecrira sur le terminal les informations brutes
qui seront reccedilu par le Node ttn uplink
Figure 91 Visualisation des trame publieacutees par TTN sur notre client MQTT
Double cliquer sur le Node ttn uplink pour le configurer comme la figure suivante
Le champ Name sera le nom du Node sur votre scheacutema Le champ Device ID est le device LoRa
concerneacute dans votre application De plus il faut entrer les caracteacuteristiques de votre application (Add
new ttn app) pour que Node-RED puisse sy connecter
Figure 92 Configuration du node ttn uplink
Configuration de votre nouvelle application
| 78
Figure 93 Identifiant et mot de passe de notre application
AppID Nom de votre application Dans notre cas seminaire_lorawan
Access Key Comme nous lavons deacutejagrave expliqueacute plus tocirct l Access Key vous sera donneacutee
par lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application
vous trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt
Overview
Le Node ttn uplink doit maintenant avoir le nom que vous avez configureacute Cliquer sur Deploy pour
lancer votre projet Le bloc ttn uplink doit maintenant ecirctre connecteacute agrave TTN Cela est speacutecifieacute
connected sous le bloc
Figure 94 Utilisation du Node TTN Uplink
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
Figure 95 Simulation de Uplink dans TTN
Vous devriez voir le reacutesultat dans la fenecirctre de Debug Par exemple pour le test denvoi de 31 32
correspondant au code ASCII des chiffres 1 et 2 vous devriez avoir la fenecirctre de Debug suivante
| 79
Figure 96 Reacutesultats obtenu dans la fenecirctre Debug apregraves la simulation dUplink
814 Creacuteation drsquoun Dashboard
Dans la mise en place de lenvironnement (chapitre 812) nous avons installeacute des Nodes
Dashboard qui vont nous permettre de reacutealiser une interface graphique tregraves simple et de la mettre
agrave disposition des utilisateurs via un des graphiques histogramme gauges afficheurshellip
Figure 97 Impleacutementation dune interface graphique dans Node RED
Linterface graphique que nous allons creacuteer sera constitueacutee donglet (tab) La mise en place des
composant se fait de la faccedilon suivante
Chaque eacuteleacutement graphique doit appartenir agrave un groupe de composant quil va falloir creacuteer
Chaque groupe de composant doit appartenir agrave un onglet (tab) quil va falloir creacuteer
Figure 98 Creacuteation dun groupe de composant
Figure 99 Creacuteation dun nouvel onglet dans le site web
Cliquer sur Deploy pour activer votre application
LURL pour joindre linterface graphique de votre site web est disponible sur ladresse
httpIP_Raspeberry_PI1880ui
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
| 80
Figure 100 Interface graphique du site web avec Node-RED
82 Programmation en PHP Maintenant que nous avons testeacute toute lrsquoarchitecture nous pouvons mettre en place une
application qui jouera deux rocircles
Un rocircle de Serveur HTTP POST reacutecupeacuterant les donneacutees en provenance de TTN
Un rocircle de Client HTTP POST qui geacuteneacuterera les requecirctes vers TTN
Un serveur web apache sur RPI heacuteberge cette application Linterface graphique du site web est
reacutealiseacute avec le template CSS proposeacute par Bootstrap [ httpsgetbootstrapcom ]
Figure 101 Architecture de notre application en PHP sur RPI
The Things Network
Notre Application
[ Serveur Apache sur Raspberry Pi ]
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 81
Nous allons lrsquoutiliser telle quelle Elle est juste proposeacutee agrave titre dexemple Lrsquoobjectif de cette
application est de geacuteneacuterer une ouverture fermeture de ruche agrave distance dans le cadre de projets
eacutetudiants du Master Electronique et Systegravemes Embarqueacutes de lUSMB [ httpscem-esetuniv-
smbfr ]
Figure 102 Application permettant de recevoir et deacutemettre des requecirctes HTTP POST
Configurer TTN pour pointer vers votre nouveau serveur et tester le flux montant et
descendant
| 82
9 Versions du document
Version 10 02022019
Version initiale
Version 20 23022019
Ajout drsquoun paragraphe Les systegravemes embarqueacutes dans lrsquoIoT En introduction
Compleacutement et ameacutelioration Ameacutelioration exercice eacutetalement de spectre
Correction Cacircblage Arduino
Ajout drsquoun paragraphe Fonctionnement de lrsquoArduino et ajout de librairies
Compleacutement et ameacutelioration Couche physique LoRa Ajout de 4 figures pour lrsquoexplication
de la modulation Chirp
Ajout drsquoun paragraphe sur les acronymes utiliseacutes au deacutebut du cours TTN LoRa MQTThellip
Compleacutement drsquoinformations sur les dB et dBm
Ajout LoRa Calculator
Version 30 8032019
Ajout de figure sur le rocircle de la Gateway LoRa
Ajout de paragraphe authentification avec le Network Server
Ajout de paragraphe sur le chiffrement avec lrsquoApplication Server
Ajout drsquoun sommaire en deacutebut de cours
Ajout de 2 scheacutemas ABP et OTAA
Retrait explication du deacutetail de la laquo Join Request raquo en OTAA Trop complexe attente de
reacutealisation drsquoun scheacutema plus explicite
Ajout drsquoun scheacutema sur lrsquoattaque par REPLAY
Ajout de paragraphe des diffeacuterents reacuteseaux LoRaWAN existants Opeacutereacutes et Priveacutes
Ajout des scheacutemas des trames LoRaWAN Physique LoRa MAC Application
Compleacutement drsquoinformation sur les Classes de Devices
Ajout drsquoun paragraphe sur la Gateway utiliseacutee pour le Downlink
Ajout drsquoun paragraphe sur le JSON
Compleacutement drsquoinformation sur le codage en Base64
Ajout drsquoinformation dans le deacutecodage des trames LoRaWAN
Restructuration des explications sur lrsquoenvoi et la reacutecupeacuteration des donneacutees en HTTPMQTT
Version 40 8032019
Ajout drsquoun chapitre Creacuteation de notre propre Application
Ajout drsquoun chapitre Creacuteation de notre propre Network et Application Server
Ajout drsquoune figure Visualisation des Chirps LoRa par SDR (Radio Logicielle)
Compleacutements drsquoinformation sur MQTT
Compleacutements dinformation sur les Topics de TTN en MQTT
| 3
Sommaire 1 LES SYSTEMES EMBARQUES ET LrsquoIOT 6
11 LINTERNET DES OBJETS ( INTERNET OF THINGS IOT ) 6 111 Les systegravemes embarqueacutes dans lrsquoIoT 6 112 Diffeacuterents protocoles dans lrsquoIoT 6 113 Bande de freacutequence utiliseacutees 7
12 MODES DE PARTAGE DU SUPPORT 7 13 NOTION DrsquoETALEMENT DE SPECTRE 8
131 Transmissions successives 8 132 Transmissions simultaneacutees 9 133 Cas du protocole LoRa 9
2 TRANSMISSION RADIO ET PROPAGATION 10
21 LES UNITES ET DEFINITIONS 10 22 ETUDE DE LA DOCUMENTATION DrsquoUN COMPOSANT LORA 11
3 LA COUCHE PHYSIQUE LORA 13
31 LA MODULATION LORA 13 311 La forme du symbole (Chirp) 13 312 Dureacutee drsquoeacutemission drsquoun symbole 15
32 CODING RATE 16 33 UTILISATION DU LORA CALCULATOR 17 34 TIME ON AIR 18 35 MISE EN ŒUVRE LORA EN POINT A POINT 19
351 Utilisation de lrsquoIDE Arduino 19 352 Validation du fonctionnement 20 353 Mise en valeur du Spreading Factor 20
4 LE PROTOCOLE LORAWAN 21
41 STRUCTURE DrsquoUN RESEAU LORAWAN 21 411 Les Devices LoRa 21 412 Les Gateways LoRa 21 413 Le Network Server 22 414 Application Server 22 415 Application Web Serveur 24 416 Authentification avec le Network Server 25 417 Chiffrement des donneacutees vers lrsquoApplication Server 25 418 Combinaison de lrsquoauthentification et du chiffrement 26
42 CLASSES DES DEVICES LORAWAN 26 421 Classe A (All) Minimal power Application 26 422 Classe B (Beacon) Scheduled Receive Slot 27 423 Classe C (Continuous) Continuously Listening 28 424 Quelle Gateway pour les flux Downlink 29
43 ACTIVATION DES DEVICES LORA ET SECURITE 29 431 ABP Activation By Personalization 29 432 OTAA Over The Air Activation 30 433 Seacutecuriteacute 31
44 LA TRAME LORA LORAWAN 32 441 Les couches du protocole LoRaWAN 32 442 Couche Application 33 443 Couche LoRa MAC 34
| 4
444 Couche physique Modulation LoRa 34 445 Canaux et bandes de freacutequences et Data Rate (DR) 35 446 Trame reccedilue et transmise par la Gateway LoRaWAN 36 447 Le format JSON 37
5 MISE EN ŒUVRE DrsquoUN RESEAU LORAWAN 38
51 LES DIFFERENTS TYPES DE RESEAUX 38 511 Les reacuteseaux LoRaWAN opeacutereacutes 38 512 Les reacuteseaux LoRaWAN priveacutes 38 513 Les zones de couvertures 38
52 THE THINGS NETWORK (TTN) 39 521 Preacutesentation de TTN 39 522 Configuration de la Gateway 39 523 Enregistrement des Gateways Appplication et Devices 39 524 Configuration des Devices LoRa 40
53 MISE EN APPLICATION 41 54 ANALYSE DES TRAMES ECHANGEES 41
541 Utilisation de la base 64 41 542 Inteacuterecirct et inconveacutenient de la base 64 43 543 Uplink Du Device LoRa au Network Server 43 544 Uplink Du Network Server agrave lrsquoApplication Server 45 545 Simulation drsquoUplink dans lrsquoApplication Server 46 546 Downlink De lrsquoApplication Server au Device LoRa 46
6 LA RECUPERATION DES DONNEES SUR NOTRE PROPRE APPLICATION 47
61 RECUPERATION DES DONNEES EN HTTP POST DANS LrsquoAPPLICATION 47 611 Preacutesentation du protocole HTTP 47 612 Fonctionnement drsquoun client et drsquoun serveur HTTP POST 48 613 Test du serveur HTTP POST 49 614 Test du client HTTP POST 49 615 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST 49 611 Envoyer des donneacutees depuis notre Application avec HTTP POST 51
62 RECUPERATION DES DONNEES AVEC MQTT DANS LrsquoAPPLICATION 52 621 Preacutesentation du protocole MQTT 52 622 Connexion au Broker MQTT 53 623 Qualiteacute de Service au cours dune mecircme connexion 53 624 Qualiteacute de Service apregraves une reconnexion 55 625 Les Topics du protocole MQTT 55 626 Mise en place drsquoun Broker MQTT 56 627 Mise en place drsquoun Publisher et drsquoun Subscriber MQTT 57 628 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT 57 629 Envoyer des donneacutees depuis notre Application avec MQTT 60
7 CREATION DE NOTRE PROPRE NETWORK ET APPLICATION SERVER 63
711 Objectifs 63 712 Preacutesentation de LoRaServer 63 713 Le laquo Packet Forwarder raquo (Gateway) 64 714 LoRa Gateway Bridge 66 715 LoRa Server (Network Server) 66 716 LoRa App Server (Application Server) 67 717 LoRa Geo Server 67 718 Application 67
72 INSTALLATION DE LORASERVER 67
| 5
721 Mise en place de lrsquoenvironnement 67 722 Installation sur la Raspberry PI 68
71 CONFIGURATION DE LORA SERVER POUR LUPLINK 69 711 Enregistrement drsquoune nouvelle Organisation 69 712 Enregistrement drsquoune instance du Network Server 69 713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) 70 714 Enregistrement des Devices LoRa 71 715 Visualisation des trames reccedilues 72
72 CONFIGURATION DE LORASERVER POUR LINTEGRATION DAPPLICATION 74 721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST 74 722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT 74
8 CREATION DE NOTRE PROPRE APPLICATION 76
81 UTILISATION DE NODE-RED 76 811 Preacutesentation 76 812 Mise en place de lrsquoenvironnement 76 813 Creacuteer une Application speacutecifique pour TTN 77 814 Creacuteation drsquoun Dashboard 79
82 PROGRAMMATION EN PHP 80
9 VERSIONS DU DOCUMENT 82
| 6
1 Les systegravemes embarqueacutes et lrsquoIoT
11 LInternet des Objets ( Internet of Things IoT )
111 Les systegravemes embarqueacutes dans lrsquoIoT Drsquoune faccedilon geacuteneacuterale les systegravemes eacutelectroniques peuvent ecirctre caracteacuteriseacutes par leur consommation
leur puissance de calcul leur taille et leur prix Dans le cas speacutecifique des systegravemes embarqueacutes
utiliseacutes dans lrsquoIoT nous pouvons affecter le poids suivant agrave chacune des caracteacuteristiques
Figure 1 Consommation Puissance Taille et Prix des objets connecteacutes
Compareacutes aux autres systegravemes eacutelectroniques les systegravemes embarqueacutes utiliseacutes dans lrsquoIoT possegravedent
donc
Une faible consommation
Une faible puissance de calcul
Une petite taille
Un prix faible
112 Diffeacuterents protocoles dans lrsquoIoT
Citez les diffeacuterents protocoles que vous connaissez dans le mode de lrsquoIoT (Internet Of
Things) et reportez-les dans le graphique ci-dessous en fonction de leur bande passante
et de leur porteacutee
Figure 2 Protocoles utiliseacutes dans lIoT en fonction du deacutebit et de la porteacutee
Dans lrsquoIoT les protocoles utiliseacutes possegravedent une grande porteacutee et des deacutebits faibles
Lrsquoensemble de ces reacuteseaux sont deacutenommeacutes LPWAN Low Power Wide Area Network
113 Bande de freacutequence utiliseacutees En Europe les bandes de freacutequences libres (sans licence) sont
13 Mhz (RFID) 169 Mhz 434 Mhz 868 Mhz 24Ghz 5 Ghz et 24 Ghz (Faisceau Hertzien) Parmi ces
freacutequences seul le 433 MHz et 868 MHz sont utilisables en LoRa
12 Modes de partage du support Quel que soit le protocole utiliseacute le support de transfert de lrsquoinformation est lrsquoair car tous les
protocoles de lrsquoIoT sont Wireless Le support doit ecirctre partageacute entre tous les utilisateurs de telle
faccedilon que chacun des dispositifs Wireless ne perturbe pas les autres Pour cela une bande de
freacutequence est alloueacutee Par exemple pour la radio FM la bande de freacutequence va de 875 Mhz agrave 108
Mhz
Dans leur bande de freacutequence les dispositifs peuvent se partager le support de diffeacuterentes
maniegraveres
FDM (Frequency Division Multiplexing) Ce mode utilise une partie du spectre (bande de
freacutequence) en permanence Exemple Radio FM
TDM (Time Division Multiplexing) Ce mode utilise tout le spectre (bande de freacutequence) par
intermittence Exemple GSM on a laquo 8 time slots raquo par canal
CDMA (Code Division Multiple Access) Ce mode utilise tout le spectre tout le temps
Porteacutee (Range)
Deacutebit (Bandwidth)
| 8
Les Devices LoRa sont capables drsquoeacutemettre sur un mecircme canal en mecircme temps Le protocole LoRa
utilise une modulation tregraves similaire agrave la meacutethode 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 Plus
tard dans le cours nous expliquerons les diffeacuterences de la modulation LoRa
13 Notion drsquo eacutetalement de spectre utiliseacutee en LoRa Nous allons voir au travers drsquoun exercice comment il est possible drsquoutiliser tout le spectre en
permanence tout en eacutetant capable drsquoeffectuer plusieurs transactions simultaneacutees entre diffeacuterents
eacutemetteursreacutecepteurs Cette meacutethode est souvent appeleacutee laquo eacutetalement de spectre raquo car comme
son nom lrsquoindique elle a pour conseacutequence drsquoeacutetaler le spectre du signal transmis
La meacutethode consiste agrave utiliser des codes qui ont des proprieacuteteacutes matheacutematiques adapteacutees agrave notre
objectif Transmettre en mecircme temps sur la mecircme bande de freacutequence La matrice ci-dessous
donne par exemple 4 codes drsquoeacutetalement (1 par ligne)
Code Orthogonal User 0 1 1 1 1
Code Orthogonal User 1 1 -1 1 -1
Code Orthogonal User 2 1 1 -1 -1
Code Orthogonal User 3 1 -1 -1 1
Tableau 1 Matrice de Hadamart (matheacutematicien) dordre 4
Les proprieacuteteacutes de ces codes (1 1 1 1 1 -1 1 -1 1 1 -1 -1 1 -1 -1 1) ne sont pas expliqueacutees ici Nous
nous conterons de veacuterifier leur bon fonctionnement
131 Transmissions successives Chaque tableau ci-dessous repreacutesente une transmission qui est indeacutependante des autres elles ne
se deacuteroulent pas en mecircme temps On veacuterifie qursquoavec la mise en œuvre de laquo lrsquoeacutetalement de spectre raquo
chaque transmission arrive bien agrave destination avec le message qui avait eacuteteacute transmis Le premier
tableau est deacutejagrave rempli en guise drsquoexemple La meacutethode est la suivante
A lrsquoeacutemission
Chaque bit du message est multiplieacute par un code drsquoeacutetalement (une ligne de la matrice)
Le reacutesultat de la multiplication est transmis
A la reacuteception
Chaque symbole reccedilu est multiplieacute par le mecircme code drsquoeacutetalement
Le message reccedilu est eacutegal agrave la somme des symboles diviseacute par le nombre de symbole
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
hellip transmission hellip
4 Utilisation code orthogonal User 1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1
5 Deacutecodage = (3) x (4) 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0
6 Message reccedilu (sum (5) nbr_bits) 1 0 1 0
Reacutealiser la transmission du message du User 2 et du User 3 dans les tableaux suivants
| 9
1rsquo Message User 2 0 1 0 1
2rsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
3rsquo Symboles transmis User 2 = (1rsquo) x (2rsquo) 0 0 0 0
hellip transmission hellip
4rsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
5rsquo Deacutecodage = (3rsquo) x (4rsquo) 0 0 0 0
6rsquo Message reccedilu (sum (5rsquo) nbr_bits) 0
1rsquorsquo Message User 3 1 1 0 0
2rsquorsquo Utilisation code orthogonal User 3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
3rsquorsquo Symboles transmis User 3 = (1rsquorsquo) x (2rsquorsquo) 1 -1 -1 1
hellip transmission hellip
4rsquorsquo Utilisation code orthogonal User3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
5rsquorsquo Deacutecodage = (3rsquorsquo) x (4rsquorsquo) 1 1 1 1
6rsquorsquo Message reccedilu (sum (5rsquorsquo) nbr_bits) 1
132 Transmissions simultaneacutees
Les transmissions se deacuteroulent maintenant simultaneacutement les messages des User 1 User 2 et User
3 sont envoyeacutes en mecircme temps sur la mecircme bande de freacutequence La premiegravere colonne du User 1
est deacutejagrave remplie en guise drsquoexemple La meacutethode est la suivante
Dans lrsquoair
On additionne les symboles transmis par tous les User (1 2 3) ligne 1rsquorsquorsquo
Pour la reacuteception
Chaque symbole reccedilu est multiplieacute par le code drsquoeacutetalement du User
Le message reccedilu est eacutegal agrave la somme des symboles diviseacute par le nombre de symbole
Valider le fonctionnement pour la reacuteception des messages
1rsquorsquorsquo sum des symboles transmis ( 3 + 3rsquo + 3rsquorsquo ) 2 -2 0 0
2rsquorsquorsquo Utilisation code orthogonal User 1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 2 0 0
4rsquorsquorsquo Message reccedilu User 1 (sum (3rsquorsquorsquo) nbr_bits) 1
2rsquorsquorsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 -2 0 0
4rsquorsquorsquo Message reccedilu User 2 (sum (3rsquorsquorsquo) nbr_bits) 0
2rsquorsquorsquo Utilisation code orthogonal User 3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 2 0 0
4rsquorsquorsquo Message reccedilu User 3 (sum (3rsquorsquorsquo) nbr_bits) 1
133 Cas du protocole LoRa Le LoRa utilise une meacutethode drsquoeacutetalement de spectre qui nrsquoest pas exactement celle que nous venons
drsquoeacutetudier La finaliteacute est cependant la mecircme Pouvoir transmettre en mecircme temps sur le mecircme
canal Le protocole LoRa utilise sept laquo codes drsquoeacutetalement raquo appeleacutes Spreading Factor [ SF6 SF7 SF8
SF9 SF10 SF11 et SF12 ] qui lui permet drsquoavoir sept transmissions simultaneacutees sur un mecircme canal
| 10
2 Transmission radio et propagation
21 Les uniteacutes et deacutefinitions dB Rapport entre deux puissances Une atteacutenuation est repreacutesenteacutee par un nombre
neacutegatif (-) Un gain est repreacutesenteacute par un nombre positif (+)
Rapport de puissances en dB Rapport de puissance
+ 3 dB Multiplication par 2
- 3 dB Division par 2
0 dB Egaliteacute
+ 10 dB Multiplication par 10
- 10 dB Division par 10
Tableau 2 Comparaison entre les gains en dB et en proportion
dBi Gain theacuteorique drsquoune antenne
dBm Puissance rameneacutee agrave 1mW 0 dBm correspond agrave 1 mW
En reprenant la deacutefinition des dB remplir le tableau suivant
Puissance en dBm Puissance en mW
+ 3 dBm
- 3 dBm
+ 10 dBm
- 10 dBm
Tableau 3 Comparaison entre les puissances en dB et en mW
Le Talkie-Walkie a une puissance drsquoeacutemission de 2W Quelle est la puissance drsquoeacutemission
exprimeacutees en dBm
Sensibiliteacute Puissance minimale qursquoest capable de deacutetecter un reacutecepteur
RSSI Received Signal Strength Indication
SNR Signal over Noise Ratio
Un eacutemetteur transmet agrave une puissance de 13dBm en utilisant une antenne dont le gain
est de 2dBi Les pertes dans lrsquoair sont de 60 dB Lrsquoantenne reacuteceptrice qui possegravede un gain
de 2dBi est relieacutee agrave un reacutecepteur dont la sensibiliteacute est de -80 dBm Le signal pourra-t-il
ecirctre reccedilu
Le link Budget Crsquoest la quantiteacute de puissance que nous pouvons perdre avant drsquoarriver au
reacutecepteur tout en conservant une transmission fonctionnelle Autrement dit crsquoest la
puissance de lrsquoeacutemetteur moins la sensibiliteacute du reacutecepteur Dans lrsquoexemple preacuteceacutedent le
budget que nous avons agrave disposition est de 93dB
| 11
En LoRa nous avons un Link Budget de 157 dB
En LTE (4G) nous avons un Link Budget de 130 dB
Etude de la documentation drsquoun composant LoRa Le RN2483 est le composant radiofreacutequence que nous utiliserons dans notre transmission LoRa
Voici quelques une de ses caracteacuteristiques
Figure 3 Caracteacuteristiques principales du composant radiofreacutequence utiliseacute
Reprenez la deacutefinition du Link Budget et retrouver les 157 dB annonceacute dans cette
documentation
En LoRa plus le code drsquoeacutetalement est grand plus on est capable drsquoeacutemettre dans un milieu bruiteacute La
figure ci-dessous preacutesente les rapports signal sur bruit avec lesquels nous seront capable de reacutealiser
une transmission en fonction des Spreading Factor utiliseacutes
Figure 4 Influence du Spreading Factor sur le SNR acceptable
On remarque que pour un SF8 nous sommes capables drsquoeacutemettre avec un SNR de -10 dB On pourra
transmettre malgreacute le fait que le bruit est 10 fois supeacuterieur au signal
On remarque que pour un SF12 nous sommes capables drsquoeacutemettre avec un SNR de -20 dB On
pourra transmettre malgreacute le fait que le bruit est 100 fois supeacuterieur au signal
| 12
Cependant on remarque aussi que lrsquoutilisation drsquoun Spreading Factor plus eacuteleveacute augmente
consideacuterablement le nombre de symbole eacutemis (2egraveme colonne du tableau) Comme nous le verrons
plus tard cela impactera eacutevidement le temps de transmission
| 13
3 La couche physique LoRa
31 La modulation LoRa Comme nous lrsquoavons expliqueacute plus tocirct la modulation LoRa utilise lrsquoeacutetalement de spectre pour
transmettre ces informations Mais au lieu drsquoutiliser des codes drsquoeacutetalement (CDMA) elle utilise une
meacutethode appeleacutee Chirp Spread Spectrum La finaliteacute est toujours la mecircme Avoir plusieurs
transmissions dans le mecircme canal La conseacutequence sur le spectre est aussi la mecircme cela provoque
un eacutetalement du spectre
311 La forme du symbole (Chirp) Le signal eacutemis par la modulation LoRa est un symbole dont la forme de base est repreacutesenteacutee ci-
dessous Son nom (Chirp) vient du fait que ce symbole est utiliseacute dans la technologie Radar (Chirp
Compressed High Intensity Radar Pulse)
Figure 5 Symbole de la modulation LoRa (source Wikipeacutedia)
La freacutequence de deacutepart est la freacutequence centrale du canal moins la Bande Passante diviseacutee par deux
La freacutequence de fin est la freacutequence centrale plus la Bande Passante diviseacutee par deux
La freacutequence centrale est appeleacutee le canal
La bande passante est la largeur de bande occupeacutee autour du canal
On considegravere une eacutemission sur la freacutequence centrale 868 Mhz avec une Bande Passante
de 125 kHz Donner la freacutequence de deacutebut et la freacutequence de fin du sweep
Freacutequence de deacutebut
Freacutequence de fin
Pour faciliter la repreacutesentation de ce symbole on utilise plutocirct un graphique TempsFreacutequence de
la forme suivante
| 14
Figure 6 Forme du symbole de base (CHIRP)
En LoRa chaque symbole repreacutesente un certain nombre de bits transmis La regravegle est la suivante
Nombre de bits transmis dans un symbole = Spreading Factor
Par exemple si la transmission utilise un Spreading Factor de 10 (SF10) alors un symbole repreacutesente
10 bits
Crsquoest-agrave-dire qursquoagrave lrsquoeacutemission les bits sont regroupeacutes par paquet de SF bits puis chaque paquet est
repreacutesenteacute par un symbole particulier parmi 2119878119865formes de symboles possibles
Sur la figure suivante voici un exemple theacuteorique drsquoune modulation en SF2 agrave 868 Mhz sur une
bande passante de 125 kHz Chaque symbole repreacutesente donc 2 bits
Figure 7 Symboles eacutemis en Modulation LoRa (Cas theacuteorique en SF2)
Exemple
On considegravere la suite binaire suivante 0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Le Spreading Factor utiliseacute est SF10
Nous regroupons donc les bits par paquet de 10 Chaque paquet de 10 bits sera repreacutesenteacute par un
symbole (sweep) particulier Il y a 1024 symboles diffeacuterents pour coder les 1024 combinaisons
binaires possibles (210)
Freacutequence
Temps
868 000 000 Hz
868 062 500 Hz
Un symbole Un symbole
867 937 500 Hz
Temps
868 000 000 Hz
867 937 500 Hz
Symbole 0
Bits laquo 00 raquo
Symbole 1
Bits laquo 01 raquo
Symbole 2
Bits laquo 10 raquo Symbole 3
Bits laquo 11 raquo
12
5 k
Hz
868 062 500 Hz
| 15
Figure 8 Emission des Chirp en LoRa
Avec un outils drsquoanalyse spectrale actif pendant lrsquoeacutemission LoRa drsquoun Device on peut afficher les
successions de symbole qui sont envoyeacutes Cette oscillogramme a eacuteteacute reacutealiseacute agrave lrsquoaide drsquoun SDR
(Software Digital Radio)
Figure 9 Visualisation des Chirps LoRa reacuteellement eacutemis pendant une transmission
312 Dureacutee drsquoeacutemission drsquoun symbole En LoRa la dureacutee drsquoeacutemission de chaque symbole (Chirp) deacutepend du Spreading Factor utiliseacute Plus le
SF est grand et plus le temps drsquoeacutemission sera long Pour une mecircme bande passante le temps
drsquoeacutemission drsquoun symbole en SF8 est deux fois plus long que le temps drsquoeacutemission drsquoun symbole en
SF7 Ainsi de suite jusqursquoagrave SF12
0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Envoi de 1 Chirp Envoi de 1 Chirp Envoi de 1 Chirp
Transmission Transmission Transmission
| 16
Figure 10 Temps drsquoeacutemission drsquoun symbole (Chirp) en fonction du SF
En revanche le temps drsquoeacutemission drsquoun symbole est inversement proportionnel agrave la bande passante
119879119904 =2119878119865
119861119886119899119889119908119894119889119905ℎ Le deacutebit des symboles est donc de
1
119879119878= 119865119904 =
119861119886119899119889119908119894119889119905ℎ
2119878119865 En toute logique plus la
bande passant est eacuteleveacute plus le deacutebit des symboles sera eacuteleveacute Comme chaque symbole comprend
SF bit on retrouve alors le deacutebit binaire
119863119887 = 119878119865119861119886119899119889119908119894119889119905ℎ
2119878119865
Plus le Spreading Factor sera eacuteleveacute plus le deacutebit binaire sera faible
Plus la Bande Passante sera eacuteleveacutee plus le deacutebit binaire sera fort
Exemple Drsquoapregraves la formule du deacutebit binaire trouver le deacutebit pour les deux cas suivants
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
32 Coding Rate Le Coding Rate est un ratio qui augmentera le nombre de bits agrave transmettre afin de reacutealiser de la
deacutetection correction drsquoerreur Dans le cas drsquoun CR = 4 8 il y aura 8 bits transmis reacuteellement agrave
chaque fois que nous souhaitons transmettre 4 bits Dans cette exemple cela provoque une
transmission drsquoun nombre de bit multiplieacute par 2
SF7
Freacutequence
Temps
Freacutequence centrale
Freacutequence haute
Temps drsquoun symbole eacutemit en SF 12
Freacutequence basse
SF8
SF9
SF10
SF11
SF12
Temps drsquoun symbole eacutemit en SF 11
| 17
Figure 11 Influence du Coding Rate sur le nombre de bits ajouteacute
Si on reprend lrsquoexemple preacuteceacutedent avec un CR de 4 5 nous avons une augmentation de 125 du
nombre de bits agrave transmettre Redonner la deacutebit en prenant en compte le CR
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
La documentation du composant RN2483 donne les deacutebits en fonction du Spreading Factor
la Bande Passante et le Coding Rate Veacuterifier la coheacuterence du reacutesultat avec votre calcul
preacuteceacutedent
Figure 12 Deacutebit en fonction des paramegravetres de la transmission LoRa
33 Utilisation du LoRa Calculator Le logiciel laquo LoRa Calculator raquo est un petit exeacutecutable permettant de simuler une transmission LoRa
en fonction des caracteacuteristiques saisies Canal SF CR etchellip Il est teacuteleacutechargeable agrave lrsquoadresse
suivante httpsbitly2TyloAh
| 18
Figure 13 Le logiciel LoRa Calculator
En reprenant lrsquoexemple preacuteceacutedent (SF7 Bande Passante 125 kHz CR 45) veacuterifier les
calculs du laquo Equivalent Bitrate raquo
34 Time On Air La norme LoRaWAN impose qursquoun Device LoRa ne transmette pas plus de 1 du temps Cela est
repreacutesenteacute par un Duty Cycle Par exemple un Duty Cycle de 1 signifie que si jrsquoeacutemet pendant 1 je
ne dois plus eacutemettre pendant 99 quel que soit lrsquouniteacute de temps utiliseacutee
En reprenant les exemples preacuteceacutedents quels sont les deacutebits moyens si on prend en compte
le laquo Time On Air raquo
Cas 1 Pour SF7 et 125 khz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
Dans le logiciel laquo LoRa Calculator raquo (onglet laquo Energy Profile raquo) nous pouvons estimer la
dureacutee de vie drsquoune batterie Nous prenons lrsquoexemple drsquoun releveacute de tempeacuterature dans un
bacirctiment avec les caracteacuteristiques suivantes
| 19
SF CR Bande Passante etc Nous nous placcedilons dans le cas 1 des exemples preacuteceacutedents
Le releveacute de tempeacuterature se fera toutes les 15 mins
La batterie est constitueacute de 3 petites piles bacirctons [ AAA LR03 ] 12V en seacuterie Soit 36 V
1000 mAh
35 Mise en œuvre LoRa en point agrave point Ce test sera reacutealiseacute avec des modules LoRa RN2483 (Microchip) et une carte microcontrocircleur
ARDUINO
Figure 14 Communication LoRa en Point agrave Point
Reacutealiser le cacircblage de votre module RN2483 suivant le tableau suivant
Connecteur Arduino Click Board RN2483
5V 5V
GND GND
11 RX
10 TX
Tableau 4 Cacircblage de lrsquoARDUINO et de la click Board RN2483
351 Utilisation de lrsquoIDE Arduino Lrsquoenvironnement Arduino est tregraves simple Nous allons reacutealiser un programme pour montrer son
fonctionnement
La connexion de la carte est effectueacutee agrave lrsquoaide drsquoun port USB qui eacutemule une liaison seacuterie
RS232 Il faut donc choisir le bon port Arduino IDE gt Outils gt Port
Pour creacuteer un nouveau programme (sketch) Arduino IDE gt Fichier gt Nouveau
Il y a deux parties dans un sketch
Une fonction setup() qui sera exeacutecuteacutee qursquoune seule fois au deacutemarrage
Une fonction loop() qui sera exeacutecuteacutee en boucle
Ecrire le code suivant
Emetteur
Reacutecepteur
UA
RT
UA
RT
| 20
void setup()
Serialbegin(9600)
void loop()
Serialprintln(hello word)
Compiler et Teacuteleacuteverser Croquis gt Teacuteleacuteverser
Voir la sortie sur la liaison seacuterie Outils gt Moniteur Seacuterie gt Choisir la vitesse de
transmission ici 9600 bauds (en bas agrave droite)
352 Validation du fonctionnement Deux binocircmes joueront le rocircle drsquoeacutemetteur tous les autres binocircmes seront en reacutecepteur
Reacutecupeacuterer les programmes dans Moodle dans le dossier laquo RN2483-Arduino-Point2Point raquo
Installer la librairie RN2483 Arduino IDE gt Croquis gt Inclure une bibliothegraveque gt Ajouter la
bibliothegraveque zip
Reacutepartissez les rocircles Emetteurs Reacutecepteurs et reacutecupeacuterer le programme LoraBlinkerRX ou
LoraBlinkerTX en fonction Les 2 binocircmes en eacutemission devront modifier le code du sketch
Arduino pour transmettre des donneacutees speacutecifiques afin de les diffeacuterencier [
loraSerialprintln(radio tx 30) ]
Validez la reacuteception des donneacutees eacutemises par les deux binocircmes qui transmettent des
donneacutees Ces donneacutees reccedilues sont eacutecrite agrave 57600 bauds sur le moniteur seacuterie de lrsquoArduino
353 Mise en valeur du Spreading Factor On srsquoaperccediloit dans la manipulation preacuteceacutedente que les Devices LoRa reccediloivent les donneacutees des deux
eacutemetteurs Nous allons conserver le mecircme canal drsquoeacutemission (8691 Mhz) mais un des deux
eacutemetteurs va modifier son laquo Spreading Factor raquo La salle sera donc seacutepareacutee en deux groupes
1er groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF7
2egraveme groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF8
Validez la reacuteception des donneacutees eacutemises seulement pour le Spreading Factor que vous
utilisez
| 21
4 Le protocole LoRaWAN
Le LoRa est le type de modulation utiliseacute entre deux Devices ou entre un Device et une Gateway
Lorsque nous parlons de lrsquoensemble de la chaine de communication (Device Gateway Serveur) alors
nous parlons de communication LoRaWAN Nous allons voir lrsquoarchitecture drsquoun reacuteseau LoRaWAN
ainsi que les regravegles de ce protocole
41 Structure drsquoun reacuteseau LoRaWAN Nous retrouvons drsquoun cocircteacute le Device LoRa qui transmet une donneacutee Elle est reacuteceptionneacutee agrave lrsquoautre
extreacutemiteacute du reacuteseau par un Utilisateur La structure globale du reacuteseau LoRaWAN peut ecirctre
repreacutesenteacutee par la figure suivante
411 Les Devices LoRa Les Devices LoRa sont des systegravemes eacutelectroniques appartenant au monde de lrsquoIoT Faible
consommation faible taille faible puissance et faible taille
Ils possegravedent une radio LoRa permettant de joindre les Gateways Les Gateways ne sont pas
adresseacutees speacutecifiquement toutes celles preacutesentes dans la zone de couverture reccediloivent les
messages et les traitent
412 Les Gateways LoRa Elles eacutecoutent sur tous les canaux et sur tous les Spreading Factor Lorsqursquoune trame LoRa est reccedilue
elle transmet son contenu sur internet agrave destination du Network Server qui a eacuteteacute configureacute dans la
Gateway au preacutealable
Elle joue donc le rocircle de passerelle entre une modulation LoRa et une communication IP
Devices
LoRa Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
Internet Internet
Figure 15 Structure globale dun reacuteseau LORAWAN
| 22
Chaque Gateway LoRa possegravede un identifiant unique (EUI sur 64 bits)
413 Le Network Server
Le Network Server reccediloit les messages transmis par les Gateways et supprime les doublons
(plusieurs Gateway peuvent avoir reccedilu le mecircme message) Les informations transmises au Network
Server depuis les Devices LoRa sont authentifieacutes gracircce agrave une cleacute AES 128 bits appeleacutee Network
Session Key NwkSKey Nous parlons bien ici drsquoauthentification et non pas de chiffrement comme
nous le verrons plus tard
414 Application Server Il est souvent sur le mecircme support physique que le Network Server Il permet de dissocier les
applications les unes des autres Chaque application enregistre des Devices LoRa qui auront le droit
Devices Gateways Network
Server
Internet
Network Session Key (NwkSKey)
Authentification
Figure 17 Authentification entre le Device LoRa et le Network Server
Internet
UDP IP
Modulation
LoRa
Device LoRa
Gateway
Network Server
LoRaWAN
Modulation
LoRa
Passerelle LoRa Internet
Internet
UDP IP
LoRaWAN
Transmission Radio
Application Application
Figure 16 Le rocircle de la Gateway LoRa
| 23
de stocker leurs donneacutees (Frame Payload) Les message transmis agrave lrsquoapplication server sont chiffreacutes
gracircce agrave une cleacute AES 128 bits appeleacutee Application Session Key AppSKey
Le scheacutema suivant reacutesume lrsquoutilisation
De la Network Session Key (NwkSKey) pour lrsquoauthentification entre le Device LoRa et le
Network Server
De lrsquoApplication Session Key (AppSKey) pour le chiffrement entre le Device LoRa et
lrsquoApplication Server
Devices Gateways Network
Server Application
Server
Internet
Application Session Key (AppSKey)
Chiffrement
Figure 18 Chiffrement entre le Device LORA et lrsquoApplication Server
| 24
415 Application Web Serveur Cette application doit drsquoune part reacutecupeacuterer les donneacutees de lrsquoApplication Serveur Dans le cadre de
ce cours cela sera fait de deux faccedilons
Avec le protocole HTTP
Avec le protocole MQTT
Figure 20 Application Web Server
Figure 19 Authentification et chiffrement en LoRaWan
Devices Gateways
Network
Server Application
Server
Internet
Network Session Key
Application Session Key
Network
Server Application
Server
Application
Server Web
Utilisateur
Protocole
MQTT ou HTTP
Flux Uplink
Flux Downlink
| 25
Le flux habituel dans lrsquoIoT est le flux Uplink (flux montant) crsquoest-agrave-dire lrsquoeacutemission de donneacutees des
objets vers le serveur Comme nous lrsquoexpliquerons plus loin en LoRaWAN il est aussi possible de
transfeacuterer des donneacutees aux Device LoRa par un flux Downlink (flux descendant)
Drsquoautre part lrsquoapplication mettra agrave disposition les donneacutees aux utilisateurs sous forme par exemple
drsquoun serveur web drsquoune base de donneacutees et drsquoune visualisation graphique
416 Authentification avec le Network Server La Network Session Key (NwkSKey) sert agrave lrsquoauthentification entre le Device LoRa e le Network Server
Afin de reacutealiser cette authentification entre le Device et le Network Server un champ MIC (Message
Integrity Control) est rajouteacute agrave la trame Il est calculeacute en fonction des donneacutees transmises et du
NwkSkey A la reacuteception le mecircme calcul est effectueacute Si les cleacutes sont eacutequivalentes dans le Device et
dans le Network Server alors les deux MIC calculeacutes doivent correspondre
417 Chiffrement des donneacutees vers lrsquoApplication Server
LrsquoApplication Session Key (AppSKey) sert pour le chiffrement entre le Device LoRa et lrsquoApplication
Server Les donneacutees chiffreacutees seront alors deacutecodeacutees agrave la reacuteception sur lrsquoApplication Server srsquoil
possegravede la mecircme cleacute Si on reprend le scheacutema preacuteceacutedent les laquo donneacutees x raquo sont chiffreacutees
deacutechiffreacutees par le processus suivant
Donneacutees x chiffreacutees NwkSkey x
MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees
NwkSkey x
Trame eacutemise Trame reccedilue
Device LoRa Network Server
Si =
Alors la trame est authentifieacutee
MIC geacuteneacutereacute Emission MIC geacuteneacutereacute Reacuteception
MIC geacuteneacutereacute Reacuteception
Figure 21 Authentification dun Device LoRa par le Network Server
| 26
Figure 22 Chiffrement des donneacutees par lApplication Session Key
418 Combinaison de lrsquoauthentification et du chiffrement On peut maintenant repreacutesenter sur le mecircme scheacutema la construction de la trame LoRaWAN avec
drsquoune part lrsquoauthentification et drsquoautre part le chiffrement
Figure 23 Chiffrement puis Authentification
42 Classes des Devices LoRaWAN Les Devices LoRa sont classeacutes en 3 cateacutegories (A B C) en fonction de leur consommation et de leur
accessibiliteacute en Downlink crsquoest-agrave-dire la faciliteacute qursquoun utilisateur aura agrave transmettre une trame au
Device LoRa
421 Classe A (All) Minimal power Application Tous les Devices LoRaWAN sont de classe A Chaque Device peut transmettre (Uplink) agrave la Gateway
sans veacuterification de la disponibiliteacute du reacutecepteur Si la transmission eacutechoue elle sera reacuteeacutemise apregraves
un certain temps Cette transmission est suivie de 2 fenecirctres de reacuteception tregraves courtes La Gateway
peut alors transmettre pendant le laquo RX Slot 1 raquo ou le laquo RX Slot 2 raquo mais pas les deux
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Device LoRa
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Application Server
Donneacutees non chiffreacutees
AppSKey
Donneacutees chiffreacutees Entecircte
NwkSKey
MIC geacuteneacutereacute en eacutemission Trame transmise =
| 27
Figure 24 Slots de reacuteception pour un Device LoRa de classe A
Source de lrsquoimage httpszakelijkforumkpncom
La dureacutee des fenecirctres doit ecirctre au minimum la dureacutee de reacuteception drsquoun preacuteambule Un preacuteambule
dure 1225 Tsymbole et deacutepend donc du Data Rate (DR voir paragraphe 445 pour plus drsquoinformation
sur le DR) Lorsque qursquoun preacuteambule est deacutetecteacute le reacutecepteur doit rester actif jusqursquoagrave la fin de la
transmission Si la trame reccedilue pendant la premiegravere fenecirctre de reacuteception eacutetait bien agrave destination du
Device LoRa alors la deuxiegraveme fenecirctre nrsquoest pas ouverte
Premiegravere fenecirctre de reacuteception
Le Slot RX1 est programmeacute par deacutefaut agrave 1 seconde + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont les mecircme que ceux choisis lors de la phase drsquoeacutemission
(Uplink)
Seconde fenecirctre de reacuteception
Le Slot RX2 est programmeacute par deacutefaut agrave 2 secondes + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont configurables mais fixes
Un Device LoRa qui est uniquement de classe A ne peut pas recevoir srsquoil nrsquoa pas eacutemis Il
nrsquoest donc pas joignable facilement
422 Classe B (Beacon) Scheduled Receive Slot Les Devices de classe B ont le mecircme comportement que les Devices de classe A mais drsquoautres
fenecirctres de reacuteceptions sont programmeacutees agrave des peacuteriodes preacutecises Afin de synchroniser les fenecirctres
de reacuteception du Device LoRa la Gateway doit transmettre des balises (Beacons) de faccedilon reacuteguliegravere
| 28
Figure 25 Slots de reacuteception pour un Device LoRa de classe B
Source de lrsquoimage httpszakelijkforumkpncom
Un Device LoRa de classe B est joignable reacuteguliegraverement sans qursquoil soit neacutecessairement
obligeacute drsquoeacutemettre En revanche il consomme plus qursquoun Device de classe A
423 Classe C (Continuous) Continuously Listening Les Devices de classe C ont des fenecirctres de reacuteception constamment ouvertes entre 2 Uplinks Ces
Devices consomment donc beaucoup plus
Figure 26 Slots de reacuteception pour un Device LoRa de classe C
Source de lrsquoimage httpszakelijkforumkpncom
| 29
Un Device LoRa de classe C est joignable en permanence En revanche crsquoest la classe de
Device qui est la plus eacutenergivore
424 Quelle Gateway pour les flux Downlink
Nous avons donc vu que le fonctionnement classique du protocole LoRaWAN eacutetait de reacutecupeacuterer de
lrsquoinformation depuis le Device LoRa Crsquoest le flux Uplink
Dans le cas ougrave lrsquoutilisateur transmet des informations au Device LoRa (flux Downlink) on peut se
demander quelle Gateway sera choisie pour transfeacuterer les donneacutees au Device LoRa En effet
lrsquoendroit ougrave est situeacute le Device LoRa nrsquoest pas neacutecessairement connu agrave lrsquoavance
La Gateway utiliseacutee pour le Downlink est celle qui a reccedilu le dernier message du Device
LoRa Un message ne pourra jamais arriver agrave destination drsquoun Device LoRa si celui-ci nrsquoa
jamais transmis quel que soit sa classe A B ou C
43 Activation des Devices LoRa et seacutecuriteacute En LoRaWAN les trois eacuteleacutements indispensables pour la communication sont le DevAddr pour
lrsquoindentification du Device ainsi que deux cleacutes le NwkSKey pour lrsquoauthentification et lrsquoAppSKey
pour le chiffrement Deux meacutethodes sont possibles pour fournir ces informations agrave la fois au Device
LoRa et au serveur
Activation By Personalization APB
Over The Air Activation
431 ABP Activation By Personalization Crsquoest la plus simple des meacutethodes Crsquoest donc peut ecirctre celle que nous avons tendance agrave utiliser lors
drsquoun test de prototype et drsquoune mise en place de communication LoRaWAN
Le Device LoRa possegravede deacutejagrave le DevAddr lrsquoAppSKey et le NwkSKey
Le Network server possegravede deacutejagrave le DevAddr et le NwkSKey
Lrsquoapplication serveur possegravede deacutejagrave le DevAddr et le AppSKey
En ABP toutes les informations neacutecessaires agrave la communication sont deacutejagrave connues par le
Device LoRa et par le Serveur
| 30
432 OTAA Over The Air Activation Crsquoest la meacutethode qursquoil faut privileacutegier car crsquoest celle qui est la plus seacutecuriseacutee Le Device LoRa doit
connaitre le DevEUI lrsquoAppEUI et lrsquoAppkey Le Network Server doit lui connaitre la mecircme Appkey
Tous les eacuteleacutements noteacutes EUI (Extended Unique Identifier) sont toujours sur une taille de
64 bits
Gracircce agrave ces informations de deacutepart et une neacutegociation avec le Network Server (Join Request) le
Device LoRa et le serveur vont geacuteneacuterer les informations essentielles DevAddr NwkSKey et
AppSKey
Figure 28 Obtention du DevAddr NwkSKey et AppSKey en OTAA
DevEUI Unique Identifier pour le device LoRa (Equivalent agrave une MAC sur Ethernet)
Certains Device LoRa ont deacutejagrave un DevEUI fourni en usine
AppEUI Unique Identifier pour lrsquoapplication server
DevEUI
AppEUI
AppKey
Join
Request
DevAddr
NwkSKey
AppSKey
Network Server
Application Server
Devices 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 2
NwkSkey 2
AppSKey 2
Devices 2
DevAddr 2
NwkSkey 2
AppSKey 2
Paramegravetres stockeacutes sur le serveur
Paramegravetres programmeacutes
dans le composant
Figure 27 Parameacutetrage de DevAddr NwkSKey et AppSKey
| 31
AppKey AES 128 cleacute utiliseacutee pour geacuteneacuterer le MIC (Message Code Integrity) lors de la Join
Resquest Il est partageacute avec le Network server
NwkSKey Utiliseacute pour lrsquoauthentification avec le Network Server
AppSKey Utiliseacute pour le chiffrement des donneacutees
433 Seacutecuriteacute Les cleacutes AES 128 bits permettent le chiffrement des informations transmises en LoRaWAN Malgreacute
ce chiffrement une attaque connue en Wireless est celle du REPLAY Crsquoest-agrave-dire que le Hacker
enregistre des trames chiffreacutees circulant sur le reacuteseau LoRa pour les reacuteeacutemettre plus tard Mecircme si
le Hacker ne comprend pas le contenu (les trames sont chiffreacutees) les donneacutees qui sont transporteacutees
sont elles bien comprises par lrsquoApplication Server Des actions peuvent donc ecirctre reacutealiseacutees
simplement par mimeacutetisme
Pour eacuteviter cela la trame LoRaWAN integravegre un champ variable appeleacute laquo Frame Counter raquo Il srsquoagit
drsquoun nombre numeacuterotant la trame sur 16 ou 32 bits LrsquoApplication Server acceptera une trame
uniquement si le laquo Frame Counter raquo reccedilu est supeacuterieur au laquoFrame Counter raquo preacuteceacutedemment Donc
si le Hacker retransmet la trame telle qursquoelle le laquo Frame Counter raquo sera eacutequivalent donc la trame
sera refuseacutee Et comme la trame est chiffreacutee le Hacker nrsquoa pas moyen de savoir comment modifier
un champ de cette trame
Cette seacutecuriteacute impleacutementeacutee par les laquo Frame Counter raquo est inteacuteressante pour srsquoaffranchir drsquoune
attaque par REPLAY mais dans nos tests cela peut poser problegraveme En effet agrave chaque fois que nous
redeacutemarrons le microcontrocircleur notre laquo Frame Counter raquo revient agrave zeacutero alors que celui de
lrsquoApplication Server continue de srsquoincreacutementer Cela peut ecirctre reacutesolue par diffeacuterentes maniegraveres
1 Deacutesactivation du laquo Frame Counter Check raquo Dans certain Application Server cette option
peut ecirctre proposeacutee Bien sucircr il faudra garder en tecircte la faille de seacutecuriteacute que cela engendre
Network Server
Application Server
Devices LoRa
NwkSkey
AppSKey
NwkSkey
AppSKey Hacker
(1) (2)
(1) Ecoute
(2) Reacuteeacutemission
Figure 29 Attaque par REPLAY
| 32
Figure 30 Deacutesactivation du Frame Counter Check dans TTN
2 Utiliser lrsquoauthentification par OTAA au lieu de ABP En effet agrave chaque ouverture de session
en OTAA le laquo Frame Counter raquo est reacuteinitialiseacute coteacute serveur
3 Conserver la valeur du laquo Frame Counter raquo dans une meacutemoire non volatile et reacutecupeacuterer sa
valeur au deacutemarrage du Device LoRa
44 La Trame LoRa LoRaWAN
441 Les couches du protocole LoRaWAN
Lorsque nous avons fait une communication en Point agrave Point nous avons simplement utiliseacute la
couche physique de la modulation LoRa Lorsque nous souhaitons utiliser le protocole LoRaWAN
des couches protocolaires suppleacutementaires se rajoutent
Figure 31 Les couches protocolaires du LoRaWAN
Chaque couche rajoute un service Lors de lrsquoenvoi de la trame les donneacutees utilisateurs sont donc
encapsuleacutees dans chaque couche infeacuterieure jusqursquoagrave la transmission Le deacutetail de lrsquoensemble de la
trame LoRaWAN par couche est deacutecrit sur la figure Figure 32
LoRa Modulation
LoRa Mac
Application
Couche Physique
Couche Mac
Couche Application
| 33
442 Couche Application La couche Application accueille les donneacutees de lrsquoutilisateur Avant de les encapsuler elles sont
chiffreacutees avec lrsquoAppSKey afin de seacutecuriser la transaction
Un ensemble de champs nommeacute Frame Header permet de speacutecifier le DevAddr le Frame Control
le Frame Counter et le Frame Option
Le Frame Port deacutepend du type drsquoapplication et sera choisi par lrsquoutilisateur
Le Frame Payload sont les donneacutees chiffreacutees agrave transmettre Le nombre drsquooctets maximum pouvant
ecirctre transmis (N octets) est donneacute dans le tableau suivant
PHY Payload
P octets Couche
Physique
Couche
Mac
Couche
Application
CRC
2 octets Header + Header CRC
20 bits Preamble
MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Figure 32 Trame LORAWAN complegravete par couche protocolaire
Couche
Application Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Frame Header
Figure 33 Trame LORA couche Applicative
| 34
Data Rate Spreading Factor Bandwidth Max Frame Payload (Nombre N) DR 0 SF12 125 KHz 51 octets
DR 1 SF11 125 KHz 51 octets
DR 2 SF10 125 KHz 51 octets
DR 3 SF9 125 KHz 115 octets
DR 4 SF8 125 KHz 222 octets
DR 5 SF7 125 KHz 222 octets
DR 6 SF7 250 KHz 222 octets
Tableau 5 Taille maximum du Frame Payload en fonction du Data Rate
443 Couche LoRa MAC Cette trame est destineacutee au Network Server Elle est authentifieacutee gracircce au champ MIC (Message
Integrity Protocol) selon la meacutethode expliqueacutee au paragraphe 416
Le protocole LoRa MAC est composeacute de
1 MAC Header Version de protocole et type de message
Type de Message Description 000 Join-Request
001 Join-Accept
010 Unconfirmed Data Up
011 Unconfirmed Data Down
100 Confirmed Data Up
101 Confirmed Data Down
110 Rejoin-request
111 Proprietary
Tableau 6 Les types de messages transmis en LoRaWAN
2 MAC Payload Contient tout le protocole applicatif
3 MIC Message Integrity Code pour lrsquoauthentification de la trame
444 Couche physique Modulation LoRa
Le choix du moment drsquoeacutemission des Devices LoRa se fait de faccedilon simple Lorsqursquoun eacutequipement
doit eacutemettre il le fait sans controcircle et ne cherche pas agrave savoir si le canal est libre Si le paquet a eacuteteacute
perdu il le retransmettra simplement au bout drsquoun temps aleacuteatoire La couche physique est
repreacutesenteacutee par lrsquoeacutemission de la trame suivante
Couche
Mac MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Figure 34 Trame LORA couche LORA MAC
| 35
Le Preacuteambule est repreacutesenteacute par 8 symboles + 425 Le temps du Preacuteambule est donc de 1225
Tsymbole
Len-tecircte (Header optionnel) est seulement preacutesent dans le mode de transmission par deacutefaut
(explicite) il est transmis avec un Coding Rate de 48 Il indique la taille des donneacutees le Coding Rate
pour le reste de la trame et il preacutecise eacutegalement si un CRC sera preacutesent en fin de trame
Le PHY Payload contient toutes les informations de la Couche LoRa MAC
Le CRC sert agrave la deacutetection drsquoerreur de la trame LoRa
445 Canaux et bandes de freacutequences et Data Rate (DR) Le LoRa utilise des bandes de freacutequences diffeacuterentes suivant les reacutegions du monde En Europe la
bande utiliseacutee est celle des 868 Mhz [ De 863 Mhz agrave 870 Mhz ] Le LoRaWAN deacutefinie les 8 canaux agrave
utiliser pour communiquer avec une Gateway suivant le tableau suivant
Canaux Spreading Factor Bandwidth 8681 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz SF7 250 kHz
8685 Mhz De SF7 agrave SF12 125 kHz
8671 Mhz De SF7 agrave SF12 125 kHz
8673 Mhz De SF7 agrave SF12 125 kHz
8675 Mhz De SF7 agrave SF12 125 kHz
8677 Mhz De SF7 agrave SF12 125 kHz
8679 Mhz De SF7 agrave SF12 125 kHz
Tableau 7 Canaux SF et Bandwidth de notre Gateway LoRaWAN
Une Gateway LoRa eacutecoute donc sur 8 canaux simultaneacutement avec les 6 Spreading Factor
diffeacuterents soit 48 combinaisons possibles
Comme nous lrsquoavons vu le Spreading Factor a des conseacutequences sur le deacutebit de la transmission Ces
deacutebits sont noteacutes DR (Data Rate) et sont normaliseacutes de DR0 agrave DR6
PHY Payload
P octets Couche
Physique CRC
2 octets Header + Header CRC
( Optionnel ) 20 bits Preamble
Figure 35 Trame LORA couche Physique
| 36
Data Rate Spreading Factor Bandwidth DR 0 SF12 125 KHz
DR 1 SF11 125 KHz
DR 2 SF10 125 KHz
DR 3 SF9 125 KHz
DR 4 SF8 125 KHz
DR 5 SF7 125 KHz
DR 6 SF7 250 KHz
Tableau 8 Deacutenomination DR en fonction du SF et de la Bande Passante
446 Trame reccedilue et transmise par la Gateway LoRaWAN La Gateway reccediloit drsquoun cocircteacute un message radio moduleacute en LoRa et transmet de lrsquoautre cocircteacute une trame
IP agrave destination du Network Server
Coteacute interface Radio La Gateway reacuteceptionne une trame LoRaWAN et extrait le PHY Payload Celui-
ci est codeacute au format ASCII en base 64 (voir le paragraphe 541) La Gateway extrait aussi toutes les
informations utiles sur les caracteacuteristiques de la reacuteception qui a eu lieu SF Bandwidth RSSI Time
On Airhellipetchellip
Coteacute interface reacuteseau IP La Gateway transmet lrsquoensemble de ces informations dans un paquet IP
(UDP) au Network Server Les donneacutees transmises sont du texte en format JSON (voir paragraphe
447) La Gateway a donc bien un rocircle de passerelle entre le protocole LoRa drsquoun cocircteacute et un reacuteseau
IP de lrsquoautre
Internet
UDP IP
Device LoRa
Gateway
Network Server Modulation
LoRa
Passerelle LoRa Internet
Transmission Radio Internet
Figure 36 Rocircle de la Gateway LoRa
| 37
447 Le format JSON Le format JSON est un format texte composeacute drsquoune succession de couple nomvaleur Dans
lrsquoexemple de la figure preacuteceacutedente gw_id est un nom et eui-b827ebfffeae26f5 est la valeur
associeacutee Dans cette exemple la valeur est un string Les objets sont deacutelimiteacutes par un des accolades
et
Une valeur peut ecirctre
Un string exemple coding_rate 45
Un nombre exemple spreading_factor 12
Un objet exemple lora spreading_factor 12 air_time 2465792000
Un Boolean
Ethernet
Gateway
Modulation
LORA
Reacutecupeacuteration du PHY PAYLOAD en base 64
Reacutecupeacuteration des caracteacuteristiques de la transmission Canal SF CR hellip
IP (IP dest routereuthethingsnetwork)
UDP (Port dest 1700 Port source 1700)
Donneacutees applicatives (format JSON)
gw_id eui-b827ebfffeae26f5
payload QNAPvA6Ax3ECqHk4C8hfzuA==
lora
spreading_factor 12
bandwidth 125
air_time 2465792000
coding_rate 45
timestamp 2019-01-20T133746017Z
rssi -105
snr -162
dev_addr 0EBC0FD0
frequency 867100000
Internet Transmission Radio LORA
Figure 37 Passerelle (Gateway) LORAWAN
| 38
5 Mise en œuvre drsquoun reacuteseau LoRaWAN
51 Les diffeacuterents types de reacuteseaux Les reacuteseaux LoRaWAN peuvent ecirctre utiliseacute suivant deux meacutethodes
En utilisant les reacuteseaux LoRaWAN opeacutereacutes proposeacutes par les opeacuterateurs de teacuteleacutecoms
En utilisant votre propre reacuteseau LoRaWAN priveacute
511 Les reacuteseaux LoRaWAN opeacutereacutes Ce sont des reacuteseaux LoRaWAN proposeacutes par les opeacuterateurs Par exemple Objenious (filiale de
Bouyges) ou encore Orange Dans le cas de lrsquoutilisation des reacuteseaux opeacutereacutes lrsquoutilisateur a juste
besoin de srsquooccuper des Devices LoRa Les Gateways le Network Server et lrsquoApplication Server sont
geacutereacutes par lrsquoopeacuterateur
512 Les reacuteseaux LoRaWAN priveacutes Chacun est libre de reacutealiser son propre reacuteseau priveacute en impleacutementant sa propre Gateway pour
communiquer avec ses Devices LoRa Lrsquoimpleacutementation du Network Server et de lrsquoApplication Server
peuvent alors ecirctre envisageacutes de diffeacuterentes faccedilons
Network Server et Application serveur priveacutees Crsquoest le deacuteveloppeur qui les mets en place Dans
certaines Gateways une impleacutementation de ces deux serveurs est deacutejagrave proposeacutee Sinon il est
possible de la mettre en place Il existe des serveurs (Network et Application) open source crsquoest le
cas par exemple de LoRa Serveur [ wwwloraserverio ]
Une autre alternantive est httpsgithubcomgotthardplorawan-server
LoRaServer et lorawan-server sont deux applications Open Source
Network Server et Application Server en ligne Un certain nombre de Network Server et
drsquoApplication Server sont proposeacutes Ce sont des services payants ou avec des contreparties
Loriot [ wwwloriotio ]
ResIoT [ wwwresiotio ]
The Things Network [ wwwthethingsnetworkorg ] Crsquoest la solution que nous utiliserons
513 Les zones de couvertures
Les zones de couvertures des reacuteseaux opeacutereacutes sont mise agrave jour par les opeacuterateurs celle drsquoobjenious
est par exemple disponible ici httpsobjeniouscomreseau
Pour connaitre la zone de couverture de notre Gateway utiliseacutee avec TTN nous pouvons utiliser
lrsquoapplication TTN Mapper httpsttnmapperorg Lrsquoideacutee est de promener son Device LoRa associeacute
agrave un GPS dans la zone de couverture des Gateway qui nous entourent A chaque trame reccedilue par le
| 39
Serveur on note les coordonneacutees GPS du Device LoRa ainsi que la Gateway qui a transmis le
message Toutes ces informations sont alors retranscrites sur une carte
52 The Things Network (TTN)
521 Preacutesentation de TTN
Pour la suite nous utiliserons le Network Server et lrsquoApplication Server fourni par TTN
[wwwthethingsnetworkorg]
TTN est gratuit et Open Source En revanche le fait drsquoutiliser TTN impose agrave ceux qui enregistrent
des Gateways de les mettre agrave disposition agrave tous les autres utilisateurs de TTN Lrsquoobjectif est de
reacutealiser un reacuteseau global ouvert
522 Configuration de la Gateway A lrsquouniversiteacute nous avons deux Gateways LoRa (Marque EBDS) Elles sont toutes les deux situeacutees sur
le Campus de Technolac Une Gateway est agrave lrsquointeacuterieur du bacirctiment ISERAN et sert essentiellement
pour les Travaux Pratiques et formations Lrsquoautre est sur le toit du bacirctiment Chablais et est mise agrave
disposition du public via le service de TTN
Les deux Gateway eacutecoutent sur tous les canaux et sur tous les Spreading Factor SF7 gt SF12
Lrsquo IP de la Gateway LoRa agrave lrsquouniversiteacute (bacirctiment ISERAN) est 192168140196
Serveur DNS 1934812032 19348129137
Network Server (TTN) 137616868 routereuthethingsnetwork
Port Upstream 1700 Port Downstream 1700
523 Enregistrement des Gateways Appplication et Devices La configuration de TTN se fait en ligne La premiegravere opeacuteration agrave reacutealiser lorsqursquoune nouvelle
Gateway est deacuteployeacutee crsquoest de lrsquoenregistrer dans TTN
Enregistrement drsquoune Gateway LoRa TTN gt Console gt Gateway gt register gateway
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Figure 38 Scheacutema de notre application
| 40
Figure 39 Enregistrement dune Gateway LoRa sur TTN
Enregistrement drsquoune application TTN gt Console gt Application gt add application
Figure 40 Enregistrement dune application sur TTN
Enregistrement des Devices LoRa dans lrsquoapplication Nom de lrsquoapplication gt register device
Figure 41 Enregistrement des Devices LoRa dans une application
524 Configuration des Devices LoRa Lorsque nous avons enregistreacute des Devices LoRa dans TTN nous devons choisir entre les deux modes
drsquoauthentification Dans un premier temps nous utiliserons le mode le plus simple qui est ABP Nous
geacuteneacuterons dans TTN les DevAddr NetwkSKey et AppSKey
| 41
Figure 42 Configuration des Devices LoRa en ABP dans TTN
53 Mise en application Nous avons dans notre application 10 Devices LoRa drsquoenregistreacutes aduino0 agrave arduino9 Ils sont tous
configureacutes en ABP Les configurations des 10 Devices (DevAddr NetwkSKey et AppSKey) sont noteacutes
en commentaire dans le code de vous allez reacutecupeacuterer
Reacutecupeacuterer le code Arduino laquo RN2483-Arduino-LORAWANino raquo dans Moodle
Modifier votre configuration (DevAddr NetwkSKey et AppSKey) en fonction de votre
numeacutero de binocircme
Veacuterifier que votre Device LoRa arrive bien agrave transmettre des informations (Uplink) vers la
Gateway puis vers le Network Serveur de TTN (The Things Network)
54 Analyse des trames eacutechangeacutees
541 Utilisation de la base 64 Notre Gateway nous preacutesente le Payload PHY en base64 Lrsquoexplication de la meacutethode de
repreacutesentation en base 64 est fourni au travers drsquoun exemple Le code hexadeacutecimal 0x4869
repreacutesente nos donneacutees binaires que nous souhaitons transmettre en base 64
1 On eacutecrit les donneacutees agrave transmettre en binaire
2 On regroupe les eacuteleacutements binaires par des blocs de 6 bits Le nombre de bloc de 6 bits doit
ecirctre un multiple de 4 (minimum 4 blocs) Srsquoil manque des bits pour constituer un groupe de
6 bits on rajoute des zeacuteros
0x4869 = 0100 1000 0110 1001
| 42
3 Srsquoil manque des blocs pour faire un minimum de 4 blocs des caractegraveres speacuteciaux seront
ajouteacutes
4 Chaque groupe de 6 bits est traduit par le tableau suivant (Source Wikipeacutedia)
Figure 43 Codage en base 64
5 Si un bloc de 6 bits manque (ils doivent ecirctre un multiple de 4) on rajoute un ou plusieurs
compleacutements (caractegravere laquo = raquo )
Reacutesultat Le codage de 0x4869 en base 64 est laquo SGk= raquo
010010 000110 100100
On ajoute 00 pour avoir
6 bits dans le groupe
Bloc de 6 bits
010010 000110 100100
S G k
010010 000110 100100
S G k =
1er Bloc
2egraveme Bloc
3egraveme Bloc
4egraveme Bloc
| 43
542 Inteacuterecirct et inconveacutenient de la base 64 Lrsquoutilisation de la base 64 est un choix qui a eacuteteacute fait pour le protocole LoRa LoRaWAN afin de rendre
les donneacutees binaires lisibles Le problegraveme du code ASCII crsquoest qursquoil est composeacute drsquoun certain nombre
de caractegraveres non imprimables (EOF CR LFhellip) Pour eacuteviter ces soucis la base 64 ne comporte que
64 caractegraveres imprimables (voir tableau ci-dessus)
La restriction agrave 64 caractegraveres a cependant un inconveacutenient crsquoest que nous ne pouvons coder que 6
bits (26=64) au lieu de 8 La base 64 est donc moins efficace drsquoune faccedilon geacuteneacuterale
Nous cherchons agrave coder le code ASCII laquo AA raquo en base 64 Retrouver la deacutemarche en
montrant que le reacutesultat en base 64 est laquo QUE= raquo
543 Uplink Du Device LoRa au Network Server Le Network Server de TTN reccediloit des trames IP en provenance de la Gateway Comme nous lrsquoavons
vu preacuteceacutedemment un certain nombre drsquoinformations peuvent ecirctre retrouveacutees avec cette trame
(DevAddr SF Bandwidth etchellip) mais les donneacutees Applicatives sont bien sucircr chiffreacutees (avec
lrsquoAppkSKey) A ce niveau de reacuteception (sans connaitre lrsquoAppSKey) il nrsquoest donc pas possible de
comprendre la totaliteacute du message reccedilu
Imaginons que la trame IP reccedilue 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 45
timestamp 2019-03-05T140042448Z
rssi -82
snr 9
dev_addr 26011AD3
frequency 867300000
Le Network Server affiche donc les informations de la faccedilon suivante
Figure 44 Trame reacutecupeacutereacutee sur le laquo Network Server raquo de TTN
Nous retrouvons bien les valeurs fournies par la Gateway
timestamp ( agrave 1 heure pregraves en fonction du fuseau horaire)
| 44
frequency 8673 Mhz
modulation Lora
Coding Rate 45
data Rate SF 7 125 kHz (DR5)
air time 463 ms
Drsquoautres information proviennent de lrsquoanalyse du Payload Le Payload inscrit ici est le PHY Payload
Il y a donc une partie chiffreacutee (Frame Payload) mais les entecirctes sont en claires (voir paragraphe
441) Ce PHY Payload est laquo QNMaASYABwAP1obuUHQ= raquo Lorsque celui-ci est exprimeacute en
hexadeacutecimal au lieu de la base 64 il vaut laquo 40D31A01260007000FD686EE5074 raquo comme le montre
le Network Server de TTN
Figure 45 PHY Payload preacutesenteacute dans notre Network Server
Sa taille est bien de 14 octets (en hexadeacutecimal) comme preacuteciseacute sur la Figure 44
Nous reprenons le format de la trame LoRaWAN vu agrave la Figure 32 Nous pouvons alors retrouver
tous les champs de toute la trame
PHYPayload = 40D31A01260007000FD686EE5074
PHYPayload = MAC Header[1 octet] | MACPayload[] | MIC[4 octets]
MAC Header = 40 (Unconfirmed data up)
MACPayload = D31A01260007000FD6
Message Integrity Code = 86EE5074
MACPayload = Frame Header | Frame Port | FramePayload )
Frame Header = D31A0126000700
FPort = 0F
FramePayload = D6
Frame Header = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[015]
DevAddr = 26011AD3 (Big Endian)
FCtrl (Frame Control) = 00 (No ACK No ADR)
FCnt (Frame Counter) = 0007 (Big Endian)
FOpts (Frame Option) =
Vous pouvez veacuterifier lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN
(LoRaWAN packet decoder) httpsbitly2szdXtv
| 45
Figure 46 LoRaWAN packet decoder
544 Uplink Du Network Server agrave lrsquoApplication Server
Nous reprenons lrsquoexemple de la trame ci-dessus (Figure 45) Pour information les cleacutes NwkSKey et
AppSKey suivantes ont eacuteteacute utiliseacutee
NwkSKey E3D90AFBC36AD479552EFEA2CDA937B9
AppSKey F0BC25E9E554B9646F208E1A8E3C7B24
Le Network Server a deacutecodeacute lrsquoensemble de la trame Si le MIC est correct (authentification de la
trame par le NwkSKey) alors le Network Server va passer le contenu du message chiffreacute (Frame
Payload) agrave lrsquoApplication Server Dans notre cas le Frame Payload est (drsquoapregraves le deacutecodage effectueacute
au chapitre preacuteceacutedent)
FramePayload = D6
D6 est le contenu chiffreacute lorsqursquoil est deacutechiffreacute avec lrsquoAppSkey on trouve 01 Vous pouvez veacuterifier
lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN httpsbitly2szdXtv
A noter que lrsquoApplication Server recevra les donneacutees chiffreacutees seulement si le Device LoRa a bien
eacuteteacute enregistreacute On peut aussi veacuterifier ci-dessous que lrsquoApplication Serveur de TTN nous retourne bien
un payload (Frame Payload) de 01
Figure 47 Trame reacutecupeacutereacutee sur lrsquoApplication Server de TTN
time 2019-03-05T140042379279991Z
frequency 8673
modulation LORA
data_rate SF7BW125
coding_rate 45
gateways [
gtw_id eui-b827ebfffeae26f6
timestamp 2447508531
time
channel 4
rssi -82
snr 9
latitude 4563647
longitude 58721523
| 46
location_source registry
]
545 Simulation drsquoUplink dans lrsquoApplication Server
Dans beaucoup de situations nous souhaitons valider le fonctionnement de lrsquoApplication Server de
TTN ouet de notre propre Application Il est donc tregraves utile de pouvoir simuler lrsquoenvoi drsquoune trame
LoRa sur lrsquoApplication Server sans que celle-ci soit reacuteellement eacutemise par un Device LoRa Pour cela
un outil existe dans les Settings de chaque Device enregistreacute dans TTN Nous avons juste besoin de
speacutecifier le Frame Payload en clair en hexadeacutecimal et le numeacutero de Port
Figure 48 Simulation drsquoune trame envoyeacutee par un Device LoRa
546 Downlink De lrsquoApplication Server au Device LoRa La communication LoRa est bidirectionnelle Des donneacutees peuvent ecirctre transmis au Device LoRa
depuis lrsquoApplication Server Depuis TTN un outil existe dans les Settings de chaque Device
enregistreacute Lrsquointerface est repreacutesenteacutee ci-dessous
Figure 49 Transmission de donneacutees de lrsquo laquo Application Server raquo jusqursquoau Device LoRa
Replace scheduling Mode Par deacutefaut le Frame Payload transmis remplacera le Frame
Payload en attente (si il existe) Dans ce mode un seul Frame Payload est planifieacute
First scheduling Mode Le Frame Payload est mis en file drsquoattente en premiegravere position
Last scheduling Mode Le Payload est mis en file drsquoattente en derniegravere position
Une demande de confirmation peut ecirctre demandeacutee au Device LoRa pour qursquoil preacutecise srsquoil a bien reccedilu
les donneacutees Lrsquooption laquo confirmed raquo permet donc de speacutecifier le type de trame dans le MAC Header
(voir paragraphe 443) laquo Confirmed Data Down raquo ou laquo Unconfirmed Data Down raquo dans notre cas
| 47
6 La reacutecupeacuteration des donneacutees sur notre propre Application
Nous utiliserons agrave nouveau le Network Server et Application Server de The Things Network Jusqursquoici
nous nous sommes contenteacute de veacuterifier que les donneacutees de lrsquoutilisateur (Frame Payload) soient bien
arriveacutees agrave destination dans lrsquoApplication Server Il faut maintenant les reacutecupeacuterer avec notre propre
Application qui aura pour rocircle
De stocker et traiter les donneacutees
De les mettre agrave disposition de lrsquoutilisateur (Serveur Web par exemple)
Drsquoenvoyer des commandes de lrsquoutilisateur aux Devices LoRa si besoin (Flux Downlink)
Nous allons voir deux meacutethodes pour communiquer entre notre application et TTN
Le protocole HTTP POST
Le protocole MQTT
61 Reacutecupeacuteration des donneacutees en HTTP POST dans lrsquoApplication
611 Preacutesentation du protocole HTTP
Dans le monde de lrsquointernet le protocole HTTP est tregraves utiliseacute pour le dialogue entre un client et un
serveur web Classiquement le client (un navigateur web par exemple) fait une requecircte HTTP GET
et le serveur lui retourne le contenu de la page web demandeacutee
Dans notre cas la probleacutematique est diffeacuterente car le client doit modifier le contenu du serveur
avec les donneacutees envoyeacutees par le Device LORA La requecircte srsquoappelle HTTP POST Son nom indique
que le client va poster (et on pas reacutecupeacuterer) des donneacutees
Lrsquoutilisateur qui souhaite reacuteceptionner des donneacutees sur son serveur doit donc concevoir un serveur
HTTP capable de traiter des requecirctes HTTP POST [ requecircte noteacutee (1) sur la Figure 51 ] fournies par
TTN Dans cette configuration TTN jouera le rocircle de client et notre application le rocircle de serveur
Devices
LORA Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
HTTP POST
MQTT Internet
Figure 50 Structure globale drsquoun reacuteseau LORAWAN
| 48
Figure 51 Communication bidirectionnelle entre TTN et notre Application
A lrsquoinverse lrsquoutilisateur qui souhaite transmettre des donneacutees agrave destination du Device LoRa
(Downlink) doit ecirctre capable de fournir une requecircte HTTP POST [ requecircte noteacutee (2) sur la Figure 51
] vers TTN Dans cette configuration TTN jouera le rocircle de Serveur et notre application le rocircle de
client
612 Fonctionnement drsquoun client et drsquoun serveur HTTP POST Afin de bien comprendre le fonctionnement des requecirctes HTTP POST nous allons proceacuteder par
eacutetape Le premier test que nous effectuerons sera decorreacuteleacute de TTN Le principe est le suivant
Utilisation drsquoun serveur HTTP disponible sur le web geacuterant les requecirctes HTTP POST [
httpsrbasketsin ] ou [ httpsbeeceptorcom ] par exemple
Utilisation drsquoun client HTTP eacutemettant des requecirctes HTTP POST commande curl sous linux
ou logiciel Postman [ wwwgetpostmancom ] sous windows par exemple
Ce test nous permet de valider le fonctionnement drsquoun serveur HTTP POST et drsquoun client HTTP POST
Une fois que nous serons sucircr de leur fonctionnement nous les utiliserons avec TTN
The Things Network
Application
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 49
Figure 52 Validation dun server HTTP POST et drsquoun client HTTP POST
613 Test du serveur HTTP POST Nous utiliserons un serveur web proposeacute par httpsrbasketsin
Aller sur le site httpsrbasketsin et creacuteer un nouveau laquo Basket raquo Zone ougrave vous pourrez
visualiser les requecirctes qui ont eacuteteacute eacutemises vers votre serveur
A partir de maintenant toutes les requecirctes dirigeacutees vers lrsquoadresse creacuteeacute seront traiteacutees et
srsquoafficheront Dans le menu de configuration il est aussi possible de deacutefinir le contenu de la reacuteponse
qui sera fournie
Deacutefinir un format de reacuteponse pour les requecirctes HTTP POST avec un body personnaliseacute
614 Test du client HTTP POST On peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande (la commande cURL
srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN sous Windows
Commande cURL curl ndashX POST ndashd lsquorsquodonneacutees agrave envoyerrsquorsquo DuServeurHTTP
Logiciel Postman New gt Request gt Creacuteer une requecircte HTTP POST gt Send
Veacuterifier que les requecirctes HTTP POST sont bien reacutecupeacutereacutees sur votre serveur creacutee preacuteceacutedemment
615 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST
Maintenant que nous avons un serveur HTTP (POST) fonctionnel nous allons configurer TTN pour
jouer le rocircle du client et pour qursquoil envoie des requecirctes HTTP POST vers notre Serveur degraves qursquoune
donneacutee drsquoun Device LoRa est disponible Nous geacuterons donc ici le flux Uplink
Requecircte
HTTP POST
Reacuteponse
(contenu parameacutetrable)
Client HTTP (POST)
Server HTTP (POST) [ httpsrbasketsin ]
| 50
Figure 53 Reacutecupeacuteration des donneacutees sur notre Application
Dans TTN nous inteacutegrons un bloc appeleacute laquo HTTP Integration raquo permettant de jouer le rocircle de client
crsquoest-agrave-dire drsquoenvoyer des requecirctes HTTP POST agrave destination de notre nouveau Serveur HTTP
Lrsquointeacutegration se faire agrave partir de TTN gt Console gt Application gt Nom_de_votre_application gt
Integration
Figure 54 Ajout dun client HTTP POST dans TTN
Pour valider le fonctionnement de notre architecture nous pouvons soit
Envoyer une trame depuis un Device LoRa vers TTN
Simuler lrsquoenvoi drsquoune trame drsquoun Device LoRa vers TTN (gracircce agrave lrsquooutil proposeacute par TTN vu
paragraphe 545)
Dans les deux cas voici un exemple de requecircte POST reccedilue sur notre serveur HTTP
app_id test_app_lorawan_sylvainmontagny
dev_id stm32lorawan_1
hardware_serial 0056AF49877
port 1
counter 0
payload_raw qg==
metadata
Requecircte
HTTP POST
Server HTTP (POST) [ httpsrbasketsin ]
The Things Network (Client)
La requecircte contient le Frame Payload deacutechiffreacutee
agrave transmettre agrave lrsquoApplication
| 51
time 2019-01-24T15243703499298Z
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Comme nous pouvons le voir le contenu fourni agrave notre serveur est formateacute en JSON (voir
paragraphe 0) Voici quelques compleacutements drsquoinformation
payload_raw Frame Payload deacutechiffreacute crsquoest donc les donneacutees en clairs dans la base 64
downlink_url URL du serveur HTTP POST qui serviront agrave transmettre des donneacutees au Device
LoRa (flux Downlink)
611 Envoyer des donneacutees depuis notre Application avec HTTP POST
Lorsque nous avons ajouteacute le bloc laquo HTTP Integration raquo au paragraphe preacuteceacutedent nous avons aussi
implicitement activeacute la fonctionnaliteacute que TTN soit precirct agrave recevoir et agrave traiter les requecirctes HTTP
POST La seule information qursquoil nous manque est lrsquoadresse du server HTTP vers lequel il faut eacutemettre
les requecirctes Si on observe la trame reccedilue preacuteceacutedemment en provenance de TTN on srsquoaperccediloit que
dans la trame JSON reccedilu une URL (downlink_url) est speacutecifieacutee
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Crsquoest cette URL que nous devrons utiliser Nous allons nous placer dans la configuration suivante
Figure 55 Envoi de donneacutees agrave partir de notre Application
Comme preacuteceacutedemment on peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande
(la commande cURL srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN
Commande cURL curl ndashX POST ndashdata lsquo dev_id Identidiant_De_Votre_Device
payload_raw AQE= rsquo DuServeurHTTP
Logiciel Postman New gt Request gt HTTP POST puis Body gt Raw gt JSON
Requecircte HTTP POST vers serveur TTN laquo downlink_url raquo httpsintegrationsthethingsnetworUaeb8ypKieQ
Contenu de la requecircte
dev_id Identidiant_De_Votre_Device
payload_raw aGVsbG8=
The Things Network (Serveur)
POSTMAN (Client HTTP POST)
| 52
dev_id YourDeviceID
payload_raw aGVsbG8=
Vous devez envoyer le texte (payload_raw) en base 64 Dans lrsquoexemple ci-dessus laquo aGVsbG8= raquo
correspond agrave la chaine de caractegravere laquo hello raquo Vous pouvez utiliser les nombreux encodeurdecodeur
en ligne pour vous aider Le texte doit srsquoafficher sur votre moniteur seacuterie Arduino dans le cadre de
notre deacutemonstrateur sur Arduino
62 Reacutecupeacuteration des donneacutees avec MQTT dans lrsquoApplication
621 Preacutesentation du protocole MQTT
MQTT est un protocole leacuteger qui permet de srsquoabonner agrave des flux de donneacutees Plutocirct que
lrsquoarchitecture Client Serveur classique qui fonctionne avec des Requecirctes Reacuteponses MQTT est
baseacute sur un modegravele Publisher Subscriber La diffeacuterence est importante car cela eacutevite davoir agrave
demander (Requecircte) des donneacutees dont on na aucune ideacutee du moment ougrave elles vont arriver Une
donneacutee sera donc directement transmise au Subscriber degraves lors que celle-ci a eacuteteacute reccedilue dans le
Broker (serveur central)
Figure 56 Modegravele Publisher Subscriber du protocole MQTT
Pour recevoir les donneacutees appartenant agrave un Topic un Subscriber doit souscrire (comme son nom
lindique) au preacutealable sur ce Topic
MQTT est un protocole qui repose sur TCP Lencapsulation des trames sur le reacuteseau est donc la
suivante
Broker
Client
Publisher 1
Client
Publisher 2
Client
Subscriber
Topic
Tempeacuterature
Topic
Humiditeacute
| 53
Figure 57 Protocoles utiliseacutes pour la communication avec MQTT
On peut le veacuterifier par une capture de trame sur Wireshark
Figure 58 Capture dune trame MQTT avec Wireshark
On peut noter que le port TCP utiliseacute pour le protocole MQTT (non chiffreacute) est le 1883
Les Publishers et les Subscribers nrsquoont pas besoin de se connaitre
Les Publishers et les Subscribers ne sont pas obligeacute de srsquoexeacutecuter en mecircme temps
622 Connexion au Broker MQTT Nous nous inteacuteresserons essentiellement aux options de connexion qui permettront de geacuterer la
Qualiteacute de Service (QoS) Pour se connecter un client MQTT envoie deux informations importantes
au Broker
keepAlive Cest la peacuteriode la plus longue pendant laquelle le client Publisher ou Subscriber pourra
rester silencieux Au-delagrave il sera consideacutereacute comme deacuteconnecteacute
cleanSession Lorsque le Client et le Broker sont momentaneacutement deacuteconnecteacutes (au-delagrave du
keepAlive annonceacute) on peut donc se poser la question de savoir ce quil se passera lorsque le client
sera agrave nouveau connecteacute
Si la connexion eacutetait non persistante (cleanSession = True) alors les messages non transmis
sont perdus Quel que soit le niveau de QoS (Quality of Service)
Si la connexion eacutetait persistante (cleanSession = False) alors les messages non transmis
seront eacuteventuellement reacuteeacutemis en fonction du niveau de QoS Voir le chapitre 624
623 Qualiteacute de Service au cours dune mecircme connexion
A partir du moment ougrave le Client se connecte au Broker il est possible de choisir un niveau de fiabiliteacute
des transactions Le Publisher fiabilise leacutemission de ces messages vers le Broker et le Subscriber
fiabilise la reacuteception des messages en provenance du Broker Une parle ici du cas dune mecircme
connexion crsquoest-agrave-dire entre le moment ou le Client se connecte et le moment ougrave
Soit il se deacuteconnecte explicitement (Close connexion)
Soit il na rien eacutemis ni fait signe de vie pendant le temps keepAlive
TCP
MQTT
Reacuteseau
Transport
Couche Application
IP
| 54
Lors dune mecircme connexion la Qualiteacute de Service (QoS) qui est mise en œuvre deacutepend uniquement
de la valeur du QoS selon les valeurs suivantes
QoS 0 At most once (au plus une fois) Le premier niveau de qualiteacute est sans acquittement Le
Publisher envoie un message une seule fois au Broker et le Broker ne transmet ce message quune
seule fois aux Subscribers Ce meacutecanise ne garantit pas la bonne reacuteception des messages MQTT
QoS 1 At least once (au moins une fois) Le deuxiegraveme niveau de qualiteacute est avec acquittement
Le Publisher envoie un message au Broker et attends sa confirmation De la mecircme faccedilon le Broker
envoie un message agrave ces Subscriber et attends leurs confirmations Ce meacutecanisme garantit la
reacuteception des message MQTT
Cependant si les acquittements nrsquoarrivent pas en temps voulu ou srsquoils se perdent la reacuteeacutemission du
message dorigine peut engendrer une duplication du message Il peut donc ecirctre reccedilu plusieurs fois
QoS 2 Exactly once (exactement une fois) Le troisiegraveme niveau de qualiteacute est garanti une seule
fois Le Publisher envoie un message au Broker et attends sa confirmation Le Publisher donne alors
lrsquoordre de diffuser le message et attends une confirmation Ce meacutecanisme garantit que quel que
soit le nombre de tentatives de reacuteemission le message ne sera deacutelivreacute quune seule fois
La Figure 59 montre les trames eacutemises pour chaque niveau de QoS
Figure 59 Qualiteacute de Service en MQTT
La Figure 60 repreacutesentes les 3 captures de trames sur Wireshark repreacutesentant les 3 QoS (1 2 et 3)
que nous venons dexpliquer
Broker
QoS 0
Au plus une fois
Message supprimeacute apregraves envoi
PUBLISH
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Duplications possibles
PUBLISH
PUBLICH Ack
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Pas de duplication
PUBLISH
PUBLISH Receive
PUBLISH Release
PUBLISH Complete
| 55
Figure 60 Capture de trame avec QoS = 0 puis QoS = 1 puis QoS = 2
624 Qualiteacute de Service apregraves une reconnexion
La question que nous nous posons et de savoir ce que deviennent les messages publieacutes sur le Broker
lorsquun ou plusieurs Subscribers sont momentaneacutement injoignables Il est possible de conserver
les messages qui ont eacuteteacute publieacutes sur le Broker afin de les retransmettre lors de la prochaine
connexion Cette possibiliteacute de sauvegarde doit ecirctre activeacutee agrave louverture de connexion gracircce au flag
cleanSession = 0 La connexion sera alors persistante crsquoest-agrave-dire que le Broker enregistre tous les
messages quil na pas reacuteussi agrave diffuser au Subscriber
Le Tableau 9 reacutesume leffet du flag cleanSession et du QoS
Clean Session Flag Subscriber QoS Publisher QoS Comportement True ( = 1) 0 1 2 0 1 2 Messages perdus
False ( = 0 ) 0 0 1 2 Messages perdus
False (= 0 ) 0 1 2 0 Messages perdus
False (= 0 ) 1 2 1 2 Tous les messages sont retransmis
Tableau 9 Qualiteacute de Service en fonction de la valeur du QoS et du flag cleanSession
625 Les Topics du protocole MQTT Les chaicircnes deacutecrivant un sujet forment une arborescence en utilisant la barre oblique comme
caractegravere de seacuteparation La Figure 61 et le Tableau 10 donne un exemple dorganisation de Topic
Figure 61 Exemple de hieacuterarchie de Topic MQTT
Niveau 3
Niveau 2
Niveau 1 Maison
Chambre
Temperature Humidite Bruit
Salon
Temperature
| 56
Nom du Topic Deacutetail du Topic MaisonChambreTemperature La tempeacuterature de la chambre de la maison
MaisonChambreBruit Le bruit de la chambre de la maison
MaisonSalonTemperature La tempeacuterature du Salon de la maison
Tableau 10 Exemple de Topic
Un client peut sabonner (ou se deacutesabonner) agrave plusieurs branches de larborescence agrave laide de
jokers englobant plusieurs Topics Deux caractegraveres jokers existent
Le signe plus + remplace nimporte quelle chaine de caractegravere sur le niveau ougrave il est placeacute
Le diegravese remplace nimporte quelle chaine de caractegravere sur tous les niveaux suivants Il
est obligatoirement placeacute agrave la fin
Nom du Topic Deacutetail du Topic Maison+Temperature Les tempeacuteratures de toutes les piegraveces de la maison
MaisonChambre La tempeacuterature lhumiditeacute et le bruit de la chambre de la maison
Tableau 11 Exemple de Topic
626 Mise en place drsquoun Broker MQTT Afin de bien comprendre le fonctionnement du protocole de MQTT on reacutealise des tests
indeacutependamment de TTN Nous allons mettre en place
Un Broker Mosquitto httpstestmosquittoorg
Un client Publisher MQTT Box sur Windows
Un client Subscriber MQTT Box sur Windows
Figure 62 Test du protocole MQTT
MQTT Client (Subscriber)
MQTT Client (Publisher)
Publish
Subscribe
BROKER (Mosquitto)
| 57
Le Broker MQTT est commun agrave tout le monde Nous pouvons soit le reacutealiser nous-mecircme soit utiliser
un Broker MQTT public de test Nous utiliserons le Broker de test de Mosquitto disponible sur
httpstestmosquittoorg Drsquoautres sont eacuteventuellement disponibles en cas de problegraveme par
exemple httpwwwmqtt-dashboardcom
Si nous deacutecidions de le reacutealiser nous-mecircme agrave lrsquoaide drsquoune Raspberry Pi (par exemple) Lrsquoinstallation
se ferait en deux lignes de commande
apt-get install mosquito Installation
sudo systemctl start mosquittoservice Lancement du service
Il est neacutecessaire drsquoinstaller mosquitto-clients si on souhaite que le Raspberry PI joue aussi le rocircle de
client ce qui nrsquoest pas notre cas
627 Mise en place drsquoun Publisher et drsquoun Subscriber MQTT Lancer le logiciel MQTTBox
MQTTBox gt Create MQTT Client
Dans ce client les seuls champs indispensables sont
Protocol MQTT TCP
Host testmosquittoorg
Figure 63 Configuration dun Client MQTT dans MQTT Box
Tester lrsquoenvoi et la reacuteception sur les Topics de votre choix
628 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT La reacutecupeacuteration des donneacutees fait reacutefeacuterence au flux Uplink Dans ce cas
TTN joue le rocircle de client Publisher
TTN joue aussi le rocircle de Broker
Notre application joue le rocircle de Subscriber
Nous pouvons donc repreacutesenter lrsquoapplication globale par le scheacutema suivant
| 58
Figure 64 Publisher et Subscriber dans en MQTT avec TTN
La publication est repreacutesenteacutee par la trame MQTT (1)
La souscription est repreacutesenteacutee par la trame MQTT (2)
Le client Publisher eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box mais cette fois avec la configuration suivante
Protocol mqtt tcp
Host Crsquoest lrsquoIP du Broker vers lequel il faut se connecter Dans notre cas il srsquoagit de celui
de TTN dont lrsquoadresse est euthethingsnetwork
Username La connexion vers le broker MQTT est soumis agrave une authentification Username
Password Dans notre cas le Username correspond au nom de notre application crsquoest-agrave-
dire seminaire_lorawan Si vous avez choisi une autre applicationil faut bien mettre la
votre
Password Le Password est nommeacute laquo Access Key raquo par TTN Elle vous sera donneacutee par
lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application vous
trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt Overview
Figure 65 Access Keys de lapplication dans TTN
The Things Network (Application Server)
BROKER
Application
The Things Network (Network Server)
Publish (1 )
[ Flux Uplink ]
Subscribe (2 )
[ Flux Uplink ]
| 59
Figure 66 Configuration du Client dans MQTT Box
Le client MQTT eacutetant configureacute il est maintenant capable de se connecter au Broker Il reste donc agrave
deacutefinir le fait que le client sera Subscriber Les informations que recevra le Subscriber deacutependent du
Topic auquel nous souscrivons Voici les Topic disponibles sur le Broker de TTN
ltAppIDgt correspond au nom de votre Application
ltDevIDgt correspond au nom de votre Device LoRa
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink ltAppIDgtdevicesltDevIDgtup
[Donneacutees] Flux Downlink ltAppIDgtdevicesltDevIDgtdown
[Activation Events] Activation dun Device ltAppIDgtdevicesltDevIDgteventsactivations
[Management Events] Creacuteation dun Device ltAppIDgtdevicesltDevIDgteventscreate
[Management Events] Update dun Device ltAppIDgtdevicesltDevIDgteventsupdate
[Management Events] Suppression dun Device ltAppIDgtdevicesltDevIDgteventsdelete
[Downlink Events ] Message programmeacute ltAppIDgtdevicesltDevIDgteventsdownscheduled
[Downlink Events ] Message envoyeacute ltAppIDgtdevicesltDevIDgteventsdownsent
[Erreurs] Uplink erreurs ltAppIDgtdevicesltDevIDgteventsuperrors
[Erreurs] Downlink erreurs ltAppIDgtdevicesltDevIDgteventsdownerrors
[Erreurs] Activations erreurs ltAppIDgtdevicesltDevIDgteventsactivationserrors
Tableau 12 Topics enregistreacutes dans TTN
Dans un premier temps nous souscrivons au Topic +devices+up Cela signifie que nous
souscrivons agrave tous les Devices LoRa de toutes nos applications pour le flux Uplink
Figure 67 Configuration du Subscriber
Les eacuteleacutements eacutemis par le Broker seront alors afficheacutes dans MQTTBox La
| 60
Figure 68 Trame LoRaWAN reccedilu sur le Subscriber MQTT
Ces donneacutees sont eacutecrites en JSON nous pouvons les remettre en forme
applicationID3
applicationNamemyApplication
deviceNamearduino0
devEUI0056xxxxxxxxx877
txInfo
frequency868500000
dr5
adrfalse
fCnt792
fPort15
dataSGVsbG8=
Le Frame Payload deacutechiffreacute est fourni dans le champ data en base 64 La valeur fournie par
dataSGVsbG8= correspond bien agrave la chaine de caractegravere hello que nous avons eacutemise avec le
Device LoRa
629 Envoyer des donneacutees depuis notre Application avec MQTT
Lrsquoenvoi des donneacutees fait reacutefeacuterence au flux Downlink Dans ce cas
Notre application joue le rocircle de Publisher
TTN joue le rocircle de Broker
TTN joue aussi le rocircle de client Subscriber
| 61
La publication est repreacutesenteacutee par la trame MQTT (3)
La souscription est repreacutesenteacutee par la trame MQTT (4)
Le client Subscriber eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box Le rocircle de client dans MQTT Box a eacuteteacute faite au
paragraphe 628 Il nous reste simplement agrave ajouter le rocircle de Publisher La configuration est la
suivante
Topic du Subscriber seminaire_lorawandevicesarduino0down ougrave seminaire_lorawan
est agrave remplacer par le nom de votre application et arduino0 par le nom du Device LoRa vers
lequel vous souhaitez envoyeacute une donneacutee (Voir chapitre 628 pour comprendre les Topics)
Le Payload doit ecirctre au format JSON Lrsquoexemple suivant envoie laquohello raquo
payload_raw aGVsbG8=
The Things Network (Application Server)
BROKER
Application
Publish (3)
[ Flux Downlink ]
The Things Network (Network Server)
Subscribe (4)
[ Flux Downlink ]
| 62
Figure 69 Configuration du Publisher
Vous devriez voir les donneacutees arriver sur votre Device LoRA
| 63
7 Creacuteation de notre propre Network et Application Server
711 Objectifs Lors de la mise en œuvre du reacuteseau LoRaWAN au chapitre 52 nous avons utiliseacute TTN (The Things
Network) pour jouer le rocircle de Network Server et drsquoApplication Server Pour de multiples raisons
Seacutecuriteacute autonomie coucircthellipil peut ecirctre inteacuteressant de monter soi-mecircme un Network Server et un
Application Server Cela est possible seulement si vous posseacutedez vos propres Gateway puisque
celles-ci devront forwarder leur paquet agrave destination preacutecise Il faudra donc les reconfigurer pour
qursquoelles pointent vers votre nouvelle architecture
712 Preacutesentation de LoRaServer LoRaServer [ wwwloraserverio ] est un projet Open-Source reacutepondant exactement au besoin que
nous avons Nous lrsquoutiliserons sur une cible Raspberry PI En reacutealiteacute il peut souvent ecirctre mise en
place dans le mecircme systegraveme que la Gateway surtout si celle-ci est elle-mecircme agrave base de RPI Les
Gateway EBDS que nous posseacutedons possegravedent drsquoailleurs un Network Server et un Application Server
que nous aurions pu utiliser Neacuteanmoins pour des raisons peacutedagogiques il est inteacuteressant de
seacuteparer les systegravemes pour bien diffeacuterencier les probleacutematiques
Attention il y a une ambiguiumlteacute dans la deacutenomination des entiteacutes logiciels de LoRaServer
LoRaServer (sans espace entre le mot LoRa et Server) est le nom du projet global En
revanche LoRa Server (avec un espace) est le nom du service qui joue le rocircle du Network
Server
Lrsquoarchitecture et le fonctionnement de LoRaServer est preacutesenteacutee dans sa documentation par le
scheacutema suivant
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Raspberry PI
Figure 70 Architecture globale de notre reacuteseau loRaWAN
| 64
Figure 71 Architecture deacutetailleacutee de LoRaServer
On srsquoattends agrave voir uniquement un Network Server (LoRa Server) et un Application Server (LoRa App
Server) mais ce scheacutema est plus complexe Il demande un certain nombre drsquoexplications pour bien
comprendre ce que nous allons installer et la faccedilon dont nous lrsquoutiliserons par la suite
713 Le laquo Packet Forwarder raquo (Gateway) Comme nous lrsquoavons vu au chapitre 412 les Gateways LoRa sont des passerelles entre la
modulation LoRa et un reacuteseau IP Pour reacutealiser cette passerelle un service nommeacute laquo UDP Packet
Forwarder raquo a eacuteteacute deacuteveloppeacute par Semtech httpsgithubcomLora-netpacket_forwarder Dans
ce dossier github un fichier nommeacute PROTOCOLTXT explique parfaitement ce protocole applicatif
qui travaille au-dessus de UDP
Figure 72 Protocole Uplink (PUSH_DATA du Packet Forwarder)
| 65
On remarque que les paquets sont envoyeacutes en UDP au Network Server dans une trame appeleacutee
PUSH_DATA Cette trame est acquitteacutee par le Network Server par une trame appeleacutee PUSH_ACK
Sur notre Network Server nous pouvons reacutealiser une capture de trame pour veacuterifier si le protocole
est bien celui preacutesenteacute dans le document
Figure 73 Trame captureacutee par Wireshark lors dun Uplink
Drsquoapregraves la capture preacuteceacutedente on remarque que le Packet Forwarder fonctionne bien avec UDP sur
le port 1700
Le contenu des donneacutees (champ Data) est deacutetailleacute dans le tableau suivant
Champ | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | random token
[3] | 3 | PUSH_DATA identifier = 0x00
[4] | 4-11 | Gateway unique identifier (MAC address)
[5] | 12-end | JSON object starting with ending with
Lrsquoobjet JSON de la transmission reacuteeacutecrit plus proprement est celui-ci
Figure 74 Analyse du champ Donneacutees du protocole laquo Packet Forwarder raquo
0000 02 f9 30 00 b8 27 eb ff fe ae 26 f5 7b 22 72 78 0amprx 0010 70 6b 22 3a 5b 7b 22 74 6d 73 74 22 3a 33 37 35 pk[tmst375 0020 35 30 30 35 38 31 39 2c 22 63 68 61 6e 22 3a 32 5005819chan2 0030 2c 22 72 66 63 68 22 3a 31 2c 22 66 72 65 71 22 rfch1freq 0040 3a 38 36 38 2e 35 30 30 30 30 30 2c 22 73 74 61 868500000sta 0050 74 22 3a 31 2c 22 6d 6f 64 75 22 3a 22 4c 4f 52 t1moduLOR 0060 41 22 2c 22 64 61 74 72 22 3a 22 53 46 37 42 57 AdatrSF7BW 0070 31 32 35 22 2c 22 63 6f 64 72 22 3a 22 34 2f 35 125codr45 0080 22 2c 22 6c 73 6e 72 22 3a 36 2e 35 2c 22 72 73 lsnr65rs 0090 73 69 22 3a 2d 31 2c 22 73 69 7a 65 22 3a 31 38 si-1size18 00a0 2c 22 64 61 74 61 22 3a 22 51 4e 4d 61 41 53 59 dataQNMaASY 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 ]
Ch
amp
[1
]
Ch
amp
[2
]
Ch
amp
[3
]
Ch
amp
[4
]
| 66
rxpk[ tmst3755005819
chan2
rfch1
freq868500000
stat1
moduLORA
datrSF7BW125
codr45
lsnr65
rssi-1
size18
dataQNMaASYAAQAPpyPZ955+SmY
]
Le champ data correspond au PHY Payload
De la mecircme faccedilon on retrouve la Trame drsquoacquittement
Figure 75 Trame captureacutee par Wireshark lors de lrsquoacquittement drsquoun Uplink
Champs | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | same token as the PUSH_DATA to acknowledge
[3] | 3 | PUSH_ACK identifier = 0x01
Nous retrouvons bien tous ces champs dans la trame Wireshark
714 LoRa Gateway Bridge Nous avons deacutecrit au chapitre preacuteceacutedent (713) le fonctionnement du Packet Forwarder Le
Network Server(Lora Server) que nous allons mettre en place aurait tregraves bien pu srsquointerfacer
directement agrave ce protocole Mais cela aurait plusieurs impacts dont un qui est important dans la
conception de logiciel Si le Packet Forwarder change ou si un autre type de Forwarder est utiliseacute
alors lrsquoutilisation du LoRa Server devient impossible Il a donc eacuteteacute choisi de creacuteer une eacutetape
intermeacutediaire Le Network Server que nous mettrons en plus utilisera le protocole MQTT plutocirct que
le protocole UDP packet Forwarder
En drsquoautres termes le LoRa Gateway Bridge est un service qui fera abstraction du Packet Forwarder
pour srsquointerfacer plus simplement avec le Network Server
715 LoRa Server (Network Server) Il srsquoagit de notre Network Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
413 Cependant il srsquointerfacera au protocole MQTT en recevant les informations agrave partir du
Broker au lieu de recevoir directement les trames en provenance de la Gateway
| 67
716 LoRa App Server (Application Server) Il srsquogit de notre Application Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
414
717 LoRa Geo Server Il srsquoagit drsquoun service qui permet drsquoutiliser certaines proprieacuteteacutes du protocole LoRa pour proposer un
service de geacuteolocalisation des Devices LoRa Nous ne lrsquoutiliserons pas dans notre cas
718 Application Il srsquoagit de notre Application qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre 415
Elle ne fait pas partie du projet LoRaServer crsquoest donc bien toujours agrave nous de proposer notre propre
Application
Figure 76 Les interfaces possibles entre LoRaServer et lrsquoApplication utilisateur
Comme nous pouvons le voir sur la figure preacuteceacutedente deux possibiliteacutes sont offertes pour interfacer
notre application JSON REST (incluant HTTP POST) et via un Broker MQTT Ces deux meacutethodes ont
deacutejagrave eacuteteacute traiteacutee au chapitre 61 (HTTP POST ) et au chapitre 62 (MQTT) Nous verrons aussi drsquoautres
possibiliteacutes pour personnaliser notre application au chapitre 7
72 Installation de LoRaServer
721 Mise en place de lrsquoenvironnement
Nous allons installer une carte SD avec la derniegravere version de Raspbian Nous ne deacutetaillerons pas la
deacutemarche pour cela car elles sont largement documenteacutees et mises agrave jour sur le site
wwwraspberrypiorg
Installer un carte SD avec la derniegravere version de Raspbian
Plutocirct que de fonctionner avec un clavier et une souris nous preacuteconisons de travailler agrave distance
avec la RPI via une connexion SSH Depuis quelques anneacutees Raspbian a supprimeacute le deacutemarrage du
service SSH au boot Heureusement il est possible de le reacuteactiver par la meacutethode suivante
Avec Windows ou Linux ouvrir la partition BOOT de votre carte SD et placer un fichier agrave la
racine nommeacute sshtxt (ou ssh)
Mettre la carte SD dans votre RPI et la deacutemarrer
| 68
Pour acceacuteder agrave la RPI en SSH depuis Windows nous utiliserons de preacutefeacuterence le logiciel
client MobaXterm mais tout autre client SSH est valable
Installer MobaXterm sur votre PC et connectez-vous agrave votre Raspberry PI
Lrsquoutilisation drsquoun espion de reacuteseau type Wireshark peut ecirctre inteacuteressant pour eacutetudier les trames qui
sont reccedilues et qui sont eacutemises Cela nous permettra de valider le fonctionnement des diffeacuterents
protocoles reacuteseau qui permettent de communiquer agrave la Gateway drsquoune part et agrave lrsquoApplication
drsquoautre part Nous utiliserons tshark
apt-get install tshark installation
tshark ndashn -i eth0 Exemple drsquoune analyse sur lrsquointerface wlan0
722 Installation sur la Raspberry PI La meacutethode drsquoinstallation de LoRaServer est documenteacutee sur le site web agrave lrsquoadresse suivante
[ httpswwwloraserverioguidesdebian-ubuntu ] Nous installerons le LoRa Gateway Bridge
le LoRa Server et le LoRa App Server
Apregraves lrsquoinstallation la configuration se fait par une interface graphique accessible par le reacuteseau sur
le port 8080
Si vous travaillez sur la RPI connectez-vous sur httplocalhost8080
Si vous travaillez agrave distance (SSH) connectez-vous sur httpIP_RPI8080
Les Usernames et Password par deacutefaut sont
Username admin
Password admin
Lrsquoeacutecran drsquoaccueil sera donc le suivant
Figure 77 Architecture globale apregraves installation de LoRaServer
Devices
Gateways LoRa
UDP Packet Forwarder
Application Server
LoRa App Server
Internet
Network Server
LoRa Server
LoRa Gateway Bridge
| 69
Figure 78 Ecran daccueil de LoRaServer apregraves authentification
71 Configuration de LoRa Server pour lUplink
711 Enregistrement drsquoune nouvelle Organisation
Pour enregistrer une nouvelle Organizations Organizations gt Create Puis entrer les configurations
suivantes
Figure 79 Enregistrement dun nouvelle Organisation
712 Enregistrement drsquoune instance du Network Server Pour enregistrer une nouvelle instance du Network Server Network Server gt Create Puis entrer
les configurations suivantes
| 70
Figure 80 Enregistrement dun nouveau Network Server
Dans lrsquoonglet Gateway Discovery il est possible drsquoactiver une option de deacutecouverte de Gateway aux
alentours Lorsqursquoelle est configureacutee le Network Server va envoyer une trame Downlink de
configuration de la Gateway lui ordonnant de reacutealiser des PING en LoRa La configuration du
Gateway Discovery preacutevoit de speacutecifier
Le nombre de fois par jour que les PING LoRa sont envoyeacutes
Le canal drsquoeacutemission
Le Data Rate (Voir paragraphe 445)
Un PING LoRa reccedilu sur une Gateway sera retransmis sur le Network Server (Lora Server) et une carte
sera afficheacutee
Lrsquoonglet TLS Certificates ne sera pas utiliseacute dans le cadre de notre deacutemonstration
713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) Il faut tout drsquoabord faire un enregistrement drsquoun laquo service-profile raquo Un laquo service profile permet de
faire la connexion entre le Network Server et les Applications que nous enregistrerons dans notre
Organisation Service-profiles gt Create
Service-profile name myServiceProfile
Network-server myNetworkServer
On laissera par deacutefaut toutes les autres options
Pour enregistrer une nouvelle Application Applications gt Create Puis entrer les configurations
suivantes
| 71
Figure 81 Enregistrement dune nouvelle Application
714 Enregistrement des Devices LoRa Il faut tout drsquoabord faire lrsquoenregistrement drsquoun Device-profile pour les Devices LoRa que vous
souhaitez connecter Dans notre cas nous ferons un premier test en speacutecifiant que nous utilisons
seulement le mode drsquoauthentification ABP (voir chapitre 431) Devices profile gt Create
Figure 82 Enregistrement dun laquo Device profile raquo
Nous pouvons alors creacuteer dans notre Application des nouveaux Devices Application gt
myApplication gt Create
| 72
Figure 83 Enregistrement dun nouveau Device LoRa
Dans la fenecirctre Activation on va alors configurer les 3 eacuteleacutements indispensables agrave une
authentification en APB Le DevAddr le NwkSKey et lrsquoAppSKey
Figure 84 Configuration de lenregistrement du Device LoRa (en ABP)
La configuration minimale de LoRaServer est maintenant termineacutee Nous pouvons donc brancher
un Device LoRa qui possegravede les les attribus (DevAddr NwkSKey et AppSKey) que nous avons
enregistreacute dans LoRaServer et le faire eacutemettre
715 Visualisation des trames reccedilues Les trames eacutemises par le Device LoRa vont donc parcourir le cheminement suivant
| 73
Figure 85 Reacutesumeacute du cheminement des trames LoRaWan en Uplink avec LoRaServer
En allant dans le Live Device Data (Application gt Nom_du_Device gt Live Device Data) on peut voir la
liste des trames reccedilues ainsi que les donneacutees applicatives deacutechiffreacutees
Figure 86 Reacuteception des trames des Devices LoRa
Figure 87 Analyse des trames des Devices LoRa
Dans lrsquoonglet LIVE LORAWAN FRAME nous pouvons voir les trames LORAWAN et si besoin eacutetudier
le contenu de ce qursquoelles contiennent En revanche les donneacutees applicatives sont ici chiffreacutees
UDP
Packet Forwarder
LoRa Bridge
Gateway LoRa Server LoRa App Server
Gateway
Server
Internet
| 74
Figure 88 Reacuteception des Trames LoRaWAN
72 Configuration de LoRaServer pour linteacutegration dApplication Nous avons vu dans le chapitre 718 que linterface entre LoRaServer et notre Application pouvait
ecirctre reacutealiseacutee soit par MQTT soit par les meacutethodes REST (HTTP POST) Nous avons deacutejagrave impleacutementeacute
et expliqueacute ces protocoles dans le cadre de son utilisation avec TTN Nous allons donc juste
configurer LoRaServer pour tester ces deux meacutethodes
721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST Nous utiliserons exactement la mecircme meacutethode que celle que nous avons utiliseacute avec TTN au
chapitre 615 Les diffeacuterentes Clients et Serveurs disponibles pour ces tests sont expliqueacutes au
paragraphe 612
Dans LoRaServer ajouter une inteacutegration HTTP LoRaServer gt Applications gt myApplication gt
Integrations gt Create gt HTTP Integration et la configurer comme le montre la Figure 89 Vous
remplacerez eacutevidement le lien par votre propre Endpoints
Figure 89 Configuration de linteacutegration HTTP POST dans LoRaServer
En envoyant des trames LoRa depuis votre Device vous devriez voir les contenus JSON sur votre
Endpoint
722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT Nous allons nous connecter au Broker MQTT de LoRaServer Pour cela nous utiliserons la mecircme
meacutethode que celle que nous avons utiliseacute avec TTN au chapitre 628 Nous utiliserons MQTTBox
comme nous lavons deacutejagrave fait au paragraphe 627
Le Broker de LoRaServer a enregistreacute les Topics suivant
[applicationID] correspond au nom de votre Application
[devEUI] correspond au nom de votre Device LoRa
| 75
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink application[applicationID]device[devEUI]rx
[Donneacutees] Flux Downlink application[applicationID]device[devEUI]tx
[Status] Statut dun Device application[applicationID]device[devEUI]status
[Ack] Acquittement des messages application[applicationID]device[devEUI]ack
[Erreurs] Erreurs application[applicationID]device[devEUI]error
Tableau 13 Topics enregistreacutes dans LoRaServer
| 76
8 Creacuteation de notre propre Application
81 Utilisation de Node-RED
811 Preacutesentation Node-RED est un outil de programmation graphique qui permet de faire communiquer les
peacuteripheacuteriques mateacuteriels drsquoun systegraveme sans eacutecrire de code De nombreux protocoles sont aussi pris
en charge au travers de bloc ( Node) qursquoil suffit de connecter entre eux pour reacutealiser simplement
une application Il peut srsquoexeacutecuter localement sur un PC ou sur des cibles embarqueacutees telle qursquoune
Raspberry PI (RPI)
Dans les deacutemonstrations que nous mettrons en œuvre nous utiliserons une RPI Par soucis de
simpliciteacute nous utiliserons les derniegraveres versions de Raspbian (systegraveme drsquoexploitation de la RPI) qui
integravegre drsquoorigine Node-RED Il nrsquoy a donc tregraves peu de chose agrave mettre en place pour arriver agrave mettre
en place une Application Nous pouvons travailler soit directement sur la RPI agrave lrsquoaide drsquoune souris-
clavier mais il est recommandeacute de travailler agrave distance avec une connexion SSH
812 Mise en place de lrsquoenvironnement La mise en place de la RPI avec le systegraveme drsquoexploitation Raspbian a eacuteteacute preacutesenteacute au chapitre 721
Vous pouvez reprendre la mecircme installation ou repartir sur une nouvelle
Il est possible de faire en sorte que Node-RED se lance directement au deacutemarrage gracircce agrave la
commande sudo systemctl enable noderedservice
Sil nest pas actif lancer Node-RED sur votre RPI node-red-start
Nous nous connectons au Node-RED de la RPI via un navigateur web sur le port 1880 en tapant dans
la barre dURL httpIP_Raspeberry_PI1880 Ce nous permet darriver agrave la fenecirctre suivante
Figure 90 Page daccueil de Node-RED
Il est possible de sinterfacer avec TTN avec les Nodes deacutejagrave disponibles gracircce au protocole HTTP
POST ou MQTT Neacuteanmoins nous pouvons avantageusement installer deux librairies speacutecifiques
Une qui facilite linterfaccedilage avec TTN
Une qui facilite la mise en place dinterface graphique
Installation des Nodes TTN
cd $HOMEnode-red
npm install node-red-contrib-ttn
Installation de Dashboard (interface graphique)
| 77
cd $HOMEnode-red
npm install node-red-dashboard
Il peut ecirctre necessaire de redeacutemarrer Node-RED pour prendre en compte linstallation de nos deux
Nodes
-----------------------------------
sudo apt-get install npm
sudo npm install -g npm
hash -r
cd ~node-red
npm install node-red-example node name
------------------------------------
813 Creacuteer une Application speacutecifique pour TTN Nous allons commencer par geacuterer le flux Uplink Apporter sur votre scheacutema un Node ttn uplink et
un Node Debug puis relier les Le Node ttn uplink nous permettra de configurer la
communication avec TTN en MQTT Le Node debug eacutecrira sur le terminal les informations brutes
qui seront reccedilu par le Node ttn uplink
Figure 91 Visualisation des trame publieacutees par TTN sur notre client MQTT
Double cliquer sur le Node ttn uplink pour le configurer comme la figure suivante
Le champ Name sera le nom du Node sur votre scheacutema Le champ Device ID est le device LoRa
concerneacute dans votre application De plus il faut entrer les caracteacuteristiques de votre application (Add
new ttn app) pour que Node-RED puisse sy connecter
Figure 92 Configuration du node ttn uplink
Configuration de votre nouvelle application
| 78
Figure 93 Identifiant et mot de passe de notre application
AppID Nom de votre application Dans notre cas seminaire_lorawan
Access Key Comme nous lavons deacutejagrave expliqueacute plus tocirct l Access Key vous sera donneacutee
par lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application
vous trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt
Overview
Le Node ttn uplink doit maintenant avoir le nom que vous avez configureacute Cliquer sur Deploy pour
lancer votre projet Le bloc ttn uplink doit maintenant ecirctre connecteacute agrave TTN Cela est speacutecifieacute
connected sous le bloc
Figure 94 Utilisation du Node TTN Uplink
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
Figure 95 Simulation de Uplink dans TTN
Vous devriez voir le reacutesultat dans la fenecirctre de Debug Par exemple pour le test denvoi de 31 32
correspondant au code ASCII des chiffres 1 et 2 vous devriez avoir la fenecirctre de Debug suivante
| 79
Figure 96 Reacutesultats obtenu dans la fenecirctre Debug apregraves la simulation dUplink
814 Creacuteation drsquoun Dashboard
Dans la mise en place de lenvironnement (chapitre 812) nous avons installeacute des Nodes
Dashboard qui vont nous permettre de reacutealiser une interface graphique tregraves simple et de la mettre
agrave disposition des utilisateurs via un des graphiques histogramme gauges afficheurshellip
Figure 97 Impleacutementation dune interface graphique dans Node RED
Linterface graphique que nous allons creacuteer sera constitueacutee donglet (tab) La mise en place des
composant se fait de la faccedilon suivante
Chaque eacuteleacutement graphique doit appartenir agrave un groupe de composant quil va falloir creacuteer
Chaque groupe de composant doit appartenir agrave un onglet (tab) quil va falloir creacuteer
Figure 98 Creacuteation dun groupe de composant
Figure 99 Creacuteation dun nouvel onglet dans le site web
Cliquer sur Deploy pour activer votre application
LURL pour joindre linterface graphique de votre site web est disponible sur ladresse
httpIP_Raspeberry_PI1880ui
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
| 80
Figure 100 Interface graphique du site web avec Node-RED
82 Programmation en PHP Maintenant que nous avons testeacute toute lrsquoarchitecture nous pouvons mettre en place une
application qui jouera deux rocircles
Un rocircle de Serveur HTTP POST reacutecupeacuterant les donneacutees en provenance de TTN
Un rocircle de Client HTTP POST qui geacuteneacuterera les requecirctes vers TTN
Un serveur web apache sur RPI heacuteberge cette application Linterface graphique du site web est
reacutealiseacute avec le template CSS proposeacute par Bootstrap [ httpsgetbootstrapcom ]
Figure 101 Architecture de notre application en PHP sur RPI
The Things Network
Notre Application
[ Serveur Apache sur Raspberry Pi ]
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 81
Nous allons lrsquoutiliser telle quelle Elle est juste proposeacutee agrave titre dexemple Lrsquoobjectif de cette
application est de geacuteneacuterer une ouverture fermeture de ruche agrave distance dans le cadre de projets
eacutetudiants du Master Electronique et Systegravemes Embarqueacutes de lUSMB [ httpscem-esetuniv-
smbfr ]
Figure 102 Application permettant de recevoir et deacutemettre des requecirctes HTTP POST
Configurer TTN pour pointer vers votre nouveau serveur et tester le flux montant et
descendant
| 82
9 Versions du document
Version 10 02022019
Version initiale
Version 20 23022019
Ajout drsquoun paragraphe Les systegravemes embarqueacutes dans lrsquoIoT En introduction
Compleacutement et ameacutelioration Ameacutelioration exercice eacutetalement de spectre
Correction Cacircblage Arduino
Ajout drsquoun paragraphe Fonctionnement de lrsquoArduino et ajout de librairies
Compleacutement et ameacutelioration Couche physique LoRa Ajout de 4 figures pour lrsquoexplication
de la modulation Chirp
Ajout drsquoun paragraphe sur les acronymes utiliseacutes au deacutebut du cours TTN LoRa MQTThellip
Compleacutement drsquoinformations sur les dB et dBm
Ajout LoRa Calculator
Version 30 8032019
Ajout de figure sur le rocircle de la Gateway LoRa
Ajout de paragraphe authentification avec le Network Server
Ajout de paragraphe sur le chiffrement avec lrsquoApplication Server
Ajout drsquoun sommaire en deacutebut de cours
Ajout de 2 scheacutemas ABP et OTAA
Retrait explication du deacutetail de la laquo Join Request raquo en OTAA Trop complexe attente de
reacutealisation drsquoun scheacutema plus explicite
Ajout drsquoun scheacutema sur lrsquoattaque par REPLAY
Ajout de paragraphe des diffeacuterents reacuteseaux LoRaWAN existants Opeacutereacutes et Priveacutes
Ajout des scheacutemas des trames LoRaWAN Physique LoRa MAC Application
Compleacutement drsquoinformation sur les Classes de Devices
Ajout drsquoun paragraphe sur la Gateway utiliseacutee pour le Downlink
Ajout drsquoun paragraphe sur le JSON
Compleacutement drsquoinformation sur le codage en Base64
Ajout drsquoinformation dans le deacutecodage des trames LoRaWAN
Restructuration des explications sur lrsquoenvoi et la reacutecupeacuteration des donneacutees en HTTPMQTT
Version 40 8032019
Ajout drsquoun chapitre Creacuteation de notre propre Application
Ajout drsquoun chapitre Creacuteation de notre propre Network et Application Server
Ajout drsquoune figure Visualisation des Chirps LoRa par SDR (Radio Logicielle)
Compleacutements drsquoinformation sur MQTT
Compleacutements dinformation sur les Topics de TTN en MQTT
| 4
444 Couche physique Modulation LoRa 34 445 Canaux et bandes de freacutequences et Data Rate (DR) 35 446 Trame reccedilue et transmise par la Gateway LoRaWAN 36 447 Le format JSON 37
5 MISE EN ŒUVRE DrsquoUN RESEAU LORAWAN 38
51 LES DIFFERENTS TYPES DE RESEAUX 38 511 Les reacuteseaux LoRaWAN opeacutereacutes 38 512 Les reacuteseaux LoRaWAN priveacutes 38 513 Les zones de couvertures 38
52 THE THINGS NETWORK (TTN) 39 521 Preacutesentation de TTN 39 522 Configuration de la Gateway 39 523 Enregistrement des Gateways Appplication et Devices 39 524 Configuration des Devices LoRa 40
53 MISE EN APPLICATION 41 54 ANALYSE DES TRAMES ECHANGEES 41
541 Utilisation de la base 64 41 542 Inteacuterecirct et inconveacutenient de la base 64 43 543 Uplink Du Device LoRa au Network Server 43 544 Uplink Du Network Server agrave lrsquoApplication Server 45 545 Simulation drsquoUplink dans lrsquoApplication Server 46 546 Downlink De lrsquoApplication Server au Device LoRa 46
6 LA RECUPERATION DES DONNEES SUR NOTRE PROPRE APPLICATION 47
61 RECUPERATION DES DONNEES EN HTTP POST DANS LrsquoAPPLICATION 47 611 Preacutesentation du protocole HTTP 47 612 Fonctionnement drsquoun client et drsquoun serveur HTTP POST 48 613 Test du serveur HTTP POST 49 614 Test du client HTTP POST 49 615 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST 49 611 Envoyer des donneacutees depuis notre Application avec HTTP POST 51
62 RECUPERATION DES DONNEES AVEC MQTT DANS LrsquoAPPLICATION 52 621 Preacutesentation du protocole MQTT 52 622 Connexion au Broker MQTT 53 623 Qualiteacute de Service au cours dune mecircme connexion 53 624 Qualiteacute de Service apregraves une reconnexion 55 625 Les Topics du protocole MQTT 55 626 Mise en place drsquoun Broker MQTT 56 627 Mise en place drsquoun Publisher et drsquoun Subscriber MQTT 57 628 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT 57 629 Envoyer des donneacutees depuis notre Application avec MQTT 60
7 CREATION DE NOTRE PROPRE NETWORK ET APPLICATION SERVER 63
711 Objectifs 63 712 Preacutesentation de LoRaServer 63 713 Le laquo Packet Forwarder raquo (Gateway) 64 714 LoRa Gateway Bridge 66 715 LoRa Server (Network Server) 66 716 LoRa App Server (Application Server) 67 717 LoRa Geo Server 67 718 Application 67
72 INSTALLATION DE LORASERVER 67
| 5
721 Mise en place de lrsquoenvironnement 67 722 Installation sur la Raspberry PI 68
71 CONFIGURATION DE LORA SERVER POUR LUPLINK 69 711 Enregistrement drsquoune nouvelle Organisation 69 712 Enregistrement drsquoune instance du Network Server 69 713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) 70 714 Enregistrement des Devices LoRa 71 715 Visualisation des trames reccedilues 72
72 CONFIGURATION DE LORASERVER POUR LINTEGRATION DAPPLICATION 74 721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST 74 722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT 74
8 CREATION DE NOTRE PROPRE APPLICATION 76
81 UTILISATION DE NODE-RED 76 811 Preacutesentation 76 812 Mise en place de lrsquoenvironnement 76 813 Creacuteer une Application speacutecifique pour TTN 77 814 Creacuteation drsquoun Dashboard 79
82 PROGRAMMATION EN PHP 80
9 VERSIONS DU DOCUMENT 82
| 6
1 Les systegravemes embarqueacutes et lrsquoIoT
11 LInternet des Objets ( Internet of Things IoT )
111 Les systegravemes embarqueacutes dans lrsquoIoT Drsquoune faccedilon geacuteneacuterale les systegravemes eacutelectroniques peuvent ecirctre caracteacuteriseacutes par leur consommation
leur puissance de calcul leur taille et leur prix Dans le cas speacutecifique des systegravemes embarqueacutes
utiliseacutes dans lrsquoIoT nous pouvons affecter le poids suivant agrave chacune des caracteacuteristiques
Figure 1 Consommation Puissance Taille et Prix des objets connecteacutes
Compareacutes aux autres systegravemes eacutelectroniques les systegravemes embarqueacutes utiliseacutes dans lrsquoIoT possegravedent
donc
Une faible consommation
Une faible puissance de calcul
Une petite taille
Un prix faible
112 Diffeacuterents protocoles dans lrsquoIoT
Citez les diffeacuterents protocoles que vous connaissez dans le mode de lrsquoIoT (Internet Of
Things) et reportez-les dans le graphique ci-dessous en fonction de leur bande passante
et de leur porteacutee
Figure 2 Protocoles utiliseacutes dans lIoT en fonction du deacutebit et de la porteacutee
Dans lrsquoIoT les protocoles utiliseacutes possegravedent une grande porteacutee et des deacutebits faibles
Lrsquoensemble de ces reacuteseaux sont deacutenommeacutes LPWAN Low Power Wide Area Network
113 Bande de freacutequence utiliseacutees En Europe les bandes de freacutequences libres (sans licence) sont
13 Mhz (RFID) 169 Mhz 434 Mhz 868 Mhz 24Ghz 5 Ghz et 24 Ghz (Faisceau Hertzien) Parmi ces
freacutequences seul le 433 MHz et 868 MHz sont utilisables en LoRa
12 Modes de partage du support Quel que soit le protocole utiliseacute le support de transfert de lrsquoinformation est lrsquoair car tous les
protocoles de lrsquoIoT sont Wireless Le support doit ecirctre partageacute entre tous les utilisateurs de telle
faccedilon que chacun des dispositifs Wireless ne perturbe pas les autres Pour cela une bande de
freacutequence est alloueacutee Par exemple pour la radio FM la bande de freacutequence va de 875 Mhz agrave 108
Mhz
Dans leur bande de freacutequence les dispositifs peuvent se partager le support de diffeacuterentes
maniegraveres
FDM (Frequency Division Multiplexing) Ce mode utilise une partie du spectre (bande de
freacutequence) en permanence Exemple Radio FM
TDM (Time Division Multiplexing) Ce mode utilise tout le spectre (bande de freacutequence) par
intermittence Exemple GSM on a laquo 8 time slots raquo par canal
CDMA (Code Division Multiple Access) Ce mode utilise tout le spectre tout le temps
Porteacutee (Range)
Deacutebit (Bandwidth)
| 8
Les Devices LoRa sont capables drsquoeacutemettre sur un mecircme canal en mecircme temps Le protocole LoRa
utilise une modulation tregraves similaire agrave la meacutethode 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 Plus
tard dans le cours nous expliquerons les diffeacuterences de la modulation LoRa
13 Notion drsquo eacutetalement de spectre utiliseacutee en LoRa Nous allons voir au travers drsquoun exercice comment il est possible drsquoutiliser tout le spectre en
permanence tout en eacutetant capable drsquoeffectuer plusieurs transactions simultaneacutees entre diffeacuterents
eacutemetteursreacutecepteurs Cette meacutethode est souvent appeleacutee laquo eacutetalement de spectre raquo car comme
son nom lrsquoindique elle a pour conseacutequence drsquoeacutetaler le spectre du signal transmis
La meacutethode consiste agrave utiliser des codes qui ont des proprieacuteteacutes matheacutematiques adapteacutees agrave notre
objectif Transmettre en mecircme temps sur la mecircme bande de freacutequence La matrice ci-dessous
donne par exemple 4 codes drsquoeacutetalement (1 par ligne)
Code Orthogonal User 0 1 1 1 1
Code Orthogonal User 1 1 -1 1 -1
Code Orthogonal User 2 1 1 -1 -1
Code Orthogonal User 3 1 -1 -1 1
Tableau 1 Matrice de Hadamart (matheacutematicien) dordre 4
Les proprieacuteteacutes de ces codes (1 1 1 1 1 -1 1 -1 1 1 -1 -1 1 -1 -1 1) ne sont pas expliqueacutees ici Nous
nous conterons de veacuterifier leur bon fonctionnement
131 Transmissions successives Chaque tableau ci-dessous repreacutesente une transmission qui est indeacutependante des autres elles ne
se deacuteroulent pas en mecircme temps On veacuterifie qursquoavec la mise en œuvre de laquo lrsquoeacutetalement de spectre raquo
chaque transmission arrive bien agrave destination avec le message qui avait eacuteteacute transmis Le premier
tableau est deacutejagrave rempli en guise drsquoexemple La meacutethode est la suivante
A lrsquoeacutemission
Chaque bit du message est multiplieacute par un code drsquoeacutetalement (une ligne de la matrice)
Le reacutesultat de la multiplication est transmis
A la reacuteception
Chaque symbole reccedilu est multiplieacute par le mecircme code drsquoeacutetalement
Le message reccedilu est eacutegal agrave la somme des symboles diviseacute par le nombre de symbole
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
hellip transmission hellip
4 Utilisation code orthogonal User 1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1
5 Deacutecodage = (3) x (4) 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0
6 Message reccedilu (sum (5) nbr_bits) 1 0 1 0
Reacutealiser la transmission du message du User 2 et du User 3 dans les tableaux suivants
| 9
1rsquo Message User 2 0 1 0 1
2rsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
3rsquo Symboles transmis User 2 = (1rsquo) x (2rsquo) 0 0 0 0
hellip transmission hellip
4rsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
5rsquo Deacutecodage = (3rsquo) x (4rsquo) 0 0 0 0
6rsquo Message reccedilu (sum (5rsquo) nbr_bits) 0
1rsquorsquo Message User 3 1 1 0 0
2rsquorsquo Utilisation code orthogonal User 3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
3rsquorsquo Symboles transmis User 3 = (1rsquorsquo) x (2rsquorsquo) 1 -1 -1 1
hellip transmission hellip
4rsquorsquo Utilisation code orthogonal User3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
5rsquorsquo Deacutecodage = (3rsquorsquo) x (4rsquorsquo) 1 1 1 1
6rsquorsquo Message reccedilu (sum (5rsquorsquo) nbr_bits) 1
132 Transmissions simultaneacutees
Les transmissions se deacuteroulent maintenant simultaneacutement les messages des User 1 User 2 et User
3 sont envoyeacutes en mecircme temps sur la mecircme bande de freacutequence La premiegravere colonne du User 1
est deacutejagrave remplie en guise drsquoexemple La meacutethode est la suivante
Dans lrsquoair
On additionne les symboles transmis par tous les User (1 2 3) ligne 1rsquorsquorsquo
Pour la reacuteception
Chaque symbole reccedilu est multiplieacute par le code drsquoeacutetalement du User
Le message reccedilu est eacutegal agrave la somme des symboles diviseacute par le nombre de symbole
Valider le fonctionnement pour la reacuteception des messages
1rsquorsquorsquo sum des symboles transmis ( 3 + 3rsquo + 3rsquorsquo ) 2 -2 0 0
2rsquorsquorsquo Utilisation code orthogonal User 1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 2 0 0
4rsquorsquorsquo Message reccedilu User 1 (sum (3rsquorsquorsquo) nbr_bits) 1
2rsquorsquorsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 -2 0 0
4rsquorsquorsquo Message reccedilu User 2 (sum (3rsquorsquorsquo) nbr_bits) 0
2rsquorsquorsquo Utilisation code orthogonal User 3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 2 0 0
4rsquorsquorsquo Message reccedilu User 3 (sum (3rsquorsquorsquo) nbr_bits) 1
133 Cas du protocole LoRa Le LoRa utilise une meacutethode drsquoeacutetalement de spectre qui nrsquoest pas exactement celle que nous venons
drsquoeacutetudier La finaliteacute est cependant la mecircme Pouvoir transmettre en mecircme temps sur le mecircme
canal Le protocole LoRa utilise sept laquo codes drsquoeacutetalement raquo appeleacutes Spreading Factor [ SF6 SF7 SF8
SF9 SF10 SF11 et SF12 ] qui lui permet drsquoavoir sept transmissions simultaneacutees sur un mecircme canal
| 10
2 Transmission radio et propagation
21 Les uniteacutes et deacutefinitions dB Rapport entre deux puissances Une atteacutenuation est repreacutesenteacutee par un nombre
neacutegatif (-) Un gain est repreacutesenteacute par un nombre positif (+)
Rapport de puissances en dB Rapport de puissance
+ 3 dB Multiplication par 2
- 3 dB Division par 2
0 dB Egaliteacute
+ 10 dB Multiplication par 10
- 10 dB Division par 10
Tableau 2 Comparaison entre les gains en dB et en proportion
dBi Gain theacuteorique drsquoune antenne
dBm Puissance rameneacutee agrave 1mW 0 dBm correspond agrave 1 mW
En reprenant la deacutefinition des dB remplir le tableau suivant
Puissance en dBm Puissance en mW
+ 3 dBm
- 3 dBm
+ 10 dBm
- 10 dBm
Tableau 3 Comparaison entre les puissances en dB et en mW
Le Talkie-Walkie a une puissance drsquoeacutemission de 2W Quelle est la puissance drsquoeacutemission
exprimeacutees en dBm
Sensibiliteacute Puissance minimale qursquoest capable de deacutetecter un reacutecepteur
RSSI Received Signal Strength Indication
SNR Signal over Noise Ratio
Un eacutemetteur transmet agrave une puissance de 13dBm en utilisant une antenne dont le gain
est de 2dBi Les pertes dans lrsquoair sont de 60 dB Lrsquoantenne reacuteceptrice qui possegravede un gain
de 2dBi est relieacutee agrave un reacutecepteur dont la sensibiliteacute est de -80 dBm Le signal pourra-t-il
ecirctre reccedilu
Le link Budget Crsquoest la quantiteacute de puissance que nous pouvons perdre avant drsquoarriver au
reacutecepteur tout en conservant une transmission fonctionnelle Autrement dit crsquoest la
puissance de lrsquoeacutemetteur moins la sensibiliteacute du reacutecepteur Dans lrsquoexemple preacuteceacutedent le
budget que nous avons agrave disposition est de 93dB
| 11
En LoRa nous avons un Link Budget de 157 dB
En LTE (4G) nous avons un Link Budget de 130 dB
Etude de la documentation drsquoun composant LoRa Le RN2483 est le composant radiofreacutequence que nous utiliserons dans notre transmission LoRa
Voici quelques une de ses caracteacuteristiques
Figure 3 Caracteacuteristiques principales du composant radiofreacutequence utiliseacute
Reprenez la deacutefinition du Link Budget et retrouver les 157 dB annonceacute dans cette
documentation
En LoRa plus le code drsquoeacutetalement est grand plus on est capable drsquoeacutemettre dans un milieu bruiteacute La
figure ci-dessous preacutesente les rapports signal sur bruit avec lesquels nous seront capable de reacutealiser
une transmission en fonction des Spreading Factor utiliseacutes
Figure 4 Influence du Spreading Factor sur le SNR acceptable
On remarque que pour un SF8 nous sommes capables drsquoeacutemettre avec un SNR de -10 dB On pourra
transmettre malgreacute le fait que le bruit est 10 fois supeacuterieur au signal
On remarque que pour un SF12 nous sommes capables drsquoeacutemettre avec un SNR de -20 dB On
pourra transmettre malgreacute le fait que le bruit est 100 fois supeacuterieur au signal
| 12
Cependant on remarque aussi que lrsquoutilisation drsquoun Spreading Factor plus eacuteleveacute augmente
consideacuterablement le nombre de symbole eacutemis (2egraveme colonne du tableau) Comme nous le verrons
plus tard cela impactera eacutevidement le temps de transmission
| 13
3 La couche physique LoRa
31 La modulation LoRa Comme nous lrsquoavons expliqueacute plus tocirct la modulation LoRa utilise lrsquoeacutetalement de spectre pour
transmettre ces informations Mais au lieu drsquoutiliser des codes drsquoeacutetalement (CDMA) elle utilise une
meacutethode appeleacutee Chirp Spread Spectrum La finaliteacute est toujours la mecircme Avoir plusieurs
transmissions dans le mecircme canal La conseacutequence sur le spectre est aussi la mecircme cela provoque
un eacutetalement du spectre
311 La forme du symbole (Chirp) Le signal eacutemis par la modulation LoRa est un symbole dont la forme de base est repreacutesenteacutee ci-
dessous Son nom (Chirp) vient du fait que ce symbole est utiliseacute dans la technologie Radar (Chirp
Compressed High Intensity Radar Pulse)
Figure 5 Symbole de la modulation LoRa (source Wikipeacutedia)
La freacutequence de deacutepart est la freacutequence centrale du canal moins la Bande Passante diviseacutee par deux
La freacutequence de fin est la freacutequence centrale plus la Bande Passante diviseacutee par deux
La freacutequence centrale est appeleacutee le canal
La bande passante est la largeur de bande occupeacutee autour du canal
On considegravere une eacutemission sur la freacutequence centrale 868 Mhz avec une Bande Passante
de 125 kHz Donner la freacutequence de deacutebut et la freacutequence de fin du sweep
Freacutequence de deacutebut
Freacutequence de fin
Pour faciliter la repreacutesentation de ce symbole on utilise plutocirct un graphique TempsFreacutequence de
la forme suivante
| 14
Figure 6 Forme du symbole de base (CHIRP)
En LoRa chaque symbole repreacutesente un certain nombre de bits transmis La regravegle est la suivante
Nombre de bits transmis dans un symbole = Spreading Factor
Par exemple si la transmission utilise un Spreading Factor de 10 (SF10) alors un symbole repreacutesente
10 bits
Crsquoest-agrave-dire qursquoagrave lrsquoeacutemission les bits sont regroupeacutes par paquet de SF bits puis chaque paquet est
repreacutesenteacute par un symbole particulier parmi 2119878119865formes de symboles possibles
Sur la figure suivante voici un exemple theacuteorique drsquoune modulation en SF2 agrave 868 Mhz sur une
bande passante de 125 kHz Chaque symbole repreacutesente donc 2 bits
Figure 7 Symboles eacutemis en Modulation LoRa (Cas theacuteorique en SF2)
Exemple
On considegravere la suite binaire suivante 0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Le Spreading Factor utiliseacute est SF10
Nous regroupons donc les bits par paquet de 10 Chaque paquet de 10 bits sera repreacutesenteacute par un
symbole (sweep) particulier Il y a 1024 symboles diffeacuterents pour coder les 1024 combinaisons
binaires possibles (210)
Freacutequence
Temps
868 000 000 Hz
868 062 500 Hz
Un symbole Un symbole
867 937 500 Hz
Temps
868 000 000 Hz
867 937 500 Hz
Symbole 0
Bits laquo 00 raquo
Symbole 1
Bits laquo 01 raquo
Symbole 2
Bits laquo 10 raquo Symbole 3
Bits laquo 11 raquo
12
5 k
Hz
868 062 500 Hz
| 15
Figure 8 Emission des Chirp en LoRa
Avec un outils drsquoanalyse spectrale actif pendant lrsquoeacutemission LoRa drsquoun Device on peut afficher les
successions de symbole qui sont envoyeacutes Cette oscillogramme a eacuteteacute reacutealiseacute agrave lrsquoaide drsquoun SDR
(Software Digital Radio)
Figure 9 Visualisation des Chirps LoRa reacuteellement eacutemis pendant une transmission
312 Dureacutee drsquoeacutemission drsquoun symbole En LoRa la dureacutee drsquoeacutemission de chaque symbole (Chirp) deacutepend du Spreading Factor utiliseacute Plus le
SF est grand et plus le temps drsquoeacutemission sera long Pour une mecircme bande passante le temps
drsquoeacutemission drsquoun symbole en SF8 est deux fois plus long que le temps drsquoeacutemission drsquoun symbole en
SF7 Ainsi de suite jusqursquoagrave SF12
0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Envoi de 1 Chirp Envoi de 1 Chirp Envoi de 1 Chirp
Transmission Transmission Transmission
| 16
Figure 10 Temps drsquoeacutemission drsquoun symbole (Chirp) en fonction du SF
En revanche le temps drsquoeacutemission drsquoun symbole est inversement proportionnel agrave la bande passante
119879119904 =2119878119865
119861119886119899119889119908119894119889119905ℎ Le deacutebit des symboles est donc de
1
119879119878= 119865119904 =
119861119886119899119889119908119894119889119905ℎ
2119878119865 En toute logique plus la
bande passant est eacuteleveacute plus le deacutebit des symboles sera eacuteleveacute Comme chaque symbole comprend
SF bit on retrouve alors le deacutebit binaire
119863119887 = 119878119865119861119886119899119889119908119894119889119905ℎ
2119878119865
Plus le Spreading Factor sera eacuteleveacute plus le deacutebit binaire sera faible
Plus la Bande Passante sera eacuteleveacutee plus le deacutebit binaire sera fort
Exemple Drsquoapregraves la formule du deacutebit binaire trouver le deacutebit pour les deux cas suivants
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
32 Coding Rate Le Coding Rate est un ratio qui augmentera le nombre de bits agrave transmettre afin de reacutealiser de la
deacutetection correction drsquoerreur Dans le cas drsquoun CR = 4 8 il y aura 8 bits transmis reacuteellement agrave
chaque fois que nous souhaitons transmettre 4 bits Dans cette exemple cela provoque une
transmission drsquoun nombre de bit multiplieacute par 2
SF7
Freacutequence
Temps
Freacutequence centrale
Freacutequence haute
Temps drsquoun symbole eacutemit en SF 12
Freacutequence basse
SF8
SF9
SF10
SF11
SF12
Temps drsquoun symbole eacutemit en SF 11
| 17
Figure 11 Influence du Coding Rate sur le nombre de bits ajouteacute
Si on reprend lrsquoexemple preacuteceacutedent avec un CR de 4 5 nous avons une augmentation de 125 du
nombre de bits agrave transmettre Redonner la deacutebit en prenant en compte le CR
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
La documentation du composant RN2483 donne les deacutebits en fonction du Spreading Factor
la Bande Passante et le Coding Rate Veacuterifier la coheacuterence du reacutesultat avec votre calcul
preacuteceacutedent
Figure 12 Deacutebit en fonction des paramegravetres de la transmission LoRa
33 Utilisation du LoRa Calculator Le logiciel laquo LoRa Calculator raquo est un petit exeacutecutable permettant de simuler une transmission LoRa
en fonction des caracteacuteristiques saisies Canal SF CR etchellip Il est teacuteleacutechargeable agrave lrsquoadresse
suivante httpsbitly2TyloAh
| 18
Figure 13 Le logiciel LoRa Calculator
En reprenant lrsquoexemple preacuteceacutedent (SF7 Bande Passante 125 kHz CR 45) veacuterifier les
calculs du laquo Equivalent Bitrate raquo
34 Time On Air La norme LoRaWAN impose qursquoun Device LoRa ne transmette pas plus de 1 du temps Cela est
repreacutesenteacute par un Duty Cycle Par exemple un Duty Cycle de 1 signifie que si jrsquoeacutemet pendant 1 je
ne dois plus eacutemettre pendant 99 quel que soit lrsquouniteacute de temps utiliseacutee
En reprenant les exemples preacuteceacutedents quels sont les deacutebits moyens si on prend en compte
le laquo Time On Air raquo
Cas 1 Pour SF7 et 125 khz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
Dans le logiciel laquo LoRa Calculator raquo (onglet laquo Energy Profile raquo) nous pouvons estimer la
dureacutee de vie drsquoune batterie Nous prenons lrsquoexemple drsquoun releveacute de tempeacuterature dans un
bacirctiment avec les caracteacuteristiques suivantes
| 19
SF CR Bande Passante etc Nous nous placcedilons dans le cas 1 des exemples preacuteceacutedents
Le releveacute de tempeacuterature se fera toutes les 15 mins
La batterie est constitueacute de 3 petites piles bacirctons [ AAA LR03 ] 12V en seacuterie Soit 36 V
1000 mAh
35 Mise en œuvre LoRa en point agrave point Ce test sera reacutealiseacute avec des modules LoRa RN2483 (Microchip) et une carte microcontrocircleur
ARDUINO
Figure 14 Communication LoRa en Point agrave Point
Reacutealiser le cacircblage de votre module RN2483 suivant le tableau suivant
Connecteur Arduino Click Board RN2483
5V 5V
GND GND
11 RX
10 TX
Tableau 4 Cacircblage de lrsquoARDUINO et de la click Board RN2483
351 Utilisation de lrsquoIDE Arduino Lrsquoenvironnement Arduino est tregraves simple Nous allons reacutealiser un programme pour montrer son
fonctionnement
La connexion de la carte est effectueacutee agrave lrsquoaide drsquoun port USB qui eacutemule une liaison seacuterie
RS232 Il faut donc choisir le bon port Arduino IDE gt Outils gt Port
Pour creacuteer un nouveau programme (sketch) Arduino IDE gt Fichier gt Nouveau
Il y a deux parties dans un sketch
Une fonction setup() qui sera exeacutecuteacutee qursquoune seule fois au deacutemarrage
Une fonction loop() qui sera exeacutecuteacutee en boucle
Ecrire le code suivant
Emetteur
Reacutecepteur
UA
RT
UA
RT
| 20
void setup()
Serialbegin(9600)
void loop()
Serialprintln(hello word)
Compiler et Teacuteleacuteverser Croquis gt Teacuteleacuteverser
Voir la sortie sur la liaison seacuterie Outils gt Moniteur Seacuterie gt Choisir la vitesse de
transmission ici 9600 bauds (en bas agrave droite)
352 Validation du fonctionnement Deux binocircmes joueront le rocircle drsquoeacutemetteur tous les autres binocircmes seront en reacutecepteur
Reacutecupeacuterer les programmes dans Moodle dans le dossier laquo RN2483-Arduino-Point2Point raquo
Installer la librairie RN2483 Arduino IDE gt Croquis gt Inclure une bibliothegraveque gt Ajouter la
bibliothegraveque zip
Reacutepartissez les rocircles Emetteurs Reacutecepteurs et reacutecupeacuterer le programme LoraBlinkerRX ou
LoraBlinkerTX en fonction Les 2 binocircmes en eacutemission devront modifier le code du sketch
Arduino pour transmettre des donneacutees speacutecifiques afin de les diffeacuterencier [
loraSerialprintln(radio tx 30) ]
Validez la reacuteception des donneacutees eacutemises par les deux binocircmes qui transmettent des
donneacutees Ces donneacutees reccedilues sont eacutecrite agrave 57600 bauds sur le moniteur seacuterie de lrsquoArduino
353 Mise en valeur du Spreading Factor On srsquoaperccediloit dans la manipulation preacuteceacutedente que les Devices LoRa reccediloivent les donneacutees des deux
eacutemetteurs Nous allons conserver le mecircme canal drsquoeacutemission (8691 Mhz) mais un des deux
eacutemetteurs va modifier son laquo Spreading Factor raquo La salle sera donc seacutepareacutee en deux groupes
1er groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF7
2egraveme groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF8
Validez la reacuteception des donneacutees eacutemises seulement pour le Spreading Factor que vous
utilisez
| 21
4 Le protocole LoRaWAN
Le LoRa est le type de modulation utiliseacute entre deux Devices ou entre un Device et une Gateway
Lorsque nous parlons de lrsquoensemble de la chaine de communication (Device Gateway Serveur) alors
nous parlons de communication LoRaWAN Nous allons voir lrsquoarchitecture drsquoun reacuteseau LoRaWAN
ainsi que les regravegles de ce protocole
41 Structure drsquoun reacuteseau LoRaWAN Nous retrouvons drsquoun cocircteacute le Device LoRa qui transmet une donneacutee Elle est reacuteceptionneacutee agrave lrsquoautre
extreacutemiteacute du reacuteseau par un Utilisateur La structure globale du reacuteseau LoRaWAN peut ecirctre
repreacutesenteacutee par la figure suivante
411 Les Devices LoRa Les Devices LoRa sont des systegravemes eacutelectroniques appartenant au monde de lrsquoIoT Faible
consommation faible taille faible puissance et faible taille
Ils possegravedent une radio LoRa permettant de joindre les Gateways Les Gateways ne sont pas
adresseacutees speacutecifiquement toutes celles preacutesentes dans la zone de couverture reccediloivent les
messages et les traitent
412 Les Gateways LoRa Elles eacutecoutent sur tous les canaux et sur tous les Spreading Factor Lorsqursquoune trame LoRa est reccedilue
elle transmet son contenu sur internet agrave destination du Network Server qui a eacuteteacute configureacute dans la
Gateway au preacutealable
Elle joue donc le rocircle de passerelle entre une modulation LoRa et une communication IP
Devices
LoRa Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
Internet Internet
Figure 15 Structure globale dun reacuteseau LORAWAN
| 22
Chaque Gateway LoRa possegravede un identifiant unique (EUI sur 64 bits)
413 Le Network Server
Le Network Server reccediloit les messages transmis par les Gateways et supprime les doublons
(plusieurs Gateway peuvent avoir reccedilu le mecircme message) Les informations transmises au Network
Server depuis les Devices LoRa sont authentifieacutes gracircce agrave une cleacute AES 128 bits appeleacutee Network
Session Key NwkSKey Nous parlons bien ici drsquoauthentification et non pas de chiffrement comme
nous le verrons plus tard
414 Application Server Il est souvent sur le mecircme support physique que le Network Server Il permet de dissocier les
applications les unes des autres Chaque application enregistre des Devices LoRa qui auront le droit
Devices Gateways Network
Server
Internet
Network Session Key (NwkSKey)
Authentification
Figure 17 Authentification entre le Device LoRa et le Network Server
Internet
UDP IP
Modulation
LoRa
Device LoRa
Gateway
Network Server
LoRaWAN
Modulation
LoRa
Passerelle LoRa Internet
Internet
UDP IP
LoRaWAN
Transmission Radio
Application Application
Figure 16 Le rocircle de la Gateway LoRa
| 23
de stocker leurs donneacutees (Frame Payload) Les message transmis agrave lrsquoapplication server sont chiffreacutes
gracircce agrave une cleacute AES 128 bits appeleacutee Application Session Key AppSKey
Le scheacutema suivant reacutesume lrsquoutilisation
De la Network Session Key (NwkSKey) pour lrsquoauthentification entre le Device LoRa et le
Network Server
De lrsquoApplication Session Key (AppSKey) pour le chiffrement entre le Device LoRa et
lrsquoApplication Server
Devices Gateways Network
Server Application
Server
Internet
Application Session Key (AppSKey)
Chiffrement
Figure 18 Chiffrement entre le Device LORA et lrsquoApplication Server
| 24
415 Application Web Serveur Cette application doit drsquoune part reacutecupeacuterer les donneacutees de lrsquoApplication Serveur Dans le cadre de
ce cours cela sera fait de deux faccedilons
Avec le protocole HTTP
Avec le protocole MQTT
Figure 20 Application Web Server
Figure 19 Authentification et chiffrement en LoRaWan
Devices Gateways
Network
Server Application
Server
Internet
Network Session Key
Application Session Key
Network
Server Application
Server
Application
Server Web
Utilisateur
Protocole
MQTT ou HTTP
Flux Uplink
Flux Downlink
| 25
Le flux habituel dans lrsquoIoT est le flux Uplink (flux montant) crsquoest-agrave-dire lrsquoeacutemission de donneacutees des
objets vers le serveur Comme nous lrsquoexpliquerons plus loin en LoRaWAN il est aussi possible de
transfeacuterer des donneacutees aux Device LoRa par un flux Downlink (flux descendant)
Drsquoautre part lrsquoapplication mettra agrave disposition les donneacutees aux utilisateurs sous forme par exemple
drsquoun serveur web drsquoune base de donneacutees et drsquoune visualisation graphique
416 Authentification avec le Network Server La Network Session Key (NwkSKey) sert agrave lrsquoauthentification entre le Device LoRa e le Network Server
Afin de reacutealiser cette authentification entre le Device et le Network Server un champ MIC (Message
Integrity Control) est rajouteacute agrave la trame Il est calculeacute en fonction des donneacutees transmises et du
NwkSkey A la reacuteception le mecircme calcul est effectueacute Si les cleacutes sont eacutequivalentes dans le Device et
dans le Network Server alors les deux MIC calculeacutes doivent correspondre
417 Chiffrement des donneacutees vers lrsquoApplication Server
LrsquoApplication Session Key (AppSKey) sert pour le chiffrement entre le Device LoRa et lrsquoApplication
Server Les donneacutees chiffreacutees seront alors deacutecodeacutees agrave la reacuteception sur lrsquoApplication Server srsquoil
possegravede la mecircme cleacute Si on reprend le scheacutema preacuteceacutedent les laquo donneacutees x raquo sont chiffreacutees
deacutechiffreacutees par le processus suivant
Donneacutees x chiffreacutees NwkSkey x
MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees
NwkSkey x
Trame eacutemise Trame reccedilue
Device LoRa Network Server
Si =
Alors la trame est authentifieacutee
MIC geacuteneacutereacute Emission MIC geacuteneacutereacute Reacuteception
MIC geacuteneacutereacute Reacuteception
Figure 21 Authentification dun Device LoRa par le Network Server
| 26
Figure 22 Chiffrement des donneacutees par lApplication Session Key
418 Combinaison de lrsquoauthentification et du chiffrement On peut maintenant repreacutesenter sur le mecircme scheacutema la construction de la trame LoRaWAN avec
drsquoune part lrsquoauthentification et drsquoautre part le chiffrement
Figure 23 Chiffrement puis Authentification
42 Classes des Devices LoRaWAN Les Devices LoRa sont classeacutes en 3 cateacutegories (A B C) en fonction de leur consommation et de leur
accessibiliteacute en Downlink crsquoest-agrave-dire la faciliteacute qursquoun utilisateur aura agrave transmettre une trame au
Device LoRa
421 Classe A (All) Minimal power Application Tous les Devices LoRaWAN sont de classe A Chaque Device peut transmettre (Uplink) agrave la Gateway
sans veacuterification de la disponibiliteacute du reacutecepteur Si la transmission eacutechoue elle sera reacuteeacutemise apregraves
un certain temps Cette transmission est suivie de 2 fenecirctres de reacuteception tregraves courtes La Gateway
peut alors transmettre pendant le laquo RX Slot 1 raquo ou le laquo RX Slot 2 raquo mais pas les deux
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Device LoRa
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Application Server
Donneacutees non chiffreacutees
AppSKey
Donneacutees chiffreacutees Entecircte
NwkSKey
MIC geacuteneacutereacute en eacutemission Trame transmise =
| 27
Figure 24 Slots de reacuteception pour un Device LoRa de classe A
Source de lrsquoimage httpszakelijkforumkpncom
La dureacutee des fenecirctres doit ecirctre au minimum la dureacutee de reacuteception drsquoun preacuteambule Un preacuteambule
dure 1225 Tsymbole et deacutepend donc du Data Rate (DR voir paragraphe 445 pour plus drsquoinformation
sur le DR) Lorsque qursquoun preacuteambule est deacutetecteacute le reacutecepteur doit rester actif jusqursquoagrave la fin de la
transmission Si la trame reccedilue pendant la premiegravere fenecirctre de reacuteception eacutetait bien agrave destination du
Device LoRa alors la deuxiegraveme fenecirctre nrsquoest pas ouverte
Premiegravere fenecirctre de reacuteception
Le Slot RX1 est programmeacute par deacutefaut agrave 1 seconde + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont les mecircme que ceux choisis lors de la phase drsquoeacutemission
(Uplink)
Seconde fenecirctre de reacuteception
Le Slot RX2 est programmeacute par deacutefaut agrave 2 secondes + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont configurables mais fixes
Un Device LoRa qui est uniquement de classe A ne peut pas recevoir srsquoil nrsquoa pas eacutemis Il
nrsquoest donc pas joignable facilement
422 Classe B (Beacon) Scheduled Receive Slot Les Devices de classe B ont le mecircme comportement que les Devices de classe A mais drsquoautres
fenecirctres de reacuteceptions sont programmeacutees agrave des peacuteriodes preacutecises Afin de synchroniser les fenecirctres
de reacuteception du Device LoRa la Gateway doit transmettre des balises (Beacons) de faccedilon reacuteguliegravere
| 28
Figure 25 Slots de reacuteception pour un Device LoRa de classe B
Source de lrsquoimage httpszakelijkforumkpncom
Un Device LoRa de classe B est joignable reacuteguliegraverement sans qursquoil soit neacutecessairement
obligeacute drsquoeacutemettre En revanche il consomme plus qursquoun Device de classe A
423 Classe C (Continuous) Continuously Listening Les Devices de classe C ont des fenecirctres de reacuteception constamment ouvertes entre 2 Uplinks Ces
Devices consomment donc beaucoup plus
Figure 26 Slots de reacuteception pour un Device LoRa de classe C
Source de lrsquoimage httpszakelijkforumkpncom
| 29
Un Device LoRa de classe C est joignable en permanence En revanche crsquoest la classe de
Device qui est la plus eacutenergivore
424 Quelle Gateway pour les flux Downlink
Nous avons donc vu que le fonctionnement classique du protocole LoRaWAN eacutetait de reacutecupeacuterer de
lrsquoinformation depuis le Device LoRa Crsquoest le flux Uplink
Dans le cas ougrave lrsquoutilisateur transmet des informations au Device LoRa (flux Downlink) on peut se
demander quelle Gateway sera choisie pour transfeacuterer les donneacutees au Device LoRa En effet
lrsquoendroit ougrave est situeacute le Device LoRa nrsquoest pas neacutecessairement connu agrave lrsquoavance
La Gateway utiliseacutee pour le Downlink est celle qui a reccedilu le dernier message du Device
LoRa Un message ne pourra jamais arriver agrave destination drsquoun Device LoRa si celui-ci nrsquoa
jamais transmis quel que soit sa classe A B ou C
43 Activation des Devices LoRa et seacutecuriteacute En LoRaWAN les trois eacuteleacutements indispensables pour la communication sont le DevAddr pour
lrsquoindentification du Device ainsi que deux cleacutes le NwkSKey pour lrsquoauthentification et lrsquoAppSKey
pour le chiffrement Deux meacutethodes sont possibles pour fournir ces informations agrave la fois au Device
LoRa et au serveur
Activation By Personalization APB
Over The Air Activation
431 ABP Activation By Personalization Crsquoest la plus simple des meacutethodes Crsquoest donc peut ecirctre celle que nous avons tendance agrave utiliser lors
drsquoun test de prototype et drsquoune mise en place de communication LoRaWAN
Le Device LoRa possegravede deacutejagrave le DevAddr lrsquoAppSKey et le NwkSKey
Le Network server possegravede deacutejagrave le DevAddr et le NwkSKey
Lrsquoapplication serveur possegravede deacutejagrave le DevAddr et le AppSKey
En ABP toutes les informations neacutecessaires agrave la communication sont deacutejagrave connues par le
Device LoRa et par le Serveur
| 30
432 OTAA Over The Air Activation Crsquoest la meacutethode qursquoil faut privileacutegier car crsquoest celle qui est la plus seacutecuriseacutee Le Device LoRa doit
connaitre le DevEUI lrsquoAppEUI et lrsquoAppkey Le Network Server doit lui connaitre la mecircme Appkey
Tous les eacuteleacutements noteacutes EUI (Extended Unique Identifier) sont toujours sur une taille de
64 bits
Gracircce agrave ces informations de deacutepart et une neacutegociation avec le Network Server (Join Request) le
Device LoRa et le serveur vont geacuteneacuterer les informations essentielles DevAddr NwkSKey et
AppSKey
Figure 28 Obtention du DevAddr NwkSKey et AppSKey en OTAA
DevEUI Unique Identifier pour le device LoRa (Equivalent agrave une MAC sur Ethernet)
Certains Device LoRa ont deacutejagrave un DevEUI fourni en usine
AppEUI Unique Identifier pour lrsquoapplication server
DevEUI
AppEUI
AppKey
Join
Request
DevAddr
NwkSKey
AppSKey
Network Server
Application Server
Devices 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 2
NwkSkey 2
AppSKey 2
Devices 2
DevAddr 2
NwkSkey 2
AppSKey 2
Paramegravetres stockeacutes sur le serveur
Paramegravetres programmeacutes
dans le composant
Figure 27 Parameacutetrage de DevAddr NwkSKey et AppSKey
| 31
AppKey AES 128 cleacute utiliseacutee pour geacuteneacuterer le MIC (Message Code Integrity) lors de la Join
Resquest Il est partageacute avec le Network server
NwkSKey Utiliseacute pour lrsquoauthentification avec le Network Server
AppSKey Utiliseacute pour le chiffrement des donneacutees
433 Seacutecuriteacute Les cleacutes AES 128 bits permettent le chiffrement des informations transmises en LoRaWAN Malgreacute
ce chiffrement une attaque connue en Wireless est celle du REPLAY Crsquoest-agrave-dire que le Hacker
enregistre des trames chiffreacutees circulant sur le reacuteseau LoRa pour les reacuteeacutemettre plus tard Mecircme si
le Hacker ne comprend pas le contenu (les trames sont chiffreacutees) les donneacutees qui sont transporteacutees
sont elles bien comprises par lrsquoApplication Server Des actions peuvent donc ecirctre reacutealiseacutees
simplement par mimeacutetisme
Pour eacuteviter cela la trame LoRaWAN integravegre un champ variable appeleacute laquo Frame Counter raquo Il srsquoagit
drsquoun nombre numeacuterotant la trame sur 16 ou 32 bits LrsquoApplication Server acceptera une trame
uniquement si le laquo Frame Counter raquo reccedilu est supeacuterieur au laquoFrame Counter raquo preacuteceacutedemment Donc
si le Hacker retransmet la trame telle qursquoelle le laquo Frame Counter raquo sera eacutequivalent donc la trame
sera refuseacutee Et comme la trame est chiffreacutee le Hacker nrsquoa pas moyen de savoir comment modifier
un champ de cette trame
Cette seacutecuriteacute impleacutementeacutee par les laquo Frame Counter raquo est inteacuteressante pour srsquoaffranchir drsquoune
attaque par REPLAY mais dans nos tests cela peut poser problegraveme En effet agrave chaque fois que nous
redeacutemarrons le microcontrocircleur notre laquo Frame Counter raquo revient agrave zeacutero alors que celui de
lrsquoApplication Server continue de srsquoincreacutementer Cela peut ecirctre reacutesolue par diffeacuterentes maniegraveres
1 Deacutesactivation du laquo Frame Counter Check raquo Dans certain Application Server cette option
peut ecirctre proposeacutee Bien sucircr il faudra garder en tecircte la faille de seacutecuriteacute que cela engendre
Network Server
Application Server
Devices LoRa
NwkSkey
AppSKey
NwkSkey
AppSKey Hacker
(1) (2)
(1) Ecoute
(2) Reacuteeacutemission
Figure 29 Attaque par REPLAY
| 32
Figure 30 Deacutesactivation du Frame Counter Check dans TTN
2 Utiliser lrsquoauthentification par OTAA au lieu de ABP En effet agrave chaque ouverture de session
en OTAA le laquo Frame Counter raquo est reacuteinitialiseacute coteacute serveur
3 Conserver la valeur du laquo Frame Counter raquo dans une meacutemoire non volatile et reacutecupeacuterer sa
valeur au deacutemarrage du Device LoRa
44 La Trame LoRa LoRaWAN
441 Les couches du protocole LoRaWAN
Lorsque nous avons fait une communication en Point agrave Point nous avons simplement utiliseacute la
couche physique de la modulation LoRa Lorsque nous souhaitons utiliser le protocole LoRaWAN
des couches protocolaires suppleacutementaires se rajoutent
Figure 31 Les couches protocolaires du LoRaWAN
Chaque couche rajoute un service Lors de lrsquoenvoi de la trame les donneacutees utilisateurs sont donc
encapsuleacutees dans chaque couche infeacuterieure jusqursquoagrave la transmission Le deacutetail de lrsquoensemble de la
trame LoRaWAN par couche est deacutecrit sur la figure Figure 32
LoRa Modulation
LoRa Mac
Application
Couche Physique
Couche Mac
Couche Application
| 33
442 Couche Application La couche Application accueille les donneacutees de lrsquoutilisateur Avant de les encapsuler elles sont
chiffreacutees avec lrsquoAppSKey afin de seacutecuriser la transaction
Un ensemble de champs nommeacute Frame Header permet de speacutecifier le DevAddr le Frame Control
le Frame Counter et le Frame Option
Le Frame Port deacutepend du type drsquoapplication et sera choisi par lrsquoutilisateur
Le Frame Payload sont les donneacutees chiffreacutees agrave transmettre Le nombre drsquooctets maximum pouvant
ecirctre transmis (N octets) est donneacute dans le tableau suivant
PHY Payload
P octets Couche
Physique
Couche
Mac
Couche
Application
CRC
2 octets Header + Header CRC
20 bits Preamble
MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Figure 32 Trame LORAWAN complegravete par couche protocolaire
Couche
Application Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Frame Header
Figure 33 Trame LORA couche Applicative
| 34
Data Rate Spreading Factor Bandwidth Max Frame Payload (Nombre N) DR 0 SF12 125 KHz 51 octets
DR 1 SF11 125 KHz 51 octets
DR 2 SF10 125 KHz 51 octets
DR 3 SF9 125 KHz 115 octets
DR 4 SF8 125 KHz 222 octets
DR 5 SF7 125 KHz 222 octets
DR 6 SF7 250 KHz 222 octets
Tableau 5 Taille maximum du Frame Payload en fonction du Data Rate
443 Couche LoRa MAC Cette trame est destineacutee au Network Server Elle est authentifieacutee gracircce au champ MIC (Message
Integrity Protocol) selon la meacutethode expliqueacutee au paragraphe 416
Le protocole LoRa MAC est composeacute de
1 MAC Header Version de protocole et type de message
Type de Message Description 000 Join-Request
001 Join-Accept
010 Unconfirmed Data Up
011 Unconfirmed Data Down
100 Confirmed Data Up
101 Confirmed Data Down
110 Rejoin-request
111 Proprietary
Tableau 6 Les types de messages transmis en LoRaWAN
2 MAC Payload Contient tout le protocole applicatif
3 MIC Message Integrity Code pour lrsquoauthentification de la trame
444 Couche physique Modulation LoRa
Le choix du moment drsquoeacutemission des Devices LoRa se fait de faccedilon simple Lorsqursquoun eacutequipement
doit eacutemettre il le fait sans controcircle et ne cherche pas agrave savoir si le canal est libre Si le paquet a eacuteteacute
perdu il le retransmettra simplement au bout drsquoun temps aleacuteatoire La couche physique est
repreacutesenteacutee par lrsquoeacutemission de la trame suivante
Couche
Mac MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Figure 34 Trame LORA couche LORA MAC
| 35
Le Preacuteambule est repreacutesenteacute par 8 symboles + 425 Le temps du Preacuteambule est donc de 1225
Tsymbole
Len-tecircte (Header optionnel) est seulement preacutesent dans le mode de transmission par deacutefaut
(explicite) il est transmis avec un Coding Rate de 48 Il indique la taille des donneacutees le Coding Rate
pour le reste de la trame et il preacutecise eacutegalement si un CRC sera preacutesent en fin de trame
Le PHY Payload contient toutes les informations de la Couche LoRa MAC
Le CRC sert agrave la deacutetection drsquoerreur de la trame LoRa
445 Canaux et bandes de freacutequences et Data Rate (DR) Le LoRa utilise des bandes de freacutequences diffeacuterentes suivant les reacutegions du monde En Europe la
bande utiliseacutee est celle des 868 Mhz [ De 863 Mhz agrave 870 Mhz ] Le LoRaWAN deacutefinie les 8 canaux agrave
utiliser pour communiquer avec une Gateway suivant le tableau suivant
Canaux Spreading Factor Bandwidth 8681 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz SF7 250 kHz
8685 Mhz De SF7 agrave SF12 125 kHz
8671 Mhz De SF7 agrave SF12 125 kHz
8673 Mhz De SF7 agrave SF12 125 kHz
8675 Mhz De SF7 agrave SF12 125 kHz
8677 Mhz De SF7 agrave SF12 125 kHz
8679 Mhz De SF7 agrave SF12 125 kHz
Tableau 7 Canaux SF et Bandwidth de notre Gateway LoRaWAN
Une Gateway LoRa eacutecoute donc sur 8 canaux simultaneacutement avec les 6 Spreading Factor
diffeacuterents soit 48 combinaisons possibles
Comme nous lrsquoavons vu le Spreading Factor a des conseacutequences sur le deacutebit de la transmission Ces
deacutebits sont noteacutes DR (Data Rate) et sont normaliseacutes de DR0 agrave DR6
PHY Payload
P octets Couche
Physique CRC
2 octets Header + Header CRC
( Optionnel ) 20 bits Preamble
Figure 35 Trame LORA couche Physique
| 36
Data Rate Spreading Factor Bandwidth DR 0 SF12 125 KHz
DR 1 SF11 125 KHz
DR 2 SF10 125 KHz
DR 3 SF9 125 KHz
DR 4 SF8 125 KHz
DR 5 SF7 125 KHz
DR 6 SF7 250 KHz
Tableau 8 Deacutenomination DR en fonction du SF et de la Bande Passante
446 Trame reccedilue et transmise par la Gateway LoRaWAN La Gateway reccediloit drsquoun cocircteacute un message radio moduleacute en LoRa et transmet de lrsquoautre cocircteacute une trame
IP agrave destination du Network Server
Coteacute interface Radio La Gateway reacuteceptionne une trame LoRaWAN et extrait le PHY Payload Celui-
ci est codeacute au format ASCII en base 64 (voir le paragraphe 541) La Gateway extrait aussi toutes les
informations utiles sur les caracteacuteristiques de la reacuteception qui a eu lieu SF Bandwidth RSSI Time
On Airhellipetchellip
Coteacute interface reacuteseau IP La Gateway transmet lrsquoensemble de ces informations dans un paquet IP
(UDP) au Network Server Les donneacutees transmises sont du texte en format JSON (voir paragraphe
447) La Gateway a donc bien un rocircle de passerelle entre le protocole LoRa drsquoun cocircteacute et un reacuteseau
IP de lrsquoautre
Internet
UDP IP
Device LoRa
Gateway
Network Server Modulation
LoRa
Passerelle LoRa Internet
Transmission Radio Internet
Figure 36 Rocircle de la Gateway LoRa
| 37
447 Le format JSON Le format JSON est un format texte composeacute drsquoune succession de couple nomvaleur Dans
lrsquoexemple de la figure preacuteceacutedente gw_id est un nom et eui-b827ebfffeae26f5 est la valeur
associeacutee Dans cette exemple la valeur est un string Les objets sont deacutelimiteacutes par un des accolades
et
Une valeur peut ecirctre
Un string exemple coding_rate 45
Un nombre exemple spreading_factor 12
Un objet exemple lora spreading_factor 12 air_time 2465792000
Un Boolean
Ethernet
Gateway
Modulation
LORA
Reacutecupeacuteration du PHY PAYLOAD en base 64
Reacutecupeacuteration des caracteacuteristiques de la transmission Canal SF CR hellip
IP (IP dest routereuthethingsnetwork)
UDP (Port dest 1700 Port source 1700)
Donneacutees applicatives (format JSON)
gw_id eui-b827ebfffeae26f5
payload QNAPvA6Ax3ECqHk4C8hfzuA==
lora
spreading_factor 12
bandwidth 125
air_time 2465792000
coding_rate 45
timestamp 2019-01-20T133746017Z
rssi -105
snr -162
dev_addr 0EBC0FD0
frequency 867100000
Internet Transmission Radio LORA
Figure 37 Passerelle (Gateway) LORAWAN
| 38
5 Mise en œuvre drsquoun reacuteseau LoRaWAN
51 Les diffeacuterents types de reacuteseaux Les reacuteseaux LoRaWAN peuvent ecirctre utiliseacute suivant deux meacutethodes
En utilisant les reacuteseaux LoRaWAN opeacutereacutes proposeacutes par les opeacuterateurs de teacuteleacutecoms
En utilisant votre propre reacuteseau LoRaWAN priveacute
511 Les reacuteseaux LoRaWAN opeacutereacutes Ce sont des reacuteseaux LoRaWAN proposeacutes par les opeacuterateurs Par exemple Objenious (filiale de
Bouyges) ou encore Orange Dans le cas de lrsquoutilisation des reacuteseaux opeacutereacutes lrsquoutilisateur a juste
besoin de srsquooccuper des Devices LoRa Les Gateways le Network Server et lrsquoApplication Server sont
geacutereacutes par lrsquoopeacuterateur
512 Les reacuteseaux LoRaWAN priveacutes Chacun est libre de reacutealiser son propre reacuteseau priveacute en impleacutementant sa propre Gateway pour
communiquer avec ses Devices LoRa Lrsquoimpleacutementation du Network Server et de lrsquoApplication Server
peuvent alors ecirctre envisageacutes de diffeacuterentes faccedilons
Network Server et Application serveur priveacutees Crsquoest le deacuteveloppeur qui les mets en place Dans
certaines Gateways une impleacutementation de ces deux serveurs est deacutejagrave proposeacutee Sinon il est
possible de la mettre en place Il existe des serveurs (Network et Application) open source crsquoest le
cas par exemple de LoRa Serveur [ wwwloraserverio ]
Une autre alternantive est httpsgithubcomgotthardplorawan-server
LoRaServer et lorawan-server sont deux applications Open Source
Network Server et Application Server en ligne Un certain nombre de Network Server et
drsquoApplication Server sont proposeacutes Ce sont des services payants ou avec des contreparties
Loriot [ wwwloriotio ]
ResIoT [ wwwresiotio ]
The Things Network [ wwwthethingsnetworkorg ] Crsquoest la solution que nous utiliserons
513 Les zones de couvertures
Les zones de couvertures des reacuteseaux opeacutereacutes sont mise agrave jour par les opeacuterateurs celle drsquoobjenious
est par exemple disponible ici httpsobjeniouscomreseau
Pour connaitre la zone de couverture de notre Gateway utiliseacutee avec TTN nous pouvons utiliser
lrsquoapplication TTN Mapper httpsttnmapperorg Lrsquoideacutee est de promener son Device LoRa associeacute
agrave un GPS dans la zone de couverture des Gateway qui nous entourent A chaque trame reccedilue par le
| 39
Serveur on note les coordonneacutees GPS du Device LoRa ainsi que la Gateway qui a transmis le
message Toutes ces informations sont alors retranscrites sur une carte
52 The Things Network (TTN)
521 Preacutesentation de TTN
Pour la suite nous utiliserons le Network Server et lrsquoApplication Server fourni par TTN
[wwwthethingsnetworkorg]
TTN est gratuit et Open Source En revanche le fait drsquoutiliser TTN impose agrave ceux qui enregistrent
des Gateways de les mettre agrave disposition agrave tous les autres utilisateurs de TTN Lrsquoobjectif est de
reacutealiser un reacuteseau global ouvert
522 Configuration de la Gateway A lrsquouniversiteacute nous avons deux Gateways LoRa (Marque EBDS) Elles sont toutes les deux situeacutees sur
le Campus de Technolac Une Gateway est agrave lrsquointeacuterieur du bacirctiment ISERAN et sert essentiellement
pour les Travaux Pratiques et formations Lrsquoautre est sur le toit du bacirctiment Chablais et est mise agrave
disposition du public via le service de TTN
Les deux Gateway eacutecoutent sur tous les canaux et sur tous les Spreading Factor SF7 gt SF12
Lrsquo IP de la Gateway LoRa agrave lrsquouniversiteacute (bacirctiment ISERAN) est 192168140196
Serveur DNS 1934812032 19348129137
Network Server (TTN) 137616868 routereuthethingsnetwork
Port Upstream 1700 Port Downstream 1700
523 Enregistrement des Gateways Appplication et Devices La configuration de TTN se fait en ligne La premiegravere opeacuteration agrave reacutealiser lorsqursquoune nouvelle
Gateway est deacuteployeacutee crsquoest de lrsquoenregistrer dans TTN
Enregistrement drsquoune Gateway LoRa TTN gt Console gt Gateway gt register gateway
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Figure 38 Scheacutema de notre application
| 40
Figure 39 Enregistrement dune Gateway LoRa sur TTN
Enregistrement drsquoune application TTN gt Console gt Application gt add application
Figure 40 Enregistrement dune application sur TTN
Enregistrement des Devices LoRa dans lrsquoapplication Nom de lrsquoapplication gt register device
Figure 41 Enregistrement des Devices LoRa dans une application
524 Configuration des Devices LoRa Lorsque nous avons enregistreacute des Devices LoRa dans TTN nous devons choisir entre les deux modes
drsquoauthentification Dans un premier temps nous utiliserons le mode le plus simple qui est ABP Nous
geacuteneacuterons dans TTN les DevAddr NetwkSKey et AppSKey
| 41
Figure 42 Configuration des Devices LoRa en ABP dans TTN
53 Mise en application Nous avons dans notre application 10 Devices LoRa drsquoenregistreacutes aduino0 agrave arduino9 Ils sont tous
configureacutes en ABP Les configurations des 10 Devices (DevAddr NetwkSKey et AppSKey) sont noteacutes
en commentaire dans le code de vous allez reacutecupeacuterer
Reacutecupeacuterer le code Arduino laquo RN2483-Arduino-LORAWANino raquo dans Moodle
Modifier votre configuration (DevAddr NetwkSKey et AppSKey) en fonction de votre
numeacutero de binocircme
Veacuterifier que votre Device LoRa arrive bien agrave transmettre des informations (Uplink) vers la
Gateway puis vers le Network Serveur de TTN (The Things Network)
54 Analyse des trames eacutechangeacutees
541 Utilisation de la base 64 Notre Gateway nous preacutesente le Payload PHY en base64 Lrsquoexplication de la meacutethode de
repreacutesentation en base 64 est fourni au travers drsquoun exemple Le code hexadeacutecimal 0x4869
repreacutesente nos donneacutees binaires que nous souhaitons transmettre en base 64
1 On eacutecrit les donneacutees agrave transmettre en binaire
2 On regroupe les eacuteleacutements binaires par des blocs de 6 bits Le nombre de bloc de 6 bits doit
ecirctre un multiple de 4 (minimum 4 blocs) Srsquoil manque des bits pour constituer un groupe de
6 bits on rajoute des zeacuteros
0x4869 = 0100 1000 0110 1001
| 42
3 Srsquoil manque des blocs pour faire un minimum de 4 blocs des caractegraveres speacuteciaux seront
ajouteacutes
4 Chaque groupe de 6 bits est traduit par le tableau suivant (Source Wikipeacutedia)
Figure 43 Codage en base 64
5 Si un bloc de 6 bits manque (ils doivent ecirctre un multiple de 4) on rajoute un ou plusieurs
compleacutements (caractegravere laquo = raquo )
Reacutesultat Le codage de 0x4869 en base 64 est laquo SGk= raquo
010010 000110 100100
On ajoute 00 pour avoir
6 bits dans le groupe
Bloc de 6 bits
010010 000110 100100
S G k
010010 000110 100100
S G k =
1er Bloc
2egraveme Bloc
3egraveme Bloc
4egraveme Bloc
| 43
542 Inteacuterecirct et inconveacutenient de la base 64 Lrsquoutilisation de la base 64 est un choix qui a eacuteteacute fait pour le protocole LoRa LoRaWAN afin de rendre
les donneacutees binaires lisibles Le problegraveme du code ASCII crsquoest qursquoil est composeacute drsquoun certain nombre
de caractegraveres non imprimables (EOF CR LFhellip) Pour eacuteviter ces soucis la base 64 ne comporte que
64 caractegraveres imprimables (voir tableau ci-dessus)
La restriction agrave 64 caractegraveres a cependant un inconveacutenient crsquoest que nous ne pouvons coder que 6
bits (26=64) au lieu de 8 La base 64 est donc moins efficace drsquoune faccedilon geacuteneacuterale
Nous cherchons agrave coder le code ASCII laquo AA raquo en base 64 Retrouver la deacutemarche en
montrant que le reacutesultat en base 64 est laquo QUE= raquo
543 Uplink Du Device LoRa au Network Server Le Network Server de TTN reccediloit des trames IP en provenance de la Gateway Comme nous lrsquoavons
vu preacuteceacutedemment un certain nombre drsquoinformations peuvent ecirctre retrouveacutees avec cette trame
(DevAddr SF Bandwidth etchellip) mais les donneacutees Applicatives sont bien sucircr chiffreacutees (avec
lrsquoAppkSKey) A ce niveau de reacuteception (sans connaitre lrsquoAppSKey) il nrsquoest donc pas possible de
comprendre la totaliteacute du message reccedilu
Imaginons que la trame IP reccedilue 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 45
timestamp 2019-03-05T140042448Z
rssi -82
snr 9
dev_addr 26011AD3
frequency 867300000
Le Network Server affiche donc les informations de la faccedilon suivante
Figure 44 Trame reacutecupeacutereacutee sur le laquo Network Server raquo de TTN
Nous retrouvons bien les valeurs fournies par la Gateway
timestamp ( agrave 1 heure pregraves en fonction du fuseau horaire)
| 44
frequency 8673 Mhz
modulation Lora
Coding Rate 45
data Rate SF 7 125 kHz (DR5)
air time 463 ms
Drsquoautres information proviennent de lrsquoanalyse du Payload Le Payload inscrit ici est le PHY Payload
Il y a donc une partie chiffreacutee (Frame Payload) mais les entecirctes sont en claires (voir paragraphe
441) Ce PHY Payload est laquo QNMaASYABwAP1obuUHQ= raquo Lorsque celui-ci est exprimeacute en
hexadeacutecimal au lieu de la base 64 il vaut laquo 40D31A01260007000FD686EE5074 raquo comme le montre
le Network Server de TTN
Figure 45 PHY Payload preacutesenteacute dans notre Network Server
Sa taille est bien de 14 octets (en hexadeacutecimal) comme preacuteciseacute sur la Figure 44
Nous reprenons le format de la trame LoRaWAN vu agrave la Figure 32 Nous pouvons alors retrouver
tous les champs de toute la trame
PHYPayload = 40D31A01260007000FD686EE5074
PHYPayload = MAC Header[1 octet] | MACPayload[] | MIC[4 octets]
MAC Header = 40 (Unconfirmed data up)
MACPayload = D31A01260007000FD6
Message Integrity Code = 86EE5074
MACPayload = Frame Header | Frame Port | FramePayload )
Frame Header = D31A0126000700
FPort = 0F
FramePayload = D6
Frame Header = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[015]
DevAddr = 26011AD3 (Big Endian)
FCtrl (Frame Control) = 00 (No ACK No ADR)
FCnt (Frame Counter) = 0007 (Big Endian)
FOpts (Frame Option) =
Vous pouvez veacuterifier lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN
(LoRaWAN packet decoder) httpsbitly2szdXtv
| 45
Figure 46 LoRaWAN packet decoder
544 Uplink Du Network Server agrave lrsquoApplication Server
Nous reprenons lrsquoexemple de la trame ci-dessus (Figure 45) Pour information les cleacutes NwkSKey et
AppSKey suivantes ont eacuteteacute utiliseacutee
NwkSKey E3D90AFBC36AD479552EFEA2CDA937B9
AppSKey F0BC25E9E554B9646F208E1A8E3C7B24
Le Network Server a deacutecodeacute lrsquoensemble de la trame Si le MIC est correct (authentification de la
trame par le NwkSKey) alors le Network Server va passer le contenu du message chiffreacute (Frame
Payload) agrave lrsquoApplication Server Dans notre cas le Frame Payload est (drsquoapregraves le deacutecodage effectueacute
au chapitre preacuteceacutedent)
FramePayload = D6
D6 est le contenu chiffreacute lorsqursquoil est deacutechiffreacute avec lrsquoAppSkey on trouve 01 Vous pouvez veacuterifier
lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN httpsbitly2szdXtv
A noter que lrsquoApplication Server recevra les donneacutees chiffreacutees seulement si le Device LoRa a bien
eacuteteacute enregistreacute On peut aussi veacuterifier ci-dessous que lrsquoApplication Serveur de TTN nous retourne bien
un payload (Frame Payload) de 01
Figure 47 Trame reacutecupeacutereacutee sur lrsquoApplication Server de TTN
time 2019-03-05T140042379279991Z
frequency 8673
modulation LORA
data_rate SF7BW125
coding_rate 45
gateways [
gtw_id eui-b827ebfffeae26f6
timestamp 2447508531
time
channel 4
rssi -82
snr 9
latitude 4563647
longitude 58721523
| 46
location_source registry
]
545 Simulation drsquoUplink dans lrsquoApplication Server
Dans beaucoup de situations nous souhaitons valider le fonctionnement de lrsquoApplication Server de
TTN ouet de notre propre Application Il est donc tregraves utile de pouvoir simuler lrsquoenvoi drsquoune trame
LoRa sur lrsquoApplication Server sans que celle-ci soit reacuteellement eacutemise par un Device LoRa Pour cela
un outil existe dans les Settings de chaque Device enregistreacute dans TTN Nous avons juste besoin de
speacutecifier le Frame Payload en clair en hexadeacutecimal et le numeacutero de Port
Figure 48 Simulation drsquoune trame envoyeacutee par un Device LoRa
546 Downlink De lrsquoApplication Server au Device LoRa La communication LoRa est bidirectionnelle Des donneacutees peuvent ecirctre transmis au Device LoRa
depuis lrsquoApplication Server Depuis TTN un outil existe dans les Settings de chaque Device
enregistreacute Lrsquointerface est repreacutesenteacutee ci-dessous
Figure 49 Transmission de donneacutees de lrsquo laquo Application Server raquo jusqursquoau Device LoRa
Replace scheduling Mode Par deacutefaut le Frame Payload transmis remplacera le Frame
Payload en attente (si il existe) Dans ce mode un seul Frame Payload est planifieacute
First scheduling Mode Le Frame Payload est mis en file drsquoattente en premiegravere position
Last scheduling Mode Le Payload est mis en file drsquoattente en derniegravere position
Une demande de confirmation peut ecirctre demandeacutee au Device LoRa pour qursquoil preacutecise srsquoil a bien reccedilu
les donneacutees Lrsquooption laquo confirmed raquo permet donc de speacutecifier le type de trame dans le MAC Header
(voir paragraphe 443) laquo Confirmed Data Down raquo ou laquo Unconfirmed Data Down raquo dans notre cas
| 47
6 La reacutecupeacuteration des donneacutees sur notre propre Application
Nous utiliserons agrave nouveau le Network Server et Application Server de The Things Network Jusqursquoici
nous nous sommes contenteacute de veacuterifier que les donneacutees de lrsquoutilisateur (Frame Payload) soient bien
arriveacutees agrave destination dans lrsquoApplication Server Il faut maintenant les reacutecupeacuterer avec notre propre
Application qui aura pour rocircle
De stocker et traiter les donneacutees
De les mettre agrave disposition de lrsquoutilisateur (Serveur Web par exemple)
Drsquoenvoyer des commandes de lrsquoutilisateur aux Devices LoRa si besoin (Flux Downlink)
Nous allons voir deux meacutethodes pour communiquer entre notre application et TTN
Le protocole HTTP POST
Le protocole MQTT
61 Reacutecupeacuteration des donneacutees en HTTP POST dans lrsquoApplication
611 Preacutesentation du protocole HTTP
Dans le monde de lrsquointernet le protocole HTTP est tregraves utiliseacute pour le dialogue entre un client et un
serveur web Classiquement le client (un navigateur web par exemple) fait une requecircte HTTP GET
et le serveur lui retourne le contenu de la page web demandeacutee
Dans notre cas la probleacutematique est diffeacuterente car le client doit modifier le contenu du serveur
avec les donneacutees envoyeacutees par le Device LORA La requecircte srsquoappelle HTTP POST Son nom indique
que le client va poster (et on pas reacutecupeacuterer) des donneacutees
Lrsquoutilisateur qui souhaite reacuteceptionner des donneacutees sur son serveur doit donc concevoir un serveur
HTTP capable de traiter des requecirctes HTTP POST [ requecircte noteacutee (1) sur la Figure 51 ] fournies par
TTN Dans cette configuration TTN jouera le rocircle de client et notre application le rocircle de serveur
Devices
LORA Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
HTTP POST
MQTT Internet
Figure 50 Structure globale drsquoun reacuteseau LORAWAN
| 48
Figure 51 Communication bidirectionnelle entre TTN et notre Application
A lrsquoinverse lrsquoutilisateur qui souhaite transmettre des donneacutees agrave destination du Device LoRa
(Downlink) doit ecirctre capable de fournir une requecircte HTTP POST [ requecircte noteacutee (2) sur la Figure 51
] vers TTN Dans cette configuration TTN jouera le rocircle de Serveur et notre application le rocircle de
client
612 Fonctionnement drsquoun client et drsquoun serveur HTTP POST Afin de bien comprendre le fonctionnement des requecirctes HTTP POST nous allons proceacuteder par
eacutetape Le premier test que nous effectuerons sera decorreacuteleacute de TTN Le principe est le suivant
Utilisation drsquoun serveur HTTP disponible sur le web geacuterant les requecirctes HTTP POST [
httpsrbasketsin ] ou [ httpsbeeceptorcom ] par exemple
Utilisation drsquoun client HTTP eacutemettant des requecirctes HTTP POST commande curl sous linux
ou logiciel Postman [ wwwgetpostmancom ] sous windows par exemple
Ce test nous permet de valider le fonctionnement drsquoun serveur HTTP POST et drsquoun client HTTP POST
Une fois que nous serons sucircr de leur fonctionnement nous les utiliserons avec TTN
The Things Network
Application
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 49
Figure 52 Validation dun server HTTP POST et drsquoun client HTTP POST
613 Test du serveur HTTP POST Nous utiliserons un serveur web proposeacute par httpsrbasketsin
Aller sur le site httpsrbasketsin et creacuteer un nouveau laquo Basket raquo Zone ougrave vous pourrez
visualiser les requecirctes qui ont eacuteteacute eacutemises vers votre serveur
A partir de maintenant toutes les requecirctes dirigeacutees vers lrsquoadresse creacuteeacute seront traiteacutees et
srsquoafficheront Dans le menu de configuration il est aussi possible de deacutefinir le contenu de la reacuteponse
qui sera fournie
Deacutefinir un format de reacuteponse pour les requecirctes HTTP POST avec un body personnaliseacute
614 Test du client HTTP POST On peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande (la commande cURL
srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN sous Windows
Commande cURL curl ndashX POST ndashd lsquorsquodonneacutees agrave envoyerrsquorsquo DuServeurHTTP
Logiciel Postman New gt Request gt Creacuteer une requecircte HTTP POST gt Send
Veacuterifier que les requecirctes HTTP POST sont bien reacutecupeacutereacutees sur votre serveur creacutee preacuteceacutedemment
615 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST
Maintenant que nous avons un serveur HTTP (POST) fonctionnel nous allons configurer TTN pour
jouer le rocircle du client et pour qursquoil envoie des requecirctes HTTP POST vers notre Serveur degraves qursquoune
donneacutee drsquoun Device LoRa est disponible Nous geacuterons donc ici le flux Uplink
Requecircte
HTTP POST
Reacuteponse
(contenu parameacutetrable)
Client HTTP (POST)
Server HTTP (POST) [ httpsrbasketsin ]
| 50
Figure 53 Reacutecupeacuteration des donneacutees sur notre Application
Dans TTN nous inteacutegrons un bloc appeleacute laquo HTTP Integration raquo permettant de jouer le rocircle de client
crsquoest-agrave-dire drsquoenvoyer des requecirctes HTTP POST agrave destination de notre nouveau Serveur HTTP
Lrsquointeacutegration se faire agrave partir de TTN gt Console gt Application gt Nom_de_votre_application gt
Integration
Figure 54 Ajout dun client HTTP POST dans TTN
Pour valider le fonctionnement de notre architecture nous pouvons soit
Envoyer une trame depuis un Device LoRa vers TTN
Simuler lrsquoenvoi drsquoune trame drsquoun Device LoRa vers TTN (gracircce agrave lrsquooutil proposeacute par TTN vu
paragraphe 545)
Dans les deux cas voici un exemple de requecircte POST reccedilue sur notre serveur HTTP
app_id test_app_lorawan_sylvainmontagny
dev_id stm32lorawan_1
hardware_serial 0056AF49877
port 1
counter 0
payload_raw qg==
metadata
Requecircte
HTTP POST
Server HTTP (POST) [ httpsrbasketsin ]
The Things Network (Client)
La requecircte contient le Frame Payload deacutechiffreacutee
agrave transmettre agrave lrsquoApplication
| 51
time 2019-01-24T15243703499298Z
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Comme nous pouvons le voir le contenu fourni agrave notre serveur est formateacute en JSON (voir
paragraphe 0) Voici quelques compleacutements drsquoinformation
payload_raw Frame Payload deacutechiffreacute crsquoest donc les donneacutees en clairs dans la base 64
downlink_url URL du serveur HTTP POST qui serviront agrave transmettre des donneacutees au Device
LoRa (flux Downlink)
611 Envoyer des donneacutees depuis notre Application avec HTTP POST
Lorsque nous avons ajouteacute le bloc laquo HTTP Integration raquo au paragraphe preacuteceacutedent nous avons aussi
implicitement activeacute la fonctionnaliteacute que TTN soit precirct agrave recevoir et agrave traiter les requecirctes HTTP
POST La seule information qursquoil nous manque est lrsquoadresse du server HTTP vers lequel il faut eacutemettre
les requecirctes Si on observe la trame reccedilue preacuteceacutedemment en provenance de TTN on srsquoaperccediloit que
dans la trame JSON reccedilu une URL (downlink_url) est speacutecifieacutee
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Crsquoest cette URL que nous devrons utiliser Nous allons nous placer dans la configuration suivante
Figure 55 Envoi de donneacutees agrave partir de notre Application
Comme preacuteceacutedemment on peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande
(la commande cURL srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN
Commande cURL curl ndashX POST ndashdata lsquo dev_id Identidiant_De_Votre_Device
payload_raw AQE= rsquo DuServeurHTTP
Logiciel Postman New gt Request gt HTTP POST puis Body gt Raw gt JSON
Requecircte HTTP POST vers serveur TTN laquo downlink_url raquo httpsintegrationsthethingsnetworUaeb8ypKieQ
Contenu de la requecircte
dev_id Identidiant_De_Votre_Device
payload_raw aGVsbG8=
The Things Network (Serveur)
POSTMAN (Client HTTP POST)
| 52
dev_id YourDeviceID
payload_raw aGVsbG8=
Vous devez envoyer le texte (payload_raw) en base 64 Dans lrsquoexemple ci-dessus laquo aGVsbG8= raquo
correspond agrave la chaine de caractegravere laquo hello raquo Vous pouvez utiliser les nombreux encodeurdecodeur
en ligne pour vous aider Le texte doit srsquoafficher sur votre moniteur seacuterie Arduino dans le cadre de
notre deacutemonstrateur sur Arduino
62 Reacutecupeacuteration des donneacutees avec MQTT dans lrsquoApplication
621 Preacutesentation du protocole MQTT
MQTT est un protocole leacuteger qui permet de srsquoabonner agrave des flux de donneacutees Plutocirct que
lrsquoarchitecture Client Serveur classique qui fonctionne avec des Requecirctes Reacuteponses MQTT est
baseacute sur un modegravele Publisher Subscriber La diffeacuterence est importante car cela eacutevite davoir agrave
demander (Requecircte) des donneacutees dont on na aucune ideacutee du moment ougrave elles vont arriver Une
donneacutee sera donc directement transmise au Subscriber degraves lors que celle-ci a eacuteteacute reccedilue dans le
Broker (serveur central)
Figure 56 Modegravele Publisher Subscriber du protocole MQTT
Pour recevoir les donneacutees appartenant agrave un Topic un Subscriber doit souscrire (comme son nom
lindique) au preacutealable sur ce Topic
MQTT est un protocole qui repose sur TCP Lencapsulation des trames sur le reacuteseau est donc la
suivante
Broker
Client
Publisher 1
Client
Publisher 2
Client
Subscriber
Topic
Tempeacuterature
Topic
Humiditeacute
| 53
Figure 57 Protocoles utiliseacutes pour la communication avec MQTT
On peut le veacuterifier par une capture de trame sur Wireshark
Figure 58 Capture dune trame MQTT avec Wireshark
On peut noter que le port TCP utiliseacute pour le protocole MQTT (non chiffreacute) est le 1883
Les Publishers et les Subscribers nrsquoont pas besoin de se connaitre
Les Publishers et les Subscribers ne sont pas obligeacute de srsquoexeacutecuter en mecircme temps
622 Connexion au Broker MQTT Nous nous inteacuteresserons essentiellement aux options de connexion qui permettront de geacuterer la
Qualiteacute de Service (QoS) Pour se connecter un client MQTT envoie deux informations importantes
au Broker
keepAlive Cest la peacuteriode la plus longue pendant laquelle le client Publisher ou Subscriber pourra
rester silencieux Au-delagrave il sera consideacutereacute comme deacuteconnecteacute
cleanSession Lorsque le Client et le Broker sont momentaneacutement deacuteconnecteacutes (au-delagrave du
keepAlive annonceacute) on peut donc se poser la question de savoir ce quil se passera lorsque le client
sera agrave nouveau connecteacute
Si la connexion eacutetait non persistante (cleanSession = True) alors les messages non transmis
sont perdus Quel que soit le niveau de QoS (Quality of Service)
Si la connexion eacutetait persistante (cleanSession = False) alors les messages non transmis
seront eacuteventuellement reacuteeacutemis en fonction du niveau de QoS Voir le chapitre 624
623 Qualiteacute de Service au cours dune mecircme connexion
A partir du moment ougrave le Client se connecte au Broker il est possible de choisir un niveau de fiabiliteacute
des transactions Le Publisher fiabilise leacutemission de ces messages vers le Broker et le Subscriber
fiabilise la reacuteception des messages en provenance du Broker Une parle ici du cas dune mecircme
connexion crsquoest-agrave-dire entre le moment ou le Client se connecte et le moment ougrave
Soit il se deacuteconnecte explicitement (Close connexion)
Soit il na rien eacutemis ni fait signe de vie pendant le temps keepAlive
TCP
MQTT
Reacuteseau
Transport
Couche Application
IP
| 54
Lors dune mecircme connexion la Qualiteacute de Service (QoS) qui est mise en œuvre deacutepend uniquement
de la valeur du QoS selon les valeurs suivantes
QoS 0 At most once (au plus une fois) Le premier niveau de qualiteacute est sans acquittement Le
Publisher envoie un message une seule fois au Broker et le Broker ne transmet ce message quune
seule fois aux Subscribers Ce meacutecanise ne garantit pas la bonne reacuteception des messages MQTT
QoS 1 At least once (au moins une fois) Le deuxiegraveme niveau de qualiteacute est avec acquittement
Le Publisher envoie un message au Broker et attends sa confirmation De la mecircme faccedilon le Broker
envoie un message agrave ces Subscriber et attends leurs confirmations Ce meacutecanisme garantit la
reacuteception des message MQTT
Cependant si les acquittements nrsquoarrivent pas en temps voulu ou srsquoils se perdent la reacuteeacutemission du
message dorigine peut engendrer une duplication du message Il peut donc ecirctre reccedilu plusieurs fois
QoS 2 Exactly once (exactement une fois) Le troisiegraveme niveau de qualiteacute est garanti une seule
fois Le Publisher envoie un message au Broker et attends sa confirmation Le Publisher donne alors
lrsquoordre de diffuser le message et attends une confirmation Ce meacutecanisme garantit que quel que
soit le nombre de tentatives de reacuteemission le message ne sera deacutelivreacute quune seule fois
La Figure 59 montre les trames eacutemises pour chaque niveau de QoS
Figure 59 Qualiteacute de Service en MQTT
La Figure 60 repreacutesentes les 3 captures de trames sur Wireshark repreacutesentant les 3 QoS (1 2 et 3)
que nous venons dexpliquer
Broker
QoS 0
Au plus une fois
Message supprimeacute apregraves envoi
PUBLISH
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Duplications possibles
PUBLISH
PUBLICH Ack
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Pas de duplication
PUBLISH
PUBLISH Receive
PUBLISH Release
PUBLISH Complete
| 55
Figure 60 Capture de trame avec QoS = 0 puis QoS = 1 puis QoS = 2
624 Qualiteacute de Service apregraves une reconnexion
La question que nous nous posons et de savoir ce que deviennent les messages publieacutes sur le Broker
lorsquun ou plusieurs Subscribers sont momentaneacutement injoignables Il est possible de conserver
les messages qui ont eacuteteacute publieacutes sur le Broker afin de les retransmettre lors de la prochaine
connexion Cette possibiliteacute de sauvegarde doit ecirctre activeacutee agrave louverture de connexion gracircce au flag
cleanSession = 0 La connexion sera alors persistante crsquoest-agrave-dire que le Broker enregistre tous les
messages quil na pas reacuteussi agrave diffuser au Subscriber
Le Tableau 9 reacutesume leffet du flag cleanSession et du QoS
Clean Session Flag Subscriber QoS Publisher QoS Comportement True ( = 1) 0 1 2 0 1 2 Messages perdus
False ( = 0 ) 0 0 1 2 Messages perdus
False (= 0 ) 0 1 2 0 Messages perdus
False (= 0 ) 1 2 1 2 Tous les messages sont retransmis
Tableau 9 Qualiteacute de Service en fonction de la valeur du QoS et du flag cleanSession
625 Les Topics du protocole MQTT Les chaicircnes deacutecrivant un sujet forment une arborescence en utilisant la barre oblique comme
caractegravere de seacuteparation La Figure 61 et le Tableau 10 donne un exemple dorganisation de Topic
Figure 61 Exemple de hieacuterarchie de Topic MQTT
Niveau 3
Niveau 2
Niveau 1 Maison
Chambre
Temperature Humidite Bruit
Salon
Temperature
| 56
Nom du Topic Deacutetail du Topic MaisonChambreTemperature La tempeacuterature de la chambre de la maison
MaisonChambreBruit Le bruit de la chambre de la maison
MaisonSalonTemperature La tempeacuterature du Salon de la maison
Tableau 10 Exemple de Topic
Un client peut sabonner (ou se deacutesabonner) agrave plusieurs branches de larborescence agrave laide de
jokers englobant plusieurs Topics Deux caractegraveres jokers existent
Le signe plus + remplace nimporte quelle chaine de caractegravere sur le niveau ougrave il est placeacute
Le diegravese remplace nimporte quelle chaine de caractegravere sur tous les niveaux suivants Il
est obligatoirement placeacute agrave la fin
Nom du Topic Deacutetail du Topic Maison+Temperature Les tempeacuteratures de toutes les piegraveces de la maison
MaisonChambre La tempeacuterature lhumiditeacute et le bruit de la chambre de la maison
Tableau 11 Exemple de Topic
626 Mise en place drsquoun Broker MQTT Afin de bien comprendre le fonctionnement du protocole de MQTT on reacutealise des tests
indeacutependamment de TTN Nous allons mettre en place
Un Broker Mosquitto httpstestmosquittoorg
Un client Publisher MQTT Box sur Windows
Un client Subscriber MQTT Box sur Windows
Figure 62 Test du protocole MQTT
MQTT Client (Subscriber)
MQTT Client (Publisher)
Publish
Subscribe
BROKER (Mosquitto)
| 57
Le Broker MQTT est commun agrave tout le monde Nous pouvons soit le reacutealiser nous-mecircme soit utiliser
un Broker MQTT public de test Nous utiliserons le Broker de test de Mosquitto disponible sur
httpstestmosquittoorg Drsquoautres sont eacuteventuellement disponibles en cas de problegraveme par
exemple httpwwwmqtt-dashboardcom
Si nous deacutecidions de le reacutealiser nous-mecircme agrave lrsquoaide drsquoune Raspberry Pi (par exemple) Lrsquoinstallation
se ferait en deux lignes de commande
apt-get install mosquito Installation
sudo systemctl start mosquittoservice Lancement du service
Il est neacutecessaire drsquoinstaller mosquitto-clients si on souhaite que le Raspberry PI joue aussi le rocircle de
client ce qui nrsquoest pas notre cas
627 Mise en place drsquoun Publisher et drsquoun Subscriber MQTT Lancer le logiciel MQTTBox
MQTTBox gt Create MQTT Client
Dans ce client les seuls champs indispensables sont
Protocol MQTT TCP
Host testmosquittoorg
Figure 63 Configuration dun Client MQTT dans MQTT Box
Tester lrsquoenvoi et la reacuteception sur les Topics de votre choix
628 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT La reacutecupeacuteration des donneacutees fait reacutefeacuterence au flux Uplink Dans ce cas
TTN joue le rocircle de client Publisher
TTN joue aussi le rocircle de Broker
Notre application joue le rocircle de Subscriber
Nous pouvons donc repreacutesenter lrsquoapplication globale par le scheacutema suivant
| 58
Figure 64 Publisher et Subscriber dans en MQTT avec TTN
La publication est repreacutesenteacutee par la trame MQTT (1)
La souscription est repreacutesenteacutee par la trame MQTT (2)
Le client Publisher eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box mais cette fois avec la configuration suivante
Protocol mqtt tcp
Host Crsquoest lrsquoIP du Broker vers lequel il faut se connecter Dans notre cas il srsquoagit de celui
de TTN dont lrsquoadresse est euthethingsnetwork
Username La connexion vers le broker MQTT est soumis agrave une authentification Username
Password Dans notre cas le Username correspond au nom de notre application crsquoest-agrave-
dire seminaire_lorawan Si vous avez choisi une autre applicationil faut bien mettre la
votre
Password Le Password est nommeacute laquo Access Key raquo par TTN Elle vous sera donneacutee par
lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application vous
trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt Overview
Figure 65 Access Keys de lapplication dans TTN
The Things Network (Application Server)
BROKER
Application
The Things Network (Network Server)
Publish (1 )
[ Flux Uplink ]
Subscribe (2 )
[ Flux Uplink ]
| 59
Figure 66 Configuration du Client dans MQTT Box
Le client MQTT eacutetant configureacute il est maintenant capable de se connecter au Broker Il reste donc agrave
deacutefinir le fait que le client sera Subscriber Les informations que recevra le Subscriber deacutependent du
Topic auquel nous souscrivons Voici les Topic disponibles sur le Broker de TTN
ltAppIDgt correspond au nom de votre Application
ltDevIDgt correspond au nom de votre Device LoRa
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink ltAppIDgtdevicesltDevIDgtup
[Donneacutees] Flux Downlink ltAppIDgtdevicesltDevIDgtdown
[Activation Events] Activation dun Device ltAppIDgtdevicesltDevIDgteventsactivations
[Management Events] Creacuteation dun Device ltAppIDgtdevicesltDevIDgteventscreate
[Management Events] Update dun Device ltAppIDgtdevicesltDevIDgteventsupdate
[Management Events] Suppression dun Device ltAppIDgtdevicesltDevIDgteventsdelete
[Downlink Events ] Message programmeacute ltAppIDgtdevicesltDevIDgteventsdownscheduled
[Downlink Events ] Message envoyeacute ltAppIDgtdevicesltDevIDgteventsdownsent
[Erreurs] Uplink erreurs ltAppIDgtdevicesltDevIDgteventsuperrors
[Erreurs] Downlink erreurs ltAppIDgtdevicesltDevIDgteventsdownerrors
[Erreurs] Activations erreurs ltAppIDgtdevicesltDevIDgteventsactivationserrors
Tableau 12 Topics enregistreacutes dans TTN
Dans un premier temps nous souscrivons au Topic +devices+up Cela signifie que nous
souscrivons agrave tous les Devices LoRa de toutes nos applications pour le flux Uplink
Figure 67 Configuration du Subscriber
Les eacuteleacutements eacutemis par le Broker seront alors afficheacutes dans MQTTBox La
| 60
Figure 68 Trame LoRaWAN reccedilu sur le Subscriber MQTT
Ces donneacutees sont eacutecrites en JSON nous pouvons les remettre en forme
applicationID3
applicationNamemyApplication
deviceNamearduino0
devEUI0056xxxxxxxxx877
txInfo
frequency868500000
dr5
adrfalse
fCnt792
fPort15
dataSGVsbG8=
Le Frame Payload deacutechiffreacute est fourni dans le champ data en base 64 La valeur fournie par
dataSGVsbG8= correspond bien agrave la chaine de caractegravere hello que nous avons eacutemise avec le
Device LoRa
629 Envoyer des donneacutees depuis notre Application avec MQTT
Lrsquoenvoi des donneacutees fait reacutefeacuterence au flux Downlink Dans ce cas
Notre application joue le rocircle de Publisher
TTN joue le rocircle de Broker
TTN joue aussi le rocircle de client Subscriber
| 61
La publication est repreacutesenteacutee par la trame MQTT (3)
La souscription est repreacutesenteacutee par la trame MQTT (4)
Le client Subscriber eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box Le rocircle de client dans MQTT Box a eacuteteacute faite au
paragraphe 628 Il nous reste simplement agrave ajouter le rocircle de Publisher La configuration est la
suivante
Topic du Subscriber seminaire_lorawandevicesarduino0down ougrave seminaire_lorawan
est agrave remplacer par le nom de votre application et arduino0 par le nom du Device LoRa vers
lequel vous souhaitez envoyeacute une donneacutee (Voir chapitre 628 pour comprendre les Topics)
Le Payload doit ecirctre au format JSON Lrsquoexemple suivant envoie laquohello raquo
payload_raw aGVsbG8=
The Things Network (Application Server)
BROKER
Application
Publish (3)
[ Flux Downlink ]
The Things Network (Network Server)
Subscribe (4)
[ Flux Downlink ]
| 62
Figure 69 Configuration du Publisher
Vous devriez voir les donneacutees arriver sur votre Device LoRA
| 63
7 Creacuteation de notre propre Network et Application Server
711 Objectifs Lors de la mise en œuvre du reacuteseau LoRaWAN au chapitre 52 nous avons utiliseacute TTN (The Things
Network) pour jouer le rocircle de Network Server et drsquoApplication Server Pour de multiples raisons
Seacutecuriteacute autonomie coucircthellipil peut ecirctre inteacuteressant de monter soi-mecircme un Network Server et un
Application Server Cela est possible seulement si vous posseacutedez vos propres Gateway puisque
celles-ci devront forwarder leur paquet agrave destination preacutecise Il faudra donc les reconfigurer pour
qursquoelles pointent vers votre nouvelle architecture
712 Preacutesentation de LoRaServer LoRaServer [ wwwloraserverio ] est un projet Open-Source reacutepondant exactement au besoin que
nous avons Nous lrsquoutiliserons sur une cible Raspberry PI En reacutealiteacute il peut souvent ecirctre mise en
place dans le mecircme systegraveme que la Gateway surtout si celle-ci est elle-mecircme agrave base de RPI Les
Gateway EBDS que nous posseacutedons possegravedent drsquoailleurs un Network Server et un Application Server
que nous aurions pu utiliser Neacuteanmoins pour des raisons peacutedagogiques il est inteacuteressant de
seacuteparer les systegravemes pour bien diffeacuterencier les probleacutematiques
Attention il y a une ambiguiumlteacute dans la deacutenomination des entiteacutes logiciels de LoRaServer
LoRaServer (sans espace entre le mot LoRa et Server) est le nom du projet global En
revanche LoRa Server (avec un espace) est le nom du service qui joue le rocircle du Network
Server
Lrsquoarchitecture et le fonctionnement de LoRaServer est preacutesenteacutee dans sa documentation par le
scheacutema suivant
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Raspberry PI
Figure 70 Architecture globale de notre reacuteseau loRaWAN
| 64
Figure 71 Architecture deacutetailleacutee de LoRaServer
On srsquoattends agrave voir uniquement un Network Server (LoRa Server) et un Application Server (LoRa App
Server) mais ce scheacutema est plus complexe Il demande un certain nombre drsquoexplications pour bien
comprendre ce que nous allons installer et la faccedilon dont nous lrsquoutiliserons par la suite
713 Le laquo Packet Forwarder raquo (Gateway) Comme nous lrsquoavons vu au chapitre 412 les Gateways LoRa sont des passerelles entre la
modulation LoRa et un reacuteseau IP Pour reacutealiser cette passerelle un service nommeacute laquo UDP Packet
Forwarder raquo a eacuteteacute deacuteveloppeacute par Semtech httpsgithubcomLora-netpacket_forwarder Dans
ce dossier github un fichier nommeacute PROTOCOLTXT explique parfaitement ce protocole applicatif
qui travaille au-dessus de UDP
Figure 72 Protocole Uplink (PUSH_DATA du Packet Forwarder)
| 65
On remarque que les paquets sont envoyeacutes en UDP au Network Server dans une trame appeleacutee
PUSH_DATA Cette trame est acquitteacutee par le Network Server par une trame appeleacutee PUSH_ACK
Sur notre Network Server nous pouvons reacutealiser une capture de trame pour veacuterifier si le protocole
est bien celui preacutesenteacute dans le document
Figure 73 Trame captureacutee par Wireshark lors dun Uplink
Drsquoapregraves la capture preacuteceacutedente on remarque que le Packet Forwarder fonctionne bien avec UDP sur
le port 1700
Le contenu des donneacutees (champ Data) est deacutetailleacute dans le tableau suivant
Champ | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | random token
[3] | 3 | PUSH_DATA identifier = 0x00
[4] | 4-11 | Gateway unique identifier (MAC address)
[5] | 12-end | JSON object starting with ending with
Lrsquoobjet JSON de la transmission reacuteeacutecrit plus proprement est celui-ci
Figure 74 Analyse du champ Donneacutees du protocole laquo Packet Forwarder raquo
0000 02 f9 30 00 b8 27 eb ff fe ae 26 f5 7b 22 72 78 0amprx 0010 70 6b 22 3a 5b 7b 22 74 6d 73 74 22 3a 33 37 35 pk[tmst375 0020 35 30 30 35 38 31 39 2c 22 63 68 61 6e 22 3a 32 5005819chan2 0030 2c 22 72 66 63 68 22 3a 31 2c 22 66 72 65 71 22 rfch1freq 0040 3a 38 36 38 2e 35 30 30 30 30 30 2c 22 73 74 61 868500000sta 0050 74 22 3a 31 2c 22 6d 6f 64 75 22 3a 22 4c 4f 52 t1moduLOR 0060 41 22 2c 22 64 61 74 72 22 3a 22 53 46 37 42 57 AdatrSF7BW 0070 31 32 35 22 2c 22 63 6f 64 72 22 3a 22 34 2f 35 125codr45 0080 22 2c 22 6c 73 6e 72 22 3a 36 2e 35 2c 22 72 73 lsnr65rs 0090 73 69 22 3a 2d 31 2c 22 73 69 7a 65 22 3a 31 38 si-1size18 00a0 2c 22 64 61 74 61 22 3a 22 51 4e 4d 61 41 53 59 dataQNMaASY 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 ]
Ch
amp
[1
]
Ch
amp
[2
]
Ch
amp
[3
]
Ch
amp
[4
]
| 66
rxpk[ tmst3755005819
chan2
rfch1
freq868500000
stat1
moduLORA
datrSF7BW125
codr45
lsnr65
rssi-1
size18
dataQNMaASYAAQAPpyPZ955+SmY
]
Le champ data correspond au PHY Payload
De la mecircme faccedilon on retrouve la Trame drsquoacquittement
Figure 75 Trame captureacutee par Wireshark lors de lrsquoacquittement drsquoun Uplink
Champs | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | same token as the PUSH_DATA to acknowledge
[3] | 3 | PUSH_ACK identifier = 0x01
Nous retrouvons bien tous ces champs dans la trame Wireshark
714 LoRa Gateway Bridge Nous avons deacutecrit au chapitre preacuteceacutedent (713) le fonctionnement du Packet Forwarder Le
Network Server(Lora Server) que nous allons mettre en place aurait tregraves bien pu srsquointerfacer
directement agrave ce protocole Mais cela aurait plusieurs impacts dont un qui est important dans la
conception de logiciel Si le Packet Forwarder change ou si un autre type de Forwarder est utiliseacute
alors lrsquoutilisation du LoRa Server devient impossible Il a donc eacuteteacute choisi de creacuteer une eacutetape
intermeacutediaire Le Network Server que nous mettrons en plus utilisera le protocole MQTT plutocirct que
le protocole UDP packet Forwarder
En drsquoautres termes le LoRa Gateway Bridge est un service qui fera abstraction du Packet Forwarder
pour srsquointerfacer plus simplement avec le Network Server
715 LoRa Server (Network Server) Il srsquoagit de notre Network Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
413 Cependant il srsquointerfacera au protocole MQTT en recevant les informations agrave partir du
Broker au lieu de recevoir directement les trames en provenance de la Gateway
| 67
716 LoRa App Server (Application Server) Il srsquogit de notre Application Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
414
717 LoRa Geo Server Il srsquoagit drsquoun service qui permet drsquoutiliser certaines proprieacuteteacutes du protocole LoRa pour proposer un
service de geacuteolocalisation des Devices LoRa Nous ne lrsquoutiliserons pas dans notre cas
718 Application Il srsquoagit de notre Application qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre 415
Elle ne fait pas partie du projet LoRaServer crsquoest donc bien toujours agrave nous de proposer notre propre
Application
Figure 76 Les interfaces possibles entre LoRaServer et lrsquoApplication utilisateur
Comme nous pouvons le voir sur la figure preacuteceacutedente deux possibiliteacutes sont offertes pour interfacer
notre application JSON REST (incluant HTTP POST) et via un Broker MQTT Ces deux meacutethodes ont
deacutejagrave eacuteteacute traiteacutee au chapitre 61 (HTTP POST ) et au chapitre 62 (MQTT) Nous verrons aussi drsquoautres
possibiliteacutes pour personnaliser notre application au chapitre 7
72 Installation de LoRaServer
721 Mise en place de lrsquoenvironnement
Nous allons installer une carte SD avec la derniegravere version de Raspbian Nous ne deacutetaillerons pas la
deacutemarche pour cela car elles sont largement documenteacutees et mises agrave jour sur le site
wwwraspberrypiorg
Installer un carte SD avec la derniegravere version de Raspbian
Plutocirct que de fonctionner avec un clavier et une souris nous preacuteconisons de travailler agrave distance
avec la RPI via une connexion SSH Depuis quelques anneacutees Raspbian a supprimeacute le deacutemarrage du
service SSH au boot Heureusement il est possible de le reacuteactiver par la meacutethode suivante
Avec Windows ou Linux ouvrir la partition BOOT de votre carte SD et placer un fichier agrave la
racine nommeacute sshtxt (ou ssh)
Mettre la carte SD dans votre RPI et la deacutemarrer
| 68
Pour acceacuteder agrave la RPI en SSH depuis Windows nous utiliserons de preacutefeacuterence le logiciel
client MobaXterm mais tout autre client SSH est valable
Installer MobaXterm sur votre PC et connectez-vous agrave votre Raspberry PI
Lrsquoutilisation drsquoun espion de reacuteseau type Wireshark peut ecirctre inteacuteressant pour eacutetudier les trames qui
sont reccedilues et qui sont eacutemises Cela nous permettra de valider le fonctionnement des diffeacuterents
protocoles reacuteseau qui permettent de communiquer agrave la Gateway drsquoune part et agrave lrsquoApplication
drsquoautre part Nous utiliserons tshark
apt-get install tshark installation
tshark ndashn -i eth0 Exemple drsquoune analyse sur lrsquointerface wlan0
722 Installation sur la Raspberry PI La meacutethode drsquoinstallation de LoRaServer est documenteacutee sur le site web agrave lrsquoadresse suivante
[ httpswwwloraserverioguidesdebian-ubuntu ] Nous installerons le LoRa Gateway Bridge
le LoRa Server et le LoRa App Server
Apregraves lrsquoinstallation la configuration se fait par une interface graphique accessible par le reacuteseau sur
le port 8080
Si vous travaillez sur la RPI connectez-vous sur httplocalhost8080
Si vous travaillez agrave distance (SSH) connectez-vous sur httpIP_RPI8080
Les Usernames et Password par deacutefaut sont
Username admin
Password admin
Lrsquoeacutecran drsquoaccueil sera donc le suivant
Figure 77 Architecture globale apregraves installation de LoRaServer
Devices
Gateways LoRa
UDP Packet Forwarder
Application Server
LoRa App Server
Internet
Network Server
LoRa Server
LoRa Gateway Bridge
| 69
Figure 78 Ecran daccueil de LoRaServer apregraves authentification
71 Configuration de LoRa Server pour lUplink
711 Enregistrement drsquoune nouvelle Organisation
Pour enregistrer une nouvelle Organizations Organizations gt Create Puis entrer les configurations
suivantes
Figure 79 Enregistrement dun nouvelle Organisation
712 Enregistrement drsquoune instance du Network Server Pour enregistrer une nouvelle instance du Network Server Network Server gt Create Puis entrer
les configurations suivantes
| 70
Figure 80 Enregistrement dun nouveau Network Server
Dans lrsquoonglet Gateway Discovery il est possible drsquoactiver une option de deacutecouverte de Gateway aux
alentours Lorsqursquoelle est configureacutee le Network Server va envoyer une trame Downlink de
configuration de la Gateway lui ordonnant de reacutealiser des PING en LoRa La configuration du
Gateway Discovery preacutevoit de speacutecifier
Le nombre de fois par jour que les PING LoRa sont envoyeacutes
Le canal drsquoeacutemission
Le Data Rate (Voir paragraphe 445)
Un PING LoRa reccedilu sur une Gateway sera retransmis sur le Network Server (Lora Server) et une carte
sera afficheacutee
Lrsquoonglet TLS Certificates ne sera pas utiliseacute dans le cadre de notre deacutemonstration
713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) Il faut tout drsquoabord faire un enregistrement drsquoun laquo service-profile raquo Un laquo service profile permet de
faire la connexion entre le Network Server et les Applications que nous enregistrerons dans notre
Organisation Service-profiles gt Create
Service-profile name myServiceProfile
Network-server myNetworkServer
On laissera par deacutefaut toutes les autres options
Pour enregistrer une nouvelle Application Applications gt Create Puis entrer les configurations
suivantes
| 71
Figure 81 Enregistrement dune nouvelle Application
714 Enregistrement des Devices LoRa Il faut tout drsquoabord faire lrsquoenregistrement drsquoun Device-profile pour les Devices LoRa que vous
souhaitez connecter Dans notre cas nous ferons un premier test en speacutecifiant que nous utilisons
seulement le mode drsquoauthentification ABP (voir chapitre 431) Devices profile gt Create
Figure 82 Enregistrement dun laquo Device profile raquo
Nous pouvons alors creacuteer dans notre Application des nouveaux Devices Application gt
myApplication gt Create
| 72
Figure 83 Enregistrement dun nouveau Device LoRa
Dans la fenecirctre Activation on va alors configurer les 3 eacuteleacutements indispensables agrave une
authentification en APB Le DevAddr le NwkSKey et lrsquoAppSKey
Figure 84 Configuration de lenregistrement du Device LoRa (en ABP)
La configuration minimale de LoRaServer est maintenant termineacutee Nous pouvons donc brancher
un Device LoRa qui possegravede les les attribus (DevAddr NwkSKey et AppSKey) que nous avons
enregistreacute dans LoRaServer et le faire eacutemettre
715 Visualisation des trames reccedilues Les trames eacutemises par le Device LoRa vont donc parcourir le cheminement suivant
| 73
Figure 85 Reacutesumeacute du cheminement des trames LoRaWan en Uplink avec LoRaServer
En allant dans le Live Device Data (Application gt Nom_du_Device gt Live Device Data) on peut voir la
liste des trames reccedilues ainsi que les donneacutees applicatives deacutechiffreacutees
Figure 86 Reacuteception des trames des Devices LoRa
Figure 87 Analyse des trames des Devices LoRa
Dans lrsquoonglet LIVE LORAWAN FRAME nous pouvons voir les trames LORAWAN et si besoin eacutetudier
le contenu de ce qursquoelles contiennent En revanche les donneacutees applicatives sont ici chiffreacutees
UDP
Packet Forwarder
LoRa Bridge
Gateway LoRa Server LoRa App Server
Gateway
Server
Internet
| 74
Figure 88 Reacuteception des Trames LoRaWAN
72 Configuration de LoRaServer pour linteacutegration dApplication Nous avons vu dans le chapitre 718 que linterface entre LoRaServer et notre Application pouvait
ecirctre reacutealiseacutee soit par MQTT soit par les meacutethodes REST (HTTP POST) Nous avons deacutejagrave impleacutementeacute
et expliqueacute ces protocoles dans le cadre de son utilisation avec TTN Nous allons donc juste
configurer LoRaServer pour tester ces deux meacutethodes
721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST Nous utiliserons exactement la mecircme meacutethode que celle que nous avons utiliseacute avec TTN au
chapitre 615 Les diffeacuterentes Clients et Serveurs disponibles pour ces tests sont expliqueacutes au
paragraphe 612
Dans LoRaServer ajouter une inteacutegration HTTP LoRaServer gt Applications gt myApplication gt
Integrations gt Create gt HTTP Integration et la configurer comme le montre la Figure 89 Vous
remplacerez eacutevidement le lien par votre propre Endpoints
Figure 89 Configuration de linteacutegration HTTP POST dans LoRaServer
En envoyant des trames LoRa depuis votre Device vous devriez voir les contenus JSON sur votre
Endpoint
722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT Nous allons nous connecter au Broker MQTT de LoRaServer Pour cela nous utiliserons la mecircme
meacutethode que celle que nous avons utiliseacute avec TTN au chapitre 628 Nous utiliserons MQTTBox
comme nous lavons deacutejagrave fait au paragraphe 627
Le Broker de LoRaServer a enregistreacute les Topics suivant
[applicationID] correspond au nom de votre Application
[devEUI] correspond au nom de votre Device LoRa
| 75
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink application[applicationID]device[devEUI]rx
[Donneacutees] Flux Downlink application[applicationID]device[devEUI]tx
[Status] Statut dun Device application[applicationID]device[devEUI]status
[Ack] Acquittement des messages application[applicationID]device[devEUI]ack
[Erreurs] Erreurs application[applicationID]device[devEUI]error
Tableau 13 Topics enregistreacutes dans LoRaServer
| 76
8 Creacuteation de notre propre Application
81 Utilisation de Node-RED
811 Preacutesentation Node-RED est un outil de programmation graphique qui permet de faire communiquer les
peacuteripheacuteriques mateacuteriels drsquoun systegraveme sans eacutecrire de code De nombreux protocoles sont aussi pris
en charge au travers de bloc ( Node) qursquoil suffit de connecter entre eux pour reacutealiser simplement
une application Il peut srsquoexeacutecuter localement sur un PC ou sur des cibles embarqueacutees telle qursquoune
Raspberry PI (RPI)
Dans les deacutemonstrations que nous mettrons en œuvre nous utiliserons une RPI Par soucis de
simpliciteacute nous utiliserons les derniegraveres versions de Raspbian (systegraveme drsquoexploitation de la RPI) qui
integravegre drsquoorigine Node-RED Il nrsquoy a donc tregraves peu de chose agrave mettre en place pour arriver agrave mettre
en place une Application Nous pouvons travailler soit directement sur la RPI agrave lrsquoaide drsquoune souris-
clavier mais il est recommandeacute de travailler agrave distance avec une connexion SSH
812 Mise en place de lrsquoenvironnement La mise en place de la RPI avec le systegraveme drsquoexploitation Raspbian a eacuteteacute preacutesenteacute au chapitre 721
Vous pouvez reprendre la mecircme installation ou repartir sur une nouvelle
Il est possible de faire en sorte que Node-RED se lance directement au deacutemarrage gracircce agrave la
commande sudo systemctl enable noderedservice
Sil nest pas actif lancer Node-RED sur votre RPI node-red-start
Nous nous connectons au Node-RED de la RPI via un navigateur web sur le port 1880 en tapant dans
la barre dURL httpIP_Raspeberry_PI1880 Ce nous permet darriver agrave la fenecirctre suivante
Figure 90 Page daccueil de Node-RED
Il est possible de sinterfacer avec TTN avec les Nodes deacutejagrave disponibles gracircce au protocole HTTP
POST ou MQTT Neacuteanmoins nous pouvons avantageusement installer deux librairies speacutecifiques
Une qui facilite linterfaccedilage avec TTN
Une qui facilite la mise en place dinterface graphique
Installation des Nodes TTN
cd $HOMEnode-red
npm install node-red-contrib-ttn
Installation de Dashboard (interface graphique)
| 77
cd $HOMEnode-red
npm install node-red-dashboard
Il peut ecirctre necessaire de redeacutemarrer Node-RED pour prendre en compte linstallation de nos deux
Nodes
-----------------------------------
sudo apt-get install npm
sudo npm install -g npm
hash -r
cd ~node-red
npm install node-red-example node name
------------------------------------
813 Creacuteer une Application speacutecifique pour TTN Nous allons commencer par geacuterer le flux Uplink Apporter sur votre scheacutema un Node ttn uplink et
un Node Debug puis relier les Le Node ttn uplink nous permettra de configurer la
communication avec TTN en MQTT Le Node debug eacutecrira sur le terminal les informations brutes
qui seront reccedilu par le Node ttn uplink
Figure 91 Visualisation des trame publieacutees par TTN sur notre client MQTT
Double cliquer sur le Node ttn uplink pour le configurer comme la figure suivante
Le champ Name sera le nom du Node sur votre scheacutema Le champ Device ID est le device LoRa
concerneacute dans votre application De plus il faut entrer les caracteacuteristiques de votre application (Add
new ttn app) pour que Node-RED puisse sy connecter
Figure 92 Configuration du node ttn uplink
Configuration de votre nouvelle application
| 78
Figure 93 Identifiant et mot de passe de notre application
AppID Nom de votre application Dans notre cas seminaire_lorawan
Access Key Comme nous lavons deacutejagrave expliqueacute plus tocirct l Access Key vous sera donneacutee
par lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application
vous trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt
Overview
Le Node ttn uplink doit maintenant avoir le nom que vous avez configureacute Cliquer sur Deploy pour
lancer votre projet Le bloc ttn uplink doit maintenant ecirctre connecteacute agrave TTN Cela est speacutecifieacute
connected sous le bloc
Figure 94 Utilisation du Node TTN Uplink
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
Figure 95 Simulation de Uplink dans TTN
Vous devriez voir le reacutesultat dans la fenecirctre de Debug Par exemple pour le test denvoi de 31 32
correspondant au code ASCII des chiffres 1 et 2 vous devriez avoir la fenecirctre de Debug suivante
| 79
Figure 96 Reacutesultats obtenu dans la fenecirctre Debug apregraves la simulation dUplink
814 Creacuteation drsquoun Dashboard
Dans la mise en place de lenvironnement (chapitre 812) nous avons installeacute des Nodes
Dashboard qui vont nous permettre de reacutealiser une interface graphique tregraves simple et de la mettre
agrave disposition des utilisateurs via un des graphiques histogramme gauges afficheurshellip
Figure 97 Impleacutementation dune interface graphique dans Node RED
Linterface graphique que nous allons creacuteer sera constitueacutee donglet (tab) La mise en place des
composant se fait de la faccedilon suivante
Chaque eacuteleacutement graphique doit appartenir agrave un groupe de composant quil va falloir creacuteer
Chaque groupe de composant doit appartenir agrave un onglet (tab) quil va falloir creacuteer
Figure 98 Creacuteation dun groupe de composant
Figure 99 Creacuteation dun nouvel onglet dans le site web
Cliquer sur Deploy pour activer votre application
LURL pour joindre linterface graphique de votre site web est disponible sur ladresse
httpIP_Raspeberry_PI1880ui
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
| 80
Figure 100 Interface graphique du site web avec Node-RED
82 Programmation en PHP Maintenant que nous avons testeacute toute lrsquoarchitecture nous pouvons mettre en place une
application qui jouera deux rocircles
Un rocircle de Serveur HTTP POST reacutecupeacuterant les donneacutees en provenance de TTN
Un rocircle de Client HTTP POST qui geacuteneacuterera les requecirctes vers TTN
Un serveur web apache sur RPI heacuteberge cette application Linterface graphique du site web est
reacutealiseacute avec le template CSS proposeacute par Bootstrap [ httpsgetbootstrapcom ]
Figure 101 Architecture de notre application en PHP sur RPI
The Things Network
Notre Application
[ Serveur Apache sur Raspberry Pi ]
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 81
Nous allons lrsquoutiliser telle quelle Elle est juste proposeacutee agrave titre dexemple Lrsquoobjectif de cette
application est de geacuteneacuterer une ouverture fermeture de ruche agrave distance dans le cadre de projets
eacutetudiants du Master Electronique et Systegravemes Embarqueacutes de lUSMB [ httpscem-esetuniv-
smbfr ]
Figure 102 Application permettant de recevoir et deacutemettre des requecirctes HTTP POST
Configurer TTN pour pointer vers votre nouveau serveur et tester le flux montant et
descendant
| 82
9 Versions du document
Version 10 02022019
Version initiale
Version 20 23022019
Ajout drsquoun paragraphe Les systegravemes embarqueacutes dans lrsquoIoT En introduction
Compleacutement et ameacutelioration Ameacutelioration exercice eacutetalement de spectre
Correction Cacircblage Arduino
Ajout drsquoun paragraphe Fonctionnement de lrsquoArduino et ajout de librairies
Compleacutement et ameacutelioration Couche physique LoRa Ajout de 4 figures pour lrsquoexplication
de la modulation Chirp
Ajout drsquoun paragraphe sur les acronymes utiliseacutes au deacutebut du cours TTN LoRa MQTThellip
Compleacutement drsquoinformations sur les dB et dBm
Ajout LoRa Calculator
Version 30 8032019
Ajout de figure sur le rocircle de la Gateway LoRa
Ajout de paragraphe authentification avec le Network Server
Ajout de paragraphe sur le chiffrement avec lrsquoApplication Server
Ajout drsquoun sommaire en deacutebut de cours
Ajout de 2 scheacutemas ABP et OTAA
Retrait explication du deacutetail de la laquo Join Request raquo en OTAA Trop complexe attente de
reacutealisation drsquoun scheacutema plus explicite
Ajout drsquoun scheacutema sur lrsquoattaque par REPLAY
Ajout de paragraphe des diffeacuterents reacuteseaux LoRaWAN existants Opeacutereacutes et Priveacutes
Ajout des scheacutemas des trames LoRaWAN Physique LoRa MAC Application
Compleacutement drsquoinformation sur les Classes de Devices
Ajout drsquoun paragraphe sur la Gateway utiliseacutee pour le Downlink
Ajout drsquoun paragraphe sur le JSON
Compleacutement drsquoinformation sur le codage en Base64
Ajout drsquoinformation dans le deacutecodage des trames LoRaWAN
Restructuration des explications sur lrsquoenvoi et la reacutecupeacuteration des donneacutees en HTTPMQTT
Version 40 8032019
Ajout drsquoun chapitre Creacuteation de notre propre Application
Ajout drsquoun chapitre Creacuteation de notre propre Network et Application Server
Ajout drsquoune figure Visualisation des Chirps LoRa par SDR (Radio Logicielle)
Compleacutements drsquoinformation sur MQTT
Compleacutements dinformation sur les Topics de TTN en MQTT
| 5
721 Mise en place de lrsquoenvironnement 67 722 Installation sur la Raspberry PI 68
71 CONFIGURATION DE LORA SERVER POUR LUPLINK 69 711 Enregistrement drsquoune nouvelle Organisation 69 712 Enregistrement drsquoune instance du Network Server 69 713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) 70 714 Enregistrement des Devices LoRa 71 715 Visualisation des trames reccedilues 72
72 CONFIGURATION DE LORASERVER POUR LINTEGRATION DAPPLICATION 74 721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST 74 722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT 74
8 CREATION DE NOTRE PROPRE APPLICATION 76
81 UTILISATION DE NODE-RED 76 811 Preacutesentation 76 812 Mise en place de lrsquoenvironnement 76 813 Creacuteer une Application speacutecifique pour TTN 77 814 Creacuteation drsquoun Dashboard 79
82 PROGRAMMATION EN PHP 80
9 VERSIONS DU DOCUMENT 82
| 6
1 Les systegravemes embarqueacutes et lrsquoIoT
11 LInternet des Objets ( Internet of Things IoT )
111 Les systegravemes embarqueacutes dans lrsquoIoT Drsquoune faccedilon geacuteneacuterale les systegravemes eacutelectroniques peuvent ecirctre caracteacuteriseacutes par leur consommation
leur puissance de calcul leur taille et leur prix Dans le cas speacutecifique des systegravemes embarqueacutes
utiliseacutes dans lrsquoIoT nous pouvons affecter le poids suivant agrave chacune des caracteacuteristiques
Figure 1 Consommation Puissance Taille et Prix des objets connecteacutes
Compareacutes aux autres systegravemes eacutelectroniques les systegravemes embarqueacutes utiliseacutes dans lrsquoIoT possegravedent
donc
Une faible consommation
Une faible puissance de calcul
Une petite taille
Un prix faible
112 Diffeacuterents protocoles dans lrsquoIoT
Citez les diffeacuterents protocoles que vous connaissez dans le mode de lrsquoIoT (Internet Of
Things) et reportez-les dans le graphique ci-dessous en fonction de leur bande passante
et de leur porteacutee
Figure 2 Protocoles utiliseacutes dans lIoT en fonction du deacutebit et de la porteacutee
Dans lrsquoIoT les protocoles utiliseacutes possegravedent une grande porteacutee et des deacutebits faibles
Lrsquoensemble de ces reacuteseaux sont deacutenommeacutes LPWAN Low Power Wide Area Network
113 Bande de freacutequence utiliseacutees En Europe les bandes de freacutequences libres (sans licence) sont
13 Mhz (RFID) 169 Mhz 434 Mhz 868 Mhz 24Ghz 5 Ghz et 24 Ghz (Faisceau Hertzien) Parmi ces
freacutequences seul le 433 MHz et 868 MHz sont utilisables en LoRa
12 Modes de partage du support Quel que soit le protocole utiliseacute le support de transfert de lrsquoinformation est lrsquoair car tous les
protocoles de lrsquoIoT sont Wireless Le support doit ecirctre partageacute entre tous les utilisateurs de telle
faccedilon que chacun des dispositifs Wireless ne perturbe pas les autres Pour cela une bande de
freacutequence est alloueacutee Par exemple pour la radio FM la bande de freacutequence va de 875 Mhz agrave 108
Mhz
Dans leur bande de freacutequence les dispositifs peuvent se partager le support de diffeacuterentes
maniegraveres
FDM (Frequency Division Multiplexing) Ce mode utilise une partie du spectre (bande de
freacutequence) en permanence Exemple Radio FM
TDM (Time Division Multiplexing) Ce mode utilise tout le spectre (bande de freacutequence) par
intermittence Exemple GSM on a laquo 8 time slots raquo par canal
CDMA (Code Division Multiple Access) Ce mode utilise tout le spectre tout le temps
Porteacutee (Range)
Deacutebit (Bandwidth)
| 8
Les Devices LoRa sont capables drsquoeacutemettre sur un mecircme canal en mecircme temps Le protocole LoRa
utilise une modulation tregraves similaire agrave la meacutethode 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 Plus
tard dans le cours nous expliquerons les diffeacuterences de la modulation LoRa
13 Notion drsquo eacutetalement de spectre utiliseacutee en LoRa Nous allons voir au travers drsquoun exercice comment il est possible drsquoutiliser tout le spectre en
permanence tout en eacutetant capable drsquoeffectuer plusieurs transactions simultaneacutees entre diffeacuterents
eacutemetteursreacutecepteurs Cette meacutethode est souvent appeleacutee laquo eacutetalement de spectre raquo car comme
son nom lrsquoindique elle a pour conseacutequence drsquoeacutetaler le spectre du signal transmis
La meacutethode consiste agrave utiliser des codes qui ont des proprieacuteteacutes matheacutematiques adapteacutees agrave notre
objectif Transmettre en mecircme temps sur la mecircme bande de freacutequence La matrice ci-dessous
donne par exemple 4 codes drsquoeacutetalement (1 par ligne)
Code Orthogonal User 0 1 1 1 1
Code Orthogonal User 1 1 -1 1 -1
Code Orthogonal User 2 1 1 -1 -1
Code Orthogonal User 3 1 -1 -1 1
Tableau 1 Matrice de Hadamart (matheacutematicien) dordre 4
Les proprieacuteteacutes de ces codes (1 1 1 1 1 -1 1 -1 1 1 -1 -1 1 -1 -1 1) ne sont pas expliqueacutees ici Nous
nous conterons de veacuterifier leur bon fonctionnement
131 Transmissions successives Chaque tableau ci-dessous repreacutesente une transmission qui est indeacutependante des autres elles ne
se deacuteroulent pas en mecircme temps On veacuterifie qursquoavec la mise en œuvre de laquo lrsquoeacutetalement de spectre raquo
chaque transmission arrive bien agrave destination avec le message qui avait eacuteteacute transmis Le premier
tableau est deacutejagrave rempli en guise drsquoexemple La meacutethode est la suivante
A lrsquoeacutemission
Chaque bit du message est multiplieacute par un code drsquoeacutetalement (une ligne de la matrice)
Le reacutesultat de la multiplication est transmis
A la reacuteception
Chaque symbole reccedilu est multiplieacute par le mecircme code drsquoeacutetalement
Le message reccedilu est eacutegal agrave la somme des symboles diviseacute par le nombre de symbole
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
hellip transmission hellip
4 Utilisation code orthogonal User 1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1
5 Deacutecodage = (3) x (4) 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0
6 Message reccedilu (sum (5) nbr_bits) 1 0 1 0
Reacutealiser la transmission du message du User 2 et du User 3 dans les tableaux suivants
| 9
1rsquo Message User 2 0 1 0 1
2rsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
3rsquo Symboles transmis User 2 = (1rsquo) x (2rsquo) 0 0 0 0
hellip transmission hellip
4rsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
5rsquo Deacutecodage = (3rsquo) x (4rsquo) 0 0 0 0
6rsquo Message reccedilu (sum (5rsquo) nbr_bits) 0
1rsquorsquo Message User 3 1 1 0 0
2rsquorsquo Utilisation code orthogonal User 3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
3rsquorsquo Symboles transmis User 3 = (1rsquorsquo) x (2rsquorsquo) 1 -1 -1 1
hellip transmission hellip
4rsquorsquo Utilisation code orthogonal User3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
5rsquorsquo Deacutecodage = (3rsquorsquo) x (4rsquorsquo) 1 1 1 1
6rsquorsquo Message reccedilu (sum (5rsquorsquo) nbr_bits) 1
132 Transmissions simultaneacutees
Les transmissions se deacuteroulent maintenant simultaneacutement les messages des User 1 User 2 et User
3 sont envoyeacutes en mecircme temps sur la mecircme bande de freacutequence La premiegravere colonne du User 1
est deacutejagrave remplie en guise drsquoexemple La meacutethode est la suivante
Dans lrsquoair
On additionne les symboles transmis par tous les User (1 2 3) ligne 1rsquorsquorsquo
Pour la reacuteception
Chaque symbole reccedilu est multiplieacute par le code drsquoeacutetalement du User
Le message reccedilu est eacutegal agrave la somme des symboles diviseacute par le nombre de symbole
Valider le fonctionnement pour la reacuteception des messages
1rsquorsquorsquo sum des symboles transmis ( 3 + 3rsquo + 3rsquorsquo ) 2 -2 0 0
2rsquorsquorsquo Utilisation code orthogonal User 1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 2 0 0
4rsquorsquorsquo Message reccedilu User 1 (sum (3rsquorsquorsquo) nbr_bits) 1
2rsquorsquorsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 -2 0 0
4rsquorsquorsquo Message reccedilu User 2 (sum (3rsquorsquorsquo) nbr_bits) 0
2rsquorsquorsquo Utilisation code orthogonal User 3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 2 0 0
4rsquorsquorsquo Message reccedilu User 3 (sum (3rsquorsquorsquo) nbr_bits) 1
133 Cas du protocole LoRa Le LoRa utilise une meacutethode drsquoeacutetalement de spectre qui nrsquoest pas exactement celle que nous venons
drsquoeacutetudier La finaliteacute est cependant la mecircme Pouvoir transmettre en mecircme temps sur le mecircme
canal Le protocole LoRa utilise sept laquo codes drsquoeacutetalement raquo appeleacutes Spreading Factor [ SF6 SF7 SF8
SF9 SF10 SF11 et SF12 ] qui lui permet drsquoavoir sept transmissions simultaneacutees sur un mecircme canal
| 10
2 Transmission radio et propagation
21 Les uniteacutes et deacutefinitions dB Rapport entre deux puissances Une atteacutenuation est repreacutesenteacutee par un nombre
neacutegatif (-) Un gain est repreacutesenteacute par un nombre positif (+)
Rapport de puissances en dB Rapport de puissance
+ 3 dB Multiplication par 2
- 3 dB Division par 2
0 dB Egaliteacute
+ 10 dB Multiplication par 10
- 10 dB Division par 10
Tableau 2 Comparaison entre les gains en dB et en proportion
dBi Gain theacuteorique drsquoune antenne
dBm Puissance rameneacutee agrave 1mW 0 dBm correspond agrave 1 mW
En reprenant la deacutefinition des dB remplir le tableau suivant
Puissance en dBm Puissance en mW
+ 3 dBm
- 3 dBm
+ 10 dBm
- 10 dBm
Tableau 3 Comparaison entre les puissances en dB et en mW
Le Talkie-Walkie a une puissance drsquoeacutemission de 2W Quelle est la puissance drsquoeacutemission
exprimeacutees en dBm
Sensibiliteacute Puissance minimale qursquoest capable de deacutetecter un reacutecepteur
RSSI Received Signal Strength Indication
SNR Signal over Noise Ratio
Un eacutemetteur transmet agrave une puissance de 13dBm en utilisant une antenne dont le gain
est de 2dBi Les pertes dans lrsquoair sont de 60 dB Lrsquoantenne reacuteceptrice qui possegravede un gain
de 2dBi est relieacutee agrave un reacutecepteur dont la sensibiliteacute est de -80 dBm Le signal pourra-t-il
ecirctre reccedilu
Le link Budget Crsquoest la quantiteacute de puissance que nous pouvons perdre avant drsquoarriver au
reacutecepteur tout en conservant une transmission fonctionnelle Autrement dit crsquoest la
puissance de lrsquoeacutemetteur moins la sensibiliteacute du reacutecepteur Dans lrsquoexemple preacuteceacutedent le
budget que nous avons agrave disposition est de 93dB
| 11
En LoRa nous avons un Link Budget de 157 dB
En LTE (4G) nous avons un Link Budget de 130 dB
Etude de la documentation drsquoun composant LoRa Le RN2483 est le composant radiofreacutequence que nous utiliserons dans notre transmission LoRa
Voici quelques une de ses caracteacuteristiques
Figure 3 Caracteacuteristiques principales du composant radiofreacutequence utiliseacute
Reprenez la deacutefinition du Link Budget et retrouver les 157 dB annonceacute dans cette
documentation
En LoRa plus le code drsquoeacutetalement est grand plus on est capable drsquoeacutemettre dans un milieu bruiteacute La
figure ci-dessous preacutesente les rapports signal sur bruit avec lesquels nous seront capable de reacutealiser
une transmission en fonction des Spreading Factor utiliseacutes
Figure 4 Influence du Spreading Factor sur le SNR acceptable
On remarque que pour un SF8 nous sommes capables drsquoeacutemettre avec un SNR de -10 dB On pourra
transmettre malgreacute le fait que le bruit est 10 fois supeacuterieur au signal
On remarque que pour un SF12 nous sommes capables drsquoeacutemettre avec un SNR de -20 dB On
pourra transmettre malgreacute le fait que le bruit est 100 fois supeacuterieur au signal
| 12
Cependant on remarque aussi que lrsquoutilisation drsquoun Spreading Factor plus eacuteleveacute augmente
consideacuterablement le nombre de symbole eacutemis (2egraveme colonne du tableau) Comme nous le verrons
plus tard cela impactera eacutevidement le temps de transmission
| 13
3 La couche physique LoRa
31 La modulation LoRa Comme nous lrsquoavons expliqueacute plus tocirct la modulation LoRa utilise lrsquoeacutetalement de spectre pour
transmettre ces informations Mais au lieu drsquoutiliser des codes drsquoeacutetalement (CDMA) elle utilise une
meacutethode appeleacutee Chirp Spread Spectrum La finaliteacute est toujours la mecircme Avoir plusieurs
transmissions dans le mecircme canal La conseacutequence sur le spectre est aussi la mecircme cela provoque
un eacutetalement du spectre
311 La forme du symbole (Chirp) Le signal eacutemis par la modulation LoRa est un symbole dont la forme de base est repreacutesenteacutee ci-
dessous Son nom (Chirp) vient du fait que ce symbole est utiliseacute dans la technologie Radar (Chirp
Compressed High Intensity Radar Pulse)
Figure 5 Symbole de la modulation LoRa (source Wikipeacutedia)
La freacutequence de deacutepart est la freacutequence centrale du canal moins la Bande Passante diviseacutee par deux
La freacutequence de fin est la freacutequence centrale plus la Bande Passante diviseacutee par deux
La freacutequence centrale est appeleacutee le canal
La bande passante est la largeur de bande occupeacutee autour du canal
On considegravere une eacutemission sur la freacutequence centrale 868 Mhz avec une Bande Passante
de 125 kHz Donner la freacutequence de deacutebut et la freacutequence de fin du sweep
Freacutequence de deacutebut
Freacutequence de fin
Pour faciliter la repreacutesentation de ce symbole on utilise plutocirct un graphique TempsFreacutequence de
la forme suivante
| 14
Figure 6 Forme du symbole de base (CHIRP)
En LoRa chaque symbole repreacutesente un certain nombre de bits transmis La regravegle est la suivante
Nombre de bits transmis dans un symbole = Spreading Factor
Par exemple si la transmission utilise un Spreading Factor de 10 (SF10) alors un symbole repreacutesente
10 bits
Crsquoest-agrave-dire qursquoagrave lrsquoeacutemission les bits sont regroupeacutes par paquet de SF bits puis chaque paquet est
repreacutesenteacute par un symbole particulier parmi 2119878119865formes de symboles possibles
Sur la figure suivante voici un exemple theacuteorique drsquoune modulation en SF2 agrave 868 Mhz sur une
bande passante de 125 kHz Chaque symbole repreacutesente donc 2 bits
Figure 7 Symboles eacutemis en Modulation LoRa (Cas theacuteorique en SF2)
Exemple
On considegravere la suite binaire suivante 0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Le Spreading Factor utiliseacute est SF10
Nous regroupons donc les bits par paquet de 10 Chaque paquet de 10 bits sera repreacutesenteacute par un
symbole (sweep) particulier Il y a 1024 symboles diffeacuterents pour coder les 1024 combinaisons
binaires possibles (210)
Freacutequence
Temps
868 000 000 Hz
868 062 500 Hz
Un symbole Un symbole
867 937 500 Hz
Temps
868 000 000 Hz
867 937 500 Hz
Symbole 0
Bits laquo 00 raquo
Symbole 1
Bits laquo 01 raquo
Symbole 2
Bits laquo 10 raquo Symbole 3
Bits laquo 11 raquo
12
5 k
Hz
868 062 500 Hz
| 15
Figure 8 Emission des Chirp en LoRa
Avec un outils drsquoanalyse spectrale actif pendant lrsquoeacutemission LoRa drsquoun Device on peut afficher les
successions de symbole qui sont envoyeacutes Cette oscillogramme a eacuteteacute reacutealiseacute agrave lrsquoaide drsquoun SDR
(Software Digital Radio)
Figure 9 Visualisation des Chirps LoRa reacuteellement eacutemis pendant une transmission
312 Dureacutee drsquoeacutemission drsquoun symbole En LoRa la dureacutee drsquoeacutemission de chaque symbole (Chirp) deacutepend du Spreading Factor utiliseacute Plus le
SF est grand et plus le temps drsquoeacutemission sera long Pour une mecircme bande passante le temps
drsquoeacutemission drsquoun symbole en SF8 est deux fois plus long que le temps drsquoeacutemission drsquoun symbole en
SF7 Ainsi de suite jusqursquoagrave SF12
0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Envoi de 1 Chirp Envoi de 1 Chirp Envoi de 1 Chirp
Transmission Transmission Transmission
| 16
Figure 10 Temps drsquoeacutemission drsquoun symbole (Chirp) en fonction du SF
En revanche le temps drsquoeacutemission drsquoun symbole est inversement proportionnel agrave la bande passante
119879119904 =2119878119865
119861119886119899119889119908119894119889119905ℎ Le deacutebit des symboles est donc de
1
119879119878= 119865119904 =
119861119886119899119889119908119894119889119905ℎ
2119878119865 En toute logique plus la
bande passant est eacuteleveacute plus le deacutebit des symboles sera eacuteleveacute Comme chaque symbole comprend
SF bit on retrouve alors le deacutebit binaire
119863119887 = 119878119865119861119886119899119889119908119894119889119905ℎ
2119878119865
Plus le Spreading Factor sera eacuteleveacute plus le deacutebit binaire sera faible
Plus la Bande Passante sera eacuteleveacutee plus le deacutebit binaire sera fort
Exemple Drsquoapregraves la formule du deacutebit binaire trouver le deacutebit pour les deux cas suivants
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
32 Coding Rate Le Coding Rate est un ratio qui augmentera le nombre de bits agrave transmettre afin de reacutealiser de la
deacutetection correction drsquoerreur Dans le cas drsquoun CR = 4 8 il y aura 8 bits transmis reacuteellement agrave
chaque fois que nous souhaitons transmettre 4 bits Dans cette exemple cela provoque une
transmission drsquoun nombre de bit multiplieacute par 2
SF7
Freacutequence
Temps
Freacutequence centrale
Freacutequence haute
Temps drsquoun symbole eacutemit en SF 12
Freacutequence basse
SF8
SF9
SF10
SF11
SF12
Temps drsquoun symbole eacutemit en SF 11
| 17
Figure 11 Influence du Coding Rate sur le nombre de bits ajouteacute
Si on reprend lrsquoexemple preacuteceacutedent avec un CR de 4 5 nous avons une augmentation de 125 du
nombre de bits agrave transmettre Redonner la deacutebit en prenant en compte le CR
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
La documentation du composant RN2483 donne les deacutebits en fonction du Spreading Factor
la Bande Passante et le Coding Rate Veacuterifier la coheacuterence du reacutesultat avec votre calcul
preacuteceacutedent
Figure 12 Deacutebit en fonction des paramegravetres de la transmission LoRa
33 Utilisation du LoRa Calculator Le logiciel laquo LoRa Calculator raquo est un petit exeacutecutable permettant de simuler une transmission LoRa
en fonction des caracteacuteristiques saisies Canal SF CR etchellip Il est teacuteleacutechargeable agrave lrsquoadresse
suivante httpsbitly2TyloAh
| 18
Figure 13 Le logiciel LoRa Calculator
En reprenant lrsquoexemple preacuteceacutedent (SF7 Bande Passante 125 kHz CR 45) veacuterifier les
calculs du laquo Equivalent Bitrate raquo
34 Time On Air La norme LoRaWAN impose qursquoun Device LoRa ne transmette pas plus de 1 du temps Cela est
repreacutesenteacute par un Duty Cycle Par exemple un Duty Cycle de 1 signifie que si jrsquoeacutemet pendant 1 je
ne dois plus eacutemettre pendant 99 quel que soit lrsquouniteacute de temps utiliseacutee
En reprenant les exemples preacuteceacutedents quels sont les deacutebits moyens si on prend en compte
le laquo Time On Air raquo
Cas 1 Pour SF7 et 125 khz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
Dans le logiciel laquo LoRa Calculator raquo (onglet laquo Energy Profile raquo) nous pouvons estimer la
dureacutee de vie drsquoune batterie Nous prenons lrsquoexemple drsquoun releveacute de tempeacuterature dans un
bacirctiment avec les caracteacuteristiques suivantes
| 19
SF CR Bande Passante etc Nous nous placcedilons dans le cas 1 des exemples preacuteceacutedents
Le releveacute de tempeacuterature se fera toutes les 15 mins
La batterie est constitueacute de 3 petites piles bacirctons [ AAA LR03 ] 12V en seacuterie Soit 36 V
1000 mAh
35 Mise en œuvre LoRa en point agrave point Ce test sera reacutealiseacute avec des modules LoRa RN2483 (Microchip) et une carte microcontrocircleur
ARDUINO
Figure 14 Communication LoRa en Point agrave Point
Reacutealiser le cacircblage de votre module RN2483 suivant le tableau suivant
Connecteur Arduino Click Board RN2483
5V 5V
GND GND
11 RX
10 TX
Tableau 4 Cacircblage de lrsquoARDUINO et de la click Board RN2483
351 Utilisation de lrsquoIDE Arduino Lrsquoenvironnement Arduino est tregraves simple Nous allons reacutealiser un programme pour montrer son
fonctionnement
La connexion de la carte est effectueacutee agrave lrsquoaide drsquoun port USB qui eacutemule une liaison seacuterie
RS232 Il faut donc choisir le bon port Arduino IDE gt Outils gt Port
Pour creacuteer un nouveau programme (sketch) Arduino IDE gt Fichier gt Nouveau
Il y a deux parties dans un sketch
Une fonction setup() qui sera exeacutecuteacutee qursquoune seule fois au deacutemarrage
Une fonction loop() qui sera exeacutecuteacutee en boucle
Ecrire le code suivant
Emetteur
Reacutecepteur
UA
RT
UA
RT
| 20
void setup()
Serialbegin(9600)
void loop()
Serialprintln(hello word)
Compiler et Teacuteleacuteverser Croquis gt Teacuteleacuteverser
Voir la sortie sur la liaison seacuterie Outils gt Moniteur Seacuterie gt Choisir la vitesse de
transmission ici 9600 bauds (en bas agrave droite)
352 Validation du fonctionnement Deux binocircmes joueront le rocircle drsquoeacutemetteur tous les autres binocircmes seront en reacutecepteur
Reacutecupeacuterer les programmes dans Moodle dans le dossier laquo RN2483-Arduino-Point2Point raquo
Installer la librairie RN2483 Arduino IDE gt Croquis gt Inclure une bibliothegraveque gt Ajouter la
bibliothegraveque zip
Reacutepartissez les rocircles Emetteurs Reacutecepteurs et reacutecupeacuterer le programme LoraBlinkerRX ou
LoraBlinkerTX en fonction Les 2 binocircmes en eacutemission devront modifier le code du sketch
Arduino pour transmettre des donneacutees speacutecifiques afin de les diffeacuterencier [
loraSerialprintln(radio tx 30) ]
Validez la reacuteception des donneacutees eacutemises par les deux binocircmes qui transmettent des
donneacutees Ces donneacutees reccedilues sont eacutecrite agrave 57600 bauds sur le moniteur seacuterie de lrsquoArduino
353 Mise en valeur du Spreading Factor On srsquoaperccediloit dans la manipulation preacuteceacutedente que les Devices LoRa reccediloivent les donneacutees des deux
eacutemetteurs Nous allons conserver le mecircme canal drsquoeacutemission (8691 Mhz) mais un des deux
eacutemetteurs va modifier son laquo Spreading Factor raquo La salle sera donc seacutepareacutee en deux groupes
1er groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF7
2egraveme groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF8
Validez la reacuteception des donneacutees eacutemises seulement pour le Spreading Factor que vous
utilisez
| 21
4 Le protocole LoRaWAN
Le LoRa est le type de modulation utiliseacute entre deux Devices ou entre un Device et une Gateway
Lorsque nous parlons de lrsquoensemble de la chaine de communication (Device Gateway Serveur) alors
nous parlons de communication LoRaWAN Nous allons voir lrsquoarchitecture drsquoun reacuteseau LoRaWAN
ainsi que les regravegles de ce protocole
41 Structure drsquoun reacuteseau LoRaWAN Nous retrouvons drsquoun cocircteacute le Device LoRa qui transmet une donneacutee Elle est reacuteceptionneacutee agrave lrsquoautre
extreacutemiteacute du reacuteseau par un Utilisateur La structure globale du reacuteseau LoRaWAN peut ecirctre
repreacutesenteacutee par la figure suivante
411 Les Devices LoRa Les Devices LoRa sont des systegravemes eacutelectroniques appartenant au monde de lrsquoIoT Faible
consommation faible taille faible puissance et faible taille
Ils possegravedent une radio LoRa permettant de joindre les Gateways Les Gateways ne sont pas
adresseacutees speacutecifiquement toutes celles preacutesentes dans la zone de couverture reccediloivent les
messages et les traitent
412 Les Gateways LoRa Elles eacutecoutent sur tous les canaux et sur tous les Spreading Factor Lorsqursquoune trame LoRa est reccedilue
elle transmet son contenu sur internet agrave destination du Network Server qui a eacuteteacute configureacute dans la
Gateway au preacutealable
Elle joue donc le rocircle de passerelle entre une modulation LoRa et une communication IP
Devices
LoRa Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
Internet Internet
Figure 15 Structure globale dun reacuteseau LORAWAN
| 22
Chaque Gateway LoRa possegravede un identifiant unique (EUI sur 64 bits)
413 Le Network Server
Le Network Server reccediloit les messages transmis par les Gateways et supprime les doublons
(plusieurs Gateway peuvent avoir reccedilu le mecircme message) Les informations transmises au Network
Server depuis les Devices LoRa sont authentifieacutes gracircce agrave une cleacute AES 128 bits appeleacutee Network
Session Key NwkSKey Nous parlons bien ici drsquoauthentification et non pas de chiffrement comme
nous le verrons plus tard
414 Application Server Il est souvent sur le mecircme support physique que le Network Server Il permet de dissocier les
applications les unes des autres Chaque application enregistre des Devices LoRa qui auront le droit
Devices Gateways Network
Server
Internet
Network Session Key (NwkSKey)
Authentification
Figure 17 Authentification entre le Device LoRa et le Network Server
Internet
UDP IP
Modulation
LoRa
Device LoRa
Gateway
Network Server
LoRaWAN
Modulation
LoRa
Passerelle LoRa Internet
Internet
UDP IP
LoRaWAN
Transmission Radio
Application Application
Figure 16 Le rocircle de la Gateway LoRa
| 23
de stocker leurs donneacutees (Frame Payload) Les message transmis agrave lrsquoapplication server sont chiffreacutes
gracircce agrave une cleacute AES 128 bits appeleacutee Application Session Key AppSKey
Le scheacutema suivant reacutesume lrsquoutilisation
De la Network Session Key (NwkSKey) pour lrsquoauthentification entre le Device LoRa et le
Network Server
De lrsquoApplication Session Key (AppSKey) pour le chiffrement entre le Device LoRa et
lrsquoApplication Server
Devices Gateways Network
Server Application
Server
Internet
Application Session Key (AppSKey)
Chiffrement
Figure 18 Chiffrement entre le Device LORA et lrsquoApplication Server
| 24
415 Application Web Serveur Cette application doit drsquoune part reacutecupeacuterer les donneacutees de lrsquoApplication Serveur Dans le cadre de
ce cours cela sera fait de deux faccedilons
Avec le protocole HTTP
Avec le protocole MQTT
Figure 20 Application Web Server
Figure 19 Authentification et chiffrement en LoRaWan
Devices Gateways
Network
Server Application
Server
Internet
Network Session Key
Application Session Key
Network
Server Application
Server
Application
Server Web
Utilisateur
Protocole
MQTT ou HTTP
Flux Uplink
Flux Downlink
| 25
Le flux habituel dans lrsquoIoT est le flux Uplink (flux montant) crsquoest-agrave-dire lrsquoeacutemission de donneacutees des
objets vers le serveur Comme nous lrsquoexpliquerons plus loin en LoRaWAN il est aussi possible de
transfeacuterer des donneacutees aux Device LoRa par un flux Downlink (flux descendant)
Drsquoautre part lrsquoapplication mettra agrave disposition les donneacutees aux utilisateurs sous forme par exemple
drsquoun serveur web drsquoune base de donneacutees et drsquoune visualisation graphique
416 Authentification avec le Network Server La Network Session Key (NwkSKey) sert agrave lrsquoauthentification entre le Device LoRa e le Network Server
Afin de reacutealiser cette authentification entre le Device et le Network Server un champ MIC (Message
Integrity Control) est rajouteacute agrave la trame Il est calculeacute en fonction des donneacutees transmises et du
NwkSkey A la reacuteception le mecircme calcul est effectueacute Si les cleacutes sont eacutequivalentes dans le Device et
dans le Network Server alors les deux MIC calculeacutes doivent correspondre
417 Chiffrement des donneacutees vers lrsquoApplication Server
LrsquoApplication Session Key (AppSKey) sert pour le chiffrement entre le Device LoRa et lrsquoApplication
Server Les donneacutees chiffreacutees seront alors deacutecodeacutees agrave la reacuteception sur lrsquoApplication Server srsquoil
possegravede la mecircme cleacute Si on reprend le scheacutema preacuteceacutedent les laquo donneacutees x raquo sont chiffreacutees
deacutechiffreacutees par le processus suivant
Donneacutees x chiffreacutees NwkSkey x
MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees
NwkSkey x
Trame eacutemise Trame reccedilue
Device LoRa Network Server
Si =
Alors la trame est authentifieacutee
MIC geacuteneacutereacute Emission MIC geacuteneacutereacute Reacuteception
MIC geacuteneacutereacute Reacuteception
Figure 21 Authentification dun Device LoRa par le Network Server
| 26
Figure 22 Chiffrement des donneacutees par lApplication Session Key
418 Combinaison de lrsquoauthentification et du chiffrement On peut maintenant repreacutesenter sur le mecircme scheacutema la construction de la trame LoRaWAN avec
drsquoune part lrsquoauthentification et drsquoautre part le chiffrement
Figure 23 Chiffrement puis Authentification
42 Classes des Devices LoRaWAN Les Devices LoRa sont classeacutes en 3 cateacutegories (A B C) en fonction de leur consommation et de leur
accessibiliteacute en Downlink crsquoest-agrave-dire la faciliteacute qursquoun utilisateur aura agrave transmettre une trame au
Device LoRa
421 Classe A (All) Minimal power Application Tous les Devices LoRaWAN sont de classe A Chaque Device peut transmettre (Uplink) agrave la Gateway
sans veacuterification de la disponibiliteacute du reacutecepteur Si la transmission eacutechoue elle sera reacuteeacutemise apregraves
un certain temps Cette transmission est suivie de 2 fenecirctres de reacuteception tregraves courtes La Gateway
peut alors transmettre pendant le laquo RX Slot 1 raquo ou le laquo RX Slot 2 raquo mais pas les deux
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Device LoRa
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Application Server
Donneacutees non chiffreacutees
AppSKey
Donneacutees chiffreacutees Entecircte
NwkSKey
MIC geacuteneacutereacute en eacutemission Trame transmise =
| 27
Figure 24 Slots de reacuteception pour un Device LoRa de classe A
Source de lrsquoimage httpszakelijkforumkpncom
La dureacutee des fenecirctres doit ecirctre au minimum la dureacutee de reacuteception drsquoun preacuteambule Un preacuteambule
dure 1225 Tsymbole et deacutepend donc du Data Rate (DR voir paragraphe 445 pour plus drsquoinformation
sur le DR) Lorsque qursquoun preacuteambule est deacutetecteacute le reacutecepteur doit rester actif jusqursquoagrave la fin de la
transmission Si la trame reccedilue pendant la premiegravere fenecirctre de reacuteception eacutetait bien agrave destination du
Device LoRa alors la deuxiegraveme fenecirctre nrsquoest pas ouverte
Premiegravere fenecirctre de reacuteception
Le Slot RX1 est programmeacute par deacutefaut agrave 1 seconde + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont les mecircme que ceux choisis lors de la phase drsquoeacutemission
(Uplink)
Seconde fenecirctre de reacuteception
Le Slot RX2 est programmeacute par deacutefaut agrave 2 secondes + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont configurables mais fixes
Un Device LoRa qui est uniquement de classe A ne peut pas recevoir srsquoil nrsquoa pas eacutemis Il
nrsquoest donc pas joignable facilement
422 Classe B (Beacon) Scheduled Receive Slot Les Devices de classe B ont le mecircme comportement que les Devices de classe A mais drsquoautres
fenecirctres de reacuteceptions sont programmeacutees agrave des peacuteriodes preacutecises Afin de synchroniser les fenecirctres
de reacuteception du Device LoRa la Gateway doit transmettre des balises (Beacons) de faccedilon reacuteguliegravere
| 28
Figure 25 Slots de reacuteception pour un Device LoRa de classe B
Source de lrsquoimage httpszakelijkforumkpncom
Un Device LoRa de classe B est joignable reacuteguliegraverement sans qursquoil soit neacutecessairement
obligeacute drsquoeacutemettre En revanche il consomme plus qursquoun Device de classe A
423 Classe C (Continuous) Continuously Listening Les Devices de classe C ont des fenecirctres de reacuteception constamment ouvertes entre 2 Uplinks Ces
Devices consomment donc beaucoup plus
Figure 26 Slots de reacuteception pour un Device LoRa de classe C
Source de lrsquoimage httpszakelijkforumkpncom
| 29
Un Device LoRa de classe C est joignable en permanence En revanche crsquoest la classe de
Device qui est la plus eacutenergivore
424 Quelle Gateway pour les flux Downlink
Nous avons donc vu que le fonctionnement classique du protocole LoRaWAN eacutetait de reacutecupeacuterer de
lrsquoinformation depuis le Device LoRa Crsquoest le flux Uplink
Dans le cas ougrave lrsquoutilisateur transmet des informations au Device LoRa (flux Downlink) on peut se
demander quelle Gateway sera choisie pour transfeacuterer les donneacutees au Device LoRa En effet
lrsquoendroit ougrave est situeacute le Device LoRa nrsquoest pas neacutecessairement connu agrave lrsquoavance
La Gateway utiliseacutee pour le Downlink est celle qui a reccedilu le dernier message du Device
LoRa Un message ne pourra jamais arriver agrave destination drsquoun Device LoRa si celui-ci nrsquoa
jamais transmis quel que soit sa classe A B ou C
43 Activation des Devices LoRa et seacutecuriteacute En LoRaWAN les trois eacuteleacutements indispensables pour la communication sont le DevAddr pour
lrsquoindentification du Device ainsi que deux cleacutes le NwkSKey pour lrsquoauthentification et lrsquoAppSKey
pour le chiffrement Deux meacutethodes sont possibles pour fournir ces informations agrave la fois au Device
LoRa et au serveur
Activation By Personalization APB
Over The Air Activation
431 ABP Activation By Personalization Crsquoest la plus simple des meacutethodes Crsquoest donc peut ecirctre celle que nous avons tendance agrave utiliser lors
drsquoun test de prototype et drsquoune mise en place de communication LoRaWAN
Le Device LoRa possegravede deacutejagrave le DevAddr lrsquoAppSKey et le NwkSKey
Le Network server possegravede deacutejagrave le DevAddr et le NwkSKey
Lrsquoapplication serveur possegravede deacutejagrave le DevAddr et le AppSKey
En ABP toutes les informations neacutecessaires agrave la communication sont deacutejagrave connues par le
Device LoRa et par le Serveur
| 30
432 OTAA Over The Air Activation Crsquoest la meacutethode qursquoil faut privileacutegier car crsquoest celle qui est la plus seacutecuriseacutee Le Device LoRa doit
connaitre le DevEUI lrsquoAppEUI et lrsquoAppkey Le Network Server doit lui connaitre la mecircme Appkey
Tous les eacuteleacutements noteacutes EUI (Extended Unique Identifier) sont toujours sur une taille de
64 bits
Gracircce agrave ces informations de deacutepart et une neacutegociation avec le Network Server (Join Request) le
Device LoRa et le serveur vont geacuteneacuterer les informations essentielles DevAddr NwkSKey et
AppSKey
Figure 28 Obtention du DevAddr NwkSKey et AppSKey en OTAA
DevEUI Unique Identifier pour le device LoRa (Equivalent agrave une MAC sur Ethernet)
Certains Device LoRa ont deacutejagrave un DevEUI fourni en usine
AppEUI Unique Identifier pour lrsquoapplication server
DevEUI
AppEUI
AppKey
Join
Request
DevAddr
NwkSKey
AppSKey
Network Server
Application Server
Devices 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 2
NwkSkey 2
AppSKey 2
Devices 2
DevAddr 2
NwkSkey 2
AppSKey 2
Paramegravetres stockeacutes sur le serveur
Paramegravetres programmeacutes
dans le composant
Figure 27 Parameacutetrage de DevAddr NwkSKey et AppSKey
| 31
AppKey AES 128 cleacute utiliseacutee pour geacuteneacuterer le MIC (Message Code Integrity) lors de la Join
Resquest Il est partageacute avec le Network server
NwkSKey Utiliseacute pour lrsquoauthentification avec le Network Server
AppSKey Utiliseacute pour le chiffrement des donneacutees
433 Seacutecuriteacute Les cleacutes AES 128 bits permettent le chiffrement des informations transmises en LoRaWAN Malgreacute
ce chiffrement une attaque connue en Wireless est celle du REPLAY Crsquoest-agrave-dire que le Hacker
enregistre des trames chiffreacutees circulant sur le reacuteseau LoRa pour les reacuteeacutemettre plus tard Mecircme si
le Hacker ne comprend pas le contenu (les trames sont chiffreacutees) les donneacutees qui sont transporteacutees
sont elles bien comprises par lrsquoApplication Server Des actions peuvent donc ecirctre reacutealiseacutees
simplement par mimeacutetisme
Pour eacuteviter cela la trame LoRaWAN integravegre un champ variable appeleacute laquo Frame Counter raquo Il srsquoagit
drsquoun nombre numeacuterotant la trame sur 16 ou 32 bits LrsquoApplication Server acceptera une trame
uniquement si le laquo Frame Counter raquo reccedilu est supeacuterieur au laquoFrame Counter raquo preacuteceacutedemment Donc
si le Hacker retransmet la trame telle qursquoelle le laquo Frame Counter raquo sera eacutequivalent donc la trame
sera refuseacutee Et comme la trame est chiffreacutee le Hacker nrsquoa pas moyen de savoir comment modifier
un champ de cette trame
Cette seacutecuriteacute impleacutementeacutee par les laquo Frame Counter raquo est inteacuteressante pour srsquoaffranchir drsquoune
attaque par REPLAY mais dans nos tests cela peut poser problegraveme En effet agrave chaque fois que nous
redeacutemarrons le microcontrocircleur notre laquo Frame Counter raquo revient agrave zeacutero alors que celui de
lrsquoApplication Server continue de srsquoincreacutementer Cela peut ecirctre reacutesolue par diffeacuterentes maniegraveres
1 Deacutesactivation du laquo Frame Counter Check raquo Dans certain Application Server cette option
peut ecirctre proposeacutee Bien sucircr il faudra garder en tecircte la faille de seacutecuriteacute que cela engendre
Network Server
Application Server
Devices LoRa
NwkSkey
AppSKey
NwkSkey
AppSKey Hacker
(1) (2)
(1) Ecoute
(2) Reacuteeacutemission
Figure 29 Attaque par REPLAY
| 32
Figure 30 Deacutesactivation du Frame Counter Check dans TTN
2 Utiliser lrsquoauthentification par OTAA au lieu de ABP En effet agrave chaque ouverture de session
en OTAA le laquo Frame Counter raquo est reacuteinitialiseacute coteacute serveur
3 Conserver la valeur du laquo Frame Counter raquo dans une meacutemoire non volatile et reacutecupeacuterer sa
valeur au deacutemarrage du Device LoRa
44 La Trame LoRa LoRaWAN
441 Les couches du protocole LoRaWAN
Lorsque nous avons fait une communication en Point agrave Point nous avons simplement utiliseacute la
couche physique de la modulation LoRa Lorsque nous souhaitons utiliser le protocole LoRaWAN
des couches protocolaires suppleacutementaires se rajoutent
Figure 31 Les couches protocolaires du LoRaWAN
Chaque couche rajoute un service Lors de lrsquoenvoi de la trame les donneacutees utilisateurs sont donc
encapsuleacutees dans chaque couche infeacuterieure jusqursquoagrave la transmission Le deacutetail de lrsquoensemble de la
trame LoRaWAN par couche est deacutecrit sur la figure Figure 32
LoRa Modulation
LoRa Mac
Application
Couche Physique
Couche Mac
Couche Application
| 33
442 Couche Application La couche Application accueille les donneacutees de lrsquoutilisateur Avant de les encapsuler elles sont
chiffreacutees avec lrsquoAppSKey afin de seacutecuriser la transaction
Un ensemble de champs nommeacute Frame Header permet de speacutecifier le DevAddr le Frame Control
le Frame Counter et le Frame Option
Le Frame Port deacutepend du type drsquoapplication et sera choisi par lrsquoutilisateur
Le Frame Payload sont les donneacutees chiffreacutees agrave transmettre Le nombre drsquooctets maximum pouvant
ecirctre transmis (N octets) est donneacute dans le tableau suivant
PHY Payload
P octets Couche
Physique
Couche
Mac
Couche
Application
CRC
2 octets Header + Header CRC
20 bits Preamble
MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Figure 32 Trame LORAWAN complegravete par couche protocolaire
Couche
Application Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Frame Header
Figure 33 Trame LORA couche Applicative
| 34
Data Rate Spreading Factor Bandwidth Max Frame Payload (Nombre N) DR 0 SF12 125 KHz 51 octets
DR 1 SF11 125 KHz 51 octets
DR 2 SF10 125 KHz 51 octets
DR 3 SF9 125 KHz 115 octets
DR 4 SF8 125 KHz 222 octets
DR 5 SF7 125 KHz 222 octets
DR 6 SF7 250 KHz 222 octets
Tableau 5 Taille maximum du Frame Payload en fonction du Data Rate
443 Couche LoRa MAC Cette trame est destineacutee au Network Server Elle est authentifieacutee gracircce au champ MIC (Message
Integrity Protocol) selon la meacutethode expliqueacutee au paragraphe 416
Le protocole LoRa MAC est composeacute de
1 MAC Header Version de protocole et type de message
Type de Message Description 000 Join-Request
001 Join-Accept
010 Unconfirmed Data Up
011 Unconfirmed Data Down
100 Confirmed Data Up
101 Confirmed Data Down
110 Rejoin-request
111 Proprietary
Tableau 6 Les types de messages transmis en LoRaWAN
2 MAC Payload Contient tout le protocole applicatif
3 MIC Message Integrity Code pour lrsquoauthentification de la trame
444 Couche physique Modulation LoRa
Le choix du moment drsquoeacutemission des Devices LoRa se fait de faccedilon simple Lorsqursquoun eacutequipement
doit eacutemettre il le fait sans controcircle et ne cherche pas agrave savoir si le canal est libre Si le paquet a eacuteteacute
perdu il le retransmettra simplement au bout drsquoun temps aleacuteatoire La couche physique est
repreacutesenteacutee par lrsquoeacutemission de la trame suivante
Couche
Mac MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Figure 34 Trame LORA couche LORA MAC
| 35
Le Preacuteambule est repreacutesenteacute par 8 symboles + 425 Le temps du Preacuteambule est donc de 1225
Tsymbole
Len-tecircte (Header optionnel) est seulement preacutesent dans le mode de transmission par deacutefaut
(explicite) il est transmis avec un Coding Rate de 48 Il indique la taille des donneacutees le Coding Rate
pour le reste de la trame et il preacutecise eacutegalement si un CRC sera preacutesent en fin de trame
Le PHY Payload contient toutes les informations de la Couche LoRa MAC
Le CRC sert agrave la deacutetection drsquoerreur de la trame LoRa
445 Canaux et bandes de freacutequences et Data Rate (DR) Le LoRa utilise des bandes de freacutequences diffeacuterentes suivant les reacutegions du monde En Europe la
bande utiliseacutee est celle des 868 Mhz [ De 863 Mhz agrave 870 Mhz ] Le LoRaWAN deacutefinie les 8 canaux agrave
utiliser pour communiquer avec une Gateway suivant le tableau suivant
Canaux Spreading Factor Bandwidth 8681 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz SF7 250 kHz
8685 Mhz De SF7 agrave SF12 125 kHz
8671 Mhz De SF7 agrave SF12 125 kHz
8673 Mhz De SF7 agrave SF12 125 kHz
8675 Mhz De SF7 agrave SF12 125 kHz
8677 Mhz De SF7 agrave SF12 125 kHz
8679 Mhz De SF7 agrave SF12 125 kHz
Tableau 7 Canaux SF et Bandwidth de notre Gateway LoRaWAN
Une Gateway LoRa eacutecoute donc sur 8 canaux simultaneacutement avec les 6 Spreading Factor
diffeacuterents soit 48 combinaisons possibles
Comme nous lrsquoavons vu le Spreading Factor a des conseacutequences sur le deacutebit de la transmission Ces
deacutebits sont noteacutes DR (Data Rate) et sont normaliseacutes de DR0 agrave DR6
PHY Payload
P octets Couche
Physique CRC
2 octets Header + Header CRC
( Optionnel ) 20 bits Preamble
Figure 35 Trame LORA couche Physique
| 36
Data Rate Spreading Factor Bandwidth DR 0 SF12 125 KHz
DR 1 SF11 125 KHz
DR 2 SF10 125 KHz
DR 3 SF9 125 KHz
DR 4 SF8 125 KHz
DR 5 SF7 125 KHz
DR 6 SF7 250 KHz
Tableau 8 Deacutenomination DR en fonction du SF et de la Bande Passante
446 Trame reccedilue et transmise par la Gateway LoRaWAN La Gateway reccediloit drsquoun cocircteacute un message radio moduleacute en LoRa et transmet de lrsquoautre cocircteacute une trame
IP agrave destination du Network Server
Coteacute interface Radio La Gateway reacuteceptionne une trame LoRaWAN et extrait le PHY Payload Celui-
ci est codeacute au format ASCII en base 64 (voir le paragraphe 541) La Gateway extrait aussi toutes les
informations utiles sur les caracteacuteristiques de la reacuteception qui a eu lieu SF Bandwidth RSSI Time
On Airhellipetchellip
Coteacute interface reacuteseau IP La Gateway transmet lrsquoensemble de ces informations dans un paquet IP
(UDP) au Network Server Les donneacutees transmises sont du texte en format JSON (voir paragraphe
447) La Gateway a donc bien un rocircle de passerelle entre le protocole LoRa drsquoun cocircteacute et un reacuteseau
IP de lrsquoautre
Internet
UDP IP
Device LoRa
Gateway
Network Server Modulation
LoRa
Passerelle LoRa Internet
Transmission Radio Internet
Figure 36 Rocircle de la Gateway LoRa
| 37
447 Le format JSON Le format JSON est un format texte composeacute drsquoune succession de couple nomvaleur Dans
lrsquoexemple de la figure preacuteceacutedente gw_id est un nom et eui-b827ebfffeae26f5 est la valeur
associeacutee Dans cette exemple la valeur est un string Les objets sont deacutelimiteacutes par un des accolades
et
Une valeur peut ecirctre
Un string exemple coding_rate 45
Un nombre exemple spreading_factor 12
Un objet exemple lora spreading_factor 12 air_time 2465792000
Un Boolean
Ethernet
Gateway
Modulation
LORA
Reacutecupeacuteration du PHY PAYLOAD en base 64
Reacutecupeacuteration des caracteacuteristiques de la transmission Canal SF CR hellip
IP (IP dest routereuthethingsnetwork)
UDP (Port dest 1700 Port source 1700)
Donneacutees applicatives (format JSON)
gw_id eui-b827ebfffeae26f5
payload QNAPvA6Ax3ECqHk4C8hfzuA==
lora
spreading_factor 12
bandwidth 125
air_time 2465792000
coding_rate 45
timestamp 2019-01-20T133746017Z
rssi -105
snr -162
dev_addr 0EBC0FD0
frequency 867100000
Internet Transmission Radio LORA
Figure 37 Passerelle (Gateway) LORAWAN
| 38
5 Mise en œuvre drsquoun reacuteseau LoRaWAN
51 Les diffeacuterents types de reacuteseaux Les reacuteseaux LoRaWAN peuvent ecirctre utiliseacute suivant deux meacutethodes
En utilisant les reacuteseaux LoRaWAN opeacutereacutes proposeacutes par les opeacuterateurs de teacuteleacutecoms
En utilisant votre propre reacuteseau LoRaWAN priveacute
511 Les reacuteseaux LoRaWAN opeacutereacutes Ce sont des reacuteseaux LoRaWAN proposeacutes par les opeacuterateurs Par exemple Objenious (filiale de
Bouyges) ou encore Orange Dans le cas de lrsquoutilisation des reacuteseaux opeacutereacutes lrsquoutilisateur a juste
besoin de srsquooccuper des Devices LoRa Les Gateways le Network Server et lrsquoApplication Server sont
geacutereacutes par lrsquoopeacuterateur
512 Les reacuteseaux LoRaWAN priveacutes Chacun est libre de reacutealiser son propre reacuteseau priveacute en impleacutementant sa propre Gateway pour
communiquer avec ses Devices LoRa Lrsquoimpleacutementation du Network Server et de lrsquoApplication Server
peuvent alors ecirctre envisageacutes de diffeacuterentes faccedilons
Network Server et Application serveur priveacutees Crsquoest le deacuteveloppeur qui les mets en place Dans
certaines Gateways une impleacutementation de ces deux serveurs est deacutejagrave proposeacutee Sinon il est
possible de la mettre en place Il existe des serveurs (Network et Application) open source crsquoest le
cas par exemple de LoRa Serveur [ wwwloraserverio ]
Une autre alternantive est httpsgithubcomgotthardplorawan-server
LoRaServer et lorawan-server sont deux applications Open Source
Network Server et Application Server en ligne Un certain nombre de Network Server et
drsquoApplication Server sont proposeacutes Ce sont des services payants ou avec des contreparties
Loriot [ wwwloriotio ]
ResIoT [ wwwresiotio ]
The Things Network [ wwwthethingsnetworkorg ] Crsquoest la solution que nous utiliserons
513 Les zones de couvertures
Les zones de couvertures des reacuteseaux opeacutereacutes sont mise agrave jour par les opeacuterateurs celle drsquoobjenious
est par exemple disponible ici httpsobjeniouscomreseau
Pour connaitre la zone de couverture de notre Gateway utiliseacutee avec TTN nous pouvons utiliser
lrsquoapplication TTN Mapper httpsttnmapperorg Lrsquoideacutee est de promener son Device LoRa associeacute
agrave un GPS dans la zone de couverture des Gateway qui nous entourent A chaque trame reccedilue par le
| 39
Serveur on note les coordonneacutees GPS du Device LoRa ainsi que la Gateway qui a transmis le
message Toutes ces informations sont alors retranscrites sur une carte
52 The Things Network (TTN)
521 Preacutesentation de TTN
Pour la suite nous utiliserons le Network Server et lrsquoApplication Server fourni par TTN
[wwwthethingsnetworkorg]
TTN est gratuit et Open Source En revanche le fait drsquoutiliser TTN impose agrave ceux qui enregistrent
des Gateways de les mettre agrave disposition agrave tous les autres utilisateurs de TTN Lrsquoobjectif est de
reacutealiser un reacuteseau global ouvert
522 Configuration de la Gateway A lrsquouniversiteacute nous avons deux Gateways LoRa (Marque EBDS) Elles sont toutes les deux situeacutees sur
le Campus de Technolac Une Gateway est agrave lrsquointeacuterieur du bacirctiment ISERAN et sert essentiellement
pour les Travaux Pratiques et formations Lrsquoautre est sur le toit du bacirctiment Chablais et est mise agrave
disposition du public via le service de TTN
Les deux Gateway eacutecoutent sur tous les canaux et sur tous les Spreading Factor SF7 gt SF12
Lrsquo IP de la Gateway LoRa agrave lrsquouniversiteacute (bacirctiment ISERAN) est 192168140196
Serveur DNS 1934812032 19348129137
Network Server (TTN) 137616868 routereuthethingsnetwork
Port Upstream 1700 Port Downstream 1700
523 Enregistrement des Gateways Appplication et Devices La configuration de TTN se fait en ligne La premiegravere opeacuteration agrave reacutealiser lorsqursquoune nouvelle
Gateway est deacuteployeacutee crsquoest de lrsquoenregistrer dans TTN
Enregistrement drsquoune Gateway LoRa TTN gt Console gt Gateway gt register gateway
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Figure 38 Scheacutema de notre application
| 40
Figure 39 Enregistrement dune Gateway LoRa sur TTN
Enregistrement drsquoune application TTN gt Console gt Application gt add application
Figure 40 Enregistrement dune application sur TTN
Enregistrement des Devices LoRa dans lrsquoapplication Nom de lrsquoapplication gt register device
Figure 41 Enregistrement des Devices LoRa dans une application
524 Configuration des Devices LoRa Lorsque nous avons enregistreacute des Devices LoRa dans TTN nous devons choisir entre les deux modes
drsquoauthentification Dans un premier temps nous utiliserons le mode le plus simple qui est ABP Nous
geacuteneacuterons dans TTN les DevAddr NetwkSKey et AppSKey
| 41
Figure 42 Configuration des Devices LoRa en ABP dans TTN
53 Mise en application Nous avons dans notre application 10 Devices LoRa drsquoenregistreacutes aduino0 agrave arduino9 Ils sont tous
configureacutes en ABP Les configurations des 10 Devices (DevAddr NetwkSKey et AppSKey) sont noteacutes
en commentaire dans le code de vous allez reacutecupeacuterer
Reacutecupeacuterer le code Arduino laquo RN2483-Arduino-LORAWANino raquo dans Moodle
Modifier votre configuration (DevAddr NetwkSKey et AppSKey) en fonction de votre
numeacutero de binocircme
Veacuterifier que votre Device LoRa arrive bien agrave transmettre des informations (Uplink) vers la
Gateway puis vers le Network Serveur de TTN (The Things Network)
54 Analyse des trames eacutechangeacutees
541 Utilisation de la base 64 Notre Gateway nous preacutesente le Payload PHY en base64 Lrsquoexplication de la meacutethode de
repreacutesentation en base 64 est fourni au travers drsquoun exemple Le code hexadeacutecimal 0x4869
repreacutesente nos donneacutees binaires que nous souhaitons transmettre en base 64
1 On eacutecrit les donneacutees agrave transmettre en binaire
2 On regroupe les eacuteleacutements binaires par des blocs de 6 bits Le nombre de bloc de 6 bits doit
ecirctre un multiple de 4 (minimum 4 blocs) Srsquoil manque des bits pour constituer un groupe de
6 bits on rajoute des zeacuteros
0x4869 = 0100 1000 0110 1001
| 42
3 Srsquoil manque des blocs pour faire un minimum de 4 blocs des caractegraveres speacuteciaux seront
ajouteacutes
4 Chaque groupe de 6 bits est traduit par le tableau suivant (Source Wikipeacutedia)
Figure 43 Codage en base 64
5 Si un bloc de 6 bits manque (ils doivent ecirctre un multiple de 4) on rajoute un ou plusieurs
compleacutements (caractegravere laquo = raquo )
Reacutesultat Le codage de 0x4869 en base 64 est laquo SGk= raquo
010010 000110 100100
On ajoute 00 pour avoir
6 bits dans le groupe
Bloc de 6 bits
010010 000110 100100
S G k
010010 000110 100100
S G k =
1er Bloc
2egraveme Bloc
3egraveme Bloc
4egraveme Bloc
| 43
542 Inteacuterecirct et inconveacutenient de la base 64 Lrsquoutilisation de la base 64 est un choix qui a eacuteteacute fait pour le protocole LoRa LoRaWAN afin de rendre
les donneacutees binaires lisibles Le problegraveme du code ASCII crsquoest qursquoil est composeacute drsquoun certain nombre
de caractegraveres non imprimables (EOF CR LFhellip) Pour eacuteviter ces soucis la base 64 ne comporte que
64 caractegraveres imprimables (voir tableau ci-dessus)
La restriction agrave 64 caractegraveres a cependant un inconveacutenient crsquoest que nous ne pouvons coder que 6
bits (26=64) au lieu de 8 La base 64 est donc moins efficace drsquoune faccedilon geacuteneacuterale
Nous cherchons agrave coder le code ASCII laquo AA raquo en base 64 Retrouver la deacutemarche en
montrant que le reacutesultat en base 64 est laquo QUE= raquo
543 Uplink Du Device LoRa au Network Server Le Network Server de TTN reccediloit des trames IP en provenance de la Gateway Comme nous lrsquoavons
vu preacuteceacutedemment un certain nombre drsquoinformations peuvent ecirctre retrouveacutees avec cette trame
(DevAddr SF Bandwidth etchellip) mais les donneacutees Applicatives sont bien sucircr chiffreacutees (avec
lrsquoAppkSKey) A ce niveau de reacuteception (sans connaitre lrsquoAppSKey) il nrsquoest donc pas possible de
comprendre la totaliteacute du message reccedilu
Imaginons que la trame IP reccedilue 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 45
timestamp 2019-03-05T140042448Z
rssi -82
snr 9
dev_addr 26011AD3
frequency 867300000
Le Network Server affiche donc les informations de la faccedilon suivante
Figure 44 Trame reacutecupeacutereacutee sur le laquo Network Server raquo de TTN
Nous retrouvons bien les valeurs fournies par la Gateway
timestamp ( agrave 1 heure pregraves en fonction du fuseau horaire)
| 44
frequency 8673 Mhz
modulation Lora
Coding Rate 45
data Rate SF 7 125 kHz (DR5)
air time 463 ms
Drsquoautres information proviennent de lrsquoanalyse du Payload Le Payload inscrit ici est le PHY Payload
Il y a donc une partie chiffreacutee (Frame Payload) mais les entecirctes sont en claires (voir paragraphe
441) Ce PHY Payload est laquo QNMaASYABwAP1obuUHQ= raquo Lorsque celui-ci est exprimeacute en
hexadeacutecimal au lieu de la base 64 il vaut laquo 40D31A01260007000FD686EE5074 raquo comme le montre
le Network Server de TTN
Figure 45 PHY Payload preacutesenteacute dans notre Network Server
Sa taille est bien de 14 octets (en hexadeacutecimal) comme preacuteciseacute sur la Figure 44
Nous reprenons le format de la trame LoRaWAN vu agrave la Figure 32 Nous pouvons alors retrouver
tous les champs de toute la trame
PHYPayload = 40D31A01260007000FD686EE5074
PHYPayload = MAC Header[1 octet] | MACPayload[] | MIC[4 octets]
MAC Header = 40 (Unconfirmed data up)
MACPayload = D31A01260007000FD6
Message Integrity Code = 86EE5074
MACPayload = Frame Header | Frame Port | FramePayload )
Frame Header = D31A0126000700
FPort = 0F
FramePayload = D6
Frame Header = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[015]
DevAddr = 26011AD3 (Big Endian)
FCtrl (Frame Control) = 00 (No ACK No ADR)
FCnt (Frame Counter) = 0007 (Big Endian)
FOpts (Frame Option) =
Vous pouvez veacuterifier lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN
(LoRaWAN packet decoder) httpsbitly2szdXtv
| 45
Figure 46 LoRaWAN packet decoder
544 Uplink Du Network Server agrave lrsquoApplication Server
Nous reprenons lrsquoexemple de la trame ci-dessus (Figure 45) Pour information les cleacutes NwkSKey et
AppSKey suivantes ont eacuteteacute utiliseacutee
NwkSKey E3D90AFBC36AD479552EFEA2CDA937B9
AppSKey F0BC25E9E554B9646F208E1A8E3C7B24
Le Network Server a deacutecodeacute lrsquoensemble de la trame Si le MIC est correct (authentification de la
trame par le NwkSKey) alors le Network Server va passer le contenu du message chiffreacute (Frame
Payload) agrave lrsquoApplication Server Dans notre cas le Frame Payload est (drsquoapregraves le deacutecodage effectueacute
au chapitre preacuteceacutedent)
FramePayload = D6
D6 est le contenu chiffreacute lorsqursquoil est deacutechiffreacute avec lrsquoAppSkey on trouve 01 Vous pouvez veacuterifier
lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN httpsbitly2szdXtv
A noter que lrsquoApplication Server recevra les donneacutees chiffreacutees seulement si le Device LoRa a bien
eacuteteacute enregistreacute On peut aussi veacuterifier ci-dessous que lrsquoApplication Serveur de TTN nous retourne bien
un payload (Frame Payload) de 01
Figure 47 Trame reacutecupeacutereacutee sur lrsquoApplication Server de TTN
time 2019-03-05T140042379279991Z
frequency 8673
modulation LORA
data_rate SF7BW125
coding_rate 45
gateways [
gtw_id eui-b827ebfffeae26f6
timestamp 2447508531
time
channel 4
rssi -82
snr 9
latitude 4563647
longitude 58721523
| 46
location_source registry
]
545 Simulation drsquoUplink dans lrsquoApplication Server
Dans beaucoup de situations nous souhaitons valider le fonctionnement de lrsquoApplication Server de
TTN ouet de notre propre Application Il est donc tregraves utile de pouvoir simuler lrsquoenvoi drsquoune trame
LoRa sur lrsquoApplication Server sans que celle-ci soit reacuteellement eacutemise par un Device LoRa Pour cela
un outil existe dans les Settings de chaque Device enregistreacute dans TTN Nous avons juste besoin de
speacutecifier le Frame Payload en clair en hexadeacutecimal et le numeacutero de Port
Figure 48 Simulation drsquoune trame envoyeacutee par un Device LoRa
546 Downlink De lrsquoApplication Server au Device LoRa La communication LoRa est bidirectionnelle Des donneacutees peuvent ecirctre transmis au Device LoRa
depuis lrsquoApplication Server Depuis TTN un outil existe dans les Settings de chaque Device
enregistreacute Lrsquointerface est repreacutesenteacutee ci-dessous
Figure 49 Transmission de donneacutees de lrsquo laquo Application Server raquo jusqursquoau Device LoRa
Replace scheduling Mode Par deacutefaut le Frame Payload transmis remplacera le Frame
Payload en attente (si il existe) Dans ce mode un seul Frame Payload est planifieacute
First scheduling Mode Le Frame Payload est mis en file drsquoattente en premiegravere position
Last scheduling Mode Le Payload est mis en file drsquoattente en derniegravere position
Une demande de confirmation peut ecirctre demandeacutee au Device LoRa pour qursquoil preacutecise srsquoil a bien reccedilu
les donneacutees Lrsquooption laquo confirmed raquo permet donc de speacutecifier le type de trame dans le MAC Header
(voir paragraphe 443) laquo Confirmed Data Down raquo ou laquo Unconfirmed Data Down raquo dans notre cas
| 47
6 La reacutecupeacuteration des donneacutees sur notre propre Application
Nous utiliserons agrave nouveau le Network Server et Application Server de The Things Network Jusqursquoici
nous nous sommes contenteacute de veacuterifier que les donneacutees de lrsquoutilisateur (Frame Payload) soient bien
arriveacutees agrave destination dans lrsquoApplication Server Il faut maintenant les reacutecupeacuterer avec notre propre
Application qui aura pour rocircle
De stocker et traiter les donneacutees
De les mettre agrave disposition de lrsquoutilisateur (Serveur Web par exemple)
Drsquoenvoyer des commandes de lrsquoutilisateur aux Devices LoRa si besoin (Flux Downlink)
Nous allons voir deux meacutethodes pour communiquer entre notre application et TTN
Le protocole HTTP POST
Le protocole MQTT
61 Reacutecupeacuteration des donneacutees en HTTP POST dans lrsquoApplication
611 Preacutesentation du protocole HTTP
Dans le monde de lrsquointernet le protocole HTTP est tregraves utiliseacute pour le dialogue entre un client et un
serveur web Classiquement le client (un navigateur web par exemple) fait une requecircte HTTP GET
et le serveur lui retourne le contenu de la page web demandeacutee
Dans notre cas la probleacutematique est diffeacuterente car le client doit modifier le contenu du serveur
avec les donneacutees envoyeacutees par le Device LORA La requecircte srsquoappelle HTTP POST Son nom indique
que le client va poster (et on pas reacutecupeacuterer) des donneacutees
Lrsquoutilisateur qui souhaite reacuteceptionner des donneacutees sur son serveur doit donc concevoir un serveur
HTTP capable de traiter des requecirctes HTTP POST [ requecircte noteacutee (1) sur la Figure 51 ] fournies par
TTN Dans cette configuration TTN jouera le rocircle de client et notre application le rocircle de serveur
Devices
LORA Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
HTTP POST
MQTT Internet
Figure 50 Structure globale drsquoun reacuteseau LORAWAN
| 48
Figure 51 Communication bidirectionnelle entre TTN et notre Application
A lrsquoinverse lrsquoutilisateur qui souhaite transmettre des donneacutees agrave destination du Device LoRa
(Downlink) doit ecirctre capable de fournir une requecircte HTTP POST [ requecircte noteacutee (2) sur la Figure 51
] vers TTN Dans cette configuration TTN jouera le rocircle de Serveur et notre application le rocircle de
client
612 Fonctionnement drsquoun client et drsquoun serveur HTTP POST Afin de bien comprendre le fonctionnement des requecirctes HTTP POST nous allons proceacuteder par
eacutetape Le premier test que nous effectuerons sera decorreacuteleacute de TTN Le principe est le suivant
Utilisation drsquoun serveur HTTP disponible sur le web geacuterant les requecirctes HTTP POST [
httpsrbasketsin ] ou [ httpsbeeceptorcom ] par exemple
Utilisation drsquoun client HTTP eacutemettant des requecirctes HTTP POST commande curl sous linux
ou logiciel Postman [ wwwgetpostmancom ] sous windows par exemple
Ce test nous permet de valider le fonctionnement drsquoun serveur HTTP POST et drsquoun client HTTP POST
Une fois que nous serons sucircr de leur fonctionnement nous les utiliserons avec TTN
The Things Network
Application
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 49
Figure 52 Validation dun server HTTP POST et drsquoun client HTTP POST
613 Test du serveur HTTP POST Nous utiliserons un serveur web proposeacute par httpsrbasketsin
Aller sur le site httpsrbasketsin et creacuteer un nouveau laquo Basket raquo Zone ougrave vous pourrez
visualiser les requecirctes qui ont eacuteteacute eacutemises vers votre serveur
A partir de maintenant toutes les requecirctes dirigeacutees vers lrsquoadresse creacuteeacute seront traiteacutees et
srsquoafficheront Dans le menu de configuration il est aussi possible de deacutefinir le contenu de la reacuteponse
qui sera fournie
Deacutefinir un format de reacuteponse pour les requecirctes HTTP POST avec un body personnaliseacute
614 Test du client HTTP POST On peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande (la commande cURL
srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN sous Windows
Commande cURL curl ndashX POST ndashd lsquorsquodonneacutees agrave envoyerrsquorsquo DuServeurHTTP
Logiciel Postman New gt Request gt Creacuteer une requecircte HTTP POST gt Send
Veacuterifier que les requecirctes HTTP POST sont bien reacutecupeacutereacutees sur votre serveur creacutee preacuteceacutedemment
615 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST
Maintenant que nous avons un serveur HTTP (POST) fonctionnel nous allons configurer TTN pour
jouer le rocircle du client et pour qursquoil envoie des requecirctes HTTP POST vers notre Serveur degraves qursquoune
donneacutee drsquoun Device LoRa est disponible Nous geacuterons donc ici le flux Uplink
Requecircte
HTTP POST
Reacuteponse
(contenu parameacutetrable)
Client HTTP (POST)
Server HTTP (POST) [ httpsrbasketsin ]
| 50
Figure 53 Reacutecupeacuteration des donneacutees sur notre Application
Dans TTN nous inteacutegrons un bloc appeleacute laquo HTTP Integration raquo permettant de jouer le rocircle de client
crsquoest-agrave-dire drsquoenvoyer des requecirctes HTTP POST agrave destination de notre nouveau Serveur HTTP
Lrsquointeacutegration se faire agrave partir de TTN gt Console gt Application gt Nom_de_votre_application gt
Integration
Figure 54 Ajout dun client HTTP POST dans TTN
Pour valider le fonctionnement de notre architecture nous pouvons soit
Envoyer une trame depuis un Device LoRa vers TTN
Simuler lrsquoenvoi drsquoune trame drsquoun Device LoRa vers TTN (gracircce agrave lrsquooutil proposeacute par TTN vu
paragraphe 545)
Dans les deux cas voici un exemple de requecircte POST reccedilue sur notre serveur HTTP
app_id test_app_lorawan_sylvainmontagny
dev_id stm32lorawan_1
hardware_serial 0056AF49877
port 1
counter 0
payload_raw qg==
metadata
Requecircte
HTTP POST
Server HTTP (POST) [ httpsrbasketsin ]
The Things Network (Client)
La requecircte contient le Frame Payload deacutechiffreacutee
agrave transmettre agrave lrsquoApplication
| 51
time 2019-01-24T15243703499298Z
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Comme nous pouvons le voir le contenu fourni agrave notre serveur est formateacute en JSON (voir
paragraphe 0) Voici quelques compleacutements drsquoinformation
payload_raw Frame Payload deacutechiffreacute crsquoest donc les donneacutees en clairs dans la base 64
downlink_url URL du serveur HTTP POST qui serviront agrave transmettre des donneacutees au Device
LoRa (flux Downlink)
611 Envoyer des donneacutees depuis notre Application avec HTTP POST
Lorsque nous avons ajouteacute le bloc laquo HTTP Integration raquo au paragraphe preacuteceacutedent nous avons aussi
implicitement activeacute la fonctionnaliteacute que TTN soit precirct agrave recevoir et agrave traiter les requecirctes HTTP
POST La seule information qursquoil nous manque est lrsquoadresse du server HTTP vers lequel il faut eacutemettre
les requecirctes Si on observe la trame reccedilue preacuteceacutedemment en provenance de TTN on srsquoaperccediloit que
dans la trame JSON reccedilu une URL (downlink_url) est speacutecifieacutee
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Crsquoest cette URL que nous devrons utiliser Nous allons nous placer dans la configuration suivante
Figure 55 Envoi de donneacutees agrave partir de notre Application
Comme preacuteceacutedemment on peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande
(la commande cURL srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN
Commande cURL curl ndashX POST ndashdata lsquo dev_id Identidiant_De_Votre_Device
payload_raw AQE= rsquo DuServeurHTTP
Logiciel Postman New gt Request gt HTTP POST puis Body gt Raw gt JSON
Requecircte HTTP POST vers serveur TTN laquo downlink_url raquo httpsintegrationsthethingsnetworUaeb8ypKieQ
Contenu de la requecircte
dev_id Identidiant_De_Votre_Device
payload_raw aGVsbG8=
The Things Network (Serveur)
POSTMAN (Client HTTP POST)
| 52
dev_id YourDeviceID
payload_raw aGVsbG8=
Vous devez envoyer le texte (payload_raw) en base 64 Dans lrsquoexemple ci-dessus laquo aGVsbG8= raquo
correspond agrave la chaine de caractegravere laquo hello raquo Vous pouvez utiliser les nombreux encodeurdecodeur
en ligne pour vous aider Le texte doit srsquoafficher sur votre moniteur seacuterie Arduino dans le cadre de
notre deacutemonstrateur sur Arduino
62 Reacutecupeacuteration des donneacutees avec MQTT dans lrsquoApplication
621 Preacutesentation du protocole MQTT
MQTT est un protocole leacuteger qui permet de srsquoabonner agrave des flux de donneacutees Plutocirct que
lrsquoarchitecture Client Serveur classique qui fonctionne avec des Requecirctes Reacuteponses MQTT est
baseacute sur un modegravele Publisher Subscriber La diffeacuterence est importante car cela eacutevite davoir agrave
demander (Requecircte) des donneacutees dont on na aucune ideacutee du moment ougrave elles vont arriver Une
donneacutee sera donc directement transmise au Subscriber degraves lors que celle-ci a eacuteteacute reccedilue dans le
Broker (serveur central)
Figure 56 Modegravele Publisher Subscriber du protocole MQTT
Pour recevoir les donneacutees appartenant agrave un Topic un Subscriber doit souscrire (comme son nom
lindique) au preacutealable sur ce Topic
MQTT est un protocole qui repose sur TCP Lencapsulation des trames sur le reacuteseau est donc la
suivante
Broker
Client
Publisher 1
Client
Publisher 2
Client
Subscriber
Topic
Tempeacuterature
Topic
Humiditeacute
| 53
Figure 57 Protocoles utiliseacutes pour la communication avec MQTT
On peut le veacuterifier par une capture de trame sur Wireshark
Figure 58 Capture dune trame MQTT avec Wireshark
On peut noter que le port TCP utiliseacute pour le protocole MQTT (non chiffreacute) est le 1883
Les Publishers et les Subscribers nrsquoont pas besoin de se connaitre
Les Publishers et les Subscribers ne sont pas obligeacute de srsquoexeacutecuter en mecircme temps
622 Connexion au Broker MQTT Nous nous inteacuteresserons essentiellement aux options de connexion qui permettront de geacuterer la
Qualiteacute de Service (QoS) Pour se connecter un client MQTT envoie deux informations importantes
au Broker
keepAlive Cest la peacuteriode la plus longue pendant laquelle le client Publisher ou Subscriber pourra
rester silencieux Au-delagrave il sera consideacutereacute comme deacuteconnecteacute
cleanSession Lorsque le Client et le Broker sont momentaneacutement deacuteconnecteacutes (au-delagrave du
keepAlive annonceacute) on peut donc se poser la question de savoir ce quil se passera lorsque le client
sera agrave nouveau connecteacute
Si la connexion eacutetait non persistante (cleanSession = True) alors les messages non transmis
sont perdus Quel que soit le niveau de QoS (Quality of Service)
Si la connexion eacutetait persistante (cleanSession = False) alors les messages non transmis
seront eacuteventuellement reacuteeacutemis en fonction du niveau de QoS Voir le chapitre 624
623 Qualiteacute de Service au cours dune mecircme connexion
A partir du moment ougrave le Client se connecte au Broker il est possible de choisir un niveau de fiabiliteacute
des transactions Le Publisher fiabilise leacutemission de ces messages vers le Broker et le Subscriber
fiabilise la reacuteception des messages en provenance du Broker Une parle ici du cas dune mecircme
connexion crsquoest-agrave-dire entre le moment ou le Client se connecte et le moment ougrave
Soit il se deacuteconnecte explicitement (Close connexion)
Soit il na rien eacutemis ni fait signe de vie pendant le temps keepAlive
TCP
MQTT
Reacuteseau
Transport
Couche Application
IP
| 54
Lors dune mecircme connexion la Qualiteacute de Service (QoS) qui est mise en œuvre deacutepend uniquement
de la valeur du QoS selon les valeurs suivantes
QoS 0 At most once (au plus une fois) Le premier niveau de qualiteacute est sans acquittement Le
Publisher envoie un message une seule fois au Broker et le Broker ne transmet ce message quune
seule fois aux Subscribers Ce meacutecanise ne garantit pas la bonne reacuteception des messages MQTT
QoS 1 At least once (au moins une fois) Le deuxiegraveme niveau de qualiteacute est avec acquittement
Le Publisher envoie un message au Broker et attends sa confirmation De la mecircme faccedilon le Broker
envoie un message agrave ces Subscriber et attends leurs confirmations Ce meacutecanisme garantit la
reacuteception des message MQTT
Cependant si les acquittements nrsquoarrivent pas en temps voulu ou srsquoils se perdent la reacuteeacutemission du
message dorigine peut engendrer une duplication du message Il peut donc ecirctre reccedilu plusieurs fois
QoS 2 Exactly once (exactement une fois) Le troisiegraveme niveau de qualiteacute est garanti une seule
fois Le Publisher envoie un message au Broker et attends sa confirmation Le Publisher donne alors
lrsquoordre de diffuser le message et attends une confirmation Ce meacutecanisme garantit que quel que
soit le nombre de tentatives de reacuteemission le message ne sera deacutelivreacute quune seule fois
La Figure 59 montre les trames eacutemises pour chaque niveau de QoS
Figure 59 Qualiteacute de Service en MQTT
La Figure 60 repreacutesentes les 3 captures de trames sur Wireshark repreacutesentant les 3 QoS (1 2 et 3)
que nous venons dexpliquer
Broker
QoS 0
Au plus une fois
Message supprimeacute apregraves envoi
PUBLISH
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Duplications possibles
PUBLISH
PUBLICH Ack
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Pas de duplication
PUBLISH
PUBLISH Receive
PUBLISH Release
PUBLISH Complete
| 55
Figure 60 Capture de trame avec QoS = 0 puis QoS = 1 puis QoS = 2
624 Qualiteacute de Service apregraves une reconnexion
La question que nous nous posons et de savoir ce que deviennent les messages publieacutes sur le Broker
lorsquun ou plusieurs Subscribers sont momentaneacutement injoignables Il est possible de conserver
les messages qui ont eacuteteacute publieacutes sur le Broker afin de les retransmettre lors de la prochaine
connexion Cette possibiliteacute de sauvegarde doit ecirctre activeacutee agrave louverture de connexion gracircce au flag
cleanSession = 0 La connexion sera alors persistante crsquoest-agrave-dire que le Broker enregistre tous les
messages quil na pas reacuteussi agrave diffuser au Subscriber
Le Tableau 9 reacutesume leffet du flag cleanSession et du QoS
Clean Session Flag Subscriber QoS Publisher QoS Comportement True ( = 1) 0 1 2 0 1 2 Messages perdus
False ( = 0 ) 0 0 1 2 Messages perdus
False (= 0 ) 0 1 2 0 Messages perdus
False (= 0 ) 1 2 1 2 Tous les messages sont retransmis
Tableau 9 Qualiteacute de Service en fonction de la valeur du QoS et du flag cleanSession
625 Les Topics du protocole MQTT Les chaicircnes deacutecrivant un sujet forment une arborescence en utilisant la barre oblique comme
caractegravere de seacuteparation La Figure 61 et le Tableau 10 donne un exemple dorganisation de Topic
Figure 61 Exemple de hieacuterarchie de Topic MQTT
Niveau 3
Niveau 2
Niveau 1 Maison
Chambre
Temperature Humidite Bruit
Salon
Temperature
| 56
Nom du Topic Deacutetail du Topic MaisonChambreTemperature La tempeacuterature de la chambre de la maison
MaisonChambreBruit Le bruit de la chambre de la maison
MaisonSalonTemperature La tempeacuterature du Salon de la maison
Tableau 10 Exemple de Topic
Un client peut sabonner (ou se deacutesabonner) agrave plusieurs branches de larborescence agrave laide de
jokers englobant plusieurs Topics Deux caractegraveres jokers existent
Le signe plus + remplace nimporte quelle chaine de caractegravere sur le niveau ougrave il est placeacute
Le diegravese remplace nimporte quelle chaine de caractegravere sur tous les niveaux suivants Il
est obligatoirement placeacute agrave la fin
Nom du Topic Deacutetail du Topic Maison+Temperature Les tempeacuteratures de toutes les piegraveces de la maison
MaisonChambre La tempeacuterature lhumiditeacute et le bruit de la chambre de la maison
Tableau 11 Exemple de Topic
626 Mise en place drsquoun Broker MQTT Afin de bien comprendre le fonctionnement du protocole de MQTT on reacutealise des tests
indeacutependamment de TTN Nous allons mettre en place
Un Broker Mosquitto httpstestmosquittoorg
Un client Publisher MQTT Box sur Windows
Un client Subscriber MQTT Box sur Windows
Figure 62 Test du protocole MQTT
MQTT Client (Subscriber)
MQTT Client (Publisher)
Publish
Subscribe
BROKER (Mosquitto)
| 57
Le Broker MQTT est commun agrave tout le monde Nous pouvons soit le reacutealiser nous-mecircme soit utiliser
un Broker MQTT public de test Nous utiliserons le Broker de test de Mosquitto disponible sur
httpstestmosquittoorg Drsquoautres sont eacuteventuellement disponibles en cas de problegraveme par
exemple httpwwwmqtt-dashboardcom
Si nous deacutecidions de le reacutealiser nous-mecircme agrave lrsquoaide drsquoune Raspberry Pi (par exemple) Lrsquoinstallation
se ferait en deux lignes de commande
apt-get install mosquito Installation
sudo systemctl start mosquittoservice Lancement du service
Il est neacutecessaire drsquoinstaller mosquitto-clients si on souhaite que le Raspberry PI joue aussi le rocircle de
client ce qui nrsquoest pas notre cas
627 Mise en place drsquoun Publisher et drsquoun Subscriber MQTT Lancer le logiciel MQTTBox
MQTTBox gt Create MQTT Client
Dans ce client les seuls champs indispensables sont
Protocol MQTT TCP
Host testmosquittoorg
Figure 63 Configuration dun Client MQTT dans MQTT Box
Tester lrsquoenvoi et la reacuteception sur les Topics de votre choix
628 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT La reacutecupeacuteration des donneacutees fait reacutefeacuterence au flux Uplink Dans ce cas
TTN joue le rocircle de client Publisher
TTN joue aussi le rocircle de Broker
Notre application joue le rocircle de Subscriber
Nous pouvons donc repreacutesenter lrsquoapplication globale par le scheacutema suivant
| 58
Figure 64 Publisher et Subscriber dans en MQTT avec TTN
La publication est repreacutesenteacutee par la trame MQTT (1)
La souscription est repreacutesenteacutee par la trame MQTT (2)
Le client Publisher eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box mais cette fois avec la configuration suivante
Protocol mqtt tcp
Host Crsquoest lrsquoIP du Broker vers lequel il faut se connecter Dans notre cas il srsquoagit de celui
de TTN dont lrsquoadresse est euthethingsnetwork
Username La connexion vers le broker MQTT est soumis agrave une authentification Username
Password Dans notre cas le Username correspond au nom de notre application crsquoest-agrave-
dire seminaire_lorawan Si vous avez choisi une autre applicationil faut bien mettre la
votre
Password Le Password est nommeacute laquo Access Key raquo par TTN Elle vous sera donneacutee par
lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application vous
trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt Overview
Figure 65 Access Keys de lapplication dans TTN
The Things Network (Application Server)
BROKER
Application
The Things Network (Network Server)
Publish (1 )
[ Flux Uplink ]
Subscribe (2 )
[ Flux Uplink ]
| 59
Figure 66 Configuration du Client dans MQTT Box
Le client MQTT eacutetant configureacute il est maintenant capable de se connecter au Broker Il reste donc agrave
deacutefinir le fait que le client sera Subscriber Les informations que recevra le Subscriber deacutependent du
Topic auquel nous souscrivons Voici les Topic disponibles sur le Broker de TTN
ltAppIDgt correspond au nom de votre Application
ltDevIDgt correspond au nom de votre Device LoRa
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink ltAppIDgtdevicesltDevIDgtup
[Donneacutees] Flux Downlink ltAppIDgtdevicesltDevIDgtdown
[Activation Events] Activation dun Device ltAppIDgtdevicesltDevIDgteventsactivations
[Management Events] Creacuteation dun Device ltAppIDgtdevicesltDevIDgteventscreate
[Management Events] Update dun Device ltAppIDgtdevicesltDevIDgteventsupdate
[Management Events] Suppression dun Device ltAppIDgtdevicesltDevIDgteventsdelete
[Downlink Events ] Message programmeacute ltAppIDgtdevicesltDevIDgteventsdownscheduled
[Downlink Events ] Message envoyeacute ltAppIDgtdevicesltDevIDgteventsdownsent
[Erreurs] Uplink erreurs ltAppIDgtdevicesltDevIDgteventsuperrors
[Erreurs] Downlink erreurs ltAppIDgtdevicesltDevIDgteventsdownerrors
[Erreurs] Activations erreurs ltAppIDgtdevicesltDevIDgteventsactivationserrors
Tableau 12 Topics enregistreacutes dans TTN
Dans un premier temps nous souscrivons au Topic +devices+up Cela signifie que nous
souscrivons agrave tous les Devices LoRa de toutes nos applications pour le flux Uplink
Figure 67 Configuration du Subscriber
Les eacuteleacutements eacutemis par le Broker seront alors afficheacutes dans MQTTBox La
| 60
Figure 68 Trame LoRaWAN reccedilu sur le Subscriber MQTT
Ces donneacutees sont eacutecrites en JSON nous pouvons les remettre en forme
applicationID3
applicationNamemyApplication
deviceNamearduino0
devEUI0056xxxxxxxxx877
txInfo
frequency868500000
dr5
adrfalse
fCnt792
fPort15
dataSGVsbG8=
Le Frame Payload deacutechiffreacute est fourni dans le champ data en base 64 La valeur fournie par
dataSGVsbG8= correspond bien agrave la chaine de caractegravere hello que nous avons eacutemise avec le
Device LoRa
629 Envoyer des donneacutees depuis notre Application avec MQTT
Lrsquoenvoi des donneacutees fait reacutefeacuterence au flux Downlink Dans ce cas
Notre application joue le rocircle de Publisher
TTN joue le rocircle de Broker
TTN joue aussi le rocircle de client Subscriber
| 61
La publication est repreacutesenteacutee par la trame MQTT (3)
La souscription est repreacutesenteacutee par la trame MQTT (4)
Le client Subscriber eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box Le rocircle de client dans MQTT Box a eacuteteacute faite au
paragraphe 628 Il nous reste simplement agrave ajouter le rocircle de Publisher La configuration est la
suivante
Topic du Subscriber seminaire_lorawandevicesarduino0down ougrave seminaire_lorawan
est agrave remplacer par le nom de votre application et arduino0 par le nom du Device LoRa vers
lequel vous souhaitez envoyeacute une donneacutee (Voir chapitre 628 pour comprendre les Topics)
Le Payload doit ecirctre au format JSON Lrsquoexemple suivant envoie laquohello raquo
payload_raw aGVsbG8=
The Things Network (Application Server)
BROKER
Application
Publish (3)
[ Flux Downlink ]
The Things Network (Network Server)
Subscribe (4)
[ Flux Downlink ]
| 62
Figure 69 Configuration du Publisher
Vous devriez voir les donneacutees arriver sur votre Device LoRA
| 63
7 Creacuteation de notre propre Network et Application Server
711 Objectifs Lors de la mise en œuvre du reacuteseau LoRaWAN au chapitre 52 nous avons utiliseacute TTN (The Things
Network) pour jouer le rocircle de Network Server et drsquoApplication Server Pour de multiples raisons
Seacutecuriteacute autonomie coucircthellipil peut ecirctre inteacuteressant de monter soi-mecircme un Network Server et un
Application Server Cela est possible seulement si vous posseacutedez vos propres Gateway puisque
celles-ci devront forwarder leur paquet agrave destination preacutecise Il faudra donc les reconfigurer pour
qursquoelles pointent vers votre nouvelle architecture
712 Preacutesentation de LoRaServer LoRaServer [ wwwloraserverio ] est un projet Open-Source reacutepondant exactement au besoin que
nous avons Nous lrsquoutiliserons sur une cible Raspberry PI En reacutealiteacute il peut souvent ecirctre mise en
place dans le mecircme systegraveme que la Gateway surtout si celle-ci est elle-mecircme agrave base de RPI Les
Gateway EBDS que nous posseacutedons possegravedent drsquoailleurs un Network Server et un Application Server
que nous aurions pu utiliser Neacuteanmoins pour des raisons peacutedagogiques il est inteacuteressant de
seacuteparer les systegravemes pour bien diffeacuterencier les probleacutematiques
Attention il y a une ambiguiumlteacute dans la deacutenomination des entiteacutes logiciels de LoRaServer
LoRaServer (sans espace entre le mot LoRa et Server) est le nom du projet global En
revanche LoRa Server (avec un espace) est le nom du service qui joue le rocircle du Network
Server
Lrsquoarchitecture et le fonctionnement de LoRaServer est preacutesenteacutee dans sa documentation par le
scheacutema suivant
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Raspberry PI
Figure 70 Architecture globale de notre reacuteseau loRaWAN
| 64
Figure 71 Architecture deacutetailleacutee de LoRaServer
On srsquoattends agrave voir uniquement un Network Server (LoRa Server) et un Application Server (LoRa App
Server) mais ce scheacutema est plus complexe Il demande un certain nombre drsquoexplications pour bien
comprendre ce que nous allons installer et la faccedilon dont nous lrsquoutiliserons par la suite
713 Le laquo Packet Forwarder raquo (Gateway) Comme nous lrsquoavons vu au chapitre 412 les Gateways LoRa sont des passerelles entre la
modulation LoRa et un reacuteseau IP Pour reacutealiser cette passerelle un service nommeacute laquo UDP Packet
Forwarder raquo a eacuteteacute deacuteveloppeacute par Semtech httpsgithubcomLora-netpacket_forwarder Dans
ce dossier github un fichier nommeacute PROTOCOLTXT explique parfaitement ce protocole applicatif
qui travaille au-dessus de UDP
Figure 72 Protocole Uplink (PUSH_DATA du Packet Forwarder)
| 65
On remarque que les paquets sont envoyeacutes en UDP au Network Server dans une trame appeleacutee
PUSH_DATA Cette trame est acquitteacutee par le Network Server par une trame appeleacutee PUSH_ACK
Sur notre Network Server nous pouvons reacutealiser une capture de trame pour veacuterifier si le protocole
est bien celui preacutesenteacute dans le document
Figure 73 Trame captureacutee par Wireshark lors dun Uplink
Drsquoapregraves la capture preacuteceacutedente on remarque que le Packet Forwarder fonctionne bien avec UDP sur
le port 1700
Le contenu des donneacutees (champ Data) est deacutetailleacute dans le tableau suivant
Champ | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | random token
[3] | 3 | PUSH_DATA identifier = 0x00
[4] | 4-11 | Gateway unique identifier (MAC address)
[5] | 12-end | JSON object starting with ending with
Lrsquoobjet JSON de la transmission reacuteeacutecrit plus proprement est celui-ci
Figure 74 Analyse du champ Donneacutees du protocole laquo Packet Forwarder raquo
0000 02 f9 30 00 b8 27 eb ff fe ae 26 f5 7b 22 72 78 0amprx 0010 70 6b 22 3a 5b 7b 22 74 6d 73 74 22 3a 33 37 35 pk[tmst375 0020 35 30 30 35 38 31 39 2c 22 63 68 61 6e 22 3a 32 5005819chan2 0030 2c 22 72 66 63 68 22 3a 31 2c 22 66 72 65 71 22 rfch1freq 0040 3a 38 36 38 2e 35 30 30 30 30 30 2c 22 73 74 61 868500000sta 0050 74 22 3a 31 2c 22 6d 6f 64 75 22 3a 22 4c 4f 52 t1moduLOR 0060 41 22 2c 22 64 61 74 72 22 3a 22 53 46 37 42 57 AdatrSF7BW 0070 31 32 35 22 2c 22 63 6f 64 72 22 3a 22 34 2f 35 125codr45 0080 22 2c 22 6c 73 6e 72 22 3a 36 2e 35 2c 22 72 73 lsnr65rs 0090 73 69 22 3a 2d 31 2c 22 73 69 7a 65 22 3a 31 38 si-1size18 00a0 2c 22 64 61 74 61 22 3a 22 51 4e 4d 61 41 53 59 dataQNMaASY 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 ]
Ch
amp
[1
]
Ch
amp
[2
]
Ch
amp
[3
]
Ch
amp
[4
]
| 66
rxpk[ tmst3755005819
chan2
rfch1
freq868500000
stat1
moduLORA
datrSF7BW125
codr45
lsnr65
rssi-1
size18
dataQNMaASYAAQAPpyPZ955+SmY
]
Le champ data correspond au PHY Payload
De la mecircme faccedilon on retrouve la Trame drsquoacquittement
Figure 75 Trame captureacutee par Wireshark lors de lrsquoacquittement drsquoun Uplink
Champs | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | same token as the PUSH_DATA to acknowledge
[3] | 3 | PUSH_ACK identifier = 0x01
Nous retrouvons bien tous ces champs dans la trame Wireshark
714 LoRa Gateway Bridge Nous avons deacutecrit au chapitre preacuteceacutedent (713) le fonctionnement du Packet Forwarder Le
Network Server(Lora Server) que nous allons mettre en place aurait tregraves bien pu srsquointerfacer
directement agrave ce protocole Mais cela aurait plusieurs impacts dont un qui est important dans la
conception de logiciel Si le Packet Forwarder change ou si un autre type de Forwarder est utiliseacute
alors lrsquoutilisation du LoRa Server devient impossible Il a donc eacuteteacute choisi de creacuteer une eacutetape
intermeacutediaire Le Network Server que nous mettrons en plus utilisera le protocole MQTT plutocirct que
le protocole UDP packet Forwarder
En drsquoautres termes le LoRa Gateway Bridge est un service qui fera abstraction du Packet Forwarder
pour srsquointerfacer plus simplement avec le Network Server
715 LoRa Server (Network Server) Il srsquoagit de notre Network Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
413 Cependant il srsquointerfacera au protocole MQTT en recevant les informations agrave partir du
Broker au lieu de recevoir directement les trames en provenance de la Gateway
| 67
716 LoRa App Server (Application Server) Il srsquogit de notre Application Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
414
717 LoRa Geo Server Il srsquoagit drsquoun service qui permet drsquoutiliser certaines proprieacuteteacutes du protocole LoRa pour proposer un
service de geacuteolocalisation des Devices LoRa Nous ne lrsquoutiliserons pas dans notre cas
718 Application Il srsquoagit de notre Application qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre 415
Elle ne fait pas partie du projet LoRaServer crsquoest donc bien toujours agrave nous de proposer notre propre
Application
Figure 76 Les interfaces possibles entre LoRaServer et lrsquoApplication utilisateur
Comme nous pouvons le voir sur la figure preacuteceacutedente deux possibiliteacutes sont offertes pour interfacer
notre application JSON REST (incluant HTTP POST) et via un Broker MQTT Ces deux meacutethodes ont
deacutejagrave eacuteteacute traiteacutee au chapitre 61 (HTTP POST ) et au chapitre 62 (MQTT) Nous verrons aussi drsquoautres
possibiliteacutes pour personnaliser notre application au chapitre 7
72 Installation de LoRaServer
721 Mise en place de lrsquoenvironnement
Nous allons installer une carte SD avec la derniegravere version de Raspbian Nous ne deacutetaillerons pas la
deacutemarche pour cela car elles sont largement documenteacutees et mises agrave jour sur le site
wwwraspberrypiorg
Installer un carte SD avec la derniegravere version de Raspbian
Plutocirct que de fonctionner avec un clavier et une souris nous preacuteconisons de travailler agrave distance
avec la RPI via une connexion SSH Depuis quelques anneacutees Raspbian a supprimeacute le deacutemarrage du
service SSH au boot Heureusement il est possible de le reacuteactiver par la meacutethode suivante
Avec Windows ou Linux ouvrir la partition BOOT de votre carte SD et placer un fichier agrave la
racine nommeacute sshtxt (ou ssh)
Mettre la carte SD dans votre RPI et la deacutemarrer
| 68
Pour acceacuteder agrave la RPI en SSH depuis Windows nous utiliserons de preacutefeacuterence le logiciel
client MobaXterm mais tout autre client SSH est valable
Installer MobaXterm sur votre PC et connectez-vous agrave votre Raspberry PI
Lrsquoutilisation drsquoun espion de reacuteseau type Wireshark peut ecirctre inteacuteressant pour eacutetudier les trames qui
sont reccedilues et qui sont eacutemises Cela nous permettra de valider le fonctionnement des diffeacuterents
protocoles reacuteseau qui permettent de communiquer agrave la Gateway drsquoune part et agrave lrsquoApplication
drsquoautre part Nous utiliserons tshark
apt-get install tshark installation
tshark ndashn -i eth0 Exemple drsquoune analyse sur lrsquointerface wlan0
722 Installation sur la Raspberry PI La meacutethode drsquoinstallation de LoRaServer est documenteacutee sur le site web agrave lrsquoadresse suivante
[ httpswwwloraserverioguidesdebian-ubuntu ] Nous installerons le LoRa Gateway Bridge
le LoRa Server et le LoRa App Server
Apregraves lrsquoinstallation la configuration se fait par une interface graphique accessible par le reacuteseau sur
le port 8080
Si vous travaillez sur la RPI connectez-vous sur httplocalhost8080
Si vous travaillez agrave distance (SSH) connectez-vous sur httpIP_RPI8080
Les Usernames et Password par deacutefaut sont
Username admin
Password admin
Lrsquoeacutecran drsquoaccueil sera donc le suivant
Figure 77 Architecture globale apregraves installation de LoRaServer
Devices
Gateways LoRa
UDP Packet Forwarder
Application Server
LoRa App Server
Internet
Network Server
LoRa Server
LoRa Gateway Bridge
| 69
Figure 78 Ecran daccueil de LoRaServer apregraves authentification
71 Configuration de LoRa Server pour lUplink
711 Enregistrement drsquoune nouvelle Organisation
Pour enregistrer une nouvelle Organizations Organizations gt Create Puis entrer les configurations
suivantes
Figure 79 Enregistrement dun nouvelle Organisation
712 Enregistrement drsquoune instance du Network Server Pour enregistrer une nouvelle instance du Network Server Network Server gt Create Puis entrer
les configurations suivantes
| 70
Figure 80 Enregistrement dun nouveau Network Server
Dans lrsquoonglet Gateway Discovery il est possible drsquoactiver une option de deacutecouverte de Gateway aux
alentours Lorsqursquoelle est configureacutee le Network Server va envoyer une trame Downlink de
configuration de la Gateway lui ordonnant de reacutealiser des PING en LoRa La configuration du
Gateway Discovery preacutevoit de speacutecifier
Le nombre de fois par jour que les PING LoRa sont envoyeacutes
Le canal drsquoeacutemission
Le Data Rate (Voir paragraphe 445)
Un PING LoRa reccedilu sur une Gateway sera retransmis sur le Network Server (Lora Server) et une carte
sera afficheacutee
Lrsquoonglet TLS Certificates ne sera pas utiliseacute dans le cadre de notre deacutemonstration
713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) Il faut tout drsquoabord faire un enregistrement drsquoun laquo service-profile raquo Un laquo service profile permet de
faire la connexion entre le Network Server et les Applications que nous enregistrerons dans notre
Organisation Service-profiles gt Create
Service-profile name myServiceProfile
Network-server myNetworkServer
On laissera par deacutefaut toutes les autres options
Pour enregistrer une nouvelle Application Applications gt Create Puis entrer les configurations
suivantes
| 71
Figure 81 Enregistrement dune nouvelle Application
714 Enregistrement des Devices LoRa Il faut tout drsquoabord faire lrsquoenregistrement drsquoun Device-profile pour les Devices LoRa que vous
souhaitez connecter Dans notre cas nous ferons un premier test en speacutecifiant que nous utilisons
seulement le mode drsquoauthentification ABP (voir chapitre 431) Devices profile gt Create
Figure 82 Enregistrement dun laquo Device profile raquo
Nous pouvons alors creacuteer dans notre Application des nouveaux Devices Application gt
myApplication gt Create
| 72
Figure 83 Enregistrement dun nouveau Device LoRa
Dans la fenecirctre Activation on va alors configurer les 3 eacuteleacutements indispensables agrave une
authentification en APB Le DevAddr le NwkSKey et lrsquoAppSKey
Figure 84 Configuration de lenregistrement du Device LoRa (en ABP)
La configuration minimale de LoRaServer est maintenant termineacutee Nous pouvons donc brancher
un Device LoRa qui possegravede les les attribus (DevAddr NwkSKey et AppSKey) que nous avons
enregistreacute dans LoRaServer et le faire eacutemettre
715 Visualisation des trames reccedilues Les trames eacutemises par le Device LoRa vont donc parcourir le cheminement suivant
| 73
Figure 85 Reacutesumeacute du cheminement des trames LoRaWan en Uplink avec LoRaServer
En allant dans le Live Device Data (Application gt Nom_du_Device gt Live Device Data) on peut voir la
liste des trames reccedilues ainsi que les donneacutees applicatives deacutechiffreacutees
Figure 86 Reacuteception des trames des Devices LoRa
Figure 87 Analyse des trames des Devices LoRa
Dans lrsquoonglet LIVE LORAWAN FRAME nous pouvons voir les trames LORAWAN et si besoin eacutetudier
le contenu de ce qursquoelles contiennent En revanche les donneacutees applicatives sont ici chiffreacutees
UDP
Packet Forwarder
LoRa Bridge
Gateway LoRa Server LoRa App Server
Gateway
Server
Internet
| 74
Figure 88 Reacuteception des Trames LoRaWAN
72 Configuration de LoRaServer pour linteacutegration dApplication Nous avons vu dans le chapitre 718 que linterface entre LoRaServer et notre Application pouvait
ecirctre reacutealiseacutee soit par MQTT soit par les meacutethodes REST (HTTP POST) Nous avons deacutejagrave impleacutementeacute
et expliqueacute ces protocoles dans le cadre de son utilisation avec TTN Nous allons donc juste
configurer LoRaServer pour tester ces deux meacutethodes
721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST Nous utiliserons exactement la mecircme meacutethode que celle que nous avons utiliseacute avec TTN au
chapitre 615 Les diffeacuterentes Clients et Serveurs disponibles pour ces tests sont expliqueacutes au
paragraphe 612
Dans LoRaServer ajouter une inteacutegration HTTP LoRaServer gt Applications gt myApplication gt
Integrations gt Create gt HTTP Integration et la configurer comme le montre la Figure 89 Vous
remplacerez eacutevidement le lien par votre propre Endpoints
Figure 89 Configuration de linteacutegration HTTP POST dans LoRaServer
En envoyant des trames LoRa depuis votre Device vous devriez voir les contenus JSON sur votre
Endpoint
722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT Nous allons nous connecter au Broker MQTT de LoRaServer Pour cela nous utiliserons la mecircme
meacutethode que celle que nous avons utiliseacute avec TTN au chapitre 628 Nous utiliserons MQTTBox
comme nous lavons deacutejagrave fait au paragraphe 627
Le Broker de LoRaServer a enregistreacute les Topics suivant
[applicationID] correspond au nom de votre Application
[devEUI] correspond au nom de votre Device LoRa
| 75
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink application[applicationID]device[devEUI]rx
[Donneacutees] Flux Downlink application[applicationID]device[devEUI]tx
[Status] Statut dun Device application[applicationID]device[devEUI]status
[Ack] Acquittement des messages application[applicationID]device[devEUI]ack
[Erreurs] Erreurs application[applicationID]device[devEUI]error
Tableau 13 Topics enregistreacutes dans LoRaServer
| 76
8 Creacuteation de notre propre Application
81 Utilisation de Node-RED
811 Preacutesentation Node-RED est un outil de programmation graphique qui permet de faire communiquer les
peacuteripheacuteriques mateacuteriels drsquoun systegraveme sans eacutecrire de code De nombreux protocoles sont aussi pris
en charge au travers de bloc ( Node) qursquoil suffit de connecter entre eux pour reacutealiser simplement
une application Il peut srsquoexeacutecuter localement sur un PC ou sur des cibles embarqueacutees telle qursquoune
Raspberry PI (RPI)
Dans les deacutemonstrations que nous mettrons en œuvre nous utiliserons une RPI Par soucis de
simpliciteacute nous utiliserons les derniegraveres versions de Raspbian (systegraveme drsquoexploitation de la RPI) qui
integravegre drsquoorigine Node-RED Il nrsquoy a donc tregraves peu de chose agrave mettre en place pour arriver agrave mettre
en place une Application Nous pouvons travailler soit directement sur la RPI agrave lrsquoaide drsquoune souris-
clavier mais il est recommandeacute de travailler agrave distance avec une connexion SSH
812 Mise en place de lrsquoenvironnement La mise en place de la RPI avec le systegraveme drsquoexploitation Raspbian a eacuteteacute preacutesenteacute au chapitre 721
Vous pouvez reprendre la mecircme installation ou repartir sur une nouvelle
Il est possible de faire en sorte que Node-RED se lance directement au deacutemarrage gracircce agrave la
commande sudo systemctl enable noderedservice
Sil nest pas actif lancer Node-RED sur votre RPI node-red-start
Nous nous connectons au Node-RED de la RPI via un navigateur web sur le port 1880 en tapant dans
la barre dURL httpIP_Raspeberry_PI1880 Ce nous permet darriver agrave la fenecirctre suivante
Figure 90 Page daccueil de Node-RED
Il est possible de sinterfacer avec TTN avec les Nodes deacutejagrave disponibles gracircce au protocole HTTP
POST ou MQTT Neacuteanmoins nous pouvons avantageusement installer deux librairies speacutecifiques
Une qui facilite linterfaccedilage avec TTN
Une qui facilite la mise en place dinterface graphique
Installation des Nodes TTN
cd $HOMEnode-red
npm install node-red-contrib-ttn
Installation de Dashboard (interface graphique)
| 77
cd $HOMEnode-red
npm install node-red-dashboard
Il peut ecirctre necessaire de redeacutemarrer Node-RED pour prendre en compte linstallation de nos deux
Nodes
-----------------------------------
sudo apt-get install npm
sudo npm install -g npm
hash -r
cd ~node-red
npm install node-red-example node name
------------------------------------
813 Creacuteer une Application speacutecifique pour TTN Nous allons commencer par geacuterer le flux Uplink Apporter sur votre scheacutema un Node ttn uplink et
un Node Debug puis relier les Le Node ttn uplink nous permettra de configurer la
communication avec TTN en MQTT Le Node debug eacutecrira sur le terminal les informations brutes
qui seront reccedilu par le Node ttn uplink
Figure 91 Visualisation des trame publieacutees par TTN sur notre client MQTT
Double cliquer sur le Node ttn uplink pour le configurer comme la figure suivante
Le champ Name sera le nom du Node sur votre scheacutema Le champ Device ID est le device LoRa
concerneacute dans votre application De plus il faut entrer les caracteacuteristiques de votre application (Add
new ttn app) pour que Node-RED puisse sy connecter
Figure 92 Configuration du node ttn uplink
Configuration de votre nouvelle application
| 78
Figure 93 Identifiant et mot de passe de notre application
AppID Nom de votre application Dans notre cas seminaire_lorawan
Access Key Comme nous lavons deacutejagrave expliqueacute plus tocirct l Access Key vous sera donneacutee
par lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application
vous trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt
Overview
Le Node ttn uplink doit maintenant avoir le nom que vous avez configureacute Cliquer sur Deploy pour
lancer votre projet Le bloc ttn uplink doit maintenant ecirctre connecteacute agrave TTN Cela est speacutecifieacute
connected sous le bloc
Figure 94 Utilisation du Node TTN Uplink
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
Figure 95 Simulation de Uplink dans TTN
Vous devriez voir le reacutesultat dans la fenecirctre de Debug Par exemple pour le test denvoi de 31 32
correspondant au code ASCII des chiffres 1 et 2 vous devriez avoir la fenecirctre de Debug suivante
| 79
Figure 96 Reacutesultats obtenu dans la fenecirctre Debug apregraves la simulation dUplink
814 Creacuteation drsquoun Dashboard
Dans la mise en place de lenvironnement (chapitre 812) nous avons installeacute des Nodes
Dashboard qui vont nous permettre de reacutealiser une interface graphique tregraves simple et de la mettre
agrave disposition des utilisateurs via un des graphiques histogramme gauges afficheurshellip
Figure 97 Impleacutementation dune interface graphique dans Node RED
Linterface graphique que nous allons creacuteer sera constitueacutee donglet (tab) La mise en place des
composant se fait de la faccedilon suivante
Chaque eacuteleacutement graphique doit appartenir agrave un groupe de composant quil va falloir creacuteer
Chaque groupe de composant doit appartenir agrave un onglet (tab) quil va falloir creacuteer
Figure 98 Creacuteation dun groupe de composant
Figure 99 Creacuteation dun nouvel onglet dans le site web
Cliquer sur Deploy pour activer votre application
LURL pour joindre linterface graphique de votre site web est disponible sur ladresse
httpIP_Raspeberry_PI1880ui
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
| 80
Figure 100 Interface graphique du site web avec Node-RED
82 Programmation en PHP Maintenant que nous avons testeacute toute lrsquoarchitecture nous pouvons mettre en place une
application qui jouera deux rocircles
Un rocircle de Serveur HTTP POST reacutecupeacuterant les donneacutees en provenance de TTN
Un rocircle de Client HTTP POST qui geacuteneacuterera les requecirctes vers TTN
Un serveur web apache sur RPI heacuteberge cette application Linterface graphique du site web est
reacutealiseacute avec le template CSS proposeacute par Bootstrap [ httpsgetbootstrapcom ]
Figure 101 Architecture de notre application en PHP sur RPI
The Things Network
Notre Application
[ Serveur Apache sur Raspberry Pi ]
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 81
Nous allons lrsquoutiliser telle quelle Elle est juste proposeacutee agrave titre dexemple Lrsquoobjectif de cette
application est de geacuteneacuterer une ouverture fermeture de ruche agrave distance dans le cadre de projets
eacutetudiants du Master Electronique et Systegravemes Embarqueacutes de lUSMB [ httpscem-esetuniv-
smbfr ]
Figure 102 Application permettant de recevoir et deacutemettre des requecirctes HTTP POST
Configurer TTN pour pointer vers votre nouveau serveur et tester le flux montant et
descendant
| 82
9 Versions du document
Version 10 02022019
Version initiale
Version 20 23022019
Ajout drsquoun paragraphe Les systegravemes embarqueacutes dans lrsquoIoT En introduction
Compleacutement et ameacutelioration Ameacutelioration exercice eacutetalement de spectre
Correction Cacircblage Arduino
Ajout drsquoun paragraphe Fonctionnement de lrsquoArduino et ajout de librairies
Compleacutement et ameacutelioration Couche physique LoRa Ajout de 4 figures pour lrsquoexplication
de la modulation Chirp
Ajout drsquoun paragraphe sur les acronymes utiliseacutes au deacutebut du cours TTN LoRa MQTThellip
Compleacutement drsquoinformations sur les dB et dBm
Ajout LoRa Calculator
Version 30 8032019
Ajout de figure sur le rocircle de la Gateway LoRa
Ajout de paragraphe authentification avec le Network Server
Ajout de paragraphe sur le chiffrement avec lrsquoApplication Server
Ajout drsquoun sommaire en deacutebut de cours
Ajout de 2 scheacutemas ABP et OTAA
Retrait explication du deacutetail de la laquo Join Request raquo en OTAA Trop complexe attente de
reacutealisation drsquoun scheacutema plus explicite
Ajout drsquoun scheacutema sur lrsquoattaque par REPLAY
Ajout de paragraphe des diffeacuterents reacuteseaux LoRaWAN existants Opeacutereacutes et Priveacutes
Ajout des scheacutemas des trames LoRaWAN Physique LoRa MAC Application
Compleacutement drsquoinformation sur les Classes de Devices
Ajout drsquoun paragraphe sur la Gateway utiliseacutee pour le Downlink
Ajout drsquoun paragraphe sur le JSON
Compleacutement drsquoinformation sur le codage en Base64
Ajout drsquoinformation dans le deacutecodage des trames LoRaWAN
Restructuration des explications sur lrsquoenvoi et la reacutecupeacuteration des donneacutees en HTTPMQTT
Version 40 8032019
Ajout drsquoun chapitre Creacuteation de notre propre Application
Ajout drsquoun chapitre Creacuteation de notre propre Network et Application Server
Ajout drsquoune figure Visualisation des Chirps LoRa par SDR (Radio Logicielle)
Compleacutements drsquoinformation sur MQTT
Compleacutements dinformation sur les Topics de TTN en MQTT
| 6
1 Les systegravemes embarqueacutes et lrsquoIoT
11 LInternet des Objets ( Internet of Things IoT )
111 Les systegravemes embarqueacutes dans lrsquoIoT Drsquoune faccedilon geacuteneacuterale les systegravemes eacutelectroniques peuvent ecirctre caracteacuteriseacutes par leur consommation
leur puissance de calcul leur taille et leur prix Dans le cas speacutecifique des systegravemes embarqueacutes
utiliseacutes dans lrsquoIoT nous pouvons affecter le poids suivant agrave chacune des caracteacuteristiques
Figure 1 Consommation Puissance Taille et Prix des objets connecteacutes
Compareacutes aux autres systegravemes eacutelectroniques les systegravemes embarqueacutes utiliseacutes dans lrsquoIoT possegravedent
donc
Une faible consommation
Une faible puissance de calcul
Une petite taille
Un prix faible
112 Diffeacuterents protocoles dans lrsquoIoT
Citez les diffeacuterents protocoles que vous connaissez dans le mode de lrsquoIoT (Internet Of
Things) et reportez-les dans le graphique ci-dessous en fonction de leur bande passante
et de leur porteacutee
Figure 2 Protocoles utiliseacutes dans lIoT en fonction du deacutebit et de la porteacutee
Dans lrsquoIoT les protocoles utiliseacutes possegravedent une grande porteacutee et des deacutebits faibles
Lrsquoensemble de ces reacuteseaux sont deacutenommeacutes LPWAN Low Power Wide Area Network
113 Bande de freacutequence utiliseacutees En Europe les bandes de freacutequences libres (sans licence) sont
13 Mhz (RFID) 169 Mhz 434 Mhz 868 Mhz 24Ghz 5 Ghz et 24 Ghz (Faisceau Hertzien) Parmi ces
freacutequences seul le 433 MHz et 868 MHz sont utilisables en LoRa
12 Modes de partage du support Quel que soit le protocole utiliseacute le support de transfert de lrsquoinformation est lrsquoair car tous les
protocoles de lrsquoIoT sont Wireless Le support doit ecirctre partageacute entre tous les utilisateurs de telle
faccedilon que chacun des dispositifs Wireless ne perturbe pas les autres Pour cela une bande de
freacutequence est alloueacutee Par exemple pour la radio FM la bande de freacutequence va de 875 Mhz agrave 108
Mhz
Dans leur bande de freacutequence les dispositifs peuvent se partager le support de diffeacuterentes
maniegraveres
FDM (Frequency Division Multiplexing) Ce mode utilise une partie du spectre (bande de
freacutequence) en permanence Exemple Radio FM
TDM (Time Division Multiplexing) Ce mode utilise tout le spectre (bande de freacutequence) par
intermittence Exemple GSM on a laquo 8 time slots raquo par canal
CDMA (Code Division Multiple Access) Ce mode utilise tout le spectre tout le temps
Porteacutee (Range)
Deacutebit (Bandwidth)
| 8
Les Devices LoRa sont capables drsquoeacutemettre sur un mecircme canal en mecircme temps Le protocole LoRa
utilise une modulation tregraves similaire agrave la meacutethode 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 Plus
tard dans le cours nous expliquerons les diffeacuterences de la modulation LoRa
13 Notion drsquo eacutetalement de spectre utiliseacutee en LoRa Nous allons voir au travers drsquoun exercice comment il est possible drsquoutiliser tout le spectre en
permanence tout en eacutetant capable drsquoeffectuer plusieurs transactions simultaneacutees entre diffeacuterents
eacutemetteursreacutecepteurs Cette meacutethode est souvent appeleacutee laquo eacutetalement de spectre raquo car comme
son nom lrsquoindique elle a pour conseacutequence drsquoeacutetaler le spectre du signal transmis
La meacutethode consiste agrave utiliser des codes qui ont des proprieacuteteacutes matheacutematiques adapteacutees agrave notre
objectif Transmettre en mecircme temps sur la mecircme bande de freacutequence La matrice ci-dessous
donne par exemple 4 codes drsquoeacutetalement (1 par ligne)
Code Orthogonal User 0 1 1 1 1
Code Orthogonal User 1 1 -1 1 -1
Code Orthogonal User 2 1 1 -1 -1
Code Orthogonal User 3 1 -1 -1 1
Tableau 1 Matrice de Hadamart (matheacutematicien) dordre 4
Les proprieacuteteacutes de ces codes (1 1 1 1 1 -1 1 -1 1 1 -1 -1 1 -1 -1 1) ne sont pas expliqueacutees ici Nous
nous conterons de veacuterifier leur bon fonctionnement
131 Transmissions successives Chaque tableau ci-dessous repreacutesente une transmission qui est indeacutependante des autres elles ne
se deacuteroulent pas en mecircme temps On veacuterifie qursquoavec la mise en œuvre de laquo lrsquoeacutetalement de spectre raquo
chaque transmission arrive bien agrave destination avec le message qui avait eacuteteacute transmis Le premier
tableau est deacutejagrave rempli en guise drsquoexemple La meacutethode est la suivante
A lrsquoeacutemission
Chaque bit du message est multiplieacute par un code drsquoeacutetalement (une ligne de la matrice)
Le reacutesultat de la multiplication est transmis
A la reacuteception
Chaque symbole reccedilu est multiplieacute par le mecircme code drsquoeacutetalement
Le message reccedilu est eacutegal agrave la somme des symboles diviseacute par le nombre de symbole
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
hellip transmission hellip
4 Utilisation code orthogonal User 1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1
5 Deacutecodage = (3) x (4) 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0
6 Message reccedilu (sum (5) nbr_bits) 1 0 1 0
Reacutealiser la transmission du message du User 2 et du User 3 dans les tableaux suivants
| 9
1rsquo Message User 2 0 1 0 1
2rsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
3rsquo Symboles transmis User 2 = (1rsquo) x (2rsquo) 0 0 0 0
hellip transmission hellip
4rsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
5rsquo Deacutecodage = (3rsquo) x (4rsquo) 0 0 0 0
6rsquo Message reccedilu (sum (5rsquo) nbr_bits) 0
1rsquorsquo Message User 3 1 1 0 0
2rsquorsquo Utilisation code orthogonal User 3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
3rsquorsquo Symboles transmis User 3 = (1rsquorsquo) x (2rsquorsquo) 1 -1 -1 1
hellip transmission hellip
4rsquorsquo Utilisation code orthogonal User3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
5rsquorsquo Deacutecodage = (3rsquorsquo) x (4rsquorsquo) 1 1 1 1
6rsquorsquo Message reccedilu (sum (5rsquorsquo) nbr_bits) 1
132 Transmissions simultaneacutees
Les transmissions se deacuteroulent maintenant simultaneacutement les messages des User 1 User 2 et User
3 sont envoyeacutes en mecircme temps sur la mecircme bande de freacutequence La premiegravere colonne du User 1
est deacutejagrave remplie en guise drsquoexemple La meacutethode est la suivante
Dans lrsquoair
On additionne les symboles transmis par tous les User (1 2 3) ligne 1rsquorsquorsquo
Pour la reacuteception
Chaque symbole reccedilu est multiplieacute par le code drsquoeacutetalement du User
Le message reccedilu est eacutegal agrave la somme des symboles diviseacute par le nombre de symbole
Valider le fonctionnement pour la reacuteception des messages
1rsquorsquorsquo sum des symboles transmis ( 3 + 3rsquo + 3rsquorsquo ) 2 -2 0 0
2rsquorsquorsquo Utilisation code orthogonal User 1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 2 0 0
4rsquorsquorsquo Message reccedilu User 1 (sum (3rsquorsquorsquo) nbr_bits) 1
2rsquorsquorsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 -2 0 0
4rsquorsquorsquo Message reccedilu User 2 (sum (3rsquorsquorsquo) nbr_bits) 0
2rsquorsquorsquo Utilisation code orthogonal User 3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 2 0 0
4rsquorsquorsquo Message reccedilu User 3 (sum (3rsquorsquorsquo) nbr_bits) 1
133 Cas du protocole LoRa Le LoRa utilise une meacutethode drsquoeacutetalement de spectre qui nrsquoest pas exactement celle que nous venons
drsquoeacutetudier La finaliteacute est cependant la mecircme Pouvoir transmettre en mecircme temps sur le mecircme
canal Le protocole LoRa utilise sept laquo codes drsquoeacutetalement raquo appeleacutes Spreading Factor [ SF6 SF7 SF8
SF9 SF10 SF11 et SF12 ] qui lui permet drsquoavoir sept transmissions simultaneacutees sur un mecircme canal
| 10
2 Transmission radio et propagation
21 Les uniteacutes et deacutefinitions dB Rapport entre deux puissances Une atteacutenuation est repreacutesenteacutee par un nombre
neacutegatif (-) Un gain est repreacutesenteacute par un nombre positif (+)
Rapport de puissances en dB Rapport de puissance
+ 3 dB Multiplication par 2
- 3 dB Division par 2
0 dB Egaliteacute
+ 10 dB Multiplication par 10
- 10 dB Division par 10
Tableau 2 Comparaison entre les gains en dB et en proportion
dBi Gain theacuteorique drsquoune antenne
dBm Puissance rameneacutee agrave 1mW 0 dBm correspond agrave 1 mW
En reprenant la deacutefinition des dB remplir le tableau suivant
Puissance en dBm Puissance en mW
+ 3 dBm
- 3 dBm
+ 10 dBm
- 10 dBm
Tableau 3 Comparaison entre les puissances en dB et en mW
Le Talkie-Walkie a une puissance drsquoeacutemission de 2W Quelle est la puissance drsquoeacutemission
exprimeacutees en dBm
Sensibiliteacute Puissance minimale qursquoest capable de deacutetecter un reacutecepteur
RSSI Received Signal Strength Indication
SNR Signal over Noise Ratio
Un eacutemetteur transmet agrave une puissance de 13dBm en utilisant une antenne dont le gain
est de 2dBi Les pertes dans lrsquoair sont de 60 dB Lrsquoantenne reacuteceptrice qui possegravede un gain
de 2dBi est relieacutee agrave un reacutecepteur dont la sensibiliteacute est de -80 dBm Le signal pourra-t-il
ecirctre reccedilu
Le link Budget Crsquoest la quantiteacute de puissance que nous pouvons perdre avant drsquoarriver au
reacutecepteur tout en conservant une transmission fonctionnelle Autrement dit crsquoest la
puissance de lrsquoeacutemetteur moins la sensibiliteacute du reacutecepteur Dans lrsquoexemple preacuteceacutedent le
budget que nous avons agrave disposition est de 93dB
| 11
En LoRa nous avons un Link Budget de 157 dB
En LTE (4G) nous avons un Link Budget de 130 dB
Etude de la documentation drsquoun composant LoRa Le RN2483 est le composant radiofreacutequence que nous utiliserons dans notre transmission LoRa
Voici quelques une de ses caracteacuteristiques
Figure 3 Caracteacuteristiques principales du composant radiofreacutequence utiliseacute
Reprenez la deacutefinition du Link Budget et retrouver les 157 dB annonceacute dans cette
documentation
En LoRa plus le code drsquoeacutetalement est grand plus on est capable drsquoeacutemettre dans un milieu bruiteacute La
figure ci-dessous preacutesente les rapports signal sur bruit avec lesquels nous seront capable de reacutealiser
une transmission en fonction des Spreading Factor utiliseacutes
Figure 4 Influence du Spreading Factor sur le SNR acceptable
On remarque que pour un SF8 nous sommes capables drsquoeacutemettre avec un SNR de -10 dB On pourra
transmettre malgreacute le fait que le bruit est 10 fois supeacuterieur au signal
On remarque que pour un SF12 nous sommes capables drsquoeacutemettre avec un SNR de -20 dB On
pourra transmettre malgreacute le fait que le bruit est 100 fois supeacuterieur au signal
| 12
Cependant on remarque aussi que lrsquoutilisation drsquoun Spreading Factor plus eacuteleveacute augmente
consideacuterablement le nombre de symbole eacutemis (2egraveme colonne du tableau) Comme nous le verrons
plus tard cela impactera eacutevidement le temps de transmission
| 13
3 La couche physique LoRa
31 La modulation LoRa Comme nous lrsquoavons expliqueacute plus tocirct la modulation LoRa utilise lrsquoeacutetalement de spectre pour
transmettre ces informations Mais au lieu drsquoutiliser des codes drsquoeacutetalement (CDMA) elle utilise une
meacutethode appeleacutee Chirp Spread Spectrum La finaliteacute est toujours la mecircme Avoir plusieurs
transmissions dans le mecircme canal La conseacutequence sur le spectre est aussi la mecircme cela provoque
un eacutetalement du spectre
311 La forme du symbole (Chirp) Le signal eacutemis par la modulation LoRa est un symbole dont la forme de base est repreacutesenteacutee ci-
dessous Son nom (Chirp) vient du fait que ce symbole est utiliseacute dans la technologie Radar (Chirp
Compressed High Intensity Radar Pulse)
Figure 5 Symbole de la modulation LoRa (source Wikipeacutedia)
La freacutequence de deacutepart est la freacutequence centrale du canal moins la Bande Passante diviseacutee par deux
La freacutequence de fin est la freacutequence centrale plus la Bande Passante diviseacutee par deux
La freacutequence centrale est appeleacutee le canal
La bande passante est la largeur de bande occupeacutee autour du canal
On considegravere une eacutemission sur la freacutequence centrale 868 Mhz avec une Bande Passante
de 125 kHz Donner la freacutequence de deacutebut et la freacutequence de fin du sweep
Freacutequence de deacutebut
Freacutequence de fin
Pour faciliter la repreacutesentation de ce symbole on utilise plutocirct un graphique TempsFreacutequence de
la forme suivante
| 14
Figure 6 Forme du symbole de base (CHIRP)
En LoRa chaque symbole repreacutesente un certain nombre de bits transmis La regravegle est la suivante
Nombre de bits transmis dans un symbole = Spreading Factor
Par exemple si la transmission utilise un Spreading Factor de 10 (SF10) alors un symbole repreacutesente
10 bits
Crsquoest-agrave-dire qursquoagrave lrsquoeacutemission les bits sont regroupeacutes par paquet de SF bits puis chaque paquet est
repreacutesenteacute par un symbole particulier parmi 2119878119865formes de symboles possibles
Sur la figure suivante voici un exemple theacuteorique drsquoune modulation en SF2 agrave 868 Mhz sur une
bande passante de 125 kHz Chaque symbole repreacutesente donc 2 bits
Figure 7 Symboles eacutemis en Modulation LoRa (Cas theacuteorique en SF2)
Exemple
On considegravere la suite binaire suivante 0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Le Spreading Factor utiliseacute est SF10
Nous regroupons donc les bits par paquet de 10 Chaque paquet de 10 bits sera repreacutesenteacute par un
symbole (sweep) particulier Il y a 1024 symboles diffeacuterents pour coder les 1024 combinaisons
binaires possibles (210)
Freacutequence
Temps
868 000 000 Hz
868 062 500 Hz
Un symbole Un symbole
867 937 500 Hz
Temps
868 000 000 Hz
867 937 500 Hz
Symbole 0
Bits laquo 00 raquo
Symbole 1
Bits laquo 01 raquo
Symbole 2
Bits laquo 10 raquo Symbole 3
Bits laquo 11 raquo
12
5 k
Hz
868 062 500 Hz
| 15
Figure 8 Emission des Chirp en LoRa
Avec un outils drsquoanalyse spectrale actif pendant lrsquoeacutemission LoRa drsquoun Device on peut afficher les
successions de symbole qui sont envoyeacutes Cette oscillogramme a eacuteteacute reacutealiseacute agrave lrsquoaide drsquoun SDR
(Software Digital Radio)
Figure 9 Visualisation des Chirps LoRa reacuteellement eacutemis pendant une transmission
312 Dureacutee drsquoeacutemission drsquoun symbole En LoRa la dureacutee drsquoeacutemission de chaque symbole (Chirp) deacutepend du Spreading Factor utiliseacute Plus le
SF est grand et plus le temps drsquoeacutemission sera long Pour une mecircme bande passante le temps
drsquoeacutemission drsquoun symbole en SF8 est deux fois plus long que le temps drsquoeacutemission drsquoun symbole en
SF7 Ainsi de suite jusqursquoagrave SF12
0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Envoi de 1 Chirp Envoi de 1 Chirp Envoi de 1 Chirp
Transmission Transmission Transmission
| 16
Figure 10 Temps drsquoeacutemission drsquoun symbole (Chirp) en fonction du SF
En revanche le temps drsquoeacutemission drsquoun symbole est inversement proportionnel agrave la bande passante
119879119904 =2119878119865
119861119886119899119889119908119894119889119905ℎ Le deacutebit des symboles est donc de
1
119879119878= 119865119904 =
119861119886119899119889119908119894119889119905ℎ
2119878119865 En toute logique plus la
bande passant est eacuteleveacute plus le deacutebit des symboles sera eacuteleveacute Comme chaque symbole comprend
SF bit on retrouve alors le deacutebit binaire
119863119887 = 119878119865119861119886119899119889119908119894119889119905ℎ
2119878119865
Plus le Spreading Factor sera eacuteleveacute plus le deacutebit binaire sera faible
Plus la Bande Passante sera eacuteleveacutee plus le deacutebit binaire sera fort
Exemple Drsquoapregraves la formule du deacutebit binaire trouver le deacutebit pour les deux cas suivants
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
32 Coding Rate Le Coding Rate est un ratio qui augmentera le nombre de bits agrave transmettre afin de reacutealiser de la
deacutetection correction drsquoerreur Dans le cas drsquoun CR = 4 8 il y aura 8 bits transmis reacuteellement agrave
chaque fois que nous souhaitons transmettre 4 bits Dans cette exemple cela provoque une
transmission drsquoun nombre de bit multiplieacute par 2
SF7
Freacutequence
Temps
Freacutequence centrale
Freacutequence haute
Temps drsquoun symbole eacutemit en SF 12
Freacutequence basse
SF8
SF9
SF10
SF11
SF12
Temps drsquoun symbole eacutemit en SF 11
| 17
Figure 11 Influence du Coding Rate sur le nombre de bits ajouteacute
Si on reprend lrsquoexemple preacuteceacutedent avec un CR de 4 5 nous avons une augmentation de 125 du
nombre de bits agrave transmettre Redonner la deacutebit en prenant en compte le CR
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
La documentation du composant RN2483 donne les deacutebits en fonction du Spreading Factor
la Bande Passante et le Coding Rate Veacuterifier la coheacuterence du reacutesultat avec votre calcul
preacuteceacutedent
Figure 12 Deacutebit en fonction des paramegravetres de la transmission LoRa
33 Utilisation du LoRa Calculator Le logiciel laquo LoRa Calculator raquo est un petit exeacutecutable permettant de simuler une transmission LoRa
en fonction des caracteacuteristiques saisies Canal SF CR etchellip Il est teacuteleacutechargeable agrave lrsquoadresse
suivante httpsbitly2TyloAh
| 18
Figure 13 Le logiciel LoRa Calculator
En reprenant lrsquoexemple preacuteceacutedent (SF7 Bande Passante 125 kHz CR 45) veacuterifier les
calculs du laquo Equivalent Bitrate raquo
34 Time On Air La norme LoRaWAN impose qursquoun Device LoRa ne transmette pas plus de 1 du temps Cela est
repreacutesenteacute par un Duty Cycle Par exemple un Duty Cycle de 1 signifie que si jrsquoeacutemet pendant 1 je
ne dois plus eacutemettre pendant 99 quel que soit lrsquouniteacute de temps utiliseacutee
En reprenant les exemples preacuteceacutedents quels sont les deacutebits moyens si on prend en compte
le laquo Time On Air raquo
Cas 1 Pour SF7 et 125 khz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
Dans le logiciel laquo LoRa Calculator raquo (onglet laquo Energy Profile raquo) nous pouvons estimer la
dureacutee de vie drsquoune batterie Nous prenons lrsquoexemple drsquoun releveacute de tempeacuterature dans un
bacirctiment avec les caracteacuteristiques suivantes
| 19
SF CR Bande Passante etc Nous nous placcedilons dans le cas 1 des exemples preacuteceacutedents
Le releveacute de tempeacuterature se fera toutes les 15 mins
La batterie est constitueacute de 3 petites piles bacirctons [ AAA LR03 ] 12V en seacuterie Soit 36 V
1000 mAh
35 Mise en œuvre LoRa en point agrave point Ce test sera reacutealiseacute avec des modules LoRa RN2483 (Microchip) et une carte microcontrocircleur
ARDUINO
Figure 14 Communication LoRa en Point agrave Point
Reacutealiser le cacircblage de votre module RN2483 suivant le tableau suivant
Connecteur Arduino Click Board RN2483
5V 5V
GND GND
11 RX
10 TX
Tableau 4 Cacircblage de lrsquoARDUINO et de la click Board RN2483
351 Utilisation de lrsquoIDE Arduino Lrsquoenvironnement Arduino est tregraves simple Nous allons reacutealiser un programme pour montrer son
fonctionnement
La connexion de la carte est effectueacutee agrave lrsquoaide drsquoun port USB qui eacutemule une liaison seacuterie
RS232 Il faut donc choisir le bon port Arduino IDE gt Outils gt Port
Pour creacuteer un nouveau programme (sketch) Arduino IDE gt Fichier gt Nouveau
Il y a deux parties dans un sketch
Une fonction setup() qui sera exeacutecuteacutee qursquoune seule fois au deacutemarrage
Une fonction loop() qui sera exeacutecuteacutee en boucle
Ecrire le code suivant
Emetteur
Reacutecepteur
UA
RT
UA
RT
| 20
void setup()
Serialbegin(9600)
void loop()
Serialprintln(hello word)
Compiler et Teacuteleacuteverser Croquis gt Teacuteleacuteverser
Voir la sortie sur la liaison seacuterie Outils gt Moniteur Seacuterie gt Choisir la vitesse de
transmission ici 9600 bauds (en bas agrave droite)
352 Validation du fonctionnement Deux binocircmes joueront le rocircle drsquoeacutemetteur tous les autres binocircmes seront en reacutecepteur
Reacutecupeacuterer les programmes dans Moodle dans le dossier laquo RN2483-Arduino-Point2Point raquo
Installer la librairie RN2483 Arduino IDE gt Croquis gt Inclure une bibliothegraveque gt Ajouter la
bibliothegraveque zip
Reacutepartissez les rocircles Emetteurs Reacutecepteurs et reacutecupeacuterer le programme LoraBlinkerRX ou
LoraBlinkerTX en fonction Les 2 binocircmes en eacutemission devront modifier le code du sketch
Arduino pour transmettre des donneacutees speacutecifiques afin de les diffeacuterencier [
loraSerialprintln(radio tx 30) ]
Validez la reacuteception des donneacutees eacutemises par les deux binocircmes qui transmettent des
donneacutees Ces donneacutees reccedilues sont eacutecrite agrave 57600 bauds sur le moniteur seacuterie de lrsquoArduino
353 Mise en valeur du Spreading Factor On srsquoaperccediloit dans la manipulation preacuteceacutedente que les Devices LoRa reccediloivent les donneacutees des deux
eacutemetteurs Nous allons conserver le mecircme canal drsquoeacutemission (8691 Mhz) mais un des deux
eacutemetteurs va modifier son laquo Spreading Factor raquo La salle sera donc seacutepareacutee en deux groupes
1er groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF7
2egraveme groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF8
Validez la reacuteception des donneacutees eacutemises seulement pour le Spreading Factor que vous
utilisez
| 21
4 Le protocole LoRaWAN
Le LoRa est le type de modulation utiliseacute entre deux Devices ou entre un Device et une Gateway
Lorsque nous parlons de lrsquoensemble de la chaine de communication (Device Gateway Serveur) alors
nous parlons de communication LoRaWAN Nous allons voir lrsquoarchitecture drsquoun reacuteseau LoRaWAN
ainsi que les regravegles de ce protocole
41 Structure drsquoun reacuteseau LoRaWAN Nous retrouvons drsquoun cocircteacute le Device LoRa qui transmet une donneacutee Elle est reacuteceptionneacutee agrave lrsquoautre
extreacutemiteacute du reacuteseau par un Utilisateur La structure globale du reacuteseau LoRaWAN peut ecirctre
repreacutesenteacutee par la figure suivante
411 Les Devices LoRa Les Devices LoRa sont des systegravemes eacutelectroniques appartenant au monde de lrsquoIoT Faible
consommation faible taille faible puissance et faible taille
Ils possegravedent une radio LoRa permettant de joindre les Gateways Les Gateways ne sont pas
adresseacutees speacutecifiquement toutes celles preacutesentes dans la zone de couverture reccediloivent les
messages et les traitent
412 Les Gateways LoRa Elles eacutecoutent sur tous les canaux et sur tous les Spreading Factor Lorsqursquoune trame LoRa est reccedilue
elle transmet son contenu sur internet agrave destination du Network Server qui a eacuteteacute configureacute dans la
Gateway au preacutealable
Elle joue donc le rocircle de passerelle entre une modulation LoRa et une communication IP
Devices
LoRa Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
Internet Internet
Figure 15 Structure globale dun reacuteseau LORAWAN
| 22
Chaque Gateway LoRa possegravede un identifiant unique (EUI sur 64 bits)
413 Le Network Server
Le Network Server reccediloit les messages transmis par les Gateways et supprime les doublons
(plusieurs Gateway peuvent avoir reccedilu le mecircme message) Les informations transmises au Network
Server depuis les Devices LoRa sont authentifieacutes gracircce agrave une cleacute AES 128 bits appeleacutee Network
Session Key NwkSKey Nous parlons bien ici drsquoauthentification et non pas de chiffrement comme
nous le verrons plus tard
414 Application Server Il est souvent sur le mecircme support physique que le Network Server Il permet de dissocier les
applications les unes des autres Chaque application enregistre des Devices LoRa qui auront le droit
Devices Gateways Network
Server
Internet
Network Session Key (NwkSKey)
Authentification
Figure 17 Authentification entre le Device LoRa et le Network Server
Internet
UDP IP
Modulation
LoRa
Device LoRa
Gateway
Network Server
LoRaWAN
Modulation
LoRa
Passerelle LoRa Internet
Internet
UDP IP
LoRaWAN
Transmission Radio
Application Application
Figure 16 Le rocircle de la Gateway LoRa
| 23
de stocker leurs donneacutees (Frame Payload) Les message transmis agrave lrsquoapplication server sont chiffreacutes
gracircce agrave une cleacute AES 128 bits appeleacutee Application Session Key AppSKey
Le scheacutema suivant reacutesume lrsquoutilisation
De la Network Session Key (NwkSKey) pour lrsquoauthentification entre le Device LoRa et le
Network Server
De lrsquoApplication Session Key (AppSKey) pour le chiffrement entre le Device LoRa et
lrsquoApplication Server
Devices Gateways Network
Server Application
Server
Internet
Application Session Key (AppSKey)
Chiffrement
Figure 18 Chiffrement entre le Device LORA et lrsquoApplication Server
| 24
415 Application Web Serveur Cette application doit drsquoune part reacutecupeacuterer les donneacutees de lrsquoApplication Serveur Dans le cadre de
ce cours cela sera fait de deux faccedilons
Avec le protocole HTTP
Avec le protocole MQTT
Figure 20 Application Web Server
Figure 19 Authentification et chiffrement en LoRaWan
Devices Gateways
Network
Server Application
Server
Internet
Network Session Key
Application Session Key
Network
Server Application
Server
Application
Server Web
Utilisateur
Protocole
MQTT ou HTTP
Flux Uplink
Flux Downlink
| 25
Le flux habituel dans lrsquoIoT est le flux Uplink (flux montant) crsquoest-agrave-dire lrsquoeacutemission de donneacutees des
objets vers le serveur Comme nous lrsquoexpliquerons plus loin en LoRaWAN il est aussi possible de
transfeacuterer des donneacutees aux Device LoRa par un flux Downlink (flux descendant)
Drsquoautre part lrsquoapplication mettra agrave disposition les donneacutees aux utilisateurs sous forme par exemple
drsquoun serveur web drsquoune base de donneacutees et drsquoune visualisation graphique
416 Authentification avec le Network Server La Network Session Key (NwkSKey) sert agrave lrsquoauthentification entre le Device LoRa e le Network Server
Afin de reacutealiser cette authentification entre le Device et le Network Server un champ MIC (Message
Integrity Control) est rajouteacute agrave la trame Il est calculeacute en fonction des donneacutees transmises et du
NwkSkey A la reacuteception le mecircme calcul est effectueacute Si les cleacutes sont eacutequivalentes dans le Device et
dans le Network Server alors les deux MIC calculeacutes doivent correspondre
417 Chiffrement des donneacutees vers lrsquoApplication Server
LrsquoApplication Session Key (AppSKey) sert pour le chiffrement entre le Device LoRa et lrsquoApplication
Server Les donneacutees chiffreacutees seront alors deacutecodeacutees agrave la reacuteception sur lrsquoApplication Server srsquoil
possegravede la mecircme cleacute Si on reprend le scheacutema preacuteceacutedent les laquo donneacutees x raquo sont chiffreacutees
deacutechiffreacutees par le processus suivant
Donneacutees x chiffreacutees NwkSkey x
MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees
NwkSkey x
Trame eacutemise Trame reccedilue
Device LoRa Network Server
Si =
Alors la trame est authentifieacutee
MIC geacuteneacutereacute Emission MIC geacuteneacutereacute Reacuteception
MIC geacuteneacutereacute Reacuteception
Figure 21 Authentification dun Device LoRa par le Network Server
| 26
Figure 22 Chiffrement des donneacutees par lApplication Session Key
418 Combinaison de lrsquoauthentification et du chiffrement On peut maintenant repreacutesenter sur le mecircme scheacutema la construction de la trame LoRaWAN avec
drsquoune part lrsquoauthentification et drsquoautre part le chiffrement
Figure 23 Chiffrement puis Authentification
42 Classes des Devices LoRaWAN Les Devices LoRa sont classeacutes en 3 cateacutegories (A B C) en fonction de leur consommation et de leur
accessibiliteacute en Downlink crsquoest-agrave-dire la faciliteacute qursquoun utilisateur aura agrave transmettre une trame au
Device LoRa
421 Classe A (All) Minimal power Application Tous les Devices LoRaWAN sont de classe A Chaque Device peut transmettre (Uplink) agrave la Gateway
sans veacuterification de la disponibiliteacute du reacutecepteur Si la transmission eacutechoue elle sera reacuteeacutemise apregraves
un certain temps Cette transmission est suivie de 2 fenecirctres de reacuteception tregraves courtes La Gateway
peut alors transmettre pendant le laquo RX Slot 1 raquo ou le laquo RX Slot 2 raquo mais pas les deux
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Device LoRa
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Application Server
Donneacutees non chiffreacutees
AppSKey
Donneacutees chiffreacutees Entecircte
NwkSKey
MIC geacuteneacutereacute en eacutemission Trame transmise =
| 27
Figure 24 Slots de reacuteception pour un Device LoRa de classe A
Source de lrsquoimage httpszakelijkforumkpncom
La dureacutee des fenecirctres doit ecirctre au minimum la dureacutee de reacuteception drsquoun preacuteambule Un preacuteambule
dure 1225 Tsymbole et deacutepend donc du Data Rate (DR voir paragraphe 445 pour plus drsquoinformation
sur le DR) Lorsque qursquoun preacuteambule est deacutetecteacute le reacutecepteur doit rester actif jusqursquoagrave la fin de la
transmission Si la trame reccedilue pendant la premiegravere fenecirctre de reacuteception eacutetait bien agrave destination du
Device LoRa alors la deuxiegraveme fenecirctre nrsquoest pas ouverte
Premiegravere fenecirctre de reacuteception
Le Slot RX1 est programmeacute par deacutefaut agrave 1 seconde + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont les mecircme que ceux choisis lors de la phase drsquoeacutemission
(Uplink)
Seconde fenecirctre de reacuteception
Le Slot RX2 est programmeacute par deacutefaut agrave 2 secondes + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont configurables mais fixes
Un Device LoRa qui est uniquement de classe A ne peut pas recevoir srsquoil nrsquoa pas eacutemis Il
nrsquoest donc pas joignable facilement
422 Classe B (Beacon) Scheduled Receive Slot Les Devices de classe B ont le mecircme comportement que les Devices de classe A mais drsquoautres
fenecirctres de reacuteceptions sont programmeacutees agrave des peacuteriodes preacutecises Afin de synchroniser les fenecirctres
de reacuteception du Device LoRa la Gateway doit transmettre des balises (Beacons) de faccedilon reacuteguliegravere
| 28
Figure 25 Slots de reacuteception pour un Device LoRa de classe B
Source de lrsquoimage httpszakelijkforumkpncom
Un Device LoRa de classe B est joignable reacuteguliegraverement sans qursquoil soit neacutecessairement
obligeacute drsquoeacutemettre En revanche il consomme plus qursquoun Device de classe A
423 Classe C (Continuous) Continuously Listening Les Devices de classe C ont des fenecirctres de reacuteception constamment ouvertes entre 2 Uplinks Ces
Devices consomment donc beaucoup plus
Figure 26 Slots de reacuteception pour un Device LoRa de classe C
Source de lrsquoimage httpszakelijkforumkpncom
| 29
Un Device LoRa de classe C est joignable en permanence En revanche crsquoest la classe de
Device qui est la plus eacutenergivore
424 Quelle Gateway pour les flux Downlink
Nous avons donc vu que le fonctionnement classique du protocole LoRaWAN eacutetait de reacutecupeacuterer de
lrsquoinformation depuis le Device LoRa Crsquoest le flux Uplink
Dans le cas ougrave lrsquoutilisateur transmet des informations au Device LoRa (flux Downlink) on peut se
demander quelle Gateway sera choisie pour transfeacuterer les donneacutees au Device LoRa En effet
lrsquoendroit ougrave est situeacute le Device LoRa nrsquoest pas neacutecessairement connu agrave lrsquoavance
La Gateway utiliseacutee pour le Downlink est celle qui a reccedilu le dernier message du Device
LoRa Un message ne pourra jamais arriver agrave destination drsquoun Device LoRa si celui-ci nrsquoa
jamais transmis quel que soit sa classe A B ou C
43 Activation des Devices LoRa et seacutecuriteacute En LoRaWAN les trois eacuteleacutements indispensables pour la communication sont le DevAddr pour
lrsquoindentification du Device ainsi que deux cleacutes le NwkSKey pour lrsquoauthentification et lrsquoAppSKey
pour le chiffrement Deux meacutethodes sont possibles pour fournir ces informations agrave la fois au Device
LoRa et au serveur
Activation By Personalization APB
Over The Air Activation
431 ABP Activation By Personalization Crsquoest la plus simple des meacutethodes Crsquoest donc peut ecirctre celle que nous avons tendance agrave utiliser lors
drsquoun test de prototype et drsquoune mise en place de communication LoRaWAN
Le Device LoRa possegravede deacutejagrave le DevAddr lrsquoAppSKey et le NwkSKey
Le Network server possegravede deacutejagrave le DevAddr et le NwkSKey
Lrsquoapplication serveur possegravede deacutejagrave le DevAddr et le AppSKey
En ABP toutes les informations neacutecessaires agrave la communication sont deacutejagrave connues par le
Device LoRa et par le Serveur
| 30
432 OTAA Over The Air Activation Crsquoest la meacutethode qursquoil faut privileacutegier car crsquoest celle qui est la plus seacutecuriseacutee Le Device LoRa doit
connaitre le DevEUI lrsquoAppEUI et lrsquoAppkey Le Network Server doit lui connaitre la mecircme Appkey
Tous les eacuteleacutements noteacutes EUI (Extended Unique Identifier) sont toujours sur une taille de
64 bits
Gracircce agrave ces informations de deacutepart et une neacutegociation avec le Network Server (Join Request) le
Device LoRa et le serveur vont geacuteneacuterer les informations essentielles DevAddr NwkSKey et
AppSKey
Figure 28 Obtention du DevAddr NwkSKey et AppSKey en OTAA
DevEUI Unique Identifier pour le device LoRa (Equivalent agrave une MAC sur Ethernet)
Certains Device LoRa ont deacutejagrave un DevEUI fourni en usine
AppEUI Unique Identifier pour lrsquoapplication server
DevEUI
AppEUI
AppKey
Join
Request
DevAddr
NwkSKey
AppSKey
Network Server
Application Server
Devices 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 2
NwkSkey 2
AppSKey 2
Devices 2
DevAddr 2
NwkSkey 2
AppSKey 2
Paramegravetres stockeacutes sur le serveur
Paramegravetres programmeacutes
dans le composant
Figure 27 Parameacutetrage de DevAddr NwkSKey et AppSKey
| 31
AppKey AES 128 cleacute utiliseacutee pour geacuteneacuterer le MIC (Message Code Integrity) lors de la Join
Resquest Il est partageacute avec le Network server
NwkSKey Utiliseacute pour lrsquoauthentification avec le Network Server
AppSKey Utiliseacute pour le chiffrement des donneacutees
433 Seacutecuriteacute Les cleacutes AES 128 bits permettent le chiffrement des informations transmises en LoRaWAN Malgreacute
ce chiffrement une attaque connue en Wireless est celle du REPLAY Crsquoest-agrave-dire que le Hacker
enregistre des trames chiffreacutees circulant sur le reacuteseau LoRa pour les reacuteeacutemettre plus tard Mecircme si
le Hacker ne comprend pas le contenu (les trames sont chiffreacutees) les donneacutees qui sont transporteacutees
sont elles bien comprises par lrsquoApplication Server Des actions peuvent donc ecirctre reacutealiseacutees
simplement par mimeacutetisme
Pour eacuteviter cela la trame LoRaWAN integravegre un champ variable appeleacute laquo Frame Counter raquo Il srsquoagit
drsquoun nombre numeacuterotant la trame sur 16 ou 32 bits LrsquoApplication Server acceptera une trame
uniquement si le laquo Frame Counter raquo reccedilu est supeacuterieur au laquoFrame Counter raquo preacuteceacutedemment Donc
si le Hacker retransmet la trame telle qursquoelle le laquo Frame Counter raquo sera eacutequivalent donc la trame
sera refuseacutee Et comme la trame est chiffreacutee le Hacker nrsquoa pas moyen de savoir comment modifier
un champ de cette trame
Cette seacutecuriteacute impleacutementeacutee par les laquo Frame Counter raquo est inteacuteressante pour srsquoaffranchir drsquoune
attaque par REPLAY mais dans nos tests cela peut poser problegraveme En effet agrave chaque fois que nous
redeacutemarrons le microcontrocircleur notre laquo Frame Counter raquo revient agrave zeacutero alors que celui de
lrsquoApplication Server continue de srsquoincreacutementer Cela peut ecirctre reacutesolue par diffeacuterentes maniegraveres
1 Deacutesactivation du laquo Frame Counter Check raquo Dans certain Application Server cette option
peut ecirctre proposeacutee Bien sucircr il faudra garder en tecircte la faille de seacutecuriteacute que cela engendre
Network Server
Application Server
Devices LoRa
NwkSkey
AppSKey
NwkSkey
AppSKey Hacker
(1) (2)
(1) Ecoute
(2) Reacuteeacutemission
Figure 29 Attaque par REPLAY
| 32
Figure 30 Deacutesactivation du Frame Counter Check dans TTN
2 Utiliser lrsquoauthentification par OTAA au lieu de ABP En effet agrave chaque ouverture de session
en OTAA le laquo Frame Counter raquo est reacuteinitialiseacute coteacute serveur
3 Conserver la valeur du laquo Frame Counter raquo dans une meacutemoire non volatile et reacutecupeacuterer sa
valeur au deacutemarrage du Device LoRa
44 La Trame LoRa LoRaWAN
441 Les couches du protocole LoRaWAN
Lorsque nous avons fait une communication en Point agrave Point nous avons simplement utiliseacute la
couche physique de la modulation LoRa Lorsque nous souhaitons utiliser le protocole LoRaWAN
des couches protocolaires suppleacutementaires se rajoutent
Figure 31 Les couches protocolaires du LoRaWAN
Chaque couche rajoute un service Lors de lrsquoenvoi de la trame les donneacutees utilisateurs sont donc
encapsuleacutees dans chaque couche infeacuterieure jusqursquoagrave la transmission Le deacutetail de lrsquoensemble de la
trame LoRaWAN par couche est deacutecrit sur la figure Figure 32
LoRa Modulation
LoRa Mac
Application
Couche Physique
Couche Mac
Couche Application
| 33
442 Couche Application La couche Application accueille les donneacutees de lrsquoutilisateur Avant de les encapsuler elles sont
chiffreacutees avec lrsquoAppSKey afin de seacutecuriser la transaction
Un ensemble de champs nommeacute Frame Header permet de speacutecifier le DevAddr le Frame Control
le Frame Counter et le Frame Option
Le Frame Port deacutepend du type drsquoapplication et sera choisi par lrsquoutilisateur
Le Frame Payload sont les donneacutees chiffreacutees agrave transmettre Le nombre drsquooctets maximum pouvant
ecirctre transmis (N octets) est donneacute dans le tableau suivant
PHY Payload
P octets Couche
Physique
Couche
Mac
Couche
Application
CRC
2 octets Header + Header CRC
20 bits Preamble
MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Figure 32 Trame LORAWAN complegravete par couche protocolaire
Couche
Application Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Frame Header
Figure 33 Trame LORA couche Applicative
| 34
Data Rate Spreading Factor Bandwidth Max Frame Payload (Nombre N) DR 0 SF12 125 KHz 51 octets
DR 1 SF11 125 KHz 51 octets
DR 2 SF10 125 KHz 51 octets
DR 3 SF9 125 KHz 115 octets
DR 4 SF8 125 KHz 222 octets
DR 5 SF7 125 KHz 222 octets
DR 6 SF7 250 KHz 222 octets
Tableau 5 Taille maximum du Frame Payload en fonction du Data Rate
443 Couche LoRa MAC Cette trame est destineacutee au Network Server Elle est authentifieacutee gracircce au champ MIC (Message
Integrity Protocol) selon la meacutethode expliqueacutee au paragraphe 416
Le protocole LoRa MAC est composeacute de
1 MAC Header Version de protocole et type de message
Type de Message Description 000 Join-Request
001 Join-Accept
010 Unconfirmed Data Up
011 Unconfirmed Data Down
100 Confirmed Data Up
101 Confirmed Data Down
110 Rejoin-request
111 Proprietary
Tableau 6 Les types de messages transmis en LoRaWAN
2 MAC Payload Contient tout le protocole applicatif
3 MIC Message Integrity Code pour lrsquoauthentification de la trame
444 Couche physique Modulation LoRa
Le choix du moment drsquoeacutemission des Devices LoRa se fait de faccedilon simple Lorsqursquoun eacutequipement
doit eacutemettre il le fait sans controcircle et ne cherche pas agrave savoir si le canal est libre Si le paquet a eacuteteacute
perdu il le retransmettra simplement au bout drsquoun temps aleacuteatoire La couche physique est
repreacutesenteacutee par lrsquoeacutemission de la trame suivante
Couche
Mac MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Figure 34 Trame LORA couche LORA MAC
| 35
Le Preacuteambule est repreacutesenteacute par 8 symboles + 425 Le temps du Preacuteambule est donc de 1225
Tsymbole
Len-tecircte (Header optionnel) est seulement preacutesent dans le mode de transmission par deacutefaut
(explicite) il est transmis avec un Coding Rate de 48 Il indique la taille des donneacutees le Coding Rate
pour le reste de la trame et il preacutecise eacutegalement si un CRC sera preacutesent en fin de trame
Le PHY Payload contient toutes les informations de la Couche LoRa MAC
Le CRC sert agrave la deacutetection drsquoerreur de la trame LoRa
445 Canaux et bandes de freacutequences et Data Rate (DR) Le LoRa utilise des bandes de freacutequences diffeacuterentes suivant les reacutegions du monde En Europe la
bande utiliseacutee est celle des 868 Mhz [ De 863 Mhz agrave 870 Mhz ] Le LoRaWAN deacutefinie les 8 canaux agrave
utiliser pour communiquer avec une Gateway suivant le tableau suivant
Canaux Spreading Factor Bandwidth 8681 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz SF7 250 kHz
8685 Mhz De SF7 agrave SF12 125 kHz
8671 Mhz De SF7 agrave SF12 125 kHz
8673 Mhz De SF7 agrave SF12 125 kHz
8675 Mhz De SF7 agrave SF12 125 kHz
8677 Mhz De SF7 agrave SF12 125 kHz
8679 Mhz De SF7 agrave SF12 125 kHz
Tableau 7 Canaux SF et Bandwidth de notre Gateway LoRaWAN
Une Gateway LoRa eacutecoute donc sur 8 canaux simultaneacutement avec les 6 Spreading Factor
diffeacuterents soit 48 combinaisons possibles
Comme nous lrsquoavons vu le Spreading Factor a des conseacutequences sur le deacutebit de la transmission Ces
deacutebits sont noteacutes DR (Data Rate) et sont normaliseacutes de DR0 agrave DR6
PHY Payload
P octets Couche
Physique CRC
2 octets Header + Header CRC
( Optionnel ) 20 bits Preamble
Figure 35 Trame LORA couche Physique
| 36
Data Rate Spreading Factor Bandwidth DR 0 SF12 125 KHz
DR 1 SF11 125 KHz
DR 2 SF10 125 KHz
DR 3 SF9 125 KHz
DR 4 SF8 125 KHz
DR 5 SF7 125 KHz
DR 6 SF7 250 KHz
Tableau 8 Deacutenomination DR en fonction du SF et de la Bande Passante
446 Trame reccedilue et transmise par la Gateway LoRaWAN La Gateway reccediloit drsquoun cocircteacute un message radio moduleacute en LoRa et transmet de lrsquoautre cocircteacute une trame
IP agrave destination du Network Server
Coteacute interface Radio La Gateway reacuteceptionne une trame LoRaWAN et extrait le PHY Payload Celui-
ci est codeacute au format ASCII en base 64 (voir le paragraphe 541) La Gateway extrait aussi toutes les
informations utiles sur les caracteacuteristiques de la reacuteception qui a eu lieu SF Bandwidth RSSI Time
On Airhellipetchellip
Coteacute interface reacuteseau IP La Gateway transmet lrsquoensemble de ces informations dans un paquet IP
(UDP) au Network Server Les donneacutees transmises sont du texte en format JSON (voir paragraphe
447) La Gateway a donc bien un rocircle de passerelle entre le protocole LoRa drsquoun cocircteacute et un reacuteseau
IP de lrsquoautre
Internet
UDP IP
Device LoRa
Gateway
Network Server Modulation
LoRa
Passerelle LoRa Internet
Transmission Radio Internet
Figure 36 Rocircle de la Gateway LoRa
| 37
447 Le format JSON Le format JSON est un format texte composeacute drsquoune succession de couple nomvaleur Dans
lrsquoexemple de la figure preacuteceacutedente gw_id est un nom et eui-b827ebfffeae26f5 est la valeur
associeacutee Dans cette exemple la valeur est un string Les objets sont deacutelimiteacutes par un des accolades
et
Une valeur peut ecirctre
Un string exemple coding_rate 45
Un nombre exemple spreading_factor 12
Un objet exemple lora spreading_factor 12 air_time 2465792000
Un Boolean
Ethernet
Gateway
Modulation
LORA
Reacutecupeacuteration du PHY PAYLOAD en base 64
Reacutecupeacuteration des caracteacuteristiques de la transmission Canal SF CR hellip
IP (IP dest routereuthethingsnetwork)
UDP (Port dest 1700 Port source 1700)
Donneacutees applicatives (format JSON)
gw_id eui-b827ebfffeae26f5
payload QNAPvA6Ax3ECqHk4C8hfzuA==
lora
spreading_factor 12
bandwidth 125
air_time 2465792000
coding_rate 45
timestamp 2019-01-20T133746017Z
rssi -105
snr -162
dev_addr 0EBC0FD0
frequency 867100000
Internet Transmission Radio LORA
Figure 37 Passerelle (Gateway) LORAWAN
| 38
5 Mise en œuvre drsquoun reacuteseau LoRaWAN
51 Les diffeacuterents types de reacuteseaux Les reacuteseaux LoRaWAN peuvent ecirctre utiliseacute suivant deux meacutethodes
En utilisant les reacuteseaux LoRaWAN opeacutereacutes proposeacutes par les opeacuterateurs de teacuteleacutecoms
En utilisant votre propre reacuteseau LoRaWAN priveacute
511 Les reacuteseaux LoRaWAN opeacutereacutes Ce sont des reacuteseaux LoRaWAN proposeacutes par les opeacuterateurs Par exemple Objenious (filiale de
Bouyges) ou encore Orange Dans le cas de lrsquoutilisation des reacuteseaux opeacutereacutes lrsquoutilisateur a juste
besoin de srsquooccuper des Devices LoRa Les Gateways le Network Server et lrsquoApplication Server sont
geacutereacutes par lrsquoopeacuterateur
512 Les reacuteseaux LoRaWAN priveacutes Chacun est libre de reacutealiser son propre reacuteseau priveacute en impleacutementant sa propre Gateway pour
communiquer avec ses Devices LoRa Lrsquoimpleacutementation du Network Server et de lrsquoApplication Server
peuvent alors ecirctre envisageacutes de diffeacuterentes faccedilons
Network Server et Application serveur priveacutees Crsquoest le deacuteveloppeur qui les mets en place Dans
certaines Gateways une impleacutementation de ces deux serveurs est deacutejagrave proposeacutee Sinon il est
possible de la mettre en place Il existe des serveurs (Network et Application) open source crsquoest le
cas par exemple de LoRa Serveur [ wwwloraserverio ]
Une autre alternantive est httpsgithubcomgotthardplorawan-server
LoRaServer et lorawan-server sont deux applications Open Source
Network Server et Application Server en ligne Un certain nombre de Network Server et
drsquoApplication Server sont proposeacutes Ce sont des services payants ou avec des contreparties
Loriot [ wwwloriotio ]
ResIoT [ wwwresiotio ]
The Things Network [ wwwthethingsnetworkorg ] Crsquoest la solution que nous utiliserons
513 Les zones de couvertures
Les zones de couvertures des reacuteseaux opeacutereacutes sont mise agrave jour par les opeacuterateurs celle drsquoobjenious
est par exemple disponible ici httpsobjeniouscomreseau
Pour connaitre la zone de couverture de notre Gateway utiliseacutee avec TTN nous pouvons utiliser
lrsquoapplication TTN Mapper httpsttnmapperorg Lrsquoideacutee est de promener son Device LoRa associeacute
agrave un GPS dans la zone de couverture des Gateway qui nous entourent A chaque trame reccedilue par le
| 39
Serveur on note les coordonneacutees GPS du Device LoRa ainsi que la Gateway qui a transmis le
message Toutes ces informations sont alors retranscrites sur une carte
52 The Things Network (TTN)
521 Preacutesentation de TTN
Pour la suite nous utiliserons le Network Server et lrsquoApplication Server fourni par TTN
[wwwthethingsnetworkorg]
TTN est gratuit et Open Source En revanche le fait drsquoutiliser TTN impose agrave ceux qui enregistrent
des Gateways de les mettre agrave disposition agrave tous les autres utilisateurs de TTN Lrsquoobjectif est de
reacutealiser un reacuteseau global ouvert
522 Configuration de la Gateway A lrsquouniversiteacute nous avons deux Gateways LoRa (Marque EBDS) Elles sont toutes les deux situeacutees sur
le Campus de Technolac Une Gateway est agrave lrsquointeacuterieur du bacirctiment ISERAN et sert essentiellement
pour les Travaux Pratiques et formations Lrsquoautre est sur le toit du bacirctiment Chablais et est mise agrave
disposition du public via le service de TTN
Les deux Gateway eacutecoutent sur tous les canaux et sur tous les Spreading Factor SF7 gt SF12
Lrsquo IP de la Gateway LoRa agrave lrsquouniversiteacute (bacirctiment ISERAN) est 192168140196
Serveur DNS 1934812032 19348129137
Network Server (TTN) 137616868 routereuthethingsnetwork
Port Upstream 1700 Port Downstream 1700
523 Enregistrement des Gateways Appplication et Devices La configuration de TTN se fait en ligne La premiegravere opeacuteration agrave reacutealiser lorsqursquoune nouvelle
Gateway est deacuteployeacutee crsquoest de lrsquoenregistrer dans TTN
Enregistrement drsquoune Gateway LoRa TTN gt Console gt Gateway gt register gateway
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Figure 38 Scheacutema de notre application
| 40
Figure 39 Enregistrement dune Gateway LoRa sur TTN
Enregistrement drsquoune application TTN gt Console gt Application gt add application
Figure 40 Enregistrement dune application sur TTN
Enregistrement des Devices LoRa dans lrsquoapplication Nom de lrsquoapplication gt register device
Figure 41 Enregistrement des Devices LoRa dans une application
524 Configuration des Devices LoRa Lorsque nous avons enregistreacute des Devices LoRa dans TTN nous devons choisir entre les deux modes
drsquoauthentification Dans un premier temps nous utiliserons le mode le plus simple qui est ABP Nous
geacuteneacuterons dans TTN les DevAddr NetwkSKey et AppSKey
| 41
Figure 42 Configuration des Devices LoRa en ABP dans TTN
53 Mise en application Nous avons dans notre application 10 Devices LoRa drsquoenregistreacutes aduino0 agrave arduino9 Ils sont tous
configureacutes en ABP Les configurations des 10 Devices (DevAddr NetwkSKey et AppSKey) sont noteacutes
en commentaire dans le code de vous allez reacutecupeacuterer
Reacutecupeacuterer le code Arduino laquo RN2483-Arduino-LORAWANino raquo dans Moodle
Modifier votre configuration (DevAddr NetwkSKey et AppSKey) en fonction de votre
numeacutero de binocircme
Veacuterifier que votre Device LoRa arrive bien agrave transmettre des informations (Uplink) vers la
Gateway puis vers le Network Serveur de TTN (The Things Network)
54 Analyse des trames eacutechangeacutees
541 Utilisation de la base 64 Notre Gateway nous preacutesente le Payload PHY en base64 Lrsquoexplication de la meacutethode de
repreacutesentation en base 64 est fourni au travers drsquoun exemple Le code hexadeacutecimal 0x4869
repreacutesente nos donneacutees binaires que nous souhaitons transmettre en base 64
1 On eacutecrit les donneacutees agrave transmettre en binaire
2 On regroupe les eacuteleacutements binaires par des blocs de 6 bits Le nombre de bloc de 6 bits doit
ecirctre un multiple de 4 (minimum 4 blocs) Srsquoil manque des bits pour constituer un groupe de
6 bits on rajoute des zeacuteros
0x4869 = 0100 1000 0110 1001
| 42
3 Srsquoil manque des blocs pour faire un minimum de 4 blocs des caractegraveres speacuteciaux seront
ajouteacutes
4 Chaque groupe de 6 bits est traduit par le tableau suivant (Source Wikipeacutedia)
Figure 43 Codage en base 64
5 Si un bloc de 6 bits manque (ils doivent ecirctre un multiple de 4) on rajoute un ou plusieurs
compleacutements (caractegravere laquo = raquo )
Reacutesultat Le codage de 0x4869 en base 64 est laquo SGk= raquo
010010 000110 100100
On ajoute 00 pour avoir
6 bits dans le groupe
Bloc de 6 bits
010010 000110 100100
S G k
010010 000110 100100
S G k =
1er Bloc
2egraveme Bloc
3egraveme Bloc
4egraveme Bloc
| 43
542 Inteacuterecirct et inconveacutenient de la base 64 Lrsquoutilisation de la base 64 est un choix qui a eacuteteacute fait pour le protocole LoRa LoRaWAN afin de rendre
les donneacutees binaires lisibles Le problegraveme du code ASCII crsquoest qursquoil est composeacute drsquoun certain nombre
de caractegraveres non imprimables (EOF CR LFhellip) Pour eacuteviter ces soucis la base 64 ne comporte que
64 caractegraveres imprimables (voir tableau ci-dessus)
La restriction agrave 64 caractegraveres a cependant un inconveacutenient crsquoest que nous ne pouvons coder que 6
bits (26=64) au lieu de 8 La base 64 est donc moins efficace drsquoune faccedilon geacuteneacuterale
Nous cherchons agrave coder le code ASCII laquo AA raquo en base 64 Retrouver la deacutemarche en
montrant que le reacutesultat en base 64 est laquo QUE= raquo
543 Uplink Du Device LoRa au Network Server Le Network Server de TTN reccediloit des trames IP en provenance de la Gateway Comme nous lrsquoavons
vu preacuteceacutedemment un certain nombre drsquoinformations peuvent ecirctre retrouveacutees avec cette trame
(DevAddr SF Bandwidth etchellip) mais les donneacutees Applicatives sont bien sucircr chiffreacutees (avec
lrsquoAppkSKey) A ce niveau de reacuteception (sans connaitre lrsquoAppSKey) il nrsquoest donc pas possible de
comprendre la totaliteacute du message reccedilu
Imaginons que la trame IP reccedilue 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 45
timestamp 2019-03-05T140042448Z
rssi -82
snr 9
dev_addr 26011AD3
frequency 867300000
Le Network Server affiche donc les informations de la faccedilon suivante
Figure 44 Trame reacutecupeacutereacutee sur le laquo Network Server raquo de TTN
Nous retrouvons bien les valeurs fournies par la Gateway
timestamp ( agrave 1 heure pregraves en fonction du fuseau horaire)
| 44
frequency 8673 Mhz
modulation Lora
Coding Rate 45
data Rate SF 7 125 kHz (DR5)
air time 463 ms
Drsquoautres information proviennent de lrsquoanalyse du Payload Le Payload inscrit ici est le PHY Payload
Il y a donc une partie chiffreacutee (Frame Payload) mais les entecirctes sont en claires (voir paragraphe
441) Ce PHY Payload est laquo QNMaASYABwAP1obuUHQ= raquo Lorsque celui-ci est exprimeacute en
hexadeacutecimal au lieu de la base 64 il vaut laquo 40D31A01260007000FD686EE5074 raquo comme le montre
le Network Server de TTN
Figure 45 PHY Payload preacutesenteacute dans notre Network Server
Sa taille est bien de 14 octets (en hexadeacutecimal) comme preacuteciseacute sur la Figure 44
Nous reprenons le format de la trame LoRaWAN vu agrave la Figure 32 Nous pouvons alors retrouver
tous les champs de toute la trame
PHYPayload = 40D31A01260007000FD686EE5074
PHYPayload = MAC Header[1 octet] | MACPayload[] | MIC[4 octets]
MAC Header = 40 (Unconfirmed data up)
MACPayload = D31A01260007000FD6
Message Integrity Code = 86EE5074
MACPayload = Frame Header | Frame Port | FramePayload )
Frame Header = D31A0126000700
FPort = 0F
FramePayload = D6
Frame Header = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[015]
DevAddr = 26011AD3 (Big Endian)
FCtrl (Frame Control) = 00 (No ACK No ADR)
FCnt (Frame Counter) = 0007 (Big Endian)
FOpts (Frame Option) =
Vous pouvez veacuterifier lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN
(LoRaWAN packet decoder) httpsbitly2szdXtv
| 45
Figure 46 LoRaWAN packet decoder
544 Uplink Du Network Server agrave lrsquoApplication Server
Nous reprenons lrsquoexemple de la trame ci-dessus (Figure 45) Pour information les cleacutes NwkSKey et
AppSKey suivantes ont eacuteteacute utiliseacutee
NwkSKey E3D90AFBC36AD479552EFEA2CDA937B9
AppSKey F0BC25E9E554B9646F208E1A8E3C7B24
Le Network Server a deacutecodeacute lrsquoensemble de la trame Si le MIC est correct (authentification de la
trame par le NwkSKey) alors le Network Server va passer le contenu du message chiffreacute (Frame
Payload) agrave lrsquoApplication Server Dans notre cas le Frame Payload est (drsquoapregraves le deacutecodage effectueacute
au chapitre preacuteceacutedent)
FramePayload = D6
D6 est le contenu chiffreacute lorsqursquoil est deacutechiffreacute avec lrsquoAppSkey on trouve 01 Vous pouvez veacuterifier
lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN httpsbitly2szdXtv
A noter que lrsquoApplication Server recevra les donneacutees chiffreacutees seulement si le Device LoRa a bien
eacuteteacute enregistreacute On peut aussi veacuterifier ci-dessous que lrsquoApplication Serveur de TTN nous retourne bien
un payload (Frame Payload) de 01
Figure 47 Trame reacutecupeacutereacutee sur lrsquoApplication Server de TTN
time 2019-03-05T140042379279991Z
frequency 8673
modulation LORA
data_rate SF7BW125
coding_rate 45
gateways [
gtw_id eui-b827ebfffeae26f6
timestamp 2447508531
time
channel 4
rssi -82
snr 9
latitude 4563647
longitude 58721523
| 46
location_source registry
]
545 Simulation drsquoUplink dans lrsquoApplication Server
Dans beaucoup de situations nous souhaitons valider le fonctionnement de lrsquoApplication Server de
TTN ouet de notre propre Application Il est donc tregraves utile de pouvoir simuler lrsquoenvoi drsquoune trame
LoRa sur lrsquoApplication Server sans que celle-ci soit reacuteellement eacutemise par un Device LoRa Pour cela
un outil existe dans les Settings de chaque Device enregistreacute dans TTN Nous avons juste besoin de
speacutecifier le Frame Payload en clair en hexadeacutecimal et le numeacutero de Port
Figure 48 Simulation drsquoune trame envoyeacutee par un Device LoRa
546 Downlink De lrsquoApplication Server au Device LoRa La communication LoRa est bidirectionnelle Des donneacutees peuvent ecirctre transmis au Device LoRa
depuis lrsquoApplication Server Depuis TTN un outil existe dans les Settings de chaque Device
enregistreacute Lrsquointerface est repreacutesenteacutee ci-dessous
Figure 49 Transmission de donneacutees de lrsquo laquo Application Server raquo jusqursquoau Device LoRa
Replace scheduling Mode Par deacutefaut le Frame Payload transmis remplacera le Frame
Payload en attente (si il existe) Dans ce mode un seul Frame Payload est planifieacute
First scheduling Mode Le Frame Payload est mis en file drsquoattente en premiegravere position
Last scheduling Mode Le Payload est mis en file drsquoattente en derniegravere position
Une demande de confirmation peut ecirctre demandeacutee au Device LoRa pour qursquoil preacutecise srsquoil a bien reccedilu
les donneacutees Lrsquooption laquo confirmed raquo permet donc de speacutecifier le type de trame dans le MAC Header
(voir paragraphe 443) laquo Confirmed Data Down raquo ou laquo Unconfirmed Data Down raquo dans notre cas
| 47
6 La reacutecupeacuteration des donneacutees sur notre propre Application
Nous utiliserons agrave nouveau le Network Server et Application Server de The Things Network Jusqursquoici
nous nous sommes contenteacute de veacuterifier que les donneacutees de lrsquoutilisateur (Frame Payload) soient bien
arriveacutees agrave destination dans lrsquoApplication Server Il faut maintenant les reacutecupeacuterer avec notre propre
Application qui aura pour rocircle
De stocker et traiter les donneacutees
De les mettre agrave disposition de lrsquoutilisateur (Serveur Web par exemple)
Drsquoenvoyer des commandes de lrsquoutilisateur aux Devices LoRa si besoin (Flux Downlink)
Nous allons voir deux meacutethodes pour communiquer entre notre application et TTN
Le protocole HTTP POST
Le protocole MQTT
61 Reacutecupeacuteration des donneacutees en HTTP POST dans lrsquoApplication
611 Preacutesentation du protocole HTTP
Dans le monde de lrsquointernet le protocole HTTP est tregraves utiliseacute pour le dialogue entre un client et un
serveur web Classiquement le client (un navigateur web par exemple) fait une requecircte HTTP GET
et le serveur lui retourne le contenu de la page web demandeacutee
Dans notre cas la probleacutematique est diffeacuterente car le client doit modifier le contenu du serveur
avec les donneacutees envoyeacutees par le Device LORA La requecircte srsquoappelle HTTP POST Son nom indique
que le client va poster (et on pas reacutecupeacuterer) des donneacutees
Lrsquoutilisateur qui souhaite reacuteceptionner des donneacutees sur son serveur doit donc concevoir un serveur
HTTP capable de traiter des requecirctes HTTP POST [ requecircte noteacutee (1) sur la Figure 51 ] fournies par
TTN Dans cette configuration TTN jouera le rocircle de client et notre application le rocircle de serveur
Devices
LORA Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
HTTP POST
MQTT Internet
Figure 50 Structure globale drsquoun reacuteseau LORAWAN
| 48
Figure 51 Communication bidirectionnelle entre TTN et notre Application
A lrsquoinverse lrsquoutilisateur qui souhaite transmettre des donneacutees agrave destination du Device LoRa
(Downlink) doit ecirctre capable de fournir une requecircte HTTP POST [ requecircte noteacutee (2) sur la Figure 51
] vers TTN Dans cette configuration TTN jouera le rocircle de Serveur et notre application le rocircle de
client
612 Fonctionnement drsquoun client et drsquoun serveur HTTP POST Afin de bien comprendre le fonctionnement des requecirctes HTTP POST nous allons proceacuteder par
eacutetape Le premier test que nous effectuerons sera decorreacuteleacute de TTN Le principe est le suivant
Utilisation drsquoun serveur HTTP disponible sur le web geacuterant les requecirctes HTTP POST [
httpsrbasketsin ] ou [ httpsbeeceptorcom ] par exemple
Utilisation drsquoun client HTTP eacutemettant des requecirctes HTTP POST commande curl sous linux
ou logiciel Postman [ wwwgetpostmancom ] sous windows par exemple
Ce test nous permet de valider le fonctionnement drsquoun serveur HTTP POST et drsquoun client HTTP POST
Une fois que nous serons sucircr de leur fonctionnement nous les utiliserons avec TTN
The Things Network
Application
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 49
Figure 52 Validation dun server HTTP POST et drsquoun client HTTP POST
613 Test du serveur HTTP POST Nous utiliserons un serveur web proposeacute par httpsrbasketsin
Aller sur le site httpsrbasketsin et creacuteer un nouveau laquo Basket raquo Zone ougrave vous pourrez
visualiser les requecirctes qui ont eacuteteacute eacutemises vers votre serveur
A partir de maintenant toutes les requecirctes dirigeacutees vers lrsquoadresse creacuteeacute seront traiteacutees et
srsquoafficheront Dans le menu de configuration il est aussi possible de deacutefinir le contenu de la reacuteponse
qui sera fournie
Deacutefinir un format de reacuteponse pour les requecirctes HTTP POST avec un body personnaliseacute
614 Test du client HTTP POST On peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande (la commande cURL
srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN sous Windows
Commande cURL curl ndashX POST ndashd lsquorsquodonneacutees agrave envoyerrsquorsquo DuServeurHTTP
Logiciel Postman New gt Request gt Creacuteer une requecircte HTTP POST gt Send
Veacuterifier que les requecirctes HTTP POST sont bien reacutecupeacutereacutees sur votre serveur creacutee preacuteceacutedemment
615 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST
Maintenant que nous avons un serveur HTTP (POST) fonctionnel nous allons configurer TTN pour
jouer le rocircle du client et pour qursquoil envoie des requecirctes HTTP POST vers notre Serveur degraves qursquoune
donneacutee drsquoun Device LoRa est disponible Nous geacuterons donc ici le flux Uplink
Requecircte
HTTP POST
Reacuteponse
(contenu parameacutetrable)
Client HTTP (POST)
Server HTTP (POST) [ httpsrbasketsin ]
| 50
Figure 53 Reacutecupeacuteration des donneacutees sur notre Application
Dans TTN nous inteacutegrons un bloc appeleacute laquo HTTP Integration raquo permettant de jouer le rocircle de client
crsquoest-agrave-dire drsquoenvoyer des requecirctes HTTP POST agrave destination de notre nouveau Serveur HTTP
Lrsquointeacutegration se faire agrave partir de TTN gt Console gt Application gt Nom_de_votre_application gt
Integration
Figure 54 Ajout dun client HTTP POST dans TTN
Pour valider le fonctionnement de notre architecture nous pouvons soit
Envoyer une trame depuis un Device LoRa vers TTN
Simuler lrsquoenvoi drsquoune trame drsquoun Device LoRa vers TTN (gracircce agrave lrsquooutil proposeacute par TTN vu
paragraphe 545)
Dans les deux cas voici un exemple de requecircte POST reccedilue sur notre serveur HTTP
app_id test_app_lorawan_sylvainmontagny
dev_id stm32lorawan_1
hardware_serial 0056AF49877
port 1
counter 0
payload_raw qg==
metadata
Requecircte
HTTP POST
Server HTTP (POST) [ httpsrbasketsin ]
The Things Network (Client)
La requecircte contient le Frame Payload deacutechiffreacutee
agrave transmettre agrave lrsquoApplication
| 51
time 2019-01-24T15243703499298Z
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Comme nous pouvons le voir le contenu fourni agrave notre serveur est formateacute en JSON (voir
paragraphe 0) Voici quelques compleacutements drsquoinformation
payload_raw Frame Payload deacutechiffreacute crsquoest donc les donneacutees en clairs dans la base 64
downlink_url URL du serveur HTTP POST qui serviront agrave transmettre des donneacutees au Device
LoRa (flux Downlink)
611 Envoyer des donneacutees depuis notre Application avec HTTP POST
Lorsque nous avons ajouteacute le bloc laquo HTTP Integration raquo au paragraphe preacuteceacutedent nous avons aussi
implicitement activeacute la fonctionnaliteacute que TTN soit precirct agrave recevoir et agrave traiter les requecirctes HTTP
POST La seule information qursquoil nous manque est lrsquoadresse du server HTTP vers lequel il faut eacutemettre
les requecirctes Si on observe la trame reccedilue preacuteceacutedemment en provenance de TTN on srsquoaperccediloit que
dans la trame JSON reccedilu une URL (downlink_url) est speacutecifieacutee
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Crsquoest cette URL que nous devrons utiliser Nous allons nous placer dans la configuration suivante
Figure 55 Envoi de donneacutees agrave partir de notre Application
Comme preacuteceacutedemment on peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande
(la commande cURL srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN
Commande cURL curl ndashX POST ndashdata lsquo dev_id Identidiant_De_Votre_Device
payload_raw AQE= rsquo DuServeurHTTP
Logiciel Postman New gt Request gt HTTP POST puis Body gt Raw gt JSON
Requecircte HTTP POST vers serveur TTN laquo downlink_url raquo httpsintegrationsthethingsnetworUaeb8ypKieQ
Contenu de la requecircte
dev_id Identidiant_De_Votre_Device
payload_raw aGVsbG8=
The Things Network (Serveur)
POSTMAN (Client HTTP POST)
| 52
dev_id YourDeviceID
payload_raw aGVsbG8=
Vous devez envoyer le texte (payload_raw) en base 64 Dans lrsquoexemple ci-dessus laquo aGVsbG8= raquo
correspond agrave la chaine de caractegravere laquo hello raquo Vous pouvez utiliser les nombreux encodeurdecodeur
en ligne pour vous aider Le texte doit srsquoafficher sur votre moniteur seacuterie Arduino dans le cadre de
notre deacutemonstrateur sur Arduino
62 Reacutecupeacuteration des donneacutees avec MQTT dans lrsquoApplication
621 Preacutesentation du protocole MQTT
MQTT est un protocole leacuteger qui permet de srsquoabonner agrave des flux de donneacutees Plutocirct que
lrsquoarchitecture Client Serveur classique qui fonctionne avec des Requecirctes Reacuteponses MQTT est
baseacute sur un modegravele Publisher Subscriber La diffeacuterence est importante car cela eacutevite davoir agrave
demander (Requecircte) des donneacutees dont on na aucune ideacutee du moment ougrave elles vont arriver Une
donneacutee sera donc directement transmise au Subscriber degraves lors que celle-ci a eacuteteacute reccedilue dans le
Broker (serveur central)
Figure 56 Modegravele Publisher Subscriber du protocole MQTT
Pour recevoir les donneacutees appartenant agrave un Topic un Subscriber doit souscrire (comme son nom
lindique) au preacutealable sur ce Topic
MQTT est un protocole qui repose sur TCP Lencapsulation des trames sur le reacuteseau est donc la
suivante
Broker
Client
Publisher 1
Client
Publisher 2
Client
Subscriber
Topic
Tempeacuterature
Topic
Humiditeacute
| 53
Figure 57 Protocoles utiliseacutes pour la communication avec MQTT
On peut le veacuterifier par une capture de trame sur Wireshark
Figure 58 Capture dune trame MQTT avec Wireshark
On peut noter que le port TCP utiliseacute pour le protocole MQTT (non chiffreacute) est le 1883
Les Publishers et les Subscribers nrsquoont pas besoin de se connaitre
Les Publishers et les Subscribers ne sont pas obligeacute de srsquoexeacutecuter en mecircme temps
622 Connexion au Broker MQTT Nous nous inteacuteresserons essentiellement aux options de connexion qui permettront de geacuterer la
Qualiteacute de Service (QoS) Pour se connecter un client MQTT envoie deux informations importantes
au Broker
keepAlive Cest la peacuteriode la plus longue pendant laquelle le client Publisher ou Subscriber pourra
rester silencieux Au-delagrave il sera consideacutereacute comme deacuteconnecteacute
cleanSession Lorsque le Client et le Broker sont momentaneacutement deacuteconnecteacutes (au-delagrave du
keepAlive annonceacute) on peut donc se poser la question de savoir ce quil se passera lorsque le client
sera agrave nouveau connecteacute
Si la connexion eacutetait non persistante (cleanSession = True) alors les messages non transmis
sont perdus Quel que soit le niveau de QoS (Quality of Service)
Si la connexion eacutetait persistante (cleanSession = False) alors les messages non transmis
seront eacuteventuellement reacuteeacutemis en fonction du niveau de QoS Voir le chapitre 624
623 Qualiteacute de Service au cours dune mecircme connexion
A partir du moment ougrave le Client se connecte au Broker il est possible de choisir un niveau de fiabiliteacute
des transactions Le Publisher fiabilise leacutemission de ces messages vers le Broker et le Subscriber
fiabilise la reacuteception des messages en provenance du Broker Une parle ici du cas dune mecircme
connexion crsquoest-agrave-dire entre le moment ou le Client se connecte et le moment ougrave
Soit il se deacuteconnecte explicitement (Close connexion)
Soit il na rien eacutemis ni fait signe de vie pendant le temps keepAlive
TCP
MQTT
Reacuteseau
Transport
Couche Application
IP
| 54
Lors dune mecircme connexion la Qualiteacute de Service (QoS) qui est mise en œuvre deacutepend uniquement
de la valeur du QoS selon les valeurs suivantes
QoS 0 At most once (au plus une fois) Le premier niveau de qualiteacute est sans acquittement Le
Publisher envoie un message une seule fois au Broker et le Broker ne transmet ce message quune
seule fois aux Subscribers Ce meacutecanise ne garantit pas la bonne reacuteception des messages MQTT
QoS 1 At least once (au moins une fois) Le deuxiegraveme niveau de qualiteacute est avec acquittement
Le Publisher envoie un message au Broker et attends sa confirmation De la mecircme faccedilon le Broker
envoie un message agrave ces Subscriber et attends leurs confirmations Ce meacutecanisme garantit la
reacuteception des message MQTT
Cependant si les acquittements nrsquoarrivent pas en temps voulu ou srsquoils se perdent la reacuteeacutemission du
message dorigine peut engendrer une duplication du message Il peut donc ecirctre reccedilu plusieurs fois
QoS 2 Exactly once (exactement une fois) Le troisiegraveme niveau de qualiteacute est garanti une seule
fois Le Publisher envoie un message au Broker et attends sa confirmation Le Publisher donne alors
lrsquoordre de diffuser le message et attends une confirmation Ce meacutecanisme garantit que quel que
soit le nombre de tentatives de reacuteemission le message ne sera deacutelivreacute quune seule fois
La Figure 59 montre les trames eacutemises pour chaque niveau de QoS
Figure 59 Qualiteacute de Service en MQTT
La Figure 60 repreacutesentes les 3 captures de trames sur Wireshark repreacutesentant les 3 QoS (1 2 et 3)
que nous venons dexpliquer
Broker
QoS 0
Au plus une fois
Message supprimeacute apregraves envoi
PUBLISH
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Duplications possibles
PUBLISH
PUBLICH Ack
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Pas de duplication
PUBLISH
PUBLISH Receive
PUBLISH Release
PUBLISH Complete
| 55
Figure 60 Capture de trame avec QoS = 0 puis QoS = 1 puis QoS = 2
624 Qualiteacute de Service apregraves une reconnexion
La question que nous nous posons et de savoir ce que deviennent les messages publieacutes sur le Broker
lorsquun ou plusieurs Subscribers sont momentaneacutement injoignables Il est possible de conserver
les messages qui ont eacuteteacute publieacutes sur le Broker afin de les retransmettre lors de la prochaine
connexion Cette possibiliteacute de sauvegarde doit ecirctre activeacutee agrave louverture de connexion gracircce au flag
cleanSession = 0 La connexion sera alors persistante crsquoest-agrave-dire que le Broker enregistre tous les
messages quil na pas reacuteussi agrave diffuser au Subscriber
Le Tableau 9 reacutesume leffet du flag cleanSession et du QoS
Clean Session Flag Subscriber QoS Publisher QoS Comportement True ( = 1) 0 1 2 0 1 2 Messages perdus
False ( = 0 ) 0 0 1 2 Messages perdus
False (= 0 ) 0 1 2 0 Messages perdus
False (= 0 ) 1 2 1 2 Tous les messages sont retransmis
Tableau 9 Qualiteacute de Service en fonction de la valeur du QoS et du flag cleanSession
625 Les Topics du protocole MQTT Les chaicircnes deacutecrivant un sujet forment une arborescence en utilisant la barre oblique comme
caractegravere de seacuteparation La Figure 61 et le Tableau 10 donne un exemple dorganisation de Topic
Figure 61 Exemple de hieacuterarchie de Topic MQTT
Niveau 3
Niveau 2
Niveau 1 Maison
Chambre
Temperature Humidite Bruit
Salon
Temperature
| 56
Nom du Topic Deacutetail du Topic MaisonChambreTemperature La tempeacuterature de la chambre de la maison
MaisonChambreBruit Le bruit de la chambre de la maison
MaisonSalonTemperature La tempeacuterature du Salon de la maison
Tableau 10 Exemple de Topic
Un client peut sabonner (ou se deacutesabonner) agrave plusieurs branches de larborescence agrave laide de
jokers englobant plusieurs Topics Deux caractegraveres jokers existent
Le signe plus + remplace nimporte quelle chaine de caractegravere sur le niveau ougrave il est placeacute
Le diegravese remplace nimporte quelle chaine de caractegravere sur tous les niveaux suivants Il
est obligatoirement placeacute agrave la fin
Nom du Topic Deacutetail du Topic Maison+Temperature Les tempeacuteratures de toutes les piegraveces de la maison
MaisonChambre La tempeacuterature lhumiditeacute et le bruit de la chambre de la maison
Tableau 11 Exemple de Topic
626 Mise en place drsquoun Broker MQTT Afin de bien comprendre le fonctionnement du protocole de MQTT on reacutealise des tests
indeacutependamment de TTN Nous allons mettre en place
Un Broker Mosquitto httpstestmosquittoorg
Un client Publisher MQTT Box sur Windows
Un client Subscriber MQTT Box sur Windows
Figure 62 Test du protocole MQTT
MQTT Client (Subscriber)
MQTT Client (Publisher)
Publish
Subscribe
BROKER (Mosquitto)
| 57
Le Broker MQTT est commun agrave tout le monde Nous pouvons soit le reacutealiser nous-mecircme soit utiliser
un Broker MQTT public de test Nous utiliserons le Broker de test de Mosquitto disponible sur
httpstestmosquittoorg Drsquoautres sont eacuteventuellement disponibles en cas de problegraveme par
exemple httpwwwmqtt-dashboardcom
Si nous deacutecidions de le reacutealiser nous-mecircme agrave lrsquoaide drsquoune Raspberry Pi (par exemple) Lrsquoinstallation
se ferait en deux lignes de commande
apt-get install mosquito Installation
sudo systemctl start mosquittoservice Lancement du service
Il est neacutecessaire drsquoinstaller mosquitto-clients si on souhaite que le Raspberry PI joue aussi le rocircle de
client ce qui nrsquoest pas notre cas
627 Mise en place drsquoun Publisher et drsquoun Subscriber MQTT Lancer le logiciel MQTTBox
MQTTBox gt Create MQTT Client
Dans ce client les seuls champs indispensables sont
Protocol MQTT TCP
Host testmosquittoorg
Figure 63 Configuration dun Client MQTT dans MQTT Box
Tester lrsquoenvoi et la reacuteception sur les Topics de votre choix
628 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT La reacutecupeacuteration des donneacutees fait reacutefeacuterence au flux Uplink Dans ce cas
TTN joue le rocircle de client Publisher
TTN joue aussi le rocircle de Broker
Notre application joue le rocircle de Subscriber
Nous pouvons donc repreacutesenter lrsquoapplication globale par le scheacutema suivant
| 58
Figure 64 Publisher et Subscriber dans en MQTT avec TTN
La publication est repreacutesenteacutee par la trame MQTT (1)
La souscription est repreacutesenteacutee par la trame MQTT (2)
Le client Publisher eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box mais cette fois avec la configuration suivante
Protocol mqtt tcp
Host Crsquoest lrsquoIP du Broker vers lequel il faut se connecter Dans notre cas il srsquoagit de celui
de TTN dont lrsquoadresse est euthethingsnetwork
Username La connexion vers le broker MQTT est soumis agrave une authentification Username
Password Dans notre cas le Username correspond au nom de notre application crsquoest-agrave-
dire seminaire_lorawan Si vous avez choisi une autre applicationil faut bien mettre la
votre
Password Le Password est nommeacute laquo Access Key raquo par TTN Elle vous sera donneacutee par
lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application vous
trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt Overview
Figure 65 Access Keys de lapplication dans TTN
The Things Network (Application Server)
BROKER
Application
The Things Network (Network Server)
Publish (1 )
[ Flux Uplink ]
Subscribe (2 )
[ Flux Uplink ]
| 59
Figure 66 Configuration du Client dans MQTT Box
Le client MQTT eacutetant configureacute il est maintenant capable de se connecter au Broker Il reste donc agrave
deacutefinir le fait que le client sera Subscriber Les informations que recevra le Subscriber deacutependent du
Topic auquel nous souscrivons Voici les Topic disponibles sur le Broker de TTN
ltAppIDgt correspond au nom de votre Application
ltDevIDgt correspond au nom de votre Device LoRa
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink ltAppIDgtdevicesltDevIDgtup
[Donneacutees] Flux Downlink ltAppIDgtdevicesltDevIDgtdown
[Activation Events] Activation dun Device ltAppIDgtdevicesltDevIDgteventsactivations
[Management Events] Creacuteation dun Device ltAppIDgtdevicesltDevIDgteventscreate
[Management Events] Update dun Device ltAppIDgtdevicesltDevIDgteventsupdate
[Management Events] Suppression dun Device ltAppIDgtdevicesltDevIDgteventsdelete
[Downlink Events ] Message programmeacute ltAppIDgtdevicesltDevIDgteventsdownscheduled
[Downlink Events ] Message envoyeacute ltAppIDgtdevicesltDevIDgteventsdownsent
[Erreurs] Uplink erreurs ltAppIDgtdevicesltDevIDgteventsuperrors
[Erreurs] Downlink erreurs ltAppIDgtdevicesltDevIDgteventsdownerrors
[Erreurs] Activations erreurs ltAppIDgtdevicesltDevIDgteventsactivationserrors
Tableau 12 Topics enregistreacutes dans TTN
Dans un premier temps nous souscrivons au Topic +devices+up Cela signifie que nous
souscrivons agrave tous les Devices LoRa de toutes nos applications pour le flux Uplink
Figure 67 Configuration du Subscriber
Les eacuteleacutements eacutemis par le Broker seront alors afficheacutes dans MQTTBox La
| 60
Figure 68 Trame LoRaWAN reccedilu sur le Subscriber MQTT
Ces donneacutees sont eacutecrites en JSON nous pouvons les remettre en forme
applicationID3
applicationNamemyApplication
deviceNamearduino0
devEUI0056xxxxxxxxx877
txInfo
frequency868500000
dr5
adrfalse
fCnt792
fPort15
dataSGVsbG8=
Le Frame Payload deacutechiffreacute est fourni dans le champ data en base 64 La valeur fournie par
dataSGVsbG8= correspond bien agrave la chaine de caractegravere hello que nous avons eacutemise avec le
Device LoRa
629 Envoyer des donneacutees depuis notre Application avec MQTT
Lrsquoenvoi des donneacutees fait reacutefeacuterence au flux Downlink Dans ce cas
Notre application joue le rocircle de Publisher
TTN joue le rocircle de Broker
TTN joue aussi le rocircle de client Subscriber
| 61
La publication est repreacutesenteacutee par la trame MQTT (3)
La souscription est repreacutesenteacutee par la trame MQTT (4)
Le client Subscriber eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box Le rocircle de client dans MQTT Box a eacuteteacute faite au
paragraphe 628 Il nous reste simplement agrave ajouter le rocircle de Publisher La configuration est la
suivante
Topic du Subscriber seminaire_lorawandevicesarduino0down ougrave seminaire_lorawan
est agrave remplacer par le nom de votre application et arduino0 par le nom du Device LoRa vers
lequel vous souhaitez envoyeacute une donneacutee (Voir chapitre 628 pour comprendre les Topics)
Le Payload doit ecirctre au format JSON Lrsquoexemple suivant envoie laquohello raquo
payload_raw aGVsbG8=
The Things Network (Application Server)
BROKER
Application
Publish (3)
[ Flux Downlink ]
The Things Network (Network Server)
Subscribe (4)
[ Flux Downlink ]
| 62
Figure 69 Configuration du Publisher
Vous devriez voir les donneacutees arriver sur votre Device LoRA
| 63
7 Creacuteation de notre propre Network et Application Server
711 Objectifs Lors de la mise en œuvre du reacuteseau LoRaWAN au chapitre 52 nous avons utiliseacute TTN (The Things
Network) pour jouer le rocircle de Network Server et drsquoApplication Server Pour de multiples raisons
Seacutecuriteacute autonomie coucircthellipil peut ecirctre inteacuteressant de monter soi-mecircme un Network Server et un
Application Server Cela est possible seulement si vous posseacutedez vos propres Gateway puisque
celles-ci devront forwarder leur paquet agrave destination preacutecise Il faudra donc les reconfigurer pour
qursquoelles pointent vers votre nouvelle architecture
712 Preacutesentation de LoRaServer LoRaServer [ wwwloraserverio ] est un projet Open-Source reacutepondant exactement au besoin que
nous avons Nous lrsquoutiliserons sur une cible Raspberry PI En reacutealiteacute il peut souvent ecirctre mise en
place dans le mecircme systegraveme que la Gateway surtout si celle-ci est elle-mecircme agrave base de RPI Les
Gateway EBDS que nous posseacutedons possegravedent drsquoailleurs un Network Server et un Application Server
que nous aurions pu utiliser Neacuteanmoins pour des raisons peacutedagogiques il est inteacuteressant de
seacuteparer les systegravemes pour bien diffeacuterencier les probleacutematiques
Attention il y a une ambiguiumlteacute dans la deacutenomination des entiteacutes logiciels de LoRaServer
LoRaServer (sans espace entre le mot LoRa et Server) est le nom du projet global En
revanche LoRa Server (avec un espace) est le nom du service qui joue le rocircle du Network
Server
Lrsquoarchitecture et le fonctionnement de LoRaServer est preacutesenteacutee dans sa documentation par le
scheacutema suivant
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Raspberry PI
Figure 70 Architecture globale de notre reacuteseau loRaWAN
| 64
Figure 71 Architecture deacutetailleacutee de LoRaServer
On srsquoattends agrave voir uniquement un Network Server (LoRa Server) et un Application Server (LoRa App
Server) mais ce scheacutema est plus complexe Il demande un certain nombre drsquoexplications pour bien
comprendre ce que nous allons installer et la faccedilon dont nous lrsquoutiliserons par la suite
713 Le laquo Packet Forwarder raquo (Gateway) Comme nous lrsquoavons vu au chapitre 412 les Gateways LoRa sont des passerelles entre la
modulation LoRa et un reacuteseau IP Pour reacutealiser cette passerelle un service nommeacute laquo UDP Packet
Forwarder raquo a eacuteteacute deacuteveloppeacute par Semtech httpsgithubcomLora-netpacket_forwarder Dans
ce dossier github un fichier nommeacute PROTOCOLTXT explique parfaitement ce protocole applicatif
qui travaille au-dessus de UDP
Figure 72 Protocole Uplink (PUSH_DATA du Packet Forwarder)
| 65
On remarque que les paquets sont envoyeacutes en UDP au Network Server dans une trame appeleacutee
PUSH_DATA Cette trame est acquitteacutee par le Network Server par une trame appeleacutee PUSH_ACK
Sur notre Network Server nous pouvons reacutealiser une capture de trame pour veacuterifier si le protocole
est bien celui preacutesenteacute dans le document
Figure 73 Trame captureacutee par Wireshark lors dun Uplink
Drsquoapregraves la capture preacuteceacutedente on remarque que le Packet Forwarder fonctionne bien avec UDP sur
le port 1700
Le contenu des donneacutees (champ Data) est deacutetailleacute dans le tableau suivant
Champ | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | random token
[3] | 3 | PUSH_DATA identifier = 0x00
[4] | 4-11 | Gateway unique identifier (MAC address)
[5] | 12-end | JSON object starting with ending with
Lrsquoobjet JSON de la transmission reacuteeacutecrit plus proprement est celui-ci
Figure 74 Analyse du champ Donneacutees du protocole laquo Packet Forwarder raquo
0000 02 f9 30 00 b8 27 eb ff fe ae 26 f5 7b 22 72 78 0amprx 0010 70 6b 22 3a 5b 7b 22 74 6d 73 74 22 3a 33 37 35 pk[tmst375 0020 35 30 30 35 38 31 39 2c 22 63 68 61 6e 22 3a 32 5005819chan2 0030 2c 22 72 66 63 68 22 3a 31 2c 22 66 72 65 71 22 rfch1freq 0040 3a 38 36 38 2e 35 30 30 30 30 30 2c 22 73 74 61 868500000sta 0050 74 22 3a 31 2c 22 6d 6f 64 75 22 3a 22 4c 4f 52 t1moduLOR 0060 41 22 2c 22 64 61 74 72 22 3a 22 53 46 37 42 57 AdatrSF7BW 0070 31 32 35 22 2c 22 63 6f 64 72 22 3a 22 34 2f 35 125codr45 0080 22 2c 22 6c 73 6e 72 22 3a 36 2e 35 2c 22 72 73 lsnr65rs 0090 73 69 22 3a 2d 31 2c 22 73 69 7a 65 22 3a 31 38 si-1size18 00a0 2c 22 64 61 74 61 22 3a 22 51 4e 4d 61 41 53 59 dataQNMaASY 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 ]
Ch
amp
[1
]
Ch
amp
[2
]
Ch
amp
[3
]
Ch
amp
[4
]
| 66
rxpk[ tmst3755005819
chan2
rfch1
freq868500000
stat1
moduLORA
datrSF7BW125
codr45
lsnr65
rssi-1
size18
dataQNMaASYAAQAPpyPZ955+SmY
]
Le champ data correspond au PHY Payload
De la mecircme faccedilon on retrouve la Trame drsquoacquittement
Figure 75 Trame captureacutee par Wireshark lors de lrsquoacquittement drsquoun Uplink
Champs | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | same token as the PUSH_DATA to acknowledge
[3] | 3 | PUSH_ACK identifier = 0x01
Nous retrouvons bien tous ces champs dans la trame Wireshark
714 LoRa Gateway Bridge Nous avons deacutecrit au chapitre preacuteceacutedent (713) le fonctionnement du Packet Forwarder Le
Network Server(Lora Server) que nous allons mettre en place aurait tregraves bien pu srsquointerfacer
directement agrave ce protocole Mais cela aurait plusieurs impacts dont un qui est important dans la
conception de logiciel Si le Packet Forwarder change ou si un autre type de Forwarder est utiliseacute
alors lrsquoutilisation du LoRa Server devient impossible Il a donc eacuteteacute choisi de creacuteer une eacutetape
intermeacutediaire Le Network Server que nous mettrons en plus utilisera le protocole MQTT plutocirct que
le protocole UDP packet Forwarder
En drsquoautres termes le LoRa Gateway Bridge est un service qui fera abstraction du Packet Forwarder
pour srsquointerfacer plus simplement avec le Network Server
715 LoRa Server (Network Server) Il srsquoagit de notre Network Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
413 Cependant il srsquointerfacera au protocole MQTT en recevant les informations agrave partir du
Broker au lieu de recevoir directement les trames en provenance de la Gateway
| 67
716 LoRa App Server (Application Server) Il srsquogit de notre Application Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
414
717 LoRa Geo Server Il srsquoagit drsquoun service qui permet drsquoutiliser certaines proprieacuteteacutes du protocole LoRa pour proposer un
service de geacuteolocalisation des Devices LoRa Nous ne lrsquoutiliserons pas dans notre cas
718 Application Il srsquoagit de notre Application qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre 415
Elle ne fait pas partie du projet LoRaServer crsquoest donc bien toujours agrave nous de proposer notre propre
Application
Figure 76 Les interfaces possibles entre LoRaServer et lrsquoApplication utilisateur
Comme nous pouvons le voir sur la figure preacuteceacutedente deux possibiliteacutes sont offertes pour interfacer
notre application JSON REST (incluant HTTP POST) et via un Broker MQTT Ces deux meacutethodes ont
deacutejagrave eacuteteacute traiteacutee au chapitre 61 (HTTP POST ) et au chapitre 62 (MQTT) Nous verrons aussi drsquoautres
possibiliteacutes pour personnaliser notre application au chapitre 7
72 Installation de LoRaServer
721 Mise en place de lrsquoenvironnement
Nous allons installer une carte SD avec la derniegravere version de Raspbian Nous ne deacutetaillerons pas la
deacutemarche pour cela car elles sont largement documenteacutees et mises agrave jour sur le site
wwwraspberrypiorg
Installer un carte SD avec la derniegravere version de Raspbian
Plutocirct que de fonctionner avec un clavier et une souris nous preacuteconisons de travailler agrave distance
avec la RPI via une connexion SSH Depuis quelques anneacutees Raspbian a supprimeacute le deacutemarrage du
service SSH au boot Heureusement il est possible de le reacuteactiver par la meacutethode suivante
Avec Windows ou Linux ouvrir la partition BOOT de votre carte SD et placer un fichier agrave la
racine nommeacute sshtxt (ou ssh)
Mettre la carte SD dans votre RPI et la deacutemarrer
| 68
Pour acceacuteder agrave la RPI en SSH depuis Windows nous utiliserons de preacutefeacuterence le logiciel
client MobaXterm mais tout autre client SSH est valable
Installer MobaXterm sur votre PC et connectez-vous agrave votre Raspberry PI
Lrsquoutilisation drsquoun espion de reacuteseau type Wireshark peut ecirctre inteacuteressant pour eacutetudier les trames qui
sont reccedilues et qui sont eacutemises Cela nous permettra de valider le fonctionnement des diffeacuterents
protocoles reacuteseau qui permettent de communiquer agrave la Gateway drsquoune part et agrave lrsquoApplication
drsquoautre part Nous utiliserons tshark
apt-get install tshark installation
tshark ndashn -i eth0 Exemple drsquoune analyse sur lrsquointerface wlan0
722 Installation sur la Raspberry PI La meacutethode drsquoinstallation de LoRaServer est documenteacutee sur le site web agrave lrsquoadresse suivante
[ httpswwwloraserverioguidesdebian-ubuntu ] Nous installerons le LoRa Gateway Bridge
le LoRa Server et le LoRa App Server
Apregraves lrsquoinstallation la configuration se fait par une interface graphique accessible par le reacuteseau sur
le port 8080
Si vous travaillez sur la RPI connectez-vous sur httplocalhost8080
Si vous travaillez agrave distance (SSH) connectez-vous sur httpIP_RPI8080
Les Usernames et Password par deacutefaut sont
Username admin
Password admin
Lrsquoeacutecran drsquoaccueil sera donc le suivant
Figure 77 Architecture globale apregraves installation de LoRaServer
Devices
Gateways LoRa
UDP Packet Forwarder
Application Server
LoRa App Server
Internet
Network Server
LoRa Server
LoRa Gateway Bridge
| 69
Figure 78 Ecran daccueil de LoRaServer apregraves authentification
71 Configuration de LoRa Server pour lUplink
711 Enregistrement drsquoune nouvelle Organisation
Pour enregistrer une nouvelle Organizations Organizations gt Create Puis entrer les configurations
suivantes
Figure 79 Enregistrement dun nouvelle Organisation
712 Enregistrement drsquoune instance du Network Server Pour enregistrer une nouvelle instance du Network Server Network Server gt Create Puis entrer
les configurations suivantes
| 70
Figure 80 Enregistrement dun nouveau Network Server
Dans lrsquoonglet Gateway Discovery il est possible drsquoactiver une option de deacutecouverte de Gateway aux
alentours Lorsqursquoelle est configureacutee le Network Server va envoyer une trame Downlink de
configuration de la Gateway lui ordonnant de reacutealiser des PING en LoRa La configuration du
Gateway Discovery preacutevoit de speacutecifier
Le nombre de fois par jour que les PING LoRa sont envoyeacutes
Le canal drsquoeacutemission
Le Data Rate (Voir paragraphe 445)
Un PING LoRa reccedilu sur une Gateway sera retransmis sur le Network Server (Lora Server) et une carte
sera afficheacutee
Lrsquoonglet TLS Certificates ne sera pas utiliseacute dans le cadre de notre deacutemonstration
713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) Il faut tout drsquoabord faire un enregistrement drsquoun laquo service-profile raquo Un laquo service profile permet de
faire la connexion entre le Network Server et les Applications que nous enregistrerons dans notre
Organisation Service-profiles gt Create
Service-profile name myServiceProfile
Network-server myNetworkServer
On laissera par deacutefaut toutes les autres options
Pour enregistrer une nouvelle Application Applications gt Create Puis entrer les configurations
suivantes
| 71
Figure 81 Enregistrement dune nouvelle Application
714 Enregistrement des Devices LoRa Il faut tout drsquoabord faire lrsquoenregistrement drsquoun Device-profile pour les Devices LoRa que vous
souhaitez connecter Dans notre cas nous ferons un premier test en speacutecifiant que nous utilisons
seulement le mode drsquoauthentification ABP (voir chapitre 431) Devices profile gt Create
Figure 82 Enregistrement dun laquo Device profile raquo
Nous pouvons alors creacuteer dans notre Application des nouveaux Devices Application gt
myApplication gt Create
| 72
Figure 83 Enregistrement dun nouveau Device LoRa
Dans la fenecirctre Activation on va alors configurer les 3 eacuteleacutements indispensables agrave une
authentification en APB Le DevAddr le NwkSKey et lrsquoAppSKey
Figure 84 Configuration de lenregistrement du Device LoRa (en ABP)
La configuration minimale de LoRaServer est maintenant termineacutee Nous pouvons donc brancher
un Device LoRa qui possegravede les les attribus (DevAddr NwkSKey et AppSKey) que nous avons
enregistreacute dans LoRaServer et le faire eacutemettre
715 Visualisation des trames reccedilues Les trames eacutemises par le Device LoRa vont donc parcourir le cheminement suivant
| 73
Figure 85 Reacutesumeacute du cheminement des trames LoRaWan en Uplink avec LoRaServer
En allant dans le Live Device Data (Application gt Nom_du_Device gt Live Device Data) on peut voir la
liste des trames reccedilues ainsi que les donneacutees applicatives deacutechiffreacutees
Figure 86 Reacuteception des trames des Devices LoRa
Figure 87 Analyse des trames des Devices LoRa
Dans lrsquoonglet LIVE LORAWAN FRAME nous pouvons voir les trames LORAWAN et si besoin eacutetudier
le contenu de ce qursquoelles contiennent En revanche les donneacutees applicatives sont ici chiffreacutees
UDP
Packet Forwarder
LoRa Bridge
Gateway LoRa Server LoRa App Server
Gateway
Server
Internet
| 74
Figure 88 Reacuteception des Trames LoRaWAN
72 Configuration de LoRaServer pour linteacutegration dApplication Nous avons vu dans le chapitre 718 que linterface entre LoRaServer et notre Application pouvait
ecirctre reacutealiseacutee soit par MQTT soit par les meacutethodes REST (HTTP POST) Nous avons deacutejagrave impleacutementeacute
et expliqueacute ces protocoles dans le cadre de son utilisation avec TTN Nous allons donc juste
configurer LoRaServer pour tester ces deux meacutethodes
721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST Nous utiliserons exactement la mecircme meacutethode que celle que nous avons utiliseacute avec TTN au
chapitre 615 Les diffeacuterentes Clients et Serveurs disponibles pour ces tests sont expliqueacutes au
paragraphe 612
Dans LoRaServer ajouter une inteacutegration HTTP LoRaServer gt Applications gt myApplication gt
Integrations gt Create gt HTTP Integration et la configurer comme le montre la Figure 89 Vous
remplacerez eacutevidement le lien par votre propre Endpoints
Figure 89 Configuration de linteacutegration HTTP POST dans LoRaServer
En envoyant des trames LoRa depuis votre Device vous devriez voir les contenus JSON sur votre
Endpoint
722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT Nous allons nous connecter au Broker MQTT de LoRaServer Pour cela nous utiliserons la mecircme
meacutethode que celle que nous avons utiliseacute avec TTN au chapitre 628 Nous utiliserons MQTTBox
comme nous lavons deacutejagrave fait au paragraphe 627
Le Broker de LoRaServer a enregistreacute les Topics suivant
[applicationID] correspond au nom de votre Application
[devEUI] correspond au nom de votre Device LoRa
| 75
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink application[applicationID]device[devEUI]rx
[Donneacutees] Flux Downlink application[applicationID]device[devEUI]tx
[Status] Statut dun Device application[applicationID]device[devEUI]status
[Ack] Acquittement des messages application[applicationID]device[devEUI]ack
[Erreurs] Erreurs application[applicationID]device[devEUI]error
Tableau 13 Topics enregistreacutes dans LoRaServer
| 76
8 Creacuteation de notre propre Application
81 Utilisation de Node-RED
811 Preacutesentation Node-RED est un outil de programmation graphique qui permet de faire communiquer les
peacuteripheacuteriques mateacuteriels drsquoun systegraveme sans eacutecrire de code De nombreux protocoles sont aussi pris
en charge au travers de bloc ( Node) qursquoil suffit de connecter entre eux pour reacutealiser simplement
une application Il peut srsquoexeacutecuter localement sur un PC ou sur des cibles embarqueacutees telle qursquoune
Raspberry PI (RPI)
Dans les deacutemonstrations que nous mettrons en œuvre nous utiliserons une RPI Par soucis de
simpliciteacute nous utiliserons les derniegraveres versions de Raspbian (systegraveme drsquoexploitation de la RPI) qui
integravegre drsquoorigine Node-RED Il nrsquoy a donc tregraves peu de chose agrave mettre en place pour arriver agrave mettre
en place une Application Nous pouvons travailler soit directement sur la RPI agrave lrsquoaide drsquoune souris-
clavier mais il est recommandeacute de travailler agrave distance avec une connexion SSH
812 Mise en place de lrsquoenvironnement La mise en place de la RPI avec le systegraveme drsquoexploitation Raspbian a eacuteteacute preacutesenteacute au chapitre 721
Vous pouvez reprendre la mecircme installation ou repartir sur une nouvelle
Il est possible de faire en sorte que Node-RED se lance directement au deacutemarrage gracircce agrave la
commande sudo systemctl enable noderedservice
Sil nest pas actif lancer Node-RED sur votre RPI node-red-start
Nous nous connectons au Node-RED de la RPI via un navigateur web sur le port 1880 en tapant dans
la barre dURL httpIP_Raspeberry_PI1880 Ce nous permet darriver agrave la fenecirctre suivante
Figure 90 Page daccueil de Node-RED
Il est possible de sinterfacer avec TTN avec les Nodes deacutejagrave disponibles gracircce au protocole HTTP
POST ou MQTT Neacuteanmoins nous pouvons avantageusement installer deux librairies speacutecifiques
Une qui facilite linterfaccedilage avec TTN
Une qui facilite la mise en place dinterface graphique
Installation des Nodes TTN
cd $HOMEnode-red
npm install node-red-contrib-ttn
Installation de Dashboard (interface graphique)
| 77
cd $HOMEnode-red
npm install node-red-dashboard
Il peut ecirctre necessaire de redeacutemarrer Node-RED pour prendre en compte linstallation de nos deux
Nodes
-----------------------------------
sudo apt-get install npm
sudo npm install -g npm
hash -r
cd ~node-red
npm install node-red-example node name
------------------------------------
813 Creacuteer une Application speacutecifique pour TTN Nous allons commencer par geacuterer le flux Uplink Apporter sur votre scheacutema un Node ttn uplink et
un Node Debug puis relier les Le Node ttn uplink nous permettra de configurer la
communication avec TTN en MQTT Le Node debug eacutecrira sur le terminal les informations brutes
qui seront reccedilu par le Node ttn uplink
Figure 91 Visualisation des trame publieacutees par TTN sur notre client MQTT
Double cliquer sur le Node ttn uplink pour le configurer comme la figure suivante
Le champ Name sera le nom du Node sur votre scheacutema Le champ Device ID est le device LoRa
concerneacute dans votre application De plus il faut entrer les caracteacuteristiques de votre application (Add
new ttn app) pour que Node-RED puisse sy connecter
Figure 92 Configuration du node ttn uplink
Configuration de votre nouvelle application
| 78
Figure 93 Identifiant et mot de passe de notre application
AppID Nom de votre application Dans notre cas seminaire_lorawan
Access Key Comme nous lavons deacutejagrave expliqueacute plus tocirct l Access Key vous sera donneacutee
par lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application
vous trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt
Overview
Le Node ttn uplink doit maintenant avoir le nom que vous avez configureacute Cliquer sur Deploy pour
lancer votre projet Le bloc ttn uplink doit maintenant ecirctre connecteacute agrave TTN Cela est speacutecifieacute
connected sous le bloc
Figure 94 Utilisation du Node TTN Uplink
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
Figure 95 Simulation de Uplink dans TTN
Vous devriez voir le reacutesultat dans la fenecirctre de Debug Par exemple pour le test denvoi de 31 32
correspondant au code ASCII des chiffres 1 et 2 vous devriez avoir la fenecirctre de Debug suivante
| 79
Figure 96 Reacutesultats obtenu dans la fenecirctre Debug apregraves la simulation dUplink
814 Creacuteation drsquoun Dashboard
Dans la mise en place de lenvironnement (chapitre 812) nous avons installeacute des Nodes
Dashboard qui vont nous permettre de reacutealiser une interface graphique tregraves simple et de la mettre
agrave disposition des utilisateurs via un des graphiques histogramme gauges afficheurshellip
Figure 97 Impleacutementation dune interface graphique dans Node RED
Linterface graphique que nous allons creacuteer sera constitueacutee donglet (tab) La mise en place des
composant se fait de la faccedilon suivante
Chaque eacuteleacutement graphique doit appartenir agrave un groupe de composant quil va falloir creacuteer
Chaque groupe de composant doit appartenir agrave un onglet (tab) quil va falloir creacuteer
Figure 98 Creacuteation dun groupe de composant
Figure 99 Creacuteation dun nouvel onglet dans le site web
Cliquer sur Deploy pour activer votre application
LURL pour joindre linterface graphique de votre site web est disponible sur ladresse
httpIP_Raspeberry_PI1880ui
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
| 80
Figure 100 Interface graphique du site web avec Node-RED
82 Programmation en PHP Maintenant que nous avons testeacute toute lrsquoarchitecture nous pouvons mettre en place une
application qui jouera deux rocircles
Un rocircle de Serveur HTTP POST reacutecupeacuterant les donneacutees en provenance de TTN
Un rocircle de Client HTTP POST qui geacuteneacuterera les requecirctes vers TTN
Un serveur web apache sur RPI heacuteberge cette application Linterface graphique du site web est
reacutealiseacute avec le template CSS proposeacute par Bootstrap [ httpsgetbootstrapcom ]
Figure 101 Architecture de notre application en PHP sur RPI
The Things Network
Notre Application
[ Serveur Apache sur Raspberry Pi ]
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 81
Nous allons lrsquoutiliser telle quelle Elle est juste proposeacutee agrave titre dexemple Lrsquoobjectif de cette
application est de geacuteneacuterer une ouverture fermeture de ruche agrave distance dans le cadre de projets
eacutetudiants du Master Electronique et Systegravemes Embarqueacutes de lUSMB [ httpscem-esetuniv-
smbfr ]
Figure 102 Application permettant de recevoir et deacutemettre des requecirctes HTTP POST
Configurer TTN pour pointer vers votre nouveau serveur et tester le flux montant et
descendant
| 82
9 Versions du document
Version 10 02022019
Version initiale
Version 20 23022019
Ajout drsquoun paragraphe Les systegravemes embarqueacutes dans lrsquoIoT En introduction
Compleacutement et ameacutelioration Ameacutelioration exercice eacutetalement de spectre
Correction Cacircblage Arduino
Ajout drsquoun paragraphe Fonctionnement de lrsquoArduino et ajout de librairies
Compleacutement et ameacutelioration Couche physique LoRa Ajout de 4 figures pour lrsquoexplication
de la modulation Chirp
Ajout drsquoun paragraphe sur les acronymes utiliseacutes au deacutebut du cours TTN LoRa MQTThellip
Compleacutement drsquoinformations sur les dB et dBm
Ajout LoRa Calculator
Version 30 8032019
Ajout de figure sur le rocircle de la Gateway LoRa
Ajout de paragraphe authentification avec le Network Server
Ajout de paragraphe sur le chiffrement avec lrsquoApplication Server
Ajout drsquoun sommaire en deacutebut de cours
Ajout de 2 scheacutemas ABP et OTAA
Retrait explication du deacutetail de la laquo Join Request raquo en OTAA Trop complexe attente de
reacutealisation drsquoun scheacutema plus explicite
Ajout drsquoun scheacutema sur lrsquoattaque par REPLAY
Ajout de paragraphe des diffeacuterents reacuteseaux LoRaWAN existants Opeacutereacutes et Priveacutes
Ajout des scheacutemas des trames LoRaWAN Physique LoRa MAC Application
Compleacutement drsquoinformation sur les Classes de Devices
Ajout drsquoun paragraphe sur la Gateway utiliseacutee pour le Downlink
Ajout drsquoun paragraphe sur le JSON
Compleacutement drsquoinformation sur le codage en Base64
Ajout drsquoinformation dans le deacutecodage des trames LoRaWAN
Restructuration des explications sur lrsquoenvoi et la reacutecupeacuteration des donneacutees en HTTPMQTT
Version 40 8032019
Ajout drsquoun chapitre Creacuteation de notre propre Application
Ajout drsquoun chapitre Creacuteation de notre propre Network et Application Server
Ajout drsquoune figure Visualisation des Chirps LoRa par SDR (Radio Logicielle)
Compleacutements drsquoinformation sur MQTT
Compleacutements dinformation sur les Topics de TTN en MQTT
Figure 2 Protocoles utiliseacutes dans lIoT en fonction du deacutebit et de la porteacutee
Dans lrsquoIoT les protocoles utiliseacutes possegravedent une grande porteacutee et des deacutebits faibles
Lrsquoensemble de ces reacuteseaux sont deacutenommeacutes LPWAN Low Power Wide Area Network
113 Bande de freacutequence utiliseacutees En Europe les bandes de freacutequences libres (sans licence) sont
13 Mhz (RFID) 169 Mhz 434 Mhz 868 Mhz 24Ghz 5 Ghz et 24 Ghz (Faisceau Hertzien) Parmi ces
freacutequences seul le 433 MHz et 868 MHz sont utilisables en LoRa
12 Modes de partage du support Quel que soit le protocole utiliseacute le support de transfert de lrsquoinformation est lrsquoair car tous les
protocoles de lrsquoIoT sont Wireless Le support doit ecirctre partageacute entre tous les utilisateurs de telle
faccedilon que chacun des dispositifs Wireless ne perturbe pas les autres Pour cela une bande de
freacutequence est alloueacutee Par exemple pour la radio FM la bande de freacutequence va de 875 Mhz agrave 108
Mhz
Dans leur bande de freacutequence les dispositifs peuvent se partager le support de diffeacuterentes
maniegraveres
FDM (Frequency Division Multiplexing) Ce mode utilise une partie du spectre (bande de
freacutequence) en permanence Exemple Radio FM
TDM (Time Division Multiplexing) Ce mode utilise tout le spectre (bande de freacutequence) par
intermittence Exemple GSM on a laquo 8 time slots raquo par canal
CDMA (Code Division Multiple Access) Ce mode utilise tout le spectre tout le temps
Porteacutee (Range)
Deacutebit (Bandwidth)
| 8
Les Devices LoRa sont capables drsquoeacutemettre sur un mecircme canal en mecircme temps Le protocole LoRa
utilise une modulation tregraves similaire agrave la meacutethode 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 Plus
tard dans le cours nous expliquerons les diffeacuterences de la modulation LoRa
13 Notion drsquo eacutetalement de spectre utiliseacutee en LoRa Nous allons voir au travers drsquoun exercice comment il est possible drsquoutiliser tout le spectre en
permanence tout en eacutetant capable drsquoeffectuer plusieurs transactions simultaneacutees entre diffeacuterents
eacutemetteursreacutecepteurs Cette meacutethode est souvent appeleacutee laquo eacutetalement de spectre raquo car comme
son nom lrsquoindique elle a pour conseacutequence drsquoeacutetaler le spectre du signal transmis
La meacutethode consiste agrave utiliser des codes qui ont des proprieacuteteacutes matheacutematiques adapteacutees agrave notre
objectif Transmettre en mecircme temps sur la mecircme bande de freacutequence La matrice ci-dessous
donne par exemple 4 codes drsquoeacutetalement (1 par ligne)
Code Orthogonal User 0 1 1 1 1
Code Orthogonal User 1 1 -1 1 -1
Code Orthogonal User 2 1 1 -1 -1
Code Orthogonal User 3 1 -1 -1 1
Tableau 1 Matrice de Hadamart (matheacutematicien) dordre 4
Les proprieacuteteacutes de ces codes (1 1 1 1 1 -1 1 -1 1 1 -1 -1 1 -1 -1 1) ne sont pas expliqueacutees ici Nous
nous conterons de veacuterifier leur bon fonctionnement
131 Transmissions successives Chaque tableau ci-dessous repreacutesente une transmission qui est indeacutependante des autres elles ne
se deacuteroulent pas en mecircme temps On veacuterifie qursquoavec la mise en œuvre de laquo lrsquoeacutetalement de spectre raquo
chaque transmission arrive bien agrave destination avec le message qui avait eacuteteacute transmis Le premier
tableau est deacutejagrave rempli en guise drsquoexemple La meacutethode est la suivante
A lrsquoeacutemission
Chaque bit du message est multiplieacute par un code drsquoeacutetalement (une ligne de la matrice)
Le reacutesultat de la multiplication est transmis
A la reacuteception
Chaque symbole reccedilu est multiplieacute par le mecircme code drsquoeacutetalement
Le message reccedilu est eacutegal agrave la somme des symboles diviseacute par le nombre de symbole
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
hellip transmission hellip
4 Utilisation code orthogonal User 1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1
5 Deacutecodage = (3) x (4) 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0
6 Message reccedilu (sum (5) nbr_bits) 1 0 1 0
Reacutealiser la transmission du message du User 2 et du User 3 dans les tableaux suivants
| 9
1rsquo Message User 2 0 1 0 1
2rsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
3rsquo Symboles transmis User 2 = (1rsquo) x (2rsquo) 0 0 0 0
hellip transmission hellip
4rsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
5rsquo Deacutecodage = (3rsquo) x (4rsquo) 0 0 0 0
6rsquo Message reccedilu (sum (5rsquo) nbr_bits) 0
1rsquorsquo Message User 3 1 1 0 0
2rsquorsquo Utilisation code orthogonal User 3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
3rsquorsquo Symboles transmis User 3 = (1rsquorsquo) x (2rsquorsquo) 1 -1 -1 1
hellip transmission hellip
4rsquorsquo Utilisation code orthogonal User3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
5rsquorsquo Deacutecodage = (3rsquorsquo) x (4rsquorsquo) 1 1 1 1
6rsquorsquo Message reccedilu (sum (5rsquorsquo) nbr_bits) 1
132 Transmissions simultaneacutees
Les transmissions se deacuteroulent maintenant simultaneacutement les messages des User 1 User 2 et User
3 sont envoyeacutes en mecircme temps sur la mecircme bande de freacutequence La premiegravere colonne du User 1
est deacutejagrave remplie en guise drsquoexemple La meacutethode est la suivante
Dans lrsquoair
On additionne les symboles transmis par tous les User (1 2 3) ligne 1rsquorsquorsquo
Pour la reacuteception
Chaque symbole reccedilu est multiplieacute par le code drsquoeacutetalement du User
Le message reccedilu est eacutegal agrave la somme des symboles diviseacute par le nombre de symbole
Valider le fonctionnement pour la reacuteception des messages
1rsquorsquorsquo sum des symboles transmis ( 3 + 3rsquo + 3rsquorsquo ) 2 -2 0 0
2rsquorsquorsquo Utilisation code orthogonal User 1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 2 0 0
4rsquorsquorsquo Message reccedilu User 1 (sum (3rsquorsquorsquo) nbr_bits) 1
2rsquorsquorsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 -2 0 0
4rsquorsquorsquo Message reccedilu User 2 (sum (3rsquorsquorsquo) nbr_bits) 0
2rsquorsquorsquo Utilisation code orthogonal User 3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 2 0 0
4rsquorsquorsquo Message reccedilu User 3 (sum (3rsquorsquorsquo) nbr_bits) 1
133 Cas du protocole LoRa Le LoRa utilise une meacutethode drsquoeacutetalement de spectre qui nrsquoest pas exactement celle que nous venons
drsquoeacutetudier La finaliteacute est cependant la mecircme Pouvoir transmettre en mecircme temps sur le mecircme
canal Le protocole LoRa utilise sept laquo codes drsquoeacutetalement raquo appeleacutes Spreading Factor [ SF6 SF7 SF8
SF9 SF10 SF11 et SF12 ] qui lui permet drsquoavoir sept transmissions simultaneacutees sur un mecircme canal
| 10
2 Transmission radio et propagation
21 Les uniteacutes et deacutefinitions dB Rapport entre deux puissances Une atteacutenuation est repreacutesenteacutee par un nombre
neacutegatif (-) Un gain est repreacutesenteacute par un nombre positif (+)
Rapport de puissances en dB Rapport de puissance
+ 3 dB Multiplication par 2
- 3 dB Division par 2
0 dB Egaliteacute
+ 10 dB Multiplication par 10
- 10 dB Division par 10
Tableau 2 Comparaison entre les gains en dB et en proportion
dBi Gain theacuteorique drsquoune antenne
dBm Puissance rameneacutee agrave 1mW 0 dBm correspond agrave 1 mW
En reprenant la deacutefinition des dB remplir le tableau suivant
Puissance en dBm Puissance en mW
+ 3 dBm
- 3 dBm
+ 10 dBm
- 10 dBm
Tableau 3 Comparaison entre les puissances en dB et en mW
Le Talkie-Walkie a une puissance drsquoeacutemission de 2W Quelle est la puissance drsquoeacutemission
exprimeacutees en dBm
Sensibiliteacute Puissance minimale qursquoest capable de deacutetecter un reacutecepteur
RSSI Received Signal Strength Indication
SNR Signal over Noise Ratio
Un eacutemetteur transmet agrave une puissance de 13dBm en utilisant une antenne dont le gain
est de 2dBi Les pertes dans lrsquoair sont de 60 dB Lrsquoantenne reacuteceptrice qui possegravede un gain
de 2dBi est relieacutee agrave un reacutecepteur dont la sensibiliteacute est de -80 dBm Le signal pourra-t-il
ecirctre reccedilu
Le link Budget Crsquoest la quantiteacute de puissance que nous pouvons perdre avant drsquoarriver au
reacutecepteur tout en conservant une transmission fonctionnelle Autrement dit crsquoest la
puissance de lrsquoeacutemetteur moins la sensibiliteacute du reacutecepteur Dans lrsquoexemple preacuteceacutedent le
budget que nous avons agrave disposition est de 93dB
| 11
En LoRa nous avons un Link Budget de 157 dB
En LTE (4G) nous avons un Link Budget de 130 dB
Etude de la documentation drsquoun composant LoRa Le RN2483 est le composant radiofreacutequence que nous utiliserons dans notre transmission LoRa
Voici quelques une de ses caracteacuteristiques
Figure 3 Caracteacuteristiques principales du composant radiofreacutequence utiliseacute
Reprenez la deacutefinition du Link Budget et retrouver les 157 dB annonceacute dans cette
documentation
En LoRa plus le code drsquoeacutetalement est grand plus on est capable drsquoeacutemettre dans un milieu bruiteacute La
figure ci-dessous preacutesente les rapports signal sur bruit avec lesquels nous seront capable de reacutealiser
une transmission en fonction des Spreading Factor utiliseacutes
Figure 4 Influence du Spreading Factor sur le SNR acceptable
On remarque que pour un SF8 nous sommes capables drsquoeacutemettre avec un SNR de -10 dB On pourra
transmettre malgreacute le fait que le bruit est 10 fois supeacuterieur au signal
On remarque que pour un SF12 nous sommes capables drsquoeacutemettre avec un SNR de -20 dB On
pourra transmettre malgreacute le fait que le bruit est 100 fois supeacuterieur au signal
| 12
Cependant on remarque aussi que lrsquoutilisation drsquoun Spreading Factor plus eacuteleveacute augmente
consideacuterablement le nombre de symbole eacutemis (2egraveme colonne du tableau) Comme nous le verrons
plus tard cela impactera eacutevidement le temps de transmission
| 13
3 La couche physique LoRa
31 La modulation LoRa Comme nous lrsquoavons expliqueacute plus tocirct la modulation LoRa utilise lrsquoeacutetalement de spectre pour
transmettre ces informations Mais au lieu drsquoutiliser des codes drsquoeacutetalement (CDMA) elle utilise une
meacutethode appeleacutee Chirp Spread Spectrum La finaliteacute est toujours la mecircme Avoir plusieurs
transmissions dans le mecircme canal La conseacutequence sur le spectre est aussi la mecircme cela provoque
un eacutetalement du spectre
311 La forme du symbole (Chirp) Le signal eacutemis par la modulation LoRa est un symbole dont la forme de base est repreacutesenteacutee ci-
dessous Son nom (Chirp) vient du fait que ce symbole est utiliseacute dans la technologie Radar (Chirp
Compressed High Intensity Radar Pulse)
Figure 5 Symbole de la modulation LoRa (source Wikipeacutedia)
La freacutequence de deacutepart est la freacutequence centrale du canal moins la Bande Passante diviseacutee par deux
La freacutequence de fin est la freacutequence centrale plus la Bande Passante diviseacutee par deux
La freacutequence centrale est appeleacutee le canal
La bande passante est la largeur de bande occupeacutee autour du canal
On considegravere une eacutemission sur la freacutequence centrale 868 Mhz avec une Bande Passante
de 125 kHz Donner la freacutequence de deacutebut et la freacutequence de fin du sweep
Freacutequence de deacutebut
Freacutequence de fin
Pour faciliter la repreacutesentation de ce symbole on utilise plutocirct un graphique TempsFreacutequence de
la forme suivante
| 14
Figure 6 Forme du symbole de base (CHIRP)
En LoRa chaque symbole repreacutesente un certain nombre de bits transmis La regravegle est la suivante
Nombre de bits transmis dans un symbole = Spreading Factor
Par exemple si la transmission utilise un Spreading Factor de 10 (SF10) alors un symbole repreacutesente
10 bits
Crsquoest-agrave-dire qursquoagrave lrsquoeacutemission les bits sont regroupeacutes par paquet de SF bits puis chaque paquet est
repreacutesenteacute par un symbole particulier parmi 2119878119865formes de symboles possibles
Sur la figure suivante voici un exemple theacuteorique drsquoune modulation en SF2 agrave 868 Mhz sur une
bande passante de 125 kHz Chaque symbole repreacutesente donc 2 bits
Figure 7 Symboles eacutemis en Modulation LoRa (Cas theacuteorique en SF2)
Exemple
On considegravere la suite binaire suivante 0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Le Spreading Factor utiliseacute est SF10
Nous regroupons donc les bits par paquet de 10 Chaque paquet de 10 bits sera repreacutesenteacute par un
symbole (sweep) particulier Il y a 1024 symboles diffeacuterents pour coder les 1024 combinaisons
binaires possibles (210)
Freacutequence
Temps
868 000 000 Hz
868 062 500 Hz
Un symbole Un symbole
867 937 500 Hz
Temps
868 000 000 Hz
867 937 500 Hz
Symbole 0
Bits laquo 00 raquo
Symbole 1
Bits laquo 01 raquo
Symbole 2
Bits laquo 10 raquo Symbole 3
Bits laquo 11 raquo
12
5 k
Hz
868 062 500 Hz
| 15
Figure 8 Emission des Chirp en LoRa
Avec un outils drsquoanalyse spectrale actif pendant lrsquoeacutemission LoRa drsquoun Device on peut afficher les
successions de symbole qui sont envoyeacutes Cette oscillogramme a eacuteteacute reacutealiseacute agrave lrsquoaide drsquoun SDR
(Software Digital Radio)
Figure 9 Visualisation des Chirps LoRa reacuteellement eacutemis pendant une transmission
312 Dureacutee drsquoeacutemission drsquoun symbole En LoRa la dureacutee drsquoeacutemission de chaque symbole (Chirp) deacutepend du Spreading Factor utiliseacute Plus le
SF est grand et plus le temps drsquoeacutemission sera long Pour une mecircme bande passante le temps
drsquoeacutemission drsquoun symbole en SF8 est deux fois plus long que le temps drsquoeacutemission drsquoun symbole en
SF7 Ainsi de suite jusqursquoagrave SF12
0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Envoi de 1 Chirp Envoi de 1 Chirp Envoi de 1 Chirp
Transmission Transmission Transmission
| 16
Figure 10 Temps drsquoeacutemission drsquoun symbole (Chirp) en fonction du SF
En revanche le temps drsquoeacutemission drsquoun symbole est inversement proportionnel agrave la bande passante
119879119904 =2119878119865
119861119886119899119889119908119894119889119905ℎ Le deacutebit des symboles est donc de
1
119879119878= 119865119904 =
119861119886119899119889119908119894119889119905ℎ
2119878119865 En toute logique plus la
bande passant est eacuteleveacute plus le deacutebit des symboles sera eacuteleveacute Comme chaque symbole comprend
SF bit on retrouve alors le deacutebit binaire
119863119887 = 119878119865119861119886119899119889119908119894119889119905ℎ
2119878119865
Plus le Spreading Factor sera eacuteleveacute plus le deacutebit binaire sera faible
Plus la Bande Passante sera eacuteleveacutee plus le deacutebit binaire sera fort
Exemple Drsquoapregraves la formule du deacutebit binaire trouver le deacutebit pour les deux cas suivants
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
32 Coding Rate Le Coding Rate est un ratio qui augmentera le nombre de bits agrave transmettre afin de reacutealiser de la
deacutetection correction drsquoerreur Dans le cas drsquoun CR = 4 8 il y aura 8 bits transmis reacuteellement agrave
chaque fois que nous souhaitons transmettre 4 bits Dans cette exemple cela provoque une
transmission drsquoun nombre de bit multiplieacute par 2
SF7
Freacutequence
Temps
Freacutequence centrale
Freacutequence haute
Temps drsquoun symbole eacutemit en SF 12
Freacutequence basse
SF8
SF9
SF10
SF11
SF12
Temps drsquoun symbole eacutemit en SF 11
| 17
Figure 11 Influence du Coding Rate sur le nombre de bits ajouteacute
Si on reprend lrsquoexemple preacuteceacutedent avec un CR de 4 5 nous avons une augmentation de 125 du
nombre de bits agrave transmettre Redonner la deacutebit en prenant en compte le CR
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
La documentation du composant RN2483 donne les deacutebits en fonction du Spreading Factor
la Bande Passante et le Coding Rate Veacuterifier la coheacuterence du reacutesultat avec votre calcul
preacuteceacutedent
Figure 12 Deacutebit en fonction des paramegravetres de la transmission LoRa
33 Utilisation du LoRa Calculator Le logiciel laquo LoRa Calculator raquo est un petit exeacutecutable permettant de simuler une transmission LoRa
en fonction des caracteacuteristiques saisies Canal SF CR etchellip Il est teacuteleacutechargeable agrave lrsquoadresse
suivante httpsbitly2TyloAh
| 18
Figure 13 Le logiciel LoRa Calculator
En reprenant lrsquoexemple preacuteceacutedent (SF7 Bande Passante 125 kHz CR 45) veacuterifier les
calculs du laquo Equivalent Bitrate raquo
34 Time On Air La norme LoRaWAN impose qursquoun Device LoRa ne transmette pas plus de 1 du temps Cela est
repreacutesenteacute par un Duty Cycle Par exemple un Duty Cycle de 1 signifie que si jrsquoeacutemet pendant 1 je
ne dois plus eacutemettre pendant 99 quel que soit lrsquouniteacute de temps utiliseacutee
En reprenant les exemples preacuteceacutedents quels sont les deacutebits moyens si on prend en compte
le laquo Time On Air raquo
Cas 1 Pour SF7 et 125 khz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
Dans le logiciel laquo LoRa Calculator raquo (onglet laquo Energy Profile raquo) nous pouvons estimer la
dureacutee de vie drsquoune batterie Nous prenons lrsquoexemple drsquoun releveacute de tempeacuterature dans un
bacirctiment avec les caracteacuteristiques suivantes
| 19
SF CR Bande Passante etc Nous nous placcedilons dans le cas 1 des exemples preacuteceacutedents
Le releveacute de tempeacuterature se fera toutes les 15 mins
La batterie est constitueacute de 3 petites piles bacirctons [ AAA LR03 ] 12V en seacuterie Soit 36 V
1000 mAh
35 Mise en œuvre LoRa en point agrave point Ce test sera reacutealiseacute avec des modules LoRa RN2483 (Microchip) et une carte microcontrocircleur
ARDUINO
Figure 14 Communication LoRa en Point agrave Point
Reacutealiser le cacircblage de votre module RN2483 suivant le tableau suivant
Connecteur Arduino Click Board RN2483
5V 5V
GND GND
11 RX
10 TX
Tableau 4 Cacircblage de lrsquoARDUINO et de la click Board RN2483
351 Utilisation de lrsquoIDE Arduino Lrsquoenvironnement Arduino est tregraves simple Nous allons reacutealiser un programme pour montrer son
fonctionnement
La connexion de la carte est effectueacutee agrave lrsquoaide drsquoun port USB qui eacutemule une liaison seacuterie
RS232 Il faut donc choisir le bon port Arduino IDE gt Outils gt Port
Pour creacuteer un nouveau programme (sketch) Arduino IDE gt Fichier gt Nouveau
Il y a deux parties dans un sketch
Une fonction setup() qui sera exeacutecuteacutee qursquoune seule fois au deacutemarrage
Une fonction loop() qui sera exeacutecuteacutee en boucle
Ecrire le code suivant
Emetteur
Reacutecepteur
UA
RT
UA
RT
| 20
void setup()
Serialbegin(9600)
void loop()
Serialprintln(hello word)
Compiler et Teacuteleacuteverser Croquis gt Teacuteleacuteverser
Voir la sortie sur la liaison seacuterie Outils gt Moniteur Seacuterie gt Choisir la vitesse de
transmission ici 9600 bauds (en bas agrave droite)
352 Validation du fonctionnement Deux binocircmes joueront le rocircle drsquoeacutemetteur tous les autres binocircmes seront en reacutecepteur
Reacutecupeacuterer les programmes dans Moodle dans le dossier laquo RN2483-Arduino-Point2Point raquo
Installer la librairie RN2483 Arduino IDE gt Croquis gt Inclure une bibliothegraveque gt Ajouter la
bibliothegraveque zip
Reacutepartissez les rocircles Emetteurs Reacutecepteurs et reacutecupeacuterer le programme LoraBlinkerRX ou
LoraBlinkerTX en fonction Les 2 binocircmes en eacutemission devront modifier le code du sketch
Arduino pour transmettre des donneacutees speacutecifiques afin de les diffeacuterencier [
loraSerialprintln(radio tx 30) ]
Validez la reacuteception des donneacutees eacutemises par les deux binocircmes qui transmettent des
donneacutees Ces donneacutees reccedilues sont eacutecrite agrave 57600 bauds sur le moniteur seacuterie de lrsquoArduino
353 Mise en valeur du Spreading Factor On srsquoaperccediloit dans la manipulation preacuteceacutedente que les Devices LoRa reccediloivent les donneacutees des deux
eacutemetteurs Nous allons conserver le mecircme canal drsquoeacutemission (8691 Mhz) mais un des deux
eacutemetteurs va modifier son laquo Spreading Factor raquo La salle sera donc seacutepareacutee en deux groupes
1er groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF7
2egraveme groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF8
Validez la reacuteception des donneacutees eacutemises seulement pour le Spreading Factor que vous
utilisez
| 21
4 Le protocole LoRaWAN
Le LoRa est le type de modulation utiliseacute entre deux Devices ou entre un Device et une Gateway
Lorsque nous parlons de lrsquoensemble de la chaine de communication (Device Gateway Serveur) alors
nous parlons de communication LoRaWAN Nous allons voir lrsquoarchitecture drsquoun reacuteseau LoRaWAN
ainsi que les regravegles de ce protocole
41 Structure drsquoun reacuteseau LoRaWAN Nous retrouvons drsquoun cocircteacute le Device LoRa qui transmet une donneacutee Elle est reacuteceptionneacutee agrave lrsquoautre
extreacutemiteacute du reacuteseau par un Utilisateur La structure globale du reacuteseau LoRaWAN peut ecirctre
repreacutesenteacutee par la figure suivante
411 Les Devices LoRa Les Devices LoRa sont des systegravemes eacutelectroniques appartenant au monde de lrsquoIoT Faible
consommation faible taille faible puissance et faible taille
Ils possegravedent une radio LoRa permettant de joindre les Gateways Les Gateways ne sont pas
adresseacutees speacutecifiquement toutes celles preacutesentes dans la zone de couverture reccediloivent les
messages et les traitent
412 Les Gateways LoRa Elles eacutecoutent sur tous les canaux et sur tous les Spreading Factor Lorsqursquoune trame LoRa est reccedilue
elle transmet son contenu sur internet agrave destination du Network Server qui a eacuteteacute configureacute dans la
Gateway au preacutealable
Elle joue donc le rocircle de passerelle entre une modulation LoRa et une communication IP
Devices
LoRa Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
Internet Internet
Figure 15 Structure globale dun reacuteseau LORAWAN
| 22
Chaque Gateway LoRa possegravede un identifiant unique (EUI sur 64 bits)
413 Le Network Server
Le Network Server reccediloit les messages transmis par les Gateways et supprime les doublons
(plusieurs Gateway peuvent avoir reccedilu le mecircme message) Les informations transmises au Network
Server depuis les Devices LoRa sont authentifieacutes gracircce agrave une cleacute AES 128 bits appeleacutee Network
Session Key NwkSKey Nous parlons bien ici drsquoauthentification et non pas de chiffrement comme
nous le verrons plus tard
414 Application Server Il est souvent sur le mecircme support physique que le Network Server Il permet de dissocier les
applications les unes des autres Chaque application enregistre des Devices LoRa qui auront le droit
Devices Gateways Network
Server
Internet
Network Session Key (NwkSKey)
Authentification
Figure 17 Authentification entre le Device LoRa et le Network Server
Internet
UDP IP
Modulation
LoRa
Device LoRa
Gateway
Network Server
LoRaWAN
Modulation
LoRa
Passerelle LoRa Internet
Internet
UDP IP
LoRaWAN
Transmission Radio
Application Application
Figure 16 Le rocircle de la Gateway LoRa
| 23
de stocker leurs donneacutees (Frame Payload) Les message transmis agrave lrsquoapplication server sont chiffreacutes
gracircce agrave une cleacute AES 128 bits appeleacutee Application Session Key AppSKey
Le scheacutema suivant reacutesume lrsquoutilisation
De la Network Session Key (NwkSKey) pour lrsquoauthentification entre le Device LoRa et le
Network Server
De lrsquoApplication Session Key (AppSKey) pour le chiffrement entre le Device LoRa et
lrsquoApplication Server
Devices Gateways Network
Server Application
Server
Internet
Application Session Key (AppSKey)
Chiffrement
Figure 18 Chiffrement entre le Device LORA et lrsquoApplication Server
| 24
415 Application Web Serveur Cette application doit drsquoune part reacutecupeacuterer les donneacutees de lrsquoApplication Serveur Dans le cadre de
ce cours cela sera fait de deux faccedilons
Avec le protocole HTTP
Avec le protocole MQTT
Figure 20 Application Web Server
Figure 19 Authentification et chiffrement en LoRaWan
Devices Gateways
Network
Server Application
Server
Internet
Network Session Key
Application Session Key
Network
Server Application
Server
Application
Server Web
Utilisateur
Protocole
MQTT ou HTTP
Flux Uplink
Flux Downlink
| 25
Le flux habituel dans lrsquoIoT est le flux Uplink (flux montant) crsquoest-agrave-dire lrsquoeacutemission de donneacutees des
objets vers le serveur Comme nous lrsquoexpliquerons plus loin en LoRaWAN il est aussi possible de
transfeacuterer des donneacutees aux Device LoRa par un flux Downlink (flux descendant)
Drsquoautre part lrsquoapplication mettra agrave disposition les donneacutees aux utilisateurs sous forme par exemple
drsquoun serveur web drsquoune base de donneacutees et drsquoune visualisation graphique
416 Authentification avec le Network Server La Network Session Key (NwkSKey) sert agrave lrsquoauthentification entre le Device LoRa e le Network Server
Afin de reacutealiser cette authentification entre le Device et le Network Server un champ MIC (Message
Integrity Control) est rajouteacute agrave la trame Il est calculeacute en fonction des donneacutees transmises et du
NwkSkey A la reacuteception le mecircme calcul est effectueacute Si les cleacutes sont eacutequivalentes dans le Device et
dans le Network Server alors les deux MIC calculeacutes doivent correspondre
417 Chiffrement des donneacutees vers lrsquoApplication Server
LrsquoApplication Session Key (AppSKey) sert pour le chiffrement entre le Device LoRa et lrsquoApplication
Server Les donneacutees chiffreacutees seront alors deacutecodeacutees agrave la reacuteception sur lrsquoApplication Server srsquoil
possegravede la mecircme cleacute Si on reprend le scheacutema preacuteceacutedent les laquo donneacutees x raquo sont chiffreacutees
deacutechiffreacutees par le processus suivant
Donneacutees x chiffreacutees NwkSkey x
MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees
NwkSkey x
Trame eacutemise Trame reccedilue
Device LoRa Network Server
Si =
Alors la trame est authentifieacutee
MIC geacuteneacutereacute Emission MIC geacuteneacutereacute Reacuteception
MIC geacuteneacutereacute Reacuteception
Figure 21 Authentification dun Device LoRa par le Network Server
| 26
Figure 22 Chiffrement des donneacutees par lApplication Session Key
418 Combinaison de lrsquoauthentification et du chiffrement On peut maintenant repreacutesenter sur le mecircme scheacutema la construction de la trame LoRaWAN avec
drsquoune part lrsquoauthentification et drsquoautre part le chiffrement
Figure 23 Chiffrement puis Authentification
42 Classes des Devices LoRaWAN Les Devices LoRa sont classeacutes en 3 cateacutegories (A B C) en fonction de leur consommation et de leur
accessibiliteacute en Downlink crsquoest-agrave-dire la faciliteacute qursquoun utilisateur aura agrave transmettre une trame au
Device LoRa
421 Classe A (All) Minimal power Application Tous les Devices LoRaWAN sont de classe A Chaque Device peut transmettre (Uplink) agrave la Gateway
sans veacuterification de la disponibiliteacute du reacutecepteur Si la transmission eacutechoue elle sera reacuteeacutemise apregraves
un certain temps Cette transmission est suivie de 2 fenecirctres de reacuteception tregraves courtes La Gateway
peut alors transmettre pendant le laquo RX Slot 1 raquo ou le laquo RX Slot 2 raquo mais pas les deux
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Device LoRa
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Application Server
Donneacutees non chiffreacutees
AppSKey
Donneacutees chiffreacutees Entecircte
NwkSKey
MIC geacuteneacutereacute en eacutemission Trame transmise =
| 27
Figure 24 Slots de reacuteception pour un Device LoRa de classe A
Source de lrsquoimage httpszakelijkforumkpncom
La dureacutee des fenecirctres doit ecirctre au minimum la dureacutee de reacuteception drsquoun preacuteambule Un preacuteambule
dure 1225 Tsymbole et deacutepend donc du Data Rate (DR voir paragraphe 445 pour plus drsquoinformation
sur le DR) Lorsque qursquoun preacuteambule est deacutetecteacute le reacutecepteur doit rester actif jusqursquoagrave la fin de la
transmission Si la trame reccedilue pendant la premiegravere fenecirctre de reacuteception eacutetait bien agrave destination du
Device LoRa alors la deuxiegraveme fenecirctre nrsquoest pas ouverte
Premiegravere fenecirctre de reacuteception
Le Slot RX1 est programmeacute par deacutefaut agrave 1 seconde + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont les mecircme que ceux choisis lors de la phase drsquoeacutemission
(Uplink)
Seconde fenecirctre de reacuteception
Le Slot RX2 est programmeacute par deacutefaut agrave 2 secondes + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont configurables mais fixes
Un Device LoRa qui est uniquement de classe A ne peut pas recevoir srsquoil nrsquoa pas eacutemis Il
nrsquoest donc pas joignable facilement
422 Classe B (Beacon) Scheduled Receive Slot Les Devices de classe B ont le mecircme comportement que les Devices de classe A mais drsquoautres
fenecirctres de reacuteceptions sont programmeacutees agrave des peacuteriodes preacutecises Afin de synchroniser les fenecirctres
de reacuteception du Device LoRa la Gateway doit transmettre des balises (Beacons) de faccedilon reacuteguliegravere
| 28
Figure 25 Slots de reacuteception pour un Device LoRa de classe B
Source de lrsquoimage httpszakelijkforumkpncom
Un Device LoRa de classe B est joignable reacuteguliegraverement sans qursquoil soit neacutecessairement
obligeacute drsquoeacutemettre En revanche il consomme plus qursquoun Device de classe A
423 Classe C (Continuous) Continuously Listening Les Devices de classe C ont des fenecirctres de reacuteception constamment ouvertes entre 2 Uplinks Ces
Devices consomment donc beaucoup plus
Figure 26 Slots de reacuteception pour un Device LoRa de classe C
Source de lrsquoimage httpszakelijkforumkpncom
| 29
Un Device LoRa de classe C est joignable en permanence En revanche crsquoest la classe de
Device qui est la plus eacutenergivore
424 Quelle Gateway pour les flux Downlink
Nous avons donc vu que le fonctionnement classique du protocole LoRaWAN eacutetait de reacutecupeacuterer de
lrsquoinformation depuis le Device LoRa Crsquoest le flux Uplink
Dans le cas ougrave lrsquoutilisateur transmet des informations au Device LoRa (flux Downlink) on peut se
demander quelle Gateway sera choisie pour transfeacuterer les donneacutees au Device LoRa En effet
lrsquoendroit ougrave est situeacute le Device LoRa nrsquoest pas neacutecessairement connu agrave lrsquoavance
La Gateway utiliseacutee pour le Downlink est celle qui a reccedilu le dernier message du Device
LoRa Un message ne pourra jamais arriver agrave destination drsquoun Device LoRa si celui-ci nrsquoa
jamais transmis quel que soit sa classe A B ou C
43 Activation des Devices LoRa et seacutecuriteacute En LoRaWAN les trois eacuteleacutements indispensables pour la communication sont le DevAddr pour
lrsquoindentification du Device ainsi que deux cleacutes le NwkSKey pour lrsquoauthentification et lrsquoAppSKey
pour le chiffrement Deux meacutethodes sont possibles pour fournir ces informations agrave la fois au Device
LoRa et au serveur
Activation By Personalization APB
Over The Air Activation
431 ABP Activation By Personalization Crsquoest la plus simple des meacutethodes Crsquoest donc peut ecirctre celle que nous avons tendance agrave utiliser lors
drsquoun test de prototype et drsquoune mise en place de communication LoRaWAN
Le Device LoRa possegravede deacutejagrave le DevAddr lrsquoAppSKey et le NwkSKey
Le Network server possegravede deacutejagrave le DevAddr et le NwkSKey
Lrsquoapplication serveur possegravede deacutejagrave le DevAddr et le AppSKey
En ABP toutes les informations neacutecessaires agrave la communication sont deacutejagrave connues par le
Device LoRa et par le Serveur
| 30
432 OTAA Over The Air Activation Crsquoest la meacutethode qursquoil faut privileacutegier car crsquoest celle qui est la plus seacutecuriseacutee Le Device LoRa doit
connaitre le DevEUI lrsquoAppEUI et lrsquoAppkey Le Network Server doit lui connaitre la mecircme Appkey
Tous les eacuteleacutements noteacutes EUI (Extended Unique Identifier) sont toujours sur une taille de
64 bits
Gracircce agrave ces informations de deacutepart et une neacutegociation avec le Network Server (Join Request) le
Device LoRa et le serveur vont geacuteneacuterer les informations essentielles DevAddr NwkSKey et
AppSKey
Figure 28 Obtention du DevAddr NwkSKey et AppSKey en OTAA
DevEUI Unique Identifier pour le device LoRa (Equivalent agrave une MAC sur Ethernet)
Certains Device LoRa ont deacutejagrave un DevEUI fourni en usine
AppEUI Unique Identifier pour lrsquoapplication server
DevEUI
AppEUI
AppKey
Join
Request
DevAddr
NwkSKey
AppSKey
Network Server
Application Server
Devices 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 2
NwkSkey 2
AppSKey 2
Devices 2
DevAddr 2
NwkSkey 2
AppSKey 2
Paramegravetres stockeacutes sur le serveur
Paramegravetres programmeacutes
dans le composant
Figure 27 Parameacutetrage de DevAddr NwkSKey et AppSKey
| 31
AppKey AES 128 cleacute utiliseacutee pour geacuteneacuterer le MIC (Message Code Integrity) lors de la Join
Resquest Il est partageacute avec le Network server
NwkSKey Utiliseacute pour lrsquoauthentification avec le Network Server
AppSKey Utiliseacute pour le chiffrement des donneacutees
433 Seacutecuriteacute Les cleacutes AES 128 bits permettent le chiffrement des informations transmises en LoRaWAN Malgreacute
ce chiffrement une attaque connue en Wireless est celle du REPLAY Crsquoest-agrave-dire que le Hacker
enregistre des trames chiffreacutees circulant sur le reacuteseau LoRa pour les reacuteeacutemettre plus tard Mecircme si
le Hacker ne comprend pas le contenu (les trames sont chiffreacutees) les donneacutees qui sont transporteacutees
sont elles bien comprises par lrsquoApplication Server Des actions peuvent donc ecirctre reacutealiseacutees
simplement par mimeacutetisme
Pour eacuteviter cela la trame LoRaWAN integravegre un champ variable appeleacute laquo Frame Counter raquo Il srsquoagit
drsquoun nombre numeacuterotant la trame sur 16 ou 32 bits LrsquoApplication Server acceptera une trame
uniquement si le laquo Frame Counter raquo reccedilu est supeacuterieur au laquoFrame Counter raquo preacuteceacutedemment Donc
si le Hacker retransmet la trame telle qursquoelle le laquo Frame Counter raquo sera eacutequivalent donc la trame
sera refuseacutee Et comme la trame est chiffreacutee le Hacker nrsquoa pas moyen de savoir comment modifier
un champ de cette trame
Cette seacutecuriteacute impleacutementeacutee par les laquo Frame Counter raquo est inteacuteressante pour srsquoaffranchir drsquoune
attaque par REPLAY mais dans nos tests cela peut poser problegraveme En effet agrave chaque fois que nous
redeacutemarrons le microcontrocircleur notre laquo Frame Counter raquo revient agrave zeacutero alors que celui de
lrsquoApplication Server continue de srsquoincreacutementer Cela peut ecirctre reacutesolue par diffeacuterentes maniegraveres
1 Deacutesactivation du laquo Frame Counter Check raquo Dans certain Application Server cette option
peut ecirctre proposeacutee Bien sucircr il faudra garder en tecircte la faille de seacutecuriteacute que cela engendre
Network Server
Application Server
Devices LoRa
NwkSkey
AppSKey
NwkSkey
AppSKey Hacker
(1) (2)
(1) Ecoute
(2) Reacuteeacutemission
Figure 29 Attaque par REPLAY
| 32
Figure 30 Deacutesactivation du Frame Counter Check dans TTN
2 Utiliser lrsquoauthentification par OTAA au lieu de ABP En effet agrave chaque ouverture de session
en OTAA le laquo Frame Counter raquo est reacuteinitialiseacute coteacute serveur
3 Conserver la valeur du laquo Frame Counter raquo dans une meacutemoire non volatile et reacutecupeacuterer sa
valeur au deacutemarrage du Device LoRa
44 La Trame LoRa LoRaWAN
441 Les couches du protocole LoRaWAN
Lorsque nous avons fait une communication en Point agrave Point nous avons simplement utiliseacute la
couche physique de la modulation LoRa Lorsque nous souhaitons utiliser le protocole LoRaWAN
des couches protocolaires suppleacutementaires se rajoutent
Figure 31 Les couches protocolaires du LoRaWAN
Chaque couche rajoute un service Lors de lrsquoenvoi de la trame les donneacutees utilisateurs sont donc
encapsuleacutees dans chaque couche infeacuterieure jusqursquoagrave la transmission Le deacutetail de lrsquoensemble de la
trame LoRaWAN par couche est deacutecrit sur la figure Figure 32
LoRa Modulation
LoRa Mac
Application
Couche Physique
Couche Mac
Couche Application
| 33
442 Couche Application La couche Application accueille les donneacutees de lrsquoutilisateur Avant de les encapsuler elles sont
chiffreacutees avec lrsquoAppSKey afin de seacutecuriser la transaction
Un ensemble de champs nommeacute Frame Header permet de speacutecifier le DevAddr le Frame Control
le Frame Counter et le Frame Option
Le Frame Port deacutepend du type drsquoapplication et sera choisi par lrsquoutilisateur
Le Frame Payload sont les donneacutees chiffreacutees agrave transmettre Le nombre drsquooctets maximum pouvant
ecirctre transmis (N octets) est donneacute dans le tableau suivant
PHY Payload
P octets Couche
Physique
Couche
Mac
Couche
Application
CRC
2 octets Header + Header CRC
20 bits Preamble
MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Figure 32 Trame LORAWAN complegravete par couche protocolaire
Couche
Application Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Frame Header
Figure 33 Trame LORA couche Applicative
| 34
Data Rate Spreading Factor Bandwidth Max Frame Payload (Nombre N) DR 0 SF12 125 KHz 51 octets
DR 1 SF11 125 KHz 51 octets
DR 2 SF10 125 KHz 51 octets
DR 3 SF9 125 KHz 115 octets
DR 4 SF8 125 KHz 222 octets
DR 5 SF7 125 KHz 222 octets
DR 6 SF7 250 KHz 222 octets
Tableau 5 Taille maximum du Frame Payload en fonction du Data Rate
443 Couche LoRa MAC Cette trame est destineacutee au Network Server Elle est authentifieacutee gracircce au champ MIC (Message
Integrity Protocol) selon la meacutethode expliqueacutee au paragraphe 416
Le protocole LoRa MAC est composeacute de
1 MAC Header Version de protocole et type de message
Type de Message Description 000 Join-Request
001 Join-Accept
010 Unconfirmed Data Up
011 Unconfirmed Data Down
100 Confirmed Data Up
101 Confirmed Data Down
110 Rejoin-request
111 Proprietary
Tableau 6 Les types de messages transmis en LoRaWAN
2 MAC Payload Contient tout le protocole applicatif
3 MIC Message Integrity Code pour lrsquoauthentification de la trame
444 Couche physique Modulation LoRa
Le choix du moment drsquoeacutemission des Devices LoRa se fait de faccedilon simple Lorsqursquoun eacutequipement
doit eacutemettre il le fait sans controcircle et ne cherche pas agrave savoir si le canal est libre Si le paquet a eacuteteacute
perdu il le retransmettra simplement au bout drsquoun temps aleacuteatoire La couche physique est
repreacutesenteacutee par lrsquoeacutemission de la trame suivante
Couche
Mac MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Figure 34 Trame LORA couche LORA MAC
| 35
Le Preacuteambule est repreacutesenteacute par 8 symboles + 425 Le temps du Preacuteambule est donc de 1225
Tsymbole
Len-tecircte (Header optionnel) est seulement preacutesent dans le mode de transmission par deacutefaut
(explicite) il est transmis avec un Coding Rate de 48 Il indique la taille des donneacutees le Coding Rate
pour le reste de la trame et il preacutecise eacutegalement si un CRC sera preacutesent en fin de trame
Le PHY Payload contient toutes les informations de la Couche LoRa MAC
Le CRC sert agrave la deacutetection drsquoerreur de la trame LoRa
445 Canaux et bandes de freacutequences et Data Rate (DR) Le LoRa utilise des bandes de freacutequences diffeacuterentes suivant les reacutegions du monde En Europe la
bande utiliseacutee est celle des 868 Mhz [ De 863 Mhz agrave 870 Mhz ] Le LoRaWAN deacutefinie les 8 canaux agrave
utiliser pour communiquer avec une Gateway suivant le tableau suivant
Canaux Spreading Factor Bandwidth 8681 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz SF7 250 kHz
8685 Mhz De SF7 agrave SF12 125 kHz
8671 Mhz De SF7 agrave SF12 125 kHz
8673 Mhz De SF7 agrave SF12 125 kHz
8675 Mhz De SF7 agrave SF12 125 kHz
8677 Mhz De SF7 agrave SF12 125 kHz
8679 Mhz De SF7 agrave SF12 125 kHz
Tableau 7 Canaux SF et Bandwidth de notre Gateway LoRaWAN
Une Gateway LoRa eacutecoute donc sur 8 canaux simultaneacutement avec les 6 Spreading Factor
diffeacuterents soit 48 combinaisons possibles
Comme nous lrsquoavons vu le Spreading Factor a des conseacutequences sur le deacutebit de la transmission Ces
deacutebits sont noteacutes DR (Data Rate) et sont normaliseacutes de DR0 agrave DR6
PHY Payload
P octets Couche
Physique CRC
2 octets Header + Header CRC
( Optionnel ) 20 bits Preamble
Figure 35 Trame LORA couche Physique
| 36
Data Rate Spreading Factor Bandwidth DR 0 SF12 125 KHz
DR 1 SF11 125 KHz
DR 2 SF10 125 KHz
DR 3 SF9 125 KHz
DR 4 SF8 125 KHz
DR 5 SF7 125 KHz
DR 6 SF7 250 KHz
Tableau 8 Deacutenomination DR en fonction du SF et de la Bande Passante
446 Trame reccedilue et transmise par la Gateway LoRaWAN La Gateway reccediloit drsquoun cocircteacute un message radio moduleacute en LoRa et transmet de lrsquoautre cocircteacute une trame
IP agrave destination du Network Server
Coteacute interface Radio La Gateway reacuteceptionne une trame LoRaWAN et extrait le PHY Payload Celui-
ci est codeacute au format ASCII en base 64 (voir le paragraphe 541) La Gateway extrait aussi toutes les
informations utiles sur les caracteacuteristiques de la reacuteception qui a eu lieu SF Bandwidth RSSI Time
On Airhellipetchellip
Coteacute interface reacuteseau IP La Gateway transmet lrsquoensemble de ces informations dans un paquet IP
(UDP) au Network Server Les donneacutees transmises sont du texte en format JSON (voir paragraphe
447) La Gateway a donc bien un rocircle de passerelle entre le protocole LoRa drsquoun cocircteacute et un reacuteseau
IP de lrsquoautre
Internet
UDP IP
Device LoRa
Gateway
Network Server Modulation
LoRa
Passerelle LoRa Internet
Transmission Radio Internet
Figure 36 Rocircle de la Gateway LoRa
| 37
447 Le format JSON Le format JSON est un format texte composeacute drsquoune succession de couple nomvaleur Dans
lrsquoexemple de la figure preacuteceacutedente gw_id est un nom et eui-b827ebfffeae26f5 est la valeur
associeacutee Dans cette exemple la valeur est un string Les objets sont deacutelimiteacutes par un des accolades
et
Une valeur peut ecirctre
Un string exemple coding_rate 45
Un nombre exemple spreading_factor 12
Un objet exemple lora spreading_factor 12 air_time 2465792000
Un Boolean
Ethernet
Gateway
Modulation
LORA
Reacutecupeacuteration du PHY PAYLOAD en base 64
Reacutecupeacuteration des caracteacuteristiques de la transmission Canal SF CR hellip
IP (IP dest routereuthethingsnetwork)
UDP (Port dest 1700 Port source 1700)
Donneacutees applicatives (format JSON)
gw_id eui-b827ebfffeae26f5
payload QNAPvA6Ax3ECqHk4C8hfzuA==
lora
spreading_factor 12
bandwidth 125
air_time 2465792000
coding_rate 45
timestamp 2019-01-20T133746017Z
rssi -105
snr -162
dev_addr 0EBC0FD0
frequency 867100000
Internet Transmission Radio LORA
Figure 37 Passerelle (Gateway) LORAWAN
| 38
5 Mise en œuvre drsquoun reacuteseau LoRaWAN
51 Les diffeacuterents types de reacuteseaux Les reacuteseaux LoRaWAN peuvent ecirctre utiliseacute suivant deux meacutethodes
En utilisant les reacuteseaux LoRaWAN opeacutereacutes proposeacutes par les opeacuterateurs de teacuteleacutecoms
En utilisant votre propre reacuteseau LoRaWAN priveacute
511 Les reacuteseaux LoRaWAN opeacutereacutes Ce sont des reacuteseaux LoRaWAN proposeacutes par les opeacuterateurs Par exemple Objenious (filiale de
Bouyges) ou encore Orange Dans le cas de lrsquoutilisation des reacuteseaux opeacutereacutes lrsquoutilisateur a juste
besoin de srsquooccuper des Devices LoRa Les Gateways le Network Server et lrsquoApplication Server sont
geacutereacutes par lrsquoopeacuterateur
512 Les reacuteseaux LoRaWAN priveacutes Chacun est libre de reacutealiser son propre reacuteseau priveacute en impleacutementant sa propre Gateway pour
communiquer avec ses Devices LoRa Lrsquoimpleacutementation du Network Server et de lrsquoApplication Server
peuvent alors ecirctre envisageacutes de diffeacuterentes faccedilons
Network Server et Application serveur priveacutees Crsquoest le deacuteveloppeur qui les mets en place Dans
certaines Gateways une impleacutementation de ces deux serveurs est deacutejagrave proposeacutee Sinon il est
possible de la mettre en place Il existe des serveurs (Network et Application) open source crsquoest le
cas par exemple de LoRa Serveur [ wwwloraserverio ]
Une autre alternantive est httpsgithubcomgotthardplorawan-server
LoRaServer et lorawan-server sont deux applications Open Source
Network Server et Application Server en ligne Un certain nombre de Network Server et
drsquoApplication Server sont proposeacutes Ce sont des services payants ou avec des contreparties
Loriot [ wwwloriotio ]
ResIoT [ wwwresiotio ]
The Things Network [ wwwthethingsnetworkorg ] Crsquoest la solution que nous utiliserons
513 Les zones de couvertures
Les zones de couvertures des reacuteseaux opeacutereacutes sont mise agrave jour par les opeacuterateurs celle drsquoobjenious
est par exemple disponible ici httpsobjeniouscomreseau
Pour connaitre la zone de couverture de notre Gateway utiliseacutee avec TTN nous pouvons utiliser
lrsquoapplication TTN Mapper httpsttnmapperorg Lrsquoideacutee est de promener son Device LoRa associeacute
agrave un GPS dans la zone de couverture des Gateway qui nous entourent A chaque trame reccedilue par le
| 39
Serveur on note les coordonneacutees GPS du Device LoRa ainsi que la Gateway qui a transmis le
message Toutes ces informations sont alors retranscrites sur une carte
52 The Things Network (TTN)
521 Preacutesentation de TTN
Pour la suite nous utiliserons le Network Server et lrsquoApplication Server fourni par TTN
[wwwthethingsnetworkorg]
TTN est gratuit et Open Source En revanche le fait drsquoutiliser TTN impose agrave ceux qui enregistrent
des Gateways de les mettre agrave disposition agrave tous les autres utilisateurs de TTN Lrsquoobjectif est de
reacutealiser un reacuteseau global ouvert
522 Configuration de la Gateway A lrsquouniversiteacute nous avons deux Gateways LoRa (Marque EBDS) Elles sont toutes les deux situeacutees sur
le Campus de Technolac Une Gateway est agrave lrsquointeacuterieur du bacirctiment ISERAN et sert essentiellement
pour les Travaux Pratiques et formations Lrsquoautre est sur le toit du bacirctiment Chablais et est mise agrave
disposition du public via le service de TTN
Les deux Gateway eacutecoutent sur tous les canaux et sur tous les Spreading Factor SF7 gt SF12
Lrsquo IP de la Gateway LoRa agrave lrsquouniversiteacute (bacirctiment ISERAN) est 192168140196
Serveur DNS 1934812032 19348129137
Network Server (TTN) 137616868 routereuthethingsnetwork
Port Upstream 1700 Port Downstream 1700
523 Enregistrement des Gateways Appplication et Devices La configuration de TTN se fait en ligne La premiegravere opeacuteration agrave reacutealiser lorsqursquoune nouvelle
Gateway est deacuteployeacutee crsquoest de lrsquoenregistrer dans TTN
Enregistrement drsquoune Gateway LoRa TTN gt Console gt Gateway gt register gateway
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Figure 38 Scheacutema de notre application
| 40
Figure 39 Enregistrement dune Gateway LoRa sur TTN
Enregistrement drsquoune application TTN gt Console gt Application gt add application
Figure 40 Enregistrement dune application sur TTN
Enregistrement des Devices LoRa dans lrsquoapplication Nom de lrsquoapplication gt register device
Figure 41 Enregistrement des Devices LoRa dans une application
524 Configuration des Devices LoRa Lorsque nous avons enregistreacute des Devices LoRa dans TTN nous devons choisir entre les deux modes
drsquoauthentification Dans un premier temps nous utiliserons le mode le plus simple qui est ABP Nous
geacuteneacuterons dans TTN les DevAddr NetwkSKey et AppSKey
| 41
Figure 42 Configuration des Devices LoRa en ABP dans TTN
53 Mise en application Nous avons dans notre application 10 Devices LoRa drsquoenregistreacutes aduino0 agrave arduino9 Ils sont tous
configureacutes en ABP Les configurations des 10 Devices (DevAddr NetwkSKey et AppSKey) sont noteacutes
en commentaire dans le code de vous allez reacutecupeacuterer
Reacutecupeacuterer le code Arduino laquo RN2483-Arduino-LORAWANino raquo dans Moodle
Modifier votre configuration (DevAddr NetwkSKey et AppSKey) en fonction de votre
numeacutero de binocircme
Veacuterifier que votre Device LoRa arrive bien agrave transmettre des informations (Uplink) vers la
Gateway puis vers le Network Serveur de TTN (The Things Network)
54 Analyse des trames eacutechangeacutees
541 Utilisation de la base 64 Notre Gateway nous preacutesente le Payload PHY en base64 Lrsquoexplication de la meacutethode de
repreacutesentation en base 64 est fourni au travers drsquoun exemple Le code hexadeacutecimal 0x4869
repreacutesente nos donneacutees binaires que nous souhaitons transmettre en base 64
1 On eacutecrit les donneacutees agrave transmettre en binaire
2 On regroupe les eacuteleacutements binaires par des blocs de 6 bits Le nombre de bloc de 6 bits doit
ecirctre un multiple de 4 (minimum 4 blocs) Srsquoil manque des bits pour constituer un groupe de
6 bits on rajoute des zeacuteros
0x4869 = 0100 1000 0110 1001
| 42
3 Srsquoil manque des blocs pour faire un minimum de 4 blocs des caractegraveres speacuteciaux seront
ajouteacutes
4 Chaque groupe de 6 bits est traduit par le tableau suivant (Source Wikipeacutedia)
Figure 43 Codage en base 64
5 Si un bloc de 6 bits manque (ils doivent ecirctre un multiple de 4) on rajoute un ou plusieurs
compleacutements (caractegravere laquo = raquo )
Reacutesultat Le codage de 0x4869 en base 64 est laquo SGk= raquo
010010 000110 100100
On ajoute 00 pour avoir
6 bits dans le groupe
Bloc de 6 bits
010010 000110 100100
S G k
010010 000110 100100
S G k =
1er Bloc
2egraveme Bloc
3egraveme Bloc
4egraveme Bloc
| 43
542 Inteacuterecirct et inconveacutenient de la base 64 Lrsquoutilisation de la base 64 est un choix qui a eacuteteacute fait pour le protocole LoRa LoRaWAN afin de rendre
les donneacutees binaires lisibles Le problegraveme du code ASCII crsquoest qursquoil est composeacute drsquoun certain nombre
de caractegraveres non imprimables (EOF CR LFhellip) Pour eacuteviter ces soucis la base 64 ne comporte que
64 caractegraveres imprimables (voir tableau ci-dessus)
La restriction agrave 64 caractegraveres a cependant un inconveacutenient crsquoest que nous ne pouvons coder que 6
bits (26=64) au lieu de 8 La base 64 est donc moins efficace drsquoune faccedilon geacuteneacuterale
Nous cherchons agrave coder le code ASCII laquo AA raquo en base 64 Retrouver la deacutemarche en
montrant que le reacutesultat en base 64 est laquo QUE= raquo
543 Uplink Du Device LoRa au Network Server Le Network Server de TTN reccediloit des trames IP en provenance de la Gateway Comme nous lrsquoavons
vu preacuteceacutedemment un certain nombre drsquoinformations peuvent ecirctre retrouveacutees avec cette trame
(DevAddr SF Bandwidth etchellip) mais les donneacutees Applicatives sont bien sucircr chiffreacutees (avec
lrsquoAppkSKey) A ce niveau de reacuteception (sans connaitre lrsquoAppSKey) il nrsquoest donc pas possible de
comprendre la totaliteacute du message reccedilu
Imaginons que la trame IP reccedilue 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 45
timestamp 2019-03-05T140042448Z
rssi -82
snr 9
dev_addr 26011AD3
frequency 867300000
Le Network Server affiche donc les informations de la faccedilon suivante
Figure 44 Trame reacutecupeacutereacutee sur le laquo Network Server raquo de TTN
Nous retrouvons bien les valeurs fournies par la Gateway
timestamp ( agrave 1 heure pregraves en fonction du fuseau horaire)
| 44
frequency 8673 Mhz
modulation Lora
Coding Rate 45
data Rate SF 7 125 kHz (DR5)
air time 463 ms
Drsquoautres information proviennent de lrsquoanalyse du Payload Le Payload inscrit ici est le PHY Payload
Il y a donc une partie chiffreacutee (Frame Payload) mais les entecirctes sont en claires (voir paragraphe
441) Ce PHY Payload est laquo QNMaASYABwAP1obuUHQ= raquo Lorsque celui-ci est exprimeacute en
hexadeacutecimal au lieu de la base 64 il vaut laquo 40D31A01260007000FD686EE5074 raquo comme le montre
le Network Server de TTN
Figure 45 PHY Payload preacutesenteacute dans notre Network Server
Sa taille est bien de 14 octets (en hexadeacutecimal) comme preacuteciseacute sur la Figure 44
Nous reprenons le format de la trame LoRaWAN vu agrave la Figure 32 Nous pouvons alors retrouver
tous les champs de toute la trame
PHYPayload = 40D31A01260007000FD686EE5074
PHYPayload = MAC Header[1 octet] | MACPayload[] | MIC[4 octets]
MAC Header = 40 (Unconfirmed data up)
MACPayload = D31A01260007000FD6
Message Integrity Code = 86EE5074
MACPayload = Frame Header | Frame Port | FramePayload )
Frame Header = D31A0126000700
FPort = 0F
FramePayload = D6
Frame Header = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[015]
DevAddr = 26011AD3 (Big Endian)
FCtrl (Frame Control) = 00 (No ACK No ADR)
FCnt (Frame Counter) = 0007 (Big Endian)
FOpts (Frame Option) =
Vous pouvez veacuterifier lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN
(LoRaWAN packet decoder) httpsbitly2szdXtv
| 45
Figure 46 LoRaWAN packet decoder
544 Uplink Du Network Server agrave lrsquoApplication Server
Nous reprenons lrsquoexemple de la trame ci-dessus (Figure 45) Pour information les cleacutes NwkSKey et
AppSKey suivantes ont eacuteteacute utiliseacutee
NwkSKey E3D90AFBC36AD479552EFEA2CDA937B9
AppSKey F0BC25E9E554B9646F208E1A8E3C7B24
Le Network Server a deacutecodeacute lrsquoensemble de la trame Si le MIC est correct (authentification de la
trame par le NwkSKey) alors le Network Server va passer le contenu du message chiffreacute (Frame
Payload) agrave lrsquoApplication Server Dans notre cas le Frame Payload est (drsquoapregraves le deacutecodage effectueacute
au chapitre preacuteceacutedent)
FramePayload = D6
D6 est le contenu chiffreacute lorsqursquoil est deacutechiffreacute avec lrsquoAppSkey on trouve 01 Vous pouvez veacuterifier
lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN httpsbitly2szdXtv
A noter que lrsquoApplication Server recevra les donneacutees chiffreacutees seulement si le Device LoRa a bien
eacuteteacute enregistreacute On peut aussi veacuterifier ci-dessous que lrsquoApplication Serveur de TTN nous retourne bien
un payload (Frame Payload) de 01
Figure 47 Trame reacutecupeacutereacutee sur lrsquoApplication Server de TTN
time 2019-03-05T140042379279991Z
frequency 8673
modulation LORA
data_rate SF7BW125
coding_rate 45
gateways [
gtw_id eui-b827ebfffeae26f6
timestamp 2447508531
time
channel 4
rssi -82
snr 9
latitude 4563647
longitude 58721523
| 46
location_source registry
]
545 Simulation drsquoUplink dans lrsquoApplication Server
Dans beaucoup de situations nous souhaitons valider le fonctionnement de lrsquoApplication Server de
TTN ouet de notre propre Application Il est donc tregraves utile de pouvoir simuler lrsquoenvoi drsquoune trame
LoRa sur lrsquoApplication Server sans que celle-ci soit reacuteellement eacutemise par un Device LoRa Pour cela
un outil existe dans les Settings de chaque Device enregistreacute dans TTN Nous avons juste besoin de
speacutecifier le Frame Payload en clair en hexadeacutecimal et le numeacutero de Port
Figure 48 Simulation drsquoune trame envoyeacutee par un Device LoRa
546 Downlink De lrsquoApplication Server au Device LoRa La communication LoRa est bidirectionnelle Des donneacutees peuvent ecirctre transmis au Device LoRa
depuis lrsquoApplication Server Depuis TTN un outil existe dans les Settings de chaque Device
enregistreacute Lrsquointerface est repreacutesenteacutee ci-dessous
Figure 49 Transmission de donneacutees de lrsquo laquo Application Server raquo jusqursquoau Device LoRa
Replace scheduling Mode Par deacutefaut le Frame Payload transmis remplacera le Frame
Payload en attente (si il existe) Dans ce mode un seul Frame Payload est planifieacute
First scheduling Mode Le Frame Payload est mis en file drsquoattente en premiegravere position
Last scheduling Mode Le Payload est mis en file drsquoattente en derniegravere position
Une demande de confirmation peut ecirctre demandeacutee au Device LoRa pour qursquoil preacutecise srsquoil a bien reccedilu
les donneacutees Lrsquooption laquo confirmed raquo permet donc de speacutecifier le type de trame dans le MAC Header
(voir paragraphe 443) laquo Confirmed Data Down raquo ou laquo Unconfirmed Data Down raquo dans notre cas
| 47
6 La reacutecupeacuteration des donneacutees sur notre propre Application
Nous utiliserons agrave nouveau le Network Server et Application Server de The Things Network Jusqursquoici
nous nous sommes contenteacute de veacuterifier que les donneacutees de lrsquoutilisateur (Frame Payload) soient bien
arriveacutees agrave destination dans lrsquoApplication Server Il faut maintenant les reacutecupeacuterer avec notre propre
Application qui aura pour rocircle
De stocker et traiter les donneacutees
De les mettre agrave disposition de lrsquoutilisateur (Serveur Web par exemple)
Drsquoenvoyer des commandes de lrsquoutilisateur aux Devices LoRa si besoin (Flux Downlink)
Nous allons voir deux meacutethodes pour communiquer entre notre application et TTN
Le protocole HTTP POST
Le protocole MQTT
61 Reacutecupeacuteration des donneacutees en HTTP POST dans lrsquoApplication
611 Preacutesentation du protocole HTTP
Dans le monde de lrsquointernet le protocole HTTP est tregraves utiliseacute pour le dialogue entre un client et un
serveur web Classiquement le client (un navigateur web par exemple) fait une requecircte HTTP GET
et le serveur lui retourne le contenu de la page web demandeacutee
Dans notre cas la probleacutematique est diffeacuterente car le client doit modifier le contenu du serveur
avec les donneacutees envoyeacutees par le Device LORA La requecircte srsquoappelle HTTP POST Son nom indique
que le client va poster (et on pas reacutecupeacuterer) des donneacutees
Lrsquoutilisateur qui souhaite reacuteceptionner des donneacutees sur son serveur doit donc concevoir un serveur
HTTP capable de traiter des requecirctes HTTP POST [ requecircte noteacutee (1) sur la Figure 51 ] fournies par
TTN Dans cette configuration TTN jouera le rocircle de client et notre application le rocircle de serveur
Devices
LORA Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
HTTP POST
MQTT Internet
Figure 50 Structure globale drsquoun reacuteseau LORAWAN
| 48
Figure 51 Communication bidirectionnelle entre TTN et notre Application
A lrsquoinverse lrsquoutilisateur qui souhaite transmettre des donneacutees agrave destination du Device LoRa
(Downlink) doit ecirctre capable de fournir une requecircte HTTP POST [ requecircte noteacutee (2) sur la Figure 51
] vers TTN Dans cette configuration TTN jouera le rocircle de Serveur et notre application le rocircle de
client
612 Fonctionnement drsquoun client et drsquoun serveur HTTP POST Afin de bien comprendre le fonctionnement des requecirctes HTTP POST nous allons proceacuteder par
eacutetape Le premier test que nous effectuerons sera decorreacuteleacute de TTN Le principe est le suivant
Utilisation drsquoun serveur HTTP disponible sur le web geacuterant les requecirctes HTTP POST [
httpsrbasketsin ] ou [ httpsbeeceptorcom ] par exemple
Utilisation drsquoun client HTTP eacutemettant des requecirctes HTTP POST commande curl sous linux
ou logiciel Postman [ wwwgetpostmancom ] sous windows par exemple
Ce test nous permet de valider le fonctionnement drsquoun serveur HTTP POST et drsquoun client HTTP POST
Une fois que nous serons sucircr de leur fonctionnement nous les utiliserons avec TTN
The Things Network
Application
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 49
Figure 52 Validation dun server HTTP POST et drsquoun client HTTP POST
613 Test du serveur HTTP POST Nous utiliserons un serveur web proposeacute par httpsrbasketsin
Aller sur le site httpsrbasketsin et creacuteer un nouveau laquo Basket raquo Zone ougrave vous pourrez
visualiser les requecirctes qui ont eacuteteacute eacutemises vers votre serveur
A partir de maintenant toutes les requecirctes dirigeacutees vers lrsquoadresse creacuteeacute seront traiteacutees et
srsquoafficheront Dans le menu de configuration il est aussi possible de deacutefinir le contenu de la reacuteponse
qui sera fournie
Deacutefinir un format de reacuteponse pour les requecirctes HTTP POST avec un body personnaliseacute
614 Test du client HTTP POST On peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande (la commande cURL
srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN sous Windows
Commande cURL curl ndashX POST ndashd lsquorsquodonneacutees agrave envoyerrsquorsquo DuServeurHTTP
Logiciel Postman New gt Request gt Creacuteer une requecircte HTTP POST gt Send
Veacuterifier que les requecirctes HTTP POST sont bien reacutecupeacutereacutees sur votre serveur creacutee preacuteceacutedemment
615 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST
Maintenant que nous avons un serveur HTTP (POST) fonctionnel nous allons configurer TTN pour
jouer le rocircle du client et pour qursquoil envoie des requecirctes HTTP POST vers notre Serveur degraves qursquoune
donneacutee drsquoun Device LoRa est disponible Nous geacuterons donc ici le flux Uplink
Requecircte
HTTP POST
Reacuteponse
(contenu parameacutetrable)
Client HTTP (POST)
Server HTTP (POST) [ httpsrbasketsin ]
| 50
Figure 53 Reacutecupeacuteration des donneacutees sur notre Application
Dans TTN nous inteacutegrons un bloc appeleacute laquo HTTP Integration raquo permettant de jouer le rocircle de client
crsquoest-agrave-dire drsquoenvoyer des requecirctes HTTP POST agrave destination de notre nouveau Serveur HTTP
Lrsquointeacutegration se faire agrave partir de TTN gt Console gt Application gt Nom_de_votre_application gt
Integration
Figure 54 Ajout dun client HTTP POST dans TTN
Pour valider le fonctionnement de notre architecture nous pouvons soit
Envoyer une trame depuis un Device LoRa vers TTN
Simuler lrsquoenvoi drsquoune trame drsquoun Device LoRa vers TTN (gracircce agrave lrsquooutil proposeacute par TTN vu
paragraphe 545)
Dans les deux cas voici un exemple de requecircte POST reccedilue sur notre serveur HTTP
app_id test_app_lorawan_sylvainmontagny
dev_id stm32lorawan_1
hardware_serial 0056AF49877
port 1
counter 0
payload_raw qg==
metadata
Requecircte
HTTP POST
Server HTTP (POST) [ httpsrbasketsin ]
The Things Network (Client)
La requecircte contient le Frame Payload deacutechiffreacutee
agrave transmettre agrave lrsquoApplication
| 51
time 2019-01-24T15243703499298Z
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Comme nous pouvons le voir le contenu fourni agrave notre serveur est formateacute en JSON (voir
paragraphe 0) Voici quelques compleacutements drsquoinformation
payload_raw Frame Payload deacutechiffreacute crsquoest donc les donneacutees en clairs dans la base 64
downlink_url URL du serveur HTTP POST qui serviront agrave transmettre des donneacutees au Device
LoRa (flux Downlink)
611 Envoyer des donneacutees depuis notre Application avec HTTP POST
Lorsque nous avons ajouteacute le bloc laquo HTTP Integration raquo au paragraphe preacuteceacutedent nous avons aussi
implicitement activeacute la fonctionnaliteacute que TTN soit precirct agrave recevoir et agrave traiter les requecirctes HTTP
POST La seule information qursquoil nous manque est lrsquoadresse du server HTTP vers lequel il faut eacutemettre
les requecirctes Si on observe la trame reccedilue preacuteceacutedemment en provenance de TTN on srsquoaperccediloit que
dans la trame JSON reccedilu une URL (downlink_url) est speacutecifieacutee
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Crsquoest cette URL que nous devrons utiliser Nous allons nous placer dans la configuration suivante
Figure 55 Envoi de donneacutees agrave partir de notre Application
Comme preacuteceacutedemment on peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande
(la commande cURL srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN
Commande cURL curl ndashX POST ndashdata lsquo dev_id Identidiant_De_Votre_Device
payload_raw AQE= rsquo DuServeurHTTP
Logiciel Postman New gt Request gt HTTP POST puis Body gt Raw gt JSON
Requecircte HTTP POST vers serveur TTN laquo downlink_url raquo httpsintegrationsthethingsnetworUaeb8ypKieQ
Contenu de la requecircte
dev_id Identidiant_De_Votre_Device
payload_raw aGVsbG8=
The Things Network (Serveur)
POSTMAN (Client HTTP POST)
| 52
dev_id YourDeviceID
payload_raw aGVsbG8=
Vous devez envoyer le texte (payload_raw) en base 64 Dans lrsquoexemple ci-dessus laquo aGVsbG8= raquo
correspond agrave la chaine de caractegravere laquo hello raquo Vous pouvez utiliser les nombreux encodeurdecodeur
en ligne pour vous aider Le texte doit srsquoafficher sur votre moniteur seacuterie Arduino dans le cadre de
notre deacutemonstrateur sur Arduino
62 Reacutecupeacuteration des donneacutees avec MQTT dans lrsquoApplication
621 Preacutesentation du protocole MQTT
MQTT est un protocole leacuteger qui permet de srsquoabonner agrave des flux de donneacutees Plutocirct que
lrsquoarchitecture Client Serveur classique qui fonctionne avec des Requecirctes Reacuteponses MQTT est
baseacute sur un modegravele Publisher Subscriber La diffeacuterence est importante car cela eacutevite davoir agrave
demander (Requecircte) des donneacutees dont on na aucune ideacutee du moment ougrave elles vont arriver Une
donneacutee sera donc directement transmise au Subscriber degraves lors que celle-ci a eacuteteacute reccedilue dans le
Broker (serveur central)
Figure 56 Modegravele Publisher Subscriber du protocole MQTT
Pour recevoir les donneacutees appartenant agrave un Topic un Subscriber doit souscrire (comme son nom
lindique) au preacutealable sur ce Topic
MQTT est un protocole qui repose sur TCP Lencapsulation des trames sur le reacuteseau est donc la
suivante
Broker
Client
Publisher 1
Client
Publisher 2
Client
Subscriber
Topic
Tempeacuterature
Topic
Humiditeacute
| 53
Figure 57 Protocoles utiliseacutes pour la communication avec MQTT
On peut le veacuterifier par une capture de trame sur Wireshark
Figure 58 Capture dune trame MQTT avec Wireshark
On peut noter que le port TCP utiliseacute pour le protocole MQTT (non chiffreacute) est le 1883
Les Publishers et les Subscribers nrsquoont pas besoin de se connaitre
Les Publishers et les Subscribers ne sont pas obligeacute de srsquoexeacutecuter en mecircme temps
622 Connexion au Broker MQTT Nous nous inteacuteresserons essentiellement aux options de connexion qui permettront de geacuterer la
Qualiteacute de Service (QoS) Pour se connecter un client MQTT envoie deux informations importantes
au Broker
keepAlive Cest la peacuteriode la plus longue pendant laquelle le client Publisher ou Subscriber pourra
rester silencieux Au-delagrave il sera consideacutereacute comme deacuteconnecteacute
cleanSession Lorsque le Client et le Broker sont momentaneacutement deacuteconnecteacutes (au-delagrave du
keepAlive annonceacute) on peut donc se poser la question de savoir ce quil se passera lorsque le client
sera agrave nouveau connecteacute
Si la connexion eacutetait non persistante (cleanSession = True) alors les messages non transmis
sont perdus Quel que soit le niveau de QoS (Quality of Service)
Si la connexion eacutetait persistante (cleanSession = False) alors les messages non transmis
seront eacuteventuellement reacuteeacutemis en fonction du niveau de QoS Voir le chapitre 624
623 Qualiteacute de Service au cours dune mecircme connexion
A partir du moment ougrave le Client se connecte au Broker il est possible de choisir un niveau de fiabiliteacute
des transactions Le Publisher fiabilise leacutemission de ces messages vers le Broker et le Subscriber
fiabilise la reacuteception des messages en provenance du Broker Une parle ici du cas dune mecircme
connexion crsquoest-agrave-dire entre le moment ou le Client se connecte et le moment ougrave
Soit il se deacuteconnecte explicitement (Close connexion)
Soit il na rien eacutemis ni fait signe de vie pendant le temps keepAlive
TCP
MQTT
Reacuteseau
Transport
Couche Application
IP
| 54
Lors dune mecircme connexion la Qualiteacute de Service (QoS) qui est mise en œuvre deacutepend uniquement
de la valeur du QoS selon les valeurs suivantes
QoS 0 At most once (au plus une fois) Le premier niveau de qualiteacute est sans acquittement Le
Publisher envoie un message une seule fois au Broker et le Broker ne transmet ce message quune
seule fois aux Subscribers Ce meacutecanise ne garantit pas la bonne reacuteception des messages MQTT
QoS 1 At least once (au moins une fois) Le deuxiegraveme niveau de qualiteacute est avec acquittement
Le Publisher envoie un message au Broker et attends sa confirmation De la mecircme faccedilon le Broker
envoie un message agrave ces Subscriber et attends leurs confirmations Ce meacutecanisme garantit la
reacuteception des message MQTT
Cependant si les acquittements nrsquoarrivent pas en temps voulu ou srsquoils se perdent la reacuteeacutemission du
message dorigine peut engendrer une duplication du message Il peut donc ecirctre reccedilu plusieurs fois
QoS 2 Exactly once (exactement une fois) Le troisiegraveme niveau de qualiteacute est garanti une seule
fois Le Publisher envoie un message au Broker et attends sa confirmation Le Publisher donne alors
lrsquoordre de diffuser le message et attends une confirmation Ce meacutecanisme garantit que quel que
soit le nombre de tentatives de reacuteemission le message ne sera deacutelivreacute quune seule fois
La Figure 59 montre les trames eacutemises pour chaque niveau de QoS
Figure 59 Qualiteacute de Service en MQTT
La Figure 60 repreacutesentes les 3 captures de trames sur Wireshark repreacutesentant les 3 QoS (1 2 et 3)
que nous venons dexpliquer
Broker
QoS 0
Au plus une fois
Message supprimeacute apregraves envoi
PUBLISH
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Duplications possibles
PUBLISH
PUBLICH Ack
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Pas de duplication
PUBLISH
PUBLISH Receive
PUBLISH Release
PUBLISH Complete
| 55
Figure 60 Capture de trame avec QoS = 0 puis QoS = 1 puis QoS = 2
624 Qualiteacute de Service apregraves une reconnexion
La question que nous nous posons et de savoir ce que deviennent les messages publieacutes sur le Broker
lorsquun ou plusieurs Subscribers sont momentaneacutement injoignables Il est possible de conserver
les messages qui ont eacuteteacute publieacutes sur le Broker afin de les retransmettre lors de la prochaine
connexion Cette possibiliteacute de sauvegarde doit ecirctre activeacutee agrave louverture de connexion gracircce au flag
cleanSession = 0 La connexion sera alors persistante crsquoest-agrave-dire que le Broker enregistre tous les
messages quil na pas reacuteussi agrave diffuser au Subscriber
Le Tableau 9 reacutesume leffet du flag cleanSession et du QoS
Clean Session Flag Subscriber QoS Publisher QoS Comportement True ( = 1) 0 1 2 0 1 2 Messages perdus
False ( = 0 ) 0 0 1 2 Messages perdus
False (= 0 ) 0 1 2 0 Messages perdus
False (= 0 ) 1 2 1 2 Tous les messages sont retransmis
Tableau 9 Qualiteacute de Service en fonction de la valeur du QoS et du flag cleanSession
625 Les Topics du protocole MQTT Les chaicircnes deacutecrivant un sujet forment une arborescence en utilisant la barre oblique comme
caractegravere de seacuteparation La Figure 61 et le Tableau 10 donne un exemple dorganisation de Topic
Figure 61 Exemple de hieacuterarchie de Topic MQTT
Niveau 3
Niveau 2
Niveau 1 Maison
Chambre
Temperature Humidite Bruit
Salon
Temperature
| 56
Nom du Topic Deacutetail du Topic MaisonChambreTemperature La tempeacuterature de la chambre de la maison
MaisonChambreBruit Le bruit de la chambre de la maison
MaisonSalonTemperature La tempeacuterature du Salon de la maison
Tableau 10 Exemple de Topic
Un client peut sabonner (ou se deacutesabonner) agrave plusieurs branches de larborescence agrave laide de
jokers englobant plusieurs Topics Deux caractegraveres jokers existent
Le signe plus + remplace nimporte quelle chaine de caractegravere sur le niveau ougrave il est placeacute
Le diegravese remplace nimporte quelle chaine de caractegravere sur tous les niveaux suivants Il
est obligatoirement placeacute agrave la fin
Nom du Topic Deacutetail du Topic Maison+Temperature Les tempeacuteratures de toutes les piegraveces de la maison
MaisonChambre La tempeacuterature lhumiditeacute et le bruit de la chambre de la maison
Tableau 11 Exemple de Topic
626 Mise en place drsquoun Broker MQTT Afin de bien comprendre le fonctionnement du protocole de MQTT on reacutealise des tests
indeacutependamment de TTN Nous allons mettre en place
Un Broker Mosquitto httpstestmosquittoorg
Un client Publisher MQTT Box sur Windows
Un client Subscriber MQTT Box sur Windows
Figure 62 Test du protocole MQTT
MQTT Client (Subscriber)
MQTT Client (Publisher)
Publish
Subscribe
BROKER (Mosquitto)
| 57
Le Broker MQTT est commun agrave tout le monde Nous pouvons soit le reacutealiser nous-mecircme soit utiliser
un Broker MQTT public de test Nous utiliserons le Broker de test de Mosquitto disponible sur
httpstestmosquittoorg Drsquoautres sont eacuteventuellement disponibles en cas de problegraveme par
exemple httpwwwmqtt-dashboardcom
Si nous deacutecidions de le reacutealiser nous-mecircme agrave lrsquoaide drsquoune Raspberry Pi (par exemple) Lrsquoinstallation
se ferait en deux lignes de commande
apt-get install mosquito Installation
sudo systemctl start mosquittoservice Lancement du service
Il est neacutecessaire drsquoinstaller mosquitto-clients si on souhaite que le Raspberry PI joue aussi le rocircle de
client ce qui nrsquoest pas notre cas
627 Mise en place drsquoun Publisher et drsquoun Subscriber MQTT Lancer le logiciel MQTTBox
MQTTBox gt Create MQTT Client
Dans ce client les seuls champs indispensables sont
Protocol MQTT TCP
Host testmosquittoorg
Figure 63 Configuration dun Client MQTT dans MQTT Box
Tester lrsquoenvoi et la reacuteception sur les Topics de votre choix
628 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT La reacutecupeacuteration des donneacutees fait reacutefeacuterence au flux Uplink Dans ce cas
TTN joue le rocircle de client Publisher
TTN joue aussi le rocircle de Broker
Notre application joue le rocircle de Subscriber
Nous pouvons donc repreacutesenter lrsquoapplication globale par le scheacutema suivant
| 58
Figure 64 Publisher et Subscriber dans en MQTT avec TTN
La publication est repreacutesenteacutee par la trame MQTT (1)
La souscription est repreacutesenteacutee par la trame MQTT (2)
Le client Publisher eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box mais cette fois avec la configuration suivante
Protocol mqtt tcp
Host Crsquoest lrsquoIP du Broker vers lequel il faut se connecter Dans notre cas il srsquoagit de celui
de TTN dont lrsquoadresse est euthethingsnetwork
Username La connexion vers le broker MQTT est soumis agrave une authentification Username
Password Dans notre cas le Username correspond au nom de notre application crsquoest-agrave-
dire seminaire_lorawan Si vous avez choisi une autre applicationil faut bien mettre la
votre
Password Le Password est nommeacute laquo Access Key raquo par TTN Elle vous sera donneacutee par
lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application vous
trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt Overview
Figure 65 Access Keys de lapplication dans TTN
The Things Network (Application Server)
BROKER
Application
The Things Network (Network Server)
Publish (1 )
[ Flux Uplink ]
Subscribe (2 )
[ Flux Uplink ]
| 59
Figure 66 Configuration du Client dans MQTT Box
Le client MQTT eacutetant configureacute il est maintenant capable de se connecter au Broker Il reste donc agrave
deacutefinir le fait que le client sera Subscriber Les informations que recevra le Subscriber deacutependent du
Topic auquel nous souscrivons Voici les Topic disponibles sur le Broker de TTN
ltAppIDgt correspond au nom de votre Application
ltDevIDgt correspond au nom de votre Device LoRa
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink ltAppIDgtdevicesltDevIDgtup
[Donneacutees] Flux Downlink ltAppIDgtdevicesltDevIDgtdown
[Activation Events] Activation dun Device ltAppIDgtdevicesltDevIDgteventsactivations
[Management Events] Creacuteation dun Device ltAppIDgtdevicesltDevIDgteventscreate
[Management Events] Update dun Device ltAppIDgtdevicesltDevIDgteventsupdate
[Management Events] Suppression dun Device ltAppIDgtdevicesltDevIDgteventsdelete
[Downlink Events ] Message programmeacute ltAppIDgtdevicesltDevIDgteventsdownscheduled
[Downlink Events ] Message envoyeacute ltAppIDgtdevicesltDevIDgteventsdownsent
[Erreurs] Uplink erreurs ltAppIDgtdevicesltDevIDgteventsuperrors
[Erreurs] Downlink erreurs ltAppIDgtdevicesltDevIDgteventsdownerrors
[Erreurs] Activations erreurs ltAppIDgtdevicesltDevIDgteventsactivationserrors
Tableau 12 Topics enregistreacutes dans TTN
Dans un premier temps nous souscrivons au Topic +devices+up Cela signifie que nous
souscrivons agrave tous les Devices LoRa de toutes nos applications pour le flux Uplink
Figure 67 Configuration du Subscriber
Les eacuteleacutements eacutemis par le Broker seront alors afficheacutes dans MQTTBox La
| 60
Figure 68 Trame LoRaWAN reccedilu sur le Subscriber MQTT
Ces donneacutees sont eacutecrites en JSON nous pouvons les remettre en forme
applicationID3
applicationNamemyApplication
deviceNamearduino0
devEUI0056xxxxxxxxx877
txInfo
frequency868500000
dr5
adrfalse
fCnt792
fPort15
dataSGVsbG8=
Le Frame Payload deacutechiffreacute est fourni dans le champ data en base 64 La valeur fournie par
dataSGVsbG8= correspond bien agrave la chaine de caractegravere hello que nous avons eacutemise avec le
Device LoRa
629 Envoyer des donneacutees depuis notre Application avec MQTT
Lrsquoenvoi des donneacutees fait reacutefeacuterence au flux Downlink Dans ce cas
Notre application joue le rocircle de Publisher
TTN joue le rocircle de Broker
TTN joue aussi le rocircle de client Subscriber
| 61
La publication est repreacutesenteacutee par la trame MQTT (3)
La souscription est repreacutesenteacutee par la trame MQTT (4)
Le client Subscriber eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box Le rocircle de client dans MQTT Box a eacuteteacute faite au
paragraphe 628 Il nous reste simplement agrave ajouter le rocircle de Publisher La configuration est la
suivante
Topic du Subscriber seminaire_lorawandevicesarduino0down ougrave seminaire_lorawan
est agrave remplacer par le nom de votre application et arduino0 par le nom du Device LoRa vers
lequel vous souhaitez envoyeacute une donneacutee (Voir chapitre 628 pour comprendre les Topics)
Le Payload doit ecirctre au format JSON Lrsquoexemple suivant envoie laquohello raquo
payload_raw aGVsbG8=
The Things Network (Application Server)
BROKER
Application
Publish (3)
[ Flux Downlink ]
The Things Network (Network Server)
Subscribe (4)
[ Flux Downlink ]
| 62
Figure 69 Configuration du Publisher
Vous devriez voir les donneacutees arriver sur votre Device LoRA
| 63
7 Creacuteation de notre propre Network et Application Server
711 Objectifs Lors de la mise en œuvre du reacuteseau LoRaWAN au chapitre 52 nous avons utiliseacute TTN (The Things
Network) pour jouer le rocircle de Network Server et drsquoApplication Server Pour de multiples raisons
Seacutecuriteacute autonomie coucircthellipil peut ecirctre inteacuteressant de monter soi-mecircme un Network Server et un
Application Server Cela est possible seulement si vous posseacutedez vos propres Gateway puisque
celles-ci devront forwarder leur paquet agrave destination preacutecise Il faudra donc les reconfigurer pour
qursquoelles pointent vers votre nouvelle architecture
712 Preacutesentation de LoRaServer LoRaServer [ wwwloraserverio ] est un projet Open-Source reacutepondant exactement au besoin que
nous avons Nous lrsquoutiliserons sur une cible Raspberry PI En reacutealiteacute il peut souvent ecirctre mise en
place dans le mecircme systegraveme que la Gateway surtout si celle-ci est elle-mecircme agrave base de RPI Les
Gateway EBDS que nous posseacutedons possegravedent drsquoailleurs un Network Server et un Application Server
que nous aurions pu utiliser Neacuteanmoins pour des raisons peacutedagogiques il est inteacuteressant de
seacuteparer les systegravemes pour bien diffeacuterencier les probleacutematiques
Attention il y a une ambiguiumlteacute dans la deacutenomination des entiteacutes logiciels de LoRaServer
LoRaServer (sans espace entre le mot LoRa et Server) est le nom du projet global En
revanche LoRa Server (avec un espace) est le nom du service qui joue le rocircle du Network
Server
Lrsquoarchitecture et le fonctionnement de LoRaServer est preacutesenteacutee dans sa documentation par le
scheacutema suivant
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Raspberry PI
Figure 70 Architecture globale de notre reacuteseau loRaWAN
| 64
Figure 71 Architecture deacutetailleacutee de LoRaServer
On srsquoattends agrave voir uniquement un Network Server (LoRa Server) et un Application Server (LoRa App
Server) mais ce scheacutema est plus complexe Il demande un certain nombre drsquoexplications pour bien
comprendre ce que nous allons installer et la faccedilon dont nous lrsquoutiliserons par la suite
713 Le laquo Packet Forwarder raquo (Gateway) Comme nous lrsquoavons vu au chapitre 412 les Gateways LoRa sont des passerelles entre la
modulation LoRa et un reacuteseau IP Pour reacutealiser cette passerelle un service nommeacute laquo UDP Packet
Forwarder raquo a eacuteteacute deacuteveloppeacute par Semtech httpsgithubcomLora-netpacket_forwarder Dans
ce dossier github un fichier nommeacute PROTOCOLTXT explique parfaitement ce protocole applicatif
qui travaille au-dessus de UDP
Figure 72 Protocole Uplink (PUSH_DATA du Packet Forwarder)
| 65
On remarque que les paquets sont envoyeacutes en UDP au Network Server dans une trame appeleacutee
PUSH_DATA Cette trame est acquitteacutee par le Network Server par une trame appeleacutee PUSH_ACK
Sur notre Network Server nous pouvons reacutealiser une capture de trame pour veacuterifier si le protocole
est bien celui preacutesenteacute dans le document
Figure 73 Trame captureacutee par Wireshark lors dun Uplink
Drsquoapregraves la capture preacuteceacutedente on remarque que le Packet Forwarder fonctionne bien avec UDP sur
le port 1700
Le contenu des donneacutees (champ Data) est deacutetailleacute dans le tableau suivant
Champ | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | random token
[3] | 3 | PUSH_DATA identifier = 0x00
[4] | 4-11 | Gateway unique identifier (MAC address)
[5] | 12-end | JSON object starting with ending with
Lrsquoobjet JSON de la transmission reacuteeacutecrit plus proprement est celui-ci
Figure 74 Analyse du champ Donneacutees du protocole laquo Packet Forwarder raquo
0000 02 f9 30 00 b8 27 eb ff fe ae 26 f5 7b 22 72 78 0amprx 0010 70 6b 22 3a 5b 7b 22 74 6d 73 74 22 3a 33 37 35 pk[tmst375 0020 35 30 30 35 38 31 39 2c 22 63 68 61 6e 22 3a 32 5005819chan2 0030 2c 22 72 66 63 68 22 3a 31 2c 22 66 72 65 71 22 rfch1freq 0040 3a 38 36 38 2e 35 30 30 30 30 30 2c 22 73 74 61 868500000sta 0050 74 22 3a 31 2c 22 6d 6f 64 75 22 3a 22 4c 4f 52 t1moduLOR 0060 41 22 2c 22 64 61 74 72 22 3a 22 53 46 37 42 57 AdatrSF7BW 0070 31 32 35 22 2c 22 63 6f 64 72 22 3a 22 34 2f 35 125codr45 0080 22 2c 22 6c 73 6e 72 22 3a 36 2e 35 2c 22 72 73 lsnr65rs 0090 73 69 22 3a 2d 31 2c 22 73 69 7a 65 22 3a 31 38 si-1size18 00a0 2c 22 64 61 74 61 22 3a 22 51 4e 4d 61 41 53 59 dataQNMaASY 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 ]
Ch
amp
[1
]
Ch
amp
[2
]
Ch
amp
[3
]
Ch
amp
[4
]
| 66
rxpk[ tmst3755005819
chan2
rfch1
freq868500000
stat1
moduLORA
datrSF7BW125
codr45
lsnr65
rssi-1
size18
dataQNMaASYAAQAPpyPZ955+SmY
]
Le champ data correspond au PHY Payload
De la mecircme faccedilon on retrouve la Trame drsquoacquittement
Figure 75 Trame captureacutee par Wireshark lors de lrsquoacquittement drsquoun Uplink
Champs | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | same token as the PUSH_DATA to acknowledge
[3] | 3 | PUSH_ACK identifier = 0x01
Nous retrouvons bien tous ces champs dans la trame Wireshark
714 LoRa Gateway Bridge Nous avons deacutecrit au chapitre preacuteceacutedent (713) le fonctionnement du Packet Forwarder Le
Network Server(Lora Server) que nous allons mettre en place aurait tregraves bien pu srsquointerfacer
directement agrave ce protocole Mais cela aurait plusieurs impacts dont un qui est important dans la
conception de logiciel Si le Packet Forwarder change ou si un autre type de Forwarder est utiliseacute
alors lrsquoutilisation du LoRa Server devient impossible Il a donc eacuteteacute choisi de creacuteer une eacutetape
intermeacutediaire Le Network Server que nous mettrons en plus utilisera le protocole MQTT plutocirct que
le protocole UDP packet Forwarder
En drsquoautres termes le LoRa Gateway Bridge est un service qui fera abstraction du Packet Forwarder
pour srsquointerfacer plus simplement avec le Network Server
715 LoRa Server (Network Server) Il srsquoagit de notre Network Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
413 Cependant il srsquointerfacera au protocole MQTT en recevant les informations agrave partir du
Broker au lieu de recevoir directement les trames en provenance de la Gateway
| 67
716 LoRa App Server (Application Server) Il srsquogit de notre Application Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
414
717 LoRa Geo Server Il srsquoagit drsquoun service qui permet drsquoutiliser certaines proprieacuteteacutes du protocole LoRa pour proposer un
service de geacuteolocalisation des Devices LoRa Nous ne lrsquoutiliserons pas dans notre cas
718 Application Il srsquoagit de notre Application qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre 415
Elle ne fait pas partie du projet LoRaServer crsquoest donc bien toujours agrave nous de proposer notre propre
Application
Figure 76 Les interfaces possibles entre LoRaServer et lrsquoApplication utilisateur
Comme nous pouvons le voir sur la figure preacuteceacutedente deux possibiliteacutes sont offertes pour interfacer
notre application JSON REST (incluant HTTP POST) et via un Broker MQTT Ces deux meacutethodes ont
deacutejagrave eacuteteacute traiteacutee au chapitre 61 (HTTP POST ) et au chapitre 62 (MQTT) Nous verrons aussi drsquoautres
possibiliteacutes pour personnaliser notre application au chapitre 7
72 Installation de LoRaServer
721 Mise en place de lrsquoenvironnement
Nous allons installer une carte SD avec la derniegravere version de Raspbian Nous ne deacutetaillerons pas la
deacutemarche pour cela car elles sont largement documenteacutees et mises agrave jour sur le site
wwwraspberrypiorg
Installer un carte SD avec la derniegravere version de Raspbian
Plutocirct que de fonctionner avec un clavier et une souris nous preacuteconisons de travailler agrave distance
avec la RPI via une connexion SSH Depuis quelques anneacutees Raspbian a supprimeacute le deacutemarrage du
service SSH au boot Heureusement il est possible de le reacuteactiver par la meacutethode suivante
Avec Windows ou Linux ouvrir la partition BOOT de votre carte SD et placer un fichier agrave la
racine nommeacute sshtxt (ou ssh)
Mettre la carte SD dans votre RPI et la deacutemarrer
| 68
Pour acceacuteder agrave la RPI en SSH depuis Windows nous utiliserons de preacutefeacuterence le logiciel
client MobaXterm mais tout autre client SSH est valable
Installer MobaXterm sur votre PC et connectez-vous agrave votre Raspberry PI
Lrsquoutilisation drsquoun espion de reacuteseau type Wireshark peut ecirctre inteacuteressant pour eacutetudier les trames qui
sont reccedilues et qui sont eacutemises Cela nous permettra de valider le fonctionnement des diffeacuterents
protocoles reacuteseau qui permettent de communiquer agrave la Gateway drsquoune part et agrave lrsquoApplication
drsquoautre part Nous utiliserons tshark
apt-get install tshark installation
tshark ndashn -i eth0 Exemple drsquoune analyse sur lrsquointerface wlan0
722 Installation sur la Raspberry PI La meacutethode drsquoinstallation de LoRaServer est documenteacutee sur le site web agrave lrsquoadresse suivante
[ httpswwwloraserverioguidesdebian-ubuntu ] Nous installerons le LoRa Gateway Bridge
le LoRa Server et le LoRa App Server
Apregraves lrsquoinstallation la configuration se fait par une interface graphique accessible par le reacuteseau sur
le port 8080
Si vous travaillez sur la RPI connectez-vous sur httplocalhost8080
Si vous travaillez agrave distance (SSH) connectez-vous sur httpIP_RPI8080
Les Usernames et Password par deacutefaut sont
Username admin
Password admin
Lrsquoeacutecran drsquoaccueil sera donc le suivant
Figure 77 Architecture globale apregraves installation de LoRaServer
Devices
Gateways LoRa
UDP Packet Forwarder
Application Server
LoRa App Server
Internet
Network Server
LoRa Server
LoRa Gateway Bridge
| 69
Figure 78 Ecran daccueil de LoRaServer apregraves authentification
71 Configuration de LoRa Server pour lUplink
711 Enregistrement drsquoune nouvelle Organisation
Pour enregistrer une nouvelle Organizations Organizations gt Create Puis entrer les configurations
suivantes
Figure 79 Enregistrement dun nouvelle Organisation
712 Enregistrement drsquoune instance du Network Server Pour enregistrer une nouvelle instance du Network Server Network Server gt Create Puis entrer
les configurations suivantes
| 70
Figure 80 Enregistrement dun nouveau Network Server
Dans lrsquoonglet Gateway Discovery il est possible drsquoactiver une option de deacutecouverte de Gateway aux
alentours Lorsqursquoelle est configureacutee le Network Server va envoyer une trame Downlink de
configuration de la Gateway lui ordonnant de reacutealiser des PING en LoRa La configuration du
Gateway Discovery preacutevoit de speacutecifier
Le nombre de fois par jour que les PING LoRa sont envoyeacutes
Le canal drsquoeacutemission
Le Data Rate (Voir paragraphe 445)
Un PING LoRa reccedilu sur une Gateway sera retransmis sur le Network Server (Lora Server) et une carte
sera afficheacutee
Lrsquoonglet TLS Certificates ne sera pas utiliseacute dans le cadre de notre deacutemonstration
713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) Il faut tout drsquoabord faire un enregistrement drsquoun laquo service-profile raquo Un laquo service profile permet de
faire la connexion entre le Network Server et les Applications que nous enregistrerons dans notre
Organisation Service-profiles gt Create
Service-profile name myServiceProfile
Network-server myNetworkServer
On laissera par deacutefaut toutes les autres options
Pour enregistrer une nouvelle Application Applications gt Create Puis entrer les configurations
suivantes
| 71
Figure 81 Enregistrement dune nouvelle Application
714 Enregistrement des Devices LoRa Il faut tout drsquoabord faire lrsquoenregistrement drsquoun Device-profile pour les Devices LoRa que vous
souhaitez connecter Dans notre cas nous ferons un premier test en speacutecifiant que nous utilisons
seulement le mode drsquoauthentification ABP (voir chapitre 431) Devices profile gt Create
Figure 82 Enregistrement dun laquo Device profile raquo
Nous pouvons alors creacuteer dans notre Application des nouveaux Devices Application gt
myApplication gt Create
| 72
Figure 83 Enregistrement dun nouveau Device LoRa
Dans la fenecirctre Activation on va alors configurer les 3 eacuteleacutements indispensables agrave une
authentification en APB Le DevAddr le NwkSKey et lrsquoAppSKey
Figure 84 Configuration de lenregistrement du Device LoRa (en ABP)
La configuration minimale de LoRaServer est maintenant termineacutee Nous pouvons donc brancher
un Device LoRa qui possegravede les les attribus (DevAddr NwkSKey et AppSKey) que nous avons
enregistreacute dans LoRaServer et le faire eacutemettre
715 Visualisation des trames reccedilues Les trames eacutemises par le Device LoRa vont donc parcourir le cheminement suivant
| 73
Figure 85 Reacutesumeacute du cheminement des trames LoRaWan en Uplink avec LoRaServer
En allant dans le Live Device Data (Application gt Nom_du_Device gt Live Device Data) on peut voir la
liste des trames reccedilues ainsi que les donneacutees applicatives deacutechiffreacutees
Figure 86 Reacuteception des trames des Devices LoRa
Figure 87 Analyse des trames des Devices LoRa
Dans lrsquoonglet LIVE LORAWAN FRAME nous pouvons voir les trames LORAWAN et si besoin eacutetudier
le contenu de ce qursquoelles contiennent En revanche les donneacutees applicatives sont ici chiffreacutees
UDP
Packet Forwarder
LoRa Bridge
Gateway LoRa Server LoRa App Server
Gateway
Server
Internet
| 74
Figure 88 Reacuteception des Trames LoRaWAN
72 Configuration de LoRaServer pour linteacutegration dApplication Nous avons vu dans le chapitre 718 que linterface entre LoRaServer et notre Application pouvait
ecirctre reacutealiseacutee soit par MQTT soit par les meacutethodes REST (HTTP POST) Nous avons deacutejagrave impleacutementeacute
et expliqueacute ces protocoles dans le cadre de son utilisation avec TTN Nous allons donc juste
configurer LoRaServer pour tester ces deux meacutethodes
721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST Nous utiliserons exactement la mecircme meacutethode que celle que nous avons utiliseacute avec TTN au
chapitre 615 Les diffeacuterentes Clients et Serveurs disponibles pour ces tests sont expliqueacutes au
paragraphe 612
Dans LoRaServer ajouter une inteacutegration HTTP LoRaServer gt Applications gt myApplication gt
Integrations gt Create gt HTTP Integration et la configurer comme le montre la Figure 89 Vous
remplacerez eacutevidement le lien par votre propre Endpoints
Figure 89 Configuration de linteacutegration HTTP POST dans LoRaServer
En envoyant des trames LoRa depuis votre Device vous devriez voir les contenus JSON sur votre
Endpoint
722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT Nous allons nous connecter au Broker MQTT de LoRaServer Pour cela nous utiliserons la mecircme
meacutethode que celle que nous avons utiliseacute avec TTN au chapitre 628 Nous utiliserons MQTTBox
comme nous lavons deacutejagrave fait au paragraphe 627
Le Broker de LoRaServer a enregistreacute les Topics suivant
[applicationID] correspond au nom de votre Application
[devEUI] correspond au nom de votre Device LoRa
| 75
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink application[applicationID]device[devEUI]rx
[Donneacutees] Flux Downlink application[applicationID]device[devEUI]tx
[Status] Statut dun Device application[applicationID]device[devEUI]status
[Ack] Acquittement des messages application[applicationID]device[devEUI]ack
[Erreurs] Erreurs application[applicationID]device[devEUI]error
Tableau 13 Topics enregistreacutes dans LoRaServer
| 76
8 Creacuteation de notre propre Application
81 Utilisation de Node-RED
811 Preacutesentation Node-RED est un outil de programmation graphique qui permet de faire communiquer les
peacuteripheacuteriques mateacuteriels drsquoun systegraveme sans eacutecrire de code De nombreux protocoles sont aussi pris
en charge au travers de bloc ( Node) qursquoil suffit de connecter entre eux pour reacutealiser simplement
une application Il peut srsquoexeacutecuter localement sur un PC ou sur des cibles embarqueacutees telle qursquoune
Raspberry PI (RPI)
Dans les deacutemonstrations que nous mettrons en œuvre nous utiliserons une RPI Par soucis de
simpliciteacute nous utiliserons les derniegraveres versions de Raspbian (systegraveme drsquoexploitation de la RPI) qui
integravegre drsquoorigine Node-RED Il nrsquoy a donc tregraves peu de chose agrave mettre en place pour arriver agrave mettre
en place une Application Nous pouvons travailler soit directement sur la RPI agrave lrsquoaide drsquoune souris-
clavier mais il est recommandeacute de travailler agrave distance avec une connexion SSH
812 Mise en place de lrsquoenvironnement La mise en place de la RPI avec le systegraveme drsquoexploitation Raspbian a eacuteteacute preacutesenteacute au chapitre 721
Vous pouvez reprendre la mecircme installation ou repartir sur une nouvelle
Il est possible de faire en sorte que Node-RED se lance directement au deacutemarrage gracircce agrave la
commande sudo systemctl enable noderedservice
Sil nest pas actif lancer Node-RED sur votre RPI node-red-start
Nous nous connectons au Node-RED de la RPI via un navigateur web sur le port 1880 en tapant dans
la barre dURL httpIP_Raspeberry_PI1880 Ce nous permet darriver agrave la fenecirctre suivante
Figure 90 Page daccueil de Node-RED
Il est possible de sinterfacer avec TTN avec les Nodes deacutejagrave disponibles gracircce au protocole HTTP
POST ou MQTT Neacuteanmoins nous pouvons avantageusement installer deux librairies speacutecifiques
Une qui facilite linterfaccedilage avec TTN
Une qui facilite la mise en place dinterface graphique
Installation des Nodes TTN
cd $HOMEnode-red
npm install node-red-contrib-ttn
Installation de Dashboard (interface graphique)
| 77
cd $HOMEnode-red
npm install node-red-dashboard
Il peut ecirctre necessaire de redeacutemarrer Node-RED pour prendre en compte linstallation de nos deux
Nodes
-----------------------------------
sudo apt-get install npm
sudo npm install -g npm
hash -r
cd ~node-red
npm install node-red-example node name
------------------------------------
813 Creacuteer une Application speacutecifique pour TTN Nous allons commencer par geacuterer le flux Uplink Apporter sur votre scheacutema un Node ttn uplink et
un Node Debug puis relier les Le Node ttn uplink nous permettra de configurer la
communication avec TTN en MQTT Le Node debug eacutecrira sur le terminal les informations brutes
qui seront reccedilu par le Node ttn uplink
Figure 91 Visualisation des trame publieacutees par TTN sur notre client MQTT
Double cliquer sur le Node ttn uplink pour le configurer comme la figure suivante
Le champ Name sera le nom du Node sur votre scheacutema Le champ Device ID est le device LoRa
concerneacute dans votre application De plus il faut entrer les caracteacuteristiques de votre application (Add
new ttn app) pour que Node-RED puisse sy connecter
Figure 92 Configuration du node ttn uplink
Configuration de votre nouvelle application
| 78
Figure 93 Identifiant et mot de passe de notre application
AppID Nom de votre application Dans notre cas seminaire_lorawan
Access Key Comme nous lavons deacutejagrave expliqueacute plus tocirct l Access Key vous sera donneacutee
par lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application
vous trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt
Overview
Le Node ttn uplink doit maintenant avoir le nom que vous avez configureacute Cliquer sur Deploy pour
lancer votre projet Le bloc ttn uplink doit maintenant ecirctre connecteacute agrave TTN Cela est speacutecifieacute
connected sous le bloc
Figure 94 Utilisation du Node TTN Uplink
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
Figure 95 Simulation de Uplink dans TTN
Vous devriez voir le reacutesultat dans la fenecirctre de Debug Par exemple pour le test denvoi de 31 32
correspondant au code ASCII des chiffres 1 et 2 vous devriez avoir la fenecirctre de Debug suivante
| 79
Figure 96 Reacutesultats obtenu dans la fenecirctre Debug apregraves la simulation dUplink
814 Creacuteation drsquoun Dashboard
Dans la mise en place de lenvironnement (chapitre 812) nous avons installeacute des Nodes
Dashboard qui vont nous permettre de reacutealiser une interface graphique tregraves simple et de la mettre
agrave disposition des utilisateurs via un des graphiques histogramme gauges afficheurshellip
Figure 97 Impleacutementation dune interface graphique dans Node RED
Linterface graphique que nous allons creacuteer sera constitueacutee donglet (tab) La mise en place des
composant se fait de la faccedilon suivante
Chaque eacuteleacutement graphique doit appartenir agrave un groupe de composant quil va falloir creacuteer
Chaque groupe de composant doit appartenir agrave un onglet (tab) quil va falloir creacuteer
Figure 98 Creacuteation dun groupe de composant
Figure 99 Creacuteation dun nouvel onglet dans le site web
Cliquer sur Deploy pour activer votre application
LURL pour joindre linterface graphique de votre site web est disponible sur ladresse
httpIP_Raspeberry_PI1880ui
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
| 80
Figure 100 Interface graphique du site web avec Node-RED
82 Programmation en PHP Maintenant que nous avons testeacute toute lrsquoarchitecture nous pouvons mettre en place une
application qui jouera deux rocircles
Un rocircle de Serveur HTTP POST reacutecupeacuterant les donneacutees en provenance de TTN
Un rocircle de Client HTTP POST qui geacuteneacuterera les requecirctes vers TTN
Un serveur web apache sur RPI heacuteberge cette application Linterface graphique du site web est
reacutealiseacute avec le template CSS proposeacute par Bootstrap [ httpsgetbootstrapcom ]
Figure 101 Architecture de notre application en PHP sur RPI
The Things Network
Notre Application
[ Serveur Apache sur Raspberry Pi ]
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 81
Nous allons lrsquoutiliser telle quelle Elle est juste proposeacutee agrave titre dexemple Lrsquoobjectif de cette
application est de geacuteneacuterer une ouverture fermeture de ruche agrave distance dans le cadre de projets
eacutetudiants du Master Electronique et Systegravemes Embarqueacutes de lUSMB [ httpscem-esetuniv-
smbfr ]
Figure 102 Application permettant de recevoir et deacutemettre des requecirctes HTTP POST
Configurer TTN pour pointer vers votre nouveau serveur et tester le flux montant et
descendant
| 82
9 Versions du document
Version 10 02022019
Version initiale
Version 20 23022019
Ajout drsquoun paragraphe Les systegravemes embarqueacutes dans lrsquoIoT En introduction
Compleacutement et ameacutelioration Ameacutelioration exercice eacutetalement de spectre
Correction Cacircblage Arduino
Ajout drsquoun paragraphe Fonctionnement de lrsquoArduino et ajout de librairies
Compleacutement et ameacutelioration Couche physique LoRa Ajout de 4 figures pour lrsquoexplication
de la modulation Chirp
Ajout drsquoun paragraphe sur les acronymes utiliseacutes au deacutebut du cours TTN LoRa MQTThellip
Compleacutement drsquoinformations sur les dB et dBm
Ajout LoRa Calculator
Version 30 8032019
Ajout de figure sur le rocircle de la Gateway LoRa
Ajout de paragraphe authentification avec le Network Server
Ajout de paragraphe sur le chiffrement avec lrsquoApplication Server
Ajout drsquoun sommaire en deacutebut de cours
Ajout de 2 scheacutemas ABP et OTAA
Retrait explication du deacutetail de la laquo Join Request raquo en OTAA Trop complexe attente de
reacutealisation drsquoun scheacutema plus explicite
Ajout drsquoun scheacutema sur lrsquoattaque par REPLAY
Ajout de paragraphe des diffeacuterents reacuteseaux LoRaWAN existants Opeacutereacutes et Priveacutes
Ajout des scheacutemas des trames LoRaWAN Physique LoRa MAC Application
Compleacutement drsquoinformation sur les Classes de Devices
Ajout drsquoun paragraphe sur la Gateway utiliseacutee pour le Downlink
Ajout drsquoun paragraphe sur le JSON
Compleacutement drsquoinformation sur le codage en Base64
Ajout drsquoinformation dans le deacutecodage des trames LoRaWAN
Restructuration des explications sur lrsquoenvoi et la reacutecupeacuteration des donneacutees en HTTPMQTT
Version 40 8032019
Ajout drsquoun chapitre Creacuteation de notre propre Application
Ajout drsquoun chapitre Creacuteation de notre propre Network et Application Server
Ajout drsquoune figure Visualisation des Chirps LoRa par SDR (Radio Logicielle)
Compleacutements drsquoinformation sur MQTT
Compleacutements dinformation sur les Topics de TTN en MQTT
| 8
Les Devices LoRa sont capables drsquoeacutemettre sur un mecircme canal en mecircme temps Le protocole LoRa
utilise une modulation tregraves similaire agrave la meacutethode 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 Plus
tard dans le cours nous expliquerons les diffeacuterences de la modulation LoRa
13 Notion drsquo eacutetalement de spectre utiliseacutee en LoRa Nous allons voir au travers drsquoun exercice comment il est possible drsquoutiliser tout le spectre en
permanence tout en eacutetant capable drsquoeffectuer plusieurs transactions simultaneacutees entre diffeacuterents
eacutemetteursreacutecepteurs Cette meacutethode est souvent appeleacutee laquo eacutetalement de spectre raquo car comme
son nom lrsquoindique elle a pour conseacutequence drsquoeacutetaler le spectre du signal transmis
La meacutethode consiste agrave utiliser des codes qui ont des proprieacuteteacutes matheacutematiques adapteacutees agrave notre
objectif Transmettre en mecircme temps sur la mecircme bande de freacutequence La matrice ci-dessous
donne par exemple 4 codes drsquoeacutetalement (1 par ligne)
Code Orthogonal User 0 1 1 1 1
Code Orthogonal User 1 1 -1 1 -1
Code Orthogonal User 2 1 1 -1 -1
Code Orthogonal User 3 1 -1 -1 1
Tableau 1 Matrice de Hadamart (matheacutematicien) dordre 4
Les proprieacuteteacutes de ces codes (1 1 1 1 1 -1 1 -1 1 1 -1 -1 1 -1 -1 1) ne sont pas expliqueacutees ici Nous
nous conterons de veacuterifier leur bon fonctionnement
131 Transmissions successives Chaque tableau ci-dessous repreacutesente une transmission qui est indeacutependante des autres elles ne
se deacuteroulent pas en mecircme temps On veacuterifie qursquoavec la mise en œuvre de laquo lrsquoeacutetalement de spectre raquo
chaque transmission arrive bien agrave destination avec le message qui avait eacuteteacute transmis Le premier
tableau est deacutejagrave rempli en guise drsquoexemple La meacutethode est la suivante
A lrsquoeacutemission
Chaque bit du message est multiplieacute par un code drsquoeacutetalement (une ligne de la matrice)
Le reacutesultat de la multiplication est transmis
A la reacuteception
Chaque symbole reccedilu est multiplieacute par le mecircme code drsquoeacutetalement
Le message reccedilu est eacutegal agrave la somme des symboles diviseacute par le nombre de symbole
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
hellip transmission hellip
4 Utilisation code orthogonal User 1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1
5 Deacutecodage = (3) x (4) 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0
6 Message reccedilu (sum (5) nbr_bits) 1 0 1 0
Reacutealiser la transmission du message du User 2 et du User 3 dans les tableaux suivants
| 9
1rsquo Message User 2 0 1 0 1
2rsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
3rsquo Symboles transmis User 2 = (1rsquo) x (2rsquo) 0 0 0 0
hellip transmission hellip
4rsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
5rsquo Deacutecodage = (3rsquo) x (4rsquo) 0 0 0 0
6rsquo Message reccedilu (sum (5rsquo) nbr_bits) 0
1rsquorsquo Message User 3 1 1 0 0
2rsquorsquo Utilisation code orthogonal User 3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
3rsquorsquo Symboles transmis User 3 = (1rsquorsquo) x (2rsquorsquo) 1 -1 -1 1
hellip transmission hellip
4rsquorsquo Utilisation code orthogonal User3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
5rsquorsquo Deacutecodage = (3rsquorsquo) x (4rsquorsquo) 1 1 1 1
6rsquorsquo Message reccedilu (sum (5rsquorsquo) nbr_bits) 1
132 Transmissions simultaneacutees
Les transmissions se deacuteroulent maintenant simultaneacutement les messages des User 1 User 2 et User
3 sont envoyeacutes en mecircme temps sur la mecircme bande de freacutequence La premiegravere colonne du User 1
est deacutejagrave remplie en guise drsquoexemple La meacutethode est la suivante
Dans lrsquoair
On additionne les symboles transmis par tous les User (1 2 3) ligne 1rsquorsquorsquo
Pour la reacuteception
Chaque symbole reccedilu est multiplieacute par le code drsquoeacutetalement du User
Le message reccedilu est eacutegal agrave la somme des symboles diviseacute par le nombre de symbole
Valider le fonctionnement pour la reacuteception des messages
1rsquorsquorsquo sum des symboles transmis ( 3 + 3rsquo + 3rsquorsquo ) 2 -2 0 0
2rsquorsquorsquo Utilisation code orthogonal User 1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 2 0 0
4rsquorsquorsquo Message reccedilu User 1 (sum (3rsquorsquorsquo) nbr_bits) 1
2rsquorsquorsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 -2 0 0
4rsquorsquorsquo Message reccedilu User 2 (sum (3rsquorsquorsquo) nbr_bits) 0
2rsquorsquorsquo Utilisation code orthogonal User 3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 2 0 0
4rsquorsquorsquo Message reccedilu User 3 (sum (3rsquorsquorsquo) nbr_bits) 1
133 Cas du protocole LoRa Le LoRa utilise une meacutethode drsquoeacutetalement de spectre qui nrsquoest pas exactement celle que nous venons
drsquoeacutetudier La finaliteacute est cependant la mecircme Pouvoir transmettre en mecircme temps sur le mecircme
canal Le protocole LoRa utilise sept laquo codes drsquoeacutetalement raquo appeleacutes Spreading Factor [ SF6 SF7 SF8
SF9 SF10 SF11 et SF12 ] qui lui permet drsquoavoir sept transmissions simultaneacutees sur un mecircme canal
| 10
2 Transmission radio et propagation
21 Les uniteacutes et deacutefinitions dB Rapport entre deux puissances Une atteacutenuation est repreacutesenteacutee par un nombre
neacutegatif (-) Un gain est repreacutesenteacute par un nombre positif (+)
Rapport de puissances en dB Rapport de puissance
+ 3 dB Multiplication par 2
- 3 dB Division par 2
0 dB Egaliteacute
+ 10 dB Multiplication par 10
- 10 dB Division par 10
Tableau 2 Comparaison entre les gains en dB et en proportion
dBi Gain theacuteorique drsquoune antenne
dBm Puissance rameneacutee agrave 1mW 0 dBm correspond agrave 1 mW
En reprenant la deacutefinition des dB remplir le tableau suivant
Puissance en dBm Puissance en mW
+ 3 dBm
- 3 dBm
+ 10 dBm
- 10 dBm
Tableau 3 Comparaison entre les puissances en dB et en mW
Le Talkie-Walkie a une puissance drsquoeacutemission de 2W Quelle est la puissance drsquoeacutemission
exprimeacutees en dBm
Sensibiliteacute Puissance minimale qursquoest capable de deacutetecter un reacutecepteur
RSSI Received Signal Strength Indication
SNR Signal over Noise Ratio
Un eacutemetteur transmet agrave une puissance de 13dBm en utilisant une antenne dont le gain
est de 2dBi Les pertes dans lrsquoair sont de 60 dB Lrsquoantenne reacuteceptrice qui possegravede un gain
de 2dBi est relieacutee agrave un reacutecepteur dont la sensibiliteacute est de -80 dBm Le signal pourra-t-il
ecirctre reccedilu
Le link Budget Crsquoest la quantiteacute de puissance que nous pouvons perdre avant drsquoarriver au
reacutecepteur tout en conservant une transmission fonctionnelle Autrement dit crsquoest la
puissance de lrsquoeacutemetteur moins la sensibiliteacute du reacutecepteur Dans lrsquoexemple preacuteceacutedent le
budget que nous avons agrave disposition est de 93dB
| 11
En LoRa nous avons un Link Budget de 157 dB
En LTE (4G) nous avons un Link Budget de 130 dB
Etude de la documentation drsquoun composant LoRa Le RN2483 est le composant radiofreacutequence que nous utiliserons dans notre transmission LoRa
Voici quelques une de ses caracteacuteristiques
Figure 3 Caracteacuteristiques principales du composant radiofreacutequence utiliseacute
Reprenez la deacutefinition du Link Budget et retrouver les 157 dB annonceacute dans cette
documentation
En LoRa plus le code drsquoeacutetalement est grand plus on est capable drsquoeacutemettre dans un milieu bruiteacute La
figure ci-dessous preacutesente les rapports signal sur bruit avec lesquels nous seront capable de reacutealiser
une transmission en fonction des Spreading Factor utiliseacutes
Figure 4 Influence du Spreading Factor sur le SNR acceptable
On remarque que pour un SF8 nous sommes capables drsquoeacutemettre avec un SNR de -10 dB On pourra
transmettre malgreacute le fait que le bruit est 10 fois supeacuterieur au signal
On remarque que pour un SF12 nous sommes capables drsquoeacutemettre avec un SNR de -20 dB On
pourra transmettre malgreacute le fait que le bruit est 100 fois supeacuterieur au signal
| 12
Cependant on remarque aussi que lrsquoutilisation drsquoun Spreading Factor plus eacuteleveacute augmente
consideacuterablement le nombre de symbole eacutemis (2egraveme colonne du tableau) Comme nous le verrons
plus tard cela impactera eacutevidement le temps de transmission
| 13
3 La couche physique LoRa
31 La modulation LoRa Comme nous lrsquoavons expliqueacute plus tocirct la modulation LoRa utilise lrsquoeacutetalement de spectre pour
transmettre ces informations Mais au lieu drsquoutiliser des codes drsquoeacutetalement (CDMA) elle utilise une
meacutethode appeleacutee Chirp Spread Spectrum La finaliteacute est toujours la mecircme Avoir plusieurs
transmissions dans le mecircme canal La conseacutequence sur le spectre est aussi la mecircme cela provoque
un eacutetalement du spectre
311 La forme du symbole (Chirp) Le signal eacutemis par la modulation LoRa est un symbole dont la forme de base est repreacutesenteacutee ci-
dessous Son nom (Chirp) vient du fait que ce symbole est utiliseacute dans la technologie Radar (Chirp
Compressed High Intensity Radar Pulse)
Figure 5 Symbole de la modulation LoRa (source Wikipeacutedia)
La freacutequence de deacutepart est la freacutequence centrale du canal moins la Bande Passante diviseacutee par deux
La freacutequence de fin est la freacutequence centrale plus la Bande Passante diviseacutee par deux
La freacutequence centrale est appeleacutee le canal
La bande passante est la largeur de bande occupeacutee autour du canal
On considegravere une eacutemission sur la freacutequence centrale 868 Mhz avec une Bande Passante
de 125 kHz Donner la freacutequence de deacutebut et la freacutequence de fin du sweep
Freacutequence de deacutebut
Freacutequence de fin
Pour faciliter la repreacutesentation de ce symbole on utilise plutocirct un graphique TempsFreacutequence de
la forme suivante
| 14
Figure 6 Forme du symbole de base (CHIRP)
En LoRa chaque symbole repreacutesente un certain nombre de bits transmis La regravegle est la suivante
Nombre de bits transmis dans un symbole = Spreading Factor
Par exemple si la transmission utilise un Spreading Factor de 10 (SF10) alors un symbole repreacutesente
10 bits
Crsquoest-agrave-dire qursquoagrave lrsquoeacutemission les bits sont regroupeacutes par paquet de SF bits puis chaque paquet est
repreacutesenteacute par un symbole particulier parmi 2119878119865formes de symboles possibles
Sur la figure suivante voici un exemple theacuteorique drsquoune modulation en SF2 agrave 868 Mhz sur une
bande passante de 125 kHz Chaque symbole repreacutesente donc 2 bits
Figure 7 Symboles eacutemis en Modulation LoRa (Cas theacuteorique en SF2)
Exemple
On considegravere la suite binaire suivante 0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Le Spreading Factor utiliseacute est SF10
Nous regroupons donc les bits par paquet de 10 Chaque paquet de 10 bits sera repreacutesenteacute par un
symbole (sweep) particulier Il y a 1024 symboles diffeacuterents pour coder les 1024 combinaisons
binaires possibles (210)
Freacutequence
Temps
868 000 000 Hz
868 062 500 Hz
Un symbole Un symbole
867 937 500 Hz
Temps
868 000 000 Hz
867 937 500 Hz
Symbole 0
Bits laquo 00 raquo
Symbole 1
Bits laquo 01 raquo
Symbole 2
Bits laquo 10 raquo Symbole 3
Bits laquo 11 raquo
12
5 k
Hz
868 062 500 Hz
| 15
Figure 8 Emission des Chirp en LoRa
Avec un outils drsquoanalyse spectrale actif pendant lrsquoeacutemission LoRa drsquoun Device on peut afficher les
successions de symbole qui sont envoyeacutes Cette oscillogramme a eacuteteacute reacutealiseacute agrave lrsquoaide drsquoun SDR
(Software Digital Radio)
Figure 9 Visualisation des Chirps LoRa reacuteellement eacutemis pendant une transmission
312 Dureacutee drsquoeacutemission drsquoun symbole En LoRa la dureacutee drsquoeacutemission de chaque symbole (Chirp) deacutepend du Spreading Factor utiliseacute Plus le
SF est grand et plus le temps drsquoeacutemission sera long Pour une mecircme bande passante le temps
drsquoeacutemission drsquoun symbole en SF8 est deux fois plus long que le temps drsquoeacutemission drsquoun symbole en
SF7 Ainsi de suite jusqursquoagrave SF12
0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Envoi de 1 Chirp Envoi de 1 Chirp Envoi de 1 Chirp
Transmission Transmission Transmission
| 16
Figure 10 Temps drsquoeacutemission drsquoun symbole (Chirp) en fonction du SF
En revanche le temps drsquoeacutemission drsquoun symbole est inversement proportionnel agrave la bande passante
119879119904 =2119878119865
119861119886119899119889119908119894119889119905ℎ Le deacutebit des symboles est donc de
1
119879119878= 119865119904 =
119861119886119899119889119908119894119889119905ℎ
2119878119865 En toute logique plus la
bande passant est eacuteleveacute plus le deacutebit des symboles sera eacuteleveacute Comme chaque symbole comprend
SF bit on retrouve alors le deacutebit binaire
119863119887 = 119878119865119861119886119899119889119908119894119889119905ℎ
2119878119865
Plus le Spreading Factor sera eacuteleveacute plus le deacutebit binaire sera faible
Plus la Bande Passante sera eacuteleveacutee plus le deacutebit binaire sera fort
Exemple Drsquoapregraves la formule du deacutebit binaire trouver le deacutebit pour les deux cas suivants
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
32 Coding Rate Le Coding Rate est un ratio qui augmentera le nombre de bits agrave transmettre afin de reacutealiser de la
deacutetection correction drsquoerreur Dans le cas drsquoun CR = 4 8 il y aura 8 bits transmis reacuteellement agrave
chaque fois que nous souhaitons transmettre 4 bits Dans cette exemple cela provoque une
transmission drsquoun nombre de bit multiplieacute par 2
SF7
Freacutequence
Temps
Freacutequence centrale
Freacutequence haute
Temps drsquoun symbole eacutemit en SF 12
Freacutequence basse
SF8
SF9
SF10
SF11
SF12
Temps drsquoun symbole eacutemit en SF 11
| 17
Figure 11 Influence du Coding Rate sur le nombre de bits ajouteacute
Si on reprend lrsquoexemple preacuteceacutedent avec un CR de 4 5 nous avons une augmentation de 125 du
nombre de bits agrave transmettre Redonner la deacutebit en prenant en compte le CR
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
La documentation du composant RN2483 donne les deacutebits en fonction du Spreading Factor
la Bande Passante et le Coding Rate Veacuterifier la coheacuterence du reacutesultat avec votre calcul
preacuteceacutedent
Figure 12 Deacutebit en fonction des paramegravetres de la transmission LoRa
33 Utilisation du LoRa Calculator Le logiciel laquo LoRa Calculator raquo est un petit exeacutecutable permettant de simuler une transmission LoRa
en fonction des caracteacuteristiques saisies Canal SF CR etchellip Il est teacuteleacutechargeable agrave lrsquoadresse
suivante httpsbitly2TyloAh
| 18
Figure 13 Le logiciel LoRa Calculator
En reprenant lrsquoexemple preacuteceacutedent (SF7 Bande Passante 125 kHz CR 45) veacuterifier les
calculs du laquo Equivalent Bitrate raquo
34 Time On Air La norme LoRaWAN impose qursquoun Device LoRa ne transmette pas plus de 1 du temps Cela est
repreacutesenteacute par un Duty Cycle Par exemple un Duty Cycle de 1 signifie que si jrsquoeacutemet pendant 1 je
ne dois plus eacutemettre pendant 99 quel que soit lrsquouniteacute de temps utiliseacutee
En reprenant les exemples preacuteceacutedents quels sont les deacutebits moyens si on prend en compte
le laquo Time On Air raquo
Cas 1 Pour SF7 et 125 khz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
Dans le logiciel laquo LoRa Calculator raquo (onglet laquo Energy Profile raquo) nous pouvons estimer la
dureacutee de vie drsquoune batterie Nous prenons lrsquoexemple drsquoun releveacute de tempeacuterature dans un
bacirctiment avec les caracteacuteristiques suivantes
| 19
SF CR Bande Passante etc Nous nous placcedilons dans le cas 1 des exemples preacuteceacutedents
Le releveacute de tempeacuterature se fera toutes les 15 mins
La batterie est constitueacute de 3 petites piles bacirctons [ AAA LR03 ] 12V en seacuterie Soit 36 V
1000 mAh
35 Mise en œuvre LoRa en point agrave point Ce test sera reacutealiseacute avec des modules LoRa RN2483 (Microchip) et une carte microcontrocircleur
ARDUINO
Figure 14 Communication LoRa en Point agrave Point
Reacutealiser le cacircblage de votre module RN2483 suivant le tableau suivant
Connecteur Arduino Click Board RN2483
5V 5V
GND GND
11 RX
10 TX
Tableau 4 Cacircblage de lrsquoARDUINO et de la click Board RN2483
351 Utilisation de lrsquoIDE Arduino Lrsquoenvironnement Arduino est tregraves simple Nous allons reacutealiser un programme pour montrer son
fonctionnement
La connexion de la carte est effectueacutee agrave lrsquoaide drsquoun port USB qui eacutemule une liaison seacuterie
RS232 Il faut donc choisir le bon port Arduino IDE gt Outils gt Port
Pour creacuteer un nouveau programme (sketch) Arduino IDE gt Fichier gt Nouveau
Il y a deux parties dans un sketch
Une fonction setup() qui sera exeacutecuteacutee qursquoune seule fois au deacutemarrage
Une fonction loop() qui sera exeacutecuteacutee en boucle
Ecrire le code suivant
Emetteur
Reacutecepteur
UA
RT
UA
RT
| 20
void setup()
Serialbegin(9600)
void loop()
Serialprintln(hello word)
Compiler et Teacuteleacuteverser Croquis gt Teacuteleacuteverser
Voir la sortie sur la liaison seacuterie Outils gt Moniteur Seacuterie gt Choisir la vitesse de
transmission ici 9600 bauds (en bas agrave droite)
352 Validation du fonctionnement Deux binocircmes joueront le rocircle drsquoeacutemetteur tous les autres binocircmes seront en reacutecepteur
Reacutecupeacuterer les programmes dans Moodle dans le dossier laquo RN2483-Arduino-Point2Point raquo
Installer la librairie RN2483 Arduino IDE gt Croquis gt Inclure une bibliothegraveque gt Ajouter la
bibliothegraveque zip
Reacutepartissez les rocircles Emetteurs Reacutecepteurs et reacutecupeacuterer le programme LoraBlinkerRX ou
LoraBlinkerTX en fonction Les 2 binocircmes en eacutemission devront modifier le code du sketch
Arduino pour transmettre des donneacutees speacutecifiques afin de les diffeacuterencier [
loraSerialprintln(radio tx 30) ]
Validez la reacuteception des donneacutees eacutemises par les deux binocircmes qui transmettent des
donneacutees Ces donneacutees reccedilues sont eacutecrite agrave 57600 bauds sur le moniteur seacuterie de lrsquoArduino
353 Mise en valeur du Spreading Factor On srsquoaperccediloit dans la manipulation preacuteceacutedente que les Devices LoRa reccediloivent les donneacutees des deux
eacutemetteurs Nous allons conserver le mecircme canal drsquoeacutemission (8691 Mhz) mais un des deux
eacutemetteurs va modifier son laquo Spreading Factor raquo La salle sera donc seacutepareacutee en deux groupes
1er groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF7
2egraveme groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF8
Validez la reacuteception des donneacutees eacutemises seulement pour le Spreading Factor que vous
utilisez
| 21
4 Le protocole LoRaWAN
Le LoRa est le type de modulation utiliseacute entre deux Devices ou entre un Device et une Gateway
Lorsque nous parlons de lrsquoensemble de la chaine de communication (Device Gateway Serveur) alors
nous parlons de communication LoRaWAN Nous allons voir lrsquoarchitecture drsquoun reacuteseau LoRaWAN
ainsi que les regravegles de ce protocole
41 Structure drsquoun reacuteseau LoRaWAN Nous retrouvons drsquoun cocircteacute le Device LoRa qui transmet une donneacutee Elle est reacuteceptionneacutee agrave lrsquoautre
extreacutemiteacute du reacuteseau par un Utilisateur La structure globale du reacuteseau LoRaWAN peut ecirctre
repreacutesenteacutee par la figure suivante
411 Les Devices LoRa Les Devices LoRa sont des systegravemes eacutelectroniques appartenant au monde de lrsquoIoT Faible
consommation faible taille faible puissance et faible taille
Ils possegravedent une radio LoRa permettant de joindre les Gateways Les Gateways ne sont pas
adresseacutees speacutecifiquement toutes celles preacutesentes dans la zone de couverture reccediloivent les
messages et les traitent
412 Les Gateways LoRa Elles eacutecoutent sur tous les canaux et sur tous les Spreading Factor Lorsqursquoune trame LoRa est reccedilue
elle transmet son contenu sur internet agrave destination du Network Server qui a eacuteteacute configureacute dans la
Gateway au preacutealable
Elle joue donc le rocircle de passerelle entre une modulation LoRa et une communication IP
Devices
LoRa Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
Internet Internet
Figure 15 Structure globale dun reacuteseau LORAWAN
| 22
Chaque Gateway LoRa possegravede un identifiant unique (EUI sur 64 bits)
413 Le Network Server
Le Network Server reccediloit les messages transmis par les Gateways et supprime les doublons
(plusieurs Gateway peuvent avoir reccedilu le mecircme message) Les informations transmises au Network
Server depuis les Devices LoRa sont authentifieacutes gracircce agrave une cleacute AES 128 bits appeleacutee Network
Session Key NwkSKey Nous parlons bien ici drsquoauthentification et non pas de chiffrement comme
nous le verrons plus tard
414 Application Server Il est souvent sur le mecircme support physique que le Network Server Il permet de dissocier les
applications les unes des autres Chaque application enregistre des Devices LoRa qui auront le droit
Devices Gateways Network
Server
Internet
Network Session Key (NwkSKey)
Authentification
Figure 17 Authentification entre le Device LoRa et le Network Server
Internet
UDP IP
Modulation
LoRa
Device LoRa
Gateway
Network Server
LoRaWAN
Modulation
LoRa
Passerelle LoRa Internet
Internet
UDP IP
LoRaWAN
Transmission Radio
Application Application
Figure 16 Le rocircle de la Gateway LoRa
| 23
de stocker leurs donneacutees (Frame Payload) Les message transmis agrave lrsquoapplication server sont chiffreacutes
gracircce agrave une cleacute AES 128 bits appeleacutee Application Session Key AppSKey
Le scheacutema suivant reacutesume lrsquoutilisation
De la Network Session Key (NwkSKey) pour lrsquoauthentification entre le Device LoRa et le
Network Server
De lrsquoApplication Session Key (AppSKey) pour le chiffrement entre le Device LoRa et
lrsquoApplication Server
Devices Gateways Network
Server Application
Server
Internet
Application Session Key (AppSKey)
Chiffrement
Figure 18 Chiffrement entre le Device LORA et lrsquoApplication Server
| 24
415 Application Web Serveur Cette application doit drsquoune part reacutecupeacuterer les donneacutees de lrsquoApplication Serveur Dans le cadre de
ce cours cela sera fait de deux faccedilons
Avec le protocole HTTP
Avec le protocole MQTT
Figure 20 Application Web Server
Figure 19 Authentification et chiffrement en LoRaWan
Devices Gateways
Network
Server Application
Server
Internet
Network Session Key
Application Session Key
Network
Server Application
Server
Application
Server Web
Utilisateur
Protocole
MQTT ou HTTP
Flux Uplink
Flux Downlink
| 25
Le flux habituel dans lrsquoIoT est le flux Uplink (flux montant) crsquoest-agrave-dire lrsquoeacutemission de donneacutees des
objets vers le serveur Comme nous lrsquoexpliquerons plus loin en LoRaWAN il est aussi possible de
transfeacuterer des donneacutees aux Device LoRa par un flux Downlink (flux descendant)
Drsquoautre part lrsquoapplication mettra agrave disposition les donneacutees aux utilisateurs sous forme par exemple
drsquoun serveur web drsquoune base de donneacutees et drsquoune visualisation graphique
416 Authentification avec le Network Server La Network Session Key (NwkSKey) sert agrave lrsquoauthentification entre le Device LoRa e le Network Server
Afin de reacutealiser cette authentification entre le Device et le Network Server un champ MIC (Message
Integrity Control) est rajouteacute agrave la trame Il est calculeacute en fonction des donneacutees transmises et du
NwkSkey A la reacuteception le mecircme calcul est effectueacute Si les cleacutes sont eacutequivalentes dans le Device et
dans le Network Server alors les deux MIC calculeacutes doivent correspondre
417 Chiffrement des donneacutees vers lrsquoApplication Server
LrsquoApplication Session Key (AppSKey) sert pour le chiffrement entre le Device LoRa et lrsquoApplication
Server Les donneacutees chiffreacutees seront alors deacutecodeacutees agrave la reacuteception sur lrsquoApplication Server srsquoil
possegravede la mecircme cleacute Si on reprend le scheacutema preacuteceacutedent les laquo donneacutees x raquo sont chiffreacutees
deacutechiffreacutees par le processus suivant
Donneacutees x chiffreacutees NwkSkey x
MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees
NwkSkey x
Trame eacutemise Trame reccedilue
Device LoRa Network Server
Si =
Alors la trame est authentifieacutee
MIC geacuteneacutereacute Emission MIC geacuteneacutereacute Reacuteception
MIC geacuteneacutereacute Reacuteception
Figure 21 Authentification dun Device LoRa par le Network Server
| 26
Figure 22 Chiffrement des donneacutees par lApplication Session Key
418 Combinaison de lrsquoauthentification et du chiffrement On peut maintenant repreacutesenter sur le mecircme scheacutema la construction de la trame LoRaWAN avec
drsquoune part lrsquoauthentification et drsquoautre part le chiffrement
Figure 23 Chiffrement puis Authentification
42 Classes des Devices LoRaWAN Les Devices LoRa sont classeacutes en 3 cateacutegories (A B C) en fonction de leur consommation et de leur
accessibiliteacute en Downlink crsquoest-agrave-dire la faciliteacute qursquoun utilisateur aura agrave transmettre une trame au
Device LoRa
421 Classe A (All) Minimal power Application Tous les Devices LoRaWAN sont de classe A Chaque Device peut transmettre (Uplink) agrave la Gateway
sans veacuterification de la disponibiliteacute du reacutecepteur Si la transmission eacutechoue elle sera reacuteeacutemise apregraves
un certain temps Cette transmission est suivie de 2 fenecirctres de reacuteception tregraves courtes La Gateway
peut alors transmettre pendant le laquo RX Slot 1 raquo ou le laquo RX Slot 2 raquo mais pas les deux
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Device LoRa
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Application Server
Donneacutees non chiffreacutees
AppSKey
Donneacutees chiffreacutees Entecircte
NwkSKey
MIC geacuteneacutereacute en eacutemission Trame transmise =
| 27
Figure 24 Slots de reacuteception pour un Device LoRa de classe A
Source de lrsquoimage httpszakelijkforumkpncom
La dureacutee des fenecirctres doit ecirctre au minimum la dureacutee de reacuteception drsquoun preacuteambule Un preacuteambule
dure 1225 Tsymbole et deacutepend donc du Data Rate (DR voir paragraphe 445 pour plus drsquoinformation
sur le DR) Lorsque qursquoun preacuteambule est deacutetecteacute le reacutecepteur doit rester actif jusqursquoagrave la fin de la
transmission Si la trame reccedilue pendant la premiegravere fenecirctre de reacuteception eacutetait bien agrave destination du
Device LoRa alors la deuxiegraveme fenecirctre nrsquoest pas ouverte
Premiegravere fenecirctre de reacuteception
Le Slot RX1 est programmeacute par deacutefaut agrave 1 seconde + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont les mecircme que ceux choisis lors de la phase drsquoeacutemission
(Uplink)
Seconde fenecirctre de reacuteception
Le Slot RX2 est programmeacute par deacutefaut agrave 2 secondes + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont configurables mais fixes
Un Device LoRa qui est uniquement de classe A ne peut pas recevoir srsquoil nrsquoa pas eacutemis Il
nrsquoest donc pas joignable facilement
422 Classe B (Beacon) Scheduled Receive Slot Les Devices de classe B ont le mecircme comportement que les Devices de classe A mais drsquoautres
fenecirctres de reacuteceptions sont programmeacutees agrave des peacuteriodes preacutecises Afin de synchroniser les fenecirctres
de reacuteception du Device LoRa la Gateway doit transmettre des balises (Beacons) de faccedilon reacuteguliegravere
| 28
Figure 25 Slots de reacuteception pour un Device LoRa de classe B
Source de lrsquoimage httpszakelijkforumkpncom
Un Device LoRa de classe B est joignable reacuteguliegraverement sans qursquoil soit neacutecessairement
obligeacute drsquoeacutemettre En revanche il consomme plus qursquoun Device de classe A
423 Classe C (Continuous) Continuously Listening Les Devices de classe C ont des fenecirctres de reacuteception constamment ouvertes entre 2 Uplinks Ces
Devices consomment donc beaucoup plus
Figure 26 Slots de reacuteception pour un Device LoRa de classe C
Source de lrsquoimage httpszakelijkforumkpncom
| 29
Un Device LoRa de classe C est joignable en permanence En revanche crsquoest la classe de
Device qui est la plus eacutenergivore
424 Quelle Gateway pour les flux Downlink
Nous avons donc vu que le fonctionnement classique du protocole LoRaWAN eacutetait de reacutecupeacuterer de
lrsquoinformation depuis le Device LoRa Crsquoest le flux Uplink
Dans le cas ougrave lrsquoutilisateur transmet des informations au Device LoRa (flux Downlink) on peut se
demander quelle Gateway sera choisie pour transfeacuterer les donneacutees au Device LoRa En effet
lrsquoendroit ougrave est situeacute le Device LoRa nrsquoest pas neacutecessairement connu agrave lrsquoavance
La Gateway utiliseacutee pour le Downlink est celle qui a reccedilu le dernier message du Device
LoRa Un message ne pourra jamais arriver agrave destination drsquoun Device LoRa si celui-ci nrsquoa
jamais transmis quel que soit sa classe A B ou C
43 Activation des Devices LoRa et seacutecuriteacute En LoRaWAN les trois eacuteleacutements indispensables pour la communication sont le DevAddr pour
lrsquoindentification du Device ainsi que deux cleacutes le NwkSKey pour lrsquoauthentification et lrsquoAppSKey
pour le chiffrement Deux meacutethodes sont possibles pour fournir ces informations agrave la fois au Device
LoRa et au serveur
Activation By Personalization APB
Over The Air Activation
431 ABP Activation By Personalization Crsquoest la plus simple des meacutethodes Crsquoest donc peut ecirctre celle que nous avons tendance agrave utiliser lors
drsquoun test de prototype et drsquoune mise en place de communication LoRaWAN
Le Device LoRa possegravede deacutejagrave le DevAddr lrsquoAppSKey et le NwkSKey
Le Network server possegravede deacutejagrave le DevAddr et le NwkSKey
Lrsquoapplication serveur possegravede deacutejagrave le DevAddr et le AppSKey
En ABP toutes les informations neacutecessaires agrave la communication sont deacutejagrave connues par le
Device LoRa et par le Serveur
| 30
432 OTAA Over The Air Activation Crsquoest la meacutethode qursquoil faut privileacutegier car crsquoest celle qui est la plus seacutecuriseacutee Le Device LoRa doit
connaitre le DevEUI lrsquoAppEUI et lrsquoAppkey Le Network Server doit lui connaitre la mecircme Appkey
Tous les eacuteleacutements noteacutes EUI (Extended Unique Identifier) sont toujours sur une taille de
64 bits
Gracircce agrave ces informations de deacutepart et une neacutegociation avec le Network Server (Join Request) le
Device LoRa et le serveur vont geacuteneacuterer les informations essentielles DevAddr NwkSKey et
AppSKey
Figure 28 Obtention du DevAddr NwkSKey et AppSKey en OTAA
DevEUI Unique Identifier pour le device LoRa (Equivalent agrave une MAC sur Ethernet)
Certains Device LoRa ont deacutejagrave un DevEUI fourni en usine
AppEUI Unique Identifier pour lrsquoapplication server
DevEUI
AppEUI
AppKey
Join
Request
DevAddr
NwkSKey
AppSKey
Network Server
Application Server
Devices 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 2
NwkSkey 2
AppSKey 2
Devices 2
DevAddr 2
NwkSkey 2
AppSKey 2
Paramegravetres stockeacutes sur le serveur
Paramegravetres programmeacutes
dans le composant
Figure 27 Parameacutetrage de DevAddr NwkSKey et AppSKey
| 31
AppKey AES 128 cleacute utiliseacutee pour geacuteneacuterer le MIC (Message Code Integrity) lors de la Join
Resquest Il est partageacute avec le Network server
NwkSKey Utiliseacute pour lrsquoauthentification avec le Network Server
AppSKey Utiliseacute pour le chiffrement des donneacutees
433 Seacutecuriteacute Les cleacutes AES 128 bits permettent le chiffrement des informations transmises en LoRaWAN Malgreacute
ce chiffrement une attaque connue en Wireless est celle du REPLAY Crsquoest-agrave-dire que le Hacker
enregistre des trames chiffreacutees circulant sur le reacuteseau LoRa pour les reacuteeacutemettre plus tard Mecircme si
le Hacker ne comprend pas le contenu (les trames sont chiffreacutees) les donneacutees qui sont transporteacutees
sont elles bien comprises par lrsquoApplication Server Des actions peuvent donc ecirctre reacutealiseacutees
simplement par mimeacutetisme
Pour eacuteviter cela la trame LoRaWAN integravegre un champ variable appeleacute laquo Frame Counter raquo Il srsquoagit
drsquoun nombre numeacuterotant la trame sur 16 ou 32 bits LrsquoApplication Server acceptera une trame
uniquement si le laquo Frame Counter raquo reccedilu est supeacuterieur au laquoFrame Counter raquo preacuteceacutedemment Donc
si le Hacker retransmet la trame telle qursquoelle le laquo Frame Counter raquo sera eacutequivalent donc la trame
sera refuseacutee Et comme la trame est chiffreacutee le Hacker nrsquoa pas moyen de savoir comment modifier
un champ de cette trame
Cette seacutecuriteacute impleacutementeacutee par les laquo Frame Counter raquo est inteacuteressante pour srsquoaffranchir drsquoune
attaque par REPLAY mais dans nos tests cela peut poser problegraveme En effet agrave chaque fois que nous
redeacutemarrons le microcontrocircleur notre laquo Frame Counter raquo revient agrave zeacutero alors que celui de
lrsquoApplication Server continue de srsquoincreacutementer Cela peut ecirctre reacutesolue par diffeacuterentes maniegraveres
1 Deacutesactivation du laquo Frame Counter Check raquo Dans certain Application Server cette option
peut ecirctre proposeacutee Bien sucircr il faudra garder en tecircte la faille de seacutecuriteacute que cela engendre
Network Server
Application Server
Devices LoRa
NwkSkey
AppSKey
NwkSkey
AppSKey Hacker
(1) (2)
(1) Ecoute
(2) Reacuteeacutemission
Figure 29 Attaque par REPLAY
| 32
Figure 30 Deacutesactivation du Frame Counter Check dans TTN
2 Utiliser lrsquoauthentification par OTAA au lieu de ABP En effet agrave chaque ouverture de session
en OTAA le laquo Frame Counter raquo est reacuteinitialiseacute coteacute serveur
3 Conserver la valeur du laquo Frame Counter raquo dans une meacutemoire non volatile et reacutecupeacuterer sa
valeur au deacutemarrage du Device LoRa
44 La Trame LoRa LoRaWAN
441 Les couches du protocole LoRaWAN
Lorsque nous avons fait une communication en Point agrave Point nous avons simplement utiliseacute la
couche physique de la modulation LoRa Lorsque nous souhaitons utiliser le protocole LoRaWAN
des couches protocolaires suppleacutementaires se rajoutent
Figure 31 Les couches protocolaires du LoRaWAN
Chaque couche rajoute un service Lors de lrsquoenvoi de la trame les donneacutees utilisateurs sont donc
encapsuleacutees dans chaque couche infeacuterieure jusqursquoagrave la transmission Le deacutetail de lrsquoensemble de la
trame LoRaWAN par couche est deacutecrit sur la figure Figure 32
LoRa Modulation
LoRa Mac
Application
Couche Physique
Couche Mac
Couche Application
| 33
442 Couche Application La couche Application accueille les donneacutees de lrsquoutilisateur Avant de les encapsuler elles sont
chiffreacutees avec lrsquoAppSKey afin de seacutecuriser la transaction
Un ensemble de champs nommeacute Frame Header permet de speacutecifier le DevAddr le Frame Control
le Frame Counter et le Frame Option
Le Frame Port deacutepend du type drsquoapplication et sera choisi par lrsquoutilisateur
Le Frame Payload sont les donneacutees chiffreacutees agrave transmettre Le nombre drsquooctets maximum pouvant
ecirctre transmis (N octets) est donneacute dans le tableau suivant
PHY Payload
P octets Couche
Physique
Couche
Mac
Couche
Application
CRC
2 octets Header + Header CRC
20 bits Preamble
MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Figure 32 Trame LORAWAN complegravete par couche protocolaire
Couche
Application Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Frame Header
Figure 33 Trame LORA couche Applicative
| 34
Data Rate Spreading Factor Bandwidth Max Frame Payload (Nombre N) DR 0 SF12 125 KHz 51 octets
DR 1 SF11 125 KHz 51 octets
DR 2 SF10 125 KHz 51 octets
DR 3 SF9 125 KHz 115 octets
DR 4 SF8 125 KHz 222 octets
DR 5 SF7 125 KHz 222 octets
DR 6 SF7 250 KHz 222 octets
Tableau 5 Taille maximum du Frame Payload en fonction du Data Rate
443 Couche LoRa MAC Cette trame est destineacutee au Network Server Elle est authentifieacutee gracircce au champ MIC (Message
Integrity Protocol) selon la meacutethode expliqueacutee au paragraphe 416
Le protocole LoRa MAC est composeacute de
1 MAC Header Version de protocole et type de message
Type de Message Description 000 Join-Request
001 Join-Accept
010 Unconfirmed Data Up
011 Unconfirmed Data Down
100 Confirmed Data Up
101 Confirmed Data Down
110 Rejoin-request
111 Proprietary
Tableau 6 Les types de messages transmis en LoRaWAN
2 MAC Payload Contient tout le protocole applicatif
3 MIC Message Integrity Code pour lrsquoauthentification de la trame
444 Couche physique Modulation LoRa
Le choix du moment drsquoeacutemission des Devices LoRa se fait de faccedilon simple Lorsqursquoun eacutequipement
doit eacutemettre il le fait sans controcircle et ne cherche pas agrave savoir si le canal est libre Si le paquet a eacuteteacute
perdu il le retransmettra simplement au bout drsquoun temps aleacuteatoire La couche physique est
repreacutesenteacutee par lrsquoeacutemission de la trame suivante
Couche
Mac MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Figure 34 Trame LORA couche LORA MAC
| 35
Le Preacuteambule est repreacutesenteacute par 8 symboles + 425 Le temps du Preacuteambule est donc de 1225
Tsymbole
Len-tecircte (Header optionnel) est seulement preacutesent dans le mode de transmission par deacutefaut
(explicite) il est transmis avec un Coding Rate de 48 Il indique la taille des donneacutees le Coding Rate
pour le reste de la trame et il preacutecise eacutegalement si un CRC sera preacutesent en fin de trame
Le PHY Payload contient toutes les informations de la Couche LoRa MAC
Le CRC sert agrave la deacutetection drsquoerreur de la trame LoRa
445 Canaux et bandes de freacutequences et Data Rate (DR) Le LoRa utilise des bandes de freacutequences diffeacuterentes suivant les reacutegions du monde En Europe la
bande utiliseacutee est celle des 868 Mhz [ De 863 Mhz agrave 870 Mhz ] Le LoRaWAN deacutefinie les 8 canaux agrave
utiliser pour communiquer avec une Gateway suivant le tableau suivant
Canaux Spreading Factor Bandwidth 8681 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz SF7 250 kHz
8685 Mhz De SF7 agrave SF12 125 kHz
8671 Mhz De SF7 agrave SF12 125 kHz
8673 Mhz De SF7 agrave SF12 125 kHz
8675 Mhz De SF7 agrave SF12 125 kHz
8677 Mhz De SF7 agrave SF12 125 kHz
8679 Mhz De SF7 agrave SF12 125 kHz
Tableau 7 Canaux SF et Bandwidth de notre Gateway LoRaWAN
Une Gateway LoRa eacutecoute donc sur 8 canaux simultaneacutement avec les 6 Spreading Factor
diffeacuterents soit 48 combinaisons possibles
Comme nous lrsquoavons vu le Spreading Factor a des conseacutequences sur le deacutebit de la transmission Ces
deacutebits sont noteacutes DR (Data Rate) et sont normaliseacutes de DR0 agrave DR6
PHY Payload
P octets Couche
Physique CRC
2 octets Header + Header CRC
( Optionnel ) 20 bits Preamble
Figure 35 Trame LORA couche Physique
| 36
Data Rate Spreading Factor Bandwidth DR 0 SF12 125 KHz
DR 1 SF11 125 KHz
DR 2 SF10 125 KHz
DR 3 SF9 125 KHz
DR 4 SF8 125 KHz
DR 5 SF7 125 KHz
DR 6 SF7 250 KHz
Tableau 8 Deacutenomination DR en fonction du SF et de la Bande Passante
446 Trame reccedilue et transmise par la Gateway LoRaWAN La Gateway reccediloit drsquoun cocircteacute un message radio moduleacute en LoRa et transmet de lrsquoautre cocircteacute une trame
IP agrave destination du Network Server
Coteacute interface Radio La Gateway reacuteceptionne une trame LoRaWAN et extrait le PHY Payload Celui-
ci est codeacute au format ASCII en base 64 (voir le paragraphe 541) La Gateway extrait aussi toutes les
informations utiles sur les caracteacuteristiques de la reacuteception qui a eu lieu SF Bandwidth RSSI Time
On Airhellipetchellip
Coteacute interface reacuteseau IP La Gateway transmet lrsquoensemble de ces informations dans un paquet IP
(UDP) au Network Server Les donneacutees transmises sont du texte en format JSON (voir paragraphe
447) La Gateway a donc bien un rocircle de passerelle entre le protocole LoRa drsquoun cocircteacute et un reacuteseau
IP de lrsquoautre
Internet
UDP IP
Device LoRa
Gateway
Network Server Modulation
LoRa
Passerelle LoRa Internet
Transmission Radio Internet
Figure 36 Rocircle de la Gateway LoRa
| 37
447 Le format JSON Le format JSON est un format texte composeacute drsquoune succession de couple nomvaleur Dans
lrsquoexemple de la figure preacuteceacutedente gw_id est un nom et eui-b827ebfffeae26f5 est la valeur
associeacutee Dans cette exemple la valeur est un string Les objets sont deacutelimiteacutes par un des accolades
et
Une valeur peut ecirctre
Un string exemple coding_rate 45
Un nombre exemple spreading_factor 12
Un objet exemple lora spreading_factor 12 air_time 2465792000
Un Boolean
Ethernet
Gateway
Modulation
LORA
Reacutecupeacuteration du PHY PAYLOAD en base 64
Reacutecupeacuteration des caracteacuteristiques de la transmission Canal SF CR hellip
IP (IP dest routereuthethingsnetwork)
UDP (Port dest 1700 Port source 1700)
Donneacutees applicatives (format JSON)
gw_id eui-b827ebfffeae26f5
payload QNAPvA6Ax3ECqHk4C8hfzuA==
lora
spreading_factor 12
bandwidth 125
air_time 2465792000
coding_rate 45
timestamp 2019-01-20T133746017Z
rssi -105
snr -162
dev_addr 0EBC0FD0
frequency 867100000
Internet Transmission Radio LORA
Figure 37 Passerelle (Gateway) LORAWAN
| 38
5 Mise en œuvre drsquoun reacuteseau LoRaWAN
51 Les diffeacuterents types de reacuteseaux Les reacuteseaux LoRaWAN peuvent ecirctre utiliseacute suivant deux meacutethodes
En utilisant les reacuteseaux LoRaWAN opeacutereacutes proposeacutes par les opeacuterateurs de teacuteleacutecoms
En utilisant votre propre reacuteseau LoRaWAN priveacute
511 Les reacuteseaux LoRaWAN opeacutereacutes Ce sont des reacuteseaux LoRaWAN proposeacutes par les opeacuterateurs Par exemple Objenious (filiale de
Bouyges) ou encore Orange Dans le cas de lrsquoutilisation des reacuteseaux opeacutereacutes lrsquoutilisateur a juste
besoin de srsquooccuper des Devices LoRa Les Gateways le Network Server et lrsquoApplication Server sont
geacutereacutes par lrsquoopeacuterateur
512 Les reacuteseaux LoRaWAN priveacutes Chacun est libre de reacutealiser son propre reacuteseau priveacute en impleacutementant sa propre Gateway pour
communiquer avec ses Devices LoRa Lrsquoimpleacutementation du Network Server et de lrsquoApplication Server
peuvent alors ecirctre envisageacutes de diffeacuterentes faccedilons
Network Server et Application serveur priveacutees Crsquoest le deacuteveloppeur qui les mets en place Dans
certaines Gateways une impleacutementation de ces deux serveurs est deacutejagrave proposeacutee Sinon il est
possible de la mettre en place Il existe des serveurs (Network et Application) open source crsquoest le
cas par exemple de LoRa Serveur [ wwwloraserverio ]
Une autre alternantive est httpsgithubcomgotthardplorawan-server
LoRaServer et lorawan-server sont deux applications Open Source
Network Server et Application Server en ligne Un certain nombre de Network Server et
drsquoApplication Server sont proposeacutes Ce sont des services payants ou avec des contreparties
Loriot [ wwwloriotio ]
ResIoT [ wwwresiotio ]
The Things Network [ wwwthethingsnetworkorg ] Crsquoest la solution que nous utiliserons
513 Les zones de couvertures
Les zones de couvertures des reacuteseaux opeacutereacutes sont mise agrave jour par les opeacuterateurs celle drsquoobjenious
est par exemple disponible ici httpsobjeniouscomreseau
Pour connaitre la zone de couverture de notre Gateway utiliseacutee avec TTN nous pouvons utiliser
lrsquoapplication TTN Mapper httpsttnmapperorg Lrsquoideacutee est de promener son Device LoRa associeacute
agrave un GPS dans la zone de couverture des Gateway qui nous entourent A chaque trame reccedilue par le
| 39
Serveur on note les coordonneacutees GPS du Device LoRa ainsi que la Gateway qui a transmis le
message Toutes ces informations sont alors retranscrites sur une carte
52 The Things Network (TTN)
521 Preacutesentation de TTN
Pour la suite nous utiliserons le Network Server et lrsquoApplication Server fourni par TTN
[wwwthethingsnetworkorg]
TTN est gratuit et Open Source En revanche le fait drsquoutiliser TTN impose agrave ceux qui enregistrent
des Gateways de les mettre agrave disposition agrave tous les autres utilisateurs de TTN Lrsquoobjectif est de
reacutealiser un reacuteseau global ouvert
522 Configuration de la Gateway A lrsquouniversiteacute nous avons deux Gateways LoRa (Marque EBDS) Elles sont toutes les deux situeacutees sur
le Campus de Technolac Une Gateway est agrave lrsquointeacuterieur du bacirctiment ISERAN et sert essentiellement
pour les Travaux Pratiques et formations Lrsquoautre est sur le toit du bacirctiment Chablais et est mise agrave
disposition du public via le service de TTN
Les deux Gateway eacutecoutent sur tous les canaux et sur tous les Spreading Factor SF7 gt SF12
Lrsquo IP de la Gateway LoRa agrave lrsquouniversiteacute (bacirctiment ISERAN) est 192168140196
Serveur DNS 1934812032 19348129137
Network Server (TTN) 137616868 routereuthethingsnetwork
Port Upstream 1700 Port Downstream 1700
523 Enregistrement des Gateways Appplication et Devices La configuration de TTN se fait en ligne La premiegravere opeacuteration agrave reacutealiser lorsqursquoune nouvelle
Gateway est deacuteployeacutee crsquoest de lrsquoenregistrer dans TTN
Enregistrement drsquoune Gateway LoRa TTN gt Console gt Gateway gt register gateway
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Figure 38 Scheacutema de notre application
| 40
Figure 39 Enregistrement dune Gateway LoRa sur TTN
Enregistrement drsquoune application TTN gt Console gt Application gt add application
Figure 40 Enregistrement dune application sur TTN
Enregistrement des Devices LoRa dans lrsquoapplication Nom de lrsquoapplication gt register device
Figure 41 Enregistrement des Devices LoRa dans une application
524 Configuration des Devices LoRa Lorsque nous avons enregistreacute des Devices LoRa dans TTN nous devons choisir entre les deux modes
drsquoauthentification Dans un premier temps nous utiliserons le mode le plus simple qui est ABP Nous
geacuteneacuterons dans TTN les DevAddr NetwkSKey et AppSKey
| 41
Figure 42 Configuration des Devices LoRa en ABP dans TTN
53 Mise en application Nous avons dans notre application 10 Devices LoRa drsquoenregistreacutes aduino0 agrave arduino9 Ils sont tous
configureacutes en ABP Les configurations des 10 Devices (DevAddr NetwkSKey et AppSKey) sont noteacutes
en commentaire dans le code de vous allez reacutecupeacuterer
Reacutecupeacuterer le code Arduino laquo RN2483-Arduino-LORAWANino raquo dans Moodle
Modifier votre configuration (DevAddr NetwkSKey et AppSKey) en fonction de votre
numeacutero de binocircme
Veacuterifier que votre Device LoRa arrive bien agrave transmettre des informations (Uplink) vers la
Gateway puis vers le Network Serveur de TTN (The Things Network)
54 Analyse des trames eacutechangeacutees
541 Utilisation de la base 64 Notre Gateway nous preacutesente le Payload PHY en base64 Lrsquoexplication de la meacutethode de
repreacutesentation en base 64 est fourni au travers drsquoun exemple Le code hexadeacutecimal 0x4869
repreacutesente nos donneacutees binaires que nous souhaitons transmettre en base 64
1 On eacutecrit les donneacutees agrave transmettre en binaire
2 On regroupe les eacuteleacutements binaires par des blocs de 6 bits Le nombre de bloc de 6 bits doit
ecirctre un multiple de 4 (minimum 4 blocs) Srsquoil manque des bits pour constituer un groupe de
6 bits on rajoute des zeacuteros
0x4869 = 0100 1000 0110 1001
| 42
3 Srsquoil manque des blocs pour faire un minimum de 4 blocs des caractegraveres speacuteciaux seront
ajouteacutes
4 Chaque groupe de 6 bits est traduit par le tableau suivant (Source Wikipeacutedia)
Figure 43 Codage en base 64
5 Si un bloc de 6 bits manque (ils doivent ecirctre un multiple de 4) on rajoute un ou plusieurs
compleacutements (caractegravere laquo = raquo )
Reacutesultat Le codage de 0x4869 en base 64 est laquo SGk= raquo
010010 000110 100100
On ajoute 00 pour avoir
6 bits dans le groupe
Bloc de 6 bits
010010 000110 100100
S G k
010010 000110 100100
S G k =
1er Bloc
2egraveme Bloc
3egraveme Bloc
4egraveme Bloc
| 43
542 Inteacuterecirct et inconveacutenient de la base 64 Lrsquoutilisation de la base 64 est un choix qui a eacuteteacute fait pour le protocole LoRa LoRaWAN afin de rendre
les donneacutees binaires lisibles Le problegraveme du code ASCII crsquoest qursquoil est composeacute drsquoun certain nombre
de caractegraveres non imprimables (EOF CR LFhellip) Pour eacuteviter ces soucis la base 64 ne comporte que
64 caractegraveres imprimables (voir tableau ci-dessus)
La restriction agrave 64 caractegraveres a cependant un inconveacutenient crsquoest que nous ne pouvons coder que 6
bits (26=64) au lieu de 8 La base 64 est donc moins efficace drsquoune faccedilon geacuteneacuterale
Nous cherchons agrave coder le code ASCII laquo AA raquo en base 64 Retrouver la deacutemarche en
montrant que le reacutesultat en base 64 est laquo QUE= raquo
543 Uplink Du Device LoRa au Network Server Le Network Server de TTN reccediloit des trames IP en provenance de la Gateway Comme nous lrsquoavons
vu preacuteceacutedemment un certain nombre drsquoinformations peuvent ecirctre retrouveacutees avec cette trame
(DevAddr SF Bandwidth etchellip) mais les donneacutees Applicatives sont bien sucircr chiffreacutees (avec
lrsquoAppkSKey) A ce niveau de reacuteception (sans connaitre lrsquoAppSKey) il nrsquoest donc pas possible de
comprendre la totaliteacute du message reccedilu
Imaginons que la trame IP reccedilue 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 45
timestamp 2019-03-05T140042448Z
rssi -82
snr 9
dev_addr 26011AD3
frequency 867300000
Le Network Server affiche donc les informations de la faccedilon suivante
Figure 44 Trame reacutecupeacutereacutee sur le laquo Network Server raquo de TTN
Nous retrouvons bien les valeurs fournies par la Gateway
timestamp ( agrave 1 heure pregraves en fonction du fuseau horaire)
| 44
frequency 8673 Mhz
modulation Lora
Coding Rate 45
data Rate SF 7 125 kHz (DR5)
air time 463 ms
Drsquoautres information proviennent de lrsquoanalyse du Payload Le Payload inscrit ici est le PHY Payload
Il y a donc une partie chiffreacutee (Frame Payload) mais les entecirctes sont en claires (voir paragraphe
441) Ce PHY Payload est laquo QNMaASYABwAP1obuUHQ= raquo Lorsque celui-ci est exprimeacute en
hexadeacutecimal au lieu de la base 64 il vaut laquo 40D31A01260007000FD686EE5074 raquo comme le montre
le Network Server de TTN
Figure 45 PHY Payload preacutesenteacute dans notre Network Server
Sa taille est bien de 14 octets (en hexadeacutecimal) comme preacuteciseacute sur la Figure 44
Nous reprenons le format de la trame LoRaWAN vu agrave la Figure 32 Nous pouvons alors retrouver
tous les champs de toute la trame
PHYPayload = 40D31A01260007000FD686EE5074
PHYPayload = MAC Header[1 octet] | MACPayload[] | MIC[4 octets]
MAC Header = 40 (Unconfirmed data up)
MACPayload = D31A01260007000FD6
Message Integrity Code = 86EE5074
MACPayload = Frame Header | Frame Port | FramePayload )
Frame Header = D31A0126000700
FPort = 0F
FramePayload = D6
Frame Header = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[015]
DevAddr = 26011AD3 (Big Endian)
FCtrl (Frame Control) = 00 (No ACK No ADR)
FCnt (Frame Counter) = 0007 (Big Endian)
FOpts (Frame Option) =
Vous pouvez veacuterifier lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN
(LoRaWAN packet decoder) httpsbitly2szdXtv
| 45
Figure 46 LoRaWAN packet decoder
544 Uplink Du Network Server agrave lrsquoApplication Server
Nous reprenons lrsquoexemple de la trame ci-dessus (Figure 45) Pour information les cleacutes NwkSKey et
AppSKey suivantes ont eacuteteacute utiliseacutee
NwkSKey E3D90AFBC36AD479552EFEA2CDA937B9
AppSKey F0BC25E9E554B9646F208E1A8E3C7B24
Le Network Server a deacutecodeacute lrsquoensemble de la trame Si le MIC est correct (authentification de la
trame par le NwkSKey) alors le Network Server va passer le contenu du message chiffreacute (Frame
Payload) agrave lrsquoApplication Server Dans notre cas le Frame Payload est (drsquoapregraves le deacutecodage effectueacute
au chapitre preacuteceacutedent)
FramePayload = D6
D6 est le contenu chiffreacute lorsqursquoil est deacutechiffreacute avec lrsquoAppSkey on trouve 01 Vous pouvez veacuterifier
lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN httpsbitly2szdXtv
A noter que lrsquoApplication Server recevra les donneacutees chiffreacutees seulement si le Device LoRa a bien
eacuteteacute enregistreacute On peut aussi veacuterifier ci-dessous que lrsquoApplication Serveur de TTN nous retourne bien
un payload (Frame Payload) de 01
Figure 47 Trame reacutecupeacutereacutee sur lrsquoApplication Server de TTN
time 2019-03-05T140042379279991Z
frequency 8673
modulation LORA
data_rate SF7BW125
coding_rate 45
gateways [
gtw_id eui-b827ebfffeae26f6
timestamp 2447508531
time
channel 4
rssi -82
snr 9
latitude 4563647
longitude 58721523
| 46
location_source registry
]
545 Simulation drsquoUplink dans lrsquoApplication Server
Dans beaucoup de situations nous souhaitons valider le fonctionnement de lrsquoApplication Server de
TTN ouet de notre propre Application Il est donc tregraves utile de pouvoir simuler lrsquoenvoi drsquoune trame
LoRa sur lrsquoApplication Server sans que celle-ci soit reacuteellement eacutemise par un Device LoRa Pour cela
un outil existe dans les Settings de chaque Device enregistreacute dans TTN Nous avons juste besoin de
speacutecifier le Frame Payload en clair en hexadeacutecimal et le numeacutero de Port
Figure 48 Simulation drsquoune trame envoyeacutee par un Device LoRa
546 Downlink De lrsquoApplication Server au Device LoRa La communication LoRa est bidirectionnelle Des donneacutees peuvent ecirctre transmis au Device LoRa
depuis lrsquoApplication Server Depuis TTN un outil existe dans les Settings de chaque Device
enregistreacute Lrsquointerface est repreacutesenteacutee ci-dessous
Figure 49 Transmission de donneacutees de lrsquo laquo Application Server raquo jusqursquoau Device LoRa
Replace scheduling Mode Par deacutefaut le Frame Payload transmis remplacera le Frame
Payload en attente (si il existe) Dans ce mode un seul Frame Payload est planifieacute
First scheduling Mode Le Frame Payload est mis en file drsquoattente en premiegravere position
Last scheduling Mode Le Payload est mis en file drsquoattente en derniegravere position
Une demande de confirmation peut ecirctre demandeacutee au Device LoRa pour qursquoil preacutecise srsquoil a bien reccedilu
les donneacutees Lrsquooption laquo confirmed raquo permet donc de speacutecifier le type de trame dans le MAC Header
(voir paragraphe 443) laquo Confirmed Data Down raquo ou laquo Unconfirmed Data Down raquo dans notre cas
| 47
6 La reacutecupeacuteration des donneacutees sur notre propre Application
Nous utiliserons agrave nouveau le Network Server et Application Server de The Things Network Jusqursquoici
nous nous sommes contenteacute de veacuterifier que les donneacutees de lrsquoutilisateur (Frame Payload) soient bien
arriveacutees agrave destination dans lrsquoApplication Server Il faut maintenant les reacutecupeacuterer avec notre propre
Application qui aura pour rocircle
De stocker et traiter les donneacutees
De les mettre agrave disposition de lrsquoutilisateur (Serveur Web par exemple)
Drsquoenvoyer des commandes de lrsquoutilisateur aux Devices LoRa si besoin (Flux Downlink)
Nous allons voir deux meacutethodes pour communiquer entre notre application et TTN
Le protocole HTTP POST
Le protocole MQTT
61 Reacutecupeacuteration des donneacutees en HTTP POST dans lrsquoApplication
611 Preacutesentation du protocole HTTP
Dans le monde de lrsquointernet le protocole HTTP est tregraves utiliseacute pour le dialogue entre un client et un
serveur web Classiquement le client (un navigateur web par exemple) fait une requecircte HTTP GET
et le serveur lui retourne le contenu de la page web demandeacutee
Dans notre cas la probleacutematique est diffeacuterente car le client doit modifier le contenu du serveur
avec les donneacutees envoyeacutees par le Device LORA La requecircte srsquoappelle HTTP POST Son nom indique
que le client va poster (et on pas reacutecupeacuterer) des donneacutees
Lrsquoutilisateur qui souhaite reacuteceptionner des donneacutees sur son serveur doit donc concevoir un serveur
HTTP capable de traiter des requecirctes HTTP POST [ requecircte noteacutee (1) sur la Figure 51 ] fournies par
TTN Dans cette configuration TTN jouera le rocircle de client et notre application le rocircle de serveur
Devices
LORA Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
HTTP POST
MQTT Internet
Figure 50 Structure globale drsquoun reacuteseau LORAWAN
| 48
Figure 51 Communication bidirectionnelle entre TTN et notre Application
A lrsquoinverse lrsquoutilisateur qui souhaite transmettre des donneacutees agrave destination du Device LoRa
(Downlink) doit ecirctre capable de fournir une requecircte HTTP POST [ requecircte noteacutee (2) sur la Figure 51
] vers TTN Dans cette configuration TTN jouera le rocircle de Serveur et notre application le rocircle de
client
612 Fonctionnement drsquoun client et drsquoun serveur HTTP POST Afin de bien comprendre le fonctionnement des requecirctes HTTP POST nous allons proceacuteder par
eacutetape Le premier test que nous effectuerons sera decorreacuteleacute de TTN Le principe est le suivant
Utilisation drsquoun serveur HTTP disponible sur le web geacuterant les requecirctes HTTP POST [
httpsrbasketsin ] ou [ httpsbeeceptorcom ] par exemple
Utilisation drsquoun client HTTP eacutemettant des requecirctes HTTP POST commande curl sous linux
ou logiciel Postman [ wwwgetpostmancom ] sous windows par exemple
Ce test nous permet de valider le fonctionnement drsquoun serveur HTTP POST et drsquoun client HTTP POST
Une fois que nous serons sucircr de leur fonctionnement nous les utiliserons avec TTN
The Things Network
Application
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 49
Figure 52 Validation dun server HTTP POST et drsquoun client HTTP POST
613 Test du serveur HTTP POST Nous utiliserons un serveur web proposeacute par httpsrbasketsin
Aller sur le site httpsrbasketsin et creacuteer un nouveau laquo Basket raquo Zone ougrave vous pourrez
visualiser les requecirctes qui ont eacuteteacute eacutemises vers votre serveur
A partir de maintenant toutes les requecirctes dirigeacutees vers lrsquoadresse creacuteeacute seront traiteacutees et
srsquoafficheront Dans le menu de configuration il est aussi possible de deacutefinir le contenu de la reacuteponse
qui sera fournie
Deacutefinir un format de reacuteponse pour les requecirctes HTTP POST avec un body personnaliseacute
614 Test du client HTTP POST On peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande (la commande cURL
srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN sous Windows
Commande cURL curl ndashX POST ndashd lsquorsquodonneacutees agrave envoyerrsquorsquo DuServeurHTTP
Logiciel Postman New gt Request gt Creacuteer une requecircte HTTP POST gt Send
Veacuterifier que les requecirctes HTTP POST sont bien reacutecupeacutereacutees sur votre serveur creacutee preacuteceacutedemment
615 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST
Maintenant que nous avons un serveur HTTP (POST) fonctionnel nous allons configurer TTN pour
jouer le rocircle du client et pour qursquoil envoie des requecirctes HTTP POST vers notre Serveur degraves qursquoune
donneacutee drsquoun Device LoRa est disponible Nous geacuterons donc ici le flux Uplink
Requecircte
HTTP POST
Reacuteponse
(contenu parameacutetrable)
Client HTTP (POST)
Server HTTP (POST) [ httpsrbasketsin ]
| 50
Figure 53 Reacutecupeacuteration des donneacutees sur notre Application
Dans TTN nous inteacutegrons un bloc appeleacute laquo HTTP Integration raquo permettant de jouer le rocircle de client
crsquoest-agrave-dire drsquoenvoyer des requecirctes HTTP POST agrave destination de notre nouveau Serveur HTTP
Lrsquointeacutegration se faire agrave partir de TTN gt Console gt Application gt Nom_de_votre_application gt
Integration
Figure 54 Ajout dun client HTTP POST dans TTN
Pour valider le fonctionnement de notre architecture nous pouvons soit
Envoyer une trame depuis un Device LoRa vers TTN
Simuler lrsquoenvoi drsquoune trame drsquoun Device LoRa vers TTN (gracircce agrave lrsquooutil proposeacute par TTN vu
paragraphe 545)
Dans les deux cas voici un exemple de requecircte POST reccedilue sur notre serveur HTTP
app_id test_app_lorawan_sylvainmontagny
dev_id stm32lorawan_1
hardware_serial 0056AF49877
port 1
counter 0
payload_raw qg==
metadata
Requecircte
HTTP POST
Server HTTP (POST) [ httpsrbasketsin ]
The Things Network (Client)
La requecircte contient le Frame Payload deacutechiffreacutee
agrave transmettre agrave lrsquoApplication
| 51
time 2019-01-24T15243703499298Z
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Comme nous pouvons le voir le contenu fourni agrave notre serveur est formateacute en JSON (voir
paragraphe 0) Voici quelques compleacutements drsquoinformation
payload_raw Frame Payload deacutechiffreacute crsquoest donc les donneacutees en clairs dans la base 64
downlink_url URL du serveur HTTP POST qui serviront agrave transmettre des donneacutees au Device
LoRa (flux Downlink)
611 Envoyer des donneacutees depuis notre Application avec HTTP POST
Lorsque nous avons ajouteacute le bloc laquo HTTP Integration raquo au paragraphe preacuteceacutedent nous avons aussi
implicitement activeacute la fonctionnaliteacute que TTN soit precirct agrave recevoir et agrave traiter les requecirctes HTTP
POST La seule information qursquoil nous manque est lrsquoadresse du server HTTP vers lequel il faut eacutemettre
les requecirctes Si on observe la trame reccedilue preacuteceacutedemment en provenance de TTN on srsquoaperccediloit que
dans la trame JSON reccedilu une URL (downlink_url) est speacutecifieacutee
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Crsquoest cette URL que nous devrons utiliser Nous allons nous placer dans la configuration suivante
Figure 55 Envoi de donneacutees agrave partir de notre Application
Comme preacuteceacutedemment on peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande
(la commande cURL srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN
Commande cURL curl ndashX POST ndashdata lsquo dev_id Identidiant_De_Votre_Device
payload_raw AQE= rsquo DuServeurHTTP
Logiciel Postman New gt Request gt HTTP POST puis Body gt Raw gt JSON
Requecircte HTTP POST vers serveur TTN laquo downlink_url raquo httpsintegrationsthethingsnetworUaeb8ypKieQ
Contenu de la requecircte
dev_id Identidiant_De_Votre_Device
payload_raw aGVsbG8=
The Things Network (Serveur)
POSTMAN (Client HTTP POST)
| 52
dev_id YourDeviceID
payload_raw aGVsbG8=
Vous devez envoyer le texte (payload_raw) en base 64 Dans lrsquoexemple ci-dessus laquo aGVsbG8= raquo
correspond agrave la chaine de caractegravere laquo hello raquo Vous pouvez utiliser les nombreux encodeurdecodeur
en ligne pour vous aider Le texte doit srsquoafficher sur votre moniteur seacuterie Arduino dans le cadre de
notre deacutemonstrateur sur Arduino
62 Reacutecupeacuteration des donneacutees avec MQTT dans lrsquoApplication
621 Preacutesentation du protocole MQTT
MQTT est un protocole leacuteger qui permet de srsquoabonner agrave des flux de donneacutees Plutocirct que
lrsquoarchitecture Client Serveur classique qui fonctionne avec des Requecirctes Reacuteponses MQTT est
baseacute sur un modegravele Publisher Subscriber La diffeacuterence est importante car cela eacutevite davoir agrave
demander (Requecircte) des donneacutees dont on na aucune ideacutee du moment ougrave elles vont arriver Une
donneacutee sera donc directement transmise au Subscriber degraves lors que celle-ci a eacuteteacute reccedilue dans le
Broker (serveur central)
Figure 56 Modegravele Publisher Subscriber du protocole MQTT
Pour recevoir les donneacutees appartenant agrave un Topic un Subscriber doit souscrire (comme son nom
lindique) au preacutealable sur ce Topic
MQTT est un protocole qui repose sur TCP Lencapsulation des trames sur le reacuteseau est donc la
suivante
Broker
Client
Publisher 1
Client
Publisher 2
Client
Subscriber
Topic
Tempeacuterature
Topic
Humiditeacute
| 53
Figure 57 Protocoles utiliseacutes pour la communication avec MQTT
On peut le veacuterifier par une capture de trame sur Wireshark
Figure 58 Capture dune trame MQTT avec Wireshark
On peut noter que le port TCP utiliseacute pour le protocole MQTT (non chiffreacute) est le 1883
Les Publishers et les Subscribers nrsquoont pas besoin de se connaitre
Les Publishers et les Subscribers ne sont pas obligeacute de srsquoexeacutecuter en mecircme temps
622 Connexion au Broker MQTT Nous nous inteacuteresserons essentiellement aux options de connexion qui permettront de geacuterer la
Qualiteacute de Service (QoS) Pour se connecter un client MQTT envoie deux informations importantes
au Broker
keepAlive Cest la peacuteriode la plus longue pendant laquelle le client Publisher ou Subscriber pourra
rester silencieux Au-delagrave il sera consideacutereacute comme deacuteconnecteacute
cleanSession Lorsque le Client et le Broker sont momentaneacutement deacuteconnecteacutes (au-delagrave du
keepAlive annonceacute) on peut donc se poser la question de savoir ce quil se passera lorsque le client
sera agrave nouveau connecteacute
Si la connexion eacutetait non persistante (cleanSession = True) alors les messages non transmis
sont perdus Quel que soit le niveau de QoS (Quality of Service)
Si la connexion eacutetait persistante (cleanSession = False) alors les messages non transmis
seront eacuteventuellement reacuteeacutemis en fonction du niveau de QoS Voir le chapitre 624
623 Qualiteacute de Service au cours dune mecircme connexion
A partir du moment ougrave le Client se connecte au Broker il est possible de choisir un niveau de fiabiliteacute
des transactions Le Publisher fiabilise leacutemission de ces messages vers le Broker et le Subscriber
fiabilise la reacuteception des messages en provenance du Broker Une parle ici du cas dune mecircme
connexion crsquoest-agrave-dire entre le moment ou le Client se connecte et le moment ougrave
Soit il se deacuteconnecte explicitement (Close connexion)
Soit il na rien eacutemis ni fait signe de vie pendant le temps keepAlive
TCP
MQTT
Reacuteseau
Transport
Couche Application
IP
| 54
Lors dune mecircme connexion la Qualiteacute de Service (QoS) qui est mise en œuvre deacutepend uniquement
de la valeur du QoS selon les valeurs suivantes
QoS 0 At most once (au plus une fois) Le premier niveau de qualiteacute est sans acquittement Le
Publisher envoie un message une seule fois au Broker et le Broker ne transmet ce message quune
seule fois aux Subscribers Ce meacutecanise ne garantit pas la bonne reacuteception des messages MQTT
QoS 1 At least once (au moins une fois) Le deuxiegraveme niveau de qualiteacute est avec acquittement
Le Publisher envoie un message au Broker et attends sa confirmation De la mecircme faccedilon le Broker
envoie un message agrave ces Subscriber et attends leurs confirmations Ce meacutecanisme garantit la
reacuteception des message MQTT
Cependant si les acquittements nrsquoarrivent pas en temps voulu ou srsquoils se perdent la reacuteeacutemission du
message dorigine peut engendrer une duplication du message Il peut donc ecirctre reccedilu plusieurs fois
QoS 2 Exactly once (exactement une fois) Le troisiegraveme niveau de qualiteacute est garanti une seule
fois Le Publisher envoie un message au Broker et attends sa confirmation Le Publisher donne alors
lrsquoordre de diffuser le message et attends une confirmation Ce meacutecanisme garantit que quel que
soit le nombre de tentatives de reacuteemission le message ne sera deacutelivreacute quune seule fois
La Figure 59 montre les trames eacutemises pour chaque niveau de QoS
Figure 59 Qualiteacute de Service en MQTT
La Figure 60 repreacutesentes les 3 captures de trames sur Wireshark repreacutesentant les 3 QoS (1 2 et 3)
que nous venons dexpliquer
Broker
QoS 0
Au plus une fois
Message supprimeacute apregraves envoi
PUBLISH
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Duplications possibles
PUBLISH
PUBLICH Ack
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Pas de duplication
PUBLISH
PUBLISH Receive
PUBLISH Release
PUBLISH Complete
| 55
Figure 60 Capture de trame avec QoS = 0 puis QoS = 1 puis QoS = 2
624 Qualiteacute de Service apregraves une reconnexion
La question que nous nous posons et de savoir ce que deviennent les messages publieacutes sur le Broker
lorsquun ou plusieurs Subscribers sont momentaneacutement injoignables Il est possible de conserver
les messages qui ont eacuteteacute publieacutes sur le Broker afin de les retransmettre lors de la prochaine
connexion Cette possibiliteacute de sauvegarde doit ecirctre activeacutee agrave louverture de connexion gracircce au flag
cleanSession = 0 La connexion sera alors persistante crsquoest-agrave-dire que le Broker enregistre tous les
messages quil na pas reacuteussi agrave diffuser au Subscriber
Le Tableau 9 reacutesume leffet du flag cleanSession et du QoS
Clean Session Flag Subscriber QoS Publisher QoS Comportement True ( = 1) 0 1 2 0 1 2 Messages perdus
False ( = 0 ) 0 0 1 2 Messages perdus
False (= 0 ) 0 1 2 0 Messages perdus
False (= 0 ) 1 2 1 2 Tous les messages sont retransmis
Tableau 9 Qualiteacute de Service en fonction de la valeur du QoS et du flag cleanSession
625 Les Topics du protocole MQTT Les chaicircnes deacutecrivant un sujet forment une arborescence en utilisant la barre oblique comme
caractegravere de seacuteparation La Figure 61 et le Tableau 10 donne un exemple dorganisation de Topic
Figure 61 Exemple de hieacuterarchie de Topic MQTT
Niveau 3
Niveau 2
Niveau 1 Maison
Chambre
Temperature Humidite Bruit
Salon
Temperature
| 56
Nom du Topic Deacutetail du Topic MaisonChambreTemperature La tempeacuterature de la chambre de la maison
MaisonChambreBruit Le bruit de la chambre de la maison
MaisonSalonTemperature La tempeacuterature du Salon de la maison
Tableau 10 Exemple de Topic
Un client peut sabonner (ou se deacutesabonner) agrave plusieurs branches de larborescence agrave laide de
jokers englobant plusieurs Topics Deux caractegraveres jokers existent
Le signe plus + remplace nimporte quelle chaine de caractegravere sur le niveau ougrave il est placeacute
Le diegravese remplace nimporte quelle chaine de caractegravere sur tous les niveaux suivants Il
est obligatoirement placeacute agrave la fin
Nom du Topic Deacutetail du Topic Maison+Temperature Les tempeacuteratures de toutes les piegraveces de la maison
MaisonChambre La tempeacuterature lhumiditeacute et le bruit de la chambre de la maison
Tableau 11 Exemple de Topic
626 Mise en place drsquoun Broker MQTT Afin de bien comprendre le fonctionnement du protocole de MQTT on reacutealise des tests
indeacutependamment de TTN Nous allons mettre en place
Un Broker Mosquitto httpstestmosquittoorg
Un client Publisher MQTT Box sur Windows
Un client Subscriber MQTT Box sur Windows
Figure 62 Test du protocole MQTT
MQTT Client (Subscriber)
MQTT Client (Publisher)
Publish
Subscribe
BROKER (Mosquitto)
| 57
Le Broker MQTT est commun agrave tout le monde Nous pouvons soit le reacutealiser nous-mecircme soit utiliser
un Broker MQTT public de test Nous utiliserons le Broker de test de Mosquitto disponible sur
httpstestmosquittoorg Drsquoautres sont eacuteventuellement disponibles en cas de problegraveme par
exemple httpwwwmqtt-dashboardcom
Si nous deacutecidions de le reacutealiser nous-mecircme agrave lrsquoaide drsquoune Raspberry Pi (par exemple) Lrsquoinstallation
se ferait en deux lignes de commande
apt-get install mosquito Installation
sudo systemctl start mosquittoservice Lancement du service
Il est neacutecessaire drsquoinstaller mosquitto-clients si on souhaite que le Raspberry PI joue aussi le rocircle de
client ce qui nrsquoest pas notre cas
627 Mise en place drsquoun Publisher et drsquoun Subscriber MQTT Lancer le logiciel MQTTBox
MQTTBox gt Create MQTT Client
Dans ce client les seuls champs indispensables sont
Protocol MQTT TCP
Host testmosquittoorg
Figure 63 Configuration dun Client MQTT dans MQTT Box
Tester lrsquoenvoi et la reacuteception sur les Topics de votre choix
628 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT La reacutecupeacuteration des donneacutees fait reacutefeacuterence au flux Uplink Dans ce cas
TTN joue le rocircle de client Publisher
TTN joue aussi le rocircle de Broker
Notre application joue le rocircle de Subscriber
Nous pouvons donc repreacutesenter lrsquoapplication globale par le scheacutema suivant
| 58
Figure 64 Publisher et Subscriber dans en MQTT avec TTN
La publication est repreacutesenteacutee par la trame MQTT (1)
La souscription est repreacutesenteacutee par la trame MQTT (2)
Le client Publisher eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box mais cette fois avec la configuration suivante
Protocol mqtt tcp
Host Crsquoest lrsquoIP du Broker vers lequel il faut se connecter Dans notre cas il srsquoagit de celui
de TTN dont lrsquoadresse est euthethingsnetwork
Username La connexion vers le broker MQTT est soumis agrave une authentification Username
Password Dans notre cas le Username correspond au nom de notre application crsquoest-agrave-
dire seminaire_lorawan Si vous avez choisi une autre applicationil faut bien mettre la
votre
Password Le Password est nommeacute laquo Access Key raquo par TTN Elle vous sera donneacutee par
lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application vous
trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt Overview
Figure 65 Access Keys de lapplication dans TTN
The Things Network (Application Server)
BROKER
Application
The Things Network (Network Server)
Publish (1 )
[ Flux Uplink ]
Subscribe (2 )
[ Flux Uplink ]
| 59
Figure 66 Configuration du Client dans MQTT Box
Le client MQTT eacutetant configureacute il est maintenant capable de se connecter au Broker Il reste donc agrave
deacutefinir le fait que le client sera Subscriber Les informations que recevra le Subscriber deacutependent du
Topic auquel nous souscrivons Voici les Topic disponibles sur le Broker de TTN
ltAppIDgt correspond au nom de votre Application
ltDevIDgt correspond au nom de votre Device LoRa
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink ltAppIDgtdevicesltDevIDgtup
[Donneacutees] Flux Downlink ltAppIDgtdevicesltDevIDgtdown
[Activation Events] Activation dun Device ltAppIDgtdevicesltDevIDgteventsactivations
[Management Events] Creacuteation dun Device ltAppIDgtdevicesltDevIDgteventscreate
[Management Events] Update dun Device ltAppIDgtdevicesltDevIDgteventsupdate
[Management Events] Suppression dun Device ltAppIDgtdevicesltDevIDgteventsdelete
[Downlink Events ] Message programmeacute ltAppIDgtdevicesltDevIDgteventsdownscheduled
[Downlink Events ] Message envoyeacute ltAppIDgtdevicesltDevIDgteventsdownsent
[Erreurs] Uplink erreurs ltAppIDgtdevicesltDevIDgteventsuperrors
[Erreurs] Downlink erreurs ltAppIDgtdevicesltDevIDgteventsdownerrors
[Erreurs] Activations erreurs ltAppIDgtdevicesltDevIDgteventsactivationserrors
Tableau 12 Topics enregistreacutes dans TTN
Dans un premier temps nous souscrivons au Topic +devices+up Cela signifie que nous
souscrivons agrave tous les Devices LoRa de toutes nos applications pour le flux Uplink
Figure 67 Configuration du Subscriber
Les eacuteleacutements eacutemis par le Broker seront alors afficheacutes dans MQTTBox La
| 60
Figure 68 Trame LoRaWAN reccedilu sur le Subscriber MQTT
Ces donneacutees sont eacutecrites en JSON nous pouvons les remettre en forme
applicationID3
applicationNamemyApplication
deviceNamearduino0
devEUI0056xxxxxxxxx877
txInfo
frequency868500000
dr5
adrfalse
fCnt792
fPort15
dataSGVsbG8=
Le Frame Payload deacutechiffreacute est fourni dans le champ data en base 64 La valeur fournie par
dataSGVsbG8= correspond bien agrave la chaine de caractegravere hello que nous avons eacutemise avec le
Device LoRa
629 Envoyer des donneacutees depuis notre Application avec MQTT
Lrsquoenvoi des donneacutees fait reacutefeacuterence au flux Downlink Dans ce cas
Notre application joue le rocircle de Publisher
TTN joue le rocircle de Broker
TTN joue aussi le rocircle de client Subscriber
| 61
La publication est repreacutesenteacutee par la trame MQTT (3)
La souscription est repreacutesenteacutee par la trame MQTT (4)
Le client Subscriber eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box Le rocircle de client dans MQTT Box a eacuteteacute faite au
paragraphe 628 Il nous reste simplement agrave ajouter le rocircle de Publisher La configuration est la
suivante
Topic du Subscriber seminaire_lorawandevicesarduino0down ougrave seminaire_lorawan
est agrave remplacer par le nom de votre application et arduino0 par le nom du Device LoRa vers
lequel vous souhaitez envoyeacute une donneacutee (Voir chapitre 628 pour comprendre les Topics)
Le Payload doit ecirctre au format JSON Lrsquoexemple suivant envoie laquohello raquo
payload_raw aGVsbG8=
The Things Network (Application Server)
BROKER
Application
Publish (3)
[ Flux Downlink ]
The Things Network (Network Server)
Subscribe (4)
[ Flux Downlink ]
| 62
Figure 69 Configuration du Publisher
Vous devriez voir les donneacutees arriver sur votre Device LoRA
| 63
7 Creacuteation de notre propre Network et Application Server
711 Objectifs Lors de la mise en œuvre du reacuteseau LoRaWAN au chapitre 52 nous avons utiliseacute TTN (The Things
Network) pour jouer le rocircle de Network Server et drsquoApplication Server Pour de multiples raisons
Seacutecuriteacute autonomie coucircthellipil peut ecirctre inteacuteressant de monter soi-mecircme un Network Server et un
Application Server Cela est possible seulement si vous posseacutedez vos propres Gateway puisque
celles-ci devront forwarder leur paquet agrave destination preacutecise Il faudra donc les reconfigurer pour
qursquoelles pointent vers votre nouvelle architecture
712 Preacutesentation de LoRaServer LoRaServer [ wwwloraserverio ] est un projet Open-Source reacutepondant exactement au besoin que
nous avons Nous lrsquoutiliserons sur une cible Raspberry PI En reacutealiteacute il peut souvent ecirctre mise en
place dans le mecircme systegraveme que la Gateway surtout si celle-ci est elle-mecircme agrave base de RPI Les
Gateway EBDS que nous posseacutedons possegravedent drsquoailleurs un Network Server et un Application Server
que nous aurions pu utiliser Neacuteanmoins pour des raisons peacutedagogiques il est inteacuteressant de
seacuteparer les systegravemes pour bien diffeacuterencier les probleacutematiques
Attention il y a une ambiguiumlteacute dans la deacutenomination des entiteacutes logiciels de LoRaServer
LoRaServer (sans espace entre le mot LoRa et Server) est le nom du projet global En
revanche LoRa Server (avec un espace) est le nom du service qui joue le rocircle du Network
Server
Lrsquoarchitecture et le fonctionnement de LoRaServer est preacutesenteacutee dans sa documentation par le
scheacutema suivant
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Raspberry PI
Figure 70 Architecture globale de notre reacuteseau loRaWAN
| 64
Figure 71 Architecture deacutetailleacutee de LoRaServer
On srsquoattends agrave voir uniquement un Network Server (LoRa Server) et un Application Server (LoRa App
Server) mais ce scheacutema est plus complexe Il demande un certain nombre drsquoexplications pour bien
comprendre ce que nous allons installer et la faccedilon dont nous lrsquoutiliserons par la suite
713 Le laquo Packet Forwarder raquo (Gateway) Comme nous lrsquoavons vu au chapitre 412 les Gateways LoRa sont des passerelles entre la
modulation LoRa et un reacuteseau IP Pour reacutealiser cette passerelle un service nommeacute laquo UDP Packet
Forwarder raquo a eacuteteacute deacuteveloppeacute par Semtech httpsgithubcomLora-netpacket_forwarder Dans
ce dossier github un fichier nommeacute PROTOCOLTXT explique parfaitement ce protocole applicatif
qui travaille au-dessus de UDP
Figure 72 Protocole Uplink (PUSH_DATA du Packet Forwarder)
| 65
On remarque que les paquets sont envoyeacutes en UDP au Network Server dans une trame appeleacutee
PUSH_DATA Cette trame est acquitteacutee par le Network Server par une trame appeleacutee PUSH_ACK
Sur notre Network Server nous pouvons reacutealiser une capture de trame pour veacuterifier si le protocole
est bien celui preacutesenteacute dans le document
Figure 73 Trame captureacutee par Wireshark lors dun Uplink
Drsquoapregraves la capture preacuteceacutedente on remarque que le Packet Forwarder fonctionne bien avec UDP sur
le port 1700
Le contenu des donneacutees (champ Data) est deacutetailleacute dans le tableau suivant
Champ | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | random token
[3] | 3 | PUSH_DATA identifier = 0x00
[4] | 4-11 | Gateway unique identifier (MAC address)
[5] | 12-end | JSON object starting with ending with
Lrsquoobjet JSON de la transmission reacuteeacutecrit plus proprement est celui-ci
Figure 74 Analyse du champ Donneacutees du protocole laquo Packet Forwarder raquo
0000 02 f9 30 00 b8 27 eb ff fe ae 26 f5 7b 22 72 78 0amprx 0010 70 6b 22 3a 5b 7b 22 74 6d 73 74 22 3a 33 37 35 pk[tmst375 0020 35 30 30 35 38 31 39 2c 22 63 68 61 6e 22 3a 32 5005819chan2 0030 2c 22 72 66 63 68 22 3a 31 2c 22 66 72 65 71 22 rfch1freq 0040 3a 38 36 38 2e 35 30 30 30 30 30 2c 22 73 74 61 868500000sta 0050 74 22 3a 31 2c 22 6d 6f 64 75 22 3a 22 4c 4f 52 t1moduLOR 0060 41 22 2c 22 64 61 74 72 22 3a 22 53 46 37 42 57 AdatrSF7BW 0070 31 32 35 22 2c 22 63 6f 64 72 22 3a 22 34 2f 35 125codr45 0080 22 2c 22 6c 73 6e 72 22 3a 36 2e 35 2c 22 72 73 lsnr65rs 0090 73 69 22 3a 2d 31 2c 22 73 69 7a 65 22 3a 31 38 si-1size18 00a0 2c 22 64 61 74 61 22 3a 22 51 4e 4d 61 41 53 59 dataQNMaASY 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 ]
Ch
amp
[1
]
Ch
amp
[2
]
Ch
amp
[3
]
Ch
amp
[4
]
| 66
rxpk[ tmst3755005819
chan2
rfch1
freq868500000
stat1
moduLORA
datrSF7BW125
codr45
lsnr65
rssi-1
size18
dataQNMaASYAAQAPpyPZ955+SmY
]
Le champ data correspond au PHY Payload
De la mecircme faccedilon on retrouve la Trame drsquoacquittement
Figure 75 Trame captureacutee par Wireshark lors de lrsquoacquittement drsquoun Uplink
Champs | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | same token as the PUSH_DATA to acknowledge
[3] | 3 | PUSH_ACK identifier = 0x01
Nous retrouvons bien tous ces champs dans la trame Wireshark
714 LoRa Gateway Bridge Nous avons deacutecrit au chapitre preacuteceacutedent (713) le fonctionnement du Packet Forwarder Le
Network Server(Lora Server) que nous allons mettre en place aurait tregraves bien pu srsquointerfacer
directement agrave ce protocole Mais cela aurait plusieurs impacts dont un qui est important dans la
conception de logiciel Si le Packet Forwarder change ou si un autre type de Forwarder est utiliseacute
alors lrsquoutilisation du LoRa Server devient impossible Il a donc eacuteteacute choisi de creacuteer une eacutetape
intermeacutediaire Le Network Server que nous mettrons en plus utilisera le protocole MQTT plutocirct que
le protocole UDP packet Forwarder
En drsquoautres termes le LoRa Gateway Bridge est un service qui fera abstraction du Packet Forwarder
pour srsquointerfacer plus simplement avec le Network Server
715 LoRa Server (Network Server) Il srsquoagit de notre Network Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
413 Cependant il srsquointerfacera au protocole MQTT en recevant les informations agrave partir du
Broker au lieu de recevoir directement les trames en provenance de la Gateway
| 67
716 LoRa App Server (Application Server) Il srsquogit de notre Application Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
414
717 LoRa Geo Server Il srsquoagit drsquoun service qui permet drsquoutiliser certaines proprieacuteteacutes du protocole LoRa pour proposer un
service de geacuteolocalisation des Devices LoRa Nous ne lrsquoutiliserons pas dans notre cas
718 Application Il srsquoagit de notre Application qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre 415
Elle ne fait pas partie du projet LoRaServer crsquoest donc bien toujours agrave nous de proposer notre propre
Application
Figure 76 Les interfaces possibles entre LoRaServer et lrsquoApplication utilisateur
Comme nous pouvons le voir sur la figure preacuteceacutedente deux possibiliteacutes sont offertes pour interfacer
notre application JSON REST (incluant HTTP POST) et via un Broker MQTT Ces deux meacutethodes ont
deacutejagrave eacuteteacute traiteacutee au chapitre 61 (HTTP POST ) et au chapitre 62 (MQTT) Nous verrons aussi drsquoautres
possibiliteacutes pour personnaliser notre application au chapitre 7
72 Installation de LoRaServer
721 Mise en place de lrsquoenvironnement
Nous allons installer une carte SD avec la derniegravere version de Raspbian Nous ne deacutetaillerons pas la
deacutemarche pour cela car elles sont largement documenteacutees et mises agrave jour sur le site
wwwraspberrypiorg
Installer un carte SD avec la derniegravere version de Raspbian
Plutocirct que de fonctionner avec un clavier et une souris nous preacuteconisons de travailler agrave distance
avec la RPI via une connexion SSH Depuis quelques anneacutees Raspbian a supprimeacute le deacutemarrage du
service SSH au boot Heureusement il est possible de le reacuteactiver par la meacutethode suivante
Avec Windows ou Linux ouvrir la partition BOOT de votre carte SD et placer un fichier agrave la
racine nommeacute sshtxt (ou ssh)
Mettre la carte SD dans votre RPI et la deacutemarrer
| 68
Pour acceacuteder agrave la RPI en SSH depuis Windows nous utiliserons de preacutefeacuterence le logiciel
client MobaXterm mais tout autre client SSH est valable
Installer MobaXterm sur votre PC et connectez-vous agrave votre Raspberry PI
Lrsquoutilisation drsquoun espion de reacuteseau type Wireshark peut ecirctre inteacuteressant pour eacutetudier les trames qui
sont reccedilues et qui sont eacutemises Cela nous permettra de valider le fonctionnement des diffeacuterents
protocoles reacuteseau qui permettent de communiquer agrave la Gateway drsquoune part et agrave lrsquoApplication
drsquoautre part Nous utiliserons tshark
apt-get install tshark installation
tshark ndashn -i eth0 Exemple drsquoune analyse sur lrsquointerface wlan0
722 Installation sur la Raspberry PI La meacutethode drsquoinstallation de LoRaServer est documenteacutee sur le site web agrave lrsquoadresse suivante
[ httpswwwloraserverioguidesdebian-ubuntu ] Nous installerons le LoRa Gateway Bridge
le LoRa Server et le LoRa App Server
Apregraves lrsquoinstallation la configuration se fait par une interface graphique accessible par le reacuteseau sur
le port 8080
Si vous travaillez sur la RPI connectez-vous sur httplocalhost8080
Si vous travaillez agrave distance (SSH) connectez-vous sur httpIP_RPI8080
Les Usernames et Password par deacutefaut sont
Username admin
Password admin
Lrsquoeacutecran drsquoaccueil sera donc le suivant
Figure 77 Architecture globale apregraves installation de LoRaServer
Devices
Gateways LoRa
UDP Packet Forwarder
Application Server
LoRa App Server
Internet
Network Server
LoRa Server
LoRa Gateway Bridge
| 69
Figure 78 Ecran daccueil de LoRaServer apregraves authentification
71 Configuration de LoRa Server pour lUplink
711 Enregistrement drsquoune nouvelle Organisation
Pour enregistrer une nouvelle Organizations Organizations gt Create Puis entrer les configurations
suivantes
Figure 79 Enregistrement dun nouvelle Organisation
712 Enregistrement drsquoune instance du Network Server Pour enregistrer une nouvelle instance du Network Server Network Server gt Create Puis entrer
les configurations suivantes
| 70
Figure 80 Enregistrement dun nouveau Network Server
Dans lrsquoonglet Gateway Discovery il est possible drsquoactiver une option de deacutecouverte de Gateway aux
alentours Lorsqursquoelle est configureacutee le Network Server va envoyer une trame Downlink de
configuration de la Gateway lui ordonnant de reacutealiser des PING en LoRa La configuration du
Gateway Discovery preacutevoit de speacutecifier
Le nombre de fois par jour que les PING LoRa sont envoyeacutes
Le canal drsquoeacutemission
Le Data Rate (Voir paragraphe 445)
Un PING LoRa reccedilu sur une Gateway sera retransmis sur le Network Server (Lora Server) et une carte
sera afficheacutee
Lrsquoonglet TLS Certificates ne sera pas utiliseacute dans le cadre de notre deacutemonstration
713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) Il faut tout drsquoabord faire un enregistrement drsquoun laquo service-profile raquo Un laquo service profile permet de
faire la connexion entre le Network Server et les Applications que nous enregistrerons dans notre
Organisation Service-profiles gt Create
Service-profile name myServiceProfile
Network-server myNetworkServer
On laissera par deacutefaut toutes les autres options
Pour enregistrer une nouvelle Application Applications gt Create Puis entrer les configurations
suivantes
| 71
Figure 81 Enregistrement dune nouvelle Application
714 Enregistrement des Devices LoRa Il faut tout drsquoabord faire lrsquoenregistrement drsquoun Device-profile pour les Devices LoRa que vous
souhaitez connecter Dans notre cas nous ferons un premier test en speacutecifiant que nous utilisons
seulement le mode drsquoauthentification ABP (voir chapitre 431) Devices profile gt Create
Figure 82 Enregistrement dun laquo Device profile raquo
Nous pouvons alors creacuteer dans notre Application des nouveaux Devices Application gt
myApplication gt Create
| 72
Figure 83 Enregistrement dun nouveau Device LoRa
Dans la fenecirctre Activation on va alors configurer les 3 eacuteleacutements indispensables agrave une
authentification en APB Le DevAddr le NwkSKey et lrsquoAppSKey
Figure 84 Configuration de lenregistrement du Device LoRa (en ABP)
La configuration minimale de LoRaServer est maintenant termineacutee Nous pouvons donc brancher
un Device LoRa qui possegravede les les attribus (DevAddr NwkSKey et AppSKey) que nous avons
enregistreacute dans LoRaServer et le faire eacutemettre
715 Visualisation des trames reccedilues Les trames eacutemises par le Device LoRa vont donc parcourir le cheminement suivant
| 73
Figure 85 Reacutesumeacute du cheminement des trames LoRaWan en Uplink avec LoRaServer
En allant dans le Live Device Data (Application gt Nom_du_Device gt Live Device Data) on peut voir la
liste des trames reccedilues ainsi que les donneacutees applicatives deacutechiffreacutees
Figure 86 Reacuteception des trames des Devices LoRa
Figure 87 Analyse des trames des Devices LoRa
Dans lrsquoonglet LIVE LORAWAN FRAME nous pouvons voir les trames LORAWAN et si besoin eacutetudier
le contenu de ce qursquoelles contiennent En revanche les donneacutees applicatives sont ici chiffreacutees
UDP
Packet Forwarder
LoRa Bridge
Gateway LoRa Server LoRa App Server
Gateway
Server
Internet
| 74
Figure 88 Reacuteception des Trames LoRaWAN
72 Configuration de LoRaServer pour linteacutegration dApplication Nous avons vu dans le chapitre 718 que linterface entre LoRaServer et notre Application pouvait
ecirctre reacutealiseacutee soit par MQTT soit par les meacutethodes REST (HTTP POST) Nous avons deacutejagrave impleacutementeacute
et expliqueacute ces protocoles dans le cadre de son utilisation avec TTN Nous allons donc juste
configurer LoRaServer pour tester ces deux meacutethodes
721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST Nous utiliserons exactement la mecircme meacutethode que celle que nous avons utiliseacute avec TTN au
chapitre 615 Les diffeacuterentes Clients et Serveurs disponibles pour ces tests sont expliqueacutes au
paragraphe 612
Dans LoRaServer ajouter une inteacutegration HTTP LoRaServer gt Applications gt myApplication gt
Integrations gt Create gt HTTP Integration et la configurer comme le montre la Figure 89 Vous
remplacerez eacutevidement le lien par votre propre Endpoints
Figure 89 Configuration de linteacutegration HTTP POST dans LoRaServer
En envoyant des trames LoRa depuis votre Device vous devriez voir les contenus JSON sur votre
Endpoint
722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT Nous allons nous connecter au Broker MQTT de LoRaServer Pour cela nous utiliserons la mecircme
meacutethode que celle que nous avons utiliseacute avec TTN au chapitre 628 Nous utiliserons MQTTBox
comme nous lavons deacutejagrave fait au paragraphe 627
Le Broker de LoRaServer a enregistreacute les Topics suivant
[applicationID] correspond au nom de votre Application
[devEUI] correspond au nom de votre Device LoRa
| 75
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink application[applicationID]device[devEUI]rx
[Donneacutees] Flux Downlink application[applicationID]device[devEUI]tx
[Status] Statut dun Device application[applicationID]device[devEUI]status
[Ack] Acquittement des messages application[applicationID]device[devEUI]ack
[Erreurs] Erreurs application[applicationID]device[devEUI]error
Tableau 13 Topics enregistreacutes dans LoRaServer
| 76
8 Creacuteation de notre propre Application
81 Utilisation de Node-RED
811 Preacutesentation Node-RED est un outil de programmation graphique qui permet de faire communiquer les
peacuteripheacuteriques mateacuteriels drsquoun systegraveme sans eacutecrire de code De nombreux protocoles sont aussi pris
en charge au travers de bloc ( Node) qursquoil suffit de connecter entre eux pour reacutealiser simplement
une application Il peut srsquoexeacutecuter localement sur un PC ou sur des cibles embarqueacutees telle qursquoune
Raspberry PI (RPI)
Dans les deacutemonstrations que nous mettrons en œuvre nous utiliserons une RPI Par soucis de
simpliciteacute nous utiliserons les derniegraveres versions de Raspbian (systegraveme drsquoexploitation de la RPI) qui
integravegre drsquoorigine Node-RED Il nrsquoy a donc tregraves peu de chose agrave mettre en place pour arriver agrave mettre
en place une Application Nous pouvons travailler soit directement sur la RPI agrave lrsquoaide drsquoune souris-
clavier mais il est recommandeacute de travailler agrave distance avec une connexion SSH
812 Mise en place de lrsquoenvironnement La mise en place de la RPI avec le systegraveme drsquoexploitation Raspbian a eacuteteacute preacutesenteacute au chapitre 721
Vous pouvez reprendre la mecircme installation ou repartir sur une nouvelle
Il est possible de faire en sorte que Node-RED se lance directement au deacutemarrage gracircce agrave la
commande sudo systemctl enable noderedservice
Sil nest pas actif lancer Node-RED sur votre RPI node-red-start
Nous nous connectons au Node-RED de la RPI via un navigateur web sur le port 1880 en tapant dans
la barre dURL httpIP_Raspeberry_PI1880 Ce nous permet darriver agrave la fenecirctre suivante
Figure 90 Page daccueil de Node-RED
Il est possible de sinterfacer avec TTN avec les Nodes deacutejagrave disponibles gracircce au protocole HTTP
POST ou MQTT Neacuteanmoins nous pouvons avantageusement installer deux librairies speacutecifiques
Une qui facilite linterfaccedilage avec TTN
Une qui facilite la mise en place dinterface graphique
Installation des Nodes TTN
cd $HOMEnode-red
npm install node-red-contrib-ttn
Installation de Dashboard (interface graphique)
| 77
cd $HOMEnode-red
npm install node-red-dashboard
Il peut ecirctre necessaire de redeacutemarrer Node-RED pour prendre en compte linstallation de nos deux
Nodes
-----------------------------------
sudo apt-get install npm
sudo npm install -g npm
hash -r
cd ~node-red
npm install node-red-example node name
------------------------------------
813 Creacuteer une Application speacutecifique pour TTN Nous allons commencer par geacuterer le flux Uplink Apporter sur votre scheacutema un Node ttn uplink et
un Node Debug puis relier les Le Node ttn uplink nous permettra de configurer la
communication avec TTN en MQTT Le Node debug eacutecrira sur le terminal les informations brutes
qui seront reccedilu par le Node ttn uplink
Figure 91 Visualisation des trame publieacutees par TTN sur notre client MQTT
Double cliquer sur le Node ttn uplink pour le configurer comme la figure suivante
Le champ Name sera le nom du Node sur votre scheacutema Le champ Device ID est le device LoRa
concerneacute dans votre application De plus il faut entrer les caracteacuteristiques de votre application (Add
new ttn app) pour que Node-RED puisse sy connecter
Figure 92 Configuration du node ttn uplink
Configuration de votre nouvelle application
| 78
Figure 93 Identifiant et mot de passe de notre application
AppID Nom de votre application Dans notre cas seminaire_lorawan
Access Key Comme nous lavons deacutejagrave expliqueacute plus tocirct l Access Key vous sera donneacutee
par lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application
vous trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt
Overview
Le Node ttn uplink doit maintenant avoir le nom que vous avez configureacute Cliquer sur Deploy pour
lancer votre projet Le bloc ttn uplink doit maintenant ecirctre connecteacute agrave TTN Cela est speacutecifieacute
connected sous le bloc
Figure 94 Utilisation du Node TTN Uplink
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
Figure 95 Simulation de Uplink dans TTN
Vous devriez voir le reacutesultat dans la fenecirctre de Debug Par exemple pour le test denvoi de 31 32
correspondant au code ASCII des chiffres 1 et 2 vous devriez avoir la fenecirctre de Debug suivante
| 79
Figure 96 Reacutesultats obtenu dans la fenecirctre Debug apregraves la simulation dUplink
814 Creacuteation drsquoun Dashboard
Dans la mise en place de lenvironnement (chapitre 812) nous avons installeacute des Nodes
Dashboard qui vont nous permettre de reacutealiser une interface graphique tregraves simple et de la mettre
agrave disposition des utilisateurs via un des graphiques histogramme gauges afficheurshellip
Figure 97 Impleacutementation dune interface graphique dans Node RED
Linterface graphique que nous allons creacuteer sera constitueacutee donglet (tab) La mise en place des
composant se fait de la faccedilon suivante
Chaque eacuteleacutement graphique doit appartenir agrave un groupe de composant quil va falloir creacuteer
Chaque groupe de composant doit appartenir agrave un onglet (tab) quil va falloir creacuteer
Figure 98 Creacuteation dun groupe de composant
Figure 99 Creacuteation dun nouvel onglet dans le site web
Cliquer sur Deploy pour activer votre application
LURL pour joindre linterface graphique de votre site web est disponible sur ladresse
httpIP_Raspeberry_PI1880ui
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
| 80
Figure 100 Interface graphique du site web avec Node-RED
82 Programmation en PHP Maintenant que nous avons testeacute toute lrsquoarchitecture nous pouvons mettre en place une
application qui jouera deux rocircles
Un rocircle de Serveur HTTP POST reacutecupeacuterant les donneacutees en provenance de TTN
Un rocircle de Client HTTP POST qui geacuteneacuterera les requecirctes vers TTN
Un serveur web apache sur RPI heacuteberge cette application Linterface graphique du site web est
reacutealiseacute avec le template CSS proposeacute par Bootstrap [ httpsgetbootstrapcom ]
Figure 101 Architecture de notre application en PHP sur RPI
The Things Network
Notre Application
[ Serveur Apache sur Raspberry Pi ]
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 81
Nous allons lrsquoutiliser telle quelle Elle est juste proposeacutee agrave titre dexemple Lrsquoobjectif de cette
application est de geacuteneacuterer une ouverture fermeture de ruche agrave distance dans le cadre de projets
eacutetudiants du Master Electronique et Systegravemes Embarqueacutes de lUSMB [ httpscem-esetuniv-
smbfr ]
Figure 102 Application permettant de recevoir et deacutemettre des requecirctes HTTP POST
Configurer TTN pour pointer vers votre nouveau serveur et tester le flux montant et
descendant
| 82
9 Versions du document
Version 10 02022019
Version initiale
Version 20 23022019
Ajout drsquoun paragraphe Les systegravemes embarqueacutes dans lrsquoIoT En introduction
Compleacutement et ameacutelioration Ameacutelioration exercice eacutetalement de spectre
Correction Cacircblage Arduino
Ajout drsquoun paragraphe Fonctionnement de lrsquoArduino et ajout de librairies
Compleacutement et ameacutelioration Couche physique LoRa Ajout de 4 figures pour lrsquoexplication
de la modulation Chirp
Ajout drsquoun paragraphe sur les acronymes utiliseacutes au deacutebut du cours TTN LoRa MQTThellip
Compleacutement drsquoinformations sur les dB et dBm
Ajout LoRa Calculator
Version 30 8032019
Ajout de figure sur le rocircle de la Gateway LoRa
Ajout de paragraphe authentification avec le Network Server
Ajout de paragraphe sur le chiffrement avec lrsquoApplication Server
Ajout drsquoun sommaire en deacutebut de cours
Ajout de 2 scheacutemas ABP et OTAA
Retrait explication du deacutetail de la laquo Join Request raquo en OTAA Trop complexe attente de
reacutealisation drsquoun scheacutema plus explicite
Ajout drsquoun scheacutema sur lrsquoattaque par REPLAY
Ajout de paragraphe des diffeacuterents reacuteseaux LoRaWAN existants Opeacutereacutes et Priveacutes
Ajout des scheacutemas des trames LoRaWAN Physique LoRa MAC Application
Compleacutement drsquoinformation sur les Classes de Devices
Ajout drsquoun paragraphe sur la Gateway utiliseacutee pour le Downlink
Ajout drsquoun paragraphe sur le JSON
Compleacutement drsquoinformation sur le codage en Base64
Ajout drsquoinformation dans le deacutecodage des trames LoRaWAN
Restructuration des explications sur lrsquoenvoi et la reacutecupeacuteration des donneacutees en HTTPMQTT
Version 40 8032019
Ajout drsquoun chapitre Creacuteation de notre propre Application
Ajout drsquoun chapitre Creacuteation de notre propre Network et Application Server
Ajout drsquoune figure Visualisation des Chirps LoRa par SDR (Radio Logicielle)
Compleacutements drsquoinformation sur MQTT
Compleacutements dinformation sur les Topics de TTN en MQTT
| 9
1rsquo Message User 2 0 1 0 1
2rsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
3rsquo Symboles transmis User 2 = (1rsquo) x (2rsquo) 0 0 0 0
hellip transmission hellip
4rsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
5rsquo Deacutecodage = (3rsquo) x (4rsquo) 0 0 0 0
6rsquo Message reccedilu (sum (5rsquo) nbr_bits) 0
1rsquorsquo Message User 3 1 1 0 0
2rsquorsquo Utilisation code orthogonal User 3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
3rsquorsquo Symboles transmis User 3 = (1rsquorsquo) x (2rsquorsquo) 1 -1 -1 1
hellip transmission hellip
4rsquorsquo Utilisation code orthogonal User3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
5rsquorsquo Deacutecodage = (3rsquorsquo) x (4rsquorsquo) 1 1 1 1
6rsquorsquo Message reccedilu (sum (5rsquorsquo) nbr_bits) 1
132 Transmissions simultaneacutees
Les transmissions se deacuteroulent maintenant simultaneacutement les messages des User 1 User 2 et User
3 sont envoyeacutes en mecircme temps sur la mecircme bande de freacutequence La premiegravere colonne du User 1
est deacutejagrave remplie en guise drsquoexemple La meacutethode est la suivante
Dans lrsquoair
On additionne les symboles transmis par tous les User (1 2 3) ligne 1rsquorsquorsquo
Pour la reacuteception
Chaque symbole reccedilu est multiplieacute par le code drsquoeacutetalement du User
Le message reccedilu est eacutegal agrave la somme des symboles diviseacute par le nombre de symbole
Valider le fonctionnement pour la reacuteception des messages
1rsquorsquorsquo sum des symboles transmis ( 3 + 3rsquo + 3rsquorsquo ) 2 -2 0 0
2rsquorsquorsquo Utilisation code orthogonal User 1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 2 0 0
4rsquorsquorsquo Message reccedilu User 1 (sum (3rsquorsquorsquo) nbr_bits) 1
2rsquorsquorsquo Utilisation code orthogonal User 2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 -2 0 0
4rsquorsquorsquo Message reccedilu User 2 (sum (3rsquorsquorsquo) nbr_bits) 0
2rsquorsquorsquo Utilisation code orthogonal User 3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
3rsquorsquorsquo Deacutecodage (1rsquorsquorsquo) x (2rsquorsquorsquo) 2 2 0 0
4rsquorsquorsquo Message reccedilu User 3 (sum (3rsquorsquorsquo) nbr_bits) 1
133 Cas du protocole LoRa Le LoRa utilise une meacutethode drsquoeacutetalement de spectre qui nrsquoest pas exactement celle que nous venons
drsquoeacutetudier La finaliteacute est cependant la mecircme Pouvoir transmettre en mecircme temps sur le mecircme
canal Le protocole LoRa utilise sept laquo codes drsquoeacutetalement raquo appeleacutes Spreading Factor [ SF6 SF7 SF8
SF9 SF10 SF11 et SF12 ] qui lui permet drsquoavoir sept transmissions simultaneacutees sur un mecircme canal
| 10
2 Transmission radio et propagation
21 Les uniteacutes et deacutefinitions dB Rapport entre deux puissances Une atteacutenuation est repreacutesenteacutee par un nombre
neacutegatif (-) Un gain est repreacutesenteacute par un nombre positif (+)
Rapport de puissances en dB Rapport de puissance
+ 3 dB Multiplication par 2
- 3 dB Division par 2
0 dB Egaliteacute
+ 10 dB Multiplication par 10
- 10 dB Division par 10
Tableau 2 Comparaison entre les gains en dB et en proportion
dBi Gain theacuteorique drsquoune antenne
dBm Puissance rameneacutee agrave 1mW 0 dBm correspond agrave 1 mW
En reprenant la deacutefinition des dB remplir le tableau suivant
Puissance en dBm Puissance en mW
+ 3 dBm
- 3 dBm
+ 10 dBm
- 10 dBm
Tableau 3 Comparaison entre les puissances en dB et en mW
Le Talkie-Walkie a une puissance drsquoeacutemission de 2W Quelle est la puissance drsquoeacutemission
exprimeacutees en dBm
Sensibiliteacute Puissance minimale qursquoest capable de deacutetecter un reacutecepteur
RSSI Received Signal Strength Indication
SNR Signal over Noise Ratio
Un eacutemetteur transmet agrave une puissance de 13dBm en utilisant une antenne dont le gain
est de 2dBi Les pertes dans lrsquoair sont de 60 dB Lrsquoantenne reacuteceptrice qui possegravede un gain
de 2dBi est relieacutee agrave un reacutecepteur dont la sensibiliteacute est de -80 dBm Le signal pourra-t-il
ecirctre reccedilu
Le link Budget Crsquoest la quantiteacute de puissance que nous pouvons perdre avant drsquoarriver au
reacutecepteur tout en conservant une transmission fonctionnelle Autrement dit crsquoest la
puissance de lrsquoeacutemetteur moins la sensibiliteacute du reacutecepteur Dans lrsquoexemple preacuteceacutedent le
budget que nous avons agrave disposition est de 93dB
| 11
En LoRa nous avons un Link Budget de 157 dB
En LTE (4G) nous avons un Link Budget de 130 dB
Etude de la documentation drsquoun composant LoRa Le RN2483 est le composant radiofreacutequence que nous utiliserons dans notre transmission LoRa
Voici quelques une de ses caracteacuteristiques
Figure 3 Caracteacuteristiques principales du composant radiofreacutequence utiliseacute
Reprenez la deacutefinition du Link Budget et retrouver les 157 dB annonceacute dans cette
documentation
En LoRa plus le code drsquoeacutetalement est grand plus on est capable drsquoeacutemettre dans un milieu bruiteacute La
figure ci-dessous preacutesente les rapports signal sur bruit avec lesquels nous seront capable de reacutealiser
une transmission en fonction des Spreading Factor utiliseacutes
Figure 4 Influence du Spreading Factor sur le SNR acceptable
On remarque que pour un SF8 nous sommes capables drsquoeacutemettre avec un SNR de -10 dB On pourra
transmettre malgreacute le fait que le bruit est 10 fois supeacuterieur au signal
On remarque que pour un SF12 nous sommes capables drsquoeacutemettre avec un SNR de -20 dB On
pourra transmettre malgreacute le fait que le bruit est 100 fois supeacuterieur au signal
| 12
Cependant on remarque aussi que lrsquoutilisation drsquoun Spreading Factor plus eacuteleveacute augmente
consideacuterablement le nombre de symbole eacutemis (2egraveme colonne du tableau) Comme nous le verrons
plus tard cela impactera eacutevidement le temps de transmission
| 13
3 La couche physique LoRa
31 La modulation LoRa Comme nous lrsquoavons expliqueacute plus tocirct la modulation LoRa utilise lrsquoeacutetalement de spectre pour
transmettre ces informations Mais au lieu drsquoutiliser des codes drsquoeacutetalement (CDMA) elle utilise une
meacutethode appeleacutee Chirp Spread Spectrum La finaliteacute est toujours la mecircme Avoir plusieurs
transmissions dans le mecircme canal La conseacutequence sur le spectre est aussi la mecircme cela provoque
un eacutetalement du spectre
311 La forme du symbole (Chirp) Le signal eacutemis par la modulation LoRa est un symbole dont la forme de base est repreacutesenteacutee ci-
dessous Son nom (Chirp) vient du fait que ce symbole est utiliseacute dans la technologie Radar (Chirp
Compressed High Intensity Radar Pulse)
Figure 5 Symbole de la modulation LoRa (source Wikipeacutedia)
La freacutequence de deacutepart est la freacutequence centrale du canal moins la Bande Passante diviseacutee par deux
La freacutequence de fin est la freacutequence centrale plus la Bande Passante diviseacutee par deux
La freacutequence centrale est appeleacutee le canal
La bande passante est la largeur de bande occupeacutee autour du canal
On considegravere une eacutemission sur la freacutequence centrale 868 Mhz avec une Bande Passante
de 125 kHz Donner la freacutequence de deacutebut et la freacutequence de fin du sweep
Freacutequence de deacutebut
Freacutequence de fin
Pour faciliter la repreacutesentation de ce symbole on utilise plutocirct un graphique TempsFreacutequence de
la forme suivante
| 14
Figure 6 Forme du symbole de base (CHIRP)
En LoRa chaque symbole repreacutesente un certain nombre de bits transmis La regravegle est la suivante
Nombre de bits transmis dans un symbole = Spreading Factor
Par exemple si la transmission utilise un Spreading Factor de 10 (SF10) alors un symbole repreacutesente
10 bits
Crsquoest-agrave-dire qursquoagrave lrsquoeacutemission les bits sont regroupeacutes par paquet de SF bits puis chaque paquet est
repreacutesenteacute par un symbole particulier parmi 2119878119865formes de symboles possibles
Sur la figure suivante voici un exemple theacuteorique drsquoune modulation en SF2 agrave 868 Mhz sur une
bande passante de 125 kHz Chaque symbole repreacutesente donc 2 bits
Figure 7 Symboles eacutemis en Modulation LoRa (Cas theacuteorique en SF2)
Exemple
On considegravere la suite binaire suivante 0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Le Spreading Factor utiliseacute est SF10
Nous regroupons donc les bits par paquet de 10 Chaque paquet de 10 bits sera repreacutesenteacute par un
symbole (sweep) particulier Il y a 1024 symboles diffeacuterents pour coder les 1024 combinaisons
binaires possibles (210)
Freacutequence
Temps
868 000 000 Hz
868 062 500 Hz
Un symbole Un symbole
867 937 500 Hz
Temps
868 000 000 Hz
867 937 500 Hz
Symbole 0
Bits laquo 00 raquo
Symbole 1
Bits laquo 01 raquo
Symbole 2
Bits laquo 10 raquo Symbole 3
Bits laquo 11 raquo
12
5 k
Hz
868 062 500 Hz
| 15
Figure 8 Emission des Chirp en LoRa
Avec un outils drsquoanalyse spectrale actif pendant lrsquoeacutemission LoRa drsquoun Device on peut afficher les
successions de symbole qui sont envoyeacutes Cette oscillogramme a eacuteteacute reacutealiseacute agrave lrsquoaide drsquoun SDR
(Software Digital Radio)
Figure 9 Visualisation des Chirps LoRa reacuteellement eacutemis pendant une transmission
312 Dureacutee drsquoeacutemission drsquoun symbole En LoRa la dureacutee drsquoeacutemission de chaque symbole (Chirp) deacutepend du Spreading Factor utiliseacute Plus le
SF est grand et plus le temps drsquoeacutemission sera long Pour une mecircme bande passante le temps
drsquoeacutemission drsquoun symbole en SF8 est deux fois plus long que le temps drsquoeacutemission drsquoun symbole en
SF7 Ainsi de suite jusqursquoagrave SF12
0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Envoi de 1 Chirp Envoi de 1 Chirp Envoi de 1 Chirp
Transmission Transmission Transmission
| 16
Figure 10 Temps drsquoeacutemission drsquoun symbole (Chirp) en fonction du SF
En revanche le temps drsquoeacutemission drsquoun symbole est inversement proportionnel agrave la bande passante
119879119904 =2119878119865
119861119886119899119889119908119894119889119905ℎ Le deacutebit des symboles est donc de
1
119879119878= 119865119904 =
119861119886119899119889119908119894119889119905ℎ
2119878119865 En toute logique plus la
bande passant est eacuteleveacute plus le deacutebit des symboles sera eacuteleveacute Comme chaque symbole comprend
SF bit on retrouve alors le deacutebit binaire
119863119887 = 119878119865119861119886119899119889119908119894119889119905ℎ
2119878119865
Plus le Spreading Factor sera eacuteleveacute plus le deacutebit binaire sera faible
Plus la Bande Passante sera eacuteleveacutee plus le deacutebit binaire sera fort
Exemple Drsquoapregraves la formule du deacutebit binaire trouver le deacutebit pour les deux cas suivants
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
32 Coding Rate Le Coding Rate est un ratio qui augmentera le nombre de bits agrave transmettre afin de reacutealiser de la
deacutetection correction drsquoerreur Dans le cas drsquoun CR = 4 8 il y aura 8 bits transmis reacuteellement agrave
chaque fois que nous souhaitons transmettre 4 bits Dans cette exemple cela provoque une
transmission drsquoun nombre de bit multiplieacute par 2
SF7
Freacutequence
Temps
Freacutequence centrale
Freacutequence haute
Temps drsquoun symbole eacutemit en SF 12
Freacutequence basse
SF8
SF9
SF10
SF11
SF12
Temps drsquoun symbole eacutemit en SF 11
| 17
Figure 11 Influence du Coding Rate sur le nombre de bits ajouteacute
Si on reprend lrsquoexemple preacuteceacutedent avec un CR de 4 5 nous avons une augmentation de 125 du
nombre de bits agrave transmettre Redonner la deacutebit en prenant en compte le CR
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
La documentation du composant RN2483 donne les deacutebits en fonction du Spreading Factor
la Bande Passante et le Coding Rate Veacuterifier la coheacuterence du reacutesultat avec votre calcul
preacuteceacutedent
Figure 12 Deacutebit en fonction des paramegravetres de la transmission LoRa
33 Utilisation du LoRa Calculator Le logiciel laquo LoRa Calculator raquo est un petit exeacutecutable permettant de simuler une transmission LoRa
en fonction des caracteacuteristiques saisies Canal SF CR etchellip Il est teacuteleacutechargeable agrave lrsquoadresse
suivante httpsbitly2TyloAh
| 18
Figure 13 Le logiciel LoRa Calculator
En reprenant lrsquoexemple preacuteceacutedent (SF7 Bande Passante 125 kHz CR 45) veacuterifier les
calculs du laquo Equivalent Bitrate raquo
34 Time On Air La norme LoRaWAN impose qursquoun Device LoRa ne transmette pas plus de 1 du temps Cela est
repreacutesenteacute par un Duty Cycle Par exemple un Duty Cycle de 1 signifie que si jrsquoeacutemet pendant 1 je
ne dois plus eacutemettre pendant 99 quel que soit lrsquouniteacute de temps utiliseacutee
En reprenant les exemples preacuteceacutedents quels sont les deacutebits moyens si on prend en compte
le laquo Time On Air raquo
Cas 1 Pour SF7 et 125 khz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
Dans le logiciel laquo LoRa Calculator raquo (onglet laquo Energy Profile raquo) nous pouvons estimer la
dureacutee de vie drsquoune batterie Nous prenons lrsquoexemple drsquoun releveacute de tempeacuterature dans un
bacirctiment avec les caracteacuteristiques suivantes
| 19
SF CR Bande Passante etc Nous nous placcedilons dans le cas 1 des exemples preacuteceacutedents
Le releveacute de tempeacuterature se fera toutes les 15 mins
La batterie est constitueacute de 3 petites piles bacirctons [ AAA LR03 ] 12V en seacuterie Soit 36 V
1000 mAh
35 Mise en œuvre LoRa en point agrave point Ce test sera reacutealiseacute avec des modules LoRa RN2483 (Microchip) et une carte microcontrocircleur
ARDUINO
Figure 14 Communication LoRa en Point agrave Point
Reacutealiser le cacircblage de votre module RN2483 suivant le tableau suivant
Connecteur Arduino Click Board RN2483
5V 5V
GND GND
11 RX
10 TX
Tableau 4 Cacircblage de lrsquoARDUINO et de la click Board RN2483
351 Utilisation de lrsquoIDE Arduino Lrsquoenvironnement Arduino est tregraves simple Nous allons reacutealiser un programme pour montrer son
fonctionnement
La connexion de la carte est effectueacutee agrave lrsquoaide drsquoun port USB qui eacutemule une liaison seacuterie
RS232 Il faut donc choisir le bon port Arduino IDE gt Outils gt Port
Pour creacuteer un nouveau programme (sketch) Arduino IDE gt Fichier gt Nouveau
Il y a deux parties dans un sketch
Une fonction setup() qui sera exeacutecuteacutee qursquoune seule fois au deacutemarrage
Une fonction loop() qui sera exeacutecuteacutee en boucle
Ecrire le code suivant
Emetteur
Reacutecepteur
UA
RT
UA
RT
| 20
void setup()
Serialbegin(9600)
void loop()
Serialprintln(hello word)
Compiler et Teacuteleacuteverser Croquis gt Teacuteleacuteverser
Voir la sortie sur la liaison seacuterie Outils gt Moniteur Seacuterie gt Choisir la vitesse de
transmission ici 9600 bauds (en bas agrave droite)
352 Validation du fonctionnement Deux binocircmes joueront le rocircle drsquoeacutemetteur tous les autres binocircmes seront en reacutecepteur
Reacutecupeacuterer les programmes dans Moodle dans le dossier laquo RN2483-Arduino-Point2Point raquo
Installer la librairie RN2483 Arduino IDE gt Croquis gt Inclure une bibliothegraveque gt Ajouter la
bibliothegraveque zip
Reacutepartissez les rocircles Emetteurs Reacutecepteurs et reacutecupeacuterer le programme LoraBlinkerRX ou
LoraBlinkerTX en fonction Les 2 binocircmes en eacutemission devront modifier le code du sketch
Arduino pour transmettre des donneacutees speacutecifiques afin de les diffeacuterencier [
loraSerialprintln(radio tx 30) ]
Validez la reacuteception des donneacutees eacutemises par les deux binocircmes qui transmettent des
donneacutees Ces donneacutees reccedilues sont eacutecrite agrave 57600 bauds sur le moniteur seacuterie de lrsquoArduino
353 Mise en valeur du Spreading Factor On srsquoaperccediloit dans la manipulation preacuteceacutedente que les Devices LoRa reccediloivent les donneacutees des deux
eacutemetteurs Nous allons conserver le mecircme canal drsquoeacutemission (8691 Mhz) mais un des deux
eacutemetteurs va modifier son laquo Spreading Factor raquo La salle sera donc seacutepareacutee en deux groupes
1er groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF7
2egraveme groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF8
Validez la reacuteception des donneacutees eacutemises seulement pour le Spreading Factor que vous
utilisez
| 21
4 Le protocole LoRaWAN
Le LoRa est le type de modulation utiliseacute entre deux Devices ou entre un Device et une Gateway
Lorsque nous parlons de lrsquoensemble de la chaine de communication (Device Gateway Serveur) alors
nous parlons de communication LoRaWAN Nous allons voir lrsquoarchitecture drsquoun reacuteseau LoRaWAN
ainsi que les regravegles de ce protocole
41 Structure drsquoun reacuteseau LoRaWAN Nous retrouvons drsquoun cocircteacute le Device LoRa qui transmet une donneacutee Elle est reacuteceptionneacutee agrave lrsquoautre
extreacutemiteacute du reacuteseau par un Utilisateur La structure globale du reacuteseau LoRaWAN peut ecirctre
repreacutesenteacutee par la figure suivante
411 Les Devices LoRa Les Devices LoRa sont des systegravemes eacutelectroniques appartenant au monde de lrsquoIoT Faible
consommation faible taille faible puissance et faible taille
Ils possegravedent une radio LoRa permettant de joindre les Gateways Les Gateways ne sont pas
adresseacutees speacutecifiquement toutes celles preacutesentes dans la zone de couverture reccediloivent les
messages et les traitent
412 Les Gateways LoRa Elles eacutecoutent sur tous les canaux et sur tous les Spreading Factor Lorsqursquoune trame LoRa est reccedilue
elle transmet son contenu sur internet agrave destination du Network Server qui a eacuteteacute configureacute dans la
Gateway au preacutealable
Elle joue donc le rocircle de passerelle entre une modulation LoRa et une communication IP
Devices
LoRa Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
Internet Internet
Figure 15 Structure globale dun reacuteseau LORAWAN
| 22
Chaque Gateway LoRa possegravede un identifiant unique (EUI sur 64 bits)
413 Le Network Server
Le Network Server reccediloit les messages transmis par les Gateways et supprime les doublons
(plusieurs Gateway peuvent avoir reccedilu le mecircme message) Les informations transmises au Network
Server depuis les Devices LoRa sont authentifieacutes gracircce agrave une cleacute AES 128 bits appeleacutee Network
Session Key NwkSKey Nous parlons bien ici drsquoauthentification et non pas de chiffrement comme
nous le verrons plus tard
414 Application Server Il est souvent sur le mecircme support physique que le Network Server Il permet de dissocier les
applications les unes des autres Chaque application enregistre des Devices LoRa qui auront le droit
Devices Gateways Network
Server
Internet
Network Session Key (NwkSKey)
Authentification
Figure 17 Authentification entre le Device LoRa et le Network Server
Internet
UDP IP
Modulation
LoRa
Device LoRa
Gateway
Network Server
LoRaWAN
Modulation
LoRa
Passerelle LoRa Internet
Internet
UDP IP
LoRaWAN
Transmission Radio
Application Application
Figure 16 Le rocircle de la Gateway LoRa
| 23
de stocker leurs donneacutees (Frame Payload) Les message transmis agrave lrsquoapplication server sont chiffreacutes
gracircce agrave une cleacute AES 128 bits appeleacutee Application Session Key AppSKey
Le scheacutema suivant reacutesume lrsquoutilisation
De la Network Session Key (NwkSKey) pour lrsquoauthentification entre le Device LoRa et le
Network Server
De lrsquoApplication Session Key (AppSKey) pour le chiffrement entre le Device LoRa et
lrsquoApplication Server
Devices Gateways Network
Server Application
Server
Internet
Application Session Key (AppSKey)
Chiffrement
Figure 18 Chiffrement entre le Device LORA et lrsquoApplication Server
| 24
415 Application Web Serveur Cette application doit drsquoune part reacutecupeacuterer les donneacutees de lrsquoApplication Serveur Dans le cadre de
ce cours cela sera fait de deux faccedilons
Avec le protocole HTTP
Avec le protocole MQTT
Figure 20 Application Web Server
Figure 19 Authentification et chiffrement en LoRaWan
Devices Gateways
Network
Server Application
Server
Internet
Network Session Key
Application Session Key
Network
Server Application
Server
Application
Server Web
Utilisateur
Protocole
MQTT ou HTTP
Flux Uplink
Flux Downlink
| 25
Le flux habituel dans lrsquoIoT est le flux Uplink (flux montant) crsquoest-agrave-dire lrsquoeacutemission de donneacutees des
objets vers le serveur Comme nous lrsquoexpliquerons plus loin en LoRaWAN il est aussi possible de
transfeacuterer des donneacutees aux Device LoRa par un flux Downlink (flux descendant)
Drsquoautre part lrsquoapplication mettra agrave disposition les donneacutees aux utilisateurs sous forme par exemple
drsquoun serveur web drsquoune base de donneacutees et drsquoune visualisation graphique
416 Authentification avec le Network Server La Network Session Key (NwkSKey) sert agrave lrsquoauthentification entre le Device LoRa e le Network Server
Afin de reacutealiser cette authentification entre le Device et le Network Server un champ MIC (Message
Integrity Control) est rajouteacute agrave la trame Il est calculeacute en fonction des donneacutees transmises et du
NwkSkey A la reacuteception le mecircme calcul est effectueacute Si les cleacutes sont eacutequivalentes dans le Device et
dans le Network Server alors les deux MIC calculeacutes doivent correspondre
417 Chiffrement des donneacutees vers lrsquoApplication Server
LrsquoApplication Session Key (AppSKey) sert pour le chiffrement entre le Device LoRa et lrsquoApplication
Server Les donneacutees chiffreacutees seront alors deacutecodeacutees agrave la reacuteception sur lrsquoApplication Server srsquoil
possegravede la mecircme cleacute Si on reprend le scheacutema preacuteceacutedent les laquo donneacutees x raquo sont chiffreacutees
deacutechiffreacutees par le processus suivant
Donneacutees x chiffreacutees NwkSkey x
MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees
NwkSkey x
Trame eacutemise Trame reccedilue
Device LoRa Network Server
Si =
Alors la trame est authentifieacutee
MIC geacuteneacutereacute Emission MIC geacuteneacutereacute Reacuteception
MIC geacuteneacutereacute Reacuteception
Figure 21 Authentification dun Device LoRa par le Network Server
| 26
Figure 22 Chiffrement des donneacutees par lApplication Session Key
418 Combinaison de lrsquoauthentification et du chiffrement On peut maintenant repreacutesenter sur le mecircme scheacutema la construction de la trame LoRaWAN avec
drsquoune part lrsquoauthentification et drsquoautre part le chiffrement
Figure 23 Chiffrement puis Authentification
42 Classes des Devices LoRaWAN Les Devices LoRa sont classeacutes en 3 cateacutegories (A B C) en fonction de leur consommation et de leur
accessibiliteacute en Downlink crsquoest-agrave-dire la faciliteacute qursquoun utilisateur aura agrave transmettre une trame au
Device LoRa
421 Classe A (All) Minimal power Application Tous les Devices LoRaWAN sont de classe A Chaque Device peut transmettre (Uplink) agrave la Gateway
sans veacuterification de la disponibiliteacute du reacutecepteur Si la transmission eacutechoue elle sera reacuteeacutemise apregraves
un certain temps Cette transmission est suivie de 2 fenecirctres de reacuteception tregraves courtes La Gateway
peut alors transmettre pendant le laquo RX Slot 1 raquo ou le laquo RX Slot 2 raquo mais pas les deux
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Device LoRa
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Application Server
Donneacutees non chiffreacutees
AppSKey
Donneacutees chiffreacutees Entecircte
NwkSKey
MIC geacuteneacutereacute en eacutemission Trame transmise =
| 27
Figure 24 Slots de reacuteception pour un Device LoRa de classe A
Source de lrsquoimage httpszakelijkforumkpncom
La dureacutee des fenecirctres doit ecirctre au minimum la dureacutee de reacuteception drsquoun preacuteambule Un preacuteambule
dure 1225 Tsymbole et deacutepend donc du Data Rate (DR voir paragraphe 445 pour plus drsquoinformation
sur le DR) Lorsque qursquoun preacuteambule est deacutetecteacute le reacutecepteur doit rester actif jusqursquoagrave la fin de la
transmission Si la trame reccedilue pendant la premiegravere fenecirctre de reacuteception eacutetait bien agrave destination du
Device LoRa alors la deuxiegraveme fenecirctre nrsquoest pas ouverte
Premiegravere fenecirctre de reacuteception
Le Slot RX1 est programmeacute par deacutefaut agrave 1 seconde + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont les mecircme que ceux choisis lors de la phase drsquoeacutemission
(Uplink)
Seconde fenecirctre de reacuteception
Le Slot RX2 est programmeacute par deacutefaut agrave 2 secondes + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont configurables mais fixes
Un Device LoRa qui est uniquement de classe A ne peut pas recevoir srsquoil nrsquoa pas eacutemis Il
nrsquoest donc pas joignable facilement
422 Classe B (Beacon) Scheduled Receive Slot Les Devices de classe B ont le mecircme comportement que les Devices de classe A mais drsquoautres
fenecirctres de reacuteceptions sont programmeacutees agrave des peacuteriodes preacutecises Afin de synchroniser les fenecirctres
de reacuteception du Device LoRa la Gateway doit transmettre des balises (Beacons) de faccedilon reacuteguliegravere
| 28
Figure 25 Slots de reacuteception pour un Device LoRa de classe B
Source de lrsquoimage httpszakelijkforumkpncom
Un Device LoRa de classe B est joignable reacuteguliegraverement sans qursquoil soit neacutecessairement
obligeacute drsquoeacutemettre En revanche il consomme plus qursquoun Device de classe A
423 Classe C (Continuous) Continuously Listening Les Devices de classe C ont des fenecirctres de reacuteception constamment ouvertes entre 2 Uplinks Ces
Devices consomment donc beaucoup plus
Figure 26 Slots de reacuteception pour un Device LoRa de classe C
Source de lrsquoimage httpszakelijkforumkpncom
| 29
Un Device LoRa de classe C est joignable en permanence En revanche crsquoest la classe de
Device qui est la plus eacutenergivore
424 Quelle Gateway pour les flux Downlink
Nous avons donc vu que le fonctionnement classique du protocole LoRaWAN eacutetait de reacutecupeacuterer de
lrsquoinformation depuis le Device LoRa Crsquoest le flux Uplink
Dans le cas ougrave lrsquoutilisateur transmet des informations au Device LoRa (flux Downlink) on peut se
demander quelle Gateway sera choisie pour transfeacuterer les donneacutees au Device LoRa En effet
lrsquoendroit ougrave est situeacute le Device LoRa nrsquoest pas neacutecessairement connu agrave lrsquoavance
La Gateway utiliseacutee pour le Downlink est celle qui a reccedilu le dernier message du Device
LoRa Un message ne pourra jamais arriver agrave destination drsquoun Device LoRa si celui-ci nrsquoa
jamais transmis quel que soit sa classe A B ou C
43 Activation des Devices LoRa et seacutecuriteacute En LoRaWAN les trois eacuteleacutements indispensables pour la communication sont le DevAddr pour
lrsquoindentification du Device ainsi que deux cleacutes le NwkSKey pour lrsquoauthentification et lrsquoAppSKey
pour le chiffrement Deux meacutethodes sont possibles pour fournir ces informations agrave la fois au Device
LoRa et au serveur
Activation By Personalization APB
Over The Air Activation
431 ABP Activation By Personalization Crsquoest la plus simple des meacutethodes Crsquoest donc peut ecirctre celle que nous avons tendance agrave utiliser lors
drsquoun test de prototype et drsquoune mise en place de communication LoRaWAN
Le Device LoRa possegravede deacutejagrave le DevAddr lrsquoAppSKey et le NwkSKey
Le Network server possegravede deacutejagrave le DevAddr et le NwkSKey
Lrsquoapplication serveur possegravede deacutejagrave le DevAddr et le AppSKey
En ABP toutes les informations neacutecessaires agrave la communication sont deacutejagrave connues par le
Device LoRa et par le Serveur
| 30
432 OTAA Over The Air Activation Crsquoest la meacutethode qursquoil faut privileacutegier car crsquoest celle qui est la plus seacutecuriseacutee Le Device LoRa doit
connaitre le DevEUI lrsquoAppEUI et lrsquoAppkey Le Network Server doit lui connaitre la mecircme Appkey
Tous les eacuteleacutements noteacutes EUI (Extended Unique Identifier) sont toujours sur une taille de
64 bits
Gracircce agrave ces informations de deacutepart et une neacutegociation avec le Network Server (Join Request) le
Device LoRa et le serveur vont geacuteneacuterer les informations essentielles DevAddr NwkSKey et
AppSKey
Figure 28 Obtention du DevAddr NwkSKey et AppSKey en OTAA
DevEUI Unique Identifier pour le device LoRa (Equivalent agrave une MAC sur Ethernet)
Certains Device LoRa ont deacutejagrave un DevEUI fourni en usine
AppEUI Unique Identifier pour lrsquoapplication server
DevEUI
AppEUI
AppKey
Join
Request
DevAddr
NwkSKey
AppSKey
Network Server
Application Server
Devices 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 2
NwkSkey 2
AppSKey 2
Devices 2
DevAddr 2
NwkSkey 2
AppSKey 2
Paramegravetres stockeacutes sur le serveur
Paramegravetres programmeacutes
dans le composant
Figure 27 Parameacutetrage de DevAddr NwkSKey et AppSKey
| 31
AppKey AES 128 cleacute utiliseacutee pour geacuteneacuterer le MIC (Message Code Integrity) lors de la Join
Resquest Il est partageacute avec le Network server
NwkSKey Utiliseacute pour lrsquoauthentification avec le Network Server
AppSKey Utiliseacute pour le chiffrement des donneacutees
433 Seacutecuriteacute Les cleacutes AES 128 bits permettent le chiffrement des informations transmises en LoRaWAN Malgreacute
ce chiffrement une attaque connue en Wireless est celle du REPLAY Crsquoest-agrave-dire que le Hacker
enregistre des trames chiffreacutees circulant sur le reacuteseau LoRa pour les reacuteeacutemettre plus tard Mecircme si
le Hacker ne comprend pas le contenu (les trames sont chiffreacutees) les donneacutees qui sont transporteacutees
sont elles bien comprises par lrsquoApplication Server Des actions peuvent donc ecirctre reacutealiseacutees
simplement par mimeacutetisme
Pour eacuteviter cela la trame LoRaWAN integravegre un champ variable appeleacute laquo Frame Counter raquo Il srsquoagit
drsquoun nombre numeacuterotant la trame sur 16 ou 32 bits LrsquoApplication Server acceptera une trame
uniquement si le laquo Frame Counter raquo reccedilu est supeacuterieur au laquoFrame Counter raquo preacuteceacutedemment Donc
si le Hacker retransmet la trame telle qursquoelle le laquo Frame Counter raquo sera eacutequivalent donc la trame
sera refuseacutee Et comme la trame est chiffreacutee le Hacker nrsquoa pas moyen de savoir comment modifier
un champ de cette trame
Cette seacutecuriteacute impleacutementeacutee par les laquo Frame Counter raquo est inteacuteressante pour srsquoaffranchir drsquoune
attaque par REPLAY mais dans nos tests cela peut poser problegraveme En effet agrave chaque fois que nous
redeacutemarrons le microcontrocircleur notre laquo Frame Counter raquo revient agrave zeacutero alors que celui de
lrsquoApplication Server continue de srsquoincreacutementer Cela peut ecirctre reacutesolue par diffeacuterentes maniegraveres
1 Deacutesactivation du laquo Frame Counter Check raquo Dans certain Application Server cette option
peut ecirctre proposeacutee Bien sucircr il faudra garder en tecircte la faille de seacutecuriteacute que cela engendre
Network Server
Application Server
Devices LoRa
NwkSkey
AppSKey
NwkSkey
AppSKey Hacker
(1) (2)
(1) Ecoute
(2) Reacuteeacutemission
Figure 29 Attaque par REPLAY
| 32
Figure 30 Deacutesactivation du Frame Counter Check dans TTN
2 Utiliser lrsquoauthentification par OTAA au lieu de ABP En effet agrave chaque ouverture de session
en OTAA le laquo Frame Counter raquo est reacuteinitialiseacute coteacute serveur
3 Conserver la valeur du laquo Frame Counter raquo dans une meacutemoire non volatile et reacutecupeacuterer sa
valeur au deacutemarrage du Device LoRa
44 La Trame LoRa LoRaWAN
441 Les couches du protocole LoRaWAN
Lorsque nous avons fait une communication en Point agrave Point nous avons simplement utiliseacute la
couche physique de la modulation LoRa Lorsque nous souhaitons utiliser le protocole LoRaWAN
des couches protocolaires suppleacutementaires se rajoutent
Figure 31 Les couches protocolaires du LoRaWAN
Chaque couche rajoute un service Lors de lrsquoenvoi de la trame les donneacutees utilisateurs sont donc
encapsuleacutees dans chaque couche infeacuterieure jusqursquoagrave la transmission Le deacutetail de lrsquoensemble de la
trame LoRaWAN par couche est deacutecrit sur la figure Figure 32
LoRa Modulation
LoRa Mac
Application
Couche Physique
Couche Mac
Couche Application
| 33
442 Couche Application La couche Application accueille les donneacutees de lrsquoutilisateur Avant de les encapsuler elles sont
chiffreacutees avec lrsquoAppSKey afin de seacutecuriser la transaction
Un ensemble de champs nommeacute Frame Header permet de speacutecifier le DevAddr le Frame Control
le Frame Counter et le Frame Option
Le Frame Port deacutepend du type drsquoapplication et sera choisi par lrsquoutilisateur
Le Frame Payload sont les donneacutees chiffreacutees agrave transmettre Le nombre drsquooctets maximum pouvant
ecirctre transmis (N octets) est donneacute dans le tableau suivant
PHY Payload
P octets Couche
Physique
Couche
Mac
Couche
Application
CRC
2 octets Header + Header CRC
20 bits Preamble
MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Figure 32 Trame LORAWAN complegravete par couche protocolaire
Couche
Application Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Frame Header
Figure 33 Trame LORA couche Applicative
| 34
Data Rate Spreading Factor Bandwidth Max Frame Payload (Nombre N) DR 0 SF12 125 KHz 51 octets
DR 1 SF11 125 KHz 51 octets
DR 2 SF10 125 KHz 51 octets
DR 3 SF9 125 KHz 115 octets
DR 4 SF8 125 KHz 222 octets
DR 5 SF7 125 KHz 222 octets
DR 6 SF7 250 KHz 222 octets
Tableau 5 Taille maximum du Frame Payload en fonction du Data Rate
443 Couche LoRa MAC Cette trame est destineacutee au Network Server Elle est authentifieacutee gracircce au champ MIC (Message
Integrity Protocol) selon la meacutethode expliqueacutee au paragraphe 416
Le protocole LoRa MAC est composeacute de
1 MAC Header Version de protocole et type de message
Type de Message Description 000 Join-Request
001 Join-Accept
010 Unconfirmed Data Up
011 Unconfirmed Data Down
100 Confirmed Data Up
101 Confirmed Data Down
110 Rejoin-request
111 Proprietary
Tableau 6 Les types de messages transmis en LoRaWAN
2 MAC Payload Contient tout le protocole applicatif
3 MIC Message Integrity Code pour lrsquoauthentification de la trame
444 Couche physique Modulation LoRa
Le choix du moment drsquoeacutemission des Devices LoRa se fait de faccedilon simple Lorsqursquoun eacutequipement
doit eacutemettre il le fait sans controcircle et ne cherche pas agrave savoir si le canal est libre Si le paquet a eacuteteacute
perdu il le retransmettra simplement au bout drsquoun temps aleacuteatoire La couche physique est
repreacutesenteacutee par lrsquoeacutemission de la trame suivante
Couche
Mac MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Figure 34 Trame LORA couche LORA MAC
| 35
Le Preacuteambule est repreacutesenteacute par 8 symboles + 425 Le temps du Preacuteambule est donc de 1225
Tsymbole
Len-tecircte (Header optionnel) est seulement preacutesent dans le mode de transmission par deacutefaut
(explicite) il est transmis avec un Coding Rate de 48 Il indique la taille des donneacutees le Coding Rate
pour le reste de la trame et il preacutecise eacutegalement si un CRC sera preacutesent en fin de trame
Le PHY Payload contient toutes les informations de la Couche LoRa MAC
Le CRC sert agrave la deacutetection drsquoerreur de la trame LoRa
445 Canaux et bandes de freacutequences et Data Rate (DR) Le LoRa utilise des bandes de freacutequences diffeacuterentes suivant les reacutegions du monde En Europe la
bande utiliseacutee est celle des 868 Mhz [ De 863 Mhz agrave 870 Mhz ] Le LoRaWAN deacutefinie les 8 canaux agrave
utiliser pour communiquer avec une Gateway suivant le tableau suivant
Canaux Spreading Factor Bandwidth 8681 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz SF7 250 kHz
8685 Mhz De SF7 agrave SF12 125 kHz
8671 Mhz De SF7 agrave SF12 125 kHz
8673 Mhz De SF7 agrave SF12 125 kHz
8675 Mhz De SF7 agrave SF12 125 kHz
8677 Mhz De SF7 agrave SF12 125 kHz
8679 Mhz De SF7 agrave SF12 125 kHz
Tableau 7 Canaux SF et Bandwidth de notre Gateway LoRaWAN
Une Gateway LoRa eacutecoute donc sur 8 canaux simultaneacutement avec les 6 Spreading Factor
diffeacuterents soit 48 combinaisons possibles
Comme nous lrsquoavons vu le Spreading Factor a des conseacutequences sur le deacutebit de la transmission Ces
deacutebits sont noteacutes DR (Data Rate) et sont normaliseacutes de DR0 agrave DR6
PHY Payload
P octets Couche
Physique CRC
2 octets Header + Header CRC
( Optionnel ) 20 bits Preamble
Figure 35 Trame LORA couche Physique
| 36
Data Rate Spreading Factor Bandwidth DR 0 SF12 125 KHz
DR 1 SF11 125 KHz
DR 2 SF10 125 KHz
DR 3 SF9 125 KHz
DR 4 SF8 125 KHz
DR 5 SF7 125 KHz
DR 6 SF7 250 KHz
Tableau 8 Deacutenomination DR en fonction du SF et de la Bande Passante
446 Trame reccedilue et transmise par la Gateway LoRaWAN La Gateway reccediloit drsquoun cocircteacute un message radio moduleacute en LoRa et transmet de lrsquoautre cocircteacute une trame
IP agrave destination du Network Server
Coteacute interface Radio La Gateway reacuteceptionne une trame LoRaWAN et extrait le PHY Payload Celui-
ci est codeacute au format ASCII en base 64 (voir le paragraphe 541) La Gateway extrait aussi toutes les
informations utiles sur les caracteacuteristiques de la reacuteception qui a eu lieu SF Bandwidth RSSI Time
On Airhellipetchellip
Coteacute interface reacuteseau IP La Gateway transmet lrsquoensemble de ces informations dans un paquet IP
(UDP) au Network Server Les donneacutees transmises sont du texte en format JSON (voir paragraphe
447) La Gateway a donc bien un rocircle de passerelle entre le protocole LoRa drsquoun cocircteacute et un reacuteseau
IP de lrsquoautre
Internet
UDP IP
Device LoRa
Gateway
Network Server Modulation
LoRa
Passerelle LoRa Internet
Transmission Radio Internet
Figure 36 Rocircle de la Gateway LoRa
| 37
447 Le format JSON Le format JSON est un format texte composeacute drsquoune succession de couple nomvaleur Dans
lrsquoexemple de la figure preacuteceacutedente gw_id est un nom et eui-b827ebfffeae26f5 est la valeur
associeacutee Dans cette exemple la valeur est un string Les objets sont deacutelimiteacutes par un des accolades
et
Une valeur peut ecirctre
Un string exemple coding_rate 45
Un nombre exemple spreading_factor 12
Un objet exemple lora spreading_factor 12 air_time 2465792000
Un Boolean
Ethernet
Gateway
Modulation
LORA
Reacutecupeacuteration du PHY PAYLOAD en base 64
Reacutecupeacuteration des caracteacuteristiques de la transmission Canal SF CR hellip
IP (IP dest routereuthethingsnetwork)
UDP (Port dest 1700 Port source 1700)
Donneacutees applicatives (format JSON)
gw_id eui-b827ebfffeae26f5
payload QNAPvA6Ax3ECqHk4C8hfzuA==
lora
spreading_factor 12
bandwidth 125
air_time 2465792000
coding_rate 45
timestamp 2019-01-20T133746017Z
rssi -105
snr -162
dev_addr 0EBC0FD0
frequency 867100000
Internet Transmission Radio LORA
Figure 37 Passerelle (Gateway) LORAWAN
| 38
5 Mise en œuvre drsquoun reacuteseau LoRaWAN
51 Les diffeacuterents types de reacuteseaux Les reacuteseaux LoRaWAN peuvent ecirctre utiliseacute suivant deux meacutethodes
En utilisant les reacuteseaux LoRaWAN opeacutereacutes proposeacutes par les opeacuterateurs de teacuteleacutecoms
En utilisant votre propre reacuteseau LoRaWAN priveacute
511 Les reacuteseaux LoRaWAN opeacutereacutes Ce sont des reacuteseaux LoRaWAN proposeacutes par les opeacuterateurs Par exemple Objenious (filiale de
Bouyges) ou encore Orange Dans le cas de lrsquoutilisation des reacuteseaux opeacutereacutes lrsquoutilisateur a juste
besoin de srsquooccuper des Devices LoRa Les Gateways le Network Server et lrsquoApplication Server sont
geacutereacutes par lrsquoopeacuterateur
512 Les reacuteseaux LoRaWAN priveacutes Chacun est libre de reacutealiser son propre reacuteseau priveacute en impleacutementant sa propre Gateway pour
communiquer avec ses Devices LoRa Lrsquoimpleacutementation du Network Server et de lrsquoApplication Server
peuvent alors ecirctre envisageacutes de diffeacuterentes faccedilons
Network Server et Application serveur priveacutees Crsquoest le deacuteveloppeur qui les mets en place Dans
certaines Gateways une impleacutementation de ces deux serveurs est deacutejagrave proposeacutee Sinon il est
possible de la mettre en place Il existe des serveurs (Network et Application) open source crsquoest le
cas par exemple de LoRa Serveur [ wwwloraserverio ]
Une autre alternantive est httpsgithubcomgotthardplorawan-server
LoRaServer et lorawan-server sont deux applications Open Source
Network Server et Application Server en ligne Un certain nombre de Network Server et
drsquoApplication Server sont proposeacutes Ce sont des services payants ou avec des contreparties
Loriot [ wwwloriotio ]
ResIoT [ wwwresiotio ]
The Things Network [ wwwthethingsnetworkorg ] Crsquoest la solution que nous utiliserons
513 Les zones de couvertures
Les zones de couvertures des reacuteseaux opeacutereacutes sont mise agrave jour par les opeacuterateurs celle drsquoobjenious
est par exemple disponible ici httpsobjeniouscomreseau
Pour connaitre la zone de couverture de notre Gateway utiliseacutee avec TTN nous pouvons utiliser
lrsquoapplication TTN Mapper httpsttnmapperorg Lrsquoideacutee est de promener son Device LoRa associeacute
agrave un GPS dans la zone de couverture des Gateway qui nous entourent A chaque trame reccedilue par le
| 39
Serveur on note les coordonneacutees GPS du Device LoRa ainsi que la Gateway qui a transmis le
message Toutes ces informations sont alors retranscrites sur une carte
52 The Things Network (TTN)
521 Preacutesentation de TTN
Pour la suite nous utiliserons le Network Server et lrsquoApplication Server fourni par TTN
[wwwthethingsnetworkorg]
TTN est gratuit et Open Source En revanche le fait drsquoutiliser TTN impose agrave ceux qui enregistrent
des Gateways de les mettre agrave disposition agrave tous les autres utilisateurs de TTN Lrsquoobjectif est de
reacutealiser un reacuteseau global ouvert
522 Configuration de la Gateway A lrsquouniversiteacute nous avons deux Gateways LoRa (Marque EBDS) Elles sont toutes les deux situeacutees sur
le Campus de Technolac Une Gateway est agrave lrsquointeacuterieur du bacirctiment ISERAN et sert essentiellement
pour les Travaux Pratiques et formations Lrsquoautre est sur le toit du bacirctiment Chablais et est mise agrave
disposition du public via le service de TTN
Les deux Gateway eacutecoutent sur tous les canaux et sur tous les Spreading Factor SF7 gt SF12
Lrsquo IP de la Gateway LoRa agrave lrsquouniversiteacute (bacirctiment ISERAN) est 192168140196
Serveur DNS 1934812032 19348129137
Network Server (TTN) 137616868 routereuthethingsnetwork
Port Upstream 1700 Port Downstream 1700
523 Enregistrement des Gateways Appplication et Devices La configuration de TTN se fait en ligne La premiegravere opeacuteration agrave reacutealiser lorsqursquoune nouvelle
Gateway est deacuteployeacutee crsquoest de lrsquoenregistrer dans TTN
Enregistrement drsquoune Gateway LoRa TTN gt Console gt Gateway gt register gateway
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Figure 38 Scheacutema de notre application
| 40
Figure 39 Enregistrement dune Gateway LoRa sur TTN
Enregistrement drsquoune application TTN gt Console gt Application gt add application
Figure 40 Enregistrement dune application sur TTN
Enregistrement des Devices LoRa dans lrsquoapplication Nom de lrsquoapplication gt register device
Figure 41 Enregistrement des Devices LoRa dans une application
524 Configuration des Devices LoRa Lorsque nous avons enregistreacute des Devices LoRa dans TTN nous devons choisir entre les deux modes
drsquoauthentification Dans un premier temps nous utiliserons le mode le plus simple qui est ABP Nous
geacuteneacuterons dans TTN les DevAddr NetwkSKey et AppSKey
| 41
Figure 42 Configuration des Devices LoRa en ABP dans TTN
53 Mise en application Nous avons dans notre application 10 Devices LoRa drsquoenregistreacutes aduino0 agrave arduino9 Ils sont tous
configureacutes en ABP Les configurations des 10 Devices (DevAddr NetwkSKey et AppSKey) sont noteacutes
en commentaire dans le code de vous allez reacutecupeacuterer
Reacutecupeacuterer le code Arduino laquo RN2483-Arduino-LORAWANino raquo dans Moodle
Modifier votre configuration (DevAddr NetwkSKey et AppSKey) en fonction de votre
numeacutero de binocircme
Veacuterifier que votre Device LoRa arrive bien agrave transmettre des informations (Uplink) vers la
Gateway puis vers le Network Serveur de TTN (The Things Network)
54 Analyse des trames eacutechangeacutees
541 Utilisation de la base 64 Notre Gateway nous preacutesente le Payload PHY en base64 Lrsquoexplication de la meacutethode de
repreacutesentation en base 64 est fourni au travers drsquoun exemple Le code hexadeacutecimal 0x4869
repreacutesente nos donneacutees binaires que nous souhaitons transmettre en base 64
1 On eacutecrit les donneacutees agrave transmettre en binaire
2 On regroupe les eacuteleacutements binaires par des blocs de 6 bits Le nombre de bloc de 6 bits doit
ecirctre un multiple de 4 (minimum 4 blocs) Srsquoil manque des bits pour constituer un groupe de
6 bits on rajoute des zeacuteros
0x4869 = 0100 1000 0110 1001
| 42
3 Srsquoil manque des blocs pour faire un minimum de 4 blocs des caractegraveres speacuteciaux seront
ajouteacutes
4 Chaque groupe de 6 bits est traduit par le tableau suivant (Source Wikipeacutedia)
Figure 43 Codage en base 64
5 Si un bloc de 6 bits manque (ils doivent ecirctre un multiple de 4) on rajoute un ou plusieurs
compleacutements (caractegravere laquo = raquo )
Reacutesultat Le codage de 0x4869 en base 64 est laquo SGk= raquo
010010 000110 100100
On ajoute 00 pour avoir
6 bits dans le groupe
Bloc de 6 bits
010010 000110 100100
S G k
010010 000110 100100
S G k =
1er Bloc
2egraveme Bloc
3egraveme Bloc
4egraveme Bloc
| 43
542 Inteacuterecirct et inconveacutenient de la base 64 Lrsquoutilisation de la base 64 est un choix qui a eacuteteacute fait pour le protocole LoRa LoRaWAN afin de rendre
les donneacutees binaires lisibles Le problegraveme du code ASCII crsquoest qursquoil est composeacute drsquoun certain nombre
de caractegraveres non imprimables (EOF CR LFhellip) Pour eacuteviter ces soucis la base 64 ne comporte que
64 caractegraveres imprimables (voir tableau ci-dessus)
La restriction agrave 64 caractegraveres a cependant un inconveacutenient crsquoest que nous ne pouvons coder que 6
bits (26=64) au lieu de 8 La base 64 est donc moins efficace drsquoune faccedilon geacuteneacuterale
Nous cherchons agrave coder le code ASCII laquo AA raquo en base 64 Retrouver la deacutemarche en
montrant que le reacutesultat en base 64 est laquo QUE= raquo
543 Uplink Du Device LoRa au Network Server Le Network Server de TTN reccediloit des trames IP en provenance de la Gateway Comme nous lrsquoavons
vu preacuteceacutedemment un certain nombre drsquoinformations peuvent ecirctre retrouveacutees avec cette trame
(DevAddr SF Bandwidth etchellip) mais les donneacutees Applicatives sont bien sucircr chiffreacutees (avec
lrsquoAppkSKey) A ce niveau de reacuteception (sans connaitre lrsquoAppSKey) il nrsquoest donc pas possible de
comprendre la totaliteacute du message reccedilu
Imaginons que la trame IP reccedilue 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 45
timestamp 2019-03-05T140042448Z
rssi -82
snr 9
dev_addr 26011AD3
frequency 867300000
Le Network Server affiche donc les informations de la faccedilon suivante
Figure 44 Trame reacutecupeacutereacutee sur le laquo Network Server raquo de TTN
Nous retrouvons bien les valeurs fournies par la Gateway
timestamp ( agrave 1 heure pregraves en fonction du fuseau horaire)
| 44
frequency 8673 Mhz
modulation Lora
Coding Rate 45
data Rate SF 7 125 kHz (DR5)
air time 463 ms
Drsquoautres information proviennent de lrsquoanalyse du Payload Le Payload inscrit ici est le PHY Payload
Il y a donc une partie chiffreacutee (Frame Payload) mais les entecirctes sont en claires (voir paragraphe
441) Ce PHY Payload est laquo QNMaASYABwAP1obuUHQ= raquo Lorsque celui-ci est exprimeacute en
hexadeacutecimal au lieu de la base 64 il vaut laquo 40D31A01260007000FD686EE5074 raquo comme le montre
le Network Server de TTN
Figure 45 PHY Payload preacutesenteacute dans notre Network Server
Sa taille est bien de 14 octets (en hexadeacutecimal) comme preacuteciseacute sur la Figure 44
Nous reprenons le format de la trame LoRaWAN vu agrave la Figure 32 Nous pouvons alors retrouver
tous les champs de toute la trame
PHYPayload = 40D31A01260007000FD686EE5074
PHYPayload = MAC Header[1 octet] | MACPayload[] | MIC[4 octets]
MAC Header = 40 (Unconfirmed data up)
MACPayload = D31A01260007000FD6
Message Integrity Code = 86EE5074
MACPayload = Frame Header | Frame Port | FramePayload )
Frame Header = D31A0126000700
FPort = 0F
FramePayload = D6
Frame Header = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[015]
DevAddr = 26011AD3 (Big Endian)
FCtrl (Frame Control) = 00 (No ACK No ADR)
FCnt (Frame Counter) = 0007 (Big Endian)
FOpts (Frame Option) =
Vous pouvez veacuterifier lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN
(LoRaWAN packet decoder) httpsbitly2szdXtv
| 45
Figure 46 LoRaWAN packet decoder
544 Uplink Du Network Server agrave lrsquoApplication Server
Nous reprenons lrsquoexemple de la trame ci-dessus (Figure 45) Pour information les cleacutes NwkSKey et
AppSKey suivantes ont eacuteteacute utiliseacutee
NwkSKey E3D90AFBC36AD479552EFEA2CDA937B9
AppSKey F0BC25E9E554B9646F208E1A8E3C7B24
Le Network Server a deacutecodeacute lrsquoensemble de la trame Si le MIC est correct (authentification de la
trame par le NwkSKey) alors le Network Server va passer le contenu du message chiffreacute (Frame
Payload) agrave lrsquoApplication Server Dans notre cas le Frame Payload est (drsquoapregraves le deacutecodage effectueacute
au chapitre preacuteceacutedent)
FramePayload = D6
D6 est le contenu chiffreacute lorsqursquoil est deacutechiffreacute avec lrsquoAppSkey on trouve 01 Vous pouvez veacuterifier
lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN httpsbitly2szdXtv
A noter que lrsquoApplication Server recevra les donneacutees chiffreacutees seulement si le Device LoRa a bien
eacuteteacute enregistreacute On peut aussi veacuterifier ci-dessous que lrsquoApplication Serveur de TTN nous retourne bien
un payload (Frame Payload) de 01
Figure 47 Trame reacutecupeacutereacutee sur lrsquoApplication Server de TTN
time 2019-03-05T140042379279991Z
frequency 8673
modulation LORA
data_rate SF7BW125
coding_rate 45
gateways [
gtw_id eui-b827ebfffeae26f6
timestamp 2447508531
time
channel 4
rssi -82
snr 9
latitude 4563647
longitude 58721523
| 46
location_source registry
]
545 Simulation drsquoUplink dans lrsquoApplication Server
Dans beaucoup de situations nous souhaitons valider le fonctionnement de lrsquoApplication Server de
TTN ouet de notre propre Application Il est donc tregraves utile de pouvoir simuler lrsquoenvoi drsquoune trame
LoRa sur lrsquoApplication Server sans que celle-ci soit reacuteellement eacutemise par un Device LoRa Pour cela
un outil existe dans les Settings de chaque Device enregistreacute dans TTN Nous avons juste besoin de
speacutecifier le Frame Payload en clair en hexadeacutecimal et le numeacutero de Port
Figure 48 Simulation drsquoune trame envoyeacutee par un Device LoRa
546 Downlink De lrsquoApplication Server au Device LoRa La communication LoRa est bidirectionnelle Des donneacutees peuvent ecirctre transmis au Device LoRa
depuis lrsquoApplication Server Depuis TTN un outil existe dans les Settings de chaque Device
enregistreacute Lrsquointerface est repreacutesenteacutee ci-dessous
Figure 49 Transmission de donneacutees de lrsquo laquo Application Server raquo jusqursquoau Device LoRa
Replace scheduling Mode Par deacutefaut le Frame Payload transmis remplacera le Frame
Payload en attente (si il existe) Dans ce mode un seul Frame Payload est planifieacute
First scheduling Mode Le Frame Payload est mis en file drsquoattente en premiegravere position
Last scheduling Mode Le Payload est mis en file drsquoattente en derniegravere position
Une demande de confirmation peut ecirctre demandeacutee au Device LoRa pour qursquoil preacutecise srsquoil a bien reccedilu
les donneacutees Lrsquooption laquo confirmed raquo permet donc de speacutecifier le type de trame dans le MAC Header
(voir paragraphe 443) laquo Confirmed Data Down raquo ou laquo Unconfirmed Data Down raquo dans notre cas
| 47
6 La reacutecupeacuteration des donneacutees sur notre propre Application
Nous utiliserons agrave nouveau le Network Server et Application Server de The Things Network Jusqursquoici
nous nous sommes contenteacute de veacuterifier que les donneacutees de lrsquoutilisateur (Frame Payload) soient bien
arriveacutees agrave destination dans lrsquoApplication Server Il faut maintenant les reacutecupeacuterer avec notre propre
Application qui aura pour rocircle
De stocker et traiter les donneacutees
De les mettre agrave disposition de lrsquoutilisateur (Serveur Web par exemple)
Drsquoenvoyer des commandes de lrsquoutilisateur aux Devices LoRa si besoin (Flux Downlink)
Nous allons voir deux meacutethodes pour communiquer entre notre application et TTN
Le protocole HTTP POST
Le protocole MQTT
61 Reacutecupeacuteration des donneacutees en HTTP POST dans lrsquoApplication
611 Preacutesentation du protocole HTTP
Dans le monde de lrsquointernet le protocole HTTP est tregraves utiliseacute pour le dialogue entre un client et un
serveur web Classiquement le client (un navigateur web par exemple) fait une requecircte HTTP GET
et le serveur lui retourne le contenu de la page web demandeacutee
Dans notre cas la probleacutematique est diffeacuterente car le client doit modifier le contenu du serveur
avec les donneacutees envoyeacutees par le Device LORA La requecircte srsquoappelle HTTP POST Son nom indique
que le client va poster (et on pas reacutecupeacuterer) des donneacutees
Lrsquoutilisateur qui souhaite reacuteceptionner des donneacutees sur son serveur doit donc concevoir un serveur
HTTP capable de traiter des requecirctes HTTP POST [ requecircte noteacutee (1) sur la Figure 51 ] fournies par
TTN Dans cette configuration TTN jouera le rocircle de client et notre application le rocircle de serveur
Devices
LORA Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
HTTP POST
MQTT Internet
Figure 50 Structure globale drsquoun reacuteseau LORAWAN
| 48
Figure 51 Communication bidirectionnelle entre TTN et notre Application
A lrsquoinverse lrsquoutilisateur qui souhaite transmettre des donneacutees agrave destination du Device LoRa
(Downlink) doit ecirctre capable de fournir une requecircte HTTP POST [ requecircte noteacutee (2) sur la Figure 51
] vers TTN Dans cette configuration TTN jouera le rocircle de Serveur et notre application le rocircle de
client
612 Fonctionnement drsquoun client et drsquoun serveur HTTP POST Afin de bien comprendre le fonctionnement des requecirctes HTTP POST nous allons proceacuteder par
eacutetape Le premier test que nous effectuerons sera decorreacuteleacute de TTN Le principe est le suivant
Utilisation drsquoun serveur HTTP disponible sur le web geacuterant les requecirctes HTTP POST [
httpsrbasketsin ] ou [ httpsbeeceptorcom ] par exemple
Utilisation drsquoun client HTTP eacutemettant des requecirctes HTTP POST commande curl sous linux
ou logiciel Postman [ wwwgetpostmancom ] sous windows par exemple
Ce test nous permet de valider le fonctionnement drsquoun serveur HTTP POST et drsquoun client HTTP POST
Une fois que nous serons sucircr de leur fonctionnement nous les utiliserons avec TTN
The Things Network
Application
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 49
Figure 52 Validation dun server HTTP POST et drsquoun client HTTP POST
613 Test du serveur HTTP POST Nous utiliserons un serveur web proposeacute par httpsrbasketsin
Aller sur le site httpsrbasketsin et creacuteer un nouveau laquo Basket raquo Zone ougrave vous pourrez
visualiser les requecirctes qui ont eacuteteacute eacutemises vers votre serveur
A partir de maintenant toutes les requecirctes dirigeacutees vers lrsquoadresse creacuteeacute seront traiteacutees et
srsquoafficheront Dans le menu de configuration il est aussi possible de deacutefinir le contenu de la reacuteponse
qui sera fournie
Deacutefinir un format de reacuteponse pour les requecirctes HTTP POST avec un body personnaliseacute
614 Test du client HTTP POST On peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande (la commande cURL
srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN sous Windows
Commande cURL curl ndashX POST ndashd lsquorsquodonneacutees agrave envoyerrsquorsquo DuServeurHTTP
Logiciel Postman New gt Request gt Creacuteer une requecircte HTTP POST gt Send
Veacuterifier que les requecirctes HTTP POST sont bien reacutecupeacutereacutees sur votre serveur creacutee preacuteceacutedemment
615 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST
Maintenant que nous avons un serveur HTTP (POST) fonctionnel nous allons configurer TTN pour
jouer le rocircle du client et pour qursquoil envoie des requecirctes HTTP POST vers notre Serveur degraves qursquoune
donneacutee drsquoun Device LoRa est disponible Nous geacuterons donc ici le flux Uplink
Requecircte
HTTP POST
Reacuteponse
(contenu parameacutetrable)
Client HTTP (POST)
Server HTTP (POST) [ httpsrbasketsin ]
| 50
Figure 53 Reacutecupeacuteration des donneacutees sur notre Application
Dans TTN nous inteacutegrons un bloc appeleacute laquo HTTP Integration raquo permettant de jouer le rocircle de client
crsquoest-agrave-dire drsquoenvoyer des requecirctes HTTP POST agrave destination de notre nouveau Serveur HTTP
Lrsquointeacutegration se faire agrave partir de TTN gt Console gt Application gt Nom_de_votre_application gt
Integration
Figure 54 Ajout dun client HTTP POST dans TTN
Pour valider le fonctionnement de notre architecture nous pouvons soit
Envoyer une trame depuis un Device LoRa vers TTN
Simuler lrsquoenvoi drsquoune trame drsquoun Device LoRa vers TTN (gracircce agrave lrsquooutil proposeacute par TTN vu
paragraphe 545)
Dans les deux cas voici un exemple de requecircte POST reccedilue sur notre serveur HTTP
app_id test_app_lorawan_sylvainmontagny
dev_id stm32lorawan_1
hardware_serial 0056AF49877
port 1
counter 0
payload_raw qg==
metadata
Requecircte
HTTP POST
Server HTTP (POST) [ httpsrbasketsin ]
The Things Network (Client)
La requecircte contient le Frame Payload deacutechiffreacutee
agrave transmettre agrave lrsquoApplication
| 51
time 2019-01-24T15243703499298Z
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Comme nous pouvons le voir le contenu fourni agrave notre serveur est formateacute en JSON (voir
paragraphe 0) Voici quelques compleacutements drsquoinformation
payload_raw Frame Payload deacutechiffreacute crsquoest donc les donneacutees en clairs dans la base 64
downlink_url URL du serveur HTTP POST qui serviront agrave transmettre des donneacutees au Device
LoRa (flux Downlink)
611 Envoyer des donneacutees depuis notre Application avec HTTP POST
Lorsque nous avons ajouteacute le bloc laquo HTTP Integration raquo au paragraphe preacuteceacutedent nous avons aussi
implicitement activeacute la fonctionnaliteacute que TTN soit precirct agrave recevoir et agrave traiter les requecirctes HTTP
POST La seule information qursquoil nous manque est lrsquoadresse du server HTTP vers lequel il faut eacutemettre
les requecirctes Si on observe la trame reccedilue preacuteceacutedemment en provenance de TTN on srsquoaperccediloit que
dans la trame JSON reccedilu une URL (downlink_url) est speacutecifieacutee
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Crsquoest cette URL que nous devrons utiliser Nous allons nous placer dans la configuration suivante
Figure 55 Envoi de donneacutees agrave partir de notre Application
Comme preacuteceacutedemment on peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande
(la commande cURL srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN
Commande cURL curl ndashX POST ndashdata lsquo dev_id Identidiant_De_Votre_Device
payload_raw AQE= rsquo DuServeurHTTP
Logiciel Postman New gt Request gt HTTP POST puis Body gt Raw gt JSON
Requecircte HTTP POST vers serveur TTN laquo downlink_url raquo httpsintegrationsthethingsnetworUaeb8ypKieQ
Contenu de la requecircte
dev_id Identidiant_De_Votre_Device
payload_raw aGVsbG8=
The Things Network (Serveur)
POSTMAN (Client HTTP POST)
| 52
dev_id YourDeviceID
payload_raw aGVsbG8=
Vous devez envoyer le texte (payload_raw) en base 64 Dans lrsquoexemple ci-dessus laquo aGVsbG8= raquo
correspond agrave la chaine de caractegravere laquo hello raquo Vous pouvez utiliser les nombreux encodeurdecodeur
en ligne pour vous aider Le texte doit srsquoafficher sur votre moniteur seacuterie Arduino dans le cadre de
notre deacutemonstrateur sur Arduino
62 Reacutecupeacuteration des donneacutees avec MQTT dans lrsquoApplication
621 Preacutesentation du protocole MQTT
MQTT est un protocole leacuteger qui permet de srsquoabonner agrave des flux de donneacutees Plutocirct que
lrsquoarchitecture Client Serveur classique qui fonctionne avec des Requecirctes Reacuteponses MQTT est
baseacute sur un modegravele Publisher Subscriber La diffeacuterence est importante car cela eacutevite davoir agrave
demander (Requecircte) des donneacutees dont on na aucune ideacutee du moment ougrave elles vont arriver Une
donneacutee sera donc directement transmise au Subscriber degraves lors que celle-ci a eacuteteacute reccedilue dans le
Broker (serveur central)
Figure 56 Modegravele Publisher Subscriber du protocole MQTT
Pour recevoir les donneacutees appartenant agrave un Topic un Subscriber doit souscrire (comme son nom
lindique) au preacutealable sur ce Topic
MQTT est un protocole qui repose sur TCP Lencapsulation des trames sur le reacuteseau est donc la
suivante
Broker
Client
Publisher 1
Client
Publisher 2
Client
Subscriber
Topic
Tempeacuterature
Topic
Humiditeacute
| 53
Figure 57 Protocoles utiliseacutes pour la communication avec MQTT
On peut le veacuterifier par une capture de trame sur Wireshark
Figure 58 Capture dune trame MQTT avec Wireshark
On peut noter que le port TCP utiliseacute pour le protocole MQTT (non chiffreacute) est le 1883
Les Publishers et les Subscribers nrsquoont pas besoin de se connaitre
Les Publishers et les Subscribers ne sont pas obligeacute de srsquoexeacutecuter en mecircme temps
622 Connexion au Broker MQTT Nous nous inteacuteresserons essentiellement aux options de connexion qui permettront de geacuterer la
Qualiteacute de Service (QoS) Pour se connecter un client MQTT envoie deux informations importantes
au Broker
keepAlive Cest la peacuteriode la plus longue pendant laquelle le client Publisher ou Subscriber pourra
rester silencieux Au-delagrave il sera consideacutereacute comme deacuteconnecteacute
cleanSession Lorsque le Client et le Broker sont momentaneacutement deacuteconnecteacutes (au-delagrave du
keepAlive annonceacute) on peut donc se poser la question de savoir ce quil se passera lorsque le client
sera agrave nouveau connecteacute
Si la connexion eacutetait non persistante (cleanSession = True) alors les messages non transmis
sont perdus Quel que soit le niveau de QoS (Quality of Service)
Si la connexion eacutetait persistante (cleanSession = False) alors les messages non transmis
seront eacuteventuellement reacuteeacutemis en fonction du niveau de QoS Voir le chapitre 624
623 Qualiteacute de Service au cours dune mecircme connexion
A partir du moment ougrave le Client se connecte au Broker il est possible de choisir un niveau de fiabiliteacute
des transactions Le Publisher fiabilise leacutemission de ces messages vers le Broker et le Subscriber
fiabilise la reacuteception des messages en provenance du Broker Une parle ici du cas dune mecircme
connexion crsquoest-agrave-dire entre le moment ou le Client se connecte et le moment ougrave
Soit il se deacuteconnecte explicitement (Close connexion)
Soit il na rien eacutemis ni fait signe de vie pendant le temps keepAlive
TCP
MQTT
Reacuteseau
Transport
Couche Application
IP
| 54
Lors dune mecircme connexion la Qualiteacute de Service (QoS) qui est mise en œuvre deacutepend uniquement
de la valeur du QoS selon les valeurs suivantes
QoS 0 At most once (au plus une fois) Le premier niveau de qualiteacute est sans acquittement Le
Publisher envoie un message une seule fois au Broker et le Broker ne transmet ce message quune
seule fois aux Subscribers Ce meacutecanise ne garantit pas la bonne reacuteception des messages MQTT
QoS 1 At least once (au moins une fois) Le deuxiegraveme niveau de qualiteacute est avec acquittement
Le Publisher envoie un message au Broker et attends sa confirmation De la mecircme faccedilon le Broker
envoie un message agrave ces Subscriber et attends leurs confirmations Ce meacutecanisme garantit la
reacuteception des message MQTT
Cependant si les acquittements nrsquoarrivent pas en temps voulu ou srsquoils se perdent la reacuteeacutemission du
message dorigine peut engendrer une duplication du message Il peut donc ecirctre reccedilu plusieurs fois
QoS 2 Exactly once (exactement une fois) Le troisiegraveme niveau de qualiteacute est garanti une seule
fois Le Publisher envoie un message au Broker et attends sa confirmation Le Publisher donne alors
lrsquoordre de diffuser le message et attends une confirmation Ce meacutecanisme garantit que quel que
soit le nombre de tentatives de reacuteemission le message ne sera deacutelivreacute quune seule fois
La Figure 59 montre les trames eacutemises pour chaque niveau de QoS
Figure 59 Qualiteacute de Service en MQTT
La Figure 60 repreacutesentes les 3 captures de trames sur Wireshark repreacutesentant les 3 QoS (1 2 et 3)
que nous venons dexpliquer
Broker
QoS 0
Au plus une fois
Message supprimeacute apregraves envoi
PUBLISH
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Duplications possibles
PUBLISH
PUBLICH Ack
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Pas de duplication
PUBLISH
PUBLISH Receive
PUBLISH Release
PUBLISH Complete
| 55
Figure 60 Capture de trame avec QoS = 0 puis QoS = 1 puis QoS = 2
624 Qualiteacute de Service apregraves une reconnexion
La question que nous nous posons et de savoir ce que deviennent les messages publieacutes sur le Broker
lorsquun ou plusieurs Subscribers sont momentaneacutement injoignables Il est possible de conserver
les messages qui ont eacuteteacute publieacutes sur le Broker afin de les retransmettre lors de la prochaine
connexion Cette possibiliteacute de sauvegarde doit ecirctre activeacutee agrave louverture de connexion gracircce au flag
cleanSession = 0 La connexion sera alors persistante crsquoest-agrave-dire que le Broker enregistre tous les
messages quil na pas reacuteussi agrave diffuser au Subscriber
Le Tableau 9 reacutesume leffet du flag cleanSession et du QoS
Clean Session Flag Subscriber QoS Publisher QoS Comportement True ( = 1) 0 1 2 0 1 2 Messages perdus
False ( = 0 ) 0 0 1 2 Messages perdus
False (= 0 ) 0 1 2 0 Messages perdus
False (= 0 ) 1 2 1 2 Tous les messages sont retransmis
Tableau 9 Qualiteacute de Service en fonction de la valeur du QoS et du flag cleanSession
625 Les Topics du protocole MQTT Les chaicircnes deacutecrivant un sujet forment une arborescence en utilisant la barre oblique comme
caractegravere de seacuteparation La Figure 61 et le Tableau 10 donne un exemple dorganisation de Topic
Figure 61 Exemple de hieacuterarchie de Topic MQTT
Niveau 3
Niveau 2
Niveau 1 Maison
Chambre
Temperature Humidite Bruit
Salon
Temperature
| 56
Nom du Topic Deacutetail du Topic MaisonChambreTemperature La tempeacuterature de la chambre de la maison
MaisonChambreBruit Le bruit de la chambre de la maison
MaisonSalonTemperature La tempeacuterature du Salon de la maison
Tableau 10 Exemple de Topic
Un client peut sabonner (ou se deacutesabonner) agrave plusieurs branches de larborescence agrave laide de
jokers englobant plusieurs Topics Deux caractegraveres jokers existent
Le signe plus + remplace nimporte quelle chaine de caractegravere sur le niveau ougrave il est placeacute
Le diegravese remplace nimporte quelle chaine de caractegravere sur tous les niveaux suivants Il
est obligatoirement placeacute agrave la fin
Nom du Topic Deacutetail du Topic Maison+Temperature Les tempeacuteratures de toutes les piegraveces de la maison
MaisonChambre La tempeacuterature lhumiditeacute et le bruit de la chambre de la maison
Tableau 11 Exemple de Topic
626 Mise en place drsquoun Broker MQTT Afin de bien comprendre le fonctionnement du protocole de MQTT on reacutealise des tests
indeacutependamment de TTN Nous allons mettre en place
Un Broker Mosquitto httpstestmosquittoorg
Un client Publisher MQTT Box sur Windows
Un client Subscriber MQTT Box sur Windows
Figure 62 Test du protocole MQTT
MQTT Client (Subscriber)
MQTT Client (Publisher)
Publish
Subscribe
BROKER (Mosquitto)
| 57
Le Broker MQTT est commun agrave tout le monde Nous pouvons soit le reacutealiser nous-mecircme soit utiliser
un Broker MQTT public de test Nous utiliserons le Broker de test de Mosquitto disponible sur
httpstestmosquittoorg Drsquoautres sont eacuteventuellement disponibles en cas de problegraveme par
exemple httpwwwmqtt-dashboardcom
Si nous deacutecidions de le reacutealiser nous-mecircme agrave lrsquoaide drsquoune Raspberry Pi (par exemple) Lrsquoinstallation
se ferait en deux lignes de commande
apt-get install mosquito Installation
sudo systemctl start mosquittoservice Lancement du service
Il est neacutecessaire drsquoinstaller mosquitto-clients si on souhaite que le Raspberry PI joue aussi le rocircle de
client ce qui nrsquoest pas notre cas
627 Mise en place drsquoun Publisher et drsquoun Subscriber MQTT Lancer le logiciel MQTTBox
MQTTBox gt Create MQTT Client
Dans ce client les seuls champs indispensables sont
Protocol MQTT TCP
Host testmosquittoorg
Figure 63 Configuration dun Client MQTT dans MQTT Box
Tester lrsquoenvoi et la reacuteception sur les Topics de votre choix
628 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT La reacutecupeacuteration des donneacutees fait reacutefeacuterence au flux Uplink Dans ce cas
TTN joue le rocircle de client Publisher
TTN joue aussi le rocircle de Broker
Notre application joue le rocircle de Subscriber
Nous pouvons donc repreacutesenter lrsquoapplication globale par le scheacutema suivant
| 58
Figure 64 Publisher et Subscriber dans en MQTT avec TTN
La publication est repreacutesenteacutee par la trame MQTT (1)
La souscription est repreacutesenteacutee par la trame MQTT (2)
Le client Publisher eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box mais cette fois avec la configuration suivante
Protocol mqtt tcp
Host Crsquoest lrsquoIP du Broker vers lequel il faut se connecter Dans notre cas il srsquoagit de celui
de TTN dont lrsquoadresse est euthethingsnetwork
Username La connexion vers le broker MQTT est soumis agrave une authentification Username
Password Dans notre cas le Username correspond au nom de notre application crsquoest-agrave-
dire seminaire_lorawan Si vous avez choisi une autre applicationil faut bien mettre la
votre
Password Le Password est nommeacute laquo Access Key raquo par TTN Elle vous sera donneacutee par
lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application vous
trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt Overview
Figure 65 Access Keys de lapplication dans TTN
The Things Network (Application Server)
BROKER
Application
The Things Network (Network Server)
Publish (1 )
[ Flux Uplink ]
Subscribe (2 )
[ Flux Uplink ]
| 59
Figure 66 Configuration du Client dans MQTT Box
Le client MQTT eacutetant configureacute il est maintenant capable de se connecter au Broker Il reste donc agrave
deacutefinir le fait que le client sera Subscriber Les informations que recevra le Subscriber deacutependent du
Topic auquel nous souscrivons Voici les Topic disponibles sur le Broker de TTN
ltAppIDgt correspond au nom de votre Application
ltDevIDgt correspond au nom de votre Device LoRa
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink ltAppIDgtdevicesltDevIDgtup
[Donneacutees] Flux Downlink ltAppIDgtdevicesltDevIDgtdown
[Activation Events] Activation dun Device ltAppIDgtdevicesltDevIDgteventsactivations
[Management Events] Creacuteation dun Device ltAppIDgtdevicesltDevIDgteventscreate
[Management Events] Update dun Device ltAppIDgtdevicesltDevIDgteventsupdate
[Management Events] Suppression dun Device ltAppIDgtdevicesltDevIDgteventsdelete
[Downlink Events ] Message programmeacute ltAppIDgtdevicesltDevIDgteventsdownscheduled
[Downlink Events ] Message envoyeacute ltAppIDgtdevicesltDevIDgteventsdownsent
[Erreurs] Uplink erreurs ltAppIDgtdevicesltDevIDgteventsuperrors
[Erreurs] Downlink erreurs ltAppIDgtdevicesltDevIDgteventsdownerrors
[Erreurs] Activations erreurs ltAppIDgtdevicesltDevIDgteventsactivationserrors
Tableau 12 Topics enregistreacutes dans TTN
Dans un premier temps nous souscrivons au Topic +devices+up Cela signifie que nous
souscrivons agrave tous les Devices LoRa de toutes nos applications pour le flux Uplink
Figure 67 Configuration du Subscriber
Les eacuteleacutements eacutemis par le Broker seront alors afficheacutes dans MQTTBox La
| 60
Figure 68 Trame LoRaWAN reccedilu sur le Subscriber MQTT
Ces donneacutees sont eacutecrites en JSON nous pouvons les remettre en forme
applicationID3
applicationNamemyApplication
deviceNamearduino0
devEUI0056xxxxxxxxx877
txInfo
frequency868500000
dr5
adrfalse
fCnt792
fPort15
dataSGVsbG8=
Le Frame Payload deacutechiffreacute est fourni dans le champ data en base 64 La valeur fournie par
dataSGVsbG8= correspond bien agrave la chaine de caractegravere hello que nous avons eacutemise avec le
Device LoRa
629 Envoyer des donneacutees depuis notre Application avec MQTT
Lrsquoenvoi des donneacutees fait reacutefeacuterence au flux Downlink Dans ce cas
Notre application joue le rocircle de Publisher
TTN joue le rocircle de Broker
TTN joue aussi le rocircle de client Subscriber
| 61
La publication est repreacutesenteacutee par la trame MQTT (3)
La souscription est repreacutesenteacutee par la trame MQTT (4)
Le client Subscriber eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box Le rocircle de client dans MQTT Box a eacuteteacute faite au
paragraphe 628 Il nous reste simplement agrave ajouter le rocircle de Publisher La configuration est la
suivante
Topic du Subscriber seminaire_lorawandevicesarduino0down ougrave seminaire_lorawan
est agrave remplacer par le nom de votre application et arduino0 par le nom du Device LoRa vers
lequel vous souhaitez envoyeacute une donneacutee (Voir chapitre 628 pour comprendre les Topics)
Le Payload doit ecirctre au format JSON Lrsquoexemple suivant envoie laquohello raquo
payload_raw aGVsbG8=
The Things Network (Application Server)
BROKER
Application
Publish (3)
[ Flux Downlink ]
The Things Network (Network Server)
Subscribe (4)
[ Flux Downlink ]
| 62
Figure 69 Configuration du Publisher
Vous devriez voir les donneacutees arriver sur votre Device LoRA
| 63
7 Creacuteation de notre propre Network et Application Server
711 Objectifs Lors de la mise en œuvre du reacuteseau LoRaWAN au chapitre 52 nous avons utiliseacute TTN (The Things
Network) pour jouer le rocircle de Network Server et drsquoApplication Server Pour de multiples raisons
Seacutecuriteacute autonomie coucircthellipil peut ecirctre inteacuteressant de monter soi-mecircme un Network Server et un
Application Server Cela est possible seulement si vous posseacutedez vos propres Gateway puisque
celles-ci devront forwarder leur paquet agrave destination preacutecise Il faudra donc les reconfigurer pour
qursquoelles pointent vers votre nouvelle architecture
712 Preacutesentation de LoRaServer LoRaServer [ wwwloraserverio ] est un projet Open-Source reacutepondant exactement au besoin que
nous avons Nous lrsquoutiliserons sur une cible Raspberry PI En reacutealiteacute il peut souvent ecirctre mise en
place dans le mecircme systegraveme que la Gateway surtout si celle-ci est elle-mecircme agrave base de RPI Les
Gateway EBDS que nous posseacutedons possegravedent drsquoailleurs un Network Server et un Application Server
que nous aurions pu utiliser Neacuteanmoins pour des raisons peacutedagogiques il est inteacuteressant de
seacuteparer les systegravemes pour bien diffeacuterencier les probleacutematiques
Attention il y a une ambiguiumlteacute dans la deacutenomination des entiteacutes logiciels de LoRaServer
LoRaServer (sans espace entre le mot LoRa et Server) est le nom du projet global En
revanche LoRa Server (avec un espace) est le nom du service qui joue le rocircle du Network
Server
Lrsquoarchitecture et le fonctionnement de LoRaServer est preacutesenteacutee dans sa documentation par le
scheacutema suivant
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Raspberry PI
Figure 70 Architecture globale de notre reacuteseau loRaWAN
| 64
Figure 71 Architecture deacutetailleacutee de LoRaServer
On srsquoattends agrave voir uniquement un Network Server (LoRa Server) et un Application Server (LoRa App
Server) mais ce scheacutema est plus complexe Il demande un certain nombre drsquoexplications pour bien
comprendre ce que nous allons installer et la faccedilon dont nous lrsquoutiliserons par la suite
713 Le laquo Packet Forwarder raquo (Gateway) Comme nous lrsquoavons vu au chapitre 412 les Gateways LoRa sont des passerelles entre la
modulation LoRa et un reacuteseau IP Pour reacutealiser cette passerelle un service nommeacute laquo UDP Packet
Forwarder raquo a eacuteteacute deacuteveloppeacute par Semtech httpsgithubcomLora-netpacket_forwarder Dans
ce dossier github un fichier nommeacute PROTOCOLTXT explique parfaitement ce protocole applicatif
qui travaille au-dessus de UDP
Figure 72 Protocole Uplink (PUSH_DATA du Packet Forwarder)
| 65
On remarque que les paquets sont envoyeacutes en UDP au Network Server dans une trame appeleacutee
PUSH_DATA Cette trame est acquitteacutee par le Network Server par une trame appeleacutee PUSH_ACK
Sur notre Network Server nous pouvons reacutealiser une capture de trame pour veacuterifier si le protocole
est bien celui preacutesenteacute dans le document
Figure 73 Trame captureacutee par Wireshark lors dun Uplink
Drsquoapregraves la capture preacuteceacutedente on remarque que le Packet Forwarder fonctionne bien avec UDP sur
le port 1700
Le contenu des donneacutees (champ Data) est deacutetailleacute dans le tableau suivant
Champ | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | random token
[3] | 3 | PUSH_DATA identifier = 0x00
[4] | 4-11 | Gateway unique identifier (MAC address)
[5] | 12-end | JSON object starting with ending with
Lrsquoobjet JSON de la transmission reacuteeacutecrit plus proprement est celui-ci
Figure 74 Analyse du champ Donneacutees du protocole laquo Packet Forwarder raquo
0000 02 f9 30 00 b8 27 eb ff fe ae 26 f5 7b 22 72 78 0amprx 0010 70 6b 22 3a 5b 7b 22 74 6d 73 74 22 3a 33 37 35 pk[tmst375 0020 35 30 30 35 38 31 39 2c 22 63 68 61 6e 22 3a 32 5005819chan2 0030 2c 22 72 66 63 68 22 3a 31 2c 22 66 72 65 71 22 rfch1freq 0040 3a 38 36 38 2e 35 30 30 30 30 30 2c 22 73 74 61 868500000sta 0050 74 22 3a 31 2c 22 6d 6f 64 75 22 3a 22 4c 4f 52 t1moduLOR 0060 41 22 2c 22 64 61 74 72 22 3a 22 53 46 37 42 57 AdatrSF7BW 0070 31 32 35 22 2c 22 63 6f 64 72 22 3a 22 34 2f 35 125codr45 0080 22 2c 22 6c 73 6e 72 22 3a 36 2e 35 2c 22 72 73 lsnr65rs 0090 73 69 22 3a 2d 31 2c 22 73 69 7a 65 22 3a 31 38 si-1size18 00a0 2c 22 64 61 74 61 22 3a 22 51 4e 4d 61 41 53 59 dataQNMaASY 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 ]
Ch
amp
[1
]
Ch
amp
[2
]
Ch
amp
[3
]
Ch
amp
[4
]
| 66
rxpk[ tmst3755005819
chan2
rfch1
freq868500000
stat1
moduLORA
datrSF7BW125
codr45
lsnr65
rssi-1
size18
dataQNMaASYAAQAPpyPZ955+SmY
]
Le champ data correspond au PHY Payload
De la mecircme faccedilon on retrouve la Trame drsquoacquittement
Figure 75 Trame captureacutee par Wireshark lors de lrsquoacquittement drsquoun Uplink
Champs | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | same token as the PUSH_DATA to acknowledge
[3] | 3 | PUSH_ACK identifier = 0x01
Nous retrouvons bien tous ces champs dans la trame Wireshark
714 LoRa Gateway Bridge Nous avons deacutecrit au chapitre preacuteceacutedent (713) le fonctionnement du Packet Forwarder Le
Network Server(Lora Server) que nous allons mettre en place aurait tregraves bien pu srsquointerfacer
directement agrave ce protocole Mais cela aurait plusieurs impacts dont un qui est important dans la
conception de logiciel Si le Packet Forwarder change ou si un autre type de Forwarder est utiliseacute
alors lrsquoutilisation du LoRa Server devient impossible Il a donc eacuteteacute choisi de creacuteer une eacutetape
intermeacutediaire Le Network Server que nous mettrons en plus utilisera le protocole MQTT plutocirct que
le protocole UDP packet Forwarder
En drsquoautres termes le LoRa Gateway Bridge est un service qui fera abstraction du Packet Forwarder
pour srsquointerfacer plus simplement avec le Network Server
715 LoRa Server (Network Server) Il srsquoagit de notre Network Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
413 Cependant il srsquointerfacera au protocole MQTT en recevant les informations agrave partir du
Broker au lieu de recevoir directement les trames en provenance de la Gateway
| 67
716 LoRa App Server (Application Server) Il srsquogit de notre Application Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
414
717 LoRa Geo Server Il srsquoagit drsquoun service qui permet drsquoutiliser certaines proprieacuteteacutes du protocole LoRa pour proposer un
service de geacuteolocalisation des Devices LoRa Nous ne lrsquoutiliserons pas dans notre cas
718 Application Il srsquoagit de notre Application qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre 415
Elle ne fait pas partie du projet LoRaServer crsquoest donc bien toujours agrave nous de proposer notre propre
Application
Figure 76 Les interfaces possibles entre LoRaServer et lrsquoApplication utilisateur
Comme nous pouvons le voir sur la figure preacuteceacutedente deux possibiliteacutes sont offertes pour interfacer
notre application JSON REST (incluant HTTP POST) et via un Broker MQTT Ces deux meacutethodes ont
deacutejagrave eacuteteacute traiteacutee au chapitre 61 (HTTP POST ) et au chapitre 62 (MQTT) Nous verrons aussi drsquoautres
possibiliteacutes pour personnaliser notre application au chapitre 7
72 Installation de LoRaServer
721 Mise en place de lrsquoenvironnement
Nous allons installer une carte SD avec la derniegravere version de Raspbian Nous ne deacutetaillerons pas la
deacutemarche pour cela car elles sont largement documenteacutees et mises agrave jour sur le site
wwwraspberrypiorg
Installer un carte SD avec la derniegravere version de Raspbian
Plutocirct que de fonctionner avec un clavier et une souris nous preacuteconisons de travailler agrave distance
avec la RPI via une connexion SSH Depuis quelques anneacutees Raspbian a supprimeacute le deacutemarrage du
service SSH au boot Heureusement il est possible de le reacuteactiver par la meacutethode suivante
Avec Windows ou Linux ouvrir la partition BOOT de votre carte SD et placer un fichier agrave la
racine nommeacute sshtxt (ou ssh)
Mettre la carte SD dans votre RPI et la deacutemarrer
| 68
Pour acceacuteder agrave la RPI en SSH depuis Windows nous utiliserons de preacutefeacuterence le logiciel
client MobaXterm mais tout autre client SSH est valable
Installer MobaXterm sur votre PC et connectez-vous agrave votre Raspberry PI
Lrsquoutilisation drsquoun espion de reacuteseau type Wireshark peut ecirctre inteacuteressant pour eacutetudier les trames qui
sont reccedilues et qui sont eacutemises Cela nous permettra de valider le fonctionnement des diffeacuterents
protocoles reacuteseau qui permettent de communiquer agrave la Gateway drsquoune part et agrave lrsquoApplication
drsquoautre part Nous utiliserons tshark
apt-get install tshark installation
tshark ndashn -i eth0 Exemple drsquoune analyse sur lrsquointerface wlan0
722 Installation sur la Raspberry PI La meacutethode drsquoinstallation de LoRaServer est documenteacutee sur le site web agrave lrsquoadresse suivante
[ httpswwwloraserverioguidesdebian-ubuntu ] Nous installerons le LoRa Gateway Bridge
le LoRa Server et le LoRa App Server
Apregraves lrsquoinstallation la configuration se fait par une interface graphique accessible par le reacuteseau sur
le port 8080
Si vous travaillez sur la RPI connectez-vous sur httplocalhost8080
Si vous travaillez agrave distance (SSH) connectez-vous sur httpIP_RPI8080
Les Usernames et Password par deacutefaut sont
Username admin
Password admin
Lrsquoeacutecran drsquoaccueil sera donc le suivant
Figure 77 Architecture globale apregraves installation de LoRaServer
Devices
Gateways LoRa
UDP Packet Forwarder
Application Server
LoRa App Server
Internet
Network Server
LoRa Server
LoRa Gateway Bridge
| 69
Figure 78 Ecran daccueil de LoRaServer apregraves authentification
71 Configuration de LoRa Server pour lUplink
711 Enregistrement drsquoune nouvelle Organisation
Pour enregistrer une nouvelle Organizations Organizations gt Create Puis entrer les configurations
suivantes
Figure 79 Enregistrement dun nouvelle Organisation
712 Enregistrement drsquoune instance du Network Server Pour enregistrer une nouvelle instance du Network Server Network Server gt Create Puis entrer
les configurations suivantes
| 70
Figure 80 Enregistrement dun nouveau Network Server
Dans lrsquoonglet Gateway Discovery il est possible drsquoactiver une option de deacutecouverte de Gateway aux
alentours Lorsqursquoelle est configureacutee le Network Server va envoyer une trame Downlink de
configuration de la Gateway lui ordonnant de reacutealiser des PING en LoRa La configuration du
Gateway Discovery preacutevoit de speacutecifier
Le nombre de fois par jour que les PING LoRa sont envoyeacutes
Le canal drsquoeacutemission
Le Data Rate (Voir paragraphe 445)
Un PING LoRa reccedilu sur une Gateway sera retransmis sur le Network Server (Lora Server) et une carte
sera afficheacutee
Lrsquoonglet TLS Certificates ne sera pas utiliseacute dans le cadre de notre deacutemonstration
713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) Il faut tout drsquoabord faire un enregistrement drsquoun laquo service-profile raquo Un laquo service profile permet de
faire la connexion entre le Network Server et les Applications que nous enregistrerons dans notre
Organisation Service-profiles gt Create
Service-profile name myServiceProfile
Network-server myNetworkServer
On laissera par deacutefaut toutes les autres options
Pour enregistrer une nouvelle Application Applications gt Create Puis entrer les configurations
suivantes
| 71
Figure 81 Enregistrement dune nouvelle Application
714 Enregistrement des Devices LoRa Il faut tout drsquoabord faire lrsquoenregistrement drsquoun Device-profile pour les Devices LoRa que vous
souhaitez connecter Dans notre cas nous ferons un premier test en speacutecifiant que nous utilisons
seulement le mode drsquoauthentification ABP (voir chapitre 431) Devices profile gt Create
Figure 82 Enregistrement dun laquo Device profile raquo
Nous pouvons alors creacuteer dans notre Application des nouveaux Devices Application gt
myApplication gt Create
| 72
Figure 83 Enregistrement dun nouveau Device LoRa
Dans la fenecirctre Activation on va alors configurer les 3 eacuteleacutements indispensables agrave une
authentification en APB Le DevAddr le NwkSKey et lrsquoAppSKey
Figure 84 Configuration de lenregistrement du Device LoRa (en ABP)
La configuration minimale de LoRaServer est maintenant termineacutee Nous pouvons donc brancher
un Device LoRa qui possegravede les les attribus (DevAddr NwkSKey et AppSKey) que nous avons
enregistreacute dans LoRaServer et le faire eacutemettre
715 Visualisation des trames reccedilues Les trames eacutemises par le Device LoRa vont donc parcourir le cheminement suivant
| 73
Figure 85 Reacutesumeacute du cheminement des trames LoRaWan en Uplink avec LoRaServer
En allant dans le Live Device Data (Application gt Nom_du_Device gt Live Device Data) on peut voir la
liste des trames reccedilues ainsi que les donneacutees applicatives deacutechiffreacutees
Figure 86 Reacuteception des trames des Devices LoRa
Figure 87 Analyse des trames des Devices LoRa
Dans lrsquoonglet LIVE LORAWAN FRAME nous pouvons voir les trames LORAWAN et si besoin eacutetudier
le contenu de ce qursquoelles contiennent En revanche les donneacutees applicatives sont ici chiffreacutees
UDP
Packet Forwarder
LoRa Bridge
Gateway LoRa Server LoRa App Server
Gateway
Server
Internet
| 74
Figure 88 Reacuteception des Trames LoRaWAN
72 Configuration de LoRaServer pour linteacutegration dApplication Nous avons vu dans le chapitre 718 que linterface entre LoRaServer et notre Application pouvait
ecirctre reacutealiseacutee soit par MQTT soit par les meacutethodes REST (HTTP POST) Nous avons deacutejagrave impleacutementeacute
et expliqueacute ces protocoles dans le cadre de son utilisation avec TTN Nous allons donc juste
configurer LoRaServer pour tester ces deux meacutethodes
721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST Nous utiliserons exactement la mecircme meacutethode que celle que nous avons utiliseacute avec TTN au
chapitre 615 Les diffeacuterentes Clients et Serveurs disponibles pour ces tests sont expliqueacutes au
paragraphe 612
Dans LoRaServer ajouter une inteacutegration HTTP LoRaServer gt Applications gt myApplication gt
Integrations gt Create gt HTTP Integration et la configurer comme le montre la Figure 89 Vous
remplacerez eacutevidement le lien par votre propre Endpoints
Figure 89 Configuration de linteacutegration HTTP POST dans LoRaServer
En envoyant des trames LoRa depuis votre Device vous devriez voir les contenus JSON sur votre
Endpoint
722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT Nous allons nous connecter au Broker MQTT de LoRaServer Pour cela nous utiliserons la mecircme
meacutethode que celle que nous avons utiliseacute avec TTN au chapitre 628 Nous utiliserons MQTTBox
comme nous lavons deacutejagrave fait au paragraphe 627
Le Broker de LoRaServer a enregistreacute les Topics suivant
[applicationID] correspond au nom de votre Application
[devEUI] correspond au nom de votre Device LoRa
| 75
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink application[applicationID]device[devEUI]rx
[Donneacutees] Flux Downlink application[applicationID]device[devEUI]tx
[Status] Statut dun Device application[applicationID]device[devEUI]status
[Ack] Acquittement des messages application[applicationID]device[devEUI]ack
[Erreurs] Erreurs application[applicationID]device[devEUI]error
Tableau 13 Topics enregistreacutes dans LoRaServer
| 76
8 Creacuteation de notre propre Application
81 Utilisation de Node-RED
811 Preacutesentation Node-RED est un outil de programmation graphique qui permet de faire communiquer les
peacuteripheacuteriques mateacuteriels drsquoun systegraveme sans eacutecrire de code De nombreux protocoles sont aussi pris
en charge au travers de bloc ( Node) qursquoil suffit de connecter entre eux pour reacutealiser simplement
une application Il peut srsquoexeacutecuter localement sur un PC ou sur des cibles embarqueacutees telle qursquoune
Raspberry PI (RPI)
Dans les deacutemonstrations que nous mettrons en œuvre nous utiliserons une RPI Par soucis de
simpliciteacute nous utiliserons les derniegraveres versions de Raspbian (systegraveme drsquoexploitation de la RPI) qui
integravegre drsquoorigine Node-RED Il nrsquoy a donc tregraves peu de chose agrave mettre en place pour arriver agrave mettre
en place une Application Nous pouvons travailler soit directement sur la RPI agrave lrsquoaide drsquoune souris-
clavier mais il est recommandeacute de travailler agrave distance avec une connexion SSH
812 Mise en place de lrsquoenvironnement La mise en place de la RPI avec le systegraveme drsquoexploitation Raspbian a eacuteteacute preacutesenteacute au chapitre 721
Vous pouvez reprendre la mecircme installation ou repartir sur une nouvelle
Il est possible de faire en sorte que Node-RED se lance directement au deacutemarrage gracircce agrave la
commande sudo systemctl enable noderedservice
Sil nest pas actif lancer Node-RED sur votre RPI node-red-start
Nous nous connectons au Node-RED de la RPI via un navigateur web sur le port 1880 en tapant dans
la barre dURL httpIP_Raspeberry_PI1880 Ce nous permet darriver agrave la fenecirctre suivante
Figure 90 Page daccueil de Node-RED
Il est possible de sinterfacer avec TTN avec les Nodes deacutejagrave disponibles gracircce au protocole HTTP
POST ou MQTT Neacuteanmoins nous pouvons avantageusement installer deux librairies speacutecifiques
Une qui facilite linterfaccedilage avec TTN
Une qui facilite la mise en place dinterface graphique
Installation des Nodes TTN
cd $HOMEnode-red
npm install node-red-contrib-ttn
Installation de Dashboard (interface graphique)
| 77
cd $HOMEnode-red
npm install node-red-dashboard
Il peut ecirctre necessaire de redeacutemarrer Node-RED pour prendre en compte linstallation de nos deux
Nodes
-----------------------------------
sudo apt-get install npm
sudo npm install -g npm
hash -r
cd ~node-red
npm install node-red-example node name
------------------------------------
813 Creacuteer une Application speacutecifique pour TTN Nous allons commencer par geacuterer le flux Uplink Apporter sur votre scheacutema un Node ttn uplink et
un Node Debug puis relier les Le Node ttn uplink nous permettra de configurer la
communication avec TTN en MQTT Le Node debug eacutecrira sur le terminal les informations brutes
qui seront reccedilu par le Node ttn uplink
Figure 91 Visualisation des trame publieacutees par TTN sur notre client MQTT
Double cliquer sur le Node ttn uplink pour le configurer comme la figure suivante
Le champ Name sera le nom du Node sur votre scheacutema Le champ Device ID est le device LoRa
concerneacute dans votre application De plus il faut entrer les caracteacuteristiques de votre application (Add
new ttn app) pour que Node-RED puisse sy connecter
Figure 92 Configuration du node ttn uplink
Configuration de votre nouvelle application
| 78
Figure 93 Identifiant et mot de passe de notre application
AppID Nom de votre application Dans notre cas seminaire_lorawan
Access Key Comme nous lavons deacutejagrave expliqueacute plus tocirct l Access Key vous sera donneacutee
par lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application
vous trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt
Overview
Le Node ttn uplink doit maintenant avoir le nom que vous avez configureacute Cliquer sur Deploy pour
lancer votre projet Le bloc ttn uplink doit maintenant ecirctre connecteacute agrave TTN Cela est speacutecifieacute
connected sous le bloc
Figure 94 Utilisation du Node TTN Uplink
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
Figure 95 Simulation de Uplink dans TTN
Vous devriez voir le reacutesultat dans la fenecirctre de Debug Par exemple pour le test denvoi de 31 32
correspondant au code ASCII des chiffres 1 et 2 vous devriez avoir la fenecirctre de Debug suivante
| 79
Figure 96 Reacutesultats obtenu dans la fenecirctre Debug apregraves la simulation dUplink
814 Creacuteation drsquoun Dashboard
Dans la mise en place de lenvironnement (chapitre 812) nous avons installeacute des Nodes
Dashboard qui vont nous permettre de reacutealiser une interface graphique tregraves simple et de la mettre
agrave disposition des utilisateurs via un des graphiques histogramme gauges afficheurshellip
Figure 97 Impleacutementation dune interface graphique dans Node RED
Linterface graphique que nous allons creacuteer sera constitueacutee donglet (tab) La mise en place des
composant se fait de la faccedilon suivante
Chaque eacuteleacutement graphique doit appartenir agrave un groupe de composant quil va falloir creacuteer
Chaque groupe de composant doit appartenir agrave un onglet (tab) quil va falloir creacuteer
Figure 98 Creacuteation dun groupe de composant
Figure 99 Creacuteation dun nouvel onglet dans le site web
Cliquer sur Deploy pour activer votre application
LURL pour joindre linterface graphique de votre site web est disponible sur ladresse
httpIP_Raspeberry_PI1880ui
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
| 80
Figure 100 Interface graphique du site web avec Node-RED
82 Programmation en PHP Maintenant que nous avons testeacute toute lrsquoarchitecture nous pouvons mettre en place une
application qui jouera deux rocircles
Un rocircle de Serveur HTTP POST reacutecupeacuterant les donneacutees en provenance de TTN
Un rocircle de Client HTTP POST qui geacuteneacuterera les requecirctes vers TTN
Un serveur web apache sur RPI heacuteberge cette application Linterface graphique du site web est
reacutealiseacute avec le template CSS proposeacute par Bootstrap [ httpsgetbootstrapcom ]
Figure 101 Architecture de notre application en PHP sur RPI
The Things Network
Notre Application
[ Serveur Apache sur Raspberry Pi ]
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 81
Nous allons lrsquoutiliser telle quelle Elle est juste proposeacutee agrave titre dexemple Lrsquoobjectif de cette
application est de geacuteneacuterer une ouverture fermeture de ruche agrave distance dans le cadre de projets
eacutetudiants du Master Electronique et Systegravemes Embarqueacutes de lUSMB [ httpscem-esetuniv-
smbfr ]
Figure 102 Application permettant de recevoir et deacutemettre des requecirctes HTTP POST
Configurer TTN pour pointer vers votre nouveau serveur et tester le flux montant et
descendant
| 82
9 Versions du document
Version 10 02022019
Version initiale
Version 20 23022019
Ajout drsquoun paragraphe Les systegravemes embarqueacutes dans lrsquoIoT En introduction
Compleacutement et ameacutelioration Ameacutelioration exercice eacutetalement de spectre
Correction Cacircblage Arduino
Ajout drsquoun paragraphe Fonctionnement de lrsquoArduino et ajout de librairies
Compleacutement et ameacutelioration Couche physique LoRa Ajout de 4 figures pour lrsquoexplication
de la modulation Chirp
Ajout drsquoun paragraphe sur les acronymes utiliseacutes au deacutebut du cours TTN LoRa MQTThellip
Compleacutement drsquoinformations sur les dB et dBm
Ajout LoRa Calculator
Version 30 8032019
Ajout de figure sur le rocircle de la Gateway LoRa
Ajout de paragraphe authentification avec le Network Server
Ajout de paragraphe sur le chiffrement avec lrsquoApplication Server
Ajout drsquoun sommaire en deacutebut de cours
Ajout de 2 scheacutemas ABP et OTAA
Retrait explication du deacutetail de la laquo Join Request raquo en OTAA Trop complexe attente de
reacutealisation drsquoun scheacutema plus explicite
Ajout drsquoun scheacutema sur lrsquoattaque par REPLAY
Ajout de paragraphe des diffeacuterents reacuteseaux LoRaWAN existants Opeacutereacutes et Priveacutes
Ajout des scheacutemas des trames LoRaWAN Physique LoRa MAC Application
Compleacutement drsquoinformation sur les Classes de Devices
Ajout drsquoun paragraphe sur la Gateway utiliseacutee pour le Downlink
Ajout drsquoun paragraphe sur le JSON
Compleacutement drsquoinformation sur le codage en Base64
Ajout drsquoinformation dans le deacutecodage des trames LoRaWAN
Restructuration des explications sur lrsquoenvoi et la reacutecupeacuteration des donneacutees en HTTPMQTT
Version 40 8032019
Ajout drsquoun chapitre Creacuteation de notre propre Application
Ajout drsquoun chapitre Creacuteation de notre propre Network et Application Server
Ajout drsquoune figure Visualisation des Chirps LoRa par SDR (Radio Logicielle)
Compleacutements drsquoinformation sur MQTT
Compleacutements dinformation sur les Topics de TTN en MQTT
| 10
2 Transmission radio et propagation
21 Les uniteacutes et deacutefinitions dB Rapport entre deux puissances Une atteacutenuation est repreacutesenteacutee par un nombre
neacutegatif (-) Un gain est repreacutesenteacute par un nombre positif (+)
Rapport de puissances en dB Rapport de puissance
+ 3 dB Multiplication par 2
- 3 dB Division par 2
0 dB Egaliteacute
+ 10 dB Multiplication par 10
- 10 dB Division par 10
Tableau 2 Comparaison entre les gains en dB et en proportion
dBi Gain theacuteorique drsquoune antenne
dBm Puissance rameneacutee agrave 1mW 0 dBm correspond agrave 1 mW
En reprenant la deacutefinition des dB remplir le tableau suivant
Puissance en dBm Puissance en mW
+ 3 dBm
- 3 dBm
+ 10 dBm
- 10 dBm
Tableau 3 Comparaison entre les puissances en dB et en mW
Le Talkie-Walkie a une puissance drsquoeacutemission de 2W Quelle est la puissance drsquoeacutemission
exprimeacutees en dBm
Sensibiliteacute Puissance minimale qursquoest capable de deacutetecter un reacutecepteur
RSSI Received Signal Strength Indication
SNR Signal over Noise Ratio
Un eacutemetteur transmet agrave une puissance de 13dBm en utilisant une antenne dont le gain
est de 2dBi Les pertes dans lrsquoair sont de 60 dB Lrsquoantenne reacuteceptrice qui possegravede un gain
de 2dBi est relieacutee agrave un reacutecepteur dont la sensibiliteacute est de -80 dBm Le signal pourra-t-il
ecirctre reccedilu
Le link Budget Crsquoest la quantiteacute de puissance que nous pouvons perdre avant drsquoarriver au
reacutecepteur tout en conservant une transmission fonctionnelle Autrement dit crsquoest la
puissance de lrsquoeacutemetteur moins la sensibiliteacute du reacutecepteur Dans lrsquoexemple preacuteceacutedent le
budget que nous avons agrave disposition est de 93dB
| 11
En LoRa nous avons un Link Budget de 157 dB
En LTE (4G) nous avons un Link Budget de 130 dB
Etude de la documentation drsquoun composant LoRa Le RN2483 est le composant radiofreacutequence que nous utiliserons dans notre transmission LoRa
Voici quelques une de ses caracteacuteristiques
Figure 3 Caracteacuteristiques principales du composant radiofreacutequence utiliseacute
Reprenez la deacutefinition du Link Budget et retrouver les 157 dB annonceacute dans cette
documentation
En LoRa plus le code drsquoeacutetalement est grand plus on est capable drsquoeacutemettre dans un milieu bruiteacute La
figure ci-dessous preacutesente les rapports signal sur bruit avec lesquels nous seront capable de reacutealiser
une transmission en fonction des Spreading Factor utiliseacutes
Figure 4 Influence du Spreading Factor sur le SNR acceptable
On remarque que pour un SF8 nous sommes capables drsquoeacutemettre avec un SNR de -10 dB On pourra
transmettre malgreacute le fait que le bruit est 10 fois supeacuterieur au signal
On remarque que pour un SF12 nous sommes capables drsquoeacutemettre avec un SNR de -20 dB On
pourra transmettre malgreacute le fait que le bruit est 100 fois supeacuterieur au signal
| 12
Cependant on remarque aussi que lrsquoutilisation drsquoun Spreading Factor plus eacuteleveacute augmente
consideacuterablement le nombre de symbole eacutemis (2egraveme colonne du tableau) Comme nous le verrons
plus tard cela impactera eacutevidement le temps de transmission
| 13
3 La couche physique LoRa
31 La modulation LoRa Comme nous lrsquoavons expliqueacute plus tocirct la modulation LoRa utilise lrsquoeacutetalement de spectre pour
transmettre ces informations Mais au lieu drsquoutiliser des codes drsquoeacutetalement (CDMA) elle utilise une
meacutethode appeleacutee Chirp Spread Spectrum La finaliteacute est toujours la mecircme Avoir plusieurs
transmissions dans le mecircme canal La conseacutequence sur le spectre est aussi la mecircme cela provoque
un eacutetalement du spectre
311 La forme du symbole (Chirp) Le signal eacutemis par la modulation LoRa est un symbole dont la forme de base est repreacutesenteacutee ci-
dessous Son nom (Chirp) vient du fait que ce symbole est utiliseacute dans la technologie Radar (Chirp
Compressed High Intensity Radar Pulse)
Figure 5 Symbole de la modulation LoRa (source Wikipeacutedia)
La freacutequence de deacutepart est la freacutequence centrale du canal moins la Bande Passante diviseacutee par deux
La freacutequence de fin est la freacutequence centrale plus la Bande Passante diviseacutee par deux
La freacutequence centrale est appeleacutee le canal
La bande passante est la largeur de bande occupeacutee autour du canal
On considegravere une eacutemission sur la freacutequence centrale 868 Mhz avec une Bande Passante
de 125 kHz Donner la freacutequence de deacutebut et la freacutequence de fin du sweep
Freacutequence de deacutebut
Freacutequence de fin
Pour faciliter la repreacutesentation de ce symbole on utilise plutocirct un graphique TempsFreacutequence de
la forme suivante
| 14
Figure 6 Forme du symbole de base (CHIRP)
En LoRa chaque symbole repreacutesente un certain nombre de bits transmis La regravegle est la suivante
Nombre de bits transmis dans un symbole = Spreading Factor
Par exemple si la transmission utilise un Spreading Factor de 10 (SF10) alors un symbole repreacutesente
10 bits
Crsquoest-agrave-dire qursquoagrave lrsquoeacutemission les bits sont regroupeacutes par paquet de SF bits puis chaque paquet est
repreacutesenteacute par un symbole particulier parmi 2119878119865formes de symboles possibles
Sur la figure suivante voici un exemple theacuteorique drsquoune modulation en SF2 agrave 868 Mhz sur une
bande passante de 125 kHz Chaque symbole repreacutesente donc 2 bits
Figure 7 Symboles eacutemis en Modulation LoRa (Cas theacuteorique en SF2)
Exemple
On considegravere la suite binaire suivante 0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Le Spreading Factor utiliseacute est SF10
Nous regroupons donc les bits par paquet de 10 Chaque paquet de 10 bits sera repreacutesenteacute par un
symbole (sweep) particulier Il y a 1024 symboles diffeacuterents pour coder les 1024 combinaisons
binaires possibles (210)
Freacutequence
Temps
868 000 000 Hz
868 062 500 Hz
Un symbole Un symbole
867 937 500 Hz
Temps
868 000 000 Hz
867 937 500 Hz
Symbole 0
Bits laquo 00 raquo
Symbole 1
Bits laquo 01 raquo
Symbole 2
Bits laquo 10 raquo Symbole 3
Bits laquo 11 raquo
12
5 k
Hz
868 062 500 Hz
| 15
Figure 8 Emission des Chirp en LoRa
Avec un outils drsquoanalyse spectrale actif pendant lrsquoeacutemission LoRa drsquoun Device on peut afficher les
successions de symbole qui sont envoyeacutes Cette oscillogramme a eacuteteacute reacutealiseacute agrave lrsquoaide drsquoun SDR
(Software Digital Radio)
Figure 9 Visualisation des Chirps LoRa reacuteellement eacutemis pendant une transmission
312 Dureacutee drsquoeacutemission drsquoun symbole En LoRa la dureacutee drsquoeacutemission de chaque symbole (Chirp) deacutepend du Spreading Factor utiliseacute Plus le
SF est grand et plus le temps drsquoeacutemission sera long Pour une mecircme bande passante le temps
drsquoeacutemission drsquoun symbole en SF8 est deux fois plus long que le temps drsquoeacutemission drsquoun symbole en
SF7 Ainsi de suite jusqursquoagrave SF12
0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Envoi de 1 Chirp Envoi de 1 Chirp Envoi de 1 Chirp
Transmission Transmission Transmission
| 16
Figure 10 Temps drsquoeacutemission drsquoun symbole (Chirp) en fonction du SF
En revanche le temps drsquoeacutemission drsquoun symbole est inversement proportionnel agrave la bande passante
119879119904 =2119878119865
119861119886119899119889119908119894119889119905ℎ Le deacutebit des symboles est donc de
1
119879119878= 119865119904 =
119861119886119899119889119908119894119889119905ℎ
2119878119865 En toute logique plus la
bande passant est eacuteleveacute plus le deacutebit des symboles sera eacuteleveacute Comme chaque symbole comprend
SF bit on retrouve alors le deacutebit binaire
119863119887 = 119878119865119861119886119899119889119908119894119889119905ℎ
2119878119865
Plus le Spreading Factor sera eacuteleveacute plus le deacutebit binaire sera faible
Plus la Bande Passante sera eacuteleveacutee plus le deacutebit binaire sera fort
Exemple Drsquoapregraves la formule du deacutebit binaire trouver le deacutebit pour les deux cas suivants
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
32 Coding Rate Le Coding Rate est un ratio qui augmentera le nombre de bits agrave transmettre afin de reacutealiser de la
deacutetection correction drsquoerreur Dans le cas drsquoun CR = 4 8 il y aura 8 bits transmis reacuteellement agrave
chaque fois que nous souhaitons transmettre 4 bits Dans cette exemple cela provoque une
transmission drsquoun nombre de bit multiplieacute par 2
SF7
Freacutequence
Temps
Freacutequence centrale
Freacutequence haute
Temps drsquoun symbole eacutemit en SF 12
Freacutequence basse
SF8
SF9
SF10
SF11
SF12
Temps drsquoun symbole eacutemit en SF 11
| 17
Figure 11 Influence du Coding Rate sur le nombre de bits ajouteacute
Si on reprend lrsquoexemple preacuteceacutedent avec un CR de 4 5 nous avons une augmentation de 125 du
nombre de bits agrave transmettre Redonner la deacutebit en prenant en compte le CR
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
La documentation du composant RN2483 donne les deacutebits en fonction du Spreading Factor
la Bande Passante et le Coding Rate Veacuterifier la coheacuterence du reacutesultat avec votre calcul
preacuteceacutedent
Figure 12 Deacutebit en fonction des paramegravetres de la transmission LoRa
33 Utilisation du LoRa Calculator Le logiciel laquo LoRa Calculator raquo est un petit exeacutecutable permettant de simuler une transmission LoRa
en fonction des caracteacuteristiques saisies Canal SF CR etchellip Il est teacuteleacutechargeable agrave lrsquoadresse
suivante httpsbitly2TyloAh
| 18
Figure 13 Le logiciel LoRa Calculator
En reprenant lrsquoexemple preacuteceacutedent (SF7 Bande Passante 125 kHz CR 45) veacuterifier les
calculs du laquo Equivalent Bitrate raquo
34 Time On Air La norme LoRaWAN impose qursquoun Device LoRa ne transmette pas plus de 1 du temps Cela est
repreacutesenteacute par un Duty Cycle Par exemple un Duty Cycle de 1 signifie que si jrsquoeacutemet pendant 1 je
ne dois plus eacutemettre pendant 99 quel que soit lrsquouniteacute de temps utiliseacutee
En reprenant les exemples preacuteceacutedents quels sont les deacutebits moyens si on prend en compte
le laquo Time On Air raquo
Cas 1 Pour SF7 et 125 khz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
Dans le logiciel laquo LoRa Calculator raquo (onglet laquo Energy Profile raquo) nous pouvons estimer la
dureacutee de vie drsquoune batterie Nous prenons lrsquoexemple drsquoun releveacute de tempeacuterature dans un
bacirctiment avec les caracteacuteristiques suivantes
| 19
SF CR Bande Passante etc Nous nous placcedilons dans le cas 1 des exemples preacuteceacutedents
Le releveacute de tempeacuterature se fera toutes les 15 mins
La batterie est constitueacute de 3 petites piles bacirctons [ AAA LR03 ] 12V en seacuterie Soit 36 V
1000 mAh
35 Mise en œuvre LoRa en point agrave point Ce test sera reacutealiseacute avec des modules LoRa RN2483 (Microchip) et une carte microcontrocircleur
ARDUINO
Figure 14 Communication LoRa en Point agrave Point
Reacutealiser le cacircblage de votre module RN2483 suivant le tableau suivant
Connecteur Arduino Click Board RN2483
5V 5V
GND GND
11 RX
10 TX
Tableau 4 Cacircblage de lrsquoARDUINO et de la click Board RN2483
351 Utilisation de lrsquoIDE Arduino Lrsquoenvironnement Arduino est tregraves simple Nous allons reacutealiser un programme pour montrer son
fonctionnement
La connexion de la carte est effectueacutee agrave lrsquoaide drsquoun port USB qui eacutemule une liaison seacuterie
RS232 Il faut donc choisir le bon port Arduino IDE gt Outils gt Port
Pour creacuteer un nouveau programme (sketch) Arduino IDE gt Fichier gt Nouveau
Il y a deux parties dans un sketch
Une fonction setup() qui sera exeacutecuteacutee qursquoune seule fois au deacutemarrage
Une fonction loop() qui sera exeacutecuteacutee en boucle
Ecrire le code suivant
Emetteur
Reacutecepteur
UA
RT
UA
RT
| 20
void setup()
Serialbegin(9600)
void loop()
Serialprintln(hello word)
Compiler et Teacuteleacuteverser Croquis gt Teacuteleacuteverser
Voir la sortie sur la liaison seacuterie Outils gt Moniteur Seacuterie gt Choisir la vitesse de
transmission ici 9600 bauds (en bas agrave droite)
352 Validation du fonctionnement Deux binocircmes joueront le rocircle drsquoeacutemetteur tous les autres binocircmes seront en reacutecepteur
Reacutecupeacuterer les programmes dans Moodle dans le dossier laquo RN2483-Arduino-Point2Point raquo
Installer la librairie RN2483 Arduino IDE gt Croquis gt Inclure une bibliothegraveque gt Ajouter la
bibliothegraveque zip
Reacutepartissez les rocircles Emetteurs Reacutecepteurs et reacutecupeacuterer le programme LoraBlinkerRX ou
LoraBlinkerTX en fonction Les 2 binocircmes en eacutemission devront modifier le code du sketch
Arduino pour transmettre des donneacutees speacutecifiques afin de les diffeacuterencier [
loraSerialprintln(radio tx 30) ]
Validez la reacuteception des donneacutees eacutemises par les deux binocircmes qui transmettent des
donneacutees Ces donneacutees reccedilues sont eacutecrite agrave 57600 bauds sur le moniteur seacuterie de lrsquoArduino
353 Mise en valeur du Spreading Factor On srsquoaperccediloit dans la manipulation preacuteceacutedente que les Devices LoRa reccediloivent les donneacutees des deux
eacutemetteurs Nous allons conserver le mecircme canal drsquoeacutemission (8691 Mhz) mais un des deux
eacutemetteurs va modifier son laquo Spreading Factor raquo La salle sera donc seacutepareacutee en deux groupes
1er groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF7
2egraveme groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF8
Validez la reacuteception des donneacutees eacutemises seulement pour le Spreading Factor que vous
utilisez
| 21
4 Le protocole LoRaWAN
Le LoRa est le type de modulation utiliseacute entre deux Devices ou entre un Device et une Gateway
Lorsque nous parlons de lrsquoensemble de la chaine de communication (Device Gateway Serveur) alors
nous parlons de communication LoRaWAN Nous allons voir lrsquoarchitecture drsquoun reacuteseau LoRaWAN
ainsi que les regravegles de ce protocole
41 Structure drsquoun reacuteseau LoRaWAN Nous retrouvons drsquoun cocircteacute le Device LoRa qui transmet une donneacutee Elle est reacuteceptionneacutee agrave lrsquoautre
extreacutemiteacute du reacuteseau par un Utilisateur La structure globale du reacuteseau LoRaWAN peut ecirctre
repreacutesenteacutee par la figure suivante
411 Les Devices LoRa Les Devices LoRa sont des systegravemes eacutelectroniques appartenant au monde de lrsquoIoT Faible
consommation faible taille faible puissance et faible taille
Ils possegravedent une radio LoRa permettant de joindre les Gateways Les Gateways ne sont pas
adresseacutees speacutecifiquement toutes celles preacutesentes dans la zone de couverture reccediloivent les
messages et les traitent
412 Les Gateways LoRa Elles eacutecoutent sur tous les canaux et sur tous les Spreading Factor Lorsqursquoune trame LoRa est reccedilue
elle transmet son contenu sur internet agrave destination du Network Server qui a eacuteteacute configureacute dans la
Gateway au preacutealable
Elle joue donc le rocircle de passerelle entre une modulation LoRa et une communication IP
Devices
LoRa Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
Internet Internet
Figure 15 Structure globale dun reacuteseau LORAWAN
| 22
Chaque Gateway LoRa possegravede un identifiant unique (EUI sur 64 bits)
413 Le Network Server
Le Network Server reccediloit les messages transmis par les Gateways et supprime les doublons
(plusieurs Gateway peuvent avoir reccedilu le mecircme message) Les informations transmises au Network
Server depuis les Devices LoRa sont authentifieacutes gracircce agrave une cleacute AES 128 bits appeleacutee Network
Session Key NwkSKey Nous parlons bien ici drsquoauthentification et non pas de chiffrement comme
nous le verrons plus tard
414 Application Server Il est souvent sur le mecircme support physique que le Network Server Il permet de dissocier les
applications les unes des autres Chaque application enregistre des Devices LoRa qui auront le droit
Devices Gateways Network
Server
Internet
Network Session Key (NwkSKey)
Authentification
Figure 17 Authentification entre le Device LoRa et le Network Server
Internet
UDP IP
Modulation
LoRa
Device LoRa
Gateway
Network Server
LoRaWAN
Modulation
LoRa
Passerelle LoRa Internet
Internet
UDP IP
LoRaWAN
Transmission Radio
Application Application
Figure 16 Le rocircle de la Gateway LoRa
| 23
de stocker leurs donneacutees (Frame Payload) Les message transmis agrave lrsquoapplication server sont chiffreacutes
gracircce agrave une cleacute AES 128 bits appeleacutee Application Session Key AppSKey
Le scheacutema suivant reacutesume lrsquoutilisation
De la Network Session Key (NwkSKey) pour lrsquoauthentification entre le Device LoRa et le
Network Server
De lrsquoApplication Session Key (AppSKey) pour le chiffrement entre le Device LoRa et
lrsquoApplication Server
Devices Gateways Network
Server Application
Server
Internet
Application Session Key (AppSKey)
Chiffrement
Figure 18 Chiffrement entre le Device LORA et lrsquoApplication Server
| 24
415 Application Web Serveur Cette application doit drsquoune part reacutecupeacuterer les donneacutees de lrsquoApplication Serveur Dans le cadre de
ce cours cela sera fait de deux faccedilons
Avec le protocole HTTP
Avec le protocole MQTT
Figure 20 Application Web Server
Figure 19 Authentification et chiffrement en LoRaWan
Devices Gateways
Network
Server Application
Server
Internet
Network Session Key
Application Session Key
Network
Server Application
Server
Application
Server Web
Utilisateur
Protocole
MQTT ou HTTP
Flux Uplink
Flux Downlink
| 25
Le flux habituel dans lrsquoIoT est le flux Uplink (flux montant) crsquoest-agrave-dire lrsquoeacutemission de donneacutees des
objets vers le serveur Comme nous lrsquoexpliquerons plus loin en LoRaWAN il est aussi possible de
transfeacuterer des donneacutees aux Device LoRa par un flux Downlink (flux descendant)
Drsquoautre part lrsquoapplication mettra agrave disposition les donneacutees aux utilisateurs sous forme par exemple
drsquoun serveur web drsquoune base de donneacutees et drsquoune visualisation graphique
416 Authentification avec le Network Server La Network Session Key (NwkSKey) sert agrave lrsquoauthentification entre le Device LoRa e le Network Server
Afin de reacutealiser cette authentification entre le Device et le Network Server un champ MIC (Message
Integrity Control) est rajouteacute agrave la trame Il est calculeacute en fonction des donneacutees transmises et du
NwkSkey A la reacuteception le mecircme calcul est effectueacute Si les cleacutes sont eacutequivalentes dans le Device et
dans le Network Server alors les deux MIC calculeacutes doivent correspondre
417 Chiffrement des donneacutees vers lrsquoApplication Server
LrsquoApplication Session Key (AppSKey) sert pour le chiffrement entre le Device LoRa et lrsquoApplication
Server Les donneacutees chiffreacutees seront alors deacutecodeacutees agrave la reacuteception sur lrsquoApplication Server srsquoil
possegravede la mecircme cleacute Si on reprend le scheacutema preacuteceacutedent les laquo donneacutees x raquo sont chiffreacutees
deacutechiffreacutees par le processus suivant
Donneacutees x chiffreacutees NwkSkey x
MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees
NwkSkey x
Trame eacutemise Trame reccedilue
Device LoRa Network Server
Si =
Alors la trame est authentifieacutee
MIC geacuteneacutereacute Emission MIC geacuteneacutereacute Reacuteception
MIC geacuteneacutereacute Reacuteception
Figure 21 Authentification dun Device LoRa par le Network Server
| 26
Figure 22 Chiffrement des donneacutees par lApplication Session Key
418 Combinaison de lrsquoauthentification et du chiffrement On peut maintenant repreacutesenter sur le mecircme scheacutema la construction de la trame LoRaWAN avec
drsquoune part lrsquoauthentification et drsquoautre part le chiffrement
Figure 23 Chiffrement puis Authentification
42 Classes des Devices LoRaWAN Les Devices LoRa sont classeacutes en 3 cateacutegories (A B C) en fonction de leur consommation et de leur
accessibiliteacute en Downlink crsquoest-agrave-dire la faciliteacute qursquoun utilisateur aura agrave transmettre une trame au
Device LoRa
421 Classe A (All) Minimal power Application Tous les Devices LoRaWAN sont de classe A Chaque Device peut transmettre (Uplink) agrave la Gateway
sans veacuterification de la disponibiliteacute du reacutecepteur Si la transmission eacutechoue elle sera reacuteeacutemise apregraves
un certain temps Cette transmission est suivie de 2 fenecirctres de reacuteception tregraves courtes La Gateway
peut alors transmettre pendant le laquo RX Slot 1 raquo ou le laquo RX Slot 2 raquo mais pas les deux
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Device LoRa
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Application Server
Donneacutees non chiffreacutees
AppSKey
Donneacutees chiffreacutees Entecircte
NwkSKey
MIC geacuteneacutereacute en eacutemission Trame transmise =
| 27
Figure 24 Slots de reacuteception pour un Device LoRa de classe A
Source de lrsquoimage httpszakelijkforumkpncom
La dureacutee des fenecirctres doit ecirctre au minimum la dureacutee de reacuteception drsquoun preacuteambule Un preacuteambule
dure 1225 Tsymbole et deacutepend donc du Data Rate (DR voir paragraphe 445 pour plus drsquoinformation
sur le DR) Lorsque qursquoun preacuteambule est deacutetecteacute le reacutecepteur doit rester actif jusqursquoagrave la fin de la
transmission Si la trame reccedilue pendant la premiegravere fenecirctre de reacuteception eacutetait bien agrave destination du
Device LoRa alors la deuxiegraveme fenecirctre nrsquoest pas ouverte
Premiegravere fenecirctre de reacuteception
Le Slot RX1 est programmeacute par deacutefaut agrave 1 seconde + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont les mecircme que ceux choisis lors de la phase drsquoeacutemission
(Uplink)
Seconde fenecirctre de reacuteception
Le Slot RX2 est programmeacute par deacutefaut agrave 2 secondes + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont configurables mais fixes
Un Device LoRa qui est uniquement de classe A ne peut pas recevoir srsquoil nrsquoa pas eacutemis Il
nrsquoest donc pas joignable facilement
422 Classe B (Beacon) Scheduled Receive Slot Les Devices de classe B ont le mecircme comportement que les Devices de classe A mais drsquoautres
fenecirctres de reacuteceptions sont programmeacutees agrave des peacuteriodes preacutecises Afin de synchroniser les fenecirctres
de reacuteception du Device LoRa la Gateway doit transmettre des balises (Beacons) de faccedilon reacuteguliegravere
| 28
Figure 25 Slots de reacuteception pour un Device LoRa de classe B
Source de lrsquoimage httpszakelijkforumkpncom
Un Device LoRa de classe B est joignable reacuteguliegraverement sans qursquoil soit neacutecessairement
obligeacute drsquoeacutemettre En revanche il consomme plus qursquoun Device de classe A
423 Classe C (Continuous) Continuously Listening Les Devices de classe C ont des fenecirctres de reacuteception constamment ouvertes entre 2 Uplinks Ces
Devices consomment donc beaucoup plus
Figure 26 Slots de reacuteception pour un Device LoRa de classe C
Source de lrsquoimage httpszakelijkforumkpncom
| 29
Un Device LoRa de classe C est joignable en permanence En revanche crsquoest la classe de
Device qui est la plus eacutenergivore
424 Quelle Gateway pour les flux Downlink
Nous avons donc vu que le fonctionnement classique du protocole LoRaWAN eacutetait de reacutecupeacuterer de
lrsquoinformation depuis le Device LoRa Crsquoest le flux Uplink
Dans le cas ougrave lrsquoutilisateur transmet des informations au Device LoRa (flux Downlink) on peut se
demander quelle Gateway sera choisie pour transfeacuterer les donneacutees au Device LoRa En effet
lrsquoendroit ougrave est situeacute le Device LoRa nrsquoest pas neacutecessairement connu agrave lrsquoavance
La Gateway utiliseacutee pour le Downlink est celle qui a reccedilu le dernier message du Device
LoRa Un message ne pourra jamais arriver agrave destination drsquoun Device LoRa si celui-ci nrsquoa
jamais transmis quel que soit sa classe A B ou C
43 Activation des Devices LoRa et seacutecuriteacute En LoRaWAN les trois eacuteleacutements indispensables pour la communication sont le DevAddr pour
lrsquoindentification du Device ainsi que deux cleacutes le NwkSKey pour lrsquoauthentification et lrsquoAppSKey
pour le chiffrement Deux meacutethodes sont possibles pour fournir ces informations agrave la fois au Device
LoRa et au serveur
Activation By Personalization APB
Over The Air Activation
431 ABP Activation By Personalization Crsquoest la plus simple des meacutethodes Crsquoest donc peut ecirctre celle que nous avons tendance agrave utiliser lors
drsquoun test de prototype et drsquoune mise en place de communication LoRaWAN
Le Device LoRa possegravede deacutejagrave le DevAddr lrsquoAppSKey et le NwkSKey
Le Network server possegravede deacutejagrave le DevAddr et le NwkSKey
Lrsquoapplication serveur possegravede deacutejagrave le DevAddr et le AppSKey
En ABP toutes les informations neacutecessaires agrave la communication sont deacutejagrave connues par le
Device LoRa et par le Serveur
| 30
432 OTAA Over The Air Activation Crsquoest la meacutethode qursquoil faut privileacutegier car crsquoest celle qui est la plus seacutecuriseacutee Le Device LoRa doit
connaitre le DevEUI lrsquoAppEUI et lrsquoAppkey Le Network Server doit lui connaitre la mecircme Appkey
Tous les eacuteleacutements noteacutes EUI (Extended Unique Identifier) sont toujours sur une taille de
64 bits
Gracircce agrave ces informations de deacutepart et une neacutegociation avec le Network Server (Join Request) le
Device LoRa et le serveur vont geacuteneacuterer les informations essentielles DevAddr NwkSKey et
AppSKey
Figure 28 Obtention du DevAddr NwkSKey et AppSKey en OTAA
DevEUI Unique Identifier pour le device LoRa (Equivalent agrave une MAC sur Ethernet)
Certains Device LoRa ont deacutejagrave un DevEUI fourni en usine
AppEUI Unique Identifier pour lrsquoapplication server
DevEUI
AppEUI
AppKey
Join
Request
DevAddr
NwkSKey
AppSKey
Network Server
Application Server
Devices 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 2
NwkSkey 2
AppSKey 2
Devices 2
DevAddr 2
NwkSkey 2
AppSKey 2
Paramegravetres stockeacutes sur le serveur
Paramegravetres programmeacutes
dans le composant
Figure 27 Parameacutetrage de DevAddr NwkSKey et AppSKey
| 31
AppKey AES 128 cleacute utiliseacutee pour geacuteneacuterer le MIC (Message Code Integrity) lors de la Join
Resquest Il est partageacute avec le Network server
NwkSKey Utiliseacute pour lrsquoauthentification avec le Network Server
AppSKey Utiliseacute pour le chiffrement des donneacutees
433 Seacutecuriteacute Les cleacutes AES 128 bits permettent le chiffrement des informations transmises en LoRaWAN Malgreacute
ce chiffrement une attaque connue en Wireless est celle du REPLAY Crsquoest-agrave-dire que le Hacker
enregistre des trames chiffreacutees circulant sur le reacuteseau LoRa pour les reacuteeacutemettre plus tard Mecircme si
le Hacker ne comprend pas le contenu (les trames sont chiffreacutees) les donneacutees qui sont transporteacutees
sont elles bien comprises par lrsquoApplication Server Des actions peuvent donc ecirctre reacutealiseacutees
simplement par mimeacutetisme
Pour eacuteviter cela la trame LoRaWAN integravegre un champ variable appeleacute laquo Frame Counter raquo Il srsquoagit
drsquoun nombre numeacuterotant la trame sur 16 ou 32 bits LrsquoApplication Server acceptera une trame
uniquement si le laquo Frame Counter raquo reccedilu est supeacuterieur au laquoFrame Counter raquo preacuteceacutedemment Donc
si le Hacker retransmet la trame telle qursquoelle le laquo Frame Counter raquo sera eacutequivalent donc la trame
sera refuseacutee Et comme la trame est chiffreacutee le Hacker nrsquoa pas moyen de savoir comment modifier
un champ de cette trame
Cette seacutecuriteacute impleacutementeacutee par les laquo Frame Counter raquo est inteacuteressante pour srsquoaffranchir drsquoune
attaque par REPLAY mais dans nos tests cela peut poser problegraveme En effet agrave chaque fois que nous
redeacutemarrons le microcontrocircleur notre laquo Frame Counter raquo revient agrave zeacutero alors que celui de
lrsquoApplication Server continue de srsquoincreacutementer Cela peut ecirctre reacutesolue par diffeacuterentes maniegraveres
1 Deacutesactivation du laquo Frame Counter Check raquo Dans certain Application Server cette option
peut ecirctre proposeacutee Bien sucircr il faudra garder en tecircte la faille de seacutecuriteacute que cela engendre
Network Server
Application Server
Devices LoRa
NwkSkey
AppSKey
NwkSkey
AppSKey Hacker
(1) (2)
(1) Ecoute
(2) Reacuteeacutemission
Figure 29 Attaque par REPLAY
| 32
Figure 30 Deacutesactivation du Frame Counter Check dans TTN
2 Utiliser lrsquoauthentification par OTAA au lieu de ABP En effet agrave chaque ouverture de session
en OTAA le laquo Frame Counter raquo est reacuteinitialiseacute coteacute serveur
3 Conserver la valeur du laquo Frame Counter raquo dans une meacutemoire non volatile et reacutecupeacuterer sa
valeur au deacutemarrage du Device LoRa
44 La Trame LoRa LoRaWAN
441 Les couches du protocole LoRaWAN
Lorsque nous avons fait une communication en Point agrave Point nous avons simplement utiliseacute la
couche physique de la modulation LoRa Lorsque nous souhaitons utiliser le protocole LoRaWAN
des couches protocolaires suppleacutementaires se rajoutent
Figure 31 Les couches protocolaires du LoRaWAN
Chaque couche rajoute un service Lors de lrsquoenvoi de la trame les donneacutees utilisateurs sont donc
encapsuleacutees dans chaque couche infeacuterieure jusqursquoagrave la transmission Le deacutetail de lrsquoensemble de la
trame LoRaWAN par couche est deacutecrit sur la figure Figure 32
LoRa Modulation
LoRa Mac
Application
Couche Physique
Couche Mac
Couche Application
| 33
442 Couche Application La couche Application accueille les donneacutees de lrsquoutilisateur Avant de les encapsuler elles sont
chiffreacutees avec lrsquoAppSKey afin de seacutecuriser la transaction
Un ensemble de champs nommeacute Frame Header permet de speacutecifier le DevAddr le Frame Control
le Frame Counter et le Frame Option
Le Frame Port deacutepend du type drsquoapplication et sera choisi par lrsquoutilisateur
Le Frame Payload sont les donneacutees chiffreacutees agrave transmettre Le nombre drsquooctets maximum pouvant
ecirctre transmis (N octets) est donneacute dans le tableau suivant
PHY Payload
P octets Couche
Physique
Couche
Mac
Couche
Application
CRC
2 octets Header + Header CRC
20 bits Preamble
MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Figure 32 Trame LORAWAN complegravete par couche protocolaire
Couche
Application Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Frame Header
Figure 33 Trame LORA couche Applicative
| 34
Data Rate Spreading Factor Bandwidth Max Frame Payload (Nombre N) DR 0 SF12 125 KHz 51 octets
DR 1 SF11 125 KHz 51 octets
DR 2 SF10 125 KHz 51 octets
DR 3 SF9 125 KHz 115 octets
DR 4 SF8 125 KHz 222 octets
DR 5 SF7 125 KHz 222 octets
DR 6 SF7 250 KHz 222 octets
Tableau 5 Taille maximum du Frame Payload en fonction du Data Rate
443 Couche LoRa MAC Cette trame est destineacutee au Network Server Elle est authentifieacutee gracircce au champ MIC (Message
Integrity Protocol) selon la meacutethode expliqueacutee au paragraphe 416
Le protocole LoRa MAC est composeacute de
1 MAC Header Version de protocole et type de message
Type de Message Description 000 Join-Request
001 Join-Accept
010 Unconfirmed Data Up
011 Unconfirmed Data Down
100 Confirmed Data Up
101 Confirmed Data Down
110 Rejoin-request
111 Proprietary
Tableau 6 Les types de messages transmis en LoRaWAN
2 MAC Payload Contient tout le protocole applicatif
3 MIC Message Integrity Code pour lrsquoauthentification de la trame
444 Couche physique Modulation LoRa
Le choix du moment drsquoeacutemission des Devices LoRa se fait de faccedilon simple Lorsqursquoun eacutequipement
doit eacutemettre il le fait sans controcircle et ne cherche pas agrave savoir si le canal est libre Si le paquet a eacuteteacute
perdu il le retransmettra simplement au bout drsquoun temps aleacuteatoire La couche physique est
repreacutesenteacutee par lrsquoeacutemission de la trame suivante
Couche
Mac MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Figure 34 Trame LORA couche LORA MAC
| 35
Le Preacuteambule est repreacutesenteacute par 8 symboles + 425 Le temps du Preacuteambule est donc de 1225
Tsymbole
Len-tecircte (Header optionnel) est seulement preacutesent dans le mode de transmission par deacutefaut
(explicite) il est transmis avec un Coding Rate de 48 Il indique la taille des donneacutees le Coding Rate
pour le reste de la trame et il preacutecise eacutegalement si un CRC sera preacutesent en fin de trame
Le PHY Payload contient toutes les informations de la Couche LoRa MAC
Le CRC sert agrave la deacutetection drsquoerreur de la trame LoRa
445 Canaux et bandes de freacutequences et Data Rate (DR) Le LoRa utilise des bandes de freacutequences diffeacuterentes suivant les reacutegions du monde En Europe la
bande utiliseacutee est celle des 868 Mhz [ De 863 Mhz agrave 870 Mhz ] Le LoRaWAN deacutefinie les 8 canaux agrave
utiliser pour communiquer avec une Gateway suivant le tableau suivant
Canaux Spreading Factor Bandwidth 8681 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz SF7 250 kHz
8685 Mhz De SF7 agrave SF12 125 kHz
8671 Mhz De SF7 agrave SF12 125 kHz
8673 Mhz De SF7 agrave SF12 125 kHz
8675 Mhz De SF7 agrave SF12 125 kHz
8677 Mhz De SF7 agrave SF12 125 kHz
8679 Mhz De SF7 agrave SF12 125 kHz
Tableau 7 Canaux SF et Bandwidth de notre Gateway LoRaWAN
Une Gateway LoRa eacutecoute donc sur 8 canaux simultaneacutement avec les 6 Spreading Factor
diffeacuterents soit 48 combinaisons possibles
Comme nous lrsquoavons vu le Spreading Factor a des conseacutequences sur le deacutebit de la transmission Ces
deacutebits sont noteacutes DR (Data Rate) et sont normaliseacutes de DR0 agrave DR6
PHY Payload
P octets Couche
Physique CRC
2 octets Header + Header CRC
( Optionnel ) 20 bits Preamble
Figure 35 Trame LORA couche Physique
| 36
Data Rate Spreading Factor Bandwidth DR 0 SF12 125 KHz
DR 1 SF11 125 KHz
DR 2 SF10 125 KHz
DR 3 SF9 125 KHz
DR 4 SF8 125 KHz
DR 5 SF7 125 KHz
DR 6 SF7 250 KHz
Tableau 8 Deacutenomination DR en fonction du SF et de la Bande Passante
446 Trame reccedilue et transmise par la Gateway LoRaWAN La Gateway reccediloit drsquoun cocircteacute un message radio moduleacute en LoRa et transmet de lrsquoautre cocircteacute une trame
IP agrave destination du Network Server
Coteacute interface Radio La Gateway reacuteceptionne une trame LoRaWAN et extrait le PHY Payload Celui-
ci est codeacute au format ASCII en base 64 (voir le paragraphe 541) La Gateway extrait aussi toutes les
informations utiles sur les caracteacuteristiques de la reacuteception qui a eu lieu SF Bandwidth RSSI Time
On Airhellipetchellip
Coteacute interface reacuteseau IP La Gateway transmet lrsquoensemble de ces informations dans un paquet IP
(UDP) au Network Server Les donneacutees transmises sont du texte en format JSON (voir paragraphe
447) La Gateway a donc bien un rocircle de passerelle entre le protocole LoRa drsquoun cocircteacute et un reacuteseau
IP de lrsquoautre
Internet
UDP IP
Device LoRa
Gateway
Network Server Modulation
LoRa
Passerelle LoRa Internet
Transmission Radio Internet
Figure 36 Rocircle de la Gateway LoRa
| 37
447 Le format JSON Le format JSON est un format texte composeacute drsquoune succession de couple nomvaleur Dans
lrsquoexemple de la figure preacuteceacutedente gw_id est un nom et eui-b827ebfffeae26f5 est la valeur
associeacutee Dans cette exemple la valeur est un string Les objets sont deacutelimiteacutes par un des accolades
et
Une valeur peut ecirctre
Un string exemple coding_rate 45
Un nombre exemple spreading_factor 12
Un objet exemple lora spreading_factor 12 air_time 2465792000
Un Boolean
Ethernet
Gateway
Modulation
LORA
Reacutecupeacuteration du PHY PAYLOAD en base 64
Reacutecupeacuteration des caracteacuteristiques de la transmission Canal SF CR hellip
IP (IP dest routereuthethingsnetwork)
UDP (Port dest 1700 Port source 1700)
Donneacutees applicatives (format JSON)
gw_id eui-b827ebfffeae26f5
payload QNAPvA6Ax3ECqHk4C8hfzuA==
lora
spreading_factor 12
bandwidth 125
air_time 2465792000
coding_rate 45
timestamp 2019-01-20T133746017Z
rssi -105
snr -162
dev_addr 0EBC0FD0
frequency 867100000
Internet Transmission Radio LORA
Figure 37 Passerelle (Gateway) LORAWAN
| 38
5 Mise en œuvre drsquoun reacuteseau LoRaWAN
51 Les diffeacuterents types de reacuteseaux Les reacuteseaux LoRaWAN peuvent ecirctre utiliseacute suivant deux meacutethodes
En utilisant les reacuteseaux LoRaWAN opeacutereacutes proposeacutes par les opeacuterateurs de teacuteleacutecoms
En utilisant votre propre reacuteseau LoRaWAN priveacute
511 Les reacuteseaux LoRaWAN opeacutereacutes Ce sont des reacuteseaux LoRaWAN proposeacutes par les opeacuterateurs Par exemple Objenious (filiale de
Bouyges) ou encore Orange Dans le cas de lrsquoutilisation des reacuteseaux opeacutereacutes lrsquoutilisateur a juste
besoin de srsquooccuper des Devices LoRa Les Gateways le Network Server et lrsquoApplication Server sont
geacutereacutes par lrsquoopeacuterateur
512 Les reacuteseaux LoRaWAN priveacutes Chacun est libre de reacutealiser son propre reacuteseau priveacute en impleacutementant sa propre Gateway pour
communiquer avec ses Devices LoRa Lrsquoimpleacutementation du Network Server et de lrsquoApplication Server
peuvent alors ecirctre envisageacutes de diffeacuterentes faccedilons
Network Server et Application serveur priveacutees Crsquoest le deacuteveloppeur qui les mets en place Dans
certaines Gateways une impleacutementation de ces deux serveurs est deacutejagrave proposeacutee Sinon il est
possible de la mettre en place Il existe des serveurs (Network et Application) open source crsquoest le
cas par exemple de LoRa Serveur [ wwwloraserverio ]
Une autre alternantive est httpsgithubcomgotthardplorawan-server
LoRaServer et lorawan-server sont deux applications Open Source
Network Server et Application Server en ligne Un certain nombre de Network Server et
drsquoApplication Server sont proposeacutes Ce sont des services payants ou avec des contreparties
Loriot [ wwwloriotio ]
ResIoT [ wwwresiotio ]
The Things Network [ wwwthethingsnetworkorg ] Crsquoest la solution que nous utiliserons
513 Les zones de couvertures
Les zones de couvertures des reacuteseaux opeacutereacutes sont mise agrave jour par les opeacuterateurs celle drsquoobjenious
est par exemple disponible ici httpsobjeniouscomreseau
Pour connaitre la zone de couverture de notre Gateway utiliseacutee avec TTN nous pouvons utiliser
lrsquoapplication TTN Mapper httpsttnmapperorg Lrsquoideacutee est de promener son Device LoRa associeacute
agrave un GPS dans la zone de couverture des Gateway qui nous entourent A chaque trame reccedilue par le
| 39
Serveur on note les coordonneacutees GPS du Device LoRa ainsi que la Gateway qui a transmis le
message Toutes ces informations sont alors retranscrites sur une carte
52 The Things Network (TTN)
521 Preacutesentation de TTN
Pour la suite nous utiliserons le Network Server et lrsquoApplication Server fourni par TTN
[wwwthethingsnetworkorg]
TTN est gratuit et Open Source En revanche le fait drsquoutiliser TTN impose agrave ceux qui enregistrent
des Gateways de les mettre agrave disposition agrave tous les autres utilisateurs de TTN Lrsquoobjectif est de
reacutealiser un reacuteseau global ouvert
522 Configuration de la Gateway A lrsquouniversiteacute nous avons deux Gateways LoRa (Marque EBDS) Elles sont toutes les deux situeacutees sur
le Campus de Technolac Une Gateway est agrave lrsquointeacuterieur du bacirctiment ISERAN et sert essentiellement
pour les Travaux Pratiques et formations Lrsquoautre est sur le toit du bacirctiment Chablais et est mise agrave
disposition du public via le service de TTN
Les deux Gateway eacutecoutent sur tous les canaux et sur tous les Spreading Factor SF7 gt SF12
Lrsquo IP de la Gateway LoRa agrave lrsquouniversiteacute (bacirctiment ISERAN) est 192168140196
Serveur DNS 1934812032 19348129137
Network Server (TTN) 137616868 routereuthethingsnetwork
Port Upstream 1700 Port Downstream 1700
523 Enregistrement des Gateways Appplication et Devices La configuration de TTN se fait en ligne La premiegravere opeacuteration agrave reacutealiser lorsqursquoune nouvelle
Gateway est deacuteployeacutee crsquoest de lrsquoenregistrer dans TTN
Enregistrement drsquoune Gateway LoRa TTN gt Console gt Gateway gt register gateway
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Figure 38 Scheacutema de notre application
| 40
Figure 39 Enregistrement dune Gateway LoRa sur TTN
Enregistrement drsquoune application TTN gt Console gt Application gt add application
Figure 40 Enregistrement dune application sur TTN
Enregistrement des Devices LoRa dans lrsquoapplication Nom de lrsquoapplication gt register device
Figure 41 Enregistrement des Devices LoRa dans une application
524 Configuration des Devices LoRa Lorsque nous avons enregistreacute des Devices LoRa dans TTN nous devons choisir entre les deux modes
drsquoauthentification Dans un premier temps nous utiliserons le mode le plus simple qui est ABP Nous
geacuteneacuterons dans TTN les DevAddr NetwkSKey et AppSKey
| 41
Figure 42 Configuration des Devices LoRa en ABP dans TTN
53 Mise en application Nous avons dans notre application 10 Devices LoRa drsquoenregistreacutes aduino0 agrave arduino9 Ils sont tous
configureacutes en ABP Les configurations des 10 Devices (DevAddr NetwkSKey et AppSKey) sont noteacutes
en commentaire dans le code de vous allez reacutecupeacuterer
Reacutecupeacuterer le code Arduino laquo RN2483-Arduino-LORAWANino raquo dans Moodle
Modifier votre configuration (DevAddr NetwkSKey et AppSKey) en fonction de votre
numeacutero de binocircme
Veacuterifier que votre Device LoRa arrive bien agrave transmettre des informations (Uplink) vers la
Gateway puis vers le Network Serveur de TTN (The Things Network)
54 Analyse des trames eacutechangeacutees
541 Utilisation de la base 64 Notre Gateway nous preacutesente le Payload PHY en base64 Lrsquoexplication de la meacutethode de
repreacutesentation en base 64 est fourni au travers drsquoun exemple Le code hexadeacutecimal 0x4869
repreacutesente nos donneacutees binaires que nous souhaitons transmettre en base 64
1 On eacutecrit les donneacutees agrave transmettre en binaire
2 On regroupe les eacuteleacutements binaires par des blocs de 6 bits Le nombre de bloc de 6 bits doit
ecirctre un multiple de 4 (minimum 4 blocs) Srsquoil manque des bits pour constituer un groupe de
6 bits on rajoute des zeacuteros
0x4869 = 0100 1000 0110 1001
| 42
3 Srsquoil manque des blocs pour faire un minimum de 4 blocs des caractegraveres speacuteciaux seront
ajouteacutes
4 Chaque groupe de 6 bits est traduit par le tableau suivant (Source Wikipeacutedia)
Figure 43 Codage en base 64
5 Si un bloc de 6 bits manque (ils doivent ecirctre un multiple de 4) on rajoute un ou plusieurs
compleacutements (caractegravere laquo = raquo )
Reacutesultat Le codage de 0x4869 en base 64 est laquo SGk= raquo
010010 000110 100100
On ajoute 00 pour avoir
6 bits dans le groupe
Bloc de 6 bits
010010 000110 100100
S G k
010010 000110 100100
S G k =
1er Bloc
2egraveme Bloc
3egraveme Bloc
4egraveme Bloc
| 43
542 Inteacuterecirct et inconveacutenient de la base 64 Lrsquoutilisation de la base 64 est un choix qui a eacuteteacute fait pour le protocole LoRa LoRaWAN afin de rendre
les donneacutees binaires lisibles Le problegraveme du code ASCII crsquoest qursquoil est composeacute drsquoun certain nombre
de caractegraveres non imprimables (EOF CR LFhellip) Pour eacuteviter ces soucis la base 64 ne comporte que
64 caractegraveres imprimables (voir tableau ci-dessus)
La restriction agrave 64 caractegraveres a cependant un inconveacutenient crsquoest que nous ne pouvons coder que 6
bits (26=64) au lieu de 8 La base 64 est donc moins efficace drsquoune faccedilon geacuteneacuterale
Nous cherchons agrave coder le code ASCII laquo AA raquo en base 64 Retrouver la deacutemarche en
montrant que le reacutesultat en base 64 est laquo QUE= raquo
543 Uplink Du Device LoRa au Network Server Le Network Server de TTN reccediloit des trames IP en provenance de la Gateway Comme nous lrsquoavons
vu preacuteceacutedemment un certain nombre drsquoinformations peuvent ecirctre retrouveacutees avec cette trame
(DevAddr SF Bandwidth etchellip) mais les donneacutees Applicatives sont bien sucircr chiffreacutees (avec
lrsquoAppkSKey) A ce niveau de reacuteception (sans connaitre lrsquoAppSKey) il nrsquoest donc pas possible de
comprendre la totaliteacute du message reccedilu
Imaginons que la trame IP reccedilue 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 45
timestamp 2019-03-05T140042448Z
rssi -82
snr 9
dev_addr 26011AD3
frequency 867300000
Le Network Server affiche donc les informations de la faccedilon suivante
Figure 44 Trame reacutecupeacutereacutee sur le laquo Network Server raquo de TTN
Nous retrouvons bien les valeurs fournies par la Gateway
timestamp ( agrave 1 heure pregraves en fonction du fuseau horaire)
| 44
frequency 8673 Mhz
modulation Lora
Coding Rate 45
data Rate SF 7 125 kHz (DR5)
air time 463 ms
Drsquoautres information proviennent de lrsquoanalyse du Payload Le Payload inscrit ici est le PHY Payload
Il y a donc une partie chiffreacutee (Frame Payload) mais les entecirctes sont en claires (voir paragraphe
441) Ce PHY Payload est laquo QNMaASYABwAP1obuUHQ= raquo Lorsque celui-ci est exprimeacute en
hexadeacutecimal au lieu de la base 64 il vaut laquo 40D31A01260007000FD686EE5074 raquo comme le montre
le Network Server de TTN
Figure 45 PHY Payload preacutesenteacute dans notre Network Server
Sa taille est bien de 14 octets (en hexadeacutecimal) comme preacuteciseacute sur la Figure 44
Nous reprenons le format de la trame LoRaWAN vu agrave la Figure 32 Nous pouvons alors retrouver
tous les champs de toute la trame
PHYPayload = 40D31A01260007000FD686EE5074
PHYPayload = MAC Header[1 octet] | MACPayload[] | MIC[4 octets]
MAC Header = 40 (Unconfirmed data up)
MACPayload = D31A01260007000FD6
Message Integrity Code = 86EE5074
MACPayload = Frame Header | Frame Port | FramePayload )
Frame Header = D31A0126000700
FPort = 0F
FramePayload = D6
Frame Header = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[015]
DevAddr = 26011AD3 (Big Endian)
FCtrl (Frame Control) = 00 (No ACK No ADR)
FCnt (Frame Counter) = 0007 (Big Endian)
FOpts (Frame Option) =
Vous pouvez veacuterifier lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN
(LoRaWAN packet decoder) httpsbitly2szdXtv
| 45
Figure 46 LoRaWAN packet decoder
544 Uplink Du Network Server agrave lrsquoApplication Server
Nous reprenons lrsquoexemple de la trame ci-dessus (Figure 45) Pour information les cleacutes NwkSKey et
AppSKey suivantes ont eacuteteacute utiliseacutee
NwkSKey E3D90AFBC36AD479552EFEA2CDA937B9
AppSKey F0BC25E9E554B9646F208E1A8E3C7B24
Le Network Server a deacutecodeacute lrsquoensemble de la trame Si le MIC est correct (authentification de la
trame par le NwkSKey) alors le Network Server va passer le contenu du message chiffreacute (Frame
Payload) agrave lrsquoApplication Server Dans notre cas le Frame Payload est (drsquoapregraves le deacutecodage effectueacute
au chapitre preacuteceacutedent)
FramePayload = D6
D6 est le contenu chiffreacute lorsqursquoil est deacutechiffreacute avec lrsquoAppSkey on trouve 01 Vous pouvez veacuterifier
lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN httpsbitly2szdXtv
A noter que lrsquoApplication Server recevra les donneacutees chiffreacutees seulement si le Device LoRa a bien
eacuteteacute enregistreacute On peut aussi veacuterifier ci-dessous que lrsquoApplication Serveur de TTN nous retourne bien
un payload (Frame Payload) de 01
Figure 47 Trame reacutecupeacutereacutee sur lrsquoApplication Server de TTN
time 2019-03-05T140042379279991Z
frequency 8673
modulation LORA
data_rate SF7BW125
coding_rate 45
gateways [
gtw_id eui-b827ebfffeae26f6
timestamp 2447508531
time
channel 4
rssi -82
snr 9
latitude 4563647
longitude 58721523
| 46
location_source registry
]
545 Simulation drsquoUplink dans lrsquoApplication Server
Dans beaucoup de situations nous souhaitons valider le fonctionnement de lrsquoApplication Server de
TTN ouet de notre propre Application Il est donc tregraves utile de pouvoir simuler lrsquoenvoi drsquoune trame
LoRa sur lrsquoApplication Server sans que celle-ci soit reacuteellement eacutemise par un Device LoRa Pour cela
un outil existe dans les Settings de chaque Device enregistreacute dans TTN Nous avons juste besoin de
speacutecifier le Frame Payload en clair en hexadeacutecimal et le numeacutero de Port
Figure 48 Simulation drsquoune trame envoyeacutee par un Device LoRa
546 Downlink De lrsquoApplication Server au Device LoRa La communication LoRa est bidirectionnelle Des donneacutees peuvent ecirctre transmis au Device LoRa
depuis lrsquoApplication Server Depuis TTN un outil existe dans les Settings de chaque Device
enregistreacute Lrsquointerface est repreacutesenteacutee ci-dessous
Figure 49 Transmission de donneacutees de lrsquo laquo Application Server raquo jusqursquoau Device LoRa
Replace scheduling Mode Par deacutefaut le Frame Payload transmis remplacera le Frame
Payload en attente (si il existe) Dans ce mode un seul Frame Payload est planifieacute
First scheduling Mode Le Frame Payload est mis en file drsquoattente en premiegravere position
Last scheduling Mode Le Payload est mis en file drsquoattente en derniegravere position
Une demande de confirmation peut ecirctre demandeacutee au Device LoRa pour qursquoil preacutecise srsquoil a bien reccedilu
les donneacutees Lrsquooption laquo confirmed raquo permet donc de speacutecifier le type de trame dans le MAC Header
(voir paragraphe 443) laquo Confirmed Data Down raquo ou laquo Unconfirmed Data Down raquo dans notre cas
| 47
6 La reacutecupeacuteration des donneacutees sur notre propre Application
Nous utiliserons agrave nouveau le Network Server et Application Server de The Things Network Jusqursquoici
nous nous sommes contenteacute de veacuterifier que les donneacutees de lrsquoutilisateur (Frame Payload) soient bien
arriveacutees agrave destination dans lrsquoApplication Server Il faut maintenant les reacutecupeacuterer avec notre propre
Application qui aura pour rocircle
De stocker et traiter les donneacutees
De les mettre agrave disposition de lrsquoutilisateur (Serveur Web par exemple)
Drsquoenvoyer des commandes de lrsquoutilisateur aux Devices LoRa si besoin (Flux Downlink)
Nous allons voir deux meacutethodes pour communiquer entre notre application et TTN
Le protocole HTTP POST
Le protocole MQTT
61 Reacutecupeacuteration des donneacutees en HTTP POST dans lrsquoApplication
611 Preacutesentation du protocole HTTP
Dans le monde de lrsquointernet le protocole HTTP est tregraves utiliseacute pour le dialogue entre un client et un
serveur web Classiquement le client (un navigateur web par exemple) fait une requecircte HTTP GET
et le serveur lui retourne le contenu de la page web demandeacutee
Dans notre cas la probleacutematique est diffeacuterente car le client doit modifier le contenu du serveur
avec les donneacutees envoyeacutees par le Device LORA La requecircte srsquoappelle HTTP POST Son nom indique
que le client va poster (et on pas reacutecupeacuterer) des donneacutees
Lrsquoutilisateur qui souhaite reacuteceptionner des donneacutees sur son serveur doit donc concevoir un serveur
HTTP capable de traiter des requecirctes HTTP POST [ requecircte noteacutee (1) sur la Figure 51 ] fournies par
TTN Dans cette configuration TTN jouera le rocircle de client et notre application le rocircle de serveur
Devices
LORA Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
HTTP POST
MQTT Internet
Figure 50 Structure globale drsquoun reacuteseau LORAWAN
| 48
Figure 51 Communication bidirectionnelle entre TTN et notre Application
A lrsquoinverse lrsquoutilisateur qui souhaite transmettre des donneacutees agrave destination du Device LoRa
(Downlink) doit ecirctre capable de fournir une requecircte HTTP POST [ requecircte noteacutee (2) sur la Figure 51
] vers TTN Dans cette configuration TTN jouera le rocircle de Serveur et notre application le rocircle de
client
612 Fonctionnement drsquoun client et drsquoun serveur HTTP POST Afin de bien comprendre le fonctionnement des requecirctes HTTP POST nous allons proceacuteder par
eacutetape Le premier test que nous effectuerons sera decorreacuteleacute de TTN Le principe est le suivant
Utilisation drsquoun serveur HTTP disponible sur le web geacuterant les requecirctes HTTP POST [
httpsrbasketsin ] ou [ httpsbeeceptorcom ] par exemple
Utilisation drsquoun client HTTP eacutemettant des requecirctes HTTP POST commande curl sous linux
ou logiciel Postman [ wwwgetpostmancom ] sous windows par exemple
Ce test nous permet de valider le fonctionnement drsquoun serveur HTTP POST et drsquoun client HTTP POST
Une fois que nous serons sucircr de leur fonctionnement nous les utiliserons avec TTN
The Things Network
Application
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 49
Figure 52 Validation dun server HTTP POST et drsquoun client HTTP POST
613 Test du serveur HTTP POST Nous utiliserons un serveur web proposeacute par httpsrbasketsin
Aller sur le site httpsrbasketsin et creacuteer un nouveau laquo Basket raquo Zone ougrave vous pourrez
visualiser les requecirctes qui ont eacuteteacute eacutemises vers votre serveur
A partir de maintenant toutes les requecirctes dirigeacutees vers lrsquoadresse creacuteeacute seront traiteacutees et
srsquoafficheront Dans le menu de configuration il est aussi possible de deacutefinir le contenu de la reacuteponse
qui sera fournie
Deacutefinir un format de reacuteponse pour les requecirctes HTTP POST avec un body personnaliseacute
614 Test du client HTTP POST On peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande (la commande cURL
srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN sous Windows
Commande cURL curl ndashX POST ndashd lsquorsquodonneacutees agrave envoyerrsquorsquo DuServeurHTTP
Logiciel Postman New gt Request gt Creacuteer une requecircte HTTP POST gt Send
Veacuterifier que les requecirctes HTTP POST sont bien reacutecupeacutereacutees sur votre serveur creacutee preacuteceacutedemment
615 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST
Maintenant que nous avons un serveur HTTP (POST) fonctionnel nous allons configurer TTN pour
jouer le rocircle du client et pour qursquoil envoie des requecirctes HTTP POST vers notre Serveur degraves qursquoune
donneacutee drsquoun Device LoRa est disponible Nous geacuterons donc ici le flux Uplink
Requecircte
HTTP POST
Reacuteponse
(contenu parameacutetrable)
Client HTTP (POST)
Server HTTP (POST) [ httpsrbasketsin ]
| 50
Figure 53 Reacutecupeacuteration des donneacutees sur notre Application
Dans TTN nous inteacutegrons un bloc appeleacute laquo HTTP Integration raquo permettant de jouer le rocircle de client
crsquoest-agrave-dire drsquoenvoyer des requecirctes HTTP POST agrave destination de notre nouveau Serveur HTTP
Lrsquointeacutegration se faire agrave partir de TTN gt Console gt Application gt Nom_de_votre_application gt
Integration
Figure 54 Ajout dun client HTTP POST dans TTN
Pour valider le fonctionnement de notre architecture nous pouvons soit
Envoyer une trame depuis un Device LoRa vers TTN
Simuler lrsquoenvoi drsquoune trame drsquoun Device LoRa vers TTN (gracircce agrave lrsquooutil proposeacute par TTN vu
paragraphe 545)
Dans les deux cas voici un exemple de requecircte POST reccedilue sur notre serveur HTTP
app_id test_app_lorawan_sylvainmontagny
dev_id stm32lorawan_1
hardware_serial 0056AF49877
port 1
counter 0
payload_raw qg==
metadata
Requecircte
HTTP POST
Server HTTP (POST) [ httpsrbasketsin ]
The Things Network (Client)
La requecircte contient le Frame Payload deacutechiffreacutee
agrave transmettre agrave lrsquoApplication
| 51
time 2019-01-24T15243703499298Z
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Comme nous pouvons le voir le contenu fourni agrave notre serveur est formateacute en JSON (voir
paragraphe 0) Voici quelques compleacutements drsquoinformation
payload_raw Frame Payload deacutechiffreacute crsquoest donc les donneacutees en clairs dans la base 64
downlink_url URL du serveur HTTP POST qui serviront agrave transmettre des donneacutees au Device
LoRa (flux Downlink)
611 Envoyer des donneacutees depuis notre Application avec HTTP POST
Lorsque nous avons ajouteacute le bloc laquo HTTP Integration raquo au paragraphe preacuteceacutedent nous avons aussi
implicitement activeacute la fonctionnaliteacute que TTN soit precirct agrave recevoir et agrave traiter les requecirctes HTTP
POST La seule information qursquoil nous manque est lrsquoadresse du server HTTP vers lequel il faut eacutemettre
les requecirctes Si on observe la trame reccedilue preacuteceacutedemment en provenance de TTN on srsquoaperccediloit que
dans la trame JSON reccedilu une URL (downlink_url) est speacutecifieacutee
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Crsquoest cette URL que nous devrons utiliser Nous allons nous placer dans la configuration suivante
Figure 55 Envoi de donneacutees agrave partir de notre Application
Comme preacuteceacutedemment on peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande
(la commande cURL srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN
Commande cURL curl ndashX POST ndashdata lsquo dev_id Identidiant_De_Votre_Device
payload_raw AQE= rsquo DuServeurHTTP
Logiciel Postman New gt Request gt HTTP POST puis Body gt Raw gt JSON
Requecircte HTTP POST vers serveur TTN laquo downlink_url raquo httpsintegrationsthethingsnetworUaeb8ypKieQ
Contenu de la requecircte
dev_id Identidiant_De_Votre_Device
payload_raw aGVsbG8=
The Things Network (Serveur)
POSTMAN (Client HTTP POST)
| 52
dev_id YourDeviceID
payload_raw aGVsbG8=
Vous devez envoyer le texte (payload_raw) en base 64 Dans lrsquoexemple ci-dessus laquo aGVsbG8= raquo
correspond agrave la chaine de caractegravere laquo hello raquo Vous pouvez utiliser les nombreux encodeurdecodeur
en ligne pour vous aider Le texte doit srsquoafficher sur votre moniteur seacuterie Arduino dans le cadre de
notre deacutemonstrateur sur Arduino
62 Reacutecupeacuteration des donneacutees avec MQTT dans lrsquoApplication
621 Preacutesentation du protocole MQTT
MQTT est un protocole leacuteger qui permet de srsquoabonner agrave des flux de donneacutees Plutocirct que
lrsquoarchitecture Client Serveur classique qui fonctionne avec des Requecirctes Reacuteponses MQTT est
baseacute sur un modegravele Publisher Subscriber La diffeacuterence est importante car cela eacutevite davoir agrave
demander (Requecircte) des donneacutees dont on na aucune ideacutee du moment ougrave elles vont arriver Une
donneacutee sera donc directement transmise au Subscriber degraves lors que celle-ci a eacuteteacute reccedilue dans le
Broker (serveur central)
Figure 56 Modegravele Publisher Subscriber du protocole MQTT
Pour recevoir les donneacutees appartenant agrave un Topic un Subscriber doit souscrire (comme son nom
lindique) au preacutealable sur ce Topic
MQTT est un protocole qui repose sur TCP Lencapsulation des trames sur le reacuteseau est donc la
suivante
Broker
Client
Publisher 1
Client
Publisher 2
Client
Subscriber
Topic
Tempeacuterature
Topic
Humiditeacute
| 53
Figure 57 Protocoles utiliseacutes pour la communication avec MQTT
On peut le veacuterifier par une capture de trame sur Wireshark
Figure 58 Capture dune trame MQTT avec Wireshark
On peut noter que le port TCP utiliseacute pour le protocole MQTT (non chiffreacute) est le 1883
Les Publishers et les Subscribers nrsquoont pas besoin de se connaitre
Les Publishers et les Subscribers ne sont pas obligeacute de srsquoexeacutecuter en mecircme temps
622 Connexion au Broker MQTT Nous nous inteacuteresserons essentiellement aux options de connexion qui permettront de geacuterer la
Qualiteacute de Service (QoS) Pour se connecter un client MQTT envoie deux informations importantes
au Broker
keepAlive Cest la peacuteriode la plus longue pendant laquelle le client Publisher ou Subscriber pourra
rester silencieux Au-delagrave il sera consideacutereacute comme deacuteconnecteacute
cleanSession Lorsque le Client et le Broker sont momentaneacutement deacuteconnecteacutes (au-delagrave du
keepAlive annonceacute) on peut donc se poser la question de savoir ce quil se passera lorsque le client
sera agrave nouveau connecteacute
Si la connexion eacutetait non persistante (cleanSession = True) alors les messages non transmis
sont perdus Quel que soit le niveau de QoS (Quality of Service)
Si la connexion eacutetait persistante (cleanSession = False) alors les messages non transmis
seront eacuteventuellement reacuteeacutemis en fonction du niveau de QoS Voir le chapitre 624
623 Qualiteacute de Service au cours dune mecircme connexion
A partir du moment ougrave le Client se connecte au Broker il est possible de choisir un niveau de fiabiliteacute
des transactions Le Publisher fiabilise leacutemission de ces messages vers le Broker et le Subscriber
fiabilise la reacuteception des messages en provenance du Broker Une parle ici du cas dune mecircme
connexion crsquoest-agrave-dire entre le moment ou le Client se connecte et le moment ougrave
Soit il se deacuteconnecte explicitement (Close connexion)
Soit il na rien eacutemis ni fait signe de vie pendant le temps keepAlive
TCP
MQTT
Reacuteseau
Transport
Couche Application
IP
| 54
Lors dune mecircme connexion la Qualiteacute de Service (QoS) qui est mise en œuvre deacutepend uniquement
de la valeur du QoS selon les valeurs suivantes
QoS 0 At most once (au plus une fois) Le premier niveau de qualiteacute est sans acquittement Le
Publisher envoie un message une seule fois au Broker et le Broker ne transmet ce message quune
seule fois aux Subscribers Ce meacutecanise ne garantit pas la bonne reacuteception des messages MQTT
QoS 1 At least once (au moins une fois) Le deuxiegraveme niveau de qualiteacute est avec acquittement
Le Publisher envoie un message au Broker et attends sa confirmation De la mecircme faccedilon le Broker
envoie un message agrave ces Subscriber et attends leurs confirmations Ce meacutecanisme garantit la
reacuteception des message MQTT
Cependant si les acquittements nrsquoarrivent pas en temps voulu ou srsquoils se perdent la reacuteeacutemission du
message dorigine peut engendrer une duplication du message Il peut donc ecirctre reccedilu plusieurs fois
QoS 2 Exactly once (exactement une fois) Le troisiegraveme niveau de qualiteacute est garanti une seule
fois Le Publisher envoie un message au Broker et attends sa confirmation Le Publisher donne alors
lrsquoordre de diffuser le message et attends une confirmation Ce meacutecanisme garantit que quel que
soit le nombre de tentatives de reacuteemission le message ne sera deacutelivreacute quune seule fois
La Figure 59 montre les trames eacutemises pour chaque niveau de QoS
Figure 59 Qualiteacute de Service en MQTT
La Figure 60 repreacutesentes les 3 captures de trames sur Wireshark repreacutesentant les 3 QoS (1 2 et 3)
que nous venons dexpliquer
Broker
QoS 0
Au plus une fois
Message supprimeacute apregraves envoi
PUBLISH
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Duplications possibles
PUBLISH
PUBLICH Ack
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Pas de duplication
PUBLISH
PUBLISH Receive
PUBLISH Release
PUBLISH Complete
| 55
Figure 60 Capture de trame avec QoS = 0 puis QoS = 1 puis QoS = 2
624 Qualiteacute de Service apregraves une reconnexion
La question que nous nous posons et de savoir ce que deviennent les messages publieacutes sur le Broker
lorsquun ou plusieurs Subscribers sont momentaneacutement injoignables Il est possible de conserver
les messages qui ont eacuteteacute publieacutes sur le Broker afin de les retransmettre lors de la prochaine
connexion Cette possibiliteacute de sauvegarde doit ecirctre activeacutee agrave louverture de connexion gracircce au flag
cleanSession = 0 La connexion sera alors persistante crsquoest-agrave-dire que le Broker enregistre tous les
messages quil na pas reacuteussi agrave diffuser au Subscriber
Le Tableau 9 reacutesume leffet du flag cleanSession et du QoS
Clean Session Flag Subscriber QoS Publisher QoS Comportement True ( = 1) 0 1 2 0 1 2 Messages perdus
False ( = 0 ) 0 0 1 2 Messages perdus
False (= 0 ) 0 1 2 0 Messages perdus
False (= 0 ) 1 2 1 2 Tous les messages sont retransmis
Tableau 9 Qualiteacute de Service en fonction de la valeur du QoS et du flag cleanSession
625 Les Topics du protocole MQTT Les chaicircnes deacutecrivant un sujet forment une arborescence en utilisant la barre oblique comme
caractegravere de seacuteparation La Figure 61 et le Tableau 10 donne un exemple dorganisation de Topic
Figure 61 Exemple de hieacuterarchie de Topic MQTT
Niveau 3
Niveau 2
Niveau 1 Maison
Chambre
Temperature Humidite Bruit
Salon
Temperature
| 56
Nom du Topic Deacutetail du Topic MaisonChambreTemperature La tempeacuterature de la chambre de la maison
MaisonChambreBruit Le bruit de la chambre de la maison
MaisonSalonTemperature La tempeacuterature du Salon de la maison
Tableau 10 Exemple de Topic
Un client peut sabonner (ou se deacutesabonner) agrave plusieurs branches de larborescence agrave laide de
jokers englobant plusieurs Topics Deux caractegraveres jokers existent
Le signe plus + remplace nimporte quelle chaine de caractegravere sur le niveau ougrave il est placeacute
Le diegravese remplace nimporte quelle chaine de caractegravere sur tous les niveaux suivants Il
est obligatoirement placeacute agrave la fin
Nom du Topic Deacutetail du Topic Maison+Temperature Les tempeacuteratures de toutes les piegraveces de la maison
MaisonChambre La tempeacuterature lhumiditeacute et le bruit de la chambre de la maison
Tableau 11 Exemple de Topic
626 Mise en place drsquoun Broker MQTT Afin de bien comprendre le fonctionnement du protocole de MQTT on reacutealise des tests
indeacutependamment de TTN Nous allons mettre en place
Un Broker Mosquitto httpstestmosquittoorg
Un client Publisher MQTT Box sur Windows
Un client Subscriber MQTT Box sur Windows
Figure 62 Test du protocole MQTT
MQTT Client (Subscriber)
MQTT Client (Publisher)
Publish
Subscribe
BROKER (Mosquitto)
| 57
Le Broker MQTT est commun agrave tout le monde Nous pouvons soit le reacutealiser nous-mecircme soit utiliser
un Broker MQTT public de test Nous utiliserons le Broker de test de Mosquitto disponible sur
httpstestmosquittoorg Drsquoautres sont eacuteventuellement disponibles en cas de problegraveme par
exemple httpwwwmqtt-dashboardcom
Si nous deacutecidions de le reacutealiser nous-mecircme agrave lrsquoaide drsquoune Raspberry Pi (par exemple) Lrsquoinstallation
se ferait en deux lignes de commande
apt-get install mosquito Installation
sudo systemctl start mosquittoservice Lancement du service
Il est neacutecessaire drsquoinstaller mosquitto-clients si on souhaite que le Raspberry PI joue aussi le rocircle de
client ce qui nrsquoest pas notre cas
627 Mise en place drsquoun Publisher et drsquoun Subscriber MQTT Lancer le logiciel MQTTBox
MQTTBox gt Create MQTT Client
Dans ce client les seuls champs indispensables sont
Protocol MQTT TCP
Host testmosquittoorg
Figure 63 Configuration dun Client MQTT dans MQTT Box
Tester lrsquoenvoi et la reacuteception sur les Topics de votre choix
628 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT La reacutecupeacuteration des donneacutees fait reacutefeacuterence au flux Uplink Dans ce cas
TTN joue le rocircle de client Publisher
TTN joue aussi le rocircle de Broker
Notre application joue le rocircle de Subscriber
Nous pouvons donc repreacutesenter lrsquoapplication globale par le scheacutema suivant
| 58
Figure 64 Publisher et Subscriber dans en MQTT avec TTN
La publication est repreacutesenteacutee par la trame MQTT (1)
La souscription est repreacutesenteacutee par la trame MQTT (2)
Le client Publisher eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box mais cette fois avec la configuration suivante
Protocol mqtt tcp
Host Crsquoest lrsquoIP du Broker vers lequel il faut se connecter Dans notre cas il srsquoagit de celui
de TTN dont lrsquoadresse est euthethingsnetwork
Username La connexion vers le broker MQTT est soumis agrave une authentification Username
Password Dans notre cas le Username correspond au nom de notre application crsquoest-agrave-
dire seminaire_lorawan Si vous avez choisi une autre applicationil faut bien mettre la
votre
Password Le Password est nommeacute laquo Access Key raquo par TTN Elle vous sera donneacutee par
lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application vous
trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt Overview
Figure 65 Access Keys de lapplication dans TTN
The Things Network (Application Server)
BROKER
Application
The Things Network (Network Server)
Publish (1 )
[ Flux Uplink ]
Subscribe (2 )
[ Flux Uplink ]
| 59
Figure 66 Configuration du Client dans MQTT Box
Le client MQTT eacutetant configureacute il est maintenant capable de se connecter au Broker Il reste donc agrave
deacutefinir le fait que le client sera Subscriber Les informations que recevra le Subscriber deacutependent du
Topic auquel nous souscrivons Voici les Topic disponibles sur le Broker de TTN
ltAppIDgt correspond au nom de votre Application
ltDevIDgt correspond au nom de votre Device LoRa
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink ltAppIDgtdevicesltDevIDgtup
[Donneacutees] Flux Downlink ltAppIDgtdevicesltDevIDgtdown
[Activation Events] Activation dun Device ltAppIDgtdevicesltDevIDgteventsactivations
[Management Events] Creacuteation dun Device ltAppIDgtdevicesltDevIDgteventscreate
[Management Events] Update dun Device ltAppIDgtdevicesltDevIDgteventsupdate
[Management Events] Suppression dun Device ltAppIDgtdevicesltDevIDgteventsdelete
[Downlink Events ] Message programmeacute ltAppIDgtdevicesltDevIDgteventsdownscheduled
[Downlink Events ] Message envoyeacute ltAppIDgtdevicesltDevIDgteventsdownsent
[Erreurs] Uplink erreurs ltAppIDgtdevicesltDevIDgteventsuperrors
[Erreurs] Downlink erreurs ltAppIDgtdevicesltDevIDgteventsdownerrors
[Erreurs] Activations erreurs ltAppIDgtdevicesltDevIDgteventsactivationserrors
Tableau 12 Topics enregistreacutes dans TTN
Dans un premier temps nous souscrivons au Topic +devices+up Cela signifie que nous
souscrivons agrave tous les Devices LoRa de toutes nos applications pour le flux Uplink
Figure 67 Configuration du Subscriber
Les eacuteleacutements eacutemis par le Broker seront alors afficheacutes dans MQTTBox La
| 60
Figure 68 Trame LoRaWAN reccedilu sur le Subscriber MQTT
Ces donneacutees sont eacutecrites en JSON nous pouvons les remettre en forme
applicationID3
applicationNamemyApplication
deviceNamearduino0
devEUI0056xxxxxxxxx877
txInfo
frequency868500000
dr5
adrfalse
fCnt792
fPort15
dataSGVsbG8=
Le Frame Payload deacutechiffreacute est fourni dans le champ data en base 64 La valeur fournie par
dataSGVsbG8= correspond bien agrave la chaine de caractegravere hello que nous avons eacutemise avec le
Device LoRa
629 Envoyer des donneacutees depuis notre Application avec MQTT
Lrsquoenvoi des donneacutees fait reacutefeacuterence au flux Downlink Dans ce cas
Notre application joue le rocircle de Publisher
TTN joue le rocircle de Broker
TTN joue aussi le rocircle de client Subscriber
| 61
La publication est repreacutesenteacutee par la trame MQTT (3)
La souscription est repreacutesenteacutee par la trame MQTT (4)
Le client Subscriber eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box Le rocircle de client dans MQTT Box a eacuteteacute faite au
paragraphe 628 Il nous reste simplement agrave ajouter le rocircle de Publisher La configuration est la
suivante
Topic du Subscriber seminaire_lorawandevicesarduino0down ougrave seminaire_lorawan
est agrave remplacer par le nom de votre application et arduino0 par le nom du Device LoRa vers
lequel vous souhaitez envoyeacute une donneacutee (Voir chapitre 628 pour comprendre les Topics)
Le Payload doit ecirctre au format JSON Lrsquoexemple suivant envoie laquohello raquo
payload_raw aGVsbG8=
The Things Network (Application Server)
BROKER
Application
Publish (3)
[ Flux Downlink ]
The Things Network (Network Server)
Subscribe (4)
[ Flux Downlink ]
| 62
Figure 69 Configuration du Publisher
Vous devriez voir les donneacutees arriver sur votre Device LoRA
| 63
7 Creacuteation de notre propre Network et Application Server
711 Objectifs Lors de la mise en œuvre du reacuteseau LoRaWAN au chapitre 52 nous avons utiliseacute TTN (The Things
Network) pour jouer le rocircle de Network Server et drsquoApplication Server Pour de multiples raisons
Seacutecuriteacute autonomie coucircthellipil peut ecirctre inteacuteressant de monter soi-mecircme un Network Server et un
Application Server Cela est possible seulement si vous posseacutedez vos propres Gateway puisque
celles-ci devront forwarder leur paquet agrave destination preacutecise Il faudra donc les reconfigurer pour
qursquoelles pointent vers votre nouvelle architecture
712 Preacutesentation de LoRaServer LoRaServer [ wwwloraserverio ] est un projet Open-Source reacutepondant exactement au besoin que
nous avons Nous lrsquoutiliserons sur une cible Raspberry PI En reacutealiteacute il peut souvent ecirctre mise en
place dans le mecircme systegraveme que la Gateway surtout si celle-ci est elle-mecircme agrave base de RPI Les
Gateway EBDS que nous posseacutedons possegravedent drsquoailleurs un Network Server et un Application Server
que nous aurions pu utiliser Neacuteanmoins pour des raisons peacutedagogiques il est inteacuteressant de
seacuteparer les systegravemes pour bien diffeacuterencier les probleacutematiques
Attention il y a une ambiguiumlteacute dans la deacutenomination des entiteacutes logiciels de LoRaServer
LoRaServer (sans espace entre le mot LoRa et Server) est le nom du projet global En
revanche LoRa Server (avec un espace) est le nom du service qui joue le rocircle du Network
Server
Lrsquoarchitecture et le fonctionnement de LoRaServer est preacutesenteacutee dans sa documentation par le
scheacutema suivant
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Raspberry PI
Figure 70 Architecture globale de notre reacuteseau loRaWAN
| 64
Figure 71 Architecture deacutetailleacutee de LoRaServer
On srsquoattends agrave voir uniquement un Network Server (LoRa Server) et un Application Server (LoRa App
Server) mais ce scheacutema est plus complexe Il demande un certain nombre drsquoexplications pour bien
comprendre ce que nous allons installer et la faccedilon dont nous lrsquoutiliserons par la suite
713 Le laquo Packet Forwarder raquo (Gateway) Comme nous lrsquoavons vu au chapitre 412 les Gateways LoRa sont des passerelles entre la
modulation LoRa et un reacuteseau IP Pour reacutealiser cette passerelle un service nommeacute laquo UDP Packet
Forwarder raquo a eacuteteacute deacuteveloppeacute par Semtech httpsgithubcomLora-netpacket_forwarder Dans
ce dossier github un fichier nommeacute PROTOCOLTXT explique parfaitement ce protocole applicatif
qui travaille au-dessus de UDP
Figure 72 Protocole Uplink (PUSH_DATA du Packet Forwarder)
| 65
On remarque que les paquets sont envoyeacutes en UDP au Network Server dans une trame appeleacutee
PUSH_DATA Cette trame est acquitteacutee par le Network Server par une trame appeleacutee PUSH_ACK
Sur notre Network Server nous pouvons reacutealiser une capture de trame pour veacuterifier si le protocole
est bien celui preacutesenteacute dans le document
Figure 73 Trame captureacutee par Wireshark lors dun Uplink
Drsquoapregraves la capture preacuteceacutedente on remarque que le Packet Forwarder fonctionne bien avec UDP sur
le port 1700
Le contenu des donneacutees (champ Data) est deacutetailleacute dans le tableau suivant
Champ | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | random token
[3] | 3 | PUSH_DATA identifier = 0x00
[4] | 4-11 | Gateway unique identifier (MAC address)
[5] | 12-end | JSON object starting with ending with
Lrsquoobjet JSON de la transmission reacuteeacutecrit plus proprement est celui-ci
Figure 74 Analyse du champ Donneacutees du protocole laquo Packet Forwarder raquo
0000 02 f9 30 00 b8 27 eb ff fe ae 26 f5 7b 22 72 78 0amprx 0010 70 6b 22 3a 5b 7b 22 74 6d 73 74 22 3a 33 37 35 pk[tmst375 0020 35 30 30 35 38 31 39 2c 22 63 68 61 6e 22 3a 32 5005819chan2 0030 2c 22 72 66 63 68 22 3a 31 2c 22 66 72 65 71 22 rfch1freq 0040 3a 38 36 38 2e 35 30 30 30 30 30 2c 22 73 74 61 868500000sta 0050 74 22 3a 31 2c 22 6d 6f 64 75 22 3a 22 4c 4f 52 t1moduLOR 0060 41 22 2c 22 64 61 74 72 22 3a 22 53 46 37 42 57 AdatrSF7BW 0070 31 32 35 22 2c 22 63 6f 64 72 22 3a 22 34 2f 35 125codr45 0080 22 2c 22 6c 73 6e 72 22 3a 36 2e 35 2c 22 72 73 lsnr65rs 0090 73 69 22 3a 2d 31 2c 22 73 69 7a 65 22 3a 31 38 si-1size18 00a0 2c 22 64 61 74 61 22 3a 22 51 4e 4d 61 41 53 59 dataQNMaASY 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 ]
Ch
amp
[1
]
Ch
amp
[2
]
Ch
amp
[3
]
Ch
amp
[4
]
| 66
rxpk[ tmst3755005819
chan2
rfch1
freq868500000
stat1
moduLORA
datrSF7BW125
codr45
lsnr65
rssi-1
size18
dataQNMaASYAAQAPpyPZ955+SmY
]
Le champ data correspond au PHY Payload
De la mecircme faccedilon on retrouve la Trame drsquoacquittement
Figure 75 Trame captureacutee par Wireshark lors de lrsquoacquittement drsquoun Uplink
Champs | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | same token as the PUSH_DATA to acknowledge
[3] | 3 | PUSH_ACK identifier = 0x01
Nous retrouvons bien tous ces champs dans la trame Wireshark
714 LoRa Gateway Bridge Nous avons deacutecrit au chapitre preacuteceacutedent (713) le fonctionnement du Packet Forwarder Le
Network Server(Lora Server) que nous allons mettre en place aurait tregraves bien pu srsquointerfacer
directement agrave ce protocole Mais cela aurait plusieurs impacts dont un qui est important dans la
conception de logiciel Si le Packet Forwarder change ou si un autre type de Forwarder est utiliseacute
alors lrsquoutilisation du LoRa Server devient impossible Il a donc eacuteteacute choisi de creacuteer une eacutetape
intermeacutediaire Le Network Server que nous mettrons en plus utilisera le protocole MQTT plutocirct que
le protocole UDP packet Forwarder
En drsquoautres termes le LoRa Gateway Bridge est un service qui fera abstraction du Packet Forwarder
pour srsquointerfacer plus simplement avec le Network Server
715 LoRa Server (Network Server) Il srsquoagit de notre Network Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
413 Cependant il srsquointerfacera au protocole MQTT en recevant les informations agrave partir du
Broker au lieu de recevoir directement les trames en provenance de la Gateway
| 67
716 LoRa App Server (Application Server) Il srsquogit de notre Application Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
414
717 LoRa Geo Server Il srsquoagit drsquoun service qui permet drsquoutiliser certaines proprieacuteteacutes du protocole LoRa pour proposer un
service de geacuteolocalisation des Devices LoRa Nous ne lrsquoutiliserons pas dans notre cas
718 Application Il srsquoagit de notre Application qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre 415
Elle ne fait pas partie du projet LoRaServer crsquoest donc bien toujours agrave nous de proposer notre propre
Application
Figure 76 Les interfaces possibles entre LoRaServer et lrsquoApplication utilisateur
Comme nous pouvons le voir sur la figure preacuteceacutedente deux possibiliteacutes sont offertes pour interfacer
notre application JSON REST (incluant HTTP POST) et via un Broker MQTT Ces deux meacutethodes ont
deacutejagrave eacuteteacute traiteacutee au chapitre 61 (HTTP POST ) et au chapitre 62 (MQTT) Nous verrons aussi drsquoautres
possibiliteacutes pour personnaliser notre application au chapitre 7
72 Installation de LoRaServer
721 Mise en place de lrsquoenvironnement
Nous allons installer une carte SD avec la derniegravere version de Raspbian Nous ne deacutetaillerons pas la
deacutemarche pour cela car elles sont largement documenteacutees et mises agrave jour sur le site
wwwraspberrypiorg
Installer un carte SD avec la derniegravere version de Raspbian
Plutocirct que de fonctionner avec un clavier et une souris nous preacuteconisons de travailler agrave distance
avec la RPI via une connexion SSH Depuis quelques anneacutees Raspbian a supprimeacute le deacutemarrage du
service SSH au boot Heureusement il est possible de le reacuteactiver par la meacutethode suivante
Avec Windows ou Linux ouvrir la partition BOOT de votre carte SD et placer un fichier agrave la
racine nommeacute sshtxt (ou ssh)
Mettre la carte SD dans votre RPI et la deacutemarrer
| 68
Pour acceacuteder agrave la RPI en SSH depuis Windows nous utiliserons de preacutefeacuterence le logiciel
client MobaXterm mais tout autre client SSH est valable
Installer MobaXterm sur votre PC et connectez-vous agrave votre Raspberry PI
Lrsquoutilisation drsquoun espion de reacuteseau type Wireshark peut ecirctre inteacuteressant pour eacutetudier les trames qui
sont reccedilues et qui sont eacutemises Cela nous permettra de valider le fonctionnement des diffeacuterents
protocoles reacuteseau qui permettent de communiquer agrave la Gateway drsquoune part et agrave lrsquoApplication
drsquoautre part Nous utiliserons tshark
apt-get install tshark installation
tshark ndashn -i eth0 Exemple drsquoune analyse sur lrsquointerface wlan0
722 Installation sur la Raspberry PI La meacutethode drsquoinstallation de LoRaServer est documenteacutee sur le site web agrave lrsquoadresse suivante
[ httpswwwloraserverioguidesdebian-ubuntu ] Nous installerons le LoRa Gateway Bridge
le LoRa Server et le LoRa App Server
Apregraves lrsquoinstallation la configuration se fait par une interface graphique accessible par le reacuteseau sur
le port 8080
Si vous travaillez sur la RPI connectez-vous sur httplocalhost8080
Si vous travaillez agrave distance (SSH) connectez-vous sur httpIP_RPI8080
Les Usernames et Password par deacutefaut sont
Username admin
Password admin
Lrsquoeacutecran drsquoaccueil sera donc le suivant
Figure 77 Architecture globale apregraves installation de LoRaServer
Devices
Gateways LoRa
UDP Packet Forwarder
Application Server
LoRa App Server
Internet
Network Server
LoRa Server
LoRa Gateway Bridge
| 69
Figure 78 Ecran daccueil de LoRaServer apregraves authentification
71 Configuration de LoRa Server pour lUplink
711 Enregistrement drsquoune nouvelle Organisation
Pour enregistrer une nouvelle Organizations Organizations gt Create Puis entrer les configurations
suivantes
Figure 79 Enregistrement dun nouvelle Organisation
712 Enregistrement drsquoune instance du Network Server Pour enregistrer une nouvelle instance du Network Server Network Server gt Create Puis entrer
les configurations suivantes
| 70
Figure 80 Enregistrement dun nouveau Network Server
Dans lrsquoonglet Gateway Discovery il est possible drsquoactiver une option de deacutecouverte de Gateway aux
alentours Lorsqursquoelle est configureacutee le Network Server va envoyer une trame Downlink de
configuration de la Gateway lui ordonnant de reacutealiser des PING en LoRa La configuration du
Gateway Discovery preacutevoit de speacutecifier
Le nombre de fois par jour que les PING LoRa sont envoyeacutes
Le canal drsquoeacutemission
Le Data Rate (Voir paragraphe 445)
Un PING LoRa reccedilu sur une Gateway sera retransmis sur le Network Server (Lora Server) et une carte
sera afficheacutee
Lrsquoonglet TLS Certificates ne sera pas utiliseacute dans le cadre de notre deacutemonstration
713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) Il faut tout drsquoabord faire un enregistrement drsquoun laquo service-profile raquo Un laquo service profile permet de
faire la connexion entre le Network Server et les Applications que nous enregistrerons dans notre
Organisation Service-profiles gt Create
Service-profile name myServiceProfile
Network-server myNetworkServer
On laissera par deacutefaut toutes les autres options
Pour enregistrer une nouvelle Application Applications gt Create Puis entrer les configurations
suivantes
| 71
Figure 81 Enregistrement dune nouvelle Application
714 Enregistrement des Devices LoRa Il faut tout drsquoabord faire lrsquoenregistrement drsquoun Device-profile pour les Devices LoRa que vous
souhaitez connecter Dans notre cas nous ferons un premier test en speacutecifiant que nous utilisons
seulement le mode drsquoauthentification ABP (voir chapitre 431) Devices profile gt Create
Figure 82 Enregistrement dun laquo Device profile raquo
Nous pouvons alors creacuteer dans notre Application des nouveaux Devices Application gt
myApplication gt Create
| 72
Figure 83 Enregistrement dun nouveau Device LoRa
Dans la fenecirctre Activation on va alors configurer les 3 eacuteleacutements indispensables agrave une
authentification en APB Le DevAddr le NwkSKey et lrsquoAppSKey
Figure 84 Configuration de lenregistrement du Device LoRa (en ABP)
La configuration minimale de LoRaServer est maintenant termineacutee Nous pouvons donc brancher
un Device LoRa qui possegravede les les attribus (DevAddr NwkSKey et AppSKey) que nous avons
enregistreacute dans LoRaServer et le faire eacutemettre
715 Visualisation des trames reccedilues Les trames eacutemises par le Device LoRa vont donc parcourir le cheminement suivant
| 73
Figure 85 Reacutesumeacute du cheminement des trames LoRaWan en Uplink avec LoRaServer
En allant dans le Live Device Data (Application gt Nom_du_Device gt Live Device Data) on peut voir la
liste des trames reccedilues ainsi que les donneacutees applicatives deacutechiffreacutees
Figure 86 Reacuteception des trames des Devices LoRa
Figure 87 Analyse des trames des Devices LoRa
Dans lrsquoonglet LIVE LORAWAN FRAME nous pouvons voir les trames LORAWAN et si besoin eacutetudier
le contenu de ce qursquoelles contiennent En revanche les donneacutees applicatives sont ici chiffreacutees
UDP
Packet Forwarder
LoRa Bridge
Gateway LoRa Server LoRa App Server
Gateway
Server
Internet
| 74
Figure 88 Reacuteception des Trames LoRaWAN
72 Configuration de LoRaServer pour linteacutegration dApplication Nous avons vu dans le chapitre 718 que linterface entre LoRaServer et notre Application pouvait
ecirctre reacutealiseacutee soit par MQTT soit par les meacutethodes REST (HTTP POST) Nous avons deacutejagrave impleacutementeacute
et expliqueacute ces protocoles dans le cadre de son utilisation avec TTN Nous allons donc juste
configurer LoRaServer pour tester ces deux meacutethodes
721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST Nous utiliserons exactement la mecircme meacutethode que celle que nous avons utiliseacute avec TTN au
chapitre 615 Les diffeacuterentes Clients et Serveurs disponibles pour ces tests sont expliqueacutes au
paragraphe 612
Dans LoRaServer ajouter une inteacutegration HTTP LoRaServer gt Applications gt myApplication gt
Integrations gt Create gt HTTP Integration et la configurer comme le montre la Figure 89 Vous
remplacerez eacutevidement le lien par votre propre Endpoints
Figure 89 Configuration de linteacutegration HTTP POST dans LoRaServer
En envoyant des trames LoRa depuis votre Device vous devriez voir les contenus JSON sur votre
Endpoint
722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT Nous allons nous connecter au Broker MQTT de LoRaServer Pour cela nous utiliserons la mecircme
meacutethode que celle que nous avons utiliseacute avec TTN au chapitre 628 Nous utiliserons MQTTBox
comme nous lavons deacutejagrave fait au paragraphe 627
Le Broker de LoRaServer a enregistreacute les Topics suivant
[applicationID] correspond au nom de votre Application
[devEUI] correspond au nom de votre Device LoRa
| 75
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink application[applicationID]device[devEUI]rx
[Donneacutees] Flux Downlink application[applicationID]device[devEUI]tx
[Status] Statut dun Device application[applicationID]device[devEUI]status
[Ack] Acquittement des messages application[applicationID]device[devEUI]ack
[Erreurs] Erreurs application[applicationID]device[devEUI]error
Tableau 13 Topics enregistreacutes dans LoRaServer
| 76
8 Creacuteation de notre propre Application
81 Utilisation de Node-RED
811 Preacutesentation Node-RED est un outil de programmation graphique qui permet de faire communiquer les
peacuteripheacuteriques mateacuteriels drsquoun systegraveme sans eacutecrire de code De nombreux protocoles sont aussi pris
en charge au travers de bloc ( Node) qursquoil suffit de connecter entre eux pour reacutealiser simplement
une application Il peut srsquoexeacutecuter localement sur un PC ou sur des cibles embarqueacutees telle qursquoune
Raspberry PI (RPI)
Dans les deacutemonstrations que nous mettrons en œuvre nous utiliserons une RPI Par soucis de
simpliciteacute nous utiliserons les derniegraveres versions de Raspbian (systegraveme drsquoexploitation de la RPI) qui
integravegre drsquoorigine Node-RED Il nrsquoy a donc tregraves peu de chose agrave mettre en place pour arriver agrave mettre
en place une Application Nous pouvons travailler soit directement sur la RPI agrave lrsquoaide drsquoune souris-
clavier mais il est recommandeacute de travailler agrave distance avec une connexion SSH
812 Mise en place de lrsquoenvironnement La mise en place de la RPI avec le systegraveme drsquoexploitation Raspbian a eacuteteacute preacutesenteacute au chapitre 721
Vous pouvez reprendre la mecircme installation ou repartir sur une nouvelle
Il est possible de faire en sorte que Node-RED se lance directement au deacutemarrage gracircce agrave la
commande sudo systemctl enable noderedservice
Sil nest pas actif lancer Node-RED sur votre RPI node-red-start
Nous nous connectons au Node-RED de la RPI via un navigateur web sur le port 1880 en tapant dans
la barre dURL httpIP_Raspeberry_PI1880 Ce nous permet darriver agrave la fenecirctre suivante
Figure 90 Page daccueil de Node-RED
Il est possible de sinterfacer avec TTN avec les Nodes deacutejagrave disponibles gracircce au protocole HTTP
POST ou MQTT Neacuteanmoins nous pouvons avantageusement installer deux librairies speacutecifiques
Une qui facilite linterfaccedilage avec TTN
Une qui facilite la mise en place dinterface graphique
Installation des Nodes TTN
cd $HOMEnode-red
npm install node-red-contrib-ttn
Installation de Dashboard (interface graphique)
| 77
cd $HOMEnode-red
npm install node-red-dashboard
Il peut ecirctre necessaire de redeacutemarrer Node-RED pour prendre en compte linstallation de nos deux
Nodes
-----------------------------------
sudo apt-get install npm
sudo npm install -g npm
hash -r
cd ~node-red
npm install node-red-example node name
------------------------------------
813 Creacuteer une Application speacutecifique pour TTN Nous allons commencer par geacuterer le flux Uplink Apporter sur votre scheacutema un Node ttn uplink et
un Node Debug puis relier les Le Node ttn uplink nous permettra de configurer la
communication avec TTN en MQTT Le Node debug eacutecrira sur le terminal les informations brutes
qui seront reccedilu par le Node ttn uplink
Figure 91 Visualisation des trame publieacutees par TTN sur notre client MQTT
Double cliquer sur le Node ttn uplink pour le configurer comme la figure suivante
Le champ Name sera le nom du Node sur votre scheacutema Le champ Device ID est le device LoRa
concerneacute dans votre application De plus il faut entrer les caracteacuteristiques de votre application (Add
new ttn app) pour que Node-RED puisse sy connecter
Figure 92 Configuration du node ttn uplink
Configuration de votre nouvelle application
| 78
Figure 93 Identifiant et mot de passe de notre application
AppID Nom de votre application Dans notre cas seminaire_lorawan
Access Key Comme nous lavons deacutejagrave expliqueacute plus tocirct l Access Key vous sera donneacutee
par lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application
vous trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt
Overview
Le Node ttn uplink doit maintenant avoir le nom que vous avez configureacute Cliquer sur Deploy pour
lancer votre projet Le bloc ttn uplink doit maintenant ecirctre connecteacute agrave TTN Cela est speacutecifieacute
connected sous le bloc
Figure 94 Utilisation du Node TTN Uplink
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
Figure 95 Simulation de Uplink dans TTN
Vous devriez voir le reacutesultat dans la fenecirctre de Debug Par exemple pour le test denvoi de 31 32
correspondant au code ASCII des chiffres 1 et 2 vous devriez avoir la fenecirctre de Debug suivante
| 79
Figure 96 Reacutesultats obtenu dans la fenecirctre Debug apregraves la simulation dUplink
814 Creacuteation drsquoun Dashboard
Dans la mise en place de lenvironnement (chapitre 812) nous avons installeacute des Nodes
Dashboard qui vont nous permettre de reacutealiser une interface graphique tregraves simple et de la mettre
agrave disposition des utilisateurs via un des graphiques histogramme gauges afficheurshellip
Figure 97 Impleacutementation dune interface graphique dans Node RED
Linterface graphique que nous allons creacuteer sera constitueacutee donglet (tab) La mise en place des
composant se fait de la faccedilon suivante
Chaque eacuteleacutement graphique doit appartenir agrave un groupe de composant quil va falloir creacuteer
Chaque groupe de composant doit appartenir agrave un onglet (tab) quil va falloir creacuteer
Figure 98 Creacuteation dun groupe de composant
Figure 99 Creacuteation dun nouvel onglet dans le site web
Cliquer sur Deploy pour activer votre application
LURL pour joindre linterface graphique de votre site web est disponible sur ladresse
httpIP_Raspeberry_PI1880ui
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
| 80
Figure 100 Interface graphique du site web avec Node-RED
82 Programmation en PHP Maintenant que nous avons testeacute toute lrsquoarchitecture nous pouvons mettre en place une
application qui jouera deux rocircles
Un rocircle de Serveur HTTP POST reacutecupeacuterant les donneacutees en provenance de TTN
Un rocircle de Client HTTP POST qui geacuteneacuterera les requecirctes vers TTN
Un serveur web apache sur RPI heacuteberge cette application Linterface graphique du site web est
reacutealiseacute avec le template CSS proposeacute par Bootstrap [ httpsgetbootstrapcom ]
Figure 101 Architecture de notre application en PHP sur RPI
The Things Network
Notre Application
[ Serveur Apache sur Raspberry Pi ]
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 81
Nous allons lrsquoutiliser telle quelle Elle est juste proposeacutee agrave titre dexemple Lrsquoobjectif de cette
application est de geacuteneacuterer une ouverture fermeture de ruche agrave distance dans le cadre de projets
eacutetudiants du Master Electronique et Systegravemes Embarqueacutes de lUSMB [ httpscem-esetuniv-
smbfr ]
Figure 102 Application permettant de recevoir et deacutemettre des requecirctes HTTP POST
Configurer TTN pour pointer vers votre nouveau serveur et tester le flux montant et
descendant
| 82
9 Versions du document
Version 10 02022019
Version initiale
Version 20 23022019
Ajout drsquoun paragraphe Les systegravemes embarqueacutes dans lrsquoIoT En introduction
Compleacutement et ameacutelioration Ameacutelioration exercice eacutetalement de spectre
Correction Cacircblage Arduino
Ajout drsquoun paragraphe Fonctionnement de lrsquoArduino et ajout de librairies
Compleacutement et ameacutelioration Couche physique LoRa Ajout de 4 figures pour lrsquoexplication
de la modulation Chirp
Ajout drsquoun paragraphe sur les acronymes utiliseacutes au deacutebut du cours TTN LoRa MQTThellip
Compleacutement drsquoinformations sur les dB et dBm
Ajout LoRa Calculator
Version 30 8032019
Ajout de figure sur le rocircle de la Gateway LoRa
Ajout de paragraphe authentification avec le Network Server
Ajout de paragraphe sur le chiffrement avec lrsquoApplication Server
Ajout drsquoun sommaire en deacutebut de cours
Ajout de 2 scheacutemas ABP et OTAA
Retrait explication du deacutetail de la laquo Join Request raquo en OTAA Trop complexe attente de
reacutealisation drsquoun scheacutema plus explicite
Ajout drsquoun scheacutema sur lrsquoattaque par REPLAY
Ajout de paragraphe des diffeacuterents reacuteseaux LoRaWAN existants Opeacutereacutes et Priveacutes
Ajout des scheacutemas des trames LoRaWAN Physique LoRa MAC Application
Compleacutement drsquoinformation sur les Classes de Devices
Ajout drsquoun paragraphe sur la Gateway utiliseacutee pour le Downlink
Ajout drsquoun paragraphe sur le JSON
Compleacutement drsquoinformation sur le codage en Base64
Ajout drsquoinformation dans le deacutecodage des trames LoRaWAN
Restructuration des explications sur lrsquoenvoi et la reacutecupeacuteration des donneacutees en HTTPMQTT
Version 40 8032019
Ajout drsquoun chapitre Creacuteation de notre propre Application
Ajout drsquoun chapitre Creacuteation de notre propre Network et Application Server
Ajout drsquoune figure Visualisation des Chirps LoRa par SDR (Radio Logicielle)
Compleacutements drsquoinformation sur MQTT
Compleacutements dinformation sur les Topics de TTN en MQTT
| 11
En LoRa nous avons un Link Budget de 157 dB
En LTE (4G) nous avons un Link Budget de 130 dB
Etude de la documentation drsquoun composant LoRa Le RN2483 est le composant radiofreacutequence que nous utiliserons dans notre transmission LoRa
Voici quelques une de ses caracteacuteristiques
Figure 3 Caracteacuteristiques principales du composant radiofreacutequence utiliseacute
Reprenez la deacutefinition du Link Budget et retrouver les 157 dB annonceacute dans cette
documentation
En LoRa plus le code drsquoeacutetalement est grand plus on est capable drsquoeacutemettre dans un milieu bruiteacute La
figure ci-dessous preacutesente les rapports signal sur bruit avec lesquels nous seront capable de reacutealiser
une transmission en fonction des Spreading Factor utiliseacutes
Figure 4 Influence du Spreading Factor sur le SNR acceptable
On remarque que pour un SF8 nous sommes capables drsquoeacutemettre avec un SNR de -10 dB On pourra
transmettre malgreacute le fait que le bruit est 10 fois supeacuterieur au signal
On remarque que pour un SF12 nous sommes capables drsquoeacutemettre avec un SNR de -20 dB On
pourra transmettre malgreacute le fait que le bruit est 100 fois supeacuterieur au signal
| 12
Cependant on remarque aussi que lrsquoutilisation drsquoun Spreading Factor plus eacuteleveacute augmente
consideacuterablement le nombre de symbole eacutemis (2egraveme colonne du tableau) Comme nous le verrons
plus tard cela impactera eacutevidement le temps de transmission
| 13
3 La couche physique LoRa
31 La modulation LoRa Comme nous lrsquoavons expliqueacute plus tocirct la modulation LoRa utilise lrsquoeacutetalement de spectre pour
transmettre ces informations Mais au lieu drsquoutiliser des codes drsquoeacutetalement (CDMA) elle utilise une
meacutethode appeleacutee Chirp Spread Spectrum La finaliteacute est toujours la mecircme Avoir plusieurs
transmissions dans le mecircme canal La conseacutequence sur le spectre est aussi la mecircme cela provoque
un eacutetalement du spectre
311 La forme du symbole (Chirp) Le signal eacutemis par la modulation LoRa est un symbole dont la forme de base est repreacutesenteacutee ci-
dessous Son nom (Chirp) vient du fait que ce symbole est utiliseacute dans la technologie Radar (Chirp
Compressed High Intensity Radar Pulse)
Figure 5 Symbole de la modulation LoRa (source Wikipeacutedia)
La freacutequence de deacutepart est la freacutequence centrale du canal moins la Bande Passante diviseacutee par deux
La freacutequence de fin est la freacutequence centrale plus la Bande Passante diviseacutee par deux
La freacutequence centrale est appeleacutee le canal
La bande passante est la largeur de bande occupeacutee autour du canal
On considegravere une eacutemission sur la freacutequence centrale 868 Mhz avec une Bande Passante
de 125 kHz Donner la freacutequence de deacutebut et la freacutequence de fin du sweep
Freacutequence de deacutebut
Freacutequence de fin
Pour faciliter la repreacutesentation de ce symbole on utilise plutocirct un graphique TempsFreacutequence de
la forme suivante
| 14
Figure 6 Forme du symbole de base (CHIRP)
En LoRa chaque symbole repreacutesente un certain nombre de bits transmis La regravegle est la suivante
Nombre de bits transmis dans un symbole = Spreading Factor
Par exemple si la transmission utilise un Spreading Factor de 10 (SF10) alors un symbole repreacutesente
10 bits
Crsquoest-agrave-dire qursquoagrave lrsquoeacutemission les bits sont regroupeacutes par paquet de SF bits puis chaque paquet est
repreacutesenteacute par un symbole particulier parmi 2119878119865formes de symboles possibles
Sur la figure suivante voici un exemple theacuteorique drsquoune modulation en SF2 agrave 868 Mhz sur une
bande passante de 125 kHz Chaque symbole repreacutesente donc 2 bits
Figure 7 Symboles eacutemis en Modulation LoRa (Cas theacuteorique en SF2)
Exemple
On considegravere la suite binaire suivante 0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Le Spreading Factor utiliseacute est SF10
Nous regroupons donc les bits par paquet de 10 Chaque paquet de 10 bits sera repreacutesenteacute par un
symbole (sweep) particulier Il y a 1024 symboles diffeacuterents pour coder les 1024 combinaisons
binaires possibles (210)
Freacutequence
Temps
868 000 000 Hz
868 062 500 Hz
Un symbole Un symbole
867 937 500 Hz
Temps
868 000 000 Hz
867 937 500 Hz
Symbole 0
Bits laquo 00 raquo
Symbole 1
Bits laquo 01 raquo
Symbole 2
Bits laquo 10 raquo Symbole 3
Bits laquo 11 raquo
12
5 k
Hz
868 062 500 Hz
| 15
Figure 8 Emission des Chirp en LoRa
Avec un outils drsquoanalyse spectrale actif pendant lrsquoeacutemission LoRa drsquoun Device on peut afficher les
successions de symbole qui sont envoyeacutes Cette oscillogramme a eacuteteacute reacutealiseacute agrave lrsquoaide drsquoun SDR
(Software Digital Radio)
Figure 9 Visualisation des Chirps LoRa reacuteellement eacutemis pendant une transmission
312 Dureacutee drsquoeacutemission drsquoun symbole En LoRa la dureacutee drsquoeacutemission de chaque symbole (Chirp) deacutepend du Spreading Factor utiliseacute Plus le
SF est grand et plus le temps drsquoeacutemission sera long Pour une mecircme bande passante le temps
drsquoeacutemission drsquoun symbole en SF8 est deux fois plus long que le temps drsquoeacutemission drsquoun symbole en
SF7 Ainsi de suite jusqursquoagrave SF12
0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Envoi de 1 Chirp Envoi de 1 Chirp Envoi de 1 Chirp
Transmission Transmission Transmission
| 16
Figure 10 Temps drsquoeacutemission drsquoun symbole (Chirp) en fonction du SF
En revanche le temps drsquoeacutemission drsquoun symbole est inversement proportionnel agrave la bande passante
119879119904 =2119878119865
119861119886119899119889119908119894119889119905ℎ Le deacutebit des symboles est donc de
1
119879119878= 119865119904 =
119861119886119899119889119908119894119889119905ℎ
2119878119865 En toute logique plus la
bande passant est eacuteleveacute plus le deacutebit des symboles sera eacuteleveacute Comme chaque symbole comprend
SF bit on retrouve alors le deacutebit binaire
119863119887 = 119878119865119861119886119899119889119908119894119889119905ℎ
2119878119865
Plus le Spreading Factor sera eacuteleveacute plus le deacutebit binaire sera faible
Plus la Bande Passante sera eacuteleveacutee plus le deacutebit binaire sera fort
Exemple Drsquoapregraves la formule du deacutebit binaire trouver le deacutebit pour les deux cas suivants
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
32 Coding Rate Le Coding Rate est un ratio qui augmentera le nombre de bits agrave transmettre afin de reacutealiser de la
deacutetection correction drsquoerreur Dans le cas drsquoun CR = 4 8 il y aura 8 bits transmis reacuteellement agrave
chaque fois que nous souhaitons transmettre 4 bits Dans cette exemple cela provoque une
transmission drsquoun nombre de bit multiplieacute par 2
SF7
Freacutequence
Temps
Freacutequence centrale
Freacutequence haute
Temps drsquoun symbole eacutemit en SF 12
Freacutequence basse
SF8
SF9
SF10
SF11
SF12
Temps drsquoun symbole eacutemit en SF 11
| 17
Figure 11 Influence du Coding Rate sur le nombre de bits ajouteacute
Si on reprend lrsquoexemple preacuteceacutedent avec un CR de 4 5 nous avons une augmentation de 125 du
nombre de bits agrave transmettre Redonner la deacutebit en prenant en compte le CR
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
La documentation du composant RN2483 donne les deacutebits en fonction du Spreading Factor
la Bande Passante et le Coding Rate Veacuterifier la coheacuterence du reacutesultat avec votre calcul
preacuteceacutedent
Figure 12 Deacutebit en fonction des paramegravetres de la transmission LoRa
33 Utilisation du LoRa Calculator Le logiciel laquo LoRa Calculator raquo est un petit exeacutecutable permettant de simuler une transmission LoRa
en fonction des caracteacuteristiques saisies Canal SF CR etchellip Il est teacuteleacutechargeable agrave lrsquoadresse
suivante httpsbitly2TyloAh
| 18
Figure 13 Le logiciel LoRa Calculator
En reprenant lrsquoexemple preacuteceacutedent (SF7 Bande Passante 125 kHz CR 45) veacuterifier les
calculs du laquo Equivalent Bitrate raquo
34 Time On Air La norme LoRaWAN impose qursquoun Device LoRa ne transmette pas plus de 1 du temps Cela est
repreacutesenteacute par un Duty Cycle Par exemple un Duty Cycle de 1 signifie que si jrsquoeacutemet pendant 1 je
ne dois plus eacutemettre pendant 99 quel que soit lrsquouniteacute de temps utiliseacutee
En reprenant les exemples preacuteceacutedents quels sont les deacutebits moyens si on prend en compte
le laquo Time On Air raquo
Cas 1 Pour SF7 et 125 khz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
Dans le logiciel laquo LoRa Calculator raquo (onglet laquo Energy Profile raquo) nous pouvons estimer la
dureacutee de vie drsquoune batterie Nous prenons lrsquoexemple drsquoun releveacute de tempeacuterature dans un
bacirctiment avec les caracteacuteristiques suivantes
| 19
SF CR Bande Passante etc Nous nous placcedilons dans le cas 1 des exemples preacuteceacutedents
Le releveacute de tempeacuterature se fera toutes les 15 mins
La batterie est constitueacute de 3 petites piles bacirctons [ AAA LR03 ] 12V en seacuterie Soit 36 V
1000 mAh
35 Mise en œuvre LoRa en point agrave point Ce test sera reacutealiseacute avec des modules LoRa RN2483 (Microchip) et une carte microcontrocircleur
ARDUINO
Figure 14 Communication LoRa en Point agrave Point
Reacutealiser le cacircblage de votre module RN2483 suivant le tableau suivant
Connecteur Arduino Click Board RN2483
5V 5V
GND GND
11 RX
10 TX
Tableau 4 Cacircblage de lrsquoARDUINO et de la click Board RN2483
351 Utilisation de lrsquoIDE Arduino Lrsquoenvironnement Arduino est tregraves simple Nous allons reacutealiser un programme pour montrer son
fonctionnement
La connexion de la carte est effectueacutee agrave lrsquoaide drsquoun port USB qui eacutemule une liaison seacuterie
RS232 Il faut donc choisir le bon port Arduino IDE gt Outils gt Port
Pour creacuteer un nouveau programme (sketch) Arduino IDE gt Fichier gt Nouveau
Il y a deux parties dans un sketch
Une fonction setup() qui sera exeacutecuteacutee qursquoune seule fois au deacutemarrage
Une fonction loop() qui sera exeacutecuteacutee en boucle
Ecrire le code suivant
Emetteur
Reacutecepteur
UA
RT
UA
RT
| 20
void setup()
Serialbegin(9600)
void loop()
Serialprintln(hello word)
Compiler et Teacuteleacuteverser Croquis gt Teacuteleacuteverser
Voir la sortie sur la liaison seacuterie Outils gt Moniteur Seacuterie gt Choisir la vitesse de
transmission ici 9600 bauds (en bas agrave droite)
352 Validation du fonctionnement Deux binocircmes joueront le rocircle drsquoeacutemetteur tous les autres binocircmes seront en reacutecepteur
Reacutecupeacuterer les programmes dans Moodle dans le dossier laquo RN2483-Arduino-Point2Point raquo
Installer la librairie RN2483 Arduino IDE gt Croquis gt Inclure une bibliothegraveque gt Ajouter la
bibliothegraveque zip
Reacutepartissez les rocircles Emetteurs Reacutecepteurs et reacutecupeacuterer le programme LoraBlinkerRX ou
LoraBlinkerTX en fonction Les 2 binocircmes en eacutemission devront modifier le code du sketch
Arduino pour transmettre des donneacutees speacutecifiques afin de les diffeacuterencier [
loraSerialprintln(radio tx 30) ]
Validez la reacuteception des donneacutees eacutemises par les deux binocircmes qui transmettent des
donneacutees Ces donneacutees reccedilues sont eacutecrite agrave 57600 bauds sur le moniteur seacuterie de lrsquoArduino
353 Mise en valeur du Spreading Factor On srsquoaperccediloit dans la manipulation preacuteceacutedente que les Devices LoRa reccediloivent les donneacutees des deux
eacutemetteurs Nous allons conserver le mecircme canal drsquoeacutemission (8691 Mhz) mais un des deux
eacutemetteurs va modifier son laquo Spreading Factor raquo La salle sera donc seacutepareacutee en deux groupes
1er groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF7
2egraveme groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF8
Validez la reacuteception des donneacutees eacutemises seulement pour le Spreading Factor que vous
utilisez
| 21
4 Le protocole LoRaWAN
Le LoRa est le type de modulation utiliseacute entre deux Devices ou entre un Device et une Gateway
Lorsque nous parlons de lrsquoensemble de la chaine de communication (Device Gateway Serveur) alors
nous parlons de communication LoRaWAN Nous allons voir lrsquoarchitecture drsquoun reacuteseau LoRaWAN
ainsi que les regravegles de ce protocole
41 Structure drsquoun reacuteseau LoRaWAN Nous retrouvons drsquoun cocircteacute le Device LoRa qui transmet une donneacutee Elle est reacuteceptionneacutee agrave lrsquoautre
extreacutemiteacute du reacuteseau par un Utilisateur La structure globale du reacuteseau LoRaWAN peut ecirctre
repreacutesenteacutee par la figure suivante
411 Les Devices LoRa Les Devices LoRa sont des systegravemes eacutelectroniques appartenant au monde de lrsquoIoT Faible
consommation faible taille faible puissance et faible taille
Ils possegravedent une radio LoRa permettant de joindre les Gateways Les Gateways ne sont pas
adresseacutees speacutecifiquement toutes celles preacutesentes dans la zone de couverture reccediloivent les
messages et les traitent
412 Les Gateways LoRa Elles eacutecoutent sur tous les canaux et sur tous les Spreading Factor Lorsqursquoune trame LoRa est reccedilue
elle transmet son contenu sur internet agrave destination du Network Server qui a eacuteteacute configureacute dans la
Gateway au preacutealable
Elle joue donc le rocircle de passerelle entre une modulation LoRa et une communication IP
Devices
LoRa Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
Internet Internet
Figure 15 Structure globale dun reacuteseau LORAWAN
| 22
Chaque Gateway LoRa possegravede un identifiant unique (EUI sur 64 bits)
413 Le Network Server
Le Network Server reccediloit les messages transmis par les Gateways et supprime les doublons
(plusieurs Gateway peuvent avoir reccedilu le mecircme message) Les informations transmises au Network
Server depuis les Devices LoRa sont authentifieacutes gracircce agrave une cleacute AES 128 bits appeleacutee Network
Session Key NwkSKey Nous parlons bien ici drsquoauthentification et non pas de chiffrement comme
nous le verrons plus tard
414 Application Server Il est souvent sur le mecircme support physique que le Network Server Il permet de dissocier les
applications les unes des autres Chaque application enregistre des Devices LoRa qui auront le droit
Devices Gateways Network
Server
Internet
Network Session Key (NwkSKey)
Authentification
Figure 17 Authentification entre le Device LoRa et le Network Server
Internet
UDP IP
Modulation
LoRa
Device LoRa
Gateway
Network Server
LoRaWAN
Modulation
LoRa
Passerelle LoRa Internet
Internet
UDP IP
LoRaWAN
Transmission Radio
Application Application
Figure 16 Le rocircle de la Gateway LoRa
| 23
de stocker leurs donneacutees (Frame Payload) Les message transmis agrave lrsquoapplication server sont chiffreacutes
gracircce agrave une cleacute AES 128 bits appeleacutee Application Session Key AppSKey
Le scheacutema suivant reacutesume lrsquoutilisation
De la Network Session Key (NwkSKey) pour lrsquoauthentification entre le Device LoRa et le
Network Server
De lrsquoApplication Session Key (AppSKey) pour le chiffrement entre le Device LoRa et
lrsquoApplication Server
Devices Gateways Network
Server Application
Server
Internet
Application Session Key (AppSKey)
Chiffrement
Figure 18 Chiffrement entre le Device LORA et lrsquoApplication Server
| 24
415 Application Web Serveur Cette application doit drsquoune part reacutecupeacuterer les donneacutees de lrsquoApplication Serveur Dans le cadre de
ce cours cela sera fait de deux faccedilons
Avec le protocole HTTP
Avec le protocole MQTT
Figure 20 Application Web Server
Figure 19 Authentification et chiffrement en LoRaWan
Devices Gateways
Network
Server Application
Server
Internet
Network Session Key
Application Session Key
Network
Server Application
Server
Application
Server Web
Utilisateur
Protocole
MQTT ou HTTP
Flux Uplink
Flux Downlink
| 25
Le flux habituel dans lrsquoIoT est le flux Uplink (flux montant) crsquoest-agrave-dire lrsquoeacutemission de donneacutees des
objets vers le serveur Comme nous lrsquoexpliquerons plus loin en LoRaWAN il est aussi possible de
transfeacuterer des donneacutees aux Device LoRa par un flux Downlink (flux descendant)
Drsquoautre part lrsquoapplication mettra agrave disposition les donneacutees aux utilisateurs sous forme par exemple
drsquoun serveur web drsquoune base de donneacutees et drsquoune visualisation graphique
416 Authentification avec le Network Server La Network Session Key (NwkSKey) sert agrave lrsquoauthentification entre le Device LoRa e le Network Server
Afin de reacutealiser cette authentification entre le Device et le Network Server un champ MIC (Message
Integrity Control) est rajouteacute agrave la trame Il est calculeacute en fonction des donneacutees transmises et du
NwkSkey A la reacuteception le mecircme calcul est effectueacute Si les cleacutes sont eacutequivalentes dans le Device et
dans le Network Server alors les deux MIC calculeacutes doivent correspondre
417 Chiffrement des donneacutees vers lrsquoApplication Server
LrsquoApplication Session Key (AppSKey) sert pour le chiffrement entre le Device LoRa et lrsquoApplication
Server Les donneacutees chiffreacutees seront alors deacutecodeacutees agrave la reacuteception sur lrsquoApplication Server srsquoil
possegravede la mecircme cleacute Si on reprend le scheacutema preacuteceacutedent les laquo donneacutees x raquo sont chiffreacutees
deacutechiffreacutees par le processus suivant
Donneacutees x chiffreacutees NwkSkey x
MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees
NwkSkey x
Trame eacutemise Trame reccedilue
Device LoRa Network Server
Si =
Alors la trame est authentifieacutee
MIC geacuteneacutereacute Emission MIC geacuteneacutereacute Reacuteception
MIC geacuteneacutereacute Reacuteception
Figure 21 Authentification dun Device LoRa par le Network Server
| 26
Figure 22 Chiffrement des donneacutees par lApplication Session Key
418 Combinaison de lrsquoauthentification et du chiffrement On peut maintenant repreacutesenter sur le mecircme scheacutema la construction de la trame LoRaWAN avec
drsquoune part lrsquoauthentification et drsquoautre part le chiffrement
Figure 23 Chiffrement puis Authentification
42 Classes des Devices LoRaWAN Les Devices LoRa sont classeacutes en 3 cateacutegories (A B C) en fonction de leur consommation et de leur
accessibiliteacute en Downlink crsquoest-agrave-dire la faciliteacute qursquoun utilisateur aura agrave transmettre une trame au
Device LoRa
421 Classe A (All) Minimal power Application Tous les Devices LoRaWAN sont de classe A Chaque Device peut transmettre (Uplink) agrave la Gateway
sans veacuterification de la disponibiliteacute du reacutecepteur Si la transmission eacutechoue elle sera reacuteeacutemise apregraves
un certain temps Cette transmission est suivie de 2 fenecirctres de reacuteception tregraves courtes La Gateway
peut alors transmettre pendant le laquo RX Slot 1 raquo ou le laquo RX Slot 2 raquo mais pas les deux
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Device LoRa
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Application Server
Donneacutees non chiffreacutees
AppSKey
Donneacutees chiffreacutees Entecircte
NwkSKey
MIC geacuteneacutereacute en eacutemission Trame transmise =
| 27
Figure 24 Slots de reacuteception pour un Device LoRa de classe A
Source de lrsquoimage httpszakelijkforumkpncom
La dureacutee des fenecirctres doit ecirctre au minimum la dureacutee de reacuteception drsquoun preacuteambule Un preacuteambule
dure 1225 Tsymbole et deacutepend donc du Data Rate (DR voir paragraphe 445 pour plus drsquoinformation
sur le DR) Lorsque qursquoun preacuteambule est deacutetecteacute le reacutecepteur doit rester actif jusqursquoagrave la fin de la
transmission Si la trame reccedilue pendant la premiegravere fenecirctre de reacuteception eacutetait bien agrave destination du
Device LoRa alors la deuxiegraveme fenecirctre nrsquoest pas ouverte
Premiegravere fenecirctre de reacuteception
Le Slot RX1 est programmeacute par deacutefaut agrave 1 seconde + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont les mecircme que ceux choisis lors de la phase drsquoeacutemission
(Uplink)
Seconde fenecirctre de reacuteception
Le Slot RX2 est programmeacute par deacutefaut agrave 2 secondes + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont configurables mais fixes
Un Device LoRa qui est uniquement de classe A ne peut pas recevoir srsquoil nrsquoa pas eacutemis Il
nrsquoest donc pas joignable facilement
422 Classe B (Beacon) Scheduled Receive Slot Les Devices de classe B ont le mecircme comportement que les Devices de classe A mais drsquoautres
fenecirctres de reacuteceptions sont programmeacutees agrave des peacuteriodes preacutecises Afin de synchroniser les fenecirctres
de reacuteception du Device LoRa la Gateway doit transmettre des balises (Beacons) de faccedilon reacuteguliegravere
| 28
Figure 25 Slots de reacuteception pour un Device LoRa de classe B
Source de lrsquoimage httpszakelijkforumkpncom
Un Device LoRa de classe B est joignable reacuteguliegraverement sans qursquoil soit neacutecessairement
obligeacute drsquoeacutemettre En revanche il consomme plus qursquoun Device de classe A
423 Classe C (Continuous) Continuously Listening Les Devices de classe C ont des fenecirctres de reacuteception constamment ouvertes entre 2 Uplinks Ces
Devices consomment donc beaucoup plus
Figure 26 Slots de reacuteception pour un Device LoRa de classe C
Source de lrsquoimage httpszakelijkforumkpncom
| 29
Un Device LoRa de classe C est joignable en permanence En revanche crsquoest la classe de
Device qui est la plus eacutenergivore
424 Quelle Gateway pour les flux Downlink
Nous avons donc vu que le fonctionnement classique du protocole LoRaWAN eacutetait de reacutecupeacuterer de
lrsquoinformation depuis le Device LoRa Crsquoest le flux Uplink
Dans le cas ougrave lrsquoutilisateur transmet des informations au Device LoRa (flux Downlink) on peut se
demander quelle Gateway sera choisie pour transfeacuterer les donneacutees au Device LoRa En effet
lrsquoendroit ougrave est situeacute le Device LoRa nrsquoest pas neacutecessairement connu agrave lrsquoavance
La Gateway utiliseacutee pour le Downlink est celle qui a reccedilu le dernier message du Device
LoRa Un message ne pourra jamais arriver agrave destination drsquoun Device LoRa si celui-ci nrsquoa
jamais transmis quel que soit sa classe A B ou C
43 Activation des Devices LoRa et seacutecuriteacute En LoRaWAN les trois eacuteleacutements indispensables pour la communication sont le DevAddr pour
lrsquoindentification du Device ainsi que deux cleacutes le NwkSKey pour lrsquoauthentification et lrsquoAppSKey
pour le chiffrement Deux meacutethodes sont possibles pour fournir ces informations agrave la fois au Device
LoRa et au serveur
Activation By Personalization APB
Over The Air Activation
431 ABP Activation By Personalization Crsquoest la plus simple des meacutethodes Crsquoest donc peut ecirctre celle que nous avons tendance agrave utiliser lors
drsquoun test de prototype et drsquoune mise en place de communication LoRaWAN
Le Device LoRa possegravede deacutejagrave le DevAddr lrsquoAppSKey et le NwkSKey
Le Network server possegravede deacutejagrave le DevAddr et le NwkSKey
Lrsquoapplication serveur possegravede deacutejagrave le DevAddr et le AppSKey
En ABP toutes les informations neacutecessaires agrave la communication sont deacutejagrave connues par le
Device LoRa et par le Serveur
| 30
432 OTAA Over The Air Activation Crsquoest la meacutethode qursquoil faut privileacutegier car crsquoest celle qui est la plus seacutecuriseacutee Le Device LoRa doit
connaitre le DevEUI lrsquoAppEUI et lrsquoAppkey Le Network Server doit lui connaitre la mecircme Appkey
Tous les eacuteleacutements noteacutes EUI (Extended Unique Identifier) sont toujours sur une taille de
64 bits
Gracircce agrave ces informations de deacutepart et une neacutegociation avec le Network Server (Join Request) le
Device LoRa et le serveur vont geacuteneacuterer les informations essentielles DevAddr NwkSKey et
AppSKey
Figure 28 Obtention du DevAddr NwkSKey et AppSKey en OTAA
DevEUI Unique Identifier pour le device LoRa (Equivalent agrave une MAC sur Ethernet)
Certains Device LoRa ont deacutejagrave un DevEUI fourni en usine
AppEUI Unique Identifier pour lrsquoapplication server
DevEUI
AppEUI
AppKey
Join
Request
DevAddr
NwkSKey
AppSKey
Network Server
Application Server
Devices 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 2
NwkSkey 2
AppSKey 2
Devices 2
DevAddr 2
NwkSkey 2
AppSKey 2
Paramegravetres stockeacutes sur le serveur
Paramegravetres programmeacutes
dans le composant
Figure 27 Parameacutetrage de DevAddr NwkSKey et AppSKey
| 31
AppKey AES 128 cleacute utiliseacutee pour geacuteneacuterer le MIC (Message Code Integrity) lors de la Join
Resquest Il est partageacute avec le Network server
NwkSKey Utiliseacute pour lrsquoauthentification avec le Network Server
AppSKey Utiliseacute pour le chiffrement des donneacutees
433 Seacutecuriteacute Les cleacutes AES 128 bits permettent le chiffrement des informations transmises en LoRaWAN Malgreacute
ce chiffrement une attaque connue en Wireless est celle du REPLAY Crsquoest-agrave-dire que le Hacker
enregistre des trames chiffreacutees circulant sur le reacuteseau LoRa pour les reacuteeacutemettre plus tard Mecircme si
le Hacker ne comprend pas le contenu (les trames sont chiffreacutees) les donneacutees qui sont transporteacutees
sont elles bien comprises par lrsquoApplication Server Des actions peuvent donc ecirctre reacutealiseacutees
simplement par mimeacutetisme
Pour eacuteviter cela la trame LoRaWAN integravegre un champ variable appeleacute laquo Frame Counter raquo Il srsquoagit
drsquoun nombre numeacuterotant la trame sur 16 ou 32 bits LrsquoApplication Server acceptera une trame
uniquement si le laquo Frame Counter raquo reccedilu est supeacuterieur au laquoFrame Counter raquo preacuteceacutedemment Donc
si le Hacker retransmet la trame telle qursquoelle le laquo Frame Counter raquo sera eacutequivalent donc la trame
sera refuseacutee Et comme la trame est chiffreacutee le Hacker nrsquoa pas moyen de savoir comment modifier
un champ de cette trame
Cette seacutecuriteacute impleacutementeacutee par les laquo Frame Counter raquo est inteacuteressante pour srsquoaffranchir drsquoune
attaque par REPLAY mais dans nos tests cela peut poser problegraveme En effet agrave chaque fois que nous
redeacutemarrons le microcontrocircleur notre laquo Frame Counter raquo revient agrave zeacutero alors que celui de
lrsquoApplication Server continue de srsquoincreacutementer Cela peut ecirctre reacutesolue par diffeacuterentes maniegraveres
1 Deacutesactivation du laquo Frame Counter Check raquo Dans certain Application Server cette option
peut ecirctre proposeacutee Bien sucircr il faudra garder en tecircte la faille de seacutecuriteacute que cela engendre
Network Server
Application Server
Devices LoRa
NwkSkey
AppSKey
NwkSkey
AppSKey Hacker
(1) (2)
(1) Ecoute
(2) Reacuteeacutemission
Figure 29 Attaque par REPLAY
| 32
Figure 30 Deacutesactivation du Frame Counter Check dans TTN
2 Utiliser lrsquoauthentification par OTAA au lieu de ABP En effet agrave chaque ouverture de session
en OTAA le laquo Frame Counter raquo est reacuteinitialiseacute coteacute serveur
3 Conserver la valeur du laquo Frame Counter raquo dans une meacutemoire non volatile et reacutecupeacuterer sa
valeur au deacutemarrage du Device LoRa
44 La Trame LoRa LoRaWAN
441 Les couches du protocole LoRaWAN
Lorsque nous avons fait une communication en Point agrave Point nous avons simplement utiliseacute la
couche physique de la modulation LoRa Lorsque nous souhaitons utiliser le protocole LoRaWAN
des couches protocolaires suppleacutementaires se rajoutent
Figure 31 Les couches protocolaires du LoRaWAN
Chaque couche rajoute un service Lors de lrsquoenvoi de la trame les donneacutees utilisateurs sont donc
encapsuleacutees dans chaque couche infeacuterieure jusqursquoagrave la transmission Le deacutetail de lrsquoensemble de la
trame LoRaWAN par couche est deacutecrit sur la figure Figure 32
LoRa Modulation
LoRa Mac
Application
Couche Physique
Couche Mac
Couche Application
| 33
442 Couche Application La couche Application accueille les donneacutees de lrsquoutilisateur Avant de les encapsuler elles sont
chiffreacutees avec lrsquoAppSKey afin de seacutecuriser la transaction
Un ensemble de champs nommeacute Frame Header permet de speacutecifier le DevAddr le Frame Control
le Frame Counter et le Frame Option
Le Frame Port deacutepend du type drsquoapplication et sera choisi par lrsquoutilisateur
Le Frame Payload sont les donneacutees chiffreacutees agrave transmettre Le nombre drsquooctets maximum pouvant
ecirctre transmis (N octets) est donneacute dans le tableau suivant
PHY Payload
P octets Couche
Physique
Couche
Mac
Couche
Application
CRC
2 octets Header + Header CRC
20 bits Preamble
MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Figure 32 Trame LORAWAN complegravete par couche protocolaire
Couche
Application Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Frame Header
Figure 33 Trame LORA couche Applicative
| 34
Data Rate Spreading Factor Bandwidth Max Frame Payload (Nombre N) DR 0 SF12 125 KHz 51 octets
DR 1 SF11 125 KHz 51 octets
DR 2 SF10 125 KHz 51 octets
DR 3 SF9 125 KHz 115 octets
DR 4 SF8 125 KHz 222 octets
DR 5 SF7 125 KHz 222 octets
DR 6 SF7 250 KHz 222 octets
Tableau 5 Taille maximum du Frame Payload en fonction du Data Rate
443 Couche LoRa MAC Cette trame est destineacutee au Network Server Elle est authentifieacutee gracircce au champ MIC (Message
Integrity Protocol) selon la meacutethode expliqueacutee au paragraphe 416
Le protocole LoRa MAC est composeacute de
1 MAC Header Version de protocole et type de message
Type de Message Description 000 Join-Request
001 Join-Accept
010 Unconfirmed Data Up
011 Unconfirmed Data Down
100 Confirmed Data Up
101 Confirmed Data Down
110 Rejoin-request
111 Proprietary
Tableau 6 Les types de messages transmis en LoRaWAN
2 MAC Payload Contient tout le protocole applicatif
3 MIC Message Integrity Code pour lrsquoauthentification de la trame
444 Couche physique Modulation LoRa
Le choix du moment drsquoeacutemission des Devices LoRa se fait de faccedilon simple Lorsqursquoun eacutequipement
doit eacutemettre il le fait sans controcircle et ne cherche pas agrave savoir si le canal est libre Si le paquet a eacuteteacute
perdu il le retransmettra simplement au bout drsquoun temps aleacuteatoire La couche physique est
repreacutesenteacutee par lrsquoeacutemission de la trame suivante
Couche
Mac MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Figure 34 Trame LORA couche LORA MAC
| 35
Le Preacuteambule est repreacutesenteacute par 8 symboles + 425 Le temps du Preacuteambule est donc de 1225
Tsymbole
Len-tecircte (Header optionnel) est seulement preacutesent dans le mode de transmission par deacutefaut
(explicite) il est transmis avec un Coding Rate de 48 Il indique la taille des donneacutees le Coding Rate
pour le reste de la trame et il preacutecise eacutegalement si un CRC sera preacutesent en fin de trame
Le PHY Payload contient toutes les informations de la Couche LoRa MAC
Le CRC sert agrave la deacutetection drsquoerreur de la trame LoRa
445 Canaux et bandes de freacutequences et Data Rate (DR) Le LoRa utilise des bandes de freacutequences diffeacuterentes suivant les reacutegions du monde En Europe la
bande utiliseacutee est celle des 868 Mhz [ De 863 Mhz agrave 870 Mhz ] Le LoRaWAN deacutefinie les 8 canaux agrave
utiliser pour communiquer avec une Gateway suivant le tableau suivant
Canaux Spreading Factor Bandwidth 8681 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz SF7 250 kHz
8685 Mhz De SF7 agrave SF12 125 kHz
8671 Mhz De SF7 agrave SF12 125 kHz
8673 Mhz De SF7 agrave SF12 125 kHz
8675 Mhz De SF7 agrave SF12 125 kHz
8677 Mhz De SF7 agrave SF12 125 kHz
8679 Mhz De SF7 agrave SF12 125 kHz
Tableau 7 Canaux SF et Bandwidth de notre Gateway LoRaWAN
Une Gateway LoRa eacutecoute donc sur 8 canaux simultaneacutement avec les 6 Spreading Factor
diffeacuterents soit 48 combinaisons possibles
Comme nous lrsquoavons vu le Spreading Factor a des conseacutequences sur le deacutebit de la transmission Ces
deacutebits sont noteacutes DR (Data Rate) et sont normaliseacutes de DR0 agrave DR6
PHY Payload
P octets Couche
Physique CRC
2 octets Header + Header CRC
( Optionnel ) 20 bits Preamble
Figure 35 Trame LORA couche Physique
| 36
Data Rate Spreading Factor Bandwidth DR 0 SF12 125 KHz
DR 1 SF11 125 KHz
DR 2 SF10 125 KHz
DR 3 SF9 125 KHz
DR 4 SF8 125 KHz
DR 5 SF7 125 KHz
DR 6 SF7 250 KHz
Tableau 8 Deacutenomination DR en fonction du SF et de la Bande Passante
446 Trame reccedilue et transmise par la Gateway LoRaWAN La Gateway reccediloit drsquoun cocircteacute un message radio moduleacute en LoRa et transmet de lrsquoautre cocircteacute une trame
IP agrave destination du Network Server
Coteacute interface Radio La Gateway reacuteceptionne une trame LoRaWAN et extrait le PHY Payload Celui-
ci est codeacute au format ASCII en base 64 (voir le paragraphe 541) La Gateway extrait aussi toutes les
informations utiles sur les caracteacuteristiques de la reacuteception qui a eu lieu SF Bandwidth RSSI Time
On Airhellipetchellip
Coteacute interface reacuteseau IP La Gateway transmet lrsquoensemble de ces informations dans un paquet IP
(UDP) au Network Server Les donneacutees transmises sont du texte en format JSON (voir paragraphe
447) La Gateway a donc bien un rocircle de passerelle entre le protocole LoRa drsquoun cocircteacute et un reacuteseau
IP de lrsquoautre
Internet
UDP IP
Device LoRa
Gateway
Network Server Modulation
LoRa
Passerelle LoRa Internet
Transmission Radio Internet
Figure 36 Rocircle de la Gateway LoRa
| 37
447 Le format JSON Le format JSON est un format texte composeacute drsquoune succession de couple nomvaleur Dans
lrsquoexemple de la figure preacuteceacutedente gw_id est un nom et eui-b827ebfffeae26f5 est la valeur
associeacutee Dans cette exemple la valeur est un string Les objets sont deacutelimiteacutes par un des accolades
et
Une valeur peut ecirctre
Un string exemple coding_rate 45
Un nombre exemple spreading_factor 12
Un objet exemple lora spreading_factor 12 air_time 2465792000
Un Boolean
Ethernet
Gateway
Modulation
LORA
Reacutecupeacuteration du PHY PAYLOAD en base 64
Reacutecupeacuteration des caracteacuteristiques de la transmission Canal SF CR hellip
IP (IP dest routereuthethingsnetwork)
UDP (Port dest 1700 Port source 1700)
Donneacutees applicatives (format JSON)
gw_id eui-b827ebfffeae26f5
payload QNAPvA6Ax3ECqHk4C8hfzuA==
lora
spreading_factor 12
bandwidth 125
air_time 2465792000
coding_rate 45
timestamp 2019-01-20T133746017Z
rssi -105
snr -162
dev_addr 0EBC0FD0
frequency 867100000
Internet Transmission Radio LORA
Figure 37 Passerelle (Gateway) LORAWAN
| 38
5 Mise en œuvre drsquoun reacuteseau LoRaWAN
51 Les diffeacuterents types de reacuteseaux Les reacuteseaux LoRaWAN peuvent ecirctre utiliseacute suivant deux meacutethodes
En utilisant les reacuteseaux LoRaWAN opeacutereacutes proposeacutes par les opeacuterateurs de teacuteleacutecoms
En utilisant votre propre reacuteseau LoRaWAN priveacute
511 Les reacuteseaux LoRaWAN opeacutereacutes Ce sont des reacuteseaux LoRaWAN proposeacutes par les opeacuterateurs Par exemple Objenious (filiale de
Bouyges) ou encore Orange Dans le cas de lrsquoutilisation des reacuteseaux opeacutereacutes lrsquoutilisateur a juste
besoin de srsquooccuper des Devices LoRa Les Gateways le Network Server et lrsquoApplication Server sont
geacutereacutes par lrsquoopeacuterateur
512 Les reacuteseaux LoRaWAN priveacutes Chacun est libre de reacutealiser son propre reacuteseau priveacute en impleacutementant sa propre Gateway pour
communiquer avec ses Devices LoRa Lrsquoimpleacutementation du Network Server et de lrsquoApplication Server
peuvent alors ecirctre envisageacutes de diffeacuterentes faccedilons
Network Server et Application serveur priveacutees Crsquoest le deacuteveloppeur qui les mets en place Dans
certaines Gateways une impleacutementation de ces deux serveurs est deacutejagrave proposeacutee Sinon il est
possible de la mettre en place Il existe des serveurs (Network et Application) open source crsquoest le
cas par exemple de LoRa Serveur [ wwwloraserverio ]
Une autre alternantive est httpsgithubcomgotthardplorawan-server
LoRaServer et lorawan-server sont deux applications Open Source
Network Server et Application Server en ligne Un certain nombre de Network Server et
drsquoApplication Server sont proposeacutes Ce sont des services payants ou avec des contreparties
Loriot [ wwwloriotio ]
ResIoT [ wwwresiotio ]
The Things Network [ wwwthethingsnetworkorg ] Crsquoest la solution que nous utiliserons
513 Les zones de couvertures
Les zones de couvertures des reacuteseaux opeacutereacutes sont mise agrave jour par les opeacuterateurs celle drsquoobjenious
est par exemple disponible ici httpsobjeniouscomreseau
Pour connaitre la zone de couverture de notre Gateway utiliseacutee avec TTN nous pouvons utiliser
lrsquoapplication TTN Mapper httpsttnmapperorg Lrsquoideacutee est de promener son Device LoRa associeacute
agrave un GPS dans la zone de couverture des Gateway qui nous entourent A chaque trame reccedilue par le
| 39
Serveur on note les coordonneacutees GPS du Device LoRa ainsi que la Gateway qui a transmis le
message Toutes ces informations sont alors retranscrites sur une carte
52 The Things Network (TTN)
521 Preacutesentation de TTN
Pour la suite nous utiliserons le Network Server et lrsquoApplication Server fourni par TTN
[wwwthethingsnetworkorg]
TTN est gratuit et Open Source En revanche le fait drsquoutiliser TTN impose agrave ceux qui enregistrent
des Gateways de les mettre agrave disposition agrave tous les autres utilisateurs de TTN Lrsquoobjectif est de
reacutealiser un reacuteseau global ouvert
522 Configuration de la Gateway A lrsquouniversiteacute nous avons deux Gateways LoRa (Marque EBDS) Elles sont toutes les deux situeacutees sur
le Campus de Technolac Une Gateway est agrave lrsquointeacuterieur du bacirctiment ISERAN et sert essentiellement
pour les Travaux Pratiques et formations Lrsquoautre est sur le toit du bacirctiment Chablais et est mise agrave
disposition du public via le service de TTN
Les deux Gateway eacutecoutent sur tous les canaux et sur tous les Spreading Factor SF7 gt SF12
Lrsquo IP de la Gateway LoRa agrave lrsquouniversiteacute (bacirctiment ISERAN) est 192168140196
Serveur DNS 1934812032 19348129137
Network Server (TTN) 137616868 routereuthethingsnetwork
Port Upstream 1700 Port Downstream 1700
523 Enregistrement des Gateways Appplication et Devices La configuration de TTN se fait en ligne La premiegravere opeacuteration agrave reacutealiser lorsqursquoune nouvelle
Gateway est deacuteployeacutee crsquoest de lrsquoenregistrer dans TTN
Enregistrement drsquoune Gateway LoRa TTN gt Console gt Gateway gt register gateway
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Figure 38 Scheacutema de notre application
| 40
Figure 39 Enregistrement dune Gateway LoRa sur TTN
Enregistrement drsquoune application TTN gt Console gt Application gt add application
Figure 40 Enregistrement dune application sur TTN
Enregistrement des Devices LoRa dans lrsquoapplication Nom de lrsquoapplication gt register device
Figure 41 Enregistrement des Devices LoRa dans une application
524 Configuration des Devices LoRa Lorsque nous avons enregistreacute des Devices LoRa dans TTN nous devons choisir entre les deux modes
drsquoauthentification Dans un premier temps nous utiliserons le mode le plus simple qui est ABP Nous
geacuteneacuterons dans TTN les DevAddr NetwkSKey et AppSKey
| 41
Figure 42 Configuration des Devices LoRa en ABP dans TTN
53 Mise en application Nous avons dans notre application 10 Devices LoRa drsquoenregistreacutes aduino0 agrave arduino9 Ils sont tous
configureacutes en ABP Les configurations des 10 Devices (DevAddr NetwkSKey et AppSKey) sont noteacutes
en commentaire dans le code de vous allez reacutecupeacuterer
Reacutecupeacuterer le code Arduino laquo RN2483-Arduino-LORAWANino raquo dans Moodle
Modifier votre configuration (DevAddr NetwkSKey et AppSKey) en fonction de votre
numeacutero de binocircme
Veacuterifier que votre Device LoRa arrive bien agrave transmettre des informations (Uplink) vers la
Gateway puis vers le Network Serveur de TTN (The Things Network)
54 Analyse des trames eacutechangeacutees
541 Utilisation de la base 64 Notre Gateway nous preacutesente le Payload PHY en base64 Lrsquoexplication de la meacutethode de
repreacutesentation en base 64 est fourni au travers drsquoun exemple Le code hexadeacutecimal 0x4869
repreacutesente nos donneacutees binaires que nous souhaitons transmettre en base 64
1 On eacutecrit les donneacutees agrave transmettre en binaire
2 On regroupe les eacuteleacutements binaires par des blocs de 6 bits Le nombre de bloc de 6 bits doit
ecirctre un multiple de 4 (minimum 4 blocs) Srsquoil manque des bits pour constituer un groupe de
6 bits on rajoute des zeacuteros
0x4869 = 0100 1000 0110 1001
| 42
3 Srsquoil manque des blocs pour faire un minimum de 4 blocs des caractegraveres speacuteciaux seront
ajouteacutes
4 Chaque groupe de 6 bits est traduit par le tableau suivant (Source Wikipeacutedia)
Figure 43 Codage en base 64
5 Si un bloc de 6 bits manque (ils doivent ecirctre un multiple de 4) on rajoute un ou plusieurs
compleacutements (caractegravere laquo = raquo )
Reacutesultat Le codage de 0x4869 en base 64 est laquo SGk= raquo
010010 000110 100100
On ajoute 00 pour avoir
6 bits dans le groupe
Bloc de 6 bits
010010 000110 100100
S G k
010010 000110 100100
S G k =
1er Bloc
2egraveme Bloc
3egraveme Bloc
4egraveme Bloc
| 43
542 Inteacuterecirct et inconveacutenient de la base 64 Lrsquoutilisation de la base 64 est un choix qui a eacuteteacute fait pour le protocole LoRa LoRaWAN afin de rendre
les donneacutees binaires lisibles Le problegraveme du code ASCII crsquoest qursquoil est composeacute drsquoun certain nombre
de caractegraveres non imprimables (EOF CR LFhellip) Pour eacuteviter ces soucis la base 64 ne comporte que
64 caractegraveres imprimables (voir tableau ci-dessus)
La restriction agrave 64 caractegraveres a cependant un inconveacutenient crsquoest que nous ne pouvons coder que 6
bits (26=64) au lieu de 8 La base 64 est donc moins efficace drsquoune faccedilon geacuteneacuterale
Nous cherchons agrave coder le code ASCII laquo AA raquo en base 64 Retrouver la deacutemarche en
montrant que le reacutesultat en base 64 est laquo QUE= raquo
543 Uplink Du Device LoRa au Network Server Le Network Server de TTN reccediloit des trames IP en provenance de la Gateway Comme nous lrsquoavons
vu preacuteceacutedemment un certain nombre drsquoinformations peuvent ecirctre retrouveacutees avec cette trame
(DevAddr SF Bandwidth etchellip) mais les donneacutees Applicatives sont bien sucircr chiffreacutees (avec
lrsquoAppkSKey) A ce niveau de reacuteception (sans connaitre lrsquoAppSKey) il nrsquoest donc pas possible de
comprendre la totaliteacute du message reccedilu
Imaginons que la trame IP reccedilue 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 45
timestamp 2019-03-05T140042448Z
rssi -82
snr 9
dev_addr 26011AD3
frequency 867300000
Le Network Server affiche donc les informations de la faccedilon suivante
Figure 44 Trame reacutecupeacutereacutee sur le laquo Network Server raquo de TTN
Nous retrouvons bien les valeurs fournies par la Gateway
timestamp ( agrave 1 heure pregraves en fonction du fuseau horaire)
| 44
frequency 8673 Mhz
modulation Lora
Coding Rate 45
data Rate SF 7 125 kHz (DR5)
air time 463 ms
Drsquoautres information proviennent de lrsquoanalyse du Payload Le Payload inscrit ici est le PHY Payload
Il y a donc une partie chiffreacutee (Frame Payload) mais les entecirctes sont en claires (voir paragraphe
441) Ce PHY Payload est laquo QNMaASYABwAP1obuUHQ= raquo Lorsque celui-ci est exprimeacute en
hexadeacutecimal au lieu de la base 64 il vaut laquo 40D31A01260007000FD686EE5074 raquo comme le montre
le Network Server de TTN
Figure 45 PHY Payload preacutesenteacute dans notre Network Server
Sa taille est bien de 14 octets (en hexadeacutecimal) comme preacuteciseacute sur la Figure 44
Nous reprenons le format de la trame LoRaWAN vu agrave la Figure 32 Nous pouvons alors retrouver
tous les champs de toute la trame
PHYPayload = 40D31A01260007000FD686EE5074
PHYPayload = MAC Header[1 octet] | MACPayload[] | MIC[4 octets]
MAC Header = 40 (Unconfirmed data up)
MACPayload = D31A01260007000FD6
Message Integrity Code = 86EE5074
MACPayload = Frame Header | Frame Port | FramePayload )
Frame Header = D31A0126000700
FPort = 0F
FramePayload = D6
Frame Header = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[015]
DevAddr = 26011AD3 (Big Endian)
FCtrl (Frame Control) = 00 (No ACK No ADR)
FCnt (Frame Counter) = 0007 (Big Endian)
FOpts (Frame Option) =
Vous pouvez veacuterifier lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN
(LoRaWAN packet decoder) httpsbitly2szdXtv
| 45
Figure 46 LoRaWAN packet decoder
544 Uplink Du Network Server agrave lrsquoApplication Server
Nous reprenons lrsquoexemple de la trame ci-dessus (Figure 45) Pour information les cleacutes NwkSKey et
AppSKey suivantes ont eacuteteacute utiliseacutee
NwkSKey E3D90AFBC36AD479552EFEA2CDA937B9
AppSKey F0BC25E9E554B9646F208E1A8E3C7B24
Le Network Server a deacutecodeacute lrsquoensemble de la trame Si le MIC est correct (authentification de la
trame par le NwkSKey) alors le Network Server va passer le contenu du message chiffreacute (Frame
Payload) agrave lrsquoApplication Server Dans notre cas le Frame Payload est (drsquoapregraves le deacutecodage effectueacute
au chapitre preacuteceacutedent)
FramePayload = D6
D6 est le contenu chiffreacute lorsqursquoil est deacutechiffreacute avec lrsquoAppSkey on trouve 01 Vous pouvez veacuterifier
lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN httpsbitly2szdXtv
A noter que lrsquoApplication Server recevra les donneacutees chiffreacutees seulement si le Device LoRa a bien
eacuteteacute enregistreacute On peut aussi veacuterifier ci-dessous que lrsquoApplication Serveur de TTN nous retourne bien
un payload (Frame Payload) de 01
Figure 47 Trame reacutecupeacutereacutee sur lrsquoApplication Server de TTN
time 2019-03-05T140042379279991Z
frequency 8673
modulation LORA
data_rate SF7BW125
coding_rate 45
gateways [
gtw_id eui-b827ebfffeae26f6
timestamp 2447508531
time
channel 4
rssi -82
snr 9
latitude 4563647
longitude 58721523
| 46
location_source registry
]
545 Simulation drsquoUplink dans lrsquoApplication Server
Dans beaucoup de situations nous souhaitons valider le fonctionnement de lrsquoApplication Server de
TTN ouet de notre propre Application Il est donc tregraves utile de pouvoir simuler lrsquoenvoi drsquoune trame
LoRa sur lrsquoApplication Server sans que celle-ci soit reacuteellement eacutemise par un Device LoRa Pour cela
un outil existe dans les Settings de chaque Device enregistreacute dans TTN Nous avons juste besoin de
speacutecifier le Frame Payload en clair en hexadeacutecimal et le numeacutero de Port
Figure 48 Simulation drsquoune trame envoyeacutee par un Device LoRa
546 Downlink De lrsquoApplication Server au Device LoRa La communication LoRa est bidirectionnelle Des donneacutees peuvent ecirctre transmis au Device LoRa
depuis lrsquoApplication Server Depuis TTN un outil existe dans les Settings de chaque Device
enregistreacute Lrsquointerface est repreacutesenteacutee ci-dessous
Figure 49 Transmission de donneacutees de lrsquo laquo Application Server raquo jusqursquoau Device LoRa
Replace scheduling Mode Par deacutefaut le Frame Payload transmis remplacera le Frame
Payload en attente (si il existe) Dans ce mode un seul Frame Payload est planifieacute
First scheduling Mode Le Frame Payload est mis en file drsquoattente en premiegravere position
Last scheduling Mode Le Payload est mis en file drsquoattente en derniegravere position
Une demande de confirmation peut ecirctre demandeacutee au Device LoRa pour qursquoil preacutecise srsquoil a bien reccedilu
les donneacutees Lrsquooption laquo confirmed raquo permet donc de speacutecifier le type de trame dans le MAC Header
(voir paragraphe 443) laquo Confirmed Data Down raquo ou laquo Unconfirmed Data Down raquo dans notre cas
| 47
6 La reacutecupeacuteration des donneacutees sur notre propre Application
Nous utiliserons agrave nouveau le Network Server et Application Server de The Things Network Jusqursquoici
nous nous sommes contenteacute de veacuterifier que les donneacutees de lrsquoutilisateur (Frame Payload) soient bien
arriveacutees agrave destination dans lrsquoApplication Server Il faut maintenant les reacutecupeacuterer avec notre propre
Application qui aura pour rocircle
De stocker et traiter les donneacutees
De les mettre agrave disposition de lrsquoutilisateur (Serveur Web par exemple)
Drsquoenvoyer des commandes de lrsquoutilisateur aux Devices LoRa si besoin (Flux Downlink)
Nous allons voir deux meacutethodes pour communiquer entre notre application et TTN
Le protocole HTTP POST
Le protocole MQTT
61 Reacutecupeacuteration des donneacutees en HTTP POST dans lrsquoApplication
611 Preacutesentation du protocole HTTP
Dans le monde de lrsquointernet le protocole HTTP est tregraves utiliseacute pour le dialogue entre un client et un
serveur web Classiquement le client (un navigateur web par exemple) fait une requecircte HTTP GET
et le serveur lui retourne le contenu de la page web demandeacutee
Dans notre cas la probleacutematique est diffeacuterente car le client doit modifier le contenu du serveur
avec les donneacutees envoyeacutees par le Device LORA La requecircte srsquoappelle HTTP POST Son nom indique
que le client va poster (et on pas reacutecupeacuterer) des donneacutees
Lrsquoutilisateur qui souhaite reacuteceptionner des donneacutees sur son serveur doit donc concevoir un serveur
HTTP capable de traiter des requecirctes HTTP POST [ requecircte noteacutee (1) sur la Figure 51 ] fournies par
TTN Dans cette configuration TTN jouera le rocircle de client et notre application le rocircle de serveur
Devices
LORA Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
HTTP POST
MQTT Internet
Figure 50 Structure globale drsquoun reacuteseau LORAWAN
| 48
Figure 51 Communication bidirectionnelle entre TTN et notre Application
A lrsquoinverse lrsquoutilisateur qui souhaite transmettre des donneacutees agrave destination du Device LoRa
(Downlink) doit ecirctre capable de fournir une requecircte HTTP POST [ requecircte noteacutee (2) sur la Figure 51
] vers TTN Dans cette configuration TTN jouera le rocircle de Serveur et notre application le rocircle de
client
612 Fonctionnement drsquoun client et drsquoun serveur HTTP POST Afin de bien comprendre le fonctionnement des requecirctes HTTP POST nous allons proceacuteder par
eacutetape Le premier test que nous effectuerons sera decorreacuteleacute de TTN Le principe est le suivant
Utilisation drsquoun serveur HTTP disponible sur le web geacuterant les requecirctes HTTP POST [
httpsrbasketsin ] ou [ httpsbeeceptorcom ] par exemple
Utilisation drsquoun client HTTP eacutemettant des requecirctes HTTP POST commande curl sous linux
ou logiciel Postman [ wwwgetpostmancom ] sous windows par exemple
Ce test nous permet de valider le fonctionnement drsquoun serveur HTTP POST et drsquoun client HTTP POST
Une fois que nous serons sucircr de leur fonctionnement nous les utiliserons avec TTN
The Things Network
Application
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 49
Figure 52 Validation dun server HTTP POST et drsquoun client HTTP POST
613 Test du serveur HTTP POST Nous utiliserons un serveur web proposeacute par httpsrbasketsin
Aller sur le site httpsrbasketsin et creacuteer un nouveau laquo Basket raquo Zone ougrave vous pourrez
visualiser les requecirctes qui ont eacuteteacute eacutemises vers votre serveur
A partir de maintenant toutes les requecirctes dirigeacutees vers lrsquoadresse creacuteeacute seront traiteacutees et
srsquoafficheront Dans le menu de configuration il est aussi possible de deacutefinir le contenu de la reacuteponse
qui sera fournie
Deacutefinir un format de reacuteponse pour les requecirctes HTTP POST avec un body personnaliseacute
614 Test du client HTTP POST On peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande (la commande cURL
srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN sous Windows
Commande cURL curl ndashX POST ndashd lsquorsquodonneacutees agrave envoyerrsquorsquo DuServeurHTTP
Logiciel Postman New gt Request gt Creacuteer une requecircte HTTP POST gt Send
Veacuterifier que les requecirctes HTTP POST sont bien reacutecupeacutereacutees sur votre serveur creacutee preacuteceacutedemment
615 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST
Maintenant que nous avons un serveur HTTP (POST) fonctionnel nous allons configurer TTN pour
jouer le rocircle du client et pour qursquoil envoie des requecirctes HTTP POST vers notre Serveur degraves qursquoune
donneacutee drsquoun Device LoRa est disponible Nous geacuterons donc ici le flux Uplink
Requecircte
HTTP POST
Reacuteponse
(contenu parameacutetrable)
Client HTTP (POST)
Server HTTP (POST) [ httpsrbasketsin ]
| 50
Figure 53 Reacutecupeacuteration des donneacutees sur notre Application
Dans TTN nous inteacutegrons un bloc appeleacute laquo HTTP Integration raquo permettant de jouer le rocircle de client
crsquoest-agrave-dire drsquoenvoyer des requecirctes HTTP POST agrave destination de notre nouveau Serveur HTTP
Lrsquointeacutegration se faire agrave partir de TTN gt Console gt Application gt Nom_de_votre_application gt
Integration
Figure 54 Ajout dun client HTTP POST dans TTN
Pour valider le fonctionnement de notre architecture nous pouvons soit
Envoyer une trame depuis un Device LoRa vers TTN
Simuler lrsquoenvoi drsquoune trame drsquoun Device LoRa vers TTN (gracircce agrave lrsquooutil proposeacute par TTN vu
paragraphe 545)
Dans les deux cas voici un exemple de requecircte POST reccedilue sur notre serveur HTTP
app_id test_app_lorawan_sylvainmontagny
dev_id stm32lorawan_1
hardware_serial 0056AF49877
port 1
counter 0
payload_raw qg==
metadata
Requecircte
HTTP POST
Server HTTP (POST) [ httpsrbasketsin ]
The Things Network (Client)
La requecircte contient le Frame Payload deacutechiffreacutee
agrave transmettre agrave lrsquoApplication
| 51
time 2019-01-24T15243703499298Z
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Comme nous pouvons le voir le contenu fourni agrave notre serveur est formateacute en JSON (voir
paragraphe 0) Voici quelques compleacutements drsquoinformation
payload_raw Frame Payload deacutechiffreacute crsquoest donc les donneacutees en clairs dans la base 64
downlink_url URL du serveur HTTP POST qui serviront agrave transmettre des donneacutees au Device
LoRa (flux Downlink)
611 Envoyer des donneacutees depuis notre Application avec HTTP POST
Lorsque nous avons ajouteacute le bloc laquo HTTP Integration raquo au paragraphe preacuteceacutedent nous avons aussi
implicitement activeacute la fonctionnaliteacute que TTN soit precirct agrave recevoir et agrave traiter les requecirctes HTTP
POST La seule information qursquoil nous manque est lrsquoadresse du server HTTP vers lequel il faut eacutemettre
les requecirctes Si on observe la trame reccedilue preacuteceacutedemment en provenance de TTN on srsquoaperccediloit que
dans la trame JSON reccedilu une URL (downlink_url) est speacutecifieacutee
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Crsquoest cette URL que nous devrons utiliser Nous allons nous placer dans la configuration suivante
Figure 55 Envoi de donneacutees agrave partir de notre Application
Comme preacuteceacutedemment on peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande
(la commande cURL srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN
Commande cURL curl ndashX POST ndashdata lsquo dev_id Identidiant_De_Votre_Device
payload_raw AQE= rsquo DuServeurHTTP
Logiciel Postman New gt Request gt HTTP POST puis Body gt Raw gt JSON
Requecircte HTTP POST vers serveur TTN laquo downlink_url raquo httpsintegrationsthethingsnetworUaeb8ypKieQ
Contenu de la requecircte
dev_id Identidiant_De_Votre_Device
payload_raw aGVsbG8=
The Things Network (Serveur)
POSTMAN (Client HTTP POST)
| 52
dev_id YourDeviceID
payload_raw aGVsbG8=
Vous devez envoyer le texte (payload_raw) en base 64 Dans lrsquoexemple ci-dessus laquo aGVsbG8= raquo
correspond agrave la chaine de caractegravere laquo hello raquo Vous pouvez utiliser les nombreux encodeurdecodeur
en ligne pour vous aider Le texte doit srsquoafficher sur votre moniteur seacuterie Arduino dans le cadre de
notre deacutemonstrateur sur Arduino
62 Reacutecupeacuteration des donneacutees avec MQTT dans lrsquoApplication
621 Preacutesentation du protocole MQTT
MQTT est un protocole leacuteger qui permet de srsquoabonner agrave des flux de donneacutees Plutocirct que
lrsquoarchitecture Client Serveur classique qui fonctionne avec des Requecirctes Reacuteponses MQTT est
baseacute sur un modegravele Publisher Subscriber La diffeacuterence est importante car cela eacutevite davoir agrave
demander (Requecircte) des donneacutees dont on na aucune ideacutee du moment ougrave elles vont arriver Une
donneacutee sera donc directement transmise au Subscriber degraves lors que celle-ci a eacuteteacute reccedilue dans le
Broker (serveur central)
Figure 56 Modegravele Publisher Subscriber du protocole MQTT
Pour recevoir les donneacutees appartenant agrave un Topic un Subscriber doit souscrire (comme son nom
lindique) au preacutealable sur ce Topic
MQTT est un protocole qui repose sur TCP Lencapsulation des trames sur le reacuteseau est donc la
suivante
Broker
Client
Publisher 1
Client
Publisher 2
Client
Subscriber
Topic
Tempeacuterature
Topic
Humiditeacute
| 53
Figure 57 Protocoles utiliseacutes pour la communication avec MQTT
On peut le veacuterifier par une capture de trame sur Wireshark
Figure 58 Capture dune trame MQTT avec Wireshark
On peut noter que le port TCP utiliseacute pour le protocole MQTT (non chiffreacute) est le 1883
Les Publishers et les Subscribers nrsquoont pas besoin de se connaitre
Les Publishers et les Subscribers ne sont pas obligeacute de srsquoexeacutecuter en mecircme temps
622 Connexion au Broker MQTT Nous nous inteacuteresserons essentiellement aux options de connexion qui permettront de geacuterer la
Qualiteacute de Service (QoS) Pour se connecter un client MQTT envoie deux informations importantes
au Broker
keepAlive Cest la peacuteriode la plus longue pendant laquelle le client Publisher ou Subscriber pourra
rester silencieux Au-delagrave il sera consideacutereacute comme deacuteconnecteacute
cleanSession Lorsque le Client et le Broker sont momentaneacutement deacuteconnecteacutes (au-delagrave du
keepAlive annonceacute) on peut donc se poser la question de savoir ce quil se passera lorsque le client
sera agrave nouveau connecteacute
Si la connexion eacutetait non persistante (cleanSession = True) alors les messages non transmis
sont perdus Quel que soit le niveau de QoS (Quality of Service)
Si la connexion eacutetait persistante (cleanSession = False) alors les messages non transmis
seront eacuteventuellement reacuteeacutemis en fonction du niveau de QoS Voir le chapitre 624
623 Qualiteacute de Service au cours dune mecircme connexion
A partir du moment ougrave le Client se connecte au Broker il est possible de choisir un niveau de fiabiliteacute
des transactions Le Publisher fiabilise leacutemission de ces messages vers le Broker et le Subscriber
fiabilise la reacuteception des messages en provenance du Broker Une parle ici du cas dune mecircme
connexion crsquoest-agrave-dire entre le moment ou le Client se connecte et le moment ougrave
Soit il se deacuteconnecte explicitement (Close connexion)
Soit il na rien eacutemis ni fait signe de vie pendant le temps keepAlive
TCP
MQTT
Reacuteseau
Transport
Couche Application
IP
| 54
Lors dune mecircme connexion la Qualiteacute de Service (QoS) qui est mise en œuvre deacutepend uniquement
de la valeur du QoS selon les valeurs suivantes
QoS 0 At most once (au plus une fois) Le premier niveau de qualiteacute est sans acquittement Le
Publisher envoie un message une seule fois au Broker et le Broker ne transmet ce message quune
seule fois aux Subscribers Ce meacutecanise ne garantit pas la bonne reacuteception des messages MQTT
QoS 1 At least once (au moins une fois) Le deuxiegraveme niveau de qualiteacute est avec acquittement
Le Publisher envoie un message au Broker et attends sa confirmation De la mecircme faccedilon le Broker
envoie un message agrave ces Subscriber et attends leurs confirmations Ce meacutecanisme garantit la
reacuteception des message MQTT
Cependant si les acquittements nrsquoarrivent pas en temps voulu ou srsquoils se perdent la reacuteeacutemission du
message dorigine peut engendrer une duplication du message Il peut donc ecirctre reccedilu plusieurs fois
QoS 2 Exactly once (exactement une fois) Le troisiegraveme niveau de qualiteacute est garanti une seule
fois Le Publisher envoie un message au Broker et attends sa confirmation Le Publisher donne alors
lrsquoordre de diffuser le message et attends une confirmation Ce meacutecanisme garantit que quel que
soit le nombre de tentatives de reacuteemission le message ne sera deacutelivreacute quune seule fois
La Figure 59 montre les trames eacutemises pour chaque niveau de QoS
Figure 59 Qualiteacute de Service en MQTT
La Figure 60 repreacutesentes les 3 captures de trames sur Wireshark repreacutesentant les 3 QoS (1 2 et 3)
que nous venons dexpliquer
Broker
QoS 0
Au plus une fois
Message supprimeacute apregraves envoi
PUBLISH
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Duplications possibles
PUBLISH
PUBLICH Ack
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Pas de duplication
PUBLISH
PUBLISH Receive
PUBLISH Release
PUBLISH Complete
| 55
Figure 60 Capture de trame avec QoS = 0 puis QoS = 1 puis QoS = 2
624 Qualiteacute de Service apregraves une reconnexion
La question que nous nous posons et de savoir ce que deviennent les messages publieacutes sur le Broker
lorsquun ou plusieurs Subscribers sont momentaneacutement injoignables Il est possible de conserver
les messages qui ont eacuteteacute publieacutes sur le Broker afin de les retransmettre lors de la prochaine
connexion Cette possibiliteacute de sauvegarde doit ecirctre activeacutee agrave louverture de connexion gracircce au flag
cleanSession = 0 La connexion sera alors persistante crsquoest-agrave-dire que le Broker enregistre tous les
messages quil na pas reacuteussi agrave diffuser au Subscriber
Le Tableau 9 reacutesume leffet du flag cleanSession et du QoS
Clean Session Flag Subscriber QoS Publisher QoS Comportement True ( = 1) 0 1 2 0 1 2 Messages perdus
False ( = 0 ) 0 0 1 2 Messages perdus
False (= 0 ) 0 1 2 0 Messages perdus
False (= 0 ) 1 2 1 2 Tous les messages sont retransmis
Tableau 9 Qualiteacute de Service en fonction de la valeur du QoS et du flag cleanSession
625 Les Topics du protocole MQTT Les chaicircnes deacutecrivant un sujet forment une arborescence en utilisant la barre oblique comme
caractegravere de seacuteparation La Figure 61 et le Tableau 10 donne un exemple dorganisation de Topic
Figure 61 Exemple de hieacuterarchie de Topic MQTT
Niveau 3
Niveau 2
Niveau 1 Maison
Chambre
Temperature Humidite Bruit
Salon
Temperature
| 56
Nom du Topic Deacutetail du Topic MaisonChambreTemperature La tempeacuterature de la chambre de la maison
MaisonChambreBruit Le bruit de la chambre de la maison
MaisonSalonTemperature La tempeacuterature du Salon de la maison
Tableau 10 Exemple de Topic
Un client peut sabonner (ou se deacutesabonner) agrave plusieurs branches de larborescence agrave laide de
jokers englobant plusieurs Topics Deux caractegraveres jokers existent
Le signe plus + remplace nimporte quelle chaine de caractegravere sur le niveau ougrave il est placeacute
Le diegravese remplace nimporte quelle chaine de caractegravere sur tous les niveaux suivants Il
est obligatoirement placeacute agrave la fin
Nom du Topic Deacutetail du Topic Maison+Temperature Les tempeacuteratures de toutes les piegraveces de la maison
MaisonChambre La tempeacuterature lhumiditeacute et le bruit de la chambre de la maison
Tableau 11 Exemple de Topic
626 Mise en place drsquoun Broker MQTT Afin de bien comprendre le fonctionnement du protocole de MQTT on reacutealise des tests
indeacutependamment de TTN Nous allons mettre en place
Un Broker Mosquitto httpstestmosquittoorg
Un client Publisher MQTT Box sur Windows
Un client Subscriber MQTT Box sur Windows
Figure 62 Test du protocole MQTT
MQTT Client (Subscriber)
MQTT Client (Publisher)
Publish
Subscribe
BROKER (Mosquitto)
| 57
Le Broker MQTT est commun agrave tout le monde Nous pouvons soit le reacutealiser nous-mecircme soit utiliser
un Broker MQTT public de test Nous utiliserons le Broker de test de Mosquitto disponible sur
httpstestmosquittoorg Drsquoautres sont eacuteventuellement disponibles en cas de problegraveme par
exemple httpwwwmqtt-dashboardcom
Si nous deacutecidions de le reacutealiser nous-mecircme agrave lrsquoaide drsquoune Raspberry Pi (par exemple) Lrsquoinstallation
se ferait en deux lignes de commande
apt-get install mosquito Installation
sudo systemctl start mosquittoservice Lancement du service
Il est neacutecessaire drsquoinstaller mosquitto-clients si on souhaite que le Raspberry PI joue aussi le rocircle de
client ce qui nrsquoest pas notre cas
627 Mise en place drsquoun Publisher et drsquoun Subscriber MQTT Lancer le logiciel MQTTBox
MQTTBox gt Create MQTT Client
Dans ce client les seuls champs indispensables sont
Protocol MQTT TCP
Host testmosquittoorg
Figure 63 Configuration dun Client MQTT dans MQTT Box
Tester lrsquoenvoi et la reacuteception sur les Topics de votre choix
628 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT La reacutecupeacuteration des donneacutees fait reacutefeacuterence au flux Uplink Dans ce cas
TTN joue le rocircle de client Publisher
TTN joue aussi le rocircle de Broker
Notre application joue le rocircle de Subscriber
Nous pouvons donc repreacutesenter lrsquoapplication globale par le scheacutema suivant
| 58
Figure 64 Publisher et Subscriber dans en MQTT avec TTN
La publication est repreacutesenteacutee par la trame MQTT (1)
La souscription est repreacutesenteacutee par la trame MQTT (2)
Le client Publisher eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box mais cette fois avec la configuration suivante
Protocol mqtt tcp
Host Crsquoest lrsquoIP du Broker vers lequel il faut se connecter Dans notre cas il srsquoagit de celui
de TTN dont lrsquoadresse est euthethingsnetwork
Username La connexion vers le broker MQTT est soumis agrave une authentification Username
Password Dans notre cas le Username correspond au nom de notre application crsquoest-agrave-
dire seminaire_lorawan Si vous avez choisi une autre applicationil faut bien mettre la
votre
Password Le Password est nommeacute laquo Access Key raquo par TTN Elle vous sera donneacutee par
lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application vous
trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt Overview
Figure 65 Access Keys de lapplication dans TTN
The Things Network (Application Server)
BROKER
Application
The Things Network (Network Server)
Publish (1 )
[ Flux Uplink ]
Subscribe (2 )
[ Flux Uplink ]
| 59
Figure 66 Configuration du Client dans MQTT Box
Le client MQTT eacutetant configureacute il est maintenant capable de se connecter au Broker Il reste donc agrave
deacutefinir le fait que le client sera Subscriber Les informations que recevra le Subscriber deacutependent du
Topic auquel nous souscrivons Voici les Topic disponibles sur le Broker de TTN
ltAppIDgt correspond au nom de votre Application
ltDevIDgt correspond au nom de votre Device LoRa
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink ltAppIDgtdevicesltDevIDgtup
[Donneacutees] Flux Downlink ltAppIDgtdevicesltDevIDgtdown
[Activation Events] Activation dun Device ltAppIDgtdevicesltDevIDgteventsactivations
[Management Events] Creacuteation dun Device ltAppIDgtdevicesltDevIDgteventscreate
[Management Events] Update dun Device ltAppIDgtdevicesltDevIDgteventsupdate
[Management Events] Suppression dun Device ltAppIDgtdevicesltDevIDgteventsdelete
[Downlink Events ] Message programmeacute ltAppIDgtdevicesltDevIDgteventsdownscheduled
[Downlink Events ] Message envoyeacute ltAppIDgtdevicesltDevIDgteventsdownsent
[Erreurs] Uplink erreurs ltAppIDgtdevicesltDevIDgteventsuperrors
[Erreurs] Downlink erreurs ltAppIDgtdevicesltDevIDgteventsdownerrors
[Erreurs] Activations erreurs ltAppIDgtdevicesltDevIDgteventsactivationserrors
Tableau 12 Topics enregistreacutes dans TTN
Dans un premier temps nous souscrivons au Topic +devices+up Cela signifie que nous
souscrivons agrave tous les Devices LoRa de toutes nos applications pour le flux Uplink
Figure 67 Configuration du Subscriber
Les eacuteleacutements eacutemis par le Broker seront alors afficheacutes dans MQTTBox La
| 60
Figure 68 Trame LoRaWAN reccedilu sur le Subscriber MQTT
Ces donneacutees sont eacutecrites en JSON nous pouvons les remettre en forme
applicationID3
applicationNamemyApplication
deviceNamearduino0
devEUI0056xxxxxxxxx877
txInfo
frequency868500000
dr5
adrfalse
fCnt792
fPort15
dataSGVsbG8=
Le Frame Payload deacutechiffreacute est fourni dans le champ data en base 64 La valeur fournie par
dataSGVsbG8= correspond bien agrave la chaine de caractegravere hello que nous avons eacutemise avec le
Device LoRa
629 Envoyer des donneacutees depuis notre Application avec MQTT
Lrsquoenvoi des donneacutees fait reacutefeacuterence au flux Downlink Dans ce cas
Notre application joue le rocircle de Publisher
TTN joue le rocircle de Broker
TTN joue aussi le rocircle de client Subscriber
| 61
La publication est repreacutesenteacutee par la trame MQTT (3)
La souscription est repreacutesenteacutee par la trame MQTT (4)
Le client Subscriber eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box Le rocircle de client dans MQTT Box a eacuteteacute faite au
paragraphe 628 Il nous reste simplement agrave ajouter le rocircle de Publisher La configuration est la
suivante
Topic du Subscriber seminaire_lorawandevicesarduino0down ougrave seminaire_lorawan
est agrave remplacer par le nom de votre application et arduino0 par le nom du Device LoRa vers
lequel vous souhaitez envoyeacute une donneacutee (Voir chapitre 628 pour comprendre les Topics)
Le Payload doit ecirctre au format JSON Lrsquoexemple suivant envoie laquohello raquo
payload_raw aGVsbG8=
The Things Network (Application Server)
BROKER
Application
Publish (3)
[ Flux Downlink ]
The Things Network (Network Server)
Subscribe (4)
[ Flux Downlink ]
| 62
Figure 69 Configuration du Publisher
Vous devriez voir les donneacutees arriver sur votre Device LoRA
| 63
7 Creacuteation de notre propre Network et Application Server
711 Objectifs Lors de la mise en œuvre du reacuteseau LoRaWAN au chapitre 52 nous avons utiliseacute TTN (The Things
Network) pour jouer le rocircle de Network Server et drsquoApplication Server Pour de multiples raisons
Seacutecuriteacute autonomie coucircthellipil peut ecirctre inteacuteressant de monter soi-mecircme un Network Server et un
Application Server Cela est possible seulement si vous posseacutedez vos propres Gateway puisque
celles-ci devront forwarder leur paquet agrave destination preacutecise Il faudra donc les reconfigurer pour
qursquoelles pointent vers votre nouvelle architecture
712 Preacutesentation de LoRaServer LoRaServer [ wwwloraserverio ] est un projet Open-Source reacutepondant exactement au besoin que
nous avons Nous lrsquoutiliserons sur une cible Raspberry PI En reacutealiteacute il peut souvent ecirctre mise en
place dans le mecircme systegraveme que la Gateway surtout si celle-ci est elle-mecircme agrave base de RPI Les
Gateway EBDS que nous posseacutedons possegravedent drsquoailleurs un Network Server et un Application Server
que nous aurions pu utiliser Neacuteanmoins pour des raisons peacutedagogiques il est inteacuteressant de
seacuteparer les systegravemes pour bien diffeacuterencier les probleacutematiques
Attention il y a une ambiguiumlteacute dans la deacutenomination des entiteacutes logiciels de LoRaServer
LoRaServer (sans espace entre le mot LoRa et Server) est le nom du projet global En
revanche LoRa Server (avec un espace) est le nom du service qui joue le rocircle du Network
Server
Lrsquoarchitecture et le fonctionnement de LoRaServer est preacutesenteacutee dans sa documentation par le
scheacutema suivant
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Raspberry PI
Figure 70 Architecture globale de notre reacuteseau loRaWAN
| 64
Figure 71 Architecture deacutetailleacutee de LoRaServer
On srsquoattends agrave voir uniquement un Network Server (LoRa Server) et un Application Server (LoRa App
Server) mais ce scheacutema est plus complexe Il demande un certain nombre drsquoexplications pour bien
comprendre ce que nous allons installer et la faccedilon dont nous lrsquoutiliserons par la suite
713 Le laquo Packet Forwarder raquo (Gateway) Comme nous lrsquoavons vu au chapitre 412 les Gateways LoRa sont des passerelles entre la
modulation LoRa et un reacuteseau IP Pour reacutealiser cette passerelle un service nommeacute laquo UDP Packet
Forwarder raquo a eacuteteacute deacuteveloppeacute par Semtech httpsgithubcomLora-netpacket_forwarder Dans
ce dossier github un fichier nommeacute PROTOCOLTXT explique parfaitement ce protocole applicatif
qui travaille au-dessus de UDP
Figure 72 Protocole Uplink (PUSH_DATA du Packet Forwarder)
| 65
On remarque que les paquets sont envoyeacutes en UDP au Network Server dans une trame appeleacutee
PUSH_DATA Cette trame est acquitteacutee par le Network Server par une trame appeleacutee PUSH_ACK
Sur notre Network Server nous pouvons reacutealiser une capture de trame pour veacuterifier si le protocole
est bien celui preacutesenteacute dans le document
Figure 73 Trame captureacutee par Wireshark lors dun Uplink
Drsquoapregraves la capture preacuteceacutedente on remarque que le Packet Forwarder fonctionne bien avec UDP sur
le port 1700
Le contenu des donneacutees (champ Data) est deacutetailleacute dans le tableau suivant
Champ | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | random token
[3] | 3 | PUSH_DATA identifier = 0x00
[4] | 4-11 | Gateway unique identifier (MAC address)
[5] | 12-end | JSON object starting with ending with
Lrsquoobjet JSON de la transmission reacuteeacutecrit plus proprement est celui-ci
Figure 74 Analyse du champ Donneacutees du protocole laquo Packet Forwarder raquo
0000 02 f9 30 00 b8 27 eb ff fe ae 26 f5 7b 22 72 78 0amprx 0010 70 6b 22 3a 5b 7b 22 74 6d 73 74 22 3a 33 37 35 pk[tmst375 0020 35 30 30 35 38 31 39 2c 22 63 68 61 6e 22 3a 32 5005819chan2 0030 2c 22 72 66 63 68 22 3a 31 2c 22 66 72 65 71 22 rfch1freq 0040 3a 38 36 38 2e 35 30 30 30 30 30 2c 22 73 74 61 868500000sta 0050 74 22 3a 31 2c 22 6d 6f 64 75 22 3a 22 4c 4f 52 t1moduLOR 0060 41 22 2c 22 64 61 74 72 22 3a 22 53 46 37 42 57 AdatrSF7BW 0070 31 32 35 22 2c 22 63 6f 64 72 22 3a 22 34 2f 35 125codr45 0080 22 2c 22 6c 73 6e 72 22 3a 36 2e 35 2c 22 72 73 lsnr65rs 0090 73 69 22 3a 2d 31 2c 22 73 69 7a 65 22 3a 31 38 si-1size18 00a0 2c 22 64 61 74 61 22 3a 22 51 4e 4d 61 41 53 59 dataQNMaASY 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 ]
Ch
amp
[1
]
Ch
amp
[2
]
Ch
amp
[3
]
Ch
amp
[4
]
| 66
rxpk[ tmst3755005819
chan2
rfch1
freq868500000
stat1
moduLORA
datrSF7BW125
codr45
lsnr65
rssi-1
size18
dataQNMaASYAAQAPpyPZ955+SmY
]
Le champ data correspond au PHY Payload
De la mecircme faccedilon on retrouve la Trame drsquoacquittement
Figure 75 Trame captureacutee par Wireshark lors de lrsquoacquittement drsquoun Uplink
Champs | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | same token as the PUSH_DATA to acknowledge
[3] | 3 | PUSH_ACK identifier = 0x01
Nous retrouvons bien tous ces champs dans la trame Wireshark
714 LoRa Gateway Bridge Nous avons deacutecrit au chapitre preacuteceacutedent (713) le fonctionnement du Packet Forwarder Le
Network Server(Lora Server) que nous allons mettre en place aurait tregraves bien pu srsquointerfacer
directement agrave ce protocole Mais cela aurait plusieurs impacts dont un qui est important dans la
conception de logiciel Si le Packet Forwarder change ou si un autre type de Forwarder est utiliseacute
alors lrsquoutilisation du LoRa Server devient impossible Il a donc eacuteteacute choisi de creacuteer une eacutetape
intermeacutediaire Le Network Server que nous mettrons en plus utilisera le protocole MQTT plutocirct que
le protocole UDP packet Forwarder
En drsquoautres termes le LoRa Gateway Bridge est un service qui fera abstraction du Packet Forwarder
pour srsquointerfacer plus simplement avec le Network Server
715 LoRa Server (Network Server) Il srsquoagit de notre Network Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
413 Cependant il srsquointerfacera au protocole MQTT en recevant les informations agrave partir du
Broker au lieu de recevoir directement les trames en provenance de la Gateway
| 67
716 LoRa App Server (Application Server) Il srsquogit de notre Application Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
414
717 LoRa Geo Server Il srsquoagit drsquoun service qui permet drsquoutiliser certaines proprieacuteteacutes du protocole LoRa pour proposer un
service de geacuteolocalisation des Devices LoRa Nous ne lrsquoutiliserons pas dans notre cas
718 Application Il srsquoagit de notre Application qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre 415
Elle ne fait pas partie du projet LoRaServer crsquoest donc bien toujours agrave nous de proposer notre propre
Application
Figure 76 Les interfaces possibles entre LoRaServer et lrsquoApplication utilisateur
Comme nous pouvons le voir sur la figure preacuteceacutedente deux possibiliteacutes sont offertes pour interfacer
notre application JSON REST (incluant HTTP POST) et via un Broker MQTT Ces deux meacutethodes ont
deacutejagrave eacuteteacute traiteacutee au chapitre 61 (HTTP POST ) et au chapitre 62 (MQTT) Nous verrons aussi drsquoautres
possibiliteacutes pour personnaliser notre application au chapitre 7
72 Installation de LoRaServer
721 Mise en place de lrsquoenvironnement
Nous allons installer une carte SD avec la derniegravere version de Raspbian Nous ne deacutetaillerons pas la
deacutemarche pour cela car elles sont largement documenteacutees et mises agrave jour sur le site
wwwraspberrypiorg
Installer un carte SD avec la derniegravere version de Raspbian
Plutocirct que de fonctionner avec un clavier et une souris nous preacuteconisons de travailler agrave distance
avec la RPI via une connexion SSH Depuis quelques anneacutees Raspbian a supprimeacute le deacutemarrage du
service SSH au boot Heureusement il est possible de le reacuteactiver par la meacutethode suivante
Avec Windows ou Linux ouvrir la partition BOOT de votre carte SD et placer un fichier agrave la
racine nommeacute sshtxt (ou ssh)
Mettre la carte SD dans votre RPI et la deacutemarrer
| 68
Pour acceacuteder agrave la RPI en SSH depuis Windows nous utiliserons de preacutefeacuterence le logiciel
client MobaXterm mais tout autre client SSH est valable
Installer MobaXterm sur votre PC et connectez-vous agrave votre Raspberry PI
Lrsquoutilisation drsquoun espion de reacuteseau type Wireshark peut ecirctre inteacuteressant pour eacutetudier les trames qui
sont reccedilues et qui sont eacutemises Cela nous permettra de valider le fonctionnement des diffeacuterents
protocoles reacuteseau qui permettent de communiquer agrave la Gateway drsquoune part et agrave lrsquoApplication
drsquoautre part Nous utiliserons tshark
apt-get install tshark installation
tshark ndashn -i eth0 Exemple drsquoune analyse sur lrsquointerface wlan0
722 Installation sur la Raspberry PI La meacutethode drsquoinstallation de LoRaServer est documenteacutee sur le site web agrave lrsquoadresse suivante
[ httpswwwloraserverioguidesdebian-ubuntu ] Nous installerons le LoRa Gateway Bridge
le LoRa Server et le LoRa App Server
Apregraves lrsquoinstallation la configuration se fait par une interface graphique accessible par le reacuteseau sur
le port 8080
Si vous travaillez sur la RPI connectez-vous sur httplocalhost8080
Si vous travaillez agrave distance (SSH) connectez-vous sur httpIP_RPI8080
Les Usernames et Password par deacutefaut sont
Username admin
Password admin
Lrsquoeacutecran drsquoaccueil sera donc le suivant
Figure 77 Architecture globale apregraves installation de LoRaServer
Devices
Gateways LoRa
UDP Packet Forwarder
Application Server
LoRa App Server
Internet
Network Server
LoRa Server
LoRa Gateway Bridge
| 69
Figure 78 Ecran daccueil de LoRaServer apregraves authentification
71 Configuration de LoRa Server pour lUplink
711 Enregistrement drsquoune nouvelle Organisation
Pour enregistrer une nouvelle Organizations Organizations gt Create Puis entrer les configurations
suivantes
Figure 79 Enregistrement dun nouvelle Organisation
712 Enregistrement drsquoune instance du Network Server Pour enregistrer une nouvelle instance du Network Server Network Server gt Create Puis entrer
les configurations suivantes
| 70
Figure 80 Enregistrement dun nouveau Network Server
Dans lrsquoonglet Gateway Discovery il est possible drsquoactiver une option de deacutecouverte de Gateway aux
alentours Lorsqursquoelle est configureacutee le Network Server va envoyer une trame Downlink de
configuration de la Gateway lui ordonnant de reacutealiser des PING en LoRa La configuration du
Gateway Discovery preacutevoit de speacutecifier
Le nombre de fois par jour que les PING LoRa sont envoyeacutes
Le canal drsquoeacutemission
Le Data Rate (Voir paragraphe 445)
Un PING LoRa reccedilu sur une Gateway sera retransmis sur le Network Server (Lora Server) et une carte
sera afficheacutee
Lrsquoonglet TLS Certificates ne sera pas utiliseacute dans le cadre de notre deacutemonstration
713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) Il faut tout drsquoabord faire un enregistrement drsquoun laquo service-profile raquo Un laquo service profile permet de
faire la connexion entre le Network Server et les Applications que nous enregistrerons dans notre
Organisation Service-profiles gt Create
Service-profile name myServiceProfile
Network-server myNetworkServer
On laissera par deacutefaut toutes les autres options
Pour enregistrer une nouvelle Application Applications gt Create Puis entrer les configurations
suivantes
| 71
Figure 81 Enregistrement dune nouvelle Application
714 Enregistrement des Devices LoRa Il faut tout drsquoabord faire lrsquoenregistrement drsquoun Device-profile pour les Devices LoRa que vous
souhaitez connecter Dans notre cas nous ferons un premier test en speacutecifiant que nous utilisons
seulement le mode drsquoauthentification ABP (voir chapitre 431) Devices profile gt Create
Figure 82 Enregistrement dun laquo Device profile raquo
Nous pouvons alors creacuteer dans notre Application des nouveaux Devices Application gt
myApplication gt Create
| 72
Figure 83 Enregistrement dun nouveau Device LoRa
Dans la fenecirctre Activation on va alors configurer les 3 eacuteleacutements indispensables agrave une
authentification en APB Le DevAddr le NwkSKey et lrsquoAppSKey
Figure 84 Configuration de lenregistrement du Device LoRa (en ABP)
La configuration minimale de LoRaServer est maintenant termineacutee Nous pouvons donc brancher
un Device LoRa qui possegravede les les attribus (DevAddr NwkSKey et AppSKey) que nous avons
enregistreacute dans LoRaServer et le faire eacutemettre
715 Visualisation des trames reccedilues Les trames eacutemises par le Device LoRa vont donc parcourir le cheminement suivant
| 73
Figure 85 Reacutesumeacute du cheminement des trames LoRaWan en Uplink avec LoRaServer
En allant dans le Live Device Data (Application gt Nom_du_Device gt Live Device Data) on peut voir la
liste des trames reccedilues ainsi que les donneacutees applicatives deacutechiffreacutees
Figure 86 Reacuteception des trames des Devices LoRa
Figure 87 Analyse des trames des Devices LoRa
Dans lrsquoonglet LIVE LORAWAN FRAME nous pouvons voir les trames LORAWAN et si besoin eacutetudier
le contenu de ce qursquoelles contiennent En revanche les donneacutees applicatives sont ici chiffreacutees
UDP
Packet Forwarder
LoRa Bridge
Gateway LoRa Server LoRa App Server
Gateway
Server
Internet
| 74
Figure 88 Reacuteception des Trames LoRaWAN
72 Configuration de LoRaServer pour linteacutegration dApplication Nous avons vu dans le chapitre 718 que linterface entre LoRaServer et notre Application pouvait
ecirctre reacutealiseacutee soit par MQTT soit par les meacutethodes REST (HTTP POST) Nous avons deacutejagrave impleacutementeacute
et expliqueacute ces protocoles dans le cadre de son utilisation avec TTN Nous allons donc juste
configurer LoRaServer pour tester ces deux meacutethodes
721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST Nous utiliserons exactement la mecircme meacutethode que celle que nous avons utiliseacute avec TTN au
chapitre 615 Les diffeacuterentes Clients et Serveurs disponibles pour ces tests sont expliqueacutes au
paragraphe 612
Dans LoRaServer ajouter une inteacutegration HTTP LoRaServer gt Applications gt myApplication gt
Integrations gt Create gt HTTP Integration et la configurer comme le montre la Figure 89 Vous
remplacerez eacutevidement le lien par votre propre Endpoints
Figure 89 Configuration de linteacutegration HTTP POST dans LoRaServer
En envoyant des trames LoRa depuis votre Device vous devriez voir les contenus JSON sur votre
Endpoint
722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT Nous allons nous connecter au Broker MQTT de LoRaServer Pour cela nous utiliserons la mecircme
meacutethode que celle que nous avons utiliseacute avec TTN au chapitre 628 Nous utiliserons MQTTBox
comme nous lavons deacutejagrave fait au paragraphe 627
Le Broker de LoRaServer a enregistreacute les Topics suivant
[applicationID] correspond au nom de votre Application
[devEUI] correspond au nom de votre Device LoRa
| 75
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink application[applicationID]device[devEUI]rx
[Donneacutees] Flux Downlink application[applicationID]device[devEUI]tx
[Status] Statut dun Device application[applicationID]device[devEUI]status
[Ack] Acquittement des messages application[applicationID]device[devEUI]ack
[Erreurs] Erreurs application[applicationID]device[devEUI]error
Tableau 13 Topics enregistreacutes dans LoRaServer
| 76
8 Creacuteation de notre propre Application
81 Utilisation de Node-RED
811 Preacutesentation Node-RED est un outil de programmation graphique qui permet de faire communiquer les
peacuteripheacuteriques mateacuteriels drsquoun systegraveme sans eacutecrire de code De nombreux protocoles sont aussi pris
en charge au travers de bloc ( Node) qursquoil suffit de connecter entre eux pour reacutealiser simplement
une application Il peut srsquoexeacutecuter localement sur un PC ou sur des cibles embarqueacutees telle qursquoune
Raspberry PI (RPI)
Dans les deacutemonstrations que nous mettrons en œuvre nous utiliserons une RPI Par soucis de
simpliciteacute nous utiliserons les derniegraveres versions de Raspbian (systegraveme drsquoexploitation de la RPI) qui
integravegre drsquoorigine Node-RED Il nrsquoy a donc tregraves peu de chose agrave mettre en place pour arriver agrave mettre
en place une Application Nous pouvons travailler soit directement sur la RPI agrave lrsquoaide drsquoune souris-
clavier mais il est recommandeacute de travailler agrave distance avec une connexion SSH
812 Mise en place de lrsquoenvironnement La mise en place de la RPI avec le systegraveme drsquoexploitation Raspbian a eacuteteacute preacutesenteacute au chapitre 721
Vous pouvez reprendre la mecircme installation ou repartir sur une nouvelle
Il est possible de faire en sorte que Node-RED se lance directement au deacutemarrage gracircce agrave la
commande sudo systemctl enable noderedservice
Sil nest pas actif lancer Node-RED sur votre RPI node-red-start
Nous nous connectons au Node-RED de la RPI via un navigateur web sur le port 1880 en tapant dans
la barre dURL httpIP_Raspeberry_PI1880 Ce nous permet darriver agrave la fenecirctre suivante
Figure 90 Page daccueil de Node-RED
Il est possible de sinterfacer avec TTN avec les Nodes deacutejagrave disponibles gracircce au protocole HTTP
POST ou MQTT Neacuteanmoins nous pouvons avantageusement installer deux librairies speacutecifiques
Une qui facilite linterfaccedilage avec TTN
Une qui facilite la mise en place dinterface graphique
Installation des Nodes TTN
cd $HOMEnode-red
npm install node-red-contrib-ttn
Installation de Dashboard (interface graphique)
| 77
cd $HOMEnode-red
npm install node-red-dashboard
Il peut ecirctre necessaire de redeacutemarrer Node-RED pour prendre en compte linstallation de nos deux
Nodes
-----------------------------------
sudo apt-get install npm
sudo npm install -g npm
hash -r
cd ~node-red
npm install node-red-example node name
------------------------------------
813 Creacuteer une Application speacutecifique pour TTN Nous allons commencer par geacuterer le flux Uplink Apporter sur votre scheacutema un Node ttn uplink et
un Node Debug puis relier les Le Node ttn uplink nous permettra de configurer la
communication avec TTN en MQTT Le Node debug eacutecrira sur le terminal les informations brutes
qui seront reccedilu par le Node ttn uplink
Figure 91 Visualisation des trame publieacutees par TTN sur notre client MQTT
Double cliquer sur le Node ttn uplink pour le configurer comme la figure suivante
Le champ Name sera le nom du Node sur votre scheacutema Le champ Device ID est le device LoRa
concerneacute dans votre application De plus il faut entrer les caracteacuteristiques de votre application (Add
new ttn app) pour que Node-RED puisse sy connecter
Figure 92 Configuration du node ttn uplink
Configuration de votre nouvelle application
| 78
Figure 93 Identifiant et mot de passe de notre application
AppID Nom de votre application Dans notre cas seminaire_lorawan
Access Key Comme nous lavons deacutejagrave expliqueacute plus tocirct l Access Key vous sera donneacutee
par lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application
vous trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt
Overview
Le Node ttn uplink doit maintenant avoir le nom que vous avez configureacute Cliquer sur Deploy pour
lancer votre projet Le bloc ttn uplink doit maintenant ecirctre connecteacute agrave TTN Cela est speacutecifieacute
connected sous le bloc
Figure 94 Utilisation du Node TTN Uplink
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
Figure 95 Simulation de Uplink dans TTN
Vous devriez voir le reacutesultat dans la fenecirctre de Debug Par exemple pour le test denvoi de 31 32
correspondant au code ASCII des chiffres 1 et 2 vous devriez avoir la fenecirctre de Debug suivante
| 79
Figure 96 Reacutesultats obtenu dans la fenecirctre Debug apregraves la simulation dUplink
814 Creacuteation drsquoun Dashboard
Dans la mise en place de lenvironnement (chapitre 812) nous avons installeacute des Nodes
Dashboard qui vont nous permettre de reacutealiser une interface graphique tregraves simple et de la mettre
agrave disposition des utilisateurs via un des graphiques histogramme gauges afficheurshellip
Figure 97 Impleacutementation dune interface graphique dans Node RED
Linterface graphique que nous allons creacuteer sera constitueacutee donglet (tab) La mise en place des
composant se fait de la faccedilon suivante
Chaque eacuteleacutement graphique doit appartenir agrave un groupe de composant quil va falloir creacuteer
Chaque groupe de composant doit appartenir agrave un onglet (tab) quil va falloir creacuteer
Figure 98 Creacuteation dun groupe de composant
Figure 99 Creacuteation dun nouvel onglet dans le site web
Cliquer sur Deploy pour activer votre application
LURL pour joindre linterface graphique de votre site web est disponible sur ladresse
httpIP_Raspeberry_PI1880ui
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
| 80
Figure 100 Interface graphique du site web avec Node-RED
82 Programmation en PHP Maintenant que nous avons testeacute toute lrsquoarchitecture nous pouvons mettre en place une
application qui jouera deux rocircles
Un rocircle de Serveur HTTP POST reacutecupeacuterant les donneacutees en provenance de TTN
Un rocircle de Client HTTP POST qui geacuteneacuterera les requecirctes vers TTN
Un serveur web apache sur RPI heacuteberge cette application Linterface graphique du site web est
reacutealiseacute avec le template CSS proposeacute par Bootstrap [ httpsgetbootstrapcom ]
Figure 101 Architecture de notre application en PHP sur RPI
The Things Network
Notre Application
[ Serveur Apache sur Raspberry Pi ]
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 81
Nous allons lrsquoutiliser telle quelle Elle est juste proposeacutee agrave titre dexemple Lrsquoobjectif de cette
application est de geacuteneacuterer une ouverture fermeture de ruche agrave distance dans le cadre de projets
eacutetudiants du Master Electronique et Systegravemes Embarqueacutes de lUSMB [ httpscem-esetuniv-
smbfr ]
Figure 102 Application permettant de recevoir et deacutemettre des requecirctes HTTP POST
Configurer TTN pour pointer vers votre nouveau serveur et tester le flux montant et
descendant
| 82
9 Versions du document
Version 10 02022019
Version initiale
Version 20 23022019
Ajout drsquoun paragraphe Les systegravemes embarqueacutes dans lrsquoIoT En introduction
Compleacutement et ameacutelioration Ameacutelioration exercice eacutetalement de spectre
Correction Cacircblage Arduino
Ajout drsquoun paragraphe Fonctionnement de lrsquoArduino et ajout de librairies
Compleacutement et ameacutelioration Couche physique LoRa Ajout de 4 figures pour lrsquoexplication
de la modulation Chirp
Ajout drsquoun paragraphe sur les acronymes utiliseacutes au deacutebut du cours TTN LoRa MQTThellip
Compleacutement drsquoinformations sur les dB et dBm
Ajout LoRa Calculator
Version 30 8032019
Ajout de figure sur le rocircle de la Gateway LoRa
Ajout de paragraphe authentification avec le Network Server
Ajout de paragraphe sur le chiffrement avec lrsquoApplication Server
Ajout drsquoun sommaire en deacutebut de cours
Ajout de 2 scheacutemas ABP et OTAA
Retrait explication du deacutetail de la laquo Join Request raquo en OTAA Trop complexe attente de
reacutealisation drsquoun scheacutema plus explicite
Ajout drsquoun scheacutema sur lrsquoattaque par REPLAY
Ajout de paragraphe des diffeacuterents reacuteseaux LoRaWAN existants Opeacutereacutes et Priveacutes
Ajout des scheacutemas des trames LoRaWAN Physique LoRa MAC Application
Compleacutement drsquoinformation sur les Classes de Devices
Ajout drsquoun paragraphe sur la Gateway utiliseacutee pour le Downlink
Ajout drsquoun paragraphe sur le JSON
Compleacutement drsquoinformation sur le codage en Base64
Ajout drsquoinformation dans le deacutecodage des trames LoRaWAN
Restructuration des explications sur lrsquoenvoi et la reacutecupeacuteration des donneacutees en HTTPMQTT
Version 40 8032019
Ajout drsquoun chapitre Creacuteation de notre propre Application
Ajout drsquoun chapitre Creacuteation de notre propre Network et Application Server
Ajout drsquoune figure Visualisation des Chirps LoRa par SDR (Radio Logicielle)
Compleacutements drsquoinformation sur MQTT
Compleacutements dinformation sur les Topics de TTN en MQTT
| 12
Cependant on remarque aussi que lrsquoutilisation drsquoun Spreading Factor plus eacuteleveacute augmente
consideacuterablement le nombre de symbole eacutemis (2egraveme colonne du tableau) Comme nous le verrons
plus tard cela impactera eacutevidement le temps de transmission
| 13
3 La couche physique LoRa
31 La modulation LoRa Comme nous lrsquoavons expliqueacute plus tocirct la modulation LoRa utilise lrsquoeacutetalement de spectre pour
transmettre ces informations Mais au lieu drsquoutiliser des codes drsquoeacutetalement (CDMA) elle utilise une
meacutethode appeleacutee Chirp Spread Spectrum La finaliteacute est toujours la mecircme Avoir plusieurs
transmissions dans le mecircme canal La conseacutequence sur le spectre est aussi la mecircme cela provoque
un eacutetalement du spectre
311 La forme du symbole (Chirp) Le signal eacutemis par la modulation LoRa est un symbole dont la forme de base est repreacutesenteacutee ci-
dessous Son nom (Chirp) vient du fait que ce symbole est utiliseacute dans la technologie Radar (Chirp
Compressed High Intensity Radar Pulse)
Figure 5 Symbole de la modulation LoRa (source Wikipeacutedia)
La freacutequence de deacutepart est la freacutequence centrale du canal moins la Bande Passante diviseacutee par deux
La freacutequence de fin est la freacutequence centrale plus la Bande Passante diviseacutee par deux
La freacutequence centrale est appeleacutee le canal
La bande passante est la largeur de bande occupeacutee autour du canal
On considegravere une eacutemission sur la freacutequence centrale 868 Mhz avec une Bande Passante
de 125 kHz Donner la freacutequence de deacutebut et la freacutequence de fin du sweep
Freacutequence de deacutebut
Freacutequence de fin
Pour faciliter la repreacutesentation de ce symbole on utilise plutocirct un graphique TempsFreacutequence de
la forme suivante
| 14
Figure 6 Forme du symbole de base (CHIRP)
En LoRa chaque symbole repreacutesente un certain nombre de bits transmis La regravegle est la suivante
Nombre de bits transmis dans un symbole = Spreading Factor
Par exemple si la transmission utilise un Spreading Factor de 10 (SF10) alors un symbole repreacutesente
10 bits
Crsquoest-agrave-dire qursquoagrave lrsquoeacutemission les bits sont regroupeacutes par paquet de SF bits puis chaque paquet est
repreacutesenteacute par un symbole particulier parmi 2119878119865formes de symboles possibles
Sur la figure suivante voici un exemple theacuteorique drsquoune modulation en SF2 agrave 868 Mhz sur une
bande passante de 125 kHz Chaque symbole repreacutesente donc 2 bits
Figure 7 Symboles eacutemis en Modulation LoRa (Cas theacuteorique en SF2)
Exemple
On considegravere la suite binaire suivante 0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Le Spreading Factor utiliseacute est SF10
Nous regroupons donc les bits par paquet de 10 Chaque paquet de 10 bits sera repreacutesenteacute par un
symbole (sweep) particulier Il y a 1024 symboles diffeacuterents pour coder les 1024 combinaisons
binaires possibles (210)
Freacutequence
Temps
868 000 000 Hz
868 062 500 Hz
Un symbole Un symbole
867 937 500 Hz
Temps
868 000 000 Hz
867 937 500 Hz
Symbole 0
Bits laquo 00 raquo
Symbole 1
Bits laquo 01 raquo
Symbole 2
Bits laquo 10 raquo Symbole 3
Bits laquo 11 raquo
12
5 k
Hz
868 062 500 Hz
| 15
Figure 8 Emission des Chirp en LoRa
Avec un outils drsquoanalyse spectrale actif pendant lrsquoeacutemission LoRa drsquoun Device on peut afficher les
successions de symbole qui sont envoyeacutes Cette oscillogramme a eacuteteacute reacutealiseacute agrave lrsquoaide drsquoun SDR
(Software Digital Radio)
Figure 9 Visualisation des Chirps LoRa reacuteellement eacutemis pendant une transmission
312 Dureacutee drsquoeacutemission drsquoun symbole En LoRa la dureacutee drsquoeacutemission de chaque symbole (Chirp) deacutepend du Spreading Factor utiliseacute Plus le
SF est grand et plus le temps drsquoeacutemission sera long Pour une mecircme bande passante le temps
drsquoeacutemission drsquoun symbole en SF8 est deux fois plus long que le temps drsquoeacutemission drsquoun symbole en
SF7 Ainsi de suite jusqursquoagrave SF12
0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Envoi de 1 Chirp Envoi de 1 Chirp Envoi de 1 Chirp
Transmission Transmission Transmission
| 16
Figure 10 Temps drsquoeacutemission drsquoun symbole (Chirp) en fonction du SF
En revanche le temps drsquoeacutemission drsquoun symbole est inversement proportionnel agrave la bande passante
119879119904 =2119878119865
119861119886119899119889119908119894119889119905ℎ Le deacutebit des symboles est donc de
1
119879119878= 119865119904 =
119861119886119899119889119908119894119889119905ℎ
2119878119865 En toute logique plus la
bande passant est eacuteleveacute plus le deacutebit des symboles sera eacuteleveacute Comme chaque symbole comprend
SF bit on retrouve alors le deacutebit binaire
119863119887 = 119878119865119861119886119899119889119908119894119889119905ℎ
2119878119865
Plus le Spreading Factor sera eacuteleveacute plus le deacutebit binaire sera faible
Plus la Bande Passante sera eacuteleveacutee plus le deacutebit binaire sera fort
Exemple Drsquoapregraves la formule du deacutebit binaire trouver le deacutebit pour les deux cas suivants
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
32 Coding Rate Le Coding Rate est un ratio qui augmentera le nombre de bits agrave transmettre afin de reacutealiser de la
deacutetection correction drsquoerreur Dans le cas drsquoun CR = 4 8 il y aura 8 bits transmis reacuteellement agrave
chaque fois que nous souhaitons transmettre 4 bits Dans cette exemple cela provoque une
transmission drsquoun nombre de bit multiplieacute par 2
SF7
Freacutequence
Temps
Freacutequence centrale
Freacutequence haute
Temps drsquoun symbole eacutemit en SF 12
Freacutequence basse
SF8
SF9
SF10
SF11
SF12
Temps drsquoun symbole eacutemit en SF 11
| 17
Figure 11 Influence du Coding Rate sur le nombre de bits ajouteacute
Si on reprend lrsquoexemple preacuteceacutedent avec un CR de 4 5 nous avons une augmentation de 125 du
nombre de bits agrave transmettre Redonner la deacutebit en prenant en compte le CR
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
La documentation du composant RN2483 donne les deacutebits en fonction du Spreading Factor
la Bande Passante et le Coding Rate Veacuterifier la coheacuterence du reacutesultat avec votre calcul
preacuteceacutedent
Figure 12 Deacutebit en fonction des paramegravetres de la transmission LoRa
33 Utilisation du LoRa Calculator Le logiciel laquo LoRa Calculator raquo est un petit exeacutecutable permettant de simuler une transmission LoRa
en fonction des caracteacuteristiques saisies Canal SF CR etchellip Il est teacuteleacutechargeable agrave lrsquoadresse
suivante httpsbitly2TyloAh
| 18
Figure 13 Le logiciel LoRa Calculator
En reprenant lrsquoexemple preacuteceacutedent (SF7 Bande Passante 125 kHz CR 45) veacuterifier les
calculs du laquo Equivalent Bitrate raquo
34 Time On Air La norme LoRaWAN impose qursquoun Device LoRa ne transmette pas plus de 1 du temps Cela est
repreacutesenteacute par un Duty Cycle Par exemple un Duty Cycle de 1 signifie que si jrsquoeacutemet pendant 1 je
ne dois plus eacutemettre pendant 99 quel que soit lrsquouniteacute de temps utiliseacutee
En reprenant les exemples preacuteceacutedents quels sont les deacutebits moyens si on prend en compte
le laquo Time On Air raquo
Cas 1 Pour SF7 et 125 khz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
Dans le logiciel laquo LoRa Calculator raquo (onglet laquo Energy Profile raquo) nous pouvons estimer la
dureacutee de vie drsquoune batterie Nous prenons lrsquoexemple drsquoun releveacute de tempeacuterature dans un
bacirctiment avec les caracteacuteristiques suivantes
| 19
SF CR Bande Passante etc Nous nous placcedilons dans le cas 1 des exemples preacuteceacutedents
Le releveacute de tempeacuterature se fera toutes les 15 mins
La batterie est constitueacute de 3 petites piles bacirctons [ AAA LR03 ] 12V en seacuterie Soit 36 V
1000 mAh
35 Mise en œuvre LoRa en point agrave point Ce test sera reacutealiseacute avec des modules LoRa RN2483 (Microchip) et une carte microcontrocircleur
ARDUINO
Figure 14 Communication LoRa en Point agrave Point
Reacutealiser le cacircblage de votre module RN2483 suivant le tableau suivant
Connecteur Arduino Click Board RN2483
5V 5V
GND GND
11 RX
10 TX
Tableau 4 Cacircblage de lrsquoARDUINO et de la click Board RN2483
351 Utilisation de lrsquoIDE Arduino Lrsquoenvironnement Arduino est tregraves simple Nous allons reacutealiser un programme pour montrer son
fonctionnement
La connexion de la carte est effectueacutee agrave lrsquoaide drsquoun port USB qui eacutemule une liaison seacuterie
RS232 Il faut donc choisir le bon port Arduino IDE gt Outils gt Port
Pour creacuteer un nouveau programme (sketch) Arduino IDE gt Fichier gt Nouveau
Il y a deux parties dans un sketch
Une fonction setup() qui sera exeacutecuteacutee qursquoune seule fois au deacutemarrage
Une fonction loop() qui sera exeacutecuteacutee en boucle
Ecrire le code suivant
Emetteur
Reacutecepteur
UA
RT
UA
RT
| 20
void setup()
Serialbegin(9600)
void loop()
Serialprintln(hello word)
Compiler et Teacuteleacuteverser Croquis gt Teacuteleacuteverser
Voir la sortie sur la liaison seacuterie Outils gt Moniteur Seacuterie gt Choisir la vitesse de
transmission ici 9600 bauds (en bas agrave droite)
352 Validation du fonctionnement Deux binocircmes joueront le rocircle drsquoeacutemetteur tous les autres binocircmes seront en reacutecepteur
Reacutecupeacuterer les programmes dans Moodle dans le dossier laquo RN2483-Arduino-Point2Point raquo
Installer la librairie RN2483 Arduino IDE gt Croquis gt Inclure une bibliothegraveque gt Ajouter la
bibliothegraveque zip
Reacutepartissez les rocircles Emetteurs Reacutecepteurs et reacutecupeacuterer le programme LoraBlinkerRX ou
LoraBlinkerTX en fonction Les 2 binocircmes en eacutemission devront modifier le code du sketch
Arduino pour transmettre des donneacutees speacutecifiques afin de les diffeacuterencier [
loraSerialprintln(radio tx 30) ]
Validez la reacuteception des donneacutees eacutemises par les deux binocircmes qui transmettent des
donneacutees Ces donneacutees reccedilues sont eacutecrite agrave 57600 bauds sur le moniteur seacuterie de lrsquoArduino
353 Mise en valeur du Spreading Factor On srsquoaperccediloit dans la manipulation preacuteceacutedente que les Devices LoRa reccediloivent les donneacutees des deux
eacutemetteurs Nous allons conserver le mecircme canal drsquoeacutemission (8691 Mhz) mais un des deux
eacutemetteurs va modifier son laquo Spreading Factor raquo La salle sera donc seacutepareacutee en deux groupes
1er groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF7
2egraveme groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF8
Validez la reacuteception des donneacutees eacutemises seulement pour le Spreading Factor que vous
utilisez
| 21
4 Le protocole LoRaWAN
Le LoRa est le type de modulation utiliseacute entre deux Devices ou entre un Device et une Gateway
Lorsque nous parlons de lrsquoensemble de la chaine de communication (Device Gateway Serveur) alors
nous parlons de communication LoRaWAN Nous allons voir lrsquoarchitecture drsquoun reacuteseau LoRaWAN
ainsi que les regravegles de ce protocole
41 Structure drsquoun reacuteseau LoRaWAN Nous retrouvons drsquoun cocircteacute le Device LoRa qui transmet une donneacutee Elle est reacuteceptionneacutee agrave lrsquoautre
extreacutemiteacute du reacuteseau par un Utilisateur La structure globale du reacuteseau LoRaWAN peut ecirctre
repreacutesenteacutee par la figure suivante
411 Les Devices LoRa Les Devices LoRa sont des systegravemes eacutelectroniques appartenant au monde de lrsquoIoT Faible
consommation faible taille faible puissance et faible taille
Ils possegravedent une radio LoRa permettant de joindre les Gateways Les Gateways ne sont pas
adresseacutees speacutecifiquement toutes celles preacutesentes dans la zone de couverture reccediloivent les
messages et les traitent
412 Les Gateways LoRa Elles eacutecoutent sur tous les canaux et sur tous les Spreading Factor Lorsqursquoune trame LoRa est reccedilue
elle transmet son contenu sur internet agrave destination du Network Server qui a eacuteteacute configureacute dans la
Gateway au preacutealable
Elle joue donc le rocircle de passerelle entre une modulation LoRa et une communication IP
Devices
LoRa Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
Internet Internet
Figure 15 Structure globale dun reacuteseau LORAWAN
| 22
Chaque Gateway LoRa possegravede un identifiant unique (EUI sur 64 bits)
413 Le Network Server
Le Network Server reccediloit les messages transmis par les Gateways et supprime les doublons
(plusieurs Gateway peuvent avoir reccedilu le mecircme message) Les informations transmises au Network
Server depuis les Devices LoRa sont authentifieacutes gracircce agrave une cleacute AES 128 bits appeleacutee Network
Session Key NwkSKey Nous parlons bien ici drsquoauthentification et non pas de chiffrement comme
nous le verrons plus tard
414 Application Server Il est souvent sur le mecircme support physique que le Network Server Il permet de dissocier les
applications les unes des autres Chaque application enregistre des Devices LoRa qui auront le droit
Devices Gateways Network
Server
Internet
Network Session Key (NwkSKey)
Authentification
Figure 17 Authentification entre le Device LoRa et le Network Server
Internet
UDP IP
Modulation
LoRa
Device LoRa
Gateway
Network Server
LoRaWAN
Modulation
LoRa
Passerelle LoRa Internet
Internet
UDP IP
LoRaWAN
Transmission Radio
Application Application
Figure 16 Le rocircle de la Gateway LoRa
| 23
de stocker leurs donneacutees (Frame Payload) Les message transmis agrave lrsquoapplication server sont chiffreacutes
gracircce agrave une cleacute AES 128 bits appeleacutee Application Session Key AppSKey
Le scheacutema suivant reacutesume lrsquoutilisation
De la Network Session Key (NwkSKey) pour lrsquoauthentification entre le Device LoRa et le
Network Server
De lrsquoApplication Session Key (AppSKey) pour le chiffrement entre le Device LoRa et
lrsquoApplication Server
Devices Gateways Network
Server Application
Server
Internet
Application Session Key (AppSKey)
Chiffrement
Figure 18 Chiffrement entre le Device LORA et lrsquoApplication Server
| 24
415 Application Web Serveur Cette application doit drsquoune part reacutecupeacuterer les donneacutees de lrsquoApplication Serveur Dans le cadre de
ce cours cela sera fait de deux faccedilons
Avec le protocole HTTP
Avec le protocole MQTT
Figure 20 Application Web Server
Figure 19 Authentification et chiffrement en LoRaWan
Devices Gateways
Network
Server Application
Server
Internet
Network Session Key
Application Session Key
Network
Server Application
Server
Application
Server Web
Utilisateur
Protocole
MQTT ou HTTP
Flux Uplink
Flux Downlink
| 25
Le flux habituel dans lrsquoIoT est le flux Uplink (flux montant) crsquoest-agrave-dire lrsquoeacutemission de donneacutees des
objets vers le serveur Comme nous lrsquoexpliquerons plus loin en LoRaWAN il est aussi possible de
transfeacuterer des donneacutees aux Device LoRa par un flux Downlink (flux descendant)
Drsquoautre part lrsquoapplication mettra agrave disposition les donneacutees aux utilisateurs sous forme par exemple
drsquoun serveur web drsquoune base de donneacutees et drsquoune visualisation graphique
416 Authentification avec le Network Server La Network Session Key (NwkSKey) sert agrave lrsquoauthentification entre le Device LoRa e le Network Server
Afin de reacutealiser cette authentification entre le Device et le Network Server un champ MIC (Message
Integrity Control) est rajouteacute agrave la trame Il est calculeacute en fonction des donneacutees transmises et du
NwkSkey A la reacuteception le mecircme calcul est effectueacute Si les cleacutes sont eacutequivalentes dans le Device et
dans le Network Server alors les deux MIC calculeacutes doivent correspondre
417 Chiffrement des donneacutees vers lrsquoApplication Server
LrsquoApplication Session Key (AppSKey) sert pour le chiffrement entre le Device LoRa et lrsquoApplication
Server Les donneacutees chiffreacutees seront alors deacutecodeacutees agrave la reacuteception sur lrsquoApplication Server srsquoil
possegravede la mecircme cleacute Si on reprend le scheacutema preacuteceacutedent les laquo donneacutees x raquo sont chiffreacutees
deacutechiffreacutees par le processus suivant
Donneacutees x chiffreacutees NwkSkey x
MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees
NwkSkey x
Trame eacutemise Trame reccedilue
Device LoRa Network Server
Si =
Alors la trame est authentifieacutee
MIC geacuteneacutereacute Emission MIC geacuteneacutereacute Reacuteception
MIC geacuteneacutereacute Reacuteception
Figure 21 Authentification dun Device LoRa par le Network Server
| 26
Figure 22 Chiffrement des donneacutees par lApplication Session Key
418 Combinaison de lrsquoauthentification et du chiffrement On peut maintenant repreacutesenter sur le mecircme scheacutema la construction de la trame LoRaWAN avec
drsquoune part lrsquoauthentification et drsquoautre part le chiffrement
Figure 23 Chiffrement puis Authentification
42 Classes des Devices LoRaWAN Les Devices LoRa sont classeacutes en 3 cateacutegories (A B C) en fonction de leur consommation et de leur
accessibiliteacute en Downlink crsquoest-agrave-dire la faciliteacute qursquoun utilisateur aura agrave transmettre une trame au
Device LoRa
421 Classe A (All) Minimal power Application Tous les Devices LoRaWAN sont de classe A Chaque Device peut transmettre (Uplink) agrave la Gateway
sans veacuterification de la disponibiliteacute du reacutecepteur Si la transmission eacutechoue elle sera reacuteeacutemise apregraves
un certain temps Cette transmission est suivie de 2 fenecirctres de reacuteception tregraves courtes La Gateway
peut alors transmettre pendant le laquo RX Slot 1 raquo ou le laquo RX Slot 2 raquo mais pas les deux
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Device LoRa
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Application Server
Donneacutees non chiffreacutees
AppSKey
Donneacutees chiffreacutees Entecircte
NwkSKey
MIC geacuteneacutereacute en eacutemission Trame transmise =
| 27
Figure 24 Slots de reacuteception pour un Device LoRa de classe A
Source de lrsquoimage httpszakelijkforumkpncom
La dureacutee des fenecirctres doit ecirctre au minimum la dureacutee de reacuteception drsquoun preacuteambule Un preacuteambule
dure 1225 Tsymbole et deacutepend donc du Data Rate (DR voir paragraphe 445 pour plus drsquoinformation
sur le DR) Lorsque qursquoun preacuteambule est deacutetecteacute le reacutecepteur doit rester actif jusqursquoagrave la fin de la
transmission Si la trame reccedilue pendant la premiegravere fenecirctre de reacuteception eacutetait bien agrave destination du
Device LoRa alors la deuxiegraveme fenecirctre nrsquoest pas ouverte
Premiegravere fenecirctre de reacuteception
Le Slot RX1 est programmeacute par deacutefaut agrave 1 seconde + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont les mecircme que ceux choisis lors de la phase drsquoeacutemission
(Uplink)
Seconde fenecirctre de reacuteception
Le Slot RX2 est programmeacute par deacutefaut agrave 2 secondes + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont configurables mais fixes
Un Device LoRa qui est uniquement de classe A ne peut pas recevoir srsquoil nrsquoa pas eacutemis Il
nrsquoest donc pas joignable facilement
422 Classe B (Beacon) Scheduled Receive Slot Les Devices de classe B ont le mecircme comportement que les Devices de classe A mais drsquoautres
fenecirctres de reacuteceptions sont programmeacutees agrave des peacuteriodes preacutecises Afin de synchroniser les fenecirctres
de reacuteception du Device LoRa la Gateway doit transmettre des balises (Beacons) de faccedilon reacuteguliegravere
| 28
Figure 25 Slots de reacuteception pour un Device LoRa de classe B
Source de lrsquoimage httpszakelijkforumkpncom
Un Device LoRa de classe B est joignable reacuteguliegraverement sans qursquoil soit neacutecessairement
obligeacute drsquoeacutemettre En revanche il consomme plus qursquoun Device de classe A
423 Classe C (Continuous) Continuously Listening Les Devices de classe C ont des fenecirctres de reacuteception constamment ouvertes entre 2 Uplinks Ces
Devices consomment donc beaucoup plus
Figure 26 Slots de reacuteception pour un Device LoRa de classe C
Source de lrsquoimage httpszakelijkforumkpncom
| 29
Un Device LoRa de classe C est joignable en permanence En revanche crsquoest la classe de
Device qui est la plus eacutenergivore
424 Quelle Gateway pour les flux Downlink
Nous avons donc vu que le fonctionnement classique du protocole LoRaWAN eacutetait de reacutecupeacuterer de
lrsquoinformation depuis le Device LoRa Crsquoest le flux Uplink
Dans le cas ougrave lrsquoutilisateur transmet des informations au Device LoRa (flux Downlink) on peut se
demander quelle Gateway sera choisie pour transfeacuterer les donneacutees au Device LoRa En effet
lrsquoendroit ougrave est situeacute le Device LoRa nrsquoest pas neacutecessairement connu agrave lrsquoavance
La Gateway utiliseacutee pour le Downlink est celle qui a reccedilu le dernier message du Device
LoRa Un message ne pourra jamais arriver agrave destination drsquoun Device LoRa si celui-ci nrsquoa
jamais transmis quel que soit sa classe A B ou C
43 Activation des Devices LoRa et seacutecuriteacute En LoRaWAN les trois eacuteleacutements indispensables pour la communication sont le DevAddr pour
lrsquoindentification du Device ainsi que deux cleacutes le NwkSKey pour lrsquoauthentification et lrsquoAppSKey
pour le chiffrement Deux meacutethodes sont possibles pour fournir ces informations agrave la fois au Device
LoRa et au serveur
Activation By Personalization APB
Over The Air Activation
431 ABP Activation By Personalization Crsquoest la plus simple des meacutethodes Crsquoest donc peut ecirctre celle que nous avons tendance agrave utiliser lors
drsquoun test de prototype et drsquoune mise en place de communication LoRaWAN
Le Device LoRa possegravede deacutejagrave le DevAddr lrsquoAppSKey et le NwkSKey
Le Network server possegravede deacutejagrave le DevAddr et le NwkSKey
Lrsquoapplication serveur possegravede deacutejagrave le DevAddr et le AppSKey
En ABP toutes les informations neacutecessaires agrave la communication sont deacutejagrave connues par le
Device LoRa et par le Serveur
| 30
432 OTAA Over The Air Activation Crsquoest la meacutethode qursquoil faut privileacutegier car crsquoest celle qui est la plus seacutecuriseacutee Le Device LoRa doit
connaitre le DevEUI lrsquoAppEUI et lrsquoAppkey Le Network Server doit lui connaitre la mecircme Appkey
Tous les eacuteleacutements noteacutes EUI (Extended Unique Identifier) sont toujours sur une taille de
64 bits
Gracircce agrave ces informations de deacutepart et une neacutegociation avec le Network Server (Join Request) le
Device LoRa et le serveur vont geacuteneacuterer les informations essentielles DevAddr NwkSKey et
AppSKey
Figure 28 Obtention du DevAddr NwkSKey et AppSKey en OTAA
DevEUI Unique Identifier pour le device LoRa (Equivalent agrave une MAC sur Ethernet)
Certains Device LoRa ont deacutejagrave un DevEUI fourni en usine
AppEUI Unique Identifier pour lrsquoapplication server
DevEUI
AppEUI
AppKey
Join
Request
DevAddr
NwkSKey
AppSKey
Network Server
Application Server
Devices 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 2
NwkSkey 2
AppSKey 2
Devices 2
DevAddr 2
NwkSkey 2
AppSKey 2
Paramegravetres stockeacutes sur le serveur
Paramegravetres programmeacutes
dans le composant
Figure 27 Parameacutetrage de DevAddr NwkSKey et AppSKey
| 31
AppKey AES 128 cleacute utiliseacutee pour geacuteneacuterer le MIC (Message Code Integrity) lors de la Join
Resquest Il est partageacute avec le Network server
NwkSKey Utiliseacute pour lrsquoauthentification avec le Network Server
AppSKey Utiliseacute pour le chiffrement des donneacutees
433 Seacutecuriteacute Les cleacutes AES 128 bits permettent le chiffrement des informations transmises en LoRaWAN Malgreacute
ce chiffrement une attaque connue en Wireless est celle du REPLAY Crsquoest-agrave-dire que le Hacker
enregistre des trames chiffreacutees circulant sur le reacuteseau LoRa pour les reacuteeacutemettre plus tard Mecircme si
le Hacker ne comprend pas le contenu (les trames sont chiffreacutees) les donneacutees qui sont transporteacutees
sont elles bien comprises par lrsquoApplication Server Des actions peuvent donc ecirctre reacutealiseacutees
simplement par mimeacutetisme
Pour eacuteviter cela la trame LoRaWAN integravegre un champ variable appeleacute laquo Frame Counter raquo Il srsquoagit
drsquoun nombre numeacuterotant la trame sur 16 ou 32 bits LrsquoApplication Server acceptera une trame
uniquement si le laquo Frame Counter raquo reccedilu est supeacuterieur au laquoFrame Counter raquo preacuteceacutedemment Donc
si le Hacker retransmet la trame telle qursquoelle le laquo Frame Counter raquo sera eacutequivalent donc la trame
sera refuseacutee Et comme la trame est chiffreacutee le Hacker nrsquoa pas moyen de savoir comment modifier
un champ de cette trame
Cette seacutecuriteacute impleacutementeacutee par les laquo Frame Counter raquo est inteacuteressante pour srsquoaffranchir drsquoune
attaque par REPLAY mais dans nos tests cela peut poser problegraveme En effet agrave chaque fois que nous
redeacutemarrons le microcontrocircleur notre laquo Frame Counter raquo revient agrave zeacutero alors que celui de
lrsquoApplication Server continue de srsquoincreacutementer Cela peut ecirctre reacutesolue par diffeacuterentes maniegraveres
1 Deacutesactivation du laquo Frame Counter Check raquo Dans certain Application Server cette option
peut ecirctre proposeacutee Bien sucircr il faudra garder en tecircte la faille de seacutecuriteacute que cela engendre
Network Server
Application Server
Devices LoRa
NwkSkey
AppSKey
NwkSkey
AppSKey Hacker
(1) (2)
(1) Ecoute
(2) Reacuteeacutemission
Figure 29 Attaque par REPLAY
| 32
Figure 30 Deacutesactivation du Frame Counter Check dans TTN
2 Utiliser lrsquoauthentification par OTAA au lieu de ABP En effet agrave chaque ouverture de session
en OTAA le laquo Frame Counter raquo est reacuteinitialiseacute coteacute serveur
3 Conserver la valeur du laquo Frame Counter raquo dans une meacutemoire non volatile et reacutecupeacuterer sa
valeur au deacutemarrage du Device LoRa
44 La Trame LoRa LoRaWAN
441 Les couches du protocole LoRaWAN
Lorsque nous avons fait une communication en Point agrave Point nous avons simplement utiliseacute la
couche physique de la modulation LoRa Lorsque nous souhaitons utiliser le protocole LoRaWAN
des couches protocolaires suppleacutementaires se rajoutent
Figure 31 Les couches protocolaires du LoRaWAN
Chaque couche rajoute un service Lors de lrsquoenvoi de la trame les donneacutees utilisateurs sont donc
encapsuleacutees dans chaque couche infeacuterieure jusqursquoagrave la transmission Le deacutetail de lrsquoensemble de la
trame LoRaWAN par couche est deacutecrit sur la figure Figure 32
LoRa Modulation
LoRa Mac
Application
Couche Physique
Couche Mac
Couche Application
| 33
442 Couche Application La couche Application accueille les donneacutees de lrsquoutilisateur Avant de les encapsuler elles sont
chiffreacutees avec lrsquoAppSKey afin de seacutecuriser la transaction
Un ensemble de champs nommeacute Frame Header permet de speacutecifier le DevAddr le Frame Control
le Frame Counter et le Frame Option
Le Frame Port deacutepend du type drsquoapplication et sera choisi par lrsquoutilisateur
Le Frame Payload sont les donneacutees chiffreacutees agrave transmettre Le nombre drsquooctets maximum pouvant
ecirctre transmis (N octets) est donneacute dans le tableau suivant
PHY Payload
P octets Couche
Physique
Couche
Mac
Couche
Application
CRC
2 octets Header + Header CRC
20 bits Preamble
MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Figure 32 Trame LORAWAN complegravete par couche protocolaire
Couche
Application Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Frame Header
Figure 33 Trame LORA couche Applicative
| 34
Data Rate Spreading Factor Bandwidth Max Frame Payload (Nombre N) DR 0 SF12 125 KHz 51 octets
DR 1 SF11 125 KHz 51 octets
DR 2 SF10 125 KHz 51 octets
DR 3 SF9 125 KHz 115 octets
DR 4 SF8 125 KHz 222 octets
DR 5 SF7 125 KHz 222 octets
DR 6 SF7 250 KHz 222 octets
Tableau 5 Taille maximum du Frame Payload en fonction du Data Rate
443 Couche LoRa MAC Cette trame est destineacutee au Network Server Elle est authentifieacutee gracircce au champ MIC (Message
Integrity Protocol) selon la meacutethode expliqueacutee au paragraphe 416
Le protocole LoRa MAC est composeacute de
1 MAC Header Version de protocole et type de message
Type de Message Description 000 Join-Request
001 Join-Accept
010 Unconfirmed Data Up
011 Unconfirmed Data Down
100 Confirmed Data Up
101 Confirmed Data Down
110 Rejoin-request
111 Proprietary
Tableau 6 Les types de messages transmis en LoRaWAN
2 MAC Payload Contient tout le protocole applicatif
3 MIC Message Integrity Code pour lrsquoauthentification de la trame
444 Couche physique Modulation LoRa
Le choix du moment drsquoeacutemission des Devices LoRa se fait de faccedilon simple Lorsqursquoun eacutequipement
doit eacutemettre il le fait sans controcircle et ne cherche pas agrave savoir si le canal est libre Si le paquet a eacuteteacute
perdu il le retransmettra simplement au bout drsquoun temps aleacuteatoire La couche physique est
repreacutesenteacutee par lrsquoeacutemission de la trame suivante
Couche
Mac MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Figure 34 Trame LORA couche LORA MAC
| 35
Le Preacuteambule est repreacutesenteacute par 8 symboles + 425 Le temps du Preacuteambule est donc de 1225
Tsymbole
Len-tecircte (Header optionnel) est seulement preacutesent dans le mode de transmission par deacutefaut
(explicite) il est transmis avec un Coding Rate de 48 Il indique la taille des donneacutees le Coding Rate
pour le reste de la trame et il preacutecise eacutegalement si un CRC sera preacutesent en fin de trame
Le PHY Payload contient toutes les informations de la Couche LoRa MAC
Le CRC sert agrave la deacutetection drsquoerreur de la trame LoRa
445 Canaux et bandes de freacutequences et Data Rate (DR) Le LoRa utilise des bandes de freacutequences diffeacuterentes suivant les reacutegions du monde En Europe la
bande utiliseacutee est celle des 868 Mhz [ De 863 Mhz agrave 870 Mhz ] Le LoRaWAN deacutefinie les 8 canaux agrave
utiliser pour communiquer avec une Gateway suivant le tableau suivant
Canaux Spreading Factor Bandwidth 8681 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz SF7 250 kHz
8685 Mhz De SF7 agrave SF12 125 kHz
8671 Mhz De SF7 agrave SF12 125 kHz
8673 Mhz De SF7 agrave SF12 125 kHz
8675 Mhz De SF7 agrave SF12 125 kHz
8677 Mhz De SF7 agrave SF12 125 kHz
8679 Mhz De SF7 agrave SF12 125 kHz
Tableau 7 Canaux SF et Bandwidth de notre Gateway LoRaWAN
Une Gateway LoRa eacutecoute donc sur 8 canaux simultaneacutement avec les 6 Spreading Factor
diffeacuterents soit 48 combinaisons possibles
Comme nous lrsquoavons vu le Spreading Factor a des conseacutequences sur le deacutebit de la transmission Ces
deacutebits sont noteacutes DR (Data Rate) et sont normaliseacutes de DR0 agrave DR6
PHY Payload
P octets Couche
Physique CRC
2 octets Header + Header CRC
( Optionnel ) 20 bits Preamble
Figure 35 Trame LORA couche Physique
| 36
Data Rate Spreading Factor Bandwidth DR 0 SF12 125 KHz
DR 1 SF11 125 KHz
DR 2 SF10 125 KHz
DR 3 SF9 125 KHz
DR 4 SF8 125 KHz
DR 5 SF7 125 KHz
DR 6 SF7 250 KHz
Tableau 8 Deacutenomination DR en fonction du SF et de la Bande Passante
446 Trame reccedilue et transmise par la Gateway LoRaWAN La Gateway reccediloit drsquoun cocircteacute un message radio moduleacute en LoRa et transmet de lrsquoautre cocircteacute une trame
IP agrave destination du Network Server
Coteacute interface Radio La Gateway reacuteceptionne une trame LoRaWAN et extrait le PHY Payload Celui-
ci est codeacute au format ASCII en base 64 (voir le paragraphe 541) La Gateway extrait aussi toutes les
informations utiles sur les caracteacuteristiques de la reacuteception qui a eu lieu SF Bandwidth RSSI Time
On Airhellipetchellip
Coteacute interface reacuteseau IP La Gateway transmet lrsquoensemble de ces informations dans un paquet IP
(UDP) au Network Server Les donneacutees transmises sont du texte en format JSON (voir paragraphe
447) La Gateway a donc bien un rocircle de passerelle entre le protocole LoRa drsquoun cocircteacute et un reacuteseau
IP de lrsquoautre
Internet
UDP IP
Device LoRa
Gateway
Network Server Modulation
LoRa
Passerelle LoRa Internet
Transmission Radio Internet
Figure 36 Rocircle de la Gateway LoRa
| 37
447 Le format JSON Le format JSON est un format texte composeacute drsquoune succession de couple nomvaleur Dans
lrsquoexemple de la figure preacuteceacutedente gw_id est un nom et eui-b827ebfffeae26f5 est la valeur
associeacutee Dans cette exemple la valeur est un string Les objets sont deacutelimiteacutes par un des accolades
et
Une valeur peut ecirctre
Un string exemple coding_rate 45
Un nombre exemple spreading_factor 12
Un objet exemple lora spreading_factor 12 air_time 2465792000
Un Boolean
Ethernet
Gateway
Modulation
LORA
Reacutecupeacuteration du PHY PAYLOAD en base 64
Reacutecupeacuteration des caracteacuteristiques de la transmission Canal SF CR hellip
IP (IP dest routereuthethingsnetwork)
UDP (Port dest 1700 Port source 1700)
Donneacutees applicatives (format JSON)
gw_id eui-b827ebfffeae26f5
payload QNAPvA6Ax3ECqHk4C8hfzuA==
lora
spreading_factor 12
bandwidth 125
air_time 2465792000
coding_rate 45
timestamp 2019-01-20T133746017Z
rssi -105
snr -162
dev_addr 0EBC0FD0
frequency 867100000
Internet Transmission Radio LORA
Figure 37 Passerelle (Gateway) LORAWAN
| 38
5 Mise en œuvre drsquoun reacuteseau LoRaWAN
51 Les diffeacuterents types de reacuteseaux Les reacuteseaux LoRaWAN peuvent ecirctre utiliseacute suivant deux meacutethodes
En utilisant les reacuteseaux LoRaWAN opeacutereacutes proposeacutes par les opeacuterateurs de teacuteleacutecoms
En utilisant votre propre reacuteseau LoRaWAN priveacute
511 Les reacuteseaux LoRaWAN opeacutereacutes Ce sont des reacuteseaux LoRaWAN proposeacutes par les opeacuterateurs Par exemple Objenious (filiale de
Bouyges) ou encore Orange Dans le cas de lrsquoutilisation des reacuteseaux opeacutereacutes lrsquoutilisateur a juste
besoin de srsquooccuper des Devices LoRa Les Gateways le Network Server et lrsquoApplication Server sont
geacutereacutes par lrsquoopeacuterateur
512 Les reacuteseaux LoRaWAN priveacutes Chacun est libre de reacutealiser son propre reacuteseau priveacute en impleacutementant sa propre Gateway pour
communiquer avec ses Devices LoRa Lrsquoimpleacutementation du Network Server et de lrsquoApplication Server
peuvent alors ecirctre envisageacutes de diffeacuterentes faccedilons
Network Server et Application serveur priveacutees Crsquoest le deacuteveloppeur qui les mets en place Dans
certaines Gateways une impleacutementation de ces deux serveurs est deacutejagrave proposeacutee Sinon il est
possible de la mettre en place Il existe des serveurs (Network et Application) open source crsquoest le
cas par exemple de LoRa Serveur [ wwwloraserverio ]
Une autre alternantive est httpsgithubcomgotthardplorawan-server
LoRaServer et lorawan-server sont deux applications Open Source
Network Server et Application Server en ligne Un certain nombre de Network Server et
drsquoApplication Server sont proposeacutes Ce sont des services payants ou avec des contreparties
Loriot [ wwwloriotio ]
ResIoT [ wwwresiotio ]
The Things Network [ wwwthethingsnetworkorg ] Crsquoest la solution que nous utiliserons
513 Les zones de couvertures
Les zones de couvertures des reacuteseaux opeacutereacutes sont mise agrave jour par les opeacuterateurs celle drsquoobjenious
est par exemple disponible ici httpsobjeniouscomreseau
Pour connaitre la zone de couverture de notre Gateway utiliseacutee avec TTN nous pouvons utiliser
lrsquoapplication TTN Mapper httpsttnmapperorg Lrsquoideacutee est de promener son Device LoRa associeacute
agrave un GPS dans la zone de couverture des Gateway qui nous entourent A chaque trame reccedilue par le
| 39
Serveur on note les coordonneacutees GPS du Device LoRa ainsi que la Gateway qui a transmis le
message Toutes ces informations sont alors retranscrites sur une carte
52 The Things Network (TTN)
521 Preacutesentation de TTN
Pour la suite nous utiliserons le Network Server et lrsquoApplication Server fourni par TTN
[wwwthethingsnetworkorg]
TTN est gratuit et Open Source En revanche le fait drsquoutiliser TTN impose agrave ceux qui enregistrent
des Gateways de les mettre agrave disposition agrave tous les autres utilisateurs de TTN Lrsquoobjectif est de
reacutealiser un reacuteseau global ouvert
522 Configuration de la Gateway A lrsquouniversiteacute nous avons deux Gateways LoRa (Marque EBDS) Elles sont toutes les deux situeacutees sur
le Campus de Technolac Une Gateway est agrave lrsquointeacuterieur du bacirctiment ISERAN et sert essentiellement
pour les Travaux Pratiques et formations Lrsquoautre est sur le toit du bacirctiment Chablais et est mise agrave
disposition du public via le service de TTN
Les deux Gateway eacutecoutent sur tous les canaux et sur tous les Spreading Factor SF7 gt SF12
Lrsquo IP de la Gateway LoRa agrave lrsquouniversiteacute (bacirctiment ISERAN) est 192168140196
Serveur DNS 1934812032 19348129137
Network Server (TTN) 137616868 routereuthethingsnetwork
Port Upstream 1700 Port Downstream 1700
523 Enregistrement des Gateways Appplication et Devices La configuration de TTN se fait en ligne La premiegravere opeacuteration agrave reacutealiser lorsqursquoune nouvelle
Gateway est deacuteployeacutee crsquoest de lrsquoenregistrer dans TTN
Enregistrement drsquoune Gateway LoRa TTN gt Console gt Gateway gt register gateway
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Figure 38 Scheacutema de notre application
| 40
Figure 39 Enregistrement dune Gateway LoRa sur TTN
Enregistrement drsquoune application TTN gt Console gt Application gt add application
Figure 40 Enregistrement dune application sur TTN
Enregistrement des Devices LoRa dans lrsquoapplication Nom de lrsquoapplication gt register device
Figure 41 Enregistrement des Devices LoRa dans une application
524 Configuration des Devices LoRa Lorsque nous avons enregistreacute des Devices LoRa dans TTN nous devons choisir entre les deux modes
drsquoauthentification Dans un premier temps nous utiliserons le mode le plus simple qui est ABP Nous
geacuteneacuterons dans TTN les DevAddr NetwkSKey et AppSKey
| 41
Figure 42 Configuration des Devices LoRa en ABP dans TTN
53 Mise en application Nous avons dans notre application 10 Devices LoRa drsquoenregistreacutes aduino0 agrave arduino9 Ils sont tous
configureacutes en ABP Les configurations des 10 Devices (DevAddr NetwkSKey et AppSKey) sont noteacutes
en commentaire dans le code de vous allez reacutecupeacuterer
Reacutecupeacuterer le code Arduino laquo RN2483-Arduino-LORAWANino raquo dans Moodle
Modifier votre configuration (DevAddr NetwkSKey et AppSKey) en fonction de votre
numeacutero de binocircme
Veacuterifier que votre Device LoRa arrive bien agrave transmettre des informations (Uplink) vers la
Gateway puis vers le Network Serveur de TTN (The Things Network)
54 Analyse des trames eacutechangeacutees
541 Utilisation de la base 64 Notre Gateway nous preacutesente le Payload PHY en base64 Lrsquoexplication de la meacutethode de
repreacutesentation en base 64 est fourni au travers drsquoun exemple Le code hexadeacutecimal 0x4869
repreacutesente nos donneacutees binaires que nous souhaitons transmettre en base 64
1 On eacutecrit les donneacutees agrave transmettre en binaire
2 On regroupe les eacuteleacutements binaires par des blocs de 6 bits Le nombre de bloc de 6 bits doit
ecirctre un multiple de 4 (minimum 4 blocs) Srsquoil manque des bits pour constituer un groupe de
6 bits on rajoute des zeacuteros
0x4869 = 0100 1000 0110 1001
| 42
3 Srsquoil manque des blocs pour faire un minimum de 4 blocs des caractegraveres speacuteciaux seront
ajouteacutes
4 Chaque groupe de 6 bits est traduit par le tableau suivant (Source Wikipeacutedia)
Figure 43 Codage en base 64
5 Si un bloc de 6 bits manque (ils doivent ecirctre un multiple de 4) on rajoute un ou plusieurs
compleacutements (caractegravere laquo = raquo )
Reacutesultat Le codage de 0x4869 en base 64 est laquo SGk= raquo
010010 000110 100100
On ajoute 00 pour avoir
6 bits dans le groupe
Bloc de 6 bits
010010 000110 100100
S G k
010010 000110 100100
S G k =
1er Bloc
2egraveme Bloc
3egraveme Bloc
4egraveme Bloc
| 43
542 Inteacuterecirct et inconveacutenient de la base 64 Lrsquoutilisation de la base 64 est un choix qui a eacuteteacute fait pour le protocole LoRa LoRaWAN afin de rendre
les donneacutees binaires lisibles Le problegraveme du code ASCII crsquoest qursquoil est composeacute drsquoun certain nombre
de caractegraveres non imprimables (EOF CR LFhellip) Pour eacuteviter ces soucis la base 64 ne comporte que
64 caractegraveres imprimables (voir tableau ci-dessus)
La restriction agrave 64 caractegraveres a cependant un inconveacutenient crsquoest que nous ne pouvons coder que 6
bits (26=64) au lieu de 8 La base 64 est donc moins efficace drsquoune faccedilon geacuteneacuterale
Nous cherchons agrave coder le code ASCII laquo AA raquo en base 64 Retrouver la deacutemarche en
montrant que le reacutesultat en base 64 est laquo QUE= raquo
543 Uplink Du Device LoRa au Network Server Le Network Server de TTN reccediloit des trames IP en provenance de la Gateway Comme nous lrsquoavons
vu preacuteceacutedemment un certain nombre drsquoinformations peuvent ecirctre retrouveacutees avec cette trame
(DevAddr SF Bandwidth etchellip) mais les donneacutees Applicatives sont bien sucircr chiffreacutees (avec
lrsquoAppkSKey) A ce niveau de reacuteception (sans connaitre lrsquoAppSKey) il nrsquoest donc pas possible de
comprendre la totaliteacute du message reccedilu
Imaginons que la trame IP reccedilue 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 45
timestamp 2019-03-05T140042448Z
rssi -82
snr 9
dev_addr 26011AD3
frequency 867300000
Le Network Server affiche donc les informations de la faccedilon suivante
Figure 44 Trame reacutecupeacutereacutee sur le laquo Network Server raquo de TTN
Nous retrouvons bien les valeurs fournies par la Gateway
timestamp ( agrave 1 heure pregraves en fonction du fuseau horaire)
| 44
frequency 8673 Mhz
modulation Lora
Coding Rate 45
data Rate SF 7 125 kHz (DR5)
air time 463 ms
Drsquoautres information proviennent de lrsquoanalyse du Payload Le Payload inscrit ici est le PHY Payload
Il y a donc une partie chiffreacutee (Frame Payload) mais les entecirctes sont en claires (voir paragraphe
441) Ce PHY Payload est laquo QNMaASYABwAP1obuUHQ= raquo Lorsque celui-ci est exprimeacute en
hexadeacutecimal au lieu de la base 64 il vaut laquo 40D31A01260007000FD686EE5074 raquo comme le montre
le Network Server de TTN
Figure 45 PHY Payload preacutesenteacute dans notre Network Server
Sa taille est bien de 14 octets (en hexadeacutecimal) comme preacuteciseacute sur la Figure 44
Nous reprenons le format de la trame LoRaWAN vu agrave la Figure 32 Nous pouvons alors retrouver
tous les champs de toute la trame
PHYPayload = 40D31A01260007000FD686EE5074
PHYPayload = MAC Header[1 octet] | MACPayload[] | MIC[4 octets]
MAC Header = 40 (Unconfirmed data up)
MACPayload = D31A01260007000FD6
Message Integrity Code = 86EE5074
MACPayload = Frame Header | Frame Port | FramePayload )
Frame Header = D31A0126000700
FPort = 0F
FramePayload = D6
Frame Header = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[015]
DevAddr = 26011AD3 (Big Endian)
FCtrl (Frame Control) = 00 (No ACK No ADR)
FCnt (Frame Counter) = 0007 (Big Endian)
FOpts (Frame Option) =
Vous pouvez veacuterifier lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN
(LoRaWAN packet decoder) httpsbitly2szdXtv
| 45
Figure 46 LoRaWAN packet decoder
544 Uplink Du Network Server agrave lrsquoApplication Server
Nous reprenons lrsquoexemple de la trame ci-dessus (Figure 45) Pour information les cleacutes NwkSKey et
AppSKey suivantes ont eacuteteacute utiliseacutee
NwkSKey E3D90AFBC36AD479552EFEA2CDA937B9
AppSKey F0BC25E9E554B9646F208E1A8E3C7B24
Le Network Server a deacutecodeacute lrsquoensemble de la trame Si le MIC est correct (authentification de la
trame par le NwkSKey) alors le Network Server va passer le contenu du message chiffreacute (Frame
Payload) agrave lrsquoApplication Server Dans notre cas le Frame Payload est (drsquoapregraves le deacutecodage effectueacute
au chapitre preacuteceacutedent)
FramePayload = D6
D6 est le contenu chiffreacute lorsqursquoil est deacutechiffreacute avec lrsquoAppSkey on trouve 01 Vous pouvez veacuterifier
lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN httpsbitly2szdXtv
A noter que lrsquoApplication Server recevra les donneacutees chiffreacutees seulement si le Device LoRa a bien
eacuteteacute enregistreacute On peut aussi veacuterifier ci-dessous que lrsquoApplication Serveur de TTN nous retourne bien
un payload (Frame Payload) de 01
Figure 47 Trame reacutecupeacutereacutee sur lrsquoApplication Server de TTN
time 2019-03-05T140042379279991Z
frequency 8673
modulation LORA
data_rate SF7BW125
coding_rate 45
gateways [
gtw_id eui-b827ebfffeae26f6
timestamp 2447508531
time
channel 4
rssi -82
snr 9
latitude 4563647
longitude 58721523
| 46
location_source registry
]
545 Simulation drsquoUplink dans lrsquoApplication Server
Dans beaucoup de situations nous souhaitons valider le fonctionnement de lrsquoApplication Server de
TTN ouet de notre propre Application Il est donc tregraves utile de pouvoir simuler lrsquoenvoi drsquoune trame
LoRa sur lrsquoApplication Server sans que celle-ci soit reacuteellement eacutemise par un Device LoRa Pour cela
un outil existe dans les Settings de chaque Device enregistreacute dans TTN Nous avons juste besoin de
speacutecifier le Frame Payload en clair en hexadeacutecimal et le numeacutero de Port
Figure 48 Simulation drsquoune trame envoyeacutee par un Device LoRa
546 Downlink De lrsquoApplication Server au Device LoRa La communication LoRa est bidirectionnelle Des donneacutees peuvent ecirctre transmis au Device LoRa
depuis lrsquoApplication Server Depuis TTN un outil existe dans les Settings de chaque Device
enregistreacute Lrsquointerface est repreacutesenteacutee ci-dessous
Figure 49 Transmission de donneacutees de lrsquo laquo Application Server raquo jusqursquoau Device LoRa
Replace scheduling Mode Par deacutefaut le Frame Payload transmis remplacera le Frame
Payload en attente (si il existe) Dans ce mode un seul Frame Payload est planifieacute
First scheduling Mode Le Frame Payload est mis en file drsquoattente en premiegravere position
Last scheduling Mode Le Payload est mis en file drsquoattente en derniegravere position
Une demande de confirmation peut ecirctre demandeacutee au Device LoRa pour qursquoil preacutecise srsquoil a bien reccedilu
les donneacutees Lrsquooption laquo confirmed raquo permet donc de speacutecifier le type de trame dans le MAC Header
(voir paragraphe 443) laquo Confirmed Data Down raquo ou laquo Unconfirmed Data Down raquo dans notre cas
| 47
6 La reacutecupeacuteration des donneacutees sur notre propre Application
Nous utiliserons agrave nouveau le Network Server et Application Server de The Things Network Jusqursquoici
nous nous sommes contenteacute de veacuterifier que les donneacutees de lrsquoutilisateur (Frame Payload) soient bien
arriveacutees agrave destination dans lrsquoApplication Server Il faut maintenant les reacutecupeacuterer avec notre propre
Application qui aura pour rocircle
De stocker et traiter les donneacutees
De les mettre agrave disposition de lrsquoutilisateur (Serveur Web par exemple)
Drsquoenvoyer des commandes de lrsquoutilisateur aux Devices LoRa si besoin (Flux Downlink)
Nous allons voir deux meacutethodes pour communiquer entre notre application et TTN
Le protocole HTTP POST
Le protocole MQTT
61 Reacutecupeacuteration des donneacutees en HTTP POST dans lrsquoApplication
611 Preacutesentation du protocole HTTP
Dans le monde de lrsquointernet le protocole HTTP est tregraves utiliseacute pour le dialogue entre un client et un
serveur web Classiquement le client (un navigateur web par exemple) fait une requecircte HTTP GET
et le serveur lui retourne le contenu de la page web demandeacutee
Dans notre cas la probleacutematique est diffeacuterente car le client doit modifier le contenu du serveur
avec les donneacutees envoyeacutees par le Device LORA La requecircte srsquoappelle HTTP POST Son nom indique
que le client va poster (et on pas reacutecupeacuterer) des donneacutees
Lrsquoutilisateur qui souhaite reacuteceptionner des donneacutees sur son serveur doit donc concevoir un serveur
HTTP capable de traiter des requecirctes HTTP POST [ requecircte noteacutee (1) sur la Figure 51 ] fournies par
TTN Dans cette configuration TTN jouera le rocircle de client et notre application le rocircle de serveur
Devices
LORA Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
HTTP POST
MQTT Internet
Figure 50 Structure globale drsquoun reacuteseau LORAWAN
| 48
Figure 51 Communication bidirectionnelle entre TTN et notre Application
A lrsquoinverse lrsquoutilisateur qui souhaite transmettre des donneacutees agrave destination du Device LoRa
(Downlink) doit ecirctre capable de fournir une requecircte HTTP POST [ requecircte noteacutee (2) sur la Figure 51
] vers TTN Dans cette configuration TTN jouera le rocircle de Serveur et notre application le rocircle de
client
612 Fonctionnement drsquoun client et drsquoun serveur HTTP POST Afin de bien comprendre le fonctionnement des requecirctes HTTP POST nous allons proceacuteder par
eacutetape Le premier test que nous effectuerons sera decorreacuteleacute de TTN Le principe est le suivant
Utilisation drsquoun serveur HTTP disponible sur le web geacuterant les requecirctes HTTP POST [
httpsrbasketsin ] ou [ httpsbeeceptorcom ] par exemple
Utilisation drsquoun client HTTP eacutemettant des requecirctes HTTP POST commande curl sous linux
ou logiciel Postman [ wwwgetpostmancom ] sous windows par exemple
Ce test nous permet de valider le fonctionnement drsquoun serveur HTTP POST et drsquoun client HTTP POST
Une fois que nous serons sucircr de leur fonctionnement nous les utiliserons avec TTN
The Things Network
Application
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 49
Figure 52 Validation dun server HTTP POST et drsquoun client HTTP POST
613 Test du serveur HTTP POST Nous utiliserons un serveur web proposeacute par httpsrbasketsin
Aller sur le site httpsrbasketsin et creacuteer un nouveau laquo Basket raquo Zone ougrave vous pourrez
visualiser les requecirctes qui ont eacuteteacute eacutemises vers votre serveur
A partir de maintenant toutes les requecirctes dirigeacutees vers lrsquoadresse creacuteeacute seront traiteacutees et
srsquoafficheront Dans le menu de configuration il est aussi possible de deacutefinir le contenu de la reacuteponse
qui sera fournie
Deacutefinir un format de reacuteponse pour les requecirctes HTTP POST avec un body personnaliseacute
614 Test du client HTTP POST On peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande (la commande cURL
srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN sous Windows
Commande cURL curl ndashX POST ndashd lsquorsquodonneacutees agrave envoyerrsquorsquo DuServeurHTTP
Logiciel Postman New gt Request gt Creacuteer une requecircte HTTP POST gt Send
Veacuterifier que les requecirctes HTTP POST sont bien reacutecupeacutereacutees sur votre serveur creacutee preacuteceacutedemment
615 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST
Maintenant que nous avons un serveur HTTP (POST) fonctionnel nous allons configurer TTN pour
jouer le rocircle du client et pour qursquoil envoie des requecirctes HTTP POST vers notre Serveur degraves qursquoune
donneacutee drsquoun Device LoRa est disponible Nous geacuterons donc ici le flux Uplink
Requecircte
HTTP POST
Reacuteponse
(contenu parameacutetrable)
Client HTTP (POST)
Server HTTP (POST) [ httpsrbasketsin ]
| 50
Figure 53 Reacutecupeacuteration des donneacutees sur notre Application
Dans TTN nous inteacutegrons un bloc appeleacute laquo HTTP Integration raquo permettant de jouer le rocircle de client
crsquoest-agrave-dire drsquoenvoyer des requecirctes HTTP POST agrave destination de notre nouveau Serveur HTTP
Lrsquointeacutegration se faire agrave partir de TTN gt Console gt Application gt Nom_de_votre_application gt
Integration
Figure 54 Ajout dun client HTTP POST dans TTN
Pour valider le fonctionnement de notre architecture nous pouvons soit
Envoyer une trame depuis un Device LoRa vers TTN
Simuler lrsquoenvoi drsquoune trame drsquoun Device LoRa vers TTN (gracircce agrave lrsquooutil proposeacute par TTN vu
paragraphe 545)
Dans les deux cas voici un exemple de requecircte POST reccedilue sur notre serveur HTTP
app_id test_app_lorawan_sylvainmontagny
dev_id stm32lorawan_1
hardware_serial 0056AF49877
port 1
counter 0
payload_raw qg==
metadata
Requecircte
HTTP POST
Server HTTP (POST) [ httpsrbasketsin ]
The Things Network (Client)
La requecircte contient le Frame Payload deacutechiffreacutee
agrave transmettre agrave lrsquoApplication
| 51
time 2019-01-24T15243703499298Z
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Comme nous pouvons le voir le contenu fourni agrave notre serveur est formateacute en JSON (voir
paragraphe 0) Voici quelques compleacutements drsquoinformation
payload_raw Frame Payload deacutechiffreacute crsquoest donc les donneacutees en clairs dans la base 64
downlink_url URL du serveur HTTP POST qui serviront agrave transmettre des donneacutees au Device
LoRa (flux Downlink)
611 Envoyer des donneacutees depuis notre Application avec HTTP POST
Lorsque nous avons ajouteacute le bloc laquo HTTP Integration raquo au paragraphe preacuteceacutedent nous avons aussi
implicitement activeacute la fonctionnaliteacute que TTN soit precirct agrave recevoir et agrave traiter les requecirctes HTTP
POST La seule information qursquoil nous manque est lrsquoadresse du server HTTP vers lequel il faut eacutemettre
les requecirctes Si on observe la trame reccedilue preacuteceacutedemment en provenance de TTN on srsquoaperccediloit que
dans la trame JSON reccedilu une URL (downlink_url) est speacutecifieacutee
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Crsquoest cette URL que nous devrons utiliser Nous allons nous placer dans la configuration suivante
Figure 55 Envoi de donneacutees agrave partir de notre Application
Comme preacuteceacutedemment on peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande
(la commande cURL srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN
Commande cURL curl ndashX POST ndashdata lsquo dev_id Identidiant_De_Votre_Device
payload_raw AQE= rsquo DuServeurHTTP
Logiciel Postman New gt Request gt HTTP POST puis Body gt Raw gt JSON
Requecircte HTTP POST vers serveur TTN laquo downlink_url raquo httpsintegrationsthethingsnetworUaeb8ypKieQ
Contenu de la requecircte
dev_id Identidiant_De_Votre_Device
payload_raw aGVsbG8=
The Things Network (Serveur)
POSTMAN (Client HTTP POST)
| 52
dev_id YourDeviceID
payload_raw aGVsbG8=
Vous devez envoyer le texte (payload_raw) en base 64 Dans lrsquoexemple ci-dessus laquo aGVsbG8= raquo
correspond agrave la chaine de caractegravere laquo hello raquo Vous pouvez utiliser les nombreux encodeurdecodeur
en ligne pour vous aider Le texte doit srsquoafficher sur votre moniteur seacuterie Arduino dans le cadre de
notre deacutemonstrateur sur Arduino
62 Reacutecupeacuteration des donneacutees avec MQTT dans lrsquoApplication
621 Preacutesentation du protocole MQTT
MQTT est un protocole leacuteger qui permet de srsquoabonner agrave des flux de donneacutees Plutocirct que
lrsquoarchitecture Client Serveur classique qui fonctionne avec des Requecirctes Reacuteponses MQTT est
baseacute sur un modegravele Publisher Subscriber La diffeacuterence est importante car cela eacutevite davoir agrave
demander (Requecircte) des donneacutees dont on na aucune ideacutee du moment ougrave elles vont arriver Une
donneacutee sera donc directement transmise au Subscriber degraves lors que celle-ci a eacuteteacute reccedilue dans le
Broker (serveur central)
Figure 56 Modegravele Publisher Subscriber du protocole MQTT
Pour recevoir les donneacutees appartenant agrave un Topic un Subscriber doit souscrire (comme son nom
lindique) au preacutealable sur ce Topic
MQTT est un protocole qui repose sur TCP Lencapsulation des trames sur le reacuteseau est donc la
suivante
Broker
Client
Publisher 1
Client
Publisher 2
Client
Subscriber
Topic
Tempeacuterature
Topic
Humiditeacute
| 53
Figure 57 Protocoles utiliseacutes pour la communication avec MQTT
On peut le veacuterifier par une capture de trame sur Wireshark
Figure 58 Capture dune trame MQTT avec Wireshark
On peut noter que le port TCP utiliseacute pour le protocole MQTT (non chiffreacute) est le 1883
Les Publishers et les Subscribers nrsquoont pas besoin de se connaitre
Les Publishers et les Subscribers ne sont pas obligeacute de srsquoexeacutecuter en mecircme temps
622 Connexion au Broker MQTT Nous nous inteacuteresserons essentiellement aux options de connexion qui permettront de geacuterer la
Qualiteacute de Service (QoS) Pour se connecter un client MQTT envoie deux informations importantes
au Broker
keepAlive Cest la peacuteriode la plus longue pendant laquelle le client Publisher ou Subscriber pourra
rester silencieux Au-delagrave il sera consideacutereacute comme deacuteconnecteacute
cleanSession Lorsque le Client et le Broker sont momentaneacutement deacuteconnecteacutes (au-delagrave du
keepAlive annonceacute) on peut donc se poser la question de savoir ce quil se passera lorsque le client
sera agrave nouveau connecteacute
Si la connexion eacutetait non persistante (cleanSession = True) alors les messages non transmis
sont perdus Quel que soit le niveau de QoS (Quality of Service)
Si la connexion eacutetait persistante (cleanSession = False) alors les messages non transmis
seront eacuteventuellement reacuteeacutemis en fonction du niveau de QoS Voir le chapitre 624
623 Qualiteacute de Service au cours dune mecircme connexion
A partir du moment ougrave le Client se connecte au Broker il est possible de choisir un niveau de fiabiliteacute
des transactions Le Publisher fiabilise leacutemission de ces messages vers le Broker et le Subscriber
fiabilise la reacuteception des messages en provenance du Broker Une parle ici du cas dune mecircme
connexion crsquoest-agrave-dire entre le moment ou le Client se connecte et le moment ougrave
Soit il se deacuteconnecte explicitement (Close connexion)
Soit il na rien eacutemis ni fait signe de vie pendant le temps keepAlive
TCP
MQTT
Reacuteseau
Transport
Couche Application
IP
| 54
Lors dune mecircme connexion la Qualiteacute de Service (QoS) qui est mise en œuvre deacutepend uniquement
de la valeur du QoS selon les valeurs suivantes
QoS 0 At most once (au plus une fois) Le premier niveau de qualiteacute est sans acquittement Le
Publisher envoie un message une seule fois au Broker et le Broker ne transmet ce message quune
seule fois aux Subscribers Ce meacutecanise ne garantit pas la bonne reacuteception des messages MQTT
QoS 1 At least once (au moins une fois) Le deuxiegraveme niveau de qualiteacute est avec acquittement
Le Publisher envoie un message au Broker et attends sa confirmation De la mecircme faccedilon le Broker
envoie un message agrave ces Subscriber et attends leurs confirmations Ce meacutecanisme garantit la
reacuteception des message MQTT
Cependant si les acquittements nrsquoarrivent pas en temps voulu ou srsquoils se perdent la reacuteeacutemission du
message dorigine peut engendrer une duplication du message Il peut donc ecirctre reccedilu plusieurs fois
QoS 2 Exactly once (exactement une fois) Le troisiegraveme niveau de qualiteacute est garanti une seule
fois Le Publisher envoie un message au Broker et attends sa confirmation Le Publisher donne alors
lrsquoordre de diffuser le message et attends une confirmation Ce meacutecanisme garantit que quel que
soit le nombre de tentatives de reacuteemission le message ne sera deacutelivreacute quune seule fois
La Figure 59 montre les trames eacutemises pour chaque niveau de QoS
Figure 59 Qualiteacute de Service en MQTT
La Figure 60 repreacutesentes les 3 captures de trames sur Wireshark repreacutesentant les 3 QoS (1 2 et 3)
que nous venons dexpliquer
Broker
QoS 0
Au plus une fois
Message supprimeacute apregraves envoi
PUBLISH
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Duplications possibles
PUBLISH
PUBLICH Ack
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Pas de duplication
PUBLISH
PUBLISH Receive
PUBLISH Release
PUBLISH Complete
| 55
Figure 60 Capture de trame avec QoS = 0 puis QoS = 1 puis QoS = 2
624 Qualiteacute de Service apregraves une reconnexion
La question que nous nous posons et de savoir ce que deviennent les messages publieacutes sur le Broker
lorsquun ou plusieurs Subscribers sont momentaneacutement injoignables Il est possible de conserver
les messages qui ont eacuteteacute publieacutes sur le Broker afin de les retransmettre lors de la prochaine
connexion Cette possibiliteacute de sauvegarde doit ecirctre activeacutee agrave louverture de connexion gracircce au flag
cleanSession = 0 La connexion sera alors persistante crsquoest-agrave-dire que le Broker enregistre tous les
messages quil na pas reacuteussi agrave diffuser au Subscriber
Le Tableau 9 reacutesume leffet du flag cleanSession et du QoS
Clean Session Flag Subscriber QoS Publisher QoS Comportement True ( = 1) 0 1 2 0 1 2 Messages perdus
False ( = 0 ) 0 0 1 2 Messages perdus
False (= 0 ) 0 1 2 0 Messages perdus
False (= 0 ) 1 2 1 2 Tous les messages sont retransmis
Tableau 9 Qualiteacute de Service en fonction de la valeur du QoS et du flag cleanSession
625 Les Topics du protocole MQTT Les chaicircnes deacutecrivant un sujet forment une arborescence en utilisant la barre oblique comme
caractegravere de seacuteparation La Figure 61 et le Tableau 10 donne un exemple dorganisation de Topic
Figure 61 Exemple de hieacuterarchie de Topic MQTT
Niveau 3
Niveau 2
Niveau 1 Maison
Chambre
Temperature Humidite Bruit
Salon
Temperature
| 56
Nom du Topic Deacutetail du Topic MaisonChambreTemperature La tempeacuterature de la chambre de la maison
MaisonChambreBruit Le bruit de la chambre de la maison
MaisonSalonTemperature La tempeacuterature du Salon de la maison
Tableau 10 Exemple de Topic
Un client peut sabonner (ou se deacutesabonner) agrave plusieurs branches de larborescence agrave laide de
jokers englobant plusieurs Topics Deux caractegraveres jokers existent
Le signe plus + remplace nimporte quelle chaine de caractegravere sur le niveau ougrave il est placeacute
Le diegravese remplace nimporte quelle chaine de caractegravere sur tous les niveaux suivants Il
est obligatoirement placeacute agrave la fin
Nom du Topic Deacutetail du Topic Maison+Temperature Les tempeacuteratures de toutes les piegraveces de la maison
MaisonChambre La tempeacuterature lhumiditeacute et le bruit de la chambre de la maison
Tableau 11 Exemple de Topic
626 Mise en place drsquoun Broker MQTT Afin de bien comprendre le fonctionnement du protocole de MQTT on reacutealise des tests
indeacutependamment de TTN Nous allons mettre en place
Un Broker Mosquitto httpstestmosquittoorg
Un client Publisher MQTT Box sur Windows
Un client Subscriber MQTT Box sur Windows
Figure 62 Test du protocole MQTT
MQTT Client (Subscriber)
MQTT Client (Publisher)
Publish
Subscribe
BROKER (Mosquitto)
| 57
Le Broker MQTT est commun agrave tout le monde Nous pouvons soit le reacutealiser nous-mecircme soit utiliser
un Broker MQTT public de test Nous utiliserons le Broker de test de Mosquitto disponible sur
httpstestmosquittoorg Drsquoautres sont eacuteventuellement disponibles en cas de problegraveme par
exemple httpwwwmqtt-dashboardcom
Si nous deacutecidions de le reacutealiser nous-mecircme agrave lrsquoaide drsquoune Raspberry Pi (par exemple) Lrsquoinstallation
se ferait en deux lignes de commande
apt-get install mosquito Installation
sudo systemctl start mosquittoservice Lancement du service
Il est neacutecessaire drsquoinstaller mosquitto-clients si on souhaite que le Raspberry PI joue aussi le rocircle de
client ce qui nrsquoest pas notre cas
627 Mise en place drsquoun Publisher et drsquoun Subscriber MQTT Lancer le logiciel MQTTBox
MQTTBox gt Create MQTT Client
Dans ce client les seuls champs indispensables sont
Protocol MQTT TCP
Host testmosquittoorg
Figure 63 Configuration dun Client MQTT dans MQTT Box
Tester lrsquoenvoi et la reacuteception sur les Topics de votre choix
628 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT La reacutecupeacuteration des donneacutees fait reacutefeacuterence au flux Uplink Dans ce cas
TTN joue le rocircle de client Publisher
TTN joue aussi le rocircle de Broker
Notre application joue le rocircle de Subscriber
Nous pouvons donc repreacutesenter lrsquoapplication globale par le scheacutema suivant
| 58
Figure 64 Publisher et Subscriber dans en MQTT avec TTN
La publication est repreacutesenteacutee par la trame MQTT (1)
La souscription est repreacutesenteacutee par la trame MQTT (2)
Le client Publisher eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box mais cette fois avec la configuration suivante
Protocol mqtt tcp
Host Crsquoest lrsquoIP du Broker vers lequel il faut se connecter Dans notre cas il srsquoagit de celui
de TTN dont lrsquoadresse est euthethingsnetwork
Username La connexion vers le broker MQTT est soumis agrave une authentification Username
Password Dans notre cas le Username correspond au nom de notre application crsquoest-agrave-
dire seminaire_lorawan Si vous avez choisi une autre applicationil faut bien mettre la
votre
Password Le Password est nommeacute laquo Access Key raquo par TTN Elle vous sera donneacutee par
lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application vous
trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt Overview
Figure 65 Access Keys de lapplication dans TTN
The Things Network (Application Server)
BROKER
Application
The Things Network (Network Server)
Publish (1 )
[ Flux Uplink ]
Subscribe (2 )
[ Flux Uplink ]
| 59
Figure 66 Configuration du Client dans MQTT Box
Le client MQTT eacutetant configureacute il est maintenant capable de se connecter au Broker Il reste donc agrave
deacutefinir le fait que le client sera Subscriber Les informations que recevra le Subscriber deacutependent du
Topic auquel nous souscrivons Voici les Topic disponibles sur le Broker de TTN
ltAppIDgt correspond au nom de votre Application
ltDevIDgt correspond au nom de votre Device LoRa
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink ltAppIDgtdevicesltDevIDgtup
[Donneacutees] Flux Downlink ltAppIDgtdevicesltDevIDgtdown
[Activation Events] Activation dun Device ltAppIDgtdevicesltDevIDgteventsactivations
[Management Events] Creacuteation dun Device ltAppIDgtdevicesltDevIDgteventscreate
[Management Events] Update dun Device ltAppIDgtdevicesltDevIDgteventsupdate
[Management Events] Suppression dun Device ltAppIDgtdevicesltDevIDgteventsdelete
[Downlink Events ] Message programmeacute ltAppIDgtdevicesltDevIDgteventsdownscheduled
[Downlink Events ] Message envoyeacute ltAppIDgtdevicesltDevIDgteventsdownsent
[Erreurs] Uplink erreurs ltAppIDgtdevicesltDevIDgteventsuperrors
[Erreurs] Downlink erreurs ltAppIDgtdevicesltDevIDgteventsdownerrors
[Erreurs] Activations erreurs ltAppIDgtdevicesltDevIDgteventsactivationserrors
Tableau 12 Topics enregistreacutes dans TTN
Dans un premier temps nous souscrivons au Topic +devices+up Cela signifie que nous
souscrivons agrave tous les Devices LoRa de toutes nos applications pour le flux Uplink
Figure 67 Configuration du Subscriber
Les eacuteleacutements eacutemis par le Broker seront alors afficheacutes dans MQTTBox La
| 60
Figure 68 Trame LoRaWAN reccedilu sur le Subscriber MQTT
Ces donneacutees sont eacutecrites en JSON nous pouvons les remettre en forme
applicationID3
applicationNamemyApplication
deviceNamearduino0
devEUI0056xxxxxxxxx877
txInfo
frequency868500000
dr5
adrfalse
fCnt792
fPort15
dataSGVsbG8=
Le Frame Payload deacutechiffreacute est fourni dans le champ data en base 64 La valeur fournie par
dataSGVsbG8= correspond bien agrave la chaine de caractegravere hello que nous avons eacutemise avec le
Device LoRa
629 Envoyer des donneacutees depuis notre Application avec MQTT
Lrsquoenvoi des donneacutees fait reacutefeacuterence au flux Downlink Dans ce cas
Notre application joue le rocircle de Publisher
TTN joue le rocircle de Broker
TTN joue aussi le rocircle de client Subscriber
| 61
La publication est repreacutesenteacutee par la trame MQTT (3)
La souscription est repreacutesenteacutee par la trame MQTT (4)
Le client Subscriber eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box Le rocircle de client dans MQTT Box a eacuteteacute faite au
paragraphe 628 Il nous reste simplement agrave ajouter le rocircle de Publisher La configuration est la
suivante
Topic du Subscriber seminaire_lorawandevicesarduino0down ougrave seminaire_lorawan
est agrave remplacer par le nom de votre application et arduino0 par le nom du Device LoRa vers
lequel vous souhaitez envoyeacute une donneacutee (Voir chapitre 628 pour comprendre les Topics)
Le Payload doit ecirctre au format JSON Lrsquoexemple suivant envoie laquohello raquo
payload_raw aGVsbG8=
The Things Network (Application Server)
BROKER
Application
Publish (3)
[ Flux Downlink ]
The Things Network (Network Server)
Subscribe (4)
[ Flux Downlink ]
| 62
Figure 69 Configuration du Publisher
Vous devriez voir les donneacutees arriver sur votre Device LoRA
| 63
7 Creacuteation de notre propre Network et Application Server
711 Objectifs Lors de la mise en œuvre du reacuteseau LoRaWAN au chapitre 52 nous avons utiliseacute TTN (The Things
Network) pour jouer le rocircle de Network Server et drsquoApplication Server Pour de multiples raisons
Seacutecuriteacute autonomie coucircthellipil peut ecirctre inteacuteressant de monter soi-mecircme un Network Server et un
Application Server Cela est possible seulement si vous posseacutedez vos propres Gateway puisque
celles-ci devront forwarder leur paquet agrave destination preacutecise Il faudra donc les reconfigurer pour
qursquoelles pointent vers votre nouvelle architecture
712 Preacutesentation de LoRaServer LoRaServer [ wwwloraserverio ] est un projet Open-Source reacutepondant exactement au besoin que
nous avons Nous lrsquoutiliserons sur une cible Raspberry PI En reacutealiteacute il peut souvent ecirctre mise en
place dans le mecircme systegraveme que la Gateway surtout si celle-ci est elle-mecircme agrave base de RPI Les
Gateway EBDS que nous posseacutedons possegravedent drsquoailleurs un Network Server et un Application Server
que nous aurions pu utiliser Neacuteanmoins pour des raisons peacutedagogiques il est inteacuteressant de
seacuteparer les systegravemes pour bien diffeacuterencier les probleacutematiques
Attention il y a une ambiguiumlteacute dans la deacutenomination des entiteacutes logiciels de LoRaServer
LoRaServer (sans espace entre le mot LoRa et Server) est le nom du projet global En
revanche LoRa Server (avec un espace) est le nom du service qui joue le rocircle du Network
Server
Lrsquoarchitecture et le fonctionnement de LoRaServer est preacutesenteacutee dans sa documentation par le
scheacutema suivant
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Raspberry PI
Figure 70 Architecture globale de notre reacuteseau loRaWAN
| 64
Figure 71 Architecture deacutetailleacutee de LoRaServer
On srsquoattends agrave voir uniquement un Network Server (LoRa Server) et un Application Server (LoRa App
Server) mais ce scheacutema est plus complexe Il demande un certain nombre drsquoexplications pour bien
comprendre ce que nous allons installer et la faccedilon dont nous lrsquoutiliserons par la suite
713 Le laquo Packet Forwarder raquo (Gateway) Comme nous lrsquoavons vu au chapitre 412 les Gateways LoRa sont des passerelles entre la
modulation LoRa et un reacuteseau IP Pour reacutealiser cette passerelle un service nommeacute laquo UDP Packet
Forwarder raquo a eacuteteacute deacuteveloppeacute par Semtech httpsgithubcomLora-netpacket_forwarder Dans
ce dossier github un fichier nommeacute PROTOCOLTXT explique parfaitement ce protocole applicatif
qui travaille au-dessus de UDP
Figure 72 Protocole Uplink (PUSH_DATA du Packet Forwarder)
| 65
On remarque que les paquets sont envoyeacutes en UDP au Network Server dans une trame appeleacutee
PUSH_DATA Cette trame est acquitteacutee par le Network Server par une trame appeleacutee PUSH_ACK
Sur notre Network Server nous pouvons reacutealiser une capture de trame pour veacuterifier si le protocole
est bien celui preacutesenteacute dans le document
Figure 73 Trame captureacutee par Wireshark lors dun Uplink
Drsquoapregraves la capture preacuteceacutedente on remarque que le Packet Forwarder fonctionne bien avec UDP sur
le port 1700
Le contenu des donneacutees (champ Data) est deacutetailleacute dans le tableau suivant
Champ | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | random token
[3] | 3 | PUSH_DATA identifier = 0x00
[4] | 4-11 | Gateway unique identifier (MAC address)
[5] | 12-end | JSON object starting with ending with
Lrsquoobjet JSON de la transmission reacuteeacutecrit plus proprement est celui-ci
Figure 74 Analyse du champ Donneacutees du protocole laquo Packet Forwarder raquo
0000 02 f9 30 00 b8 27 eb ff fe ae 26 f5 7b 22 72 78 0amprx 0010 70 6b 22 3a 5b 7b 22 74 6d 73 74 22 3a 33 37 35 pk[tmst375 0020 35 30 30 35 38 31 39 2c 22 63 68 61 6e 22 3a 32 5005819chan2 0030 2c 22 72 66 63 68 22 3a 31 2c 22 66 72 65 71 22 rfch1freq 0040 3a 38 36 38 2e 35 30 30 30 30 30 2c 22 73 74 61 868500000sta 0050 74 22 3a 31 2c 22 6d 6f 64 75 22 3a 22 4c 4f 52 t1moduLOR 0060 41 22 2c 22 64 61 74 72 22 3a 22 53 46 37 42 57 AdatrSF7BW 0070 31 32 35 22 2c 22 63 6f 64 72 22 3a 22 34 2f 35 125codr45 0080 22 2c 22 6c 73 6e 72 22 3a 36 2e 35 2c 22 72 73 lsnr65rs 0090 73 69 22 3a 2d 31 2c 22 73 69 7a 65 22 3a 31 38 si-1size18 00a0 2c 22 64 61 74 61 22 3a 22 51 4e 4d 61 41 53 59 dataQNMaASY 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 ]
Ch
amp
[1
]
Ch
amp
[2
]
Ch
amp
[3
]
Ch
amp
[4
]
| 66
rxpk[ tmst3755005819
chan2
rfch1
freq868500000
stat1
moduLORA
datrSF7BW125
codr45
lsnr65
rssi-1
size18
dataQNMaASYAAQAPpyPZ955+SmY
]
Le champ data correspond au PHY Payload
De la mecircme faccedilon on retrouve la Trame drsquoacquittement
Figure 75 Trame captureacutee par Wireshark lors de lrsquoacquittement drsquoun Uplink
Champs | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | same token as the PUSH_DATA to acknowledge
[3] | 3 | PUSH_ACK identifier = 0x01
Nous retrouvons bien tous ces champs dans la trame Wireshark
714 LoRa Gateway Bridge Nous avons deacutecrit au chapitre preacuteceacutedent (713) le fonctionnement du Packet Forwarder Le
Network Server(Lora Server) que nous allons mettre en place aurait tregraves bien pu srsquointerfacer
directement agrave ce protocole Mais cela aurait plusieurs impacts dont un qui est important dans la
conception de logiciel Si le Packet Forwarder change ou si un autre type de Forwarder est utiliseacute
alors lrsquoutilisation du LoRa Server devient impossible Il a donc eacuteteacute choisi de creacuteer une eacutetape
intermeacutediaire Le Network Server que nous mettrons en plus utilisera le protocole MQTT plutocirct que
le protocole UDP packet Forwarder
En drsquoautres termes le LoRa Gateway Bridge est un service qui fera abstraction du Packet Forwarder
pour srsquointerfacer plus simplement avec le Network Server
715 LoRa Server (Network Server) Il srsquoagit de notre Network Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
413 Cependant il srsquointerfacera au protocole MQTT en recevant les informations agrave partir du
Broker au lieu de recevoir directement les trames en provenance de la Gateway
| 67
716 LoRa App Server (Application Server) Il srsquogit de notre Application Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
414
717 LoRa Geo Server Il srsquoagit drsquoun service qui permet drsquoutiliser certaines proprieacuteteacutes du protocole LoRa pour proposer un
service de geacuteolocalisation des Devices LoRa Nous ne lrsquoutiliserons pas dans notre cas
718 Application Il srsquoagit de notre Application qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre 415
Elle ne fait pas partie du projet LoRaServer crsquoest donc bien toujours agrave nous de proposer notre propre
Application
Figure 76 Les interfaces possibles entre LoRaServer et lrsquoApplication utilisateur
Comme nous pouvons le voir sur la figure preacuteceacutedente deux possibiliteacutes sont offertes pour interfacer
notre application JSON REST (incluant HTTP POST) et via un Broker MQTT Ces deux meacutethodes ont
deacutejagrave eacuteteacute traiteacutee au chapitre 61 (HTTP POST ) et au chapitre 62 (MQTT) Nous verrons aussi drsquoautres
possibiliteacutes pour personnaliser notre application au chapitre 7
72 Installation de LoRaServer
721 Mise en place de lrsquoenvironnement
Nous allons installer une carte SD avec la derniegravere version de Raspbian Nous ne deacutetaillerons pas la
deacutemarche pour cela car elles sont largement documenteacutees et mises agrave jour sur le site
wwwraspberrypiorg
Installer un carte SD avec la derniegravere version de Raspbian
Plutocirct que de fonctionner avec un clavier et une souris nous preacuteconisons de travailler agrave distance
avec la RPI via une connexion SSH Depuis quelques anneacutees Raspbian a supprimeacute le deacutemarrage du
service SSH au boot Heureusement il est possible de le reacuteactiver par la meacutethode suivante
Avec Windows ou Linux ouvrir la partition BOOT de votre carte SD et placer un fichier agrave la
racine nommeacute sshtxt (ou ssh)
Mettre la carte SD dans votre RPI et la deacutemarrer
| 68
Pour acceacuteder agrave la RPI en SSH depuis Windows nous utiliserons de preacutefeacuterence le logiciel
client MobaXterm mais tout autre client SSH est valable
Installer MobaXterm sur votre PC et connectez-vous agrave votre Raspberry PI
Lrsquoutilisation drsquoun espion de reacuteseau type Wireshark peut ecirctre inteacuteressant pour eacutetudier les trames qui
sont reccedilues et qui sont eacutemises Cela nous permettra de valider le fonctionnement des diffeacuterents
protocoles reacuteseau qui permettent de communiquer agrave la Gateway drsquoune part et agrave lrsquoApplication
drsquoautre part Nous utiliserons tshark
apt-get install tshark installation
tshark ndashn -i eth0 Exemple drsquoune analyse sur lrsquointerface wlan0
722 Installation sur la Raspberry PI La meacutethode drsquoinstallation de LoRaServer est documenteacutee sur le site web agrave lrsquoadresse suivante
[ httpswwwloraserverioguidesdebian-ubuntu ] Nous installerons le LoRa Gateway Bridge
le LoRa Server et le LoRa App Server
Apregraves lrsquoinstallation la configuration se fait par une interface graphique accessible par le reacuteseau sur
le port 8080
Si vous travaillez sur la RPI connectez-vous sur httplocalhost8080
Si vous travaillez agrave distance (SSH) connectez-vous sur httpIP_RPI8080
Les Usernames et Password par deacutefaut sont
Username admin
Password admin
Lrsquoeacutecran drsquoaccueil sera donc le suivant
Figure 77 Architecture globale apregraves installation de LoRaServer
Devices
Gateways LoRa
UDP Packet Forwarder
Application Server
LoRa App Server
Internet
Network Server
LoRa Server
LoRa Gateway Bridge
| 69
Figure 78 Ecran daccueil de LoRaServer apregraves authentification
71 Configuration de LoRa Server pour lUplink
711 Enregistrement drsquoune nouvelle Organisation
Pour enregistrer une nouvelle Organizations Organizations gt Create Puis entrer les configurations
suivantes
Figure 79 Enregistrement dun nouvelle Organisation
712 Enregistrement drsquoune instance du Network Server Pour enregistrer une nouvelle instance du Network Server Network Server gt Create Puis entrer
les configurations suivantes
| 70
Figure 80 Enregistrement dun nouveau Network Server
Dans lrsquoonglet Gateway Discovery il est possible drsquoactiver une option de deacutecouverte de Gateway aux
alentours Lorsqursquoelle est configureacutee le Network Server va envoyer une trame Downlink de
configuration de la Gateway lui ordonnant de reacutealiser des PING en LoRa La configuration du
Gateway Discovery preacutevoit de speacutecifier
Le nombre de fois par jour que les PING LoRa sont envoyeacutes
Le canal drsquoeacutemission
Le Data Rate (Voir paragraphe 445)
Un PING LoRa reccedilu sur une Gateway sera retransmis sur le Network Server (Lora Server) et une carte
sera afficheacutee
Lrsquoonglet TLS Certificates ne sera pas utiliseacute dans le cadre de notre deacutemonstration
713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) Il faut tout drsquoabord faire un enregistrement drsquoun laquo service-profile raquo Un laquo service profile permet de
faire la connexion entre le Network Server et les Applications que nous enregistrerons dans notre
Organisation Service-profiles gt Create
Service-profile name myServiceProfile
Network-server myNetworkServer
On laissera par deacutefaut toutes les autres options
Pour enregistrer une nouvelle Application Applications gt Create Puis entrer les configurations
suivantes
| 71
Figure 81 Enregistrement dune nouvelle Application
714 Enregistrement des Devices LoRa Il faut tout drsquoabord faire lrsquoenregistrement drsquoun Device-profile pour les Devices LoRa que vous
souhaitez connecter Dans notre cas nous ferons un premier test en speacutecifiant que nous utilisons
seulement le mode drsquoauthentification ABP (voir chapitre 431) Devices profile gt Create
Figure 82 Enregistrement dun laquo Device profile raquo
Nous pouvons alors creacuteer dans notre Application des nouveaux Devices Application gt
myApplication gt Create
| 72
Figure 83 Enregistrement dun nouveau Device LoRa
Dans la fenecirctre Activation on va alors configurer les 3 eacuteleacutements indispensables agrave une
authentification en APB Le DevAddr le NwkSKey et lrsquoAppSKey
Figure 84 Configuration de lenregistrement du Device LoRa (en ABP)
La configuration minimale de LoRaServer est maintenant termineacutee Nous pouvons donc brancher
un Device LoRa qui possegravede les les attribus (DevAddr NwkSKey et AppSKey) que nous avons
enregistreacute dans LoRaServer et le faire eacutemettre
715 Visualisation des trames reccedilues Les trames eacutemises par le Device LoRa vont donc parcourir le cheminement suivant
| 73
Figure 85 Reacutesumeacute du cheminement des trames LoRaWan en Uplink avec LoRaServer
En allant dans le Live Device Data (Application gt Nom_du_Device gt Live Device Data) on peut voir la
liste des trames reccedilues ainsi que les donneacutees applicatives deacutechiffreacutees
Figure 86 Reacuteception des trames des Devices LoRa
Figure 87 Analyse des trames des Devices LoRa
Dans lrsquoonglet LIVE LORAWAN FRAME nous pouvons voir les trames LORAWAN et si besoin eacutetudier
le contenu de ce qursquoelles contiennent En revanche les donneacutees applicatives sont ici chiffreacutees
UDP
Packet Forwarder
LoRa Bridge
Gateway LoRa Server LoRa App Server
Gateway
Server
Internet
| 74
Figure 88 Reacuteception des Trames LoRaWAN
72 Configuration de LoRaServer pour linteacutegration dApplication Nous avons vu dans le chapitre 718 que linterface entre LoRaServer et notre Application pouvait
ecirctre reacutealiseacutee soit par MQTT soit par les meacutethodes REST (HTTP POST) Nous avons deacutejagrave impleacutementeacute
et expliqueacute ces protocoles dans le cadre de son utilisation avec TTN Nous allons donc juste
configurer LoRaServer pour tester ces deux meacutethodes
721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST Nous utiliserons exactement la mecircme meacutethode que celle que nous avons utiliseacute avec TTN au
chapitre 615 Les diffeacuterentes Clients et Serveurs disponibles pour ces tests sont expliqueacutes au
paragraphe 612
Dans LoRaServer ajouter une inteacutegration HTTP LoRaServer gt Applications gt myApplication gt
Integrations gt Create gt HTTP Integration et la configurer comme le montre la Figure 89 Vous
remplacerez eacutevidement le lien par votre propre Endpoints
Figure 89 Configuration de linteacutegration HTTP POST dans LoRaServer
En envoyant des trames LoRa depuis votre Device vous devriez voir les contenus JSON sur votre
Endpoint
722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT Nous allons nous connecter au Broker MQTT de LoRaServer Pour cela nous utiliserons la mecircme
meacutethode que celle que nous avons utiliseacute avec TTN au chapitre 628 Nous utiliserons MQTTBox
comme nous lavons deacutejagrave fait au paragraphe 627
Le Broker de LoRaServer a enregistreacute les Topics suivant
[applicationID] correspond au nom de votre Application
[devEUI] correspond au nom de votre Device LoRa
| 75
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink application[applicationID]device[devEUI]rx
[Donneacutees] Flux Downlink application[applicationID]device[devEUI]tx
[Status] Statut dun Device application[applicationID]device[devEUI]status
[Ack] Acquittement des messages application[applicationID]device[devEUI]ack
[Erreurs] Erreurs application[applicationID]device[devEUI]error
Tableau 13 Topics enregistreacutes dans LoRaServer
| 76
8 Creacuteation de notre propre Application
81 Utilisation de Node-RED
811 Preacutesentation Node-RED est un outil de programmation graphique qui permet de faire communiquer les
peacuteripheacuteriques mateacuteriels drsquoun systegraveme sans eacutecrire de code De nombreux protocoles sont aussi pris
en charge au travers de bloc ( Node) qursquoil suffit de connecter entre eux pour reacutealiser simplement
une application Il peut srsquoexeacutecuter localement sur un PC ou sur des cibles embarqueacutees telle qursquoune
Raspberry PI (RPI)
Dans les deacutemonstrations que nous mettrons en œuvre nous utiliserons une RPI Par soucis de
simpliciteacute nous utiliserons les derniegraveres versions de Raspbian (systegraveme drsquoexploitation de la RPI) qui
integravegre drsquoorigine Node-RED Il nrsquoy a donc tregraves peu de chose agrave mettre en place pour arriver agrave mettre
en place une Application Nous pouvons travailler soit directement sur la RPI agrave lrsquoaide drsquoune souris-
clavier mais il est recommandeacute de travailler agrave distance avec une connexion SSH
812 Mise en place de lrsquoenvironnement La mise en place de la RPI avec le systegraveme drsquoexploitation Raspbian a eacuteteacute preacutesenteacute au chapitre 721
Vous pouvez reprendre la mecircme installation ou repartir sur une nouvelle
Il est possible de faire en sorte que Node-RED se lance directement au deacutemarrage gracircce agrave la
commande sudo systemctl enable noderedservice
Sil nest pas actif lancer Node-RED sur votre RPI node-red-start
Nous nous connectons au Node-RED de la RPI via un navigateur web sur le port 1880 en tapant dans
la barre dURL httpIP_Raspeberry_PI1880 Ce nous permet darriver agrave la fenecirctre suivante
Figure 90 Page daccueil de Node-RED
Il est possible de sinterfacer avec TTN avec les Nodes deacutejagrave disponibles gracircce au protocole HTTP
POST ou MQTT Neacuteanmoins nous pouvons avantageusement installer deux librairies speacutecifiques
Une qui facilite linterfaccedilage avec TTN
Une qui facilite la mise en place dinterface graphique
Installation des Nodes TTN
cd $HOMEnode-red
npm install node-red-contrib-ttn
Installation de Dashboard (interface graphique)
| 77
cd $HOMEnode-red
npm install node-red-dashboard
Il peut ecirctre necessaire de redeacutemarrer Node-RED pour prendre en compte linstallation de nos deux
Nodes
-----------------------------------
sudo apt-get install npm
sudo npm install -g npm
hash -r
cd ~node-red
npm install node-red-example node name
------------------------------------
813 Creacuteer une Application speacutecifique pour TTN Nous allons commencer par geacuterer le flux Uplink Apporter sur votre scheacutema un Node ttn uplink et
un Node Debug puis relier les Le Node ttn uplink nous permettra de configurer la
communication avec TTN en MQTT Le Node debug eacutecrira sur le terminal les informations brutes
qui seront reccedilu par le Node ttn uplink
Figure 91 Visualisation des trame publieacutees par TTN sur notre client MQTT
Double cliquer sur le Node ttn uplink pour le configurer comme la figure suivante
Le champ Name sera le nom du Node sur votre scheacutema Le champ Device ID est le device LoRa
concerneacute dans votre application De plus il faut entrer les caracteacuteristiques de votre application (Add
new ttn app) pour que Node-RED puisse sy connecter
Figure 92 Configuration du node ttn uplink
Configuration de votre nouvelle application
| 78
Figure 93 Identifiant et mot de passe de notre application
AppID Nom de votre application Dans notre cas seminaire_lorawan
Access Key Comme nous lavons deacutejagrave expliqueacute plus tocirct l Access Key vous sera donneacutee
par lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application
vous trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt
Overview
Le Node ttn uplink doit maintenant avoir le nom que vous avez configureacute Cliquer sur Deploy pour
lancer votre projet Le bloc ttn uplink doit maintenant ecirctre connecteacute agrave TTN Cela est speacutecifieacute
connected sous le bloc
Figure 94 Utilisation du Node TTN Uplink
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
Figure 95 Simulation de Uplink dans TTN
Vous devriez voir le reacutesultat dans la fenecirctre de Debug Par exemple pour le test denvoi de 31 32
correspondant au code ASCII des chiffres 1 et 2 vous devriez avoir la fenecirctre de Debug suivante
| 79
Figure 96 Reacutesultats obtenu dans la fenecirctre Debug apregraves la simulation dUplink
814 Creacuteation drsquoun Dashboard
Dans la mise en place de lenvironnement (chapitre 812) nous avons installeacute des Nodes
Dashboard qui vont nous permettre de reacutealiser une interface graphique tregraves simple et de la mettre
agrave disposition des utilisateurs via un des graphiques histogramme gauges afficheurshellip
Figure 97 Impleacutementation dune interface graphique dans Node RED
Linterface graphique que nous allons creacuteer sera constitueacutee donglet (tab) La mise en place des
composant se fait de la faccedilon suivante
Chaque eacuteleacutement graphique doit appartenir agrave un groupe de composant quil va falloir creacuteer
Chaque groupe de composant doit appartenir agrave un onglet (tab) quil va falloir creacuteer
Figure 98 Creacuteation dun groupe de composant
Figure 99 Creacuteation dun nouvel onglet dans le site web
Cliquer sur Deploy pour activer votre application
LURL pour joindre linterface graphique de votre site web est disponible sur ladresse
httpIP_Raspeberry_PI1880ui
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
| 80
Figure 100 Interface graphique du site web avec Node-RED
82 Programmation en PHP Maintenant que nous avons testeacute toute lrsquoarchitecture nous pouvons mettre en place une
application qui jouera deux rocircles
Un rocircle de Serveur HTTP POST reacutecupeacuterant les donneacutees en provenance de TTN
Un rocircle de Client HTTP POST qui geacuteneacuterera les requecirctes vers TTN
Un serveur web apache sur RPI heacuteberge cette application Linterface graphique du site web est
reacutealiseacute avec le template CSS proposeacute par Bootstrap [ httpsgetbootstrapcom ]
Figure 101 Architecture de notre application en PHP sur RPI
The Things Network
Notre Application
[ Serveur Apache sur Raspberry Pi ]
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 81
Nous allons lrsquoutiliser telle quelle Elle est juste proposeacutee agrave titre dexemple Lrsquoobjectif de cette
application est de geacuteneacuterer une ouverture fermeture de ruche agrave distance dans le cadre de projets
eacutetudiants du Master Electronique et Systegravemes Embarqueacutes de lUSMB [ httpscem-esetuniv-
smbfr ]
Figure 102 Application permettant de recevoir et deacutemettre des requecirctes HTTP POST
Configurer TTN pour pointer vers votre nouveau serveur et tester le flux montant et
descendant
| 82
9 Versions du document
Version 10 02022019
Version initiale
Version 20 23022019
Ajout drsquoun paragraphe Les systegravemes embarqueacutes dans lrsquoIoT En introduction
Compleacutement et ameacutelioration Ameacutelioration exercice eacutetalement de spectre
Correction Cacircblage Arduino
Ajout drsquoun paragraphe Fonctionnement de lrsquoArduino et ajout de librairies
Compleacutement et ameacutelioration Couche physique LoRa Ajout de 4 figures pour lrsquoexplication
de la modulation Chirp
Ajout drsquoun paragraphe sur les acronymes utiliseacutes au deacutebut du cours TTN LoRa MQTThellip
Compleacutement drsquoinformations sur les dB et dBm
Ajout LoRa Calculator
Version 30 8032019
Ajout de figure sur le rocircle de la Gateway LoRa
Ajout de paragraphe authentification avec le Network Server
Ajout de paragraphe sur le chiffrement avec lrsquoApplication Server
Ajout drsquoun sommaire en deacutebut de cours
Ajout de 2 scheacutemas ABP et OTAA
Retrait explication du deacutetail de la laquo Join Request raquo en OTAA Trop complexe attente de
reacutealisation drsquoun scheacutema plus explicite
Ajout drsquoun scheacutema sur lrsquoattaque par REPLAY
Ajout de paragraphe des diffeacuterents reacuteseaux LoRaWAN existants Opeacutereacutes et Priveacutes
Ajout des scheacutemas des trames LoRaWAN Physique LoRa MAC Application
Compleacutement drsquoinformation sur les Classes de Devices
Ajout drsquoun paragraphe sur la Gateway utiliseacutee pour le Downlink
Ajout drsquoun paragraphe sur le JSON
Compleacutement drsquoinformation sur le codage en Base64
Ajout drsquoinformation dans le deacutecodage des trames LoRaWAN
Restructuration des explications sur lrsquoenvoi et la reacutecupeacuteration des donneacutees en HTTPMQTT
Version 40 8032019
Ajout drsquoun chapitre Creacuteation de notre propre Application
Ajout drsquoun chapitre Creacuteation de notre propre Network et Application Server
Ajout drsquoune figure Visualisation des Chirps LoRa par SDR (Radio Logicielle)
Compleacutements drsquoinformation sur MQTT
Compleacutements dinformation sur les Topics de TTN en MQTT
| 13
3 La couche physique LoRa
31 La modulation LoRa Comme nous lrsquoavons expliqueacute plus tocirct la modulation LoRa utilise lrsquoeacutetalement de spectre pour
transmettre ces informations Mais au lieu drsquoutiliser des codes drsquoeacutetalement (CDMA) elle utilise une
meacutethode appeleacutee Chirp Spread Spectrum La finaliteacute est toujours la mecircme Avoir plusieurs
transmissions dans le mecircme canal La conseacutequence sur le spectre est aussi la mecircme cela provoque
un eacutetalement du spectre
311 La forme du symbole (Chirp) Le signal eacutemis par la modulation LoRa est un symbole dont la forme de base est repreacutesenteacutee ci-
dessous Son nom (Chirp) vient du fait que ce symbole est utiliseacute dans la technologie Radar (Chirp
Compressed High Intensity Radar Pulse)
Figure 5 Symbole de la modulation LoRa (source Wikipeacutedia)
La freacutequence de deacutepart est la freacutequence centrale du canal moins la Bande Passante diviseacutee par deux
La freacutequence de fin est la freacutequence centrale plus la Bande Passante diviseacutee par deux
La freacutequence centrale est appeleacutee le canal
La bande passante est la largeur de bande occupeacutee autour du canal
On considegravere une eacutemission sur la freacutequence centrale 868 Mhz avec une Bande Passante
de 125 kHz Donner la freacutequence de deacutebut et la freacutequence de fin du sweep
Freacutequence de deacutebut
Freacutequence de fin
Pour faciliter la repreacutesentation de ce symbole on utilise plutocirct un graphique TempsFreacutequence de
la forme suivante
| 14
Figure 6 Forme du symbole de base (CHIRP)
En LoRa chaque symbole repreacutesente un certain nombre de bits transmis La regravegle est la suivante
Nombre de bits transmis dans un symbole = Spreading Factor
Par exemple si la transmission utilise un Spreading Factor de 10 (SF10) alors un symbole repreacutesente
10 bits
Crsquoest-agrave-dire qursquoagrave lrsquoeacutemission les bits sont regroupeacutes par paquet de SF bits puis chaque paquet est
repreacutesenteacute par un symbole particulier parmi 2119878119865formes de symboles possibles
Sur la figure suivante voici un exemple theacuteorique drsquoune modulation en SF2 agrave 868 Mhz sur une
bande passante de 125 kHz Chaque symbole repreacutesente donc 2 bits
Figure 7 Symboles eacutemis en Modulation LoRa (Cas theacuteorique en SF2)
Exemple
On considegravere la suite binaire suivante 0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Le Spreading Factor utiliseacute est SF10
Nous regroupons donc les bits par paquet de 10 Chaque paquet de 10 bits sera repreacutesenteacute par un
symbole (sweep) particulier Il y a 1024 symboles diffeacuterents pour coder les 1024 combinaisons
binaires possibles (210)
Freacutequence
Temps
868 000 000 Hz
868 062 500 Hz
Un symbole Un symbole
867 937 500 Hz
Temps
868 000 000 Hz
867 937 500 Hz
Symbole 0
Bits laquo 00 raquo
Symbole 1
Bits laquo 01 raquo
Symbole 2
Bits laquo 10 raquo Symbole 3
Bits laquo 11 raquo
12
5 k
Hz
868 062 500 Hz
| 15
Figure 8 Emission des Chirp en LoRa
Avec un outils drsquoanalyse spectrale actif pendant lrsquoeacutemission LoRa drsquoun Device on peut afficher les
successions de symbole qui sont envoyeacutes Cette oscillogramme a eacuteteacute reacutealiseacute agrave lrsquoaide drsquoun SDR
(Software Digital Radio)
Figure 9 Visualisation des Chirps LoRa reacuteellement eacutemis pendant une transmission
312 Dureacutee drsquoeacutemission drsquoun symbole En LoRa la dureacutee drsquoeacutemission de chaque symbole (Chirp) deacutepend du Spreading Factor utiliseacute Plus le
SF est grand et plus le temps drsquoeacutemission sera long Pour une mecircme bande passante le temps
drsquoeacutemission drsquoun symbole en SF8 est deux fois plus long que le temps drsquoeacutemission drsquoun symbole en
SF7 Ainsi de suite jusqursquoagrave SF12
0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Envoi de 1 Chirp Envoi de 1 Chirp Envoi de 1 Chirp
Transmission Transmission Transmission
| 16
Figure 10 Temps drsquoeacutemission drsquoun symbole (Chirp) en fonction du SF
En revanche le temps drsquoeacutemission drsquoun symbole est inversement proportionnel agrave la bande passante
119879119904 =2119878119865
119861119886119899119889119908119894119889119905ℎ Le deacutebit des symboles est donc de
1
119879119878= 119865119904 =
119861119886119899119889119908119894119889119905ℎ
2119878119865 En toute logique plus la
bande passant est eacuteleveacute plus le deacutebit des symboles sera eacuteleveacute Comme chaque symbole comprend
SF bit on retrouve alors le deacutebit binaire
119863119887 = 119878119865119861119886119899119889119908119894119889119905ℎ
2119878119865
Plus le Spreading Factor sera eacuteleveacute plus le deacutebit binaire sera faible
Plus la Bande Passante sera eacuteleveacutee plus le deacutebit binaire sera fort
Exemple Drsquoapregraves la formule du deacutebit binaire trouver le deacutebit pour les deux cas suivants
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
32 Coding Rate Le Coding Rate est un ratio qui augmentera le nombre de bits agrave transmettre afin de reacutealiser de la
deacutetection correction drsquoerreur Dans le cas drsquoun CR = 4 8 il y aura 8 bits transmis reacuteellement agrave
chaque fois que nous souhaitons transmettre 4 bits Dans cette exemple cela provoque une
transmission drsquoun nombre de bit multiplieacute par 2
SF7
Freacutequence
Temps
Freacutequence centrale
Freacutequence haute
Temps drsquoun symbole eacutemit en SF 12
Freacutequence basse
SF8
SF9
SF10
SF11
SF12
Temps drsquoun symbole eacutemit en SF 11
| 17
Figure 11 Influence du Coding Rate sur le nombre de bits ajouteacute
Si on reprend lrsquoexemple preacuteceacutedent avec un CR de 4 5 nous avons une augmentation de 125 du
nombre de bits agrave transmettre Redonner la deacutebit en prenant en compte le CR
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
La documentation du composant RN2483 donne les deacutebits en fonction du Spreading Factor
la Bande Passante et le Coding Rate Veacuterifier la coheacuterence du reacutesultat avec votre calcul
preacuteceacutedent
Figure 12 Deacutebit en fonction des paramegravetres de la transmission LoRa
33 Utilisation du LoRa Calculator Le logiciel laquo LoRa Calculator raquo est un petit exeacutecutable permettant de simuler une transmission LoRa
en fonction des caracteacuteristiques saisies Canal SF CR etchellip Il est teacuteleacutechargeable agrave lrsquoadresse
suivante httpsbitly2TyloAh
| 18
Figure 13 Le logiciel LoRa Calculator
En reprenant lrsquoexemple preacuteceacutedent (SF7 Bande Passante 125 kHz CR 45) veacuterifier les
calculs du laquo Equivalent Bitrate raquo
34 Time On Air La norme LoRaWAN impose qursquoun Device LoRa ne transmette pas plus de 1 du temps Cela est
repreacutesenteacute par un Duty Cycle Par exemple un Duty Cycle de 1 signifie que si jrsquoeacutemet pendant 1 je
ne dois plus eacutemettre pendant 99 quel que soit lrsquouniteacute de temps utiliseacutee
En reprenant les exemples preacuteceacutedents quels sont les deacutebits moyens si on prend en compte
le laquo Time On Air raquo
Cas 1 Pour SF7 et 125 khz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
Dans le logiciel laquo LoRa Calculator raquo (onglet laquo Energy Profile raquo) nous pouvons estimer la
dureacutee de vie drsquoune batterie Nous prenons lrsquoexemple drsquoun releveacute de tempeacuterature dans un
bacirctiment avec les caracteacuteristiques suivantes
| 19
SF CR Bande Passante etc Nous nous placcedilons dans le cas 1 des exemples preacuteceacutedents
Le releveacute de tempeacuterature se fera toutes les 15 mins
La batterie est constitueacute de 3 petites piles bacirctons [ AAA LR03 ] 12V en seacuterie Soit 36 V
1000 mAh
35 Mise en œuvre LoRa en point agrave point Ce test sera reacutealiseacute avec des modules LoRa RN2483 (Microchip) et une carte microcontrocircleur
ARDUINO
Figure 14 Communication LoRa en Point agrave Point
Reacutealiser le cacircblage de votre module RN2483 suivant le tableau suivant
Connecteur Arduino Click Board RN2483
5V 5V
GND GND
11 RX
10 TX
Tableau 4 Cacircblage de lrsquoARDUINO et de la click Board RN2483
351 Utilisation de lrsquoIDE Arduino Lrsquoenvironnement Arduino est tregraves simple Nous allons reacutealiser un programme pour montrer son
fonctionnement
La connexion de la carte est effectueacutee agrave lrsquoaide drsquoun port USB qui eacutemule une liaison seacuterie
RS232 Il faut donc choisir le bon port Arduino IDE gt Outils gt Port
Pour creacuteer un nouveau programme (sketch) Arduino IDE gt Fichier gt Nouveau
Il y a deux parties dans un sketch
Une fonction setup() qui sera exeacutecuteacutee qursquoune seule fois au deacutemarrage
Une fonction loop() qui sera exeacutecuteacutee en boucle
Ecrire le code suivant
Emetteur
Reacutecepteur
UA
RT
UA
RT
| 20
void setup()
Serialbegin(9600)
void loop()
Serialprintln(hello word)
Compiler et Teacuteleacuteverser Croquis gt Teacuteleacuteverser
Voir la sortie sur la liaison seacuterie Outils gt Moniteur Seacuterie gt Choisir la vitesse de
transmission ici 9600 bauds (en bas agrave droite)
352 Validation du fonctionnement Deux binocircmes joueront le rocircle drsquoeacutemetteur tous les autres binocircmes seront en reacutecepteur
Reacutecupeacuterer les programmes dans Moodle dans le dossier laquo RN2483-Arduino-Point2Point raquo
Installer la librairie RN2483 Arduino IDE gt Croquis gt Inclure une bibliothegraveque gt Ajouter la
bibliothegraveque zip
Reacutepartissez les rocircles Emetteurs Reacutecepteurs et reacutecupeacuterer le programme LoraBlinkerRX ou
LoraBlinkerTX en fonction Les 2 binocircmes en eacutemission devront modifier le code du sketch
Arduino pour transmettre des donneacutees speacutecifiques afin de les diffeacuterencier [
loraSerialprintln(radio tx 30) ]
Validez la reacuteception des donneacutees eacutemises par les deux binocircmes qui transmettent des
donneacutees Ces donneacutees reccedilues sont eacutecrite agrave 57600 bauds sur le moniteur seacuterie de lrsquoArduino
353 Mise en valeur du Spreading Factor On srsquoaperccediloit dans la manipulation preacuteceacutedente que les Devices LoRa reccediloivent les donneacutees des deux
eacutemetteurs Nous allons conserver le mecircme canal drsquoeacutemission (8691 Mhz) mais un des deux
eacutemetteurs va modifier son laquo Spreading Factor raquo La salle sera donc seacutepareacutee en deux groupes
1er groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF7
2egraveme groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF8
Validez la reacuteception des donneacutees eacutemises seulement pour le Spreading Factor que vous
utilisez
| 21
4 Le protocole LoRaWAN
Le LoRa est le type de modulation utiliseacute entre deux Devices ou entre un Device et une Gateway
Lorsque nous parlons de lrsquoensemble de la chaine de communication (Device Gateway Serveur) alors
nous parlons de communication LoRaWAN Nous allons voir lrsquoarchitecture drsquoun reacuteseau LoRaWAN
ainsi que les regravegles de ce protocole
41 Structure drsquoun reacuteseau LoRaWAN Nous retrouvons drsquoun cocircteacute le Device LoRa qui transmet une donneacutee Elle est reacuteceptionneacutee agrave lrsquoautre
extreacutemiteacute du reacuteseau par un Utilisateur La structure globale du reacuteseau LoRaWAN peut ecirctre
repreacutesenteacutee par la figure suivante
411 Les Devices LoRa Les Devices LoRa sont des systegravemes eacutelectroniques appartenant au monde de lrsquoIoT Faible
consommation faible taille faible puissance et faible taille
Ils possegravedent une radio LoRa permettant de joindre les Gateways Les Gateways ne sont pas
adresseacutees speacutecifiquement toutes celles preacutesentes dans la zone de couverture reccediloivent les
messages et les traitent
412 Les Gateways LoRa Elles eacutecoutent sur tous les canaux et sur tous les Spreading Factor Lorsqursquoune trame LoRa est reccedilue
elle transmet son contenu sur internet agrave destination du Network Server qui a eacuteteacute configureacute dans la
Gateway au preacutealable
Elle joue donc le rocircle de passerelle entre une modulation LoRa et une communication IP
Devices
LoRa Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
Internet Internet
Figure 15 Structure globale dun reacuteseau LORAWAN
| 22
Chaque Gateway LoRa possegravede un identifiant unique (EUI sur 64 bits)
413 Le Network Server
Le Network Server reccediloit les messages transmis par les Gateways et supprime les doublons
(plusieurs Gateway peuvent avoir reccedilu le mecircme message) Les informations transmises au Network
Server depuis les Devices LoRa sont authentifieacutes gracircce agrave une cleacute AES 128 bits appeleacutee Network
Session Key NwkSKey Nous parlons bien ici drsquoauthentification et non pas de chiffrement comme
nous le verrons plus tard
414 Application Server Il est souvent sur le mecircme support physique que le Network Server Il permet de dissocier les
applications les unes des autres Chaque application enregistre des Devices LoRa qui auront le droit
Devices Gateways Network
Server
Internet
Network Session Key (NwkSKey)
Authentification
Figure 17 Authentification entre le Device LoRa et le Network Server
Internet
UDP IP
Modulation
LoRa
Device LoRa
Gateway
Network Server
LoRaWAN
Modulation
LoRa
Passerelle LoRa Internet
Internet
UDP IP
LoRaWAN
Transmission Radio
Application Application
Figure 16 Le rocircle de la Gateway LoRa
| 23
de stocker leurs donneacutees (Frame Payload) Les message transmis agrave lrsquoapplication server sont chiffreacutes
gracircce agrave une cleacute AES 128 bits appeleacutee Application Session Key AppSKey
Le scheacutema suivant reacutesume lrsquoutilisation
De la Network Session Key (NwkSKey) pour lrsquoauthentification entre le Device LoRa et le
Network Server
De lrsquoApplication Session Key (AppSKey) pour le chiffrement entre le Device LoRa et
lrsquoApplication Server
Devices Gateways Network
Server Application
Server
Internet
Application Session Key (AppSKey)
Chiffrement
Figure 18 Chiffrement entre le Device LORA et lrsquoApplication Server
| 24
415 Application Web Serveur Cette application doit drsquoune part reacutecupeacuterer les donneacutees de lrsquoApplication Serveur Dans le cadre de
ce cours cela sera fait de deux faccedilons
Avec le protocole HTTP
Avec le protocole MQTT
Figure 20 Application Web Server
Figure 19 Authentification et chiffrement en LoRaWan
Devices Gateways
Network
Server Application
Server
Internet
Network Session Key
Application Session Key
Network
Server Application
Server
Application
Server Web
Utilisateur
Protocole
MQTT ou HTTP
Flux Uplink
Flux Downlink
| 25
Le flux habituel dans lrsquoIoT est le flux Uplink (flux montant) crsquoest-agrave-dire lrsquoeacutemission de donneacutees des
objets vers le serveur Comme nous lrsquoexpliquerons plus loin en LoRaWAN il est aussi possible de
transfeacuterer des donneacutees aux Device LoRa par un flux Downlink (flux descendant)
Drsquoautre part lrsquoapplication mettra agrave disposition les donneacutees aux utilisateurs sous forme par exemple
drsquoun serveur web drsquoune base de donneacutees et drsquoune visualisation graphique
416 Authentification avec le Network Server La Network Session Key (NwkSKey) sert agrave lrsquoauthentification entre le Device LoRa e le Network Server
Afin de reacutealiser cette authentification entre le Device et le Network Server un champ MIC (Message
Integrity Control) est rajouteacute agrave la trame Il est calculeacute en fonction des donneacutees transmises et du
NwkSkey A la reacuteception le mecircme calcul est effectueacute Si les cleacutes sont eacutequivalentes dans le Device et
dans le Network Server alors les deux MIC calculeacutes doivent correspondre
417 Chiffrement des donneacutees vers lrsquoApplication Server
LrsquoApplication Session Key (AppSKey) sert pour le chiffrement entre le Device LoRa et lrsquoApplication
Server Les donneacutees chiffreacutees seront alors deacutecodeacutees agrave la reacuteception sur lrsquoApplication Server srsquoil
possegravede la mecircme cleacute Si on reprend le scheacutema preacuteceacutedent les laquo donneacutees x raquo sont chiffreacutees
deacutechiffreacutees par le processus suivant
Donneacutees x chiffreacutees NwkSkey x
MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees
NwkSkey x
Trame eacutemise Trame reccedilue
Device LoRa Network Server
Si =
Alors la trame est authentifieacutee
MIC geacuteneacutereacute Emission MIC geacuteneacutereacute Reacuteception
MIC geacuteneacutereacute Reacuteception
Figure 21 Authentification dun Device LoRa par le Network Server
| 26
Figure 22 Chiffrement des donneacutees par lApplication Session Key
418 Combinaison de lrsquoauthentification et du chiffrement On peut maintenant repreacutesenter sur le mecircme scheacutema la construction de la trame LoRaWAN avec
drsquoune part lrsquoauthentification et drsquoautre part le chiffrement
Figure 23 Chiffrement puis Authentification
42 Classes des Devices LoRaWAN Les Devices LoRa sont classeacutes en 3 cateacutegories (A B C) en fonction de leur consommation et de leur
accessibiliteacute en Downlink crsquoest-agrave-dire la faciliteacute qursquoun utilisateur aura agrave transmettre une trame au
Device LoRa
421 Classe A (All) Minimal power Application Tous les Devices LoRaWAN sont de classe A Chaque Device peut transmettre (Uplink) agrave la Gateway
sans veacuterification de la disponibiliteacute du reacutecepteur Si la transmission eacutechoue elle sera reacuteeacutemise apregraves
un certain temps Cette transmission est suivie de 2 fenecirctres de reacuteception tregraves courtes La Gateway
peut alors transmettre pendant le laquo RX Slot 1 raquo ou le laquo RX Slot 2 raquo mais pas les deux
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Device LoRa
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Application Server
Donneacutees non chiffreacutees
AppSKey
Donneacutees chiffreacutees Entecircte
NwkSKey
MIC geacuteneacutereacute en eacutemission Trame transmise =
| 27
Figure 24 Slots de reacuteception pour un Device LoRa de classe A
Source de lrsquoimage httpszakelijkforumkpncom
La dureacutee des fenecirctres doit ecirctre au minimum la dureacutee de reacuteception drsquoun preacuteambule Un preacuteambule
dure 1225 Tsymbole et deacutepend donc du Data Rate (DR voir paragraphe 445 pour plus drsquoinformation
sur le DR) Lorsque qursquoun preacuteambule est deacutetecteacute le reacutecepteur doit rester actif jusqursquoagrave la fin de la
transmission Si la trame reccedilue pendant la premiegravere fenecirctre de reacuteception eacutetait bien agrave destination du
Device LoRa alors la deuxiegraveme fenecirctre nrsquoest pas ouverte
Premiegravere fenecirctre de reacuteception
Le Slot RX1 est programmeacute par deacutefaut agrave 1 seconde + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont les mecircme que ceux choisis lors de la phase drsquoeacutemission
(Uplink)
Seconde fenecirctre de reacuteception
Le Slot RX2 est programmeacute par deacutefaut agrave 2 secondes + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont configurables mais fixes
Un Device LoRa qui est uniquement de classe A ne peut pas recevoir srsquoil nrsquoa pas eacutemis Il
nrsquoest donc pas joignable facilement
422 Classe B (Beacon) Scheduled Receive Slot Les Devices de classe B ont le mecircme comportement que les Devices de classe A mais drsquoautres
fenecirctres de reacuteceptions sont programmeacutees agrave des peacuteriodes preacutecises Afin de synchroniser les fenecirctres
de reacuteception du Device LoRa la Gateway doit transmettre des balises (Beacons) de faccedilon reacuteguliegravere
| 28
Figure 25 Slots de reacuteception pour un Device LoRa de classe B
Source de lrsquoimage httpszakelijkforumkpncom
Un Device LoRa de classe B est joignable reacuteguliegraverement sans qursquoil soit neacutecessairement
obligeacute drsquoeacutemettre En revanche il consomme plus qursquoun Device de classe A
423 Classe C (Continuous) Continuously Listening Les Devices de classe C ont des fenecirctres de reacuteception constamment ouvertes entre 2 Uplinks Ces
Devices consomment donc beaucoup plus
Figure 26 Slots de reacuteception pour un Device LoRa de classe C
Source de lrsquoimage httpszakelijkforumkpncom
| 29
Un Device LoRa de classe C est joignable en permanence En revanche crsquoest la classe de
Device qui est la plus eacutenergivore
424 Quelle Gateway pour les flux Downlink
Nous avons donc vu que le fonctionnement classique du protocole LoRaWAN eacutetait de reacutecupeacuterer de
lrsquoinformation depuis le Device LoRa Crsquoest le flux Uplink
Dans le cas ougrave lrsquoutilisateur transmet des informations au Device LoRa (flux Downlink) on peut se
demander quelle Gateway sera choisie pour transfeacuterer les donneacutees au Device LoRa En effet
lrsquoendroit ougrave est situeacute le Device LoRa nrsquoest pas neacutecessairement connu agrave lrsquoavance
La Gateway utiliseacutee pour le Downlink est celle qui a reccedilu le dernier message du Device
LoRa Un message ne pourra jamais arriver agrave destination drsquoun Device LoRa si celui-ci nrsquoa
jamais transmis quel que soit sa classe A B ou C
43 Activation des Devices LoRa et seacutecuriteacute En LoRaWAN les trois eacuteleacutements indispensables pour la communication sont le DevAddr pour
lrsquoindentification du Device ainsi que deux cleacutes le NwkSKey pour lrsquoauthentification et lrsquoAppSKey
pour le chiffrement Deux meacutethodes sont possibles pour fournir ces informations agrave la fois au Device
LoRa et au serveur
Activation By Personalization APB
Over The Air Activation
431 ABP Activation By Personalization Crsquoest la plus simple des meacutethodes Crsquoest donc peut ecirctre celle que nous avons tendance agrave utiliser lors
drsquoun test de prototype et drsquoune mise en place de communication LoRaWAN
Le Device LoRa possegravede deacutejagrave le DevAddr lrsquoAppSKey et le NwkSKey
Le Network server possegravede deacutejagrave le DevAddr et le NwkSKey
Lrsquoapplication serveur possegravede deacutejagrave le DevAddr et le AppSKey
En ABP toutes les informations neacutecessaires agrave la communication sont deacutejagrave connues par le
Device LoRa et par le Serveur
| 30
432 OTAA Over The Air Activation Crsquoest la meacutethode qursquoil faut privileacutegier car crsquoest celle qui est la plus seacutecuriseacutee Le Device LoRa doit
connaitre le DevEUI lrsquoAppEUI et lrsquoAppkey Le Network Server doit lui connaitre la mecircme Appkey
Tous les eacuteleacutements noteacutes EUI (Extended Unique Identifier) sont toujours sur une taille de
64 bits
Gracircce agrave ces informations de deacutepart et une neacutegociation avec le Network Server (Join Request) le
Device LoRa et le serveur vont geacuteneacuterer les informations essentielles DevAddr NwkSKey et
AppSKey
Figure 28 Obtention du DevAddr NwkSKey et AppSKey en OTAA
DevEUI Unique Identifier pour le device LoRa (Equivalent agrave une MAC sur Ethernet)
Certains Device LoRa ont deacutejagrave un DevEUI fourni en usine
AppEUI Unique Identifier pour lrsquoapplication server
DevEUI
AppEUI
AppKey
Join
Request
DevAddr
NwkSKey
AppSKey
Network Server
Application Server
Devices 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 2
NwkSkey 2
AppSKey 2
Devices 2
DevAddr 2
NwkSkey 2
AppSKey 2
Paramegravetres stockeacutes sur le serveur
Paramegravetres programmeacutes
dans le composant
Figure 27 Parameacutetrage de DevAddr NwkSKey et AppSKey
| 31
AppKey AES 128 cleacute utiliseacutee pour geacuteneacuterer le MIC (Message Code Integrity) lors de la Join
Resquest Il est partageacute avec le Network server
NwkSKey Utiliseacute pour lrsquoauthentification avec le Network Server
AppSKey Utiliseacute pour le chiffrement des donneacutees
433 Seacutecuriteacute Les cleacutes AES 128 bits permettent le chiffrement des informations transmises en LoRaWAN Malgreacute
ce chiffrement une attaque connue en Wireless est celle du REPLAY Crsquoest-agrave-dire que le Hacker
enregistre des trames chiffreacutees circulant sur le reacuteseau LoRa pour les reacuteeacutemettre plus tard Mecircme si
le Hacker ne comprend pas le contenu (les trames sont chiffreacutees) les donneacutees qui sont transporteacutees
sont elles bien comprises par lrsquoApplication Server Des actions peuvent donc ecirctre reacutealiseacutees
simplement par mimeacutetisme
Pour eacuteviter cela la trame LoRaWAN integravegre un champ variable appeleacute laquo Frame Counter raquo Il srsquoagit
drsquoun nombre numeacuterotant la trame sur 16 ou 32 bits LrsquoApplication Server acceptera une trame
uniquement si le laquo Frame Counter raquo reccedilu est supeacuterieur au laquoFrame Counter raquo preacuteceacutedemment Donc
si le Hacker retransmet la trame telle qursquoelle le laquo Frame Counter raquo sera eacutequivalent donc la trame
sera refuseacutee Et comme la trame est chiffreacutee le Hacker nrsquoa pas moyen de savoir comment modifier
un champ de cette trame
Cette seacutecuriteacute impleacutementeacutee par les laquo Frame Counter raquo est inteacuteressante pour srsquoaffranchir drsquoune
attaque par REPLAY mais dans nos tests cela peut poser problegraveme En effet agrave chaque fois que nous
redeacutemarrons le microcontrocircleur notre laquo Frame Counter raquo revient agrave zeacutero alors que celui de
lrsquoApplication Server continue de srsquoincreacutementer Cela peut ecirctre reacutesolue par diffeacuterentes maniegraveres
1 Deacutesactivation du laquo Frame Counter Check raquo Dans certain Application Server cette option
peut ecirctre proposeacutee Bien sucircr il faudra garder en tecircte la faille de seacutecuriteacute que cela engendre
Network Server
Application Server
Devices LoRa
NwkSkey
AppSKey
NwkSkey
AppSKey Hacker
(1) (2)
(1) Ecoute
(2) Reacuteeacutemission
Figure 29 Attaque par REPLAY
| 32
Figure 30 Deacutesactivation du Frame Counter Check dans TTN
2 Utiliser lrsquoauthentification par OTAA au lieu de ABP En effet agrave chaque ouverture de session
en OTAA le laquo Frame Counter raquo est reacuteinitialiseacute coteacute serveur
3 Conserver la valeur du laquo Frame Counter raquo dans une meacutemoire non volatile et reacutecupeacuterer sa
valeur au deacutemarrage du Device LoRa
44 La Trame LoRa LoRaWAN
441 Les couches du protocole LoRaWAN
Lorsque nous avons fait une communication en Point agrave Point nous avons simplement utiliseacute la
couche physique de la modulation LoRa Lorsque nous souhaitons utiliser le protocole LoRaWAN
des couches protocolaires suppleacutementaires se rajoutent
Figure 31 Les couches protocolaires du LoRaWAN
Chaque couche rajoute un service Lors de lrsquoenvoi de la trame les donneacutees utilisateurs sont donc
encapsuleacutees dans chaque couche infeacuterieure jusqursquoagrave la transmission Le deacutetail de lrsquoensemble de la
trame LoRaWAN par couche est deacutecrit sur la figure Figure 32
LoRa Modulation
LoRa Mac
Application
Couche Physique
Couche Mac
Couche Application
| 33
442 Couche Application La couche Application accueille les donneacutees de lrsquoutilisateur Avant de les encapsuler elles sont
chiffreacutees avec lrsquoAppSKey afin de seacutecuriser la transaction
Un ensemble de champs nommeacute Frame Header permet de speacutecifier le DevAddr le Frame Control
le Frame Counter et le Frame Option
Le Frame Port deacutepend du type drsquoapplication et sera choisi par lrsquoutilisateur
Le Frame Payload sont les donneacutees chiffreacutees agrave transmettre Le nombre drsquooctets maximum pouvant
ecirctre transmis (N octets) est donneacute dans le tableau suivant
PHY Payload
P octets Couche
Physique
Couche
Mac
Couche
Application
CRC
2 octets Header + Header CRC
20 bits Preamble
MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Figure 32 Trame LORAWAN complegravete par couche protocolaire
Couche
Application Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Frame Header
Figure 33 Trame LORA couche Applicative
| 34
Data Rate Spreading Factor Bandwidth Max Frame Payload (Nombre N) DR 0 SF12 125 KHz 51 octets
DR 1 SF11 125 KHz 51 octets
DR 2 SF10 125 KHz 51 octets
DR 3 SF9 125 KHz 115 octets
DR 4 SF8 125 KHz 222 octets
DR 5 SF7 125 KHz 222 octets
DR 6 SF7 250 KHz 222 octets
Tableau 5 Taille maximum du Frame Payload en fonction du Data Rate
443 Couche LoRa MAC Cette trame est destineacutee au Network Server Elle est authentifieacutee gracircce au champ MIC (Message
Integrity Protocol) selon la meacutethode expliqueacutee au paragraphe 416
Le protocole LoRa MAC est composeacute de
1 MAC Header Version de protocole et type de message
Type de Message Description 000 Join-Request
001 Join-Accept
010 Unconfirmed Data Up
011 Unconfirmed Data Down
100 Confirmed Data Up
101 Confirmed Data Down
110 Rejoin-request
111 Proprietary
Tableau 6 Les types de messages transmis en LoRaWAN
2 MAC Payload Contient tout le protocole applicatif
3 MIC Message Integrity Code pour lrsquoauthentification de la trame
444 Couche physique Modulation LoRa
Le choix du moment drsquoeacutemission des Devices LoRa se fait de faccedilon simple Lorsqursquoun eacutequipement
doit eacutemettre il le fait sans controcircle et ne cherche pas agrave savoir si le canal est libre Si le paquet a eacuteteacute
perdu il le retransmettra simplement au bout drsquoun temps aleacuteatoire La couche physique est
repreacutesenteacutee par lrsquoeacutemission de la trame suivante
Couche
Mac MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Figure 34 Trame LORA couche LORA MAC
| 35
Le Preacuteambule est repreacutesenteacute par 8 symboles + 425 Le temps du Preacuteambule est donc de 1225
Tsymbole
Len-tecircte (Header optionnel) est seulement preacutesent dans le mode de transmission par deacutefaut
(explicite) il est transmis avec un Coding Rate de 48 Il indique la taille des donneacutees le Coding Rate
pour le reste de la trame et il preacutecise eacutegalement si un CRC sera preacutesent en fin de trame
Le PHY Payload contient toutes les informations de la Couche LoRa MAC
Le CRC sert agrave la deacutetection drsquoerreur de la trame LoRa
445 Canaux et bandes de freacutequences et Data Rate (DR) Le LoRa utilise des bandes de freacutequences diffeacuterentes suivant les reacutegions du monde En Europe la
bande utiliseacutee est celle des 868 Mhz [ De 863 Mhz agrave 870 Mhz ] Le LoRaWAN deacutefinie les 8 canaux agrave
utiliser pour communiquer avec une Gateway suivant le tableau suivant
Canaux Spreading Factor Bandwidth 8681 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz SF7 250 kHz
8685 Mhz De SF7 agrave SF12 125 kHz
8671 Mhz De SF7 agrave SF12 125 kHz
8673 Mhz De SF7 agrave SF12 125 kHz
8675 Mhz De SF7 agrave SF12 125 kHz
8677 Mhz De SF7 agrave SF12 125 kHz
8679 Mhz De SF7 agrave SF12 125 kHz
Tableau 7 Canaux SF et Bandwidth de notre Gateway LoRaWAN
Une Gateway LoRa eacutecoute donc sur 8 canaux simultaneacutement avec les 6 Spreading Factor
diffeacuterents soit 48 combinaisons possibles
Comme nous lrsquoavons vu le Spreading Factor a des conseacutequences sur le deacutebit de la transmission Ces
deacutebits sont noteacutes DR (Data Rate) et sont normaliseacutes de DR0 agrave DR6
PHY Payload
P octets Couche
Physique CRC
2 octets Header + Header CRC
( Optionnel ) 20 bits Preamble
Figure 35 Trame LORA couche Physique
| 36
Data Rate Spreading Factor Bandwidth DR 0 SF12 125 KHz
DR 1 SF11 125 KHz
DR 2 SF10 125 KHz
DR 3 SF9 125 KHz
DR 4 SF8 125 KHz
DR 5 SF7 125 KHz
DR 6 SF7 250 KHz
Tableau 8 Deacutenomination DR en fonction du SF et de la Bande Passante
446 Trame reccedilue et transmise par la Gateway LoRaWAN La Gateway reccediloit drsquoun cocircteacute un message radio moduleacute en LoRa et transmet de lrsquoautre cocircteacute une trame
IP agrave destination du Network Server
Coteacute interface Radio La Gateway reacuteceptionne une trame LoRaWAN et extrait le PHY Payload Celui-
ci est codeacute au format ASCII en base 64 (voir le paragraphe 541) La Gateway extrait aussi toutes les
informations utiles sur les caracteacuteristiques de la reacuteception qui a eu lieu SF Bandwidth RSSI Time
On Airhellipetchellip
Coteacute interface reacuteseau IP La Gateway transmet lrsquoensemble de ces informations dans un paquet IP
(UDP) au Network Server Les donneacutees transmises sont du texte en format JSON (voir paragraphe
447) La Gateway a donc bien un rocircle de passerelle entre le protocole LoRa drsquoun cocircteacute et un reacuteseau
IP de lrsquoautre
Internet
UDP IP
Device LoRa
Gateway
Network Server Modulation
LoRa
Passerelle LoRa Internet
Transmission Radio Internet
Figure 36 Rocircle de la Gateway LoRa
| 37
447 Le format JSON Le format JSON est un format texte composeacute drsquoune succession de couple nomvaleur Dans
lrsquoexemple de la figure preacuteceacutedente gw_id est un nom et eui-b827ebfffeae26f5 est la valeur
associeacutee Dans cette exemple la valeur est un string Les objets sont deacutelimiteacutes par un des accolades
et
Une valeur peut ecirctre
Un string exemple coding_rate 45
Un nombre exemple spreading_factor 12
Un objet exemple lora spreading_factor 12 air_time 2465792000
Un Boolean
Ethernet
Gateway
Modulation
LORA
Reacutecupeacuteration du PHY PAYLOAD en base 64
Reacutecupeacuteration des caracteacuteristiques de la transmission Canal SF CR hellip
IP (IP dest routereuthethingsnetwork)
UDP (Port dest 1700 Port source 1700)
Donneacutees applicatives (format JSON)
gw_id eui-b827ebfffeae26f5
payload QNAPvA6Ax3ECqHk4C8hfzuA==
lora
spreading_factor 12
bandwidth 125
air_time 2465792000
coding_rate 45
timestamp 2019-01-20T133746017Z
rssi -105
snr -162
dev_addr 0EBC0FD0
frequency 867100000
Internet Transmission Radio LORA
Figure 37 Passerelle (Gateway) LORAWAN
| 38
5 Mise en œuvre drsquoun reacuteseau LoRaWAN
51 Les diffeacuterents types de reacuteseaux Les reacuteseaux LoRaWAN peuvent ecirctre utiliseacute suivant deux meacutethodes
En utilisant les reacuteseaux LoRaWAN opeacutereacutes proposeacutes par les opeacuterateurs de teacuteleacutecoms
En utilisant votre propre reacuteseau LoRaWAN priveacute
511 Les reacuteseaux LoRaWAN opeacutereacutes Ce sont des reacuteseaux LoRaWAN proposeacutes par les opeacuterateurs Par exemple Objenious (filiale de
Bouyges) ou encore Orange Dans le cas de lrsquoutilisation des reacuteseaux opeacutereacutes lrsquoutilisateur a juste
besoin de srsquooccuper des Devices LoRa Les Gateways le Network Server et lrsquoApplication Server sont
geacutereacutes par lrsquoopeacuterateur
512 Les reacuteseaux LoRaWAN priveacutes Chacun est libre de reacutealiser son propre reacuteseau priveacute en impleacutementant sa propre Gateway pour
communiquer avec ses Devices LoRa Lrsquoimpleacutementation du Network Server et de lrsquoApplication Server
peuvent alors ecirctre envisageacutes de diffeacuterentes faccedilons
Network Server et Application serveur priveacutees Crsquoest le deacuteveloppeur qui les mets en place Dans
certaines Gateways une impleacutementation de ces deux serveurs est deacutejagrave proposeacutee Sinon il est
possible de la mettre en place Il existe des serveurs (Network et Application) open source crsquoest le
cas par exemple de LoRa Serveur [ wwwloraserverio ]
Une autre alternantive est httpsgithubcomgotthardplorawan-server
LoRaServer et lorawan-server sont deux applications Open Source
Network Server et Application Server en ligne Un certain nombre de Network Server et
drsquoApplication Server sont proposeacutes Ce sont des services payants ou avec des contreparties
Loriot [ wwwloriotio ]
ResIoT [ wwwresiotio ]
The Things Network [ wwwthethingsnetworkorg ] Crsquoest la solution que nous utiliserons
513 Les zones de couvertures
Les zones de couvertures des reacuteseaux opeacutereacutes sont mise agrave jour par les opeacuterateurs celle drsquoobjenious
est par exemple disponible ici httpsobjeniouscomreseau
Pour connaitre la zone de couverture de notre Gateway utiliseacutee avec TTN nous pouvons utiliser
lrsquoapplication TTN Mapper httpsttnmapperorg Lrsquoideacutee est de promener son Device LoRa associeacute
agrave un GPS dans la zone de couverture des Gateway qui nous entourent A chaque trame reccedilue par le
| 39
Serveur on note les coordonneacutees GPS du Device LoRa ainsi que la Gateway qui a transmis le
message Toutes ces informations sont alors retranscrites sur une carte
52 The Things Network (TTN)
521 Preacutesentation de TTN
Pour la suite nous utiliserons le Network Server et lrsquoApplication Server fourni par TTN
[wwwthethingsnetworkorg]
TTN est gratuit et Open Source En revanche le fait drsquoutiliser TTN impose agrave ceux qui enregistrent
des Gateways de les mettre agrave disposition agrave tous les autres utilisateurs de TTN Lrsquoobjectif est de
reacutealiser un reacuteseau global ouvert
522 Configuration de la Gateway A lrsquouniversiteacute nous avons deux Gateways LoRa (Marque EBDS) Elles sont toutes les deux situeacutees sur
le Campus de Technolac Une Gateway est agrave lrsquointeacuterieur du bacirctiment ISERAN et sert essentiellement
pour les Travaux Pratiques et formations Lrsquoautre est sur le toit du bacirctiment Chablais et est mise agrave
disposition du public via le service de TTN
Les deux Gateway eacutecoutent sur tous les canaux et sur tous les Spreading Factor SF7 gt SF12
Lrsquo IP de la Gateway LoRa agrave lrsquouniversiteacute (bacirctiment ISERAN) est 192168140196
Serveur DNS 1934812032 19348129137
Network Server (TTN) 137616868 routereuthethingsnetwork
Port Upstream 1700 Port Downstream 1700
523 Enregistrement des Gateways Appplication et Devices La configuration de TTN se fait en ligne La premiegravere opeacuteration agrave reacutealiser lorsqursquoune nouvelle
Gateway est deacuteployeacutee crsquoest de lrsquoenregistrer dans TTN
Enregistrement drsquoune Gateway LoRa TTN gt Console gt Gateway gt register gateway
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Figure 38 Scheacutema de notre application
| 40
Figure 39 Enregistrement dune Gateway LoRa sur TTN
Enregistrement drsquoune application TTN gt Console gt Application gt add application
Figure 40 Enregistrement dune application sur TTN
Enregistrement des Devices LoRa dans lrsquoapplication Nom de lrsquoapplication gt register device
Figure 41 Enregistrement des Devices LoRa dans une application
524 Configuration des Devices LoRa Lorsque nous avons enregistreacute des Devices LoRa dans TTN nous devons choisir entre les deux modes
drsquoauthentification Dans un premier temps nous utiliserons le mode le plus simple qui est ABP Nous
geacuteneacuterons dans TTN les DevAddr NetwkSKey et AppSKey
| 41
Figure 42 Configuration des Devices LoRa en ABP dans TTN
53 Mise en application Nous avons dans notre application 10 Devices LoRa drsquoenregistreacutes aduino0 agrave arduino9 Ils sont tous
configureacutes en ABP Les configurations des 10 Devices (DevAddr NetwkSKey et AppSKey) sont noteacutes
en commentaire dans le code de vous allez reacutecupeacuterer
Reacutecupeacuterer le code Arduino laquo RN2483-Arduino-LORAWANino raquo dans Moodle
Modifier votre configuration (DevAddr NetwkSKey et AppSKey) en fonction de votre
numeacutero de binocircme
Veacuterifier que votre Device LoRa arrive bien agrave transmettre des informations (Uplink) vers la
Gateway puis vers le Network Serveur de TTN (The Things Network)
54 Analyse des trames eacutechangeacutees
541 Utilisation de la base 64 Notre Gateway nous preacutesente le Payload PHY en base64 Lrsquoexplication de la meacutethode de
repreacutesentation en base 64 est fourni au travers drsquoun exemple Le code hexadeacutecimal 0x4869
repreacutesente nos donneacutees binaires que nous souhaitons transmettre en base 64
1 On eacutecrit les donneacutees agrave transmettre en binaire
2 On regroupe les eacuteleacutements binaires par des blocs de 6 bits Le nombre de bloc de 6 bits doit
ecirctre un multiple de 4 (minimum 4 blocs) Srsquoil manque des bits pour constituer un groupe de
6 bits on rajoute des zeacuteros
0x4869 = 0100 1000 0110 1001
| 42
3 Srsquoil manque des blocs pour faire un minimum de 4 blocs des caractegraveres speacuteciaux seront
ajouteacutes
4 Chaque groupe de 6 bits est traduit par le tableau suivant (Source Wikipeacutedia)
Figure 43 Codage en base 64
5 Si un bloc de 6 bits manque (ils doivent ecirctre un multiple de 4) on rajoute un ou plusieurs
compleacutements (caractegravere laquo = raquo )
Reacutesultat Le codage de 0x4869 en base 64 est laquo SGk= raquo
010010 000110 100100
On ajoute 00 pour avoir
6 bits dans le groupe
Bloc de 6 bits
010010 000110 100100
S G k
010010 000110 100100
S G k =
1er Bloc
2egraveme Bloc
3egraveme Bloc
4egraveme Bloc
| 43
542 Inteacuterecirct et inconveacutenient de la base 64 Lrsquoutilisation de la base 64 est un choix qui a eacuteteacute fait pour le protocole LoRa LoRaWAN afin de rendre
les donneacutees binaires lisibles Le problegraveme du code ASCII crsquoest qursquoil est composeacute drsquoun certain nombre
de caractegraveres non imprimables (EOF CR LFhellip) Pour eacuteviter ces soucis la base 64 ne comporte que
64 caractegraveres imprimables (voir tableau ci-dessus)
La restriction agrave 64 caractegraveres a cependant un inconveacutenient crsquoest que nous ne pouvons coder que 6
bits (26=64) au lieu de 8 La base 64 est donc moins efficace drsquoune faccedilon geacuteneacuterale
Nous cherchons agrave coder le code ASCII laquo AA raquo en base 64 Retrouver la deacutemarche en
montrant que le reacutesultat en base 64 est laquo QUE= raquo
543 Uplink Du Device LoRa au Network Server Le Network Server de TTN reccediloit des trames IP en provenance de la Gateway Comme nous lrsquoavons
vu preacuteceacutedemment un certain nombre drsquoinformations peuvent ecirctre retrouveacutees avec cette trame
(DevAddr SF Bandwidth etchellip) mais les donneacutees Applicatives sont bien sucircr chiffreacutees (avec
lrsquoAppkSKey) A ce niveau de reacuteception (sans connaitre lrsquoAppSKey) il nrsquoest donc pas possible de
comprendre la totaliteacute du message reccedilu
Imaginons que la trame IP reccedilue 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 45
timestamp 2019-03-05T140042448Z
rssi -82
snr 9
dev_addr 26011AD3
frequency 867300000
Le Network Server affiche donc les informations de la faccedilon suivante
Figure 44 Trame reacutecupeacutereacutee sur le laquo Network Server raquo de TTN
Nous retrouvons bien les valeurs fournies par la Gateway
timestamp ( agrave 1 heure pregraves en fonction du fuseau horaire)
| 44
frequency 8673 Mhz
modulation Lora
Coding Rate 45
data Rate SF 7 125 kHz (DR5)
air time 463 ms
Drsquoautres information proviennent de lrsquoanalyse du Payload Le Payload inscrit ici est le PHY Payload
Il y a donc une partie chiffreacutee (Frame Payload) mais les entecirctes sont en claires (voir paragraphe
441) Ce PHY Payload est laquo QNMaASYABwAP1obuUHQ= raquo Lorsque celui-ci est exprimeacute en
hexadeacutecimal au lieu de la base 64 il vaut laquo 40D31A01260007000FD686EE5074 raquo comme le montre
le Network Server de TTN
Figure 45 PHY Payload preacutesenteacute dans notre Network Server
Sa taille est bien de 14 octets (en hexadeacutecimal) comme preacuteciseacute sur la Figure 44
Nous reprenons le format de la trame LoRaWAN vu agrave la Figure 32 Nous pouvons alors retrouver
tous les champs de toute la trame
PHYPayload = 40D31A01260007000FD686EE5074
PHYPayload = MAC Header[1 octet] | MACPayload[] | MIC[4 octets]
MAC Header = 40 (Unconfirmed data up)
MACPayload = D31A01260007000FD6
Message Integrity Code = 86EE5074
MACPayload = Frame Header | Frame Port | FramePayload )
Frame Header = D31A0126000700
FPort = 0F
FramePayload = D6
Frame Header = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[015]
DevAddr = 26011AD3 (Big Endian)
FCtrl (Frame Control) = 00 (No ACK No ADR)
FCnt (Frame Counter) = 0007 (Big Endian)
FOpts (Frame Option) =
Vous pouvez veacuterifier lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN
(LoRaWAN packet decoder) httpsbitly2szdXtv
| 45
Figure 46 LoRaWAN packet decoder
544 Uplink Du Network Server agrave lrsquoApplication Server
Nous reprenons lrsquoexemple de la trame ci-dessus (Figure 45) Pour information les cleacutes NwkSKey et
AppSKey suivantes ont eacuteteacute utiliseacutee
NwkSKey E3D90AFBC36AD479552EFEA2CDA937B9
AppSKey F0BC25E9E554B9646F208E1A8E3C7B24
Le Network Server a deacutecodeacute lrsquoensemble de la trame Si le MIC est correct (authentification de la
trame par le NwkSKey) alors le Network Server va passer le contenu du message chiffreacute (Frame
Payload) agrave lrsquoApplication Server Dans notre cas le Frame Payload est (drsquoapregraves le deacutecodage effectueacute
au chapitre preacuteceacutedent)
FramePayload = D6
D6 est le contenu chiffreacute lorsqursquoil est deacutechiffreacute avec lrsquoAppSkey on trouve 01 Vous pouvez veacuterifier
lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN httpsbitly2szdXtv
A noter que lrsquoApplication Server recevra les donneacutees chiffreacutees seulement si le Device LoRa a bien
eacuteteacute enregistreacute On peut aussi veacuterifier ci-dessous que lrsquoApplication Serveur de TTN nous retourne bien
un payload (Frame Payload) de 01
Figure 47 Trame reacutecupeacutereacutee sur lrsquoApplication Server de TTN
time 2019-03-05T140042379279991Z
frequency 8673
modulation LORA
data_rate SF7BW125
coding_rate 45
gateways [
gtw_id eui-b827ebfffeae26f6
timestamp 2447508531
time
channel 4
rssi -82
snr 9
latitude 4563647
longitude 58721523
| 46
location_source registry
]
545 Simulation drsquoUplink dans lrsquoApplication Server
Dans beaucoup de situations nous souhaitons valider le fonctionnement de lrsquoApplication Server de
TTN ouet de notre propre Application Il est donc tregraves utile de pouvoir simuler lrsquoenvoi drsquoune trame
LoRa sur lrsquoApplication Server sans que celle-ci soit reacuteellement eacutemise par un Device LoRa Pour cela
un outil existe dans les Settings de chaque Device enregistreacute dans TTN Nous avons juste besoin de
speacutecifier le Frame Payload en clair en hexadeacutecimal et le numeacutero de Port
Figure 48 Simulation drsquoune trame envoyeacutee par un Device LoRa
546 Downlink De lrsquoApplication Server au Device LoRa La communication LoRa est bidirectionnelle Des donneacutees peuvent ecirctre transmis au Device LoRa
depuis lrsquoApplication Server Depuis TTN un outil existe dans les Settings de chaque Device
enregistreacute Lrsquointerface est repreacutesenteacutee ci-dessous
Figure 49 Transmission de donneacutees de lrsquo laquo Application Server raquo jusqursquoau Device LoRa
Replace scheduling Mode Par deacutefaut le Frame Payload transmis remplacera le Frame
Payload en attente (si il existe) Dans ce mode un seul Frame Payload est planifieacute
First scheduling Mode Le Frame Payload est mis en file drsquoattente en premiegravere position
Last scheduling Mode Le Payload est mis en file drsquoattente en derniegravere position
Une demande de confirmation peut ecirctre demandeacutee au Device LoRa pour qursquoil preacutecise srsquoil a bien reccedilu
les donneacutees Lrsquooption laquo confirmed raquo permet donc de speacutecifier le type de trame dans le MAC Header
(voir paragraphe 443) laquo Confirmed Data Down raquo ou laquo Unconfirmed Data Down raquo dans notre cas
| 47
6 La reacutecupeacuteration des donneacutees sur notre propre Application
Nous utiliserons agrave nouveau le Network Server et Application Server de The Things Network Jusqursquoici
nous nous sommes contenteacute de veacuterifier que les donneacutees de lrsquoutilisateur (Frame Payload) soient bien
arriveacutees agrave destination dans lrsquoApplication Server Il faut maintenant les reacutecupeacuterer avec notre propre
Application qui aura pour rocircle
De stocker et traiter les donneacutees
De les mettre agrave disposition de lrsquoutilisateur (Serveur Web par exemple)
Drsquoenvoyer des commandes de lrsquoutilisateur aux Devices LoRa si besoin (Flux Downlink)
Nous allons voir deux meacutethodes pour communiquer entre notre application et TTN
Le protocole HTTP POST
Le protocole MQTT
61 Reacutecupeacuteration des donneacutees en HTTP POST dans lrsquoApplication
611 Preacutesentation du protocole HTTP
Dans le monde de lrsquointernet le protocole HTTP est tregraves utiliseacute pour le dialogue entre un client et un
serveur web Classiquement le client (un navigateur web par exemple) fait une requecircte HTTP GET
et le serveur lui retourne le contenu de la page web demandeacutee
Dans notre cas la probleacutematique est diffeacuterente car le client doit modifier le contenu du serveur
avec les donneacutees envoyeacutees par le Device LORA La requecircte srsquoappelle HTTP POST Son nom indique
que le client va poster (et on pas reacutecupeacuterer) des donneacutees
Lrsquoutilisateur qui souhaite reacuteceptionner des donneacutees sur son serveur doit donc concevoir un serveur
HTTP capable de traiter des requecirctes HTTP POST [ requecircte noteacutee (1) sur la Figure 51 ] fournies par
TTN Dans cette configuration TTN jouera le rocircle de client et notre application le rocircle de serveur
Devices
LORA Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
HTTP POST
MQTT Internet
Figure 50 Structure globale drsquoun reacuteseau LORAWAN
| 48
Figure 51 Communication bidirectionnelle entre TTN et notre Application
A lrsquoinverse lrsquoutilisateur qui souhaite transmettre des donneacutees agrave destination du Device LoRa
(Downlink) doit ecirctre capable de fournir une requecircte HTTP POST [ requecircte noteacutee (2) sur la Figure 51
] vers TTN Dans cette configuration TTN jouera le rocircle de Serveur et notre application le rocircle de
client
612 Fonctionnement drsquoun client et drsquoun serveur HTTP POST Afin de bien comprendre le fonctionnement des requecirctes HTTP POST nous allons proceacuteder par
eacutetape Le premier test que nous effectuerons sera decorreacuteleacute de TTN Le principe est le suivant
Utilisation drsquoun serveur HTTP disponible sur le web geacuterant les requecirctes HTTP POST [
httpsrbasketsin ] ou [ httpsbeeceptorcom ] par exemple
Utilisation drsquoun client HTTP eacutemettant des requecirctes HTTP POST commande curl sous linux
ou logiciel Postman [ wwwgetpostmancom ] sous windows par exemple
Ce test nous permet de valider le fonctionnement drsquoun serveur HTTP POST et drsquoun client HTTP POST
Une fois que nous serons sucircr de leur fonctionnement nous les utiliserons avec TTN
The Things Network
Application
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 49
Figure 52 Validation dun server HTTP POST et drsquoun client HTTP POST
613 Test du serveur HTTP POST Nous utiliserons un serveur web proposeacute par httpsrbasketsin
Aller sur le site httpsrbasketsin et creacuteer un nouveau laquo Basket raquo Zone ougrave vous pourrez
visualiser les requecirctes qui ont eacuteteacute eacutemises vers votre serveur
A partir de maintenant toutes les requecirctes dirigeacutees vers lrsquoadresse creacuteeacute seront traiteacutees et
srsquoafficheront Dans le menu de configuration il est aussi possible de deacutefinir le contenu de la reacuteponse
qui sera fournie
Deacutefinir un format de reacuteponse pour les requecirctes HTTP POST avec un body personnaliseacute
614 Test du client HTTP POST On peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande (la commande cURL
srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN sous Windows
Commande cURL curl ndashX POST ndashd lsquorsquodonneacutees agrave envoyerrsquorsquo DuServeurHTTP
Logiciel Postman New gt Request gt Creacuteer une requecircte HTTP POST gt Send
Veacuterifier que les requecirctes HTTP POST sont bien reacutecupeacutereacutees sur votre serveur creacutee preacuteceacutedemment
615 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST
Maintenant que nous avons un serveur HTTP (POST) fonctionnel nous allons configurer TTN pour
jouer le rocircle du client et pour qursquoil envoie des requecirctes HTTP POST vers notre Serveur degraves qursquoune
donneacutee drsquoun Device LoRa est disponible Nous geacuterons donc ici le flux Uplink
Requecircte
HTTP POST
Reacuteponse
(contenu parameacutetrable)
Client HTTP (POST)
Server HTTP (POST) [ httpsrbasketsin ]
| 50
Figure 53 Reacutecupeacuteration des donneacutees sur notre Application
Dans TTN nous inteacutegrons un bloc appeleacute laquo HTTP Integration raquo permettant de jouer le rocircle de client
crsquoest-agrave-dire drsquoenvoyer des requecirctes HTTP POST agrave destination de notre nouveau Serveur HTTP
Lrsquointeacutegration se faire agrave partir de TTN gt Console gt Application gt Nom_de_votre_application gt
Integration
Figure 54 Ajout dun client HTTP POST dans TTN
Pour valider le fonctionnement de notre architecture nous pouvons soit
Envoyer une trame depuis un Device LoRa vers TTN
Simuler lrsquoenvoi drsquoune trame drsquoun Device LoRa vers TTN (gracircce agrave lrsquooutil proposeacute par TTN vu
paragraphe 545)
Dans les deux cas voici un exemple de requecircte POST reccedilue sur notre serveur HTTP
app_id test_app_lorawan_sylvainmontagny
dev_id stm32lorawan_1
hardware_serial 0056AF49877
port 1
counter 0
payload_raw qg==
metadata
Requecircte
HTTP POST
Server HTTP (POST) [ httpsrbasketsin ]
The Things Network (Client)
La requecircte contient le Frame Payload deacutechiffreacutee
agrave transmettre agrave lrsquoApplication
| 51
time 2019-01-24T15243703499298Z
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Comme nous pouvons le voir le contenu fourni agrave notre serveur est formateacute en JSON (voir
paragraphe 0) Voici quelques compleacutements drsquoinformation
payload_raw Frame Payload deacutechiffreacute crsquoest donc les donneacutees en clairs dans la base 64
downlink_url URL du serveur HTTP POST qui serviront agrave transmettre des donneacutees au Device
LoRa (flux Downlink)
611 Envoyer des donneacutees depuis notre Application avec HTTP POST
Lorsque nous avons ajouteacute le bloc laquo HTTP Integration raquo au paragraphe preacuteceacutedent nous avons aussi
implicitement activeacute la fonctionnaliteacute que TTN soit precirct agrave recevoir et agrave traiter les requecirctes HTTP
POST La seule information qursquoil nous manque est lrsquoadresse du server HTTP vers lequel il faut eacutemettre
les requecirctes Si on observe la trame reccedilue preacuteceacutedemment en provenance de TTN on srsquoaperccediloit que
dans la trame JSON reccedilu une URL (downlink_url) est speacutecifieacutee
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Crsquoest cette URL que nous devrons utiliser Nous allons nous placer dans la configuration suivante
Figure 55 Envoi de donneacutees agrave partir de notre Application
Comme preacuteceacutedemment on peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande
(la commande cURL srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN
Commande cURL curl ndashX POST ndashdata lsquo dev_id Identidiant_De_Votre_Device
payload_raw AQE= rsquo DuServeurHTTP
Logiciel Postman New gt Request gt HTTP POST puis Body gt Raw gt JSON
Requecircte HTTP POST vers serveur TTN laquo downlink_url raquo httpsintegrationsthethingsnetworUaeb8ypKieQ
Contenu de la requecircte
dev_id Identidiant_De_Votre_Device
payload_raw aGVsbG8=
The Things Network (Serveur)
POSTMAN (Client HTTP POST)
| 52
dev_id YourDeviceID
payload_raw aGVsbG8=
Vous devez envoyer le texte (payload_raw) en base 64 Dans lrsquoexemple ci-dessus laquo aGVsbG8= raquo
correspond agrave la chaine de caractegravere laquo hello raquo Vous pouvez utiliser les nombreux encodeurdecodeur
en ligne pour vous aider Le texte doit srsquoafficher sur votre moniteur seacuterie Arduino dans le cadre de
notre deacutemonstrateur sur Arduino
62 Reacutecupeacuteration des donneacutees avec MQTT dans lrsquoApplication
621 Preacutesentation du protocole MQTT
MQTT est un protocole leacuteger qui permet de srsquoabonner agrave des flux de donneacutees Plutocirct que
lrsquoarchitecture Client Serveur classique qui fonctionne avec des Requecirctes Reacuteponses MQTT est
baseacute sur un modegravele Publisher Subscriber La diffeacuterence est importante car cela eacutevite davoir agrave
demander (Requecircte) des donneacutees dont on na aucune ideacutee du moment ougrave elles vont arriver Une
donneacutee sera donc directement transmise au Subscriber degraves lors que celle-ci a eacuteteacute reccedilue dans le
Broker (serveur central)
Figure 56 Modegravele Publisher Subscriber du protocole MQTT
Pour recevoir les donneacutees appartenant agrave un Topic un Subscriber doit souscrire (comme son nom
lindique) au preacutealable sur ce Topic
MQTT est un protocole qui repose sur TCP Lencapsulation des trames sur le reacuteseau est donc la
suivante
Broker
Client
Publisher 1
Client
Publisher 2
Client
Subscriber
Topic
Tempeacuterature
Topic
Humiditeacute
| 53
Figure 57 Protocoles utiliseacutes pour la communication avec MQTT
On peut le veacuterifier par une capture de trame sur Wireshark
Figure 58 Capture dune trame MQTT avec Wireshark
On peut noter que le port TCP utiliseacute pour le protocole MQTT (non chiffreacute) est le 1883
Les Publishers et les Subscribers nrsquoont pas besoin de se connaitre
Les Publishers et les Subscribers ne sont pas obligeacute de srsquoexeacutecuter en mecircme temps
622 Connexion au Broker MQTT Nous nous inteacuteresserons essentiellement aux options de connexion qui permettront de geacuterer la
Qualiteacute de Service (QoS) Pour se connecter un client MQTT envoie deux informations importantes
au Broker
keepAlive Cest la peacuteriode la plus longue pendant laquelle le client Publisher ou Subscriber pourra
rester silencieux Au-delagrave il sera consideacutereacute comme deacuteconnecteacute
cleanSession Lorsque le Client et le Broker sont momentaneacutement deacuteconnecteacutes (au-delagrave du
keepAlive annonceacute) on peut donc se poser la question de savoir ce quil se passera lorsque le client
sera agrave nouveau connecteacute
Si la connexion eacutetait non persistante (cleanSession = True) alors les messages non transmis
sont perdus Quel que soit le niveau de QoS (Quality of Service)
Si la connexion eacutetait persistante (cleanSession = False) alors les messages non transmis
seront eacuteventuellement reacuteeacutemis en fonction du niveau de QoS Voir le chapitre 624
623 Qualiteacute de Service au cours dune mecircme connexion
A partir du moment ougrave le Client se connecte au Broker il est possible de choisir un niveau de fiabiliteacute
des transactions Le Publisher fiabilise leacutemission de ces messages vers le Broker et le Subscriber
fiabilise la reacuteception des messages en provenance du Broker Une parle ici du cas dune mecircme
connexion crsquoest-agrave-dire entre le moment ou le Client se connecte et le moment ougrave
Soit il se deacuteconnecte explicitement (Close connexion)
Soit il na rien eacutemis ni fait signe de vie pendant le temps keepAlive
TCP
MQTT
Reacuteseau
Transport
Couche Application
IP
| 54
Lors dune mecircme connexion la Qualiteacute de Service (QoS) qui est mise en œuvre deacutepend uniquement
de la valeur du QoS selon les valeurs suivantes
QoS 0 At most once (au plus une fois) Le premier niveau de qualiteacute est sans acquittement Le
Publisher envoie un message une seule fois au Broker et le Broker ne transmet ce message quune
seule fois aux Subscribers Ce meacutecanise ne garantit pas la bonne reacuteception des messages MQTT
QoS 1 At least once (au moins une fois) Le deuxiegraveme niveau de qualiteacute est avec acquittement
Le Publisher envoie un message au Broker et attends sa confirmation De la mecircme faccedilon le Broker
envoie un message agrave ces Subscriber et attends leurs confirmations Ce meacutecanisme garantit la
reacuteception des message MQTT
Cependant si les acquittements nrsquoarrivent pas en temps voulu ou srsquoils se perdent la reacuteeacutemission du
message dorigine peut engendrer une duplication du message Il peut donc ecirctre reccedilu plusieurs fois
QoS 2 Exactly once (exactement une fois) Le troisiegraveme niveau de qualiteacute est garanti une seule
fois Le Publisher envoie un message au Broker et attends sa confirmation Le Publisher donne alors
lrsquoordre de diffuser le message et attends une confirmation Ce meacutecanisme garantit que quel que
soit le nombre de tentatives de reacuteemission le message ne sera deacutelivreacute quune seule fois
La Figure 59 montre les trames eacutemises pour chaque niveau de QoS
Figure 59 Qualiteacute de Service en MQTT
La Figure 60 repreacutesentes les 3 captures de trames sur Wireshark repreacutesentant les 3 QoS (1 2 et 3)
que nous venons dexpliquer
Broker
QoS 0
Au plus une fois
Message supprimeacute apregraves envoi
PUBLISH
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Duplications possibles
PUBLISH
PUBLICH Ack
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Pas de duplication
PUBLISH
PUBLISH Receive
PUBLISH Release
PUBLISH Complete
| 55
Figure 60 Capture de trame avec QoS = 0 puis QoS = 1 puis QoS = 2
624 Qualiteacute de Service apregraves une reconnexion
La question que nous nous posons et de savoir ce que deviennent les messages publieacutes sur le Broker
lorsquun ou plusieurs Subscribers sont momentaneacutement injoignables Il est possible de conserver
les messages qui ont eacuteteacute publieacutes sur le Broker afin de les retransmettre lors de la prochaine
connexion Cette possibiliteacute de sauvegarde doit ecirctre activeacutee agrave louverture de connexion gracircce au flag
cleanSession = 0 La connexion sera alors persistante crsquoest-agrave-dire que le Broker enregistre tous les
messages quil na pas reacuteussi agrave diffuser au Subscriber
Le Tableau 9 reacutesume leffet du flag cleanSession et du QoS
Clean Session Flag Subscriber QoS Publisher QoS Comportement True ( = 1) 0 1 2 0 1 2 Messages perdus
False ( = 0 ) 0 0 1 2 Messages perdus
False (= 0 ) 0 1 2 0 Messages perdus
False (= 0 ) 1 2 1 2 Tous les messages sont retransmis
Tableau 9 Qualiteacute de Service en fonction de la valeur du QoS et du flag cleanSession
625 Les Topics du protocole MQTT Les chaicircnes deacutecrivant un sujet forment une arborescence en utilisant la barre oblique comme
caractegravere de seacuteparation La Figure 61 et le Tableau 10 donne un exemple dorganisation de Topic
Figure 61 Exemple de hieacuterarchie de Topic MQTT
Niveau 3
Niveau 2
Niveau 1 Maison
Chambre
Temperature Humidite Bruit
Salon
Temperature
| 56
Nom du Topic Deacutetail du Topic MaisonChambreTemperature La tempeacuterature de la chambre de la maison
MaisonChambreBruit Le bruit de la chambre de la maison
MaisonSalonTemperature La tempeacuterature du Salon de la maison
Tableau 10 Exemple de Topic
Un client peut sabonner (ou se deacutesabonner) agrave plusieurs branches de larborescence agrave laide de
jokers englobant plusieurs Topics Deux caractegraveres jokers existent
Le signe plus + remplace nimporte quelle chaine de caractegravere sur le niveau ougrave il est placeacute
Le diegravese remplace nimporte quelle chaine de caractegravere sur tous les niveaux suivants Il
est obligatoirement placeacute agrave la fin
Nom du Topic Deacutetail du Topic Maison+Temperature Les tempeacuteratures de toutes les piegraveces de la maison
MaisonChambre La tempeacuterature lhumiditeacute et le bruit de la chambre de la maison
Tableau 11 Exemple de Topic
626 Mise en place drsquoun Broker MQTT Afin de bien comprendre le fonctionnement du protocole de MQTT on reacutealise des tests
indeacutependamment de TTN Nous allons mettre en place
Un Broker Mosquitto httpstestmosquittoorg
Un client Publisher MQTT Box sur Windows
Un client Subscriber MQTT Box sur Windows
Figure 62 Test du protocole MQTT
MQTT Client (Subscriber)
MQTT Client (Publisher)
Publish
Subscribe
BROKER (Mosquitto)
| 57
Le Broker MQTT est commun agrave tout le monde Nous pouvons soit le reacutealiser nous-mecircme soit utiliser
un Broker MQTT public de test Nous utiliserons le Broker de test de Mosquitto disponible sur
httpstestmosquittoorg Drsquoautres sont eacuteventuellement disponibles en cas de problegraveme par
exemple httpwwwmqtt-dashboardcom
Si nous deacutecidions de le reacutealiser nous-mecircme agrave lrsquoaide drsquoune Raspberry Pi (par exemple) Lrsquoinstallation
se ferait en deux lignes de commande
apt-get install mosquito Installation
sudo systemctl start mosquittoservice Lancement du service
Il est neacutecessaire drsquoinstaller mosquitto-clients si on souhaite que le Raspberry PI joue aussi le rocircle de
client ce qui nrsquoest pas notre cas
627 Mise en place drsquoun Publisher et drsquoun Subscriber MQTT Lancer le logiciel MQTTBox
MQTTBox gt Create MQTT Client
Dans ce client les seuls champs indispensables sont
Protocol MQTT TCP
Host testmosquittoorg
Figure 63 Configuration dun Client MQTT dans MQTT Box
Tester lrsquoenvoi et la reacuteception sur les Topics de votre choix
628 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT La reacutecupeacuteration des donneacutees fait reacutefeacuterence au flux Uplink Dans ce cas
TTN joue le rocircle de client Publisher
TTN joue aussi le rocircle de Broker
Notre application joue le rocircle de Subscriber
Nous pouvons donc repreacutesenter lrsquoapplication globale par le scheacutema suivant
| 58
Figure 64 Publisher et Subscriber dans en MQTT avec TTN
La publication est repreacutesenteacutee par la trame MQTT (1)
La souscription est repreacutesenteacutee par la trame MQTT (2)
Le client Publisher eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box mais cette fois avec la configuration suivante
Protocol mqtt tcp
Host Crsquoest lrsquoIP du Broker vers lequel il faut se connecter Dans notre cas il srsquoagit de celui
de TTN dont lrsquoadresse est euthethingsnetwork
Username La connexion vers le broker MQTT est soumis agrave une authentification Username
Password Dans notre cas le Username correspond au nom de notre application crsquoest-agrave-
dire seminaire_lorawan Si vous avez choisi une autre applicationil faut bien mettre la
votre
Password Le Password est nommeacute laquo Access Key raquo par TTN Elle vous sera donneacutee par
lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application vous
trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt Overview
Figure 65 Access Keys de lapplication dans TTN
The Things Network (Application Server)
BROKER
Application
The Things Network (Network Server)
Publish (1 )
[ Flux Uplink ]
Subscribe (2 )
[ Flux Uplink ]
| 59
Figure 66 Configuration du Client dans MQTT Box
Le client MQTT eacutetant configureacute il est maintenant capable de se connecter au Broker Il reste donc agrave
deacutefinir le fait que le client sera Subscriber Les informations que recevra le Subscriber deacutependent du
Topic auquel nous souscrivons Voici les Topic disponibles sur le Broker de TTN
ltAppIDgt correspond au nom de votre Application
ltDevIDgt correspond au nom de votre Device LoRa
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink ltAppIDgtdevicesltDevIDgtup
[Donneacutees] Flux Downlink ltAppIDgtdevicesltDevIDgtdown
[Activation Events] Activation dun Device ltAppIDgtdevicesltDevIDgteventsactivations
[Management Events] Creacuteation dun Device ltAppIDgtdevicesltDevIDgteventscreate
[Management Events] Update dun Device ltAppIDgtdevicesltDevIDgteventsupdate
[Management Events] Suppression dun Device ltAppIDgtdevicesltDevIDgteventsdelete
[Downlink Events ] Message programmeacute ltAppIDgtdevicesltDevIDgteventsdownscheduled
[Downlink Events ] Message envoyeacute ltAppIDgtdevicesltDevIDgteventsdownsent
[Erreurs] Uplink erreurs ltAppIDgtdevicesltDevIDgteventsuperrors
[Erreurs] Downlink erreurs ltAppIDgtdevicesltDevIDgteventsdownerrors
[Erreurs] Activations erreurs ltAppIDgtdevicesltDevIDgteventsactivationserrors
Tableau 12 Topics enregistreacutes dans TTN
Dans un premier temps nous souscrivons au Topic +devices+up Cela signifie que nous
souscrivons agrave tous les Devices LoRa de toutes nos applications pour le flux Uplink
Figure 67 Configuration du Subscriber
Les eacuteleacutements eacutemis par le Broker seront alors afficheacutes dans MQTTBox La
| 60
Figure 68 Trame LoRaWAN reccedilu sur le Subscriber MQTT
Ces donneacutees sont eacutecrites en JSON nous pouvons les remettre en forme
applicationID3
applicationNamemyApplication
deviceNamearduino0
devEUI0056xxxxxxxxx877
txInfo
frequency868500000
dr5
adrfalse
fCnt792
fPort15
dataSGVsbG8=
Le Frame Payload deacutechiffreacute est fourni dans le champ data en base 64 La valeur fournie par
dataSGVsbG8= correspond bien agrave la chaine de caractegravere hello que nous avons eacutemise avec le
Device LoRa
629 Envoyer des donneacutees depuis notre Application avec MQTT
Lrsquoenvoi des donneacutees fait reacutefeacuterence au flux Downlink Dans ce cas
Notre application joue le rocircle de Publisher
TTN joue le rocircle de Broker
TTN joue aussi le rocircle de client Subscriber
| 61
La publication est repreacutesenteacutee par la trame MQTT (3)
La souscription est repreacutesenteacutee par la trame MQTT (4)
Le client Subscriber eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box Le rocircle de client dans MQTT Box a eacuteteacute faite au
paragraphe 628 Il nous reste simplement agrave ajouter le rocircle de Publisher La configuration est la
suivante
Topic du Subscriber seminaire_lorawandevicesarduino0down ougrave seminaire_lorawan
est agrave remplacer par le nom de votre application et arduino0 par le nom du Device LoRa vers
lequel vous souhaitez envoyeacute une donneacutee (Voir chapitre 628 pour comprendre les Topics)
Le Payload doit ecirctre au format JSON Lrsquoexemple suivant envoie laquohello raquo
payload_raw aGVsbG8=
The Things Network (Application Server)
BROKER
Application
Publish (3)
[ Flux Downlink ]
The Things Network (Network Server)
Subscribe (4)
[ Flux Downlink ]
| 62
Figure 69 Configuration du Publisher
Vous devriez voir les donneacutees arriver sur votre Device LoRA
| 63
7 Creacuteation de notre propre Network et Application Server
711 Objectifs Lors de la mise en œuvre du reacuteseau LoRaWAN au chapitre 52 nous avons utiliseacute TTN (The Things
Network) pour jouer le rocircle de Network Server et drsquoApplication Server Pour de multiples raisons
Seacutecuriteacute autonomie coucircthellipil peut ecirctre inteacuteressant de monter soi-mecircme un Network Server et un
Application Server Cela est possible seulement si vous posseacutedez vos propres Gateway puisque
celles-ci devront forwarder leur paquet agrave destination preacutecise Il faudra donc les reconfigurer pour
qursquoelles pointent vers votre nouvelle architecture
712 Preacutesentation de LoRaServer LoRaServer [ wwwloraserverio ] est un projet Open-Source reacutepondant exactement au besoin que
nous avons Nous lrsquoutiliserons sur une cible Raspberry PI En reacutealiteacute il peut souvent ecirctre mise en
place dans le mecircme systegraveme que la Gateway surtout si celle-ci est elle-mecircme agrave base de RPI Les
Gateway EBDS que nous posseacutedons possegravedent drsquoailleurs un Network Server et un Application Server
que nous aurions pu utiliser Neacuteanmoins pour des raisons peacutedagogiques il est inteacuteressant de
seacuteparer les systegravemes pour bien diffeacuterencier les probleacutematiques
Attention il y a une ambiguiumlteacute dans la deacutenomination des entiteacutes logiciels de LoRaServer
LoRaServer (sans espace entre le mot LoRa et Server) est le nom du projet global En
revanche LoRa Server (avec un espace) est le nom du service qui joue le rocircle du Network
Server
Lrsquoarchitecture et le fonctionnement de LoRaServer est preacutesenteacutee dans sa documentation par le
scheacutema suivant
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Raspberry PI
Figure 70 Architecture globale de notre reacuteseau loRaWAN
| 64
Figure 71 Architecture deacutetailleacutee de LoRaServer
On srsquoattends agrave voir uniquement un Network Server (LoRa Server) et un Application Server (LoRa App
Server) mais ce scheacutema est plus complexe Il demande un certain nombre drsquoexplications pour bien
comprendre ce que nous allons installer et la faccedilon dont nous lrsquoutiliserons par la suite
713 Le laquo Packet Forwarder raquo (Gateway) Comme nous lrsquoavons vu au chapitre 412 les Gateways LoRa sont des passerelles entre la
modulation LoRa et un reacuteseau IP Pour reacutealiser cette passerelle un service nommeacute laquo UDP Packet
Forwarder raquo a eacuteteacute deacuteveloppeacute par Semtech httpsgithubcomLora-netpacket_forwarder Dans
ce dossier github un fichier nommeacute PROTOCOLTXT explique parfaitement ce protocole applicatif
qui travaille au-dessus de UDP
Figure 72 Protocole Uplink (PUSH_DATA du Packet Forwarder)
| 65
On remarque que les paquets sont envoyeacutes en UDP au Network Server dans une trame appeleacutee
PUSH_DATA Cette trame est acquitteacutee par le Network Server par une trame appeleacutee PUSH_ACK
Sur notre Network Server nous pouvons reacutealiser une capture de trame pour veacuterifier si le protocole
est bien celui preacutesenteacute dans le document
Figure 73 Trame captureacutee par Wireshark lors dun Uplink
Drsquoapregraves la capture preacuteceacutedente on remarque que le Packet Forwarder fonctionne bien avec UDP sur
le port 1700
Le contenu des donneacutees (champ Data) est deacutetailleacute dans le tableau suivant
Champ | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | random token
[3] | 3 | PUSH_DATA identifier = 0x00
[4] | 4-11 | Gateway unique identifier (MAC address)
[5] | 12-end | JSON object starting with ending with
Lrsquoobjet JSON de la transmission reacuteeacutecrit plus proprement est celui-ci
Figure 74 Analyse du champ Donneacutees du protocole laquo Packet Forwarder raquo
0000 02 f9 30 00 b8 27 eb ff fe ae 26 f5 7b 22 72 78 0amprx 0010 70 6b 22 3a 5b 7b 22 74 6d 73 74 22 3a 33 37 35 pk[tmst375 0020 35 30 30 35 38 31 39 2c 22 63 68 61 6e 22 3a 32 5005819chan2 0030 2c 22 72 66 63 68 22 3a 31 2c 22 66 72 65 71 22 rfch1freq 0040 3a 38 36 38 2e 35 30 30 30 30 30 2c 22 73 74 61 868500000sta 0050 74 22 3a 31 2c 22 6d 6f 64 75 22 3a 22 4c 4f 52 t1moduLOR 0060 41 22 2c 22 64 61 74 72 22 3a 22 53 46 37 42 57 AdatrSF7BW 0070 31 32 35 22 2c 22 63 6f 64 72 22 3a 22 34 2f 35 125codr45 0080 22 2c 22 6c 73 6e 72 22 3a 36 2e 35 2c 22 72 73 lsnr65rs 0090 73 69 22 3a 2d 31 2c 22 73 69 7a 65 22 3a 31 38 si-1size18 00a0 2c 22 64 61 74 61 22 3a 22 51 4e 4d 61 41 53 59 dataQNMaASY 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 ]
Ch
amp
[1
]
Ch
amp
[2
]
Ch
amp
[3
]
Ch
amp
[4
]
| 66
rxpk[ tmst3755005819
chan2
rfch1
freq868500000
stat1
moduLORA
datrSF7BW125
codr45
lsnr65
rssi-1
size18
dataQNMaASYAAQAPpyPZ955+SmY
]
Le champ data correspond au PHY Payload
De la mecircme faccedilon on retrouve la Trame drsquoacquittement
Figure 75 Trame captureacutee par Wireshark lors de lrsquoacquittement drsquoun Uplink
Champs | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | same token as the PUSH_DATA to acknowledge
[3] | 3 | PUSH_ACK identifier = 0x01
Nous retrouvons bien tous ces champs dans la trame Wireshark
714 LoRa Gateway Bridge Nous avons deacutecrit au chapitre preacuteceacutedent (713) le fonctionnement du Packet Forwarder Le
Network Server(Lora Server) que nous allons mettre en place aurait tregraves bien pu srsquointerfacer
directement agrave ce protocole Mais cela aurait plusieurs impacts dont un qui est important dans la
conception de logiciel Si le Packet Forwarder change ou si un autre type de Forwarder est utiliseacute
alors lrsquoutilisation du LoRa Server devient impossible Il a donc eacuteteacute choisi de creacuteer une eacutetape
intermeacutediaire Le Network Server que nous mettrons en plus utilisera le protocole MQTT plutocirct que
le protocole UDP packet Forwarder
En drsquoautres termes le LoRa Gateway Bridge est un service qui fera abstraction du Packet Forwarder
pour srsquointerfacer plus simplement avec le Network Server
715 LoRa Server (Network Server) Il srsquoagit de notre Network Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
413 Cependant il srsquointerfacera au protocole MQTT en recevant les informations agrave partir du
Broker au lieu de recevoir directement les trames en provenance de la Gateway
| 67
716 LoRa App Server (Application Server) Il srsquogit de notre Application Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
414
717 LoRa Geo Server Il srsquoagit drsquoun service qui permet drsquoutiliser certaines proprieacuteteacutes du protocole LoRa pour proposer un
service de geacuteolocalisation des Devices LoRa Nous ne lrsquoutiliserons pas dans notre cas
718 Application Il srsquoagit de notre Application qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre 415
Elle ne fait pas partie du projet LoRaServer crsquoest donc bien toujours agrave nous de proposer notre propre
Application
Figure 76 Les interfaces possibles entre LoRaServer et lrsquoApplication utilisateur
Comme nous pouvons le voir sur la figure preacuteceacutedente deux possibiliteacutes sont offertes pour interfacer
notre application JSON REST (incluant HTTP POST) et via un Broker MQTT Ces deux meacutethodes ont
deacutejagrave eacuteteacute traiteacutee au chapitre 61 (HTTP POST ) et au chapitre 62 (MQTT) Nous verrons aussi drsquoautres
possibiliteacutes pour personnaliser notre application au chapitre 7
72 Installation de LoRaServer
721 Mise en place de lrsquoenvironnement
Nous allons installer une carte SD avec la derniegravere version de Raspbian Nous ne deacutetaillerons pas la
deacutemarche pour cela car elles sont largement documenteacutees et mises agrave jour sur le site
wwwraspberrypiorg
Installer un carte SD avec la derniegravere version de Raspbian
Plutocirct que de fonctionner avec un clavier et une souris nous preacuteconisons de travailler agrave distance
avec la RPI via une connexion SSH Depuis quelques anneacutees Raspbian a supprimeacute le deacutemarrage du
service SSH au boot Heureusement il est possible de le reacuteactiver par la meacutethode suivante
Avec Windows ou Linux ouvrir la partition BOOT de votre carte SD et placer un fichier agrave la
racine nommeacute sshtxt (ou ssh)
Mettre la carte SD dans votre RPI et la deacutemarrer
| 68
Pour acceacuteder agrave la RPI en SSH depuis Windows nous utiliserons de preacutefeacuterence le logiciel
client MobaXterm mais tout autre client SSH est valable
Installer MobaXterm sur votre PC et connectez-vous agrave votre Raspberry PI
Lrsquoutilisation drsquoun espion de reacuteseau type Wireshark peut ecirctre inteacuteressant pour eacutetudier les trames qui
sont reccedilues et qui sont eacutemises Cela nous permettra de valider le fonctionnement des diffeacuterents
protocoles reacuteseau qui permettent de communiquer agrave la Gateway drsquoune part et agrave lrsquoApplication
drsquoautre part Nous utiliserons tshark
apt-get install tshark installation
tshark ndashn -i eth0 Exemple drsquoune analyse sur lrsquointerface wlan0
722 Installation sur la Raspberry PI La meacutethode drsquoinstallation de LoRaServer est documenteacutee sur le site web agrave lrsquoadresse suivante
[ httpswwwloraserverioguidesdebian-ubuntu ] Nous installerons le LoRa Gateway Bridge
le LoRa Server et le LoRa App Server
Apregraves lrsquoinstallation la configuration se fait par une interface graphique accessible par le reacuteseau sur
le port 8080
Si vous travaillez sur la RPI connectez-vous sur httplocalhost8080
Si vous travaillez agrave distance (SSH) connectez-vous sur httpIP_RPI8080
Les Usernames et Password par deacutefaut sont
Username admin
Password admin
Lrsquoeacutecran drsquoaccueil sera donc le suivant
Figure 77 Architecture globale apregraves installation de LoRaServer
Devices
Gateways LoRa
UDP Packet Forwarder
Application Server
LoRa App Server
Internet
Network Server
LoRa Server
LoRa Gateway Bridge
| 69
Figure 78 Ecran daccueil de LoRaServer apregraves authentification
71 Configuration de LoRa Server pour lUplink
711 Enregistrement drsquoune nouvelle Organisation
Pour enregistrer une nouvelle Organizations Organizations gt Create Puis entrer les configurations
suivantes
Figure 79 Enregistrement dun nouvelle Organisation
712 Enregistrement drsquoune instance du Network Server Pour enregistrer une nouvelle instance du Network Server Network Server gt Create Puis entrer
les configurations suivantes
| 70
Figure 80 Enregistrement dun nouveau Network Server
Dans lrsquoonglet Gateway Discovery il est possible drsquoactiver une option de deacutecouverte de Gateway aux
alentours Lorsqursquoelle est configureacutee le Network Server va envoyer une trame Downlink de
configuration de la Gateway lui ordonnant de reacutealiser des PING en LoRa La configuration du
Gateway Discovery preacutevoit de speacutecifier
Le nombre de fois par jour que les PING LoRa sont envoyeacutes
Le canal drsquoeacutemission
Le Data Rate (Voir paragraphe 445)
Un PING LoRa reccedilu sur une Gateway sera retransmis sur le Network Server (Lora Server) et une carte
sera afficheacutee
Lrsquoonglet TLS Certificates ne sera pas utiliseacute dans le cadre de notre deacutemonstration
713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) Il faut tout drsquoabord faire un enregistrement drsquoun laquo service-profile raquo Un laquo service profile permet de
faire la connexion entre le Network Server et les Applications que nous enregistrerons dans notre
Organisation Service-profiles gt Create
Service-profile name myServiceProfile
Network-server myNetworkServer
On laissera par deacutefaut toutes les autres options
Pour enregistrer une nouvelle Application Applications gt Create Puis entrer les configurations
suivantes
| 71
Figure 81 Enregistrement dune nouvelle Application
714 Enregistrement des Devices LoRa Il faut tout drsquoabord faire lrsquoenregistrement drsquoun Device-profile pour les Devices LoRa que vous
souhaitez connecter Dans notre cas nous ferons un premier test en speacutecifiant que nous utilisons
seulement le mode drsquoauthentification ABP (voir chapitre 431) Devices profile gt Create
Figure 82 Enregistrement dun laquo Device profile raquo
Nous pouvons alors creacuteer dans notre Application des nouveaux Devices Application gt
myApplication gt Create
| 72
Figure 83 Enregistrement dun nouveau Device LoRa
Dans la fenecirctre Activation on va alors configurer les 3 eacuteleacutements indispensables agrave une
authentification en APB Le DevAddr le NwkSKey et lrsquoAppSKey
Figure 84 Configuration de lenregistrement du Device LoRa (en ABP)
La configuration minimale de LoRaServer est maintenant termineacutee Nous pouvons donc brancher
un Device LoRa qui possegravede les les attribus (DevAddr NwkSKey et AppSKey) que nous avons
enregistreacute dans LoRaServer et le faire eacutemettre
715 Visualisation des trames reccedilues Les trames eacutemises par le Device LoRa vont donc parcourir le cheminement suivant
| 73
Figure 85 Reacutesumeacute du cheminement des trames LoRaWan en Uplink avec LoRaServer
En allant dans le Live Device Data (Application gt Nom_du_Device gt Live Device Data) on peut voir la
liste des trames reccedilues ainsi que les donneacutees applicatives deacutechiffreacutees
Figure 86 Reacuteception des trames des Devices LoRa
Figure 87 Analyse des trames des Devices LoRa
Dans lrsquoonglet LIVE LORAWAN FRAME nous pouvons voir les trames LORAWAN et si besoin eacutetudier
le contenu de ce qursquoelles contiennent En revanche les donneacutees applicatives sont ici chiffreacutees
UDP
Packet Forwarder
LoRa Bridge
Gateway LoRa Server LoRa App Server
Gateway
Server
Internet
| 74
Figure 88 Reacuteception des Trames LoRaWAN
72 Configuration de LoRaServer pour linteacutegration dApplication Nous avons vu dans le chapitre 718 que linterface entre LoRaServer et notre Application pouvait
ecirctre reacutealiseacutee soit par MQTT soit par les meacutethodes REST (HTTP POST) Nous avons deacutejagrave impleacutementeacute
et expliqueacute ces protocoles dans le cadre de son utilisation avec TTN Nous allons donc juste
configurer LoRaServer pour tester ces deux meacutethodes
721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST Nous utiliserons exactement la mecircme meacutethode que celle que nous avons utiliseacute avec TTN au
chapitre 615 Les diffeacuterentes Clients et Serveurs disponibles pour ces tests sont expliqueacutes au
paragraphe 612
Dans LoRaServer ajouter une inteacutegration HTTP LoRaServer gt Applications gt myApplication gt
Integrations gt Create gt HTTP Integration et la configurer comme le montre la Figure 89 Vous
remplacerez eacutevidement le lien par votre propre Endpoints
Figure 89 Configuration de linteacutegration HTTP POST dans LoRaServer
En envoyant des trames LoRa depuis votre Device vous devriez voir les contenus JSON sur votre
Endpoint
722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT Nous allons nous connecter au Broker MQTT de LoRaServer Pour cela nous utiliserons la mecircme
meacutethode que celle que nous avons utiliseacute avec TTN au chapitre 628 Nous utiliserons MQTTBox
comme nous lavons deacutejagrave fait au paragraphe 627
Le Broker de LoRaServer a enregistreacute les Topics suivant
[applicationID] correspond au nom de votre Application
[devEUI] correspond au nom de votre Device LoRa
| 75
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink application[applicationID]device[devEUI]rx
[Donneacutees] Flux Downlink application[applicationID]device[devEUI]tx
[Status] Statut dun Device application[applicationID]device[devEUI]status
[Ack] Acquittement des messages application[applicationID]device[devEUI]ack
[Erreurs] Erreurs application[applicationID]device[devEUI]error
Tableau 13 Topics enregistreacutes dans LoRaServer
| 76
8 Creacuteation de notre propre Application
81 Utilisation de Node-RED
811 Preacutesentation Node-RED est un outil de programmation graphique qui permet de faire communiquer les
peacuteripheacuteriques mateacuteriels drsquoun systegraveme sans eacutecrire de code De nombreux protocoles sont aussi pris
en charge au travers de bloc ( Node) qursquoil suffit de connecter entre eux pour reacutealiser simplement
une application Il peut srsquoexeacutecuter localement sur un PC ou sur des cibles embarqueacutees telle qursquoune
Raspberry PI (RPI)
Dans les deacutemonstrations que nous mettrons en œuvre nous utiliserons une RPI Par soucis de
simpliciteacute nous utiliserons les derniegraveres versions de Raspbian (systegraveme drsquoexploitation de la RPI) qui
integravegre drsquoorigine Node-RED Il nrsquoy a donc tregraves peu de chose agrave mettre en place pour arriver agrave mettre
en place une Application Nous pouvons travailler soit directement sur la RPI agrave lrsquoaide drsquoune souris-
clavier mais il est recommandeacute de travailler agrave distance avec une connexion SSH
812 Mise en place de lrsquoenvironnement La mise en place de la RPI avec le systegraveme drsquoexploitation Raspbian a eacuteteacute preacutesenteacute au chapitre 721
Vous pouvez reprendre la mecircme installation ou repartir sur une nouvelle
Il est possible de faire en sorte que Node-RED se lance directement au deacutemarrage gracircce agrave la
commande sudo systemctl enable noderedservice
Sil nest pas actif lancer Node-RED sur votre RPI node-red-start
Nous nous connectons au Node-RED de la RPI via un navigateur web sur le port 1880 en tapant dans
la barre dURL httpIP_Raspeberry_PI1880 Ce nous permet darriver agrave la fenecirctre suivante
Figure 90 Page daccueil de Node-RED
Il est possible de sinterfacer avec TTN avec les Nodes deacutejagrave disponibles gracircce au protocole HTTP
POST ou MQTT Neacuteanmoins nous pouvons avantageusement installer deux librairies speacutecifiques
Une qui facilite linterfaccedilage avec TTN
Une qui facilite la mise en place dinterface graphique
Installation des Nodes TTN
cd $HOMEnode-red
npm install node-red-contrib-ttn
Installation de Dashboard (interface graphique)
| 77
cd $HOMEnode-red
npm install node-red-dashboard
Il peut ecirctre necessaire de redeacutemarrer Node-RED pour prendre en compte linstallation de nos deux
Nodes
-----------------------------------
sudo apt-get install npm
sudo npm install -g npm
hash -r
cd ~node-red
npm install node-red-example node name
------------------------------------
813 Creacuteer une Application speacutecifique pour TTN Nous allons commencer par geacuterer le flux Uplink Apporter sur votre scheacutema un Node ttn uplink et
un Node Debug puis relier les Le Node ttn uplink nous permettra de configurer la
communication avec TTN en MQTT Le Node debug eacutecrira sur le terminal les informations brutes
qui seront reccedilu par le Node ttn uplink
Figure 91 Visualisation des trame publieacutees par TTN sur notre client MQTT
Double cliquer sur le Node ttn uplink pour le configurer comme la figure suivante
Le champ Name sera le nom du Node sur votre scheacutema Le champ Device ID est le device LoRa
concerneacute dans votre application De plus il faut entrer les caracteacuteristiques de votre application (Add
new ttn app) pour que Node-RED puisse sy connecter
Figure 92 Configuration du node ttn uplink
Configuration de votre nouvelle application
| 78
Figure 93 Identifiant et mot de passe de notre application
AppID Nom de votre application Dans notre cas seminaire_lorawan
Access Key Comme nous lavons deacutejagrave expliqueacute plus tocirct l Access Key vous sera donneacutee
par lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application
vous trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt
Overview
Le Node ttn uplink doit maintenant avoir le nom que vous avez configureacute Cliquer sur Deploy pour
lancer votre projet Le bloc ttn uplink doit maintenant ecirctre connecteacute agrave TTN Cela est speacutecifieacute
connected sous le bloc
Figure 94 Utilisation du Node TTN Uplink
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
Figure 95 Simulation de Uplink dans TTN
Vous devriez voir le reacutesultat dans la fenecirctre de Debug Par exemple pour le test denvoi de 31 32
correspondant au code ASCII des chiffres 1 et 2 vous devriez avoir la fenecirctre de Debug suivante
| 79
Figure 96 Reacutesultats obtenu dans la fenecirctre Debug apregraves la simulation dUplink
814 Creacuteation drsquoun Dashboard
Dans la mise en place de lenvironnement (chapitre 812) nous avons installeacute des Nodes
Dashboard qui vont nous permettre de reacutealiser une interface graphique tregraves simple et de la mettre
agrave disposition des utilisateurs via un des graphiques histogramme gauges afficheurshellip
Figure 97 Impleacutementation dune interface graphique dans Node RED
Linterface graphique que nous allons creacuteer sera constitueacutee donglet (tab) La mise en place des
composant se fait de la faccedilon suivante
Chaque eacuteleacutement graphique doit appartenir agrave un groupe de composant quil va falloir creacuteer
Chaque groupe de composant doit appartenir agrave un onglet (tab) quil va falloir creacuteer
Figure 98 Creacuteation dun groupe de composant
Figure 99 Creacuteation dun nouvel onglet dans le site web
Cliquer sur Deploy pour activer votre application
LURL pour joindre linterface graphique de votre site web est disponible sur ladresse
httpIP_Raspeberry_PI1880ui
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
| 80
Figure 100 Interface graphique du site web avec Node-RED
82 Programmation en PHP Maintenant que nous avons testeacute toute lrsquoarchitecture nous pouvons mettre en place une
application qui jouera deux rocircles
Un rocircle de Serveur HTTP POST reacutecupeacuterant les donneacutees en provenance de TTN
Un rocircle de Client HTTP POST qui geacuteneacuterera les requecirctes vers TTN
Un serveur web apache sur RPI heacuteberge cette application Linterface graphique du site web est
reacutealiseacute avec le template CSS proposeacute par Bootstrap [ httpsgetbootstrapcom ]
Figure 101 Architecture de notre application en PHP sur RPI
The Things Network
Notre Application
[ Serveur Apache sur Raspberry Pi ]
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 81
Nous allons lrsquoutiliser telle quelle Elle est juste proposeacutee agrave titre dexemple Lrsquoobjectif de cette
application est de geacuteneacuterer une ouverture fermeture de ruche agrave distance dans le cadre de projets
eacutetudiants du Master Electronique et Systegravemes Embarqueacutes de lUSMB [ httpscem-esetuniv-
smbfr ]
Figure 102 Application permettant de recevoir et deacutemettre des requecirctes HTTP POST
Configurer TTN pour pointer vers votre nouveau serveur et tester le flux montant et
descendant
| 82
9 Versions du document
Version 10 02022019
Version initiale
Version 20 23022019
Ajout drsquoun paragraphe Les systegravemes embarqueacutes dans lrsquoIoT En introduction
Compleacutement et ameacutelioration Ameacutelioration exercice eacutetalement de spectre
Correction Cacircblage Arduino
Ajout drsquoun paragraphe Fonctionnement de lrsquoArduino et ajout de librairies
Compleacutement et ameacutelioration Couche physique LoRa Ajout de 4 figures pour lrsquoexplication
de la modulation Chirp
Ajout drsquoun paragraphe sur les acronymes utiliseacutes au deacutebut du cours TTN LoRa MQTThellip
Compleacutement drsquoinformations sur les dB et dBm
Ajout LoRa Calculator
Version 30 8032019
Ajout de figure sur le rocircle de la Gateway LoRa
Ajout de paragraphe authentification avec le Network Server
Ajout de paragraphe sur le chiffrement avec lrsquoApplication Server
Ajout drsquoun sommaire en deacutebut de cours
Ajout de 2 scheacutemas ABP et OTAA
Retrait explication du deacutetail de la laquo Join Request raquo en OTAA Trop complexe attente de
reacutealisation drsquoun scheacutema plus explicite
Ajout drsquoun scheacutema sur lrsquoattaque par REPLAY
Ajout de paragraphe des diffeacuterents reacuteseaux LoRaWAN existants Opeacutereacutes et Priveacutes
Ajout des scheacutemas des trames LoRaWAN Physique LoRa MAC Application
Compleacutement drsquoinformation sur les Classes de Devices
Ajout drsquoun paragraphe sur la Gateway utiliseacutee pour le Downlink
Ajout drsquoun paragraphe sur le JSON
Compleacutement drsquoinformation sur le codage en Base64
Ajout drsquoinformation dans le deacutecodage des trames LoRaWAN
Restructuration des explications sur lrsquoenvoi et la reacutecupeacuteration des donneacutees en HTTPMQTT
Version 40 8032019
Ajout drsquoun chapitre Creacuteation de notre propre Application
Ajout drsquoun chapitre Creacuteation de notre propre Network et Application Server
Ajout drsquoune figure Visualisation des Chirps LoRa par SDR (Radio Logicielle)
Compleacutements drsquoinformation sur MQTT
Compleacutements dinformation sur les Topics de TTN en MQTT
| 14
Figure 6 Forme du symbole de base (CHIRP)
En LoRa chaque symbole repreacutesente un certain nombre de bits transmis La regravegle est la suivante
Nombre de bits transmis dans un symbole = Spreading Factor
Par exemple si la transmission utilise un Spreading Factor de 10 (SF10) alors un symbole repreacutesente
10 bits
Crsquoest-agrave-dire qursquoagrave lrsquoeacutemission les bits sont regroupeacutes par paquet de SF bits puis chaque paquet est
repreacutesenteacute par un symbole particulier parmi 2119878119865formes de symboles possibles
Sur la figure suivante voici un exemple theacuteorique drsquoune modulation en SF2 agrave 868 Mhz sur une
bande passante de 125 kHz Chaque symbole repreacutesente donc 2 bits
Figure 7 Symboles eacutemis en Modulation LoRa (Cas theacuteorique en SF2)
Exemple
On considegravere la suite binaire suivante 0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Le Spreading Factor utiliseacute est SF10
Nous regroupons donc les bits par paquet de 10 Chaque paquet de 10 bits sera repreacutesenteacute par un
symbole (sweep) particulier Il y a 1024 symboles diffeacuterents pour coder les 1024 combinaisons
binaires possibles (210)
Freacutequence
Temps
868 000 000 Hz
868 062 500 Hz
Un symbole Un symbole
867 937 500 Hz
Temps
868 000 000 Hz
867 937 500 Hz
Symbole 0
Bits laquo 00 raquo
Symbole 1
Bits laquo 01 raquo
Symbole 2
Bits laquo 10 raquo Symbole 3
Bits laquo 11 raquo
12
5 k
Hz
868 062 500 Hz
| 15
Figure 8 Emission des Chirp en LoRa
Avec un outils drsquoanalyse spectrale actif pendant lrsquoeacutemission LoRa drsquoun Device on peut afficher les
successions de symbole qui sont envoyeacutes Cette oscillogramme a eacuteteacute reacutealiseacute agrave lrsquoaide drsquoun SDR
(Software Digital Radio)
Figure 9 Visualisation des Chirps LoRa reacuteellement eacutemis pendant une transmission
312 Dureacutee drsquoeacutemission drsquoun symbole En LoRa la dureacutee drsquoeacutemission de chaque symbole (Chirp) deacutepend du Spreading Factor utiliseacute Plus le
SF est grand et plus le temps drsquoeacutemission sera long Pour une mecircme bande passante le temps
drsquoeacutemission drsquoun symbole en SF8 est deux fois plus long que le temps drsquoeacutemission drsquoun symbole en
SF7 Ainsi de suite jusqursquoagrave SF12
0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Envoi de 1 Chirp Envoi de 1 Chirp Envoi de 1 Chirp
Transmission Transmission Transmission
| 16
Figure 10 Temps drsquoeacutemission drsquoun symbole (Chirp) en fonction du SF
En revanche le temps drsquoeacutemission drsquoun symbole est inversement proportionnel agrave la bande passante
119879119904 =2119878119865
119861119886119899119889119908119894119889119905ℎ Le deacutebit des symboles est donc de
1
119879119878= 119865119904 =
119861119886119899119889119908119894119889119905ℎ
2119878119865 En toute logique plus la
bande passant est eacuteleveacute plus le deacutebit des symboles sera eacuteleveacute Comme chaque symbole comprend
SF bit on retrouve alors le deacutebit binaire
119863119887 = 119878119865119861119886119899119889119908119894119889119905ℎ
2119878119865
Plus le Spreading Factor sera eacuteleveacute plus le deacutebit binaire sera faible
Plus la Bande Passante sera eacuteleveacutee plus le deacutebit binaire sera fort
Exemple Drsquoapregraves la formule du deacutebit binaire trouver le deacutebit pour les deux cas suivants
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
32 Coding Rate Le Coding Rate est un ratio qui augmentera le nombre de bits agrave transmettre afin de reacutealiser de la
deacutetection correction drsquoerreur Dans le cas drsquoun CR = 4 8 il y aura 8 bits transmis reacuteellement agrave
chaque fois que nous souhaitons transmettre 4 bits Dans cette exemple cela provoque une
transmission drsquoun nombre de bit multiplieacute par 2
SF7
Freacutequence
Temps
Freacutequence centrale
Freacutequence haute
Temps drsquoun symbole eacutemit en SF 12
Freacutequence basse
SF8
SF9
SF10
SF11
SF12
Temps drsquoun symbole eacutemit en SF 11
| 17
Figure 11 Influence du Coding Rate sur le nombre de bits ajouteacute
Si on reprend lrsquoexemple preacuteceacutedent avec un CR de 4 5 nous avons une augmentation de 125 du
nombre de bits agrave transmettre Redonner la deacutebit en prenant en compte le CR
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
La documentation du composant RN2483 donne les deacutebits en fonction du Spreading Factor
la Bande Passante et le Coding Rate Veacuterifier la coheacuterence du reacutesultat avec votre calcul
preacuteceacutedent
Figure 12 Deacutebit en fonction des paramegravetres de la transmission LoRa
33 Utilisation du LoRa Calculator Le logiciel laquo LoRa Calculator raquo est un petit exeacutecutable permettant de simuler une transmission LoRa
en fonction des caracteacuteristiques saisies Canal SF CR etchellip Il est teacuteleacutechargeable agrave lrsquoadresse
suivante httpsbitly2TyloAh
| 18
Figure 13 Le logiciel LoRa Calculator
En reprenant lrsquoexemple preacuteceacutedent (SF7 Bande Passante 125 kHz CR 45) veacuterifier les
calculs du laquo Equivalent Bitrate raquo
34 Time On Air La norme LoRaWAN impose qursquoun Device LoRa ne transmette pas plus de 1 du temps Cela est
repreacutesenteacute par un Duty Cycle Par exemple un Duty Cycle de 1 signifie que si jrsquoeacutemet pendant 1 je
ne dois plus eacutemettre pendant 99 quel que soit lrsquouniteacute de temps utiliseacutee
En reprenant les exemples preacuteceacutedents quels sont les deacutebits moyens si on prend en compte
le laquo Time On Air raquo
Cas 1 Pour SF7 et 125 khz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
Dans le logiciel laquo LoRa Calculator raquo (onglet laquo Energy Profile raquo) nous pouvons estimer la
dureacutee de vie drsquoune batterie Nous prenons lrsquoexemple drsquoun releveacute de tempeacuterature dans un
bacirctiment avec les caracteacuteristiques suivantes
| 19
SF CR Bande Passante etc Nous nous placcedilons dans le cas 1 des exemples preacuteceacutedents
Le releveacute de tempeacuterature se fera toutes les 15 mins
La batterie est constitueacute de 3 petites piles bacirctons [ AAA LR03 ] 12V en seacuterie Soit 36 V
1000 mAh
35 Mise en œuvre LoRa en point agrave point Ce test sera reacutealiseacute avec des modules LoRa RN2483 (Microchip) et une carte microcontrocircleur
ARDUINO
Figure 14 Communication LoRa en Point agrave Point
Reacutealiser le cacircblage de votre module RN2483 suivant le tableau suivant
Connecteur Arduino Click Board RN2483
5V 5V
GND GND
11 RX
10 TX
Tableau 4 Cacircblage de lrsquoARDUINO et de la click Board RN2483
351 Utilisation de lrsquoIDE Arduino Lrsquoenvironnement Arduino est tregraves simple Nous allons reacutealiser un programme pour montrer son
fonctionnement
La connexion de la carte est effectueacutee agrave lrsquoaide drsquoun port USB qui eacutemule une liaison seacuterie
RS232 Il faut donc choisir le bon port Arduino IDE gt Outils gt Port
Pour creacuteer un nouveau programme (sketch) Arduino IDE gt Fichier gt Nouveau
Il y a deux parties dans un sketch
Une fonction setup() qui sera exeacutecuteacutee qursquoune seule fois au deacutemarrage
Une fonction loop() qui sera exeacutecuteacutee en boucle
Ecrire le code suivant
Emetteur
Reacutecepteur
UA
RT
UA
RT
| 20
void setup()
Serialbegin(9600)
void loop()
Serialprintln(hello word)
Compiler et Teacuteleacuteverser Croquis gt Teacuteleacuteverser
Voir la sortie sur la liaison seacuterie Outils gt Moniteur Seacuterie gt Choisir la vitesse de
transmission ici 9600 bauds (en bas agrave droite)
352 Validation du fonctionnement Deux binocircmes joueront le rocircle drsquoeacutemetteur tous les autres binocircmes seront en reacutecepteur
Reacutecupeacuterer les programmes dans Moodle dans le dossier laquo RN2483-Arduino-Point2Point raquo
Installer la librairie RN2483 Arduino IDE gt Croquis gt Inclure une bibliothegraveque gt Ajouter la
bibliothegraveque zip
Reacutepartissez les rocircles Emetteurs Reacutecepteurs et reacutecupeacuterer le programme LoraBlinkerRX ou
LoraBlinkerTX en fonction Les 2 binocircmes en eacutemission devront modifier le code du sketch
Arduino pour transmettre des donneacutees speacutecifiques afin de les diffeacuterencier [
loraSerialprintln(radio tx 30) ]
Validez la reacuteception des donneacutees eacutemises par les deux binocircmes qui transmettent des
donneacutees Ces donneacutees reccedilues sont eacutecrite agrave 57600 bauds sur le moniteur seacuterie de lrsquoArduino
353 Mise en valeur du Spreading Factor On srsquoaperccediloit dans la manipulation preacuteceacutedente que les Devices LoRa reccediloivent les donneacutees des deux
eacutemetteurs Nous allons conserver le mecircme canal drsquoeacutemission (8691 Mhz) mais un des deux
eacutemetteurs va modifier son laquo Spreading Factor raquo La salle sera donc seacutepareacutee en deux groupes
1er groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF7
2egraveme groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF8
Validez la reacuteception des donneacutees eacutemises seulement pour le Spreading Factor que vous
utilisez
| 21
4 Le protocole LoRaWAN
Le LoRa est le type de modulation utiliseacute entre deux Devices ou entre un Device et une Gateway
Lorsque nous parlons de lrsquoensemble de la chaine de communication (Device Gateway Serveur) alors
nous parlons de communication LoRaWAN Nous allons voir lrsquoarchitecture drsquoun reacuteseau LoRaWAN
ainsi que les regravegles de ce protocole
41 Structure drsquoun reacuteseau LoRaWAN Nous retrouvons drsquoun cocircteacute le Device LoRa qui transmet une donneacutee Elle est reacuteceptionneacutee agrave lrsquoautre
extreacutemiteacute du reacuteseau par un Utilisateur La structure globale du reacuteseau LoRaWAN peut ecirctre
repreacutesenteacutee par la figure suivante
411 Les Devices LoRa Les Devices LoRa sont des systegravemes eacutelectroniques appartenant au monde de lrsquoIoT Faible
consommation faible taille faible puissance et faible taille
Ils possegravedent une radio LoRa permettant de joindre les Gateways Les Gateways ne sont pas
adresseacutees speacutecifiquement toutes celles preacutesentes dans la zone de couverture reccediloivent les
messages et les traitent
412 Les Gateways LoRa Elles eacutecoutent sur tous les canaux et sur tous les Spreading Factor Lorsqursquoune trame LoRa est reccedilue
elle transmet son contenu sur internet agrave destination du Network Server qui a eacuteteacute configureacute dans la
Gateway au preacutealable
Elle joue donc le rocircle de passerelle entre une modulation LoRa et une communication IP
Devices
LoRa Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
Internet Internet
Figure 15 Structure globale dun reacuteseau LORAWAN
| 22
Chaque Gateway LoRa possegravede un identifiant unique (EUI sur 64 bits)
413 Le Network Server
Le Network Server reccediloit les messages transmis par les Gateways et supprime les doublons
(plusieurs Gateway peuvent avoir reccedilu le mecircme message) Les informations transmises au Network
Server depuis les Devices LoRa sont authentifieacutes gracircce agrave une cleacute AES 128 bits appeleacutee Network
Session Key NwkSKey Nous parlons bien ici drsquoauthentification et non pas de chiffrement comme
nous le verrons plus tard
414 Application Server Il est souvent sur le mecircme support physique que le Network Server Il permet de dissocier les
applications les unes des autres Chaque application enregistre des Devices LoRa qui auront le droit
Devices Gateways Network
Server
Internet
Network Session Key (NwkSKey)
Authentification
Figure 17 Authentification entre le Device LoRa et le Network Server
Internet
UDP IP
Modulation
LoRa
Device LoRa
Gateway
Network Server
LoRaWAN
Modulation
LoRa
Passerelle LoRa Internet
Internet
UDP IP
LoRaWAN
Transmission Radio
Application Application
Figure 16 Le rocircle de la Gateway LoRa
| 23
de stocker leurs donneacutees (Frame Payload) Les message transmis agrave lrsquoapplication server sont chiffreacutes
gracircce agrave une cleacute AES 128 bits appeleacutee Application Session Key AppSKey
Le scheacutema suivant reacutesume lrsquoutilisation
De la Network Session Key (NwkSKey) pour lrsquoauthentification entre le Device LoRa et le
Network Server
De lrsquoApplication Session Key (AppSKey) pour le chiffrement entre le Device LoRa et
lrsquoApplication Server
Devices Gateways Network
Server Application
Server
Internet
Application Session Key (AppSKey)
Chiffrement
Figure 18 Chiffrement entre le Device LORA et lrsquoApplication Server
| 24
415 Application Web Serveur Cette application doit drsquoune part reacutecupeacuterer les donneacutees de lrsquoApplication Serveur Dans le cadre de
ce cours cela sera fait de deux faccedilons
Avec le protocole HTTP
Avec le protocole MQTT
Figure 20 Application Web Server
Figure 19 Authentification et chiffrement en LoRaWan
Devices Gateways
Network
Server Application
Server
Internet
Network Session Key
Application Session Key
Network
Server Application
Server
Application
Server Web
Utilisateur
Protocole
MQTT ou HTTP
Flux Uplink
Flux Downlink
| 25
Le flux habituel dans lrsquoIoT est le flux Uplink (flux montant) crsquoest-agrave-dire lrsquoeacutemission de donneacutees des
objets vers le serveur Comme nous lrsquoexpliquerons plus loin en LoRaWAN il est aussi possible de
transfeacuterer des donneacutees aux Device LoRa par un flux Downlink (flux descendant)
Drsquoautre part lrsquoapplication mettra agrave disposition les donneacutees aux utilisateurs sous forme par exemple
drsquoun serveur web drsquoune base de donneacutees et drsquoune visualisation graphique
416 Authentification avec le Network Server La Network Session Key (NwkSKey) sert agrave lrsquoauthentification entre le Device LoRa e le Network Server
Afin de reacutealiser cette authentification entre le Device et le Network Server un champ MIC (Message
Integrity Control) est rajouteacute agrave la trame Il est calculeacute en fonction des donneacutees transmises et du
NwkSkey A la reacuteception le mecircme calcul est effectueacute Si les cleacutes sont eacutequivalentes dans le Device et
dans le Network Server alors les deux MIC calculeacutes doivent correspondre
417 Chiffrement des donneacutees vers lrsquoApplication Server
LrsquoApplication Session Key (AppSKey) sert pour le chiffrement entre le Device LoRa et lrsquoApplication
Server Les donneacutees chiffreacutees seront alors deacutecodeacutees agrave la reacuteception sur lrsquoApplication Server srsquoil
possegravede la mecircme cleacute Si on reprend le scheacutema preacuteceacutedent les laquo donneacutees x raquo sont chiffreacutees
deacutechiffreacutees par le processus suivant
Donneacutees x chiffreacutees NwkSkey x
MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees
NwkSkey x
Trame eacutemise Trame reccedilue
Device LoRa Network Server
Si =
Alors la trame est authentifieacutee
MIC geacuteneacutereacute Emission MIC geacuteneacutereacute Reacuteception
MIC geacuteneacutereacute Reacuteception
Figure 21 Authentification dun Device LoRa par le Network Server
| 26
Figure 22 Chiffrement des donneacutees par lApplication Session Key
418 Combinaison de lrsquoauthentification et du chiffrement On peut maintenant repreacutesenter sur le mecircme scheacutema la construction de la trame LoRaWAN avec
drsquoune part lrsquoauthentification et drsquoautre part le chiffrement
Figure 23 Chiffrement puis Authentification
42 Classes des Devices LoRaWAN Les Devices LoRa sont classeacutes en 3 cateacutegories (A B C) en fonction de leur consommation et de leur
accessibiliteacute en Downlink crsquoest-agrave-dire la faciliteacute qursquoun utilisateur aura agrave transmettre une trame au
Device LoRa
421 Classe A (All) Minimal power Application Tous les Devices LoRaWAN sont de classe A Chaque Device peut transmettre (Uplink) agrave la Gateway
sans veacuterification de la disponibiliteacute du reacutecepteur Si la transmission eacutechoue elle sera reacuteeacutemise apregraves
un certain temps Cette transmission est suivie de 2 fenecirctres de reacuteception tregraves courtes La Gateway
peut alors transmettre pendant le laquo RX Slot 1 raquo ou le laquo RX Slot 2 raquo mais pas les deux
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Device LoRa
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Application Server
Donneacutees non chiffreacutees
AppSKey
Donneacutees chiffreacutees Entecircte
NwkSKey
MIC geacuteneacutereacute en eacutemission Trame transmise =
| 27
Figure 24 Slots de reacuteception pour un Device LoRa de classe A
Source de lrsquoimage httpszakelijkforumkpncom
La dureacutee des fenecirctres doit ecirctre au minimum la dureacutee de reacuteception drsquoun preacuteambule Un preacuteambule
dure 1225 Tsymbole et deacutepend donc du Data Rate (DR voir paragraphe 445 pour plus drsquoinformation
sur le DR) Lorsque qursquoun preacuteambule est deacutetecteacute le reacutecepteur doit rester actif jusqursquoagrave la fin de la
transmission Si la trame reccedilue pendant la premiegravere fenecirctre de reacuteception eacutetait bien agrave destination du
Device LoRa alors la deuxiegraveme fenecirctre nrsquoest pas ouverte
Premiegravere fenecirctre de reacuteception
Le Slot RX1 est programmeacute par deacutefaut agrave 1 seconde + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont les mecircme que ceux choisis lors de la phase drsquoeacutemission
(Uplink)
Seconde fenecirctre de reacuteception
Le Slot RX2 est programmeacute par deacutefaut agrave 2 secondes + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont configurables mais fixes
Un Device LoRa qui est uniquement de classe A ne peut pas recevoir srsquoil nrsquoa pas eacutemis Il
nrsquoest donc pas joignable facilement
422 Classe B (Beacon) Scheduled Receive Slot Les Devices de classe B ont le mecircme comportement que les Devices de classe A mais drsquoautres
fenecirctres de reacuteceptions sont programmeacutees agrave des peacuteriodes preacutecises Afin de synchroniser les fenecirctres
de reacuteception du Device LoRa la Gateway doit transmettre des balises (Beacons) de faccedilon reacuteguliegravere
| 28
Figure 25 Slots de reacuteception pour un Device LoRa de classe B
Source de lrsquoimage httpszakelijkforumkpncom
Un Device LoRa de classe B est joignable reacuteguliegraverement sans qursquoil soit neacutecessairement
obligeacute drsquoeacutemettre En revanche il consomme plus qursquoun Device de classe A
423 Classe C (Continuous) Continuously Listening Les Devices de classe C ont des fenecirctres de reacuteception constamment ouvertes entre 2 Uplinks Ces
Devices consomment donc beaucoup plus
Figure 26 Slots de reacuteception pour un Device LoRa de classe C
Source de lrsquoimage httpszakelijkforumkpncom
| 29
Un Device LoRa de classe C est joignable en permanence En revanche crsquoest la classe de
Device qui est la plus eacutenergivore
424 Quelle Gateway pour les flux Downlink
Nous avons donc vu que le fonctionnement classique du protocole LoRaWAN eacutetait de reacutecupeacuterer de
lrsquoinformation depuis le Device LoRa Crsquoest le flux Uplink
Dans le cas ougrave lrsquoutilisateur transmet des informations au Device LoRa (flux Downlink) on peut se
demander quelle Gateway sera choisie pour transfeacuterer les donneacutees au Device LoRa En effet
lrsquoendroit ougrave est situeacute le Device LoRa nrsquoest pas neacutecessairement connu agrave lrsquoavance
La Gateway utiliseacutee pour le Downlink est celle qui a reccedilu le dernier message du Device
LoRa Un message ne pourra jamais arriver agrave destination drsquoun Device LoRa si celui-ci nrsquoa
jamais transmis quel que soit sa classe A B ou C
43 Activation des Devices LoRa et seacutecuriteacute En LoRaWAN les trois eacuteleacutements indispensables pour la communication sont le DevAddr pour
lrsquoindentification du Device ainsi que deux cleacutes le NwkSKey pour lrsquoauthentification et lrsquoAppSKey
pour le chiffrement Deux meacutethodes sont possibles pour fournir ces informations agrave la fois au Device
LoRa et au serveur
Activation By Personalization APB
Over The Air Activation
431 ABP Activation By Personalization Crsquoest la plus simple des meacutethodes Crsquoest donc peut ecirctre celle que nous avons tendance agrave utiliser lors
drsquoun test de prototype et drsquoune mise en place de communication LoRaWAN
Le Device LoRa possegravede deacutejagrave le DevAddr lrsquoAppSKey et le NwkSKey
Le Network server possegravede deacutejagrave le DevAddr et le NwkSKey
Lrsquoapplication serveur possegravede deacutejagrave le DevAddr et le AppSKey
En ABP toutes les informations neacutecessaires agrave la communication sont deacutejagrave connues par le
Device LoRa et par le Serveur
| 30
432 OTAA Over The Air Activation Crsquoest la meacutethode qursquoil faut privileacutegier car crsquoest celle qui est la plus seacutecuriseacutee Le Device LoRa doit
connaitre le DevEUI lrsquoAppEUI et lrsquoAppkey Le Network Server doit lui connaitre la mecircme Appkey
Tous les eacuteleacutements noteacutes EUI (Extended Unique Identifier) sont toujours sur une taille de
64 bits
Gracircce agrave ces informations de deacutepart et une neacutegociation avec le Network Server (Join Request) le
Device LoRa et le serveur vont geacuteneacuterer les informations essentielles DevAddr NwkSKey et
AppSKey
Figure 28 Obtention du DevAddr NwkSKey et AppSKey en OTAA
DevEUI Unique Identifier pour le device LoRa (Equivalent agrave une MAC sur Ethernet)
Certains Device LoRa ont deacutejagrave un DevEUI fourni en usine
AppEUI Unique Identifier pour lrsquoapplication server
DevEUI
AppEUI
AppKey
Join
Request
DevAddr
NwkSKey
AppSKey
Network Server
Application Server
Devices 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 2
NwkSkey 2
AppSKey 2
Devices 2
DevAddr 2
NwkSkey 2
AppSKey 2
Paramegravetres stockeacutes sur le serveur
Paramegravetres programmeacutes
dans le composant
Figure 27 Parameacutetrage de DevAddr NwkSKey et AppSKey
| 31
AppKey AES 128 cleacute utiliseacutee pour geacuteneacuterer le MIC (Message Code Integrity) lors de la Join
Resquest Il est partageacute avec le Network server
NwkSKey Utiliseacute pour lrsquoauthentification avec le Network Server
AppSKey Utiliseacute pour le chiffrement des donneacutees
433 Seacutecuriteacute Les cleacutes AES 128 bits permettent le chiffrement des informations transmises en LoRaWAN Malgreacute
ce chiffrement une attaque connue en Wireless est celle du REPLAY Crsquoest-agrave-dire que le Hacker
enregistre des trames chiffreacutees circulant sur le reacuteseau LoRa pour les reacuteeacutemettre plus tard Mecircme si
le Hacker ne comprend pas le contenu (les trames sont chiffreacutees) les donneacutees qui sont transporteacutees
sont elles bien comprises par lrsquoApplication Server Des actions peuvent donc ecirctre reacutealiseacutees
simplement par mimeacutetisme
Pour eacuteviter cela la trame LoRaWAN integravegre un champ variable appeleacute laquo Frame Counter raquo Il srsquoagit
drsquoun nombre numeacuterotant la trame sur 16 ou 32 bits LrsquoApplication Server acceptera une trame
uniquement si le laquo Frame Counter raquo reccedilu est supeacuterieur au laquoFrame Counter raquo preacuteceacutedemment Donc
si le Hacker retransmet la trame telle qursquoelle le laquo Frame Counter raquo sera eacutequivalent donc la trame
sera refuseacutee Et comme la trame est chiffreacutee le Hacker nrsquoa pas moyen de savoir comment modifier
un champ de cette trame
Cette seacutecuriteacute impleacutementeacutee par les laquo Frame Counter raquo est inteacuteressante pour srsquoaffranchir drsquoune
attaque par REPLAY mais dans nos tests cela peut poser problegraveme En effet agrave chaque fois que nous
redeacutemarrons le microcontrocircleur notre laquo Frame Counter raquo revient agrave zeacutero alors que celui de
lrsquoApplication Server continue de srsquoincreacutementer Cela peut ecirctre reacutesolue par diffeacuterentes maniegraveres
1 Deacutesactivation du laquo Frame Counter Check raquo Dans certain Application Server cette option
peut ecirctre proposeacutee Bien sucircr il faudra garder en tecircte la faille de seacutecuriteacute que cela engendre
Network Server
Application Server
Devices LoRa
NwkSkey
AppSKey
NwkSkey
AppSKey Hacker
(1) (2)
(1) Ecoute
(2) Reacuteeacutemission
Figure 29 Attaque par REPLAY
| 32
Figure 30 Deacutesactivation du Frame Counter Check dans TTN
2 Utiliser lrsquoauthentification par OTAA au lieu de ABP En effet agrave chaque ouverture de session
en OTAA le laquo Frame Counter raquo est reacuteinitialiseacute coteacute serveur
3 Conserver la valeur du laquo Frame Counter raquo dans une meacutemoire non volatile et reacutecupeacuterer sa
valeur au deacutemarrage du Device LoRa
44 La Trame LoRa LoRaWAN
441 Les couches du protocole LoRaWAN
Lorsque nous avons fait une communication en Point agrave Point nous avons simplement utiliseacute la
couche physique de la modulation LoRa Lorsque nous souhaitons utiliser le protocole LoRaWAN
des couches protocolaires suppleacutementaires se rajoutent
Figure 31 Les couches protocolaires du LoRaWAN
Chaque couche rajoute un service Lors de lrsquoenvoi de la trame les donneacutees utilisateurs sont donc
encapsuleacutees dans chaque couche infeacuterieure jusqursquoagrave la transmission Le deacutetail de lrsquoensemble de la
trame LoRaWAN par couche est deacutecrit sur la figure Figure 32
LoRa Modulation
LoRa Mac
Application
Couche Physique
Couche Mac
Couche Application
| 33
442 Couche Application La couche Application accueille les donneacutees de lrsquoutilisateur Avant de les encapsuler elles sont
chiffreacutees avec lrsquoAppSKey afin de seacutecuriser la transaction
Un ensemble de champs nommeacute Frame Header permet de speacutecifier le DevAddr le Frame Control
le Frame Counter et le Frame Option
Le Frame Port deacutepend du type drsquoapplication et sera choisi par lrsquoutilisateur
Le Frame Payload sont les donneacutees chiffreacutees agrave transmettre Le nombre drsquooctets maximum pouvant
ecirctre transmis (N octets) est donneacute dans le tableau suivant
PHY Payload
P octets Couche
Physique
Couche
Mac
Couche
Application
CRC
2 octets Header + Header CRC
20 bits Preamble
MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Figure 32 Trame LORAWAN complegravete par couche protocolaire
Couche
Application Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Frame Header
Figure 33 Trame LORA couche Applicative
| 34
Data Rate Spreading Factor Bandwidth Max Frame Payload (Nombre N) DR 0 SF12 125 KHz 51 octets
DR 1 SF11 125 KHz 51 octets
DR 2 SF10 125 KHz 51 octets
DR 3 SF9 125 KHz 115 octets
DR 4 SF8 125 KHz 222 octets
DR 5 SF7 125 KHz 222 octets
DR 6 SF7 250 KHz 222 octets
Tableau 5 Taille maximum du Frame Payload en fonction du Data Rate
443 Couche LoRa MAC Cette trame est destineacutee au Network Server Elle est authentifieacutee gracircce au champ MIC (Message
Integrity Protocol) selon la meacutethode expliqueacutee au paragraphe 416
Le protocole LoRa MAC est composeacute de
1 MAC Header Version de protocole et type de message
Type de Message Description 000 Join-Request
001 Join-Accept
010 Unconfirmed Data Up
011 Unconfirmed Data Down
100 Confirmed Data Up
101 Confirmed Data Down
110 Rejoin-request
111 Proprietary
Tableau 6 Les types de messages transmis en LoRaWAN
2 MAC Payload Contient tout le protocole applicatif
3 MIC Message Integrity Code pour lrsquoauthentification de la trame
444 Couche physique Modulation LoRa
Le choix du moment drsquoeacutemission des Devices LoRa se fait de faccedilon simple Lorsqursquoun eacutequipement
doit eacutemettre il le fait sans controcircle et ne cherche pas agrave savoir si le canal est libre Si le paquet a eacuteteacute
perdu il le retransmettra simplement au bout drsquoun temps aleacuteatoire La couche physique est
repreacutesenteacutee par lrsquoeacutemission de la trame suivante
Couche
Mac MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Figure 34 Trame LORA couche LORA MAC
| 35
Le Preacuteambule est repreacutesenteacute par 8 symboles + 425 Le temps du Preacuteambule est donc de 1225
Tsymbole
Len-tecircte (Header optionnel) est seulement preacutesent dans le mode de transmission par deacutefaut
(explicite) il est transmis avec un Coding Rate de 48 Il indique la taille des donneacutees le Coding Rate
pour le reste de la trame et il preacutecise eacutegalement si un CRC sera preacutesent en fin de trame
Le PHY Payload contient toutes les informations de la Couche LoRa MAC
Le CRC sert agrave la deacutetection drsquoerreur de la trame LoRa
445 Canaux et bandes de freacutequences et Data Rate (DR) Le LoRa utilise des bandes de freacutequences diffeacuterentes suivant les reacutegions du monde En Europe la
bande utiliseacutee est celle des 868 Mhz [ De 863 Mhz agrave 870 Mhz ] Le LoRaWAN deacutefinie les 8 canaux agrave
utiliser pour communiquer avec une Gateway suivant le tableau suivant
Canaux Spreading Factor Bandwidth 8681 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz SF7 250 kHz
8685 Mhz De SF7 agrave SF12 125 kHz
8671 Mhz De SF7 agrave SF12 125 kHz
8673 Mhz De SF7 agrave SF12 125 kHz
8675 Mhz De SF7 agrave SF12 125 kHz
8677 Mhz De SF7 agrave SF12 125 kHz
8679 Mhz De SF7 agrave SF12 125 kHz
Tableau 7 Canaux SF et Bandwidth de notre Gateway LoRaWAN
Une Gateway LoRa eacutecoute donc sur 8 canaux simultaneacutement avec les 6 Spreading Factor
diffeacuterents soit 48 combinaisons possibles
Comme nous lrsquoavons vu le Spreading Factor a des conseacutequences sur le deacutebit de la transmission Ces
deacutebits sont noteacutes DR (Data Rate) et sont normaliseacutes de DR0 agrave DR6
PHY Payload
P octets Couche
Physique CRC
2 octets Header + Header CRC
( Optionnel ) 20 bits Preamble
Figure 35 Trame LORA couche Physique
| 36
Data Rate Spreading Factor Bandwidth DR 0 SF12 125 KHz
DR 1 SF11 125 KHz
DR 2 SF10 125 KHz
DR 3 SF9 125 KHz
DR 4 SF8 125 KHz
DR 5 SF7 125 KHz
DR 6 SF7 250 KHz
Tableau 8 Deacutenomination DR en fonction du SF et de la Bande Passante
446 Trame reccedilue et transmise par la Gateway LoRaWAN La Gateway reccediloit drsquoun cocircteacute un message radio moduleacute en LoRa et transmet de lrsquoautre cocircteacute une trame
IP agrave destination du Network Server
Coteacute interface Radio La Gateway reacuteceptionne une trame LoRaWAN et extrait le PHY Payload Celui-
ci est codeacute au format ASCII en base 64 (voir le paragraphe 541) La Gateway extrait aussi toutes les
informations utiles sur les caracteacuteristiques de la reacuteception qui a eu lieu SF Bandwidth RSSI Time
On Airhellipetchellip
Coteacute interface reacuteseau IP La Gateway transmet lrsquoensemble de ces informations dans un paquet IP
(UDP) au Network Server Les donneacutees transmises sont du texte en format JSON (voir paragraphe
447) La Gateway a donc bien un rocircle de passerelle entre le protocole LoRa drsquoun cocircteacute et un reacuteseau
IP de lrsquoautre
Internet
UDP IP
Device LoRa
Gateway
Network Server Modulation
LoRa
Passerelle LoRa Internet
Transmission Radio Internet
Figure 36 Rocircle de la Gateway LoRa
| 37
447 Le format JSON Le format JSON est un format texte composeacute drsquoune succession de couple nomvaleur Dans
lrsquoexemple de la figure preacuteceacutedente gw_id est un nom et eui-b827ebfffeae26f5 est la valeur
associeacutee Dans cette exemple la valeur est un string Les objets sont deacutelimiteacutes par un des accolades
et
Une valeur peut ecirctre
Un string exemple coding_rate 45
Un nombre exemple spreading_factor 12
Un objet exemple lora spreading_factor 12 air_time 2465792000
Un Boolean
Ethernet
Gateway
Modulation
LORA
Reacutecupeacuteration du PHY PAYLOAD en base 64
Reacutecupeacuteration des caracteacuteristiques de la transmission Canal SF CR hellip
IP (IP dest routereuthethingsnetwork)
UDP (Port dest 1700 Port source 1700)
Donneacutees applicatives (format JSON)
gw_id eui-b827ebfffeae26f5
payload QNAPvA6Ax3ECqHk4C8hfzuA==
lora
spreading_factor 12
bandwidth 125
air_time 2465792000
coding_rate 45
timestamp 2019-01-20T133746017Z
rssi -105
snr -162
dev_addr 0EBC0FD0
frequency 867100000
Internet Transmission Radio LORA
Figure 37 Passerelle (Gateway) LORAWAN
| 38
5 Mise en œuvre drsquoun reacuteseau LoRaWAN
51 Les diffeacuterents types de reacuteseaux Les reacuteseaux LoRaWAN peuvent ecirctre utiliseacute suivant deux meacutethodes
En utilisant les reacuteseaux LoRaWAN opeacutereacutes proposeacutes par les opeacuterateurs de teacuteleacutecoms
En utilisant votre propre reacuteseau LoRaWAN priveacute
511 Les reacuteseaux LoRaWAN opeacutereacutes Ce sont des reacuteseaux LoRaWAN proposeacutes par les opeacuterateurs Par exemple Objenious (filiale de
Bouyges) ou encore Orange Dans le cas de lrsquoutilisation des reacuteseaux opeacutereacutes lrsquoutilisateur a juste
besoin de srsquooccuper des Devices LoRa Les Gateways le Network Server et lrsquoApplication Server sont
geacutereacutes par lrsquoopeacuterateur
512 Les reacuteseaux LoRaWAN priveacutes Chacun est libre de reacutealiser son propre reacuteseau priveacute en impleacutementant sa propre Gateway pour
communiquer avec ses Devices LoRa Lrsquoimpleacutementation du Network Server et de lrsquoApplication Server
peuvent alors ecirctre envisageacutes de diffeacuterentes faccedilons
Network Server et Application serveur priveacutees Crsquoest le deacuteveloppeur qui les mets en place Dans
certaines Gateways une impleacutementation de ces deux serveurs est deacutejagrave proposeacutee Sinon il est
possible de la mettre en place Il existe des serveurs (Network et Application) open source crsquoest le
cas par exemple de LoRa Serveur [ wwwloraserverio ]
Une autre alternantive est httpsgithubcomgotthardplorawan-server
LoRaServer et lorawan-server sont deux applications Open Source
Network Server et Application Server en ligne Un certain nombre de Network Server et
drsquoApplication Server sont proposeacutes Ce sont des services payants ou avec des contreparties
Loriot [ wwwloriotio ]
ResIoT [ wwwresiotio ]
The Things Network [ wwwthethingsnetworkorg ] Crsquoest la solution que nous utiliserons
513 Les zones de couvertures
Les zones de couvertures des reacuteseaux opeacutereacutes sont mise agrave jour par les opeacuterateurs celle drsquoobjenious
est par exemple disponible ici httpsobjeniouscomreseau
Pour connaitre la zone de couverture de notre Gateway utiliseacutee avec TTN nous pouvons utiliser
lrsquoapplication TTN Mapper httpsttnmapperorg Lrsquoideacutee est de promener son Device LoRa associeacute
agrave un GPS dans la zone de couverture des Gateway qui nous entourent A chaque trame reccedilue par le
| 39
Serveur on note les coordonneacutees GPS du Device LoRa ainsi que la Gateway qui a transmis le
message Toutes ces informations sont alors retranscrites sur une carte
52 The Things Network (TTN)
521 Preacutesentation de TTN
Pour la suite nous utiliserons le Network Server et lrsquoApplication Server fourni par TTN
[wwwthethingsnetworkorg]
TTN est gratuit et Open Source En revanche le fait drsquoutiliser TTN impose agrave ceux qui enregistrent
des Gateways de les mettre agrave disposition agrave tous les autres utilisateurs de TTN Lrsquoobjectif est de
reacutealiser un reacuteseau global ouvert
522 Configuration de la Gateway A lrsquouniversiteacute nous avons deux Gateways LoRa (Marque EBDS) Elles sont toutes les deux situeacutees sur
le Campus de Technolac Une Gateway est agrave lrsquointeacuterieur du bacirctiment ISERAN et sert essentiellement
pour les Travaux Pratiques et formations Lrsquoautre est sur le toit du bacirctiment Chablais et est mise agrave
disposition du public via le service de TTN
Les deux Gateway eacutecoutent sur tous les canaux et sur tous les Spreading Factor SF7 gt SF12
Lrsquo IP de la Gateway LoRa agrave lrsquouniversiteacute (bacirctiment ISERAN) est 192168140196
Serveur DNS 1934812032 19348129137
Network Server (TTN) 137616868 routereuthethingsnetwork
Port Upstream 1700 Port Downstream 1700
523 Enregistrement des Gateways Appplication et Devices La configuration de TTN se fait en ligne La premiegravere opeacuteration agrave reacutealiser lorsqursquoune nouvelle
Gateway est deacuteployeacutee crsquoest de lrsquoenregistrer dans TTN
Enregistrement drsquoune Gateway LoRa TTN gt Console gt Gateway gt register gateway
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Figure 38 Scheacutema de notre application
| 40
Figure 39 Enregistrement dune Gateway LoRa sur TTN
Enregistrement drsquoune application TTN gt Console gt Application gt add application
Figure 40 Enregistrement dune application sur TTN
Enregistrement des Devices LoRa dans lrsquoapplication Nom de lrsquoapplication gt register device
Figure 41 Enregistrement des Devices LoRa dans une application
524 Configuration des Devices LoRa Lorsque nous avons enregistreacute des Devices LoRa dans TTN nous devons choisir entre les deux modes
drsquoauthentification Dans un premier temps nous utiliserons le mode le plus simple qui est ABP Nous
geacuteneacuterons dans TTN les DevAddr NetwkSKey et AppSKey
| 41
Figure 42 Configuration des Devices LoRa en ABP dans TTN
53 Mise en application Nous avons dans notre application 10 Devices LoRa drsquoenregistreacutes aduino0 agrave arduino9 Ils sont tous
configureacutes en ABP Les configurations des 10 Devices (DevAddr NetwkSKey et AppSKey) sont noteacutes
en commentaire dans le code de vous allez reacutecupeacuterer
Reacutecupeacuterer le code Arduino laquo RN2483-Arduino-LORAWANino raquo dans Moodle
Modifier votre configuration (DevAddr NetwkSKey et AppSKey) en fonction de votre
numeacutero de binocircme
Veacuterifier que votre Device LoRa arrive bien agrave transmettre des informations (Uplink) vers la
Gateway puis vers le Network Serveur de TTN (The Things Network)
54 Analyse des trames eacutechangeacutees
541 Utilisation de la base 64 Notre Gateway nous preacutesente le Payload PHY en base64 Lrsquoexplication de la meacutethode de
repreacutesentation en base 64 est fourni au travers drsquoun exemple Le code hexadeacutecimal 0x4869
repreacutesente nos donneacutees binaires que nous souhaitons transmettre en base 64
1 On eacutecrit les donneacutees agrave transmettre en binaire
2 On regroupe les eacuteleacutements binaires par des blocs de 6 bits Le nombre de bloc de 6 bits doit
ecirctre un multiple de 4 (minimum 4 blocs) Srsquoil manque des bits pour constituer un groupe de
6 bits on rajoute des zeacuteros
0x4869 = 0100 1000 0110 1001
| 42
3 Srsquoil manque des blocs pour faire un minimum de 4 blocs des caractegraveres speacuteciaux seront
ajouteacutes
4 Chaque groupe de 6 bits est traduit par le tableau suivant (Source Wikipeacutedia)
Figure 43 Codage en base 64
5 Si un bloc de 6 bits manque (ils doivent ecirctre un multiple de 4) on rajoute un ou plusieurs
compleacutements (caractegravere laquo = raquo )
Reacutesultat Le codage de 0x4869 en base 64 est laquo SGk= raquo
010010 000110 100100
On ajoute 00 pour avoir
6 bits dans le groupe
Bloc de 6 bits
010010 000110 100100
S G k
010010 000110 100100
S G k =
1er Bloc
2egraveme Bloc
3egraveme Bloc
4egraveme Bloc
| 43
542 Inteacuterecirct et inconveacutenient de la base 64 Lrsquoutilisation de la base 64 est un choix qui a eacuteteacute fait pour le protocole LoRa LoRaWAN afin de rendre
les donneacutees binaires lisibles Le problegraveme du code ASCII crsquoest qursquoil est composeacute drsquoun certain nombre
de caractegraveres non imprimables (EOF CR LFhellip) Pour eacuteviter ces soucis la base 64 ne comporte que
64 caractegraveres imprimables (voir tableau ci-dessus)
La restriction agrave 64 caractegraveres a cependant un inconveacutenient crsquoest que nous ne pouvons coder que 6
bits (26=64) au lieu de 8 La base 64 est donc moins efficace drsquoune faccedilon geacuteneacuterale
Nous cherchons agrave coder le code ASCII laquo AA raquo en base 64 Retrouver la deacutemarche en
montrant que le reacutesultat en base 64 est laquo QUE= raquo
543 Uplink Du Device LoRa au Network Server Le Network Server de TTN reccediloit des trames IP en provenance de la Gateway Comme nous lrsquoavons
vu preacuteceacutedemment un certain nombre drsquoinformations peuvent ecirctre retrouveacutees avec cette trame
(DevAddr SF Bandwidth etchellip) mais les donneacutees Applicatives sont bien sucircr chiffreacutees (avec
lrsquoAppkSKey) A ce niveau de reacuteception (sans connaitre lrsquoAppSKey) il nrsquoest donc pas possible de
comprendre la totaliteacute du message reccedilu
Imaginons que la trame IP reccedilue 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 45
timestamp 2019-03-05T140042448Z
rssi -82
snr 9
dev_addr 26011AD3
frequency 867300000
Le Network Server affiche donc les informations de la faccedilon suivante
Figure 44 Trame reacutecupeacutereacutee sur le laquo Network Server raquo de TTN
Nous retrouvons bien les valeurs fournies par la Gateway
timestamp ( agrave 1 heure pregraves en fonction du fuseau horaire)
| 44
frequency 8673 Mhz
modulation Lora
Coding Rate 45
data Rate SF 7 125 kHz (DR5)
air time 463 ms
Drsquoautres information proviennent de lrsquoanalyse du Payload Le Payload inscrit ici est le PHY Payload
Il y a donc une partie chiffreacutee (Frame Payload) mais les entecirctes sont en claires (voir paragraphe
441) Ce PHY Payload est laquo QNMaASYABwAP1obuUHQ= raquo Lorsque celui-ci est exprimeacute en
hexadeacutecimal au lieu de la base 64 il vaut laquo 40D31A01260007000FD686EE5074 raquo comme le montre
le Network Server de TTN
Figure 45 PHY Payload preacutesenteacute dans notre Network Server
Sa taille est bien de 14 octets (en hexadeacutecimal) comme preacuteciseacute sur la Figure 44
Nous reprenons le format de la trame LoRaWAN vu agrave la Figure 32 Nous pouvons alors retrouver
tous les champs de toute la trame
PHYPayload = 40D31A01260007000FD686EE5074
PHYPayload = MAC Header[1 octet] | MACPayload[] | MIC[4 octets]
MAC Header = 40 (Unconfirmed data up)
MACPayload = D31A01260007000FD6
Message Integrity Code = 86EE5074
MACPayload = Frame Header | Frame Port | FramePayload )
Frame Header = D31A0126000700
FPort = 0F
FramePayload = D6
Frame Header = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[015]
DevAddr = 26011AD3 (Big Endian)
FCtrl (Frame Control) = 00 (No ACK No ADR)
FCnt (Frame Counter) = 0007 (Big Endian)
FOpts (Frame Option) =
Vous pouvez veacuterifier lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN
(LoRaWAN packet decoder) httpsbitly2szdXtv
| 45
Figure 46 LoRaWAN packet decoder
544 Uplink Du Network Server agrave lrsquoApplication Server
Nous reprenons lrsquoexemple de la trame ci-dessus (Figure 45) Pour information les cleacutes NwkSKey et
AppSKey suivantes ont eacuteteacute utiliseacutee
NwkSKey E3D90AFBC36AD479552EFEA2CDA937B9
AppSKey F0BC25E9E554B9646F208E1A8E3C7B24
Le Network Server a deacutecodeacute lrsquoensemble de la trame Si le MIC est correct (authentification de la
trame par le NwkSKey) alors le Network Server va passer le contenu du message chiffreacute (Frame
Payload) agrave lrsquoApplication Server Dans notre cas le Frame Payload est (drsquoapregraves le deacutecodage effectueacute
au chapitre preacuteceacutedent)
FramePayload = D6
D6 est le contenu chiffreacute lorsqursquoil est deacutechiffreacute avec lrsquoAppSkey on trouve 01 Vous pouvez veacuterifier
lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN httpsbitly2szdXtv
A noter que lrsquoApplication Server recevra les donneacutees chiffreacutees seulement si le Device LoRa a bien
eacuteteacute enregistreacute On peut aussi veacuterifier ci-dessous que lrsquoApplication Serveur de TTN nous retourne bien
un payload (Frame Payload) de 01
Figure 47 Trame reacutecupeacutereacutee sur lrsquoApplication Server de TTN
time 2019-03-05T140042379279991Z
frequency 8673
modulation LORA
data_rate SF7BW125
coding_rate 45
gateways [
gtw_id eui-b827ebfffeae26f6
timestamp 2447508531
time
channel 4
rssi -82
snr 9
latitude 4563647
longitude 58721523
| 46
location_source registry
]
545 Simulation drsquoUplink dans lrsquoApplication Server
Dans beaucoup de situations nous souhaitons valider le fonctionnement de lrsquoApplication Server de
TTN ouet de notre propre Application Il est donc tregraves utile de pouvoir simuler lrsquoenvoi drsquoune trame
LoRa sur lrsquoApplication Server sans que celle-ci soit reacuteellement eacutemise par un Device LoRa Pour cela
un outil existe dans les Settings de chaque Device enregistreacute dans TTN Nous avons juste besoin de
speacutecifier le Frame Payload en clair en hexadeacutecimal et le numeacutero de Port
Figure 48 Simulation drsquoune trame envoyeacutee par un Device LoRa
546 Downlink De lrsquoApplication Server au Device LoRa La communication LoRa est bidirectionnelle Des donneacutees peuvent ecirctre transmis au Device LoRa
depuis lrsquoApplication Server Depuis TTN un outil existe dans les Settings de chaque Device
enregistreacute Lrsquointerface est repreacutesenteacutee ci-dessous
Figure 49 Transmission de donneacutees de lrsquo laquo Application Server raquo jusqursquoau Device LoRa
Replace scheduling Mode Par deacutefaut le Frame Payload transmis remplacera le Frame
Payload en attente (si il existe) Dans ce mode un seul Frame Payload est planifieacute
First scheduling Mode Le Frame Payload est mis en file drsquoattente en premiegravere position
Last scheduling Mode Le Payload est mis en file drsquoattente en derniegravere position
Une demande de confirmation peut ecirctre demandeacutee au Device LoRa pour qursquoil preacutecise srsquoil a bien reccedilu
les donneacutees Lrsquooption laquo confirmed raquo permet donc de speacutecifier le type de trame dans le MAC Header
(voir paragraphe 443) laquo Confirmed Data Down raquo ou laquo Unconfirmed Data Down raquo dans notre cas
| 47
6 La reacutecupeacuteration des donneacutees sur notre propre Application
Nous utiliserons agrave nouveau le Network Server et Application Server de The Things Network Jusqursquoici
nous nous sommes contenteacute de veacuterifier que les donneacutees de lrsquoutilisateur (Frame Payload) soient bien
arriveacutees agrave destination dans lrsquoApplication Server Il faut maintenant les reacutecupeacuterer avec notre propre
Application qui aura pour rocircle
De stocker et traiter les donneacutees
De les mettre agrave disposition de lrsquoutilisateur (Serveur Web par exemple)
Drsquoenvoyer des commandes de lrsquoutilisateur aux Devices LoRa si besoin (Flux Downlink)
Nous allons voir deux meacutethodes pour communiquer entre notre application et TTN
Le protocole HTTP POST
Le protocole MQTT
61 Reacutecupeacuteration des donneacutees en HTTP POST dans lrsquoApplication
611 Preacutesentation du protocole HTTP
Dans le monde de lrsquointernet le protocole HTTP est tregraves utiliseacute pour le dialogue entre un client et un
serveur web Classiquement le client (un navigateur web par exemple) fait une requecircte HTTP GET
et le serveur lui retourne le contenu de la page web demandeacutee
Dans notre cas la probleacutematique est diffeacuterente car le client doit modifier le contenu du serveur
avec les donneacutees envoyeacutees par le Device LORA La requecircte srsquoappelle HTTP POST Son nom indique
que le client va poster (et on pas reacutecupeacuterer) des donneacutees
Lrsquoutilisateur qui souhaite reacuteceptionner des donneacutees sur son serveur doit donc concevoir un serveur
HTTP capable de traiter des requecirctes HTTP POST [ requecircte noteacutee (1) sur la Figure 51 ] fournies par
TTN Dans cette configuration TTN jouera le rocircle de client et notre application le rocircle de serveur
Devices
LORA Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
HTTP POST
MQTT Internet
Figure 50 Structure globale drsquoun reacuteseau LORAWAN
| 48
Figure 51 Communication bidirectionnelle entre TTN et notre Application
A lrsquoinverse lrsquoutilisateur qui souhaite transmettre des donneacutees agrave destination du Device LoRa
(Downlink) doit ecirctre capable de fournir une requecircte HTTP POST [ requecircte noteacutee (2) sur la Figure 51
] vers TTN Dans cette configuration TTN jouera le rocircle de Serveur et notre application le rocircle de
client
612 Fonctionnement drsquoun client et drsquoun serveur HTTP POST Afin de bien comprendre le fonctionnement des requecirctes HTTP POST nous allons proceacuteder par
eacutetape Le premier test que nous effectuerons sera decorreacuteleacute de TTN Le principe est le suivant
Utilisation drsquoun serveur HTTP disponible sur le web geacuterant les requecirctes HTTP POST [
httpsrbasketsin ] ou [ httpsbeeceptorcom ] par exemple
Utilisation drsquoun client HTTP eacutemettant des requecirctes HTTP POST commande curl sous linux
ou logiciel Postman [ wwwgetpostmancom ] sous windows par exemple
Ce test nous permet de valider le fonctionnement drsquoun serveur HTTP POST et drsquoun client HTTP POST
Une fois que nous serons sucircr de leur fonctionnement nous les utiliserons avec TTN
The Things Network
Application
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 49
Figure 52 Validation dun server HTTP POST et drsquoun client HTTP POST
613 Test du serveur HTTP POST Nous utiliserons un serveur web proposeacute par httpsrbasketsin
Aller sur le site httpsrbasketsin et creacuteer un nouveau laquo Basket raquo Zone ougrave vous pourrez
visualiser les requecirctes qui ont eacuteteacute eacutemises vers votre serveur
A partir de maintenant toutes les requecirctes dirigeacutees vers lrsquoadresse creacuteeacute seront traiteacutees et
srsquoafficheront Dans le menu de configuration il est aussi possible de deacutefinir le contenu de la reacuteponse
qui sera fournie
Deacutefinir un format de reacuteponse pour les requecirctes HTTP POST avec un body personnaliseacute
614 Test du client HTTP POST On peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande (la commande cURL
srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN sous Windows
Commande cURL curl ndashX POST ndashd lsquorsquodonneacutees agrave envoyerrsquorsquo DuServeurHTTP
Logiciel Postman New gt Request gt Creacuteer une requecircte HTTP POST gt Send
Veacuterifier que les requecirctes HTTP POST sont bien reacutecupeacutereacutees sur votre serveur creacutee preacuteceacutedemment
615 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST
Maintenant que nous avons un serveur HTTP (POST) fonctionnel nous allons configurer TTN pour
jouer le rocircle du client et pour qursquoil envoie des requecirctes HTTP POST vers notre Serveur degraves qursquoune
donneacutee drsquoun Device LoRa est disponible Nous geacuterons donc ici le flux Uplink
Requecircte
HTTP POST
Reacuteponse
(contenu parameacutetrable)
Client HTTP (POST)
Server HTTP (POST) [ httpsrbasketsin ]
| 50
Figure 53 Reacutecupeacuteration des donneacutees sur notre Application
Dans TTN nous inteacutegrons un bloc appeleacute laquo HTTP Integration raquo permettant de jouer le rocircle de client
crsquoest-agrave-dire drsquoenvoyer des requecirctes HTTP POST agrave destination de notre nouveau Serveur HTTP
Lrsquointeacutegration se faire agrave partir de TTN gt Console gt Application gt Nom_de_votre_application gt
Integration
Figure 54 Ajout dun client HTTP POST dans TTN
Pour valider le fonctionnement de notre architecture nous pouvons soit
Envoyer une trame depuis un Device LoRa vers TTN
Simuler lrsquoenvoi drsquoune trame drsquoun Device LoRa vers TTN (gracircce agrave lrsquooutil proposeacute par TTN vu
paragraphe 545)
Dans les deux cas voici un exemple de requecircte POST reccedilue sur notre serveur HTTP
app_id test_app_lorawan_sylvainmontagny
dev_id stm32lorawan_1
hardware_serial 0056AF49877
port 1
counter 0
payload_raw qg==
metadata
Requecircte
HTTP POST
Server HTTP (POST) [ httpsrbasketsin ]
The Things Network (Client)
La requecircte contient le Frame Payload deacutechiffreacutee
agrave transmettre agrave lrsquoApplication
| 51
time 2019-01-24T15243703499298Z
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Comme nous pouvons le voir le contenu fourni agrave notre serveur est formateacute en JSON (voir
paragraphe 0) Voici quelques compleacutements drsquoinformation
payload_raw Frame Payload deacutechiffreacute crsquoest donc les donneacutees en clairs dans la base 64
downlink_url URL du serveur HTTP POST qui serviront agrave transmettre des donneacutees au Device
LoRa (flux Downlink)
611 Envoyer des donneacutees depuis notre Application avec HTTP POST
Lorsque nous avons ajouteacute le bloc laquo HTTP Integration raquo au paragraphe preacuteceacutedent nous avons aussi
implicitement activeacute la fonctionnaliteacute que TTN soit precirct agrave recevoir et agrave traiter les requecirctes HTTP
POST La seule information qursquoil nous manque est lrsquoadresse du server HTTP vers lequel il faut eacutemettre
les requecirctes Si on observe la trame reccedilue preacuteceacutedemment en provenance de TTN on srsquoaperccediloit que
dans la trame JSON reccedilu une URL (downlink_url) est speacutecifieacutee
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Crsquoest cette URL que nous devrons utiliser Nous allons nous placer dans la configuration suivante
Figure 55 Envoi de donneacutees agrave partir de notre Application
Comme preacuteceacutedemment on peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande
(la commande cURL srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN
Commande cURL curl ndashX POST ndashdata lsquo dev_id Identidiant_De_Votre_Device
payload_raw AQE= rsquo DuServeurHTTP
Logiciel Postman New gt Request gt HTTP POST puis Body gt Raw gt JSON
Requecircte HTTP POST vers serveur TTN laquo downlink_url raquo httpsintegrationsthethingsnetworUaeb8ypKieQ
Contenu de la requecircte
dev_id Identidiant_De_Votre_Device
payload_raw aGVsbG8=
The Things Network (Serveur)
POSTMAN (Client HTTP POST)
| 52
dev_id YourDeviceID
payload_raw aGVsbG8=
Vous devez envoyer le texte (payload_raw) en base 64 Dans lrsquoexemple ci-dessus laquo aGVsbG8= raquo
correspond agrave la chaine de caractegravere laquo hello raquo Vous pouvez utiliser les nombreux encodeurdecodeur
en ligne pour vous aider Le texte doit srsquoafficher sur votre moniteur seacuterie Arduino dans le cadre de
notre deacutemonstrateur sur Arduino
62 Reacutecupeacuteration des donneacutees avec MQTT dans lrsquoApplication
621 Preacutesentation du protocole MQTT
MQTT est un protocole leacuteger qui permet de srsquoabonner agrave des flux de donneacutees Plutocirct que
lrsquoarchitecture Client Serveur classique qui fonctionne avec des Requecirctes Reacuteponses MQTT est
baseacute sur un modegravele Publisher Subscriber La diffeacuterence est importante car cela eacutevite davoir agrave
demander (Requecircte) des donneacutees dont on na aucune ideacutee du moment ougrave elles vont arriver Une
donneacutee sera donc directement transmise au Subscriber degraves lors que celle-ci a eacuteteacute reccedilue dans le
Broker (serveur central)
Figure 56 Modegravele Publisher Subscriber du protocole MQTT
Pour recevoir les donneacutees appartenant agrave un Topic un Subscriber doit souscrire (comme son nom
lindique) au preacutealable sur ce Topic
MQTT est un protocole qui repose sur TCP Lencapsulation des trames sur le reacuteseau est donc la
suivante
Broker
Client
Publisher 1
Client
Publisher 2
Client
Subscriber
Topic
Tempeacuterature
Topic
Humiditeacute
| 53
Figure 57 Protocoles utiliseacutes pour la communication avec MQTT
On peut le veacuterifier par une capture de trame sur Wireshark
Figure 58 Capture dune trame MQTT avec Wireshark
On peut noter que le port TCP utiliseacute pour le protocole MQTT (non chiffreacute) est le 1883
Les Publishers et les Subscribers nrsquoont pas besoin de se connaitre
Les Publishers et les Subscribers ne sont pas obligeacute de srsquoexeacutecuter en mecircme temps
622 Connexion au Broker MQTT Nous nous inteacuteresserons essentiellement aux options de connexion qui permettront de geacuterer la
Qualiteacute de Service (QoS) Pour se connecter un client MQTT envoie deux informations importantes
au Broker
keepAlive Cest la peacuteriode la plus longue pendant laquelle le client Publisher ou Subscriber pourra
rester silencieux Au-delagrave il sera consideacutereacute comme deacuteconnecteacute
cleanSession Lorsque le Client et le Broker sont momentaneacutement deacuteconnecteacutes (au-delagrave du
keepAlive annonceacute) on peut donc se poser la question de savoir ce quil se passera lorsque le client
sera agrave nouveau connecteacute
Si la connexion eacutetait non persistante (cleanSession = True) alors les messages non transmis
sont perdus Quel que soit le niveau de QoS (Quality of Service)
Si la connexion eacutetait persistante (cleanSession = False) alors les messages non transmis
seront eacuteventuellement reacuteeacutemis en fonction du niveau de QoS Voir le chapitre 624
623 Qualiteacute de Service au cours dune mecircme connexion
A partir du moment ougrave le Client se connecte au Broker il est possible de choisir un niveau de fiabiliteacute
des transactions Le Publisher fiabilise leacutemission de ces messages vers le Broker et le Subscriber
fiabilise la reacuteception des messages en provenance du Broker Une parle ici du cas dune mecircme
connexion crsquoest-agrave-dire entre le moment ou le Client se connecte et le moment ougrave
Soit il se deacuteconnecte explicitement (Close connexion)
Soit il na rien eacutemis ni fait signe de vie pendant le temps keepAlive
TCP
MQTT
Reacuteseau
Transport
Couche Application
IP
| 54
Lors dune mecircme connexion la Qualiteacute de Service (QoS) qui est mise en œuvre deacutepend uniquement
de la valeur du QoS selon les valeurs suivantes
QoS 0 At most once (au plus une fois) Le premier niveau de qualiteacute est sans acquittement Le
Publisher envoie un message une seule fois au Broker et le Broker ne transmet ce message quune
seule fois aux Subscribers Ce meacutecanise ne garantit pas la bonne reacuteception des messages MQTT
QoS 1 At least once (au moins une fois) Le deuxiegraveme niveau de qualiteacute est avec acquittement
Le Publisher envoie un message au Broker et attends sa confirmation De la mecircme faccedilon le Broker
envoie un message agrave ces Subscriber et attends leurs confirmations Ce meacutecanisme garantit la
reacuteception des message MQTT
Cependant si les acquittements nrsquoarrivent pas en temps voulu ou srsquoils se perdent la reacuteeacutemission du
message dorigine peut engendrer une duplication du message Il peut donc ecirctre reccedilu plusieurs fois
QoS 2 Exactly once (exactement une fois) Le troisiegraveme niveau de qualiteacute est garanti une seule
fois Le Publisher envoie un message au Broker et attends sa confirmation Le Publisher donne alors
lrsquoordre de diffuser le message et attends une confirmation Ce meacutecanisme garantit que quel que
soit le nombre de tentatives de reacuteemission le message ne sera deacutelivreacute quune seule fois
La Figure 59 montre les trames eacutemises pour chaque niveau de QoS
Figure 59 Qualiteacute de Service en MQTT
La Figure 60 repreacutesentes les 3 captures de trames sur Wireshark repreacutesentant les 3 QoS (1 2 et 3)
que nous venons dexpliquer
Broker
QoS 0
Au plus une fois
Message supprimeacute apregraves envoi
PUBLISH
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Duplications possibles
PUBLISH
PUBLICH Ack
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Pas de duplication
PUBLISH
PUBLISH Receive
PUBLISH Release
PUBLISH Complete
| 55
Figure 60 Capture de trame avec QoS = 0 puis QoS = 1 puis QoS = 2
624 Qualiteacute de Service apregraves une reconnexion
La question que nous nous posons et de savoir ce que deviennent les messages publieacutes sur le Broker
lorsquun ou plusieurs Subscribers sont momentaneacutement injoignables Il est possible de conserver
les messages qui ont eacuteteacute publieacutes sur le Broker afin de les retransmettre lors de la prochaine
connexion Cette possibiliteacute de sauvegarde doit ecirctre activeacutee agrave louverture de connexion gracircce au flag
cleanSession = 0 La connexion sera alors persistante crsquoest-agrave-dire que le Broker enregistre tous les
messages quil na pas reacuteussi agrave diffuser au Subscriber
Le Tableau 9 reacutesume leffet du flag cleanSession et du QoS
Clean Session Flag Subscriber QoS Publisher QoS Comportement True ( = 1) 0 1 2 0 1 2 Messages perdus
False ( = 0 ) 0 0 1 2 Messages perdus
False (= 0 ) 0 1 2 0 Messages perdus
False (= 0 ) 1 2 1 2 Tous les messages sont retransmis
Tableau 9 Qualiteacute de Service en fonction de la valeur du QoS et du flag cleanSession
625 Les Topics du protocole MQTT Les chaicircnes deacutecrivant un sujet forment une arborescence en utilisant la barre oblique comme
caractegravere de seacuteparation La Figure 61 et le Tableau 10 donne un exemple dorganisation de Topic
Figure 61 Exemple de hieacuterarchie de Topic MQTT
Niveau 3
Niveau 2
Niveau 1 Maison
Chambre
Temperature Humidite Bruit
Salon
Temperature
| 56
Nom du Topic Deacutetail du Topic MaisonChambreTemperature La tempeacuterature de la chambre de la maison
MaisonChambreBruit Le bruit de la chambre de la maison
MaisonSalonTemperature La tempeacuterature du Salon de la maison
Tableau 10 Exemple de Topic
Un client peut sabonner (ou se deacutesabonner) agrave plusieurs branches de larborescence agrave laide de
jokers englobant plusieurs Topics Deux caractegraveres jokers existent
Le signe plus + remplace nimporte quelle chaine de caractegravere sur le niveau ougrave il est placeacute
Le diegravese remplace nimporte quelle chaine de caractegravere sur tous les niveaux suivants Il
est obligatoirement placeacute agrave la fin
Nom du Topic Deacutetail du Topic Maison+Temperature Les tempeacuteratures de toutes les piegraveces de la maison
MaisonChambre La tempeacuterature lhumiditeacute et le bruit de la chambre de la maison
Tableau 11 Exemple de Topic
626 Mise en place drsquoun Broker MQTT Afin de bien comprendre le fonctionnement du protocole de MQTT on reacutealise des tests
indeacutependamment de TTN Nous allons mettre en place
Un Broker Mosquitto httpstestmosquittoorg
Un client Publisher MQTT Box sur Windows
Un client Subscriber MQTT Box sur Windows
Figure 62 Test du protocole MQTT
MQTT Client (Subscriber)
MQTT Client (Publisher)
Publish
Subscribe
BROKER (Mosquitto)
| 57
Le Broker MQTT est commun agrave tout le monde Nous pouvons soit le reacutealiser nous-mecircme soit utiliser
un Broker MQTT public de test Nous utiliserons le Broker de test de Mosquitto disponible sur
httpstestmosquittoorg Drsquoautres sont eacuteventuellement disponibles en cas de problegraveme par
exemple httpwwwmqtt-dashboardcom
Si nous deacutecidions de le reacutealiser nous-mecircme agrave lrsquoaide drsquoune Raspberry Pi (par exemple) Lrsquoinstallation
se ferait en deux lignes de commande
apt-get install mosquito Installation
sudo systemctl start mosquittoservice Lancement du service
Il est neacutecessaire drsquoinstaller mosquitto-clients si on souhaite que le Raspberry PI joue aussi le rocircle de
client ce qui nrsquoest pas notre cas
627 Mise en place drsquoun Publisher et drsquoun Subscriber MQTT Lancer le logiciel MQTTBox
MQTTBox gt Create MQTT Client
Dans ce client les seuls champs indispensables sont
Protocol MQTT TCP
Host testmosquittoorg
Figure 63 Configuration dun Client MQTT dans MQTT Box
Tester lrsquoenvoi et la reacuteception sur les Topics de votre choix
628 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT La reacutecupeacuteration des donneacutees fait reacutefeacuterence au flux Uplink Dans ce cas
TTN joue le rocircle de client Publisher
TTN joue aussi le rocircle de Broker
Notre application joue le rocircle de Subscriber
Nous pouvons donc repreacutesenter lrsquoapplication globale par le scheacutema suivant
| 58
Figure 64 Publisher et Subscriber dans en MQTT avec TTN
La publication est repreacutesenteacutee par la trame MQTT (1)
La souscription est repreacutesenteacutee par la trame MQTT (2)
Le client Publisher eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box mais cette fois avec la configuration suivante
Protocol mqtt tcp
Host Crsquoest lrsquoIP du Broker vers lequel il faut se connecter Dans notre cas il srsquoagit de celui
de TTN dont lrsquoadresse est euthethingsnetwork
Username La connexion vers le broker MQTT est soumis agrave une authentification Username
Password Dans notre cas le Username correspond au nom de notre application crsquoest-agrave-
dire seminaire_lorawan Si vous avez choisi une autre applicationil faut bien mettre la
votre
Password Le Password est nommeacute laquo Access Key raquo par TTN Elle vous sera donneacutee par
lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application vous
trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt Overview
Figure 65 Access Keys de lapplication dans TTN
The Things Network (Application Server)
BROKER
Application
The Things Network (Network Server)
Publish (1 )
[ Flux Uplink ]
Subscribe (2 )
[ Flux Uplink ]
| 59
Figure 66 Configuration du Client dans MQTT Box
Le client MQTT eacutetant configureacute il est maintenant capable de se connecter au Broker Il reste donc agrave
deacutefinir le fait que le client sera Subscriber Les informations que recevra le Subscriber deacutependent du
Topic auquel nous souscrivons Voici les Topic disponibles sur le Broker de TTN
ltAppIDgt correspond au nom de votre Application
ltDevIDgt correspond au nom de votre Device LoRa
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink ltAppIDgtdevicesltDevIDgtup
[Donneacutees] Flux Downlink ltAppIDgtdevicesltDevIDgtdown
[Activation Events] Activation dun Device ltAppIDgtdevicesltDevIDgteventsactivations
[Management Events] Creacuteation dun Device ltAppIDgtdevicesltDevIDgteventscreate
[Management Events] Update dun Device ltAppIDgtdevicesltDevIDgteventsupdate
[Management Events] Suppression dun Device ltAppIDgtdevicesltDevIDgteventsdelete
[Downlink Events ] Message programmeacute ltAppIDgtdevicesltDevIDgteventsdownscheduled
[Downlink Events ] Message envoyeacute ltAppIDgtdevicesltDevIDgteventsdownsent
[Erreurs] Uplink erreurs ltAppIDgtdevicesltDevIDgteventsuperrors
[Erreurs] Downlink erreurs ltAppIDgtdevicesltDevIDgteventsdownerrors
[Erreurs] Activations erreurs ltAppIDgtdevicesltDevIDgteventsactivationserrors
Tableau 12 Topics enregistreacutes dans TTN
Dans un premier temps nous souscrivons au Topic +devices+up Cela signifie que nous
souscrivons agrave tous les Devices LoRa de toutes nos applications pour le flux Uplink
Figure 67 Configuration du Subscriber
Les eacuteleacutements eacutemis par le Broker seront alors afficheacutes dans MQTTBox La
| 60
Figure 68 Trame LoRaWAN reccedilu sur le Subscriber MQTT
Ces donneacutees sont eacutecrites en JSON nous pouvons les remettre en forme
applicationID3
applicationNamemyApplication
deviceNamearduino0
devEUI0056xxxxxxxxx877
txInfo
frequency868500000
dr5
adrfalse
fCnt792
fPort15
dataSGVsbG8=
Le Frame Payload deacutechiffreacute est fourni dans le champ data en base 64 La valeur fournie par
dataSGVsbG8= correspond bien agrave la chaine de caractegravere hello que nous avons eacutemise avec le
Device LoRa
629 Envoyer des donneacutees depuis notre Application avec MQTT
Lrsquoenvoi des donneacutees fait reacutefeacuterence au flux Downlink Dans ce cas
Notre application joue le rocircle de Publisher
TTN joue le rocircle de Broker
TTN joue aussi le rocircle de client Subscriber
| 61
La publication est repreacutesenteacutee par la trame MQTT (3)
La souscription est repreacutesenteacutee par la trame MQTT (4)
Le client Subscriber eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box Le rocircle de client dans MQTT Box a eacuteteacute faite au
paragraphe 628 Il nous reste simplement agrave ajouter le rocircle de Publisher La configuration est la
suivante
Topic du Subscriber seminaire_lorawandevicesarduino0down ougrave seminaire_lorawan
est agrave remplacer par le nom de votre application et arduino0 par le nom du Device LoRa vers
lequel vous souhaitez envoyeacute une donneacutee (Voir chapitre 628 pour comprendre les Topics)
Le Payload doit ecirctre au format JSON Lrsquoexemple suivant envoie laquohello raquo
payload_raw aGVsbG8=
The Things Network (Application Server)
BROKER
Application
Publish (3)
[ Flux Downlink ]
The Things Network (Network Server)
Subscribe (4)
[ Flux Downlink ]
| 62
Figure 69 Configuration du Publisher
Vous devriez voir les donneacutees arriver sur votre Device LoRA
| 63
7 Creacuteation de notre propre Network et Application Server
711 Objectifs Lors de la mise en œuvre du reacuteseau LoRaWAN au chapitre 52 nous avons utiliseacute TTN (The Things
Network) pour jouer le rocircle de Network Server et drsquoApplication Server Pour de multiples raisons
Seacutecuriteacute autonomie coucircthellipil peut ecirctre inteacuteressant de monter soi-mecircme un Network Server et un
Application Server Cela est possible seulement si vous posseacutedez vos propres Gateway puisque
celles-ci devront forwarder leur paquet agrave destination preacutecise Il faudra donc les reconfigurer pour
qursquoelles pointent vers votre nouvelle architecture
712 Preacutesentation de LoRaServer LoRaServer [ wwwloraserverio ] est un projet Open-Source reacutepondant exactement au besoin que
nous avons Nous lrsquoutiliserons sur une cible Raspberry PI En reacutealiteacute il peut souvent ecirctre mise en
place dans le mecircme systegraveme que la Gateway surtout si celle-ci est elle-mecircme agrave base de RPI Les
Gateway EBDS que nous posseacutedons possegravedent drsquoailleurs un Network Server et un Application Server
que nous aurions pu utiliser Neacuteanmoins pour des raisons peacutedagogiques il est inteacuteressant de
seacuteparer les systegravemes pour bien diffeacuterencier les probleacutematiques
Attention il y a une ambiguiumlteacute dans la deacutenomination des entiteacutes logiciels de LoRaServer
LoRaServer (sans espace entre le mot LoRa et Server) est le nom du projet global En
revanche LoRa Server (avec un espace) est le nom du service qui joue le rocircle du Network
Server
Lrsquoarchitecture et le fonctionnement de LoRaServer est preacutesenteacutee dans sa documentation par le
scheacutema suivant
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Raspberry PI
Figure 70 Architecture globale de notre reacuteseau loRaWAN
| 64
Figure 71 Architecture deacutetailleacutee de LoRaServer
On srsquoattends agrave voir uniquement un Network Server (LoRa Server) et un Application Server (LoRa App
Server) mais ce scheacutema est plus complexe Il demande un certain nombre drsquoexplications pour bien
comprendre ce que nous allons installer et la faccedilon dont nous lrsquoutiliserons par la suite
713 Le laquo Packet Forwarder raquo (Gateway) Comme nous lrsquoavons vu au chapitre 412 les Gateways LoRa sont des passerelles entre la
modulation LoRa et un reacuteseau IP Pour reacutealiser cette passerelle un service nommeacute laquo UDP Packet
Forwarder raquo a eacuteteacute deacuteveloppeacute par Semtech httpsgithubcomLora-netpacket_forwarder Dans
ce dossier github un fichier nommeacute PROTOCOLTXT explique parfaitement ce protocole applicatif
qui travaille au-dessus de UDP
Figure 72 Protocole Uplink (PUSH_DATA du Packet Forwarder)
| 65
On remarque que les paquets sont envoyeacutes en UDP au Network Server dans une trame appeleacutee
PUSH_DATA Cette trame est acquitteacutee par le Network Server par une trame appeleacutee PUSH_ACK
Sur notre Network Server nous pouvons reacutealiser une capture de trame pour veacuterifier si le protocole
est bien celui preacutesenteacute dans le document
Figure 73 Trame captureacutee par Wireshark lors dun Uplink
Drsquoapregraves la capture preacuteceacutedente on remarque que le Packet Forwarder fonctionne bien avec UDP sur
le port 1700
Le contenu des donneacutees (champ Data) est deacutetailleacute dans le tableau suivant
Champ | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | random token
[3] | 3 | PUSH_DATA identifier = 0x00
[4] | 4-11 | Gateway unique identifier (MAC address)
[5] | 12-end | JSON object starting with ending with
Lrsquoobjet JSON de la transmission reacuteeacutecrit plus proprement est celui-ci
Figure 74 Analyse du champ Donneacutees du protocole laquo Packet Forwarder raquo
0000 02 f9 30 00 b8 27 eb ff fe ae 26 f5 7b 22 72 78 0amprx 0010 70 6b 22 3a 5b 7b 22 74 6d 73 74 22 3a 33 37 35 pk[tmst375 0020 35 30 30 35 38 31 39 2c 22 63 68 61 6e 22 3a 32 5005819chan2 0030 2c 22 72 66 63 68 22 3a 31 2c 22 66 72 65 71 22 rfch1freq 0040 3a 38 36 38 2e 35 30 30 30 30 30 2c 22 73 74 61 868500000sta 0050 74 22 3a 31 2c 22 6d 6f 64 75 22 3a 22 4c 4f 52 t1moduLOR 0060 41 22 2c 22 64 61 74 72 22 3a 22 53 46 37 42 57 AdatrSF7BW 0070 31 32 35 22 2c 22 63 6f 64 72 22 3a 22 34 2f 35 125codr45 0080 22 2c 22 6c 73 6e 72 22 3a 36 2e 35 2c 22 72 73 lsnr65rs 0090 73 69 22 3a 2d 31 2c 22 73 69 7a 65 22 3a 31 38 si-1size18 00a0 2c 22 64 61 74 61 22 3a 22 51 4e 4d 61 41 53 59 dataQNMaASY 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 ]
Ch
amp
[1
]
Ch
amp
[2
]
Ch
amp
[3
]
Ch
amp
[4
]
| 66
rxpk[ tmst3755005819
chan2
rfch1
freq868500000
stat1
moduLORA
datrSF7BW125
codr45
lsnr65
rssi-1
size18
dataQNMaASYAAQAPpyPZ955+SmY
]
Le champ data correspond au PHY Payload
De la mecircme faccedilon on retrouve la Trame drsquoacquittement
Figure 75 Trame captureacutee par Wireshark lors de lrsquoacquittement drsquoun Uplink
Champs | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | same token as the PUSH_DATA to acknowledge
[3] | 3 | PUSH_ACK identifier = 0x01
Nous retrouvons bien tous ces champs dans la trame Wireshark
714 LoRa Gateway Bridge Nous avons deacutecrit au chapitre preacuteceacutedent (713) le fonctionnement du Packet Forwarder Le
Network Server(Lora Server) que nous allons mettre en place aurait tregraves bien pu srsquointerfacer
directement agrave ce protocole Mais cela aurait plusieurs impacts dont un qui est important dans la
conception de logiciel Si le Packet Forwarder change ou si un autre type de Forwarder est utiliseacute
alors lrsquoutilisation du LoRa Server devient impossible Il a donc eacuteteacute choisi de creacuteer une eacutetape
intermeacutediaire Le Network Server que nous mettrons en plus utilisera le protocole MQTT plutocirct que
le protocole UDP packet Forwarder
En drsquoautres termes le LoRa Gateway Bridge est un service qui fera abstraction du Packet Forwarder
pour srsquointerfacer plus simplement avec le Network Server
715 LoRa Server (Network Server) Il srsquoagit de notre Network Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
413 Cependant il srsquointerfacera au protocole MQTT en recevant les informations agrave partir du
Broker au lieu de recevoir directement les trames en provenance de la Gateway
| 67
716 LoRa App Server (Application Server) Il srsquogit de notre Application Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
414
717 LoRa Geo Server Il srsquoagit drsquoun service qui permet drsquoutiliser certaines proprieacuteteacutes du protocole LoRa pour proposer un
service de geacuteolocalisation des Devices LoRa Nous ne lrsquoutiliserons pas dans notre cas
718 Application Il srsquoagit de notre Application qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre 415
Elle ne fait pas partie du projet LoRaServer crsquoest donc bien toujours agrave nous de proposer notre propre
Application
Figure 76 Les interfaces possibles entre LoRaServer et lrsquoApplication utilisateur
Comme nous pouvons le voir sur la figure preacuteceacutedente deux possibiliteacutes sont offertes pour interfacer
notre application JSON REST (incluant HTTP POST) et via un Broker MQTT Ces deux meacutethodes ont
deacutejagrave eacuteteacute traiteacutee au chapitre 61 (HTTP POST ) et au chapitre 62 (MQTT) Nous verrons aussi drsquoautres
possibiliteacutes pour personnaliser notre application au chapitre 7
72 Installation de LoRaServer
721 Mise en place de lrsquoenvironnement
Nous allons installer une carte SD avec la derniegravere version de Raspbian Nous ne deacutetaillerons pas la
deacutemarche pour cela car elles sont largement documenteacutees et mises agrave jour sur le site
wwwraspberrypiorg
Installer un carte SD avec la derniegravere version de Raspbian
Plutocirct que de fonctionner avec un clavier et une souris nous preacuteconisons de travailler agrave distance
avec la RPI via une connexion SSH Depuis quelques anneacutees Raspbian a supprimeacute le deacutemarrage du
service SSH au boot Heureusement il est possible de le reacuteactiver par la meacutethode suivante
Avec Windows ou Linux ouvrir la partition BOOT de votre carte SD et placer un fichier agrave la
racine nommeacute sshtxt (ou ssh)
Mettre la carte SD dans votre RPI et la deacutemarrer
| 68
Pour acceacuteder agrave la RPI en SSH depuis Windows nous utiliserons de preacutefeacuterence le logiciel
client MobaXterm mais tout autre client SSH est valable
Installer MobaXterm sur votre PC et connectez-vous agrave votre Raspberry PI
Lrsquoutilisation drsquoun espion de reacuteseau type Wireshark peut ecirctre inteacuteressant pour eacutetudier les trames qui
sont reccedilues et qui sont eacutemises Cela nous permettra de valider le fonctionnement des diffeacuterents
protocoles reacuteseau qui permettent de communiquer agrave la Gateway drsquoune part et agrave lrsquoApplication
drsquoautre part Nous utiliserons tshark
apt-get install tshark installation
tshark ndashn -i eth0 Exemple drsquoune analyse sur lrsquointerface wlan0
722 Installation sur la Raspberry PI La meacutethode drsquoinstallation de LoRaServer est documenteacutee sur le site web agrave lrsquoadresse suivante
[ httpswwwloraserverioguidesdebian-ubuntu ] Nous installerons le LoRa Gateway Bridge
le LoRa Server et le LoRa App Server
Apregraves lrsquoinstallation la configuration se fait par une interface graphique accessible par le reacuteseau sur
le port 8080
Si vous travaillez sur la RPI connectez-vous sur httplocalhost8080
Si vous travaillez agrave distance (SSH) connectez-vous sur httpIP_RPI8080
Les Usernames et Password par deacutefaut sont
Username admin
Password admin
Lrsquoeacutecran drsquoaccueil sera donc le suivant
Figure 77 Architecture globale apregraves installation de LoRaServer
Devices
Gateways LoRa
UDP Packet Forwarder
Application Server
LoRa App Server
Internet
Network Server
LoRa Server
LoRa Gateway Bridge
| 69
Figure 78 Ecran daccueil de LoRaServer apregraves authentification
71 Configuration de LoRa Server pour lUplink
711 Enregistrement drsquoune nouvelle Organisation
Pour enregistrer une nouvelle Organizations Organizations gt Create Puis entrer les configurations
suivantes
Figure 79 Enregistrement dun nouvelle Organisation
712 Enregistrement drsquoune instance du Network Server Pour enregistrer une nouvelle instance du Network Server Network Server gt Create Puis entrer
les configurations suivantes
| 70
Figure 80 Enregistrement dun nouveau Network Server
Dans lrsquoonglet Gateway Discovery il est possible drsquoactiver une option de deacutecouverte de Gateway aux
alentours Lorsqursquoelle est configureacutee le Network Server va envoyer une trame Downlink de
configuration de la Gateway lui ordonnant de reacutealiser des PING en LoRa La configuration du
Gateway Discovery preacutevoit de speacutecifier
Le nombre de fois par jour que les PING LoRa sont envoyeacutes
Le canal drsquoeacutemission
Le Data Rate (Voir paragraphe 445)
Un PING LoRa reccedilu sur une Gateway sera retransmis sur le Network Server (Lora Server) et une carte
sera afficheacutee
Lrsquoonglet TLS Certificates ne sera pas utiliseacute dans le cadre de notre deacutemonstration
713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) Il faut tout drsquoabord faire un enregistrement drsquoun laquo service-profile raquo Un laquo service profile permet de
faire la connexion entre le Network Server et les Applications que nous enregistrerons dans notre
Organisation Service-profiles gt Create
Service-profile name myServiceProfile
Network-server myNetworkServer
On laissera par deacutefaut toutes les autres options
Pour enregistrer une nouvelle Application Applications gt Create Puis entrer les configurations
suivantes
| 71
Figure 81 Enregistrement dune nouvelle Application
714 Enregistrement des Devices LoRa Il faut tout drsquoabord faire lrsquoenregistrement drsquoun Device-profile pour les Devices LoRa que vous
souhaitez connecter Dans notre cas nous ferons un premier test en speacutecifiant que nous utilisons
seulement le mode drsquoauthentification ABP (voir chapitre 431) Devices profile gt Create
Figure 82 Enregistrement dun laquo Device profile raquo
Nous pouvons alors creacuteer dans notre Application des nouveaux Devices Application gt
myApplication gt Create
| 72
Figure 83 Enregistrement dun nouveau Device LoRa
Dans la fenecirctre Activation on va alors configurer les 3 eacuteleacutements indispensables agrave une
authentification en APB Le DevAddr le NwkSKey et lrsquoAppSKey
Figure 84 Configuration de lenregistrement du Device LoRa (en ABP)
La configuration minimale de LoRaServer est maintenant termineacutee Nous pouvons donc brancher
un Device LoRa qui possegravede les les attribus (DevAddr NwkSKey et AppSKey) que nous avons
enregistreacute dans LoRaServer et le faire eacutemettre
715 Visualisation des trames reccedilues Les trames eacutemises par le Device LoRa vont donc parcourir le cheminement suivant
| 73
Figure 85 Reacutesumeacute du cheminement des trames LoRaWan en Uplink avec LoRaServer
En allant dans le Live Device Data (Application gt Nom_du_Device gt Live Device Data) on peut voir la
liste des trames reccedilues ainsi que les donneacutees applicatives deacutechiffreacutees
Figure 86 Reacuteception des trames des Devices LoRa
Figure 87 Analyse des trames des Devices LoRa
Dans lrsquoonglet LIVE LORAWAN FRAME nous pouvons voir les trames LORAWAN et si besoin eacutetudier
le contenu de ce qursquoelles contiennent En revanche les donneacutees applicatives sont ici chiffreacutees
UDP
Packet Forwarder
LoRa Bridge
Gateway LoRa Server LoRa App Server
Gateway
Server
Internet
| 74
Figure 88 Reacuteception des Trames LoRaWAN
72 Configuration de LoRaServer pour linteacutegration dApplication Nous avons vu dans le chapitre 718 que linterface entre LoRaServer et notre Application pouvait
ecirctre reacutealiseacutee soit par MQTT soit par les meacutethodes REST (HTTP POST) Nous avons deacutejagrave impleacutementeacute
et expliqueacute ces protocoles dans le cadre de son utilisation avec TTN Nous allons donc juste
configurer LoRaServer pour tester ces deux meacutethodes
721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST Nous utiliserons exactement la mecircme meacutethode que celle que nous avons utiliseacute avec TTN au
chapitre 615 Les diffeacuterentes Clients et Serveurs disponibles pour ces tests sont expliqueacutes au
paragraphe 612
Dans LoRaServer ajouter une inteacutegration HTTP LoRaServer gt Applications gt myApplication gt
Integrations gt Create gt HTTP Integration et la configurer comme le montre la Figure 89 Vous
remplacerez eacutevidement le lien par votre propre Endpoints
Figure 89 Configuration de linteacutegration HTTP POST dans LoRaServer
En envoyant des trames LoRa depuis votre Device vous devriez voir les contenus JSON sur votre
Endpoint
722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT Nous allons nous connecter au Broker MQTT de LoRaServer Pour cela nous utiliserons la mecircme
meacutethode que celle que nous avons utiliseacute avec TTN au chapitre 628 Nous utiliserons MQTTBox
comme nous lavons deacutejagrave fait au paragraphe 627
Le Broker de LoRaServer a enregistreacute les Topics suivant
[applicationID] correspond au nom de votre Application
[devEUI] correspond au nom de votre Device LoRa
| 75
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink application[applicationID]device[devEUI]rx
[Donneacutees] Flux Downlink application[applicationID]device[devEUI]tx
[Status] Statut dun Device application[applicationID]device[devEUI]status
[Ack] Acquittement des messages application[applicationID]device[devEUI]ack
[Erreurs] Erreurs application[applicationID]device[devEUI]error
Tableau 13 Topics enregistreacutes dans LoRaServer
| 76
8 Creacuteation de notre propre Application
81 Utilisation de Node-RED
811 Preacutesentation Node-RED est un outil de programmation graphique qui permet de faire communiquer les
peacuteripheacuteriques mateacuteriels drsquoun systegraveme sans eacutecrire de code De nombreux protocoles sont aussi pris
en charge au travers de bloc ( Node) qursquoil suffit de connecter entre eux pour reacutealiser simplement
une application Il peut srsquoexeacutecuter localement sur un PC ou sur des cibles embarqueacutees telle qursquoune
Raspberry PI (RPI)
Dans les deacutemonstrations que nous mettrons en œuvre nous utiliserons une RPI Par soucis de
simpliciteacute nous utiliserons les derniegraveres versions de Raspbian (systegraveme drsquoexploitation de la RPI) qui
integravegre drsquoorigine Node-RED Il nrsquoy a donc tregraves peu de chose agrave mettre en place pour arriver agrave mettre
en place une Application Nous pouvons travailler soit directement sur la RPI agrave lrsquoaide drsquoune souris-
clavier mais il est recommandeacute de travailler agrave distance avec une connexion SSH
812 Mise en place de lrsquoenvironnement La mise en place de la RPI avec le systegraveme drsquoexploitation Raspbian a eacuteteacute preacutesenteacute au chapitre 721
Vous pouvez reprendre la mecircme installation ou repartir sur une nouvelle
Il est possible de faire en sorte que Node-RED se lance directement au deacutemarrage gracircce agrave la
commande sudo systemctl enable noderedservice
Sil nest pas actif lancer Node-RED sur votre RPI node-red-start
Nous nous connectons au Node-RED de la RPI via un navigateur web sur le port 1880 en tapant dans
la barre dURL httpIP_Raspeberry_PI1880 Ce nous permet darriver agrave la fenecirctre suivante
Figure 90 Page daccueil de Node-RED
Il est possible de sinterfacer avec TTN avec les Nodes deacutejagrave disponibles gracircce au protocole HTTP
POST ou MQTT Neacuteanmoins nous pouvons avantageusement installer deux librairies speacutecifiques
Une qui facilite linterfaccedilage avec TTN
Une qui facilite la mise en place dinterface graphique
Installation des Nodes TTN
cd $HOMEnode-red
npm install node-red-contrib-ttn
Installation de Dashboard (interface graphique)
| 77
cd $HOMEnode-red
npm install node-red-dashboard
Il peut ecirctre necessaire de redeacutemarrer Node-RED pour prendre en compte linstallation de nos deux
Nodes
-----------------------------------
sudo apt-get install npm
sudo npm install -g npm
hash -r
cd ~node-red
npm install node-red-example node name
------------------------------------
813 Creacuteer une Application speacutecifique pour TTN Nous allons commencer par geacuterer le flux Uplink Apporter sur votre scheacutema un Node ttn uplink et
un Node Debug puis relier les Le Node ttn uplink nous permettra de configurer la
communication avec TTN en MQTT Le Node debug eacutecrira sur le terminal les informations brutes
qui seront reccedilu par le Node ttn uplink
Figure 91 Visualisation des trame publieacutees par TTN sur notre client MQTT
Double cliquer sur le Node ttn uplink pour le configurer comme la figure suivante
Le champ Name sera le nom du Node sur votre scheacutema Le champ Device ID est le device LoRa
concerneacute dans votre application De plus il faut entrer les caracteacuteristiques de votre application (Add
new ttn app) pour que Node-RED puisse sy connecter
Figure 92 Configuration du node ttn uplink
Configuration de votre nouvelle application
| 78
Figure 93 Identifiant et mot de passe de notre application
AppID Nom de votre application Dans notre cas seminaire_lorawan
Access Key Comme nous lavons deacutejagrave expliqueacute plus tocirct l Access Key vous sera donneacutee
par lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application
vous trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt
Overview
Le Node ttn uplink doit maintenant avoir le nom que vous avez configureacute Cliquer sur Deploy pour
lancer votre projet Le bloc ttn uplink doit maintenant ecirctre connecteacute agrave TTN Cela est speacutecifieacute
connected sous le bloc
Figure 94 Utilisation du Node TTN Uplink
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
Figure 95 Simulation de Uplink dans TTN
Vous devriez voir le reacutesultat dans la fenecirctre de Debug Par exemple pour le test denvoi de 31 32
correspondant au code ASCII des chiffres 1 et 2 vous devriez avoir la fenecirctre de Debug suivante
| 79
Figure 96 Reacutesultats obtenu dans la fenecirctre Debug apregraves la simulation dUplink
814 Creacuteation drsquoun Dashboard
Dans la mise en place de lenvironnement (chapitre 812) nous avons installeacute des Nodes
Dashboard qui vont nous permettre de reacutealiser une interface graphique tregraves simple et de la mettre
agrave disposition des utilisateurs via un des graphiques histogramme gauges afficheurshellip
Figure 97 Impleacutementation dune interface graphique dans Node RED
Linterface graphique que nous allons creacuteer sera constitueacutee donglet (tab) La mise en place des
composant se fait de la faccedilon suivante
Chaque eacuteleacutement graphique doit appartenir agrave un groupe de composant quil va falloir creacuteer
Chaque groupe de composant doit appartenir agrave un onglet (tab) quil va falloir creacuteer
Figure 98 Creacuteation dun groupe de composant
Figure 99 Creacuteation dun nouvel onglet dans le site web
Cliquer sur Deploy pour activer votre application
LURL pour joindre linterface graphique de votre site web est disponible sur ladresse
httpIP_Raspeberry_PI1880ui
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
| 80
Figure 100 Interface graphique du site web avec Node-RED
82 Programmation en PHP Maintenant que nous avons testeacute toute lrsquoarchitecture nous pouvons mettre en place une
application qui jouera deux rocircles
Un rocircle de Serveur HTTP POST reacutecupeacuterant les donneacutees en provenance de TTN
Un rocircle de Client HTTP POST qui geacuteneacuterera les requecirctes vers TTN
Un serveur web apache sur RPI heacuteberge cette application Linterface graphique du site web est
reacutealiseacute avec le template CSS proposeacute par Bootstrap [ httpsgetbootstrapcom ]
Figure 101 Architecture de notre application en PHP sur RPI
The Things Network
Notre Application
[ Serveur Apache sur Raspberry Pi ]
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 81
Nous allons lrsquoutiliser telle quelle Elle est juste proposeacutee agrave titre dexemple Lrsquoobjectif de cette
application est de geacuteneacuterer une ouverture fermeture de ruche agrave distance dans le cadre de projets
eacutetudiants du Master Electronique et Systegravemes Embarqueacutes de lUSMB [ httpscem-esetuniv-
smbfr ]
Figure 102 Application permettant de recevoir et deacutemettre des requecirctes HTTP POST
Configurer TTN pour pointer vers votre nouveau serveur et tester le flux montant et
descendant
| 82
9 Versions du document
Version 10 02022019
Version initiale
Version 20 23022019
Ajout drsquoun paragraphe Les systegravemes embarqueacutes dans lrsquoIoT En introduction
Compleacutement et ameacutelioration Ameacutelioration exercice eacutetalement de spectre
Correction Cacircblage Arduino
Ajout drsquoun paragraphe Fonctionnement de lrsquoArduino et ajout de librairies
Compleacutement et ameacutelioration Couche physique LoRa Ajout de 4 figures pour lrsquoexplication
de la modulation Chirp
Ajout drsquoun paragraphe sur les acronymes utiliseacutes au deacutebut du cours TTN LoRa MQTThellip
Compleacutement drsquoinformations sur les dB et dBm
Ajout LoRa Calculator
Version 30 8032019
Ajout de figure sur le rocircle de la Gateway LoRa
Ajout de paragraphe authentification avec le Network Server
Ajout de paragraphe sur le chiffrement avec lrsquoApplication Server
Ajout drsquoun sommaire en deacutebut de cours
Ajout de 2 scheacutemas ABP et OTAA
Retrait explication du deacutetail de la laquo Join Request raquo en OTAA Trop complexe attente de
reacutealisation drsquoun scheacutema plus explicite
Ajout drsquoun scheacutema sur lrsquoattaque par REPLAY
Ajout de paragraphe des diffeacuterents reacuteseaux LoRaWAN existants Opeacutereacutes et Priveacutes
Ajout des scheacutemas des trames LoRaWAN Physique LoRa MAC Application
Compleacutement drsquoinformation sur les Classes de Devices
Ajout drsquoun paragraphe sur la Gateway utiliseacutee pour le Downlink
Ajout drsquoun paragraphe sur le JSON
Compleacutement drsquoinformation sur le codage en Base64
Ajout drsquoinformation dans le deacutecodage des trames LoRaWAN
Restructuration des explications sur lrsquoenvoi et la reacutecupeacuteration des donneacutees en HTTPMQTT
Version 40 8032019
Ajout drsquoun chapitre Creacuteation de notre propre Application
Ajout drsquoun chapitre Creacuteation de notre propre Network et Application Server
Ajout drsquoune figure Visualisation des Chirps LoRa par SDR (Radio Logicielle)
Compleacutements drsquoinformation sur MQTT
Compleacutements dinformation sur les Topics de TTN en MQTT
| 15
Figure 8 Emission des Chirp en LoRa
Avec un outils drsquoanalyse spectrale actif pendant lrsquoeacutemission LoRa drsquoun Device on peut afficher les
successions de symbole qui sont envoyeacutes Cette oscillogramme a eacuteteacute reacutealiseacute agrave lrsquoaide drsquoun SDR
(Software Digital Radio)
Figure 9 Visualisation des Chirps LoRa reacuteellement eacutemis pendant une transmission
312 Dureacutee drsquoeacutemission drsquoun symbole En LoRa la dureacutee drsquoeacutemission de chaque symbole (Chirp) deacutepend du Spreading Factor utiliseacute Plus le
SF est grand et plus le temps drsquoeacutemission sera long Pour une mecircme bande passante le temps
drsquoeacutemission drsquoun symbole en SF8 est deux fois plus long que le temps drsquoeacutemission drsquoun symbole en
SF7 Ainsi de suite jusqursquoagrave SF12
0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 0 1 1 0 1 0 0 1 1 0 0 1 0 0 0 1 1 0 1
Envoi de 1 Chirp Envoi de 1 Chirp Envoi de 1 Chirp
Transmission Transmission Transmission
| 16
Figure 10 Temps drsquoeacutemission drsquoun symbole (Chirp) en fonction du SF
En revanche le temps drsquoeacutemission drsquoun symbole est inversement proportionnel agrave la bande passante
119879119904 =2119878119865
119861119886119899119889119908119894119889119905ℎ Le deacutebit des symboles est donc de
1
119879119878= 119865119904 =
119861119886119899119889119908119894119889119905ℎ
2119878119865 En toute logique plus la
bande passant est eacuteleveacute plus le deacutebit des symboles sera eacuteleveacute Comme chaque symbole comprend
SF bit on retrouve alors le deacutebit binaire
119863119887 = 119878119865119861119886119899119889119908119894119889119905ℎ
2119878119865
Plus le Spreading Factor sera eacuteleveacute plus le deacutebit binaire sera faible
Plus la Bande Passante sera eacuteleveacutee plus le deacutebit binaire sera fort
Exemple Drsquoapregraves la formule du deacutebit binaire trouver le deacutebit pour les deux cas suivants
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
32 Coding Rate Le Coding Rate est un ratio qui augmentera le nombre de bits agrave transmettre afin de reacutealiser de la
deacutetection correction drsquoerreur Dans le cas drsquoun CR = 4 8 il y aura 8 bits transmis reacuteellement agrave
chaque fois que nous souhaitons transmettre 4 bits Dans cette exemple cela provoque une
transmission drsquoun nombre de bit multiplieacute par 2
SF7
Freacutequence
Temps
Freacutequence centrale
Freacutequence haute
Temps drsquoun symbole eacutemit en SF 12
Freacutequence basse
SF8
SF9
SF10
SF11
SF12
Temps drsquoun symbole eacutemit en SF 11
| 17
Figure 11 Influence du Coding Rate sur le nombre de bits ajouteacute
Si on reprend lrsquoexemple preacuteceacutedent avec un CR de 4 5 nous avons une augmentation de 125 du
nombre de bits agrave transmettre Redonner la deacutebit en prenant en compte le CR
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
La documentation du composant RN2483 donne les deacutebits en fonction du Spreading Factor
la Bande Passante et le Coding Rate Veacuterifier la coheacuterence du reacutesultat avec votre calcul
preacuteceacutedent
Figure 12 Deacutebit en fonction des paramegravetres de la transmission LoRa
33 Utilisation du LoRa Calculator Le logiciel laquo LoRa Calculator raquo est un petit exeacutecutable permettant de simuler une transmission LoRa
en fonction des caracteacuteristiques saisies Canal SF CR etchellip Il est teacuteleacutechargeable agrave lrsquoadresse
suivante httpsbitly2TyloAh
| 18
Figure 13 Le logiciel LoRa Calculator
En reprenant lrsquoexemple preacuteceacutedent (SF7 Bande Passante 125 kHz CR 45) veacuterifier les
calculs du laquo Equivalent Bitrate raquo
34 Time On Air La norme LoRaWAN impose qursquoun Device LoRa ne transmette pas plus de 1 du temps Cela est
repreacutesenteacute par un Duty Cycle Par exemple un Duty Cycle de 1 signifie que si jrsquoeacutemet pendant 1 je
ne dois plus eacutemettre pendant 99 quel que soit lrsquouniteacute de temps utiliseacutee
En reprenant les exemples preacuteceacutedents quels sont les deacutebits moyens si on prend en compte
le laquo Time On Air raquo
Cas 1 Pour SF7 et 125 khz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
Dans le logiciel laquo LoRa Calculator raquo (onglet laquo Energy Profile raquo) nous pouvons estimer la
dureacutee de vie drsquoune batterie Nous prenons lrsquoexemple drsquoun releveacute de tempeacuterature dans un
bacirctiment avec les caracteacuteristiques suivantes
| 19
SF CR Bande Passante etc Nous nous placcedilons dans le cas 1 des exemples preacuteceacutedents
Le releveacute de tempeacuterature se fera toutes les 15 mins
La batterie est constitueacute de 3 petites piles bacirctons [ AAA LR03 ] 12V en seacuterie Soit 36 V
1000 mAh
35 Mise en œuvre LoRa en point agrave point Ce test sera reacutealiseacute avec des modules LoRa RN2483 (Microchip) et une carte microcontrocircleur
ARDUINO
Figure 14 Communication LoRa en Point agrave Point
Reacutealiser le cacircblage de votre module RN2483 suivant le tableau suivant
Connecteur Arduino Click Board RN2483
5V 5V
GND GND
11 RX
10 TX
Tableau 4 Cacircblage de lrsquoARDUINO et de la click Board RN2483
351 Utilisation de lrsquoIDE Arduino Lrsquoenvironnement Arduino est tregraves simple Nous allons reacutealiser un programme pour montrer son
fonctionnement
La connexion de la carte est effectueacutee agrave lrsquoaide drsquoun port USB qui eacutemule une liaison seacuterie
RS232 Il faut donc choisir le bon port Arduino IDE gt Outils gt Port
Pour creacuteer un nouveau programme (sketch) Arduino IDE gt Fichier gt Nouveau
Il y a deux parties dans un sketch
Une fonction setup() qui sera exeacutecuteacutee qursquoune seule fois au deacutemarrage
Une fonction loop() qui sera exeacutecuteacutee en boucle
Ecrire le code suivant
Emetteur
Reacutecepteur
UA
RT
UA
RT
| 20
void setup()
Serialbegin(9600)
void loop()
Serialprintln(hello word)
Compiler et Teacuteleacuteverser Croquis gt Teacuteleacuteverser
Voir la sortie sur la liaison seacuterie Outils gt Moniteur Seacuterie gt Choisir la vitesse de
transmission ici 9600 bauds (en bas agrave droite)
352 Validation du fonctionnement Deux binocircmes joueront le rocircle drsquoeacutemetteur tous les autres binocircmes seront en reacutecepteur
Reacutecupeacuterer les programmes dans Moodle dans le dossier laquo RN2483-Arduino-Point2Point raquo
Installer la librairie RN2483 Arduino IDE gt Croquis gt Inclure une bibliothegraveque gt Ajouter la
bibliothegraveque zip
Reacutepartissez les rocircles Emetteurs Reacutecepteurs et reacutecupeacuterer le programme LoraBlinkerRX ou
LoraBlinkerTX en fonction Les 2 binocircmes en eacutemission devront modifier le code du sketch
Arduino pour transmettre des donneacutees speacutecifiques afin de les diffeacuterencier [
loraSerialprintln(radio tx 30) ]
Validez la reacuteception des donneacutees eacutemises par les deux binocircmes qui transmettent des
donneacutees Ces donneacutees reccedilues sont eacutecrite agrave 57600 bauds sur le moniteur seacuterie de lrsquoArduino
353 Mise en valeur du Spreading Factor On srsquoaperccediloit dans la manipulation preacuteceacutedente que les Devices LoRa reccediloivent les donneacutees des deux
eacutemetteurs Nous allons conserver le mecircme canal drsquoeacutemission (8691 Mhz) mais un des deux
eacutemetteurs va modifier son laquo Spreading Factor raquo La salle sera donc seacutepareacutee en deux groupes
1er groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF7
2egraveme groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF8
Validez la reacuteception des donneacutees eacutemises seulement pour le Spreading Factor que vous
utilisez
| 21
4 Le protocole LoRaWAN
Le LoRa est le type de modulation utiliseacute entre deux Devices ou entre un Device et une Gateway
Lorsque nous parlons de lrsquoensemble de la chaine de communication (Device Gateway Serveur) alors
nous parlons de communication LoRaWAN Nous allons voir lrsquoarchitecture drsquoun reacuteseau LoRaWAN
ainsi que les regravegles de ce protocole
41 Structure drsquoun reacuteseau LoRaWAN Nous retrouvons drsquoun cocircteacute le Device LoRa qui transmet une donneacutee Elle est reacuteceptionneacutee agrave lrsquoautre
extreacutemiteacute du reacuteseau par un Utilisateur La structure globale du reacuteseau LoRaWAN peut ecirctre
repreacutesenteacutee par la figure suivante
411 Les Devices LoRa Les Devices LoRa sont des systegravemes eacutelectroniques appartenant au monde de lrsquoIoT Faible
consommation faible taille faible puissance et faible taille
Ils possegravedent une radio LoRa permettant de joindre les Gateways Les Gateways ne sont pas
adresseacutees speacutecifiquement toutes celles preacutesentes dans la zone de couverture reccediloivent les
messages et les traitent
412 Les Gateways LoRa Elles eacutecoutent sur tous les canaux et sur tous les Spreading Factor Lorsqursquoune trame LoRa est reccedilue
elle transmet son contenu sur internet agrave destination du Network Server qui a eacuteteacute configureacute dans la
Gateway au preacutealable
Elle joue donc le rocircle de passerelle entre une modulation LoRa et une communication IP
Devices
LoRa Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
Internet Internet
Figure 15 Structure globale dun reacuteseau LORAWAN
| 22
Chaque Gateway LoRa possegravede un identifiant unique (EUI sur 64 bits)
413 Le Network Server
Le Network Server reccediloit les messages transmis par les Gateways et supprime les doublons
(plusieurs Gateway peuvent avoir reccedilu le mecircme message) Les informations transmises au Network
Server depuis les Devices LoRa sont authentifieacutes gracircce agrave une cleacute AES 128 bits appeleacutee Network
Session Key NwkSKey Nous parlons bien ici drsquoauthentification et non pas de chiffrement comme
nous le verrons plus tard
414 Application Server Il est souvent sur le mecircme support physique que le Network Server Il permet de dissocier les
applications les unes des autres Chaque application enregistre des Devices LoRa qui auront le droit
Devices Gateways Network
Server
Internet
Network Session Key (NwkSKey)
Authentification
Figure 17 Authentification entre le Device LoRa et le Network Server
Internet
UDP IP
Modulation
LoRa
Device LoRa
Gateway
Network Server
LoRaWAN
Modulation
LoRa
Passerelle LoRa Internet
Internet
UDP IP
LoRaWAN
Transmission Radio
Application Application
Figure 16 Le rocircle de la Gateway LoRa
| 23
de stocker leurs donneacutees (Frame Payload) Les message transmis agrave lrsquoapplication server sont chiffreacutes
gracircce agrave une cleacute AES 128 bits appeleacutee Application Session Key AppSKey
Le scheacutema suivant reacutesume lrsquoutilisation
De la Network Session Key (NwkSKey) pour lrsquoauthentification entre le Device LoRa et le
Network Server
De lrsquoApplication Session Key (AppSKey) pour le chiffrement entre le Device LoRa et
lrsquoApplication Server
Devices Gateways Network
Server Application
Server
Internet
Application Session Key (AppSKey)
Chiffrement
Figure 18 Chiffrement entre le Device LORA et lrsquoApplication Server
| 24
415 Application Web Serveur Cette application doit drsquoune part reacutecupeacuterer les donneacutees de lrsquoApplication Serveur Dans le cadre de
ce cours cela sera fait de deux faccedilons
Avec le protocole HTTP
Avec le protocole MQTT
Figure 20 Application Web Server
Figure 19 Authentification et chiffrement en LoRaWan
Devices Gateways
Network
Server Application
Server
Internet
Network Session Key
Application Session Key
Network
Server Application
Server
Application
Server Web
Utilisateur
Protocole
MQTT ou HTTP
Flux Uplink
Flux Downlink
| 25
Le flux habituel dans lrsquoIoT est le flux Uplink (flux montant) crsquoest-agrave-dire lrsquoeacutemission de donneacutees des
objets vers le serveur Comme nous lrsquoexpliquerons plus loin en LoRaWAN il est aussi possible de
transfeacuterer des donneacutees aux Device LoRa par un flux Downlink (flux descendant)
Drsquoautre part lrsquoapplication mettra agrave disposition les donneacutees aux utilisateurs sous forme par exemple
drsquoun serveur web drsquoune base de donneacutees et drsquoune visualisation graphique
416 Authentification avec le Network Server La Network Session Key (NwkSKey) sert agrave lrsquoauthentification entre le Device LoRa e le Network Server
Afin de reacutealiser cette authentification entre le Device et le Network Server un champ MIC (Message
Integrity Control) est rajouteacute agrave la trame Il est calculeacute en fonction des donneacutees transmises et du
NwkSkey A la reacuteception le mecircme calcul est effectueacute Si les cleacutes sont eacutequivalentes dans le Device et
dans le Network Server alors les deux MIC calculeacutes doivent correspondre
417 Chiffrement des donneacutees vers lrsquoApplication Server
LrsquoApplication Session Key (AppSKey) sert pour le chiffrement entre le Device LoRa et lrsquoApplication
Server Les donneacutees chiffreacutees seront alors deacutecodeacutees agrave la reacuteception sur lrsquoApplication Server srsquoil
possegravede la mecircme cleacute Si on reprend le scheacutema preacuteceacutedent les laquo donneacutees x raquo sont chiffreacutees
deacutechiffreacutees par le processus suivant
Donneacutees x chiffreacutees NwkSkey x
MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees
NwkSkey x
Trame eacutemise Trame reccedilue
Device LoRa Network Server
Si =
Alors la trame est authentifieacutee
MIC geacuteneacutereacute Emission MIC geacuteneacutereacute Reacuteception
MIC geacuteneacutereacute Reacuteception
Figure 21 Authentification dun Device LoRa par le Network Server
| 26
Figure 22 Chiffrement des donneacutees par lApplication Session Key
418 Combinaison de lrsquoauthentification et du chiffrement On peut maintenant repreacutesenter sur le mecircme scheacutema la construction de la trame LoRaWAN avec
drsquoune part lrsquoauthentification et drsquoautre part le chiffrement
Figure 23 Chiffrement puis Authentification
42 Classes des Devices LoRaWAN Les Devices LoRa sont classeacutes en 3 cateacutegories (A B C) en fonction de leur consommation et de leur
accessibiliteacute en Downlink crsquoest-agrave-dire la faciliteacute qursquoun utilisateur aura agrave transmettre une trame au
Device LoRa
421 Classe A (All) Minimal power Application Tous les Devices LoRaWAN sont de classe A Chaque Device peut transmettre (Uplink) agrave la Gateway
sans veacuterification de la disponibiliteacute du reacutecepteur Si la transmission eacutechoue elle sera reacuteeacutemise apregraves
un certain temps Cette transmission est suivie de 2 fenecirctres de reacuteception tregraves courtes La Gateway
peut alors transmettre pendant le laquo RX Slot 1 raquo ou le laquo RX Slot 2 raquo mais pas les deux
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Device LoRa
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Application Server
Donneacutees non chiffreacutees
AppSKey
Donneacutees chiffreacutees Entecircte
NwkSKey
MIC geacuteneacutereacute en eacutemission Trame transmise =
| 27
Figure 24 Slots de reacuteception pour un Device LoRa de classe A
Source de lrsquoimage httpszakelijkforumkpncom
La dureacutee des fenecirctres doit ecirctre au minimum la dureacutee de reacuteception drsquoun preacuteambule Un preacuteambule
dure 1225 Tsymbole et deacutepend donc du Data Rate (DR voir paragraphe 445 pour plus drsquoinformation
sur le DR) Lorsque qursquoun preacuteambule est deacutetecteacute le reacutecepteur doit rester actif jusqursquoagrave la fin de la
transmission Si la trame reccedilue pendant la premiegravere fenecirctre de reacuteception eacutetait bien agrave destination du
Device LoRa alors la deuxiegraveme fenecirctre nrsquoest pas ouverte
Premiegravere fenecirctre de reacuteception
Le Slot RX1 est programmeacute par deacutefaut agrave 1 seconde + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont les mecircme que ceux choisis lors de la phase drsquoeacutemission
(Uplink)
Seconde fenecirctre de reacuteception
Le Slot RX2 est programmeacute par deacutefaut agrave 2 secondes + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont configurables mais fixes
Un Device LoRa qui est uniquement de classe A ne peut pas recevoir srsquoil nrsquoa pas eacutemis Il
nrsquoest donc pas joignable facilement
422 Classe B (Beacon) Scheduled Receive Slot Les Devices de classe B ont le mecircme comportement que les Devices de classe A mais drsquoautres
fenecirctres de reacuteceptions sont programmeacutees agrave des peacuteriodes preacutecises Afin de synchroniser les fenecirctres
de reacuteception du Device LoRa la Gateway doit transmettre des balises (Beacons) de faccedilon reacuteguliegravere
| 28
Figure 25 Slots de reacuteception pour un Device LoRa de classe B
Source de lrsquoimage httpszakelijkforumkpncom
Un Device LoRa de classe B est joignable reacuteguliegraverement sans qursquoil soit neacutecessairement
obligeacute drsquoeacutemettre En revanche il consomme plus qursquoun Device de classe A
423 Classe C (Continuous) Continuously Listening Les Devices de classe C ont des fenecirctres de reacuteception constamment ouvertes entre 2 Uplinks Ces
Devices consomment donc beaucoup plus
Figure 26 Slots de reacuteception pour un Device LoRa de classe C
Source de lrsquoimage httpszakelijkforumkpncom
| 29
Un Device LoRa de classe C est joignable en permanence En revanche crsquoest la classe de
Device qui est la plus eacutenergivore
424 Quelle Gateway pour les flux Downlink
Nous avons donc vu que le fonctionnement classique du protocole LoRaWAN eacutetait de reacutecupeacuterer de
lrsquoinformation depuis le Device LoRa Crsquoest le flux Uplink
Dans le cas ougrave lrsquoutilisateur transmet des informations au Device LoRa (flux Downlink) on peut se
demander quelle Gateway sera choisie pour transfeacuterer les donneacutees au Device LoRa En effet
lrsquoendroit ougrave est situeacute le Device LoRa nrsquoest pas neacutecessairement connu agrave lrsquoavance
La Gateway utiliseacutee pour le Downlink est celle qui a reccedilu le dernier message du Device
LoRa Un message ne pourra jamais arriver agrave destination drsquoun Device LoRa si celui-ci nrsquoa
jamais transmis quel que soit sa classe A B ou C
43 Activation des Devices LoRa et seacutecuriteacute En LoRaWAN les trois eacuteleacutements indispensables pour la communication sont le DevAddr pour
lrsquoindentification du Device ainsi que deux cleacutes le NwkSKey pour lrsquoauthentification et lrsquoAppSKey
pour le chiffrement Deux meacutethodes sont possibles pour fournir ces informations agrave la fois au Device
LoRa et au serveur
Activation By Personalization APB
Over The Air Activation
431 ABP Activation By Personalization Crsquoest la plus simple des meacutethodes Crsquoest donc peut ecirctre celle que nous avons tendance agrave utiliser lors
drsquoun test de prototype et drsquoune mise en place de communication LoRaWAN
Le Device LoRa possegravede deacutejagrave le DevAddr lrsquoAppSKey et le NwkSKey
Le Network server possegravede deacutejagrave le DevAddr et le NwkSKey
Lrsquoapplication serveur possegravede deacutejagrave le DevAddr et le AppSKey
En ABP toutes les informations neacutecessaires agrave la communication sont deacutejagrave connues par le
Device LoRa et par le Serveur
| 30
432 OTAA Over The Air Activation Crsquoest la meacutethode qursquoil faut privileacutegier car crsquoest celle qui est la plus seacutecuriseacutee Le Device LoRa doit
connaitre le DevEUI lrsquoAppEUI et lrsquoAppkey Le Network Server doit lui connaitre la mecircme Appkey
Tous les eacuteleacutements noteacutes EUI (Extended Unique Identifier) sont toujours sur une taille de
64 bits
Gracircce agrave ces informations de deacutepart et une neacutegociation avec le Network Server (Join Request) le
Device LoRa et le serveur vont geacuteneacuterer les informations essentielles DevAddr NwkSKey et
AppSKey
Figure 28 Obtention du DevAddr NwkSKey et AppSKey en OTAA
DevEUI Unique Identifier pour le device LoRa (Equivalent agrave une MAC sur Ethernet)
Certains Device LoRa ont deacutejagrave un DevEUI fourni en usine
AppEUI Unique Identifier pour lrsquoapplication server
DevEUI
AppEUI
AppKey
Join
Request
DevAddr
NwkSKey
AppSKey
Network Server
Application Server
Devices 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 2
NwkSkey 2
AppSKey 2
Devices 2
DevAddr 2
NwkSkey 2
AppSKey 2
Paramegravetres stockeacutes sur le serveur
Paramegravetres programmeacutes
dans le composant
Figure 27 Parameacutetrage de DevAddr NwkSKey et AppSKey
| 31
AppKey AES 128 cleacute utiliseacutee pour geacuteneacuterer le MIC (Message Code Integrity) lors de la Join
Resquest Il est partageacute avec le Network server
NwkSKey Utiliseacute pour lrsquoauthentification avec le Network Server
AppSKey Utiliseacute pour le chiffrement des donneacutees
433 Seacutecuriteacute Les cleacutes AES 128 bits permettent le chiffrement des informations transmises en LoRaWAN Malgreacute
ce chiffrement une attaque connue en Wireless est celle du REPLAY Crsquoest-agrave-dire que le Hacker
enregistre des trames chiffreacutees circulant sur le reacuteseau LoRa pour les reacuteeacutemettre plus tard Mecircme si
le Hacker ne comprend pas le contenu (les trames sont chiffreacutees) les donneacutees qui sont transporteacutees
sont elles bien comprises par lrsquoApplication Server Des actions peuvent donc ecirctre reacutealiseacutees
simplement par mimeacutetisme
Pour eacuteviter cela la trame LoRaWAN integravegre un champ variable appeleacute laquo Frame Counter raquo Il srsquoagit
drsquoun nombre numeacuterotant la trame sur 16 ou 32 bits LrsquoApplication Server acceptera une trame
uniquement si le laquo Frame Counter raquo reccedilu est supeacuterieur au laquoFrame Counter raquo preacuteceacutedemment Donc
si le Hacker retransmet la trame telle qursquoelle le laquo Frame Counter raquo sera eacutequivalent donc la trame
sera refuseacutee Et comme la trame est chiffreacutee le Hacker nrsquoa pas moyen de savoir comment modifier
un champ de cette trame
Cette seacutecuriteacute impleacutementeacutee par les laquo Frame Counter raquo est inteacuteressante pour srsquoaffranchir drsquoune
attaque par REPLAY mais dans nos tests cela peut poser problegraveme En effet agrave chaque fois que nous
redeacutemarrons le microcontrocircleur notre laquo Frame Counter raquo revient agrave zeacutero alors que celui de
lrsquoApplication Server continue de srsquoincreacutementer Cela peut ecirctre reacutesolue par diffeacuterentes maniegraveres
1 Deacutesactivation du laquo Frame Counter Check raquo Dans certain Application Server cette option
peut ecirctre proposeacutee Bien sucircr il faudra garder en tecircte la faille de seacutecuriteacute que cela engendre
Network Server
Application Server
Devices LoRa
NwkSkey
AppSKey
NwkSkey
AppSKey Hacker
(1) (2)
(1) Ecoute
(2) Reacuteeacutemission
Figure 29 Attaque par REPLAY
| 32
Figure 30 Deacutesactivation du Frame Counter Check dans TTN
2 Utiliser lrsquoauthentification par OTAA au lieu de ABP En effet agrave chaque ouverture de session
en OTAA le laquo Frame Counter raquo est reacuteinitialiseacute coteacute serveur
3 Conserver la valeur du laquo Frame Counter raquo dans une meacutemoire non volatile et reacutecupeacuterer sa
valeur au deacutemarrage du Device LoRa
44 La Trame LoRa LoRaWAN
441 Les couches du protocole LoRaWAN
Lorsque nous avons fait une communication en Point agrave Point nous avons simplement utiliseacute la
couche physique de la modulation LoRa Lorsque nous souhaitons utiliser le protocole LoRaWAN
des couches protocolaires suppleacutementaires se rajoutent
Figure 31 Les couches protocolaires du LoRaWAN
Chaque couche rajoute un service Lors de lrsquoenvoi de la trame les donneacutees utilisateurs sont donc
encapsuleacutees dans chaque couche infeacuterieure jusqursquoagrave la transmission Le deacutetail de lrsquoensemble de la
trame LoRaWAN par couche est deacutecrit sur la figure Figure 32
LoRa Modulation
LoRa Mac
Application
Couche Physique
Couche Mac
Couche Application
| 33
442 Couche Application La couche Application accueille les donneacutees de lrsquoutilisateur Avant de les encapsuler elles sont
chiffreacutees avec lrsquoAppSKey afin de seacutecuriser la transaction
Un ensemble de champs nommeacute Frame Header permet de speacutecifier le DevAddr le Frame Control
le Frame Counter et le Frame Option
Le Frame Port deacutepend du type drsquoapplication et sera choisi par lrsquoutilisateur
Le Frame Payload sont les donneacutees chiffreacutees agrave transmettre Le nombre drsquooctets maximum pouvant
ecirctre transmis (N octets) est donneacute dans le tableau suivant
PHY Payload
P octets Couche
Physique
Couche
Mac
Couche
Application
CRC
2 octets Header + Header CRC
20 bits Preamble
MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Figure 32 Trame LORAWAN complegravete par couche protocolaire
Couche
Application Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Frame Header
Figure 33 Trame LORA couche Applicative
| 34
Data Rate Spreading Factor Bandwidth Max Frame Payload (Nombre N) DR 0 SF12 125 KHz 51 octets
DR 1 SF11 125 KHz 51 octets
DR 2 SF10 125 KHz 51 octets
DR 3 SF9 125 KHz 115 octets
DR 4 SF8 125 KHz 222 octets
DR 5 SF7 125 KHz 222 octets
DR 6 SF7 250 KHz 222 octets
Tableau 5 Taille maximum du Frame Payload en fonction du Data Rate
443 Couche LoRa MAC Cette trame est destineacutee au Network Server Elle est authentifieacutee gracircce au champ MIC (Message
Integrity Protocol) selon la meacutethode expliqueacutee au paragraphe 416
Le protocole LoRa MAC est composeacute de
1 MAC Header Version de protocole et type de message
Type de Message Description 000 Join-Request
001 Join-Accept
010 Unconfirmed Data Up
011 Unconfirmed Data Down
100 Confirmed Data Up
101 Confirmed Data Down
110 Rejoin-request
111 Proprietary
Tableau 6 Les types de messages transmis en LoRaWAN
2 MAC Payload Contient tout le protocole applicatif
3 MIC Message Integrity Code pour lrsquoauthentification de la trame
444 Couche physique Modulation LoRa
Le choix du moment drsquoeacutemission des Devices LoRa se fait de faccedilon simple Lorsqursquoun eacutequipement
doit eacutemettre il le fait sans controcircle et ne cherche pas agrave savoir si le canal est libre Si le paquet a eacuteteacute
perdu il le retransmettra simplement au bout drsquoun temps aleacuteatoire La couche physique est
repreacutesenteacutee par lrsquoeacutemission de la trame suivante
Couche
Mac MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Figure 34 Trame LORA couche LORA MAC
| 35
Le Preacuteambule est repreacutesenteacute par 8 symboles + 425 Le temps du Preacuteambule est donc de 1225
Tsymbole
Len-tecircte (Header optionnel) est seulement preacutesent dans le mode de transmission par deacutefaut
(explicite) il est transmis avec un Coding Rate de 48 Il indique la taille des donneacutees le Coding Rate
pour le reste de la trame et il preacutecise eacutegalement si un CRC sera preacutesent en fin de trame
Le PHY Payload contient toutes les informations de la Couche LoRa MAC
Le CRC sert agrave la deacutetection drsquoerreur de la trame LoRa
445 Canaux et bandes de freacutequences et Data Rate (DR) Le LoRa utilise des bandes de freacutequences diffeacuterentes suivant les reacutegions du monde En Europe la
bande utiliseacutee est celle des 868 Mhz [ De 863 Mhz agrave 870 Mhz ] Le LoRaWAN deacutefinie les 8 canaux agrave
utiliser pour communiquer avec une Gateway suivant le tableau suivant
Canaux Spreading Factor Bandwidth 8681 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz SF7 250 kHz
8685 Mhz De SF7 agrave SF12 125 kHz
8671 Mhz De SF7 agrave SF12 125 kHz
8673 Mhz De SF7 agrave SF12 125 kHz
8675 Mhz De SF7 agrave SF12 125 kHz
8677 Mhz De SF7 agrave SF12 125 kHz
8679 Mhz De SF7 agrave SF12 125 kHz
Tableau 7 Canaux SF et Bandwidth de notre Gateway LoRaWAN
Une Gateway LoRa eacutecoute donc sur 8 canaux simultaneacutement avec les 6 Spreading Factor
diffeacuterents soit 48 combinaisons possibles
Comme nous lrsquoavons vu le Spreading Factor a des conseacutequences sur le deacutebit de la transmission Ces
deacutebits sont noteacutes DR (Data Rate) et sont normaliseacutes de DR0 agrave DR6
PHY Payload
P octets Couche
Physique CRC
2 octets Header + Header CRC
( Optionnel ) 20 bits Preamble
Figure 35 Trame LORA couche Physique
| 36
Data Rate Spreading Factor Bandwidth DR 0 SF12 125 KHz
DR 1 SF11 125 KHz
DR 2 SF10 125 KHz
DR 3 SF9 125 KHz
DR 4 SF8 125 KHz
DR 5 SF7 125 KHz
DR 6 SF7 250 KHz
Tableau 8 Deacutenomination DR en fonction du SF et de la Bande Passante
446 Trame reccedilue et transmise par la Gateway LoRaWAN La Gateway reccediloit drsquoun cocircteacute un message radio moduleacute en LoRa et transmet de lrsquoautre cocircteacute une trame
IP agrave destination du Network Server
Coteacute interface Radio La Gateway reacuteceptionne une trame LoRaWAN et extrait le PHY Payload Celui-
ci est codeacute au format ASCII en base 64 (voir le paragraphe 541) La Gateway extrait aussi toutes les
informations utiles sur les caracteacuteristiques de la reacuteception qui a eu lieu SF Bandwidth RSSI Time
On Airhellipetchellip
Coteacute interface reacuteseau IP La Gateway transmet lrsquoensemble de ces informations dans un paquet IP
(UDP) au Network Server Les donneacutees transmises sont du texte en format JSON (voir paragraphe
447) La Gateway a donc bien un rocircle de passerelle entre le protocole LoRa drsquoun cocircteacute et un reacuteseau
IP de lrsquoautre
Internet
UDP IP
Device LoRa
Gateway
Network Server Modulation
LoRa
Passerelle LoRa Internet
Transmission Radio Internet
Figure 36 Rocircle de la Gateway LoRa
| 37
447 Le format JSON Le format JSON est un format texte composeacute drsquoune succession de couple nomvaleur Dans
lrsquoexemple de la figure preacuteceacutedente gw_id est un nom et eui-b827ebfffeae26f5 est la valeur
associeacutee Dans cette exemple la valeur est un string Les objets sont deacutelimiteacutes par un des accolades
et
Une valeur peut ecirctre
Un string exemple coding_rate 45
Un nombre exemple spreading_factor 12
Un objet exemple lora spreading_factor 12 air_time 2465792000
Un Boolean
Ethernet
Gateway
Modulation
LORA
Reacutecupeacuteration du PHY PAYLOAD en base 64
Reacutecupeacuteration des caracteacuteristiques de la transmission Canal SF CR hellip
IP (IP dest routereuthethingsnetwork)
UDP (Port dest 1700 Port source 1700)
Donneacutees applicatives (format JSON)
gw_id eui-b827ebfffeae26f5
payload QNAPvA6Ax3ECqHk4C8hfzuA==
lora
spreading_factor 12
bandwidth 125
air_time 2465792000
coding_rate 45
timestamp 2019-01-20T133746017Z
rssi -105
snr -162
dev_addr 0EBC0FD0
frequency 867100000
Internet Transmission Radio LORA
Figure 37 Passerelle (Gateway) LORAWAN
| 38
5 Mise en œuvre drsquoun reacuteseau LoRaWAN
51 Les diffeacuterents types de reacuteseaux Les reacuteseaux LoRaWAN peuvent ecirctre utiliseacute suivant deux meacutethodes
En utilisant les reacuteseaux LoRaWAN opeacutereacutes proposeacutes par les opeacuterateurs de teacuteleacutecoms
En utilisant votre propre reacuteseau LoRaWAN priveacute
511 Les reacuteseaux LoRaWAN opeacutereacutes Ce sont des reacuteseaux LoRaWAN proposeacutes par les opeacuterateurs Par exemple Objenious (filiale de
Bouyges) ou encore Orange Dans le cas de lrsquoutilisation des reacuteseaux opeacutereacutes lrsquoutilisateur a juste
besoin de srsquooccuper des Devices LoRa Les Gateways le Network Server et lrsquoApplication Server sont
geacutereacutes par lrsquoopeacuterateur
512 Les reacuteseaux LoRaWAN priveacutes Chacun est libre de reacutealiser son propre reacuteseau priveacute en impleacutementant sa propre Gateway pour
communiquer avec ses Devices LoRa Lrsquoimpleacutementation du Network Server et de lrsquoApplication Server
peuvent alors ecirctre envisageacutes de diffeacuterentes faccedilons
Network Server et Application serveur priveacutees Crsquoest le deacuteveloppeur qui les mets en place Dans
certaines Gateways une impleacutementation de ces deux serveurs est deacutejagrave proposeacutee Sinon il est
possible de la mettre en place Il existe des serveurs (Network et Application) open source crsquoest le
cas par exemple de LoRa Serveur [ wwwloraserverio ]
Une autre alternantive est httpsgithubcomgotthardplorawan-server
LoRaServer et lorawan-server sont deux applications Open Source
Network Server et Application Server en ligne Un certain nombre de Network Server et
drsquoApplication Server sont proposeacutes Ce sont des services payants ou avec des contreparties
Loriot [ wwwloriotio ]
ResIoT [ wwwresiotio ]
The Things Network [ wwwthethingsnetworkorg ] Crsquoest la solution que nous utiliserons
513 Les zones de couvertures
Les zones de couvertures des reacuteseaux opeacutereacutes sont mise agrave jour par les opeacuterateurs celle drsquoobjenious
est par exemple disponible ici httpsobjeniouscomreseau
Pour connaitre la zone de couverture de notre Gateway utiliseacutee avec TTN nous pouvons utiliser
lrsquoapplication TTN Mapper httpsttnmapperorg Lrsquoideacutee est de promener son Device LoRa associeacute
agrave un GPS dans la zone de couverture des Gateway qui nous entourent A chaque trame reccedilue par le
| 39
Serveur on note les coordonneacutees GPS du Device LoRa ainsi que la Gateway qui a transmis le
message Toutes ces informations sont alors retranscrites sur une carte
52 The Things Network (TTN)
521 Preacutesentation de TTN
Pour la suite nous utiliserons le Network Server et lrsquoApplication Server fourni par TTN
[wwwthethingsnetworkorg]
TTN est gratuit et Open Source En revanche le fait drsquoutiliser TTN impose agrave ceux qui enregistrent
des Gateways de les mettre agrave disposition agrave tous les autres utilisateurs de TTN Lrsquoobjectif est de
reacutealiser un reacuteseau global ouvert
522 Configuration de la Gateway A lrsquouniversiteacute nous avons deux Gateways LoRa (Marque EBDS) Elles sont toutes les deux situeacutees sur
le Campus de Technolac Une Gateway est agrave lrsquointeacuterieur du bacirctiment ISERAN et sert essentiellement
pour les Travaux Pratiques et formations Lrsquoautre est sur le toit du bacirctiment Chablais et est mise agrave
disposition du public via le service de TTN
Les deux Gateway eacutecoutent sur tous les canaux et sur tous les Spreading Factor SF7 gt SF12
Lrsquo IP de la Gateway LoRa agrave lrsquouniversiteacute (bacirctiment ISERAN) est 192168140196
Serveur DNS 1934812032 19348129137
Network Server (TTN) 137616868 routereuthethingsnetwork
Port Upstream 1700 Port Downstream 1700
523 Enregistrement des Gateways Appplication et Devices La configuration de TTN se fait en ligne La premiegravere opeacuteration agrave reacutealiser lorsqursquoune nouvelle
Gateway est deacuteployeacutee crsquoest de lrsquoenregistrer dans TTN
Enregistrement drsquoune Gateway LoRa TTN gt Console gt Gateway gt register gateway
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Figure 38 Scheacutema de notre application
| 40
Figure 39 Enregistrement dune Gateway LoRa sur TTN
Enregistrement drsquoune application TTN gt Console gt Application gt add application
Figure 40 Enregistrement dune application sur TTN
Enregistrement des Devices LoRa dans lrsquoapplication Nom de lrsquoapplication gt register device
Figure 41 Enregistrement des Devices LoRa dans une application
524 Configuration des Devices LoRa Lorsque nous avons enregistreacute des Devices LoRa dans TTN nous devons choisir entre les deux modes
drsquoauthentification Dans un premier temps nous utiliserons le mode le plus simple qui est ABP Nous
geacuteneacuterons dans TTN les DevAddr NetwkSKey et AppSKey
| 41
Figure 42 Configuration des Devices LoRa en ABP dans TTN
53 Mise en application Nous avons dans notre application 10 Devices LoRa drsquoenregistreacutes aduino0 agrave arduino9 Ils sont tous
configureacutes en ABP Les configurations des 10 Devices (DevAddr NetwkSKey et AppSKey) sont noteacutes
en commentaire dans le code de vous allez reacutecupeacuterer
Reacutecupeacuterer le code Arduino laquo RN2483-Arduino-LORAWANino raquo dans Moodle
Modifier votre configuration (DevAddr NetwkSKey et AppSKey) en fonction de votre
numeacutero de binocircme
Veacuterifier que votre Device LoRa arrive bien agrave transmettre des informations (Uplink) vers la
Gateway puis vers le Network Serveur de TTN (The Things Network)
54 Analyse des trames eacutechangeacutees
541 Utilisation de la base 64 Notre Gateway nous preacutesente le Payload PHY en base64 Lrsquoexplication de la meacutethode de
repreacutesentation en base 64 est fourni au travers drsquoun exemple Le code hexadeacutecimal 0x4869
repreacutesente nos donneacutees binaires que nous souhaitons transmettre en base 64
1 On eacutecrit les donneacutees agrave transmettre en binaire
2 On regroupe les eacuteleacutements binaires par des blocs de 6 bits Le nombre de bloc de 6 bits doit
ecirctre un multiple de 4 (minimum 4 blocs) Srsquoil manque des bits pour constituer un groupe de
6 bits on rajoute des zeacuteros
0x4869 = 0100 1000 0110 1001
| 42
3 Srsquoil manque des blocs pour faire un minimum de 4 blocs des caractegraveres speacuteciaux seront
ajouteacutes
4 Chaque groupe de 6 bits est traduit par le tableau suivant (Source Wikipeacutedia)
Figure 43 Codage en base 64
5 Si un bloc de 6 bits manque (ils doivent ecirctre un multiple de 4) on rajoute un ou plusieurs
compleacutements (caractegravere laquo = raquo )
Reacutesultat Le codage de 0x4869 en base 64 est laquo SGk= raquo
010010 000110 100100
On ajoute 00 pour avoir
6 bits dans le groupe
Bloc de 6 bits
010010 000110 100100
S G k
010010 000110 100100
S G k =
1er Bloc
2egraveme Bloc
3egraveme Bloc
4egraveme Bloc
| 43
542 Inteacuterecirct et inconveacutenient de la base 64 Lrsquoutilisation de la base 64 est un choix qui a eacuteteacute fait pour le protocole LoRa LoRaWAN afin de rendre
les donneacutees binaires lisibles Le problegraveme du code ASCII crsquoest qursquoil est composeacute drsquoun certain nombre
de caractegraveres non imprimables (EOF CR LFhellip) Pour eacuteviter ces soucis la base 64 ne comporte que
64 caractegraveres imprimables (voir tableau ci-dessus)
La restriction agrave 64 caractegraveres a cependant un inconveacutenient crsquoest que nous ne pouvons coder que 6
bits (26=64) au lieu de 8 La base 64 est donc moins efficace drsquoune faccedilon geacuteneacuterale
Nous cherchons agrave coder le code ASCII laquo AA raquo en base 64 Retrouver la deacutemarche en
montrant que le reacutesultat en base 64 est laquo QUE= raquo
543 Uplink Du Device LoRa au Network Server Le Network Server de TTN reccediloit des trames IP en provenance de la Gateway Comme nous lrsquoavons
vu preacuteceacutedemment un certain nombre drsquoinformations peuvent ecirctre retrouveacutees avec cette trame
(DevAddr SF Bandwidth etchellip) mais les donneacutees Applicatives sont bien sucircr chiffreacutees (avec
lrsquoAppkSKey) A ce niveau de reacuteception (sans connaitre lrsquoAppSKey) il nrsquoest donc pas possible de
comprendre la totaliteacute du message reccedilu
Imaginons que la trame IP reccedilue 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 45
timestamp 2019-03-05T140042448Z
rssi -82
snr 9
dev_addr 26011AD3
frequency 867300000
Le Network Server affiche donc les informations de la faccedilon suivante
Figure 44 Trame reacutecupeacutereacutee sur le laquo Network Server raquo de TTN
Nous retrouvons bien les valeurs fournies par la Gateway
timestamp ( agrave 1 heure pregraves en fonction du fuseau horaire)
| 44
frequency 8673 Mhz
modulation Lora
Coding Rate 45
data Rate SF 7 125 kHz (DR5)
air time 463 ms
Drsquoautres information proviennent de lrsquoanalyse du Payload Le Payload inscrit ici est le PHY Payload
Il y a donc une partie chiffreacutee (Frame Payload) mais les entecirctes sont en claires (voir paragraphe
441) Ce PHY Payload est laquo QNMaASYABwAP1obuUHQ= raquo Lorsque celui-ci est exprimeacute en
hexadeacutecimal au lieu de la base 64 il vaut laquo 40D31A01260007000FD686EE5074 raquo comme le montre
le Network Server de TTN
Figure 45 PHY Payload preacutesenteacute dans notre Network Server
Sa taille est bien de 14 octets (en hexadeacutecimal) comme preacuteciseacute sur la Figure 44
Nous reprenons le format de la trame LoRaWAN vu agrave la Figure 32 Nous pouvons alors retrouver
tous les champs de toute la trame
PHYPayload = 40D31A01260007000FD686EE5074
PHYPayload = MAC Header[1 octet] | MACPayload[] | MIC[4 octets]
MAC Header = 40 (Unconfirmed data up)
MACPayload = D31A01260007000FD6
Message Integrity Code = 86EE5074
MACPayload = Frame Header | Frame Port | FramePayload )
Frame Header = D31A0126000700
FPort = 0F
FramePayload = D6
Frame Header = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[015]
DevAddr = 26011AD3 (Big Endian)
FCtrl (Frame Control) = 00 (No ACK No ADR)
FCnt (Frame Counter) = 0007 (Big Endian)
FOpts (Frame Option) =
Vous pouvez veacuterifier lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN
(LoRaWAN packet decoder) httpsbitly2szdXtv
| 45
Figure 46 LoRaWAN packet decoder
544 Uplink Du Network Server agrave lrsquoApplication Server
Nous reprenons lrsquoexemple de la trame ci-dessus (Figure 45) Pour information les cleacutes NwkSKey et
AppSKey suivantes ont eacuteteacute utiliseacutee
NwkSKey E3D90AFBC36AD479552EFEA2CDA937B9
AppSKey F0BC25E9E554B9646F208E1A8E3C7B24
Le Network Server a deacutecodeacute lrsquoensemble de la trame Si le MIC est correct (authentification de la
trame par le NwkSKey) alors le Network Server va passer le contenu du message chiffreacute (Frame
Payload) agrave lrsquoApplication Server Dans notre cas le Frame Payload est (drsquoapregraves le deacutecodage effectueacute
au chapitre preacuteceacutedent)
FramePayload = D6
D6 est le contenu chiffreacute lorsqursquoil est deacutechiffreacute avec lrsquoAppSkey on trouve 01 Vous pouvez veacuterifier
lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN httpsbitly2szdXtv
A noter que lrsquoApplication Server recevra les donneacutees chiffreacutees seulement si le Device LoRa a bien
eacuteteacute enregistreacute On peut aussi veacuterifier ci-dessous que lrsquoApplication Serveur de TTN nous retourne bien
un payload (Frame Payload) de 01
Figure 47 Trame reacutecupeacutereacutee sur lrsquoApplication Server de TTN
time 2019-03-05T140042379279991Z
frequency 8673
modulation LORA
data_rate SF7BW125
coding_rate 45
gateways [
gtw_id eui-b827ebfffeae26f6
timestamp 2447508531
time
channel 4
rssi -82
snr 9
latitude 4563647
longitude 58721523
| 46
location_source registry
]
545 Simulation drsquoUplink dans lrsquoApplication Server
Dans beaucoup de situations nous souhaitons valider le fonctionnement de lrsquoApplication Server de
TTN ouet de notre propre Application Il est donc tregraves utile de pouvoir simuler lrsquoenvoi drsquoune trame
LoRa sur lrsquoApplication Server sans que celle-ci soit reacuteellement eacutemise par un Device LoRa Pour cela
un outil existe dans les Settings de chaque Device enregistreacute dans TTN Nous avons juste besoin de
speacutecifier le Frame Payload en clair en hexadeacutecimal et le numeacutero de Port
Figure 48 Simulation drsquoune trame envoyeacutee par un Device LoRa
546 Downlink De lrsquoApplication Server au Device LoRa La communication LoRa est bidirectionnelle Des donneacutees peuvent ecirctre transmis au Device LoRa
depuis lrsquoApplication Server Depuis TTN un outil existe dans les Settings de chaque Device
enregistreacute Lrsquointerface est repreacutesenteacutee ci-dessous
Figure 49 Transmission de donneacutees de lrsquo laquo Application Server raquo jusqursquoau Device LoRa
Replace scheduling Mode Par deacutefaut le Frame Payload transmis remplacera le Frame
Payload en attente (si il existe) Dans ce mode un seul Frame Payload est planifieacute
First scheduling Mode Le Frame Payload est mis en file drsquoattente en premiegravere position
Last scheduling Mode Le Payload est mis en file drsquoattente en derniegravere position
Une demande de confirmation peut ecirctre demandeacutee au Device LoRa pour qursquoil preacutecise srsquoil a bien reccedilu
les donneacutees Lrsquooption laquo confirmed raquo permet donc de speacutecifier le type de trame dans le MAC Header
(voir paragraphe 443) laquo Confirmed Data Down raquo ou laquo Unconfirmed Data Down raquo dans notre cas
| 47
6 La reacutecupeacuteration des donneacutees sur notre propre Application
Nous utiliserons agrave nouveau le Network Server et Application Server de The Things Network Jusqursquoici
nous nous sommes contenteacute de veacuterifier que les donneacutees de lrsquoutilisateur (Frame Payload) soient bien
arriveacutees agrave destination dans lrsquoApplication Server Il faut maintenant les reacutecupeacuterer avec notre propre
Application qui aura pour rocircle
De stocker et traiter les donneacutees
De les mettre agrave disposition de lrsquoutilisateur (Serveur Web par exemple)
Drsquoenvoyer des commandes de lrsquoutilisateur aux Devices LoRa si besoin (Flux Downlink)
Nous allons voir deux meacutethodes pour communiquer entre notre application et TTN
Le protocole HTTP POST
Le protocole MQTT
61 Reacutecupeacuteration des donneacutees en HTTP POST dans lrsquoApplication
611 Preacutesentation du protocole HTTP
Dans le monde de lrsquointernet le protocole HTTP est tregraves utiliseacute pour le dialogue entre un client et un
serveur web Classiquement le client (un navigateur web par exemple) fait une requecircte HTTP GET
et le serveur lui retourne le contenu de la page web demandeacutee
Dans notre cas la probleacutematique est diffeacuterente car le client doit modifier le contenu du serveur
avec les donneacutees envoyeacutees par le Device LORA La requecircte srsquoappelle HTTP POST Son nom indique
que le client va poster (et on pas reacutecupeacuterer) des donneacutees
Lrsquoutilisateur qui souhaite reacuteceptionner des donneacutees sur son serveur doit donc concevoir un serveur
HTTP capable de traiter des requecirctes HTTP POST [ requecircte noteacutee (1) sur la Figure 51 ] fournies par
TTN Dans cette configuration TTN jouera le rocircle de client et notre application le rocircle de serveur
Devices
LORA Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
HTTP POST
MQTT Internet
Figure 50 Structure globale drsquoun reacuteseau LORAWAN
| 48
Figure 51 Communication bidirectionnelle entre TTN et notre Application
A lrsquoinverse lrsquoutilisateur qui souhaite transmettre des donneacutees agrave destination du Device LoRa
(Downlink) doit ecirctre capable de fournir une requecircte HTTP POST [ requecircte noteacutee (2) sur la Figure 51
] vers TTN Dans cette configuration TTN jouera le rocircle de Serveur et notre application le rocircle de
client
612 Fonctionnement drsquoun client et drsquoun serveur HTTP POST Afin de bien comprendre le fonctionnement des requecirctes HTTP POST nous allons proceacuteder par
eacutetape Le premier test que nous effectuerons sera decorreacuteleacute de TTN Le principe est le suivant
Utilisation drsquoun serveur HTTP disponible sur le web geacuterant les requecirctes HTTP POST [
httpsrbasketsin ] ou [ httpsbeeceptorcom ] par exemple
Utilisation drsquoun client HTTP eacutemettant des requecirctes HTTP POST commande curl sous linux
ou logiciel Postman [ wwwgetpostmancom ] sous windows par exemple
Ce test nous permet de valider le fonctionnement drsquoun serveur HTTP POST et drsquoun client HTTP POST
Une fois que nous serons sucircr de leur fonctionnement nous les utiliserons avec TTN
The Things Network
Application
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 49
Figure 52 Validation dun server HTTP POST et drsquoun client HTTP POST
613 Test du serveur HTTP POST Nous utiliserons un serveur web proposeacute par httpsrbasketsin
Aller sur le site httpsrbasketsin et creacuteer un nouveau laquo Basket raquo Zone ougrave vous pourrez
visualiser les requecirctes qui ont eacuteteacute eacutemises vers votre serveur
A partir de maintenant toutes les requecirctes dirigeacutees vers lrsquoadresse creacuteeacute seront traiteacutees et
srsquoafficheront Dans le menu de configuration il est aussi possible de deacutefinir le contenu de la reacuteponse
qui sera fournie
Deacutefinir un format de reacuteponse pour les requecirctes HTTP POST avec un body personnaliseacute
614 Test du client HTTP POST On peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande (la commande cURL
srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN sous Windows
Commande cURL curl ndashX POST ndashd lsquorsquodonneacutees agrave envoyerrsquorsquo DuServeurHTTP
Logiciel Postman New gt Request gt Creacuteer une requecircte HTTP POST gt Send
Veacuterifier que les requecirctes HTTP POST sont bien reacutecupeacutereacutees sur votre serveur creacutee preacuteceacutedemment
615 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST
Maintenant que nous avons un serveur HTTP (POST) fonctionnel nous allons configurer TTN pour
jouer le rocircle du client et pour qursquoil envoie des requecirctes HTTP POST vers notre Serveur degraves qursquoune
donneacutee drsquoun Device LoRa est disponible Nous geacuterons donc ici le flux Uplink
Requecircte
HTTP POST
Reacuteponse
(contenu parameacutetrable)
Client HTTP (POST)
Server HTTP (POST) [ httpsrbasketsin ]
| 50
Figure 53 Reacutecupeacuteration des donneacutees sur notre Application
Dans TTN nous inteacutegrons un bloc appeleacute laquo HTTP Integration raquo permettant de jouer le rocircle de client
crsquoest-agrave-dire drsquoenvoyer des requecirctes HTTP POST agrave destination de notre nouveau Serveur HTTP
Lrsquointeacutegration se faire agrave partir de TTN gt Console gt Application gt Nom_de_votre_application gt
Integration
Figure 54 Ajout dun client HTTP POST dans TTN
Pour valider le fonctionnement de notre architecture nous pouvons soit
Envoyer une trame depuis un Device LoRa vers TTN
Simuler lrsquoenvoi drsquoune trame drsquoun Device LoRa vers TTN (gracircce agrave lrsquooutil proposeacute par TTN vu
paragraphe 545)
Dans les deux cas voici un exemple de requecircte POST reccedilue sur notre serveur HTTP
app_id test_app_lorawan_sylvainmontagny
dev_id stm32lorawan_1
hardware_serial 0056AF49877
port 1
counter 0
payload_raw qg==
metadata
Requecircte
HTTP POST
Server HTTP (POST) [ httpsrbasketsin ]
The Things Network (Client)
La requecircte contient le Frame Payload deacutechiffreacutee
agrave transmettre agrave lrsquoApplication
| 51
time 2019-01-24T15243703499298Z
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Comme nous pouvons le voir le contenu fourni agrave notre serveur est formateacute en JSON (voir
paragraphe 0) Voici quelques compleacutements drsquoinformation
payload_raw Frame Payload deacutechiffreacute crsquoest donc les donneacutees en clairs dans la base 64
downlink_url URL du serveur HTTP POST qui serviront agrave transmettre des donneacutees au Device
LoRa (flux Downlink)
611 Envoyer des donneacutees depuis notre Application avec HTTP POST
Lorsque nous avons ajouteacute le bloc laquo HTTP Integration raquo au paragraphe preacuteceacutedent nous avons aussi
implicitement activeacute la fonctionnaliteacute que TTN soit precirct agrave recevoir et agrave traiter les requecirctes HTTP
POST La seule information qursquoil nous manque est lrsquoadresse du server HTTP vers lequel il faut eacutemettre
les requecirctes Si on observe la trame reccedilue preacuteceacutedemment en provenance de TTN on srsquoaperccediloit que
dans la trame JSON reccedilu une URL (downlink_url) est speacutecifieacutee
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Crsquoest cette URL que nous devrons utiliser Nous allons nous placer dans la configuration suivante
Figure 55 Envoi de donneacutees agrave partir de notre Application
Comme preacuteceacutedemment on peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande
(la commande cURL srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN
Commande cURL curl ndashX POST ndashdata lsquo dev_id Identidiant_De_Votre_Device
payload_raw AQE= rsquo DuServeurHTTP
Logiciel Postman New gt Request gt HTTP POST puis Body gt Raw gt JSON
Requecircte HTTP POST vers serveur TTN laquo downlink_url raquo httpsintegrationsthethingsnetworUaeb8ypKieQ
Contenu de la requecircte
dev_id Identidiant_De_Votre_Device
payload_raw aGVsbG8=
The Things Network (Serveur)
POSTMAN (Client HTTP POST)
| 52
dev_id YourDeviceID
payload_raw aGVsbG8=
Vous devez envoyer le texte (payload_raw) en base 64 Dans lrsquoexemple ci-dessus laquo aGVsbG8= raquo
correspond agrave la chaine de caractegravere laquo hello raquo Vous pouvez utiliser les nombreux encodeurdecodeur
en ligne pour vous aider Le texte doit srsquoafficher sur votre moniteur seacuterie Arduino dans le cadre de
notre deacutemonstrateur sur Arduino
62 Reacutecupeacuteration des donneacutees avec MQTT dans lrsquoApplication
621 Preacutesentation du protocole MQTT
MQTT est un protocole leacuteger qui permet de srsquoabonner agrave des flux de donneacutees Plutocirct que
lrsquoarchitecture Client Serveur classique qui fonctionne avec des Requecirctes Reacuteponses MQTT est
baseacute sur un modegravele Publisher Subscriber La diffeacuterence est importante car cela eacutevite davoir agrave
demander (Requecircte) des donneacutees dont on na aucune ideacutee du moment ougrave elles vont arriver Une
donneacutee sera donc directement transmise au Subscriber degraves lors que celle-ci a eacuteteacute reccedilue dans le
Broker (serveur central)
Figure 56 Modegravele Publisher Subscriber du protocole MQTT
Pour recevoir les donneacutees appartenant agrave un Topic un Subscriber doit souscrire (comme son nom
lindique) au preacutealable sur ce Topic
MQTT est un protocole qui repose sur TCP Lencapsulation des trames sur le reacuteseau est donc la
suivante
Broker
Client
Publisher 1
Client
Publisher 2
Client
Subscriber
Topic
Tempeacuterature
Topic
Humiditeacute
| 53
Figure 57 Protocoles utiliseacutes pour la communication avec MQTT
On peut le veacuterifier par une capture de trame sur Wireshark
Figure 58 Capture dune trame MQTT avec Wireshark
On peut noter que le port TCP utiliseacute pour le protocole MQTT (non chiffreacute) est le 1883
Les Publishers et les Subscribers nrsquoont pas besoin de se connaitre
Les Publishers et les Subscribers ne sont pas obligeacute de srsquoexeacutecuter en mecircme temps
622 Connexion au Broker MQTT Nous nous inteacuteresserons essentiellement aux options de connexion qui permettront de geacuterer la
Qualiteacute de Service (QoS) Pour se connecter un client MQTT envoie deux informations importantes
au Broker
keepAlive Cest la peacuteriode la plus longue pendant laquelle le client Publisher ou Subscriber pourra
rester silencieux Au-delagrave il sera consideacutereacute comme deacuteconnecteacute
cleanSession Lorsque le Client et le Broker sont momentaneacutement deacuteconnecteacutes (au-delagrave du
keepAlive annonceacute) on peut donc se poser la question de savoir ce quil se passera lorsque le client
sera agrave nouveau connecteacute
Si la connexion eacutetait non persistante (cleanSession = True) alors les messages non transmis
sont perdus Quel que soit le niveau de QoS (Quality of Service)
Si la connexion eacutetait persistante (cleanSession = False) alors les messages non transmis
seront eacuteventuellement reacuteeacutemis en fonction du niveau de QoS Voir le chapitre 624
623 Qualiteacute de Service au cours dune mecircme connexion
A partir du moment ougrave le Client se connecte au Broker il est possible de choisir un niveau de fiabiliteacute
des transactions Le Publisher fiabilise leacutemission de ces messages vers le Broker et le Subscriber
fiabilise la reacuteception des messages en provenance du Broker Une parle ici du cas dune mecircme
connexion crsquoest-agrave-dire entre le moment ou le Client se connecte et le moment ougrave
Soit il se deacuteconnecte explicitement (Close connexion)
Soit il na rien eacutemis ni fait signe de vie pendant le temps keepAlive
TCP
MQTT
Reacuteseau
Transport
Couche Application
IP
| 54
Lors dune mecircme connexion la Qualiteacute de Service (QoS) qui est mise en œuvre deacutepend uniquement
de la valeur du QoS selon les valeurs suivantes
QoS 0 At most once (au plus une fois) Le premier niveau de qualiteacute est sans acquittement Le
Publisher envoie un message une seule fois au Broker et le Broker ne transmet ce message quune
seule fois aux Subscribers Ce meacutecanise ne garantit pas la bonne reacuteception des messages MQTT
QoS 1 At least once (au moins une fois) Le deuxiegraveme niveau de qualiteacute est avec acquittement
Le Publisher envoie un message au Broker et attends sa confirmation De la mecircme faccedilon le Broker
envoie un message agrave ces Subscriber et attends leurs confirmations Ce meacutecanisme garantit la
reacuteception des message MQTT
Cependant si les acquittements nrsquoarrivent pas en temps voulu ou srsquoils se perdent la reacuteeacutemission du
message dorigine peut engendrer une duplication du message Il peut donc ecirctre reccedilu plusieurs fois
QoS 2 Exactly once (exactement une fois) Le troisiegraveme niveau de qualiteacute est garanti une seule
fois Le Publisher envoie un message au Broker et attends sa confirmation Le Publisher donne alors
lrsquoordre de diffuser le message et attends une confirmation Ce meacutecanisme garantit que quel que
soit le nombre de tentatives de reacuteemission le message ne sera deacutelivreacute quune seule fois
La Figure 59 montre les trames eacutemises pour chaque niveau de QoS
Figure 59 Qualiteacute de Service en MQTT
La Figure 60 repreacutesentes les 3 captures de trames sur Wireshark repreacutesentant les 3 QoS (1 2 et 3)
que nous venons dexpliquer
Broker
QoS 0
Au plus une fois
Message supprimeacute apregraves envoi
PUBLISH
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Duplications possibles
PUBLISH
PUBLICH Ack
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Pas de duplication
PUBLISH
PUBLISH Receive
PUBLISH Release
PUBLISH Complete
| 55
Figure 60 Capture de trame avec QoS = 0 puis QoS = 1 puis QoS = 2
624 Qualiteacute de Service apregraves une reconnexion
La question que nous nous posons et de savoir ce que deviennent les messages publieacutes sur le Broker
lorsquun ou plusieurs Subscribers sont momentaneacutement injoignables Il est possible de conserver
les messages qui ont eacuteteacute publieacutes sur le Broker afin de les retransmettre lors de la prochaine
connexion Cette possibiliteacute de sauvegarde doit ecirctre activeacutee agrave louverture de connexion gracircce au flag
cleanSession = 0 La connexion sera alors persistante crsquoest-agrave-dire que le Broker enregistre tous les
messages quil na pas reacuteussi agrave diffuser au Subscriber
Le Tableau 9 reacutesume leffet du flag cleanSession et du QoS
Clean Session Flag Subscriber QoS Publisher QoS Comportement True ( = 1) 0 1 2 0 1 2 Messages perdus
False ( = 0 ) 0 0 1 2 Messages perdus
False (= 0 ) 0 1 2 0 Messages perdus
False (= 0 ) 1 2 1 2 Tous les messages sont retransmis
Tableau 9 Qualiteacute de Service en fonction de la valeur du QoS et du flag cleanSession
625 Les Topics du protocole MQTT Les chaicircnes deacutecrivant un sujet forment une arborescence en utilisant la barre oblique comme
caractegravere de seacuteparation La Figure 61 et le Tableau 10 donne un exemple dorganisation de Topic
Figure 61 Exemple de hieacuterarchie de Topic MQTT
Niveau 3
Niveau 2
Niveau 1 Maison
Chambre
Temperature Humidite Bruit
Salon
Temperature
| 56
Nom du Topic Deacutetail du Topic MaisonChambreTemperature La tempeacuterature de la chambre de la maison
MaisonChambreBruit Le bruit de la chambre de la maison
MaisonSalonTemperature La tempeacuterature du Salon de la maison
Tableau 10 Exemple de Topic
Un client peut sabonner (ou se deacutesabonner) agrave plusieurs branches de larborescence agrave laide de
jokers englobant plusieurs Topics Deux caractegraveres jokers existent
Le signe plus + remplace nimporte quelle chaine de caractegravere sur le niveau ougrave il est placeacute
Le diegravese remplace nimporte quelle chaine de caractegravere sur tous les niveaux suivants Il
est obligatoirement placeacute agrave la fin
Nom du Topic Deacutetail du Topic Maison+Temperature Les tempeacuteratures de toutes les piegraveces de la maison
MaisonChambre La tempeacuterature lhumiditeacute et le bruit de la chambre de la maison
Tableau 11 Exemple de Topic
626 Mise en place drsquoun Broker MQTT Afin de bien comprendre le fonctionnement du protocole de MQTT on reacutealise des tests
indeacutependamment de TTN Nous allons mettre en place
Un Broker Mosquitto httpstestmosquittoorg
Un client Publisher MQTT Box sur Windows
Un client Subscriber MQTT Box sur Windows
Figure 62 Test du protocole MQTT
MQTT Client (Subscriber)
MQTT Client (Publisher)
Publish
Subscribe
BROKER (Mosquitto)
| 57
Le Broker MQTT est commun agrave tout le monde Nous pouvons soit le reacutealiser nous-mecircme soit utiliser
un Broker MQTT public de test Nous utiliserons le Broker de test de Mosquitto disponible sur
httpstestmosquittoorg Drsquoautres sont eacuteventuellement disponibles en cas de problegraveme par
exemple httpwwwmqtt-dashboardcom
Si nous deacutecidions de le reacutealiser nous-mecircme agrave lrsquoaide drsquoune Raspberry Pi (par exemple) Lrsquoinstallation
se ferait en deux lignes de commande
apt-get install mosquito Installation
sudo systemctl start mosquittoservice Lancement du service
Il est neacutecessaire drsquoinstaller mosquitto-clients si on souhaite que le Raspberry PI joue aussi le rocircle de
client ce qui nrsquoest pas notre cas
627 Mise en place drsquoun Publisher et drsquoun Subscriber MQTT Lancer le logiciel MQTTBox
MQTTBox gt Create MQTT Client
Dans ce client les seuls champs indispensables sont
Protocol MQTT TCP
Host testmosquittoorg
Figure 63 Configuration dun Client MQTT dans MQTT Box
Tester lrsquoenvoi et la reacuteception sur les Topics de votre choix
628 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT La reacutecupeacuteration des donneacutees fait reacutefeacuterence au flux Uplink Dans ce cas
TTN joue le rocircle de client Publisher
TTN joue aussi le rocircle de Broker
Notre application joue le rocircle de Subscriber
Nous pouvons donc repreacutesenter lrsquoapplication globale par le scheacutema suivant
| 58
Figure 64 Publisher et Subscriber dans en MQTT avec TTN
La publication est repreacutesenteacutee par la trame MQTT (1)
La souscription est repreacutesenteacutee par la trame MQTT (2)
Le client Publisher eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box mais cette fois avec la configuration suivante
Protocol mqtt tcp
Host Crsquoest lrsquoIP du Broker vers lequel il faut se connecter Dans notre cas il srsquoagit de celui
de TTN dont lrsquoadresse est euthethingsnetwork
Username La connexion vers le broker MQTT est soumis agrave une authentification Username
Password Dans notre cas le Username correspond au nom de notre application crsquoest-agrave-
dire seminaire_lorawan Si vous avez choisi une autre applicationil faut bien mettre la
votre
Password Le Password est nommeacute laquo Access Key raquo par TTN Elle vous sera donneacutee par
lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application vous
trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt Overview
Figure 65 Access Keys de lapplication dans TTN
The Things Network (Application Server)
BROKER
Application
The Things Network (Network Server)
Publish (1 )
[ Flux Uplink ]
Subscribe (2 )
[ Flux Uplink ]
| 59
Figure 66 Configuration du Client dans MQTT Box
Le client MQTT eacutetant configureacute il est maintenant capable de se connecter au Broker Il reste donc agrave
deacutefinir le fait que le client sera Subscriber Les informations que recevra le Subscriber deacutependent du
Topic auquel nous souscrivons Voici les Topic disponibles sur le Broker de TTN
ltAppIDgt correspond au nom de votre Application
ltDevIDgt correspond au nom de votre Device LoRa
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink ltAppIDgtdevicesltDevIDgtup
[Donneacutees] Flux Downlink ltAppIDgtdevicesltDevIDgtdown
[Activation Events] Activation dun Device ltAppIDgtdevicesltDevIDgteventsactivations
[Management Events] Creacuteation dun Device ltAppIDgtdevicesltDevIDgteventscreate
[Management Events] Update dun Device ltAppIDgtdevicesltDevIDgteventsupdate
[Management Events] Suppression dun Device ltAppIDgtdevicesltDevIDgteventsdelete
[Downlink Events ] Message programmeacute ltAppIDgtdevicesltDevIDgteventsdownscheduled
[Downlink Events ] Message envoyeacute ltAppIDgtdevicesltDevIDgteventsdownsent
[Erreurs] Uplink erreurs ltAppIDgtdevicesltDevIDgteventsuperrors
[Erreurs] Downlink erreurs ltAppIDgtdevicesltDevIDgteventsdownerrors
[Erreurs] Activations erreurs ltAppIDgtdevicesltDevIDgteventsactivationserrors
Tableau 12 Topics enregistreacutes dans TTN
Dans un premier temps nous souscrivons au Topic +devices+up Cela signifie que nous
souscrivons agrave tous les Devices LoRa de toutes nos applications pour le flux Uplink
Figure 67 Configuration du Subscriber
Les eacuteleacutements eacutemis par le Broker seront alors afficheacutes dans MQTTBox La
| 60
Figure 68 Trame LoRaWAN reccedilu sur le Subscriber MQTT
Ces donneacutees sont eacutecrites en JSON nous pouvons les remettre en forme
applicationID3
applicationNamemyApplication
deviceNamearduino0
devEUI0056xxxxxxxxx877
txInfo
frequency868500000
dr5
adrfalse
fCnt792
fPort15
dataSGVsbG8=
Le Frame Payload deacutechiffreacute est fourni dans le champ data en base 64 La valeur fournie par
dataSGVsbG8= correspond bien agrave la chaine de caractegravere hello que nous avons eacutemise avec le
Device LoRa
629 Envoyer des donneacutees depuis notre Application avec MQTT
Lrsquoenvoi des donneacutees fait reacutefeacuterence au flux Downlink Dans ce cas
Notre application joue le rocircle de Publisher
TTN joue le rocircle de Broker
TTN joue aussi le rocircle de client Subscriber
| 61
La publication est repreacutesenteacutee par la trame MQTT (3)
La souscription est repreacutesenteacutee par la trame MQTT (4)
Le client Subscriber eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box Le rocircle de client dans MQTT Box a eacuteteacute faite au
paragraphe 628 Il nous reste simplement agrave ajouter le rocircle de Publisher La configuration est la
suivante
Topic du Subscriber seminaire_lorawandevicesarduino0down ougrave seminaire_lorawan
est agrave remplacer par le nom de votre application et arduino0 par le nom du Device LoRa vers
lequel vous souhaitez envoyeacute une donneacutee (Voir chapitre 628 pour comprendre les Topics)
Le Payload doit ecirctre au format JSON Lrsquoexemple suivant envoie laquohello raquo
payload_raw aGVsbG8=
The Things Network (Application Server)
BROKER
Application
Publish (3)
[ Flux Downlink ]
The Things Network (Network Server)
Subscribe (4)
[ Flux Downlink ]
| 62
Figure 69 Configuration du Publisher
Vous devriez voir les donneacutees arriver sur votre Device LoRA
| 63
7 Creacuteation de notre propre Network et Application Server
711 Objectifs Lors de la mise en œuvre du reacuteseau LoRaWAN au chapitre 52 nous avons utiliseacute TTN (The Things
Network) pour jouer le rocircle de Network Server et drsquoApplication Server Pour de multiples raisons
Seacutecuriteacute autonomie coucircthellipil peut ecirctre inteacuteressant de monter soi-mecircme un Network Server et un
Application Server Cela est possible seulement si vous posseacutedez vos propres Gateway puisque
celles-ci devront forwarder leur paquet agrave destination preacutecise Il faudra donc les reconfigurer pour
qursquoelles pointent vers votre nouvelle architecture
712 Preacutesentation de LoRaServer LoRaServer [ wwwloraserverio ] est un projet Open-Source reacutepondant exactement au besoin que
nous avons Nous lrsquoutiliserons sur une cible Raspberry PI En reacutealiteacute il peut souvent ecirctre mise en
place dans le mecircme systegraveme que la Gateway surtout si celle-ci est elle-mecircme agrave base de RPI Les
Gateway EBDS que nous posseacutedons possegravedent drsquoailleurs un Network Server et un Application Server
que nous aurions pu utiliser Neacuteanmoins pour des raisons peacutedagogiques il est inteacuteressant de
seacuteparer les systegravemes pour bien diffeacuterencier les probleacutematiques
Attention il y a une ambiguiumlteacute dans la deacutenomination des entiteacutes logiciels de LoRaServer
LoRaServer (sans espace entre le mot LoRa et Server) est le nom du projet global En
revanche LoRa Server (avec un espace) est le nom du service qui joue le rocircle du Network
Server
Lrsquoarchitecture et le fonctionnement de LoRaServer est preacutesenteacutee dans sa documentation par le
scheacutema suivant
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Raspberry PI
Figure 70 Architecture globale de notre reacuteseau loRaWAN
| 64
Figure 71 Architecture deacutetailleacutee de LoRaServer
On srsquoattends agrave voir uniquement un Network Server (LoRa Server) et un Application Server (LoRa App
Server) mais ce scheacutema est plus complexe Il demande un certain nombre drsquoexplications pour bien
comprendre ce que nous allons installer et la faccedilon dont nous lrsquoutiliserons par la suite
713 Le laquo Packet Forwarder raquo (Gateway) Comme nous lrsquoavons vu au chapitre 412 les Gateways LoRa sont des passerelles entre la
modulation LoRa et un reacuteseau IP Pour reacutealiser cette passerelle un service nommeacute laquo UDP Packet
Forwarder raquo a eacuteteacute deacuteveloppeacute par Semtech httpsgithubcomLora-netpacket_forwarder Dans
ce dossier github un fichier nommeacute PROTOCOLTXT explique parfaitement ce protocole applicatif
qui travaille au-dessus de UDP
Figure 72 Protocole Uplink (PUSH_DATA du Packet Forwarder)
| 65
On remarque que les paquets sont envoyeacutes en UDP au Network Server dans une trame appeleacutee
PUSH_DATA Cette trame est acquitteacutee par le Network Server par une trame appeleacutee PUSH_ACK
Sur notre Network Server nous pouvons reacutealiser une capture de trame pour veacuterifier si le protocole
est bien celui preacutesenteacute dans le document
Figure 73 Trame captureacutee par Wireshark lors dun Uplink
Drsquoapregraves la capture preacuteceacutedente on remarque que le Packet Forwarder fonctionne bien avec UDP sur
le port 1700
Le contenu des donneacutees (champ Data) est deacutetailleacute dans le tableau suivant
Champ | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | random token
[3] | 3 | PUSH_DATA identifier = 0x00
[4] | 4-11 | Gateway unique identifier (MAC address)
[5] | 12-end | JSON object starting with ending with
Lrsquoobjet JSON de la transmission reacuteeacutecrit plus proprement est celui-ci
Figure 74 Analyse du champ Donneacutees du protocole laquo Packet Forwarder raquo
0000 02 f9 30 00 b8 27 eb ff fe ae 26 f5 7b 22 72 78 0amprx 0010 70 6b 22 3a 5b 7b 22 74 6d 73 74 22 3a 33 37 35 pk[tmst375 0020 35 30 30 35 38 31 39 2c 22 63 68 61 6e 22 3a 32 5005819chan2 0030 2c 22 72 66 63 68 22 3a 31 2c 22 66 72 65 71 22 rfch1freq 0040 3a 38 36 38 2e 35 30 30 30 30 30 2c 22 73 74 61 868500000sta 0050 74 22 3a 31 2c 22 6d 6f 64 75 22 3a 22 4c 4f 52 t1moduLOR 0060 41 22 2c 22 64 61 74 72 22 3a 22 53 46 37 42 57 AdatrSF7BW 0070 31 32 35 22 2c 22 63 6f 64 72 22 3a 22 34 2f 35 125codr45 0080 22 2c 22 6c 73 6e 72 22 3a 36 2e 35 2c 22 72 73 lsnr65rs 0090 73 69 22 3a 2d 31 2c 22 73 69 7a 65 22 3a 31 38 si-1size18 00a0 2c 22 64 61 74 61 22 3a 22 51 4e 4d 61 41 53 59 dataQNMaASY 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 ]
Ch
amp
[1
]
Ch
amp
[2
]
Ch
amp
[3
]
Ch
amp
[4
]
| 66
rxpk[ tmst3755005819
chan2
rfch1
freq868500000
stat1
moduLORA
datrSF7BW125
codr45
lsnr65
rssi-1
size18
dataQNMaASYAAQAPpyPZ955+SmY
]
Le champ data correspond au PHY Payload
De la mecircme faccedilon on retrouve la Trame drsquoacquittement
Figure 75 Trame captureacutee par Wireshark lors de lrsquoacquittement drsquoun Uplink
Champs | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | same token as the PUSH_DATA to acknowledge
[3] | 3 | PUSH_ACK identifier = 0x01
Nous retrouvons bien tous ces champs dans la trame Wireshark
714 LoRa Gateway Bridge Nous avons deacutecrit au chapitre preacuteceacutedent (713) le fonctionnement du Packet Forwarder Le
Network Server(Lora Server) que nous allons mettre en place aurait tregraves bien pu srsquointerfacer
directement agrave ce protocole Mais cela aurait plusieurs impacts dont un qui est important dans la
conception de logiciel Si le Packet Forwarder change ou si un autre type de Forwarder est utiliseacute
alors lrsquoutilisation du LoRa Server devient impossible Il a donc eacuteteacute choisi de creacuteer une eacutetape
intermeacutediaire Le Network Server que nous mettrons en plus utilisera le protocole MQTT plutocirct que
le protocole UDP packet Forwarder
En drsquoautres termes le LoRa Gateway Bridge est un service qui fera abstraction du Packet Forwarder
pour srsquointerfacer plus simplement avec le Network Server
715 LoRa Server (Network Server) Il srsquoagit de notre Network Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
413 Cependant il srsquointerfacera au protocole MQTT en recevant les informations agrave partir du
Broker au lieu de recevoir directement les trames en provenance de la Gateway
| 67
716 LoRa App Server (Application Server) Il srsquogit de notre Application Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
414
717 LoRa Geo Server Il srsquoagit drsquoun service qui permet drsquoutiliser certaines proprieacuteteacutes du protocole LoRa pour proposer un
service de geacuteolocalisation des Devices LoRa Nous ne lrsquoutiliserons pas dans notre cas
718 Application Il srsquoagit de notre Application qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre 415
Elle ne fait pas partie du projet LoRaServer crsquoest donc bien toujours agrave nous de proposer notre propre
Application
Figure 76 Les interfaces possibles entre LoRaServer et lrsquoApplication utilisateur
Comme nous pouvons le voir sur la figure preacuteceacutedente deux possibiliteacutes sont offertes pour interfacer
notre application JSON REST (incluant HTTP POST) et via un Broker MQTT Ces deux meacutethodes ont
deacutejagrave eacuteteacute traiteacutee au chapitre 61 (HTTP POST ) et au chapitre 62 (MQTT) Nous verrons aussi drsquoautres
possibiliteacutes pour personnaliser notre application au chapitre 7
72 Installation de LoRaServer
721 Mise en place de lrsquoenvironnement
Nous allons installer une carte SD avec la derniegravere version de Raspbian Nous ne deacutetaillerons pas la
deacutemarche pour cela car elles sont largement documenteacutees et mises agrave jour sur le site
wwwraspberrypiorg
Installer un carte SD avec la derniegravere version de Raspbian
Plutocirct que de fonctionner avec un clavier et une souris nous preacuteconisons de travailler agrave distance
avec la RPI via une connexion SSH Depuis quelques anneacutees Raspbian a supprimeacute le deacutemarrage du
service SSH au boot Heureusement il est possible de le reacuteactiver par la meacutethode suivante
Avec Windows ou Linux ouvrir la partition BOOT de votre carte SD et placer un fichier agrave la
racine nommeacute sshtxt (ou ssh)
Mettre la carte SD dans votre RPI et la deacutemarrer
| 68
Pour acceacuteder agrave la RPI en SSH depuis Windows nous utiliserons de preacutefeacuterence le logiciel
client MobaXterm mais tout autre client SSH est valable
Installer MobaXterm sur votre PC et connectez-vous agrave votre Raspberry PI
Lrsquoutilisation drsquoun espion de reacuteseau type Wireshark peut ecirctre inteacuteressant pour eacutetudier les trames qui
sont reccedilues et qui sont eacutemises Cela nous permettra de valider le fonctionnement des diffeacuterents
protocoles reacuteseau qui permettent de communiquer agrave la Gateway drsquoune part et agrave lrsquoApplication
drsquoautre part Nous utiliserons tshark
apt-get install tshark installation
tshark ndashn -i eth0 Exemple drsquoune analyse sur lrsquointerface wlan0
722 Installation sur la Raspberry PI La meacutethode drsquoinstallation de LoRaServer est documenteacutee sur le site web agrave lrsquoadresse suivante
[ httpswwwloraserverioguidesdebian-ubuntu ] Nous installerons le LoRa Gateway Bridge
le LoRa Server et le LoRa App Server
Apregraves lrsquoinstallation la configuration se fait par une interface graphique accessible par le reacuteseau sur
le port 8080
Si vous travaillez sur la RPI connectez-vous sur httplocalhost8080
Si vous travaillez agrave distance (SSH) connectez-vous sur httpIP_RPI8080
Les Usernames et Password par deacutefaut sont
Username admin
Password admin
Lrsquoeacutecran drsquoaccueil sera donc le suivant
Figure 77 Architecture globale apregraves installation de LoRaServer
Devices
Gateways LoRa
UDP Packet Forwarder
Application Server
LoRa App Server
Internet
Network Server
LoRa Server
LoRa Gateway Bridge
| 69
Figure 78 Ecran daccueil de LoRaServer apregraves authentification
71 Configuration de LoRa Server pour lUplink
711 Enregistrement drsquoune nouvelle Organisation
Pour enregistrer une nouvelle Organizations Organizations gt Create Puis entrer les configurations
suivantes
Figure 79 Enregistrement dun nouvelle Organisation
712 Enregistrement drsquoune instance du Network Server Pour enregistrer une nouvelle instance du Network Server Network Server gt Create Puis entrer
les configurations suivantes
| 70
Figure 80 Enregistrement dun nouveau Network Server
Dans lrsquoonglet Gateway Discovery il est possible drsquoactiver une option de deacutecouverte de Gateway aux
alentours Lorsqursquoelle est configureacutee le Network Server va envoyer une trame Downlink de
configuration de la Gateway lui ordonnant de reacutealiser des PING en LoRa La configuration du
Gateway Discovery preacutevoit de speacutecifier
Le nombre de fois par jour que les PING LoRa sont envoyeacutes
Le canal drsquoeacutemission
Le Data Rate (Voir paragraphe 445)
Un PING LoRa reccedilu sur une Gateway sera retransmis sur le Network Server (Lora Server) et une carte
sera afficheacutee
Lrsquoonglet TLS Certificates ne sera pas utiliseacute dans le cadre de notre deacutemonstration
713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) Il faut tout drsquoabord faire un enregistrement drsquoun laquo service-profile raquo Un laquo service profile permet de
faire la connexion entre le Network Server et les Applications que nous enregistrerons dans notre
Organisation Service-profiles gt Create
Service-profile name myServiceProfile
Network-server myNetworkServer
On laissera par deacutefaut toutes les autres options
Pour enregistrer une nouvelle Application Applications gt Create Puis entrer les configurations
suivantes
| 71
Figure 81 Enregistrement dune nouvelle Application
714 Enregistrement des Devices LoRa Il faut tout drsquoabord faire lrsquoenregistrement drsquoun Device-profile pour les Devices LoRa que vous
souhaitez connecter Dans notre cas nous ferons un premier test en speacutecifiant que nous utilisons
seulement le mode drsquoauthentification ABP (voir chapitre 431) Devices profile gt Create
Figure 82 Enregistrement dun laquo Device profile raquo
Nous pouvons alors creacuteer dans notre Application des nouveaux Devices Application gt
myApplication gt Create
| 72
Figure 83 Enregistrement dun nouveau Device LoRa
Dans la fenecirctre Activation on va alors configurer les 3 eacuteleacutements indispensables agrave une
authentification en APB Le DevAddr le NwkSKey et lrsquoAppSKey
Figure 84 Configuration de lenregistrement du Device LoRa (en ABP)
La configuration minimale de LoRaServer est maintenant termineacutee Nous pouvons donc brancher
un Device LoRa qui possegravede les les attribus (DevAddr NwkSKey et AppSKey) que nous avons
enregistreacute dans LoRaServer et le faire eacutemettre
715 Visualisation des trames reccedilues Les trames eacutemises par le Device LoRa vont donc parcourir le cheminement suivant
| 73
Figure 85 Reacutesumeacute du cheminement des trames LoRaWan en Uplink avec LoRaServer
En allant dans le Live Device Data (Application gt Nom_du_Device gt Live Device Data) on peut voir la
liste des trames reccedilues ainsi que les donneacutees applicatives deacutechiffreacutees
Figure 86 Reacuteception des trames des Devices LoRa
Figure 87 Analyse des trames des Devices LoRa
Dans lrsquoonglet LIVE LORAWAN FRAME nous pouvons voir les trames LORAWAN et si besoin eacutetudier
le contenu de ce qursquoelles contiennent En revanche les donneacutees applicatives sont ici chiffreacutees
UDP
Packet Forwarder
LoRa Bridge
Gateway LoRa Server LoRa App Server
Gateway
Server
Internet
| 74
Figure 88 Reacuteception des Trames LoRaWAN
72 Configuration de LoRaServer pour linteacutegration dApplication Nous avons vu dans le chapitre 718 que linterface entre LoRaServer et notre Application pouvait
ecirctre reacutealiseacutee soit par MQTT soit par les meacutethodes REST (HTTP POST) Nous avons deacutejagrave impleacutementeacute
et expliqueacute ces protocoles dans le cadre de son utilisation avec TTN Nous allons donc juste
configurer LoRaServer pour tester ces deux meacutethodes
721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST Nous utiliserons exactement la mecircme meacutethode que celle que nous avons utiliseacute avec TTN au
chapitre 615 Les diffeacuterentes Clients et Serveurs disponibles pour ces tests sont expliqueacutes au
paragraphe 612
Dans LoRaServer ajouter une inteacutegration HTTP LoRaServer gt Applications gt myApplication gt
Integrations gt Create gt HTTP Integration et la configurer comme le montre la Figure 89 Vous
remplacerez eacutevidement le lien par votre propre Endpoints
Figure 89 Configuration de linteacutegration HTTP POST dans LoRaServer
En envoyant des trames LoRa depuis votre Device vous devriez voir les contenus JSON sur votre
Endpoint
722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT Nous allons nous connecter au Broker MQTT de LoRaServer Pour cela nous utiliserons la mecircme
meacutethode que celle que nous avons utiliseacute avec TTN au chapitre 628 Nous utiliserons MQTTBox
comme nous lavons deacutejagrave fait au paragraphe 627
Le Broker de LoRaServer a enregistreacute les Topics suivant
[applicationID] correspond au nom de votre Application
[devEUI] correspond au nom de votre Device LoRa
| 75
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink application[applicationID]device[devEUI]rx
[Donneacutees] Flux Downlink application[applicationID]device[devEUI]tx
[Status] Statut dun Device application[applicationID]device[devEUI]status
[Ack] Acquittement des messages application[applicationID]device[devEUI]ack
[Erreurs] Erreurs application[applicationID]device[devEUI]error
Tableau 13 Topics enregistreacutes dans LoRaServer
| 76
8 Creacuteation de notre propre Application
81 Utilisation de Node-RED
811 Preacutesentation Node-RED est un outil de programmation graphique qui permet de faire communiquer les
peacuteripheacuteriques mateacuteriels drsquoun systegraveme sans eacutecrire de code De nombreux protocoles sont aussi pris
en charge au travers de bloc ( Node) qursquoil suffit de connecter entre eux pour reacutealiser simplement
une application Il peut srsquoexeacutecuter localement sur un PC ou sur des cibles embarqueacutees telle qursquoune
Raspberry PI (RPI)
Dans les deacutemonstrations que nous mettrons en œuvre nous utiliserons une RPI Par soucis de
simpliciteacute nous utiliserons les derniegraveres versions de Raspbian (systegraveme drsquoexploitation de la RPI) qui
integravegre drsquoorigine Node-RED Il nrsquoy a donc tregraves peu de chose agrave mettre en place pour arriver agrave mettre
en place une Application Nous pouvons travailler soit directement sur la RPI agrave lrsquoaide drsquoune souris-
clavier mais il est recommandeacute de travailler agrave distance avec une connexion SSH
812 Mise en place de lrsquoenvironnement La mise en place de la RPI avec le systegraveme drsquoexploitation Raspbian a eacuteteacute preacutesenteacute au chapitre 721
Vous pouvez reprendre la mecircme installation ou repartir sur une nouvelle
Il est possible de faire en sorte que Node-RED se lance directement au deacutemarrage gracircce agrave la
commande sudo systemctl enable noderedservice
Sil nest pas actif lancer Node-RED sur votre RPI node-red-start
Nous nous connectons au Node-RED de la RPI via un navigateur web sur le port 1880 en tapant dans
la barre dURL httpIP_Raspeberry_PI1880 Ce nous permet darriver agrave la fenecirctre suivante
Figure 90 Page daccueil de Node-RED
Il est possible de sinterfacer avec TTN avec les Nodes deacutejagrave disponibles gracircce au protocole HTTP
POST ou MQTT Neacuteanmoins nous pouvons avantageusement installer deux librairies speacutecifiques
Une qui facilite linterfaccedilage avec TTN
Une qui facilite la mise en place dinterface graphique
Installation des Nodes TTN
cd $HOMEnode-red
npm install node-red-contrib-ttn
Installation de Dashboard (interface graphique)
| 77
cd $HOMEnode-red
npm install node-red-dashboard
Il peut ecirctre necessaire de redeacutemarrer Node-RED pour prendre en compte linstallation de nos deux
Nodes
-----------------------------------
sudo apt-get install npm
sudo npm install -g npm
hash -r
cd ~node-red
npm install node-red-example node name
------------------------------------
813 Creacuteer une Application speacutecifique pour TTN Nous allons commencer par geacuterer le flux Uplink Apporter sur votre scheacutema un Node ttn uplink et
un Node Debug puis relier les Le Node ttn uplink nous permettra de configurer la
communication avec TTN en MQTT Le Node debug eacutecrira sur le terminal les informations brutes
qui seront reccedilu par le Node ttn uplink
Figure 91 Visualisation des trame publieacutees par TTN sur notre client MQTT
Double cliquer sur le Node ttn uplink pour le configurer comme la figure suivante
Le champ Name sera le nom du Node sur votre scheacutema Le champ Device ID est le device LoRa
concerneacute dans votre application De plus il faut entrer les caracteacuteristiques de votre application (Add
new ttn app) pour que Node-RED puisse sy connecter
Figure 92 Configuration du node ttn uplink
Configuration de votre nouvelle application
| 78
Figure 93 Identifiant et mot de passe de notre application
AppID Nom de votre application Dans notre cas seminaire_lorawan
Access Key Comme nous lavons deacutejagrave expliqueacute plus tocirct l Access Key vous sera donneacutee
par lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application
vous trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt
Overview
Le Node ttn uplink doit maintenant avoir le nom que vous avez configureacute Cliquer sur Deploy pour
lancer votre projet Le bloc ttn uplink doit maintenant ecirctre connecteacute agrave TTN Cela est speacutecifieacute
connected sous le bloc
Figure 94 Utilisation du Node TTN Uplink
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
Figure 95 Simulation de Uplink dans TTN
Vous devriez voir le reacutesultat dans la fenecirctre de Debug Par exemple pour le test denvoi de 31 32
correspondant au code ASCII des chiffres 1 et 2 vous devriez avoir la fenecirctre de Debug suivante
| 79
Figure 96 Reacutesultats obtenu dans la fenecirctre Debug apregraves la simulation dUplink
814 Creacuteation drsquoun Dashboard
Dans la mise en place de lenvironnement (chapitre 812) nous avons installeacute des Nodes
Dashboard qui vont nous permettre de reacutealiser une interface graphique tregraves simple et de la mettre
agrave disposition des utilisateurs via un des graphiques histogramme gauges afficheurshellip
Figure 97 Impleacutementation dune interface graphique dans Node RED
Linterface graphique que nous allons creacuteer sera constitueacutee donglet (tab) La mise en place des
composant se fait de la faccedilon suivante
Chaque eacuteleacutement graphique doit appartenir agrave un groupe de composant quil va falloir creacuteer
Chaque groupe de composant doit appartenir agrave un onglet (tab) quil va falloir creacuteer
Figure 98 Creacuteation dun groupe de composant
Figure 99 Creacuteation dun nouvel onglet dans le site web
Cliquer sur Deploy pour activer votre application
LURL pour joindre linterface graphique de votre site web est disponible sur ladresse
httpIP_Raspeberry_PI1880ui
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
| 80
Figure 100 Interface graphique du site web avec Node-RED
82 Programmation en PHP Maintenant que nous avons testeacute toute lrsquoarchitecture nous pouvons mettre en place une
application qui jouera deux rocircles
Un rocircle de Serveur HTTP POST reacutecupeacuterant les donneacutees en provenance de TTN
Un rocircle de Client HTTP POST qui geacuteneacuterera les requecirctes vers TTN
Un serveur web apache sur RPI heacuteberge cette application Linterface graphique du site web est
reacutealiseacute avec le template CSS proposeacute par Bootstrap [ httpsgetbootstrapcom ]
Figure 101 Architecture de notre application en PHP sur RPI
The Things Network
Notre Application
[ Serveur Apache sur Raspberry Pi ]
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 81
Nous allons lrsquoutiliser telle quelle Elle est juste proposeacutee agrave titre dexemple Lrsquoobjectif de cette
application est de geacuteneacuterer une ouverture fermeture de ruche agrave distance dans le cadre de projets
eacutetudiants du Master Electronique et Systegravemes Embarqueacutes de lUSMB [ httpscem-esetuniv-
smbfr ]
Figure 102 Application permettant de recevoir et deacutemettre des requecirctes HTTP POST
Configurer TTN pour pointer vers votre nouveau serveur et tester le flux montant et
descendant
| 82
9 Versions du document
Version 10 02022019
Version initiale
Version 20 23022019
Ajout drsquoun paragraphe Les systegravemes embarqueacutes dans lrsquoIoT En introduction
Compleacutement et ameacutelioration Ameacutelioration exercice eacutetalement de spectre
Correction Cacircblage Arduino
Ajout drsquoun paragraphe Fonctionnement de lrsquoArduino et ajout de librairies
Compleacutement et ameacutelioration Couche physique LoRa Ajout de 4 figures pour lrsquoexplication
de la modulation Chirp
Ajout drsquoun paragraphe sur les acronymes utiliseacutes au deacutebut du cours TTN LoRa MQTThellip
Compleacutement drsquoinformations sur les dB et dBm
Ajout LoRa Calculator
Version 30 8032019
Ajout de figure sur le rocircle de la Gateway LoRa
Ajout de paragraphe authentification avec le Network Server
Ajout de paragraphe sur le chiffrement avec lrsquoApplication Server
Ajout drsquoun sommaire en deacutebut de cours
Ajout de 2 scheacutemas ABP et OTAA
Retrait explication du deacutetail de la laquo Join Request raquo en OTAA Trop complexe attente de
reacutealisation drsquoun scheacutema plus explicite
Ajout drsquoun scheacutema sur lrsquoattaque par REPLAY
Ajout de paragraphe des diffeacuterents reacuteseaux LoRaWAN existants Opeacutereacutes et Priveacutes
Ajout des scheacutemas des trames LoRaWAN Physique LoRa MAC Application
Compleacutement drsquoinformation sur les Classes de Devices
Ajout drsquoun paragraphe sur la Gateway utiliseacutee pour le Downlink
Ajout drsquoun paragraphe sur le JSON
Compleacutement drsquoinformation sur le codage en Base64
Ajout drsquoinformation dans le deacutecodage des trames LoRaWAN
Restructuration des explications sur lrsquoenvoi et la reacutecupeacuteration des donneacutees en HTTPMQTT
Version 40 8032019
Ajout drsquoun chapitre Creacuteation de notre propre Application
Ajout drsquoun chapitre Creacuteation de notre propre Network et Application Server
Ajout drsquoune figure Visualisation des Chirps LoRa par SDR (Radio Logicielle)
Compleacutements drsquoinformation sur MQTT
Compleacutements dinformation sur les Topics de TTN en MQTT
| 16
Figure 10 Temps drsquoeacutemission drsquoun symbole (Chirp) en fonction du SF
En revanche le temps drsquoeacutemission drsquoun symbole est inversement proportionnel agrave la bande passante
119879119904 =2119878119865
119861119886119899119889119908119894119889119905ℎ Le deacutebit des symboles est donc de
1
119879119878= 119865119904 =
119861119886119899119889119908119894119889119905ℎ
2119878119865 En toute logique plus la
bande passant est eacuteleveacute plus le deacutebit des symboles sera eacuteleveacute Comme chaque symbole comprend
SF bit on retrouve alors le deacutebit binaire
119863119887 = 119878119865119861119886119899119889119908119894119889119905ℎ
2119878119865
Plus le Spreading Factor sera eacuteleveacute plus le deacutebit binaire sera faible
Plus la Bande Passante sera eacuteleveacutee plus le deacutebit binaire sera fort
Exemple Drsquoapregraves la formule du deacutebit binaire trouver le deacutebit pour les deux cas suivants
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
32 Coding Rate Le Coding Rate est un ratio qui augmentera le nombre de bits agrave transmettre afin de reacutealiser de la
deacutetection correction drsquoerreur Dans le cas drsquoun CR = 4 8 il y aura 8 bits transmis reacuteellement agrave
chaque fois que nous souhaitons transmettre 4 bits Dans cette exemple cela provoque une
transmission drsquoun nombre de bit multiplieacute par 2
SF7
Freacutequence
Temps
Freacutequence centrale
Freacutequence haute
Temps drsquoun symbole eacutemit en SF 12
Freacutequence basse
SF8
SF9
SF10
SF11
SF12
Temps drsquoun symbole eacutemit en SF 11
| 17
Figure 11 Influence du Coding Rate sur le nombre de bits ajouteacute
Si on reprend lrsquoexemple preacuteceacutedent avec un CR de 4 5 nous avons une augmentation de 125 du
nombre de bits agrave transmettre Redonner la deacutebit en prenant en compte le CR
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
La documentation du composant RN2483 donne les deacutebits en fonction du Spreading Factor
la Bande Passante et le Coding Rate Veacuterifier la coheacuterence du reacutesultat avec votre calcul
preacuteceacutedent
Figure 12 Deacutebit en fonction des paramegravetres de la transmission LoRa
33 Utilisation du LoRa Calculator Le logiciel laquo LoRa Calculator raquo est un petit exeacutecutable permettant de simuler une transmission LoRa
en fonction des caracteacuteristiques saisies Canal SF CR etchellip Il est teacuteleacutechargeable agrave lrsquoadresse
suivante httpsbitly2TyloAh
| 18
Figure 13 Le logiciel LoRa Calculator
En reprenant lrsquoexemple preacuteceacutedent (SF7 Bande Passante 125 kHz CR 45) veacuterifier les
calculs du laquo Equivalent Bitrate raquo
34 Time On Air La norme LoRaWAN impose qursquoun Device LoRa ne transmette pas plus de 1 du temps Cela est
repreacutesenteacute par un Duty Cycle Par exemple un Duty Cycle de 1 signifie que si jrsquoeacutemet pendant 1 je
ne dois plus eacutemettre pendant 99 quel que soit lrsquouniteacute de temps utiliseacutee
En reprenant les exemples preacuteceacutedents quels sont les deacutebits moyens si on prend en compte
le laquo Time On Air raquo
Cas 1 Pour SF7 et 125 khz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
Dans le logiciel laquo LoRa Calculator raquo (onglet laquo Energy Profile raquo) nous pouvons estimer la
dureacutee de vie drsquoune batterie Nous prenons lrsquoexemple drsquoun releveacute de tempeacuterature dans un
bacirctiment avec les caracteacuteristiques suivantes
| 19
SF CR Bande Passante etc Nous nous placcedilons dans le cas 1 des exemples preacuteceacutedents
Le releveacute de tempeacuterature se fera toutes les 15 mins
La batterie est constitueacute de 3 petites piles bacirctons [ AAA LR03 ] 12V en seacuterie Soit 36 V
1000 mAh
35 Mise en œuvre LoRa en point agrave point Ce test sera reacutealiseacute avec des modules LoRa RN2483 (Microchip) et une carte microcontrocircleur
ARDUINO
Figure 14 Communication LoRa en Point agrave Point
Reacutealiser le cacircblage de votre module RN2483 suivant le tableau suivant
Connecteur Arduino Click Board RN2483
5V 5V
GND GND
11 RX
10 TX
Tableau 4 Cacircblage de lrsquoARDUINO et de la click Board RN2483
351 Utilisation de lrsquoIDE Arduino Lrsquoenvironnement Arduino est tregraves simple Nous allons reacutealiser un programme pour montrer son
fonctionnement
La connexion de la carte est effectueacutee agrave lrsquoaide drsquoun port USB qui eacutemule une liaison seacuterie
RS232 Il faut donc choisir le bon port Arduino IDE gt Outils gt Port
Pour creacuteer un nouveau programme (sketch) Arduino IDE gt Fichier gt Nouveau
Il y a deux parties dans un sketch
Une fonction setup() qui sera exeacutecuteacutee qursquoune seule fois au deacutemarrage
Une fonction loop() qui sera exeacutecuteacutee en boucle
Ecrire le code suivant
Emetteur
Reacutecepteur
UA
RT
UA
RT
| 20
void setup()
Serialbegin(9600)
void loop()
Serialprintln(hello word)
Compiler et Teacuteleacuteverser Croquis gt Teacuteleacuteverser
Voir la sortie sur la liaison seacuterie Outils gt Moniteur Seacuterie gt Choisir la vitesse de
transmission ici 9600 bauds (en bas agrave droite)
352 Validation du fonctionnement Deux binocircmes joueront le rocircle drsquoeacutemetteur tous les autres binocircmes seront en reacutecepteur
Reacutecupeacuterer les programmes dans Moodle dans le dossier laquo RN2483-Arduino-Point2Point raquo
Installer la librairie RN2483 Arduino IDE gt Croquis gt Inclure une bibliothegraveque gt Ajouter la
bibliothegraveque zip
Reacutepartissez les rocircles Emetteurs Reacutecepteurs et reacutecupeacuterer le programme LoraBlinkerRX ou
LoraBlinkerTX en fonction Les 2 binocircmes en eacutemission devront modifier le code du sketch
Arduino pour transmettre des donneacutees speacutecifiques afin de les diffeacuterencier [
loraSerialprintln(radio tx 30) ]
Validez la reacuteception des donneacutees eacutemises par les deux binocircmes qui transmettent des
donneacutees Ces donneacutees reccedilues sont eacutecrite agrave 57600 bauds sur le moniteur seacuterie de lrsquoArduino
353 Mise en valeur du Spreading Factor On srsquoaperccediloit dans la manipulation preacuteceacutedente que les Devices LoRa reccediloivent les donneacutees des deux
eacutemetteurs Nous allons conserver le mecircme canal drsquoeacutemission (8691 Mhz) mais un des deux
eacutemetteurs va modifier son laquo Spreading Factor raquo La salle sera donc seacutepareacutee en deux groupes
1er groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF7
2egraveme groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF8
Validez la reacuteception des donneacutees eacutemises seulement pour le Spreading Factor que vous
utilisez
| 21
4 Le protocole LoRaWAN
Le LoRa est le type de modulation utiliseacute entre deux Devices ou entre un Device et une Gateway
Lorsque nous parlons de lrsquoensemble de la chaine de communication (Device Gateway Serveur) alors
nous parlons de communication LoRaWAN Nous allons voir lrsquoarchitecture drsquoun reacuteseau LoRaWAN
ainsi que les regravegles de ce protocole
41 Structure drsquoun reacuteseau LoRaWAN Nous retrouvons drsquoun cocircteacute le Device LoRa qui transmet une donneacutee Elle est reacuteceptionneacutee agrave lrsquoautre
extreacutemiteacute du reacuteseau par un Utilisateur La structure globale du reacuteseau LoRaWAN peut ecirctre
repreacutesenteacutee par la figure suivante
411 Les Devices LoRa Les Devices LoRa sont des systegravemes eacutelectroniques appartenant au monde de lrsquoIoT Faible
consommation faible taille faible puissance et faible taille
Ils possegravedent une radio LoRa permettant de joindre les Gateways Les Gateways ne sont pas
adresseacutees speacutecifiquement toutes celles preacutesentes dans la zone de couverture reccediloivent les
messages et les traitent
412 Les Gateways LoRa Elles eacutecoutent sur tous les canaux et sur tous les Spreading Factor Lorsqursquoune trame LoRa est reccedilue
elle transmet son contenu sur internet agrave destination du Network Server qui a eacuteteacute configureacute dans la
Gateway au preacutealable
Elle joue donc le rocircle de passerelle entre une modulation LoRa et une communication IP
Devices
LoRa Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
Internet Internet
Figure 15 Structure globale dun reacuteseau LORAWAN
| 22
Chaque Gateway LoRa possegravede un identifiant unique (EUI sur 64 bits)
413 Le Network Server
Le Network Server reccediloit les messages transmis par les Gateways et supprime les doublons
(plusieurs Gateway peuvent avoir reccedilu le mecircme message) Les informations transmises au Network
Server depuis les Devices LoRa sont authentifieacutes gracircce agrave une cleacute AES 128 bits appeleacutee Network
Session Key NwkSKey Nous parlons bien ici drsquoauthentification et non pas de chiffrement comme
nous le verrons plus tard
414 Application Server Il est souvent sur le mecircme support physique que le Network Server Il permet de dissocier les
applications les unes des autres Chaque application enregistre des Devices LoRa qui auront le droit
Devices Gateways Network
Server
Internet
Network Session Key (NwkSKey)
Authentification
Figure 17 Authentification entre le Device LoRa et le Network Server
Internet
UDP IP
Modulation
LoRa
Device LoRa
Gateway
Network Server
LoRaWAN
Modulation
LoRa
Passerelle LoRa Internet
Internet
UDP IP
LoRaWAN
Transmission Radio
Application Application
Figure 16 Le rocircle de la Gateway LoRa
| 23
de stocker leurs donneacutees (Frame Payload) Les message transmis agrave lrsquoapplication server sont chiffreacutes
gracircce agrave une cleacute AES 128 bits appeleacutee Application Session Key AppSKey
Le scheacutema suivant reacutesume lrsquoutilisation
De la Network Session Key (NwkSKey) pour lrsquoauthentification entre le Device LoRa et le
Network Server
De lrsquoApplication Session Key (AppSKey) pour le chiffrement entre le Device LoRa et
lrsquoApplication Server
Devices Gateways Network
Server Application
Server
Internet
Application Session Key (AppSKey)
Chiffrement
Figure 18 Chiffrement entre le Device LORA et lrsquoApplication Server
| 24
415 Application Web Serveur Cette application doit drsquoune part reacutecupeacuterer les donneacutees de lrsquoApplication Serveur Dans le cadre de
ce cours cela sera fait de deux faccedilons
Avec le protocole HTTP
Avec le protocole MQTT
Figure 20 Application Web Server
Figure 19 Authentification et chiffrement en LoRaWan
Devices Gateways
Network
Server Application
Server
Internet
Network Session Key
Application Session Key
Network
Server Application
Server
Application
Server Web
Utilisateur
Protocole
MQTT ou HTTP
Flux Uplink
Flux Downlink
| 25
Le flux habituel dans lrsquoIoT est le flux Uplink (flux montant) crsquoest-agrave-dire lrsquoeacutemission de donneacutees des
objets vers le serveur Comme nous lrsquoexpliquerons plus loin en LoRaWAN il est aussi possible de
transfeacuterer des donneacutees aux Device LoRa par un flux Downlink (flux descendant)
Drsquoautre part lrsquoapplication mettra agrave disposition les donneacutees aux utilisateurs sous forme par exemple
drsquoun serveur web drsquoune base de donneacutees et drsquoune visualisation graphique
416 Authentification avec le Network Server La Network Session Key (NwkSKey) sert agrave lrsquoauthentification entre le Device LoRa e le Network Server
Afin de reacutealiser cette authentification entre le Device et le Network Server un champ MIC (Message
Integrity Control) est rajouteacute agrave la trame Il est calculeacute en fonction des donneacutees transmises et du
NwkSkey A la reacuteception le mecircme calcul est effectueacute Si les cleacutes sont eacutequivalentes dans le Device et
dans le Network Server alors les deux MIC calculeacutes doivent correspondre
417 Chiffrement des donneacutees vers lrsquoApplication Server
LrsquoApplication Session Key (AppSKey) sert pour le chiffrement entre le Device LoRa et lrsquoApplication
Server Les donneacutees chiffreacutees seront alors deacutecodeacutees agrave la reacuteception sur lrsquoApplication Server srsquoil
possegravede la mecircme cleacute Si on reprend le scheacutema preacuteceacutedent les laquo donneacutees x raquo sont chiffreacutees
deacutechiffreacutees par le processus suivant
Donneacutees x chiffreacutees NwkSkey x
MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees
NwkSkey x
Trame eacutemise Trame reccedilue
Device LoRa Network Server
Si =
Alors la trame est authentifieacutee
MIC geacuteneacutereacute Emission MIC geacuteneacutereacute Reacuteception
MIC geacuteneacutereacute Reacuteception
Figure 21 Authentification dun Device LoRa par le Network Server
| 26
Figure 22 Chiffrement des donneacutees par lApplication Session Key
418 Combinaison de lrsquoauthentification et du chiffrement On peut maintenant repreacutesenter sur le mecircme scheacutema la construction de la trame LoRaWAN avec
drsquoune part lrsquoauthentification et drsquoautre part le chiffrement
Figure 23 Chiffrement puis Authentification
42 Classes des Devices LoRaWAN Les Devices LoRa sont classeacutes en 3 cateacutegories (A B C) en fonction de leur consommation et de leur
accessibiliteacute en Downlink crsquoest-agrave-dire la faciliteacute qursquoun utilisateur aura agrave transmettre une trame au
Device LoRa
421 Classe A (All) Minimal power Application Tous les Devices LoRaWAN sont de classe A Chaque Device peut transmettre (Uplink) agrave la Gateway
sans veacuterification de la disponibiliteacute du reacutecepteur Si la transmission eacutechoue elle sera reacuteeacutemise apregraves
un certain temps Cette transmission est suivie de 2 fenecirctres de reacuteception tregraves courtes La Gateway
peut alors transmettre pendant le laquo RX Slot 1 raquo ou le laquo RX Slot 2 raquo mais pas les deux
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Device LoRa
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Application Server
Donneacutees non chiffreacutees
AppSKey
Donneacutees chiffreacutees Entecircte
NwkSKey
MIC geacuteneacutereacute en eacutemission Trame transmise =
| 27
Figure 24 Slots de reacuteception pour un Device LoRa de classe A
Source de lrsquoimage httpszakelijkforumkpncom
La dureacutee des fenecirctres doit ecirctre au minimum la dureacutee de reacuteception drsquoun preacuteambule Un preacuteambule
dure 1225 Tsymbole et deacutepend donc du Data Rate (DR voir paragraphe 445 pour plus drsquoinformation
sur le DR) Lorsque qursquoun preacuteambule est deacutetecteacute le reacutecepteur doit rester actif jusqursquoagrave la fin de la
transmission Si la trame reccedilue pendant la premiegravere fenecirctre de reacuteception eacutetait bien agrave destination du
Device LoRa alors la deuxiegraveme fenecirctre nrsquoest pas ouverte
Premiegravere fenecirctre de reacuteception
Le Slot RX1 est programmeacute par deacutefaut agrave 1 seconde + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont les mecircme que ceux choisis lors de la phase drsquoeacutemission
(Uplink)
Seconde fenecirctre de reacuteception
Le Slot RX2 est programmeacute par deacutefaut agrave 2 secondes + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont configurables mais fixes
Un Device LoRa qui est uniquement de classe A ne peut pas recevoir srsquoil nrsquoa pas eacutemis Il
nrsquoest donc pas joignable facilement
422 Classe B (Beacon) Scheduled Receive Slot Les Devices de classe B ont le mecircme comportement que les Devices de classe A mais drsquoautres
fenecirctres de reacuteceptions sont programmeacutees agrave des peacuteriodes preacutecises Afin de synchroniser les fenecirctres
de reacuteception du Device LoRa la Gateway doit transmettre des balises (Beacons) de faccedilon reacuteguliegravere
| 28
Figure 25 Slots de reacuteception pour un Device LoRa de classe B
Source de lrsquoimage httpszakelijkforumkpncom
Un Device LoRa de classe B est joignable reacuteguliegraverement sans qursquoil soit neacutecessairement
obligeacute drsquoeacutemettre En revanche il consomme plus qursquoun Device de classe A
423 Classe C (Continuous) Continuously Listening Les Devices de classe C ont des fenecirctres de reacuteception constamment ouvertes entre 2 Uplinks Ces
Devices consomment donc beaucoup plus
Figure 26 Slots de reacuteception pour un Device LoRa de classe C
Source de lrsquoimage httpszakelijkforumkpncom
| 29
Un Device LoRa de classe C est joignable en permanence En revanche crsquoest la classe de
Device qui est la plus eacutenergivore
424 Quelle Gateway pour les flux Downlink
Nous avons donc vu que le fonctionnement classique du protocole LoRaWAN eacutetait de reacutecupeacuterer de
lrsquoinformation depuis le Device LoRa Crsquoest le flux Uplink
Dans le cas ougrave lrsquoutilisateur transmet des informations au Device LoRa (flux Downlink) on peut se
demander quelle Gateway sera choisie pour transfeacuterer les donneacutees au Device LoRa En effet
lrsquoendroit ougrave est situeacute le Device LoRa nrsquoest pas neacutecessairement connu agrave lrsquoavance
La Gateway utiliseacutee pour le Downlink est celle qui a reccedilu le dernier message du Device
LoRa Un message ne pourra jamais arriver agrave destination drsquoun Device LoRa si celui-ci nrsquoa
jamais transmis quel que soit sa classe A B ou C
43 Activation des Devices LoRa et seacutecuriteacute En LoRaWAN les trois eacuteleacutements indispensables pour la communication sont le DevAddr pour
lrsquoindentification du Device ainsi que deux cleacutes le NwkSKey pour lrsquoauthentification et lrsquoAppSKey
pour le chiffrement Deux meacutethodes sont possibles pour fournir ces informations agrave la fois au Device
LoRa et au serveur
Activation By Personalization APB
Over The Air Activation
431 ABP Activation By Personalization Crsquoest la plus simple des meacutethodes Crsquoest donc peut ecirctre celle que nous avons tendance agrave utiliser lors
drsquoun test de prototype et drsquoune mise en place de communication LoRaWAN
Le Device LoRa possegravede deacutejagrave le DevAddr lrsquoAppSKey et le NwkSKey
Le Network server possegravede deacutejagrave le DevAddr et le NwkSKey
Lrsquoapplication serveur possegravede deacutejagrave le DevAddr et le AppSKey
En ABP toutes les informations neacutecessaires agrave la communication sont deacutejagrave connues par le
Device LoRa et par le Serveur
| 30
432 OTAA Over The Air Activation Crsquoest la meacutethode qursquoil faut privileacutegier car crsquoest celle qui est la plus seacutecuriseacutee Le Device LoRa doit
connaitre le DevEUI lrsquoAppEUI et lrsquoAppkey Le Network Server doit lui connaitre la mecircme Appkey
Tous les eacuteleacutements noteacutes EUI (Extended Unique Identifier) sont toujours sur une taille de
64 bits
Gracircce agrave ces informations de deacutepart et une neacutegociation avec le Network Server (Join Request) le
Device LoRa et le serveur vont geacuteneacuterer les informations essentielles DevAddr NwkSKey et
AppSKey
Figure 28 Obtention du DevAddr NwkSKey et AppSKey en OTAA
DevEUI Unique Identifier pour le device LoRa (Equivalent agrave une MAC sur Ethernet)
Certains Device LoRa ont deacutejagrave un DevEUI fourni en usine
AppEUI Unique Identifier pour lrsquoapplication server
DevEUI
AppEUI
AppKey
Join
Request
DevAddr
NwkSKey
AppSKey
Network Server
Application Server
Devices 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 2
NwkSkey 2
AppSKey 2
Devices 2
DevAddr 2
NwkSkey 2
AppSKey 2
Paramegravetres stockeacutes sur le serveur
Paramegravetres programmeacutes
dans le composant
Figure 27 Parameacutetrage de DevAddr NwkSKey et AppSKey
| 31
AppKey AES 128 cleacute utiliseacutee pour geacuteneacuterer le MIC (Message Code Integrity) lors de la Join
Resquest Il est partageacute avec le Network server
NwkSKey Utiliseacute pour lrsquoauthentification avec le Network Server
AppSKey Utiliseacute pour le chiffrement des donneacutees
433 Seacutecuriteacute Les cleacutes AES 128 bits permettent le chiffrement des informations transmises en LoRaWAN Malgreacute
ce chiffrement une attaque connue en Wireless est celle du REPLAY Crsquoest-agrave-dire que le Hacker
enregistre des trames chiffreacutees circulant sur le reacuteseau LoRa pour les reacuteeacutemettre plus tard Mecircme si
le Hacker ne comprend pas le contenu (les trames sont chiffreacutees) les donneacutees qui sont transporteacutees
sont elles bien comprises par lrsquoApplication Server Des actions peuvent donc ecirctre reacutealiseacutees
simplement par mimeacutetisme
Pour eacuteviter cela la trame LoRaWAN integravegre un champ variable appeleacute laquo Frame Counter raquo Il srsquoagit
drsquoun nombre numeacuterotant la trame sur 16 ou 32 bits LrsquoApplication Server acceptera une trame
uniquement si le laquo Frame Counter raquo reccedilu est supeacuterieur au laquoFrame Counter raquo preacuteceacutedemment Donc
si le Hacker retransmet la trame telle qursquoelle le laquo Frame Counter raquo sera eacutequivalent donc la trame
sera refuseacutee Et comme la trame est chiffreacutee le Hacker nrsquoa pas moyen de savoir comment modifier
un champ de cette trame
Cette seacutecuriteacute impleacutementeacutee par les laquo Frame Counter raquo est inteacuteressante pour srsquoaffranchir drsquoune
attaque par REPLAY mais dans nos tests cela peut poser problegraveme En effet agrave chaque fois que nous
redeacutemarrons le microcontrocircleur notre laquo Frame Counter raquo revient agrave zeacutero alors que celui de
lrsquoApplication Server continue de srsquoincreacutementer Cela peut ecirctre reacutesolue par diffeacuterentes maniegraveres
1 Deacutesactivation du laquo Frame Counter Check raquo Dans certain Application Server cette option
peut ecirctre proposeacutee Bien sucircr il faudra garder en tecircte la faille de seacutecuriteacute que cela engendre
Network Server
Application Server
Devices LoRa
NwkSkey
AppSKey
NwkSkey
AppSKey Hacker
(1) (2)
(1) Ecoute
(2) Reacuteeacutemission
Figure 29 Attaque par REPLAY
| 32
Figure 30 Deacutesactivation du Frame Counter Check dans TTN
2 Utiliser lrsquoauthentification par OTAA au lieu de ABP En effet agrave chaque ouverture de session
en OTAA le laquo Frame Counter raquo est reacuteinitialiseacute coteacute serveur
3 Conserver la valeur du laquo Frame Counter raquo dans une meacutemoire non volatile et reacutecupeacuterer sa
valeur au deacutemarrage du Device LoRa
44 La Trame LoRa LoRaWAN
441 Les couches du protocole LoRaWAN
Lorsque nous avons fait une communication en Point agrave Point nous avons simplement utiliseacute la
couche physique de la modulation LoRa Lorsque nous souhaitons utiliser le protocole LoRaWAN
des couches protocolaires suppleacutementaires se rajoutent
Figure 31 Les couches protocolaires du LoRaWAN
Chaque couche rajoute un service Lors de lrsquoenvoi de la trame les donneacutees utilisateurs sont donc
encapsuleacutees dans chaque couche infeacuterieure jusqursquoagrave la transmission Le deacutetail de lrsquoensemble de la
trame LoRaWAN par couche est deacutecrit sur la figure Figure 32
LoRa Modulation
LoRa Mac
Application
Couche Physique
Couche Mac
Couche Application
| 33
442 Couche Application La couche Application accueille les donneacutees de lrsquoutilisateur Avant de les encapsuler elles sont
chiffreacutees avec lrsquoAppSKey afin de seacutecuriser la transaction
Un ensemble de champs nommeacute Frame Header permet de speacutecifier le DevAddr le Frame Control
le Frame Counter et le Frame Option
Le Frame Port deacutepend du type drsquoapplication et sera choisi par lrsquoutilisateur
Le Frame Payload sont les donneacutees chiffreacutees agrave transmettre Le nombre drsquooctets maximum pouvant
ecirctre transmis (N octets) est donneacute dans le tableau suivant
PHY Payload
P octets Couche
Physique
Couche
Mac
Couche
Application
CRC
2 octets Header + Header CRC
20 bits Preamble
MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Figure 32 Trame LORAWAN complegravete par couche protocolaire
Couche
Application Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Frame Header
Figure 33 Trame LORA couche Applicative
| 34
Data Rate Spreading Factor Bandwidth Max Frame Payload (Nombre N) DR 0 SF12 125 KHz 51 octets
DR 1 SF11 125 KHz 51 octets
DR 2 SF10 125 KHz 51 octets
DR 3 SF9 125 KHz 115 octets
DR 4 SF8 125 KHz 222 octets
DR 5 SF7 125 KHz 222 octets
DR 6 SF7 250 KHz 222 octets
Tableau 5 Taille maximum du Frame Payload en fonction du Data Rate
443 Couche LoRa MAC Cette trame est destineacutee au Network Server Elle est authentifieacutee gracircce au champ MIC (Message
Integrity Protocol) selon la meacutethode expliqueacutee au paragraphe 416
Le protocole LoRa MAC est composeacute de
1 MAC Header Version de protocole et type de message
Type de Message Description 000 Join-Request
001 Join-Accept
010 Unconfirmed Data Up
011 Unconfirmed Data Down
100 Confirmed Data Up
101 Confirmed Data Down
110 Rejoin-request
111 Proprietary
Tableau 6 Les types de messages transmis en LoRaWAN
2 MAC Payload Contient tout le protocole applicatif
3 MIC Message Integrity Code pour lrsquoauthentification de la trame
444 Couche physique Modulation LoRa
Le choix du moment drsquoeacutemission des Devices LoRa se fait de faccedilon simple Lorsqursquoun eacutequipement
doit eacutemettre il le fait sans controcircle et ne cherche pas agrave savoir si le canal est libre Si le paquet a eacuteteacute
perdu il le retransmettra simplement au bout drsquoun temps aleacuteatoire La couche physique est
repreacutesenteacutee par lrsquoeacutemission de la trame suivante
Couche
Mac MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Figure 34 Trame LORA couche LORA MAC
| 35
Le Preacuteambule est repreacutesenteacute par 8 symboles + 425 Le temps du Preacuteambule est donc de 1225
Tsymbole
Len-tecircte (Header optionnel) est seulement preacutesent dans le mode de transmission par deacutefaut
(explicite) il est transmis avec un Coding Rate de 48 Il indique la taille des donneacutees le Coding Rate
pour le reste de la trame et il preacutecise eacutegalement si un CRC sera preacutesent en fin de trame
Le PHY Payload contient toutes les informations de la Couche LoRa MAC
Le CRC sert agrave la deacutetection drsquoerreur de la trame LoRa
445 Canaux et bandes de freacutequences et Data Rate (DR) Le LoRa utilise des bandes de freacutequences diffeacuterentes suivant les reacutegions du monde En Europe la
bande utiliseacutee est celle des 868 Mhz [ De 863 Mhz agrave 870 Mhz ] Le LoRaWAN deacutefinie les 8 canaux agrave
utiliser pour communiquer avec une Gateway suivant le tableau suivant
Canaux Spreading Factor Bandwidth 8681 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz SF7 250 kHz
8685 Mhz De SF7 agrave SF12 125 kHz
8671 Mhz De SF7 agrave SF12 125 kHz
8673 Mhz De SF7 agrave SF12 125 kHz
8675 Mhz De SF7 agrave SF12 125 kHz
8677 Mhz De SF7 agrave SF12 125 kHz
8679 Mhz De SF7 agrave SF12 125 kHz
Tableau 7 Canaux SF et Bandwidth de notre Gateway LoRaWAN
Une Gateway LoRa eacutecoute donc sur 8 canaux simultaneacutement avec les 6 Spreading Factor
diffeacuterents soit 48 combinaisons possibles
Comme nous lrsquoavons vu le Spreading Factor a des conseacutequences sur le deacutebit de la transmission Ces
deacutebits sont noteacutes DR (Data Rate) et sont normaliseacutes de DR0 agrave DR6
PHY Payload
P octets Couche
Physique CRC
2 octets Header + Header CRC
( Optionnel ) 20 bits Preamble
Figure 35 Trame LORA couche Physique
| 36
Data Rate Spreading Factor Bandwidth DR 0 SF12 125 KHz
DR 1 SF11 125 KHz
DR 2 SF10 125 KHz
DR 3 SF9 125 KHz
DR 4 SF8 125 KHz
DR 5 SF7 125 KHz
DR 6 SF7 250 KHz
Tableau 8 Deacutenomination DR en fonction du SF et de la Bande Passante
446 Trame reccedilue et transmise par la Gateway LoRaWAN La Gateway reccediloit drsquoun cocircteacute un message radio moduleacute en LoRa et transmet de lrsquoautre cocircteacute une trame
IP agrave destination du Network Server
Coteacute interface Radio La Gateway reacuteceptionne une trame LoRaWAN et extrait le PHY Payload Celui-
ci est codeacute au format ASCII en base 64 (voir le paragraphe 541) La Gateway extrait aussi toutes les
informations utiles sur les caracteacuteristiques de la reacuteception qui a eu lieu SF Bandwidth RSSI Time
On Airhellipetchellip
Coteacute interface reacuteseau IP La Gateway transmet lrsquoensemble de ces informations dans un paquet IP
(UDP) au Network Server Les donneacutees transmises sont du texte en format JSON (voir paragraphe
447) La Gateway a donc bien un rocircle de passerelle entre le protocole LoRa drsquoun cocircteacute et un reacuteseau
IP de lrsquoautre
Internet
UDP IP
Device LoRa
Gateway
Network Server Modulation
LoRa
Passerelle LoRa Internet
Transmission Radio Internet
Figure 36 Rocircle de la Gateway LoRa
| 37
447 Le format JSON Le format JSON est un format texte composeacute drsquoune succession de couple nomvaleur Dans
lrsquoexemple de la figure preacuteceacutedente gw_id est un nom et eui-b827ebfffeae26f5 est la valeur
associeacutee Dans cette exemple la valeur est un string Les objets sont deacutelimiteacutes par un des accolades
et
Une valeur peut ecirctre
Un string exemple coding_rate 45
Un nombre exemple spreading_factor 12
Un objet exemple lora spreading_factor 12 air_time 2465792000
Un Boolean
Ethernet
Gateway
Modulation
LORA
Reacutecupeacuteration du PHY PAYLOAD en base 64
Reacutecupeacuteration des caracteacuteristiques de la transmission Canal SF CR hellip
IP (IP dest routereuthethingsnetwork)
UDP (Port dest 1700 Port source 1700)
Donneacutees applicatives (format JSON)
gw_id eui-b827ebfffeae26f5
payload QNAPvA6Ax3ECqHk4C8hfzuA==
lora
spreading_factor 12
bandwidth 125
air_time 2465792000
coding_rate 45
timestamp 2019-01-20T133746017Z
rssi -105
snr -162
dev_addr 0EBC0FD0
frequency 867100000
Internet Transmission Radio LORA
Figure 37 Passerelle (Gateway) LORAWAN
| 38
5 Mise en œuvre drsquoun reacuteseau LoRaWAN
51 Les diffeacuterents types de reacuteseaux Les reacuteseaux LoRaWAN peuvent ecirctre utiliseacute suivant deux meacutethodes
En utilisant les reacuteseaux LoRaWAN opeacutereacutes proposeacutes par les opeacuterateurs de teacuteleacutecoms
En utilisant votre propre reacuteseau LoRaWAN priveacute
511 Les reacuteseaux LoRaWAN opeacutereacutes Ce sont des reacuteseaux LoRaWAN proposeacutes par les opeacuterateurs Par exemple Objenious (filiale de
Bouyges) ou encore Orange Dans le cas de lrsquoutilisation des reacuteseaux opeacutereacutes lrsquoutilisateur a juste
besoin de srsquooccuper des Devices LoRa Les Gateways le Network Server et lrsquoApplication Server sont
geacutereacutes par lrsquoopeacuterateur
512 Les reacuteseaux LoRaWAN priveacutes Chacun est libre de reacutealiser son propre reacuteseau priveacute en impleacutementant sa propre Gateway pour
communiquer avec ses Devices LoRa Lrsquoimpleacutementation du Network Server et de lrsquoApplication Server
peuvent alors ecirctre envisageacutes de diffeacuterentes faccedilons
Network Server et Application serveur priveacutees Crsquoest le deacuteveloppeur qui les mets en place Dans
certaines Gateways une impleacutementation de ces deux serveurs est deacutejagrave proposeacutee Sinon il est
possible de la mettre en place Il existe des serveurs (Network et Application) open source crsquoest le
cas par exemple de LoRa Serveur [ wwwloraserverio ]
Une autre alternantive est httpsgithubcomgotthardplorawan-server
LoRaServer et lorawan-server sont deux applications Open Source
Network Server et Application Server en ligne Un certain nombre de Network Server et
drsquoApplication Server sont proposeacutes Ce sont des services payants ou avec des contreparties
Loriot [ wwwloriotio ]
ResIoT [ wwwresiotio ]
The Things Network [ wwwthethingsnetworkorg ] Crsquoest la solution que nous utiliserons
513 Les zones de couvertures
Les zones de couvertures des reacuteseaux opeacutereacutes sont mise agrave jour par les opeacuterateurs celle drsquoobjenious
est par exemple disponible ici httpsobjeniouscomreseau
Pour connaitre la zone de couverture de notre Gateway utiliseacutee avec TTN nous pouvons utiliser
lrsquoapplication TTN Mapper httpsttnmapperorg Lrsquoideacutee est de promener son Device LoRa associeacute
agrave un GPS dans la zone de couverture des Gateway qui nous entourent A chaque trame reccedilue par le
| 39
Serveur on note les coordonneacutees GPS du Device LoRa ainsi que la Gateway qui a transmis le
message Toutes ces informations sont alors retranscrites sur une carte
52 The Things Network (TTN)
521 Preacutesentation de TTN
Pour la suite nous utiliserons le Network Server et lrsquoApplication Server fourni par TTN
[wwwthethingsnetworkorg]
TTN est gratuit et Open Source En revanche le fait drsquoutiliser TTN impose agrave ceux qui enregistrent
des Gateways de les mettre agrave disposition agrave tous les autres utilisateurs de TTN Lrsquoobjectif est de
reacutealiser un reacuteseau global ouvert
522 Configuration de la Gateway A lrsquouniversiteacute nous avons deux Gateways LoRa (Marque EBDS) Elles sont toutes les deux situeacutees sur
le Campus de Technolac Une Gateway est agrave lrsquointeacuterieur du bacirctiment ISERAN et sert essentiellement
pour les Travaux Pratiques et formations Lrsquoautre est sur le toit du bacirctiment Chablais et est mise agrave
disposition du public via le service de TTN
Les deux Gateway eacutecoutent sur tous les canaux et sur tous les Spreading Factor SF7 gt SF12
Lrsquo IP de la Gateway LoRa agrave lrsquouniversiteacute (bacirctiment ISERAN) est 192168140196
Serveur DNS 1934812032 19348129137
Network Server (TTN) 137616868 routereuthethingsnetwork
Port Upstream 1700 Port Downstream 1700
523 Enregistrement des Gateways Appplication et Devices La configuration de TTN se fait en ligne La premiegravere opeacuteration agrave reacutealiser lorsqursquoune nouvelle
Gateway est deacuteployeacutee crsquoest de lrsquoenregistrer dans TTN
Enregistrement drsquoune Gateway LoRa TTN gt Console gt Gateway gt register gateway
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Figure 38 Scheacutema de notre application
| 40
Figure 39 Enregistrement dune Gateway LoRa sur TTN
Enregistrement drsquoune application TTN gt Console gt Application gt add application
Figure 40 Enregistrement dune application sur TTN
Enregistrement des Devices LoRa dans lrsquoapplication Nom de lrsquoapplication gt register device
Figure 41 Enregistrement des Devices LoRa dans une application
524 Configuration des Devices LoRa Lorsque nous avons enregistreacute des Devices LoRa dans TTN nous devons choisir entre les deux modes
drsquoauthentification Dans un premier temps nous utiliserons le mode le plus simple qui est ABP Nous
geacuteneacuterons dans TTN les DevAddr NetwkSKey et AppSKey
| 41
Figure 42 Configuration des Devices LoRa en ABP dans TTN
53 Mise en application Nous avons dans notre application 10 Devices LoRa drsquoenregistreacutes aduino0 agrave arduino9 Ils sont tous
configureacutes en ABP Les configurations des 10 Devices (DevAddr NetwkSKey et AppSKey) sont noteacutes
en commentaire dans le code de vous allez reacutecupeacuterer
Reacutecupeacuterer le code Arduino laquo RN2483-Arduino-LORAWANino raquo dans Moodle
Modifier votre configuration (DevAddr NetwkSKey et AppSKey) en fonction de votre
numeacutero de binocircme
Veacuterifier que votre Device LoRa arrive bien agrave transmettre des informations (Uplink) vers la
Gateway puis vers le Network Serveur de TTN (The Things Network)
54 Analyse des trames eacutechangeacutees
541 Utilisation de la base 64 Notre Gateway nous preacutesente le Payload PHY en base64 Lrsquoexplication de la meacutethode de
repreacutesentation en base 64 est fourni au travers drsquoun exemple Le code hexadeacutecimal 0x4869
repreacutesente nos donneacutees binaires que nous souhaitons transmettre en base 64
1 On eacutecrit les donneacutees agrave transmettre en binaire
2 On regroupe les eacuteleacutements binaires par des blocs de 6 bits Le nombre de bloc de 6 bits doit
ecirctre un multiple de 4 (minimum 4 blocs) Srsquoil manque des bits pour constituer un groupe de
6 bits on rajoute des zeacuteros
0x4869 = 0100 1000 0110 1001
| 42
3 Srsquoil manque des blocs pour faire un minimum de 4 blocs des caractegraveres speacuteciaux seront
ajouteacutes
4 Chaque groupe de 6 bits est traduit par le tableau suivant (Source Wikipeacutedia)
Figure 43 Codage en base 64
5 Si un bloc de 6 bits manque (ils doivent ecirctre un multiple de 4) on rajoute un ou plusieurs
compleacutements (caractegravere laquo = raquo )
Reacutesultat Le codage de 0x4869 en base 64 est laquo SGk= raquo
010010 000110 100100
On ajoute 00 pour avoir
6 bits dans le groupe
Bloc de 6 bits
010010 000110 100100
S G k
010010 000110 100100
S G k =
1er Bloc
2egraveme Bloc
3egraveme Bloc
4egraveme Bloc
| 43
542 Inteacuterecirct et inconveacutenient de la base 64 Lrsquoutilisation de la base 64 est un choix qui a eacuteteacute fait pour le protocole LoRa LoRaWAN afin de rendre
les donneacutees binaires lisibles Le problegraveme du code ASCII crsquoest qursquoil est composeacute drsquoun certain nombre
de caractegraveres non imprimables (EOF CR LFhellip) Pour eacuteviter ces soucis la base 64 ne comporte que
64 caractegraveres imprimables (voir tableau ci-dessus)
La restriction agrave 64 caractegraveres a cependant un inconveacutenient crsquoest que nous ne pouvons coder que 6
bits (26=64) au lieu de 8 La base 64 est donc moins efficace drsquoune faccedilon geacuteneacuterale
Nous cherchons agrave coder le code ASCII laquo AA raquo en base 64 Retrouver la deacutemarche en
montrant que le reacutesultat en base 64 est laquo QUE= raquo
543 Uplink Du Device LoRa au Network Server Le Network Server de TTN reccediloit des trames IP en provenance de la Gateway Comme nous lrsquoavons
vu preacuteceacutedemment un certain nombre drsquoinformations peuvent ecirctre retrouveacutees avec cette trame
(DevAddr SF Bandwidth etchellip) mais les donneacutees Applicatives sont bien sucircr chiffreacutees (avec
lrsquoAppkSKey) A ce niveau de reacuteception (sans connaitre lrsquoAppSKey) il nrsquoest donc pas possible de
comprendre la totaliteacute du message reccedilu
Imaginons que la trame IP reccedilue 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 45
timestamp 2019-03-05T140042448Z
rssi -82
snr 9
dev_addr 26011AD3
frequency 867300000
Le Network Server affiche donc les informations de la faccedilon suivante
Figure 44 Trame reacutecupeacutereacutee sur le laquo Network Server raquo de TTN
Nous retrouvons bien les valeurs fournies par la Gateway
timestamp ( agrave 1 heure pregraves en fonction du fuseau horaire)
| 44
frequency 8673 Mhz
modulation Lora
Coding Rate 45
data Rate SF 7 125 kHz (DR5)
air time 463 ms
Drsquoautres information proviennent de lrsquoanalyse du Payload Le Payload inscrit ici est le PHY Payload
Il y a donc une partie chiffreacutee (Frame Payload) mais les entecirctes sont en claires (voir paragraphe
441) Ce PHY Payload est laquo QNMaASYABwAP1obuUHQ= raquo Lorsque celui-ci est exprimeacute en
hexadeacutecimal au lieu de la base 64 il vaut laquo 40D31A01260007000FD686EE5074 raquo comme le montre
le Network Server de TTN
Figure 45 PHY Payload preacutesenteacute dans notre Network Server
Sa taille est bien de 14 octets (en hexadeacutecimal) comme preacuteciseacute sur la Figure 44
Nous reprenons le format de la trame LoRaWAN vu agrave la Figure 32 Nous pouvons alors retrouver
tous les champs de toute la trame
PHYPayload = 40D31A01260007000FD686EE5074
PHYPayload = MAC Header[1 octet] | MACPayload[] | MIC[4 octets]
MAC Header = 40 (Unconfirmed data up)
MACPayload = D31A01260007000FD6
Message Integrity Code = 86EE5074
MACPayload = Frame Header | Frame Port | FramePayload )
Frame Header = D31A0126000700
FPort = 0F
FramePayload = D6
Frame Header = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[015]
DevAddr = 26011AD3 (Big Endian)
FCtrl (Frame Control) = 00 (No ACK No ADR)
FCnt (Frame Counter) = 0007 (Big Endian)
FOpts (Frame Option) =
Vous pouvez veacuterifier lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN
(LoRaWAN packet decoder) httpsbitly2szdXtv
| 45
Figure 46 LoRaWAN packet decoder
544 Uplink Du Network Server agrave lrsquoApplication Server
Nous reprenons lrsquoexemple de la trame ci-dessus (Figure 45) Pour information les cleacutes NwkSKey et
AppSKey suivantes ont eacuteteacute utiliseacutee
NwkSKey E3D90AFBC36AD479552EFEA2CDA937B9
AppSKey F0BC25E9E554B9646F208E1A8E3C7B24
Le Network Server a deacutecodeacute lrsquoensemble de la trame Si le MIC est correct (authentification de la
trame par le NwkSKey) alors le Network Server va passer le contenu du message chiffreacute (Frame
Payload) agrave lrsquoApplication Server Dans notre cas le Frame Payload est (drsquoapregraves le deacutecodage effectueacute
au chapitre preacuteceacutedent)
FramePayload = D6
D6 est le contenu chiffreacute lorsqursquoil est deacutechiffreacute avec lrsquoAppSkey on trouve 01 Vous pouvez veacuterifier
lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN httpsbitly2szdXtv
A noter que lrsquoApplication Server recevra les donneacutees chiffreacutees seulement si le Device LoRa a bien
eacuteteacute enregistreacute On peut aussi veacuterifier ci-dessous que lrsquoApplication Serveur de TTN nous retourne bien
un payload (Frame Payload) de 01
Figure 47 Trame reacutecupeacutereacutee sur lrsquoApplication Server de TTN
time 2019-03-05T140042379279991Z
frequency 8673
modulation LORA
data_rate SF7BW125
coding_rate 45
gateways [
gtw_id eui-b827ebfffeae26f6
timestamp 2447508531
time
channel 4
rssi -82
snr 9
latitude 4563647
longitude 58721523
| 46
location_source registry
]
545 Simulation drsquoUplink dans lrsquoApplication Server
Dans beaucoup de situations nous souhaitons valider le fonctionnement de lrsquoApplication Server de
TTN ouet de notre propre Application Il est donc tregraves utile de pouvoir simuler lrsquoenvoi drsquoune trame
LoRa sur lrsquoApplication Server sans que celle-ci soit reacuteellement eacutemise par un Device LoRa Pour cela
un outil existe dans les Settings de chaque Device enregistreacute dans TTN Nous avons juste besoin de
speacutecifier le Frame Payload en clair en hexadeacutecimal et le numeacutero de Port
Figure 48 Simulation drsquoune trame envoyeacutee par un Device LoRa
546 Downlink De lrsquoApplication Server au Device LoRa La communication LoRa est bidirectionnelle Des donneacutees peuvent ecirctre transmis au Device LoRa
depuis lrsquoApplication Server Depuis TTN un outil existe dans les Settings de chaque Device
enregistreacute Lrsquointerface est repreacutesenteacutee ci-dessous
Figure 49 Transmission de donneacutees de lrsquo laquo Application Server raquo jusqursquoau Device LoRa
Replace scheduling Mode Par deacutefaut le Frame Payload transmis remplacera le Frame
Payload en attente (si il existe) Dans ce mode un seul Frame Payload est planifieacute
First scheduling Mode Le Frame Payload est mis en file drsquoattente en premiegravere position
Last scheduling Mode Le Payload est mis en file drsquoattente en derniegravere position
Une demande de confirmation peut ecirctre demandeacutee au Device LoRa pour qursquoil preacutecise srsquoil a bien reccedilu
les donneacutees Lrsquooption laquo confirmed raquo permet donc de speacutecifier le type de trame dans le MAC Header
(voir paragraphe 443) laquo Confirmed Data Down raquo ou laquo Unconfirmed Data Down raquo dans notre cas
| 47
6 La reacutecupeacuteration des donneacutees sur notre propre Application
Nous utiliserons agrave nouveau le Network Server et Application Server de The Things Network Jusqursquoici
nous nous sommes contenteacute de veacuterifier que les donneacutees de lrsquoutilisateur (Frame Payload) soient bien
arriveacutees agrave destination dans lrsquoApplication Server Il faut maintenant les reacutecupeacuterer avec notre propre
Application qui aura pour rocircle
De stocker et traiter les donneacutees
De les mettre agrave disposition de lrsquoutilisateur (Serveur Web par exemple)
Drsquoenvoyer des commandes de lrsquoutilisateur aux Devices LoRa si besoin (Flux Downlink)
Nous allons voir deux meacutethodes pour communiquer entre notre application et TTN
Le protocole HTTP POST
Le protocole MQTT
61 Reacutecupeacuteration des donneacutees en HTTP POST dans lrsquoApplication
611 Preacutesentation du protocole HTTP
Dans le monde de lrsquointernet le protocole HTTP est tregraves utiliseacute pour le dialogue entre un client et un
serveur web Classiquement le client (un navigateur web par exemple) fait une requecircte HTTP GET
et le serveur lui retourne le contenu de la page web demandeacutee
Dans notre cas la probleacutematique est diffeacuterente car le client doit modifier le contenu du serveur
avec les donneacutees envoyeacutees par le Device LORA La requecircte srsquoappelle HTTP POST Son nom indique
que le client va poster (et on pas reacutecupeacuterer) des donneacutees
Lrsquoutilisateur qui souhaite reacuteceptionner des donneacutees sur son serveur doit donc concevoir un serveur
HTTP capable de traiter des requecirctes HTTP POST [ requecircte noteacutee (1) sur la Figure 51 ] fournies par
TTN Dans cette configuration TTN jouera le rocircle de client et notre application le rocircle de serveur
Devices
LORA Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
HTTP POST
MQTT Internet
Figure 50 Structure globale drsquoun reacuteseau LORAWAN
| 48
Figure 51 Communication bidirectionnelle entre TTN et notre Application
A lrsquoinverse lrsquoutilisateur qui souhaite transmettre des donneacutees agrave destination du Device LoRa
(Downlink) doit ecirctre capable de fournir une requecircte HTTP POST [ requecircte noteacutee (2) sur la Figure 51
] vers TTN Dans cette configuration TTN jouera le rocircle de Serveur et notre application le rocircle de
client
612 Fonctionnement drsquoun client et drsquoun serveur HTTP POST Afin de bien comprendre le fonctionnement des requecirctes HTTP POST nous allons proceacuteder par
eacutetape Le premier test que nous effectuerons sera decorreacuteleacute de TTN Le principe est le suivant
Utilisation drsquoun serveur HTTP disponible sur le web geacuterant les requecirctes HTTP POST [
httpsrbasketsin ] ou [ httpsbeeceptorcom ] par exemple
Utilisation drsquoun client HTTP eacutemettant des requecirctes HTTP POST commande curl sous linux
ou logiciel Postman [ wwwgetpostmancom ] sous windows par exemple
Ce test nous permet de valider le fonctionnement drsquoun serveur HTTP POST et drsquoun client HTTP POST
Une fois que nous serons sucircr de leur fonctionnement nous les utiliserons avec TTN
The Things Network
Application
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 49
Figure 52 Validation dun server HTTP POST et drsquoun client HTTP POST
613 Test du serveur HTTP POST Nous utiliserons un serveur web proposeacute par httpsrbasketsin
Aller sur le site httpsrbasketsin et creacuteer un nouveau laquo Basket raquo Zone ougrave vous pourrez
visualiser les requecirctes qui ont eacuteteacute eacutemises vers votre serveur
A partir de maintenant toutes les requecirctes dirigeacutees vers lrsquoadresse creacuteeacute seront traiteacutees et
srsquoafficheront Dans le menu de configuration il est aussi possible de deacutefinir le contenu de la reacuteponse
qui sera fournie
Deacutefinir un format de reacuteponse pour les requecirctes HTTP POST avec un body personnaliseacute
614 Test du client HTTP POST On peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande (la commande cURL
srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN sous Windows
Commande cURL curl ndashX POST ndashd lsquorsquodonneacutees agrave envoyerrsquorsquo DuServeurHTTP
Logiciel Postman New gt Request gt Creacuteer une requecircte HTTP POST gt Send
Veacuterifier que les requecirctes HTTP POST sont bien reacutecupeacutereacutees sur votre serveur creacutee preacuteceacutedemment
615 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST
Maintenant que nous avons un serveur HTTP (POST) fonctionnel nous allons configurer TTN pour
jouer le rocircle du client et pour qursquoil envoie des requecirctes HTTP POST vers notre Serveur degraves qursquoune
donneacutee drsquoun Device LoRa est disponible Nous geacuterons donc ici le flux Uplink
Requecircte
HTTP POST
Reacuteponse
(contenu parameacutetrable)
Client HTTP (POST)
Server HTTP (POST) [ httpsrbasketsin ]
| 50
Figure 53 Reacutecupeacuteration des donneacutees sur notre Application
Dans TTN nous inteacutegrons un bloc appeleacute laquo HTTP Integration raquo permettant de jouer le rocircle de client
crsquoest-agrave-dire drsquoenvoyer des requecirctes HTTP POST agrave destination de notre nouveau Serveur HTTP
Lrsquointeacutegration se faire agrave partir de TTN gt Console gt Application gt Nom_de_votre_application gt
Integration
Figure 54 Ajout dun client HTTP POST dans TTN
Pour valider le fonctionnement de notre architecture nous pouvons soit
Envoyer une trame depuis un Device LoRa vers TTN
Simuler lrsquoenvoi drsquoune trame drsquoun Device LoRa vers TTN (gracircce agrave lrsquooutil proposeacute par TTN vu
paragraphe 545)
Dans les deux cas voici un exemple de requecircte POST reccedilue sur notre serveur HTTP
app_id test_app_lorawan_sylvainmontagny
dev_id stm32lorawan_1
hardware_serial 0056AF49877
port 1
counter 0
payload_raw qg==
metadata
Requecircte
HTTP POST
Server HTTP (POST) [ httpsrbasketsin ]
The Things Network (Client)
La requecircte contient le Frame Payload deacutechiffreacutee
agrave transmettre agrave lrsquoApplication
| 51
time 2019-01-24T15243703499298Z
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Comme nous pouvons le voir le contenu fourni agrave notre serveur est formateacute en JSON (voir
paragraphe 0) Voici quelques compleacutements drsquoinformation
payload_raw Frame Payload deacutechiffreacute crsquoest donc les donneacutees en clairs dans la base 64
downlink_url URL du serveur HTTP POST qui serviront agrave transmettre des donneacutees au Device
LoRa (flux Downlink)
611 Envoyer des donneacutees depuis notre Application avec HTTP POST
Lorsque nous avons ajouteacute le bloc laquo HTTP Integration raquo au paragraphe preacuteceacutedent nous avons aussi
implicitement activeacute la fonctionnaliteacute que TTN soit precirct agrave recevoir et agrave traiter les requecirctes HTTP
POST La seule information qursquoil nous manque est lrsquoadresse du server HTTP vers lequel il faut eacutemettre
les requecirctes Si on observe la trame reccedilue preacuteceacutedemment en provenance de TTN on srsquoaperccediloit que
dans la trame JSON reccedilu une URL (downlink_url) est speacutecifieacutee
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Crsquoest cette URL que nous devrons utiliser Nous allons nous placer dans la configuration suivante
Figure 55 Envoi de donneacutees agrave partir de notre Application
Comme preacuteceacutedemment on peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande
(la commande cURL srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN
Commande cURL curl ndashX POST ndashdata lsquo dev_id Identidiant_De_Votre_Device
payload_raw AQE= rsquo DuServeurHTTP
Logiciel Postman New gt Request gt HTTP POST puis Body gt Raw gt JSON
Requecircte HTTP POST vers serveur TTN laquo downlink_url raquo httpsintegrationsthethingsnetworUaeb8ypKieQ
Contenu de la requecircte
dev_id Identidiant_De_Votre_Device
payload_raw aGVsbG8=
The Things Network (Serveur)
POSTMAN (Client HTTP POST)
| 52
dev_id YourDeviceID
payload_raw aGVsbG8=
Vous devez envoyer le texte (payload_raw) en base 64 Dans lrsquoexemple ci-dessus laquo aGVsbG8= raquo
correspond agrave la chaine de caractegravere laquo hello raquo Vous pouvez utiliser les nombreux encodeurdecodeur
en ligne pour vous aider Le texte doit srsquoafficher sur votre moniteur seacuterie Arduino dans le cadre de
notre deacutemonstrateur sur Arduino
62 Reacutecupeacuteration des donneacutees avec MQTT dans lrsquoApplication
621 Preacutesentation du protocole MQTT
MQTT est un protocole leacuteger qui permet de srsquoabonner agrave des flux de donneacutees Plutocirct que
lrsquoarchitecture Client Serveur classique qui fonctionne avec des Requecirctes Reacuteponses MQTT est
baseacute sur un modegravele Publisher Subscriber La diffeacuterence est importante car cela eacutevite davoir agrave
demander (Requecircte) des donneacutees dont on na aucune ideacutee du moment ougrave elles vont arriver Une
donneacutee sera donc directement transmise au Subscriber degraves lors que celle-ci a eacuteteacute reccedilue dans le
Broker (serveur central)
Figure 56 Modegravele Publisher Subscriber du protocole MQTT
Pour recevoir les donneacutees appartenant agrave un Topic un Subscriber doit souscrire (comme son nom
lindique) au preacutealable sur ce Topic
MQTT est un protocole qui repose sur TCP Lencapsulation des trames sur le reacuteseau est donc la
suivante
Broker
Client
Publisher 1
Client
Publisher 2
Client
Subscriber
Topic
Tempeacuterature
Topic
Humiditeacute
| 53
Figure 57 Protocoles utiliseacutes pour la communication avec MQTT
On peut le veacuterifier par une capture de trame sur Wireshark
Figure 58 Capture dune trame MQTT avec Wireshark
On peut noter que le port TCP utiliseacute pour le protocole MQTT (non chiffreacute) est le 1883
Les Publishers et les Subscribers nrsquoont pas besoin de se connaitre
Les Publishers et les Subscribers ne sont pas obligeacute de srsquoexeacutecuter en mecircme temps
622 Connexion au Broker MQTT Nous nous inteacuteresserons essentiellement aux options de connexion qui permettront de geacuterer la
Qualiteacute de Service (QoS) Pour se connecter un client MQTT envoie deux informations importantes
au Broker
keepAlive Cest la peacuteriode la plus longue pendant laquelle le client Publisher ou Subscriber pourra
rester silencieux Au-delagrave il sera consideacutereacute comme deacuteconnecteacute
cleanSession Lorsque le Client et le Broker sont momentaneacutement deacuteconnecteacutes (au-delagrave du
keepAlive annonceacute) on peut donc se poser la question de savoir ce quil se passera lorsque le client
sera agrave nouveau connecteacute
Si la connexion eacutetait non persistante (cleanSession = True) alors les messages non transmis
sont perdus Quel que soit le niveau de QoS (Quality of Service)
Si la connexion eacutetait persistante (cleanSession = False) alors les messages non transmis
seront eacuteventuellement reacuteeacutemis en fonction du niveau de QoS Voir le chapitre 624
623 Qualiteacute de Service au cours dune mecircme connexion
A partir du moment ougrave le Client se connecte au Broker il est possible de choisir un niveau de fiabiliteacute
des transactions Le Publisher fiabilise leacutemission de ces messages vers le Broker et le Subscriber
fiabilise la reacuteception des messages en provenance du Broker Une parle ici du cas dune mecircme
connexion crsquoest-agrave-dire entre le moment ou le Client se connecte et le moment ougrave
Soit il se deacuteconnecte explicitement (Close connexion)
Soit il na rien eacutemis ni fait signe de vie pendant le temps keepAlive
TCP
MQTT
Reacuteseau
Transport
Couche Application
IP
| 54
Lors dune mecircme connexion la Qualiteacute de Service (QoS) qui est mise en œuvre deacutepend uniquement
de la valeur du QoS selon les valeurs suivantes
QoS 0 At most once (au plus une fois) Le premier niveau de qualiteacute est sans acquittement Le
Publisher envoie un message une seule fois au Broker et le Broker ne transmet ce message quune
seule fois aux Subscribers Ce meacutecanise ne garantit pas la bonne reacuteception des messages MQTT
QoS 1 At least once (au moins une fois) Le deuxiegraveme niveau de qualiteacute est avec acquittement
Le Publisher envoie un message au Broker et attends sa confirmation De la mecircme faccedilon le Broker
envoie un message agrave ces Subscriber et attends leurs confirmations Ce meacutecanisme garantit la
reacuteception des message MQTT
Cependant si les acquittements nrsquoarrivent pas en temps voulu ou srsquoils se perdent la reacuteeacutemission du
message dorigine peut engendrer une duplication du message Il peut donc ecirctre reccedilu plusieurs fois
QoS 2 Exactly once (exactement une fois) Le troisiegraveme niveau de qualiteacute est garanti une seule
fois Le Publisher envoie un message au Broker et attends sa confirmation Le Publisher donne alors
lrsquoordre de diffuser le message et attends une confirmation Ce meacutecanisme garantit que quel que
soit le nombre de tentatives de reacuteemission le message ne sera deacutelivreacute quune seule fois
La Figure 59 montre les trames eacutemises pour chaque niveau de QoS
Figure 59 Qualiteacute de Service en MQTT
La Figure 60 repreacutesentes les 3 captures de trames sur Wireshark repreacutesentant les 3 QoS (1 2 et 3)
que nous venons dexpliquer
Broker
QoS 0
Au plus une fois
Message supprimeacute apregraves envoi
PUBLISH
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Duplications possibles
PUBLISH
PUBLICH Ack
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Pas de duplication
PUBLISH
PUBLISH Receive
PUBLISH Release
PUBLISH Complete
| 55
Figure 60 Capture de trame avec QoS = 0 puis QoS = 1 puis QoS = 2
624 Qualiteacute de Service apregraves une reconnexion
La question que nous nous posons et de savoir ce que deviennent les messages publieacutes sur le Broker
lorsquun ou plusieurs Subscribers sont momentaneacutement injoignables Il est possible de conserver
les messages qui ont eacuteteacute publieacutes sur le Broker afin de les retransmettre lors de la prochaine
connexion Cette possibiliteacute de sauvegarde doit ecirctre activeacutee agrave louverture de connexion gracircce au flag
cleanSession = 0 La connexion sera alors persistante crsquoest-agrave-dire que le Broker enregistre tous les
messages quil na pas reacuteussi agrave diffuser au Subscriber
Le Tableau 9 reacutesume leffet du flag cleanSession et du QoS
Clean Session Flag Subscriber QoS Publisher QoS Comportement True ( = 1) 0 1 2 0 1 2 Messages perdus
False ( = 0 ) 0 0 1 2 Messages perdus
False (= 0 ) 0 1 2 0 Messages perdus
False (= 0 ) 1 2 1 2 Tous les messages sont retransmis
Tableau 9 Qualiteacute de Service en fonction de la valeur du QoS et du flag cleanSession
625 Les Topics du protocole MQTT Les chaicircnes deacutecrivant un sujet forment une arborescence en utilisant la barre oblique comme
caractegravere de seacuteparation La Figure 61 et le Tableau 10 donne un exemple dorganisation de Topic
Figure 61 Exemple de hieacuterarchie de Topic MQTT
Niveau 3
Niveau 2
Niveau 1 Maison
Chambre
Temperature Humidite Bruit
Salon
Temperature
| 56
Nom du Topic Deacutetail du Topic MaisonChambreTemperature La tempeacuterature de la chambre de la maison
MaisonChambreBruit Le bruit de la chambre de la maison
MaisonSalonTemperature La tempeacuterature du Salon de la maison
Tableau 10 Exemple de Topic
Un client peut sabonner (ou se deacutesabonner) agrave plusieurs branches de larborescence agrave laide de
jokers englobant plusieurs Topics Deux caractegraveres jokers existent
Le signe plus + remplace nimporte quelle chaine de caractegravere sur le niveau ougrave il est placeacute
Le diegravese remplace nimporte quelle chaine de caractegravere sur tous les niveaux suivants Il
est obligatoirement placeacute agrave la fin
Nom du Topic Deacutetail du Topic Maison+Temperature Les tempeacuteratures de toutes les piegraveces de la maison
MaisonChambre La tempeacuterature lhumiditeacute et le bruit de la chambre de la maison
Tableau 11 Exemple de Topic
626 Mise en place drsquoun Broker MQTT Afin de bien comprendre le fonctionnement du protocole de MQTT on reacutealise des tests
indeacutependamment de TTN Nous allons mettre en place
Un Broker Mosquitto httpstestmosquittoorg
Un client Publisher MQTT Box sur Windows
Un client Subscriber MQTT Box sur Windows
Figure 62 Test du protocole MQTT
MQTT Client (Subscriber)
MQTT Client (Publisher)
Publish
Subscribe
BROKER (Mosquitto)
| 57
Le Broker MQTT est commun agrave tout le monde Nous pouvons soit le reacutealiser nous-mecircme soit utiliser
un Broker MQTT public de test Nous utiliserons le Broker de test de Mosquitto disponible sur
httpstestmosquittoorg Drsquoautres sont eacuteventuellement disponibles en cas de problegraveme par
exemple httpwwwmqtt-dashboardcom
Si nous deacutecidions de le reacutealiser nous-mecircme agrave lrsquoaide drsquoune Raspberry Pi (par exemple) Lrsquoinstallation
se ferait en deux lignes de commande
apt-get install mosquito Installation
sudo systemctl start mosquittoservice Lancement du service
Il est neacutecessaire drsquoinstaller mosquitto-clients si on souhaite que le Raspberry PI joue aussi le rocircle de
client ce qui nrsquoest pas notre cas
627 Mise en place drsquoun Publisher et drsquoun Subscriber MQTT Lancer le logiciel MQTTBox
MQTTBox gt Create MQTT Client
Dans ce client les seuls champs indispensables sont
Protocol MQTT TCP
Host testmosquittoorg
Figure 63 Configuration dun Client MQTT dans MQTT Box
Tester lrsquoenvoi et la reacuteception sur les Topics de votre choix
628 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT La reacutecupeacuteration des donneacutees fait reacutefeacuterence au flux Uplink Dans ce cas
TTN joue le rocircle de client Publisher
TTN joue aussi le rocircle de Broker
Notre application joue le rocircle de Subscriber
Nous pouvons donc repreacutesenter lrsquoapplication globale par le scheacutema suivant
| 58
Figure 64 Publisher et Subscriber dans en MQTT avec TTN
La publication est repreacutesenteacutee par la trame MQTT (1)
La souscription est repreacutesenteacutee par la trame MQTT (2)
Le client Publisher eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box mais cette fois avec la configuration suivante
Protocol mqtt tcp
Host Crsquoest lrsquoIP du Broker vers lequel il faut se connecter Dans notre cas il srsquoagit de celui
de TTN dont lrsquoadresse est euthethingsnetwork
Username La connexion vers le broker MQTT est soumis agrave une authentification Username
Password Dans notre cas le Username correspond au nom de notre application crsquoest-agrave-
dire seminaire_lorawan Si vous avez choisi une autre applicationil faut bien mettre la
votre
Password Le Password est nommeacute laquo Access Key raquo par TTN Elle vous sera donneacutee par
lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application vous
trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt Overview
Figure 65 Access Keys de lapplication dans TTN
The Things Network (Application Server)
BROKER
Application
The Things Network (Network Server)
Publish (1 )
[ Flux Uplink ]
Subscribe (2 )
[ Flux Uplink ]
| 59
Figure 66 Configuration du Client dans MQTT Box
Le client MQTT eacutetant configureacute il est maintenant capable de se connecter au Broker Il reste donc agrave
deacutefinir le fait que le client sera Subscriber Les informations que recevra le Subscriber deacutependent du
Topic auquel nous souscrivons Voici les Topic disponibles sur le Broker de TTN
ltAppIDgt correspond au nom de votre Application
ltDevIDgt correspond au nom de votre Device LoRa
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink ltAppIDgtdevicesltDevIDgtup
[Donneacutees] Flux Downlink ltAppIDgtdevicesltDevIDgtdown
[Activation Events] Activation dun Device ltAppIDgtdevicesltDevIDgteventsactivations
[Management Events] Creacuteation dun Device ltAppIDgtdevicesltDevIDgteventscreate
[Management Events] Update dun Device ltAppIDgtdevicesltDevIDgteventsupdate
[Management Events] Suppression dun Device ltAppIDgtdevicesltDevIDgteventsdelete
[Downlink Events ] Message programmeacute ltAppIDgtdevicesltDevIDgteventsdownscheduled
[Downlink Events ] Message envoyeacute ltAppIDgtdevicesltDevIDgteventsdownsent
[Erreurs] Uplink erreurs ltAppIDgtdevicesltDevIDgteventsuperrors
[Erreurs] Downlink erreurs ltAppIDgtdevicesltDevIDgteventsdownerrors
[Erreurs] Activations erreurs ltAppIDgtdevicesltDevIDgteventsactivationserrors
Tableau 12 Topics enregistreacutes dans TTN
Dans un premier temps nous souscrivons au Topic +devices+up Cela signifie que nous
souscrivons agrave tous les Devices LoRa de toutes nos applications pour le flux Uplink
Figure 67 Configuration du Subscriber
Les eacuteleacutements eacutemis par le Broker seront alors afficheacutes dans MQTTBox La
| 60
Figure 68 Trame LoRaWAN reccedilu sur le Subscriber MQTT
Ces donneacutees sont eacutecrites en JSON nous pouvons les remettre en forme
applicationID3
applicationNamemyApplication
deviceNamearduino0
devEUI0056xxxxxxxxx877
txInfo
frequency868500000
dr5
adrfalse
fCnt792
fPort15
dataSGVsbG8=
Le Frame Payload deacutechiffreacute est fourni dans le champ data en base 64 La valeur fournie par
dataSGVsbG8= correspond bien agrave la chaine de caractegravere hello que nous avons eacutemise avec le
Device LoRa
629 Envoyer des donneacutees depuis notre Application avec MQTT
Lrsquoenvoi des donneacutees fait reacutefeacuterence au flux Downlink Dans ce cas
Notre application joue le rocircle de Publisher
TTN joue le rocircle de Broker
TTN joue aussi le rocircle de client Subscriber
| 61
La publication est repreacutesenteacutee par la trame MQTT (3)
La souscription est repreacutesenteacutee par la trame MQTT (4)
Le client Subscriber eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box Le rocircle de client dans MQTT Box a eacuteteacute faite au
paragraphe 628 Il nous reste simplement agrave ajouter le rocircle de Publisher La configuration est la
suivante
Topic du Subscriber seminaire_lorawandevicesarduino0down ougrave seminaire_lorawan
est agrave remplacer par le nom de votre application et arduino0 par le nom du Device LoRa vers
lequel vous souhaitez envoyeacute une donneacutee (Voir chapitre 628 pour comprendre les Topics)
Le Payload doit ecirctre au format JSON Lrsquoexemple suivant envoie laquohello raquo
payload_raw aGVsbG8=
The Things Network (Application Server)
BROKER
Application
Publish (3)
[ Flux Downlink ]
The Things Network (Network Server)
Subscribe (4)
[ Flux Downlink ]
| 62
Figure 69 Configuration du Publisher
Vous devriez voir les donneacutees arriver sur votre Device LoRA
| 63
7 Creacuteation de notre propre Network et Application Server
711 Objectifs Lors de la mise en œuvre du reacuteseau LoRaWAN au chapitre 52 nous avons utiliseacute TTN (The Things
Network) pour jouer le rocircle de Network Server et drsquoApplication Server Pour de multiples raisons
Seacutecuriteacute autonomie coucircthellipil peut ecirctre inteacuteressant de monter soi-mecircme un Network Server et un
Application Server Cela est possible seulement si vous posseacutedez vos propres Gateway puisque
celles-ci devront forwarder leur paquet agrave destination preacutecise Il faudra donc les reconfigurer pour
qursquoelles pointent vers votre nouvelle architecture
712 Preacutesentation de LoRaServer LoRaServer [ wwwloraserverio ] est un projet Open-Source reacutepondant exactement au besoin que
nous avons Nous lrsquoutiliserons sur une cible Raspberry PI En reacutealiteacute il peut souvent ecirctre mise en
place dans le mecircme systegraveme que la Gateway surtout si celle-ci est elle-mecircme agrave base de RPI Les
Gateway EBDS que nous posseacutedons possegravedent drsquoailleurs un Network Server et un Application Server
que nous aurions pu utiliser Neacuteanmoins pour des raisons peacutedagogiques il est inteacuteressant de
seacuteparer les systegravemes pour bien diffeacuterencier les probleacutematiques
Attention il y a une ambiguiumlteacute dans la deacutenomination des entiteacutes logiciels de LoRaServer
LoRaServer (sans espace entre le mot LoRa et Server) est le nom du projet global En
revanche LoRa Server (avec un espace) est le nom du service qui joue le rocircle du Network
Server
Lrsquoarchitecture et le fonctionnement de LoRaServer est preacutesenteacutee dans sa documentation par le
scheacutema suivant
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Raspberry PI
Figure 70 Architecture globale de notre reacuteseau loRaWAN
| 64
Figure 71 Architecture deacutetailleacutee de LoRaServer
On srsquoattends agrave voir uniquement un Network Server (LoRa Server) et un Application Server (LoRa App
Server) mais ce scheacutema est plus complexe Il demande un certain nombre drsquoexplications pour bien
comprendre ce que nous allons installer et la faccedilon dont nous lrsquoutiliserons par la suite
713 Le laquo Packet Forwarder raquo (Gateway) Comme nous lrsquoavons vu au chapitre 412 les Gateways LoRa sont des passerelles entre la
modulation LoRa et un reacuteseau IP Pour reacutealiser cette passerelle un service nommeacute laquo UDP Packet
Forwarder raquo a eacuteteacute deacuteveloppeacute par Semtech httpsgithubcomLora-netpacket_forwarder Dans
ce dossier github un fichier nommeacute PROTOCOLTXT explique parfaitement ce protocole applicatif
qui travaille au-dessus de UDP
Figure 72 Protocole Uplink (PUSH_DATA du Packet Forwarder)
| 65
On remarque que les paquets sont envoyeacutes en UDP au Network Server dans une trame appeleacutee
PUSH_DATA Cette trame est acquitteacutee par le Network Server par une trame appeleacutee PUSH_ACK
Sur notre Network Server nous pouvons reacutealiser une capture de trame pour veacuterifier si le protocole
est bien celui preacutesenteacute dans le document
Figure 73 Trame captureacutee par Wireshark lors dun Uplink
Drsquoapregraves la capture preacuteceacutedente on remarque que le Packet Forwarder fonctionne bien avec UDP sur
le port 1700
Le contenu des donneacutees (champ Data) est deacutetailleacute dans le tableau suivant
Champ | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | random token
[3] | 3 | PUSH_DATA identifier = 0x00
[4] | 4-11 | Gateway unique identifier (MAC address)
[5] | 12-end | JSON object starting with ending with
Lrsquoobjet JSON de la transmission reacuteeacutecrit plus proprement est celui-ci
Figure 74 Analyse du champ Donneacutees du protocole laquo Packet Forwarder raquo
0000 02 f9 30 00 b8 27 eb ff fe ae 26 f5 7b 22 72 78 0amprx 0010 70 6b 22 3a 5b 7b 22 74 6d 73 74 22 3a 33 37 35 pk[tmst375 0020 35 30 30 35 38 31 39 2c 22 63 68 61 6e 22 3a 32 5005819chan2 0030 2c 22 72 66 63 68 22 3a 31 2c 22 66 72 65 71 22 rfch1freq 0040 3a 38 36 38 2e 35 30 30 30 30 30 2c 22 73 74 61 868500000sta 0050 74 22 3a 31 2c 22 6d 6f 64 75 22 3a 22 4c 4f 52 t1moduLOR 0060 41 22 2c 22 64 61 74 72 22 3a 22 53 46 37 42 57 AdatrSF7BW 0070 31 32 35 22 2c 22 63 6f 64 72 22 3a 22 34 2f 35 125codr45 0080 22 2c 22 6c 73 6e 72 22 3a 36 2e 35 2c 22 72 73 lsnr65rs 0090 73 69 22 3a 2d 31 2c 22 73 69 7a 65 22 3a 31 38 si-1size18 00a0 2c 22 64 61 74 61 22 3a 22 51 4e 4d 61 41 53 59 dataQNMaASY 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 ]
Ch
amp
[1
]
Ch
amp
[2
]
Ch
amp
[3
]
Ch
amp
[4
]
| 66
rxpk[ tmst3755005819
chan2
rfch1
freq868500000
stat1
moduLORA
datrSF7BW125
codr45
lsnr65
rssi-1
size18
dataQNMaASYAAQAPpyPZ955+SmY
]
Le champ data correspond au PHY Payload
De la mecircme faccedilon on retrouve la Trame drsquoacquittement
Figure 75 Trame captureacutee par Wireshark lors de lrsquoacquittement drsquoun Uplink
Champs | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | same token as the PUSH_DATA to acknowledge
[3] | 3 | PUSH_ACK identifier = 0x01
Nous retrouvons bien tous ces champs dans la trame Wireshark
714 LoRa Gateway Bridge Nous avons deacutecrit au chapitre preacuteceacutedent (713) le fonctionnement du Packet Forwarder Le
Network Server(Lora Server) que nous allons mettre en place aurait tregraves bien pu srsquointerfacer
directement agrave ce protocole Mais cela aurait plusieurs impacts dont un qui est important dans la
conception de logiciel Si le Packet Forwarder change ou si un autre type de Forwarder est utiliseacute
alors lrsquoutilisation du LoRa Server devient impossible Il a donc eacuteteacute choisi de creacuteer une eacutetape
intermeacutediaire Le Network Server que nous mettrons en plus utilisera le protocole MQTT plutocirct que
le protocole UDP packet Forwarder
En drsquoautres termes le LoRa Gateway Bridge est un service qui fera abstraction du Packet Forwarder
pour srsquointerfacer plus simplement avec le Network Server
715 LoRa Server (Network Server) Il srsquoagit de notre Network Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
413 Cependant il srsquointerfacera au protocole MQTT en recevant les informations agrave partir du
Broker au lieu de recevoir directement les trames en provenance de la Gateway
| 67
716 LoRa App Server (Application Server) Il srsquogit de notre Application Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
414
717 LoRa Geo Server Il srsquoagit drsquoun service qui permet drsquoutiliser certaines proprieacuteteacutes du protocole LoRa pour proposer un
service de geacuteolocalisation des Devices LoRa Nous ne lrsquoutiliserons pas dans notre cas
718 Application Il srsquoagit de notre Application qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre 415
Elle ne fait pas partie du projet LoRaServer crsquoest donc bien toujours agrave nous de proposer notre propre
Application
Figure 76 Les interfaces possibles entre LoRaServer et lrsquoApplication utilisateur
Comme nous pouvons le voir sur la figure preacuteceacutedente deux possibiliteacutes sont offertes pour interfacer
notre application JSON REST (incluant HTTP POST) et via un Broker MQTT Ces deux meacutethodes ont
deacutejagrave eacuteteacute traiteacutee au chapitre 61 (HTTP POST ) et au chapitre 62 (MQTT) Nous verrons aussi drsquoautres
possibiliteacutes pour personnaliser notre application au chapitre 7
72 Installation de LoRaServer
721 Mise en place de lrsquoenvironnement
Nous allons installer une carte SD avec la derniegravere version de Raspbian Nous ne deacutetaillerons pas la
deacutemarche pour cela car elles sont largement documenteacutees et mises agrave jour sur le site
wwwraspberrypiorg
Installer un carte SD avec la derniegravere version de Raspbian
Plutocirct que de fonctionner avec un clavier et une souris nous preacuteconisons de travailler agrave distance
avec la RPI via une connexion SSH Depuis quelques anneacutees Raspbian a supprimeacute le deacutemarrage du
service SSH au boot Heureusement il est possible de le reacuteactiver par la meacutethode suivante
Avec Windows ou Linux ouvrir la partition BOOT de votre carte SD et placer un fichier agrave la
racine nommeacute sshtxt (ou ssh)
Mettre la carte SD dans votre RPI et la deacutemarrer
| 68
Pour acceacuteder agrave la RPI en SSH depuis Windows nous utiliserons de preacutefeacuterence le logiciel
client MobaXterm mais tout autre client SSH est valable
Installer MobaXterm sur votre PC et connectez-vous agrave votre Raspberry PI
Lrsquoutilisation drsquoun espion de reacuteseau type Wireshark peut ecirctre inteacuteressant pour eacutetudier les trames qui
sont reccedilues et qui sont eacutemises Cela nous permettra de valider le fonctionnement des diffeacuterents
protocoles reacuteseau qui permettent de communiquer agrave la Gateway drsquoune part et agrave lrsquoApplication
drsquoautre part Nous utiliserons tshark
apt-get install tshark installation
tshark ndashn -i eth0 Exemple drsquoune analyse sur lrsquointerface wlan0
722 Installation sur la Raspberry PI La meacutethode drsquoinstallation de LoRaServer est documenteacutee sur le site web agrave lrsquoadresse suivante
[ httpswwwloraserverioguidesdebian-ubuntu ] Nous installerons le LoRa Gateway Bridge
le LoRa Server et le LoRa App Server
Apregraves lrsquoinstallation la configuration se fait par une interface graphique accessible par le reacuteseau sur
le port 8080
Si vous travaillez sur la RPI connectez-vous sur httplocalhost8080
Si vous travaillez agrave distance (SSH) connectez-vous sur httpIP_RPI8080
Les Usernames et Password par deacutefaut sont
Username admin
Password admin
Lrsquoeacutecran drsquoaccueil sera donc le suivant
Figure 77 Architecture globale apregraves installation de LoRaServer
Devices
Gateways LoRa
UDP Packet Forwarder
Application Server
LoRa App Server
Internet
Network Server
LoRa Server
LoRa Gateway Bridge
| 69
Figure 78 Ecran daccueil de LoRaServer apregraves authentification
71 Configuration de LoRa Server pour lUplink
711 Enregistrement drsquoune nouvelle Organisation
Pour enregistrer une nouvelle Organizations Organizations gt Create Puis entrer les configurations
suivantes
Figure 79 Enregistrement dun nouvelle Organisation
712 Enregistrement drsquoune instance du Network Server Pour enregistrer une nouvelle instance du Network Server Network Server gt Create Puis entrer
les configurations suivantes
| 70
Figure 80 Enregistrement dun nouveau Network Server
Dans lrsquoonglet Gateway Discovery il est possible drsquoactiver une option de deacutecouverte de Gateway aux
alentours Lorsqursquoelle est configureacutee le Network Server va envoyer une trame Downlink de
configuration de la Gateway lui ordonnant de reacutealiser des PING en LoRa La configuration du
Gateway Discovery preacutevoit de speacutecifier
Le nombre de fois par jour que les PING LoRa sont envoyeacutes
Le canal drsquoeacutemission
Le Data Rate (Voir paragraphe 445)
Un PING LoRa reccedilu sur une Gateway sera retransmis sur le Network Server (Lora Server) et une carte
sera afficheacutee
Lrsquoonglet TLS Certificates ne sera pas utiliseacute dans le cadre de notre deacutemonstration
713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) Il faut tout drsquoabord faire un enregistrement drsquoun laquo service-profile raquo Un laquo service profile permet de
faire la connexion entre le Network Server et les Applications que nous enregistrerons dans notre
Organisation Service-profiles gt Create
Service-profile name myServiceProfile
Network-server myNetworkServer
On laissera par deacutefaut toutes les autres options
Pour enregistrer une nouvelle Application Applications gt Create Puis entrer les configurations
suivantes
| 71
Figure 81 Enregistrement dune nouvelle Application
714 Enregistrement des Devices LoRa Il faut tout drsquoabord faire lrsquoenregistrement drsquoun Device-profile pour les Devices LoRa que vous
souhaitez connecter Dans notre cas nous ferons un premier test en speacutecifiant que nous utilisons
seulement le mode drsquoauthentification ABP (voir chapitre 431) Devices profile gt Create
Figure 82 Enregistrement dun laquo Device profile raquo
Nous pouvons alors creacuteer dans notre Application des nouveaux Devices Application gt
myApplication gt Create
| 72
Figure 83 Enregistrement dun nouveau Device LoRa
Dans la fenecirctre Activation on va alors configurer les 3 eacuteleacutements indispensables agrave une
authentification en APB Le DevAddr le NwkSKey et lrsquoAppSKey
Figure 84 Configuration de lenregistrement du Device LoRa (en ABP)
La configuration minimale de LoRaServer est maintenant termineacutee Nous pouvons donc brancher
un Device LoRa qui possegravede les les attribus (DevAddr NwkSKey et AppSKey) que nous avons
enregistreacute dans LoRaServer et le faire eacutemettre
715 Visualisation des trames reccedilues Les trames eacutemises par le Device LoRa vont donc parcourir le cheminement suivant
| 73
Figure 85 Reacutesumeacute du cheminement des trames LoRaWan en Uplink avec LoRaServer
En allant dans le Live Device Data (Application gt Nom_du_Device gt Live Device Data) on peut voir la
liste des trames reccedilues ainsi que les donneacutees applicatives deacutechiffreacutees
Figure 86 Reacuteception des trames des Devices LoRa
Figure 87 Analyse des trames des Devices LoRa
Dans lrsquoonglet LIVE LORAWAN FRAME nous pouvons voir les trames LORAWAN et si besoin eacutetudier
le contenu de ce qursquoelles contiennent En revanche les donneacutees applicatives sont ici chiffreacutees
UDP
Packet Forwarder
LoRa Bridge
Gateway LoRa Server LoRa App Server
Gateway
Server
Internet
| 74
Figure 88 Reacuteception des Trames LoRaWAN
72 Configuration de LoRaServer pour linteacutegration dApplication Nous avons vu dans le chapitre 718 que linterface entre LoRaServer et notre Application pouvait
ecirctre reacutealiseacutee soit par MQTT soit par les meacutethodes REST (HTTP POST) Nous avons deacutejagrave impleacutementeacute
et expliqueacute ces protocoles dans le cadre de son utilisation avec TTN Nous allons donc juste
configurer LoRaServer pour tester ces deux meacutethodes
721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST Nous utiliserons exactement la mecircme meacutethode que celle que nous avons utiliseacute avec TTN au
chapitre 615 Les diffeacuterentes Clients et Serveurs disponibles pour ces tests sont expliqueacutes au
paragraphe 612
Dans LoRaServer ajouter une inteacutegration HTTP LoRaServer gt Applications gt myApplication gt
Integrations gt Create gt HTTP Integration et la configurer comme le montre la Figure 89 Vous
remplacerez eacutevidement le lien par votre propre Endpoints
Figure 89 Configuration de linteacutegration HTTP POST dans LoRaServer
En envoyant des trames LoRa depuis votre Device vous devriez voir les contenus JSON sur votre
Endpoint
722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT Nous allons nous connecter au Broker MQTT de LoRaServer Pour cela nous utiliserons la mecircme
meacutethode que celle que nous avons utiliseacute avec TTN au chapitre 628 Nous utiliserons MQTTBox
comme nous lavons deacutejagrave fait au paragraphe 627
Le Broker de LoRaServer a enregistreacute les Topics suivant
[applicationID] correspond au nom de votre Application
[devEUI] correspond au nom de votre Device LoRa
| 75
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink application[applicationID]device[devEUI]rx
[Donneacutees] Flux Downlink application[applicationID]device[devEUI]tx
[Status] Statut dun Device application[applicationID]device[devEUI]status
[Ack] Acquittement des messages application[applicationID]device[devEUI]ack
[Erreurs] Erreurs application[applicationID]device[devEUI]error
Tableau 13 Topics enregistreacutes dans LoRaServer
| 76
8 Creacuteation de notre propre Application
81 Utilisation de Node-RED
811 Preacutesentation Node-RED est un outil de programmation graphique qui permet de faire communiquer les
peacuteripheacuteriques mateacuteriels drsquoun systegraveme sans eacutecrire de code De nombreux protocoles sont aussi pris
en charge au travers de bloc ( Node) qursquoil suffit de connecter entre eux pour reacutealiser simplement
une application Il peut srsquoexeacutecuter localement sur un PC ou sur des cibles embarqueacutees telle qursquoune
Raspberry PI (RPI)
Dans les deacutemonstrations que nous mettrons en œuvre nous utiliserons une RPI Par soucis de
simpliciteacute nous utiliserons les derniegraveres versions de Raspbian (systegraveme drsquoexploitation de la RPI) qui
integravegre drsquoorigine Node-RED Il nrsquoy a donc tregraves peu de chose agrave mettre en place pour arriver agrave mettre
en place une Application Nous pouvons travailler soit directement sur la RPI agrave lrsquoaide drsquoune souris-
clavier mais il est recommandeacute de travailler agrave distance avec une connexion SSH
812 Mise en place de lrsquoenvironnement La mise en place de la RPI avec le systegraveme drsquoexploitation Raspbian a eacuteteacute preacutesenteacute au chapitre 721
Vous pouvez reprendre la mecircme installation ou repartir sur une nouvelle
Il est possible de faire en sorte que Node-RED se lance directement au deacutemarrage gracircce agrave la
commande sudo systemctl enable noderedservice
Sil nest pas actif lancer Node-RED sur votre RPI node-red-start
Nous nous connectons au Node-RED de la RPI via un navigateur web sur le port 1880 en tapant dans
la barre dURL httpIP_Raspeberry_PI1880 Ce nous permet darriver agrave la fenecirctre suivante
Figure 90 Page daccueil de Node-RED
Il est possible de sinterfacer avec TTN avec les Nodes deacutejagrave disponibles gracircce au protocole HTTP
POST ou MQTT Neacuteanmoins nous pouvons avantageusement installer deux librairies speacutecifiques
Une qui facilite linterfaccedilage avec TTN
Une qui facilite la mise en place dinterface graphique
Installation des Nodes TTN
cd $HOMEnode-red
npm install node-red-contrib-ttn
Installation de Dashboard (interface graphique)
| 77
cd $HOMEnode-red
npm install node-red-dashboard
Il peut ecirctre necessaire de redeacutemarrer Node-RED pour prendre en compte linstallation de nos deux
Nodes
-----------------------------------
sudo apt-get install npm
sudo npm install -g npm
hash -r
cd ~node-red
npm install node-red-example node name
------------------------------------
813 Creacuteer une Application speacutecifique pour TTN Nous allons commencer par geacuterer le flux Uplink Apporter sur votre scheacutema un Node ttn uplink et
un Node Debug puis relier les Le Node ttn uplink nous permettra de configurer la
communication avec TTN en MQTT Le Node debug eacutecrira sur le terminal les informations brutes
qui seront reccedilu par le Node ttn uplink
Figure 91 Visualisation des trame publieacutees par TTN sur notre client MQTT
Double cliquer sur le Node ttn uplink pour le configurer comme la figure suivante
Le champ Name sera le nom du Node sur votre scheacutema Le champ Device ID est le device LoRa
concerneacute dans votre application De plus il faut entrer les caracteacuteristiques de votre application (Add
new ttn app) pour que Node-RED puisse sy connecter
Figure 92 Configuration du node ttn uplink
Configuration de votre nouvelle application
| 78
Figure 93 Identifiant et mot de passe de notre application
AppID Nom de votre application Dans notre cas seminaire_lorawan
Access Key Comme nous lavons deacutejagrave expliqueacute plus tocirct l Access Key vous sera donneacutee
par lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application
vous trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt
Overview
Le Node ttn uplink doit maintenant avoir le nom que vous avez configureacute Cliquer sur Deploy pour
lancer votre projet Le bloc ttn uplink doit maintenant ecirctre connecteacute agrave TTN Cela est speacutecifieacute
connected sous le bloc
Figure 94 Utilisation du Node TTN Uplink
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
Figure 95 Simulation de Uplink dans TTN
Vous devriez voir le reacutesultat dans la fenecirctre de Debug Par exemple pour le test denvoi de 31 32
correspondant au code ASCII des chiffres 1 et 2 vous devriez avoir la fenecirctre de Debug suivante
| 79
Figure 96 Reacutesultats obtenu dans la fenecirctre Debug apregraves la simulation dUplink
814 Creacuteation drsquoun Dashboard
Dans la mise en place de lenvironnement (chapitre 812) nous avons installeacute des Nodes
Dashboard qui vont nous permettre de reacutealiser une interface graphique tregraves simple et de la mettre
agrave disposition des utilisateurs via un des graphiques histogramme gauges afficheurshellip
Figure 97 Impleacutementation dune interface graphique dans Node RED
Linterface graphique que nous allons creacuteer sera constitueacutee donglet (tab) La mise en place des
composant se fait de la faccedilon suivante
Chaque eacuteleacutement graphique doit appartenir agrave un groupe de composant quil va falloir creacuteer
Chaque groupe de composant doit appartenir agrave un onglet (tab) quil va falloir creacuteer
Figure 98 Creacuteation dun groupe de composant
Figure 99 Creacuteation dun nouvel onglet dans le site web
Cliquer sur Deploy pour activer votre application
LURL pour joindre linterface graphique de votre site web est disponible sur ladresse
httpIP_Raspeberry_PI1880ui
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
| 80
Figure 100 Interface graphique du site web avec Node-RED
82 Programmation en PHP Maintenant que nous avons testeacute toute lrsquoarchitecture nous pouvons mettre en place une
application qui jouera deux rocircles
Un rocircle de Serveur HTTP POST reacutecupeacuterant les donneacutees en provenance de TTN
Un rocircle de Client HTTP POST qui geacuteneacuterera les requecirctes vers TTN
Un serveur web apache sur RPI heacuteberge cette application Linterface graphique du site web est
reacutealiseacute avec le template CSS proposeacute par Bootstrap [ httpsgetbootstrapcom ]
Figure 101 Architecture de notre application en PHP sur RPI
The Things Network
Notre Application
[ Serveur Apache sur Raspberry Pi ]
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 81
Nous allons lrsquoutiliser telle quelle Elle est juste proposeacutee agrave titre dexemple Lrsquoobjectif de cette
application est de geacuteneacuterer une ouverture fermeture de ruche agrave distance dans le cadre de projets
eacutetudiants du Master Electronique et Systegravemes Embarqueacutes de lUSMB [ httpscem-esetuniv-
smbfr ]
Figure 102 Application permettant de recevoir et deacutemettre des requecirctes HTTP POST
Configurer TTN pour pointer vers votre nouveau serveur et tester le flux montant et
descendant
| 82
9 Versions du document
Version 10 02022019
Version initiale
Version 20 23022019
Ajout drsquoun paragraphe Les systegravemes embarqueacutes dans lrsquoIoT En introduction
Compleacutement et ameacutelioration Ameacutelioration exercice eacutetalement de spectre
Correction Cacircblage Arduino
Ajout drsquoun paragraphe Fonctionnement de lrsquoArduino et ajout de librairies
Compleacutement et ameacutelioration Couche physique LoRa Ajout de 4 figures pour lrsquoexplication
de la modulation Chirp
Ajout drsquoun paragraphe sur les acronymes utiliseacutes au deacutebut du cours TTN LoRa MQTThellip
Compleacutement drsquoinformations sur les dB et dBm
Ajout LoRa Calculator
Version 30 8032019
Ajout de figure sur le rocircle de la Gateway LoRa
Ajout de paragraphe authentification avec le Network Server
Ajout de paragraphe sur le chiffrement avec lrsquoApplication Server
Ajout drsquoun sommaire en deacutebut de cours
Ajout de 2 scheacutemas ABP et OTAA
Retrait explication du deacutetail de la laquo Join Request raquo en OTAA Trop complexe attente de
reacutealisation drsquoun scheacutema plus explicite
Ajout drsquoun scheacutema sur lrsquoattaque par REPLAY
Ajout de paragraphe des diffeacuterents reacuteseaux LoRaWAN existants Opeacutereacutes et Priveacutes
Ajout des scheacutemas des trames LoRaWAN Physique LoRa MAC Application
Compleacutement drsquoinformation sur les Classes de Devices
Ajout drsquoun paragraphe sur la Gateway utiliseacutee pour le Downlink
Ajout drsquoun paragraphe sur le JSON
Compleacutement drsquoinformation sur le codage en Base64
Ajout drsquoinformation dans le deacutecodage des trames LoRaWAN
Restructuration des explications sur lrsquoenvoi et la reacutecupeacuteration des donneacutees en HTTPMQTT
Version 40 8032019
Ajout drsquoun chapitre Creacuteation de notre propre Application
Ajout drsquoun chapitre Creacuteation de notre propre Network et Application Server
Ajout drsquoune figure Visualisation des Chirps LoRa par SDR (Radio Logicielle)
Compleacutements drsquoinformation sur MQTT
Compleacutements dinformation sur les Topics de TTN en MQTT
| 17
Figure 11 Influence du Coding Rate sur le nombre de bits ajouteacute
Si on reprend lrsquoexemple preacuteceacutedent avec un CR de 4 5 nous avons une augmentation de 125 du
nombre de bits agrave transmettre Redonner la deacutebit en prenant en compte le CR
Cas 1 Pour SF7 et 125 kHz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
La documentation du composant RN2483 donne les deacutebits en fonction du Spreading Factor
la Bande Passante et le Coding Rate Veacuterifier la coheacuterence du reacutesultat avec votre calcul
preacuteceacutedent
Figure 12 Deacutebit en fonction des paramegravetres de la transmission LoRa
33 Utilisation du LoRa Calculator Le logiciel laquo LoRa Calculator raquo est un petit exeacutecutable permettant de simuler une transmission LoRa
en fonction des caracteacuteristiques saisies Canal SF CR etchellip Il est teacuteleacutechargeable agrave lrsquoadresse
suivante httpsbitly2TyloAh
| 18
Figure 13 Le logiciel LoRa Calculator
En reprenant lrsquoexemple preacuteceacutedent (SF7 Bande Passante 125 kHz CR 45) veacuterifier les
calculs du laquo Equivalent Bitrate raquo
34 Time On Air La norme LoRaWAN impose qursquoun Device LoRa ne transmette pas plus de 1 du temps Cela est
repreacutesenteacute par un Duty Cycle Par exemple un Duty Cycle de 1 signifie que si jrsquoeacutemet pendant 1 je
ne dois plus eacutemettre pendant 99 quel que soit lrsquouniteacute de temps utiliseacutee
En reprenant les exemples preacuteceacutedents quels sont les deacutebits moyens si on prend en compte
le laquo Time On Air raquo
Cas 1 Pour SF7 et 125 khz gt Deacutebit =
Cas 2 Pour SF12 et 125 kHz gt Deacutebit =
Dans le logiciel laquo LoRa Calculator raquo (onglet laquo Energy Profile raquo) nous pouvons estimer la
dureacutee de vie drsquoune batterie Nous prenons lrsquoexemple drsquoun releveacute de tempeacuterature dans un
bacirctiment avec les caracteacuteristiques suivantes
| 19
SF CR Bande Passante etc Nous nous placcedilons dans le cas 1 des exemples preacuteceacutedents
Le releveacute de tempeacuterature se fera toutes les 15 mins
La batterie est constitueacute de 3 petites piles bacirctons [ AAA LR03 ] 12V en seacuterie Soit 36 V
1000 mAh
35 Mise en œuvre LoRa en point agrave point Ce test sera reacutealiseacute avec des modules LoRa RN2483 (Microchip) et une carte microcontrocircleur
ARDUINO
Figure 14 Communication LoRa en Point agrave Point
Reacutealiser le cacircblage de votre module RN2483 suivant le tableau suivant
Connecteur Arduino Click Board RN2483
5V 5V
GND GND
11 RX
10 TX
Tableau 4 Cacircblage de lrsquoARDUINO et de la click Board RN2483
351 Utilisation de lrsquoIDE Arduino Lrsquoenvironnement Arduino est tregraves simple Nous allons reacutealiser un programme pour montrer son
fonctionnement
La connexion de la carte est effectueacutee agrave lrsquoaide drsquoun port USB qui eacutemule une liaison seacuterie
RS232 Il faut donc choisir le bon port Arduino IDE gt Outils gt Port
Pour creacuteer un nouveau programme (sketch) Arduino IDE gt Fichier gt Nouveau
Il y a deux parties dans un sketch
Une fonction setup() qui sera exeacutecuteacutee qursquoune seule fois au deacutemarrage
Une fonction loop() qui sera exeacutecuteacutee en boucle
Ecrire le code suivant
Emetteur
Reacutecepteur
UA
RT
UA
RT
| 20
void setup()
Serialbegin(9600)
void loop()
Serialprintln(hello word)
Compiler et Teacuteleacuteverser Croquis gt Teacuteleacuteverser
Voir la sortie sur la liaison seacuterie Outils gt Moniteur Seacuterie gt Choisir la vitesse de
transmission ici 9600 bauds (en bas agrave droite)
352 Validation du fonctionnement Deux binocircmes joueront le rocircle drsquoeacutemetteur tous les autres binocircmes seront en reacutecepteur
Reacutecupeacuterer les programmes dans Moodle dans le dossier laquo RN2483-Arduino-Point2Point raquo
Installer la librairie RN2483 Arduino IDE gt Croquis gt Inclure une bibliothegraveque gt Ajouter la
bibliothegraveque zip
Reacutepartissez les rocircles Emetteurs Reacutecepteurs et reacutecupeacuterer le programme LoraBlinkerRX ou
LoraBlinkerTX en fonction Les 2 binocircmes en eacutemission devront modifier le code du sketch
Arduino pour transmettre des donneacutees speacutecifiques afin de les diffeacuterencier [
loraSerialprintln(radio tx 30) ]
Validez la reacuteception des donneacutees eacutemises par les deux binocircmes qui transmettent des
donneacutees Ces donneacutees reccedilues sont eacutecrite agrave 57600 bauds sur le moniteur seacuterie de lrsquoArduino
353 Mise en valeur du Spreading Factor On srsquoaperccediloit dans la manipulation preacuteceacutedente que les Devices LoRa reccediloivent les donneacutees des deux
eacutemetteurs Nous allons conserver le mecircme canal drsquoeacutemission (8691 Mhz) mais un des deux
eacutemetteurs va modifier son laquo Spreading Factor raquo La salle sera donc seacutepareacutee en deux groupes
1er groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF7
2egraveme groupe Un eacutemetteur et au minimum un reacutecepteur utiliseront un SF8
Validez la reacuteception des donneacutees eacutemises seulement pour le Spreading Factor que vous
utilisez
| 21
4 Le protocole LoRaWAN
Le LoRa est le type de modulation utiliseacute entre deux Devices ou entre un Device et une Gateway
Lorsque nous parlons de lrsquoensemble de la chaine de communication (Device Gateway Serveur) alors
nous parlons de communication LoRaWAN Nous allons voir lrsquoarchitecture drsquoun reacuteseau LoRaWAN
ainsi que les regravegles de ce protocole
41 Structure drsquoun reacuteseau LoRaWAN Nous retrouvons drsquoun cocircteacute le Device LoRa qui transmet une donneacutee Elle est reacuteceptionneacutee agrave lrsquoautre
extreacutemiteacute du reacuteseau par un Utilisateur La structure globale du reacuteseau LoRaWAN peut ecirctre
repreacutesenteacutee par la figure suivante
411 Les Devices LoRa Les Devices LoRa sont des systegravemes eacutelectroniques appartenant au monde de lrsquoIoT Faible
consommation faible taille faible puissance et faible taille
Ils possegravedent une radio LoRa permettant de joindre les Gateways Les Gateways ne sont pas
adresseacutees speacutecifiquement toutes celles preacutesentes dans la zone de couverture reccediloivent les
messages et les traitent
412 Les Gateways LoRa Elles eacutecoutent sur tous les canaux et sur tous les Spreading Factor Lorsqursquoune trame LoRa est reccedilue
elle transmet son contenu sur internet agrave destination du Network Server qui a eacuteteacute configureacute dans la
Gateway au preacutealable
Elle joue donc le rocircle de passerelle entre une modulation LoRa et une communication IP
Devices
LoRa Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
Internet Internet
Figure 15 Structure globale dun reacuteseau LORAWAN
| 22
Chaque Gateway LoRa possegravede un identifiant unique (EUI sur 64 bits)
413 Le Network Server
Le Network Server reccediloit les messages transmis par les Gateways et supprime les doublons
(plusieurs Gateway peuvent avoir reccedilu le mecircme message) Les informations transmises au Network
Server depuis les Devices LoRa sont authentifieacutes gracircce agrave une cleacute AES 128 bits appeleacutee Network
Session Key NwkSKey Nous parlons bien ici drsquoauthentification et non pas de chiffrement comme
nous le verrons plus tard
414 Application Server Il est souvent sur le mecircme support physique que le Network Server Il permet de dissocier les
applications les unes des autres Chaque application enregistre des Devices LoRa qui auront le droit
Devices Gateways Network
Server
Internet
Network Session Key (NwkSKey)
Authentification
Figure 17 Authentification entre le Device LoRa et le Network Server
Internet
UDP IP
Modulation
LoRa
Device LoRa
Gateway
Network Server
LoRaWAN
Modulation
LoRa
Passerelle LoRa Internet
Internet
UDP IP
LoRaWAN
Transmission Radio
Application Application
Figure 16 Le rocircle de la Gateway LoRa
| 23
de stocker leurs donneacutees (Frame Payload) Les message transmis agrave lrsquoapplication server sont chiffreacutes
gracircce agrave une cleacute AES 128 bits appeleacutee Application Session Key AppSKey
Le scheacutema suivant reacutesume lrsquoutilisation
De la Network Session Key (NwkSKey) pour lrsquoauthentification entre le Device LoRa et le
Network Server
De lrsquoApplication Session Key (AppSKey) pour le chiffrement entre le Device LoRa et
lrsquoApplication Server
Devices Gateways Network
Server Application
Server
Internet
Application Session Key (AppSKey)
Chiffrement
Figure 18 Chiffrement entre le Device LORA et lrsquoApplication Server
| 24
415 Application Web Serveur Cette application doit drsquoune part reacutecupeacuterer les donneacutees de lrsquoApplication Serveur Dans le cadre de
ce cours cela sera fait de deux faccedilons
Avec le protocole HTTP
Avec le protocole MQTT
Figure 20 Application Web Server
Figure 19 Authentification et chiffrement en LoRaWan
Devices Gateways
Network
Server Application
Server
Internet
Network Session Key
Application Session Key
Network
Server Application
Server
Application
Server Web
Utilisateur
Protocole
MQTT ou HTTP
Flux Uplink
Flux Downlink
| 25
Le flux habituel dans lrsquoIoT est le flux Uplink (flux montant) crsquoest-agrave-dire lrsquoeacutemission de donneacutees des
objets vers le serveur Comme nous lrsquoexpliquerons plus loin en LoRaWAN il est aussi possible de
transfeacuterer des donneacutees aux Device LoRa par un flux Downlink (flux descendant)
Drsquoautre part lrsquoapplication mettra agrave disposition les donneacutees aux utilisateurs sous forme par exemple
drsquoun serveur web drsquoune base de donneacutees et drsquoune visualisation graphique
416 Authentification avec le Network Server La Network Session Key (NwkSKey) sert agrave lrsquoauthentification entre le Device LoRa e le Network Server
Afin de reacutealiser cette authentification entre le Device et le Network Server un champ MIC (Message
Integrity Control) est rajouteacute agrave la trame Il est calculeacute en fonction des donneacutees transmises et du
NwkSkey A la reacuteception le mecircme calcul est effectueacute Si les cleacutes sont eacutequivalentes dans le Device et
dans le Network Server alors les deux MIC calculeacutes doivent correspondre
417 Chiffrement des donneacutees vers lrsquoApplication Server
LrsquoApplication Session Key (AppSKey) sert pour le chiffrement entre le Device LoRa et lrsquoApplication
Server Les donneacutees chiffreacutees seront alors deacutecodeacutees agrave la reacuteception sur lrsquoApplication Server srsquoil
possegravede la mecircme cleacute Si on reprend le scheacutema preacuteceacutedent les laquo donneacutees x raquo sont chiffreacutees
deacutechiffreacutees par le processus suivant
Donneacutees x chiffreacutees NwkSkey x
MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees MIC geacuteneacutereacute Emission Donneacutees x chiffreacutees
NwkSkey x
Trame eacutemise Trame reccedilue
Device LoRa Network Server
Si =
Alors la trame est authentifieacutee
MIC geacuteneacutereacute Emission MIC geacuteneacutereacute Reacuteception
MIC geacuteneacutereacute Reacuteception
Figure 21 Authentification dun Device LoRa par le Network Server
| 26
Figure 22 Chiffrement des donneacutees par lApplication Session Key
418 Combinaison de lrsquoauthentification et du chiffrement On peut maintenant repreacutesenter sur le mecircme scheacutema la construction de la trame LoRaWAN avec
drsquoune part lrsquoauthentification et drsquoautre part le chiffrement
Figure 23 Chiffrement puis Authentification
42 Classes des Devices LoRaWAN Les Devices LoRa sont classeacutes en 3 cateacutegories (A B C) en fonction de leur consommation et de leur
accessibiliteacute en Downlink crsquoest-agrave-dire la faciliteacute qursquoun utilisateur aura agrave transmettre une trame au
Device LoRa
421 Classe A (All) Minimal power Application Tous les Devices LoRaWAN sont de classe A Chaque Device peut transmettre (Uplink) agrave la Gateway
sans veacuterification de la disponibiliteacute du reacutecepteur Si la transmission eacutechoue elle sera reacuteeacutemise apregraves
un certain temps Cette transmission est suivie de 2 fenecirctres de reacuteception tregraves courtes La Gateway
peut alors transmettre pendant le laquo RX Slot 1 raquo ou le laquo RX Slot 2 raquo mais pas les deux
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Device LoRa
Donneacutees x non chiffreacutees
AppSKey
Donneacutees x chiffreacutees
Application Server
Donneacutees non chiffreacutees
AppSKey
Donneacutees chiffreacutees Entecircte
NwkSKey
MIC geacuteneacutereacute en eacutemission Trame transmise =
| 27
Figure 24 Slots de reacuteception pour un Device LoRa de classe A
Source de lrsquoimage httpszakelijkforumkpncom
La dureacutee des fenecirctres doit ecirctre au minimum la dureacutee de reacuteception drsquoun preacuteambule Un preacuteambule
dure 1225 Tsymbole et deacutepend donc du Data Rate (DR voir paragraphe 445 pour plus drsquoinformation
sur le DR) Lorsque qursquoun preacuteambule est deacutetecteacute le reacutecepteur doit rester actif jusqursquoagrave la fin de la
transmission Si la trame reccedilue pendant la premiegravere fenecirctre de reacuteception eacutetait bien agrave destination du
Device LoRa alors la deuxiegraveme fenecirctre nrsquoest pas ouverte
Premiegravere fenecirctre de reacuteception
Le Slot RX1 est programmeacute par deacutefaut agrave 1 seconde + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont les mecircme que ceux choisis lors de la phase drsquoeacutemission
(Uplink)
Seconde fenecirctre de reacuteception
Le Slot RX2 est programmeacute par deacutefaut agrave 2 secondes + 20 micros apregraves la fin de lrsquoeacutemission Uplink
La freacutequence et le Data Rate (DR) sont configurables mais fixes
Un Device LoRa qui est uniquement de classe A ne peut pas recevoir srsquoil nrsquoa pas eacutemis Il
nrsquoest donc pas joignable facilement
422 Classe B (Beacon) Scheduled Receive Slot Les Devices de classe B ont le mecircme comportement que les Devices de classe A mais drsquoautres
fenecirctres de reacuteceptions sont programmeacutees agrave des peacuteriodes preacutecises Afin de synchroniser les fenecirctres
de reacuteception du Device LoRa la Gateway doit transmettre des balises (Beacons) de faccedilon reacuteguliegravere
| 28
Figure 25 Slots de reacuteception pour un Device LoRa de classe B
Source de lrsquoimage httpszakelijkforumkpncom
Un Device LoRa de classe B est joignable reacuteguliegraverement sans qursquoil soit neacutecessairement
obligeacute drsquoeacutemettre En revanche il consomme plus qursquoun Device de classe A
423 Classe C (Continuous) Continuously Listening Les Devices de classe C ont des fenecirctres de reacuteception constamment ouvertes entre 2 Uplinks Ces
Devices consomment donc beaucoup plus
Figure 26 Slots de reacuteception pour un Device LoRa de classe C
Source de lrsquoimage httpszakelijkforumkpncom
| 29
Un Device LoRa de classe C est joignable en permanence En revanche crsquoest la classe de
Device qui est la plus eacutenergivore
424 Quelle Gateway pour les flux Downlink
Nous avons donc vu que le fonctionnement classique du protocole LoRaWAN eacutetait de reacutecupeacuterer de
lrsquoinformation depuis le Device LoRa Crsquoest le flux Uplink
Dans le cas ougrave lrsquoutilisateur transmet des informations au Device LoRa (flux Downlink) on peut se
demander quelle Gateway sera choisie pour transfeacuterer les donneacutees au Device LoRa En effet
lrsquoendroit ougrave est situeacute le Device LoRa nrsquoest pas neacutecessairement connu agrave lrsquoavance
La Gateway utiliseacutee pour le Downlink est celle qui a reccedilu le dernier message du Device
LoRa Un message ne pourra jamais arriver agrave destination drsquoun Device LoRa si celui-ci nrsquoa
jamais transmis quel que soit sa classe A B ou C
43 Activation des Devices LoRa et seacutecuriteacute En LoRaWAN les trois eacuteleacutements indispensables pour la communication sont le DevAddr pour
lrsquoindentification du Device ainsi que deux cleacutes le NwkSKey pour lrsquoauthentification et lrsquoAppSKey
pour le chiffrement Deux meacutethodes sont possibles pour fournir ces informations agrave la fois au Device
LoRa et au serveur
Activation By Personalization APB
Over The Air Activation
431 ABP Activation By Personalization Crsquoest la plus simple des meacutethodes Crsquoest donc peut ecirctre celle que nous avons tendance agrave utiliser lors
drsquoun test de prototype et drsquoune mise en place de communication LoRaWAN
Le Device LoRa possegravede deacutejagrave le DevAddr lrsquoAppSKey et le NwkSKey
Le Network server possegravede deacutejagrave le DevAddr et le NwkSKey
Lrsquoapplication serveur possegravede deacutejagrave le DevAddr et le AppSKey
En ABP toutes les informations neacutecessaires agrave la communication sont deacutejagrave connues par le
Device LoRa et par le Serveur
| 30
432 OTAA Over The Air Activation Crsquoest la meacutethode qursquoil faut privileacutegier car crsquoest celle qui est la plus seacutecuriseacutee Le Device LoRa doit
connaitre le DevEUI lrsquoAppEUI et lrsquoAppkey Le Network Server doit lui connaitre la mecircme Appkey
Tous les eacuteleacutements noteacutes EUI (Extended Unique Identifier) sont toujours sur une taille de
64 bits
Gracircce agrave ces informations de deacutepart et une neacutegociation avec le Network Server (Join Request) le
Device LoRa et le serveur vont geacuteneacuterer les informations essentielles DevAddr NwkSKey et
AppSKey
Figure 28 Obtention du DevAddr NwkSKey et AppSKey en OTAA
DevEUI Unique Identifier pour le device LoRa (Equivalent agrave une MAC sur Ethernet)
Certains Device LoRa ont deacutejagrave un DevEUI fourni en usine
AppEUI Unique Identifier pour lrsquoapplication server
DevEUI
AppEUI
AppKey
Join
Request
DevAddr
NwkSKey
AppSKey
Network Server
Application Server
Devices 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 1
NwkSkey 1
AppSKey 1
DevAddr 2
NwkSkey 2
AppSKey 2
Devices 2
DevAddr 2
NwkSkey 2
AppSKey 2
Paramegravetres stockeacutes sur le serveur
Paramegravetres programmeacutes
dans le composant
Figure 27 Parameacutetrage de DevAddr NwkSKey et AppSKey
| 31
AppKey AES 128 cleacute utiliseacutee pour geacuteneacuterer le MIC (Message Code Integrity) lors de la Join
Resquest Il est partageacute avec le Network server
NwkSKey Utiliseacute pour lrsquoauthentification avec le Network Server
AppSKey Utiliseacute pour le chiffrement des donneacutees
433 Seacutecuriteacute Les cleacutes AES 128 bits permettent le chiffrement des informations transmises en LoRaWAN Malgreacute
ce chiffrement une attaque connue en Wireless est celle du REPLAY Crsquoest-agrave-dire que le Hacker
enregistre des trames chiffreacutees circulant sur le reacuteseau LoRa pour les reacuteeacutemettre plus tard Mecircme si
le Hacker ne comprend pas le contenu (les trames sont chiffreacutees) les donneacutees qui sont transporteacutees
sont elles bien comprises par lrsquoApplication Server Des actions peuvent donc ecirctre reacutealiseacutees
simplement par mimeacutetisme
Pour eacuteviter cela la trame LoRaWAN integravegre un champ variable appeleacute laquo Frame Counter raquo Il srsquoagit
drsquoun nombre numeacuterotant la trame sur 16 ou 32 bits LrsquoApplication Server acceptera une trame
uniquement si le laquo Frame Counter raquo reccedilu est supeacuterieur au laquoFrame Counter raquo preacuteceacutedemment Donc
si le Hacker retransmet la trame telle qursquoelle le laquo Frame Counter raquo sera eacutequivalent donc la trame
sera refuseacutee Et comme la trame est chiffreacutee le Hacker nrsquoa pas moyen de savoir comment modifier
un champ de cette trame
Cette seacutecuriteacute impleacutementeacutee par les laquo Frame Counter raquo est inteacuteressante pour srsquoaffranchir drsquoune
attaque par REPLAY mais dans nos tests cela peut poser problegraveme En effet agrave chaque fois que nous
redeacutemarrons le microcontrocircleur notre laquo Frame Counter raquo revient agrave zeacutero alors que celui de
lrsquoApplication Server continue de srsquoincreacutementer Cela peut ecirctre reacutesolue par diffeacuterentes maniegraveres
1 Deacutesactivation du laquo Frame Counter Check raquo Dans certain Application Server cette option
peut ecirctre proposeacutee Bien sucircr il faudra garder en tecircte la faille de seacutecuriteacute que cela engendre
Network Server
Application Server
Devices LoRa
NwkSkey
AppSKey
NwkSkey
AppSKey Hacker
(1) (2)
(1) Ecoute
(2) Reacuteeacutemission
Figure 29 Attaque par REPLAY
| 32
Figure 30 Deacutesactivation du Frame Counter Check dans TTN
2 Utiliser lrsquoauthentification par OTAA au lieu de ABP En effet agrave chaque ouverture de session
en OTAA le laquo Frame Counter raquo est reacuteinitialiseacute coteacute serveur
3 Conserver la valeur du laquo Frame Counter raquo dans une meacutemoire non volatile et reacutecupeacuterer sa
valeur au deacutemarrage du Device LoRa
44 La Trame LoRa LoRaWAN
441 Les couches du protocole LoRaWAN
Lorsque nous avons fait une communication en Point agrave Point nous avons simplement utiliseacute la
couche physique de la modulation LoRa Lorsque nous souhaitons utiliser le protocole LoRaWAN
des couches protocolaires suppleacutementaires se rajoutent
Figure 31 Les couches protocolaires du LoRaWAN
Chaque couche rajoute un service Lors de lrsquoenvoi de la trame les donneacutees utilisateurs sont donc
encapsuleacutees dans chaque couche infeacuterieure jusqursquoagrave la transmission Le deacutetail de lrsquoensemble de la
trame LoRaWAN par couche est deacutecrit sur la figure Figure 32
LoRa Modulation
LoRa Mac
Application
Couche Physique
Couche Mac
Couche Application
| 33
442 Couche Application La couche Application accueille les donneacutees de lrsquoutilisateur Avant de les encapsuler elles sont
chiffreacutees avec lrsquoAppSKey afin de seacutecuriser la transaction
Un ensemble de champs nommeacute Frame Header permet de speacutecifier le DevAddr le Frame Control
le Frame Counter et le Frame Option
Le Frame Port deacutepend du type drsquoapplication et sera choisi par lrsquoutilisateur
Le Frame Payload sont les donneacutees chiffreacutees agrave transmettre Le nombre drsquooctets maximum pouvant
ecirctre transmis (N octets) est donneacute dans le tableau suivant
PHY Payload
P octets Couche
Physique
Couche
Mac
Couche
Application
CRC
2 octets Header + Header CRC
20 bits Preamble
MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Figure 32 Trame LORAWAN complegravete par couche protocolaire
Couche
Application Frame Port
1 octet Frame Option
0 agrave 15 octets Frame Counter
2 octets Frame Control
1 octet Device Address
4 octets Frame Payload
N octets
Donneacutees utilisateur
N octets
AppSKey
Chiffrement des donneacutees
utilisateur par lrsquoAppSkey
Frame Header
Figure 33 Trame LORA couche Applicative
| 34
Data Rate Spreading Factor Bandwidth Max Frame Payload (Nombre N) DR 0 SF12 125 KHz 51 octets
DR 1 SF11 125 KHz 51 octets
DR 2 SF10 125 KHz 51 octets
DR 3 SF9 125 KHz 115 octets
DR 4 SF8 125 KHz 222 octets
DR 5 SF7 125 KHz 222 octets
DR 6 SF7 250 KHz 222 octets
Tableau 5 Taille maximum du Frame Payload en fonction du Data Rate
443 Couche LoRa MAC Cette trame est destineacutee au Network Server Elle est authentifieacutee gracircce au champ MIC (Message
Integrity Protocol) selon la meacutethode expliqueacutee au paragraphe 416
Le protocole LoRa MAC est composeacute de
1 MAC Header Version de protocole et type de message
Type de Message Description 000 Join-Request
001 Join-Accept
010 Unconfirmed Data Up
011 Unconfirmed Data Down
100 Confirmed Data Up
101 Confirmed Data Down
110 Rejoin-request
111 Proprietary
Tableau 6 Les types de messages transmis en LoRaWAN
2 MAC Payload Contient tout le protocole applicatif
3 MIC Message Integrity Code pour lrsquoauthentification de la trame
444 Couche physique Modulation LoRa
Le choix du moment drsquoeacutemission des Devices LoRa se fait de faccedilon simple Lorsqursquoun eacutequipement
doit eacutemettre il le fait sans controcircle et ne cherche pas agrave savoir si le canal est libre Si le paquet a eacuteteacute
perdu il le retransmettra simplement au bout drsquoun temps aleacuteatoire La couche physique est
repreacutesenteacutee par lrsquoeacutemission de la trame suivante
Couche
Mac MAC Payload
M octets MIC
2 octets MAC Header
1 octet
Figure 34 Trame LORA couche LORA MAC
| 35
Le Preacuteambule est repreacutesenteacute par 8 symboles + 425 Le temps du Preacuteambule est donc de 1225
Tsymbole
Len-tecircte (Header optionnel) est seulement preacutesent dans le mode de transmission par deacutefaut
(explicite) il est transmis avec un Coding Rate de 48 Il indique la taille des donneacutees le Coding Rate
pour le reste de la trame et il preacutecise eacutegalement si un CRC sera preacutesent en fin de trame
Le PHY Payload contient toutes les informations de la Couche LoRa MAC
Le CRC sert agrave la deacutetection drsquoerreur de la trame LoRa
445 Canaux et bandes de freacutequences et Data Rate (DR) Le LoRa utilise des bandes de freacutequences diffeacuterentes suivant les reacutegions du monde En Europe la
bande utiliseacutee est celle des 868 Mhz [ De 863 Mhz agrave 870 Mhz ] Le LoRaWAN deacutefinie les 8 canaux agrave
utiliser pour communiquer avec une Gateway suivant le tableau suivant
Canaux Spreading Factor Bandwidth 8681 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz De SF7 agrave SF12 125 kHz
8683 Mhz SF7 250 kHz
8685 Mhz De SF7 agrave SF12 125 kHz
8671 Mhz De SF7 agrave SF12 125 kHz
8673 Mhz De SF7 agrave SF12 125 kHz
8675 Mhz De SF7 agrave SF12 125 kHz
8677 Mhz De SF7 agrave SF12 125 kHz
8679 Mhz De SF7 agrave SF12 125 kHz
Tableau 7 Canaux SF et Bandwidth de notre Gateway LoRaWAN
Une Gateway LoRa eacutecoute donc sur 8 canaux simultaneacutement avec les 6 Spreading Factor
diffeacuterents soit 48 combinaisons possibles
Comme nous lrsquoavons vu le Spreading Factor a des conseacutequences sur le deacutebit de la transmission Ces
deacutebits sont noteacutes DR (Data Rate) et sont normaliseacutes de DR0 agrave DR6
PHY Payload
P octets Couche
Physique CRC
2 octets Header + Header CRC
( Optionnel ) 20 bits Preamble
Figure 35 Trame LORA couche Physique
| 36
Data Rate Spreading Factor Bandwidth DR 0 SF12 125 KHz
DR 1 SF11 125 KHz
DR 2 SF10 125 KHz
DR 3 SF9 125 KHz
DR 4 SF8 125 KHz
DR 5 SF7 125 KHz
DR 6 SF7 250 KHz
Tableau 8 Deacutenomination DR en fonction du SF et de la Bande Passante
446 Trame reccedilue et transmise par la Gateway LoRaWAN La Gateway reccediloit drsquoun cocircteacute un message radio moduleacute en LoRa et transmet de lrsquoautre cocircteacute une trame
IP agrave destination du Network Server
Coteacute interface Radio La Gateway reacuteceptionne une trame LoRaWAN et extrait le PHY Payload Celui-
ci est codeacute au format ASCII en base 64 (voir le paragraphe 541) La Gateway extrait aussi toutes les
informations utiles sur les caracteacuteristiques de la reacuteception qui a eu lieu SF Bandwidth RSSI Time
On Airhellipetchellip
Coteacute interface reacuteseau IP La Gateway transmet lrsquoensemble de ces informations dans un paquet IP
(UDP) au Network Server Les donneacutees transmises sont du texte en format JSON (voir paragraphe
447) La Gateway a donc bien un rocircle de passerelle entre le protocole LoRa drsquoun cocircteacute et un reacuteseau
IP de lrsquoautre
Internet
UDP IP
Device LoRa
Gateway
Network Server Modulation
LoRa
Passerelle LoRa Internet
Transmission Radio Internet
Figure 36 Rocircle de la Gateway LoRa
| 37
447 Le format JSON Le format JSON est un format texte composeacute drsquoune succession de couple nomvaleur Dans
lrsquoexemple de la figure preacuteceacutedente gw_id est un nom et eui-b827ebfffeae26f5 est la valeur
associeacutee Dans cette exemple la valeur est un string Les objets sont deacutelimiteacutes par un des accolades
et
Une valeur peut ecirctre
Un string exemple coding_rate 45
Un nombre exemple spreading_factor 12
Un objet exemple lora spreading_factor 12 air_time 2465792000
Un Boolean
Ethernet
Gateway
Modulation
LORA
Reacutecupeacuteration du PHY PAYLOAD en base 64
Reacutecupeacuteration des caracteacuteristiques de la transmission Canal SF CR hellip
IP (IP dest routereuthethingsnetwork)
UDP (Port dest 1700 Port source 1700)
Donneacutees applicatives (format JSON)
gw_id eui-b827ebfffeae26f5
payload QNAPvA6Ax3ECqHk4C8hfzuA==
lora
spreading_factor 12
bandwidth 125
air_time 2465792000
coding_rate 45
timestamp 2019-01-20T133746017Z
rssi -105
snr -162
dev_addr 0EBC0FD0
frequency 867100000
Internet Transmission Radio LORA
Figure 37 Passerelle (Gateway) LORAWAN
| 38
5 Mise en œuvre drsquoun reacuteseau LoRaWAN
51 Les diffeacuterents types de reacuteseaux Les reacuteseaux LoRaWAN peuvent ecirctre utiliseacute suivant deux meacutethodes
En utilisant les reacuteseaux LoRaWAN opeacutereacutes proposeacutes par les opeacuterateurs de teacuteleacutecoms
En utilisant votre propre reacuteseau LoRaWAN priveacute
511 Les reacuteseaux LoRaWAN opeacutereacutes Ce sont des reacuteseaux LoRaWAN proposeacutes par les opeacuterateurs Par exemple Objenious (filiale de
Bouyges) ou encore Orange Dans le cas de lrsquoutilisation des reacuteseaux opeacutereacutes lrsquoutilisateur a juste
besoin de srsquooccuper des Devices LoRa Les Gateways le Network Server et lrsquoApplication Server sont
geacutereacutes par lrsquoopeacuterateur
512 Les reacuteseaux LoRaWAN priveacutes Chacun est libre de reacutealiser son propre reacuteseau priveacute en impleacutementant sa propre Gateway pour
communiquer avec ses Devices LoRa Lrsquoimpleacutementation du Network Server et de lrsquoApplication Server
peuvent alors ecirctre envisageacutes de diffeacuterentes faccedilons
Network Server et Application serveur priveacutees Crsquoest le deacuteveloppeur qui les mets en place Dans
certaines Gateways une impleacutementation de ces deux serveurs est deacutejagrave proposeacutee Sinon il est
possible de la mettre en place Il existe des serveurs (Network et Application) open source crsquoest le
cas par exemple de LoRa Serveur [ wwwloraserverio ]
Une autre alternantive est httpsgithubcomgotthardplorawan-server
LoRaServer et lorawan-server sont deux applications Open Source
Network Server et Application Server en ligne Un certain nombre de Network Server et
drsquoApplication Server sont proposeacutes Ce sont des services payants ou avec des contreparties
Loriot [ wwwloriotio ]
ResIoT [ wwwresiotio ]
The Things Network [ wwwthethingsnetworkorg ] Crsquoest la solution que nous utiliserons
513 Les zones de couvertures
Les zones de couvertures des reacuteseaux opeacutereacutes sont mise agrave jour par les opeacuterateurs celle drsquoobjenious
est par exemple disponible ici httpsobjeniouscomreseau
Pour connaitre la zone de couverture de notre Gateway utiliseacutee avec TTN nous pouvons utiliser
lrsquoapplication TTN Mapper httpsttnmapperorg Lrsquoideacutee est de promener son Device LoRa associeacute
agrave un GPS dans la zone de couverture des Gateway qui nous entourent A chaque trame reccedilue par le
| 39
Serveur on note les coordonneacutees GPS du Device LoRa ainsi que la Gateway qui a transmis le
message Toutes ces informations sont alors retranscrites sur une carte
52 The Things Network (TTN)
521 Preacutesentation de TTN
Pour la suite nous utiliserons le Network Server et lrsquoApplication Server fourni par TTN
[wwwthethingsnetworkorg]
TTN est gratuit et Open Source En revanche le fait drsquoutiliser TTN impose agrave ceux qui enregistrent
des Gateways de les mettre agrave disposition agrave tous les autres utilisateurs de TTN Lrsquoobjectif est de
reacutealiser un reacuteseau global ouvert
522 Configuration de la Gateway A lrsquouniversiteacute nous avons deux Gateways LoRa (Marque EBDS) Elles sont toutes les deux situeacutees sur
le Campus de Technolac Une Gateway est agrave lrsquointeacuterieur du bacirctiment ISERAN et sert essentiellement
pour les Travaux Pratiques et formations Lrsquoautre est sur le toit du bacirctiment Chablais et est mise agrave
disposition du public via le service de TTN
Les deux Gateway eacutecoutent sur tous les canaux et sur tous les Spreading Factor SF7 gt SF12
Lrsquo IP de la Gateway LoRa agrave lrsquouniversiteacute (bacirctiment ISERAN) est 192168140196
Serveur DNS 1934812032 19348129137
Network Server (TTN) 137616868 routereuthethingsnetwork
Port Upstream 1700 Port Downstream 1700
523 Enregistrement des Gateways Appplication et Devices La configuration de TTN se fait en ligne La premiegravere opeacuteration agrave reacutealiser lorsqursquoune nouvelle
Gateway est deacuteployeacutee crsquoest de lrsquoenregistrer dans TTN
Enregistrement drsquoune Gateway LoRa TTN gt Console gt Gateway gt register gateway
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Figure 38 Scheacutema de notre application
| 40
Figure 39 Enregistrement dune Gateway LoRa sur TTN
Enregistrement drsquoune application TTN gt Console gt Application gt add application
Figure 40 Enregistrement dune application sur TTN
Enregistrement des Devices LoRa dans lrsquoapplication Nom de lrsquoapplication gt register device
Figure 41 Enregistrement des Devices LoRa dans une application
524 Configuration des Devices LoRa Lorsque nous avons enregistreacute des Devices LoRa dans TTN nous devons choisir entre les deux modes
drsquoauthentification Dans un premier temps nous utiliserons le mode le plus simple qui est ABP Nous
geacuteneacuterons dans TTN les DevAddr NetwkSKey et AppSKey
| 41
Figure 42 Configuration des Devices LoRa en ABP dans TTN
53 Mise en application Nous avons dans notre application 10 Devices LoRa drsquoenregistreacutes aduino0 agrave arduino9 Ils sont tous
configureacutes en ABP Les configurations des 10 Devices (DevAddr NetwkSKey et AppSKey) sont noteacutes
en commentaire dans le code de vous allez reacutecupeacuterer
Reacutecupeacuterer le code Arduino laquo RN2483-Arduino-LORAWANino raquo dans Moodle
Modifier votre configuration (DevAddr NetwkSKey et AppSKey) en fonction de votre
numeacutero de binocircme
Veacuterifier que votre Device LoRa arrive bien agrave transmettre des informations (Uplink) vers la
Gateway puis vers le Network Serveur de TTN (The Things Network)
54 Analyse des trames eacutechangeacutees
541 Utilisation de la base 64 Notre Gateway nous preacutesente le Payload PHY en base64 Lrsquoexplication de la meacutethode de
repreacutesentation en base 64 est fourni au travers drsquoun exemple Le code hexadeacutecimal 0x4869
repreacutesente nos donneacutees binaires que nous souhaitons transmettre en base 64
1 On eacutecrit les donneacutees agrave transmettre en binaire
2 On regroupe les eacuteleacutements binaires par des blocs de 6 bits Le nombre de bloc de 6 bits doit
ecirctre un multiple de 4 (minimum 4 blocs) Srsquoil manque des bits pour constituer un groupe de
6 bits on rajoute des zeacuteros
0x4869 = 0100 1000 0110 1001
| 42
3 Srsquoil manque des blocs pour faire un minimum de 4 blocs des caractegraveres speacuteciaux seront
ajouteacutes
4 Chaque groupe de 6 bits est traduit par le tableau suivant (Source Wikipeacutedia)
Figure 43 Codage en base 64
5 Si un bloc de 6 bits manque (ils doivent ecirctre un multiple de 4) on rajoute un ou plusieurs
compleacutements (caractegravere laquo = raquo )
Reacutesultat Le codage de 0x4869 en base 64 est laquo SGk= raquo
010010 000110 100100
On ajoute 00 pour avoir
6 bits dans le groupe
Bloc de 6 bits
010010 000110 100100
S G k
010010 000110 100100
S G k =
1er Bloc
2egraveme Bloc
3egraveme Bloc
4egraveme Bloc
| 43
542 Inteacuterecirct et inconveacutenient de la base 64 Lrsquoutilisation de la base 64 est un choix qui a eacuteteacute fait pour le protocole LoRa LoRaWAN afin de rendre
les donneacutees binaires lisibles Le problegraveme du code ASCII crsquoest qursquoil est composeacute drsquoun certain nombre
de caractegraveres non imprimables (EOF CR LFhellip) Pour eacuteviter ces soucis la base 64 ne comporte que
64 caractegraveres imprimables (voir tableau ci-dessus)
La restriction agrave 64 caractegraveres a cependant un inconveacutenient crsquoest que nous ne pouvons coder que 6
bits (26=64) au lieu de 8 La base 64 est donc moins efficace drsquoune faccedilon geacuteneacuterale
Nous cherchons agrave coder le code ASCII laquo AA raquo en base 64 Retrouver la deacutemarche en
montrant que le reacutesultat en base 64 est laquo QUE= raquo
543 Uplink Du Device LoRa au Network Server Le Network Server de TTN reccediloit des trames IP en provenance de la Gateway Comme nous lrsquoavons
vu preacuteceacutedemment un certain nombre drsquoinformations peuvent ecirctre retrouveacutees avec cette trame
(DevAddr SF Bandwidth etchellip) mais les donneacutees Applicatives sont bien sucircr chiffreacutees (avec
lrsquoAppkSKey) A ce niveau de reacuteception (sans connaitre lrsquoAppSKey) il nrsquoest donc pas possible de
comprendre la totaliteacute du message reccedilu
Imaginons que la trame IP reccedilue 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 45
timestamp 2019-03-05T140042448Z
rssi -82
snr 9
dev_addr 26011AD3
frequency 867300000
Le Network Server affiche donc les informations de la faccedilon suivante
Figure 44 Trame reacutecupeacutereacutee sur le laquo Network Server raquo de TTN
Nous retrouvons bien les valeurs fournies par la Gateway
timestamp ( agrave 1 heure pregraves en fonction du fuseau horaire)
| 44
frequency 8673 Mhz
modulation Lora
Coding Rate 45
data Rate SF 7 125 kHz (DR5)
air time 463 ms
Drsquoautres information proviennent de lrsquoanalyse du Payload Le Payload inscrit ici est le PHY Payload
Il y a donc une partie chiffreacutee (Frame Payload) mais les entecirctes sont en claires (voir paragraphe
441) Ce PHY Payload est laquo QNMaASYABwAP1obuUHQ= raquo Lorsque celui-ci est exprimeacute en
hexadeacutecimal au lieu de la base 64 il vaut laquo 40D31A01260007000FD686EE5074 raquo comme le montre
le Network Server de TTN
Figure 45 PHY Payload preacutesenteacute dans notre Network Server
Sa taille est bien de 14 octets (en hexadeacutecimal) comme preacuteciseacute sur la Figure 44
Nous reprenons le format de la trame LoRaWAN vu agrave la Figure 32 Nous pouvons alors retrouver
tous les champs de toute la trame
PHYPayload = 40D31A01260007000FD686EE5074
PHYPayload = MAC Header[1 octet] | MACPayload[] | MIC[4 octets]
MAC Header = 40 (Unconfirmed data up)
MACPayload = D31A01260007000FD6
Message Integrity Code = 86EE5074
MACPayload = Frame Header | Frame Port | FramePayload )
Frame Header = D31A0126000700
FPort = 0F
FramePayload = D6
Frame Header = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[015]
DevAddr = 26011AD3 (Big Endian)
FCtrl (Frame Control) = 00 (No ACK No ADR)
FCnt (Frame Counter) = 0007 (Big Endian)
FOpts (Frame Option) =
Vous pouvez veacuterifier lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN
(LoRaWAN packet decoder) httpsbitly2szdXtv
| 45
Figure 46 LoRaWAN packet decoder
544 Uplink Du Network Server agrave lrsquoApplication Server
Nous reprenons lrsquoexemple de la trame ci-dessus (Figure 45) Pour information les cleacutes NwkSKey et
AppSKey suivantes ont eacuteteacute utiliseacutee
NwkSKey E3D90AFBC36AD479552EFEA2CDA937B9
AppSKey F0BC25E9E554B9646F208E1A8E3C7B24
Le Network Server a deacutecodeacute lrsquoensemble de la trame Si le MIC est correct (authentification de la
trame par le NwkSKey) alors le Network Server va passer le contenu du message chiffreacute (Frame
Payload) agrave lrsquoApplication Server Dans notre cas le Frame Payload est (drsquoapregraves le deacutecodage effectueacute
au chapitre preacuteceacutedent)
FramePayload = D6
D6 est le contenu chiffreacute lorsqursquoil est deacutechiffreacute avec lrsquoAppSkey on trouve 01 Vous pouvez veacuterifier
lrsquoensemble de ces informations gracircce au deacutecodeur de trame LoRaWAN httpsbitly2szdXtv
A noter que lrsquoApplication Server recevra les donneacutees chiffreacutees seulement si le Device LoRa a bien
eacuteteacute enregistreacute On peut aussi veacuterifier ci-dessous que lrsquoApplication Serveur de TTN nous retourne bien
un payload (Frame Payload) de 01
Figure 47 Trame reacutecupeacutereacutee sur lrsquoApplication Server de TTN
time 2019-03-05T140042379279991Z
frequency 8673
modulation LORA
data_rate SF7BW125
coding_rate 45
gateways [
gtw_id eui-b827ebfffeae26f6
timestamp 2447508531
time
channel 4
rssi -82
snr 9
latitude 4563647
longitude 58721523
| 46
location_source registry
]
545 Simulation drsquoUplink dans lrsquoApplication Server
Dans beaucoup de situations nous souhaitons valider le fonctionnement de lrsquoApplication Server de
TTN ouet de notre propre Application Il est donc tregraves utile de pouvoir simuler lrsquoenvoi drsquoune trame
LoRa sur lrsquoApplication Server sans que celle-ci soit reacuteellement eacutemise par un Device LoRa Pour cela
un outil existe dans les Settings de chaque Device enregistreacute dans TTN Nous avons juste besoin de
speacutecifier le Frame Payload en clair en hexadeacutecimal et le numeacutero de Port
Figure 48 Simulation drsquoune trame envoyeacutee par un Device LoRa
546 Downlink De lrsquoApplication Server au Device LoRa La communication LoRa est bidirectionnelle Des donneacutees peuvent ecirctre transmis au Device LoRa
depuis lrsquoApplication Server Depuis TTN un outil existe dans les Settings de chaque Device
enregistreacute Lrsquointerface est repreacutesenteacutee ci-dessous
Figure 49 Transmission de donneacutees de lrsquo laquo Application Server raquo jusqursquoau Device LoRa
Replace scheduling Mode Par deacutefaut le Frame Payload transmis remplacera le Frame
Payload en attente (si il existe) Dans ce mode un seul Frame Payload est planifieacute
First scheduling Mode Le Frame Payload est mis en file drsquoattente en premiegravere position
Last scheduling Mode Le Payload est mis en file drsquoattente en derniegravere position
Une demande de confirmation peut ecirctre demandeacutee au Device LoRa pour qursquoil preacutecise srsquoil a bien reccedilu
les donneacutees Lrsquooption laquo confirmed raquo permet donc de speacutecifier le type de trame dans le MAC Header
(voir paragraphe 443) laquo Confirmed Data Down raquo ou laquo Unconfirmed Data Down raquo dans notre cas
| 47
6 La reacutecupeacuteration des donneacutees sur notre propre Application
Nous utiliserons agrave nouveau le Network Server et Application Server de The Things Network Jusqursquoici
nous nous sommes contenteacute de veacuterifier que les donneacutees de lrsquoutilisateur (Frame Payload) soient bien
arriveacutees agrave destination dans lrsquoApplication Server Il faut maintenant les reacutecupeacuterer avec notre propre
Application qui aura pour rocircle
De stocker et traiter les donneacutees
De les mettre agrave disposition de lrsquoutilisateur (Serveur Web par exemple)
Drsquoenvoyer des commandes de lrsquoutilisateur aux Devices LoRa si besoin (Flux Downlink)
Nous allons voir deux meacutethodes pour communiquer entre notre application et TTN
Le protocole HTTP POST
Le protocole MQTT
61 Reacutecupeacuteration des donneacutees en HTTP POST dans lrsquoApplication
611 Preacutesentation du protocole HTTP
Dans le monde de lrsquointernet le protocole HTTP est tregraves utiliseacute pour le dialogue entre un client et un
serveur web Classiquement le client (un navigateur web par exemple) fait une requecircte HTTP GET
et le serveur lui retourne le contenu de la page web demandeacutee
Dans notre cas la probleacutematique est diffeacuterente car le client doit modifier le contenu du serveur
avec les donneacutees envoyeacutees par le Device LORA La requecircte srsquoappelle HTTP POST Son nom indique
que le client va poster (et on pas reacutecupeacuterer) des donneacutees
Lrsquoutilisateur qui souhaite reacuteceptionner des donneacutees sur son serveur doit donc concevoir un serveur
HTTP capable de traiter des requecirctes HTTP POST [ requecircte noteacutee (1) sur la Figure 51 ] fournies par
TTN Dans cette configuration TTN jouera le rocircle de client et notre application le rocircle de serveur
Devices
LORA Gateways
Network
Server Application
Server
Application
Server Web
Utilisateur
HTTP POST
MQTT Internet
Figure 50 Structure globale drsquoun reacuteseau LORAWAN
| 48
Figure 51 Communication bidirectionnelle entre TTN et notre Application
A lrsquoinverse lrsquoutilisateur qui souhaite transmettre des donneacutees agrave destination du Device LoRa
(Downlink) doit ecirctre capable de fournir une requecircte HTTP POST [ requecircte noteacutee (2) sur la Figure 51
] vers TTN Dans cette configuration TTN jouera le rocircle de Serveur et notre application le rocircle de
client
612 Fonctionnement drsquoun client et drsquoun serveur HTTP POST Afin de bien comprendre le fonctionnement des requecirctes HTTP POST nous allons proceacuteder par
eacutetape Le premier test que nous effectuerons sera decorreacuteleacute de TTN Le principe est le suivant
Utilisation drsquoun serveur HTTP disponible sur le web geacuterant les requecirctes HTTP POST [
httpsrbasketsin ] ou [ httpsbeeceptorcom ] par exemple
Utilisation drsquoun client HTTP eacutemettant des requecirctes HTTP POST commande curl sous linux
ou logiciel Postman [ wwwgetpostmancom ] sous windows par exemple
Ce test nous permet de valider le fonctionnement drsquoun serveur HTTP POST et drsquoun client HTTP POST
Une fois que nous serons sucircr de leur fonctionnement nous les utiliserons avec TTN
The Things Network
Application
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 49
Figure 52 Validation dun server HTTP POST et drsquoun client HTTP POST
613 Test du serveur HTTP POST Nous utiliserons un serveur web proposeacute par httpsrbasketsin
Aller sur le site httpsrbasketsin et creacuteer un nouveau laquo Basket raquo Zone ougrave vous pourrez
visualiser les requecirctes qui ont eacuteteacute eacutemises vers votre serveur
A partir de maintenant toutes les requecirctes dirigeacutees vers lrsquoadresse creacuteeacute seront traiteacutees et
srsquoafficheront Dans le menu de configuration il est aussi possible de deacutefinir le contenu de la reacuteponse
qui sera fournie
Deacutefinir un format de reacuteponse pour les requecirctes HTTP POST avec un body personnaliseacute
614 Test du client HTTP POST On peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande (la commande cURL
srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN sous Windows
Commande cURL curl ndashX POST ndashd lsquorsquodonneacutees agrave envoyerrsquorsquo DuServeurHTTP
Logiciel Postman New gt Request gt Creacuteer une requecircte HTTP POST gt Send
Veacuterifier que les requecirctes HTTP POST sont bien reacutecupeacutereacutees sur votre serveur creacutee preacuteceacutedemment
615 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST
Maintenant que nous avons un serveur HTTP (POST) fonctionnel nous allons configurer TTN pour
jouer le rocircle du client et pour qursquoil envoie des requecirctes HTTP POST vers notre Serveur degraves qursquoune
donneacutee drsquoun Device LoRa est disponible Nous geacuterons donc ici le flux Uplink
Requecircte
HTTP POST
Reacuteponse
(contenu parameacutetrable)
Client HTTP (POST)
Server HTTP (POST) [ httpsrbasketsin ]
| 50
Figure 53 Reacutecupeacuteration des donneacutees sur notre Application
Dans TTN nous inteacutegrons un bloc appeleacute laquo HTTP Integration raquo permettant de jouer le rocircle de client
crsquoest-agrave-dire drsquoenvoyer des requecirctes HTTP POST agrave destination de notre nouveau Serveur HTTP
Lrsquointeacutegration se faire agrave partir de TTN gt Console gt Application gt Nom_de_votre_application gt
Integration
Figure 54 Ajout dun client HTTP POST dans TTN
Pour valider le fonctionnement de notre architecture nous pouvons soit
Envoyer une trame depuis un Device LoRa vers TTN
Simuler lrsquoenvoi drsquoune trame drsquoun Device LoRa vers TTN (gracircce agrave lrsquooutil proposeacute par TTN vu
paragraphe 545)
Dans les deux cas voici un exemple de requecircte POST reccedilue sur notre serveur HTTP
app_id test_app_lorawan_sylvainmontagny
dev_id stm32lorawan_1
hardware_serial 0056AF49877
port 1
counter 0
payload_raw qg==
metadata
Requecircte
HTTP POST
Server HTTP (POST) [ httpsrbasketsin ]
The Things Network (Client)
La requecircte contient le Frame Payload deacutechiffreacutee
agrave transmettre agrave lrsquoApplication
| 51
time 2019-01-24T15243703499298Z
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Comme nous pouvons le voir le contenu fourni agrave notre serveur est formateacute en JSON (voir
paragraphe 0) Voici quelques compleacutements drsquoinformation
payload_raw Frame Payload deacutechiffreacute crsquoest donc les donneacutees en clairs dans la base 64
downlink_url URL du serveur HTTP POST qui serviront agrave transmettre des donneacutees au Device
LoRa (flux Downlink)
611 Envoyer des donneacutees depuis notre Application avec HTTP POST
Lorsque nous avons ajouteacute le bloc laquo HTTP Integration raquo au paragraphe preacuteceacutedent nous avons aussi
implicitement activeacute la fonctionnaliteacute que TTN soit precirct agrave recevoir et agrave traiter les requecirctes HTTP
POST La seule information qursquoil nous manque est lrsquoadresse du server HTTP vers lequel il faut eacutemettre
les requecirctes Si on observe la trame reccedilue preacuteceacutedemment en provenance de TTN on srsquoaperccediloit que
dans la trame JSON reccedilu une URL (downlink_url) est speacutecifieacutee
downlink_urlhttpsintegrationsthethingsnetworkorgttn-euapiv2downtest_app_lorawan_sylvainmontagnyrbasketskey=ttn-account-v28ypjj7ZnL3KieQ
Crsquoest cette URL que nous devrons utiliser Nous allons nous placer dans la configuration suivante
Figure 55 Envoi de donneacutees agrave partir de notre Application
Comme preacuteceacutedemment on peut reacutealiser le rocircle du client de deux faccedilons soit en ligne de commande
(la commande cURL srsquoexeacutecute depuis un Terminal sous linux) soit avec le logiciel POSTMAN
Commande cURL curl ndashX POST ndashdata lsquo dev_id Identidiant_De_Votre_Device
payload_raw AQE= rsquo DuServeurHTTP
Logiciel Postman New gt Request gt HTTP POST puis Body gt Raw gt JSON
Requecircte HTTP POST vers serveur TTN laquo downlink_url raquo httpsintegrationsthethingsnetworUaeb8ypKieQ
Contenu de la requecircte
dev_id Identidiant_De_Votre_Device
payload_raw aGVsbG8=
The Things Network (Serveur)
POSTMAN (Client HTTP POST)
| 52
dev_id YourDeviceID
payload_raw aGVsbG8=
Vous devez envoyer le texte (payload_raw) en base 64 Dans lrsquoexemple ci-dessus laquo aGVsbG8= raquo
correspond agrave la chaine de caractegravere laquo hello raquo Vous pouvez utiliser les nombreux encodeurdecodeur
en ligne pour vous aider Le texte doit srsquoafficher sur votre moniteur seacuterie Arduino dans le cadre de
notre deacutemonstrateur sur Arduino
62 Reacutecupeacuteration des donneacutees avec MQTT dans lrsquoApplication
621 Preacutesentation du protocole MQTT
MQTT est un protocole leacuteger qui permet de srsquoabonner agrave des flux de donneacutees Plutocirct que
lrsquoarchitecture Client Serveur classique qui fonctionne avec des Requecirctes Reacuteponses MQTT est
baseacute sur un modegravele Publisher Subscriber La diffeacuterence est importante car cela eacutevite davoir agrave
demander (Requecircte) des donneacutees dont on na aucune ideacutee du moment ougrave elles vont arriver Une
donneacutee sera donc directement transmise au Subscriber degraves lors que celle-ci a eacuteteacute reccedilue dans le
Broker (serveur central)
Figure 56 Modegravele Publisher Subscriber du protocole MQTT
Pour recevoir les donneacutees appartenant agrave un Topic un Subscriber doit souscrire (comme son nom
lindique) au preacutealable sur ce Topic
MQTT est un protocole qui repose sur TCP Lencapsulation des trames sur le reacuteseau est donc la
suivante
Broker
Client
Publisher 1
Client
Publisher 2
Client
Subscriber
Topic
Tempeacuterature
Topic
Humiditeacute
| 53
Figure 57 Protocoles utiliseacutes pour la communication avec MQTT
On peut le veacuterifier par une capture de trame sur Wireshark
Figure 58 Capture dune trame MQTT avec Wireshark
On peut noter que le port TCP utiliseacute pour le protocole MQTT (non chiffreacute) est le 1883
Les Publishers et les Subscribers nrsquoont pas besoin de se connaitre
Les Publishers et les Subscribers ne sont pas obligeacute de srsquoexeacutecuter en mecircme temps
622 Connexion au Broker MQTT Nous nous inteacuteresserons essentiellement aux options de connexion qui permettront de geacuterer la
Qualiteacute de Service (QoS) Pour se connecter un client MQTT envoie deux informations importantes
au Broker
keepAlive Cest la peacuteriode la plus longue pendant laquelle le client Publisher ou Subscriber pourra
rester silencieux Au-delagrave il sera consideacutereacute comme deacuteconnecteacute
cleanSession Lorsque le Client et le Broker sont momentaneacutement deacuteconnecteacutes (au-delagrave du
keepAlive annonceacute) on peut donc se poser la question de savoir ce quil se passera lorsque le client
sera agrave nouveau connecteacute
Si la connexion eacutetait non persistante (cleanSession = True) alors les messages non transmis
sont perdus Quel que soit le niveau de QoS (Quality of Service)
Si la connexion eacutetait persistante (cleanSession = False) alors les messages non transmis
seront eacuteventuellement reacuteeacutemis en fonction du niveau de QoS Voir le chapitre 624
623 Qualiteacute de Service au cours dune mecircme connexion
A partir du moment ougrave le Client se connecte au Broker il est possible de choisir un niveau de fiabiliteacute
des transactions Le Publisher fiabilise leacutemission de ces messages vers le Broker et le Subscriber
fiabilise la reacuteception des messages en provenance du Broker Une parle ici du cas dune mecircme
connexion crsquoest-agrave-dire entre le moment ou le Client se connecte et le moment ougrave
Soit il se deacuteconnecte explicitement (Close connexion)
Soit il na rien eacutemis ni fait signe de vie pendant le temps keepAlive
TCP
MQTT
Reacuteseau
Transport
Couche Application
IP
| 54
Lors dune mecircme connexion la Qualiteacute de Service (QoS) qui est mise en œuvre deacutepend uniquement
de la valeur du QoS selon les valeurs suivantes
QoS 0 At most once (au plus une fois) Le premier niveau de qualiteacute est sans acquittement Le
Publisher envoie un message une seule fois au Broker et le Broker ne transmet ce message quune
seule fois aux Subscribers Ce meacutecanise ne garantit pas la bonne reacuteception des messages MQTT
QoS 1 At least once (au moins une fois) Le deuxiegraveme niveau de qualiteacute est avec acquittement
Le Publisher envoie un message au Broker et attends sa confirmation De la mecircme faccedilon le Broker
envoie un message agrave ces Subscriber et attends leurs confirmations Ce meacutecanisme garantit la
reacuteception des message MQTT
Cependant si les acquittements nrsquoarrivent pas en temps voulu ou srsquoils se perdent la reacuteeacutemission du
message dorigine peut engendrer une duplication du message Il peut donc ecirctre reccedilu plusieurs fois
QoS 2 Exactly once (exactement une fois) Le troisiegraveme niveau de qualiteacute est garanti une seule
fois Le Publisher envoie un message au Broker et attends sa confirmation Le Publisher donne alors
lrsquoordre de diffuser le message et attends une confirmation Ce meacutecanisme garantit que quel que
soit le nombre de tentatives de reacuteemission le message ne sera deacutelivreacute quune seule fois
La Figure 59 montre les trames eacutemises pour chaque niveau de QoS
Figure 59 Qualiteacute de Service en MQTT
La Figure 60 repreacutesentes les 3 captures de trames sur Wireshark repreacutesentant les 3 QoS (1 2 et 3)
que nous venons dexpliquer
Broker
QoS 0
Au plus une fois
Message supprimeacute apregraves envoi
PUBLISH
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Duplications possibles
PUBLISH
PUBLICH Ack
QoS 0
Au moins une fois
Message enregistreacute
Survie agrave une perte de connexion
Pas de duplication
PUBLISH
PUBLISH Receive
PUBLISH Release
PUBLISH Complete
| 55
Figure 60 Capture de trame avec QoS = 0 puis QoS = 1 puis QoS = 2
624 Qualiteacute de Service apregraves une reconnexion
La question que nous nous posons et de savoir ce que deviennent les messages publieacutes sur le Broker
lorsquun ou plusieurs Subscribers sont momentaneacutement injoignables Il est possible de conserver
les messages qui ont eacuteteacute publieacutes sur le Broker afin de les retransmettre lors de la prochaine
connexion Cette possibiliteacute de sauvegarde doit ecirctre activeacutee agrave louverture de connexion gracircce au flag
cleanSession = 0 La connexion sera alors persistante crsquoest-agrave-dire que le Broker enregistre tous les
messages quil na pas reacuteussi agrave diffuser au Subscriber
Le Tableau 9 reacutesume leffet du flag cleanSession et du QoS
Clean Session Flag Subscriber QoS Publisher QoS Comportement True ( = 1) 0 1 2 0 1 2 Messages perdus
False ( = 0 ) 0 0 1 2 Messages perdus
False (= 0 ) 0 1 2 0 Messages perdus
False (= 0 ) 1 2 1 2 Tous les messages sont retransmis
Tableau 9 Qualiteacute de Service en fonction de la valeur du QoS et du flag cleanSession
625 Les Topics du protocole MQTT Les chaicircnes deacutecrivant un sujet forment une arborescence en utilisant la barre oblique comme
caractegravere de seacuteparation La Figure 61 et le Tableau 10 donne un exemple dorganisation de Topic
Figure 61 Exemple de hieacuterarchie de Topic MQTT
Niveau 3
Niveau 2
Niveau 1 Maison
Chambre
Temperature Humidite Bruit
Salon
Temperature
| 56
Nom du Topic Deacutetail du Topic MaisonChambreTemperature La tempeacuterature de la chambre de la maison
MaisonChambreBruit Le bruit de la chambre de la maison
MaisonSalonTemperature La tempeacuterature du Salon de la maison
Tableau 10 Exemple de Topic
Un client peut sabonner (ou se deacutesabonner) agrave plusieurs branches de larborescence agrave laide de
jokers englobant plusieurs Topics Deux caractegraveres jokers existent
Le signe plus + remplace nimporte quelle chaine de caractegravere sur le niveau ougrave il est placeacute
Le diegravese remplace nimporte quelle chaine de caractegravere sur tous les niveaux suivants Il
est obligatoirement placeacute agrave la fin
Nom du Topic Deacutetail du Topic Maison+Temperature Les tempeacuteratures de toutes les piegraveces de la maison
MaisonChambre La tempeacuterature lhumiditeacute et le bruit de la chambre de la maison
Tableau 11 Exemple de Topic
626 Mise en place drsquoun Broker MQTT Afin de bien comprendre le fonctionnement du protocole de MQTT on reacutealise des tests
indeacutependamment de TTN Nous allons mettre en place
Un Broker Mosquitto httpstestmosquittoorg
Un client Publisher MQTT Box sur Windows
Un client Subscriber MQTT Box sur Windows
Figure 62 Test du protocole MQTT
MQTT Client (Subscriber)
MQTT Client (Publisher)
Publish
Subscribe
BROKER (Mosquitto)
| 57
Le Broker MQTT est commun agrave tout le monde Nous pouvons soit le reacutealiser nous-mecircme soit utiliser
un Broker MQTT public de test Nous utiliserons le Broker de test de Mosquitto disponible sur
httpstestmosquittoorg Drsquoautres sont eacuteventuellement disponibles en cas de problegraveme par
exemple httpwwwmqtt-dashboardcom
Si nous deacutecidions de le reacutealiser nous-mecircme agrave lrsquoaide drsquoune Raspberry Pi (par exemple) Lrsquoinstallation
se ferait en deux lignes de commande
apt-get install mosquito Installation
sudo systemctl start mosquittoservice Lancement du service
Il est neacutecessaire drsquoinstaller mosquitto-clients si on souhaite que le Raspberry PI joue aussi le rocircle de
client ce qui nrsquoest pas notre cas
627 Mise en place drsquoun Publisher et drsquoun Subscriber MQTT Lancer le logiciel MQTTBox
MQTTBox gt Create MQTT Client
Dans ce client les seuls champs indispensables sont
Protocol MQTT TCP
Host testmosquittoorg
Figure 63 Configuration dun Client MQTT dans MQTT Box
Tester lrsquoenvoi et la reacuteception sur les Topics de votre choix
628 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT La reacutecupeacuteration des donneacutees fait reacutefeacuterence au flux Uplink Dans ce cas
TTN joue le rocircle de client Publisher
TTN joue aussi le rocircle de Broker
Notre application joue le rocircle de Subscriber
Nous pouvons donc repreacutesenter lrsquoapplication globale par le scheacutema suivant
| 58
Figure 64 Publisher et Subscriber dans en MQTT avec TTN
La publication est repreacutesenteacutee par la trame MQTT (1)
La souscription est repreacutesenteacutee par la trame MQTT (2)
Le client Publisher eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box mais cette fois avec la configuration suivante
Protocol mqtt tcp
Host Crsquoest lrsquoIP du Broker vers lequel il faut se connecter Dans notre cas il srsquoagit de celui
de TTN dont lrsquoadresse est euthethingsnetwork
Username La connexion vers le broker MQTT est soumis agrave une authentification Username
Password Dans notre cas le Username correspond au nom de notre application crsquoest-agrave-
dire seminaire_lorawan Si vous avez choisi une autre applicationil faut bien mettre la
votre
Password Le Password est nommeacute laquo Access Key raquo par TTN Elle vous sera donneacutee par
lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application vous
trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt Overview
Figure 65 Access Keys de lapplication dans TTN
The Things Network (Application Server)
BROKER
Application
The Things Network (Network Server)
Publish (1 )
[ Flux Uplink ]
Subscribe (2 )
[ Flux Uplink ]
| 59
Figure 66 Configuration du Client dans MQTT Box
Le client MQTT eacutetant configureacute il est maintenant capable de se connecter au Broker Il reste donc agrave
deacutefinir le fait que le client sera Subscriber Les informations que recevra le Subscriber deacutependent du
Topic auquel nous souscrivons Voici les Topic disponibles sur le Broker de TTN
ltAppIDgt correspond au nom de votre Application
ltDevIDgt correspond au nom de votre Device LoRa
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink ltAppIDgtdevicesltDevIDgtup
[Donneacutees] Flux Downlink ltAppIDgtdevicesltDevIDgtdown
[Activation Events] Activation dun Device ltAppIDgtdevicesltDevIDgteventsactivations
[Management Events] Creacuteation dun Device ltAppIDgtdevicesltDevIDgteventscreate
[Management Events] Update dun Device ltAppIDgtdevicesltDevIDgteventsupdate
[Management Events] Suppression dun Device ltAppIDgtdevicesltDevIDgteventsdelete
[Downlink Events ] Message programmeacute ltAppIDgtdevicesltDevIDgteventsdownscheduled
[Downlink Events ] Message envoyeacute ltAppIDgtdevicesltDevIDgteventsdownsent
[Erreurs] Uplink erreurs ltAppIDgtdevicesltDevIDgteventsuperrors
[Erreurs] Downlink erreurs ltAppIDgtdevicesltDevIDgteventsdownerrors
[Erreurs] Activations erreurs ltAppIDgtdevicesltDevIDgteventsactivationserrors
Tableau 12 Topics enregistreacutes dans TTN
Dans un premier temps nous souscrivons au Topic +devices+up Cela signifie que nous
souscrivons agrave tous les Devices LoRa de toutes nos applications pour le flux Uplink
Figure 67 Configuration du Subscriber
Les eacuteleacutements eacutemis par le Broker seront alors afficheacutes dans MQTTBox La
| 60
Figure 68 Trame LoRaWAN reccedilu sur le Subscriber MQTT
Ces donneacutees sont eacutecrites en JSON nous pouvons les remettre en forme
applicationID3
applicationNamemyApplication
deviceNamearduino0
devEUI0056xxxxxxxxx877
txInfo
frequency868500000
dr5
adrfalse
fCnt792
fPort15
dataSGVsbG8=
Le Frame Payload deacutechiffreacute est fourni dans le champ data en base 64 La valeur fournie par
dataSGVsbG8= correspond bien agrave la chaine de caractegravere hello que nous avons eacutemise avec le
Device LoRa
629 Envoyer des donneacutees depuis notre Application avec MQTT
Lrsquoenvoi des donneacutees fait reacutefeacuterence au flux Downlink Dans ce cas
Notre application joue le rocircle de Publisher
TTN joue le rocircle de Broker
TTN joue aussi le rocircle de client Subscriber
| 61
La publication est repreacutesenteacutee par la trame MQTT (3)
La souscription est repreacutesenteacutee par la trame MQTT (4)
Le client Subscriber eacutetant reacutealiseacute par TTN il est deacutejagrave configureacute Il nous reste agrave configure le client
Subscriber Nous utiliserons agrave nouveau MQTT Box Le rocircle de client dans MQTT Box a eacuteteacute faite au
paragraphe 628 Il nous reste simplement agrave ajouter le rocircle de Publisher La configuration est la
suivante
Topic du Subscriber seminaire_lorawandevicesarduino0down ougrave seminaire_lorawan
est agrave remplacer par le nom de votre application et arduino0 par le nom du Device LoRa vers
lequel vous souhaitez envoyeacute une donneacutee (Voir chapitre 628 pour comprendre les Topics)
Le Payload doit ecirctre au format JSON Lrsquoexemple suivant envoie laquohello raquo
payload_raw aGVsbG8=
The Things Network (Application Server)
BROKER
Application
Publish (3)
[ Flux Downlink ]
The Things Network (Network Server)
Subscribe (4)
[ Flux Downlink ]
| 62
Figure 69 Configuration du Publisher
Vous devriez voir les donneacutees arriver sur votre Device LoRA
| 63
7 Creacuteation de notre propre Network et Application Server
711 Objectifs Lors de la mise en œuvre du reacuteseau LoRaWAN au chapitre 52 nous avons utiliseacute TTN (The Things
Network) pour jouer le rocircle de Network Server et drsquoApplication Server Pour de multiples raisons
Seacutecuriteacute autonomie coucircthellipil peut ecirctre inteacuteressant de monter soi-mecircme un Network Server et un
Application Server Cela est possible seulement si vous posseacutedez vos propres Gateway puisque
celles-ci devront forwarder leur paquet agrave destination preacutecise Il faudra donc les reconfigurer pour
qursquoelles pointent vers votre nouvelle architecture
712 Preacutesentation de LoRaServer LoRaServer [ wwwloraserverio ] est un projet Open-Source reacutepondant exactement au besoin que
nous avons Nous lrsquoutiliserons sur une cible Raspberry PI En reacutealiteacute il peut souvent ecirctre mise en
place dans le mecircme systegraveme que la Gateway surtout si celle-ci est elle-mecircme agrave base de RPI Les
Gateway EBDS que nous posseacutedons possegravedent drsquoailleurs un Network Server et un Application Server
que nous aurions pu utiliser Neacuteanmoins pour des raisons peacutedagogiques il est inteacuteressant de
seacuteparer les systegravemes pour bien diffeacuterencier les probleacutematiques
Attention il y a une ambiguiumlteacute dans la deacutenomination des entiteacutes logiciels de LoRaServer
LoRaServer (sans espace entre le mot LoRa et Server) est le nom du projet global En
revanche LoRa Server (avec un espace) est le nom du service qui joue le rocircle du Network
Server
Lrsquoarchitecture et le fonctionnement de LoRaServer est preacutesenteacutee dans sa documentation par le
scheacutema suivant
Devices
Arduino
RN2483
Gateways
EBDS
Network
Server Application
Server
IP
Raspberry PI
Figure 70 Architecture globale de notre reacuteseau loRaWAN
| 64
Figure 71 Architecture deacutetailleacutee de LoRaServer
On srsquoattends agrave voir uniquement un Network Server (LoRa Server) et un Application Server (LoRa App
Server) mais ce scheacutema est plus complexe Il demande un certain nombre drsquoexplications pour bien
comprendre ce que nous allons installer et la faccedilon dont nous lrsquoutiliserons par la suite
713 Le laquo Packet Forwarder raquo (Gateway) Comme nous lrsquoavons vu au chapitre 412 les Gateways LoRa sont des passerelles entre la
modulation LoRa et un reacuteseau IP Pour reacutealiser cette passerelle un service nommeacute laquo UDP Packet
Forwarder raquo a eacuteteacute deacuteveloppeacute par Semtech httpsgithubcomLora-netpacket_forwarder Dans
ce dossier github un fichier nommeacute PROTOCOLTXT explique parfaitement ce protocole applicatif
qui travaille au-dessus de UDP
Figure 72 Protocole Uplink (PUSH_DATA du Packet Forwarder)
| 65
On remarque que les paquets sont envoyeacutes en UDP au Network Server dans une trame appeleacutee
PUSH_DATA Cette trame est acquitteacutee par le Network Server par une trame appeleacutee PUSH_ACK
Sur notre Network Server nous pouvons reacutealiser une capture de trame pour veacuterifier si le protocole
est bien celui preacutesenteacute dans le document
Figure 73 Trame captureacutee par Wireshark lors dun Uplink
Drsquoapregraves la capture preacuteceacutedente on remarque que le Packet Forwarder fonctionne bien avec UDP sur
le port 1700
Le contenu des donneacutees (champ Data) est deacutetailleacute dans le tableau suivant
Champ | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | random token
[3] | 3 | PUSH_DATA identifier = 0x00
[4] | 4-11 | Gateway unique identifier (MAC address)
[5] | 12-end | JSON object starting with ending with
Lrsquoobjet JSON de la transmission reacuteeacutecrit plus proprement est celui-ci
Figure 74 Analyse du champ Donneacutees du protocole laquo Packet Forwarder raquo
0000 02 f9 30 00 b8 27 eb ff fe ae 26 f5 7b 22 72 78 0amprx 0010 70 6b 22 3a 5b 7b 22 74 6d 73 74 22 3a 33 37 35 pk[tmst375 0020 35 30 30 35 38 31 39 2c 22 63 68 61 6e 22 3a 32 5005819chan2 0030 2c 22 72 66 63 68 22 3a 31 2c 22 66 72 65 71 22 rfch1freq 0040 3a 38 36 38 2e 35 30 30 30 30 30 2c 22 73 74 61 868500000sta 0050 74 22 3a 31 2c 22 6d 6f 64 75 22 3a 22 4c 4f 52 t1moduLOR 0060 41 22 2c 22 64 61 74 72 22 3a 22 53 46 37 42 57 AdatrSF7BW 0070 31 32 35 22 2c 22 63 6f 64 72 22 3a 22 34 2f 35 125codr45 0080 22 2c 22 6c 73 6e 72 22 3a 36 2e 35 2c 22 72 73 lsnr65rs 0090 73 69 22 3a 2d 31 2c 22 73 69 7a 65 22 3a 31 38 si-1size18 00a0 2c 22 64 61 74 61 22 3a 22 51 4e 4d 61 41 53 59 dataQNMaASY 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 ]
Ch
amp
[1
]
Ch
amp
[2
]
Ch
amp
[3
]
Ch
amp
[4
]
| 66
rxpk[ tmst3755005819
chan2
rfch1
freq868500000
stat1
moduLORA
datrSF7BW125
codr45
lsnr65
rssi-1
size18
dataQNMaASYAAQAPpyPZ955+SmY
]
Le champ data correspond au PHY Payload
De la mecircme faccedilon on retrouve la Trame drsquoacquittement
Figure 75 Trame captureacutee par Wireshark lors de lrsquoacquittement drsquoun Uplink
Champs | Num octet | Fonction
-------|--------------------------------------------------------
[1] | 0 | protocol version = 0x02
[2] | 1-2 | same token as the PUSH_DATA to acknowledge
[3] | 3 | PUSH_ACK identifier = 0x01
Nous retrouvons bien tous ces champs dans la trame Wireshark
714 LoRa Gateway Bridge Nous avons deacutecrit au chapitre preacuteceacutedent (713) le fonctionnement du Packet Forwarder Le
Network Server(Lora Server) que nous allons mettre en place aurait tregraves bien pu srsquointerfacer
directement agrave ce protocole Mais cela aurait plusieurs impacts dont un qui est important dans la
conception de logiciel Si le Packet Forwarder change ou si un autre type de Forwarder est utiliseacute
alors lrsquoutilisation du LoRa Server devient impossible Il a donc eacuteteacute choisi de creacuteer une eacutetape
intermeacutediaire Le Network Server que nous mettrons en plus utilisera le protocole MQTT plutocirct que
le protocole UDP packet Forwarder
En drsquoautres termes le LoRa Gateway Bridge est un service qui fera abstraction du Packet Forwarder
pour srsquointerfacer plus simplement avec le Network Server
715 LoRa Server (Network Server) Il srsquoagit de notre Network Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
413 Cependant il srsquointerfacera au protocole MQTT en recevant les informations agrave partir du
Broker au lieu de recevoir directement les trames en provenance de la Gateway
| 67
716 LoRa App Server (Application Server) Il srsquogit de notre Application Server qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre
414
717 LoRa Geo Server Il srsquoagit drsquoun service qui permet drsquoutiliser certaines proprieacuteteacutes du protocole LoRa pour proposer un
service de geacuteolocalisation des Devices LoRa Nous ne lrsquoutiliserons pas dans notre cas
718 Application Il srsquoagit de notre Application qui a le mecircme rocircle que celui que nous avons eacutetudieacute au chapitre 415
Elle ne fait pas partie du projet LoRaServer crsquoest donc bien toujours agrave nous de proposer notre propre
Application
Figure 76 Les interfaces possibles entre LoRaServer et lrsquoApplication utilisateur
Comme nous pouvons le voir sur la figure preacuteceacutedente deux possibiliteacutes sont offertes pour interfacer
notre application JSON REST (incluant HTTP POST) et via un Broker MQTT Ces deux meacutethodes ont
deacutejagrave eacuteteacute traiteacutee au chapitre 61 (HTTP POST ) et au chapitre 62 (MQTT) Nous verrons aussi drsquoautres
possibiliteacutes pour personnaliser notre application au chapitre 7
72 Installation de LoRaServer
721 Mise en place de lrsquoenvironnement
Nous allons installer une carte SD avec la derniegravere version de Raspbian Nous ne deacutetaillerons pas la
deacutemarche pour cela car elles sont largement documenteacutees et mises agrave jour sur le site
wwwraspberrypiorg
Installer un carte SD avec la derniegravere version de Raspbian
Plutocirct que de fonctionner avec un clavier et une souris nous preacuteconisons de travailler agrave distance
avec la RPI via une connexion SSH Depuis quelques anneacutees Raspbian a supprimeacute le deacutemarrage du
service SSH au boot Heureusement il est possible de le reacuteactiver par la meacutethode suivante
Avec Windows ou Linux ouvrir la partition BOOT de votre carte SD et placer un fichier agrave la
racine nommeacute sshtxt (ou ssh)
Mettre la carte SD dans votre RPI et la deacutemarrer
| 68
Pour acceacuteder agrave la RPI en SSH depuis Windows nous utiliserons de preacutefeacuterence le logiciel
client MobaXterm mais tout autre client SSH est valable
Installer MobaXterm sur votre PC et connectez-vous agrave votre Raspberry PI
Lrsquoutilisation drsquoun espion de reacuteseau type Wireshark peut ecirctre inteacuteressant pour eacutetudier les trames qui
sont reccedilues et qui sont eacutemises Cela nous permettra de valider le fonctionnement des diffeacuterents
protocoles reacuteseau qui permettent de communiquer agrave la Gateway drsquoune part et agrave lrsquoApplication
drsquoautre part Nous utiliserons tshark
apt-get install tshark installation
tshark ndashn -i eth0 Exemple drsquoune analyse sur lrsquointerface wlan0
722 Installation sur la Raspberry PI La meacutethode drsquoinstallation de LoRaServer est documenteacutee sur le site web agrave lrsquoadresse suivante
[ httpswwwloraserverioguidesdebian-ubuntu ] Nous installerons le LoRa Gateway Bridge
le LoRa Server et le LoRa App Server
Apregraves lrsquoinstallation la configuration se fait par une interface graphique accessible par le reacuteseau sur
le port 8080
Si vous travaillez sur la RPI connectez-vous sur httplocalhost8080
Si vous travaillez agrave distance (SSH) connectez-vous sur httpIP_RPI8080
Les Usernames et Password par deacutefaut sont
Username admin
Password admin
Lrsquoeacutecran drsquoaccueil sera donc le suivant
Figure 77 Architecture globale apregraves installation de LoRaServer
Devices
Gateways LoRa
UDP Packet Forwarder
Application Server
LoRa App Server
Internet
Network Server
LoRa Server
LoRa Gateway Bridge
| 69
Figure 78 Ecran daccueil de LoRaServer apregraves authentification
71 Configuration de LoRa Server pour lUplink
711 Enregistrement drsquoune nouvelle Organisation
Pour enregistrer une nouvelle Organizations Organizations gt Create Puis entrer les configurations
suivantes
Figure 79 Enregistrement dun nouvelle Organisation
712 Enregistrement drsquoune instance du Network Server Pour enregistrer une nouvelle instance du Network Server Network Server gt Create Puis entrer
les configurations suivantes
| 70
Figure 80 Enregistrement dun nouveau Network Server
Dans lrsquoonglet Gateway Discovery il est possible drsquoactiver une option de deacutecouverte de Gateway aux
alentours Lorsqursquoelle est configureacutee le Network Server va envoyer une trame Downlink de
configuration de la Gateway lui ordonnant de reacutealiser des PING en LoRa La configuration du
Gateway Discovery preacutevoit de speacutecifier
Le nombre de fois par jour que les PING LoRa sont envoyeacutes
Le canal drsquoeacutemission
Le Data Rate (Voir paragraphe 445)
Un PING LoRa reccedilu sur une Gateway sera retransmis sur le Network Server (Lora Server) et une carte
sera afficheacutee
Lrsquoonglet TLS Certificates ne sera pas utiliseacute dans le cadre de notre deacutemonstration
713 Enregistrement drsquoune Application (Sur lrsquoApplication Server) Il faut tout drsquoabord faire un enregistrement drsquoun laquo service-profile raquo Un laquo service profile permet de
faire la connexion entre le Network Server et les Applications que nous enregistrerons dans notre
Organisation Service-profiles gt Create
Service-profile name myServiceProfile
Network-server myNetworkServer
On laissera par deacutefaut toutes les autres options
Pour enregistrer une nouvelle Application Applications gt Create Puis entrer les configurations
suivantes
| 71
Figure 81 Enregistrement dune nouvelle Application
714 Enregistrement des Devices LoRa Il faut tout drsquoabord faire lrsquoenregistrement drsquoun Device-profile pour les Devices LoRa que vous
souhaitez connecter Dans notre cas nous ferons un premier test en speacutecifiant que nous utilisons
seulement le mode drsquoauthentification ABP (voir chapitre 431) Devices profile gt Create
Figure 82 Enregistrement dun laquo Device profile raquo
Nous pouvons alors creacuteer dans notre Application des nouveaux Devices Application gt
myApplication gt Create
| 72
Figure 83 Enregistrement dun nouveau Device LoRa
Dans la fenecirctre Activation on va alors configurer les 3 eacuteleacutements indispensables agrave une
authentification en APB Le DevAddr le NwkSKey et lrsquoAppSKey
Figure 84 Configuration de lenregistrement du Device LoRa (en ABP)
La configuration minimale de LoRaServer est maintenant termineacutee Nous pouvons donc brancher
un Device LoRa qui possegravede les les attribus (DevAddr NwkSKey et AppSKey) que nous avons
enregistreacute dans LoRaServer et le faire eacutemettre
715 Visualisation des trames reccedilues Les trames eacutemises par le Device LoRa vont donc parcourir le cheminement suivant
| 73
Figure 85 Reacutesumeacute du cheminement des trames LoRaWan en Uplink avec LoRaServer
En allant dans le Live Device Data (Application gt Nom_du_Device gt Live Device Data) on peut voir la
liste des trames reccedilues ainsi que les donneacutees applicatives deacutechiffreacutees
Figure 86 Reacuteception des trames des Devices LoRa
Figure 87 Analyse des trames des Devices LoRa
Dans lrsquoonglet LIVE LORAWAN FRAME nous pouvons voir les trames LORAWAN et si besoin eacutetudier
le contenu de ce qursquoelles contiennent En revanche les donneacutees applicatives sont ici chiffreacutees
UDP
Packet Forwarder
LoRa Bridge
Gateway LoRa Server LoRa App Server
Gateway
Server
Internet
| 74
Figure 88 Reacuteception des Trames LoRaWAN
72 Configuration de LoRaServer pour linteacutegration dApplication Nous avons vu dans le chapitre 718 que linterface entre LoRaServer et notre Application pouvait
ecirctre reacutealiseacutee soit par MQTT soit par les meacutethodes REST (HTTP POST) Nous avons deacutejagrave impleacutementeacute
et expliqueacute ces protocoles dans le cadre de son utilisation avec TTN Nous allons donc juste
configurer LoRaServer pour tester ces deux meacutethodes
721 Reacutecupeacuterer des donneacutees sur notre Application avec HTTP POST Nous utiliserons exactement la mecircme meacutethode que celle que nous avons utiliseacute avec TTN au
chapitre 615 Les diffeacuterentes Clients et Serveurs disponibles pour ces tests sont expliqueacutes au
paragraphe 612
Dans LoRaServer ajouter une inteacutegration HTTP LoRaServer gt Applications gt myApplication gt
Integrations gt Create gt HTTP Integration et la configurer comme le montre la Figure 89 Vous
remplacerez eacutevidement le lien par votre propre Endpoints
Figure 89 Configuration de linteacutegration HTTP POST dans LoRaServer
En envoyant des trames LoRa depuis votre Device vous devriez voir les contenus JSON sur votre
Endpoint
722 Reacutecupeacuterer des donneacutees sur notre Application avec MQTT Nous allons nous connecter au Broker MQTT de LoRaServer Pour cela nous utiliserons la mecircme
meacutethode que celle que nous avons utiliseacute avec TTN au chapitre 628 Nous utiliserons MQTTBox
comme nous lavons deacutejagrave fait au paragraphe 627
Le Broker de LoRaServer a enregistreacute les Topics suivant
[applicationID] correspond au nom de votre Application
[devEUI] correspond au nom de votre Device LoRa
| 75
Deacutetail du Topic Nom du Topic [Donneacutees] Flux Uplink application[applicationID]device[devEUI]rx
[Donneacutees] Flux Downlink application[applicationID]device[devEUI]tx
[Status] Statut dun Device application[applicationID]device[devEUI]status
[Ack] Acquittement des messages application[applicationID]device[devEUI]ack
[Erreurs] Erreurs application[applicationID]device[devEUI]error
Tableau 13 Topics enregistreacutes dans LoRaServer
| 76
8 Creacuteation de notre propre Application
81 Utilisation de Node-RED
811 Preacutesentation Node-RED est un outil de programmation graphique qui permet de faire communiquer les
peacuteripheacuteriques mateacuteriels drsquoun systegraveme sans eacutecrire de code De nombreux protocoles sont aussi pris
en charge au travers de bloc ( Node) qursquoil suffit de connecter entre eux pour reacutealiser simplement
une application Il peut srsquoexeacutecuter localement sur un PC ou sur des cibles embarqueacutees telle qursquoune
Raspberry PI (RPI)
Dans les deacutemonstrations que nous mettrons en œuvre nous utiliserons une RPI Par soucis de
simpliciteacute nous utiliserons les derniegraveres versions de Raspbian (systegraveme drsquoexploitation de la RPI) qui
integravegre drsquoorigine Node-RED Il nrsquoy a donc tregraves peu de chose agrave mettre en place pour arriver agrave mettre
en place une Application Nous pouvons travailler soit directement sur la RPI agrave lrsquoaide drsquoune souris-
clavier mais il est recommandeacute de travailler agrave distance avec une connexion SSH
812 Mise en place de lrsquoenvironnement La mise en place de la RPI avec le systegraveme drsquoexploitation Raspbian a eacuteteacute preacutesenteacute au chapitre 721
Vous pouvez reprendre la mecircme installation ou repartir sur une nouvelle
Il est possible de faire en sorte que Node-RED se lance directement au deacutemarrage gracircce agrave la
commande sudo systemctl enable noderedservice
Sil nest pas actif lancer Node-RED sur votre RPI node-red-start
Nous nous connectons au Node-RED de la RPI via un navigateur web sur le port 1880 en tapant dans
la barre dURL httpIP_Raspeberry_PI1880 Ce nous permet darriver agrave la fenecirctre suivante
Figure 90 Page daccueil de Node-RED
Il est possible de sinterfacer avec TTN avec les Nodes deacutejagrave disponibles gracircce au protocole HTTP
POST ou MQTT Neacuteanmoins nous pouvons avantageusement installer deux librairies speacutecifiques
Une qui facilite linterfaccedilage avec TTN
Une qui facilite la mise en place dinterface graphique
Installation des Nodes TTN
cd $HOMEnode-red
npm install node-red-contrib-ttn
Installation de Dashboard (interface graphique)
| 77
cd $HOMEnode-red
npm install node-red-dashboard
Il peut ecirctre necessaire de redeacutemarrer Node-RED pour prendre en compte linstallation de nos deux
Nodes
-----------------------------------
sudo apt-get install npm
sudo npm install -g npm
hash -r
cd ~node-red
npm install node-red-example node name
------------------------------------
813 Creacuteer une Application speacutecifique pour TTN Nous allons commencer par geacuterer le flux Uplink Apporter sur votre scheacutema un Node ttn uplink et
un Node Debug puis relier les Le Node ttn uplink nous permettra de configurer la
communication avec TTN en MQTT Le Node debug eacutecrira sur le terminal les informations brutes
qui seront reccedilu par le Node ttn uplink
Figure 91 Visualisation des trame publieacutees par TTN sur notre client MQTT
Double cliquer sur le Node ttn uplink pour le configurer comme la figure suivante
Le champ Name sera le nom du Node sur votre scheacutema Le champ Device ID est le device LoRa
concerneacute dans votre application De plus il faut entrer les caracteacuteristiques de votre application (Add
new ttn app) pour que Node-RED puisse sy connecter
Figure 92 Configuration du node ttn uplink
Configuration de votre nouvelle application
| 78
Figure 93 Identifiant et mot de passe de notre application
AppID Nom de votre application Dans notre cas seminaire_lorawan
Access Key Comme nous lavons deacutejagrave expliqueacute plus tocirct l Access Key vous sera donneacutee
par lrsquoenseignant dans le cadre de ce test Si vous avez enregistreacute votre propre application
vous trouverez lrsquoAccess Key dans TTN gt Application gt Nom_de_votre_application gt
Overview
Le Node ttn uplink doit maintenant avoir le nom que vous avez configureacute Cliquer sur Deploy pour
lancer votre projet Le bloc ttn uplink doit maintenant ecirctre connecteacute agrave TTN Cela est speacutecifieacute
connected sous le bloc
Figure 94 Utilisation du Node TTN Uplink
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
Figure 95 Simulation de Uplink dans TTN
Vous devriez voir le reacutesultat dans la fenecirctre de Debug Par exemple pour le test denvoi de 31 32
correspondant au code ASCII des chiffres 1 et 2 vous devriez avoir la fenecirctre de Debug suivante
| 79
Figure 96 Reacutesultats obtenu dans la fenecirctre Debug apregraves la simulation dUplink
814 Creacuteation drsquoun Dashboard
Dans la mise en place de lenvironnement (chapitre 812) nous avons installeacute des Nodes
Dashboard qui vont nous permettre de reacutealiser une interface graphique tregraves simple et de la mettre
agrave disposition des utilisateurs via un des graphiques histogramme gauges afficheurshellip
Figure 97 Impleacutementation dune interface graphique dans Node RED
Linterface graphique que nous allons creacuteer sera constitueacutee donglet (tab) La mise en place des
composant se fait de la faccedilon suivante
Chaque eacuteleacutement graphique doit appartenir agrave un groupe de composant quil va falloir creacuteer
Chaque groupe de composant doit appartenir agrave un onglet (tab) quil va falloir creacuteer
Figure 98 Creacuteation dun groupe de composant
Figure 99 Creacuteation dun nouvel onglet dans le site web
Cliquer sur Deploy pour activer votre application
LURL pour joindre linterface graphique de votre site web est disponible sur ladresse
httpIP_Raspeberry_PI1880ui
Reacutealiser un test de communication gracircce agrave une simulation duplink comme nous lavons vu au
paragraphe 545 TTN gt Application gt Nom_de_votre_application gt Devices gt arduino0
| 80
Figure 100 Interface graphique du site web avec Node-RED
82 Programmation en PHP Maintenant que nous avons testeacute toute lrsquoarchitecture nous pouvons mettre en place une
application qui jouera deux rocircles
Un rocircle de Serveur HTTP POST reacutecupeacuterant les donneacutees en provenance de TTN
Un rocircle de Client HTTP POST qui geacuteneacuterera les requecirctes vers TTN
Un serveur web apache sur RPI heacuteberge cette application Linterface graphique du site web est
reacutealiseacute avec le template CSS proposeacute par Bootstrap [ httpsgetbootstrapcom ]
Figure 101 Architecture de notre application en PHP sur RPI
The Things Network
Notre Application
[ Serveur Apache sur Raspberry Pi ]
Requecircte (1 )
HTTP POST
[ Flux Uplink ]
Requecircte (2)
HTTP POST
[ Flux Downlink ]
| 81
Nous allons lrsquoutiliser telle quelle Elle est juste proposeacutee agrave titre dexemple Lrsquoobjectif de cette
application est de geacuteneacuterer une ouverture fermeture de ruche agrave distance dans le cadre de projets
eacutetudiants du Master Electronique et Systegravemes Embarqueacutes de lUSMB [ httpscem-esetuniv-
smbfr ]
Figure 102 Application permettant de recevoir et deacutemettre des requecirctes HTTP POST
Configurer TTN pour pointer vers votre nouveau serveur et tester le flux montant et
descendant
| 82
9 Versions du document
Version 10 02022019
Version initiale
Version 20 23022019
Ajout drsquoun paragraphe Les systegravemes embarqueacutes dans lrsquoIoT En introduction
Compleacutement et ameacutelioration Ameacutelioration exercice eacutetalement de spectre
Correction Cacircblage Arduino
Ajout drsquoun paragraphe Fonctionnement de lrsquoArduino et ajout de librairies
Compleacutement et ameacutelioration Couche physique LoRa Ajout de 4 figures pour lrsquoexplication
de la modulation Chirp
Ajout drsquoun paragraphe sur les acronymes utiliseacutes au deacutebut du cours TTN LoRa MQTThellip
Compleacutement drsquoinformations sur les dB et dBm
Ajout LoRa Calculator
Version 30 8032019
Ajout de figure sur le rocircle de la Gateway LoRa
Ajout de paragraphe authentification avec le Network Server
Ajout de paragraphe sur le chiffrement avec lrsquoApplication Server
Ajout drsquoun sommaire en deacutebut de cours
Ajout de 2 scheacutemas ABP et OTAA
Retrait explication du deacutetail de la laquo Join Request raquo en OTAA Trop complexe attente de
reacutealisation drsquoun scheacutema plus explicite
Ajout drsquoun scheacutema sur lrsquoattaque par REPLAY
Ajout de paragraphe des diffeacuterents reacuteseaux LoRaWAN existants Opeacutereacutes et Priveacutes
Ajout des scheacutemas des trames LoRaWAN Physique LoRa MAC Application
Compleacutement drsquoinformation sur les Classes de Devices
Ajout drsquoun paragraphe sur la Gateway utiliseacutee pour le Downlink
Ajout drsquoun paragraphe sur le JSON
Compleacutement drsquoinformation sur le codage en Base64
Ajout drsquoinformation dans le deacutecodage des trames LoRaWAN
Restructuration des explications sur lrsquoenvoi et la reacutecupeacuteration des donneacutees en HTTPMQTT
Version 40 8032019
Ajout drsquoun chapitre Creacuteation de notre propre Application
Ajout drsquoun chapitre Creacuteation de notre propre Network et Application Server
Ajout drsquoune figure Visualisation des Chirps LoRa par SDR (Radio Logicielle)
Compleacutements drsquoinformation sur MQTT
Compleacutements dinformation sur les Topics de TTN en MQTT
