Comunicações e redes entre drones aquáticos

(1)

Universidade de Aveiro Departamento deElectrónica, Telecomunica¸cões e Informática, 2017

(2)

(3)

Universidade de Aveiro Departamento deElectrónica, Telecomunica¸cões e Informática, 2017

Deolinda Rosa Moura

Comunica¸

c˜

oes e Redes entre Drones Aqu´

aticos

Disserta¸cão apresentada à Universidade de Aveiro para cumprimento dos requisitos necessários à obten¸cão do grau de Mestre em Engenharia Eletr´ o-nica e Telecomuo-nica¸cões, realizada sob a orienta¸cão cient´ıfica da Professora Doutora Susana Sargento, Professora Associada com Agrega¸cão do Depar-tamento de Eletrónica, Telecomunica¸cões e Informática da Universidade de Aveiro e co-orienta¸cão cient´ıfica do Doutor Lucas Guardalben, Investigador do Instituto de Telecomunica¸cões de Aveiro.

(4)

(5)

o j´uri / the jury

presidente / president Professor Doutor Andr´e Ventura da Cruz Marnoto Z´uquete

Professor Auxiliar, Departamento de Electrónica, Telecomunica¸cões e Informática da Universidade de Aveiro

vogais / examiners committee Professora Doutora Ana Cristina Costa Aguiar

Professora Auxiliar, Departamento de Engenharia Electrot´ecnica e de Computado-res da Faculdade de Engenharia da Universidade do Porto (Arguente)

Professora Doutora Susana Isabel Barreto de Miranda Sargento Professora Associada com Agrega¸cão, Departamento de Electrónica, Telecomuni-ca¸cões e Informática da Universidade de Aveiro (Orientadora)

(6)

(7)

agradecimentos A entrega desta disserta¸cão simboliza mais uma meta cumprida na minha vida, e é com enorme satisfa¸cão que aqui deixo agradecimentos a todos os que, directa ou indirectamente, contribu´ıram para a realiza¸cão deste traba-lho e me apoiaram ao longo do meu percurso académico.

Em primeiro lugar, quero agradecer aos meus Avós e Irmã por todo o apoio, motiva¸cão e paciência que tiveram comigo ao longo destes últimos anos nada fáceis, cheios de altos e baixos. Sem vocês eu não teria chegado até aqui, não seria o que sou hoje e todo este percurso não teria passado de uma mera utopia. Um Grande Obrigada! Quero agradecer também aos meus Primos e Tios que sempre acreditaram em mim e me motivaram a ir mais além. Muito Obrigada!

Quero agradecer à Manuela Fernandes, que é a prova de que as amizades de infância perduram, não morrendo a adversidades da vida. Consegues estar presente para me dar for¸ca sempre que é preciso, nem a distância te impede. Muito Obrigada! Agrade¸co também à Carolina Martins por toda a compreensão, apoio, for¸ca e amizade demonstrada tanto nos bons como nos maus momentos. Sem dúvida, outra amizade para a vida, Muito Obrigada! Quero agradecer ao Rúben Oliveira, ao André Barros, ao Tiago Almeida e ao Diogo Silva por toda a amizade que demonstraram desde os primeiros dias da minha existência nesta Universidade. Obrigada por me aturarem tanto tempo e espero que continuem!

Quero agradecer à Daniela Louren¸co e à Amélia Ramos por permitirem eu ser a Patroa de praxe babada que sou hoje! Obrigada meninas por sempre acreditarem e me motivarem a dar o melhor de mim! São as maiores vocês! Quero agradecer ao José Silva por todo o amor, apoio e motiva¸cão demons-trado ao longo deste percurso a dois, que nem sempre foi fácil. Obrigada por tudo!

Quero agradecer a todo o grupo de investiga¸cão do NAP pela boa disposi-¸cão e pelo bom ambiente de trabalho que proporcionaram. Quero destacar o Carlos Ferreira pela importante ajuda no in´ıcio deste trabalho pois sem ele o “Cross Compile” teria sido um “bicho de sete cabe¸cas”. Quero agrade-cer também à “fila do fundo”, Rúben, Carolina e Rodrigo Almeida pela boa disposi¸cão e dias bem passados no Laboratório de Redes. Obrigada! Quero agradecer ao grupo de investiga¸cão BioMachines Lab do ISCTE por toda a ajuda, hospitalidade e boa disposi¸cão demonstrada nas minhas esta-dias pela Capital! Obrigada!

Agrade¸co `a Professora Doutora Susana Sargento e ao Doutor Lucas Guar-dalben por me terem sugerido este tema e por toda a orienta¸c˜ao e apoio dados durante o desenvolvimento deste trabalho. Obrigada pela experiˆ en-cia!

Para terminar, quero fazer um agradecimento especial às pessoas que por ironia do destino aparecem nos momentos mais dif´ıceis e que conseguem arrancar me um sorriso, quando eu mesma pensava que já não era poss´ıvel!

(8)

(9)

“- Why do we fall sir?

- So we can learn to pick ourselves up” by Alfred in Batman Begins

(10)

(11)

Resumo Os drones têm-se tornado cada vez mais comuns no dia-a-dia da nossa so-ciedade uma vez que podem ser utilizados para inúmeras aplica¸cões. Dado que a maior parte da superf´ıcie do planeta Terra é coberta por água, os dro-nes aquáticos podem-se revelar grandes aliados na monitoriza¸cão do meio aquático. Para tal é necessário um número elevado de drones em constante comunica¸cão, para assim se poderem auto-organizar de acordo com as suas missões, sendo também importante que as informa¸cões recolhidas pelos seus sensores cheguem a esta¸cões fixas em terra.

Esta disserta¸cão propõe um mecanismo que determina e avalia a qualidade da liga¸cão entre os drones com base na for¸ca de sinal, na estabilidade da liga¸cão e na sua largura de banda. Esta qualidade da liga¸cão pode ser usada como um parâmetro relevante no sistema de controlo dos drones, para que estes se consigam organizar de forma a manterem uma rede de boa quali-dade. Como esperado, verifica-se que a qualidade da liga¸cão decresce com a distância entre drones, tendo sido poss´ıvel comunica¸cão em água a uma distância máxima de 110 metros com a tecnologia Wi-Fi.

Este mecanismo de avalia¸cão da qualidade de liga¸cão entre drones é pos-teriormente integrado no processo de encaminhamento numa DTN, para o transporte de informa¸cão de sensores de forma eficiente dentro de um cluster de drones. Para o efeito são propostas três estratégias de encami-nhamento: 1 - Encaminhamento através do primeiro contacto de vizinho recebido; 2 - Encaminhamento através do contacto com melhor Qualidade; e 3 - Encaminhamento através do contacto com melhor Qualidade para a Gateway. De forma a avaliar o desempenho das estratégias propostas foram efectuados testes em dois cenários, um onde os drones se encontram em posi¸cões fixas e outro onde existem drones móveis. A estratégia de encami-nhamento que considera o contacto com melhor Qualidade para a Gateway ´

(12)

(13)

Abstract Drones have become increasingly commonplace in our daily basis since they can be used for numerous applications. Most of the Earth surface is covered by water, and therefore, aquatic drones can become great assets in aquatic environment monitoring tasks. Thus, we need to guarantee a per-sistent communication among a high number of drones required to assure the drones’ self-control, according to their tasks, as well as to make sure that sensors data can reach the fixed gateway placed ashore.

This dissertation proposes a mechanism to calculate and assess the link qua-lity between drones based on the signal strength, stabiqua-lity of the connection and its bandwidth. This link quality can be used as a relevant parameter to the drones control system, for them to be able to maintain a good quality network by self-organizing. The link quality is therefore used as an input parameter of the drones control system, to maintain the connectivity of the entire cluster. Real scenario results have shown that it is possible to maintain an acceptable level of communication in water up to a maximum distance of 110 meters with the Wi-Fi technology.

This quality evaluation mechanism is integrated in the routing process of a DTN for an efficient transport data information inside the cluster. In this approach, three routing strategies are proposed: 1 - Routing through the first contact received by the neighbour; 2 - Routing through the best Quality contact; 3 - Routing through the best Quality contact to the Gateway. To evaluate the performance of the proposed routing strategies, two distinct scenarios were adopted, with and without movement, and the results have shown that strategy “Best Quality Contact to the Gateway” presents the best results, in both scenarios, when compared to other routing strategies.

(14)

(15)

Conte´

udo

Conte´udo i

Lista de Figuras v

Lista de Tabelas ix

Lista de Equa¸c˜oes xi

Lista de Acr´onimos xiii

1 Introdu¸c˜ao 1

1.1 Contexto e Motiva¸c˜ao . . . 1

1.2 Objectivos e Contribui¸c˜oes . . . 2

1.3 Organiza¸c˜ao da Disserta¸c˜ao . . . 3

2 Estado da Arte 5 2.1 Descri¸c˜ao do Cap´ıtulo . . . 5

2.2 Drones . . . 5

2.2.1 Drones Aqu´aticos . . . 6

2.3 Redes Tolerantes a Atrasos . . . 8

2.3.1 Defini¸c˜ao . . . 8

2.3.2 Arquitectura . . . 9

2.3.3 Implementa¸c˜oes . . . 10

2.3.3.1 DTN2 . . . 10

2.3.3.2 IBR-DTN . . . 11

2.3.3.3 mobile Opportunistic enVironmEnt (mOVE) . . . 13

2.3.3.4 Compara¸c˜ao entre as diferentes implementa¸c˜oes de DTN . . . 18

2.4 Protocolos de Encaminhamento . . . 19

2.4.1 Epidemic . . . 19

2.4.2 Spray and Wait . . . 20

2.4.3 PRoPHET . . . 21

2.4.4 MaxProp . . . 22

2.4.5 RAPID . . . 23

2.4.6 Compara¸c˜ao entre os diferentes protocolos de encaminhamento . . . 23

(16)

3 Comunica¸c˜oes entre Drones Aqu´aticos 25

3.1 Descri¸c˜ao do Cap´ıtulo . . . 25

3.2 Problema . . . 25

3.3 Qualidade da Liga¸c˜ao . . . 26

3.4 Estrat´egias de encaminhamento da informa¸c˜ao . . . 28

3.4.1 Primeiro Contacto . . . 29

3.4.2 Contacto com melhor Qualidade . . . 29

3.4.3 Contacto com melhor Qualidade para a Gateway . . . 30

3.5 Arquitectura do Drone . . . 31

3.5.1 M´odulo Drone Quality Connection (DQC) . . . 32

3.5.1.1 Inicializa¸c˜ao . . . 32

3.5.1.2 Gestor de Vizinhos . . . 33

3.5.1.3 Eventos Peri´odicos . . . 33

3.5.1.4 Listening Socket . . . 34

3.5.1.5 Leitura do Signal Strength Intensity (SSI) . . . 34

3.5.1.6 Leitura da Largura de Banda Dispon´ıvel . . . 35

3.5.1.7 IPC Socket - Comunica¸c˜ao com o mOVE . . . 35

3.5.2 Comunica¸c˜ao com o M´odulo de Controlo do Drone . . . 36

3.6 Considera¸c˜oes do Cap´ıtulo . . . 38

4 Integra¸cão e Implementa¸cão 39 4.1 Descri¸cão do Cap´ıtulo . . . 39

4.2 Modifica¸c˜oes Gerais . . . 39

4.2.1 Biblioteca de Suporte do mOVE e Cabe¸calho do Pacote . . . 39

4.2.2 M´odulo RX . . . 41

4.2.3 M´odulo Neighboring . . . 41

4.2.4 M´odulo Logging . . . 41

4.3 Descri¸c˜ao do M´odulo de Routing . . . 42

4.4 Implementa¸c˜ao das estrat´egias de encaminhamento propostas . . . 43

4.4.1 Primeiro Contacto . . . 45

4.4.2 Contacto com melhor Qualidade . . . 45

4.4.3 Contacto com melhor Qualidade para a Gateway . . . 48

4.4.4 Processo para evitar ciclos . . . 52

5 Resultados 55 5.1 Descri¸c˜ao do Cap´ıtulo . . . 55

5.2 Software e Equipamento . . . 55

5.3 M´etricas de Avalia¸c˜ao . . . 55

5.3.1 M´etricas do DQC . . . 56

5.3.2 M´etricas das estrat´egias de encaminhamento . . . 56

5.3.3 M´etricas da carga computacional . . . 57

5.4 Avalia¸c˜ao do DQC . . . 57

5.4.1 Cen´ario e considera¸c˜oes . . . 57

5.4.2 Resultados . . . 58

5.5 Avalia¸c˜ao das estrat´egias de encaminhamento . . . 63

(17)

5.5.2 Primeiro cen´ario . . . 64

5.5.2.1 Resultados . . . 64

5.5.3 Segundo cen´ario . . . 73

5.5.3.1 Resultados . . . 73

6 Conclus˜oes e Trabalho Futuro 81 6.1 Conclus˜oes . . . 81

6.2 Trabalho Futuro . . . 82

Bibliografia 83

(18)

(19)

Lista de Figuras

1.1 Distribui¸c˜ao dos drones por clusters . . . 1

2.1 Ziphius . . . 7

2.2 iBubble . . . 7

2.3 Seis drones aqu´aticos . . . 8

2.4 Bundle Forwarder Architecture . . . 9

2.5 Mecanismo de SCF . . . 10

2.6 Compara¸c˜ao entre o protocolo da Internet (esquerda) com o protocolo da DTN (direita) . . . 10

2.7 Arquitectura do DTN2 . . . 11

2.8 Arquitectura do IBR-DTN . . . 11

2.9 Arquitectura do mOVE . . . 14

2.10 Classes do m´odulo Neighboring . . . 15

2.11 Organiza¸c˜ao da Storage . . . 16

2.12 Classes do m´odulo Routing . . . 16

2.13 Exemplo de configura¸c˜ao do mOVE . . . 18

2.14 Fluxograma operacional do mOVE . . . 18

2.15 Exemplo do protocolo Epidemic . . . 20

2.16 Exemplo de mensagens trocadas no protocolo Epidemic . . . 20

2.17 Exemplo do protocolo Spray and Wait . . . 21

2.18 Exemplo do protocolo PRoPHET . . . 23

3.1 Cenário de monitoriza¸cão do mar com drones aquáticos . . . 26

3.2 Exemplo da estrat´egia: Contacto com melhor Qualidade . . . 30

3.3 Exemplo da estrat´egia: Contacto com melhor Qualidade para a Gateway . . . . 31

3.4 Arquitectura do drone . . . 31

3.5 Fluxograma da Inicializa¸c˜ao do m´odulo DQC . . . 33

3.6 Estrutura dos pacotes trocados entre o DQC . . . 34

3.7 Estrutura dos pacotes enviados pelo cliente DQC . . . 35

3.8 Estrutura dos pacotes enviados pelo servidor (mOVE) . . . 35

3.9 Processo de desenvolvimento do controlador h´ıbrido para cada tarefa . . . 36

3.10 Drone Remote Console . . . 37

3.11 Estrutura dos pacotes de controlo . . . 38

4.1 Arquitectura do mOVE e cabe¸calho do pacote modificados . . . 40

4.2 Fluxograma da recep¸c˜ao de um pacote de acknowledgment . . . 44

(20)

4.4 Fluxogramada da actualiza¸cão e envio de um pacote de dados para um vizinho 47 4.5 Fluxograma da decisão de envio de um pacote de dados para a estratégia:

primeiro vizinho . . . 47

4.6 Fluxograma da decis˜ao de envio de um pacote de dados para a estrat´egia: vizinho com melhor qualidade . . . 48

4.7 Estrutura do pacote de advertisement . . . 49

4.8 Fluxograma da decis˜ao de envio dos pacotes de advertisements . . . 50

4.9 Fluxograma da recep¸c˜ao dos pacotes de advertisements . . . 51

4.10 Fluxograma da decis˜ao de envio de um pacote de dados para a estrat´egia: vizinho com melhor qualidade para a gateway . . . 53

4.11 Preven¸c˜ao de ciclos a um salto . . . 54

4.12 Preven¸c˜ao de ciclos a dois saltos . . . 54

4.13 Preven¸c˜ao de ciclos a v´arios saltos . . . 54

5.1 Drone Aqu´atico . . . 56

5.2 Cen´ario no Parque das Na¸c˜oes em Lisboa . . . 58

5.3 SSI medido entre os drones . . . 59

5.4 SSI normalizado entre os drones . . . 59

5.5 Estabilidade medida entre os drones . . . 60

5.6 Estabilidade normalizado entre os drones . . . 60

5.7 Largura de Banda Dispon´ıvel (Ab) medida entre os Drones . . . 60

5.8 Largura de Banda Efectiva (Ce) medida entre os drones . . . 61

5.9 Largura de Banda Dispon´ıvel normalizado entre os drones . . . 61

5.10 Qualidade da liga¸c˜ao entre os Drones . . . 61

5.11 Percentagem de utiliza¸cão do CPU (à esquerda: Drone 1, à direita: Drone 2) . 62 5.12 Média da Carga (à esquerda: Drone 1, à direita: Drone 2) . . . 62

5.13 Primeiro cen´ario: N´os fixos . . . 64

5.14 Primeiro cen´ario - Teste 1: Percentagem de pacotes entregues `a gateway - Taxa de entrega . . . 65

5.15 Primeiro cen´ario - Teste 2: Percentagem de pacotes entregues `a gateway - Taxa de entrega . . . 66

5.16 Primeiro cenário - Teste 1: Número de pacotes transmitidos por nó . . . 66

5.17 Primeiro cenário - Teste 2: Número de pacotes transmitidos por nó . . . 67

5.18 Primeiro cenário - Teste 1: Número de pacotes recebidos por nó . . . 67

5.19 Primeiro cenário - Teste 2: Número de pacotes recebidos por nó . . . 67

5.20 Primeiro cenário - Teste 1: Número de pacotes na tabela noData por nó . . . . 68

5.21 Primeiro cenário - Teste 2: Número de pacotes na tabela noData por nó . . . . 68

5.22 Primeiro cenário - Teste 1: Número de pacotes de acknowledgments por nó . . 68

5.23 Primeiro cenário - Teste 2: Número de pacotes de acknowledgments por nó . . 69

5.24 Primeiro cenário - Teste 1: Número de pacotes ouvidos por nó . . . 69

5.25 Primeiro cenário - Teste 2: Número de pacotes ouvidos por nó . . . 69

5.26 Primeiro cenário - Teste 1: Número de pacotes repetidos por nó . . . 70

5.27 Primeiro cenário - Teste 2: Número de pacotes repetidos por nó . . . 70

5.28 Primeiro cenário - Teste 1: Número de pacotes de advertisements por nó . . . 71

5.29 Primeiro cenário - Teste 2: Número de pacotes de advertisements por nó . . . 71

5.30 Segundo cen´ario: Mobilidade . . . 73

(21)

5.32 Segundo cenário: Percentagem de pacotes entregues à gateway - Taxa de entrega 74 5.33 Segundo cenário: Percentagem de pacotes entregues à gateway - Taxa de

en-trega (com intervalos de confian¸ca) . . . 75

5.34 Segundo cenário: Número de pacotes transmitidos por nó . . . 75

5.35 Segundo cenário: Número de pacotes recebidos por nó . . . 76

5.36 Segundo cenário: Número de pacotes na tabela noData por nó . . . 76

5.37 Segundo cenário: Número de pacotes de acknowledgments por nó . . . 77

5.38 Segundo cenário: Número de pacotes ouvidos por nó . . . 77

5.39 Segundo cenário: Número de pacotes repetidos por nó . . . 78

5.40 Segundo cenário: Número de pacotes de advertisements por nó . . . 78

A.1 N´umero de pacotes na tabela Expiry - Primeiro cen´ario, Teste 1 . . . 89

A.2 N´umero de pacotes na tabela onHold - Primeiro cen´ario, Teste 1 . . . 90

A.3 N´umero de pacotes na tabela noData - Primeiro cen´ario, Teste 1 . . . 90

A.4 N´umero de pacotes na tabela Own - Primeiro cen´ario, Teste 1 . . . 91

A.5 N´umero de pacotes na tabela Expiry - Primeiro cen´ario, Teste 2 . . . 91

A.6 N´umero de pacotes na tabela onHold - Primeiro cen´ario, Teste 2 . . . 92

A.7 N´umero de pacotes na tabela noData - Primeiro cen´ario, Teste 2 . . . 92

A.8 N´umero de pacotes na tabela Own - Primeiro cen´ario, Teste 2 . . . 93

A.9 N´umero de pacotes na tabela Expiry - Segundo cen´ario . . . 93

A.10 N´umero de pacotes na tabela onHold - Segundo cen´ario . . . 94

A.11 N´umero de pacotes na tabela noData - Segundo cen´ario . . . 94

(22)

(23)

Lista de Tabelas

4.1 Tabela de encaminhamento - Contacto com melhor Qualidade para a Gateway 49 5.1 Periodicidade de envio dos pacotes para o m´odulo de controlo (cPacket) e da

leitura das larguras de banda (wBest) para cada experiência . . . 58 5.2 Pacotes armazenados inicialmente em cada nó . . . 63 5.3 Primeiro cenário - Teste 1: Tamanho dos pacotes de dados, de

acknowledg-ments e de advertiseacknowledg-ments . . . 72 5.4 Primeiro cen´ario - Teste 2: Tamanho dos pacotes de dados, de

acknowledg-ments e de advertiseacknowledg-ments . . . 72 5.5 Segundo cen´ario: Tamanho dos pacotes de dados, de acknowledgments e de

(24)

(25)

Lista de Equa¸

c˜

oes

2.1 PRoPHET: Encontro directo . . . 21 2.2 PRoPHET: Diminui¸cão ao longo do tempo . . . 22 2.3 PRoPHET: Propriedade transitiva . . . 22 3.1 Potência do sinal em decibel miliwatts (dBm) . . . 27 3.2 Fun¸cão da estabilidade entre um nó A e um nó B . . . 27 3.3 Fun¸cão da Largura de Banda Dispon´ıvel entre um nó A e um nó B . . . 27 3.4 Fun¸cão da qualidade entre um nó A e um nó B . . . 28 4.1 Fun¸cão da qualidade de um nó A até à Gateway . . . 50 5.1 Utiliza¸cão de CPU . . . 57

(26)

(27)

Lista de Acr´

onimos

API Application Programming Interface ARM Advanced RISC Machine

CLA Convergence Layer Adapter CPU Central Processing Unit CSV Comma-Separated Values dBm decibel miliwatts

DQC Drone Quality Connection DTN Delay Tolerant Network EID Endpoint Identifier

EUA Estados Unidos da Am´erica GPS Global Positioning System HTTP HyperText Transfer Protocol

IEEE Institute of Electrical and Electronics Engineers

IP Internet Protocol

IPC Inter Process Communication JSON JavaScript Object Notation

LoRa Long Range

MAC Medium Access Control MATLAB MATrix LABoratory

mOVE mobile Opportunistic enVironmEnt NAP Network Architectures and Protocols NTP Network Time Protocol

(28)

OSI Open Systems Interconnection

PRoPHET Probabilistic Routing Protocol using History of Encounters and Transitivity

RAM Random Access Memory

RAPID Resource Allocation Protocol for Intentional DTN RFC Request for Comments

RSU Road Side Unit

SBC Single Board Computer SCF Store-Carry-and-Forward

SN Sequence Number

SSI Signal Strength Intensity

SV Summary Vector

TCP Transmission Control Protocol UAV Unmanned Aerial Vehicles UDP User Datagram Protocol VANET Vehicular Ad-hoc NETwork

WAVE Wireless Access in Vehicular Environments WBest Wireless Bandwidth Estimation Tool Wi-Fi Wireless Fidelity

(29)

Cap´ıtulo 1

Introdu¸

c˜

ao

1.1 Contexto e Motiva¸

c˜

ao

A oceanografia é uma área que merece alguma aten¸cão visto que mais de 70% da superf´ıcie do planeta Terra é coberta por oceanos e que em grande parte está inexplorada [1], existindo uma grande quantidade de recursos naturais a serem descobertos. Pensando no caso de Portugal, o mar representa um dos seus principais recursos.

Figura 1.1: Distribui¸c˜ao dos drones por clusters

Novas formas de explorar os recursos e as oportunidades mar´ıtimas são de particular interesse, sobretudo se considerarmos que alguns dos métodos usados actualmente colocam em risco a vida humana ou simplesmente são demasiado dispendiosas. Assim, os drones aquáticos têm vindo a ganhar bastante relevância em determinadas tarefas e aplica¸cões, tais como, a monitoriza¸cão do meio aquático, o patrulhamento das zonas costeiras, o aux´ılio em estudos de biologia marinha e aquecimento dos oceanos, entre outras. Estas tarefas exigem um número elevado de drones, que devem estar em comunica¸cão constante e partilhar entre eles informa¸cão relevante (dados adquiridos dos sensores que se encontram a bordo dos

(30)

drones) para que um ou mais a possa fazer chegar a terra. Para garantir que nenhum drone fique isolado, é necessário que estes tenham capacidade de se auto-organizar, ou seja, de se reposicionarem tendo em conta a qualidade das liga¸cões entre eles.

Pretende-se implementar e avaliar uma arquitectura de rede para drones aquáticos, o que por si só possui desafios importantes. Dada a sua mobilidade e as condi¸cões do meio, há uma grande probabilidade de existir intermitências nas comunica¸cões. O facto de nem sempre existir comunica¸cão com uma esta¸cão base, leva a que os drones necessitem de, para além dos mecanismos de encaminhamento, incluir o armazenamento de informa¸cão para posteriormente a enviarem para outros drones ou gateways de forma a chegar ao destino. Nesta disserta¸cão apenas serão abordadas as comunica¸cões Wireless Fidelity (Wi-Fi) dentro de um cluster, ou seja, a informa¸cão dos sensores de cada drone terá de chegar a uma gateway de forma eficiente. Uma gateway é um drone com capacidade de comunicar também a longo alcance. Outro desafio prende-se com o facto de analisar como os drones se devem movimentar na água para garantir constante comunica¸cão, e através da qualidade da rede que eles formam, dar ordens para que eles se organizem e mudem de localiza¸cão consoante as respectivas missões, no sentido de não deixar nenhum drone sem contacto. Assim, torna-se essencial garantir uma constante comunica¸cão entre o mecanismo de controlo do drone e a rede.

Desta forma, a motiva¸cão deste trabalho é melhorar a comunica¸cão em cenários de drones aquáticos, oferecendo mais valor com menores custos, explorando a possibilidade de usar so-lu¸cões de comunica¸cão que possam ser aplicadas em dispositivos prontos a usar neste tipo de cenários. Como base de comunica¸cão serão usadas Redes Tolerantes a Atrasos (Delay Tolerant Networks (DTNs)) porque são adequadas para trabalhar com fragmenta¸cões da rede, devido aos seus mecanismos de tolerância a atrasos (armazenamento, transporte e encaminhamento). Para lidar com as intermitências nas comunica¸cões, são propostas estratégias de encaminha-mento baseadas no próximo salto e/ou na qualidade das liga¸cões de forma a seleccionar os melhores caminhos para encaminhar as informa¸cões dos drones.

1.2 Objectivos e Contribui¸

c˜

oes

O objectivo desta disserta¸cão é o estudo de mecanismos para a comunica¸cão entre os drones aquáticos e implementa¸cão de estratégias de encaminhamento de informa¸cão num cluster de drones. De seguida são apresentados os principais objectivos:

• Estudo, implementa¸cão e avalia¸cão em ambiente real de um mecanismo que calcula a qualidade da comunica¸cão entre drones com base no Signal Strength Intensity (SSI), na estabilidade e na largura de banda dispon´ıvel, de forma a descobrir os limites de distância que dois drones conseguem manter a comunica¸cão.

• Fornecer informa¸cões da rede, nomeadamente o valor da qualidade da liga¸cão, ao sistema de controlo dos drones, para assim interligar o seu movimento não só com as suas tarefas, mas também com a manuten¸cão da rede com uma boa qualidade e impedir que os drones saiam do alcance de comunica¸cão.

• Implementa¸cão e avalia¸cão de estratégias de encaminhamento numa DTN para enca-minhar a informa¸cão dos sensores integrados nos drones, de forma eficiente até uma gateway dentro do cluster.

(31)

1.3 Organiza¸

c˜

ao da Disserta¸

c˜

ao

A presente disserta¸c˜ao est´a organizada da seguinte forma:

• Cap´ıtulo 1 contém o contexto, motiva¸cão e objectivos desta disserta¸cão.

• Cap´ıtulo 2 exp˜oe o estado de arte dos drones aqu´aticos, redes tolerantes a atrasos e protocolos de encaminhamento.

• Cap´ıtulo 3 descreve o problema das comunica¸cões entre drones aquáticos, o conceito de qualidade da liga¸cão, as estratégias de encaminhamento e a arquitectura proposta para cada drone.

• Cap´ıtulo 4 descreve a implementa¸cão e integra¸cão da solu¸cão implementada. • Cap´ıtulo 5 apresenta os resultados da avalia¸cão da solu¸cão implementada. • Cap´ıtulo 6 apresenta as conclusões e trabalho futuro.

(32)

(33)

Cap´ıtulo 2

Estado da Arte

2.1 Descri¸

c˜

ao do Cap´ıtulo

Neste cap´ıtulo serão apresentados alguns cenários de aplica¸cão, onde os drones poderão desempenhar um papel importante, serão apresentados exemplos de drones aquáticos e é feita uma breve descri¸cão dos drones aquáticos utilizados neste trabalho. De seguida será apresentada a defini¸cão e arquitectura das redes tolerantes a atrasos, sendo também apre-sentadas algumas implementa¸cões já existentes, entre elas o mobile Opportunistic enViron-mEnt (mOVE), a DTN utilizada neste trabalho. Por fim, serão apresentados exemplos de protocolos de encaminhamento aplicados a DTNs.

2.2 Drones

Actualmente vivemos numa era onde a evolu¸cão tecnológica cresce exponencialmente e onde surgem conceitos novos diariamente. Uma das tecnologias mais emergentes e com maior impacto nos últimos anos é a comercializa¸cão de Unmanned Aerial Vehicles (UAV), mais conhecidos como drones [2] [3] [4] . Estes drones surgiram inicialmente para fins militares, nos anos noventa nos Estados Unidos da América (EUA) [5]; contudo ganharam notoriedade e já come¸cam a fazer parte do uso civil de forma bastante relevante. Este facto veio contribuir para inúmeras aplica¸cões civis, devido a serem vistos como objectos úteis em inúmeras manobras que poderiam colocar em risco a vida de um ser humano, proporcionando assim benef´ıcios na realiza¸cão de certas tarefas tanto a n´ıvel de dificuldade operacional como a n´ıvel monetário.

Existem vários cenários de aplica¸cões civis [6] onde os drones poderão desempenhar um papel importante:

Investiga¸c˜ao

• Pesquisa meteorol´ogica

• Acidentes nucleares - monitoriza¸cão, medi¸cão da contamina¸cão • Erup¸cões vulcânicas - análise de nuvens de cinzas

• Silvicultura - acompanhamento do crescimento das ´arvores • Monitoriza¸c˜ao de oceanos e mares

(34)

Aplica¸cões de proteçcão civil

• Aplica¸c˜oes policiais para a seguran¸ca civil • Combate a incˆendios florestais

• Vigilˆancia das fronteiras e da costa

• Vigilˆancia de grandes eventos desportivos ou sociais com elevado risco de confrontos f´ısicos

• Monitoriza¸cão de catástrofes naturais Inspeçcões industriais

• Inspeçcões de oleodutos ou gasodutos • Inspeçcões de turbinas eólicas ou pontes

• Inspeçcões de linhas de energia ou postes de alta tensão

Capta¸c˜ao de v´ıdeo e fotografia, permitindo o registo de imagem para v´arios tipos de finalidades

• Eventos sociais p´ublicos ou particulares • Controlo de fronteira

• Apoio aéreo no combate a incêndios florestais • Monitoriza¸cão de espécies mar´ıtimas

Em suma, existe um grande leque de tarefas de dif´ıcil execu¸c˜ao onde os drones se revelam ser uma ferramenta preciosa.

2.2.1 Drones Aqu´aticos

Nos últimos anos tem surgido uma nova gera¸cão de drones aquáticos.

O Ziphius1é o primeiro protótipo português capaz de navegar sobre lagos, mar ou piscinas, controlado directamente por um telemóvel ou tablet (iOS ou Android). Este drone tem um alcance de comunica¸cão com os utilizadores de aproximadamente 90 metros. Possuiu uma câmara HD inclinável que permite ver tanto acima como abaixo da superf´ıcie, e transporta a bordo um Raspberry Pi 2.

O iBubble 3 é um protótipo francês projectado para facilitar a vida dos mergulhadores, uma vez que consegue submergir capturando fotos e v´ıdeos de diversos ângulos de forma aut´ o-noma, o que permite que o mergulhador fique com as mãos livres para poder explorar o fundo do mar. Tudo o que for gravado pode ser reproduzido num telemóvel ou tablet via Wi-Fi ou Bluetooth. O mergulhador possui ainda uma pulseira de controlo com algumas funciona-lidades: possibilidade de controlar manualmente os movimentos da câmara; iniciar/parar a grava¸cão de v´ıdeos e a possibilidade de chamar o drone para perto do mergulhador.

1_{http://myziphius.com/} 2

https://www.raspberrypi.org/

(35)

Figura 2.1: Ziphius 1

Figura 2.2: iBubble 3

Existem muitos outros drones aquáticos, tais como, Aquabotix 4 e Trident 5, que têm diversas caracter´ısticas em comum com os primeiros. Para além de terem um custo bastante elevado, são mais direccionados para entretenimento e o seu software não é open source, apre-sentando também algumas limita¸cões de comunica¸cão, uma vez que não comunicam entre si e apenas comunicam com telemóveis ou tablets, não conseguindo agir de forma autónoma.

Os drones aquáticos têm sido estudados para um grande leque de aplica¸cões: monito-riza¸cão ambiental [7], geologia [8], arqueologia [9], hidrografia [10], defesa [11] e seguran¸ca mar´ıtima [12]. Nos últimos anos foram realizados investimentos públicos e privados impor-tantes na área dos drones aquáticos [13] [14]. O foco principal tem sido em sistemas de um ´

unico robô com um grau elevado de complexidade de hardware e software. Embora estes sistemas tenham sido aplicados a uma variedade de cenários e tenham provado ser comer-cialmente viáveis, têm custos elevados, limitados em termos das tarefas que podem realizar (por exemplo, monitoriza¸cão de grandes áreas) e requerem uma comunica¸cão constante entre a esta¸cão base e os drones.

4

http://www.aquabotix.com/

(36)

De forma a combater estas limita¸cões, os autores de [15] [16] [17] propõem um sistema de drones aquáticos de larga escala, compostos por drones simples, de baixo custo e com um controlo descentralizado, sendo capazes de tomar decisões de forma autónoma nas mais diversas tarefas mar´ıtimas. A Figura 2.3 apresentada seis drones. Para a comunica¸cão entre os drones é proposta a utiliza¸cão de uma rede sem fios ad-hoc baseada em IEEE 802.11g (Wi-Fi) onde toda a informa¸cão é enviada em broadcast, ou seja, não tem qualquer tipo de inteligência. Foram também testadas em [18] outras tecnologias de comunica¸cão de baixo alcance, XBee 6 _{e de longo alcance, LongRange(LoRa)}T M 7_{, para futuramente ser implementada uma rede} heterogénea entre os drones. Um ponto importante que será abordado neste trabalho é a comunica¸cão entre a camada de rede e o controlo do drone, de forma a este poder tomar decisões com base nas informa¸cões da rede, o que ainda não acontece.

Figura 2.3: Seis drones aqu´aticos [17]

2.3 Redes Tolerantes a Atrasos

2.3.1 Defini¸c˜ao

Uma Rede Tolerante a Atrasos, denominada Delay Tolerant Network (DTN), é definida em [19] como sendo “a área das redes que aborda os desafios de redes intermitentes e sem uma conexão end-to-end ”. Este tipo de rede foi criada principalmente para assegurar a comu-nica¸cão em ambientes extremos, tais como comunica¸cões espaciais ou interplanetárias. Estes ambientes são caracterizados pela sua latência elevada (que pode atingir horas ou mesmo dias) e taxas elevadas de erros.

Uma vez que este tipo de protocolo de rede foi desenvolvido tendo em conta esses am-bientes, as DTNs são muito mais flex´ıveis e podem-se adaptar a outros ambientes extremos, além do espa¸co. Após a publica¸cão do primeiro rascunho desta arquitectura [20], os autores pretenderam usar a arquitectura DTN nas redes sem fios da Terra.

6

https://www.digi.com/lp/xbee

(37)

2.3.2 Arquitectura

A arquitectura da DTN tem como objectivo adaptar-se à interrup¸cão da rede e também à heterogeneidade dos protocolos subjacentes utilizados para fornecer funcionalidades de rede, como transporte e encaminhamento. De acordo com [21], a DTN usa camadas, encapsula-mento e armazenaencapsula-mento persistente para ligar partes heterogéneas de uma rede.

Uma DTN pode usar protocolos diferentes para a entrega de dados (Transmission Control Protocol (TCP)/Internet Protocol (IP), Ethernet). Uma vez que cada protocolo tem as suas próprias conven¸cões e semânticas, a arquitectura da DTN inclui um módulo denominado de Convergence Layer Adapter (CLA), que é responsável por fornecer todas as fun¸cões necessárias para transportar os pacotes de dados da DTN (chamados bundles) para o respectivo protocolo. Como se pode observar na Figura 2.4, o elemento central da arquitectura da DTN é o Bundle Forwarder, que é responsável pelo encaminhamento de pacotes entre a storage, o CLA e as aplica¸cões, dependendo das decisões tomadas pelos algoritmos de encaminhamento.

Figura 2.4: Bundle Forwarder Architecture [21]

Para superar as questões associadas à interrup¸cão da rede, conectividade intermitente, atraso longo ou variável, taxas de dados assimétricas e taxas de erro altas, as DTNs usam um mecanismo chamado Store-Carry-and-Forward (SCF) (ilustrado na Figura 2.5). Este mecanismo permite receber dados, armazená-los e só os encaminhará quando a comunica¸cão estiver dispon´ıvel.

Dependendo do tipo de rede onde as DTNs são usadas, a comunica¸cão pode ficar indis-pon´ıvel para um nó por um per´ıodo de tempo considerável (horas ou dias). Além disso, se existir uma interrup¸cão na comunica¸cão durante a transmissão de informa¸cão, tal informa¸cão deve ser armazenada no nó remetente para posterior retransmissão. Como resultado, os nós precisam de ser equipados com discos r´ıgidos para fins de armazenamento. Em conclusão, o mecanismo SCF é a resposta à conectividade intermitente.

Para incluir o mecanismo SCF na rede, a arquitectura da DTN adiciona uma nova camada entre as camadas de Aplica¸c˜ao e de Transporte. De acordo com [20], a camada do pacote

(38)

Figura 2.5: Mecanismo de SCF [22]

(Bundle) é responsável por aplicar o armazenamento persistente como uma contramedida à conectividade intermitente, assim como o mecanismo SCF. A Figura 2.6 representa o modelo Open Systems Interconnection (OSI) integrando a camada de Bundle referida anteriormente.

Figura 2.6: Compara¸c˜ao entre o protocolo da Internet (esquerda) com o protocolo da DTN (direita) [22]

2.3.3 Implementa¸c˜oes

2.3.3.1 DTN2

O DTN2 [23] é a implementa¸cão de referência do Bundle Protocol [24] e seu principal ob-jectivo é fornecer uma estrutura de software flex´ıvel e robusto para experimenta¸cão, extensão e implanta¸cão do mundo real. A arquitectura do DTN2 é apresentada na Figura 2.7 sendo os seus módulos descritos de seguida.

Bundle Router e Bundle Forwarder: O Bundle Router é responsável por tomar decisões de encaminhamento (por exemplo, seleccionar uma rota). Ele toma as decisões com base em eventos externos e passa um conjunto de instru¸cões para o Bundle Forwarder que é responsável pela execu¸cão das decisões de encaminhamento.

Convergence Layers: As Convergence Layers permitem estabelecer uma conexão entre nós DTN e os protocolos de transporte, por exemplo TCP ou User Datagram Protocol (UDP). Permitem a conversão de pacotes em fluxos de dados adequados capazes de serem transpor-tados por protocolos de transporte de um nó para outro.

Persistent Storage: Este módulo é composto por duas bases de dados que são respon-sáveis por armazenar o conteúdo dos pacotes durante a fase carry do mecanismo SCF.

Fragmentation Module: Este módulo é responsável pela fragmenta¸cão e posterior re-constitui¸cão de pacotes. Quando todos os fragmentos de um determinado pacote forem rece-bidos, este módulo sinaliza o Bundle Router.

(39)

Figura 2.7: Arquitectura do DTN2 [23]

Contact Manager: Este módulo é responsável por manter um registo actualizado sobre os links de comunica¸cão dispon´ıveis com outros nós. Essas informa¸cões incluem dados hist´ ori-cos sobre sua conectividade e desempenho. Estas informa¸cões são usadas pelo Bundle Router para tomar decisões de encaminhamento.

2.3.3.2 IBR-DTN

O IBR-DTN [25] foi especialmente desenvolvido para sistemas embutidos e funciona em OpenWRT8, que é um sistema operativo baseado em Linux criado para correr em sistemas embutidos. A implementa¸cão do IBR-DTN pretende ser o mais modular poss´ıvel e pretende minimizar os requisitos externos (por exemplo, bibliotecas), uma vez que estas dependências externas nem sempre se encontram dispon´ıveis para determinadas plataformas ou o espa¸co de memória dispon´ıvel não ser o suficiente para tais requisitos. A Figura 2.8 apresenta a arquitectura do IBR-DTN sendo os seus módulos descritos de seguida.

Figura 2.8: Arquitectura do IBR-DTN [25]

(40)

Event Switch

O Event Switch é o módulo principal do IBR-DTN sendo este módulo responsável por encaminhar um conjunto de eventos padrão para todos os sub-módulos relevantes. Os eventos padrão existem para lidar com o armazenamento e encaminhamento de pacotes, e com a comunica¸cão entre os vizinhos.

Discovery Agent

O módulo Discovery Agent é responsável pela descoberta de nós vizinhos, ou seja, gera eventos relacionados com a descoberta e o desaparecimento de vizinhos. Quando é detectado um novo vizinho, o módulo Base Router verifica se existe algum pacote para ser transferido para este vizinho, caso exista envia-o.

Connection Manager

O Connection Manager é o módulo responsável por gerir os protocolos de n´ıvel inferior usados pelo IBR-DTN para comunicar com outros nós. Os protocolos de n´ıvel inferior usados para estabelecer uma conexão entre nós DTN são chamados de Convergence Layer Adapters, estando estes implementados como módulos na arquitectura do IBR-DTN. Assim, através destes módulos é poss´ıvel transferir pacotes entre nós. O IBR-DTN possui quatro convergence layers:

• O TCPCL usa o mecanismo de handshake entre os diferentes n´os DTN e tem a capaci-dade de dividir os pacotes em fragmentos, sendo estes reconhecidos nos n´os receptores. • O UDPCL permite uma maneira simples de trocar pacotes utilizando o protocolo UDP.

O tamanho máximo dos pacotes é limitado pelo tamanho máximo dos pacotes UDP. • O HTTPCL é baseado no libcurl [26] e usa um servidor HyperText Transfer Protocol

(HTTP) para enviar e receber pacotes.

• O LowPANCL suporta o protocolo IEEE 802.15.4 MAC [27] e ´e tipicamente usado em redes de sensores.

Base Router

O Base Router é responsável por gerir os vários módulos de encaminhamento, podendo es-tes operar em simultâneo. Este módulo recebe através do Discovery Agent informa¸cões sobre novos vizinhos e é informado sempre que chegam novos pacotes. Quando um módulo de enca-minhamento pretende enviar um pacote, este solicita ao Connection Manager a convergence layer mais adequada para o enviar. O IBR-DTN inclui vários módulos de encaminhamento:

• Static: Todas as rotas e caminhos são configurados no in´ıcio da execu¸cão e é assumido que eles estão sempre dispon´ıveis.

• Epidemic: Todos os nós transmitem constantemente todas as mensagens para todos os nós que encontra caso ainda não tenham as mensagens. Uma descri¸cão mais completa deste protocolo de encaminhamento é apresentada na Seçcão 2.4.1.

(41)

• Neighbor : Os pacotes s˜ao enviados para os vizinhos descobertos pelo Discovery Agent no momento da decis˜ao.

• Retransmission: Este módulo é responsável por erros de sinaliza¸cão ocorridos durante a transmissão de um pacote. Quando ocorre um erro de transmissão, o pacote permanece armazenado para posterior retransmissão. Existem dois tipos de erros, permanentes e temporários. Um pacote é retransmitido somente se o erro for temporário.

• PRoPHET: Uma descri¸cão mais completa do protocolo Probabilistic Routing Protocol using History of Encounters and Transitivity (PRoPHET) é apresentada na Seçcão 2.4.3. Bundle Storage

O Bundle Storage é o módulo capaz de armazenar pacotes por longos per´ıodos de tempo. Este módulo oferece uma interface para armazenar e recuperar pacotes por diferentes critérios de pesquisa, por exemplo pelo ID do pacote. Existem três tipos de armazenamento de pacotes: • Memory: Este tipo de memória é um armazenamento volátil em que todos os pacotes são armazenados na Random Access Memory (RAM) e é o tipo de armazenamento padrão no IBR-DTN. Um limite de tamanho máximo pode ser definido, tipicamente limitado pelo sistema operativo.

• File Based Storage: Neste caso os pacotes s˜ao armazenados persistentemente (por exem-plo, num disco r´ıgido) e permanecem armazenados mesmo se o dispositivo estiver des-ligado.

• SQLite: Esse tipo de armazenamento depende de uma base de dados SQLite 9 _{e pode} ser ´util para os m´odulos de encaminhamento mais complexos.

Wall Clock

O Wall Clock estabelece um relógio global para ser usado pelo IBR-DTN. Este módulo fornece um evento de tempo global que é enviado a todos os outros módulos através do Event Switch. Este evento é também usado por módulos simples para iniciar tarefas.

IBR-DTN API

O IBR-DTN fornece uma Application Programming Interface (API) baseada em sockets, a IBR-DTN API. A interface pode ser um TCP socket para estabelecer comunica¸cão através de diferentes máquinas, ou um Unix Domain Socket, para ser usado localmente. O IBR-DTN fornece uma biblioteca para ser ligada a aplica¸cões a fim de simplificar a cria¸cão de pacotes. 2.3.3.3 mOVE

O mOVE é um software de DTN desenvolvido e implementado pelo grupo de investiga¸cão Network Architectures and Protocols (NAP) 10. A linguagem de programa¸cão utilizada foi C/C++ e o software foi projectado para ser modular e extens´ıvel. O mOVE suporta comunica-¸

cões usando o padrão de referência IEEE 802.11p e protocolos Wireless Access in Vehicular Environments (WAVE), além da tecnologia Wi-Fi convencional, IEEE 802.11a/b/g.

9

https://www.sqlite.org/

(42)

Arquitectura

A Figura 2.9 apresenta uma visão geral da arquitectura do mOVE. Esta é composta por seis módulos: Neighboring, Socket, API Management, Storage, RX e Routing. Cada um deles é responsável por implementar e executar um conjunto de fun¸cões necessárias para o correcto funcionamento da DTN. Para executar as suas fun¸cões, os módulos podem interagir entre si através de Inter Process Communication (IPC) sockets, e um nó pode trocar pacotes com outros nós usando o protocolo de transporte UDP.

De seguida, é feita uma breve descri¸cão de cada módulo.

Figura 2.9: Arquitectura do mOVE, baseado em [28]

(43)

O módulo Socket é uma camada de abstraçcão para enviar/receber pacotes de/para nós vizinhos e gere o acesso a um UDP socket.

• M´odulo RX

O módulo RX possui uma thread interna que verifica constantemente se foi recebido algum pacote no UDP socket. Quando recebe um pacote, o módulo RX analisa-o e classifica-o de acordo com as suas flags, o Endpoint Identifier (EID) do destino e/ou o serviceID. Após esta classifica¸cão, o módulo encaminha os pacotes de anúncios de vizinhos para o módulo Neighboring e os restantes para o módulo de Routing.

• M´odulo Neighboring

Este é o módulo responsável pela descoberta dos vizinhos de um nó. Cada nó envia pe-riodicamente um pacote de anúncio de vizinho a anunciar a sua presen¸ca. Quando um nó recebe um pacote de anúncio de vizinho actualiza as suas tabelas internas com a in-forma¸cão do novo vizinho: EID, IP, tipo (por exemplo WiFi) e o porto de comunica¸cão.

´

E poss´ıvel operar com diferentes tipos de nós vizinhos dependendo da interface de co-munica¸cão utilizada, sendo que o mOVE suporta Wi-Fi, WAVE, interfaces de Ethernet e rotas estáticas (Figura 2.10).

Figura 2.10: Classes do m´odulo Neighboring [28]

• M´odulo Storage

Este módulo é responsável pelo armazenamento de pacotes dos nós, isto é, é respon-sável por manter os pacotes de dados juntamente com as informa¸cões necessárias para encaminhá-los para um vizinho. De um modo geral, os métodos mais importantes en-volvem armazenar/retirar (push e pull ) um pacote na/da storage; verificar o EID de destino e obter uma cópia do pacote (peek ), serviceID ou tempo de expira¸cão; e remo-ver e consultar a existência de um pacote espec´ıfico da storage. Este módulo também contém dois sub-módulos, StorageRAM e StorageDisk.

A StorageRAM implementa na memória quatro tabelas de informa¸cões para consultas rápidas, sendo estas as seguintes:

– Tabela Expiry: Pacotes ordenados por tempo restante at´e a expira¸c˜ao. – Tabela onHold : Pacotes ordenados por tempo onHold.

– Tabela Own: Pacotes ordenados por service ID, não destinados a encaminhamento para outros nós pois são destinados ao próprio.

– Tabela noData: Pacotes ordenados por tempo de expira¸c˜ao, conhecidos na rede, mas nenhum dado ´e armazenado.

(44)

A StorageDisk tem várias fun¸cões: gere o armazenamento de pacotes em disco, executa opera¸cões de leitura e escrita para obter pacotes, e usa as tabelas da StorageRAM para optimizar o seu desempenho. A Figura 2.11 ilustra a organiza¸cão deste módulo.

Figura 2.11: Organiza¸c˜ao da Storage [28]

• M´odulo de Routing

O módulo de Routing é responsável por decidir quais os pacotes que devem ser enviados, para qual vizinho e quando os deve enviar. O encaminhamento é feito de uma forma h´ıbrida, ou seja, por vizinho e pelo tipo do pacote. A primeira decisão de encaminha-mento é baseada no tipo do pacote (dados ou controlo), sendo esta feita no módulo RX. Mas todo o processo seguinte depende do tipo do nó, como se pode observar na Figura 2.12. Para enviar um pacote, o nó deve verificar se tem vizinhos dispon´ıveis e seleccionar um (ou mais) para o enviar.

Os tipos de nós existentes são: WiFi endpoint tipicamente sensores ou enpoints, servidor (Server ), Road Side Unit (RSU) e On Board Unit (OBU). Como estes tipos de nós foram implementados tendo em conta uma rede veicular, neste trabalho serão implementados novos tipos de nós para os cenários de drones aquáticos, descritos na Seçcão 4.3.

Figura 2.12: Classes do m´odulo Routing [28]

• M´odulo API Management

Um nó mOVE interage com aplica¸cões externas através do módulo API Management. Este módulo usa UNIX sockets Datagram Communications para gerir mensagens de con-trolo e de dados entre o mOVE e as aplica¸cões do mesmo (mOVE Apps). As mensagens IPC são usadas para separar as mensagens de controlo das mensagens de dados. Este módulo tem uma thread para tratar os pacotes das mOVE Apps através da API socket, e cria uma camada de abstraçcão para enviar/receber pacotes para/da API. Além disso, gere o acesso das mOVE Apps ao mOVE (registo e cancelamento do registo). Tem ainda uma thread auxiliar responsável por recolher os próprios pacotes do módulo Storage.

(45)

Existe um conjunto de mOVE Apps que j´a foram desenvolvidas e testadas, como mO-VEPing, mOVESend-String/mOVERecvString, mOVESendFile/mOVEInbox e mOVE-Monitor /mOVECollectmOVE-Monitor.

Estrutura dos pacotes

A camada de bundle é implementada sobre a camada de transporte, tal como é sugerido na especifica¸cão de referência de DTN, Request for Comments (RFC) 4838 [29]. No entanto, a implementa¸cão do mOVE não segue estritamente a especifica¸cão de referência do protocolo de bundle descrito na RFC 5050 [24]. A principal diferen¸ca está relacionada com os pacotes, que neste caso são chamados mOVE Packets. Segue uma breve descri¸cão da estrutura do pacote (ver Figura 2.9):

• Cabe¸calho do mOVE (mOVE Header ): – Vers˜ao do mOVE

– Tipo de servi¸co

– EIDs da origem (srcEID) e do destino (dstEID) – EID do vizinho anterior (prevEID)

– Hash (identificador único para um pacote) – Data de expira¸cão (tempo de cria¸cão + vida útil) – Tamanho da informa¸cão útil (dados)

– Tamanho das op¸c˜oes – Prioridade

– N´umero actual de vizinhos que receberam o pacote – Flags para identificar o tipo de pacotes

• Op¸c˜oes:

Este é um campo opcional, as op¸cões podem ser adicionadas mais tarde (por exemplo, lista de vizinhos que já receberam o pacote)

• Payload :

Matriz de bytes com um máximo de 32 KB (se as op¸cões foram adicionadas, o tamanho máximo deste campo diminuirá)

Configura¸c˜ao

A configura¸cão do mOVE é feita usando um ficheiro JavaScript Object Notation (JSON) 11 _{que ´}_{e lido e analisado no in´ıcio da execu¸}_c˜_{ao. Este ficheiro cont´}_{em v´}_{arias configura¸}_c˜_{oes tais} como a capacidade de armazenamento e o caminho, o EID do nó, nome das interfaces de comunica¸cão, a versão do routing, entre outras. Na Figura 2.13 encontra-se um exemplo de configura¸cão.

Fluxograma operacional

(46)

Figura 2.13: Exemplo de configura¸c˜ao do mOVE

Como se pode observar na Figura 2.14 o mOVE é um software multi-thread composto por vários módulos a correrem simultaneamente. Antes de iniciar todas as threads de cada módulo, é analisado o ficheiro de configura¸cão (Figura 2.13). Assim, à medida que o ficheiro é lido, os módulos são criados e inicializados. Uma vez que todas as threads foram iniciadas, o mOVE é executado até que um sinal externo seja enviado.

Figura 2.14: Fluxograma operacional do mOVE [28]

2.3.3.4 Compara¸c˜ao entre as diferentes implementa¸c˜oes de DTN

Nesta seçcão foram apresentadas algumas das implementa¸cões de DTNs mais comuns. As primeiras implementa¸cões apresentadas foram projectadas para serem usadas numa gama

(47)

ampla de dispositivos e plataformas, pelo que o seu uso não é optimizado para ambientes espec´ıficos como uma rede de drones aquáticos. De forma a superar esta caracter´ıstica e obter uma implementa¸cão de DTN capaz de se ajustar às necessidades de ambientes espec´ıficos, o grupo de investiga¸cão NAP desenvolveu uma nova solu¸cão chamada mOVE. O mOVE foi inicialmente projectado para redes veiculares, no entanto, como é uma implementa¸cão inicial é poss´ıvel melhorar e optimizá-la para ambientes espec´ıficos de drones aquáticos, sendo por este motivo seleccionado para ser utilizado neste trabalho. O Cap´ıtulo 4 descreve as melhorias e modifica¸cões necessárias para o seu funcionamento na rede de drones aquáticos considerada.

2.4 Protocolos de Encaminhamento

O encaminhamento é o processo que escolhe o caminho para enviar informa¸cões para um destino na rede. Tipicamente, a ideia é ter um algoritmo a correr nos nós capaz de seleccionar o melhor caminho para o destino de cada nó [30]. O melhor caminho pode ser definido por um conjunto de factores, tais como: o caminho mais curto para o destino, o caminho mais seguro, o caminho mais rápido para entregar dados, etc. Existem muitos algoritmos de encaminhamento, alguns precisam de mais informa¸cões sobre a rede para operar bem e outros precisam de menos, contudo nem todos os algoritmos são adequados para todos os tipos de rede. O foco principal desta seçcão será o encaminhamento em DTNs.

De seguida s˜ao descritos protocolos de encaminhamento aplicados a DTNs: Epidemic e Spray and Wait que foram estudados em ambientes de comunica¸c˜ao mar´ıtima por [31], PRoPHET, MaxProp e Resource Allocation Protocol for Intentional DTN (RAPID).

2.4.1 Epidemic

O Epidemic [32] é um protocolo de encaminhamento onde todos os nós transmitem cons-tantemente todas as mensagens para todos os nós que encontra caso ainda não tenham as mensagens. O principal objectivo é maximizar a taxa de entrega e minimizar o atraso end-to-end, considerando que os nós da rede têm uma memória infinita e o tempo de contacto entre nós é longo o suficiente para a transmissão completa. Contudo, estas considera¸cões não são necessariamente verdade pois os nós continuam a enviar as mensagens mesmo quando já foram recebidas no destino. Assim, este processo consome muitos recursos ao longo da rede, sendo o principal a memória.

A Figura 2.15 ilustra um exemplo do processo de encaminhamento do Epidemic. Os c´ırculos a lilás representam os nós móveis e os c´ırculos a picotado representam o alcance das suas comunica¸cões Wi-Fi. Na Figura 2.15 (a), o nó origem S pretende enviar uma mensagem para o destino D mas não existe nenhum caminho dispon´ıvel entre estes dois nós. Assim, o nó S vai enviar a mensagem para os vizinhos que estão no seu alcance, C1 e C2. Mais tarde (Figura 2.15 (b)), verifica-se que os nós C1 e C2 se moveram, estando o nó C2 no alcance de comunica¸cão do nó C3 é enviada a mensagem para o nó C3. Como o nó C3 está no alcance de comunica¸cão do nó D, a mensagem é finalmente entregue ao destino.

O Epidemic implementa o mecanismo de Summary Vectors (SVs) para limitar o número de mensagens transferidas. Um SV contém uma representa¸cão compacta das mensagens armazenadas num certo nó. Por exemplo, na Figura 2.16 o nó A encontra o nó B. O nó A em vez de enviar as suas mensagens, vai enviar um SV que contém uma lista compacta das suas mensagens (1). O nó B analisa o SV recebido e em resposta vai transmitir um vector de

(48)

Figura 2.15: Exemplo do protocolo Epidemic [32]

mensagens que não contém (2). Finalmente, o nó A recebe este vector e transmite apenas as mensagens que faltam ao nó B (3).

Figura 2.16: Exemplo de mensagens trocadas no protocolo Epidemic [32]

Uma vez que a maioria dos dispositivos tem recursos limitados e o Epidemic desperdi¸ca bastante memória e largura de banda, pode ser aconselhável usar outras técnicas de enca-minhamento. Contudo, em algumas circunstâncias e cenários, esta pode ser a única op¸cão viável para uma entrega bem sucedida dos dados.

2.4.2 Spray and Wait

O Spray and Wait [33] é um protocolo de encaminhamento simples mas eficiente, dese-nhado com o objectivo de aumentar a taxa de entrega limitando o número de cópias por mensagem permitidas na rede. O Spray and Wait consiste em duas fases: a fase spray e a fase wait.

Durante a fase spray, quando uma mensagem é gerada num nó origem, este nó é respon-sável por distribuir uma cópia para L nós distintos. Quando um nó recebe uma cópia, este come¸ca a fase wait, ou seja, o nó mantém a mensagem até encontrar directamente o destino e ser poss´ıvel enviá-la. Este mecanismo gera L cópias da mensagem, que é o máximo de cópias permitidas na rede.

Por exemplo, na Figura 2.17 o nó F encontra-se na fase spray uma vez que pretende enviar uma mensagem para o nó D. Inicialmente, no instante t+t0o nó F é responsável por distribuir

(49)

uma cópia para 4 nós distintos (L = 4). No instante t + t1 encontra o nó X a quem envia uma cópia, assim o nó X come¸ca a fase wait e o nó F fica com 3 cópias para distribuir. Por fim, no instante t + t2 o processo repete-se para o nó W, no entanto como o nó X encontra o nó destino D irá enviar-lhe a respectiva mensagem.

Figura 2.17: Exemplo do protocolo Spray and Wait, baseado em [34]

2.4.3 PRoPHET

O PRoPHET [35] [36] considera que a maioria dos nós não se movimentam de uma forma completamente aleatória, isto é, existem padrões previs´ıveis nos seus movimentos. Se um nó visitou com frequência um certo local, é provável que ele visite esse local novamente. Esta informa¸cão é utilizada para melhorar o desempenho do encaminhamento. Assim, o PRoPHET define uma métrica probabil´ıstica chamada delivery predictability, P_(A,B) ∈ [0, 1], que indica a probabilidade de um determinado nó A entregar uma mensagem a um outro nó B.

O mecanismo do PRoPHET é bastante semelhante ao do Epidemic (Figura 2.16), isto é, quando dois nós se encontram trocam entre si SVs que contêm as informa¸cões de delivery predictability armazenadas nos nós. Essas informa¸cões são usadas para actualizar o vector interno de delivery predictability. O summary vector é usado para decidir quais os pacotes que serão trocados entre os dois nós com base na estratégia de encaminhamento usada. O cálculo da delivery predictability é dividido em três etapas:

• A primeira etapa consiste em actualizar a métrica delivery predictability sempre que é encontrado um nó. Esta cálculo é apresentado na Equa¸cão 2.1, onde o Pinitcorresponde a uma constante inicial entre o intervalo [1, 0].

P(A,B)= P(A,B)old+ (1 − P(A,B)old) × Pinit (2.1)

• A segunda etapa ocorre quando dois n´os n˜ao se encontram durante algum tempo, o que significa que a probabilidade de trocarem mensagens entre eles vai diminuir. Assim, a

(50)

métrica delivery predictability deve diminuir como é mostrado na Equa¸cão 2.2, onde γk ´

e a constante que permite reduzir a delivery predictability e k é o número de unidades de tempo que passou desde a última vez que a métrica foi reduzida. A unidade de tempo deve ser definida de acordo com a aplica¸cão e os atrasos esperados na rede.

P_(A,B)= P_(A,B)_old× γk _(2.2)

• A terceira etapa é relativa a uma propriedade transitiva que se baseia no seguinte: se um nó A encontra frequentemente um nó B e o nó B encontra frequentemente um nó C, provavelmente o nó B é um bom nó para encaminhar pacotes entre os nós A e C. Na Equa¸cão 2.3 pode-se observar o impacto da transitividade na métrica delivery predictability, onde β ∈ [0, 1] é a constante que controla esse impacto.

P(A,C)= P(A,C)old+ (1 − P(A,C)old) × P(A,B)× P(B,C)× β (2.3)

Para uma melhor compreensão do mecanismo de encaminhamento do PRoPHET, a Fi-gura 2.18 apresenta um exemplo da propriedade transitiva na métrica delivery predictability e da opera¸cão básica do PRoPHET. Na Figura 2.18 é ilustrado um cenário onde o nó A contém um pacote cujo destino é o nó D. Nas Figura 2.18 a) e b) são apresentadas para cada nó a tabela de delivery predictability. Supondo que os nós C e D se encontram com alguma frequência, na Figura 2.18 a) isso implica que os valores de delivery predictability que têm um com o outro vão ser altos. Supondo que o nó C também encontra frequentemente o nó B, os seus valores de delivery predictability também vão ser elevados, como se pode ver na Figura 2.18 c). Assim, a propriedade transitiva vai aumentar o valor que o nó B tem para o nó D para um valor intermédio. Finalmente, o nó B encontra o nó A que tem um pacote para o nó D (Figura 2.18 c)). A Figura 2.18 d) mostra a troca dos SVs e as informa¸cões de delivery predictability entre o nó A e o nó B. Após o nó A verificar que o nó B não contém o pacote e que P(B,D) > P(A,D), é enviado o pacote do nó A para o nó B.

2.4.4 MaxProp

O MaxProp [38] é um protocolo baseado em flooding mas cai na categoria de protocolos baseados em replica¸cão. Este protocolo utiliza vários mecanismos que trabalham em conjunto para aumentar a taxa de entrega e diminuir a latência dos pacotes entregues no destino. O MaxProp é capaz de determinar quais os pacotes que devem ser transmitidos primeiro pois possui uma fila ordenada com base no destino de cada pacote. Assim são transmitidos os pacotes para outros nós numa ordem espec´ıfica que tem em conta o número de saltos e a probabilidade de entrega com base em encontros anteriores. Por exemplo, quando dois nós se encontram, trocam entre si a probabilidade estimada desse encontro, e com base nesta informa¸cão e no número de saltos, o nó pode então calcular um caminho mais curto para o destino. Além disso, este protocolo informa os seus vizinhos para eliminar as cópias dos pacotes entregues no destino através de acknowledgments enviados em broadcast para toda a rede.

(51)

Figura 2.18: Exemplo do protocolo PRoPHET [37]

2.4.5 RAPID

O RAPID [39] é um protocolo de encaminhamento baseado em replica¸cão que permite optimizar uma métrica de encaminhamento especificada, como por exemplo a latência de entrega do pior caso ou o número de pacotes que são entregues dentro de um determinado prazo. Para conseguir isso é usada uma variável aleatória para representar o encontro entre dois nós e são propagadas mensagens através da rede com essa informa¸cão. O envio dessas mensagens depende da sua utilidade marginal. A utilidade marginal é calculada usando uma fun¸cão de utilidade que se baseia na rela¸cão entre o tamanho da mensagem e o atraso m´ınimo da entrega no destino. Após isto, apenas as mensagens com uma utilidade marginal positiva são replicadas na rede. Assim, também este protocolo é baseado em replica¸cão onde a replica¸cão é controlada pela utilidade marginal.

2.4.6 Compara¸c˜ao entre os diferentes protocolos de encaminhamento

Alguns protocolos abordados nesta seçcão não têm conhecimento total da rede, têm con-sumos de recursos elevados e sobrecarregam a rede quando trocam informa¸cões acerca da mesma. Quanto ao processo de encaminhamento estes protocolos adoptam estratégias basea-das em flooding e replica¸cão, o que leva à existência de muitos pacotes redundantes na rede e a sobrecarga da mesma. Para combater a sobrecarga da rede e consumo de recursos elevados é proposta uma estratégia com base na qualidade das liga¸cões (Seçcão 3.4.3), que selecciona a informa¸cão que é enviada nas tabelas de encaminhamento com base no destino (gateways). Além disso, apenas os nós que não são gateways irão enviar essa informa¸cão. Assim esta estra-tégia tem um conhecimento mais abrangente da rede até à gateway não se limitando apenas

(52)

ao conhecimento dos vizinhos que estão a um salto. Uma vez que o mOVE se encontra numa fase inicial de implementa¸cão para cenários de drones aquáticos, como referido anteriormente, torna-se poss´ıvel ter um conhecimento global de toda a implementa¸cão existente. Por estes motivos consegue-se ter um maior controlo sobre as decisões de envio e recep¸cão dos pacotes na DTN caso sejam desenvolvidas estratégias na mesma.

2.5 Considera¸

c˜

oes do Cap´ıtulo

Neste cap´ıtulo foram apresentados cenários de aplica¸cões dos drones e exemplos de drones aquáticos, onde se observa que existem aspectos a serem melhorados tanto a n´ıvel de software como hardware, assim como a n´ıvel da comunica¸cão entre eles. De seguida, foram apresentadas as redes tolerantes a atrasos, o mOVE e exemplos de protocolos de encaminhamento aplicados a DTNs.

O próximo cap´ıtulo apresenta o problema das comunica¸cões sem fios (Wi-Fi) entre os drones aquáticos, o conceito de qualidade da liga¸cão, e são propostas três estratégias de encaminhamento implementadas no mOVE. Por fim será apresentada a arquitectura proposta para cada drone.

(53)

Cap´ıtulo 3

Comunica¸

c˜

oes entre Drones

Aqu´

aticos

3.1 Descri¸

c˜

ao do Cap´ıtulo

Neste cap´ıtulo será descrito o problema das comunica¸cões sem fios (Wi-Fi) entre os drones aquáticos. De seguida será apresentado um conceito de qualidade da liga¸cão e propostas três estratégias, implementadas numa DTN, para encaminhar a informa¸cão de sensores num cluster de drones. Por fim será apresentada a arquitectura de cada drone onde será descrito o módulo Drone Quality Connection (DQC) e a respectiva integra¸cão com a DTN e o módulo de controlo do drone.

3.2 Problema

A Figura 3.1 apresenta um exemplo de um cenário de monitoriza¸cão do mar com drones aquáticos. Como se pode observar os drones são organizados por clusters comunicando entre si através da tecnologia Wi-Fi. Dentro de cada cluster existe um ou mais drones com capacidade de comunicar a longo alcance, designados por gateways. Cada gateway tem capacidade de comunicar por Wi-Fi dentro do cluster, utilizando por exemplo a tecnologia LoRa ou rede celular para comunica¸cão com outros clusters ou esta¸cões fixas em terra. Caso um drone sem capacidade de comunicar a longo alcance se afaste de um cluster, a liga¸cão da comunica¸cão fica fraca sendo necessário agir de forma a voltar para o alcance do cluster.

A comunica¸cão entre drones tem uma importância crucial para que a missão dentro de um cluster de drones seja bem sucedida (por exemplo, monitoriza¸cão de uma certa área). Esta comunica¸cão é importante para que, sempre que poss´ıvel, nenhum drone saia do alcance de, pelo menos, um outro drone (drone mais à esquerda na Figura 3.1), e por sua vez, que a informa¸cão recolhida pelos seus sensores circule dentro do cluster de forma eficiente até chegar a um drone com a capacidade de comunicar com um outro cluster (gateways na Figura 3.1) ou directamente com uma esta¸cão fixa em terra, sendo este o objectivo primordial dos drones. Uma primeira abordagem para esta comunica¸cão, implementada por [40], é a utiliza¸cão de uma rede sem fios ad-hoc baseada em IEEE 802.11g (Wi-Fi). Todo o tipo de mensagens trocadas, controlo ou dados, é feita em broadcast. Nesta abordagem nenhum drone tem conhecimento do estado da rede enquanto está a executar as suas tarefas. Isto implica que, se um drone deixar de ter comunica¸cão com os seus vizinhos, pode estar isolado, e ao se

(54)

Figura 3.1: Cenário de monitoriza¸cão do mar com drones aquáticos

aperceber disso, pode já ser tarde e não conseguir voltar a entrar em contacto com outros drones do cluster (liga¸cão vermelha na Figura 3.1). Para prevenir este tipo de situa¸cões é proposto um mecanismo que calcula a qualidade das liga¸cões (Seçcão 3.3) entre um drone e os seus vizinhos e reporta esses valores periodicamente ao mecanismo de controlo do drone. Assim, o drone é alertado antecipadamente que se poderá estar a afastar, tendo uma menor probabilidade de se perder.

O encaminhamento da informa¸cão (dados de sensores, por exemplo temperatura da água) na rede também não tem qualquer tipo de inteligência e/ou mecanismos que tratem de dis-rup¸cões e persistência da informa¸cão, ou seja, todos os drones enviam esta informa¸cão em broadcast. Isto pode levar à circula¸cão de muito tráfego na rede. Existe também a preo-cupa¸cão das inúmeras reflexões na água e a consequente perda de informa¸cão. De forma a optimizar este processo são propostas estratégias de encaminhamento (Seçcão 3.4), imple-mentadas numa DTN, que consideram a informa¸cão fornecida pelo mecanismo de cálculo da qualidade da rede para identificar o melhor vizinho ao qual será enviada a respectiva infor-ma¸cão, reduzindo assim o tráfego a circular na rede e a possibilidade de perda da informa¸cão, assim como a perda de conectividade com a rede (liga¸cões Wi-Fi na Figura 3.1).

3.3 Qualidade da Liga¸

c˜

ao

A qualidade da liga¸cão, nesta disserta¸cão, é definida como uma variável adimensional, que tem como objectivo descrever a capacidade que a liga¸cão entre dois nós tem em trocar dados de forma eficiente em redes sem fios. Para medir a qualidade é necessário definir e usar métricas numéricas, tendo estas uma rela¸cão qualitativa com a qualidade das liga¸cões. São consideradas três métricas: o Signal Strength Intensity (SSI), a estabilidade da liga¸cão e a largura de banda dispon´ıvel.

• O SSI é a diferen¸ca entre a potência de sinal medida na antena receptora e uma dada referência. Tem como unidade o dBm que se expressa pela potência absoluta mediante uma rela¸cão logar´ıtmica, isto é, define-se como o n´ıvel de potência em decibéis em