Wi-Fi HaLow est l’un des rares standards IoT où la performance finale dépend moins de la radio brute que de la configuration MAC. Là où Zigbee,Thread ou LoRaWAN sont relativement tolérants aux erreurs de dimensionnement,802.11ah exige une approche quasi mathématique. Ce document propose un modèle de raisonnement opérationnel pour concevoir un réseau HaLow stable,en explicitant les paramètres réellement déterminants,les équations simplifiées utiles et les erreurs fatales observées sur le terrain.
1. Le vrai goulot d’étranglement HaLow
En 802.11ah,le facteur limitant n’est pas le débit PHY maximal mais le temps radio disponible par fenêtre d’accès. La ressource rare est le temps d’antenne planifié. Toute approche basée uniquement sur “kbps disponibles” est incorrecte. Il faut raisonner en occupation temporelle.
Capacité réseau ≈ somme des durées de transmission utiles + overhead MAC + marges de contention,le tout borné par la durée des fenêtres RAW.
2. RAW (Restricted Access Window) : cœur du système
RAW segmente les stations en groupes et n’autorise l’accès au médium que pendant des fenêtres temporelles définies. Chaque RAW est découpée en slots. Une station n’a le droit d’émettre que dans son slot.
Les paramètres fondamentaux sont nombre de groupes RAW,nombre de slots par groupe,durée de slot,et périodicité RAW.
Erreur classique numéro un : utiliser RAW sans vraiment dimensionner les groupes,ce qui revient à faire du Wi-Fi classique déguisé.
3. Modèle simple de dimensionnement RAW
Prenons un point d’accès HaLow avec N stations. On les répartit en G groupes RAW. Chaque groupe contient Ng = N/G stations. Chaque groupe est actif pendant une fenêtre Tg. Cette fenêtre est découpée en S slots.
Durée slot ≥ temps de transmission d’un paquet + ACK + guard time.
Temps transmission ≈ (payload + headers) / PHY rate.
Exemple réaliste IoT : payload 50 octets,headers MAC+IP+UDP ≈ 60 octets,total ≈ 110 octets. À 300 kbps effectifs,temps ≈ (110*8)/300k ≈ 2,9 ms. Avec ACK et marge,slot ≈ 5 ms.
Si un groupe contient 100 stations,il faut au minimum S = 100 slots,donc Tg ≈ 500 ms pour que chaque station puisse parler une fois.
4. Calcul de capacité par période
Si ton application exige un uplink toutes les 5 minutes par station,et que tu as 1000 stations,le nombre total de transmissions par minute est 1000/5 = 200.
Si tu répartis en 10 groupes RAW,chaque groupe gère 100 stations. Chaque groupe doit donc être activé toutes les 5 minutes. Si chaque activation consomme 500 ms,la charge radio totale est 10*0,5 = 5 secondes toutes les 5 minutes,soit 1,67 % d’occupation radio.
C’est très confortable,mais uniquement si RAW est correctement configuré.
5. Pourquoi les réseaux HaLow “s’écroulent” en pratique
Trois causes dominantes. Premièrement,slots trop courts entraînant collisions et retransmissions. Deuxièmement,trop de stations par groupe RAW ce qui crée une latence imprévisible. Troisièmement,trafic descendant non anticipé,car le downlink consomme aussi du temps RAW.
Le downlink est souvent le tueur silencieux des réseaux HaLow mal conçus.
6. TWT (Target Wake Time) et énergie
TWT permet à la station de dormir en dehors de ses fenêtres RAW. La consommation moyenne est proportionnelle au duty cycle radio.
Consommation ≈ I_tx * t_tx + I_rx * t_rx + I_sleep * t_sleep.
Une station qui se réveille 1 seconde toutes les 5 minutes a un duty cycle de 0,33 %. Si la radio consomme 40 mA en RX et 50 mA en TX,la moyenne tombe à quelques centaines de microampères,compatible avec des autonomies multi-années.
Mais si la station rate sa fenêtre RAW et reste à l’écoute,le budget énergétique explose.
7. Impact direct de la qualité radio sur l’autonomie
Une baisse de SNR oblige à utiliser un MCS plus robuste,ce qui augmente la durée de transmission par paquet. Durée slot augmente,donc Tg augmente,donc occupation radio augmente,donc latence et consommation augmentent.
C’est pourquoi on dimensionne toujours HaLow avec une marge radio importante plutôt qu’en limite de portée.
8. Latence réelle : formule simplifiée
Latence max ≈ période RAW + durée du slot.
Si un groupe RAW est activé toutes les 30 secondes et que le slot dure 5 ms,la latence worst-case est ≈ 30 s. Pour des alarmes,ce n’est pas acceptable.
Solution : soit multiplier les activations RAW,soit créer un groupe RAW dédié aux messages urgents avec périodicité courte.
9. Stratégie multi-RAW par profil de trafic
Une architecture sérieuse utilise plusieurs RAW parallèles. Exemple concret. RAW A pour capteurs périodiques basse priorité,activation toutes les 5 minutes. RAW B pour alarmes,activation toutes les 1 seconde avec peu de stations. RAW C pour commandes descendantes,fenêtre courte mais fréquente.
C’est exactement ainsi qu’on évite que les alarmes soient bloquées par des capteurs “bruyants”.
10. RAW vs contention libre
802.11ah permet encore du contention-based access. C’est utile pour de l’ad-hoc ou du debug. En production IoT massif,c’est une erreur. Toute station en contention libre peut perturber l’équilibre temporel du réseau.
Règle d’or : zéro trafic critique hors RAW.
11. IP et overhead réel
Chaque station HaLow transporte IPv6 ou IPv4,UDP ou TCP,et parfois TLS. L’overhead est significatif comparé aux payloads IoT. Sur des petits messages,le ratio overhead/payload peut dépasser 1.
Cela renforce l’intérêt de messages courts,binaires,et de limiter la fréquence plutôt que d’augmenter le débit PHY.
12. Sécurité et RAW
WPA3 ajoute des échanges supplémentaires lors de l’association,mais en régime établi,l’impact est faible. Le vrai risque sécurité est la saturation volontaire ou involontaire d’un RAW par des stations mal configurées ou compromises.
D’où l’importance d’isoler les profils,et de pouvoir désactiver un groupe RAW sans impacter le reste du réseau.
13. Modèle mental correct pour HaLow
Ne pense pas HaLow comme “un AP Wi-Fi qui couvre loin”. Pense-le comme un scheduler radio temps-partagé où chaque objet achète des millisecondes d’antenne. Tant que la somme des millisecondes reste faible,le réseau est stable,prévisible et économe. Dès que tu perds le contrôle de ces millisecondes,le réseau se comporte comme un Wi-Fi congestionné classique.
Conclusion
Wi-Fi HaLow est une technologie d’ingénieur, pas de plug-and-play. Sa puissance vient de RAW,TWT et de la planification temporelle explicite. Bien conçu,il peut supporter des milliers d’objets IP sub-GHz avec une latence maîtrisée et une autonomie multi-années. Mal conçu,il devient un Wi-Fi lent,énergivore et instable. La différence ne tient pas à la radio mais à la discipline d’architecture.