{"id":70827,"date":"2020-02-21T14:42:12","date_gmt":"2020-02-21T11:42:12","guid":{"rendered":"https:\/\/prohoster.info\/blog\/802-11ba-wur-ili-kak-skrestit-uzha-s-ezhom"},"modified":"2020-03-03T16:14:44","modified_gmt":"2020-03-03T13:14:44","slug":"802-11ba-wur-ili-kak-skrestit-uzha-s-ezhom","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/802-11ba-wur-ili-kak-skrestit-uzha-s-ezhom","title":{"rendered":"802.11ba (WUR) eller hvordan man krydser en hugorm med et pindsvin","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

For nylig har jeg p\u00e5 forskellige andre platforme og p\u00e5 min blog fortalt, at ZigBee er d\u00f8d, og at det er p\u00e5 tide at begrave det. For at f\u00e5 et godt ansigt p\u00e5 trods af de d\u00e5rlige kort med Thread, som k\u00f8rer over IPv6 og 6LowPan, er det tilstr\u00e6kkeligt 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\u00f8je overvejelse har besluttet, at det er tid til at tilf\u00f8je 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\u00e6re umuligt uden at sk\u00e6re i den hellige ko af bagudkompatibilitet. I sidste ende opgav de Long-Range og beholdt kun Low-Power, hvilket ogs\u00e5 er ganske godt. Resultatet blev en blanding af 802.11 + 802.15.4, eller simpelthen Wi-Fi + ZigBee. Det kan alts\u00e5 siges, at den nye teknologi ikke er en konkurrent til LoraWAN-l\u00f8sninger, men derimod er designet til at supplere dem.
\n<\/a><\/noindex>
\nLad os begynde med det vigtigste \u2014 Nu skal der v\u00e6re to radiomoduler i enheder, der underst\u00f8tter 802.11ba. Tilsyneladende, efter at have set p\u00e5 802.11ah\/ax med deres teknologi Target Wake Time (TWT), besluttede ingeni\u00f8rerne, at dette ikke var tilstr\u00e6kkeligt, og at energiforbruget radikalt skulle reduceres. Standardiseringen foreskriver derfor opdeling i to forskellige typer radio \u2014 Primary Communication Radio (PCR) og Wake-Up Radio (WUR). Det er klart, hvad den f\u00f8rste er; det er hovedradioen, der sender og modtager data, men det er ikke s\u00e5 klart ang\u00e5ende den anden. Faktisk repr\u00e6senterer WUR mest af alt en lytteenhed (RX) og er designet til at forbruge meget lidt energi i drift. Dens prim\u00e6re opgave er at modtage v\u00e6kningsignalet fra AP og aktivere PCR. Dette betyder, at metoden betydeligt reducerer koldstartstiden og g\u00f8r det muligt at v\u00e6kke enheder p\u00e5 bestemte tidspunkter med maksimal pr\u00e6cision. Dette er s\u00e6rligt nyttigt, n\u00e5r 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\u00e6kningsfrekvens til siden af AP. Hvis der i LoRAWAN bruges en PUSH-metodologi, hvor de udf\u00f8rende enheder selv v\u00e5gner op og sender noget i \u00e6teren, mens de sover det meste af tiden, er det omvendt i dette tilf\u00e6lde; AP bestemmer, hvorn\u00e5r og hvilken enhed der skal v\u00e6kkes, og de udf\u00f8rende enheder... sover ikke altid.<\/p>\n

Lad os nu se p\u00e5 rammeformater og sikre kompatibilitet. Hvis 802.11ah som f\u00f8rste fors\u00f8g blev udviklet til omr\u00e5derne 868\/915 MHz eller blot SUB-1GHz, er 802.11ba nu designet til omr\u00e5derne 2.4GHz og 5GHz. I de tidligere \u00abnye\u00bb standarder blev kompatibilitet opn\u00e5et ved hj\u00e6lp af en pr\u00e6ambel, som var forst\u00e5elig for \u00e6ldre enheder. Det vil sige, at tanken altid har v\u00e6ret, at \u00e6ldre enheder ikke n\u00f8dvendigvis beh\u00f8ver at kunne genkende hele rammen; det er tilstr\u00e6kkeligt at forst\u00e5, hvorn\u00e5r rammen starter, og hvor lang tid transmissionen vil vare. Det er netop denne information, de udtr\u00e6kker fra pr\u00e6ambelen. 802.11ba er ikke blevet en undtagelse, da denne skema har vist sig at v\u00e6re effektiv og gennempr\u00f8vet (omkostningssp\u00f8rgsm\u00e5let lad os l\u00e6gge til side for nu).<\/p>\n

Som resultat ser rammen for 802.11ba s\u00e5ledes ud:<\/p>\n

\"802.11ba
\n
\nNon-HT pr\u00e6ambel og kort fragment af OFDM med BPSK-modulering g\u00f8r det muligt for alle enheder 802.11a\/g\/n\/ac\/ax at h\u00f8re begyndelsen af transmissionen af denne ramme og ikke blande sig, mens de g\u00e5r i lyttemodus. Efter pr\u00e6ambelen f\u00f8lger 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\u00e5 dette tidspunkt skifter transmitteren til en anden kanalbredde p\u00e5 4 MHz. Hvorfor? Det er meget enkelt. Det er n\u00f8dvendigt for at reducere effekten og opn\u00e5 et sammenligneligt signal-til-st\u00f8j-forhold (SINR). Eller beholde effekten som den er og opn\u00e5 en betydelig stigning i transmissionsafstand. Jeg vil sige, at dette er en ganske elegant l\u00f8sning, der ogs\u00e5 muligg\u00f8r betydelige krav til str\u00f8mkilder. Lad os huske p\u00e5 den popul\u00e6re ESP8266. I transmissionsmode med en bitrate p\u00e5 54 Mbps og en effekt p\u00e5 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\u00e6sten ikke miste transmissionsafstanden, men str\u00f8mforbruget 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\u00f8r brug af noget som CR2032 eller batterier designet til langvarig energilagring med lave nominale afladningsstr\u00f8mme. Selvf\u00f8lgelig er intet gratis, og reduktion af kanalbredden vil f\u00f8re til et fald i kanalhastigheden med en tilsvarende stigning i transmissionstiden for en enkelt ramme. <\/p>\n

For resten, ang\u00e5ende kanalhastigheden. Standardet i sin nuv\u00e6rende form indeb\u00e6rer to varianter: 62,5 Kbps og 250 Kbps. Kan I m\u00e6rke det, ZigBee her? Det er ikke uden grund, da den har en kanalbredde p\u00e5 2 MHz i stedet for 4 MHz, men en anden type modulering med h\u00f8jere spektral densitet. I sidste ende skal r\u00e6kkevidden for 802.11ba-enheder v\u00e6re st\u00f8rre, hvilket er ganske nyttigt for IoT-scenarier indend\u00f8rs.<\/p>\n

Men vent nu lige et \u00f8jeblik... At f\u00e5 alle stationer i omr\u00e5det til at tie stille, ved kun at bruge 4 MHz fra 20 MHz-b\u00e5ndet... \"DET ER DA R\u00c5DVELT!\" - vil I sige, og I vil have ret. Men nej, HER ER DEN VIRKELIGE R\u00c5DVELT!<\/p>\n

\"802.11ba
\n
\nStandardet indeholder muligheden for at bruge underkanaler p\u00e5 40 MHz og 80 MHz. Samtidig kan bitraterne for hver underkanal variere, og for at synkronisere transmissions tiden tilf\u00f8jes Padding i slutningen af rammerne. Det vil sige, at enheden kan optage sendetid p\u00e5 alle 80 MHz, men kun bruge det p\u00e5 16 MHz. Det er nemlig rigtigt r\u00e5dvildt.<\/p>\n

For \u00f8vrigt har andre Wi-Fi-enheder ingen chance for at forst\u00e5, hvad der transmitteres i luften. Fordi traditionelt OFDM ikke bruges til kodning af 802.11ba-rammer. Ja, s\u00e5dan valgte alliancen at give afkald p\u00e5 det, der havde fungeret fejlfrit i mange \u00e5r. I stedet for klassisk OFDM anvendes Multi-Carrier (MC)-OOK moduleringsmetoden. 4MHz-kanalen opdeles i 16(?) b\u00e6rere, hvor hver b\u00e6rer bruger Manchester-kodning. Selve DATA-feltet er desuden logisk opdelt i segmenter p\u00e5 4 \u00b5s eller 2 \u00b5s afh\u00e6ngigt af bitraten, og i hver af disse segmenter kan en enhed svare med et lavt eller h\u00f8jt kodningsniveau. Det er en s\u00e5dan l\u00f8sning for at undg\u00e5 lange sekvenser af nuller eller ettere. Scrambling p\u00e5 minimumsniveau.<\/p>\n

\"802.11ba
\n
\nMAC-niveauet er ogs\u00e5 voldsomt forenklet. Det indeholder kun f\u00f8lgende felter:<\/p>\n