Vor nicht allzu langer Zeit habe ich in verschiedenen anderen Ressourcen und in meinem Blog darüber gesprochen, dass ZigBee tot ist und es an der Zeit wäre, die Technologie aufzugeben. Um bei Thread, das über IPv6 und 6LowPan läuft, gut abzuschneiden, reicht eine besser geeignete Variante von Bluetooth (LE) aus. Aber darüber werde ich ein anderes Mal sprechen. Heute geht es darum, dass die Arbeitsgruppe des Komitees gründlich überlegt hat, wie sie nach 802.11ah vorgehen wollen, und beschlossen hat, der 802.11-Norm eine vollwertige Version von etwas Ähnlichem wie LRLP (Long-Range Low-Power) analog zu LoRA hinzuzufügen. Allerdings stellte sich heraus, dass dies nicht umsetzbar ist, ohne die heilige Kuh der Abwärtskompatibilität zu opfern. Letztendlich wurde von Long-Range Abstand genommen und nur Low-Power übrig gelassen, was ebenfalls sehr gut ist. Es entstand eine Mischung aus 802.11 und 802.15.4 oder einfacher gesagt Wi-Fi und ZigBee. Das bedeutet, die neue Technologie ist kein Konkurrent zu LoRaWAN-Lösungen, sondern wurde vielmehr entwickelt, um sie zu ergänzen.
Beginnen wir mit dem Wichtigsten – Um die Geräte mit 802.11ba zu unterstützen, müssen jetzt zwei Funkmodule vorhanden sein. Die Ingenieure, die sich 802.11ah/ax und deren Technologie zur gezielten Weckzeit (TWT) angesehen haben, fanden offenbar, dass dies nicht ausreicht, und wollten den Energieverbrauch radikal senken. Deshalb sieht der Standard die Unterteilung in zwei verschiedene Funktypen vor – Primary Communication Radio (PCR) und Wake-Up Radio (WUR). Während das erste, das Hauptfunkgerät, Daten sendet und empfängt, ist die Funktionsweise des zweiten weniger klar. Tatsächlich handelt es sich bei WUR größtenteils um ein Empfangsgerät (RX), das nach Planung sehr wenig Energie verbrauchen soll. Die Hauptaufgabe besteht darin, das Wecksignal vom AP zu empfangen und PCR zu aktivieren. Diese Methode reduziert die Zeit für den Kaltstart erheblich und ermöglicht es, Geräte zu genau festgelegten Zeiten zu wecken. Dies ist besonders nützlich, wenn Sie beispielsweise nicht zehn, sondern hundert zehn Geräte haben und in kurzer Zeit Daten mit jedem von ihnen austauschen müssen. Darüber hinaus wird die Logik der Frequenz und der Weckperioden auf die Seite des AP übertragen. Während im LoRAWAN die PUSH-Methodologie angewendet wird, bei der die Endgeräte selbst aufwachen und Informationen übermitteln, während sie die meiste Zeit schlafen, entscheidet in diesem Fall der AP, wann und welches Gerät geweckt werden soll, während die Endgeräte… nicht immer schlafen.
Lassen Sie uns nun zu den Rahmenformaten und der Kompatibilität übergehen. Während 802.11ah als erster Versuch für die Frequenzen von 868/915 MHz oder einfach SUB-1GHz entwickelt wurde, ist 802.11ba bereits für die Bereiche von 2,4 GHz und 5 GHz vorgesehen. Bei den vorherigen "neuen" Standards wurde die Kompatibilität durch ein Präambel erreicht, die für ältere Geräte verständlich war. Das heißt, es wurde immer davon ausgegangen, dass alte Geräte nicht in der Lage sein müssen, das gesamte Frame zu erkennen, sondern lediglich zu verstehen, wann dieses Frame beginnt und wie lange die Übertragung dauert. Genau diese Informationen gewinnen sie aus der Präambel. 802.11ba bildet da keine Ausnahme, da das Schema erprobt und bewährt ist (die Kostenfrage lassen wir vorerst außen vor).
Insgesamt sieht ein 802.11ba-Frame etwa so aus:
Die Non-HT-Präambel und der kurze OFDM-Fragment mit BPSK-Modulation ermöglichen es allen 802.11a/g/n/ac/ax Geräten, den Beginn der Übertragung dieses Frames zu hören und sich zurückzuziehen, während sie in den Empfangsmodus wechseln. Auf die Präambel folgt das Synchronisationsfeld (SYNC), welches im Wesentlichen dem L-STF/L-LTF ähnelt. Es dient dazu, die Frequenz anzupassen und den Empfänger des Geräts zu synchronisieren. In diesem Moment wechselt das sendende Gerät auf eine andere Kanalbreite von 4 MHz. Warum? Ganz einfach. Es ist notwendig, um die Leistung zu reduzieren und ein vergleichbares Signal-Rausch-Verhältnis (SINR) zu erreichen. Alternativ kann die Leistung beibehalten werden, um die Reichweite der Übertragung signifikant zu erhöhen. Ich würde sagen, das ist eine ziemlich elegante Lösung, die zudem die Anforderungen an die Stromversorgung erheblich senkt. Denken wir zum Beispiel an den populären ESP8266. Im Übertragungsmodus mit einer Bitrate von 54 Mbps und einer Leistung von 16 dBm verbraucht er 196 mA, was für etwas wie eine CR2032 viel zu viel ist. Wenn wir die Kanalbreite um den Faktor fünf und die Sendeleistung um den Faktor fünf reduzieren, verlieren wir praktisch nichts an Übertragungsreichweite, der Stromverbrauch lässt sich jedoch erheblich auf etwa 50 mA senken. Das ist nicht unbedingt kritisch für den AP, der den Frame für WUR überträgt, aber trotzdem nicht schlecht. Für STA macht es jedoch durchaus Sinn, da der geringere Stromverbrauch die Verwendung von CR2032 und Batterien ermöglicht, die auf eine lange Energielagerung mit niedrigen Entladeströmen ausgelegt sind. Natürlich gibt es nichts umsonst, und die Reduzierung der Kanalbreite wird zu einer Verringerung der Kanaldatenrate und einer Erhöhung der Übertragungszeit eines Frames führen.
Übrigens, zur Kanalkapazität. Der Standard sieht aktuell zwei Varianten vor: 62,5 Kbps und 250 Kbps. Spüren Sie das ZigBee-Gefühl? Das ist kein Zufall, denn es hat eine Bandbreite von 2 MHz anstelle von 4 MHz, aber eine andere Modulationsart mit höherer spektraler Dichte. Folglich sollte die Reichweite von 802.11ba-Geräten größer sein, was für IoT-Szenarien in Innenräumen sehr praktisch ist.
Moment mal... Alle Stationen in der Umgebung zum Schweigen zu bringen, während man nur 4 MHz aus einem 20 MHz-Band verwendet... „DAS IST VERSCHWENDUNG!“ werden Sie sagen, und Sie hätten recht. Aber nein, DAS IST ECHTE VERSCHWENDUNG!
Der Standard erlaubt die Verwendung von Unterkanälen mit 40 MHz und 80 MHz. Dabei können die Bitraten jedes Unterkanals unterschiedlich sein, und um synchron zur Übertragung zu sein, wird am Ende des Frames ein Padding hinzugefügt. Das bedeutet, dass das Gerät die Übertragungszeit auf allen 80 MHz belegen kann, sie jedoch nur mit 16 MHz nutzen kann. Das ist echte Verschwendung.
Übrigens haben umliegende Wi-Fi-Geräte keine Chance, zu verstehen, was über die Luft übertragen wird. Denn zur Kodierung der 802.11ba-Frames wird nicht das ihnen vertraute OFDM verwendet. Ja, so hat das Konsortium gewagt, auf etwas zu verzichten, das viele Jahre zuverlässig funktioniert hat. Statt des klassischen OFDM wird die Multi-Carrier (MC)-OOK-Modulation eingesetzt. Der Kanal mit 4 MHz wird in 16 (?) Unterträger aufgeteilt, von denen jeder Manchester-Codierung verwendet. Das eigentliche DATA-Feld wird zudem logisch in Abschnitte von 4 μs oder 2 μs unterteilt, je nach Bitrate, wobei in jedem solchen Abschnitt eine Eins durch einen niedrigen oder hohen Pegel kodiert werden kann. So wird eine lange Folge von Nullen oder Einsen vermieden. Ein Minimal-Scrambling.
Die MAC-Ebene ist ebenfalls stark vereinfacht. Sie enthält nur die folgenden Felder:
- Frame Control
Kann Werte wie Beacon, WuP, Discovery oder jede andere vom Anbieter gewählte Option annehmen.
Das Beacon dient der Zeit-Synchronisation, WuP ist dazu gedacht, ein oder mehrere Geräte aufzuwecken, und Discovery funktioniert in umgekehrter Richtung von STA zu AP und ist dazu erstellt, Zugangspunkte zu finden, die 802.11ba unterstützen. In diesem Feld wird auch die Länge des Frames übermittelt, wenn sie 48 Bits überschreitet. - ID
Je nach Art des Frames kann der AP, STA oder eine Gruppe von STAs identifiziert werden, für die dieser Frame gedacht ist. (Ja, es ist möglich, Geräte in Gruppen zu wecken, das nennt man Groupcast-Wake-ups, und das ist ziemlich cool).
- Typabhängig (TD)
Ein sehr flexibles Feld. Genau hier kann die genaue Uhrzeit, ein Signal zur Aktualisierung der Firmware/Konfiguration mit Versionsnummer oder etwas Nützliches übermittelt werden, das die STA wissen sollte.
- Frame-Checksumme-Feld (FCS)
Hier ist alles einfach. Das ist die Prüfziffer.
Um sicherzustellen, dass die Technologie funktioniert, ist es nicht genug, nur das richtige Format zu senden. Der STA und der AP müssen sich abstimmen. Der STA teilt seine Parameter mit, einschließlich der Zeit, die für die Initialisierung des PCR benötigt wird. Die gesamte Abstimmung erfolgt unter Verwendung der normalen 802.11-Frames, danach kann der STA den PCR deaktivieren und in den WUR-Aktivierungsmodus wechseln. Er kann sogar ein wenig schlafen, wenn es die Möglichkeit dazu gibt. Denn wenn es diese Möglichkeit gibt, sollte man sie nutzen.
Dann beginnt das vorsichtige Herausquetschen wertvoller Milliamperestunden, das als WUR Duty Cycle bekannt ist. Es ist nicht kompliziert, der STA und der AP stimmen, ähnlich wie es beim TWT war, einen Schlafplan ab. Danach schläft der STA überwiegend und schaltet gelegentlich den WUR ein, um zu hören: "Ist etwas Nützliches für mich angekommen?" Nur bei Bedarf aktiviert er das Hauptfunkmodul für den Datenaustausch.
Das verändert die Situation im Vergleich zu TWT und U-APSD radikal, oder nicht?
Jetzt ein wichtiger Aspekt, den man nicht sofort bedenkt. Das WUR muss nicht unbedingt mit der gleichen Frequenz wie das Hauptmodul arbeiten. Im Gegenteil, es ist wünschenswert und empfohlen, dass es auf einem anderen Kanal arbeitet. In diesem Fall beeinträchtigt die Funktionalität von 802.11ba die Netzwerkarbeit in keiner Weise und kann im Gegenteil zur Übertragung nützlicher Informationen verwendet werden. Standort, Nachbarliste und vieles mehr im Rahmen anderer Standards von 802.11, beispielsweise 802.11k/v. Und welche Vorteile sich für Mesh-Netzwerke ergeben... Aber das ist ein Thema für einen eigenen Artikel.
Was die Zukunft des Standards als Dokument betrifft, Das heißt, in diesem Jahr kann man mit einem echten Standard oder zumindest mit ersten Umsetzungen rechnen. Wie weit er sich verbreiten wird, wird nur die Zeit zeigen.
So sieht's aus… (c) .
Empfohlene Literatur zur Lektüre:
Quelle: habr.com
