IV SAISEE –SEMINÁRIO DE AUTOMAÇÃO INDUSTRIAL E SISTEMAS ELETRO-ELETRÔNICOS INSTITUTO NACIONAL DE TELECOMUNICAÇÕES –INATEL
ISSN2319-0280 MARÇO DE 2016
Resumo— Este trabalho apresenta um protocolo de descoberta e gerenciamento de rotas para Redes de Sensores Sem Fio (RSSF), com abordagem centralizada. Neste sistema, caberá a um Proxy Manager, através do protocolo proposto, encontrar possíveis rotas para Nós Sensores, tendo como base a RSSI (Received Signal Strenght Indication) dos enlaces de comunicação e o número de saltos entre os mesmos. Para implantação e apresentação da proposta, foram instalados cinco Nós Sensores em um ambiente predial. As rotas encontradas foram testadas através de solicitação persistente de dados para os Nós Sensores, sendo apresentada a PER dos mesmos. Como perspectiva futura, serão realizados testes envolvendo um número maior de Nós Sensores, bem como integrar o Proxy Manager a um Gerente de Rede, para que este possa parametrizar o protocolo e obter dados sumarizados da RSSF.
Palavras chave—Internet das Coisas, PER, RSSF, RSSI, Roteamento.
Abstract— This paper presents a discovery and management protocol for routes on Wireless Sensor Networks (WSN), with a centralized approach. In this system, a Proxy Manager finds possible routes to nodes based on the RSSI (Received Signal Strenght Indication) and the number of hops between them. For the implementation and presentation, five Nodes were installed in a built environment. The routes found were tested by persistent data request to the Nodes, when the PER was demonstrated. As a future development, tests involving a larger number of Nodes need to be done , as well as integrating a Proxy Manager to the Network Manager, so that it can parametrize the protocol and obtain summarized data from the WSN.
Keywords - Internet of Things, PER, RSSI, Routing, WSN.
I. INTRODUÇÃO
Redes de Sensores sem Fio (RSSF) são redes formadas por n Nós Sensores (NS) que cooperativamente monitoram grandezas físicas, tais como temperatura, luminosidade, pressão atmosférica, etc. Um NS é formado por um subsistema de sensoriamento, comunicação, processamento (processador e memória) e fornecimento de energia [1]. Estes subsistemas, devido ao tamanho reduzido do NS, são tipicamente limitados do ponto de vista de recursos, devendo ser utilizados da melhor maneira possível para atingir os resultados esperados.
Os dados coletados por um NS são enviados diretamente ou por intermédio de outros NS para um Nó Sorvedouro, enviando os mesmos uma rede externa (ex: TCP/IP) por
intermédio de um a um Gateway [2][3]. Um Gateway possui maior capacidade computacional e energética do que os NS. A interligação da RSSF com uma rede TCP/IP é ilustrada na Figura 1.
Fig. 1 – Interligação de uma RSSF com uma rede TCP/IP (Fonte: elaboração própria)
Embora possa promover conectividade entre a RSSF e outra rede, um gateway não é um elemento capaz de gerenciar os aspectos funcionais de uma RSSF, como hibernação dos NS, rotas, QoS, taxas de transmissão, etc.
A proposta deste trabalho é apresentar um protocolo para descoberta e gerenciamento de rotas em RSSF com abordagem flat pró ativa e gerenciamento centralizado, tendo como base para atribuição de custos a RSSI (Received Signal Strenght Indication) dos enlaces entre os NS e o número de saltos entre os mesmos. Caso alguma rota para determinado NS seja comprometida, uma nova rota será descoberta, caso essa exista. O protocolo é executado a partir do gateway, o qual passará a exercer a função de um Proxy Manager. Um Proxy Manager [4] é um elemento capaz de receber parâmetros relacionados à gerência de um Gerente de Rede e traduzi-los para um padrão específico, de forma que o elemento gerenciado possa compreendê-los. Sendo assim, os dados relacionados às rotas ficarão armazenadas exclusivamente no Proxy Manager, sendo transmitidos aos NS no momento da solicitação de dados. Esta abordagem permite que a complexidade seja concentrada no Proxy Manager, tornando os NS mais simples do ponto de vista de processamento e armazenamento.
O restante do trabalho é organizado da seguinte maneira: na sessão II, é apresentada uma revisão de conceitos necessários para a compreensão da proposta; na sessão III é detalhada a
Protocolo para gerenciamento de rotas em Redes de Sensores sem Fio
Rodolfo Francisco de Oliveira1, Dr. Omar C. Branquinho1, Pedro Chaves1 & Fernando Lino2 1 - Pontifícia Universidade Católica de Campinas
2 - Instituto Federal de Educação, Ciência e Tecnologia de São Paulo
proposta deste trabalho; na sessão IV é apresentado os materiais e métodos utilizados para implantação e testes da proposta; na sessão V é apresentado os resultados, e, por fim, na sessão VI as conclusões e perspectivas para futuros trabalhos.
II. REVISÃOBIBLIOGRÁFICA A. Gerenciamento em RSSF
O gerenciamento de uma rede pode ser definido em cinco áreas funcionais, definidas pela International Organization for Standardization (ISO) [4], a saber: falhas (detecção, isolação e correção de operações anormais), contagem (contabilização de recursos e custos vinculados aos mesmos), configuração (inicializar, desligar, manter, adicionar e atualizar componentes e configurações da rede), desempenho (monitorar e avaliar o comportamento dos objetos gerenciados) e segurança (proteção relacionada ao controle de acesso aos recursos da rede e proteção da informação). O processo de gerenciamento é realizado por um Gerente, que por sua vez gerencia diversos elementos gerenciados.
O gerenciamento de uma RSSF deve levar em consideração as características e restrições da mesma, as quais diferem de redes cabeadas e redes sem fio ad-hoc tradicionais. Em [11]
são listados os principais pontos a serem considerados:
operação leve (a fim de não consumir muito os recursos energéticos e computacionais dos NS), oferecer robustez e tolerância a falhas, ser adaptativo, ser escalável e armazenar o mínimo possível de dados nos NS.
Tendo como base [3] e [4], a arquitetura de gerenciamento pode ser:
Centralizada: Todo processo de gerenciamento parte de um Gerente (podendo ser realizada por intermédio de um Proxy Manager, quando o Gerente não se situa dentro da RSSF), e este analisa de forma centralizada os dados coletados da RSSF para tomada de decisões, incluindo a análise e escolha das melhores rotas. NS não participam do processo de gerência;
Distribuída: O processo de gerenciamento é distribuído nos NS que compõem a RSSF;
Hierarquia: O gerenciamento da rede é distribuído em diversos Cluster Heads, que por sua vez gerenciam uma parcela especifica da rede, denominada cluster.
Um NS Gerente por sua vez pode se reportar a outro NS Gerente de nível superior, até que se atinja uma NS Gerente Central;
B. Roteamento em RSSF
Entre os aspectos funcionais da RSSF que podem ser gerenciados, o roteamento exerce papel fundamental para a entrega de pacotes entre os NS e entre estes e o Nó Sorvedouro. O roteamento entre os NS se faz necessário, pois nem sempre o NS de origem está próximo o suficiente do Nó Sorvedouro para encaminhamento direto dos pacotes. Neste caso, a comunicação é realizada por NS intermediários, formando uma rede de múltiplos saltos.
Um NS pode desempenhar duas tarefas em uma rede de múltiplos saltos [3]:
Sensoriamento: Obter dados do ambiente através de um ou mais sensores e;
Roteamento: retransmitir dados gerados em um NS até que se atinja o PM;
Dentre os principais desafios [5] [6] para o desenvolvimento de protocolos de roteamento, pode-se citar:
Eficiência Energética, Distribuição dos NS, Modelo de entrega de dados, Funções desempenhadas pelos NS, Escalabilidade da RSSF, Robustez do protocolo e Topologia da RSSF.
Em [6] e [12] são apresentadas duas formas de classificação de protocolos de roteamento em RSSF. A primeira é baseada na estrutura da rede, enquanto a segunda é baseada na operação do protocolo. Para a compreensão do protocolo proposto neste trabalho, a seguir são apresentadas as classificações baseadas na estrutura de rede, bem como alguns exemplos de protocolos que trabalham com a mesma:
Flat: Todos os NS desempenham a mesma função, seja de sensoriamento, quanto de roteamento. Protocolos flat podem ainda ser subdivididos em [12]: pró ativos (a descoberta de rotas é realizada por troca periódica de dados entre os NS, sendo que cada um deles mantém sua própria tabela de roteamento, consultada antes de solicitar dados. Este processo leva a uma troca de pacotes mais rápida e eficiente, mas aumenta a troca de pacotes entre os NS. Ex: WRP, TBRPF), reativos (a descoberta de rotas é realizada somente quando necessário. Isto diminui consideravelmente a troca de pacotes, mas pode causar atrasos de entrega.
Exemplo: TORA, E-TORA, Gossiping, Flooding, RR) ou híbridos (combina as vantagens dos protocolos pró ativos e reativos, usando roteamento pró ativo em um dado grupo de NS, e reativos entre estes grupos . Ex: ZRP);
Hierárquico: Os NS são divididos em clusters. Em um dado cluster, cada NS envia pacotes diretamente para outro NS. Cada cluster possui um NS Cluster Head (CH), o qual é responsável pela comunicação do cluster com um CH de nível superior. Este por sua vez pode encaminhar pacotes para CH de mesmo nível ou superior, sucessivamente; (Ex: LEACH, LEACH-C, PEGASIS, TEEN);
Diversos Protocolos de roteamento para RSSF com abordagem flat foram propostos na literatura [5] [6]. A seguir, serão listados alguns exemplos semelhantes a este trabalho.
Wireless Routing Protocol (WRP) [7] mantém uma tabela em cada NS com dados atualizados da rede como distância, rotas, custo de link e retransmissão de mensagens. Atualizações dos dados são realizadas entre NS vizinhos, o que possibilita descobertas de novas rotas de maneira rápida. Topology Dissemination Based on Reverse-Path Forwarding Protocol (TBRPF) [8] utiliza o direção reversa (em direção ao Nó Sorvedouro) para encaminhar as atualizações de roteamento, usadas para calcular caminhos com o mínimo número de
saltos. Em ambos os protocolos, porém, é necessário que os NS possuam alto poder de processamento e armazenamento, aumentando a complexidade e consequentemente aumentando o custo final da RSSF. Sequential Assignment Routing (SAR) [9] introduz o conceito de QoS (Quality of Service – Qualidade de Serviço) avaliando os recursos energéticos dos NSs, QoS dos enlaces e prioridade de entrega dos pacotes, criando uma arvore de roteamento entre os NS para garantir múltiplas rotas. Minimum Cost Forwarding Algorithm (MCFA) [10] não utiliza tabelas para armazenamento de rotas nos NS, mas sim um custo estimado dele mesmo para o gateway. Um NS transmite um pacote através do processo de broadcast. Quando um NS recebe o pacote, verifica se está no caminho de menor custo. Em caso positivo, ele transmite o pacote, até que se atinja o gateway. A grande desvantagem deste protocolo é a grande quantidade de pacotes broadcast gerados, exaurindo os recursos dos NS.
III. PROPOSTA
A proposta deste trabalho é apresentar um protocolo para descoberta de rotas com abordagem flat pró ativo. O protocolo é executado a partir do gateway da RSSF, o qual passa a exercer a função de Proxy Manager (PM). A arquitetura de gerenciamento será centralizada, tendo como foco a área de gerência de configuração. Toda descoberta de rotas e solicitação de dados é realizada apenas a partir do PM.
O NS pode desempenhar duas funções: roteamento de pacotes ou coleta e envio de dados coletados para o PM, conforme solicitação deste. Um NS sabe qual das duas funções desempenhar tendo como base o endereço de destino final informado pelo PM (caso este seja igual ao do NS que recebê- lo, a sua função será coletar dados e enviá-los para o PM). No caso de execução da função de roteamento, o pacote é processado até a camada de rede. Já para solicitação de coleta de dados, será processado até a camada de aplicação. O PM intermedia e torna acessível os dados coletados pelos NS para uma rede com uma pilha de protocolos diferente (por exemplo, TCP/IP), bem como recebe parâmetros de configuração da RSSF. As camadas de rede implementadas por todos os elementos são mostradas na Figura 2. Na mesma, a comunicação entre o PM e o NS Final é intermediada por 2 NS.
Fig 2. Arquitetura de Camadas da Proposta (fonte: elaboração própria)
A seguir, será detalhado o funcionamento do protocolo de gerenciamento proposto neste trabalho.
Primeiramente, o PM é parametrizado com os seguintes dados:
Endereços dos NS que compõem a RSSF;
Limite máximo de saltos permitidos na RSSF (N);
Quantidade de pacotes enviados para o NS no momento de descoberta de rota (M);
Custo de um enlace com RSSI limiar (K). NS com Rota de enlaces com um RSSI igual ou superior a K não passarão pelo processo de descoberta de novas rotas. Quanto menor for o valor, maior será a probabilidade de o protocolo encontrar rotas com enlaces com RSSI maiores. Em contrapartida, quanto maior for seu valor menor será o tempo para estabelecimento das rotas;
Custo de um único salto entre os NS (Y). Rotas com vários saltos tenderão a ter um custo maior. A transmissão de um pacote para um dado NS com i saltos consumirá os recursos de i-1 NS;
Tabela de classificação para RSSI.
Tendo estes parâmetros, o PM, através do protocolo de roteamento, descobrirá as rotas para os NS entre 1 e N turnos, sendo N o valor máximo de saltos permitidos na RSSF, a partir do PM. Em um dado turno t, somente será realizado tentativas de descoberta de rotas para NS por intermédio de outros NS com rotas já descobertas com t-1 saltos. O PM enviará M pacotes de descoberta para um determinado NS. Dos pacotes recebidos como resposta, será escolhido aquele com a menor RSSI obtida. Caso o NS responda com um pacote de retorno de rota, o PM irá cadastrar a rota para o mesmo através dos seguintes dados:
Rota: endereço dos nós intermediários e do NS em questão, sendo este cadastrado por ultimo;
Número de Saltos: número de saltos para o NS em questão, sendo que este deve ser sempre menor ou igual a N;
Custo: Será calculado conforme Equação 1:
C(z-1)Y+Ci+Ce (1) Na qual C é o custo para o nó em questão; z é o número de saltos para o NS; Y é o custo referente a um salto; Ci é o custo da rota do último NS intermediário (caso este exista) e Ce é o custo da RSSI medido no último enlace, obtido comparando a mesma com a tabela de classificação de RSSI para enlaces, entre o NS intermediário (ou PM, no caso do destino ser de 1 salto) e o NS de destino. A Tabela 1 demonstra um possível exemplo de classificação, baseada em [13].
TABELAI
EXEMPLO DE CLASSIFICAÇÃO DE RSSI (ADAPTADO DE [13])
RSSI Legenda Custo
> -50 dBm Excelente 1
Entre -50 dBm e -59,99 dBm Ótimo 2 Entre -60 dBm e -69,99 dBm Bom 4 Entre -70 dBm e -79,99 dBm Regular 8 Entre -80 dBm e -89,99 dBm Ruim 16
< -90 dBm Péssimo 32
Rotas descobertas no primeiro turno (número de saltos atual igual a 1) terão custo igual a Ce. Após o término deste, quatro possibilidades podem ocorrer:
1º possibilidade: nenhuma rota foi descoberta;
2º possibilidade: rotas para todos os NS foram descobertas, e o custo das mesmas é igual ou inferior a Ca (indicada na Equação 2):
Ca=(z-1)Y+zK (2) na qual z é o número de saltos atual, Y o custo referente ao número de saltos e K o custo limiar do enlace;
3º possibilidade: rotas para todos os NS foram descobertas, na qual ao menos uma possui um custo superior à K;
4º possibilidade: rotas para um número parcial de NS foram descobertas.
Caso a 1º ou 2º possibilidade ocorrer, o protocolo de roteamento encerrará suas atividades. No caso de ocorrência da 3º ou da 4º, o número de saltos atual será incrementado em 1, entrando no segundo turno. A partir deste, até o último turno, o PM irá realizar tentativas de descoberta de rota por intermédio de todos os NS com rota cadastrada com número de saltos z-1, sendo z o número de saltos atual, para todos os NS que ainda não foram descobertos, ou que não possuam rota onde a RSSI recebida nos enlaces obteve um custo igual ou inferior a K. Caso uma rota alternativa seja encontrada para um NS com rota já cadastrada, esta será substituída caso aquela possua um custo inferior. Caso nenhuma rota seja descoberta em determinado turno, o protocolo encerrará as atividades.
A Tabela II ilustra um possível resultado de rotas descobertas para um exemplo de cenário com 4 NS, baseado em um cenário fictício da Figura 3, onde o peso de um salto é igual a 1 e os dados para classificação do RSSI utilizados estão na Tabela I.
TABELAII ROTASCADASTRADAS Endereço
NS Rota Saltos Custo
1 2,1 2 5
2 2 1 1
3 2,1,3 3 9
4 4 1 1
Fig 3. RSSF com 4 NSs e a RSSI dos enlaces (fonte: elaboração própria)
IV. MATERIAISEMÉTODOS
Para implementação do protocolo proposto, foram utilizados 5 NS DK-101 da plataforma Radiuino [14]. O Radiuino é uma extensão da plataforma Arduino, o qual agrega a este funcionalidades de uma RSSF. As funcionalidades do Nó Sorvedouro e do PM foram implementadas em um Single Board Computer BeagleBone Black, com o sistema operacional Ubuntu Linux instalado. As funções do protocolo de roteamento do PM foram implementadas em um script utilizando a linguagem de programação Python. Tanto os NS quanto o Nó Sorvedouro utilizam módulos de rádio BE-900, que atende as regulamentações da ANATEL e FCC. O mesmo trabalha na faixa de frequência de 902-907,5MHz e 915-928MHz, utiliza a modulação 2FSK e possui taxa de transmissão de até 250 Kbps [15]. Tanto o PM quanto os NS foram instalados em um prédio localizado no conjunto laboratorial CEATEC da PUC Campinas. A distância dos NS em relação ao Nó Sorvedouro / Gateway é mostrada na Tabela III.
TABELAIII
DISTÂNCIAENTREOSNSEONÓSORVEDOURO NS Distância
(em metros)
1 3
2 16
3 12
4 19
5 29
Para transmissão dos dados referente ao roteamento, foram utilizados ao todo 15 bytes dos 52 disponíveis no pacote original do Radiuino, onde cada byte representa um campo. Os mesmos são detalhados a seguir;
Byte 08: endereço do próximo NS ou PM a ser enviado o pacote;
Byte 10: endereço do NS ou PM que está enviando o pacote;
Byte 11: flag que indica qual o tipo de pacote. Este pode ser de 4 tipos, conforme Tabela IV;
TABELAIV
FLAGSPARATIPOSDEPACOTES Flag (valor em
decimal) Descrição
128 Solicitação de rota 64 Resposta de rota 254 Solicitação de dados 255 Resposta de dados
Byte 22: endereço do NS o qual a rota está sendo descoberta;
Byte 23: número máximo de saltos permitido;
Byte 24: número atual de saltos;
Byte 25: endereço do NS que está conectado ao NS especificado no byte 22;
Byte 26: RSSI de download do último enlace, o qual o NS especificado no byte 22 está conectado;
Byte 27: RSSI de upload do último enlace, o qual o NS especificado no byte 22 está conectado;
Byte 28 até Byte 33: armazenamento da rota para o NS final, onde cada byte armazena um endereço.
Os parâmetros passados ao PM foram informados manualmente em tempo de execução do script. Os seguintes parâmetros foram utilizados:
Endereços dos NS que compõem a RSSF: foram informados os 5 endereços dos NS utilizados nos testes (1,2,3,4 e 5);
Limite máximo de saltos permitidos na RSSF: devido a quantidade de NS utilizadas durante os testes, o número de saltos foi estabelecido como 5, prevendo- se assim um cenário onde um dos NS estiver a um alcance de 5 saltos de distância do PM;
Quantidade de pacotes enviados para o NS no momento de descoberta de rota: foram enviados 3 pacotes de descoberta de rotas para cada NS;
Custo limiar para enlaces: a fim de tentar obter rotas com enlaces com um alto nível de RSSI, o custo limiar para os enlaces foi configurado como 2;
Custo de um único salto: cada NS utilizado como roteador acrescentará 1 ao custo da rota;
Tabela de Classificação de RSSI para enlaces: para classificação dos enlaces, foram utilizados os dados contidos na Tabela 1. Os custos foram dispostos de forma a priorizar enlaces com RSSI maior.
A fim de demonstrar a execução do protocolo, foram enviados mil pacotes de solicitação de dados para cada NS em cinco testes consecutivos de descoberta de rotas.
V. RESULTADOS
As árvores de escoamento geradas pelo protocolo nos cinco testes são mostradas na Figura 4.
Fig 4. Árvores de escoamento geradas pelo protocolo (fonte: elaboração própria)
A distribuição de cada uma nos testes foi dada da seguinte forma:
1º Teste: Figura 4(a);
2º Teste: Figura 4(b);
3º, 4º e 5º Teste: Figura 5(c).
A diferença entre as rotas encontradas está relacionada aos NS de número 4 e 5, localizados com maior distância do Nó Sorvedouro. A tabela V mostra os custos das rotas para cada NS nos cinco testes realizados.
TABELAV
CUSTODASROTASENCONTRADAS ROTA
PARANS:
TESTES
1º 2º 3º 4º 5º
1 2 2 2 2 2
2 7 7 7 7 7
3 2 2 2 2 2
4 5 7 5 7 5
5 19 8 10 10 10
A Tabela VI apresenta a PER relacionada ao envio de 1000 pacotes de solicitação de dados, realizados após cada teste de descoberta. Ao analisar a mesma, é possível inferir que, durante os testes realizados, o número de saltos não afetou de forma significativa o desempenho do protocolo de roteamento, pois o NS 5, que estava a uma distância de 3 saltos do Nó Sorvedouro em 4 testes, obteve um melhor resultado do que o NS 4, que estava somente a 2 saltos.
TABELAVI PER–TESTEDASROTAS
NS EXECUÇÃO
1º 2º 3º 4º 5º
1 0,3% 0,6% 0% 0,2% 0,1%
2 0,6% 0,5% 1,2% 1% 1%
3 0% 0,2% 0,1% 0,1% 0,2%
4 20,1% 26,5% 15,9% 33,6% 0,4%
5 10,7% 25,7% 2,6% 2% 2,4%
No entanto, é possível observar que a rota para o NS 4 obteve uma PER alta em quatro dos cinco testes, bem como a do NS 5 em dois, se comparados aos demais NS. Um maior número de testes é necessário para inferir se os valores obtidos são persistentes ou pontuais.
VI. CONCLUSÕES
Este trabalho apresentou um novo protocolo para descoberta e manutenção de rotas em RSSF, com abordagem flat pró ativa. A execução deste protocolo coube a um Proxy Manager, que complementa a função do gateway da RSSF. O Proxy Manager implementa a função de gerência de configuração no que tange a roteamento. Foram realizadas cinco execuções consecutivas do protocolo, sendo enviados 1000 pacotes para coleta de coleta de dados aos NS através das rotas descobertas, tendo como objetivo apresentar o funcionamento do protocolo e obter a PER das mesmas. Com os resultados. foi possível aferir que durante os testes realizados o número de saltos não afetou de forma significativa o protocolo de roteamento. No entanto, os dois NS mais distantes fisicamente do Nó Sorvedouro apresentaram rotas
com uma PER alta (quatro e dois dos cinco testes realizados, respectivamente) se comparada aos demais NS. Um número maior de testes deve ser realizado para avaliar a persistência destes valores. O envolvimento e análise de outros parâmetros, como a LQI (Link Quality Indicator), também devem ser realizados.
Como perspectiva futura, propõe-se testes com o protocolo em uma RSSF com um número maior de NS e saltos. As áreas de gerência de desempenho e falhas também devem ser implementadas, possibilitando ao Proxy Manager analisar continuamente o comportamento do roteamento e responder a instabilidades de forma dinâmica e em tempo de execução.
REFERÊNCIAS
[1] W. DARGIE, C. POELLABAUR, Fundamentals of Wireless Sensor Networks: Theory and Practice, John Wiley & Sons, 2010.
[2] P. Rawat, K. D. Singh, H. Chaouchi and J. M. Bonnin "Wireless sensor networks: A survey on recent developments and potential synergies", J.
Supercomput., vol. 68, no. 1, pp.1 -48, 2014
[3] I. AKYILDIZ, C. V. MEHMET, Wireless Sensor Networks, John Wiley & Sons, 2010.
[4] W. STALLINGS, SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, Addison – Wesley, 1998.
[5] M. PATIL, R. C. BIRADAR, “A survey on routing protocols in Wireless Sensor Networks”, Networks (ICON), 2012 18th IEEE International Conference on, Singapure, pp 86-91, 2012
[6] J. Al-Karaki, A. Kamal, “Routing techniques in wireless sensor networks: A survey”, IEEE Wireless Communications Magazine, vol 11. No 6, Dec. 2004, pp. 6-28
[7] S. Murphy, L. Aceves, “An Efficient Routing Protocol for Wireless Networks” Mobile Networks and Applications, ACM Journal, USA, Hingham, 1996, Vol. 1, Issue 2, pp 183-197
[8] F. Ye et al, “A Scalable Solution to Minimum Cost Forwarding in Large Sensor Networks”, Proc 10th Int’l. Conf. Comp. Commun. And Networks,2001, pp 304-309.
[9] R. Orgier, F. Templin, M. Lewis, “Topology Dissemination Base don Reverse-Path Forwarding (TBRPF)” RFC Editor 2004.
[10] K. SOHRABI, J. POTTIE, “Protocols for self-organization of a wireless sensor network”, IEEE Personal Communications, Volume 7, Issue 5, pp 16-27, 2000.
[11] W. L. LEE, A. DATTA, R. CARDELL-OLIVER, “Network Management in Wireless Sensor Networks”, Handbook of Mobile Ad Hoc and Pervasive Communication, American Scientif Publishers, 2006.
[12] N. A. Pantazis, S. A. Nikolidakis and D. D. Vergados "Energy-efficient routing protocols in wireless sensor networks: A survey", IEEE Commun. Surveys Tuts., vol. 15, no. 2, pp.551 -591, 2013.
[13] C. R. REAL, “Medida e análise de comportamento da RSSI de uma rede de sensor sem fio em ambiente industrial” - Campinas: PUC-Campinas, 2015.
[14] “História do Radiuino”. Disponível em: <http://radiuino.cc> (Acessado em 23 de novembro de 2015).
[15] “BE-900 – Módulo de comunicação sem fio” Disponível em:
<http://radioit.com.br/wp-content/uploads/2015/06/BE900-Datasheet- v1.5.pdf> (Acessado em 23 de novembro de 2015).
