Inte sÄ lÀnge sedan berÀttade jag pÄ olika plattformar och i min blogg att ZigBee Àr död och att det Àr dags att begrava teknologin. För att göra en bra min vid ett dÄligt spel med Thread, som fungerar ovanpÄ IPv6 och 6LowPan, behövs det en mer anpassad version av Bluetooth (LE). Men det fÄr jag ta en annan gÄng. I dag handlar det om hur arbetsgruppen i kommittén kom pÄ andra tankar efter 802.11ah och beslutade att det var dags att lÀgga till en heltÀckande version av nÄgot som liknar LRLP (Long-Range Low-Power) i standarderna för 802.11, inspirerat av LoRA. Men det visade sig vara omöjligt utan att skÀra ner pÄ den heliga kon av bakÄtkompatibilitet. Resultatet blev att de avstod frÄn Long-Range och behöll enbart Low-Power, vilket ocksÄ Àr mycket bra. Det blev en blandning av 802.11 + 802.15.4 eller enkelt sagt Wi-Fi + ZigBee. SÄ man kan sÀga att den nya teknologin inte Àr en konkurrent till LoRaWAN-lösningar, utan snarare skapad för att komplettera dem.
SĂ„, lĂ„t oss börja med det mest grundlĂ€ggande â Nu ska enheter som stödjer 802.11ba ha tvĂ„ radiomoduler. Tydligen, efter att ha sett pĂ„ 802.11ah/ax med deras teknologi för mĂ„linriktad vakttid (TWT), bestĂ€mde ingenjörerna att detta inte var tillrĂ€ckligt och att energiförbrukningen behövde minska radikalt. För detta förutsĂ€tter standarden uppdelning i tvĂ„ olika typer av radio â PrimĂ€r Kommunikationsradio (PCR) och Vaknaradiomodul (WUR). Om det första Ă€r klart och tydligt, alltsĂ„ den huvudsakliga radion som sĂ€nder och tar emot data, sĂ„ Ă€r det andra mer oklart. Faktiskt sett Ă€r WUR i stort sett en lyssnande enhet (RX) och enligt planen ska den konsumera mycket lite energi för att fungera. Dess huvuduppgift Ă€r att ta emot ett vĂ€ckningssignal frĂ„n AP och aktivera PCR. Detta innebĂ€r att metoden avsevĂ€rt minskar tiden för kallstart och möjliggör att vĂ€cka enheter vid en angiven tid med maximal noggrannhet. Detta Ă€r mycket anvĂ€ndbart nĂ€r du kanske har inte tio enheter, utan hundra tio och behöver utbyta data med var och en av dem pĂ„ kort tid. Dessutom överförs logiken för frekvens och vĂ€ckningsperioder till AP. Om vi sĂ€ger att i LoRAWAN anvĂ€nds en PUSH-metodik dĂ€r utförandeenheterna sjĂ€lva vaknar och sĂ€nder nĂ„got, medan de andra tiden sover, sĂ„ Ă€r det i detta fall tvĂ€rtom; AP bestĂ€mmer nĂ€r och vilken enhet som ska vĂ€ckas, medan sjĂ€lva utförandeenheterna... inte alltid sover.
Nu gÄr vi vidare till ramformat och sÀkerstÀllande av kompatibilitet. Om 802.11ah som ett första försök skapades för frekvensomrÄdena 868/915 MHz eller helt enkelt SUB-1GHz, sÄ Àr 802.11ba redan avsett för frekvensomrÄdena 2.4GHz och 5GHz. I tidigare "nya" standarder uppnÄddes kompatibilitet genom att anvÀnda en preambel som var begriplig för Àldre enheter. Det vill sÀga, det har alltid varit sÄ att Àldre enheter inte nödvÀndigtvis behöver kunna kÀnna igen hela ramen, de mÄste bara förstÄ nÀr denna ram börjar och hur lÀnge överföringen kommer att pÄgÄ. Denna information fÄr de frÄn preamblen. 802.11ba Àr inget undantag, eftersom schemat Àr beprövat och vÀl fungerande (frÄgan om kostnader lÀmnar vi Ät sidan för nu).
Resultatet Àr att ramen för 802.11ba ser ut pÄ följande sÀtt:
Non-HT-preambulÀren och korta OFDM-fragmentet med BPSK-modulering gör att alla enheter 802.11a/g/n/ac/ax kan höra början av sÀndningen av detta paket och inte störa, utan gÄ in i lyssningslÀge. Efter preamblen följer synkroniseringsfÀltet (SYNC) som i praktiken Àr en motsvarighet till L-STF/L-LTF. Det syftar till att ge möjlighet att justera frekvensen och synkronisera mottagaren av enheten. Just i detta ögonblick vÀxlar sÀndande enhet till en annan kanalbredd pÄ 4 MHz. Varför? Det Àr ganska enkelt. Det Àr nödvÀndigt för att kunna sÀnka effekten och uppnÄ en jÀmförbar signal-till-brus-förhÄllande (SINR). Alternativt kan vi behÄlla effekten oförÀndrad och uppnÄ en betydande ökning av överföringsrÀckvidden. Jag skulle sÀga att det Àr en ganska elegant lösning, dessutom möjliggör den betydligt lÀgre krav pÄ strömförsörjningen. Vi kan till exempel tÀnka pÄ den populÀra ESP8266. I sÀndningslÀge, med en bitrate pÄ 54 Mbps och en effekt pÄ 16dBm, drar den 196 mA, vilket Àr oerhört mycket för nÄgot som CR2032. Om vi minskar kanalbredden fem gÄnger och sÀnker sÀndarteffekten fem gÄnger, kommer vi praktiskt taget inte förlora pÄ överföringsrÀckvidden, men strömförbrukningen kan sjunka till cirka 50 mA. Det Àr inte sÄ kritiskt ur AP:s synvinkel som sÀnder ramen för WUR, men i alla fall bra. För STA har det redan betydelse, eftersom en lÀgre förbrukning möjliggör anvÀndning av nÄgot som CR2032 eller batterier avsedda för lÄngvarig energigasmedling med lÄga nominella urladdningsström. Naturligtvis fÄr man ingenting gratis, och en minskning av kanalbredden leder till en minskning av kanalens hastighet med ökad överföringstid för ett paket.
Förresten, om kanalens hastighet. Standarden i dess nuvarande tillstÄnd tillhandahÄller tvÄ alternativ: 62,5 Kbps och 250 Kbps. KÀnner ni igen ZigBee? Det Àr ingen tillfÀllighet, eftersom det har en kanalbred pÄ 2 MHz istÀllet för 4 MHz, men en annan typ av modulering med högre spektral densitet. Som ett resultat bör rÀckvidden för 802.11ba-enheter vara större, vilket Àr fördelaktigt för IoT-scenarier inomhus.
Men vĂ€nta lite... Att tvinga alla stationer i omrĂ„det att vara tysta med endast 4 MHz av 20 MHz-bandet... "DET ĂR JU SLĂSERI!" - sĂ€ger ni, och ni har rĂ€tt. Men nej, DETTA ĂR VERKLIGT SLĂSERI!
Standarden har inbyggd möjlighet att anvÀnda underkanaler pÄ 40 MHz och 80 MHz. Samtidigt kan bithastigheterna för varje underkanal vara olika, och för att synkronisera sÀndningen lÀggs padding till i slutet av ramen. Det vill sÀga att enheten kan anvÀnda alla 80 MHz för sÀndning, men bara anvÀnda 16 MHz. Det Àr redan riktigt slöseri.
Förresten har de omgivande Wi-Fi-enheterna ingen chans att förstĂ„ vad som sĂ€nds i luften. För kodningen av 802.11ba-ramar anvĂ€nds INTE det vĂ€lbekanta OFDM. Ja, sĂ„ hĂ€r avfĂ€rdade alliansen nĂ„got som har fungerat felfritt i mĂ„nga Ă„r. IstĂ€llet för klassiskt OFDM anvĂ€nds Multi-Carrier (MC)-OOK-modulation. Kanalen pĂ„ 4MHz delas upp i 16(?) bĂ€rvĂ„gor, var och en som anvĂ€nder Manchester-kodning. Samtidigt Ă€r sjĂ€lva DATA-fĂ€ltet logiskt uppdelat i segment pĂ„ 4 ÎŒs eller 2 ÎŒs beroende pĂ„ bithastigheten, dĂ€r varje sĂ„dant segment kan representeras av en lĂ„g eller hög kodningsnivĂ„. En sĂ„dan lösning för att undvika lĂ„nga sekvenser av nollor eller ettor. Scrambling pĂ„ minimumnivĂ„.
MAC-nivÄn Àr ocksÄ oerhört förenklad. Den innehÄller endast följande fÀlt:
- Frame Control
Kan anta vÀrdena Beacon, WuP, Discovery eller vilken annan som helst av tillverkaren.
Beacon anvÀnds för tidsynkronisering, WuP Àr avsedd för att vÀcka en eller flera enheter, medan Discovery fungerar motsatt frÄn STA till AP och Àr skapad för att hitta accesspunkter som stöder 802.11ba. I det hÀr fÀltet överförs ocksÄ lÀngden pÄ ramen om den överstiger 48 bitar. - ID
Beroende pÄ typ av ram kan den identifiera AP, STA eller en grupp STA som denna ram Àr avsedd för. (Ja, det Àr möjligt att vÀcka enheter i grupper, det kallas groupcast wake-ups och Àr ganska coolt).
- Typberoende (TD)
En ganska flexibel fÀlt. I detta kan exakt tid, signal om uppdatering av firmware/konfiguration med versionsnummer eller nÄgot anvÀndbart som STA bör veta överföras.
- Frame Checksum Field (FCS)
HÀr Àr det enkelt. Det Àr checksumma.
Men för att teknologin ska fungera Àr det inte tillrÀckligt att bara skicka en ram i rÀtt format. STA och AP mÄste komma överens. STA meddelar sina parametrar, inklusive den tid som krÀvs för att initiera PCR. All överenskommelse sker med hjÀlp av vanliga 802.11-ramar, efter vilket STA kan stÀnga av PCR och gÄ in i WUR-aktiveringslÀget. STA kan till och med ta en liten tupplur, om det Àr möjligt. För om det Àr möjligt, Àr det bÀttre att utnyttja det.
DÀrefter börjar en liten pressning av vÀrdefulla milliampere-timmar som kallas WUR Duty Cycle. Det Àr inget komplicerat, bara STA och AP kommer överens om en sömnplan, precis som det gjorde för TWT. Efter detta sover STA mestadels, men slÄr pÄ WUR dÄ och dÄ för att lyssna: "Har det kommit nÄgot anvÀndbart för mig?". Och endast vid behov vÀcker den huvudradiomodulen för att byta trafik.
Det radikalt förÀndrar situationen jÀmfört med TWT och U-APSD, eller hur?
Och nu en viktig aspekt som man inte tÀnker pÄ direkt. WUR behöver inte nödvÀndigtvis arbeta pÄ samma frekvens som huvudmodulen. Snarare Àr det önskvÀrt och rekommenderas att den arbetar pÄ en annan kanal. PÄ sÄ sÀtt stör funktionaliteten i 802.11ba pÄ inget sÀtt nÀtverksdrift och kan tvÀrtom anvÀndas för att skicka nyttig information. Location, Neighbour List och mycket annat inom andra 802.11-standarder, till exempel 802.11k/v. Och vilka fördelar som öppnas för Mesh-nÀtverk... Men det Àr ett Àmne för en annan artikel.
NĂ€r det gĂ€ller ödet för sjĂ€lva standarddokumentet, sĂ„ . Det vill sĂ€ga, i Ă„r kan vi förvĂ€nta oss en riktig standard eller Ă„tminstone de första implementationerna. Och hur utbredd den kommer att bli â det kommer bara tiden att visa.
SÄ kan det gÄ... (c) .
Rekommenderad litteratur för fördjupning:
KĂ€lla: habr.com
