Non molto tempo fa, su varie altre risorse e nel mio blog, ho parlato del fatto che ZigBee è morto ed è ora di seppellire l'assistente di volo. Per dare una bella faccia a un brutto gioco con Thread che funziona su IPv6 e 6LowPan, è sufficiente il Bluetooth (LE) più adatto a questo. Ma di questo te ne parlerò un'altra volta. Oggi parleremo di come il gruppo di lavoro del comitato ha deciso di pensarci due volte dopo l'802.11ah e ha deciso che era giunto il momento di aggiungere una versione completa di qualcosa come LRLP (Long-Range Low-Power) al pool di standard 802.11, simile a LoRA. Ma ciò si è rivelato impossibile da attuare senza macellare la vacca sacra della compatibilità con le versioni precedenti. Di conseguenza, il lungo raggio è stato abbandonato ed è rimasto solo il basso consumo, il che è anch'esso molto buono. Il risultato è stato un mix di 802.11 + 802.15.4, o semplicemente Wi-Fi + ZigBee. Cioè, possiamo dire che la nuova tecnologia non è un concorrente delle soluzioni LoraWAN, ma, al contrario, viene creata per completarle.
Quindi iniziamo con la cosa più importante: ora i dispositivi che supportano 802.11ba dovrebbero avere due moduli radio. Apparentemente, dopo aver esaminato 802.11ah/ax con la sua tecnologia Target Wake Time (TWT), gli ingegneri hanno deciso che ciò non era sufficiente e che era necessario ridurre radicalmente il consumo energetico. Perché lo standard prevede una divisione in due diverse tipologie di radio: Primary Communication Radio (PCR) e Wake-Up Radio (WUR). Se con il primo tutto è chiaro, questa è la radio principale, trasmette e riceve dati, con il secondo non è così tanto. In effetti, il WUR è principalmente un dispositivo di ascolto (RX) ed è progettato per consumare pochissima energia per funzionare. Il suo compito principale è ricevere un segnale di riattivazione dall'AP e abilitare la PCR. Cioè, questo metodo riduce significativamente il tempo di avvio a freddo e consente di riattivare i dispositivi in un determinato momento con la massima precisione. Questo è molto utile quando hai, diciamo, non dieci dispositivi, ma centodieci e devi scambiare dati con ciascuno di essi in un breve periodo di tempo. Inoltre, la logica della frequenza e della periodicità del risveglio si sposta dal lato AP. Se, ad esempio, LoRAWAN utilizza la metodologia PUSH quando gli attuatori stessi si svegliano e trasmettono qualcosa in onda e dormono per il resto del tempo, allora in questo caso, al contrario, l'AP decide quando e quale dispositivo dovrebbe svegliarsi e gli attuatori stessi... non sempre dormono.
Passiamo ora ai formati dei frame e alla compatibilità. Se 802.11ah, come primo tentativo, è stato creato per le bande 868/915 MHz o semplicemente SUB-1GHz, allora 802.11ba è già destinato alle bande 2.4GHz e 5GHz. Nei precedenti "nuovi" standard la compatibilità veniva raggiunta tramite un preambolo comprensibile ai dispositivi più vecchi. Cioè, il calcolo è sempre stato che i dispositivi più vecchi non devono necessariamente essere in grado di riconoscere l'intero frame, è sufficiente che capiscano quando inizierà questo frame e quanto durerà la trasmissione. È questa l'informazione che prendono dal preambolo. 802.11ba non ha fatto eccezione, poiché lo schema è collaudato e collaudato (per ora ignoreremo la questione dei costi).
Di conseguenza, il frame 802.11ba assomiglia a questo:
Un preambolo non HT e un breve frammento OFDM con modulazione BPSK consentono a tutti i dispositivi 802.11a/g/n/ac/ax di sentire l'inizio della trasmissione di questo frame e di non interferire, entrando in modalità di ascolto broadcast. Dopo il preambolo c'è il campo di sincronizzazione (SYNC), che è essenzialmente un analogo di L-STF/L-LTF. Serve per consentire la regolazione della frequenza e la sincronizzazione del ricevitore dell'apparecchio. Ed è in questo momento che il dispositivo trasmittente passa ad un'altra larghezza del canale di 4 MHz. Per quello? Tutto è molto semplice. Ciò è necessario affinché la potenza possa essere ridotta e si possa ottenere un rapporto segnale-rumore (SINR) comparabile. Oppure lascia la potenza così com'è e ottieni un aumento significativo della portata di trasmissione. Direi che si tratta di una soluzione molto elegante, che permette anche di ridurre notevolmente il fabbisogno di alimentatori. Ricordiamo, ad esempio, il popolare ESP8266. In modalità di trasmissione utilizzando un bitrate di 54 Mbps e una potenza di 16dBm, consuma 196 mA, che è proibitivo per qualcosa come il CR2032. Se riduciamo la larghezza del canale di cinque volte e riduciamo la potenza del trasmettitore di cinque volte, praticamente non perderemo il raggio di trasmissione, ma il consumo di corrente sarà ridotto di un fattore, diciamo, a circa 50 mA. Non che questo sia critico da parte dell’AP che trasmette il frame per WUR, ma non è comunque male. Ma per STA questo ha già senso, poiché un consumo inferiore consente l’uso di qualcosa come CR2032 o batterie progettate per l’accumulo di energia a lungo termine con correnti di scarica nominali basse. Naturalmente, nulla è gratuito e la riduzione della larghezza del canale porterà rispettivamente ad una diminuzione della velocità del canale con un aumento del tempo di trasmissione di un frame.
A proposito, sulla velocità del canale. Lo standard nella sua forma attuale prevede due opzioni: 62.5 Kbps e 250 Kbps. Senti l'odore di ZigBee? Questo non è facile, poiché ha una larghezza di canale di 2Mhz invece di 4Mhz, ma un diverso tipo di modulazione con una densità spettrale maggiore. Di conseguenza, la portata dei dispositivi 802.11ba dovrebbe essere maggiore, il che è molto utile per gli scenari IoT indoor.
Però, aspettate un attimo... Costringendo al silenzio tutte le stazioni della zona, utilizzando solo 4 MHz della banda dei 20 MHz... “QUESTO È UNO SPRECO!” - dirai e avrai ragione. Ma no, QUESTO È IL VERO RIFIUTO!
Lo standard offre la possibilità di utilizzare sottocanali da 40 MHz e 80 MHz. In questo caso, i bitrate di ciascun sottocanale possono essere diversi e, per corrispondere all'ora di trasmissione, viene aggiunto il Padding alla fine del frame. Cioè, il dispositivo può occupare il tempo di trasmissione su tutti gli 80 MHz, ma usarlo solo sui 16 MHz. Questo è un vero spreco.
A proposito, i dispositivi Wi-Fi circostanti non hanno alcuna possibilità di capire cosa viene trasmesso lì. Perché il solito OFDM NON viene utilizzato per codificare i frame 802.11ba. Sì, proprio così, l’alleanza ha notoriamente abbandonato ciò che aveva funzionato perfettamente per molti anni. Invece del classico OFDM, viene utilizzata la modulazione Multi-Carrier (MC)-OOK. Il canale da 4 MHz è diviso in 16(?) sottoportanti, ciascuna delle quali utilizza la codifica Manchester. Allo stesso tempo, anche il campo DATA stesso è logicamente suddiviso in segmenti di 4 μs o 2 μs a seconda del bitrate, e in ciascuno di questi segmenti un livello di codifica basso o alto può corrispondere a un'unità. Questa è la soluzione per evitare una lunga sequenza di zeri o uno. La corsa al salario minimo.
Anche il livello MAC è estremamente semplificato. Contiene solo i seguenti campi:
- Controllo frame
Può assumere i valori Beacon, WuP, Discovery o qualsiasi altro valore a scelta del venditore.
Beacon viene utilizzato per la sincronizzazione dell'ora, WuP è progettato per riattivare uno o un gruppo di dispositivi e Discovery funziona nella direzione opposta da STA ad AP ed è progettato per trovare punti di accesso che supportano 802.11ba. Questo campo contiene anche la lunghezza del frame se supera i 48 bit. - ID
A seconda del tipo di frame, può identificare un AP, oppure una STA, oppure un gruppo di STA a cui è destinato questo frame. (Sì, puoi riattivare i dispositivi in gruppi, si chiama risvegli groupcast ed è davvero interessante).
- Dipendente dal tipo (TD)
Un campo piuttosto flessibile. È in esso che può essere trasmessa l'ora esatta, un segnale sull'aggiornamento del firmware/configurazione con un numero di versione o qualcosa di utile di cui la STA dovrebbe essere a conoscenza.
- Campo checksum frame (FCS)
Tutto è semplice qui. Questa è una somma di controllo
Ma affinché la tecnologia funzioni, non è sufficiente inviare semplicemente un frame nel formato richiesto. La STA e l'AP devono essere d'accordo. La STA riporta i suoi parametri, compreso il tempo necessario per inizializzare la PCR. Tutta la negoziazione avviene utilizzando frame 802.11 regolari, dopodiché la STA può disabilitare PCR ed entrare in modalità di abilitazione WUR. O magari anche dormire un po', se possibile. Perché se esiste, allora è meglio usarlo.
Poi arriva un po' più di compressione delle preziose ore in milliampere chiamate WUR Duty Cycle. Non c'è niente di complicato, solo STA e AP, analogamente a come è stato per TWT, concordano un programma di sonno. Dopodiché, STA dorme per lo più, accendendo occasionalmente WUR per ascoltare "Mi è arrivato qualcosa di utile?" E solo se necessario risveglia il modulo radio principale per lo scambio del traffico.
Cambia radicalmente la situazione rispetto a TWT e U-APSD, non è vero?
E ora una sfumatura importante a cui non pensi subito. Il WUR non deve funzionare alla stessa frequenza del modulo principale. Al contrario, è auspicabile e consigliabile che funzioni su un canale diverso. In questo caso la funzionalità 802.11ba non interferisce in alcun modo con il funzionamento della rete e, anzi, può essere utilizzata per inviare informazioni utili. Posizione, Elenco dei vicini e molto altro all'interno di altri standard 802.11, come 802.11k/v. E quali vantaggi si aprono per le reti Mesh... Ma questo è l'argomento di un articolo a parte.
Per quanto riguarda il destino della norma stessa come documento, allora . Cioè, quest'anno possiamo aspettarci uno standard vero e proprio o almeno le prime implementazioni. Solo il tempo dirà quanto sarà diffuso.
Cose del genere... (c) .
Lettura consigliata:
Fonte: habr.com