Non molto tempo fa, su vari altri siti e nel mio blog, ho parlato del fatto che ZigBee è morto e che è ora di seppellire l'assistente di volo. Per fare una buona faccia a cattivo gioco con Thread, che funziona sopra IPv6 e 6LowPan, basta un Bluetooth (LE) più adattato a questo scopo. Ma di questo parlerò un'altra volta. Oggi discuteremo di come nel gruppo di lavoro del comitato si sia riflettuto bene una seconda volta dopo 802.11ah e si sia deciso che era giunto il momento di aggiungere al pool degli standard 802.11 una versione completa di qualcosa simile a LRLP (Long-Range Low-Power), in analogia con LoRA. Ma questo si è rivelato irrealizzabile senza sacrificare la sacra mucca della retrocompatibilità. Alla fine, si è rinunciato al Long-Range e è rimasto solo il Low-Power, che è comunque molto positivo. È risultata una miscela di 802.11 + 802.15.4, o più semplicemente Wi-Fi + ZigBee. Quindi, si può dire che la nuova tecnologia non è un concorrente delle soluzioni LoraWAN, ma al contrario è concepita per integrarle.
Iniziamo con la cosa più importante — Ora nei dispositivi che supportano 802.11ba devono esserci due moduli radio. Apparentemente, osservando 802.11ah/ax con la loro tecnologia Target Wake Time (TWT), gli ingegneri hanno ritenuto che fosse insufficiente e che fosse necessario ridurre drasticamente il consumo energetico. A questo scopo, lo standard prevede la suddivisione in due tipi diversi di radio: Primary Communication Radio (PCR) e Wake-Up Radio (WUR). Se per la prima è tutto chiaro, essendo essa la radio principale che trasmette e riceve dati, con la seconda non è così semplice. Di fatto, WUR rappresenta per la maggior parte un dispositivo in ascolto (RX) e dovrebbe consumare pochissima energia per funzionare. Il suo compito principale è ricevere il segnale di risveglio dall'AP e attivare il PCR. Questo metodo riduce notevolmente il tempo di avvio a freddo e consente di risvegliare i dispositivi a un orario prestabilito con la massima precisione. Questo è molto utile quando si hanno, per esempio, non dieci dispositivi, ma cento e dieci, e si deve scambiare dati con ciascuno di essi in un breve intervallo di tempo. Inoltre, la logica della frequenza e della periodicità di risveglio passa sotto il controllo dell'AP. Se, per esempio, in LoRAWAN si applica la metodologia PUSH in cui i dispositivi esecutivi si svegliano da soli e trasmettono qualcosa in radio, mentre il resto del tempo dormono, in questo caso è l'AP a decidere quando e quale dispositivo deve svegliarsi, e i dispositivi esecutivi… non sempre dormono.
Passiamo ora ai formati dei frame e all'assicurazione della compatibilità. Se il 802.11ah come primo tentativo era stato sviluppato per le bande 868/915 MHz o semplicemente per SUB-1GHz, il 802.11ba è già destinato alle bande 2.4GHz e 5GHz. Nei precedenti "nuovi" standard, la compatibilità veniva raggiunta grazie a un preambolo comprensibile per i dispositivi più vecchi. In altre parole, si contava sempre sul fatto che ai dispositivi più vecchi non fosse necessariamente richiesta la possibilità di riconoscere l'intero frame; era sufficiente che comprendessero quando questo frame iniziasse e quanto durasse la trasmissione. Questa informazione la ricavano dal preambolo. Anche il 802.11ba non è stato un'eccezione, poiché lo schema è collaudato e consolidato (la questione dei costi la esaminiamo più avanti).
Alla fine, il frame 802.11ba appare in questo modo:
La preambolo Non-HT e il breve frammento OFDM con modulazione BPSK consentono a tutti i dispositivi 802.11a/g/n/ac/ax di rilevare l'inizio della trasmissione di questo frame e di non interferire, entrando in modalità di ascolto del canale. Dopo la preambolo segue il campo di sincronizzazione (SYNC), che è fondamentalmente l'equivalente di L-STF/L-LTF. Questo serve a permettere l'adeguamento della frequenza e a sincronizzare il ricevitore del dispositivo. Ed è proprio in questo momento che il dispositivo trasmittente passa a una larghezza di banda di 4 MHz. Perché? È molto semplice. È necessario per ridurre la potenza e ottenere un rapporto segnale-potenza rispetto al rumore (SINR) comparabile. Oppure si può mantenere la potenza com'è e ottenere un significativo aumento della distanza di trasmissione. Direi che questa è una soluzione piuttosto elegante, che consente anche di ridurre notevolmente le esigenze di alimentazione. Ricordiamo, ad esempio, il popolare ESP8266. In modalità trasmissione con una velocità di bit di 54 Mbps e una potenza di 16 dBm, consuma 196 mA, che è estremamente elevato per qualcosa come una CR2032. Se si riduce di cinque volte la larghezza di banda e si abbassa di cinque volte la potenza del trasmettitore, praticamente non perderemo nella distanza di trasmissione, ma il consumo di corrente verrà ridotto drasticamente, diciamo, a circa 50 mA. Non che fosse critico per l'AP che trasmette il frame per WUR, ma è comunque un miglioramento. Ma per il STA ha già senso, poiché un consumo inferiore consente di utilizzare qualcosa come una CR2032 o batterie progettate per una lunga durata con basse correnti nominali di scarica. Naturalmente, nulla è gratis e la riduzione della larghezza di banda porterà a una diminuzione della velocità di canale con conseguente aumento del tempo di trasmissione di un singolo frame.
A proposito della velocità di canale. Lo standard nella sua forma attuale prevede due opzioni: 62,5 Kbps e 250 Kbps. Senti, ZigBee fa capolino? Non è un caso, poiché ha una larghezza di banda di 2 MHz invece di 4 MHz, ma un altro tipo di modulazione con una maggiore densità spettrale. Di conseguenza, il raggio d'azione dei dispositivi 802.11ba dovrebbe essere maggiore, il che è molto utile per scenari IoT all'interno degli edifici.
Aspetta un attimo... Costringere tutte le stazioni nei paraggi a tacere usando solo 4 MHz della banda da 20 MHz... "QUESTO È UNO SPRECO!", direte voi e avrete ragione. Ma no, ECCO LO SPRECO REALE!
Nello standard è prevista la possibilità di utilizzare sottobande da 40 MHz e 80 MHz. I bitrate di ciascuna sottobanda possono essere diversi e, per allineare i tempi di trasmissione, viene aggiunto un Padding alla fine del frame. Cioè, il dispositivo può occupare tempo di trasmissione su tutti gli 80 MHz, utilizzandolo solo su 16 MHz. Questo è già un vero spreco.
A proposito, gli altri dispositivi Wi-Fi non hanno alcuna possibilità di capire cosa stia trasmettendo nell'aria. Questo perché per la codifica dei frame 802.11ba NON viene utilizzato il consueto OFDM. Sì, così, il consorzio ha abbandonato ciò che ha funzionato senza problemi per molti anni. Invece del classico OFDM, viene utilizzata la modulazione Multi-Carrier (MC)-OOK. Il canale da 4 MHz viene suddiviso in 16(?) portanti, ognuna delle quali utilizza la codifica di Manchester. Inoltre, il campo DATA è logicamente diviso in segmenti di 4 μs o 2 μs a seconda del bitrate, e in ciascun segmento un’unità può essere rappresentata da un livello di codifica basso o alto. Questa è una soluzione per evitare lunghe sequenze di zeri o uni. Scrambling al minimo.
Anche il livello MAC è estremamente semplificato. Contiene solo i seguenti campi:
- Frame Control
Può assumere i valori Beacon, WuP, Discovery o qualsiasi altro a scelta del fornitore.
Beacon serve per la sincronizzazione del tempo, WuP è destinato a risvegliare uno o più dispositivi, mentre Discovery opera in direzione opposta da STA a AP ed è creato per trovare punti di accesso che supportano 802.11ba. Inoltre, in questo campo viene trasmessa la lunghezza del frame se supera i 48 bit. - ID
A seconda del tipo di frame, può identificare AP o STA o un gruppo di STA a cui è destinato il frame. (Sì, è possibile svegliare i dispositivi in gruppi, si chiama groupcast wake-ups ed è piuttosto interessante).
- Type Dependent (TD)
Campo piuttosto flessibile. In esso possono essere trasmessi tempo preciso, segnale di aggiornamento del firmware/configurazione con numero di versione o qualcosa di utile che STA deve conoscere.
- Frame Checksum Field (FCS)
Qui è tutto semplice. Si tratta di un checksum
Ma affinché la tecnologia funzioni, non basta semplicemente inviare un frame nel formato corretto. STA e AP devono accordarsi. STA comunica i propri parametri, incluso il tempo necessario per inizializzare il PCR. Tutto l'accordo avviene utilizzando normali frame 802.11, dopo di che STA può disattivare il PCR e passare alla modalità di attivazione WUR. Può anche riposare un po', se possibile. Perché se c'è l'opportunità, è meglio sfruttarla.
Poi inizia una piccola estrazione di preziosi milliampere-ora chiamata WUR Duty Cycle. Non c'è niente di complesso, sta semplicemente a STA e AP concordare un programma di sonno, similmente a quanto fatto per il TWT. Dopo ciò, STA riposa per lo più, accendendo occasionalmente il WUR per verificare "Non è arrivato nulla di utile per me?". E solo in caso di necessità risveglia il modulo radio principale per lo scambio di traffico.
Cambia radicalmente la situazione rispetto al TWT e all'U-APSD, non è vero?
E ora un importante dettaglio a cui non si pensa subito. Il WUR non deve necessariamente funzionare sulla stessa frequenza del modulo principale. Al contrario, è desiderabile e consigliato che operi su un canale diverso. In tal caso, la funzionalità 802.11ba non interferisce in alcun modo con il funzionamento della rete e al contrario può essere utilizzata per inviare informazioni utili. Posizione, lista dei vicini e molte altre cose all'interno di altri standard 802.11, come 802.11k/v. E quali vantaggi si aprono per le reti Mesh... Ma questo è un argomento per un altro articolo.
Per quanto riguarda il futuro dello standard come documento, . Quindi, quest'anno possiamo aspettarci uno standard vero e proprio o almeno le prime implementazioni. E quanto si diffonderà - solo il tempo lo dirà.
Queste sono le cose... (c) .
Literatura consigliata per approfondimenti:
Fonte: habr.com
