José António da Cunha Teixeira Gomes Criação de uma rede...
Transcript of 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
Fundamentos Teóricos
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
Fundamentos Teóricos
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;
Fundamentos Teóricos
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
Fundamentos Teóricos
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;
Fundamentos Teóricos
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
Fundamentos Teóricos
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])
Fundamentos Teóricos
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].
Fundamentos Teóricos
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].
Fundamentos Teóricos
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
Fundamentos Teóricos
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].
Fundamentos Teóricos
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-
Fundamentos Teóricos
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.
Análise e desenho da solução
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
Análise e desenho da solução
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
Análise e desenho da solução
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
Análise e desenho da solução
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
Análise e desenho da solução
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
Análise e desenho da solução
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).
Análise e desenho da solução
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
Análise e desenho da solução
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
Análise e desenho da solução
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).
Análise e desenho da solução
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
Ambiente de trabalho
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.
Ambiente de trabalho
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
Ambiente de trabalho
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
Ambiente de trabalho
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].
Ambiente de trabalho
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].
Ambiente de trabalho
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])
Ambiente de trabalho
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,
Ambiente de trabalho
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.
Ambiente de trabalho
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.
Descrição da implementação
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
Descrição da implementação
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.
Descrição da implementação
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.
Descrição da implementação
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
Descrição da implementação
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
Descrição da implementação
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
Descrição da implementação
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
Descrição da implementação
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.
Descrição da implementação
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
Descrição da implementação
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
Descrição da implementação
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).
Descrição da implementação
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.
Descrição da implementação
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).
Descrição da implementação
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.
Descrição da implementação
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.
Descrição da implementação
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
Descrição da implementação
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¶m=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;
}