REDES DE COMUNICAÇÕES MÓVEIS 2º Trabalho de Laboratório. DESEMPENHO E LIMITAÇÕES DE REDES SEM FIOS IEEE Introdução

Transcrição

1 Mestrado em Engª de Redes de Comunicações REDES DE COMUNICAÇÕES MÓVEIS 2º Trabalho de Laboratório 3º ano, 1º semestre, 2010/11 Segunda-Feira, 16:30h Alunos Nome Número João Salada Marco Alves Carlos Simões DESEMPENHO E LIMITAÇÕES DE REDES SEM FIOS IEEE Introdução Para analisarmos o desempenho e limitações das redes IEEE neste trabalho, vamos comparar resultados obtidos, em situações controladas por nós, do desempenho da IEEE802.11a e IEEE802.11g. A norma IEEE802.11a trabalha sobre o espectro de frequências dos 5GHz, com varaições diferentes para a Europa, EUA e Japão. Já a IEEE802.11g funciona nos 2,4GHz, frequência bastante povoada. Ambos utilizam OFDM(Orthogonal Frequency-Division Multiplexing), tendo os mesmos valores possíveis para os débitos totais(mbps) idênticos: 6,9,12,18,24,36,48 e 54. A norma g pode ainda utilizar tecnologia existente na b, o DDSS (Direct Sequence Spread Spectrum), facto que não queremos que aconteça nesta actividade laboratorial pois iria afectar o desempenho da g. 2- Objectivos Os objectivos deste trabalho são: Caracterização de uma rede local sem fios, IEEE802.11g e a; Observação de fenómenos característicos terminal escondido 3- Metodologia Experimental Antes de realizarmos a actividade experimental no laboratório, foram decididos os pontos para preparação da mesma. Foram preparados scripts para acelerar todo o processo.

2 Assim, ficou decidido o seguinte: Hardware a utilizar: o Router WiFi Microtik o PC1 (Servidor Iperf) PC Laboratório Sistema Operativo: Ubuntu Placa Ethernet o Portátil 1 Placa de Wireless: Intel PRO/Wireless 2200BG Processador: Pentium M 1.6GHz Sistema Operativo: Ubuntu Memória Ram: 786 MB o Portátil 2 Placa de Wireless: Intel PRO/Wireless 3945ABG Processador: Intel Core 2 Duo 2.2GHz Sistema Operativo: Ubuntu Memória Ram: 2GB Software a utilizar: o Configuração do AP: WinBox o Teste de conectividade: Ping o Medição do débito: Iperf o Controlo do débito máximo: Iwconfig No decorrer do laboratório: Tarefa 1 Configuração do Ponto de Acesso Para iniciarmos os testes foi necessário configurar o AP Foi utilizada uma ligação Ethernet ao mesmo e o WinBox, a partir do qual conseguíamos entrar no sistema do AP: Foi criada uma Bridge no AP, onde foram adicionada uma interface Wireless e uma Ethernet. A interface Wireless foi configurada da seguinte maneira: o Norma a utilizar: g ou a consoante os testes o Definida SSID com nome RCM-04 o Escolhido o canal a usar, tendo em conta o facto de este não estar a ser utilizado por nenhum outro AP e desse encontrar o mais distante possível de todos os outros. Foi utilizada a ferramenta de scan do AP para realizar a pesquisa. o Desligado o RTS/CTS( mais tarde seria activado para realização de outros testes) O DHCP, foi activado e configurado com a seguinte pool de endereços: /24 Tarefa 2 Caracterização de Débitos Foi montado um servidor Iperf UDP e TCP no PC1, ligado ao AP por Ethernet. o Comando utilizado para servidor UDP

3 o iperf -su -B ip do servidor -i 1; Comando a utilizar para servidor TCP iperf -s -i 1 Tarefa 2.1 Débitos UDP/TCP sem Interfências (802.11g) Correu-se o Iperf num portátil ligado ao AP via Wireless: o Testado débito UDP com o seguinte comando: iperf uc ip do servidor b 54MB i 1 t 60 o Testado débito TCP com o seguinte comando: iperf c ip do servidor i 1 t 120 -N o Procedimento repetido mas com RTC/CTS ligado Tarefa 2.2 Débitos UDP/TCP com influência de outro terminal O mesmo cenário da tarefa anterior, mas desta vez com outro portátil associado ao mesmo AP, enviando continuamente dados para outra instância o iperf via UDP no PC1: o Foi utilizado o seguinte comando, para cria um servidor iperf a escutar noutra porta: iperf -su -B ip do servidor -p i 1 Repetidos os mesmos testes de cliente a partir do portátil. Tarefa 2.3 Débitos UDP/TCP em ª Modificada no AP a norma para a. Escolhido canal livre. Repetido processo explicado na tarefa Resultados Obtidos Começámos por realizar os testes com o AP configurado para operar na norma g, estando representado no seguinte gráfico os 4 casos de teste.

4 Observa-se uma melhor prestação por parte do protocolo UDP, independentemente do facto de estar activado o mecânismo RTS-CTS, embora a presença deste último faça descer a prestação de ambos os protocolos. Passámos em seguida para o teste com mais um portátil associado ao AP, para o qual obtivémos os seguintes resultados: Aqui a situação altera-se para o caso do protocolo TCP, em relação à experiência anterior, que não sofre descida do débito por ter activado o mecânismo RTS-CTS. Ao colocarmos um limite de 2Mb/s na interface de interferência, obtivémos os seguintes resultados:

5 Aqui nota-se uma melhor performance por parte do protocolo TCP, mas continuou-se a observar uma tendência que o mecânismo RTS-CTS afecta adversamente a performance das ligações. Finalmente, realizou-se o teste semelhante ao primeiro, apenas alterando a norma utilizada pelo AP para a. Novamente, os resultados obtidos estão representados no gráfico seguinte com os 4 casos diferentes representados por barras diferentes. Os resultados são, para todos os casos de teste, superiores aos registados para a norma b/g, havendo, porém, uma semelhança nas variações entre os casos de teste. 5- Análise de Resultados 1- Débitos UDP/TCP sem interferências Como é sugerido pelo gráfico, uma ligação UDP obtém um maior débito face a TCP, visto ser um protocolo sem controlo de fluxo, e assim, consegue utilizar completamente os recursos oferecidos pelo canal ao máximo durante toda a transmissão. Por outro lado, como o TCP opera com mecânismos de controlo de fluxo, a velocidade da transmissão varia ao longo do tempo, sacrificando a possibilidade de transmitir a um débito mais elevado durante mais tempo.

6 Finalmente, o mecânismo RTS-CTS, utilizado para reduzir colisões entre terminais a utilizar o mesmo meio para transmissão, causou uma diminuição nos débitos das transmissões, o que era esperado, visto serem trocadas mais mensagens por cada trama de dados Débitos UDP/TCP com influência de outro terminal Para o primeiro caso desta experiência, verificou-se que ambos os protocolos sofrem redução nos débitos apresentados sem interferência, embora a redução seja menos acentuada para o protocolo UDP. No segundo caso, ao limitarmos o ritmo da interface de rede a 2Mb/s, acabámos por gerar ainda mais tráfego, visto haver maior fragmentação dos pacotes. Notou-se aqui, que o protocolo TCP, através do seu controlo de fluxo, conseguiu ter menores perdas. 3- Débitos UDP/TCP a, sem interferências Os resultados deste último deste apresentam uma distribuição semelhante em relação aos dois casos de protocolo de transporte utilizado, e a presença ou não de mecânismo RTS- CTS: UDP tem maiores débitos do que TCP, e em ambos os protocolos há uma queda de débito com a activação do mecânismo de RTS-CTS. Porém, registaram-se débitos médios mais elevados do que no caso da primeira experiência, o que se pode dever ao facto de esta norma operar numa banda de frequências menos suspectiva a interferência de outros equipamentos (nomeadamente receptores Bluetooth ou telefones sem fios). Finalmente, este teste mostra que nunca se terá um débito de 54Mbit/s, como aliás já havia sido notado nas aulas, visto haver algum overhead adicionado pela informação para manter a ligação aberta. Como tal, esperávamos um limite no débito de 32Mbit/s, e foi esse o resultado que obtivémos. 6- Conclusões A norma g, sendo uma boa evolução da versão b, continua a sofrer do mesmo problema de utilizar uma banda de frequências já de si só bastante populada. De notar também, que comparada com a norma a, existe uma maior sobreposição de canais, o que origina uma influencia por parte de outros AP s na zona. Mas ainda assim, é possível obter-se débitos mais que suficientes para a maioria das aplicações dos dias de hoje. Este facto não se aplica à norma a, que opera num espectro menos populado, e vê-se menos afectada por interferências geradas por aparelhos externos à rede. Porém, pelo facto de se utilizar um meio de propagação partilhado, quanto mais terminais estiverem ligados ao mesmo AP, pior será a prestação obtida do canal, embora isso possa ser amenizado com a utilização do protocolo TCP, de modo a que o débito seja ajustado de acordo com a congestão da rede.