No hace mucho, en varios otros recursos y en mi blog, hablé sobre cómo ZigBee está muerto y ya es hora de enterrar a la azafata. Para hacer buena cara ante un mal juego con Thread, que funciona sobre IPv6 y 6LowPan, basta con un Bluetooth (LE) más adecuado para esto. Pero de eso hablaré en otra ocasión. Hoy hablaremos sobre cómo el grupo de trabajo del comité reconsideró bien después de 802.11ah y decidió que era el momento de agregar a la serie de estándares 802.11 una versión completa de algo como LRLP (Long-Range Low-Power) por analogía con LoRA. Sin embargo, esto resultó inviable sin sacrificar la sagrada vaca de la compatibilidad hacia atrás. Al final, se desestimó el Long-Range y solo quedó el Low-Power, lo cual también es bastante bueno. Resultó ser una mezcla de 802.11 + 802.15.4 o, en términos simples, Wi-Fi + ZigBee. Es decir, se puede decir que la nueva tecnología no es un competidor de las soluciones LoraWAN, sino que, por el contrario, se crea para complementarlas.
Entonces, comencemos con lo más importante: Ahora en los dispositivos que soportan 802.11ba debe haber dos módulos de radio. Al parecer, al observar el 802.11ah/ax con su tecnología Target Wake Time (TWT), los ingenieros decidieron que esto no era suficiente y que era necesario reducir drásticamente el consumo de energía. Para ello, el estándar prevé la división en dos tipos diferentes de radio: Primary Communication Radio (PCR) y Wake-Up Radio (WUR). Si con el primero todo está claro, siendo esta la radio principal que envía y recibe datos, con el segundo no es tan claro. De hecho, el WUR se presenta en su mayor parte como un dispositivo receptor (RX) y, según el diseño, debería consumir muy poca energía para funcionar. Su tarea principal es recibir una señal de activación del AP y encender el PCR. Esto significa que este método reduce significativamente el tiempo de arranque en frío y permite despertar dispositivos a una hora programada con máxima precisión. Esto es muy útil cuando, digamos, no tienes diez dispositivos, sino ciento diez, y necesitas intercambiar datos con cada uno de ellos en un corto intervalo de tiempo. Además, la lógica de frecuencia y periodicidad de activación se traslada al AP. Si, por ejemplo, en LoRAWAN se aplica la metodología PUSH, donde los dispositivos ejecutores se despiertan por sí mismos y transmiten en el aire, durmiendo el resto del tiempo, en este caso es al contrario, el AP decide cuándo y qué dispositivo debe despertarse, y los dispositivos ejecutores... no siempre están durmiendo.
Ahora pasemos a los formatos de tramas y a garantizar la compatibilidad. Si el 802.11ah, como primer intento, se creó para las bandas de 868/915 MHz o simplemente SUB-1GHz, el 802.11ba ya está diseñado para las bandas de 2.4GHz y 5GHz. En los anteriores "nuevos" estándares, la compatibilidad se lograba gracias a una preámbulo comprensible para dispositivos más antiguos. Es decir, siempre se suponía que los dispositivos más antiguos no necesitaban reconocer toda la trama, solo debían entender cuándo comenzaría la trama y cuánto tiempo duraría la transmisión. Esta es la información que obtienen del preámbulo. El 802.11ba no fue una excepción, ya que el esquema es probado y eficaz (no abordaremos el tema de los costos por ahora).
En resumen, la trama 802.11ba se ve algo así:
La preámbulo Non-HT y el fragmento corto de OFDM con modulación BPSK permite a todos los dispositivos 802.11a/g/n/ac/ax escuchar el inicio de la transmisión de este marco y no interferir, pasando al modo de escucha de la radiofrecuencia. Después del preámbulo, se incluye el campo de sincronización (SYNC), que es esencialmente el análogo de L-STF/L-LTF. Su propósito es permitir ajustar la frecuencia y sincronizar el receptor del dispositivo. Y es en este momento que el dispositivo transmisor cambia a un ancho de canal diferente de 4MHz. ¿Por qué? Es bastante simple. Esto es necesario para reducir la potencia y lograr una relación comparable entre la señal y el ruido (SINR). O, si se mantiene la potencia como está, se puede lograr un aumento significativo en la distancia de transmisión. Diría que esta es una solución bastante elegante, además de permitir reducir significativamente las demandas sobre las fuentes de alimentación. Recordemos, por ejemplo, el popular ESP8266. En modo de transmisión utilizando una tasa de bits de 54 Mbps y una potencia de 16dBm, consume 196 mA, lo cual es excesivo para algo como una CR2032. Si se reduce el ancho de banda cinco veces y se disminuye la potencia del transmisor cinco veces, prácticamente no perderemos en distancia de transmisión, pero la corriente consumida se reducirá drásticamente, digamos, a aproximadamente 50 mA. No es que esto sea crítico desde el punto de vista de la AP que transmite el marco para WUR, pero sigue siendo un buen resultado. Para STA ya tiene sentido, ya que un consumo más bajo permite utilizar precisamente algo como una CR2032 o baterías diseñadas para un almacenamiento prolongado de energía con bajo consumo nominal de descarga. Por supuesto, nada es gratis, y la reducción del ancho de canal conducirá a una disminución de la velocidad del canal con un aumento en el tiempo de transmisión de un solo marco en consecuencia.
Hablando de la velocidad del canal. El estándar en su forma actual prevé dos opciones, 62.5 Kbps y 250 Kbps. ¿Sientes el aroma de ZigBee? No es casualidad, ya que tiene un ancho de canal de 2MHz en lugar de 4MHz, pero otro tipo de modulación con una mayor densidad espectral. Como resultado, el alcance de los dispositivos 802.11ba debería ser mayor, lo cual es bastante conveniente para los escenarios de IoT en interiores.
Sin embargo, espera un momento... Hacer que todas las estaciones en los alrededores permanezcan en silencio utilizando solo 4 MHz de la banda de 20 MHz... "¡ESO ES DESPERDICIO!" dirás, y tendrás razón. Pero no, ¡ESTO ES EL VERDADERO DESPERDICIO!
El estándar incluye la posibilidad de utilizar subcanales de 40 MHz y 80 MHz. Los bitrates de cada subcanal pueden ser diferentes, y para que coincidan en tiempo de transmisión, se añade un Padding al final del marco. Es decir, el dispositivo puede ocupar tiempo de aire en todos los 80 MHz, pero usarlo solo en 16 MHz. Esto ya es un verdadero desperdicio.
Por cierto, los dispositivos Wi-Fi circundantes no tienen ninguna posibilidad de entender qué se está transmitiendo en el aire. Porque para la codificación de los tramas 802.11ba NO se utiliza el OFDM habitual. Sí, así de audazmente la alianza renunció a lo que funcionó sin fallas durante muchos años. En lugar del clásico OFDM, se aplica la modulación Multi-Carrier (MC)-OOK. El canal de 4 MHz se divide en 16(?) subportadoras, cada una de las cuales utiliza codificación manchester. Además, el propio campo DATA se divide lógicamente en segmentos de 4 μs o 2 μs dependiendo del bitrate, y en cada segmento puede haber un nivel bajo o alto de codificación. Esta es una solución para evitar largas secuencias de ceros o unos. Scrambling en su mínima expresión.
El nivel MAC también está extremadamente simplificado. Solo contiene los siguientes campos:
- Control de Trama
Puede tomar valores de Beacon, WuP, Discovery o cualquier otro a elección del proveedor.
Beacon se utiliza para la sincronización del tiempo, WuP está destinado a despertar a uno o un grupo de dispositivos, mientras que Discovery trabaja en la dirección opuesta de STA a AP y está diseñado para buscar puntos de acceso que soporten 802.11ba. Además, en este campo se transmite la longitud del marco si excede 48 bits. - ID
Dependiendo del tipo de trama, puede identificar AP, o STA o grupo de STA para los cuales se destina esta trama. (Sí, se pueden despertar dispositivos en grupos, esto se llama groupcast wake-ups y es bastante interesante).
- Tipo Dependiente (TD)
Un campo bastante flexible. En él se puede transmitir la hora exacta, una señal de actualización de firmware/configuración con el número de versión o algo útil que STA deba saber.
- Campo de Suma de Verificación de Trama (FCS)
Aquí es todo simple. Es una suma de verificación
Pero para que la tecnología funcione, no es suficiente con enviar un cuadro en el formato correcto. STA y AP deben llegar a un acuerdo. STA informa sus parámetros, incluido el tiempo necesario para inicializar el PCR. Todo el consenso se lleva a cabo utilizando marcos 802.11 estándar, después de lo cual la STA puede desactivar el PCR y entrar en modo de activación WUR. Y puede incluso dormir un poco, si es posible. Porque si hay oportunidad, es mejor aprovecharla.
Luego comienza una pequeña extracción de preciosos miliamperios hora llamada Ciclo de Trabajo WUR. No hay nada complicado, simplemente STA y AP, similar a lo que sucedió con TWT, acuerdan un horario de sueño. Después de esto, la STA mayormente duerme, encendiendo ocasionalmente WUR para escuchar: '¿No ha llegado nada útil para mí?'. Y solo en caso de necesidad despierta el módulo de radio principal para intercambiar tráfico.
Cambia radicalmente la situación en comparación con TWT y U-APSD, ¿verdad?
Ahora hay un matiz importante en el que no se piensa de inmediato. WUR no necesariamente tiene que operar en la misma frecuencia que el módulo principal. Por el contrario, es deseable y recomendado que opere en un canal diferente. En tal caso, la funcionalidad 802.11ba de ninguna manera interfiere con el funcionamiento de la red y, por el contrario, puede usarse para enviar información útil. Información de ubicación, lista de vecinos y mucho más en el marco de otros estándares 802.11, como 802.11k/v. Y las ventajas que se abren para las redes Mesh... Pero ese es el tema de otro artículo.
En cuanto al destino del estándar como documento, . Es decir, este año se puede esperar un estándar verdadero o al menos las primeras implementaciones. Y cuánto se difundirá — solo el tiempo lo dirá.
Así están las cosas... (c) .
Literatura recomendada para leer:
Fuente: habr.com
