Nouveau : le pare-feu IA surveille chaque module et explique chaque incident en termes simples. Découvrez comment ça marche

Fonctionnement de LoRaWAN dans Hermetry

Le parcours d'une trame LoRaWAN, du capteur aux passerelles, au serveur réseau et à un codec, jusqu'aux mesures de votre appareil.

Cette page explique ce qui se passe entre l’envoi d’une trame LoRaWAN par un capteur et l’apparition d’une mesure sur son appareil dans Hermetry. Lisez-la une fois avant d’ajouter des passerelles et des appareils ; la plupart des dépannages partent de ce schéma.

Les composants

ComposantRôle
Équipement final (capteur)Envoie de courtes trames radio (uplinks) et écoute brièvement les réponses (downlinks).
PasserelleReçoit toutes les trames LoRaWAN à portée et les transmet au serveur réseau via Internet. Elle émet aussi les downlinks. Une passerelle ne sait pas quels appareils vous appartiennent.
Serveur réseauServeur intégré à Hermetry. Il contrôle chaque trame, fusionne les copies reçues par plusieurs passerelles, conserve la session et les compteurs de l’appareil, gère la couche MAC (ADR et autres paramètres radio) et planifie les downlinks.
Serveur de jointurePartie du serveur réseau. Il répond aux demandes de jointure des appareils OTAA et crée leurs clés de session.
CodecTransforme les octets d’une trame en valeurs nommées, par exemple temperature et humidity.
FluxLes messages de vos appareils passent par le flux racine, qui enregistre les valeurs et exécute les règles d’alarme.

Les passerelles et les équipements finaux sont tous deux des appareils dans Hermetry. Une passerelle utilise le profil intégré LoRaWAN gateway ; un équipement final ajouté manuellement utilise le profil intégré LoRaWAN EU868 Class A OTAA (1.0.3). Les deux sont créés la première fois que vous en avez besoin.

D’un capteur à une mesure

  1. Le capteur envoie un uplink. Chaque passerelle à portée le reçoit.
  2. Chaque passerelle transmet sa copie, avec la puissance du signal (RSSI) et la qualité (SNR) qu’elle a mesurées, à l’adresse du serveur réseau de votre organisation.
  3. Le serveur réseau collecte les copies d’une même trame pendant une courte fenêtre (200 ms par défaut) et les fusionne en un seul uplink. Les copies ne sont fusionnées qu’au sein d’une même organisation : une trame reçue par la passerelle d’un autre client n’est jamais mélangée à la vôtre.
  4. Il contrôle la trame : l’adresse de l’appareil (DevAddr) doit appartenir à la session de l’un de vos appareils, le contrôle d’intégrité (MIC) doit réussir avec la clé de cette session, et le compteur de trames doit avancer. Une trame en échec est rejetée et affichée dans le journal des trames avec sa raison.
  5. Il traite les commandes MAC envoyées par l’appareil et décide si une réponse est nécessaire (un accusé de réception, une requête MAC ou un downlink en file d’attente).
  6. Il décode la charge utile applicative avec le codec de l’appareil. Sans codec, ou si le décodage échoue, la charge utile brute est transmise en hexadécimal sous la clé raw.
  7. Il écrit un message d’appareil pour l’uplink. Lorsque le paramètre de profil Ajouter les valeurs radio (lora.rssi, lora.snr, …) à chaque message est activé, le message contient aussi lora.rssi, lora.snr, lora.gw_count, lora.dr, lora.freq et lora.fcnt_up.
  8. Le message traverse votre flux racine comme tout message d’appareil. Le flux racine enregistre les valeurs.

Un uplink correspond à un seul message d’appareil, quel que soit le nombre de passerelles qui l’ont reçu. Les trames sur FPort 0 (commandes MAC uniquement) n’écrivent aucun message d’appareil.

Dédoublonnage

Plusieurs passerelles reçoivent souvent le même uplink. Le serveur réseau identifie chaque copie par votre organisation et par les octets exacts de la trame. La première copie ouvre un groupe ; les copies qui arrivent dans la fenêtre s’y ajoutent ; à la fermeture de la fenêtre, l’uplink est traité une seule fois, avec la liste de toutes les passerelles qui l’ont reçu. Une copie qui arrive après la fermeture de la fenêtre est comptée comme tardive et ignorée.

La meilleure passerelle (SNR le plus élevé, puis RSSI) sert aux valeurs radio du message et est le premier choix pour une réponse.

Jointures

Un appareil OTAA doit rejoindre le réseau avant de pouvoir envoyer des données. Sa demande de jointure passe par les mêmes passerelles et le même dédoublonnage. Le serveur de jointure contrôle le DevEUI, le JoinEUI, l’AppKey et le DevNonce de l’appareil, crée une session et renvoie une acceptation de jointure par la meilleure passerelle capable d’atteindre encore l’appareil à temps. Voir Comment un appareil rejoint le réseau.

Un appareil ABP ne rejoint pas le réseau. Sa session (adresse et clés) est saisie lors de son ajout.

Un appareil Class A n’écoute que pendant deux courtes fenêtres après chaque uplink (RX1 et RX2). Le serveur réseau choisit la passerelle et la fenêtre encore capables de transmettre, en fonction du temps d’aller-retour de la passerelle et de son budget de cycle d’utilisation (duty cycle). Un appareil Class C écoute en permanence, donc ses downlinks en file d’attente partent immédiatement. Voir Classes d’appareils et Envoi de downlinks.

Isolation entre organisations

Chaque DevEUI et chaque EUI de passerelle ne peut être enregistré qu’une seule fois sur l’ensemble de la plateforme. Lorsque vous essayez d’enregistrer un identifiant déjà détenu par une autre organisation, Hermetry indique qu’il est déjà utilisé et ne précise jamais qui le détient. Les trames des appareils d’une autre organisation captées par vos passerelles sont rejetées avec le motif « Un appareil d’un autre réseau », et aucune information sur cet appareil ne vous est montrée.

Ce qui n’est pas conservé

Le serveur réseau ne conserve qu’un court journal des trames (la dernière journée, 1 000 trames au maximum par organisation) et la dernière réception de chaque appareil. L’historique des réceptions n’est enregistré que si votre flux sauvegarde les clés lora.* avec les autres valeurs, ce que fait le flux racine par défaut lorsque le profil les ajoute au message.