O documento propõe uma avaliação de simuladores para redes veiculares ad hoc (VANETs) com foco na implementação de aplicações de gerenciamento baseadas em tecnologia peer-to-peer (P2P). O autor descreve os tipos de simuladores VANET e aplicações de gerenciamento, e realizou testes com simuladores e métricas para avaliar o suporte a aplicações P2P.

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. $ ./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. $ 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. 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. 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. 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. 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. 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. 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