josé antónio da cunha teixeira gomes criação de uma rede...

José António da Cunha Teixeira Gomes

Criação de uma rede mesh wireless

José

Ant

ónio

C.T

. Gom

es

Novembro de 2010UMin

ho |

201

0C

riaç

ão d

e um

a re

de m

esh

wir

eles

s

Universidade do MinhoEscola de Engenharia

Novembro de 2010

Tese de MestradoCiclo de Estudos Integrados Conducentes aoGrau de Mestre em Engenharia Electrónica Industrial eComputadores

Trabalho efectuado sob a orientação doProfessor Doutor Sérgio Adriano Fernandes Lopes

José António da Cunha Teixeira Gomes

Criação de uma rede mesh wireless

Universidade do MinhoEscola de Engenharia

ii

Agradecimentos

À EFACEC Sistemas de Electrónica, na pessoa do Eng. Paulo Delfim Rodrigues

pela oportunidade que me deu de poder realizar este trabalho e pelo apoio dado

durante a elaboração do mesmo.

Ao meu orientador, Doutor Sérgio Lopes pelo apoio prestado e pela

disponibilidade demonstrada.

Aos meus pais e irmãos pelo incentivo e apoio que sempre demonstraram, não

só no meu percurso académico como em tudo o resto.

Resumo

iii

Resumo

O objectivo desta dissertação consiste no desenvolvimento de uma pilha de

software para utilização em redes LR-WPAN, que permita implementar uma topologia

mesh. A pilha desenvolvida utiliza o protocolo IPv6 e está implementada sobre nós

físicos que seguem a norma IEEE 802.15.4. Nesse sentido, a pilha utiliza uma camada

de adaptação 6LoWPAN entre a camada IPv6 e a camada MAC do IEEE 802.15.4. Esta

camada de adaptação, efectua a compressão do cabeçalho IPv6 e a fragmentação e

desfragmentação do pacote IPv6, de modo a ser possível transmitir os pacotes IPv6

sobre frames IEEE 802.15.4. A pilha desenvolvida teve por base a pilha IPv6 incluída no

sistema operativo Contiki. O Contiki também inclui uma adaptação para redes LR-

WPAN do algoritmo para redes mesh AODV, que foi o algoritmo usado na realização

deste trabalho. Dado que a pilha IPv6 incluída no Contiki não cumpria todos os

requisitos especificados, foi necessário implementar algumas funcionalidades,

nomeadamente, o multicast e um mecanismo que permitisse ao coordenador aceder à

topologia da rede. Para demonstrar o funcionamento da pilha desenvolvida, foi

também desenvolvido para PC um programa de demonstração em linguagem Java.

Este programa permite visualizar a topologia da rede, assim como a rota efectuada por

uma mensagem, quando esta é enviada de um nó para outro.

Abstract

iv

Abstract

The objective of this dissertation is the development of a software stack for use

in a LR-WPAN network that allows the implementation of a mesh topology. The stack

developed uses the IPv6 protocol and is implemented over physical nodes that follow

the IEEE 802.15.4 standard. For that, the stack uses a 6LoWPAN adaptation layer

between the IPv6 layer and the MAC layer. This adaptation layer is responsible for the

IPv6 header compression and for the fragmentation and defragmentation of the IPv6

package, in order to make possible the transmission of the IPv6 packets over the IEEE

802.15.4 frames. The stack developed is based on the IPv6 stack included in the

Contiki operating system. The Contiki also includes an adaptation for LR-WPAN

networks of the AODV mesh algorithm, which is the algorithm used in this project. The

IPv6 stack included in the Contiki does not fulfill all the requirements specified for the

project. Consequently, it was necessary to implement some functionalities, like the

multicast and a mechanism that allows the coordinator to know the network topology.

In order to demonstrate the operation of the developed stack, a demonstration

program was also developed for PC in Java language. This program shows the network

topology and the route covered by a message, when it is sent from a node to another.

Índice

v

Índice

Agradecimentos ................................................................................................................. ii

Resumo ............................................................................................................................. iii

Abstract ............................................................................................................................ iv

Índice de figuras ............................................................................................................. viii

Índice de tabelas ................................................................................................................ x

Acrónimos ......................................................................................................................... xi

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

1.1 Motivação e enquadramento ............................................................................ 1

1.2 Objectivos .......................................................................................................... 2

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

2 Fundamentos Teóricos .............................................................................................. 4

2.1 Rede mesh sem fios ........................................................................................... 4

2.2 IEEE 802.15.4...................................................................................................... 6

2.3 6LoWPAN ........................................................................................................... 8

2.3.1 Problemas e objectivos............................................................................... 8

2.3.2 Arquitectura de rede ................................................................................ 10

2.3.3 Camada de adaptação 6LoWPAN ............................................................. 11

2.3.4 Compressão do cabeçalho IPv6 ................................................................ 13

2.3.5 Encaminhamento...................................................................................... 14

2.4 Conclusões ....................................................................................................... 15

3 Análise e desenho da solução ................................................................................. 17

3.1 Especificação de requisitos .............................................................................. 17

Índice

vi

3.1.1 Descrição Geral ......................................................................................... 17

3.1.2 Especificações ........................................................................................... 17

3.2 Topologia da rede ............................................................................................ 20

3.3 Escolha do Hardware ....................................................................................... 21

3.4 Escolha do Software......................................................................................... 22

3.5 Protocolo de encaminhamento ....................................................................... 24

3.6 Conclusões ....................................................................................................... 27

4 Ambiente de trabalho ............................................................................................. 28

4.1 Cooja ................................................................................................................ 28

4.2 AVR Raven ........................................................................................................ 31

4.3 AVR Dragon ...................................................................................................... 31

4.4 Modelo de programação do Contiki ................................................................ 32

4.4.1 Protothreads ............................................................................................. 32

4.4.2 Compilação ............................................................................................... 35

4.5 Conclusões ....................................................................................................... 37

5 Descrição da implementação .................................................................................. 38

5.1 Análise comparativa ......................................................................................... 38

5.1.1 6LoWPAN .................................................................................................. 38

5.1.2 Rede mesh ................................................................................................ 40

5.2 Alterações à pilha ............................................................................................. 42

5.2.1 Multicast ................................................................................................... 42

5.2.2 Protocolo de comunicação da topologia .................................................. 45

5.3 Programa de demonstração ............................................................................ 45

5.3.1 Captura dos pacotes ................................................................................. 46

5.3.2 Descrição funcional .................................................................................. 48

5.3.3 Implementação ......................................................................................... 52

Índice

vii

5.4 Conclusões ....................................................................................................... 54

6 Teste e Resultados .................................................................................................. 56

6.1 Conclusões ....................................................................................................... 59

7 Conclusões ............................................................................................................... 60

Glossário ......................................................................................................................... 62

Bibliografia ...................................................................................................................... 63

Anexo A – Implementação do multicast ........................................................................ 65

Anexo B – Classes e métodos da Jpcap .......................................................................... 66

Índice de figuras

viii

Índice de figuras

Figura 2.1 – Rede mesh .................................................................................................... 4

Figura 2.2 – Ligação entre dois nós .................................................................................. 4

Figura 2.3 - Reparação de rota ......................................................................................... 5

Figura 2.4 - Descoberta de rota ........................................................................................ 5

Figura 2.5 - Mensagem unicast ........................................................................................ 6

Figura 2.6 – Tecnologias de redes sem fios (retirada de [12]) ......................................... 7

Figura 2.7 - Integração do 6LoWPAN na Internet (retirada de [17]) .............................. 10

Figura 2.8 – Comparação entre a pilha 6LoWPAN e IP (retirada de [14]) ...................... 11

Figura 2.9 - Cabeçalhos 6LoWPAN (retirado de [17])..................................................... 11

Figura 2.10 - Cabeçalho de fragmentação (retirada de [17]) ......................................... 12

Figura 2.11 - Cabeçalho mesh (retirada de [17]) ............................................................ 13

Figura 2.12 - Compressão do cabeçalho IPv6 (retirada de [17]) .................................... 13

Figura 2.13 - Compressão do cabeçalho UDP (retirada de [17]) .................................... 14

Figura 2.14 – Encaminhamento 6LoWPAN (retirada de [7]) .......................................... 15

Figura 3.1 – Topologia da rede ....................................................................................... 20

Figura 3.2 – Camadas de rede ........................................................................................ 23

Figura 3.3 – Requisição de rota ...................................................................................... 24

Figura 3.4 – Envio de RREQ ............................................................................................. 25

Figura 3.5 - Recepção de um RREQ ................................................................................ 26

Figura 3.6 – Actualização da tabela ................................................................................ 27

Figura 4.1 – Modelos de propagação rádio .................................................................... 28

Figura 4.2 – Selecção da pilha de comunicação ............................................................. 29

Figura 4.3 – Selecção dos interfaces dos nós ................................................................. 30

Figura 4.4 – Plugins ......................................................................................................... 30

Figura 4.5 – AVR Raven ................................................................................................... 31

Figura 4.6 – AVR Dragon ................................................................................................. 32

Figura 4.7 – Utilização de memória para implementar a pilha de execução threads e

protothreads (retirada de [23]) ...................................................................................... 33

Índice de figuras

ix

Figura 4.8 – Comparação do código usado em threads e eventos (retirada de [23]) ... 34

Figura 4.9 – Padrões básicos de um sistema orientado a eventos (retirada de [23]) .... 34

Figura 4.10 – Processo .................................................................................................... 35

Figura 4.11 – Makefile .................................................................................................... 36

Figura 5.1 - Envio do pacote ........................................................................................... 42

Figura 5.2 - Declaração da tabela multicast ................................................................... 43

Figura 5.3 - Retransmissão do pacote ............................................................................ 43

Figura 5.4 - Algoritmo do multicast ................................................................................ 44

Figura 5.5 - Frame de encaminhamento ........................................................................ 45

Figura 5.6 - Topologia da rede ........................................................................................ 46

Figura 5.7 – Programa de demonstração ....................................................................... 49

Figura 5.8 - Escrever mensagem ..................................................................................... 50

Figura 5.9 - Descoberta de rota ...................................................................................... 51

Figura 5.10 - Recepção da mensagem ............................................................................ 51

Figura 5.11 - Leitura do sensor de temperatura ............................................................ 52

Figura 5.12 - Formato da mensagem.............................................................................. 52

Figura 5.13 - Frame da temperatura .............................................................................. 54

Figura 6.1 - Conexão com o nó intermédio .................................................................... 56

Figura 6.2 - Envio de mensagem .................................................................................... 57

Figura 6.3 - Introdução de um novo nó .......................................................................... 57

Figura 6.4 - Envio de Neighbor Solicitation .................................................................... 58

Figura 6.5 - Criação de nova rota .................................................................................... 58

Figura 6.6 - Reenvio da mensagem ................................................................................ 58

Índice de tabelas

x

Índice de tabelas

Tabela 2.1 - Bandas de frequência do IEEE 802.15.4 ....................................................... 8

Tabela 2.2 - Identificação do tipo de cabeçalho (retirada de [18]) ................................ 12

Tabela 3.1 - Especificação de requisitos ......................................................................... 20

Tabela 3.2 – Módulos IEEE 802.15.4 .............................................................................. 21

Tabela 3.3 – Pilhas open source ...................................................................................... 22

Tabela 5.1 – Recomendações para o protocolo Neighbor Discovery ............................ 39

Tabela 5.2 – Recomendações para o protocolo de encaminhamento .......................... 41

Tabela 5.3 – Tabela multicast ......................................................................................... 43

Tabela 5.4 – Classes da Jpcap ......................................................................................... 47

Tabela 5.5 - Métodos utilizados ..................................................................................... 48

Tabela 5.6 - Códigos ........................................................................................................ 53

Acrónimos

xi

Acrónimos

6LoWPAN IPv6 over Low power Wireless Personal Area Network

AODV Ad hoc On demand Distance Vector routing

API Application Programming Interface

CRC Cyclic Redundancy Check

DAD Duplicate Address Detection

DSR Dynamic Source Routing

ED Energy Detection

GPRS General Packet Radio Service

ICMP Internet Control Message Protocol

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

ISP In-system programming

IP Internet Protocol

JTAG Joint Test Action Group

LOAD 6LoWPAN Ad Hoc On-Demand Distance Vector Routing

LQI Link Quality Indicator

LR-WPAN Low Rate - Wireless Personal Area Network

MAC Medium Access Control

MANET Mobile Ad-hoc Networks

MTU Maximum Transmission Unit

NUR Neighbor Unreachability Detection

PAN ID Personal Area Network Identifier

Acrónimos

xii

PLC Power Line Communications

ROLL Routing Over Low power and Lossy Networks

RPL Ripple

RREP Route Reply

RREQ Route Request

RSSI Received Signal Strength Indicator

TCP Transmission Control Protocol

UDP User Datagram Protocol

WPAN Wireless Personal Area Network

Introdução

1

1. Introdução

1.1 Motivação e enquadramento

A crescente utilização de redes sem fios em aplicações de monitorização e

actuação nas mais diversas áreas, como por exemplo na medicina, indústria e

domótica, levou à necessidade de desenvolvimento de novas plataformas de hardware

e software que satisfizessem as especificidades deste tipo de rede. Nomeadamente,

esses requisitos incluem a necessidade da rede ter um baixo consumo de energia, uma

vez que os dispositivos podem ser alimentados por baterias, e baixo custo. É neste

contexto que surgem as redes LR-WPAN (Low Rate – Wireless Personal Area Network).

Este tipo de redes caracterizam-se por terem uma baixa taxa de transmissão, baixo

consumo de energia, baixo custo e recursos de hardware limitados. De forma a

permitir a conectividade entre diferentes plataformas de hardware foi desenvolvida a

norma IEEE 802.15.4 [1], que define a camada física e a camada MAC do hardware das

redes LR-WPAN. Acima da camada IEEE 802.15.4 podem ser implementados vários

protocolos de comunicação sem fios, como o Zigbee [2], o MiWi [3], ou o

WirelessHART [4]. Como alternativa pode ser utilizado o protocolo IPv6 [5], sendo

neste caso necessário introduzir uma camada de adaptação entre este protocolo e a

camada IEEE 802.15.4. A forma como a camada de adaptação é implementada é

definida pelo grupo 6LoWPAN do Internet Engineering Task Force (IETF) [6], e

encontra-se descrita no RFC 4944 [7].

Este projecto foi desenvolvido a partir de uma colaboração com a empresa

EFACEC Sistemas de Electrónica. A empresa tem interesse no desenvolvimento de

soluções de monitorização e controlo, nomeadamente para as suas estações e postos

de transformação, e portanto teve o papel principal na definição dos requisitos do

projecto. Portanto, este é um projecto que para além dos objectivos académicos tem

uma forte componente de interesse aplicacional na indústria.

Introdução

2

1.2 Objectivos

O projecto tem como finalidade a criação de uma pilha de software para redes

LR-WPAN que permita implementar uma topologia mesh. A pilha de software

consistirá num conjunto de protocolos de rede, que serão implementados sobre nós

físicos que seguem a norma IEEE 802.15.4. O software deverá ser capaz de efectuar

funções de gestão de rede, como permitir a inclusão de um nó na rede, a conexão

deste com outros nós, e o encaminhamento de dados entre os nós da rede. A pilha de

software permitirá também a conectividade entre os nós IEEE 802.15.4 e outros

dispositivos que utilizem diferentes meios físicos de transmissão, mediante a utilização

do protocolo IPv6 e de um router.

Neste projecto não se pretende desenvolver de raiz um protocolo para redes

mesh. Ao invés, considera-se viável uma solução construída com base em pilhas para

redes mesh já existentes, e que sejam open source. O software a implementar deverá

garantir o máximo de portabilidade entre diferentes plataformas de hardware que

sigam a norma IEEE 802.15.4. O projecto foi realizado em cinco fases:

definição dos requisitos da rede;

pesquisa de pilhas de protocolos open-source que cumpram alguns dos

requisitos definidos;

desenho da solução, possivelmente partindo de uma pilha open-source

escolhida, alterando-a de forma a cumprir todos os requisitos prioritários;

implementação de um protótipo

teste da solução.

Introdução

3

1.3 Organização da tese

Esta dissertação encontra-se dividida em sete capítulos. No primeiro capítulo será

descrito as motivações para a realização do trabalho e indicados os seus objectivos. No

segundo capítulo é apresentada uma breve descrição do funcionamento de uma rede

mesh sem fios, é descrita sucintamente a norma IEEE 802.15.4 e é feita uma

introdução ao 6LoWPAN. No terceiro capítulo são indicados os requisitos para a

elaboração do trabalho, é descrito o protocolo de encaminhamento AODV e indicados

os motivos que levaram à escolha do hardware e do software utilizados. No capítulo

quatro é descrito o hardware e software utilizados. No capítulo cinco serão expostas as

alterações efectuadas à pilha seleccionada para a realização do trabalho, será

efectuada uma comparação entre esta pilha e as recomendações do 6LoWPAN e será

efectuada uma descrição do programa de demonstração desenvolvido Os testes e

resultados são apresentados no capítulo seis e as conclusões no capítulo sete.

Fundamentos Teóricos

4

2 Fundamentos Teóricos

2.1 Redes mesh sem fios

Uma rede com topologia mesh é constituída por um conjunto de nós que se

encontram conectados entre si, sem qualquer tipo de relação hierárquica (figura 2.1).

A rede é constituída por routers (a escuro na figura 2.1), podendo incluir também nós

host que não efectuam funções de encaminhamento (a claro na figura 2.1). Um nó

host liga-se a um router, efectuando por intermédio deste a comunicação com os

restantes elementos da rede.

Figura 2.1 – Rede mesh

Para que dois nós de uma rede possam comunicar entre si, é necessário criar uma

rota entre eles (figura 2.2).

Figura 2.2 – Ligação entre dois nós


5

Quando a rota criada se encontra indisponível, quando por exemplo um nó intermédio

é desligado ou o sinal é bloqueado por um obstáculo, é automaticamente procurada

uma nova rota (figura 2.3).

Figura 2.3 - Reparação de rota

A forma como esta rota é criada depende do algoritmo de encaminhamento

utilizado. De entre este tipo de algoritmos encontram-se o AODV [8], o Dymo [9] e o

DSR [10]. No caso dos protocolos reactivos (e.g., AODV), apenas se cria uma rota

quando um nó pretende comunicar com outro. Por outro lado, os protocolos

proactivos criam, e mantêm, um conjunto de rotas mesmo que estas nunca venham a

ser utilizadas. No caso do AODV, quando um nó pretende comunicar com outro

efectua um broadcast, usando o protocolo UDP, com um pedido para que seja

efectuada uma descoberta de rota. No exemplo da figura 2.4, o nó 1 envia um pedido

para ser descoberta uma rota para o nó 10.

Figura 2.4 - Descoberta de rota


6

O broadcast do pedido resulta num conjunto de mensagens que chegam ao nó 10

através de diferentes rotas. Na figura 2.4 podem chegar ao nó 10 dez mensagens, cujas

rotas foram 1-0-7-9-10, 1-0-6-10, 1-0-6-9-10, 1-5-10, 1-5-6-10, 1-0-5-10, 1-0-5-6-9-10,

1-5-0-6-10, 1-5-0-6-9-10 e 1-5-6-9-10. A rota pela qual transitou a mensagem que

efectuou o menor número de hops é a seleccionada para efectuar a comunicação

entre o nó 1 e o nó 10, neste caso é a rota 1-5-10. Esta escolha é realizada pelo nó 10

que a comunica aos restantes nós que integram a rota, através de uma mensagem

unicast enviada para o nó 1. Esta mensagem percorre a rota seleccionada no sentido

inverso da mensagem que lhe deu origem (figura 2.5).

Figura 2.5 - Mensagem unicast

2.2 IEEE 802.15.4

Uma WPAN (Wireless Personal Area Network) é uma rede sem fios cujos nós

constituintes possuem uma pequena área de actuação, geralmente cerca de 10 m. O

grupo de trabalho IEEE 802.15, responsável pela normalização de redes WPAN, define

três classes para este tipo de rede [11]:

redes com alta taxa de transmissão (IEEE 802.15.3), adequadas para aplicações

que necessitem de uma elevada qualidade de serviço;


7

redes com taxa de transmissão média (IEEE 802.15.1/Bluetooth), desenvolvidas

para substituírem a cablagem eléctrica em equipamentos de electrónica de

consumo;

redes com baixa taxa de transmissão (IEEE 802.15.4), denominadas LR-WPAN,

desenvolvidas para aplicações com requisitos de qualidade de serviço menos

exigentes e com recursos de memória e processamento limitados.

As redes LR-WPAN são usadas por exemplo, em áreas como a medicina e a

domótica para tarefas de monitorização e actuação, em infra-estruturas de smart grid,

em aplicações militares e na área da automação industrial. Na figura 2.6 é possível

visualizar a comparação entre o IEEE 802.15 e um conjunto de outras tecnologias de

redes sem fios, tendo em conta o alcance e o débito de dados.

Figura 2.6 – Tecnologias de redes sem fios (retirada de [12])

O IEEE 802.15.4 define a camada física e a camada MAC dos nós de uma rede LR-

WPAN. No nível físico é disponibilizado um conjunto de 27 canais de frequência. Cada

canal é identificado por uma combinação de número de página e número de canal,

apresentados na tabela 2.1. Os canais distribuem-se pelas bandas de frequência de

868 MHz, disponível na Europa, 915 MHz, disponível na América do Norte e nalguns

países asiáticos e 2,4 GHz que se encontra disponível globalmente. Segundo o IEEE

802.15.4, um transceiver que opere na banda dos 2,4 GHz não necessita de suportar

frequências na banda dos 868/915 MHz, e nesse caso só comunicará com dispositivos


8

que suportem frequências na banda dos 2,4 GHz. Para um transceiver que opere nas

frequências de 868/915 MHz, a norma disponibiliza uma especificação de

implementação obrigatória (página 0) e duas de implementação opcional (páginas 1 e

2), não sendo necessário, no caso da página 0, implementar a banda de frequência dos

2,4 GHz [13]. O protocolo utilizado para controlo de acesso ao meio no IEEE 802.15.4 é

o CSMA/CA.

Página Número de canal Frequência Taxa de transmissão

(Kb/s) Modulação

0

0 868 MHz 20 BPSK

1-10 915 MHz 40 BPSK

11-26 2,4 GHz 250 O-QPSK

1

0 868 MHz 250 ASK

1-10 915 MHz 250 ASK

11-26 Reservado - -

2

0 868 MHz 100 O-QPSK

1-10 915 MHz 250 O-QPSK

11-26 Reservado - -

3-31 Reservado Reservado - - Tabela 2.1 - Bandas de frequência do IEEE 802.15.4

2.3 6LoWPAN

2.3.1 Problemas e objectivos

O 6LoWPAN [6] é um grupo de trabalho do IETF responsável pela definição de

normas que permitam a implementação do protocolo IPv6 sobre redes IEEE 802.15.4.

Actualmente, a implementação de redes LR-WPAN é efectuada por um conjunto de

tecnologias proprietárias, o que dificulta a interoperabilidade entre diferentes redes e

a sua inserção em serviços baseados na Internet. A integração do protocolo IP em

redes LR-WPAN permite superar este problema e introduz um conjunto de vantagens,

nomeadamente [14]:

a natureza ubíqua das redes IP permite a utilização de infra-estruturas já

existentes;


9

a tecnologia IP é bem conhecida e já se encontra devidamente testada;

o protocolo IP é definido em especificações do IETF, que são disponibilizadas

livremente;

já existem um conjunto de ferramentas disponíveis para diagnóstico e gestão

de redes IP;

dispositivos com conectividade IP podem ser ligados a uma rede IP sem

necessidade de um gateway ou proxy.

No entanto, o hardware das redes IEEE 802.15.4 tem várias limitações, que

dificultam a implementação do protocolo IP. Nomeadamente, o tamanho máximo das

frames é de apenas 127 bytes, o alcance de transmissão é no máximo de algumas

dezenas de metros, a taxa de transmissão máxima é de 250 kbps e os recursos de

memória são limitados. Por isso, a adaptação do protocolo IP a uma rede IEEE 802.15.4

levanta um conjunto de problemas [14][15], incluindo:

um pacote IPv6 deve sempre que possível ser enviado em apenas uma frame

IEEE 802.15.4, de forma a evitar uma fragmentação excessiva;

as soluções actuais para encaminhamento IP podem não ser adequadas para a

topologia mesh (que é a topologia normalmente utilizada);

o IPv6 inclui mecanismos de segurança (IPsec) que podem ser demasiado

complexos para serem usados em dispositivos IEEE 802.15.4;

os protocolos da pilha TCP/IP não estão optimizados para funcionar em redes

LR-WPAN;

os nós de uma rede LR-WPAN permanecem inactivos durante longos períodos

de tempo. No entanto, o protocolo IP assume que um dispositivo se encontra

sempre conectado.

Um dos objectivos do 6LoWPAN é definir a forma como um pacote IPv6, cujo

MTU (Maximum Transmission Unit) mínimo é de 1280 bytes, deve ser acomodado

em frames IEEE 802.15.4 que têm um MTU de apenas 127 bytes. Nesse sentido, o

6LoWPAN acrescenta uma camada de adaptação à pilha IP, que permite

fragmentar e desfragmentar um pacote IPv6 em frames IEEE 802.15.4 e efectuar a

compressão do cabeçalho IPv6 [15]. O 6LoWPAN indica ainda os requisitos para


10

efectuar o encaminhamento em redes mesh, sugere algumas recomendações de

segurança e descreve as alterações a efectuar ao Neighbor Discovery Protocol, de

forma a optimiza-lo para redes LR-WPAN. O Neighbor Discovery Protocol é um

protocolo incluído na pilha TCP/IP que tem as seguintes funções: autoconfiguração

de endereço; resolução de endereço; detecção de duplicação de endereço e

descoberta de routers. [16]. Estas recomendações são analisadas em maior detalhe

no capítulo 5.

2.3.2 Arquitectura de rede

Conforme é ilustrado na figura 2.7, uma rede 6LoWPAN pode conectar-se a outras

redes IP, que utilizem um meio físico de transmissão diferente, usando como

intermediário um edge router. A rede IP à qual é efectuada a conexão pode utilizar

qualquer tipo de meio físico de transmissão, como por exemplo PLC, Wi-Fi, Ethernet

ou GPRS. Uma rede 6LoWPAN pode ter mais do que um edge router, e um nó pode

pertencer simultaneamente a mais de que uma rede 6LoWPAN (multi-homing) [14].

Figura 2.7 - Integração do 6LoWPAN na Internet (retirada de [17])


11

2.3.3 Camada de adaptação 6LoWPAN

A figura 2.8 mostra uma comparação entre a pilha 6LoWPAN e a pilha IP. Uma

pilha 6LoWPAN tem uma estrutura similar a uma pilha IP, com a diferença de que é

introduzida uma camada de adaptação entre o IEEE 802.15.4 e a camada IP [7].

Figura 2.8 – Comparação entre a pilha 6LoWPAN e IP (retirada de [14])

A camada de adaptação tem essencialmente duas funções: compressão do cabeçalho

IPv6, e fragmentação e desfragmentação do pacote IPv6. Nesta camada, além do

cabeçalho IPv6 comprimido, podem ser acrescentados dois cabeçalhos opcionais. Um

dos cabeçalhos é acrescentado quando é efectuada a fragmentação do pacote e o

outro quando o encaminhamento mesh é efectuado ao nível da camada de ligação,

podendo então resultar frames como o ilustrado na figura 2.9.

Figura 2.9 - Cabeçalhos 6LoWPAN (retirado de [17])

A figura 2.10 descreve o formato do cabeçalho de fragmentação. Os primeiros 5

bits servem para identificar o tipo de cabeçalho. Estes bits, cujo significado é

apresentado na tabela 2.2, estão presentes em todos os tipos de cabeçalhos [18].


12

Figura 2.10 - Cabeçalho de fragmentação (retirada de [17])

O campo Datagram Size contém o tamanho total do pacote IPv6 não fragmentado. O

Datagram Tag contém um número que é igual para todos os fragmentos de um

mesmo pacote, o que permite na recepção associar os fragmentos ao respectivo

pacote. O Datagram Offset só é colocado a partir do segundo fragmento inclusive e

indica o offset do fragmento em relação ao início do payload não fragmentado, em

que cada unidade representa um bloco de 8 Bytes [17].

Tabela 2.2 - Identificação do tipo de cabeçalho (retirada de [18])

O cabeçalho mesh, apresentado na figura 2.11 é constituído por um campo que

indica o número máximo de hops que o pacote pode efectuar e dois campos que

indicam o endereço de destino e de origem. Os bits S e D indicam se o endereço de

origem e de destino respectivamente são endereços do tipo IEEE 802.15.4 de 64 bits

(valor ´0´) ou de 16 bits (valor ´1´) [18].


13

Figura 2.11 - Cabeçalho mesh (retirada de [17])

2.3.4 Compressão do cabeçalho IPv6

A compressão do cabeçalho IPv6 é efectuada eliminando total ou parcialmente

campos, que tenham valores previamente conhecidos. Por exemplo: o prefixo de 64

bits é reduzido a 1 bit quando é usado o prefixo para ligação local; os campos Traffic

Class e Flow Label são reduzidos a 1 bit quando ambos são zero; e, o campo Next

Header é reduzido a 2 bits quando o pacote usa TCP, UDP ou ICMPv6. [17] Alguns

campos podem ser eliminados, uma vez que podem ser inferidos por intermédio do

cabeçalho IEEE 802.15.4, como é o caso do Payload Lenght e por vezes dos endereços

de origem e de destino. A figura 2.12 mostra o cabeçalho IPv6 comprimido. Os

primeiros 8 bits indicam que o cabeçalho se encontra comprimido e os 8 bits seguintes

a forma como é efectuada a compressão de cada campo. Por cada endereço, um bit

indica se o prefixo usado é de ligação local e outro bit indica se o endereço pode, ou

não, ser inferido pelo endereço IEEE 802.15.4. O bit TF indica se os campos Traffic

Class e Flow Label são ambos zero, o Next Header indica o tipo do próximo cabeçalho e

o HC2 se o próximo cabeçalho se encontra comprimido [18].

Figura 2.12 - Compressão do cabeçalho IPv6 (retirada de [17])

Se o bit HC2 tiver o valor ´1´, é acrescentado ao cabeçalho UDP um conjunto de

8 bits, que especificam a forma como este é comprimido (figura 2.13) [17]. Os dois


14

primeiros bits indicam se as portas UDP são (valor ´1´) ou não (valor ´0´) comprimidas e

o terceiro bit indica se o tamanho do pacote UDP é (valor ´1´) ou não (valor ´0´)

inferido pelo tamanho do pacote IEEE 802.15.4. De acordo com o 6LoWPAN a

compressão das portas UDP pode realizar-se se estas pertencerem ao intervalo de

61616 a 61631 inclusive. Se for o caso, cada porta é apenas comprimida para apenas 4

bits [17].

Figura 2.13 - Compressão do cabeçalho UDP (retirada de [17])

2.3.5 Encaminhamento

O encaminhamento mesh numa rede 6LoWPAN pode ser implementado num de

dois níveis: ao nível da camada IP ou abaixo desta camada, conforme representado na

figura 2.14. No primeiro caso é denominado de encaminhamento route-over e no

segundo caso de encaminhamento mesh-under [19]. Conforme descrito na secção

2.3.3, o 6LoWPAN disponibiliza um cabeçalho que pode ser usado para efectuar o

encaminhamento mesh-under usando endereços IEEE 802.15.4. No entanto, não

define nenhum algoritmo de encaminhamento que use este cabeçalho. O

encaminhamento route-over baseia-se no endereçamento IP e é habitualmente o mais

usado. A principal vantagem deste tipo de encaminhamento é que este pode ser

implementado noutros meios físicos de transmissão, para além do IEEE 802.15.4,

facilitando a integração das redes 6LoWPAN com outras redes IP [14].


15

Figura 2.14 – Encaminhamento 6LoWPAN (retirada de [7])

Os primeiros protocolos desenvolvidos para redes 6LoWPAN foram baseados nos

protocolos para redes móveis ad hoc, definidos pelo grupo MANET (Mobile Ad-hoc

Networks) [20] do IETF. Entre os protocolos desenvolvidos com base no grupo MANET

encontram-se o LOAD, o TinyAODV e o AODVjr, baseados no AODV, e o DYMO-low

com base no DYMO. Estes protocolos foram desenvolvidos para funcionar ao nível da

camada de adaptação e eliminam algumas das funcionalidades dos protocolos MANET,

como por exemplo as mensagens Hello e a lista de precursores, de forma a adaptá-los

aos requisitos das redes 6LoWPAN [14]. Em 2008, o IETF criou o grupo ROLL (Routing

Over Low power and Lossy Networks) [21], com o objectivo de desenvolver soluções de

encaminhamento para redes de baixa potência, como o IEEE 802.15.4 e o Bluetooth.

Este grupo desenvolveu um protocolo de encaminhamento para redes de baixa

potência denominado Ripple (RPL) [22], que deverá tornar-se no algoritmo standard

deste tipo de redes.

2.4 Conclusões

Uma WPAN é uma rede cujos nós constituintes têm uma área de actuação de cerca

de 10 m. O IEEE 802.15 divida estas redes em três classes: redes com alta taxa de

transmissão, redes com taxa média de transmissão e redes com baixa taxa de

transmissão. O IEEE 802.15.4 define a camada física e a camada MAC das redes com

baixa taxa de transmissão, denominadas LR-WPAN. A implementação de redes LR-


16

WPAN é efectuada por um conjunto de tecnologias proprietárias ou definidas por

alianças exclusivas, o que dificulta a interoperabilidade entre diferentes redes e a sua

inserção na Internet. A integração do protocolo IP em redes LR-WPAN permite superar

este problema, no entanto é necessário optimizar os protocolos da pilha TCP/IP para

permitir a sua utilização neste tipo de redes. O 6LoWPAN é um grupo de trabalho do

IETF responsável pela definição de normas que permitam a implementação do IPv6

sobre nós IEEE 802.15.4. Este grupo define uma camada de adaptação entre o IEEE

802.15.4 e a camada IPv6, que efectua a fragmentação e desfragmentação dos pacotes

IPv6 em frames IEEE 802.15.4 e a compressão do cabeçalho IPv6. Para efectuar o

encaminhamento em redes LR-WPAN têm sido utilizadas duas soluções, uma delas é a

adaptação dos protocolos de encaminhamento para redes móveis ad hoc do grupo

MANET e outra a utilização do protocolo RPL definido pelo ROLL.

Análise e desenho da solução

17

3 Análise e desenho da solução

3.1 Especificação de requisitos

Este capítulo especifica os requisitos de software para criação de uma rede mesh

sem fios, usando módulos IEEE 802.15.4. O conteúdo apresentado faz parte do

documento de requisitos elaborado em parceria com a EFACEC Sistemas de

Electrónica.

3.1.1 Descrição Geral

O projecto tem como finalidade a criação de uma pilha de software, para

implementação de uma rede mesh sem fios. A rede terá como base nós físicos que

seguem a norma IEEE 802.15.4, e deverá permitir a utilização de outros meios físicos

para além do sem fios. A pilha de software deverá incluir uma camada de rede, e

deverá permitir a portabilidade entre diferentes plataformas de hardware. O software

deverá ser capaz de efectuar funções de gestão de rede, como permitir a inclusão de

um nó na rede, a conexão deste com outros nós, e encaminhamento de dados entre os

nós da rede.

3.1.2 Especificações

Na tabela 3.1 temos os requisitos enumerados por grupo e classificados de acordo

com os seguintes níveis de prioridade:

P0 - Essencial (nível de prioridade mais elevada). Os requisitos com este nível

de prioridade devem ser validados na primeira versão do produto.

P1 - Muito desejável (segundo nível de prioridade). Estes requisitos devem ser

contemplados numa segunda fase de implementação do produto, não é

necessário que sejam contemplados na primeira versão, mas deverão

obrigatoriamente ser implementados. A versão final do produto deve

contemplar estes requisitos que devem, nessa altura ser validados.


18

P2 - Desejável (terceiro nível de prioridade). São requisitos que têm ou podem

ter interesse para o cliente, mas cuja implementação não é indispensável. Se

forem implementados, devem ser validados.

Ref. Descrição Prioridade

Geral

G1 A rede deverá permitir a utilização de outros meios de

transmissão, para além do sem fios.

P0

G2 A rede de comunicação implementada deverá ter algoritmos de

redes mesh.

P0

G3 Cada nó de rede deverá suportar no mínimo 3 dispositivos. P0

Hardware

HW1 A rede deverá ser implementada em módulos IEEE 802.15.4. P0

Software

SW1 As camadas da pilha de rede mesh devem seguir o modelo de

referência OSI:

P0

SW2 Possibilidade de activar e desactivar traces de comunicações das

várias camadas protocolares.

P0

Funcionais

FC1 A rede deverá ter um coordenador. P0

FC2 A rede deverá suportar, inicialmente, no mínimo 15 nós. P0

FC3 A rede deverá suportar, na versão final, no mínimo 1000 nós. P1

FC4 A rede deverá suportar um nível de profundidade mínimo de 7. P0

FC5 Possibilidade de o nó ser apenas repetidor. P0

FC6 Selecção do canal de forma manual. P0

FC7 Selecção do canal de forma automática. P1

FC8 Determinar a qualidade da ligação entre nós (LQI), podendo estes

dados ser usados de forma a permitir a definição de rotas.

P1

FC9 Deve ser garantido que a rede utilize um PAN ID diferente, de

outras redes eventualmente existentes.

P0

FC10 A rede deverá ser capaz de atribuir diferentes níveis de prioridade P2


19

a cada mensagem.

FC11 Implementação do processo de associação e dissociação de rede,

de forma automática.

P0

FC12 As mensagens deverão conter um mecanismo de validação das

mesmas (por exemplo CRC).

P0

FC13 Implementação de transmissão de dados com aviso de recepção,

e numeração de tramas.

P0

FC14 A implementação do modo robusto de transmissão, e a alteração

deste para o modo normal, e vice-versa, deverá ser automática.

P1

FC15 Deverá ser possível parametrizar o número de repetições, e

timeout, para a transmissão de uma determinada mensagem.

P0

FC16 Todos os nós da rede poderão ser configurados para ter um

endereço fixo ou dinâmico.

P0

FC17 Implementação de broadcasting. P0

FC18 Implementação de multicasting. P0

FC19 Emissão e recepção de pedidos para descoberta de rota. P0

FC20 Determinação do custo de cada rota, e selecção da rota de menor

custo.

P0

FC21 O dispositivo deverá guardar de forma persistente uma tabela de

encaminhamento.

P0

FC22 O nó deverá ter a capacidade de recuperação de rota, ou

redescoberta de rota, em caso de falha.

P0

FC23 O coordenador deverá ter um serviço para fazer um reset à rede,

de forma a reconfigurar toda a topologia da rede.

P2

FC24 A rede deverá se manter inalterável mesmo depois de um reset

global dos nós.

P0

Diagnóstico

DG1 Cada nó deverá guardar informação de diagnóstico como:

número de mensagens enviadas, recebidas, de falhas de

comunicação, e retransmissões.

P0

DG2 O coordenador deverá poder aceder a informação do estado da P0


20

rede tais como topologia, e qualidade da ligação entre cada nó.

DG3 O nó coordenador deverá ser informado de tudo o que se passa

na rede ( joins, removes, rejoines).

P0

DG4 Cada nó deverá suportar watchdog de SW e HW. P0

Tabela 3.1 - Especificação de requisitos

3.2 Topologia da rede

Conforme ilustrado na figura 3.1, a rede será constituída por um

dispositivo coordenador responsável por registar parâmetros da rede. Um, ou

mais, dispositivos edge router permitirão a comunicação com outras redes

existentes, que utilizem meios físicos de transmissão diferentes. A rede permitirá

ainda a existência de nós repetidores que recebem o sinal e o retransmitem para

os nós vizinhos. A profundidade da rede será determinada pelo número máximo

de saltos entre nós (hops), que um pacote poderá efectuar. Por exemplo na figura

3.1 a profundidade é 6.

Figura 3.1 – Topologia da rede


21

3.3 Escolha do Hardware

O hardware escolhido para o desenvolvimento do projecto foi o kit RZRAVEN da

Atmel para aplicações sem fios de baixo consumo de energia. Este kit foi seleccionado

de entre um conjunto de módulos IEEE 802.15.4 disponíveis no mercado (ver tabela

3.2). O facto de permitir o suporte a IPv6, através da pilha IPv6 do Contiki, assim como

o preço baixo comparativamente a outros módulos, foram os principais motivos que

levaram à escolha desta plataforma de hardware. O kit RZRAVEN é constituído por um

stick USB para ligar ao PC e duas placas com microcontrolador AVRRAVEN. As

AVRRAVEN foram utilizadas para implementar os nós da rede mesh e podem ser

programados por ISP (In-system-programming), JTAG e via wireless pelo stick, mas neste

último caso apenas permite actualizar o firmware fornecido pela Atmel.

Kit/Módulo Transceiver Microcontrolador Sistema operativo

BTnode TI CC1000 ATmega 128L TinyOS

RZRaven AT86RF230 ATmega 1284PV Contiki

TinyNode Semtech SX1211 TI MSP430 TinyOS

Tmote Sky TI CC2420 TI MSP430 Contiki, TinyOS

ZDK AT86RF230 ATmega 1281V Contiki

Iris AT86RF230 Atmega 1281 TinyOS

MicaZ TI CC2420 Atmega 128L TinyOS, Contiki

Imote2 TI CC2420 Marvell PXA271 TinyOS

Mica2 TI CC1000 ATmega 128L TinyOS

TelosB TI CC2420 TI MSP430 TinyOS, Contiki

Tabela 3.2 – Módulos IEEE 802.15.4


22

3.4 Escolha do Software

A pilha de software desenvolvida está integrada num sistema operativo para

sistemas embebidos. A escolha desta opção prende-se com o facto de permitir a

portabilidade da pilha, uma vez que o sistema operativo contém um conjunto de

interfaces para diferentes plataformas de hardware. Os sistemas operativos open

source mais utilizados em redes de sensores sem fios, e com maior grau de

portabilidade entre plataformas, são o TinyOS e o Contiki, conforme ilustram as

tabelas 3.2 e 3.3.

Tabela 3.3 – Pilhas open source

Dado que a rede deve ser capaz de comunicar através do protocolo IPv6 com outras

redes que utilizem um meio físico de transmissão diferente, a pilha a escolher deverá

disponibilizar suporte para IPv6. Existem duas pilhas open source disponíveis para os

sistemas operativos anteriormente referidos (tabela 3.3) e que suportam IPv6: a Blip

para o TinyOS e a uIPv6 para o Contiki. A escolha do hardware e software a utilizar foi

Pilha S.O. suportado Hardware Suportado Nível OSI Serviços

FreakZ Contiki Atmel Raven 2,3 Zigbee, mesh

Rime Contiki Atmel Raven, TelosB,

Tmote Sky

2,3 Mesh

Blip TinyOS TelosB, Iris, MicaZ 2,3,4 6LoWPAN, mesh

Nanostack FreeRTOS Sensinode micro e nano. 2,3 6LoWPAN, mesh

Microchip - PIC18, PIC24 e transceivers

MRF24J40, MRF24J40MA,

e MRF24J40MB

2,3 Zigbee, mesh

Open-zb TinyOS TelosB 2,3 Zigbee, Cluster

tree

uIPv6 Contiki Atmel Raven, Tmote

Sky/TelosB, e noutras

plataformas baseadas no

MSP430, e Atmel AVR

2,3,4 6LoWPAN

openMAC - Módulos Zigbit e Atmel 2


23

feita em conjunto por haver uma interdependência entre elas. A pilha seleccionada

para a elaboração deste projecto foi a uIPv6, que é compatível com a plataforma de

hardware adoptada, a Raven da Atmel.

Figura 3.2 – Camadas de rede

A pilha IPv6 do Contiki é constituída por cinco camadas protocolares (figura

3.2), que se descrevem de seguida:

Camada física IEEE 802.15.4 – O Contiki inclui uma camada de abstracção de

hardware para o transceiver AT86RF230, e disponibiliza um interface que

permite ler e alterar parâmetros do mesmo.

SICSLoWMAC – Camada MAC de suporte ao 6LoWPAN, para a AVR Raven.

SICSLoWPAN – Camada de adaptação 6LoWPAN que permite que pacotes IPv6

sejam transmitidos sobre dispositivos IEEE 802.15.4. É responsável, entre

outras funções, pela compressão do header TCP/IP, e pela fragmentação dos

pacotes IPv6 em frames IEEE 802.15.4.

uIP TCP/IPv6 – Implementação da pilha de protocolos TCP/IP. Entre os

protocolos implementados encontram-se o ICMPv6 (RFC 4443), e o Neighbor

Discovery Protocol (RFC 4861). Este último inclui funcionalidades como DAD

(Duplicate Address Detection), NUR (Neighbor Unreachability Detection), e

autoconfiguração de endereço (RFC 4862).


24

3.5 Protocolo de encaminhamento

A implementação do encaminhamento será baseada no protocolo AODV (Ad hoc

On Demand Distance Vector Routing) [8]. O Contiki inclui uma implementação route-

over deste protocolo (ver secção 2.3.5), ou seja o encaminhamento é efectuado ao

nível da camada IP.

No protocolo AODV, quando um nó pretende iniciar uma comunicação verifica

na sua tabela de encaminhamento se existe uma rota para o destino pretendido. Caso

isso não se verifique, o nó inicia um processo de descoberta de rota. O processo é

iniciado com a criação de um pacote Route Request (RREQ). Entre os dados enviados

no RREQ, encontram-se os endereços IP do nó origem e do nó destino, o número de

sequência, e o número de hops. O nó incrementa o seu número de sequência e envia o

pacote para todos os seus vizinhos (figura 3.3).

Figura 3.3 – Requisição de rota

Cada nó guarda um número de sequência, que é incrementado sempre que é enviado

um Route Request, ou um Route Reply. Este número permite determinar se os dados


25

disponibilizados no RREQ estão mais actualizados que os guardados na tabela de

encaminhamento de cada nó. Na figura 3.3, o nó 1 incrementa o número de sequência

de 110 para 111 e efectua um RREQ.

Quando um nó recebe um RREQ, incrementa o número de hops do pacote e

verifica se já existe uma entrada na tabela de encaminhamento para o nó que enviou o

RREQ, se não existir é criada uma entrada. Se já existir uma entrada na tabela de

encaminhamento, a entrada é actualizada se o número de sequência recebido no

RREQ for maior que o número de sequência guardado na entrada da tabela. Se os

números de sequência forem iguais, a tabela só é actualizada se o número de hops do

RREQ mais um, for menor que o número de hops da tabela. No caso em que o número

de sequência da tabela é maior que o número de sequência do RREQ, o nó pode enviar

um Route Reply (RREP) para indicar que já possui uma rota para o destino. No exemplo

da figura 3.3, como o número de sequência do RREQ é 111 e o número de sequência

da tabela é 78, a tabela de encaminhamento do nó 2 será actualizada. Neste exemplo,

todos os campos da tabela irão permanecer iguais, com excepção do número de

sequência que irá passar para 111.

Figura 3.4 – Envio de RREQ

Após actualizar a tabela, e caso não tenham enviado um RREP, o nó 2 e 4 enviam o

RREQ para os seus vizinhos (figura 3.4), que após a recepção do RREQ actualizam as


26

suas tabelas de encaminhamento. O fluxograma do processo que é efectuado por um

nó quando recebe uma RREQ é descrito de forma completa na figura 3.5.

Figura 3.5 - Recepção de um RREQ

Quando um RREQ chega ao nó de destino, é enviado um RREP para o nó que

requisitou a rota. Um Route Reply contém o número de hops, o número de sequência

do destino, e os endereços IP do destino e da fonte. No processo de encaminhamento

da RREP, as tabelas de cada nó são actualizadas de forma similar ao procedimento

efectuado para os RREQ (figura 3.6).


27

Figura 3.6 – Actualização da tabela

3.6 Conclusões

O objectivo deste trabalho consiste na implementação de uma pilha para redes

LR-WPAN que satisfaça os requisitos definidos em conjunto com a EFACEC Sistemas de

electrónica. A rede a implementar deverá incluir um edge router que permita a

comunicação com outras redes, um nó coordenador que receba informações de

diagnóstico dos outros nós da rede e nós repetidores. A pilha seleccionada para a

elaboração deste trabalho foi a uIPv6 incluída no sistema operativo Contiki. A pilha

utiliza o protocolo IPv6, o que facilita a comunicação com outras redes que utilizem um

meio físico de transmissão diferente e permite a portabilidade entre diferentes

plataformas de hardware, por se encontrar inserida num sistema operativo. O sistema

operativo Contiki inclui ainda uma implementação route over do algoritmo de

encaminhamento AODV, que será o algoritmo utilizado neste trabalho. O hardware

utilizado neste trabalho será o kit RZRaven da Atmel que é constituído por um stick usb

e por duas placas AVR Raven.

Ambiente de trabalho

28

4 Ambiente de trabalho

4.1 Cooja

O Cooja é um simulador para redes de sensores sem fios, desenvolvido em Java e

integrado no Contiki. O simulador disponibiliza diferentes modelos de propagação de

ondas rádio, concretamente:

Unit Disk Graph Medium – permite criar um círculo à volta do nó que define o

alcance máximo da transmissão (figura 4.1a).

Directed Graph Radio Medium – permite parametrizar uma ligação entre dois

nós.

Multi-path Ray-tracer Medium – permite visualizar, e alterar, um conjunto de

características do rádio e da onda propagada, e também introduzir obstáculos à

propagação das ondas (figura 4.1b).

Figura 4.1 – Modelos de propagação rádio

Antes de inicializar a simulação, é necessário compilar o código que executará

em cada um dos nós que serão utilizados na simulação. Os nós podem ser simulados


29

para uma plataforma de hardware específica (Tmote Sky, MicaZ e ESB), ao nível do

sistema operativo Contiki ou pode ser seleccionada uma aplicação java já existente. No

menu Mote Type -> Create Mote Type é possível seleccionar a que nível o nó será

simulado. Quando um nó é simulado ao nível do sistema operativo, é necessário

seleccionar a pilha de comunicação que será utilizada. Existem três pilhas disponíveis:

uipv6, uipv4 e Rime (figura 4.2).

Figura 4.2 – Selecção da pilha de comunicação

São disponibilizados pelo simulador um conjunto de interfaces para interacção

com o nó como por exemplo, um interface que simula um conjunto de LEDs e outro

que simula um botão. Os interfaces que se pretendem que sejam incluídos na

simulação podem ser seleccionados no momento da compilação, no separador Mote

interfaces (figura 4.3). Para visualizar, ou alterar, o estado dos interfaces durante a

simulação, pode-se carregar com o botão direito do rato sobre o nó, e seleccionar

Open Mote Plugin for Contiki X -> Mote Interface Viewer.


30

Figura 4.3 – Selecção dos interfaces dos nós

O Cooja disponibiliza um conjunto de plugins que permitem visualizar

características da simulação. Entre os plugins disponibilizados existe uma

representação gráfica da posição dos nós, um logger e uma tabela temporal,

apresentados na figura 4.4.

Figura 4.4 – Plugins


31

4.2 AVR Raven

A AVR Raven (ver figura 4.5) é uma plataforma de hardware para comunicações sem

fios que segue a norma IEEE 802.15.4. Cada módulo inclui um transceiver AT86RF230 e

dois microcontroladores: o microcontrolador ATmega1284PV que controla as

comunicações, e o ATmega3290PV que controla o LCD. Uma memória EEPROM de 2

Kbits encontra-se conectada ao ATmega3290PV, enquanto o microcontrolador

ATmega1284PV é conectado a uma memória flash de 16 Mbits. O transceiver

AT86RF230 efectua a validação das frames recebidas (CRC), e permite a leitura dos

seus parâmetros, como por exemplo LQI (Link Quality Indication), RSSI (Received Signal

Strength Indicator) e ED (Energy Detection). A AVR Raven inclui um conjunto de

interfaces que podem ser usados para comunicação série, interacção com sensores

externos, programação e debug. Ambos os microcontroladores incluídos na placa

podem ser programados por ISP ou JTAG. A AVR Raven pode ser alimentada por duas

baterias LR44 ou por uma alimentação externa entre 5 e 12 Volts.

Figura 4.5 – AVR Raven

4.3 AVR Dragon

Para programar os nós da rede mesh (AVRRAVEN) foi utilizada uma AVR Dragon

também da Atmel porque, não é possível programar via wireless, dado que esta opção

apenas está disponível se for usado o firmware disponibilizado no kit RZRaven. A AVR


32

Dragon (ver figura 4.6) é uma plataforma de hardware para programação, e emulação,

de microcontroladores da família AVR. A AVR Dragon liga-se à AVR Raven via JTAG, e

ao PC por USB. Para utilizar a AVR Dragon é necessário ter instalado no PC o software

AVR Studio. O AVR Studio é um IDE disponibilizado gratuitamente pela Atmel e que

inclui um simulador, um assemblador e um compilador para a linguagem C. Foi esta

ferramenta que foi utilizada para desenvolver e programar os nós da rede mesh

durante o trabalho aqui descrito.

Figura 4.6 – AVR Dragon

4.4 Modelo de programação do Contiki

4.4.1 Protothreads

Em sistemas com restrições de memória, como redes LR-WPAN, o uso de um

modelo de programação baseado em multi-threading é desaconselhado, uma vez que

consome uma elevada percentagem de memória. Num sistema multi-threading, a cada

thread é alocada em memória uma pilha de execução, espaço esse que não pode ser

utilizado por mais nenhuma outra thread (ver figura 4.7b). Como a alocação de

memória é efectuada no momento de criação da thread, e dado ser difícil determinar

antecipadamente qual o tamanho da pilha que a thread necessitará, a memória

alocada é por vezes sobredimensionada Por esta razão, em sistemas com restrições de

memória, o multi-threading é geralmente preterido, em favor de um modelo de

programação orientado a eventos. Neste modelo, todas as threads partilham a mesma

pilha, o que permite minimizar a percentagem de memória utilizada (figura 4.7a) [23].


33

Figura 4.7 – Utilização de memória para implementar a pilha de execução threads e protothreads

(retirada de [23])

O modelo de programação orientado a eventos não suporta blocos de espera

condicional, por exemplo não é possível bloquear a execução de um programa

enquanto se aguarda que ocorra um evento, como a expiração de um timer, e depois

continuar a execução a partir da linha de código em que o programa foi bloqueado.

Num sistema orientado a eventos, o programa apenas é executado em resposta à

ocorrência de um evento e não pode ser bloqueado em nenhum momento da sua

execução. Isto implica que a implementação tenha que ser efectuada usando

máquinas de estado. A utilização de máquinas de estado aumenta a complexidade do

código e torna mais difícil a sua programação, porque o código é implementado de

forma não sequencial (figura 4.8) e os programadores estão normalmente habituados

à programação sequencial. De forma a beneficiar das vantagens de um modelo

orientado a eventos e das vantagens de um sistema multi-threading, o Contiki

implementa um mecanismo denominado protothread. Uma protothread permite a

implementação de blocos condicionais mas, contrariamente a uma thread tradicional,

pode partilhar a mesma pilha com outras protothreads [23].


34

Figura 4.8 – Comparação do código usado em threads e eventos (retirada de [23])

Uma protothread implementa os três padrões básicos que podem ser habitualmente

encontrados num sistema orientado a eventos: sequência, iteração e selecção (figura

4.9). Numa sequência, a protothread é parada até que se verifique uma determinada

condição, após a condição ser verdadeira a protothread continua a sua execução.

Numa iteração, a protothread permanece no mesmo estado enquanto se verificar uma

condição, prosseguindo a sua execução quando esta condição for falsa. Numa

selecção, a protrothread é parada e só prossegue a sua execução caso se verifique uma

de duas, ou mais, condições [23].

Figura 4.9 – Padrões básicos de um sistema orientado a eventos (retirada de [23])


35

O Contiki fornece um kernel orientado a eventos, em cima do qual podem ser

executados processos. Um processo é uma protothread que é invocada sempre que o

processo recebe um evento. Tipicamente um processo segue um modelo similar ao

apresentado na figura 4.10. Após o processo ser iniciado (através da função

PROCESS_BEGIN()), este é bloqueado e aguarda um evento. Quando um evento

ocorre, o kernel invoca o processo e este prossegue a sua execução. No exemplo

apresentado, a função PROCESS_YIELD () bloqueia o processo. Quando ocorre um

evento, o processo continua a sua execução e verifica se o evento foi causado pelo

timer previamente definido. Existem outros eventos para além do timer, como é o

caso do evento TCP/IP que é accionado quando ocorre um evento na pilha IPv6, por

exemplo a recepção de uma mensagem.

Figura 4.10 – Processo

4.4.2 Compilação

O Contiki é disponibilizado num ambiente de desenvolvimento denominado

Instant Contiki, que contém um conjunto de ferramentas para compilação e simulação.

Este sistema consiste numa máquina virtual Ubuntu, que é executada no VMWare

Player. Para criar um projecto deve ser criada uma pasta, com o ficheiro que contém o

código, na directoria Contiki-2.4. O projecto é compilado usando o compilador GCC,


36

que permite criar código executável para ser utilizado numa plataforma diferente da

que está a ser utilizada pelo compilador. Neste caso, o código será compilado numa

máquina virtual Ubuntu e posteriormente descarregado para a AVR Raven por

intermédio da AVR Dragon e do AVR Studio. Para compilar um projecto no Contiki,

deve ser colocado na directoria onde se encontra o projecto um makefile com o código

igual ao da figura 4.11, substituindo onde diz project pelo nome do projecto. A este

makefile deve ser acrescentado uma linha com o código UIP_CONF_IPv6 = 1, de forma

a compilar a pilha IPv6.

Figura 4.11 – Makefile

De seguida é necessário executar a seguinte linha de comando na directoria do

projecto:

make TARGET = platform project

Em que platform é uma das plataformas disponíveis na directoria platform, e para a

qual se pretende compilar o projecto definido em project. Para os casos da AVR Raven

e do simulador Cooja seria respectivamente:

make TARGET = avr-raven project

make TARGET = cooja project

O Contiki utiliza um conjunto de makefiles que permitem compilar um projecto.

Sendo eles os seguintes:

Makefile: O makefile do projecto

Makefile.include: O makefile geral do Contiki, localizado na raiz do sistema

operativo.


37

Makefile.$(TARGET): makefile da plataforma, localizada na directoria

platform, em que $(TARGET) é o nome da plataforma para a qual o projecto

vai ser compilado.

Makefile.$(CPU): regras para a arquitectura do CPU, localizado na directoria

CPU, em que $(CPU) é o nome do CPU utilizado pela plataforma para a qual

o projecto vai ser compilado.

Makefile.$(APP): regras para compilar as aplicações na directoria apps, em

que $(APP) é o nome da aplicação.

4.5 Conclusões

O Contiki inclui um simulador para redes de sensores sem fios denominado Cooja.

Este simulador disponibiliza três modelos de propagação de ondas rádio e permite

simular um nó em três diferentes níveis: para um plataforma de hardware específica,

ao nível do sistema operativo Contiki ou pode ser seleccionada uma aplicação Java já

existente. O Contiki tem um modelo de programação baseado em protothreads. Uma

protothread é uma thread que permite a implementação de blocos condicionais, tal

como num sistema multi-threading mas, ao contrário de uma thread tradicional, pode

partilhar a mesma pilha com outras protothreads. O kit RZRAVEN da Atmel é

constituído por um stick usb e por duas placas AVR Raven. Cada AVR Raven inclui um

transceiver AT86RF230 e dois microcontroladores: o microcontrolador ATmega1284PV

que controla as comunicações, e o ATmega3290PV que controla o LCD. Uma memória

EEPROM de 2 Kbits encontra-se conectada ao ATmega3290PV, enquanto o

microcontrolador ATmega1284PV é conectado a uma memória flash de 16 Mbits. Para

programar os nós da rede (AVR RAVEN) foi utilizada uma AVR Dragon. A AVR Dragon é

uma plataforma de hardware para programação, e emulação, de microcontroladores

da família AVR.

Descrição da implementação

38

5 Descrição da implementação

5.1 Análise comparativa

5.1.1 6LoWPAN

O IEFT define um conjunto de normas que descrevem a forma como o

protocolo IPv6 deve ser implementado. Das normas definidas, o Contiki implementa as

seguintes:

RFC 2460 – Especificação do IPv6.

RFC 4291 – Especifica a arquitectura de endereçamento do IPv6. Define o

formato básico dos vários tipos de endereços IPv6 (unicast, anycast e multicast).

RFC 4443 – Define o protocolo ICMP (Internet Control Message Protocol).

RFC 4861 - Especifica o protocolo Neighbor Discovery v6.

RFC 4862 – Descreve os passos necessários para um nó efectuar

autoconfiguração de endereço.

O grupo 6LoWPAN do IETF foi criado com o propósito de definir um conjunto

de normas que permitam a implementação do protocolo IPv6 em dispositivos IEEE

802.15.4. As normas definidas pelo 6LoWPAN são:

RFC 4919 – Indica os objectivos do grupo 6LoWPAN.

RFC 4944 – Define uma camada de adaptação para transmissão de pacotes IPv6

em redes IEEE 802.15.4

draft-ietf-6lowpan-hc – Especifica como deve ser efectuada a compressão dos

cabeçalhos IPv6.

draft-ietf-6lowpan-nd – Optimização do protocolo Neighbor Discovery para

utilização em redes de baixa potência.

draft-ietf-6lowpan-routing-requirements – Requisitos para efectuar o

encaminhamento em redes 6LoWPAN.


39

Destas normas, o Contiki apenas implementa o RFC 4944 e o draft-ietf-

6lowpan-hc. Na tabela 5.1 são indicadas algumas das alterações que devem ser

efectuadas ao protocolo Neighbor Discovery do Contiki (RFC 4861), de forma a

seguir as recomendações do draft-ietf-6lowpan-nd-09.

RFC 4861 draft-ietf-6lowpan-nd-09

-

Cada nó deve registar-se num router fornecendo o(s) seu(s)

endereço(s) IP e endereço MAC. Um router (edge router) é

responsável por guardar os dados de todos os nós da rede.

Neighbor Solicitation As Neighbor Solicitations são enviadas para o router,

evitando o uso de multicasting.

Resolução de endereço É eliminado o uso de multicasting para resolução de

endereço. A resolução de endereço é feita pelos routers.

Cada router mantém uma tabela com os endereços MAC dos

nós a que está conectado.

Detecção de duplicação de

endereço.

Os routers recebem os endereços IP e MAC e comunicam

com o edge router para verificar se existe duplicação de

endereço para um determinado nó. Se o endereço IP do nó a

que está a ser feito o DAD já estiver registado com endereço

MAC diferente, é considerado que existe uma duplicação de

endereço. Este mecanismo de DAD é opcional.

Redireccionamento São eliminadas mensagens de redireccionamento.

Router Apenas são emitidos router advertisements após um envio

de um router solicitation por parte de um nó host. São assim

eliminados router advertisements não solicitados ou

periódicos.

- Permite que um host fique em standby.

- Introduz mecanismos opcionais para transmitir informações

de contexto.

Tabela 5.1 – Recomendações para o protocolo Neighbor Discovery


40

5.1.2 Rede mesh

O desenho de um protocolo de encaminhamento para redes 6LoWPAN é

condicionado por dois atributos, característicos deste tipo de rede. O primeiro atributo

a considerar é o da conservação de energia. O consumo de energia provocado pelo

protocolo de encaminhamento deve ser baixo, uma vez que os módulos podem ser

alimentados por baterias. O segundo atributo a considerar é a baixa performance do

hardware utilizado pelas redes 6LoWPAN, constituídas por dispositivos com

capacidade computacional reduzida, pequena memória e baixa taxa de transmissão.

Tendo em contas estes atributos, um protocolo de rede mesh para redes 6LoWPAN

deve obedecer aos seguintes requisitos [19]:

Dado o tamanho de uma frame IEEE 802.15.4, o protocolo de

encaminhamento deve impor um baixo overhead nos pacotes de dados.

O protocolo deve ter um baixo overhead nos pacotes de controlo do

encaminhamento.

Os requisitos de computação e memória do protocolo de encaminhamento

devem ser mínimos, o que implica que deve ser evitada a manutenção e

armazenamento de tabelas de encaminhamento de grande dimensão.

Suporte para topologias em que os nós são alimentados por bateria, o que

inclui a possibilidade de efectuar o encaminhamento na presença de nós

em standby.

Na tabela 5.2 é possível visualizar algumas das recomendações do 6lowpan-

routing-requirements-06, em comparação com a implementação do AODV para o Contiki

(uAODV).

6lowpan-routing-requirements-06 uAODV

O protocolo de encaminhamento deve

permitir uma implementação que consuma

poucos recursos de hardware.

O uAODV elimina algumas das

funcionalidades do AODV de forma a não

sobrecarregar os recursos de hardware.

O protocolo deve minimizar os gastos de

energia, melhorando a eficiência com que os

O uAODV envia um multicasting para todos os

nós quando efectua um route request.


41

pacotes de controlo são enviados.

Nomeadamente deve ser evitado o envio de

mensagens multicast ao nível IP que

provoquem um broadcast ao nível da camada

de ligação.

Uma mensagem de controlo não deve

exceder o tamanho de uma frame IEEE

802.15.4.

As mensagens de controlo não excedem o

tamanho de uma frame IEEE 802.15.4.

A métrica usada pelo protocolo de

encaminhamento pode ser baseada em

parâmetros obtidos na camada de ligação,

como o LQI e o RSSI.

Usa o número de hops para determinar a

melhor rota.

Não recomenda a implementação de

mensagens Hello, podendo em alternativa,

para determinar se um nó está activo, usar

outros mecanismos como os acknowledges

recebidos pela camada de ligação.

Não implementa mensagens Hello. O nó é

considerado inactivo quando é removido da

tabela de vizinhos.

O protocolo de encaminhamento deve ser

confiável mesmo que alguns dos nós da rede

possam entrar em hibernação.

O protocolo de encaminhamento não tem em

consideração a existência de nós em estado

de hibernação.

O protocolo de encaminhamento deve

garantir a segurança dos dados enviados nas

mensagens de controlo. Podem ser usados os

mecanismos existentes no IEEE 802.15.4

como o AES.

A plataforma de hardware e software

utilizadas não garantem a segurança dos

dados.

Tabela 5.2 – Recomendações para o protocolo de encaminhamento

Desta forma conclui-se que as principais diferenças entre o uAODV e as

recomendações do 6LoWPAN são a utilização de multicasting nos pacotes de controlo,

por parte do uAODV e a inexistência de mecanismos de segurança no software e no

hardware utilizados.


42

5.2 Alterações à pilha

5.2.1 Multicast

Contrariamente aos requisitos especificados, a pilha IPv6 do Contiki não

fornece suporte para multicast, dessa forma foi necessário efectuar a sua

implementação. O multicast foi implementado usando flooding, ou seja, quando um

nó envia um pacote, este é encaminhado para todos os nós da rede que verificam

individualmente se pertencem ao grupo multicast para o qual foi enviado o pacote. O

uso de flooding é preferível, em vez de os pacotes serem enviados directamente para

os elementos do grupo, dado que esta última solução implicaria a manutenção de um

conjunto de tabelas que aumentam o consumo de energia e a percentagem de

memória utilizada [24]. No exemplo da figura 5.1, o nó 1 incrementa o seu número de

sequência e efectua um broadcast para os nós que se encontram na sua área de

transmissão.

Figura 5.1 - Envio do pacote

O número de sequência é um número único para cada nó, que é incrementado sempre

que é efectuado um multicast. Ao pacote IPv6 enviado é substituído o campo com o

número de hops máximo por um campo com o número de sequência do nó de origem

da mensagem. Quando o pacote é recebido pelos nós na área de transmissão do nó 1,

estes verificam se o pacote já foi recebido anteriormente. Para o efeito, foi

acrescentado a cada nó uma tabela com o número de sequência e o endereço de


43

origem dos últimos pacotes recebidos, um exemplo de tabela é apresentado na tabela

5.3 e o código que a declara na figura 5.2.

Número de sequência Endereço do nó

123 FE80::0011::22ff::fe33::4455

234 FE80::0011::22ff::fe33::4454

Tabela 5.3 – Tabela multicast

Se o número de sequência do pacote recebido for igual, ou menor, que o número de

sequência da entrada da tabela para o endereço do nó 1, o pacote é descartado.

Figura 5.2 - Declaração da tabela multicast

Na situação inversa, cada nó actualiza o número de sequência para a entrada do nó 1 e

verifica se pertence ao grupo multicast para o qual está a ser enviado o pacote. Se

pertencer então passa o pacote para a camada de aplicação. Quer o nó pertença ou

não ao grupo, este irá retransmitir o pacote, caso seja router, para os nós na sua área

de transmissão, conforme se constata na figura 5.3. Ao ser retransmitido o pacote será

enviado novamente para o nó 1, mas como o endereço de origem do pacote é igual ao

do nó 1 este será descartado.

Figura 5.3 - Retransmissão do pacote


44

Um processo similar é efectuado pelos restantes nós da rede, o que permite que a

mensagem seja retransmitida por toda a rede. O fluxograma da figura 5.4 indica o

algoritmo que é efectuado por cada nó, quando recebe um pacote multicast. A

implementação do fluxograma pode ser vista no Anexo A.

Figura 5.4 - Algoritmo do multicast


45

5.2.2 Protocolo de comunicação da topologia

De forma a indicar ao coordenador a topologia da rede, sempre que é alterada a

tabela de encaminhamento de um nó, é enviado por esse nó para o coordenador, um

pacote de dados UDP com o formato da figura 5.5. O campo comando indica se foi

criada (código “01”), ou eliminada (código “02”), uma ligação com o nó cujo endereço

é indicado no pacote de dados.

Figura 5.5 - Frame de encaminhamento

5.3 Programa de demonstração

De forma a demonstrar o funcionamento da pilha IPv6 para redes mesh que foi

desenvolvida, foi também desenvolvido para PC um programa de demonstração em

linguagem Java. O programa exibe a topologia da rede e permite visualizar a rota

efectuada por uma mensagem, quando esta é enviada de um nó para outro. A

comunicação entre o computador, onde se encontra instalado o demonstrador, e os

restantes nós da rede é efectuada usando o stick disponível no kit RZRAVEN da Atmel.

No entanto, não é possível instalar a totalidade da pilha IPv6 no stick, dado que este

não tem recursos de memória suficientes. A versão da pilha instalada no stick apenas

efectua o encaminhamento de mensagens entre o PC e um nó da rede e vice-versa.

Entre as funcionalidades que não são implementadas no stick encontra-se o protocolo

UDP, que é necessário para executar o processo que implementa o algoritmo de

encaminhamento (uAODV). Esta circunstância impossibilita que o uAODV possa ser

executado no stick, impedindo o stick de participar na rede, uma vez que não pode

requisitar uma rota, encaminhar mensagens ou participar na descoberta de uma rota.

Dessa forma a comunicação entre o stick e a rede é efectuada usando um nó da rede


46

como intermediário (figura 5.6); este nó, que corresponde ao nó coordenador, é

responsável por receber as mensagens do stick e encaminhá-las para a rede ou vice-

versa. O software instalado no nó coordenador difere do que é instalado nos outros

apenas ao nível da aplicação.

Figura 5.6 - Topologia da rede

5.3.1 Captura dos pacotes

Para efectuar a captura dos pacotes recebidos pelo stick, o software

desenvolvido usa uma biblioteca denominada Jpcap [25]. A Jpcap é uma biblioteca

intermédia entre a linguagem Java e a API responsável pela captura dos pacotes. No

caso do sistema operativo Windows esta API é a WinPcap e no Linux é a Libpcap,

ambas são implementadas em linguagem C e devem ser instaladas previamente. A

Jpcap permite efectuar as seguintes operações:

Identificar todos os interfaces de rede existentes no sistema como por

exemplo, o interface Ethernet e o stick USB da RZRaven.

Capturar pacotes de um interface de rede.

Aplicar filtros à captura de pacotes, como por exemplo, filtrar apenas

pacotes UDP ou TCP.

Enviar pacotes.

Gravar os pacotes capturados num ficheiro.

Ler os pacotes capturados de um ficheiro.


47

Na tabela 5.4 são apresentadas as classes da biblioteca Jpcap, que se

encontram divididas em dois pacotes: jpcap, que disponibiliza um conjunto de classes

para capturar e enviar pacotes de um interface de rede e ler e escrever pacotes num

ficheiro; e o jpcap.packet, que inclui um conjunto de classes que representam um

pacote.

Pacote Classe Descrição

Jpcap

JpcapCaptor É usada para capturar pacotes ou ler pacotes

de um ficheiro.

JpcapSender É usada para enviar um pacote.

JpcapWriter É usada para guardar pacotes num ficheiro.

NetworkInterface Representa um interface de rede.

NetworkInterfaceAddress Representa um endereço associado a um

interface de rede

jpcap.packet

ARPPacket Representa um pacote ARP/RARP.

DatalinkPacket Representa um pacote da camada de ligação.

EthernetPacket Representa um pacote Ethernet.

ICMPPacket Representa um pacote ICMP

IPPacket Representa um pacote IP

IPv6Option Representa os cabeçalhos do IPv6

Packet Representa um pacote genérico é a classe da

qual derivam todas as restantes classes do

pacote jpcap.packet.

TCPPacket Representa um pacote TCP.

UDPPacket Representa um pacote UDP

Tabela 5.4 – Classes da Jpcap


48

Na tabela 5.5 são descritos os métodos que foram utilizados na elaboração do

trabalho e a classe a que pertencem. No anexo B encontra-se a lista completa dos

métodos disponíveis na Jpcap.

Método Classe Função

openDevice(NetworkInterface device) JpcapSender Abre um interface de rede para

enviar um pacote.

sendPacket(Packet packet) JpcapSender Envia um pacote.

setIPv6Parameter(int cls, int flowlabel,

int nxt_hdr, int hop_limit,

java.net.InetAddress src,

java.net.InetAddress dst)

UDPPacket Define os parâmetros do

cabeçalho IPv6, nomeadamente:

classe; flow label; next header;

número máximo de hops;

endereço de origem; endereço

de destino.

getPacket() JpcapCaptor Captura um pacote.

getDeviceList() JpcapCaptor Devolve todos os interfaces de

rede.

openDevice(NetworkInterface intrface, int snaplen, boolean promisc, int to_ms)

JpcapCaptor Abre um interface de rede para

capturar um pacote, indicando o

número máximo de bytes que

podem ser capturados, se o

interface usa ou não o modo

promíscuo e o timeout de

espera.

Tabela 5.5 - Métodos utilizados

5.3.2 Descrição funcional

A figura 5.7 apresenta o programa de demonstração que foi desenvolvido. De

forma a não ocupar um espaço demasiado grande do ecrã e permitir a visualização de


49

um maior número de nós de forma clara, cada nó é representado por um círculo e é

identificado apenas pelo último byte do respectivo endereço IPv6, sendo os restantes

bytes iguais para os endereços de todos os nós. O nó identificado com o número 85 é o

nó intermédio entre o stick e os restantes nós da rede.

Figura 5.7 – Programa de demonstração

Para enviar uma mensagem entre dois nós, é necessário premir com o botão

direito do rato sobre o círculo cujo nó se pretende que envie a mensagem. Ao fazer

isto, surge uma caixa de diálogo que permite indicar o endereço do nó (apenas o

último byte) para o qual será enviada a mensagem, e também escrever a mensagem

pretendida (figura 5.8).


50

Figura 5.8 - Escrever mensagem

No exemplo da figura 5.8, o nó que irá enviar a mensagem será o nó 86, e o nó

que irá receber a mensagem é o nó 89. Quando o botão “Enviar” é premido, a

mensagem é enviada do PC para o nó intermédio. Após a recepção da mensagem pelo

nó intermédio, este verifica qual é o nó de origem e se já existe uma rota para esse nó.

No exemplo apresentado na figura 5.8, como essa rota já existe, a mensagem é

encaminhada para o nó de origem, ou seja, para o nó 86. Se não existisse rota seria

necessário efectuar um processo de descoberta de rota. O trajecto desde o nó

intermédio até ao nó de origem é transparente para o programa que corre no PC.

Quando a mensagem chega ao nó de origem, inicia-se o processo que é ilustrado na

aplicação do PC. Como no exemplo não existe uma rota do nó origem para o nó

destino, o nó 86 não poderá enviar a mensagem e terá que obter primeiro uma rota

para o nó 89. A figura 5.9 mostra a nova topologia da rede, após o processo de

descoberta de rota ter sido concluído.


51

Figura 5.9 - Descoberta de rota

Uma vez que já existe uma rota disponível, a mensagem já pode ser enviada do

nó 86 para o nó 89. Ao chegar ao nó 89, a mensagem é enviada para o PC onde é

apresentada no ecrã junto ao nó que a recebeu (89), assim como o caminho percorrido

pela mesma entre os nós 86 e 89, conforme ilustra a figura 5.10.

Figura 5.10 - Recepção da mensagem

O demonstrador permite também obter o valor da temperatura que é lido pelo

sensor que se encontra nos módulos RAVEN. Para seleccionar o nó do qual se pretende

obter o valor da temperatura, clica-se sobre o mesmo com o botão esquerdo do rato.

A temperatura é apresentada debaixo do círculo de cujo nó se pretende saber a

temperatura (figura 5.11).


52

Figura 5.11 - Leitura do sensor de temperatura

5.3.3 Implementação

Para efectuar a comunicação entre as aplicações que correm no nó intermédio, no

PC e nos restantes nós foi necessário definir um protocolo de comunicação que será

descrito nesta secção. Este protocolo será implemetado ao nivel da camada de

aplicação. O pacote de dados da figura 5.12 é usado sempre que se pretende enviar

uma mensagem entre dois nós.

Figura 5.12 - Formato da mensagem

No campo comando é colocado o código que indica que está a ser enviada uma

mensagem (tabela 5.6), os campos seguintes são respectivamente o último byte do

endereço do nó origem e do nó destino, segue-se o tamanho da mensagem e por fim

é colocada a mensagem. No exemplo da secção 5.3.2, o pacote de dados enviado do

PC para o nó 86, e do nó 86 para o nó 89 segue o formato da figura 5.12, contendo no

campo comando o código A1. Quando a mensagem é enviada do nó 89 para o PC o

formato permanece o mesmo, no entanto, é alterado o código que é enviado no

campo comando passando a ser 05.


53

Enviado

por:

Código Descrição

Aplicação

dos Nós

01 Enviado pelo nó para indicar que existe uma nova ligação.

02 Enviado pelo nó para indicar que eliminou uma ligação.

04 Enviado pelo nó para indicar que recebeu uma mensagem.

05 Recepção de uma mensagem pelo demonstrador

54 Recepção do valor da temperatura pelo demonstrador.

Aplicação

do PC

A1 Indica que está a ser enviada uma mensagem.

A2 Indica um pedido para envio do valor da temperatura.

Tabela 5.6 - Códigos

Sempre que é efectuado um processo de descoberta de rota, os nós da rede

vão actualizando as respectivas tabelas de encaminhamento. Sempre que é criada, ou

eliminada, uma ligação é enviada para o nó coordenador, mediante o mecanismo

descrito na secção 5.2.2, um pacote de dados igual ao da figura 5.5. Este mecanismo é

parte integrante da pilha e não faz parte da aplicação que corre nos nós da rede. Após

a recepção destes pacotes de dados pelo nó coordenador, este envia-os para o stick.

No exemplo apresentado na figura 5.9, o nó 88 enviou um pacote com o código 01 e

com o endereço do nó 86, e uma segundo pacote com o mesmo código e com o

endereço do nó 89. Caso o nó 88 fosse desligado da rede e o nó 86 efectuasse um

novo pedido de rota e este fosse bem sucedido, seria enviado pelo nó 86 um pacote

com o código 02 e o endereço do nó 88.

À medida que é feito o encaminhamento de uma mensagem entre o nó de

origem e o nó de destino, todos os nós pelos quais a mensagem transita enviam um

pacote para o PC, para indicar a origem da mensagem. O demonstrador irá

posteriormente utilizar a informação recebida através deste conjunto de pacotes, para

indicar o caminho percorrido pela mensagem. Os pacotes enviados pelos nós para o PC

seguem o formato da figura 5.5. O campo comando deverá conter o código que indica

que o nó recebeu uma mensagem (04), e no campo endereço deverá ser colocado o

endereço do nó de origem da mensagem que no exemplo da secção 5.3.2 é o nó 86.


54

De forma a efectuar um pedido para obter o valor da temperatura de um nó, é enviado

pelo PC um pacote com o formato da figura 5.13, em que o campo comando contém o

código A2 para indicar um pedido de temperatura e o endereço é o nó do qual se

pretende obter o valor da temperatura. O pacote é encaminhado para o nó de destino

e após a sua recepção este envia uma frame para o PC igual à da figura 5.13, com o

comando 54 e com o valor da temperatura.

Figura 5.13 - Frame da temperatura

Para implementar o programa de demonstração que corre no PC foram usadas

um conjunto de funções da biblioteca Jpcap, que se indicam a seguir:

NetworkInterface: utilizado para guardar o interface de rede, neste caso o stick;

JpcapCaptor: utilizado para capturar os pacotes que são recepcionados pelo

stick;

JpcapSender: utilizado para enviar pacotes pelo stick;

UDPPacket: utilizado para criar um pacote UDP para ser enviado ao para ser

capturado;

EthernetPacket: utilizado para criar os pacotes Ethernet, sobre os quais eram

enviados os pacotes UDP do PC para o stick;

5.4 Conclusões

As principais diferenças entre o uAODV e as recomendações do 6LoWPAN são a

utilização de multicasting nos pacotes de controlo, por parte do uAODV e a


55

inexistência de mecanismos de segurança no software e no hardware utilizados.

Contrariamente aos requisitos especificados, a pilha IPv6 do Contiki não fornece

suporte para multicast, tendo sido necessário efectuar a sua implementação. O

multicast foi implementado usando flooding, ou seja, quando um nó envia um pacote,

este é encaminhado para todos os nós da rede que verificam individualmente se

pertencem ao grupo multicast para o qual foi enviado o pacote. Além do multicast foi

necessário implementar um mecanismo que permita ao nó coordenador aceder à

topologia da rede. De forma a demonstrar o funcionamento da pilha IPv6, foi

desenvolvido um programa de demonstração em linguagem Java. Este programa

permite visualizar a topologia da rede, assim como a rota efectuada por uma

mensagem, quando esta é enviada de um nó para outro. Para efectuar a captura dos

pacotes recebidos pelo stick, o software desenvolvido usa uma biblioteca denominada

Jpcap. A Jpcap é uma biblioteca intermédia entre a linguagem Java e a API responsável

pela captura dos pacotes, que no caso do Windows é a WinPcap e no Linux é a

Libpcap.

Teste e resultados

56

6 Teste e Resultados

De forma a demonstrar o funcionamento do algoritmo de encaminhamento,

apresenta-se de seguida um exemplo onde é possível visualizar a formação da rede, o

encaminhamento de dados entre os nós da rede, o processo de descoberta de rota e

de recuperação de uma rota. A demonstração será efectuada usando o Wireshark e o

programa de demonstração descrito anteriormente. Inicialmente, todos os nós da rede

tentam conectar-se ao nó intermédio entre o stick e a rede. O pedido de conexão de

cada nó é efectuado enviando um RREQ tendo como destino o nó intermédio. O nó

intermédio responde com um RREP a cada uma das RREQ recebidas, formando-se

assim um conjunto de conexões entre todos os nós da rede e o nó intermédio. A figura

6.1 mostra uma topologia da rede, que tem como nó intermédio o nó 55, assim como

as mensagens trocadas entre o nó 53 e o nó intermédio para criar uma rota. Na figura

6.1 são visíveis os pacotes IP (2 e 8), os pacotes do neighbor discovery protocol (5 e 6) e

as frames IEEE 802.15.4 (1,3,5 e 7).

Figura 6.1 - Conexão com o nó intermédio

Após a criação das rotas, é possível enviar uma mensagem entre o nó 52 e o nó 55,

usando o nó 53 como intermediário. A figura 6.2 mostra o encaminhamento da

mensagem do nó 55 para o nó 52 e a resposta enviada pelo nó 52. Na figura não é

visível o encaminhamento do nó 52 para o nó 53, porque o sniffer utilizado para

efectuar a captura dos pacotes está junto ao nó 55 e portanto as mensagens emitidas

pelo nó 52 estão fora do alcance da respectiva antena.

Teste e resultados

57

Figura 6.2 - Envio de mensagem

De forma a simular um processo de recuperação de rota, é desligado o nó 53 e

conectado o nó 54 na mesma posição onde se encontrava o nó 53. Conforme se pode

verificar na figura 6.3, o nó 53 não desaparece da topologia, uma vez que o AODV é um

protocolo reactivo, logo só será criada uma nova rota quando o nó 52 tentar

comunicar com o nó 55 ou vice-versa. Na figura 6.3 é visível o envio do RREQ por parte

do nó 54 e o do RREP por parte do nó 55. Sempre que um nó envia uma mensagem é

também enviado um Neighbor solicitation. O nó que para o qual foi enviada a

mensagem responde ao Neighbor solicitation com um Neighbor advertisement.

Figura 6.3 - Introdução de um novo nó

Quando o nó 55 tenta comunicar com o nó 52 a mensagem é na mesma enviada, mas

como o nó 53 não responde com um Neighbor Advertising ao Neighbor solicitation

enviado pelo nó 55, este nó passa a considerar a rota como inválida (figura 6.4). No

Teste e resultados

58

entanto, a rota mantém-se na tabela de encaminhamento do nó 55 se este não tentar

enviar uma nova mensagem para o nó 52.

Figura 6.4 - Envio de Neighbor Solicitation

Só se o nó 55 tentar enviar uma mensagem para o nó 52, é que será efectuado um

novo processo de descoberta de rota. Nesse caso, antes de enviar a mensagem, o nó

55 efectua um RREQ, que é repetido pelo nó 54. O nó 52 quando recebe o RREQ envia

o RREP, que é reencaminhado pelo nó 54 para o nó 55 (figura 6.5).

Figura 6.5 - Criação de nova rota

Após a descoberta da rota, já é possível comunicar novamente entre o nó 52 e o nó 55.

Conforme é visível na figura 6.6.

Figura 6.6 - Reenvio da mensagem

Teste e resultados

59

6.1 Conclusões

Os resultados dos testes ao protocolo de encaminhamento foram positivos tendo

sido possivel visualizar a formação de uma rota entre dois nós, o envio de uma

mensagem entre dois nós e a formação de uma nova rota em caso de falha da rota

previamente existente.

Conclusões

60

7 Conclusões

As redes LR-WPAN usam actualmente um conjunto de protocolos, que geralmente

ou são proprietários ou especificados por alianças exclusivas. A existência de

diferentes protocolos provoca problemas de interoperabilidade entre diferentes redes

e dificulta a sua integração na Internet. O protocolo IP devido à sua natureza ubíqua e

escalabilidade é a solução ideal para resolver este problema. No entanto, este

protocolo foi desenvolvido para redes com recursos de hardware mais vastos do que

as redes LR-WPAN e com menos limitações ao nível do dispêndio de energia. Desse

modo, é necessário optimizar os protocolos da pilha TCP/IP para permitir a sua

utilização em redes LR-WPAN, podendo também, nalguns casos, serem criados novos

protocolos em substituição de alguns dos protocolos TCP/IP. Uma vez que as frames

usadas pelo hardware destas redes têm um tamanho mais pequeno do que o pacote

IPv6, têm que ser introduzidos mecanismos de compressão do cabeçalho IPv6 e de

fragmentação e desfragmentação do pacote IPv6. A escolha do algoritmo de

encaminhamento para utilização em redes LR-WPAN, também é condicionada pelas

limitações impostas pelas características do hardware utilizado neste tipo de rede.

Para efectuar o encaminhamento têm sido utilizadas duas soluções, uma delas é a

utilização dos protocolos de encaminhamento para redes móveis ad hoc do grupo

MANET e outra a utilização do protocolo RPL definido pelo ROLL.

O objectivo do trabalho era a implementação de uma pilha para redes LR-WPAN

que satisfizesse os requisitos definidos em conjunto com a EFACEC Sistemas de

electrónica. A rede a implementar deveria ser capaz de comunicar com outras redes

que utilizassem meios físicos de transmissão diferentes, mediante a utilização de um

edge router. A rede deveria ainda ter um nó coordenador que recebesse informações

de diagnóstico dos outros nós da rede, como por exemplo a topologia da rede. Neste

trabalho foi apresentada uma solução baseada na pilha uIPv6, que se encontra

integrada no sistema operativo para sistemas embebidos Contiki. Este sistema

operativo tem um modelo de programação baseado em protothreads. Uma

Conclusões

61

protothread é uma thread que permite a implementação de blocos condicionais, tal

como num sistema multi-threading mas, ao contrário de uma thread tradicional, pode

partilhar a mesma pilha com outras protothreads. Como plataforma de hardware foi

usada o kit RZRAVEN da Atmel que é constituído por um stick usb e por duas placas

AVR Raven. O sistema operativo Contiki disponibiliza uma adaptação para redes LR-

WPAN do algoritmo de encaminhamento AODV, denominada uAODV. A solução

encontrada não segue completamente as recomendações do 6LoWPAN,

nomeadamente usa multicasting para enviar os pacotes de controlo do algoritmo de

encaminhamento e não implementa soluções de segurança. De forma a serem

implementados a totalidade dos requisitos especificados, foi necessário efectuar a

implementação do multicasting e de um protocolo que permitisse que o nó

coordenador pudesse saber a topologia da rede. Foi ainda desenvolvido, um programa

de demonstração que permite visualizar a topologia da rede, assim como a rota

efectuada por uma mensagem, quando esta é enviada de um nó para outro. Os

requisitos especificados foram cumpridos e os resultados dos testes efectuados foram

positivos. Quanto a eventuais alterações futuras ao software desenvolvido, poderá

passar por adaptar o algoritmo de encaminhamento e o protocolo Neighbor Discovery

às recomendações do 6LoWPAN descritas na secção 5.1.

Glossário

62

Glossário

Edge router – Router que conecta uma ou mais redes de área local.

Frame – Uma frame é um pacote de dados que é utilizado no nível 2 do modelo

OSI.

Gateway – Dispositivo que permite conectar uma ou mais redes que utilizem

protocolos diferentes.

Pacote – É uma sequência de dados transmitida por uma rede ou linha de

comunicação.

Payload – São os dados efectivos que são transmitidos num pacote.

Router – Dispositivo que conecta uma ou mais redes e efectua o

encaminhamento de pacotes de dados entre as várias redes.

Bibliografia

63

Bibliografia

[1] IEEE 802.15.4 - http://www.ieee802.org/15 Consultado em 12 de Outubro de 2010.

[2] Zigbee - http://www.zigbee.org/ Consultado em 12 de Outubro de 2010.

[3] MiWi - http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE

&nodeId=2113&param=en520414 Consultado em 12 de Outubro de 2010.

[4] WirelessHART - http://www.hartcomm.org/protocol/wihart/wireless_techno

logy.html Consultado em 12 de Outubro de 2010.

[5] RFC 2460 - http://tools.ietf.org/html/rfc2460 Consultado em 2 de Setembro de

2010.

[6] 6LoWPAN - http://datatracker.ietf.org/wg/6lowpan/ Consultado em 2 de Setembro

de 2010.

[7] RFC 4944 - http://www.rfc-editor.org/rfc/rfc4944.txt Consultado em 2 de Setembro

de 2010.

[8] AODV - http://www.ietf.org/rfc/rfc3561.txt Consultado em 19 de Julho de 2010.

[9] DYMO - http://www.ianchak.com/dymo/draft-ietf-manet-dymo-04.txt Consultado

em 12 de Outubro de 2010.

[10] DSR - http://www.ietf.org/rfc/rfc4728.txt Consultado em 12 de Outubro de 2010.

[11] José A. Gutierrez; Edgar H. Callaway Jr; Raymon L. Barrett Jr, Low-Rate Wireless

Sensors with IEEE 802.15.4, Standards Information Network IEEE Press, 2004.

[12] Houda Labiod; Hossam Afifi; Constantino De Santis, Wi-Fi, Bluetooth and Wimax,

Springer, 2007

[13] Shahin Farahani, Zigbee Wireless Networks and transceivers, Newnes, 2008.

Bibliografia

64

[14]Zach Shelby; Carsten Bormann, 6LoWPAN The Wireless Embedded Internet, Wiley,

2009

[15] RFC 4919 http://datatracker.ietf.org/doc/rfc4919/ Consultado em 10 de Setembro

de 2010.

[16] RFC 4861 http://tools.ietf.org/html/rfc4861 Consultado em 10 de Setembro de

2010.

[17] Jonathan Hui; David Culler; Samita Chakrabarti, 6LoWPAN: Incorporating IEEE

802.15.4 into the IP architecture, IPSO Alliance, 2009.

[18] Naveed Abbasi, 6LoWPAN for Battery-less Building Networks, Technische

Universiteit Eindhoven, 2009

[19] draft-ietf-6lowpan-routing-requirements - http://datatracker.ietf.org/doc/draft-

ietf-6lowpan-routing-requirements/

[20] MANET - http://datatracker.ietf.org/wg/manet/charter/ Consultado em 25 de

Setembro de 2010.

[21] ROLL - http://datatracker.ietf.org/wg/roll/ Consultado em 25 de Setembro de

2010.

[22] Ripple - https://datatracker.ietf.org/wg/roll/charter/ Consultado em 25 de

Setembro de 2010.

[23] Adam Dunkels; Oliver Schmidt; Thiemo Voigt; Muneeb Ali, Protothreads:

Simplifying Event-Driven Programming of Memory Constrained Embedded Systems,

Swedish Institute of Computer Science, 2006

[24] Gerald Wagenknecht; Markus Anwander; Marc Brogle; Torsten Braun, Reliable

Multicast in Wireless Sensor Networks, University of Bern.

[25] Jpcap - http://netresearch.ics.uci.edu/kfujii/Jpcap/doc/ Consultado em 3 de

Outubro de 2010.

Anexos

65

Anexo A – Implementação do multicast

struct multicast_cache *cache;

if(is_hostaddr(&UIP_IP_BUF->srcipaddr))

{

goto drop;

}

cache = multicast_cache_addr_lookup(&UIP_IP_BUF->srcipaddr);

if(cache->seqn < &UIP_IP_BUF->ttl || cache == NULL)

{

multicast_cache_add_entry(&UIP_IP_BUF->srcipaddr, &UIP_IP_BUF->ttl);

memcpy(rot_buf, UIP_IP_BUF, uip_len);

rot_buf_len = uip_len;

uip_ipaddr_copy(&destino, &UIP_IP_BUF->destipaddr);

process_post(&rot, ROUTE, 0);

}

else{

goto drop;

}

if(multicast_addr_lookup(&UIP_IP_BUF->destipaddr)!= NULL);

{

goto drop;

}

Anexos

66

Anexo B – Classes e métodos da Jpcap

Anexos

67

josé antónio da cunha teixeira gomes criação de uma rede...

Documents