Detecção de intrusões em operações de segurança com base em Redes de … · Detecção de...

Detecção de intrusões em operações desegurança com base em Redes de Sensores

sem fios

Pedro Lopes da Costa Louro de Almeida

Dissertação para obtenção do Grau de Mestre em

Engenharia Electrotécnica e de Computadores

Júrí

Presidente: Profa Dra Isabel Maria Silva Nobre Parreira Cacho Teixeira

Vogal: Prof. Dr. Renato Jorge Caleira Nunes

Orientador: Prof. Dr. António Manuel Raminhos Cordeiro Grilo

Co-Orientador: Prof. Dr. Mário Sera�m dos Santos Nunes

Dezembro 2007

Detecção de intrusões em operações de segurança combase em Redes de Sensores sem fios

Pedro Lopes da Costa Louro de Almeida

Documento produzido a partir dos �cheiros LATEX originais do autor

iii

Agradecimentos

Gostaria de agradecer ao Professor António Grilo e ao Professor Mário Sera�m Nunes pelo apoio

e ajuda prestados a favor do bom desenvolvimento deste projecto, assim como a disponibilidade

do material necessário para a realização do mesmo. Agradeço também a oportunidade dada de

ter levado este trabalho, ainda que numa forma bastante primária, ao 4o Seminário da RTCM

em 2006, no Porto, uma experiência muito interessante.

Queria também salutar a compreensão da minha família e amigos, por todo o tempo que

não lhes pude dar durante a realização deste projecto, e a todas as pessoas que, directa ou

indirectamente, contribuíram de alguma forma para a sua produção, entre eles David Gay, Fer-

nanda Esteves, Filipe Lourenço, Guilherme de Almeida, João Pequenão, Luís Mendes, Marisa

Rodrigues, Nuno Oliveira, Philip Levis, Sandra Martins, Sara Nunes, Steve McKown e Vera

Tavares.

v

Resumo

Neste trabalho é implementada uma rede sem �os de sensores que inclui funcionalidades de

encaminhamento de pacotes entre os nós da rede. Estes nós possuem sensores para detecção

de movimento, distribuindo quaisquer alarmes detectados para uma Gateway local. A partir

dela, os dados serão feitos chegar, através de tecnologia complementar de longo alcance, a

um Servidor remoto. Os nós comunicam entre si através de uma tecnologia RF especialmente

desenvolvida para redes sensoriais, Zigbee, devido ao seu baixo custo, baixo tempo de resposta

e baixo consumo de energia (ideais para uma rede de sensores que se pretende funcional durante

muito tempo), aliados a um alcance satisfatório (≈100 m).Os nós disseminam informação dentro da rede usando um algoritmo de encaminhamento

especí�co para redes sensoriais, nativamente embutido no sistema operativo que corre nos mó-

dulos da rede. Esta possui ainda capacidades de adaptação a alterações da sua topologia (e.g.

alterações devidas a vandalismo, mau funcionamento de um nó, mudanças de posição, etc.).

Além dos módulos, podem ainda participar na rede terminais PDA, que têm capacidade de

adquirir informação a partir dela, quer vinda do Servidor, quer localmente, se equipados com

um nó Mica Z.

Nos PDAs corre uma aplicação de Percepção da Situação Operacional (PSO) que possibilita,

em tempo real, o acesso a um mapa sobre o qual se apresenta informação de posicionamento

de outros terminais PDA ligados à rede, assim como os sensores cuja posição é conhecida.

Foram desenvolvidos independentemente as quatro componentes descritas acima: a rede

sensorial, a Gateway, o Servidor e a aplicação de PSO.

O sistema mostrou-se e�caz e resoluto, mostrando que as tecnologias existentes são já e�-

cazes e �áveis. Com o avançar do tempo, tarefas mais complexas e em maior número poderão

ser pedidas a redes deste tipo, tornando-as ainda mais operacionais e integradas em variados

cenários.

Palavras-chave

• Redes sensoriais

• Servidor

• Gateway

• Percepção de Situação Operacional

• Encaminhamento

vii

Abstract

In this project, a multi-hop wireless sensor network was implemented, which includes the capa-

bility of packet routing among the network's nodes. These nodes are equipped with sensors for

movement detection, broadcasting any triggered alarms to a local Gateway. From it, data will

be forwarded, through complementary long range technology, to a remote Server. Nodes com-

municate between themselves using a RF tecnhnology specially developed for sensor networks,

Zigbee, given its low cost, low response time and low energy consumption (ideal for a sensor

network that is intended to work by itself for long periods of time), together with a suitable

range (≈100 m).The nodes spread the information within the network using a routing algorithm speci�ally

developed for sensor networks, natively embedded in the operating system that runs within the

network modules (Mica Z). The former posesses also the ability to adapt to topology changes

(e.g. vandalism, node malfunction, position shifts, etc.). Besides the modules, PDA terminals

may also participate in the network, that have the ability to extract information from it, either

from the Server or from the network itself, if a network module is attached to the PDA.

In the PDA, a Situation Awareness application allows the real time access to a map over

which positioning information is presented, concerning other PDA terminals connected to the

network, as well as the sensor nodes whose position is known.

The following four components were independently developed for this work: the sensor

network, the Gateway, the Server and the Situation Awareness application.

The system was shown to be e�ective and resolute, demonstrating that the current tecnho-

logies can already be considered e�ective and reliable. In a few years, more and highly complex

tasks can be demanded from such networks, allowing them to be widely used in several scenarios

as fully functional and integrated systems.

Keywords

• Sensor Networks

• Server

• Gateway

• Situation Awareness

• Routing

ix

Conteúdo

1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Requisitos e objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Organização da dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Redes sem �os ad-hoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Redes sem �os com nós móveis . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Redes em malha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 Redes sensoriais sem �os . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 Encaminhamento tradicional em redes . . . . . . . . . . . . . . . . . . . . 8

2.5 Encaminhamento em redes ad-hoc . . . . . . . . . . . . . . . . . . . . . . 10

2.6 Encaminhamentos usados em WSNs . . . . . . . . . . . . . . . . . . . . . 13

2.7 Encaminhamentos especialmente desenvolvidos para WNSs . . . . . . . . 14

3 Tecnologias e Equipamento utilizados . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Estado da arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Tecnologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3 Equipamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4 Linguagens e ambientes de desenvolvimento . . . . . . . . . . . . . . . . . 24

4 Arquitectura Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1 Cenário global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Segurança no sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.3 Opções em comunicações . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5 Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.1 Aproximação ao problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2 Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.3 Interface e Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.4 Base de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37


6.2 Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.3 Interacção entre sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.4 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7 Percepção da Situação Operacional . . . . . . . . . . . . . . . . . . . . . . . . . . 44


7.2 Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.3 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

8 Rede de Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

xi


8.2 Encaminhamento dentro da rede . . . . . . . . . . . . . . . . . . . . . . . 48

8.3 Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

8.4 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

8.5 Estrutura das mensagens . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

9 Mensagens de protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

9.1 Veri�cação de integridade . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

9.2 Estrutura e funcionamento de mensagens extra-rede sensorial . . . . . . . 54

9.3 Estrutura e funcionamento de mensagens intra-rede sensorial . . . . . . . 58

10 Medidas de desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

10.1 Alcance máximo entre dois nós . . . . . . . . . . . . . . . . . . . . . . . . 60

10.2 Cobertura de espaços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

10.3 Autonomia dos nós da rede . . . . . . . . . . . . . . . . . . . . . . . . . . 62

10.4 Interferências na banda 2.4Ghz . . . . . . . . . . . . . . . . . . . . . . . . 63

10.5 Desempenho do algoritmo CTP . . . . . . . . . . . . . . . . . . . . . . . . 66

10.6 Desempenho no sistema global . . . . . . . . . . . . . . . . . . . . . . . . 66

11 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Anexo 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Anexo 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

xii

Lista de Figuras

1.1 Redes de sensores aplicadas à prevenção de incêndios. . . . . . . . . . . . . . . . 1

1.2 Interligação dos diversos sistemas desenvolvidos neste projecto. . . . . . . . . . . 2

2.1 Rede em malha. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Redes sensoriais em cenários militares. . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Topologia numa rede auto-con�gurável. . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Estrutura hierárquica de rede. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5 Demonstração do algoritmo AODV. . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Escolha greedy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1 Camadas de�nidas pelo IEEE 802.15.4 e pela ZigBee Alliance. . . . . . . . . . . 18

3.2 Enquadramento do Zigbee versus outras tecnologias. . . . . . . . . . . . . . . . . 19

3.3 Mote MicaZ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4 Placas programadoras. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.5 Qtek 9090. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.6 Sensor de presença com mote Mica Z acoplado. . . . . . . . . . . . . . . . . . . . 24

4.1 Cenário geral da aplicação: as linhas a vermelho representam o trajecto dos

pacotes desde o nó que lança o alarme (marcado com um �!�)até chegar ao nó

sink, ligado à Gateway. As linhas a verde representam as comunicações entre

os Access Points e os PDAs. As linhas a azul representam as ligações entre as

Gateways espalhadas em diversos locais e o Servidor. . . . . . . . . . . . . . . . . 25

5.1 Ligação entre Servidor e diversas Gateways. . . . . . . . . . . . . . . . . . . . . . 32

5.2 Fluxo de dados dentro do Servidor. O VIM, que ocorre em todos os sistemas,

representa a Veri�cação de Integridade Mensagem: início, �m e checksum espe-

rados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.3 Janela da interface do Servidor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.4 Apresentação de um mapa com nós projectados. . . . . . . . . . . . . . . . . . . 35

5.5 Janela do Registo Histórico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.6 Diagrama de Base de Dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.1 Fluxo de dados na Gateway. O VIM, que ocorre em todos os sistemas, representa

a Veri�cação de Integridade Mensagem: início, �m e checksum esperados. . . . . 38

6.2 Exempli�cação de uma situação de troca de mensagens entre os três sistemas. . . 40

6.3 Interface utilizador da Gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7.1 Envio e recepção de mensagens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.2 Fluxo de dados na aplicação de PSO. O VIM, que ocorre em todos os siste-

mas, representa a Veri�cação de Integridade Mensagem: início, �m e checksum

esperados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.3 Interface de utilização da aplicação PSO. . . . . . . . . . . . . . . . . . . . . . . 46

xiii

7.4 Envio e recepção de mensagens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

8.1 Algoritmo CTP reagindo a uma quebra de ligação que provoca um loop dentro

da rede. Os números ao lado de cada ligação é o seu ETX, e o número dentro de

cada �nó�, o ETX desse nó. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

8.2 Fluxo de dados no nó central. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

8.3 Estrutura das tramas 802.15.4. [1]. . . . . . . . . . . . . . . . . . . . . . . . . . . 52

8.4 Conteúdo do MPDU [1]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

10.1 Resultado dos testes de alcance entre dois nós (domínio de utilização). . . . . . . 60

10.2 Distribuição espacial de nós numa rede para maximização de cobertura tendo

em conta o alcance. Este tipo de distribuição assegura que cada ponto está

coberto sempre por mais do que um nó (três, neste caso). Uma distribuição

mais simplista, como numa distribuição em matriz perfeita, criaria zonas sem

cobertura assim que um nó deixasse de funcionar, comprometendo diversas rotas. 62

10.3 Relação entre alcance e número de nós necessário para cobrir uma área de 1km2. 63

10.4 Autonomia da rede em função da capacidade das baterias e do consumo ener-

gético. Os grá�cos representam três duty-cycles diferentes, sendo o 0,13% o

correspondente a estra trabalhos e os restantes para efeito comparativo. . . . . . 64

10.5 Espectro de canais Zigbee e Wi-Fi. Representação XY de Energia versus Frequên-

cia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

10.6 Distribuição dos nós no teste realizado para medição de interferências. . . . . . . 65

10.7 Representação grá�ca dos dados da Tabela 1.4 no Anexo 2. Os identi�cadores

de nós referem-se àqueles observáveis na Figura 10.6. . . . . . . . . . . . . . . . . 65

10.8 Garantia de entrega para mensagens em massa chegadas ao Servidor vindas da

rede/PDA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

10.9 Tempo necessário ao Servidor, em segundos, para processar determinado número

de mensagens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

1.1 Esquema da arquitectura Zigbee . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

1.2 Dados que dão origem ao grá�co da Figura 10.4. . . . . . . . . . . . . . . . . . . 87

xiv

Lista de Tabelas

3.1 Comparação entre Zigbee e outros standards. . . . . . . . . . . . . . . . . . . . . 20

4.1 Modelo Internet (RFC 1122). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

8.1 Estrutura dos cabeçalhos CTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

8.2 Estrutura das tramas na porta de série. . . . . . . . . . . . . . . . . . . . . . . . 53

9.1 Exempli�cação do checksum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

9.2 Mensagem: Adicionar/Actualizar nó. . . . . . . . . . . . . . . . . . . . . . . . . . 55

9.3 Mensagem: remover nó. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

9.4 Mensagem: pedir dados de rede. . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

9.5 Mensagem: mensagens simples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

9.6 Mensagem: desligar conexão. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

9.7 Mensagem: Noti�ca Alarme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

9.8 Mensagem: Keep-Alive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

9.9 Trama de payload. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

9.10 Mensagem de alarme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

9.11 Mensagem de keep-alive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

1.1 Garantia de entrega para mensagens em massa chegadas ao Servidor vindas da

rede/PDA (Figura 10.8). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

1.2 Tempo necessário ao Servidor, em segundos, para processar determinado número

de mensagens (Figura 10.9). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

1.3 Relação entre alcance e número de nós necessário para cobrir uma área de 1km2

(Figura 10.3). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

1.4 Taxas de entrega no nó raiz para diferentes frequências de funcionamento Zigbee

(Figura 10.7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

1.5 Taxas de entrega e retransmissão de mensagens em função da distância entre

dois nós consecutivos (Figura 10.1). . . . . . . . . . . . . . . . . . . . . . . . . . . 86

xv

Lista de Siglas

ACQUIRE - ACtive QUery forwarding In sensoR nEtworks

AES - Advanced Encryption Standard

AODV - Ad-hoc On-Demand Distance Vector

AP - Access Point

BD - Base de Dados

CCMP - Counter-Mode�CBC-Mac Protocol

CDMA/CA - Code Division Multiple Access / Collision Avoidance

CGSR - Clusterhead-Gateway Switch Routing

CIEXSS - Centro de Inactivação de EXplosivos e Segurança em Subsolo

CKK - Complementary Code Keying

CMOS - Complementary Metal Oxide Semiconductor

COP - Common Operational Picture

CTP - Collection Tree Protocol

DD - Directed Di�usion

DHCP - Dynamic Host Dynamic Host Con�guration Protocol

DSDV - Destination Sequenced Distance Vector

DSR - Dynamic Source Routing

EAPM - External Attack Prevention Model

EEPROM - Electrically Erasable Programmable Read Only Memory

ETX - Expected Transmissions

FCS - Frame Check Sequence

GeoCast - Geographic Addressing and Routing

GOE - Grupo de Operações Especiais

GPRS - General Packet Radio Service

GPS - Global Positioning System

GPSR - Greedy Perimeter Stateless Routing

GSM - Global System for Mobile communication

IADM - Internal Attack Detection Model

IEEE - Institute of Electrical and Electronics Engineers

ISM - Industrial Scienti�c Medical

JTRS - Joint Tactical Radio System

LAR - Location Aided Routing

LEACH - Low Energy Adaptive Clustering Hierarchy

LED - Light Emission Diode MAC - Media Access Control

MANET - Mobile Ad-hoc NETwork

MFR - MAC Footer

xvii

MHR - MAC Header

MPDU - MAC Protocol Data Unit

MSDU - MAC Service Data Unit

NTDR - Near-Term Digital Radio

OFDM - Orthogonal Frequency-Division Multiplexing

PDA - Personal Digital Assistant

PHY - Physical Layer

PPDU - PHY Protocol Data Unit

PSDU - PHY Service Data Unit

PSO - Percepção de Situação Operacional

PSP - Polícia de Segurança Pública

RF - Radio Frequency

RISC - Reduced Instruction Set Computer

SHR - Synchronization Header

SIRESP - Sistema Integrado de Redes de Emergência e Segurança de Portugal

SPIN - Sensor Protocols for Information via Negotiation

SQL - Structured Query Language

SSID - Service Set IDenti�er

TCP/IP - Transmission Control Protocol / Internet Protocol

TETRA - TErrestrial Trunked RAdio

TKIP - Temporal Key Integrity Protocol

UDP - User Datagram Protocol

UMTS - Universal Mobile Telecommunications System

VANET - Vehicular Ad-Hoc NETworks

VPN - Virtual Private Network

WEP - Wired Equivalency Privacy

WiMAX - Worldwide Interoperability for Microwave Access

WPAN - Wireless Personal Area Networks

WRP - Wireless Routing Protocol

WSN - Wireless Sensor Network

ZRP - Zone Routing Protocol

xviii

1 Introdução

1.1 Contexto

Quer seja no âmbito de operações de protecção civil (e.g., combate a incêndios), segurança

pública (e.g., operações anti-terrorismo), monitorização de edifícios (e.g., termóstatos, medição

de vibração da estrutura, ruído, etc.) ou militares (e.g., detecção de movimento e actividades

hostis), a e�cácia e e�ciência da actuação das equipas tácticas no desempenho da sua missão

podem ser signi�cativamente melhoradas através da disseminação em tempo-real de informação

relativa à situação operacional (ou Common Operational Picture - COP). Tal informação pode

incluir, entre outras coisas, informação geográ�ca, posicionamento geográ�co dos elementos

da mesma equipa táctica (e.g. pessoal, sensores, veículos, etc.), informação de Comando e

Controlo (C2) (e.g. planos de actuação, ordens, informação logística, etc.), dados provenientes

dos sensores, etc.

Dado que estas operações podem ocorrer em locais de difícil acesso e em que pode não existir

à partida uma infra-estrutura de comunicações, a rede de comunicações da equipa táctica deve

ser auto-su�ciente, auto-con�gurável, robusta, �exível e suportar mobilidade, o que corresponde

às características de uma rede ad-hoc. Certo elementos de rede, como PDAs, por exemplo,

necessitam de uma infra-estrutura que permita assegurar as comunicações com �abilidade.

Recentemente, foi aprovado em Portugal um sistema de redes de emergência e segurança,

que dota todas as forças de segurança e serviços de emergência nacionais de um único sistema

integrado de comunicações: o SIRESP (Sistema Integrado das Redes de Emergência e Segurança

de Portugal). Este sistema, baseado em TETRA2, assegura comunicações de elevada qualidade,

possibilitando a todos os elementos que comuniquem entre si. Até agora, comunicações entre,

por exemplo, a PSP e a GNR eram apenas possíveis recorrendo à linha �xa ou ao telemóvel,

ambos com as suas limitações de acesso em cenários de emergência.

Figura 1.1: Redes de sensores aplicadas à prevenção de incêndios.

1

As redes de sensores constituem um caso particular de redes ad-hoc, juntando às caracterís-

ticas atrás mencionadas as limitações inerentes aos sensores autónomos: capacidade energética

limitada e baixa capacidade de processamento. Isto conduz à utilização de tecnologias de co-

municação desenhadas especi�camente para redes sensoriais (e.g. ZigBee), complementadas

com tecnologias de comunicação com maior alcance (e.g. TETRA, CDMA450, GSM/GPRS,

UMTS, etc.) que garantem que a informação recolhida pelos sensores é disseminada para partes

remotas da rede tais como Centros de Comando e Controlo.

Uma rede de sensores sem �os consiste num conjunto de dezenas, centenas ou mesmo mi-

lhares de nós de baixo custo que podem ser instalados em locais �xos ou, embora raramente,

sujeitos a movimentações. Os nós comunicam mutuamente utilizando um conceito multi-salto

(multi-hop). A informação pode ser pedida por um nó a outro em especí�co ou pode então ser

canalizada a nós principais da rede, normalmente referidos como sinks, que recolhem a infor-

mação global da rede. Estas estações estão ligadas a uma Gateway, que transmite a informação

recolhida até uma estação central (um Servidor) para posterior tratamento. Dado o elevado

processamento a que estas estações estão sujeitas, são normalmente constituídas por elementos

com elevada memória, capacidade de armazenamento, poder de computação e continuamente

alimentados (vulgarmente PCs).

Em certas situações pode ser vantajoso obter os dados provenientes da rede directamente

dela, sem passar pelo Servidor, que pode nem sempre estar acessível. Tal veri�ca-se em si-

tuações de alteração de topologia (mudar �sicamente a posição dos nós sem poder avisar o

Servidor) ou situações em que a intervenção no cenário seja directamente in�uenciável pelos

dados fornecidos pela rede (combate a incêndios e operações anti-terrorismo), pelo que é possí-

vel tornar disponíveis os dados de imediato, mediante a utilização de aplicações de Percepção

de Situação Operacional (PSO) a correr sobre dispositivos PDAs que se liguem às Gateways.

Servidor

��

��

HHHHH

HHHHHHH

Gateway 1

Rede de Sensores

��

��

@@@

PPPPPPP

Sensor Sensor Sensor Sensor

........ Gateway N

��

HHHH

Rede de Sensores

��

HHHHH

Sensor Sensor Sensor

PDA

Figura 1.2: Interligação dos diversos sistemas desenvolvidos neste projecto.

Foram resultado deste trabalho o desenvolvimento, integração e interligação dos vários sis-

temas acima descritos: Servidor, Gateways, rede sensorial e aplicação de PSO nos PDAs, tal

como representado, em situação exemplo, na Figura 1.2.

2

1.2 Requisitos e objectivos

O objectivo proposto para este trabalho foi o desenvolvimento de um protótipo para um sistema

integrado de monitorização de segurança em áreas sensíveis direccionado para apoio a Operações

da PSP (e.g., GOE/CIEXSS), assim como avaliações de desempenho e viabilidade. Este sistema

deve ser capaz de detectar a passagem de uma pessoa não autorizada num ambiente restrito e

comunicar a transgressão a um posto centralizado. Essa informação é armazenada num Servidor

que posteriormente distribui informação detalhada a componentes aplicacionais que os agentes

no terreno transportam (PDAs).

A detecção é feita recorrendo a sensores de movimento (presença) por infra-vermelhos, aco-

plados a módulos sem �os distribuídos espacialmente numa rede coesa e interligada, com a

capacidade de encaminhar quaisquer sinais de alarme até uma Gateway local. Esta Gateway

reencaminhará a informação que lhe chegue não só aos PDAs mas igualmente ao Servidor, e

ambos recebem estas actualizações em tempo real.

A rede deve ser auto-su�ciente, capaz de criar e reparar ligações consoante as eventuais

alterações de topologia que eventualmente sofra, como por exemplo a remoção ou mau funcio-

namento de um dos seus elementos.

1.3 Organização da dissertação

A presente dissertação está organizada em 11 Capítulos. Após este capítulo introdutório, serão

dados alguns conceitos simples sobre redes, dando especial foco as redes sensoriais, e serão

introduzidos tipos de encaminhamentos em redes sensoriais, com descrições sumárias de cada

um. Seguidamente, serão explicadas com mais detalhes as tecnologias presentes e como se

enquadram, assim como todo o material que é usado neste trabalho e o estado da arte. No

Capítulo 4 serão �nalmente apresentados e demonstrados, no seu todo, os sistemas envolvidos,

como se interligam, opções tomadas e preocupações de segurança, etc.

Nos quatro Capítulos seguintes (5, 6, 7 e 8) serão explicados em detalhe os quatros cons-

tituintes do sistema geral apresentado no Capítulo 2: o Servidor, a Gateway, a aplicação de

Percepção de Situação Operacional e a rede de sensores. Segue-se um capítulo onde é apresen-

tado o protocolo de mensagens, onde são descritos os constituintes de todas as mensagens que

circulam no sistema e como se enquadram nos diversos sistemas.

Finalmente, nos dois últimos capítulos, são analisadas as medidas de desempenho do sistema

e os resultados obtidos (Cap. 10), assim como as conclusões a que se pôde chegar (Cap. 11). No

�nal encontram-se as referências a elementos de pesquisa, e eventuais endereços para páginas

da Internet foram acedidos com sucesso à data de escrita desta dissertação (Maio 2007).

3

2 Redes sem �os ad-hoc

Uma rede sem �os ad-hoc é uma rede formada no momento na qual o meio de comunicação entre

os nós é conseguido sem o recurso a cablagem. A rede diz-se ad-hoc pois cada nó está preparado

para encaminhar dados para outros nós, e a escolha de qual o nó para o qual determinado

pacote deve ser enviado é calculado dinamicamente baseado na conectividade da rede. Este

funcionamento contrasta com outras tecnologias de rede mais clássicas nas quais alguns nós

designados da rede, normalmente com hardware dedicado e denominados de routers, estão

encarregues de encaminhar os dados.

Um mínimo de con�guração e rápida instalação tornam as redes ad-hoc indicadas para

situações de emergência onde à partida não existe uma infra-estrutura de rede montada, como

cenários de acidentes naturais ou induzidos por humanos, situações médicas de emergência

e especialmente para �ns militares [2], onde estão a ser largamente implementadas para os

sistemas JTRS [3] [4](Joint Tactical Radio System) e NTDR [5] (Near-Term Digital Radio).

Tipos de redes ad-hoc sem �os incluem redes com sensores móveis (MANET), redes em

malha (Mesh) e, mais particularmente aplicado a este trabalho, redes sensoriais sem �os.

2.1 Redes sem �os com nós móveis

Uma rede móvel ad-hoc (mobile ad-hoc network - MANET), é um tipo particular de redes

ad-hoc sem �os, auto-con�gurável e constituída por nós encaminhadores móveis interligados

por meios sem �os - a união dos quais forma uma topologia arbitrária. Os encaminhadores

estão possibilitados de se deslocar aleatoriamente e organizar-se arbitrariamente; sendo assim,

a topologia da rede pode alterar-se rapidamente e inesperadamente.

As MANET podem ser descritas como �Redes de nós que casualmente se encontraram na

vizinhança uns dos outros sem ter uma infraestrutura �xa à partida�. As redes ad-hoc móveis

tornaram-se um popular assunto de investigação assim que a norma 802.11/Wi-Fi (3.2.2) e os

computadores portáteis se massi�caram no �nal da década de 90. Muito papers académicos

avaliavam protocolos e capacidades assumindo variados níveis de mobilidade dentro de um

espaço limitado, usualmente com todos os nós à distância de alguns hops 1 uns dos outros,

e com estes a enviar dados a uma frequência constante. Diferentes protocolos são por isso

concebidos tendo em conta a perda de pacotes, a introdução de overhead pelo algoritmo de

encaminhamento e outras medidas.

As redes ad-hoc veículares (Vehicular Ad-Hoc Networks - VANET [6]) são um caso particular

de MANETS usadas para comunicação entre veículos e entre veículos e equipamentos instalados

na berma da estrada.

2.2 Redes em malha

Comunicações em redes em malha é uma forma particular de encaminhar dados, voz, instruções,

etc. entre nós. Permite ligações e recon�gurações contínuas em torno de caminhos quebrados

ou bloqueados, bastando para isso �saltar� de nó em nó até o destino ser alcançado. Uma rede

em malha cujos nós estão todos ligados uns aos outros trata-se de uma rede totalmente ligada.

As redes deste tipo diferem de outras redes na questão que todas as partes se podem ligar

a todas as outras através de múltiplos hops, os quais geralmente não são móveis, permitindo

1Hop: um hop é um salto, entre dois nós consecutivos, ao longo de um caminho numa rede.

5

alcançar pontos extremamente distantes, resultado em redes que se podem estender por grandes

distâncias.

Estas redes estão proximamente relacionadas com as MANETS, na medida em que também

têm de lidar com os problemas introduzidos pela eventual mobilidade/desaparecimento de nós.

São também auto-recon�guráveis, isto é, a rede é capaz de operar quando um nó se avaria ou as

capacidades de transmissão se deterioram. Como consequência, consegue-se uma rede bastante

�ável, pois cada nó está ligado a muitos outros e ,na situação de falha, bastará apenas aos nós

vizinhos encontrarem nova rota para encaminhar os dados. Este conceito é aplicável tanto a

redes com �os como sem �os.

Figura 2.1: Rede em malha.

O exemplo mais típico para redes deste tipo é a Internet, que embora funcione por via

de �os, se baseia no mesmo princípio: os dados saltam de dispositivo em dispositivo até al-

cançar determinado destino. As capacidades dinâmicas de encaminhamento incluídas em cada

um destes dispositivos possibilitam que tal seja executado. Para o poder implementar, cada

dispositivo necessita de comunicar as suas informações de encaminhamento a todos os outros

dispositivos ao qual está conectado, informação essa que deve ser sempre actualizada em tempo

real. Cada dispositivo determina então o que fazer com os dados que recebe: ou �car com eles

ou encaminhá-los ao próximo dispositivo existente na rota de destino desse pacote de dados.

O algoritmo utilizado deve garantir sempre que os dados são transmitidos pelo caminho mais

indicado (o mais rápido) até ao seu destino.

O sistema WiMax, por exemplo, é outro exemplo de uma rede que funciona em malha, e em

virtude da sua aplicabilidade estas redes são denominadas de Redes Metropolitanas em Malha,

já que o sistema baseia por um distribuição em malha dos módulos prestadores de serviço.

6

2.3 Redes sensoriais sem �os

2.3.1 O que são

Uma rede sensorial sem �os (WSN - Wireless Sensor Network) consiste numa rede de dis-

positivos autónomos espacialmente distribuídos que recorrem a sensores para, em conjunto,

monitorizar condições físicas ou ambientais, como sejam temperatura, som, vibração, pressão

ou, caso particular deste trabalho, movimento. O desenvolvimento deste tipo de redes foi inici-

almente motivado para aplicações militares como vigilância de campos de batalha. No entanto,

as WSN são hoje em dia utilizadas em inúmeras aplicações de cariz civil, incluindo monitori-

zação ambiental e habitats [7], aplicações clínicas [8], automação doméstica [9] e controlo de

tráfego [10].

Adicionalmente a um ou mais sensores, cada nó numa WSN está tipicamente equipado com

um transmissor rádio (ou outros meios de comunicação sem �os), um pequeno processador

com limitado poder computacional, uma fonte de energia (normalmente uma pilha) e memória

interna limitada. O tamanho de um único sensor pode variar desde a dimensão de uma caixa

de sapatos até algo tão pequeno como um grão de areia. O custo destes sensores varia na

mesma ordem, desde as centenas de euros até alguns cêntimos, dependendo no tamanho da

rede sensorial e da complexidade individual necessária em cada um dos nós. Limitações de

tamanho e custo dos nós resultam nas correspondentes limitações em recursos, como energia,

memória interna, poder computacional e largura de banda.

As características únicas que podemos associar a WSNs são:

• Sensores de reduzida dimensão

• Limitações energéticas, tanto de consumo como de armazenamento

• Condições ambientais adversas, que podem contribuir para deterioramento da capacidade

de comunicação

• Mau funcionamento dos nós, que não deve comprometer o normal funcionamento da rede

• Mobilidade dos nós, contribuindo para uma alteração dinâmica da topologia da rede;

embora não seja um comportamento �típico� de WSNs, estas devem saber reagir

• Falhas de comunicação, devendo a rede ser capaz de encontrar novos caminhos para fazer

chegar informação ao destino

• Colocações em larga escala

• Funcionamento não assistido

• Padrão de tráfego em que os sensores geram pacotes para os sinks e recebem destes

comandos e con�gurações

Actualmente, tratando-se de um tema em grande expansão e com inúmeras aplicações,

realiza-se muita investigação nesta área, e anualmente têm lugar diversos workshops e confe-

rências subordinadas a este tema.

2.3.2 Para que servem

As aplicações das WSN são muitas e variadas. Têm uso em aplicações comerciais e industriais

para monitorizar dados que seriam de difícil obtenção ou de elevada despesa caso fossem usados

sensores ligados por �o. Estas redes podem ser instaladas em áreas ambientais, onde permane-

cem por diversos anos (monitorizando algumas variáveis ambientais, como a temperatura, para

prevenção de incêndios [11]) sem a necessidade de recarregar/substituir a sua fonte energética.

7

Podem ser ainda colocados ao longo de um perímetro de uma propriedade ou recinto e moni-

torizar as movimentações de intrusos (passando a informação de um nó para o seguinte). Uma

situação deste tipo é aquela contemplada por este trabalho.

Figura 2.2: Redes sensoriais em cenários militares.

Monitorização de um espaço é a aplicação mais típica para WSNs, onde a rede é instalada

numa região onde um certo fenómeno deve ser vigiado. Quando os sensores detectam o evento

em causa (temperatura, pressão, som, luz, campos electro-magnéticos, vibrações, etc), este

é comunicado até uma das bases centrais, que toma então as medidas apropriadas (enviar a

mensagem para um servidor, para a Internet, para um transmissor de satélite, para um Centro

de Comando, etc). Dependendo do objectivo da rede, diferentes formas de propagação de

dados devem ser adoptadas, consoante variáveis como a necessidade de resposta em tempo-real,

redundância dos dados, necessidades de segurança, etc.

Existem muitas mais aplicações para WSNs, entre as quais monitorização de habitats, ras-

treio de objectos, controlo de reactores nucleares, detecção de incêndios, monitorização de

tráfego, vigilância militar (Figura 2.2), detecção acústica, sísmica ou vulcânica, etc.

2.4 Encaminhamento tradicional em redes

Por encaminhamento entende-se a forma de seleccionar e optimizar caminhos entre nós de uma

rede de forma a fazer chegar informação a determinado destino, atravessando nós intermediários,

denominados de routers (encaminhadores). Estes nós normalmente armazenam informação

sobre a melhor rota para os diferentes destinos, pelo que uma e�caz construção destas tabelas

contribui para um melhor desempenho da rede. As redes pequenas e estáticas podem admitir

uma introdução manual das tabelas, mas para redes maiores, com topologias complexas e com

mudanças de posição, a construção destas tabelas torna-se um processo problemático.

O encaminhamento dinâmico, portanto, propõe-se a resolver tal questão, cabendo aos nós

a tarefa de, autonomamente, serem capazes de construir as tabelas baseando-se na informação

que circula pela rede, permitindo que seja capaz de responder e�cazmente a alterações na rede.

Quanto ao encaminhamento em redes, pode-se identi�car algumas categorias:

8

2.4.1 Algoritmos vector distância

Os algoritmos vector distância utilizam o algoritmo de Bellman-Ford. Esta aproximação associa

um número (o custo) a cada uma das ligações entre cada nó da rede. Os nós enviam informação

de um ponto A a um ponto B através do caminho do qual resulta um menor custo total (i.e.,

a soma dos custos parciais ao longo de cada um dos passos).

Este algoritmo funciona duma forma muito simples. Quando um nó arranca, conhece apenas

os seus vizinhos imediatos e o custo envolvido em cada uma destas ligações. Esta informação,

a lista de destinos, o custo total até cada e o nó seguinte para chegar a cada um deles constitui

a tabela de encaminhamento, ou tabela de distâncias. Cada nó, a intervalos regulares, indica a

cada um dos vizinhos a sua própria noção do custo total para chegar a todos os destinos que

conhece. Os nós vizinhos analisam esta informação e comparam-na com a que já conhecem:

tudo o que seja uma melhoria em relação aos dados que dispunham é actualizado nas suas

próprias tabelas. Com o passar do tempo, todos os nós da rede vão �car a saber qual o melhor

nó seguinte ao qual passar a informação para chegar a determinado destino, e o custo total do

trajecto.

Quando um dos nós se avaria (ou é removido), os nós que o usavam como nó seguinte para

certos destinos descartam essa entrada nas suas tabelas e criam novas rotas para actualizarem

as suas tabelas de encaminhamento. Esta informação é passada aos nós vizinhos, e o processo

repete-se, resultando que todos os nós saberão das novas melhores rotas para chegar aos destinos

existentes. Na situação em que, se o nó removido seja essencial para fazer a ligação a todo um

conjunto de diferentes nós que, após a sua remoção, se tornaram inacessíveis, as entradas

referentes a esses nós são removidos a todos os outros.

2.4.2 Algoritmos link-state

Ao aplicar algoritmos link-state, cada nó utiliza um mapa da rede, na forma de um grafo, como

informação principal. Para o produzir, cada nó faz �ood 2 à rede sobre a que outros nós se

pode ligar, e cada nó, independentemente, utilizará esta informação para a construção do grafo.

Recorrendo a ele, cada nó calcula o caminho de menor custo que o liga a todos os restantes nós

da rede usando algoritmos convencionais de menor custo, como o algoritmo de Dijkstra [12]. O

resultado é uma árvore com início no nó �actual�, em que as folhas são todos os restantes nós

da rede, ligados pelos diversos caminhos de menor custo. Com esta árvore contrói-se a tabela de

encaminhamento, que especi�ca o melhor nó seguinte para fazer chegar um pacote a qualquer

outro nó da rede.

2.4.3 Algoritmos vector caminho

Os dois algoritmos descritos acima são mais indicados para encaminhamento intra-domínio. São

usados dentro de um sistema autónomo, mas não entre sistemas autónomos. Ambos se tornam

impraticáveis para redes de grande dimensão e não são utilizáveis para encaminhamento inter-

redes. O encaminhamento vector distância torna-se instável se há mais do que uma série de

hops dentro da rede e o encaminhamento link-state necessita de uma enorme quantidade de

recursos para calcular as tabelas de encaminhamento. Origina também um intenso tráfego na

2Flood: situação em que toda a rede é �inundada� com um pedido.

9

rede causado pelo �ooding de dados, o que numa rede sensorial aumenta consideravelmente o

indesejável consumo energético.

O encaminhamento por vector caminho também é usado dentro da rede. Nesse aspecto,

assemelha-se ao vector distância. No encaminhamento por vector caminho assume-se que há

um dos nós da rede (apesar de poder serem mais) em cada um dos sistemas autónomos que

funciona em representação de todo o sistema. A este nó chama-se o speaker node. Este nó cria

uma tabela de encaminhamento dentro da sua própria rede e comunica-a aos restantes speaker

nodes seus vizinhos. A semelhança com o encaminhamento por vector distância só difere no que

toca aos speaker nodes, que são os únicos nós em cada rede autónoma que podem comunicar

com as outras redes.

2.5 Encaminhamento em redes ad-hoc

As redes sensoriais ad-hoc enfrentam di�culdades acrescidas no que diz respeito à exequibilidade

das soluções propostas e às limitações do hardware disponível, o que tem originado uma grande

investigação nesta área, havendo mais de 50 algoritmos propostos [13] [14]. As principais razões

prendem-se com a convergência lenta na criação/manutenção de caminhos e com o elevado

overhead associado a estes algoritmos. Não se pode esquecer que as comunicações em redes

ad-hoc são altamente dinâmicas, ou seja, as condições de transmissão podem variar muito

rapidamente, nem todos os caminhos são simétricos, os nós podem falhar frequentemente, etc.

Além destas questões, devem ser tidos em conta a dimensão da rede, a potencial perda

de pacotes, atrasos na transmissão e chegada de mensagens ao destino, congestão na rede,

interferências externas, a estabilidade da rede, o tempo de conexão e principalmente a utilização

energética (a manutenção periódica das tabelas de encaminhamento implica consumo energético

embora não esteja a contribuir directamente para a transmissão de dados) [15].

Alguns conceitos de encaminhamento base surgem para se adequar às necessidades das redes

sensoriais.

2.5.1 Encaminhamento pró-activo

Numa rede ad-hoc, os nós não possuem um conhecimento a priori da topologia da rede, neces-

sitando de a descobrir. O conceito por detrás dessa descoberta é que um nó deve �anunciar�

a sua presença, �ouvindo� também os seus vizinhos anunciar as suas presenças. Cada nó tem

então conhecimento dos seus nós vizinhos e propaga aos outros nós aqueles que também lhe são

vizinhos. Ao �m de algum tempo, cada nó sabe de cada um dos outros e formas (e�cazes) de

chegar a eles. Este tipo de estabelecimento de rede, em que cada nó obtém conhecimento geral

da rede, determinam-se de pró-activos, ou seja, os nós conhecem as melhores rotas até cada

um dos destinos antes mesmo de ser necessário utilizar essa rota. Regularmente, os nós devem

avisar a sua presença para assegurar a sua permanência nas tabelas de encaminhamento.

Exemplos de algoritmos de encaminhamento pró-activo conhecidos são o DSDV [16] [17](Des-

tination Sequenced Distance Vector) e o WRP [18](Wireless Routing Protocol).

2.5.2 Encaminhamento re-activo

Alternativamente, o caminho de um nó a outro pode apenas ser determinado quando realmente

é necessário, poupando assim processamento e energia à rede necessária na manutenção de

10

Figura 2.3: Topologia numa rede auto-con�gurável.

caminhos. Este tipo de algoritmos denomina-se de reactivo, pois a rede reage a pedidos expressos

a ela feitos. Da primeira vez que um nó se introduz na rede, não tem qualquer preocupação com

a sua vizinhança. Apenas quando necessita de descobrir um caminho o nó inicia a sua descoberta

de rota até ao destino da mensagem, inundando a rede com o seu pedido (�ooding). Segundo

essa ideia, todos os nós da rede, ao receberem uma mensagem de descoberta, retransmitem-na

a todos os nós que possam estar a �ouvir�. Em ambos os casos, sempre que um nó retransmite

uma mensagem de descoberta de rota, vai recebê-la dos nós que estavam no seu alcance e

que, na sua vez, retransmitiram a mensagem de descoberta (para evitar uma retransmissão

contínua das mensagens, estas transportam números de sequência que são incrementados a

cada passagem por um nó). Aproveitando esse acontecimento, os nós aproveitam e tomam

conhecimento dos nós que lhes são vizinhos. Sempre que uma rota é completada, a mensagem

é devolvida à origem, atravessando no sentido inverso os nós que fazem parte da agora rota

descoberta. Perante esta informação, os nós que compõem essa rota obtêm o nó seguinte para

chegar a esse destino. Eventualmente, com a sucessão de pedidos, os nós terão informação sobre

todos os nós da rede e o nó a seguir para todos os destinos.

Algoritmos como o AODV [19] [20](Ad-hoc On-Demand Distance) ou o DSR [21](Dynamic

Source Routing) são um exemplo de protocolos reactivos.

2.5.3 Encaminhamento geográ�co

Algoritmos de encaminhamento geográ�co são uma alternativa aos já conhecidos e acima des-

critos algoritmos em redes ad-hoc, porque permitem mais facilmente a sua instalação em larga

escala; a informação mantida em cada nó depende, aqui, não da dimensão da rede em que se

inserem, mas apenas da densidade de elementos instalados. Esta �loso�a mantém-se válida para

11

redes em que as coordenadas dos elementos não estão disponíveis, visto que podem, a cada um

deles ser atribuídas coordenadas virtuais, podendo assim algoritmos baseados neste princípio

ser utilizados nas mais diversas situações, incluindo redes indoor.

Como grandes vantagens desta abordagem, temos o facto de não ser necessário guardar uma

grande quantidade de informação referente a ligações na rede, sendo em cada elemento apenas

guardada informação referente aos seus vizinhos, bem como a possibilidade de se eliminar a

sobrecarga provocada por mensagens de procura de caminhos, já que um pacote segue uma

�direcção�, em vez dum �caminho�. Esta abordagem permite também em geral encontrar

percursos bastante directos, com um numero reduzido de elementos intermédios (hops) para

cada ligação.

Os algoritmos LAR [22] (Location Aided Routing) ou GeoCast [23] (Geographic Addressing

and Routing) são característicos.

2.5.4 Encaminhamento hierárquico

Com o aumentar de tamanho da rede, a dimensão das tabelas de encaminhamento cresce

proporcionalmente (salvaguardando método de encaminhamento que guardam tal informação

em cada nó). Não só mais memória interna �ca ocupada pela dimensão crescente das tabelas,

como também maior é o processamento requerido para procurar entradas ao longo das tabelas,

assim como consome largura de banda enviar noti�cações de estado destas ligações. A partir

de determinado ponto, a rede pode crescer até uma altura onde é impraticável cada nó possuir

uma entrada para cada um dos outros, altura em que o encaminhamento tem de ser feito

hierarquicamente, tal como acontece para as redes telefónicas.

Figura 2.4: Estrutura hierárquica de rede.

Quando o encaminhamento hierárquico é utilizado, os nós são agrupados em regiões, cabendo

a determinados nós encaminhadores em cada região saber como despachar pacotes dentro da

sua própria região, mas sem nada saber das regiões restantes. Quando diferentes regiões são

12

interligadas, cada região é tratada independentemente, para que cada nó encaminhador seja

aliviado da tarefa de guardar informação da topologia das restantes regiões.

Quando as redes se tornam ainda maiores, mais hierarquias serão feitas. Os nós são agrupa-

dos em regiões, as regiões em clusters, os clusters em grupos, etc. Supondo uma rede de 1000

nós, em vez de cada nó ter de conter informação sobre o nó seguinte para chegar a cada um dos

restantes 999 nós, podem-se formar clusters de 100 nós cada, cada um destes tendo 4 regiões

de 25 nós.

A desvantagem desta aproximação é que, estando cada nó subordinado ao seu nó encami-

nhador directo, mesmo que o destino imediato de uma mensagem esteja ao alcance do sinal de

transmissão, os dados têm de percorrer todo o trajecto pelos nós encaminhadores intermédios.

Alguns algoritmos que se baseiam nesta hierarquia são o ZRP [24] (Zone Routing Protocol)

e o CGSR [25] (Clusterhead-Gateway Switch Routing) ou o modelo Cluster Tree (2.6.3).

2.6 Encaminhamentos usados em WSNs

2.6.1 AODV

O algoritmo de encaminhamento AODV (Ad-Hoc On-demand Distance Vector), é largamente

utilizado para encaminhar mensagens em redes ad-hoc sem �os não hierárquicas. O AODV

é capaz de efectuar tanto unicast como multicast. É um protocolo reactivo, ou seja, apenas

é estabelecida uma rota para determinado destino quando necessário. Note-se que a grande

maioria dos protocolos de encaminhamento são pró-activos, tentando assim estabelecer rotas

independentemente de estas se virem a veri�car necessárias ou não.

Figura 2.5: Demonstração do algoritmo AODV.

13

Neste protocolo a rede mantém-se adormecida até que se torne necessário estabelecer uma

ligação entre quaisquer dos elementos que a constituem; nesta altura o elemento que está na

posse de uma mensagem para ser enviada, solicita na forma de difusão um pedido de ligação

para o destino da mensagem. Outros elementos da rede que recebam este pedido retransmitem-

no de forma a dar seguimento ao mesmo e guardam informação do nó do qual receberam o

pedido em questão, criando assim um caminho de regresso para o nó de origem. Assim que um

nó que receba um pedido deste tipo e tenha conhecimento de uma rota para o destino desejado,

envia uma mensagem de volta para o nó que deu origem ao pedido, dando assim origem ao

estabelecimento de uma rota. Caminhos mais curtos que sejam mais tarde encontrados vêm

substituir rotas já existente; as entradas não utilizadas nas tabelas de encaminhamento são

retiradas após um determinado período de tempo sem utilização.

2.6.2 DSR

O algoritmo de encaminhamento DSR (Dynamic Source Routing), é outro protocolo para en-

caminhamento em redes sem �os, é em parte semelhante ao já referido AODV no aspecto em

que também estabelece rotas, sempre e só quando são necessárias. A diferença reside em que

é utilizado encaminhamento baseado em informação guardada na fonte e não em todos os nós

utilizados no seu percurso até ao destino.

Para estabelecer uma rota para determinado destino é necessário guardar na origem o en-

dereço de todos os elementos por onde a mensagem irá ser encaminhada. Neste caso existe a

possibilidade de pacotes �carem fortemente sobrecarregados com informação referente à rota a

percorrer, pelo que as optimizações se tornam cruciais em redes de alguma dimensão.

Em altura de descoberta de rota, durante o �ood à rede, sempre que a mensagem passa

por um nó, o seu endereço é adicionado ao próprio conteúdo da mensagem, de forma a que a

rota completa �que guardada. Este sistema torna-se complicado para redes com largo número

de nós e cujas mensagens atravessem um grande número de elementos, não só pela sobrecarga

de dados na própria mensagem, mas também porque nem todas as rotas são simétricas e a

possibilidade de perder um pacote aumenta quanto maior o número de hops na rota. Como

cada nó intermédio não guarda informação sobre os vizinhos, quando a mensagem é perdida o

processo tem de ser recomeçado do início.

2.6.3 Cluster-Tree

Os algoritmos descritos acima, apesar de não guardarem as rotas para todos os outros ele-

mentos da rede, procurando apenas caminhos assim que necessários, e guardando-os por um

determinado período, não dispensam a necessidade de se manter uma quantidade elevada de

dados armazenada para manter rotas activas. Ao diminuir o numero máximo de rotas activas

aumenta-se o número de mensagens para restabelecimento de rotas. Uma forma de diminuir a

quantidade de informação guardada referente a caminhos é encontrar uma topologia para a rede

organizada hierarquicamente, em que um elemento com elevada capacidade de armazenamento

e processamento guarda informação sobre toda a rede, é o caso do algoritmo Cluster Tree [26].

O nó que centraliza a informação da rede é denominado por Cluster-Head (CH) (o Speaker

node), que gere ainda permissões para novos nós se juntarem à rede estabelecida. Os restantes

nós apenas necessitam manter informação do caminho até ao CH, sendo depois este responsável

por a encaminhar para o destino �nal. Caso o nó que gere a rede falhe ou esteja inacessível a

14

rede deve estabelecer um novo CH que o venha a substituir, o que nem sempre é viável pelos

baixos recursos dos restantes elementos da rede.

2.7 Encaminhamentos especialmente desenvolvidos para WNSs

2.7.1 Directed Di�usion

O Directed Di�usion (DD), um algoritmo reactivo especialmente desenhado para redes senso-

riais, apresenta soluções para todos os problemas até aqui descritos. Os nós de origem lançam

�interesses� para a rede, como seja medir a temperatura do ar. Sempre que as condições desse

interesse se veri�quem (temperatura a exceder um certo limiar), esse �evento� é reportado à

rede, difundindo-se por ela até ao nó originante. Em vez de receber pedidos regulares de um

nó fonte, é o próprio sensor destino que toma a iniciativa sempre que a condição requerida for

veri�cada. Tratando-se de um algoritmo reactivo, está assegurada a poupança energética. O

DD introduz ainda o conceito de caching nos nós, guardando informação e dando uma vali-

dade à informação recebida. Se o nó receber um pedido dentro dessa validade, a informação é

devolvida directamente por esse nó, poupando energia aos restantes.

Quanto ao mecanismo de poupança do volume de informação, o DD introduz conceitos

de agregação. Por exemplo, se o evento for veri�cado em 10 nós de regiões próximas que

veri�cam a mesma temperatura (ou intervalo de temperatura), o nó que as recebe, antes de

as retransmitir, agrupa-as numa só, transformandoas numa única mensagem. Enquanto os

algoritmos descritos anteriormente são algoritmos genéricos de encaminhamento em redes ad-

hoc, o DD é especialmente concebido para WSNs, tal como o SPIN [27](Sensor Protocols for

Information via Negotiation), LEACH [28](Low Energy Adaptive Clustering Hierarchy) ou o

ACQUIRE [29](ACtive QUery forwarding In sensoR nEtworks).

2.7.2 GPSR

O GPSR [30] (Greedy Perimeter Stateless Routing) tem-se tornado recentemente um algoritmo

preferencial em redes sensoriais devido à sua generalidade e escalabilidade. Neste método, cada

nó conhece apenas os nós seus vizinhos, o que resulta que a informação armazenada é resultado

apenas da densidade de nós no local e não do número total de nós da rede, informação essa que

não requer, admitindo o cariz mais ou menos estático de redes de sensores, grande actualização.

Todos os nós periodicamente anunciam a sua própria posição, guardando a posição também

anunciada pelos seus vizinhos (esta posição pode ser geográ�ca ou pontos num referencial

ortonormado projectado).

Sempre que um pacote deve chegar a um certo destino, o nó origem escolhe o nó seguinte

que está mais perto, de entre os seus vizinhos, do nó destino. Numa situação exemplo retirada

de [30], apresentada na Figura 2.6, o nó x quer fazer chegar um pacote a D, e escolhe y como

nó seguinte. Pode haver casos em que nenhum dos nós vizinhos estão entre os mais próximos

(por exemplo, na presença de obstáculos): nessa situação, o pacote deve circular em torno do

obstáculo.

De um encaminhamento greedy (avarento), o método transforma-se em encaminhamento

por perímetro, em que nos nós exteriores mais próximos do destino são escolhidos. Este modo

termina quando um nó não exterior mais próximo é encontrado (altura em que se retorna ao

encaminhamento greedy.

15

Figura 2.6: Escolha greedy.

Simulações mostram que este método tem uma elevada taxa de sucesso, e que consegue, na

grande maioria dos casos, encontrar sempre o caminho mais curto (em número de hops), com

um overhead menor que aquele produzido pelo DSR.

16

3 Tecnologias e Equipamento utilizados

3.1 Estado da arte

Resultado da miniaturização de sistemas e de avanços na tecnologia CMOS, os sistemas em-

bebidos, aliados a um mais ambicioso poder computacional e de armazenamento, puderam

colocar-se massivamente no mercado, possibilitando a expansão de áreas tão variadas como

telemóveis, leitores MP3, consolas portáteis, PDAs e, também, em sistemas desenvolvidos para

redes de sensores. Nestes últimos, a miniaturização permitiu que num reduzido espaço físico

fossem colocados, além do microcontrolador, meios de comunicação, armazenamento, e variados

sistemas de recolha de dados (sensores) e interferência com o ambiente (actuadores). Diversos

standards para comunicação sem �os foram surgindo ao longo da última década, o que permi-

tiu um novo conjunto de possíveis aplicações para este sistemas, que assim deixavam de estar

limitados a ligações por �o e podiam assim ser instalados praticamente em qualquer lugar.

Mas esta nova possibilidade trouxe um novo conjunto de desa�os inerentes à comunicação

sem �os e principalmente à autonomia dos nós da rede, que se pretendia cada vez mais au-

tónoma e duradoira. Protocolos como o Wi-Fi ou o Bluetooth, apesar de bem instalados no

mercado e formando com sucesso redes ad-hoc nos dispositivos que o utilizam, desde computa-

dores portáteis, telemóveis, consolas, auriculares sem-�os, etc., a sua implementação em redes

sensoriais não foi equacionada, dado o seu pesado consumo energético.

Comunicações por rádio-frequência são um método de baixo custo e reduzido consumo para

transmissão de dados, tornando-se altamente indicado para este tipo de redes. No entanto, as

comunicações sem �os por este sistema devem assentar num protocolo que assegure não só a

�abilidade dessas mesmas transmissões, como também minimize o consumo da rede, através da

redução de solicitações aos nós para retransmissão de pacotes. Com o intuito de maximizar ao

máximo a longevidade destas redes, surgiu o protocolo 802.15.4, ou Zigbee. Com este protocolo

possibilitou-se que os nós da rede permanecessem adormecidos a maior parte do tempo, salvo

quando são necessários para efectuar tarefas na rede. Para tirar ainda melhor partido deste

estado, inúmeros métodos de encaminhamentos de mensagens foram adaptados a estas redes

para tentar minimizar a actividade dos nós na rede, aumentando assim consideravelmente a

sua duração. Nos últimos anos, começaram a ser desenvolvidos algoritmos de encaminhamento

especialmente concebidos para redes sensoriais, que incorporam conceitos de agregação ou de

cache de dados recentemente obtidos nos nós, por exemplo.

Actualmente, com a cada vez maior optimização do consumo energético na rede aliado

a maior espaço de armazenamento e processamento, novas abordagens estão a ser feitas. O

estado da arte nesta área consiste na aproximação com Tiny DB [31, 32]. O Tiny DB é um

processador de aquisição de queries distribuídas que corre em cada nó numa redes sensorial,

sobre o Tiny OS. Tem a capacidade de controlar quando, onde, e com que regularidade os dados

devem ser obtidos na rede de forma a reduzir o consumo energético, contendo ainda muitas das

características associadas a outros algoritmos, como selecção, decisão, agrupamento a agregação

de dados. A BD contém uma tabela com uma coluna para cada tipo de sensor existente, e um

novo tuplo é adicionado à tabela em intervalos regulares sempre que um novo dado é obtido,

contendo mais informação referente ao identi�cador do nó, localização, hora de aquisição e o

valor da leitura.

O interesse por baixos consumos energéticos em pequenos dispositivos é grande, e novas

17

normas e conceitos vão saindo. Em 2006, a Nokia anunciou o Wibree [33], baseado também em

tecnologia RF, destinado para dispositivos com ultra baixo consumo (alimentados a baterias tipo

�botão�) e comunicações de curto alcance, como relógios de pulso, teclados sem �os, brinquedos

e sensores desportivos. Funcionando também na banda ISM3 de 2.4GHz, introduziu-se como

complemento (e potencial substituto) do Bluetooth.

Futuramente, podemos esperar ver novas normas sem �os, que apresentam soluções mais

�exíveis, mais optimizadas para os recursos disponíveis, mais autónomos e, principalmente,

mais baratos e massi�cados no mercado, possibilitando que de uma forma fácil e quase imediata

consigamos estabelecer comunicações entre os mais variados dispositivos.

3.2 Tecnologias

3.2.1 Zigbee/802.15.4

O ZigBee é o nome de uma especi�cação de protocolos de comunicação de alto nível que usa

rádios com baixas necessidades energéticas, baseada no standard 802.15.4 do IEEE para redes

locais sem �os (WPANs - Wireless Personal Area Networks), estando dirigido a aplicações RF

que requerem baixo débito, elevada autonomia e comunicações seguras. O consórcio responsável

pela especi�cação da norma ZigBee é a ZigBee Alliance, do qual já fazem parte mais de 150

membros. Este nome provém dos trajectos erráticos (zigging) que as abelhas (bees) efectuam

quando recolhem pólen pelas diversas �ores.

A ZigBee Alliance, como se pode observar na Figura 3.1, de�niu as especi�cações sobre a

norma 802.15.4 nas camadas de rede, segurança e interface à aplicação (API).

Figura 3.1: Camadas de�nidas pelo IEEE 802.15.4 e pela ZigBee Alliance.

As especi�cações a nível das camadas de dados (MAC) e física (PHY) são aquelas previa-

mente estabelecidas pela IEEE, cuja estrutura se pode ver na Figura 3.1.

A norma Zigbee/802.15.4 apresenta diversas características:

3Industrial, Scienti�c, Medical

18

• Variadas frequências de funcionamento (2.4GHz e 868/915 MHz)

• Débitos de 250kbps (a 2.4 GHz, a nível internacional), 40 kbps (a 902-928 MHz, na

América) e 20 kbps (a 868.3 MHz, na Europa), conhecidas como bandas ISM - Industrial,

Scienti�cal and Medical

• Canais de acesso CSMA-CA. Permite alto throughput e baixa latência para dispositivos

com baixos duty cycles como sensores e comandos

• Baixo consumo (duração da bateria de muitos meses a anos, através do 'adormecimento'

regular do dispositivo)

• Múltiplas topologias: estrela, peer-to-peer, malha

• Espaço de endereçamento para até:

� 18.450.000.000.000.000.000 dispositivos (endereços IEEE de 64 bits)

� 65.535 redes

• Time slot opcional garantido para aplicações que requerem baixa latência

• Protocolo totalmente assente em hand-shake para �abilidade na transmissão

• Alcance: 50 metros típicos (5-500 metros consoante o espaço)

A área de actuação desta tecnologia prende-se com situações que tiram proveito de elevada

autonomia e reduzida troca de dados a baixo débito, do tipo 'montar e esquecer', como sejam

por exemplo controlos de iluminação, medições regulares automáticas, detectores de CO e fumo

sem �os, controlo de aquecimento, segurança interna (homeland security, onde este projecto se

insere), controlo de persianas via medição de iluminação, controlo e medições médicas, controlos

remotos universais, automação industrial, etc.

Na Figura 3.2 podemos ver onde se insere o ZigBee comparativamente a outras tecnologias

sem �os.

Figura 3.2: Enquadramento do Zigbee versus outras tecnologias.

Esta norma propõe, comparativamente aos concorrentes directos imediatos, como o Blue-

tooth, uma solução extremamente mais barata (componentes mais básicos, código não propri-

etário), escalável (redes podem ter supostamente milhares de nós em vez de agrupamentos de

piconettes de 7 elementos de cada vez do Bluetooth, com sistemas de polling altamente consu-

midores de energia), simples (pilha anunciada com 10% do tamanho da do Bluetooth, embora

em termos práticos esteja mais na ordem dos 50%) e duradoira (os baixos duty cycles permitem

que a bateria dure anos).

19

A exequibilidade da norma ZigBee para redes sensoriais, comparativamente a outras tecno-

logias, é observável na Tabela 3.1.

Tabela 3.1: Comparação entre Zigbee e outros standards.

Nome Comercial Zigbee � Wi-Fi Bluetooth

Standard 802.15.4 GSM/GPRS/

CDMA/1xRTT

802.11.b 802.15.1

Foco de aplicação Monitorização

e controlo

Grande cober-

tura de voz e

dados

Web, Email,

Video

Substituição

de cabos

Recursos do sistema 4KB-32KB 16MB+ 1MB+ 250KB

Duração da bateria (dias) 100-1000+ 1-7 0.5-5 1-7

Tamanho da rede Ilimitado (26) 1 32 7

Largura de Banda (KB/s) 20-250 64-128+ 11.000+ 720

Alcance de transmissão (me-

tros)

1-100+ 1.000+ 1-100 1-10+

Factores de sucesso Fiabilidade,

Consumo,

Custo

Alcance, Qua-

lidade

Velocidade,

Flexibilidade

Custo, Conve-

niência

Como se pode constatar, pelas várias razões descritas acima, o protocolo 802.15.4 coloca-se

como a solução mais viável em implementações de redes sensoriais, e é a especi�cação usada

pelos nós da rede para comunicar entre si.

3.2.2 Wi-Fi/802.11

O Wi-Fi, acrónimo popular para wireless-�delity, foi originalmente uma marca licenciada em

1997 pela Wi-Fi Alliance para descrever a tecnologia embebida de redes locais sem �os (Wireless

Local Area Networks - WLAN ) baseada nas especi�cações 802.11. O seu objectivo era criar um

método de comunicação de banda larga, seguro, �exível, com boa qualidade de serviço, rápido

de instalar e que possibilitasse comunicações ad-hoc.

A primeira forma comercial massi�cada surgiu com a norma 802.11b. Recorrendo inicial-

mente a uma modulação CKK (Complementary code keying) e conseguia uma taxa de transfe-

rência real na ordem dos 5.9Mbps (o overhead do CSMA/CA baixava o throughput dos originais

11Mbps). No entanto, como a banda usada dos 2.4GHz é abundantemente aproveitada (por ser

livre), a norma seguinte, 802.11a, propôs a adopção dos 5Ghz o que, juntamente com a nova

modulação por OFDM (orthogonal frequency-division multiplexing), proporcionou aumentar

a transferência para os 54Mbps (com o valor real causado pelo overhead a aproximar-se dos

20Mbps). A desvantagem da alteração para 5GHz foi a redução do alcance do sinal, pois a maior

frequência era mais rapidamente absorvida por obstáculos sólidos. Apesar disso, ao não haver

interferência com outros sistemas que antes recorriam também aos 2.4GHz tornou o sistema

muito pretendido por pro�ssionais que desejavam maior potencialidades e �abilidade, apesar

do custo acrescido.

Em 2003, procurando maior massi�cação no mercado e introdução do sistema em dispositivos

20

como computadores portáteis, computadores de bolso, telemóveis ou consolas portáteis, aliado

à necessária redução de preço, a norma 802.11g reintroduziu os 2.4GHz, desta vez a 54Mbps

graças à modulação por OFDM, apesar de ainda se debater com os problemas de interferência.

Futuramente, prevê-se a introdução da norma 802.11n, que deverá ser cerca de 4 vezes mais

rápida que a 802.11g, a uns reais 248Mbps (2x2 antenas), conjuntamente com uma (teórica)

duplicação do alcance.

O funcionamento requer, para redes infra-estruturadas (como a deste trabalho) um AP

(Access Point) prestador do serviço e um ou mais �clientes� (neste caso, os PDAs).

3.2.3 TinyOS

Os sistemas operativos para redes sensoriais sem �os são geralmente menos complexos que

aqueles ditos convencionais, o que é causado não só pelos requisitos especiais das aplicações

da rede mas também pelas limitações de recursos nas plataformas de hardware. Por exemplo,

aplicações de redes sensoriais não são normalmente tão interactivas quanto aquelas que correm

sobre PCs, pelo qual o sistema operativo não necessita de suportar interfaces para com o

utilizador. Além do mais, as limitações de recursos em termos de memória e suporte de hardware

para mapeamento de memória tornam mecanismos como memória virtual tanto desnecessárias

como impossíveis de implementar.

O hardware em redes sensoriais sem �os não é muito diferente daquele usado tradicional-

mente em sistemas embebidos e é portanto possível utilizar sistemas operativos embebidos como

o eCos ou uC/OS para redes sensoriais. No entanto, tais sistemas operativos são vulgarmente

desenhados com propriedades de tempo-real, característica normalmente ausente em sistemas

especialmente criados para redes sensoriais, dado que as redes deste tipo normalmente se en-

quadram em padrões de recolhas periódicas de dados. Nesse prisma, não há uma necessidade

de precisão temporal por parte de obtenção de dados.

O TinyOS surge como um sistema operativo open-source especialmente concebido para redes

sensoriais sem �os. Oferece uma arquitectura baseada em componentes que permite rápida

inovação e implementação ao mesmo tempo que consegue minimizar o tamanho do código, tal

como necessário tendo em conta as grandes limitações de memória em redes deste tipo. A

biblioteca por componentes inclui protocolos de rede, serviços distribuídos, controladores para

sensores e ferramentas para aquisição de dados, todos prontos a ser usados ou a ser alterados

para se ajustar a aplicações especí�cas. O núcleo do TinyOS consiste apenas numa rotina de

inicialização (172 octetos), num pequeno runtime em C (82 octetos) e um calendarizador de

eventos (178 octetos).

Este sistema operativo é provavelmente o primeiro especialmente desenhado para redes sen-

soriais sem �os. Ao contrário dos restantes, o TinyOS baseia-se num modelo baseado em eventos

em vez de multi-threading. Sempre que um evento externo ocorre, como por exemplo a chegada

de um pacote de dados ou uma leitura de um sensor, o TinyOS invoca o handler do evento

apropriado para ser executado. Estes podem adiar tarefas que estão programadas pelo kernel

para serem executadas mais tarde (entrando numa �la FIFO de tarefas). Como as tarefas são

executadas num modelo de correr até ao �nal, e estas não entram em preempção umas com as

outras, devem ser deixadas curtas. Tanto o sistema TinyOS como os programas escritos para

ele são feitos numa linguagem de programação especial, denominada nesC, que é uma extensão

da linguagem C.

21

Actualmente na versão 2.0.1 (Maio 2007), o TinyOS já foi adaptado para mais de uma dú-

zia de plataformas e numerosos sistemas. Uma grande comunidade usa-o em simulações para

desenvolver e testar numerosos algoritmos e protocolos. Cada nova release é acompanhada

por milhares de downloads. Mais de 500 grupos de investigação e empresas estão neste mo-

mento a usar o sistema operativo. Comercialmente, empresas como a Crossbow ou a MoteIV

disponibilizam hardware que recorre ao TinyOS nos seus módulos sensoriais.

3.3 Equipamento

3.3.1 MicaZ

O hardware utilizado para a rede sensorial foi o Mote MicaZ, desenvolvido pela Crossbow. Este

dispositivo programável recorre a um processador RISC ATMEGA 128L da Atmel, com 128KB

de memória programável e 4KB de EEPROM. Contém 7 conversores ADC com resolução de 10

bits e ainda 512KB de memória �ash persistente, gastando, em estado adormecido, menos de

15 µA. Está ainda equipado com um rádio CC2420 802.15.4 capaz de debitar 250Kbps a 100

metros (anunciados), e o seu sistema garante segurança AES-128 bits.

Sobre estes dispositivos corre o sistema operativo TinyOS, um sistema open-source especial-

mente desenvolvido para sistemas embebidos e programável numa linguagem adequada também

para este tipo de redes, o nesC (network embedded system). Permite, de origem, suporte para

disseminação, encaminhamento e recolha de dados da rede. Outros módulos suportados pelo

TinyOS (e redes semelhantes) são, por exemplo, os também da Crossbow Mica2 e Mica2dot, e

da Moteiv Telos, os módulos TMote Sky.

Figura 3.3: Mote MicaZ.

Apesar dos módulos da Telos apresentarem melhor autonomia que os da Crossbow, os

motes MicaZ lidam melhor com o processamento de tarefas múltiplas e, principalmente, têm

um conector de 51 pinos (ao contrário dos conectores de 10 e 4 pinos da Telos) que permitem

uma interface muito mais facilitada e �exível a dispositivos sensoriais (que normalmente são

também de 51 pinos). A alimentação dos módulos está a cargo de duas pilhas R6 (AA) de 1,5V

enquanto módulo independente, utilizando a alimentação por via USB da placa programadora

quando conectada a ela.

3.3.2 MIB 520

Os motes MicaZ não têm interface PC (apenas dispõem do conector de 51 pinos), pelo que não

são programáveis directamente. Para tal, recorrem a placas programadoras, as MIB 520, que

funcionam como Gateways para os módulos MicaZ. A ligação é feita ao PC através de uma

ligação USB, que se monta como duas portas virtuais (uma para leitura de dados, outra para

22

programação) série, no caso da ligação em Windows e USB, para ligação Linux. A alimentação

é conseguida através dessa mesma ligação, podendo transmitir energia também aos módulos

ligados no conector de 51 pinos.

(a) MIB 510 (b) MIB 520

Figura 3.4: Placas programadoras.

No sistema de redes sensoriais previsto pelo TinyOS, a informação circulante é encaminhada

por omissão para um nó central, denominado Base Station. Dado que o MIB 520 não tem

sistema RF e o MicaZ não tem interface USB, os dois ligam-se em conjunto para formar este

nó central, passando a informação transparentemente a nível da camada de aplicação desde a

interface RF para a interface USB.

Além do MIB 520, também existem disponíveis o MIB 500, o MIB 510 e MIB 600, com

ligações por porta paralela, série e RJ45, respectivamente. O MIB 510 foi usado para ligação

com o PDA, dado que este não permite ser host USB.

3.3.3 PDA

Embora qualquer PDA que utilize o sistema operativo Pocket PC/Windows Mobile 5 (dada a

linguagem de desenvolvimento utilizada - C# - ser licenciada pela Microsoft, a aplicação não

corre sobre Palm OS) permita a execução da aplicação de Percepção de Situação Operacional,

o modelo usado para demonstração deste projecto foi o Qtek 9090, dotado de um processador

de 400MHz e 128MB de RAM, com comunicações Wi-Fi e GPRS.

Figura 3.5: Qtek 9090.

O PDA deve possuir, além do visor touchscreen característico, capacidade de comunicar

23

em Wi-Fi (para ligação à Gateway) e, importante mas não imprescindível, leitor de cartões de

memória para fácil actualização de �cheiros de mapas (para armazenamento no cartão em vez

da memória interna do PDA).

Caso se pretenda acoplar um módulo MicaZ, a interface deve ser feita recorrendo a uma placa

programadora MIB. Se se usar a MIB 520, com ligação USB, o PDA deve ter a funcionalidade

de USB host (que o 9090 não tem). O host está encarregue de coordenar a con�guração e

transmissão de dados sobre o suporte físico numa ligação USB, dado que periférico cliente não

pode iniciar transmissões, apenas responder a pedidos feitos pelo host. Se o PDA em uso não

o permitir, dever-se-à usar o MIB 510 para efectuar transmissão por porta série.

3.3.4 Detector de Presença

Os motes Mica Z acomplam-se a este sensor através duma ligação de 51 pinos. A detecção é

feita por infra-vermelhos dentro de um campo de 180o à volta do detector e num alcance até 9

metros (anunciado). A alimentação é feita através duma pilha de 9V.

Figura 3.6: Sensor de presença com mote Mica Z acoplado.

3.4 Linguagens e ambientes de desenvolvimento

O Servidor, Gateway e aplicação de PSO foram todos desenvolvidos em C# (Framework 2.0) no

ambiente integrado de desenvolvimento da Microsoft, o Visual Studio 2005. A base de dados que

corre no servidor é em SQL Server 2005. A programação para os nós da rede fez-se em ambiente

Linux (foi usada a distribuição Fedora Core 6), os quais são programados em linguagem nesC.

24

4 Arquitectura Geral

4.1 Cenário global

O cenário em que este projecto se enquadra é virado para uma situação de actuação em áreas

sensíveis, embora o sistema seja su�cientemente �exível para se adaptar e modelar a novos

cenários que envolvem redes de sensores. Desde que o paradigma se mantenha, é possível

reutilizar as funcionalidades para cenários de temperatura, humidade relativa, concentração de

gases, luminosidade, etc., através da uma substituição dos módulos da rede, desde que estes

cumpram as restrições necessárias para serem reconhecidos como uma rede perante o sistema

previamente montado. Sendo assim, o cenário agora descrito é uma aplicação possível para

redes de sensores.

Por área sensível entende-se uma área cuja vigilância, por motivos de segurança, deve ser

escrupulosamente cuidada, tratando-se portanto de uma área reservada ou de acesso restrito. Ao

invés de um cenário onde são usadas câmaras de vídeo, por exemplo, a utilização de sensores com

detectores de presença previne o factor humano e a atenção ou falta dela perante um conjunto de

monitores televisivos, cuja vigilância constante é complicada, dividindo atenções por diversos

monitores. A rede de sensores consegue fazer esta detecção duma forma mais autónoma e

automática, sem a dependência constante de um agente, ao mesmo tempo que impõe um menor

custo e mais rápida instalação. O panorama geral da situação está representado na Figura 4.1.

Figura 4.1: Cenário geral da aplicação: as linhas a vermelho representam o trajecto dos pacotes

desde o nó que lança o alarme (marcado com um �!�)até chegar ao nó sink, ligado à Gateway.

As linhas a verde representam as comunicações entre os Access Points e os PDAs. As linhas a

azul representam as ligações entre as Gateways espalhadas em diversos locais e o Servidor.

Uma rede deste tipo, equipada em cada nó com detectores de presença, transmitirá, caso

tal se veri�que, um sinal de alarme pela rede, que deve chegar aos clientes �nais: o Servidor e a

Gateway. Os sensores da rede devem estar dispostos de maneira tal que cada um consiga fazer

chegar as suas mensagens ao nó central, pois isoladamente, e na falta de meio de transmissão,

tornam-se inúteis. A transmissão assenta sobre um protocolo de encaminhamento de mensagens

subjacente aos nós da rede, a que cabe a tarefa de fazer chegar este tipo de mensagens a

um nó central especí�co (ao invés de inundar a rede com dados desnecessários), vulgarmente

denominado sink. Este nó, conectado a uma Gateway, transmitir-lhe-á todas as mensagens

recebidas em tempo real.

25

A esta Gateway está ligado o Servidor, assim como eventuais PDAs; a ambos são dissemina-

dos os dados provenientes da rede. Cabe ao Servidor a tarefa de ser um sistema centralizado de

recepção, armazenamento e distribuição de dados obtidos das diversas Gateways a ele ligado.

Estes dados são actualizados sempre que a rede ou os PDAs enviam actualizações de informação

e estão disponíveis não só ao técnico que utiliza o Servidor, mas também deve estar disponível

aos PDAs, caso estes o solicitem.

Os PDAs actuam não só como fonte, mas também como destino de dados. Em tempo de

colocação, os agentes instaladores indicam, na aplicação de PSO, onde instalaram �sicamente

o nó, indicação essa que é imediatamente enviada para o Servidor para que este possa registar

esta introdução; remoções e alterações de posições são igualmente comunicadas. No entanto,

após a rede estar devidamente instalada, a aplicação de PSO exerce a sua outra tarefa: a de

recepção. Após estar a funcionar em pleno, a rede envia os seus dados para a Gateway, que

difunde esta informação pelos clientes, onde se incluem os PDAs, que conseguem assim ter

acesso à informação actualizada tal como o Servidor. Esta colocação �manual� prende-se com

o objectivo de minimização de custos na criação de redes deste tipo. Dada a dimensão da

rede, seria extremamente dispendioso dotar cada nó de sistemas de localização própria, como

receptores GPS, que são igualmente mais indicados para redes outdoor. No presente projecto, a

rede pretende-se indoor, o que torna esta solução, além de dispendiosa, inadequada. Os sistemas

de localização indoor, baseados em medições do sinal RF, não são de todo �áveis, pelo que a

opção introduzida é a mais exequível.

Finalmente, cada PDA pode ainda introduzir-se na rede, bastando para isso indicar a sua

própria posição no mapa, tal como faria com um sensor: ao fazer isto, dá a conhecer ao Servidor

e aos restantes PDAs a sua posição (e estes podem fazer o mesmo, fazendo com que toda a

equipa esteja indicada no mapa). Com isto, é possível estabelecer diálogos simples de texto

entre os vários PDAs ligados e o próprio Servidor.

Por vezes zonas da rede �cam isoladas, ou porque as condições de transmissão se deterioram,

ou porque alguns nós intermédios deixam de funcionar, por exemplo, o que leva a que o Servidor

deixe de ter conhecimento não só dos eventuais nós que deixaram de funcionar, como também

daqueles que �caram isolados, embora estes continuem a funcionar em pleno. Nesta situação,

um PDA pode, se tiver um módulo de rede acoplado a ele, escutar as transmissões de alarme

feitas na vizinhança e apresentá-las ao utilizador e, caso tenha cobertura para um Access Point

(ponto de acesso que disponibiliza ligação à rede e ele próprio está ligado à Gateway), enviar

esta informação ao Servidor que assim recebe os dados de uma forma indirecta.

4.2 Segurança no sistema

O sistema global está em alguns pontos vulnerável a ataques do exterior, susceptibilidade essa

que partilha com as demais redes sem �os, quer a componente por Wi-Fi (entre os PDAs e a

Gateway e - eventualmente - esta e o Servidor), quer a componente por RF dentro da rede de

sensores.

No modelo Internet (RFC 1122, simpli�cação do modelo OSI - Open Systems Interconnection

Basic Reference Model - usado na pilha 802.15.4), uma representação abstracta em camadas

para o protocolo de comunicações em sistemas computacionais, e de�nido como apresentado na

Tabela 4.1 [15], é possível identi�car as áreas de actuação do presente trabalho.

As aplicações desenvolvidas concentram-se na camada de aplicação, tanto a nível da rede

26

Tabela 4.1: Modelo Internet (RFC 1122).

Camada de aplicaçãoLocalização de serviçoNovas aplicações, multimediaAplicações adaptativas

Camada de transporteControlo de congestão e �uxoQualidade de serviço

Camada de redeEndereçamento, encaminhamentohandover

Camada de ligação de dados

AutenticaçãoAcesso a dispositivosMultiplexagemControlo de Acesso ao Meio (MAC)

Camada física

EncriptaçãoModulaçãoInterferênciaAtenuaçãoFrequência

sensorial como nas restantes aplicações. As considerações particulares em cada um dos sistemas

são diferentes consoante as comunicações envolvidas e o nível de segurança pretendido, e podem

estender-se em várias camadas, mais particularmente na camada física e de dados.

Estas considerações pretendem apenas indicar e descrever alguns dos potenciais ataques a

que estes tipos de rede estão sujeitos, não tendo sido desenvolvidos métodos para os evitar, já

que não se encontra no âmbito deste trabalho.

4.2.1 Segurança em Wi-Fi [34] [35]

As comunicações falíveis analisadas neste sub-tópico referem-se às transmissões Wi-Fi entre o

Access Point presente na Gateway e os PDAs que a ela se vão ligar e a ele subordinados. As

comunicações com o Servidor, caso se façam igualmente por Wi-Fi, estão sujeitas aos mesmos

condicionalismos de segurança. Caso se faça por via cablada, um sistema de Firewall, com

algum nível de con�guração, fará a segurança da rede. Abaixo estão apresentados os principais

mecanismos de segurança (embora haja outros) implementados para redes sem �os funcionando

sobre 802.11.

Identi�cação de SSID - Service Set Identi�er do Access Point oculta Cada Access

Point contém um (ou mais) SSID, o que corresponde a uma espécie de identi�cador de rede.

Como é necessário conhecer este SSID para nela participar, este funciona como uma espécie de

password de baixo nível, a não ser que o AP o transmita, o que permitirá a qualquer pessoa

receber o sinal e aceder ao AP. Desligar a transmissão do SSID consiste numa barreira inicial

(embora pouco segura) de protecção.

Restrição de utilizadores por endereço MAC Tal como um AP pode ser identi�cado

por um SSID, um cliente identi�ca-se univocamente pelo seu endereço MAC. Para aumentar a

segurança, os AP podem ser programados para apenas permitir a ligação a clientes de MAC

conhecido. É mais indicado para redes de pequena dimensão e com poucas alterações, pois cada

endereço (no máximo de 255) deve ser inserido no AP. Não constitui, ainda assim, uma defesa

considerada �segura�.

27

Wired Equivalent Privacy - WEP O WEP foi o método original de cifra e autenticação

em 802.11, utilizando um sistema de chave partilhada. Neste sistema, tanto os clientes como

o AP na rede usam a mesma chave para encriptar e desencriptar dados, que reside em ambos

os lados e cuja inserção e gestão são feitas manualmente, dado que o WEP não funciona em

parceria com um gestor de chaves. A chave é constituída por 40 ou 104 bits ao qual se juntam

mais 24 bits para o vector de inicialização, resultado numa chave alfanumérica de 64 ou 128 bits

que é então usada para as comunicações. Esta barreira é já facilmente quebrável, por isso na

sua utilização, uma chave 128 bits conjugada com as duas medidas em cima enunciada devem

ser usadas para máxima protecção. A chave deve ser ainda regularmente alterada.

Virtual Private Network - VPN Uma VPN actua como um túnel entre uma rede conhe-

cida (neste caso, a do Servidor) e uma desconhecida (a ligação aos PDA, susceptível a ataques),

entre os quais normalmente está uma Firewall. Esta ligação com o AP está com acesso livre e

sem protecção WEP. Assim que o cliente tenta ligar, deve passar informação de autenticação

(username/password) para o serviço de autenticação/encriptação existente no sistema associado

ao AP. Se a informação for válida, é dado acesso à VPN.

IEEE 802.11i Robust Secure Network O IEEE 802.11i é um acrescento ao standard 802.11

com via a melhorar o panorama de segurança nestas redes, cujos métodos iniciais acabaram por

se tornar insu�cientes e falíveis. Sem protecção a nível da camada de ligação de dados, o TKIP

introduziu-se como medida provisória, sem necessitar de novo hardware, usando mecanismos

semelhantes ao WEP, mas introduzindo conceitos novos como variação de chave por pacote,

veri�cação de integridade de mensagens e troca automática de chave. O TKIP garantia que

cada pacote era enviado com a sua própria chave de encriptação. Posteriormente, tanto o TKIP

(que era transitório) como o WEP foram substituídos pelo CCMP (Counter Mode-CBC MAC

Protocol). Este funciona sobre o AES [36] - Advanced Encryption Standard, componente único

que gere toda a segurança nas comunicações da rede, um sistema de cifras em bloco inicialmente

usado pelo governo dos EUA e agora massi�cado com a introdução no Wi-Fi. É actualmente a

solução �nal para a segurança nas redes sem-�os 802.11.

4.2.2 Segurança em redes sensoriais

As redes sensoriais estão sujeitas a outros tipos de ataques, mas que podem igualmente com-

prometer o total funcionamento da rede. Mais uma vez, as implementações que visam proteger

destes ataques concentram-se fora da camada de aplicação. Algumas soluções a nível de segu-

rança foram sugeridas [37], nomeadamente o EAPM (External Attack Prevention Model ), que

implementa autenticação de mensagens para assegurar a integridade dos pacotes circulantes na

rede. Outra alternativa sugerida é o IADM (Internal Attack Detection Model ), que analisa

os dados que atravessam a rede, e identi�ca comportamentos suspeitos dentro da rede, com-

parando com os tipos de ataque já conhecidos. A plataforma MicaZ, a usada neste projecto,

inclui medidas para a inclusão de segurança AES-128.

Abaixo são referidos os ataques mais comuns a estas redes, embora haja muitos outros [38].

Buraco negro Os buracos negros referem-se a locais na rede onde todo os pacotes que a

ele chegam são descartados, sem informar a fonte que tal pacote não chegou ao seu destino.

Caracterizam-se, por exemplo, por nós cujo identi�cador é anunciado mas que na realidade não

28

existe. Estes nós não são visíveis, e só podem ser encontrados ao monitorizar o tráfego na rede

perdido.

Buraco de verme Neste ataque, o invasor recebe pacotes numa localização da rede e transfere-

os (selectivamente, se tal for esse o interesse) através de um túnel de rede (worm hole) para

uma outra localização da rede, onde os pacotes são reintroduzidos. Muitos dos algoritmos de

encaminhamento não saberão encaminhar estes pacotes recém-chegados, por não conseguirem

obter uma rota válida, enquanto consomem recursos na tentativa de o fazer.

Ataque bizantino Aqui, um nó que se introduz na rede insere uma série de comportamentos

erráticos propositados, mas que aos olhos da rede pode parecer um comportamento casual,

daí a difícil detecção. Este nó pode alternadamente criar loops de comunicação, encaminhar

erradamente pacotes e descartar pacotes selectivamente.

Recusa de serviço - Denial of Service Um ataque deste tipo consiste em tornar um

recurso dum sistema indisponível aos utilizadores legítimos. Há várias formas de o fazer, entre as

quais inundar uma rede com dados, ocupando os seus recursos e impedindo o tráfego legítimo, ou

inundando o servidor de pedidos, mais do que ele pode atender, impedindo os clientes legítimos

de dele usufruírem.

Over�ow da tabela de encaminhamento Nesta situação, um nó intruso anuncia aos nós

da rede caminhos para chegar a nós que não existem. Com este ataque, as tabelas de encami-

nhamento presentes em cada nó enchem-se de dados �ctícios, o que impede que sejam ocupadas

com informação para nós legítimos da rede. Os algoritmos que se baseiam na manutenção de

tabelas, e os pró-activos mais que os reactivos estão vulneráveis a este ataque.

Consumo energético Como a longevidade e funcionalidade de uma rede se baseia na sua

autonomia e durabilidade, alguns ataques focalizam-se no consumo energético de certos nós.

Um nó intruso pode sistematicamente pedir a outro que lhe encaminhe pacotes ou procure rotas

para determinados destinos, existentes ou não, consumindo energia não só a este nó, mas aos

restantes da rota pedida.

4.3 Opções em comunicações

Certas considerações sobre o tipo de comunicações usadas neste trabalho são já discutidas em

outras secções deste relatório. Muito por alto, as comunicações Wi-Fi entre a Gateway e os

PDAs oferecem segurança, rapidez e baixo custo. Esta comunicação está naturalmente limi-

tada às ligações existentes no PDA, sendo as alternativas GPRS (General Packet Radio Service)

ou UMTS (Universal Mobile Telecommunications System). Não só estas últimas obrigam ao

pagamento para prestação do serviço pelo operador (ou instalação de material próprio, ex-

tremamente caro comparativamente a Wi-Fi), como também há questões de cobertura. Com

Access Points ou repetidores de sinal Wi-Fi garante-se facilmente a cobertura de lugares sub-

terrâneos, por exemplo, onde o GPRS/UMTS teria di�culdade em chegar. Já num edifício, o

GPRS/UMTS chegaria a todo o lado com apenas um emissor, com os condicionalismos de custo

atrás referidos. Por questões de custo, �exibilidade do sistema e simplicidade na instalação, o

29

Wi-Fi é naturalmente o melhor método de comunicação para ligar Gateway e PDAs no presente

cenário.

Estes ligam-se normalmente a Access Points (AP) Na situação de haver mais do que um

AP, o endereço IP de cada um dos PDAs deve ser �xo e distinto dentro de cada Gateway, para

que não haja colisões, já que os PDAs são identi�cados e diferenciados dentro da rede pelo seu

endereço.

A rede local formada pela Gateway e PDAs deve conter uma máscara nos três primeiros

octetos dos endereços IP (255.255.255.0) de forma a que os PDAs ligados entrem numa sub-rede

em que apenas o último octeto, que é usado para identi�cação destes elementos, seja usado.

Caso contrário, poderia haver repetição de endereços associado à alteração do penúltimo octecto

(endereços 192.168.0.100 e 192.168.1.100, por exemplo). Tem a limitação de permitir no máximo

255 elementos PDAs em simultâneo, algo que não se prevê que aconteça.

Poderia pensar-se numa solução ad-hoc para ligação entre os PDAs, mas esta não permite

as operações pretendidas para este projecto: adição/remoção de nós não seriam comunicadas a

um Servidor, comunicações entre PDAs estariam limitadas aos dispositivos ao seu alcance, não

seria possível obter qualquer dado sobre a rede do Servidor, etc. Outro motivo bastante sólido

é o fraco alcance dos dispositivos alimentados pelo sistema móvel comparativamente à solução

infra-estruturada de forte potência de sinal. As comunicações dentro da rede são consequência

do hardware instalado nós seus módulos e, pelos motivos descritos também neste relatório,

utilizam tecnologia de RF.

A ligação entre a Gateway e o Servidor far-se-à, muito provavelmente, por rede cabo ou

telefone. A não ser que a distância não o permita, como cenários muito afastados e isolados e

onde à partida não existe uma estrutura de cabos montados que permitam fazer essa ligação,

o que obrigue à utilização de tecnologia alternativa. Nesta situação, soluções como UMTS,

TETRA, CDMA450 ou feixes hertzianos são válidas.

Dentro das comunicações Wi-Fi em si algumas opções foram, no entanto, tomadas, nomea-

damente no que diz respeito ao suporte na camada de transporte. Foi usado TCP (Transmission

Control Protocol) em vez de UDP (User Datagram Protocol). Esta decisão foi tomada tendo

em conta a natureza do projecto em causa e a natureza de ambos os protocolos de transmissão.

O UDP não tem a mesma �abilidade que o TCP, ou seja, quando uma mensagem é enviada,

não há forma de saber se foi recebida ou perdida pelo caminho. Num sistema desta natureza,

não é concebível perder um alarme por motivos de perda de pacotes, e se há um sistema que

assegura esta entrega (TCP), então esse sistema deve ser adoptado. O UDP é mais indicado

para comunicações em que a perda de um pacote não compromete a integridade da mensagem

global, como seja voz ou vídeo. O UDP não garante a entrega ordenada de mensagens; actu-

almente não é problema, pois as mensagens não estão partidas por diversos pacotes, mas se

de futuro vier a acontecer, e for necessário reconstruir um conjunto de pacotes no destino, a

ordenação de pacotes é essencial.

Uma situação em que o UDP é favorável sobre o TCP é na possibilidade que tem de fazer

broadcast 4 e multicast 5 aos clientes, coisa que este não é capaz. Esta particularidade torna-se

mais interessante quando o número de clientes aumenta consideravelmente, mas como não chega

a ser o caso, as mensagens são enviadas por iteração de endereços dos clientes.

4Enviar informação para todos os nós da rede ao mesmo tempo5Enviar informação para vários nós da rede ao mesmo tempo

30

5 Servidor

5.1 Aproximação ao problema

Em tecnologias de informação, um servidor (ou aplicação de servidor) é um �programa que

aceita conexões com o objectivo de servir pedidos através do envio de respostas�, serviços

prestados a outros sistemas (clientes) dentro de uma rede. No presente projecto, os clientes

são as Gateways e os serviços prestados são a disponibilização dos dados recolhidos da rede

sensorial aos clientes.

O Servidor actua como o sistema central de armazenamento de informação fornecido pelas

diversas Gateways, que deve estar disponível sempre que solicitado pelos clientes destas (os

PDA), além de, naturalmente, disponibilizar a informação prontamente ao utilizador diante do

sistema, que pode intervir directamente sobre a informação nele contida. Em base de dados

são guardadas informações referentes às diversas redes de sensores e, sempre que tal ocorra, de

PDAs que a elas se liguem. A esta informação, são adicionados mapas a que correspondem os

locais sobre os quais são montados os sensores, para que seja visível a sua posição relativa em

cada cenário. Esta informação é naturalmente cruzada com os dados das redes, pois a cada

mapa está associado uma Gateway.

O sistema deve reconhecer os clientes que a ele se liguem (as Gateways) e processar univo-

camente os dados recebidos de cada uma delas, para que a qualquer altura se possa reconhecer

a proveniência de uma dada informação e a localização de um sensor a ela associado. Para

garantir essa associação unívoca, os endereços IP de cada uma das Gateways devem ser �xos de

modo a que, sempre que uma se ligue, seja possível reconhecer qual é (e com isso, reconhecer a

sua localização geográ�ca, a topologia da rede a ela ligada, etc.). Também o servidor deve estar

provido de um endereço IP �xo para que as Gateways possam a ele aceder com consistência e

�abilidade sem necessidade de actualizar o endereço.

Pretendeu-se que o que transparecesse para o utilizador fosse simples e de interpretação e

intervenção rápida, através de um interface ligeiro e fácil de compreender. Todo o Servidor foi

feito de raiz em C#.

5.2 Funcionamento

O Servidor de qualquer rede, ao acumular os dados a ela necessários e dela provenientes, deve

assegurar a possibilidade de a qualquer altura tais serem requisitados, sob compromisso de

tornar inútil o sistema de quem dele depende. No presente caso, são as Gateways que se irão

ligar para servir de ponte entre servidor e rede de sensores (e eventualmente PDAs), tendo tanto

o Servidor como as Gateways endereços IP externos �xos para conexão imediata e persistente

das comunicações TCP entre os sistemas. A continuidade desta ligação é assegurada por um

temporizador, ao �m do qual caso não haja recepções por parte de um determinado cliente, a

ligação assume-se fantasma e é encerrada pelo Servidor. Para impedir tal, cabe àGateway enviar

pacotes regulares de keep-alive ao Servidor de forma a garantir a continuidade da ligação. Este

método previne a persistência de ligações já extintas no sistema. Uma exempli�cação básica da

ligação é representada na Figura 5.1. As ligações assinaladas são efectuadas com tecnologias

alternativas, consoante a topologia do terreno e a distância entre os sistemas. Podem ser ligações

cabladas convencionais, até ligações wireless terrestres ou por satélite.

Para identi�cação da localização de cada uma das Gateways, o Servidor contém em base

31

Servidor

��

HHHHH

Gateway 1 ... Gateway N

Figura 5.1: Ligação entre Servidor e diversas Gateways.

de dados informação referente ao endereço IP de cada uma delas, assim como a localização

correspondente, de forma a que assim que uma se ligue, se consiga saber, através do endereço

(possível apenas quando este é �xo), a que Gateway corresponde. Ao fazer esta associação,

em posteriores conexões os dados de redes de sensores contidos em base de dados permanecem

associados a um determinado endereço IP. Além dos sensores, também se assegura a correcta

ligação a mapas. As mensagens provenientes das diferentes Gateways, e após uma validação

por checksum simples, proporcionam a actualização imediata dos dados contidos em base de

dados, logo após recepção.

Como cada Gateway tem associada uma rede de sensores, rede essa que pode estar dis-

tribuída ao longo de vários níveis/andares, o Servidor guarda igualmente informação relativa

aos mapas de cada uma, estando portanto também associados a endereços IP. Esta associação

é feita assim que o mapa é adicionado, altura em que se deve escolher de entre as Gateways

disponíveis em base de dados. Uma Gateway pode ter vários mapas, mas um mapa apenas pode

estar associado a uma Gateway, pois estando um mapa associado a uma zona contemplada por

uma Gateway, não pode servir outra com a qual não esteja relacionada.

Com esta identi�cação, é possível reconhecer a origem (associando o endereço a uma loca-

lização especí�ca) e guardar a informação referente a cada nó de cada uma das redes, salva-

guardando a sua origem. Esta diferença é feita recorrendo à concatenação entre identi�cador

de rede de cada nó e o último octeto do endereço IP da Gateway a ele associada, intercalados

com o algarismo 0. A título de exemplo, o nó 15 da Gateway dada pelo endereço 174.84.124.96

adquire o identi�cador 15096 dentro do Servidor (guardando no entanto o identi�cador original

do nó). A inserção do algarismo 0 serve para evitar coincidências que poderiam ocorrer na sua

ausência: por exemplo, o nó 11 da Gateway com último octeto de IP 15 daria o identi�cador

1115, que seria exactamente o mesmo do nó 111 na rede 5. Com o 0, este problema evita-se

por completo.

Este identi�cador é produzido não só para distinção visível e identi�cável ao utilizador do

Servidor, mas também pois em bases de dados, cada identi�cador deve ser único. No entanto, a

nível de comunicações com as Gateways em qualquer dos sentidos, prevalecem os identi�cadores

próprios e únicos de dentro das suas rede, pois a selecção de rede já está feita e não ocorre o

risco de saber a que Gateway corresponde determinado nó.

A interacção disponível com os dados armazenados aconselha-se limitada, pois esta deve

caber aos técnicos no terreno munidos de um PDA e que montam/movem/eliminam sensores

in loco. Não é recomendável mover-se a posição de um nó no Servidor sem efectivamente o

mover no local onde está instalado. No entanto, não deve ser impossível, por via de uma

necessidade, efectuar estas alterações, como seja situações de remoção em massa de um local ou

de remoção por mau-funcionamento declarado, em que possa ser conveniente fazer esta alteração

imediatamente no Servidor. Por isso essas opções estão disponíveis no Servidor, embora, como

32

Figura 5.2: Fluxo de dados dentro do Servidor. O VIM, que ocorre em todos os sistemas,

representa a Veri�cação de Integridade Mensagem: início, �m e checksum esperados.

dito acima, seja recomendável que estas alterações sejam sempre efectuadas pelo agente no

terreno.

O Servidor deve enviar dados aos PDAs se assim o solicitarem (pedidos encaminhados através

da Gateway), estando ainda possibilitado o envio de mensagens simples aos PDAs ligados.

Naturalmente que apenas aqueles que se anunciarem estarão disponíveis para esta troca, e um

agente que esteja a usar o Servidor pode enviar mensagens a um PDA especí�co ou difundir

uma mensagem por todos os ligados (nesta situação, até os não anunciados a receberão). Como

também pode ser o receptor destas mensagens simples, o Servidor tem dentro do sistema global

o identi�cador 0 (zero).

Todas as alterações efectuadas sobre a base de dados, na forma de alterações dos dados das

Gateways ou dos �cheiros de mapas, assim como actualizações de informação referente aos nós

da rede ou alarmes disparados, são guardados num registo histórico (log) para eventual consulta

a qualquer altura, com �ltragem por tipo e datas.

O Servidor de rede presta assim serviço de recolha e disponibilização �ável e sempre actua-

lizada da informação proveniente das diversas redes.

33

5.3 Interface e Funcionalidades

A interface utilizador do Servidor tenta, na medida do possível, apresentar ao utilizador o

máximo de informação possível em simultâneo, de forma a tornar menos confuso o acesso à

informação. Pode ver-se ao mesmo tempo os mapas, os sensores e chegadas de informação

ao Servidor, estando o acesso à restante informação, como o registo histórico ou as Gateways

rapidamente acessíveis através de menus. Pode observar-se na Figura 5.3 a janela principal.

Figura 5.3: Janela da interface do Servidor.

O Servidor ao iniciar carrega automaticamente os dados contidos em bases de dados, popu-

lando as tabelas apresentadas, que são guardados também de forma automática pelo sistema

sempre que se registarem alterações (os valores N/A correspondem a números não aplicáveis).

As comunicações, essas, são iniciadas/terminadas a ordem do utilizador, através de botões co-

locados para o efeito. É possível ainda adicionar/editar/remover posteriores Gateways que se

queiram incorporar no sistema, da mesma forma que se pode fazê-lo com mapas.

Estão ainda disponíveis mecanismos que permitem interagir directamente com a Base de

Dados (5.4), fazendo um bypass à Interface, uma ferramenta chamada SQL Analyser, incorpo-

rada na aplicação, mas cuja utilização tem um propósito mais de debug e manutenção do que

fazer parte do funcionamento típico desta aplicação.

Ao abrir um mapa, é possível ver projectado sobre ele todos os nós da rede, móveis ou �xos,

a rapidamente obter informação sobre eles. O seu ícone é característico do seu tipo, assim como

também se altera na ocorrência de alarme. É ainda aqui que, escolhendo um dos nós móveis,

se permite que sejam enviadas mensagens simples de texto a um (ou todos) deles.

Finalmente, dado que todas as ocorrências são guardadas num registo histórico, é de todo

conveniente que seja possível aceder a esta lista de forma a consultá-la. Para tal, um pequeno

módulo na aplicação permite listar, por categoria e por intervalo temporal, todos os registos de

ocorrências (Figura 5.5).

34

Figura 5.4: Apresentação de um mapa com nós projectados.

Figura 5.5: Janela do Registo Histórico.

35

5.4 Base de Dados

A base de dados do sistema, desenvolvida em SQL, ponto de concentração e arquivo dos dados

das diversas redes, necessita de poucas tabelas e relações para assegurar a salvaguarda dos

dados, contendo um conjunto de relações que permitem uma e�caz procura de dados. Um

diagrama de representação da base de dados é apresentado na Figura 5.6.

Figura 5.6: Diagrama de Base de Dados.

É visível no diagrama quer as chaves primárias quer as chaves estrangeiras constituintes

de cada tabela (as linhas ligam as chaves estrangeiras, as primárias estão representadas por

uma chave). É ainda visível a tabela a que corresponde o registo histórico, cuja escrita é

assegurada através de uma série de triggers nas outras tabelas que irão gravar no registo alte-

rações/adições/eliminações dos seus tuplos. Este registo histórico tem uma dimensão limitada

pré-de�nida, actuando o registo histórico como um bu�er circular assim que a capacidade má-

xima é atingida.

Um mutex 6 garante acesso exclusivo à base de dados por cada tarefa que dela necessite,

garantido correcção dos dados.

6Espécie de variável bloqueante que garante exclusividade de acesso a determinado recurso; normalmente

usado em programas com muita concorrêcia de recursos.

36

6 Gateway


Uma Gateway, em termos genéricos, serve de interface entre dois sistemas que usam protoco-

los distintos, recebendo informação de um lado e convertendo-a para o formato necessário ao

terminal oposto, de uma forma transparente para ambos os sistemas. No presente trabalho,

pretende-se efectuar esta tradução entre um Servidor e redes, sendo estas do tipo redes sensori-

ais ou um conjunto de terminais PDAs, onde é desejável poder-se endereçar univocamente um

nó em qualquer uma das redes a partir do Servidor ou de outro nó PDA cliente.

Para a identi�cação de PDAs, conferiu-se àGateway (suporte PC) a capacidade de identi�car

univocamente um destes elementos através do seu endereço IP de rede local. Esta possibilidade

permite o envio de informação unidireccional (ou multidireccional, se for essa a intenção) a

qualquer um dos restantes PDAs, quer pelo Servidor, quer pelos restantes clientes deste tipo.

O endereçamento dentro da rede de sensores é feito pela própria rede, de forma a que caberá

a esta assegurar a chegada de uma mensagem ao sink, pois, ao contrário da rede de PDAs (onde

cada elemento liga directamente à Gateway), apenas um dos elementos está ligado (para onde

a informação da rede é canalizada). As mensagens provenientes da rede são convertidas pela

Gateway numa mensagem reconhecível, tanto pelo servidor como pelos PDAs.

Foi objectivo que esta Gateway conseguisse uma ligação e�caz, �ável e transparente entre as

três partes a ela ligadas: servidor, rede de sensores e rede de PDAs. Deveria também assegurar

autonomamente a manutenção das ligações entre os três, assim como poder permitir a troca

de informação simples entre e para os clientes PDA da rede. Esta possibilidade é uma forte

garantia de expansibilidade do sistema para futuras trocas de informação. Toda a Gateway foi

feita de raiz em C#.

6.2 Funcionamento

Sendo a Gateway uma máquina cuja função é de autonomamente fazer a transformação e

encaminhamento correcto de mensagens, são estes os pontos a focar no desenvolvimento da

mesma. Esta não deve actuar como um terminal end-user, mas deve sim prestar os seus serviços

autonomamente com intervenção mínima de um técnico que assegure o correcto funcionamento

de todas as transmissões de dados. Estando no �meio�, a falha deste elemento compromete o

total funcionamento do sistema global.

Para assegurar a correcta permanência da ligação ao Servidor, sempre que esta cai ou é

terminada, a Gateway tenta, periodicamente, reestabelecer a ligação, e continuará a fazê-lo

até o conseguir. Na situação oposta, em que a Gateway actua como um servidor para os

PDAs, cabe a estes fazer esta detecção (pois actuam como clientes). O controlo a montante

feito neste caso é uma monitorização da recepção das mensagens provenientes dos clientes, que

devem periodicamente anunciar a sua presença como forma de garantir a sua existência na

rede. Findo um determinado período sem enviar dados, o PDA assume-se �morto� (deixou de

comunicar sem proceder ao fecho da comunicação) e a sua ligação é terminada. Esta forma de

controlo existe para cobrir as situações em que por qualquer motivo o PDA perdeu meio de

ligação com a Gateway (como por exemplo por falta de cobertura wireless) e não foi possível

detectar o correcto fecho da ligação.

Durante o seu funcionamento, todas as mensagens que chegam à Gateway passam por um

37

Figura 6.1: Fluxo de dados na Gateway. O VIM, que ocorre em todos os sistemas, representa

a Veri�cação de Integridade Mensagem: início, �m e checksum esperados.

�ltro de integridade simples, que assegura a correcta estrutura das mesmas (início e �ns de�nidos

para tipos conhecidos). Caso estes testes falhem, as mensagens não são sequer retransmitidas,

poupando-se esse processamento desnecessário aos terminais de destino; caso contrário, são

então para eles encaminhadas. Consoante o tipo de mensagem, podem ser retransmitidas para

todos os terminais ou apenas para um, possibilidade assegurada através de campos existentes

dentro das tramas das próprias mensagens, correspondentes aos identi�cadores de destino.

Nos tipos de mensagens em que não se pretende um destinatário único, todos os elementos

da rede são automaticamente tornados destinatários de todas as mensagens, excepto a rede

sensorial, naturalmente, pois não faz uso das mensagens circulantes entre servidor e PDAs,

mas cuja informação interessa a todos os outros. A título de exemplo, quando se registar uma

situação de alarme num determinado sensor, a Gateway fará chegar essa informação quer ao

Servidor, quer a todos os PDAs ligados. Se um PDA anunciar a colocação (por posição) de um

sensor dentro da rede, todos os restantes PDAs ligados, assim como o Servidor, serão noti�cados.

A difusão se mensagens é total, excepto, como visto acima, se pretenda um envio ponto-a-ponto.

O �uxo de dados dentro da Gateway está representado na Figura 6.1. Os números representam

os identi�cadores de mensagens recebidas, que podem ser observados no Capítulo 9.

Para este envio ponto-a-ponto se tornar possível (ao contrário do multi-ponto), cada PDA

deve �anunciar-se� perante a rede, de forma a que todos os clientes possam saber da sua

existência (a Gateway sabe desta ligação, mas como é �anónima�, não pode fazer nada com

ela). A noti�cação é, além de um número, também um nome e uma posição (como será analisado

em (6.3)). Ao anunciar-se, o PDA gera uma mensagem de �Novo nó� (9.2.1), contendo o seu

identi�cador (obtido do seu endereço IP), nome e posição. No entanto, já que ao se anunciar

38

é adicionado um novo nó �móvel� no Servidor, quando se desliga este deve sair. Para o fazer,

a Gateway toma a iniciativa, ao detectar a desconexão do PDA, de enviar uma mensagem de

remoção (9.2.2) para o Servidor (e restantes PDAs), o que lhe é possível dado que conhece

identi�cação obtida daquele através do endereço de cliente a ela ligado.

De referir que, caso um dos três elementos tenha a sua ligação à Gateway desfeita, os

restantes elementos mantêm, sempre que possível, a troca de informação entre si.

6.3 Interacção entre sistemas

A Gateway serve de interconexão entre três conjuntos de sistemas: o Servidor, os PDAs e a

Rede de Sensores. Para cada uma delas, deve efectuar a gestão de ligação e a correcta tradução

de mensagens, permitindo que sejam reconhecidas pelas restantes partes interessadas, de forma

particular para cada uma das partes. Uma exempli�cação de uma situação tipo de troca de

mensagens entre os três sistemas pode observar-se na Figura 6.2.

6.3.1 Interacção com o Servidor

Perante o Servidor, a Gateway actua como um cliente deste. A interacção é relativamente

simples, baseando-se na manutenção da ligação e da transmissão de dados por parte da Gateway.

A permanência desta ligação é assegurada através do reestabelecimento automático da conexão,

que é tentado continuamente até à ligação ser restabelecida. Mesmo numa situação em que o

Servidor esteja inatingível, a Gateway continuará as tentativas, e assim que o Servidor volte a

�car à escuta, a conexão será reestabelecida e o sistema retomará o seu funcionamento normal.

O envio de mensagens para o servidor é simples, sem qualquer processamento ou selecção (pois

apenas existe uma conexão para o Servidor). Em comunicações do tipo troca de mensagens

simples (9.2.4), o Servidor está identi�cado com ID=0, utilizado na selecção quer do remetente,

quero do destinatário da mensagem.

6.3.2 Interacção com PDAs

Nas ligações aos PDAs, como podem existir vários elementos deste tipo e pode ser desejável

estabelecer uma comunicação unívoca entre dois dos sistemas (PDA<>Servidor, PDA<>PDA),

é necessário identi�car e distinguir as entidades Servidor e PDAs dentro da própria Gateway.

A ideia base é simples: a Gateway conhece o endereço IP (único) de cada cliente PDA a si

ligado no momento da ligação (pois actua como servidor destes), endereço esse que pode ser

usado como diferenciação entre os vários clientes. Certas mensagens contêm espaços para aco-

modar estes identi�cadores que posteriormente permitirão fazer a selecção de cliente à chegada

da mensagem. Caso se pretenda enviar a todos os intervenientes, basta colocar um endereço

de difusão (255.255.255.255) no lugar do endereço de destino que a Gateway envia a todos os

PDAs a si ligados (ver Tabela 9.2).

À chegada de uma mensagem de �Novo nó�, a Gateway observa os campos de IP (se for esse

o tipo de mensagem), e envia para todos os clientes no caso de o destino ser 255.255.255.255.

Caso contrário, procurará, de entre os clientes ligados, se há um que corresponde a este endereço.

Se não existir, a mensagem é descartada.

Apesar de ligado, o PDA não está �visível� na rede, pois um utilizador deve ser mais do

que um número. Tem também um nome e uma posição, anunciados perante a rede assim que o

39

Figura 6.2: Exempli�cação de uma situação de troca de mensagens entre os três sistemas.

utilizador o desejar (activação por botão no cliente PDA). Após esta identi�cação, o Servidor

�ca a �conhecer� este utilizador, mas também a Gateway, como �ponte� entre Servidor e PDA,

tem agora uma responsabilidade de assegurar a validade desta identi�cação. Por isso, dado que o

cliente passou a �existir� na rede aos olhos do Servidor, também este deve saber da desconexão

desse mesmo cliente. Por isso, quando tal se veri�ca, cabe à Gateway tomar a iniciativa de

avisar o Servidor o sucedido, altura em que gera e envia uma mensagem de eliminação de nó

9.2.2 Mas como atribuir um número único que identi�ca o cliente?

A identi�cação dos nós PDA na rede é feita utilizando o último octeto do endereço IP destes,

pois sendo a rede de PDAs uma rede local associada à Gateway, este identi�cador é distinto

para cada um. Convencionou-se um sistema de identi�cação que coloca o algarismo �7� atrás

desse mesmo identi�cador. Essa distinção prende-se com o facto de ser necessário diferenciar

um identi�cador de PDA de um identi�cador na Rede de Sensores, pois é teoricamente possível,

por exemplo, haver um sensor de identi�cador 120 e um PDA com IP dado por 192.168.1.120.

Esta colisão veri�car-se-ia quando, por exemplo, fosse dada uma ordem de eliminação de nó

120, e cada nó deve ter um identi�cador único. Assim, o nó PDA passa de 120 para 7120.

Naturalmente, não será permitido usar identi�cadores iniciados por 7 na rede de sensores.

O servidor tem ainda o identi�cador '0', quando se pretende que a mensagem chegue apenas

ao servidor, e o identi�cador '65535' (255.255) corresponde à difusão de mensagens para todos

os clientes. Este tipo de identi�cação é usado no envio de mensagens simples (9.2.4), ou na

40

adição de sensor (9.2.1).

O porquê destes dois tipos de identi�cação, em vez de um único, prende-se com as circuns-

tâncias em que cada pedido é feito. É preciso o PDA anunciar-se dentro da rede para que o seu

identi�cador exista (apesar de também se gerar na Gateway, o utilizador pode não ter intenções

de se fazer anunciar), pelo que até lá não é possível fazer uso deste número. O anúncio também

não pode ser automático por parte da Gateway, pois a anunciação de um nó PDA deve levar a

sua posição e o nome do utilizador. Se o número fosse automaticamente gerado e disponibili-

zado para o Servidor, as mensagens enviar-se-iam para um número, e não um �utilizador�, pois

até a anunciação por parte do utilizador, é impossível saber de quem se trata.

Naturalmente, a Gateway deve ainda assegurar a correcta detecção do fecho de ligação com

os PDAs, para poder avisar com legitimidade o Servidor da conexão e desconexão dos clientes.

6.3.3 Interacção com a Rede de Sensores

A interacção com a Rede de Sensores faz-se através de comunicações via USB com um nó

da rede, que actua como o sink, recebendo os dados daquela. Dado que novamente se trata

de apenas uma ligação, as funções da Gateway para com a Rede de Sensores são apenas de

traduzir as mensagens recebidas pela rede naquelas que o restante sistema utiliza. Todas as

mensagem que chegam da rede são difundidas normalmente, para o Servidor e todos os clientes

PDA ligados.

6.4 Interface

Dada a ausência de um utilizador que controle constantemente o funcionamento da Gateway, a

interface fez-se simplista e tão clara quanto possível, como se pode observar na Figura 6.3.

Figura 6.3: Interface utilizador da Gateway.

Os controlos são essencialmente para lançar e terminar os diversos serviços e escolher o

intervalo de reconexão da Gateway perante o Servidor.

41

7 Percepção da Situação Operacional


A Percepção da Situação Operacional (PSO) consiste numa aplicação de software que corre

sobre um PDA, permitindo, a um utilizador dele munido, actuar directamente sobre a rede

(movendo, adicionando e removendo nós) e dela receber informações oriundas ou do Servidor

(utilizando dados armazenados em base de dados) ou da Gateway, que retransmite directamente

aos PDAs alertas na rede.

A aplicação desenvolvida é capaz de se conectar à Gateway de rede, mantendo e assegurando

esta ligação, que assim faz a ponte para recolha de dados desde o Servidor ou a rede sensorial.

Esta informação é disponibilizada na aplicação de uma forma clara e simples, permitindo que

seja uma mais-valia quer em tempo de instalação de rede, quer em tempo de vigilância, ao

receber informação em tempo real, não só da rede sensorial, como também de outros agentes

munidos de igual aplicação. Caso não haja ligação à Gateway disponível, o aplicação de PSO

pode funcionar em modo �Local�, recebendo dados apenas do módulo de rede a ele acoplado.

É também interessante que um agente munido de um PDA possa tornar-se membro activo

da rede subordinada à Gateway, por isso conferiu-se à aplicação de PSO capacidades de se

anunciar perante a rede, permitindo que o Servidor (e restantes PDAs) tomem conhecimento

da existência e da posição de cada agente (ao anunciar-se, o agente indica a sua posição sobre

o mapa onde se encontra), assim como permitir troca de mensagens de texto simples entre os

extremos do sistema (Servidor e diversos PDAs).

(a) Um PDA envia... (b) ...e recebe resposta.

Figura 7.1: Envio e recepção de mensagens.

Tirando partido do paradigma Orientado a Objectos do C#, e de forma a deixar o programa

aberto para futuras extensões a novos sensores, por exemplo, fez-se com que cada tipo de sensor

fosse herdado de uma classe �pai� sensor. Sendo assim, futuramente será mais simples incluir

um novo tipo de sensor ou nó (implementado também do lado do Servidor). Toda a aplicação

foi feita de raiz em C#.

43

7.2 Funcionamento

Os PDAs actuam essencialmente como clientes (numa perspectiva Cliente-Servidor) da Ga-

teway. A ligação é mantida através do envio periódico de mensagens de keep-alive (pacotes

vazios) para a Gateway, que interpretará estes pacotes como desejo de cada PDA de manter a

sua ligação activa. A ligação encerrar-se-á caso o PDA/Gateway se desligue ou na situação em

que os pacotes deixem de ser recebidos, altura em que ocorrerá um timeout na Gateway e a

ligação será propositadamente terminada. O envio de informação é bidireccional entre ambas

as partes, sendo que toda a informação transmitida a partir de um PDA para o Servidor é di-

fundida pela Gateway para todos os restantes PDAs ligados, recebendo cada um, naturalmente

(resultado da difusão), as suas próprias mensagens acabadas de enviar.

Apesar de aos olhos da Gateway um PDA não ser mais do que um endereço IP, este pode,

se tal o desejar, anunciar-se, indicando a todos (Servidor e restantes PDAs) a sua posição sobre

o mapa, assim como o seu nome (obtido através do nome dado como utilizador do PDA), o

que vai permitir que sejam trocadas entre os diversos extremos da rede mensagens simples de

texto. No entanto, como está dentro da rede em simultâneo com os sensores, deve ter um

endereço único que o distinga como um cliente do tipo PDA. E algo único que caracteriza o

PDA é o seu endereço IP dentro da rede, que é então usado para atribuição deste identi�cador.

O último octeto do endereço (suponhamos, o 85 em 79.145.32.85) é concatenado ao algarismo

inicial '7' (todos os identi�cadores de PDA terão de ter este início) para formar o identi�cador

único. Caberá posteriormente à Gateway efectuar a retransmissão correcta de mensagens entre

os diferentes sistemas.

Figura 7.2: Fluxo de dados na aplicação de PSO. O VIM, que ocorre em todos os sistemas,

representa a Veri�cação de Integridade Mensagem: início, �m e checksum esperados.

Localmente, a aplicação de PSO carrega um mapa sobre o qual um agente/utilizador pode

adicionar/mover/remover sensores (presumindo que também o faz �sicamente no sensor em

causa) através de uma interface do tipo tap&hold (carregar e segurar), característica dos sis-

temas PDA. A Gateway canaliza para a rede de PDAs toda a informação referente à rede,

independentemente do mapa que estiver carregado na altura da ocorrência. Isto permite alter-

44

nar entre mapas sem requisitar nova informação do Servidor e tornar possível poder receber

e guardar informação de um sensor para o qual se recebe uma noti�cação de alarme, mesmo

não estando localizado no mapa em uso. À colocação/edição de um sensor está associado o

nome do colocador (owner do PDA). Esta pessoa é a única a que é permita efectuar posteriores

alterações à situação do sensor, a não ser que o PDA esteja com o utilizador �Admin�, a quem

é dado total permissão (o Servidor actua também como Admin).

Estes mesmos mapas são carregados e abertos na totalidade, sendo visível uma fracção da

imagem correspondente à área possível tendo em conta o tamanho do visor do PDA. É possível

deslocar-se sobre o mapa (carregando sobre ele e arrastando), ocultando os sensores visíveis no

processo, de forma a acelerar esse mesmo arrastamento; as novas posições são determinadas

apenas tendo em conta a posição em que o mapa é largado, não executando por isso proces-

samento paralelo durante o arrasto. O sistema pode no entanto tornar-se pesado e lento para

redes de sensores com elevado número de nós visíveis em simultâneo, pois as operações de

esconder/mostrar devem propagar-se a todos eles.

É guardado em memória um registo dos alarmes ocorridos na rede desde que a aplicação está

em execução (limpável a qualquer altura), quer globalmente, quer a nível de nó e, na ocorrência

de alarme, o gra�smo associado aos sensores é alterado para fácil identi�cação, como se vê na

Figura 7.3. É possível também enviar mensagens para todos os utilizadores (e também para o

Servidor) do tipo PDA que estejam ligados a determinado momento à Gateway.

Figura 7.3: Interface de utilização da aplicação PSO.

A aplicação pode ainda requisitar ao Servidor a con�guração de toda a rede associada à

Gateway a que o PDA está ligado (apropriado para quando o PDA acaba de se ligar e necessita

de informação de rede), assim como enviar mensagens ao Servidor, a um PDA em especí�co

(desde que este se tenha anunciado perante a rede) ou a todos os PDAs.

Em termos de interacção com a rede, o PDA recebe mensagens que escuta da rede através

do nó MicaZ a ele acoplado (recepção limitada ao raio de captura da antena RF) e apresenta

os resultados apenas sobre a forma de um identi�cador. Dado que os nós na rede não contêm

qualquer informação além do seu próprio identi�cador (por exemplo, não têm informação da

posição), não é possível projectá-los sobre o mapa, pelo que apenas funcionam como noti�cações,

45

apresentadas ao utilizador. No entanto, o PDA encaminha estas mensagens ao servidor. Esta

funcionalidade é introduzia para situações em que fracções da rede, isoladas por qualquer motivo

de contacto com a Gateway (como por exemplo, mau funcionamento de nós intermédios de uma

rota), não conseguem transmitir informações. O PDA pode então apanhar estas transmissões,

apresentá-las ao utilizador e fornecê-las ao Servidor.

7.3 Interface

A interface com o utilizador da aplicação de PSO, dado que é a principal interacção com a

rede, foi tentada tornar o mais possível simplista e acessível, apenas com funções essenciais e

facilmente atingíveis. A aplicação recorre a �cheiros de mapas (extensões permitidas: PNG,

JPG, GIF, BMP) que devem estar acessíveis à aplicação, ou seja, na pasta My Documents ou

no cartão de memória. A ligação com os sistemas exteriores faz-se via Wi-Fi/GPRS (consoante

o suporte existente) com a Gateway, e via porta série (caso existente e o PDA suporte modo

host) com a rede.

(a) Janela de identi�cação de alarmes. (b) Informação detalhada para um nó.

Figura 7.4: Envio e recepção de mensagens.

Sempre que um alarme é despoletado, quer proveniente de um outro PDA (retransmitido

pela Gateway) ou do nó acoplado, um sinal sonoro é ouvido e as estruturas de alarmes escritas.

Os nós afectados alteram o seu ícone para mais fácil identi�cação e mudam para um estado de

�Alarme accionado�. Este estado deve ser atendido para o nó voltar ao seu estado normal de

vigilância, dentro das estruturas da aplicação. Estas alterações são feitas localmente para cada

PDA.

46

8 Rede de Sensores


O que se pretende para a rede sensorial é conseguir estabelecer uma rede espacialmente distri-

buída de módulos Mica Z (alguns dos quais equipados com detectores de presença), que consiga,

no seu todo, fazer chegar os alarmes accionados por alguns dos módulos até um nó central que,

ligado a uma Gateway local, faça chegar a informação posteriormente a um Servidor remoto.

Apesar de apenas alguns dos nós estarem equipados com sensores de movimento, todos eles

devem participar e contribuir para o encaminhamento de pacotes dentro da rede. O encami-

nhamento a que a rede recorre é o Collection Tree Protocol (CTP), um algoritmo nativo no

sistema Tiny OS e cujo funcionamento é melhor descrito em (8.2). Não só a rede deve ser

auto-con�gurável (estabelecer por si só uma rede de raiz à medida que nós forem surgindo na

vizinhança um dos outros), como também auto-regenerável, isto é, caso algum dos nós desapa-

reça, por exemplo, a rede deve sozinha conseguir recon�gurar-se e criar um novo caminho (mais

curto, se possível) até ao nó central. Da mesma forma, caso surjam novos nós, a rede deve dele

tirar proveito caso a sua introdução contribua para mais e�cazes rotas de encaminhamento de

pacotes. Todas estas questões estão a cabo do CTP.

Também foram desenvolvidos alguns nós especiais para se acoplarem aos dispositivos móveis

PDAs, que não participam de todo nas tarefas da rede, mas em vez disso escutam a informação

que conseguem apanhar do meio (limitado ao alcance permitido pela antena), e disponibilizam-

na ao utilizador. O sistema desenvolvido para todos os tipos de nós teve por base alguns progra-

mas exemplo que acompanham o TinyOS (TestNetwork e BaseStationCC2420) e focalizam-se

na camada aplicacional.

8.2 Encaminhamento dentro da rede

O encaminhamento de pacotes dentro da rede recorre ao algoritmo Collection Tree Protocol [39]

(CTP), baseado num algoritmo de colecção em árvore, e é nativo do TinyOS. O seu funcio-

namento é o seguinte: um (ou mais) nós da rede anunciam-se como nós �raiz�; os restantes

estabelecem árvores de encaminhamento até esses nós. O CTP é livre de endereçamento na

medida em que um nó não envia um pacote até uma �raiz� em particular. Ao invés disso,

escolhe implicitamente uma �raiz� através da escolha do nó seguinte. Os nós geram rotas até

às �raízes� da árvore usando um gradiente de encaminhamento.

O CTP assume que tem estimativas quanto à qualidade da ligação a alguns dos vizinhos.

Estes fornecem uma estimativa do número de transmissões necessárias para que um nó faça

chegar um pacote unicast ao qual o seu ack7 seja recebido com sucesso (efectuado a nível da

camada de ligação de dados - link layer). O CTP tem diversos mecanismos de forma a melhorar

a garantia de entrega, mas não garante total garantia. É um compromisso de melhor esforço,

mas exaustivo.

O gradiente de encaminhamento é o das transmissões esperadas (ETX - Expected Transmis-

sions). Uma raiz tem um ETX de 0, e o ETX dos restantes nós é dado pela soma do ETX

do seu nó �pai� com o ETX da ligação até ele. Dado um conjunto de rotas válidas, caberá ao

CTP escolher de entre as disponíveis a que tiver um ETX menor.

7Acknowledgement : mensagem de con�rmação

47

Este encaminhamento não está isento da ocorrência de loops na rede, e o comportamento

perante tal está demonstrado na Figura 8.1. Estes podem ocorrer quando um nó escolhe uma

nova rota cujo ETX é substancialmente superior ao anterior, decisão tomada por falta de

conectividade ao �pai� anterior, por exemplo (Figura 8.1 a)). Se a nova rota inclui um nó que

era anteriormente um ��lho�, dá-se o loop (Figura 8.1 b)).

Figura 8.1: Algoritmo CTP reagindo a uma quebra de ligação que provoca um loop dentro da

rede. Os números ao lado de cada ligação é o seu ETX, e o número dentro de cada �nó�, o

ETX desse nó.

O CTP contorna este problema de duas formas. Primeiro, cada pacote CTP contém o valor

do gradiente actual do nó. Se o CTP recebe um pacote cujo valor gradiente é menor que o seu

actual, tal indica uma inconsistência na rede. Esta inconsistência é resolvida através do envio

por broadcast de um pacote de sinalização, com a suposição de que o nó que enviou o pacote o

ouça e ajuste as rotas em conformidade (Figura 8.1 c)). Se um agrupamento de nós está isolado

do resto da rede, então irão formar um loop cujos valores ETX irão aumentar inde�nidamente

(primeira iteração na Figura 8.1 b)). Nesta situação, o segundo mecanismo do CTP é não

considerar rotas cujo ETX esteja acima dum limiar aceitável, valor esse que é dependente da

implementação em causa.

No geral, é possível decompor o CTP em 3 componentes:

• Estimador de ligação, responsável por estimar o valor ETX das vizinhanças de um nó.

• Motor de encaminhamento, que usa as estimativas ETX para determinar qual o nó

seguinte na rota de encaminhamento.

• Motor de reencaminhamento, que mantém a �la de pacotes a enviar, decidindo quais

e quando a enviar. Este motor é responsável não só pelo reencaminhamento de tráfego

na rede assim como do tráfego gerado no próprio nó

Os campos necessários à formação e manutenção da árvore CTP são incluídos como octetos

extra no payload das mensagens de dados trocados, cujo conteúdo é representado na Tabela 8.1.

A qualidade da ligação (ETX) é avaliada não só através das mensagens de dados que atravessam

a rede (pois faz parte dos campos CTP), mas também através de mensagens de estimação que

48

medem especi�camente este valor para cada hop em intervalos aleatórios e exponenciais. Estes

intervalos são reiniciados caso o CTP detecte alguma potencial falha na ligação e veja necessário

reapreciar a qualidade das ligações.

Tabela 8.1: Estrutura dos cabeçalhos CTP.

1 octeto 1 octeto 2 octetos 2 octetos 1 octeto 1 octeto

Options THL ETX Origin Seq.No. Collection ID

Dentro das opções (Options), encontram-se alguns bits de noti�cação de congestão e de

reavaliação de rota, assim como alguns bits reservados. O THL representa Time Has Lived,

que é usado como contador para retransmissões (ver mais abaixo em detalhe). Um nó que

origina um pacote tem um THL de 0, e este valor deve ser incrementado, pela camada de

ligação de dados, em cada hop numa transmissão. Dado que incrementa por cada vez que

é encaminhado, pode ser usado como medidor para ver o número de saltos que efectuou no

trajecto dentro da rede até ao sink. O campo ETX mede a qualidade do hop da ligação, que

deve ser actualizado em cada encaminhamento (dado que o ETX é dado pelo valor da ligação

ao seu nó �pai� mais a deste até ao sink). Caso um nó receba um pacote cujo ETX é inferior

ao seu próprio, é considerada uma inconsistência na rede e este nó pedirá ao seu predecessor

uma reapreciação da ligação activando o bit de reavaliação de rota assinalado acima. Caso a

diferença seja substancial, esta informação será enviada para toda a rede, o que poderá alterar

um conjunto de rotas na rede.

Os campos seguintes são de�nidos à origem e não devem ser actualizados pelos nós enca-

minhadores. A origem (Origin) identi�ca o nó remetente da mensagem e Sequence Numeber

(Seq.No.) o número de sequência desta mensagem. A identi�cação de colecção (Collection ID)

de�ne o CTP no qual a mensagem se integra (pode haver várias árvores de colecção numa rede).

Há que fazer uma distinção entre o número de sequência e o campo THL, que podem parecer

mutuamente redundantes à primeira vista. Normalmente, para cada mensagem recebida, um

nó envia uma mensagem de ack ao seu predecessor para con�rmar a chegada. Só que esta

resposta pode não chegar ao seu destino (os caminhos nem sempre são simétricos, o que origina

uma retransmissão do pacote anteriormente enviado. Como este pacote é repetido (número de

sequência igual), é posteriormente descartado ao chegar ao destino.

Um nó num loop pode receber facilmente pacotes legítimos mais do que uma vez (quando

a mensagem dá uma volta completa pela rota do loop), pelo que se for avaliar uma mensagem

apenas pelo nó originante e seu número de sequência (que se mantên durante um loop), muito

pacotes serão descartados, tanto as retransmissões por falha de recepção de ack como as men-

sagens circulantes. Para o corrigir, o campo THL, incrementado em cada hop, foi adicionado:

uma retransmissão tem assim o mesmo valor THL, enquanto que o mesmo pacote num loop

não (já que por cada salto no hop, este valor é incrementado), podendo assim estabelecer uma

distinção.

8.3 Funcionamento

O funcionamento da rede está estritamente ligado com o funcionamento do algoritmo de enca-

minhamento CTP. Ao serem iniciados, os nós da rede iniciam um processo de estabelecimento

de rede, formando uma árvore com raiz no nó central. A partir daí, a manutenção das ligações

49

com eventuais alterações de topologia está a cargo do CTP.

Os nós equipados com detectores de presença, cuja ligação é efectuada via conexão de 51

pinos, lêem periodicamente o estado dos pinos a intervalos de 750 ms (esta frequência foi ca-

librada para que um alarme detectado gere apenas uma mensagem; para intervalos menores,

o estado do pino ainda não estaria inalterado, o que resultaria num novo alarme enviado).

Quando o detector regista movimento, o módulo MicaZ lê a alteração do estado do pino e inicia

a transmissão ao longo da rede de uma mensagem de alarme. A garantia de chegada desta men-

sagem está a cargo do algoritmo CTP. Estes nós participam activamente no encaminhamento

de mensagens dentro da rede, mesmo que não tenham sido eles os nós originantes.

Figura 8.2: Fluxo de dados no nó central.

Os restantes nós da rede, que não estão equipados com detectores de presença, participam

no entanto igualmente nas tarefas de encaminhamento dentro da rede. O código de execução

que ambos partilham é idêntico, apenas em altura de arranque da aplicação uma variável

(pré-de�nida nos �cheiros de cabeçalho) determinará se o temporizador referente à leitura dos

pinos deverá ser iniciado. Todos eles, no entanto, noti�cam periodicamente o Servidor da sua

permanência da rede, enviando pacotes de keep-alive a intervalos ajustáveis (antes de programar

os nós).

Há ainda um terceiro tipo de nó, embora não participe na rede. Apenas se limita a escutar

os pacotes que circulam ao alcance do seu receptor RF e mostram-no ao utilizador do PDA.

Como não participa no CTP, apenas escuta (pois o nó é extremamente móvel e volátil), não

chega a entrar na formação da árvore do CTP, nunca participando como possível veículo de

encaminhamento de mensagens.

Caso a rede gere um tráfego �anormal�, provocado por ataques à rede ou mesmo um excesso

de alarmes simultâneos ou uma coincidência em que muitos keep-alives chegam ao mesmo tempo,

pode ocorrer congestão nos nós, o que resultaria em perda de pacotes. Para o contornar, os

módulos possuem listas de espera (queues) que, segundo uma política de First In-First Out8,

vão despachando as mensagens na medida do possível.

8Primeiro a entrar, primeiro a sair.

50

8.4 Interface

Dado que os módulos Mica Z não dispõem de qualquer tipo de ligação para além das antenas

RF, é necessário dispor de uma placa programadora MIB 5x0/600 (a usada foi a MIB 510), ao

qual os módulos Mica Z são acoplados, para poder interagir bidireccionalmente com os módulos.

A interacção com o MIB 510 é USB, mas a interacção faz-se através de portas série emuladas,

em Windows, e mesmo USB, em Linux, embora em Linux a leitura da porta se faça através de

uma aplicação especial em Java que parametriza correctamente a leitura.

Os parâmetros para as portas se série emuladas são os seguintes:

• 57600 bits por segundo

• 8 bits de dados

• Nenhum bit de paridade

• 1 bit de paragem

• Sem controlo de �uxo (handshaking)

8.5 Estrutura das mensagens

As mensagens que circulam na rede seguem uma estrutura rígida pré-de�nida, cabendo ao

utilizador a utilização e gestão dos octetos de payload. Os restantes, são os de�nidos pela

Zigbee e TinyOS Alliances. Sobre o conteúdo do payload, consultar (9.3).

Entre nós da rede, as mensagens de dados circulantes seguem a estrutura representada na

Figura 8.3.

Figura 8.3: Estrutura das tramas 802.15.4. [1].

O payload dos dados é passado para a camada MAC e denomina-se como o MSDU. Dentro

deste payload a aplicação ainda adiciona 1 octeto, não representado, antes dos restantes dados

e que de�ne o tipo de mensagem (Active Message). Conjuntamente com o MHR colocado antes

e o MFR depois, formam o MPDU. O MFR consiste num teste de redundância (CRC) de 2

octetos.

Este MPDU é enviado para a camada física como o seu payload (PSDU). O cabeçalho que

antecede o PSDU consiste num conjunto de octetos de sincronização (SHR) (que contém uma

sequência preambular e um delimitador de trama (SFD)) e o PHR, que indica o tamanho do

payload PSDU. Todos juntos, o SHR, PHR e o PSDU formam um pacote de dados da camada

física, o PPDU. Em mais detalhe, o MPDU pode ser visto como apresentado na Figura 8.4

Nos campos de endereçamento, todos os identi�cadores são descritos como 2 octetos, excepto

o campo Source PAN Identi�er que não é preenchido, dado que há apenas uma rede instalada

51

Figura 8.4: Conteúdo do MPDU [1].

e não se prevê inter-operabilidade entre redes.

Analisando o tamanho total dos cabeçalhos, conclui-se que as tramas têm um comprimento

de 18 octetos mais o comprimento do payload, até um máximo de 128 octetos de�nido como

limite pela especi�cação. Os elementos necessários à formação da árvore CTP encontram-se

dentro do MSDU (consultar (9.3) para mais informação).

Na transposição para a porta de série, as tramas são diferentes, acomodando octetos ne-

cessários à sincronização com a porta e prescindindo, naturalmente, de informação relativa ao

endereçamento dentro da rede. Assim sendo, uma trama deste tipo, designada por Serial Frame,

é estruturado como apresentado na Tabela 8.2, e é aquela processada na chegada à Gateway e

ao PDA para extracção de campos.

Tabela 8.2: Estrutura das tramas na porta de série.1 octeto 1 octeto 1 octeto 2 octetos 2 octetos 1 octeto 1 octeto 1 octeto N octetos 2 octetos 1 octeto

Delimiter Protocol Dispatch Destination Source Length Group Type Payload CRC Delimiter

Os delimitadores de trama (Frame Delimiter) são sempre sempre caracterizados pelo octeto

hexadecimal 7E, quer no início quer no �m da trama. O octeto de protocolo (Protocol) deter-

mina que se trata de um tipo de transmissão sem acks e o octeto de Dispatch coloca-se a zero,

identi�cador de Active Message. O destino (Destination) é colocado com FF FF (dado que é

enviado para a porta de série, não tem identi�cador próprio) e a origem (Source) é sempre 0 (o

nó raiz). O comprimento (length) indica o comprimento do payload, em octetos, e os dois oc-

tetos que lhe sucedem, Group e Type, respectivamente, indicam o identi�cador de grupo (zero,

pois que não está determinado) e o identi�cador de grupo de rede. Antes do delimitador, é

incluído um CRC a dois octetos.

Dentro do payload vão também as estruturas necessárias à formação e manutenção da ár-

vore CTP, que devem devem ser consultadas em (9.3). O comprimento total destas tramas é

assim de 13 octetos mais o payload, que normalmente é de 19 octetos, totalizando 32 octetos.

Normalmente pois, caso algum octeto seja igual a 7E, para evitar confusões com o delimitador,

estes são convertidos para 7D 5E e, na situação de 7D ocorrer isoladamente, para evitar con-

fusões com um 7D convertido de 7E, é também transformado em 7D 5D; estas transformações

provocam aumentos ocasionais no tamanho das tramas.

52

9 Mensagens de protocolo

A comunicação entre os diversos sistemas é feita através da transmissão de cadeias de octetos

contendo caracteres ASCII, com o comprimento �xo de�nido de 200 octetos. Todas as mensa-

gens estão delimitadas com um caracter especial ($) que de�ne o início e �m de cada mensagem,

e contêm um octeto para veri�cação de integridade através de um teste simples de checksum,

colocado no penúltimo octeto de cada trama. As mensagens disponíveis entre o Servidor e os

PDAs são as seguintes:

• Adicionar/Actualizar Nó

• Remover Nó

• Pedir Dados de Rede

• Enviar Mensagem

• Desligar Conexão

Ao chegar à Gateway, algumas mensagens oriundas da rede sensorial são geradas propositada-

mente para serem reconhecíveis pelos demais sistemas e obedecerem à estrutura implementada.

São elas:

• Noti�cação de Alarme

• Mensagem de keep-alive

9.1 Veri�cação de integridade

O checksum consiste numa forma de veri�cação de redundância, um método simples de sal-

vaguardar a integridade dos dados que são transmitidos no espaço (telecomunicações) ou no

tempo (arquivo). Neste projecto a veri�cação que se adoptou foi o resultado da operação de

ou-exclusivo (XOR), aplicado octeto a octeto ao longo da mensagem, desde o segundo octeto

(após o $ inicial) até ao octeto imediatamente anterior ao correspondente ao checksum, tal

como exempli�cado na Tabela 9.1. O octeto de checksum é construído juntamente com o resto

da mensagem aquando do seu envio e comparado, à chegada sua chegada ao destino, com um

octeto construído segundo o mesmo princípio. Se estes octetos não forem iguais, a mensagem é

descartada.

Tabela 9.1: Exempli�cação do checksum.

$ 2o octeto 3o octeto 4o octeto checksum $

valor em binário - 01010000 01100110 10010111 10100001 -

resultado por octeto - 00000000 00110110 10100001 - -

Apesar do protocolo TCP implementar um checksum a nível da camada de transporte, o

checksum incluído nestas mensagens pretende comprovar que estas foram construídas e popu-

ladas correctamente, nomeadamente ao nível da separação de campos, mais do que veri�car se

houve pacotes corrompidos na transmissão (que é o que o TCP faz com a sua veri�cação).

53

9.2 Estrutura e funcionamento de mensagens extra-rede sensorial

Cada tipo de mensagem tem propósitos e estruturas diferentes, as quais serão descritas com

maior detalhe abaixo.

9.2.1 Adicionar/Actualizar Nó

Esta mensagem está relacionada com o posicionamento e informação detalhada característica

a cada nó, e é utilizada na transmissão de dados entre Servidor e PDAs, podendo ser gerada

em ambos os extremos da comunicação. Os PDAs formam uma mensagem deste tipo sempre

que, através da sua aplicação, desejam noti�car o Servidor da colocação de um novo nó na rede

sensorial. A mesma mensagem serve como actualização de dados, ou seja, se o nó for movido

ou a sua descrição sumária for alterada, uma mensagem equivalente será enviada, mas caso já

exista informação relativa a esse nó no Servidor, aquela será actualizada.

A estrutura desta mensagem é visível na Tabela 9.2.

Tabela 9.2: Mensagem: Adicionar/Actualizar nó.

$ 80 ID X Y Tipo Valor Owner ? Descrição ? Mapa IP Checksum $

1 octeto 1 octeto 2 octetos 2 octetos 2 octetos 1 octeto 2 octeto 30 octetos 1 octeto 120 octetos 1 octecto 30 octetos 4 octetos 1 octeto 1 octeto

Na situação em que é o PDA a produzir a mensagem, apenas os campos do identi�cador

'ID', do 'Tipo' e da 'Descrição' são inseridos manualmente. O utilizador deve indicar o tipo e

o identi�cador do sensor que vai colocar, podendo incluir, se assim o entender, uma pequena

descrição sobre este nó (local, particularidades, etc). Todos os outros são obtidos directamente

do sistema: a posição 'X' e 'Y' já foram seleccionadas quando o utilizador indicou o local no

mapa (campo Mapa, obtido a partir da imagem em uso) onde irá colocar o sensor, o campo

'Valor' é deixado vazio (pois aquando da inserção, ainda não há valores/registos obtidos) e o

'Owner' corresponde ao dono do sistema Pocket PC a correr no PDA. O campo 'Valor' será

apenas usado para sistemas que incluam sensores de valores, não sendo necessariamente usado

em redes de detecção de presença, daí que este campo tenha sido incluído por questões de

expansibilidade do sistema. O campo IP é deixado em branco, pois nesta situação não é usado.

Este campo é usado na situação em que a mensagem circula no sentido oposto. O PDA

pode em qualquer altura solicitar o envio para si de toda a informação de rede, através de

uma mensagem Pedir Dados de Rede (9.2.3), onde inclui o seu próprio endereço IP. Como

resposta, o servidor envia unidireccionalmente a este PDA uma sucessão de mensagens do

tipo Adicionar/Actualizar Nó, tantas vezes quantos os sensores presentes na rede, colocando

então nesta mensagem o endereço IP do remetente, obtida na mensagem de pedido de dados.

A colocação do endereço IP na mensagem permitirá à Gateway seleccionar correctamente o

destinatário destas mensagens.

O PDA pode ainda enviar uma mensagem deste tipo quando se desejar anunciar perante

a rede, altura em que constrói esta mensagem automaticamente com Tipo correspondente a

utilizador, �adicionando-se� à rede.

Nota quanto aos octetos contendo um '?': estes octetos servem de delimitadores entre os

campos 'Owner', 'Descrição' e 'Mapa', pois como são de comprimento variável (ao contrário

de todos os outros), não é possível identi�car onde um acaba e o outro começa, pelo que este

caracter foi adicionado com o intuito de delimitar essa fronteira.

54

9.2.2 Remover Nó

A mensagem de Remover Nó, como representada na Tabela 9.3, pode ser gerada no PDA, na

Gateway, ou no Servidor. Apesar do Servidor poder remover nós, o a sua execução deve estar

sempre associada à remoção física dos mesmos, pelo que esta operação é apenas para forçar

a eliminação caso alguma noti�cação não tenha chegado ao Servidor e se deseje eliminar o nó

da base de dados. Uma mensagem deste género é tipicamente enviada por um PDA quando,

através da sua aplicação, remove um nó da rede (ao mesmo tempo que o remove �sicamente

da rede), sendo esta mensagem difundida pela Gateway a todo o sistema. O identi�cador

transportado na mensagem é o identi�cador do próprio sensor dentro da rede. A Gateway

Tabela 9.3: Mensagem: remover nó.

$ 81 ID Checksum $

1 octeto 1 octeto 2 octetos 1 octeto 1 octeto

pode ainda originar uma mensagem deste tipo: sempre que um PDA se anuncia na rede, ele

torna-se um nó dessa rede, pelo que também deve ser noti�cado sempre que dela sai. Dito isto,

a Gateway, ao detectar a desconexão de um PDA (ver 6.3.2), produz esta mensagem e envia-a

ao Servidor e aos restantes clientes, com o correspondente identi�cador do PDA dentro da rede.

9.2.3 Pedir Dados de Rede

Imediatamente após se ligar à Gateway, um PDA desconhece por completo a constituição da

rede sensorial, por isso o passo seguinte será obter toda a informação existente até à data,

informação essa que está armazenada no Servidor. Para tal, cada PDA envia uma mensagem

deste tipo ao Servidor, obtendo como resposta uma sucessão de mensagens do tipo Adicio-

nar/Actualizar Nó, tantas vezes quanto os nós existentes na rede, de forma a �car a conhecê-la.

Dado que é uma operação que pode originar grande sobrecarga (para redes com elevado número

de nós), não deve ser usada com muita frequência (idealmente, apenas imediatamente após se

ligar à Gateway).

A estrutura da mensagem pode ser observada na Tabela 9.4. Depois do pedido chegar ao

Tabela 9.4: Mensagem: pedir dados de rede.

$ 82 IP Checksum $


Servidor, a resposta deve chegar unicamente ao PDA que o requisitou, não deve ser difundida por

todos os clientes. A selecção de cliente é feita na Gateway recorrendo ao endereço IP. Quando

o pedido é feito no cliente, o seu próprio endereço é inserido na mensagem (no campo IP visível

na Tabela 9.4), que é depois reintroduzido no campo IP das mensagens Adicionar/Actualizar

Nó de resposta. Sempre que receber uma mensagem deste tipo, a Gateway analisa os campos

de IP e encaminhará a mensagem para o destinatário correcto.

55

9.2.4 Enviar Mensagem

A troca de mensagem simples pode ser feita entre Servidor e PDA e entre PDAs, e baseia-se

numa estrutura simples de mensagens, como se pode observar na Tabela 9.5. Os identi�cadores

Tabela 9.5: Mensagem: mensagens simples.

$ 70 ID_Origem ID_Destino Texto Checksum $

1 octeco 1 octeto 2 octetos 2 octetos 192 octetos 1 octecto 1 octeto

de origem e destino têm a ver com os IDs que a Gateway utiliza para identi�car todos os

sistemas a si ligados. Para ver a atribuição de IDs, consultar o Capítulo 6.3.2.

Em traços gerais, o Servidor assume o identi�cador 0 (zero), uma mensagem para ser di-

fundida por todos tem o ID destino de 65535 e os identi�cadores de cada PDA são o algarismo

7 seguido do último octeto do endereço IP de cada PDA. A título de exemplo, um PDA com

endereço 192.168.1.120 tem o identi�cador 7120.

O campo 'Texto' é uma cadeia de caracteres ASCII. Esta opção inviabiliza o uso de ca-

racteres especí�cos da língua portuguesa, como caracteres acentuados ou cedilhados, mas esta

utilização requeria uma codi�cação Unicode, que ocupa dois octetos para cada caracter. Man-

tendo a codi�cação como ASCII, duplica-se o número de caracteres disponíveis para introduzir

na mensagem. Este campo, no fundo um payload, permite expandir grandemente as capaci-

dades do sistema apenas à custa da interpretação desta mensagem, sem necessariamente criar

mais tipos de mensagem.

9.2.5 Desligar Conexão

Esta mensagem é bastante evidente. Sempre que um dos componentes do sistema termina

a sessão (fecho das comunicações), envia uma mensagem deste tipo a avisar os restantes do

sucedido, para que possam também eles encerrar devidamente a conexão.

Tabela 9.6: Mensagem: desligar conexão.

$ 60 $

1 octeto 1 octeto 1 octeto

9.2.6 Noti�cação de Alarme

Quando um alarme é registado na rede sensorial, esta encarrega-se de fazer chegar esse alarme

até à Gateway, que por sua vez converterá a mensagem no formato utilizado pela rede sensorial

no formato utilizado pelo resto do sistema. O identi�cador utilizado é aquele que identi�ca o

sensor dentro da própria rede.

Tabela 9.7: Mensagem: Noti�ca Alarme.

$ 40 ID Checksum $


56

9.2.7 Keep-Alive

Durante o normal funcionamento da rede, é necessário que toda a informação esteja actuali-

zada, isto é, deve ser possível garantir que os sensores que estão disponíveis na base de dados

no Servidor estão efectivamente funcionais e passíveis de transmitir informação �dedigna a

qualquer altura. Dito de outra forma, é necessário garantir que os sensores estão funcionais e

efectivamente no local.

Para se poder constatar tal (e remotamente), os sensores enviam periodicamente pacotes de

keep-alive para a Gateway, de forma a anunciar a sua presença e de que ainda estão funcionais

(e há um caminho pela rede entre esse mesmo nó e a Gateway). Caso um nó não comunique

em tempo útil a sua presença, é legítimo a�rmar que o nó não consta mais da rede, seja por

falta de bateria, mau funcionamento, perda de meio de comunicação, etc. Quando tal acontece,

o sensor é dado como �morto� do lado do Servidor, comunicando esse facto na interface. O

mau funcionamento de um dos sensores pode comprometer o funcionamento global da rede

(se for um elo importante na manutenção de rotas de dados), pelo que a sua substituição (ou

averiguação da falta de comunicação) são essenciais.

Tabela 9.8: Mensagem: Keep-Alive.

$ 41 ID Checksum $


9.3 Estrutura e funcionamento de mensagens intra-rede sensorial

As mensagens que circulam dentro da rede sensorial têm um protocolo de mensagens rígido

independente e naturalmente distinto daquele utilizado nas restantes comunicações, pois devem

obedecer à estrutura estipulada e convencionada pela TinyOS Alliance e pela Zigbee Alliance,

cabendo ao utilizador a gestão dos octetos de payload. Sobre a estrutura completa, consultar

8.5.

O payload consiste no cabeçalho especi�cado do CTP, seguido pelas estruturas adicionadas

pelo utilizador na camada de aplicação. Os octetos especí�cos ao CTP podem ser consultados

com maior detalhe na Tabela 8.1.

Dentro das estruturas de�nidas pelo utilizador, são apresentados os campos na Tabela 9.9.

Tabela 9.9: Trama de payload.

2 octetos 2 octetos 2 octetos 2 octetos 2 octetos 1 octeto 2 octetos 2 octetos

Source Seq.No. Parent Metric Data Hopcount SendCount SendSuccessCount

Estes campos são todos preenchidos no nó produtor da mensagem e não devem ser alterados

pelos nós encaminhadores. O campo source é o identi�cador do próprio nó que produz a

mensagem, Seq.No. o número de sequência desta mensagem, Parent o nó pai e Metric o

valor ETX da sua ligação através do nó pai até ao sink (estes dois campos obtidos através de

informação sobre a árvore CTP). Hopcount está de�nido a 0 (pois é o nó originante) e os dois

campos �nais estão relacionados com retransmissões dos pacotes.

Apesar de apenas o campo Data ser usado, dado que esta implementação do CTP é um

reaproveitamento de um programa exemplo, os restantes campos servem mais para controlo

57

de dados e efeitos de monitorização de comportamento da rede, já que não são directamente

usados. Sendo assim, dois os octetos em Data, que internamente são dois campos de 1 octeto

cada, dividem-se em duas categorias, consoante o tipo de mensagem.

9.3.1 Alarme

Tabela 9.10: Mensagem de alarme.

1 octeto 1 octeto

0x10 0x10

Nesta situação 0x10 indica tratar-se de uma mensagem de alarme. Como apenas os nós que

têm detector de presença acoplado geram esta mensagem, não é necessário fazer a distinção

deste tipo, pelo que o 2o octeto é apenas uma repetição do primeiro.

9.3.2 Keep-Alive

Tabela 9.11: Mensagem de keep-alive.

1 octeto 1 octeto

0x20 Tipo No

O valor hexadecimal 0x20 identi�ca tratar-se de uma mensagem deste tipo, enquanto o

segundo octeto permite saber se a mensagem foi proveniente de um nó encaminhador ou de um

nó associado a um detector de presença. Esta distinção é útil para a aplicação de PSO quando,

ao receber uma trama do ar, pode saber de que tipo de sensor se trata. Este valor pode ser

0x0A, para um nó com detector de presença, ou 0x12, para apenas encaminhador.

58

10 Medidas de desempenho

A �m de avaliar o desempenho global do sistema, foram feitos diversos testes a cada um dos

módulos que o constituem, simulando condições reais de funcionamento e vendo como se com-

portaria perante diferentes cenários. Algumas medições têm também um carácter documental,

de forma a que seja possível montar uma rede mais sólida e �ável tendo em conta os resultados

obtidos.

Os testes nos PDAs foram efectuados no Qtek 9090 e o Servidor e a Gateway correram

num PC AMD64 com 3GHz e 1GB de RAM, Windows XP. As comunicações Wi-Fi entre PDA

e Servidor foram efectuadas através dum router 802.11b a 11Mbps, com potência de sinal a

aproximadamente 40% e cifra WEP 64 bits.

No Anexo 2 encontram-se os valores teóricos usados para a produção dos grá�cos apresen-

tados.

10.1 Alcance máximo entre dois nós

O alcance máximo permite saber a que distância dois nós consecutivos se podem instalar,

assegurando qualidade de transmissão e garantia de entrega. Para o testar, procedeu-se da

seguinte forma: cada mote ao receber uma mensagem acciona um LED; os nós são gradualmente

afastados entre si até o LED deixar de acusar mensagem recebida. O valor anunciado para esta

medida é de cerca de 75-100 metros.

No entanto, testes práticos, realizados num campo de futebol, zona plana e totalmente

desobstruída, sem elementos que causem eventuais re�exões de sinal, apontam para valores

mais na ordem dos 50 metros, visíveis na Figura 10.1.

Figura 10.1: Resultado dos testes de alcance entre dois nós (domínio de utilização).

Acima disso, algumas mensagens chegam, mas não com uma regularidade que se possa

a�rmar que ainda é uma distância utilizável. Existe um incremento visível e gradual da taxa

de retransmissão acompanhando o aumentar da distância entre nós, mas a partir de um certo

ponto a degradação da qualidade da transmissão causa que não seja mais possível contabilizar

correctamente as retransmissões (ver Tabela 1.5 no Anexo 2), por isso é possível apenas estimar

a continuação do comportamento. Na situação limite, nenhuma mensagem chega ao destino

59

(retransmissão total) e a árvore CTP quebra-se. Ainda antes do limiar é possível que a árvore

se forme e desfaça diversas vezes, mas, em média, podemos assumir o comportamento descrito

pelo grá�co.

Os testes foram feitos quer em ambiente coberto, quer ao ar livre, e sempre com linha de

vista. Apesar do fabricante anunciar uma redução do alcance em ambiente coberto para os 20-30

metros [40], não foi visível essa redução, pelo contrário: o alcance aumentou. Com obstrução, o

este é variável em função da própria natureza da obstrução, de forma que não é possível chegar

a conclusões nesse sentido.

É possível observar como a taxa de entrega se mantém bastante elevada ate aos 45 metros,

altura em que desce abruptamente. Mesmo até aos 45 metros, a entrega começa a ser garantida

apenas à custa de uma cada vez maior repetição do envio de pacotes para garantir a sua chegada.

Muitas vezes o pacote chega, mas a mensagem ACK de con�rmação de regresso não é recebida

(caminhos não simétricos), o que origina uma retransmissão do pacote na origem.

A partir destes valores é possível extrapolar para um maior número de hops e constatar a

importância de manter os nós não muito afastados, pois globalmente, a retransmissão de pacotes

causada pelo demasiado afastamento pode provocar um maior consumo energético provocado

pela provável abundância de pacotes redundantes de retransmissão dentro da rede.

Outro factor a ter em conta, e que foi comprovado, foi o alcance em função da energia

disponível nas baterias instaladas. Os testes foram feitos com pilhas alcalinas novas, embora

se tenha notado que, quando instaladas pilhas já com aproximadamente 50% da capacidade,

o alcance diminuía. Infelizmente, não há um conjunto de baterias disponíveis que permita

estabelecer uma relação numérica entre a carga e o alcance, mas �cou anotada a situação.

Recentemente, a Crossbow, empresa fabricante dos motes MicaZ anunciou um novo produto

na sua linha, o �IRIS�, com um alcance aproximado de até 3x mais que o apresentado por

aparelhos similares.

10.2 Cobertura de espaços

Admitindo um alcance �seguro� de 50 metros, dentro do qual as comunicações são �áveis e a

garantia de entrega ainda não é comprometida pela distância, é possível estimar a quantidade

de nós para cobrir determinada área. Se toda a área deve estar coberta com detectores de

presença, a distância entre nós está limitada à distância permitida pelo detector, mas a título

de exemplo será estimado apenas para os motes Mica Z.

Suponha-se que a área aberta é de 1 km2 (1000 metros por 1000 metros), com distância

entre hops de no máximo 50 metros e a ausência de um nó não deve causar o isolamento de

conjuntos de nós da rede, ou seja, esta deve poder encontrar rotas alternativas. O nó sink é

aleatoriamente colocado numa zona central da malha (não incluído na �gura pois não é relevante

para a distribuição dos restantes nós). Uma representação está demonstrada na Figura 10.2.

Com esta distribuição, cada ponto está sempre à distância de três nós, no mínimo, e sete, no

máximo. Desta forma, a eliminação de um nó não compromete a criação de rotas alternativas.

Tendo em conta que cada nó tem na linha ímpar 1000/50 = 20 nós + 1 = 21 (porque os nós

extremos são instalados em �cantos�), a linha par tem, portanto, 20. Ou seja, há 11 linhas

de 21 nós e 10 linhas de 20 nós, o que perfaz um total de 431 nós para cobrir 1km2 nestas

condições.

Numa situação de distribuição em linha recta, por exemplo, a quantidade de nós necessários

60

Figura 10.2: Distribuição espacial de nós numa rede para maximização de cobertura tendo em

conta o alcance. Este tipo de distribuição assegura que cada ponto está coberto sempre por

mais do que um nó (três, neste caso). Uma distribuição mais simplista, como numa distribui-

ção em matriz perfeita, criaria zonas sem cobertura assim que um nó deixasse de funcionar,

comprometendo diversas rotas.

é simples e facilmente determinada pelo quociente entre a distância a cobrir e o alcance entre

dois nós, apresentando esta relação uma curva em todo semelhante àquela representada na

Figura 10.3. Numa situação de um cenário misto ou irregular, como por exemplo um edifício

ou um recinto, as arquitectura destes condicionará a colocação e disposição dos nós, e será

analisado caso a caso como situações pontuais de áreas abertas (salas) ou distribuições em

linha (corredores). Dado que se trata de um cenário indoor, é de esperar alguma melhoria no

que diz respeito ao alcance. Comunicações entre andares, é de todo impossível.

A Figura 10.3 mostra que uma melhoria no alcance reduz de uma forma signi�cativa o total

de nós necessário para a cobertura de uma área. Torna-se vantajoso portanto apostar numa

melhoria do alcance nesta tecnologia, pois ainda que o custo unitário seja maior, ele não cresce

na mesma proporção que o número de nós decresce. Mesmo para 75 metros (distância ainda

aceitável), a quantidade de nós necessária cai de 431 para 199.

10.3 Autonomia dos nós da rede

Pretendendo-se que as redes deste tipo se mantenham activas por muito tempo sem necessidade

de substituição das suas fontes energéticas, o sistema deve estar projectado para poupar, na

medida do possível, a energia disponível que alimenta os nós. Uma medida que ajuda a determi-

nar a potencial �esperança de vida� da rede é o duty cycle associado, ou seja, o tempo no qual

o módulo está efectivamente funcional. Supondo que 1 em cada 100 segundos um dispositivo

está a operar, então o seu duty cycle será de 1%.

Na Figura 10.4 é possível observar o efeito decisivo que uma redução no duty cycle pode ter

na melhoria da longevidade das baterias; foram utilizadas as especi�cações da plataforma Mica

Z [40] e o recurso a uma folha de cálculo própria da Crossbow [41] para obter esta representação.

Incluído está também, além de valores exemplo, a situação especí�ca para este trabalho:

61

Figura 10.3: Relação entre alcance e número de nós necessário para cobrir uma área de 1km2.

• Keep-Alives alternados cada 5000ms, originam uma trama de 32 octetos que demoram

14,2ms a ser encaminhadas (7,1ms para recepção e transmissão) a 38400 baud. Duty-cycle

associado de 14,2/5000=0,284% (recepção mais transmissão).

• Leitura periódica do estado do sensor cada 750ms. Tempo de ocupação do processador

nesta leitura de 1ms (assumido). Duty-cycle associado de 1/750=0.13%. Mensagens

originadas para efeitos de alarme não contabilizadas, pois são presumivelmente �1% do

total.

• Utilização estimada total de 0,0877 mAh, o que equivale a uma duração de 30 meses para

pilhas de 2000mAh.

Figura 10.4: Autonomia da rede em função da capacidade das baterias e do consumo energético.

Os grá�cos representam três duty-cycles diferentes, sendo o 0,13% o correspondente a estra

trabalhos e os restantes para efeito comparativo.

62

De notar que estes valores apenas são considerados válidos se forem introduzidas as instru-

ções e tomadas as precauções que permitem ao módulo adormecer nos intervalos das interrup-

ções. Apesar das estimativas optimistas, a �função de longevidade� apresentada não é linear.

Com o desgastar das baterias, o alcance diminui, a perda de pacotes aumenta, assim como a

taxa de retransmissões, o que provoca um aumento gradual do consumo ao longo do tempo,

sendo portanto de esperar uma longevidade bastante abaixo da anunciada.

10.4 Interferências na banda 2.4Ghz

Em virtude de tanto o Zigbee (802.15.4) como o Wi-Fi (802.11b/g/n) (assim como outros dis-

positivos) trabalharem na banda livre dos 2.4Ghz, podem ocorrer interferências que prejudicam

o normal funcionamento das comunicações dentro da rede, diminuindo a qualidade do serviço e

prejudicando a garantia de entrega. Estes problemas podem ser contornados se forem tomadas

medidas preventivas. Dado que os sistemas desenvolvidos para este protótipo recorrem a ambas

estas tecnologias, há que ter cuidado com a sua implementação.

Apesar de não funcionarem em apenas um canal de comunicação, ocupando cada um dos

espectros diferentes bandas de frequências, dada a dimensão do espectro do Wi-Fi comparati-

vamente com o do Zigbee, sobreposições ocorrem facilmente, como se pode observar na Figura

10.5 [42].

Figura 10.5: Espectro de canais Zigbee e Wi-Fi. Representação XY de Energia versus Frequên-

cia.

A Crossbow disponibiliza resultados tanto para Access Points Wi-Fi de elevada potência

como para baixo (este o representado aqui), comparando a interferência em diversos nós de uma

rede distribuída, numa topologia visível na Figura 10.6. Mais detalhes podem ser consultados

em [42]; na Tabela 1.4 (Anexo 2) e na Figura 10.7 são mostrados os resultados para uma rede

Wi-Fi a funcionar no Canal 3 (2422 MHz), comparativamente a diferentes frequências usadas

numa rede Zigbee, quando sujeitas a um sinal Wi-Fi de potência normal.

É facilmente observável como a presença do sinal Wi-Fi prejudica a garantia de entrega dos

63

Figura 10.6: Distribuição dos nós no teste realizado para medição de interferências.

Figura 10.7: Representação grá�ca dos dados da Tabela 1.4 no Anexo 2. Os identi�cadores de

nós referem-se àqueles observáveis na Figura 10.6.

64

pacotes na rede. Ao afastar-se das zonas de maior emissão de energia do espectro (comparar

com Figura 10.5), os valores voltam a aproximar-se mais dos 99-100% típicos. Em frequências

adjacentes à frequência usada ainda se notam os efeitos da interferência causados por frequências

de intermodulação criadas através da interacção do sinal RF do Zigbee e Wi-Fi em proximidade.

No outro exemplo, para um AP de maior potência (23dBm), as taxas chegam a situar-se por

vezes abaixo dos 80% nas frequências adjacentes, continuando a manter os 99-100% à medida

que se afasta da frequência central do sinal Wi-Fi.

Ao instalar o sistema completo é possível ajustar a frequência em função do Canal usado

para o sinal Wi-Fi, já que os módulos MicaZ funcionam entre os 2.4GHz e os 2.4835GHz, em

intervalos con�guráveis de 1MHz.

10.5 Desempenho do algoritmo CTP

Em tempo de arranque, nenhum dos nós conhece os seus vizinhos, ou seja, não há qualquer

rami�cação na árvore à partida. Esta árvore forma-se segundo o algoritmo CTP, cujo funcio-

namento é descrito com maior detalhe em 8.2. Para efectuar este teste, foram distribuídos os

nós em três situações: todos à distância do sink, todos em linha de forma a que só houvesse um

salto possível na rota até ao sink, ou em linha mas com uma �zona central� de 2 nós.

Em todas as situações, os nós começaram a responder e a enviar dados imediatamente

após terem sido ligados, o que sugere que a árvore se forma em fracções de segundo. Dada

a baixa quantidade de nós disponíveis para teste (quatro), cada nó não tinha muitos vizinhos

por onde escolher e avaliar qualidades de ligações e rotas de forma a escolher a mais viável,

daí que o processo seja naturalmente rápido. Numa rede bastante mais alargada, com diversas

concentrações de nós e rotas possíveis, é de presumir que a formação da árvore demore mais

algum tempo, não sendo, ainda assim, de esperar que seja algo �demorado�

Da mesma forma, com a quantidade de nós disponíveis para teste (excluindo o sink), não

foi possível medir, com rigor, a rapidez com que a árvore CTP se readapta para alterações de

topologia. Os nós foram dispostos de forma a que cada um apenas visse o seu vizinho imediato

no trajecto até ao sink, sem hipótese de �atalhos�. Com 4 nós, foram alteradas as posições

em 2 hops, desligando os módulos nas suas posições iniciais e voltando a ligá-los nas novas. A

rede iniciou retransmissões de dados correcta e imediatamente, não havendo qualquer atraso

aparente provocado pela alteração da topologia.

10.6 Desempenho no sistema global

Este conjunto de testes centra-se nos atrasos obtidos na actualização do conjunto de aplicações

exteriores à rede de sensores (Servidor e PDAs). Essencialmente, é o tempo que demora desde

que se veri�ca uma alteração de um dos lados até esta ser registada no outro extremo. Testou-se

ainda o desempenho a nível de garantias de entrega quando o Servidor está sob um elevado

�uxo de dados.

10.6.1 Actualizações da COP

Neste teste, consideraram-se todos os extremos como origem e destinos de mensagens, produ-

zindo uma mensagem na origem e vendo o seu atraso até chegar ao destino. Os resultados

65

apresentados são valores em média, seguindo distribuições normais (em Anexo podem ser con-

sultados os dados com maior detalhe). Sendo a Gateway o �centro nevrálgico� do sistema e

por onde todas as comunicações passam, é o sistema mais passível de introduzir atraso na rede

caso esteja sob muito processamento. Embora o processamento de mensagens da rede ou por

comunicações TCP corram sempre em threads separadas, quer na Gateway quer nos PDAs, a

preempção causada no processador pode introduzir atraso, variável em função da capacidade de

processamento destes. Dado que a rede só produz tráfego esporádico (quer de keep-alives, quer

de alarmes), não é de esperar, excepto em situações de ataque à rede como Denial of Service,

que a Gateway se veja em situações de congestionamento de tráfego por esta parte.

Atraso PDA <> PDA Cenário em que dois PDAs estão ligados à mesma Gateway e

efectuam comunicações entre si. Neste cenário estão contempladas todas as operações de adi-

ção/edição/remoção de nós da rede, que se propagam a todos os elementos ligados à Gateway

(como os restantes PDAs), assim como troca directa de mensagens entre dois PDAs. Neste

cenário e em condições de rede sem qualquer tipo de �tráfego�, toda a troca de dados fez-se

instantaneamente, com atrasos inferiores a um segundo, pelo que esta medida não é de todo

mensurável. Este tempo pode ser aumentado (teoricamente, dado que não foi testado), em

situações que causem elevada carga de processamento quer na Gateway, quer no PDA.

Por exemplo, se a rede fornecer grandes quantidades (milhares) de dados ao mesmo tempo

à Gateway (situação de ataque à rede, dado que é improvável acontecer normalmente) esta

fará por distribuí-los ao Servidor e PDAs. Se durante o despacho destas mensagens os PDAs

tentarem comunicar (e porque farão uso do mesmo canal de comunicação que os dados da rede

usam para chegar aos PDAs), é provável que um atraso seja introduzido, ou mesmo até eventual

perda de pacotes.

Este problema é idêntico caso seja o Servidor a enviar milhares de pacotes em direcção

aos PDAs (igualmente uma situação improvável de acontecer) ou caso o nó acoplado ao PDA

registe uma �inundação� de tráfego em seu redor, causando aí a preempção no próprio PDA.

Esta situação também só é eventualmente concebível em ataques à rede, dado que esta não

produz naturalmente muito tráfego.

Atraso PDA <> Servidor Em semelhança da situação anterior, e nas mesmas condições,

as mensagens �zeram-se chegar quase instantaneamente, com atrasos inferiores a um segundo.

Dada as elevadas capacidades do computador Servidor, o atraso provocado por preempção

torna-se menos problemático. Aqui os atrasos na Gateway também podem causar alguns atrasos

em situações de ataque à rede, como visto acima.

O próprio Servidor, dado que está ligado pelas diversas Gateways às diversas redes, caso

várias redes estejam sob ataques o Servidor �ca rapidamente congestionado, e começará even-

tualmente a perder pacotes, além de poder provocar grandes atrasos. No entanto, foi feito um

teste em que se submeteu o Servidor a uma elevada carga de pacotes (foram enviados 3000,

ainda que todos da mesma Gateway), enquanto um PDA e o Servidor trocavam mensagens

entre si (por exemplo, um dos lados introduzia um sensor e outro removia-o, mensagens essas

que são trocadas por estes elementos através da Gateway).

O Servidor garantiu a troca de mensagens enviadas ao PDA, embora perdesse os pacotes

recebidos em massa durante a produção destas mensagens. No sentido inverso (PDA>Servidor),

não houve perda de pacotes e as mensagens chegaram, com a diferença que estas últimas se

66

�zeram chegar todas antes que as do PDA fossem processadas; nesta situação, o atraso de

chegada é então tanto maior quando o número de mensagens ainda por despachar.

Aqui existe sim um grande atraso, provocado naturalmente pela diferença de sentido no

�uxo de dados na Gateway : como cada cliente (PDA) na Gateway ocupa uma thread diferente

mas com igual prioridade, aquela terá de despachar todos os pacotes vindos de uma thread

antes de passar à seguinte: daí que os pacotes produzidos num PDA apenas cheguem depois de

todos os outros terem chegado.

Atraso Rede > PDA/Servidor Neste cenário, simularam-se as situações em que a rede

transmite grandes quantidades de informações à Gateway e de transmissão normal de alarmes,

caso este fossem gerado algures dentro da rede.

Numa situação �normal�, �zeram-se disparar alguns alarmes na rede (a até 4 hops de

distância) e esperar-se-ia medir o tempo de transmissão desde que o sinal sonoro é despoletado

até a mensagem ser actualizada no Servidor ou no PDA. Na verdade, a chegada foi instantânea,

não sendo por isso possível chegar a qualquer conclusão. Mesmo com um número de nós

dezenas de vezes superiores, é possível que, caso as rotas já estivessem estabelecidas, o tempo

de transmissão fosse igualmente desprezável.

Analisando os resultados após a Gateway fazer chegar os resultados ao Servidor, estes são

em todo semelhantes àquelas apresentados em (10.6.2). Quanto aos chegados ao PDA, não

há dados disponíveis por não ser possível fazer um registo adequado do número de mensagens

efectivamente chegadas sem que o processamento dessa contagem comprometesse a e�cácia da

própria recepção (como por exemplo, escrever em Base de Dados), dado que o PDA tem um

poder de processamento bastante reduzido comparativamente a um PC.

10.6.2 Flood ao Servidor

Este teste de certa forma confunde-se um pouco com os último testes do grupo anterior. No

entanto, há um maior controlo do número de mensagens produzidas, que é vigiado e pode ser

manipulado para avaliação de desempenho. Em vez de virem hipoteticamente da rede, como

no teste anterior, provêm de um cliente simulado, que, do ponto de vista do Servidor, pode ser

da rede ou do PDA - essencialmente, são mensagens em elevado número que chegam até ao

Servidor num reduzido espaço de tempo.

Estes testes visam analisar o comportamento do Servidor nesta situação, na sua capacidade

de lidar com elevado tráfego e garantia de entrega de pacotes. Os testes realizados são em

cenários em que o único tráfego é aquele propositadamente produzido. A comprovação de

chegada mediu-se pela análise ao número de entradas no registo histórico de eventos do Servidor

comparativamente ao número de pacotes enviados no cliente teste.

Garantia de entrega Avalia a capacidade do Servidor de processar convenientemente os

dados que lhe chegam, estabelecendo uma relação entre o número de mensagens enviadas e as

que foram efectivamente recebidas/processadas.

Dado que as mensagens estão a chegar continuamente ao socket, entre cada duas o Servidor

tem de saber identi�car qual é e o que quer fazer com cada mensagem, processamento esse que

introduz atraso, ainda que mínimo, mas que acumulado com centenas ou milhares de mensagens

se torna signi�cativo.

67

Consoante o que é necessário fazer com cada mensagem e a saturação do processador em cada

momento (pois o Servidor realiza outras tarefas em simultâneo, algumas com maior prioridade),

algumas mensagens podem-se perder, o que �cou comprovado quando propositadamente e em

simultâneo com a recepção de mensagens se obrigou o sistema operativo a abrir aplicações

pesadas ou utilizar a largura de banda disponível.

De modo geral, cada mensagem que chega (por exemplo, um keep-alive de rede, a mensagem

mais frequente a chegar ao Servidor) é processada da seguinte forma (até ao terceiro ponto

abaixo indicado, sempre que uma das condições não se veri�car, a mensagem é descartada):

• Veri�ca se mensagem inicia e termina com o caracter '$'.

• Comprova checksum correcto.

• Extrai identi�cador da mensagem e veri�ca se existe em BD.

• Actualiza BD das alterações.

• Actualiza grelha de visionamento.

• Apresenta mensagens de progresso no display.

Os resultados para este teste, e em condições ideais (o único tráfego na rede era aquele

produzido para este teste), produziram os resultados observáveis na Figura 10.8

Figura 10.8: Garantia de entrega para mensagens em massa chegadas ao Servidor vindas da

rede/PDA.

Como se pode ver, curiosamente, um maior número de mensagens enviadas não produziu

uma menor garantia, que se situa em cerca de 98% para qualquer das situações. Este número

é bastante alterado caso haja processamento simultâneo, onde será de esperar que quanto mais

mensagens se �zerem chegar, mais se perderão, enquanto as tarefas simultâneas se estiverem

a veri�car. Não foi incluído um grá�co para este cenário dado que as situações tipo não são

reproduzíveis ao ponto de os seus resultados serem apreciáveis.

Tempo de processamento Avalia quanto tempo demora o Servidor a despachar determi-

nado número de mensagens, admitindo que chegam todas em rajada.

68

Foram realizados testes para diversos conjuntos de mensagens, e os resultados são os apre-

sentados na Figura 10.9.

Figura 10.9: Tempo necessário ao Servidor, em segundos, para processar determinado número

de mensagens.

É visível, através da recta de regressão adicionada, que a relação é aproximadamente linear

entre o número de mensagens enviadas e o tempo necessário para todas serem processadas, o

que indicia que o ritmo de processamento é constante - notar que o conteúdo das mensagens

neste teste era sempre o mesmo, sendo portanto uma repetição de N vezes da mesma mensagem.

A relação torna-se menos linear consoante a garantia de entrega e as condições em que se

encontra o Servidor à chegada das mensagens, como visto no ponto acima. Um Servidor mais

sobrecarregado irá provocar não só perda de pacotes, como também atrasar o despacho geral

de mensagens. No computador do presente teste, entre 50 e 60 mensagens foram despachadas

por segundo, em média.

10.6.3 Flood à Rede

Para este teste tentou simular-se, por exemplo, um ataque de Denial of Service 4.2.2 em que o nó

sink é inundado de pedidos, congestionando-o e forçando-o a perder pacotes. Dado o reduzido

número de nós existentes para testes, não foi possível chegar a resultados concludentes.

Foram colocados 3 nós ao alcance do sink, que enviaram mensagens a um ritmo de 10 por

segundo. No entanto, provavelmente devido à presença de um bu�er de recepção no sink e

ao reduzido número de nós �atacantes�, todas as mensagens chegaram sem problemas, sendo

muito raramente um pacote descartado (<1%).

69

11 Conclusões

Foi objectivo do presente projecto desenvolver um sistema completo de vigilância em cenários de

Segurança Interna, ou mais concretamente, para aquele desenvolvido, situações de vigilância de

áreas de acesso restrito, recorrendo a sensores de presença. A implementação do sistema recorre

ao inovador método de formar uma rede autónoma com nós equipados com transmissores rádio,

que propagam e encaminham os dados obtidos até um servidor remoto, disponibilizando ainda

a informação disponível a agentes no terreno, quando equipados com um PDA.

Dada a potencial aplicabilidade do sistema a diversos cenários além da detecção de presença,

foi preocupação no desenvolvimento deste trabalho permitir sempre, na medida do possível, a

abertura da aplicação para contemplar diversos cenários com diferentes tipos de sensores, como

por exemplo sensores de temperatura, luz, som, gases, etc. Para isso, foram incluídos octetos

extra nas tramas que circulam na rede para que neles se possa incluir um tipo diferente de

sensor e, eventualmente, uma medição dele obtida (ver 9.2.1). Da mesma forma, recorrendo ao

conceito de programação orientada a objectos, cada tipo de sensor diferente herda de um tipo

�pai� sensor, de maneira a que seja rápida e facilmente incluído outro tipo de sensor. No total,

pretende-se uma arquitectura que permita actualizações dinâmicas consoante as necessidades,

quer na rede, quer no conjunto Servidor/Gateway/PDA.

Apesar do sistema aparentar ser teoricamente bastante apelativo e funcional, alguns entraves

impossibilitam-no de colocar-se facilmente em todos os potenciais cenários para ele previstos.

Um deles surge quando no mesmo local onde está instalada a rede, outros dispositivos que

recorrem à banda livre de 2.4GHz estão também em funcionamento, o que é comprometedor

para a situação global proposta neste trabalho (os PDAs). Quanto mais ocupada estiver a

banda, maior a possibilidade de a interferência comprometer o bom funcionamento da rede.

Apesar de a questão ser contornável, quer recorrendo a bandas Wi-Fi que ocupam outras

frequências (802.11a/n a 5Ghz) ou jogando com o espectro de frequências para minimizar a

interferência, a verdade é que compromete um pouco o conceito de �instalar & esquecer�.

Mesmo em zonas onde se pode excluir de todo o recurso a Wi-Fi, a banda 2.4Ghz está bastante

congestionada hoje em dia com diversos equipamentos, pelo que um maior investimento no

sistema de transporte poderia viabilizar e �abilizar muito mais o sistema.

Por outro lado, nem o alcance nem a autonomia se podem considerar próximos do esperado.

O alcance, numa situação de baterias novas e com garantia de entrega ainda dita satisfatória,

situa-se algures nos 50 metros em ambiente aberto, abaixo dos 100 anunciados (embora se tenha

veri�cado melhores resultados em ambientes fechados). No entanto, com o gastar das baterias

este valor reduz-se, comprometendo o plano de distribuição inicial da rede e aumentando o

número de nós necessário já que, por questões de segurança, se tem de aproximar os nós à

partida prevendo a redução de alcance com o passar do tempo.

Em termos de autonomia, esta varia enormemente com o duty cycle utilizado, assim como

as próprias características das baterias, de maneira que o funcionamento dos nós deve ser

cuidadosamente estudado para não comprometer a longevidade do sistema. Uma rede mais

congestionada pode ver a sua autonomia rapidamente reduzida e inviabilizar o conceito deste

tipo de redes. Quanto maior o número de elementos na rede, mais inconveniente é a sua

substituição e manutenção. Dado que uma rede com detecção de presença é teoricamente

muito baixa em termos de tráfego, o duty cycle será portanto muito reduzido, o que amplia

vantajosamente a longevidade da rede. De referir que um mais baixo duty-cycle não interfere

71

com eventuais atrasos dentro da rede, já que o TinyOS funciona por meio de eventos e não de

esperas activas.

Recentemente (Junho 2007), a Crossbow anunciou o �IRIS�, um novo mote na sua linha

de produção que tem, segundo a própria empresa, o triplo do alcance RF dos restantes motes

convencionais, com uma necessidade energética em modo sleep de cerca de metade daquela do

MicaZ (8uA em vez de 15uA), além de incluir o dobro da memória programável disponível

(8kb). Esta conjugação de factores certamente permitirá que redes de maior escala sejam mais

exequíveis de ser implementadas, com um menor custo e longevidade globais.

Complementarmente, o algoritmo de encaminhamento Collection Tree Protocol assume-se

como uma solução mais apropriada para redes com pouco tráfego, o que se adequa ao tipo

de redes com detecção de presença; outro tipo de encaminhamento será mais indicado caso o

excesso de tráfego traga contrapartidas energéticas. Mostrou-se bastante e�caz, estabelecendo

rapidamente novas rotas e corrigindo alterações de topologia; o seu encaminhamento livre de

endereçamento permite facilmente estabelecer rotas até ao destino (que é sempre o nó sink),

o que é um problema caso se queira endereçar um nó especí�co que não o raiz. No entanto,

dado que se trata de um sistema de �colecção�, esse tipo de comunicação não está naturalmente

contemplado, pelo que caso seja necessário fazê-lo, outro tipo de encaminhamento, baseado em

endereçamento nó a nó (como o AODV 2.6.1), deverá ser usado.

O CTP não garante igualmente uma entrega a 100%, mas esforça-se por o fazer ao máximo.

Este benefício também tem os seus inconvenientes: no desaparecimento do nó sink, por exem-

plo, a ausência de um ACK vindo deste e a impossibilidade de os restantes nós conseguirem

estabelecer uma nova rota obrigam a rede a inundar-se de mensagens de procura de rota até

encontrarem novo sink, causando loops (embora o CTP corrija estes ao �m de alguns ciclos)

e aumentando gravemente o consumo energético neste período. Enquanto novo nó raiz não

for colocado, a rede irá continuar a insistir até eventualmente consumir toda a energia, ou um

novo nó raiz surgir. Apesar de não ser suposto o nó sink desaparecer, dado que deve estar

continuamente alimentado e seguro, devem ser tomadas algumas medidas contra este método

de procura.

O sistema que actualmente corre no sistema embebido dos módulos da rede, o Tiny OS,

encontra-se de momento na versão 2.0.1, e pese embora se considere num estado sólido, funcional

e utilizável a ponto de ser implementado em diversos sistemas, tendo em conta o seu carácter

open source encontra-se continuamente num estado work in progress, apresentando margem

para melhorias em questões de transporte e dependência energética. A documentação é pouca

e pobre e a aprendizagem é feita sobretudo recorrendo a programas exemplo que felizmente

contemplam a maioria das necessidades básicas necessárias para iniciação e desenvolvimento de

alguns programas. As aplicações que correm nos módulos de rede neste trabalho, por exemplo,

aproveitam a quase totalidade de programas exemplo disponibilizados. Apesar de open source,

os criadores iniciais do sistema participam activamente nas mailing lists do Tiny OS, prestando

esclarecimentos sempre que possível, e actualizam, acrescentam e complementam regularmente

a documentação, tutoriais, programas exemplo, etc.

Apesar de alguns pontos por apurar no desenvolvimento da plataforma, nomeadamente as

referidas questões de alcance, autonomia, etc., o sistema apresenta-se exequível para cenários de

menor dimensão, na ordem das dezenas de nós, para cobertura de recintos de menor dimensão,

como pequenos parques �orestais ou urbanos, recintos, edifícios, etc., ou seja, adequa-se ao

espectro de intervenção deste projecto. Dada a própria topologia destes ambientes, questões de

72

alcance máximo não são problemáticos, a autonomia também não é comprometedora dado o

baixo número de elementos envolvidos (fácil substituição), e por este mesmo motivo, o tráfego

na rede não propicia a congestão do algoritmo CTP.

Para ambientes maiores, em que os nós são na ordem das centenas, ou cujo espaço é amplo

e se pretende tirar partido da distância para espaçar os nós, a plataforma ainda precisa de

melhoramentos para garantir a entrega, melhorar o aproveitamento energético (pois a redução

do alcance durante a duração de vida da rede pode comprometer a viabilização desta) e requer

uma grande optimização do duty cycle caso a rede seja bastante activa.

De um modo geral, é possível a�rmar que o presente estado da tecnologia permite criar

uma rede proveitosa para monitorização de áreas de acesso restrito, fazendo a salvaguarda das

eventuais condicionantes e tendo em conta a topologia e dimensão da rede a instalar.

73

Bibliogra�a

[1] Society, I. C., Part 15.4: Wireless medium access control (mac) and physical layer (phy)

speci�cations for low-rate wireless personal area networks (lr-wpans).

[2] Grilo, A., Silva, R., Nunes, P., Martins, J., and Nunes, M., Wireless Sensor Networking

Support to Military Operations on Urban Terrain, 12th International Command and Con-

trol Technology Symposium (ICCRTS 2007), Command and Control Research Program

(CCRP), The O�ce of the Assistant Secretary of Defense, Networks and Information In-

tegration (OASD-NII), 2007.

[3] program, J. T. R. S., http://enterprise.spawar.navy.mil/body.cfm?type=

c&category=27&subcat=60.

[4] Joint Tactical Radio System: Programmable, M. C. S., http://www.globalsecurity.

org/military/systems/ground/jtrs.htm.

[5] Radio, N.-T. D., http://www.monmouth.army.mil/peoc3s/trcs/MF1NTDR.htm.

[6] on Vehicular Ad Hoc Networks (VANET 2006), T. T. A. I. W., http://www.sigmobile.

org/workshops/vanet2006/.

[7] Martinez, K., Hart, J. K., and Ong, R., Environmental Sensor Networks.

[8] Stankovic, J. A. et al., Wireless Sensor Networks for In-Home Healthcare: Potential and

Challenges, Department of Computer Science, University of Virginia.

[9] http://www.wsnplanet.com/.

[10] Römer, K. and Mattern, F., The Design Space of Wireless Sensor Networks, IEEEWireless

Communications 11 (6): 54-61., 2004.

[11] Almeida, P. and Oliveira, N., Rede local de PDAs e sensores para combate a incêndios.,

Relatório de Trabalho Final de Curso, 2006.

[12] Algorithm, D., http://www-b2.is.tokushima-u.ac.jp/~ikeda/suuri/dijkstra/

Dijkstra.shtml.

[13] Al-Karaki, J. N. and Kamal, A. E., Routing Techniques in Wireless Sensor Networks: A

Survey, Department of Electrical and Computer Engineering, Iowa State University, Ames,

Iowa, EUA.

[14] Royer, E. M. and Toh, C.-K., A Review of Current Routing Protocols for Ad-Hoc Mobile

Wireless Networks, 1999.

75

http://enterprise.spawar.navy.mil/body.cfm?type=c&category=27&subcat=60

http://enterprise.spawar.navy.mil/body.cfm?type=c&category=27&subcat=60

http://www.globalsecurity.org/military/systems/ground/jtrs.htm

http://www.globalsecurity.org/military/systems/ground/jtrs.htm

http://www.monmouth.army.mil/peoc3s/trcs/MF1NTDR.htm

http://www.sigmobile.org/workshops/vanet2006/

http://www.sigmobile.org/workshops/vanet2006/

http://www-b2.is.tokushima-u.ac.jp/~ikeda/suuri/dijkstra/Dijkstra.shtml

http://www-b2.is.tokushima-u.ac.jp/~ikeda/suuri/dijkstra/Dijkstra.shtml

[15] Schiller, J., Mobile Communications, Addison-Wesley, 2003.

[16] Perkins, C. E. and Bhagwat, P., Highly Dynamic Destination-Sequenced Distance-Vector

Routing (DSDV) for Mobile Computers, 1994.

[17] He, G., Destination-Sequenced Distance Vector (DSDV) Protocol, Networking Laboratory,

Helsinki University of Technology.

[18] Murthy, S. and Garcia-Luna-Aceves, J. J., An E�cient Routing Protocol for Wireless

Networks, Computing Engineering, University of California, 1999.

[19] Montenegro, G. and Kushalnagar, N., AODV for IEEE 802.15.4 Networks, draft-

montenegro-lowpan-aodv-00, 2003.

[20] Perkins, C., Belding-Royer, E., and Das, S., Ad-hoc On-Demand Distance Vector (AODV)

Routing, draft-ietf-manet-aodv-13, 2003.

[21] Johnson, D. B., Johnson, D. A., and Hu, Y.-C., The Dynamic Source Routing Procotol for

Mobile Ad-hoc Networks (DSR), draft-ietf-manet-dsr-10, 2004.

[22] Ko, Y.-B. and Vaidya, N. H., Location-Aided Routing (LAR) in Mobile Ad Hoc Networks,

1998.

[23] Navas, J. C. and Imielinski, T., GeoCast - Geographic Addressing and Routing, Computer

Science Department, Rutgers, The State University, Piscataway, NJ, EUA, 2002.

[24] Haas, Z. J., Pearlman, M. R., and Samar, P., The Zone Routing Protocol (ZRP) for Ad

Hoc Networks, draft-ietf-manet-zone-zrp-04.txt, 2002.

[25] Chiang, C.-C., Wu, H.-K., Liu, W., and Gerla, M., Routing in Clustered Multihop, Mobile

Wireless Networks with Fading Channel, Computer Science Department, University of

California, Los Angeles, EUA, 1997.

[26] Jiang, M., Li, J., and Tay, Y., Cluster Based Routing Protocol (CBRP), draft-ietf-manet-

cbrp-spec-01, National University of Singapore, Singapore, 1999.

[27] Heinzelman, W., Kulik, J., and Balakrishnan, H., Adaptive Protocols for Information

Dissemination in Wireless Sensor Networks, Proc. 5th ACM/IEEE Mobicom Conference,

Seattle, WA, EUA, 1999.

[28] Heinzelman, W., Chandrakasan, A., and Balakrishnan, H., Energy-E�cient Communica-

tion Protocols for Wireless Microsensor Networks, Proc. Hawaaian Int'l Conf. on Systems

Science, EUA, 2000.

[29] Sadagopan, N., Krishnamachari, B., and Helmy, A., Active Query Forwarding in Sensor

Networks (ACQUIRE), Department of Electrical Engineering - Systems, University of

Southern California, Los Angeles, California, USA, 2003.

[30] Karp, B. and Kung, H. T., Greedy perimeter stateless routing (gpsr) for wireless networks,

2000.

[31] Madden, S., Franklin, M. J., Hellerstein, J. M., and Hong, W., The Design of an Acquisi-

tional Query Processor For Sensor Networks, 2003.

76

[32] Amato, G., Caruso, A., Chessa, S., Masi, V., and Urpi, A., State of the Art and Future

Directions in Wireless Sensor Networks Data Management.

[33] www.wibree.com.

[34] Nunes, M. and Silva, R., Segurança em Redes 802.11, 2006.

[35] Dell, Wireless Security in 802.11 (Wi-Fi) Networks, 2003.

[36] Daemen, J., Borg, S., and Rijmen, V., The Design of Rijndael: AES - The Advanced

Encryption Standard., Springer-Verlag, 2002.

[37] Yan, Z., Zhang, P., and Virtanen, T., Trust Evaluation Based Security Solution in Ad Hoc

Networks, Nokia Research Center, Nokia Group, Helsinki, Finland.

[38] Manoj, B. and Murthy, C. S. R., Transport Layer and Security Protocols for Ad Hoc

Wireless Networks, Prentice-Hall, 2005.

[39] Fonseca, R. et al., The collection tree protocol (ctp), 2006.

[40] Inc., C. T., Micaz datasheet.

[41] Inc., C. T., Mote battery life calculator.

[42] Inc., C. T., Micaz-based zigbee and wi� coexistence: Avoiding rf interference between wi�

and zigbee.

77

Anexos

79

Anexo 1

Figura 1.1: Esquema da arquitectura Zigbee

81

Anexo 2

Resultados teóricos que deram origem à produção de alguns dos grá�cos presentes no corpo do

relatório.

Tabela 1.1: Garantia de entrega para mensagens em massa chegadas ao Servidor vindas da

rede/PDA (Figura 10.8).

No de Mensagens Série 1 Série 2 Série 3 Média % Entregue

200 199 198 196 197,67 98,83333333

500 494 484 496 491,33 98,26666667

750 736 740 739 738,33 98,44444444

1000 973 981 997 983,67 98,36666667

1500 1482 1481 1478 1480,33 98,68888889

2000 1897 1993 1992 1960,67 98,03333333

Tabela 1.2: Tempo necessário ao Servidor, em segundos, para processar determinado número

de mensagens (Figura 10.9).

No de mensagens Série 1 Série 2 Série 3 Média

200 5 6 5 5,33

500 10 7 8 8,33

750 12 10 11 11,00

1000 17 18 16 17,00

1500 25 24 26 25,00

2000 35 36 36 35,67

83

Tabela 1.3: Relação entre alcance e número de nós necessário para cobrir uma área de 1km2

(Figura 10.3).

Alcance (metros) Nós/1000m Total necessário

30 34 1163

50 20 431

75 14 199

100 10 116

150 7 56

200 5 34

250 4 23

Tabela 1.4: Taxas de entrega no nó raiz para diferentes frequências de funcionamento Zigbee

(Figura 10.7.

Nó 1 Nó 2 Nó 3 Nó 4 Nó 5

Sem Wi-Fi 100.00 99.95 100.00 100.00 100.00

Canal Zigbee 11 - 2.405GHz 100.00 100.00 100.00 100.00 99.95

Canal Zigbee 14 - 2.420GHz 96.19 98.45 95.05 98.02 94.67

Canal Zigbee 15 - 2.425GHz 98.63 98.99 98.89 99.05 98.86

Canal Zigbee 20 - 2.450GHz 99.95 100.00 99.95 99.95 99.95

Canal Zigbee 16 - 2.480GHz 100.00 100.00 99.95 100.00 99.89

Tabela 1.5: Taxas de entrega e retransmissão de mensagens em função da distância entre dois

nós consecutivos (Figura 10.1).

Metros NSeq da Última No Msg Distintas No Msg Recebidas % Duplicada % Entregue

0 100 100 100 0,00 100,00

13 106 106 106 0,00 100,00

26 141 141 167 18,44 100,00

39 111 111 151 36,04 100,00

45 85 83 130 56,63 97,65

52 80 56 69 23,21* 70,00*

55 100 37 41 10,81* 37,00*

84

Figura 1.2: Dados que dão origem ao grá�co da Figura 10.4.

85

Detecção de intrusões em operações de segurança com base em Redes de … · Detecção de...

Documents

Transcript of Detecção de intrusões em operações de segurança com base em Redes de … · Detecção de...