1. Présentation générale
LoRaWAN appartient à la catégorie des LPWAN (Low Power Wide-Area Network), réseaux basse consommation d'énergie, longue portée, adaptés aux objets connectés dont l'application requiert une autonomie importante. Ils utilisent les bandes de fréquences à usage libre ISM, partagées avec d'autres technologies sans-fil. Ils sont donc contraints au respect de règles d'utilisation définies, notamment en ce qui concerne la puissance d'émission, le rapport cyclique et la bande passante.
Les cas d'usage les plus courants des réseaux LPWAN sont les smart cities, les industries connectées et la mesure de données en milieu isolé, par exemple agricoles et météorologiques.
La figure ci-dessous présente le positionnement des LPWAN vis à vis des autres réseaux sans fil, par rapport à leur portée et bande passante respectives.
LoRa, pour Long Range, est une couche physique développée par Semtech qui permet des communications sans fil longue distance. LoRaWAN définit le protocole de communication et l'architecture du réseau.
LoRa utilise principalement la bande de fréquence 868MHz en Europe et emploie une modulation à étalement de spectre qui offre d'excellentes performances, une portée importante (plus de 15km en moyenne, record établi à 702km!) avec un signal robuste et une sensibilité accrue côté récepteur. Le débit est relativement faible, variant entre 300bps et 50kbps selon le facteur d'étalement.
La figure suivante présente l'architecture d'un réseau LoRaWAN.
Une topologie star-of-stars est utilisée avec au centre le serveur réseau. Les équipements, appelés end-devices, communiquent en modulation LoRa avec des passerelles qui centralisent les données avant de les transmettre via des liens IP (ethernet, 3G/4G) au serveur réseau.
Les end-devices ne communiquent pas exclusivement avec une passerelle définie mais avec l'ensemble des concentrateurs qui les couvrent. Ce mécanisme s'avère très efficace, particulièrement dans le cas d'un réseau mobile, en supprimant la nécessité de réaliser un hand-over. Inversement lorsque le serveur souhaite transmettre un message à un end-device, celui-ci est envoyé via une seule passerelle.
Les transmissions entre end-devices et passerelles doivent respecter les règles suivantes :
- Le device change de canal de manière pseudo-aléatoire à chaque transmission.
- Ne pas dépasser le rapport cyclique autorisé (1% en Europe, soit 36 secondes par heure).
- Ne pas dépasser la puissance maximale d'émission autorisée (+14dBm soit 25mW Europe).
Le serveur réseau assure la gestion de la sécurité, du débit adaptatif, de la redondance et communique avec des serveurs applicatifs qui exploitent les données en provenance des end-devices.
2. Un peu de théorie
Cette seconde partie explore les principaux concepts de la technologie LoRa, du protocole LoRaWAN et fournit un panorama global de l'écosystème existant.
2.1 LoRaWAN
2.1.1 LoRa Alliance
Créée en 2015, la LoRa Alliance est un consortium d'industriels et d'opérateurs, regroupés autour de LoRa dont l'objectif est la standardisation des réseaux à longue distance LPWAN et notamment de permettre l'interopérabilité de ces réseaux de télécommunication.
L'alliance est à l'origine du protocole LoRaWAN qui permet de construire des réseaux utilisant comme couche physique la modulation LoRa. La dernière version en date du protocole est la version 1.02.
La figure suivante présente l'architecture en couche de LoRaWAN en reprenant la terminologie du modèle OSI.
A noter qu'il est possible d'effectuer des communications point à point entre deux end-devices. Pour cela la spécification LoRaWAN définit le protocole LoRa-MAC.
2.1.2 Classes
La spécification LoRaWAN définit trois classes d'équipements pour des applications aux besoins distincts :
- Classe A "All" :
Les périphériques LoRaWAN implémentent au minimum le mode de fonctionnement décrit par la classe A. Il s'agit d'une communication bi-directionnelle : après l'envoi d'un message en uplink, le périphérique alloue deux courtes fenêtres de réception de messages downlink de la part de la passerelle. C'est la solution la plus économe en énergie pour les devices dont l'application ne nécessitent pas d'avantage de réception de messages downlinks.
La figure ci-dessus présente la réception d'un message pendant la seconde fenêtre de réception.
- Classe B "Beacon" :
Définit des end-devices bidirectionnels avec des slots de réception planifiés. Le fonctionnement est le même que pour la classe A avec
l'ajout d'un slot de réception programmé en plus des deux fenêtres aléatoires. La planification est permise par l'envoi d'un beacon de
synchronisation par la passerelle. La consommation en énergie est plus importante.
- Classe C "Continuous" :
Concerne les end-devices qui écoutent le réseau continuellement. Ce mode de fonctionnement est réservé aux périphériques qui
n'ont pas de contraintes de consommation d'énergie et offre la latence la plus faible.
2.1.3 Adresses
Le protocole LoRaWAN utilise plusieurs adresses pour identifier les différents périphériques sur le réseau.
- DevEUI - Identifie le end-device, format EUI-64 (unique)
- AppEUI - Identifie l'application, EUI-64 (unique)
- GatewayEUI - Identifie la passerelle, EUI-64 (unique)
- DevAddr - Adresse du device sur le réseau sur 32 bits (non unique)
2.2 La modulation LoRa, couche physique
Il existe deux grands types de modulation en LPWAN :
- L'Ultra Narrow Band qui consiste à transmettre les signaux dans une gamme de fréquence la plus étroite possible.
- L'étalement de spectre qui revient à étaler le spectre sur une large bande de fréquences avec une puissance d'émission très faible.
La modulation LoRa utilise une variante de l'étalement de spectre appelée Chirp Spread Spectrum pour coder l'information. A titre de comparaison SigFox utilise l'Ultra Narrow Band.
Un chirp ou gazouillis est un signal sinusoïdal dont la fréquence augmente ou diminue au cours du temps, on parle respectivement d'upchirp et downchirp. Initialement destinée à des applications militaires, cette modulation est également utilisée par les radars et les sonars. Elle est robuste contre les perturbations narrowband, broadband et le multipath fading.
L'étalement de spectre est réalisé par la génération d'un signal chirp linéaire dont la fréquence varie continuellement et qui vient ensuite moduler le signal à transmettre. Le facteur d'étalement, ou Spreading Factor est défini par le logarithme base 2 du nombre de chirps par symbole. Autrement dit, en LoRa un symbole est encodé par 2 exposant SF chirps.
La documentation Semtech nous fournit la relation suivante entre le débit de modulation Rb, le facteur d'étalement SF, la bande passante BW et le Rate Code, un code de correction de type FEC.
La portée d’une communication LoRa est déterminée par sa bande passante, la puissance d'émission du signal et le facteur d’étalement. En effet, l'étalement du signal augmente sa portée, mais réduit le débit, la transmission étant plus longue. Une transmission plus longue entraîne une consommation d'énergie supérieure et donc une diminution d'autonomie du device.
LoRaWAN supporte 6 facteurs d'étalements (de SF7 à SF12). La figure suivante présente le débit utile, la portée en fonction du facteur d'étalement.
L'algorithme ADR de gestion du débit adaptatif se base sur des changements de SF.
Une passerelle LoRaWAN doit au minimum proposer trois canaux de fréquence, 868,10, 868.30 et 868.50 avec une bande passante de 125KHz.
Les paramètres régionaux pour l'Europe spécifient :
- 10 canaux de 125kHz/250kHz(SF7).
- Une puissance d'émission TXmax de +14dBm.
- Un débit compris entre 250bps et 11kbps (50 kbps en LoRaWAN avec modulation FSK).
- Un bilan de liaison maximal de 155dB (Semtech garantissant une sensiblité des tranceivers jusqu'à -141dBm).
2.3 Mécanisme d'adaptation du débit ADR
Le réseau LoRaWAN permet aux end-devices de changer individuellement leur débit de transmission. Ce mécanisme appelé Adaptive Data Rate optimise les communications des end-devices statiques, en utilisant le débit le plus rapide possible. Le temps dans les airs est réduit, la consommation d'énergie est diminuée et la capacité du réseau augmente.
Le schéma suivant décrit avec un exemple le fonctionnement haut niveau de l'algorithme.
- Un paquet est envoyé par un end-device au débit le plus faible, correspondant au facteur d'étalement SF12 et avec un rapport signal sur bruit SNR de -10dB.
- Une marge de -5dB est ajoutée au SNR, on obtient -15dB, ce qui correspond à un SF10.
- Une instruction de changement de facteur d'étalement est envoyée au end-device, qui passe en SF10.
Plus en détail, dans l'implémentation de The Things Network, le mécanisme est activé quand le end-device positionne le bit ADR à 1 dans ses messages uplink.
Le serveur réseau détecte ce changement et récupère le SNR maximal pour chacun des messages reçus, le nombre de passerelles et les 20 derniers messages uplink qui sont insérés dans un tableau. Si le bit ADR passe à 0, le tableau est supprimé.
Après 20 messages il est possible de calculer la marge de SNR et le nombre d'étapes d'ajustement NStep :
SNRmargin = SNRm – RequiredSNR(DR) - margin_db SNRm : max SNR sur les 20 frames. RequiredSNR(DR) : avec le débit DR du dernier message. NStep = round(SNRmargin/3)
- Si NStep > 0 : le débit peut être augmenté ou la puissance d'émission réduite. Le débit augmente par NStep jusqu'à atteindre SF7. Si le nombre d'étapes nécessaires est inférieur à NStep, le "reste" est utilisé pour diminuer la puissance d'émission, de 3dBm, étape par étape jusqu'à atteindre TXMIN = 2dBm pour la région Europe 868MHz.
- Si NStep < 0 : la puissance peut être augmentée de 3dBm par étape jusqu'à atteindre la puissance d'émission TXMAX = 14dBm.
Le débit n'est pas réduit par cet algorithme. Une réduction automatique est appliquée directement par le end-device si les messages uplinks de demande d'acquittement ne sont pas acquittés (contenant le bit ADRACKReq positionné à 1).
2.4 Sécurité et activation
2.4.1 Sécurité dans un réseau LoRaWAN
En matière de sécurité, la norme LoRaWAN spécifie trois clefs AES-128 :
- NwkSKey, clef de session réseau, qui est utilisée lors des échanges entre le end-device et le coeur de réseau. Elle assure l'authenticité des devices en calculant et vérifiant un Message Integrity Code, MIC, à partir du Header et du Payload chiffré.
- AppSKey, clef de session applicative, spécifique à un end-device est utilisée pour chiffrer et déchiffrer le payload.
- AppKey, clef applicative connue seulement par l'application et le end-device et qui permet de déduire les deux clefs précédentes.
La clé de session applicative est connue uniquement par le fournisseur d'application. Il est donc impossible pour un tiers, y compris l'opérateur, de consulter les données.
On utilise également un frame counter pour se protéger contre les attaques par rejeu, qui consistent à répéter une transmission malicieusement interceptée. Le compteur est incrémenté à chaque transmission. La passerelle et les end-devices rejettent les transmissions dont la valeur de compteur est inférieure à celle attendue.
Le schéma suivant résume le processus de signature/chiffrement.
Pour faire partie d'un réseau LoRaWAN, chaque device doit obtenir les deux clefs de session. Cette étape d'activation peut s'effectuer de deux manières : Over-The-Air Activation (OTAA) ou Activation By Personalization (APB).
2.4.2 Over-The-Air Activation
En OTAA, le device doit transmettre au serveur réseau une demande d'accès, appelée join request et composée de trois paramètres :
- DevEUI
- AppEUI
- Un MIC applicatif calculé avec AppKey
Le serveur d'enregistrement dispose également de l'AppKey qu'il utilise pour vérifier le MIC réceptionné. Le serveur répond ensuite avec un message join accept qui contient l'adresse du device sur le réseau DevAddr et AppNonce, un application nonce de 3 octets qui permet au end-device de dériver les clefs de session NwkSKey, AppSKey.
Aucune réponse n'est transmise au device si la demande est rejetée.
Le schéma suivant présente la méthode d'activation Over-The-Air.
2.4.3 Activation By Personalization
En ABP, les clefs de session NwkSKey, AppSKey et l'adresse du device DevAddr sont directement stockées sur le end-device. Il est possible alors de passer outre la procédure de join request, join accept.
NwkSKey et AppSKey doivent être uniques !
2.5 Piles de communication logicielles
- Pile Semtech : Il s'agit de la pile officielle LoRaWAN écrite en C par Semtech. Disponible pour les passerelles et pour les capteurs, c'est l'implémentation la plus complète du protocole, à jour avec la spécification.
- RadioHead : libraire de communication radio pour microcontrôleur. Elle supporte notamment le tranceiver HopeRF RFM95 et la modulation LoRa. Le protocole LoRaWAN n'est pas supporté.
- IBM LMIC : pile en C implémentant le protocole LoRaWAN. Plutôt légère, elle se destine principalement aux microcontrôleurs. Elle est portée pour l'environnement Arduino mais aussi pour ARM, notamment pour les STM32 et pour Linux.
2.6 Couverture et opérateurs
LoRaWAN permet la coexistence de deux types d'opérateurs : publics et privés.
2.6.1 Réseaux publics
En France deux opérateurs de télécommunications ont déployé des réseaux LoRaWAN :
- Objenious, le réseau de Bouygues Telecom. Crée en février 2016, c'est actuellement le premier réseau français avec une couverture de plus de 93 % de la population. Plus de 4000 antennes ont été déployées sur le territoire. De plus des accords de roaming sont déjà conclus avec Senet (US), Digimondo (Allemagne) et Proximus (Belgique). L'entreprise offre également une plateforme web de gestion des objets, SPOT et une grande variété de capteurs compatibles.
- Orange, dont le réseau couvre actuellement plus de 4000 communes et sites industriels sur le territoire (chiffres juin 2017) et qui vise la couverture nationale complète pour fin 2017.
La carte ci-dessous présente la couverture française du réseau Objenious.
2.6.2 Réseaux privés
Il est possible pour les particuliers, entreprises non opérateurs, ou encore les communes de déployer leur propre réseau LoRaWAN.
Plusieurs opérateurs associatifs ont ainsi émergé, parmi lesquels figure le néerlandais The Things Network, dont l'objectif est de construite un réseau open source et décentralisé pour l'IOT. Sur un modèle de financement participatif, le réseau est à la propriété de ses utilisateurs qui se regroupent en communautés, principalement en zone urbaine.
Les utilisateurs déploient leurs propres passerelles, connectées par des liens haut débits au coeur de réseau The Things Network par le biais d'un client logiciel fourni par l'association. Actuellement le réseau se compose de 23000 contributeurs regroupés en plus de 400 communautés dans 90 pays.
TTN lance son propre matériel via une campagne de financement participatif en proposant passerelles et end-devices compatibles LoRaWAN en open hardware.
3. Application pratique
Cette section décrit un cas d'application simple de réseau LoRaWAN avec transmission d'une mesure de température à The Things Network et récupération en MQTT.
3.1 Architecture de la solution
On utilise ici une architecture relativement simple. Notre capteur Adafruit feather est équipé d'un tranceiver RFM95W et transmet à intervalles réguliers la température relevée par la sonde DHT22. La passerelle, construite sur base d'un Raspberry Pi 3 et d'un tranceiver LoRa transfère le message vers le coeur de réseau The Things Network.
On récupère la température en se connectant au broker MQTT de The Things Network, qui est ensuite enregistrée dans notre base de donnée timeseries InfluxDB et affichée sur la plateforme web Grafana.
3.2 Partie capteur
Le fait d'utiliser directement une carte de développement Adafruit Feather facilite l'effort de développement côté capteur. En effet, en étant compatible avec l'écosystème Arduino, on peut directement utiliser les librairies adaptées pour la sonde DHT22 et surtout
LMIC pour le tranceiver RFM95W.
Dans cet exemple, on utilise la méthode d'activation ABP, il faut donc définir les clefs de sessions réseau NwkSKey et applicatives AppSKey ainsi que l'adresse du device DevAddr directement dans le code :
// Most Significant Bit first
static const u1_t APPSKEY[16] = {0xDB, 0x42, 0x86, 0x08, 0xFF, 0xE3, 0xC8, 0x74, 0xBD, 0xC2, 0x73, 0x5B, 0xC1, 0x8E, 0x8D, 0xB0};
static const u1_t NWKSKEY[16] = {0x76, 0x5B, 0x48, 0xFE, 0xDD, 0xCB, 0xEF, 0x41, 0xA9, 0xFC, 0xD2, 0xEB, 0x1C, 0xD4, 0xF4, 0x9E};
static const u4_t DEVADDR = 0x26011A91;Pour générer automatiquement ces clefs, il est nécessaire de créer une application sur le portail de The Things Network, via l'outil Console et d'y ajouter un device :
La librairie LMIC fonctionne avec sa propre mainloop qui est lancée après configuration de la session, des canaux de transmission, de la puissance d'émission et du facteur d'étalement initial. Dans le code source, on définit TX_INTERVAL comme l'intervalle de temps entre l'envoi successif de deux messages. Ce délai est ajusté automatiquement par la suite pour ne pas dépasser les limitations de rapport cyclique imposées par la norme.
On prépare le payload à envoyer lors de la prochaine transmission avec la fonction do_send :
void do_send(osjob_t* j){
static uint8_t mydata[] = {0};
float t = dht.readTemperature();
// Convert t variable into ASCII representation
dtostrf(t,5,2,(char*)mydata);
// Check if there is not a current TX/RX job running
if (LMIC.opmode & OP_TXRXPEND) {
Serial.println(F("OP_TXRXPEND, not sending"));
}
else {
// Prepare data transmission at the next possible time
LMIC_setTxData2(1, mydata, strlen((char*) mydata), 0);
Serial.println(F("Packet queued"));
}
}Le payload se présente sous la forme d'une chaîne de caractère, une solution possible pour transmettre ce float est de convertir la température en représentation ASCII. Côté application, le portail The Things Network nous offre une certaine flexibilité en nous permettant de définir notre propre fonction de décodage du payload :
Notre capteur est ainsi prêt à envoyer ses données au coeur de réseau TTN !
3.3 Du côté de la passerelle
Notre capteur étant désormais fonctionnel, on s'intéresse à la passerelle qui va relayer le message vers The Things Network. Pour cette preuve de concept on utilise au niveau matériel un Raspberry Pi3 sur lequel on vient connecter une carte d'extension ChisteraPi conçue par l'entreprise toulousaine Snootlab. Elle embarque deux tranceivers radios, un RFM22 permettant d'effectuer des transmissions en 433MHz et un RFM95W 868MHz permettant de faire du LoRa.
Initialement prévue pour transformer le raspberry pi en end-device, il est néanmoins possible de détourner cette carte pour un faire un packet forwarder, ou une passerelle mono canal. Pour cela, on utilise un programme conçu par The Things Network et fonctionnant sous linux, disponible ici.
Dans le cadre du projet de stage e-diot, une distribution linux a été construite avec Yocto et intègre une recette pour ce packet forwarder. On utilise un unit file systemd pour lancer le programme au démarrage du système.
DESCRIPTION = "Single Channel Gateway"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://${COREBASE}/meta/files/common-licenses/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
DEPENDS = "wiringpi"
SRCREV = "c3cf15f6f3db46ec554de873326d253ee0508ea4"
SRC_URI = "git://github.com/ArnaudPec/single_chan_pkt_fwd.git;protocol=git;branch=master \
file://sgw.service"
S = "${WORKDIR}/git/"
inherit autotools systemd
PARALLEL_MAKE = ""
SYSTEMD_PACKAGES = "${PN}"
SYSTEMD_SERVICE_${PN} = " sgw.service"
FILES_${PN} += " ${systemd_unitdir}/system/sgw.service"
do_install_append(){
install -d ${D}${systemd_unitdir}/system/
install -m 0644 ${WORKDIR}/sgw.service ${D}${systemd_unitdir}/system/
}Une fois la passerelle installée, il est nécessaire de la configurer sur le portail de The Things Network. Cette opération se fait également via l'outil Console. Il est nécessaire d'y définir le plan de fréquences, l'emplacement géographique et notamment de choisir le routeur TTN. On a à présent une passerelle fonctionnelle, qui retransmet au coeur de réseau les messages des end-devices LoRaWAN à portée.
3.4 Cloud et récupération des données
La dernière étape consiste à récupérer nos données depuis le coeur de réseau TTN et les transférer vers notre base de données et notre interface de visualisation.
Plusieurs approches sont possibles pour collecter nos données, notamment une intégration HTTP et MQTT. On privilégie ici la deuxième option, très facile à mettre en oeuvre. On peut se connecter rapidement au broker TTN depuis un shell linux avec le client mosquitto :
mosquitto_sub -h eu.thethings.network -t '+/devices/+/up' -u $APP_ID -P $APP_KEY -v
APP_ID et APP_KEY sont disponibles sur le portail web TTN, via la page d'application. Le choix du topic -t nous permet d'affiner notre sélection de end-devices dans l'application. Le payload arrive sous forme de json, que l'on parse avec l'outil en ligne de commande jq pour une lecture plus aisée :
testfeather/devices/feather/up
{
"app_id": "testfeather",
"dev_id": "feather",
"hardware_serial": "0083F538919A9B51",
"port": 1,
"counter": 0,
"is_retry": true,
"payload_raw": "MjQuNjA=",
"payload_fields": {
"temperature": "24.60"
},
"metadata": {
"time": "2017-09-13T09:01:27.51959633Z",
"frequency": 868.1,
"modulation": "LORA",
"data_rate": "SF7BW125",
"coding_rate": "4/5",
"gateways": [
{
"gtw_id": "eui-b827ebffffa310ed",
"timestamp": 1877700397,
"time": "",
"channel": 0,
"rssi": -67,
"snr": 9,
"rf_chain": 0,
"latitude": 43.6115,
"longitude": 1.4359,
"altitude": 162
}
]
}
}
A présent il convient de créer un service pour automatiser la récupération des données sur le broker TTN. Notre architecture en place utilise un broker MQTT local, déjà connecté à InfluxDB par un programme Go et qui permet de centraliser des données capteurs de sources multiples. Notre service se limite donc à une fonction de pont entre les deux brokers.
Pour se connecter en MQTT, on utilise le package paho.mqtt.golang du projet Eclipse. Le langage Go nous fournit également des solutions permettant de décoder facilement le json à partir d'une structure de données préalablement définie. Notre programme a donc le fonctionnement suivant :
- Connexion au broker TTN, avec identification et choix du topic
- Pour chaque message publié:
- Récupération du message
- Parsage de l'objet json et extraction des éléments d'intérêt: payload, metadata
- Préparation du payload
- Publication sur notre broker local
Le code complet de ce connecteur configurable est disponible ici.
On peut ensuite exploiter les mesures collectées avec Grafana, une application web qui permet de présenter les métriques sous forme de graphiques, diagrammes, courbes et indicateurs. Elle s'interface aisément avec InfluxDB et il est possible de formuler graphiquement les requêtes dans un langage proche de SQL.
Conclusion
On a donc une preuve de concept de réseau IOT LoRaWAN Open Source simple mais fonctionnelle qui peut facilement être étendue par l'ajout d'autres capteurs et l'amélioration du connecteur MQTT. Cependant pour un véritable environnement de production, les passerelles mono canal sont à proscrire au profit de passerelles entièrement compatibles avec la spécification LoRaWAN, permettant notamment de recevoir et émettre simultanément sur plusieurs canaux et avec des facteurs d'étalement différents.
La technologie LoRa et le protocole LoRaWAN bien que encore relativement jeunes constituent une alternative viable au leader actuel du marché des réseaux IOT : SigFox. Si les performances radios des deux concurrents sont relativement proches, leurs modèles économiques sont diamétralement opposés. L'approche plus ouverte de LoRaWAN séduit, mais les multiples réseaux publics n'égalent pas encore la couverture de SigFox. De plus la démocratisation prochaine des standards LTE-M et NB-IOT risque de transformer significativement le marché.
Sources :
https://www.thethingsnetwork.org/wiki/LoRaWAN/Home
https://www.frugalprototype.com/technologie-lora-reseau-lorawan/
Merci pour cette excellente présentation de LoRa et sa mise en oeuvre autour d'une carte RPi.
P. Kadionik
MCF-HDR à l'ENSEIRB-MATMECA