Il n'y a pas si longtemps, sur divers autres sites et dans mon blog, j'ai mentionné que ZigBee était mort et qu'il était temps d'enterrer la hôtesse de l'air. Pour faire bonne figure face à la situation avec Thread, qui fonctionne sur IPv6 et 6LowPan, il suffit d'un Bluetooth (LE) mieux adapté à cela. Mais j'en parlerai un autre jour. Aujourd'hui, je vais expliquer comment le groupe de travail du comité a sérieusement réfléchi une seconde fois après le 802.11ah et a décidé qu'il était temps d'ajouter au pool des standards 802.11 une version complète de quelque chose comme LRLP (Long-Range Low-Power), similaire à LoRA. Cependant, cela s'est avéré irréalisable sans sacrifier la vache sacrée de la rétrocompatibilité. Finalement, ils ont renoncé au Long-Range et ne sont restés qu'avec le Low-Power, ce qui est également très bien. Cela a donné une combinaison de 802.11 + 802.15.4 ou, en termes simples, Wi-Fi + ZigBee. En d'autres termes, on peut dire que la nouvelle technologie n'est pas un concurrent des solutions LoraWAN, mais qu'elle est au contraire conçue pour les compléter.
Commençons par l'essentiel — Les appareils prenant en charge 802.11ba doivent maintenant avoir deux modules radio. Il semble qu’après avoir observé les 802.11ah/ax avec leur technologie Target Wake Time (TWT), les ingénieurs ont décidé que cela ne suffisait pas et qu'il fallait réduire radicalement la consommation d'énergie. Pour cela, la norme prévoit une séparation en deux types de radio différents — Radio de communication principale (PCR) et Radio de réveil (WUR). Pour la première, tout est clair : c'est le radio principal qui transmet et reçoit des données, mais pour la seconde, ce n'est pas si évident. En fait, le WUR est principalement un dispositif d'écoute (RX) et doit consommer très peu d'énergie pour fonctionner. Sa tâche principale est de recevoir un signal de réveil de l'AP et d'activer le PCR. En d'autres termes, cette méthode réduit considérablement le temps de démarrage à froid et permet de réveiller les appareils à des moments précis. Cela est particulièrement utile lorsque vous avez, disons, pas dix appareils, mais cent dix, et que vous devez échanger des données avec chacun d'eux en peu de temps. De plus, la logique de fréquence et de périodicité de réveil est déplacée du côté de l'AP. Alors que, par exemple, dans LoRAWAN, une méthodologie PUSH est utilisée où les dispositifs exécutifs se réveillent et transmettent quelque chose dans l'air, puis dorment le reste du temps, ici, c'est l'inverse : l'AP décide de quel appareil doit se réveiller, et les dispositifs exécutifs... ne dorment pas toujours.
Passons maintenant aux formats de trame et à la garantie de compatibilité. Si le 802.11ah, en tant que première tentative, était conçu pour les bandes 868/915 MHz, ou simplement SUB-1GHz, le 802.11ba est déjà destiné aux plages de 2,4 GHz et 5 GHz. Dans les précédentes « nouvelles » normes, la compatibilité était obtenue grâce à un préambule compréhensible par les anciens appareils. En d'autres termes, on s'appuyait sur le fait que les anciens appareils n'avaient en réalité pas besoin de reconnaître l'intégralité de la trame, il leur suffisait de comprendre quand celle-ci commencerait et combien de temps durerait la transmission. C'est cette information qu'ils obtiennent du préambule. Le 802.11ba n'a pas fait exception, car le schéma a été éprouvé et testé (la question des coûts est pour l'instant mise de côté).
Ainsi, une trame 802.11ba ressemble à ceci :
La préambule Non-HT et le bref fragment OFDM avec modulation BPSK permettent à tous les dispositifs 802.11a/g/n/ac/ax d'entendre le début de la transmission de ce cadre et de ne pas interférer, passant en mode écoute. Après le préambule, il y a le champ de synchronisation (SYNC) qui est en essence l'analogue de L-STF/L-LTF. Il sert à ajuster la fréquence et à synchroniser le récepteur de l'appareil. À ce moment précis, l'appareil émetteur passe à une largeur de canal différente de 4 MHz. Pourquoi ? C'est très simple. Cela permet de réduire la puissance et d'obtenir un rapport signal sur bruit (SINR) comparable. Ou bien de maintenir la puissance telle quelle et d'obtenir une portée de transmission significativement augmentée. Je dirais que c'est une solution assez élégante, de plus, elle permet de réduire considérablement les exigences en matière d'alimentation. Rappelons, par exemple, le populaire ESP8266. En mode transmission avec un débit de 54 Mbps et une puissance de 16 dBm, il consomme 196 mA, ce qui est excessif pour quelque chose comme une CR2032. Si l'on réduit la largeur de canal par cinq et la puissance de l'émetteur par cinq, nous ne perdons pratiquement pas en portée de transmission, mais nous allons considérablement réduire le courant de consommation, disons, à environ 50 mA. Ce n'est pas que cela soit critique du point de vue de l'AP qui transmet le cadre pour WUR, mais c'est tout de même appréciable. En revanche, pour le STA, cela a du sens, car une consommation plus faible permet d'utiliser quelque chose comme une CR2032 ou des batteries conçues pour un stockage prolongé d'énergie avec de faibles courants nominales de décharge. Bien sûr, il n'y a rien de gratuit et la réduction de la largeur de canal entraînera une diminution de la vitesse de canal avec une augmentation du temps de transmission d'un cadre en conséquence.
À propos de la vitesse de canal. La norme sous sa forme actuelle prévoit deux options : 62,5 Kbps et 250 Kbps. Vous sentez quelque chose de ZigBee ? Ce n'est pas pour rien, car il a une largeur de canal de 2 MHz au lieu de 4 MHz, mais un autre type de modulation avec une plus grande densité spectrale. En fin de compte, le rayon d'action des dispositifs 802.11ba devrait être supérieur, ce qui est particulièrement utile pour les scénarios IoT à l'intérieur.
Mais attendez une minute... Forcer toutes les stations environnantes à se taire en utilisant seulement 4 MHz de la bande de 20 MHz... «C'EST UN GASPILLAGE!» - diriez-vous, et vous auriez raison. Mais non, VOICI LE VRAI GASPILLAGE!
La norme permet d'utiliser des sous-canaux de 40 MHz et 80 MHz. De plus, les débits de chaque sous-canal peuvent être différents, et pour correspondre dans le temps, un Padding est ajouté à la fin de la trame. Ainsi, un appareil peut occuper le temps d'uzid à tous les 80 MHz, mais n'utiliser que 16 MHz. Là, c'est vraiment un gaspillage.
Au fait, les dispositifs Wi-Fi environnants n'ont aucune chance de comprendre ce qui est diffusé dans l'air. Parce que pour coder les trames 802.11ba, le traditionnel OFDM qu'ils connaissent n'est PAS utilisé. Oui, c'est ainsi que l'alliance a abandonné ce qui fonctionnait sans faille pendant de nombreuses années. Au lieu du classique OFDM, on utilise la modulation Multi-Carrier (MC)-OOK. Le canal de 4 MHz est divisé en 16(?) sous-porteuses, chacune utilisant un codage de Manchester. De plus, le champ DATA lui-même est logiquement divisé en segments de 4 μs ou 2 μs selon le débit, et dans chaque segment, un niveau de codage peut répondre à un niveau bas ou élevé. C'est une solution pour éviter de longues séquences de zéros ou de uns. Du scrambling à minima.
Le niveau MAC est également extrêmement simplifié. Il ne contient que les champs suivants :
- Contrôle de trame
Peut prendre les valeurs Beacon, WuP, Discovery ou toute autre à la discrétion du fournisseur.
Le Beacon sert à la synchronisation temporelle, le WuP est destiné à réveiller un ou plusieurs dispositifs, et le Discovery fonctionne dans le sens inverse du STA vers l'AP et est conçu pour rechercher des points d'accès prenant en charge 802.11ba. Ce champ contient également la longueur de la trame si elle dépasse 48 bits. - ID
Selon le type de trame, il peut identifier un AP, ou un STA ou un groupe de STA auquel la trame est destinée. (Oui, il est possible de réveiller des appareils par groupes, cela s'appelle des réveils groupés et c'est plutôt cool).
- Type Dépendant (TD)
C'est un champ assez flexible. C'est là que l'on peut transmettre l'heure exacte, un signal de mise à jour du firmware/configuration avec un numéro de version ou quelque chose d'utile que le STA devrait connaître.
- Champ de contrôle de trame (FCS)
Ici, c'est simple. C'est une somme de contrôle.
Mais pour que la technologie fonctionne, il ne suffit pas d'envoyer un cadre du bon format. STA et AP doivent trouver un accord. La STA communique ses paramètres, y compris le temps nécessaire pour initialiser le PCR. Tout le processus de négociation se fait en utilisant les trames classiques 802.11, après quoi la STA peut désactiver le PCR et passer en mode d'activation WUR. Elle peut même se reposer un peu, si possible. Car si l'opportunité se présente, il vaut mieux en profiter.
Ensuite, il y a une petite extraction de précieuses milliampères-heure appelée cycle de service WUR. Rien de compliqué, c'est juste que la STA et l'AP, comme pour le TWT, conviennent d'un calendrier de sommeil. Après cela, la STA dort principalement, activant de temps en temps le WUR pour écouter "N'est-ce pas que quelque chose d'utile est arrivé pour moi ?". Et seulement si nécessaire, elle réveille le module radio principal pour échanger des données.
Cela change radicalement la situation par rapport à TWT et U-APSD, n'est-ce pas ?
Et maintenant, un point important auquel on ne pense pas immédiatement. Le WUR n'a pas nécessairement besoin de fonctionner à la même fréquence que le module principal. Au contraire, il est souhaitable et recommandé qu'il fonctionne sur un autre canal. Dans ce cas, la fonctionnalité 802.11ba n'entrave en rien le fonctionnement du réseau et peut au contraire être utilisée pour diffuser des informations utiles. Localisation, liste des voisins et bien d'autres choses dans le cadre d'autres normes 802.11, comme 802.11k/v. Et quels avantages s'ouvrent pour les réseaux Mesh… Mais c'est un sujet pour un autre article.
En ce qui concerne le destin même de la norme en tant que document, . Cela signifie que cette année, on peut attendre un véritable standard, ou du moins les premières réalisations. Quant à sa diffusion, seul le temps le dira.
Voilà… (c) .
Lectures recommandées pour en savoir plus :
Source : habr.com
