Le serveur réseau gère les paramètres radio de chaque appareil avec des commandes MAC : de courtes instructions transmises dans les downlinks et des réponses transmises dans les uplinks. La plus importante est l’adaptive data rate (ADR). Cette page explique ce que le serveur réseau fait de lui-même et comment l’influencer depuis le profil.
Adaptive data rate (ADR)
Un appareil proche d’une passerelle n’a pas besoin du débit le plus lent et de la plus longue portée. L’ADR le fait passer à un débit plus rapide et à une puissance d’émission plus faible, ce qui économise la batterie et le temps d’antenne et laisse de la place aux autres appareils.
L’ADR s’exécute lorsque les deux conditions suivantes sont remplies :
- Adaptive data rate (ADR) est activé dans le profil de l’appareil (activé par défaut).
- L’appareil lui-même demande l’ADR dans ses uplinks (c’est le cas de la plupart des appareils).
Comment un changement est décidé
- Pour chaque uplink, le serveur réseau retient le meilleur SNR parmi toutes les passerelles qui l’ont reçu.
- Dès qu’il dispose de 20 uplinks, il retient le meilleur SNR de ces 20.
- Marge = ce SNR − le SNR qu’exige le débit actuel − la marge d’installation (10 dB par défaut, paramètre API
installationMarginDb, 0–30). - Chaque tranche complète de 3 dB de marge correspond à un palier. Les paliers augmentent d’abord le débit, jusqu’au Highest data rate (DR) du profil ; les paliers restants réduisent la puissance d’émission de 2 dB chacun.
- Le serveur réseau n’augmente jamais la puissance d’un appareil et ne réduit jamais son débit en dessous de sa valeur actuelle.
- Le changement est envoyé sous forme de LinkADRReq. Lorsque l’appareil l’accepte, l’historique repart à zéro et aucun nouveau changement n’est effectué pendant les 20 uplinks suivants.
Lorsqu’un changement est accepté, les attributs de l’appareil lora.dr et lora.txPower sont mis à jour.
Paramètres du profil
| Champ | Par défaut | Effet |
|---|---|---|
| Adaptive data rate (ADR) | Activé | Désactivé : le serveur réseau n’envoie jamais de changements ADR. |
| Lowest data rate (DR) | DR0 | Le plancher que l’ADR conserve. |
| Highest data rate (DR) | DR5 | Le plafond vers lequel l’ADR fait passer les appareils. |
Désactivez l’ADR pour les appareils mobiles (trackers) : leur signal change plus vite que 20 uplinks.
Autres actions effectuées par le serveur réseau de lui-même
| Action | Quand |
|---|---|
| Définit le délai RX1 (RXTimingSetupReq) | Lorsque le délai RX1 de l’appareil diffère de celui du profil, par exemple pour un appareil ABP qui démarre à 1 s. Répété jusqu’à ce que l’appareil confirme. |
| Définit le décalage RX1 et RX2 (RXParamSetupReq) | Lorsque les valeurs de l’appareil diffèrent de celles du profil. |
| Demande la batterie et la marge de liaison (DevStatusReq) | Après chaque join, puis toutes les 24 heures (paramètre API devStatusIntervalH, 0 = jamais). |
| Définit une limite agrégée de cycle d’utilisation (DutyCycleReq) | Uniquement lorsque le paramètre API maxDutyCycle est supérieur à 0. |
| Répond aux contrôles de liaison (LinkCheckAns) | Lorsque l’appareil le demande ; lui indique la marge et le nombre de passerelles qui l’ont reçu. |
| Répond aux demandes d’heure (DeviceTimeAns) | Lorsque l’appareil demande l’heure du réseau. |
La batterie et la marge de l’appareil arrivent sous forme de télémétrie dans le message suivant lorsque Add the radio values est activé : lora.battery_level (0–100 %, absent pour les appareils alimentés en externe ou lorsque la valeur est inconnue) et lora.margin_db (la marge de liaison mesurée par l’appareil, −32 à 31 dB).
Comment les commandes MAC sont livrées
- Les réponses passent en premier, suivies des demandes en attente, dans l’en-tête du downlink (jusqu’à 15 octets). Lorsque le surplus ne tient pas, les commandes sont envoyées sur le FPort 0 à la place, et votre downlink applicatif attend la fenêtre suivante.
- Une demande en attente est renvoyée avec chaque downlink jusqu’à ce que l’appareil réponde, au maximum 3 fois, puis abandonnée.
- Le serveur réseau répond à un uplink même sans donnée applicative lorsqu’une réponse MAC est due ou lorsque l’appareil a demandé un accusé de réception de son ADR (ADRACKReq).
- Les commandes MAC ne bloquent jamais longtemps un downlink applicatif : lorsque les deux tiennent, les deux partent.
Commandes MAC prises en charge (LoRaWAN 1.0.x)
| Commande | Sens | Prise en charge |
|---|---|---|
| LinkCheckReq / LinkCheckAns | L’appareil demande, le réseau répond | Oui |
| LinkADRReq / LinkADRAns | Le réseau demande, l’appareil répond | Oui |
| DutyCycleReq / DutyCycleAns | Le réseau demande | Oui (uniquement lorsque maxDutyCycle > 0) |
| RXParamSetupReq / RXParamSetupAns | Le réseau demande | Oui |
| DevStatusReq / DevStatusAns | Le réseau demande | Oui |
| NewChannelReq / NewChannelAns | Le réseau demande | Les réponses sont interprétées |
| RXTimingSetupReq / RXTimingSetupAns | Le réseau demande | Oui |
| DlChannelReq / DlChannelAns | Le réseau demande | Les réponses sont interprétées |
| DeviceTimeReq / DeviceTimeAns | L’appareil demande, le réseau répond | Oui |
| TxParamSetupReq | Le réseau demande | Non utilisé en EU868 |
| Commandes de classe B (PingSlot, Beacon) | — | Non prises en charge |
| Commandes LoRaWAN 1.1 (Rekey, Rejoin, ResetInd) | — | Non prises en charge |
Une commande inconnue dans un uplink interrompt la lecture des commandes MAC restantes de cet uplink, comme l’exige la spécification LoRaWAN.