Non molto tempo fa, su vari altri strumenti e nel mio blog, ho parlato del fatto che ZigBee è morto e che è ora di seppellire la hostess. Per fare un buon viso a un cattivo gioco con Thread, che opera sopra IPv6 e 6LowPan, è sufficiente un Bluetooth (LE) più adatto a questo scopo. Ma di questo parlerò un'altra volta. Oggi parlerò di come il gruppo di lavoro del comitato ha riflettuto bene una seconda volta dopo l'802.11ah e ha 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) ispirata a LoRA. Tuttavia, 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 buono. È nata una miscela di 802.11 + 802.15.4, o semplicemente Wi-Fi + ZigBee. Quindi, si può dire che la nuova tecnologia non è un competitor delle soluzioni LoraWAN, ma al contrario viene creata per integrarle.
Iniziamo con la cosa più importante: ora nei dispositivi che supportano 802.11ba devono esserci due moduli radio. Dopo aver osservato 802.11ah/ax con la loro tecnologia Target Wake Time (TWT), gli ingegneri hanno ritenuto che non fosse sufficiente e che fosse necessario ridurre drasticamente il consumo energetico. A tal fine, lo standard prevede una suddivisione in due diversi tipi di radio: Primary Communication Radio (PCR) e Wake-Up Radio (WUR). Se per il primo tutto è chiaro, in quanto è la radio principale che trasmette e riceve dati, il secondo è meno comprensibile. Fondamentalmente, il WUR funge in gran parte da dispositivo di ascolto (RX) e, secondo le intenzioni, dovrebbe consumare molto poca energia per funzionare. Il suo compito principale è ricevere un segnale di risveglio dall'AP e accendere il PCR. Questo metodo riduce notevolmente il tempo di avvio a freddo e consente di risvegliare i dispositivi a un orario programmato con la massima precisione. Questo è particolarmente utile quando si dispone, ad esempio, non di dieci dispositivi, ma di cento 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, ad esempio, in LoRAWAN si applica la metodologia PUSH, in cui i dispositivi esecutivi si svegliano da soli e trasmettono qualcosa nell'aria, mentre per il resto del tempo dormono, in questo caso è il contrario: l'AP decide quando e quale dispositivo deve risvegliarsi, mentre i dispositivi esecutivi… non sempre dormono.
Passiamo ora ai formati dei frame e alla compatibilità. Se il 802.11ah è stato creato come primo tentativo per le bande 868/915 MHz, o semplicemente SUB-1GHz, il 802.11ba è già destinato alle bande 2.4GHz e 5GHz. Nei precedenti "nuovi" standard, la compatibilità era raggiunta tramite un'intestazione comprensibile ai dispositivi più vecchi. In altre parole, l'idea era che i dispositivi più vecchi non avessero necessariamente la possibilità di riconoscere l'intero frame, ma dovevano semplicemente capire quando questo frame iniziava e quanto tempo sarebbe durata la trasmissione. Queste informazioni vengono proprio dall'intestazione. Anche il 802.11ba non fa eccezione, poiché è uno schema collaudato e funzionante (lasciamo perdere il discorso sui costi per ora).
In conclusione, il frame 802.11ba appare in questo modo:
Il preambolo non-HT e il breve frammento OFDM con modulazione BPSK consentono a tutti i dispositivi 802.11a/g/n/ac/ax di ricevere l'inizio della trasmissione di questo frame e di non interferire, passando alla modalità di ascolto del canale. Dopo il preambolo c'è il campo di sincronizzazione (SYNC), che è sostanzialmente equivalente a L-STF/L-LTF. Serve per consentire la regolazione della frequenza e la sincronizzazione del ricevitore del dispositivo. E proprio in quel momento il dispositivo trasmittente passa a una larghezza di canale di 4MHz. Perché? È molto semplice. Questo è necessario per poter ridurre la potenza e ottenere un rapporto segnale-a-potenza con il rumore (SINR) confrontabile. Oppure mantenere la potenza invariata e ottenere un notevole aumento della distanza di trasmissione. Direi che è una soluzione piuttosto elegante, inoltre consente di ridurre significativamente le esigenze di alimentazione. Pensiamo, ad esempio, al popolare ESP8266. In modalità di trasmissione utilizzando un bitrate di 54 Mbps e una potenza di 16dBm consuma 196 mA, che è estremamente elevato per qualcosa come una CR2032. Se riduciamo la larghezza del canale di cinque volte e riduciamo di cinque volte la potenza del trasmettitore, praticamente non perderemo in distanza di trasmissione, ma la corrente assorbita scenderà drasticamente, diciamo, a circa 50 mA. Non che questo sia cruciale per l'AP che trasmette il frame per WUR, ma è comunque positivo. Per lo STA, questo ha già un senso, poiché un consumo inferiore consente l'uso di qualcosa come una CR2032 o batterie progettate per una lunga conservazione dell'energia con tassi di scarica nominali bassi. Naturalmente, nulla è gratuito e la riduzione della larghezza del canale comporterà una diminuzione della velocità di canale con un aumento del tempo di trasmissione di un frame di conseguenza.
A proposito della velocità di canale. Lo standard attuale prevede due varianti: 62,5 Kbps e 250 Kbps. Sentite, zigbee è nell'aria? Non è una coincidenza, 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, la portata dei dispositivi 802.11ba dovrebbe essere maggiore, il che è molto utile per gli scenari IoT all'interno degli edifici.
Tuttavia, aspettate un attimo... Costringere tutte le stazioni circostanti a rimanere in silenzio, utilizzando solo 4 MHz da una banda di 20 MHz... "È uno spreco!" – direte e avrete ragione. Ma no, QUI C'È UN VERO SPRECO!
Lo standard prevede la possibilità di utilizzare sotto-canali da 40 MHz e 80 MHz. In questo caso, i bitrate di ciascun sotto-canale possono essere diversi e, per allineare i tempi di trasmissione, alla fine del frame viene aggiunto un padding. Cioè, un dispositivo può occupare tempo di trasmissione su tutti gli 80 MHz, ma utilizzarne solo 16 MHz. Questo è già uno vero spreco.
In effetti, i dispositivi Wi-Fi circostanti non hanno alcuna possibilità di capire cosa venga trasmesso nell'aria. Questo perché per la codifica dei frame 802.11ba NON viene utilizzato il consueto OFDM. Sì, il consorzio ha abbandonato audacemente ciò che ha funzionato senza problemi per molti anni. Al posto del classico OFDM, viene impiegata la modulazione Multi-Carrier (MC)-OOK. Il canale da 4 MHz è suddiviso in 16 (?) portanti, ciascuna delle quali utilizza la codifica Manchester. Durante questo processo, il campo DATA è logicamente suddiviso in segmenti di 4 μs o 2 μs a seconda della velocità di trasmissione, e in ciascun segmento un'unità può essere rappresentata da un livello di codifica basso o alto. Questa è una soluzione progettata per evitare lunghe sequenze di zeri o uni. Scrambling al minimo.
Il livello MAC è stato estremamente semplificato. Contiene solo i seguenti campi:
- Frame Control
Può assumere valori Beacon, WuP, Discovery o qualsiasi altro a scelta del fornitore.
Il Beacon serve per la sincronizzazione del tempo, WuP è destinato a risvegliare un dispositivo o un gruppo di dispositivi, mentre il Discovery funziona in direzione opposta da STA a AP ed è progettato per trovare punti di accesso che supportano 802.11ba. In questo campo viene anche trasmessa la lunghezza del frame se supera i 48 bit. - ID
A seconda del tipo di frame, può identificare AP, oppure STA o un gruppo di STA a cui è destinato questo frame. (Sì, è possibile risvegliare i dispositivi in gruppi, si chiama groupcast wake-ups ed è piuttosto interessante).
- Type Dependent (TD)
Campo piuttosto flessibile. È qui che possono essere trasmessi il tempo esatto, un segnale di aggiornamento del firmware/configurazione con il numero di versione, o altre informazioni utili che la STA dovrebbe conoscere.
- Frame Checksum Field (FCS)
Qui è tutto semplice. È un checksum
Ma affinché la tecnologia funzioni, non basta semplicemente inviare un fotogramma nel formato corretto. STA e AP devono concordare. STA comunica i propri parametri, compreso il tempo necessario per inizializzare il PCR. Tutte le intese avvengono utilizzando normali frame 802.11, dopodiché STA può disattivare il PCR e passare alla modalità di attivazione WUR. E può anche riposare un po', se ne ha la possibilità. Perché se c'è, è meglio approfittarne.
Poi inizia un'altra piccola estrazione di preziosi milliampere-ora chiamata WUR Duty Cycle. Non c'è niente di complicato, basta che STA e AP concordino un programma di sonno, proprio come per TWT. Dopo di che, STA rimane principalmente in stato di sonno, accendendo di tanto in tanto il WUR per ascoltare "È arrivato qualcosa di utile per me?". E solo se necessario, risveglia il modulo radio principale per lo scambio di traffico.
Cambia radicalmente la situazione rispetto a TWT e U-APSD, non è vero?
E ora un punto importante a cui non si pensa subito. WUR non deve necessariamente operare alla stessa frequenza del modulo principale. Al contrario, è preferibile e consigliato che funzioni su un canale diverso. In questo modo, la funzionalità 802.11ba non interferisce in alcun modo con il funzionamento della rete e può anzi essere utilizzata per inviare informazioni utili. Location, Neighbour List e molto altro all'interno di altri standard 802.11, ad esempio 802.11k/v. E quali vantaggi si aprono per le reti Mesh… Ma questo è un argomento per un articolo a parte.
Per quanto riguarda il destino stesso dello standard come documento, . Quindi, quest'anno ci si può aspettare un vero e proprio standard o almeno le prime implementazioni. E quanto si diffonderà — solo il tempo lo dirà.
Ecco come stanno le cose… (c) .
Letteratura consigliata per approfondire:
Fonte: habr.com
