For ikke så længe siden, på forskellige andre ressourcer og i min blog, talte jeg om, at ZigBee er død, og det er tid til at begrave stewardessen. For at sætte et godt ansigt på et dårligt spil med Thread, der arbejder oven på IPv6 og 6LowPan, er Bluetooth (LE), der er mere egnet til dette, tilstrækkeligt. Men jeg fortæller dig om det en anden gang. I dag vil vi tale om, hvordan udvalgets arbejdsgruppe besluttede at tænke sig om to gange efter 802.11ah og besluttede, at det var på tide at tilføje en fuldgyldig version af noget som LRLP (Long-Range Low-Power) til puljen af 802.11-standarder, lignende til LoRA. Men dette viste sig at være umuligt at implementere uden at slagte bagudkompatibilitetens hellige ko. Som et resultat blev Long-Range opgivet, og kun Low-Power var tilbage, hvilket også er meget godt. Resultatet var en blanding af 802.11 + 802.15.4 eller blot Wi-Fi + ZigBee. Det vil sige, at vi kan sige, at den nye teknologi ikke er en konkurrent til LoraWAN-løsninger, men tværtimod bliver skabt for at komplementere dem.
Så lad os starte med det vigtigste - Nu skal enheder, der understøtter 802.11ba, have to radiomoduler. Efter at have set på 802.11ah/axe med dens Target Wake Time (TWT) teknologi, besluttede ingeniørerne tilsyneladende, at dette ikke var nok, og at de skulle reducere strømforbruget radikalt. Hvorfor standarden giver mulighed for en opdeling i to forskellige typer radio - Primary Communication Radio (PCR) og Wake-Up Radio (WUR). Hvis alt er klart med den første, dette er hovedradioen, den sender og modtager data, så er det ikke så meget med den anden. Faktisk er WUR for det meste en lytteenhed (RX) og er designet til at bruge meget lidt strøm til at betjene. Dens hovedopgave er at modtage et vækkesignal fra AP og aktivere PCR. Det vil sige, at denne metode reducerer koldstartstiden betydeligt og giver dig mulighed for at vække enheder på et givet tidspunkt med maksimal nøjagtighed. Dette er meget nyttigt, når du f.eks. ikke har ti enheder, men hundrede og ti, og du skal udveksle data med hver af dem på kort tid. Plus, logikken i frekvensen og periodiciteten af opvågning flytter til AP-siden. Hvis f.eks. LoRAWAN bruger PUSH-metoden, når aktuatorerne selv vågner og transmitterer noget i luften og sover resten af tiden, så bestemmer AP i dette tilfælde tværtimod, hvornår og hvilken enhed der skal vågne, og selve aktuatorerne... sover ikke altid.
Lad os nu gå videre til rammeformater og kompatibilitet. Hvis 802.11ah, som det første forsøg, blev skabt til 868/915 MHz-båndene eller blot SUB-1GHz, så er 802.11ba allerede beregnet til 2.4GHz- og 5GHz-båndene. I tidligere "nye" standarder blev kompatibilitet opnået gennem en præamble, der var forståelig for ældre enheder. Det vil sige, at beregningen altid har været, at ældre enheder ikke nødvendigvis behøver at kunne genkende hele rammen, det er nok for dem at forstå, hvornår denne ramme begynder, og hvor længe transmissionen vil vare. Det er disse oplysninger, de tager fra præamblen. 802.11ba var ingen undtagelse, da ordningen er bevist og bevist (vi vil ignorere spørgsmålet om omkostninger for nu).
Som et resultat ser 802.11ba-rammen noget sådan ud:
En ikke-HT-præamble og et kort OFDM-fragment med BPSK-modulation gør det muligt for alle 802.11a/g/n/ac/ax-enheder at høre begyndelsen af transmissionen af denne ramme og ikke forstyrre, og gå i broadcast-lyttetilstand. Efter præamblen kommer synkroniseringsfeltet (SYNC), som i det væsentlige er en analog af L-STF/L-LTF. Det tjener til at gøre det muligt at justere frekvensen og synkronisere enhedens modtager. Og det er i dette øjeblik, at sendeenheden skifter til en anden kanalbredde på 4 MHz. For hvad? Alt er meget enkelt. Dette er nødvendigt, for at effekten kan reduceres og et sammenligneligt signal-til-støj-forhold (SINR) kan opnås. Eller lad strømmen være som den er og opnå en betydelig forøgelse af transmissionsrækkevidden. Jeg vil sige, at dette er en meget elegant løsning, som også gør, at man kan reducere kravene til strømforsyninger markant. Lad os for eksempel huske den populære ESP8266. I transmissionstilstand, der bruger en bitrate på 54 Mbps og en effekt på 16dBm, forbruger den 196 mA, hvilket er uoverkommeligt højt for noget som CR2032. Hvis vi reducerer kanalbredden med fem gange og reducerer sendereffekten med fem gange, vil vi praktisk talt ikke miste i transmissionsområdet, men strømforbruget vil blive reduceret med en faktor på for eksempel til omkring 50 mA. Ikke at dette er kritisk fra den side af AP, der transmitterer rammen for WUR, men det er stadig ikke dårligt. Men for STA giver dette allerede mening, da lavere forbrug tillader brugen af noget som CR2032 eller batterier designet til langsigtet energilagring med lave nominelle udladningsstrømme. Naturligvis kommer intet gratis, og reduktion af kanalbredden vil føre til et fald i kanalhastigheden med en stigning i transmissionstiden for henholdsvis en frame.
I øvrigt om kanalhastighed. Standarden i sin nuværende form giver to muligheder: 62.5 Kbps og 250 Kbps. Mærker du lugten af ZigBee? Dette er ikke nemt, da det har en kanalbredde på 2Mhz i stedet for 4Mhz, men en anden type modulering med højere spektraltæthed. Som et resultat bør rækkevidden af 802.11ba-enheder være større, hvilket er meget nyttigt til indendørs IoT-scenarier.
Selvom, vent et øjeblik... Tvinger alle stationerne i området til at være stille, mens du kun bruger 4 MHz af 20 MHz-båndet... "DETTE ER SPILD!" - vil du sige, og du vil have ret. Men nej, DETTE ER DET RIGTIGE AFFALD!
Standarden giver mulighed for at bruge 40 MHz og 80 MHz underkanaler. I dette tilfælde kan bithastighederne for hver underkanal være forskellige, og for at matche udsendelsestiden tilføjes Padding til slutningen af rammen. Det vil sige, at enheden kan optage sendetid på alle 80 MHz, men kun bruge den på 16 MHz. Dette er ægte affald.
I øvrigt har omkringliggende Wi-Fi-enheder ingen chance for at forstå, hvad der udsendes der. Fordi den sædvanlige OFDM IKKE bruges til at kode 802.11ba-rammer. Ja, bare sådan opgav alliancen berømt det, der havde fungeret upåklageligt i mange år. I stedet for klassisk OFDM bruges Multi-Carrier (MC)-OOK-modulation. 4MHz-kanalen er opdelt i 16(?) underbærere, som hver bruger Manchester-kodning. Samtidig er selve DATA-feltet også logisk opdelt i segmenter på 4 μs eller 2 μs afhængig af bitrate, og i hvert sådant segment kan et lavt eller højt kodningsniveau svare til et. Dette er løsningen for at undgå en lang sekvens af nuller eller ettaller. Krafter om mindstelønninger.
MAC-niveauet er også ekstremt forenklet. Den indeholder kun følgende felter:
- Rammekontrol
Kan tage værdierne Beacon, WuP, Discovery eller enhver anden værdi efter leverandørens valg.
Beacon bruges til tidssynkronisering, WuP er designet til at vække en eller en gruppe af enheder, og Discovery arbejder i den modsatte retning fra STA til AP og er designet til at finde adgangspunkter, der understøtter 802.11ba. Dette felt indeholder også længden af rammen, hvis den overstiger 48 bit. - ID
Afhængigt af typen af ramme kan den identificere en AP eller en STA eller en gruppe af STA'er, som denne ramme er beregnet til. (Ja, du kan vække enheder i grupper, det kaldes groupcast wake-ups, og det er ret fedt).
- Typeafhængig (TD)
Et ret fleksibelt felt. Det er i den, at det nøjagtige tidspunkt kan sendes, et signal om en firmware/konfigurationsopdatering med et versionsnummer, eller noget nyttigt, som STA bør vide om.
- Frame Checksum Field (FCS)
Alt er enkelt her. Dette er en kontrolsum
Men for at teknologien skal fungere, er det ikke nok blot at sende en ramme i det krævede format. STA og AP skal være enige. STA rapporterer sine parametre, herunder den tid, der kræves til at initialisere PCR. Al forhandling foregår ved hjælp af almindelige 802.11-rammer, hvorefter STA kan deaktivere PCR og gå ind i WUR-aktiveringstilstand. Eller måske endda få noget søvn, hvis det er muligt. For hvis det findes, så er det bedre at bruge det.
Dernæst kommer lidt mere klemning af dyrebare milliamperetimer kaldet WUR Duty Cycle. Der er ikke noget kompliceret, bare STA og AP, analogt med hvordan det var for TWT, er enige om en søvnplan. Herefter sover STA for det meste og tænder af og til WUR for at lytte til "Er der kommet noget nyttigt til mig?" Og kun hvis det er nødvendigt, vækker den hovedradiomodulet til trafikudveksling.
Ændrer situationen radikalt sammenlignet med TWT og U-APSD, gør det ikke?
Og nu en vigtig nuance, som du ikke umiddelbart tænker over. WUR behøver ikke at køre på samme frekvens som hovedmodulet. Tværtimod er det ønskeligt og anbefales, at det virker på en anden kanal. I dette tilfælde forstyrrer 802.11ba-funktionaliteten ikke på nogen måde driften af netværket og kan tværtimod bruges til at sende nyttige oplysninger. Placering, Naboliste og meget mere inden for andre 802.11-standarder, for eksempel 802.11k/v. Og hvilke fordele åbner der op for Mesh-netværk... Men dette er emnet for en separat artikel.
Hvad angår selve standardens skæbne som et dokument, altså . Det vil sige, at vi i år kan forvente en reel standard eller i hvert fald de første implementeringer. Kun tiden vil vise, hvor udbredt det bliver.
Sådanne ting... (c) .
Anbefalet læsning:
Kilde: www.habr.com