No hace mucho, en varios otros recursos y en mi blog, hablé sobre el hecho de que ZigBee está muerto y es hora de enterrar a la azafata. Para poner buena cara a un mal juego con Thread funcionando sobre IPv6 y 6LowPan, Bluetooth (LE) que es más adecuado para esto es suficiente. Pero esto ya os lo contaré en otra ocasión. Hoy hablaremos sobre cómo el grupo de trabajo del comité decidió pensar dos veces después de 802.11ah y decidió que era hora de agregar una versión completa de algo como LRLP (Long-Range Low-Power) al conjunto de estándares 802.11, similar a LoRA. Pero esto resultó imposible de implementar sin sacrificar la vaca sagrada de la compatibilidad con versiones anteriores. Como resultado, se abandonó el largo alcance y solo quedó el bajo consumo, lo cual también es muy bueno. El resultado fue una mezcla de 802.11 + 802.15.4, o simplemente Wi-Fi + ZigBee. Es decir, podemos decir que la nueva tecnología no compite con las soluciones LoraWAN, sino que, por el contrario, se está creando para complementarlas.
Entonces, comencemos con lo más importante: ahora los dispositivos compatibles con 802.11ba deberían tener dos módulos de radio. Aparentemente, después de analizar 802.11ah/ax con su tecnología Target Wake Time (TWT), los ingenieros decidieron que esto no era suficiente y que era necesario reducir radicalmente el consumo de energía. Por qué el estándar prevé una división en dos tipos diferentes de radio: radio de comunicación primaria (PCR) y radio despertador (WUR). Si con el primero todo está claro, esta es la radio principal, transmite y recibe datos, entonces con el segundo no lo es tanto. De hecho, el WUR es principalmente un dispositivo de escucha (RX) y está diseñado para consumir muy poca energía para funcionar. Su tarea principal es recibir una señal de activación del AP y habilitar la PCR. Es decir, este método reduce significativamente el tiempo de inicio en frío y le permite reactivar los dispositivos en un momento determinado con la máxima precisión. Esto es muy útil cuando no tienes, digamos, diez dispositivos, sino ciento diez y necesitas intercambiar datos con cada uno de ellos en un corto período de tiempo. Además, la lógica de la frecuencia y periodicidad del despertar se mueve hacia el lado AP. Si, digamos, LoRAWAN usa la metodología PUSH cuando los propios actuadores se despiertan y transmiten algo al aire, y el resto del tiempo duermen, entonces, en este caso, por el contrario, el AP decide cuándo y qué dispositivo debe despertarse, y los propios actuadores... no siempre duermen.
Ahora pasemos a los formatos de cuadros y la compatibilidad. Si 802.11ah, como primer intento, se creó para las bandas de 868/915 MHz o simplemente SUB-1GHz, entonces 802.11ba ya está destinado a las bandas de 2.4GHz y 5GHz. En los "nuevos" estándares anteriores, la compatibilidad se lograba mediante un preámbulo que era comprensible para los dispositivos más antiguos. Es decir, siempre se ha calculado que los dispositivos más antiguos no necesitan necesariamente poder reconocer la trama completa, sino que les basta con saber cuándo comenzará esta trama y cuánto durará la transmisión. Es esta información la que toman del preámbulo. 802.11ba no fue una excepción, ya que el esquema está probado y comprobado (por ahora ignoraremos la cuestión de los costos).
Como resultado, el marco 802.11ba se parece a esto:
Un preámbulo no HT y un breve fragmento OFDM con modulación BPSK permiten que todos los dispositivos 802.11a/g/n/ac/ax escuchen el comienzo de la transmisión de esta trama y no interfieran, pasando al modo de escucha de transmisión. Después del preámbulo viene el campo de sincronización (SYNC), que es esencialmente un análogo de L-STF/L-LTF. Sirve para permitir ajustar la frecuencia y sincronizar el receptor del dispositivo. Y es en este momento que el dispositivo transmisor cambia a otro ancho de canal de 4 MHz. ¿Para qué? Todo es muy sencillo. Esto es necesario para poder reducir la potencia y lograr una relación señal-ruido (SINR) comparable. O dejar la potencia como está y lograr un aumento significativo en el rango de transmisión. Yo diría que se trata de una solución muy elegante, que también permite reducir significativamente los requisitos de fuente 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 16 dBm, consume 196 mA, lo que es prohibitivamente alto para algo como el CR2032. Si reducimos el ancho del canal cinco veces y reducimos la potencia del transmisor cinco veces, prácticamente no perderemos alcance de transmisión, pero el consumo de corriente se reducirá en un factor de, digamos, a aproximadamente 50 mA. No es que esto sea crítico por parte del AP que transmite la trama para WUR, pero aun así no está mal. Pero para STA esto ya tiene sentido, ya que un menor consumo permite el uso de algo como CR2032 o baterías diseñadas para el almacenamiento de energía a largo plazo con corrientes de descarga nominales bajas. Por supuesto, nada viene gratis y reducir el ancho del canal conducirá a una disminución en la velocidad del canal con un aumento en el tiempo de transmisión de un cuadro, respectivamente.
Por cierto, sobre la velocidad del canal. El estándar en su forma actual ofrece dos opciones: 62.5 Kbps y 250 Kbps. ¿Sientes el olor de ZigBee? Esto no es fácil, ya que tiene un ancho de canal de 2Mhz en lugar de 4Mhz, pero un tipo diferente de modulación con mayor densidad espectral. Como resultado, el alcance de los dispositivos 802.11ba debería ser mayor, lo cual es muy útil para escenarios de IoT en interiores.
Aunque, esperen un momento... Obligar a todas las estaciones de la zona a estar en silencio, mientras se utiliza sólo 4 MHz de la banda de 20 MHz... “¡ESTO ES UN DESPERDICIO!” - dirás y tendrás razón. Pero no, ¡ESTE ES EL VERDADERO DESPERDICIO!
El estándar ofrece la posibilidad de utilizar subcanales de 40 MHz y 80 MHz. En este caso, las velocidades de bits de cada subcanal pueden ser diferentes y, para coincidir con el tiempo de transmisión, se agrega relleno al final del cuadro. Es decir, el dispositivo puede ocupar tiempo aire en los 80 MHz, pero usarlo solo en 16 MHz. Esto es un verdadero desperdicio.
Por cierto, los dispositivos Wi-Fi circundantes no tienen ninguna posibilidad de entender lo que se transmite allí. Porque el OFDM habitual NO se utiliza para codificar tramas 802.11ba. Sí, así de simple, la alianza abandonó lo que había funcionado perfectamente durante muchos años. En lugar del OFDM clásico, se utiliza la modulación Multi-Carrier (MC)-OOK. El canal de 4MHz está dividido en 16(?) subportadoras, cada una de las cuales utiliza codificación Manchester. Al mismo tiempo, el campo DATOS en sí también se divide lógicamente en segmentos de 4 μs o 2 μs dependiendo de la tasa de bits, y en cada uno de esos segmentos un nivel de codificación alto o bajo puede corresponder a uno. Esta es la solución para evitar una larga secuencia de ceros o unos. Luchando por los salarios mínimos.
El nivel MAC también está extremadamente simplificado. Sólo contiene los siguientes campos:
- Control de cuadros
Puede tomar los valores Beacon, WuP, Discovery o cualquier otro valor a elección del proveedor.
Beacon se utiliza para la sincronización horaria, WuP está diseñado para activar uno o un grupo de dispositivos y Discovery funciona en la dirección opuesta de STA a AP y está diseñado para encontrar puntos de acceso que admitan 802.11ba. Este campo también contiene la longitud de la trama si supera los 48 bits. - ID
Dependiendo del tipo de trama, puede identificar un AP, una STA o un grupo de STA a las que está destinada esta trama. (Sí, puedes activar dispositivos en grupos, se llama activación por transmisión en grupo y es genial).
- Dependiente del tipo (TD)
Un campo bastante flexible. Es en él donde se puede transmitir la hora exacta, una señal sobre una actualización de firmware/configuración con un número de versión, o algo útil que la STA debería conocer.
- Campo de suma de comprobación del marco (FCS)
Aquí todo es sencillo. Esta es una suma de control
Pero para que la tecnología funcione, no basta con enviar un marco en el formato requerido. La STA y la AP deben estar de acuerdo. La STA informa sus parámetros, incluido el tiempo necesario para inicializar la PCR. Toda la negociación se produce mediante tramas 802.11 normales, después de las cuales STA puede desactivar PCR e ingresar al modo de habilitación WUR. O tal vez incluso dormir un poco, si es posible. Porque si existe, entonces es mejor usarlo.
Luego viene un poco más de exprimir los preciosos miliamperios hora llamado ciclo de trabajo WUR. No hay nada complicado, solo STA y AP, por analogía con TWT, acuerdan un horario de sueño. Después de esto, STA duerme mayoritariamente y ocasionalmente enciende WUR para escuchar "¿Ha llegado algo útil para mí?" Y sólo si es necesario, activa el módulo de radio principal para el intercambio de tráfico.
La situación cambia radicalmente en comparación con TWT y U-APSD, ¿no es así?
Y ahora un matiz importante en el que no piensas de inmediato. La WUR no tiene que funcionar a la misma frecuencia que el módulo principal. Al contrario, es deseable y recomendable que funcione en otro canal. En este caso, la funcionalidad 802.11ba no interfiere de ninguna manera con el funcionamiento de la red y, por el contrario, puede utilizarse para enviar información útil. Ubicación, lista de vecinos y mucho más dentro de otros estándares 802.11, por ejemplo 802.11k/v. Y qué ventajas se abren para las redes Mesh... Pero este es el tema de un artículo aparte.
En cuanto al destino de la propia norma como documento, entonces . Es decir, este año podemos esperar un estándar real o al menos las primeras implementaciones. Sólo el tiempo dirá qué tan extendido estará.
Cosas así... (c) .
Lectura recomendada:
Fuente: habr.com