Para determinar se o algoritmo sugerido resolve ou atenua o problema dos nodos escon- didos, nos testes a realizar foi necessário simular esse problema e monitorizar os valores de retransmissões e erros. Para isso, foram usados dois computadores colocados no limite do alcance do sinal do ponto de acesso. Desta forma, consegue-se que ambos os computadores consigam estar ao alcance do ponto de acesso, mas não ao alcance um do outro. Para poder confirmar se a situação de nodos escondidos foi criada com sucesso, foi necessário introduzir tráfego na rede, pondo os dois computadores a descarregar um ficheiro de 700MB através um servidor FTP, instalado no mesmo computador que corre o programa de monitorização, esperando-se o aumento do número de retransmissões ou erros.
Nos primeiros testes verificou-se que a instância do objecto do tipo contador dot11FailedCount da MIB IEEE802dot11 incrementa quando um MSDU não é transmitido com sucesso e con- sequentemente, é necessária a retransmissão. Concluiu-se que o contador não é útil para o efeito desejado devido ao facto de apenas considerar as transmissões (do ponto de acesso para os clientes) e não as recepções (dos clientes para o ponto de acesso). O que realmente interessa são as retransmissões dos clientes, já que são os clientes que são os nodos escondidos e é neles que o número de retransmissões aumentaria. Verificou-se de facto, que os valores no gráfico da aplicação de monitorização não aumentaram muito significativamente quando era introduzida carga na rede. Provavelmente se fosse possível monitorizar por SNMP os clientes, seria possível observar um aumento significativo do número de retransmissões. Assim, para conseguir notar diferenças significativas tentou-se a monitorização do objecto dot11FCSErrorCount que contabiliza o número de erros FCS detectados. A ideia geral se- ria que o aumento do número de erros de processamento dos pacotes, traduzisse também
o aumento de colisões devido à existência de nodos escondidos. Com isto abandonou-se o algoritmo RoD-R que monitoriza as retransmissões e trabalhou-se apenas com o algoritmo RoD-E que monitoriza os erros.
As primeiras simulações de nodos escondidos foram efectuadas da seguinte forma: inici- almente, um dos computadores (PC1) foi colocado no limite do alcance do ponto de acesso, mas de forma a ainda ter sinal (30%) para poder descarregar o ficheiro do servidor FTP. O outro computador (PC2) foi colocado muito perto do ponto de acesso. Para melhor se perceber os gráficos apresentados, convém explicar o o processo sequencial:
1. Depois da preparação dos computadores, foi iniciado o programa de monitorização com um tamanho de janela suficientemente grande para poder capturar todo o proce- dimento.
2. Com o programa a correr, foi iniciada a transferência FTP no PC1. 3. Alguns segundos depois, foi iniciada a transferência FTP no PC2.
4. Alguns segundos depois, o PC2 foi levado para longe do ponto de acesso, quase até ao ponto de perder o sinal (30%).
5. Depois de dois a três minutos, o PC2 foi levado para junto do ponto de acesso nova- mente.
6. Aguardou-se alguns segundos e terminou-se o programa. Este procedimento foi repetido várias vezes.
Durante os testes, o intervalo entre consultas SNMP foi de cinco segundos. Em cada um dos gráficos estão presentes três linhas. A linha vermelha representa a média de erros FCS, a linha azul representa a carga de CPU e a linha verde representa a média ponderada dos erros FCS, de forma a obter-se uma linha mais estável, visto os valores variarem bastante no eixo vertical. No eixo horizontal estão representados os valores de up time do ponto de acesso em timeticks (centésimos de segundo). A a biblioteca usada para representar os gráfi- cos adapta-se automaticamente ao valor mais alto, os valores da carga de utilização do CPU foram divididos por 10. Estes testes foram efectuados com o mecanismo RTS/CTS desligado. Conforme é possível observar na figura 4.1, onde estão representados os gráficos correspon- dentes aos primeiros quatro testes efectuados, os valores demonstram um comportamento idêntico ou padrão. Quando o PC2 é afastado do ponto de acesso, até ficar quase fora do seu alcance e consequentemente fora do alcance do PC1 (do ponto 4 ao ponto 5), a média de erros aumenta significativamente. É provável que o incremento e decremento relevante dos erros sejam devidos não só à distância para o ponto de acesso, como também ao fenómeno de nós escondidos.
Figura 4.1: Gráficos de alguns dos testes efectuados.
Entretanto foram repetidos os mesmos testes, mas desta vez com o mecanismo RTS/CTS ligado. Para o conseguir, foi desligada a activação automática do mecanismo no aplicação implementada e activado manualmente. Conforme já referido anteriormente, alterando o va- lor do objecto dot11RTSThreshold para zero, todos os pacotes são transmitidos usando a negociação RTS/CTS. Podia esperar-se que ao activar o mecanismo RTS/CTS no ponto de acesso, que a média de erros baixasse, mas não foi isso que aconteceu. De certa forma isto já era previsível, já que seria necessário activar o mecanismo RTS/CTS nos clientes. Os gráficos destes testes não diferem quase nada em relação aos gráficos anteriores.
Será que a média de erros baixou, mas de forma quase irrisória e não foi possível obser- var no gráfico? Será que o mecanismo RTS/CTS não fez qualquer diferença? Depois de
verificar e confirmar que os valores obtidos pelo programa estavam correctos, procedeu-se à investigação da causa deste problema.
Ao investigar a primeira dúvida surgiu a hipótese de que dois computadores poderiam não ser suficientes para fazer com que a média de erros aumentasse consideravelmente. Pensou-se nisto devido ao facto de o ponto de acesso pertencer à gama empresarial, que tem produtos com melhores características, como por exemplo um melhor rendimento das comunicações, mesmo com bastante tráfego em circulação.