Estudo e Implementação de Protocolos de Disseminação de Dados para Redes de Sensores Sem Fio

(1)

Estudo e Implementação de Protocolos de

Disseminação de Dados para Redes de Sensores Sem

Fio

Florianópolis 2009

(2)

Estudo e Implementação de Protocolos de

Disseminação de Dados para Redes de Sensores Sem

Fio

Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do grau de Bacharel em Ciências da Computação.

Orientador:

Antônio Augusto M. Fröhlich

Co-orientador:

Giovani Gracioli

BACHARELADO EMCIÊNCIAS DA COMPUTAÇÃO DEPARTAMENTO DE INFORMÁTICA EESTATÍSTICA

CENTROTECNOLÓGICO

UNIVERSIDADEFEDERAL DE SANTA CATARINA

Florianópolis 2009

(3)

aprovado em de de , em Florianópolis, Santa Catarina, pela banca examinadora constituída por:

Banca Examinadora

Prof. Dr. Antônio Augusto Medeiros Fröhlich Orientador

M.Sc Giovani Gracioli Co-orientador

M.Sc Rafael Pereira Pires

(4)

Ana Maria Vieira Steiner Sérgio Machado Steiner

(5)

(6)

Resumo

Redes de sensores sem fio foram propostas como uma solução para coleta de dados com uma ampla gama de aplicações incluindo as áreas de saúde, segurança, ambiental entre ou-tras. Apesar dos recursos limitados que essas redes possuem, espera-se que elas funcionem por um longo intervalo de tempo sem intervenções humanas, um requisito difícil de ser alcançado uma vez que o ambiente monitorado pode desenvolver características não previstas, ou alguma funcionalidade da rede pode necessitar mudanças. Como essas redes podem ser formadas por milhares de nodos, é impraticável recolhê-los para realizar a atualização, por este motivo é ne-cessário um mecanismo que permita a reprogramação do software dos nodos da rede após a implantação da mesma.

Para a rede ser atualizada é essencial que todos os seus nodos recebam os dados necessários, isto ocorre através da utilização de um protocolo de disseminação, responsável por propagar os dados através da rede. Dito isso, podemos considerar o processo de distribuição de código como um caso especial de disseminação confiável, onde o protocolo de disseminação garante a correta entrega dos dados para todos os nodos da rede.

Este trabalho apresenta uma visão geral de redes de sensores sem fio e tecnologias en-volvidas, um estudo sobre protocolos de disseminação de dados e o desenvolvimento de um protocolo para o sistema operacional EPOS.

(7)

Wireless sensor networks have been proposed as a solution for data gathering with a wide range of aplications including areas like health, security, environmental and others. Despite the limited resources these networks posseses, they are expected to operate for a long period of time without human interventions, a requirement difficult to be accomplished since the envi-ronment might develop unpredicted characteristics, or some network functionality might need some changes. Since these networks can be formed by thousands of nodes, it is impractcal to collect them completely to perform the update, reason why we need a mechanism that allows the software reprogramming of the network nodes after its deployment.

To update the network it is essencial that all nodes receive the necessary data, this occurs through the use of a dissemination protocol, responsible for spreading the data over the network. That said, it is possible to consider the process of code distribution as a special case of reliable dissemination, where the dissemination protocol guarantees the correct delivery of data to all network nodes.

This work presents an overview of wireless sensor networks and technologies involved, a study of data dissemination protocols and the development of a protocol for the EPOSoperating system.

(8)

Sumário

Lista de Figuras Lista de Tabelas 1 Introdução p. 13 1.1 Objetivos . . . p. 14 1.2 Organização do Trabalho . . . p. 14

2 Redes de Sensores Sem Fio p. 15

2.1 Nodos Sensores . . . p. 16 2.1.1 Restrições de Hardware . . . p. 16 2.1.2 Crossbow MICA2 . . . p. 17 2.2 Arquiteturas de Execução . . . p. 18 2.2.1 Arquiteturas com MMU . . . p. 18 2.2.2 Arquiteturas sem MMU . . . p. 18 2.3 Aplicações . . . p. 20 2.4 Sistemas Operacionais para Redes de Sensores Sem Fio . . . p. 20 2.4.1 TinyOS . . . p. 21 2.4.2 Mantis OS . . . p. 21 2.4.3 SOS . . . p. 21 2.4.4 EPOS . . . p. 21

(9)

3.3 Análise dos Protocolos Existentes . . . p. 26 3.3.1 Reijers et al. . . p. 26 3.3.2 MOAP . . . p. 27 3.3.3 Deluge . . . p. 29 3.3.4 MNP . . . p. 31 3.3.5 Infuse . . . p. 33 3.3.6 Sprinkler . . . p. 35 3.4 Comparação dos Protocolos Analisados . . . p. 36

4 Proposta p. 39

4.1 Escolhas de projeto . . . p. 39 4.2 Abordagem baseada em diferenças . . . p. 40 4.2.1 Formato de arquivo Intel Hex . . . p. 40 4.2.2 Geração de diferenças . . . p. 40 4.3 Disseminação . . . p. 41 4.3.1 Multiplexação espacial . . . p. 41 4.4 Seleção de emissores . . . p. 42 4.5 Política de retransmissão . . . p. 43 4.6 Gerência de segmentos . . . p. 44 4.7 Atualização tardia . . . p. 45 4.8 Reinicialização . . . p. 45 4.9 Implementação . . . p. 45 4.9.1 Configurabilidade . . . p. 46 5 Considerações Finais p. 48

(10)

Referências Bibliográficas p. 50

Apêndice A -- Código fonte p. 53

A.1 packer.cc . . . p. 53 A.2 updater.h . . . p. 56 A.3 updater.cc . . . p. 57

(11)

2.1 Arquitetura de uma RSSF [Akyildiz et al. 2002]. . . p. 15 2.2 Componentes de um nodo sensor [Akyildiz et al. 2002]. . . p. 16 2.3 Nodo sensor MICA2 [Crossbow Technology Inc.]. . . p. 17 3.1 Processo de programação em rede [Jeong e Culler 2004]. . . p. 23 3.2 Diagrama de características. . . p. 25 3.3 Escolhas de projeto do Reijers et al.. . . p. 26 3.4 Deslocamento de endereços [Reijers e Langendoen 2003]. . . p. 27 3.5 Escolhas de projeto do MOAP. . . p. 27 3.6 Máquina de estados: MOAP. . . p. 29 3.7 Escolhas de projeto do Deluge. . . p. 29 3.8 Hierarquia de gerenciamento de dados [Hui e Culler 2004]. . . p. 30 3.9 Máquina de estados: Deluge. . . p. 31 3.10 Escolhas de projeto do MNP. . . p. 31 3.11 Máquina de estados: MNP. . . p. 33 3.12 Escolhas de projeto do Infuse. . . p. 33 3.13 Máquina de estados: Infuse. . . p. 34 3.14 Escolhas de projeto do Sprinkler. . . p. 35 3.15 Máquina de estados: Sprinkler. . . p. 36 4.1 Escolhas de projeto do protocolo desenvolvido. . . p. 39 4.2 Formato do arquivo Intel HEX. . . p. 41 4.3 Tarefas de um potencial emissor [Wang 2004]. . . p. 42 4.4 Tarefas de um receptor [Wang 2004]. . . p. 42

(12)

4.6 Máquina de estados do protocolo desenvolvido. . . p. 46 4.7 Configurabilidade do protocolo pelo Traits. . . p. 46 4.8 Criação durante a inicialização das threads do sistema. . . p. 47

(13)

2.1 Hardware do MICA2. . . p. 18 2.2 Comparação entre as arquiteturas de execução [Han et al. 2005]. . . p. 19 3.1 Resumo dos protocolos estudados. . . p. 38 3.2 Escolhas de projeto dos protocolos estudados (prioridade dada às propriedades). p. 38

(14)

1 Introdução

Redes de sensores sem fio são formadas por um conjunto de pequenos dispositivos sensores, chamados nodos sensores, que cooperam entre si no monitoramento do ambiente em que se encontram. Estes dispositivos, em sua maioria, possuem baixo poder de processamento, pouca memória, largura de banda pequena (rádios de baixa potência e curto alcance) e uma quantidade limitada de energia [Stathopoulos John Heidemann 2003].

Não obstante os recursos limitados característicos dessas redes, uma vez implantada no am-biente, espera-se que elas apresentem uma vida útil extensa, ou seja, funcionem por um longo intervalo de tempo sem manutenção. Entretanto existem situações contrárias a esta expectativa, como mudanças no ambiente que desenvolvam características não previstas, gerando a necessi-dade de adicionar/corrigir/melhorar/remover funcionalinecessi-dades.

Uma solução seria coletar todos os nodos sensores, reprogramá-los e recolocá-los no am-biente, porém, existem vários cenários onde alcançá-los fisicamente é impraticável devido ao grande número de nodos ou ao fato de eles estarem em locais de difícil acesso (e.g. copas de árvores), prejudicial ao monitoramento (e.g. nodos em ninhos) ou até mesmo impossível (e.g. nodos cercados de concreto monitorando a vibração de uma ponte). Portanto, é necessário um mecanismo capaz de transmitir todos os dados essenciais para a atualização da rede sem ter que alcançar fisicamente cada um de seus nodos [Wang 2004].

Utilizando um protocolo de disseminação podemos propagar os dados pela rede utilizando seus próprios nodos para isso. De forma simplificada, um protocolo funciona da seguinte ma-neira: a disseminação começa através de uma estação base responsável por transmitir os da-dos aos seus noda-dos vizinhos. Uma vez que um nodo recebe os dada-dos ele passa a ser capaz de retransmití-los aos seus próprios vizinhos. Assim, se um nodo A tem B como vizinho, e o nodo B tem A e C como vizinhos, ao receber os dados de A o nodo B vai retransmití-los para C. O processo se repete para todos os nodos, de forma que a rede inteira receba os dados [Stathopoulos John Heidemann 2003, Hui e Culler 2004].

(15)

rede, por este motivo, o protocolo deve garantir a correta entrega dos mesmos e possuir meca-nismos de recuperação de pacotes perdidos. Todavia, enviar o novo código inteiro envolve uma alta quantidade de dados transmitidos, resultando em um maior consumo de energia e exigindo dos nodos espaço de armazenamento livre para recepção total desses dados, aumentando o nú-mero de escritas na memória. Para reduzir estes problemas pode-se utilizar técnicas integradas ao protocolo de disseminação que enviam apenas as diferenças entre o novo código e o que está sendo executando [Reijers e Langendoen 2003].

1.1 Objetivos

Este trabalho tem como principal objetivo o desenvolvimento de um protocolo de dissemi-nação de dados para redes de sensores sem fio, de forma a habilitar o processo de reprogramação em rede.

Com base no objetivo principal, são definidos os seguintes objetivos específicos:

• Estudar Redes de Sensores Sem Fio e tecnologias envolvidas;

• Estudar protocolos de disseminação de dados, suas propriedades e componentes; • Estudar o estado da arte e analisar soluções existentes para disseminação de dados; • Modelar e implementar o protocolo de disseminação de dados utilizando o sistema

ope-racional EPOS;

1.2 Organização do Trabalho

Capítulo 2 apresenta uma visão geral sobre redes de sensores sem fio, características do hard-ware utilizado, aplicações relevantes e sistemas operacionais que as suportam.

Capítulo 3 define protocolo de disseminação de dados, suas propriedades e componentes; além de um estudo, análise e comparação de protocolos existentes.

Capítulo 4 descreve o protocolo proposto, seu funcionamento, características, escolhas de pro-jetos realizadas e implementação.

Capítulo 5 conclui a dissertação e sugere trabalhos futuros, procedentes desse, como pesquisas futuras e melhorias que possam ser feitas ao que foi desenvolvido.

(16)

2 Redes de Sensores Sem Fio

Recentes avanços na tecnologia de circuitos integrados possibilitaram a construção de com-ponentes, como sensores, rádios e processadores, mais baratos e ainda assim mais eficientes [Pottie e Kaiser 2000]. Através destes avanços chegamos à beira de uma nova era, onde peque-nos dispositivos sem fio irão fornecer acesso à informação a qualquer hora, em qualquer lugar [Tilak, Abu-Ghazaleh e Heinzelman 2002]. Estes pequenos dispositivos, que são constituídos com módulos de sensoriamento, computação e comunicação, impulsionaram a ídeia de redes de sensores formadas por um grande número de nodos trabalhando de maneira colaborativa [Akyildiz et al. 2002]. A Figura 2.1 apresenta a arquitetura de uma Rede de Sensores Sem Fio (RSSF).

Algumas características que diferenciam RSSF de redes ad hoc tradicionais são:

• o número de nodos sensores pode ser muito maior; • nodos sensosres são mais propensos a falhas;

• a topologia da rede não precisa ser pré-determinada ou calculada;

• nodos sensores possuem energia, capacidade de processamento e memória limitados;

Figura 2.1: Arquitetura de uma RSSF [Akyildiz et al. 2002].

Este capítulo descreve a arquitetura dos nodos sensores que formam a rede, aplicações e os sistemas operacionais para RSSF.

(17)

2.1 Nodos Sensores

Nodos sensores são os componentes básicos de uma RSSF, são eles os responsáveis pelo nível mais baixo da aplicação de sensoriamento. Vários nodos são depositados pelo ambiente a ser monitorado e cada nodo coleta dados de seus arredores. Os dados adquiridos são então pré-processados no nodo e depois enviados para uma estação base através da rede.

Como mostrado na Figura 2.2, nodos sensores são formados por quatro componentes bási-cos:

Unidade de sensoriamento: comumente formada por duas subunidades; sensores e converso-res analógico digital (ADC - Analog to Digital Converter). Os sinais analógicos gerados pelos sensores são convertidos para sinais digitais pelos ADCs e depois passados para a unidade de processamento.

Unidade de processamento: geralmente associada com uma unidade de armazenamento, ela gerencia as funções do nodo para que ele colabore com os outros nodos da rede de forma a cumprir as tarefas a eles atribuídas.

Unidade transceptora: encarregada de conectar o nodo à rede. Unidade de energia: responsável por fornecer energia ao nodo.

Além destes, os nodos também podem possuir componentes adicionais dependentes de aplicação, como sistemas de localização, fontes de energia, entre outros.

Figura 2.2: Componentes de um nodo sensor [Akyildiz et al. 2002].

2.1.1 Restrições de Hardware

Além do tamanho, que deve ser pequeno, um nodo sensor deve possuir consumo de energia extremamente baixo e baixo custo de produção [Kahn, Katz e Pister 1999].

(18)

Pode-se considerar no mínimo imprático ter que coletar todos os nodos de uma rede para substituir suas fontes de energia, e.g. trocar pilhas. Além disso, espera-se que um nodo sensor opere de forma autônoma, portanto seu tempo de vida depende diretamente de seus recursos energéticos. Uma maneira de aumentar a duração da vida de um nodo é utilizar algum meca-nismo capaz de retirar energia do ambiente (e.g. células solares).

Como uma RSSF pode ser formada por um grande número de nodos sensores, o custo individual dos nodos não deve ser alto de forma a não tornar a rede uma solução inviável. Por este motivo nodos sensores, em geral, apresentam baixo poder de processamento e pouca memória.

2.1.2 Crossbow MICA2

Para a implementação do projeto foi escolhido o nodo sensor MICA2, ilustrado na Figura 2.3, devido a sua disponibilidade e ao fato de que o sistema operacional EPOS (ver seção 2.4) possui suporte a esse dispositivo.

O MICA2 pertence a uma família de nodos criados por um grupo de pesquisa da Uni-versidade de Berkley [Hill e Culler 2002]. Atualmente ele é fabricado e comercializado pela companhia Crossbow Technology.

Figura 2.3: Nodo sensor MICA2 [Crossbow Technology Inc.].

Este nodo sensor possui um microcontrolador com memória de programa interna, interfaces para placas de sensores, um módulo de rádio de baixa potência e um chip de memória não volátil. A Tabela 2.1 apresenta a configuração de hardware do MICA2.

(19)

Tabela 2.1: Hardware do MICA2. Nome MICA2

Modelo MPR 400

MCU 7.37 MHz, 8 bit ATMega128L Rádio 868/916 MHz MultiChannel Flash 128 kB SRAM 4 kB EEPROM 4 kB Bateria 2x AA

2.2 Arquiteturas de Execução

Uma arquitetura de execução é o modelo no qual o programa executa “em cima” do hard-ware do nodo sensor. Os diferentes tipos de hardhard-ware existentes, assim como as necessidades das aplicações no domínio de RSSF, acabaram por criar uma variedade de arquiteturas de exe-cução customizadas para realizar o melhor uso do hardware disponível [Han et al. 2005].

2.2.1 Arquiteturas com MMU

Em geral, RSSFs não são formadas exclusivamente por nodos equipados com uma MMU (Memory Management Unit), mas pode ocorrer de algumas redes utilizarem um pequeno con-junto de nodos mais sofisticados para gerenciar os outros nodos da rede.

Através da MMU os nodos são capazes de utilizar memória virtual, tornando grande parte do código independente de posição. Essa propriedade é muito útil quando se deseja realizar uma atualização, pois os processos podem ser atualizados em tempo de execução sem ter que utilizar referências a endereços de memória absolutos [Han et al. 2005].

2.2.2 Arquiteturas sem MMU

Muitos dos microcontroladores usados em RSSF não possuem uma MMU, como é o caso do microcontrolador presente no nodo sensor MICA2. Nestas arquiteturas o nodo opera em um único espaço de endereçamento que é vulnerável a referências de memória incorretas.

(20)

Monolítica

Arquiteturas monolíticas realizam otimizações em tempo de compilação para obter um me-lhor desempenho em tempo de execução. Desta forma o código gerado não possui uma separa-ção entre o kernel do sistema e a aplicasepara-ção. Exemplos dessa arquitetura são: EPOS, TinyOS e MantisOS, apresentados na seção 2.4.

Modular

Nestas arquiteturas o sistema é dividido em duas partes: o kernel do sistema que é estático e módulos individuais capazes de serem carregados ou removidos em tempo de execução. O kernel fornece serviços como I/O e gerenciamento de memória que são utilizados pelos módulos para extender as funcionalidades do sistema. Um exemplo é o sistema operacional SOS, ver seção 2.4.

Máquina Virtual

Uma máquina virtual abstrai o hardware com o intuito de fornecer instruções de mais alto nível para as aplicações. Essas instruções permitem a criação de scripts que são interpreta-dos e executainterpreta-dos no nodo sensor. Um exemplo dessa arquitetura é a máquina virtual Maté [Levis e Culler 2002].

A vantagem dessa abordagem é que todos os acessos ao hardware são gerenciados indi-retamente pela máquina virtual, evitando problemas como referências de memória incorretas. Todavia, interpretar as instruções da máquina virtual é um processo mais custoso do que execu-tar instruções nativas do hardware.

Tabela 2.2: Comparação entre as arquiteturas de execução [Han et al. 2005].

Consumo Energético Monolítica Modular Máquina Virtual

Transmissão em rede Pior Intermediário Melhor

Armazenamento externo Pior Intermediário Melhor

Armazenamento on-chip Pior Intermediário Melhor

Execução do programa Melhor Intermediário Pior

Flexibilidade de atualização Melhor Intermediário Pior

(21)

2.3 Aplicações

RSSF podem ser consituídas por vários tipos de sensores: sísmicos; magnéticos; térmi-cos; visuais; infravermelhos; acústicos e radares, permitindo o monitoramento de uma ampla variedade de condições ambientais incluindo [Estrin et al. 1999]:

• temperatura; • umidade; • movimentação de veículos; • luminosidade; • pressão; • composição do solo; • níveis de ruído;

• presença ou ausência de objetos; • nível de tensão mecânica;

• caractéristicas atuais de um objeto, como velocidade, direção e tamanho;

Nodos sensores podem ser utilizados em monitoramentos contínuos, detecção de eventos, sensioramento de localização e no controle local de atuadores [Akyildiz et al. 2002]. O conceito de micro-sensores e a conexão sem fio desses nodos permite sua utilização em muitas áreas, em especial aplicações ambientais, de sáude, comerciais, militares e ambientes inteligentes.

2.4 Sistemas Operacionais para Redes de Sensores Sem Fio

Nodos sensores possuem poder computacional limitado, desta forma não são capazes de executar SOs (Sistemas Operacionais) de uso geral. Uma série de SOs foram desenvolvidos levando em consideração essas limitações, nesta seção alguns deles são apresentados.

(22)

2.4.1 TinyOS

TinyOS é um sistema operacional constituído de componentes reutilizáveis que são usa-dos em conjunto formando uma aplicação específica [Levis et al. 2005]. Ele apresenta um modelo de concorrência orientado a eventos e é implementado utilizando a linguagem NesC [Gay et al. 2003], que suporta seus modelos de componentes e concorrência, assim como uma série de otimizações entre componentes e detecção de condições de corrida em tempo de com-pilação. Este SO suporta uma ampla gama de plataformas de hardware e tem sido utilizado em várias gerações de nodos sensores, podendo ser considerado o SO mais usado na área de RSSF.

2.4.2 Mantis OS

Multimodal Networks of In-situ Sensors é um SO multithread [Bhatti et al. 2005]. Ele apre-senta uma API (Application Programming Interface) compatível com o padrão POSIX (Porta-ble Operating System Interface for Unix) que é implementada utilizando a linguagem C, per-mitindo um suporte à multiplataformas e minimizando a barreira para iniciantes em termos de propramação para redes de sensores.

2.4.3 SOS

SOS consiste em módulos dinamicamente carregáveis e um kernel, o qual implementa ser-viços de passagem de mensagens, alocação de memória, carga e descarga de módulos entre outros [Han et al. 2005]. Módulos enviam mensagens e se comunicam com o kernel através de uma tabela do sistema que contém jumps relativos. Através dessa combinação, o SOS suporta alterações no software de maneira mais eficiente. Ele é implementado em C, de forma a tirar proveito das ferramentas já existentes para essa linguagem, como compiladores, depuradores entre outras.

2.4.4 EPOS

Embedded Parallel Operating System é um framework baseado em componentes para gera-ção de sistemas embarcados [Polpeta e Frohlich 2004]. Ele é baseado na metodologia ADESD (Application-Driven Embedded System Design) [Fröhlich 2001], permitindo que aplicações se-jam desenvolvidas sem depender da plataforma alvo. O sistema suporta diversas arquiteturas, entre elas: IA32, PowerPC e MIPS.

(23)

possibilitando a sua utilização sobre a plataforma MICA2; um protocolo de controle de acesso ao meio configurável (C-MAC), permitindo que as aplicações configurem o canal de comuni-cação de acordo com suas necessidades; e um sistema de aquisição de dados de sensores, capaz de abstrair famílias de dispositivos sensores de maneira uniforme, sem ocasionar sobrecusto excessivo [Wanner et al. 2006].

(24)

3 Protocolos de Disseminação de Dados

para Redes de Sensores Sem Fio

Protocolos de disseminação de dados são utilizados em redes de sensores sem fio para propagar dados pela rede utilizando seus próprios nodos para isso. Em especial, um protocolo utilizado por um mecanismo de reprogramação em rede deve ser acima de tudo confiável, ou seja, deve garantir a entrega correta de todos os dados a todos os nodos.

Em geral o processo de programação em rede é dividido em três etapas, como ilustrado na Figura 3.1. A primeira é responsável pela preparação dos dados a serem disseminados. A segunda etapa engloba todo o processo de disseminação, onde os dados são enviados e armaze-nados pelos nodos sensores pertencentes à rede. Por fim, o mecanismo de atualização reconstrói a imagem binária e atualiza a memória de programa, desta forma, atualizando o nodo.

Figura 3.1: Processo de programação em rede [Jeong e Culler 2004].

Este capítulo descreve as propriedades e componentes de um protocolo de disseminação de dados e realiza um estudo sobre alguns protocolos existentes.

(25)

3.1 Propriedades

Um protocolo de disseminação de dados deve ser projetado levando em conta as seguintes propriedades [Lanigan, Gandhi e Narasimhan 2005]:

Baixa Latência: como a atualização é um serviço secundário o protocolo não deve interromper a aplicação principal por muito tempo.

Baixo Consumo de Memória: os dados necessários para a atualização devem ser armazena-dos até que a transmissão termine, entretanto o protocolo deve requisitar pouco espaço de armazenamento de forma a não restringir a quantidade de memória disponível para a aplicação principal.

Confiabilidade: ao contrário das aplicações tradicionais de redes de sensores onde a perda de um pacote é tolerável devido ao fato de que os dados extraídos do ambiente são re-dundantes e correlacionados, na reprogramação cada pacote é crucial e todos devem ser recebidos para que a atualização possa ocorrer. Sendo assim o protocolo deve possuir uma política de retransmissão permitindo a recuperação de pacotes perdidos.

Eficiência Energética: o protocolo deve minimizar seu consumo de energia de forma a não diminuir severamente o tempo de vida da rede.

Tolerância a Inclusão/Remoção de nodos: é possível que um nodo falhe durante um periodo de tempo e depois volte a funcionar, ou até mesmo que novos nodos sejam incluídos na rede. Desta forma a disseminação não deve ser severamente afetada pela inclusão ou remoção de nodos.

Uniformidade: para garantir que a rede inteira seja atualizada, todos os dados devem ser en-tregues a todos os nodos da rede. Nodos incluídos na rede durante ou depois de uma atualização também devem ser capazes de receber os dados da atualização.

As propriedades de confiabilidade e uniformidade são obrigatórias, uma vez que garan-tem o funcionamento correto do protocolo. Já as propriedades de baixa latência, baixo consumo de memória, eficiência energética e tolerância a inclusão ou remoção de nodos são apenas de-sejáveis, pois não garantem corretude. Entretanto um protocolo que as ignore seria de pouca utilidade na prática [Stathopoulos John Heidemann 2003].

Como algumas propriedades desejáveis entram em conflito com outras, os protocolos exis-tentes realizam escolhas de projetos dando preferência a umas em detrimento de outras.

(26)

3.2 Componentes

A Figura 3.2 apresenta o diagrama de características de um protocolo de disseminação de dados. Analisando o diagrama é possível caracterizar os componentes que juntos fornecem a funcionalidade básica de um protocolo.

Preparador: este componente decide quais dados vão ser transmitidos e de que forma eles serão representados. Como a quantidade de dados pode ser alta eles são dividos em seg-mentos que são empacotados e utilizados pelo disseminador. Também é responsável por executar alguns passos de inicialização nos nodos da rede caso necessário (e.g. calcular faixas de tempo TDMA, calcular um CDS).

Disseminador: este componente permite que os dados sejam propagados pela rede e possui alguns mecanismos para diminuir o número de transmissões e colisões, gerenciar seg-mentos e detectar perdas de pacotes.

Finalizador: este componente é responsável por interpretar os dados recebidos e utilizá-los para reconstruir a memória de programa, finalizando o processo de atualização.

(27)

3.3 Análise dos Protocolos Existentes

3.3.1 Reijers et al.

O mecanismo de distribuição de código descrito em [Reijers e Langendoen 2003] foi pro-jetado com o intuito de ser energéticamente eficiente, Figura 3.3. Para isto, é utilizado um esquema baseado em diferenças responsável por reduzir a quantidade de dados a ser enviada.

0 0 0 1 1 1 00 11 0 0 1 1 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 Latência Consumo de Memória Consumo de Energia 00000000 00000000 00000000 00000000 00000000 00000000 11111111 11111111 11111111 11111111 11111111 11111111 0000 0000 0000 0000 0000 0000 1111 1111 1111 1111 1111 1111

Figura 3.3: Escolhas de projeto do Reijers et al..

Esse esquema se baseia na suposição de que em muitos casos as mudanças no código bi-nário serão pequenas. Mesmo aplicações completamente diferentes podem ter partes iguais do sistema operacional e bibliotecas de funções presentes em suas imagens binárias. Sendo assim, a solução proposta é semelhante ao comando diff dos sistemas operacionais tipo Unix. A fun-ção desse comando é encontrar o menor edit script entre duas strings. Esse script consiste nas operações que devem ser realizadas em uma string de forma que ela fique idêntica à outra. Para isso, o diff utiliza operações de inserção, remoção e substituição de caracteres. Entretanto, fora a operação inserir, o esquema apresentado utiliza operações diferentes.

É provável que partes do código sejam deslocadas de posição entre duas versões e que par-tes genéricas de código apareçam em ambas. Nespar-tes casos utilizar um comando copiar, ao invés de remover e depois inserir, reduz o tamanho do edit script. Além disso também é possível que algumas partes do código sejam semelhantes mas não identicas. Um comando reparar, que opera um comando copiar substituindo uma ou duas palavras em um deter-minado offset dos dados copiados, é menor do que a sequência copiar, inserir, copiar. Mesmo utilizando esta abordagem o tamanho do edit script talvez continue grande. Isto ocorre porque uma mudança no código fonte pode deslocar o endereço de funções e dados, como mostra a Figura 3.4. Uma vez que funções e endereços de dados são utilizados mais de uma vez, várias instruções são afetadas, necessitando de muitas operações reparar. Consi-derando que grupos de funções ou dados são deslocados pelo mesmo offset, conhecendo estes deslocamentos os nodos são capazes de corrigir os endereços das instruções automaticamente ao executar um comando copiar. Sendo assim, os deslocamentos são descritos por uma lista

(28)

de tuplas {endereço base, endereço final, offset} e enviados aos nodos utilizando o comando lista de correções. O problema de se fazer isto é que torna o esquema dependente da arquitetura na qual está sendo executado, pois agora deve-se conhecer o formato das instruções utilizadas a fim de alterá-las.

Figura 3.4: Deslocamento de endereços [Reijers e Langendoen 2003].

Apesar do algoritmo para geração do edit script ter sido bem desenvolvido, a distribuição dos dados é menos sofisticada do que deveria e incapaz de atualizar a rede inteira. É uma comu-nicação nodo a nodo com confirmações (acknowledgements) para transferir o script, utilizando apenas dois nodos, onde um reprograma o outro.

3.3.2 MOAP

Multi-hop Over the Air Programming é um mecanismo de distribuição de código desen-volvido especificamente para o nodo MICA2 [Stathopoulos John Heidemann 2003], projetado priorizando o consumo de energia e memória em detrimento da latência, Figura 3.5.

Figura 3.5: Escolhas de projeto do MOAP.

O novo código é passado para um empacotador responsável por dividir a imagem binária em segmentos e empacotá-los. Cada segmento possui um campo de dois bytes indicando seu endereço na memória de programa e um campo de dezesseis bytes para dados. Cada pacote possui um segmento.

(29)

O MOAP utiliza um mecanismo de disseminação chamado Ripple, que distribui os dados de vizinhança em vizinhança. É como se dividissemos uma propagação multi-hop em uma série de transmissões single-hop. Em cada vizinhança apenas um pequeno subconjunto de nodos (de preferência apenas um) funcionam como emissores, enquanto os restantes são receptores. Quando os nodos recebem todos os dados eles podem se tornar emissores para seus próprios vizinhos (que estavam fora do alcance do emissor original). Para evitar que nodos se tornem emissores em uma vizinhança que já possua um, o mecanismo utiliza uma interface divulga-inscreve. Nodos emissores divulgam sua versão e todos os interessados se inscrevem. Se um emissor não recebe inscrições ele fica em silêncio. A Figura 3.6 apresenta a máquina de estados do MOAP.

Uma vantagem do Ripple é a garantia de que se uma transmissão de dados estiver em progresso, o emissor está a apenas um hop de distância. Assim, todos os reparos (retransmissões de pacotes perdidos) são locais, diminuindo a complexidade e consumo de energia do protocolo, uma vez que os reparos não precisam ser roteados por um caminho muito longo. O custo disto é um aumento na latência, já que os dados não são transmitidos para todos os nodos ao mesmo tempo, isto porque um nodo necessita receber todos os segmentos para se tornar um emissor.

Os receptores são responsáveis por detectar a perda de pacotes e realizam esta tarefa utili-zando o mecanismo de janelas deslizantes para gerenciamento de segmentos [Tanenbaum 2003]. Ao detectar uma perda, o receptor envia um pedido de retransmissão para o emissor, utilizando um pacote unicast. Quando dois pedidos iguais chegam a um mesmo emissor dentro de de-terminado tempo, eles são suprimidos. Os pedidos de retransmissão possuem uma prioridade maior que pacotes normais, então um emissor irá primeiro responder a todas as requisições an-tes de continuar com a transmissão. A vantagem desta abordagem é a recuperação imediata das perdas. No entanto, ela pode sofrer do problema crying babe, isto é, se a comunicação com um nodo da vizinhança possuir uma elevada taxa de erros, o emissor pode receber um número ex-cessivo de pedidos de retransmissão, atrasando a disseminação e prejudicando os outros nodos da rede [Holbrook, Singhal e Cheriton 1995].

Caso um receptor perca contato com seu emissor, ele transmite um pedido broadcast de recuperação, para o qual todos os emissores em alcance irão responder, permitindo ao receptor escolher um novo emissor. Caso não haja emissores em alcance, o nodo vai continuar transmi-tindo o pedido de recuperação até atingir um número máximo de tentativas e então irá abortar, esperando por um novo vizinho virar emissor, ou irá se utilizar do mecanismo de atualização tardia.

(30)

ope-ração de disseminação receberem a nova imagem. Este mecanismo requer que todos os nodos divulguem suas versões periodicamente. Caso um nodo receba uma mensagem com uma versão menor, ele vai mandar uma nova mensagem divulgando a sua versão.

Figura 3.6: Máquina de estados: MOAP.

3.3.3 Deluge

Deluge é um protocolo de disseminação projetado para propagar uma grande quantidade de dados de forma rápida e confiável, Figura 3.7. Ele compartilha várias idéias com o MOAP, como o uso de NACKs, pedidos de retransmissão unicast, transmissão de dados broadcast e “janelamento” para gerenciar segmentos [Hui e Culler 2004].

0 0 0 1 1 1 00 11 0 0 1 1 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 1111111111 1111111111 1111111111 1111111111 1111111111 1111111111 1111111111 1111111111 1111111111 1111111111 1111111111 1111111111 1111111111 1111111111 1111111111 1111111111 1111111111 1111111111 Latência Consumo de Memória Consumo de Energia 00000000 00000000 00000000 00000000 00000000 00000000 11111111 11111111 11111111 11111111 11111111 11111111 0000000 0000000 0000000 1111111 1111111 1111111

Figura 3.7: Escolhas de projeto do Deluge.

Com o intuito de limitar a quantidade de informações que um receptor deve manter, possibi-litar atualizações incrementais e permitir multiplexação espacial, o protocolo utiliza o conceito de páginas. Os dados são divididos em P páginas, sendo que uma página nada mais é do que

(31)

um conjunto de N pacotes, ver Figura 3.8. Exigindo que os nodos recebam uma página por vez, pode-se utilizar um mapa de bits de apenas N bits para gerenciamento de segmentos, pois não é mais necessário manter registros de todos os pacotes ao mesmo tempo. Utilizando um vetor de idades para descrever a idade de cada página, os nodos são capazes de determinar quando uma página mudou e se necessitam ou não requisitá-la.

Figura 3.8: Hierarquia de gerenciamento de dados [Hui e Culler 2004].

Durante o processo de disseminação um nodo qualquer está sempre operando em um de três estados: MAINTAIN, onde é responsável por garantir que todos os nodos ao seu alcance possuam a versão mais recente dos dados; RX, responsável por requisitar os pacotes que faltam para completar uma página; e TX, responsável por transmitir todos os pacotes requisitados para uma determinada página. A Figura 3.9 apresenta a máquina de estados do Deluge.

Cada nodo divulga sua versão e o número de sua maior página disponível para transferência, sendo que uma página p só está disponível para transferência se todas as páginas no intervalo [0, p] estão completas. Para diminuir a transmissão de mensagens de controle redundantes utiliza-se o mecanismo de supressão Trickle [Levis et al. 2004]. O Trickle divide o tempo em uma série de intervalos e os nodos decidem se divulgam ou não em cada um deles, sendo que há um número máximo de divulgações que podem ser realizadas durante cada intervalo. Apesar deste mecanismo evitar colisões ele introduz uma certa latência. Entretanto, como um nodo pode divulgar uma página mesmo antes de possuir todos os dados, isto possibilita uma propagação em paralelo pela rede, diminuindo o tempo total de disseminação.

Através das mensagens de divulgação um nodo pode descobrir se algum vizinho possui uma versão mais antiga, e neste caso transmitir sua versão e seu vetor de idades. Ao ouvir a divulgação de uma página que não possua, o nodo muda do estado MAINTAIN para RX, a menos que tenha recentemente ouvido (i) uma requisição para uma página menor, neste caso passando para o estado TX; ou (ii) um pacote de dados que pertença à página desejada ou menor.

(32)

quais pacotes são necessários para completar uma determinada página. Feita uma requisição, espera-se pela resposta e realiza-se outras requisições caso haja alguma perda. O nodo retorna ao estado MAINTAIN quando recebe todos os pacotes necessários, ou após realizar um número máximo de requisições caso a taxa de recepção esteja muito baixa. É importante ressaltar que um nodo não precisa estar no estado RX para receber pacotes de dados, o protocolo se aproveita das transmissões de dados broadcast e qualquer pacote necessário para completar uma página incompleta é salvo independente do estado em que o nodo se encontra.

Nodos no estado TX só retornam ao estado MAINTAIN após terem transmitido todas as requisições recebidas. Os pacotes são mantidos em um conjunto e enviados em ordem round-robin. Pacotes requisitados em novas mensagens são adicionados ao conjunto e os pacotes enviados são removidos do mesmo.

Figura 3.9: Máquina de estados: Deluge.

3.3.4 MNP

Multi-hop Network Programming é um protocolo de reprogramação em rede projetado para o nodo MICA2 [Wang 2004]. Suas principais características incluem um mecanismo para sele-ção de emissor e uma abordagem para reduzir o uso da memória RAM, Figura 3.10.

0 0 0 1 1 1 00 11 0 0 1 1 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 Latência Consumo de Memória Consumo de Energia 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 0000 0000 0000 1111 1111 1111

Figura 3.10: Escolhas de projeto do MNP.

Assim como no MOAP a disseminação ocorre de vizinhança em vizinhança e um nodo só pode se tornar emissor após receber todos os dados. O MNP consiste em quatro fases principais:

(33)

Advertisement/Request; Forward/Download; Query/Update e Reboot. A Figura 3.11 apresenta a máquina de estados do MNP.

Na primeira fase, Advertisement/Request, os potenciais emissores divulgam suas versões, em intervalos aleatórios, e nodos interessados a requisitam. Através do algoritmo para seleção de emissor, um nodo decide se deve transmitir o código ou não. O objetivo deste algoritmo é o de garantir que a qualquer momento apenas um nodo esteja transmitindo os dados por vez, e que este transmissor seja o que vai causar maior impacto, em outras palavras, o que tiver um maior número de receptores. É importante ressaltar que o algoritmo não garante encontrar o emissor ideal, todavia, ele seleciona “bons” emissores e reduz o número de colisões.

Potenciais emissores mantêm uma variável ReqCtr, inicializada com zero, e a incrementa para cada nova requisição recebida, destinada a ele, vinda de um nodo ainda não computado. As mensagens de divulgação tem duas funções: anunciar uma nova versão e previnir que nodos com menos requisições virem emissores; elas possuem o número e tamanho da nova versão, o id do emissor e sua variável ReqCtr. Quando um nodo recebe uma mensagem de divulgação que contenha uma nova versão, ele irá enviar uma requisição broadcast contendo seu id, o do transmissor e o valor da ReqCtr recebida. Como as divulgações e requisições são broadcasts outros nodos que estão na disputa para se tornarem emissores também as recebem e caso pos-suam um ReqCtr menor vão para o estado sleep. Como critério de desempate é utilizado o id dos nodos.

Ao virar emissor um nodo transmite uma mensagem broadcast “StartDownload” dando início a segunda fase, Forward/Download, e passa a enviar os dados, pacote por pacote em or-dem sequencial. Os receptores definem este nodo como seu “pai” e só aceitam pacotes vindo dele, armazenando-os na EEPROM. Cada pacote possui um identificador único sequencial e os receptores mantêm o número do último pacote recebido. Assim, ao receber um novo pacote verifica-se se há uma lacuna entre estes dois números e os pacotes intermediários são consi-derados perdidos. Com o intuito de evitar o problema do crying babe, as requisições não são realizadas na hora da detecção, desta forma deve-se manter registro dos pacotes perdidos. Para isto o MNP utiliza uma lista encadeada, armazenada na EEPROM, a fim de reduzir o consumo da memória RAM.

Após a transmissão de todos os pacotes começa a terceira fase, Query/Update, onde o emissor consulta seus receptores através de uma mensagem broadcast query. Requisições são feitas de maneira unicast e retransmissões de forma broadcast. Caso um receptor fique por um longo período de tempo sem ouvir de seu pai, tanto nesta quanto na segunda fase, ele o considera morto e espera por uma nova mensagem “StartDownload”. No final da terceira fase o emissor

(34)

vai para o estado sleep, evitando que um mesmo nodo se torne emissor continuamente.

A quarta fase ocorre após um nodo transmitir divulgações, por um determinado tempo, sem receber nenhuma requisição, assumindo assim que todos seus vizinhos possuem a mesma versão. O novo código é transferido da EEPROM para a memória de programa e o nodo reini-cializa.

Figura 3.11: Máquina de estados: MNP.

3.3.5 Infuse

Infuse é um protocolo de disseminação de dados baseado em uma comunicação sem coli-sões devido ao uso do MAC (Medium Access Control) TDMA (Time Division Multiple Access) [Arumugam 2004]. Suas escolhas de projeto são apresentadas na Figura 3.12.

Figura 3.12: Escolhas de projeto do Infuse.

Este protocolo requer que os nodos conheçam tanto a sua localização como a de seus vizi-nhos, classificando-os em predecessores e sucessores. Além disso, ele assume que as faixas de tempo TDMA são atribuídas através da estação base e que seja feita uma divisão justa entre os nodos. Assim um nodo ouve durante a faixa de tempo de seus predecessores para receber os dados e transmite durante a sua.

(35)

O processo de disseminação inicia quando a estação base envia uma mensagem broadcast start-download. Esta mensagem inclui o número da versão e sua quantidade de pacotes. Feito isto, a estação passa a transmitir os pacotes de dados, um por vez em sua faixa TDMA. Quando um nodo recebe a mensagem start-download ele se prepara para realizar a recepção e armaze-namento dos dados, e por fim, adiciona a mensagem em sua fila TDMA, transmitindo-a em sua faixa de tempo. Ao receber um pacote de dados, ele é armazenado na memória flash e depois adicionado na fila para transmissão. A Figura 3.13 apresenta a máquina de estados do Infuse.

Apesar do TDMA garantir que não há colisões, ainda assim é possível que um pacote seja perdido devido a ruídos no ambiente ou algum outro erro. Desta forma, o Infuse apresenta dois algoritmos para detecção de erros baseados no mecanismo de janelas deslizantes, são eles: go-back-n e selective retransmission. Para não ter que utilizar ACKs explícitos, a responsabilidade de detectar uma perda fica no emissor simplesmente fazendo com que ele ouça seus sucessores verificando se estão transmitindo determinado pacote e desta forma recebendo um ACK implí-cito. Entretanto, quando um nodo falhar, o emissor não receberá o ACK, então após enviar um número máximo de retransmissões o emissor declara o nodo como falho e passa a retransmitir pacotes apenas aos seus vizinhos ativos.

Para reduzir o consumo de energia, é utilizado o conceito de predecessores preferidos. Um nodo seleciona um predecessor do qual deseja receber pacotes perdidos e adicionam esta infor-mação ao enviar seus pacotes. Conhecendo esta inforinfor-mação, os predecessores não escolhidos passam a escutar por ACKs implícitos ocasionalmente, apenas para permitir uma recuperação caso o predecessor escolhido falhe.

(36)

3.3.6 Sprinkler

Sprinkler é um serviço de disseminação de dados projetado para ser energéticamente efi-ciente através da computação de um subconjunto de nodos emissores e do uso de TDMA [Naik et al. 2005]. Suas escolhas de projeto são apresentadas na Figura 3.14.

Figura 3.14: Escolhas de projeto do Sprinkler.

Assim como o Infuse, o Sprinkler também requer que os nodos saibam a sua localização. Além disto, este mecanismo assume que a distribuição dos nodos possua uma densidade mí-nima. Partindo destas duas premissas um CDS (Connected Dominating Set) é computado e sobre este conjunto são calculadas faixas de tempo para uma transmissão TDMA através do algoritmo de coloração D-2. É importante ressaltar que os algoritmos utilizados não fornecem a solução ótima, mas sim uma aproximação.

Cada nodo, independentemente de pertencer ao CDS ou não, seleciona o nodo do CDS mais perto de si como seu pai. Nodos pais são responsáveis por retransmitir pacotes perdidos e o objetivo desta seleção é distribuir o número de retransmissões de maneira uniforme entre os nodos do CDS. A disseminação é dividida em duas fases: Streaming, onde apenas os nodos pertencentes ao CDS transmitem pacotes e Recovering; sendo que cada fase utiliza uma política de retransmissão diferente. A Figura 3.15 apresenta a máquina de estados do Sprinkler.

Durante a primeira fase, Streaming, um nodo do CDS passa adiante todo novo pacote ou-vido. Ele adiciona um NACK para os pacotes perdidos e o id de seu pai ao transmitir um pacote de dados. Quando um nodo pai recebe um NACK, ele retransmite o pacote correspondente no seu próximo período de transmissão. Ao final desta fase todos os nodos do CDS terão recebido os dados completamente.

Somente os nodos que não receberam todos os dados ao fim da primeira fase entram na segunda. Para recuperar as perdas, um nodo envia uma requisição unicast ao seu pai contendo uma lista dos pacotes perdidos. Como nesta fase as mensagens podem ser enviadas tanto por nodos pertencentes ao CDS, responsáveis pelas retrasmissões de pacotes, quanto por nodos fora dele, responsáveis pelas requisições de pacotes, não se pode mais utilizar as faixas de tempo

(37)

TDMA. Desta forma, durante a segunda fase é utilizado um mecanismo RTS-CTS-DATA-ACK. Apesar do uso de um CDS diminuir a quantidade de nodos emissores, esta abordagem não distribui o uso de energia de forma igualitária entre os nodos da rede, uma vez que nodos pertencentes ao conjunto vão gastar mais energia do que os não pertencentes.

Figura 3.15: Máquina de estados: Sprinkler.

3.4 Comparação dos Protocolos Analisados

A Tabela 3.1 apresenta uma comparação entre as características dos protocolos analisados. Apenas Reijers et al. e Deluge possuem um mecanismo baseado em diferenças para disseminar os dados. Enquanto este apresenta o conceito de páginas e realmente envia apenas os dados que mudaram, aquele envia um edit script que é utilizado para editar a imagem binária já existente nos nodos. Como uma pequena mudança no código fonte pode causar um grande deslocamento nos dados binários, a abordagem de um edit script pode reduzir bastante a quantidade de dados a serem enviados, entretanto o mecanismo apresentado se utiliza de um conhecimento sobre o conjunto de instruções da arquitetura, tornando-se dependente da mesma.

A forma como os dados são disseminados também muda de acordo com o protocolo. MOAP, MNP e Deluge apresentam uma propagação que ocorre de vizinhança em vizinhança, entretanto ao contrário dos dois primeiros o Deluge não requer que um nodo receba os dados completamente para só depois passa-los adiante, desta forma explorando o conceito de multi-plexação espacial, permitindo que os dados sejam transmitidos paralelamente por toda a rede. Infuse e Sprinkler também exploram a multiplexação espacial. Todavia, como ambos são

(38)

base-ados em TDMA, sua disseminação não ocorre por vizinhanças, os dbase-ados vão passando sequen-cialmente por grupos de nodos predecessores e sucessores, mas para isso ambos exigem que os nodos saibam sua localização e o Sprinkler ainda requer uma densidade mínima na distribuição da rede, requisitos que restringem o uso desses protocolos.

O mecanismo para seleção de emissores é importante pois pode diminuir o número de colisões e o total de mensagens transmitidas. Apesar de MOAP, Deluge e MNP apresentarem interfaces divulga-inscreve, os dois primeiros só estão preocupados em diminuir o número de emissores existentes ao mesmo tempo em uma vizinhança, enquanto o MNP também leva em conta qual emissor causaria maior impacto. Além disso, o mecanismo para seleção de emissor do MNP não sofre do problema do terminal oculto ao contrário dos outros dois. Tanto Infuse quanto Sprinkler utilizam faixas de tempo TDMA para selecionar nodos emissores, porém o segundo ainda realiza a computação de um CDS diminuindo o número total de emissores. O Sprinkler ainda possui uma etapa onde as faixas de tempo TDMA não são utilizadas, ao invés disso, é empregada uma abordagem RTS-CTS.

Políticas de retransmissão são utilizadas para garantir a propriedade de confiabilidade do protocolo. MOAP, Deluge, MNP e a segunda fase do Sprinkler colocam a responsabilidade de detectar uma perda nos receptores e utilizam NACKs unicast para realizar pedidos de re-transmissões. Na primeira fase do Sprinkler os receptores adicionam um NACK nos pacotes de dados, não utilizando um pacote exclusivo para requisitar uma retransmissão. Já o Infuse responsabiliza nodos emissores por detectarem perdas, fazendo-os ouvir seus sucessores desta forma recebendo ACKs implícitos. Outra característica que vale mencionar é se retransmissões são realizadas na hora de sua detecção ou depois. MOAP, Deluge, Infuse se encaixam na pri-meira opção, enquanto MNP na segunda. O Sprinkler utiliza as duas, a pripri-meira para nodos pertencentes ao CDS, e a segunda para os não pertencentes.

Perdas são detectadas através da gerência de segmentos. MOAP, Infuse e Deluge utilizam o conceito de “janelamento”, todavia enquanto os dois primeiros usam mecanismos de janelas deslizantes, o Deluge utiliza um mapa de bits do tamanho de uma página. MNP e Sprinkler utilizam uma lista de pacotes perdidos.

Através de um mecanismo de atualização tardia nodos que foram desconectados, se recupe-raram de uma falha, ou que de alguma forma perderam a operação de disseminação, ainda assim possam receber os novos dados. Apenas MOAP e Deluge apresentam tal mecanismo. Para isso, eles fazem com que todos os nodos enviem mensagens divulgando suas versões periodicamente.

(39)

Tabela 3.1: Resumo dos protocolos estudados. Protocolo Baseado em diferenças Disseminação Seleção de emissor Multiple xação espacial Política de retransmissão Gerência de se gmentos Atualização tardia Reijers et al. sim ponto a ponto n/a n/a A CK n/a n/a MO AP não vizinhança em vizinhança di vulg a /inscre ve não unicast N A CK janela deslizante sim Deluge sim vizinhança em vizinhança di vulg a /inscre ve sim unicast N A CK mapa de bits sim MNP não vizinhança em vizinhança di vulg a /inscre ve não unicast N A CK lista encadeada não Infuse não predecessor /sucessor faixas de tempo TDMA sim A CK implicito janela deslizante não Sprinkler não predecessor /sucessor pai /filhos CDS & faixas de tempo TDMA RTS-CTS sim pacote + N A CK unicast N A CK lista não Tabela 3.2: Escolhas de projeto dos protocolos estudados (prioridade dada às propriedades). Protocolo Ener gia Latência M emória Reijers et al. 1 o 3 o 2 o MO AP 1 o 3 o 2 o Deluge 3 o 1 o 2 o MNP 2 o 3 o 1 o Infuse 1 o 2 o 3 o Sprinkler 1 o 2 o 3 o

(40)

4 Proposta

Este capítulo apresenta o protocolo de disseminação de dados para redes de sensores sem fio desenvolvido neste trabalho, com base no sistema operacional EPOS.

4.1 Escolhas de projeto

A seção 3.1 apresentou as propriedades que devem ser levadas em consideração ao se desen-volver um protocolo de disseminação. Confiabilidade e uniformidade são obrigatórias, portanto os mecanismos para garantir tais propriedades se fazem presentes. As outras propriedades en-tretanto, não garantem corretude e por isso dá-se preferência a umas em relação a outras, como mostra a Figura 4.1.

A propriedade não obrigatória considerada mais importante é a eficiência energética. To-das as operações realizaTo-das necessitam de energia e, considerando que os nodos MICA2 são alimentados por pilhas, há apenas uma quantidade finita disponível.

Depois priorizou-se o consumo de memória, visto que o protocolo de disseminação não é a aplicação principal do nodo, mas apenas um serviço oferecido pelo sistema operacional. Desta forma, não se deve limitar a quantidade de memória disponível para as aplicações.

Por fim, a latência. Ao priorizar o consumo de energia e memória, abriu-se mão de que o tempo necessário para realizar a disseminação seja curto.

(41)

4.2 Abordagem baseada em diferenças

A operação mais cara, em termos de consumo energético, é o uso do rádio e, em particular, a transmissão de dados (o rádio CC1000, presente nos nodos MICA2, consome 12mA no modo de transmissão e 4mA no modo de recepção). Outra operação que também possui consumo elevado de energia é a escrita na memória flash. Esta operação consome aproximadamente o equivalente a um oitavo da energia necessária para transmitir o mesmo número de bytes. Já a operação de leitura é mais economica, pois a maioria das memórias flash são otimizadas para leituras [Stathopoulos John Heidemann 2003].

Como todos os dados necessários para a atualização vão ser transmitidos, via rádio, e arma-zenados, na memória flash, pode-se concluir que diminuindo a quantidade de dados envolvidos no processo de disseminação, diminui-se a quantidade total de energia consumida.

4.2.1 Formato de arquivo Intel Hex

As aplicações desenvolvidas utilizando o EPOS são escritas na linguagem C++. Após a compilação do código fonte, é gerado um arquivo ELF. No caso do MICA2, este ELF é con-vertido para o formato Intel HEX (.hex) e carregado para o nodo sensor via ISP (In-System Programming).

O formato Intel HEX é uma representação em ASCII (American Standart Code for Infor-mation Interchange) do código binário [Intel Corporation], sendo que cada linha de um arquivo .hex contém bytes de dados do código binário mais informações para controle, como tipo do dado, tamanho, endereço na memória e checksum, Figura 4.2.

4.2.2 Geração de diferenças

Para a geração de diferenças compara-se o arquivo .hex do novo código com o antigo, linha por linha. Se duas linhas correspondentes são iguais, quer dizer que os dados naquele endereço de memória não foram alterados e, portanto, nenhum pacote é gerado. Desta forma, a criação de um pacote só ocorre quando linhas correspondentes não coincidirem, ou quando uma linha do novo código não tiver uma linha correspondente (quando há um crescimento no tamanho do código). Cada novo pacote contém um número único, o endereço base de seus dados, a quantidade de bytes no campo de dados, e os dados.

(42)

. . . :100000000C9454000E9480000E9480000E94800096 :100010000E9480000E9480000E9480000E94800058 :100020000E9480000E9480000E9480000E94800048 :10E1B000FF90EF90DF90CF90BF90AF909F908F90A7 :0EE1C0007F906F905F904F903F902F9008954A :00000001FF Byte size 1 1 2 1 n 1

Start code Byte count Address Record type Data Checksum

Figura 4.2: Formato do arquivo Intel HEX.

4.3 Disseminação

A utilização do MAC TDMA é interessante pois garante que não ocorram colisões durante a transmissão. Entretanto, para realizar uma disseminação utilizando TDMA, nodos devem manter informações, armazenadas na memória, sobre quem são seus predecessores e sucesso-res. Uma vez que RSSF são formadas por um grande número de nodos sensores, manter essas informações implica em um alto consumo de memória, o que não vai de acordo com a segunda escolha de projeto realizada. Além disso, a utilização de TDMA requer que uma nova atri-buição das faixas de tempo seja feita sempre que ocorra uma alteração na topologia da rede (inclusão/remoção de nodos ou mesmo a mudança de posição de nodos da rede), incluindo um sobrecusto para redes com nodos sensores móveis. Desta forma, optou-se por uma dissemina-ção que ocorre de vizinhança em vizinhança.

4.3.1 Multiplexação espacial

Outra característica da disseminação é possibilitar que os dados sejam transmitidos de forma paralela pela rede, diminuindo o tempo necessário para que todos os nodos recebam os dados. Todavia, isso aumenta a complexidade do protocolo, uma vez que os nodos podem tanto enviar quanto receber pacotes antes de possuirem todos os dados. Particularmente, em uma disseminação que ocorre por vizinhanças, essa característica possibilita a existência de vários emissores concorrentes na mesma vizinhança, aumentando o número de colisões e consequete-mente o número de retransmissões necessárias, implicando em um maior consumo de energia. Indo de acordo com as escolhas de projeto realizadas optou-se por não explorar o conceito de

(43)

multiplexação espacial, priorizando-se um menor consumo de energia em troca de uma latência maior.

4.4 Seleção de emissores

A seleção de emissores realizada se baseia no mecanismo apresentado pelo MNP, pois foi a única abordagem estudada que além de diminuir o número de colisões também tenta escolher o melhor emissor, desta forma, diminuindo o número total de transmissões a serem realizadas e consequentemente diminuindo a energia total gasta. As Figuras 4.3 e 4.4 apresentam as tarefas dos nodos emissores e receptores, respectivamente, nesta abordagem.

Broadcast an advertisement message every random interval. if a download request message arrives,

if it is destined to me,

if it is from a "new" requester, Increase ReqCtr by 1.

endif

else // the message is destined to some other node

if (ReqCtr value carried by this message is higher than my ReqCtr), or (ReqCtr value is equal to my ReqCtr, and DestID is higher than my node ID)

Stop advertising and go to "sleep" state. endif

endif endif

if an advertisement message arrives,

if ReqCtr value carried by this message is higher than my ReqCtr, Stop advertising and go to "sleep" state.

endif endif

Figura 4.3: Tarefas de um potencial emissor [Wang 2004].

if an advertisement message arrives if it is a "new" program,

Pepare download request message:

copy SourceID of advertisement message into DestID field; copy ReqCtr of advertisement message into ReqCtr field. Send download request message.

endif endif

Figura 4.4: Tarefas de um receptor [Wang 2004].

A Figura 4.5 apresenta uma RSSF de exemplo. Supondo que a disseminação comece pelo nodo A, os primeiros nodos a receberem os novos dados e tornarem-se potenciais emissores são

(44)

B e C. C é um melhor emissor que B neste caso, pois uma propagação a partir de C atinge o restante dos nodos da rede, desta maneira encerrando o processo de disseminação. Entretanto, o algoritmo apresentado pode falhar. Considerando que os nodos B e C, nesta ordem, enviaram mensagens de divulgação contendo o número da nova versão e suas variáveis ReqCtr (iguais a zero). O nodo E irá responder primeiro com os dados de B e só depois com os de C. Já os nodos D e F irão responder somente com os dados de C. Porém, caso C receba primeiro a mensagem de requisição vinda de E contendo os dados de B, ele vai verificar que sua ReqCtr é igual e se o id de B for maior que o seu irá para o estado sleep, sem nem ouvir D e F. Assim B torna-se o emissor, mesmo não sendo a melhor opção.

A B C F D E Figura 4.5: RSSF exemplo.

Para resolver esse problema basta adicionar uma condição a mais ao algoritmo dos poten-ciais emissores apresentado na Figura 4.3. Ao receber uma mensagem de requisição destinada a outro nodo, verifica-se se o valor de ReqCtr da mensagem é maior que zero, caso contrário a mensagem é ignorada. Com isso dá-se tempo para que ao menos uma “rodada” de divulgação e requisições seja realizada antes que algum nodo desista da competição.

4.5 Política de retransmissão

A política de retransmissão envolve questões como quem é o responsável por detectar per-das, como e quando são feitas as requisições por pacotes perdidos, e por fim, como são feitas as retransmissões de pacotes.

(45)

todos os seus receptores. Em contrapartida, um receptor só tem que manter informações de si mesmo e de quem é seu emissor.

Requisições broadcast possuem uma probabilidade maior de serem atendidas, já que todos os potenciais emissores na vizinhança irão recebê-las, entretanto isso pode causar um elevado número de respostas duplicadas caso um mecanismo de supressão não seja utilizado. Por outro lado, requisições unicast possuem um mecanismo de supressão implícito, porém menor pro-babilidade de serem atendidas, já que apenas um emissor irá recebê-las. Além disso caso o emissor em questão falhe, deve haver algum mecanismo que possibilite a um nodo recuperar pacotes a partir de outro emissor.

Uma requisição pode ser realizada assim que uma perda é detectada, desta forma interrom-pendo a sequência de transmissão do emissor, ou pode-se esperar que o emissor envie todos os pacotes para só depois requisitar pacotes perdidos.

Dados empíricos mostram que a maioria dos pacotes perdidos estão altamente correlaci-onados, ou seja, vários receptores perdem o mesmo conjunto de pacotes [Wang 2004]. Desta forma, retransmissões broadcast são mais econômicas, pois permitem que vários receptores recebam o pacote em questão, diminuindo o número de requisições realizadas.

Indo de acordo com as escolhas de projeto, escolheu-se responsabilizar os receptores por detectar perdas, realizar requisições unicast e utilizar retransmissões broadcast de pacotes. A decisão de quando requisitar um pacote perdido depende da gerência de segmentos utilizada, e portanto é descrita na próxima seção.

4.6 Gerência de segmentos

Esperar o fim da transmissão para só então realizar requisições, requer que informações sobre quais pacotes foram perdidos sejam mantidas em memória. Como este número pode ser grande, esta abordagem vai contra a propriedade de baixo consumo de memória. Dito isso, optou-se por utilizar o mecanismo de janelas deslizantes, desta forma, limitando a quantidade de informações que devem ser mantidas em memória para o tamanho da janela.

Segmentos recebidos devem ser armazenados. Os nodos MICA2 possuem apenas 4kB de SRAM e 4kB de EEPROM. Limitar o número de segmentos a esse valor limitaria a capacidade de atualização para algumas aplicações. Por isso, optou-se por dividir a memória flash em duas partes de 64kB cada, uma para o código da aplicação e a outra para armazenar os segmentos utilizados em uma atualização.

(46)

4.7 Atualização tardia

Para possibilitar a atualização tardia todos os nodos enviam mensagens de divulgação pe-riodicamente. Ao perceber uma inconsistência (receber uma mensagem contendo uma versão mais velha), um nodo divulga sua versão imediatamente.

4.8 Reinicialização

Após receber todos os pacotes um nodo torna-se um potencial emissor e passa a divulgar a nova versão. Caso não vire emissor o nodo atualiza sua memória de programa e reinicia executando o novo código.

Para possibilitar a escrita na memória de programa o código de escrita na flash foi colocado na seção BOOTLOADER_SECTION. Com a memória de programa atualizada o nodo deve rei-niciar, para isso foi implementado o método reboot no mediador da CPU da arquitetura AVR8.

4.9 Implementação

Para a implementação do empacotador foi desenvolvida uma aplicação em C++, sem rela-ção com o sistema operacional EPOS. Esta aplicação executa na máquina host sendo responsá-vel por gerar as diferenças entre as duas versões do código e empacotar esses dados. Terminada essa fase, os pacotes são passados a uma estação base através de uma porta serial. Essa estação base executa uma aplicação desenvolvida utilizando o EPOSe é a responsável por inicializar o processo de disseminação, enviando mensagens do tipo start download (S_DOWNLOAD).

O processo de disseminação do protocolo desenvolvido possui características semelhantes ao MOAP: vizinhança em vizinhança, divulga / inscreve, sem multiplexação espacial, requisi-ções unicast, janela deslizante e atualização tardia. Contudo, é mais eficiente, uma vez que seu mecanismo para seleção de nodos emissores é uma melhoria daquele apresentado pelo MNP. Além disso, a abordagem baseada em diferenças utilizada reduz a quantidade de dados a serem propagados. A Figura 4.6 apresenta a máquina de estados do protocolo.

O protocolo foi desenvolvido como um serviço do sistema operacional e portanto executa em uma thread própria, independente da aplicação, além disso seus dados são alocados na heap do sistema.

(47)

Figura 4.6: Máquina de estados do protocolo desenvolvido.

4.9.1 Configurabilidade

O EPOSutiliza o mesmo conceito de Traits presente na biblioteca padrão da linguagem C++ [Stroustrup 2000]. Traits são classes parametrizadas das quais atributos constantes e estáticos descrevem as propriedades de um determinado tipo [Fröhlich 2001]. Utilizando metaprograma-ção estática e inlining de funções, essas propriedades não adicionam nenhum sobrecusto para o código gerado [Gracioli 2009].

A Figura 4.7 apresenta as propriedades do protocolo que são configuradas via o Traits: o número da versão que está sendo executada; o tamanho da janela utilizada na gerência de segmentos e o intervalo que os nodos levam para enviar mensagens de divulgação.

// ...

template <> struct Traits<ATMega128_Common>: public Traits<void> {

static const bool reconfiguration = true; static const unsigned char node_id = 0x10; };

// ...

template <> struct Traits<Updater>: public Traits<void> {

static const unsigned char version = 0; static const unsigned int window_size = 13;

static const unsigned int advertise_period = 50000; };

// ...

(48)

O atributo reconfiguration é utilizado para habilitar ou desabilitar o uso do protocolo. Durante a inicialização das threads do sistema a thread do protocolo só será inicializada caso Traits<Machine>::reconfiguration possua um valor igual a true, Figura 4.8. Como este valor é uma constante esta verificação é realizada em tempo de compilação sem sobrecustos durante a execução.

// ...

// Creates the application's main thread

// It won't start running because reschedule will find prev == next new(kmalloc(sizeof(Thread))) Thread(entry, RUNNING, MAIN);

// ...

// Creates the system's updater thread if(Traits<Machine>::reconfiguration)

new(kmalloc(sizeof(Thread))) Thread(&Updater::start, READY, NORMAL, 512); // ...

Figura 4.8: Criação durante a inicialização das threads do sistema.

Todas as configurações envolvendo o protocolo são realizadas pelo Traits, tornando-o total-mente transparente para a aplicação.