NET-OPP: UM MIDDLEWARE TRANSPARENTE PARA FORMAÇÃO …

UNIVERSIDADE FEDERAL DE OURO PRETOINSTITUTO DE CIÊNCIAS EXATAS E BIOLÓGICAS

DEPARTAMENTO DE COMPUTAÇÃO

PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

NET-OPP: UM MIDDLEWARETRANSPARENTE PARA FORMAÇÃO DE

REDES E TROCA DE CONTEÚDOS PARAAPLICAÇÕES OPORTUNISTAS

CHARLES TIM BATISTA GARROCHO

ORIENTADOR: PROF. DR. RICARDO AUGUSTO RABELO OLIVEIRA

Ouro Preto – MG

Setembro de 2015

UNIVERSIDADE FEDERAL DE OURO PRETOINSTITUTO DE CIÊNCIAS EXATAS E BIOLÓGICAS

DEPARTAMENTO DE COMPUTAÇÃO

PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

NET-OPP: UM MIDDLEWARETRANSPARENTE PARA FORMAÇÃO DE

REDES E TROCA DE CONTEÚDOS PARAAPLICAÇÕES OPORTUNISTAS

CHARLES TIM BATISTA GARROCHO

Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Univer-sidade Federal de Ouro Preto, como parte dos requi-sitos para a obtenção do título de Mestre em Ciênciada Computação.Orientador: Prof. Dr. Ricardo Augusto Rabelo Oli-veira

Ouro Preto – MG

Setembro de 2015

Catalogação: www.sisbin.ufop.br

G243n Garrocho, Charles Tim Batista. Net-Opp [manuscrito]: um middleware transparente para formação de redes etroca de conteúdos para aplicações oportunistas / Charles Tim Batista Garrocho.- 2015. 93f.: il.: color; grafs; tabs.

Orientador: Prof. Dr. Ricardo Augusto Rabelo Oliveira.

Dissertação (Mestrado) - Universidade Federal de Ouro Preto. Instituto deCiências Exatas e Biológicas. Departamento de Computação. Programa de Pósgraduação em Ciências da Computação. Área de Concentração: Sistemas de Computação.

1. Arquitetura de redes de computador. 2. Computadores - Equipamento deentrada e saída. I. Oliveira, Ricardo Augusto Rabelo. II. Universidade Federalde Ouro Preto. III. Titulo.

CDU: 004.2

Dedico este trabalho a meus pais, Téoem memória e Maria, ambos exemplos de

coragem, determinação e bondade para minha vida.

AGRADECIMENTOS

Agradeço primeiramente a Deus, por me proporcionar a vida, os desafios, as dificuldades e

a força para superar mais um obstáculo.

Agradeço a minha esposa Lourdes e meu filho Gabriel, pelo amor, paciência, compreensão

e companheirismo de todos esses anos juntos.

Agradeço aos meus pais Teófilo e Maria, e meus irmãos Thiago e Gustavo, pelo incentivo,

aconchego e por me apoiarem em todos os momentos de minha vida.

Agradeço aos amigos que fiz no mestrado. Em especial aos amigos do Laboratório iMobilis,

com os quais desopilei em vários momentos e que contribuíram direta ou indiretamente com

ideias valiosas para o desenvolvimento deste trabalho.

Agradeço aos professores, principalmente ao Ricardo, pela contribuição substancial para a

concretização deste trabalho e orientação recebida.

Agradeço à Universidade Federal de Ouro Preto (UFOP) e a cidade de Ouro Preto, pelos

ensinamentos.

Agradeço ao Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq), pelo

apoio financeiro.

Agradeço a todos que me ajudaram direta ou indiretamente neste trabalho.

Agradeço aos esquecidos não mencionados explicitamente aqui.

Muito Obrigado.

Queria ser o sol

para iluminar os quatro cantos

da tua cela de prisão...

Queria ser as estrelas

para te fazer lembrar das noites da nossa terra...

Queria ser a lua para clarear

mais e mais teus sentimentos de liberdade...

Queria ser um pássaro

para te levar um cantar de que o amanhã

será mais livre...

Walter Teófilo Rocha Garrocho (Téo Garrocho)

RESUMO

O avanço e popularização de dispositivos móveis e a integração de novos recursos de co-

municação possibilitaram o surgimento das redes oportunistas. Rede oportunista é um tipo

de rede que promove uma comunicação entre dois dispositivos móveis mesmo que uma rota

para conectá-los não exista. Esse processo é feito através de oportunidades de encontros não

programados entre dispositivos móveis que trocam dados entre si até que a mensagem che-

gue ao destinatário. Essa comunicação de encontros em redes oportunistas permitiu diversas

aplicações, como na redução de tráfego de rede celular, em comunicações em situação de

emergência, e no contorno a censura de comunicação. O crescente aumento de dispositivos

móveis deve, em tese, promover redes oportunistas, já que com mais dispositivos, maiores

possibilidades de encontros será possível. Porém, na prática, as tecnologias atuais para re-

des oportunistas não estão disponíveis (Wi-Fi Ad-Hoc) nos dispositivos móveis atuais ou

exigem interação indesejada (Bluetooth e Wi-Fi Direct) do usuário para estabelecer conec-

tividade. Para superar essas deficiências é apresentado o middleware Net-Opp. Baseado na

tecnologia Wi-Fi modo infraestrutura, onde o dispositivo se torna um ponto de acesso, Net-

Opp pesquisa e analisa pontos de acesso disponíveis no ambiente, e se encontrar se associa

com um ponto. Se nenhum ponto de acesso for encontrado, Net-Opp torna o dispositivo

em um ponto de acesso, no modo infraestrutura, para prover uma rede de comunicação para

outros dispositivos, possibilitando uma troca transparente de conteúdos entre os dispositi-

vos, já que neste modo de operação do Wi-Fi não é exigido pareamento (associação entre

dispositivos). Esse processo realizado por Net-Opp é feito automaticamente sem exigir in-

teração humana e alteração no sistema operacional dos dispositivos móveis. Como prova de

conceito e avaliação são apresentadas duas aplicações que empregam o uso da arquitetura

desse middleware. As aplicações foram desenvolvidas em cenários de dispositivos móveis

pessoais e veiculares. O principal objetivo dessas aplicações é a avaliação do middleware

Net-Opp em cenários reais e diferentes e provar que esse processo de alternância entre esca-

neamento e ponto de acesso pode promover uma comunicação transparente ao usuário final.

Resultados de avaliações nas aplicações demonstraram que o middleware conseguiu criar

uma camada de interoperabilidade entre o sistema operacional e as aplicações oportunistas,

e abstrair a formação da rede e a troca de conteúdos entre vários dispositivos simultanea-

mente de forma transparente nos dois cenários.

Palavras-chave: Arquitetura de sistema, Redes oportunistas, Dispositivo-para-Dispositivo, Middleware,

Aplicativos

ABSTRACT

The advancement and popularization of mobile devices and the integration of new commu-

nication capabilities made possible the emergence of opportunistic networks. Opportunistic

network is a type of network that promotes communication between two mobile devices

even if a route to connect them does not exist. This process is done through meetings op-

portunities unscheduled between mobile devices that exchange data with each other until

the message reaches the recipient. This communication meetings in opportunistic networks

allow various applications, such as the reduction of mobile network traffic, communications

in emergency situations, and outline the censorship of communication. The increasing num-

ber of mobile devices should, in theory, promote opportunistic networks, as more devices,

more likely to meetings will be possible. However, in practice, current technologies for op-

portunistic networks are not available (Wi-Fi Ad-Hoc) in today’s mobile devices or require

unwanted interaction (Bluetooth and Wi-Fi Direct) User to establish connectivity. To over-

come these shortcomings is shown the Net-Opp middleware. Based on Wi-Fi technology

infrastructure mode, where the device becomes a point of access, Net-Opp research and

analyzes access points available in the environment, and meet associates with a point. If no

access point is found, Net-Opp makes the device in an access point in infrastructure mode,

to provide a communications network to other devices, enabling a transparent exchange of

content between devices, since in this operating mode Wi-Fi is not required pairing (as-

sociation between devices). This process carried out by Net-Opp is done automatically

without requiring human interaction and change in operating system for mobile devices.

As proof of concept and evaluation are presented two applications that employ the use of

this middleware architecture. The applications were developed in scenarios of personal and

vehicular mobile devices. The main purpose of these applications is the evaluation of the

Net-Opp middleware in real and different scenarios and prove that this process of switching

between scanning and access point can promote transparent communication to the end user.

Results of assessments in applications showed that the middleware has managed to create a

layer of interoperability between the operating system and opportunistic applications, and

abstract the formation of the network and the exchange of content among multiple devices

simultaneously transparently in both scenarios.

Keywords: System architecture, Opportunistic networks, device-to-device, Middleware, Applications

LISTA DE FIGURAS

2.1 Visão geral dos princípios de Computação Pervasiva. Fonte: adaptado de (SA-

LES, 2010). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Comunicação dos dispositivos em uma rede oportunista. Fonte: adaptado de

(HU, 2015). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Alcance das redes sem fio. Fonte: (BORGES; LEMES; ALECRIM, 2007). . . . . . 14

2.4 Modos de operação da tecnologia Wi-Fi. Fonte: (TANENBAUM, 2003). . . . . . 16

2.5 Arquitetura lógica de uma rede 802.11. Fonte: (TELECO, 2015). . . . . . . . . 16

2.6 Exemplo de funcionamento do Wi-Fi Tethering. Fonte: (CONSTANTINESCU,

2014). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.7 Funcionamento do Wi-Fi modo infraestrutura e Tethering. Fonte: (BRUN, 2014). 18

2.8 Desafios apresentados pela tecnologia Wi-Fi Tethering. Fonte: adaptado de

(TRIFUNOVIC, 2015). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Visão geral da arquitetura de Haggle. Fonte: (SU, 2007). . . . . . . . . . . . . 21

3.2 Visão geral do sistema MobiClique. Fonte: (PIETILAINEN, 2009). . . . . . . . . 23

3.3 Arquitetura do middleware Shair. Fonte: (DUBOIS, 2013b). . . . . . . . . . . . 24

3.4 Arquitetura de software de CAMEO. Fonte: (ARNABOLDI; CONTI; DELMASTRO,

2014). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.5 Diagrama de transição de estados do framework WiFi-Opp. Fonte: (TRIFUNO-

VIC, 2011). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.6 Diagrama de transição de estados de WLAN-Opp. Fonte: (TRIFUNOVIC, 2015). 28

3.7 Diagrama de transição de estados do framework LISOpp. Fonte: (DUBOIS, 2013a). 29

3.8 Exemplo da estrutura rede de comunicação criada pelo framework MA-Fi. Fonte:

(WIRTZ, 2011). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.9 Esquema básico de funcionamento do projeto ZebraNet. Fonte: adaptado de

(BAZA CUÑADO, 2011). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.10 Esquema geral da arquitetura do projeto DakNet. Fonte: (PENTLAND; FLET-

CHER; HASSON, 2004). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.11 Arquitetura de sistema do projeto CarTel. Fonte: (HULL, 2006). . . . . . . . . . 34

3.12 Arquitetura geral do projeto BikeNet. Fonte: (EISENMAN, 2009). . . . . . . . . 35

4.1 Arquitetura do middleware Net-Opp. . . . . . . . . . . . . . . . . . . . . . . . 40

4.2 Diagrama de estados do módulo Gerenciador de Rede. . . . . . . . . . . . . . 41

4.3 Módulos em execução com a rede de comunicação estabelecida. . . . . . . . . 43

5.1 Diagrama de atividades do módulo Gerenciador de Rede do middleware Net-Opp. 49

5.2 Imagens da aplicação Crowd Wi-Fi. . . . . . . . . . . . . . . . . . . . . . . . 50

5.3 Imagens da aplicação Crowd Wi-Fi. . . . . . . . . . . . . . . . . . . . . . . . 51

5.4 Organização dos componentes no veículo. . . . . . . . . . . . . . . . . . . . . 52

5.5 Diagrama de atividades do módulo Gerenciador de Rede do middleware Net-Opp. 53

5.6 Troca de conteúdos em um possível contato oportunista em uma estrada. . . . . 55

5.7 Entrega de um conteúdo tolerante a atrasos a uma infraestrutura na via. . . . . . 55

6.1 Vista aérea da região de experimentação. Os números correspondem a cada

dispositivo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.2 Vista aérea da região de experimentação. Ponto 1 é a infraestrutura fixa. Ponto

2 é o veículo móvel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.1 Tempo de associação da rede de comunicação. . . . . . . . . . . . . . . . . . . 65

7.2 Atraso médio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.3 Taxa de transmissão de pacotes. . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.4 Tempo de transferência de arquivos. . . . . . . . . . . . . . . . . . . . . . . . 67

7.5 Tempo de associação da rede de comunicação. . . . . . . . . . . . . . . . . . . 68

7.6 Taxa de transmissão de pacotes. . . . . . . . . . . . . . . . . . . . . . . . . . 69

7.7 Tempo de entrega de arquivos. . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.8 Média de perda de pacotes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.9 Atraso médio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7.10 Taxa de transmissão média. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

B.1 Diagrama de classes do módulo Gerenciador de Rede. . . . . . . . . . . . . . 89

B.2 Diagrama de classes do módulo Gerenciador de Informações. . . . . . . . . . 91

B.3 Diagrama de classes do módulo Provedor de Conteúdos. . . . . . . . . . . . . 93

LISTA DE TABELAS

3.1 Quadro comparativo das soluções de middlewares para redes oportunistas. . . . 37

4.1 Requisições que o submódulo AP aceita do submódulo STA. . . . . . . . . . . 43

LISTA DE CÓDIGOS FONTE

B.1 Interface que possui a definição dos métodos para acesso ao Net-Opp. . . . . . 87

SUMÁRIO

CAPÍTULO 1 – INTRODUÇÃO 1

1.1 Problemática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Hipótese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5 Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

CAPÍTULO 2 – FUNDAMENTAÇÃO TEÓRICA 8

2.1 Computação Pervasiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Ambientes Pervasivos . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Redes Tolerantes a Atrasos e Desconexões . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Tipos de Contatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.2 Redes Oportunistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Redes Sem Fio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.1 Wi-Fi (IEEE 802.11) . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.1.1 Modos de Operação do Wi-Fi . . . . . . . . . . . . . . . . . 15

2.3.2 Tecnologia Wi-Fi Tethering . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.2.1 Desafios do Wi-Fi Tethering . . . . . . . . . . . . . . . . . . 18

CAPÍTULO 3 – TRABALHOS RELACIONADOS 20

3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Middlewares para Redes Oportunistas . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 Haggle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.2 MobiClique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.3 Shair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.4 CAMEO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3 Frameworks para Comunicações Oportunistas . . . . . . . . . . . . . . . . . . 26

3.3.1 WiFi-Opp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3.2 WLAN-Opp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3.3 LISOpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3.4 MA-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.4 Aplicações para Redes Tolerantes a Atrasos e Desconexões . . . . . . . . . . . 31

3.4.1 ZebraNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.4.2 DakNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4.3 CarTel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.4.4 BikeNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.5 Comparação Entre Net-Opp e os Trabalhos Relacionados . . . . . . . . . . . . 36

CAPÍTULO 4 – O MIDDLEWARE NET-OPP 39

4.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3 Funcionamento dos Módulos . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4 Contorno às limitações do modo infraestrutura . . . . . . . . . . . . . . . . . . 44

4.5 Distribuição de Conteúdos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.6 Gerenciamento das Informações da Rede . . . . . . . . . . . . . . . . . . . . . 46

4.7 Segurança e Privacidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

CAPÍTULO 5 – PROVAS DE CONCEITO 48

5.1 Relevância do Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2 Aplicação Crowd Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2.1 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.2.2 Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2.3 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.3 Aplicação Black Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.3.1 Organização e Implementação . . . . . . . . . . . . . . . . . . . . . . 52

5.3.2 Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.3.3 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

CAPÍTULO 6 – METODOLOGIA DE AVALIAÇÃO 57


6.1.1 Tempo de Formação Topológica da Rede de Comunicação . . . . . . . 58

6.1.2 Tempo de Atraso dos Pacotes . . . . . . . . . . . . . . . . . . . . . . 58

6.1.3 Taxa de Transmissão . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.1.4 Tempo de Transferência de Arquivos . . . . . . . . . . . . . . . . . . 59


6.2.1 Comunicação Entre Veículo Para Veículo . . . . . . . . . . . . . . . . 60

6.2.1.1 Tempo de Formação Topológica de Rede . . . . . . . . . . . 60

6.2.1.2 Taxa de Transmissão . . . . . . . . . . . . . . . . . . . . . . 60

6.2.1.3 Tempo de Entrega de Arquivo Tolerante a Atrasos e Desco-

nexões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.2.2 Comunicação Entre Veículo Para Infraestrutura . . . . . . . . . . . . . 62

6.2.2.1 Taxa de Perda de Pacotes . . . . . . . . . . . . . . . . . . . 63

6.2.2.2 Atraso na Transmissão . . . . . . . . . . . . . . . . . . . . . 63


CAPÍTULO 7 – RESULTADOS EXPERIMENTAIS 64


7.1.1 Tempo de Formação Topológica da Rede de Comunicação . . . . . . . 64

7.1.2 Tempo de Atraso dos Pacotes . . . . . . . . . . . . . . . . . . . . . . 65

7.1.3 Taxa de Transmissão . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.1.4 Tempo de Transferência de Arquivos . . . . . . . . . . . . . . . . . . 67


7.2.1 Comunicação Entre Veículo Para Veículo . . . . . . . . . . . . . . . . 68

7.2.1.1 Tempo de Formação Topológica da Rede de Comunicação . . 68


7.2.1.3 Tempo de Entrega de Arquivo Tolerante a Atrasos e Desco-

nexões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

7.2.2 Comunicação Entre Veículo Para Infraestrutura . . . . . . . . . . . . . 70

7.2.2.1 Taxa de Perda de Pacotes . . . . . . . . . . . . . . . . . . . 71

7.2.2.2 Atraso na Transmissão . . . . . . . . . . . . . . . . . . . . . 72


7.3 Observações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

CAPÍTULO 8 – CONCLUSÕES 74

8.1 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

8.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

8.3 Produção e Inovação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

REFERÊNCIAS 77

GLOSSÁRIO 83

APÊNDICE A – CÓDIGO FONTE DO MIDDLEWARE NET-OPP 86

APÊNDICE B – MODELAGEM DA ARQUITETURA DE NET-OPP 87

B.1 Módulo API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

B.2 Módulo Gerenciador de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

B.3 Módulo Gerenciador de Informações . . . . . . . . . . . . . . . . . . . . . . . 90

B.4 Módulo Provedor de Conteúdos . . . . . . . . . . . . . . . . . . . . . . . . . 92

Capítulo 1INTRODUÇÃO

Hoje em dia, as redes de comunicação sem fio tornaram-se essenciais no cotidiano de toda

sociedade (CASTELLS, 2009). As pessoas podem se conectar a redes de dados, acessar e dis-

ponibilizar conteúdos em qualquer lugar, por meio de diferentes dispositivos e tecnologias de

comunicação (GANTI; YE; LEI, 2011). Diversos dispositivos móveis (por exemplo, smartpho-

nes, tablets e micro-computadores) vêm se popularizando e evoluindo muito nos últimos anos,

tornando a cada dia que passa a interação do usuário final com o dispositivo uma experiência

menos virtual e mais realista (COTTRILL, 2013).

Esse cenário vem se mostrando propício para a viabilização do paradigma de Computação

Pervasiva (SAHA; MUKHERJEE, 2003), no qual dispositivos executam aplicações e integram-se

de forma transparente à vida das pessoas, auxiliando-as em suas tarefas. O avanço desse para-

digma, motivou o surgimento de um domínio denominado Redes Sociais Móveis (BEN MOKH-

TAR; CAPRA, 2009; KAYASTHA, 2011), que estuda a integração desse paradigma com os serviços

sociais da web (por exemplo, (HOFFMAN, 2003; ZUCKERBERG, 2004; CHEN; HURLEY; KARIM,

2005; DORSEY; WILLIAMS; STONE, 2006)). Essa integração possibilita aos usuários, que com-

partilham interesses e frequentam lugares em comum, interagirem em qualquer lugar, a qualquer

momento (CHURCHILL; HALVERSON et al., 2005; HUMPHREYS, 2010).

Essa interação se tornou possível através da troca de dados entre os dispositivos feita pela

rede de dados celular (por exemplo, 3G (Third Generation of Mobile Telecommunications Te-

chnology), e LTE (Long Term Evolution)). Entretanto, tecnologias como o Bluetooth e Wi-Fi

Direct abriram novas possibilidades de redes (MA; ZHAO; YUAN, 2014), como exemplo, a MA-

NET (Mobile Ad Hoc Network), que permite que dispositivos se comuniquem diretamente entre

si através de múltiplos saltos dentro da rede usando receptores e transmissores sem fio sem a

necessidade de uma infraestrutura fixa (PERKINS, 2008). As MANETs evoluíram muito e deram

origem a novos tipos de redes, entre elas está as redes oportunistas.

1 Introdução 2

Segundo Pelusi, Passarella e Conti (2006), redes oportunistas são uma das evoluções mais

interessantes de MANETs, pois neste tipo de rede de comunicação os dispositivos móveis po-

dem se comunicar uns com os outros, mesmo se uma rota para conectá-los não existe. Este tipo

de abordagem de comunicação é feita através de oportunidades de encontros não programa-

dos entre dispositivos móveis que trocam dados (através de Bluetooth, Wi-Fi Direct ou Wi-Fi

Ad-Hoc) entre si até que a mensagem chegue ao destinatário (BOLDRINI, 2014).

Redes oportunistas podem trazer vários benefícios para as redes baseadas em infraestrutura

sem fio (3G e LTE), por exemplo, na utilização eficiente do espectro radioelétrico disponí-

vel (VUKADINOVIC; KARLSSON, 2010) ou em reduzir a carga de tráfego celular (HAN, 2010),

sendo assim, uma solução para nova geração de telefonia celular, a 5G (Fifth Generation of

Mobile Telecommunications Technology) (MUMTAZ, 2014). Além disso, Segundo Martín Cam-

pillo (2013), ela é ótima para lidar com falhas de infraestrutura de comunicação, parciais ou

totais causadas por desastres naturais (DEKKER; KARSBERG; LAKKA, 2013), censura do governo

(HELFT; BARBOZA, 2010) ou por até uma interrupção de Internet (CHEN, 2011).

Redes oportunistas tem sido um tema de pesquisa há anos, produzindo diversas arquiteturas

de comunicação (SU, 2007; PIETILAINEN, 2009; DUBOIS, 2013b; ARNABOLDI; CONTI; DELMAS-

TRO, 2014). No entanto, uma rede oportunista entre dispositivos móveis depende das capa-

cidades de tais dispositivos para estabelecer comunicação entre si. Embora as tecnologias de

interface sem fio, Bluetooth, Wi-Fi Direct e Wi-Fi Ad-Hoc oferecem tais capacidades em teo-

ria, limitações da especificação do protocolo, chipsets1 e sistemas operacionais em dispositivos

móveis tornam essas tecnologias em grande parte não aplicadas na prática.

Dispositivos móveis atuais (por exemplo, smartphones, tablets e micro-computadores) não

suportam a tecnologia Wi-Fi Ad-Hoc (GROUP et al., 2007), a não ser com firmwares2 custo-

mizados que exigem acesso root ao SO (Sistema Operacional) do dispositivo, como feito nos

trabalhos (DUBOIS, 2013b) e (ARNABOLDI; CONTI; DELMASTRO, 2014). A tecnologia Bluetooth

é limitada em termos de alcance de comunicação e largura de banda, bem como descoberta sem

interação humana (HAARTSEN, 2000). Além disso, a tecnologia Bluetooth leva muito tempo

para parear3 e muitas das tentativas de pareamento não são feitas com sucesso (PIETILAINEN,

2009). Comunicação através da tecnologia Wi-Fi Direct é outra opção, mas requer pareamento,

podendo demorar até dois minutos para formação de grupo e ainda requer interação do usuário

com o dispositivo (ALLIANCE, 2010).

1Chipsets são um conjunto de circuitos integrados que são responsáveis por fazer com que todos os componen-tes do dispositivo possam trocar informações e assim realizar as tarefas que exigimos deles.

2Firmwares são um conjunto de instruções operacionais que são programadas diretamente no hardware deequipamentos eletrônicos.

3Parear é o termo usado para designar uma associação de segurança obrigatória entre dois dispositivos.

1 Introdução 3

Essas características das tecnologias citadas, impedem na prática o desenvolvimento de

aplicações que necessitam de comunicação transparente, isto é, formação da rede de comu-

nicação e a troca de conteúdos sem a necessidade de interação do usuário com o dispositivo.

Para superar essas deficiências é proposto o middleware Net-Opp. Baseado na tecnologia Wi-Fi

modo infraestrutura (modo ponto de acesso do Wi-Fi), Net-Opp cria a capacidade de comunica-

ção entre os dispositivos de forma transparente, sem que haja pareamento entre os dispositivos.

Net-Opp automaticamente analisa pontos de acesso disponíveis no ambiente e se associa com

um ponto, se nenhum ponto de acesso for encontrado, Net-Opp habilita o modo infraestrutura

Wi-Fi do dispositivo, transformando-o em um ponto de acesso para prover uma rede de comu-

nicação para outros dispositivos, viabilizando a troca transparente de conteúdos entre os dispo-

sitivos. Todo esse processo é realizado automaticamente sem exigir pareamento e alteração no

SO dos dispositivos.

Os principais benefícios do middleware proposto podem ser avaliados sob o ponto de vista

dos desenvolvedores de aplicações oportunistas. O sistema oferece uma camada de interope-

rabilidade entre as diferentes aplicações e a rede oportunista. O middleware Net-Opp cria a

abstração da formação da rede oportunista e da troca de conteúdos, fornecendo serviços para as

várias aplicações, facilitando o trabalho do desenvolvedor, liberando-o de se preocupar com a

infraestrutura da rede e da troca de conteúdos. O usuário pode escrever sua aplicação e conectá-

la sem impacto ao middleware. Essas características tornam o middleware uma abordagem

prática para aplicações de redes oportunistas.

O presente trabalho apresenta a arquitetura do middleware proposto e a descrição do seu

funcionamento. Além disso, como prova de conceito foram criadas e demonstradas as seguintes

aplicações:

• A primeira aplicação, Crowd Wi-Fi, permite o compartilhamento transparente de arquivos

de um diretório local do dispositivo para outros dispositivos conectados à rede oportunista

provida pelo Net-Opp.

• A segunda aplicação, Black Box, permite a entrega tolerante a atraso de vídeos de um

veículo origem para diversos veículos destino conectados à rede oportunista provida pelo

Net-Opp.

1.1 Problemática 4

1.1 Problemática

Segundo Wang (2014), existe um pequeno número de middlewares (SU, 2007; PIETILAI-

NEN, 2009; DUBOIS, 2013b; ARNABOLDI; CONTI; DELMASTRO, 2014) voltados para o desenvol-

vimento de redes oportunistas e cada um deles propõe uma solução diferente. Dessa forma,

é possível perceber que os pesquisadores ainda buscam soluções eficientes para problemas de

conectividade, escalabilidade e eficiência energética. Dentro desse contexto, as soluções de

middlewares na literatura têm apresentado os seguintes problemas:

• Perda de conectividade entre os dispositivos móveis da rede, uma vez que a tecnologia

Bluetooth não suporta grande distâncias de comunicação e transmite em baixa velocidade

(HAARTSEN, 2000);

• Descoberta e troca de dados com necessidade de interação humana com o dispositivo,

uma vez que tecnologias como o Bluetooth ou Wi-Fi Direct necessitam de pareamento

para formarem a rede e trocarem conteúdos (ALLIANCE, 2010);

• Tempo consideravelmente alto para parear os dispositivos e muitas das tentativas de pare-

amento não são feitas com sucesso, impedindo mobilidade dos dispositivos (PIETILAINEN,

2009);

• Nem todos os dispositivos móveis e SOs móveis suportam a tecnologia Wi-Fi Ad-Hoc

(GROUP et al., 2007), e quando suportada a tecnologia nos dispositivos, é necessário alte-

ração do SO Móvel para ativa-lá, como foi feito nos trabalhos (DUBOIS, 2013b; ARNA-

BOLDI; CONTI; DELMASTRO, 2014).

1.2 Hipótese

Seguindo esse raciocínio, este trabalho se propõe a responder a seguinte questão:

• O uso do Wi-Fi para alternância entre escaneamento e ponto de acesso (modo infraes-

trutura) para formação de rede na camada de comunicação de um middleware para redes

oportunistas traria comunicação transparente e a execução de aplicações sem a necessi-

dade de alteração no SO móvel dos dispositivos?

1.3 Objetivos 5

1.3 Objetivos

Nesta Seção são apresentados os objetivos geral e específicos relacionados a este trabalho.

1.3.1 Objetivo Geral

Este trabalho tem como objetivo geral responder a hipótese definida na Seção 1.2, a partir

do desenvolvimento do middleware Net-Opp, um middleware que, por meio da tecnologia Wi-

Fi (padrão IEEE 802.11), visa criar um processo de alternância entre escaneamento de redes

Wi-Fi e transformar o dispositivo em ponto de acesso (modo infraestrutura) para proporcionar

uma rede de comunicação oportunista sem interação humana e sem alteração no SO móvel dos

dispositivos.

1.3.2 Objetivos Específicos

Os objetivos específicos desse trabalho são:

• Propor uma nova arquitetura de middleware nomeada de Net-Opp para redes oportunistas

baseada em um processo de alternância entre os modos de operação de escaneamento de

redes e ponto de acesso do Wi-Fi;

• Como provas de conceito, são propostos a implementação e a avaliação dessa nova arqui-

tetura de middleware em dois ambientes reais e diferentes, sendo o primeiro de dispositi-

vos móveis pessoais através da plataforma Android, e o segundo de dispositivos móveis

veiculares através da plataforma Linux;

• Realizar uma revisão bibliográfica na literatura buscando arquiteturas de middlewares,

frameworks e aplicações voltadas ao contexto de redes tolerantes a atrasos e desconexões,

e redes oportunistas. Trabalhos estes, que se assemelham a arquitetura e objetivos do

middleware Net-Opp;

• Disponibilizar uma API (Application Programming Interface) para o desenvolvimento de

aplicações de redes oportunistas sobre o middleware Net-Opp, visando às plataformas de

sistemas móveis Android e Linux.

1.4 Metodologia 6

1.4 Metodologia

Fazendo uso da definição de Appolinário (2007), o qual salienta que pesquisas aplicadas

têm o objetivo de “resolver problemas ou necessidades concretas e imediatas”, este trabalho

pode ser classificado como de natureza aplicada, uma vez que este trabalho tem como meta o

desenvolvimento de um middleware voltado para solucionar problemas relacionados as redes

oportunistas.

Para executar este trabalho e alcançar os objetivos propostos na Seção 1.3, foi realizada

uma pesquisa exploratória, segundo a abordagem de Wazlawick (2009). Através dessa pesquisa

foi realizado um levantamento dos trabalhos no estado da arte na literatura relacionados à mid-

dlewares para redes oportunistas, a fim de proporcionar uma maior familiaridade com o objeto

de estudo.

Além do levantamento bibliográfico a respeito de middlewares, também foi necessário re-

alizar uma pesquisa bibliográfica a respeito das redes tolerantes a atrasos e desconexões, redes

oportunistas, aplicações oportunistas, e da tecnologia Wi-Fi e seus modos de operação, já que

estes tipos de redes, aplicações e tecnologias são partes fundamentais da arquitetura do mid-

dleware Net-Opp.

É importante ressaltar que neste trabalho foi feita uma abordagem híbrida com relação a

pesquisa, ou seja, ela foi qualitativa e quantitativa, levando em consideração os conceitos apre-

sentados em Moreira (2002). Isso é justificado pelo fato de que este trabalho expõe o detalha-

mento do middleware Net-Opp, no que se refere a sua arquitetura e seus principais recursos,

e apresentar um comparativo entre ele e as soluções de middleware para redes oportunistas

presentes na literatura.

Este trabalho também apresenta dois estudos de caso, os quais foram desenvolvidos para

serem utilizados como prova de conceito para avaliação do middleware Net-Opp. Foram fei-

tas avaliações do tempo na formação de topologia de rede móvel, atraso na transferência de

arquivos e taxa de transmissão de arquivos entre dispositivos móveis nos dois cenários reais

de dispositivos móveis pessoais e veiculares. Através dessas avaliações foram gerados dados

estatísticos relacionados ao desempenho do middleware Net-Opp, os quais são apresentados na

forma de gráficos e discutidos no Capítulo 7.

1.5 Estrutura da Dissertação 7

1.5 Estrutura da Dissertação

Esta dissertação está dividida em oito capítulos. Neste primeiro capítulo foi apresentado

uma introdução e o restante dessa dissertação esta organizada em mais sete capítulos citados

nos tópicos abaixo. Os tópicos a seguir descrevem resumidamente o conteúdo de cada um

destes capítulos:

• No Capítulo 2 é apresentado a fundamentação teórica necessária para o entendimento

desse trabalho, onde são abordados conceitos relativos à Computação Pervasiva, redes

tolerantes a atrasos e desconexões, redes oportunistas, redes sem fio, e os modos de ope-

ração da tecnologia Wi-Fi;

• No Capítulo 3 são apresentados os trabalhos relacionados referentes aos middlewares,

frameworks e aplicações para as redes oportunistas, um breve comparativo entre eles e o

middleware Net-Opp;

• No Capítulo 4 é apresentado a visão geral da arquitetura do middleware Net-Opp, suas

principais características e funcionalidades;

• No Capítulo 5 são apresentadas as provas de conceito que foram desenvolvidos sobre o

middleware Net-Opp, sendo que na Subseção 5.2 é apresentado a aplicação Crowd Wi-Fi

para dispositivos móveis pessoais, e na Subseção 5.3 é apresentado a aplicação Black Box

para dispositivos móveis veiculares;

• No Capítulo 6 é apresentada a metodologia de avaliação do middleware Net-Opp, sendo

apresentado os cenários e métricas avaliadas;

• No Capítulo 7 são apresentados os resultados experimentais e as análises realizadas sobre

os experimentos;

• Finalmente no Capítulo 8 são apresentadas as conclusões, contribuições que esse trabalho

gerou, e os trabalhos futuros.

Capítulo 2FUNDAMENTAÇÃO TEÓRICA

Neste capítulo é apresentado o embasamento teórico que norteia os principais domínios

de conhecimentos envolvidos neste trabalho. Inicialmente, será apresentada uma breve des-

crição sobre o paradigma de Computação Pervasiva, destacando seus princípios e os fatores

necessários para sua viabilização. A segunda parte deste capítulo descreve o domínio das Re-

des Tolerantes a Atrasos e Desconexões e sua subárea de Redes Oportunistas. Ao final, são

apresentados as Redes Sem Fio e a tecnologia Wi-Fi (padrão IEEE 802.11) e seus modos de

operação (por exemplo, estação e infraestrutura).

2.1 Computação Pervasiva

O paradigma de Computação Pervasiva foi definido por Mark Weiser, em 1991, quando

publicou o trabalho contendo as bases para esse paradigma (WEISER, 1991). Nesse trabalho foi

apresentado um mundo no qual a computação e as aplicações estariam embutidas nos objetos do

dia-a-dia, de forma integrada ao ambiente. Esses objetos seriam capazes de interagir uns com os

outros de forma transparente, isto é, sem serem notados ou requererem interação dos usuários.

Nessa perspectiva, recursos computacionais seriam utilizados sem o conhecimento dos usuários,

com o objetivo de realizar ações de acordo com as suas necessidades e preferências e tornar

disponíveis informações relevantes para eles, no lugar e momento certo (LOUREIRO, 2008).

Para que a visão de Weiser sobre o paradigma de Computação Pervasiva pudesse ser con-

cretizada, três elementos principais deveriam estar disponíveis, conforme ilustrado na Figura

2.1: dispositivos baratos e com baixo consumo de energia, rede sem fio e sistemas que imple-

mentassem aplicações pervasivas (LOUREIRO, 2008). No entanto, a época que Weiser lançou o

paradigma de Computação Pervasiva, esses elementos não apresentavam um estágio de desen-

volvimento avançado, nem a massificação e popularização necessárias para tornar realidade.

2.1 Computação Pervasiva 9

Figura 2.1: Visão geral dos princípios de Computação Pervasiva. Fonte: adaptado de (SALES,2010).

Segundo Ma, Zhao e Yuan (2014), nos últimos anos, esse cenário sofreu uma mudança sig-

nificativa com a popularização do acesso à Internet, em conjunto com o extraordinário avanço

das tecnologias de comunicação sem fio (por exemplo, Bluetooth, Wi-Fi, 3G, Wi-Max, entre

outros) e a massificação dos dispositivos móveis no mercado consumidor, principalmente, note-

books, smartphones e wearables. Os dois últimos, em especial, estão se tornando cada vez mais

baratos, acessíveis e com uma grande gama de recursos disponíveis, tais como câmera digital,

vídeo, GPS, bússola digital, acelerômetro, conexões Wi-Fi, 3G, Bluetooth, dentre outros.

Consequentemente, tem-se tornado cada vez mais comum o fato das pessoas estarem sem-

pre portando seus dispositivos móveis, assim como, passarem grande parte do tempo conectadas

à Internet, em qualquer lugar, a qualquer momento (PEJOVIC; MUSOLESI, 2015). Esse novo ce-

nário tem se mostrado propício para a viabilização do paradigma de Computação Pervasiva e

para o desenvolvimento de aplicações que possam ser executadas em ambientes pervasivos.

2.1.1 Ambientes Pervasivos

Ambientes pervasivos podem ser definidos como ambientes saturados com capacidade de

computação e comunicação (SATYANARAYANAN, 2001). Dentre as suas principais caracterís-

ticas, destacam-se a heterogeneidade e a dinamicidade. A primeira característica está relacio-

nada com a diversidade de: dispositivos com poder de processamento distintos que podem estar

presentes no ambiente (por exemplo, wearables, smartphones, netbooks, notebooks, computa-

dores pessoais, etc); interfaces de comunicação sem fio (por exemplo, Bluetooth, Wi-Fi, 3G,

etc); Sistemas Operacionais; etc. Já a segunda característica está relacionada à: capacidade de

2.2 Redes Tolerantes a Atrasos e Desconexões 10

mobilidade de tais dispositivos, permitindo que estes possam entrar/sair do ambiente a qualquer

momento; capacidade de um dispositivo passar a fornecer ou deixar de fornecer algum serviço.

Segundo Yu (2013), no nível de rede, a mobilidade e a descoberta de usuários são duas

características importantes para ambientes pervasivos. A primeira permite que as aplicações

movam-se entre as diversas redes existentes em um ambiente pervasivo, sem interromper a

execução de um serviço. A segunda característica permite que os dispositivos descubram uns

aos outros na rede e que possam trocar informações, compartilhar recursos, ou ainda, executar

os serviços disponíveis na rede.

A ideia de dispositivos transparentemente integrados aos seres humanos aliada à necessi-

dade de lidar com as características de ambientes pervasivos, requer que as aplicações se adap-

tem em tempo de execução às alterações no ambiente e às necessidades dos usuários. Dentro

do escopo de Computação Pervasiva, esta adaptabilidade é guiada por dois elementos chave: as

noções de contexto e ciência de contexto (PERERA, 2014). Entretanto, como o foco do trabalho

está no nível de rede, este assunto não será amplamente discutido.

2.2 Redes Tolerantes a Atrasos e Desconexões

As DTNs (Delay and Disruption Tolerant Networks), ou Redes Tolerantes a Atrasos e Des-

conexões, são um tipo de rede com conexão intermitente na qual um caminho fim-a-fim entre

os dispositivos móveis que estão comunicando pode nunca existir (VASILAKOS; ZHANG; SPYRO-

POULOS, 2011).

Segundo Oliveira (2007), as principais características encontradas em um tipo de rede DTN

são as seguintes:

• Atrasos longos e/ou variáveis – uma DTN pode chegar a ter atrasos da ordem de horas e,

até mesmo, dias. A variação do atraso também pode chegar a estes valores;

• Frequentes desconexões – desconexões podem ocorrer pela mobilidade que provoca cons-

tantes mudanças na topologia da rede, por péssimas condições de comunicação (desvane-

cimentos), por economia de recursos como em sensores sem fio onde sensores dormem

para poupar energia, por negação de serviço como o ato do inimigo sujar a frequência em

operações militares. Estes eventos podem resultar em uma conectividade intermitente da

rede, ou seja, na inexistência de um caminho fim-a-fim entre um nó origem e um nó de

destino.


Numa tentativa de contornar os problemas de atrasos e desconexões, as redes DTN imple-

mentam técnicas de comutação de mensagens e de armazenamento persistente. Uma mensagem

é enviada na rede pelo modo armazena e encaminha (store-and-forward), nó a nó, até alcan-

çar o nó destino. Por fazer uso desta técnica, as redes DTNs são conhecidas por redes do tipo

armazena-e-encaminha. Assim, não há necessidade alguma do nó destino estar ativo no mo-

mento que o nó origem envia a mensagem (MCMAHON; FARRELL, 2009).

Segundo Cerf (2007), para utilização da técnica de comutação de mensagens e armazena-

mento persistente de dados, foi necessário a criação de uma sobrecamada (overlay) abaixo da

camada de aplicação, denominada camada de agregação ou Bundle Layer. Nessa camada, todos

os nós pertencentes à rede DTN executam um protocolo para agregação, desde a origem até o

destino.

Além disso, as redes DTN estabelecem uma nomenclatura diferenciada com a inclusão de

diversos conceitos. Um deles é o conceito de região, que consiste em um agrupamento de nós

(fixos ou móveis) com características semelhantes. O nó que é responsável pela conexão entre

regiões é denominado de nó mensageiro. Esse é um tipo especial de nó, tipicamente móvel,

que participa de duas ou mais regiões a fim de proporcionar a conexão e a troca de informações

entre as regiões.

2.2.1 Tipos de Contatos

Outro conceito importante definido pelas redes DTN é o contato. Segundo Jain, Fall e Patra

(2004), um contato é o momento que dois nós se encontram na rede, uma oportunidade para

ocorrer uma transmissão de dados:

• Contato persistente: são contatos que estão sempre disponíveis. O nó pode enviar a

mensagem a qualquer momento que houver necessidade;

• Contato sob demanda: esse tipo de contato necessita que em algum momento uma ação

seja tomada com o objetivo de instanciar o contato. Depois de estabelecido, se comporta

como um contato persistente;

• Contato previsível: nesse tipo de contato os nós fazem previsões acerca do horário e da

duração do contato conforme históricos armazenados de contatos passados;

• Contato oportunista: contatos que ocorrem ao acaso, sem que haja prévia programação;

• Contato programado: tipo de contato no qual o momento e a duração do contato são

pré-estabelecidos.


2.2.2 Redes Oportunistas

Os contatos oportunistas ocorrem diante de encontros não previamente programados entre

os dispositivos móveis. Esse tipo de contato tem como objetivo obter vantagens de contatos

realizados totalmente ao acaso para realizar a comunicação com qualquer dispositivo que esteja

fora do alcance de um dispositivo origem. Assim, utilizando a capacidade dos dispositivos se

comunicarem localmente com os seus vizinhos para criar possibilidades de comunicação com

outros dispositivos que estão fora do alcance. Esta é uma característica inédita que não existe

similar na Internet convencional (GALATI, 2010).

Segundo Cerf (2007), o conceito de contato oportunista permite comunicação entre dispo-

sitivos móveis na qual em nenhum momento existe um caminho inteiramente conectado entre

eles, o que inviabiliza a comunicação na Internet convencional. Geralmente, os dispositivos que

estabelecem contatos oportunistas desconhecem qualquer informação acerca do estado, da lo-

calização ou dos padrões de mobilidade dos outros dispositivos. Além disso, os dispositivos são

autônomos, o que significa que cada dispositivo possui um controle independente de si mesmo

e de seus movimentos.

Nessa abordagem de comunicação oportunista, os dispositivos móveis utilizam tecnologias

de redes sem fio (por exemplo, Bluetooth, Wi-Fi Direct, entre outras) para estabelecerem uma

comunicação ponto-a-ponto e assim trocarem conteúdos entre si (CONTI; GIORDANO, 2014).

A Figura 2.2 ilustra o funcionamento da abordagem de comunicação das redes oportunistas.

Pode-se visualizar na Figura 2.2, que um dispositivo origem se comunica com um dispositivo

destino, através do envio de uma mensagem para qualquer dispositivo que estiver próximo. O

dispositivo que receber a mensagem pode se locomover e retransmitir a mensagem para outro

dispositivo, podendo este ser um dispositivo retransmissor ou o dispositivo destino.

Figura 2.2: Comunicação dos dispositivos em uma rede oportunista. Fonte: adaptado de (HU,2015).

2.3 Redes Sem Fio 13

A troca de mensagens ou conteúdos nos encontros entre os dispositivos é feita através de

tecnologias de redes sem fio (por exemplo, Bluetooth, Wi-Fi Direct, Wi-Fi Ad-Hoc). Apesar

de dispositivos terem tecnologia necessária para estabelecer comunicação ponto-a-ponto com

dispositivos vizinhos, estas tecnologias de rede sem fio ponto-a-ponto não são amplamente uti-

lizadas. Isso por que essas tecnologias apresentam descoberta e troca de dados com necessidade

de interação humana com o dispositivo (ALLIANCE, 2010), ou nem todos os dispositivos móveis

e SOs móveis tem suporte às novas tecnologias (GROUP et al., 2007).

Segundo Denko (2011), através da exploração da natureza dinâmica – pessoas que se des-

locam com os seus dispositivos – de tais redes oportunistas, muitas novas aplicações seriam

possíveis:

• Em caso de um desastre natural (por exemplo, um terremoto, tsunami ou furacão), que

destrói a infraestrutura de comunicação celular, rede oportunista pode ajudar a manter

as comunicações entre dispositivos móveis, e permitir a coordenação das operações de

salvamento;

• Em regiões ou locais onde não existe a infraestrutura de comunicação celular, rede oportu-

nista poderia conectar os dispositivos dos moradores e ajudá-los a melhorar suas relações

sociais;

• Quando a infraestrutura de comunicação celular é desligada (por exemplo, deliberada-

mente, de modo a suprimir os movimentos de liberdade de expressão, ou caso esteja

sobrecarregada), rede oportunista pode permitir que um conjunto de pessoas se comuni-

quem;

• Os jogos multijogadores ou aplicativos de troca de mensagens podem usar redes opor-

tunistas para encontrar outros participantes sem a necessidade de acesso à Internet e um

servidor intermediário.

2.3 Redes Sem Fio

Uma das principais características dos dispositivos móveis está na possibilidade do usuário

ter acesso a serviços de conteúdos a qualquer hora e de qualquer local que ele esteja (LOUREIRO,

2003). Para que isso possa ser viável, esses equipamentos fazem uso de um tipo especial de rede,

onde não existe a necessidade de cabos para o acesso aos serviços, a qual é conhecida como

rede sem fio (NICOPOLITIDIS, 2003).


Conforme é ilustrado na Figura 2.3, os padrões propostos pelo IEEE permitem configurar

arquiteturas de redes sem fio, como as redes pessoais WPAN (Wireless Personal Area Network),

as locais WLAN (Wireless Local Area Network), as metropolitanas WMAN (Wireless Metropo-

litan Area Network) e as de longa distância WWAN (Wireless Wide Área Network), oferecendo

boa mobilidade aos seus usuários (AKYILDIZ; WANG; WANG, 2005).

Figura 2.3: Alcance das redes sem fio. Fonte: (BORGES; LEMES; ALECRIM, 2007).

Apesar de existirem muitos outros padrões de redes sem fio na literatura, por exemplo, o

Bluetooth, o 3G, o LTE, o NFC (Near Field Communication) e o infravermelho, nesta Seção é

feito um maior detalhamento na tecnologia que foi utilizada no desenvolvimento do middleware

Net-Opp, ou seja, na tecnologia Wi-Fi (padrão IEEE 802.11).

2.3.1 Wi-Fi (IEEE 802.11)

A partir da necessidade de acesso a Internet em locais onde a rede cabeada estivesse inaces-

sível, diversos pesquisadores começaram a trabalhar em soluções baseadas em transmissores e

receptores de rádio de ondas e na comunicação entre esses equipamentos (PAHLAVAN, 2011).

Segundo Rappaport et al. (1996), dentre os muitos padrões que surgiram na década de 1990

como resultado dessas pesquisas está o protocolo IEEE 802.11, também conhecido como a tec-

nologia Wi-Fi, o qual, hoje, está presente em residências, aeroportos e escritórios. A arquitetura

IEEE 802.11 (CROW, 1997) é formada por vários componentes e serviços que interagem para

proporcionar a mobilidade da estação para as camadas superiores da pilha de rede:

• STA (Wireless LAN Station): é o componente mais básico da rede sem fio. Uma STA

é qualquer dispositivo que contém a funcionalidade do protocolo IEEE 802.11: controle

de acesso ao meio (MAC), a camada física (PHY), e uma ligação aos meios de comu-

nicação sem fio. Normalmente, as funções são implementadas no hardware e software

de um cartão de interface de rede (NIC). A estação pode ser um computador, notebook,


smartphone, wearable ou um ponto de acesso (AP). Todas as estações possuem serviços

de autenticação, desautenticação, privacidade e entrega de dados.

• BSS (Basic Service Set): uma rede BSS consiste de um simples Access Point (AP) que

suporta um ou mais clientes sem fio. Essa rede é também conhecida como Infrastructure

Wireless Network (Rede Infraestrutura). Nessa rede todas as estações se comunicam entre

si através de um AP. Esse tipo de rede tem o inconveniente de consumir o dobro da banda,

mas um dos grandes benefícios é o armazenamento dos dados enquanto as estações estão

em modo de economia de energia (Power Save). O AP provê conectividade entre as

estações e fornece funcionalidade de bridge quando uma estação inicia a comunicação

com outra estação ou com um nó do sistema de distribuição (Distribution System - DS).

• IBSS (Independent Basic Service Set): uma rede IBSS consiste de pelo menos duas esta-

ções, onde não há ponto de acesso que conecte a rede a um sistema de distribuição. Essa

rede também é conhecida como uma rede sem fio Ad-hoc.

• ESS (Extended Service Set): uma rede ESS é constituída por dois ou mais APs conectados

na mesma rede cabeada que pertencem ao mesmo segmento lógico (subnet), separado por

um roteador.

• DS (Distribution Systems): os APs de múltiplos BSSs são interconectados através do DS.

Isso provê mobilidade, pois as estações podem mover-se de um BSS para outro BSS. Os

APs podem ser interconectados através da rede cabeada ou não. O DS é o componente

lógico usado para interconectar BSSs. O DS provê serviços que permitem o roaming

entre as estações e os BSSs.

• SSID (Service Set Identifier): é um rótulo exclusivo que distingue uma WLAN de outro.

Assim, todos os APs e STAs tentando tornar-se uma parte de uma WLAN específica

devem usar o mesmo SSID. STAs sem fio usam o SSID para estabelecer e manter a

conectividade com APs.

2.3.1.1 Modos de Operação do Wi-Fi

As redes sem fios da tecnologia Wi-Fi podem operar em duas configurações (ou também

chamado de modo de operação), com e sem a presença de um ponto de acesso. Consequente-

mente, o padrão IEEE 802.11 leva em conta esse fato e prevê ambas as organizações em um

dispositivo. Os dois modos de operação são ilustrados na Figura 2.4, sendo que na Figura 2.4(a)

é ilustrado o modo de operação com a presença de um AP, e a Figura 2.4(b) é ilustrado o modo

de operação sem a presença de um AP.


(a) Com a presença de um AP. (b) Sem a presença de um AP.

Figura 2.4: Modos de operação da tecnologia Wi-Fi. Fonte: (TANENBAUM, 2003).

Segundo Roshan e Leary (2010), a configuração de rede apresentada na Figura 2.4(a) é

denominada de LAN com infraestrutura, onde um dispositivo se torna o AP e os demais dis-

positivos se conectam ao AP e o usa como ponto de comunicação para se comunicar com os

demais. A Figura 2.4(b) ilustra a configuração denominada ad hoc. Segundo Perkins (2008),

nesse tipo de organização não existe controle central. A rede é formada por dispositivos próxi-

mos uns dos outros que tenham necessidade de se comunicar.

Na configuração de rede sem fio LAN com infraestrutura, o AP e cada estação de trabalho

possui um endereço MAC de 6 bytes armazenado na sua placa de interface de rede 802.11.

A esse conjunto de AP e estações de trabalho se dá o nome de BSS. Conforme é ilustrado na

Figura 2.5, toda a comunicação realizada entre as estações presentes na BSS passa pelo AP.

Porém, para ter acesso ao AP a estação deve procurá-lo pelo seu SSID e associar-se a ele. É

importante lembrar que o AP deve estar conectado a um dispositivo de interconexão como um

hub ou um roteador para prover a ligação entre a BSS e a Internet.

Figura 2.5: Arquitetura lógica de uma rede 802.11. Fonte: (TELECO, 2015).


2.3.2 Tecnologia Wi-Fi Tethering

A tecnologia Wi-Fi Tethering foi um modo criado para permitir o compartilhamento de

acesso à Internet 3G e LTE de um smartphone a uma gama de dispositivos clientes. Esta tecno-

logia é suportada por todos os principais fabricantes de dispositivos e está disponível em todas

as principais plataformas de sistemas operacionais, tais como iOS 4.3+ (APPLE, 2015), Android

2.2+ (GOOGLE, 2015) e Windows 7.5+ (MICROSOFT, 2015).

Segundo Constantinescu (2014), além de compartilhar a Internet entre vários dispositivos

simultaneamente, conforme é ilustrado na Figura 2.6, a tecnologia Wi-Fi Tethering pode ser

usada para comunicações móveis de cliente para cliente e comunicações ponto de acesso para

cliente, permitindo assim comunicações oportunistas.

Figura 2.6: Exemplo de funcionamento do Wi-Fi Tethering. Fonte: (CONSTANTINESCU, 2014).

Entre todas as tecnologias móveis existentes, Wi-Fi Tethering é a única opção disponível

para compartilhar conexões de dados com outros dispositivos. Algumas outras técnicas de tethe-

ring existentes, como gateways de modem, proxies da camada de aplicação ou redirecionamento

de portas, fornecem apenas conectividade limitada e não permitem a utilização simultânea de

serviços de voz e dados (SCHULZ, 2012).

A tecnologia Wi-Fi Tethering utiliza o modo infraestrutura do Wi-Fi para para a criação da

rede, transformando o dispositivo ponto de acesso em uma ponte de comunicação. A Figura

2.7 ilustra como seu funcionamento diferencia do modo clássico de funcionamento do Wi-Fi.

Conforme é ilustrado na Figura 2.7(b), no Wi-Fi Tethering, um dispositivo móvel se torna um

ponto de acesso, e toda comunicação entre os demais dispositivos conectados é passado através

deste dispositivo, inclusive ele pode se comunicar com os dispositivos conectados a ele. Já no

modo clássico de funcionamento do Wi-Fi modo infraestrutura, ilustrado na Figura 2.7(a), o

dispositivo que é o ponto de acesso é um roteador ou qualquer outro dispositivo portátil fixo,

sendo apenas uma ponte de comunicação dos dispositivos conectados a ele.


(a) Modo infraestrutura clássico. (b) Modo infraestrutura no Tethe-ring.

Figura 2.7: Funcionamento do Wi-Fi modo infraestrutura e Tethering. Fonte: (BRUN, 2014).

2.3.2.1 Desafios do Wi-Fi Tethering

A tecnologia Wi-Fi Tethering apresenta como principal vantagem a comunicação de vários

dispositivos em uma rede WLAN (através do Wi-Fi modo infraestrutura) e a possibilidade de

formação de rede sem exigir interação com o usuário, isto é, sem pareamento obrigatório entre

os dispositivos. A Figura 2.8 ilustra os modos de operação dessa tecnologia e seus desafios.

(a) Dispositivos em modo esca-neamento não descobrem um aooutro.

(b) Dispositivos em modotethering não descobrem um aooutro.

(c) Dois grupos de comunica-ção não se comunicacam entresi.

Figura 2.8: Desafios apresentados pela tecnologia Wi-Fi Tethering. Fonte: adaptado de (TRIFUNO-VIC, 2015).

A pesar de todos esses benefícios apresentados, a tecnologia Wi-Fi Tethering apresenta

alguns problemas que, segundo Constantinescu (2014), se tornam desafios a serem superados.

Cada problema apresentado pela tecnologia Wi-Fi Tethering é descrito e apresentado nos itens

a seguir:

• Dispositivos no modo escaneamento podem procurar redes para descobrir APs, mas des-

conhecem outro dispositivo que também estiver no modo escaneamento (Figura 2.8(a)).

Um conjunto de dispositivos podem estar, assim, no alcance um do outro mas (ainda) não

conectados;


• Dispositivos APs não são capazes de procurar por redes e são, portanto, incapazes de

detectar um ao outro (Figura 2.8(b)). Dispositivos APs são apenas conscientes dos seus

clientes, ou seja, dispositivos que estão associados a eles. Assim, eles podem perder

oportunidades para se juntar a outras redes existentes na proximidade levando a redes em

um particionado (grupos disjuntos. Figura 2.8(c));

• Finalmente, os clientes associados a diferentes pontos de acesso não conseguem se co-

municar um com o outro. Esta é a segunda causa de grupos disjuntos que não são capazes

de se comunicar uns com os outros (Figura 2.8(c)).

Para superar esses desafios é proposto algumas técnicas que baseiam-se na utilização do

nível de bateria do dispositivo ou na criação de tempos randômicos. Essas técnicas são apre-

sentadas na Seção 4.4.

Capítulo 3TRABALHOS RELACIONADOS

Neste capítulo é feito uma breve introdução e apresentado os trabalhos relacionados re-

ferentes aos middlewares para redes oportunistas, aplicações para redes tolerantes a atrasos e

desconexões, e frameworks de alternância entre ponto de acesso e escaneamento de redes. Por

fim é apresentado um comparativo entre os trabalhos relacionados apresentados com a proposta

do middleware Net-Opp.

3.1 Introdução

Recentemente, na área de redes oportunistas, os protocolos de roteamentos foram mais

abordados que arquiteturas e aplicações práticas. Segundo Huang, Lan e Tsai (2008), um grande

número de algoritmos de encaminhamento, sem infraestruturas foram desenvolvidos. Os auto-

res desses trabalhos baseiam-se que os dispositivos móveis possuem a capacidade de troca e

encaminhamento de mensagens através de uma rede Wireless Ad-Hoc, utilizando tecnologias

sem fio, como o Bluetooth ou Wi-Fi.

Na maioria dos protocolos e algoritmos desenvolvidos a avaliação foi feita de forma si-

mulada. Com o surgimento de arquiteturas e aplicações práticas, experimentos demonstraram

diversas limitações (necessidade de pareamento e frequentes desconexões) das tecnologias uti-

lizadas para as redes oportunistas (PIETILÄINEN; DIOT, 2009). Assim, a seguir, são apresentados

trabalhos que discutem e contornam essas limitações.

Segundo Boldrini (2014), no ambiente móvel, o usuário deseja ter acesso à informação a

qualquer momento em qualquer lugar. Sendo assim, mesmo em ambientes em que o usuário não

tenha a acesso a roteadores ou torres de transmissão para se conectar a Internet, um middleware,

framework ou aplicação para redes oportunistas deve prover a ele alternativas de comunicação.

3.2 Middlewares para Redes Oportunistas 21

3.2 Middlewares para Redes Oportunistas

Existem na literatura diversas soluções cuja meta é auxiliar no processo de desenvolvimento

de aplicações voltadas para o ambiente social móvel (HU, 2015). Essas soluções fazem uso de

diferentes arquiteturas, tecnologias de rede, entre outras características. Entretanto, algumas

pesquisas recentes demonstram que são poucas as soluções voltadas para as redes oportunistas

(WANG, 2014).

Segundo Wang (2014), para um middleware ser considerado de redes oportunistas, ele deve

promover uma comunicação oportunista, possibilitando trocas de informações e conteúdos em

possíveis encontros entre os dispositivos no cotidiano das pessoas. Sendo assim, nessa seção

são apresentados apenas trabalhos cuja proposta é possibilitar uma troca de informações e con-

teúdos para redes oportunistas.

3.2.1 Haggle

Projeto Haggle (SCOTT, 2006; SU, 2007) é a primeira arquitetura abrangente de redes autô-

nomas e oportunistas, projetado para permitir a comunicação na presença de conectividade de

rede intermitente, este sistema possibilita a troca de conteúdos entre os dispositivos em possí-

veis encontros. A Figura 3.1 ilustra a arquitetura do middleware Haggle.

Figura 3.1: Visão geral da arquitetura de Haggle. Fonte: (SU, 2007).


A arquitetura do middleware Haggle é internamente constituída por seis módulos. Cada

módulo é responsável por um componente ou uma estrutura modular de dados (em itálico no

diagrama) - esta arquitetura oferece flexibilidade, por exemplo, permitindo a muitos protocolos

(por exemplo, SMTP (Simple Mail Transfer Protocol) e HTTP (Hypertext Transfer Protocol))

e conectividades (por exemplo, 802.11 e Bluetooth) serem instanciados de forma simultânea

(SCOTT, 2006).

Todos os módulos têm APIs bem definidas, e cada módulo e seus componentes internos

podem utilizar a API de qualquer outro módulo para se comunicar. Externamente, a API de

camada de aplicação é um subconjunto de interfaces fornecidas pelos módulos individuais (SU,

2007).

Para estabelecer a conexão de rede sem fio e permitir a troca de conteúdos nos possíveis

encontros entre os dispositivos móveis, o middleware Haggle utiliza as tecnologias de rede

sem fio, Bluetooth ou Wi-Fi, possibilitando assim uma troca de dados descentralizada por ser

ponto-a-ponto.

Haggle tem sido uma plataforma escolhida para uma variedade de aplicações baseadas em

proximidade (por exemplo, comunicações em possíveis desastres, busca de amigos e localiza-

ções, e compartilhamento de imagens entre dispositivos móveis).

3.2.2 MobiClique

O MobiClique (PIETILAINEN, 2009) é um software social móvel que visa dar às pessoas

a possibilidade de se corresponderem e estenderem as suas redes sociais. Para alcançar esse

objetivo o MobiClique foi desenvolvido de forma descentralizada e faz uso de uma rede ad hoc

móvel onde a comunicação é feita via Bluetooth, de modo que conexões oportunísticas sejam

criadas entre dispositivos vizinhos.

O MobiClique foi implementado usando C++ e C# e roda apenas na plataforma Windows

Mobile. A comunicação oportunística é baseada na arquitetura de rede Haggle, onde os dados

entre os dispositivos são trocados em possíveis encontros entre os dispositivos.

O perfil social do MobiClique é representado por um identificador único para o usuário,

um nome de usuário, uma pequena descrição, uma lista de amigos e uma lista de grupos de

interesse. A inicialização dos perfis é feita através do uso da API do Facebook. O MobiClique

fornece uma estrutura genérica para o desenvolvimento de novos aplicativos de MSN (Mobile

Social Network) sobre o middleware.


A Figura 3.2 ilustra a estrutura do middleware MobiClique. Quando uma conexão oportu-

nística entre dois usuário é feita, se eles tem os mesmos amigos ou interesses, eles são alertados

e a partir daí podem começar a troca de conteúdo, ou seja, links e outros objetos como atuali-

zações de status.

Figura 3.2: Visão geral do sistema MobiClique. Fonte: (PIETILAINEN, 2009).

Uma das limitações encontradas nessa solução, refere-se a falta de escalabilidade na quan-

tidade de conexões realizadas através do Bluetooth entre os dispositivos móveis. Os testes

realizados pelos autores apresentaram um limite de apenas três conexões simultâneas por dis-

positivo. Dessa forma, perde-se a oportunidade de criar ou manter mais laços de amizade si-

multaneamente.

Esta solução de middleware também apresenta problemas em relação à privacidade das

informações dos usuários. Uma vez que, caso o dispositivo móvel não possua conexão com a

Internet, este dependerá de outro dispositivo ou computador pessoal que possua tal recurso para

obter ou atualizar as informações do perfil do usuário.

3.2.3 Shair

Shair (DUBOIS, 2013b) é um middleware para compartilhamento de recursos P2P (Peer-

to-Peer) móvel (como dados, armazenamento, conexões e computação) sem a necessidade de

conexões à Internet, que utiliza o projeto Haggle como fonte de inspiração.


A arquitetura de Shair, representada na Figura 3.3, é composta por três partes: Application

Logic, Middleware Logic e Device Specific Logic. Todos os componentes de Shair possuem

APIs e são acompanhadas de observadores adicionais usados para gerenciar as chamadas de

retorno.

Figura 3.3: Arquitetura do middleware Shair. Fonte: (DUBOIS, 2013b).

A Application Logic contém a lógica necessária para comunicação da aplicação para o

middleware, onde essa comunicação é possível através de um conjunto de APIs especializadas.

A Middleware Logic contém toda a estrutura para gerenciamento (adicionar, consultar, notificar,

atualizar, excluir, transferir) dos recursos do dispositivo, persistência de dados e tomadas de

decisão; A Device Specific Logic contém a implementação de APIs de baixo nível para acessar

redes (por exemplo, Wi-Fi, LTE, etc.) e dispositivos de armazenamento (por exemplo, memória

flash, armazenamento em nuvem, etc.).

Baseado no middleware Shair, um aplicativo Android, chamado MobileP2P Photo Sha-

ring App, foi desenvolvido, no qual, as imagens dos usuários em seus dispositivos podem ser

compartilhadas diretamente através de dispositivos sem conexões com a Internet, utilizando

Bluetooth ou Wi-Fi Ad-Hoc como fonte de comunicação.


3.2.4 CAMEO

CAMEO (Context-aware middleware for Opportunistic Mobile Social Networks) (ARNA-

BOLDI; CONTI; DELMASTRO, 2014) é um middleware que foca no gerenciamento e na elaboração

de informação baseada no contexto móvel para implementar um conjunto de serviços otimiza-

dos para redes oportunistas e para apoiar no desenvolvimento otimizado de aplicativos sensíveis

ao contexto.

Conforme é ilustrado na Figura 3.4, o middleware CAMEO é representado por dois fra-

meworks, o LRM-Fw (Local Resource Management Framework) e o CA-Fw (Context-Aware

Framework).

Figura 3.4: Arquitetura de software de CAMEO. Fonte: (ARNABOLDI; CONTI; DELMASTRO, 2014).

O LRM-Fw implementa características relacionadas estritamente a interação com os recur-

sos locais dos dispositivos, tanto de hardware (sensores embutidos, capacidade, bateria, inter-

faces wireless) quanto de software (primitivas de comunicação e bibliotecas de programação).

Por sua vez, o CA-Fw armazena, elabora e dissemina a informação contextual além de definir

protocolos de encaminhamentos otimizados.

3.3 Frameworks para Comunicações Oportunistas 26

Para otimizar e facilitar o desenvolvimento de aplicações MSN oportunísticas orientadas a

contextos sociais, o middleware CAMEO fornece uma API que permite a interação das apli-

cações desenvolvidas com as suas funções internas. A comunicação entre o CAMEO e as

aplicações está implementada em uma classe proxy em Java para Android. Além disso, a AIDL

(Android Interface Definition Language) é usada para definir a interface de chamada de cada

aplicação para notificações de eventos.

Esta solução de middleware também foi instalado em celulares para que turistas pudessem

trocar suas experiências. Essa troca de informações entre os dispositivos foi possível através

da utilização da tecnologia de rede sem fio Wi-Fi Ad-Hoc, que possibilitou a criação da rede

comunicação (KHAN, 2013).

3.3 Frameworks para Comunicações Oportunistas

Diferentemente dos middlewares apresentados na Seção anterior, que criam uma camada de

interoperabilidade entre as aplicações e o SO, um framework é uma abstração que une códigos

comuns entre vários projetos de software provendo uma funcionalidade genérica (GREENFIELD;

SHORT, 2003).

Segundo Wang (2014), existem na literatura algumas soluções de frameworks cuja meta é

encontrar uma alternativa de rede para aplicações oportunistas utilizando a tecnologia de rede

sem fio Wi-Fi modo infraestrutura. A seguir são apresentados e discutidos alguns desses fra-

meworks.

3.3.1 WiFi-Opp

Para superar a falta e inoperância da tecnologia de rede sem fio Wi-Fi Ad-Hoc em dis-

positivos móveis como smartphones e tablets, e possibilitar uma comunicação transparente,

Trifunovic (2011) desenvolveu o framework WiFi-Opp, que possibilita os dispositivos móveis

se comunicarem em possíveis encontros sem a necessidade de pareamento. O framework WiFi-

Opp funciona como uma máquina de estados, e é basicamente dividido em dois modos de

operação.

Conforme é ilustrado na Figura 3.5, no framework WiFi-Opp é sugerido dois modos de

operação: nós móveis analisam pontos de acesso no ambiente e se associam com um ponto de

acesso. Se nenhum ponto de acesso for encontrado, o dispositivo torna-se um ponto de acesso

para facilitar a comunicação para outros nós.


Figura 3.5: Diagrama de transição de estados do framework WiFi-Opp. Fonte: (TRIFUNOVIC,2011).

O maior desafio encontrado por Trifunovic (2011) em seu trabalho foi o problema de dois

dispositivos móveis sempre estarem no mesmo modo de operação (ponto de acesso ou cliente

conectado ao ponto de acesso) durante sua execução, não conseguindo estabelecer uma rede de

comunicação.

Para superar esse desafio, o trabalho WiFi-Opp define que todos os dispositivos móveis

devem a todo instante gerar tempos randômicos para serem utilizados como o tempo de alter-

nância entre o estado de ponto de acesso e o estado de escaneamento de redes Wi-Fi. Assim, a

probabilidade de dois dispositivos estarem no mesmo estado é bem menor, já que o tempo para

entrar nesse estado é gerado de forma aleatória e é diferente dos demais dispositivos móveis

que estão no mesmo ambiente.

3.3.2 WLAN-Opp

Enquanto que no trabalho WiFi-Opp é feita uma comparação do consumo de energia em

relação a tecnologia Wi-Fi Ad-Hoc e definido o processo de alternância entre escaneamento e

ponto de acesso, no trabalho WLAN-Opp (TRIFUNOVIC, 2015) é feito uma extensão de WiFi-

Opp, onde Trifunovic (2015) propõe um protocolo personalizado onde o framework tenta se

conectar a qualquer rede Wi-Fi disponível no ambiente (rede de roteadores Wi-Fi de locais

públicos e comércio geral).


Seguindo a ideia inicialmente proposta por (KÄRKKÄINEN; PITKÄNEN; OTT, 2013), WLAN-

Opp aproveita qualquer tipo de rede Wi-Fi e tenta se conectar a ela. Diferentemente do trabalho

WiFi-Opp que define apenas um tipo de rede para conexão, e esta rede é criada apenas por

WiFi-Opp através de configurações definidas nos dispositivos móveis, não aproveitando, por

exemplo, de pontos de acessos na cidade.

Segundo Trifunovic (2015), além de criar redes oportunistas como foi feito em WiFi-Opp,

a utilização de pontos de acessos públicos em cidades podem aumentar a troca de dados e a

capacidade de acesso a internet aos dispositivos a rede de dados.

Figura 3.6: Diagrama de transição de estados de WLAN-Opp. Fonte: (TRIFUNOVIC, 2015).

Conforme é ilustrado na Figura 3.6, WLAN-Opp define uma máquina de estados que rea-

liza transições. A seguir é descrito o funcionamento de cada um dos três modos de operação

definidos:

• Modo IDLE: O estado IDLE é o estado inicial de um nó de WLAN-Opp. O nó entra

nesse estado quando deixa de ser um cliente (STA) ou deixa de ter o papel de ponto de

acesso (AP). No estado IDLE, o nó verifica as redes disponíveis.

• Modo STA: Nós IDLE podem, eventualmente, encontrar uma rede disponível e se conec-

tar a ela. Conectado a um AP, o dispositivo passa ao modo STA. No modo STA, um nó

ainda pode procurar redes e muda para outra rede disponível.

• Modo AP: Se um nó IDLE não encontrar redes para se conectar, ele torna-se um AP e

cria uma rede por si só.


3.3.3 LISOpp

No framework LISOpp (Lightweight self-organizing reconfiguration of opportunistic in-

frastructure mode Wi-Fi networks) (DUBOIS, 2013a) também é proposto a utilização da ideia de

(TRIFUNOVIC, 2011, 2015) para alternar o dispositivo no modo de operação de ponto de acesso

e modo de operação escaneamento de redes Wi-Fi.

A diferença do LISOpp em relação aos demais frameworks está em sua melhor precisão

das decisões para qual estado o dispositivo deve estar, tendo em conta também as frequências

e tráfego de rede. Para isso, LISOpp utiliza protocolos e algoritmos para a criação de redes

oportunistas nas proximidades.

Assim como em (TRIFUNOVIC, 2011) e (TRIFUNOVIC, 2015), em LISOpp é definido uma

máquina de estados (representada na Figura 3.7) em que o dispositivo móvel se mantém cons-

tantemente alternando entre os estados de operação de forma a criar e gerenciar as redes opor-

tunistas.

Figura 3.7: Diagrama de transição de estados do framework LISOpp. Fonte: (DUBOIS, 2013a).


Cada círculo na Figura 3.7 representa um estado específico, que pode ser passivo (um estado

para dispositivos que não são clientes e nem pontos de acesso), cliente e ponto de acesso. Setas

simples representam um ECA (Event Condition Action), regras para que se desloquem de um

estado origem para um estado destino.

Uma regra de ECA somente é ativada quando ocorre um evento: nesse caso, se a condição

se mantém, então a ação é executada. Flechas tracejadas representam eventos imprevisíveis

que modificam o estado atual de forma determinística (que têm precedência sobre as outras

transições).

Conforme é ilustrado na Figura 3.7, as transições são executadas de acordo com intervalos

gerados a partir de uma distribuição exponencial. Quando duas transições executam ao mesmo

tempo, apenas uma é executada de acordo com, por exemplo, a uma distribuição de probabili-

dade uniforme aleatória.

3.3.4 MA-Fi

No framework MA-Fi (Mobile Ad-Hoc Wi-Fi) (WIRTZ, 2011) os autores criaram um pro-

cesso de virtualização da interface de rede Wi-Fi nos dispositivos móveis, nesse caso compu-

tadores pessoais (notebooks), para permitir que os dispositivos móveis simultaneamente assu-

missem os papéis de ponto de acesso e escaneamento de redes Wi-Fi. A Figura 3.8 ilustra um

exemplo de funcionamento dessa estrutura de comunicação.

Figura 3.8: Exemplo da estrutura rede de comunicação criada pelo framework MA-Fi. Fonte:(WIRTZ, 2011).

3.4 Aplicações para Redes Tolerantes a Atrasos e Desconexões 31

Especificamente, no framework MA-Fi (representado na Figura 3.8) foi criado uma hierar-

quia de dois níveis de nós roteadores (RONS) que executam funções ad-hoc e nós de estação

(Stans) que estão conectados à rede ad-hoc através de um RON. A partir da perspectiva de um

STAN, o RON se comporta como um ponto de acesso (Wi-Fi modo infraestrutura) comum que

conecta o STAN para a totalidade da rede ad-hoc.

Como nesse processo criado cada dispositivo assume o papel de cliente e ponto e acesso,

este tipo de estrutura permite que os dispositivos consigam enviar mensagens em vários saltos,

possibilitando assim comunicação multihop. No entanto, a virtualização das interfaces de rede

não é suportado em dispositivos móveis, como smartphones e tablets.

3.4 Aplicações para Redes Tolerantes a Atrasos e Descone-xões

Uma aplicação ou um programa informático, é uma coleção de instruções que descrevem

uma tarefa a ser realizada por um computador (incluindo dispositivos em geral) (LLOYD, 2012).

Normalmente uma aplicação é desenvolvida para uma determinada tarefa gerando resultados

esperados.

Atualmente existem diversos programas que permitem a simulação de ambientes, por exem-

plo, o ambiente de redes DTN (KAUR; MALHOTRA, 2015). Essas simulações podem garantir um

menor custo da avaliação de projetos e até mesmo criar ambientes que são impossíveis por falta

de tecnologia existente. Apesar desses benefícios, os resultados de experimentos feitos em am-

bientes reais continuam tendo maior impacto que ambientes simulados (RUTTEN; JOOLINGEN;

VEEN, 2012).

Segundo Câmara (2011), por razões técnicas (por exemplo, da mobilidade do dispositivo)

ou fatores econômicos (por exemplo, não há infraestrutura fixa), a topologia da rede muda

constantemente e caminhos fim-a-fim raramente estão disponíveis em DTNs. Quase todas as

aplicações tradicionais não conseguem trabalhar em tais redes.

Existem na literatura algumas soluções de aplicações cuja meta é explorar as características

inerentes as redes DTNs para a transmissão de mensagens, permitindo uma entrega de mensa-

gens tolerantes a atrasos mesmo em falta de infraestrutura de comunicação (WEI; LIANG; XU,

2014).


3.4.1 ZebraNet

O sistema ZebraNet (JUANG, 2002), conforme é ilustrado na Figura 3.9, consiste em coleiras

de rastreamento transportadas por zebras no âmbito de reservas da África. A estrutura da coleira

consiste de um GPS (Global Positioning System), uma memória flash, um receptor sem fios

(contendo as tecnologias de rede sem fio Wi-Fi e Bluetooth) e um pequeno processador de

baixo consumo.

Os colares operam como forma de conexão oportunista para transmitir dados de volta para

os pesquisadores. Isso significa que quando duas zebras se encontram, as coleiras registram as

informações de encontro e trocam os dados armazenados em suas memórias locais. Através

de oportunidades de encontro intermitentes, informação é gravada e depois difundida a essas

zebras que transportam coleiras de rastreamento.

Figura 3.9: Esquema básico de funcionamento do projeto ZebraNet. Fonte: adaptado de(BAZA CUÑADO, 2011).

Pesquisadores da vida selvagem semanalmente atravessam com um veículo a reserva de ani-

mais da África, principalmente próximos aos locais onde normalmente ficam as zebras. Dentro

do veículo é instalado uma estação base móvel (um computador com uma antena de alto alcance

de transmissão). Ao se locomover pela reserva, a estação base do veículo se encontra com as

zebras e recolhe todos os dados contidos em suas memórias.

As informações ao serem transmitidas pelo colar à estação base móvel, são automatica-

mente excluídas das memórias dos colares, para permitirem que novos dados seja armazenados.

As informações recolhidas pela estação base móvel são analisadas pelos pesquisadores da vida

selvagem.


3.4.2 DakNet

O sistema DakNet (PENTLAND; FLETCHER; HASSON, 2004) foi um projeto desenvolvido

para criação de uma rede Ad-Hoc tolerante a atrasos e desconexões. Este sistema utiliza tecno-

logias de redes sem fio para fornecer serviços de conectividade. O DakNet foi desenvolvido por

pesquisadores MIT Media Lab1, e foi implantado com sucesso em partes remotas da Índia e do

Camboja.

Conforme é ilustrado na Figura 3.10, o sistema DakNet consiste de quiosques com Wi-Fi

habilitado em aldeias, e de MAPs (dispositivos portáteis de armazenamento). Quando um MAP

se aproxima de um quiosque de uma aldeia, ele detecta automaticamente as conexões sem fio

e, em seguida, realiza a transmissão e recebimento de dados com o quiosque. Quando um

MAP entra no alcance de comunicação de um ponto de acesso à Internet, ele irá sincronizar

automaticamente as mensagens dos quiosques das aldeias com à Internet.

Figura 3.10: Esquema geral da arquitetura do projeto DakNet. Fonte: (PENTLAND; FLETCHER;HASSON, 2004).

O sistema DakNet combina um meio físico de transporte (ônibus, motocicleta, ou mesmo

uma bicicleta) com tecnologia de comunicação sem fio para fornecer (não em tempo real) ser-

viços de acesso à Internet tolerantes ao atraso.1https://www.media.mit.edu


3.4.3 CarTel

Cartel (HULL, 2006) é um sistema de comunicação projetado para coletar, transmitir e vi-

sualizar dados a partir de sensores localizados em unidades móveis, como carros.

Conforme e ilustrado na Figura 3.11, a arquitetura de CarTel consiste em um portal, um

ICEDB (Intermittently Connected Database), e um CafNet (Carry-and-Forward of Network).

O Portal hospeda aplicativos CarTel e funciona como ponto de controle e configuração para o

sistema; O ICEDB é um processador de consulta contínuo tolerante à atraso; O CafNet é um

sistema de rede tolerante à atraso.

Figura 3.11: Arquitetura de sistema do projeto CarTel. Fonte: (HULL, 2006).

Um nó CarTel (computador acoplado a um conjunto de sensores) coleta e processa a mensa-

gem de sensores localizados em automóveis, e em seguida, entrega esses dados para um portal

central, utilizando CafNet. Em outras palavras, nós CarTel dependem de conectividade sem

fio oportunista (por exemplo, Wi-Fi, Bluetooth) para se comunicar com um portal. Aplicações

CarTel executadas no portal utilizam ICEDB para especificar como nós móveis devem operar

para filtrar e priorizar dados dinamicamente.


3.4.4 BikeNet

BikeNet (EISENMAN, 2009) é um sistema móvel de mapeamento das experiências de ciclis-

tas. Ele usa uma série de sensores embarcados em uma bicicleta para coletar dados sobre os

passeios de ciclistas.

Conforme é ilustrado na Figura 3.12, BikeNet encontra pontos de acesso sem fio de forma

oportunista para troca de conteúdos, e aproveita o canal de dados celular dos ciclistas para

comunicação em tempo real, se necessário.

BikeNet também fornece um portal Web para cada ciclista acessar seus dados, e para permi-

tir o compartilhamento de dados relacionados com o ciclismo (por exemplo, rotas de ciclismo

favoritas) com grupos interessados em ciclismo, e dados de interesse mais geral (por exemplo,

dados de poluição) com a comunidade em geral.

Figura 3.12: Arquitetura geral do projeto BikeNet. Fonte: (EISENMAN, 2009).

Os Sensores de BikeNet recolhem dados ambientais ao longo da rota e transmitem esses

dados quando os sensores estão dentro do alcance de um SAP (Sensor Access Point) fixo ou

através de um SAP móvel ao longo da rota.

Todos os dados coletados são relacionados ao estado do ciclista (por exemplo, ritmo car-

díaco), sobre o desempenho dos ciclistas (por exemplo, velocidade das rodas), e sobre os arre-

dores dos ciclistas (nível de som, nível de dióxido de carbono, carros).

3.5 Comparação Entre Net-Opp e os Trabalhos Relacionados 36

3.5 Comparação Entre Net-Opp e os Trabalhos Relaciona-dos

Como ficou evidenciado, existem na literatura diversas soluções cuja meta é auxiliar no

processo de desenvolvimento de aplicações oportunistas voltadas para o ambiente móvel. Essas

soluções fazem uso de diferentes arquiteturas, tecnologias de rede, entre outras características.

Sendo assim, diante dessa diversidade de soluções, nesta seção, será realizado um comparativo,

levando em consideração as características apresentadas em (WANG, 2014).

A principal vantagem do middleware Net-Opp em relação aos trabalhos apresentados na

Seção 3.4 de aplicações tolerantes a atrasos e desconexões, está na capacidade de Net-Opp po-

der se comunicar com diferentes aplicações através de sua API de comunicação. O middleware

Net-Opp cria a abstração da formação da rede oportunista e da troca de conteúdos, fornecendo

serviços para as várias aplicações, facilitando o trabalho do desenvolvedor, liberando-o de se

preocupar com a infraestrutura da rede e da troca de conteúdos. O usuário pode escrever sua

aplicação e conectá-la sem impacto ao middleware. Enquanto que os demais trabalhos (JU-

ANG, 2002; PENTLAND; FLETCHER; HASSON, 2004; HULL, 2006; EISENMAN, 2009) apresentam

apenas aplicações e não dão suporte de comunicação para outras aplicações.

Um middleware para rede oportunista deve criar uma camada de interoperabilidade entre

as aplicações e o SO de um dispositivo, possibilitando a troca de conteúdos e informações entre

os dispositivos (WANG, 2014). Nesse contexto o middleware Net-Opp difere dos middlewares

apresentados na Seção 3.2 no estabelecimento de conexão de rede e na troca de conteúdos entre

os dispositivos. Em Net-Opp não é necessário pareamento para formação de rede e para troca de

conteúdos, diferentemente de como ocorre em (SU, 2007; PIETILAINEN, 2009; DUBOIS, 2013b),

onde é necessário interação humana para o pareamento entre os dispositivos.

Para a utilização de Net-Opp, os desenvolvedores necessitam apenas de importar o mid-

dleware e se comunicar pela API de comunicação, sem a necessidade de alterações no SO do

dispositivo, diferentemente de como ocorre em (DUBOIS, 2013b) e (ARNABOLDI; CONTI; DEL-

MASTRO, 2014), onde é necessário a utilização de firmwares customizados que exigem acesso

root ao dispositivo para habilitarem a tecnologia Wi-Fi Ad-Hoc.

Como resultado da análise das soluções de middleware apresentadas nesta seção, a Tabela

3.1 foi construída. Nela, está exposto um comparativo entre os middlewares, evidenciando quais

características cada um possui. É importante destacar que na Tabela 3.1 também está inserido

o middleware proposto neste trabalho, o Net-Opp, que tem como objetivo tornar transparente a

comunicação entre os nós.


Tabela 3.1: Quadro comparativo das soluções de middlewares para redes oportunistas.

Middleware Infraestrutura Tecnologia sem fio InteraçãoHumana

AcessoRoot

Haggle Descentralizada Bluetooth, Wi-Fi modo Ad-Hoc Sim SimMobiClique Híbrida Bluetooth, Wi-Fi modo Ad-Hoc Sim SimCAMEO Descentralizada Wi-Fi modo Ad-Hoc Não SimShair Descentralizada Bluetooth, Wi-Fi modo Ad-Hoc Sim SimNet-Opp Centralizada Alternância entre Wi-Fi modo

infraestrutura e escaneamentoNão Não

O middleware Net-Opp tem como objetivo principal amenizar problemas como dependên-

cia de interação humana e acesso root ao dispositivo móvel, assim estas são as principais vanta-

gens destacadas nas colunas Interação Humana e Acesso Root em relação aos demais trabalhos.

Apesar de oferecer essas vantagens, Net-Opp tem como principal desvantagem destacado na

coluna infraestrutura da Tabela 3.1. Por transformar um dispositivo em AP e os demais se

conectarem a ele para formar a rede oportunista, a infraestrutura de rede fica denominada cen-

tralizada. Assim se o dispositivo AP vir ficar inoperante, toda a rede fica inoperante, apesar de o

middleware Net-Opp contornar essa situação, conforme é destacado na Seção 4.3. Já os demais

trabalhos apresentam uma infraestrutura descentralizada, onde os dispositivos se comunicam

diretamente, sem a necessidade de uma ponto de comunicação.

Todas as vantagens oferecidas por Net-Opp são alcançadas através de um processo custo-

mizado e transparente para formação de rede utilizando a tecnologia Wi-Fi modo infraestrutura.

Em dispositivos móveis pessoais, este modo é utilizado pela tecnologia Wi-Fi Tethering. Esta

tecnologia é suportada por todos os principais fabricantes de dispositivos e está disponível em

todas as principais plataformas de SOs, tais como iOS 4.3+ (APPLE, 2015), Android 2.2+ (GO-

OGLE, 2015) e Windows 7.5+ (MICROSOFT, 2015). Enquanto esta tecnologia é inicialmente

concebida para compartilhar o acesso de uma Internet 3G e LTE para clientes, ela pode ser

usada para comunicações móveis de cliente para cliente e comunicações ponto de acesso para

cliente, permitindo assim comunicações oportunistas.

Existem na literatura algumas soluções cuja meta é encontrar uma alternativa de rede para

aplicações oportunistas utilizando a tecnologia Wi-Fi Tethering. Nos estudos dos trabalhos

(TRIFUNOVIC, 2011; WIRTZ, 2011; DUBOIS, 2013a; TRIFUNOVIC, 2015), os autores investigam

o impacto de vários parâmetros (por exemplo, o tempo de baliza, intervalo de varredura, tempo

de conexão) por meio de simulações e comparam o consumo de energia com Wi-Fi Ad Hoc,

mas eles não analisam o tempo de formação de uma topologia de rede, nem mesmo como a rede

se comporta com tráfego de conteúdos em aplicações distribuídas.


Enquanto que nos trabalhos (TRIFUNOVIC, 2011; WIRTZ, 2011; DUBOIS, 2013a; TRIFUNO-

VIC, 2015) é apresentado a criação desta estrutura de rede com a tecnologia Wi-Fi modo infra-

estrutura e feito comparações com o Wi-Fi Ad-Hoc, em nosso trabalho é feito uma extensão

desses trabalhos, onde é proposto um middleware personalizado que é capaz de abstrair deta-

lhes da formação desta estrutura de rede e também da troca de conteúdos para as aplicações

oportunistas em dispositivos móveis pessoais (smartphones e tablets).

O middleware Net-Opp proposto neste trabalho é baseado na tecnologia Wi-Fi modo in-

fraestrutura de dispositivos móveis, que estabelece a comunicação semelhante ao Wi-Fi Direct,

porém sem necessitar de pareamento nas operações de formação topológica de rede e na troca

de conteúdos entre os dispositivos. Além disso, como caso de uso do middleware é apresentado

duas aplicações e através delas são avaliados o tempo de formação topológica desta estrutura de

rede e o impacto do compartilhamento de conteúdos entre dispositivos através do middleware

Net-Opp em dois cenários reais com dispositivos móveis pessoais (smartphones e tablets) e

veiculares (micro-computadores), enquanto que os demais trabalhos, ou apresentam apenas si-

mulações (TRIFUNOVIC, 2011; DUBOIS, 2013a; TRIFUNOVIC, 2015), ou utilizam computadores

pessoais, como notebooks para transformar os dispositivos em pontos de acessos (WIRTZ, 2011).

Capítulo 4O MIDDLEWARE NET-OPP

Neste capítulo é descrito o middleware proposto nesta dissertação, o Net-Opp. Inicialmente,

é feita uma breve introdução a respeito do Net-Opp. Em seguida, a arquitetura do Net-Opp é

apresentada, evidenciando cada módulo que a compõe. Além disso, neste capítulo, é apresen-

tado o contorno as limitações do modo infraestrutura do Wi-Fi, o gerenciamento (identificação

e segurança) de informações e conteúdos na rede.

4.1 Introdução

A introdução dos middlewares no campo das redes oportunistas, tem como propósito, fa-

cilitar o desenvolvimento deste tipo de rede através da disponibilização de funcionalidades que

auxiliem os desenvolvedores no gerenciamento da rede e na troca de conteúdos entre os dispo-

sitivos.

Como foi discutido na Seção 3.5 do Capítulo 3, um dos problemas apresentados pelos mid-

dlewares para redes oportunistas presentes na literatura é a descoberta sem interação humana,

uma vez que Bluetooth ou Wi-Fi Direct necessitam de pareamento para formarem a rede e

trocarem conteúdos e alteração no SO móvel do dispositivo para habilitar o Wi-Fi Ad Hoc.

Pensando em resolver esses problemas, este trabalho apresenta como solução uma arquite-

tura de middleware chamada de Net-Opp, onde a comunicação entre os nós é realizada através

de um processo customizado que utiliza o Wi-Fi modo infraestrutura. Net-Opp cria a capa-

cidade de comunicação entre os dispositivos de forma transparente, sem que haja pareamento

entre os dispositivos.

Net-Opp automaticamente analisa pontos de acesso disponíveis no ambiente e se associa

com um ponto, se nenhum ponto de acesso for encontrado, Net-Opp habilita o Wi-Fi modo in-

4.2 Arquitetura 40

fraestrutura (ponto de acesso) do dispositivo para prover uma rede de comunicação para outros

dispositivos, possibilitando uma troca transparente de conteúdos entre os dispositivos. Todo

esse processo é realizado automaticamente sem exigir pareamento e alteração no SO dos dispo-

sitivos.

4.2 Arquitetura

A arquitetura do middleware Net-Opp foi projetada tendo como objetivo principal dar su-

porte a comunicação transparente entre dispositivos móveis pessoais (smartphones e tablets).

Para atingir essa meta, a arquitetura foi dividida em módulos, conforme é ilustrado na Figura

4.1, onde cada um é responsável por gerenciar uma parte dos recursos do middleware. Os mó-

dulos que compõem Net-Opp são: API, Gerenciador de Informações, Gerenciador de Rede e

Provedor de Conteúdos.

Figura 4.1: Arquitetura do middleware Net-Opp.

4.3 Funcionamento dos Módulos 41

4.3 Funcionamento dos Módulos

O módulo API foi projetado para permitir que os desenvolvedores de aplicações oportunis-

tas possam usufruir das funcionalidades do middleware Net-Opp. Dessa forma, esse módulo

disponibiliza uma interface de acesso ao middleware Net-Opp, a qual pode ser utilizada pelos

desenvolvedores para explorar os recursos desse middleware. Para isso, a API do middleware

Net-Opp foi projetada e desenvolvida visando o paradigma de comunicação entre processos, o

IPC (Inter-Process Communication).

O módulo Gerenciador de Informações é responsável por gerenciar as informações refe-

rentes a rede (por exemplo, endereços IP, informações dos dispositivos, etc) e os conteúdos

disponibilizados por todos os dispositivos conectados a rede. Este módulo é dividido entre os

submódulos AP e STA. A execução e o gerenciamento dos submódulos AP e STA é realizado

pelo módulo Gerenciador de Rede.

O módulo Gerenciador de Rede é responsável pela formação e manutenção da rede oportu-

nista. Para realizar essas atividades, este módulo faz uso de diversos artifícios do sistema ope-

racional móvel do dispositivo, por exemplo, a tecnologia Wi-Fi modo infraestrutura, o modo de

escaneamento de redes Wi-Fi, e informações do estado do dispositivo (por exemplo, nível de

bateria de um smartphone ou sensores de um veículo).

Para realizar a manutenção da rede oportunista o módulo Gerenciador de Rede foi projetado

para ser executado como uma máquina de estados. Na Figura 4.2 é ilustrado um diagrama de

estados que representa a execução do módulo Gerenciador de Rede.

Figura 4.2: Diagrama de estados do módulo Gerenciador de Rede.


Os seguintes estados descritos abaixo estão em execução durante a execução do módulo

Gerenciador de Rede:

1 Carrega uma informação de estado do dispositivo móvel (por exemplo, o nível de bateria)

e calcula um tempo (se nenhuma informação for carregada, o tempo deve ser aleatório)

para o escaneamento de redes.

2 É habilitado o escaneamento de redes Wi-Fi no ambiente e para cada rede encontrada é

feito uma tentativa de se conectar à rede de acordo com as informações configuradas no

dispositivo. Enquanto não é encontrado uma rede Wi-Fi, o tempo vai decrementando.

Caso contrário, e uma rede Wi-Fi seja encontrada e estabelecido uma comunicação, o

tempo é reiniciado e o submódulo STA é executado.

3 O tempo chegou a zero, e nenhuma rede Wi-Fi foi encontrada, ou não foi possível esta-

belecer uma comunicação, ou a rede ficou inoperante. O submódulo STA é desativado se

estiver em execução.

4 O modo infraestrutura da tecnologia Wi-Fi é habilitado, e o submódulo AP é executado.

O submódulo AP cria a lista de endereços IP e a lista de níveis de bateria, e começa a

realizar o gerenciamento das mesmas.

5 Enquanto em execução, o submódulo AP verifica se existem outros dispositivos conecta-

dos ao ponto de acesso. Caso não existam, o tempo vai decrementando, caso contrário, e

existam dispositivos conectados, o tempo é reiniciado.

6 O tempo chegou a zero e nenhum dispositivo está conectado ao dispositivo ponto de

acesso. O modo infraestrutura da tecnologia Wi-Fi é desativado e o tempo de pesquisa de

redes é reiniciado.

7 O submódulo AP é desativado, e o módulo Gerenciador de Rede volta ao seu primeiro

estado, carregando informações de estado do dispositivo, e continuando a pesquisar novas

redes, garantindo a manutenção desta estrutura de rede.

A Figura 4.3 ilustra quais módulos do middleware Net-Opp estão em execução quando a

estrutura de rede está estabelecida pelo módulo Gerenciador de Rede. O submódulo AP só

é executado em um dispositivo ponto de acesso, e o submódulo STA é executado apenas em

dispositivos clientes, e os módulos API e Provedor de Conteúdos são executados durante toda

a execução de todos os dispositivos.


Figura 4.3: Módulos em execução com a rede de comunicação estabelecida.

O submódulo AP é um servidor que possibilita conexões simultâneas do submódulo STA

de dispositivos clientes. Conforme é mostrado na Tabela 4.1, este módulo trata três tipos de

requisições: adicionar um conteúdo a rede; adicionar o nível de bateria de um dispositivo; e

listar endereços IP (Internet Protocol), conteúdos e o novo tempo de escaneamento de redes.

Todas essas requisições são efetuadas pelo submódulo STA dos dispositivos clientes utilizando

como identificador do dispositivo o seu endereço MAC.

Tabela 4.1: Requisições que o submódulo AP aceita do submódulo STA.

Requisições OperaçõesPUT O dispositivo cliente solicita a adição de um novo arquivo a rede de comu-

nicação. O dispositivo ponto de acesso recebe o conteúdo e distribui para osdemais dispositivos conectados.

LIST O dispositivo cliente solicita ao dispositivo ponto de acesso, a listagem deendereços IPs, arquivos compartilhados e probabilidades da rede de comuni-cação.

BAT O dispositivo cliente envia o seu nível atual de bateria. O dispositivo ponto deacesso recebe este nível de bateria e o adiciona ou o atualiza em sua lista debaterias.

Qualquer dispositivo pode disponibilizar e requisitar conteúdos nessa rede. Os submódulos

AP e STA são responsáveis por requisitarem os conteúdos a outros dispositivos. Já o módulo

Provedor de Conteúdos é responsável por receber as requisições e transmitir os conteúdos para

qualquer dispositivo da rede.

4.4 Contorno às limitações do modo infraestrutura 44

Para saber quais conteúdos podem ser transmitidos pelo dispositivo, o módulo Provedor

de Conteúdos interage com os submódulos STA ou AP do dispositivo requisitado de forma a

verificar quais conteúdos foram compartilhados pelo dispositivo. Dessa forma, é garantido que

apenas os conteúdos compartilhados pela aplicação podem ser transmitidos pelo dispositivo,

não possibilitando a transmissão dos demais conteúdos.

Com a rede de comunicação estabelecida pelo módulo Gerenciador de Rede, o submódulo

STA dos dispositivos clientes envia o nível de bateria do dispositivo para o submódulo AP do

dispositivo ponto de acesso. O submódulo AP adiciona esses níveis de bateria em uma lista de

acordo com os endereços MAC de cada dispositivo. Essa lista é ordenada de acordo com o nível

de bateria e de forma decrescente.

Quando o submódulo STA de um dispositivo cliente solicita a terceira requisição de lista-

gem, o submódulo AP do dispositivo ponto de acesso verifica qual a posição desse dispositivo

na lista de níveis de bateria e retorna sua posição multiplicado por um valor padrão (por exem-

plo, o valor dez). Assim, o dispositivo que tiver maior nível de bateria, será a posição zero

da lista, zero é multiplicado por dez, no que resulta em um tempo zero. Dessa forma, caso a

rede seja destruída por algum motivo, o dispositivo com maior nível de bateria terá um tempo

zero para o escaneamento de redes, transformando-se automaticamente em um ponto de acesso.

Enquanto isso, os demais dispositivos, terão como tempo de escaneamento de pontos de acesso,

respectivamente, dez segundos, vinte segundos, e assim sucessivamente.

4.4 Contorno às limitações do modo infraestrutura

Nesta Seção é apresentado processos específicos do módulo Gerenciador de Rede para o

contorno às limitações do modo infraestrutura da tecnologia Wi-Fi. Especificamente em relação

as limitações de: dispositivos móveis estarem com a tecnologia Wi-Fi no mesmo modo de

operação (seja em escaneamento ou ponto de acesso); rede de comunicação inoperante quando

o ponto de acesso fica inoperante. Essas duas limitações são contornadas, porém a limitações

de grupos disjuntos não é contornado.

Na Subseção 2.3.2.1 foi descrito que quando dois dispositivos se tornam um ponto de acesso

ao mesmo tempo, eles não reconhecem um ao outro. Para superar esse desafio, é proposto que

na execução do primeiro estado do módulo Gerenciador de Rede, deve ser definido que tipo

de informação poderá ser utilizada para evitar que os dispositivos se tornem ao mesmo tempo

pontos de acesso. Caso nenhuma informação seja carregada, por padrão, o dispositivo deve

gerar uma informação aleatória, por exemplo, um valor decimal.

4.5 Distribuição de Conteúdos 45

Em caso de dispositivos móveis pessoais, o módulo pode ser configurado a utilizar o nível

de bateria dos dispositivos móveis de forma a calcular um tempo para escanear rede. Já no

caso de dispositivos móveis veiculares, o nível de bateria não varia tanto em um curto espaço

de tempo, assim o nível de bateria não seria uma boa informação, nesse caso pode-se gerar

um tempo aleatório. Esse tempo pode ser baseado em um sensor (por exemplo a variação do

volante) do veículo.

Também na Seção 3.5 foi descrito que quando a rede de comunicação está estabelecida,

o dispositivo que é o ponto de acesso por vir a ficar inoperante por alguns motivos, e se isso

acontecer, toda a rede de comunicação fica inoperante. Para contornar essa situação, é proposto

que, quando a rede de comunicação está estabelecida, todos os dispositivos devem enviar ao

dispositivo ponto de acesso, suas informações de estados, por exemplo o nível de bateria.

Baseado nessa informação, o dispositivo ponto de acesso cria uma tabela de informações

referentes ao estado de todos os dispositivos e notifica os dispositivos com as informações de to-

dos os demais. Assim, se a rede vir a ficar inoperante, os dispositivos podem utilizar essa tabela

de informações para definirem o novo tempo de escaneamento de redes. Por exemplo, se um

dispositivo que fosse um cliente, e tivesse um maior nível de bateria, poderia automaticamente

se transformar em AP e os demais dispositivos com menor nível de bateria se conectariam a ele.

4.5 Distribuição de Conteúdos

Quando um dispositivo disponibiliza um arquivo na rede, o submódulo STA obtêm o ende-

reço do arquivo, e realiza uma requisição do tipo PUT mais o nome de identificação do arquivo

e envia esses dados ao submódulo AP. O submódulo AP recebe a requisição e atualiza sua lista

local de arquivos disponibilizados na rede, e verifica se este novo arquivo disponibilizado na

rede existe na sua pasta local, caso não exista, o submódulo AP dispara uma tarefa que cuida de

requisitar ao submódulo STA o arquivo disponibilizado por ele.

Quando não há arquivos para serem disponibilizados, o submódulo STA executa outras duas

requisições ao submódulo AP. A requisição LIST significa que o submódulo AP deverá retornar

respectivamente, uma lista com todos os arquivos disponibilizados pelos dispositivos da rede,

outra lista com todos os endereços IP dos dispositivos da rede, e por fim, uma lista dos níveis de

bateria de todos os dispositivos conectados a rede. O submódulo STA valida a lista de arquivos

disponibilizados na rede, e para cada arquivo não existente no dispositivo é disparado uma tarefa

que cuida de solicitar o arquivo a todos os dispositivos conectados a rede utilizando a lista de

endereços IP.

4.6 Gerenciamento das Informações da Rede 46

Após a requisição LIST, o submódulo STA realiza a terceira requisição BAT, onde o sub-

módulo envia uma mensagem contendo a identificação do dispositivo, seu endereço MAC, e o

nível atual da bateria do dispositivo. O submódulo AP recebe esta requisição, e adiciona esta

informação caso não exista em uma lista local com vários estados de bateria dos dispositivos

conectados a rede.

4.6 Gerenciamento das Informações da Rede

Em uma infraestrutura de rede WLAN, o dispositivo que é o ponto de acesso tem todas as

informações referentes a rede, pois ele é quem provê a rede para os demais dispositivos e trata

de gerenciar informações (por exemplo, endereço IP, endereço Gateway, etc) refentes à rede.

Apesar de um cliente estar conectado a um ponto de acesso, ele desconhece quais os outros

dispositivos atuais conectados à rede de comunicação, a não ser o dispositivo ponto de acesso

que sempre fica com o endereço inicial da rede.

Para que todos os clientes possam se comunicar pela rede, o submódulo AP do dispositivo

que é o ponto de acesso fornece ao submódulo STA dos clientes uma lista de endereços IP dos

dispositivos conectados à rede de comunicação. Essa lista é requisita pelo submódulo STA do

dispositivo cliente de tempo em tempo, com o objetivo de estar com a lista de endereços IP

sempre atualizada, para evitar o caso de um dispositivo sair da rede e um endereço IP inválido

ficar armazenado.

Para que os arquivos compartilhados nessa rede de comunicação sejam identificados por

cada dispositivo, o nome do arquivo é identificado pela concatenação do endereço MAC do dis-

positivo mais o nome do arquivo. Dessa forma, além do arquivo ter uma identificação única, os

dispositivos que receberem essa identificação do arquivo, saberão qual o dispositivo que dispo-

nibilizou o conteúdo na rede através do endereço MAC, e poderão encaminhar esse conteúdo a

outros dispositivos que estão aguardando o conteúdo.

4.7 Segurança e Privacidade

O middleware armazena o SSID e o PSK (Pre-Shared Key) para prover a rede de comu-

nicação, não sendo possível a modificação dessas informações. Dessa forma, os dispositivos

clientes podem escanear as redes sem fio e se conectarem automaticamente às redes encontra-

das comparando com o SSID e PSK armazenado no middleware. Se o dispositivos não encontrar

uma rede, a tecnologia Wi-Fi modo infraestrutura é ativada definindo as informações do SSID

4.7 Segurança e Privacidade 47

e o PSK da rede configurado no middleware.

O objetivo do middleware é possibilitar comunicação transparente entre os dispositivos.

Desta forma, o middleware não tem uma forte ênfase na segurança da comunicação entre dis-

positivos, como é feito no Bluetooth e Wi-Fi Direct com a segurança de pareamento. Assim,

para manter a comunicação transparente, é definido que a segurança das informações trocadas

entre os dispositivos são feitas utilizando SSL (Secure Socket Layer) (RESCORLA, 2001).

No middleware Net-Opp não é definido nenhuma privacidade dos usuários em sua rede de

comunicação. Privacidade, apesar de trazer mais segurança ao usuário, também traz limitações

em questões de troca de conteúdos em aplicações que não necessitam esse tipo de mecanismo.

Portanto, as políticas de privacidade podem ser definidas na camada de aplicação.

Capítulo 5PROVAS DE CONCEITO

Neste capítulo são apresentados dois exemplos de aplicações oportunistas, que foram desen-

volvidos sobre o middleware Net-Opp. A implementação dessas aplicações teve como objetivo

gerar os cenários para a avaliação do middleware Net-Opp. A descrição e o detalhamento das

classes e métodos dos módulos do middleware Net-Opp e das aplicações estão expostos nos

Apêndices A e B.

5.1 Relevância do Desenvolvimento

Através do desenvolvimento do middleware Net-Opp, é possível explorar as informações de

contexto social e de localização disponibilizadas e focar nas regras de negócio das aplicações,

não necessitando preocupar-se com o processo de formação das Redes Oportunistas.

Aplicações voltadas ao ambiente de dispositivos móveis pessoais e veiculares são desenvol-

vidas principalmente para auxiliar o cotidiano das pessoas, possibilitando o acesso e difusão de

informações, promovendo comunidades virtuais locais, reduzindo o tráfego de redes celulares

e possibilitando uma entrega de dados tolerante a atrasos e desconexões.

5.2 Aplicação Crowd Wi-Fi

Nesta Seção são apresentados a descrição, a implementação, o funcionamento e uma avali-

ação do primeiro exemplo de aplicação oportunista, a qual foi desenvolvida sobre o middleware

Net-Opp. Esta aplicação tem como principal objetivo o compartilhamento de conteúdos de

um diretório de um dispositivo móvel para vários outros dispositivos móveis através da rede

oportunista estabelecida pelo middleware Net-Opp.

5.2 Aplicação Crowd Wi-Fi 49

5.2.1 Implementação

A aplicação Crowd Wi-Fi e o middleware Net-Opp foram implementados com a linguagem

de programação Java e a linguagem XML (eXtensible Markup Language) através da IDE (In-

tegrated Development Environment) Eclipse com plugin ADT (Android Development Tools).

A linguagem Java foi utilizada na elaboração das Activities1. As Activities são as classes Java

onde estão implementadas as telas do aplicativo Crowd Wi-Fi e a forma como o usuário inte-

rage com ele. São nessas Activities que são acionadas as rotinas do Net-Opp de acordo com as

funcionalidades acessadas pelo usuário. Por sua vez, o XML foi empregado no posicionamento

de elementos como menus, botões e imagens na tela do aplicativo. É importante ressaltar que o

Crowd Wi-Fi funciona em dispositivos móveis com Android 4.0 ou superior.

O middleware Net-Opp foi implementado para executar como um serviço para SO Android,

sendo assim, ele executa todas as suas funções em segundo plano. Para a definição das inter-

faces da API do Net-Opp foi utilizado a AIDL. Essa linguagem é provida pelo Android para a

especificação de interfaces para o protocolo IPC. A partir das definições de interfaces feitas em

AIDL, todo código necessário para a comunicação remota entre o cliente e o serviço remoto é

gerado automaticamente.

A Figura 5.1 ilustra o diagrama de atividade do módulo Gerenciador de rede do middleware

Net-Opp. Nesta plataforma, é definido a utilização do nível de bateria dos dispositivos móveis

para definição do tempo de escaneamento de redes e para definição do próximo ponto de acesso,

caso a rede fique inoperante. Assim, o processo de alternância é baseado no nível de bateria dos

dispositivos.

Figura 5.1: Diagrama de atividades do módulo Gerenciador de Rede do middleware Net-Opp.

1http://developer.android.com/reference/android/app/Activity.html


Durante o projeto e desenvolvimento da aplicação Crowd Wi-Fi e do middleware Net-Opp,

diversos problemas foram descobertos e solucionados. O primeiro deles foi a falta de exemplos

práticos relacionados a tecnologia Wi-Fi Tethering. Apesar de a Wi-Fi Alliance disponibilizar

a documentação, o SDK (Software Development Kit) do Android não apresenta nenhuma espe-

cificação sobre a tecnologia. O fato dessa tecnologia ser recente, resulta em poucos projetos, o

que dificulta a busca por exemplos práticos em sites de repositórios de código-fonte livre, por

exemplo, os repositórios do GitHub2 e do Google Code3.

5.2.2 Funcionamento

Quando o Crowd Wi-Fi é instalado e executado pela primeira vez no dispositivo do usuá-

rio, é realizada a operação bind junto ao Net-Opp. Após o Net-Opp e o Crowd Wi-Fi estarem

associados, é exibida uma tela com o título "Pressione a Pasta a Ser Compartilhada", conforme

é ilustrado na Figura 5.2(a), nessa tela o usuário deve selecionar a pasta que ele deseja compar-

tilhar na rede oportunista, essa tela é somente apresentada quando o usuário ainda não definiu

uma pasta a ser compartilhada na aplicação.

(a) (b)

Figura 5.2: Imagens da aplicação Crowd Wi-Fi.

2https://github.com3https://code.google.com


O usuário, ao pressionar a pasta a ser compartilhada, automaticamente a aplicação passa a

monitorar essa pasta, verificando quais são os conteúdos atuais. Caso ocorra alguma operação

de arquivo, a aplicação notifica o middleware Net-Opp, através de métodos da API que um

conteúdo foi alterado.

Após a seleção da pasta, a Figura 5.2(b) ilustra a tela de lista de dispositivos que é automa-

ticamente gerada pelo middleware Net-Opp através de métodos da API que busca os conteúdos

disponibilizados a outros dispositivos que estão ativos na rede oportunista. Essas informações

não são necessariamente os conteúdos em si, mas informações referentes a conteúdos compar-

tilhados pelos dispositivos.

Ao clicar sobre um dos conteúdos listados na tela da Figura 5.2(b), a aplicação Crowd Wi-Fi

solicita ao middleware Net-Opp o conteúdo selecionado. Net-Opp automaticamente verifica se

o conteúdo já não existe na aplicação, caso não exista, Net-Opp requisita a algum dispositivo

da rede e baixa o arquivo. Mesmo que o conteúdo não seja encontrado, Net-Opp continua a

procurar o arquivo em novas redes. Com o conteúdo no dispositivo, Net-Opp notifica a aplica-

ção e é exibido uma mensagem na tela da aplicação permitindo o usuário escolher um serviço

para execução do conteúdo, conforme é ilustrado na Figura 5.3(a). Após o usuário selecionar

um serviço para execução do conteúdo na tela da Figura 5.3(a), o conteúdo é automaticamente

executado pelo serviço escolhido, conforme é ilustrado na tela da Figura 5.3(b).

(a) (b)

Figura 5.3: Imagens da aplicação Crowd Wi-Fi.

5.3 Aplicação Black Box 52

5.2.3 Avaliação

Com a descrição do funcionamento da aplicação Crowd Wi-Fi é possível avaliar a trans-

parência que a aplicação criou para o usuário final. É possível ver que o usuário teve que

selecionar a pasta a ser compartilhada na Figura 5.2(a) (processo necessário apenas na primeira

execução da aplicação), selecionar o conteúdo desejado na Figura 5.2(b), e selecionar o serviço

a executar o conteúdo na Figura 5.3(a) (processo necessário apenas na primeira execução do

conteúdo). Assim, Net-Opp conseguiu evitar que o usuário tenha que interagir várias vezes

com o dispositivo para a troca de conteúdos e escolha de um dispositivo para o envio.

5.3 Aplicação Black Box

Nesta Seção é apresentado e descrito a implementação, o funcionamento e uma avaliação

do segundo exemplo de aplicação oportunista, uma aplicação móvel veicular, a qual foi desen-

volvida sobre o middleware Net-Opp.

Esta aplicação realiza o gerenciamento de gravação de vídeos em partes e realiza a entrega

tolerante a atrasos e desconexões desses vídeos do veículo para um servidor. Para isso, a apli-

cação se comunica com o middleware Net-Opp para que ele realize a distribuição desses vídeos

em uma rede oportunista entre veículos.

5.3.1 Organização e Implementação

A Figura 5.4 ilustra a organização dos componentes no veículo. Cada veículo é equipado

de uma placa PandaBoardES4 e uma câmera que realiza o monitoramento do motorista.

Figura 5.4: Organização dos componentes no veículo.

4http://pandaboard.org/content/pandaboard-es


Para conseguir compartilhar os conteúdos de forma transparente, a aplicação Black Box

foi desenvolvida sobre o middleware Net-Opp. O middleware e a aplicação foram desenvolvi-

dos utilizando o SO Ubuntu 14.04, sendo utilizado uma versão totalmente customizada para a

placa PandaBoardES, que satisfaça apenas as necessidades para o desenvolvimento da aplicação

Black Box.

O middleware Net-Opp foi implementado para executar como um serviço para SO Ubuntu

14.04, sendo assim, ele executa todas as suas funções em segundo plano. Para isso, Net-Opp

utiliza o CORBA (Common Object Request Broker Architecture) para estabelecer e simplificar

a troca de dados entre o middleware e as aplicações. A aplicação Black Box se comunica com o

middleware Net-Opp através da interface de comunicação definida na API do middleware.

Para a definição das interfaces da API do Net-Opp foi utilizado a IDL (Interface Definition

Language). Essa linguagem é provida pelo C++ para a especificação de interfaces para o pro-

tocolo IPC. A partir das definições de interfaces feitas em IDL, todo código necessário para a

comunicação remota entre o cliente e o serviço remoto é gerado automaticamente.

A Figura 5.5 ilustra o diagrama de atividades do módulo Gerenciador de rede do mid-

dleware Net-Opp. Neste diagrama podemos visualizar que nessa plataforma, o tempo para

escanear redes é gerado de forma aleatória, já que em um veículo o nível de bateria não va-

ria tanto quanto um smartphone, como é feito na plataforma Android, apresentado na Seção

5.2. Também é possível visualizar no diagrama de atividades que além de verificar se exis-

tem clientes conectados quando o dispositivo se torna um ponto de acesso, foi adicionado uma

verificação de arquivos sendo transmitidos entre os veículos.

Figura 5.5: Diagrama de atividades do módulo Gerenciador de Rede do middleware Net-Opp.


O principal objetivo de verificar se ainda existem arquivos a serem transmitidos é para a

geração de novas oportunidades de encontros entre os veículos. Como foi descrito na Seção

2.3.2.1, dois dispositivos podem se tornar um ponto de acesso ao mesmo tempo, e assim, duas

redes podem ser estabelecidas em um mesmo local com vários dispositivos. Assim, com essa

verificação, caso não exista arquivos a serem transmitidos, o dispositivo AP desabilita o ponto

de acesso e faz com que todos os dispositivos pesquisem novas redes, de forma a encontrar

novos arquivos e difundir os já existentes.

5.3.2 Funcionamento

Quando a aplicação Black Box é executada na inicialização do sistema operacional móvel

da placa PandaBoardES instalada no veículo do usuário, é realizada uma operação bind junto ao

middleware Net-Opp. Após o middleware Net-Opp e a aplicação Black Box estarem associados,

a aplicação Black Box pode se comunicar com o middleware Net-Opp através de métodos da

interface da API definida no middleware Net-Opp.

A aplicação Black Box executa diversas tarefas simultaneamente enquanto está em execu-

ção, por exemplo, realiza a gravação de vídeos da câmera instalada no veículo, transmite os

conteúdos através do middleware Net-Opp, e gerencia o espaço disponível em disco apagando

vídeos antigos.

A aplicação é divida em duas Threads5, sendo que a primeira Thread realiza a gravação

dos vídeos da câmera do veículo de tempo em tempo em uma pasta do sistema. O intervalo

de tempo de gravação dos vídeos é definido em um arquivo de configuração, podendo assim,

ser modificado a qualquer momento. O nome de identificação dos vídeos gravados na pasta do

sistema é definido através do endereço MAC da placa juntamente com a data e hora atual do

sistema, criando assim, uma identificação única.

A segunda Thread realiza o gerenciamento do espaço disponível em disco do sistema, ba-

seado em um limite de espaço definido em um arquivo de configuração, sendo possível sua

modificação. Para realizar esse gerenciamento, a aplicação Black Box verifica que se caso o

limite máximo exceda, o vídeo mais antigo é removido da pasta. Esse processo é executado

de minuto em minuto através da ferramenta contrab6, com o objetivo de sempre estar com um

espaço disponível no sistema.

5Thread é um pequeno programa que trabalha como um subsistema, sendo uma forma de um processo seautodividir em duas ou mais tarefas.

6Contrab é um serviço unix que permite que tarefas sejam executadas em modo "background"em intervalosregulares de tempo.


Quando o veículo está desligado ou em movimento o sistema permanece ativo, e sistemati-

camente tenta trocar conteúdos através de contatos oportunistas. Quando um vídeo é totalmente

armazenado em uma pasta do dispositivo, a aplicação Black Box requisita ao Net-Opp a inclusão

desse novo conteúdo (vídeo) a rede oportunista. Quando uma rede é estabelecida entre veículos,

conforme é ilustrado na Figura 5.6, Net-Opp automaticamente distribui os vídeos entre todos

os dispositivos.

Figura 5.6: Troca de conteúdos em um possível contato oportunista em uma estrada.

Com o veículo em movimento o sistema pode continuar a difundir conteúdos através de

contatos oportunistas, porém, quando um veículo se encontra com uma infraestrutura, conforme

é ilustrado na Figura 5.7, o middleware Net-Opp entrega todos os conteúdos armazenados no

dispositivo. Assim, a infraestrutura, com conexão a internet, trata de entregar esses conteúdos

ao servidor destino.

Figura 5.7: Entrega de um conteúdo tolerante a atrasos a uma infraestrutura na via.


5.3.3 Avaliação

Com a descrição do funcionamento da aplicação Black Box é possível avaliar a transpa-

rência que a aplicação criou para o usuário. Com o sistema em funcionamento e o veículo em

tráfego em vias, acontece uma difusão de mensagens entre os veículos, e assim, os conteúdos

são distribuídos até que cheguem a uma infraestrutura instalada próxima a uma via, que trata de

entregar o conteúdo a um servidor através da internet.

Esse tipo de sistema traz como principal vantagem a possibilidade de entrega de conteúdos

em locais onde não há uma infraestrutura de rede celular, ou em regiões onde não há acesso a

internet. Possibilitando assim, um maior acesso à informação à sociedade.

Capítulo 6METODOLOGIA DE AVALIAÇÃO

Uma das principais vantagens do middleware é facilitar o trabalho do desenvolvedor de

aplicações oportunistas, liberando-o de se preocupar com a infraestrutura de rede e a troca de

conteúdos. O usuário pode escrever sua aplicação e conectá-la sem impacto ao Net-Opp. A

avaliação deste tipo de benefício não é possível de medir através de técnicas de simulação, mas

deve ser levada em consideração.

Neste capítulo são apresentados os cenários e métricas dos dois cenários das aplicações

Crowd Wi-Fi e Black Box apresentadas na Seção 5, para avaliação do middleware Net-Opp.


Nesta Seção são apresentados os cenários e métricas avaliadas para as comunicações D2D

(device-to-device) através do estudo de caso Crowd Wi-Fi, apresentado na Seção 5.2.

A fim de provar a viabilidade de adotar o middleware em uma rede oportunista, é importante

avaliar o impacto no tempo de formação topológica de rede, tempo de atraso na transferência

de arquivos, taxa de transmissão, e o tempo de atraso de pacotes. Estes quatro experimentos

foram realizados em laboratório, de maneira controlada, onde os dispositivos ficaram sobre

uma mesa com uma média de três metros de distância, não sendo considerado interferências e

movimentos.

Nos experimentos 6.1.1, 6.1.2 e 6.1.3 foram utilizados nove tablets, e os experimentos fo-

ram executados 30 vezes em cada dispositivo simultaneamente. Já no experimento 6.1.4, foram

utilizados apenas dois tablets e os experimentos foram executados vinte vezes. A quantidade de

dispositivos e quantidade de execuções dos testes do experimento 6.1.4 ficam diferente por que

tiveram que ser realizados iguais aos experimentos realizados nos trabalhos relacionados.


Os dados de todos os experimentos foram obtidos através da realização de cálculos na

aplicação Crowd Wi-Fi, sendo considerado um intervalo de confiança de 95%. Foi utilizado

o padrão IEEE 802.11g, quadros de controle RTS/CTS (Request to Send / Clear to Send) e

potência Tx (transmission) padrão do dispositivo de 20 dBm.

O tamanho dos arquivos utilizados nos experimentos 6.1.2 e 6.1.3 foram de 9MB por serem

um tamanho que representa a média de tamanho de arquivos de imagens e pequenos vídeos

transmitidos principalmente em redes sociais e aplicativos de mensagens em geral. Já o tamanho

dos arquivos utilizados no experimento 6.1.4 foram de 6.4MB, por que esse foi o tamanho dos

arquivos utilizado nos experimentos realizados nas arquiteturas comparadas.

6.1.1 Tempo de Formação Topológica da Rede de Comunicação

No primeiro experimento, foi avaliado o tempo de associação topológica dos dispositivos

móveis para estabelecimento da rede de comunicação. É realizado um cálculo da média da

soma do tempo em que cada dispositivo teve para estabelecer uma rede de comunicação e ter

conectividade.

Neste experimento, cada dispositivo obtêm esse tempo através do Log da aplicação An-

droid, que registra quando o dispositivo começa o processo de escaneamento de redes, e quando

o dispositivo estabeleceu uma conexão. Cada dispositivo envia seu tempo ao dispositivo AP. Ao

final o dispositivo AP faz cálculo com todos os tempo (inclusive o seu).

O principal objetivo desse experimento é avaliar como a alternância entre o modo STA e AP

pode afetar no tempo de estabelecimento de conexão. Este experimento também é importante

para avaliar o impacto que a quantidade de dispositivos promove no tempo de formação da rede

de comunicação.

6.1.2 Tempo de Atraso dos Pacotes

No segundo experimento, foi medido o tempo de atraso de pacotes entre os dispositivos da

rede de comunicação. Todos os dispositivos armazenaram os tempos no momento de transmis-

são de pacotes e no recebimento, no final todos os tempos foram coletados e feito a média do

atraso.

O principal objetivo desse experimento é avaliar o impacto que a quantidade de dispositivos

móveis promove no atraso da transmissão de pacotes entre os dispositivos nessa estrutura de

rede de comunicação.


6.1.3 Taxa de Transmissão

No terceiro experimento, a aplicação foi alterada de modo que oito dispositivos requisitas-

sem um arquivo de 9MB a um dispositivo. Foi medido a taxa de transmissão de pacotes entre

os dispositivos através do cálculo dos tempos e do tamanho do arquivo.

O principal objetivo desse experimento é avaliar como a rede de comunicação se comporta

quando um dispositivo realiza a transmissão de um arquivo para vários dispositivos (quantidades

diferentes) ao mesmo tempo.

6.1.4 Tempo de Transferência de Arquivos

No quarto experimento foi realizado comparações com os middlewares CAMEO e Haggle.

Foi medido o tempo de para a transferência de um arquivo de 6.4MB entre dois dispositivos

móveis através dos middlewares CAMEO, Haggle e Net-Opp.

O tempo de entrega de arquivos calculado nesse experimento é o intervalo de tempo que

se inicia quando o aplicativo envia uma solicitação para o middleware (Net-Opp, CAMEO ou

Haggle) para baixar o arquivo, e termina quando o middleware notifica a transferência concluída

a aplicação.

O principal objetivo desse experimento é avaliar se o processo de alternância entre o modo

STA e AP, criado pelo middleware Net-Opp, pode promover um menor atraso que os middlewa-

res CAMEO e Haggle.


Nesta Seção são apresentados os cenários e métricas avaliadas para as comunicações V2V

(Vehicle-to-Vehicle) e V2I (Vehicle-to-Infrastructure) através do estudo de caso Black Box, apre-

sentado na Seção 5.3.

Em todos os experimentos que envolvem a transferência de arquivos no Black Box, os arqui-

vos possuíam o tamanho de 1MB. Esse tamanho representava o tamanho dos vídeos gravados

nos veículos. Eles possuíam esse tamanho, por serem gravados em pequenas faixas de tempo,

estarem em preto e branco, e terem uma resolução menor.

As configurações nos vídeos foram necessárias para que se houvesse a troca dos vídeos nos

possíveis encontros entre os veículos. Já que movimento, o tempo é curto, e assim, arquivos

com tamanhos menores, possuem uma probabilidade maior de serem transmitidos.


6.2.1 Comunicação Entre Veículo Para Veículo

Para as comunicações V2V, foram realizados experimentos para avaliar o tempo de forma-

ção topológica de rede, a taxa de transmissão, e o tempo de entrega de arquivo tolerante a atrasos

e desconexões. Os experimentos foram realizados em laboratório, de maneira controlada, não

sendo considerado interferências e movimentos.

Os dados dos três experimentos foram obtidos realizando cálculos na própria aplicação

Black Box, sendo considerado um intervalo de confiança de 95%. Foi utilizado o padrão IEEE

802.11g, quadros de controle RTS/CTS e potência Tx padrão do dispositivo de 20 dBm.

6.2.1.1 Tempo de Formação Topológica de Rede

No primeiro experimento, foi medido o tempo de associação topológica de rede entre os

dispositivos. Cada dispositivo obtêm o tempo através do Log da aplicação Linux, que registra

quando o dispositivo começa o processo de escaneamento de redes, e quando o dispositivo

estabeleceu uma conexão. Cada dispositivo envia seu tempo ao dispositivo AP. Ao final o

dispositivo AP faz cálculo com todos os tempo (inclusive o seu).

Neste experimento os dispositivos ficaram sobre uma mesa com uma média de três metros

de distância. Foram utilizadas 5 placas PandaBoardES, e todos os experimentos foram exe-

cutados 30 vezes em cada dispositivo simultaneamente. Este experimento é importante para

avaliar o impacto que a quantidade de dispositivos promove no tempo de formação da rede de

comunicação.

6.2.1.2 Taxa de Transmissão

No segundo experimento, a aplicação foi alterada de modo que 4 dispositivos requisitassem

um arquivo de 1MB a um dispositivo. Foi medido a taxa de transmissão de pacotes entre os

dispositivos através do cálculo dos tempos e do tamanho do arquivo.

Neste experimento os dispositivos ficaram sobre uma mesa com uma média de três me-

tros de distância. Foram utilizadas 5 placas PandaBoardES, e todos os experimentos foram

executados 30 vezes em cada dispositivo simultaneamente.

O principal objetivo deste experimento é avaliar como a rede de comunicação se comporta

quando um dispositivo realiza a transmissão de um arquivo para vários dispositivos (quantidades

diferentes) ao mesmo tempo.


6.2.1.3 Tempo de Entrega de Arquivo Tolerante a Atrasos e Desconexões

No terceiro experimento, foi avaliado o tempo de entrega de um arquivo de 1MB em uma

rede tolerante a atrasos e desconexões. Essa rede DTN foi criada pelo sistema desenvolvido

na aplicação Black Box, sendo definido um mecanismo de receber um arquivo, armazená-lo, e

submetê-lo para outro dispositivo que solicitar o arquivo.

Cada operação (envio e recebimento) de arquivos juntamente com o tempo que a operação

foi efetivada são armazenados em um Log para que posteriormente pudesse ser lidos e gerados

as estatísticas de tempos de entrega dos arquivos.

As estatísticas extraídas foram calculadas através da soma do tempo médio que cada arquivo

(de cada dispositivo) teve para chegar em cada dispositivo participante da rede de comunica-

ção, sendo considerado dois cenários, o primeiro de três dispositivos, e o segundo com quatro

dispositivos.

Este experimento foi realizado no corredor do prédio 1 do Instituto de Ciências Exatas e

Biológicas da Universidade Federal de Ouro Preto, conforme é ilustrado na Figura 6.1. As

placas estavam separadas por um distância de 25 metros. Foram utilizadas três a quatro placas

PandaBoardES, e todos os experimentos foram executados quatro vezes em cada dispositivo

simultaneamente.

Figura 6.1: Vista aérea da região de experimentação. Os números correspondem a cada disposi-tivo.


Cada dispositivo tem armazenado um arquivo, e assim, o dispositivo 1 tem o arquivo 1, o

dispositivo 2, o arquivo 2, e assim, sucessivamente. O sistema Black Box foi modificado de

forma que quando é iniciado o SO Linux na placa, todos os arquivos são apagados, deixando

somente o arquivo que pertence ao dispositivo. Esse processo foi necessário para que não fosse

necessário realizar modificações no sistema a cada novo teste, acelerando assim, o processo dos

experimentos.

6.2.2 Comunicação Entre Veículo Para Infraestrutura

Para as comunicações V2I, os experimentos foram realizados em uma avenida localizada

na Universidade Federal de Ouro Preto, composta de um trecho de 430 metros, conforme é

ilustrado na Figura 6.2.

Figura 6.2: Vista aérea da região de experimentação. Ponto 1 é a infraestrutura fixa. Ponto 2 é oveículo móvel.

Um veículo iniciou o deslocamento em uma das extremidades da avenida (ponto 2), man-

tendo as velocidades de 60 km/h, 50 km/h, 40 km/h, 30 km/h e 20 km/h. O veículo do ponto

1, atuou como a infraestrutura, permanecendo parado no meio da avenida. A distância entre os

dois pontos é de 216 metros.

Os dados dos experimentos foram obtidos utilizando o software bwping, que disparou paco-

tes com 512 bytes a uma taxa de transmissão de 2048 kbps. Quatro repetições foram realizadas

para cada experimento. A posição geográfica do veículo foi registrada durante a realização dos

experimentos. Foi utilizado quadros de controle RTS/CTS e potência Tx padrão da placa de 20

dBm.


6.2.2.1 Taxa de Perda de Pacotes

No primeiro experimento foi avaliado a taxa de perda de pacotes na transferência de um

arquivo de 1MB. Para isso, foi feito uma comparação do número de pacotes transmitidos com

o números de pacotes efetivamente recebidos e extraído a quantidade de pacotes perdidos na

comunicação entre o veículo e a infraestrutura nas diferentes velocidades que o veículo se en-

contrava.

Essa experimento é importante para avaliar como a rede de comunicação, nessa estrutura

de rede criada pelo middleware Net-Opp, se comporta quando o veículo está em movimento em

diferentes velocidades.

6.2.2.2 Atraso na Transmissão

No segundo experimento foi avaliado o atraso na transmissão de pacotes. Para isso, foi

feito uma medição do momento em que o pacote foi transmitido de um dos dispositivos até o

momento em que o pacote chegou ao dispositivo receptor na comunicação entre o veículo e a

infraestrutura nas diferentes velocidades que o veículo se encontrava.

Essa experimento é importante para avaliar como a rede de comunicação, nessa estrutura

de rede criada pelo middleware Net-Opp, se comporta quando o veículo está em movimento em

diferentes velocidades.


No terceiro experimento foi avaliado a taxa de transmissão de pacotes. Para isso, foi feito

um cálculo dos tempos para transmissão de cada pacote juntamente com seu tamanho. Através

desse cálculo foi gerado a taxa de transmissão de pacotes na comunicação entre o veículo e a

infraestrutura nas diferentes velocidades que o veículo se encontrava.

O principal objetivo deste experimento é avaliar como a rede de comunicação se comporta

quando um veículo realiza a transmissão de um arquivo para a infraestrutura em diferentes

velocidades.

Capítulo 7RESULTADOS EXPERIMENTAIS

O principal objetivo dos experimentos realizados é analisar como a rede oportunista criada

pelo middleware Net-Opp se comporta em ambientes diferentes (dispositivos móveis pessoais,

e veiculares). Assim, neste capítulo são apresentados os resultados da avaliação feita nos expe-

rimentos do middleware Net-Opp através do estudo das aplicações Crowd Wi-Fi e Black Box,

no que se refere a aspectos de desempenho.

Este capítulo está organizado em duas Seções, sendo que a primeira Seção 7.1, apresenta

os resultados da aplicação Crowd Wi-Fi, e a segunda Seção 7.2, apresenta os resultados da

aplicação Black Box.


Antes de apresentar os resultados da aplicação Crowd Wi-Fi, vale ressaltar, que em todos

os experimentos realizados na aplicação Crowd Wi-Fi, os dispositivos móveis comunicaram-se

automaticamente, sem a necessidade de um usuário para intervir nesse processo, diferentemente

de como ocorre nos trabalhos (SU, 2007; PIETILAINEN, 2009; DUBOIS, 2013b), onde é necessário

interação humana para o pareamento entre os dispositivos. Todo esse processo transparente foi

conseguido graças as funcionalidades do middleware Net-Opp.

7.1.1 Tempo de Formação Topológica da Rede de Comunicação

A Figura 7.1 ilustra os resultados do primeiro experimento. Pode-se observar que quando

há poucos dispositivos, o tempo de formação topológica de rede é grande, e sua faixa de erro

também. Porém, quando a quantidade de dispositivos aumenta, o tempo de formação topológica

de rede diminui e a taxa de erro também. Isso acontece por que quando há poucos dispositivos,


a probabilidade dos dispositivos ficarem ao mesmo tempo escaneando ou se tornando ponto de

acesso é maior do que quando há uma quantidade maior de dispositivos.

Figura 7.1: Tempo de associação da rede de comunicação.

Além disso, também é possível avaliar que, quando há dois dispositivos, existe um tempo

para que cada dispositivo se transforme em um modo de operação do Wi-Fi. Esse tempo de

transformação é que gera aquela taxa de erro maior, pois, com quantidade menores de disposi-

tivos, eles acabam não se identificando. Com quantidades maiores de dispositivos, pelo menos

um dos dispositivos se transforma em um modo diferente do outro, acarretando na formação da

rede.

Portanto, com quantidades menores de dispositivos, maior é a taxa de erro, pois maior é

a probabilidade dos dispositivos não conseguirem se identificar por causa do tempo que levam

para trocarem de modo de operação. Porém esse tempo não influencia quando temos uma

quantidade maior de dispositivos, pois, quando um dos dispositivos se transforma em cliente,

outro dispositivo já esta no modo ponto de acesso.

7.1.2 Tempo de Atraso dos Pacotes

A Figura 7.2 ilustra os resultados do segundo experimento. Pode-se observar que o tempo

de atraso dos pacotes aumenta de acordo com que a quantidade de dispositivos que recebem

um arquivo aumenta. Isso ocorre por que o dispositivo que realiza o processo de transmitir o

arquivo tem um trabalho maior com quantidades maiores de dispositivos, e assim, o canal de

comunicação do dispositivo fica mais ocupado com mais pacotes ao mesmo tempo para serem

transmitidos e processados.


Figura 7.2: Atraso médio.

Além disso, outro aspecto influenciou no aumento do atraso. De acordo que a quantidade

de dispositivo aumentava, o número de ocorrências e interferências também aumentavam. E

assim, por causa dessas interferências, os pacotes tiveram um tempo maior para chegarem ao

seus destinos.

7.1.3 Taxa de Transmissão

A Figura 7.3 ilustra os resultados do primeiro experimento. Pode-se observar que a quanti-

dade de dispositivos também influencia na taxa de transmissão. Dessa forma, é possível perce-

ber que a taxa de transmissão diminui de acordo que a quantidade de dispositivos que recebem

um arquivo aumenta. Isso acontece por que o dispositivo servidor, que está cuidando de trans-

mitir o arquivo, tem um trabalho maior com quantidade maiores de dispositivos, e assim, a

banda de conexão desse dispositivo está mais ocupada com várias conexões simultâneas e mais

pacotes para serem processados.

Além disso, também foi possível avaliar na Figura 7.3, que a quantidade de dispositivos

influenciou em outro aspecto na taxa de transmissão. De acordo que a quantidade de dispositivo

aumentava, o número de ocorrências e interferências também aumentavam. Já a taxa de erro

deve-se ao tamanho de 9MB dos arquivos. Quando há uma quantidade maior de dados para

serem transmitidos, o canal é utilizado em um período de tempo maior, e por isso, em diferentes

períodos de tempos as ocorrências de interferências acabaram produzindo uma quantidade de

erro maior.


Figura 7.3: Taxa de transmissão de pacotes.

7.1.4 Tempo de Transferência de Arquivos

No quarto experimento, Net-Opp conseguiu ser mais eficiente que CAMEO e Haggle no

tempo de transmissão de arquivo. Na Figura 7.4, pode-se observar que Net-Opp teve um tempo

de transferência de 4s do arquivo (6.4MB), enquanto que CAMEO e Haggle, tiveram respectiva-

mente 10s e 75s. Essa eficiência é devida às características internas da arquitetura de Net-Opp.

Por possuir uma arquitetura simples, comparada com as arquiteturas de CAMEO e Haggle,

uma quantidade menor de mensagens são trocadas entre os módulos do middleware Net-Opp

em relação aos middlewares CAMEO e Haggle. A modularidade excessiva das arquiteturas de

CAMEO e Haggle resultou numa sobrecarga de mensagens internas que afetaram o desempenho

dos serviços ativos.

Figura 7.4: Tempo de transferência de arquivos.



Nesta Seção são apresentados os resultados dos experimentos da comunicação V2V e V2I.

7.2.1 Comunicação Entre Veículo Para Veículo

Antes de começar a avaliar os resultados dos experimentos V2V, vale ressaltar que os re-

sultados nesse tipo de comunicação V2V demonstraram ser bem parecidos com os mesmos ex-

perimentos D2D feitos na aplicação Crowd Wi-Fi. Porém, conforme foi apresentado na Seção

6.2, não foi considerado movimentos dos dispositivos durante a execução dos experimentos.

7.2.1.1 Tempo de Formação Topológica da Rede de Comunicação

A Figura 7.5 ilustra os resultados do primeiro experimento. Pode-se observar que, quando

há poucos dispositivos, o tempo de formação topológica de rede é grande, e sua faixa de erro

também. Porém, quando a quantidade de dispositivos aumenta, o tempo de formação topológica

de rede diminui e a taxa de erro também. Isso acontece por que quando há poucos dispositivos,

a probabilidade dos dispositivos ficarem ao mesmo tempo escaneando ou se tornando ponto de

acesso é maior do que quando há uma quantidade maior de dispositivos.

Figura 7.5: Tempo de associação da rede de comunicação.

A partir dos resultados apresentados na Figura 7.5, é possível concluir que o tempo de for-

mação de rede, não é viável para comunicação com os veículos em movimento. Entretanto, esse

sistema pode ser aplicado em locais onde os veículos se encontram e permanecem parados por

alguns instantes de tempo (por exemplo, em um sinal de trânsito, ou em um estacionamento).



No segundo experimento, pode-se observar na Figura 7.6, que a quantidade de dispositivos

influência na taxa de transmissão, onde a taxa diminui de acordo que a quantidade de disposi-

tivos que recebem um arquivo aumenta. Isso acontece por que o dispositivo servidor que está

cuidando de transmitir o arquivo, tem um trabalho maior com quantidade maiores de disposi-

tivos, e assim, a banda de conexão desse dispositivo está mais ocupada com várias conexões

simultâneas e mais pacotes para serem processados.

Figura 7.6: Taxa de transmissão de pacotes.

A partir dos resultados apresentados na Figura 7.6, também é possível verificar que a taxa

ficou menor e variou menos que a taxa apresentada na Subseção 7.1.3 da aplicação Crowd Wi-Fi.

Isso aconteceu por causa da distância entre os dispositivos e o tamanho de arquivos utilizados

em cada dispositivo. Variou menos por causa do tamanho do arquivo utilizado, no caso 1MB

na aplicação Black Box, enquanto que na aplicação Crowd Wi-Fi cada arquivo tinha o tamanho

de 9MB. Já a taxa ficou menor por causa da distância entre os dispositivos, na aplicação Black

Box foram 15 metros, enquanto que na aplicação Crowd Wi-Fi foram 3 metros.

7.2.1.3 Tempo de Entrega de Arquivo Tolerante a Atrasos e Desconexões

No terceiro experimento, pode-se observar na Figura 7.7, que o que mais impactou no

tempo de entrega de arquivos tolerante a atrasos e desconexões foi a distância entre os dispo-

sitivos. É possível visualizar que tanto para três quanto para quatro dispositivos, o tempo de

entrega dos arquivos dos dispositivos que estavam nas extremidades é maior do que o tempo

dos arquivos dos dispositivos que estavam no meio, servindo como ponto de comunicação entre

os dispositivos das extremidades.


A explicação dessa diferença de tempo deve-se principalmente ao fato de que os disposi-

tivos que estão no meio se comunicam e entregam seus arquivos com um tempo menor aos

dispositivos que estão próximos a eles, nesse caso, os dispositivos que estão na extremidade. O

tempo de entrega dos arquivos dos dispositivos das extremidades ficou maior pelo fato de que

para seus arquivos serem entregues de uma extremidade a outra, deve passar por um (três dispo-

sitivos) ou mais (quatro ou mais dispositivos) pontes de comunicação, e uma (três dispositivos)

ou mais (quatro ou mais dispositivos) redes devem ser criadas para que isso aconteça.

Figura 7.7: Tempo de entrega de arquivos.

Na Figura 7.7 também é possível visualizar uma taxa de erro grande no tempo de entrega

de arquivos, principalmente nos tempos de entrega dos dispositivos das extremidades. Isso

acontece por causa das redes formadas pelo middleware Net-Opp. Como o sistema baseia-se

em tempos aleatórios para pesquisar e formar as redes, em alguns momentos, quando não há

arquivos para serem transmitidos, o dispositivo não consegue encontrar um segundo dispositivo

além do último que ele se comunicou, e ele acaba voltando a se comunicar com o primeiro,

afetando assim, o tempo de entrega de seus arquivos e dos arquivos do primeiro dispositivo

conectado à ele.

7.2.2 Comunicação Entre Veículo Para Infraestrutura

Os resultados da aplicação Black Box foram extraídos de quatro repetições para cada expe-

rimento, no cenário apresentado na Seção 6.2.2. O intervalo de confiança considerado foi de

95%, mas não são representados no gráfico para facilitar a disposição das informações.


Todos os três experimentos foram avaliados nas velocidades de 60 km/h, 50 km/h, 40 km/h,

30 km/h e 20 km/h na mesma avenida e nas mesmas condições climáticas. Nos gráficos que

serão apresentados a seguir, a distância negativa significa a aproximação do veículo ao dispo-

sitivo destino (infraestrutura) e a distância positiva representa o seu afastamento do dispositivo

destino.

Através dos resultados dos três experimentos realizados, os dados obtidos em diferentes

velocidades mostraram que a rede de comunicação se comporta de maneira mais robusta em

velocidades menores. Foi possível realizar a transmissão de dados em até um diâmetro de

aproximadamente 85 metros.

7.2.2.1 Taxa de Perda de Pacotes

Neste primeiro experimento foi avaliado a taxa de perda de pacotes na comunicação V2I.

A Figura 7.8 ilustra os resultados desse primeiro experimento. Quanto mais próximo o veículo

está do nó receptor (infraestrutura), menor é a perda de pacotes. Quando os nós estão a uma

distância relativa de até 25 metros, a perda de pacotes ficou abaixo de 25%. A velocidade

também influenciou na perda de pacotes, mas não tanto quanto a distância.

Figura 7.8: Média de perda de pacotes.

Em alguns casos, algumas velocidades maiores conseguiram ter uma perda de pacotes me-

nores que em velocidades menores. Como é observado no canto esquerdo da Figura 7.8, a

média de perda de pacotes na velocidade de 30km/h conseguiu ser maior que 20km/h, e 50km/h

conseguiu ser maior que 40km/h.


7.2.2.2 Atraso na Transmissão

Neste segundo experimento foi avaliado o atraso na transmissão dos pacotes na comunica-

ção V2I. A Figura 7.9 ilustra os resultados desse segundo experimento. O atraso foi medido

considerando apenas os pacotes efetivamente transmitidos. O atraso médio variou de forma

significativa em relação a distância.

Figura 7.9: Atraso médio.

Os valores obtidos quando os dispositivos (tanto o veículo quanto a infraestrutura) estavam

em pontos distantes variaram bastante em relação ao atraso obtido quando os dispositivos esta-

vam próximos. Também foi verificado que ao aumentar a velocidade no veículo, o atraso nas

comunicações também sofre incremento, afetando principalmente o desempenho nas comuni-

cações.


Neste terceiro experimento foi avaliado a taxa de transmissão de dados na comunicação

V2I. Na Figura 7.10 é ilustrado as estatísticas dos resultados desse terceiro experimento. Os

dados extraídos das cinco avaliações realizadas em diferentes velocidades mostram que nas

comunicações, a taxa de transmissão média variou de forma significativa em relação a distância

entre o veículo e a infraestrutura.

Assim como no experimento apresentado na Subseção 7.2.2.1, neste experimento, algu-

mas velocidades maiores conseguiram ter uma taxa de transmissão maior que em velocidades

menores. Conforme é observado no canto esquerdo da Figura 7.10, a taxa de transmissão na

velocidade de 50km/h conseguiu ser maior que 40km/h, e 30km/h conseguiu ser maior que

20km/h.

7.3 Observações Finais 73

Figura 7.10: Taxa de transmissão média.

7.3 Observações Finais

Além dos resultados apresentados e discutidos nas seções anteriores, outros resultados do

estudo puderam ser levantados através da observação da execução dos experimentos, sendo os

principais:

• O middleware Net-Opp foi capaz de fornecer comunicação oportunista para os dois cená-

rios apresentados, possibilitando a troca de informações e conteúdos entre os dispositivos;

• Foi possível executar o middleware Net-Opp nos dispositivos sem a interferência do usuá-

rio (exigir pareamento), mesmo com o serviço em segundo plano e com a tela desligada

(no caso de smartphones);

• Com o dispositivo no modo ponto de acesso, torna-se necessário a desativação dos servi-

ços de telefonia celular (3G e LTE) para evitar a utilização de dados do plano do usuário;

• Em um cenário de áreas urbanas, pontos de acessos abertos disponíveis podem permitir

que os dispositivos se comuniquem apenas no modo cliente (STA) e aumentar a capaci-

dade de comunicação e encontros já que as redes oportunistas criadas por Net-Opp são

privadas;

• Durante a execução dos experimentos, ocorreu uma alta taxa de desconexões entre os

dispositivos, que levou a uma modificação da estrutura do sistema. Isso ocorreu quando os

SSIDs das redes eram iguais. Foi necessário criar SSIDs aleatórios a cada nova conexão

para evitar esse problema.

Capítulo 8CONCLUSÕES

Após a prospecção desta dissertação foi possível perceber que a área de middleware para

redes oportunistas ainda tem muito a ser explorada. As soluções catalogadas mostram que não

existe uma abordagem que satisfaz todas as necessidades que o desenvolvimento de uma rede

oportunista exige. Além disso, dentro desse conjunto de abordagens, cada autor tenta resolver

um ou mais problemas, presentes em um ambiente de rede oportunista, usando as mais variadas

técnicas, métodos e ferramentas.

Diante dessa heterogeneidade de soluções de middleware, esta dissertação propôs, funda-

mentou e esquematizou uma nova arquitetura de middleware chamada Net-Opp. Essa arquite-

tura foi implementada para a plataforma Linux e Android e avaliada por meio de dois estudos

de caso, o Crowd Wi-Fi e o Black Box. Durante essa avaliação, o middleware Net-Opp foi sub-

metido a diversos cenários, onde seu comportamento e desempenho puderam ser observados e

avaliados.

O Net-Opp trouxe algumas contribuições para a área de middleware para redes oportunistas.

Dentre elas, está a introdução da alternância entre o modo cliente e infraestrutura do Wi-Fi no

modulo de comunicação de um middleware. A partir dos testes executados foi possível perceber

que essa alternância pode ser utilizada na construção de aplicativos oportunistas e possui como

principal qualidade a sua comunicação transparente e taxa de transmissão de dados.

Além disso, com o middleware Net-Opp, o programador conta com um ambiente confiável

de comunicação, onde todo o processo de formação de rede oportunista é realizado de forma

automática e transparente, sem necessidade de pareamento entre os dispositivos, interação hu-

mana, e alteração no SO do dispositivo móvel.

Como o middleware Net-Opp possui uma arquitetura voltada para comunicações D2D opor-

tunista e possibilita uma comunicação transparente, este middleware também pode ser aplicado

8.1 Contribuições 75

em outros tipos de redes de comunicação, por exemplo, em comunicações M2M (machine-to-

machine).

Por fim, para os desenvolvedores e pesquisadores que desejam implementar redes oportu-

nistas, as informações contidas nesta dissertação, bem como o middleware Net-Opp descrito

nela, podem servir como ponto de partida para geração de novas ideias e produtos que podem

vir a atender as expectativas dos usuários de dispositivos móveis voltado ao ambiente de redes

oportunistas.

8.1 Contribuições

Esta dissertação trouxe as seguintes contribuições:

• Um survey de middlewares para redes oportunistas, apresentando as características e fun-

cionamento de suas arquiteturas, juntamente com suas principais vantagens e desvanta-

gens;

• Um survey de aplicações para dispositivos móveis, que foram desenvolvidas e que em-

pregam na prática o uso de redes tolerantes a atrasos e desconexões;

• Um survey de frameworks que utilizam a tecnologia Wi-Fi modo infraestrutura (ou tethe-

ring) de forma a criar uma rede oportunista entre dispositivos móveis, realizando o pro-

cesso de alternância entre os modos de operação de escaneamento de redes e ponto de

acesso, da tecnologia Wi-Fi;

• Apresentação do Net-Opp, um middleware para redes oportunistas que faz uso do Wi-Fi

modo infraestrutura para prover comunicação entre os nós, visando as plataformas Linux

e Android;

• Disponibilização da API de comunicação ao middleware Net-Opp. Possibilitando que

outros desenvolvedores utilizem essa plataforma para o desenvolvimento de aplicações

oportunistas.

• Apresentação e avaliação de duas provas de conceito do middleware Net-Opp em dois

cenários reais e diferentes. Sendo o primeiro de dispositivos móveis pessoais, e o segundo

de dispositivos móveis veiculares.

8.2 Trabalhos Futuros 76

8.2 Trabalhos Futuros

Apesar de o middleware Net-Opp já ter uma arquitetura definida e estar implementado para

os SOs Android e Linux, existem melhorias que ainda podem ser executadas. As seguintes

sugestões de trabalhos futuros que podem ser desenvolvidos a partir dessa dissertação:

• Considerar uma arquitetura orientada a conteúdo (por exemplo, CCN (Content-Centric

Networking)) rodando como aplicação nativa acima do middleware Net-Opp;

• Desenvolver uma aplicação sobre Net-Opp voltada para redes 5G, com o objetivo de re-

duzir a carga de telefonia celular, realizando cache de conteúdos nos dispositivos móveis;

• Realizar outros tipos de avaliações do middleware Net-Opp. Por exemplo, avaliação do

consumo energético;

• Estender os estudos, empregando o uso do middleware em diferentes aplicações e maiores

quantidades de dispositivos, com o propósito de avaliar mais profundamente o comporta-

mento do middleware nessa estrutura de rede.

8.3 Produção e Inovação

Esta dissertação resultou em três artigos e uma patente:

• (GARROCHO; SILVA; OLIVEIRA, 2015a). Content Delivery Architecture for Communica-

tion Device-to-Device Wireless Networks. In The Eleventh Advanced International Con-

ference on Telecommunications 2015 (AICT 2015). 21–26 de Junho de 2015;

• (GARROCHO; SILVA; OLIVEIRA, 2015d). Transparent Sharing Architecture of Content

Between Mobile Devices in Opportunistic Networks. In Simpósio Brasileiro de Siste-

mas de Informação 2015 (SBSI 2015). 26–29 de Maio de 2015;

• (GARROCHO; SILVA; OLIVEIRA, 2015b). Net-Opp: A Transparent Middleware For Network

Formation And Exchange of Content For Opportunistic Applications. In Workshop de Re-

des P2P, Dinâmicas, Sociais e Orientadas a Conteúdo (SBRC 2015 - WP2P+). 18–22 de

Maio de 2015;

• (GARROCHO; SILVA; OLIVEIRA, 2015c). Processo de Criação e Manutenção de Redes

Oportunistas sem Pareamento entre os Dispositivos. Patente de Modelo de Utilidade.

Depósito feito ao INPI em 16 de Setembro de 2015.

REFERÊNCIAS

AKYILDIZ, I. F.; WANG, X.; WANG, W. Wireless mesh networks: a survey. Computernetworks, Elsevier, v. 47, n. 4, p. 445–487, 2005.

ALLIANCE, W. Wi-fi peer-to-peer (p2p) technical 7 specification. www.wi-fi.org/Wi-Fi_Direct.php, 2010.

APPLE. Apple iOS. 2015. http://developer.apple.com/technologies/ios/.

APPOLINÁRIO, F. Dicionário de metodologia científica: um guia para a produção doconhecimento científico. In: Dicionário de metodologia científica: um guia para a produçãodo conhecimento científico. [S.l.]: Atlas, 2007.

ARNABOLDI, V.; CONTI, M.; DELMASTRO, F. Cameo: A novel context-aware middlewarefor opportunistic mobile social networks. Pervasive and Mobile Computing, Elsevier, v. 11, p.148–167, 2014.

BAZA CUÑADO, M. Diseño e implementación de una plataforma de monitorización conmulas de datos para una red de motas dispersas sun spot. 2011.

BEN MOKHTAR, S.; CAPRA, L. From pervasive to social computing: algorithms anddeployments. In: ACM. Proceedings of the 2009 international conference on Pervasiveservices. [S.l.], 2009. p. 169–178.

BOLDRINI, C. et al. Opportunistic networks. ELSEVIER SCIENCE BV, 2014.

BORGES, E. F.; LEMES, G. R.; ALECRIM, P. D. de. Estudo comparativo de desempenhona transmissão de dados entre as redes cabeadas e sem fio utilizando opnet. Conferência deEstudo em Engenharia Elétrica, 2007.

BRUN, F. Oppnet: An energy optimized service platform for opportunistic networking onandroid. 2014.

CÂMARA, D. et al. Vehicular delay tolerant networks. Handbook of research on mobility andcomputing: Evolving technologies and ubiquitous impacts, Hershey, PA, USA: IGI Global, p.356–367, 2011.

CASTELLS, M. et al. Mobile communication and society: A global perspective. [S.l.]: MitPress, 2009.

CERF, V. et al. Delay-tolerant networking architecture. [S.l.], 2007.

CHEN, S.; HURLEY, C.; KARIM, J. YouTube. 2005. http://www.youtube.com.

Referências 78

CHEN, T. M. Governments and the executive"internet kill switch"[editor’s note]. Network,IEEE, IEEE, v. 25, n. 2, p. 2–3, 2011.

CHURCHILL, E. F.; HALVERSON, C. et al. Guest editors’ introduction: Social networks andsocial networking. Internet Computing, IEEE, IEEE, v. 9, n. 5, p. 14–19, 2005.

CONSTANTINESCU, M. et al. Mobile tethering: overview, perspectives and challengess.info, Emerald Group Publishing Limited, v. 16, n. 3, p. 40–53, 2014.

CONTI, M.; GIORDANO, S. Mobile ad hoc networking: milestones, challenges, and newresearch directions. Communications Magazine, IEEE, IEEE, v. 52, n. 1, p. 85–96, 2014.

COTTRILL, C. D. et al. Future mobility survey. Transportation Research Record: Journal ofthe Transportation Research Board, Trans Res Board, v. 2354, n. 1, p. 59–67, 2013.

CROW, B. P. et al. Ieee 802.11 wireless local area networks. Communications Magazine,IEEE, IEEE, v. 35, n. 9, p. 116–126, 1997.

DEKKER, M.; KARSBERG, C.; LAKKA, M. Annual incident reports 2013. Crete, Greece:European Union Agency for Network and Information Security (ENISA), 2013.

DENKO, M. K. Mobile Opportunistic Networks: Architectures, Protocols and Applications.[S.l.]: CRC Press, 2011.

DORSEY, J.; WILLIAMS, E.; STONE, B. Twitter. 2006. http://www.twitter.com.

DUBOIS, D. J. et al. Lightweight self-organizing reconfiguration of opportunisticinfrastructure-mode wifi networks. In: IEEE. Self-Adaptive and Self-Organizing Systems(SASO), 2013 IEEE 7th International Conference on. [S.l.], 2013. p. 247–256.

DUBOIS, D. J. et al. Shair: Extensible middleware for mobile peer-to-peer resource sharing.In: ACM. Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering.[S.l.], 2013. p. 687–690.

EISENMAN, S. B. et al. Bikenet: A mobile sensing system for cyclist experience mapping.ACM Transactions on Sensor Networks (TOSN), ACM, v. 6, n. 1, p. 6, 2009.

GALATI, A. Delay tolerant network. Germany: LAP Lambert Academic Publishing, 2010.

GANTI, R. K.; YE, F.; LEI, H. Mobile crowdsensing: current state and future challenges.Communications Magazine, IEEE, IEEE, v. 49, n. 11, p. 32–39, 2011.

GARROCHO, C. T. B.; SILVA, M. J.; OLIVEIRA, R. A. R. Content delivery architecturefor communication device-to-device wireless networks. In: Proceedings of The EleventhAdvanced International Conference on Telecommunications (AICT 2015). [S.l.: s.n.], 2015. p.66–71.

GARROCHO, C. T. B.; SILVA, M. J.; OLIVEIRA, R. A. R. Net-opp: Um middlewaretransparente para formação de redes e troca de conteúdos para aplicações oportunistas. In:Workshop de Redes P2P, Dinâmicas, Sociais e Orientadas a Conteúdo (SBRC 2015 - WP2P+).[S.l.: s.n.], 2015. v. 1, p. 15–28.

Referências 79

GARROCHO, C. T. B.; SILVA, M. J.; OLIVEIRA, R. A. R. Processo de Criação eManutenção de Redes Oportunistas sem Pareamento entre os Dispositivos e o Seu Uso.[S.l.]: Instituto Nacional de Propriedade Industrial, 2015. Patente de modelo de utilidade.BR1020150238665.

GARROCHO, C. T. B.; SILVA, M. J.; OLIVEIRA, R. A. R. Transparent sharing architectureof content between mobile devices in opportunistic networks. In: BRAZILIAN COMPUTERSOCIETY. Proceedings of the annual conference on Brazilian Symposium on InformationSystems: Information Systems: A Computer Socio-Technical Perspective-Volume 1. [S.l.],2015. p. 48.

GOOGLE. Android Phone. 2015. http://www.android.com.

GREENFIELD, J.; SHORT, K. Software factories: assembling applications with patterns,models, frameworks and tools. In: ACM. Companion of the 18th annual ACM SIGPLANconference on Object-oriented programming, systems, languages, and applications. [S.l.],2003. p. 16–27.

GROUP, I. . W. et al. Wireless lan medium access control (mac) and physical layer (phy)specifications. 2007.

HAARTSEN, J. C. The bluetooth radio system. Personal Communications, IEEE, IEEE, v. 7,n. 1, p. 28–36, 2000.

HAN, B. et al. Cellular traffic offloading through opportunistic communications: a case study.In: ACM. Proceedings of the 5th ACM workshop on Challenged networks. [S.l.], 2010. p.31–38.

HELFT, M.; BARBOZA, D. Google shuts china site in dispute over censorship. NY TIMES,Mar, v. 22, 2010.

HOFFMAN, R. LinkedIn. 2003. http://www.linkedin.com.

HU, X. et al. A survey on mobile social networks: Applications, platforms, systemarchitectures, and future research directions. IEEE, 2015.

HUANG, C.-M.; LAN, K.-c.; TSAI, C.-Z. A survey of opportunistic networks. In: IEEE.Advanced Information Networking and Applications-Workshops, 2008. AINAW 2008. 22ndInternational Conference on. [S.l.], 2008. p. 1672–1677.

HULL, B. et al. Cartel: a distributed mobile sensor computing system. In: ACM. Proceedingsof the 4th international conference on Embedded networked sensor systems. [S.l.], 2006. p.125–138.

HUMPHREYS, L. Mobile social networks and urban public space. New Media & Society,SAGE Publications, v. 12, n. 5, p. 763–778, 2010.

JAIN, S.; FALL, K.; PATRA, R. Routing in a delay tolerant network. [S.l.]: ACM, 2004.

JUANG, P. et al. Energy-efficient computing for wildlife tracking: Design tradeoffs and earlyexperiences with zebranet. In: ACM. ACM Sigplan Notices. [S.l.], 2002. v. 37, p. 96–107.

Referências 80

KÄRKKÄINEN, T.; PITKÄNEN, M.; OTT, J. Enabling ad-hoc-style communication in publicwlan hot-spots. ACM SIGMOBILE Mobile Computing and Communications Review, ACM,v. 17, n. 1, p. 4–13, 2013.

KAUR, A.; MALHOTRA, J. A survey of network simulation tools. Wireless Communication,v. 7, n. 6, p. 191–194, 2015.

KAYASTHA, N. et al. Applications, architectures, and protocol design issues for mobile socialnetworks: A survey. Proceedings of the IEEE, IEEE, v. 99, n. 12, p. 2130–2158, 2011.

KHAN, A. J. et al. Cameo: A middleware for mobile advertisement delivery. In: ACM.Proceeding of the 11th annual international conference on Mobile systems, applications, andservices. [S.l.], 2013. p. 125–138.

LLOYD, J. W. Foundations of logic programming. [S.l.]: Springer Science & Business Media,2012.

LOUREIRO, A. A. et al. Redes de sensores sem fio. In: Simpósio Brasileiro de Redes deComputadores (SBRC). [S.l.: s.n.], 2003. p. 179–226.

LOUREIRO, E. et al. Pervasive computing: What is it anyway? Ubiquitous Computing:Design, Implementation and Usability. pp10-37 Information Science Reference, 2008.

MA, H.; ZHAO, D.; YUAN, P. Opportunities in mobile crowd sensing. CommunicationsMagazine, IEEE, IEEE, v. 52, n. 8, p. 29–35, 2014.

MARTÍN CAMPILLO, A. et al. Evaluating opportunistic networks in disaster scenarios.Journal of Network and computer applications, Elsevier, v. 36, n. 2, p. 870–880, 2013.

MCMAHON, A.; FARRELL, S. Delay-and disruption-tolerant networking. IEEE InternetComputing, IEEE, n. 6, p. 82–87, 2009.

MICROSOFT. Windows Phone. 2015. http://www.windowsphone.com.

MOREIRA, D. A. Metodo fenomenológico na pesquisa. [S.l.]: Cengage Learning Editores,2002.

MUMTAZ, S. et al. Direct mobile-to-mobile communication: Paradigm for 5g. WirelessCommunications, IEEE, IEEE, v. 21, n. 5, p. 14–23, 2014.

NICOPOLITIDIS, P. et al. Wireless networks. [S.l.]: John Wiley & Sons, Inc., 2003.

OLIVEIRA, C. T. de et al. Redes tolerantes a atrasos e desconexoes. SBRC Simpósio Brasileirode Redes de Computadores e Sistemas Distribuídos, 2007.

PAHLAVAN, K. Principles of wireless networks: A unified approach. [S.l.]: John Wiley &Sons, Inc., 2011.

PEJOVIC, V.; MUSOLESI, M. Anticipatory mobile computing: A survey of the state of the artand research challenges. ACM Computing Surveys (CSUR), ACM, v. 47, n. 3, p. 47, 2015.

PELUSI, L.; PASSARELLA, A.; CONTI, M. Opportunistic networking: data forwarding indisconnected mobile ad hoc networks. IEEE Communications Magazine, IEEE Press, v. 44,n. 11, p. 134–141, 2006.

Referências 81

PENTLAND, A.; FLETCHER, R.; HASSON, A. Daknet: Rethinking connectivity indeveloping nations. Computer, IEEE, v. 37, n. 1, p. 78–83, 2004.

PERERA, C. et al. Context aware computing for the internet of things: A survey.Communications Surveys & Tutorials, IEEE, IEEE, v. 16, n. 1, p. 414–454, 2014.

PERKINS, C. E. Ad hoc networking. [S.l.]: Addison-Wesley Professional, 2008.

PIETILÄINEN, A. K.; DIOT, C. Experimenting with opportunistic networking. In:CITESEER. Proc. of the ACM MobiArch Workshop. [S.l.], 2009.

PIETILAINEN, A.-K. et al. Mobiclique: middleware for mobile social networking. In: ACM.Proceedings of the 2nd ACM workshop on Online social networks. [S.l.], 2009. p. 49–54.

RAPPAPORT, T. S. et al. Wireless communications: principles and practice. [S.l.]: prenticehall PTR New Jersey, 1996.

RESCORLA, E. SSL and TLS: designing and building secure systems. [S.l.]: Addison-WesleyReading, 2001.

ROSHAN, P.; LEARY, J. 802.11 wireless LAN fundamentals. [S.l.: s.n.], 2010.

RUTTEN, N.; JOOLINGEN, W. R. van; VEEN, J. T. van der. The learning effects of computersimulations in science education. Computers & Education, Elsevier, v. 58, n. 1, p. 136–153,2012.

SAHA, D.; MUKHERJEE, A. Pervasive computing: a paradigm for the 21st century.Computer, IEEE, v. 36, n. 3, p. 25–31, 2003.

SALES, T. Especificação baseada no padrão upnp para autenticação e autorização de usuáriosem ambientes de computação pervasiva. Dissertação de mestrado, Universidade Federal deCampina Grande, Campina Grande, Paraíba - Brasil, 2010.

SATYANARAYANAN, M. Pervasive computing: Vision and challenges. PersonalCommunications, IEEE, IEEE, v. 8, n. 4, p. 10–17, 2001.

SCHULZ, S. et al. Tetherway: a framework for tethering camouflage. In: ACM. Proceedingsof the fifth ACM conference on Security and Privacy in Wireless and Mobile Networks. [S.l.],2012. p. 149–160.

SCOTT, J. et al. Haggle: A networking architecture designed around mobile users. In: WONS2006: Third Annual Conference on Wireless On-demand Network Systems and Services. [S.l.:s.n.], 2006. p. 78–86.

SU, J. et al. Haggle: Seamless networking for mobile applications. UbiComp 2007: UbiquitousComputing, Springer, p. 391, 2007.

TANENBAUM, A. Redes de computadores. CAMPUS - RJ, 2003. ISBN 9788535211856.Disponível em: <http://books.google.com.br/books?id=0tjB8FbV590C>.

TELECO. Redes LAN/MAN Wireless II: Tipos de Rede. 2015. http://www.teleco.com.br/tutoriais/tutorialrwlanman2/pagina_2.asp.

Referências 82

TRIFUNOVIC, S. et al. Wifi-opp: ad-hoc-less opportunistic networking. In: ACM.Proceedings of the 6th ACM workshop on Challenged networks. [S.l.], 2011. p. 37–42.

TRIFUNOVIC, S. et al. Wlan-opp: Ad-hoc-less opportunistic networking on smartphones. AdHoc Networks, Elsevier, v. 25, p. 346–358, 2015.

VASILAKOS, A. V.; ZHANG, Y.; SPYROPOULOS, T. Delay tolerant networks: Protocolsand applications. [S.l.]: CRC press, 2011.

VUKADINOVIC, V.; KARLSSON, G. Spectral efficiency of mobility-assisted podcasting incellular networks. In: ACM. Proceedings of the Second International Workshop on MobileOpportunistic Networking. [S.l.], 2010. p. 51–57.

WANG, Y. et al. Survey on mobile social networking in proximity (msnp): approaches,challenges and architecture. Wireless networks, Springer, v. 20, n. 6, p. 1295–1311, 2014.

WAZLAWICK, R. Metodologia de pesquisa para ciência da computação. [S.l.]: ElsevierBrasil, 2009.

WEI, K.; LIANG, X.; XU, K. A survey of social-aware routing protocols in delay tolerantnetworks: applications, taxonomy and design-related issues. Communications Surveys &Tutorials, IEEE, IEEE, v. 16, n. 1, p. 556–578, 2014.

WEISER, M. The computer for the 21st century. Scientific american, Nature PublishingGroup, v. 265, n. 3, p. 94–104, 1991.

WIRTZ, H. et al. Establishing mobile ad-hoc networks in 802.11 infrastructure mode. In:ACM. Proceedings of the 6th ACM workshop on Challenged networks. [S.l.], 2011. p. 49–52.

YU, P. et al. Application mobility in pervasive computing: A survey. Pervasive and MobileComputing, Elsevier, v. 9, n. 1, p. 2–17, 2013.

ZUCKERBERG, M. et al. Facebook. 2004. http://www.facebook.com.

GLOSSÁRIO

3G – Third Generation of Mobile Telecommunications Technology

5G – Fifth Generation of Mobile Telecommunications Technology

ADT – Android Development Tools

AIDL – Android Interface Definition Language

API – Application Programming Interface

AP – Access Point

BSS – Basic Service Set

CA-Fw – Context-Aware Framework

CAMEO – Context-aware middleware for Opportunistic Mobile Social Networks

CCN – Content-Centric Networking

CORBA – Common Object Request Broker Architecture

CTS – Clear to Send

CafNet – Carry-and-Forward of Network

D2D – Device-to-Device

DS – Distribution Systems

DTNs – Delay and Disruption Tolerant Networks

ECA – Event Condition Action

ESS – Extended Service Set

GPL – General Public License

GPS – Global Positioning System

Referências 84

HTTP – Hypertext Transfer Protocol

IBSS – Independent Basic Service Set

ICEDB – Intermittently Connected Database

IDE – Integrated Development Environment

IDL – Interface Definition Language

IPC – Inter-Process Communication

IP – Internet Protocol

Java IDL – Java Interface Definition Language

LAN – Local Area Network

LISOpp – Lightweight self-organizing reconfiguration of opportunistic infrastructure-mode

Wi-Fi networks

LRM-Fw – Local Resource Management Framework

LTE – Long Term Evolution

M2M – Machine-to-Machine

MA-Fi – Mobile Ad-Hoc Wi-Fi

MAC – Media Access Control

MANET – Mobile Ad Hoc Network

MAP – Mobile Acess Portable Storage

MSN – Mobile Social Network

NIC – Network Interface Card

P2P – Peer-to-Peer

PHY – Physical Layer

PSK – Pre-Shared Key

RTS – Request to Send

SAP – Sensor Access Point

SDK – Software Development Kit

Referências 85

SMTP – Simple Mail Transfer Protocol

SO – Sistema Operacional

SSID – Service Set Identifier

SSID – Service Set Identifier

SSL – Secure Socket Layer

STA – Wireless LAN Station

TX – Transmission

V2I – Vehicle-to-Infrastructure

V2V – Vehicle-to-Vehicle

WLAN – Wireless Local Area Network

WMAN – Wireless Metropolitan Area Network

WPAN – Wireless Personal Area Network

WWAN – Wireless Wide Área Network

XML – eXtensible Markup Language

Apêndice ACÓDIGO FONTE DO MIDDLEWARE NET-OPP

Neste Apêndice, são apresentados o código fonte do middleware Net-Opp e das aplicações

Crowd Wi-Fi e Black Box. O código é livre sob licença GPL (General Public License). Seu

código fonte se encontra disponível no repositório do git do Laboratório iMobilis, através do

endereço eletrônico: http://gitlab.uguide.com.br/charlesgarrocho/net-opp.

Apêndice BMODELAGEM DA ARQUITETURA DE NET-OPP

Neste Apêndice, apresenta-se a modelagem dos módulos da arquitetura do middleware Net-

Opp. Especificamente, descrevem-se as funcionalidades providas pelas classes presentes em

cada módulo que foi foi descrito na Seção 4.2 do Capítulo 4.

B.1 Módulo API

Como mencionado na Seção 4.2 do Capítulo 4, para a definição das interfaces da API do

Net-Opp foi utilizada as linguagens AIDL e JavaIDL, com o objetivo de dar suporte à comu-

nicação IPC. Dessa forma, a interface nomeada INetOppService foi especificada em AIDL e

JavaIDL, visando dar acesso aos recursos do Net-Opp. Essa interface pode ser vista no Código

Fonte B.1.

Código Fonte B.1: Interface que possui a definição dos métodos para acesso ao Net-Opp.

i n t e r f a c e I N e t O p p S e r v i c e {

Boolean s t a r t N e t w o r k ( ) ;

Boolean s topNetwork ( ) ;

Boolean a d d F i l e ( S t r i n g a d d r e s s ) ;

Boolean d e l F i l e ( S t r i n g a d d r e s s ) ;

Boolean addTradeOf f ( O b j e c t t r a d e o f f ) ;

j a v a . u t i l . L i s t < Person > c l i e n t L i s t ( ) ;

j a v a . u t i l . L i s t < S t r i n g > f i l e L i s t ( ) ;

}

B.1 Módulo API 88

Os métodos que compõem a INetOppService estão descritos a seguir:

• startNetwork: Este método permite a inicialização do processo criação de redes opor-

tunistas, onde o módulo Gerenciador de Rede é inciado. Caso ocorra alguma erro nessa

inicialização, um Booleano falso é retornado à aplicação, caso contrário, um Booleano

verdadeiro é retornado.

• stopNetwork: Este método permite a finalização do processo de criação de redes oportu-

nistas, onde o módulo Gerenciador de Rede é finalizado. Caso ocorra alguma erro nessa

finalização, um Booleano falso é retornado à aplicação, caso contrário, um Booleano


• addFile: Este método permite que um arquivo seja compartilhado na rede oportunista.

Ao ser executado, o conteúdo é automaticamente armazenado no módulo Gerenciador de

Informações. Caso ocorra alguma erro nesse compartilhamento do arquivo, um Booleano

falso é retornado à aplicação, caso contrário, um Booleano verdadeiro é retornado.

• delFile: Este método permite que um arquivo seja retirado da lista de arquivos comparti-

lhados na rede oportunista. Ao ser executado, o conteúdo é automaticamente retirado do

módulo Gerenciador de Informações. Caso ocorra alguma erro nesse compartilhamento

do arquivo, um Booleano falso é retornado à aplicação, caso contrário, um Booleano


• addTradeOff : Este método permite que uma informação de tradeoff (por exemplo o nível

de bateria do dispositivo) seja adicionado na rede oportunista. O módulo Gerenciador de

Informações utiliza essa informação para realiza a ordenação da lista de dispositivos que

serão pontos de acesso. Caso ocorra alguma erro nessa adição do tradeoff, um Booleano

falso é retornado à aplicação, caso contrário, um Booleano verdadeiro é retornado.

• clientList: Este método permite que seja retornado uma lista de todos os clientes co-

nectados ao ponto de acesso. Cada item da lista é representada por um tipo Person, onde

cada objeto possui um endereço MAC e o valor de tradeoff.

• fileList: Este método permite que seja retornado uma lista de todos os arquivos com-

partilhados na rede oportunista. Cada item da lista é representado por um tipo String,

onde cada objeto compreende uma concatenação do endereço MAC do dispositivo que

compartilhou o arquivo, mais o nome do arquivo.

B.2 Módulo Gerenciador de Rede 89

B.2 Módulo Gerenciador de Rede

O módulo Gerenciador de Rede é composto, basicamente, por três classes (Figura B.1):

• NetworkManager: Esta classe é responsável pelo gerenciamento do dispositivo, de modo

a auxiliá-lo a se tornar ponto de acesso ou cliente. Para isso, esta classe possui duas

variáveis e quatro métodos. A variável status se o dispositivo está no modo ponto de

acesso ou no modo cliente. A variável manager corresponde a uma instância da classe

WifiManager, que é responsável pelo gerenciamento do Wi-Fi. O método run é o método

de execução inicial da Thread. O método randInteger gera um valor aleatório através de

um valor mínimo e máximo. O método managerAP realiza o gerenciamento do modo

ponto de acesso utilizando a classe WifiApManager. O método managerSTA realiza o

gerenciamento do modo cliente utilizando a classe WifiManager.

• WifiApManager: Esta classe é responsável pelo gerenciamento do modo ponto de acesso

do Wi-Fi do dispositivo, possibilitando o dispositivo se alternar para o modo ponto de

acess. A classe é composta por três variáveis e três métodos. A variável status indica

se o dispositivo está ou não em modo ponto de acesso. A variável manager corresponde

a uma instância da classe WifiManager, que é responsável pelo gerenciamento do Wi-

Fi. O método setWifiApEnabled permite ativar ou desativar o modo ponto de acesso.

O método isWifiApEnabled retorna o estado atual do dispositivo, se ele está no modo

cliente ou no modo ponto de acesso. O método getClientList retorna uma lista de clientes

(ClientScanResult) conectados ao ponto de acesso.

• ClientScanResult: Esta classe é responsável por assumir o papel de um cliente conectado

ao ponto de acesso. Para isso, esta classe possui três variáveis. A variável IpAddress que

representa o endereço IP do cliente. A variável HwAddress que representa o endereço

MAC do cliente. A variável isReachable que indica se o cliente está comunicável ou não.

Figura B.1: Diagrama de classes do módulo Gerenciador de Rede.

B.3 Módulo Gerenciador de Informações 90

B.3 Módulo Gerenciador de Informações

O módulo Gerenciador de Informações é composto por cinco classes (Figura B.2):

• StateAP: Esta classe estende a classe Thread, e é responsável pelo gerenciamento do

dispositivo no estado de ponto de acesso, sendo composta por um servidor que é repre-

sentado pela classe Server. Esta classe é composta por três variáveis e quatro métodos. A

variável clientList representa uma lista de clientes (cada cliente é representado pela classe

Person) conectados ao ponto de acesso. A variável ipList representa uma lista de endere-

ços IP de todos os clientes conectados ao ponto de acesso. A variável fileList representa

uma lista de arquivos compartilhados por todos os dispositivos na rede oportunista. O

método run é o método de execução inicial da Thread. O método addFile permite que um

arquivo seja compartilhado na rede oportunista. O método listClients retorna ao disposi-

tivo requisitante a lista clientList. O método listFiles retorna ao dispositivo requisitante a

lista fileList.

• StateSTA: Esta classe estende a classe Thread, e é responsável pelo gerenciamento do

dispositivo no estado de cliente, sendo composta por um cliente que é representado pela

classe Client. Esta classe é composta por duas variáveis e quatro métodos. A variável cli-

entList representa uma lista de clientes (cada cliente é representado pela classe Cliente)

conectados ao ponto de acesso. A variável ipList representa uma lista de endereços IP de

todos os clientes conectados ao ponto de acesso. A variável fileList representa uma lista

de arquivos compartilhados por todos os dispositivos na rede oportunista. O método run

é o método de execução inicial da Thread. O método sendMyFiles realiza o compartilha-

mento de um arquivo submetendo as informações do dispositivo juntamente com as do

arquivo ao servidor (Server) da classe StateAP do dispositivo ponto de acesso. O método

getClientList realiza uma requisição ao servidor (Server) da classe StateAP do dispositivo

ponto de acesso, de listagem da lista de clientes (Person) conectados ao ponto de acesso.

O método getClientList realiza uma requisição ao servidor (Server) da classe StateAP do

dispositivo ponto de acesso, de listagem dos arquivos compartilhados na rede oportunista.

• Person: Esta classe é responsável por representar um cliente conectado ao ponto de

acesso. Esta classe é composta por duas variáveis e dois métodos. A variável id representa

uma identificação do dispositivo, por exemplo seu endereço MAC. A variável tradeoff

representa um dado (por exemplo o nível de bateria do dispositivo) para ser utilizado para

escolha de um Person. Essa escolha é feita através do método compareTo, que permite

ser utilizado para ordenação de uma lista de Person. Essa ordenação é feita pela classe

B.3 Módulo Gerenciador de Informações 91

StateAP, de forma a definir os próximos dispositivos a se tornarem um ponto de acesso

caso a rede fique inacessível.

• Client: Esta classe é responsável por efetuar uma conexão à classe Server. Esta classe

é composta por duas variáveis e dois métodos. A variável port representa o número

da porta que será utilizada para conectar ao ponto de acesso. A variável socket é uma

instância da classe Socket, e este permite a conexão e manipulação dos objetos na rede.

Os métodos send e recv permitem, respectivamente, o envio e recebimento de um Object

ao dispositivo que o socket estiver conectado.

• Server: Esta classe é responsável por criar um servidor no dispositivo ponto de acesso,

e permitir conexões da classe Client. Esta classe é composta por duas variáveis e dois

métodos. A variável port representa o número da porta que será utilizada para rodar o

servidor no dispositivo ponto de acesso. A variável socket é uma instância da classe Ser-

verSocket, e este permite a conexão e manipulação dos objetos na rede. Os métodos send

e recv permitem, respectivamente, o envio e recebimento de um Object ao dispositivo que

estiver conectado ao socket.

Figura B.2: Diagrama de classes do módulo Gerenciador de Informações.

B.4 Módulo Provedor de Conteúdos 92

B.4 Módulo Provedor de Conteúdos

O módulo Provedor de Conteúdos é composto, basicamente, por quatro classes (Figura

B.3):

• ContentProvider: Esta classe estende a classe Thread, e é responsável pelo gerencia-

mento do download e upload de arquivos de um dispositivo, tanto ponto de acesso como

clientente, sendo composta por um servidor representado pela classe Server. Esta classe

é composta por uma variável e dois métodos. A variável fileList representa uma lista de

arquivos compartilhados por todos os dispositivos na rede oportunista. O método run é o

método de execução inicial da Thread. O método sendFile permite que um arquivo seja

enviado para o dispositivo que fez a solicitação de envio. O método putFile permite que

um arquivo que foi compartilhado na rede oportunista, seja automaticamente obtido. A

classe GetFile é executada com o objetivo de obter o arquivo que acabou de ser compar-

tilhado.

• Client: Esta classe é responsável por efetuar uma conexão à classe Server. Esta classe

é composta por duas variáveis e dois métodos. A variável port representa o número

da porta que será utilizada para conectar ao ponto de acesso. A variável socket é uma

instância da classe Socket, e este permite a conexão e manipulação dos objetos na rede.

Os métodos send e recv permitem, respectivamente, o envio e recebimento de um Object

ao dispositivo que o socket estiver conectado.

• Server: Esta classe é responsável por criar um servidor no dispositivo ponto de acesso,

e permitir conexões da classe Client. Esta classe é composta por duas variáveis e dois

métodos. A variável port representa o número da porta que será utilizada para rodar o

servidor no dispositivo ponto de acesso. A variável socket é uma instância da classe Ser-

verSocket, e este permite a conexão e manipulação dos objetos na rede. Os métodos send

e recv permitem, respectivamente, o envio e recebimento de um Object ao dispositivo que

estiver conectado ao socket.

• GetFile: Esta classe estende a classe Thread, e é responsável por realizar o download

de um arquivo na rede oportunista. Esta classe é composta por uma variável e um mé-

todo. A variável file representa as informações (identificação do dispositivo e do arquivo)

necessárias para realizar o download do arquivo. O método run é o método de execução

inicial da Thread, e neste método é feito as operações necessárias para baixar o arquivo,

utilizando a classe Client.

B.4 Módulo Provedor de Conteúdos 93

Figura B.3: Diagrama de classes do módulo Provedor de Conteúdos.

NET-OPP: UM MIDDLEWARE TRANSPARENTE PARA FORMAÇÃO …

Documents

Transcript of NET-OPP: UM MIDDLEWARE TRANSPARENTE PARA FORMAÇÃO …