{"id":70827,"date":"2020-02-21T14:42:12","date_gmt":"2020-02-21T11:42:12","guid":{"rendered":"https:\/\/prohoster.info\/blog\/802-11ba-wur-ili-kak-skrestit-uzha-s-ezhom"},"modified":"2020-03-03T16:14:44","modified_gmt":"2020-03-03T13:14:44","slug":"802-11ba-wur-ili-kak-skrestit-uzha-s-ezhom","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/802-11ba-wur-ili-kak-skrestit-uzha-s-ezhom","title":{"rendered":"802.11ba (WUR) ou comment croiser une couleuvre avec un h\u00e9risson","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Il n'y a pas si longtemps, sur divers autres sites et dans mon blog, j'ai mentionn\u00e9 que ZigBee \u00e9tait mort et qu'il \u00e9tait temps d'enterrer la h\u00f4tesse de l'air. Pour faire bonne figure face \u00e0 la situation avec Thread, qui fonctionne sur IPv6 et 6LowPan, il suffit d'un Bluetooth (LE) mieux adapt\u00e9 \u00e0 cela. Mais j'en parlerai un autre jour. Aujourd'hui, je vais expliquer comment le groupe de travail du comit\u00e9 a s\u00e9rieusement r\u00e9fl\u00e9chi une seconde fois apr\u00e8s le 802.11ah et a d\u00e9cid\u00e9 qu'il \u00e9tait temps d'ajouter au pool des standards 802.11 une version compl\u00e8te de quelque chose comme LRLP (Long-Range Low-Power), similaire \u00e0 LoRA. Cependant, cela s'est av\u00e9r\u00e9 irr\u00e9alisable sans sacrifier la vache sacr\u00e9e de la r\u00e9trocompatibilit\u00e9. Finalement, ils ont renonc\u00e9 au Long-Range et ne sont rest\u00e9s qu'avec le Low-Power, ce qui est \u00e9galement tr\u00e8s bien. Cela a donn\u00e9 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\u00e7ue pour les compl\u00e9ter.
\n<\/a><\/noindex>
\nCommen\u00e7ons par l'essentiel \u2014 Les appareils prenant en charge 802.11ba doivent maintenant avoir deux modules radio. Il semble qu\u2019apr\u00e8s avoir observ\u00e9 les 802.11ah\/ax avec leur technologie Target Wake Time (TWT), les ing\u00e9nieurs ont d\u00e9cid\u00e9 que cela ne suffisait pas et qu'il fallait r\u00e9duire radicalement la consommation d'\u00e9nergie. Pour cela, la norme pr\u00e9voit une s\u00e9paration en deux types de radio diff\u00e9rents \u2014 Radio de communication principale (PCR) et Radio de r\u00e9veil (WUR). Pour la premi\u00e8re, tout est clair : c'est le radio principal qui transmet et re\u00e7oit des donn\u00e9es, mais pour la seconde, ce n'est pas si \u00e9vident. En fait, le WUR est principalement un dispositif d'\u00e9coute (RX) et doit consommer tr\u00e8s peu d'\u00e9nergie pour fonctionner. Sa t\u00e2che principale est de recevoir un signal de r\u00e9veil de l'AP et d'activer le PCR. En d'autres termes, cette m\u00e9thode r\u00e9duit consid\u00e9rablement le temps de d\u00e9marrage \u00e0 froid et permet de r\u00e9veiller les appareils \u00e0 des moments pr\u00e9cis. Cela est particuli\u00e8rement utile lorsque vous avez, disons, pas dix appareils, mais cent dix, et que vous devez \u00e9changer des donn\u00e9es avec chacun d'eux en peu de temps. De plus, la logique de fr\u00e9quence et de p\u00e9riodicit\u00e9 de r\u00e9veil est d\u00e9plac\u00e9e du c\u00f4t\u00e9 de l'AP. Alors que, par exemple, dans LoRAWAN, une m\u00e9thodologie PUSH est utilis\u00e9e o\u00f9 les dispositifs ex\u00e9cutifs se r\u00e9veillent et transmettent quelque chose dans l'air, puis dorment le reste du temps, ici, c'est l'inverse : l'AP d\u00e9cide de quel appareil doit se r\u00e9veiller, et les dispositifs ex\u00e9cutifs... ne dorment pas toujours.<\/p>\n

Passons maintenant aux formats de trame et \u00e0 la garantie de compatibilit\u00e9. Si le 802.11ah, en tant que premi\u00e8re tentative, \u00e9tait con\u00e7u pour les bandes 868\/915 MHz, ou simplement SUB-1GHz, le 802.11ba est d\u00e9j\u00e0 destin\u00e9 aux plages de 2,4 GHz et 5 GHz. Dans les pr\u00e9c\u00e9dentes \u00ab nouvelles \u00bb normes, la compatibilit\u00e9 \u00e9tait obtenue gr\u00e2ce \u00e0 un pr\u00e9ambule compr\u00e9hensible par les anciens appareils. En d'autres termes, on s'appuyait sur le fait que les anciens appareils n'avaient en r\u00e9alit\u00e9 pas besoin de reconna\u00eetre l'int\u00e9gralit\u00e9 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\u00e9ambule. Le 802.11ba n'a pas fait exception, car le sch\u00e9ma a \u00e9t\u00e9 \u00e9prouv\u00e9 et test\u00e9 (la question des co\u00fbts est pour l'instant mise de c\u00f4t\u00e9).<\/p>\n

Ainsi, une trame 802.11ba ressemble \u00e0 ceci :<\/p>\n

\"802.11ba
\n
\nLa pr\u00e9ambule Non-HT et le bref fragment OFDM avec modulation BPSK permettent \u00e0 tous les dispositifs 802.11a\/g\/n\/ac\/ax d'entendre le d\u00e9but de la transmission de ce cadre et de ne pas interf\u00e9rer, passant en mode \u00e9coute. Apr\u00e8s le pr\u00e9ambule, il y a le champ de synchronisation (SYNC) qui est en essence l'analogue de L-STF\/L-LTF. Il sert \u00e0 ajuster la fr\u00e9quence et \u00e0 synchroniser le r\u00e9cepteur de l'appareil. \u00c0 ce moment pr\u00e9cis, l'appareil \u00e9metteur passe \u00e0 une largeur de canal diff\u00e9rente de 4 MHz. Pourquoi ? C'est tr\u00e8s simple. Cela permet de r\u00e9duire 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\u00e9e de transmission significativement augment\u00e9e. Je dirais que c'est une solution assez \u00e9l\u00e9gante, de plus, elle permet de r\u00e9duire consid\u00e9rablement les exigences en mati\u00e8re d'alimentation. Rappelons, par exemple, le populaire ESP8266. En mode transmission avec un d\u00e9bit 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\u00e9duit la largeur de canal par cinq et la puissance de l'\u00e9metteur par cinq, nous ne perdons pratiquement pas en port\u00e9e de transmission, mais nous allons consid\u00e9rablement r\u00e9duire le courant de consommation, disons, \u00e0 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\u00eame appr\u00e9ciable. 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\u00e7ues pour un stockage prolong\u00e9 d'\u00e9nergie avec de faibles courants nominales de d\u00e9charge. Bien s\u00fbr, il n'y a rien de gratuit et la r\u00e9duction de la largeur de canal entra\u00eenera une diminution de la vitesse de canal avec une augmentation du temps de transmission d'un cadre en cons\u00e9quence. <\/p>\n

\u00c0 propos de la vitesse de canal. La norme sous sa forme actuelle pr\u00e9voit 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\u00e9 spectrale. En fin de compte, le rayon d'action des dispositifs 802.11ba devrait \u00eatre sup\u00e9rieur, ce qui est particuli\u00e8rement utile pour les sc\u00e9narios IoT \u00e0 l'int\u00e9rieur.<\/p>\n

Mais attendez une minute... Forcer toutes les stations environnantes \u00e0 se taire en utilisant seulement 4 MHz de la bande de 20 MHz... \u00abC'EST UN GASPILLAGE!\u00bb - diriez-vous, et vous auriez raison. Mais non, VOICI LE VRAI GASPILLAGE!<\/p>\n

\"802.11ba
\n
\nLa norme permet d'utiliser des sous-canaux de 40 MHz et 80 MHz. De plus, les d\u00e9bits de chaque sous-canal peuvent \u00eatre diff\u00e9rents, et pour correspondre dans le temps, un Padding est ajout\u00e9 \u00e0 la fin de la trame. Ainsi, un appareil peut occuper le temps d'uzid \u00e0 tous les 80 MHz, mais n'utiliser que 16 MHz. L\u00e0, c'est vraiment un gaspillage.<\/p>\n

Au fait, les dispositifs Wi-Fi environnants n'ont aucune chance de comprendre ce qui est diffus\u00e9 dans l'air. Parce que pour coder les trames 802.11ba, le traditionnel OFDM qu'ils connaissent n'est PAS utilis\u00e9. Oui, c'est ainsi que l'alliance a abandonn\u00e9 ce qui fonctionnait sans faille pendant de nombreuses ann\u00e9es. Au lieu du classique OFDM, on utilise la modulation Multi-Carrier (MC)-OOK. Le canal de 4 MHz est divis\u00e9 en 16(?) sous-porteuses, chacune utilisant un codage de Manchester. De plus, le champ DATA lui-m\u00eame est logiquement divis\u00e9 en segments de 4 \u03bcs ou 2 \u03bcs selon le d\u00e9bit, et dans chaque segment, un niveau de codage peut r\u00e9pondre \u00e0 un niveau bas ou \u00e9lev\u00e9. C'est une solution pour \u00e9viter de longues s\u00e9quences de z\u00e9ros ou de uns. Du scrambling \u00e0 minima.<\/p>\n

\"802.11ba
\n
\nLe niveau MAC est \u00e9galement extr\u00eamement simplifi\u00e9. Il ne contient que les champs suivants :<\/p>\n