En LoRaWAN, l’airtime est la métrique la plus importante pour comprendre la capacité réelle d’un réseau, la probabilité de collisions et la consommation énergétique des objets. Un mauvais dimensionnement airtime mène directement à la saturation radio, à une hausse du PER, à une instabilité de l’ADR et à des batteries qui s’épuisent plus vite que prévu. Cet article détaille les formules exactes de la durée d’émission LoRa, explique l’impact de chaque paramètre et fournit des exemples chiffrés exploitables.
1. Paramètres radio qui déterminent l’airtime
L’airtime dépend principalement du Spreading Factor SF, de la largeur de bande BW, du taux de codage CR, de la présence du CRC, de la présence du header implicite ou explicite, de la longueur du préambule et de la taille de la charge utile PHY. En LoRaWAN, la taille utile applicative n’est pas égale à la charge PHY car il existe des en-têtes LoRaWAN et des champs MIC, et selon le chiffrement et les options, le payload final radio augmente.
Les paramètres usuels en LoRaWAN EU868 sont BW = 125 kHz pour la majorité des uplinks, SF7 à SF12, CR souvent noté 4/5, préambule typiquement 8 symboles, header explicite, CRC activé.
2. Formules de base LoRa : symbol time et préambule
Le temps d’un symbole est donné par Tsym = 2^SF / BW. Cette formule est fondamentale car elle explique pourquoi augmenter SF fait exploser l’airtime. Sur BW = 125 kHz, Tsym vaut environ 1,024 ms en SF7, 2,048 ms en SF8, 4,096 ms en SF9, 8,192 ms en SF10, 16,384 ms en SF11, 32,768 ms en SF12.
Le temps du préambule est Tpreamble = (Npreamble + 4,25) × Tsym. En LoRaWAN, Npreamble est souvent 8, donc Tpreamble = 12,25 × Tsym.
3. Nombre de symboles payload et airtime total
L’airtime total Tpacket est la somme du préambule et du payload, donc Tpacket = Tpreamble + Tpayload.
Le nombre de symboles payload est calculé par la formule suivante, qui est celle couramment utilisée dans les calculateurs LoRa officiels et de référence : Npayload = 8 + max( ceil( (8×PL − 4×SF + 28 + 16×CRC − 20×IH) / (4×(SF − 2×DE)) ) × (CR + 4), 0 ). Ici PL est la taille de payload PHY en octets, CRC vaut 1 si CRC activé sinon 0, IH vaut 0 si header explicite sinon 1, DE vaut 1 si Low Data Rate Optimization activée sinon 0, CR est un entier correspondant au taux de codage, CR = 1 pour 4/5, CR = 2 pour 4/6, CR = 3 pour 4/7, CR = 4 pour 4/8.
Le temps payload vaut Tpayload = Npayload × Tsym, donc Tpacket = (Npreamble + 4,25 + Npayload) × Tsym.
4. Le paramètre DE et la Low Data Rate Optimization
DE s’active généralement en SF11 et SF12 avec BW 125 kHz car Tsym devient grand, ce qui augmente la sensibilité aux dérives d’oscillateur et aux erreurs. Quand DE = 1, le dénominateur (SF − 2×DE) réduit la capacité de symboles utiles par unité de payload, ce qui augmente encore l’airtime. C’est une des raisons pour lesquelles SF12 est particulièrement coûteux en capacité radio.
5. Exemples chiffrés d’airtime en EU868, BW 125 kHz, CR 4/5, préambule 8, header explicite, CRC ON
Pour fixer les ordres de grandeur, prenons un payload PHY PL = 20 octets. En SF7, Tsym = 1,024 ms, Tpreamble = 12,25 × 1,024 ms ≈ 12,544 ms. Le terme interne pour Npayload dépend du ceil, mais on obtient typiquement un Npayload de l’ordre de quelques dizaines de symboles, ce qui mène à un airtime total généralement autour de 40 à 60 ms selon les options exactes. En SF12, Tsym = 32,768 ms, Tpreamble ≈ 401,408 ms, et le payload ajoute souvent plusieurs centaines de millisecondes supplémentaires, ce qui mène à un airtime souvent supérieur à 1 seconde pour des charges modestes.
Pour un payload PHY PL = 51 octets, qui est une taille fréquente pour des trames applicatives un peu plus riches, l’airtime grimpe fortement. En SF7, on reste typiquement sous 120 ms, tandis qu’en SF12 on peut dépasser largement 1,5 seconde. Ces valeurs varient selon IH, CRC, CR et DE, mais la tendance est toujours la même, l’airtime explose avec SF et avec PL.
6. Comment convertir une charge applicative en PL radio réel
En LoRaWAN, la charge applicative FRMPayload n’est pas égale à PL. La trame LoRaWAN inclut MHDR, FHDR, FPort et MIC, et FHDR peut inclure FOpts. Une règle pratique est que la trame radio totale augmente d’une dizaine d’octets ou plus par rapport au payload applicatif, et davantage si FOpts est utilisé. Pour dimensionner correctement, il faut calculer la taille PHY émise, pas la taille applicative seule, sinon on sous-estime l’airtime et donc on sur-estime la capacité.
7. Airtime, duty cycle et limite de trafic par objet
En EU868 avec 1 % de duty cycle sur une sous-bande, un objet ne peut émettre que 36 secondes par heure sur un canal donné. Si un message dure 1 seconde, l’objet est limité à environ 36 messages par heure sur ce canal, soit en moyenne un message toutes les 100 secondes. Si un message dure 50 ms, la limite théorique monte à 720 messages par heure sur ce canal, soit un message toutes les 5 secondes, mais cette limite purement réglementaire ne tient pas compte de la capacité réseau globale ni des collisions.
En pratique, même si un objet pourrait respecter le duty cycle, le réseau ne pourra pas supporter un grand nombre d’objets émettant fréquemment, car la capacité est partagée et l’accès radio est aléatoire.
8. Lien direct entre airtime et probabilité de collisions
Dans un accès de type ALOHA, la probabilité de collision augmente avec l’occupation du canal. Plus l’airtime par message est long, plus la fenêtre de collision est grande, et plus deux messages ont de chances de se chevaucher. Cela explique pourquoi forcer trop d’objets sur SF11 ou SF12 détruit la capacité, même si le nombre de messages par objet reste faible.
9. Bonnes pratiques d’optimisation airtime
La réduction de l’airtime passe par quatre leviers. D’abord réduire SF via une couverture passerelle suffisante et un ADR bien calibré, ensuite réduire PL via des payloads compacts et des protocoles binaires, ensuite limiter les messages confirmés et le trafic descendant, enfin contrôler la fréquence d’émission et éviter les bursts synchronisés. Dans les réseaux denses, l’ADR doit être considéré comme obligatoire, mais seulement si les objets sont statiques, sinon il faut gérer le compromis entre robustesse et capacité.
Conclusion
L’airtime est la monnaie du réseau LoRaWAN. Tout calcul de capacité, toute estimation d’autonomie et toute stratégie ADR doit partir de la formule Tsym = 2^SF / BW, puis du calcul exact de Npayload. Sans ces éléments, on construit des hypothèses optimistes qui se brisent lors du passage à l’échelle. Une approche rigoureuse basée sur le calcul airtime, la distribution SF et la discipline de trafic est la condition d’un réseau LoRaWAN stable et extensible.