Aplicações para Redes Veiculares
Tolerantes a Atrasos
José Jorge da Silva Nunes
Dissertação para obtenção do Grau de Mestre em
Engenharia Electrotécnica e de Computadores
Júri
Presidente: Prof. Doutor Nuno Cavaco Gomes Horta
Orientador: Prof. Doutor Paulo Rogério Barreiros d'Almeida Pereira
Co-orientador: Prof. Doutor António Manuel Raminhos Cordeiro Grilo
Vogal: Prof. Doutor Miguel Nuno Dias Alves Pupo Correia
Maio de 2013
i
Agradecimentos
A realização desta tese não teria sido possível sem o contributo do orientador da mesma,
Professor Doutor Paulo Rogério Barreiros d’Almeida Pereira que excedeu as minhas expectativas
mais optimistas, revelando um apoio inexcedível e sempre presente. Não poderia deixar de agradecer
ao Prof. Doutor António Manuel Raminhos Cordeiro Grilo pelo apoio prestado.
Um agradecimento muito especial à minha companheira de muitos anos e mãe do meu filho
pelo seu apoio nos momentos difíceis que tive de ultrapassar. Uma palavra para o meu filho que se
viu privado de alguns momentos com o pai. Estou ciente que este esforço será um exemplo e uma
motivação para ele.
Este trabalho foi parcialmente suportado por financiamento da FCT - Fundação para a
Ciência e a Tecnologia através do projecto MPSat (FCT Ref. PTDC/EEA-TEL/099074/2008).
ii
iii
Abstract
Vehicular Delay Tolerant Networks (VDTN) allow supporting communications in adverse conditions
where assured point-to-point connectivity solutions cannot guarantee communication. In adverse
conditions, frequent loss of connectivity, considerable latency and/or lateness are common. VDTN
also provide ease of communication in remote location areas where communication infrastructures are
inexistent.
A state of the art research study was performed to validate this work, including major reference
applications in this area of expertise.
A VDTN architecture with the DTN2 reference implementation in an ad-hoc supported network was
tested. Relevant scenario testing was conducted which led to choosing an epidemic routing protocol
as the best adapted to the aforementioned architecture. A vehicular delay tolerant network was
defined on which an email application with DTN2 support was tested.
Performance tests to the demonstrator of the vehicular delay tolerant network were conducted and
supported these work conclusions. Some suggestions for future work are also presented.
iv
v
Resumo
As Redes Veiculares Tolerantes a Atrasos (RVTA) permitem dar suporte a comunicações realizadas
em condições bastante adversas, onde as soluções utilizadas em redes com conectividade ponto a
ponto assegurada não conseguem garantir a comunicação. Condições adversas são aquelas onde se
verificam perdas frequentes de conectividade, grandes latências e/ou atrasos. Estas redes são
também utilizadas para providenciar facilidades de comunicação em zonas remotas onde não existe
uma infra-estrutura de comunicações.
Para fundamento deste trabalho, realizou-se um estudo sobre o estado da arte, incluindo as principais
aplicações de referência nesta área de conhecimento.
Testou-se uma arquitectura para RVTA com a implementação de referência DTN2 suportada numa
rede ad hoc. Efectuaram-se testes aos cenários que nos pareceram mais relevantes o que nos levou
a escolher o protocolo de encaminhamento epidémico como aquele que melhor se adaptava a essa
arquitectura. Definiu-se assim um demonstrador de redes veiculares tolerantes a atrasos onde se
testou uma aplicação de correio electrónico suportada em DTN2.
Realizaram-se testes de performance ao demonstrador de redes veiculares tolerantes a atrasos que
suportaram as conclusões deste trabalho. São ainda apresentadas algumas sugestões para trabalho
futuro.
vi
vii
Keywords
Vehicular Delay-Tolerant Networks, Ad hoc networks, Epidemic routing protocol, Demonstrator.
viii
ix
Palavras-Chave
Redes Veiculares Tolerantes a Atrasos, Redes ad hoc, protocolo de encaminhamento epidémico,
Demonstrador.
x
xi
Índice
AGRADECIMENTOS ............................................................................................................................... I
ABSTRACT ............................................................................................................................................ III
RESUMO ................................................................................................................................................. V
KEYWORDS ......................................................................................................................................... VII
PALAVRAS-CHAVE .............................................................................................................................. IX
ÍNDICE .................................................................................................................................................... XI
LISTA DE FIGURAS ............................................................................................................................ XIII
LISTA DE TABELAS ............................................................................................................................XV
LISTA DE ABREVIATURAS...............................................................................................................XVII
I. INTRODUÇÃO ................................................................................................................................ 1
A. MOTIVAÇÃO ................................................................................................................................... 1
B. OBJECTIVOS .................................................................................................................................. 1
C. RESULTADOS ................................................................................................................................. 1
D. ESTRUTURA DO DOCUMENTO .......................................................................................................... 2
II. ESTADO DA ARTE ......................................................................................................................... 3
A. CONTEXTO .................................................................................................................................... 3
B. DEFINIÇÃO DE RTA (DTN) ............................................................................................................. 3
C. DEFINIÇÃO DE RVTA (VDTN) ........................................................................................................ 4
D. ARQUITECTURA E PROTOCOLOS DE DTN ........................................................................................ 4
1. Protocolo Bundle ..................................................................................................................... 5
E. PROJECTOS EXISTENTES ................................................................................................................ 5
1. Kiosk Net ................................................................................................................................. 6
2. Diesel Net ................................................................................................................................ 7
3. VDTN ....................................................................................................................................... 8
4. EMMA .................................................................................................................................... 10
5. Drive-Thru Internet ................................................................................................................ 10
6. C2C-CC ................................................................................................................................. 11
7. TomTom ................................................................................................................................ 12
8. Drive-IN .................................................................................................................................. 13
9. Bytewalla ............................................................................................................................... 14
F. IMPLEMENTAÇÕES DE REFERÊNCIA ............................................................................................... 15
G. ENCAMINHAMENTO....................................................................................................................... 16
III. ARQUITECTURA .......................................................................................................................... 19
A. IMPLEMENTAÇÕES DE REFERÊNCIA AVALIADAS .............................................................................. 19
1. KioskNet ................................................................................................................................ 19
2. Vlink ....................................................................................................................................... 19
3. Postelation ............................................................................................................................. 20
4. Haggle ................................................................................................................................... 20
5. DTN2 ..................................................................................................................................... 20
6. Resumo das implementações de referência avaliadas ......................................................... 20
B. SOLUÇÃO PROPOSTA ................................................................................................................... 20
1. Arquitectura proposta para o demonstrador de redes veiculares tolerantes a atrasos ........ 22
IV. AVALIAÇÃO DA DTN2 ................................................................................................................. 27
A. CENÁRIOS ESCOLHIDOS ............................................................................................................... 27
xii
B. CONFIGURAÇÃO DO DAEMON DTN2 EM FUNÇÃO DO CENÁRIO ESCOLHIDO ...................................... 28
C. TESTE AOS CENÁRIOS ESCOLHIDOS .............................................................................................. 35
1. Teste ao cenário 1 ................................................................................................................. 35
2. Teste ao cenário 2 ................................................................................................................. 36
3. Teste ao cenário 3 ................................................................................................................. 37
4. Teste ao cenário 4 ................................................................................................................. 38
5. Teste ao cenário 5 ................................................................................................................. 39
6. Teste ao cenário 6 ................................................................................................................. 40
7. Teste ao cenário 7 ................................................................................................................. 41
8. Teste ao cenário 8 ................................................................................................................. 42
D. CONCLUSÕES .............................................................................................................................. 43
V. APLICAÇÃO DE CORREIO ELECTRÓNICO .............................................................................. 45
A. DESCRIÇÃO DA APLICAÇÃO DE CORREIO ELECTRÓNICO .................................................................. 45
B. TESTES E AVALIAÇÃO ................................................................................................................... 47
VI. CONCLUSÃO................................................................................................................................ 53
A. CONCLUSÕES .............................................................................................................................. 53
B. TRABALHO FUTURO ..................................................................................................................... 54
REFERÊNCIAS ..................................................................................................................................... 55
ANEXO 57
xiii
Lista de figuras
Figura 1 - O protocolo Bundle na pilha de protocolos [5] ........................................................................ 5
Figura 2 - Um percurso de autocarros e Protocolos DTN providenciam o gateway entre os quiosques
e a Internet numa cidade vizinha. [1] ...................................................................................................... 6
Figura 3 - O Protocolo de Gestão de Conexões Oportunísticas (OCMP), corre no topo da camada
bundle de modo a permitir a transferência de e-mail [1] ......................................................................... 7
Figura 4 - Arquitectura por camadas de IP sobre VDTN ........................................................................ 9
Figura 5 - Arquitectura Drive-Thru Internet [1] ...................................................................................... 11
Figura 6 - Arquitectura de referência Car2Car [1] ................................................................................. 12
Figura 7 - Arquitectura da solução Bytewalla.[18] ................................................................................. 14
Figura 8 - Arquitectura por camadas da solução Bytewalla.[18] ........................................................... 15
Figura 9 - Arquitectura proposta para o demonstrador de redes veiculares tolerantes a atrasos ........ 22
Figura 10 - Mula (Robot e Netbook) ...................................................................................................... 22
Figura 11 - Computador ligado à Internet - Gateway ............................................................................ 23
Figura 12 - Computador isolado – Quiosque ........................................................................................ 24
Figura 13 - Computador instalado no robot – “Mula” ............................................................................ 25
Figura 14 - Meio congestionado. Local: INESC, 5º piso ....................................................................... 28
Figura 15 - Meio livre. Local: Aldeia no Concelho de Sintra ................................................................. 28
Figura 16 - Ficheiro “dtn.conf” de configuração do DTN2 ..................................................................... 33
Figura 17 - Captura do tráfego de bundles de 50KB pelo software Wireshark. .................................... 36
Figura 18 - Captura do tráfego de bundles de 1KB pelo software Wireshark. ...................................... 36
Figura 19 - Resultados obtidos nos testes efectuados ao cenário 2. ................................................... 37
Figura 20 - Resultados obtidos nos testes efectuados ao cenário 3. ................................................... 38
Figura 21 - Resultados obtidos nos testes efectuados ao cenário 4. ................................................... 39
Figura 22 - Resultados obtidos nos testes efectuados ao cenário 5. ................................................... 40
Figura 23 - Resultados obtidos nos testes efectuados ao cenário 6. ................................................... 41
Figura 24 - Resultados obtidos nos testes efectuados ao cenário 7. ................................................... 42
Figura 25 - Resultados obtidos nos testes efectuados ao cenário 8. ................................................... 43
Figura 26 - O cliente de email Kmail ..................................................................................................... 45
Figura 27 - Envio de email através do Kmail......................................................................................... 46
Figura 28 - Resultados obtidos nos testes efectuados à solução de correio electrónico. .................... 48
Figura 29 - Resultados obtidos nos testes efectuados à solução de correio electrónico. .................... 49
Figura 30 - Resultados obtidos nos testes efectuados à solução de correio electrónico. .................... 50
xiv
xv
Lista de Tabelas
Tabela 1 - Implementações de referência avaliadas. ........................................................................... 21
Tabela 2 - Cenários avaliados. .............................................................................................................. 27
Tabela 3 - Cenário 1. ............................................................................................................................. 35
Tabela 4 - Cenário 2. ............................................................................................................................. 36
Tabela 5 - Cenário 3. ............................................................................................................................. 37
Tabela 6 - Cenário 4. ............................................................................................................................. 38
Tabela 7 - Cenário 5. ............................................................................................................................. 39
Tabela 8 - Cenário 6. ............................................................................................................................. 40
Tabela 9 - Cenário 7. ............................................................................................................................. 41
Tabela 10 - Cenário 8. ........................................................................................................................... 42
Tabela 11 - Cenários 6 e 8. ................................................................................................................... 47
Tabela 12 - Cenário avaliado no teste da aplicação de correio electrónico ......................................... 49
Tabela 13 - Desempenho dos computadores utilizados nos testes. .................................................... 50
xvi
xvii
Lista de abreviaturas
AU Application Unit
BAB Bundle Authentication Block
BAD Bundle Aggregation and De-Aggregation Layer
BSC Bundle Signaling Control Layer
BSP Bundle Security Protocol
C2C-CC Car to Car Communication Consortium
CCSDS Consultative Committee for Space Data Systems
CFCD Cellular Floating Phone Data
CFDP CCSDS File Delivery Protocol
CONDOR Command and Control, On-the-Move, Network, Digital, Over-the-horizon Relay
DOME Diverse Outdoor Mobile Environment
DOS Denial Of Service
DTN Disruption Tolerant Networking
DTNRG Delay-Tolerant Networking Research Group
EMMA Environmental Monitoring in Metropolitan Areas
ESB Extension Security Block
Extcl External convergence layer
GPRS General Packet Radio service
GPS Global Positioning System
GSM Global System for Mobile Communications
HTTP Hypertext Transfer Protocol
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
xviii
ION Interplanetary Overlay Network
IP Internet Protocol
IRTF Internet Research Task Force
ISP Internet Service Provider
ITS Intelligent Transportation Systems
LTP Licklider Transmission Protocol
LTP Licklider Transport Protocol
MAS Asynchronous Message Service
MORA Multi-Objective Robotic Assistance
MTU Maximum Transmission Unit
Norm Nack-Oriented Reliable Multicast
OBU On Board Unit
OCMP Opportunistic Communication Management Protocol
ONE Opportunistic Networking Environement
PC Personal Computer
PCB Payload Confidentiality Block
PCMP Persistent Connection Management Protocol
PDA Personal Digital Assistant
PDU Protocol Data Unit
PEP Performance Enhancing Proxies
PIB Payload Integrity Block
PKI Public-Key Infrastructure
PRoPHET Probalilistic Routing Protocol using History of Encounters and Transitivity
RAPID Resource Allocation Protocol for Intentional DTN
RF Rádio Frequência
xix
RFC Request For Comments
RSU Road-Side Unit
RTA Redes Tolerantes a Atrasos
RVTA Redes Veiculares Tolerantes a Atrasos
SMS Short Message Service
SMTP Simple Mail Transfer Protocol
TCL Tool Command Language
TCP Transmission Control Protocol
TKIP Temporal Key Integrity Protocol
TLS Transport Layer Security
UDP User Datagram Protocol
USB Universal Serial Bus
VANET Vehicular Ad-Hoc Network
VTDN Vehicular Delay Tolerant Networks
WEP Wired Equivalent Privacy
Wi-Fi Wireless Local Area Network
XML Extensible Markup Language
xx
1
I. Introdução
Esta tese aborda a temática das aplicações para Redes Veiculares Tolerantes a Atrasos. Estas redes
permitem dar suporte a comunicações realizadas em condições bastante adversas, tais como perdas
frequentes de conectividade, grandes latências e atrasos.
Foi efectuada uma análise ao estado da arte e através dela escolhida uma implementação de
referência, DTN2 (Implementação de referência dos protocolos de Redes Tolerantes a Atrasos). Com
base nessa implementação de referência, foi desenvolvido um demonstrador de redes veiculares
tolerantes a atrasos, definida uma arquitectura de comunicações para implementação de uma
aplicação de correio electrónico suportada em DTN2, bem como a avaliação do desempenho das
aplicações. Para o leitor mais curioso, recomenda-se a leitura do seguinte artigo referenciado em [1].
A. Motivação
Tendo um percurso profissional na área das Tecnologias de Informação e Comunicação, foi com
naturalidade que escolhi uma tese na área das redes de computadores. Sempre orientei a minha vida
com o objectivo de ajudar o próximo, especialmente as camadas mais desfavorecidas da população.
Numa sociedade em que a oferta de comunicações nos chega em múltiplas configurações, somos
levados a esquecer que há locais remotos no planeta onde não há infra-estruturas de comunicações
ao dispor da população. As soluções de redes tolerantes a atrasos oferecem a possibilidade de
fornecer às populações em zonas remotas do planeta serviços de comunicações de baixo custo.
B. Objectivos
Implementação de um demonstrador de redes veiculares tolerantes a atrasos, bem como a avaliação
do desempenho da aplicação implementada.
C. Resultados
Podemos enumerar os resultados obtidos com a realização desta tese da seguinte forma:
A criação de uma arquitectura de referência nas redes tolerantes a atrasos suportadas
em redes ad hoc, como base do demonstrador de redes veiculares tolerantes a atrasos.
2
O desenvolvimento de uma aplicação de correio electrónico, simples e de baixo custo,
mas eficiente, suportada em aplicações e sistemas abertos, como uma aplicação do
demonstrador de redes veiculares tolerantes a atrasos.
Análise de desempenho das soluções implementadas.
D. Estrutura do documento
O resto deste documento está organizado da forma seguinte. O capítulo 2 introduz o estado da arte
nesta área de conhecimento. O capítulo 3 analisa várias implementações DTN existentes, a
fundamentação da escolha da implementação utilizada e sua arquitectura. O capítulo 4 apresenta os
testes realizados para escolher a melhor forma de configurar a solução proposta. O capítulo 5
apresenta uma aplicação de exemplo para transferência de correio electrónico. O capítulo 6 mostra
as conclusões do trabalho realizado, bem como sugestões para trabalho futuro. Em anexo apresenta-
se a metodologia para instalar e configurar a solução proposta.
3
II. Estado da arte
Neste capítulo apresentam-se os conceitos principais das redes veiculares tolerantes a atrasos, tais
como a arquitectura, protocolos, bem como o estado da arte em termos de projectos e
implementações existentes.
A. Contexto
A necessidade de permanente contacto num mundo cada vez mais globalizado coloca questões e
desafios constantes. As Redes Tolerantes a Atrasos (DTN-Delay Tolerant Networks) [2] propõem-se
responder às seguintes situações no estabelecimento de comunicações:
Locais onde a conectividade é intermitente ou esparsa
Ligações com atrasos grandes e/ou variáveis
Elevadas taxas de erro
Grandes assimetrias na velocidade das ligações
Inexistência de conectividade extremo a extremo
Os protocolos habituais da Internet não são úteis nestas situações porque as falhas das linhas não
são tratadas convenientemente, fazendo os protocolos dar timeout e abortar, pois assumem uma
conectividade extremo a extremo permanente.
B. Definição de RTA (DTN)
Podemos definir as Redes Tolerantes a Atrasos como aquelas que permitem responder às
dificuldades enumeradas no ponto anterior, e que em face destas condicionantes conseguem
transmitir mensagens, aproveitando as oportunidades de contacto entre nós para fazer chegar os
dados das aplicações aos seus destinos.
Podemos ainda acrescentar que são redes que podem experimentar partições frequentes e longas,
em situações em que não existe nenhuma infra-estrutura que possa garantir conectividade
permanente. Exemplos de tais situações são: comunicações militares no campo de batalha,
comunicações para o espaço profundo, redes ad hoc entre veículos e em acções de salvamento em
áreas atingidas por catástrofes, redes de sensores, redes de rastreamento de animais selvagens e
redes de comunicações utilizador a utilizador em locais remotos onde não haja a infra-estrutura
necessária para implementação de uma rede de comunicações.
4
C. Definição de RVTA (VDTN)
Um caso específico das Redes Tolerantes a Atrasos são as Redes Veiculares Tolerantes a Atrasos,
que se podem definir como redes ad hoc e espontâneas sem uma organização definida onde veículos
providos de dispositivos de comunicação sem fios, cooperam entre si e com uma infra-estrutura
existente de modo a permitir a transmissão de mensagens que de outro modo seria difícil ou mesmo
impossível.
As redes veiculares têm aplicação em notificação de condições de tráfego, alerta de acidentes,
informação de locais de estacionamento livres, publicidade e para recolha de informação, por
exemplo defeitos do pavimento das estradas ou monitorização de poluição dos veículos. As DTN
veiculares (VDTN) também aparecem como uma alternativa para oferecer acesso Internet assíncrono
economicamente eficiente para zonas rurais remotas, possibilitando serviços que não são de tempo
real, tais como correio electrónico, correio de voz, acesso à web, telemedicina, monitorização do
ambiente e outras aplicações de recolha de informação. É muito mais barato implementar uma
solução de comunicações baseada em DTN do que uma solução apoiada numa rede de infra-
estrutura.
D. Arquitectura e protocolos de DTN
O DTN Research Group (DTNRG) [3], que pertence à Internet Research Task Force (IRTF), propôs
uma arquitectura [4] conjuntamente com protocolos de comunicação para DTN, destacando-se o
Bundle Protocol [5].
O conceito consiste em agregar toda a informação requerida para a transmissão da mensagem,
minimizando assim o número de trocas de informação necessárias, o que é crucial quando o tempo
de ida e volta (round-trip) é muito elevado. É incluído na bundle o timestamp de origem, o tempo de
vida, o seu tamanho e a sua classe de serviço.
Este protocolo inclui um mecanismo de transferência de custódia que responsabiliza cada nó pela
transmissão com sucesso da bundle ao nó seguinte. É útil nestes casos a utilização de
armazenamento persistente.
Os dados são armazenados nos nós da DTN, podendo o armazenamento ser ou não persistente,
esperando um contacto oportunístico para serem encaminhados até ao seu destino ou até o seu
período de vida útil expirar. Os conceitos da arquitectura DTN foram também estendidos para redes
veiculares. [6]
5
1. Protocolo Bundle
Na arquitectura das redes tolerantes a atrasos, é adicionada uma camada orientada à mensagem,
chamada Bundle Layer. Esta camada existe acima da camada de transporte (ou de outra) das redes
por si interconectadas (Figura 1). As unidades de dados da aplicação são transformadas pela Bundle
Layer em uma, ou mais, PDU’s chamadas bundle que são encaminhadas nos nós DTN.
O conceito consiste em agregar toda a informação requerida para a transmissão da mensagem,
minimizando assim o número de trocas de informação necessárias, o que é crucial quando o tempo
de ida e volta (round-trip time) é muito elevado. É incluído na bundle o timestamp de origem, o tempo
de vida, o seu tamanho e a sua classe de serviço.
Este protocolo inclui um mecanismo de transferência de custódia que responsabiliza cada nó pela
transmissão com sucesso da bundle ao nó seguinte. É útil nestes casos a utilização de
armazenamento persistente.
Aplicação Aplicação
Camada Bundle Camada Bundle Camada Bundle Camada Bundle
Transporte Transporte Transporte Transporte
Rede Rede Rede Rede
Figura 1 - O protocolo Bundle na pilha de protocolos [5].
E. Projectos existentes
Nas subsecções seguintes são apresentados os projectos que mais se destacam nas Redes
Veiculares Tolerantes a Atrasos, sendo ainda de salientar outros projectos que merecem uma breve
referência:
O projecto CarTel [7] pretende responder a alguns dos desafios que se apresentam nos
Transportes rodoviários. Com perto de mil milhões de veículos na estrada hoje e a duplicação
projectada para os próximos 15-20 anos, enfrentamos desafios prementes para a eficiência e
a segurança desta infra-estrutura. O projecto CarTel combina a computação móvel, redes de
sensores, redes sem fios e algoritmos de cruzamento de dados para identificação de
problemas nas estradas, correndo em servidores na nuvem para enfrentar esses desafios.
O projecto CONDOR [8]: Os sistemas de comunicações militares têm de se adaptar a
situações bastante limitativas, tais como inexistência de infra-estruturas fixas, largura de
banda limitada, ambientes de difícil propagação e ter capacidade de resposta rápida aos
6
pedidos dos utilizadores. O Corpo de Fuzileiros Norte-Americano está já a utilizar conceitos
DTN no seu projecto CONDOR (Command and Control, On-the-Move, Network, Digital, Over-
the-horizon Relay).
1. Kiosk Net
O projecto Kiosk Net [9] possibilita a utilização de quiosques Internet de baixo custo em zonas rurais
com serviços que não sejam de tempo real, tais como correio electrónico, web browsing, telemedicina
e pagamento de impostos. Como estes quiosques não têm uma ligação permanente à Internet, um
autocarro e protocolos DTN providenciam a gateway entre os quiosques e a Internet numa cidade
vizinha como exemplificado na figura seguinte:
Figura 2 - Um percurso de autocarros e Protocolos DTN providenciam o gateway entre
os quiosques e a Internet numa cidade vizinha. [1]
As aplicações do utilizador comunicam através dos protocolos DTN, gerando bundles que são
guardadas em armazenamento persistente até que o autocarro passe pela aldeia. Nesse momento,
os agregados são transferidos para o agente DTN no autocarro e transportados para a cidade para
serem entregues numa gateway Internet. A figura seguinte mostra um exemplo destes procedimentos
para o envio de correio electrónico.
Cidade
Aldeia
Quiosque
Hub (Ponto de acesso à Internet)
Ponto de acesso Móvel
Aldeia
Quiosque
Aldeia
Quiosque
7
Cliente email
Controlador do
quiosque
Cliente de correio electrónico correndo num terminal
Autocarro
Internet
Proxy
Servidor de email
Legacy
OCMP SMTP plugin
OCMP deamon
DTN agent
DTN agent on bus
DTN agent
DTN agent at gateway
OCMP deamon
OCMP SMTP plugin
HELO
FROM: src
TO: dst
Data
QUIT
OK Bulk Data
AppData: SMTP, src, dst
Armazenamento
Persistente
DTN bundles
Delivery Acks
Delivery Acks
Delivery Acks
DTN bundles
Bulk Data
AppData
Armazenamento
Persistente
Create SMTP plugin
Reassemble
HELO
QUIT
OK Delivery
Ack
Gateway
Figura 3 - O Protocolo de Gestão de Conexões Oportunísticas (OCMP), corre no topo
da camada bundle de modo a permitir a transferência de e-mail [1].
Um protocolo de aplicação chamado Protocolo de Gestão de Conexões Oportunísticas (OCMP), corre
no topo da camada bundle, providenciando uma interface entre o cliente de correio electrónico e o
agente DTN no quiosque e entre o agente DTN no gateway e um servidor de correio electrónico.
Esta solução caracteriza-se por ser de rápida implementação, baixo consumo de energia e usar
software livre o que se reflecte no seu baixo custo. É de salientar também a possibilidade de
utilização de outros protocolos e ligações à Internet.
Podemos concluir que o projecto Kiosk Net desenvolveu uma solução que prova que os protocolos
DTN podem aproveitar movimentos periódicos de autocarros para transferir informação a baixo custo
entre locais isolados, oferecendo assim serviços de Internet a locais isolados.
2. Diesel Net
O projecto DieselNet [10] consiste numa rede de 40 autocarros que cobrem uma área de 150 milhas
quadradas ao redor da cidade de Amherst, nos USA. Cada um está equipado com um PC (Personal
Computer) com GPS (Global Positioning System), uma carta 802.11abg, um ponto de acesso sem
fios 802.11g, modems USB (Universal Serial Bus) sem fios 3G e um modem RF (Radio Frequência)
da banda 900MHz. O ponto de acesso permite que outros autocarros estabeleçam conexões 802.11,
dando-lhes assim acesso à Internet através de uma das interfaces de rádio externos. A interface Wi-
Fi (wireless local area network) é usada para a ligação a outros pontos de acesso, quer de infra-
estrutura quer de outros autocarros.
8
É importante referir um outro tipo de nós, as Throwboxes, nós wireless que podem actuar como
retransmissores, criando oportunidades de contacto adicionais para os autocarros envolvidos no
projecto Diesel Net.
Outra solução importante é o das redes em malha (mesh networks) associadas a este projecto.
Consistem em 26 pontos de acesso Wi-Fi instalados em locais estratégicos da cidade que
providenciam conectividade com a rede de fibra óptica local.
Estas três soluções fazem parte de um ambiente de ensaio, chamado DOME (Diverse Outdoor
Mobile Environment), que abrange desde áreas urbanas a áreas rurais com escassa conectividade.
Trata-se de um poderoso ambiente para a pesquisa de conceitos DTN como, por exemplo,
encaminhamento, gestão de energia, arquitectura do sistema e de aplicações. É de realçar também a
disponibilização de registos dos movimentos dos autocarros e dos contactos, o que é de grande
importância para a investigação de soluções DTN.
Aplicações interessantes deste projecto são a melhoria do web browsing para os utilizadores dos
autocarros assim como o suporte técnico a projectos de monitorização ambiental.
Os principais desenvolvimentos do projecto DieselNet foram novos protocolos de encaminhamento e
aplicações para DTN’s e a criação de um ambiente de ensaio de referência.
3. VDTN
O projecto de Redes Veiculares Tolerantes a Atrasos [11] propõe uma arquitectura por camadas para
as VDTN’s, onde a camada bundle é posicionada abaixo da camada de rede ao invés de estar por
cima da camada de transporte. O objectivo desta alteração é adoptar um paradigma de IP over
VDTN, onde os datagramas IP (Internet Protocol) são agrupados em bundles para serem
encaminhados em conjunto dentro da VDTN. Isto resulta num menor processamento de pacotes,
assim como em menos decisões de encaminhamento, o que se pode traduzir numa menor
complexidade e economias de custos e de energia.
Esta arquitectura usa sinalização fora de banda, através da separação dos planos de controlo e
dados, como ilustrado na figura seguinte:
9
Camada de Aplicação
Camada de Transporte
Camada de Rede
Camada BAD Camada BSC
Camada MAC Camada MAC
Camada Física Camada Física
Plano de Dados Plano de Controlo
Figura 4 - Arquitectura por camadas de IP sobre VDTN.
A camada BAD (Agregação e Desagregação da Bundle) agrega as mensagens IP que lhe chegam
em mensagens bundle que são transferidas no plano de dados e desagregadas no destino. A
camada BSC (Sinalização e Controlo da Bundle) providencia um protocolo de sinalização para uso na
fase de estabelecimento de conexão. Os nós trocam informação de controlo para partilha das suas
características (espaço em buffer disponível, bundles que têm, trajectória, etc.) e para prepararem a
transferência de dados a ocorrer no plano de dados. Esta camada inclui ainda algoritmos de
encaminhamento.
Foram especificados três tipos de nós:
Terminais – providenciam a conexão com os utilizadores finais
Móveis – transportam as mensagens entre os nós terminais
Retransmissores – nós fixos localizados em cruzamentos para aumentar a entrega de mensagens. A
sua configuração é simples pois só precisam de implementar as três camadas inferiores da pilha de
protocolos.
Foi implementado um protótipo usando um robot equipado com um PDA (Personal Digital Assistant)
emulando um terminal móvel. Os nós terminais e retransmissores foram emulados através de
computadores portáteis e de secretária. A sinalização fora de banda é processada através de uma
ligação Bluetooth persistente. Sempre que necessário, é activada uma ligação Wi-Fi para a
transferência de bundles de dados.
Esta configuração contribui para poupar energia o que é importante no caso dos nós retransmissores.
O protótipo permite o estudo e a avaliação do comportamento dos diferentes nós e dos seus
mecanismos correspondentes de encaminhamento, cache e transporte. O ambiente de ensaio
permite ainda o desenvolvimento de novos protocolos de serviços e a comparação dos seus
resultados com os obtidos por simulação.
O projecto VDTN mostrou que um plano de controlo separado pode optimizar a utilização dos
recursos do plano de dados, nomeadamente armazenamento, largura de banda e poupança de
10
energia. Este projecto também se debruçou sobre o uso de políticas de calendarização e descarte,
diferenciação de tráfego, localização de nós, nós retransmissores fixos, encaminhamento geográfico
e mecanismos de cache para incremento na eficiência das comunicações.
4. EMMA
O projecto EMMA (Environmental Monitoring in Metropolitan Areas) [12] é um projecto de
monitorização ambiental em áreas urbanas que usa uma rede pública de autocarros para monitorizar
a poluição. Os autocarros têm um GPS e vários sensores detectores de poluição que inspeccionam
continuamente o ambiente. Os dados recolhidos são transmitidos através de uma pilha DTN para um
servidor central onde os dados são analisados.
EMMA considera dois tipos de nós DTN estacionários: gateways e painéis inteligentes. Os primeiros
fornecem a interface entre os autocarros e a rede de gestão de tráfego, enviando bundles de dados
com os resultados das medições para o servidor de análise através da rede de gestão de tráfego.
Além disso, mensagens de controlo para os aparelhos de gestão de tráfego ou para os écrans de
informação são encaminhadas da rede de gestão para a DTN. Painéis inteligentes mostram
informação sobre a concentração actual de poluentes. Os valores das medições são o resultado dos
veículos que passam e do processamento de dados feito autonomamente pelo painel. O painel de
écrans pode também receber mensagens dum centro de controlo via DTN mostrando, por exemplo,
informações de tráfego. Estes painéis são também retransmissores de modo a aumentarem a
velocidade do processo de distribuição de bundles dentro da DTN.
Este projecto mostrou que uma rede de transportes públicos pode fazer parte de uma solução
economicamente eficiente para monitorização ambiental, gestão de tráfego e de serviços de
informação.
Embora este projecto seja similar a DieselNet em vários aspectos, diferencia-se por ser um sistema
de informação distribuído onde os dados das medições são transmitidos através de uma rede.
5. Drive-Thru Internet
O projecto Drive-Thru Internet [13] tem como objectivo fornecer acesso à Internet para veículos,
suportando-se na conectividade intermitente destes com pontos de acesso ao longo da estrada. O
conceito de Proxies de Alta Performance (PEP-Performance Enhancing Proxies) é usado para
ultrapassar os efeitos da conectividade intermitente.
A figura seguinte mostra a arquitectura do sistema:
11
Browser
Web
Cliente
Drive-
Thru
Proxy Drive-Thru Servidor
Web
HTTP HTTP+X HTTP+X HTTP HTTP
PCMP PCMP
TCP TCP TCP TCP TCP
IP IP IP IP IP
Nó Movél 802.1
Radio
Proxy Drive-Thru Backbone
Internet
Servidor
Figura 5 - Arquitectura Drive-Thru Internet [1].
Os nós móveis são equipados com clientes proxy que retransmitem as interacções entre as camadas
de transporte e de aplicação ao correspondente Proxy Drive-Thru através do ponto de acesso
wireless mais próximo. Estes Proxy Drive-Thru estão directamente ligados ao backbone Internet. A
persistência da sessão, apesar das desconexões é garantida pelo Protocolo de Gestão de Conexões
Persistentes (PCMP-Persistent Connection Management Protocol), um protocolo da camada de
sessão que trabalha baseado em conexões IP. Os Proxy Drive-Thru podem executar funções da
camada de aplicação, tais como pesquisa preditiva de endereços web ou correio electrónico de modo
a incrementar o desempenho. É por isto que a camada HTTP (Hypertext Transfer Protocol) é
estendida (HTTP+X) na figura acima. Um aspecto menos positivo desta arquitectura é o uso de TCP
(Transmission Control Protocol) para conexões de curta duração, o que pode causar um excessivo
overhead.
O projecto Drive-Thru Internet mostrou que uma camada de sessão acima da camada de transporte
pode manter de forma persistente uma sessão de aplicação apesar da existência de desconexões e
novas ligações.
6. C2C-CC
O consórcio de comunicações carro a carro, C2C-CC (Car 2 Car Communication Consortium) [14]
tem como objectivo a normalização de interfaces e protocolos das comunicações sem fios entre
veículos e o ambiente onde se movem, de modo a que todos os veículos, independentemente dos
fabricantes consigam comunicar entre si e com unidades fixas instaladas ao longo das estradas. A
figura seguinte mostra a arquitectura proposta:
12
In-Vehicle Domain
Infrastructure Domain
AU Application Unit GW Gateway OBU On Board Unit HS Hot Spot
RSU Road Side Unit
Access Network
Server Node
AU
OBU
AU
OBU AU
OBU
RSU RSU
GW
HS
Ad Hoc Domain
Internet
IEEE 802.11p*
IEEE 802.11a/b/g
cellular
radio
Figura 6 - Arquitectura de referência Car2Car [1].
É composta por três domínios distintos: Inter-veículos, ad hoc e infra-estrutura. O domínio inter-
veículos consiste numa rede lógica composta por uma unidade a bordo (OBU-On Board Unit) e uma,
ou mais, unidades aplicacionais (AU-Application Unit). Estas unidades aplicacionais são tipicamente
dispositivos dedicados que executam uma ou mais aplicações e que utilizam as capacidades de
comunicação das unidades a bordo. Podem ser uma parte integrante do veículo ou um computador
portátil, um PDA ou uma consola de jogos, por exemplo. O domínio ad hoc ou VANET (Vehicular Ad-
Hoc Network) é composto por OBU’s e unidades fixas ao longo da estrada, designadas por RSU
(Road-Side Unit). Um OBU é equipado no mínimo com um dispositivo de comunicações sem fio de
curto alcance dedicado à segurança na estrada, podendo ainda ter outros dispositivos de
comunicação. A principal função de um RSU é o aumento da segurança na estrada. Um RSU pode
ser ligado a uma rede da infra-estrutura, que por sua vez estará ligada à Internet. Isto possibilita que
os RSU permitam aos OBU’s o acesso a essa rede e consequentemente à Internet. Outra forma de
os OBU’s se ligarem à Internet é através de pontos de ligação (Hot Spots), quer eles sejam privados,
públicos ou que façam parte da infra-estrutura de um ISP (Internet Service Provider). Outra
possibilidade é obterem essa ligação através de redes celulares, caso os OBU’s tenham equipamento
para tal, o que só é previsto para aplicações não relacionadas com a segurança na estrada.
7. TomTom
O serviço TomTom HD Traffic [15] que abrange navegação e informação de tráfego está já disponível
em vários países europeus. Apesar de não usar protocolos DTN, é um exemplo de um sistema de
informação para redes veiculares quase em tempo real que está comercialmente disponível.
Este sistema utiliza um canal bidireccional GPRS (General Packet Radio Service) para entregar
informação de tráfego e outras informações importantes ao receptor instalado no veículo com uma
periodicidade de três minutos. Esta informação possibilita uma estimativa precisa dos tempos de
viagem que pode ser usada para seleccionar a rota mais rápida. O núcleo desta tecnologia de recolha
13
de dados de tráfego é um sistema celular telefónico de dados flutuantes (CFCD-Cellular Floating
Phone Data) que se baseia nos dados de sinalização da rede GSM (Global System for Mobile
Communications) do operador, que faz ainda uso de dados GPS e de informação fornecida por
terceiros, como por exemplo as autoridades locais e sistemas de informação existentes nas estradas.
O CFCD baseia-se nas alterações das medições de Avanço de Tempo quando um telemóvel GSM
tem uma chamada activa. O Avanço de Tempo consiste na sincronização da transmissão nas
chamadas telefónicas através medição da distância entre o telemóvel e a estação base à qual está
ligado. Esta característica permite a triangulação entre o telemóvel, a estação base e a rede de
estradas. Um mecanismo de consolidação de dados agrega a informação das várias fontes com a
informação do histórico, rejeitando também as anomalias que possam ocorrer neste processo.
É expectável que no futuro os veículos automóveis tenham capacidades de comunicação que
possibilitem a existência de um vasto conjunto de aplicações, algumas delas a aparecerem na
actualidade. Os desafios envolvidos no desenvolvimento destas tecnologias abrangem todas as
camadas de protocolo, da camada física de rádio até à de aplicação. Importa salientar que devido à
grande mobilidade dos nós, o uso de mecanismos tolerantes a atrasos é um aspecto muito
importante e que deve ser considerado.
8. Drive-IN
O objectivo do projecto Drive-In [16] é a investigação de como a comunicação inter-veículos pode
incrementar a experiência de utilização e a eficiência global dos veículos e da utilização das estradas.
O âmbito abrange as fundações e as aplicações da comunicação inter-veículos.
Serão desenvolvidos conceitos, metodologias e tecnologias em três áreas chave: Protocolos VANET
Geo-Optimizados, encaminhamento inteligente e cooperativo inter-veículos e aplicações e serviços
para VANET’s. Esta pesquisa propõe-se também desenvolver simulações realísticas em larga escala
e experiências reais em ambientes urbanos. A grande maioria de projectos existentes nesta área é
impulsionada pela indústria automóvel e focam-se no incremento dos standards de segurança através
da comunicação inter-veículos com requisitos exigentes em termos de qualidade de serviço.
Considerando que o incremento da segurança, embora importante, é apenas uma de muitas
oportunidade oferecidas pelas tecnologias VANET, o projecto Drive-In foca-se na optimização do
fluxo de tráfego e em aplicações de informação e entretenimento, que até agora receberam muito
menos atenção tanto da comunidade científica como dos maiores fabricantes mundiais. Esta
abordagem permite-nos ultrapassar os exigentes requisitos impostos para os standards de segurança
e explorar um grande leque de possibilidades entre mobilidade, navegação, cooperação, largura de
banda e atraso, que irão permitir novas e estimulantes experiências de utilização tanto para o
condutor como os passageiros.
14
9. Bytewalla
O projecto Bytewalla [17] tem como objectivo a conectividade de locais remotos sem uma ligação
persistente à Internet ou sem qualquer infra-estrutura de comunicações através de uma DTN. O
conceito base é o aproveitamento das deslocações dos habitantes às cidades, ou outras zonas
providas de infra-estruturas de comunicações com ligação à Internet, para transportarem informação
nos seus telemóveis Android. Salienta-se a continuidade desde projecto, que já vai na sua quinta
versão, provando assim a validade dos conceitos que lhe estão inerentes.
É de referir também a utilização desta solução em redes de sensores.
Este projecto constitui um marco nas soluções para DTN, pois implicou a portabilidade da
implementação DTN2 para o ambiente Android.
Figura 7 - Arquitectura da solução Bytewalla [18].
A figura 7 representa a arquitectura da solução Bytewalla, podendo ver-se a infra-estrutura
necessária na aldeia remota, um ponto de acesso remoto e um servidor de correio electrónico que
também é um servidor proxy. A transferência de informação realiza-se pela deslocação física dos
telemóveis Android entre a aldeia e a rede de uma cidade próxima. Na referida cidade existe uma
infra-estrutura composta por um ponto de acesso remoto e um servidor de correio que também é uma
gateway para a Internet, possibilitando assim o envio de correio electrónico para qualquer utilizador.
15
Figura 8 - Arquitectura por camadas da solução Bytewalla [18].
A figura 8 mostra a arquitectura por camadas da solução Bytewalla, verificando-se uma arquitectura
idêntica à da implementação de referência DTN2, apenas com a particularidade da portabilidade para
um ambiente Android de modo a poder ser possível a utilização de telemóveis Android para o
transporte de informação. A opção por este ambiente deve-se ao facto de ser um sistema aberto e à
sua popularidade.
F. Implementações de referência
A implementação de referência do protocolo Bundle é chamada DTN2 [19]. Oferece uma consola TCL
(Tool Command Language) [20] flexível e interfaces XML (Extensible Markup Language) com
aplicações externas. A DTN2 pode suportar opcionalmente o protocolo de segurança bundle que
possibilita autenticação e/ou protecção da integridade das bundles transmitidos, se isso for requerido
pela aplicação. As bundles podem ser transmitidas através de camadas de transporte IP e de várias
camadas de ligação de dados como Ethernet e Bluetooth utilizando como protocolos de transporte
UDP ou TCP A DTN2 implementa camadas de convergência que fazem a interface entre a camada
bundle e as camadas de transporte. A DTN2 fornece ainda mecanismos de encaminhamento para
envio das bundles para o seu destino, incluindo vários mecanismos de encaminhamento. Os que nos
parecem mais importantes são: i) um algoritmo de encaminhamento fixo baseado em rotas pré-
configuradas; ii) encaminhamento epidémico que envia as bundles para todos os nós que encontrar;
e iii) o PRoPHET (Probalilistic Routing Protocol using History of Encounters and Transitivity). A
multiplicidade de mecanismos de encaminhamento é uma prova da sua flexibilidade. Estes
mecanismos serão abordados em maior detalhe no ponto G – Encaminhamento. Como exemplos de
implementações temos o dtnping – para verificar a operacionalidade da rede, dtnsend e dtnrcv – para
enviar e receber bundles, e dtncp e dtncp - para enviar e receber ficheiros.
16
É de salientar que a DTN2 tem uma ferramenta de simulação em desenvolvimento. Os scripts da
linguagem TCL permitem a criação de nós e ligações, a geração de tráfego, configurar a simulação e
a obtenção de estatísticas.
A ION (Interplanetary Overlay Network) [21]é também uma implementação do protocolo bundle, LTP
(Licklider Transmission Protocol) [22], CFDP (CCSDS File Delivery Protocol) [23] e AMS
(Asynchronous Message Service) [24] O CFPD é um serviço da camada de aplicação que faz
segmentação, transmissão, recepção, assemblagem e entrega de ficheiros de uma forma tolerante a
atrasos. Mas é um serviço da camada de aplicação para distribuição de mensagens baseado na
publicação/subscrição ou um modelo cliente/servidor. A ION foi desenhada para possibilitar a
inserção, a baixo custo, das funcionalidades DTN em sistemas embebidos, tais como naves espaciais
robotizadas. A ION implementa vários adaptadores de camada de convergência: TCP, UDP (User
Datagram Protocol), serviço de retransmissão de bundles e LTP.
A IBR-DTN é uma implementação muito leve, modular e altamente portável do Bundle Protocol
desenhada para sistemas embebidos que corram OpenWRT (um firmware para routers baseado em
Linux) ou Android. Inclui suporte para as camadas de convergência TCP, UDP e providenciando
ainda um suporte experimental para implementações DTN da Internet. Reclama compatibilidade total
com a especificação do protocolo de segurança Bundle. Suporta encaminhamento baseado em
tabelas, assim como agentes de descoberta de nós em TCP e UDP, vizinhança IP e encaminhamento
epidémico.
O simulador ONE (Opportunistic Networking Environement) [25] é um simulador desenvolvido em
Java, especialmente concebido para a análise de encaminhamento DTN e de protocolos de
aplicação. São de salientar as suas capacidades na implementação de vários cenários DTN, incluindo
a mobilidade e a geração de eventos, troca de mensagens, noções básicas sobre consumo de
energia, visualização e análises, interfaces para importação e exportação de registos de mobilidade,
acontecimentos e mensagens. São suportados os seguintes protocolos de encaminhamento: 1-First
Contact, 2-PRoPHET, 3-Direct Delivery, 3-Spray and Wait, 5-Epidemic e 6-MaxProp. Estes protocolos
encontram-se detalhados na secção Encaminhamento. Os algoritmos e regras que geram os
caminhos feitos pelos movimentos dos nós são definidos através de modelos de mobilidade. Estão
incluídos no simulador três tipos de modelos de modelos de mobilidade: 1-Movimento aleatório, 2-
Movimento baseado no comportamento humano, 3-Movimento pseudo-aleatório restringido por um
mapa.
G. Encaminhamento
O protocolo bundle não define como se realiza o encaminhamento entre os nós cingindo-se apenas
ao envio das bundles. As características de plano de controlo permanecem por definir. Para o
17
encaminhamento existem várias soluções com abordagens diferentes. Iremos abordá-las
resumidamente, podendo ser encontrada informação mais detalhada em [26].
Um protocolo simplista é o Direct Delivery, no qual o nó que origina a mensagem transporta-a até se
encontrar com o seu destino, entregando-lhe directamente a mensagem.
No protocolo First Contact, os nós enviam as mensagens para o primeiro nó que encontram, o que
resulta numa busca aleatória pelo destino final.
O protocolo Spray and Wait, gera várias cópias da mesma mensagem. No seu modo de
funcionamento normal entrega uma cópia a cada um dos seus primeiros n contactos; no modo binário
entrega metade das cópias a cada contacto. Quando resta apenas uma cópia, é apenas entregue ao
destinatário.
O encaminhamento Epidemic replica as mensagens para todos os nós que ainda não a tenham. Se o
espaço de armazenamento das mensagens nos nós fosse ilimitado e os contactos entre os vários nós
fossem suficientemente longos, o atraso de entrega seria minimizado e o rácio de entrega
maximizado. Como isto não é acontece na realidade, o encaminhamento Epidemic desperdiça
espaço de armazenamento e largura de banda quando comparado com outros protocolos. Salienta-
se que na versão actual deste encaminhamento, que se encontra na versão 2.9.0 da DTN2, o nó de
origem irá receber também cópias das mensagens transmitidas.
O encaminhamento MaxProp envia a mensagem para todos os nós, mas assim que uma cópia é
entregue ao destinatário, desencadeia um procedimento para a apagar em todos os outros nós. Uma
característica interessante é o envio para outros nós numa ordem específica, tendo em conta o
número de saltos entre nós e as probabilidades de entrega das mensagens baseadas em
acontecimentos anteriores.
No encaminhamento PRoPHET o nó inicial transmite a mensagem para um nó vizinho quando ele
estima que esse vizinho tenha maior probabilidade de entregar a mensagem, baseando-se as
estimativas em encontros anteriores entre nós.
O encaminhamento RAPID (Resource Allocation Protocol for Intentional DTN) optimiza métricas de
encaminhamento específicas, tais como atraso de entrega no pior caso, ou o número de pacotes
entregues num espaço de tempo.
O encaminhamento MORA (Multi-Objective Robotic Assistance) aprende padrões com a estrutura dos
movimentos dos nós, usando esta informação para optimizar o encaminhamento de mensagens.
18
19
III. Arquitectura
Neste capítulo avaliaram-se algumas implementações de referência e definiu-se uma proposta de
arquitectura para o demonstrador de redes veiculares tolerantes a atrasos.
A. Implementações de referência avaliadas
1. KioskNet
A solução KioskNet é bastante interessante mas foi descontinuada. Face à reduzida documentação
para instalação e análise e por indicação do professor Keshav, mentor do projecto, sugerindo a
utilização do Vlink, não se fez uma análise aprofundada da mesma.
2. Vlink
A solução Vlink é a herdeira do KioskNet mas seguiu uma aproximação radicalmente diferente para a
problemática das DTN’s.
No entanto é de referir alguns aspectos interessantes da solução, tais como:
Key link - Uso de canetas USB, um acessório informático bastante popular e cuja relação
capacidade/custo não pára de aumentar.
SMS link - Uso de um link SMS (Short Message Service) através do envio de SMS por um
telemóvel.
TCP link – uma forma de permitir a comunicação através de links não fiáveis.
Salienta-se ainda a possibilidade de através de um sistema cliente ter acesso a serviços de correio
electrónico da Internet como o Hotmail e o Gmail.
A implementação desta solução foi realizada em Java ao invés da aplicação de referência DTN2, em
C e C++.
20
3. Postelation
A solução Postelation é uma implementação DTN bastante interessante, preparada para o ambiente
Windows, disponibilizado até um http proxy. No entanto, impossibilita a sua utilização num sistema
isolado, pois obriga ao registo online dos nós na Viagenie, empresa que desenvolveu a solução.
4. Haggle
A implementação Haggle é interessante, mau grado não ser uma aplicação DTN, pois não faz uso do
protocolo bundle. É uma aplicação que gere contactos oportunísticos com base num mecanismo de
publicação/subscrição. Utiliza um encaminhamento pseudo-epidémico por grupos de interesse. Não
garante comunicações ponto a ponto.
5. DTN2
A solução DTN2 é a implementação de referência do protocolo Bundle, já descrita na secção 2.6.
6. Resumo das implementações de referência avaliadas
Na Tabela 1 apresenta-se uma comparação dos aspectos mais significativos das implementações
analisadas.
B. Solução proposta
Optou-se pela utilização da implementação DTN2 devido à sua flexibilidade, maturidade e ao facto de
disponibilizar um conjunto de pequenas aplicações de grande utilidade, que irão ser utilizadas na
solução proposta.
21
Aplicação Sistema
Operativo Camadas de Convergência
Protocolos de
encaminhamento
Suportados
Aplicações incluídas Segurança Licença
KioskNet Linux TCP Epidémico API para pastas, incluindo API de
segurança
PKI (Public-Key
Infrastructure)
Open
Source
Vlink Windows XP
Pro
TCP,
SMS e disco USB Epidémico Omail e Vsync PKI
Open Source
Postellation
Windows (XP a
W7); MacOSX
e Linux
TCP, UDP, LTP (Licklider
Transport Protocol) e TCP-
TLS (Transport Layer
Security)
Estático DTNping, DTNpong, DTNsend,
DTNrecv e HTTP proxy over DTN TLS Comercial
Haggle
Windows
Mobile, iPhone
OS, Android;
MacOSX e
Linux
TCP, UDP e Bluetooth Epidémico e Prophet PhotoShare PKI Open
Source
DTN2 Linux
TCP, UDP, Ethernet,
Bluetooth, Série, Norm (Nack-
Oriented Reliable Multicast),
extcl (external convergence
layer) e null
Estático,
Epidémico,
Neighborhood,
Estado da ligação,
Prophet, Tca-router e
externo
DTNcat, DTNcp, DTNhttpproxy,
DTNmoteproxy, DTN peek, Dtnperf,
DTNpublish, DTNquery, DTNrecv
DTNrespond, DTNsend, DTNsink,
DTNdource, DTNtest, DTNtunnel,
Num2sdnv e Tca_admin
BSP (Bundle
Security
Protocol) [27]
Open
Source
Tabela 1 - Implementações de referência avaliadas.
22
1. Arquitectura proposta para o demonstrador de redes veiculares
tolerantes a atrasos
A arquitectura proposta para o demonstrador de redes veiculares tolerantes a atrasos, ilustrada na
Figura 9, consiste num computador isolado – Quiosque, um computador ligado à Internet – Gateway
e um nó mula composto por um netbook transportado num veículo robótico feito com um Lego
Mindstorm NXT [28], que realiza um percurso de ligação entre os dois computadores atrás referidos.
O nó mula pode ser visto na Figura 10.
Figura 9 - Arquitectura proposta para o demonstrador de redes veiculares tolerantes a atrasos.
Figura 10 - Mula (Robot e Netbook).
23
Nos parágrafos seguintes encontra-se uma breve descrição do esquema de blocos dos vários
componentes da arquitectura proposta:
Computador ligado à Internet - Gateway
A figura 11 ilustra o esquema de blocos do computador ligado à Internet - Gateway - mostrando como
um encaminhador bundle interage com os adaptadores de camadas de convergência, com as
decisões de encaminhamento e com o armazenamento para utilizar um dos protocolos para entrega
das bundles.
Figura 11 - Computador ligado à Internet – Gateway.
Os diferentes blocos que compõem a figura 11 têm as seguintes funcionalidades:
O Encaminhador bundle é responsável por mover as bundles entre a aplicação, o
armazenamento e os adaptadores das camadas de convergência, cumprindo as decisões
tomadas pelo algoritmo de encaminhamento.
O Armazenamento simboliza uma base de dados Berkeley para armazenamento persistente
das bundles.
Os Adaptadores de camada de camadas de convergência fazem a adaptação entre o
protocolo bundle e as camadas de transporte, TCP ou UDP, por exemplo.
Aplicação local representa a parte do código da aplicação de correio electrónico sobre DTN
que reside neste nó.
Protocolo 802.11 b/g representa o protocolo usado para comunicações sem fios Wi-Fi.
Protocolo 802.3 representa o protocolo usado para comunicações com fios Ethernet.
Gestão de processos representa toda a gestão de processos efectuada neste nó.
Decisões de encaminhamento representa todas as decisões de roteamento efectuadas neste
nó.
24
As setas indicam interfaces, que podem transportar bundles ou directivas.
Computador isolado – Quiosque
A figura 12 ilustra o esquema de blocos do computador isolado – Quiosque – mostrando como um
encaminhador bundle interage com os adaptadores de camadas de convergência e com o
armazenamento para utilizar o protocolo 802.11 b/g para entrega das bundles.
Figura 12 - Computador isolado – Quiosque.
Computador instalado no robot – “Mula”
A figura 13 ilustra o esquema de blocos do computador instalado no robot – “Mula” – mostrando como
um encaminhador bundle interage com os adaptadores de camadas de convergência, com as
decisões de roteamento e com o armazenamento para utilizar um dos protocolos para entrega das
bundles. Este esquema é semelhante ao do nó Gateway, excepto que não existe aplicação, pois este
nó se limita a transportar bundles, e apenas existe comunicação sem fios.
25
Figura 13 - Computador instalado no robot – “Mula”.
26
27
IV. Avaliação da DTN2
Neste capítulo iremos avaliar as hipóteses de configuração da DTN2 que pensamos melhor se
adaptarem à arquitectura proposta no capítulo anterior. Serão avaliados vários cenários
diferenciando-se nos seguintes aspectos: Encaminhamento, tipo de link, camada de convergência,
segurança e ambiente. A escolha destes aspectos foi feita com base na análise ao estado da arte e às
implementações de referência, com especial enfoque na DTN2.
A. Cenários Escolhidos
Na Tabela 2 apresentamos as principais características dos cenários que foram utilizados para avaliar
o desempenho dos componentes da arquitectura DTN2.
Cenário Encaminhamento Tipo de link Camada de
Convergência Segurança Ambiente
1 Estático Estático
UDP - Congestionado
2 TCP - Congestionado
3
Epidémico Dinâmico
UDP Sem Congestionado
4 WEP Congestionado
5
TCP
Sem Livre
6 Congestionado
7 WEP
Livre
8 Congestionado
Tabela 2 - Cenários avaliados.
Estes cenários foram escolhidos com base no estudo prévio do estado da arte e das implementações
de referência, e nos ambientes onde a solução potencialmente poderá funcionar, cidade – ambiente
Congestionado e locais remotos – ambiente livre. Entende-se por ambiente congestionado aquele
onde diversas redes Wi –Fi coexistem partilhando o meio e disputando o acesso ao mesmos canais
radio, logo causando atrasos umas nas outras e baixando assim o seu debito binário. Meio livre é
aquele onde só existe uma rede ou onde as redes existentes operam em canais rádio suficientemente
distantes para não partilharem quaisquer frequências. Na Figura 14 apresenta-se um exemplo de um
meio congestionado e na Figura 15 apresenta-se um exemplo de um meio livre. Estas figuras foram
obtidas com o programa inSSIDer [29].
Encaminhamento estático é um conceito que descreve o modo de configuração da selecção de
caminhos dos encaminhadores numa rede de computadores. Neste tipo de encaminhamento não
existe comunicação entre os encaminhadores para descoberta da topologia da rede de computadores
28
onde estão inseridos. Os caminhos são adicionados manualmente a uma tabela de encaminhamento.
Esta solução só é aconselhável para redes de pequena dimensão e com uma topologia de caracter
permanente ou que sofra apenas pequenas e pontuais alterações.
O encaminhamento dinâmico caracteriza-se por disponibilizar caminhos de forma dinâmica apoiando-
se em mecanismos de descoberta da topologia da rede. Torna-se assim possível definir vários
caminhos entre os mesmos pontos de entrada e saída da rede de acordo com diversos factores (por
exemplo: custo e ocupação do caminho) previamente configurados nos anteriormente referidos
mecanismos de descoberta. Este mecanismo de encaminhamento assume-se como tolerante a
falhas e passível de utilização qualquer que seja a dimensão da rede, facilitando a administração da
mesma.
Figura 14 - Meio congestionado. Local: INESC, 5º piso.
Figura 15 - Meio livre. Local: Aldeia no Concelho de Sintra.
B. Configuração do daemon DTN2 em função do cenário escolhido
O ficheiro de configuração do pacote DTN2 chama-se “DTN.conf” e encontra-se na pasta <caminho
para-DTN-2.9.0>/daemon.
29
Na Figura 16, apresenta-se o ficheiro “DTN.conf”, com indicação a negrito das linhas alteradas ou
adicionadas relativamente ao ficheiro original, e que serão explicadas pormenorizadamente de
seguida.
#
# dtn.conf
#
# Default configuration file for Internet-connected DTN nodes. The
# daemon uses a tcl interpreter to parse this file, thus any standard
# tcl commands are valid, and all settings are get/set using a single
# 'set' functions as: <module> set <var> <val?>
#
#
log /dtnd info "dtnd parsing configuration..."
#
########################################
#
# Daemon Console Configuration
#
########################################
#
# console set stdio [ true | false ]
#
# If set to false, disable the interactive console on stdin/stdout.
# The default is set to true (unless the dtnd process is run as a
# daemon).
#
# console set stdio false
#
# console set addr <port>
# console set port <port>
#
# Settings for the socket based console protocol.
# (this interprets user commands)
#
console set addr 127.0.0.1
console set port 5050
#
# console set prompt <prompt>
#
# Set the prompt string. Helps if running multiple dtnd's
#
set shorthostname [lindex [split [info hostname] .] 0]
console set prompt "$shorthostname dtn% "
#
########################################
#
# Storage Configuration
#
########################################
#
#
# storage set type [ berkeleydb | external | memorydb ]
#
# Set the storage system to be used
#
storage set type berkeleydb
#
# the following are for use with external data stores
#
30
# The server port to connect to (on localhost)
# Note that 62345 has no special significance -- chosen randomly
storage set server_port 62345
#
# The external data store schema location, which can be
# found in dtn2/oasys/storage/DS.xsd.
storage set schema /etc/DS.xsd
#
# Do a runtime check for the standard locations for the persistent
# storage directory
#
set dbdir ""
foreach dir {/var/dtn /var/tmp/dtn} {
if {[file isdirectory $dir]} {
set dbdir $dir
break
}
}
if {$dbdir == ""} {
puts stderr "Must create /var/dtn or /var/tmp/dtn storage directory"
exit 1
}
#
#
# Set the directory to be used for bundle payload files
#
storage set payloaddir /home/jnunes/dtn-2.9.0/bundles
#
# storage set dbname <db>
#
# Set the database name (appended with .db as the filename in berkeley
# db, used as-is for SQL variants
#
storage set dbname DTN
#
#
# When using berkeley db, set the directory to be used for the
# database files and the name of the files and error log.
#
storage set dbdir $dbdir/db
#
########################################
#
# Routing configuration
#
########################################
#
#
# Set the algorithm used for dtn routing.
#
# route set type [static | flood | neighborhood | linkstate | external]
#
#As duas linhas seguintes variam consoante o cenário:
route set type static; cenários 1 e 2
route set type flood; cenários 3 a 8
#
# route local_eid <eid>
#
# Set the local administrative id of this node. The default just uses
# the internet hostname plus the appended string ".dtn" to make it
31
# clear that the hostname isn't really used for DNS lookups.
#
# route local_eid "dtn://[info hostname].dtn"
route local_eid dtn://vivian.dtn
#
# External router specific options
#
# route set server_port 8001
# route set hello_interval 30
# route set schema "/etc/router.xsd"
#
########################################
#
# TCP convergence layer configuration
#
########################################
#
#
# interface add [name] [CL]
#
# Add an input interface to listen on addr:port for incoming bundles
# from other tcp / udp convergence layers
#
# For IP-based interfaces, interfaces listen on INADDR_ANY port 4556
# by default. These can be overridden by using the local_addr and/or
# local_port arguments.
# interface add tcp0 tcp
# interface add udp0 udp
#
#As duas linhas seguintes variam consoante o cenário:
interface add udp0 udp local_addr=192.168.1.1 local_port=4556;cenários 1, 3
e 4
interface add tcp0 tcp local_addr=192.168.1.1 local_port=4556;cenários 2 e
5 a 8
#
# link add <name> <nexthop> <type> <clayer> <args...>
#
# Add a link to a peer node.
#
# For IP-based links (tcp or udp), the nexthop should contain a DNS
# hostname or IP address, followed optionally by a : and a port. If
# the port is not specified, the default of 4556 is used.
#
# e.g. link add link1 dtn.dtnrg.org ONDEMAND tcp
# link add link2 dtn2.dtnrg.org:10000 ONDEMAND tcp
#
# route add <dest> <link|peer>
#
# Add a route to the given bundle endpoint id pattern <dest> using the
# specified link name or peer endpoint.
#
# e.g. route add dtn://host.domain/* tcp0
#
########################################
#
# Service discovery
#
########################################
#
# discovery add <name> <af> <opts...>
32
# discovery announce <cl_name> <discovery_name> <cl_type> <opts...>
#
# Add a local neighborhood discovery module
#
# e.g. discovery add discovery_bonjour bonjour
#
#As quatro linhas seguintes variam consoante o cenário:
discovery add udp_link1 ip port=9556 local_addr=192.168.1.1
addr=192.168.1.3; cenários 1, 3 e 4
discovery announce udp0 udp_link1 udp interval=1; cenários 1, 3 e 4
discovery add tcp_link1 ip port=9556 local_addr=192.168.1.1
addr=192.168.1.3; cenários 2 e 5 a 8
discovery announce tcp0 tcp_link1 tcp interval=1; cenários 2 e 5 a 8
#
#
########################################
#
# Parameter Tuning
#
########################################
#
#
# Set the size threshold for the daemon so any bundles smaller than this
# size maintain a shadow copy in memory to minimize disk accesses.
#
# param set payload_mem_threshold 16384
#
#
# Test option to keep all bundle files in the filesystem, even after the
# bundle is no longer present at the daemon.
#
# param set payload_test_no_remove true
#
#
# Set the size for which the tcp convergence layer sends partial reception
# acknowledgements. Used with reactive fragmentation
#
# param set tcpcl_partial_ack_len 4096
#
#
# Set if bundles are automatically deleted after transmission
#
# param set early_deletion true
# (others exist but are not fully represented here)
#
#
########################################
#
# Extension Block Configuration
#
########################################
#
#
# Attach an Age Extension Block to outgoing bundles
#
# block set age_outbound_enabled false
#
# Process the Age Extension Block on incoming bundles
#
33
# block set age_inbound_processing true
#
#
# Zero out the Creation Timestamp Time on bundles
#
# block set age_zero_creation_ts_time false
#
########################################
#
# BPQ caching control
#
########################################
#
#
# Turn on caching of passing bundles with BPQ blocks
#
# bpq enable
#
#
#
log /dtnd info "dtnd configuration parsing complete"
## emacs settings to use tcl-mode by default
## Local Variables: ***
## mode:tcl ***
## End: ***
Figura 16 - Ficheiro “dtn.conf” de configuração do DTN2.
Segue-se a explicação das linhas alteradas ou adicionadas no ficheiro DTN.conf:
storage set type berkeleydb
O armazenamento persistente, característica opcional destas implementações, mas escolhido para a
solução apresentada, foi assegurado com o recurso à base de dados open source Berkeley. O facto
de ser um produto do portfólio do líder do mercado de bases de dados, a Oracle, oferece garantias de
estabilidade e continuidade do mesmo.
route set type static; cenários 1 e 2
route set type flood; cenários 3 a 8
A primeira linha configura o daemon com encaminhamento estático.
A segunda linha configura o daemon com encaminhamento epidémico
34
route local_eid dtn://vivian.dtn
Esta linha ilustra o identificador de nó local, no caso o computador com o nome Vivian.
interface add udp0 udp local_addr=192.168.1.1 local_port=4556
interface add tcp0 tcp local_addr=192.168.1.1 local_port=4556
A primeira linha adiciona uma interface de entrada UDP para escuta, no endereço local 192.168.1.1 e
na porta 4556, por bundles originadas noutras camadas UDP.
A segunda linha adiciona uma interface de entrada TCP para escuta, no endereço local 192.168.1.1 e
na porta 4556, por bundles originadas noutras camadas TCP.
discovery add udp_link1 ip port=9556 local_addr=192.168.1.1
addr=192.168.1.3; cenários 1, 3 e 4
discovery add tcp_link1 ip port=9556 local_addr=192.168.1.1
addr=192.168.1.3; cenários 2 e 5 a 8
O comando discovery é usado para configurar um agente de descoberta de nós na vizinhança.
Anuncia-se uma camada local de convergência, registando o seu endereço local e a sua porta
através do comando discovery add. O mecanismo associado a este comando irá anunciar a
existência de uma camada de convergência aos nós vizinhos.
A primeira linha configura um agente UDP na porta 9556 no endereço local 192.168.1.1 para
comunicar com o nó vizinho com o endereço local 192.168.1.3
A segunda linha configura um agente TCP na porta 9556 no endereço local 192.168.1.1 para
comunicar com o nó vizinho com o endereço local 192.168.1.3
discovery announce udp0 udp_link1 udp interval=1; cenários 1, 3 e 4
discovery announce tcp0 tcp_link1 tcp interval=1; cenários 2 e 5 a 8
Este comando, discovery announce é utilizado para anunciar o endereço da interface associado a
uma camada de convergência.
A primeira linha anuncia um agente UDP com anúncios a intervalos de 1 segundo. Anúncios
frequentes permitem descobrir ligações disponíveis rapidamente.
35
A segunda linha anuncia um agente TCP com anúncios a intervalos de 1 segundo.
C. Teste aos cenários escolhidos
1. Teste ao cenário 1
Cenário Encaminhamento Tipo de link Camada de
Convergência
Segurança Ambiente
1 Estático Estático UDP - Congestionado
Tabela 3 - Cenário 1.
A camada de convergência UDP conecta nós DTN através de um canal UDP. Os protocolos DTN
ultrapassam a falta de fiabilidade dos canais UDP tentando alcançar uma entrega confiável dos
bundles através de um canal UDP não fiável.
Um datagrama UDP tem o tamanho limite de 65507 bytes. A camada de convergência UDP adiciona
um cabeçalho de tamanho variável, normalmente menor que 1000 bytes a cada datagrama. Como os
bundles são enviados dentro de um único datagrama UDP, isto significa que bundles cujo tamanho
exceda aproximadamente 64000 bytes não podem ser transmitidos ou recebidos por uma camada de
convergência UDP.
Devido ao protocolo da camada de ligação de dados que utilizamos, Ethernet raramente suportar o
tamanho máximo dum datagrama UDP, ele será fragmentado e reconstruido no nó destino. Este
processo, como especificado no protocolo UDP/IP, não efectua retransmissões. Como resultado
desta característica, se utilizarmos um link com uma fiabilidade muito baixa e com datagramas que
obriguem à existência de fragmentação, a taxa de transmissão será próxima de 0. Esta limitação
resulta que, na prática, o tamanho máximo das bundles que se pode utilizar num link UDP rádio
congestionado é aproximadamente 2 a 3 vezes a Unidade Máxima de Transmissão (MTU) da
camada de ligação de dados que utilizarmos. Para a Ethernet, a MTU é de 1500 bytes.
Metodologia: Foram realizadas duas baterias de testes, utilizando dois computadores correndo a
implementação de referência DTN2 configurada para o cenário escolhido. Na primeira bateria
executámos a aplicação Dtnperf [30] com bundles de 50KB e na segunda executámos o Dtnperf com
bundles de 1KB. As figuras 17 e 18 mostram o resultado dos testes.
36
Figura 17 - Captura do tráfego de bundles de 50KB pelo software Wireshark.
Figura 18 - Captura do tráfego de bundles de 1KB pelo software Wireshark.
2. Teste ao cenário 2
Cenário Encaminhamento Tipo de link Camada de
Convergência Segurança Ambiente
2 Estático Estático TCP - Congestionado
Tabela 4 - Cenário 2.
Metodologia: Foram efectuados 15 testes entre dois computadores, correndo a implementação de
referência DTN2 configurada de acordo com o cenário respectivo. Estes testes consistiram na
execução de um script de medições com o Dtnperf com bundles de 50KB e o Iperf [31] com uma
janela de 50KB, i.e. com as mesmas condições. Os resultados são mostrados na figura 19.
O Iperf é uma ferramenta de teste de redes com a qual se podem criar fluxos de dados TCP ou UDP
entre dois computadores e medir o débito da rede que os transporta.
O Dtnperf é uma ferramenta similar ao Iperf para DTN, dando-nos o goodput da DTN.
37
Goodput Débito
Mbit/s
Dtnperf (Mbit/s) Iperf (Mbit/s)
Média Dtnperf 0,722
0,715 16,400
Média Iperf 16,421
0,717 16,300
Desvio padrão Dtnperf 0,013
0,710 16,300
Desvio padrão Iperf 1,043
0,744 16,000
0,730 16,200
Média Iperf/Média Dtnperf 22,740
0,729 15,900 0,710 16,700 0,718 16,600 0,725 16,000 0,709 15,900 0,708 16,600 0,738 15,200 0,729 16,100 0,745 16,300 0,705 19,800
Figura 19 - Resultados obtidos nos testes efectuados ao cenário 2.
Os valores obtidos para o goodput através do Dtnperf apresentam uma variação pequena, como
podemos verificar pelo valor do desvio padrão, o que reflecte a estabilidade da arquitectura. Os
valores obtidos para o débito através do Iperf apresentam uma variação um pouco maior, devida a
estarmos num meio congestionado.
Podemos observar uma grande diferença entre os valores do Dtnperf e do Iperf o que indicia a
existência de um estrangulamento entre o desempenho aplicacional e o desempenho da infra-
estrutura de rede.
3. Teste ao cenário 3
Cenário Encaminhamento Tipo de link Camada de
Convergência Segurança Ambiente
3 Epidémico Dinâmico UDP Sem Congestionado
Tabela 5 - Cenário 3.
Metodologia: Foram efectuados 15 testes entre dois computadores correndo a implementação de
referência DTN2 configurada de acordo com o cenário respectivo. Estes testes consistiram na
execução de um script de medições com o Dtnperf com bundles de 3KB e o Iperf com uma largura de
banda de 1Mbit/s.
38
Goodput Débito
Mbit/s
Dtnperf (Mbit/s) Iperf (Mbit/s)
Média Dtnperf 0,039
0,050 1,050
Média Iperf 1,050
0,049 1,050
Desvio padrão Dtnperf 0,009
0,050 1,050
Desvio padrão Iperf 0,000
0,049 1,050
0,047 1,050
Média Iperf/Média Dtnperf 26,630
0,037 1,050 0,046 1,050 0,043 1,050 0,022 1,050 0,036 1,050 0,029 1,050 0,032 1,050 0,027 1,050 0,045 1,050 0,040 1,050
Figura 20 - Resultados obtidos nos testes efectuados ao cenário 3.
Os valores obtidos para o goodput através do Dtnperf apresentam uma variação pequena, como
podemos verificar pelo valor do desvio padrão, o que reflecte a estabilidade da arquitectura. Os
valores obtidos para o débito através do Iperf não apresentam variação devido a termos utilizado um
valor de teste baixo, apenas 1Mbit/s. Pretendeu-se com isto demonstrar que o estrangulamento entre
o desempenho aplicacional e o desempenho da infra-estrutura de rede não se deve a limitações do
meio de transmissão. O meio de transmissão oferece estabilidade para débitos pequenos mas
mesmo assim continua-se a verificar o estrangulamento atrás referido.
4. Teste ao cenário 4
Cenário Encaminhamento Tipo de link Camada de
Convergência Segurança Ambiente
4 Epidémico Dinâmico UDP WEP Congestionado
Tabela 6 - Cenário 4.
Metodologia: Foram efectuados 15 testes entre dois computadores correndo a implementação de
referência DTN2 configurada de acordo com o cenário respectivo. Estes testes consistiram na
execução de um script de medições com o Dtnperf com bundles de 3KB e o Iperf com uma largura de
banda de 1Mbit/s.
39
Goodput Débito
Mbit/s
Dtnperf (Mbit/s) Iperf (Mbit/s)
Média Dtnperf 0,034
0,047 1,05
Média Iperf 1,050
0,052 1,05
Desvio padrão Dtnperf 0,006
0,041 1,05
Desvio padrão Iperf 0,000
0,035 1,05
0,034 1,05
Média Iperf/Média Dtnperf 31,343
0,033 1,05 0,032 1,05 0,031 1,05 0,031 1,05 0,030 1,05 0,030 1,05 0,030 1,05 0,030 1,05 0,030 1,05 0,030 1,05
Figura 21 - Resultados obtidos nos testes efectuados ao cenário 4.
A diferença deste cenário para o anterior é a utilização de segurança WEP na rede ad hoc. Verificou-
se que a utilização deste tipo de segurança não degrada significativamente o goodput da rede DTN
testada, pois a diferença das médias do Dtnperf é de apenas 0,005 Mbit/s e a dos respectivos desvios
padrão somente de 0,003 Mbit/s. Para os valores do goodput e do débito, mantém-se as conclusões
alcançadas no ponto 3.3.1.5 – Teste ao cenário 3.
5. Teste ao cenário 5
Cenário Encaminhamento Tipo de link Camada de
Convergência Segurança Ambiente
5 Epidémico Dinâmico TCP Sem Livre
Tabela 7 - Cenário 5.
Metodologia: Foram efectuados 15 testes entre dois computadores correndo a implementação de
referência DTN2 configurada de acordo com o cenário respectivo. Estes testes consistiram na
execução de um script de medições com Dtnperf com bundles de 50KB e Iperf com uma janela de
50KB.
40
Goodput Débito
Mbit/s
Dtnperf (Mbit/s) Iperf (Mbit/s)
Média Dtnperf 0,718
0,990 20,200
Média Iperf 19,436
0,681 16,800
Desvio padrão Dtnperf 0,171
0,650 20,100
Desvio padrão Iperf 1,457
0,925 19,800
0,831 20,300
Média Iperf/Média Dtnperf 27,077
0,960 16,600 0,873 20,100 0,627 19,900 0,469 20,200 0,787 20,200 0,761 20,400 0,347 20,200 0,837 16,900 0,639 20,200 0,662 20,400
Figura 22 - Resultados obtidos nos testes efectuados ao cenário 5.
Estes testes, efectuados num meio livre, provam a inexistência de qualquer relação entre eventuais
perturbações do meio e o estrangulamento entre o desempenho aplicacional e o desempenho da
infra-estrutura de rede.
6. Teste ao cenário 6
Cenário Encaminhamento Tipo de link Camada de
Convergência Segurança Ambiente
6 Epidémico Dinâmico TCP Sem Congestionado
Tabela 8 - Cenário 6.
Metodologia: Foram efectuados 15 testes entre dois computadores correndo a implementação de
referência DTN2 configurada de acordo com o cenário respectivo. Estes testes consistiram na
execução de um script de medições com Dtnperf com bundles de 50KB e Iperf com uma janela de
50KB.
41
Goodput Débito
Mbit/s
Dtnperf (Mbit/s) Iperf (Mbit/s)
Média Dtnperf 0,944
1,496 13,300
Média Iperf 13,024
0,721 15,000
Desvio padrão Dtnperf 0,246
1,051 15,500
Desvio padrão Iperf 1,660
1,087 12,900
0,821 12,600
Média Iperf/Média Dtnperf 13,794
1,096 14,600
0,953 14,000
1,096 13,400
1,298 13,900
0,706 13,400
0,985 11,000
0,725 9,240
0,742 11,600
0,655 12,200
0,731 13,000
Figura 23 - Resultados obtidos nos testes efectuados ao cenário 6.
Comparando os cenários 6 e 2, que diferem pelo tipo de encaminhamento utilizado e pela natureza
dos links, constatamos que pela performance ligeiramente mais elevada, melhor gestão de recursos
dos PC’s e pelas facilidades de administração da solução é preferível a utilização de
encaminhamento epidémico e links dinâmicos.
7. Teste ao cenário 7
Cenário Encaminhamento Tipo de link Camada de
Convergência Segurança Ambiente
7 Epidémico Dinâmico TCP WEP Livre
Tabela 9 - Cenário 7.
Metodologia: Foram efectuados 15 testes entre dois computadores correndo a implementação de
referência DTN2 configurada de acordo com o cenário respectivo. Estes testes consistiram na
execução de um script de medições com Dtnperf com bundles de 50KB e Iperf com uma janela de
50KB.
42
Goodput Débito
Mbit/s
Dtnperf (Mbit/s) Iperf (Mbit/s)
Média Dtnperf 0,726
0,743 16,500
Média Iperf 18,924
0,829 20,100
Desvio padrão Dtnperf 0,179
0,974 20,700
Desvio padrão Iperf 1,904
0,575 18,200
0,743 20,000
Média Iperf/Média Dtnperf 26,080
0,638 20,300
0,894 20,000
0,818 20,100
0,937 20,000
0,836 20,100
0,781 16,200
0,794 20,100
0,475 18,100
0,439 18,700
0,408 18,200
Figura 24 - Resultados obtidos nos testes efectuados ao cenário 7.
Comparando os cenários 7 e 5, temos uma diferença da média do Iperf de apenas 0,008 Mbit/s,
concluindo-se, mais uma vez, e à semelhança do resultado dos testes dos cenários 3 e 4, que a
utilização de segurança WEP não tem um impacto significativo na performance da rede DTN utilizada
para os testes.
8. Teste ao cenário 8
Cenário Encaminhamento Tipo de link Camada de
Convergência Segurança Ambiente
8 Epidémico Dinâmico TCP WEP Congestionado
Tabela 10 - Cenário 8.
Metodologia: Foram efectuados 15 testes entre dois computadores correndo a implementação de
referência DTN2 configurada de acordo com o cenário respectivo. Estes testes consistiram na
execução de um script de medições com Dtnperf com bundles de 50KB e Iperf com uma janela de
50KB.
43
Goodput Débito
Mbit/s
Dtnperf (Mbit/s) Iperf (Mbit/s)
Média Dtnperf 0,708
1,028 16,100
Média Iperf 11,008
0,788 15,200
Desvio padrão Dtnperf 0,150
0,833 13,100
Desvio padrão Iperf 4,680
0,926 13,700
0,645 2,380
Média Iperf/Média Dtnperf 15,554
0,657 7,590
0,792 14,900
0,530 8,630
0,735 2,970
0,570 7,850
0,516 15,800
0,563 8,190
0,780 15,700
0,625 12,900
0,628 15,200
Figura 25 - Resultados obtidos nos testes efectuados ao cenário 8.
Os testes a este cenário permitem-nos chegar a iguais conclusões relativamente à analise de
cenários anteriores para o impacto do congestionamento do meio e da utilização de segurança WEP:
Comparando-o com o cenário 6, podemos afirmar que a utilização de segurança WEP na
rede ad hoc. não degrada significativamente o goodput da rede DTN testada.
Comparando-o com o cenário 7, verificamos que a utilização de segurança WEP não degrada
significativamente o goodput da rede DTN testada.
D. Conclusões
Dos protocolos de encaminhamento disponíveis na implementação de referência DTN2:, static,
flood, neighborhood, linkstate e external, foi escolhido o encaminhamento epidémico
(flood) por ser aquele que cumpria com os objectivos assumidos e facilitava a administração da
solução. Uma das vantagens do encaminhamento epidémico reside no facto de o mecanismo de
estabelecimento e quebra das ligações entre os nós ser dinâmico, permitindo assim um melhor
aproveitamento dos recursos de cada computador assim como facilitar e agilizar o algoritmo de
encaminhamento. É importante referir que o protocolo de encaminhamento epidémico tem uma
característica de grande importância, a redundância: Quando um nó recebe uma bundle copia-o para
todos os nós que lhe são adjacentes e esses nós farão o mesmo até a bundle chegar ao seu destino.
Aumenta assim a probabilidade de entrega das bundles. Além disso, atendendo ao número reduzido
44
de nós utilizado, o número de cópias adicionais não tem significado. A comparação entre os
resultados dos testes dos cenários 2 - Encaminhamento static, e 6 – Encaminhamento flood,
fundamentam a decisão tomada.
Todos os testes realizados indicaram que a utilização da camada de convergência TCP é preferível à
utilização da camada de convergência UDP. Já se esperava este resultado pelo explicado no ponto
IV.C.1 e, na análise feita às implementações de referência, este é o protocolo da camada de
transporte usado nas aplicações já implementadas na prática, casos do KioskNet e Vlink.
No que respeita à segurança, embora a utilização de WEP não seja a solução mais desejada pois a
sua capacidade de cifra é fraca e ultrapassável, é preferível utilizar WEP a ter comunicações sem
qualquer segurança. Nos testes realizados, verificou-se que a sua utilização não afecta a
performance da aplicação. Salienta-se que a WiFi Alliance, nas suas certificações WPA e WPA2
apenas suporta encriptação TKIP (Temporal Key Integrity Protocol) em redes suportadas numa infra-
estrutura e não em redes ad hoc.
Pelos resultados deste cenário e dos anteriores, conclui-se que a configuração ideal para o nosso
demonstrador de redes veiculares tolerantes a atrasos, é a correspondente ao cenário 8:
Cenário Encaminhamento Tipo de link Camada de
Convergência Segurança Ambiente
8 Epidémico Dinâmico TCP WEP Congestionado
Será esta configuração que irá suportar os testes da aplicação de correio electrónico suportada em
DTN2.
45
V. Aplicação de correio electrónico
Neste capítulo iremos descrever a aplicação de correio electrónico sobre a VDTN, assim como os
testes realizados para avaliação do seu desempenho e as respectivas conclusões.
A. Descrição da aplicação de correio electrónico
O propósito desta aplicação foi validar, de forma simples mas completa, a implementação DTN2 e a
arquitectura do demonstrador de redes veiculares tolerantes a atrasos. No anexo que acompanha
esta dissertação encontra-se informação de instalação da rede ad hoc, da implementação de
referência DTN2, assim como das aplicações que fazem parte dos seus pré-requisitos e ainda da
aplicação de correio electrónico.
Foi implementado um mecanismo de transferência de custódia que responsabiliza cada nó pela
transmissão com sucesso da bundle ao nó seguinte, utilizando armazenamento persistente. Este
armazenamento é garantido por uma base de dados da Berkeley que corre em cada um dos nós.
Podemos separar a aplicação em dois grandes blocos: envio e recepção de email.
Envio de email do Computador isolado – Quiosque
No Computador isolado – Quiosque foi instalado o seguinte software: a implementação de referência
DTN2, Dovecot, Kmail e Shell scripts.
O cliente de email Kmail foi configurado para utilizar pastas locais, com uma estrutura comum a
qualquer aplicação de email, como se pode ver na Figura 26.
Figura 26 - O cliente de email Kmail
46
O utilizador cria um email clicando em “New” e para o enviar deve clicar “Send Later Via”, conforme
ilustrado na Figura 27. O email é guardado na pasta outbox.
Figura 27 - Envio de email através do Kmail
É executado um script todos os minutos através do crontab que comprime e envia os emails para o
Computador ligado à Internet – Gateway via DTN. Primeiramente, os emails comprimidos são
convertidos em bundles e copiados para o daemon DTN2 que corre no Quiosque, onde esperam por
uma oportunidade de contacto com o Computador instalado no robot – “Mula”. Quando essa
oportunidade de contacto surge, as bundles são copiados para o daemon da “Mula”. Se o tempo de
contacto não for suficiente para a cópia integral das bundles e alguma for fragmentado através de um
processo de fragmentação reactiva, o fragmento que não foi copiado terá de esperar por uma nova
oportunidade de contacto para chegar ao seu destino, sendo a bundle reconstituída no nó de destino.
Fragmentação reactiva [5] é um processo que ocorre quando uma bundle não é totalmente copiada
ou por quebra na ligação ou pelo tempo de contacto não ter sido o suficiente para a sua transmissão
completa. São assim originados duas ou mais bundles em que as novas bundles terão os mesmos
endereços de origem e destino assim como o mesmo timestamp da bundle original.
Quando a “Mula” estabelece contacto via DTN com o Computador ligado à Internet – Gateway, as
bundles que transporta, são copiadas para o daemon DTN2 que corre neste nó. Na Gateway também
é executado um script todos os minutos que envia os emails que estão pendentes de envio para os
seus destinatários.
47
Recepção de email no Computador isolado –Quiosque
Quando alguém envia um email para o utilizador do Quiosque, esse email é primeiramente
recepcionado na Gateway. É executado um script todos os minutos na Gateway, que verifica a
existência de novos emails que tenham como destino o utilizador do Quiosque. Quando existem
emails, eles são comprimidos, convertidos em bundles e copiados para o daemon DTN2 que corre na
Gateway, onde esperam por uma oportunidade de contacto com o Computador instalado no robot –
“Mula”. Quando essa oportunidade de contacto surge, as bundles são copiadas para o daemon da
“Mula”. Se o tempo de contacto não for o suficiente para a cópia integral das bundles e alguma for
fragmentada através de um processo de fragmentação reactiva, o fragmento que não foi copiado terá
de esperar por uma nova oportunidade de contacto para chegar ao seu destino, sendo a bundle
reconstituída no nó de destino.
Quando a “Mula” estabelece contacto via DTN com o Quiosque, as bundles que transporta são
copiadas para o daemon DTN2 que corre neste nó. No Quiosque também é executado um script
todos os minutos que recepciona o ficheiro comprimido com os novos emails e os entrega no cliente
Kmail do utilizador do quiosque, mais especificamente na pasta inbox desse cliente.
B. Testes e avaliação
Como primeira abordagem analisámos os cenários 6 e 8, já conhecidos do capítulo anterior.
Cenário Encaminhamento Tipo de link Camada de
Convergência Segurança Ambiente
6
Epidémico Dinâmico TCP
-
Congestionado 8 WEP
Tabela 11 - Cenários 6 e 8.
Metodologia: Foram efectuados 15 testes entre três computadores (quiosque, mula e gateway)
correndo a implementação de referência DTN2 configurada de acordo com o cenário respectivo.
Estes testes consistiram na execução de um script de medições com Dtnperf com bundles de 50KB e
tempo de contacto 1min e intervalo entre contactos de 15 segundos.
48
Dtnperf sem segurança
(Mbits/s)
Dtnperf com segurança WEP
(Mbits/s)
0,003 0,002
0,003 0,003
0,003 0,003
0,003 0,003
0,003 0,002
0,003 0,003
0,003 0,003
0,003 0,003
0,003 0,003
0,003 0,003
0,003 0,003
0,003 0,003
0,003 0,003
0,003 0,002
0,003 0,003
Mbit/s
Média Dtnperf sem segurança 0,003
Média Dtnperf com segurança 0,003
Desvio padrão Dtnperf sem segurança 0,000
Desvio padrão Dtnperf com segurança 0,000
Média Dtnperf sem segurança/ Dtnperf com segurança 0,933
Figura 28 - Resultados obtidos nos testes efectuados à solução de correio electrónico.
Estes testes demostram uma performance da aplicação abaixo do esperado. Pois com um tempo de
contacto de 1 min, poderemos esperar a transmissão de apenas 180 KB por contacto, em média. Tal
deve-se ao tempo necessário para descobrir que a ligação física está disponível, para estabelecer a
ligação TCP, para negociar que bundles serão transmitidas, sobrando pouco tempo para as
transmitir, bem como as respectivas confirmações de recepção.
Como os testes à aplicação demostraram uma performance abaixo do esperado, investigamos
soluções para aumentar a performance da aplicação:
Aumentar o tempo de contacto
Ajudaria, mas não resolveria o problema pois para transferir 1 MB precisaríamos de quase 6 min.
49
Aumentar o tamanho das bundles a transmitir pelos nós.
Teste desta hipótese:
Cenário Encaminhamento Tipo de link Camada de
Convergência Segurança Ambiente
8 Epidémico Dinâmico TCP WEP Congestionado
Tabela 12 - Cenário avaliado no teste da aplicação de correio electrónico
Metodologia: Foram efectuados 15 testes entre dois computadores correndo a implementação de
referência DTN2 configurada de acordo com o cenário respectivo. Estes testes consistiram na
execução de um script de medições com Dtnperf com bundles de 10MB e Iperf com uma janela de
256KB (Máximo).
Goodput Débito
Mbit/s
Dtnperf (Mbit/s) Iperf (Mbit/s)
Média Dtnperf 11,220
11,474 16,200
Média Iperf 15,600
11,187 16,100
Desvio padrão Dtnperf 0,213
11,155 15,300
Desvio padrão Iperf 0,969
11,089 15,700
11,065 14,500
Média Iperf/Média Dtnperf 1,390
11,114 15,800 10,774 14,500 11,156 16,100 11,507 17,900 11,364 13,800 11,098 15,500 11,162 16,000 11,641 16,300 11,195 14,900 11,313 15,400
Figura 29 - Resultados obtidos nos testes efectuados à solução de correio electrónico.
Tempo médio de transmissão de 10MB: 7,13 s
Foram utilizados os seguintes computadores, apresentando-se os seus desempenhos medidos com
diferentes benchmarks:
50
Computador
Desempenho
BogoMips
Disk Transaction
Performance – PostMark
v1.51[32]
Gateway 10679,07
(Core2 Duo E6750 @2.66GHz) 370
Mula 7980,08
(Core2 Duo T7200 @2.0GHz) 46
Quiosque 12768,14
(Pentium 4 HT @3.2GHz ) 125
Tabela 13 - Desempenho dos computadores utilizados nos testes.
Com base nas conclusões do teste anterior, efectuámos outro teste para avaliação completa da
solução:
Metodologia: Foram efectuadas 2 baterias de 15 testes cada entre três computadores correndo a
implementação de referência DTN2 configurada de acordo com o cenário 8, deslocando-se a mula
entre dois deles. Estes testes consistiram na execução de um script de medições com Dtnperf com
bundles de 10MB para a 1ª bateria. Para a 2ª bateria foram executando um script de medições com
Dtnperf com bundles de 100MB.
Goodput
Mbit/s
Dtnperf (Mbit/s)
Média Dtnperf-Bateria 1 0,907
Bateria 1 Bateria 2
Média Dtnperf-Bateria 2 4,846
0,626 4,796
Desvio padrão Dtnperf-Bateria 1
0,224 0,729 4,853
0,814 4,573
Desvio padrão Dtnperf-Bateria 2
0,440 1,316 5,424
1,269 5,391
1,189 4,779
Média Dtnperf-Bateria 1 / Média Dtnperf-Bateria 2
5,342 1,073 4,992
0,994 4,668 0,820 4,582 0,603 * 3,689 0,665 5,024 0,854 5,002 0,837 4,540 0,956 5,465 0,861 4,910
Figura 30 - Resultados obtidos nos testes efectuados à solução de correio electrónico.
Nota: * - Verificou-se fragmentação da bundle nesta comunicação.
51
Da Figura 30, verifica-se que ao aumentar o tamanho das bundles 10 vezes, de 10MB para 100MB, o
Goodput aumentou 5,3 vezes. Assim, conclui-se que a degradação da performance é causada pelo
tempo de processamento das bundles no daemon, logo quanto maiores forem as bundles e mais
rápido for o computador mais célere será o processamento da informação e consequentemente maior
será o goodput da DTN.
Desta forma, mesmo um tempo de contacto de apenas 3 min, que será natural ocorrer num autocarro
que pare numa aldeia, perto de um quiosque Internet, ou numa cidade, perto de um nó gateway, é
mais que suficiente para a transferência de 100MB de emails, pelo que a solução proposta pode ser
facilmente usada na prática.
52
53
VI. Conclusão
Este capítulo encerra esta dissertação com a apresentação das principais conclusões da mesma e
com sugestões para trabalho futuro.
A. Conclusões
Esta dissertação pretendeu abordar os princípios fundamentais das Redes Veiculares Tolerantes a
Atrasos e demonstrar a sua aplicabilidade através de um demonstrador de redes veiculares tolerantes
a atrasos e das suas análises de performance.
Os conceitos inerentes às Redes Veiculares Tolerantes a Atrasos são conceitos do passado, do
presente e do futuro. De passado, pelo trabalho já realizado e que produziu as implementações de
referência que aqui abordamos e algumas aplicações práticas como o KioskNet e o Vlink. Do
presente, porque me permitiu fazer um trabalho estimulante, embora difícil e que me deu muita
satisfação. Do futuro, pois podem contribuir para a inclusão social de populações habitando locais
remotos, para a segurança rodoviária, para monitorização da vida selvagem, em comunicações no
espaço e em muitas outras situações.
Das conclusões a que chegámos, destacamos:
Escolha da implementação de referência DTN2 como a mais adequada para suporte da
aplicação de correio electrónico.
Validade da utilização de uma rede ad hoc na arquitectura proposta, ao invés de
aplicações como o KioskNet que se suportam numa rede local no nó remoto.
A escolha do protocolo de transporte TCP, pois apesar do overhead devido ao handshake
da ligação que lhe é característico, se revelou a escolha acertada para o transporte de
bundles entre diferentes nós. Salvaguarda-se a utilização de UDP em casos particulares
como os das redes de sensores.
A influência do tamanho das bundles no desempenho da aplicação de correio electrónico
em particular, mas também de uma forma geral na transmissão de qualquer bundle entre
dois ou mais nós. Quanto maior a bundle, melhor desempenho podemos esperar, pois
mesmo na ocorrência de fragmentação da mesma será atingido um goodput satisfatório.
A influência da performance dos computadores utilizados nos nós no desempenho da
aplicação de correio electrónico.
54
B. Trabalho Futuro
O trabalho apresentado chegou a conclusões interessantes, todavia é possível ir mais além,
complementá-lo e até melhorá-lo.
Seria interessante configurar a rede ad hoc com equipamento que suportasse a nova norma IEEE
802.11p [33], pois é uma norma específica para ambientes veiculares. Define os melhoramentos
necessários à norma IEEE 802.11 standard para suportar aplicações ITS (Intelligent Transportation
Systems) [34], incluindo troca de dados entre veículos a grande velocidade e entre veículos e a infra-
estrutura existente nas laterais da estrada.
A nível da implementação de referência DTN2, seria importante averiguar mais aprofundadamente as
causas da lentidão do processamento de bundles que tanto degradam o desempenho, quando são de
reduzida dimensão, de forma a reduzir os seus efeitos. É possível obter melhores resultados para um
cenário específico, fazendo o tunning à base de dados Berkeley utilizada no armazenamento
persistente. Seria ainda interessante melhorar a gestão dos buffers, sempre de acordo com um
cenário específico. Também seria interessante avaliar a utilização de classes de serviço. Estão
disponíveis 3 níveis de prioridade, estando ainda um outro reservado para uso futuro.
Outro dos aspectos que merece uma abordagem futura é a temática da segurança. A implementação
de referência DTN2, base do trabalho realizado, inclui um protocolo de segurança, o BSP [35]. Este
protocolo é constituído por quatro grandes ferramentas:
BAB (Bundle Authentication Block) – é utilizado para impedir ataques DOS (Denial Of
Service) e para assegurar que a informação de encaminhamento trocada entre nós vizinhos
é autenticada.
PCB (Payload Confidentiality Block) – é utilizado para cifrar o payload da bundle.
PIB (Payload Integrity Block) – é utilizado para validar a integridade do conteúdo da bundle.
ESB (Extension Security Block) – fornece protecção às partes da bundle que não estão
relacionadas com o payload, como por exemplo meta-data.
Ainda no que concerne à segurança, seria interessante avaliar a norma IEEE 802.11s [36], pois
providencia autenticação dos nós e cifra da comunicação entre nós mais poderosa que o WEP.
55
Referências
[1] - P. Pereira, A. Casaca, J. Rodrigues, V. Soares, J. Triay, C. Cervelló-Pastor, "From Delay-Tolerant Networks to Vehicular Delay-Tolerant Networks", IEEE Communications Surveys & Tutorials, vol 14, n.4, pp.1166-1182, 2012. [2] - Stephen Farrell e Vinny Cahill, “Delay- and Disruption-Tolerant Networking”; Artech House, Setembro de 2006. [3] - Delay Tolerant Networking Research Group, Disponível on line em http://www.DTNrg.org/wiki [4] - V. Cerf et al., “Delay Tolerant Architecture”, IETF, RFC 4838, Abril de 2007. [5] - K. Scott e S. Burleigh, “Bundle Protocol Specification, IETF, RFC 5050, Novembro de 2007. [6] - L. Frank e F. Gil-Castiñeira, “Using Delay Tolerant Networks for Car2Car Comunications”, Proc. IEEE International Symposium on Industrial Electronics, ISIE 2007, pp. 2573-2578, Vigo, Espanha, Junho de 2007. [7] - Projecto CarTel.[Online] Disponível em: http://cartel.csail.mit.edu [8] - K. Scott, “Disruption tolerant networking proxies for on-the-move tactical networks”, Proc. IEEE MILCOM 2005, vol. 5, pp. 3226-3231. [9] - S. Guo, M H. Falaki, E. A. Oliver, S. Rahman, A. Seth, M. A. Zaharia and S. Keshav, “Very Low-Cost Internet Access Using KioskNet”, ACM Computer Comunication Review, Outubro de 2007. [10] - H. Soroush, N. Banejee, A. Balasubramanian, M. D. Corner, B. N. Levine e B. Lynn, “Dome: A Diverse Outdoor Mobile Testbed”, Proc. ACM. Intl Workshop on Hot Topics of Planet-scale Mobility Measurements (Hot Planet), Junho de 2009. [11] - V. Soares, F, Farahmand and J. Rodrigues, “A Layered Architecture for Vehicular Delay-Tolerant Network”, Proc. IEEE Symposium on Computers and Communications (ISCC 2009), Sousse, Tunisia, 5 a 8 de Julho. [12] - S: Lahde, M. Doering, W. Potner, G. Lammert and L. Wolf, “A practical analysis of communication characteristics for mobile and distributed pollution measurements on the road”, Wireless Communication and Mobile Computing, vol. 7, nº 10, pp 1209-1218, Dezembro de 2007 [13] - Jörg Ott, Dirj Kutscher, “From Drive-Thru Internet to Delay-tolerant Ad hoc Networking”, Capítulo do livro “Mobile Ad hoc Networks: From Theory to Reality”, Nova Science Publishers, Inc., 2007. [14] - Car 2 Car Communication Consortium Manifesto. Overview of the C2C-CC System, 2007. Disponível online em: http://www.car-2-car.org [15] - White Paper, “How TomTom’s HD Traffic and IQ Routes data provides the very best routing”, Disponível online em: http://www.tomtom.com [16] - Drive-In Project. Disponível online em: http://drive-in.cmuportugal.org/ [17] - DTN-Bytewalla 5 Project. Disponível online em: http://csd.xen.ssvl.kth.se/csdlive/content/dtn-
bytewalla [18] - DTN-Bytewalla 5 Project. Disponível online em: http://www.docstoc.com/docs/49064103/Bytewalla-Presentation [19] - DTN2. Disponível online em: http://www.DTNrg.org/docs/code/DTN2/doc/manual/tutorial-2.html [20] - John K. Ousterhout. Tcl and the Tk Toolkit. Addison-Wesley, 1994. ISBN: 0-201-63337-X [21] - Ion - Interplanetary Overlay Network. Disponível online em: https://ion.ocp.ohiou.edu/ [22] - M. Ramadas, S. Burleigh e S. Farrell, “Licklider Transmission Protocol – Specification”, IETF RFC 5326, Setembro de 2008 [23] - “CCSDS FILE DELIVERY PROTOCOL (CFDP)”, Consultative Committee for Space Data Systems Standard 727.0-B-2, Outubro 2002, Disponível online em: http://public.ccsds.org/publications/archive/727x0b2s.pdf [24] - “Asynchronous Message Service”, CCSDS Standard 735.1-B-1. Disponível online em: http://public.ccsds.org/publications/archive/735x1b1.pdf [25] - A. Keranen, T. Karkkainen and J. Ott, “Simulating Mobility and DTN with the ONE”, Journal of Communications, vol. 5, nº 2, pp 92-105, Fevereiro de 2010 [26] - Yue Cao, Zhili Sun, “Routing in Delay/Disruption Tolerant Networks: A Taxonomy, Survey and Challenges”, IEEE Communications Surveys & Tutorials, v.15 n.2, pp.654-677, 2
nd Quarter 2013,
[Online]. Available : http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6196145 [27] - K. Scott and S. Burleigh, “Bundle Protocol Specification”, IETF, RFC 5050, November 2007
Disponivel online em: http://www.rfc-editor.org/rfc/rfc5050.txt
[28] - The Lego Group, “Lego Mindstorms NXT”. Disponivel online em http://mindstorms.lego.com/en-
us/default.aspx
[29] - inSSIDer for Home Disponível online em: http://www.metageek.net/products/inssider/
[31] - Aplicação DTNperf. Disponivel online em: http://www.pieroland.net/projects/index.php?go=dtnperf
56
[31] - Aplicação Iperf. Disponivel online em: http://sourceforge.net/projects/iperf [32] - Phoronix Test Suite. Disponivel online em: http://www.phoronix-test-suite.com/ [33] - IEEE 802.11p-2010 - IEEE Standard for Information technology-- Local and metropolitan area networks-- Specific requirements-- Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 6: Wireless Access in Vehicular Environments. Disponivel online em http://standards.ieee.org/findstds/standard/802.11p-2010.html
[34] - Intelligent Transportation Systems (ITS) Society. Disponivel online: http://sites.ieee.org/itss/
[35] - S. Symington, S. Farrell, H. Weiss, P. Lovell, “Bundle Security Protocol Specification”, IETFC RFC 6257, Maio de 2011. [36] - 802.11s-2011 - IEEE Standard for Information Technology--Telecommunications and information exchange between systems--Local and metropolitan area networks--Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 10: Mesh Networking. Disponivel online em: http://standards.ieee.org/findstds/standard/802.11s-2011.html
57
Anexo
I. Introdução
Este anexo descreve os pré-requisitos de hardware e software, a instalação da
implementação de referência DTN2 e a instalação de uma solução de envio de correio
electrónico desenvolvida no âmbito desta tese de mestrado.
Salienta-se a utilização exclusiva de software open source.
Os comandos foram escritos no formato de letra Courier de modo a serem rapidamente
diferenciados do restante texto.
II. Pré-requisitos
A. Harware
Configuração mínima:
CPU: Pentium IV
RAM: 1 GB
Hard Disk: 4 GB
B. Software
Sistema operativo: Kubuntu 12.04 LTS
Compilador de c: gcc
Compilador de c++: g++
Utilitários make e apt-get install
58
Configuração da rede ad hoc
Ficheiro /etc/network/interfaces
auto wlan1
iface wlan1 inet static
# wireless-key 1984-1984-69
address 192.168.1.X
netmask 255.255.255.0
wireless-essid JNDTN2
wireless-mode ad-hoc
wireless-channel 6
O endereço na linha “address” varia consoante o computador a configurar.
Foram testadas duas configurações, com e sem segurança, diferenciando-se apenas pela linha que
aparece comentada.
Ficheiro /etc/rc.local
iwconfig wlan1 txpower 0
iwconfig wlan1 ap CE:6C:45:CD:EE:69
III. Instalação DTN2
A. Instalação do Xerces (versão 2.8.0)
Este pacote está disponível em: http://www.apache.org/dist/xerces/c/2/sources/
1º passo: Acrescentar no .bashrc:
export XERCESCROOT=<caminho para-xerces-c-src_2_8_0>
export PATH=$PATH:<caminho para-xerces-c-src_2_8_0>/lib:<caminho para-xerces-c-
src_2_8_0>/obj:<caminho para-xerces-c-src_2_8_0>/
59
2º passo: cd /<caminho para-xerces-c-src_2_8_0>/src/xercesc/
3º passo: ./runConfigure -plinux
4º passo: make
5º passo: sudo –s
6º passo: make install
B. Instalação da base de dados da Berkeley (versão 5.3.21)
Este pacote está disponível em:
http://www.oracle.com/technetwork/products/berkeleydb/downloads/index.html
1º passo: Acrescentar no .bashrc:
export LD_LIBRARY_PATH=/usr/local/BerkeleyDB.5.3/lib
2º passo: cd <caminho para-db-5.3.21>/build_unix
3º passo: ./dist/configure –enable-cxx –enable-tcl
4º passo: make
5º passo: sudo –s
6º passo: make install
C. Instalação do interpretador de comando Tcl (versão 8.5.0-2)
Instalados através do apt-get install:
Tcl - 8.5.0-2
Tclreadline - 2.1.0-10
Tcl8.5 – 8.5.11-1ubuntu1
60
D. Instalação da biblioteca de c++ Oasys (versão 1.6.0)
Este pacote está disponível em: http://sourceforge.net/projects/dtn/files/oasys/
1º passo: cd <caminho para-oasys-1.6.0>
2º passo: sh configure –with- xerces-c –with-tcl –with-tclreadline
3º passo: make
4º passo: sudo –s
5º passo: make install
E. Instalação da implementação de referência DTN2 (versão 2.9.0)
Este pacote está disponível em: http://sourceforge.net/projects/dtn/files/DTN2/dtn-2.9.0/
1º passo: cd <caminho para-dtn-2.9.0>
2º passo: sh configure -C
3º passo: make
4º passo: sudo –s
5º passo: make install
O ficheiro de configuração do pacote DTN2 chama-se dtn.conf e encontra-se na pasta <caminho
para-dtn-2.9.0>/daemon, devendo ser copiado para <caminho para-dtn-2.9.0>.
61
IV. Instalação da solução de correio electrónico sobre DTN2
A. Servidor IMAP e POP3
Para servidor de IMAP e POP3 foi escolhido o Dovecot. Este servidor é uma excelente escolha para
instalações de pequena ou grande dimensão. É rápido, simples de instalar, não requer cuidados
especiais na sua administração e usa pouca memória.
Foi instalado através do apt-get install
B. Cliente de correio electrónico
Para cliente de correio electrónico foi escolhido o KMail. É o cliente fornecido por omissão no
ambiente KDE, suporta pastas, filtros, visualização HTML de email e caracteres internacionais. Pode
ser configurado para utilizar pastas locais, o que é o caso na solução apresentada.
C. Agente de transporte de correio electrónico
Para agente de transporte de correio electrónico foi escolhido o sendmail. É um agente poderoso,
escalável e eficiente.
Foi instalado através do apt-get install
D. Configuração do computador isolado - Quiosque
1. Software instalado:
Implementação de referência DTN2 (versão 2.9.0), Dovecot, Kmail e Shell scripts.
Foi considerada a instalação numa área de utilizador “a”. Se necessário, alterar “/home/a” para a área
utilizada.
2. Shell scripts:
Crontab
# Recepçao de email da Vivian (computador Gateway) a cada minuto
* * * * * /home/a/dtn-2.9.0/Scripts/Cpd.sh
* * * * * /home/a/dtn-2.9.0/Scripts/Recepcao-Vivian.sh
#
# Envio de email para a Vivian (computador Gateway) a cada minuto
62
* * * * * /home/a/dtn-2.9.0/Scripts/Envio-Vivian.sh
Execução do daemon dtncpd - Cpd.sh:
DIR=/home/a/dtn-2.9.0/Inbound/vivian.dtn
cd $DIR
if [ "$(ls -A $DIR)" ];then
sleep 60
else
dtncpd /home/a/dtn-2.9.0/Inbound/
fi
Recepção de email - Recepcao-Vivian.sh:
#!/bin/bash
# Descomprime os ficheiros na pasta /home/a/dtn2-9-0/Inbound/vivian.dtn obtendo o ficheiro
suzie_email
#
WDIR=/home/a/.local/share/local-mail/inbox/new
cd $WDIR
TFILES=/home/a/dtn-2.9.0/Inbound/vivian.dtn/*
for t in $TFILES
do
tar -xf $t
rm -f $t
done
# mv /home/a/dtn-2.9.0/Inbound/vivian.dtn/* /home/a/.local/share/local-mail/inbox/new
Envio de email - Envio- Suzie.sh:
#!/bin/bash
# Comprime os ficheiros na pasta /home/a/.local/share/local-mail/Outbox/new/ para o ficheiro
suzie_email
#
WDIR=/home/a/.local/share/local-mail/outbox/new
cd $WDIR
NOWDATE=$(date +"%y%m%d%H%M%S")
if [ "$(ls -A $WDIR)" ]; then
tar -cf suzie_email.$NOWDATE *
63
dtncp /home/a/.local/share/local-mail/outbox/new/suzie_email.$NOWDATE dtn://vivian.dtn
mv /home/a/.local/share/local-mail/outbox/new/* /home/a/.local/share/local-mail/sent-mail/new
rm /home/a/.local/share/local-mail/sent-mail/new/suzie_email.$NOWDATE
else
echo "$WDIR is Empty"
fi
E. Configuração do computador ligado à Internet – Gateway
1. Software instalado:
Implementação de referência DTN2 (versão 2.9.0), Dovecot, sendmail e Shell scripts.
Foi considerada a instalação numa área de utilizador “jnunes”. Se necessário, alterar “/home/jnunes”
para a área utilizada.
2. Shell scripts:
Crontab
# Envio de email para a Suzie (computador quiosque) a cada minuto
* * * * * /home/jnunes/dtn-2.9.0/Scripts/Envio- Suzie.sh
#
# Recepçao de email da Suzie (computador quiosque) a cada minuto
* * * * * /home/jnunes/dtn-2.9.0/Scripts/Cpd.sh
* * * * * /home/jnunes/dtn-2.9.0/Scripts/Recepcao-Suzie.sh
Execução do daemon dtncpd - Cpd.sh:
DIR=/home/jnunes/dtn-2.9.0/Inbound/suzie.dtn
cd $DIR
if [ "$(ls -A $DIR)" ];then
sleep 60
else
dtncpd /home/jnunes/dtn-2.9.0/Inbound/
fi
Recepção de email- Recepcao-Suzie.sh:
#!/bin/bash
64
# Recepção de email da Suzie
# Descomprime os ficheiros na pasta /home/jnunes/dtn2-9-0/Inbound/suzie.dtn obtendo o
# ficheiro vivian_email
WDIR=/home/jnunes/.local/share/local-mail/outbox/new
cd $WDIR
TFILES=/home/jnunes/dtn-2.9.0/Inbound/suzie.dtn/*
for t in $TFILES
do
tar -xf $t
rm -f $t
done
#
# Envio para a Internet
FILES=/home/jnunes/.local/share/local-mail/outbox/new/*
for f in $FILES
do
echo "Processing $f file..."
/usr/sbin/sendmail -t <$f
# cat $f
done
mv /home/jnunes/.local/share/local-mail/outbox/new/* /home/jnunes/.local/share/local-mail/sent-
mail/new
Envio de email - Envio- Suzie.sh
#!/bin/bash
# Envio de email para a Suzie
# Comprime os ficheiros na pasta /home/jnunes/Maildir/new/ para o ficheiro suzie_email
#
WDIR=/home/jnunes/Maildir/new/
cd $WDIR
NOWDATE=$(date +"%y%m%d%H%M%S")
if [ "$(ls -A $WDIR)" ];then
tar -cf vivian_email.$NOWDATE *
dtncp /home/jnunes/Maildir/new/vivian_email.$NOWDATE dtn://suzie.dtn
mv /home/jnunes/Maildir/new/* /home/jnunes/Maildir/cur/
rm -f /home/jnunes/Maildir/cur/vivian_email.$NOWDATE
else
echo "$WDIR is Empty"
65
fi
F. Configuração da “mula”
1. Software instalado:
Implementação de referência DTN2 (versão 2.9.0)