Utilisation des relais LoRaWAN®

Cette page décrit les concepts de base des relais LoRaWAN® et comment ils sont intégrés de manière transparente avec ThingPark.

Qu'est-ce qu'un relais ?

Un relais LoRaWAN® est un capteur qui transfère vers le réseau les trames uplink LoRaWAN® reçues de Capteurs finaux de confiance, en les encapsulant dans les payloads de ses propres trames. De même, le relais reçoit des trames downlink encapsulées du réseau et les transmet aux capteurs finaux appropriés après décapsulation.

Les relais offrent un moyen pratique, fiable et économique de couvrir les zones blanches pour les capteurs situés en périphérie de la couverture RF fournie par les passerelles conventionnelles. Cela pourrait être le cas pour les capteurs situés profondément à l'intérieur des bâtiments, dans des sous-sols ou même à l'intérieur d'armoires métalliques. Un exemple typique concerne les cas d'utilisation de télérelèves intelligentes, où le déploiement d'un relais élimine le besoin d'opérations coûteuses au pied des compteurs pour collecter les relevés dans les zones blanches.

De plus, d'un point de vue opérationnel, les relais sont particulièrement utiles dans les zones où il n'est pas possible/pratique d'ajouter des passerelles pico ou nano, soit en raison d'un manque d'approvisionnement en énergie ou d'options de Backhaul. En effet, contrairement aux passerelles conventionnelles, les relais sont alimentés par batterie et utilisent l'interface radio de LoRaWAN comme solution de Backhaul.

Les relais LoRaWAN® ont une architecture similaire à celle des capteurs conventionnels LoRaWAN, ils sont souvent (mais pas nécessairement) alimentés par batterie. Comme n'importe quel capteur conventionnel, un relais peut utiliser n'importe quelle classe LoRaWAN (classe A, B, C) et peut utiliser les modes d'activation OTAA ou ABP.

Un relais peut sécuriser jusqu'à 16 capteurs finaux. Les capteurs servis exclusivement par les relais ne peuvent utiliser que le mode classe A.

Mécanismes de Wake-on-Radio (WOR) et de Détection d'Activité Canal (CAD)

Pour préserver sa batterie, le relais ne peut écouter en permanence les messages entrants potentiels. Par conséquent, le protocole relais LoRaWAN® standard défini dans TS011 définit deux mécanismes :

• Wake-on-Radio (WOR) : cette trame uplink est envoyée par le capteur pour réveiller le relais et fournir des informations sur la trame uplink suivante (régulière) afin que le relais puisse ajuster son récepteur à la bonne fréquence RF et au bon débit de données.

• Détection d'Activité Canal (CAD) : la principale caractéristique de la trame Wake-on-Radio (WOR) est sa durée de préambule qui peut atteindre 1 seconde. Ce long préambule permet au relais de dormir et de ne se réveiller que périodiquement pour rechercher une activité radio. La périodicité CAD par défaut est de 1 seconde.

  

Flux de messages typiques en mode relais

1. Pour réveiller le relais à proximité, le capteur doit diffuser une trame WOR sur un canal WOR prédéfini (régional-spécifique). Dans cette trame WOR, le capteur fournit la fréquence et le débit de données de sa trame uplink suivante.
2. Si le relais a authentifié avec succès le capteur (en validant le WOR MIC), il peut acquitter cette trame WOR en envoyant un WOR ACK.
   Les WOR ACKs sont utiles pour la synchronisation temporelle entre le relais et le capteur (réduisant ainsi la longueur du préambule WOR pour économiser la batterie). Ils permettent également au capteur d'apprendre les informations de transmission du relais : le débit de données UL utilisé entre le relais et le réseau, si la limite de transmission a été atteinte...
3. Le capteur envoie le paquet uplink. Cela est une trame régulière LoRaWAN®, pas spécifique au protocole relais. En dehors du relais, toute passerelle à proximité peut démoduler et transmettre cette trame uplink régulière au réseau (ainsi, la diversité macro RF est entièrement supportée).
4. Après avoir capturé le paquet uplink du capteur, le relais l'encapsule dans la payload de sa trame MAC et y ajoute les métadonnées uplink du capteur (débit, fréquence, RSSI et SNR mesurés par le relais...). Ensuite, le relais envoie cette trame uplink encapsulée via LoRaWAN® FPort 226. La fréquence et le débit de données utilisés par le relais pour cette transmission ne sont pas nécessairement ceux utilisés par le capteur.
   Du côté cœur de réseau, le "network server" décapsule le paquet uplink du relais afin d'extraire le paquet d'origine du capteur, puis il traite normalement le paquet uplink : duplication de paquet, ADR, commandes MAC, envoi d'un ACK aux uplinks confirmés, compte rendu aux serveurs d'application...
5. Si le réseau a un paquet downlink à envoyer au capteur, il doit l'encapsuler et l'envoyer au relais, en utilisant toujours le FPort 226. Ce paquet encapsulé doit être envoyé sur les créneaux RX1 ou RX2 du relais.
6. Le relais reçoit le paquet downlink encapsulé et en extrait la payload physique originale du capteur. Puis, il achemine cette payload vers le capteur via un créneau RX spécifique au relais appelé RXR. Le créneau RXR s'ouvre 18s après la fin de la transmission uplink du capteur. Le paquet downlink envoyé sur le créneau RXR utilise la même fréquence que la trame WOR et réutilise le même taux de transfert de données que le dernier paquet uplink LoRaWAN® du capteur.

Le diagramme suivant montre le flux de bout en bout pour les capteurs OTAA rejoignant le réseau via un relais :

• ForwardUplinkReq/ForwardDownlinkReq sont les paquets UL/DL du capteur encapsulés par le relais et transmis au réseau via FPort 226.
• UpdateUplinkLinkReq est une commande MAC spécifique au relais envoyée par le network server pour configurer le relais avec le DevAddr du capteur final et la clé du relais. Il permet au relais d'ajouter ce capteur à sa liste de capteurs de fiabilité et d'authentifier ses trames WOR suivantes.

note

Pendant son cycle de Join, le capteur diffuse des trames WOR spécifiques qui ne peuvent pas être vérifiées/acquittées par le relais. C'est parce que la clé du capteur utilisée par le relais pour authentifier les trames WOR est dérivée de la clé de session du réseau du capteur, donc elle ne devient disponible pour le relais qu'après la réussite de la procédure de Join.

Principaux pré-requis

Pour les capteurs fonctionnant derrière un relais

Il n'y a pas de pré-requis matériels particuliers pour qu'un capteur utilise le protocole relais.

D'un point de vue logiciel, les capteurs fonctionnant derrière un relais doivent supporter la pile relais dans leur logiciel. Cette pile permet à ces Capteurs d'utiliser le protocole radio standard défini dans TS011 pour communiquer avec les relais et le serveur du Cœur de réseau.

Pour les relais

D'un point de vue logiciel, les relais doivent évidemment supporter la pile appropriée permettant le protocole radio défini dans TS011.

D'un point de vue matériel, étant donné qu'un relais échangera beaucoup plus de trafic LoRaWAN avec le réseau que les capteurs conventionnels, les relais alimentés par batterie devraient avoir une plus grande capacité pour leur batterie. Le dimensionnement exact de la batterie du relais dépend du nombre de capteurs qu'il sert (jusqu'à 16) et du profil de trafic qu'il est censé relayer. Pour en savoir plus sur les besoins énergétiques des relais et des capteurs, consultez le calculateur de consommation énergétique.

Les autres exigences matérielles pour le relais incluent :

• Plus de RAM et d'espace flash que les capteurs conventionnels, pour permettre le stockage des clés de session de ses capteurs de fiabilité.
• Un oscillateur à cristal compensé en température (OCCT) est recommandé pour réduire la dérive de l'horloge.

Provisioning des relais sur ThingPark

Dans la version actuelle, les relais sont provisionnés comme n'importe quel capteur conventionnel. Pour en savoir plus sur cette procédure, consultez Activation de nouveaux capteurs.

Par conséquent, vous n'avez pas besoin d'aucune configuration spéciale pour permettre à un capteur provisionné d'agir comme un relais. De plus, il n'est pas nécessaire d'associer statiquement les capteurs finaux aux relais : la liste des capteurs finaux de confiance que chaque relais peut desservir est automatiquement configurée par le network server et envoyée au relais par voie radio.

La fonctionnalité de séparation de trafic multi-entités de ThingPark Enterprise s'applique aux relais : un relais appartenant à un abonnement ThingPark ne peut servir que des capteurs appartenant à ce même abonnement, pas ceux appartenant à d'autres abonnements, à moins que plusieurs abonnements ne partagent leur réseau radio via le même SegregationID ou le même NetID supérieur à 0x000001.

Une fois provisionné, un relais peut transmettre des paquets uplink de capteurs via FPort 226. Ces paquets transmis ne sont pas envoyés au(x) serveur(s) d'application associé(s) à ce relais, afin d'éviter de saturer les serveurs d'application si le relais agit comme un capteur régulier (rapport de données aux applications) en plus de sa fonction de relais.

Cas d'utilisation supportés et limitations connues

Les cas d'utilisation suivants sont supportés :

• Les capteurs OTAA sous la couverture exclusive d'un ou plusieurs relais.

  En cas de plusieurs relais, le relais le plus proche du capteur final est sélectionné par le network server. Ce meilleur relais est sélectionné en fonction du bilan de liaison capteur/relais, évalué pendant le cycle de Join du capteur en comparant l'ESP de chaque relais transmettant le message Join-Request du capteur.

  Important

  Pour éviter les collisions d'ACK WOR, un capteur final ne peut pas être associé à plus d'un relais en même temps.

• Les capteurs OTAA sous une couverture mixte de passerelles conventionnelles et de relais.

  Dans ce cas, les paquets uplink reçus par les passerelles conventionnelles (mode direct) + le meilleur relais (mode relais) sont dédupliqués par le "network server". Pour maximiser le taux de réussite de livraison des paquets downlink, dans la mesure du possible, le network server exploite le mode mixte pour envoyer des downlinks au capteur via à la fois la meilleure passerelle de service (sur le créneau RX1 ou RX2 du capteur) et le relais (sur le créneau RXR).

• Grâce au mode de découverte automatique supporté par le protocole relais LoRaWAN, les capteurs finaux peuvent être desservis en mode relais sans initier un nouveau cycle de join. Exemple de cas d'utilisation :

  • Un nouveau relais est installé à proximité d'un capteur existant pour améliorer sa couverture RF.
  • Un capteur final mobile entre dans la zone de couverture du relais.
  • Remplacement de relais, par exemple en raison d'une panne matérielle.

  Cette découverte automatique repose sur le fait que le relais notifie le network server de la présence d'un nouveau Capteur via la commande MAC NotifyNewEndDeviceReq.

  Lorsqu'un nouveau relais est déployé pour améliorer la couverture radio d'un capteur existant déjà servi par un autre relais, le capteur passe au nouveau relais sans initier un nouveau cycle de Join.

Les limites suivantes s'appliquent à la version 8.0 de ThingPark :

• Seuls les capteurs finaux OTAA peuvent se connecter à ThingPark via un relais, le mode ABP n'est pas encore supporté.
• Parmi les commandes MAC spécifiques au relais définies dans la spécification technique LoRaWAN TS011, seules les paires UpdateUplinkListReq/Ans, NotifyNewEndDeviceReq/Ans et CtrlUplinkListReq/Ans sont actuellement supportées. D'autres commandes MAC seront supportées dans ThingPark 8.1.
• Étant donné que la paire de commandes MAC RelayConfReq/Ans n'est pas encore supportée, le mode relais doit être activé localement dans les capteurs agissant comme relais.
• Seul le canal WOR par défaut est supporté, car les commandes MAC nécessaires pour configurer un second canal WOR ne sont pas encore supportées dans cette version.
• En raison d'une limitation connue du protocole relais LoRaWAN v1.0, le mécanisme de découverte automatique basé sur la commande MAC NotifyNewEndDeviceReq ne fonctionne pas efficacement en cas de collision de DevAddr (c'est-à-dire lorsque le même DevAddr est partagé entre plusieurs Capteurs). Par conséquent, si le DevAddr inclus dans la notification du relais est utilisé par plus d'un DevEUI attaché au même abonnement que le relais lui-même, le "network server" ignore la commande NotifyNewEndDeviceReq.

Analyse du trafic des relais sur ThingPark

Les utilisateurs de ThingPark peuvent surveiller et analyser le trafic des relais via l'application Wireless Logger.

• Le trafic du capteur est associé au DevEUI/DevAddr du capteur.
  Le trafic relayé peut être identifié par le symbole F sur son logo ; tel que et pour les paquets uplink et downlink respectivement. F signifie "Transféré".
  De plus, l'ID du relais utilisé pour transmettre le paquet est explicitement indiqué dans la colonne "Relay ID", cet ID se réfère au DevEUI du relais.

• Le trafic UL/DL encapsulé envoyé par le relais est associé au DevEUI/DevAddr du relais. Ce trafic peut être facilement identifié par le champ FPort - affichant 226 Relay.
  Pour simplifier l'analyse du trafic, WLogger affiche le contenu des payloads ForwardUplinkReq et ForwardDownlinkReq au format décodé. La même chose s'applique également au contenu des commandes MAC spécifiques au relais.

  

La capture d'écran suivante montre un exemple typique d'un capteur OTAA rejoignant le réseau à travers un relais. La séquence commence par le relais lui-même rejoignant le réseau.

Voici un exemple de paquets uplink/downlink échangés entre le capteur et le réseau à travers un relais :

Pour en savoir plus sur l'utilisation de l'application Wireless Logger, consultez guide de l'utilisateur Wireless Logger.

Consommation d'énergie

Utilisez le calculateur de consommation d'énergie pour évaluer la durée de vie de la batterie du relais LoRaWAN et des capteurs relayés à partir d'estimations de consommation d'énergie (décomposées en estimations spécifiques pour la synchronisation Wake on Radio, Tx/Rx, sommeil et fuite de batterie).