For nylig har jeg på forskellige andre platforme og på min blog fortalt, at ZigBee er død, og at det er på tide at begrave det. For at få et godt ansigt på trods af de dårlige kort med Thread, som kører over IPv6 og 6LowPan, er det tilstrækkeligt med et mere tilpasset Bluetooth (LE). Men det vil jeg tage op en anden gang. I dag skal vi tale om, hvordan arbejdsgruppen i komiteen efter nøje overvejelse har besluttet, at det er tid til at tilføje en fuld variant af noget, der ligner LRLP (Long-Range Low-Power) til standarderne i 802.11, inspireret af LoRA. Men det viste sig at være umuligt uden at skære i den hellige ko af bagudkompatibilitet. I sidste ende opgav de Long-Range og beholdt kun Low-Power, hvilket også er ganske godt. Resultatet blev en blanding af 802.11 + 802.15.4, eller simpelthen Wi-Fi + ZigBee. Det kan altså siges, at den nye teknologi ikke er en konkurrent til LoraWAN-løsninger, men derimod er designet til at supplere dem.
Lad os begynde med det vigtigste — Nu skal der være to radiomoduler i enheder, der understøtter 802.11ba. Tilsyneladende, efter at have set på 802.11ah/ax med deres teknologi Target Wake Time (TWT), besluttede ingeniørerne, at dette ikke var tilstrækkeligt, og at energiforbruget radikalt skulle reduceres. Standardiseringen foreskriver derfor opdeling i to forskellige typer radio — Primary Communication Radio (PCR) og Wake-Up Radio (WUR). Det er klart, hvad den første er; det er hovedradioen, der sender og modtager data, men det er ikke så klart angående den anden. Faktisk repræsenterer WUR mest af alt en lytteenhed (RX) og er designet til at forbruge meget lidt energi i drift. Dens primære opgave er at modtage vækningsignalet fra AP og aktivere PCR. Dette betyder, at metoden betydeligt reducerer koldstartstiden og gør det muligt at vække enheder på bestemte tidspunkter med maksimal præcision. Dette er særligt nyttigt, når du har, lad os sige, ikke ti enheder, men hundrede og ti, og skal udveksle data med hver af dem inden for en kort periode. Derudover flyttes logikken for frekvens og vækningsfrekvens til siden af AP. Hvis der i LoRAWAN bruges en PUSH-metodologi, hvor de udførende enheder selv vågner op og sender noget i æteren, mens de sover det meste af tiden, er det omvendt i dette tilfælde; AP bestemmer, hvornår og hvilken enhed der skal vækkes, og de udførende enheder... sover ikke altid.
Lad os nu se på rammeformater og sikre kompatibilitet. Hvis 802.11ah som første forsøg blev udviklet til områderne 868/915 MHz eller blot SUB-1GHz, er 802.11ba nu designet til områderne 2.4GHz og 5GHz. I de tidligere «nye» standarder blev kompatibilitet opnået ved hjælp af en præambel, som var forståelig for ældre enheder. Det vil sige, at tanken altid har været, at ældre enheder ikke nødvendigvis behøver at kunne genkende hele rammen; det er tilstrækkeligt at forstå, hvornår rammen starter, og hvor lang tid transmissionen vil vare. Det er netop denne information, de udtrækker fra præambelen. 802.11ba er ikke blevet en undtagelse, da denne skema har vist sig at være effektiv og gennemprøvet (omkostningsspørgsmålet lad os lægge til side for nu).
Som resultat ser rammen for 802.11ba således ud:
Non-HT præambel og kort fragment af OFDM med BPSK-modulering gør det muligt for alle enheder 802.11a/g/n/ac/ax at høre begyndelsen af transmissionen af denne ramme og ikke blande sig, mens de går i lyttemodus. Efter præambelen følger synkroniseringsfeltet (SYNC), som i bund og grund svarer til L-STF/L-LTF. Det tjener til at give mulighed for at justere frekvensen og synkronisere modtagerenheden. Og netop på dette tidspunkt skifter transmitteren til en anden kanalbredde på 4 MHz. Hvorfor? Det er meget enkelt. Det er nødvendigt for at reducere effekten og opnå et sammenligneligt signal-til-støj-forhold (SINR). Eller beholde effekten som den er og opnå en betydelig stigning i transmissionsafstand. Jeg vil sige, at dette er en ganske elegant løsning, der også muliggør betydelige krav til strømkilder. Lad os huske på den populære ESP8266. I transmissionsmode med en bitrate på 54 Mbps og en effekt på 16 dBm forbruger den 196 mA, hvilket er alt for meget for noget som CR2032. Hvis vi femdobbelt reducerer kanalbredden og femdobbelt reducerer transmitterens effekt, vil vi næsten ikke miste transmissionsafstanden, men strømforbruget vil falde markant, lad os sige ned til cirka 50 mA. Ikke at det er kritisk fra AP, som sender rammen til WUR, men det er stadig godt. Derimod giver det mening for STA, da et lavere forbrug muliggør brug af noget som CR2032 eller batterier designet til langvarig energilagring med lave nominale afladningsstrømme. Selvfølgelig er intet gratis, og reduktion af kanalbredden vil føre til et fald i kanalhastigheden med en tilsvarende stigning i transmissionstiden for en enkelt ramme.
For resten, angående kanalhastigheden. Standardet i sin nuværende form indebærer to varianter: 62,5 Kbps og 250 Kbps. Kan I mærke det, ZigBee her? Det er ikke uden grund, da den har en kanalbredde på 2 MHz i stedet for 4 MHz, men en anden type modulering med højere spektral densitet. I sidste ende skal rækkevidden for 802.11ba-enheder være større, hvilket er ganske nyttigt for IoT-scenarier indendørs.
Men vent nu lige et øjeblik... At få alle stationer i området til at tie stille, ved kun at bruge 4 MHz fra 20 MHz-båndet... "DET ER DA RÅDVELT!" - vil I sige, og I vil have ret. Men nej, HER ER DEN VIRKELIGE RÅDVELT!
Standardet indeholder muligheden for at bruge underkanaler på 40 MHz og 80 MHz. Samtidig kan bitraterne for hver underkanal variere, og for at synkronisere transmissions tiden tilføjes Padding i slutningen af rammerne. Det vil sige, at enheden kan optage sendetid på alle 80 MHz, men kun bruge det på 16 MHz. Det er nemlig rigtigt rådvildt.
For øvrigt har andre Wi-Fi-enheder ingen chance for at forstå, hvad der transmitteres i luften. Fordi traditionelt OFDM ikke bruges til kodning af 802.11ba-rammer. Ja, sådan valgte alliancen at give afkald på det, der havde fungeret fejlfrit i mange år. I stedet for klassisk OFDM anvendes Multi-Carrier (MC)-OOK moduleringsmetoden. 4MHz-kanalen opdeles i 16(?) bærere, hvor hver bærer bruger Manchester-kodning. Selve DATA-feltet er desuden logisk opdelt i segmenter på 4 µs eller 2 µs afhængigt af bitraten, og i hver af disse segmenter kan en enhed svare med et lavt eller højt kodningsniveau. Det er en sådan løsning for at undgå lange sekvenser af nuller eller ettere. Scrambling på minimumsniveau.
MAC-niveauet er også voldsomt forenklet. Det indeholder kun følgende felter:
- Frame Control
Kan tage værdierne Beacon, WuP, Discovery eller noget andet efter leverandørens valg.
Beacon bruges til tidsynkronisering, WuP er beregnet til at vække en eller flere enheder, og Discovery arbejder i omvendt retning fra STA til AP og er designet til at finde adgangspunkter, der understøtter 802.11ba. Desuden overføres længden af rammerne i dette felt, hvis de overstiger 48 bit. - ID
Afhængig af rammetypen kan det identificere AP, STA eller en gruppe STA, som denne ramme er beregnet til. (Ja, det er muligt at vække enheder i grupper, det kaldes groupcast wake-ups, og det er ret sjovt).
- Type Dependent (TD)
Et ret fleksibelt felt. Nettet præcise tid, signal om opdatering af firmware/konfiguration med versionsnummer eller noget nyttigt, som STA bør vide, kan sendes her.
- Frame Checksum Field (FCS)
Her er det enkelt. Det er checksummen.
Men for at teknologien skal fungere, er det ikke nok bare at sende en ramme i det rigtige format. STA og AP skal blive enige. STA giver sine parametre, inklusive den tid, der er nødvendig for at initialisere PCR. Al koordinering foregår ved hjælp af almindelige 802.11-rammer, hvorefter STA kan deaktivere PCR og overgå til WUR-aktiveringsmode. Og det kan endda tage en lille lur, hvis der er mulighed for det. For hvis muligheden er der, er det bedst at udnytte den.
Herefter begynder en yderligere udnyttelse af de dyrebare milliampere-timer kendt som WUR Duty Cycle. Der er ikke noget kompliceret i det, STA og AP bliver enige om en soveplan på samme måde, som de gjorde for TWT. Efter dette sover STA for det meste, mens den sporadisk aktiverer WUR for at lytte efter "Er der noget nyttigt til mig?". Og kun ved behov vækker den den primære radiomodul for at udveksle trafik.
Radikalt ændrer situationen sammenlignet med TWT og U-APSD, gør den ikke?
Og nu et vigtigt nøglepunkt, som man ikke straks tænker på. WUR behøver ikke nødvendigvis at fungere på den samme frekvens som den primære modul. Tværtimod er det ønskeligt og anbefalet, at det fungerer på en anden kanal. I så fald interfererer 802.11ba ikke med netværkets funktionalitet og kan derimod bruges til at sende nyttige oplysninger. Location, Neighbour List og meget mere inden for andre 802.11-standarder, såsom 802.11k/v. Og hvilke fordele det åbner op for Mesh-netværk... Men det er et særskilt emne.
Hvad angår skæbnen for selve standarden som dokument, så . Det vil sige, at man i år kan forvente en ægte standard eller i det mindste de første implementeringer. Og hvor meget den vil få udbredelse – det vil tiden vise.
Sådan er det… (c) .
Anbefalet litteratur til at sætte sig ind i:
Kilde: habr.com
