Paquets unicast LoRaWAN® Downlink

Ce sujet décrit des informations de référence sur les paquets unicast LoRaWAN® en downlink.

Paquets Downlink

Les paquets non adressés de Downlink sont des paquets LoRaWAN® envoyés par les passerelles à un seul capteur, soit directement, soit via un relais LoRaWAN®. Ils sont représentés dans Wireless Logger par des icônes violettes :

• illustre un paquet unicast de downlink régulier.
• illustre le cas d'un paquet unicast de downlink envoyé en réponse à un paquet uplink répété qui est invisible dans Wireless Logger (en raison de la déduplication des paquets). Pour en savoir plus, consultez Downlinks generated for a repeated uplink.
• illustre le cas d'un paquet unicast de downlink envoyé dans le cadre d'un accord d'itinérance passive avec un réseau LoRaWAN® pair (R signifie itinérance). Pour en savoir plus, voir Paquets d'itinérance passive.
• illustre le cas d'un paquet unicast de downlink acheminé vers le capteur via un relais LoRaWAN. F signifie "Transmis". Pour en savoir plus, consultez Using LoRaWAN relays.

En cas d'échec de transmission, c'est-à-dire que le paquet Downlink n'a pas pu être transmis avec succès par la passerelle sur l'air, un point rouge s'affiche sur l'icône.

• Exemple : , ou .
• La cause détaillée de l'échec de la livraison est affichée dans le panneau extensible.
• Pour en savoir plus, consultez Downlink delivery failure causes.

Vous pouvez voir et filtrer plusieurs catégories de paquets Downlink dans Wireless Logger en fonction de leur contenu. Une trame est un paquet.

Paquet Downlink	Contenu	Description
	Trames MAC	Lorsqu'un paquet downlink est étiqueté mac uniquement, cela signifie que le paquet ne contient aucun payload applicatif provenant du serveur d'application. Ces paquets sont soit des paquets Downlink transportant uniquement des commandes MAC LoRaWAN® de couche 2 et/ou des accusés de réception MAC à des paquets Uplink confirmés précédents.
	Trames de données	Ces paquets contiennent un payload applicatif généré par des serveurs d'application mais ne contiennent aucune commande MAC.
	Trames MAC + Données	Ces paquets downlink contiennent à la fois des commandes/accusés de réception MAC et un payload applicatif.
	Join Accept frames	Ces paquets downlink ne concernent que les capteurs OTA.

Downlinks générés pour un uplink répété

Lorsque le même paquet d'Uplink est transmis plusieurs fois par le capteur (c'est-à-dire la répétition de trame), une seule copie de ce paquet d'Uplink est visible dans le Wireless Logger et envoyée aux serveurs d'application grâce au mécanisme de dé-duplication LRC.

Cependant, chaque transmission individuelle d'Uplink par le capteur permet deux créneaux de planification vers le bas (RX1 et RX2), le LRC peut envoyer des paquets de Downlink sur les créneaux RX1 ou RX2 d'un paquet d'Uplink répété.

Pour éviter toute ambiguïté :

• Downlinks pour un uplink répété indique que le paquet downlink en question est envoyé en réponse à un paquet uplink qui est masqué par la déduplication.

• Dans le panneau extensible, LoRaWAN® MType est suivi de (généré pour un UL répété).

  

Causes des échecs de livraison Downlink

Pour chaque transmission de Downlink du réseau vers le capteur, Wireless Logger affiche les informations suivantes dans le panneau extensible :

• Statut Downlink, avec deux valeurs possibles :

  • Envoyé : Si le paquet downlink a été transmis avec succès par la passerelle LRR.

    

    Dans l'exemple de la capture ci-dessus, bien que le statut de livraison soit Envoyé, Wireless Logger affiche une cause d'échec sur RX1 car le paquet downlink a été envoyé sur RX2 au lieu de RX1. Dans ce cas spécifique, le choix RX2 est déterminé par l'algorithme de sélection LRC RX1/RX2 (également connu sous le nom d'optimisation RX2).

    note

    Une transmission réussie par la passerelle ne garantit pas une réception réussie par le capteur car le paquet de Downlink pourrait être perdu par voie aérienne (en raison d'une collision par exemple ou d'une mauvaise couverture de fréquence radio).

  • Échec: Si le paquet downlink n'a pas pu être envoyé par la passerelle LRR. Dans ce cas, la cause de l'échec de la livraison sur RX1 et RX2 (et le pingslot pour les capteurs de classe B) est indiquée par Wireless Logger comme illustrée par l'exemple suivant pour un capteur de classe A :

    

• Cause de l'échec de la livraison sur RX1, RX2 et Pingslots.

  Rappel Les paquets de Downlink peuvent être programmés sur les créneaux RX1 et classe-A-RX2 pour toutes les classes de capteurs (A/B/C). Ils peuvent également être programmés sur la fenêtre RX2 étendue pour les capteurs de classe C et les pingslots des capteurs de classe B.

Le tableau suivant détaille les différentes causes d'échec de livraison sur RX1/RX2/Pingslots, pour les Downlinks unicast et multicast :

Valeur de la cause	Nom de la catégorie
Erreurs de livraison par voie aérienne pour le créneau RX1 de Downlink (toutes classes de capteurs)	Créneau de transmission occupé sur RX1 - (A0) Radio arrêtée - (A1) Radio downlink arrêtée - (A3) Radio occupée - (A4) Écoutez avant de parler - (A5) Erreur de carte radio - (A6) Cause d'échec spécifique pour Semtech basics station packet forwarder Reçu trop tard pour RX1 - (B0) Trop tard pour RX1 LRC sélectionne RX2 - (C0) LRC a sélectionné RX2 Rapport cyclique (DC) ou contrainte de passerelle sur RX1 - (D0) Contrainte de rapport cyclique détectée par LRR - (DA) Contrainte de rapport cyclique détectée par LRC - (DB) Contrainte de temps de séjour maximal détectée par le LRC - (DE) DC non autorisé par l'opérateur de peering (applicable uniquement au trafic d'itinérance passive) - (DF) Mauvais NetID (c'est-à-dire que le NetID du capteur ne correspond pas au NetID associé à aucune passerelle éligible) Trame supprimée de la file d'attente du downlink - (E1) File d'attente pleine - (E2) FCntDn invalide - (E3) Temps de validité expiré - (E4) Réinitialisation de la file d'attente suite à une reconnexion (c'est-à-dire que les paquets en attente sont supprimés)
Erreurs de livraison par voie aérienne pour le créneau RX2 de Downlink (toutes classes de capteurs)	Créneau de transmission occupé sur RX2 - (A0) Radio arrêtée - (A1) Radio downlink arrêtée - (A3) Radio occupée - (A4) Écoutez avant de parler - (A5) Erreur de carte radio - (A6) Cause d'échec spécifique pour Semtech basics station packet forwarder Reçu trop tard pour RX2 - (B0) Trop tard pour RX2 Rapport cyclique (DC) ou contrainte de passerelle sur RX2 - (D0) Contrainte de rapport cyclique détectée par LRR - (DA) Contrainte de rapport cyclique détectée par LRC - (DB) Contrainte de temps de séjour maximal détectée par le LRC - (DE) DC non autorisé par l'opérateur de peering (applicable uniquement au trafic d'itinérance passive) - (DF) Mauvais NetID (c'est-à-dire que le NetID du capteur ne correspond pas au NetID associé à aucune passerelle éligible)
Erreurs de livraison par voie aérienne pour le créneau RX2 de Downlink (uniquement pour les capteurs de classe C)	Classe C - Trame expirée avant la transmission - (E0) Délai maximal pour la classe C (60 secondes), c'est-à-dire que le paquet de classe C n'a pas pu être envoyé par le réseau en raison d'un délai d'attente.
Erreurs de livraison par voie aérienne pour les pingslots (uniquement pour les capteurs de classe B)	Créneau de transmission occupé sur le pingslot - (A0) Radio arrêtée - (A1) Radio de Downlink arrêtée - (A2) Pingslot non disponible (c'est-à-dire qu'aucun pingslot libre n'a été trouvé après plusieurs tentatives sur deux périodes de beacon) - (A3) Radio occupée - (A4) Écouter avant de parler - (A5) Erreur de carte radio Reçu trop tard pour le pingslot - (B0) Trop tard pour le pingslot Cycle d'activité (DC) ou contrainte de passerelle sur le pingslot - (D0) >Contrainte de cycle d'activité détectée par LRR - (D9) Aucun LRR éligible trouvé car tous ont été éliminés par le LRC - (DA) Contrainte de cycle d'activité détectée par LRC - (DB) Contrainte de temps de séjour maximale détectée par le LRC - (DC) Aucun LRR synchronisé GPS détecté par le LRC - (DD) Aucun LRR connecté détecté par le LRC - (DF) Mauvais NetID (c'est-à-dire que le NetID du capteur ne correspond pas au NetID associé à une passerelle éligible)

Colonnes des métadonnées Downlink

Les métadonnées sont une série d'informations liées à la transmission ou à la réception de chaque paquet. Pour plus d'informations, voir Uplinks passifs roaming LoRaWAN®.

Les métadonnées downlink les plus importantes sont affichées directement comme des colonnes distinctes dans Wireless Logger et sont listées dans le tableau suivant. Pour plus d'informations sur les autres métadonnées affichées dans le panneau extensible du paquet, voir Downlink expandable panel.

Dans le contenu du paquet downlink, ACK flag = 1 signifie que le paquet downlink accuse réception par le réseau du dernier paquet uplink.

Cet ensemble de métadonnées s'applique également aux Downlinks multicast et d'itinérance passive. Pour plus d'informations, voir Downlink LoRaWAN® multicast packets et Passive roaming LoRaWAN® packets.

Métadonnées	Description
Direction du message	Les icônes rouges montrent le paquet downlink (du LRC vers le capteur).
Type de message	data indique que le paquet contient un payload applicatif envoyé par le serveur d'application au capteur (p. ex. message de configuration, commande d'actionneur, etc.). mac indique que le paquet contient certaines commandes de service de couche MAC (modification ADR, etc.). rejoindre indique le message d'acceptation Join (pour les capteurs OTAA). Voir Downlink packets pour plus de détails.
Horodatage UTC	Horodatage UTC, utilisant le format ISO 8601.
Horodatage local	Horodatage traduit dans le fuseau horaire du navigateur, utilisant le format ISO 8601.
DevAddr	Adresse du capteur (4 octets).
DevEUI	Device EUI (8 octets) est un identifiant global de capteur dans l'espace d'adressage IEEE EUI64 qui identifie de manière unique le capteur. Si le network server agit comme forwarding network server (fNS) et que le type de message est data, le DevEUI n'est disponible que si la version des LoRaWAN® Backend Interfaces est > 1.0.
FPort	Port d'application du paquet.
NFCnt	Compteur de trames downlink maintenu par le network server LRC. - Pour LoRaWAN® 1.0.x : NFCnt est rempli avec le compteur de trames downlink (toujours présent). - Pour LoRaWAN® 1.1 : NFCnt est rempli avec la valeur NFCntDown (peut être vide si le paquet downlink contient un payload applicatif).
AFCnt	Compteur de trames downlink maintenu par le serveur d'application. - Pour LoRaWAN® 1.0.x : toujours vide. - Pour LoRaWAN® 1.1 : AFCnt est rempli avec la valeur AFCntDown (peut être vide si la trame downlink ne contient pas de payload applicatif).
SF/DR	Facteur d'étalement ou débit binaire du paquet downlink.
Sous-bande	Sous-bande de fréquence radio correspondant au canal logique utilisé pour transmettre le paquet de Downlink au capteur.
Canal	Canal logique utilisé pour transmettre le paquet de Downlink par le capteur. Remarque La légende de couleur suivante s'applique aux paquets de Downlink : - Lorsque le paquet de Downlink est envoyé sur le créneau RX1, le LC-ID s'affiche sur fond blanc. - Lorsque le paquet de Downlink est envoyé sur le créneau RX2, le LC-ID s'affiche sur fond orange. - Lorsque le paquet de Downlink est envoyé sur un pingslot de classe B, le LC-ID s'affiche sur fond bleu.
LRC Id	Identifiant du network server LRC.
Relay Id	DevEUI du relais qui a transmis le paquet downlink à l'équipement final.
LRR ID	ID du meilleur LRR envoyant le paquet de Downlink au capteur. Pour le cas d'utilisation en itinérance (itinérance passive sNS), l'identifiant LRR correspond à l'identité de la meilleure passerelle étrangère si cet identifiant a été signalé par fNS, sinon un identifiant LRR virtuel est affiché dans le Wireless Logger.

Panneau extensible Downlink

Les éléments suivants sont affichés dans le panneau extensible pour chaque paquet de downlink LoRaWAN®. Pour accéder au panneau extensible, cliquez sur sur le côté gauche du paquet.

Cet ensemble de métadonnées s'applique également aux Downlinks multicast et d'itinérance passive. Pour plus d'informations, voir Downlink LoRaWAN® multicast packets et Passive roaming LoRaWAN® packets.

Champ	Description
Mtype	Indique le type de paquet : ConfirmedDataDown, UnConfirmedDataDown, JoinAccept : - L'acceptation de Join est envoyée par le serveur Join LoRaWAN® pour accorder l'accès aux capteurs OTAA. Il permet au capteur de dériver les clés de session et d'acquérir les paramètres de fréquence radio obligatoires configurés dans le réseau. Il est affiché dans Wireless Logger avec le logo et le type de message (Mtype) comme JoinAccept. Note Le contenu du message Join Accept est affiché sous forme cryptée par Wireless Logger. - Si le paquet de Downlink nécessite un accusé de réception par le capteur, il est envoyé en mode CONFIRMÉ. Dans ce cas, Wireless Logger affiche le type de message (Mtype) comme ConfirmedDataDown. - Autrement, les paquets de Downlink peuvent être envoyés en mode NON CONFIRMÉ, signifiant que le capteur n'est pas tenu d'envoyer un accusé de réception au réseau pour ses données de downlink. Cela correspond au type de message UnconfirmedDataDown.
Drapeaux	Drapeaux de la couche MAC disponibles dans l'en-tête de trame (pour plus de détails, voir la spécification LoRaWAN® 1.0.3 MAC Layer) : - ADR : toujours réglé à 1 si la commande LinkADRReq est supportée dans le profil du capteur. - ACK : réglé à 1 si le paquet contient un accusé de réception du paquet uplink précédent, 0 sinon. - ADRACKReq : non pertinent pour les paquets downlink. - FPending : défini par le réseau pour informer le capteur que d'autres paquets downlink sont en attente de transmission côté réseau.
MAC (hex)	Contient les commandes MAC downlink au format hexadécimal, suivies du contenu décodé de chaque commande MAC.
Données (hex)	Contient le payload applicatif downlink au format hexadécimal. Remarque Ce payload peut être masqué pour des raisons de confidentialité. Pour en savoir plus, voir Affichage des Payloads décodés. L'état de chiffrement du Payload (chiffré vs non chiffré) est affiché entre crochets.
Métadonnées du driver	Métadonnées associées au profil de capteur correspondant au capteur en question. Ces métadonnées permettent à l'application Wireless Logger de mapper automatiquement le capteur au bon décodeur de Payload de la liste des drivers IoT Flow. Pour plus de détails, voir Afficher les payloads de données décodés.
Données décodées	Payload applicatif décodé, disponible uniquement lorsqu'un driver de Payload valide existe pour ce modèle de capteur et que le décodeur Wireless Logger n'est pas réglé sur "pas de décodage". Pour plus d'informations, voir Affichage des Payloads décodés.
Taille des données (octets)	Taille du Payload applicatif en octets.
Temps d'antenne (s)	Durée de l'émission du paquet dans l'air (en secondes).
Statut de Livraison	État de transmission du paquet downlink par la passerelle LRR : - Envoyé : le paquet downlink a été envoyé avec succès par le LRR. Remarque : Une transmission réussie par le LRR ne garantit pas une réception réussie par le capteur, en raison de la perte potentielle du paquet par voie aérienne (collision, problèmes de bilan de liaison, etc.). - Échoué : le paquet de Downlink n'a pas pu être envoyé par le LRR sur l'interface aérienne. La cause de l'échec de la livraison sur RX1/RX2/Pingslot (ce dernier est exclusif aux capteurs de classe B) est fournie dans le panneau extensible. Pour plus d'informations, voir Causes des échecs de livraison Downlink.
Bande ISM	Bande ISM LoRaWAN® (également connue sous le nom de profil régional selon la spécification des paramètres régionaux de LoRaWAN) associée au capteur et à son meilleur LRR (BestLRR ou BestGWID).
RF region	RF region de la meilleure passerelle (BestLRR ou BestGWID).
AS ID	ID ThingPark du serveur d'application envoyant le paquet de Downlink au capteur. Cette information s'applique uniquement aux paquets downlink portant un payload applicatif ; sinon le champ est vide.
Fréquence	Fréquence physique (en MHz) utilisée par le réseau pour transmettre le paquet downlink. Le Canal Logique correspondant est affiché dans la colonne Canal.
Statut du rapport de "Downlink Sent Indication" à AS	Pour chaque paquet de Downlink demandé par le serveur d'application (AS), le réseau envoie à l'AS un rapport "Indication de Downlink Envoyé" décrivant si la transmission a été complétée avec succès par la/les passerelle(s) du réseau. Lorsque l'interface entre ThingPark et le serveur d'application tiers utilise des connexions de type HTTP basique (également connue sous le nom d'interface NS/AS tunnel), le statut de transmission d'un tel rapport "Downlink Sent Indication" à l'AS est visible dans Wireless Logger. Deux valeurs possibles sont : OK ou Erreur. En cas d'erreur, un message est affiché dans la colonne Erreurs de transmission. Remarque Ce statut n'est pertinent que pour les types de connexions "HTTP basique". Les erreurs de livraison liées aux connexions TPX ne sont actuellement pas visibles dans le Wireless Logger.
Erreurs de transmission	Applicable uniquement si le statut de transmission est Erreur. Idx: Index de la destination qui a causé l'erreur. Valeur de départ à 0. Url: L'URL de destination qui a retourné l'erreur. Un serveur d'applications HTTP peut être configuré avec plusieurs URLs de destinations. Statut: - Timeout : Le rapport n'a pas été accusé de réception avec succès par la destination dans le délai attendu. - Erreur : Le rapport a été rejeté par la destination. (Erreur HTTP, erreur réseau, erreur DNS). - Overload : Le rapport n'a pas été envoyé vers la destination car le network server a atteint l'état OVERLOAD et le temps aller-retour moyen vers la destination est trop élevé. - Blacklist : Le rapport n'a pas été envoyé vers la destination car le network server a atteint l'état BLACKLIST et le temps aller-retour moyen vers la destination est mauvais. - Inaccessible : Le rapport n'a pas été envoyé à la destination car cette destination a été jugée inaccessible en raison d'un comportement non réactif au cours de la dernière fenêtre d'observation. Note Ces informations ne sont pertinentes que pour des connexions de type "HTTP de base". Les erreurs de livraison liées aux connexions TPX ne sont actuellement pas visibles dans le Wireless Logger.
Compteur de trame réseau confirmé à la hausse (ConfFCntUp)	Valable uniquement pour les capteurs LoRaWAN® 1.1 lorsque le paquet de Downlink accuse réception du dernier paquet d'Uplink envoyé en mode confirmé. Il indique le compteur de trame uplink FCntUp étant confirmé par le LRC (accusé de réception envoyé par le LRC). Ce champ est visible dans le panneau extensible du downlink.
Créneau de transmission	Soit RX1, RX2, Pingslot ou RXR (ce dernier n'est valide que pour les paquets Downlink transmis via un relais LoRaWAN). Note "RXR (répétition)" signifie que la transmission du paquet downlink a été tentée deux fois par le réseau : via une station passerelle directe (en utilisant les créneaux RX1/RX2 conventionnels) et via un relais (utilisant le créneau RXR). Cette répétition de DL aide à maximiser les chances du capteur de recevoir avec succès le paquet de Downlink lorsqu'il se trouve à la frontière de couverture entre une passerelle conventionnelle et un relais.