No fa gaire, en diversos altres recursos i al meu bloc, vaig parlar del fet que ZigBee ha mort i és hora d'enterrar l'assistent de vol. Per tal de posar una bona cara a un joc dolent amb Thread treballant a sobre d'IPv6 i 6LowPan, n'hi ha prou amb el Bluetooth (LE) més adequat. Però d'això us ho parlaré en un altre moment. Avui parlarem de com el grup de treball del comitè va decidir pensar-s'ho dues vegades després de 802.11ah i va decidir que era hora d'afegir una versió completa d'alguna cosa com LRLP (Long-Range Low-Power) al conjunt d'estàndards 802.11, similars. a LoRA. Però això va resultar impossible d'implementar sense sacrificar la vaca sagrada de la retrocompatibilitat. Com a resultat, Long-Range es va abandonar i només quedava Low-Power, que també és molt bo. El resultat va ser una barreja de 802.11 + 802.15.4, o simplement Wi-Fi + ZigBee. És a dir, podem dir que la nova tecnologia no és competidora de les solucions LoraWAN, sinó que, al contrari, s'està creant per complementar-les.
Per tant, comencem amb el més important: ara els dispositius que admeten 802.11ba haurien de tenir dos mòduls de ràdio. Pel que sembla, després d'haver mirat 802.11ah/ax amb la seva tecnologia Target Wake Time (TWT), els enginyers van decidir que això no era suficient i que havien de reduir radicalment el consum d'energia. Per què l'estàndard preveu una divisió en dos tipus diferents de ràdio: ràdio de comunicació primària (PCR) i ràdio despertador (WUR). Si amb la primera tot està clar, aquesta és la ràdio principal, transmet i rep dades, després amb la segona no ho és tant. De fet, el WUR és principalment un dispositiu d'escolta (RX) i està dissenyat per consumir molt poca energia per funcionar. La seva tasca principal és rebre un senyal de despertar de l'AP i habilitar la PCR. És a dir, aquest mètode redueix significativament el temps d'arrencada en fred i permet despertar els dispositius en un moment determinat amb la màxima precisió. Això és molt útil quan tens, per exemple, no deu dispositius, sinó cent deu i necessites intercanviar dades amb cadascun d'ells en un període de temps curt. A més, la lògica de la freqüència i periodicitat del despertar es mou cap al costat AP. Si, per exemple, LoRAWAN utilitza la metodologia PUSH quan els mateixos actuadors es desperten i transmeten alguna cosa a l'aire i dormen la resta del temps, en aquest cas, per contra, l'AP decideix quan i quin dispositiu s'ha de despertar, i els propis actuadors... no sempre dormen.
Ara passem als formats de marc i la compatibilitat. Si 802.11ah, com a primer intent, es va crear per a les bandes de 868/915 MHz o simplement SUB-1GHz, aleshores 802.11ba ja està pensat per a les bandes de 2.4 GHz i 5 GHz. En els estàndards "nous" anteriors, la compatibilitat s'aconseguia mitjançant un preàmbul que era comprensible per als dispositius més antics. És a dir, el càlcul sempre ha estat que els dispositius més antics no necessàriament han de ser capaços de reconèixer tot el marc; n'hi ha prou que entenguin quan començarà aquest marc i quant durarà la transmissió. És aquesta informació la que treuen del preàmbul. 802.11ba no va ser una excepció, ja que l'esquema està provat i provat (de moment ignorarem el tema dels costos).
Com a resultat, el marc 802.11ba té un aspecte semblant a això:
Un preàmbul no HT i un fragment OFDM breu amb modulació BPSK permeten que tots els dispositius 802.11a/g/n/ac/ax escoltin l'inici de la transmissió d'aquesta trama i no interfereixin, entrant en mode d'escolta de difusió. Després del preàmbul ve el camp de sincronització (SYNC), que és essencialment un anàleg de L-STF/L-LTF. Serveix per fer possible ajustar la freqüència i sincronitzar el receptor del dispositiu. I és en aquest moment que el dispositiu transmissor canvia a un altre canal d'amplada de 4 MHz. Per a què? Tot és molt senzill. Això és necessari perquè la potència es pugui reduir i es pugui aconseguir una relació senyal-soroll (SINR) comparable. O deixar la potència tal com està i aconseguir un augment significatiu del rang de transmissió. Diria que aquesta és una solució molt elegant, que també permet reduir significativament els requisits de fonts d'alimentació. Recordem, per exemple, el popular ESP8266. En mode de transmissió utilitzant una taxa de bits de 54 Mbps i una potència de 16 dBm, consumeix 196 mA, que és prohibitiu per a alguna cosa com el CR2032. Si reduïm l'amplada del canal cinc vegades i la potència del transmissor cinc vegades, pràcticament no perdrem el rang de transmissió, però el consum actual es reduirà en un factor, per exemple, a uns 50 mA. No és que això sigui crític per part de l'AP que transmet el marc per a WUR, però encara no està malament. Però per a STA això ja té sentit, ja que un consum més baix permet l'ús d'alguna cosa com CR2032 o bateries dissenyades per a l'emmagatzematge d'energia a llarg termini amb corrents de descàrrega nominals baixes. Per descomptat, res no és gratuït i reduir l'amplada del canal comportarà una disminució de la velocitat del canal amb un augment del temps de transmissió d'un fotograma, respectivament.
Per cert, sobre la velocitat del canal. L'estàndard en la seva forma actual ofereix dues opcions: 62.5 Kbps i 250 Kbps. Sents l'olor de ZigBee? Això no és fàcil, ja que té una amplada de canal de 2 Mhz en lloc de 4 Mhz, però un tipus de modulació diferent amb una densitat espectral més alta. Com a resultat, el rang de dispositius 802.11ba hauria de ser més gran, cosa que és molt útil per a escenaris d'IoT interiors.
Tot i que, espereu un minut... Obligar a totes les estacions de la zona a estar en silenci, mentre s'utilitzen només 4 MHz de la banda de 20 MHz... "AIXÒ ÉS UN DESARROLL!" - diràs i tindràs raó. Però no, AQUEST ÉS EL REBAIXAT VERDIAL!
L'estàndard ofereix la possibilitat d'utilitzar subcanals de 40 MHz i 80 MHz. En aquest cas, les taxes de bits de cada subcanal poden ser diferents i, per tal de coincidir amb el temps d'emissió, s'afegeix Padding al final del fotograma. És a dir, el dispositiu pot ocupar temps d'aire en tots els 80 MHz, però només l'utilitza en 16 MHz. Això és un autèntic residu.
Per cert, els dispositius Wi-Fi circumdants no tenen cap possibilitat d'entendre què s'emet allà. Perquè l'OFDM habitual NO s'utilitza per codificar trames 802.11ba. Sí, així, l'aliança va abandonar el que havia funcionat perfectament durant molts anys. En lloc de l'OFDM clàssic, s'utilitza la modulació Multi-Carrier (MC)-OOK. El canal de 4 MHz es divideix en 16 (?) subportadores, cadascuna de les quals utilitza la codificació Manchester. Al mateix temps, el propi camp DATA també es divideix lògicament en segments de 4 μs o 2 μs depenent de la taxa de bits, i en cadascun d'aquests segments pot correspondre un nivell de codificació baix o alt. Aquesta és la solució per evitar una llarga seqüència de zeros o uns. Lluita pels salaris mínims.
El nivell MAC també està molt simplificat. Només conté els camps següents:
- Control de fotogrames
Pot prendre els valors Beacon, WuP, Discovery o qualsevol altre valor que el venedor triï.
Beacon s'utilitza per a la sincronització de l'hora, WuP està dissenyat per despertar un o un grup de dispositius, i Discovery funciona en la direcció oposada de STA a AP i està dissenyat per trobar punts d'accés compatibles amb 802.11ba. Aquest camp també conté la longitud del fotograma si supera els 48 bits. - ID
Depenent del tipus de trama, pot identificar un AP, o un STA, o un grup de STA al qual està destinat aquest marc. (Sí, podeu despertar els dispositius en grups, s'anomena despertars en grup i és força genial).
- Dependent del tipus (TD)
Un camp bastant flexible. És en ell on es pot transmetre l'hora exacta, un senyal sobre una actualització de firmware/configuració amb un número de versió, o alguna cosa útil que l'STA hauria de conèixer.
- Camp de suma de verificació de trama (FCS)
Aquí tot és senzill. Això és una suma de control
Però perquè la tecnologia funcioni, no n'hi ha prou amb enviar un marc en el format requerit. L'STA i l'AP han d'estar d'acord. L'STA informa dels seus paràmetres, inclòs el temps necessari per inicialitzar la PCR. Totes les negociacions es produeixen mitjançant fotogrames 802.11 normals, després dels quals l'STA pot desactivar la PCR i entrar en el mode d'habilitació WUR. O potser fins i tot dormir una mica, si és possible. Perquè si existeix, és millor utilitzar-lo.
A continuació, ve una mica més d'estrenyiment de precioses hores de mil·liampères anomenada WUR Duty Cycle. No hi ha res complicat, només STA i AP, per analogia amb com va ser per a TWT, acorden un horari de son. Després d'això, STA dorm principalment, de tant en tant activa WUR per escoltar "M'ha arribat alguna cosa útil?" I només si cal, desperta el mòdul de ràdio principal per a l'intercanvi de trànsit.
Canvia radicalment la situació en comparació amb TWT i U-APSD, no?
I ara un matís important que no penseu immediatament. El WUR no ha de funcionar a la mateixa freqüència que el mòdul principal. Al contrari, és desitjable i recomanable que funcioni en un canal diferent. En aquest cas, la funcionalitat 802.11ba no interfereix de cap manera amb el funcionament de la xarxa i, per contra, es pot utilitzar per enviar informació útil. Ubicació, llista de veïns i molt més dins d'altres estàndards 802.11, per exemple 802.11k/v. I quins avantatges s'obren per a les xarxes Mesh... Però aquest és el tema d'un article a part.
Pel que fa al destí de la pròpia norma com a document, doncs . És a dir, enguany podem esperar un estàndard real o almenys les primeres implementacions. Només el temps dirà quina extensió serà.
Aquestes coses... (c) .
Lectura recomanada:
Font: www.habr.com