Wi-Fi HaLow,réseau IP natif sub-GHz à capacité moyenne et latence faible à moyenne,LoRaWAN,LPWAN sub-GHz à très longue portée mais capacité et downlink fortement contraints,Thread,réseau maillé IP natif 2,4 GHz basse conso à portée courte mais excellente densité locale.
2) Couche radio et largeur de bande,ce que ça implique vraiment
Wi-Fi HaLow 802.11ah opère en sub-GHz avec des largeurs de canal 1,2,4,8,16 MHz selon région,ce point est central car la largeur de canal détermine simultanément le budget de liaison,la capacité agrégée et la tolérance au bruit. MDPI+2zhaw.ch+2
LoRaWAN EU868 utilise typiquement des canaux LoRa de 125 kHz et des data rates basés sur SF7 à SF12,ce qui maximise la portée au prix d’une durée d’air élevée et donc d’une capacité cellule très limitée. The Things Network
Thread utilise IEEE 802.15.4 en 2,4 GHz avec 250 kbps brut,canal étroit mais propagation moins favorable que sub-GHz,compensée par le mesh.
3) Débits,mais surtout débits utiles et temps d’occupation
Wi-Fi HaLow annonce une plage de débits très large,typiquement de l’ordre de centaines de kbps à plusieurs dizaines de Mbps selon largeur de canal,MCS et nombre de streams,en pratique IoT on choisit souvent canaux étroits et MCS robustes pour la portée,donc plutôt des débits utiles de l’ordre de quelques centaines de kbps à quelques Mbps par lien,et une capacité agrégée qui dépend du nombre de stations actives et du scheduling MAC. zhaw.ch+1
LoRaWAN,a un débit utile qui varie très fortement avec le data rate,la table EU868 donne des bitrates allant typiquement de quelques centaines de bps à quelques kbps pour LoRa,suivant SF et BW,et le vrai plafond,c’est l’airtime et les limites duty-cycle sur certaines sous-bandes,donc la capacité par gateway se sature vite quand on augmente la fréquence des messages. The Things Network
Thread,à 250 kbps brut,avec overhead 802.15.4,6LoWPAN,IPv6,et éventuellement TLS ou Matter au-dessus,donc le débit utile par nœud est nettement inférieur,mais le point fort,c’est la densité locale et la réactivité sur de petites charges.
4) Densité de nœuds,la différence entre “associés” et “actifs”
Wi-Fi HaLow peut associer un nombre très élevé de stations,le standard vise jusqu’à 8191 stations associées,mais il faut distinguer associées versus actives,car la charge réelle dépend du nombre de stations qui parlent dans la même fenêtre temporelle et de la politique de scheduling. zhaw.ch
La clé HaLow,ce sont RAW et TWT,RAW partitionne les stations et n’autorise l’accès qu’à des groupes dans des fenêtres définies,et TWT planifie les réveils pour réduire collisions et consommation,ces deux mécanismes sont la raison pour laquelle HaLow peut tenir l’IoT massif,à condition d’être correctement configuré. ScienceDirect+1
LoRaWAN supporte de très grands nombres de devices au sens réseau,mais la capacité radio est limitée par la durée d’air,c’est souvent l’airtime et les collisions qui deviennent le facteur dominant bien avant le nombre d’objets “enregistrés”.
Thread peut gérer beaucoup de nœuds localement,mais la densité dépend du nombre de routeurs alimentés,du nombre de sauts,et du trafic,bien dimensionné il est très bon sur des campus ou étages,moins pertinent sur des hectares sans infrastructure.
5) Latence et déterminisme,ce qui est réaliste
Wi-Fi HaLow,avec scheduling MAC,peut atteindre une latence faible et relativement prévisible pour de l’IoT,mais ça reste du Wi-Fi,donc du déterminisme statistique,la latence augmente si tu demandes beaucoup de downlink,si tu fais des bursts,ou si tu sous-configures RAW.
LoRaWAN,latence fortement variable,et surtout le downlink est structurellement contraint,tu peux faire de l’alarm uplink très bien,mais le contrôle bidirectionnel fréquent est une mauvaise idée.
Thread,latence faible en local,mais la latence bout-en-bout dépend du mesh,du nombre de sauts,et de la couche applicative au-dessus,avec Matter ça reste correct mais pas “temps réel dur”.
6) Portée et couverture,les ordres de grandeur crédibles
Wi-Fi HaLow sub-GHz,avec canaux étroits,peut dépasser le kilomètre en champ libre,c’est documenté dans des publications et retours de tests,mais en vrai site industriel,tu dimensionnes plutôt pour une portée utile stable et une marge SNR,car sinon tu payes en retransmissions et batterie. MDPI+1
LoRaWAN,a une portée généralement supérieure en pratique sur des profils bas débit,SF élevés,mais ce gain se paye en temps d’air énorme et donc en capacité.
Thread,portée courte par saut,mais le maillage compense,à condition d’avoir des routeurs alimentés et une densité suffisante.
7) Consommation énergétique,le vrai coût c’est le temps radio et les retransmissions
Wi-Fi HaLow peut être très économe si tu utilises TWT correctement et si la couverture est bonne,parce que l’objet dort longtemps et n’ouvre sa radio que sur fenêtres planifiées,mais si le lien est limite,les retransmissions et le maintien d’association peuvent exploser l’énergie. ScienceDirect+1
LoRaWAN est extrêmement compétitif sur des petits uplinks peu fréquents,mais dès que tu augmentes la fréquence ou que tu ajoutes du downlink,la conso et la contrainte réseau montent vite.
Thread est très bon sur batterie parce que 802.15.4 et le modèle sleepy end device sont optimisés pour ça,mais il nécessite une infrastructure de routeurs alimentés et une couverture maillée bien pensée.
8) Sécurité et modèle de menace
Wi-Fi HaLow hérite du monde Wi-Fi,donc WPA2/WPA3 selon stack,avec un modèle IT classique,puissant mais exigeant côté provisioning et gestion d’identités à grande échelle.
Thread a une sécurité réseau obligatoire et une posture très “IoT moderne”,et si tu ajoutes Matter tu rajoutes une couche d’authentification et de modèles d’accès applicatifs.
LoRaWAN sécurise par clés réseau et applicatives avec chiffrement de payload,mais le modèle de menace inclut l’écosystème serveur réseau,les clés,et la gestion des join procedures.
9) Capacité cellule,un modèle chiffré simple pour décider vite
Pour décider vite,tu peux raisonner en “octets par heure par device” et “nombre de devices par cellule” en gardant une marge. Si tu as 1000 devices qui envoient 50 octets utiles toutes les 5 minutes,ça fait 50*12=600 octets par heure par device,soit 600 kB par heure pour 1000 devices,ça paraît faible,mais en LoRaWAN,c’est l’airtime qui compte,un petit payload à SF élevé peut occuper le médium longtemps,donc tu satures beaucoup plus vite que ne le laisse penser le volume IP. Pour HaLow et Thread,c’est l’inverse,le volume et la contention MAC sont plus directement liés,et la planification RAW ou la topologie mesh deviennent les paramètres dominants.
10) Règle de choix architecture,pratique et robuste
Choisis Wi-Fi HaLow si tu veux IP natif,sub-GHz,latence plus faible que LPWAN,réseau privé sous contrôle IT,et si tu acceptes de concevoir un vrai réseau,coverage planning,segmentation,auth,supervision. ScienceDirect+1
Choisis LoRaWAN si tu veux très longue portée,capteurs très low duty,peu de downlink,et une architecture orientée collecte plus que contrôle. The Things Network
Choisis Thread si tu veux un réseau local maillé basse conso,inter-op via Matter,et que tu peux installer des routeurs alimentés en densité suffisante,typiquement bâtiment,campus,étage,ou zone industrielle compacte.
11) Le point le plus “deep” à retenir
HaLow n’est pas “du Wi-Fi longue portée”,c’est du Wi-Fi re-câblé pour l’IoT massif,et sa réussite dépend d’une chose,la discipline MAC,RAW,TWT,TIM segmentation,et la qualité de couverture,si tu laisses le réseau se comporter comme du Wi-Fi classique,en contention libre,tu perds exactement ce qui fait sa valeur.