Centro Universitrio Vila Velha Curso de Cincia da Computao

Guilherme Rodrigues Martins Jackson do Prado Rafalski Rodolpho Freitas Resende

PROTTIPO DE REDE TOLERANTE A FALHAS E DESCONEXES UTILIZANDO COMUNICAO VIA BLUETOOTH ENTRE DISPOSITIVOS MVEIS ANDROID

Vila Velha 2011

Guilherme Rodrigues Martins Jackson do Prado Rafalski Rodolpho Freitas Resende

PROTTIPO DE REDE TOLERANTE A FALHAS E DESCONEXES UTILIZANDO COMUNICAO VIA BLUETOOTH ENTRE DISPOSITIVOS MVEIS ANDROID
Trabalho de Concluso de Curso apresentado ao Centro Universitrio Vila Velha como requisito parcial para a obteno do grau de Bacharel em Cincia da Computao. Orientador: Marcello Novaes de Amorim

Vila Velha 2011

Guilherme Rodrigues Martins Jackson do Prado Rafalski Rodolpho Freitas Resende

PROTTIPO DE REDE TOLERANTE A FALHAS E DESCONEXES UTILIZANDO COMUNICAO VIA BLUETOOTH ENTRE DISPOSITIVOS MVEIS ANDROID
BANCA EXAMINADORA

Prof. Msc. Marcello Novaes de Amorim Centro Universitrio Vila Velha Orientador

Prof. Msc. Hudson Ramos Centro Universitrio Vila Velha

Prof. Msc. Klayson Sesana Bonatto Centro Universitrio Vila Velha Trabalho de Concluso de Curso aprovado em 21/10/2011.

Ns, Guilherme Rodrigues Martins, Jackson do Prado Rafalski e Rodolpho Freitas Resende, autorizamos que a UVV, sem nus, promova a publicao de nossa monograa em pgina prpria na Internet ou em outro meio de divulgao de trabalho cientco.

Aos nossos pais, familiares e amigos...

AGRADECIMENTOS
Agradecemos primeiramente a Deus por nos conceder sade e sabedoria, para que fosse possvel a concluso deste trabalho. Agradecemos s nossas famlias que nos proporcionaram a possibilidade de concluir mais uma etapa de nossa vida. Por m, agradecemos a cada um dos professores do curso de Cincia da Computao, que, ao longo de toda esta jornada, nos forneceram conhecimento suciente para a elaborao deste trabalho de concluso de curso, em especial ao nosso orientador, prof. Marcello Novaes de Amorim, que nos auxiliou na execuo deste projeto audacioso.

As pessoas no sabem o que querem, at mostrarmos a elas.

Steve Jobs

LISTA DE FIGURAS
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 As Fases da Operao do TCP . . . . . . . . . . . . . . . . . . . . . . 21 22 23 24 24 27 30 31 34 38 43 45 46 49 53 54 54 55 56 57 58 59

Pilha de Protocolos da Internet e de uma DTN . . . . . . . . . . . . . . as conguraes salto a salto de um sistema store-and-forward . . . .

Sistema de Transferncia de Custdia . . . . . . . . . . . . . . . . . . . Sistema de Transferncia de Custdia - Aviso de Recebimento . . . . . Grafo Temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logomarca da OHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arquitetura Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ciclo de Vida da Atividade Android . . . . . . . . . . . . . . . . . . . . . Redes Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . O Ambiente de Tempo de Execuo Java . . . . . . . . . . . . . . . . . Comparativo de Camadas entre as Pilhas de Protocolos . . . . . . . . . Estrutura da Classe Destinatrio . . . . . . . . . . . . . . . . . . . . . . Estrutura do Pacote DTN . . . . . . . . . . . . . . . . . . . . . . . . . . Estrutura de Estados do Pacote DTN . . . . . . . . . . . . . . . . . . . . Representao da Tabela de Relacionamentos . . . . . . . . . . . . . . Incluso de novos relacionamentos adquiridos na conexo de B e C . . Incluso de novos relacionamentos adquiridos na conexo de A e B . . Diagrama de Estados da Camada Bluetooth . . . . . . . . . . . . . . .

Representao de Envio de Informao com Custdia . . . . . . . . . . Representao de Envio de Informao sem Custdia . . . . . . . . . . Diagrama de Pacote da Arquitetura do Projeto . . . . . . . . . . . . . .

23 24 25 26

Diagrama de Classe da Camada de Aplicao . . . . . . . . . . . . . . Diagrama de Classe da Camada de Empacotamento . . . . . . . . . .

60 61 62 63

Diagrama de Classe da Camada de Roteamento . . . . . . . . . . . . . Diagrama de Classe da Camada Fsica . . . . . . . . . . . . . . . . . .

Lista de Siglas
AAC Advanced Audio Coding ACK Acknowledgement AMR Audio Modem Riser CHANTS Challenged Networks CPU Unidade Central de Processamento DTN Delay-Tolerant Networking DTNRG Delay Tolerant Networking Research Group EDGE Enhanced Data rates for GSM Evolution FHS Frequency Hopping Synchronization FHSS Frequency Hopping Spread Spectrum GHz Gigahertz GIF Graphical Interchange Format GPS Global Positioning System GPU Graphics Processing Unit GSM Groupe Special Mobile IEEE Instituto de Engenheiros Eletricistas e Eletrnicos IP Internet Protocol IRTF Internet Research Task Force ISM Industrial, Scientic and Medical JPG Joint Photographic Experts Group

JVM Mquina Virtual Java Kbps Kilobit Por Segundo LAN Local Architecture Network MAC Media Access Control MANET Mobile Ad-Hoc Network MPEG Moving Picture Experts Group MP3 MPEG-12 Audio Layer 3 NDK Kit de Desenvolvimento Nativo OHA Open Handset Alliance OOP Object-Oriented Programming OpenGL Open Graphics Library OpenGL ES OpenGL for Embedded Systems OSI Open Systems Interconnection PNG Portable Network Graphics POO Programao Orientada a Objetos PROPHET Probabilistic Routing Protocol using History of Encounters and Transitivity RFC Request for Comments SDK Kit de Desenvolvimento de Software SGL Symbol Graphics Library SIG Bluetooth Special Interest Group SSL Secure Socket Layer TCP Transmission Control Protocol URI Uniform Resource Identier VANETs Vehicular Ad hoc Networks XML Extensible Markup Language

SUMRIO

RESUMO 1 INTRODUO 1.1 Justicativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Objetivo Especco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 REDES TOLERANTES A ATRASOS E DESCONEXES 2.1 Denio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Limitaes da Arquitetura TCP/IP . . . . . . . . . . . . . . . . . . . . . . 2.3 Arquitetura DTN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Transferncia de Custdia . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 O Roteamento em Delay-Tolerant Networking (DTN) . . . . . . . . . . . 2.6 O Cenrio Determinstico . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7 O Cenrio Estocstico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8 O Cenrio do Prottipo Proposto . . . . . . . . . . . . . . . . . . . . . . 3 REFERENCIAL TERICO 3.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Kit de Desenvolvimento de Software (SDK) . . . . . . . . . . . . 3.1.3 Kit de Desenvolvimento Nativo (NDK) . . . . . . . . . . . . . . . 15 16 17 17 18 19 19 20 21 23 25 26 27 27 28 28 28 29 29

3.1.4 Open Handset Alliance (OHA) . . . . . . . . . . . . . . . . . . . 3.1.5 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.6 Componentes de uma Aplicao Android . . . . . . . . . . . . . 3.1.7 Android Activity Lifecycle (Ciclo de Vida da Atividade Android) . 3.2 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Frequency Hopping Spread Spectrum (FHSS) . . . . . . . . . . 3.2.3 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4 Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 A Linguagem Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Programao Orientada a Objetos (POO) . . . . . . . . . . . . . 3.3.3 A Mquina Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . 4 ARQUITETURA DO PROTTIPO 4.1 Diviso de Camadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Camadas da Arquitetura Proposta . . . . . . . . . . . . . . . . . . . . . 4.2.1 Aplicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Empacotamento . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Roteamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.4 Fsica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Modelo de Comunicao entre Nodos . . . . . . . . . . . . . . . . . . . 4.3.1 Envio com Custdia . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Envio sem Custdia . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Diagrama de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Diagrama de Pacotes da Arquitetura do Projeto . . . . . . . . . . 4.4.2 Diagrama de Classe da Camada de Aplicao . . . . . . . . . .

30 31 32 34 35 35 36 37 38 40 40 41 42 44 44 45 45 48 53 55 57 57 57 58 58 59

4.4.3 Diagrama de Classe da Camada de Empacotamento . . . . . . 4.4.4 Diagrama de Classe da Camada de Roteamento . . . . . . . . . 4.4.5 Diagrama de Classe da Camada Fsica . . . . . . . . . . . . . . 5 TESTES 5.1 Teste de Consumo de Bateria . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Consumo de Bateria pelo Bluetooth . . . . . . . . . . . . . . . . 5.2 Teste de Consumo de Memria . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Consumo de Memria . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Teste de Tempo de Conexo . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Teste de Processamento de Pacotes . . . . . . . . . . . . . . . . . . . . 5.5 Tamanho em Bytes de cada Cabealho . . . . . . . . . . . . . . . . . . 6 CONCLUSO 6.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . REFERNCIAS

59 60 61 64 64 64 65 65 65 66 66 67 68 70

RESUMO
O enorme sucesso da Internet nas ltimas trs dcadas se deve principalmente aos protocolos denominados TCP/IP que cada vez mais, vem se tornando como base para novas aplicaes por causa de sua exibilidade, ecincia e robustez, permitindo suportar diversas aplicaes em diferentes cenrios. No entanto, em cenrios com longos atrasos e frequentes desconexes, os protocolos TCP/IP simplesmente no funcionam, e novos protocolos so necessrios. Redes que possuem essas caractersticas so chamadas de redes tolerantes a atrasos e desconexes (Delay-Tolerant Networking - DTN). Redes DTN permitem transmisses de dados entre dispositivos mesmo que eles estejam inalcanveis durante um perodo, ou seja, a conectividade m a m no garantida. Para tanto, mquinas intermedirias devem armazenar os dados destinados a outros participantes at que sejam entregues. Esse procedimento conhecido como store-and-forward. Diante do crescente nmero de usurios de dispositivos mveis, diversas aplicaes que necessitem de uma arquitetura de rede tolerante a falhas e desconexes, poderiam usufruir dessa infraestrutura sem o que est se formando. Assim, este trabalho descreve as limitaes relacionadas arquitetura TCP/IP, investiga o estado da arte das redes DTN e prope um prottipo de rede tolerante a falhas e desconexes, utilizando comunicao via Bluetooth entre dispositivos mveis com o sistema operacional Android. Palavras-chave: Bluetooth. TCP. IP. Dispositivos Mveis. Protocolo. Delay-Tolerant Networking (DTN). Sem o. Java.

15

INTRODUO

O modelo TCP/IP foi teoricamente projetado para operar de forma independente da tecnologia de sub-rede que existisse. Assim, o perl de protocolos TCP/IP deve operar em redes cabeadas conveis, redes sem o, redes de satlite, redes pticas, etc. No entanto, os atuais mecanismos do TCP/IP se baseiam em suposies tpicas de redes cabeadas convencionais, tais como a existncia de uma conectividade m a m entre fonte e destino durante todo o perodo correspondente sesso de comunicao, atrasos de comunicao relativamente pequenos (da ordem de milissegundos), baixas taxas de erros, mecanismos de retransmisso efetivos para reparar erros e suporte a taxas de dados bidirecionais relativamente simtricas [21, MOBILEPEDIA, 2011]. O grande problema surge quando no possvel formar uma rede de alta conectividade para efetuar a troca de informaes entre dois pontos que estejam localizados em regies distintas, onde no possvel a criao de um enlace de comunicao vivel para aplicao. Dessa forma, o TCP/IP no se mostra muito adequado, por exemplo, para redes mveis, redes sem o dinmicas, redes de sensores, redes com enlaces de taxas variveis e assimtricas, redes interplanetrias e redes rurais esparsas. Essas redes so caracterizadas por atrasos longos ou variveis, alta ndices de erro, limitao de recursos (ex. memria e bateria). O TCP/IP apresenta um baixo desempenho nessas redes. Convencionou-se denominar a classe de redes com estas caractersticas especcas de Redes Tolerantes a Atrasos e Desconexes (DelayTolerant Networking - DTN) [21, MOBILEPEDIA, 2011]. Redes Tolerantes a Atrasos e Desconexes so redes sem o nas quais desconexes so to frequentes, que, na maioria do tempo no existe um caminho completo entre uma origem e um destino. As principais razes mencionadas na literatura para as desconexes so a mobilidade dos nodos e a operao em ambientes hostis [21, MOBILEPEDIA, 2011].

16

O grupo de pesquisas em Redes Tolerantes a Atrasos (Delay Tolerant Networking Research Group - DTNRG) do Internet Research Task Force (IRTF) disponibiliza uma srie de documentos de pesquisa, incluindo a proposta de uma arquitetura DTN denida em um Internet Draft [21, MOBILEPEDIA, 2011]. Essa arquitetura uma evoluo da proposta do Projeto Internet Interplanetria [21, MOBILEPEDIA, 2011] e descreve a forma como um conjunto de nodos se organiza para armazenar e encaminhar mensagens cooperativamente [21, MOBILEPEDIA, 2011]. De acordo com [21, MOBILEPEDIA, 2011], h muitos casos de aplicao para redes DTN, tais como redes de sensores que monitoram a vida selvagem, redes militares, redes ad hoc veiculares (VANETs - Vehicular Ad hoc Networks), redes para fornecer acesso Internet de baixo custo a comunidades remotas. Visando ao crescimento de usurios de dispositivos mveis, este Trabalho de Concluso de Curso vai apresentar um prottipo de rede DTN para comunicao via Bluetooth que opere como um servio sobre o sistema operacional Android. Dessa forma, existem aplicaes que utilizam a arquitetura TCP/IP para troca de dados, aplicaes, que julgarem necessrio o uso do prottipo proposto, podero utiliz-lo. De acordo com pesquisa [21, MOBILEPEDIA, 2011], o sistema operacional Android, j domina 43% do mercado mundial de smartphones. Foram vendidos mais de 428 milhes de smartphones com Android apenas no segundo trimestre de 2011. Este trabalho est organizado como descrito a seguir. As sees 1.3 e 1.4 apresentam os objetivos do trabalho. A arquitetura DTN e suas denies so apresentadas no captulo 2. No captulo 3 sero apresentadas as tecnologias envolvidas para a construo da arquitetura proposta. No captulo 4 ser descrito o prottipo de rede DTN proposto para dispositivos mveis. Por m, os ltimos captulos vo apresentar alguns testes realizados, seguidos da concluso.

1.1

Justicativa

Por vezes as tecnologias de redes padro simplesmente no funcionam no contexto de desao das comunicaes, o que particularmente imposto pelas usuais falhas operacionais. Por exemplo, uma rbita em torno de Marte no pode utilizar os protocolos padro da internet devido latncia envolvida - a ligao restringida pelos tempos de ida e volta que variam de 4 a 20 minutos [23, N4C, 2008].

17

No contexto de dispositivos mveis, aplicaes que operem em ambientes hostis, sem garantia de conectividade m a m, requerem uma arquitetura de rede DTN para o seu funcionamento. Aplicaes para dispositivos mveis, como troca de mensagens, transferncia de arquivos, repositrios para compartilhamento e/ou backup, educao distncia, formulrios eletrnicos, coleta de informaes (votao, censo, entre outros), vdeos, pginas web, distribuio de jornais e revistas no formato eletrnico, operando em ambientes dinmicos, com constantes movimentaes dos nodos, so alguns exemplos que necessitam de uma arquitetura de rede DTN. As redes DTN so um tema ainda muito recente que possui diversos aspectos desaadores, por isso tm despertado o interesse de muitos pesquisadores da rea de redes. O sucesso de aplicaes comerciais nessa rea nos prximos anos deve indicar a importncia que as DTN devem assumir no futuro [25, OLIVEIRA, 2008]. Por meio do prottipo de rede proposto neste trabalho, pesquisas futuras podero desenvolver aplicaes para dispositivos mveis Android usando a implementao da arquitetura proposta, alm de realizao de experimentos, validando diversos protocolos e aplicaes em ambientes DTN reais.

1.2

Motivao

Baseado no crescimento e popularizao de dispositivos mveis com o sistema operacional Android, uma imensa infraestrutura de rede ad hoc vai se formando em diferentes ambientes. Aplicaes especcas podero utilizar, por meio do prottipo de rede apresentado neste trabalho, tanto em seu ambiente interno quanto em seu ambiente externo, essa infraestrutura de rede para o trfego de dados e comunicao entre as aplicaes.

1.3

Objetivo Geral

O objetivo geral deste trabalho desenvolver, baseado no princpio store-andforward das redes DTN, um prottipo para comunicao via Bluetooth entre dispositivos mveis com o sistema operacional Android. O prottipo ser dividido em quatro camadas: Fsica, Roteamento, Empacotamento e Aplicao.

18

Esse prottipo dever: Enviar e receber mensagens com tolerncia a atrasos e desconexes entre os dispositivos mveis mesmo em momentos com grande perodo de desconexo. Suportar aplicaes que utilizem de sua arquitetura DTN para comunicao em rede.

1.4

Objetivo Especco

Implementar um protocolo de roteamento baseado no histrico de encontros dos nodos da rede, que suporte falhas e desconexes de forma que seja possvel a troca de informaes entre os nodos conhecidos.

19

REDES TOLERANTES A ATRASOS E DESCONEXES

2.1

Denio

Uma DTN, Delay-Tolerant Networking, ou Rede Tolerante a Atrasos e Desconexes, uma rede ad hoc, ou MANET (Mobile Ad-Hoc Network ), composta por conexes sem o entre os nodos, que se autocongura de acordo com a insero e remoo de novos nodos em sua estrutura. Alm disso, consegue comportar-se de forma adequada mesmo com desconexes repentinas ou atrasos na transmisso de dados entre dois nodos [35, TABARELLI, 2009]. Essas redes tm o objetivo de prover conexes entre dispositivos em reas que no so bem dotadas da atual tecnologia de rede. Alm disso, o desempenho degrada consideravelmente com o aumento do nmero de saltos em uma comunicao sem o [28, OTT, 2006]. Apesar de o termo DTN ser o mais utilizado na literatura, tambm podem ser encontradas outras terminologias, tais como: redes com conectividade eventual, redes mveis parcialmente conectadas, redes desconectadas, redes com conectividade transiente, redes incomuns, redes extremas e, mais recentemente, redes com desaos (CHAllenged NeTworkS - CHANTS) [6, CHEN, 2006]. Caractersticas como baixa densidade de nodos, altos ndices de erros de comunicao, alta latncia, limitaes de banda e longevidade de nodos criam cenrios desaadores de rede, que na literatura so chamados de Challenged Networks [9, FALL, 2003]. Essas caractersticas das redes fazem com que as aplicaes nesses cenrios tenham um comportamento diferente do que teriam em uma rede tradicional. Um exemplo de ambiente onde os protocolos convencionais da Internet no funcionam so as redes ad hoc mveis (Mobile Ad hoc NETworks - MANETs) [19, MACKER, 2009], nas quais a topologia da rede pode mudar constantemente quando a mobilidade dos nodos muito alta, provocando frequentes desconexes[11, FALL,

20

2005].

2.2

Limitaes da Arquitetura TCP/IP

A principal causa de a Internet convencional no funcionar bem em redes com longos atrasos e frequentes desconexes est na operao do protocolo Transmission Control Protocol (TCP) [30, POSTEL, 1981]. O TCP um protocolo da camada de transporte da arquitetura TCP/IP. Segundo [32, KUROSE, 2006], posicionada entre as camadas de aplicao e de rede, a camada de transporte uma pea central da arquitetura de rede em camadas. Entre suas principais caractersticas, destacam-se as seguintes [42, KUROSE, 2006]: Orientado conexo - A aplicao envia um pedido de conexo para o destino e usa a conexo para transferir dados. Ponto a ponto - Uma conexo TCP estabelecida entre dois pontos. Conabilidade - O TCP usa vrias tcnicas para proporcionar uma entrega convel dos pacotes de dados. O TCP permite a recuperao de pacotes perdidos, a eliminao de pacotes duplicados, a recuperao de dados corrompidos, e pode recuperar a ligao em caso de problemas no sistema e na rede. De acordo com [25, OLIVEIRA, 2008], como ilustrado na Figura 1, a operao do TCP pode ser dividida em trs fases: estabelecimento de conexo, transferncia de dados e desconexo. O estabelecimento de conexo se faz com a troca de trs mensagens (three-way handshake). Em seguida, inicia-se a transferncia de dados, onde a boa recepo dos dados pelo destino deve ser sinalizada por reconhecimentos positivos (acknowledgments - ACKs). O encerramento de uma conexo TCP se d com a troca de quatro mensagens. Quando uma mensagem precisa ser enviada, ela armazenada e encaminhada nodo a nodo, desde a origem at o destino. Por utilizar essa tcnica, diz-se que as DTN so redes do tipo armazena e encaminha (store-and-forward ), ou seja, primeiro a mensagem recebida integralmente e armazenada para, em seguida, ser enviada ao prximo nodo, que pode ou no ser o destino [25, OLIVEIRA, 2008].

21

Figura 1: As Fases da Operao do TCP [25, OLIVEIRA, 2008]

2.3

Arquitetura DTN

A arquitetura DTN prev a utilizao da tcnica de comutao de mensagens e o armazenamento persistente dos dados, denindo uma sobrecamada (overlay ) abaixo da camada de aplicao. Essa nova camada denominada camada de empacotamento (Bundle Layer ) [26, OLIVEIRA, 2008]. Os pontos que armazenam as mensagens so denominados nodos DTN, sejam origem e destino, sejam pontos intermedirios. O protocolo de empacotamento executado em todos os nodos DTN pertencentes rede [20, MEDEIROS, 2009]. Somente alguns dos nodos podem estar conectados, enquanto os demais podem no ter conectividade. As possibilidades de comunicao podem se alterar a qualquer momento, devido a falhas, deslocamentos ou outros tipos de eventos [27, OLIVEIRA, 2010]. Quando h conectividade entre nodos, um nodo tem oportunidade de enviar dados pela rede em direo a seus destinos nais. Tal oportunidade chamada contato [9, FALL, 2003]. Um par de nodos pode ter, simultaneamente, vrios contatos disponveis, estabelecidos atravs de links fsicos diferentes (Wi-Fi, Bluetooth, etc). A qualidade de cada um desses contatos pode oscilar devido a obstculos e variaes na distncia entre os nodos [27, OLIVEIRA, 2010].

22

O RFC 4838 [5, CERF, 2007] descreve uma arquitetura de uma rede DTN como uma composio da pilha de camadas denidas no modelo OSI, acrescida da nova camada de empacotamento, sobreposta camada de transporte. A existncia dessa camada comum permite que redes DTN sejam compostas por vrias sub-redes heterogneas, nas quais os protocolos de comunicao das camadas inferiores podem ser inteiramente distintos [27, OLIVEIRA, 2010]. A Figura 2 apresenta as pilhas de protocolos da Internet e de uma rede DTN. Podese observar que os protocolos de comunicao da rede so especcos para cada sub-rede, que variam de acordo com o ambiente tecnolgico em que esto operando. Mas todas as sub-redes precisam possuir a camada de empacotamento, que vai fazer a interface entre a aplicao e as diversas tecnologias de comunicao entre as subredes [27, OLIVEIRA, 2010]. Na prtica, a camada de empacotamento isola, por meio de um dispositivo de armazenamento, as camadas inferiores da camada de aplicao. Isso permite a interoperabilidade de dispositivos e redes, que s passaro as informaes para a camada de Aplicao do destino. Os nodos intermedirios passam as informaes de uma camada de empacotamento para outra [20, MEDEIROS, 2009].

Figura 2: Pilha de Protocolos da Internet e de uma DTN A arquitetura DTN prope utilizar esse tipo de rede para encaminhar mensagens completas a cada salto. O roteamento da rede feito da forma armazenar-carregarrepassar, ou seja, utiliza o paradigma store-and-forward [10, FALL, 2004]. Esse procedimento estabelece que cada nodo intermedirio no caminho de uma mensagem deve armazen-la, at que seja possvel o estabelecimento de um contato com outro nodo e o encaminhamento dessa mensagem armazenada, podendo levar um longo tempo [27, OLIVEIRA, 2010]. Segundo [26, OLIVEIRA, 2008], as principais caractersticas encontradas nas re-

23

des DTN so estas: Atrasos Longos: uma DTN no possui tempo estimado para que a mensagem chegue ao seu destino. O delay entre transmisso e recepo pode chegar at a ordem de dias. Frequentes Desconexes: as desconexes podem ocorrer pela mobilidade, que provoca constantes mudanas na topologia da rede, por economia de recursos, por negao de servio ou fatores particulares da rede em questo, como a Guerra Eletrnica em operaes militares. Capacidade de Armazenamento: provavelmente a principal caracterstica das DTN a propriedade de store-and-forward. Essas redes do tipo armazena e encaminha possuem dispositivos em que a informao ca armazenada at o surgimento de um enlace com outro dispositivo cuja transmisso possibilite alcanar seu destinatrio. Cada transmisso intermediria nesse percurso denominada Hop. Esse processo de transmisso exemplicado na Figura 3:

Figura 3: as conguraes salto a salto de um sistema store-and-forward [41, WARTHMAN, 2003]

2.4

Transferncia de Custdia

A camada de empacotamento presente na arquitetura DTN possui um recurso chamado transferncia de custdia. O sistema de transferncia em custdia exemplicado na Figura 4:

24

Figura 4: Sistema de Transferncia de Custdia [41, WARTHMAN, 2003] Esse tipo de transferncia ocorre entre camadas de empacotamentos de nodos sucessivos no caminho da mensagem, da seguinte forma: a camada de empacotamento custodiante da mensagem envia a mensagem para a prxima camada de empacotamento e inicia um temporizador para esperar uma mensagem de reconhecimento (ACK), como mostra na Figura 5. Se a camada receptora da mensagem aceitar ser a nova custodiante da mensagem, ento ela envia de volta um reconhecimento positivo. Caso o tempo de espera pelo reconhecimento expire antes de o transmissor receber o reconhecimento, o transmissor envia novamente a mensagem [7, COUTINHO, 2006].

Figura 5: Sistema de Transferncia de Custdia - Aviso de Recebimento [26, OLIVEIRA, 2008] As transferncias em custdia no garantem conabilidade, a no ser que a fonte pea a conrmao da entrega da mensagem. Em poucas palavras, o conceito por

25

trs das transferncias em custdia delegar para o prximo nodo a responsabilidade de retransmitir a mensagem at que esta atinja o seu destino, o que pode ser considerado uma maneira de, apesar de no muito boa, de garantir conabilidade [7, COUTINHO, 2006].

2.5

O Roteamento em Delay-Tolerant Networking (DTN)

Os dispositivos de armazenamento mveis que servem como nodos intermedirios so chamados Mulas de dados (Data Mules). O termo MULE vem do acrnimo Mobile Ubiquitous LAN Extensions usado por [34, SHAH, 2003]. O termo Data Mule tem sido bastante usado em DTN, e os autores assumiram a traduo mula de dados para indicar a transferncia de informaes por veculos motorizados, pessoas ou animais [26, OLIVEIRA, 2008]. O roteamento DTN determina os critrios para transmisso das mensagens entre os custodiantes at que cada uma alcance o seu destino [20, MEDEIROS, 2009]. Um desao comum a todas as categorias de DTN o roteamento, pois preciso projetar protocolos capazes de superar os problemas dos atrasos extremamente longos e das frequentes desconexes, j que os protocolos convencionais no esto aptos a manipular ecientemente a transmisso de dados em DTN [22, MOTA, 2009]. Existe na literatura uma diversidade de protocolos de roteamento DTN. Segundo resumo de [20, MEDEIROS, 2009], os principais protocolos de roteamento podem ser divididos em quatro grupos: Contato Direto: o nodo de origem s transmitir uma mensagem para uma mula se o prximo contato da mula for diretamente com o destino [40, WANG, 2005]. Primeiro Contato: o nodo de origem enviar a mensagem para a primeira mula com a qual vier a estabelecer contato. A mula de dados, por sua vez, enviar a mensagem para a primeira regio que estabelecer contato e assim consequentemente [14, JAIN, 2004]. Epidmico: a principal proposta para cenrio estocstico, pois suporta a entrega eventual de mensagens a destinos arbitrrios com suposies mnimas relativas ao conhecimento da topologia de rede [38, VAHDAT, 2000].

26

Probabilstico: nos contatos previsveis, apesar do momento exato do estabelecimento de cada contato entre dois nodos da rede ser desconhecido, existe uma previso do intervalo dentro do qual cada contato vai acontecer. estabelecida uma probabilidade de ocorrncia de cada contato. [18, LINDGREN, 2004] apresenta um protocolo de roteamento probabilstico utilizando histricos de encontros e transitividade (Probabilistic Routing Protocol using History of Encounters and Transitivity - PROPHET ). Assim como acontece no roteamento epidmico, quando dois nodos iniciam um contato, so trocadas as listas com informaes que identicam as mensagens armazenadas em cada nodo. A diferena que agora existe uma informao extra para cada mensagem indicada na lista. Essa informao corresponde probabilidade de cada nodo A entregar mensagens para um destino conhecido B (P(a,b) ? [0,1]). O valor de P(a,b) aumenta sempre que A e B se encontram. Se A e B deixam de se encontrar frequentemente, P(a,b) diminui proporo que o tempo transcorre [24, OLIVEIRA, 2007]. Em redes DTN os protocolos de roteamento podem ser utilizados em diferentes cenrios, de acordo com a topologia da rede e sua dinamicidade. Em redes DTN os cenrios de roteamento podem ser divididos em determinsticos e estocsticos.

2.6

O Cenrio Determinstico

De acordo com [25, OLIVEIRA, 2008], a topologia de rede pode ser modelada por um grafo temporal, exemplicado na Figura 6, em que os vrtices so os nodos da rede e os arcos so os enlaces de comunicao sinalizados com os perodos de tempo em que estaro disponveis para transmisso. A tarefa do algoritmo de roteamento encontrar um caminho entre dois nodos nesse grafo, levando-se em considerao os perodos de tempo [20, MEDEIROS, 2009]. Segundo [20, MEDEIROS, 2009], o caminho a ser escolhido pode variar de acordo com os critrios de roteamento. Em geral, o algoritmo procura um caminho da origem at o destino que minimize alguma mtrica, como o atraso ou o nmero de enlaces. O caminho com o menor mtrica chamado caminho mais curto entre dois nodos da rede.

27

Figura 6: Grafo Temporal [26, OLIVEIRA, 2008]

2.7

O Cenrio Estocstico

Diferente do cenrio determinstico, no cenrio estocstico a topologia da rede, sua dinamicidade e as movimentaes dos nodos no so completamente conhecidas. Segundo [25, OLIVEIRA, 2008], em algumas DTN, os nodos no possuem nenhuma informao sobre o estado da rede, o que impossibilita o clculo das melhores rotas. Isso mostra que calcular rotas em cenrios estocsticos mais difcil.

2.8

O Cenrio do Prottipo Proposto

No prottipo proposto neste trabalho, os nodos da rede so formados por dispositivos mveis de diversos usurios. A movimentao dos nodos na rede algo imprevisvel, formando uma topologia desconhecida e de alta dinamicidade. De acordo com essas caractersticas, o prottipo se enquadra em um cenrio estocstico.

28

REFERENCIAL TERICO

Neste captulo sero abordadas as tecnologias necessrias para o desenvolvimento do prottipo de acordo com as caractersticas deste projeto.

3.1
3.1.1

Android
Introduo

Android um software para dispositivos mveis, que consiste em um sistema operacional, middleware e aplicaes principais, com a plataforma construda sobre o Kernel 2.6 do Linux. Envolvida por uma mquina virtual Dalvik, projetada para otimizar os recursos de memria e hardware, o Android foi construdo a partir do zero, com o objetivo explcito de ser a primeira plataforma para mobiles aberta, completa e livre. Atualmente possvel realizar um compartilhamento de informaes entre diferentes processos e aplicaes, por meio de uma espcie de interface denominada Content Provider. Existem alguns provedores de contedo nativos (por exemplo, contatos, mdia, etc) e outros novos podem ser includos, permitindo aos desenvolvedores construir aplicaes ricas. As aplicaes desenvolvidas para Android so feitas usando a linguagem de programao Java. Log, usurios que estiverem familiarizados com programao Java ou alguma outra linguagem de programao orientada a objetos, ter maior facilidade ao desenvolver aplicaes para Android. Apesar de o Android ser executado no Kernel 2.6 do Linux, ele no capaz de executar necessariamente nenhum software Linux, pois preciso compilar os aplicativos usando o SDK do Android para serem executados. Esse fato ocorre em razo de os aplicativos Android executarem arquivos de um formato Dalvik Executable (.dex) e so otimizados para que ocupe uma fatia pequena na memria.

29

3.1.2

Kit de Desenvolvimento de Software (SDK)

Android SDK vai permitir que os desenvolvedores elaborem as aplicaes para os aparelhos de celular. Algumas das tecnologias suportadas pelo sistema operacional so as seguintes: Touchscreen, Threaded text messaging, telefonia GSM, Cmera, GPS, bssola, acelermetro, Bluetooth, EDGE, 3G, e WiFi (que vo depender de hardware) [44, XAVIER, 2011]. A plataforma apresenta suporte para mdias de udio, vdeo e imagem nos formatos MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF, bem como acelerador grco 3D, baseados no OpenGL ES. Os dados podem ser armazenados em SQLite e a pltaforma traz um navegador integrado com base no cdigo livre do motor WebKit [44, XAVIER, 2011]. Normalmente os SDKs so disponibilizados por empresas ou projetos para que programadores externos tenham uma melhor integrao com o software proposto. Um exemplo de um SDK o Android SDK que inclui documentao, cdigo e utilitrios para que programadores consigam desenvolver as suas aplicaes de acordo com um padro de desenvolvimento para o sistema operacional em questo [1, ANDROIDPT, 2010].

3.1.3

Kit de Desenvolvimento Nativo (NDK)

O Android NDK proporciona o recurso de acesso direto GPU utilizando OpenGL, logo se torna possvel a utilizao de recursos como vertex, shaders e fragment shaders. Recursos fundamentais para os efeitos especiais em aplicaes grcas, sem contar no facilitador de trabalho para os desenvolvedores [12, FARIA, 2011]. O Android NDK o segundo kit de desenvolvimento disponvel para programadores interessados no sistema operacional Android. O kit convencional o Android SDK (Software Development Kit ), em que o programador desenvolve na linguagem Java [12, FARIA, 2011]. Com o NDK possvel escrever bibliotecas em C ou C++, com muita rapidez, e integr-las em aplicativos Java, o que resulta em ganho de produtividade na elaborao do aplicativo. Em contrapartida, pode-se perder a portabilidade, pois smartphones Android usam uma ampla variedade de processadores e bibliotecas nativas. Com isso talvez seja necessria a recompilao dos executveis, ao contrrio do

30

aplicativos 100% escrito em Java [12, FARIA, 2011].

3.1.4 Open Handset Alliance (OHA)

Figura 7: Logomarca da OHA A Open Handset Alliance um grupo de 84 empresas de tecnologias mveis que se uniram para acelerar a inovao e oferecer uma experincia mais rica, menos cara e mais mvel. Alguns membros participantes da OHA so: Google, HTC,Dell, Intel, Motorola, Qualcomm, Texas Instruments, Samsung, LG, T-Mobile e Nvidia. O primeiro produto lanado pela aliana o sistema operacional Android para dispositivos mveis. Os membros da OHA esto fortemente empenhados em uma ampla abertura no ecossistema mvel, o que permitir que todos, os setores dos membros da OHA inovem mais rapidamente, para fornecer um melhor atendimento s demandas dos consumidores, que esto cada vez mais exigentes. Com o Android lanado, uma srie de ferramentas de desenvolvimento e tutoriais esto disponveis para ajudar futuros desenvolvedores para o novo sistema, tudo fornecido pela Google, e pode ser encontrado no site do Google Android, que conta com arquivos de ajuda, kit de desenvolvimento de software (SDK), alm de uma comunidade de desenvolvedores.

31

3.1.5

Arquitetura

O sistema operacional Android uma pilha de softwares, onde cada camada da pilha agrupa vrios programas que suportam funes especcas do sistema operacional. Onde possui o Kernel Linux 2.6 como base, no prximo nvel se encontra a camada de bibliotecas e a camada de tempo de execuo. A prxima camada da estrutura da aplicao, no topo da pilha esto s aplicaes. A Figura 8 ilustra as camadas da arquitetura Android.

Figura 8: Arquitetura Android

Applications (aplicaes): essa camada executada dentro do Android Runtime, utilizando classes e servios disponibilizados pelo framework da aplicao. Application Framework (estrutura da aplicao): fornece classes que so utilizadas para desenvolver aplicaes Android. Alm de fornecer uma abstrao para acessar o hardware, gerencia interface de usurio e recursos de aplicativos. Android Runtime (tempo de execuo): onde esto as bibliotecas e a mquina virtual Dalvik, essa camada o mecanismo que alimenta as suas aplicaes e, com as bibliotecas, forma a base para framework da aplicao:

32

Bibliotecas principais: apesar de o desenvolvimento Android ser feito em Java, Dalvik no uma mquina virtual Java. Suas principais bibliotecas fornecem a maior parte das funcionalidades disponveis nas bibliotecas Java. Mquina Virtual Dalvik: uma mquina virtual baseada em registradores que foi otimizada para garantir que um dispositivo execute vrias instncias ecientemente, alm do Kernel Linux para baixo nvel de gerenciamento de memria e threading. Libraries (bibliotecas): um conjunto de bibliotecas C/C++ usadas por diversos componentes do sistema Android. Algumas das principais bibliotecas esto listadas abaixo: Uma biblioteca de mdia para reproduo de mdia de udio e vdeo; Gerenciador de superfcie para fornecer gerenciamento de tela; Bibliotecas grcas que incluem SGL e OpenGL para grcos 2D e 3D; SQLite para suporte banco de dados nativo; SSL e WebKit para o browser web integrado e Securit Internet. Linux Kernel: possui os principais servios, em que esto includos drivers de hardware, rede e gerenciamento de energia, segurana, processos e gerenciamento de memria.

3.1.6

Componentes de uma Aplicao Android

a) Activities (Atividades)

So trechos de cdigos executveis, instanciados pelo usurio ou o pelo sistema operacional sendo executado durante seu ciclo de vida. Interagem com o usurio, solicitao de dados de servios ou de outras atividades, consultas por meio de servios ou Intent Receiver, que parte de um cdigo executvel que responde a pedidos de dados ou servios de outras atividades. Caso o aplicativo possua uma interface de usurio, o mesmo ter uma ou mais atividades. Essas atividades correspondem normalmente a exibir telas (caso a atividade exiba uma tela para o usurio). Quando a atividade se torna inativa, ela poder ser morta pelo sistema operacional para liberar espao na memria.

33

b) Service (Servio)

Normalmente executado em segundo plano desde o momento da sua instanciao at o desligamento do dispositivo mvel. Geralmente no apresenta uma interface de usurio. Recomenda-se que aplicativos com um longo ciclo de vida sejam colocados como um servio. Podemos citar como exemplo, uma sincronizao de dados em segundo plano funcionando continuamente. c) Broadcast e Intent Receivers

Ambos respondem a pedidos de servio com base em outro aplicativo. O Broadcast Receiver r ativado aps a ocorrncia de um evento ao qual est associado. O prprio sistema transmite eventos o tempo todo. Por exemplo, quando um SMS chega, uma chamada ou a bateria fraca. Voc tambm pode enviar suas prprias emisses do seu aplicativo para outro, ou para uma aplicao totalmente diferente. Intent Receiver so mensagens assncronas enviadas entre os blocos de construo principais. A Intent pode ser explcita ou implcita. Uma Intent explcita, o remetente estabelece qual componente especco deve ser o m da recepo. Por sua vez, uma Intent implcita, o remetente especica o tipo de receptor. d) Content Provider (Provedor de contedo)

Utiliza uma interface padro na forma de um URI para atender s requisies de dados de outros aplicativos que no podem saber que provedor de contedo eles esto usando. O sistema operacional procura saber quais aplicativos esto registrados como fornecedores de contedos para o URI dado e envia o pedido para a aplicao apropriada. Se houver mais de um provedor de contedo registrado para o URI solicitado, o sistema operacional pedir ao usurio que decida qual dever usar.

34

3.1.7 Android Activity Lifecycle (Ciclo de Vida da Atividade Android)

O Android prev mecanimos para conservao de recursos, tais como memria e bateria, por serem limitados em grande parte dos dispositivos mveis. Esses mecanismos so evidentes no Ciclo de Vida da Atividade Android, no qual dene os estados ou eventos que uma atividade passa a partir do momento em que ela criada at o trmino dele. O ciclo de vida mostrado esquematicamente na gura 9.

Figura 9: Ciclo de Vida da Atividade Android Abaixo se listam os mtodos do ciclo de vida da atividade e suas funcionalidades, segundo [29, PEREIRA, 2009]:

35

onCreate: mtodo chamado quando a atividade inicialmente criada; onStart: chamado quando a atividade se torna visvel para o usurio; onResume: o topo da pilha de atividade, chamado quando vai iniciar a interao com o usurio; onPause: chamado quando o sistema est perto de comear uma prxima atividade. Geralmente utilizado para gravar as informaes que ainda no foram salvas; onStop: chamado quando a atividade no estiver mais sendo utilizada pelo usurio e perdeu o foco para outra atividade; onDestroy: pode ser chamado quando a atividade terminou ou quando o sistema precisa nalizar atividades para liberao de recursos; onRestart: chamado quando sua atividade estiver interrompida e prestes a ser acionada pelo usurio novamente; onFreeze: possibilita salvar o estado atual da atividade. Ocorre quando a atividade est prestes a ser suspensa. Esses mtodos podero ser utilizados pelas aplicaes para realizarem trabalhos adequados, quando ocorre alguma mudana no estado da atividade.

3.2
3.2.1

Bluetooth
Introduo

A tecnologia Bluetooth foi originalmente desenvolvida pela Ericsoon e tem por nalidade permitir comunicao wireless de curto alcance entre vrios dispositivos. O Bluetooth uma tecnologia em constante evoluo, isso faz com que suas especicaes mudem e surjam novas verses. Estas especicaes foram desenvolvidas e licenciadas pela The Bluetooth Special Interest Group (SIG), que padronizada pela IEEE sob a referncia IEEE 802.15.1. A tecnologia vantajosa, pois permite a comunicao entre diversos dispositivos sem o com baixo consumo de energia, podendo chegar a velocidades de transmisso de at 1 Mbps. Alm disso, se tornou uma tecnologia barata. Por esses motivos,

36

o Bluetooth ganhou popularidade, tornando-se um dos principais mtodos de conexo entre dispositivos da atualidade. Entre os dispositivos que podem ser conectados via Bluetooth, podemos citar telefones celulares, computadores, videogames, impressoras, scanners, mouses, teclados, entre outros [8, ELETRONICA, 2008]. O Bluetooth possui como principais caractersticas: curto alcance; 79 canais; 8 dispositivos conectados ao mesmo tempo; transmisso sncrona e assncrona; conexo ponto a ponto e ponto a multiponto; full-duplex; Dependendo da potncia de transmisso podendo alcanar: 1 metro, 10 metros e 100 metros. Cada sinal de transmisso que passa pelo celular consome apenas 1 miliwatt, 2,5 miliwatt e 100 miliwatt respectivamente [43, WIKIPDIA, 2006]. O Bluetooth essencialmente um padro de formao de rede que funciona em dois nveis: fornece um acordo sobre o nvel fsico (o Bluetooth um padro de rdio frequncia). ele fornece um acordo sobre o nvel do protocolo segundo o qual precisam concordar sobre quando os bits devem ser enviados, quantos devem ser enviados por vez, e como as partes em uma comunicao podem assegurar que a mensagem recebida a mesma que a mensagem enviada.

3.2.2 Frequency Hopping Spread Spectrum (FHSS)

O mtodo FHSS (Frequency Hopping Spread Spectrum - Espalhamento por Saltos em Frequncias) faz parte da tcnica Spread-Spectrum que, basicamente, consiste em espalhar a informao por uma banda muito maior do que a necessria para a sua transmisso. Para tal, FHSS divide a banda total em vrios canais de pequena largura

37

de banda. Dessa forma, transmissor e receptor saltam por esses canais conforme uma sequncia pseudoaleatria conhecida por ambos. [39, VIVASEMFIO, 2007] Ele transmite alguns bits numa determinada frequncia e depois pula para outra frequncia, transmitindo mais alguns bits, e assim por diante. Cada pacote no modelo FHSS transmitido em uma frequncia diferente, que varia de forma conhecida, porm pseudoaleatria, tendo por referncia uma sequncia que somente conhecida pelo transmissor e tambm pelo receptor, o que diculta possveis interceptadores do sinal. Pode-se denir pseudoaleatoriedade como um conjunto nito de nmeros que apresentam caractersticas de nmeros aleatrios para qualquer um que no conhea a frmula geradora dos nmeros [39, VIVASEMFIO, 2007].

3.2.3

Arquitetura

A arquitetura Bluetooth consiste basicamente em dois componentes: um transceiver (hardware) e uma pilha de protocolos (software). A frequncia utilizada por dispositivos Bluetooth opera em uma faixa de rdio no licenciada ISM (Industrial, Scientic and Medical ) entre 2.4 GHz e 2.485GHz. Para realizar uma comunicao Bluetooth, primeiro preciso saber de duas coisas importantes: preciso que haja um prestabelecimento dos dispositivos vizinhos (prximos). A comunicao baseia-se em um princpio de mestre-escravo. Quando dois ou mais dispositivos se comunicam, formam uma rede denominada piconet. Na piconet, o dispositivo que iniciou a conexo assume papel de mestre, que regula a transmisso de dados entre a rede e o sincronismo entre os dispositivos. Os demais dispositivos se tornam escravos. A piconet suporta no mximo oito dispositivos, sendo um mestre e sete escravos. A scatternet a comunicao de uma piconet com outra dentro do limite de alcance. Podemos, ento, observar que um dispositivo escravo poder fazer parte de mais de uma piconet simultaneamente; por outro lado, o mestre s poder ocupar essa posio em uma nica piconet. O dispositivo mestre possui a responsabilidade de alocar canais e estabelecer a comunicao; os dispositivos escravos no podem se comunicar diretamente uns com os outros, com exceo da fase de descoberta. Alm disso, os mestres so

38

Figura 10: Redes Bluetooth responsveis pelos ns de sondagem e de alocao ou bloqueio de uma nova conexo de largura de banda, ajuste do relgio de sincronizao da piconet. preciso que seja realizada uma identicao dos dispositivos que fazem parte da piconet. Para isso o dispositivo que deseja estabelecer uma conexo com uma piconet existente poder emitir um sinal que chamamos de Inquiry. Aps a emisso desse sinal, os dispositivos que o recebero respondem com um pacote de FHS repassando sua identicao e os dados necessrios para sincronizar com a piconet. Recebidas essas informaes os dispositivos tornam-se capazes de emitir um sinal chamado Page, mostrando que deseja estabelecer uma conexo com outro dispositivo. O Bluetooth no dependente do IP; isso permite que as implementaes de dispositivos no se preocupem com problemas de camadas superiores, tais como mscara de rede, congurao automtica, alocao de endereos.

3.2.4

Funcionamento

A rede Bluetooth transmite dados via ondas de rdio de baixa potncia, se comunica em uma frequncia entre 2,402 GHz e 2,480 GHz. Essa banda de frequncia, chamada de ISM, foi reservada por acordo internacional para o uso de dispositivos in-

39

dustriais, cientcos e mdicos. Uma srie de dispositivos utilizam essa mesma banda de frequncia de rdio. Babs eletrnicas, controles remotos de portas de garagem e a mais nova gerao de telefones sem o usam frequncias na banda ISM. Assegurar que um desses dispositivos Bluetooth no interra em outro parte fundamental do processo [17, LAYTON, 2009]. Uma das maneiras pelas quais os dispositivos Bluetooth evitam a interferncia em outros sistemas o envio de sinais fracos, de cerca de 1 miliwatt. A propsito de comparao, os celulares mais potentes podem transmitir um sinal de 100 miliwatts. A baixa potncia limita o alcance de um dispositivo Bluetooth a aproximadamente 10 metros, reduzindo a possibilidade de interferncia entre seu sistema de computador e seu telefone porttil ou televiso. Mesmo com essa baixa potncia, o Bluetooth no precisa ser apontado diretamente entre os dispositivos que se comunicam. As paredes de sua casa no detm um sinal Bluetooth, o que torna o padro til para o controle de vrios dispositivos em diferentes ambientes [17, LAYTON, 2009]. O Bluetooth pode se conectar com at oito dispositivos simultaneamente. Com todos esses dispositivos no mesmo raio de 10 metros, voc pode achar que ocorrer interferncia mtua, mas isso improvvel. O Bluetooth usa uma tcnica chamada salto de frequncia de espalhamento espectral, que praticamente impossibilita que mais de um dispositivo transmita na mesma frequncia, simultaneamente. Com essa tcnica, um dispositivo usa 79 frequncias individuais escolhidas aleatoriamente em uma faixa designada, mudando de uma para outra com regularidade. No caso do Bluetooth, os transmissores alteram as frequncias 1.600 vezes por segundo, o que signica que muitos dispositivos podem utilizar totalmente uma fatia limitada do espectro de rdio. Como todos os transmissores Bluetooth usam automaticamente a transmisso de espalhamento espectral, improvvel que dois transmissores compartilhem a mesma frequncia concomitantemente. Essa mesma tcnica reduz o risco de interferncia de telefones portteis ou babs eletrnicas nos dispositivos Bluetooth, j que qualquer interferncia em uma frequncia particular dura somente uma frao de segundo [17, LAYTON, 2009].

40

3.3
3.3.1

A Linguagem Java
Introduo

Java foi criada na Sun Microsystems, Inc. em 1991, por James Gosling, Patrick Naughton, ChrisWarth, Ed Frank e Mike Sheridan. Uma linguagem computacional completa, adequada para o desenvolvimento de aplicaes baseadas na rede Internet, redes fechadas ou ainda programas stand-alone [4, CAMPIONE, 1996]. Alm de ser uma linguagem poderosa em ambientes distribudos complexos como a rede Internet. Mas sua versatilidade permite ao programador ir alm, oferecendo uma poderosa linguagem de programao de uso geral, com recursos sucientes para a construo de uma variedade de aplicativos que podem ou no depender do uso de recursos de conectividade [45, ZUKOWSKI, 1997]. A linguagem Java obteve sucesso em cumprir os requisitos de sua especicao, mas apesar de sua ecincia no conseguiu sucesso comercial. Com a popularizao da rede Internet, os pesquisadores da Sun Microsystems perceberam que aquele seria um nicho ideal para aplicar a recm criada linguagem de programao. A partir disso, adaptaram o cdigo Java para que pudesse ser utilizado em microcomputadores conectados a rede Internet, mais especicamente no ambiente da World Wide Web. Java permitiu a criao de programas batizados applets, que trafegam e trocam dados atravs da Internet e se utilizam da interface grca de um web browser. Implementaram tambm o primeiro browser compatvel com a linguagem, o HotJava, que fazia a interface entre as aplicaes Java e o sistema operacional dos computadores [13, INDRUSIAK, 1996]. Os principais recursos da linguagem Java so as seguintes: Orientao a Objeto: baseia-se no modelo Smalltalk e Simula67; Portabilidade: pode ser executada independentemente da plataforma; Segurana: Suporta programas via rede, com restrio de execuo; Sintaxe muito semelhante as linguagens C/C++ A partir da pesquisa realizada por [36, TIOBESOFTWARE, 2011], percebemos que Java constitui uma das linguagens mais utilizadas no mercado, sendo que grande

41

parte deste sucesso, segundo [2, BAGUETE, 2009], corresponde ao princpio write once, run everywhere, focando a portabilidade da linguagem. Sendo compilada em bytecodes e interpretada na JVM, a linguagem permite a construo de programas que rodem nas mais diversas plataformas, como celulares, internet, diversos sistemas operacionais e outros, sem a necessidade (teoricamente) de se precisar fazer ajustes no cdigo.

3.3.2

Programao Orientada a Objetos (POO)

Programao Orientada a Objetos a programao implementada pelo envio de mensagens a objetos. Cada objeto ir responder s mensagens conhecidas por este, e cada objeto poder enviar mensagens a outros, para que sejam atendidas, de maneira que ao nal do programa, todas as mensagens enviadas foram respondidas, atingindo-se o objetivo do programa. Programao Orientada a Objetos, tcnicas e artefatos ditos orientados a objetos incluem linguagens, sistemas, interfaces, ambientes de desenvolvimento, bases de dados [15, LASKOSKI]. Na dcada de 60 na Noruega com a criao da linguagem Simula (Simula-67) cujo nome vem da palavra Simulao onde tinha o conceito de similaridade com o mundo real. Depois comeou a surgir outras linguagens como Simula-68 e Smalltalk criada pela Xerox sendo esta a primeira totalmente orientada a objeto e que popularizou o termo, isto em 1970. Depois desta grande evoluo foram criadas vrias outras linguagens como CC++ (da ATeT em 1980), Object Pascal (da Apple em 1986) e Java (da Sun em 1990). Hoje em dia os conceitos Orientao a Objeto tambm utilizado em Sistemas Operacionais, Banco de Dados, entre outros. A POO empregas os seguintes conceitos bsicos objeto, abstrao, encapsulamento, classe, herana e polimorsmo [31, RIGHETTI, 2003]. A unidade principal da programao orientada a objetos a Classe. Uma classe uma representao de um objeto ou idia real em forma de cdigo, separando as caractersticas operacionais dos detalhes concretos de sua implementao. Simplicando, denimos uma Classe para representar algo como um relgio. Para o usurio, no importante como o relgio funciona, tanto na vida real como na programao: importante apenas que o usurio possa interagir com o relgio, seja olhando as horas, seja ajustando o alarme ou congurando o horrio correto. As engrenagens ou funes que fazem o relgio funcionar cam escondidas do usurio: isso que queremos dizer com separar as caractersticas operacionais dos detalhes da imple-

42

mentao [37, TREVELIN, 2007].

3.3.3

A Mquina Virtual

O conceito de mquina virtual no novo - suas origens remetem ao incio da histria dos computadores, no nal dos anos de 1950 e incio de 1960. As mquinas virtuais foram originalmente desenvolvidas para centralizar os sistemas de computador utilizados no ambiente VM/370 da IBM. Naquele sistema, cada mquina virtual simula uma rplica fsica da mquina real e os usurios tm a iluso de que o sistema est disponvel para seu uso exclusivo [16, LAUREANO, 2006]. A utilizao de mquinas virtuais est se tornando uma alternativa para vrios sistemas de computao, pelas vantagens em custos e portabilidade, inclusive em sistemas de segurana [16, LAUREANO, 2006]. A JVM (Mquina Virtual Java) parte do ambiente de runtime Java e a responsvel pela interpretao dos bytecodes (programa compilado em java), ou seja, a execuo do cdigo. A JVM consiste em um conjunto de instrues, conjunto de registradores, a pilha (stack ), garbage-collected heap e a rea de memria (armazenamento de mtodos) [33, SCRIBD, 2010]. A Figura 11 mostra o ambiente de execuo Java, que fornece a nica verso para sua aplicao em diferentes plataformas. A classe a unidade de cdigo fundamental de um cdigo Java. Como em outras linguagens orientadas a objeto, elas so os componentes de aplicao que possuem o cdigo executvel e os dados. As classes podem ser mantidas separadamente e armazenadas em arquivos no sistema local ou em um servidor de rede.

43

Figura 11: O Ambiente de Tempo de Execuo Java

44

ARQUITETURA DO PROTTIPO

O prottipo foi desenvolvido de forma que tornasse possvel a reutilizao de trechos do cdigo fonte, pensando nisso, dividimos o projeto em quatro camadas, sendo que cada camada somente se comunica com suas camadas adjacentes por meio de troca de mensagens, sendo assim, em cada camada existe uma la de mensagens a serem processadas. Quando uma camada necessita-se comunicar com outra, a mesma deve postar uma mensagem na la de mensagens da camada de destino. Assim a camada de destino processar suas mensagens na ordem de entrada da la. Deixando as camadas completamente desacopladas, possibilitando sua substituio sem que haja um grande retrabalho.

4.1

Diviso de Camadas

Com a denio da arquitetura fsica e tecnologias a serem utilizadas, foi dena uma arquitetura prpria e protocolos de comunicao, tendo como referncia a pilha de protocolos TCP/IP, o projeto foi dividido em quatro camadas:

45

Figura 12: Comparativo de Camadas entre as Pilhas de Protocolos a) Aplicao Camada de interface com a aplicao requerente para utilizao da pilha de protocolos. b) Empacotamento Camada responsvel pelo tratamento de possveis desconexes durante a transmisso da informao at o destinatrio. c) Roteamento Camada que permite efetuar um roteamento entre nodos para que a informao seja repassada ao destinatrio. d) Fsica Camada responsvel por efetuar conexes entre nodos para recebimento e envio entre eles. Maiores detalhes sero explorados no captulo 4.2. Foi tambm necessria a criao de estruturas de dados para controle e encapsulamento das camadas entre si.

4.2
4.2.1

Camadas da Arquitetura Proposta

Aplicao

Conforme descrito na seo 4.1, item a, essa camada tem como principal nalidade a interface com a aplicao requerente. Dessa forma, ca responsvel pelo recebimento da informao enviada pela aplicao requerente a ser transmitida.

46

Essa camada prov alguns servios de interface, a saber: a) Lista de todos os possveis destinatrios

Retorna com sua chamada pela aplicao uma lista que contm todos dispositivos disponveis como possveis destinatrios de acordo com a estrutura a seguir. Chamada da interface: public ArrayList<Destinatario> listaDestinatarios(); Com a chamada a esse servio temos com retorno uma ArrayList de destinatrios. Quando retornar nulo, no h destinatrios.

Figura 13: Estrutura da Classe Destinatrio b) Transmisso da Informao Concedida pela Aplicao

Principal nalidade de servio postar informaes concedidas pela aplicao. Para recebimento vindo da aplicao requerente, necessrio o envio da informao com o endereo MAC de destino de acordo com declarao a seguir. Chamada da interface: public boolean envio(String MACDestino, Object informacao); Com a chamada a interface, retornar um valor booleando onde o valor true (verdadeiro) referente ao sucesso, ao postar a mensagem para envio. Quando o retorno for false (falso), isso signica que no obteve sucesso, ao postar a mensagem por motivos de no encontrar o MAC de destino em sua lista de possveis

47

destinatrios ou problemas, ao salvar no dispositivo de armazenamento, como por exemplo, se estivese cheio. c) Retorno de um Cdigo nico da Informao Postada

Ao postar uma informao gerado um cdigo nico para ela, que a combinao do endereo fsico do dispositivo e a data/hora do momento que foi postado. Chamada da interface: public String codigoInformacao(); Chamando a interface, retornar um cdigo nico da informao postada. Somente retornar o cdigo da ltima informao postada, retornando nulo quando a tentativa de postagem no foi sucedida. d) Estado dos Pacotes Postados pela Aplicao

Com o cdigo nico, possvel obter informaes posteriores sobre o objeto postado. Chamada da interface: public int estadoInformacao( String codigoUnico ); Retornar um inteiro informando qual estado que se encontra o objeto postado podendo ser Inexistente, Postado, Encaminhado ou Entregue. Detalharemos mais abaixo o signicado de cada estado. e) Recebimento de Informao pela Aplicao

Servio responsvel por retornar para aplicao o recebimento de uma informao transmitida para aquele nodo. Chamada da interface: public Object recebimento(); Com a chamada ao servio, retornar o primeiro objeto da lista de informaes recebidas pelo dispositivo que sejam realmente para aquela aplicao. Desse modo, ser possvel recuperar um objeto por vez at que a lista para aquela aplicao que vazia, tornando o retorno da chamada nulo.

48

4.2.2

Empacotamento

Recebendo um objeto da camada de aplicao, o empacotamento se responsabiliza por entregar ao destino, mesmo se a conectividade for nula em determinados momentos, tratando possveis desconexes desde transmisso do objeto at o destinatrio, armazenando todos os pacotes que ainda no chegaram em seu destino, quando alcanado e repassado a conrmao de recebimento, so descartados. Utiliza o dispositivo de armazenamento para guardar os objetos a serem enviados ou recebidos, at que a aplicao resgate-os, ou objetos recebidos para retransmisso sejam enviados a outro destinatrio, fazendo dessa forma, roteamento da informao. Para uso do dispositivo de armazenamento, podem ser adotadas algumas polticas de armazenamento, como limite na quantidade de objetos armazenados ou limite em bytes a serem usados para armazenamento. Nessa camada, ao receber um objeto da camada de aplicao, ocorre o encapsulamento dele, adicionado um cabealho da prpria camada para controle, como podemos ver na estrutura a seguir:

49

Figura 14: Estrutura do Pacote DTN

50

Na estrutura de controle de empacotamento, temos atributos como o info, que o objeto encapsulado da aplicao, seguido de outros atributos de controle: MACOrigem Guarda o endereo do dispositivo de origem do objeto recebido. MACDestino Guarda o endereo do dispositivo de destino do objeto recebido. historico Guarda um histrico de nodos pelos quais o pacote passou. Ao nal da transmisso, possvel saber qual foi o trajeto tomado pelo objeto. dataCriacao Guarda a data de criao da estrutura de empacotamento. dataLimite Guarda a data limite de vida do objeto, normalmente utilizado para informaes repassadas via broadcast. estado Guarda o estado atual do objeto. Esse estado ser citado mais adiante no item 4.2.2: Estados do pacote. contadorFinal Guarda a quantidade de nodos atingidos pelo objeto. Utilizado para tentar obter uma estimativa quantitativa de dispositivos que receberam o objeto. a) Funcionamento da Camada de Empacotamento

1) Inicializao

Ao ser inicializado, uma das primeiras atividades efetuadas o carregamento de todos os objetos guardados no dispositivo de armazenamento para a memria. Nesse procedimento, so eliminados todos os objetos que estiverem com data limite (tempo de vida) ultrapassados. Com todos os objetos em memria, verica-se quais pacotes esto es-

51

perando que sejam enviados para cada pacote em espera. repassado apenas o endereo de destino do objeto para a camada de roteamento. Mais adiante, na seo 4.2.3: Roteamento, falaremos como tratar esse aviso. Somente repassar o objeto a ser enviado para camada de roteamento, quando ela receber um aviso informando que o dispositivo est conectado. 2) Envio de Objetos

Quando a camada de empacotamento receber da camada de aplicao um objeto, primeiramente vai montar o seu cabealho e encapsular o objeto original. Aps esse procedimento, repassado apenas o endereo de destino do objeto para a camada de roteamento. Caso a camada de roteamento retorne avisando que o destino se encontra desconectado, efetuado o armazenamento no dispositivo (caso esteja dentro das polticas de armazenagem) em arquivo privado com nome nico. Esse nome composto pelo endereo fsico do dispositivo e data/hora de criao. 3) Recebimento de Objetos

Ao receber um objeto da camada de roteamento, efetuado o procedimento de gravao no dispositivo de armazenamento. Objetos recebidos que no tenham como destinatrios o dispositivo atual sero armazenados apenas para efetuarem uma futura retransmisso. Somente objetos que sejam do dispositivo passaro para camada de aplicao para que sejam entregues ao aplicativo. Neste momento tambm adicionado o prprio dispositivo no cabealho de histrico. b) Estados do Pacote

Com a chamada efetuada pela interface na camada de Aplicao, esta chama o servio da camada de empacotamento. O atributo estado do pacote de grande importncia. Dependendo de qual aplicativo trabalhar com o protocolo, ser o controle de onde o Objeto estiver. Seguem alguns dos possveis estados apresentados pelo Objeto.

52

Inexistente

Quando feita uma pesquisa sobre o estado de um objeto pelo qual j esteja com tempo de vida ultrapassado, ou quando no exite o pacote armazenado naquele dispositivo. Postado

Fazendo uma analogia com o servio dos correios, seria o ato de postar um objeto ou encomenda em uma das agncias dos correios, que esperaria pelo encaminhamento at o destinatrio. Nesse caso, seria o aplicativo postando um objeto que inicialmente taxado como postado, aguardando um nodo para transmitir e repass-lo adiante. Encaminhado

Novamente de acordo com a analogia do servio dos correios, que indica que o objeto est em trnsito at que seja entregue ao destinatrio. Ocorre a troca de estado de postado para encaminhado quando o dispositivo de origem conseguir repassar o objeto para outro nodo. Caso o outro nodo seja o destinatrio no ter estado de encaminhado, mas, sim, entregue. Recebido

Estado mostrando que o objeto foi entregue ao dispositivo. Entregue

Estado nal que mostra que o objeto foi entregue ao destinatrio. Chamada da interface: public int estadoInformacao( String codigoUnico ); Retornar um inteiro informando em qual estado se encontra o objeto postado de acordo com a estrutura Estado:

53

Figura 15: Estrutura de Estados do Pacote DTN

4.2.3

Roteamento

Camada responsvel por calcular para qual dispositivo a mensagem encaminhado dever ser transmitido, efetuando assim o roteamento da mensagem at que possivelmente chegue ao seu destinatrio com base uma lista de possveis destinos, sendo um destino virtual o destino a qual no possvel passar diretamente uma mensagem a ele, e um destino real todos destinos que so possveis efetuar conexes. Trabalhando com uma lista de dispositivos que j foram previamente pareados, onde possvel a transmisso de dados sem que necessite de aceitao do dispositivo de destino. E nessa mesma lista possvel acrescentar novos dispositivos que no foram pareados, mas que so possveis destinatrios. Esses dispositivos que no foram pareados no sero possveis transmisso de dados para tais, assim s estaro nessa lista aqueles dispositivos que tenham como pai um dispositivo j pareado da lista. Cada dispositivo tem sua lista de aparelhos pareados (amigos), formando sua lista de relacionamentos. Quando ocorrer uma conexo entre dois nodos, primeiramente sero transferidas suas listas de relacionamentos que devero ser atualizadas em cada dispositivo. Essa uma estratgia de roteamento dinmica, pois a cada nova conexo, sua tabela de possveis destinatrios aumenta, formando um roteamento dinmico baseado em histricos de relacionamentos por meio de encontros entre dispositivos, o que no foi encontrado na literatura. No exemplo abaixo, mostra como feita a base para o roteamento entre nodos. Temos trs dispositivos A, B e C, com as respectivas tabelas de relacionamentos de acordo com a Figura 16.

54

Figura 16: Representao da Tabela de Relacionamentos A tabela de relacionamento composta por dois campos: o primeiro campo o endereo fsico (MAC) do destinatrio e o outro, um indicador do nodo pai daquele destinatrio. E sendo nulo mostra que o prprio dispositivo pode efetuar conexes sem que necessite de aceitao de ambos. Conforme visualizado na Figura 16, o dispositivo A tem, em sua tabela, o dispositivo B, com nodo pai nulo. O dispositivo B tem, em sua tabela, o dispositivo A, com nodo pai nulo. E, por m, o dispositivo C tem, em sua tabela, um quarto dispositivo, o D, tambm sendo o prprio dispositivo o nodo pai. Em um determinado momento, o nodo B encontra-se com C, que, ao parearem, acabam transferindo suas respectivas tabelas de relacionamentos, sincronizando-as, dessa forma, um ter conhecimento do relacionamento do outro. Melhor visualiza-se na Figura 17.

Figura 17: Incluso de novos relacionamentos adquiridos na conexo de B e C De acordo com a gura 17, o nodo B passa a conhecer o nodo C, que se torna um novo nodo da rede. J o dispositivo D foi adicionado tabela de B apontando

55

para C, desta forma o destino D torna-se um destinatrio virtual de B, pois para que seja possvel enviar mensagens a D, ser necessrio encaminh-los primeiramente a C que considerado um destinatrio real, que car encarregado de repass-los ao nodo de destino.

Figura 18: Incluso de novos relacionamentos adquiridos na conexo de A e B Quando B voltar a se conectar com A, ocorrer o sincronismo entre suas tabelas. E nesse momento A passar a conhecer todos os outros dispositivos conhecidos de B. Para efetuar o envio de um objeto, sendo A o remetente e D o destinatrio, apenas ser preciso efetuar uma busca em sua lista pelo destinatrio D e vericar quem seria o nodo pai do destinatrio. Caso seja nulo, o prprio nodo enviar diretamente para o destinatrio quando ocorrer uma conexo entre eles.

4.2.4

Fsica

Como foi proposto trabalhar com a tecnologia Bluetooth, como meio de transmisso de dados entre dispositivos, tivemos que criar uma camada somente para controle de conexes, envios e recebimentos de dados. Com o desenvolvimento dessa camada, foram encontradas diversas limitaes referentes ao manuseio da tecnologia. Para efetuar a primeira conexo entre dois dispositivos Bluetooth preciso que um dos dispositivos permanea em modo visvel, dessa forma tornar-se possvel que o outro encontre-o em uma busca por novos dispositivos. O sistema operacional Android, permite deixar o dispositivo em modo visvel por um intervalo de tempo de no mximo 300 segundos por questes de consumo de bateria. Por segurana do Bluetooth necessita de uma autorizao para conexo (o empareamento) do outro ao tentar conectar-se pela primeira vez. Tornando limitaes de bateria e de implementao de um algoritmo automatizado para conexes em novos nodos.

56

De acordo com as limitaes encontradas, foi desenvolvida uma topologia de rede onde so possveis apenas duas conexes por dispositivo: uma conexo cliente e outra conexo servidora, em que ao ter pacotes enviar efetuada uma tentativa de conexo do tipo cliente ao destino real do pacote.

Figura 19: Diagrama de Estados da Camada Bluetooth

57

Figura 20: Representao de Envio de Informao com Custdia

4.3
4.3.1

Modelo de Comunicao entre Nodos

Envio com Custdia

Todo objeto que for congurado como envio com custdia, quando for repassado para um nodo, mesmo que este no seja o nodo nal, repassado tambm responsabilidade de entreg-lo ao destinatrio. De acordo com a imagem acima, o nodo A envia uma informao ao nodo B, que efetua a conrmao de recebimento. A partir desse momento, o nodo A elimina o pacote de seu armazenamento, pois passou a responsabilidade de entrega ao nodo B, que ao encontrar com C, repassa a informao.

4.3.2

Envio sem Custdia

Para todo objeto congurado como envio sem custdia, o remetente enviar a informao e car aguardando a conrmao de recebimento pelo destinatrio nal. Conforme ilustrado na imagem acima, quando o nodo A repassa a informao ao nodo B, este conrma ao nodo A o recebimento, assim o nodo A aguardar a conrmao de recebimento por C, seu destino nal. Quando B efetuar o envio do pacote para C, ele retornar a conrmao de sucesso e B car encarregado de enviar a conrmao de recebimento por C ao nodo A.

58

Figura 21: Representao de Envio de Informao sem Custdia

4.4

Diagrama de classes

O diagrama de classes uma metodologia utilizada para descrever os tipos de objetos do sistema e os vrios tipos de relacionamentos estticos existentes entre eles, bem como atributos e operaes de uma classe e suas restries. [3, BARRETO, 2001].

4.4.1

Diagrama de Pacotes da Arquitetura do Projeto

A Figura 22 ilustra o diagrama de pacotes da arquitetura do projeto que contm as camadas de Aplicao, Empacotamento, Roteamento e Fsica.

59

Figura 22: Diagrama de Pacote da Arquitetura do Projeto

4.4.2

Diagrama de Classe da Camada de Aplicao

A Figura 23 ilustra as classes que pertencem camada de aplicao: Classe Mensagem: classe utilizada na camada de aplicao para encapsulamento da informao recebida da aplicao. Classe Aplicao: classe responsvel pelo gerenciamento e procedimentos da camada de aplicao.

4.4.3

Diagrama de Classe da Camada de Empacotamento

A Figura 24 ilustra as classes que pertencem camada de empacotamento:

60

Figura 23: Diagrama de Classe da Camada de Aplicao Classe Empacotamento: classe responsvel por todo gerenciamento e procedimentos da camada de empacotamento, como controle de pacotes enviados, recebidos e at mesmo os armazenados. Classe PacoteDTN: classe utilizada na camada de empacotamento para encapsulamento dos objetos recebidos da camada de aplicao.

4.4.4

Diagrama de Classe da Camada de Roteamento

A Figura 25 ilustra as classes que pertencem camada de roteamento:

61

Figura 24: Diagrama de Classe da Camada de Empacotamento Classe Destinatarios: lista que contm todos os possveis destinatrios, at aqueles que no foram pareados. Classe Roteamento: classe responsvel pela resoluo dos destinatrios. Classe PacoteRede: classe utilizada pela camada de roteamento efetuando o encapsulamento dos objetos recebidos da camada de empacotamento. Classe Requerido: lista que contm todos os destinatrios requeridos pela camada superior com as respectivas tradues de endereo.

4.4.5

Diagrama de Classe da Camada Fsica

A Figura 26 ilustra as classes que pertencem camada fsica:

62

Figura 25: Diagrama de Classe da Camada de Roteamento Classe BluetoothClienteThread: uxo responsvel por efetuar conexes cliente. Classe BluetoothConexaoThread: quando conectado a um dispositivo criado esse uxo somente para gerenciamento desta conexo. Classe BluetoothServidorThread: uxo responsvel por administrar o servidor mantendo-o ativo. Classe Fisica: classe responsvel pelo gerenciamento dos uxos servidor e cliente e de possveis uxos de conexes.

63

Figura 26: Diagrama de Classe da Camada Fsica

64

TESTES

Neste captulo, so apresentados os resultados dos testes relacionados utilizao do protocolo proposto. Os testes foram realizados em diversos casos e dois casos apresentaram-se mais relevantes, a saber: caso 1: O aplicativo encontra-se aberto com apenas o servidor ativo sem envio e recebimento de mensagens. caso 2: O aplicativo encontra-se aberto com o servidor ativo e possui pacotes a enviar. Sendo assim, sero realizadas tentativas at o pacote ser repassado. Os testes foram realizados em dois tipos de smartphones: Samsung Galaxy S I9000B: Processador de 1GHz com memria RAM de 512MB e sistema operacional Android verso 2.3.3. HTC Nexus One: Processador de 1GHz com memria RAM de 512MB e sistema operacional Android verso 2.3.4.

5.1

Teste de Consumo de Bateria

Foram realizados testes para constatar o consumo de bateria referente somente ao prottipo proposto.

5.1.1

Consumo de Bateria pelo Bluetooth

Para que seja possvel a utilizao do aplicativo, o Bluetooth do dispositivo deve estar ativo. Dessa forma, mantendo apenas Bluetooth ativo (tendo em vista que o prottipo proposto esteja fechado), sem efetuar buscas nem deix-lo visvel, o consumo por manter o Bluetooth apenas ativo torna-se praticamente nulo.

65

Nos testes de bateria referente ao caso 1, constatamos que o consumo foi relativamente baixo, pois observamos um aumento em torno de 1% de toda bateria consumida durante o perodo de duas horas. Com testes referentes ao caso 2, preciso requerer conexes com o destinatrio. Baseando-se no pior caso, quando tero que efetuar diversas tentativas de conexo sem sucesso. Cada tentativa tem intervalo de dois minutos, realizados durante duas horas, em que percebe-se um aumento mdio em torno de 4% de toda bateria consumida durante o perodo de testes.

5.2

Teste de Consumo de Memria

Foram realizados testes para ns de controle do consumo de memria referente apenas ao prottipo proposto.

5.2.1

Consumo de Memria

Nos testes de memria foram observados os dois casos por perodos de duas horas cada, em que a memria utilizada pela aplicao obteve uma pequena variao de no mnimo de 4,56 MegaBytes e no mximo de 4,77 MegaBytes para o caso 1. J para o caso 2, a variao foi no mnimo de 4,51 MegaBytes e no mximo de 4,78 MegaBytes.

5.3

Teste de Tempo de Conexo

Ao trabalhar com a tecnologia Bluetooth, surgiram algumas limitaes. Uma dessas limitaes seria o tempo de espera necessrio para o retorno de uma tentativa de conexo. Quando essa tentativa bem sucedida, gasto no mximo um segundo para efetuar a conexo; j quando ocorrem problemas, ao tentar, por exemplo, conectar, e o destinatrio no se encontra no local, so gastos de seis a dez segundos.

66

5.4

Teste de Processamento de Pacotes

Conforme a arquitetura elaborada, em que o prottipo do protocolo foi dividido em quatro camadas, umas se comunicando com as outras por meio de las, houve um comprometimento do desempenho no processamento de pacotes. Assim, conforme os testes, foi possvel em mdia o processamento de sete pacotes por segundo, num total de 420 pacotes por minuto.

5.5

Tamanho em Bytes de cada Cabealho

A camada de aplicao encapsula o objeto recebido em um objeto do tipo Mensagem que de cabealho tem 210 bytes. Em seguida, ele mesmo encapsulado pela camada de empacotamento compondo o objeto PacoteDTN, que tem como cabealho 500 bytes de informaes; por m, encapsulado pela camada de rede em um objeto PacoteRede, que tem como cabealho 112 bytes de informaes, com um total de 822 bytes de cabealhos.

67

CONCLUSO

Inicialmente, o projeto proposto seria uma aplicao para dispositivos mveis, que teriam, como principais funcionalidades, a localizao de nodos ao entorno de si mesmos, com limitao de raio de alcance de acordo com a tecnologia de comunicao sem o utilizada, para que fosse possvel efetuar conexes entre dispositivos e que posteriormente fosse possvel a troca de informaes, com possibilidade de armazenamento de informaes para retransmisso. Visto o problema para a criao do dispositivo fsico, para tal projeto optamos pela utilizao de smartphone com sistema operacional Android, que possibilita criao de aplicativos para execuo sobre o sistema operacional, viabilizando recursos como armazenamento e a utilizao de tecnologias por Bluetooth como meio de transmisso sem o. Este Trabalho de Concluso de Curso teve como objetivo entender melhor o funcionamento das redes DTN e desenvolver um prottipo de rede para a comunicao tolerante a atrasos e com longos perodos de desconexes entre dispositivos mveis Android. O prottipo proposto utiliza a comunicao via Bluetooth e dividido em quatro camadas: Fsica, Roteamento, Empacotamento e Aplicao. Essas camadas so totalmente independentes entre si, completamente desacopladas, que se comunicam por meio de las de mensagens, dessa forma possibilitando sua substituio de qualquer camada, sem que haja um grande retrabalho. As camadas do prottipo proposto foram desenvolvidas para obter a melhor independncia possvel entre elas, mantendo um baixo acoplamento, com a utilizao de algumas tcnicas de programao, por exemplo, a utilizao de las de mensagens para comunicao entre camadas. Com isso, ser possvel, substituir ou inserir novas camadas ao prottipo, sem que haja grandes alteraes. Para o desenvolvimento desse prottipo, foi necessrio analisar o cenrio estocstico, onde esto inseridos os nodos da rede, sendo preciso implementar um protocolo

68

de roteamento baseado em histrico de encontros, para que haja um menor atraso na entrega das mensagens. Com base na criao desse prottipo de rede, desenvolvemos algumas aplicaes simples, como entrega de mensagens para testar sua ecincia, roteamento, consumo de bateria, memria e processamento nos dispositivos mveis. Todos os testes realizados foram satisfatrios, mostrando-se como uma soluo a utilizao de dispositivos mveis como mula de dados para redes DTN. Dessa forma, aplicaes que utilizam ou no outros tipos de dispositivos mveis como mula de dados, podero, com o aperfeioamento desse prottipo. transform-lo em uma soluo comercial, utilizando dispositivos Android como infraestrutura ad hoc para a troca de mensagens DTN.

6.1

Trabalhos Futuros

Ao longo do desenvolvimento deste prottipo, foram propostas diversas melhorias sobre sua arquitetura, como a substituio da linguagem de programao Java pela linguagem C, pois ganharamos um grande aumento no desempenho em relao ao processamento de grandes quantidades de pacotes. Em vez de utilizarmos objetos como mensagens de encapsulamento entre camadas, usados para adicionar o cabealho, para ganho de desempenho e reduo no tamanho em bytes dos cabealhos, interessante a programao em bits criando vetor de bytes (trem de bits). Pensando em futuras melhorias, notou-se que programao de alto desempenho como grande aliada para que tenhamos a possibilidade de transformar o prottipo em um servio do prprio sistema operacional Android. Com isso, qualquer aplicativo que esteja sobre o Android poder utilizar os recursos do protocolo tolerante a falhas e desconexes, de modo que possibilite a criao de diversas aplicaes. Uma das principais melhorias propostas, seria o desenvolvimento do protocolo no prprio Kernel NDK do sistema operacional Android, recompilando o ncleo para ganhos de desempenho e a agregao do protocolo no sistema operacional Android. Outra modicao interessante seria aumentar a inteligncia do protocolo de roteamento, utilizando, por exemplo, o protocolo de roteamento PROPHET proposto por [18, LINDGREN, 2004], que, alm de se basear em histricos de encontros, tambm

69

leva em considerao a probabilidade de um nodo encontrar o nodo de destino no momento em que uma mensagem for roteada pela rede. Isso vai diminuir o tempo de atraso na entrega das mensagens aos destinos nais.

70

REFERNCIAS
[1] ANDROIDPT. Sdk. URL: http://www.androidpt.info/index.php?title=SDK, 2010. ltima Visita: 13/11/2011. [2] Baguete. Escolhendo a linguagem: Java vs php. URL: http://www.baguete.com.br/colunistas/colunas/51/paulokrieser/14/05/2009/escolhendo-a-linguagem-java-vs-php, 2009. ltima Visita: 15/11/2011. [3] Jaderson Satler Barreto. Diagrama de Classes : Os Elementos Bsicos / Barreto, Jaderson Satler, Oliveira, William Ribeiro de e Lacerda, Ranieri Miranda de. Centro Universitrio do Sul de Minas (UNIS), 2001. [4] M Campione. The Java Tutorial: Object-Oriented Programming for the Internet / Campione, M e Walrath, K. SunSoft Press, 1996. [5] V. Cerf. Delay-tolerant networking architecture / Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R.; Scott, K., Fall, K. e Weiss, H. Technical report, Internet RFC 4838, 2007. [6] L-J. Chen. A Hybrid Routing Approach for Opportunistic Networks / Chen, L-J., Yu, C-H., Sun, T., Chen, Y-C., Chu H-H. ACM Special Interest Group on Data Communication, 2006. [7] G. L. Coutinho. Delay Tolerant Networks (DTN). Universidade Federal do Rio de Janeiro (UFRJ), 2006. [8] ELETRONICA.ORG. Bluetooth. URL: http://www2.eletronica.org/artigos/eletronicadigital/bluetooth, 2008. ltima Visita: 15/11/2011. [9] K. Fall. A delay-tolerant network architecture for challenged internets. ACM SIGCOMM, 2003. [10] K. Fall. Messaging in difcult environments. Technical Report IRBTR-04-019, Intel Research Berkeley, 2004. [11] K. Fall. Disruption tolerant networking for heterogeneous ad-hoc networks. IEEE Military Communications Conference (MILCOM), 2005. [12] Faria, Alessandro de Oliveira. Android ndk - desmisticando o acesso a cdigos nativos em c. URL: http://migre.me/69nD6, 2011. ltima Visita: 13/11/2011. [13] Leandro Soares Indrusiak. Linguagem Java. Grupo JavaRS JUG Rio Grande do Sul, 1996.

71

[14] S. Jain. Routing in a delay tolerant network / Jain, S., Fall, K. e Patra, R. Special Interest Group On Data Communication (SIGCOMM), 2004. [15] Jackson Laskoski. Programao Orientada a Objetos. JACK.eti.br. [16] Marcos Laureano. Mquinas Virtuais e Emuladores : Conceitos, Tcnicas e Aplicaes. Novatec Editora, 2006. [17] Curt Layton, Julia. Franklin. Como funciona o bluetooth. http://informatica.hsw.uol.com.br/bluetooth1.htm, 2009. ltima 09/11/2011. URL: Visita:

[18] A. Lindgren. Probabilistic routing in intermittently connected networks / Lindgren, A., Doria, A. e Scheln, O. International Workshop on Service Assurance with Partial and Intermittent Resources (SAPIR), 2004. [19] S. Macker, J. e Ratliff. Mobile ad-hoc networks (manet). URL: http://datatracker.ietf.org/wg/manet/charter/, 2009. ltima Visita: 15/11/2011. [20] Marcus V. B. Medeiros. Emprego de Redes Tolerantes a Atrasos e Desconexes em Sistemas de Comunicaes Militares / Medeiros, Marcus V. B. e Salles, R. M. Instituto Militar De Engenharia (IME), 2009. [21] MOBILEPEDIA. Android lidera mercado mundial de smartphones com 43 por cento. URL: http://www.mobilepedia.com.br/noticias/android-lidera-com-43-domercado-mundial-de-smartphones, 2011. ltima Visita: 05/11/2011. [22] V. F. S. Mota. Introduzindo Tolerncia a Interrupo em Redes Ad Hoc Mveis para Cenrios de Emergncia / Mota, V. F. S., Silva, T. H. e Nogueira, J. M. S. Simpsio Brasileiro de Redes de Computadores, 2009. [23] N4C. Rede para Comunicao em Comunidades Remotas - N4C. N4C Newsletter, 2008. [24] Carina T. de. Oliveira. Redes Tolerantes a Atrasos e Desconexes / Oliveira, C. T., Moreira, M. D. D., Rubinstein, M. G., Costa, L. H. M. K. e Duarte, O. C. M. B. Minicursos do Simpsio Brasileiro de Redes de Computadores, 2007. [25] Carina T. de. Oliveira. Redes Tolerantes a Atrasos e Desconexes / Oliveira, Carina T. de., Moreira, Marcelo D. D., Rubinstein Marcelo G., Costa, Henrique M. K. e Duarte Otto Carlos M. B. Universidade Federal do Rio de Janeiro (UFRJ), 2008. [26] Carina T. de. Oliveira. Uma Proposta de Roteamento Probabilstico para Redes Tolerantes a Atrasos e Desconexes. Universidade Federal do Rio de Janeiro (UFRJ), 2008. [27] Thiago Rodrigues de Oliveira. Um Modelo de Gerenciamento de Segurana Adaptativo Para Redes de Emergncia. Universidade Federal de Minas Gerais (UFMG), 2010. [28] J. Ott. Integrating DTN and MANET Routing / Ott, J., Kutscher D. e Dwertmann C. slides from ACM CHANTS workshop, 2006.

72

[29] Michael Loureno da. Pereira, Lcio Camilo Olive e Silva. Android para desenvolvedores. Brasport, 2009. [30] J. Postel. Transmission control protocol. RFC 793, Information Sciences Institute, 1981. [31] Fabiano Reese Righetti. Programao Orientada a Objetos : Engenharia de Software II. 2003. [32] James F. Ross, Keith W. e Kurose. Redes de Computadores e a Internet: Uma Abordagem Top Down. Addison-Wesley, 2006. [33] SCRIBD. Programao orientada a objetos : Linguagem de programao java. URL: http://pt.scribd.com/doc/36451849/4/Java-Virtual-Machine, 2010. ltima Visita: 15/11/2011. [34] R. Shah. Data MULEs: Modeling a three-tier architecture for sparse sensor networks / Shah, R., Roy, S., Jain, S. e Brunette, W. IEEE International Workshop On Sensor Network Protocols And Applications (SNPA), 2003. [35] Adriano Tabarelli. Redes Tolerantes a Atrasos, Protocolos de Disseminao e Aplicaes / Tabarelli, Adriano e Silva, Caio Cestari. Trabalho de Formatura Supervisionado - MAC0499, 2009. [36] TIOBESOFTWARE. Tiobe programming community index for november 2011. URL: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html, 2011. ltima Visita: 15/11/2011. [37] Enrique Camargo Trevelin. Mdulo 11 : Programao orientada objetos. URL: http://migreme.net/1gao, 2007. ltima Visita: 15/11/2011. [38] A. Vahdat. Epidemic routing for partially-connected ad hoc networks / Vahdat, A. e Beckee, D. Durham NC, 2000. [39] VIVASEMFIO. Fhss frequency hopping spread spectrum saltos. URL: http://www.vivasemo.com/blog/fhss-frequency-hopping-spread-spectrum-saltos, 2007. ltima Visita: 09/11/2011. [40] Y. Wang. Erasure-coding based routing for opportunistic networks / Wang, Y., Jain, S., Martonosi, M. e Fall, K. ACM SIGCOMMWorkshop on Delay-tolerant Networking (WDTN), 2005. [41] F. Warthman. Delay-Tolerant Networks (DTNs): A Tutorial v1.1. Warthman Associates, 2003. [42] WIKIPDIA. Transmission control protocol. URL: http://pt.wikipedia.org/wiki/Transmission_Control_Protocol, 2004. ltima Visita: 14/11/2011. [43] WIKIPDIA. Bluetooth. URL: http://pt.wikipedia.org/wiki/Bluetooth, 2006. ltima Visita: 09/11/2011.

73

[44] Xavier, Andressa. O gigante google lana o kit de desenvolvimento para a plataforma android, sistema operacional para celulares. URL: http://www.baixaki.com.br/download/android-sdk.htm, 2011. ltima Visita: 13/11/2011. [45] J. Zukowski. Java AWT Reference. OReilly e Associates, 1997.