Toda a transação ao redor do envio de um pacote torre>cliente é feito em MCS4 se setar assim.
Se o datarate é fixo há algo tipo um request-to-send em MCS4, o cliente manda um clear-to-send em MCS4, e há mais pre-estabelecimentos de comunicação feitos por ambos os lados em MCS4 afinal quem requisitou essa troca de dados foi a torre.
Se o datarate, potencia ou ack-timeout é automatico a maioria dos firmwares manda um tipo de packet-probe que ajuda na analise de qualidade pra definir se vai aumentar ou reduzir algo, são nanosegundos gastos com essas trocas.
Esse pacote hipotético é um pacote TCP/IP comum, ele saiu do linux no AP da torre e ele precisa um checksum (Ou algo do tipo), esse ckecksum que o linux da CPE precisa enviar já é outro pacote, ele será iniciado pelo linux da CPE, a wlan da CPE vai fazer automaticamente a transação, se ela está configurada pra MCS1 tudo ao redor desse mísero checksum ou simples "OK" pro pacote anterior será feito em MCS1 pelos 2 lados.
No fim das contas todo o download é feito em MCS4, e todo o upload é feito em MCS1. As respostas de pacotes que são resposta SO <> SO são feitas como se fosse download ou upload, elas é que tomam muito tempo de conexão, as respostas pra estabelecer comunicação não perdem quase nada de tempo, são poucos nanosegundos.
(Por isso nunca sugiro algo agressivo tipo -70dBm pra MCS15, em PTP isola até dá as vezes, mas em PTMP isso ia gerar muita perda de pacote nesse ato de responder cada conexão estabelecida)
Que teria muita vantagem em usar um datarate lindo tipo MCS15 nos 2 lados isso teria!
Tudo fixo em MCS15 seria perfeito, rede perfeita igual rede cabeada.
Mas olha o nível de sinal e de limpeza da zona de fresnel que ia precisar!
Em ambiente poluído o SNR necessário pode ser esse absurdo aqui:
Anexo 59425
Segundo o livro isso é pra ser analise do SNR em cada pacote, e abaixo uma aferição chamada "efetiva" de SNR levando em conta não o ruído geral no ambiente mas sim o que tem potencial pra atrapalhar o sinal depois do conversor analogico>digital (Que dizer, um transmissor FM a 100MHz, com harmonicas a 100, 200, 400, 800MHz, 1600 e 3200MHz, não deve incomodar, o ADC não vai converter isso).
O problema é: Você vê um ruído indicado em -96dBm, mas o PTP passa pouca banda. Você troca de canal, noutro canal onde também é exibido -96dBm de ruído, mas o PTP fica bom. Analisa bem, e o que tem no canal antigo? Um monte de SSID. Oras, mas SSID não é ruído, canal ocupado com outros sinais não é ruído, então apenas levar em conta o SNR não adianta, e ter um método supostamente "efetivo" ajuda menos ainda, SE usassem um método de SNR por pacote a gente veria ruído variando ora em -80, ora em -116dBm, talvez confundiria uns usuários, mas seria mais realista, perturbação não é um chiado de fundo, é o uso do canal com outros dados, esse uso varia mesmo, hora tem mais pacotes ou menos pacotes sendo trocados na vizinhança.
Ó uma suposta tomada em tempo-real do SNR:
Anexo 59426
Então como não dá pra confiar em SNR (Ou melhor, dá pra confiar, mas dá muuuuuuito trabalho, alterando datarate toda hora, exigiria muito processamento), nem em RSSI (Uma melhoria do SNR), os sistema de escolha de datarate nos chipsets não leva em conta isso, mas sim são sistemas baseados em perdas de pacotes.
São tipo auto rate fallback (Velho), adaptative auto rate fallback (Mais conservador nas tentativas de subir datarate), e um sistema de auto-rate baseado no receptor, onde o receptor informa AUMENTANDO/FUÇANDO no pacote original acrescentando dados sobre a qualidade da conexão anterior, e um algoritmo de adaptação de rate que é pra ser robusto, RRAA, que anda sendo muito usado.
Nesse algoritmo há o uso ou não de RTS/CTS (Conforme necessidade), há o uso de estimativa de perda futura (Já envia 2x antes mesmo do cliente avisar que não recebeu pacote, porque notou alteração em ruído, e... sabe que o ruído na torre pode ser de outra fonte com relação ao ruído no cliente!), e o melhor, ele usa apenas 1 frame pra fazer o packet probe a cada conexão, ele não manda um packet probe embutido ou a cada troca de dados. A princípio se suspeita que o algoritmo "Alternative" da UBNT seja esse.
(Enquanto o uso de AMPDU na MK diz que ela usa o sistema de auto-rate baseado no receptor, agregando dados no MPDU)
Esse algoritmos de tomadas de decisões são tudo software, o software diz o que vai pra camada mac e o hardware da wlan (phy) transmite e dá um feedback pro software informando tempo de respostas ou algo assim. O problema é que o software usa processamento pra pegar esse dado, analisar estimativa de perdas futuras e definir se vai ou não trocar o datarate. Quando o chipset está sobrecarregado ele fica lerdo nisso (Está compartilhando CPU com outros funções) e gera CCQ baixo e cia porque não está conseguindo analisar e trocar rates de forma rápida ou bem pensada (O software faz burrice porque o hardware fica lerdo).
Alias, tem mais uma hoje, como é sabido que muito hardware vagabundo é usado como AP em PtMP, e hardware vagabundo as vezes perde pacote porque a CPU está sobrecarregada, existe o modo de operação que CASO haja perda de pacote o próximo pacote só é enviado depois de um RTS respondido com um CTS. A intenção é: Se perdeu pacote é porque a CPU está lotada, pra não perder transmissão denovo vamos primeiro perguntar se podemos transmitir. Se esse pacote (Depois do RTS e CTS) for ok, aí os próximos pacotes são transmitidos sem RTS/CTS (Até que se perca algum denovo), o problema desse modo inteligente é: Ao invez de reduzir o datarate, o sistema insiste em datarate alto porque não sabe se a perda do pacote foi por sinal baixo ou por CPU hiperlotada, mas... sabemos que o ruído varia (SNR idem), algo comum é 1 pacote com RTS/CTS, 1 sem e perdido, 1 com RTS/CTS, 1 sem e perdido, e assim vai. Situação em que praticamente só há troca segura usando RTS/CTS. Como o pacote com RTS/CTS não é perdido nunca (Porque a contraparte da comunicação para a outras trocas de dados pra ouvir só 1 cliente) o software não experimenta baixar o datarate (Pra algum que tenha SNR melhor, e não precise RTS/CTS).
(Acho que você já deve ter testado um RTS threshold baixo, pra que quase todo pacote passe pelo processo de pedido e autorização, as vezes funciona e ajuda, mas as vezes só consome mais processamento e o resultado prático é zero (Onde não há colisão não há motivo pra implantar algo pra evitar colisão, por isso não uso colete-a-prova-de-balas nem antivirus, são proteções pra problemas que eu não tenho))
Pode parecer bobeira um algoritmo ser enganado por perda de dados, mas não podemos ver por esse lado, temos que ver a complexidade de produzir um algoritmo inteligente o suficiente pra saber diferenciar quando o pacote foi perdido por SNR baixo, quando foi por CPU lerda, quando foi por colisão, etc.
Antigamente em tempos de 802.11a o algoritmo era burro de fazer isso:
Anexo 59427
O BER é o bit error rate, 10 elevado a -4 é 4 zeros com um 10 depois, ou 0,00010, ou 0,0001%, ou 1 erro a cada 1000.
10^-5 seria um zero a mais, 1 erro a cada 10 mil.
Qual o problema disso pra chamar de algoritmo burro? O problema é que o erro JÁ OCORREU! O algoritmo não viu que o SNR era de só 10dBm? Não viu, ele esperou ter X erros pra depois perceber que era um rate ruim e então trocar.
Hoje temos algo muito melhor, que "prevê" erros.
E essa melhoria não depende do "querer fazer", mas sim do conseguir. Nunca mechi com programação porque não consigo esquematizar algoritmos (Ou falta paciência pra praticar), mas sei das dificuldades de um algoritmo que leve em conta um contador de frames perdidos, um analisador de qualidade de link (SNR, nível de sinal), um analisador de throughput necessário (E esse existe, muito ptp e ptmp cai pra 6M quando não tem tráfego, o problema disso é a demora pra "subir" o datarate quando aparecer tráfego), a coisa boba tipo "Se o índice de erros está baixo pode subir o datarate" não é suficiente, porque trafegando pacotes de 30 bytes (status de rede apenas) você tem uma taxa de ocupação do espectro, hora que passa pra pacotes de 1500 bytes (navegação/download) a ocupação aumenta, se usar um algoritmo bobo o datarate vai ficar variando.
Enfim, o problema não é ser automático, o problema é o tempo perdido na definição de QUAL rate, potencia ou ack usar. Em ambiente urbano o problema são as outras redes wifi, hora que outra rede está parada o canal fica mais limpo e você pode subir o datarate, mas hora que outra rede começar a trocar dados aos montes o seu PTMP teria que reduzir o datarate pra perder menos pacotes (Senão vai ter que ficar reenviando pacotes, aumenta o ping ou diminui o throughput se não diminuir o datarate), mas essa troca automática é lerda, e... essa mudança na ocupação dos canais ou o ruído não ocorre 3x ao dia, ela ocorre 3x por segundo e as vezes 3x por minuto, pro AP fazer uma troca rápida ele precisaria sair disparando packets probe pra todo lado, pra todos os clientes responderem e ele então definir a troca do datarate, mas isso consome muito processamento (Que um AP com 40 clientes não tem).
O resumo da coisa é estar preparado pra eventuais ruídos e ocupações alheias de canal. Um datarate baixo e fixo, com margem de sinal decente, e SNR decente, permite isso, ping constante (Sem jitter), com todos os clientes equalizados, sem variação de throughput conforme a hora do dia (Mais gente usando wifi de dia que de madrugada).
Os padrões 802.11 da IEEE não padronizam algoritmo desse tipo, cada fabricante usa um, as vezes pode ocorrer de 2 AP's tomarem a MESMA decisão e ficarem se acotovelando por canais, então nem a troca automática de canais me agrada, até porque um canal pode estar com ruído nos clientes, mas estar limpo na torre, quem manda é a torre então pode ter rede ruim por bobeira.
Sobre ack-time e SNR, também entra a questão da visada e zona de fresnel, nenhum algoritmo consegue ver qualidade da conexão física, eles olham nível de sinal, e numa zona de fresnel parcial a reflexão varia o tempo todo, varia 3x por segundo igual ruído ou SNR, um pacote curto (Uma rajada curta) vibra o elemento da antena por X picosegundos e para, mas um pacote longo (Grande) ressona ela por mais tempo de modo que altera em 1º pra baixo a emissão, porque antena multi-elemento é comum e se o sinal chegar levemente atrasado nos elemetos de cima a irradiação desse elemento cria uma quase contra-fase que empura o lóbulo de irradiação pra baixo, existe mais chance de pacote grande refletir com ganho maior, fora que pacote grande ficar em transmissão e recepção por um período de tempo maior, nesse tempo o ruído pode aumentar 10dBm "do nada" (E por ruído entenda ocupação do canal por outro AP, não entra no noise floor mas é sinal que atrapalha o desempenho da etapa de RF, é mais dado pro ADC converter).
Alias, tema que quero ler faz tempo é sobre as alterações na velocidade das ondas conforme o ambiente. Diz a física que RF só viaja na velocidade da luz no vácuo, e conforme o material há uma queda na velocidade. Falando em luz visível, sei que em diamante a velocidade é praticamente 1/3 da velocidade no vácuo (300 mil Km/s), sei que existe atenuação de RF por chuva, umidade, temperatura, mas preciso ler sobre a possivel diminuição da velocidade em sí, algum tipo de refração deve existir, mas se a luz visível chega a perder 60% da velocidade, já pensou se RF tem alterações tipo 1% na velocidade? 1% de diferença pode perfeitamente cria uma perda de pacote em wifi, porque os tempos precisam ser bem precisos pro ADC separar direito (Wifi sofre muito com efeito doppler, isso se sabe). Se uma nuvem de poeira passando atras da torre atrapalha os clientes pra aquele lado, mas não os pro outro lado, isso só geraria ainda mais processamento pra CPU desse AP numa omni, ia ter bit error rate diferente conforme o lado, e nenhum algoritmo tem como descobrir que tipo de antena está em uso, um equipto que faz beamforming sim, mas beamforming anda cada vez mais esquisito na prática, MIMO tipo 2x3 ou 2x6 parece mais fácil de implantar do que beamforming, parece que precisa muito mais processamento pro mesmo resultado (throughput). Um sistema de beamforming sim ia poder usar um datarate por cliente de forma inteligente, mas os equiptos que fazem isso andam "um pouco caros".
(E quem mais financia o mercado me parece que é o comprado de roteador de mesa midle-end, roteador de R$ 150 a 500, que atendem usuários de poucos dispositivos mas que querem muita banda, por isso tanto AP vem por default com canal de 40MHz (E vai pra MCS7 mesmo que conecte um celular com sinal -80dBm!))
Pra mim que a UBNT tem algoritmos diferentes nos Rocket e nos Picostation (Unifi não pude usar mecher quase nada), acho que estão no caminho certo, WISP precisa outro tipo de approach na seleção de rates, precisa modo de seleção 100% diferente de conexão com dispositivo mobile. Infelizmente parece que gastam muito com modos proprietários (TDMA) ao invez de fazer como Cisco ou Arruba e focar $$$ totalmente em algoritmos cada vez mais inteligentes pra essas seleções, porque elas ainda são bem burrinhas, é fácil ver CCQ de 95-98% em ptmp com tudo automático, com throughput médio tipo 10Mbps por cliente, sendo que fixando tudo em datarate baixo o CCQ fixa em 100%, o throughput médio fica nos mesmos 10Mbps, mas o jitter nos pings some, porque o algoritmo não vai pelo "rate necessário", mas sim pelo "maior rate possível, pra enganar os trouxas que só olham pra rates nominais".