Nemrégiben más forrásoknál és a blogomban is beszéltem arról, hogy a ZigBee halott, és az idő eljött, hogy elverjük a búcsúztatásának. Ahhoz, hogy jó képet alkossunk a Threadről, amely az IPv6-on és 6LowPan-en működik, elegendő egy jobban alkalmazkodó Bluetooth (LE). De erről majd később mesélek. Ma arról lesz szó, hogy a bizottság munkacsoportja alaposan átgondolta a dolgot a 802.11ah után, és úgy döntöttek, hogy itt az ideje egy teljes értékű lehetőséget adni a 802.11 szabványok közé, valami hasonló LRLP (Long-Range Low-Power) bevezetésével, a LoRA példájára. De ez nem volt megvalósítható anélkül, hogy ne áldozzák fel a visszamenőleges kompatibilitás szent tehénjét. Végül a Long-Range-t elvetették, és csak a Low-Power maradt, ami szintén nagyon jó. Így egy 802.11 + 802.15.4 keverék jött létre, vagy egyszerűen Wi-Fi + ZigBee. Ezért azt mondhatjuk, hogy az új technológia nem a LoraWAN megoldások versenytársa, hanem éppen ellenkezőleg, azokat kiegészíteni hivatott.
Tehát kezdjük a legfontosabbal – Az 802.11ba-t támogató eszközökben mostantól két rádiómodulnak kell lennie. Úgy tűnik, hogy az 802.11ah/ax Target Wake Time (TWT) technológiáját figyelembe véve a mérnökök úgy döntöttek, hogy ez nem elegendő, és radikálisan csökkenteni kell az energiafogyasztást. Erre a célra a szabvány két különböző rádiótípust határoz meg – Primary Communication Radio (PCR) és Wake-Up Radio (WUR). A PCR funkciója világos, ez az alaprádió, amely adatokat továbbít és fogad, de a WUR nem annyira egyértelmű. Valójában a WUR nagyrészt egy figyelő eszköz (RX), és a tervek szerint nagyon kis mennyiségű energiát kell fogyasztania az működéshez. Fő feladata egy ébresztőjel fogadása az AP-tól, hogy aktiválja a PCR-t. Ez a módszer jelentősen csökkenti a hideg indítás időtartamát, és lehetővé teszi az eszközök ébresztését megadott időpontban, maximális pontossággal. Ez különösen hasznos, ha például nem tíz, hanem százhúsz eszköze van, és rövid időn belül adatokat kell cserélni mindegyikkel. Ráadásul az ébresztési idő és gyakoriság logikáját az AP kezeli. Míg a LoRAWAN-ban a PUSH módszertan alapján az eszközök maguk ébrednek fel és adnak át valamit az éterben, addig ebben az esetben éppen ellenkezőleg, az AP dönti el, mikor és melyik eszköznek kell felébrednie, miközben az eszközök… nem mindig alszanak.
Most térjünk át a keretformátumokra és a kompatibilitás biztosítására. Míg az 802.11ah mint első próbálkozás az 868/915 MHz-es, vagy egyszerűen SUB-1GHz-es tartományokhoz készült, az 802.11ba már a 2.4GHz-es és az 5GHz-es tartományokra van szánva. Az előző "új" szabványok esetében a kompatibilitást a régebbi eszközök számára érthető előtét segítségével biztosították. Ez azt jelenti, hogy a számítást mindig úgy végezték, hogy a régebbi eszközöknek nem feltétlenül kellett teljes egészében felismerniük a keretet, elegendő volt, hogy megértsék, mikor kezdődik a keret, és mennyi ideig tart a továbbítás. Ezt az információt az előtétből szerzik be. Az 802.11ba sem volt kivétel, mivel ez a megoldás bevált és kipróbált (az költségeket most mellőzzük).
A végeredmény, az 802.11ba kerete valahogy így néz ki:
A nem-HT preámba és a BPSK modulációval végzett OFDM rövid szegmense lehetővé teszi minden 802.11a/g/n/ac/ax eszköz számára, hogy hallja ennek a keretnek a továbbításának kezdetét, és ne avatkozzon be, átkapcsolva a rádió vételi üzemmódba. A preámba után szinkronizáló mező (SYNC) következik, amely lényegében az L-STF/L-LTF analógja. Ennek célja, hogy lehetővé tegye a frekvencia beállítását és a készülék vevőjének szinkronizálását. Éppen ebben a pillanatban az adóeszköz 4 MHz-es csatorna szélességre vált. Miért? Az egész nagyon egyszerű. Azért, hogy csökkenthessük a teljesítményt és elérjük a jelek és zajok arányának (SINR) megfelelő értékét. Vagy pedig megőrizzük a teljesítményt, és jelentősen megnöveljük a hatótávolságot. Azt mondanám, hogy ez egy nagyon elegáns megoldás, ami ráadásul jelentősen csökkenti az áramforrások igényét. Gondoljunk például a népszerű ESP8266-ra. 54 Mbps sebesség mellett és 16 dBm teljesítményével 196 mA-t fogyaszt, ami megdöbbentően sok valami CR2032-hez hasonlónak. Ha ötödezzük a csatornaszélességet és ötödezzük az adó teljesítményét, akkor majdnem nem veszítünk a hatótávolságból, viszont az áramfogyasztást drámaian csökkenthetjük, mondjuk körülbelül 50 mA-ra. Nem mintha kritikus lenne az AP szempontjából, amely a WUR-hoz keretet továbbít, de mindenképp jónak mondható. Viszont a STA esetében ez már értelmet nyer, mivel az alacsonyabb fogyasztás lehetővé teszi olyan elemek használatát, mint a CR2032, vagy olyan akkumulátorok, amelyek hosszú tárolásra vannak optimalizálva, alacsony névleges kisütési áramokkal. Természetesen semmi sem ingyenes, és a csatornaszélesség csökkentése a csatorna sebességének csökkenésével és a keret átküldési idejének megnövekedésével jár.
Egyébként a csatorna sebességről. A szabvány jelenlegi formájában két lehetőséget biztosít: 62.5 Kbps és 250 Kbps. Érezhető a ZigBee hatása? Ez nem véletlen, mivel annak csatornaszélessége 2 MHz a 4 MHz helyett, de egy másik modulációs típussal, amely nagyobb spektrális sűrűséggel bír. A végeredmény az, hogy az 802.11ba eszközök hatótávolsága nagyobb kell, hogy legyen, ami az IoT szcenáriók esetében belső helyiségekben nagyon jól jön.
Várjunk csak... Minden állomást arra kényszeríteni, hogy néma maradjon, csupán 4 MHz-et használva a 20 MHz sávból... "EZ MÉGIS CSAK PONTPONTOS!" - mondhatnád, és igazad lenne. De nem, EZ AZ IGAZI PONT-PONTOS!
A szabvány lehetőséget biztosít 40 MHz és 80 MHz alcsatornák használatára. Ilyen módon az alcsatornák bitrátái eltérőek lehetnek, és az időbeli egybeesés érdekében a keret végére Paddingot adnak. Tehát a berendezés az összes 80 MHz-en elfoglalhatja az adásidőt, de csak 16 MHz-et használhat. Ez már valóban pazar.
Egyébként a környező Wi-Fi eszközöknek esélyük sincs megérteni, mi is sugárzik a levegőben. Mert az 802.11ba keretek kódolásához nem használják a megszokott OFDM-et. Igen, így lökdösték ki a szövetség azt, ami évek óta megbízhatóan működött. A klasszikus OFDM helyett Multi-Carrier (MC)-OOK modulációt alkalmaznak. A 4 MHz-es csatorna 16(?) alhordozóra oszlik, mindegyik Manchester-kódolást használ. Emellett a DATA mező is logikailag 4 μs vagy 2 μs szakaszokra van osztva a bitrátától függően, és minden ilyen szakaszban az alacsony vagy magas kódolás szintje választható. Ilyen megoldás a hosszú 0 vagy 1 sorozatok elkerülésére. Minimalizált scramblálás.
A MAC szint is rendkívüli mértékben leegyszerűsödött. Csak az alábbi mezőket tartalmazza:
- Frame Control
Az értékek lehetnek Beacon, WuP, Discovery vagy bármilyen más választás a gyártótól.
A Beacon az idő szinkronizálására szolgál, a WuP az egy vagy csoport eszközök felébresztésére, míg a Discovery a STA-tól az AP felé működik, és a 802.11ba-t támogató hozzáférési pontok keresésére készült. Ezen a mezőn keresztül kerül átadásra a keret hossza is, ha az meghaladja a 48 bitet. - ) és
A kerettípus függvényében az AP, a STA vagy a célzott STA csoport azonosítására is képes. (Igen, eszközöket csoportban is fel lehet ébreszteni, ezt hívják groupcast wake-ups-nak, és elég menő dolog).
- Type Dependent (TD)
Elég rugalmas mező. Itt lehet átadni a pontos időt, jelzést a firmware/config frissítéséről a verziószámmal vagy valami hasznosat, amit a STA-nak tudnia kell.
- Frame Checksum Field (FCS)
Itt minden egyszerű. Ez a checksum.
De ahhoz, hogy a technológia működjön, nem elég csak a megfelelő formátumú képkockát küldeni. Az STA-nak és az AP-nak meg kell állapodniuk. Az STA közli a paramétereit, beleértve azt az időt is, amely a PCR inicializálásához szükséges. Az összes egyeztetés az 802.11-es keretek segítségével történik, majd az STA kikapcsolhatja a PCR-t és átléphet a WUR aktiválási módba. Sőt, ha van rá lehetőség, akár egy kicsit alhat is. Mert ha van ilyen lehetőség, érdemes kihasználni azt.
Ezután elkezdődik egy újabb kis erőfeszítés a WUR Duty Cycle elnevezésű drága milliampóra óra kiaknázására. Nincs benne semmi bonyolult, az STA és az AP a TWT-hez hasonlóan egyeztetik a alvási menetrendet. Ezután az STA főként alszik, ritkán bekapcsolva a WUR-t, hogy megnézze: „Nem érkezett-e valami hasznos számomra?”. Csak szükség esetén ébreszti fel a fő rádiómodult az adatforgalom cseréjére.
Alapvetően megváltoztatja a helyzetet a TWT és az U-APSD-hez képest, nem igaz?
Most egy fontos részlet, amelyről nem gondolkodunk először. A WUR-nek nem feltétlenül ugyanazon a frekvencián kell működnie, mint a fő modulnak. Éppen ellenkezőleg, kívánatos és ajánlott, hogy más csatornán működjön. Ilyen esetben az 802.11ba funkcionalitása semmilyen módon nem zavarja a hálózat működését, és éppen ellenkezőleg, felhasználható hasznos információk terjesztésére. Hely, szomszédlista és sok más az 802.11 más szabványai keretében, például 802.11k/v. És milyen előnyök nyílnak meg a Mesh hálózatok számára… De ez egy külön cikk témája.
Ami a szabvány sorsát illeti, mint dokumentum, . Tehát ebben az évben várható a valódi szabvány, vagy legalábbis az első megvalósítások. Hogy mennyire terjed el — csak az idő fogja megmutatni.
Ilyen dolgok… (c) .
Ajánlott irodalom a megismeréshez:
Forrás: habr.com
