För inte så länge sedan, på olika andra resurser och i min blogg, pratade jag om det faktum att ZigBee är död och att det är dags att begrava flygvärdinnan. För att sätta ett bra ansikte på ett dåligt spel med Thread som fungerar ovanpå IPv6 och 6LowPan räcker det med Bluetooth (LE) som är mer lämpad för detta. Men jag ska berätta om detta någon annan gång. Idag ska vi prata om hur kommitténs arbetsgrupp bestämde sig för att tänka två gånger efter 802.11ah och beslutade att det var dags att lägga till en fullfjädrad version av något som LRLP (Long-Range Low-Power) till poolen av 802.11-standarder, liknande till LoRA. Men detta visade sig vara omöjligt att genomföra utan att slakta bakåtkompatibilitetens heliga kon. Som ett resultat övergavs Long-Range och bara Low-Power återstod, vilket också är mycket bra. Resultatet blev en blandning av 802.11 + 802.15.4, eller helt enkelt Wi-Fi + ZigBee. Det vill säga, vi kan säga att den nya tekniken inte är en konkurrent till LoraWAN-lösningar, utan tvärtom skapas för att komplettera dem.
Så, låt oss börja med det viktigaste - Nu bör enheter som stöder 802.11ba ha två radiomoduler. Tydligen, efter att ha tittat på 802.11ah/axe med dess Target Wake Time (TWT)-teknik, beslutade ingenjörerna att detta inte var tillräckligt och de behövde minska strömförbrukningen radikalt. Varför standarden ger en uppdelning i två olika typer av radio - Primary Communication Radio (PCR) och Wake-Up Radio (WUR). Om allt är klart med den första, det här är huvudradion, den sänder och tar emot data, så är det inte så mycket med den andra. Faktum är att WUR mestadels är en lyssningsenhet (RX) och är designad för att förbruka mycket lite ström för att fungera. Dess huvudsakliga uppgift är att ta emot en väckningssignal från AP och aktivera PCR. Det vill säga, den här metoden minskar kallstartstiden avsevärt och låter dig väcka enheter vid en given tidpunkt med maximal noggrannhet. Det här är väldigt användbart när du till exempel inte har tio enheter utan etthundratio och du behöver utbyta data med var och en av dem på kort tid. Dessutom flyttar logiken för frekvensen och periodiciteten för uppvaknande till AP-sidan. Om, säg, LoRAWAN använder PUSH-metodik när ställdonen själva vaknar och sänder något i luften, och sover resten av tiden, så i det här fallet, tvärtom, bestämmer AP när och vilken enhet som ska vakna, och själva ställdonen... sover inte alltid.
Låt oss nu gå vidare till ramformat och kompatibilitet. Om 802.11ah, som det första försöket, skapades för 868/915 MHz-banden eller helt enkelt SUB-1GHz, så är 802.11ba redan avsedd för 2.4GHz- och 5GHz-banden. I tidigare "nya" standarder uppnåddes kompatibilitet genom en ingress som var förståelig för äldre enheter. Det vill säga, beräkningen har alltid varit att äldre enheter inte nödvändigtvis behöver kunna känna igen hela ramen, det räcker för dem att förstå när denna ram kommer att börja och hur länge överföringen kommer att pågå. Det är denna information som de hämtar från ingressen. 802.11ba var inget undantag, eftersom systemet är beprövat och beprövat (vi ignorerar kostnadsfrågan tills vidare).
Som ett resultat ser 802.11ba-ramen ut ungefär så här:
En icke-HT-inledning och ett kort OFDM-fragment med BPSK-modulering tillåter alla 802.11a/g/n/ac/ax-enheter att höra början av sändningen av denna ram och inte störa, gå in i sändningslyssningsläge. Efter ingressen kommer synkroniseringsfältet (SYNC), som i huvudsak är en analog till L-STF/L-LTF. Det tjänar till att göra det möjligt att justera frekvensen och synkronisera enhetens mottagare. Och det är i detta ögonblick som sändningsenheten växlar till en annan kanalbredd på 4 MHz. För vad? Allt är väldigt enkelt. Detta är nödvändigt för att effekten ska kunna reduceras och ett jämförbart signal-brusförhållande (SINR) kan uppnås. Eller lämna kraften som den är och uppnå en betydande ökning av överföringsräckvidden. Jag skulle säga att detta är en mycket elegant lösning, som också gör att man kan minska kraven på strömförsörjning avsevärt. Låt oss komma ihåg till exempel den populära ESP8266. I sändningsläge med en bithastighet på 54 Mbps och en effekt på 16dBm förbrukar den 196 mA, vilket är oöverkomligt högt för något som CR2032. Om vi minskar kanalbredden med fem gånger och minskar sändareffekten med fem gånger, kommer vi praktiskt taget inte att förlora i överföringsräckvidd, men strömförbrukningen kommer att minskas med en faktor på, säg, till cirka 50 mA. Inte för att detta är kritiskt från AP:s sida som överför ramen för WUR, men det är fortfarande inte dåligt. Men för STA är detta redan vettigt, eftersom lägre förbrukning tillåter användning av något som CR2032 eller batterier designade för långtidslagring av energi med låga nominella urladdningsströmmar. Naturligtvis kommer ingenting gratis och en minskning av kanalbredden kommer att leda till en minskning av kanalhastigheten med en ökning av sändningstiden för en bildruta.
Förresten, om kanalhastighet. Standarden i sin nuvarande form ger två alternativ: 62.5 Kbps och 250 Kbps. Känner du lukten av ZigBee? Detta är inte lätt, eftersom den har en kanalbredd på 2Mhz istället för 4Mhz, men en annan typ av modulering med högre spektral densitet. Som ett resultat bör utbudet av 802.11ba-enheter vara större, vilket är mycket användbart för inomhus IoT-scenarier.
Men, vänta en minut... Tvingar alla stationer i området att vara tysta, samtidigt som du bara använder 4 MHz av 20 MHz-bandet... "DET ÄR SÖTT!" - du kommer att säga och du kommer att ha rätt. Men nej, DETTA ÄR DET RIKTIGA AVFALLET!
Standarden ger möjlighet att använda 40 MHz och 80 MHz underkanaler. I det här fallet kan bithastigheterna för varje underkanal vara olika, och för att matcha sändningstiden läggs utfyllnad till i slutet av ramen. Det vill säga att enheten kan uppta sändningstid på alla 80 MHz, men endast använda den på 16 MHz. Det här är riktigt avfall.
Omgivande Wi-Fi-enheter har förresten ingen chans att förstå vad som sänds där. Eftersom den vanliga OFDM INTE används för att koda 802.11ba-ramar. Ja, precis så övergav alliansen det som hade fungerat felfritt i många år. Istället för klassisk OFDM används Multi-Carrier (MC)-OOK-modulering. 4MHz-kanalen är uppdelad i 16(?) underbärvågor, som var och en använder Manchester-kodning. Samtidigt är själva DATA-fältet också logiskt uppdelat i segment på 4 μs eller 2 μs beroende på bithastigheten, och i varje sådant segment kan en låg eller hög kodningsnivå motsvara en. Detta är lösningen för att undvika en lång följd av nollor eller ettor. Krypta på minimilöner.
MAC-nivån är också extremt förenklad. Den innehåller bara följande fält:
- Ramkontroll
Kan ta värdena Beacon, WuP, Discovery eller något annat värde av säljarens val.
Beacon används för tidssynkronisering, WuP är designat för att väcka en eller en grupp enheter och Discovery arbetar i motsatt riktning från STA till AP och är designad för att hitta accesspunkter som stöder 802.11ba. Detta fält innehåller också längden på ramen om den överstiger 48 bitar. - ID
Beroende på typen av ram kan den identifiera en AP, eller en STA, eller en grupp av STA som denna ram är avsedd för. (Ja, du kan väcka enheter i grupper, det kallas groupcast wake-ups och det är ganska coolt).
- Typberoende (TD)
Ett ganska flexibelt område. Det är i den som den exakta tiden kan sändas, en signal om en firmware/konfigurationsuppdatering med ett versionsnummer, eller något användbart som STA bör känna till.
- Frame Checksum Field (FCS)
Allt är enkelt här. Detta är en kontrollsumma
Men för att tekniken ska fungera räcker det inte att bara skicka en ram i det format som krävs. STA och AP måste komma överens. STA rapporterar sina parametrar, inklusive den tid som krävs för att initiera PCR. All förhandling sker med vanliga 802.11-ramar, varefter STA kan inaktivera PCR och gå in i WUR-aktiveringsläge. Eller kanske till och med sova lite om möjligt. För om det finns så är det bättre att använda det.
Därefter kommer lite mer klämning av dyrbara milliampetimmar som kallas WUR Duty Cycle. Det är inget komplicerat, bara STA och AP, i analogi med hur det var för TWT, kommer överens om ett sömnschema. Efter detta sover STA mest, ibland sätter på WUR för att lyssna på "Har det kommit något användbart för mig?" Och bara vid behov väcker den huvudradiomodulen för trafikutbyte.
Förändrar situationen radikalt jämfört med TWT och U-APSD, eller hur?
Och nu en viktig nyans som du inte direkt tänker på. WUR behöver inte arbeta med samma frekvens som huvudmodulen. Tvärtom är det önskvärt och rekommenderat att det fungerar på en annan kanal. I det här fallet stör 802.11ba-funktionen inte på något sätt driften av nätverket och kan tvärtom användas för att skicka användbar information. Plats, grannlista och mycket mer inom andra 802.11-standarder, till exempel 802.11k/v. Och vilka fördelar öppnar upp för Mesh-nätverk... Men detta är ämnet för en separat artikel.
När det gäller ödet för själva standarden som ett dokument, alltså . Det vill säga, i år kan vi förvänta oss en riktig standard eller åtminstone de första implementeringarna. Bara tiden får utvisa hur utbrett det kommer att bli.
Sådana saker... (c) .
Rekommenderad läsning:
Källa: will.com