802.11ba (WUR) ou comment croiser un serpent avec un hérisson

Il n'y a pas si longtemps, sur diverses autres ressources et sur mon blog, j'ai parlé du fait que ZigBee est mort et qu'il est temps d'enterrer l'agent de bord. Afin de donner bonne mine à un mauvais jeu avec Thread fonctionnant sur IPv6 et 6LowPan, le Bluetooth (LE) qui est plus adapté à cela est suffisant. Mais je vous en parlerai une autre fois. Aujourd'hui, nous allons parler de la façon dont le groupe de travail du comité a décidé de réfléchir à deux fois après 802.11ah et a décidé qu'il était temps d'ajouter une version à part entière de quelque chose comme LRLP (Long-Range Low-Power) au pool de normes 802.11, similaire à LoRA. Mais cela s’est avéré impossible à mettre en œuvre sans abattre la vache sacrée de la rétrocompatibilité. En conséquence, le Long-Range a été abandonné et il ne reste que le Low-Power, ce qui est également très bien. Le résultat était un mélange de 802.11 + 802.15.4, ou simplement Wi-Fi + ZigBee. Autrement dit, nous pouvons dire que la nouvelle technologie n'est pas un concurrent des solutions LoraWAN, mais qu'elle est au contraire créée pour les compléter.

Commençons donc par la chose la plus importante : désormais, les appareils prenant en charge 802.11ba devraient avoir deux modules radio. Apparemment, après avoir examiné le 802.11ah/ax avec sa technologie Target Wake Time (TWT), les ingénieurs ont décidé que cela n'était pas suffisant et qu'ils devaient réduire radicalement la consommation d'énergie. Pourquoi la norme prévoit une division en deux types différents de radio : la radio de communication primaire (PCR) et la radio de réveil (WUR). Si avec le premier tout est clair, c'est la radio principale, elle transmet et reçoit des données, alors avec la seconde ce n'est pas tellement le cas. En fait, le WUR est principalement un appareil d'écoute (RX) et est conçu pour consommer très peu d'énergie pour fonctionner. Sa tâche principale est de recevoir un signal de réveil du point d'accès et d'activer la PCR. Autrement dit, cette méthode réduit considérablement le temps de démarrage à froid et vous permet de réveiller les appareils à une heure donnée avec une précision maximale. Ceci est très utile lorsque vous possédez, disons, non pas dix appareils, mais cent dix et que vous devez échanger des données avec chacun d'eux dans un court laps de temps. De plus, la logique de la fréquence et de la périodicité des réveils se déplace du côté AP. Si, disons, LoRAWAN utilise la méthodologie PUSH lorsque les actionneurs eux-mêmes se réveillent et transmettent quelque chose dans les airs, et dorment le reste du temps, alors dans ce cas, au contraire, l'AP décide quand et quel appareil doit se réveiller, et les actionneurs eux-mêmes... ne dorment pas toujours.

Passons maintenant aux formats de trames et à la compatibilité. Si le 802.11ah, dans un premier temps, a été créé pour les bandes 868/915 MHz ou simplement SUB-1GHz, alors le 802.11ba est déjà destiné aux bandes 2.4 GHz et 5 GHz. Dans les « nouvelles » normes précédentes, la compatibilité était assurée grâce à un préambule compréhensible pour les appareils plus anciens. Autrement dit, le calcul a toujours été que les appareils plus anciens n'ont pas nécessairement besoin d'être capables de reconnaître la trame entière, il leur suffit de comprendre quand cette trame commencera et combien de temps durera la transmission. C'est cette information qu'ils tirent du préambule. Le 802.11ba ne fait pas exception, puisque le système a fait ses preuves (nous ignorerons pour l’instant la question des coûts).

En conséquence, la trame 802.11ba ressemble à ceci :

Un préambule non-HT et un court fragment OFDM avec modulation BPSK permettent à tous les appareils 802.11a/g/n/ac/ax d'entendre le début de la transmission de cette trame et de ne pas interférer, passant en mode d'écoute diffusion. Après le préambule vient le champ de synchronisation (SYNC), qui est essentiellement un analogue de L-STF/L-LTF. Il sert à permettre de régler la fréquence et de synchroniser le récepteur de l’appareil. Et c'est à ce moment que l'appareil émetteur passe à une autre largeur de canal de 4 MHz. Pour quoi? Tout est très simple. Ceci est nécessaire pour que la puissance puisse être réduite et qu'un rapport signal/bruit (SINR) comparable puisse être obtenu. Ou laissez la puissance telle quelle et obtenez une augmentation significative de la portée de transmission. Je dirais que c'est une solution très élégante, qui permet également de réduire considérablement les besoins en alimentation. Rappelons par exemple le populaire ESP8266. En mode transmission utilisant un débit de 54 Mbps et une puissance de 16 dBm, il consomme 196 mA, ce qui est prohibitif pour quelque chose comme le CR2032. Si nous réduisons la largeur du canal de cinq fois et la puissance de l'émetteur de cinq fois, nous ne perdrons pratiquement pas de portée de transmission, mais la consommation de courant sera réduite d'un facteur, disons, à environ 50 mA. Non pas que cela soit critique de la part de l’AP qui transmet la trame pour WUR, mais ce n’est quand même pas mal. Mais pour STA, cela a déjà du sens, car une consommation plus faible permet d'utiliser quelque chose comme le CR2032 ou des batteries conçues pour le stockage d'énergie à long terme avec de faibles courants de décharge nominaux. Bien entendu, rien n'est gratuit et réduire la largeur du canal entraînera respectivement une diminution de la vitesse du canal avec une augmentation du temps de transmission d'une image.

À propos, à propos de la vitesse du canal. La norme dans sa forme actuelle propose deux options : 62.5 Kbps et 250 Kbps. Sentez-vous l'odeur de ZigBee ? Ce n'est pas simple, puisqu'il a une largeur de canal de 2Mhz au lieu de 4Mhz, mais un type de modulation différent avec une densité spectrale plus élevée. En conséquence, la portée des appareils 802.11ba devrait être plus large, ce qui est très utile pour les scénarios IoT en intérieur.

Mais attendez une minute... Obliger toutes les stations de la zone au silence, tout en n'utilisant que 4 MHz de la bande 20 MHz... "C'EST UN DÉCHET !" - tu diras et tu auras raison. Mais non, C'EST LE VRAI DÉCHET !

La norme offre la possibilité d'utiliser des sous-canaux de 40 MHz et 80 MHz. Dans ce cas, les débits de chaque sous-canal peuvent être différents, et afin de correspondre à l'heure de diffusion, un remplissage est ajouté à la fin de la trame. Autrement dit, l'appareil peut occuper du temps d'antenne sur les 80 MHz, mais ne l'utiliser que sur 16 MHz. C'est un vrai gaspillage.

À propos, les appareils Wi-Fi environnants n’ont aucune chance de comprendre ce qui y est diffusé. Parce que l'OFDM habituel n'est PAS utilisé pour coder les trames 802.11ba. Oui, c’est ainsi que l’alliance a abandonné ce qui fonctionnait parfaitement depuis de nombreuses années. Au lieu de l'OFDM classique, la modulation Multi-Carrier (MC)-OOK est utilisée. Le canal 4 MHz est divisé en 16 (?) Sous-porteuses, chacune utilisant le codage Manchester. Dans le même temps, le champ DATA lui-même est également logiquement divisé en segments de 4 μs ou 2 μs en fonction du débit binaire, et dans chacun de ces segments, un niveau de codage faible ou élevé peut correspondre à un. C'est la solution pour éviter une longue séquence de zéros ou de uns. Bousculade au salaire minimum.

Le niveau MAC est également extrêmement simplifié. Il contient uniquement les champs suivants :

• Contrôle du cadre

  Peut prendre les valeurs Beacon, WuP, Discovery ou toute autre valeur au choix du vendeur.
  Beacon est utilisé pour la synchronisation de l'heure, WuP est conçu pour réveiller un ou un groupe d'appareils, et Discovery fonctionne dans le sens opposé de STA à AP et est conçu pour trouver 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 une STA, ou un groupe de STA auquel cette trame est destinée. (Oui, vous pouvez réveiller des appareils en groupe, ça s’appelle des réveils groupcast et c’est plutôt cool).

• Dépend du type (TD)

  Un domaine assez flexible. C'est dans celui-ci que l'heure exacte peut être transmise, un signal concernant une mise à jour du micrologiciel/de la configuration avec un numéro de version ou quelque chose d'utile que la STA devrait connaître.

• Champ de somme de contrôle de trame (FCS)
  Tout est simple ici. Ceci est une somme de contrôle

Mais pour que la technologie fonctionne, il ne suffit pas d’envoyer simplement une trame au format requis. La STA et l'AP doivent être d'accord. La STA rapporte ses paramètres, notamment le temps nécessaire à l'initialisation du PCR. Toutes les négociations s'effectuent à l'aide de trames 802.11 normales, après quoi la STA peut désactiver PCR et passer en mode d'activation WUR. Ou peut-être même dormir un peu, si possible. Car s’il existe, alors il vaut mieux l’utiliser.
Vient ensuite un peu plus de compression des précieuses heures en milliampères appelées WUR Duty Cycle. Il n'y a rien de compliqué, juste STA et AP, par analogie avec ce qui s'est passé pour TWT, se mettent d'accord sur un horaire de sommeil. Après cela, STA dort principalement, activant occasionnellement WUR pour écouter « Est-ce que quelque chose d'utile m'est arrivé ? » Et seulement si nécessaire, il réveille le module radio principal pour l'échange de trafic.

Cela change radicalement la donne par rapport au TWT et à l'U-APSD, n'est-ce pas ?

Et maintenant une nuance importante à laquelle on ne pense pas immédiatement. Le WUR ne doit pas nécessairement fonctionner à la même fréquence que le module principal. Au contraire, il est souhaitable et recommandé qu’il fonctionne sur un canal différent. Dans ce cas, la fonctionnalité 802.11ba ne gêne en rien le fonctionnement du réseau et peut au contraire être utilisée pour envoyer des informations utiles. Emplacement, liste de voisins et bien plus encore dans d'autres normes 802.11, par exemple 802.11k/v. Et quels avantages s'offrent aux réseaux maillés... Mais c'est le sujet d'un article séparé.

Quant au sort de la norme elle-même en tant que document, alors Actuellement, la version 6.0 est prête avec un taux d'approbation : 96 %. Autrement dit, cette année, nous pouvons nous attendre à une véritable norme ou au moins aux premières implémentations. Seul le temps nous dira quelle sera son ampleur.

De telles choses... (c) MalWirelesL'Homme.

Lecture recommandée:

IEEE 802.11ba – Wi-Fi à très faible consommation pour un Internet massif des objets – Défis, problèmes ouverts, évaluation des performances

IEEE 802.11ba : radio de réveil basse consommation pour l'IoT vert

Radio de réveil compatible IEEE 802.11 : cas d'utilisation et applications

Source: habr.com