Exploitation des relais LoRaWAN® dans ThingPark

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 mécanisme de meilleure sélection de relais repose sur un ensemble de critères, tels que le bilan de liaison entre le capteur et le relais, ainsi que le nombre de capteurs actuellement servis par chaque relais (afin d’équilibrer la charge).

  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 limitations suivantes s’appliquent à la version 8.1 de ThingPark :

• Seuls les capteurs OTAA peuvent se connecter à ThingPark via un relais, le mode ABP n’est pas encore supporté.
• La commande MAC EndDeviceConfReq n’est pas encore supportée dans la version actuelle, mais toutes les autres commandes MAC spécifiées dans TS011 sont supportées.
• Seul le canal WOR par défaut est supporté, car la commande MAC requise pour configurer un second canal WOR sur le capteur n’est pas encore supportée dans cette version.

Provisionnement des relais

À partir de la version 8.1, pour tirer pleinement parti de la fonctionnalité de relais, les capteurs fonctionnant en tant que relais doivent être associés à un modèle où le mode relais est activé. Par exemple, le modèle Abeeway Compact Relay inclus dans le catalogue a la fonctionnalité de relais activée dans son profil de capteur :

Pour provisionner un relais LoRaWAN sur ThingPark, vous devez :

1. Appliquer toutes les étapes décrites dans Activer de nouveaux capteurs, tout en sélectionnant le Modèle ayant la fonctionnalité de relais activée via le profil de capteur.

2. Une fois que votre capteur relais est provisionné, si vous souhaitez personnaliser sa configuration par défaut, vous pouvez accéder à sa page détaillée, puis cliquer sur l’onglet Relay pour le configurer comme décrit dans Configurer les relais.

Une fois provisionné, un relais peut transférer des paquets uplink provenant de capteurs sur le 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.

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.

Configuration des relais

Association transparente des capteurs aux relais

Il n’est pas nécessaire d’associer statiquement les capteurs aux relais :
la liste des capteurs de confiance que chaque relais peut servir est automatiquement configurée par le network server et envoyée au relais par liaison radio.

1. Accédez à l’onglet Relay du capteur que vous souhaitez configurer.

   note

   Le mode relais est automatiquement activé après le provisionnement du relais. Si vous ne souhaitez pas l’activer immédiatement, cliquez sur le bouton DISABLE THE RELAY dans le widget WOR CONFIGURATION.

2. Dans le widget WOR CONFIGURATION, définissez les paramètres suivants (ils sont transmis au relais via la commande MAC RelayConfReq) :

   1. Périodicité CAD : ce paramètre définit le délai entre deux analyses consécutives de détection d’activité de canal (CAD) sur chaque canal WOR. Le paramétrage par défaut est de 1 seconde. L’utilisation de valeurs plus faibles augmente la consommation de batterie du relais.

   2. Canal par défaut : ce paramètre définit l’index du canal WOR par défaut. Le document LoRaWAN Regional Parameters (RP002) définit deux index de canal (avec leurs fréquences) pour le canal par défaut dans chaque profil régional.

   3. Configuration du second canal : si elle est activée, l’utilisateur doit définir la fréquence, le data rate et l’offset de fréquence WOR-ACK de ce second canal.
      Si le second canal est activé, le relais alterne les balayages CAD entre le canal par défaut et le second canal, comme décrit dans TS011.

      prudence

      L’utilisation d’un second canal WOR est actuellement soumise à restriction car la commande MAC EndDeviceConfReq n’est pas encore supportée dans la version actuelle.

3. Dans le widget FORWARD/FILTER JOIN-REQUEST RULES, vous pouvez éventuellement configurer une liste blanche et/ou une liste noire de paires JoinEUI-DevEUI. Ces règles sont transmises au relais dans la commande MAC FilterListReq.

   astuce

   Pour ajouter une règle, cliquez sur , tandis que pour supprimer une règle, cliquez sur .

   • La première règle (index 0) est obligatoire et ne peut pas être supprimée : elle définit le comportement par défaut pour tous les messages Join-Request qui ne correspondent à aucune autre règle.
   • Les règles avec les index 1-15 sont optionnelles et peuvent être ajoutées/mises à jour/supprimées à tout moment : elles définissent le comportement à appliquer aux messages Join-Request correspondant aux paires JoinEUI/DevEUI.
     • Forward signifie que le relais doit accepter les messages Join Request correspondant à la paire JoinEUI/DevEUI, tandis que Filter signifie que le relais doit les rejeter.
     • Vous pouvez définir un préfixe JoinEUI en définissant les octets de gauche sans remplir les 16 caractères hexadécimaux, mais dans ce cas vous ne pouvez pas définir de DevEUI pour cette même règle.

   

4. Dans le widget FORWARDING LIMITATIONS, vous pouvez modifier les paramètres par défaut liés aux seaux de jetons de relais.
   Ce mécanisme est défini dans TS011 afin de permettre aux relais d’optimiser leur consommation de batterie et de limiter la quantité de trafic transféré. Pour chaque type de trafic pour lequel la limitation est activée, le relais ne transfère l’uplink que lorsqu’il lui reste au moins 1 jeton pour ce type de message, et il décrémente le seau associé de 1 jeton après chaque transmission.
   Si les limites de transfert sont différentes des paramètres par défaut, elles sont transmises au relais dans la commande MAC ConfigureFwdLimitReq.

   • Le paramètre "Reset token counters" indique au relais de réinitialiser (ou non) tous les compteurs de jetons.
   • Pour chaque type de trafic LoRaWAN transféré par le relais : si vous ne souhaitez pas limiter ce trafic, activez l’option Unlimited forwarding. Sinon, définissez le taux de rechargement horaire cible et la taille maximale du seau pour chaque cas.
   • Outre les limitations de transfert par type de trafic, une limite globale s’applique à tous les types, en agrégeant tous les messages uplink transférés. C’est le périmètre des paramètres définis sous Global limit. Par conséquent, cette limite ne doit jamais être définie en dessous de la plus grande limite individuelle définie dans les sections précédentes.

Supervision des relais

Recherche de relais dans la liste des capteurs

Dans la liste des capteurs, la colonne Relay indique si le capteur peut agir en tant que relais (capacité de relais) et si l’activité de relais est activée (activation du relais).

• Not supported : le modèle de capteur ne supporte pas la fonctionnalité de relais. cette information est héritée du profil de capteur associé à chaque modèle de capteur.
• Disabled : le modèle de capteur supporte la fonctionnalité de relais mais cette fonctionnalité est actuellement désactivée pour ce capteur.
• Enabled : le modèle de capteur supporte la fonctionnalité de relais et cette fonctionnalité est actuellement activée pour ce capteur.

Pour filtrer facilement les capteurs en fonction de leur statut de relais, utilisez les cases à cocher disponibles en bas du formulaire de filtrage de capteurs (Not supported et Disabled sont regroupés pour plus de simplicité) :

De plus, sur la carte des capteurs, les relais sont représentés par un marqueur distinct (la couleur du marqueur dépend de la métrique affichée) :

• La fonctionnalité de relais est supportée mais désactivée :
• La fonctionnalité de relais est supportée et activée :

Affichage des capteurs servis par chaque relais

La liste des capteurs de confiance associés à chaque relais est affichée dans le widget SERVED DEVICES de l’onglet Relay.

Analyse du trafic de relais dans WLogger

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, comme et pour les paquets uplink et downlink respectivement. F signifie "Forwarded".
  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.

  note

  En cas de couverture mixte, pour un capteur donné, via des passerelles directes et via des relais :

  • Les paquets uplink reçus à la fois par une passerelle et par un relais apparaissent une seule fois dans WLogger : seul le message reçu par la passerelle est affiché puisqu’il arrive en premier au network server, la copie reçue via le relais étant dédupliquée par le réseau.
  • Les paquets downlink envoyés à la fois via la passerelle et via le relais apparaissent deux fois dans WLogger : la transmission via la passerelle est associée à la fenêtre RX1 ou RX2, tandis que la transmission via le relais est associée à la fenêtre RXR et marquée RXR repetition dans WLogger.

• 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é. Il en va de même pour le contenu des commandes MAC spécifiques aux 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 le guide utilisateur Wireless Logger.