Aplicações para Redes Veiculares Tolerantes a Atrasosmariel.inesc-id.pt › prbp › diversos ›...

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).

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.

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.

vii

Keywords

Vehicular Delay-Tolerant Networks, Ad hoc networks, Epidemic routing protocol, Demonstrator.

ix

Palavras-Chave

Redes Veiculares Tolerantes a Atrasos, Redes ad hoc, protocolo de encaminhamento epidémico,

Demonstrador.

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 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



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

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

http://www.irtf.org/

http://en.wikipedia.org/wiki/Intelligent_Transportation_Systems

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

http://en.wikipedia.org/wiki/Transmission_Control_Protocol

http://en.wikipedia.org/wiki/Transport_Layer_Security

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.

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.



http://www.dtnrg.org/docs/code/DTN2/doc/manual/cl-extcl.html

http://www.dtnrg.org/docs/code/DTN2/doc/manual/cl-null.html

http://www.dtnrg.org/docs/code/DTN2/doc/manual/ro_tca-router.html

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”.

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


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 Estático Estático TCP - Congestionado


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 Epidémico Dinâmico UDP Sem Congestionado


Metodologia: Foram efectuados 15 testes entre dois computadores correndo a implementação de


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



0,050 1,050

Média Iperf 1,050

0,049 1,050


0,050 1,050


0,049 1,050

0,047 1,050


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


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 Epidémico Dinâmico UDP WEP Congestionado




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



0,047 1,05

Média Iperf 1,050

0,052 1,05


0,041 1,05


0,035 1,05

0,034 1,05


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


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 Epidémico Dinâmico TCP Sem Livre




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



0,990 20,200

Média Iperf 19,436

0,681 16,800


0,650 20,100


0,925 19,800

0,831 20,300


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


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 Epidémico Dinâmico TCP Sem Congestionado





50KB.

41

Goodput Débito

Mbit/s



1,496 13,300

Média Iperf 13,024

0,721 15,000


1,051 15,500


1,087 12,900

0,821 12,600


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


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 Epidémico Dinâmico TCP WEP Livre





50KB.

42

Goodput Débito

Mbit/s



0,743 16,500

Média Iperf 18,924

0,829 20,100


0,974 20,700


0,575 18,200

0,743 20,000


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


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 Epidémico Dinâmico TCP WEP Congestionado





50KB.

43

Goodput Débito

Mbit/s



1,028 16,100

Média Iperf 11,008

0,788 15,200


0,833 13,100


0,926 13,700

0,645 2,380


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


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:




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.



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:




Tabela 12 - Cenário avaliado no teste da aplicação de correio electrónico



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



11,474 16,200

Média Iperf 15,600

11,187 16,100


11,155 15,300


11,089 15,700

11,065 14,500


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


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


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.

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


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


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

http://www.dtnrg.org/wiki

http://cartel.csail.mit.edu/

http://www.car-2-car.org/

http://www.tomtom.com/

http://drive-in.cmuportugal.org/

http://csd.xen.ssvl.kth.se/csdlive/content/dtn-bytewalla

http://csd.xen.ssvl.kth.se/csdlive/content/dtn-bytewalla

http://www.docstoc.com/docs/49064103/Bytewalla-Presentation

http://www.dtnrg.org/docs/code/DTN2/doc/manual/tutorial-2.html

https://ion.ocp.ohiou.edu/

http://public.ccsds.org/publications/archive/727x0b2s.pdf

http://public.ccsds.org/publications/archive/735x1b1.pdf

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6196145

http://www.rfc-editor.org/rfc/rfc5050.txt

http://mindstorms.lego.com/en-us/default.aspx

http://mindstorms.lego.com/en-us/default.aspx

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

http://sourceforge.net/projects/iperf

http://www.phoronix-test-suite.com/

http://standards.ieee.org/findstds/standard/802.11p-2010.html

http://sites.ieee.org/itss/

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



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

http://www.oracle.com/technetwork/products/berkeleydb/downloads/index.html

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



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



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

http://sourceforge.net/projects/dtn/files/DTN2/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


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”


Implementação de referência DTN2 (versão 2.9.0)

Aplicações para Redes Veiculares Tolerantes a Atrasosmariel.inesc-id.pt › prbp › diversos ›...

Documents

Transcript of Aplicações para Redes Veiculares Tolerantes a Atrasosmariel.inesc-id.pt › prbp › diversos ›...