Nem is olyan régen számos más forráson és a blogomban beszéltem arról, hogy ZigBee meghalt, és ideje eltemetni a légiutas-kísérőt. Ahhoz, hogy jó arcot adjunk egy rossz játéknak, ha a Thread az IPv6-on és a 6LowPanon dolgozik, elegendő az erre alkalmas Bluetooth (LE). De erről majd máskor. Ma arról fogunk beszélni, hogy a bizottság munkacsoportja úgy döntött, hogy kétszer is meggondolja magát a 802.11ah után, és úgy döntött, hogy ideje felvenni az LRLP (Long-Range Low-Power) teljes értékű változatát a 802.11 szabványok készletébe. a LoRA-nak. De ez lehetetlennek bizonyult a visszafelé kompatibilitás szent tehenének levágása nélkül. Ennek eredményeként a Long-Range-et elhagyták, és csak a Low-Power maradt, ami szintén nagyon jó. Az eredmény a 802.11 + 802.15.4, vagy egyszerűen csak Wi-Fi + ZigBee keveréke lett. Azaz elmondhatjuk, hogy az új technológia nem a LoraWAN megoldások versenytársa, hanem éppen ellenkezőleg, azok kiegészítésére készül.
Kezdjük tehát a legfontosabb dologgal – a 802.11ba szabványt támogató eszközöknek két rádiómodullal kell rendelkezniük. Nyilvánvalóan a 802.11ah/ax technológiát vizsgálva a Target Wake Time (TWT) technológiájával a mérnökök úgy döntöttek, hogy ez nem elég, és radikálisan csökkenteni kell az energiafogyasztást. Miért írja elő a szabvány két különböző típusú rádió felosztását - elsődleges kommunikációs rádió (PCR) és Wake-Up rádió (WUR). Ha az elsőnél minden világos, ez a fő rádió, adatot ad és fogad, akkor a másodiknál már nem annyira. Valójában a WUR többnyire lehallgató eszköz (RX), és úgy tervezték, hogy nagyon kevés energiát fogyasztson a működéshez. Fő feladata az AP-tól ébresztő jel vétele és a PCR engedélyezése. Vagyis ez a módszer jelentősen csökkenti a hidegindítási időt, és lehetővé teszi az eszközök adott időpontban történő maximális pontossággal történő felébresztését. Ez nagyon hasznos, ha mondjuk nem tíz, hanem száztíz eszköze van, és mindegyikkel adatot kell cserélnie rövid időn belül. Ráadásul az ébredés gyakoriságának és gyakoriságának logikája az AP oldalára költözik. Ha mondjuk a LoRAWAN PUSH-módszert használ, amikor maguk az aktuátorok felébrednek, és az éterben továbbítanak valamit, a fennmaradó időben pedig alszanak, akkor ebben az esetben éppen ellenkezőleg, az AP dönti el, hogy mikor és melyik eszköznek kell felébrednie, és maguk a működtetők... nem mindig alszanak.
Most térjünk át a keretformátumokra és a kompatibilitásra. Ha a 802.11ah-t első próbálkozásként a 868/915 MHz-es sávokra vagy egyszerűen csak SUB-1GHz-re hozták létre, akkor a 802.11ba-t már a 2.4 GHz-es és 5 GHz-es sávokra szánják. A korábbi "új" szabványokban a kompatibilitást a régebbi eszközök számára érthető preambulum révén érték el. Vagyis mindig is az volt a számítás, hogy a régebbi eszközöknek nem feltétlenül kell a teljes képkockát felismerniük, elég, ha megértik, mikor kezdődik ez a képkocka, és meddig tart az átvitel. Ezt az információt a preambulumból veszik. A 802.11ba sem volt kivétel, hiszen a séma bevált és bizonyított (a költségek kérdését egyelőre figyelmen kívül hagyjuk).
Ennek eredményeként a 802.11ba keret valahogy így néz ki:
A nem HT előtag és egy rövid OFDM töredék BPSK modulációval lehetővé teszi az összes 802.11a/g/n/ac/ax eszköz számára, hogy hallja ennek a keretnek az átvitelének kezdetét, és ne zavarjon, adáshallgatási módba lépve. A preambulum után jön a szinkronizációs mező (SYNC), amely lényegében az L-STF/L-LTF analógja. Lehetővé teszi a frekvencia beállítását és a készülék vevőjének szinkronizálását. És ebben a pillanatban az adókészülék egy másik 4 MHz-es csatornaszélességre kapcsol át. Miért? Minden nagyon egyszerű. Erre azért van szükség, hogy a teljesítményt le lehessen csökkenteni, és hasonló jel-zaj viszonyt (SINR) lehessen elérni. Vagy hagyja a teljesítményt úgy, ahogy van, és érje el az átviteli hatótávolság jelentős növekedését. Azt mondanám, hogy ez egy nagyon elegáns megoldás, amely lehetővé teszi a tápegységekkel szembeni követelmények jelentős csökkentését is. Emlékezzünk például a népszerű ESP8266-ra. Átviteli módban, 54 Mbps bitrátával és 16 dBm-es teljesítménnyel, 196 mA-t fogyaszt, ami túlzottan magas a CR2032-hez képest. Ha ötszörösére csökkentjük a csatorna szélességét és ötszörösére csökkentjük az adóteljesítményt, akkor gyakorlatilag nem veszítünk az átviteli tartományban, de az áramfelvétel egy szorzóval, mondjuk körülbelül 50 mA-re csökken. Nem mintha ez kritikus lenne a WUR keretét továbbító AP részéről, de még mindig nem rossz. De az STA esetében ennek már van értelme, mivel az alacsonyabb fogyasztás lehetővé teszi a CR2032-hez hasonló elemek vagy a hosszú távú energiatárolásra tervezett akkumulátorok használatát alacsony névleges kisülési áram mellett. Természetesen semmi sem jár ingyen, és a csatornaszélesség csökkentése a csatorna sebességének csökkenéséhez vezet egy keret átviteli idejének növekedésével, ill.
Egyébként a csatorna sebességéről. A szabvány jelenlegi formájában két lehetőséget kínál: 62.5 Kbps és 250 Kbps. Érzed a ZigBee illatát? Ez nem egyszerű, hiszen a csatornaszélessége 2Mhz helyett 4Mhz, hanem más típusú modulációja nagyobb spektrális sűrűséggel. Ennek eredményeként a 802.11ba eszközök tartományának nagyobbnak kell lennie, ami nagyon hasznos beltéri IoT-forgatókönyvek esetén.
Bár, várj egy percet... A környék összes állomásának csendre kényszerítése, miközben a 4 MHz-es sávból csak 20 MHz-et használunk fel... „EZ SZABADULÁS!” - mondod és igazad lesz. De nem, EZ AZ IGAZI HULLADÉK!
A szabvány lehetővé teszi a 40 MHz-es és 80 MHz-es alcsatornák használatát. Ebben az esetben az egyes alcsatornák bitsebessége eltérő lehet, és a sugárzási időhöz való illeszkedés érdekében a keret végére kitöltés kerül. Vagyis a készülék mind a 80 MHz-en képes adásidőt lefoglalni, de csak 16 MHz-en használja. Ez igazi pazarlás.
Egyébként a környező Wi-Fi eszközöknek esélyük sincs megérteni, hogy mit sugároznak ott. Mert a szokásos OFDM-et NEM használják a 802.11ba keretek kódolására. Igen, így a szövetség híresen felhagyott azzal, ami évek óta hibátlanul működött. A klasszikus OFDM helyett a Multi-Carrier (MC)-OOK modulációt használják. A 4 MHz-es csatorna 16(?) alvivőre van felosztva, amelyek mindegyike Manchester kódolást használ. Ugyanakkor maga a DATA mező is logikailag bitrátától függően 4 μs-os vagy 2 μs-os szegmensekre van felosztva, és minden ilyen szegmensben egy alacsony vagy magas kódolási szint felelhet meg. Ez a megoldás a nullák vagy egyesek hosszú sorozatának elkerülésére. Tülekedés a minimálbéren.
A MAC szint is rendkívül leegyszerűsített. Csak a következő mezőket tartalmazza:
- Keretvezérlés
Felveheti a Beacon, WuP, Discovery vagy bármely más, az eladó által választott értéket.
A Beacon az idő szinkronizálására szolgál, a WuP egy vagy egy eszközcsoport felébresztésére szolgál, a Discovery pedig az STA-tól az AP-ig ellentétes irányban működik, és a 802.11ba-t támogató hozzáférési pontokat keresi. Ez a mező tartalmazza a keret hosszát is, ha az meghaladja a 48 bitet. - ID
A keret típusától függően azonosíthat egy AP-t vagy egy STA-t, vagy egy STA-csoportot, amelyhez ez a keret tartozik. (Igen, fel lehet ébreszteni az eszközöket csoportosan is, ezt groupcast wake-up-nak hívják, és ez nagyon klassz).
- Típusfüggő (TD)
Elég rugalmas mezőny. Ebben lehet továbbítani a pontos időt, egy firmware/konfiguráció frissítésről szóló jelzést egy verziószámmal, vagy valami hasznosat, amiről az STA-nak tudnia kell.
- Frame Checksum Field (FCS)
Itt minden egyszerű. Ez egy ellenőrző összeg
De ahhoz, hogy a technológia működjön, nem elég egyszerűen elküldeni egy keretet a kívánt formátumban. Az STA-nak és az AP-nek meg kell egyeznie. Az STA jelenti a paramétereit, beleértve a PCR inicializálásához szükséges időt. Minden egyeztetés normál 802.11-es keretek használatával történik, amely után az STA letilthatja a PCR-t, és beléphet a WUR engedélyezési módba. Vagy aludj egy kicsit, ha lehet. Mert ha létezik, akkor jobb használni.
Következő egy kicsit több értékes milliamperóra, amelyet WUR Duty Cycle-nek hívnak. Nincs semmi bonyolult, csak az STA és az AP, a TWT-hez hasonlóan, megállapodnak az alvási ütemezésben. Ezek után az STA többnyire alszik, időnként bekapcsolja a WUR-t, hogy meghallgassa a „Érkezett valami hasznos számomra?” És csak ha szükséges, felébreszti a fő rádiómodult a forgalomcseréhez.
Radikálisan megváltoztatja a helyzetet a TWT-hez és az U-APSD-hez képest, nem?
És most egy fontos árnyalat, amelyre nem gondol azonnal. A WUR-nak nem kell ugyanazon a frekvencián 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. Ebben az esetben a 802.11ba funkcionalitás semmilyen módon nem zavarja a hálózat működését, ellenkezőleg, hasznos információk küldésére használható. Helyszín, szomszédlista és még sok más más 802.11 szabványon belül, például 802.11k/v. És milyen előnyök nyílnak meg a Mesh hálózatok előtt... De ez egy külön cikk témája.
Ami tehát magának a szabványnak, mint dokumentumnak a sorsát illeti . Azaz idén igazi színvonalra vagy legalábbis az első megvalósításokra számíthatunk. Csak az idő fogja megmondani, mennyire lesz elterjedt.
Ilyenek... (c) .
Ajánlott olvasmány:
Forrás: will.com