{"id":70827,"date":"2020-02-21T14:42:12","date_gmt":"2020-02-21T11:42:12","guid":{"rendered":"https:\/\/prohoster.info\/blog\/802-11ba-wur-ili-kak-skrestit-uzha-s-ezhom"},"modified":"2020-03-03T16:14:44","modified_gmt":"2020-03-03T13:14:44","slug":"802-11ba-wur-ili-kak-skrestit-uzha-s-ezhom","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/802-11ba-wur-ili-kak-skrestit-uzha-s-ezhom","title":{"rendered":"802.11ba (WUR) ou como cruzar uma cobrinha com um ouri\u00e7o","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

N\u00e3o faz muito tempo, em v\u00e1rios outros recursos e no meu blog, eu disse que o ZigBee est\u00e1 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, \u00e9 suficiente um Bluetooth (LE) mais adequado para isso. Mas sobre isso eu falarei em outra ocasi\u00e3o. Hoje, o assunto \u00e9 como o grupo de trabalho do comit\u00ea se aprofundou e pensou duas vezes ap\u00f3s o 802.11ah, decidindo que era hora de adicionar ao conjunto de padr\u00f5es 802.11 uma vers\u00e3o completa de algo como LRLP (Long-Range Low-Power), em analogia ao LoRA. Mas isso se revelou invi\u00e1vel sem sacrificar a sagrada vaca da retrocompatibilidade. No final, desistiram do Long-Range e ficou apenas o Low-Power, o que tamb\u00e9m \u00e9 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\u00e3o \u00e9 um concorrente das solu\u00e7\u00f5es LoraWAN, mas sim criada para complement\u00e1-las.
\n<\/a><\/noindex>
\nEnt\u00e3o, vamos come\u00e7ar pelo mais importante \u2014 agora, dispositivos compat\u00edveis com 802.11ba devem ter dois m\u00f3dulos de r\u00e1dio. Aparentemente, ap\u00f3s observar o 802.11ah\/ax com sua tecnologia Target Wake Time (TWT), os engenheiros decidiram que isso n\u00e3o era suficiente e que era necess\u00e1rio reduzir radicalmente o consumo de energia. Para isso, o padr\u00e3o prev\u00ea a divis\u00e3o em dois tipos diferentes de r\u00e1dio \u2014 R\u00e1dio de Comunica\u00e7\u00e3o Prim\u00e1ria (PCR) e R\u00e1dio de Despertar (WUR). Se o primeiro est\u00e1 claro, sendo o r\u00e1dio principal que envia e recebe dados, o segundo n\u00e3o \u00e9 t\u00e3o simples. Na verdade, o WUR \u00e9, em grande parte, um dispositivo de escuta (RX) e deve consumir muito pouca energia para funcionar. Sua principal tarefa \u00e9 receber um sinal de despertar do AP e ativar o PCR. Ou seja, esse m\u00e9todo reduz significativamente o tempo de inicializa\u00e7\u00e3o a frio e permite que os dispositivos sejam despertados em momentos espec\u00edficos com m\u00e1xima precis\u00e3o. Isso \u00e9 muito \u00fatil quando, digamos, voc\u00ea tem n\u00e3o dez dispositivos, mas cento e dez e precisa trocar dados rapidamente com cada um deles. Al\u00e9m disso, a l\u00f3gica de frequ\u00eancia e periodicidade de despertamento \u00e9 transferida para o AP. Se, por exemplo, no LoRAWAN a metodologia \u00e9 de PUSH, onde os dispositivos executores despertam por conta pr\u00f3pria e transmitem algo no ar, enquanto o resto do tempo dormem, neste caso \u00e9 o contr\u00e1rio; o AP decide quando e qual dispositivo deve despertar, e os pr\u00f3prios dispositivos executores... nem sempre dormem.<\/p>\n

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 \u00e9 projetado para as faixas de 2.4GHz e 5GHz. Nos padr\u00f5es 'novos' anteriores, a compatibilidade era alcan\u00e7ada atrav\u00e9s de um cabe\u00e7alho compreens\u00edvel para dispositivos mais antigos. Ou seja, a expectativa sempre foi que os dispositivos antigos n\u00e3o precisassem ser capazes de reconhecer todo o quadro; bastava entender quando esse quadro come\u00e7aria e quanto tempo duraria a transmiss\u00e3o. Esta informa\u00e7\u00e3o \u00e9 o que eles extraem do cabe\u00e7alho. O 802.11ba n\u00e3o foi uma exce\u00e7\u00e3o, j\u00e1 que esse esquema \u00e9 testado e comprovado (vamos deixar de lado por enquanto a quest\u00e3o dos custos).<\/p>\n

Assim, o quadro 802.11ba se parece com isso:<\/p>\n

\"802.11ba
\n
\nA pr\u00e9-ampla Non-HT e um pequeno fragmento OFDM com modula\u00e7\u00e3o BPSK permite que todos os dispositivos 802.11a\/g\/n\/ac\/ax ou\u00e7am o in\u00edcio da transmiss\u00e3o desse quadro e n\u00e3o interfiram, entrando no modo de escuta. Ap\u00f3s a pr\u00e9-ampla, segue um campo de sincroniza\u00e7\u00e3o (SYNC), que na ess\u00eancia \u00e9 an\u00e1logo ao L-STF\/L-LTF. Ele serve para permitir o ajuste da frequ\u00eancia e a sincroniza\u00e7\u00e3o do receptor do dispositivo. E \u00e9 exatamente nesse momento que o dispositivo transmissor muda para uma largura de canal diferente de 4 MHz. Por qu\u00ea? \u00c9 muito simples. Isso \u00e9 necess\u00e1rio para que seja poss\u00edvel reduzir a pot\u00eancia e alcan\u00e7ar uma rela\u00e7\u00e3o sinal-ru\u00eddo (SINR) compar\u00e1vel. Ou deixar a pot\u00eancia como est\u00e1 e conseguir um aumento significativo no alcance da transmiss\u00e3o. Eu diria que essa \u00e9 uma solu\u00e7\u00e3o bastante elegante, al\u00e9m de permitir uma redu\u00e7\u00e3o significativa nas exig\u00eancias de fontes de energia. Vamos lembrar, por exemplo, do popular ESP8266. No modo de transmiss\u00e3o usando uma taxa de bits de 54 Mbps e pot\u00eancia de 16dBm, ele consome 196 mA, o que \u00e9 excessivo para algo como uma CR2032. Se diminuirmos a largura do canal em cinco vezes e reduzirmos a pot\u00eancia do transmissor em cinco vezes, praticamente n\u00e3o perderemos no alcance da transmiss\u00e3o, mas a corrente consumida ser\u00e1 reduzida para cerca de 50 mA. N\u00e3o que isso seja cr\u00edtico do lado do AP que transmite o quadro para WUR, mas ainda assim \u00e9 bom. J\u00e1 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. \u00c9 claro que nada \u00e9 de gra\u00e7a, e a redu\u00e7\u00e3o da largura do canal levar\u00e1 a uma diminui\u00e7\u00e3o na velocidade do canal, aumentando o tempo de transmiss\u00e3o de um quadro, respectivamente. <\/p>\n

A prop\u00f3sito, sobre a velocidade do canal. O padr\u00e3o na sua forma atual prev\u00ea duas op\u00e7\u00f5es, 62.5 Kbps e 250 Kbps. Voc\u00ea sente o cheiro de ZigBee? N\u00e3o \u00e9 \u00e0 toa, pois ele tem uma largura de canal de 2 MHz em vez de 4 MHz, mas com um tipo diferente de modula\u00e7\u00e3o com maior densidade espectral. No final, o alcance dos dispositivos 802.11ba deve ser maior, o que \u00e9 bastante interessante para cen\u00e1rios IoT em ambientes fechados.<\/p>\n

Mas espere um momento... Fazer todas as esta\u00e7\u00f5es da regi\u00e3o ficarem em sil\u00eancio, usando apenas 4 MHz da largura de banda de 20 MHz... \"\u00c9 UM ABSURDO!\" \u2014 voc\u00ea dir\u00e1, e estar\u00e1 certo. Mas n\u00e3o, ISSO \u00c9 QUE \u00c9 UM VERDADEIRO ABSURDO!<\/p>\n

\"802.11ba
\n
\nO padr\u00e3o permite a utiliza\u00e7\u00e3o 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\u00e3o, um Padding \u00e9 adicionado ao final do quadro. Ou seja, o dispositivo pode ocupar o tempo de transmiss\u00e3o em todos os 80 MHz, mas usar apenas 16 MHz. Isso j\u00e1 \u00e9 um verdadeiro desperd\u00edcio.<\/p>\n

A prop\u00f3sito, os dispositivos Wi-Fi ao redor n\u00e3o t\u00eam nenhuma chance de entender o que est\u00e1 sendo transmitido no ar. Porque para codificar os quadros 802.11ba N\u00c3O \u00e9 utilizado o OFDM que eles conhecem. Pois \u00e9, assim de forma surpreendente a alian\u00e7a abriu m\u00e3o do que funcionou sem falhas por muitos anos. Em vez do cl\u00e1ssico OFDM, \u00e9 utilizada a modula\u00e7\u00e3o Multi-Carrier (MC)-OOK. O canal de 4MHz \u00e9 dividido em 16(?) subportadoras, cada uma das quais utiliza codifica\u00e7\u00e3o Manchester. Al\u00e9m disso, o pr\u00f3prio campo DATA \u00e9 logicamente dividido em segmentos de 4 \u03bcs ou 2 \u03bcs, dependendo da taxa de bits, e em cada segmento, o n\u00edvel de codifica\u00e7\u00e3o pode ser alto ou baixo. Essa \u00e9 uma solu\u00e7\u00e3o para evitar longas sequ\u00eancias de zeros ou uns. O scrambling no m\u00ednimo.<\/p>\n

\"802.11ba
\n
\nO n\u00edvel MAC tamb\u00e9m foi absurdamente simplificado. Ele cont\u00e9m apenas os seguintes campos:<\/p>\n