Niet zo lang geleden heb ik op verschillende platforms en in mijn blog gesproken over het feit dat ZigBee dood is en dat de stewardess wel mag worden begraven. Om een goede gezicht te houden bij een slecht spel met Thread, dat bovenop IPv6 en 6LowPan werkt, is een beter geschikte Bluetooth (LE) voldoende. Maar daar zal ik een andere keer over vertellen. Vandaag gaat het erover hoe de werkgroep van de commissie goed heeft nagedacht na 802.11ah en heeft besloten dat het tijd is om een volwaardige versie van iets als LRLP (Long-Range Low-Power) aan de standaard 802.11 toe te voegen, analogisch aan LoRA. Maar dit bleek niet uitvoerbaar zonder de heilige koe van achterwaartse compatibiliteit te slachten. Uiteindelijk hebben ze van Long-Range afgezien en bleef alleen Low-Power over, wat ook heel goed is. Het resultaat is een mix van 802.11 + 802.15.4, of simpelweg Wi-Fi + ZigBee. Met andere woorden, de nieuwe technologie is geen concurrent voor LoraWAN-oplossingen, maar wordt juist ontwikkeld om deze aan te vullen.
Laten we beginnen met het belangrijkste ā nu moeten apparaten die 802.11ba ondersteunen, twee radiomodules hebben. Blijkbaar, na het bekijken van 802.11ah/ax met hun Target Wake Time (TWT) technologie, hebben ingenieurs besloten dat dit niet genoeg is en dat de energieconsumptie radicaal moet worden verlaagd. Daarom voorziet de standaard in de opsplitsing in twee verschillende soorten radioās ā Primary Communication Radio (PCR) en Wake-Up Radio (WUR). Als het gaat om de eerste, is het duidelijk, dit is de hoofdradio die gegevens verzendt en ontvangt, maar met de tweede is dat minder duidelijk. Eigenlijk is WUR in de meeste gevallen een luisterapparaat (RX) dat zeer weinig energie zou moeten verbruiken. De belangrijkste taak is om het weksignaal van de AP te ontvangen en PCR in te schakelen. Dit betekent dat deze methode de opstarttijd aanzienlijk verkort en het mogelijk maakt om apparaten op een zeer nauwkeurige tijd te wekken. Dit is bijzonder nuttig wanneer je bijvoorbeeld niet tien apparaten, maar honderdtien hebt en je moet in een kort tijdsbestek met elk van hen gegevens uitwisselen. Bovendien verhuist de logica van frequentie en periodiciteit van wakker worden naar de AP. Terwijl in LoRAWAN de PUSH-methodologie wordt toegepast, waarbij uitvoerende apparaten zelf wakker worden en iets uitzenden, en de rest van de tijd slapen, beslist in dit geval de AP wanneer en welk apparaat moet ontwaken, en de uitvoerende apparaten... slapen niet altijd.
Laten we nu overgaan op de frameformaten en het waarborgen van compatibiliteit. Als 802.11ah als een eerste poging bedoeld was voor de frequentiebanden van 868/915 MHz, of simpelweg SUB-1GHz, dan is 802.11ba al bedoeld voor de frequentiebanden van 2.4GHz en 5GHz. In de eerdere 'nieuwe' standaarden werd compatibiliteit bereikt door een preambel die begrijpelijk was voor oudere apparaten. Dit betekent dat de veronderstelling altijd was dat oudere apparaten niet de mogelijkheid hoefden te hebben om het hele frame te herkennen; ze moesten gewoon begrijpen wanneer dit frame zou beginnen en hoelang de overdracht zou duren. Deze informatie halen ze uit de preambel. 802.11ba is hierop geen uitzondering, omdat het een beproefd en getest schema volgt (we laten de kwestie van kosten even buiten beschouwing).
Het frame van 802.11ba ziet er ongeveer zo uit:
De Non-HT preambule en een korte fragment van OFDM met BPSK-modulatie stelt alle 802.11a/g/n/ac/ax apparaten in staat om het begin van de overdracht van dit kader te horen en zich niet ermee te bemoeien, door in de luistermodus te gaan. Na de preambule volgt het synchronisatieveld (SYNC), wat in wezen vergelijkbaar is met L-STF/L-LTF. Dit wordt gebruikt om de frequentie aan te passen en de ontvanger van het apparaat te synchroniseren. En op dit punt schakelt het zendapparaat over naar een andere kanaalbreedte van 4MHz. Waarom? Het is heel eenvoudig. Dit is nodig om het vermogen te verlagen en een vergelijkbare signaal-ruisverhouding (SINR) te bereiken. Of laat het vermogen zoals het is en bereik een significante verhoging van de zendafstand. Ik zou zeggen dat dit een vrij elegante oplossing is, bovendien leidt het tot een aanzienlijke verlaging van de vereisten voor stroombronnen. Laten we ter herinnering de populaire ESP8266 nemen. In verzendmodus met een bitrate van 54 Mbps en een vermogen van 16dBm verbruikt hij 196 mA, wat veel te veel is voor iets als een CR2032. Als we de kanaalbreedte vijf keer verminderen en het zendvermogen vijf keer verlagen, verliezen we praktisch niets aan zendafstand, maar dalen de stroomverbruikswaarden tot ongeveer 50 mA. Niet dat dit kritiek is vanuit de AP die het frame voor WUR verzendt, maar het is wel mooi. Voor de STA is dit al zinvol, aangezien een lager verbruik het mogelijk maakt om iets zoals een CR2032 of batterijen te gebruiken die zijn ontworpen voor langdurige energieopslag met lage ontlaadtarieven. Uiteraard komt niets gratis en verlaging van de kanaalbreedte zal leiden tot een verlaging van de kanaalsnelheid met een toename van de overdrachtstijd van Ć©Ć©n kader.
Over kanalsnelheid gesproken. De standaard voorziet in twee opties: 62.5 Kbps en 250 Kbps. Voel je dat ZigBee in de lucht hangt? Dit is niet toevallig, aangezien het een kanaalbreedte van 2Mhz heeft in plaats van 4Mhz, maar met een ander type modulatie met een hogere spectrale dichtheid. Uiteindelijke moet de actieradius van 802.11ba apparaten groter zijn, wat vrij handig is voor IoT-scenario's binnenshuis.
Wacht eens even... Alle stations in de omgeving stil laten zijn met slechts 4 MHz van een bandbreedte van 20 MHz... "DAT IS TOCH VERSPELLING!" zult u zeggen, en u heeft gelijk. Maar nee, DIT IS WERKELIJK VERSPELLING!
De standaard biedt de mogelijkheid om subbanden van 40 MHz en 80 MHz te gebruiken. De bitrate van elke subband kan echter anders zijn, en om synchronisatie te waarborgen, wordt er padding aan het einde van het frame toegevoegd. Dat wil zeggen, het apparaat kan de zendtijd voor alle 80 MHz gebruiken, maar gebruikt het slechts voor 16 MHz. Dat is nu pas echt verspilling.
Overigens hebben omliggende Wi-Fi-apparaten geen enkele kans om te begrijpen wat er in de lucht wordt uitgezonden. Omdat bij de codering van 802.11ba-frames de gebruikelijke OFDM niet wordt gebruikt. Ja, zo heeft de alliantie het onfeilbare systeem dat jarenlang heeft gewerkt, laten vallen. In plaats van de klassieke OFDM wordt Multi-Carrier (MC)-OOK modulatie gebruikt. Het 4MHz-kanaal wordt verdeeld in 16(?) subdraaggolven, die elk Manchester-codering toepassen. Daarbij is het DATAGEBIED logisch verdeeld in segmenten van 4 Ī¼s of 2 Ī¼s, afhankelijk van de bitrate, waarbij in elk segment een laag of hoog niveau van codering kan worden behaald. Een oplossing om lange reeksen van nullen of enen te vermijden. Scrambling op het minimum.
Het MAC-niveau is ook extreem vereenvoudigd. Het bevat alleen de volgende velden:
- Frame Control
Kan waarden aannemen zoals Beacon, WuP, Discovery of een andere keuze van de leverancier.
Beacon dient voor tijdssynchronisatie, WuP is bedoeld voor het wakker maken van Ć©Ć©n of een groep apparaten, en Discovery werkt in de omgekeerde richting van STA naar AP en is bedoeld om toegangspunten te vinden die 802.11ba ondersteunen. Ook in dit veld wordt de lengte van het frame doorgegeven als deze meer dan 48 bits is. - ID
Afhankelijk van het type frame kan het AP, STA of een groep STA identificeren waarvoor het frame bestemd is. (Ja, je kunt apparaten in groepen wakker maken, dat heet groupcast wake-ups en is behoorlijk leuk).
- Type Afhankelijk (TD)
Een vrij flexibel veld. Precies hier kan de exacte tijd, een signaal voor firmware-/configuratie-updates met versienummer of iets nuttigs dat de STA moet weten, worden doorgegeven.
- Frame Checksum Field (FCS)
Hier is het eenvoudig. Dit is de checksum.
Maar om de technologie te laten werken, is het niet genoeg om alleen het juiste formaat van het frame te verzenden. STA en AP moeten overeenkomen. STA communiceert zijn parameters, inclusief de tijd die nodig is om de PCR te initialiseren. Alle afstemming gebeurt met behulp van standaard 802.11-frames, waarna de STA de PCR kan uitschakelen en kan overschakelen naar de WUR-activeringsmodus. En misschien zelfs een beetje slapen, als dat mogelijk is. Want als dat mogelijk is, is het beter om ervan gebruik te maken.
Vervolgens begint de kleine uitknijping van kostbare milliampĆØre-uren, genaamd WUR Duty Cycle. Er is niets ingewikkelds aan, STA en AP stemmen overeen, zoals dat was voor TWT, over de slaapschema's. Daarna slaapt de STA voornamelijk, met af en toe WUR-activering om te luisteren: 'Is er iets nuttigs voor mij binnengekomen?'. En alleen indien nodig wordt de hoofd radiomodule gewekt voor het uitwisselen van verkeer.
Radicaal anders dan TWT en U-APSD, nietwaar?
En nu een belangrijk detail waar je niet meteen aan denkt. 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 dat geval beĆÆnvloedt de functionaliteit van 802.11ba de werking van het netwerk op geen enkele manier en kan deze juist worden gebruikt voor het verzenden van nuttige informatie. Locatie, buurlijst en nog veel meer vanuit andere 802.11-standaarden, bijvoorbeeld 802.11k/v. En de voordelen voor Mesh-netwerken zijn enorm... Maar dat is een onderwerp voor een apart artikel.
Wat betreft de toekomst van de standaard als document, . Dat betekent dat we dit jaar een echte standaard of op zijn minst de eerste implementaties kunnen verwachten. Hoe wijdverspreid het zal worden, zal alleen de tijd leren.
Dat is de status... (c) .
Aanbevolen literatuur om kennis te maken:
Bron: habr.com
