Nog niet zo lang geleden sprak ik op verschillende andere bronnen en in mijn blog over het feit dat ZigBee dood is en dat het tijd is om de stewardess te begraven. Om een ββslecht spel waarbij Thread bovenop IPv6 en 6LowPan werkt een goed gezicht te geven, is Bluetooth (LE) dat hiervoor geschikter is voldoende. Maar ik zal je hier een andere keer over vertellen. Vandaag zullen we praten over hoe de werkgroep van de commissie besloot na 802.11ah twee keer na te denken en besloot dat het tijd was om een ββvolwaardige versie van zoiets als LRLP (Long-Range Low-Power) toe te voegen aan de verzameling 802.11-standaarden, vergelijkbaar naar LoRA. Maar dit bleek onmogelijk te implementeren zonder de heilige koe van achterwaartse compatibiliteit af te slachten. Als gevolg hiervan werd Long-Range verlaten en bleef alleen Low-Power over, wat ook erg goed is. Het resultaat was een combinatie van 802.11 + 802.15.4, of gewoon Wi-Fi + ZigBee. Dat wil zeggen dat we kunnen zeggen dat de nieuwe technologie geen concurrent is van LoraWAN-oplossingen, maar integendeel wordt gecreΓ«erd om deze aan te vullen.
Laten we beginnen met het allerbelangrijkste: apparaten die 802.11ba ondersteunen, zouden nu twee radiomodules moeten hebben. Blijkbaar hebben de ingenieurs, nadat ze naar 802.11ah/ax met zijn Target Wake Time (TWT)-technologie hadden gekeken, besloten dat dit niet genoeg was en dat ze het energieverbruik radicaal moesten verminderen. Waarom de standaard voorziet in een indeling in twee verschillende soorten radio: Primary Communication Radio (PCR) en Wake-Up Radio (WUR). Als bij de eerste alles duidelijk is, is dit de hoofdradio, deze verzendt en ontvangt gegevens, en bij de tweede is het niet zo veel. In feite is de WUR vooral een luisterapparaat (RX) en is ontworpen om zeer weinig stroom te verbruiken. De belangrijkste taak is het ontvangen van een weksignaal van het AP en het inschakelen van PCR. Dat wil zeggen, deze methode verkort de koude starttijd aanzienlijk en stelt u in staat apparaten op een bepaald tijdstip met maximale nauwkeurigheid te wekken. Dit is erg handig als je bijvoorbeeld niet tien apparaten hebt, maar honderdtien en met elk van hen in korte tijd gegevens moet uitwisselen. Bovendien verschuift de logica van de frequentie en periodiciteit van het ontwaken naar de AP-kant. Als LoRAWAN bijvoorbeeld de PUSH-methodologie gebruikt wanneer de actuatoren zelf wakker worden en iets in de lucht uitzenden, en de rest van de tijd slapen, dan beslist in dit geval het AP daarentegen wanneer en welk apparaat moet ontwaken, en de actuatoren zelf... slapen niet altijd.
Laten we nu verder gaan met frameformaten en compatibiliteit. Als 802.11ah bij de eerste poging is gemaakt voor de 868/915 MHz-banden of simpelweg SUB-1GHz, dan is 802.11ba al bedoeld voor de 2.4GHz- en 5GHz-banden. In eerdere "nieuwe" standaarden werd compatibiliteit bereikt via een preambule die begrijpelijk was voor oudere apparaten. Dat wil zeggen, de berekening is altijd geweest dat oudere apparaten niet noodzakelijkerwijs het hele frame hoeven te kunnen herkennen; het is voldoende dat ze begrijpen wanneer dit frame begint en hoe lang de verzending zal duren. Het is deze informatie die zij uit de preambule halen. 802.11ba vormde daarop geen uitzondering, aangezien het schema bewezen en bewezen is (we zullen de kwestie van de kosten voorlopig negeren).
Als gevolg hiervan ziet het 802.11ba-frame er ongeveer zo uit:
Een niet-HT-preambule en een kort OFDM-fragment met BPSK-modulatie zorgen ervoor dat alle 802.11a/g/n/ac/ax-apparaten het begin van de transmissie van dit frame kunnen horen en niet kunnen interfereren, waardoor ze in de uitzendluistermodus gaan. Na de preambule komt het synchronisatieveld (SYNC), dat in wezen analoog is aan L-STF/L-LTF. Het dient om het mogelijk te maken de frequentie aan te passen en de ontvanger van het apparaat te synchroniseren. En het is op dit moment dat het zendapparaat overschakelt naar een andere kanaalbreedte van 4 MHz. Waarvoor? Alles is heel eenvoudig. Dit is nodig zodat het vermogen kan worden verminderd en een vergelijkbare signaal-ruisverhouding (SINR) kan worden bereikt. Of laat het vermogen zoals het is en bereik een aanzienlijke toename van het zendbereik. Ik zou zeggen dat dit een zeer elegante oplossing is, waarmee je ook de eisen aan stroomvoorzieningen aanzienlijk kunt verminderen. Laten we bijvoorbeeld de populaire ESP8266 onthouden. In de transmissiemodus met een bitsnelheid van 54 Mbps en een vermogen van 16 dBm verbruikt hij 196 mA, wat onbetaalbaar hoog is voor zoiets als de CR2032. Als we de kanaalbreedte vijf keer verkleinen en het zendvermogen vijf keer verkleinen, verliezen we vrijwel niets aan zendbereik, maar wordt het stroomverbruik met een factor van bijvoorbeeld ongeveer 50 mA verminderd. Niet dat dit cruciaal is voor de AP die het frame voor WUR doorgeeft, maar het is nog steeds niet slecht. Maar voor STA is dit al logisch, omdat een lager verbruik het gebruik van zoiets als CR2032 of batterijen mogelijk maakt die zijn ontworpen voor langdurige energieopslag met lage nominale ontlaadstromen. Natuurlijk is niets gratis en het verkleinen van de kanaalbreedte zal respectievelijk leiden tot een afname van de kanaalsnelheid met een toename van de transmissietijd van één frame.
Trouwens, over kanaalsnelheid. De standaard in zijn huidige vorm biedt twee mogelijkheden: 62.5 Kbps en 250 Kbps. Voel jij de geur van ZigBee? Dit is niet eenvoudig, aangezien het een kanaalbreedte heeft van 2 MHz in plaats van 4 MHz, maar een ander type modulatie met een hogere spectrale dichtheid. Als gevolg hiervan zou het bereik van 802.11ba-apparaten groter moeten zijn, wat erg handig is voor IoT-scenario's binnenshuis.
Hoewel, wacht even... Alle stations in de omgeving dwingen stil te zijn, terwijl ze slechts 4 MHz van de 20 MHz-band gebruiken... "HET IS EEN AFVAL!" - zeg je en je hebt gelijk. Maar nee, DIT IS HET ECHTE AFVAL!
De standaard biedt de mogelijkheid om 40 MHz en 80 MHz subkanalen te gebruiken. In dit geval kunnen de bitrates van elk subkanaal verschillend zijn, en om de uitzendtijd aan te passen, wordt Padding toegevoegd aan het einde van het frame. Dat wil zeggen dat het apparaat zendtijd kan innemen op alle 80 MHz, maar alleen op 16 MHz. Dit is echte verspilling.
Overigens hebben omliggende Wi-Fi-apparaten geen enkele kans om te begrijpen wat daar wordt uitgezonden. Omdat de gebruikelijke OFDM NIET wordt gebruikt om 802.11ba-frames te coderen. Ja, zomaar liet de alliantie op beroemde wijze los wat jarenlang feilloos had gewerkt. In plaats van klassieke OFDM wordt Multi-Carrier (MC)-OOK-modulatie gebruikt. Het 4MHz-kanaal is verdeeld in 16(?) subdraaggolven, die elk Manchester-codering gebruiken. Tegelijkertijd is het DATA-veld zelf ook logisch verdeeld in segmenten van 4 ΞΌs of 2 ΞΌs, afhankelijk van de bitsnelheid, en in elk dergelijk segment kan een laag of hoog coderingsniveau overeenkomen met een eenheid. Dit is de oplossing om een ββlange reeks nullen of enen te vermijden. Strijd tegen minimumlonen.
Het MAC-niveau is ook extreem vereenvoudigd. Het bevat alleen de volgende velden:
- Frame Controle
Kan de waarden Beacon, WuP, Discovery of een andere waarde naar keuze van de leverancier aannemen.
Beacon wordt gebruikt voor tijdsynchronisatie, WuP is ontworpen om één of een groep apparaten wakker te maken, en Discovery werkt in de tegenovergestelde richting van STA naar AP en is ontworpen om toegangspunten te vinden die 802.11ba ondersteunen. Dit veld bevat ook de lengte van het frame als deze groter is dan 48 bits. - ID
Afhankelijk van het type frame kan het een AP, of een STA, of een groep STA's identificeren waarvoor dit frame bedoeld is. (Ja, je kunt apparaten in groepen wakker maken, het heet groupcast wake-ups en het is best gaaf).
- Typeafhankelijk (TD)
Een behoorlijk flexibel vakgebied. Daarin kan de exacte tijd worden verzonden, een signaal over een firmware-/configuratie-update met een versienummer, of iets nuttigs waarvan de STA zou moeten weten.
- Framecontrolesomveld (FCS)
Alles is hier eenvoudig. Dit is een controlesom
Maar om de technologie te laten werken, is het niet voldoende om simpelweg een frame in het vereiste formaat te verzenden. De STA en AP moeten het eens zijn. De STA rapporteert zijn parameters, inclusief de tijd die nodig is om de PCR te initialiseren. Alle onderhandeling vindt plaats met behulp van reguliere 802.11-frames, waarna de STA PCR kan uitschakelen en naar de WUR-inschakelmodus kan gaan. Of misschien zelfs wat gaan slapen, als dat mogelijk is. Want als het bestaat, is het beter om het te gebruiken.
Vervolgens komt er nog een beetje meer knijpen van kostbare milliampΓ¨re-uren, genaamd WUR Duty Cycle. Er is niets ingewikkelds, alleen STA en AP zijn het, naar analogie met hoe het was voor TWT, eens over een slaapschema. Hierna slaapt STA grotendeels en zet WUR af en toe aan om te luisteren naar βIs er iets nuttigs voor mij aangekomen?β En alleen als dat nodig is, wordt de hoofdradiomodule geactiveerd voor verkeersuitwisseling.
Verandert de situatie radicaal vergeleken met TWT en U-APSD, nietwaar?
En nu een belangrijke nuance waar je niet meteen bij stilstaat. De WUR hoeft niet op dezelfde frequentie te werken als de hoofdmodule. Integendeel, het is wenselijk en aanbevolen dat het op een ander kanaal werkt. In dit geval interfereert de 802.11ba-functionaliteit op geen enkele manier met de werking van het netwerk en kan integendeel worden gebruikt om nuttige informatie te verzenden. Locatie, burenlijst en nog veel meer binnen andere 802.11-standaarden, bijvoorbeeld 802.11k/v. En welke voordelen bieden Mesh-netwerken... Maar dit is het onderwerp van een apart artikel.
Wat betreft het lot van de standaard zelf als document dan . Dat wil zeggen, dit jaar kunnen we een echte standaard of in ieder geval de eerste implementaties verwachten. Alleen de tijd zal leren hoe wijdverbreid het zal zijn.
Zulke dingen... (c) .
Aanbevolen lectuur:
Bron: www.habr.com