Não faz muito tempo, em vários outros recursos e no meu blog, falei sobre o fato de ZigBee estar morto e é hora de enterrar o comissário de bordo. Para dar uma cara boa a um jogo ruim com Thread funcionando em cima de IPv6 e 6LowPan, basta o Bluetooth (LE) mais adequado para isso. Mas falarei sobre isso em outra ocasião. Hoje falaremos sobre como o grupo de trabalho do comitê decidiu pensar duas vezes após 802.11ah e decidiu que era hora de adicionar uma versão completa de algo como LRLP (Long-Range Low-Power) ao conjunto de padrões 802.11, semelhante para LoRA. Mas isto revelou-se impossível de implementar sem abater a vaca sagrada da retrocompatibilidade. Como resultado, o Long-Range foi abandonado e apenas o Low-Power permaneceu, o que também é muito bom. O resultado foi uma mistura de 802.11 + 802.15.4, ou simplesmente Wi-Fi + ZigBee. Ou seja, podemos dizer que a nova tecnologia não é concorrente das soluções LoraWAN, mas, pelo contrário, está a ser criada para complementá-las.
Então, vamos começar com o mais importante: agora os dispositivos que suportam 802.11ba devem ter dois módulos de rádio. Aparentemente, depois de analisarem o 802.11ah/ax com a sua tecnologia Target Wake Time (TWT), os engenheiros decidiram que isto não era suficiente e que precisavam de reduzir radicalmente o consumo de energia. Por que o padrão prevê uma divisão em dois tipos diferentes de rádio - Rádio de Comunicação Primária (PCR) e Rádio de Despertar (WUR). Se com o primeiro está tudo claro, este é o rádio principal, ele transmite e recebe dados, então com o segundo não é tanto. Na verdade, o WUR é principalmente um dispositivo de escuta (RX) e foi projetado para consumir muito pouca energia para funcionar. Sua principal tarefa é receber um sinal de despertar do AP e habilitar o PCR. Ou seja, este método reduz significativamente o tempo de inicialização a frio e permite ativar dispositivos em um determinado horário com a máxima precisão. Isso é muito útil quando você tem, digamos, não dez dispositivos, mas cento e dez e precisa trocar dados com cada um deles em um curto período de tempo. Além disso, a lógica da frequência e periodicidade do despertar passa para o lado AP. Se, digamos, LoRAWAN usa a metodologia PUSH quando os próprios atuadores acordam e transmitem algo no ar, e dormem o resto do tempo, então neste caso, ao contrário, o AP decide quando e qual dispositivo deve acordar, e os próprios atuadores... nem sempre dormem.
Agora vamos passar para os formatos e compatibilidade dos quadros. Se o 802.11ah, como primeira tentativa, foi criado para as bandas de 868/915 MHz ou simplesmente SUB-1GHz, então o 802.11ba já está destinado às bandas de 2.4 GHz e 5 GHz. Nos "novos" padrões anteriores, a compatibilidade era alcançada por meio de um preâmbulo que era compreensível para dispositivos mais antigos. Ou seja, o cálculo sempre foi de que dispositivos mais antigos não precisam necessariamente ser capazes de reconhecer todo o quadro, basta que eles entendam quando esse quadro irá começar e quanto tempo durará a transmissão. É essa informação que eles extraem do preâmbulo. O 802.11ba não foi exceção, já que o esquema está comprovado e comprovado (ignoraremos a questão dos custos por enquanto).
Como resultado, o quadro 802.11ba se parece com isto:
Um preâmbulo não HT e um pequeno fragmento OFDM com modulação BPSK permitem que todos os dispositivos 802.11a/g/n/ac/ax ouçam o início da transmissão deste quadro e não interfiram, entrando no modo de escuta de transmissão. Após o preâmbulo vem o campo de sincronização (SYNC), que é essencialmente um análogo de L-STF/L-LTF. Serve para possibilitar o ajuste da frequência e a sincronização do receptor do aparelho. E é nesse momento que o dispositivo transmissor muda para outro canal com largura de 4 MHz. Para que? Tudo é muito simples. Isto é necessário para que a potência possa ser reduzida e uma relação sinal-ruído comparável (SINR) possa ser alcançada. Ou deixe a potência como está e consiga um aumento significativo no alcance de transmissão. Eu diria que esta é uma solução muito elegante, que também permite reduzir significativamente os requisitos de fontes de alimentação. Lembremos, por exemplo, do popular ESP8266. No modo de transmissão usando taxa de bits de 54 Mbps e potência de 16dBm, ele consome 196 mA, o que é proibitivamente alto para algo como o CR2032. Se reduzirmos a largura do canal em cinco vezes e reduzirmos a potência do transmissor em cinco vezes, praticamente não perderemos o alcance de transmissão, mas o consumo de corrente será reduzido em um fator de, digamos, cerca de 50 mA. Não que isso seja crítico por parte do AP que transmite o quadro para o WUR, mas ainda assim não é ruim. Mas para o STA isto já faz sentido, uma vez que o menor consumo permite a utilização de algo como CR2032 ou baterias concebidas para armazenamento de energia a longo prazo com baixas correntes de descarga nominais. É claro que nada vem de graça e a redução da largura do canal levará a uma diminuição na velocidade do canal com um aumento no tempo de transmissão de um quadro, respectivamente.
A propósito, sobre a velocidade do canal. O padrão em sua forma atual oferece duas opções: 62.5 Kbps e 250 Kbps. Você sente o cheiro do ZigBee? Isso não é fácil, pois possui largura de canal de 2Mhz em vez de 4Mhz, mas um tipo diferente de modulação com maior densidade espectral. Como resultado, o alcance dos dispositivos 802.11ba deve ser maior, o que é muito útil para cenários de IoT internos.
Porém, espere um minuto... Forçar todas as estações da área a ficarem silenciosas, usando apenas 4 MHz da banda de 20 MHz... “ISSO É UM DESPERDÍCIO!” - você dirá e terá razão. Mas não, ESSE É O VERDADEIRO DESPERDÍCIO!
O padrão oferece a capacidade de usar subcanais de 40 MHz e 80 MHz. Neste caso, as taxas de bits de cada subcanal podem ser diferentes e, para corresponder ao tempo de transmissão, é adicionado preenchimento ao final do quadro. Ou seja, o aparelho pode ocupar tempo de antena em todos os 80 MHz, mas utilizá-lo apenas em 16 MHz. Isso é um verdadeiro desperdício.
A propósito, os dispositivos Wi-Fi próximos não têm chance de entender o que está sendo transmitido ali. Porque o OFDM normal NÃO é usado para codificar quadros 802.11ba. Sim, sem mais nem menos, a aliança abandonou o que funcionou perfeitamente durante muitos anos. Em vez do OFDM clássico, é usada a modulação Multi-Carrier (MC)-OOK. O canal de 4MHz é dividido em 16(?) subportadoras, cada uma das quais usa codificação Manchester. Ao mesmo tempo, o próprio campo DATA também é logicamente dividido em segmentos de 4 μs ou 2 μs, dependendo da taxa de bits, e em cada segmento um nível de codificação baixo ou alto pode corresponder a um. Esta é a solução para evitar uma longa sequência de zeros ou uns. Lutando por salários mínimos.
O nível MAC também é extremamente simplificado. Ele contém apenas os seguintes campos:
- Controle de quadro
Podendo levar os valores Beacon, WuP, Discovery ou qualquer outro valor à escolha do fornecedor.
O Beacon é usado para sincronização de horário, o WuP é projetado para ativar um ou um grupo de dispositivos e o Discovery funciona na direção oposta de STA para AP e é projetado para encontrar pontos de acesso que suportem 802.11ba. Este campo também contém o comprimento do quadro se exceder 48 bits. - ID
Dependendo do tipo de quadro, pode identificar um AP, ou uma STA, ou um grupo de STAs ao qual este quadro se destina. (Sim, você pode ativar dispositivos em grupos, é chamado de ativação de groupcast e é muito legal).
- Dependente de Tipo (TD)
Um campo bastante flexível. É nele que pode ser transmitida a hora exata, um sinal sobre uma atualização de firmware/configuração com um número de versão, ou algo útil que o STA deva conhecer.
- Campo de soma de verificação de quadro (FCS)
Tudo é simples aqui. Esta é uma soma de verificação
Mas para que a tecnologia funcione não basta simplesmente enviar um quadro no formato desejado. O STA e o AP devem concordar. O STA reporta seus parâmetros, incluindo o tempo necessário para inicializar o PCR. Toda a negociação ocorre usando quadros 802.11 regulares, após os quais a STA pode desabilitar o PCR e entrar no modo de habilitação do WUR. Ou talvez até durma um pouco, se possível. Porque se existe, então é melhor usá-lo.
Em seguida, vem um pouco mais de compressão de preciosas horas em miliamperes, chamada WUR Duty Cycle. Não há nada complicado, apenas STA e AP, por analogia com o TWT, concordam com o horário de sono. Depois disso, o STA dorme principalmente, ocasionalmente ligando o WUR para ouvir “Chegou alguma coisa útil para mim?” E somente se necessário, ativa o módulo de rádio principal para troca de tráfego.
Muda radicalmente a situação em relação ao TWT e ao U-APSD, não é?
E agora uma nuance importante na qual você não pensa imediatamente. O WUR não precisa operar na mesma frequência do módulo principal. Pelo contrário, é desejável e recomendado que funcione num canal diferente. Neste caso, a funcionalidade 802.11ba não interfere de forma alguma no funcionamento da rede e, pelo contrário, pode ser utilizada para enviar informações úteis. Localização, Lista de Vizinhos e muito mais dentro de outros padrões 802.11, por exemplo 802.11k/v. E quais vantagens se abrem para Redes Mesh... Mas este é o tema de um artigo separado.
Quanto ao destino da própria norma como documento, então . Ou seja, este ano podemos esperar um verdadeiro padrão ou pelo menos as primeiras implementações. Só o tempo dirá quão difundido será.
Essas coisas... (c) .
Leitura recomendada:
Fonte: habr.com