Setembro 2008
Transporte de dados multimédia em Redes de Sensores
Sem Fios.
J
OÃO
C
ASTRO DE
A
LMEIDA
Dissertação para obtenção do Grau de Mestre em
E
NGENHARIA
E
LECTROTÉCNICA E DE
C
OMPUTADORES
Júri
Presidente: Prof. Mário Serafim dos Santos Nunes
Orientador: Prof. António Manuel Raminhos Cordeiro Grilo
Co-Orientador: Prof. Paulo Rogério Barreiros d'Almeida Pereira
Vogal: Prof. Renato Jorge Caleira Nunes
Agradecimentos
Em primeiro lugar, gostaria de agradecer o enorme e incansável apoio que recebi dos meus orientadores, os professores António Grilo e Paulo Pereira.
Gostava de agradecer também à minha família e amigos, que não só compreenderam a minha ausência nos seis meses que estive dedicado à elaboração deste projecto, como também me apoiaram e me motivaram ainda mais para que o terminasse em tempo útil e com sucesso. Por isso, e porque merecem todo o reconhecimento, quero agradecer em especial às seguintes pessoas: Marta Almeida, Rute Machado, Hernâni Fernandes, José Gonçalves, Sidónio Resendes e Yoann Lage. Muito Obrigado!
Resumo
Neste trabalho efectuou-se o estudo e implementação de soluções que permitam o transporte de tráfego multimédia em Redes de Sensores Sem Fios, formalmente conhecidas por Redes de Sensores Sem Fios Multimédia (Wireless Multimédia Sensor Networks – WMSNs). O projecto foi inteiramente baseado no DTSN (Distributed Transport for Sensor Networks1).
O trabalho consistiu em dotar o DTSN de uma estrutura e mecanismos adicionais que lhe permitissem garantir um Serviço de Fiabilidade Diferenciada ao tráfego que atravessa a rede. Este serviço permite dividir uma trama de dados a ser enviada, em vários blocos, cada um com uma fiabilidade e tamanho definidos pela aplicação. Sendo assim, não é pedida a repetição de pacotes que sejam perdidos na rede e que pertençam a blocos de dados cuja fiabilidade mínima já foi atingida. Alem de diminuir as retransmissões na rede e aumentar o desempenho do sistema, este serviço vai consequentemente aumentar o tempo de vida dos nós do mesmo.
Alem do Serviço de Fiabilidade Diferenciada, foi elaborado um módulo de recuperação de pacotes. Funcionando numa camada acima do DTSN, este módulo é completamente transparente ao transporte, e permite recuperar um pacote perdido por cada bloco de pacotes, com um auxílio de um pacote de paridade.
Foi efectuada uma simulação utilizando o TOSSIM – simulador de redes para TinyOS - para que pudesse ser testado o desempenho no protocolo e o comportamento do mesmo. Verificou-se que as novas extensões do protocolo DTSN se comportam como previsto e a sua utilização pode contribuir para o aumento do desempenho da nova geração de redes de sensores.
Palavras – Chave:
Redes de Sensores Sem Fios Protocolo de Transporte Multimédia
Fiabilidade Diferenciada
1
O DTSN é um protocolo de transporte para redes de sensores que foi desenvolvido no INOV no âmbito do projecto IST FP6 UbiSec&Sens.
Abstract
This project consisted on the study and implementation of a transport protocol for Wireless Multimedia Sensor Networks. The work was based on an existing transport protocol for sensor networks called DTSN (Distributed Transport for Sensor Networks2)
For accomplishing that goal, some structural changes were made to DTSN and mechanisms were added, in order to provide a Differentiated Reliability Service for packets flowing on the sensor network. This service allows a multimedia data stream to be divided on several multimedia blocks with different reliability, whose size and reliability grade are configured by the application. With this extension implemented, lost packets from multimedia blocks with the minimum reliability already assured, will not be claimed lost by the receiver, and hence will not be retransmitted. That will cause less retransmissions on the network, throughput improvements and a significant raise of network nodes lifetime with no significant degradation of the transmitted stream, as low reliability packets are thought to be less important.
A packet recovery module has also been implemented, which allows the recovery of one lost packet per multimedia block, based on an additional packet (parity packet) that must be sent (by the stream sender) for each block. This module works on top of transport layer and is completely transparent to it.
Tests were carried out in TOSSIM – a network simulator for TinyOS. Performance and functional tests were made to the protocol, which have demonstrated the correct operation of the developed protocol and the advantages of the proposed solution.
Keywords:
Wireless Sensor Networks Transport Protocol
Multimedia
Differentiated Reliability
2
This transport protocol for Wireless Sensor Networks was developed at INOV in the context of project IST FP6 UbiSec&Sens.
Conteúdo
1.
Introdução ... 1
1.1 Enquadramento... 1
1.2 Objectivos ... 2
1.3 Estrutura da dissertação ... 3
2.
Estado da Arte das Redes de Sensores Sem Fios ... 4
2.1 Características das Redes de Sensores Sem Fios ... 4
2.2 Hardware ... 6
2.3 Sistemas Operativos ... 7
2.3.1 SensorWare ... 7
2.3.2 Eyes – Energy Efficient Sensor Networks ... 8
2.3.3 TinyOS... 8
2.4 Simuladores ... 8
2.4.1 TOSSIM ... 9
2.4.2 Avrora ... 9
2.5 Tecnologia de transmissão para Redes de Sensores Sem Fios ... 10
2.6 Encaminhamento em Redes de Sensores Sem Fios ... 11
2.6.1 SPIN ... 11
2.6.2 Directed Diffusion ... 12
2.6.3 DSDV optimizado ... 12
2.7 Protocolos de transporte para Redes de Sensores Sem Fios ... 13
2.7.1 Características dos protocolos de transporte para Redes de Sensores Sem Fios ... 13
2.7.2 Protocolos existentes para Redes de Sensores Sem Fios. ... 17
2.8 Redes de Sensores Sem Fios Multimédia ... 25
2.8.1 Hardware específico para Redes de Sensores Sem Fios Multimédia ... 25
2.8.2 Factores que influenciam o projecto de Redes de Sensores Sem Fios Multimédia... 27
2.8.3 Redes de Sensores Sem Fios Multimédia já desenvolvidas ... 28
3.
Serviço de Fiabilidade Diferenciada do DTSN ... 30
3.1 Serviço de Fiabilidade Diferenciada com configuração estática ... 31
3.1.1 Organização e configuração do protocolo para blocos de pacotes com fiabilidade
diferenciada ... 31
3.1.2 Funcionamento do serviço ... 33
3.2.1 Estrutura dos pacotes e funcionamento da camada de aplicação ... 36
3.2.2 Funcionamento do serviço ... 37
3.3 Camada responsável pela recuperação de pacotes perdidos ... 40
3.3.1 Construção e envio do pacote FEC – Emissor ... 41
3.3.2 Recuperação de pacotes perdidos usando FEC – Receptor ... 43
3.3.3 Interacção entre camadas FEC e DTSN para aproveitamento de recursos ... 46
3.4 Implementação do sistema em ambiente TinyOS ... 46
3.4.1 Serviço de Fiabilidade Diferenciada ... 47
3.4.2 Camada de Recuperação de Pacotes ... 48
4.
Avaliação ao desempenho do Sistema Implementado ... 49
4.1 Testes ao débito do sistema ... 49
4.2 Tempo de transmissão ... 52
4.3 Fiabilidade mínima e real ... 53
4.4 Teste ao desempenho da camada de recuperação de pacotes ... 54
4.5 Ocupação de memória ... 55
5.
Conclusões e trabalho futuro ... 57
Lista de Figuras
Figura 1.1: Ilustração de uma rede de sensores sem fios ... 1
Figura 2.1: Mote MICAz da Crossbow ... 6
Figura 2.2: Mote TelosB da Crossbow ... 6
Figura 2.3 MIB520CA da Crossbow ... 7
Figura 2.4: Representação das topologias em estrela e peer-to-peer. ... 10
Figura 2.5 Protocolos de transporte existentes para WSNs. ... 18
Figura 2.6: Fluxograma do funcionamento do DTSN – emissor ... 22
Figura 2.7: Fluxograma do funcionamento do DTSN - nós intermédios ... 23
Figura2.8: Fluxograma do funcionamento do DTSN – Receptor ... 24
Figura 2.9: Diagrama temporal do funcionamento do DTSN ... 24
Figura 2.10: Módulo Cyclops ligado a um mote MICAz ... 26
Figura 2.11: Imote2 da Crossbow... 26
Figura 2.12: Sensor usado na rede Panoptes ... 28
Figura 2.13: Representação de uma rede de sensores multimédia multicamada – Senseye... 29
Figura 2.14: Utilização de um nó de uma rede Deep Vision para monitorização de um ninho. . 29
Figura 3.1: Estrutura de armazenamento de informação sobre blocos ... 32
Figura 3.2: Array que define a fiabilidade mínima para cada bloco ... 32
Figura 3.3: Fluxograma do funcionamento do serviço de fiabilidade diferenciada (conf. estática)
do DTSN - emissor ... 33
Figura 3.4: Fluxograma da gestão da informação dos diversos blocos ... 34
Figura 3.5: Fluxograma do processo de decisão sobre resposta a mensagens de controlo EAR
do emissor ... 35
Figura 3.6: Estrutura do pacote da camada de aplicação. ... 36
Figura 3.7: Estrutura do payload do pacote da camada de aplicação. ... 37
Figura 3.8: Fluxograma do funcionamento da camada de aplicação... 37
Figura 3.9: Estrutura do Pacote que chega à camada de transporte. ... 38
Figura 3.10: Fluxograma do funcionamento do serviço de fiabilidade diferenciada
(configuração dinâmica) do DTSN (emissor). ... 38
Figura 3.11 Representação do comportamento do receptor quando recebe uma mensagem de
configuração. ... 39
Figura 3.12: Diagrama temporal do funcionamento do serviço de fiabilidade diferenciada do
DTSN ... 40
Figura 3.13: Fluxograma do funcionamento da camada de recuperação de pacotes – Recepção
e processamento da mensagem de configuração. ... 42
Figura 3.14: Fluxograma do funcionamento da camada de recuperação de pacotes – Recepção
e processamento de uma mensagem de dados. ... 43
Figura 3.15: Fluxograma do funcionamento da camada de recuperação de pacotes – Receptor.
... 44
Figura 3.16: Diagrama temporal do funcionamento da camada FEC. ... 45
Figura 3.17: Utilização da interface Multiblock ... 47
Figura 3.18: Utilização das interfaces Multiblock e FecCalc. ... 48
Figura 4.1: Ilustração de uma rede com 4 hops. ... 49
Figura 4.2: Gráfico representativo da variação do débito com a fiabilidade dos blocos
multimédia. ... 50
Figura 4.3: Gráfico representativo da variação do débito do sistema com a fiabilidade dos
blocos multimédia para 8 hops. ... 50
Figura 4.4: Gráfico representativo da variação do débito com o número de hops (Fiabilidade
total e diferenciada). ... 52
Figura 4.5: Gráfico representativo da variação do tempo de transmissão com o número de
“hops” (Fiabilidade total e diferenciada). ... 53
Figura 4.6: Gráfico ilustrativo da influência do uso da camada FEC no ritmo de transmissão do
sistema. ... 54
Lista de Tabelas
Lista de Siglas
ACK – Acknowledgment
ARQ – Automatic Repeat Request CCF – Control and Fairness CN – Congestion Notification
CODA – Congestion Detection and Avoidance CSMA – Carrier Sense Multiple Access
DSDV - Destination-Sequenced Distance Vector routing DTSN – Distributed Transport for Sensor Netwoks EAR – Explicit Acknowledgment Request
EEPROM – Electrically Erasable Programmable Read Only Memory ESRT – Energy Saving Token Ring Protocol
FFD – Full Function Devices FEC – Forward Error Correction FIFO – First In First Out
IEEE – Institute of Electrical and Electronics Engineers IP – Internet Protocol
MANET – Mobile Ad-Hoc Network NACK – Negative Acknowledgment PC – Personal Computer
PCCP – Priority Based Congestion Protocol
PEROS - Preemptive Eyes Real time Operating System PSFQ – Pump Slowly Fetch Quickly
QoS – Quality of Service RAM – Random Acess Memory RBC – Reliable Bursty Convergecast RF – Radio Frequency
RFD – Reduced Function Devices
ROM – Read Only Memory
RSSF – Redes de Sensores Sem Fios RTT – Round Trip Time
SPIN – Sensor Protocol for Information via Negotiation STCP – Sensor Transmission Control Protocol
TCP – Transmission Control Protocol UDP – User Datagram Protocol USB – Universal Serial Bus
WLAN – Wireless Local Area Network
WMSN – Wireless Multimedia Sensor Network WSN – Wireless Sensor Network
1. Introdução
1.1 Enquadramento
Nos últimos anos, os avanços na miniaturização dos componentes electrónicos (nomeadamente sensores), o aumento do poder de processamento dos microcontroladores e os avanços nas tecnologias de comunicação RF de baixa potência (e.g., Bluetooth e ZigBee) permitiram o despontar das Redes de Sensores Sem Fios [1] (Wireless Sensor Networks – WSNs). Estas redes descentralizadas não carecem de infra-estrutura previamente instalada, sendo formadas por pequenos dispositivos, energeticamente autónomos, com sensores e/ou actuadores acoplados, e equipados com interfaces de rede sem fios de baixo consumo (usualmente RF), com capacidade para se auto-organizar e estabelecer ligações entre si, formando rotas de encaminhamento para a transmissão dos dados. Uma ou mais estações de base (nós geralmente mais potentes que recolhem e processam a informação da rede de sensores sem fios) formam os pontos de contacto com sistemas externos que monitorizam e processam a informação recolhida. A flexibilidade deste tipo de redes permite a recolha e comunicação dos dados mesmo em ambientes hostis e zonas de difícil acesso. A integração
dessas redes com as tecnologias de redes móveis (ex: WLANs, 3G, etc.) e eventualmente com a Internet, faz com que, em qualquer parte do mundo se possa monitorizar a informação recolhida nessas redes. A limitada potência de transmissão e sensibilidade de recepção dos nós da rede, faz com que a informação se propague dos sensores até às estações de base em
múltiplos saltos, desempenhando cada nó da rede o papel de encaminhador (routers) do tráfego de outros nós.
A evolução na área da electrónica e a diminuição do preço dos chips levou ao aparecimento de sensores equipados com câmaras capazes da captação de imagem, contribuindo assim para aumentar as funcionalidades e a procura deste tipo de redes. Esta nova geração de redes de sensores é denominada Redes de Sensores Sem Fios Multimédia [2].
Os protocolos de comunicação para Redes de Sensores Sem Fios têm de ser concebidos com especial atenção às limitações deste tipo de redes, entre elas a escassez de memória e energia e a fraca capacidade de processamento. Os protocolos para Redes de Sensores Sem Fios Multimédia além de serem sensíveis às limitações das Redes de Sensores Sem Fios tradicionais têm de lidar com uma quantidade consideravelmente mais elevada de tráfego.
Com este trabalho pretende-se estudar e desenvolver soluções que permitam o transporte de tráfego multimédia em redes de sensores, minimizando o atraso de transmissão e maximizando o seu débito e o tempo de vida da rede (poupando a energia das pilhas que alimentam os dispositivos).
1.2 Objectivos
O objectivo deste trabalho é o desenvolvimento de mecanismos que suportem o transporte de multimédia em redes sem fios de sensores. Este objectivo geral pode decompor-se nos seguintes objectivos particulares:
• Desenvolvimento de um Serviço de Fiabilidade Diferenciada para o DTSN [3]
(Distributed Transport for Sensor Networks). Esse serviço vai ser responsável por atribuir a
parcelas de uma stream de multimédia – os blocos multimédia – diferentes níveis de fiabilidade. Quanto maiores esses níveis, maiores as garantias de entrega dos pacotes dos respectivos blocos ao destinatário. Com este mecanismo, pretende-se libertar a rede de retransmissões de tráfego não crítico, ou seja, pacotes que não são fundamentais para a percepção do elemento multimédia transmitido, não serão retransmitidos em caso de perda.
•
Incremento do Serviço de Fiabilidade Diferenciada do DTSN através do complemento com recuperação de pacotes baseada em códigos correctores de erros. Dessa forma será possível reconstruir pacotes perdidos na rede sem necessidade de os retransmitir. Assim será possível oferecer ao tráfego crítico níveis de fiabilidade de transporte inferiores, sendo que as perdas podem ser compensadas pelo mecanismo de recuperação de pacotes.1.3 Estrutura da dissertação
O remanescente desta dissertação encontra-se estruturado da forma descrita em seguida:
No segundo capítulo é feita uma descrição do estado de arte, focando as tecnologias envolvidas neste projecto, protocolos existentes para redes de sensores, equipamentos, sistema operativo e uma introdução ao DTSN.
O capítulo 3 faz a descrição do trabalho efectuado no desenvolvimento do Serviço de Fiabilidade Diferenciada do DTSN. Além da descrição pormenorizada do protocolo é explicado de que forma o serviço foi projectado e estruturado.
No quarto capítulo serão apresentados os resultados dos vários testes efectuados ao sistema.
Finalmente, no capítulo 5 irão ser feitos comentários ao trabalho com incidência nos resultados obtidos. Serão ainda sugeridas ideias para projectos futuros.
2. Estado da Arte das Redes de Sensores Sem Fios
As Redes de Sensores Sem Fios são sistemas que se auto-organizam constituídos por pequenos dispositivos (motes) de baixo custo, equipados com diferentes tipos de sensores consoante as exigências da aplicação. Através da sua capacidade sensorial, computacional e de comunicação sem fios, estes dispositivos podem ser espalhados por diversos locais estratégicos (e.g., locais de difícil acesso), adquirindo informação do meio. A informação captada pelos sensores é posteriormente enviada para uma, ou várias estações base (nós com maior capacidade de processamento e memória), onde a informação é processada e guardada. As estações base são muitas vezes elos de ligação entre várias redes de sensores. Essas ligações são possíveis devido à integração dessas redes com as tecnologias de redes móveis (ex: WLANs, 3G, etc.), ou mesmo com a rede IP. Esta última faz com que seja possível o controlo e monitorização da rede em qualquer parte do mundo.
A limitada potência de transmissão de grande parte dos nós, faz com que a transmissão da informação recolhida nos sensores para as estações bases, tenha de percorrer diversos saltos (multihop).
As limitações de energia fizeram com que fossem desenvolvidos mecanismos de poupança energética, que mantêm os nós activos só o tempo indispensável, de forma a garantir tempos de vida aceitáveis para estes sistemas.
Os protocolos para redes de sensores, também têm em conta as particularidades e limitações deste tipo de redes.
2.1 Características das Redes de Sensores Sem Fios
As Redes de Sensores Sem Fios têm distintas características :
• Topologia: Os nós são geralmente organizados numa topologia em árvore multihop
que tanto pode ser horizontal ou hierarquicamente organizada. A raiz da árvore (estação base) é a responsável pela gestão da informação e transmissão da mesma para redes vizinhas. Esta topologia pode ser dinâmica por motivos de variação do estado da ligação entre os nós.
• Padrão de tráfego: Nestas redes, a maior parte do tráfego gerado é no sentido da
estação base (vindo dos sensores), este tráfego é do tipo “muitos para um” (muitos nós para uma estação base). Contudo existe tráfego no outro sentido, geralmente mensagens de controlo ou de solicitação de informação. A comunicação dos sensores para a estação base pode ser contínua, gerada por um evento, resposta a um pedido da estação, ou então, uma comunicação híbrida deste conjunto.
• Tamanho reduzido das mensagens: As mensagens numa rede de sensores
geralmente têm um tamanho reduzido comparado com o das outras redes.
• Escassez de recursos: Os nós de sensores têm recursos muito limitados. O reduzido
ritmo de transmissão, a pouca capacidade de armazenamento, a dimensão reduzida de memória e uma bateria limitada, em grande parte das situações, não recarregável, são alguns dos exemplos das limitações deste tipo de redes.
As limitações energéticas constituem uma das principais preocupações para os projectistas na área de redes de sensores, e, em particular, nas transmissões de tráfego multimédia.
Algumas técnicas foram desenvolvidas para, aproveitando a energia exterior à rede, ser feito o carregamento das baterias dos diferentes nós. Alguns dos processos para produção de energia eléctrica são:
A utilização de células foto – voltaicas: ligadas a condensadores aproveitando a energia solar para o carregamento das baterias.
Os campos magnéticos: produzidos por magnetos ou bobines aproveitando vibrações que surjam na envolvente da rede.
Micro – geradores: compostos por condensadores com placas movíveis. Contudo, a energia produzida por estas técnicas de geração de energia eléctrica fica várias ordens de grandeza abaixo do que uma rede de sensores multimédia necessita, logo, só são realmente úteis para redes com pouco tráfego e processamento.
• Qualidade de Serviço: As Redes de Sensores Sem Fios são usadas em diversos
cenários e possuem um número variado de aplicações. Essas aplicações podem logicamente requerer diferentes níveis de qualidade de serviço para a transmissão de dados.
2.2 Hardware
Embora existam diversos fabricantes de dispositivos para redes de sensores, a Crossbow oferece especial destaque pela popularidade das suas soluções, muito devida ao facto de que os seus dispositivos serem compatíveis com o sistema operativo TinyOS [4] desenvolvido na UC Berkeley. Um dos dispositivos fornecidos por este fabricante é o mote MICAz [5] (fig. 4).
Este dispositivo contém um módulo RF compatível com a norma IEEE 802.15.4, e opera numa gama de frequências entre os 2.4 e os 2.4835 GHz. O ritmo de transmissão é de 250kbps. Possui um processador integrado (ATmega 128), 128 KB de memória para código, 4KB de memória RAM e 512 KB de memória Flash ROM para armazenamento de dados. Possui uma interface de 51 pinos compatível com uma variedade de sensores fabricados pela Crossbow.
Outra solução em motes para redes de sensores, é o mote TelosB [6], também da Crossbow. Este mote também é compatível com a norma IEEE 802.15.4, suportando um ritmo de transmissão até 250kbps. Possui um processador TI MSP430, 10kB de RAM e opcionalmente pode vir equipado com sensores de temperatura, pressão e humidade.
Figura 2.2: Mote TelosB da Crossbow Figura 2.1: Mote MICAz da Crossbow
Para fazer a ligação entre os motes e o computador, é usada uma placa com interface USB, MIB520CA [7], a qual vai permitir que seja monitorizada, recebida ou enviada informação para a rede a partir de um PC.
Figura 2.3 MIB520CA da Crossbow
2.3 Sistemas Operativos
As características e limitações das Redes de Sensores Sem Fios exigem que sejam concebidos sistemas operativos específicos, capazes de garantir de forma eficiente a rentabilização dos poucos recursos disponíveis. A gestão de memória e energia passa não só pela elaboração de programas eficientes, cuja dimensão e capacidade de processamento não sejam muito exigentes, como também, aproveitando o facto destes sistemas serem geralmente constituídos por uma quantidade elevada de nós, pela implementação de mecanismos de processamento distribuídos.
Existem algumas soluções para sistemas operativos em Redes de Sensores Sem Fios entre as quais destacamos o SensorWare [8], o Eyes [9], e o TinyOS [4].
2.3.1 SensorWare
O sistema operativo Sensorware é baseado em Linux e foi desenvolvido na Universidade da Califórnia, Los Angeles.
Uma das principais características deste sistema operativo é o uso de scripts que são executados parcialmente num nó específico da rede e enviados para outro onde continuam a sua execução. Outra característica é a execução de algoritmos distribuídos pelos diversos nós da rede através da disseminação de scripts. Cada nó pode conter diversos scripts que comunicam entre eles através de interfaces, cooperando para a realização das várias tarefas.
2.3.2 Eyes – Energy Efficient Sensor Networks
O projecto Eyes foi desenvolvido na Universidade de Twent na Holanda. Este sistema tem o objectivo de poupar a limitada energia da rede, ao mesmo tempo que propõe mecanismos para computação distribuída. A primeira tentativa de implementação deste S.O. foi o projecto PEROS[10] (Preemptive Eyes Real Time Operating System). As suas principais características são:
• O escalonamento preemptivo de tarefas.
• Um sistema de mensagens que permite a comunicação entre os componentes do sistema operativo e entre os nós de sensores.
• Um gerente de módulos que permite o armazenamento de módulos não utilizados numa EEPROM, carregando-os em RAM assim que forem necessários.
• Uma linha de comandos que serve de interface entre um nó sensor (ligado através da porta série ao computador) e o utilizador.
2.3.3 TinyOS
O sistema operativo TinyOS é um sistema open source concebido para Redes de Sensores Sem Fios, desenvolvido na Universidade de Berkeley, Califórnia. Este sistema foi desenvolvido na linguagem nesC, uma extensão da conhecida linguagem C, e tem uma arquitectura modular, em que diferentes módulos são ligados através das interfaces que fornecem ou usam de outros módulos. Esta arquitectura faz com que os códigos sejam relativamente curtos e eficientes. Devido à inexistência de threads neste sistema operativo, as operações de
Input-Output são geridas através de eventos. Quando existe uma chamada exterior ou mesmo uma
resposta a um pedido efectuado anteriormente, é disparado um evento, sendo este atendido por um handler pré-programado. Algoritmos que exijam elevado processamento são englobados em tasks. O processamento das tasks é agendado pelo sistema operativo de forma a não sobrecarregar o processador. A alocação dinâmica de memória é desaconselhada (devido à limitação de memória dos motes) pelo que, a memória é reservada à priori através da constituição de pools. As pools são espaços em memória para um número máximo definido de um determinado tipo de dados nesC. Consoante a memória para o tipo de dados é necessária, vai sendo tirada da pool. Quando deixa de ser necessária, volta a ser posta na pool para que possa ser reutilizada.
2.4 Simuladores
O projecto de software (e.g., protocolos) para redes de sensores não seria possível sem o auxílio de ferramentas de simulação específicas. Em ambiente de simulação é possível criarem-se redes com um número de nós variável e simular com precisão o desempenho dos sistemas.
De seguida são apresentados dois simuladores para Redes de Sensores Sem Fios, o Tossim [11] e o Avrora [12].
2.4.1 TOSSIM
Um dos simuladores de redes de sensores mais utilizados é o TOSSIM.
Das várias características que possui, algumas tornam o TOSSIM uma ferramenta prática e fundamental no teste e simulação do projecto:
• De simples utilização, este simulador é controlado por um script elaborado pelo utilizador, na linguagem Python.
• Permite simular várias topologias de rede.
• Permite a configuração de um padrão de ruído, que aproxima as condições de simulação às reais.
• Podem ser introduzidas no código dos módulos a simular, mensagens de debug para controlo do funcionamento de cada módulo.
• A sua funcionalidade, “packet injection” permite enviar pacotes para qualquer nó da rede, sendo que este os recebe pela interface de rádio, como se tivessem sido enviados por um nó vizinho.
• As variáveis dos programas que correm nos nós que estão a ser simulados podem ser monitorizadas, o que é bastante útil para o controlo do estado da simulação.
Estas especificações fizeram do TOSSIM o simulador escolhido para o teste das extensões ao DTSN apresentadas no capítulo 3.
2.4.2 Avrora
Outro conhecido simulador para redes de sensores é o Avrora. Feito em Java, este simulador tem como principal vantagem em relação aos outros a forma eficiente como mantém a sincronização dos nós. Uma grande vantagem em relação ao TOSSIM é que este simulador corre linguagem máquina, podendo simular qualquer programa para redes de sensores. Já o TOSSIM só pode simular programas para TinyOS.
O Avrora divide os nós da simulação por threads diferentes e utiliza mecanismos de sincronização para gestão de informação de sensores e troca de mensagens entre nós eficientes, rentabilizando a utilização do processador, o que faz deste simulador uma solução de alto rendimento e escalabilidade.
O funcionamento do simulador baseia-se numa fila de eventos, sendo que cada nó pode estar num modo de execução ou num modo suspenso. A cada evento da fila corresponde um temporizador de execução. Caso o nó esteja em modo de execução, o tempo que demorou a ultima instrução a ser executada vai ser subtraído ao temporizador de execução do primeiro evento da fila. Caso o nó esteja em modo suspenso (sleep mode), a cada ciclo de relógio é
decrementado o temporizador de execução do primeiro evento da fila até este disparar e acordar o nó. Após o evento ser tratado, o primeiro elemento da fila é actualizado.
2.5 Tecnologia de transmissão para Redes de Sensores Sem Fios
A maioria das Redes de Sensores Sem Fios segue a norma do IEEE, 802.15.4 [13]. Esta norma oferece soluções para camadas físicas e de acesso ao meio a sistemas que têm pouca potência de transmissão e ritmos de transmissão relativamente baixos. A norma garante um ritmo máximo de transmissão de 250kbps entre estações distanciadas de 10 metros. A camada física garante o controlo do rádio, fazendo a selecção de canais e da potência de transmissão. Na Europa, as bandas de frequências suportadas são 868-868.8 MHz e 2.40-2.48 GHz.
È ainda prevista uma organização de rede específica. As redes são constituídas por dois tipos de nós - os FFD (Full Function devices) e os RFD (Reduced Function Devices). Os FFD são nós com capacidade superior que podem funcionar como coordenadores de rede. Estes nós podem estar ligados a vários FFDs e RFDs. Os RFDs são mais limitados, só podendo estar ligadas a um FFD. Cada nó de rede tem o seu identificador próprio, de 64 bits.
As duas topologias de rede possíveis são as peer-to-peer e as redes em estrela. As primeiras são formadas por vários FFDs ligados entre si podendo cada um deles estar ligado a um ou mais RFDs.
A topologia em estrela é formada por um FFD central (e coordenador) ligado a vários nós.
O acesso ao meio é efectuado através do protocolo CSMA / CA. Quando têm informação para enviar para a rede, os nós esperam um determinado tempo seguido de um tempo de backoff que pode crescer exponencialmente. O tempo pode estar ou não dividido em
slots, sendo limitados por beacons enviados pelo nó coordenador. Existem normas bem
definidas de comunicação entre o coordenador e os restantes nós da rede.
2.6 Encaminhamento em Redes de Sensores Sem Fios
As Redes de Sensores Sem Fios possuem algumas particularidades que têm de ser levadas em conta nos protocolos de encaminhamento [14]:
• Alcance limitado - A reduzida potência de transmissão dos nós faz com que uma
mensagem tenha muitas vezes de ser transmitida através de muitos hops, passando por muitos nós intermédios, até chegar ao destino final. Esse motivo, aliado a prováveis quebras de energia que façam algumas ligações desaparecer e modifiquem constantemente as rotas da rede, levam alguns protocolos a evitar fazer a disseminação de mensagens de actualização de informação de encaminhamento.
• Auto-organização - Cada nó tem de ser capaz de, quando se junta a uma rede,
descobrir os seus vizinhos e encaminhar pacotes para estes.
• Limitações de energia - A fraca fonte de energia de que são dotados os nós da rede,
levam os protocolos para Redes de Sensores Sem Fios a serem projectados com especial cuidado com o volume de mensagens trocadas.
Em seguida é feita a descrição de alguns protocolos de encaminhamento utilizados em RSSF.
2.6.1 SPIN
A família de protocolos SPIN é especialmente desenvolvida para redes de sensores. A sua principal característica é a negociação de informação a transmitir na rede. Cada nó, ao receber informação nova, manda uma mensagem ADV (Advertise) aos nós vizinhos. Essa mensagem contém informação sobre os novos dados que chegaram ao nó provenientes dos seus sensores ou recebidos de outros nós da rede. Se aos nós vizinhos interessar essa informação, estes mandam uma mensagem de REQ (Request). O nó que conte os dados vai então mandá-los numa mensagem de DATA. Este processo vai repetir-se por toda a rede. A grande vantagem deste protocolo é que, devido à troca de informação sobre os dados que cada sensor possui, só vai fluir na rede informação útil e necessária, não sendo a rede congestionada desnecessariamente. Cada nó possui também acesso ao estado em que se encontram os seus recursos (ex: energia).
Dois dos protocolos mais conhecidos desta família são o SPIN-1 e o SPIN-2. O SPIN-1 comporta-se tal como foi comentado em cima. Já o SPIN-2 usa a informação relativa aos recursos para controlar o funcionamento de cada nó. Se um nó de sensores atingir um estado crítico de energia, só informa os outros de dados novos caso tenha a certeza que os consiga enviar com sucesso.
Uma desvantagem deste protocolo é o facto de, devido ao uso de mensagens de ADV, a informação de um nó não ser garantidamente entregue a toda a rede. Isto porque os pedidos de REQ só são efectuados se a informação for útil à aplicação que corre nos nós. Logo se, por exemplo, a um nó num extremo da rede for útil a informação de um sensor de humidade de outro nó localizado no outro extremo, mas no meio estiverem nós aos quais essa informação não é útil, é possível que o nó que pretendia essa informação nunca a venha a receber.
2.6.2 Directed Diffusion
O protocolo Directed Diffusion, tal como o SPIN, é um protocolo especialmente desenvolvido para RSSF. Este protocolo tem como característica principal a agregação de informação retirada de sensores com as mesmas características, para assim diminuir o tráfego da rede. Outra característica interessante é a maneira como se troca a informação. Um nó que necessita de determinado tipo de informação da rede, propaga uma mensagem de interesse para a rede. Sempre que os nós da rede obtenham informação que satisfaça os níveis de interesse de um nó, essa informação é agregada, como explicado anteriormente, e enviada para o nó que manifestou o interesse. Este protocolo apresenta então, outra maneira de poupar a rede de congestionamentos causados por informação pouco relevante o que, sem dúvida, é uma grande mais-valia em RSSF.
2.6.3 DSDV optimizado
Ao contrário dos protocolos descritos anteriormente, desenvolvidos especificamente para Redes de Sensores Sem Fios, o DSDV [15] é um protocolo desenhado para MANETs (Mobile
Ad-Hoc Networks). Contudo, este foi o protocolo eleito para o teste do DTSN e das suas
extensões. Essa escolha deve-se ao facto de na rede desenvolvida no projecto IST FP6 UbiSec&Sens (do qual faz parte o DTSN), os nós terem um endereço único, o que a torna neste aspecto semelhante a uma MANET. Contudo, para ser adaptado às exigências de uma rede de sensores este protocolo teve de ser optimizado.
O DSDV (original) é um protocolo de encaminhamento proactivo (faz constantemente a actualização das tabelas de encaminhamento dos nós) para redes ad-hoc. Todos os nós mantêm uma tabela de encaminhamento com entradas para todos os destinos possíveis. Para cada destino é conhecida a informação do nó seguinte (nó para o qual tem de mandar a informação para que a mensagem chegue a esse destino), a distância (em hops) e um número de sequência gerado pelo nó destino. Esse último campo serve para evitar propagações de mensagens de encaminhamento cíclicas inválidas provocadas por falhas de nós da rede. Embora sejam trocadas periodicamente mensagens de actualização das tabelas de encaminhamento, essa informação também é actualizada de imediato sempre que haja alterações na topologia da rede. As mensagens com informação de encaminhamento para um
destino só são actualizadas quando possuem maior número de sequência do que o guardado na tabela.
Para servir de base ao protocolo DTSN (vide 2.7.2.4), o protocolo DSDV foi optimizado. Na nova versão do DSDV, a estação base pode ligar ou desligar o envio de mensagens de actualização de encaminhamento, o que torna o protocolo mais escalável. Devido ao facto de o DTSN necessitar de caminhos inversos, é o próprio protocolo de transporte a manipular as tabelas de encaminhamento do DSDV. As rotas inversas vão ser criadas com base nos pacotes de dados que vão dos sensores para a estação base, sendo este o único nó que envia actualizações de encaminhamento.
2.7 Protocolos de transporte para Redes de Sensores Sem Fios
As particularidades das RSSF (vide 2.1) influenciam o projecto de protocolos de transporte para este tipo de redes. De seguida são apresentadas as características desses protocolos. Ainda nesta secção serão apresentados alguns protocolos e as suas especificidades.
2.7.1 Características dos protocolos de transporte para Redes de Sensores Sem
Fios
Os protocolos de transporte [16] são usados para a redução do congestionamento da rede e para reduzir as perdas de pacotes. Contudo os tradicionais protocolos de transporte, UDP e TCP, não servem as necessidades das Redes de Sensores Sem Fios. Como se sabe, o UDP não garante a entrega fiável de pacotes necessária para o funcionamento deste tipo de redes. Já o TCP tem muitos outros contras:
• A necessidade de uma troca de pacotes no início da ligação para estabelecimento da sessão pode não se justificar na maior parte das aplicações, especialmente nas baseadas em comunicação por eventos.
• O baixo débito devido aos conhecidos mecanismos de controlo de congestão.
• Em contraste com um controlo local, o controlo de congestão no TCP é feito
end-to-end, logo, são detectadas mais tardiamente as congestões.
• As retransmissões em TCP também são end-to-end, causando um maior gasto de energia, incomportável neste tipo de redes.
• O TCP garante uma transmissão fiável de pacotes o que nem sempre é necessário neste tipo de redes.
.
Seguidamente são descritas as características mais importantes que qualquer protocolo de transporte para RSSF deve englobar: a eficiência energética, as garantias de fiabilidade, o controlo de congestão e a qualidade de serviço.
2.7.1.1 Eficiência energética
Os nós de sensores têm energia limitada. Como resultado, é importante para os protocolos da
camada de transporte manterem níveis altos de eficiência energética para maximizarem o seu tempo de vida. Para aplicações que requerem muita fiabilidade, as perdas de pacotes levam a retransmissões e ao inevitável consumo adicional de energia. Para fazer face a essas perdas, alguns factores necessitam de ser levados em conta, como o número de retransmissões de pacote, a distância (número de nós) percorridos por cada pacote retransmitido, e o tráfego adicional associado às mensagens de controlo.
2.7.1.2 Garantias de fiabilidade
Em Redes de Sensores Sem Fios as exigências de fiabilidade podem ser distintas, consoante o tipo de aplicação. Algumas aplicações exigem a entrega de todos os pacotes. Já outras, só necessitam de receber notificações de eventos.
A congestão e os erros de bit podem causar perda de pacotes, o que faz diminuir a fiabilidade e a qualidade de serviço da ligação para além do desperdício de energia.
Outros factores que podem afectar a fiabilidade são as falhas de um nó, erros nas tabelas de expedição e falhas de energia.
Para garantir a fiabilidade é então necessário detectarem-se as perdas de pacotes e proceder à sua rápida recuperação.
Um dos métodos mais usados para identificação de perdas é o uso de números de sequência nos pacotes e verificação da continuidade dos mesmos. O método de detecção
end-to-end, usado no TCP, é preterido nas redes de sensores por várias razões, entre elas, os
gastos elevados de energia nas retransmissões de um extremo para o outro da rede (origem – destino). Assim, nas Redes de Sensores Sem Fios é preferencialmente utilizado um método de detecção de perdas ponto a ponto (ou local) em que os nós intermédios a uma comunicação intervêm na detecção de perdas. Esse método só é possível em redes em que os nós intermédios possuam uma cache para armazenar alguns dos pacotes que são enviados da origem para o destinatário.
De forma a serem detectadas as perdas, existem dois tipos de mecanismos que podem ser implementados:
• Do lado do emissor, pode ser activado um temporizador quando este envia um pacote. Uma retransmissão é efectuada caso a mensagem de confirmação de recepção desse pacote não seja recebida até ao expirar do temporizador
• Do lado do receptor, a falha é detectada quando existe uma descontinuidade no número de sequência dos pacotes recebidos.
Depois de detectada a falha, é necessário notificar o emissor da perda do pacote. As notificações de perdas são efectuadas mandando um pacote NACK à origem da mensagem. Esse pacote contudo, vai percorrer vários nós intermédios até chegar à origem.
Se estiver a ser utilizado o método de detecção ponto a ponto, o nó intermédio, ao receber o pacote NACK, procura em cache o pacote em falta. Se o tiver retransmite-o para o destino. Caso contrário transmite a mensagem de pacote perdido ao nó vizinho, e assim sucessivamente até algum nó ter o pacote em cache ou até à mensagem NACK chegar ao nó emissor. Ao contrário do método end-to-end em que os pacotes são retransmitidos da origem, este método de recuperação faz com que as distâncias percorridas pelos pacotes retransmitidos sejam mais curtas, sendo os pacotes enviados por nós intermédios. Contudo, este método implica que os nós intermédios vão guardando os pacotes transmitidos em cache, não havendo garantias de retransmissão se um dos nós falhar.
O tempo que um nó tem de guardar um pacote em cache, também depende do método a utilizar. Enquanto no método end-to-end esse tempo deve ser igual ou maior que RTT-
Round Trip Time (Tempo de ida e volta), no método ponto a ponto esse tempo é igual ao
tempo de transmissão (ida-e-volta) entre nós intermédios, logo muito menor.
A retransmissão de pacotes em Redes de Sensores Sem Fios é, sem dúvida, um tema pertinente. Uma retransmissão rápida (ARQ - Automatic Repeat Request), logo aquando da detecção da perda de um pacote é aconselhável, porque diminui os atrasos temporais. Porém, quando os pacotes são perdidos por congestão da rede, a retransmissão rápida pode não ser uma boa solução uma vez que pode agravar a congestão resultando na perda de mais pacotes.
Outra problemática interessante é o armazenamento de pacotes nas caches. Devido à fraca capacidade de memória dos nós, esse armazenamento de pacotes tem de ser cuidadosamente pensado, e baseado em cálculos probabilísticos, visto que os nós poderão não ter capacidade de armazenamento para todos os pacotes. Os nós escolhidos para armazenar informação devem ser os periféricos às zonas mais prováveis de congestionamento.
Contudo, recuperação de pacotes pode não implicar obrigatoriamente retransmissão. As técnicas de recuperação de informação perdida baseadas em FEC (Forward Error
Correction) permitem a partir de pacotes de dados codificados, enviados pela fonte juntamente
com os pacotes de paridade, recuperar pacotes perdidos sem que tenham de ser pedidas retransmissões. A essa técnica dá-se o nome de erasure coding [17].
Um erasure code transforma um bloco de n pacotes num bloco com mais de n pacotes. A fracção de pacotes necessária à recuperação da totalidade da mensagem é r (rate). Nos
erasure codes optimizados, o tamanho do bloco final é
r
n
.
Existem várias codificações possíveis para erasure coding, entre elas a Reed Solomon. Este mecanismo torna-se assim muito útil na recuperação de pacotes, uma vez que ao contrário dos baseados em ARQ, muitas vezes poupa a rede de tráfego adicional devido a retransmissões.
Há, no entanto, soluções para recuperação de pacotes que complementam o mecanismo de ARQ com FEC.
2.7.1.3 Controlo de congestão
A congestão é um aspecto importantíssimo a levar em conta no projecto de um protocolo de transporte. Numa rede de sensores, uma congestão aparece quando o número de pacotes que chegam a um certo nó é maior que o número de nós que este consegue enviar, num certo intervalo de tempo. Esse tipo de congestão é mais provável de acontecer nos nós perto da estação base, porque é nestes que se junta o tráfego proveniente dos vários caminhos para os nós da periferia. Outro tipo de congestão é causado ao nível da camada de rede, devido a interferência, tempos de contenda e erros de bit.
A congestão tem uma implicação directa na eficiência energética e na qualidade de serviço. O facto de o meio estar congestionado causa logicamente aumento do atraso na entrega dos pacotes, e, no caso das filas de espera ficarem cheias e os pacotes remanescentes forem descartados, causa retransmissões e as respectivas perdas de energia.
Por todas estas razões, a congestão em RSSF tem de ser controlada. Os três principais mecanismos de controlo de congestão são: detecção de congestão, notificação de congestão e ajuste de ritmo de transmissão.
• Detecção de Congestão - Nas redes de sensores é comum optar-se por controlo do
tamanho das filas de espera. Para redes de sensores que usam mecanismos como o CSMA para acesso ao meio, a ocupação do canal pode ser medida como indicação de congestão.
• Notificação de Congestão - Depois de ser detectada, a congestão tem de ser
enviadas restrições ao ritmo de transmissão dos nós que estão a congestionar a rede. Essa notificação pode ser explícita ou implícita. Na notificação explícita são enviadas mensagens de controlo específicas aos nós envolvidos. Na notificação implícita, os nós que detectam a congestão modificam um bit específico num pacote normal de dados para assim informarem a estação base e os outros nós da congestão.
• Ajustamento no ritmo de transmissão - Quando recebem a informação de congestão
de rede, os nós de sensores podem ajustar os ritmos a que enviam os pacotes. Se mais informação for fornecida ao nó sobre o estado de congestão da rede, este pode ajustar de forma mais correcta esse ritmo.
2.7.1.4 Qualidade de Serviço
Embora venha destacado dos outros factores, a qualidade de serviço depende muito da maneira como são geridos os mecanismos de garantia de fiabilidade e de controlo de congestão. Numa Rede de Sensores sem Fios, o tráfego adicional causado por retransmissões de pacotes perdidos, e os picos de congestão da rede, podem fazer cair drasticamente os níveis de qualidade de serviço. É necessário portanto um controlo bastante exaustivo do tráfego que percorre a rede e minimizar ao mínimo as retransmissões. A solução apresentada no capítulo 3 vem de certa forma, resolver os problemas descritos.
As métricas de qualidade de serviço incluem largura de banda, latência, atraso e rácios de perda de pacotes. Dependendo da aplicação, essas métricas ou as suas variantes podem ser usadas para Redes de Sensores Sem Fios.
2.7.2 Protocolos existentes para Redes de Sensores Sem Fios
De modo a projectar um protocolo de transporte eficiente, muitos factores têm de ser levados em conta, incluindo a topologia, diversidade de aplicações, características do tráfego e limitações de recursos.
Uma das mais importantes limitações que têm de ser enfrentadas neste tipo de redes é a limitação de energia. A qualidade de serviço pode ou não ser uma exigência da aplicação pelo que também deve ser levada em conta, nas suas várias vertentes: débito, fiabilidade e os atrasos.
Para fazer face a esses factores, os protocolos têm de ter componentes que tratem do controlo de congestão e da recuperação de pacotes perdidos, vistos estas duas fases estarem directamente ligadas à gestão de energia e à qualidade de serviço da rede. Muitos dos protocolos já existentes tratam estas duas fases separadamente, sendo implementados algoritmos e protocolos para cada uma delas. O CODA [18] (Congestion Detection and
Quickly) é um protocolo que assegura transporte fiável. O uso destes dois protocolos juntos
pode fornecer todas as funcionalidades requeridas pelos protocolos de transporte das Redes de Sensores Sem Fios.
Uma segunda alternativa é assegurar o controlo de congestão e recuperação de pacotes num único e completo protocolo. É o caso do STCP [20] (Sensor Transmission Control
Protocol). Para diferentes aplicações, este protocolo fornece diferentes políticas de controlo
para garantir as especificações da aplicação e ao mesmo tempo optimizar a eficiência energética. Esta alternativa pode ser mais eficiente uma vez que o controlo de congestão e a recuperação de pacotes estão directamente relacionados.
Um compromisso entre as duas alternativas (modular e integrada) é uma solução a explorar.
Figura 2.5 Protocolos de transporte existentes para WSNs.[16]
2.7.2.1 Protocolos para controlo de congestão
Existem vários protocolos de controlo de congestão para WSNs. Estes distribuem-se pelos seus mecanismos de detecção de congestão, notificação de congestão e ajustes do ritmo de transmissão:
• Detecção de congestão - Os protocolos Fusion [21], Siphon [22] e CODA detectam as
congestões baseando-se no tamanho das filas de espera nos nós intermédios enquanto que o CCF [23] (Control and Fairness) detecta a congestão baseando-se no tempo de serviço do pacote. O PCCP [24] (Priority Based Congestion Protocol) calcula o grau de congestão com a relação entre o atraso entre cada chegada e o tempo de serviço de pacote.
• Notificação de congestão - O CODA utiliza notificação explícita de congestão
enquanto os outros utilizam notificação implícita de congestão.
• Ajustes do ritmo de transmissão - O protocolo ARC [25] (Adaptative Rate Control)
não possui mecanismos de detecção nem notificação de congestão. O ritmo a que são enviados os pacotes baseia-se no seguinte método:
Quando um nó ouve o nó seguinte a transmitir o pacote que ele lhe tinha mandado, este aumenta o ritmo de envio proporcionalmente a uma constante α (> 1). Caso contrário, multiplica o seu ritmo por β (0 <β <1) para assim reduzir o ritmo de envio. Estas constantes α e β são diferentes consoante o tipo de tráfego e a fonte que o produz para assim se ter em conta a justiça no acesso ao meio.
No protocolo Fusion o ritmo é controlado com menos suavidade, ou seja, quando é detectada uma congestão num nó, os nós vizinhos param de lhe mandar pacotes (stop and start).
Já o CODA ajusta o seu ritmo de uma forma semelhante ao crescimento aditivo ou decrescimento multiplicativo.
O CCF e o PCCP fazem um ajuste exacto do ritmo, sendo que este último (PCCP) implementa uma política de prioridades no acesso ao meio.
O protocolo Siphon não faz ajustes no seu ritmo. Quando ocorre congestão, os nós redireccionam os pacotes para bases virtuais (Virtual Sinks), que são nós com rádios com maior alcance, capazes de enviar as mensagens para nós mais distantes, tentando desviar estes pacotes dos caminhos congestionados.
O protocolo Trickle [26] baseia-se na transmissão de um resumo de informação contida pelo nó a todos os outros nós da rede. Se o nó recebe um certo nível de informação dos vizinhos igual à que tem disponível, pode parar de mandar o resumo de informação. Por outro lado, assim que o nó recebe novo código, este deve comunicar de imediato a todos os nós. Desta forma, este protocolo pode controlar melhor o tráfego ao longo da sua rede.
2.7.2.2 Protocolos para fiabilidade
Alguns protocolos focam-se em garantir a fiabilidade do tráfego no sentido da base (upstream) enquanto outros garantem a fiabilidade do tráfego no sentido dos nós (downstream).
O protocolo ESRT [27] (Energy Saving Token Ring Protocol) só garante a fiabilidade de eventos através de ajustes de ritmo na origem e no destino da mensagem. Se na estação base a fiabilidade atingir um nível desejado, é reduzido o ritmo de emissão na fonte, caso contrário este é aumentado.
Já os protocolos RMST [28] (Reliable Multi-Segment Transport) e RBC [29] (Reliable
Bursty Convergecast) garantem a fiabilidade dos pacotes em todos os nós intermédios.
Enquanto que o protocolo RMST usa mensagens NACK selectivas (com uso de janelas na emissão e recepção), o RBC é um protocolo do tipo Stop-and-go em que o emissor bloqueia até receber um ACK. O protocolo RBC usa ainda um mecanismo de escalonamento de envio de pacotes entre nós para assim se evitar congestionamento na rede.
Para redes cujo tráfego é preferencialmente direccionado da estação base para os nós (Downstream) são apresentados dois protocolos, o GARUDA [30] e o PSFQ, ambos baseados em notificação de perdas através de NACKS e recuperação local de pacotes.
O protocolo GARUDA consiste em duas camadas, uma para os nós de núcleo, que são nós que distam múltiplos de 3 nós da base, e outra para os outros nós. A primeira fase do protocolo é assegurar que os nós de núcleo recebam correctamente os pacotes. Na segunda fase, os outros nós recuperam a informação que não conseguiram receber, dos nós de núcleo. O protocolo PSFQ baseia-se em três operações: pump, fetch e report. Na operação
pump, a base manda periodicamente e a um ritmo lento os pacotes para os nós. Quando um
nó que recebe detecta uma falha no número de sequência dos pacotes, envia um NACK no sentido oposto de forma a recuperar o pacote em falta. O nó que recebe esse NACK não o reenvia, excepto se o número de NACKS que está a receber passar um determinado nível ou se o pacote a que se refere o NACK não estiver disponível nesse nó. Se o pacote a que o NACK diz respeito estiver disponível no nó, este envia-o para o nó que o pediu. Periodicamente, a fonte informa todos os nós da informação que transmitiu através da operação report.
2.7.2.3 Protocolos que abrangem controlo de congestão e fiabilidade
O protocolo STCP proporciona ao mesmo tempo controlo de congestão e fiabilidade no envio de pacotes. Para controlar a congestão, os nós vão informando a base do estado das suas filas de espera, nos cabeçalhos das mensagens. Esta tem portanto a responsabilidade de adaptar o ritmo de transmissão à informação que recebe dos nós da rede. Quanto à fiabilidade, este protocolo tem a capacidade de se adaptar ao tipo de exigências das aplicações.
2.7.2.4 DTSN
O DTSN é um protocolo de transporte para redes de sensores elaborado no INOV e financiado pelo projecto IST FP6 UbiSec&Sens. Embora seja um protocolo que não faz controlo de congestão, garantindo unicamente a fiabilidade na entrega dos pacotes, decidiu-se separá-lo dos outros mencionados acima, para ser explicado mais pormenorizadamente, uma vez que serviu de base ao trabalho desenvolvido.
Até ao momento, o DTSN oferecia somente um serviço básico de fiabilidade total que garante a entrega fiável de todos os pacotes.
Este protocolo tem como objectivo promover uma comunicação fiável nas RSSF, levando em consideração as várias particularidades e limitações deste tipo de redes, já discutidas anteriormente (largura de banda e energia limitadas, pouca capacidade de processamento, etc…). A garantia de escalabilidade e robustez são outros dos objectivos do DTSN. O controlo de congestão ainda não faz parte das características deste protocolo. Contudo, o Serviço de Fiabilidade Diferenciada (desenvolvido na secção 3) pode, como será discutido posteriormente, em alguns casos, evitar congestionamentos na rede.
O protocolo assume que a camada MAC oferece uma ligação fiável e que a camada de rede suporta caminhos inversos (pacotes de uma dada comunicação entre dois nós percorrem os mesmos nós em ambos os sentidos).
A rede de sensores do projecto UbiSec&Sens é id-centric (existe um endereço único global para cada nó), o que a torna em termos de encaminhamento semelhante às redes móveis ad-hoc. Portanto, o protocolo de encaminhamento escolhido foi o DSDV que, embora não seja um protocolo específico para RSSF, vai de encontro às exigências da rede em questão, permitindo o teste eficaz do DTSN e das suas extensões. Ainda assim, esse protocolo foi optimizado de modo a poder ser desligado o envio de actualizações de mensagens de encaminhamento, o que o torna mais escalável e o aproxima de um protocolo específico de Redes de Sensores Sem Fios.
Quando um nó quer iniciar o envio de pacotes para um determinado nó destino, é criada uma sessão DTSN nova no nó origem. O identificador de cada sessão é constituído pelo endereço origem, endereço destino, identificação da aplicação e número de sessão. O número de sessões simultâneas que cada nó suporta é limitado e configurado antes da sua instalação nos motes. As sessões DTSN são iniciadas quando é enviado o primeiro pacote para um determinado destino e são terminadas quando expira um temporizador de actividade de sessão.
O nó origem vai mandando os pacotes consecutivamente até ser atingido o limite da janela de Acknowledgment. O tamanho dessa janela é adaptado às circunstâncias e ao cenário envolvente à rede. Quando esse limite é atingido é enviado ao destinatário um pacote de EAR (Explicit Acknowledgment Request) a que este responde com um ACK ou um NACK. Caso a resposta seja um ACK o emissor apaga do buffer de emissão os pacotes confirmados. Caso contrário, no pacote de NACK vêm descriminados os pacotes em falta que são prontamente reenviados pelo emissor. Sempre que é enviado um EAR é lançado um temporizador de EAR. Quando este temporizador expira é reenviado o pacote de EAR até a um número máximo de tentativas. Se esse número for atingido é terminada a sessão avisando a aplicação de que houve pacotes que não foram confirmados.
A figura abaixo representa um fluxograma do funcionamento do protocolo do lado do emissor.
Figura 2.6: Fluxograma do funcionamento do DTSN – emissor [3]
Opcionalmente pode ser aproveitada a cache dos nós intermédios, para, em caso de falhas de comunicação, um nó intermédio que receba um NACK, se tiver o(s) pacote(s) em falta, poder enviá-lo(s) ao destinatário, filtrando o NACK e substituindo-o por um ACK, que vai percorrer o restante caminho de volta ao emissor. Os pacotes são guardados com uma probabilidade p pré-definida nos nós intermédios, numa fila FIFO, logo, caso não haja mais capacidade para guardar um pacote, o pacote mais antigo dá o seu lugar a um novo pacote na
cache. Pacotes em cache com o número de sessão anterior ao do recebido também são
substituídos. Este mecanismo evita retransmissões end-to-end e faz com que o protocolo se torne energeticamente eficiente. Contudo, e devido às restrições de memória nos nós, o número de pacotes mantido em cache é limitado. Para serem minimizadas as retransmissões
end-to-end têm então de ser no futuro elaborados algoritmos distribuídos de gestão das caches
dos diferentes nós, para que haja maior aproveitamento deste recurso.
Na figura abaixo representa-se através de um fluxograma o funcionamento do protocolo nos nós intermédios
Figura 2.7: Fluxograma do funcionamento do DTSN - nós intermédios [3]
Do lado do nó destino da mensagem, o funcionamento do DTSN é o seguinte:
Aquando da recepção de um pacote, é verificado no cabeçalho deste a que sessão DTSN pertence. Se a sessão não existir, é criada uma nova. Se já existir um registo de sessão que coincida com o identificador, mas se o número de sessão for diferente, é feito um reset à sessão, sendo as camadas superiores avisadas caso hajam pacotes que tenham sido descartados do buffer de recepção (pacotes não sinalizados à camada superior).
Depois de ser verificada a sessão o receptor confirma se o número de sequência do pacote recebido é o esperado. Caso seja, a recepção do pacote é sinalizada às camadas superiores sendo incrementado em uma unidade o número de sequência do pacote recebido. Caso contrário (salto nos números de sequência), o pacote é guardado num buffer de recepção, à espera que sejam recebidos os pacotes em falta, para assim serem entregues ordenadamente à recepção.
Caso chegue uma mensagem de EAR, o protocolo verifica se o número de sequência do EAR corresponde ao número de sequência de pacote esperado. Em caso afirmativo manda um ACK ao receptor (confirmando a recepção com sucesso de todos os pacotes), caso contrário, são percorridos todos os números de sequência desde o esperado até ao do EAR e verificados os saltos que existem nos números de sequência dos pacotes guardados em buffer. Esses pacotes em falta são registados e enviados num pacote NACK à origem das mensagens.
Quando expira o temporizador de actividade da sessão, esta é apagada e as camadas superiores avisadas caso hajam pacotes no buffer de recepção.
Na Figura 2.8 é representado um fluxograma do funcionamento do protocolo do lado da recepção.
A figura 2.9 ilustra a transmissão de um bloco de seis pacotes, em que o segundo e o quarto são perdidos e depois recuperados com o mecanismo de cache dos nós intermédios. É assumido que a Acknowledgment Window é qual a 5.
Figura 2.9: Diagrama temporal do funcionamento do DTSN [3] Figura2.8: Fluxograma do funcionamento do DTSN – Receptor [3]
Embora o Serviço Básico do DTSN tenha em conta as limitações das RSSF, utilizando mecanismos para evitar retransmissões end-to-end e garantir níveis aceitáveis de qualidade de serviço para o tráfego que percorre a rede, este serviço não oferece a possibilidade de serem atribuídos níveis de fiabilidade diferentes para diferentes pacotes. Para baixos volumes de tráfego, essa limitação não é muito relevante. Contudo, quando se trata de grandes volumes de tráfego como dados multimédia é necessário haver mecanismos para diferenciar a fiabilidade de grupos de pacotes. Só assim será possível manter a rede descongestionada, garantindo níveis de QoS aceitáveis na rede. Esta é a grande motivação para o Serviço de Fiabilidade Diferenciada, apresentado na secção 3.
2.8 Redes de Sensores Sem Fios Multimédia
As Redes de Sensores Sem Fios Multimédia têm tomado ultimamente uma grande importância, uma vez que contrariamente às redes de sensores tradicionais, capazes de fazer medições de grandezas como a temperatura, pressão, humidade e de localizar objectos, esta nova geração de redes de sensores consegue captar, processar e transmitir dados multimédia, aumentando em larga escala a utilidade das primeiras infra-estruturas. Este tipo de sensores pode ser equipado por módulos de captação de imagem com câmaras CMOS, e de som, com a integração de microfones. Os reduzidos preços destes dispositivos tornam este tipo de redes uma solução viável para uma variedade de aplicações como ajuda médica pré-hospitalar ou plataformas de vigilância.
Esta secção disponibiliza informação sobre o hardware, características e aplicações das Redes de Sensores Sem Fios Multimédia. Embora alguma da informação não esteja directamente relacionada com os módulos implementados, é revelada para enquadrar o leitor nas exigências, limitações e aplicações deste tipo de rede.
2.8.1 Hardware específico para Redes de Sensores Sem Fios Multimédia
O recente desenvolvimento na área da electrónica, mais especificamente na tecnologia de sensores de imagem CMOS, fez com que fosse possível reunir no mesmo chip uma lente, um sensor de imagem e um processador, contribuindo bastante para o desenvolvimento de redes de sensores multimédia.
As câmaras CMOS são vulgarmente usadas em aparelhos (e.g., PDAs) que possuem uma capacidade de processamento mais elevada que os motes geralmente utilizados nas redes de sensores tradicionais. Para fazer face a essa limitação, foi desenvolvido o módulo Cyclops [31] . Este dispositivo é ligado directamente ao mote (e.g, MICAz), fornecendo-lhe uma interface de alto nível que o abstrai da complexidade de processamento exigida pela câmara.
