Não faz muito tempo, em vários outros recursos e no meu blog, eu disse que o ZigBee está morto e que era hora de enterrar de vez. Para fazer uma boa figura em meio a um jogo ruim com o Thread, que funciona sobre IPv6 e 6LowPan, é suficiente um Bluetooth (LE) mais adequado para isso. Mas sobre isso eu falarei em outra ocasião. Hoje, o assunto é como o grupo de trabalho do comitê se aprofundou e pensou duas vezes após o 802.11ah, decidindo que era hora de adicionar ao conjunto de padrões 802.11 uma versão completa de algo como LRLP (Long-Range Low-Power), em analogia ao LoRA. Mas isso se revelou inviável sem sacrificar a sagrada vaca da retrocompatibilidade. No final, desistiram do Long-Range e ficou apenas o Low-Power, o que também é bastante bom. Assim, temos uma mistura de 802.11 + 802.15.4, ou simplesmente Wi-Fi + ZigBee. Ou seja, pode-se dizer que a nova tecnologia não é um concorrente das soluções LoraWAN, mas sim criada para complementá-las.
Então, vamos começar pelo mais importante — agora, dispositivos compatíveis com 802.11ba devem ter dois módulos de rádio. Aparentemente, após observar o 802.11ah/ax com sua tecnologia Target Wake Time (TWT), os engenheiros decidiram que isso não era suficiente e que era necessário reduzir radicalmente o consumo de energia. Para isso, o padrão prevê a divisão em dois tipos diferentes de rádio — Rádio de Comunicação Primária (PCR) e Rádio de Despertar (WUR). Se o primeiro está claro, sendo o rádio principal que envia e recebe dados, o segundo não é tão simples. Na verdade, o WUR é, em grande parte, um dispositivo de escuta (RX) e deve consumir muito pouca energia para funcionar. Sua principal tarefa é receber um sinal de despertar do AP e ativar o PCR. Ou seja, esse método reduz significativamente o tempo de inicialização a frio e permite que os dispositivos sejam despertados em momentos específicos com máxima precisão. Isso é muito útil quando, digamos, você tem não dez dispositivos, mas cento e dez e precisa trocar dados rapidamente com cada um deles. Além disso, a lógica de frequência e periodicidade de despertamento é transferida para o AP. Se, por exemplo, no LoRAWAN a metodologia é de PUSH, onde os dispositivos executores despertam por conta própria e transmitem algo no ar, enquanto o resto do tempo dormem, neste caso é o contrário; o AP decide quando e qual dispositivo deve despertar, e os próprios dispositivos executores... nem sempre dormem.
Agora vamos falar sobre os formatos de quadros e a garantia de compatibilidade. Se o 802.11ah, como uma primeira tentativa, foi criado para as faixas de 868/915 MHz ou simplesmente SUB-1GHz, o 802.11ba é projetado para as faixas de 2.4GHz e 5GHz. Nos padrões 'novos' anteriores, a compatibilidade era alcançada através de um cabeçalho compreensível para dispositivos mais antigos. Ou seja, a expectativa sempre foi que os dispositivos antigos não precisassem ser capazes de reconhecer todo o quadro; bastava entender quando esse quadro começaria e quanto tempo duraria a transmissão. Esta informação é o que eles extraem do cabeçalho. O 802.11ba não foi uma exceção, já que esse esquema é testado e comprovado (vamos deixar de lado por enquanto a questão dos custos).
Assim, o quadro 802.11ba se parece com isso:
A pré-ampla Non-HT e um pequeno fragmento OFDM com modulação BPSK permite que todos os dispositivos 802.11a/g/n/ac/ax ouçam o início da transmissão desse quadro e não interfiram, entrando no modo de escuta. Após a pré-ampla, segue um campo de sincronização (SYNC), que na essência é análogo ao L-STF/L-LTF. Ele serve para permitir o ajuste da frequência e a sincronização do receptor do dispositivo. E é exatamente nesse momento que o dispositivo transmissor muda para uma largura de canal diferente de 4 MHz. Por quê? É muito simples. Isso é necessário para que seja possível reduzir a potência e alcançar uma relação sinal-ruído (SINR) comparável. Ou deixar a potência como está e conseguir um aumento significativo no alcance da transmissão. Eu diria que essa é uma solução bastante elegante, além de permitir uma redução significativa nas exigências de fontes de energia. Vamos lembrar, por exemplo, do popular ESP8266. No modo de transmissão usando uma taxa de bits de 54 Mbps e potência de 16dBm, ele consome 196 mA, o que é excessivo para algo como uma CR2032. Se diminuirmos a largura do canal em cinco vezes e reduzirmos a potência do transmissor em cinco vezes, praticamente não perderemos no alcance da transmissão, mas a corrente consumida será reduzida para cerca de 50 mA. Não que isso seja crítico do lado do AP que transmite o quadro para WUR, mas ainda assim é bom. Já para o STA, isso realmente faz sentido, pois um consumo mais baixo permite usar algo como uma CR2032 ou baterias projetadas para armazenamento de energia prolongado com baixas correntes de descarga. É claro que nada é de graça, e a redução da largura do canal levará a uma diminuição na velocidade do canal, aumentando o tempo de transmissão de um quadro, respectivamente.
A propósito, sobre a velocidade do canal. O padrão na sua forma atual prevê duas opções, 62.5 Kbps e 250 Kbps. Você sente o cheiro de ZigBee? Não é à toa, pois ele tem uma largura de canal de 2 MHz em vez de 4 MHz, mas com um tipo diferente de modulação com maior densidade espectral. No final, o alcance dos dispositivos 802.11ba deve ser maior, o que é bastante interessante para cenários IoT em ambientes fechados.
Mas espere um momento... Fazer todas as estações da região ficarem em silêncio, usando apenas 4 MHz da largura de banda de 20 MHz... "É UM ABSURDO!" — você dirá, e estará certo. Mas não, ISSO É QUE É UM VERDADEIRO ABSURDO!
O padrão permite a utilização de subcanais de 40 MHz e 80 MHz. Neste caso, as taxas de bits de cada subcanal podem ser diferentes, e para que coincidam no tempo de transmissão, um Padding é adicionado ao final do quadro. Ou seja, o dispositivo pode ocupar o tempo de transmissão em todos os 80 MHz, mas usar apenas 16 MHz. Isso já é um verdadeiro desperdício.
A propósito, os dispositivos Wi-Fi ao redor não têm nenhuma chance de entender o que está sendo transmitido no ar. Porque para codificar os quadros 802.11ba NÃO é utilizado o OFDM que eles conhecem. Pois é, assim de forma surpreendente a aliança abriu mão do que funcionou sem falhas por muitos anos. Em vez do clássico OFDM, é utilizada a modulação Multi-Carrier (MC)-OOK. O canal de 4MHz é dividido em 16(?) subportadoras, cada uma das quais utiliza codificação Manchester. Além disso, o próprio campo DATA é logicamente dividido em segmentos de 4 μs ou 2 μs, dependendo da taxa de bits, e em cada segmento, o nível de codificação pode ser alto ou baixo. Essa é uma solução para evitar longas sequências de zeros ou uns. O scrambling no mínimo.
O nível MAC também foi absurdamente simplificado. Ele contém apenas os seguintes campos:
- Controle de Quadro
Pode assumir os valores Beacon, WuP, Discovery ou qualquer outra escolha do fornecedor.
Beacon serve para sincronização de tempo, WuP é destinado a despertar um ou um grupo de dispositivos, enquanto Discovery funciona na direção oposta, de STA para AP, e foi criado para encontrar pontos de acesso que suportam 802.11ba. Este campo também transmite o comprimento do quadro se ele exceder 48 bits. - ID
Dependendo do tipo de quadro, pode identificar AP, ou STA, ou um grupo de STA ao qual este quadro se destina. (Sim, é possível acordar dispositivos em grupos, isso é chamado de groupcast wake-ups e é bastante interessante).
- Tipo Dependente (TD)
Um campo bastante flexível. É nele que pode ser transmitido o tempo exato, um sinal de atualização de firmware/configuração com número de versão ou algo útil que a STA deve saber.
- Campo de Verificação de Quadro (FCS)
Aqui é tudo simples. Esta é a soma de verificação.
Mas para que a tecnologia funcione, não adianta apenas enviar um quadro no formato correto. O STA e o AP precisam entrar em acordo. O STA informa seus parâmetros, incluindo o tempo necessário para inicializar o PCR. Todo o ajuste ocorre utilizando quadros 802.11 comuns, após o que o STA pode desligar o PCR e entrar no modo de ativação WUR. E pode até dormir um pouco, se houver essa possibilidade. Porque se houver, é melhor aproveitá-la.
A seguir, começa uma pequena extração dos preciosos miliamperes-hora chamada WUR Duty Cycle. Não há nada de complicado, apenas o STA e o AP, semelhantemente ao que foi feito para o TWT, concordam em um cronograma de sono. Depois disso, o STA dorme principalmente, ligando o WUR de tempos em tempos para ouvir: 'Não chegou nada útil para mim?'. E somente quando necessário, desperta o módulo de rádio principal para a troca de tráfego.
Muda radicalmente a situação em comparação ao TWT e U-APSD, não é mesmo?
E agora uma importante nuance sobre a qual nem sempre pensamos de imediato. O WUR não precisa necessariamente operar na mesma frequência que o módulo principal. Pelo contrário, é preferível e recomendado que opere em um canal diferente. Nesse caso, a funcionalidade 802.11ba não interfere de forma alguma no funcionamento da rede e, ao contrário, pode ser utilizada para a disseminação de informações úteis. Localização, Lista de Vizinhos e muito mais dentro de outros padrões 802.11, como 802.11k/v. E quais vantagens se abrem para redes Mesh... Mas esse é o tema de um artigo separado.
Quanto ao futuro do próprio padrão como documento, . Ou seja, este ano podemos esperar um verdadeiro padrão ou pelo menos as primeiras implementações. E o quanto ele se disseminará — isso só o tempo dirá.
Essas são as notícias... (c) .
Literatura recomendada para leitura:
Fonte: habr.com
