Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação

Transcrição

1 Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação AGREGAÇÃO DE PACOTES EM TRANSMISSÕES VOIP SOBRE REDES SEM FIO SATURADAS Paulo Henrique Azevêdo Filho Monografia apresentada como requisito parcial para conclusão do Bacharelado em Ciência da Computação Orientador Prof. Dr. Jacir Luiz Bordim Coorientador Prof. Ms. Marcos Fagundes Caetano Brasília 2010

2 Universidade de Brasília UnB Instituto de Ciências Exatas Departamento de Ciência da Computação Bacharelado em Ciência da Computação Coordenador: Prof. Dr. Marcus Vinícius Lamar Banca examinadora composta por: Prof. Dr. Jacir Luiz Bordim (Orientador) CiC/UnB Prof. Ms. Marcos Fagundes Caetano (Coorientador) CiC/UnB Prof. Ms. João José Costa Gondim CiC/UnB Prof. a Dr. a Maria Emília Machado Telles Walter CiC/UnB CIP Catalogação Internacional na Publicação Azevêdo Filho, Paulo Henrique. AGREGAÇÃO DE PACOTES EM TRANSMISSÕES VOIP SOBRE REDES SEM FIO SATURADAS / Paulo Henrique Azevêdo Filho. Brasília : UnB, p. : il. ; 29,5 cm. Monografia (Graduação) Universidade de Brasília, Brasília, VoIP, 2. SIP, 3. RTP, 4. IP, 5. Agregação de Pacotes, 6. Jitter, 7. Delay CDU 004 Endereço: Universidade de Brasília Campus Universitário Darcy Ribeiro Asa Norte CEP Brasília DF Brasil

3 Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação AGREGAÇÃO DE PACOTES EM TRANSMISSÕES VOIP SOBRE REDES SEM FIO SATURADAS Paulo Henrique Azevêdo Filho Monografia apresentada como requisito parcial para conclusão do Bacharelado em Ciência da Computação Prof. Dr. Jacir Luiz Bordim (Orientador) CiC/UnB Prof. Ms. Marcos Fagundes Caetano CiC/UnB Prof. Ms. João José Costa Gondim CiC/UnB Prof. a Dr. a Maria Emília Machado Telles Walter CiC/UnB Prof. Dr. Marcus Vinícius Lamar Coordenador do Bacharelado em Ciência da Computação Brasília, 04 de Setembro de 2010

4 Dedicatória Dedico este trabalho a todos aqueles que de alguma maneira fizeram parte dele, de modo direto ou indireto. Sem as pessoas do meu convívio não seria possível manter o constante desafio a mim mesmo, e nada mais justo que a elas dedicar os frutos dessa convivência. iv

5 Agradecimentos Após todo o apoio que tive para concluir o curso e realizar este trabalho, é difícil encontrar um modo adequado de expressar minha gratidão a todos aqueles que de alguma maneira fizeram parte dessa conquista. Se isso tudo foi realizado, foi porque eu estava de pé sobre ombros de gigantes, como dito por Isaac Newton, e de alguma maneira pude enxergar maneiras de tornar concretas ideias e sonhos que tinha desde muito novo. Agradeço a meu pai, Paulo Henrique Azevêdo, que também é professor da Universidade de Brasília, por me ajudar a planejar o ciclo que aqui se encerra, mesmo muito antes de meu ingresso na Universidade. Esse apoio se deu não apenas no âmbito acadêmico, como também em minha formação como pessoa, sendo sempre um exemplo com valores bem definidos e me ajudando a ver como o mundo funcionava bem antes de eu saber o tamanho desse mundo. Também não posso deixar de citar minha mãe, Saniday de Oliveira Azevêdo, por sempre ter sido o ponto de apoio nas horas mais duras, me apoiando irrestritamente com o que estivesse a seu alcance, nem que isso fosse colo, e me ajudando a enxergar a vida em função de pessoas, muito mais do que de estudos, trabalho e realizações, pois são as pessoas que ficam em nossas vidas. Meu irmão, Pedro Henrique, também foi uma referência, por à sua maneira me fazer enxergar como ser melhor. Outros membros da família, como avós, tios e primos, também estão todos de alguma maneira representados neste trabalho, seja em inspiração ou no uso de figuras de linguagem características, e por isso também lhes sou muito grato. A ajuda da Mariana também foi fundamental, com as revisões constantes do texto, a tolerância à ausência causada pela dedicação aos estudos, o apoio quando o cansaço surgia, o carinho e a companhia em ocasiões mais diversas, de reuniões no laboratório ANDES à participação em eventos de software livre. Agradeço aos professores Jacir e Caetano, por toda a dedicação a mim, nas matérias que pude cursar sob a tutela deles e ao longo deste projeto, que envolveu vários telefonemas durante fins de semana, s de madrugada e reuniões em horários inusitados. Com seu apoio e experiência, foi possível ir além do que eu esperava da graduação. Agredeço também aos professores Maria Emília e João Gondim, por aceitarem o meu convite para participar da banca e avaliarem meu trabalho, sempre com o objetivo de torná-lo melhor. Sem essas intervenções, esse trabalho não poderia ter a mesma qualidade. Outros participantes desse processo também devem ser lembrados, como todos os professores da Universidade com os quais tive algum tipo de relação, pois neles vi a crença profunda em progredir a ciência e repassar todo o conhecimento acumulado e gerado. Meus amigos e os colegas de curso também foram fundamentais para que essa etapa fosse concluída. Foram muitas noites viradas e muitos favores feitos, em várias instâncias da vida pessoal, estudantil e profissional, para que prazos fossem cumpridos ou simplesmente a diversão fosse alcançada. v

6 Resumo Este trabalho apresenta uma nova proposta de como aumentar a capacidade de redes sem fios saturadas para sustentar conversas de voz em tempo real, sem que isso prejudique a qualidade percebida pelos usuários. Para isso, foi elaborado um protocolo de agregação de pacotes na camada IP que visa à redução do número de transmissões no ambiente sem fios e à diminuição do volume de cabeçalhos de rede enviados, de modo que uma parte maior da capacidade da rede seja usada para trafegar os dados de voz dos usuários. Essa proposta, denominada MAPAS (Mecanismo de Agregação de Pacotes em Ambientes Saturados), foi testada em comparação com uma política de agregação de pacotes que representa o estado da arte nessa área, bem como com uma rede que não agregava pacotes, e foi possível observar uma melhora significativa no suporte às conversas pela rede que usava o MAPAS. Essa validação ocorreu em um simulador de redes especialmente desenvolvido para essa tarefa, considerando redes e VoIP com o codec ilbc como o cenário de testes. Palavras-chave: VoIP, SIP, RTP, IP, Agregação de Pacotes, Jitter, Delay vi

7 Abstract This work presents a new technique for improving the capacity of saturated wireless networks of hosting real time voice conversations, without degrading the quality provided to users. To reach this goal, a packet aggregation protocol was tailored to work in the IP layer of the networking stack, in order to reduce the number of wireless transmissions and decrease the volume of headers sent, so that a greater part of the network capacity is used to carry voice data. This technique, called MAPAS, was compared to a state-of-the-art packet aggregation policy and to a non-aggregating network, and a significant improvement in supporting the traffic was noticed in the network that used MAPAS. This test was performed in a software simulator developed especially for this experiment, considering IEEE wireless networks and the ilbc VoIP codec as the testing scenario. Keywords: VoIP, SIP, RTP, IP, Packet Aggregation, Jitter, Delay vii

8 Sumário Lista de Figuras Lista de Tabelas Glossário x xii xiii 1 Introdução Problema Objetivos Metodologia e Estrutura Redes e Redes sem Fio Redes de Dados Modelo OSI Modelo TCP/IP Redes Sem Fios Divisão do Canal Roteamento Deficiências do Considerações Finais Telefonia e VoIP Telefonia Histórico Telefonia Fixa Telefonia Móvel Observações VoIP Tipos de dispositivos VoIP Família de protocolos H Família de protocolos SIP Protocolos VoIP Problemas de qualidade de serviço em VoIP Latência ou Delay Jitter Perda de pacotes Considerações Finais viii

9 4 Agregação de Pacotes Agregação Básica Revisão do Estado da Arte Data Funneling XORs in the air Hop-By-Hop IPAC Comparação das técnicas Considerações Finais Agregação de Pacotes em Ambientes Saturados Método MAPAS (Mecanismo de Agregação de Pacotes em Ambientes Saturados) Cabeçalhos de Agregação Funcionamento Metodologia de Desenvolvimento do Simulador Considerações Finais Experimentos e Resultados Métricas Usadas Parâmetros de Eficiência no Uso do Canal Parâmetros de Qualidade de Serviço Parâmetros de Desempenho da Agregação Experimentos Primeiro Cenário: Gargalo Simples Segundo Cenário: Rede Multiplexada Terceiro Cenário: Rede Hierárquica Considerações Finais Conclusões e Trabalhos Futuros Contribuições Trabalhos Futuros Referências 77 ix

10 Lista de Figuras 2.1 Tipos de redes sem fios no padrão Problema do terminal exposto. Durante a transmissão do nó A para o nó B, o nó C não pode transmitir para o nó D sob pena de gerar interferência no nó B. Diz-se que o nó C é um terminal exposto Problema do terminal escondido. Se não há transmissões, o nó A e o nó C detectam que o canal está livre e começam uma transmissão para o nó B em momentos próximos, gerando uma colisão Uso de mensagens RTS e CTS para envio de dados em redes sem fios Overhead por cabeçalhos induzido pelas diversas camadas de rede [12] Dispositivo de conversa de voz composto por duas latas e um cordão Arquitetura típica de uma rede de telefonia convencional Visão de uma arquitetura H.323 típica [43] Visão de uma arquitetura mista com SIP e PSTN [40] Visão simplificada do estabelecimento de uma chamada SIP Qualidade de alguns CODECs de áudio em função da quantidade de pacotes descartados, de acordo com a percepção de usuários em testes 1. No caso do ilbc [2], até 5% de perdas são toleráveis, e a partir de 10% a qualidade é péssima [32] Topologia de rede composta por duas sub-redes, A e B, conectadas por roteadores. Os computadores participarão de diálogos VoIP que serão transmitidas por meio dos roteadores Representação de vários pacotes sendo agregados em um só, com a adição de cabeçalhos extras para controlar o início dos pacotes Exemplo de topologia para Data Funneling [35] Topologia de rede usada para contextualizar o artigo XORs in the air em duas situações: (a) Transmissões no modo normalmente usado. (b) Codificação oportunista proposta por Katti et al. [25] Exemplo dos dados no canal X tempo [10] Pacotes VoIP agregados pela nova proposta Esquema de modelagem do simulador, com base nas entidades identificadas como participantes das simulações Diagrama UML do simulador desenvolvido Formato da rede no primeiro cenário, com um gargalo na rede Número de transmissões em função da banda no último enlace x

11 6.3 Total de bytes transmitidos em função da banda no último enlace Volume de cabeçalhos, em bytes, transmitidos em função da banda no último enlace Tempo de simulação em função da banda no último enlace Goodput em função da banda no último enlace Throughput em função da banda no último enlace Overhead em função da banda no último enlace Porcentagem de pacotes descartados em função da banda no último enlace Delay mínimo em função da banda no último enlace Delay máximo em função da banda no último enlace Delay médio em função da banda no último enlace Jitter em função da banda no último enlace Mínimo de pacotes agregados em função da banda no último enlace Máximo de pacotes agregados em função da banda no último enlace Média de pacotes agregados em função da banda no último enlace Formato da rede no segundo cenário, com um gargalo ainda mais acentuado que na primeira rede estudada Formato da rede no terceiro cenário, no qual há uma escala hierárquica entre os nós da rede, que devem sempre se reportar aos nós superiores Comparativo gráfico do número de transmissões realizado em cada cenário usando as três abordagens implementadas Comparativo gráfico do volume em bytes transmitido em cada cenário usando as três abordagens implementadas xi

12 Lista de Tabelas 2.1 Pilha de protocolos OSI Pilha de protocolos TCP/IP Comparação dos métodos de agregação estudados Composição do cabeçalho de agregação proposto Resultados obtidos para o segundo cenário de rede simulado Resultados obtidos para o terceiro cenário de rede simulado xii

13 Glossário CBR Sigla para Constant Bit Rate, ou taxa constante de bits, um tipo de tráfego que envia bits de forma constante e uniforme. 44, 45 CTS Sigla em inglês para Clear To Send, é a resposta ao pacote RTS autorizando o envio. xiv, 44, 58 delay É o tempo levado entre a emissão de um pacote com um trecho de voz de um dispositivo e a sua chegada no destino. 35, 41 45, 59, 63 65, 70, 72, 75 DIFS Tempo durante o qual um dispositivo que quer enviar pacotes em uma rede irá escutar a rede antes de transmitir. Se durante a escuta nenhuma atividade for captada, a transmissão será realizada, caso contrário o nó aguardará um tempo exponencialmente maior do que antes e repetirá o processo, até achar o canal livre. 58 flooding É quando um dispositivo de rede envia pacotes a uma taxa muito maior do que um dos destinatários consegue processar, o que gera enfileiramento ou mesmo perda de pacotes. 5, 8 goodput Taxa de vazão dos dados em si, sem cabeçalhos, pela rede por unidade de tempo. xiv, 48, 58, 61, 62, 70, 72 jitter É a média da diferença de tempo entre a chegada de dois pacotes consecutivos. Quanto mais próximo esse valor for da diferença de tempo obtida na origem dos pacotes, mais fluida será a comunicação. 31, 32, 35, 43, 59, 66, 67, 70, 72 next hop Próximo nó da rede pelo qual um pacote tem de passar para chegar a seu destino final overhead É todo o custo extra induzido para se realizar uma operação. Por exemplo, o preço pago devido ao peso do envelope ao enviar uma carta pelos serviço de correio pode ser considerado como overhead. 30, 33, 34, 41, 42, 58, 62, 68, 70, 72 payload É o conteúdo útil de um pacote, sem seus cabeçalhos. Por exemplo, a gravação de voz em um contexto de VoIP. 30, 41, 44, 50, 53, 55, 58, 61, 70, 72 xiii

14 QoS Sigla em inglês para Quality of Service, ou Qualidade de Serviço, um conjunto de requisitos mínimos de desempenho da rede para prover condições de haver transações multimídia de nível aceitável pelos usuários, como conversas que não sofram ruídos ou interrupções , 46, 47, 57 59, 68, 70, 71, 73 RTS Sigla em inglês para Request To Send, ou Solicitação de Envio, é um pacote enviado por um nó que deseja transmitir pacotes em redes para requisitar tempo no canal para realizar a transmissão, e quando essa atividade não for causar colisões, é esperado um pacote CTS. Essa técnica evita o problema do terminal escondido. xiii, 44, 58 SIFS Sigla em inglês para Short Interframe Space, ou Pequeno Espaço entre Quadros, serve para a antena do dispositivo que estava transmitindo antes voltar ao modo de escuta para receber os pacotes da rede. 58 throughput Taxa de vazão total pela rede por unidade de tempo, considerando o fluxo de cabeçalhos e de dados. Sempre é maior ou igual ao valor do goodput na mesma rede no mesmo instante. 31, 41, 45, 57, 58, 62, 70, 72 timeout É quando um pacote chega atrasado demais para ser usado e é portanto descartado sem ser aproveitado. 9, 58, 65 UML Unified Modelling Language, ou Linguagem de Modelagem Unificada, em tradução livre, é uma linguagem gráfica padronizada e amplamente usada no mercado para representar a modelagem de sistemas computacionais. 53 xiv

15 Capítulo 1 Introdução No mundo moderno, a comunicação entre as pessoas tem tido cada vez menos barreiras, e é possível se comunicar de forma instantânea com pessoas de quase qualquer lugar do mundo usando a voz, por meio de telefones fixos e celulares e usando redes de dados. Outra inovação importante é a da conectividade sem fios, que permite o uso de estações de trabalho, computadores portáteis, agendas eletrônicas e outros dispositivos totalmente conectados entre si e à Internet sem as dificuldades impostas pelo uso de cabos de redes. Uma tendência recente é a de se usar softwares de conversa de voz em aparelhos sem fios usando redes de dados para transmissão, ao invés das redes de telefonia convencionais. Isso se justifica tanto pela redução de custos, já que especialmente para ligações de longa distância o uso de redes de dados implica custos menores para o usuário, quanto pelas possibilidades não oferecidas pela telefonia convencional, tais como troca de arquivos ou uso de vídeo em tempo real de forma paralela à conversa, permitindo que os usuários se vejam durante o diálogo. A interação, aliás, não é necessariamente entre duas pessoas, já que outra nova possibilidade é a conferência com vários participantes ao mesmo tempo. O uso de redes de dados sem fios para esses fins pode ser seriamente prejudicado pela combinação de dois elementos, a saber: Desempenho de rede: As redes sem fios não oferecem o mesmo desempenho que as redes cabeadas, pois o meio sem fios 1 é passível de muitas interferências que não afetam ou o fazem de forma moderada nas redes cabeadas; Requisitos de desempenho: A interação por voz exige que a rede tenha uma boa capacidade de enviar vários trechos de conversa de maneira contínua e que o faça de maneira rápida, pois se pedaços da conversa chegarem muito atrasados, ou se a espera entre a chegada de um trecho e o seguinte não for contínua, a qualidade da conversa será bastante degradada, atrapalhando a experiência do usuário. Outro fator que influencia negativamente essa tendência é o crescente número de usuários que compartilham uma mesma rede, fazendo com que o desempenho da rede percebido pelo usuário seja ainda inferior, mesmo quando as suas necessidades só aumentam. Vários estudos foram feitos com o intuito de melhorar o aproveitamento da rede e otimizar seu uso para melhor satisfazer aos usuários, como [10, 20, 25, 35, 37], mas alguns 1 O meio sem fios pode ser, dentre outros, o ar, o vácuo ou mesmo a água, embora no caso dos aparelhos citados nas situações descritas geralmente o ar faça o papel de meio. 1

16 deles não são aplicáveis a contextos nos quais a temporização pode ser fundamental, como o uso de voz e vídeo, e outros são muito complexos para que sejam trazidos à vida real, e de modo geral os resultados não apresentam melhorias muito significativas para justificar a sua implementação. 1.1 Problema A demanda por voz e vídeo em tempo real continua crescente, bem como o número de usuários de dispositivos móveis, o que é justificado pela queda nos preços dos aparelhos observada nos últimos anos. O uso de redes móveis já é realidade em boa parte do mundo, bem como os problemas apresentados. Desse modo, é possível prever o agravamento de problemas de comunicação multimídia em tempo real. Como os estudos recentes não resolvem de maneira satisfatória as deficiências notadas, é clara a necessidade de uma abordagem diferente para ampliar a capacidade de uso das redes e de suas infraestruturas físicas já instaladas, de modo que a computação móvel possa oferecer de maneira estável novos serviços aos usuários nos próximos anos. 1.2 Objetivos O objetivo geral desse trabalho é propor uma técnica nova de encaminhamento de dados em redes sem fios, que aumente a capacidade dessas redes de suportar comunicações por voz com qualidade. Para isso, essa nova técnica deve possuir as seguintes características: A qualidade das conversas não pode cair de forma significativa do ponto de vista do usuário; O método desenvolvido deve aumentar a capacidade da rede de suportar conversas de voz em tempo real, de modo que seja possível conduzir um número de conversas simultâneas maior do que o atual, ou ainda que uma rede que não suporte várias conversas ao mesmo tempo passe a ter capacidade para tal. Os objetivos específicos são: Propor o Mecanismo de Agregação de Pacotes em Ambientes Saturados (MAPAS); Desenvolver um simulador capaz de testar o MAPAS; Realizar testes com o MAPAS e validá-lo comparando com outras técnicas. 1.3 Metodologia e Estrutura Os estudos citados mostram que a técnica de agregação de pacotes de rede é muito promissora para cumprir com os objetivos apresentados, embora as variantes hoje disponíveis não tenham resultados tão superiores ao comportamento normal das redes. Em função disso, esse trabalho tem seu foco na técnica de agregação de pacotes e em como aplicá-la de maneira a cumprir com esses objetivos. Para isso, foi construída uma base teórica sólida, seguida pelo desenvolvimento da proposta e os experimentos e por fim as conclusões finais. Desse modo, o texto está organizado da seguinte maneira: 2

17 Capítulo 2: Contém o levantamento de como funcionam hoje as redes de dados que são usadas para tráfego de usuários em geral, explicando o funcionamento de redes com fios e sem fios, e detalhando de forma mais profunda os problemas aqui apontados; Capítulo 3: É apresentado um histórico da telefonia, de seu surgimento até os dias atuais, passando por telefonia fixa, rádios de comunicação e telefones celulares. Em seguida estão expostos os fundamentos de VoIP, a técnica usada para se manter conversas de voz em redes de dados comuns; Capítulo 4: Há um estudo sobre o estado da arte na técnica de agregação de pacotes, exibindo os estudos mais promissores nessa área e suas fraquezas, cuja diminuição é parte dos objetivos desse trabalho; Capítulo 5: Uma nova proposta é apresentada e detalhada, para que o leitor compreenda a maneira como os problemas das técnicas atuais foram sanados ou amenizados pelas escolhas feitas, e quais são as implicações dessas escolhas. No mesmo capítulo é explicado como foi realizado o desenvolvimento de um software simulador de redes sem fios, com o intuito de permitir a realização de experimentos com a aplicação da nova proposta, bem como a comparação dessa proposta com a melhor proposta dentre as estudadas anteriormente e com o cenário onde não há nenhuma tentativa de otimização, para uso como grupo de controle. Capítulo 6: Apresenta as métricas usadas para medir os resultados das simulações e fazer a comparação de desempenho da técnica proposta com os métodos de outros autores, detalha os experimentos realizados e exibe os resultados obtidos, interpretando-os sob o ponto de vista do uso eficiente da rede e da experiência percebida pelo usuário. Capítulo 7: Contém uma análise sobre a qualidade dos resultados obtidos, relacionandoos aos objetivos traçados, e também uma lista de adaptações que podem ser objetos de estudos futuros. 3

18 Capítulo 2 Redes e Redes sem Fio O objetivo desse capítulo é fazer uma exposição da parte básica de redes de dados, que abrange tanto as redes cabeadas como as sem fios, o que será feito na seção 2.1, para em seguida tratar das partes específicas de redes sem fios na seção 2.2, pois elas compõem o cenário da pesquisa sendo desenvolvida. 2.1 Redes de Dados Redes de dados são redes voltadas a comunicações que não se limitam a um único tipo de informação, tais como as antigas redes de telefonia se voltavam à voz, ou os telégrafos, que se voltavam a sinais que codificavam letras. As redes de dados são mais genéricas por transportar qualquer tipo de informação, que deverá ser transformada adequadamente antes da transmissão, de um formato compreensível por humanos para um que os dispositivos nessas redes possam transmitir, e também desse formato dos dispositivos de redes para um formato compreensível por humanos, na chegada do dado ao seu destino. De fato, a visão de que é preciso converter de formato humano para a máquina e vice-versa é simplificada. Mesmo no dispositivo, várias conversões e adaptações precisam ser feitas para que os dados possam ser trocados entre diferentes tipos de dispositivos. Como alguns tipos de conversões feitos são comuns a diversas implementações de rede, embora não houvesse padronização, em 1977 a ISO iniciou um trabalho de sistematização em camadas da arquitetura de redes então utilizada. Esse trabalho culminou com a publicação do modelo OSI (interconexão de sistemas abertos, em tradução livre), que propunha diferentes camadas empilhadas [8] Modelo OSI O modelo OSI surgiu com a filosofia de que cada uma das camadas empilhadas que o compunham iria prover serviços à camada imediatamente superior, valendo-se, para isso, de tratamentos apropriados e serviços providos a ela pela camada imediatamente inferior. Esse modelo se dividia em sete camadas, conforme visto na tabela 2.1. Entre dispositivos diferentes, nunca uma camada de um dispositivo se comunica com uma camada diferente do outro dispositivo. A comunicação sempre se dá entre camadas iguais de dispositivos diferentes. Esse modelo foi inicialmente proposto em [44], e suas camadas serão tratadas em maior detalhe a seguir. 4

19 Tabela 2.1: Pilha de protocolos OSI Camada Aplicação Apresentação Sessão Transporte Rede Enlace Física Modelo OSI Função Processamento de rede para a aplicação de usuário Representação e cifragem de dados Comunicação entre dispositivos Confiabilidade e conexões fim-a-fim Determinação de rotas e endereçamento lógico Endereçamento físico Envio e recepção dos dados da camada de enlace ao meio físico A camada física Tem a função de transmitir bits diretamente pelo canal de comunicação físico imediatamente abaixo de si. Essa camada tem a preocupação de calcular o tipo de interferência no meio que irá fazer com que os demais dispositivos na rede interpretem um bit 1 e o tipo que irá causar a interpretação de um bit 0, quanto tempo deve durar a representação de um mesmo bit, se a conexão é simplex, half-duplex ou full-duplex 1, como estabelecer uma conexão, como finalizar a mesma, quantos são e qual é a função de cada pino do conector de rede usado, etc. Esse trabalho consiste em tratar dos aspectos mecânicos e elétricos do meio físico no qual se está inserido, para garantir a transmissão dos dados. A camada de enlace Sua função é criar um canal de comunicação que pareça livre de erros de transmissão para a camada de rede, usando os serviços da camada física. Como essa camada pode sofrer erros diversos, ela não poderia prover diretamente seus serviços àquela, justificando a existência da camada de enlace. Essa tarefa é cumprida com a divisão do fluxo de dados da camada de rede em quadros com um número máximo de bytes. Esses quadros serão transmitidos sequencialmente, e a confiabilidade do serviço é garantida por quadros de confirmação enviados pela camada de enlace do dispositivo interlocutor. Outra tarefa da camada de enlace é evitar que um dispositivo muito rápido cause flooding em um dispositivo mais lento com mais pacotes do que ele possa tratar. Para isso há um mecanismo de regulação de tráfego, pelo qual um dispositivo receptor comunica ao emissor de quanto espaço ainda dispõe em sua fila de chegada. A camada de rede Responsável pelo controle da subrede, determina como os pacotes são encaminhados da origem ao destino. Essas rotas podem ser estáticas ou bastante dinâmicas, em função da rede em que se está trabalhando, e a camada de rede deve abstrair esse aspecto para a camada de transporte. No caso de haver muitos pacotes na mesma subrede, pode haver 1 Uma conexão é simplex se há um emissor e um receptor, e os papéis nunca são invertidos. Caso os papéis possam se inverter, mas a comunicação só se der em um sentido por vez, ela é half-duplex. Caso haja fluxo de dados em ambos os sentidos ao mesmo tempo, a comunicação é dita full-duplex. 5

20 congestionamento, que, por ser de natureza distinta daquele descrito na camada de enlace, deverá ser tratado pela camada de rede. Essa camada também atua na comunicação entre redes distintas, pois o tipo de endereçamento pode ser diferente entre elas, ou ainda um pacote enviado pode ser grande demais para trafegar na sua rede de destino. A camada de rede deve, então, resolver tais problemas de endereçamento e quebrar pacotes grandes demais, para que possam trafegar na rede de destino. A camada de transporte Essa camada deve tratar os dados recebidos da camada de sessão e encaminhá-los à camada de rede, assegurando que cheguem ao destino. Para isso, pode ser preciso dividir os dados em pacotes menores, juntando-os na outra ponta quando for o caso. Esse serviço deve abstrair detalhes do hardware empregado, pois as camadas superiores não devem precisar sofrer adaptações no caso de os dispositivos subjacentes evoluírem. Além disso, também será definido o tipo de conexão provida à camada de sessão. De conexões virtualmente sem erros, nas quais os bytes chegam ao destino na ordem em que foram enviados, a outras que tratam as mensagens isoladamente, sem cuidar da ordem em que chegam, passando por conexões que enviam mensagens a vários destinos de uma vez, a camada de transporte pode prover vários tipos de laços entre dispositivos. O tipo da conexão será determinado no início da mesma, e a escolha é do desenvolvedor da aplicação que for usar essa conexão, em função do tipo de confiança que é preciso ter na transmissão dos dados do aplicativo em questão. A partir da camada de transporte até a camada de aplicação, qualquer comunicação efetuada é realizada entre o emissor e o destinatário final, em contraste com as camadas inferiores, nas quais a comunicação era apenas ponto-a-ponto. Na camada de transporte já é possível ter essa abstração de funcionamento. A camada de sessão A camada de sessão provê serviços de estabelecimento de sessões, úteis para controlar qual é o dispositivo que deve transmitir em um determinado espaço de tempo, sincronização com vistas à retomada da comunicação no caso de panes e gerenciamento de tokens, para evitar que dois dispositivos realizem uma operação crítica ao mesmo tempo. A camada de apresentação A partir dessa camada há a preocupação com a sintaxe e a semântica dos dados trocados. Isso permite, por exemplo, que computadores de arquiteturas big-endian 2 se comuniquem com computadores little-endian, e que as representações de dados em um sejam adequadamente convertidas quando chegarem no computador de destino. Além disso, essa camada pode tratar da cifragem dos dados, quando do envio, e da decifragem dos mesmos, quando da recepção, para prover segurança adicional. 2 Big-endian e little-endian são diferentes maneiras de organizar os bits para representar números nos computadores. 6

21 A camada de aplicação Contém os protocolos de comunicação com os quais os usuários (programadores) tratam com frequência, tais como protocolos para transferência de arquivos, solicitação de envio de páginas web, transferência de s, etc Modelo TCP/IP Quando o Departamento de Defesa dos Estados Unidos planejava a ARPANET, no contexto da Guerra Fria, o objetivo era poder continuar transmitindo dados mesmo que alguns dispositivos intermediários pudessem ser removidos da rede durante a transmissão, por meio de sabotagens e ataques inimigos, por exemplo. O modelo TCP/IP, criado em função da ARPANET, foi projetado para cumprir esse objetivo, ao mesmo tempo em que proveria flexibilidade para servir a aplicações com os mais diversos tipos de requisitos de redes, tais como a transferência de pequenas mensagens de texto, grandes arquivos ou o uso em tempo real para conversas com áudio e vídeo [8]. Esse modelo é mais simplificado que o OSI, com menos camadas e abstrações maiores, em função da grande variedade de hardwares sobre as quais deveria operar. Essas camadas podem ser vistas na tabela 2.2. Tabela 2.2: Pilha de protocolos TCP/IP Camada Aplicação Transporte Internet Interface de Rede Modelo TCP/IP Função Processamento de rede para a aplicação de usuário Confiabilidade e conexões fim-a-fim Determinação de rotas e endereçamento lógico Envio e recepção dos dados da camada de internet ao meio físico A camada de internet É a base desse modelo, e provê a abstração necessária para que os diálogos permaneçam ativos mesmo quando dispositivos intermediários saiam de operação. Dentro dessa camada, a escolha foi pela comutação de pacotes na rede, em vez de estabelecer circuitos virtuais estáticos. Desse modo, caso dispositivos deixem de funcionar ou sofram sobrecarga de pacotes, apenas alguns desses pacotes serão perdidos, bastando achar uma nova rota e reenviá-los [41]. O nome da camada se refere à sua comunicação entre diferentes redes, e não à Internet como a rede mundial de computadores. Essa camada pode ser empregada mesmo em redes que não tenham qualquer correlação com a Internet propriamente dita. Tais características permitem que diferentes pacotes possam seguir por diferentes rotas entre sua origem e seu destino, podendo mesmo chegar em uma ordem distinta daquela do envio, quando a camada de Transporte deverá reordená-los. A camada de internet define um tipo de pacote que deverá ser trocado e um protocolo de comunicação pelo qual esse pacote será transmitido, denominado IP (Internet Protocol). Como sua tarefa é enviar um pacote e fazê-lo chegar a seu destino, os problemas que deverão ser observados são 7

22 os de congestão na rede e roteamento de pacotes, de modo que é clara a correspondência com a camada de rede do modelo OSI. A camada de transporte Ao contrário do modelo OSI, no qual há várias camadas entre a camada de rede e a de aplicação, no modelo TCP/IP há apenas a camada de transporte, responsável por estabelecer uma conexão fim-a-fim para uso da aplicação. Nesse caso, a própria aplicação deverá fazer os tratamentos relativos às camadas do modelo OSI omitidas no modelo TCP/IP, quando eles forem necessários. Os dois principais protocolos usados na camada de transporte atualmente são o TCP e o UDP. UDP O protocolo UDP (User Datagram Protocol) é o protocolo que provê serviços não orientados a conexão. Suas funcionalidades [41] são: Multiplexação de conexões: Com o uso de portas de comunicação, é possível fazer com que um dado dispositivo mantenha várias comunicações com outros dispositivos, repetidos ou não. Para isso, basta que em um dispositivo cada canal de comunicação esteja associado biunivocamente a uma porta. Desse modo, o sistema operacional poderá encaminhar adequadamente os pacotes a cada aplicação que mantém um canal de comunicação. Controle do tamanho de cada pacote: Com isso é possível encaminhar à aplicação apenas os dados destinados a ela, pois o início e o fim dos dados são bem delimitados. Verificação de integridade: Torna possível a decisão sobre o êxito do transporte de um pacote. Se o pacote chegar corretamente, pode ser usado pela aplicação. Caso contrário, é possível fazer algum tipo de interpolação para gerar dados similares aos que foram realmente transmitidos, ou mesmo descartar o pacote. Para o tipo de aplicação ao qual o UDP se destina, isso não é um problema, como será visto a seguir. O UDP não trata de situações que requeiram um retorno por parte do receptor, tais como o flooding do receptor por sua limitada capacidade de processamento, limitação do fluxo de pacotes dada uma situação de congestionamento da rede e a própria retransmissão de um pacote por falha em sua transmissão original. Além disso, características inerentes a cada pacote, como a prioridade de cada um, não podem ser implementadas nesse protocolo. Dadas essas características do UDP, é fácil ver que ele é adequado a aplicações de comunicação nas quais a perda de alguns pacotes não é um grande problema, ou ainda quando a retransmissão de um pacote faça com que ele chegue tarde demais. Exemplos dessas aplicações aparecem na transmissão de vídeos, áudio e voz, pois na falta de algum pacote é possível, usando os pacotes que vêm antes e depois, fazer a interpolação dos dados e gerar algo similar ao pacote que não foi transmitido com sucesso. Além disso, caso houvesse a retransmissão de um pacote, ele possivelmente chegaria tarde demais, quando não faria mais sentido usá-lo na comunicação. 8

23 O fato de o UDP não prover retorno, apesar de inicialmente não parecer, pode ser bastante vantajoso, pois reduz o tamanho dos pacotes e facilita o desenvolvimento de aplicações que fazem uso de transmissões multicast 3, pois de outro modo, caso o emissor aguardasse o retorno de cada receptor, seria induzido um grande atraso entre o envio de cada pacote, inviabilizando as aplicações de tempo real para as quais o UDP é mais adequado. TCP O protocolo TCP (Transmission Control Protocol) é, como seu nome indica, um protocolo que permite a realização de controle de transmissão. Ele foi criado seguindo a filosofia que norteou a criação do modelo TCP/IP como um todo, de que a rede à qual um dispositivo está conectado pode não ser confiável durante todo o tempo, e que pode haver variações radicais nos tipos e nas capacidades dos dispositivos pelos quais os dados trafegarão entre sua origem e seu destino. Como dois pacotes consecutivos poderiam ser enviados por rotas totalmente disjuntas, à exceção de sua fonte e seu destino, eles poderiam chegar ao destino em ordem inversa, ou mesmo nenhum deles chegar. O TCP foi concebido para prover um canal de comunicação confiável sobre uma rede não confiável. Ele é orientado a conexão e provê algumas características de confiabilidade à conexão [41], tais como: Os dados serão passados à camada de aplicação na ordem em que foram enviados no emissor. Haverá garantia de entrega de cada pacote, ou um aviso de que não será possível dar essa garantia. A primeira característica é obtida por meio de um campo de sequenciamento, contido em cada pacote, que permitirá a ordenação, no destino, dos dados, antes que os mesmos sejam encaminhados à camada de aplicação, e a segunda característica é implementada usando um mecanismo de ACKs e timeouts. O destinatário de uma mensagem deverá, ao receber uma mensagem, enviar ao emissor um pacote de acknowledgement, ou simplesmente ACK, que indica que o pacote foi recebido com sucesso. O emissor, após enviar um pacote, irá iniciar um cronômetro com um tempo limite. Caso esse tempo limite seja atingido sem o recebimento de um ACK relativo a esse pacote, o emissor retransmitirá, pois o pacote pode não ter sido recebido ou o ACK pode ter sido perdido no caminho. Uma característica interessante do TCP é a possibilidade de piggybacking dos ACKs, ou seja, na existência de uma comunicação bilateral entre dois dispositivos usando o protocolo TCP, ao invés de dedicar um pacote para fazer o ACK de cada pacote recebido, cada um dos interlocutores pode usar um campo no cabeçalho TCP de um pacote de dados a ser enviado para informar que recebeu com sucesso um conjunto de pacotes de sua contraparte. Isso reduz a quantidade de pacotes a serem enviados, bem como o desperdício com cabeçalhos de camadas inferiores, tornando todo o processo de comunicação mais eficiente. O TCP implementa ainda algumas características do UDP, como a possibilidade de multiplexação do canal de comunicação entre várias aplicações em execução nos 3 Transmissões unicast são aquelas nas quais o transmissor possui apenas um receptor, ao contrário de transmissões multicast, nas quais há vários receptores. 9

24 (a) Rede com infraestrutura (b) Rede ad hoc Figura 2.1: Tipos de redes sem fios no padrão dispositivos usuários do mesmo meio, usando para isso o mesmo mecanismo de portas de comunicação usado pelo UDP. Outras funcionalidades presentes no UDP e no TCP são a verificação de integridade e o controle do tamanho dos pacotes de dados. A camada de Aplicação Provê funcionalidades análogas à camada de aplicação do modelo OSI, apenas tendo o trabalho adicional de emular, quando preciso, os serviços das camadas sessão e apresentação. A camada de interface com a rede Como é dito por vários autores, como [42], há um grande vazio nessa parte do modelo TCP/IP, pois não é dito muito sobre ela no modelo de referência, além da abstração bastante genérica de que ela deve ser capaz de se conectar ao meio físico de modo que seja possível transmitir e receber pacotes IP por meio dele. Esse protocolo não está definido no modelo TCP/IP e varia em função dos dispositivos e redes usados. Essa ausência de especificação é útil pois não deixou a especificação excessivamente atrelada a um tipo de dispositivo, então hoje temos dispositivos usando os protocolos da pilha TCP/IP em redes com cabos de cobre, fibra óptica, redes sem fios, etc. 2.2 Redes Sem Fios As redes sem fios no padrão podem ser divididas em dois modelos, as redes com infraestrutura e as redes ad hoc. As redes com infraestrutura possuem um dispositivo coordenador denominado Access Point (AP), que é o ponto central da rede, fazendo a comunicação entre os nós e podendo servir de gateway da rede para outras redes, incluindo a Internet. As redes sem fios ad hoc não possuem centralizador algum, e os dispositivos 10

25 se coordenam entre si, podendo um ou mais fazer o roteamento para outras redes ou para a Internet. Exemplos de redes com infraestrutura e ad hoc podem ser vistos na figura 2.1. A família de protocolos IEEE foi desenvolvida para como uma opção de camada de interface com a rede da pilha TCP/IP, especificando de modo detalhado o que falta nesse modelo e provendo serviços para que as camadas superiores possam operar sobre redes sem fios nesse padrão. Essa especificação engloba o que seria equivalente às camadas de enlace e física da pilha OSI, realizando assim a parte da tarefa a ser realizada pela porção inferior do modelo TCP/IP Divisão do Canal Por ser um meio com acesso por vários dispositivos ao mesmo tempo, é muito importante definir maneiras de permitir a divisão do canal, porque se dois ou mais nós da rede transmitirem ao mesmo tempo, haverá uma colisão e nenhuma das transmissões poderá ser corretamente decodificada pelo seu destinatário. Além disso, há alguns agravantes inerentes ao meio sem fios: A impossibilidade de se transmitir e detectar o que está sendo transmitido na rede ao mesmo tempo (as antenas ou transmitem ou recebem, em um dado momento), o problema do terminal exposto e o problema do terminal escondido, sendo estes dois últimos em função da topologia da rede em questão. A ideia mais básica que temos sobre como evitar colisões é a da conversa humana. Se duas ou mais pessoas encontram-se reunidas para conversar, espera-se que durante a fala de uma, as demais não a interrompam. Do mesmo modo, quando há um silêncio, duas ou mais pessoas que tenham algo a falar irão sentir-se livres para iniciar o assunto 4, e pode ocorrer de duas ou mais falarem ao mesmo tempo. Desse modo, houve uma colisão, então todas elas param 5 de falar, cada uma espera um tempo aleatório, e retoma a fala. Se houver nova colisão, o processo é retomado. Essa é a base do Carrier Sense Multiple Access (CSMA), um protocolo de controle de acesso ao meio feito para evitar colisões. CSMA O CSMA é um protocolo probabilístico, baseado no fato de que, se nada é captado na rede a probabilidade de nada ser transmitido no momento seguinte é muito superior à de nada ser transmitido no momento seguinte a um durante o qual uma transmissão esteja ocorrendo. Desse modo, os usuários do meio que têm algo a enviar ficam escutando a rede até nada ser transmitido, quando então poderá ser realizada sua própria transmissão. Existem três variantes do CSMA [8], a saber: CSMA P -persistente: Se um nó tem algo a transmitir e percebe silêncio na rede, ele possui uma probabilidade P de realizar sua transmissão, e 1 P de não realizála. Se ele não fizer a transmissão, o próximo slot de tempo será aguardado e na ocorrência do mesmo, caso haja silêncio na rede, o nó irá mais uma vez transmitir com probabilidade P, e assim sucessivamente; 4 Ignorando-se o uso de recursos não verbais de comunicação que podem ser usados para a sinalização da intenção de falar. 5 Nem todas as pessoas param, há quem continue falando para garantir que será a primeira pessoa a falar, mas presumindo pessoas com status semelhantes, o esperado é o comportamento descrito. 11

26 CSMA 1-persistente: É a versão do CSMA P -persistente com probabilidade de 100% de transmitir caso haja silêncio na rede; CSMA o-persistente: Um dos nós possui o papel de coordenador, e irá atribuir uma ordem que os nós devem seguir para transmitir. Assim, quando o meio estiver livre pela primeira vez, o primeiro da fila irá transmitir, e na próxima ocasião em que houver silêncio, o segundo da fila irá transmitir, desse modo formando um ciclo. O mecanismo de aguardar o próximo momento livre da rede implica em dois problemas, o do terminal exposto e o do terminal escondido [28], ilustrados nas figuras 2.2 e 2.3, respectivamente. Figura 2.2: Problema do terminal exposto. Durante a transmissão do nó A para o nó B, o nó C não pode transmitir para o nó D sob pena de gerar interferência no nó B. Diz-se que o nó C é um terminal exposto. O terminal é exposto quando ele possui algo para transmitir em um dado momento em que nem ele e nem o seu destinatário estão transmitindo ou recebendo nada, mas um nó adjacente está transmitindo algo, o que impede que a transmissão seja feita para não gerar uma colisão com o pacote que já está cruzando o meio naquele instante. Um terminal A é escondido quando ele está fora de alcance de um outro terminal B, mas ambos possuem um terceiro terminal C em seu alcance. Desse modo, se o terminal A estiver transmitindo para o terminal B, o terminal C ainda assim irá detectar o meio como livre e pode iniciar também uma transmissão para B, causando uma colisão. CSMA/CD Em um meio que permita a transmissão e a recepção ao mesmo tempo, como as redes com fios, é possível usar o CSMA with Collision Detection (CSMA/CD), uma variação do protocolo CSMA feita para detectar a colisão o quanto antes e desencadear um procedimento de recuperação. Se durante a transmissão um nó perceber uma colisão 6, ele continua a mesma só por tempo suficiente para que o causador da colisão 12

27 Figura 2.3: Problema do terminal escondido. Se não há transmissões, o nó A e o nó C detectam que o canal está livre e começam uma transmissão para o nó B em momentos próximos, gerando uma colisão. perceba a ocorrência da mesma, em seguida aguarda por um período que depende do número de colisões observadas antes, e tenta transmitir novamente [42]. CSMA/CA Em meios onde não é possível transmitir e captar dados simultaneamente, pode-se usar o CSMA with Collision Avoidance (CSMA/CA), uma versão melhorada do CSMA e que é diferente do CSMA/CD por evitar a colisão, em vez de corrigir uma que tenha ocorrido [28]. O CSMA/CA é usado nas redes , com uma Distributed Coordination Function (DCF), ou função distribuída de coordenação, em tradução livre, que permite, sem o uso de um nó centralizador, que os nós se organizem para evitar colisões [12]. Se um nó possui dados para transmitir, ele escuta o meio. Caso o mesmo esteja ocupado, o nó aguarda um tempo (backoff ) e tenta de novo, repetidamente, até encontrar o meio livre. Se o meio estiver livre, o nó permanece escutando por mais um tempo, conhecido como Distributed Inter Frame Space (DIFS), e se ao final do mesmo o silêncio ainda permanece, então a transmissão é feita. Após o final da transmissão, o nó destinatário aguarda um tempo conhecido como Short Inter Frame Space (SIFS), e envia uma confirmação de recebimento ao emissor (ACK). Se essa confirmação não for recebida, o emissor retransmite o pacote, sucessivas vezes, até que a confirmação seja recebida ou o limite de retransmissões seja atingido. Mecanismo RTS/CTS: Embora seja opcional, há um mecanismo complementar ao CSMA/CA para corrigir problemas como o do terminal escondido, denominado RTS/CTS, que na maior parte das vezes é implementado. Quando um nó possui dados para transmissão e o meio encontra-se livre, esse nó envia um pacote de solicitação de transmissão 6 A detecção da colisão é dependente do meio. No caso de redes Ethernet, por exemplo, é possível comparar os dados enviados com os que estão sendo recebidos. Caso os dois não sejam idênticos, uma colisão ocorreu. Isso não é possível nas redes , pois a antena usada só permite transmitir ou receber dados em um dado momento, não sendo possível realizar as duas operações ao mesmo tempo. 13

28 (Request To Send, RTS). Se o nó destinatário não estiver impedido de receber o pacote naquele instante, ele responde com um pacote de transmissão livre (Clear To Send, CTS), e o primeiro nó inicia a transmissão. Desse modo, os nós vizinhos perceberão ao menos um desses dois pacotes de controle, e saberão que nos próximos instantes não será possível transmitir sem gerar colisões [28]. Esse processo está ilustrado na figura 2.4. Figura 2.4: Uso de mensagens RTS e CTS para envio de dados em redes sem fios. Em função de todo esse controle para evitar colisões, bem como do custo de recuperação das colisões que ainda assim ocorrerão, é possível perceber como é onerosa uma transmissão sem fios. Dessa maneira, quanto menos transmissões forem usadas para transportar um determinado conjunto de dados, mais eficiente será o uso do canal Roteamento Em redes sem fios, quando há vários nós em um meio e nem todos estão diretamente conectados, é especialmente crítico permitir a existência de rotas entre aqueles dispositivos que não conseguem contato direto entre si. Há duas classes de protocolos para estabelecimento de rotas [8], a saber: Protocolos link-state: Em redes com infraestrutura, os nós centralizadores (roteadores) são responsáveis por manter tabelas de conectividade da rede, correlacionando quais nós estão conectados a quais outros nós, e repassar essas tabelas para outros nós roteadores. Desse modo, cada nó centralizador poderá calcular a melhor rota para um dado destino, e os nós que dependem daquele roteador precisam apenas encaminhar os seus pacotes para ele; Protocolos distance-vector: Em redes ad hoc, os nós mantêm tabelas correlacionando seus possíveis destinos ao custo total de transmissão para os mesmos e qual é o 14

29 primeiro passo do caminho até lá (o vizinho para o qual um pacote deve ser enviado caso aquele seja o destino final). Como o foco desse trabalho é nas redes mesh, serão aprofundados dois protocolos do tipo distance-vector, o AODV e o DSDV. AODV O protocolo ad hoc on-demand distance-vector (AODV), é uma técnica reativa para o problema de localizar rotas em redes ad hoc. Quando um nó precisa de uma rota para um dado destino, ele envia a todos os seus vizinhos uma requisição de conexão para o destino final. Seus vizinhos então repassam essa requisição, que será encaminhada até que um nó que conheça uma rota para aquele destino seja alcançado, respondendo no caminho inverso que possui aquela rota. Pode ser que várias rotas sejam descobertas assim, e o nó que gerou o pacote irá optar por aquela que envolva menos saltos na rede e iniciar a transmissão. Se não houver uma rota, isso será detectado quando o pacote de descoberta de rota exceder o seu tempo de vida (TTL, do inglês), ou seja, passar por mais nós do que um limite previamente estabelecido. Caso haja alguma mudança na rede que impeça a utilização de uma rota, o nó mais próximo a essa barreira irá retornar uma mensagem informando a situação, e o nó gerador do pacote irá então reiniciar todo o processo. Outra característica é que periodicamente os nós esvaziam suas tabelas, removendo de lá as rotas mais antigas e não utilizadas. DSDV O protocolo destination-sequenced distance-vector (DSDV), em contraste com o AODV, é um protocolo proativo, calculando rotas para todos os destinos possíveis antes de a mesma ser necessária. Ele faz uso de valores sequenciais para cada destino possível, como forma de controlar há quanto tempo as rotas foram criadas 7. No início da existência da rede e de tempos em tempos (mas a intervalos grandes de tempo), cada nó encaminha para seus vizinhos toda a sua tabela de roteamento, e frequentemente (a intervalos menores), atualizações parciais, que oneram menos a rede. A tabela contém os destinos possíveis, correlacionando-os com o próximo salto que leva a ele, o número de saltos usado para atingir o destino, o número de sequência para controle de idade da rota e o momento quando aquela rota foi estabelecida, como forma de controlar a idade da mesma. Comparação dos protocolos de roteamento Enquanto o protocolo reativo é vantajoso em situações de rede pouco usada, com tráfego intenso nas rotas criadas e pouco tráfego entre os demais nós, o protocolo proativo é interessante quando há tráfego esparso entre muitos nós da rede. Além disso, a abordagem proativa permite o envio mais rápido de um pacote quando for necessário, sem ter de aguardar o estabelecimento de uma rota. Por outro lado, a abordagem reativa garante sempre rotas muito novas, enquanto o uso de uma rota estabelecida previamente pode levar à tentativa de links não mais existentes. Assim, em redes muito dinâmicas, pode ser vantajoso usar a abordagem do AODV. 7 Rotas muito antigas podem estar desatualizadas, contando com o uso de nós que não estão mais na rede como caminho para chegar ao destino final. 15

30 2.2.3 Deficiências do Conforme já foi apontado, o protocolo induz um custo muito elevado para transmitir um pacote, já que é bastante oneroso acessar o meio sem fios de uma maneira que evite colisões. Além disso, há a questão do roteamento, que induz outro custo na comunicação sem fios, e ao mesmo tempo levanta a preocupação com o uso de rotas obsoletas, que não sejam capazes de entregar o pacote a seu destino final ou que o façam com desempenho abaixo do melhor possível (degradação de rota). Ao se usar o IEEE como parte da pilha TCP/IP, há ainda o problema dos cabeçalhos inseridos a cada camada, passando a formar uma fração significativa de tudo aquilo que está sendo transmitido. Esses são alguns dos problemas que este trabalho tenta melhorar. Overhead induzido pelas camadas de rede Figura 2.5: Overhead por cabeçalhos induzido pelas diversas camadas de rede [12]. Cada camada que é percorrida por um pacote, mais cabeçalhos de controle são inseridos para permitir que todos os dispositivos pelos quais esse pacote passa consigam tratar corretamente o seu envio, fazendo-o chegar a seu destino. Desse modo, há bem mais sendo transmitido pela rede do que apenas os dados do usuário, como pode ser visto na figura 2.5. Isso é especialmente crítico no caso de pacotes muito pequenos, pois o tamanho dos cabeçalhos passa a ser bastante significativo e gera impacto no desempenho da rede percebido pela aplicação (e pelo usuário, por consequência). Para uma transmissão UDP em uma rede sem fios no padrão IEEE (a ser discutido na próxima seção), é preciso considerar os seguintes cabeçalhos: 16

31 UDP Com 8 bytes de tamanho, é responsável por marcar as portas de origem e destino do pacote, seu tamanho e se está íntegro; IP Com 20 bytes, contém várias informações, de versão e tipo de dado trafegado a endereços de origem e destino; LLC e SNAP Somados, possuem 8 bytes, usados para permitir multiplexação e controle de fluxo dentro de uma sub-rede; MAC IEEE Possui 30 bytes, para controlar origem e destino dentro da rede local (desconsiderando origem inicial e destino final do pacote), sequenciamento, etc; SVQ É um trailer, ao invés de um cabeçalho. Com 4 bytes, permite verificar a integridade do quadro MAC enviado; PLCP Responsável por se comunicar de forma mais direta com o meio físico, com o preâmbulo para permitir sincronização e o cabeçalho em si para que as estações acordem o serviço fornecido, o sinal, etc [12]. Neste trabalho, sempre será usado o long preamble, de 144 bits, pois foi considerado um cenário de rede misto entre os padrões b e g. Sendo assim, 24 bytes são usados com esses cabeçalhos. Desse modo, para uma única transmissão de dados, independente de seu tamanho, é preciso também enviar 94 bytes apenas para realizar o controle sobre o que foi transmitido e permitir que seja possível que o pacote chegue ao seu destino. 2.3 Considerações Finais Uma vez conhecidos os ambientes de redes de dados e o funcionamento de uma rede sem fios, com ênfase nas dificuldades que existem em cada transmissão, por cabeçalhos em cada camada de rede e várias esperas para acessar o meio sem fio, o próximo passo é conhecer melhor o funcionamento de serviços similares à telefonia que funcionam sobre redes de dados, o que irá completaro referencial teórico para o problema estudado, e tornará possível então descrever as soluções adotadas. 17

32 Capítulo 3 Telefonia e VoIP Para falar em como melhorar a capacidade dos serviços de Voz sobre IP (VoIP) sobre redes sem fio para suportar mais usuários, é preciso antes construir um arcabouço de informações sobre o que é uma rede baseada em fluxo de pacotes, comunicação por voz sobre essas redes, a capacidade dessas redes e os conceitos necessários para entender toda essa base teórica. Empiricamente, a forma mais conhecida de comunicação por voz é a telefonia. Desse modo, na seção 3.1 falaremos de telefonia, um pouco sobre sua evolução, desde o início, quando havia apenas telefonia fixa, até o surgimento da telefonia móvel, também conhecida como telefonia celular. Em telefonia celular, será apresentado um histórico de suas gerações até os tempos atuais. Em seguida, na seção 3.2, será apresentado o conceito de Voz sobre IP VoIP, que une a telefonia às redes de dados apresentadas no capítulo 2. Esse tipo de comunicação será comparado à telefonia tradicional, e haverá uma descrição sobre como é possível integrar sistemas de Voz sobre IP com a rede de telefonia convencional. Haverá ainda uma exposição sobre as duas principais famílias de protocolos de comunicação que são usadas para construir canais de comunicação de voz sobre redes de dados. Por fim, na seção 3.3 serão discutidos os problemas encontrados no uso de redes de dados para prover serviços de voz em tempo real, o que deve ser considerado para atingir o primeiro objetivo específico traçado para este trabalho, de não degradar a qualidade das conversas sob a perspectiva do usuário do serviço. 3.1 Telefonia O ser humano moderno sempre apresentou a necessidade de se comunicar com outros iguais. Quando da presença de seu interlocutor, essa comunicação geralmente se dá por meio da fala e de gestos, e sua necessidade é suprida, sem que seja preciso usar artifícios externos a seu corpo. O problema da comunicação surge uma vez que os participantes de uma conversa composta por dois ou mais interlocutores não estejam a uma distância que permita o uso da voz e dos gestos. Antigamente, essa barreira era superada por meio da comunicação escrita, e os interlocutores se valiam de terceiros para entregar a mensagem. Nesse caso, havia a demora entre o envio de uma mensagem e sua chegada ao destinatário quando ela chegava. A comunicação escrita também não permitia que todos os aspectos da comu- 18

33 Figura 3.1: Dispositivo de conversa de voz composto por duas latas e um cordão. nicação humana fossem trabalhados, não sendo possível transmitir informações que são facilmente expressadas por meio de gestos e entonação de voz. Surge daí a necessidade do uso da voz mesmo quando os interlocutores não se encontram próximos o bastante para usá-la da maneira tradicional Histórico A comunicação por voz à distância surgiu com o uso de dispositivos mecânicos, tais como longos tubos ocos similares a canos, ou ainda dispositivos compostos por dois diafragmas conectados por algum tipo de fio ou corda, que transmitiria os impulsos mecânicos gerados pelo ar deslocado na fala de uma pessoa quando se encontrassem com o diafragma. Um exemplo desse tipo de dispositivo é o telefone de lata usado por crianças como brinquedo, que pode ser visto na figura 3.1. Esse tipo de aparelho não é prático para o uso a distâncias grandes, pois exige que cada par de interlocutores leve consigo metade de todo o aparato para que a comunicação funcione [42]. A evolução da comunicação à distância em tempo real se deu com o emprego de dispositivos elétricos, como o telégrafo, que usava textos humanos codificados, geralmente, em Morse. Embora esses dispositivos resolvessem o problema do atraso inerente às comunicações por carta, ainda não resolviam a falta de artifícios providos pela voz. A invenção do primeiro dispositivo eletromecânico conhecido como telefone ocorreu em 1876, quando Alexander Graham Bell mostrou ao público um dispositivo capaz de converter voz humana em sinais elétricos, transmiti-los por um fio e em seguida converter esses sinais em sons similares à voz originalmente enviada, sem introduzir atraso significativo no processo. Como o invento original exigia a existência de um fio entre cada par de possíveis interlocutores, ele era pouco prático. Por isso Bell fundou, em 1878, o primeiro escritório de telefonia, que permitia que um usuário ativasse o aparelho tirando-o do gancho para chamar um telefonista, para quem seria informado o usuário que deveria ser chamado. O telefonista então faria a conexão física entre os aparelhos dos dois usuários. Esse foi o embrião da Rede Pública de Telefonia Comutada, que é o foco da próxima subseção. 19

34 Figura 3.2: Arquitetura típica de uma rede de telefonia convencional. Com relação à comunicação móvel, tudo começou em 1861, quando Maxwell propôs uma teoria matemática para ondas eletromagnéticas. Tal teoria foi comprovada por Hertz em 1887, e colocada em prática por Marconi, que em 1895 construiu o primeiro radiotelégrafo. Com base no trabalho desenvolvido por esses inventores surgiu a comunicação móvel por voz, que será tratada na subseção Telefonia Fixa A Rede Pública de Telefonia Comutada (do inglês Public Switched Telephone Network, PSTN ), também conhecida como telefonia fixa, é uma rede administrada por operadoras de serviço telefônico e comutada por circuitos. Originalmente era composta por linhas analógicas e a rede era comutada manualmente, mas atualmente essa tecnologia é digital e a comutação é realizada de modo automático por dispositivos existentes nas próprias operadoras [42]. Por ter sido projetada para tráfego de voz, a PSTN possui algumas peculiaridades: Qualidade de serviço: Como o circuito de transmissão fica totalmente reservado para a conversa durante toda a duração da mesma (até durante períodos de silêncio mútuo), é garantido que haverá recursos para a transmissão da voz durante toda a conversa. Restrições à transmissão de dados: Como a transmissão de voz não necessita de uma grande quantidade de banda, a rede foi projetada para transmitir pequenas quantidades de dados por vez, apenas 64kbps, o que é pouco quando comparado às tecnologias de transmissão de dados às quais assinantes domésticos já têm acesso hoje. No Brasil, assim como na maioria dos países, sua arquitetura é composta basicamente por três elementos, ilustrados na figura 3.2. São eles: Centrais telefônicas locais, às quais estão conetados os aparelhos telefônicos de uma pequena região 20

35 Centrais telefônicas de comutação, às quais se ligam várias centrais locais de diversas pequenas regiões Centrais telefônicas de interconexão, responsáveis por interligar centrais de comutação de regiões maiores Telefonia Móvel O primeiro método para conversa por voz à longa distância sem o uso de fios de que se tem notícia é o uso de um radiotelefone de 2MHz desenvolvido pelo Departamento de Polícia de Detroit, que começou a ser usado em 1921 [24]. Em 1933 Armstrong evoluiu esse sistema, criando o famoso e até hoje usado FM, sigla em inglês para Modulação de Frequência. Esse sistema provia uma alta qualidade na transmissão e recepção de voz, mas permitia um número limitado de usuários, pois a faixa de frequências usadas pelo sistema era pequena. Esse problema foi resolvido com a divisão da rede de comunicação em células menores. Essa proposta de um sistema celular começou nos laboratórios Bell em 1947 com D. H. Ring. A divisão em células criou um novo problema: dada a natureza móvel dos usuários do sistema, era necessário que a transição de um usuário de uma célula a outra, quando o mesmo saísse da região de uma célula e entrasse na de outra, fosse transparente, sem que a conversa fosse interrompida e sem que o usuário devesse tomar qualquer atitude com relação a essa transição. Esse problema foi resolvido pela AT&T em 1970, com o sistema AMPS (Advanced Mobile Phone Service), que essa empresa começou a explorar comercialmente apenas em Primeira Geração A primeira geração foi marcada pelo uso de sinais analógicos para transmitir voz, bem como pela total falta de interoperabilidade entre os sistemas, já que cada país desenvolvido possuía um sistema diferente, como o NMT dos países escandinavos, o TACS britânico e o C-system alemão. Logo, se um usuário saísse de seu país de origem, seu dispositivo móvel provavelmente não funcionaria em seu país de destino. Em função disso, em 1982, a CEPT (Conference of European Posts and Telegraphs) formou um grupo de estudos denominado GSM (Groupe Speciale Mobile), com o intuito de criar uma infraestrutura de telefonia móvel pan-europeia. Sete anos mais tarde, a padronização do GSM foi transferida para o ETSI (Instituto Europeu de Padrões de Telecomunicações, em tradução livre), que em 1990 publicou a primeira versão do padrão GSM. Segunda Geração No início dos anos 1990 a segunda geração da telefonia móvel já estava a caminho, sendo que o primeiro indício veio com os testes iniciais do GSM, em 1991, quando teve seu nome modificado para Global System for Mobile communications, por razões mercadológicas. Esse sistema rapidamente chegou ao topo do mercado de comunicação móvel, e em setembro de 2009 estima-se que tenha atingido a marca de 4 bilhões de usuários no mundo [23]. O GSM será detalhado mais a fundo adiante nesse trabalho. 21

36 Em paralelo ao GSM, no Japão foi desenvolvida a tecnologia PDC (Personal Digital Communications), e na América do Norte foi lançado o D-AMPS, uma versão digital do padrão AMPS da primeira geração da telefonia móvel. O sistema D-AMPS seguiu evoluindo, provendo serviços até então novos, tais como mensagens de texto (SMS). Como as demandas dos usuários só cresciam, era necessário melhorar os padrões já existentes. Em 1993 os Estados Unidos aprovaram um novo padrão proposto pela Qualcomm, chamado CDMA (Code Division Multiple Access), que possui raízes militares. Em função disso, ele era por projeto bastante resistente a interferências. Na segunda geração de sistemas móveis o principal serviço provido permaneceu sendo a comunicação por voz, mas outros serviços puderam ser oferecidos, tais como as mensagens de texto, acesso de dados a baixas velocidades (até 9600bps), fax, identificação de chamadas, conferências entre múltiplos usuários, etc. Evolução da Segunda para a Terceira Geração O crescente uso da Internet teve um grande impacto na demanda por serviços de comunicação sem fio cada vez mais complexos. Porém, a taxa de transmissão de dados dos sistemas móveis era demasiado lenta para muitos serviços de Internet. Nesta época, o GSM e outras tecnologias de Segunda Geração iniciaram o desenvolvimento dos chamados sistemas móveis 2G+, ou 2.5G. Neste grupo, os sistemas mais importantes são o HSCSD e o GPRS. Há também o EDGE, um esforço para aumentar a taxa de transmissão do GPRS, que é considerado como um passo de transição para a Terceira Geração. Terceira Geração Tendo em vista a diversidade de sistemas 2G existentes (CDMA, TDMA, GSM), a próxima geração da telefonia móvel (chamada de 3G, abreviação de Terceira Geração) deveria prover convergência dos padrões 2G. Uma vez que o GPRS já introduziu serviços orientados a pacote, permitindo conectividade à Internet, as principais melhorias no 3G são taxas de transferência de dados maiores com a utilização de banda larga e a possibilidade de criação de vários serviços sobre a mesma arquitetura de rede, separando a criação de novos serviços da operação física da rede. No processo de padronização do 3G havia primeiramente projetos regionais, como com o ETSI na Europa e o ANSI na América do Norte. O início da padronização global do 3G ocorreu com o projeto International Mobile Telephony 2000 (IMT-2000) da ITU, um framework para posteriores tecnologias 3G, de forma a aumentar a convergência entre elas. O conceito do IMT-2000 inclui os seguintes aspectos: Acesso global e uniforme às redes móveis; Compatibilidade com a maioria dos sistemas 2G; Convergência entre a rede móvel e a rede fixa; Taxa de transmissão alta para comunicação de dados pela rede sem fio; Transferência de dados orientada a circuitos e orientada a pacotes; Introdução de aplicações multimídia. 22

37 Posteriormente, os dois padrões principais criados para ser compatíveis com o IMT foram o UMTS e o CDMA2000. O UMTS é uma evolução das redes GSM, e o CDMA2000 é uma evolução do CDMA, e ambos foram desenvolvidos em parcerias entre entidades ligadas às comunicações, sendo europeias no caso do UMTS e americanas e asiáticas, no caso do CDMA Observações Tanto no âmbito da PSTN usada para prover serviços de telefonia fixa quanto no das redes de telefonia móvel, o sistema foi sempre projetado para prover voz em primeiro lugar, e só com o advento das gerações mais recentes de telefonia celular houve a preocupação de prover serviços adicionais, como identificação de chamadas e transporte de dados. Desse modo, essas redes em tese sempre irão prover qualidade de serviço adequada para que duas ou mais pessoas se comuniquem usando voz, mesmo que para isso seja necessário reduzir a qualidade dos serviços adicionais. Essa não é a mesma realidade de redes de dados, nas quais os vários tipos de tráfego com destaque para os que consomem muitos recursos, como a transferência de arquivos disputam o canal, o que pode tornar inviável seu uso para comunicações que antes eram feitas usando-se comutação por circuitos. Assim, é preciso tomar alguns cuidados ao prover esse tipo de serviços em redes que não foram originalmente projetadas para isso, mas esse uso é possível, como pode ser provado pela existência do IP Multimedia System (IMS), desenvolvido pela 3GPP, que também desenvolveu o UMTS, para prover uma suíte de comunicações multimídia completa sobre redes de dados baseadas em IP. 3.2 VoIP É uma família de tecnologias de transmissão de voz usando redes de dados baseados no Protocolo de Internet (IP). Essas tecnologias podem envolver até mesmo técnicas para transmitir voz entre redes de dados e redes de telefonia convencional (PSTN e redes móveis), usando gateways como o Asterisk [31, 33]. A transmissão de voz sobre IP possui diversas implementações, algumas proprietárias e outras que usam protocolos e padrões abertos. Ela deve emular os passos relativos ao uso da telefonia convencional: 1. Discagem para outro usuário 2. Retorno do sistema ao usuário, informando que está chamando o outro usuário, ou ainda que o mesmo está indisponível (ocupado) 3. Informar ao usuário que ele está sendo chamado 4. Permitir o atendimento pelo usuário chamado 5. Possibilitar a conversa entre os usuários de uma ligação estabelecida 6. Sinalizar ao usuário que o seu interlocutor desligou a chamada ou que houve problemas na mesma (tom de ocupado) 23

38 Na implementação aberta baseada nos protocolos SIP e RTP (explicados em maior detalhe em 3.2.4), essa emulação se dá da seguinte forma: O protocolo SIP é responsável pelas sinalizações, nos passos 1, 2, 3, 4 e 6. O protocolo RTP trata da transmissão dos dados da ligação (voz e eventualmente vídeo), no passo 5. Para que a transmissão de áudio sobre redes IP ocorra, primeiramente esse áudio deve ser transformado para o formato digital e comprimido antes do envio. Essa compressão é feita por um dispositivo chamado codec. Segundo Bordim [7], o codec comprime os dados, eliminando informações redundantes e previsíveis. Os dados passam por uma conversão analógico-digital, compreendendo a amostragem do sinal. Existem diversas implementações de codecs, livres e proprietárias, tanto para áudio quanto para vídeo Tipos de dispositivos VoIP A comunicação via VoIP pode ocorrer principalmente de três maneiras: Com softphones, com um adaptador para telefonia analógica e com dispositivos VoIP dedicados. Softphones São softwares executados sobre uma plataforma computacional genérica (não-dedicada) e se comunicam via rede de dados, servindo para conversas de voz com ou sem vídeo. Dispositivos VoIP dedicados São aparelhos telefônicos que se conectam a uma rede de dados em vez de usar a rede telefônica tradicional. Adaptadores para telefonia analógica São dispositivos que se conectam via rede de dados para realizar e receber chamadas, mas possuem uma saída típica da telefonia convencional, como RJ-11, e usam essa saída para prover serviço a aparelhos de telefonia convencional. Desse modo, os usuários dos aparelhos telefônicos não podem distinguir a rede convencional da rede VoIP que estão utilizando. Existem diversos frameworks disponíveis para implementação do VoIP. Além de uma variedade de protocolos proprietários com esse propósito, existem duas grandes famílias de protocolos abertos para a área de multimídia sobre IP, que podem ser utilizados para a implementação do VoIP: H.323 (padrão ITU-T) e SIP (padrão IETF), que serão mais detalhados nas subseções seguintes Família de protocolos H.323 A família H.323 é padronizada pela ITU-T (ITU Telecommunication Standardization Sector), uma organização responsável por coordenar padronizações relacionadas a telecomunicações, em parceria com a ITU (International Telecommunication Union). O framework para protocolos de sinalização H.323 é o padrão internacional para toda sinalização de telefonia sobre a rede de pacotes (não apenas a Internet), podendo ser usada também em redes X.25, ATM, ou qualquer outra [18]. Segundo [14], o H.323 envolve várias outras especificações ITU para prover serviços específicos. Os componentes sob a arquitetura H.323 são terminais, gateways, gatekeepers e unidades de controle multiponto (MCU, da sigla em inglês). 24

39 Figura 3.3: Visão de uma arquitetura H.323 típica [43] Um terminal representa o dispositivo na ponta de toda conexão. Ele deve prover comunicação em tempo real com outro terminal H.323, um gateway ou um MCU. Esta comunicação consiste de uma combinação qualquer de voz, dados e vídeo. Gateways estabalecem a conexão entre os terminais na rede H.323 e com os terminais pertencentes a redes com pilhas de protocolo diferentes, como a rede PSTN tradicional ou agentes de usuário SIP. Gatekeepers são responsáveis pela tradução entre números de telefone e endereços IP. Eles também gerenciam a banda disponível e provêem um mecanismo para registro e autenticação de terminais. Além disso, eles provêem serviços de transferência e redirecionamento de chamadas, espera de chamadas, serviço de identificação de nomes, entre outros. O MCU cuida do estabelecimento de conferências multiponto. Um MCU consiste obrigatoriamente em um Controle Multiponto, para sinalização de chamadas e controle de conferência, e opcionalmente em um Processador Multiponto, para qualquer processamento necessário do stream de mídia. O H.323 provê controle e sinalização de chamadas, processamento de áudio, processamento de vídeo, conferências (de voz, vídeo e/ou dados), transporte de mídia (através do uso do RTP/RTCP, também utilizado na família SIP), e serviços complementares de chamadas fornecidos pelos gatekeepers. A desvantagem do H.323 é que se trata de uma estrutura complexa demais para o VoIP, em função de seu suporte a outras mídias, como dados e vídeo, e algumas pessoas imaginavam motivos para o H.323 ser necessário para o VoIP, dadas as suas raízes na telefonia e a quantidade elevada de potência necessária para manter a rede telefônica [18] Família de protocolos SIP A arquitetura SIP (Session Initiation Protocol) é padronizada pela IETF (Internet Engineering Task Force), e foi projetada para criar sessões entre dois usuários e para ser um componente modular e flexível da arquitetura da Internet, baseada em IP. O protocolo SIP em si está localizado na camada de aplicação, e se utiliza de outros protocolos para 25

40 Figura 3.4: Visão de uma arquitetura mista com SIP e PSTN [40] cuidar do fluxo de mídia, construindo uma arquitetura multimídia completa. Apesar dessas características voltadas a redes de dados, a arquitetura SIP suporta também conversas entre dispositivos IP e outros que estejam na PSTN, como exemplificado na figura 3.4. De acordo com Dong [14], através do SIP é possível estabelecer, modificar e terminar sessões multimídia, provendo chamadas telefônicas IP. O SIP também consegue convidar participantes a sessões já existentes, criando conferências multimídia. Um tipo de mídia pode ser adicionado ou removido de uma sessão existente. Ele também suporta, de forma transparente, mapeamento de nomes (URIs) e serviços de redireção, que auxilia no suporte à mobilidade de usuários eles podem manter um único identificador externo de outro usuário, independente da rede em que estejam. A arquitetura SIP é cliente-servidor por natureza, como esperado, mas com adaptações para a natureza ponto-a-ponto da telefonia. Os componentes básicos SIP são o agente de usuário (o dispositivo na ponta da conexão), os servidores intermediários (que podem ser servidores proxy ou servidores de redireção) e o registrar [18]. Os agentes de usuário podem ser clientes (UAC, User Agent Client), quando enviam requisições SIP, ou servidores (UAS, User Agent Server), quando as recebem. Os servidores proxy repassam requisições SIP do agente de usuário para o próximo servidor ou agente de usuário, mantendo informações sobre as contas dos agentes de usuário. Os servidores de redireção respondem às requisições de clientes, informando-os o endereço do servidor requisitado. O registrar SIP guarda informação sobre agentes de usuário, tais como sua localização. 26

41 Figura 3.5: Visão simplificada do estabelecimento de uma chamada SIP Esta informação não é mantida ou acessada pelo SIP, mas por um serviço de localização em separado que ainda faz parte do framework SIP. Desta forma, o SIP é flexível o suficiente para suportar requisições independentes do estado da ligação, além de ter liberdade de método de localização de usuários e componentes SIP. Na figura 3.5 temos uma visão simplificada do estabelecimento de chamadas no SIP. Os seguintes passos são tomados: 1. O agente de usuário informa que o usuário X no domínio A deseja chamar o usuário Y no domínio B. 2. O servidor proxy de A pergunta ao servidor de redireção qual servidor proxy recebe requisições para o domínio B. 3. O servidor de redireção responde com o endereço do servidor proxy responsável pelo domínio B. 4. Envia a requisição ao servidor proxy do domínio B. 5. O servidor proxy de B pergunta ao registrar responsável por B qual o endereço IP do usuário Y. 6. O registrar de B responde com o IP de Y. 7. O servidor proxy de B envia a requisição para Y. 8. Resposta de Y. Após o início da sessão, os dados multimídia são enviados diretamente de um User Agent (UA) ao outro, sem a necessidade de passar pelos servidores proxy (rota mostrada em verde). Porém, quaisquer mensagens de controle de sessão devem passar novamente pelos servidores proxy, mas sem efetuar novamente as consultas ao servidor de redireção e ao registrar. O SIP trabalha com cinco aspectos relacionados ao estabelecimento e término de comunicações multimídia: 27

42 Localização do usuário: determinação do sistema-fim a ser usado para comunicação. Disponibilidade do usuário: determinação se o usuário chamado deseja participar da conversa. Capacidade do usuário: Determinação do tipo de mídia e dos parâmetros de mídia a serem utilizados. Estabelecimento de sessão: estabelecimento dos parâmetros da sessão e início da sessão. Gerenciamento de sessão: transferência e término de sessões, modificação de parâmetros da sessão e requisição de serviços Protocolos VoIP Na seção vimos que a arquitetura SIP é composta não somente pelo protocolo SIP, mas por vários outros protocolos associados. Alguns desses protocolos também são usados pela família H.323, como o RTP, o RTCP e o SRTP, e nos itens seguintes há uma breve explicação sobre o que fazem alguns dos principais protocolos ligados às aplicações VoIP. SIP De acordo com [7], o SIP (Session Initiation Protocol) é um protocolo de camada de aplicação, utilizado para estabelecer chamadas e conferências através de redes via IP. O protocolo SIP é um padrão da IETF (Internet Engineering Task Force). Sua última versão, chamada SIPv2, foi apresentada em 2002 como RFC 3261 [38]. O SIP é um protocolo baseado em texto, que utiliza o modelo requisição-resposta, similar ao HTTP, para iniciar sessões de comunicação interativa entre usuários. Sua rápida adoção pode estar relacionada à sua simplicidade, pois possui apenas seis métodos de requisição, definidos em [38]. REGISTER: usado por um agente de usuário (ou UA, User Agent) para notificar o seu IP atual ao servidor, e as URLs nas quais ele recebe chamadas. INVITE: usado para chamar outro agente de usuário, para iniciar uma conexão. ACK: confirma o recebimento da resposta, ao receber uma resposta que tenha código igual a 2xx. CANCEL: termina um pedido pendente. BYE: termina uma sessão estabelecida entre dois agentes de usuário. OPTIONS: pede informações sobre a capacidade do outro UA, sem estabelecer uma conexão. Os códigos numéricos possíveis para as respostas, de acordo com a especificação, são: Provisional (1xx): pedido recebido e sendo processado. Normalmente usado para responder mensagens INVITE. 28

43 SIPS Success (2xx): a ação foi recebida, entendida e aceita com sucesso. Redirection (3xx): mais ações precisam ser tomadas para completar o pedido. Client Error (4xx): o pedido contém sintaxe errada ou não pode ser atendido neste servidor. Server Error (5xx): o servidor falhou em atender um pedido aparentemente válido. Global Failure (6xx): o pedido não pode ser atendido por qualquer servidor. De acordo com a RFC 3261 [38], o SIP define dois tipos de URI possíveis para um usuário: URI SIP e URI SIPS. Uma URI SIP é uma identidade SIP, normalmente contendo um nome de usuário e um host (domínio), por exemplo, sip:alice@example.com. Uma URI SIPS funciona da mesma forma que uma URI SIP, porém iniciando com sips: ao invés de sip:. Conforme a especificação definida na RFC 5630 [4] da IETF, ao usar uma URI SIPS a rede deve garantir que um transporte seguro e criptografado será usado para transmitir as mensagens SIP. O protocolo determina que o TLS (cuja especificação pode ser encontrada em [13]) seja usado para transmitir as mensagens do transmissor para o domínio do receptor. O último salto, do domínio do receptor para o receptor, pode ser feito com algum outro mecanismo de segurança, porém deve ser seguro. SDP O SDP (Session Description Protocol) é um formato para descrever parâmetros de inicialização de streams de mídia. Assim como o SIP, este protocolo baseado em texto ASCII. O SDP é padronizado pela RFC 4566 [19]. Embora o SDP não precise ser implementado em conjunto com o SIP, normalmente ele é usado para complementar suas funcionalidades. As mensagens SIP utilizadas para criar sessões (mais especificamente a requisição INVITE e a sua resposta associada) carregam descrições de sessão que permitem que os participantes entrem em acordo sobre um conjunto de tipos de mídia compatíveis. Essas descrições de sessão são normalmente formatadas utilizando SDP. Uma descrição de sessão SDP inclui o nome e propósito da sessão, horários em que a sessão estará ativa (se for o caso), o tipo de mídia utilizado na sessão (vídeo, áudio etc.), o protocolo de transporte usado (RTP/UDP/IP, H.320, entre outros), o formato da mídia (codec utilizado, taxa de amostragem) e outras informações necessárias para receber a mídia, como endereços e portas. O SDP também pode conter informações de limitação de recursos (por exemplo, banda máxima disponível para a sessão), ou mesmo informações de contato da pessoa responsável pela sessão, se necessário. RTP Segundo [7], o RTP (Real-time Transport Protocol) é um protocolo que oferece funções de transporte de rede fim-a-fim direcionadas para aplicações que transmitem fluxos de dados 29

44 em tempo real, como áudio, vídeo e dados de simulações, por meio de serviços de rede unicast e multicast. O protocolo é especificado pelo padrão RFC 3550 ([39]), da IETF, podendo ser usado tanto no modelo SIP quanto no H.323. A especificação determina que o RTP não garante reserva de recursos ou QoS (Quality of Service) para serviços em tempo-real. Ela também define o uso de um protocolo de controle adicional (RTCP, do qual falaremos em seguida) para permitir o monitoramento da entrega de dados de forma escalável em redes multicast e oferecer funcionalidades mínimas de controle e identificação. Apesar de ser um protocolo com funções de transporte para serviços específicos, segundo [39], o RTP e o RTCP são feitos para serem independentes da camada de transporte e das outras camadas abaixo deles, ou seja, ele pode ser usado em conjunto com o UDP ou qualquer outro protocolo da camada de transporte. Uma vez que ele é normalmente implementado em conjunto com o UDP, o RTP provê formas de efetuar a detecção de perda de pacotes e a sincronização entre os agentes envolvidos. Também contém informações sobre o tipo de payload (dados de áudio ou vídeo, codec utilizado, taxa de amostragem, número de canais) para que a decodificação seja feita corretamente. Ao fazer uso do RTP para transportar um payload de voz, é preciso considerar que ele precisa de 12 bytes de cabeçalhos, de modo que o exemplo de transmissão visto ao final da seção 2.1 do capítulo 2 usaria um total de 106 bytes apenas com cabeçalhos. No caso de se usar um codec como o ilbc [32], que envia 38 bytes a cada 20 milissegundos, aproximadamente dois terços de todo o volume trafegado serão compostos por cabeçalhos, um overhead considerável. RTCP O RTCP (RTP Control Protocol), conforme definido na RFC 3550 [39], é usado em conjunto com o RTP para a transmissão de áudio e vídeo em tempo real, como dito no item anterior. Segundo [7], o protocolo é baseado na transmissão periódica de pacotes de controle a todos os articipantes de uma sessão RTP, usando o mesmo mecanismo de distribuição dos pacotes de dados. Esse protocolo também é usado em ambos os frameworks de VoIP explicados na seção 3.2. A especificação define que sua função primária é prover feedback de QoS dos dados RTP através de relatórios, que são enviados tanto pelo transmissor quanto pelo receptor. O feedback pode ser especialmente útil para o controle de codificações adaptativas, embora experimentos com IP multicasting tenham se mostrado fundamentais para obter as informações de retorno dos receptores para diagnosticar falhas na distribuição. [7]. Além disso, o RTCP provê um nome canônico (CNAME) para cada fonte RTP e permite saber quantos participantes estão na sessão. Outra função opcional do RTCP é prover informações mínimas de controle de sessão. SRTP A RFC 3711 [5] define o protocolo SRTP (Secure Real-time Transport Protocol). De acordo com a especificação, o protocolo provê um framework para acrescentar criptografia e autenticação de mensagens a fluxos RTP e RTCP (3.2.4 e 3.2.4). Ele é seguro para 30

45 aplicações RTP unicast e multicast, e foi feito para prover alto throughput e baixa expansão do tamanho do pacote. A especificação do protocolo define algumas transformações criptográficas padrão para suas premissas: Para a criptografia, o padrão define apenas o algoritmo AES, em duas versões diferentes: Counter Mode (conforme [30]) e F8 Mode (conforme [1]). As duas versões utilizam AES com chave de 128 bits e salt de 112 bits [3]. O uso de um algoritmo de criptografia é opcional na transmissão SRTP, podendo este ser desligado. Para a autenticação de mensagens é usado o algoritmo HMAC-SHA1 (conforme [26]), com uma tag de autenticação de 80 ou 32 bits [3]. A autenticação de mensagens é obrigatória. Além disso, o SRTP utiliza um algoritmo de derivação de chave, para trocá-la de tempos em tempos de acordo com a chave mestra. O algoritmo está descrito em [5]. A RFC 3711 define que, para utilizar outros algoritmos com o SRTP, uma RFC deve ser publicada especificando o uso do algoritmo com SRTP e SRTCP, e possíveis problemas a respeito das interações do algoritmo com outros aspectos do SRTP. O documento [3] define que qualquer especificação para um novo algoritmo criptográfico para o SRTP deve ser registrada na IANA (Internet Assigned Numbers Authority). Segundo [40], a chave mestra do SRTP é passada de um agente ao outro fora de banda, via SDP. Como vimos em 3.2.4, o SDP é um protocolo baseado em texto, sendo integrado às mensagens SIP de início de sessão (INVITE) quando usado na família SIP. Isso torna a chave vulnerável, se não for aplicada alguma proteção ao SIP, caso o atacante esteja escutando a rede desde antes do início da sessão. 3.3 Problemas de qualidade de serviço em VoIP A qualidade de serviço (normalmente abreviada como QoS, do inglês Quality of Service) é fundamental para a operação de uma rede VoIP. Apesar do menor custo, se o VoIP não puder apresentar a mesma qualidade da rede telefônica comum no estabelecimento de chamadas e na transmissão de voz, então ele agregará pouco valor. A implementação de diversas medidas de segurança pode degradar a qualidade do serviço, provocando atrasos na transmissão de voz, bloqueio de chamadas pelos firewalls ou variação no atraso (jitter), que torna a conversa ininteligível quando atinge um certo ponto [27]. Devido à baixa tolerância do VoIP a atrasos e perdas de pacote, muitas medidas de segurança implementadas em redes de dados tradicionais não são aplicáveis para VoIP. Os principais problemas associados ao VoIP são mostrados a seguir Latência ou Delay A latência se refere ao tempo que a voz leva para ir da origem até o destino. Idealmente, a latência deve ser a menor possível, mas o ITU-T define limites de latência para os quais a conversa permanece em uma qualidade aceitável 150ms para tráfego unidirecional (correspondente ao atraso comum nas redes PSTN dos Estados Unidos), e 400ms para ligações internacionais. 31

46 Considerando um tempo de 1 30ms para codificação da voz e 100ms no pior caso para o tempo de transmissão (na transmissão intercontinental é possível chegar a atrasos maiores, mas normalmente o atraso é menor), temos aproximadamente 20 50ms para filas e implementações de segurança. Cada nó na rede introduz um atraso adicional com as filas e o tempo de processamento. Além disso, pacotes maiores tendem a causar congestão de banda, aumentando a latência Jitter O jitter se refere a atrasos não uniformes entre pacotes, ocorrendo normalmente em situações onde a banda disponível é pequena, e é um dos problemas que mais degradam a qualidade da ligação. A ocorrência de jitter pode fazer com que pacotes cheguem ao receptor e sejam processados fora de sequência e, uma vez que usamos UDP para o transporte de pacotes RTP, esses problemas não são resolvidos pela camada de transporte. Embora o RTP permita o reordenamento dos pacotes utilizando os campos de número de sequência e de temporização, a reorganização dos pacotes não é trivial, e é muitas vezes inviabilizada pelo fato do VoIP ser uma aplicação de tempo real. Quando o jitter é alto, os pacotes chegam ao receptor em rajadas. Embora o uso de buffers auxilie na diminuição do efeito do jitter, muitas vezes a variação ultrapassa o limite dos 150ms, inviabilizando o seu uso. Outra possibilidade de diminuição de jitter é o uso de roteadores, firewalls e outros elementos de rede que suportem QoS, o que não acontece em grande parte das redes de Internet. Em geral, o uso de dispositivos que suportem QoS e de algoritmos de segurança que aproveitem a banda disponível eficientemente (sem aumentar muito o tamanho do pacote) são as formas de obter atrasos de pacote mais uniformes em uma rede VoIP Perda de pacotes O VoIP tem pouca tolerância a perdas de pacotes. As perdas podem resultar de latência excessiva, jitter ou mesmo de pacotes que não chegam nunca ao seu destino. Como o VoIP utiliza UDP para tráfego de voz, a camada de transporte não garante a entrega de pacotes. Porém, as restrições de tempo não permitem que um protocolo confiável como o TCP seja usado para trafegar mídia. Como a perda de um pacote utilizando a estratégia de agregação de pacotes, apresentada na seção 4, é muito mais prejudicial que a perda de um pacote comum RTP, esse problema deve ser observado. Outro problema é que, em geral, a perda de pacotes não ocorre de forma isolada, apenas com um pacote. Estudos feitos pela TIA (Telecommunications Industry Association) mostram que a satisfação dos usuários com o serviço cai drasticamente quando a latência ultrapassa a marca de 150ms, e mesmo quando se mantém abaixo disso, uma perda de 5% dos pacotes faz com que a qualidade de serviço apresentada fique abaixo da rede telefônica tradicional. Para codecs de baixa qualidade de transmissão (8kbps), a perda de 2% dos pacotes já degrada a transmissão consideravelmente. O estudo mostrou que maiores taxas de compressão de voz resultam em maior sensitividade à perda de pacotes. A figura 3.6 ilustra essa situação. 1 Como definido pelo ITU-T em [22], a Mean Opinion score (MOS) é a média das notas dadas por usuários a uma determinada conexão de comunicação por voz, com valores entre 1 (pior) e 5 (melhor). 32

47 Figura 3.6: Qualidade de alguns CODECs de áudio em função da quantidade de pacotes descartados, de acordo com a percepção de usuários em testes 1. No caso do ilbc [2], até 5% de perdas são toleráveis, e a partir de 10% a qualidade é péssima [32]. 3.4 Considerações Finais Conhecendo o funcionamento de redes de voz sobre IP, suas limitações e requisitos da rede subjacente, é fácil perceber que as dificuldades impostas pelos cabeçalhos e esperas em redes sem fios são ainda mais significativas nesse tipo de ambiente, pois VoIP em geral tem pacotes pequenos e restrições grandes de esperas. Por esse motivo, no próximo capítulo serão estudadas técnicas de agregação de pacotes, que visam reduzir o overhead relativo a cada transmissão, tornando o uso da rede mais eficiente. 33

48 Capítulo 4 Agregação de Pacotes A agregação de pacotes é o foco de nossa proposta de melhoria para comunicação VoIP em redes sem fios, em função do overhead induzido por cabeçalhos, tempos de espera e colisões apontado no capítulo 2. Portanto, neste capítulo essa técnica será apresentada de maneira genérica. Na seção 4.1 serão descritas as características fundamentais da agregação de pacotes. Em seguida, na seção 4.2, será realizada uma revisão do estado da arte dessa técnica, para que seja aberto caminho para a nova proposta nessa área. 4.1 Agregação Básica Em geral, os pacotes trocados entre dois dispositivos que participam em uma conversa VoIP são muitos e bastante pequenos. O codec ilbc [32], por exemplo, envia 38 bytes a cada 20 milissegundos, sendo que o tamanho limite do frame Ethernet é de 1500 bytes. Isso significa um uso de menos de 5% da capacidade de um pacote. Considerando que para enviar vários pacotes pequenos, em vez de poucos pacotes grandes em redes sem fio existem muitos custos, como visto no capítulo 2, conclui-se que a comunicação VoIP em redes sem fios é bastante onerosa. Considerando como objeto de estudo as redes sem fio, sobre as quais a comunicação móvel atualmente é construída, o foco será nesse tipo de rede, mesmo que a agregação também possa beneficiar redes cabeadas. No âmbito das redes sem fios, é possível vislumbrar dois problemas grandes na troca de muitos pacotes pequenos como no caso do VoIP, a saber: 1. Para cada pacote enviado, são inseridos vários cabeçalhos, relativos às diversas camadas de rede existentes, sendo que o tamanho desses cabeçalhos não é desprezível no caso de pacotes pequenos como os de VoIP [42]. 2. A cada transmissão de pacote em uma rede sem fio o emissor deve cuidar para não gerar colisões, bem como retransmitir pacotes que tenham sido perdidos em funções de colisões ocorridas. Para evitar as colisões, são inseridas diversas esperas na comunicação, sendo que para cada envio há uma espera [28]. Em função desses problemas, convém reduzir ao mínimo a quantidade de pacotes trafegados quando roteando diversos diálogos VoIP. Para minimizar a quantidade de pacotes 34

49 Figura 4.1: Topologia de rede composta por duas sub-redes, A e B, conectadas por roteadores. Os computadores participarão de diálogos VoIP que serão transmitidas por meio dos roteadores. enviados, foi elaborada a técnica de Agregação de Pacotes, visando à maximização da taxa de pacotes enviados por unidade de tempo. Essa técnica, que por reduzir o número de pacotes enviados pode aumentar o número de sessões VoIP abertas em uma rede, consiste em cada nó intermediário reter os pacotes recebidos por um tempo, aguardando outros pacotes que possam ter como próximo pulo o mesmo nó, para enviá-los todos de uma vez, ou ainda reter vários pacotes que tenham o mesmo destino final 1. Isso gera economia de envios e de banda desperdiçada com cabeçalhos redundantes e esperas. Na aplicação desse método é necessário determinar e observar o tempo máximo durante o qual um pacote pode ser retido, para não induzir efeitos indesejáveis nas conversas, tais como jitter e delay altos. um roteador intermediário pode aumentar a chance de aplicar a agregação [...] se aguardar pela chegada de mais pacotes VoIP. Entretanto, tal espera pode aumentar o atraso gerado pelo enfileiramento em cada salto, o que pode violar o atraso ponta a ponta tolerável por uma aplicação VoIP. Portanto, a arquitetura deve considerar o atraso máximo ponto a ponto (D app ) como uma questão chave. Por exemplo, na telefonia móvel, D app = 150ms, Hasegawa et al. (2009). 1 Nesse detalhe reside a diferença entre agregação a cada salto e agregação fim a fim, pois a primeira não espera que existam pacotes suficientes com mesma origem e destino para que a agregação contribua, então agrega a cada pulo do pacote. No segundo caso, é esperado que haja pacotes que cumpram esses requisitos, então eles são agregados na origem e só são separados quando já chegaram ao destino. 35

50 Figura 4.2: Representação de vários pacotes sendo agregados em um só, com a adição de cabeçalhos extras para controlar o início dos pacotes. Além do temporizador, outra situação que dispararia o envio do pacote ocorreria ao se atingir o limite do tamanho do frame Ethernet, para evitar a fragmentação dos pacotes nas camadas inferiores [42]. Por exemplo, na figura 4.1, supondo que haja uma conversa VoIP entre A1 e B1, outra entre A2 e B2 e ainda outra entre A3 e B3, teríamos os roteadores A e B aplicando a agregação da seguinte maneira: A retém os pacotes de A1, A2 e A3 até que o tempo T wait expire ou que o tamanho dos dados para envio seja suficiente para encher um frame Ethernet sem fragmentação, e B procede de maneira similar. Assim, o número de transmissões entre A e B seria reduzido, a grosso modo, a 1 do que seria necessário sem aplicar 3 a técnica, supondo que as três conversas perdurem durante todo o tempo de medição. Um outro exemplo seria visto caso o roteador C agregasse vários pacotes destinados de A a B, para encaminhá-los todos de uma só vez, e também tivesse comportamento semelhante no sentido inverso da comunicação. A agregação de pacotes se deve ao fato de que em conversas VoIP há um fluxo constante de pacotes entre dois nós determinados na rede (pode ser entre mais nós, caso seja admitida a existência de conferências via VoIP, o que não será tratado neste trabalho). Desconsiderando diferenças entre os métodos, geralmente o efeito obtido é similar ao representado na figura Revisão do Estado da Arte Aqui serão apontadas propostas de diversos autores na área de agregação de pacotes, incluindo o tipo de cenário ao qual cada técnica se aplica. Todos os valores aqui apontados foram extraídos das obras referenciadas. 36

51 4.2.1 Data Funneling Esse método proposto por Petrović et al. [35] trata não apenas da agregação de pacotes, mas também do roteamento dos mesmos e de compressão dos dados. Para isso, ele passa por uma fase de setup antes de começar com a transmissão dos dados propriamente dita. Quando do roteamento de pacotes, o processo é similar ao fisheye state routing [34]. Contexto Esse método foi proposto no âmbito de redes de sensores, que têm de economizar ao máximo a energia de suas baterias, reduzindo o número de transmissões, já que a parte de rede é a que mais consome bateria nesses dispositivos. No caso dessa proposta, não há foco em segurança, mas apenas em agregar, comprimir e rotear os pacotes. No roteamento há uma observação interessante: uma vez que um sensor esteja captando dados do ambiente, ele sempre terá como destino para aqueles dados um único atuador por um dado período de tempo. Além disso, o fato de não haver mudanças nos destinos dos pacotes na rede naquele período facilita a elaboração de um único caminho na rede, bem como a agregação. Setup Antes de ser iniciada a troca de dados é necessário configurar alguns parâmetros na rede, para que cada sensor saiba quando enviar um pacote agregado e qual será o próximo nó no roteamento. Para isso são seguidos os seguintes passos: 1. O atuador divide sua área de interesse (os sensores que se reportam a ele) em cubóides, subconjuntos desses sensores, e essa divisão pode ser por região física ou sala, por exemplo; 2. Para cada cubóide, será feita uma inundação com pacotes com o número de saltos até o atuador. O atuador enviará pacotes com custo zero, que serão reenviados pelos sensores com custo incrementado em um a cada salto; 3. Cada sensor armazenará o custo, em saltos, para chegar ao atuador; 4. Quando um pacote chegar à região de interesse, o primeiro nó a receber o pacote se intitulará nó de borda ; 5. O nó de borda continuará a inundação de pacotes em sua região, mas com versões modificadas dos mesmos. Os novos pacotes terão o custo do nó de borda para atingir o atuador e o custo para atingir aquele nó de borda (já que um mesmo sensor pode ter mais de um nó de borda). O custo para atingir o nó de borda é incrementado a cada novo salto; 6. Todos os nós de uma região receberão os pacotes modificados provenientes de todos os nós de borda, e baseados no custo de cada nó de borda para atingir o atuador correspondente, poderão calcular, a cada ciclo, para qual nó de borda direcionar seu pacote de dados, visando ao roteamento e à agregação. 37

52 Figura 4.3: Exemplo de topologia para Data Funneling [35] Troca de dados 1. Quando um sensor possui dados para enviar ao atuador, ele usa os dados de todos os nós de borda que possui, junto com informações sobre o tempo atual, para determinar para qual nó de borda direcionar o pacote naquele momento; 2. Cada sensor aguardará um tempo inversamente proporcional à sua distância do nó de borda para enviar o pacote. Esse tempo é usado para receber pacotes de nós mais distantes e agregá-los ao seu próprio; 3. Ao longo do caminho do nó até o nó de borda, um pacote será agregado aos demais presentes nos nós pelos quais ele passou; 4. O nó de borda recebe todos os pacotes de sua região e os agrega, enviando um só pacote em direção ao atuador. Compressão No caso das redes de sensores para as quais esse algoritmo foi projetado, os dados coletados geralmente são pequenos, podendo haver muita repetição nas leituras realizadas pelos vários sensores. Em função disso, é proposta uma compressão que usa a ordenação dos pacotes enviados para passar dados sobre pacotes que poderão ser então suprimidos. Além disso, é possível suprimir as leituras repetidas, atribuindo a mesma leitura a vários sensores diferentes. Essa compressão é chamada pelos autores de Compressão por Ordenação. No ambiente VoIP essa compressão não é útil, pois o MTU das redes IP não é grande o bastante para permitir que pacotes suficientes sejam agregados e sua ordem seja sufi- 38

53 ciente para inferir um ou mais pacotes VoIP suprimidos. Desse modo, no algoritmo data funneling, os resultados relativos à compressão proposta serão desconsiderados. Resultados Em uma região (cubóide) com n nós distantes do atuador, a energia usada na transmissão de cabeçalhos é reduzida por um fator de n. É importante frisar o fato de essa região estar longe do atuador, pois de outro modo ela deverá retransmitir pacotes oriundos de outras regiões da rede. Em um exemplo simulado pelos autores [35], em uma região com 15 nós e leituras a cada 10 segundos, houve redução de 86% no envio de cabeçalhos. Comentários Esse algoritmo é bastante simples de ser implementado, mas seus resultados são apontados apenas em termos da redução na transmissão de cabeçalhos, e deveriam ser melhor testados no caso de ambientes VoIP, nos quais as transmissões são mais frequentes e os pacotes, embora pequenos, ainda sejam maiores que os dos sensores, com requisitos de Qualidade de Serviço que os dados de sensores não possuem XORs in the air Esse método, proposto por Katti et al. [25] trata da agregação de pacotes por codificação oportunista (denominada pelo autor como COPE) no âmbito de redes mesh densas, sem interesse no aumento da segurança das comunicações e focando em dispositivos capazes de participar em redes IP. Apesar de ser uma ideia interessante e com bons resultados, tem a desvantagem de exigir algum trabalho extra entre as camadas de enlace e rede, quebrando a compatibilidade com os modelos em camadas usados atualmente. Contexto Em uma topologia simples de dois nós, Alice e Bob, comunicando-se por meio de um nó intermediário (relay), é fácil enxergar a essência da ideia proposta neste artigo. Considere na figura 4.4 os dois casos: (a) Alice encaminha um pacote para o relay, que o encaminha para Bob. Bob encaminha um pacote para o relay, que o encaminha para Alice. Total de 4 transmissões. (b) Alice encaminha um pacote para o relay, Bob encaminha um pacote para o relay. O relay faz o XOR dos dois pacotes e transmite o pacote resultante uma vez só para os demais, que de posse do pacote enviado antes podem reaver o novo pacote. Total de 3 transmissões. Esse protocolo adota dois princípios: Abrir mão da abstração ponto-a-ponto Aceitar a natureza broadcast do canal sem fio 39

54 Figura 4.4: Topologia de rede usada para contextualizar o artigo XORs in the air em duas situações: (a) Transmissões no modo normalmente usado. (b) Codificação oportunista proposta por Katti et al. [25] Funcionamento O método COPE generaliza o exemplo da figura 4.4, para vários fluxos unicast, sendo seu ganho dependente do tipo de tráfego e da topologia da rede. Terminais escondidos reduzem severamente ou mesmo anulam os ganhos do método, em especial se o tráfego for basicamente TCP 2. Cada nó guarda os pacotes ouvidos (destinados a ele ou não) por um período de tempo, para decodificar os pacotes que chegarão no futuro. Quanto mais pacotes um nó guardar, mais chances de codificação seus vizinhos terão ao transmitir um pacote a ele. Os pacotes são guardados em um pool de pacotes, e cada nó envia dados sobre os pacotes em seu pool junto com as transmissões que normalmente fará. Caso um nó fique muito tempo sem transmitir, poderá reportar os pacotes dos quais dispõe para codificação em um pacote especialmente enviado para este fim. Além disso, sempre que um nó foi o salto anterior de um pacote, ele possui esse pacote. Há ainda métodos probabilísticos para determinar se um determinado nó possui um pacote. Para facilitar o gerenciamento do pool de pacotes, bem como para tornar os relatórios dos pools mais curtos, é usado um hash do IP do emissor com o número sequencial do pacote. Dado um conjunto de pacotes a enviar na fila de saída de um nó e a informação de quais pacotes os destinatários possuem, o nó emissor pode determinar em tempo polinomial um conjunto de pacotes (e destinatários) adequado para maximizar o ganho naquele envio. Ele então fará XOR (ou qualquer outra combinação linear) dos pacotes e os enviará para todos os destinatários de uma vez. Os destinatários poderão, de posse dos pacotes que 2 Em função do controle de fluxo desse protocolo. 40

55 já possuem, decodificar seus respectivos pacotes, usando-os em suas aplicações ao mesmo tempo em que os guarda em seu próprio pool. Resultados Um efeito interessante é que, em casos como o (a) da figura 4.4 os ganhos observados foram maiores que o máximo teórico esperado pelos autores, e a explicação foi que como a camada MAC tenta ser justa, ela aloca o meio igualmente para Alice, Bob e o relay, mas de fato o relay tem de transmitir o dobro de pacotes que os demais (isso se ele não gerar tráfego). Essa injustiça leva a fila do relay a descartar metade dos pacotes recebidos. Com a codificação oportunista, o relay terá a mesma taxa de transmissão que os demais, e a camada MAC de fato será justa, gerando menos perdas. Desse modo, os autores estimam que em casos nos quais há o que eles chamam de ganho MAC e o uso da codificação, o throughput da rede pode dobrar. Nos experimentos práticos, em uma topologia real com 20 nós espalhados por dois andares do prédio da universidade dos autores, quando o meio sem fio estava congestionado e o tráfego consistia de vários fluxos UDP, o ganho com o COPE foi de 3 a 4 vezes. Em geral, fluxos que não tinham controle de congestionamento se beneficiaram do ganho MAC. Em uma rede mesh conectada à Internet por um gateway o ganho variou em função da taxa entre download e upload, oscilando entre 5% e 70%. Quando havia terminais ocultos, o TCP controlava muito os envios, confundindo a situação com uma rede congestionada, gerando poucas oportunidades de codificação e não provendo ganhos de desempenho. Comentários Esse método provê ganhos altos, mas é de difícil implementação mesmo em um teste, visto que seria preciso emular as várias camadas da pilha de rede para obter o comportamento adequado ao mesmo tempo em que se provê o ajuste necessário a algumas variáveis que regem esse método. A implementação em um experimento real é de complexidade muito elevada Hop-By-Hop Contexto Nesse artigo por Castro et al. [10] a ideia é aplicada a um contexto de redes que os autores dizem ser um ambiente ideal para as redes de 4 a geração, que são chamadas de WMNs, ou WLAN Meshed Networks, compostas por um ou mais MGs (Mesh Gateways), responsáveis por conectar a rede à Internet, um ou mais MRNs (Meshed Relay Nodes), responsáveis pelo roteamento dos pacotes, e nós ordinários, que geram tráfego. Os autores atacam o problema de tráfego VoIP ou similar, no qual há a geração de muitos pacotes pequenos com frequência, e oferecem uma solução de agregação a cada salto, pois apesar de inserir um delay maior, essa solução provê mais oportunidades de agregação. Eles justificam a escolha por esse tipo de tráfego pelo crescente interesse da sociedade em tráfego VoIP, e citam que, quando usado o CODEC G.729a, o payload dos pacotes é de 20 bytes, enquanto os cabeçalhos possuem 40 bytes, um overhead significativo. 41

56 Figura 4.5: Exemplo dos dados no canal X tempo [10] Funcionamento Os autores propõem uma agregação simples, similar à de Petrović et al. [35] (abordada na parte deste trabalho), trabalhando na camada de rede, com o cuidado de se adaptar à condição da rede no momento e ao tipo de tráfego, e com o princípio de não adicionar delay ou overhead exceto quando necessário para prover uma boa taxa de agregação. Para isso, são usados três parâmetros configuráveis, SIZE min, SIZE max e MAX delay, para controlar, respectivamente, o tamanho mínimo de um pacote agregador, o tamanho máximo do mesmo ou o máximo de atraso forçado induzido. A cada salto, os pacotes recebem um temporizador e são guardados em uma fila, entre o módulo de roteamento e a camada MAC. Assim que a camada MAC se torna ociosa o algoritmo de agregação tenta criar um pacote agregador para repassar à camada MAC. Todos os pacotes na fila com o mesmo próximo salto em sua rota podem ser agregados, caso não excedam em tamanho SIZE max. Se o tamanho exceder SIZE min os pacotes são agregados e repassados à camada MAC. Se o tamanho for inferior a SIZE min só os pacotes que excederam MAX delay são agregados e transmitidos. Se nenhum pacote for tão antigo, nada é feito e a camada MAC permanece ociosa. Se exatamente um pacote for antigo, ele é enviado como está, sem mudanças, e se dois ou mais forem antigos, eles são agregados e o conjunto é repassado à camada MAC. A agregação ocorre pela adição de um cabeçalho IP antes dos pacotes concatenados, induzindo um overhead extra de 20 bytes por pacote agregador. A distinção é feita pelo campo de protocolo nesse cabeçalho IP, que quando setado em IP META indica a agregação. O resultado pode ser visto na figura 4.5. Controle das variáveis SIZE min, quando muito pequena, faz com que os pacotes quase nunca sejam agregados, e quando muito grande faz com que atraso excessivo seja induzido. SIZE max deve ser grande o bastante para permitir a agregação, mas pequeno o bastante para não gerar fragmentação por exceder a MTU. MAX delay é muito crítica pois VoIP é sensível a atrasos, então não deve ser grande demais. Se for pequena demais, não vai permitir a agregação. Os autores indicam o valor 42

57 de 5ms no caso de redes pouco congestionadas. Em redes muito congestionadas, um valor muito alto não faz diferença, pois as filas tendem a exceder SIZE max com facilidade. Resultados Em um cenário de rede b, os autores tiveram reduções significativas, em torno de 50%, na perda de pacotes, bem como no jitter, e os números melhoravam à medida em que o número de conversas simultâneas subia, até um certo limite de saturação. O delay induzido era maior com agregação do que sem, quando havia poucas conversas, mas à medida em que o número de fluxos aumentava, até um limite, o cenário com agregação apresentava menores delays. O cenário sem agregação se mostrou com qualidade para suportar até 42 conversas com qualidade, enquanto o cenário com agregação suportou bem até 68 conversas simultâneas por um mesmo backbone, no caso de o mesmo possuir dois nós. Além disso, o tempo de uso da camada MAC foi significativamente menor no caso do cenário com agregação. A comparação final foi com diferentes números de nós compondo o backbone, e os ganhos foram de 45%, 71% e 66% no número de conversas simultâneas, quando o backbone possuía, dois, três ou quatro saltos, respectivamente. Comentários Enquanto a ideia é bem simples de ser entendida e simulada, embora não tanto de ser implementada na prática, as métricas usadas pelos autores não são diretamente correlacionadas às usadas pelos demais autores, de modo que devemos considerar fazer outros testes com métricas em comum para comparar melhor os resultados IPAC Contexto Esse artigo de Raghavendra et al. [37] propõe um método de agregação de pacotes fim a fim na camada de rede, em parte pela dificuldade de se implementar algo assim na camada de enlace em grande escala, pois exigiria a substituição de firmware de virtualmente qualquer equipamento de rede, enquanto que ao se mexer na camada de rede, basta atualizar softwares mais facilmente intercambiáveis. Tudo isso se passa no âmbito de redes sem fio. Os autores trabalham para evitar a contenção de acesso ao meio da camada de enlace, tendo como estratégia para tal a redução do número de pacotes enviados, mesmo que o volume de dados seja o mesmo (ou até maior). No planejamento do trabalho, Raghavendra et al. [37] se propuseram a responder três perguntas: 1. Há um número significativo de pacotes pequenos (agregáveis) em uma rede sem fios? 2. A transmissão de pacotes grandes causa grande aumento na probabilidade de erros? 3. Qual é o atraso induzido no enfileiramento e na concatenação de pacotes? 43

58 Ao realizar uma captura de dados de uma rede sem fios em uma conferência os autores levantaram que, ao menos naquela situação, pacotes de até 150 bytes eram a maioria, e que portanto a resposta para a primeira pergunta é sim, de modo que eles prosseguiram com a pesquisa. Funcionamento Como já foi dito, o protocolo proposto trabalha na camada IP, e começa ao determinar o melhor tamanho máximo do pacote agregado em função da qualidade da rota pela qual esse pacote irá trafegar, uma vez que se o pacote for grande demais e induzir perdas, as retransmissões decorrentes irão prejudicar demais o desempenho, anulando as vantagens do método em questão. Os autores parametrizaram o tamanho máximo do pacote agregado, que é determinado não só em função da fragmentação ou do delay induzido, mas também levando em conta a qualidade da rota desse pacote. Além disso, o tempo pelo qual um pacote pode esperar para ser agregado também foi parametrizado. É criada uma fila de pacotes para cada destinatário de um determinado nó, e essa fila é mantida até um determinado tempo sem transmissões para aquele destinatário. Ao finalizar o tempo de espera para agregar ou atingir o tamanho máximo de pacote, os pacotes a serem enviados são então agregados em um único pacote, precedido por um cabeçalho de 4 bytes com informações sobre o número e o tamanho dos pacotes agregados, e esse pacote grande é enviado como payload para a camada MAC. A determinação do tamanho máximo de pacotes para envio é feita com base em um método de Draves et al. [15, 16] (citado pelo autor do artigo aqui analisado), que envolve analisar os vários saltos de cada caminho possível, o que em nossa análise pode se tornar muito oneroso em redes grandes. O autor especifica que o método IPAC tem como objetivo melhorar o desempenho em redes sem fios estáticas com vários saltos, como backbones mesh. Nesse caso, as rotas tendem a ser mais estáticas e não onerar tanto a análise do tamanho máximo. Resultados A metodologia de testes consiste em simulações no simulador Qualnet, em um cenário de 100 nós distribuídos de forma uniforme e aleatória em uma área de 1000m X 1000m, com 10 pares de nós emissores-receptores e os demais apenas roteando, com o cálculo da média de desempenho em 5 simulações em diferentes topologias aleatórias para cada tipo de tráfego, em redes IEEE b com o mecanismo RTS/CTS desativado, e com duração de 200s em cada simulação. O primeiro passo foi determinar o melhor (maior) tamanho de pacote para cada índice de qualidade de rota, sendo que parece haver uma relação linear entre os dois parâmetros. Esse tamanho foi então usado nas simulações seguintes, em função do tamanho de pacote gerado em cada tipo de tráfego analisado. Foram analisados dois tipos de tráfego: HTTP e CBR, usando para transporte, respectivamente, TCP e UDP. Para análise dos atrasos induzidos no tráfego CBR, foi usada uma taxa de 64Kbps, que resultou em pacotes de 160 bytes. Esse tipo de tráfego não tolera grandes atrasos, ao contrário do tráfego HTTP. Embora a análise dos atrasos induzidos possa variar enormemente 44

59 em função da topologia da rede, nas topologias analisadas os autores puderam variar o tempo de espera para agregação entre 1ms e 10ms sem induzir atrasos que prejudicassem CODECs como o G.711. Para analisar o uso da rede (tempo gasto na efetiva transmissão de dados sobre a soma do tempo gasto na transmissão de dados com o tempo usado em contenção), os autores variaram, no caso do tráfego CBR, a taxa de transmissão, entre os valores 50Kbps, 100Kbps, 1Mbps e 5Mbps, obtendo taxas de, respectivamente, 27%, 30%, 50% e 77%. Outro parâmetro analisado foi o número médio de tentativas de acesso ao meio dos nós. No caso das taxas de transmissão menores, o ganho foi discreto, mas com as maiores taxas, o número médio de tentativas caiu para aproximadamente metade. O throughput também foi analisado, e praticamente dobrou no caso da taxa de 5Mbps, embora fosse praticamente o mesmo do cenário sem agregação no caso das demais taxas. O delay foi analisado novamente, agora em função da taxa de transmissão, e apresenta um resultado interessante: O atraso é máximo no caso da rede pouco congestionada, o que pode ser explicado pela demora em se encher um pacote agregado, em função da baixa ocorrência de pacotes. No caso do tráfego HTTP, o autor é mais lacônico, em parte por ser um tipo de tráfego que pouco se beneficia da agregação de pacotes, já que em geral o TCP transmite pacotes do tamanho do MTU, dada a menor vulnerabilidade desse tipo de tráfego a atrasos, quando comparado a tráfegos como de streaming de mídia e VoIP. De todo modo, houve ganhos moderados no tráfego HTTP de acordo com o autor. Comentários O método é bem simples de ser entendido e implementado, e embora apresente bons resultados, o fato de se basear em roteamento fim a fim pode ser um grande limitador, uma vez que os cenários de roteamento podem ser mais dinâmicos, e é relativamente incomum que dois ou mais tráfegos simultâneos ocorram entre dois nós fixos, cenário que seria o melhor caso para a agregação fim a fim Comparação das técnicas De forma sucinta, é possível perceber as seguintes vantagens e desvantagens nos métodos estudados neste capítulo: Data Funneling: É simples de implementar e reduz os cabeçalhos trafegados, mas não prevê QoS, de modo que pode ser muito prejudicial para VoIP; XORs in the air: Faz com que uma única transmissão sirva a vários nós de uma só vez, mas pode aumentar significativamente os requisitos de memória dos dispositivos, uma vez que precisa armazenar pacotes que já foram transmitidos ou enviados; Hop-By-Hop: É um método simples e versátil para vários tipos de tráfego, mas exige cabeçalhos de agregação grandes, e sua espera constante pode causar descarte de pacotes VoIP atrasados; IPAC: Não induz esperas ou processamento complexo ao longo da rota, mas por isso pode perder a maior parte das oportunidades de agregar pacotes. 45

60 Tabela 4.1: Comparação dos métodos de agregação estudados. Data Funneling XORs in the air Hop-By-Hop IPAC QoS Não Não Não Não Complexidade Baixa Alta Baixa Baixa Overhead Baixo Baixo Alto Alto Induz perdas em VoIP Sim Não Sim Sim Uma comparação similar pode ser vista na tabela 4.1. Dessas técnicas, a mais próxima de prover o que é necessário para os objetivos desse trabalho é a técnica Hop-By-Hop, de Castro et al. [10], mas como ela prevê uma espera constante em cada salto para agregar pacotes, é possível que sofra com duas situações antagônicas: 1. Ao transportar um pacote muito atrasado, os 5ms de espera podem fazer com que o mesmo seja descartado, de modo que não valeria a pena aguardar para que ele seja agregado a outros; 2. Se um pacote não tiver requisitos de tempo restritivos ou se os tiver mas não estiver na rede há muito tempo, pode valer a pena aguardar um tempo extra além dos 5ms para agregar este pacote, reduzindo ainda mais o número de transmissões e aumentando a eficiência no uso do canal sem fios. Desse modo, a espera fixa pode ser prejudicial tanto a pacotes muito adiantados como a pacotes que estejam atrasados, de forma que uma abordagem de espera adaptativa deve ser considerada para melhores resultados. Apesar disso, por ter sido a proposta com mais aplicação aos cenários que são o foco deste trabalho, a técnica Hop-By-Hop será usada como base para medir o desempenho da proposta do capítulo Considerações Finais É possível perceber claras vantagens no uso de agregação de pacotes, que pode reduzir o número de transmissões na rede e por consequência o volume de cabeçalhos trafegados e esperas efetuadas, mas suas desvantagens também são visíveis, como a complexidade de implementação e a possível incompatibilidade com equipamentos e softwares atualmente usados. Além disso, a espera por novos pacotes para efetuar agregação pode degradar a qualidade da rede percebida por aplicações VoIP. Desse modo, no próximo capítulo será exposta uma proposta de protocolo de agregação diferente dos aqui estudados, que tenta mesclar as vantagens percebidas com o cuidado de evitar os problemas apontados, e essa nova técnica será especialmente voltada para ambientes nos quais a QoS é muito crítica, como aqueles com tráfego VoIP, em função da necessidade percebida e apontada no capítulo 1. 46

61 Capítulo 5 Agregação de Pacotes em Ambientes Saturados Neste capítulo será apresentada uma nova proposta de agregação de pacotes, em função das desvantagens notadas nas metodologias atuais, que foram apresentadas no capítulo 4. Na seção 5.1 serão mostrados todos os aspectos que compõem essa técnica, e os motivos de ela ser melhor em cenários de redes comuns, considerando os requisitos de qualidade de serviço de aplicações VoIP. Em seguida, na seção 5.2, a metodologia usada para desenvolver o simulador de redes que foi usado para obter os resultados desse trabalho, já que para tanto seria necessário simular o comportamento não apenas da proposta apresentada, como também o comportamento das redes sem fios atuais e da técnica de agregação do estado da arte que mais se adequa aos cenários estabelecidos, de modo que fosse possível comparar resultados reais da técnica proposta com o que há de melhor. O simulador projetado e desenvolvido sob as premissas apresentadas a seguir foi batizado de CQVoIP, acrônimo para Comunicação com Qualidade em VoIP. 5.1 Método MAPAS (Mecanismo de Agregação de Pacotes em Ambientes Saturados) Nesta seção será descrito o método que doravante neste texto será denominado MAPAS, sigla para Mecanismo de Agregação de Pacotes em Ambientes Saturados. Essa proposta foi elaborada com base na análise das propostas de outros pesquisadores, exibidas no capítulo 4, bem como no funcionamento em geral de redes sem fios e de características da comunicação VoIP. A ideia é tentar ao máximo possuir as vantagens das propostas de outros autores, ao mesmo tempo em que são reduzidas as desvantagens verificadas. Para tanto, foi assumido que o foco da proposta poderia ser VoIP, mesmo que na rede trafegassem outros dados. Essa premissa também beneficia outros tipos de tráfego dependentes de QoS, tais como streaming de vídeo e áudio, dado que possuem características similares ao VoIP. Como os CODECs de VoIP geram pacotes a intervalos de 20 a 30ms, e tais pacotes possuem um tempo máximo de vida de 150ms, a agregação fim a fim, como a proposta em [37], não é adequada, por permitir, no melhor caso, agregar entre 6 e 8 pacotes por 47

62 envio, no caso de haver poucos saltos na rota. Portanto foi escolhida uma abordagem de agregação a cada salto, como em [10], para maximizar a quantidade de pacotes agregados. Na proposta de Castro et al. [10], a espera para agregar um pacote (MAX delay ) é constante, com valor sugerido pelos autores de 5ms. Na situação de um pacote estar atrasado devido ao congestionamento da rede ou à banda insuficiente de algum enlace, essa espera constante pode levar à extrapolação do tempo de 150ms de viagem do pacote, mesmo que ele tivesse condições de chegar a tempo, caso não fosse retido. Há ainda a possibilidade de que os 5ms sejam muito pouco para aproveitar melhor as oportunidades de agregação daquele pacote, se ele não estiver atrasado. Portanto, a espera constante não pode ser adotada, sob pena de perder pacotes por esperas que não podem ser efetuadas ou deixar de agregar o máximo de pacotes possíveis. Além disso, nessa mesma proposta, há a inclusão de 20 bytes (um cabeçalho IP) para cada pacote agregado, um overhead extra muito grande, considerando que no tráfego VoIP geralmente os cabeçalhos já superam em tamanho o conteúdo verdadeiro dos pacotes (voz). Se um cabeçalho de agregação tiver de ser introduzido, o mesmo deve ser menor, para uso mais eficiente do canal (maior goodput). Para ter acesso fácil às tabelas de roteamento, que permitiriam melhores possibilidades de agregação a cada salto, a escolha foi por trabalhar na camada de rede da pilha de protocolos OSI (vide tabela 2.1), ou, de modo equivalente, a camada de internet da pilha TCP/IP (vide tabela 2.2). Sendo assim, o método MAPAS irá trabalhar com uma política de esperas variáveis por novos pacotes para agregação. A espera será igual em cada nó, mas desse tempo serão descontados os períodos de transposição de enlaces, de modo que os pacotes possam sempre chegar a tempo em seu destino. Para que seja possível calcular esses tempos de espera, é preciso registrar em cada pacote sua origem, seu destino e seu tempo decorrido. Isso é feito por meio de um cabeçalho de agregação Cabeçalhos de Agregação Para permitir melhor controle sobre os pacotes transmitidos com agregação, mas sem aumentar significativamente o uso de cabeçalhos na rede, foi desenvolvido um formato de cabeçalho de agregação para uso com a proposta estabelecida nesse trabalho. Ele tem tamanho fixo de 11 bytes, e a composição detalhada na tabela 5.1, e um pacote visto do ponto de vista da camada MAC de uma rede b/g em modo misto seria, deste modo, como representado na figura 5.1. Tabela 5.1: Composição do cabeçalho de agregação proposto. Tamanho (bytes) Nome Conteúdo 1 et ime Tempo de vida do pacote, em milissegundos 2 size Tamanho, em bytes, daquela parte agregada 4 source Endereço IP da origem do pacote 4 dest Endereço IP do destino final do pacote Como o funcionamento ocorre na camada IP, para separar os diversos conteúdos agregados, basta remover os cabeçalhos MAC (feito na camada inferior) e IP (feito na própria camada IP). Na análise do campo Protocolo do cabeçalho IP, o valor indicará que há 48

63 Figura 5.1: Pacotes VoIP agregados pela nova proposta. pacotes agregados 1, então os primeiros 11 bytes após o cabeçalho IP serão de um cabeçalho de agregação. Desse cabeçalho, o campo size conterá o número de bytes, após o próprio cabeçalho de agregação, que pertencem ao pacote em questão. Após esse número de bytes, haverá outro cabeçalho de agregação, e assim sucessivamente, até que o número de bytes pesquisados após o cabeçalho IP supere o valor contido no campo T otallength do cabeçalho IP, indicando que não há mais pacotes agregados Funcionamento O princípio que rege o MAPAS é de, em vez de esperar um valor fixo para que cheguem mais pacotes agregáveis, esperar o maior tempo possível que não implique atrasos. Para tanto, é preciso que cada nó da rede possua de antemão uma estimativa 2 do tempo necessário para um pacote chegar a um determinado destino. Segundo [6], todos os protocolos de roteamento em redes mesh envolvem que os nós guardem informações sobre o caminho para um nó específico com o qual haja comunicação. Essa informação pode ser o próximo nó pelo qual o pacote deve passar (next hop), como no caso dos protocolos DSDV e AODV, ou mesmo a rota inteira, como no protocolo DSR, que pode chegar a gravar várias rotas completas para um mesmo destino, em sua variação multipath. É fácil usar, quando da descoberta da rota e independentemente do algoritmo de roteamento, um temporizador que calculará o tempo entre o envio da requisição e a chegada da primeira resposta, e o tempo estimado de chegada será a metade desse tempo, presumindo então que a qualidade da rota seja igual nos dois sentidos. Esse valor de tempo será nossa medida de congestão da rede e de qualidade de uma rota, que norteará a definição de quanto tempo um pacote pode aguardar a cada salto [9]. Ao longo do tempo, mais pacotes de descoberta de tempo podem ser enviados para atualizar as estimativas. Duas variáveis influenciam essa estimativa de tempo, e os valores adotados para as mesmas serão detalhados no capítulo 6. São elas: Tamanho do pacote de descoberta de rotas: Se esse pacote for muito grande, o algoritmo sempre irá superestimar o tempo de trânsito dos pacotes, e esperar menos do que o ideal por novos pacotes, perdendo oportunidades de agregação. Se for 1 De acordo com [21], em 9 de Agosto de 2010 havia 110 valores não utilizados para esse campo, então é possível atribuir um valor específico e usá-lo para esse formato de agregação. 2 Nos experimentos realizados, essa estimativa foi feita apenas no início das transmissões, pois presumiu-se que a rede era estática. 49

64 muito pequeno, esperará por tempo demais para agregar, e os pacotes eventualmente chegarão a seu destino tarde demais, sendo descartados. O tamanho é sempre considerando como payload da camada IP; Tempo desejado de travessia: É uma medida percentual do tempo máximo que um pacote pode esperar antes de ser descartado. Esse tempo é de 150ms, mas supondo a situação na qual dois nós vizinhos tenham dados para transmitir ao mesmo tempo e ao menos um deles possua pacotes com tempo próximo do limite, e que esse seja justamente o que teve de aguardar para ser transmitido para evitar colisões, ele provavelmente chegará atrasado e será descartado. Desse modo, convém ter como objetivo um tempo ligeiramente menor que o limite máximo, para evitar que essa situação, muito comum, gere descarte de pacotes. De posse dessas estimativas de tempo é possível utilizá-las para saber por quanto tempo esperar por novos pacotes a agregar para um dado next hop, antes de enviá-lo. O comportamento do MAPAS é descrito no algoritmo 1. Em seguida detalharemos as funções usadas no mesmo. Algoritmo 1 Roteamento com agregação Entrada Pacote P 1: P transp desencapsula(p ) 2: P P P transp 3: se P transp então 4: envia camada transporte(p transp ) 5: fim se 6: S separa(p ) 7: enf ilera(s) 8: para toda fila Q faça 9: se lim tempo(q) ou lim tamanho(q) então 10: envia camada enlace(f rente(q)) 11: fim se 12: fim para Para descrever as funções, sejam P um pacote com um ou mais payloads, S um conjunto de pacotes e Q uma fila de pacotes ordenada por menor tempo de espera possível 3. As funções do algoritmo são as seguintes: desencapsula(p) Responsável por prover os pacotes agregados em P destinados ao nó que executa a função; separa(p) Provê um conjunto 4 S de pacotes que antes estavam agregados. Esta função torna o algoritmo mais flexível, pois permite a agregação de pacotes que possuam 3 Esse tempo é calculado subtraindo o tempo já gasto do pacote em trânsito e o tempo estimado de trânsito até o final da rota do tempo máximo de espera tolerável(150ms). Dessa maneira, a fila de pacotes sempre possui em seu topo o pacote mais próximo de ser descartado, para ser enviado primeiro, sendo esse então o critério usado para definir a prioridade de um pacote. 50

65 diferentes destinos, desde que tenham trechos da rota em comum, agrupando-os em função desses trechos. enfilera(s) Recebe um conjunto S de pacotes e os coloca em suas respectivas filas, de acordo com seu next hop. Essas filas têm a propriedade de colocar em primeiro lugar os pacotes com o prazo mais curto para chegar ao destino 2 ; frente(q) Lê os pacotes de mais alta prioridade na fila Q e os transforma em um pacote agregado, subtraindo-os dessa fila; lim tempo(q) Retorna verdadeiro se o pacote de mais alta prioridade da fila Q está com o tempo de espera naquele salto esgotado e falso caso contrário. O limite de tempo é calculado com base em duas informações disponíveis: O tempo que foi gasto pelo pacote de sua origem até o nó atual e o tempo estimado de chegada ao destino mais distante (são vários pacotes agregados, podendo haver vários destinos), em que a distância é medida em tempo, que foi calculado quando da descoberta da rota. O tempo que sobra da subtração desses dois valores do tempo de espera máximo (150ms) é então dividido pelo número de saltos restantes, e o nó atual usa uma dessas partes; lim tamanho(q) Retorna verdadeiro se a fila Q já está cheia, ou seja, se não é possível agregar mais pacotes, e falso caso contrário. É passível de estudos futuros definir uma fração Φ tal que se uma parcela maior ou igual a Φ de um pacote estiver cheia a função também retorna verdadeiro. 5.2 Metodologia de Desenvolvimento do Simulador Para desenvolver o simulador citado no começo do capítulo, era preciso antes escolher uma estratégia. Havia vários entes que deveriam ser simulados pela sua participação nas redes sem fios que suportam tráfego VoIP, e seria preciso simular não apenas a proposta deste trabalho, como também uma outra proposta, do estado da arte atual, para fins de comparação de resultados, e mesmo a abordagem sem agregação de pacotes deveria ser possível, pois é a realidade na maior parte dos casos. A fim de facilitar a modelagem e a representação fiel de todos os elementos que participam no mundo real daquilo que deveria estar presente nas simulações, foi escolhido o paradigma de Programação Orientada a Objetos, e como base para prever as interações que ocorreriam no programa, as ideias expressas no diagrama da figura 5.2. Foram definidas premissas sobre as funcionalidades e características do simulador, de modo que ele servisse bem não apenas a essa pesquisa, mas a quaisquer pesquisas no campo de agregação de pacotes no âmbito de redes sem fios. Algumas dessas características e funcionalidades são: Adaptabilidade O simulador deve ser facilmente adaptável à evolução da pesquisa, tanto das propostas de outros autores como para simular mudanças na proposta que deu origem a este software; hop. 4 O que define um conjunto é o fato de todos os pacotes ali contidos terem em comum o mesmo next 51

66 Figura 5.2: Esquema de modelagem do simulador, com base nas entidades identificadas como participantes das simulações. Desempenho Ao executar simulações, elas devem durar o menor tempo possível, mas sem que para isso seja sacrificada a certeza de um resultado correto. Além disso, deve ser possível executar várias instâncias concorrentes do simulador em computadores com vários núcleos de processamento, sem que haja nada no simulador que inviabilize tecnicamente tal possibilidade; Extensibilidade Deve ser possível estender o simulador para simular outras propostas de diferentes autores, ou mesmo aumentar o grau de detalhe dos cenários propostos (como simular mais camadas da pilha de rede, ou outros protocolos). Também deve ser possível mudar as unidades de medidas usadas sem que isso gere a necessidade de grandes modificações no código; Flexibilidade Os cenários de simulação poderão ser tão complexos e realistas quanto necessário para realizar a pesquisa. Desse modo, deve ser permitido configurar as conversas VoIP para cada direção separadamente, cada uma com momentos de início e término independentes, bem como a frequência de envio dos pacotes. As bandas dos enlaces entre os nós também devem ser independentes entre si, para prover mais possibilidades de pesquisa; Interface por Linha de Comando Para aumentar a eficiência na execução do software mesmo remotamente, bem como para permitir automatização fácil, deverá ser suportada interação com o simulador por linha de comando; Manutenibilidade O código deve ser fácil de manter, mesmo por pessoas diferentes. Isso pode significar até mesmo que o novo mantenedor seja estrangeiro, de modo que todo o código, bem como sua documentação, devem estar totalmente em inglês. 52

67 Todo o código deve estar bem documentado, para facilitar o entendimento do mesmo por qualquer pessoa familiarizada com programação e com o tema abordado pelo programa; Portabilidade O programa tem de ser compatível ao menos com as plataformas de hardware x86 e x86 64, bem como com a maioria dos sistemas operacionais Unixlike para esse tipo de processador, de modo que não seja exigido dos laboratórios de pesquisa nenhuma modificação em seu parque computacional para executar o software, exceto a recompilação do mesmo; Sistema de logs Ao final da simulação deve ser possível ver um relatório, que pode ser reduzido ou completo, da simulação. Esse relatório deve poder ser gerado tanto na tela de execução quanto em arquivo de texto puro; Software Livre Para respeitar as liberdades de qualquer usuário potencial do programa desenvolvido, bem como para cumprir o papel social da Universidade, especialmente no caso de uma Universidade Pública, o software deve ser livre. Com esse intuito, foi escolhido o licenciamento sob a GNU GPL (General Public License) em sua versão 2 ou superior [17]. Desse modo, foi feito um planejamento de quais seriam os dispositivos de rede que seriam de fato implementados, e quais seriam abstraídos. Após esse planejamento, foi feita a especificação dos métodos que cada classe iria prover, com uma abordagem bottom-up iterativa, que foi escolhida para garantir que todos os aspectos desejados fossem cobertos. O resultado dessa especificação pode ser visto na figura 5.3, um diagrama de classes UML do simulador desenvolvido. Os próximos parágrafos descrevem o funcionamento interno, com abstrações, dos módulos ilustrados no referido diagrama, para melhor correlacionar os conceitos de redes e agregação de pacotes às escolhas feitas na modelagem e no desenvolvimento do programa. Módulo packetcontents Os objetos dessa classe refletem o equivalente a um único payload VoIP, não agregado. Desse modo, quando há uma transmissão de pacote (Módulo packet, a seguir), haverá um ou mais objetos do tipo packetcontents associados a ela. Esses objetos possuem informações sobre quanto tempo 5 se passou desde sua criação, sua origem, seu destino e seu tamanho (camadas de Transporte e Aplicação, apenas). Desse modo, é possível realizar todos os cálculos do MAPAS, bem como os que devem ser feitos nos outros métodos simulados (sem agregação e Castro et al.). Pode-se ainda armazenar objetos do tipo packetcontents em uma estrutura do tipo node::container, quando o pacote estiver em um nó (final ou intermediário), ao invés de estar em trânsito. Tal estrutura será detalhada mais adiante nesse texto. Módulo packet Reflete um pacote na camada de internet do modelo TCP/IP, que possuirá um ou mais pacotes das camadas superiores, representados por objetos da classe packetcontents. Os objetos da classe packet possuiem informações sobre os nós de origem e destino de sua transmissão, quantos pacotes da camada superior o compõem, tamanho 5 Tempo de simulação, que é independente do relógio real do computador que executa a simulação. 53

68 Figura 5.3: Diagrama UML do simulador desenvolvido. 54

69 usado com payload e com cabeçalhos, cuidando de não permitir agregação de mais pacotes quando o MTU for excedido e de somar automaticamente o tamanho adequado de cabeçalho de agregação, se uma técnica que use esse recurso estiver sendo empregada na simulação corrente. Módulo node Simboliza os dispositivos que compõem a rede, embora sem discriminar de qual tipo são. Cada objeto é responsável por organizar e encaminhar corretamente, de acordo com a política de agregação vigente, os pacotes que receber. Alguns nós ainda poderão ser responsáveis por gerar novos pacotes, se tiverem sido designados como participantes de conversas VoIP. Contêiner de pacotes (container) Para organizar os pacotes internamente, não importando se foram gerados localmente ou se em outro nó, cada nó gera um objeto do tipo container para guardar aquele pacote (estrutura do tipo packetcontents). Isso permite armazenar junto ao pacote outras informações úteis, como o tempo de espera que aquele pacote poderá ter no máximo naquele nó e o momento no qual o pacote chegou àquele nó. Módulo event A simulação progride em função de dois tipos de ocorrência, a geração de pacotes novos e a transmissão de pacotes. São duas atividades bem distintas, que demandam lógica de programação bem diferenciada, mas se houvesse duas classes totalmente distintas para gerir as interrupções, bem como duas filas de objetos, uma para cada uma dessas classes, a complexidade do simulador seria muito maior. Para evitar que isso ocorresse, foi definida uma interface única pela qual seria possível desencadear todas as ações inerentes aos diferentes tipos de ocorrência, para em seguida se fazer uso de herança e poder tratar todos os eventos de uma maneira única, por meio do escalonador de eventos (objeto da classe scheduler). A classe event é puramente abstrata, e dela derivam as classes responsáveis por gerar novos pacotes e transmitir pacotes pela rede. Essa escolha permite ainda ampliar mais facilmente as funcionalidades do simulador no futuro. Geração de Pacotes (nodepacketgenevent) Os eventos desse tipo são desencadeados quando chega o momento de um nó enviar um novo pacote a outro nó. Eles são gerados a partir da classe dialoggen, e são enviados, sem agregação, para o nó que será sua origem, que então o inserirá na fila apropriada e o encaminhará normalmente, agregando-o quando for pertinente. Transmissão de Pacotes (nodetransmissionevent) Esses eventos são responsáveis por transportar um pacote (que pode ou não ser composto por várias partes agregadas) de um nó vizinho a outro, cuidando de toda a parte de controle de acesso ao meio e evitando colisões com outras transmissões efetuadas ao mesmo tempo por nós vizinhos. Módulo scheduler Escalonador de eventos, responsável por centralizar os eventos em um só lugar e organizar a ordem de execução dos mesmos. Possui ainda a responsabilidade de garantir o bloqueio aos nós que estejam transmitindo/recebendo pacotes, bem como àqueles que estejam ao alcance de um nó realizando estas tarefas, devido à interferência sofrida, para que eles não consigam realizar acesso ao meio (equivalente, em funcionamento, à camada de controle de acesso ao meio da pilha de rede). 55

70 Módulo logger É globalmente acessível por todos os demais módulos, que assim podem registrar qualquer informação que seja necessária, para que ao final seja elaborado um relatório da simulação. O registro dessa maneira faz com que não seja preciso diferenciar as situações nas quais o relatório será gravado em arquivo daquelas em que o mesmo será mostrado na tela. O nível de detalhe das mensagens emitidas pelo do programa também é controlada nesse módulo, que regula quanto cada módulo pode falar em função da configuração inicial feita pelo usuário. É possível gravar dados genéricos, como uma frase de alerta, ou específicos, como a chegada de um pacote ao seu destino final, e todas as medidas de desempenho relativas a esta situação. Ao final da execução, o módulo logger fará todos os cálculos e imprimirá os indicadores consolidados de comportamento da simulação no meio de saída escolhido, seja a tela ou um arquivo. Módulo dialoggen É o módulo responsável por armazenar quais serão os diálogos VoIP na simulação e gerar os pacotes desses diálogos nos momentos adequados. Por esse motivo, seu funcionamento cumpre o papel das camadas de transporte e de aplicação nas simulações realizadas. Diálogos VoIP (dialog) São estruturas internas do módulo dialoggen responsáveis por armazenar as informações sobre uma única conversa, em apenas uma das direções da mesma, e dados como instantes de início e fim, frequência, origem, destino e alguns marcadores internos. Módulo engine O motor da simulação é responsável por unir todos os módulos especificados anteriormente, formando um simulador coeso. Seu papel é o de ler as configurações do usuário ao início da simulação, criar todos os objetos necessários e à medida em que a simulação progride esse módulo apenas cuida para evocar os demais quando necessário, não realizando nenhuma tarefa relativa à simulação que não seja acionar os demais módulos e cuidar da progressão do tempo de simulação. 5.3 Considerações Finais A proposta apresentada neste capítulo, com esperas de tempo variável por novos pacotes que possam ser agregados, possui mecanismos para reduzir o volume total de cabeçalhos trafegados quando comparados aos usados em outras técnicas do estado da arte, como [10], e também para reduzir o número de transmissões, e ainda permite que as esperas induzidas não atrapalhem o tráfego VoIP, pois elas não excederão os limites desse tipo de tráfego exceto em caso de colisões, mas sem perder a capacidade de aguardar o máximo possível por novos pacotes que possam chegar e ser agregados aos existentes para aumentar a eficiência de uso do canal. No próximo capítulo serão expostas a metodologia de experimentos com o MAPAS e as métricas usadas para compará-lo ao que já há hoje no âmbito de agregação de pacotes, bem como os resultados obtidos nos cenários de redes estudados. 56

71 Capítulo 6 Experimentos e Resultados Com o simulador pronto, foram determinados cenários de rede realísticos nos quais eram vistas fraquezas nas propostas de agregação de pacotes estudadas no capítulo 4, e que sem agregar pacotes seria impossível manter conversas VoIP nesses mesmos cenários. Para comparar as técnicas de agregação, na seção 6.1 serão definidas métricas objetivas, no âmbito da qualidade das conversas VoIP e do melhor uso do canal, pois o mesmo pode também trafegar outros tipos de dados ao mesmo tempo em que sustenta as conversas de voz. Em seguida, na seção 6.2, serão descritos os cenários de rede e os resultados obtidos nos cenários em questão, que serão discutidos. Sempre serão comparados os resultados de três abordagens diferentes: Sem agregar pacotes Agregação de Castro et al. [10] Agregação com uso do MAPAS 6.1 Métricas Usadas Para medir de forma adequada a efetividade desses métodos, serão usados três enfoques: Uso eficiente do canal: A redução do número de transmissões leva a menos tempo de esperas na rede, e ainda faz com que seja esperado que o volume de cabeçalhos trafegados diminua, e mais tempo de canal fique livre para outras transmissões, já que o throughput deve ser menor. Qualidade de Serviço VoIP: O MAPAS prevê esperas antes das transmissões para que haja oportunidade de agregar pacotes, assim como [10]. É preciso medir se essas esperas, bem como a transmissão de pacotes maiores, irá interferir negativamente na qualidade das conversas, ou se as mudanças ainda deixarão os marcadores relativos à QoS dentro do aceitável para VoIP. Desempenho da Agregação: Servirá para medir quantos pacotes estão sendo agregados, e dará subsídios para confirmar ou não a hipótese de que quanto mais pacotes forem agregados, melhores serão as medidas de eficiência de uso do canal e de QoS. A quantidade de pacotes gerados sempre será a mesma para uma dada topologia de rede, para que não interfira nas medições. 57

72 6.1.1 Parâmetros de Eficiência no Uso do Canal Para medir a eficiência de uso do canal, ou seja, quanto é desperdiçado 1 com cabeçalhos e esperas, serão usadas as seguintes medidas: Número de transmissões: Quanto menos transmissões, mais eficiente será o uso do canal, pois menos será gasto com cabeçalhos das camadas física, MAC e IP, com esperas como DIFS, SIFS, RTS, CTS e na recuperação de colisões, já que menos colisões serão geradas; Total de bytes enviados: Se a agregação gerar economia de cabeçalhos, então o volume total de dados transportados diminuirá, o que levará ao menor uso da banda, permitindo que a rede possa ser usada para outros tráfegos em paralelo, que não seriam possíveis sem implantar a agregação; Total de cabeçalhos enviados: É a medida direta do item anterior, mas foi feita separadamente para que se possa analisar o volume de cabeçalhos de forma totalmente separada dos dados enviados; Total de payload enviado: Como o número de pacotes gerados é o mesmo sempre, esse valor também deverá ser constante, salvo em caso de pacotes serem descartados por timeout, quando esse valor será então menor, e isso será também um problema de QoS; Goodput: De modo diferente do payload, o goodput pode variar entre os diferentes experimentos, pois dependendo da técnica empregada a rede pode levar mais ou menos tempo para transportar todos os pacotes, alterando assim o valor dessa medida; Throughput: Permitirá ver o impacto da queda do volume de cabeçalhos refletida na menor utilização de banda disponível na rede; Overhead induzido: É a porcentagem do volume total transmitido que é composta apenas por cabeçalhos, ou seja, quantos daqueles bytes não eram de fato voz, e sim informações sobre como fazer aquela gravação de voz chegar da origem ao destino Parâmetros de Qualidade de Serviço A qualidade de serviço para aplicações VoIP provida pela rede pode ser medida com os parâmetros a seguir: % de perda de pacotes: Conforme pode ser visto na figura 3.6, a perda de 5% de pacotes já pode ser percebida pelo usuário, e acima de 10% torna a qualidade da conversa proibitiva, quando se fala do CODEC ilbc. Portanto, uma boa técnica de agregação tem de evitar ao máximo a perda de pacotes. Vale ressaltar que a perda não se resume à situação em que o pacote não atinge seu destino. Se ele alcançar seu ponto de chegada com um atraso muito grande ele não será aproveitado, e é como se nem tivesse chegado; 1 Desperdiçado comparado ao cenário utópico e ideal de que os dados seriam transmitidos sozinhos, sem que houvesse a necessidade de usar cabeçalhos e sem que cada nova transmissão gerasse uma grande espera na contenção de acesso ao meio, já que o estudo é no âmbito das redes sem fios. 58

73 Delay mínimo: Reflete quão rápido um pacote pode chegar ao seu destino, mas sua importância é reduzida em comparação aos delays médio e máximo e ao jitter; Delay máximo: Reflete o tempo máximo de transposição de rede por um pacote que chegou ao destino a tempo, ou seja, pacotes descartados por atrasos não são contabilizados; Delay médio: É o tempo médio de travessia da rede pelos pacotes. Quanto mais próximo de 20ms melhor, embora qualquer valor abaixo de 150ms seja aceitável quando o jitter é favorável; Jitter: Os pacotes são gerados regularmente na origem, e se não chegarem de forma também regular ao seu destino, a conversa não será fluida. Quanto mais próximo de 20ms o jitter estiver, mais fluidas são as conversas na rede, pois os pacotes estão chegando a uma frequência constante e próxima à de saída da origem Parâmetros de Desempenho da Agregação Embora as medidas de eficiência de uso do canal e de QoS também sejam fruto da escolha do algoritmo de agregação, o método escolhido pode ser avaliado ainda por outras métricas, que não se encaixam em nenhuma dessas duas categorias. São elas: Mínimo de pacotes agregados por transmissão: Se esse valor é alto, o algoritmo está sendo eficiente. Por outro lado, ele pode ser baixo em um função de um nó muito isolado na rede, então tem de ser visto com cautela; Máximo de pacotes agregados por transmissão: Quanto maior esse valor, melhor está sendo o desempenho do algoritmo, mas não quer dizer que o comportamento é uniforme em toda a rede; Média de pacotes agregados por transmissão: É o indicador mais fiel da efetividade do algoritmo, uma vez que retrata o comportamento dele na rede como um todo. Se o valor for alto, espera-se que os indicadores de Qualidade de Serviço e de Uso Eficiente do Canal também estejam bons, o que demonstraria a agregação de pacotes como um método válido de se aproveitar melhor as redes sem fios. 6.2 Experimentos Uma vez que há critérios objetivos para analisar os métodos estudados, é preciso definir os cenários nos quais eles serão testados e realizar então esses experimentos. Foram escolhidos dois cenários com a presença de um gargalo de rede e um cenário em forma de árvore, pois os dois primeiros testarão as diferentes propostas em ambientes saturados, e o último cenário servirá como base para testar em um ambiente congestionado, mas não saturado. Vale ressaltar que todos os resultados foram obtidos da mesma maneira, usando o simulador CQVoIP com os mesmos arquivos de configuração, divergindo apenas no método de agregação utilizado. 59

74 Figura 6.1: Formato da rede no primeiro cenário, com um gargalo na rede Primeiro Cenário: Gargalo Simples A fim de explorar a característica do MAPAS de não esperar demais para agregar quando há um enlace muito lento mais adiante na rota, foi criada a topologia da figura 6.1. Nessa rede, os nós A e B estão ligados ao nó C por bandas de 100kBps, enquanto a banda entre os nós C e D varia de 10 a 100kBps. Os nós A e B enviam, então, dez mil pacotes destinados ao nó D cada, a intervalos de 20ms. Essa é uma situação similar à de se possuir uma rede mesh na qual apenas um dos nós possui acesso à Internet, e deverá rotear os pacotes dos demais. Foram adotados os valores de 750bytes e 100% para as variáveis de tamanho do pacote de descoberta de rota e tempo desejável de travessia, respectivamente, pelo fato de não haver disputa pelo último enlace. Pelo fato de a banda que liga os nós A e B ao nó C ser suficiente, foi explorada a variação na banda entre os nós C e D, para conhecer melhor o comportamento dos algoritmos em bandas muito pequenas e como os resultados mudam com o aumento da capacidade do enlace final. Isso ajudaria a nortear os estudos em outras topologias de rede, tornando as análises mais pontuais. Os resultados serão apresentados seguindo as mesmas divisões que as métricas, de modo que cada um dos três aspectos propostos seja explorado de maneira adequada. Eficiência de Uso do Canal Total de Transmissoes MAPAS Castro et al. Sem agregar Numero de Transmissoes Banda no ultimo enlace Figura 6.2: Número de transmissões em função da banda no último enlace. 60

75 A primeira medida de eficiência de uso do canal é o número de transmissões realizadas. Como cada nó gerou pacotes, num total de 20000, no pior caso haverá transmissões, uma por pacote por enlace que ele atravessará. Como pode ser visto no gráfico da figura 6.2, é exatamente isso que ocorre quando não são agregados pacotes. Já a abordagem de Castro et al. [10] é mais econômica no número de transmissões, embora esse número cresça com o aumento da banda. Isso pode ser explicado pelo tempo de espera constante de 5ms desse método. Quando a banda era muito estrangulada, mais pacotes estavam enfileirados e podiam ser agregados nesses 5ms, mas quando a vazão foi aumentada, não havia tantos pacotes na fila e menos agregação foi feita, aumentando o número de transmissões. O MAPAS foi mais econômico para todos os valores de banda, variando de com a banda a 10kBps a 7500 a partir de 40kBps, ou seja, fazendo entre 38% e 19% do número de transmissões atingido quando não se agrega pacotes. 6e+06 5e+06 Bytes transportados MAPAS Castro et al. Sem agregar Bytes transportados 4e+06 3e+06 2e+06 1e Banda no ultimo enlace Figura 6.3: Total de bytes transmitidos em função da banda no último enlace O volume de dados transportados pela rede refletiu o resultado do número de transmissões, como pode ser visto no gráfico da figura 6.3, tendo sido sempre 4,5MB sem agregação, pouco abaixo disso na abordagem de Castro et al. [10], com uma leve piora no aumento da banda de 10 para 20kBps, em função do tempo constante de espera para agregação. O MAPAS começou com um volume de 3,6MB e à medida em que a banda do enlace final aumentava e mais tempo podia ser gasto aguardando pacotes para agregar, menor foi o volume trafegado, chegando a aproximadamente 3,1MB para valores de banda a partir de 40kBps. O volume de cabeçalhos reflete a situação do volume de dados transmitidos, uma vez que o volume de payload é constante em toda a simulação. Isso pode ser visto no gráfico da figura 6.4. O tempo de simulação é exibido no gráfico da figura 6.5, e mostra valores próximos quando a banda é suficiente para encaminhar todos os pacotes, mas o valor é bem maior no caso de a rede não conseguir entregar todos os pacotes a tempo. O goodput, que tem sua relação com a banda do enlace final ilustrada na figura 6.6, reflete o número de pacotes que chegaram com sucesso, uma vez que o volume de payload é constante e o tempo de simulação é muito parecido em todas as situações. Como só os pacotes que chegaram com sucesso são considerados, o goodput só é igual para todos os métodos a partir de 20kBps, quando a banda é suficiente para que os pacotes não sejam 61

76 4e e+06 Cabecalhos transportados MAPAS Castro et al. Sem agregar 3e+06 Cabecalhos (bytes) 2.5e+06 2e e+06 1e Banda no ultimo enlace Figura 6.4: Volume de cabeçalhos, em bytes, transmitidos em função da banda no último enlace Tempo para Simular MAPAS Castro et al. Sem agregar Tempo (ms) Banda no enlace Figura 6.5: Tempo de simulação em função da banda no último enlace descartados por não chegarem a tempo. Para a banda de 10kBps o goodput é reduzido pelo menor número de pacotes que chegam com sucesso ao destino e pelo maior tempo de simulação, que pode ser visto no gráfico da figura 6.5. É possível ver na figura 6.7 que o throughput tem um comportamento uniforme, condizente com o do gráfico que relaciona a banda disponível com o volume de bytes trafegados, exceto no caso de o enlace final dispor de 10kBps, que mostra um valor bem baixo para as metodologias sem agregação e a com agregação de Castro et al. [10]. Isso pode ser explicado pelo fato de que como o tráfego gerou muito congestionamento nesses cenários, a simulação foi bem mais longa para permitir que todos os pacotes enfileirados fossem encaminhados, o que é confirmado pelo gráfico da figura 6.5. Desse modo, o valor do throughput foi reduzido. Nas outras situações, a simulação tem a mesma duração aproximada em todas as abordagens, trazendo então um comportamento similar ao do volume total de dados transferidos, inclusive mostrando como a nova proposta economiza banda. A figura 6.8 mostra como o overhead varia com a banda do último enlace, em termos percentuais, conforme definido na seção Enquanto sem agregar pacotes 67% do 62

77 10 Goodput MAPAS Castro et al. Sem agregar 8 Goodput (kbps) Banda no ultimo enlace Figura 6.6: Goodput em função da banda no último enlace Throughput MAPAS Castro et al. Sem agregar 20 Throughput (kbps) Banda no ultimo enlace Figura 6.7: Throughput em função da banda no último enlace volume de tráfego é apenas para controlar o fluxo de dados, valor seguido de perto pela proposta de Castro et al. [10], quando o MAPAS foi implementado esse volume caiu para 52%. Qualidade de Serviço Em termos da qualidade de serviço, pode-se ver que as abordagens sem agregar e a de Castro et al. [10] só se tornaram viáveis com a banda final a partir de 20kBps, pois antes disso mais de 40% dos pacotes são descartados por atraso com o uso dessas técnicas, como pode ser visto na figura 6.9. Por outro lado, o MAPAS não gerou descarte de pacotes para nenhum valor de banda testado, então esse não seria um fator impeditivo para conduzir diálogos VoIP, o que iria depender apenas dos outros fatores de qualidade de serviço. O delay mínimo, exibido no gráfico da figura 6.10, possui uma característica interessante, quando a banda no último enlace é de 30kBps. Nesse caso, o MAPAS, apresenta um valor bem inferior ao que os demais valores para esse método sugerem. Após análise dos relatórios de simulação produzidos pelo programa CQVoIP, foi possível constatar que 63

78 Overhead com cabecalhos 75 MAPAS Castro et al. Sem agregar Overhead (%) Banda no ultimo enlace Figura 6.8: Overhead em função da banda no último enlace Pacotes Descartados MAPAS Castro et al. Sem agregar Pacotes Descartados (%) Banda no ultimo enlace Figura 6.9: Porcentagem de pacotes descartados em função da banda no último enlace isso foi devido a uma estimativa de tempo de chegada ao destino bastante alta em função do tamanho do pacote de descoberta de rota usado, pois o programa previa que mais pacotes seriam agregados, o que levaria a um tempo de viagem maior, mas como esse número de agregações não foi atingido, os pacotes não foram retidos por todo o tempo possível, causando redução no delay mínimo. Fora esse ponto do gráfico, é possível ver que o menor atraso é obtido quando não se agrega pacotes, e o método de espera fixa é em torno de 10ms mais demorado para entregar os pacotes, em função dos 5ms de retenção em cada um dos dois saltos. O valor obtido pelo MAPAS, embora sempre mais alto, não é prejudicial à comunicação VoIP, mantendo-se abaixo de 150ms. Analisando o delay máximo, na figura 6.11, também cabe a separação entre as situações de banda a 10kBps e acima. No caso dos 10kBps, com as abordagens sem agregar e de Castro et al. [10] esse valor fica em 150ms, que é o maior valor possível 2, enquanto o MAPAS tem o delay máximo em 110ms. Já para valores de banda iguais ou superiores a 20kBps, o comportamento é diferente. Sem agregar pacotes obtém-se o menor atraso, a abordagem de agregação com esperas constantes apresenta um atraso um pouco superior, 64

79 Atraso Minimo MAPAS Castro et al. Sem agregar 80 Atraso Minimo (ms) Banda no ultimo enlace Figura 6.10: Delay mínimo em função da banda no último enlace Atraso Maximo MAPAS Castro et al. Sem agregar 150 Atraso Maximo (ms) Banda no ultimo enlace Figura 6.11: Delay máximo em função da banda no último enlace e a nova proposta tem atrasos sempre superiores a 140ms. Isso é explicado pelas esperas para aguardar pacotes para agregar, sendo que a espera de 5ms induz um pequeno atraso, e o MAPAS sempre espera o máximo possível, só transmitindo quando um pacote estiver próximo de seu timeout ou se já é possível encher um pacote inteiro do tamanho do MTU. Desse modo, seus atrasos sempre serão superiores, exceto quando há pacotes demais pra enviar, como no caso da banda de 10kBps. Como esse atraso não é superior aos 150ms toleráveis, isso não tem impacto negativo na sustentação de diálogos VoIP na rede. O delay médio sofre de um efeito similar ao do delay mínimo com a banda de 30kBps, como pode ser visto na figura Isso mostra que a superestimativa do número de agregações possível foi constante a ponto de influenciar o atraso médio, e disso é possível concluir que um estudo mais aprofundado de como adaptar os valores das variáveis que regem o MAPAS para serem dinâmicos em função da rede é altamente desejável para aproveitar essas oportunidades de agregação não utilizadas 3. Fora isso, é possível obser- 2 Na verdade o número de pacotes descartados nesse cenário indica que houve pacotes que chegaram com tempos superiores a esse, mas apenas os pacotes que chegaram a tempo são considerados. 65

80 Atraso Medio MAPAS Castro et al. Sem agregar 150 Atraso Medio (ms) Banda no ultimo enlace Figura 6.12: Delay médio em função da banda no último enlace var o delay do MAPAS alto para permitir maior agregação, e os delays da técnica de Castro et al. [10] e quando não se agrega bem inferiores, com diferença entre ambos de aproximadamente 9ms, em função da espera fixa de 5ms em cada um dos dois saltos. 50 Jitter MAPAS Castro et al. Sem agregar Jitter (ms) Banda no ultimo enlace Figura 6.13: Jitter em função da banda no último enlace O jitter é constante no caso do MAPAS, para todos os valores de banda assumindo o valor de 19ms, enquanto que as outras técnicas ofereceram um valor muito alto no caso da banda de 10kBps pela congestão da rede e valor de 20ms nos outros casos, o que está descrito no gráfico da figura Isso se explica pelo tempo constante de espera (0 ou 5ms) dessas abordagens, enquanto a nova proposta possui um tempo variável de espera. Como a nova proposta pode superestimar o tempo de chegada ao destino, no caso de pacotes cuja soma dos tamanhos de seus pacotes agregados e cabeçalhos seja menor que o tamanho do pacote de descoberta de rotas, o pacote pode ser enviado antes do último momento possível. Se isso não ocorresse, os mesmos iriam sempre chegar ao destino aos 3 Se um pacote não foi retido por todo tempo possível, ele não teve todas as oportunidades de receber outro pacote que poderia ser agregado. 66

81 150ms de existência (o mais antigo dos agregados), o que iria também tornar o valor de jitter igual a 20ms. O valor de 19ms é propício para prover serviço de VoIP, não atrapalhando o desempenho percebido pelos usuários. Desempenho da Agregação 10 Agregacao minima MAPAS Castro et al. Sem agregar 8 Numero de pacotes agregados Banda no ultimo enlace Figura 6.14: Mínimo de pacotes agregados em função da banda no último enlace O mínimo de pacotes agregados, representado no gráfico da figura 6.14, é 1 quando não se agrega pacotes, por razões óbvias, e para a abordagem de tempo de espera constante, pois aguardar apenas 5ms não é suficiente para a chegada de um novo pacote em todos os casos, já que pacotes são gerados a cada 20ms e só há duas fontes de pacotes. Já com o uso do MAPAS se agregou no mínimo de 2 a 4 pacotes, dependendo da banda do enlace final. Isso é explicado pelo fato de que como menos tempo será usado transpondo o enlace sem fios, mais tempo pode ser gasto aguardando novos pacotes para agregação, com o crescimento da banda disponível no último enlace. 10 Agregacao maxima MAPAS Castro et al. Sem agregar 8 Numero de pacotes agregados Banda no ultimo enlace Figura 6.15: Máximo de pacotes agregados em função da banda no último enlace A análise da média de pacotes agregados pelo nó que agregou mais possui alguns resultados interessantes, como retratado na figura O grupo de controle, do cenário 67

82 sem agregar, obteve média 1 como esperado. O método de Castro et al. [10] viu uma queda no valor com o crescimento da rede, que pode ser contra-intuitivo, mas está relacionado ao menor tamanho das filas de pacotes com bandas maiores, então, no curto tempo de espera usado, menos pacotes podiam ser agregados. O MAPAS teve um valor crescente em função da banda, já que pode aguardar mais tempo por pacotes para agregar à medida em que o tempo de viagem do pacote é reduzido. 10 Agregacao media MAPAS Castro et al. Sem agregar 8 Numero de pacotes agregados Banda no ultimo enlace Figura 6.16: Média de pacotes agregados em função da banda no último enlace A média de pacotes agregados na rede dá a visão do comportamento do algoritmo na rede como um todo, e pode ser visto na figura O grupo de controle possui valor 1 sempre, a abordagem de espera constante possui uma queda na média de pacotes agregados quando a banda é superior a 10kBps pelo fato já explicado na análise de agregação máxima, e o MAPAS agrega mais pacotes à medida em que mais banda está disponível. Isso significa que para essa topologia de rede o comportamento reflete aquele do nó que mais agrega, mas não pode ser considerado como regra geral em função do reduzido número de nós na rede em questão. Análise dos Resultados Como esperado, o resultado de Castro et al. [10] é superior à abordagem que não agrega pacotes, e o MAPAS oferece consistentemente melhor aproveitamento da rede, reduzindo o overhead e o uso de banda enquanto consegue entregar pacotes VoIP a tempo mesmo com um gargalo significativo na rede, representado pelo valor de 10kBps no último enlace, até quando comparado à proposta de agregação com tempo de espera constante. Isso ocorre sem que os parâmetros de QoS de VoIP sejam violados, permitindo que as conversas VoIP do cenário descrito possam ocorrer sem prejudicar a experiência dos usuários, então para o cenário descrito é possível afirmar que o MAPAS oferece melhora significativa ao estado da arte atual. No caso de dispositivos móveis, a aplicação do novo método leva ainda à economia de baterias, uma vez que são geradas menos transmissões e um volume menor de dados trafegados. 68

83 Figura 6.17: Formato da rede no segundo cenário, com um gargalo ainda mais acentuado que na primeira rede estudada Segundo Cenário: Rede Multiplexada Com o conhecimento de como o MAPAS se comportou no primeiro cenário de rede, bem como a maneira pela qual ele se adaptou ao crescimento da banda no último enlace, o próximo teste era saber como seria seu desempenho no caso de um gargalo ainda mais acentuado. Descrição Nessa rede, há oito nós ligados ao gargalo, ao invés de apenas dois. Esses oito dispositivos estão ligados ao gargalo por enlaces de 100kBps, e enviam, cada um, dez mil pacotes ao nó que está após o gargalo, um a cada 20ms, totalizando 80 mil pacotes. Essa topologia, ilustrada na figura 6.17, também simula uma rede mesh com vários nós que se conectam à Internet por apenas um. Os valores adotados para as variáveis de tamanho do pacote de descoberta de rota e tempo desejável de travessia foram, respectivamente, 1480 bytes e 93% 4. Nesse cenário, ao invés de analisar extensivamente o comportamento do algoritmo em função da banda que gera o gargalo, decidiu-se por descobrir o menor valor de banda que faria com que uma das técnicas estudadas provesse performance para tráfego VoIP, e analisou-se a partir de simulações feitas com apenas essa banda. 4 Dada a existência de disputa pelo segundo enlace entre muitos nós, isso levou a um cenário similar ao de disputa pelo último enlace, e após experimentos viu-se que esses valores eram ótimos para o cenário em questão. O estudo mais aprofundado da influência dessas variáveis está incluído no plano de estudos futuros do capítulo 7. 69

84 Resultados O menor valor de banda para o qual alguma das abordagens estudadas era boa o suficiente para que, quando usada, fosse possível trafegar VoIP na rede foi de 50kBps, valor para o qual o MAPAS permitia essa operação. Os valores obtidos para simulações com essas condições foram os da tabela 6.1. Tabela 6.1: Resultados obtidos para o segundo cenário de rede simulado. Sem agregar Castro et al. [10] MAPAS Número de transmissões Tempo de transmissão (ms) Total transmitido (bytes) Cabeçalhos enviados (bytes) Payload enviado (bytes) Goodput (kbps) 17,15 21,15 30,39 Throughput (kbps) 51,45 57,34 64,04 Overhead induzido (%) 66,67 63,11 52,55 Perda de pacotes (%) 40,94 40,96 0 Delay mínimo (ms) Delay máximo (ms) Delay médio (ms) 74,99 74,94 100,46 Jitter (ms) Mínimo de pacotes agregados Máximo de pacotes agregados Média de pacotes agregados 1 1,33 4,44 Com relação ao uso do canal, o MAPAS foi muito mais eficiente, fazendo menos de 20% do número de transmissões feito sem agregar pacotes, o que levou a uma redução de mais de 29% no volume de dados trafegados. O uso de cabeçalhos foi ligeiramente acima da metade do usado quando não se aplicava agregação, e por consequência houve redução no overhead induzido. Os resultados de throughput e goodput devem ser vistos com cautela, pois o tempo levado para transmitir todos os pacotes variou de maneira muito significativa em função da técnica adotada. Nesses parâmetros, o método de Castro et al. [10] esteve entre a nova proposta e a rede sem agregação, como pode ser visto na tabela 6.1. Mesmo com a banda muito estrangulada, a nova proposta conseguiu prover QoS suficiente para o tráfego VoIP do cenário descrito, enquanto as demais abordagens não tornavam esse tráfego possível. Mais de 40% dos pacotes foram descartados por atrasos quando não se agregou pacotes ou quando o tempo de espera foi constante em 5ms, e quando do uso do MAPAS todos os pacotes foram entregues com sucesso. O delay variou entre 0 e 150ms quando não foi usada a nova técnica proposta, com uma média próxima de 75ms. Dada essa grande variação, o jitter observado foi de 60ms quando não se agregou pacotes e 48ms quando foi usada a técnica de Castro et al. [10]. Já quando a técnica aplicada foi a de espera máxima, o delay variou de 60 a 145ms, com uma média próxima de 100ms, mas a oscilação foi menor, o que é comprovado pelo valor do jitter de 19ms. O desempenho de agregação dos algoritmos reflete os resultados já apresentados, com o grupo de controle, que não agregou pacotes, tendo o mínimo, a média e o máximo de 70

85 agregação em 1, a proposta com espera fixa agregando em média entre 1 e 4 pacotes, com média geral em 1,33 por envio, e o MAPAS agregando entre 3 e 16 pacotes por envio, com média geral da rede de 4,44. Esses valores corroboram com os resultados vistos, pois mais agregação leva a menos transmissões, trazendo economia dos recursos da rede. Análise dos Resultados Do mesmo modo que no primeiro cenário, o MAPAS é muito superior à proposta de Castro et al. [10], que por sua vez é melhor do que não agregar pacotes. Usando a nova técnica, foi possível prover QoS em um cenário onde os demais métodos não conseguiam entregar mais de 60% dos pacotes, obtendo assim um aproveitamento mais eficiente dos recursos de rede. Também é possível ver o favorecimento de dispositivos móveis pela economia de energia. Nesse tipo de cenário também é possível ver como vantajosa a adoção da proposta deste trabalho como meio para prover QoS em redes de capacidade menor que o tipo de tráfego que deve ser suportado Terceiro Cenário: Rede Hierárquica Figura 6.18: Formato da rede no terceiro cenário, no qual há uma escala hierárquica entre os nós da rede, que devem sempre se reportar aos nós superiores O último cenário estudado é o da figura 6.18, em formato de árvore invertida, e com todos os enlaces iguais, para testar o MAPAS em um cenário em que ele não se beneficiasse da vantagem de considerar a diferença de velocidade dos enlaces. Descrição Nesse cenário, há 15 nós ligados de maneira hierárquica, com cada um dos nós da base (folhas) enviando dez mil pacotes ao nó do topo (raiz), sempre a cada 20ms, totalizando 80 mil pacotes. Essa topologia simula situações como a distribuição de unidades militares em um campo de batalha, com as unidades de base passando informações do front ao Quartel General por meio de suas unidades imediatamente superiores. Nessas situações, a banda também é muito limitada, e pode-se beneficiar da agregação de pacotes. O valor da banda, como no cenário anterior, foi o menor possível para prover QoS com ao menos uma das técnicas estudadas, que é de 57kBps, permitindo ao MAPAS e ao método de Castro et al. [10] prover qualidade para o tráfego descrito. As variáveis de tamanho do pacote de descoberta de rota e o tempo desejável de travessia tiveram os valores 1480 bytes e 93%, como no experimento anterior. 71

86 Resultados Os resultados obtidos nesse cenário podem ser vistos na tabela 6.2. Tabela 6.2: Resultados obtidos para o terceiro cenário de rede simulado. Sem agregar Castro et al. [10] MAPAS Número de transmissões Tempo de transmissão (ms) Total transmitido (bytes) Cabeçalhos enviados (bytes) Payload enviado (bytes) Goodput (kbps) 33,16 45,59 45,57 Throughput (kbps) 99,5 126,4 108,7 Overhead induzido (%) 66,67 63,93 58,09 Perda de pacotes (%) 15, Delay mínimo (ms) Delay máximo (ms) Delay médio (ms) 36,15 61,21 105,21 Jitter (ms) Mínimo de pacotes agregados Máximo de pacotes agregados 1 2,88 14 Média de pacotes agregados 1 1,55 3,57 O número de transmissões do MAPAS foi menor que a metade do número usado quando pacotes não foram agregados, e mais de 25% inferior ao da proposta com espera fixa. O volume de dados transmitidos também foi inferior, embora não de forma tão expressiva quanto nos dois primeiros experimentos. A redução no volume de cabeçalhos trafegados foi de mais de 30%. O goodput e o throughput dos dois métodos que empregam agregação agora são diretamente comparáveis, uma vez que o tempo total de simulação é similar. Dado o valor próximo do tempo e o mesmo valor de volume de payload, o goodput é praticamente o mesmo, mas a nova proposta possui um throughput muito menor, decorrente do menor volume de cabeçalhos. O overhead induzido ainda é menor quando o MAPAS é aplicado. Quando não houve agregação de pacotes, 15,37% dos pacotes foram descartados, o que tornaria impossível conduzir conversas VoIP na rede. Já no caso das abordagens com agregação, o descarte foi nulo. O delay variou entre 0 e 150ms com média de 36,15ms quando não houve agregação, entre 26 e 134ms com média de 61,21ms com o método de Castro et al. [10] e entre 67 e 145ms com média de 105,21ms para o MAPAS, todos dentro dos valores toleráveis, com a ressalva de que quando pacotes não foram agregados os descartes foram gerados por atrasos excessivos que não são considerados nesse levantamento. O jitter foi de 32ms, 20ms e 19ms, respectivamente, para quando não houve agregação, quando ela foi de espera fixa e quando ela foi de espera máxima (nova proposta). Os valores de 20ms e 19ms são excelentes para esse tipo de tráfego. O desempenho dos algoritmos foi de agregação de 1 a 2,88 pacotes, em média, para espera fixa, com média geral de 1,55 pacote por envio, e entre 1 e 14 pacotes com média 72

87 geral de 3,57 pacotes por envio com o MAPAS, valores que mais uma vez refletem os demais resultados. Análise dos Resultados Figura 6.19: Comparativo gráfico do número de transmissões realizado em cada cenário usando as três abordagens implementadas. Quando não há a presença de diferentes capacidades de enlace na rede, a diferença entre o MAPAS e a técnica de Castro et al. [10] é menor, e no último cenário estudado ambos os métodos provêem QoS para tráfego VoIP, mas a nova proposta ainda apresenta resultados melhores no âmbito da eficiência no aproveitamento do canal, já que precisa de menos cabeçalhos e faz muito menos envios, como visto na figura 6.19, trazendo como consequencia uma redução no volume transmitido, ilustrada na figura Em função dessa diferença, que pode ser o determinante entre poder ou não abrigar outros tráfegos paralelos na rede, ou mesmo conduzir apenas os diálogos VoIP, a técnica proposta também é superior nesse experimento, trazendo benefícios à rede e aos usuários. 73

88 Figura 6.20: Comparativo gráfico do volume em bytes transmitido em cada cenário usando as três abordagens implementadas. 6.3 Considerações Finais Os resultados obtidos pelo MAPAS são promissores, consistentemente superando os do método Hop-By-Hop de Castro et al. [10], que já são bem superiores ao que se espera das redes sem fios modernas. Desse modo, convém planejar os próximos passos da pesquisa dessa nova proposta, bem como a maneira que ela será inserida nas pilhas de redes de dispositivos reais. Além disso, é preciso contrastar os objetivos traçados inicialmente para a pesquisa realizada e os resultados obtidos, para medir quão próximos desses objetivos os resultados estão. No próximo capítulo serão feitas estas análises, com a conclusão do trabalho. 74