DANIEL HENRIQUE JOPPI. Implementação do Protocolo de Roteamento AntHocNet no Network Simulator 2

Transcrição

1 DANIEL HENRIQUE JOPPI Implementação do Protocolo de Roteamento AntHocNet no Network Simulator 2 Joinville 2011

2 UNIVERSIDADE DO ESTADO DE SANTA CATARINA BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO DANIEL HENRIQUE JOPPI IMPLEMENTAÇÃO DO PROTOCOLO DE ROTEAMENTO ANTHOCNET NO NETWORK SIMULATOR 2 Trabalho de conclusão de curso submetido à Universidade do Estado de Santa Catarina como parte dos requisitos para a obtenção do grau de Bacharel em Ciência da Computação Orientador: Doutor, Claudio Cesar de Sá Joinville 2011

3 DANIEL HENRIQUE JOPPI IMPLEMENTAÇÃO DO PROTOCOLO DE ROTEAMENTO ANTHOCNET NO NETWORK SIMULATOR 2 Este Trabalho de Conclusão de Curso foi julgado adequado para a obtenção do título de Bacharel em Ciência da Computação e aprovado em sua forma final pelo Curso de Ciência da Computação Integral do CCT/UDESC. Banca Examinadora: Orientador: Doutor, Claudio Cesar de Sá Membro: Doutor, Rafael Rodrigues Obelheiro Membro: Doutor, Cristiano Damiani Vasconcellos Joinville, 23 de novembro de 2011

4 A Deus. À minha mãe. Aos meus familiares e amigos. Àqueles que lutam por um mundo melhor.

5 AGRADECIMENTOS Aos professores do Departamento de Ciência da Computação pelos seus ensinamentos, em especial aos professores Claudio Cesar de Sá, Rafael Rodrigues Obelheiro e Roberto Silvio Ubertino Rosso Junior, pelos muitos puxões de orelha, pois sem eles não teria concretizado o trabalho. Aos meus pais, Nelson Luiz Joppi e Lucia Anita Zancanella Joppi, pelo grande incentivo na realização deste trabalho. Ao Bahia (Danilo Gonçalves da Cruz), Bolha (Fernando de Souza Rebelo), Cabelo (Cristian Rossi), Carioca (Fábio Merciris Dutra Thuller), Cavalo (Alessandro Hoss), Cicero (Cicero Gazola), Geladeira (Pedro Roman), Germano (Estevan Eduardo Diedrich), Joelho (Reinaldo Besen), Jogador (Rafael Ledoux Rosa), Julhote (Júlio César Zambonin), Lesko (Silvio Antônio Teston), Pepê (Pedro Lyra de Toledo e Gazel), Piraberaba (Fábio Haertel Kochhann), Sabugo (Fernando Garcia), Tchê (Éverton Da Silva Amorim), Velhão (Marcelo Preis Ferreira), Xunda (Tacio Basso) e demais Rangos Compatriotas pela confiança depositada nessa grande caminhada de realizações e conquistas.

6 Se nós soubéssemos o que estavamos fazendo, isto não seria chamado de pesquisa, seria? - Albert Einstein O único modo de evitar os erros é adquirindo experiência. Contudo, a única maneira de adquirir experiência é cometendo erros. (Autor Desconhecido)

7 RESUMO Neste trabalho será apresentada a implementação do protocolo de roteamento AntHocNet para redes móveis ad hoc (MANET - Mobile Ad hoc NETwork) no simulador de rede Network Simulator 2 (NS-2), pois atualmente não existe uma implementação válida para este protocolo, neste simulador. Com isso, o trabalho reforça o uso da Inteligência de Enxames (SI - Swarm Inteligence) em roteamento de redes. O projeto foi validado ao comparar os resultados obtidos entre o AntHocNet e AODV no NS-2, utilizando as mesmas métricas e cenários aplicados por Di Caro (Di Caro, Ducatelle e Gamberdella 2005), ao usar simulador QualNet. PALAVRAS-CHAVE: AntHocNet, AODV, Inteligência de Enxames, Rede Móvel Ad Hoc, NS-2, Simulação

8 ABSTRACT This work will present the implementation of the routing protocol AntHocNet for Mobile Ad Hoc Networks (MANET) in the network simulator Network Simulator 2 (NS-2), because currently there isn t a valid implementation for this protocol, this simulator. With that, the work reinforces the use of Swarm Intelligence (SI) in routing networks. The project was validated by comparing the results between the AntHocNet and AODV in NS-2, using the same metrics and scenarios applied by Di Caro (Di Caro, Ducatelle and Gamberdella 2005), using QualNet simulator. KEYWORDS: AntHocNet, AODV, MANET, Mobile Ad Hoc Networks, NS-2, Simulation, Swarm Intelligence

9 LISTA DE FIGURAS 2.1 Mobilidade dos nós na MANET Descoberta de rota do AODV na MANET, onde o nó N6 deseja iniciar uma comunicação com o nó N Trilha de Feromônio entre a Colônia e a Fonte de Alimento Trilhas de feromônio entre o nó origem N1 e o nó destino N Gráfico comparativo entre AntHocNet e o AODV, no Cenário 1, verificando a média de delay, proporção de pacotes entregues e a taxa de overhead causado a rede (Di Caro, Ducatelle e Gamberdella 2005) Gráfico comparativo entre AntHocNet e o AODV, no Cenário 2, verificando a média de delay, proporção de pacotes entregues e a taxa de overhead causado a rede(di Caro, Ducatelle e Gamberdella 2005) Gráfico comparativo entre AntHocNet e o AODV, no Cenário 3, verificando a média de delay, proporção de pacotes entregues e a taxa de overhead causado a rede (Di Caro, Ducatelle e Gamberdella 2005) Configuração da Máquina Virtual Interfaces implementadas pelo AntHocNet para interagir com o NS Diagrama da hierarquia das classes de formigas Classe PheromoneTable gerencia as tabelas de feromônio Diagrama de classe de PheromoneTable Trilhas de feromônio gerenciadas pelo formigueiro Algorítimo de atualização de feromônio Diagrama de classe de AntNest

10 4.9 Diagrama de classe de AntHocNet Algorítimo de recebimento de pacotes Movimento dos nós n, representados por vetores n Emissão de formiga proativa por broadcast nos 2 primeiros saltos Gráfico comparativo entre AntHocNet e AODV no Cenário 1, sobre o Atraso Médio Fim-a-Fim Gráfico comparativo entre AntHocNet e AODV no Cenário 1, sobre a Taxa de Pacotes Entregues Gráfico comparativo entre AntHocNet e AODV no Cenário 1, sobre o Overhead de Roteamento Gráfico comparativo entre AntHocNet e AODV no Cenário 2, sobre o Atraso Médio Fim-a-Fim Gráfico comparativo entre AntHocNet e AODV no Cenário 2, sobre a Taxa de Pacotes Entregues Gráfico comparativo entre AntHocNet e AODV no Cenário 2, sobre o Overhead de Roteamento Gráfico comparativo entre AntHocNet e AODV no Cenário 3, sobre o Atraso Médio Fim-a-Fim Gráfico comparativo entre AntHocNet e AODV no Cenário 3, sobre a Taxa de Pacotes Entregues Gráfico comparativo entre AntHocNet e AODV no Cenário 3, sobre o Overhead de Roteamento

11 LISTA DE TABELAS 2.1 Tabela comparativa entre as classificações dos protocolos de roteamentos para MANET (Przybysz e Júnior 2005) Tabela de roteamento do nó N6, antes do deslocamento do nó N Tabela de roteamento do nó N6, após o recebimento da RERR Nova tabela de roteamento do nó N6, após o deslocamento do nó N Nova tabela de roteamento do nó N Tabela com as estruturas de dados do AntHocNet Tabela com as constantes globais disponibilizadas pela classe AntHocNetUtils Tabela metadados da classe AntBasicPacket Tabela metadados da classe AntBackPacket Tabela metadados da classe AntRepairPacket Tabela das estruturas de armazenagem da classe PheromoneTable Tabela das estruturas de dados da classe AntNest Tabela de formigas que são enviadas periodicamente

12 LISTA DE ABREVIATURAS ACO Ant Colony Optimization ANSI Ad Hoc Networking with Swarm Intelligence AODV Ad-hoc On demand Distance Vector ARA Ant-Colony Based Routing Algorithm CBR Constant Bit Rate DSDV Destination Sequenced Distance Vector DSR Dynamic Source Routing IETF Internet Engineering Task Force MANET Mobile Ad-hoc NETwork NS-2 Network Simulator 2 PRBA PRoactive Backward Ant PRFA PRoactive Forward Ants PSO Particle Swarm Optimization REBA REactive Backward Ant REFA REactive Forward Ant RERR Route ERRor RRBA Route Repair Backward Ant RREP Route REPly RREQ Route REQuest RRFA Route Repair Forward Ant RWP Random Waypoint SI Swarm Intelligence TSP Traveling Salesman Problem VM Virtual Machine ZRP Zone Routing Protocol

13 x SUMÁRIO 1 INTRODUÇÃO CONTRIBUIÇÃO DO TRABALHO OBJETIVO GERAL Objetivos Específicos ORGANIZAÇÃO DO TRABALHO Capítulo 1: Introdução Capítulo 2: Roteamento em Rede Ad Hoc Capítulo 3: Inteligência de Enxames Capítulo 4: Implementação da Proposta Capítulo 5: Modelagem dos Cenários Capítulo 6: Simulação do AntHocNet Capítulo 7: Conclusão ROTEAMENTO EM REDE AD HOC PROTOCOLOS Classificação Pró-ativo Reativo Híbrido AODV - Ad-hoc On demand Distance Vector CONSIDERAÇÕES DO CAPÍTULO INTELIGÊNCIA DE ENXAMES PRINCÍPIO BIOLÓGICO

14 3.2 HEURÍSTICA DE COLÔNIA DE FORMIGAS ACO APLICADO A ROTEAMENTO AntHocNet Componente Reativa Componente Pró-ativo Quebras de Conexão Comparativo entre AntHocNet e AODV CONSIDERAÇÕES DO CAPÍTULO IMPLEMENTAÇÃO DA PROPOSTA AMBIENTE DE DESENVOLVIMENTO NETWORK SIMULATOR IMPLEMENTAÇÃO DO ANTHOCNET Estruturas de Dados do AntHocNet Classe AntHocNetUtils: constantes globais Classe AntBasicPacket: formiga Classe PheromoneTable: tabela de feromônio Classe AntNest: formigueiro Classe AntHocNet: protocolo CONSIDERAÇÕES DO CAPÍTULO MODELAGEM DOS CENÁRIOS CRIAÇÃO AUTOMATIZADA DE TCL CENÁRIO 1: AUMENTO DO TEMPO DE PARADA DOS NÓS CENÁRIO 2: AUMENTO DE NÓS CENÁRIO 3: AUMENTO DA ÁREA CONSIDERAÇÕES DO CAPÍTULO xi

15 6 SIMULAÇÃO DO ANTHOCNET IMPLICAÇÕES NA IMPLEMENTAÇÃO SIMULAÇÃO E VALIDAÇÃO Resultado da Simulação no Cenário Resultado da Simulação no Cenário Resultado da Simulação no Cenário CONSIDERAÇÕES DO CAPÍTULO CONCLUSÃO REFERÊNCIAS

16 1 1 Introdução A facilidade de encontrar informações nos dias de hoje, se deve ao grande desenvolvimento das redes de comunicação. Isto é, a troca de informações onde antes seria praticamente impossível, devido às dificuldades de acesso ou mesmo pela complexidade do terreno. Tendo como exemplo um desastre natural ou uma guerra onde facilmente superadas ao se transmitir dados via rede wireless ou rede sem fio (Harte 2004). Esse tipo de rede, diferencia-se a grosso modo, das redes guiadas convencionais, pela simples troca da transmissão de dados física, via cabos, por uma transmissão de dados utilizando ondas de rádio. Essa mudança, ao se utilizar transmissões de dados sem fio possibilita uma grande flexibilidade ao se montar uma rede, mas isso, segundo Johnson (Johnson e Maltz 1996), também proporcionou o surgimento de tipos mais específicos de redes wireless, isto é, de acordo com a sua topologia ela pode ser separada em redes wireless estruturadas e redes wireless não estruturadas. A rede wireless não estruturada, ou rede móvel Ad Hoc (MANET - Mobile Ad hoc NETwork), tema deste trabalho, é caracterizada por não precisar de nenhuma infraestrutura, nem na fase de formação (Haas et al. 2002). Isto é, diferente da rede wireless estruturada, que necessita de pontos de acesso fixos ou de estação base para se poder iniciar uma transmissão de dados. A MANET é formada por um conjunto de nós interligados, com liberdade de movimentação, sendo esta é a causa da constante alteração nas tabelas de roteamento de todo o conjunto (Haas et al. 2002). Assim sendo, a topologia das MANETs proporcionam um desafio para a determinação de rotas, devido à sua forma dinâmica, que pode mudar de maneira imprevisível, afetando as tabelas de roteamento de todo o conjunto. Uma vez que um nó entre ou saia do conjunto da MANET, é gerada uma modificação nas rotas da rede. Essa mudança pode ter consequências significativas, no caso de um nó intermediário desligar-se do conjunto e causar uma quebra de comunicação, e, consequentemente, gerar perdas de pacotes entre nós que dele dependem. Outra característica da MANET, é que o roteamento de pacotes é realizado em cada nó do conjunto.

17 1 Introdução 2 A variação da topologia da MANET, a torna suscetível às quebras de conexões necessitando que os protocolos de roteamento sejam capazes de se adaptar a esse ambiente dinâmico. Os protocolos de roteamento usados na MANET podem ser classificados em: Pró-ativos como o DSDV (Perkins e Bhagwat 1994), que exige que cada nó da rede possua rotas sempre atualizadas para os demais integrantes, o que pode causar uma sobrecarga devido a quantidade elevada de pacotes emitidos, sugerindo altas taxas de overhead. Em contrapartida, os protocolos classificados como Reativos, como por exemplo o AODV (Perkins e Roye 1999) e DSR (Johnson e Maltz 1996), possibilitam uma redução no overhead ao restringir o envio de pacotes broadcast apenas quando houver a necessidade de buscar novos nós ou quando é detectada uma quebra de conexão. Em muitos casos, a MANET necessita da participação de um terceiro nó, ou mais nós intermediários, para encaminhar dados de um ponto a outro na rede. Essa cooperação entre o conjunto de nós interligados da MANET se assemelha ao comportamento coletivo de alguns insetos como abelhas, formigas ou cupins. Isolados, são como agentes com capacidades limitadas de resolver seus problemas, mas quando agrupados, seja na intenção de buscar alimento ou para proteger a colônia, tais insetos, tendem a apresentar um comportamento coletivo inteligente (White, Pagurek e Oppache 1998). Essa observação do comportamento coletivo de certas espécies, possibilitou o desenvolvimento de pesquisas e estudos, inclusive na computação como o Swarm Intelligence (SI) (Beni e Wang 1989) ou Inteligência de Enxames que pode ser divido em duas ramificações: Particle Swarm Optimization (PSO) ou Otimização por Enxames de Partículas, desenvolvida por (Kennedy e Eberhart 2001), cuja heurística é inspirada na observação da coreografia de animais, como a de pássaros voando em bando e de peixes nadando em cardumes; Ant Colony Optimization (ACO) ou Otimização por Colônias de Formigas, desenvolvido por (Dorigo e Stützle 2006), esta heurística é inspirada no comportamento da colônia de formigas em sua busca por alimento. O ACO foi inicialmente utilizado para resolver problemas como do caixeiro viajante, mas hoje é possível encontrar várias aplicações, sendo uma delas no uso do descobrimento de rotas numa rede ao aplicar o uso de agentes móveis (exemplo: formigas) e estigmergia (exemplo: feromônio). Estas propriedades, de acordo com Kassabalidis

18 1 Introdução 3 (Kassabalidis et al. 2001), tornam o SI capaz de atender aos requisitos da MANET. Isto é, conseguem se adaptar muito bem à estrutura dinâmica que essa rede possui, usufruindo do sistema de comunicação indireta, no caso o feromônio, que pode ser utilizado para decidir uma rota adequada até o destino. A escolha da rota é probabilística, geralmente o caminho que contém a maior quantidade de feromônio têm preferência, e é um método comum em protocolos de roteamento que se baseiam em ACO, tais como os protocolos: ARA (Gunes, Sorges e Bouazzi 2002), AntHocNet (Ducatelle 2007), ANSI (Rajagopalan e Shen 2005) e o Termite (Roth e Wicker 2003). Neste trabalho, é proposto uma implementação do protocolo de roteamento AntHoc- Net (Ducatelle 2007). Visto que em comparações feitas com o AODV, o AntHocNet se mostrou mais escalável ao apresentar melhores taxas na entrega de pacotes, atraso médio de delay, num cenário onde a quantidade de nós variava conforme o tempo. Tendo sido testados e simulados no QualNet (QualNet 2011). A proposta é realizar as mesmas simulações, só que desta vez no Network Simulator 2 (NS-2) (NS ). O NS-2 é um simulador de código fonte aberto e gratuito, além de ser muito utilizado nos meios acadêmicos. A validação é feita através da comparação dos protocolos AntHoc- Net e o AODV, após a simulação e análise dos resultados obtidos no NS-2. Os parâmetros para a avaliação seguem os mesmos modelos de cenários e métricas usadas por Di Caro (Di Caro, Ducatelle e Gamberdella 2005) no QualNet. 1.1 Contribuição do Trabalho Dada a importância do protocolo de roteamento AntHocNet para MANET, e a análise dos seus experimentos no QualNet (QualNet 2011), um simulador comercial, neste trabalho é apresentado a implementação do protocolo de roteamento AntHocNet no simulador de rede NS-2 (NS ). O NS-2 é um simulador é livre e gratuito, além de estar difundido nos meios acadêmicos. Atualmente não exitei uma implementação válida para o protocolo de roteamento AntHocNet, em tal simulador. Esta implementação reforça o uso da SI em roteamento de

19 1 Introdução 4 redes, possibilitando que novos estudos possam ser desenvolvidos a partir desse trabalho. 1.2 Objetivo Geral O principal objetivo deste trabalho é implementar o protocolo de roteamento AntHoc- Net no simulador de rede NS-2. Sendo a validação feita ao realizar a comparação dos resultados obtidos entre o AntHocNet e o AODV no NS-2. A análise é realizada seguindo as mesmas configurações de cenários e métricas utilizadas nas simulações feitas por Di Caro no simulador QualNet Objetivos Específicos Os objetivos específicos para a resolução deste trabalho envolvem o estudo dos conceitos que tratam sobe: Embasamento teórico sobre das MANET; Estudado do roteamento numa MANET, dando enfoque à análise do protocolo de roteamento AODV; Embasamento teórico sobre SI; Estudar SI para ambiente de roteamento para MANET, dando enfoque ao estudo do protocolo de roteamento AntHocNet; Implementar o protocolo de roteamento AntHocNet no simulador de rede NS-2; Modelagem dos cenários a serem usados nas simulações no NS-2; Análise das métricas utilizadas no QualNet 4.0, a serem usadas no comparativo dos protocolos no NS-2. Executar as simulações dos cenários modelados no NS-2 para comparar os resultados entre os protocolos: AODV e AntHocNet; Validar a proposta através dos resultados obtidos na simulação do NS-2.

20 1 Introdução Organização do Trabalho A formulação deste trabalho é dividida em sete capítulos. Dos quais as primeiras partes tratam dos levantamentos bibliográficos das definições da MANET e SI. Apresentando as características dos protocolos de roteamento AODV e AntHocNet. O estudo das partes teóricas serve de base para o desenvolvimento das próximas partes, criando capítulos que descrevem a implementação do protocolo AntHocNet no NS-2, assim como a modelagem dos cenários e as métricas a serem usadas nas simulações. A simulação dos protocolos AODV e AntHocNet, é apresentada nas últimas partes do trabalho, onde são gerados gráficos comparativos, proporcionando a análise dos resultados obtidos Capítulo 1: Introdução No Capítulo 1 é apresentada a síntese do trabalho sobre a implementação do protocolo de roteamento AntHocNet. Assim como o objetivo geral do trabalho e seus objetivos específicos para a confecção e organização de cada capítulo Capítulo 2: Roteamento em Rede Ad Hoc No Capítulo 2 são estudados o funcionamento e características da MANET. O levantamento bibliográfico é feito de forma a descrever os diferentes tipos de protocolos de roteamento utilizados nas MANETs. Esse estudo caracteriza a análise dos protocolos pró-ativos, reativos e híbridos, como também, serve de base para apresentar o protocolo de roteamento AODV Capítulo 3: Inteligência de Enxames No Capítulo 3 é apresentado o levantamento bibliográfico da utilização da Inteligência de Enxames no roteamento de redes, dando enfoque à heurística das Colônias de Formigas no descobrimento de rotas.

21 1 Introdução 6 O estudo se baseia na explicação do funcionamento biológico da heurística das Colônias de Formigas, bem como a sua utilização na resolução do problema do caixeiro viajante. Essa base é utilizada para a definição do ACO, aplicado no roteamento de redes, descrevendo o protocolo AntHocNet, onde também é realizado o estudo das análises de resultados de simulação realizadas entre o AntHocNet e o AODV no simulador de rede QualNet Capítulo 4: Implementação da Proposta No Capítulo 4 são apresentados os modelos das classes desenvolvidas para a implementação do protocolo de roteamento AntHocNet no NS-2, descrevendo o funcionamento das principais funções de roteamento da implementação, segundo a arquitetura de classes do simulador Capítulo 5: Modelagem dos Cenários No Capítulo 5 é descrita a modelagem dos cenários utilizados na simulação no NS- 2. Essa modelagem se baseia na estruturação de fórmulas matemáticas para a obtenção das informações do comportamento do cenário e assim, gerar os scripts em TCL com o comportamento semelhante ao descrito na mesma simulação feita por Di Caro (Di Caro, Ducatelle e Gamberdella 2005) no QualNet Capítulo 6: Simulação do AntHocNet No Capítulo 6 é realizada a simulação e validação do AntHocnet no NS-2, tendo como objetivo fundamental verificar os resultados gerados seguindo os mesmos parâmetros e cenários utilizados por Di Caro ao comparar o AntHocNet com o AODV Capítulo 7: Conclusão No Capítulo 7 é elaborada a síntese dos conhecimentos obtidos nas etapas anteriores, em que são apresentadas as conclusões sobre a implementação e os resultados gerados pela simulação dos protocolos AODV e AntHocNet, gerando as propostas de trabalhos futuros

22 1 Introdução 7 sobre possíveis melhorias no AntHocNet.

23 8 2 Roteamento em Rede Ad Hoc As redes wireless, ou redes sem fio, são caracterizadas por facilitarem a montagem de uma rede, pois não necessitam de cabos para conectar os computadores, apenas do ar. Em outras palavras, a transmissão de dados é feita via ondas de rádio. Isto descarta a utilização de switches e hubs, bastando apenas que cada computador possua uma placa de rede que emita e receba ondas de rádio direcionadas a um roteador fixo. Sendo assim, se houver o interesse de um novo nó entrar em determinada rede, este necessariamente precisa estar no raio de transmissão do roteador da mesma. Em seu livro, Tanenbaum (Tanenbaum 2003) descreve uma rede wireless formada por nós móveis, ou ainda: computadores móveis, com liberdade de se movimentarem pelo cenário, sem a necessidade de se prenderem a um roteador fixo para iniciarem uma transmissão de dados com outro membro da rede. Isso possibilita a introdução de um novo problema nos sistemas de comunicação, pois inicialmente é necessária a localização deste nó móvel na rede, para que assim seja gerada a rota e se inicie a transmissão dos pacotes de dados até ele. Esta nova característica de movimento dos nós possibilitou criar redes wireless livres de pontos acesso fixos, proporcionando criar redes sem fio totalmente móveis, também conhecidas como redes móveis Ad Hoc (MANET - Mobile Ad hoc NETwork). Assim segundo Johnson (Johnson e Maltz 1996), pode-se classificar as redes wireless em duas topologias. A primeira diz respeito às redes wireless estruturadas, já que estas necessitam de uma infraestrutura fixa previamente instalada, com por exemplo roteadores fixos. A outra forma são as redes wireless não estruturadas, ou MANETs, sendo que estas não necessitam de infraestrutura. As MANETs diferem significativamente das convencionais redes, pois apresentarem uma topologia dinâmica onde as interligações wireless entre os membros da rede são descentralizadas, isto é, não existem equipamentos que centralizam a função de roteamento, mas sim, um conjunto de indivíduos que cooperam entre si, dividindo as funções de roteamento. Assim, a saída de um dos nós da rede não acarretará no fim da mesma, pois os demais nós se auto-organizam para manter a estrutura de comunicação da rede

24 2 Roteamento em Rede Ad Hoc 9 funcionando. Os protocolos do roteamento utilizados em redes cabeadas podem ser divididos basicamente em protocolos de roteamento baseados em vetor de distância (distance-vector) e baseados em estado do enlace (link state) (Tanenbaum 2003). Qualquer um deles pode ser numa MANET. Ambos permitem que um nó-origem localize pelo menos uma rota para alcançar um determinado destino, mas estudos realizados mostram que ao utilizar protocolos de rede cabeada numa MANET geram inconveniências, como por exemplo na demora para convergirem as novas atualizações sobre a topologia da rede, além de inserirem muitas informações nos pacotes (Perkins e Bhagwat 1994). Devido à capacidade limitada de transmissão numa rede wireless, os pacotes devem possuir o mínimo de informações necessárias para o roteamento, de maneira a não comprometer a estrutura da rede. Uma qualidade da MANET, é que a sua estrutura de rede pode ser criada rapidamente, sem a existência prévia de nenhuma infraestrutura. Isto pode acarretar consequências que, de acordo com Haas et al. (Haas et al. 2002), proporcionam que seus nós possam entrar e sair da estrutura da rede a qualquer momento, muitas vezes sem nenhum aviso, e possibilitando quebras na comunicação entre outros nós da rede. Geralmente, as MANETs são formadas por poucos usuários ao atender uma finalidade específica e, em seguida são desfeitas. São alguns exemplos do uso das MANETs: Operações táticas - para estabelecer rapidamente uma rede militar durante o envio de tropas para um terreno hostil; Missões de resgate - para comunicação em áreas sem a devida cobertura wireless com pontos de acesso; Uso comercial - para uso em conferências ou em reuniões executivas. Esta mobilidade que os nós da rede possuem, podem gerar consequências para a topologia da MANET, como observado na Figura 2.1, onde o nó E é responsável pela comunicação de duas partes distintas da MANET (Figura 2.1a), sendo assim, a sua presença ou ausência, pode alterar a estrutura de comunicação de todo conjunto. Isto é demonstrado quando este nó se desliga da MANET, e causa uma quebra na comunicação entre os demais membros do conjunto. Desta forma, a MANET passará a ser dividida em

25 2 Roteamento em Rede Ad Hoc 10 duas redes distintas (Figura 2.1b): uma com os nós A, B e C (rede 1), e outra com os nós D e F (rede 2). Figura 2.1: Mobilidade dos nós na MANET Há duas situações para que essas redes possam se conectar novamente: a primeira seria o aparecimento de um nó que realize pelo menos uma ligação com as redes 1 e 2. A outra opção é a aproximação dos nós das redes em função do movimento, isto é, as redes poderiam se movimentar, e assim ficarem mais próximas fisicamente uma da outra não necessitando que um novo nó as interligue. Os nós da MANET, segundo Yoshitaka (Yoshitaka et al. 2006), podem se comunicar uns com os outros a qualquer momento, e sem restrições, exceto quando não existir nenhuma rota que os conecte. Essa característica possibilita que a MANET realize uma troca de informações que independe das mudanças na topologia da rede. Em Haas et al. (Haas et al. 2002) é comentado que as diferenças de padrões de hardware e da propagação das ondas eletromagnéticas, tornam as condições variáveis com o tempo, e podem resultar em distintas conexões entre os nós vizinhos, isto é, enviar uma informação de um nó A para um nó B por uma determinada rota, pode não ser a mesma ao enviar o mesmo pacote do nó B para o nó A. O resultado é uma variação de rota, proporcionado, por exemplo, pela diferença na capacidade de transmissão de cada nó, podendo gerar um tempo de resposta variado ao se detectar uma mudança na topologia de rede.

26 2 Roteamento em Rede Ad Hoc 11 Portanto, é necessário que os protocolos de roteamento para a MANET, sejam capazes de detectar estas variações de topologia, e realizarem as alterações nas rotas, de acordo com a necessidade da rede. Aliado a estas características, o protocolo deve ser capaz de lidar com as quebras de comunicação e com o atraso no roteamento de pacotes. Uma classificação bastante usada para dividir os protocolos de roteamento utilizados nas MANETs, podem ser separados em pró-ativos, reativos ou híbridos (Liang e Haas 2006). 2.1 Protocolos Os protocolos de roteamento são protocolos utilizados especificamente para realizar o gerenciamento de rotas numa rede de comunicação, isto é, são responsáveis por garantir que um membro da rede consiga enviar suas mensagens para seu destino, sem se preocupar como, ou por onde ela irá passar (Tanenbaum 2003). Normalmente, numa rede estruturada, existe pelo menos um nó responsável pela função de roteamento na rede, conhecido como roteador. Sendo assim, pode-se afirmar que numa MANET, todos os integrantes acumulam a função dos roteadores. Geralmente, cada roteador ao se conectar na rede, certifica-se de conhecer seus vizinhos, isto é, quais os nós que poderão auxiliá-lo no envio de pacotes, ou também chamados de gateways (Tanenbaum 2003). Dependendo do protocolo de roteamento adotado, o roteador irá procurar mais informações na rede para formar a sua tabela de roteamento, como por exemplo verificar a distância ou o custo da rota até o destino. Os protocolos de roteamento podem ser divididos em: Pró-ativos, Reativos e Híbridos. Um protocolo de roteamento pró-ativo, requer que cada nó mantenha uma tabela de roteamento atualizada, de forma a possuir uma rota sempre disponível para todos os nós da MANET. O DSDV (Perkins e Bhagwat 1994) é um exemplo de protocolo de roteamento pró-ativo. Nos protocolos de roteamento reativos, o nó não tem a responsabilidade de manter uma rota atualizada para um determinado destino, de maneira que quando necessite comunicar-se com tal destino, iniciará um processo de busca por rota. Os protocolos de roteamento AODV (Perkins e Roye 1999) e DSR (Johnson e Maltz 1996) são exemplos de protocolos reativos. Um protocolo reativo evita ficar emitindo pacotes de controle, com isso tentar diminuir

27 2 Roteamento em Rede Ad Hoc 12 o overhead causado à rede, mas no momento em que uma rota conhecida sua sofra uma alteração, sugerindo que um nó intermediário tenha desaparecido, cria-se a necessidade do nó origem refazer a rota, emitindo novos pacotes de busca por rota. Geralmente essas busca são realizadas via broadcast, e podem contribuir para o congestionamento da rede, o que se agrava caso a rede possua uma quantidade elevada de nós. Um protocolo de roteamento híbrido, como por exemplo o ZRP (Haas 1997), que foi proposto para combinar o benefício de ambas as características, utilizando as estratégias pró-ativas somente quando um nó necessitar manter suas informações atualizadas sobre os nós contidos na sua zona de roteamento, de forma que a ligação com os demais nós fora da sua zona é feita usando as características reativas Classificação Segundo Tanenbaum (Tanenbaum 2003), de acordo com o modelo OSI, a terceira camada, também conhecida como camada de rede, é responsável pelo roteamento que envolve duas operações básicas: a determinação das rotas e o encaminhamento de pacotes (Câmara 2000). Estas operações são realizadas por cada membro no conjunto da MANET, isto demonstra a característica dos nós possuírem a função de roteamento de pacotes. Por isso, segundo Bisnik (Bisnik, Abouzeid e Busch 2006), os protocolos de roteamento desenvolvidos para redes guiadas não trabalham eficientemente nas MANETs, pois elas não possuem uma infraestrutura regular, com switches e roteadores por exemplo. Destaca-se o fato de que os nós da rede possuem uma distância limitada para transmissão e recebimento de dados, com os demais integrantes do conjunto. Os protocolos de roteamento podem ser classificados conforme a construção de suas rotas, em protocolos pró-ativos, protocolos reativos ou protocolos híbridos (Liang e Haas 2006) Pró-ativo Protocolos pró-ativos guardam o máximo de informações sobre os nós da MANET em suas tabelas de roteamento. As rotas são periodicamente atualizadas, independente de serem usadas. Essa característica, possibilita a vantagem de sempre se ter uma rota para um nó destino quando esta for solicitada (Bisnik, Abouzeid e Busch 2006) (Liang e Haas 2006). Possuir informações prévias sobre determinadas rotas, possibilita que os nós possam

28 2 Roteamento em Rede Ad Hoc 13 iniciar transmissões rapidamente, uma vez que já possuam pelo menos um caminho para o destino (Inkinen 2004). Apesar dessa vantagem, os protocolos de roteamento pró-ativos necessitam de uma grande quantidade de armazenamento, largura de banda e processamento para manter as tabelas de roteamento atualizadas em cada nó da MANET. O maior problema dos protocolos pró-ativos são causados pelas constantes atualizações que devem ser realizadas cada vez que ocorre uma mudança na MANET, como quando um novo nó entra na rede ou um antigo nó a deixa. O mesmo pode ocorrer quando um nó se move para um novo local, necessitando que conheça os novos nós vizinhos. Desta forma, todos os nós na rede precisarão procurar uma nova rota para este nó. Aumentando o overhead na rede, pois cada requisição de rota, exige uma transmissão de pacotes via broadcast, para todos os nós contidos no conjunto da MANET. Esses problemas são característicos de redes com grandes variações na quantidade ou na composição de nós, já em redes de pequeno porte, ou que possuem poucos nós, os protocolos de roteamento pró-ativos podem funcionar de forma eficiente Reativo Os protocolos reativos guardam apenas as informações sobre as rotas que são de seu interesse ou que necessitem de sua participação para comunicação entre os nós da MANET (Bisnik, Abouzeid e Busch 2006) (Liang e Haas 2006). Pode se dizer que esses protocolos atendem os pedidos de rota sobre demanda, isto é, somente quando um nó da rede deseja iniciar a comunicação com um outro que o protocolo fará a busca do caminho. Isso pode acarretar um atraso até que a nova rota seja descoberta e comunicada ao nó que deu origem a requisição. Segundo Inkinen (Inkinen 2004), tal tempo de atraso para iniciar uma nova comunicação aumenta significantemente com acréscimo de nós na MANET. Para minimizar a taxa de envio de mensagens de controle, os nós da rede mantém armazenadas apenas as rotas que estão sendo utilizadas. Uma das vantagens de se adotar esta estratégia, é de diminuir significativamente a quantidade de informações que serão guardadas em cada nó da rede. Mas tem a desvantagem, de sempre que necessitar de uma rota para um nó inexistente na tabela de roteamento, implicará num tempo de espera, até que esta nova rota seja construída. Esta desvantagem também se aplica caso um nó intermediário se desligue do conjunto no mo-

29 2 Roteamento em Rede Ad Hoc 14 mento que a rota estiver em uso Híbrido Protocolos de roteamento híbridos são os que combinam tanto estratégias pró-ativas quanto reativas. Isso pode ser aplicado quando se utiliza características pró-ativas com os nós da rede que estão próximos fisicamente, enquanto que os nós mais distantes se localizam de forma reativa (Inkinen 2004) (Liang e Haas 2006). Tabela 2.1: Tabela comparativa entre as classificações dos protocolos de roteamentos para MANET (Przybysz e Júnior 2005). Características Pró-Ativo Reativo Híbrido Troca de Informações Periódica Quando Ambos sobre a topologia necessária da MANET Disponibilidade Sempre Quando Ambos de rota disponíveis necessária Como lida com Atualizações Manutenção Ambos mobilidade dos nós Periódicas de rota Tráfego de mensagens Alto Baixo Médio de controle A vantagem de se combinar essas duas estratégias tão diferentes, pode ser analisada, pela comparação demonstrada na Tabela 2.1. Pode-se ampliar, por exemplo, a capacidade de resposta de um protocolo pró-ativo, de maneira que poderia utilizar uma rota para um nó próximo, imediatamente após a requisição desta. Ou mesmo, quando este nó estiver se comunicando com um nó distante e ocorrer uma quebra de comunicação, bastando que os nós intermediários recuperem a rota com base nas informações de seus nós vizinhos. Apesar dos protocolos híbridos possibilitarem combinar ambas as características, a Internet Engineering Task Force (IETF MANET 2008) sugeriu o protocolo reativo AODV como possível padrão adotado em MANETs.

30 2 Roteamento em Rede Ad Hoc AODV - Ad-hoc On demand Distance Vector O protocolo de roteamento AODV, foi proposto por Perkins (Perkins e Roye 1999) ao verificar que o DSDV possuía o problema de contínuos envios de mensagens de atualizações por rotas, aumentando o tráfego de pacotes de controle na rede e, consequentemente, aumentando o overhead. Segundo Perkins (Perkins e Roye 1999), as emissões de pacotes do DSDV cresciam na proporção de (n 2 ), onde n é o número de nós na rede. Este protocolo também exige que cada nó mantenha uma rota para cada destino dentro da MANET, sendo que dificilmente um nó irá utilizar todas estas rotas. Por este motivo, o AODV foi proposto com a diferença que os nós adicionam apenas rotas que são de seu interesse, assim, é considerado um protocolo reativo e é candidato a virar um padrão para a MANET, segundo a IETF (IETF MANET 2008). O processo de descobrimento de rota começa assim que um nó necessitar se comunicar com outro nó, o qual não tem nenhuma informação na sua tabela de roteamento. Assim, o nó inicia a busca por uma rota, enviando um pacote RREQ (Route Request) via broadcast para todos seus vizinhos, que por sua vez retransmitem o pacote. Um pacote RREQ contém: < source_addr ; source_sequence_num ; broadcast_id ; dest_addr ; destination_sequence_num ; hop_cnt > Como no DSDV, o protocolo AODV mantém um número de sequência, a fim de manter as suas rotas atualizadas, verificando se o pacote que lhe foi transmitido é atual ou antigo. Este número de sequência é denotado da seguinte forma: Sxxx_N i, onde N i representa o nó onde for criado e Sxxx representa o valor do número de sequência, que é incrementado cada vez que as conexões do nó em questão, se alteram, devido a modificações na topologia da rede. No pacote RREQ, contém os números de sequência tanto do nó origem (source_ sequence_num) como do nó destino (destination_sequence_num). Ao retransmitir o RREQ, o nó incrementa a quantidade de saltos (hop_cnt). Estes pacotes, também possuem um identificador chamado de broadcast_id, que ao ser recebido pelo nó é adicionado temporariamente na tabela de roteamento, guardando também, o endereço do nó origem (source_addr) onde o gateway corresponde ao nó que

31 2 Roteamento em Rede Ad Hoc 16 o enviou. O identificador possibilita que o nó evite retransmitir o mesmo pacote RREQ, prevenindo a formação de loops, ao descartá-lo. Quando um nó recebe um pedido de rota, ao qual possui o nó destino contido na tabela de roteamento, este verifica se o número de sequência do nó destino que está guardado na tabela de roteamento é mais recente que o contido no pedido. Se for, é enviado um RREP (Route Reply) para o nó de origem contendo a rota. Caso o nó não possua uma rota para o destino ou o número de sequência do pacote for o mais recente, este nó retransmite a mensagem. O RREP possui os seguintes campos: < source_addr ; dest_addr ; destination_sequence_num ; hop_cnt ; lifetime > Ao receber o pacote RREP, o nó adiciona o endereço do destino (dest_addr), associando o nó que o enviou como gateway. Assim, ao ser enviada para o nó de origem (source_addr), o RREP incrementa a quantidade de saltos (hop_cnt) em cada nó que passar. É interessante ressaltar que ao contrário do RREQ, o RREP é enviado para o nó origem por apenas uma rota (ver Figura 2.2). Se no processo de comunicação um nó intermediário desaparecer, será necessário que seja iniciada uma nova descoberta de rota. A detecção de quebra de comunicação com o nó é detectada utilizando mensagens hello periódicas. As mensagens são enviadas num intervalo de tempo regular pelo nó aos seus nós vizinhos envolvidos na transmissão. Desta forma, se um nó não receber o hello de um nó vizinho no devido período de tempo, assumese que ocorreu uma quebra na comunicação e o nó realiza uma nova busca enviando um RREQ (Chakeres e Belding-Royer 2004). Quando um nó intermediário descobre uma quebra de comunicação, de acordo com Chakeres (Chakeres e Belding-Royer 2004), este envia um pacote RERR (Route Error) via broadcast para os nós vizinhos, envolvidos na comunicação, que retransmitem o RERR. Se o nó de origem ainda necessitar de uma rota até o destino, pode enviar um novo RREQ. Um exemplo de uma busca por rota, pode ser visto na Figura 2.2, onde o nó N6 (origem) deseja iniciar uma comunicação com o nó N1, então é envido um RREQ (Figura 2.2a) para todos os nós da MANET, assim, quando o nó N1 é localizado, este envia um RREP (Figura 2.2b) atualizando as tabelas de roteamento do N2, N4 e N6. Após um determinado tempo, o N1 se move na rede, e passa a se conectar com o nó N7, portanto, quando o nó N2 verificar a quebra de comunicação, este enviará um RERR (Figura 2.2c)

32 2 Roteamento em Rede Ad Hoc 17 Figura 2.2: Descoberta de rota do AODV na MANET, onde o nó N6 deseja iniciar uma comunicação com o nó N1 informando a quebra na rota, ocasionando numa nova busca por rota do nó N6 (Figura 2.2d). Pode-se observar que além do nó N1, os nós N3, N5 e N8 também se movimentaram. Tabela 2.2: Tabela de roteamento do nó N6, antes do deslocamento do nó N1. Destino Gateway Saltos Número de Nós Vizinhos Tempo (Métrica) sequência Ativos de Duração N1 N4 3 S406_N1 N Estas mudanças podem ser verificadas quando o nó N6 recebe a RREP e atualiza a sua tabela de roteamento (Tabela 2.2). Desta forma, o nó N6 incia a comunicação com o nó N1. Tabela 2.3: Tabela de roteamento do nó N6, após o recebimento da RERR. Destino Gateway Saltos Número de Nós Vizinhos Tempo (Métrica) sequência Ativos de Duração N1 N4 S406_N1 N Supondo que, após um tempo de transmissão, o nó N1 se movimente em direção ao nó N7, isto gera uma quebra de comunicação, detectada pelo nó N2, que envia um RERR alertando o nó N6. Este por sua vez, atualiza a tabela de roteamento, mudando o valor dos

33 2 Roteamento em Rede Ad Hoc 18 saltos, para o nó N1, para (Tabela 2.3), necessitando do envio de um novo RREQ caso a comunicação com N1 não tenha sido finalizada. Assim, pode-se notar que na Tabela 2.4, o novo gateway para o nó N1, passa a ser o nó N7, associado ao novo número de sequência S512_N1. Tabela 2.4: Nova tabela de roteamento do nó N6, após o deslocamento do nó N1. Destino Gateway Saltos Número de Nós Vizinhos Tempo (Métrica) sequência Ativos de Duração N1 N7 2 S512_N1 N Na Tabela 2.5, observa-se que o nó N7 mantém os nós N1 e N6 na parte de vizinhos ativos, pois está servindo como nó intermediário na comunicação entre estes dois nós. N7 passa então a enviar periodicamente, mensagens hello para estes nós vizinhos, assim, é possível saber se ocorreu uma nova quebra na comunicação. Tabela 2.5: Nova tabela de roteamento do nó N7. Destino Gateway Saltos Número de Nós Vizinhos Tempo (Métrica) sequência Ativos de Duração N1 N1 1 S512_N1 N1, N N6 N6 1 S204_N1 N1, N Basicamente o AODV cria uma única rota até um determinado destino. Isso possibilita vantagens quanto ao consumo de memórias, mas em contra partida pode causar problemas ao se detectar uma quebra de comunicação envolvendo um ou mais nós da rede e assim pode-se ocasionar perdas de pacote, como também pode acabar fazendo com que um nó da rede fique responsável pelo encaminhamento de vários pacotes o tornando um possível ponto critico na rede. 2.2 Considerações do Capítulo Os protocolos de roteamento fornecem um caminho apropriado entre o nó origem e o nó destino, usufruindo da cooperação de possíveis nós intermediários, para realizar o envio de dados pela rede. Ocasionalmente, ocorre de um destes nós intermediários ou mesmo os nós de origem e destino, se moverem para regiões fora do alcance de transmissão dos demais nós envolvidos na comunicação. A mobilidade que os nós da MANET possuem, proporciona quebras de comunicações e

34 2 Roteamento em Rede Ad Hoc 19 necessita que o protocolo utilizado no roteamento seja flexível o suficiente para se adaptar a possível mudança de rota. O problema em se buscar uma nova rota poderia ser resolvido se o protocolo possibilitasse múltiplas rotas até o destino, isto será visto no Capitulo 3 onde será estudado um protocolo que se baseiam na melhoria continua de suas rotas e assim o torna menos suscetível a perdas de pacotes e atrasos na obtenção de rotas.

35 20 3 Inteligência de Enxames Inteligência de Enxames (SI - Swarm Intelligence), segundo Dorigo (Dorigo 2007), estuda o comportamento coletivo de sistemas compostos por um grande número de indivíduos que interagem entre si, usando estruturas descentralizadas e auto-organizadas para alcançar os objetivos de todo o conjunto. Os sistemas baseados em SI, de acordo com White (White, Pagurek e Oppache 1998), são compostos por uma população de agentes capazes de interagir com seu ambiente, usando simples capacidades de atuação afim de efetuar escolhas baseadas em características locais, conduzindo a um comportamento global e complexo (Beni e Wang 1989). Essas escolhas incluem a modificação do ambiente no qual o agente atua. Neste comportamento inteligente frequentemente, surge de uma comunicação indireta entre os agentes, sendo este o princípio da estigmergia Grassé (1984) apud (Dorigo 2007). Contudo, individualmente os agentes não possuem um conhecimento global do problema apresentado, isto é, eles não sabem se a escolha adotada resultará em uma solução válida, desta forma que segundo Dorigo, os resultados são proporcionados pela sociedade de agentes através do coletivismo apresentado pelo enxame. SI pode ser divida, em duas ramificações: Otimização por Enxames de Partículas (PSO - Particle Swarm Optimization) (Kennedy e Eberhart 2001) e Otimização por Colônias de Formigas (ACO - Ant Colony Optimization) (Dorigo e Stützle 2006). A heurística de enxames de partículas (PSO) foi desenvolvida por Russ Eberhart e James Kennedy em Esta heurística é inspirada na observação da coreografia de animais, como a de pássaros voando em bando e de peixes nadando em cardumes (Kennedy e Eberhart 2001). Dentre outras, o PSO é aplicado para otimizações de funções, treinamento de redes neurais, cálculo de carga em sistemas elétricos, segmentação de imagens e verificação de voz. Diferente do PSO, a heurística das colônias de formigas (ACO), desenvolvida por Marco Dorigo em 1996, é inspirada no comportamento da colônia de formigas em sua busca por alimento. O ACO foi inicialmente utilizada para resolver problemas como do caixeiro viajante, mas hoje é possível encontrar várias aplicações para seu uso, como: escalonamento de tarefas, coloração de mapas, bioinformática, mineração

36 3 Inteligência de Enxames 21 de dados e roteamento (Dorigo e Stützle 2006). A SI tem se tornado uma fonte de inspiração para o desenvolvimento de algoritmos distribuídos e adaptáveis, como por exemplo, protocolos de roteamento. Segundo Di Caro (Di Caro, Ducatelle e Gamberdella 2005), os protocolos de roteamento baseados em SI foram inspirados no comportamento coletivo apresentado por Dorigo (Dorigo e Stützle 2006) ao descrever a heurística de colônias de formigas. A seguir, serão abordados os princípios observados nos insetos sociais ao se autoorganizarem em favorecimento de sua colônia (Seção 3.1), e como foram usados por Dorigo ao criar a heurística das colônias de formigas (Seção 3.2). De maneira a apresentar como o ACO inspirou o desenvolvimento de protocolos de roteamento (Seção 3.3). 3.1 Princípio Biológico Na natureza, observar-se a interação entre agentes e o ambiente, representados por sociedades de insetos sociais, sejam elas formigas, abelhas ou cupins. O comportamento apresentado por estes insetos sociais, é observado na forma como eles reagem ao encontrarem obstáculos nas suas trilhas até o alimento, ou na construção e defesa da sua colônia. As formigas são, provavelmente, os insetos sociais mais estudados, pois podem adaptarse coletivamente às mudanças do ambiente e encontrar o caminho mais curto para fonte de alimento Hölldobler e Wilson (1990) apud (Labella, Dorigo e Deneubourg 2006). Outros insetos que apresentam características coletivas são os cupins, que são capazes de construir ninhos grandes e complexos e as abelhas, que coletivamente escolhem um novo local para o seu ninho. A comunicação direta raramente é observada: estes insetos usam apenas as informações locais disponíveis ao explorar as características presentes no ambiente, comunicando-se indiretamente através da estigmergia Grassé (1959) apud (Labella, Dorigo e Deneubourg 2006). Os resultados do comportamento coletivo destes insetos, geralmente ultrapassam as capacidades de um único inseto, sugerindo que o trabalho de todo o conjunto tende a ser auto-organizável Camazine (2001) apud (Izquierdo-Torres 2004). O conceito de estigmergia foi introduzido pelo biólogo francês Pierre-Paul Grassé ao estudar a forma como os cupins construíam suas colônias. Ele verificou que o processo de construção não dependia apenas das decisões dos cupins, mas da forma como a colônia estava sendo feita. Estas escolhas de onde deveriam ser construídas as próximas partes da

37 3 Inteligência de Enxames 22 colônia são processos que envolvem decisões locais, isto é, cada vez que um cupim realiza uma ação de construir, modifica a configuração local. Esta nova configuração irá então, influenciar outras ações específicas dos demais cupins envolvidos no processo. Isto conduz a uma quase perfeita coordenação no trabalho coletivo, que segundo Dorigo (Dorigo 2007), pode dar a impressão de que a colônia está seguindo um projeto de construção. Outro uso de estigmergia é apresentado pelas formigas, onde esta comunicação indireta é realizada usando produtos químicos voláteis chamados de feromônios. De acordo com Dorigo (Dorigo e Stützle 2006), as formigas depositam o feromônio à medida que percorrem o caminho até o alimento, esta modificação causada no ambiente, proporciona que as próximas formigas que forem passar pelo caminho, sejam influenciadas a escolher trilhas que contenham a maior quantidade da substância. Assim, quanto mais feromônio é depositado numa trilha, mais formigas são influenciadas a seguirem por aquela trilha, e consequentemente mais feromônio é depositado, este processo é chamando de retroalimentação positiva. Figura 3.1: Trilha de Feromônio entre a Colônia e a Fonte de Alimento As formigas ao percorrerem um determinado caminho (Figura 3.1a), tendem a encontrar e utilizar a menor rota entre a colônia e a fonte de alimento. Quando se introduz um obstáculo, as formigas são obrigadas a aprenderem um novo caminho, onde num primeiro momento é visto que aproximadamente 50% das formigas escolhem o caminho mais longo e outros 50% escolhem o mais curto (Figura 3.1b). Esta escolha tende a ser randômica, pois não existe feromônio depositado em nenhuma das duas trilhas após o obstáculo ser inserido. Mas à medida que o tempo passa e as formigas do caminho mais curto começam a ir e voltar da fonte de alimento com maior intensidade (Figura 3.1c), a trilha mais curta

38 3 Inteligência de Enxames 23 tende a ficar com uma maior concentração de feromônio em relação ao caminho mais longo. Este aumento na quantidade de feromônio depositado torna-se evidente quando a trilha de menor caminho passa a ser a opção de rota para a grande maioria das formigas da colônia (Figura 3.1d), isto de acordo com Dorigo (Dorigo e Stützle 2006) é considerado um processo autocatalítico, ao melhorar as menores rotas, descartando as demais. Outro processo que contribui para o melhoramento das trilhas é o processo de evaporação, que tende a diminuir a concentração de feromônio numa trilha. Assim, uma trilha com pouca concentração de feromônio será mais afetada pela evaporação do que uma trilha com muito feromônio depositado, pois com o passar do tempo rotas pouco utilizadas pelas formigas serão extintas. Este efeito é chamando de retroalimentação negativa, pois deteriora o feromônio existente, contribuindo para que os melhores caminhos se fortaleçam em detrimento dos piores. Geralmente, a trilha que contém a maior quantidade de feromônio, segundo White (White 1997), é a que possui o melhor caminho até o alimento, fornecendo um sofisticado sistema de sinalização. 3.2 Heurística de Colônia de Formigas O processo de localizar caminhos entre a colônia e a fonte de alimento utilizado pelas formigas foi uma fonte importante de inspiração para o desenvolvimento das bases da heurística de colônia de formigas (Dorigo e Stützle 2006) (ACO - Ant Colony Optimization). Esta estrutura possibilitou o desenvolvimento de algoritmos para resolver problemas do optimização. A idéia principal do ACO se baseia na utilização de formigas artificiais para construção de soluções. Assim, quando uma formiga localiza uma possível solução, monta uma trilha de feromônio artificial, o qual é armazenado e atualizado numa matriz de feromônio artificial. Os algoritmos de ACO tendem a trabalhar de forma que todas as formigas artificiais possam construir soluções paralelamente, usando a matriz de feromônio artificial (Ducatelle 2007). Desta maneira, a matriz de feromônio guarda as informações sobre as melhores soluções que foram encontradas, e permite que as futuras formigas consigam decidir suas escolhas usando esta informação ao construir soluções novas. O primeiro algoritmo de ACO que foi desenvolvido para problemas de caixeiro viajante (TSP - Traveling Salesman Problem), foi proposto originalmente por Dorigo em No

39 3 Inteligência de Enxames 24 algoritmo, o valor do feromônio F(i, j) é associado a um custo de G(i, j), onde i e j representam duas cidades interligadas. Assim, o algoritmo utiliza as formigas artificiais para construir as soluções usando este feromônio artificial F, que será atualizado baseado na qualidade da solução obtida. O algoritmo funciona em iterações, sendo que a cada iteração é escolhida uma cidade aleatória para cada formiga, de maneira que elas se movimentem de uma cidade para outra, construindo uma solução para o TSP. Desta forma, a formiga se move de uma determinada cidade para outra, sendo que não pode visitar a uma mesma cidade mais de uma vez. Esta escolha de qual será a próxima cidade a ser visitada é probabilística, onde para cada possível cidade existe uma probabilidade p k (i, j), sendo k representa a formiga, i é a cidade atual e j a próxima cidade, a equação é dada por: [F(i, j)] α [G(i, j)] β se j N p k (i, j) = l N [F(i, l)] α [G(i, l)] β k i k i 0 senão (3.1) Na equação, Nk i representa o conjunto de cidades que são vizinhas de i e que não 1 foram visitadas pela formiga k. G(i, j) é igual, isto é, o inverso da distância entre i d(i, j) e j, que serve como um valor heurístico que irá ajudar na construção das soluções. Assim, quando a formiga tiver chegado na cidade j, é gerada uma estimativa que será incorporada ao feromônio relacionado a trajetória por onde ela passou. Esta estimativa terá maior ou menor valor dependendo se a distância total for baixa ou não. Os parâmetros α e β são os pesos relativos dados respectivamente ao feromônio e à distância heurística no processo de decisão: sendo β = 0, as decisões são baseadas puramente no feromônio, significando a experiência adquirida nas iterações anteriores, mas quando o valor de α = 0, as decisões serão baseadas puramente na distância heurística, causando uma busca gulosa. 3.3 ACO Aplicado a Roteamento O roteamento envolve problemas de decisões que somente podem ser feitas com base nas informações locais, devido ao atraso de pacotes e a dificuldade em definir rotas que

40 3 Inteligência de Enxames 25 não estejam congestionadas. Estas características possibilitaram o desenvolvimento de protocolos, como no caso do AntNet (Di Caro e Dorigo 1998) que se baseia no ACO, ao utilizar valores de feromônio como meio de determinar a probabilidade que cada pacote teria para ser encaminhado por uma determinada rota. Sendo que o AntNet também utiliza multiagentes (formigas) para determinar as rotas numa rede guiada, de maneira que um agente é responsável por localizar o destino e outro é responsável por comunicar e atualizar as tabelas de roteamento referentes à rota gerada, estes agentes são chamados respectivamente de Forward Ant e Back Ant. Segundo Dorigo (Dorigo, Di Caro e Gambardella 1999), para se utilizar SI (usando os princípios do ACO) em roteamento de redes, deve-se basear o encaminhamento das informações em amostras do ambiente (feromônio) usado como base de decisão pelos pacotes, que são chamados de formigas. Em Di Caro (Di Caro, Ducatelle e Gamberdella 2004) afirma que as formigas são geradas simultaneamente e de forma independente pelos nós, com a tarefa de testar um caminho para um destino atribuído. O envio das formigas possibilitam recolher informações sobre a qualidade da rota entre origem e destino (por exemplo, o atraso médio, a quantidade de saltos, entre outros), e assim utilizar estas informações para atualizar os valores de feromônio referentes a rota. As tabelas de roteamento associam uma porcentagem de feromônio a cada rota, o que pode gerar, para um mesmo destino, a inclusão de mais de um gateway correspondente, por isso, as tabelas de roteamento passam a ser denominadas de tabelas de feromônio (Di Caro, Ducatelle e Gamberdella 2005). Assim, quando uma formiga for enviada para um nó destino, está poderá ser encaminhada probabilisticamente por um dos gateways, sendo que esta probabilidade será baseada no feromônio. Este processo é semelhante ao feromônio usado pelas formigas reais quando se deslocam da colônia para a fonte de alimento. Tal como as formigas reais, as formigas artificiais são agentes autônomos que através da atualização das tabelas de feromônio participam do processo de comunicação. De acordo com Di Caro (Di Caro, Ducatelle e Gamberdella 2004), isto é o resultado do comportamento de aprendizagem coletiva, na qual cada formiga tem baixa complexidade e pouca importância, enquanto todo o enxame junto pode coletar e manter atualizada as informações de roteamento. Desta forma, o feromônio é utilizado para encaminhar os pacotes pela rede, esco-

41 3 Inteligência de Enxames 26 lhendo geralmente rotas que possuam uma maior probabilidade associado a valores elevados de feromônio. Isto possibilita que os pacotes de dados enviados para um mesmo destino possam ser enviados por múltiplas rotas, resultando num balanceamento de carga (Ducatelle 2007). De acordo com Ren (Ren e Meng 2006), os protocolos de roteamento baseados em SI estão sendo usados em redes de telefonia, redes guiadas e redes Ad Hoc (MANET, Rede Mesh e Rede de Sensor). Embora estes protocolos de roteamento sejam inspirados nos mesmos princípios biológicos, foram desenvolvidos de várias maneiras para cumprir objetivos diversificados. Um destes protocolos de roteamento baseados em ACO é o AntHocNet (Ducatelle 2007) que foi desenvolvido para possibilitar múltiplas rotas para um mesmo destino numa rede Ad Hoc, e assim, proporcionar uma distribuição dos pacotes de dados ao distribuir a carga de roteamento para mais nós da rede. A utilização de escolhas probabilísticas para determinar qual rota será usada para enviar os pacotes de dados são comuns em protocolos de roteamento que se baseiam em ACO, tal como o ARA (Gunes, Sorges e Bouazzi 2002), Termite (Roth e Wicker 2003) e o ANSI (Rajagopalan e Shen 2005). Em simulações realizado com estes protocolos que usam o ACO, todos tiveram resultados satisfatórios ao serem comparados com o protocolo de roteamento AODV, sendo que cada um foi testado num tipo de cenário diferente do outro. Os protocolos ARA, ANSI e Termite, obtiveram melhores resultados em termos de overhead que o apresentado pelo AODV, sendo que o ARA foi testado numa para ser melhor aplicado a uma rede de pequeno porte, sendo que na simulação foram utilizados 50 nós móveis. Já o Termite foi comparado apenas em termos de aumento da velocidade dos nós dentro do cenário, tendo apresentado bons resultados em termos de overhead. Na tese de Ducatelle (Ducatelle 2007), o AntHocNet foi comparado: ao ANSI, por ambos serem baseados em SI e apresentarem características híbridas, e ao AODV, por este estar sendo estudado pela (IETF MANET 2008) para ser tornar o protocolo padrão em MANETs. Nestas simulações, o AntHocNet se mostrou superior ao ANSI e ao AODV quando comparadas suas taxas de entrega de pacotes e a média de delay. Já quando comparado ao overhead causado na rede, o AntHocNet apresentou taxas menores que o ANSI, mas

42 3 Inteligência de Enxames 27 em algumas situações o AODV manteve uma taxa de overhead menor que a apresentada pelo AntHocNet AntHocNet O AntHocNet (Ducatelle 2007) é um protocolo de roteamento híbrido que possibilita múltiplas rotas entre origem e destino. É um protocolo baseado nos princípios da SI para roteamento. Apesar de ser baseado no AntNet (utilizado em redes guiadas), o AntHocNet se diferencia ao não manter rotas para todos os nós da rede, ele apenas cria suas rotas quando são necessárias. Isto é feito ao utilizar características reativas, quando um determinado nó de origem deseja se comunicar com um nó destino, enviando formigas via broadcast para descobrir pelo menos uma rota (Di Caro, Ducatelle e Gamberdella 2004). De acordo com Di Caro (Di Caro, Ducatelle e Gamberdella 2005), as rotas são criadas sob a forma de tabelas, que guardam respectivas quantidades de feromônio depositadas para cada gateway. Assim, após a configuração do percurso, a origem inicia o envio dos dados probabilisticamente pelas rotas, possibilitando escolhas de caminhos diferentes dependendo da tabela de feromônio. Enquanto os dados estão sendo transmitidos, os caminhos são monitorados, mantidos e melhorados utilizando estratégias pró-ativas por onde diferentes agentes, chamados de PRFAs (PRoactive Forward Ants) realizam o processo de exploração e manutenção de rotas. O protocolo reage à quebra de conexões, com reparações de rotas localmente (se for possível) ou notificando os demais nós participantes. Os nós guardam suas informações de rotas nas tabelas de feromônio. No AntHocNet, cada nó i constrói sua tabela de feromônio T i, numa matriz de duas dimensões. Assim, para uma entrada Tnd i nesta matriz representa a quantidade de feromônio depositada sobre uma rota do nó i para o nó d com gateway n. Este valor é atualizado a cada passagem das formigas. Desta forma, quando um nó i deseja enviar uma formiga para um nó d, deve-se decidir probabilisticamente, calculando a probabilidade P nd para cada gateway n, dada pela fórmula:

43 3 Inteligência de Enxames 28 P nd = (T i nd )B 1 j N i d (T i jd )B 1, B 1 1 (3.2) Além da tabela de feromônio T i, cada nó da MANET guarda uma tabela de nós vizinhos N i, onde Nd i é o conjunto de gateways de i para o destino conhecido d. Sendo que um valor baixo para o parâmetro B 1 (valor próximo a 1), os pacotes de dados ou formigas terão a característica de serem enviados por múltiplas rotas, enquanto valores altos em B 1 tendem a concentrar a maioria dos dados na trilha de maior concentração de feromônio. Como o AntHocNet é um protocolo de roteamento híbrido, é constituído por duas componentes: uma reativa, usada para localizar e gerar pelo menos uma rota entre entre uma origem e um destino; e outra pró-ativa que, além de manter a rota criada pela componente reativa, possibilita o surgimento de outras rotas, de maneira a proporcionar múltiplas rotas para o destino. Se ocorrer alguma quebra de conexão, o AntHocNet irá enviar formigas para tentar reparar esta rota Componente Reativa A característica reativa do AntHocNet é responsável pela descoberta de uma rota entre um nó de origem e um nó destino desconhecido. Por isso, quando um nó origem necessita iniciar uma transmissão com um nó destino e não possui nenhuma rota para encaminhar os pacotes de dados, ele então envia uma REFAs (REactive Forward Ant) via broadcast. Assim, se um nó intermediário possuir uma ou mais rotas válidas para o destino, ele encaminha a REFA (probabilisticamente) para o destino baseando-se nos valores de feromônio depositados para cada rota. Com isso Di Caro (Di Caro, Ducatelle e Gamberdella 2004) afirma que, se não existir nenhum de valor de feromônio disponível para o nó destino, a formiga é retransmitida via broadcast. Estas transmissões broadcast possibilitam o aumento do overhead causado a MANET, mas em contrapartida possibilitam que as formigas possam se proliferar rapidamente pela rede, seguindo caminhos diferentes para o destino. Estas REFAs ao serem enviadas para os demais nós da rede, recebem uma identificação gerada pela origem que auxilia os nós intermediários a reconhecerem e descartarem REFAs repetidas, contribuindo para o processo de criação de uma rota válida evitando loops.

44 3 Inteligência de Enxames 29 Dessa forma, segundo Di Caro (Di Caro, Ducatelle e Gamberdella 2005), apenas uma rota será criada inicialmente. Durante o envio de dados entre a origem e destino, mais caminhos são adicionados através do mecanismo de exploração e manutenção de rotas, caracterizando o comportamento pró-ativo do AntHocNet, que fornecerá um conjunto de rotas para um determinado nó da MANET. Desta forma, cada REFA acrescenta o nó que visitou numa lista P. Assim, quando a REFA alcançar o nó destino, é transformada numa REBA (REactive Backward Ant) que retorna para a origem através do caminho guardado em P. Em cada nó i P(i < d), a REBA verifica a estimativa local Hi+1 i do tempo que levou para vir do nó vizinho i + 1, isto é, do nó que transmitiu a REBA. Assim, o tempo total que a REBA levou para vir do nó destino d até o nó i será dado por: Hd i, representado na fórmula: H i d = d H j j+1 (3.3) j=i Esta estimativa Hd i é então combinada com o número de saltos h entre o nó i até o destino d, a fim de se calcular a estimativa de feromônio t i d que será usada para atualização, expressa na seguinte fórmula: ( ) H t i i 1 d = d + hs χ (3.4) 2 Onde o S χ é um valor fixo pré-determinado que representa o tempo que cada salto h supostamente levaria. A partir deste resultado é calculado o inverso, pois quanto maior o custo (neste caso o tempo) menor será quantidade de feromônio depositada na trilha. Com isso, o valor do feromônio Tnd i é atualizado do seguinte modo: Tnd i = γtnd i + (1 γ)t i d, γ [0, 1] (3.5) Assim o valor da estimativa t i d é somado ao valor de feromônio T nd i já existente. Sendo que γ é um parâmetro, que por exemplo: se possuir um valor próximo 1 aumentará significantemente a importância do valor do feromônio Tnd i depositado anteriormente, mas se possuir um valor próximo de 0, sugere que a estimativa t i d é mais significante.

45 3 Inteligência de Enxames Componente Pró-ativo O componente pró-ativo do AntHocNet é responsável pela manutenção e pela exploração de rotas, que possibilitam opções alternativas para um determinado nó destino. Durante o processo de transmissão de dados, o nó origem envia as PRFAs para atualizar as informações sobre as rotas que estão sendo usadas, bem como possui a probabilidade de encontrar novos e melhores caminhos para o destino. As PRFAs são enviadas para o destino utilizando as trilhas de feromônio depositadas nas tabelas de roteamento. Entretanto, a MANET caracteriza-se por possuir mudanças constantes na sua topologia, necessitando que as formigas sejam emitidas numa frequência elevada, podendo contribuir para o congestionamento da rede. Além disso, para se encontrar novas rotas, as formigas deveriam ser enviadas por caminhos aleatórios ou via transmissões broadcast, aumentando o overhead causado a rede. Desta forma, Ducatelle (Ducatelle 2007) descreve a necessidade de se distribuir o feromônio a fim de espalhar as informações disponíveis sobre a rede, com o uso de periódicas mensagens de atualização e reparos de rotas. Este processo fornece uma forma de atualizar as tabelas de feromônio sobre rotas existentes, e criam bases de escolhas utilizadas pelas formigas ao explorarem a MANET em busca do melhor caminho para o nó destino. Esta distribuição de feromônio utiliza mensagens curtas de hello que são transmitidas pelos nós, periodicamente de modo assíncrono, via broadcast para todos seus vizinhos. Nestas mensagens de hello, o nó i envia uma lista contendo no máximo k nós destinos. De acordo com Ducatelle (Ducatelle 2007), o k geralmente possui valor igual 10, mas ele sugere um valor aleatório para o k, caso o número de destinos contidos na tabela de feromônio for maior que 10. Assim, para cada destino d associado ao maior valor de feromônio de i para d, Tmd i onde m representa o gateway para d (m N d i). Quando o nó vizinho n recebe a mensagem de hello vinda de i, extrai da lista os valores de feromônio e verifica se algum dos destinos contidos na mensagem é de seu interesse. Caso localize uma informação que contenha um destino d que pode ser usado em uma de suas comunicações, o nó utiliza o custo de feromônio que levaria para enviar um pacote de n para d com gateway em i usando o valor de Tmd i, representado por vi d. Assim, n inicia o reparo de rota, de forma a calcular uma nova estimativa de feromônio correspondente ao gateway i com destino d, dado pela equação:

46 3 Inteligência de Enxames 31 w n id = ((v i d) 1 + t n i ) 1 (3.6) Desta forma, a tabela de feromônio passa a guardar dois tipos de feromônios: um regular T e outro virtual W. De modo que se uma rota estiver sendo utilizada para o envio de dados o valor do feromônio T n id usa a estimativa do feromônio virtual wn id como estimativa de feromônio t n d para se atualizar. Caso o nó n não esteja enviando pacotes de dados para o nó d sendo i o gateway utilizado, o feromônio virtual W n id é então atualizado da mesma forma que o feromônio regular Tid n, com a simples diferença de utilizar wn id como estimativa, visto na fórmula: W n id = γw n id + (1 γ)w n id, γ [0, 1] (3.7) Com esta distribuição de feromônio, as PRFAs conseguem usar tanto o feromônio regular quanto o virtual no processo de exploração de rotas, assim, se um determinado nó i não possuir um valor regular de feromônio Tnd i na tabela, W nd i é utilizado para indicar uma possível rota nova para d tendo como gateway n. Entretanto, este trajeto nunca foi utilizado por uma formiga devido o processo que distribuição de feromônio utilizar as mensagens de hello. Sendo que estas rotas proporcionadas pelo feromônio virtual podem levar a loops não detectados e conexões instáveis, de modo que não são usadas para enviar de dados. A fórmula usada pela PRFA para verificar as probabilidades de cada gateway é dada por: P i nd = [max(tnd i, W nd i )]B 2 j Nd i[max(t jd i, W, B jd i )]B 2 1 (3.8) 2 Isto possibilita que o feromônio virtual possa ser testado pelas PRFA. Desta maneira, o feromônio virtual é verificado e tem a probabilidade de ser usado para gerar uma nova rota regular, como no caso de uma PRFA alcançar o destino e ser transformada numa PRBA (PRoactive Backward Ant), atualizando as trilhas de feromônio (da mesma forma que uma REBA), proporcionando que esta nova rota possa ser utilizada para enviar os dados pela rede, aumentando o número dos rotas disponíveis para o roteamento dos dados e permitindo que o protocolo explore novas oportunidades na topologia dinâmica da MANET.

47 3 Inteligência de Enxames 32 Na Figura 3.2 é observado um exemplo de como o feromônio regular (retas continuas) e o feromônio virtual (retas pontilhadas) se comportam numa MANET. O nó de origem N1 se comunica com o nó de destino N8, de forma que a rota representada pelos nós N6, N4 e N5 é o resultado obtido pela componente reativa. Note que a rota do nó N7 ao nó N8 é independente da comunicação ente N1 e N8, isto porque o nó N7 sabe que N8 é seu vizinho e consequentemente possui uma rota com feromônio regular para ele. Figura 3.2: Trilhas de feromônio entre o nó origem N1 e o nó destino N8. Assim, as demais rotas representadas pelas retas pontilhadas correspondem ao feromônio virtual, obtido pela difusão de feromônio. No exemplo da Figura 3.2 o nó N6 poderia usar o valor de feromônio sobre o destino N8, enviado pelo nó N7 para fazer a sua estimativa e assim, atualizar seu valor de feromônio virtual. A idéia de manter o feromônio virtual separado do feromônio regular é justamente para separar o envio de pacotes de controle das transmissões de dados, visto que o feromônio virtual é usado apenas pelas formigas (pacotes de controle), de maneira que o feromônio regular seja o único a influenciar a emissão de dados Quebras de Conexão Os nós podem detectar quebras de conexão quando as transmissões de formigas ou de dados falham, ou quando as periódicas mensagens de hello, usadas pela difusão de feromônio, não estiverem sendo recebidas. Quando um nó i descobre que um vizinho n desapareceu, realiza os seguintes passos: Primeiramente, todas as informações de i com gateway em n recebem valor 0. Em seguida, i transmite via broadcast uma mensagem de notificação sobre a quebra de conexão.

48 3 Inteligência de Enxames 33 Esta mensagem contém uma lista dos destinos que i perdeu sua melhor rota, isto é, a rota que continha a maior quantidade de feromônio. Mas caso i possua uma ou mais rotas para o destino, acrescenta na lista a nova melhor rota. Assim, todos os nós contidos em N i recebem a mensagem e atualizam suas tabelas de feromônio usando as novas estimativas. Se um nó n (n N i ) verificar que também perdeu a sua melhor rota para o destino ou esta era a única rota que possuía, a mensagem de notificação é então atualizada e encaminhada para todos os nós contidos em N n, até que todos os nós interessados sejam notificados. Outro modo de verificar uma quebra na conexão se dá quando o nó i detecta uma falha na transmissão de pacotes dos dados, sendo que não possui nenhuma rota adicional para o destino. Assim, inicia-se o reparo local da rota através do envio de RRFA (Route Repair Forward Ant) via broadcast tendo comportamento idêntico a uma REFA, com a diferença que este pacote tem um tempo de vida calculado pela seguinte formula: tempo = 2 S χ h i jd (3.9) O nó i usa este tempo para delimitar quanto irá esperar por uma RRBA (Route Repair Backward Ant), semelhante a REBA. Assim, o nó estima este valor de tempo usando S χ multiplicado pelo valor total de saltos (h i jd ) que a antiga rota com gateway j possuía. Sendo que também se multiplica este valor por 2, pois é o tempo estimado para que a RRFA encontre o destino d e retorne na forma de RRBA. Se o reparo local falhar, i transmite uma nova mensagem de notificação para comunicar os demais vizinhos sobre a quebra na conexão Comparativo entre AntHocNet e AODV No trabalho de Di Caro (Di Caro, Ducatelle e Gamberdella 2005), foi estudado o comportamento dos protocolos de roteamento AODV e AntHocNet em diferentes cenários, usando o simulador comercial QualNet (QualNet 2011). De maneira a facilitar o entendimento de como os cenários foram estipulados, foi sugerido por Di Caro (Di Caro, Ducatelle e Gamberdella 2005) um ambiente base onde seria possível realizar algumas modificações para se obter os cenários de teste.

49 3 Inteligência de Enxames 34 Este ambiente base se caracterizou por possuir 100 nós que se movem em uma área plana retangular de m 2. Os testes padrões do movimento foram gerados de acordo com o modelo aleatório de mobilidade RWP, sendo que a velocidade adotada pelo autor varia entre 0 e 20m/s, de maneira que o tempo que o nó irá permaneceria parado foi fixado em 30 segundos, assim, cada simulação foi executada durante um tempo de 900 segundos. O tráfego de dados é gerado pelo CBR onde 20 diferentes comunicações são formadas por origens e destinos escolhidos randomicamente, durante um tempo aleatório que varia de 0 e 180 segundos, que é iniciado novamente após o término. Cada comunicação envia 4 pacotes de dados por segundo que representam 64 bytes. O padrão adotado para transmissão de dados é o IEEE b. De acordo com Ducatelle (Ducatelle 2007), a proporção de pacotes entregues (packets delivered ratio) e média de delay (average end-to-end packet delay), são métricas padrões para se testar o protocolo numa MANET segundo as recomendações da (IETF MANET 2008). Além disso, o autor também verificou a taxa de overhead (routing overhead) causado na rede, possibilitando que fossem realizadas simulações em três diferentes cenários, gerados a partir de pequenas modificações no ambiente base. Assim, para verificar como os protocolos se comportam com o aumento da mobilidade dos nós, no Cenário 1 é realizada a alteração no ambiente base para representar um aumento gradativo no tempo (pause time) que cada nó permanece parado em uma posição fixa. Desta forma, com o passar do tempo da simulação os nós da rede tendem a se movimentar com menor frequência dentro do cenário. Na Figura 3.3 é verificado que o AntHocNet apresentou um melhor desempenho ao se comparar a média de delay (Figura 3.3a) e proporção de pacotes entregues (Figura 3.3b), mas em relação ao overhead causado à rede, o AODV apresentou uma taxa menor e melhor que a do AntHocNet. O aumento das taxas de overhead (Figura 3.3c) apresentado pelo AntHocNet, cresce a medida que os nós da MANET se movem com menor frequência. De acordo com Ducatelle, este mau desempenho ocorre devido a redução da conectividade conforme a mobilidade dos nós se torna menos dinâmica (isto é uma das propriedades específicas do RWP (Christian Bettstetter and Giovanni Resta, and Paolo Santi 2003)), gerando maiores quantidades de emissões de pacotes de controle, o que pode contribuir para um con-

50 3 Inteligência de Enxames 35 Figura 3.3: Gráfico comparativo entre AntHocNet e o AODV, no Cenário 1, verificando a média de delay, proporção de pacotes entregues e a taxa de overhead causado a rede (Di Caro, Ducatelle e Gamberdella 2005). gestionamento da rede, pois o AntHocNet tenta reparar as rotas perdidas enviando RRFA via broadcast. No Cenário 2, o autor verifica como os protocolos se comportam com o aumento da densidade de nós no ambiente, isto é, a área do ambiente não se altera, mas em contra partida a quantidade de nós aumenta de 50 a 150 nós. Como no Cenário 1, o AntHocNet no Cenário 2 obtém melhor performance que a apresentada pelo AODV em termos de média de delay (Figura 3.4a) e da proporção de pacotes entregues com sucesso (Figura 3.4b), conforme a densidade de nós da rede aumentava. Mas nesta simulação o AntHocNet se portou de forma diferente em termos de overhead, pois apesar do AODV ter aumentado significantemente a sua emissão de pacotes, o AntHocNet permaneceu de certa forma estável (Figura 3.4c), isto é observado à medida que mais nós são incorporados a rede e a quantidade de overhead gerado pelo protocolo AODV cresce, isto segundo Di Caro é devido ao aumento dos pacotes de controle enviados por cada nó ao detectar, por exemplo, uma quebra de conexão, acarretando em novas

51 3 Inteligência de Enxames 36 Figura 3.4: Gráfico comparativo entre AntHocNet e o AODV, no Cenário 2, verificando a média de delay, proporção de pacotes entregues e a taxa de overhead causado a rede(di Caro, Ducatelle e Gamberdella 2005). emissões de pacotes ao procurar a rota para o destino perdido. Apesar disso, no início da simulação o AntHocNet possui uma taxa de overhead maior que a verificada no AODV, segundo o Di Caro isto acontece pois o AntHocNet além de enviar REFA por broadcast e usa mensagens de hello com maior frequência e em maior quantidade que o AODV. No Cenário 2 se verifica que o broadcast, desta vez proporcionado pelas REFAs, contribui para um rápido crescimento na taxa de overhead apresentada no início da simulação. Apesar do acréscimo de nós a rede, o AntHocNet não aumenta a emissão de pacotes da mesma forma que o AODV, isto é devido a característica do AntHocNet de buscar por rotas extras, pois diferente do Cenário 1 onde as quebras de conexão eram mais frequentes, no Cenário 2 o AntHocNet evita que pacotes sejam transmitidos por broadcast (o que ocorre com o AODV), sendo que na maioria das vezes possuirá uma rota auxiliar caso for detectada a quebra numa outra rota para o destino. Para testar o aumentar do número de nós (100 a 800 nós), juntamente com o aumento da área do cenário, de forma que a densidade dos nós não varie, o autor propõe o Cenário 3, para verificar se o AntHocNet possui melhor desempenho que o AODV.

52 3 Inteligência de Enxames 37 Figura 3.5: Gráfico comparativo entre AntHocNet e o AODV, no Cenário 3, verificando a média de delay, proporção de pacotes entregues e a taxa de overhead causado a rede (Di Caro, Ducatelle e Gamberdella 2005). Neste cenário (Figura 3.5) o AntHocNet se mostrou superior ao AODV para todas as métricas aplicadas. Devido ao mau desempenho do AODV, o autor conclui que por causa do aumento do tamanho da rede o AntHocNet consegue ser mais escalável que o AODV e por isso é apto para ser utilizado em redes de grande porte. Com estas simulações foi verificado que em todos os cenários estudados, o AntHocNet apresentou melhor performance que o AODV em termos de média de delay e proporção de pacotes entregues com sucesso. Mas em contrapartida, apresentou piores taxas de overhead nos Cenários 1 e no início das simulações do Cenário 2, de forma que o AODV causa menos overhead em redes pequenas. Como visto no Cenário 3 o AODV apresentou uma taxa superior de overhead do que o verificado com o AntHocNet, apesar disso, os dois mostraram um significativo aumento no overhead conforme o crescimento da rede, isso se deve a grande emissão de pacotes via broadcast, de maneira que quanto mais nós são acrescentados a MANET, mais estes pacotes se propagam, podendo dificultar o envio de dados e consequentemente causando

53 3 Inteligência de Enxames 38 um congestionamento na rede. 3.4 Considerações do Capítulo Neste capítulo foi apresentado o protocolo de roteamento híbrido AntHocNet, que combina o processo reativo para descobrimento de rota, sendo que após sua determinação o componente pró-ativo é usado para mantê-lo atualizado. Quando comparado o AntHocNet com o AODV, o AntHocNet demonstrou melhor performance numa MANET, mas em algumas situações apresentou taxas de overhead superiores às emitidas pelo AODV. Este aumento foi consequência de constantes quebras de conexão em virtude do diminuição da conectividade dos nós da rede na qual, sucessivos envios de RRFAs foram transmitidos por broadcast afim de reparar as rotas perdidas. Além do fato que, no início de outra simulação, as REFAs contribuíram para o rápido aumento no overhead num cenário onde a quantidade de nós aumentava em função do tempo, sendo estes pacotes também são enviados via broadcast. Num terceiro cenário, o AODV apresentou uma taxa superior de overhead do que o verificado com o AntHocNet, mas apesar disso, os dois demonstraram um aumento proporcional no overhead conforme o crescimento da rede (de 100 nós a 800 nós). Isso devido ao aumento das transmissões broadcast resultante do aumento de retransmissões devido a entrada dinâmica de novos nós na MANET. Todos esses testes foram feitos no simulador de rede QualNet e com base neles será verificado seguindo os mesmos padrões de cenários no NS-2. Possibilitando assim, validar a implementação do protocolo. No capitulo 4 serão vistos os modelos de linguagem e critérios específicos usados para o desenvolvimento da proposta de implementação do AntHocnNet no NS-2.

54 39 4 Implementação da Proposta O objetivo do trabalho é criar uma implementação para o protocolo de rede AntHocNet no simulador de rede NS-2. Sendo feita a sua validação ao ser executada a comparação entre o AntHocNet e AODV nos mesmos cenários vistos na Seção A escolha do NS-2, como alvo da implementação do AntHocNet baseou-se nas características do simulador ser de código fonte aberto e possuir distribuição gratuita, além de ser muito usado nos meios acadêmicos (NS ). A seguir, na Seção 4.1 serão abordadas as configurações do ambiente de desenvolvimento utilizadas na implementação e na Seção 4.2 é descrito a visão geral da estrutura do NS-2 utilizada neste trabalho. Por fim, na Seção 4.3 é apresentada a padronização das classes, bem como o modelo da arquitetura do protocolo. Ressaltando que todas as classes foram desenvolvidas neste trabalho. 4.1 Ambiente de Desenvolvimento Os requisitos de instalação do NS-2 definiram as bases para montar o ambiente de desenvolvimento do trabalho. Estes definiam que o sistema operacional deveria sem uma distribuição Linux, de forma que a escolha do sistema operacional se baseou numa distribuição de Linux que estivesse estável, nesse caso foi definido o Debian Squeeze. Outros sistemas foram usados, como no caso do Ubuntu 8.10 e 10.10, mas estes se tornaram incompatíveis quando uma nova versão da gcc (compilador de C/C++) era atualizada e causava erros na compilação. Por causa disso, muitos problemas foram causados, o que ocasionou atrasos na execução do trabalho. Com o intuito de simplificar a criação do ambiente, diminuído possíveis incompatibilidades entre sistema operacional e a arquitetura do computador, foi criada uma Máquina Virtual (VM - Virtual Machine). Onde são apresentadas, na Figura 4.1, as configurações utilizadas para simular uma arquitetura de computador com 2 Gigas de memória RAM e quatro processadores, sendo o sistema operacional Debian Squeeze.

55 4 Implementação da Proposta 40 Figura 4.1: Configuração da Máquina Virtual. Além disso, visando facilitar a distribuição da implementação do AntHocNet no NS-2, foi criado um projeto para este trabalho no Source Forge, onde este disponibiliza acesso ao sistema versionador de arquivos do SVN. Isso possibilitou que todo o conteúdo dos códigos fontes e seus compilados ficassem num lugar centralizado e de certa forma seguro. Levando em consideração que durante o desenvolvimento do projeto houveram situações complicadas em que a máquina precisou ser refeita. O projeto no Source Forge, contém todos os códigos fontes da implementação do AntHocNet, e podem ser acessado pelo endereço: Outro aplicativo que é importante mencionar é o Eclipse, que foi usado como ferramenta para a programação da parte C/C++ do projeto, e também na parte de geração dos arquivos em TCL. Isso se deve à quantidade de plugins que a ferramenta proporciona a seus usuários, facilitando a implementação nestas linguagens. 4.2 Network Simulator 2 Responsável por toda parte de simulação do protocolo de rede, o Network Simulator é um simulador de redes de código aberto, difundido nos meios acadêmicos para realiza-

56 4 Implementação da Proposta 41 ção de pesquisas nas MANETs. Nele, é possível criar uma topologia especifica de rede, especificando quantos nós irão participar e ainda, qual a interação entre eles ao longo do tempo da simulação. Isto é, onde eles se posicionam inicialmente e por quais pontos se deslocam no decorrer do tempo. Neste trabalho, é utilizada a versão 2 release 34 do simulador (lê-se NS 2.34) e por este motivo, a sua estrutura se baseia-se na utilização nas duas linguagens: C/C++: utilizada como a principal linguagem para implementação de protocolos. TCL: script usado para modelar a topologia da rede. A parte que gerencia a memória e controla todo o tempo de simulação, é feita em C/C++, isso possibilita a reutilização das implementações básicas de um protocolo no NS-2. Sendo necessário que o desenvolvedor estenda uma determinada classe em C++, sobrescrevendo os método que achar necessário. Basicamente, assim se deu o passo principal para a implementação do AntHocNet. A modelagem de classe no paradigma da orientação a objetos, facilita o desenvolvimento do protocolo, mas não significa que seja simples. Para implementar um protocolo no NS-2 é necessário utilizar várias de suas classes. Uma delas é a classe Agent da qual variam todas as implementações de protocolos. Basicamente, ela é uma classe abstrata que serve de base para qualquer protocolo, sendo assim o AntHocNet acaba se tornando uma subclasse de Agent (ver Subseção 4.3.6) e com isso deve respeitar alguns padrões, isto é, deve obrigatoriamente implementar os métodos recv e command (ver Figura 4.2). Esses métodos são as únicas interfaces que o NS-2 usa para interagir com o protocolo de rede. Para melhorar o desempenho do controle da alocação de memória, o NS-2 faz uso de estruturas de dados que não seguem o padrão da orientação a objeto, isto é, utiliza recursos da linguagem C. Este detalhe que gerou uma significativa demanda, pois era necessário a alocação de memória para os tipos de pacotes do AntHocNet. Ao utilizar classes de controle de lista (usando a biblioteca std::vector), no cabeçalho do protocolo, ocasionava erros na alocação de memória do pacote, principalmente se o pacote era enviado via broadcast. O simulador ao copiar os dados de um pacote recebido, criando um novo pacote com

57 4 Implementação da Proposta 42 Figura 4.2: Interfaces implementadas pelo AntHocNet para interagir com o NS-2. uma sequencia de bytes semelhante ao pacote recebido, isto comprometia as referencias de ponteiro do novo pacote. Estas acabavam referenciando posições inválidas na memória, interrompendo a execução do programa. O único meio de solução deste problema foi utilizar alocação de memória do C através do malloc. Outro detalhe importante sobre o controle de pacotes no NS-2, ou seja, quando um pacote é recebido pelo método recv. O protocolo de roteamento deve ler o seu cabeçalho e com isso, tomar a ação de encaminhar ou requisitar uma nova rota. Esta leitura se faz, usando os métodos access e offset, que por detalhe devem ser estáticos e estar incluso no tipo de pacote (ver Subseção que fala sobre os pacotes do AntHocNet). Em outras palavras, a leitura e manipulação dos pacotes recebidos pelo protocolo não é uma tarefa trivial de ser feita. Ao manipular estas informações, é necessário muito cuidado, pois do contrario o NS-2 fará a leitura errada do cabeçalho do pacote. Isso pode causar a perda do pacote ou mesmo o programa pode ser finalizado antes da conclusão da simulação. 4.3 Implementação do AntHocNet Toda a implementação do AntHocNet utilizou as bases da estrutura de classes do NS- 2, isto é, no desenvolvimento e criação das classes não foi criado nada de novo a não ser um novo protocolo de roteamento, o AntHocNet. Em mais detalhes, não foi modificado estruturas e criação de pacotes, e nem foi realizada modificação em algum outro protocolo (seja enlace ou aplicação) para se adequar ao AntHocNet. A principio, tentou-se utilizar a implementação do protocolo de rede AntNet. Sabe-se

58 4 Implementação da Proposta 43 que o AntHocNet é baseado no AntNet, então como já existia uma implementação deste predecessor, houve a tentativa de utilizá-la, mas que acabou não sendo usava, pois os códigos fontes do AntNet não se adequavam a versão corrente do NS-2. De tal forma, que a implementação foi reinicializada onde necessitou-se criar uma nova estrutura com novas classes. A nova estrutura se baseou na simples idéia em que cada nó de rede seria como um formigueiro. Sendo assim o formigueiro ficaria a cargo de gerenciar as trilhas de feromônio depositadas até os demais formigueiros, como também é responsável por criar novas formigas (métodos que iniciam com createant na classe AntNest) e remove-las (método killantpacket da classe AntNest) quando estas encontram seu destino. Combinando o conhecimento aprendido na tentativa de adequar o AntNet à arquitetura orientada a objetos do NS-2, a implementação passou a ser estruturada e separada em cinco classes principais, são elas: AntHocNetUtils: nesta classe é especificada as constantes globais ; AntBasicPacket: nesta classe é especificada a idéia básica da formiga, sendo todas as demais formigas subclasses desta; PheromoneTable: nesta classe são especificadas as tabelas de feromônio, sendo responsável por disponibilizar os métodos para acessa-las; AntNest: nesta classe é especificada a idéia do formigueiro que gerência as trilas de feromônio; AntHocNet: nesta classe é especificado o protocolo, com os métodos para receber e encaminhar os pacotes da rede. Nas subseções a seguir,são vistas, em detalhes, uma dessas classes, bem como as suas subclasses implementadas. Sendo que na Subseção é descrito os tipos de estruturas de dados criados para a manipulação das informações armazenadas no AntHocNet Estruturas de Dados do AntHocNet No desenvolvimento da implementação do AntHocNet notou-se a necessidade da criação de tipos de estruturas customizadas para realizar a manipulação das informações. Seja

59 4 Implementação da Proposta 44 estruturas montadas para o armazenamento de informações sobre endereços de nós, ou mesmo uma tabela de feromônio. Cada tipo de dado foi criado para resolver um problema específico, por exemplo, a estrutura de uma tabela de feromônio deve conter o agrupamento das informações: < nó vizinho : nó destino : feromônio > Para uma combinação < nó vizinho : nó destino > é necessário garantir que existisse apenas um valor de < feromônio >. Esse problema é resolvido utilizando a classe std:map para controlar as entradas de informações (ver MapNodePheromone na Tabela 4.1), sendo sua chave um std:pair de dois endereços de nós da rede (ver NodeEntry na Tabela 4.1). Com essa estrutura de tabela de feromônio montada, era possível obter a informação de todos os destinos que o nó poderia chegar, mas isso causava um atraso ao tentar sabe quais eram os destinos conhecidos e quem eram seus nós vizinhos. Isto fez surgir outros dois tipos, AntDestinations e AntNeighbors (ver Tabela 4.1). Ambos são representados por listas do tipo std::set que garantem que os endereços armazenados nela não se repitam. Isso proporcionou um ganho de desempenho, pois fica fácil saber quem são os vizinhos e quais os destinos que o nó pode alcançar. Fora que uma iteração dessas duas lista pode ser usada para criar agrupamentos de < nó vizinho : nó destino > e com isso saber o valor de < feromônio > armazenado na estrutura MapNodePheromone. A lista completa dos tipos e suas descrições pode ser vista na Tabela 4.1. Todas os tipos de dados usados são nativos do C++ e por isso tiveram maior importância ao serem escolhidos. Todas estas estruturas de dados ficam no arquivo ant_types.h e são usadas por todas as classes implementadas do AntHocNet. Por serem muito usadas nos pacotes de formigas, as estruturas: AntNode e AntTime- Entry foram testadas e modificadas varias vezes. Elas ao serem utilizadas pelas formigas (ver Subseção 4.3.3), ocasionavam erros de alocação de memória quando se utilizada estruturas de listas (seja std:list, std:vector ou std:set). Ao realizar uma pesquisa mais a fundo, descobriu-se que e o NS-2 não conseguia duplicá-las quando enviava pacotes via broadcast, pois elas eram tipos std:pair. A mudança para tipos class e utilização de ponteiros ajudou a corrigir o problema de envio.

60 4 Implementação da Proposta 45 Tabela 4.1: Tabela com as estruturas de dados do AntHocNet. Nome Tipo de Dado Descrição AntDestinations std::set<nsaddr_t> Lista de nós de destino Associação do endereço AntHistory std::pair<nsaddr_t, u_int8_t> do nó com o número de sequencia AntHistoryList std::set<anthistory> Lista de formigas recebidas AntNeighbors std::set<nsaddr_t> Lista de nós vizinhos Classe que possui um AntNode class endereço do nó vizitado e o valor de feromônio Lista de pacotes AntPQueue std::set<packet*> aguardando uma rota até o destino Classe que possui AntTimeEntry class um endereço do nó vizitado e o tempo Mapa de NodeEntry MapNodePheromone std::map<nodeentry, double> associado a um valor de feromônio Mapa de endereço MapAntPQueue td::map<nsaddr_t, AntPQueue> de destino associado a lista AntPQueue Agrupamento de NodeEntry std::pair<nsaddr_t, nsaddr_t> dois endereços de nó da rede Classe AntHocNetUtils: constantes globais A classe AntHocNetUtils é do tipo utilitária pois armazena os valores para atualização do feromônio e tipos de formigas (ver Tabela 4.2). Esta classe conta com constantes globais acessadas por todas as demais classes da implementação. Como tudo fica referenciado por uma constate, fica fácil modificar seus valores sem impactar na implementação das demais classes. Os valores de cálculo de feromônio foram baseados na implementação feita no QualNet. Essa medida foi tomada para que a implementação do AntHocNet no NS-2 seja a mais próxima possível do original. Essa classe se encontra no arquivo ahn_protocol_utils.h.

61 4 Implementação da Proposta 46 Tabela 4.2: Tabela com as constantes globais disponibilizadas pela classe AntHocNetUtils. Constante Tipo Valor Descrição Porcentagem de evaporação do ALFA float 0.7 feromônio (α), usada pela classe AntNest Usado no cálculo de BETA int 20 feromônio (B 1 ), usada pela classe PheromoneTable Porcentagem de atualização GAMA float 0.7 de feromônio (γ), usada pela classe AntNest Tempo pré-determinado para HOP_TIME int 50 cada salto (S χ ), usada pela classe AntNest PROACTIVE int 1 Define que a formiga é pró-ativa, usada pela classe AntHocNet REACTIVE int 2 Define que a formiga é reativa, usada pela classe AntHocNet REPAIR int 3 Define que a formiga é reparo, usada pela classe AntHocNet Quantidade de feromônio MIN_PHEROMONE double minima para manter na tabela, usada pela classe AntNest Classe AntBasicPacket: formiga A classe AntBasicPacket é responsável pelo armazenamento das informações de rota, a classe AntBasicPacket é considerada o ponto crítico da implementação. Pois, se ela apresentar algum erro na alocação de memória, o roteamento do protocolo pode não funcionar direito e com isso toda pesquisa pode estar comprometida. O cuidado para garantir que os dados inseridos no pacote não sejam perdidos, foram feitos seguindo a orientação do cabeçalho da formiga, feita por Ducatelle (Ducatelle 2007). Em sua tese, foram descritos os campos necessários ao roteamento pelo AntHocNet, desta forma, utilizou-se essa base para formar os metadados básicos e comuns para todos os tipos de formiga. Na Tabela 4.3 é apresentada a lista de metadados da classe AntBasicPacket. Estes dados são utilizados por todas as formigas, pois foram projetadas para estender esta classe. A divisão de pacotes foi baseada no envio de formigas pró-ativas e reativas. Em todos

62 4 Implementação da Proposta 47 Tabela 4.3: Tabela metadados da classe AntBasicPacket. Nome Tipo de Dado Descrição anttype u_int8_t Tipo da formiga antdirection u_int8_t Direção da formiga visitednodes AntTimeEntry** Lista de nós visitados sizenodes int Quantidade de nós visitados sourceaddress nsaddr_t Nó de origem destinationaddress nsaddr_t Nó de destino timestartant double Tempo da criação da formiga no nó origem seqnum u_int8_t Número sequencial os casos, seja na busca de novos caminhos ou na reparação de rota, temos uma formiga que vai à procura do destino (forward), e outra que volta com o caminho até o destino (back). Essa simples divisão fez surgir as outras duas subclasses de AntBasicPacket: AntForwardPacket: formiga que vai á procura do destino; AntBackPacket: formiga que retorna com o caminho até o destino. Além disso pode-se observar na Figura 4.3 que a classe AntBasicPacket possui uma terceira subclasse: AntHelloPacket. E que as classes AntForwardPacket e AntBackPacket possuem subclasses relacionadas a reparos de rota: AntForwardRepairPacket e AntBackRepairPacket respectivamente. Isso se deve ao tipo da formiga (ver anttype na Tabela 4.3), são eles: ANTTYPEHELLO: fomiga de hello; ANTTYPEREACTIVE: fomiga reativa; ANTTYPEPROACTIVE: formiga pró-ativa; ANTTYPEREPAIR: formiga de reparo. Essa combinação do tipo com a instância de uma das subclasses de AntBasicPacket, pode ser responsável por distinguir uma REFA de uma PRFA. De forma que, uma instância de AntForwardPacket vai representar uma REFA se no seu tipo estiver dito que ela é reativa (ANTTYPEREACTIVE), e uma PRFA se for uma pró-ativa (ANTTY- PEPROACTIVE). Somente uma instância de AntHelloPacket pode assumir um tipo

63 4 Implementação da Proposta 48 ANTTYPEHELLO. O mesmo acontece para os subclasses AntForwardRepairPacket e AntBackRepairPacket, que sempre são o tipo ANTTYPEREPAIR. Figura 4.3: Diagrama da hierarquia das classes de formigas. Para formigas que usam o cabeçalho da classe AntForwardPacket os metadados vistos na Tabela 4.3 são suficientes. Mas quando essas encontram o destino e uma nova formiga é gerada com a classe AntBackPacket, o cabeçalho da formiga recebe novos metadados, conforme Tabela 4.4. Essas informações são usadas para poder calcular o feromônio e assim, atualizar as tabelas de roteamento dos nós visitados. Tabela 4.4: Tabela metadados da classe AntBackPacket. Nome Tipo de Dado Descrição prevhop nsaddr_t Nó antecessor hops int Número de saltos prevsinr double Tempo total que a formiga percorreu do destino até o nó atual pheromone u_int8_t Valor de feromônio calculado do destino até o nó atual Outro método de classificação utilizado foi o de separar as instâncias de formigas de reparo. Basicamente, eles não diferem muito das outras formigas, mas possuem uma atributo especial que é o tempo de vida da formiga (ver Tabela 4.5). Essa informação serve para determinar quando tempo a formiga de reparo tem para localizar o destino e

64 4 Implementação da Proposta 49 assim, corrigir a quebra de comunicação. Tabela 4.5: Tabela metadados da classe AntRepairPacket. Nome Tipo de Dado Descrição lifeant double Tempo de vida da formiga Com essa separação, foi criada uma outra classe: a AntRepairPacket (ver Figura 4.3). Esta serve de modelo para as formigas de reparo de rota. Basicamente as classes AntForwardRepairPacket e AntBackRepairPacket, estendem tanto a classe AntBasicPacket e a classe AntRepairPacket, isto se deve ao C++ que possibilita a herança de uma ou mais classes. Numa correlação com a linguagem de programação Java, poderia se dizer que AntBasicPacket é a super classe e que AntRepairPacket é uma interface. A implementação das classes de formigas estão inclusas nos arquivos: ant_packet.h e ant_packet.cc. Essas estruturas simplificaram a classificação da formigas recebidas, e assim o gerenciamento da tabelas de feromônio por parte do formigueiro (ver Subseção 4.3.5) o qual fica transparente ao protocolo Classe PheromoneTable: tabela de feromônio Classe responsável pelo controle e armazenamento das tabelas de feromônio, Pheromone- Table disponibiliza método de inserção e busca e remoção de caminhos para um determinado destino da rede. Esse controle se baseia na utilização das tabelas de feromônio regular e virtual, vistas na Subseção Essa classe só pode ser acessada pela classe AntNest, isto é, o formigueiro (ver Subseção 4.3.5). Somente ele pode utilizar os métodos para modificar o feromônio de cada rota. Assim, quando um pacote é recebido pelo protocolo, este vai consultar o formigueiro para saber qual o próximo destino a ser encaminhado. No caso for uma formiga, se esta deve ser usada para atualizar o feromônio. A utilização de feromônio regular ou virtual vai depender unicamente do tipo do pacote recebido (Figura 4.4). Somente formigas pró-ativas podem usar o feromônio virtual, isto se deve ao processo de melhoria e atualização das rotas, onde a formiga pró-ativa passa a buscar outros caminhos para evitar futuras quebras de comunicação.

65 4 Implementação da Proposta 50 Figura 4.4: Classe PheromoneTable gerencia as tabelas de feromônio. Assim, qualquer outro pacote que não seja uma formiga pró-ativa, passa a usar a tabela de feromônio regular. Tornando-o o principal elemento da classe PheromoneTable, e indispensável para o roteamento do conjunto. Na Tabela 4.6 é apresentado as cinco estruturas para armazenar as rotas na memória (ver Subseção 4.3.1) da classe PheromoneTable, isto é, duas para controlar as tabelas de feromônio (MapNodePheromone), uma para armazenar a lista de nós vizinhos (AntNeighbors) e duas lista para guardar os nós destinos conhecidos (AntDestinations). Tabela 4.6: Tabela das estruturas de armazenagem da classe PheromoneTable. Nome Tipo de Dado Descrição pheromone_regular MapNodePheromone Tabela de feromônio regular pheromone_virtual MapNodePheromone Tabela de feromônio virtual neighbor_table AntNeighbors Lista de nós vizinhos formiga dest_table_regular AntDestinations Lista de nós destinos regular dest_table_virtual AntDestinations Lista de nós destinos virtual As tabelas de feromônio pheromone_regular e pheromone_virtual, vistas na Figura 4.5, são coleções de elementos que combinam uma chave < endereço do nó vizinho : endereço do nó destino > com o valor < valor do feromônio >. Essa estrutura facilita a busca e a manipulação dos dados, isto é, se o formigueiro requisitar a inclusão de uma chave que já exista na tabela, a classe irá substituir o valor antigo pelo novo, não gerando duplicatas. Esse controle é feito pelos métodos setpheromoneregular e setpheromonevirtual, que tem como parâmetros [ endereço do nó destino, endereço do nó vizinho, valor do feromônio ]. Nas listas de nós destinos (dest_table_regular e dest_table_virtual) e nós vizinhos (neighbor_table), são estruturadas de tal forma, que a inclusão de mesmos endereços de nós nunca se repitam. Assim, se o formigueiro requisitar a inclusão de um nó que já

66 4 Implementação da Proposta 51 Figura 4.5: Diagrama de classe de PheromoneTable. esteja contido na lista, a classe irá ignorar, e não realizará qualquer modificação. Para os endereços de destino, esse controle também é feito nos métodos setpheromoneregular e setpheromonevirtual, mas para nós vizinhos a classe disponibiliza o método addneighbor, onde este recebe o parâmetro [ endereço do nó vizinho ]. Vale ressaltar que nenhum cálculo de atualização de feromônio é feito na classe, esse controle é feito pelo formigueiro. O único cálculo realizado na classe é para saber qual o próximo nó a ser usado para alcançar um determinado destino. Essa busca é feita pelo método lookup, que recebe com parâmetro [ endereço do nó destino ] e retorna o [ endereço do próximo nó vizinho ]. A escolha da rota é feita probabilisticamente pela Equação 4.1, que utiliza o valor 20 para B 1. P nd = (T i nd )20 j N i d (T i jd )20 (4.1) Como visto na Equação 3.2 descrita na Seção 3.3.1, um valor maior que um para B 1

67 4 Implementação da Proposta 52 configura que o AntHocNet para diminuir o envio de pacotes por múltiplas rotas. Esse valor garante que a rota com maior quantidade de feromônio tenha prioridade na sobre as demais rotas. Essa medida foi adotada, pois a rota com maior quantidade tende a ser a melhor até o destino, isso é, as formigas pró-ativas passam a realizar a manutenção das rotas, melhorando os caminhos conhecidos pelo nó. Nos arquivos: ahn_pheromone_table.h e ahn_pheromone_table.cc estão inseridos os códigos fontes da implementação da classe PheromoneTable. Apesar dessa classe guardar informações do feromônio espalhado na rede, ela não sabe da existência das formigas, isto é, apenas o formigueiro tem controle sobre a leitura das informações contidas nas formigas Classe AntNest: formigueiro Partindo da idéia que temos formigas espalhando trilhas de feromônio na rede e que estas são criadas por cada nó, surgiu a necessidade de se criar uma classe onde fosse possível gerenciar a criação e morte de formigas. Assim como a manipulação das informação dos caminhos visitados e com isso atualizar o feromônio depositado nas trilhas. Com isso, criou-se a classe AntNest, ou formigueiro. Sua estrutura foi construída para gerenciar a criação de formigas, isto é, toda vez que uma formiga é gerada pelo formigueiro um novo número de sequência é atribuído a esta (ver ant_seq_num_ na Tabela 4.7). Assim, quando um nó da rede recebe uma formiga, o formigueiro verifica em seu histórico se já a recebeu (ver history na Tabela 4.7), caso seja uma repetição (geralmente causado por broadcast), ele a mata para evitar looping de pacotes. Tabela 4.7: Tabela das estruturas de dados da classe AntNest. Nome Tipo de Dado Descrição pheromone_rt_ PheromoneTable* Tabela de feromônio mapqueue MapAntPQueue Lista de pacotes a espera de um destino history AntHistoryList Histórico de formiga recebidas addr_ nsaddr_t Endereço do nó na rede ant_seq_num_ u_int8_t Número sequencial, incrementado para cada formiga Além disso, a classe é responsável por armazenar os pacotes que estão esperando por uma rota até o destino (ver mapqueue na Tabela 4.7). Eles são guardados numa coleção

68 4 Implementação da Proposta 53 de elementos que combina uma chave < nó destino > com o valor < lista de pacotes >, assim quando uma formiga que possuir o destino requerido pela chave for recebida pelo protocolo, a classe pode rapidamente buscar por esses pacotes e liberá-los para que sejam enviados. O controle das trilhas de feromônio é realizado pelo formigueiro ao manipular a classe PheromoneTable (Subseção 4.3.4), isto é, a classe AntNest é quem recebe as informações da formiga e calcula o valor de feromônio que deve ser depositado naquela trilha. Com isso, ela acaba sendo responsável por modificar a probabilidade nas rotas em função do feromônio aplicado, para um determinado destino. Em outras palavras, a classe AntNet se comportaria exatamente como visto na Figura 4.6, onde se observa o formigueiro como sendo um nó da rede. Este por sua vez conhece quatro rotas, uma para o nó 0, outro para o nó 1, 3 e 5. Assim, quando um pacote precisar ser encaminhado a algum destes destinos, o formigueiro poderá dar um caminho valido para que o protocolo faça o envio. Figura 4.6: Trilhas de feromônio gerenciadas pelo formigueiro. Um ponto importante que deve ser discutido, é que o formigueiro não sabe quando é necessário descobrir uma nova rota. A função de envio de formigas é feita exclusivamente pelo protocolo (Subseção 4.3.6), deixando que a classe fique responsável pelo controle do feromônio. Na Figura 4.7 é detalhado o funcionamento do algoritmo de atualização do feromônio. Ele se inicia quando o protocolo recebe uma formiga com instância de AntBackPacket (ver Subseção 4.3.3) e então executa o método updateregularpheromone, passando como parâmetros [ endereço do nó destino, endereço do nó vizinho, valor do feromônio ]. O algorítimo utiliza a referência de pheromone_rt_ para buscar < lista de nós vizinhos >, e iniciar uma iteração nessa lista. Pois para um mesmo destino pode ter vários nós

69 4 Implementação da Proposta 54 Figura 4.7: Algorítimo de atualização de feromônio. vizinhos como saída, com diferentes valores de feromônio. Para simplificar a explicação é adotada a seguinte nomenclatura: i : endereço do nó vizinho da iteração na < lista de nós vizinhos >; d : endereço do nó destino passado como parâmetro; n : endereço do nó vizinho passado como parâmetro; t n d : valor do feromônio passado como parâmetro. Cada iteração o algorítimo verifica se a combinação entre < i : d > possui um valor de feromônio (Tid i ). Caso não exista, é verificado se o i é igual a n. Se não for, o algorítimo desvia para o próximo vizinho da lista.

70 4 Implementação da Proposta 55 O incremento de feromônio ocorrerá quando for detectado que o i é o mesmo que foi passado como parâmetro, ou seja n. Então o algorítimo executa método incresspheromone (ver Figura 4.8), passando o valor atual do feromônio (Tid i ) e o valor que deve ser acrescentado (t n d ). Figura 4.8: Diagrama de classe de AntNest. Esse cálculo é feito pela Equação 4.2, que utiliza o valor 0,7 para γ. Além disso se observar a Equação 3.5 (ver Subseção ), perceberá que o valor de acréscimo do feromônio é sempre o mesmo, independente do i. Isso é verdade, mas repare que esse cálculo só é feito se n e i forem iguais, então essa diferença não existe. T i nd = 0, 7 T i id + (1 0, 7) t n d (4.2) Para todos os outros i o valor do feromônio é evaporado, isto é, decrementado. O algorítimo utiliza o método evaporatepheromone (ver Figura 4.8), passando o valor atual do feromônio (Tid i ). Essa atualização é feita usando a Equação 4.3, onde pode ser visto que sempre que um valor for evaporado, este perde 30% do seu valor original. processo é semelhante ao que acontece com o feromônio no mundo real, que acaba fazendo desaparecer as trilhas que não forem utilizadas. Esse

71 4 Implementação da Proposta 56 T i id = T i id (1 0, 7) T i id (4.3) Assim, a classe AntNest faz o gerenciamento das trilhas de feromônio. A sua implementação está incluída nos arquivos: ahn_ant_nest.h e ahn_ant_nest.cc Classe AntHocNet: protocolo A classe AntHocNet é a implementação do protocolo no NS-2. Sendo ela a responsável por receber os pacotes enviados pelo simulador e determinar as rotas. O NS-2 não obriga que o protocolo de rede utilize uma tabela de roteamento central, isto é, cada implementação de protocolo fica livre criar a sua da forma que bem quiser. No caso do AntHocNet utiliza uma tabela de feromônio, como visto na Subseção Com essa flexibilidade, o NS-2 atrela toda a responsabilidade do rotamento para o protocolo, assim quando é registrado uma necessidade de enviar um pacote TCP (por exemplo), o simulador constrói o pacote e executa o método recv do protocolo de roteamento. Esse método pertence originalmente da classe Agent, o qual visto na Figura 4.9 é estendida pela classe AntHocNet. Na implementação do protocolo, nada foi modificado de Agent. O desenvolvimento do protocolo se preocupou em reutilizar o máximo de métodos e classes fornecidos pelo NS-2. Com isso, a classe ficou focada em resolver o problema de roteamento. Na Figura 4.9 é visto o diagrama da classe implementada para este trabalho. Nela é possível ver que a maioria dos métodos foi projetado para receber e enviar formigas pela rede, isto é, quando o NS-2 executa o método recv do protocolo, este pode criar ou mesmo retransmitir uma formiga. Sendo o método recv o mais importante da classe, pois na execução da simulação todos os pacotes passam por ele. Como a estrutura das formigas foi projetada para ser o mais genérica possível, facilitou a detecção dos pacotes recebidos pelo protocolo, pois ou os pacotes recebidos pelo protocolo são formigas ou não são. O algorítimo que faz esse controle é visto na Figura Inicialmente quanto um pacote é recebido pelo protocolo, é realiza a primeira checagem a fim de comprovar se uma formiga foi recebida.

72 4 Implementação da Proposta 57 Figura 4.9: Diagrama de classe de AntHocNet. Caso o pacote em questão não seja uma formiga, e sim um TCP (por exemplo) o protocolo vai consultar a tabela de feromônio para ver se encontra uma rota valida para o destino requerido pelo pacote TCP, caso encontre o envia imediatamente, senão o armazena uma lista de pacotes e então pede ao formigueiro para que crie uma REFA e assim, esta é enviada para descobrir um caminho. O encaminhamento de pacotes através de um ou mais rotas é a parte básica que se espera de um protocolo de roteamento. O que complica nesse processo é a obtenção de novas rotas pelo protocolo. Que neste caso, se dá quando o método recebe uma formiga. Esta é classificada em três grupos (ver Subseção 4.3.3): hello : utiliza o cabeçalho AntHelloPacket; forward : utiliza o cabeçalho AntForwardPacket; back : utiliza o cabeçalho AntBackPacket;

73 4 Implementação da Proposta 58 Primeiramente, um protocolo só consegue funcionar corretamente se ele souber quem são seus nós vizinhos. Esta tarefa é confiada a formiga hello, pois é ela quem informa ao protocolo que este possui um vizinho. Essa formiga é então lida pelo formigueiro, o qual armazena a informação do nó vizinho e verifica se este enviou outras informações de rotas virtuais (ver Subseção ) e assim atualizar a tabela de feromônio virtual. Figura 4.10: Algorítimo de recebimento de pacotes. Esse envio de formigas hello é feito por todos os nós em tempos que variam de 750 á milissegundos. Processo semelhante acontece ao enviar PRFA, onde cada nó as envia em tempos com variação de á milissegundos. Na Tabela 4.8 é apresentado estes dados. Tanto a PRFA quanto a REFA são consideradas formigas forward pelo protocolo, e por isso são executadas da mesma maneira, isto é, se detectado que elas alcançaram seu destino, o protocolo então requisita ao formigueiro que crie uma formiga back do mesmo tipo que a formigas forward recebida. Assim, se for uma REFA o formigueiro criará uma

74 4 Implementação da Proposta 59 Tabela 4.8: Tabela de formigas que são enviadas periodicamente. formiga Intervalo de Tempo Descrição formiga hello 750 á milissegundos formiga enviada para descobrir os nós vizinhos. PRFA á milissegundos formiga enviada para realizar a manutenção das rotas. REBA e para PRFA, uma PRBA. A formiga back é usada exclusivamente para atualizar as trilhas de feromônio. Assim, quando o protocolo recebe uma, a usa para calcular o valor do feromônio a ser incrementado. Este cálculo é feito usando a Equação 4.4, a qual utiliza os seguintes parâmetros: 1. h : número de saltos do nó destino (d) até o nó atual (i). Esse valor é pego do cabeçalho da formiga back (ver hops na Tabela 4.4); 2. Hd i : estimativa de tempo do nó destino (d) até o nó atual (i). Esse valor é pego do cabeçalho da formiga back (ver prevsinr na Tabela 4.4); Esse cálculo é baseado na Equação 3.4 e utilizada o valor 50 milissegundos para a constante S χ. Esse valor é multiplicado pelo número de saltos h para estimar um tempo que supostamente levaria para a formiga ser enviada pela rede. ( ) H t i i 1 d = d + h 50 (4.4) 2 O valor do incremento t n d é usado pelo formigueiro que atualiza a tabela de feromônio. O protocolo então verifica se a formiga back alcançou o seu destino, pra poder liberar os pacotes que estão a espera de uma rota, e assim enviá-los corretamente. 4.4 Considerações do Capítulo Neste capítulo foi apresentado a implementação do protocolo de roteamento híbrido AntHocNet no simulador de redes NS-2. Toda sua estrutura de classes foi desenvolvida e criada neste trabalho. Esta modelagem de classes orientadas a objetos, possibilita a reutilização de código e proporciona um tratamento de classes de maneira genérica. Um bom exemplo é visto na

75 4 Implementação da Proposta 60 implementação das classes de formiga. Onde cada classe ficou especializada numa função, isto é, uma formiga back é diferente de uma formiga forward, pois esta não armazena o feromônio. E mesmo assim, as duas são consideradas formigas, onde que cada uma possui uma função dentro do formigueiro. Essa generalização é feita usando herança de classes. Outro ponto importante a destacar sobre a implementação, é visto na divisão de função de roteamento entre as classes AntHocNet (protocolo) e AntNest (formigueiro). Essa separação é feita para que cada classe se especialize numa tarefa, isto é, o formigueiro fica responsável pela tarefa de atualizar as tabelas de feromônio e o protocolo em enviar e receber formigas. Com essa modelagem baseada nas funções que cada classe deve possuir e qual tarefa deve realizar, facilita a manutenção de código e abre margem para inclusão ou mesmo modificação das funções de roteamento. Isto pode ocasionar na geração de novas classes, mas o que não quer dizer, por exemplo, que se for criada um novo tipo de formiga, a tabela de feromônio deva ser modificada. Com a finalização da implementação, iniciou-se o desenvolvimento dos cenários, apresentados no Capítulo 5. Deixando para o Capítulo 6 as descrições sobre as simulações realizadas no NS-2 entre o AntHocNet, desenvolvido neste trabalho, e o protocolo AODV, já incluso no simulador.

76 61 5 Modelagem dos Cenários Os cenários criados para as simulações foram escritos na forma de scripts TCL. Nestes cenários é possível configurar vários parâmetros a serem utilizados na simulação. Um exemplo é o tipo do protocolo de roteamento que é usado. Seguindo os parâmetros usando na simulação do AntHocNet e AODV, vistos na Subseção 3.3.2, deve-se criar uma ambiente base que comporte 100 nós que se movam numa área retangular de m 2. A velocidade em que os nós devem se mover deve variar entre 0 e 20m/s, sendo que após o movimento o nó deve permanecer parado por 30 segundos. Toda simulação deve ocorrer num tempo de 900 segundos. Nesse período 20 diferentes comunicações são formadas aleatoriamente em uma determinada origem e um destino. Esse ambiente serve de base para os três tipos simulações, isso é, cada cenário varia pelo menos um dos parâmetros do ambiente base. Além disso, cada cenário é avaliado utilizando as métricas: Taxa de Pacotes Entregues (Packets delivered Ratio): é a proporção de pacotes TCP que foram recebidos pelos nós de destinos, divido pela quantidade de pacotes TCP enviados pelos nós de origem. R delivery = P ackets recv T CP P ackets send T CP (5.1) Atraso Médio Fim-a-Fim (Average End-to-End Packet Delay): é o somatório da média de tempo que um pacote TCP levou para ir do nó de origem até o nó de destino, dividido pela quantidade total de pacotes TCPs recebidos. tt CP R delay = Qt recv T CP (5.2) t T CP = t recv T CP t send T CP (5.3) Overhead de Roteamento (Routing Overhead): é a proporção de pacotes do protocolo de roteamento que são transmitidos, dividido pelo total de pacotes emitidos na rede. R delivery = P acketsrouting P ackets (5.4)

77 5 Modelagem dos Cenários 62 Com essas bases iniciou-se a análise para ver se era possível criar essas condições no NS-2. E logo de início o trabalho sofreu uma pequena derrota, pois não tinha uma solução para simular o tempo de parada do nó. Esse critério era essencial para a simulação vista na Seção 5.2, pois conforme o decorrer do tempo os nós tendem a aumentar o seu tempo de parada. Outro problema que concentrou tempo foi o de simular o aumento de nós na rede e também o aumento da área do ambiente. Esses parâmetros são fixos e não se tinha uma função que possibilitasse a inclusão de novos nós durante a simulação. Essa métrica é usada nos cenários 2 e 3 e as suas soluções para aumento dos nós e da área estão descritos na Seção 5.3 e Seção 5.4 respectivamente. Essa descrição da forma que foram construídos os cenários é detalhada neste capítulo, pois assim como o desenvolvimento do protocolo (ver Capítulo 4), consumiram um bom tempo de implementação e análise. Na Seção 5.1 é apresentada a descrição e o funcionamento básico do programa que foi desenvolvido para gerar scripts TCL, seguindo os requisitos de cada cenário. 5.1 Criação Automatizada de TCL A criação dos scripts em TCL ocorreu em duas fases. Na primeira tentou-se inserir todas as métricas que seriam aplicadas ao cenário diretamente no script. Esse ponto exigiu que toda a parte de programação fosse feita em TCL. Nessa primeira tentativa, criou-se um arquivo TCL de exemplo que continha simples rotinas que geravam posições aleatórias para a criação de nós e depois para sua movimentação na rede. Isto era completado uma terceira rotina que gerava as transmissões de dados entre dois diferentes pontos da rede. Este arquivo, possibilitou realizar testes num cenário aleatório, isto é, num cenário onde a posição dos nós ao longo do tempo não era sabida, a cada execução elas poderiam se alterar. Nas primeiras simulação com o AntHocNet, se percebe que o cenário consome muita memória quando é executado, e isso causa um certo atraso quando a rede passa a possuir mais de 30 nós. O consumo de memória e o atraso na execução chegou a resultados insatisfatórios, pois o protocolo seria testado em cenários com mais de 100 nós, gerando execuções de

78 5 Modelagem dos Cenários 63 mais de 1 dia. Vale ressaltar que esse atraso também era causada pela emissão de formigas hello durante a simulação, e precisaram ser ajustadas (ver Seção 6.1). Diante deste cenário iniciou-se a segunda fase, onde foi feita a criação automatizada de scripts TCL. Nessa etapa foi construído um programa que criava um arquivo TCL com todos os comando usados pelo NS-2. Nele eram geradas as posições iniciais dos nós e suas movimentações. Isto serviu de base para realizar as modificações necessárias em cada cenário. Dependendo do cenário que seria gerado, o programa deveria levar em considerações algumas funções a serem calculadas. Essas funções são explicadas na Seção 5.2, Seção 5.3 e Seção 5.4. E serviram para adaptar o ambiente desenvolvido no QualNet no NS Cenário 1: Aumento do Tempo de Parada dos Nós O Cenário 1 utiliza todas as métricas do ambiente base, com a diferença que conforme o decorrer da simulação os nós tendem a ficarem mais tempo parados, diminuindo a mobilidade. Essa métrica é usada pelo outros cenários, mas seu tempo é fixo em 30 segundos. No estudo da criação de scripts em TCL para executar os testes no NS-2, viu-se que não se tinha um parâmetro configurável para criar essa simulação de diminuição da mobilidade dos nós na rede. O que se tinha era configurações em TCL permitiam criar um nó numa determinada posição e depois determinar um tempo que esse nós iria se deslocar para outro lugar com uma velocidade configurável. Esse deslocamento dos nós é visto na Figura 5.1, onde cada movimento do nó n é representado por um vetor n. Com o vetor n é possível saber a posição inicial (x 0, y 0 ) e final (x, y) do nó dentro do cenário, sendo o deslocamento total calculado pela Equação 5.5. Essa trajetória é realizada sobre uma velocidade v que varia de 0 á 20m/s. A geração dessa velocidade é feita randomicamente pelo programa desenvolvido para criar os cenários. Basicamente é um número randômico inteiro entre 0 e 20. n = x 2 + y 2 (5.5) Tendo esses dois valores é possível calcular o tempo que o nó demorou para se mover de um ponto a outro pela Equação 5.6. Esse tempo é usado para saber de ante mão em

79 5 Modelagem dos Cenários 64 Figura 5.1: Movimento dos nós n, representados por vetores n. que período de tempo o nó finaliza a sua trajetória. t n = n v (5.6) Esse dado é então utilizado para calcular o tempo em que o nó desloca-se novamente, isto é, em que período de tempo ele se movimenta. Na Equação 5.7 é calculado o tempo que o nó se movimenta para uma nova posição no ambiente. Veja que para o ambiente base atribui o valor de 30 segundos para o tempo de parada p n, de maneira que até o calculo desta equação os outros cenários também irão usar. t n = t n + p n (5.7) Com essas formulas é possível calcular o tempo de parada de cada nós, e assim gerar os scripts em TCL. O único detalhe que faltou para concluir a criação do Cenário 1, onde a variação do tempo de parada p n deve aumentar conforme o tempo. Esse aumento é feito pela simples Equação 5.8, onde inicialmente os nós não tem um tempo de parada, mas conforme eles se deslocam é realizada o tempo de parada é duplicado. Se t n = 0, então p n = 0 Se t n > 0 e p n = 0, então p n = 15 Senão p n = p n 2 (5.8) Esse tempo varia de 0 até 450 segundos no decorrer da simulação. E possibilita simular o incremento no tempo de parada descrito na simulação feita no QualNet. Desta forma,

80 5 Modelagem dos Cenários 65 a criação da posição inicial dos nós e seu deslocamento em TCL foi realizada por um programa a parte. Onde este realiza os cálculos anteriores e gera o script TCL. Basicamente, o que é necessário saber são os comandos devem ser escritos no script TCL, são eles: # ## Cria a posição inicial do nó $i ## # $node_($i) set X_ $y $node_($i) set Y_ $y $node_($i) set Z_ 0.0 # ## Cria o movimento do nó $i num tempo $t, com uma velocidade $v # $ns at $t "$node_($i) setdest $x $y $v" Os valores para $i, $x, $y e $v, são gerados randomicamente pelo programa que cria os TCLs. Cada um deles recebe um valor real, respeitando os seus limites inferiores e superiores. 5.3 Cenário 2: Aumento de Nós Com o problema de simular o tempo de parada resolvido ao criar o script TCL para o Cenário 1, iniciou-se o desenvolvimento do script para o Cenário 2. Inicialmente não parecia ter muitos problemas, mas quando foi realizada a análise para inclusão de novos nós durante a simulação começou os problemas. No NS-2 não é possível incluir novos nós durante a simulação, isto é, se ela iniciar com 50 nós no total, deve usar somente 50 nós. Isso gerou um complicador, pois para o Cenário 2 precisasse que a quantidade de nós na rede varie entre 50 á 150. Isso quer dizer que para executar a simulação neste cenário é obrigatório que o TCL seja configurado para possuir 150 nós. Tendo isso em mãos, precisou-se criar um mecanismo para desligados e religá-los somente quando estes fossem necessários. Isso é possível usando o módulo de consumo de energia presente no NS-2. Deste modo, é possível dizer a quantidade de energia que o nós possuirá, como também os parâmetros de consumo ao receber e enviar os pacotes. E principalmente, pode ser usada a função de liga (on) e desliga (off ) para cada nó.

81 5 Modelagem dos Cenários 66 Assim, era possível criar a rotina que desligava os nós a mais e os religava no tempo correto. Isto necessitou que fosse desenvolvido uma formula para calcular o tempo de incremento de novos nós. Esse cálculo é baseado na utilização de um fator de atualização de nós f u, visto na Equação 5.9, que nada mais é que a divisão de três constantes do cenário: T f : tempo total da simulação. Neste cenário possui valor de 900 segundos. Qt max n : quantidade máxima de nós na rede. Neste cenário possui valor 150 nós. U : quantidade de nós a serem adicionados por vez. Neste cenário possui valor 100 nós. f u = T f Qt max n + U (5.9) Isto serviu para criar-se a Equação 5.10, onde ao se multiplicar o fator f u com a quantidade de nós Qt n, era possível saber o tempo t u em que deveria ser feito o religamento dos nós no ambiente. t u = f u Qt n (5.10) Com essas equações, a simulação de variação da quantidade de nós na rede poderia ser criada. Mas como nem tudo é perfeito, o NS-2 tinha um problema quando era requisitado o desligamento do nó. Ele gerava erro na simulação e parava a sua execução. Então para se poder simular o Cenário 2, foi necessário corrigir esse bug e dar continuidade ao trabalho. Por sorte o erro foi corrigido, demorou-se para descobrir a sua causa, mas no fim a correção foi relativamente simples. Bastou uma alteração no código da classe MobileNode em C++. Essa modificação é vista no código abaixo, onde removeu-se o %s reset-state que não exite, pelo %s reset utilizado no atual NS } else if (strcmp(argv[1], "off") == 0) { energy_model()->node_on() = false; tcl.evalf("%s set netif_(0)", name_); const char *str = tcl.result(); tcl.evalf("%s NodeOff", str); tcl.evalf("%s set ragent_", name_);

82 5 Modelagem dos Cenários 67 }... str = tcl.result(); // Correção para utilizar o módulo de energia //tcl.evalf("%s reset-state", str); tcl.evalf("%s reset", str); God::instance()->ComputeRoute(); return TCL_OK; De forma que bastou criar a rotina para gerar o script TCL com os nós a mais desligados, os religando mais tarde. # ## Desliga o nó $i ## # $ns at 0.0 "$node_($i) off" # ## Religa o nó $i num tempo $t ## # $ns at $t "$node_($i) on" O estudo e a modificação no módulo de energia parecem simples, mas implicaram em um aprofundado estudo, tanto da parte de TCL quanto nos códigos fontes em C++. Apesar da correção ter sido tranquila, a localização do erro não foi. 5.4 Cenário 3: Aumento da Área Todos os cenários anteriores propiciaram um grau de dificuldade a mais no projeto, mas que no final os seus resultados serviram para iniciar a criação do script TCL para o Cenário 3. Neste caso, era necessário simular o aumento gradativo dos nós (ver Subseção 5.3), juntamente com o aumento gradativo do ambiente. Em outras palavras, a densidade definida entre quantidade de nós Qt n e área A não pode variar. Como o ambiente base define que numa área m 2 existirão 100 nós, pode se estipular a seguinte proporção: 100 Qt n = A

83 5 Modelagem dos Cenários 68 De onde se pode deduzir a Equação 5.11 para calcular qual a área A necessária para atender uma quantidade de nós Qt n. A = Qt n (5.11) Como a quantidade de nós Qt n aumenta conforme o tempo, a área A também deve seguir na mesma proporção. Sendo que a variação da área retangular do ambiente deve crescer em proporções iguais, isto é, para cara mil vezes que for aumentado no eixo y, três mil vezes devem ser acrescidas no eixo x. Desta forma, deduziu-se a Equação 5.12 para calcular esse fator de aumento dos eixos (f a ). Essa equação partiu da seguinte estimativa: 3.000f a 1.000f a = A Com isso chegou-se na equação: A f a = (5.12) Este fator f a serviu para calcular os limites superiores que um nó poderia chegar no ambiente. Assim, por exemplo, num determinado intervalo de tempo t, em que o ambiente deva comportar 300 nós, o fator de aumento dos eixos f a é aproximadamente 1, Isso quer dizer que um nó pode andar num ambiente retangular de proporções 5.196, , 0508m 2, caracterizando o aumento gradativo do ambiente, sem alteração na densidade entre quantidade de nós Qt n e área A. 5.5 Considerações do Capítulo A criação de simples funções matemáticas que possibilitam calcular as mudanças de ambiente e assim, utilizar esse dados para gerar o script TCL. Isto possibilitou uma vantagem ao reduzir a sobrecarga de geração de nós aleatórios pelo simulador, diminuindo o consumo de processamento e memória. Criando todos os nós no script, e logo inserindo suas futuras movimentações durante a simulação, possibilita realizar a comparação entre diferentes protocolos de roteamento nas mesmas condições de ambiente, isto é, os nós que se movimentam e se comunicam são as mesmas em ambas execuções.

84 69 6 Simulação do AntHocNet A simulação do AntHocNet no NS-2 (NS ), foi feita seguindo os parâmetros utilizados por Di Caro (Di Caro, Ducatelle e Gamberdella 2005) nas simulações do protocolo no QualNet (QualNet 2011). Como há diferença entre os dois simuladores as especificações dos ambientes tiveram de ser adaptados para poderem ser executados no NS-2. Um dos problemas iniciais estava na construção dos três tipos de cenários apresentados pelo autor. No primeiro notou-se o critério do tempo de parada dos nós em que a medida que a simulação fosse sendo realizada os nós se movimentariam menos. Esse recurso não existe no NS-2, isso é, não tem um comando que faça com que os nós se movimentem menos. Esse complicador gerou a necessidade da criação de funções matemáticas que permitissem gerar os cenários. Isto é visto no Capítulo 5, onde é possível criar os scripts de forma randômica. Garantindo que os padrões adotados no QualNet, possam ser adaptados ao NS-2. Com os scripts em TCL criados, iniciou-se o trabalho de realizar as simulações dos protocolos. Que no inicio criaram inconvenientes devido ao grande tempo e consumo de processamento que cada uma levava. Para se ter uma idéia, as primeiras simulações atrasavam quase 16 horas devido a enorme emissão de pacotes de hello. Na Seção 6.1 é visto como a modificação dessa emissão de pacotes proporcionou a diminuição do tempo da simulação de 16 horas para 10 minutos. Os detalhes sobre as métricas e os parâmetros utilizados nas simulações e cenários estão descritos no Capítulo 5. Com isso, foram gerados 10 ambientes aleatórios para cada cenário. De forma, cada protocolo fosse simulado uma vez em cada um deles, isto é, 10 execuções para o AntHocNet e 10 vezes para o AODV para cada cenário, totalizando em 60 testes ao todo. Após a execução das simulações pelo NS-2, arquivos de dados foram gerados, e continham as transmissões de pacotes que foram emitidas durando a execução. Os arquivos com os dados de transmissões descreviam basicamente:

85 6 Simulação do AntHocNet 70 O tempo que o pacote foi enviado ou recebido; O nó que recebeu ou enviou o pacote; Tipo do pacote, isto é, se é um pacote do AntHocNet ou do AODV, ou mesmo se é TCP; Dados cabeçalho de cada pacote: nó de origem, nó de destino entre outros. Estas informações serviram de base para gerar os dados finais e assim, conseguir os resultados apresentados na forma de gráficos, vistos na Seção Implicações na Implementação Ao iniciar as simulação notou-se que o envio das formigas hello causava uma grande quantidade de processamento. Isto comprometia a execução devido a numerosa disposição dos nós no cenário. Essa emissão de pacotes via broadcast era feita num intervalo de tempo de aproximadamente de 1 segundos. Isto numa rede com 100 nós, supondo que cada nó tenha pelo menos 10 vizinhos, gera uma taxa média de 1000 formigas hello por segundo sendo emitidas na rede. Se analisarmos essa emissão no Cenário 3, onde num determinado intervalo de tempo o ambiente irá possuir 800 nós, pode levar a uma emissão ainda maior. Ao observar o comportamento do AODV, percebesse que esta emissão de pacotes hello não comprometia a execução. Seu tempo médio no Cenário 1 ficava em torno de 10 minutos, enquanto que o mesmo com AntHocNet atrasava mais de 16 horas. Isto era causado devido a implementação do AODV no NS-2 não usar o envio de pacotes de hello, para localizar seus vizinhos e identificar as quebras de comunicação. Ele em vez disso ele identificava o nó vizinho pela camada de MAC, isso é, se ao enviar um pacote para o nó vizinho e este estiver desaparecido, a camada de MAC alerta o protocolo de roteamento que então detecta a quebra de comunicação. Essa função então foi implementada no AntHocNet. Mas a não transmissão de formigas hello causava um problema na manutenção de rotas, isto porque as formigas hello são responsáveis por montar as tabelas de feromônio virtuais, utilizadas pelas formigas proativas. Com o possível comprometimento da manutenção de rotas do AntHocNet foi preciso

86 6 Simulação do AntHocNet 71 reavaliar o envio das formigas proativas, sem alterar a implementação do protocolo em si. Isto quer dizer que a tabela de feromônio virtual deveria ser reavaliada. Nisto analisou-se que se a formiga proativa fosse enviada por numa curta emissão via broadcast, possibilitava atender a manutenção de rotas e assim, garantir o envio de pacotes por múltiplas rotas. Essa pequena emissão não poderia ser feita descontroladamente, pois senão a troca do broadcast das formigas hello pelas novas formigas proativas não valeria nada. Isto gerou uma serie de testes nos três cenários até analisasse que se elas fossem emitidas por broadcast nos dois primeiros saltos (ver Figura 6.1), a execução do programa não era comprometida e o envio de pacotes continuaria normal. Figura 6.1: Emissão de formiga proativa por broadcast nos 2 primeiros saltos. Essa simples alteração possibilitou executar as simulações no cenário um em torno de 10 minutos. Muito próximo do tempo de simulação do AODV. Como a implementação de emissão de formigas hello já estava pronta, esta não foi removia, apenas desabilitada. O AntHocNet pode ser executando rodando tando a modificação das formigas proativas ou mesmo com formigas hello, basta apenas configurar o protocolo para usar ou não a camada MAC. 6.2 Simulação e Validação Nos cenários foram realizadas 10 simulações, tanto para execuções com o protocolo AntHocNet quanto para o AODV. Estes geraram 10 arquivos de dados para cada proto-

87 6 Simulação do AntHocNet 72 colo. Onde cada um apresentou pouca diferença do outro, na emissão de pacotes. As diferenças eram esperadas, pois cada script TCL gerado, criava movimentos diferentes para os nós em cada cenário. Respeitando os parâmetros do ambiente. De maneira, que o comportamento das execuções se comportou de forma semelhante. Ao gerar-se gráficos separados para cada simulação percebeu-se que as 10 simulações, mesmo sendo diferentes, apresentavam semelhanças nas suas curvas. Desta forma, o estudo do comparativo dos protocolos passou para a próxima fase, em que se definiu por realizar a média destes resultados e apresentá-los na forma de um gráfico único para cada métrica utilizada (ver Capítulo 5). Estes gráficos são detalhados nas subseções seguintes, onde cada uma foi separada de acordo com cada cenário, visto que cada um tem características de ambientes diferentes Resultado da Simulação no Cenário 1 O Cenário 1 caracterizou-se pelo aumento gradativo no tempo de parada do nó durante a simulação. Considerando as configurações de máquina descritas na Seção 4.1, cada execução deste cenário obteve um atraso que ficou em torno de 9 minutos para ser executada. Totalizando aproximadamente 180 minutos, média total de 90 minutos para cada protocolo. Finalizada as execuções, iniciou-se a análise dos dados gerados e com isso a criação dos gráficos. O primeiro que a ser estudado foi o gráfico apresentado na Figura 6.2, onde é visto que para um pacote TCP ser enviado de um nó de origem até um nó de destino da rede, é mais rápido se este caminho fosse roteado pelo AntHocNet. Este caso é explicado devido a capacidade do protocolo poder enviar os pacotes por mais de uma rota. Visto que o AODV após ter selecionado um caminho o mantém até que a transmissão termine ou se detecte uma quebra de comunicação. Enquanto que o AntHocNet cria novas possibilidades, e em muitos casos, estas passam a ser melhores rotas naquele período de tempo. Em compensação quando o gráfico da Figura 6.3 foi gerado, não houve a mesmo ganho esperado. Esta comparação sobre a Taxa de Pacotes Entregues, isto é, o números de pacotes TCP que foram enviados pela origem dividido pelo número de pacotes TCP recebidos pelos seus destinos, o AODV teve um desempenho melhor.

88 6 Simulação do AntHocNet 73 Figura 6.2: Gráfico comparativo entre AntHocNet e AODV no Cenário 1, sobre o Atraso Médio Fim-a-Fim. Figura 6.3: Gráfico comparativo entre AntHocNet e AODV no Cenário 1, sobre a Taxa de Pacotes Entregues. Neste ponto tentou-se rever algum erro possível na implementação, mas não conseguiuse descobrir. Pelo menos não parecia ter um erro visível que atrapalha-se a entrega de pacotes. Este resultado foi insatisfatório, porém, ao observar que o AntHocNet entrega 50% dos seus pacotes e que o AODV estava entregando perto de 60%, percebeu-se que os dois tinham dificuldades na entrega de pacotes. Isto de acordo com Ducatelle (Ducatelle 2007), é uma característica do cenário em que ambos foram simulados. Isto ainda sim é um ponto que merece ser visto com mais detalhes. Pois, deve-se tentar melhorar essa entrega, visto que houve uma modificação no comportamento das formigas pró-ativas. E quem sabe isso possa servir de influência para a modificação de outras formigas, como por exemplo as de reparo de rota. Provavelmente uma das formigas mais importantes para garantir que o pacote TCP enviado chegue ao seu destino, mesmo

89 6 Simulação do AntHocNet 74 que neste caminho haja quebras constantes na comunicação. Com isso, para finalizar o estudo do Cenário 1 no NS-2, criou-se o gráfico da Figura 6.4, que comparava as taxas de pacotes dos dois protocolos emitidos na rede. Neste caso o AntHocNet, obteve uma menor taxa de emissão de pacotes. Figura 6.4: Gráfico comparativo entre AntHocNet e AODV no Cenário 1, sobre o Overhead de Roteamento. Esses dados obtidos no NS-2, com exceção da Taxa de Pacotes Entregues, se comportaram de forma semelhante aos apresentados na Figura 3.3. Onde o AntHocNet conseguiu bons resultados ao ser comparado ao AODV. E mesmo com a proporção de pacotes inferior, o AntHocNet do NS-2 acabou apresentado melhores resultados nas demais métricas Resultado da Simulação no Cenário 2 O Cenário 2 caracterizou-se pelo aumento do número de nós durante a simulação. Considerando as configurações de máquina descritas na Seção 4.1, cada execução deste cenário obteve um atraso que ficou em torno de 24 minutos. Isto deu um tempo médio de 480 minutos, divididos em 240 minutos para as 10 simulações do AntHocNet e 240 minutos para as execuções do AODV. Nestas simulações notou-se o grande aumento dos arquivos de dados, que passaram a ter mais de 6 Gigabytes. Esse numeroso crescimento das informações aconteceu devido a modificação para adição de novos nós, em outras palavras, a utilização do módulo de energia do NS-2. Com o aumento dos arquivos de dados, precisou-se limpá-los, isto é, remover as

90 6 Simulação do AntHocNet 75 informações de gastos de energia que não seriam usadas nas métricas e assim, gerar os gráficos. Essa nova montagem dos gráficos seguiu a mesma ordem da aplicada no Cenário 1 (ver Subseção 6.2.1). De forma que o primeiro gráfico gerado é visto na Figura 6.5, onde nota-se que que o AntHocNet manteve o menor tempo de entrega. Figura 6.5: Gráfico comparativo entre AntHocNet e AODV no Cenário 2, sobre o Atraso Médio Fim-a-Fim. Quando a rede passa a ter 75 nós, é verificado o primeiro aumento significativo, os dois protocolos sofrem um certo atraso. No caso do AntHocNet teve um aumento de 0.05 segundos em média, tornando a estabilizar quando a rede passa a ter 100 nós. Já ao se observar o AODV, nota-se que este passa a aumentar o seu tempo médio a medida que a rede cresce. Dando a impressão que este seria menos escalável que o AntHocNet. Essa melhora no tempo médio não é refletida quando se observa os resultados do gráfico da taxa de pacotes entregues, vistos na Figura 6.6. Neste, o AODV manteve a melhor média, assim como vista no Cenário 1. Mas que em compensação o AntHocNet desta vez apresentou uma taxa média de 80% de seus pacotes entregues. Isto ajudou a reforçar a idéia que uma possível modificação o comportamento das formigas. Pois o AODV apresentou uma boa média a entregar certa de 95% dos pacotes TCPs, podendo esta modificação melhorar a média do AntHocNet. Em compensação, e também de uma forma um pouco diferente na observada no Cenário 1 (ver Figura 6.4), o gráfico sobre a taxa de overhead apresentado na Figura 6.7

91 6 Simulação do AntHocNet 76 Figura 6.6: Gráfico comparativo entre AntHocNet e AODV no Cenário 2, sobre a Taxa de Pacotes Entregues. sofreu uma mudança a medida que a rede aumentava de tamanho. Figura 6.7: Gráfico comparativo entre AntHocNet e AODV no Cenário 2, sobre o Overhead de Roteamento. Essa diferença de emissão de pacotes é vista ao se observar que a medida que a rede aumenta de tamanho, o AODV tende a aumentar a quantidade de envio de seus pacotes pela rede. Enquanto que o AntHocNet permanece de modo estável, tendendo a diminuir o envio das formigas a medida que mais nós sejam incorporados a rede. Essa ocorrência se justifica pela manutenção de rotas do AntHocNet. Que de início acabam sendo emitidas em maior número, chegando a 40%, mas que no decorrer da simulação, essa emissão de formigas não causam um consumo excessivo da rede. A taxa de transmissão no final da simulação chega a aproximadamente 30% de pacotes enviados, o que não ocorre com o AODV que

92 6 Simulação do AntHocNet 77 tem média de 60% no mesmo período, tornando o AntHocNet mais estável neste cenário Resultado da Simulação no Cenário 3 Como esperado, no Cenário 3 o tempo de processamento nas execuções das simulações foram maiores que as realizadas no Cenário 1 e 2. Isto devido a característica do ambiente aumentar o número de nós de 100 para 800 nós, sendo que o aumento de área cresce na mesma proporção, sem apresentar mudanças na densidade entre nós e a área. Considerando as configurações de máquina descritas na Seção 4.1, a média de tempo de cada simulação ficou em torno de 65 minutos. Isso gerou no total minutos em execuções. Média de 650 minutos para cada protocolo. Nesse tempo os arquivos de dados gerados chegaram a ocupar aproximadamente 20 Gigabytes. Isto devido a utilização do módulo de energia, também usado no Cenário 2 (ver Subseção 6.2.2). Esses dados após serem filtrados, para usar somente as informações pertinentes ao roteamento, possibilitaram a geração dos gráficos no Cenário 3. Sendo a ordem iniciada pelo gráfico de média de atraso fim-a-fim, observado na Figura 6.8, possibilitou concluir que em todos os cenários o AntHocNet teve a melhor média no tempo de envio de um pacote TCP. Figura 6.8: Gráfico comparativo entre AntHocNet e AODV no Cenário 3, sobre o Atraso Médio Fim-a-Fim. Isso por um lado reforça que a característica de possuir múltiplas rotas para um mesmo destino, flexibiliza o envio. Mas claro que essa melhora não é refletida na Taxa de Pacotes Entregues que em todos os demais cenários não teve um peso significativo.

93 6 Simulação do AntHocNet 78 Desta vez, ao se analisar o gráfico da Figura 6.9, nota-se que o AODV manteve a média de entrega de 95% de seus pacotes, em quanto que o AntHocNet caiu para 70%. Esse resultado ao ser comparado ao Cenário 3 da Subseção 3.3.2, demonstra que ambas implementações do AntHocNet terminaram com cerca de 70% de pacotes entregues. O que realmente chamou a atenção foi a implementação do AODV no NS-2 conseguir manter uma média muito mais alta do que a sua desenvolvida no QualNet. Figura 6.9: Gráfico comparativo entre AntHocNet e AODV no Cenário 3, sobre a Taxa de Pacotes Entregues. Esses dados chamam a atenção pois o AODV é um dos protocolos mais estudados no NS-2, e está em constante melhora. Já o AntHocNet está na sua primeira versão e possivelmente terá muitas mudanças e melhorias. Visto que o NS-2 por ser um simulador de licença gratuita, e está difundido nos meios acadêmicos. Diferente do QualNet que é um programa comercial. Por fim, e para a surpresa, pois se esperava um resultado parecido com os dos Cenários 1 e 2. O gráfico sobre o a taxa de overhead dos protocolos, visto na Figura 6.10, demonstrou que o AODV não só é melhor na entrega de pacotes neste cenário, como também está com uma taxa menor de emissão de pacotes. Este resultado comparado aos demais cenário foi o mais interessante, pois a medida que a rede aumentou de tamanho, ambos os protocolos mantiveram uma taxa estável de envio de pacotes. Concluindo que se for mantido a densidade entre nós e área, as quebras de comunicação tendem a diminuir, e com isso menos pacotes de reparo de rota são emitidos. De maneira, que o AntHocNet ficou com uma média maior devido ao envio periódico

94 6 Simulação do AntHocNet 79 Figura 6.10: Gráfico comparativo entre AntHocNet e AODV no Cenário 3, sobre o Overhead de Roteamento. de formigas pró-ativas. Esta observação pode ser devido a modificação destas formigas para melhorar o tempo da simulação (ver Subseção 6.1), isto pode ter prejudicado de certa forma o resultado neste cenário. O que levar a crer que que novas modificação possam ser feitas para melhorar estes pontos que ficaram a baixo do esperado. 6.3 Considerações do Capítulo Neste capítulo foi apresentando as simulações da implementação do AntHocNet realizadas no NS-2. Estas foram feitas em três cenários, onde se observou que a implementação do AntHocNet possui melhores tempos de transmissão de pacotes do que o AODV, e apresenta taxas de overhead mais estáveis que o AODV. Quando comparado a proporção de pacotes entregues com sucesso, analisou-se que o AODV é superior ao AntHocNet. Isto sugere possíveis melhorias e quem sabe novas análise da implementação, pois se for contabilizado em números a diferença de entrega dos dois protocolos ficou em torno de 10%. Isto implica que o AntHocNet teria que melhorar mais de 10% nas entregas de pacotes, sem comprometer os resultados obtidos nas outras métricas. Essa melhoria não é simples de ser realizada e envolve novos estudos, isto é, melhorias que podem ser atribuídas ao protocolo, tornando mais flexível aos ambientes e assim, alcançar melhores resultados que o AODV.

95 80 7 Conclusão As redes móveis Ad Hoc (MANET - Mobile Ad hoc NETwork), são caracterizadas como um tipo específico de redes wireless ao se definir que estas não precisam de uma infraestrutura previamente montada (Tanenbaum 2003). Isto possibilita um dinamismo nos meios de comunicação, pois a MANET poda ser criada em qualquer ambiente (Harte 2004) (Tanenbaum 2003). A característica da MANET possuir nós que podem se movimentar livremente pelo ambiente, gera problemas ao se usar protocolos de roteamento que não estejam adaptados a ela (Johnson e Maltz 1996). Um deles é o protocolo de roteamento AntHocNet. Este protocolo foi desenvolvido no estudo da aplicação da Inteligência de Enxames (SI - Swarm Inteligence) nas MANETs(Ducatelle 2007). O uso da SI nas MANETs vem sendo feito há algum tempo (Di Caro e Dorigo 1998). Essa técnica proporciona bons resultados de acordo com a característica da rede estudada, isto é, disponibilizando rotas válidas e que ao longo da transmissão tendem a ser melhoradas. Com a criação de vários protocolos de roteamento baseados na SI, viu-se o AntHocNet foi o que obteve melhores resultados nas MANETs (Ducatelle 2007). Neste trabalho foram estudadas as bases teóricas que modelaram a estrutura básica do AntHocNet e como este deveria se comportar numa rede móvel. Com os dados obtidos, fica claro que a utilização das tabelas de roteamento como amostras de feromônios, possibilitam a criação de trilhas de feromônios e com isso, a tendência é que essas trilhas sejam melhoradas conforme o tempo. Assim, possibilitando que os pacotes ao serem transmitidos pela rede possam ajudar na melhoria das rotas. Logo, garantindo a manutenção das tabelas de feromônio, e com isso a constante atualização de feromônio para as rotas mais utilizadas. Com o levantamento dessas características, iniciou-se então o desenvolvimento de uma implementação do AntHocNet no simulador de redes Network Simulator 2 (NS-2) (NS ). Visto que não existia uma implementação válida para este protocolo neste simulador. A dificuldade de se implementar um protocolo no NS-2 sem ter uma base, requisitou

96 7 Conclusão 81 que uma análise fosse feita na sua estrutura, para assim se entender os critérios básicos e iniciar o desenvolvimento do trabalho em si. Houve também, incentivos da comunidade que estava querendo utilizar uma implementação do AntHocNet. Esse contato com a comunidade aconteceu após a publicação dos primeiros códigos fontes do protocolo no Source Forge. A continua procura dos interessados na implementação do AntHocNet no NS-2, via Source Forge ( ), incentivaram para a finalização deste trabalho. Com isso, todos os esforços se concentraram no desenvolvimento do protocolo. A base da idéia surgiu ao se imaginar de que cada nó da rede deveria se comportar como um formigueiro, e que cada pacote emitido por este seria uma formiga. Assim, cada formigueiro deveria saber ou então descobrir uma trilha de feromônio para os demais formigueiros da rede. Este modelo gerou as classes em C++ que formam a implementação do AntHocNet no NS-2. Basicamente cada classe, seja uma formiga ou formigueiro, tendem a ter funções especificas na parte do roteamento. Até mesmo as tabelas de feromônio tiveram de ser incorporadas na forma de uma classes que as gerenciasse de maneira simples, para que o formigueiro as atualizasse facilmente. Com essas características da implementação finalizadas, iniciou-se a criação dos cenários de testes onde seriam simulados os protocolos AntHocNet e AODV. Estas simulações deveriam seguir as mesmas condições de ambiente utilizadas na comparação de ambos protocolos no QualNet (QualNet 2011). Inicialmente notou-se que alguns dos critério usados nos cenários do QualNet não conseguiam ser aplicados no NS-2. Desta forma, realizou-se uma análise para gerar estes cenários de maneira de maneira que todos os requisitos de ambiente fossem atendidos. Isto implicou na criação de algumas fórmulas matemáticas para se poder calcular previamente as mudanças, e assim, criar o script em TCL que possui-se todos os critérios dos ambientes requeridos. Assim, as simulações foram feitas em três cenários, onde se observou que apesar da implementação do AntHocNet possuir melhores tempos de transmissão de pacotes do que o AODV, o mesmo não acontecia ao se medir a Taxa de Pacotes Entregues. Pelos números

97 7 Conclusão 82 se pode observar que a diferença básica de entrega dos dois protocolos ficou em torno de 10%. Mas isso implica que o AntHocNet teria que melhorar mais de 10% nas entregas de pacotes, sem comprometer os resultados obtidos nas outras métricas. Essa melhoria não é simples de ser realizada e envolve novos estudos, isto é, melhorias que podem ser atribuídas ao protocolo, tornando mais flexível aos ambientes e assim, alcançar melhores resultados que o AODV. Como sugestões de melhorias, pode ser citado a melhoria na transmissão das formigas de reparo, ao se detectar que um pacote esteja demorando para ser enviado, isto é, a formiga reativa que foi enviada para buscar uma rota pode ter se perdido no caminho de volta. Isto é um ponto interessante que deve ser analisado com cuidado, pois se ela não voltar, o pacote pode ficar esquecido na fila de envio do nó. Outra sugestão é a incorporação dos pacotes TCP como espécie de formigas operárias. Elas não descobrem novas rotas, apenas utilizam as rotas existentes. Desta forma quando um pacote TCP fosse transmitido com sucesso, a rota para o nó vizinho poderia incrementar o valor do feromônio. Assim, quanto mais pacotes TCPs fossem enviados para aquela rota, mais feromônio ela teria, e com isso a o encaminhamento de pacotes poderia ser maior e talvez aumentasse a proporção de pacotes entregues. Claro que isso não é trivial, pois para se fazer isso precisa-se garantir que o pacote realmente tenha sido recebido ao nó vizinho, e este consiga encaminhá-lo para o destino. Um outro ponto interessante a ser estudado uma possível forma de transmitir uma formiga de reparo, numa área limitada, isto é poucos nós vizinhos. Pois, se a quebra de comunicação aconteceu a poucos instantes, há muitas chances de que o nó próximo nó ainda esteja perto. É claro que esse estudo deve-se levar em conta que isso pode não ocorrer e que ai sim a formiga de reparo deva ser enviada via broadcast para toda rede, e assim localizar o nó desaparecido. Apesar do estudo não ter conseguido os melhores resultados em todas as métricas, possibilitou um grande aprendizado nas técnicas de roteamento em MANET, assim como os conhecimentos da SI aplicados a redes serviram para ampliar as soluções de roteamento. Além do grande entendimento do funcionamento das classes do NS-2 que gerencia o processo de simulações de redes sem fio. A implementação do AntHocNet no simulador de redes NS-2, foi desenvolvida neste

98 7 Conclusão 83 trabalho. Espera-se que novos estudos sobre o uso da SI no roteamento das MANETs se aprimorem, usando este trabalho. Visto que os códigos fontes estão disponíveis no Source Forge, facilitando a distribuição. Proporcionando que a comunidade os utilize para realizar novas simulações e até mesmo melhoramentos, pois o NS-2 é um simulador muito utilizado nos meios acadêmicos.

99 Referências Beni e Wang 1989 BENI, G.; WANG, J. Swarm Intelligence. Proc. Of the 7th Annual Meeting of the Robotics Society of Japan, p , Bisnik, Abouzeid e Busch 2006 BISNIK, N.; ABOUZEID, A.; BUSCH, C. Load Balanced Link Reversal Routing in Wireless Ad Hoc Networks. Asian International Mobile Computing Conference, Chakeres e Belding-Royer 2004 CHAKERES, I. D.; BELDING-ROYER, E. M. AODV Routing Protocol Implementation Design. Proceedings of the International Workshop on Wireless Ad Hoc Networking (WWAN), Tokyo, Japan, Christian Bettstetter and Giovanni Resta, and Paolo Santi 2003 Christian Bettstetter and Giovanni Resta, and Paolo Santi. The Node Distribution of the Random Waypoint Mobility Model for Wireless Ad Hoc Networks. IEEE Transactions on Mobile Computing, p , Câmara 2000 CâMARA, D. Um Novo Algoritmo de Roteamento para Redes Móveis Ad Hoc. Dissertação (Mestrado) Universidade Federal de Minas Gerais, Minas Gerais, Di Caro e Dorigo 1998 Di Caro, G.; DORIGO, M. AntNet: Distributed Stigmergetic Control for Comunication Networks. Journal of Artificial Intelligence Research (JAIR), p , Di Caro, Ducatelle e Gamberdella 2004 Di Caro, G.; DUCATELLE, F.; GAMBER- DELLA, L. M. AntHocNet: An Ant-Based Hybrid Routing Algorithm for Mobile Ad Hoc Networks. In:. Birmingham, UK: Proceedings of PPSN VIII - Eight International Conference on Parallel Problem Solving from Nature, Di Caro, Ducatelle e Gamberdella 2005 Di Caro, G.; DUCATELLE, F.; GAMBER- DELLA, L. M. Swarm Intelligence for Routing in Mobile Ad Hoc Networks. Swarm Intelligence Symposium, 2005.

100 Referências 85 Dorigo 2007 DORIGO, M. Swarm Intelligence. 1. ed. New York: Springer, Dorigo, Di Caro e Gambardella 1999 DORIGO, M.; Di Caro, G.; GAMBARDELLA, L. Ant Algorithms for Discrete Optimization. Artificial Life, Dorigo e Stützle 2006 DORIGO, M.; STüTZLE, T. Ant Colony Optimization. Cambridge: MIT Press, Ducatelle 2007 DUCATELLE, F. Adaptive Routing in Ad Hoc Wireless Multi-hop Networks. Tese (Doutorado) Universitá della Svizzera Italiana, Istituto Dalle Molle di Studi sull Intelligenza Artificiale, maio Gunes, Sorges e Bouazzi 2002 GUNES, M.; SORGES, U.; BOUAZZI, I. ARA - the antcolony based routing algorithm for MANETs International Conference on Parallel Processing Workshops (ICPPW 02), Haas et al HAAS, Z. et al. Wireless Ad Hoc Networks. In John Proakis, editor, Encyclopedia of Telecommunications, Haas 1997 HAAS, Z. J. A New Routing Protocol For The Reconfigurable Wireless Networks. IEEE 6th International Conference on Universal Personal Communications Record, Harte 2004 HARTE, L. Introduction to Bluetooth Technology: Market, Operation, Profiles, and Services. [S.l.]: Althos, IETF MANET 2008 IETF MANET. The Internet Engineering Task Force Mobile Ad-hoc Networking page (MANET). [S.l.], Disponível em: Acesso em: 28 de maio de Inkinen 2004 INKINEN, K. New Secure Routing in Ad Hoc Networks: Study and Evaluation of Proposed Schemes. Telecommunications Software and Multimedia, Izquierdo-Torres 2004 IZQUIERDO-TORRES, E. Collective Intelligence in Multi- Agent Robotics: Stigmergy, Self-Organization and Evolution Disponível em: citeseer.ist.psu.edu/izquierdo-torres04collective.html. Acesso em: 28 de maio de Johnson e Maltz 1996 JOHNSON, D. B.; MALTZ, D. A. Dynamic Source Routing in Ad Hoc Wireless Networks. In: IMIELINSKI, T.; KORTH, H. F. (Ed.). Mobile Computing. [S.l.]: Kluwer Academic Publishers, p

101 Referências 86 Kassabalidis et al KASSABALIDIS, I. et al. Swarm Intelligence for Routing in Communication Networks. Global Telecommunications Conference, Kennedy e Eberhart 2001 KENNEDY, J.; EBERHART, R. C. Swarm Intelligence. San Francisco, California: Morgan Kaufmann Publishes, Labella, Dorigo e Deneubourg 2006 LABELLA, T. H.; DORIGO, M.; DENEUBOURG, J.-L. Division of Labor in a Group of Robots Inspired by Ant s Foraging Behavior. ACM Transactions on Autonomous and Adaptive Systems (TAAS), n. 1, p. 4 25, Liang e Haas 2006 LIANG, B.; HAAS, Z. J. Hybrid Routing in Ad Hoc Networks With a Dynamic Virtual Backbone. IEEE Transactions on Wireless Comunications, NS NS-2. The NS Manual. UC Berkeley, LBL, USC/ISI, and Xerox PARC, Disponível em: Acesso em: 22 de novembro de Perkins e Bhagwat 1994 PERKINS, C. E.; BHAGWAT, P. Highly Dynamic Destination- Sequenced Distance-Vector Routing (DSDV) for Mobile Computers. In: ACM SIG- COMM 94 Conference on Communications Architectures, Protocols and Applications. [S.l.: s.n.], p Perkins e Roye 1999 PERKINS, C. E.; ROYE, E. M. Ad hoc On-Demand Distance Vector Routing. Proceedings of the 2nd IEEE Workshop on Mobile Computing Systems and Applications, Przybysz e Júnior 2005 PRZYBYSZ, A. L.; JúNIOR, O. J. L. Infra-estrutura e Roteamento em Redes Wireless Mesh. Pontifícia Universidade Católica do Paraná PUC-PR, QualNet 2011 QualNet. QualNet Simulator, Version 4.0. Scalable Network Technologies, Disponível em: Acesso em: 16 de novembro de Rajagopalan e Shen 2005 RAJAGOPALAN, S.; SHEN, C.-C. ANSI: A unicast routing protocol for mobile ad hoc networks using swarm intelligence. Proceedings of the 2005 International Conference on Artificial Intelligence, ICAI 2005, Ren e Meng 2006 REN, H.; MENG, M. Q.-H. Biologically Inspired Approaches for Wireless Sensor Networks. Conference on Mechatronics and Automation, Proceedings of the 2006 IEEE International, 2006.

102 Referências 87 Roth e Wicker 2003 ROTH, M.; WICKER, S. Termite: Ad-Hoc Networking with Stigmergy. Global Telecommunications Conference, GLOBECOM 03. IEEE, Tanenbaum 2003 TANENBAUM, A. S. Computer Networks. 4. ed. Englewood Cliffs, New Jersey: Prentice Hall PTR, White 1997 WHITE, T. Swarm Intelligence and Problem Solving in Telecommunications. Canadian Artificial Intelligence Magazine, n. 41, p , Spring White, Pagurek e Oppache 1998 WHITE, T.; PAGUREK, B.; OPPACHE, F. Connection Management using Adaptive Mobile Agents. In:. [S.l.: s.n.], Yoshitaka et al YOSHITAKA, O. et al. Scalable and Efficient Ant-Based Routing Algorithm for Ad-Hoc Networks. IEICE Trans Commun, 2006.