Lucas_Dreger___Simulador_VANET___PF2

120 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
120
No SlideShare
0
A partir de incorporações
0
Número de incorporações
5
Ações
Compartilhamentos
0
Downloads
1
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Lucas_Dreger___Simulador_VANET___PF2

  1. 1. Avaliac¸˜ao de Simuladores para Redes Veiculares Ad Hoc para Implementac¸˜ao de Aplicac¸˜oes P2P de Gerenciamento Lucas De Marchi Dreger1 1 Instituto de Inform´atica – Universidade do Vale do Rio dos Sinos – UNISINOS S˜ao Leopoldo – RS – Brazil lucasdreger@gmail.com Abstract. Vehicular ad hoc networks (VANETs) were designed to bring benefits to the driver and passengers of a vehicle both in terms of safety, as well as in- teractivity. These networks are characterized by the high degree of dynamism and constant mobility of its nodes. These characteristics imply, especially in its management, and may hinden the application of traditional management so- lutions. Management systems based on P2P technology (P2P-Based Network Management-P2PBNM) can be an alternative effective management, as it has a decentralised architecture, compatible with the ad hoc architecture. This option, however, needs to be evaluated. Uses tests can be performed through network simulators. The results obtained in a simulator are usually close to the ones found in real experiments. This makes these tools commonly used, to assist in the proposal for improvements in networks as VANETs. That being said, it is possible that the use of P2PBNM applications can bring positive results to VA- NETs simulation. However, the simulators need to be evaluated. Therefore, this paper proposes an evaluation of simulators, with regards to implementation of P2P management applications. Resumo. Redes veiculares ad hoc (Vehicular Ad Hoc Networks - VANET) fo- ram projetadas para trazer benef´ıcios ao motorista e aos passageiros de um ve´ıculo, tanto em termos de seguranc¸a quanto em interatividade. Estas redes s˜ao caracterizadas pelo alto grau de dinamismo e constante mobilidade de seus n´os. Tais caracter´ısticas implicam, principalmente, no seu gerenciamento e po- dem dificultar a aplicac¸˜ao de soluc¸˜oes tradicionais. Sistemas de gerenciamento baseados em tecnologia P2P (P2P-Based Network Management - P2PBNM) podem ser uma alternativa eficaz, pois possuem uma arquitetura descentrali- zada e compat´ıvel com a arquitetura ad hoc. Esta opc¸˜ao, no entanto, precisa ser testada. Testes de aplicac¸˜oes podem ser realizados atrav´es de simuladores de rede. Os resultados obtidos em um simulador s˜ao normalmente similares aos encontrados em experimentos reais. Isto faz com que estas ferramentas se- jam comumente utilizadas, podendo auxiliar na proposta de melhorias em redes como VANETs. Desta forma, ´e poss´ıvel que a utilizac¸˜ao de aplicac¸˜oes P2PBNM traga resultados positivos `a simulac¸˜ao de VANETs. No entanto, conv´em que os simuladores sejam avaliados. Sendo assim, este trabalho prop˜oe uma avaliac¸˜ao de simuladores, com relac¸˜ao `a implementac¸˜ao de aplicac¸˜oes P2P de gerencia- mento.
  2. 2. 1. Introduc¸˜ao Um ve´ıculo em movimento ´e capaz de receber e transmitir informac¸˜oes para outras fon- tes. A comunicac¸˜ao entre os ve´ıculos ´e respons´avel pela formac¸˜ao de diversas redes que se comunicam entre si. Essas redes s˜ao conhecidas como Redes Veiculares (Vehicular Networks – VNs). As VNs podem ser classificadas de acordo com sua estrutura em 3 classes: ad hoc, com infraestrutura ou h´ıbrida. Nas VNs Ad Hoc (Vehicular Ad Hoc Networks - VANET), os ve´ıculos se comunicam apenas entre si, atrav´es de dispositivos internos de comunicac¸˜ao, chamados Onboard Unit (OBU), sem o aux´ılio de uma estrutura f´ısica. VNs com infraestrutura contam com n´os est´aticos em ruas e estradas, conhecidos como Road Side Unit (RSU). Por fim, as VNs h´ıbridas s˜ao uma soluc¸˜ao intermedi´aria entre VANETs e VNs com infraestrutura. A arquitetura h´ıbrida apresenta apenas alguns pontos fixos (i.e., RSU), de forma que nos demais trechos os ve´ıculos se comunicam entre si, at´e que a informac¸˜ao chegue a um ponto estruturado [Alves et al. 2009]. Atualmente, a maior parte das pesquisas sobre VANETs ´e realizada com o aux´ılio de simuladores para este fim. Isto ocorre, entre outros motivos, porque o custo de implementac¸˜ao de VNs reais ´e considerado elevado [Alves et al. 2009]. A realizac¸˜ao de simulac¸˜oes tamb´em traz vantagens, se comparada `a implementac¸˜ao real. Al´em da reduc¸˜ao do custo, podem ser citadas a comodidade na implementac¸˜ao e a reduc¸˜ao do tempo inves- tido. A simulac¸˜ao de VANETs pode ser realizada de diferentes maneiras. No entanto, ´e comum as simulac¸˜oes contarem com a utilizac¸˜ao de dois tipos de simuladores: os simu- ladores de tr´afego e os simuladores de rede. Os simuladores de tr´afego geram o padr˜ao de mobilidade dos n´os (i.e., ve´ıculos) simulados. O simulador de rede ´e respons´avel pela simulac¸˜ao da topologia a partir do padr˜ao de mobilidade importado do simulador de tr´afego [Stanica et al. 2011]. Existem simuladores de tr´afego criados especificamente para simulac¸˜oes envol- vendo VNs (e.g., SUMO, TraNS). J´a os simuladores de rede podem ser utilizados para simular diversos tipos de ambientes. VNs possuem a necessidade de um gerenciamento eficiente, tal como as redes tradicionais. No entanto, as caracter´ısticas dessas redes (e.g., alta mobilidade dos n´os e topologia dinˆamica) oferecem desafios para o gerenciamento efetivo das mesmas. A utilizac¸˜ao de tecnologia Par-a-Par (Peer-to-Peer – P2P) no geren- ciamento de redes, tamb´em conhecida como Gerenciamento de Redes baseado em P2P (P2P-Based Network Management – P2PBNM) pode ser uma alternativa vi´avel para VNs. [Nobre et al. 2013]. Esta alternativa, no entanto, precisa ser avaliada. O presente trabalho prop˜oe uma avaliac¸˜ao de simuladores VANET para implementac¸˜ao de aplicac¸˜oes P2PBNM. Para isso, diferentes simuladores VANET foram utilizados em um ambiente de testes baseado em Linux, a fim de se realizar um estudo de seu funcionamento, bem como uma comparac¸˜ao de suas func¸˜oes. Ap´os a criac¸˜ao das simulac¸˜oes, realizou-se a implementac¸˜ao de uma aplicac¸˜ao P2PBNM. Sendo assim, conv´em que os simuladores sejam avaliados em relac¸˜ao `as aplicac¸˜oes P2PBNM imple- mentadas. Diversas m´etricas podem ser utilizadas para essa avaliac¸˜ao. Dessa forma, a investigac¸˜ao tamb´em se concentrou na definic¸˜ao de m´etricas significativas considerando as aplicac¸˜oes P2PBNM mais comuns. `A medida que VANETs vˆem se tornando um assunto de grande procura, novas
  3. 3. soluc¸˜oes tendem a ser testadas e implementadas. Dado o fato que grande parte dos testes s˜ao realizado atrav´es de simuladores, este trabalho visa oferecer uma introduc¸˜ao sobre o assunto e um suporte na escolha dos simuladores para trabalhos futuros. Este trabalho est´a organizado da seguinte maneira. Na sec¸˜ao 2 ´e apresentada uma revis˜ao te´orica sobre VNs e seus diferentes tipos de simuladores. A sec¸˜ao 3 caracteriza as diferentes abordagens de gerenciamento de VANETs. Nas sec¸˜oes 4 e 5 ser´a descrito como se deu a escolha dos simuladores, bem como as atividades pr´aticas realizadas. Por fim, a avaliac¸˜ao dos resultados ´e apresentada na sec¸˜ao 6. 2. Fundamentac¸˜ao Te´orica Rede veicular (Vehicular Network – VN) ´e uma tecnologia emergente que visa integrar as capacidades de redes sem fio de nova gerac¸˜ao com ve´ıculos inteligentes [Wang 2012]. Seu objetivo, portanto, ´e facilitar a troca de informac¸˜ao entre ve´ıculos ou entre ve´ıculo e infraestrutura (ponto de acesso). Estas informac¸˜oes s˜ao classificadas e utilizadas a fim de se estabelecer um Sistema Inteligente de Transporte (Intelligent Transportation System – ITS). O ITS possui uma s´erie de aplicac¸˜oes, onde as mensagens trocadas entre os ve´ıculos podem ser categorizadas como informac¸˜oes de tr´afego e seguranc¸a e como informac¸˜oes de interatividade. Como exemplos de informac¸˜oes de tr´afego e seguranc¸a, podemos citar o monitoramento de tr´afego cooperativo, aux´ılio em cruzamentos, controle de congestio- namento, prevenc¸˜ao de colis˜oes e desvio de rotas em tempo real [Alves et al. 2009]. Na categoria de interatividade est˜ao o acesso `a Internet e a troca de arquivos entre ve´ıculos. 2.1. Classificac¸˜ao de Redes Veiculares VNs podem ser divididas em trˆes tipos de arquitetura, de acordo com sua utilizac¸˜ao: ad hoc, com infraestrutura e h´ıbrida [Alves et al. 2009]. A seguir ser˜ao descritas as carac- ter´ısticas estruturais de cada uma delas. 2.1.1. Ad Hoc Redes ad hoc, de uma maneira geral, s˜ao redes em que n˜ao h´a um ponto central res- pons´avel pelo roteamento de informac¸˜oes. Desta forma, cada n´o da rede se transforma em um roteador dinˆamico, estando respons´avel por encaminhar informac¸˜oes de n´os pr´oximos a outros n´os fora de sua ´area de alcance [Dias et al. 2010]. ´E poss´ıvel aplicar o conceito ad hoc em redes veiculares, onde cada n´o da rede ´e caracterizado por um ve´ıculo. Este utilizar´a mensagens multicast e broadcast para trans- mitir informac¸˜oes para ve´ıculos pr´oximos [Zeadally et al. 2012]. Sua comunicac¸˜ao ´e re- alizada atrav´es de dispositivos chamados Onboard Unit (OBU), localizados no interior de cada ve´ıculo. A Figura 1 caracteriza este conceito. No exemplo, um ve´ıculo envia informac¸˜oes de um evento (e.g., colis˜ao, desvio de rota) ao ve´ıculo mais pr´oximo. Este enviar´a a informac¸˜ao ao pr´oximo ve´ıculo e, assim, sucessivamente, at´e que todos recebam a informac¸˜ao.
  4. 4. Figura 1. Roteamento ad hoc em redes veiculares 2.1.2. Com infraestrutura Redes veiculares com infraestrutura, tamb´em conhecidas como Vehicle-to-Roadside (V2R) ou Vehicle-to-Infrastructure (V2I), s˜ao caracterizadas pela presenc¸a de terminais centralizadores (pontos de acesso), os quais s˜ao respons´aveis pelo roteamento de men- sagens [Dias et al. 2010]. Estes terminais s˜ao tamb´em conhecidos como Roadside Unit (RSU) e localizam-se nas calc¸adas e acostamentos. Diferentemente da comunicac¸˜ao ad hoc, a comunicac¸˜ao com infraestrutura ´e caracterizada por um salto ´unico (single hop) de distˆancia entre o ve´ıculo e o RSU. O RSU utilizar´a mensagens broadcast que ser˜ao distribu´ıdas aos demais ve´ıculos ao seu alcance [Zeadally et al. 2012]. A Figura 2 representa a rede com infraestrutura. Nela ´e poss´ıvel perceber que a comunicac¸˜ao n˜ao ocorre mais entre os ve´ıculos, e sim diretamente ao ponto de acesso. Estes, idealmente localizados a cada quilˆometro, podem agir de forma dinˆamica, por exemplo alterando limites de velocidade. Atrav´es de informac¸˜oes como a condic¸˜ao do tr´afego e o hor´ario, o RSU determina o limite de velocidade dinamicamente, e envia uma mensagem broadcast de informac¸˜ao aos ve´ıculos. O monitoramento se d´a atrav´es de uma comparac¸˜ao entre os dados obtidos dos ve´ıculos e as informac¸˜oes geogr´aficas do mo- mento. Caso algum ve´ıculo ultrapasse o limite de velocidade, receber´a um alerta enviado pelo RSU [Zeadally et al. 2012]. 2.1.3. H´ıbrida A arquitetura h´ıbrida ´e uma soluc¸˜ao intermedi´aria entre a rede ad hoc e com infraestrutura. Nesta, utiliza-se uma infraestrutura m´ınima, de forma a aumentar a conectividade entre ve´ıculos. Por´em, grande parte da comunicac¸˜ao ´e feita atrav´es de m´ultiplos saltos entre ve´ıculos [Alves et al. 2009]
  5. 5. Figura 2. Comunicac¸ ˜ao em redes V2I Dificilmente todas as vias estar˜ao cobertas por pontos de acesso (RSUs). Desta forma, a arquitetura h´ıbrida torna-se a opc¸˜ao de melhor custo-benef´ıcio para o tr´afego inteligente. ´E poss´ıvel ter, por exemplo, RSUs localizados em vias de maior concentrac¸˜ao de ve´ıculos, utilizando roteamento ad hoc em locais onde a concentrac¸˜ao de autom´oveis ´e baixa. A utilizac¸˜ao de simuladores VANET pode ajudar a definir as melhores topologias. 2.2. Simuladores VANET A realizac¸˜ao de testes de desempenho em VNs pode se tornar invi´avel por exigir um grande n´umero de pessoas, condic¸˜oes clim´aticas favor´aveis e possuir custos elevados. Pode, ainda, tornar dif´ıcil a repetic¸˜ao de um experimento com muitas vari´aveis. Como consequˆencia, em muitos casos recomenda-se a utilizac¸˜ao de simuladores de redes para a realizac¸˜ao de testes e avaliac¸˜oes. Embora a utilizac¸˜ao de simuladores traga mais fa- cilidade e utilize menos recursos, deve-se observar que seus resultados servem apenas como indicativos de soluc¸˜ao, podendo divergir dos resultados reais de uma rede veicular [Alves et al. 2009]. A realizac¸˜ao de simulac¸˜oes de redes veiculares conta, inicialmente, com duas clas- ses de simuladores: simuladores de tr´afego e simuladores de rede. Simuladores de tr´afego s˜ao criados exclusivamente para simulac¸˜oes envolvendo VANETs, sendo respons´aveis pela criac¸˜ao de um modelo de mobilidade entre os n´os da rede. Este modelo de mo- bilidade ´e importado no simulador da rede, respons´avel por simular os protocolos de comunicac¸˜ao a serem utilizados. Para que o simulador da rede possa realizar os experi- mentos propostos, ´e necess´ario que ele possua compatibilidade com o arquivo resultante do simulador de tr´afego, tamb´em conhecido como trace, o que nem sempre ocorre. Desta forma, muitas vezes ´e utilizado um arquivo trace de mobilidade randˆomica, normalmente melhor aceito em simuladores de rede. Simuladores de tr´afego podem divergir sobre algumas caracter´ısticas. Duas im- portantes caracter´ısticas que podem ser verificadas em simuladores s˜ao o modelo de mo-
  6. 6. bilidade aplicado, e os diferentes tipos de customizac¸˜oes dispon´ıveis. O modelo de mo- bilidade est´a dividido em Macrosc´opico e Microsc´opico. Sua diferenc¸a principal est´a no n´ıvel de detalhe aplicado. O modelo macrosc´opico n˜ao trata cada ve´ıculo individualmente na simulac¸˜ao. O modelo microsc´opico possui um n´ıvel de detalhe consideravelmente maior, tratando cada ve´ıculo de forma individual. Desta forma o comportamento de cada ve´ıculo depende de diferentes quest˜oes (e.g., comportamento dos ve´ıculos pr´oximos e caracter´ısticas do motorista) [Stanica et al. 2011]. A implementac¸˜ao realizada neste trabalho concentrou-se em dois simuladores di- ferentes: O Network Simulator 3 (NS-3) e o Common Open Research Emulator (CORE). As caracter´ısticas observadas em ambas as ferramentas foram decisivas na escolha das mesmas. Detalhes sobre os simuladores poder˜ao ser visualizados na sec¸˜ao 4. 3. Gerenciamento de VANETs O gerenciamento de uma rede veicular passa pela sua arquitetura de comunicac¸˜ao. Em 2004, iniciou-se a padronizac¸˜ao da comunicac¸˜ao em VNs pelo IEEE. O padr˜ao criado ainda est´a em fase de desenvolvimento, e ´e conhecido como IEEE 802.11p WAVE. A arquitetura WAVE (Wireless Access in the Vehicular Environment), possui importantes informac¸˜oes sobre a comunicac¸˜ao entre ve´ıculos (e.g., frequˆencias utiliza- das na comunicac¸˜ao). Esta arquitetura trabalha com uma nova pilha de protocolos de comunicac¸˜ao, baseada no protocolo Wave Short Message Protocol (WSMP). Mensagens WSMP s˜ao normalmente mais utilizadas em VANETs. Isto ocorre pelo fato de terem sido criadas especificamente para este tipo de rede, podendo trazer benef´ıcios para esta comunicac¸˜ao. A arquitetura WAVE, no entanto, suporta tamb´em o envio de datagramas IP [Alves et al. 2009]. Com relac¸˜ao a sua estrutura, VANETs s˜ao conhecidas como uma subclasse das redes m´oveis ad hoc (Mobile Ad Hoc Networks - MANET). MANETs n˜ao possuem in- fraestrutura fixa, portanto atribuem aos n´os a tarefa de roteamento de informac¸˜oes. VA- NETs possuem a mesma caracter´ıstica, no entanto possuem outras particularidades n˜ao vistas em MANETs [Yousefi et al. 2006]. As particularidades encontradas em VANETs, como a necessidade dos ve´ıculos seguirem uma determinada rota (e.g., estrada), somadas `as caracter´ısticas de redes m´oveis ad hoc (e.g., alto grau de descentralizac¸˜ao) representam grandes dificuldades ao gerenciamento destas redes [Blum et al. 2004]. VANETs s˜ao caracterizadas pela grande mobilidade e o alto dinamismo dos n´os. Dado o fato de que os ve´ıculos trafegam em alta velocidade em rodovias, ´e importante que eles possam se comunicar em tempo real. Caso ocorra uma situac¸˜ao de emergˆencia, todos os ve´ıculos afetados poder˜ao ser informados sobre o evento. Outro desafio encontrado em VANETs ´e o alto n´umero de n´os. Em ´areas metropolitanas, o n´umero de ve´ıculos que trafega em um dado hor´ario pode chegar a ordem de milh˜oes, o que pode significar um congestionamento na rede. O fato de grande parte das mensagens entre ve´ıculos ocorrer em forma de broadcast contribui para a ocorrˆencia deste problema [Zhang 2012]. A importˆancia destas redes, somada as suas caracter´ısticas e particularidades, gera um aumento na busca de formas de um gerenciamento efetivo. 3.1. Abordagens de gerenciamento e roteamento de VANETs As caracter´ısticas encontradas em VANETs fazem com que diferentes ferramentas e pro- tocolos sejam criados, a fim de auxiliar seu gerenciamento. Os protocolos podem ser clas-
  7. 7. sificados da seguinte maneira: oportun´ısticos, geogr´aficos, topol´ogicos e de disseminac¸˜ao de informac¸˜oes [Alves et al. 2009]. Protocolos oportun´ısticos s˜ao normalmente adotados em Redes Tolerantes a Atra- sos (Delay Tolerant Networks – DTN). DTNs s˜ao caracterizadas pelos longos atrasos e frequentes disconex˜oes de seus n´os [Oliveira et al. 2007]. VANETs podem ser vistas como um tipo de DTN, pois podem existir frequentes interrupc¸˜oes na comunicac¸˜ao e constantes desconex˜oes de seus n´os. Portanto, existe uma incerteza se a mensagem envi- ada por um n´o conseguir´a atingir seu destino final [Alves et al. 2009]. O Vehicle-Assisted Data Delivery (VADD) ´e um exemplo de protocolo opor- tun´ıstico, criado com vista na melhoria do sistema de comunicac¸˜ao entre ve´ıculos. O VADD utiliza o conceito de encaminhamento de mensagens store-and-forward. O store- and-forward ´e comumente utilizado em DTNs [Warthman 2003], e pode ser visualizado na figura 3. Neste m´etodo, a mensagem ´e recebida integralmente e armazenada por um n´o. No momento em que houver conectividade, este n´o enviar´a a mensagem para outro, que pode ou n˜ao ser o destino final. Sendo assim, n˜ao ´e necess´ario que o n´o destino esteja ativo quando o n´o de origem envia uma mensagem [Oliveira et al. 2007]. A operac¸˜ao do VADD depende da posic¸˜ao do ve´ıculo que carrega uma mensagem e do sentido que a men- sagem dever´a obter para chegar ao seu destino. Desta forma, a mensagem ser´a entregue aos ve´ıculos que se locomovem em direc¸˜ao ao ve´ıculo destino [Zhao and Cao 2008]. No entanto, mesmo com a implantac¸˜ao do protocolo, mensagens importantes podem demorar para chegar aos seus destinos. Figura 3. Encaminhamento store-and-forward. Adaptado de [Warthman 2003] Protocolos geogr´aficos s˜ao projetados para prover escalabilidade em ambientes de alta velocidade. Algoritmos de roteamento geogr´afico normalmente utilizam algum sistema de localizac¸˜ao (e.g., GPS). O Greedly Perimeter Stateless Routing (GPSR) ´e um exemplo de protocolo geogr´afico. Para o encaminhamento de mensagens, o GPSR utiliza um algoritmo chamado greedy forwarding. A utilizac¸˜ao do greedy forwarding faz com que os n´os da rede enviem seus pacotes somente aos n´os mais pr´oximos de seu destino, evitando mensagens broadcast e duplicidade de pacotes. Este algoritmo s´o poder´a ser executado, no entanto, se cada n´o estiver ciente tanto de sua localizac¸˜ao, quanto de seus vizinhos [Karp and Kung 2000]. A figura 4 representa o roteamento obtido pelo algoritmo greedy forwarding. Nela ´e poss´ıvel perceber que o n´o A deseja enviar uma mensagem para o n´o C. Para isso, o n´o A transmite a mensagem para o n´o B, mesmo que existam n´os mais pr´oximos de A. Isto ocorre pois o n´o B ´e o mais pr´oximo de C, dentro da ´area de alcance de A. Desta forma o encaminhamento de mensagens ´e otimizado. Protocolos de roteamento baseados em topologia utilizam m´etricas para calcular
  8. 8. Figura 4. Funcionamento do algoritmo greedy forwarding o melhor caminho de transmiss˜ao de um pacote desde sua origem at´e seu destino. Tipi- camente, estas m´etricas est˜ao diretamente relacionadas ao menor custo de transmiss˜ao. Protocolos topol´ogicos podem ser divididos em proativos, reativos e h´ıbridos. Os proto- colos proativos mant´em uma lista de rotas dos n´os da rede. Esta lista ´e periodicamente atualizada atrav´es de mensagens broadcast. Os protocolos reativos, por outro lado, criam uma rota de transporte somente quando h´a necessidade de envio de dados. Por fim, os protocolos h´ıbridos s˜ao tidos como uma soluc¸˜ao intermedi´aria, por exemplo, atualizando as rotas mais utilizadas sob demanda [Alves et al. 2009]. Existem protocolos baseados em topologia criados para MANETs. No entanto, a utilizac¸˜ao destes protocolos em redes veiculares pode impactar em diversos problemas. Atrav´es de pesquisas [Naumov et al. 2006] identificou-se que 70 a 95% do tr´afego ge- rado por um protocolo topol´ogico para MANETs ´e dedicado `a difus˜ao de mensagens de requisic¸˜ao de rotas, quando aplicado a redes veiculares. O protocolo em quest˜ao chama-se Ad hoc On-Demand Distance Vector (AODV). A fim de reduzir este problema, mecanis- mos de difus˜ao espec´ıficos para VANETs comec¸aram a ser desenvolvidos, de forma a diminuir o n´umero de mensagens de difus˜ao [Alves et al. 2009]. Os protocolos de disseminac¸˜ao de informac¸˜oes diferenciam-se dos demais citados em uma quest˜ao b´asica. Protocolos topol´ogicos, geogr´aficos e oportun´ısticos concentram- se no c´alculo de rotas unicast. Os protocolos de disseminac¸˜ao, por sua vez, s˜ao normal- mente utilizados para aux´ılio ao motorista sobre as condic¸˜oes da via em determinada regi˜ao. Sendo assim, grande parte dos protocolos s˜ao criados para transmiss˜ao de uma mesma informac¸˜ao para diversos n´os. Portanto n˜ao se utiliza a transmiss˜ao ponto-a-ponto, presente nos demais protocolos. O Urban Multi-hop Broadcast (UMB) e o Segment- Oriented Data Abstraction and Dissemination (SODAD) s˜ao exemplos de protocolos de disseminac¸˜ao de informac¸˜oes [Alves et al. 2009]. Diversos protocolos de roteamento s˜ao criados e estudados a fim de se obter uma soluc¸˜ao funcional para a comunicac¸˜ao de VANETs. Uma vez que os n´os de uma VANET
  9. 9. possam se comunicar sem que haja problemas no roteamento de mensagens, ´e necess´ario que se obtenha um gerenciamento efetivo dos ve´ıculos que trafegam na rede. Atualmente, pode ser poss´ıvel a aplicac¸˜ao dos modelos pull e push em VANETs. Tais abordagens tamb´em s˜ao comuns nas DTNs de um modo geral [Bertinatto 2012]. O modelo pull ´e baseado no paradigma SNMP request/response. Neste modelo, a entidade de gerenciamento envia uma requisic¸˜ao `as unidades gerenciadas (i.e., ve´ıculos) que, por sua vez, respondem com a informac¸˜ao solicitada. J´a o modelo push ´e baseado na pr´atica de publish/subscribe. Ou seja, a unidade de gerenciamento ´e chamada subs- criber, enquanto a unidade gerenciada ´e conhecida por provider. Para que o gerencia- mento acontec¸a, ´e necess´ario que o subscriber realize um cadastro no provider, de forma a indicar quais informac¸˜oes deseja receber. Ent˜ao, o provider enviar´a as informac¸˜oes solicitadas mediante requisic¸˜ao ou acontecimento pr´e-definido. O modelo pull geral- mente requer uma latˆencia baixa para as operac¸˜oes de request/response. Sendo assim, o modelo push tende a ser melhor aplicado no gerenciamento de redes como alta latˆencia [Bertinatto 2012]. Paralelo a isso, novas abordagens s˜ao estudadas para o gerenciamento de VANETs. A utilizac¸˜ao de tecnologia P2P pode trazer resultados positivos neste tipo de rede. 3.2. Gerenciamento de VANETs atrav´es de sistemas de gerenciamento P2P Sistemas Par-a-Par (peer-to-peer – P2P) s˜ao caracterizados por possu´ırem uma arqui- tetura distribu´ıda, onde n˜ao se faz necess´aria a utilizac¸˜ao de um ponto central de ge- renciamento. A arquitetura P2P ´e conhecida por sua escalabilidade, tolerˆancia a falhas e auto-organizac¸˜ao [Androutsellis-Theotokis and Spinellis 2004]. Ainda que tenham fi- cado popularizadas pelo compartilhamento de arquivos, aplicac¸˜oes baseadas em P2P po- dem possuir as mais diversas finalidades. Aplicac¸˜oes VoIP (Voice over IP) (e.g., Skype) e compartilhamento de recursos computacionais (e.g., SETI@home) s˜ao alguns exemplos que podem ser citados [Panisson et al. 2006]. Mesmo utilizando um meio f´ısico, redes P2P s˜ao sobrepostas a outras redes, como por exemplo a Internet. Seu modelo de comunicac¸˜ao foi constru´ıdo sobre protocolos de Internet, o que possibilita que os mais diversos tipos de sistemas estejam aptos a se comunicarem. Isto torna poss´ıvel a construc¸˜ao de ambientes dinˆamicos e vers´ateis, e faz com que problemas comumente encontrados nestas redes sejam minimizados, como por exemplo dificuldades de gerenciamento [Panisson et al. 2006]. O gerenciamento de rede baseado em P2P (P2P-Based Network Management – P2PBNM) surgiu a fim de integrar modelos de gerenciamento de redes tradicionais com os novos servic¸os introduzidos pelas redes P2P. O P2PBNM ´e composto por trˆes entida- des: o top-level manager (TLM), o mid-level manager (MLM) e o Agente. O TLM ´e respons´avel pelas tarefas de gerenciamento de outros peers, atrav´es de interac¸˜oes huma- nas. O MLM opera atrav´es de instruc¸˜oes do TLM ou de outros MLMs, sem interac¸˜ao humana. O Agente ´e uma aplicac¸˜ao respons´avel por modificar (caso requisitado) ou re- portar (espontaneamente) o estado dos dispositivos gerenciados [Granville et al. 2005]. Sistemas P2PBNM possuem um alto grau de descentralizac¸˜ao em tarefas de ge- renciamento. Desta forma, os pr´oprios pares de gerenciamento s˜ao respons´aveis por pro- verem os recursos necess´arios para tais tarefas. Tamb´em devido a esta descentralizac¸˜ao, o uso de informac¸˜oes locais para a tomada de decis˜oes aumenta, o que promove a auto-
  10. 10. nomia dos pares de gerenciamento [Nobre et al. 2013]. Outra caracter´ıstica presente nos pares de gerenciamento ´e a de possu´ırem um papel duplo, operando n˜ao somente como pares de gerenciamento, mas tamb´em participando da comunicac¸˜ao entre os demais peers [Granville et al. 2005]. Nos sistemas P2PBNM os n´os s˜ao divididos em grupos, de acordo com o servic¸o de gerenciamento oferecido. Isto aumenta a disponibilidade dos servic¸os oferecidos, uma vez que os componentes de gerenciamento poder˜ao ser replicados entre os n´os do grupo. Ainda, enquanto houverem n´os dispon´ıveis no grupo, o servic¸o oferecido continuar´a dispon´ıvel. Os n´os, por´em, podem participar de diversos grupos. Esta organizac¸˜ao ´e realizada sem interac¸˜ao humana, e depende apenas do servic¸o ofertado pelo n´o [Duarte et al. 2011]. A figura 5 ilustra uma vis˜ao geral de sistemas P2PBNM. Figura 5. Vis˜ao geral de sistemas P2PBNM [Duarte et al. 2011] Redes P2P possuem caracter´ısticas que podem ser ´uteis ao gerenciamento de DTNs como VANETs. Dois benef´ıcios proporcionados por este tipo de rede s˜ao a utilizac¸˜ao de grupos de peers para execuc¸˜ao de tarefas de gerenciamento e a melhoria de conectividade para troca de informac¸˜oes de gerenciamento [Bertinatto 2012]. A utilizac¸˜ao de grupos de peers para o gerenciamento destas redes est´a ligada tanto ao desempenho, quanto a redundˆancia do servic¸o oferecido. Caso um par de gerencia- mento opere individualmente e tenha sua conex˜ao interrompida, o servic¸o oferecido por ele ficar´a indispon´ıvel. Se utilizados grupos de peers, diversos pares ser˜ao respons´aveis pela tarefa de gerenciamento, portanto este servic¸o somente ficar´a indispon´ıvel se todos
  11. 11. os pares respons´aveis ficarem inativos. Da mesma forma, os recursos computacionais de cada um podem ser compartilhados de forma a aumentar o desempenho do servic¸o oferecido [Granville et al. 2005]. A melhoria de conectividade para troca de informac¸˜oes de gerenciamento ´e tido como outra grande vantagem devido ao fato do servic¸o de roteamento de mensagens das redes P2P ser mais flex´ıvel que o implementado em redes TCP/IP. Desta forma, diferen- temente das redes tradicionais, os sistemas P2P podem selecionar mais de uma rota para comunicac¸˜ao entre dois peers. Al´em disso, tais rotas podem ser determinadas a partir de crit´erios (e.g., poder computacional dos peers, espac¸o dispon´ıvel para armazenamento) [Granville et al. 2005]. As caracter´ısticas de gerenciamento encontradas em redes P2P podem ser muito ´uteis se aplicadas em redes onde a mobilidade dos n´os ´e alta e constante, como ´e o caso de VANETs. A utilizac¸˜ao de sistemas P2PBNM pode ser uma alternativa vi´avel para seu gerenciamento efetivo. Este tipo de gerenciamento pode ser testado utilizando-se simuladores VANETs juntamente com aplicac¸˜oes P2P, a fim de se obter um ambiente funcional e de baixo custo. 4. Escolha dos simuladores VANET O presente trabalho contou com a utilizac¸˜ao de dois simuladores: O NS-3 e o CORE. Am- bas as ferramentas s˜ao caracterizadas como simuladores de rede, ou seja, s˜ao capazes de simular os mais diversos tipos de redes. Desta forma, foram adicionados modelos de mo- bilidade aos n´os da simulac¸˜ao, de forma a aproximar-se do funcionamento de VANETs. Algumas premissas foram levadas em considerac¸˜ao para a escolha dos simulado- res. Essas premissas basearam-se nas func¸˜oes principais do simulador e na maneira de gerenciamento dos n´os. Da mesma forma, alguns simuladores foram descartados por n˜ao apresentarem os recursos necess´arios para a execuc¸˜ao deste trabalho. A seguir ser˜ao citadas as principais caracter´ısticas dos simuladores trabalhados. 4.1. NS-3 O Network Simulator 3 (NS-31 ) ´e, atualmente, uma das ferramentas mais completas para simulac¸˜oes de rede [Rampfl 2013]. Ele pode ser instalado em sistemas UNIX em geral e foi escrito em linguagem C++ e Python. O simulador n˜ao possui suporte nativo a sistemas Windows, por´em pode ser instalado atrav´es do cygwin2 . Sua instalac¸˜ao e configurac¸˜ao ´e realizada atrav´es do Waf3 , uma ferramenta Python de construc¸˜ao de aplicac¸˜oes. Portanto, o Waf dever´a estar previamente instalado no sistema. A arquitetura do NS-3 ´e composta por cinco abstrac¸˜oes: n´o, aplicac¸˜ao, canal de comunicac¸˜ao, dispositivo de rede e assistente de topologia. O n´o (classe Node) ´e tratado como o host, ou computador onde se adicionam funcionalidades (e.g., aplicac¸˜oes, pilhas de protocolos). A classe de aplicac¸˜ao (Application) ´e usada para criar novas aplicac¸˜oes en- tre os n´os. Um exemplo de aplicac¸˜ao ´e uma simples troca de pacotes ICMP entre dois n´os. O canal de comunicac¸˜ao (classe Channel) comp˜oe o meio f´ısico utilizado na simulac¸˜ao. 1 https://www.nsnam.org/ 2 http://www.cygwin.com/ 3 https://code.google.com/p/waf/
  12. 12. Dois dos tipos de canal mais utilizados s˜ao o ponto-a-ponto (PointToPointChannel) e sem fio (WifiChannel). No entanto, eles podem ser customizados, a fim de se obter um ambiente mais completo. Para que os n´os possam se comunicar atrav´es dos canais de comunicac¸˜ao, ´e necess´ario que possuam interfaces de rede, capazes de se conectarem aos canais. Estas interfaces s˜ao caracterizadas pela classe Net Device e s˜ao comumente conhe- cidas como Network Interface Card (NIC). Por fim, os assistentes de topologia (Topology Helpers) auxiliam em quest˜oes rotineiras, como a atribuic¸˜ao de enderec¸os IP e MAC e configurac¸˜ao de pilhas de protocolos. Os assistentes de topologia s˜ao muito ´uteis `a me- dida que a quantidade de n´os da simulac¸˜ao aumenta. Caso contr´ario, estas configurac¸˜oes deveriam ser realizadas separadamente para cada n´o. A figura 6 caracteriza a arquitetura do NS-3. Figura 6. Arquitetura do NS-3 O NS-3 n˜ao possui interface gr´afica para criac¸˜ao de simulac¸˜oes. No entanto, ap´os a criac¸˜ao de scripts, pode-se fazer uso do NetAnim4 para melhor visualizar as simulac¸˜oes criadas. O NetAnim ´e um software auxiliar ao NS-3, que provˆe um melhor entendimento da topologia simulada atrav´es de um ambiente gr´afico. Sua instalac¸˜ao ´e realizada em poucos passos, e sua configurac¸˜ao ´e relativamente f´acil. No entanto, ´e necess´ario que o arquivo fonte de cada simulac¸˜ao seja editado para que se adicione o m´odulo e func¸˜oes NetAnim. Ap´os a modificac¸˜ao dos arquivos, uma vez que s˜ao executados, resultam em um arquivo XML de sa´ıda. O arquivo XML, por sua vez, pode ser importado no NetAnim a fim de se visualizar a simulac¸˜ao. Alguns simuladores habilitam os n´os da simulac¸˜ao a executar diferentes tipos de sistemas. Isto ´e feito para o caso de testes de aplicac¸˜oes entre os n´os, e normalmente ´e realizado atrav´es de emulac¸˜oes de outros sistemas Linux. O NS-3, se instalado em sua forma padr˜ao, n˜ao possui suporte a emulac¸˜oes em seus n´os. No entanto, existem algumas 4 http://www.nsnam.org/wiki/NetAnim
  13. 13. abordagens utilizadas para este fim. As duas maneiras mais conhecidas s˜ao a utilizac¸˜ao de Linux Containers (LXC) e Direct Code Execution (DCE). LXC ´e utilizado para a criac¸˜ao de t´uneis entre dois ou mais hosts. Estes t´uneis podem operar de duas maneiras. A primeira cria um t´unel entre equipamentos totalmente distintos. A segunda pode criar diferentes pilhas de rede na mesma m´aquina, de forma a emular diferentes ambientes dentro de um mesmo sistema, atrav´es da virtualizac¸˜ao do kernel. Portanto, o LXC pode ser ´util se utilizado em simulac¸˜oes do NS-3, de forma que cada n´o simulado represente um container diferente na ferramenta. A utilizac¸˜ao desta ferramenta, no entanto, limita-se `a quantidade de n´os simulados. Caso a simulac¸˜ao con- tenha muitos n´os, a implementac¸˜ao de t´uneis e containers pode adquirir um elevado grau de complexidade, devido aos recursos computacionais que devem ser dedicados para este fim. A figura 7 ilustra a arquitetura LXC. ´E poss´ıvel perceber que diferentes n´ıveis s˜ao uti- lizados em sua arquitetura, compreendendo desde a camada f´ısica do sistema operacional, at´e a aplicac¸˜ao iniciada dentro do n´o NS-3. Figura 7. Arquitetura LXC [Dowell 2010] O DCE ´e um m´odulo para o NS-3 que provˆe a implementac¸˜ao de protocolos de rede e aplicac¸˜oes, sem que seja necess´ario alterar seu c´odigo fonte [?]. Por exemplo, O NS-3 provˆe uma aplicac¸˜ao de tr´afego ICMP baseada em ping, chamada V4PingHelper. Atrav´es da utilizac¸˜ao do DCE, ´e poss´ıvel executar a aplicac¸˜ao ping real. De uma maneira geral, o DCE ´e suportado pelas vers˜oes mais recentes de Linux Ubuntu e Fedora. No
  14. 14. entanto, pode apresentar restric¸˜oes com outras distribuic¸˜oes. Os scripts criados no NS-3 podem incluir diversos tipos de mobilidade vincu- lados aos seus n´os. O NS-3 possui, nativamente, uma s´erie de padr˜oes de mobilidade que podem ser utilizados na simulac¸˜ao. Alternativamente, pode-se importar arquivos de mobilidade gerados por diferentes aplicac¸˜oes. As simulac¸˜oes implementadas contaram com um padr˜ao aleat´orio de mobilidade j´a implementado no NS-3, conhecido como Ran- domWalk2dMobilityModel [Chiang and Shenoy 2004]. Por fim, uma caracter´ıstica marcante relacionada ao NS-3 ´e o suporte. Em sua p´agina oficial, ´e poss´ıvel encontrar diversos manuais, v´ıdeo-aulas e documentac¸˜oes cen- tralizadas na plataforma Doxygen5 . Tamb´em nesta p´agina, ´e poss´ıvel enviar d´uvidas e solicitac¸˜oes de suporte. Por´em, recomenda-se que o usu´ario do sistema recorra preferen- cialmente `as documentac¸˜oes e ao grupo de discuss˜oes6 . No in´ıcio das simulac¸˜oes com o NS-3, verificou-se a importˆancia de ferramen- tas como o LXC e DCE para a execuc¸˜ao de aplicac¸˜oes entre os n´os simulados. Para a simulac¸˜ao de VANETs, foram utilizados m´odulos de redes sem fio tradicionais. No entanto, espera-se o desenvolvimento de novos projetos de criac¸˜oes de protocolos es- pec´ıficos para a comunicac¸˜ao entre ve´ıculos no simulador. A medida em que novas vers˜oes s˜ao criadas, a simulac¸˜ao de VANETs tende a ganhar topologias e protocolos es- pec´ıficos para este tipo de simulac¸˜ao. A figura 8 indica o ambiente de simulac¸˜ao do NS-3. ´E poss´ıvel perceber que a simulac¸˜ao ´e realizada atrav´es de comandos no terminal. A simulac¸˜ao apresentada abaixo ´e iniciada atrav´es de um script de exemplo do NS-3. Como pode ser visualizado, trata-se de uma arquitetura cliente-servidor, onde s˜ao trocados dois pacotes de dados. Figura 8. Simulac¸ ˜ao do NS-3 4.2. CORE O Common Open Research Emulator (CORE7 ) [Ahrenholz 2010] ´e tamb´em conhecido como um simulador de redes. Sua arquitetura divide-se em dois componentes principais: 5 https://www.nsnam.org/docs/doxygen/ 6 https://groups.google.com/forum/#!forum/ns-3-users 7 http://www.nrl.navy.mil/itd/ncs/products/core
  15. 15. o CORE daemon (backend) e o CORE GUI (frontend). A denominac¸˜ao backend indica o n´ucleo da aplicac¸˜ao, enquanto o frontend ´e a parte da aplicac¸˜ao que ter´a mais interac¸˜ao de seu usu´ario. No caso do CORE, o backend ´e representado pelo deamon, respons´avel pela comunicac¸˜ao dos componentes simulados. O frontend simboliza a interface gr´afica do sistema, em que o usu´ario ter´a maior proximidade. A figura 9 representa a arquitetura do CORE. ´E poss´ıvel visualizar a comunicac¸˜ao de seus dois principais componentes, bem como a comunicac¸˜ao de componentes adicionais com a camada virtualizada de cada n´o. Figura 9. Arquitetura do CORE [Ahrenholz 2013] O CORE ´e conhecido por ser um emulador. Ou seja, ele ´e capaz de realizar uma representac¸˜ao de redes de computadores como se cada computador fosse uma instˆancia real. Sendo assim, o CORE n˜ao utiliza abstrac¸˜oes encontradas no NS-3 para simulac¸˜oes. A virtualizac¸˜ao do kernel, ou implementac¸˜ao LXC, possibilita que cada n´o da rede seja uma instˆancia virtual Linux, de forma que cada instˆancia possua uma pilha de protocolos de rede independente (i.e., diferente da m´aquina original). Para a realizac¸˜ao deste traba- lho, esta caracter´ıstica teve grande importˆancia para a escolha do simulador. Consequen- temente, tamb´em facilitou a execuc¸˜ao de aplicac¸˜oes P2PBNM entre os n´os simulados. ´E motivo de destaque a quantidade de ferramentas adicionais que o CORE pode utilizar na simulac¸˜ao. As ferramentas reais de captura de tr´afego (i.e., Wireshark, TShark, Tcpdump) s˜ao as mais comuns. No entanto, existem implementac¸˜oes para teste de co- nectividade entre os n´os, e at´e mesmo diferentes tipos de shell, que podem ser usados na execuc¸˜ao de comandos nas instˆancias virtuais. Existe tamb´em uma opc¸˜ao onde ´e poss´ıvel visualizar os logs de sistema apresentados pelos n´os. Esta opc¸˜ao ´e importante para soluc¸˜ao de poss´ıveis problemas. O CORE n˜ao possui suporte a simulac¸˜oes espec´ıficas sobre VANET. Desta forma, foram utilizadas redes sem fio, adicionando-se padr˜oes de mobilidade entre os n´os. Para a simulac¸˜ao de redes sem fio ´e recomendado o uso do Extendable Mobile Ad-hoc Network
  16. 16. Emulator (EMANE). O EMANE ´e um framework que pode ser adicionado n˜ao somente no CORE, mas em diversos outros simuladores. A utilizac¸˜ao deste framework torna a arquitetura e os protocolos de uma rede sem fio mais completos em relac¸˜ao a instalac¸˜ao original do simulador. Em uma instalac¸˜ao original, o CORE gerencia todas as camadas da pilha de rede, fazendo uso da placa de rede real para gerenciamento das camadas f´ısica e de enlace. Se utilizado o EMANE, ele ´e capaz de gerenciar as camadas 1 e 2 da pilha. Desta forma, o CORE gerencia somente as camadas mais altas. Al´em do EMANE, torna-se necess´aria a instalac¸˜ao do Quagga8 para experimen- tos com o CORE. O Quagga ´e um pacote conhecido como uma suite de modelos de configurac¸˜ao para roteadores. Sua instalac¸˜ao faz com que obtenham-se pacotes ne- cess´arios para a configurac¸˜ao de roteadores sem fio de padr˜oes utilizados na simulac¸˜ao. A simulac¸˜ao foi realizada com roteadores do tipo Modular Data Router (MDR). O CORE n˜ao possui modelos nativos de mobilidade dos n´os, por´em ´e poss´ıvel importar padr˜oes externos. Em func¸˜ao disso, utilizou-se a ferramenta BonnMotion9 . O BonnMotion ´e capaz de implementar diversos tipos de mobilidade, gerando um arquivo de sa´ıda que poder´a ser importado na simulac¸˜ao. Optou-se pela utilizac¸˜ao de traces do BonnMotion pela sua maior aceitac¸˜ao nos simuladores, se comparado com traces de si- muladores de tr´afego. ´E poss´ıvel fazer com que as topologias simuladas interajam com um ambiente real. Para tanto, ´e necess´aria a instalac¸˜ao de uma Application Programming Interface (API), que pode ser obtida da p´agina principal do CORE. No caso de VANETs, isto pode ser ´util `a medida em que experimentos reais comec¸am a ser criados, de forma a utilizar ambientes reais e virtuais para a criac¸˜ao de um experimento com grandes topologias. Esta func¸˜ao pode ainda ser utilizada a fim de se obterem recursos computacionais adicionais (e.g., clusters). A Figura 10 ilustra o ambiente de configurac¸˜ao de topologias do CORE. Nela ´e poss´ıvel perceber que sua interface gr´afica ´e simples, por´em ´util e funcional. A topologia apresentada na imagem apresenta a comunicac¸˜ao sem fio de trˆes n´os. Uma vez iniciada a simulac¸˜ao, o n´o n1 envia pacotes para o n´o n3. Embora eles n˜ao possuam conectividade direta, o tr´afego ´e enviado para o n´o n2, que possui comunicac¸˜ao com ambos. n2, por sua vez, torna-se respons´avel pelo roteamento das informac¸˜oes, exemplificando o roteamento ad hoc. 4.3. OMNET++ Alguns simuladores foram considerados no in´ıcio das atividades pr´aticas. Optou-se, ao final, pela utilizac¸˜ao do CORE e NS-3. Esta decis˜ao foi tomada ao longo dos testes reali- zados. O in´ıcio dos experimentos contou com a utilizac¸˜ao do simulador OMNET++10 . A opc¸˜ao pela utilizac¸˜ao do OMNET++ foi tomada baseando-se nos projetos que ele apoia. Um destes projetos possui total relac¸˜ao com VANETs, o Veins11 . O Veins ´e um framework que re´une a interface do OMNET++ com os dados de mobilidade do 8 http://www.nongnu.org/quagga/ 9 http://www.bonnmotion.net 10 http://www.omnetpp.org/ 11 http://veins.car2x.org/
  17. 17. Figura 10. Ambiente de configurac¸ ˜ao de topologias do CORE simulador de tr´afego SUMO. Seu objetivo principal ´e a criac¸˜ao de simulac¸˜oes real´ısticas de redes veiculares sem a dependˆencia de programas auxiliares. Apesar do Veins ser uma boa opc¸˜ao para experimentos relacionados `as VANETs, o OMNET++ foi descartado ao longo deste trabalho. Esta decis˜ao foi tomada pois n˜ao foi identificada uma maneira vi´avel de execuc¸˜ao de aplicac¸˜oes nos n´os criados neste si- mulador. Esta funcionalidade ´e de grande importˆancia para a realizac¸˜ao deste trabalho. Portanto, optou-se por concentrar a pesquisa nos demais simuladores relatados. 5. Simulac¸˜ao realizada Foram realizados testes em um ambiente real e um ambiente virtual. O sistema operaci- onal utilizado em ambos os casos foi o Ubuntu 12.04 de 64 bits. O ambiente real operou com um computador com 4GB de mem´oria RAM e processador Intel Core i5-3320M. A estrutura do ambiente virtual ´e semelhante, no entanto ele possui 2GB de mem´oria RAM. A opc¸˜ao pelo sistema Linux se deu pelo fato que todas as ferramentas utilizadas foram criadas para esta plataforma. Embora algumas pesquisas mostrem que o mesmo ambi- ente poderia ser criado utilizando-se a ferramenta Cygwin, optou-se pela utilizac¸˜ao de um ambiente Linux nativo, a fim de se evitar poss´ıveis incompatibilidades. A implementac¸˜ao teve in´ıcio com o simulador NS-3. Isto se deve `a necessidade de um entendimento pr´evio para elaborac¸˜ao de scripts e comandos gerais do simulador. Estas instruc¸˜oes s˜ao obtidas por meio de manuais e tutoriais de utilizac¸˜ao. Boa parte dos manuais s˜ao encontrados na p´agina oficial do NS-3. Isto torna o in´ıcio das simulac¸˜oes um pouco demorado, principalmente para quem n˜ao mant´em contato com a linguagem de programac¸˜ao C++. Por outro lado, isso torna mais r´apida a busca por suporte, se necess´ario.
  18. 18. A implementac¸˜ao original do simulador possui exemplos de suporte a Linux Con- tainers (LXC). Assim, estes exemplos foram utilizados como base para a simulac¸˜ao fi- nal. Esta ´e uma pr´atica comum entre os usu´arios do NS-3 pois normalmente cada nova simulac¸˜ao deve ser desenvolvida, desde o in´ıcio, em linguagem C++. Portanto, torna-se uma alternativa o uso de c´odigos funcionais de outros scripts, modificando-os para que se enquadrem na simulac¸˜ao em quest˜ao. Como resultado, obteve-se um script de dois n´os em uma rede sem fio com um padr˜ao de mobilidade nativo do NS-3. A medida em que a simulac¸˜ao cresce, torna-se necess´aria a criac¸˜ao de mais n´os com suporte a LXC no script de simulac¸˜ao. A opc¸˜ao pela utilizac¸˜ao de poucos n´os na simulac¸˜ao se deu por dois motivos: primeiramente para que a topologia seja melhor compreendida; o segundo motivo est´a relacionado `a melhor utilizac¸˜ao dos recursos computacionais envolvidos. Cada nova implementac¸˜ao LXC significa uma nova camada de virtualizac¸˜ao no sistema Linux. Desta forma, ´e necess´ario cuidado com o n´umero de implementac¸˜oes simultˆaneas. Para que a simulac¸˜ao acontec¸a, o ambiente Linux deve estar configurado para suportar duas novas virtualizac¸˜oes. A configurac¸˜ao est´a explicada em detalhes no Anexo A. A criac¸˜ao de uma topologia no CORE ´e feita significativamente r´apida. O motivo que mais contribui para isso ´e a interface gr´afica obtida no CORE. Sendo assim, uma simulac¸˜ao com poucos n´os ´e criada em alguns segundos. No NS-3, a criac¸˜ao de uma simulac¸˜ao com a mesma topologia poderia levar dias, dependendo do n´ıvel de conheci- mento do desenvolvedor. Foram criadas simulac¸˜oes com dois e trˆes n´os. Dessa forma, criou-se dois arqui- vos de mobilidade randˆomica no BonnMotion. Os roteadores foram configurados como unidade sem fio, a fim de melhor representarem Onboard Units (OBUs). Para que a simulac¸˜ao tivesse in´ıcio, iniciou-se os servic¸os de roteamento dos roteadores. A atribuic¸˜ao de enderec¸os do CORE ´e feita automaticamente, o que facilita a simulac¸˜ao. Por fim, ambos os simuladores foram configurados com padr˜oes de mobilidade e funcionalidade LXC em seus n´os. Neste momento, o ManP2P-ng 12 [Duarte et al. 2011] foi executado nos n´os da rede, criando um overlay P2P e iniciando o servic¸o de monito- ramento dos n´os. Uma vez que o m´odulo de monitoramento foi iniciado, observou-se que os n´os criados iniciaram a troca de mensagens entre si. N˜ao ocorreram incompatibilida- des na execuc¸˜ao do ManP2P-ng. De forma an´aloga, ´e poss´ıvel que o monitoramento P2P obtenha resultados positivos, se implementado em VANETs reais. A Figura 11 ilustra o in´ıcio da comunicac¸˜ao entre dois n´os, chamados n1 e n2, no overlay criado no CORE. 6. Avaliac¸˜ao O resultado dos experimentos realizados na sec¸˜ao anterior busca identificar caracter´ısticas de desempenho dos simuladores utilizados. Conforme explicado na sec¸˜ao 4, existem diversos simuladores para experimentos relacionados `a topologia de VANETs, como ´e o caso do OMNET++. No entanto, a utilizac¸˜ao deste simulador dificulta a configurac¸˜ao individual dos n´os, um dos objetivos propostos neste trabalho. O NS-3 e o CORE foram mantidos na implementac¸˜ao realizada neste trabalho pois se diferenciam do OMNET++ neste quesito. Ambos s˜ao capazes de executar diferentes sistemas dentro de seus n´os. Para 12 https://github.com/ComputerNetworks-UFRGS/ManP2P-ng
  19. 19. Figura 11. overlay criado pelo ManP2P em n´os do CORE a realizac¸˜ao deste trabalho utilizou-se a aplicac¸˜ao ManP2P-ng em ambos os simuladores. O ManP2P-ng ´e um sistema P2PBNM, e foi implementado em cada n´o do experimento, de forma a simular a comunicac¸˜ao entre Onboard Units (OBUs), referenciados na sec¸˜ao 2. A avaliac¸˜ao baseou-se em alguns crit´erios apresentados pelas ferramentas. Alguns conceitos foram observados para a realizac¸˜ao de avaliac¸˜oes [Jackson et al. 2011]. Inici- almente, foram avaliadas quest˜oes relacionadas `a instalac¸˜ao das ferramentas. N˜ao existe um arquivo de construc¸˜ao (e.g., script) que realize a instalac¸˜ao completa das aplicac¸˜oes. No entanto, em ambos os casos, a documentac¸˜ao de instalac¸˜ao foi clara e precisa. A instalac¸˜ao do NS-3 ´e mais simples que a do CORE, uma vez que requer menor n´umero de ac¸˜oes por parte do usu´ario. Isto ocorre porque a instalac¸˜ao do CORE possui algu- mas dependˆencias adicionais, utilizadas neste trabalho, como o EMANE e Quagga. Estas dependˆencias devem ser instaladas separadamente, tornando a instalac¸˜ao do CORE um pouco mais lenta que a do NS-3. A pr´oxima caracter´ıstica avaliada foram as implementac¸˜oes LXC apresentadas por ambos os simuladores. Os t´uneis LXC s˜ao uma importante opc¸˜ao para a execuc¸˜ao de c´odigos diretamente nos n´os. O CORE apresenta implementac¸˜oes nativas dos t´uneis, enquanto o NS-3 necessita uma s´erie de configurac¸˜oes adicionais para poder utiliz´a-los. O NS-3, no entanto, possui outra alternativa para esta func¸˜ao, chamada Direct Code Exe- cution (DCE), cujas caracter´ısticas foram descritas na sec¸˜ao 4. A utilizac¸˜ao da ferramenta LXC foi muito importante para a instalac¸˜ao da aplicac¸˜ao P2PBNM. A virtualizac¸˜ao do kernel, obtida com a sua utilizac¸˜ao, faz com que seja poss´ıvel simular diversos equipa- mentos com caracter´ısticas distintas. Recomenda-se a utilizac¸˜ao de sistemas Linux para a instalac¸˜ao dos simuladores. Para a instalac¸˜ao do NS-3, especificamente, as distribuic¸˜oes Ubuntu e Fedora. Estas s˜ao as
  20. 20. distribuic¸˜oes utilizada para testes e documentac¸˜oes oficiais. O sistema Mac OSX tamb´em suporta a instalac¸˜ao deste simulador. O CORE pode ser executado em sistemas FreeBSD e Linux de uma maneira geral. No entanto, estas s˜ao as ´unicas plataformas suportadas pelo CORE, pois s˜ao as ´unicas que possuem suporte a virtualizac¸˜ao do kernel (LXC), executado nos n´os do CORE. Sendo assim, o sistema operacional Windows n˜ao deve ser utilizado para execuc¸˜ao destas ferramentas. Do contr´ario, isso dificultaria a execuc¸˜ao de aplicac¸˜oes P2P nos n´os da rede. Neste trabalho foi utilizado o sistema operacional Ubuntu Linux 12.04 de 64 bits, sendo que, em nenhum momento foram encontradas incompati- bilidades com as aplicac¸˜oes avaliadas. O estudo anterior mostrou que os simuladores poderiam ser utilizados de forma conjunta com redes reais. Uma vez que foram trabalhados com o uso de m´aquinas virtuais, verificou-se tamb´em se poderiam trabalhar com equipamentos (i.e., hosts) re- ais. Como resultado, constatou-se que ambos os simuladores suportam este tipo de implementac¸˜ao. O CORE possui uma ferramenta pr´opria para conex˜ao com dispositi- vos externos. O NS-3 pode fazer esta conex˜ao atrav´es das implementac¸˜oes LXC. Foram utilizados protocolos de comunicac¸˜ao tradicionais nas duas simulac¸˜oes. Isto ocorreu pois os protocolos de comunicac¸˜ao VANET referenciados na sec¸˜ao 3 (e.g., WAVE, WSMP) ainda n˜ao foram implementados nos simuladores trabalhados. Sendo assim, utilizaram-se as abstrac¸˜oes j´a implementadas para o roteamento no NS-3. Para o roteamento entre roteadores no CORE, utilizou-se o protocolo OSPFv3. A pr´oxima caracter´ıstica avaliada refere-se aos arquivos trace. a utilizac¸˜ao des- tes arquivos provˆe um padr˜ao de mobilidade aos n´os, simulando a movimentac¸˜ao de ve´ıculos. O NS-3 implementa nativamente uma s´erie de padr˜oes de mobilidade. Desta forma, utilizou-se o padr˜ao RandomWalk2dMobility. O CORE, por´em, n˜ao realiza a implementac¸˜ao de padr˜oes de mobilidade nativos. Ambos os simuladores, no entanto, s˜ao capazes de importar arquivos trace de ferramentas auxiliares. Arquivos trace podem ser obtidos tanto de simuladores de tr´afego, quando de ferramentas de gerac¸˜ao de modelos de mobilidade. A simulac¸˜ao do CORE foi realizada com padr˜oes de mobilidades gerados pela ferramenta BonnMotion. O NS-3 possui vantagem sobre o CORE, no que diz respeito a quantidade de n´os suportados na simulac¸˜ao. O fato de n˜ao possui uma interface gr´afica pode ajudar neste sentido, aumentando o desempenho da simulac¸˜ao e fazendo com que mais n´os sejam su- portados na mesma simulac¸˜ao. Uma pesquisa diz que o NS-3 pode suportar algo em torno de 1000 n´os na simulac¸˜ao [Stanica et al. 2011]. O n´umero de n´os suportados pelo CORE, de acordo com a sua documentac¸˜ao oficial, pode variar em func¸˜ao de diversos outros fato- res (e.g., hardware e sistema operacional utilizado, n´umero de processos ativos). Em um ambiente simples, com 2GB de mem´oria RAM, ele pode instanciar algo em torno de 100 n´os com o protocolo de roteamento OSPFv3 [Ahrenholz 2013]. A simulac¸˜ao realizada neste trabalho contou com poucos n´os, portanto n˜ao houveram problemas de desempenho dos n´os quando iniciada a aplicac¸˜ao P2PBNM. A Tabela 1 indica algumas caracter´ısticas avaliadas em cada simulador, com base na aplicac¸˜ao de aplicac¸˜oes baseadas em P2P. Nessa tabela, ´e poss´ıvel identificar algumas das caracter´ısticas avaliadas em cada simulador, bem como os resultados obtidos. A aplicac¸˜ao P2P pˆode ser implementada em ambos os simuladores sem qualquer
  21. 21. Tabela 1. Comparac¸ ˜ao de funcionalidades apresentadas pelos simuladores NS-3 CORE Suporte a implementac¸˜oes LXC x x Implementac¸˜oes LXC nativas x Suporte a traces externos x x Suporte completo a protocolos de comunicac¸˜ao VANET (e.g., WAVE) Integrac¸˜ao a hosts reais x x Integrac¸˜ao a redes reais x x Suporte a Sistema Operacional Linux x x Suporte a Sistema Operacional Windows Suporte a Sistema Operacional Mac OS X x Suporte a Sistema Operacional FreeBSD x x Interface gr´afica x N˜ao possui custo para implementac¸˜ao x x C´odigo aberto x x Implementa uma forma de execuc¸˜ao de comandos alternativa ao LXC x tipo de incompatibilidade. Entretanto a utilizac¸˜ao do CORE trouxe mais vantagens `a simulac¸˜ao. Sua interface gr´afica ajudou na soluc¸˜ao de problemas e maximizou o tempo de criac¸˜ao de novas simulac¸˜oes. A implementac¸˜ao pr´opria da ferramenta LXC tamb´em foi ´util na simulac¸˜ao. O NS-3 n˜ao possui esta caracter´ıstica nativamente, portanto foi necess´aria a criac¸˜ao e configurac¸˜oes de t´uneis manuais. Scripts de configurac¸˜ao LXC foram criados a fim de agilizar este processo, e podem ser visualizados no Anexo 2. O tempo de criac¸˜ao de novas simulac¸˜oes no NS-3 foi mais alto que o do CORE. Isto se deu pois os scripts de criac¸˜ao de novas simulac¸˜oes devem ser programados com linguagem C++. O NS-3, por sua vez, tamb´em possui outras vantagens, se comparado ao CORE. Primeiramente, trata-se de uma das maiores ferramentas de simulac¸˜ao da atualidade. O NS-3 possui c´odigo aberto e uma documentac¸˜ao completa e organizada na plataforma Doxygen. Isto facilita e faz com que seja poss´ıvel a atualizac¸˜ao permanente, com o envio de novos projetos, criados por desenvolvedores. Os projetos podem ser dos mais diversos tipos, podendo variar desde a implementac¸˜ao de um novo protocolo de roteamento, at´e uma simples correc¸˜ao de falha (i.e., bug fixing). Em ambos os casos, o NS-3 se torna mais indicado. No entanto, estas caracter´ısticas n˜ao tiveram relac¸˜ao direta com a aplicac¸˜ao P2P. O suporte encontrado pelo NS-3 tamb´em ´e superior ao do CORE. Talvez isto acontec¸a dada a dificuldade inicial apresentada pelo NS-3 aos novos usu´arios. Por´em, este apresenta uma s´erie de manuais, tutoriais, grupos de discuss˜ao e canais de comunicac¸˜ao. O CORE, por sua vez, possui um manual de instruc¸˜oes e um canal de comunicac¸˜ao, via e-mail. Os dois simuladores trabalhados s˜ao altamente customiz´aveis. Isto se d´a pelo fato de ambos possu´ırem c´odigo aberto. Desta forma ´e poss´ıvel alterar a maneira como os simuladores implementam suas funcionalidades. A customizac¸˜ao do NS-3, por´em, tende a ser mais ´util neste caso, dada a vasta documentac¸˜ao de suas func¸˜oes.
  22. 22. A atualizac¸˜ao dos simuladores ´e realizada atrav´es da reinstalac¸˜ao dos mesmos, utilizando a vers˜ao mais atual. Sendo assim, existe uma maior facilidade na atualizac¸˜ao do NS-3, ainda que a instalac¸˜ao do CORE n˜ao possua complicac¸˜oes. A periodicidade de atualizac¸˜oes apresentada pelo NS-3 tamb´em ´e melhor, em comparac¸˜ao ao CORE. Uma nova vers˜ao do NS-3 ´e lanc¸ada, em m´edia, a cada 4 meses. J´a as novas vers˜oes do CORE s˜ao apresentadas aproximadamente duas vezes ao ano. A tabela 2 foi criada para melhor compreender as avaliac¸˜oes realizadas. Diferen- temente da tabela 1, cujo objetivo ´e apresentar func¸˜oes implementadas nos simuladores, a tabela 2 elenca qual simulador melhor implementa as caracter´ısticas citadas. A avaliac¸˜ao foi realizada com base na construc¸˜oes de simulac¸˜oes e implementac¸˜ao do ManP2P-ng na simulac¸˜ao. Ainda que tenha sido escolhido somente um simulador para cada item, algumas caracter´ısticas s˜ao muito parecidas entre as duas ferramentas. Tabela 2. Escolha dos simuladores com base nas suas funcionalidades NS-3 CORE Maior facilidade na utilizac¸˜ao x Menor tempo de instalac¸˜ao x Melhor possibilita a customizac¸˜ao de funcionalidades x Maior n´umero de n´os suportado x Maior facilidade de contribuic¸˜ao de novas funcionalidades x Maior facilidade de contribuic¸˜ao de bug fixing x Documentac¸˜ao mais completa para usu´arios x Documentac¸˜ao mais completa para desenvolvedores x Menor tempo para adaptac¸˜ao `a ferramenta x Maior facilidade de atualizac¸˜ao de software x Menor tempo para criac¸˜ao de simulac¸˜oes x 7. Conclus˜oes e trabalhos futuros VANETs s˜ao redes projetadas para trazer benef´ıcios aos motoristas e passageiros de ve´ıculos. No entanto, o alto dinamismo dos n´os, somado a sua constante mobilidade dificultam o gerenciamento destas redes. Por se tratar de uma rede tolerante a atra- sos/desconex˜oes, este tipo de rede n˜ao possui conectividade fim-a-fim entre os n´os. Sendo assim, a conex˜ao entre ve´ıculos pode ser prejudicada, uma vez que a comunicac¸˜ao entre dois n´os (e.g., aviso sobre uma colis˜ao) pode demorar tanto a ponto de n˜ao encontrar seu destino, ou simplesmente o n´o destino n˜ao necessitar mais da informac¸˜ao. Criados com o objetivo de integrar soluc¸˜oes de gerenciamento tradicionais com a tecnologia P2P, ´e poss´ıvel que sistemas de gerenciamento baseados em P2P (P2P-Based Network Mana- gement - P2PBNM) possam auxiliar na dificuldade de gerenciamento de VANETs. Por possu´ırem uma arquitetura descentralizada e boa adaptac¸˜ao a ambientes de grande mobi- lidade entre os n´os, a utilizac¸˜ao de tecnologias P2P pode ser uma alternativa efetiva no gerenciamento de redes como VANETs. Grande parte das simulac¸˜oes de redes veiculares s˜ao realizadas com base em si- muladores de rede. O resultado obtido por simuladores pode divergir do obtido em uma rede real, no entanto ele pode servir como um indicativo de soluc¸˜ao. Simuladores po- dem ainda trazer benef´ıcios ao experimento, como a reduc¸˜ao do tempo utilizado para
  23. 23. criac¸˜ao de experimentos. A medida em que VANETs comec¸am a ganhar trac¸os de reali- dade em grandes ´areas, a utilizac¸˜ao de simuladores pode ser ben´efica de diversas formas. Por exemplo, podem se tornar uma importante opc¸˜ao para o desenvolvimento de novos modelos de gerenciamento para VANETs, como aplicac¸˜oes P2PBNM. Para tanto, existiu a necessidade de avaliac¸˜ao dos simuladores utilizados para estes experimentos, quanto a implementac¸˜ao de aplicac¸˜oes P2P. O presente trabalho abordou a realizac¸˜ao de um estudo com base em simulac¸˜oes e avaliac¸˜oes dos resultados encontrados em simuladores de redes veiculares ad hoc. Este trabalho avaliou os simuladores quanto as suas caracter´ısticas, considerando os benef´ıcios que as aplicac¸˜oes P2PBNM podem trazer ao gerenciamento de VANETs. Foram realiza- dos testes em ambientes virtualizados e ambientes reais. Pode-se dizer que, em ambos os casos, os resultados obtidos dos simuladores foram satisfat´orios. A aplicac¸˜ao P2P n˜ao apresentou incompatibilidades em nenhum dos ambientes trabalhados. Da mesma forma, n˜ao houve extrapolac¸˜ao de dados com nenhum dos simuladores. De forma an´aloga, por- tanto, ´e poss´ıvel que o monitoramento P2P obtenha resultados positivos, se implemen- tado em VANETs reais. Por outro lado, existem algumas caracter´ısticas espec´ıficas de VANETs que ainda n˜ao est˜ao dispon´ıveis para implementac¸˜ao nos simuladores trabalha- dos. `A medida que protocolos de roteamento utilizados em VANETs comec¸arem a ser modelados tamb´em em simuladores, isto certamente trar´a benef´ıcios para as simulac¸˜oes. Embora os resultados obtidos dos simuladores fossem positivos, constatou-se al- gumas divergˆencias na sua utilizac¸˜ao. Algumas func¸˜oes podem ser melhor realizadas pelo NS-3 ou pelo CORE. Para melhor visualizar dos resultados obtidos, foram criadas tabelas de comparac¸˜ao na sec¸˜ao 6. No entanto, ainda que um simulador implemente melhor uma determinada caracter´ıstica, ´e poss´ıvel dizer que os resultados obtidos entre eles foram semelhantes. Como trabalho futuro, sugere-se a implementac¸˜ao cont´ınua de funcionalidades e protocolos de comunicac¸˜ao relacionados a VANETs nos simuladores trabalhados. Alguns protocolos foram citados na sec¸˜ao 3 (e.g., WAVE, WSMP). Desta forma, as simulac¸˜oes poderiam se aproximar cada vez mais de experimentos reais, contribuindo para novos experimentos realizados sobre VANETs. Referˆencias Ahrenholz, J. (2010). Comparison of core network emulation platforms. In MILITARY COMMUNICATIONS CONFERENCE, 2010 - MILCOM 2010, pages 166–171. Ahrenholz, J. (2013). Core documentation - release 4.6. Technical report. Alves, R., Campbell, I., Couto, R., Campista, M., Moraes, I., Rubinstein, M., Costa, L., Duarte, O., and Abdalla, M. (2009). Redes veiculares: princ´ıpios, aplicac¸˜oes e desafios. In Minicurso do Simp´osio Brasileiro de Redes de Computadores, pages 199– 254. SBRC. Androutsellis-Theotokis, S. and Spinellis, D. (2004). A survey of peer-to-peer content distribution technologies. ACM Comput. Surv., 36(4):335–371. Bertinatto, F. J. (2012). Monitorac¸˜ao de encontros em redes tolerantes a atrasos e desco- nex˜oes.
  24. 24. Blum, J., Eskandarian, A., and Hoffman, L. (2004). Challenges of intervehicle ad hoc networks. Intelligent Transportation Systems, IEEE Transactions on, 5(4):347–351. Chiang, K.-H. and Shenoy, N. (2004). A 2-d random-walk mobility model for location- management studies in wireless networks. Vehicular Technology, IEEE Transactions on, 53(2):413–424. Dias, B., Andrade, R., and Guedes, M. (2010). Comunicac¸˜ao inter-veicular entre ve´ıculos- infra-estrutura com o estudo do protocolo dsrc. Dowell, C. (2010). How to use linux containers to set up virtual networks. Technical report. Duarte, P., Nobre, J., Granville, L., and Rockenbach Tarouco, L. (2011). A p2p-based self-healing service for network maintenance. In Integrated Network Management (IM), 2011 IFIP/IEEE International Symposium on, pages 313–320. Granville, L., da Rosa, D., Panisson, A., Melchiors, C., Almeida, M., and Rockenbach Ta- rouco, L. (2005). Managing computer networks using peer-to-peer technologies. Com- munications Magazine, IEEE, 43(10):62–68. Jackson, M., Crouch, S., and Baxter, R. (2011). Software evaluation: Tutorial-based assessment. Technical report. Karp, B. and Kung, H. T. (2000). Gpsr: Greedy perimeter stateless routing for wireless networks. In Proceedings of the 6th Annual International Conference on Mobile Com- puting and Networking, MobiCom ’00, pages 243–254, New York, NY, USA. ACM. Naumov, V., Baumann, R., and Gross, T. (2006). An evaluation of inter-vehicle ad hoc networks based on realistic vehicular traces. In Proceedings of the 7th ACM Internati- onal Symposium on Mobile Ad Hoc Networking and Computing, MobiHoc ’06, pages 108–119, New York, NY, USA. ACM. Nobre, J., Bertinatto, F., Duarte, P., Granville, L., and Tarouco, L. (2013). Gerenciamento oportun´ıstico em redes tolerantes a atrasos/desconex˜oes atrav´es da utilizac¸˜ao de tecno- logia par-a-par na previs˜ao de encontros entre n´os. In XVIII Workshop de Gerˆencia e Operac¸˜ao de Redes e Servic¸os. SBRC. Oliveira, C. T. D., Moreira, M. D. D., Rubinstein, M. G., Henrique, L., Costa, M. K., and Carlos, O. (2007). Redes tolerantes a atrasos e desconex˜oes. In Simp´osio Brasileiro de Redes de Computadores e Sistemas Distribu´ıdos, pages 203–256. SBRC. Panisson, A., da Rosa, D., Melchiors, C., Granville, L., Almeida, M., and Rockenbach Ta- rouco, L. (2006). Designing the architecture of p2p-based network management sys- tems. In Computers and Communications, 2006. ISCC ’06. Proceedings. 11th IEEE Symposium on, pages 69–75. Rampfl, S. (2013). Network simulation and its limitations. Seminar Future Internet (FI) SS2013, pages 57–63. Stanica, R., Chaput, E., and Beylot, A.-L. (2011). Simulation of vehicular ad-hoc networks: Challenges, review of tools and recommendations. volume 55, pages 3179– 3188. Elsevier North-Holland, Inc., New York, NY, USA. Wang, Y. (2012). Review of vehicular networks, from theory to practice. volume 43, pages 25–29. ACM, New York, NY, USA.
  25. 25. Warthman, F. (2003). Delay tolerant networks (dtns): A tutorial. Technical report, Bol. T´ec. PETROBRAS. Yousefi, S., Mousavi, M., and Fathy, M. (2006). Vehicular ad hoc networks (vanets): Challenges and perspectives. In ITS Telecommunications Proceedings, 2006 6th Inter- national Conference on, pages 761–766. Zeadally, S., Hunt, R., Chen, Y.-S., Irwin, A., and Hassan, A. (2012). Vehicular ad hoc networks (vanets): status, results, and challenges. Telecommunication Systems, 50(4):217–241. Zhang, J. (2012). Trust management for vanets: Challenges, desired properties and future directions. Int. J. Distrib. Syst. Technol., 3(1):48–62. Zhao, J. and Cao, G. (2008). Vadd: Vehicle-assisted data delivery in vehicular ad hoc networks. Vehicular Technology, IEEE Transactions on, 57(3):1910–1922.
  26. 26. 8. Anexo A - Tutorial de instalac¸˜ao e configurac¸˜ao A seguir est´a documentada a forma como as ferramentas trabalhadas foram instaladas e configuradas. Este tutorial foi criado com base no sistema operacional Ubuntu Linux 12.04 de 64 bits. 8.1. NS-3 8.1.1. Instalac¸˜ao e execuc¸˜ao A instalac¸˜ao foi realizada com base no Mercurial. Portanto, ele dever´a estar previamente instalado no sistema, juntamente de alguns outros pr´e-requisitos: $ sudo apt-get install mercurial gcc g++ python python-dev bzr Recomenda-se a criac¸˜ao de um diret´orio chamado repos, na pasta home do usu´ario. Nela ser´a copiado todo o conte´udo do Mercurial: $ cd $ mkdir repos $ cd repos $ hg clone http://code.nsnam.org/ns-3-allinone Quando o comando for finalizado, o seguinte conte´udo dever´a estar presente no diret´orio repos: build.py* constants.py dist.py* download.py* README util.py Para fazer o download da vers˜ao de desenvolvimento do NS-3, basta executar o script download.py da seguinte maneira: $ ./download.py -n ns-3-dev Caso haja necessidade de se obter uma vers˜ao diferente de desenvolvimento, basta substituir o ”ns-3-dev”pela vers˜ao desejada. Assim que o download for finalizado, basta executar o script build.py, dentro do diret´orio /home/repos/ns-3-allinone. Este script construir´a o NS-3 dentro do sistema Ubuntu. $ ./build.py Para a execuc¸˜ao de scripts criados no NS-3, ser´a utilizada a ferramenta Waf. Para configur´a-la, basta executar o seguinte comando dentro do diret´orio onde o NS-3 foi instalado:
  27. 27. $ ./waf configure Para validar a instalac¸˜ao, basta executar o script test.py: $ ./test.py Sempre que um script for executado dentro da pasta do NS-3, o Waf far´a uma compilac¸˜ao total dos scripts da pasta. No entanto, ´e uma boa pr´atica a recompilac¸˜ao de todos os scripts, atrav´es do comando: $ ./waf Para executar uma simulac¸˜ao, ´e recomendado copi´a-la para o diret´orio scratch, dentro da pasta principal do NS-3. Ap´os isto, ´e poss´ıvel execut´a-la com o comando: $ ./waf --run nome_do_arquivo Algumas simulac¸˜oes podem ter seus valores alterados no momento da execuc¸˜ao. Por exemplo, um determinado script possui uma vari´avel chamada num nos, que cont´em o n´umero de n´os da simulac¸˜ao. Se este script suportar alterac¸˜ao de vari´aveis na execuc¸˜ao, a vari´avel num nos conter´a um valor padr˜ao, por´em este valor poder´a ser alterado a partir da execuc¸˜ao: $ ./waf --run "nome_do_arquivo --num_nos=5" 8.1.2. NetAnim O NetAnim ´e uma ferramenta que auxilia o entendimento das simulac¸˜oes do NS-3 de forma gr´afica. Para os experimentos, optou-se pela instalac¸˜ao da vers˜ao 3.104, a vers˜ao est´avel mais atual. Este tutorial assume que os passos para a instalac¸˜ao do NS-3 j´a foram executados. Para iniciar, ´e necess´ario efetuar o download do NetAnim: $ hg clone http://code.nsnam.org/jabraham3/netanim-3.104 Para que seja poss´ıvel a construc¸˜ao do aplicativo, ´e necess´aria a instalac¸˜ao da ferramenta QMAKE: $ apt-get install qt4-dev-tools Para instalar o NetAnim, basta seguir os passos abaixo:
  28. 28. $ cd netanim $ make clean $ qmake NetAnim.pro $ make Uma vez instalado, as configurac¸˜oes restantes devem ser feitas diretamente nos arquivos de simulac¸˜ao. Inicialmente, ´e necess´aria a inclus˜ao do cabec¸alho abaixo: #include "ns3/netanim-module.h" Ap´os, o comando abaixo deve ser inserido antes de Simulation::Run(): AnimationInterface anim ("nome_da_animacao.xml"); Quando executado, o simulador ir´a gerar um arquivo de extens˜ao .xml, que dever´a ser encontrado na pasta raiz do NS-3. Para visualizar a simulac¸˜ao gr´afica, basta importar o arquivo .xml para o NetAnim, no bot˜ao Open. Para executar o NetAnim, basta entrar no seu respectivo diret´orio e digitar o comando: $ sudo ./NetAnim Nota: Podem existir alguns problemas na animac¸˜ao de alguns tipos de redes sem fio. Dessa forma, recomenda-se que os n´os possuam pontos fixos de inicializac¸˜ao. 8.1.3. Configurac¸˜ao dos t´uneis LXC Conforme j´a mencionado, o NS-3 possui exemplos de scripts para utilizac¸˜ao de LXC. Neste tutorial, foi utilizado o arquivo tap-wifi-virtual-machine.cc como base. Desta forma, ´e prevista a criac¸˜ao de dois n´os: o left e o right. A nomenclatura diz respeito `a orientac¸˜ao de cada terminal, a fim de facilitar sua execuc¸˜ao. A criac¸˜ao de t´uneis para a criac¸˜ao de LXC no sistema passa pela instalac¸˜ao dos seguintes pacotes: $ sudo apt-get install lxc uml-utilities vtun Inicia-se com a criac¸˜ao das bridges. Estas ser˜ao as portas utilizadas para o tr´afego de pacotes entre os Containers. $ sudo brctl addbr br-left $ sudo brctl addbr br-right A seguir, cria-se dispositivos tap, respons´aveis por coletar os pacotes da bridge
  29. 29. para o processo. Em seguida, atribui-se enderec¸o 0.0.0.0 para inici´a-los. Foram mantidas as nomenclaturas left e right, para facilitar a simulac¸˜ao. $ sudo tunctl -t tap-left $ sudo tunctl -t tap-right $ sudo ifconfig tap-left 0.0.0.0 promisc up $ sudo ifconfig tap-right 0.0.0.0 promisc up Agora ´e necess´ario adicionar os dispositivos tap com as respectivas bridges: $ sudo brctl addif br-left tap-left $ sudo ifconfig br-left up $ sudo brctl addif br-right tap-right $ sudo ifconfig br-right up O comando abaixo dever´a confirmar se os taps e bridges foram criados correta- mente: $ sudo brctl show Neste momento, ser´a preciso criar os containers. Conforme citado, a configurac¸˜ao seguiu exemplos de simulac¸˜oes do NS-3, portanto utilizaremos os arquivos de configurac¸˜ao referenciados abaixo: $ sudo lxc-create -n left -f lxc-left.conf $ sudo lxc-create -n right -f lxc-right.conf O seguinte comando pode ser utilizado para listar os containers criados. Como resultado, dever˜ao aparecer os dois containers criados (left e right) $ sudo lxc-ls Para iniciar o container left, basta digitar: $ sudo lxc-execute -n left /bin/bash Utilizando outro terminal, ser´a poss´ıvel repetir o comando para o container right. Como resultado, o hostname indicado no prompt dever´a conter o nome do container criado: # root@left:˜# O comando ifconfig servir´a para avaliar se o enderec¸amento das interfaces foi criado corretamente. Se estiver correto, os enderec¸os devem aparecer como 10.0.0.1 e
  30. 30. 10.0.0.2. Dois scripts foram criados para auxiliar na manutenc¸˜ao de containers. O pri- meiro ´e utilizado para constru´ı-los, conforme configurac¸˜ao acima, e o segundo pode ser executado para removˆe-los. Ambos podem ser visualizados no anexo B. 8.2. CORE Algumas ac¸˜oes relatadas na instalac¸˜ao do CORE poder˜ao j´a ter sido efetuadas na instalac¸˜ao do NS-3. Estas ac¸˜oes foram mantidas no tutorial, visando leitores que queiram instalar um simulador apenas. Alguns pacotes s˜ao necess´arios para o correto funcionamento do CORE: $ sudo apt-get install bash bridge-utils ebtables iproute libev-dev python tcl8.5 tk8.5 libtk-img Conforme relatado na sec¸˜ao 5 do presente artigo, ´e necess´aria a instalac¸˜ao do Quagga para configurac¸˜ao dos protocolos de roteamento. Para instalar o pacote tradicional do Quagga, basta seguir o comando abaixo. No entanto, a simulac¸˜ao realizada neste trabalho contou com uma vers˜ao diferente da tradicional. Esta permitiu que fosse poss´ıvel a utilizac¸˜ao do protocolo OSPF MDR nos roteadores. Opc¸˜ao tradicional: $ sudo apt-get install quagga Instalac¸˜ao do Quagga com OSPF MDR: $ wget http://http://downloads.pf.itd.nrl.navy.mil/ospf-manet /quagga-0.99.21mr2.2/quagga-mr_0.99.21mr2.2_amd64.deb $ sudo dpkg -i quagga-mr_0.99.21mr2.2_amd64.deb A seguir, realiza-se o download e instalac¸˜ao do CORE. Se necess´ario, deve-se alterar o amd64 por i386. $ wget http://downloads.pf.itd.nrl.navy.mil/core/packages/ 4.6/core-daemon_4.6-0ubuntu1_precise_amd64.deb $ wget http://downloads.pf.itd.nrl.navy.mil/core/packages/ 4.6/core-gui_4.6-0ubuntu1_precise_all.deb $ sudo dpkg -i core-daemon_4.6-0ubuntu1_precise_amd64.deb $ sudo dpkg -i core-gui_4.6-0ubuntu1_precise_all.deb Por fim, basta iniciar o servic¸o do CORE e abrir sua interface gr´afica: $ sudo /etc/init.d/core-daemon start $ core-gui Para criar simulac¸˜oes, deve-se clicar nos itens desejados (e.g., roteadores, laptops)
  31. 31. para inseri-los na simulac¸˜ao. Como visto no artigo, o CORE possui implementac¸˜oes nativas de LXC. Portanto, cada item da topologia poder´a ser configurado desta forma ao ser clicado duas vezes. Este trabalho utilizou em sua topologia roteadores MDR, com ferramentas WLAN. A ferramenta WLAN atribui aos roteadores a capacidade de comunicac¸˜ao sem fio. Tamb´em atrav´es da ferramenta WLAN, ´e poss´ıvel atribuir um script de mobilidade dos n´os, atrav´es da opc¸˜ao configure. Por fim, o sistema ManP2P foi iniciado entre os n´os simulados, para fins de avaliac¸˜ao. A realizac¸˜ao do monitoramento atrav´es da ferramenta P2P n˜ao apresentou problemas. 8.3. BonnMotion Para baixar a vers˜ao do BonnMotion utilizada neste trabalho, basta executar o seguinte comando: $ http://sys.cs.uos.de/bonnmotion/src/bonnmotion-2.1a.zip Ap´os, deve-se extrair o arquivo .zip e, dentro do diret´orio resultante, executar o arquivo install. Ele ser´a respons´avel pela instalac¸˜ao do BonnMotion. $ ./install Uma vez instalado, ´e poss´ıvel criar scripts de mobilidade utilizando a seguinte sintaxe: ./bin/bm (parˆametros) (aplicac¸˜ao) (parˆametros da aplicac¸˜ao) Um exemplo de sintaxe utilizada neste trabalho ´e a seguinte: $ sudo ./bin/bm -f cenario1 RandomWaypoint -n 3 -d 900 -x 200 -y 400 -h 5.0 Esta sintaxe criar´a um documento chamado cenario1, que ter´a 3 n´os e durac¸˜ao de 900 segundos, em um mapa de 200x400 metros. A velocidade de mobilidade de cada n´o ser´a de 5.0 m/s. Uma vez que o arquivo esteja criado, ´e necess´aria um novo comando para que ele se torne compat´ıvel com os simuladores utilizados: $ sudo ./bin/bm NSFile -f cenario1 Por fim, o arquivo cenario1.ns movements poder´a ser utilizado nos simuladores a fim de atribuir a mobilidade criada aos n´os simulados. O manual de utilizac¸˜ao do Bonn- Motion pode ser consultado para maiores detalhes.
  32. 32. 8.4. ManP2P O ManP2P pode ser copiado com o seguinte comando: $ wget https://github.com/ComputerNetworks-UFRGS/ManP2P-ng /archive/master.zip Deve-se extrair o arquivo .zip e acessar o seguinte diret´orio: $ cd ManP2P-ng-master/old A partir deste diret´orio as instˆancias do ManP2P ser˜ao executadas. Para iniciar uma instˆancia, a seguinte sintaxe dever´a ser utilizada: $ sh blauncher -c[IP] -l[porta] -g[grupo] [hostname] Onde: IP - ´E o IP do peer que iniciou o overlay. Caso esteja configurando o primeiro peer do overlay, prosseguir para o pr´oximo parˆametro. Porta - ´E a porta de rede em que se deseja conectar. Se n˜ao for especificada nenhuma porta, o ManP2P utilizar´a sua porta padr˜ao (8001). Grupo - O grupo de peers dever´a possuir um nome. Todos os peers que se conectarem ao overlay dever˜ao especificar o mesmo grupo. Hostname - O nome do peer que deseja se conectar ao overlay Supondo que existam dois peers que desejam conectarem a um overlay, cujos enderec¸os IP s˜ao 10.0.0.1 e 10.0.0.2, as sintaxes seriam as seguintes: Peer1 (Introdutor) - IP 10.0.0.1: $ sudo sh blaucher -ggrupo peer1 Peer2 - IP 10.0.0.2: $ sudo sh blaucher -c10.0.0.1 -ggroup peer2 O comando abaixo pode ser executado para visualizac¸˜ao de maiores detalhes sobre sintaxe: $ sudo sh blaucher -h
  33. 33. 9. Anexo B - Scripts de configurac¸˜ao e remoc¸˜ao de t´uneis LXC Dois scripts foram criados para auxiliar a configurac¸˜ao de t´uneis LXC no simulador NS- 3. Um script automatiza a criac¸˜ao dos t´uneis citada no Anexo A. O outro remove as configurac¸˜oes criadas. Os scripts abaixo seguem a nomenclatura left e right, e podem ser visualizados abaixo. 9.1. Script configuracao-lxc.sh #!/bin/sh echo "Criando Bridges..." sleep 2 brctl addbr br-left brctl addbr br-right echo "nCriando dispositivos TAP..." sleep 2 tunctl -t tap-left tunctl -t tap-right echo "nAtribuindo IP e iniciando TAPs..." sleep 2 ifconfig tap-left 0.0.0.0 promisc up ifconfig tap-right 0.0.0.0 promisc up echo "nVinculando TAPs e Bridges..." sleep 2 brctl addif br-left tap-left ifconfig br-left up brctl addif br-right tap-right ifconfig br-right up echo "nCriando os Containers.." sleep 2 lxc-create -n left -f lxc-left.conf lxc-create -n right -f lxc-right.conf echo "nScript executado! Para iniciar os containers," echo "ndigite os comandos abaixo em shells separados:" echo "nsudo lxc-execute -n right /bin/bash" echo "nsudo lxc-execute -n left /bin/bashn" 9.2. Script 2 - remocao-lxc.sh #!/bin/sh echo "nDestruindo os Containers...n"
  34. 34. sleep 2 lxc-destroy -n left lxc-destroy -n right echo "nDesativando Bridges...n" sleep 2 ifconfig br-left down ifconfig br-right down echo "nRemovendo Dispositivos TAPs das Bridges...n" sleep 2 brctl delif br-left tap-left brctl delif br-right tap-right echo "nDestruindo as Bridges...n" sleep 2 brctl delbr br-left brctl delbr br-right echo "nDesativando TAPs...n" sleep 2 ifconfig tap-left down ifconfig tap-right down echo "nRemovendo Taps...n" sleep 2 tunctl -d tap-left tunctl -d tap-right

×