For ikke så lenge siden, på forskjellige andre ressurser og i bloggen min, snakket jeg om det faktum at ZigBee er død og det er på tide å begrave flyvertinnen. For å sette et godt ansikt på et dårlig spill med Thread som fungerer på toppen av IPv6 og 6LowPan, er Bluetooth (LE) som er mer egnet for dette tilstrekkelig. Men jeg skal fortelle deg om dette en annen gang. I dag skal vi snakke om hvordan komiteens arbeidsgruppe bestemte seg for å tenke seg om to ganger etter 802.11ah og bestemte at det var på tide å legge til en fullverdig versjon av noe som LRLP (Long-Range Low-Power) til utvalget av 802.11-standarder, lignende. til LoRA. Men dette viste seg å være umulig å gjennomføre uten å slakte den hellige kua av bakoverkompatibilitet. Som et resultat ble Long-Range forlatt og bare Low-Power gjensto, noe som også er veldig bra. Resultatet ble en blanding av 802.11 + 802.15.4, eller rett og slett Wi-Fi + ZigBee. Det vil si at vi kan si at den nye teknologien ikke er en konkurrent til LoraWAN-løsninger, men tvert imot blir skapt for å utfylle dem.
Så la oss starte med det viktigste – Nå skal enheter som støtter 802.11ba ha to radiomoduler. Tilsynelatende, etter å ha sett på 802.11ah/ax med Target Wake Time (TWT)-teknologien, bestemte ingeniørene at dette ikke var nok, og at de måtte redusere strømforbruket radikalt. Hvorfor standarden legger opp til en inndeling i to forskjellige typer radio - Primær kommunikasjonsradio (PCR) og Wake-Up Radio (WUR). Hvis alt er klart med den første, dette er hovedradioen, den sender og mottar data, så er det ikke så mye med den andre. Faktisk er WUR for det meste en lytteenhet (RX) og er designet for å bruke svært lite strøm for å betjene. Hovedoppgaven er å motta et vekkesignal fra AP og aktivere PCR. Det vil si at denne metoden reduserer kaldstarttiden betydelig og lar deg vekke enheter på et gitt tidspunkt med maksimal nøyaktighet. Dette er veldig nyttig når du for eksempel ikke har ti enheter, men hundre og ti og du trenger å utveksle data med hver av dem i løpet av kort tid. I tillegg flytter logikken til frekvensen og periodisiteten til oppvåkning til AP-siden. Hvis for eksempel LoRAWAN bruker PUSH-metodikk når aktuatorene selv våkner og sender noe i luften, og sover resten av tiden, så i dette tilfellet, tvert imot, bestemmer AP når og hvilken enhet som skal våkne, og aktuatorene selv... sover ikke alltid.
La oss nå gå videre til rammeformater og kompatibilitet. Hvis 802.11ah, som det første forsøket, ble opprettet for 868/915 MHz-båndene eller bare SUB-1GHz, så er 802.11ba allerede ment for 2.4GHz- og 5GHz-båndene. I tidligere "nye" standarder ble kompatibilitet oppnådd gjennom en ingress som var forståelig for eldre enheter. Det vil si at regnestykket alltid har vært at eldre enheter ikke nødvendigvis trenger å kunne gjenkjenne hele rammen, det er nok for dem å forstå når denne rammen begynner og hvor lenge overføringen vil vare. Det er denne informasjonen de henter fra ingressen. 802.11ba var intet unntak, siden ordningen er bevist og utprøvd (vi vil ignorere spørsmålet om kostnader foreløpig).
Som et resultat ser 802.11ba-rammen omtrent slik ut:
En ikke-HT-preamble og et kort OFDM-fragment med BPSK-modulasjon gjør at alle 802.11a/g/n/ac/ax-enheter kan høre begynnelsen av overføringen av denne rammen og ikke forstyrre, gå inn i kringkastingslyttemodus. Etter ingressen kommer synkroniseringsfeltet (SYNC), som i hovedsak er en analog av L-STF/L-LTF. Det tjener til å gjøre det mulig å justere frekvensen og synkronisere enhetens mottaker. Og det er i dette øyeblikket at sendeenheten bytter til en annen kanalbredde på 4 MHz. For hva? Alt er veldig enkelt. Dette er nødvendig for at effekten skal kunne reduseres og et sammenlignbart signal-til-støyforhold (SINR) kan oppnås. Eller la strømmen være som den er og oppnå en betydelig økning i overføringsrekkevidden. Jeg vil si at dette er en veldig elegant løsning, som også lar en redusere kravene til strømforsyninger betraktelig. La oss for eksempel huske den populære ESP8266. I overføringsmodus som bruker en bitrate på 54 Mbps og en effekt på 16dBm, bruker den 196 mA, noe som er uoverkommelig høyt for noe sånt som CR2032. Hvis vi reduserer kanalbredden med fem ganger og reduserer sendereffekten med fem ganger, vil vi praktisk talt ikke miste i overføringsrekkevidden, men strømforbruket vil reduseres med en faktor på for eksempel til omtrent 50 mA. Ikke at dette er kritisk fra den delen av AP som overfører rammen for WUR, men det er fortsatt ikke dårlig. Men for STA er dette allerede fornuftig, siden lavere forbruk tillater bruk av noe som CR2032 eller batterier designet for langsiktig energilagring med lave nominelle utladningsstrømmer. Selvfølgelig kommer ingenting gratis og reduksjon av kanalbredden vil føre til en reduksjon i kanalhastighet med en økning i sendetiden til henholdsvis én ramme.
Forresten, om kanalhastighet. Standarden i sin nåværende form gir to alternativer: 62.5 Kbps og 250 Kbps. Kjenner du lukten av ZigBee? Dette er ikke lett, siden den har en kanalbredde på 2Mhz i stedet for 4Mhz, men en annen type modulasjon med høyere spektral tetthet. Som et resultat bør rekkevidden av 802.11ba-enheter være større, noe som er veldig nyttig for innendørs IoT-scenarier.
Skjønt, vent et øyeblikk... Tvinger alle stasjonene i området til å være stille, mens du bruker bare 4 MHz av 20 MHz-båndet... "DET ER AVFALL!" - vil du si og du vil ha rett. Men nei, DETTE ER DET EKTE AVFALLET!
Standarden gir muligheten til å bruke 40 MHz og 80 MHz underkanaler. I dette tilfellet kan bithastighetene til hver underkanal være forskjellige, og for å matche kringkastingstiden legges Padding til på slutten av rammen. Det vil si at enheten kan oppta sendetid på alle 80 MHz, men bruke den kun på 16 MHz. Dette er ekte avfall.
Forresten, omkringliggende Wi-Fi-enheter har ingen sjanse til å forstå hva som sendes der. Fordi den vanlige OFDM IKKE brukes til å kode 802.11ba-rammer. Ja, akkurat slik forlot alliansen som kjent det som hadde fungert feilfritt i mange år. I stedet for klassisk OFDM brukes Multi-Carrier (MC)-OOK-modulasjon. 4MHz-kanalen er delt inn i 16(?) underbærere, som hver bruker Manchester-koding. Samtidig er selve DATA-feltet også logisk delt inn i segmenter på 4 μs eller 2 μs avhengig av bitrate, og i hvert slikt segment kan et lavt eller høyt kodingsnivå tilsvare ett. Dette er løsningen for å unngå en lang sekvens av nuller eller enere. Krafting mot minstelønn.
MAC-nivået er også ekstremt forenklet. Den inneholder bare følgende felt:
- Rammekontroll
Kan ta verdiene Beacon, WuP, Discovery eller en hvilken som helst annen verdi etter leverandørens valg.
Beacon brukes til tidssynkronisering, WuP er designet for å vekke en eller en gruppe enheter, og Discovery fungerer i motsatt retning fra STA til AP og er designet for å finne tilgangspunkter som støtter 802.11ba. Dette feltet inneholder også lengden på rammen hvis den overskrider 48 biter. - ID
Avhengig av typen ramme, kan den identifisere en AP, eller en STA, eller en gruppe STA-er som denne rammen er ment for. (Ja, du kan vekke enheter i grupper, det kalles groupcast wake-ups og det er ganske kult).
- Typeavhengig (TD)
Ganske fleksibelt felt. Det er i den at den nøyaktige tiden kan overføres, et signal om en firmware/konfigurasjonsoppdatering med et versjonsnummer, eller noe nyttig som STA bør vite om.
- Frame Checksum Field (FCS)
Alt er enkelt her. Dette er en sjekksum
Men for at teknologien skal fungere, er det ikke nok å bare sende en ramme i ønsket format. STA og AP må være enige. STA rapporterer sine parametere, inkludert tiden som kreves for å initialisere PCR. All forhandling skjer ved bruk av vanlige 802.11-rammer, hvoretter STA kan deaktivere PCR og gå inn i WUR-aktiveringsmodus. Eller kanskje til og med få litt søvn, hvis det er mulig. For hvis det finnes, så er det bedre å bruke det.
Deretter kommer litt mer utklemming av dyrebare milliampetimer kalt WUR Duty Cycle. Det er ikke noe komplisert, bare STA og AP, analogt med hvordan det var for TWT, er enige om en søvnplan. Etter dette sover STA for det meste, og skrur av og til på WUR for å lytte til «Har det kommet noe nyttig for meg?» Og bare om nødvendig vekker den hovedradiomodulen for trafikkutveksling.
Endrer situasjonen radikalt sammenlignet med TWT og U-APSD, ikke sant?
Og nå en viktig nyanse som du ikke umiddelbart tenker på. WUR trenger ikke å operere på samme frekvens som hovedmodulen. Tvert imot er det ønskelig og anbefalt at det fungerer på en annen kanal. I dette tilfellet forstyrrer ikke 802.11ba-funksjonaliteten på noen måte driften av nettverket, og kan tvert imot brukes til å sende nyttig informasjon. Plassering, Naboliste og mye mer innenfor andre 802.11-standarder, for eksempel 802.11k/v. Og hvilke fordeler åpner opp for Mesh-nettverk... Men dette er tema for en egen artikkel.
Når det gjelder skjebnen til selve standarden som et dokument, altså . Det vil si at i år kan vi forvente en reell standard eller i det minste de første implementeringene. Bare tiden vil vise hvor utbredt det blir.
Slike ting... (c) .
Anbefalt lesing:
Kilde: www.habr.com