Introduction

Selon l’étude de marché menée par Statista en 2018 [1], plus de 75 milliards d’objets seront connectés à Internet en 2025, soit deux fois plus qu’en 2021 (35 milliards d’objets connectés).
Un grand nombre d’objets seront connectés via un réseau bas débit et faible coût, comme LoRaWAN, SIGFOX, ou à travers les réseaux cellulaires (LTE-M/NB-IoT).
En 2009, Christophe Fortet et Ludovic Le Moan ont créé la société SIGFOX pour le marché M2M. Dans le secteur des objets connectés, SIGFOX est le premier à s’être positionné comme Opérateur IoT en déployant son propre réseau sur plusieurs continents (déploiement de l’accès radio-électrique et du cœur de réseau).

A la même année (2009), Nicolas Sornin et Olivier Seller de la société Cyclo travaillaient sur un module de transmission longue portée pour des télé-relevées (comptage eau-électricité). L’entreprise Cycleo fut rachetée par SEMTECH en 2012 qui est à l’origine de la technologie LoRa. Les puces SX1272 et SX1276 pour les modules LoRa et SX1301 (figure 1) pour la passerelle ont été produites à partir de 2012.


Figure 1 : Puce LoRa SW1301

En 2015, l’alliance LoRaWAN, réunissant des opérateurs (Orange, Bouygues …), des équipementiers (SEMTECH, ST, …) et des éditeurs logiciels et intégrateurs (Actility, Sagemcom, Birdz, Cisco), a spécifié la norme LoRaWAN.
Enfin les réseaux d’accès LTE-M et NB-IoT (normalisés par 3GPP) s’appuient sur les réseaux de mobiles 4G/5G permettant ainsi d’apporter rapidement une connectivité mondiale.
Les premières applications nécessitant des solutions de connectivités longue portée, faible cout et consommant peu d’énergie (LPWAN : Low Power WAN) concernaient la collecte de données pour la gestion d’eau et d’Energie. A ce titre, VEOLIA a racheté l’activité Energie de la start-up Actility, complétant ainsi son activité de télé-relevé qu’elle réalise avec sa filiale Birdz (exemple pour la gestion des déchets dans le secteur Smart-City et environnement urbain).

En 2020, le marché de suivi de marchandises (s’appuyant sur ces technologies) afin d’améliorer les process logistique et afin de réduire la durée d’approvisionnement des matières premières a connu une forte croissance.
A titre d’exemple, les vaccins Covid réalisés par les laboratoires Pfizer et Moderna doivent être transportés en respectant un état en congélation à -70°C pour Pfizer et -20°C pour Moderna. Les laboratoires ont mis en place une procédure de suivi des vaccins pour suivre l’acheminement (GPS/NFC) avec un suivi de la température. Aux Etats Unis, les solutions LoRaWAN et 5G ont été étudiées puis écartées (difficulté de roaming) au bénéfice de la solution NB-IoT.
L’Internet des Objets Industriel (IIoT), qui est la base de l’Industrie 4.0 (Smart Factory / usines intelligentes) fournit également une connectivité aux machines, aux système de gestion, et à la logistique/approvisionnement.
L’hypecycle de Garter (figure 2) montre la maturité des technologies pour les années à venir, mettant ainsi en avant l’usage de la connectivité pour le secteur des véhicules autonomes.


Figure 2 : Hype Cycle pour l’IoT (Garnet Juin 2020)

La couche Physique LoRa

LoRa est une technologie de transmission RF (couche physique) utilisant la méthode de modulation à étalement de spectre CSS (Chirp Spread Spectrum) dans la bande ISM. La méthode CSS est une méthode utilisée pour les usages militaire et maritime que l’on retrouve dans les applications suivantes : les SONAR et les RADAR de l’aviation. L’avantage du CSS pour les applications militaires réside dans sa capacité à être difficilement détectable et difficile à brouiller.

Néanmoins, dans le cas d’usage de l’IoT, c’est la capacité du signal CSS d’être transmis à un faible niveau et d’avoir une grande résilience aux interférences qui est le principal atout. C’est capacité à être démodulée est d’autant plus importante dans une bande libre de droit (ISM).

Un CHIRP (dans le cas du CSS), est un signal dont la fréquence évolue continument d’une fréquence f1 à une fréquence f2. La largeur de bande BW est égale à l’écart de fréquence|f2-f1|. On parle d’un signal up-chirp (figure 3) si la fréquence augmente et down-chirp si la fréquence diminue.


Figure 3 : La transmission dans le temps d’un Up-Chirp

Un CHIRP est composé d’une séquence de code nommé CHIP. Le CHIP représente un élément de la séquence de code (un échantillon) et est transmis avec une période Te=1/BW. En général, la largeur de bande BW=125 kHz, un élément de la séquence de code (un CHIP) est donc transmis toutes les 8 µs.

La durée de transmission du CHIRP dépend du nombre de CHIP composant un CHIRP.

On appelle SF (Spreading Factor), le facteur d’étalement. On considère qu’on transmet 2SF CHIP par CHIRP, avec SF une valeur comprise entre 7 et 12.

Ainsi, la durée de transmission d’un CHIRP est de 2SF.Te, on double donc la durée du CHIRP lorsqu’on incrémente le valeur SF de 1 (Figure 4).


Figure 4 : La durée de transmission d’un CHIRP pour SF de 7 à 12

La bande de fréquence BW est décomposée en 2SF intervalles numérotés de 0 à 2SF-1.

Un intervalle est donc codé par SF bits.

Le CHIRP est un signal qui évolue en fréquence, et dont la largeur de bande est BW.

Dans le cas d’un up-chirp le signal démarre d’une fréquence minimum jusqu’à la fréquence maximum. Le signal up-chirp démarre donc à l’intervalle 0.

Un signal LoRa modulé est un signal dont la fréquence augmente jusqu’à atteindre la fréquence maximale, puis par un saut de fréquence, le signal bascule en fréquence à la valeur minimale puis la fréquence augmente pour atteindre la fréquence initiale (cf. figure 5). On dit qu’il y a un saut de fréquence BW.

La bande BW étant décomposée en 2SF sous bandes, le signal modulé M démarre en fréquence sur l’une des 2SF sous bandes. M est le symbole à transmettre et est composé de SF bits (2SF combinaisons).

Le récepteur démodule le CHIRP et récupère la valeur initiale qui correspond au symbole à transmettre.


Figure 5 : La transmission d’un CHIRP transportant un symbole

Comme tout système de transmission, le récepteur doit être synchronisé avec l’émetteur. LoRa utilise une méthode de transmissions asynchrone : le début de la trame LoRa est une séquence de synchronisation (figure 6) qui est composée de 10 CHIRPS (8 up-chirp et 2 down-chirp).


Figure 6 : La synchronisation de la trame LoRa suivi de 5 symboles

Un CHIP est transmis à la période de Te=1/BW.

Un CHIRP a une durée de 2SF. Te et transporte SF bits. Le débit d’un CHIRP est donc de SF.BW/2SF

Un autre avantage de La méthode CSS concerne les propriétés d’orthogonalité des CHIRP de valeurs SF différentes : la passerelle est donc en capacité de recevoir 6 signaux simultanément (SF=7 à SF=12) sur la même bande BW.

Si la passerelle écoute 16 canaux fréquentiels, alors le nombre de communications montantes simultanées est de 16*6=96.

La durée de transmission (TOA – Time-On-Air) impacte la consommation énergétique. L’objectif est de réduire la durée de transmission en sélectionnant un SF le plus petit possible. Cependant, la résilience au bruit se calcule par rapport au gain d’étalement : G=10.log10(2SF). Ainsi, plus SF est grand et plus le signal est résistant au bruit.

Soit Pe la puissance (en dB) du signal émis et Pr (en dB) la puissance du signal reçu. Notons A, l’atténuation en dB du signal entre l’émetteur et le récepteur.  Plus A est élevée, plus le signal est atténué.

La puissance du signal reçu et démodulé est calculée par : Pr=Pe-A+G.

On appelle SNR, le rapport signal à bruit (Signal to Noise ratio). Pour pouvoir être démodulé correctement, le rapport SNR doit être supérieur à un seuil S.

La puissance de bruit étant considérée comme identique pour une même largeur de bande B (Formule de Boltzmann) alors la stratégie radioélectrique la plus pertinente consiste à choisir un SF élevé pour un terminal le plus éloigné et un SF petit lorsque les conditions radioélectriques sont bonnes.

 

L’architecture du réseau LoRaWAN

L’architecture du réseau LoRaWAN se compose de terminaux LoRa (LoRa Mote ou end-point) communicant avec une passerelle LoRA (Gateway). La passerelle LoRa relaie les trames LoRa vers un serveur LoRAWAN (NS) via le protocole IP. Les trames LoRa sont encapsulées dans le réseau IP (figure 7).


Figure 7 : Protocole d’encapsulation de la passerelle LoRa

Les trames transportent des informations de signalisation ou des données associées à des informations de signalisation.

Le serveur LoraWAN (NS) récupère le contenu de la trame LoRa et relai les données vers le serveur d’application AS (figure 8)

Afin d’optimiser la couche radioélectrique, le contrôle du facteur d’étalement SF est réalisée par une entité logique LoRa Network Controller (NC).


Figure 8 : L’architecture du réseau LoRaWAN 1.0/1.0.2/1.0.3

En général, les entités logiques LoRa NS et LoRa NC sont situées sur la même entité physique NS (Network Server).

Les données de signalisation échangées entre le terminal et le serveur NS sont chiffrées et protégées en intégrité.

Les données de trafic émise par le terminal vers le serveur AS sont chiffrées

Les clés de chiffrement et d’intégrité sont dérivées d’une clé privée APPKEY qui est pré-commissionnée sur le terminal et provisionnée par le client avant activation du terminal dans le serveur NS (LoRaWAN 1.0/1.0.2/1.0.3).

Cette procédure a comme inconvénient de fournir la clé privé APPKEY à l’opérateur.

La version LoRaWAN 1.0.4 (2020) et LoRaWAN 1.1 (2017) proposent l’ajout d’un serveur JS (Join Server) qui appartient soit à l’équipementier, soit à l’opérateur, soit au client, soit à un fournisseur de service (Figure 9).


Figure 9 : Les possibilités de déploiement du JS

Le Join Server est provisionné avec l’identifiant DEVEUI du terminal (identifiant unique) et avec la clé privé APPKEY.

Ainsi, selon son cas d’usage, l’opérateur ne dispose plus de la clé privée et ne peut donc plus décoder les données.

Lorsque le client souhaite activer son terminal, il doit commissionner le serveur JS de l’identité de l’opérateur Home. L’opérateur Home est l’opérateur qui est en charge d’apporter les services de connectivité du terminal.

Lorsque le terminal s’allume, l’activation OTAA (Over The Air Activation) permet au hNS (Home NS) d’enregistrer le terminal.

La procédure d’activation, nommée Join Procedure (figure 10), est composée des échanges suivants :


Figure 10 :  Procédure d’enregistrement pour LoRaWAN 1.0.4 ou LoRaWAN 1.1 (2)

1 – Le terminal envoie une requête JoinRequest contenant l’identifiant DEVEUI du mobile et un numéro DevNONCE sur 16 bits et l’identifiant  APPEUI ou JOINEUI.

  • APPEUI : Identifiant du serveur d’application (LoRAWAN 1.0/1.02/1.0.3)
  • JOINEUI : Identifiant du serveur JS (LoRaWAN 1.0.4 ou LoRaWAN 1.1)

Les données ne sont pas chiffrées mais le terminal ajoute une signature MIC correspondant au calcul d’intégrité de la Payload avec la clé privée APPKEY.

DEVNONCE est soit :

  • un numéro aléatoire (LoRaWAN 1.0)
  • un numéro aléatoire qui n’a pas été choisi lors d’une précédente requête JoinRequest (LoRaWAN 1.0.2/LoRaWAN 1.0.3)
  • un compteur incrémenté de 1 à chaque requête JoinRequest et initialisé à 0.

NB : Le terminal peut être amené à réaliser plusieurs requêtes JoinRequest successives s’il n’est pas couvert par une passerelle LoRa.

2 – Le NS doit créer un contexte contenant les clés de chiffrement et d’intégrité pour les informations de signalisation et fournir une adresse LoRA (DevADDR) pour le terminal.

  • LoRaWAN 1.0/1.0.2/1.0.3 : le serveur NS vérifie l’existence du DEVEUI dans sa base de données. Le cas échéant, le NS vérifie la signature MIC avec la clé privée APPKEY. En cas de correspondance, le serveur NS choisit un numéro aléatoire AppNONCE et défini les paramètres radioélectriques (liste des fréquences à utiliser, les délais entre l’émission et la réception pour la transmission de données) qui seront imposés au terminal. La payload est composée du la configuration des paramètres radios, de l’adresse LoRa DevADDR et du numéro aléatoire AppNONCE. La payload est chiffrée par la clé privée APPKEY et un contrôle d’intégrité MIC est rajoutée aux données chiffrées. A partir des valeurs DevNonce et APPNONCE et de la clé privée APPKEY, le serveur NS dérive la clé de chiffrement et d’intégrité NwkSKey (pour chiffrer la signalisation et calculer l’intégrité du message) et la clé de chiffrement des messages AppSKey.
  • LoRaWAN 1.0.4/1.1. Le serveur NS récupère l’identifiant JOINEUI et via une  requête DNS, recherche le serveur JS. Le serveur NS choisi une adresse LoRA DevADDR et défini les paramètres radioélectriques (liste des fréquences à utiliser, les délais entre l’émission et la réception pour la transmission de données) qui seront imposés au terminal. Le serveur NS transfère la requête du mobile (JoinRequest avec les informations DEVEUI, DevNONCE, JOINEUI) et les caractéristiques radioélectriques au JS. Le serveur JS vérifie l’existence du DEVEUI dans sa base de données. Le cas échéant, le NS vérifie la signature MIC avec la clé privée APPKEY. En cas de correspondance, le serveur JS choisit un numéro aléatoire AppNONCE. La payload est composée de la configuration des paramètres radios à appliquer au niveau du terminal, de l’adresse LoRa DevADDR et du numéro aléatoire AppNONCE. La payload chiffrée et protégée en intégrité est transmise par le serveur NS au serveur JS. A partir des valeurs DevNONCE et AppNONCE et de la clé privée APPKEY, le serveur JS dérive la clé de chiffrement et d’intégrité NwkSKey* (pour chiffrer la signalisation et calculer l’intégrité du message) et la clé de chiffrement des messages AppSKey. La clé NwkSKEY est transmise au serveur NS et la clé AppSKey est transmise au serveur AS.
  • Le serveur NS termine la transaction en transmettant au terminal le message JOINAccept. Le terminal vérifie la signature MIC. En cas de succès du contrôle d’intégrité, le terminal déchiffre la PAYLOAD et récupère la valeur AppNONCE. Le terminal dérive de son côté les clés de chiffrement et d’intégrité à partir de sa clé privée APPKEY, et des séquences DevNONCE et AppNONCE.

(*): NwkSKey : Dans le cas de LoRaWAN 1.0.4, il n’y a qu’une seule clé pour la signalisation. Dans le cas LoRaWAN 1.1, le JS calcule 3 clés : FNwkSintKey,  SNwkSintKey  et NwSEncKey (deux clé d’intégrité et une clé de chiffrement).

 

En fin d’activation, le NS et l’AS ont acquis les clés de chiffrement


Figure 11 : Procédure d’activation sur LoRaWAN 1.1

L’architecture LoRaWAN 1.1 permet de mettre en place un accord de HandOver Roaming(1)  en plus de l’accord de Passive Roaming. Le Passive Roaming est fonctionnelle sur LoRaWAN 1.0.x, cela consiste à autoriser le réseau visité à contrôler le terminal.

Pour le Passive Roaming, le terminal échange la signalisation avec le réseau Visité. Le NS du réseau visité est nommé Serving NS. Les messages sont ensuite relayés au hNS.

Pour le Handover Roaming, le NS du réseau visité relai les requêtes de signalisation vers le NS du réseau Home. Le NS du réseau visité se nomme fNS (Forward NS).

Le mobile peut être en Passive Roaming sur un réseau visité NS1 lequel autorise le mobile d’être en Handover Roaming sur un réseau visité NS2 (figure 12).

 


Figure 12 : L’architecture Handover Roaming/Passive Roaming (2)

 

Les messages MAC

Le protocole LoRa décrit le format des messages échangés entre le terminal et le serveur NS ainsi que les requêtes/réponse LoRaWAN. Les informations échangées sont chiffrées et une signature est rajoutée pour garantir l’intégrité des données.

Les évolutions des spécifications LoRaWAN 1.0.x ont introduits des messages pour supporter les terminaux de classe B en mode multicast.

La spécification LoRaWAN 1.1 a introduit des requêtes supplémentaires pour supporter le mode Handover Roaming et en améliorant la sécurité des données échangées entre le réseau visité et le réseau home.

Les différentes évolutions sont les suivantes :

  • LoRaWAN 1.0 publié en janvier 2015
  • 0.2 publié en Juillet 2016
  • 0.3 publié en 2018 supporte la communication en mode unicast & multicast pour les terminaux de classes B.
  • LoRaWAN 1.0.4 publié en Octobre 2020 améliore la sécurité
  • LoRaWAN 1.1 publié en Octobre 2017 présente deux méthodes de roaming

Quel que soit la spécification, le format des messages est identique.

L’entête de la couche physique se découpe en 5 champs :

Le Préambule permet de synchroniser le récepteur, le PHDR est l’en-tête Physique (Physical Header) contenant les indications suivantes : la taille de la PhyPayload en octets, le rendement de codage et la présence ou non du CRC.
Le CRC n’est transmis que dans le cas des messages montants.

Le champ PHYPayload démarre par une entête MAC (Mac HeaDeR) suivi du message MACPayload et une signature (MIC) validant l’intégrité du message :

Le champ MHDR contient le type de requête à transmettre :

Note : La requête Rejoin Request(3)  n’est définie que pour la version LoRaWAN1.1 .

Le champ MAC Payload contient une entête de trame « Frame Header FHDR » (contenant l’adresse source et l’adresse destination et un numéro de compteur), un numéro de port de trame,  et les données utiles FRMPayload.

  • FHDR : Frame Header, contient les champs DevAddr (adresse du noeud), FCtrl (octet de controle), FCnt (2 octets pour le compteur de trames), FOpts (entre 0 et 15 octets pour les options).
  • FPort : Frame Port pour déterminer si le message contient seulement des commandes MAC (vaut 0 dans ce cas) ou si les données sont spécifiques pour une application (contient alors son numéro)
  • FRMPayload : le message chiffré avant le calcul du code d’intégrité (MIC)

 

Conclusion

Les spécifications actuelles de LoRaWAN 1.0.4 ont permis d’améliorer les failles de sécurités qui avaient été relevées au niveau de LoRaWAN 1.0.2 afin de sécuriser les communications entre les terminaux et le cœur de réseau opérateurs.

Le serveur JS (Join Server) introduit au cours de la spécification LoRaWAN 1.1 (2017) pour la gestion du roaming est également présent dans la spécification LoRaWAN 1.0.4 (2020). Les spécifications LoRaWAN 1.0.x autorisent le Passive Roaming, la spécification LoRaWAN 1.1 autorise à la fois le passive roaming et le handover Roaming. Le serveur JS permet une plus grande flexibilité sur la gestion du Roaming et garanti l’indépendance des clés de chiffrement des données.

 

Notes:

(1) Dans la formation SE21, les différents accords de Roaming sont détaillés.

(2) Extrait du support de formation SE21

(3) La formation SE21 reprend  en détail l’ensemble des messages et la signalisation MAC.

 

Référence: https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/