802.11ba (WUR) ou como cruzar unha serpe cun ourizo

Non hai moito tempo, noutros recursos e no meu blog, falei sobre o feito de que ZigBee está morto e é hora de enterrar á azafata. Para poñerlle boa cara a un xogo malo con Thread traballando enriba de IPv6 e 6LowPan, é suficiente o Bluetooth (LE) que é máis axeitado para iso. Pero disto falarei noutro momento. Hoxe falaremos de como o grupo de traballo do comité decidiu pensalo dúas veces despois de 802.11ah e decidiu que era hora de engadir unha versión completa de algo así como LRLP (Long-Range Low-Power) ao conxunto de estándares 802.11, similar. a LoRA. Pero isto resultou imposible de implementar sen sacrificar a vaca sagrada da retrocompatibilidade. Como resultado, Long-Range foi abandonado e só quedou Low-Power, o que tamén é moi bo. O resultado foi unha mestura de 802.11 + 802.15.4, ou simplemente Wi-Fi + ZigBee. É dicir, podemos dicir que a nova tecnoloxía non é competidora das solucións LoraWAN, senón que, pola contra, estase creando para complementar as mesmas.

Entón, comecemos polo máis importante: agora os dispositivos que admitan 802.11ba deberían ter dous módulos de radio. Ao parecer, despois de analizar 802.11ah/ax coa súa tecnoloxía Target Wake Time (TWT), os enxeñeiros decidiron que isto non era suficiente e necesitaban reducir radicalmente o consumo de enerxía. Por que o estándar prevé unha división en dous tipos diferentes de radio: Radio de comunicación primaria (PCR) e Radio de espertar (WUR). Se coa primeira está todo claro, esta é a radio principal, transmite e recibe datos, entón coa segunda non o é tanto. De feito, o WUR é principalmente un dispositivo de escoita (RX) e está deseñado para consumir moi pouca enerxía para funcionar. A súa tarefa principal é recibir un sinal de espertar do AP e activar a PCR. É dicir, este método reduce significativamente o tempo de inicio en frío e permite espertar os dispositivos nun momento determinado coa máxima precisión. Isto é moi útil cando tes, por exemplo, non dez dispositivos, senón cento dez e necesitas intercambiar datos con cada un deles nun curto período de tempo. Ademais, a lóxica da frecuencia e periodicidade do espertar móvese ao lado AP. Se, por exemplo, LoRAWAN usa a metodoloxía PUSH cando os propios actuadores espertan e transmiten algo no aire e dormen o resto do tempo, entón neste caso, pola contra, o AP decide cando e que dispositivo debe espertar e os propios actuadores... non sempre dormen.

Agora imos pasar aos formatos de cadros e compatibilidade. Se 802.11ah, como primeiro intento, foi creado para as bandas de 868/915 MHz ou simplemente SUB-1GHz, entón 802.11ba xa está pensado para as bandas de 2.4GHz e 5GHz. Nos "novos" estándares anteriores, a compatibilidade conseguiuse mediante un preámbulo que era comprensible para os dispositivos máis antigos. É dicir, o cálculo sempre foi que os dispositivos máis antigos non teñen necesariamente que ser capaces de recoñecer o cadro completo; é suficiente para que comprendan cando comezará este cadro e canto durará a transmisión. É esta información a que toman do preámbulo. 802.11ba non foi unha excepción, xa que o esquema está comprobado e comprobado (ignoraremos o tema dos custos polo momento).

Como resultado, o cadro 802.11ba ten un aspecto así:

802.11ba (WUR) ou como cruzar unha serpe cun ourizo

Un preámbulo non HT e un pequeno fragmento OFDM con modulación BPSK permiten que todos os dispositivos 802.11a/g/n/ac/ax escoiten o inicio da transmisión deste cadro e non interfiran, pasando ao modo de escoita de emisión. Despois do preámbulo vén o campo de sincronización (SYNC), que é esencialmente un análogo de L-STF/L-LTF. Serve para facer posible axustar a frecuencia e sincronizar o receptor do dispositivo. E é neste momento cando o dispositivo transmisor cambia a outro ancho de canle de 4 MHz. Para qué? Todo é moi sinxelo. Isto é necesario para reducir a potencia e conseguir unha relación sinal-ruído (SINR) comparable. Ou deixar a potencia como está e conseguir un aumento significativo do alcance de transmisión. Diría que esta é unha solución moi elegante, que tamén permite reducir significativamente os requisitos para as fontes de alimentación. Lembremos, por exemplo, o popular ESP8266. No modo de transmisión usando unha taxa de bits de 54 Mbps e unha potencia de 16 dBm, consome 196 mA, que é prohibitivamente alto para algo como o CR2032. Se reducimos o ancho da canle en cinco veces e reducimos a potencia do transmisor en cinco veces, entón practicamente non perderemos o alcance de transmisión, pero o consumo de corrente reducirase nun factor de, por exemplo, a uns 50 mA. Non é que isto sexa crítico por parte do AP que transmite o marco para WUR, pero aínda así non está mal. Pero para STA isto xa ten sentido, xa que un menor consumo permite o uso de algo como CR2032 ou baterías deseñadas para almacenamento de enerxía a longo prazo con baixas correntes de descarga nominal. Por suposto, nada vén de balde e reducir o ancho da canle levará a unha diminución da velocidade da canle cun aumento do tempo de transmisión dun fotograma, respectivamente.

Por certo, sobre a velocidade da canle. O estándar na súa forma actual ofrece dúas opcións: 62.5 Kbps e 250 Kbps. Sentes o cheiro a ZigBee? Isto non é doado, xa que ten un ancho de canle de 2 Mhz en lugar de 4 Mhz, pero un tipo de modulación diferente con maior densidade espectral. Como resultado, o alcance dos dispositivos 802.11ba debería ser maior, o que é moi útil para escenarios de IoT en interiores.

Aínda que, agarde un minuto... Obrigar a todas as emisoras da zona a estar en silencio, mentres usan só 4 MHz da banda de 20 MHz... "ISO É UN DESPERDICIO!" - dirás e terás razón. Pero non, ESTE É O VERDADERO DESPERDICIO!

802.11ba (WUR) ou como cruzar unha serpe cun ourizo

O estándar ofrece a posibilidade de usar subcanles de 40 MHz e 80 MHz. Neste caso, as taxas de bits de cada subcanle poden ser diferentes e, para coincidir co tempo de emisión, engádese un recheo ao final do cadro. É dicir, o dispositivo pode ocupar tempo de antena en todos os 80 MHz, pero utilízao só en 16 MHz. Isto é un auténtico desperdicio.

Por certo, os dispositivos Wi-Fi circundantes non teñen ningunha posibilidade de entender o que se transmite alí. Porque o OFDM habitual NON se usa para codificar cadros 802.11ba. Si, así, a alianza abandonou o que funcionara perfectamente durante moitos anos. En lugar do clásico OFDM, utilízase a modulación Multi-Carrier (MC)-OOK. A canle de 4 MHz divídese en 16 (?) subportadoras, cada unha das cales usa a codificación Manchester. Ao mesmo tempo, o propio campo DATA tamén se divide loxicamente en segmentos de 4 μs ou 2 μs dependendo da taxa de bits, e en cada un destes segmentos pode corresponder un nivel de codificación baixo ou alto. Esta é a solución para evitar unha secuencia longa de ceros ou uns. Revolto de salarios mínimos.

802.11ba (WUR) ou como cruzar unha serpe cun ourizo

O nivel MAC tamén é moi simplificado. Só contén os seguintes campos:

  • Control de cadros

    Pode tomar os valores Beacon, WuP, Discovery ou calquera outro valor que elixa o vendedor.
    Beacon úsase para a sincronización horaria, WuP está deseñado para espertar un ou un grupo de dispositivos e Discovery funciona na dirección oposta de STA a AP e está deseñado para atopar puntos de acceso compatibles con 802.11ba. Este campo tamén contén a lonxitude do cadro se supera os 48 bits.

  • ID

    Dependendo do tipo de marco, pode identificar un AP, ou un STA, ou un grupo de STA ao que está destinado este marco. (Si, podes espertar os dispositivos en grupos, chámase despertadores de groupcast e é moi xenial).

  • Dependente do tipo (TD)

    Un campo bastante flexible. É nela onde se pode transmitir a hora exacta, un sinal sobre unha actualización de firmware/configuración cun número de versión ou algo útil que o STA debería saber.

  • Campo de suma de verificación de trama (FCS)
    Todo é sinxelo aquí. Esta é unha suma de verificación

Pero para que a tecnoloxía funcione, non é suficiente con simplemente enviar un marco no formato necesario. O STA e AP deben estar de acordo. O STA informa dos seus parámetros, incluíndo o tempo necesario para inicializar a PCR. Toda a negociación ocorre usando cadros 802.11 habituais, despois do cal o STA pode desactivar a PCR e entrar no modo de activación de WUR. Ou quizais incluso durmir un pouco, se é posible. Porque se existe, é mellor usalo.
A continuación vén un pouco máis de apretamento de preciosas horas de miliamperios chamado ciclo de traballo WUR. Non hai nada complicado, só STA e AP, por analoxía con como foi para TWT, acordan un horario de sono. Despois disto, STA dorme principalmente, activando ocasionalmente WUR para escoitar "¿Chegou algo útil para min?" E só se é necesario, esperta o módulo de radio principal para o intercambio de tráfico.

Cambia radicalmente a situación en comparación con TWT e U-APSD, non é?

E agora un matiz importante no que non pensas inmediatamente. O WUR non ten que funcionar á mesma frecuencia que o módulo principal. Pola contra, é desexable e recomendable que funcione nunha canle diferente. Neste caso, a funcionalidade 802.11ba non interfire de ningún xeito co funcionamento da rede e, pola contra, pódese utilizar para enviar información útil. Ubicación, Lista de veciños e moito máis dentro doutros estándares 802.11, por exemplo 802.11k/v. E que vantaxes se abren para as redes Mesh... Pero este é o tema dun artigo aparte.

En canto ao destino da propia norma como documento, entón Actualmente o borrador 6.0 está listo cunha taxa de aprobación: 96 %. É dicir, este ano podemos esperar un estándar real ou polo menos as primeiras implantacións. Só o tempo dirá o difundido que estará.

Tales cousas... (c) EvilWirelesMan.

Lecturas recomendadas:

IEEE 802.11ba - Wi-Fi de potencia extremadamente baixa para Internet masivo das cousas - Desafíos, problemas abertos, avaliación do rendemento

IEEE 802.11ba: Radio despertador de baixa potencia para IoT verde

Radio despertador habilitada para IEEE 802.11: casos de uso e aplicacións

Fonte: www.habr.com

Engadir un comentario