Uma Simulação Do Protocolo de Difusão Direta para Redes de Sensores Sem Fio

CENTRO UNIVERSITRIO DA BAHIA FACULDADE DE CINCIAS EXATAS E TECNOLOGIA BACHARELADO EM CINCIA DA COMPUTAO
GILDSIO ANTONIO DE OLIVEIRA JNIOR
UMA SIMULAO DO PROTOCOLO DE DIFUSO DIRETA PARA REDES DE SENSORES SEM FIO
Salvador 2009
Monografia apresentada ao Curso de Bacharelado em Cincia da Computao da Faculdade de Cincias Exatas e Tecnologia, Centro Universitrio da Bahia, como requisito parcial para obteno do grau de Bacharel em Cincia da Computao. Orientador: Prof. Othon Marcelo Nunes Batista.
Salvador 2009
TERMO DE APROVAO
Monografia aprovada como requisito parcial para obteno do grau de Bacharel em Cincia da Computao, Centro Universitrio da Bahia, pela seguinte banca examinadora:
Orientador:
Othon Marcelo Nunes Batista Mestre em Informtica Centro Universitrio da Bahia Examinador 1:
Roberto Luiz Souza Monteiro Mestre em Modelagem Computacional Centro Universitrio da Bahia Examinador 2:
Carlos Frederico Jansen Muakad Especialista em Rede de Computadores Centro Universitrio da Bahia
Salvador, 25 de Junho de 2009
A Deus, aos meus pais e aos pesquisadores deste pas que, apesar das dificuldades continuam trilhando esse caminho.
AGRADECIMENTOS
Agradeo primeiramente a Deus por me ajudar nos momentos difceis e me mostrar novas oportunidades que contribuiro para o meu crescimento pessoal e profissional. Aos meus pais pela boa formao e educao. A famlia e amigos pelo apoio e incentivo. Agradeo ao meu professor e orientador Othon Marcelo Nunes Batista pelas idias, ensinamentos, dedicao e exemplo. Agradeo aos pesquisadores deste pas que de certa forma contriburam para realizao deste trabalho.
O propsito do aprendizado crescer, e nossas mentes, diferentes de nossos corpos, podem continuar crescendo enquanto continuamos a viver. Mortimer Adler
RESUMO
Atualmente uma das comunicaes mais empregadas no mundo a wireless e inserida neste contexto tem-se as Redes de Sensores Sem Fio (RSSF). Uma RSSF pode ser utilizada em diversas aplicaes que vai desde coletar dados do meio ambiente at aplicaes militares. Este trabalho tem como objetivo instalar e configurar uma ferramenta de simulao, chamada Castalia e atravs dela implementar um mdulo de aplicao de Difuso Direta para realizar simulaes, mostrando atravs de grafos o comportamento deste protocolo em uma RSSF. Palavras Chave: RSSF, Castalia, Simulaes, Difuso Direta.
LISTA DE FIGURAS
Figura 1. Aplicabilidade das Redes Sensores. ..........................................................15 Figura 2. Tipos de Redes Sem Fio............................................................................17 Figura 3. Sensores para detectar militares/viaturas. .................................................18 Figura 4. Sensores fazendo a integrao dos componentes da casa. ......................18 Figura 5. Sensor utilizado para monitorar desempenho de atletas. ..........................19 Figura 6. Clusterizao de ns sensores. .................................................................20 Figura 7. Transmisso multi-hop. ..............................................................................22 Figura 8. Formao em blocos de um n sensor. .....................................................23 Figura 9. Dispositivos ns sensores..........................................................................24 Figura 10. Rede RSSF com n gateway. ..................................................................24 Figura 11. Componentes de um n sensor sem fio...................................................25 Figura 12. Diagrama de radiao de uma antena isotrpica ideal. ...........................33 Figura 13. RSSI e heurstica CCA.............................................................................35 Figura 14. Diviso de roteamento em uma RSSF. ....................................................38 Figura 15. Exemplo de Difuso Direta.......................................................................38 Figura 16. Funcionamento do PEGASIS...................................................................40 Figura 17. Exemplo de depurao com o front-end XATDB. ....................................47 Figura 18. Interface grfica do TKENV......................................................................48 Figura 19. Conexes dos mdulos no Castalia. ........................................................50 Figura 20. Composio do mdulo de um n............................................................51 Figura 21. Mensagem exibida quando executado o script runValProp. .................55 Figura 22. Primeiras linhas do arquivo Castalia-Primary-Output.txt. .........................55 Figura 23. Parmetro que vincula o sistema Castalia. ..............................................60 Figura 24. Linha que contm a seo global SN.NODE. ..........................................60 Figura 25. Linha adicionada seo global SN.NODE.............................................61
Figura 26. Ns que se comunicaram e no se comunicaram com a BS. ..................64 Figura 27. Ns que conseguiram se comunicar com a BS........................................65 Figura 28. Ns que no se comunicaram com a BS. ................................................65 Figura 29. Ns que se comunicaram e no se comunicaram com a BS. ..................66 Figura 32. Ns que se comunicaram e no se comunicaram com a BS. ..................68
LISTA DE QUADROS
Quadro 1: Diferentes fontes energticas...................................................................26 Quadro 2: Transceptores e suas caractersticas. ......................................................27 Quadro 3: Consumo do Mica Motes2........................................................................27 Quadro 4: Protocolos para RSSF..............................................................................32 Quadro 5: Distribuies utilizadas no ambiente operacional.....................................52
LISTA DE SIGLAS E ABREVIATURAS

A/D ASK ATEMU BEB B-MAC BS CCA CCR CODA CPU CSMA/CA D-MAC DoS DSSS ESRT FDMA FSK LEACH LoS MAC MEMS NACK NED NS-2 OFDM Conversor Analgico Digital Amplitude Shift Keying ATmel EMUlator Binary Exponential Backoff Berkeley MAC Base Station Clear Channel Assessment Corner Cube Reflector Cluster-based sef-Organining Data Aggregation Unidade Central de Processamento Carrier Sense Multiple Access with Collision Avoidance Distributed Energy aware MAC Denial of Service Direct Sequence Spread Spectrum Event-to-Sink Reliable Transfer Frequency Division Multiple Access Frequency Shift Keying Low-Energy Adaptive Clustering Hierarchy Line of Sight Medium Access Control Micro Electro-Mecanical Systems Negative Acknowledgement Network Definition Network Simulator Orthogonal Frequency Division Multiplexing
PEGASIS PSFQ QBN RAM RF RMST RSSF RSSI SDMA SMP S-MAC SQDDP SQTL TADAP TDMA TOSSIM WLAN XML
Power-Efficient Gathering in Sensor Information Systems Pump Slowly, Fetch Quickly Material Qumico, Biolgico e Nuclear Random Access Memory Rdio Freqncia Reliable Multi-Segment Transport Redes de Sensores Sem Fio Received Signal Strenght Indicator Space Division Multiple Access Sensor Management Protocol Sensor-MAC Sensor Query and Data Dissemination Protocol Query and Task Language Task Assignment and Data Advertisement Protocol Time Division Multiple Access The TinyOS Simulator Wireless Local Access Network Extensible Markup Language
SUMRIO
INTRODUO ..........................................................................................................15 1. REDES DE SENSORES .......................................................................................17 1.1. EXEMPLOS DE APLICAES ......................................................................17 1.2. DISTRIBUIO DOS NS SENSORES ........................................................19 1.3. CONSUMO DE ENERGIA ..............................................................................19 2. ELEMENTOS DE UMA REDE DE SENSORES SEM FIO ....................................22 2.1. NS SENSORES ...........................................................................................22 2.2. NS DE ROTEAMENTO (NS GATEWAY)..................................................24 3. DIAGRAMA DE BLOCOS DE UM N SENSOR COM OS MODULOS ................25 3.1. UNIDADE DE ENERGIA.................................................................................25 3.2. UNIDADE DE COMUNICAO......................................................................26 3.3. UNIDADE DE SENSORIAMENTO .................................................................28 3.4. UNIDADE DE COMPUTAO .......................................................................28 4. CLASSIFICAO DE REDES DE SENSORES SEM FIO ....................................29 4.1. CONFIGURAO...........................................................................................29 4.2. SENSORIAMENTO ........................................................................................30 4.3. COMUNICAO.............................................................................................30 4.4. PROCESSAMENTO .......................................................................................31 5. PROTOCOLOS PARA REDES DE SENSORES SEM FIO...................................32 5.1. CAMADA FSICA ............................................................................................32 5.1.1. Comunicao ptica.................................................................................32 5.1.2. Comunicao Rdio Freqncia (RF) ......................................................33 5.1.3. Comunicao infravermelha.....................................................................34 5.2. CAMADA DE ENLACE ...................................................................................34 5.2.1. Protocolo B-MAC......................................................................................35 5.2.2. Protocolo S-MAC......................................................................................36 5.2.3. Protocolo D-MAC .....................................................................................36 5.3. CAMADA DE REDE........................................................................................37 5.3.1. Protocolo de Difuso Direta .....................................................................38 5.3.2. Protocolo SPIN.........................................................................................38 5.3.3. Protocolo LEACH .....................................................................................39 5.3.4. Protocolo PEGASIS .................................................................................39 5.3.5. Protocolo CODA.......................................................................................40
5.4. CAMADA DE TRANSPORTE .........................................................................41 5.4.1. Protocolo PSFQ .......................................................................................41 5.4.2. Protocolo ESRT .......................................................................................42 5.4.3. Protocolo RMST.......................................................................................42 5.5. CAMADA DE APLICAO .............................................................................43 5.5.1. Protocolo SMP .........................................................................................43 5.5.2. Protocolo TADAP .....................................................................................44 5.5.3. Protocolo SQDDP ....................................................................................44 6. SIMULADORES ....................................................................................................45 6.1. TOSSIM ..........................................................................................................45 6.2. NS-2................................................................................................................46 6.3. ATEMU ...........................................................................................................46 6.4. OMNeT++ .......................................................................................................47 7. CASTALIA .............................................................................................................49 7.1. ESTRUTURA DO CASTALIA .........................................................................49 7.2. INSTALAO DO OMNeT++ .........................................................................52 7.3. INSTALAO DO CASTALIA ........................................................................53 7.4. EXECUTANDO UM TESTE DE SIMULAO ................................................54 8. MODIFICAO E DEFINIO DO ALGORITMO ................................................56 8.1. ESTRUTURA E FUNCIONAMENTO DO MODELO DE APLICAO............56 8.1.1. Macros .....................................................................................................56 8.1.2. Mdulo de inicializao ............................................................................57 8.1.3. Mtodo handleMessage ...........................................................................58 8.1.4. Mdulo de finalizao...............................................................................58 8.2. DEFININDO UM NOVO MDULO .................................................................59 8.3. MODIFICANDO O ALGORITMO ....................................................................59 8.4. DEFININDO OS PARAMETROS UTILIZADOS PELO CASTALIA .................61 9. SIMULAES E TESTES COM DIFUSO DIRETA ............................................63 9.1. SIMULAO 1................................................................................................63 9.2. SIMULAO 2................................................................................................66 9.3. SIMULAO 3................................................................................................67 CONSIDERAES...................................................................................................69 REFERNCIAS.........................................................................................................71 ANEXO A Arquivo DifusaoDireta_ApplicationModule.cc ........................................75 ANEXO B Arquivo omnetpp.ini ...............................................................................80
15
INTRODUO
Atualmente h um crescente desejo da humanidade pela busca de informao cada vez mais rpida. Conforme Pereira (2003), na computao mvel desejvel obter acesso contnuo s informaes atravs de uma comunicao sem fio. Devido grande capacidade de realizar monitoramento e coleta de informaes em ambientes diversos, fica inserida neste contexto, as Redes de Sensores Sem Fio (RSSF), na qual representam uma grande plataforma computacional. De acordo com Loureiro (2002), Redes de Sensores Sem Fio (RSSF) tm sido viabilizada pela rpida convergncia de trs tecnologias: microprocessadores, comunicao sem fio e Micro Sistemas Eletro-Mecnico (MEMS Micro ElectroMecanical Systems). Uma RSSF composta por vrios ns sensores densamente espalhados onde possui baixa limitao de energia, largura de banda para comunicao, capacidade de processamento e quantidade de memria. Um n formado basicamente por: unidade de sensoriamento (sensor), memria,
processador, bateria e transceptor Rdio Freqncia (RF). Podemos ainda dizer que de acordo com sua composio os ns podem operar sozinhos ou formar uma rede com o objetivo de coletar informaes individuais para monitorar um fenmeno.
Figura 1. Aplicabilidade das Redes Sensores. Fonte: JNIOR (2004, p. 1).
16
O objetivo principal deste trabalho mostrar atravs de grafos o comportamento de uma RSSF utilizado o protocolo de Difuso Direta. O primeiro objetivo entender o funcionamento do sistema de simulao de eventos discretos OMNeT++ e a estrutura do simulador Castalia. Em seguida, pretende-se fazer a instalao e configurao do OMNeT++ e do simulador Castalia no Sistema Operacional Debian Etch 4 GNU/Linux. O terceiro objetivo entender a estrutura e funcionamento do modelo de aplicao existente no Castalia para implementar um mdulo de aplicao de Difuso Direta. Em seguida, definir o tamanho do ambiente a ser monitorado e a quantidade de ns sensores depositados nesse ambiente. Aps isso, procura-se analisar o
desempenho da rede com simulaes e mostrar atravs de grafos o comportamento de uma RSSF utilizando o protocolo de Difuso Direta. Este trabalho est organizado em nove captulos. O captulo 1 apresenta caractersticas de uma RSSF como aplicao, distribuio e consumo de energia dos ns sensores. No captulo 2 mostramos os principais elementos de uma RSSF. O captulo 3 apresenta os conceitos bsicos da composio de um n sensor. No captulo 4, as RSSF podem ser classificadas segundo sua configurao, o sensoriamento, o tipo de comunicao, e inclusive o tipo de processamento que executa. O captulo 5 define a organizao dos protocolos utilizados pelos ns. O captulo 6 apresenta algumas ferramentas utilizadas para realizar simulaes. O captulo 7 mostra a estrutura do Castalia, a sua instalao e configurao no Sistema Operacional Debian Etch 4 GNU/Linux. O captulo 8 define e modifica um novo mdulo de aplicao. Por fim, no captulo 9 so feitas trs simulaes com o protocolo de Difuso Direta.
17
1. REDES DE SENSORES
Redes de Sensores Sem Fio so diferentes em diversos aspectos de uma rede tradicional, pois a comunicao de uma rede tradicional feita atravs de uma estao base, enquanto que em uma rede mvel com sensores os ns trocam dados entre si (figura 2).
(a) Rede com infra-estrutura
(b) Rede sem infra-estrutura
Figura 2. Tipos de Redes Sem Fio. Fonte: LOUREIRO (2004, p. 3).
1.1. EXEMPLOS DE APLICAES

Com o crescimento rpido das RSSF, diversas aplicaes tm sido desenvolvidas nas mais diferentes reas. Cada rede tem um tipo de configurao especfica, que de acordo com a sua aplicao pode ser homognea ou heterogenia. Uma abordagem sucinta de tais aplicabilidades para que se tenha uma noo do crescimento do mercado de RSSF so: trfego: Para monitoramento de veculos em rodovias obtendo parmetros como densidade de trfego; energia, gs e gua: monitoramento de linhas de distribuio de energia, gs e gua, obtendo parmetros como fluxo, presso e nvel; petrleo e gs: monitoramento da extrao de petrleo e gs, geralmente em plataformas de alto-mar na indstria petrolfera. Ainda neste setor, h a
18
utilizao de RSSF para proteo catdica em oleodutos, polidutos e gasodutos; militar: para detectar presena inimiga, campos minados, Material Qumico, Biolgico e Nuclear (QBN). Nesta aplicao os dados so criptografados e submetidos assinatura digital (figura 3);
Figura 3. Sensores para detectar militares/viaturas. Fonte: http://web.tagus.ist.utl.pt/~rafael.aranha/WSN/
automao residencial: proporciona ganhos de eficincia nos ambientes domsticos tais como integrao dos componentes da casa (figura 4);
Figura 4. Sensores fazendo a integrao dos componentes da casa.
medicina: para monitorar diversas informaes biomtricas da pessoa como: postura, acelerao, freqncia e cumprimento de passos em uma corrida ou caminhada. Estas informaes so obtidas por um sensor e enviadas a um
19
computador para que possa ser feito um monitoramento do indivduo em tempo real (figura 5).
Figura 5. Sensor utilizado para monitorar desempenho de atletas. Fonte: http://www.techzine.com.br
1.2. DISTRIBUIO DOS NS SENSORES

So vrios os ambientes onde uma RSSF pode ser distribuda, como por exemplo, vulces, oceanos, rios, mares, prdios, residncias, animais, nos seres humanos, etc. Dependendo da quantidade de ns sensores e da localizao fsica de cada n, uma RSSF pode ser organizada em grupos ou cluster. Em virtude da natureza dinmica e irregular com que os ns so distribudos, a localizao de um n particular muitas vezes no pode ser determinada, desta forma so utilizados diversos algoritmos e conjuntos de regras para clusterizao. Existem dois tipos de distribuio de RSSF: irregular: rede que apresenta uma distribuio no uniforme dos ns da rea monitorada; regular: rede que apresenta uma distribuio uniforme dos ns da rea monitorada.
1.3. CONSUMO DE ENERGIA

A principal restrio das RSSF a limitao de energia (bateria). Geralmente a vida til de uma RSSF est diretamente ligada quantidade de energia disponvel nos ns. Muitas vezes estes ns so instalados em regies de difcil acesso, sendo
20
praticamente impossvel realizar manutenes, alm disso, estas fontes de energia normalmente no so recarregveis. Grande parte do consumo de energia de um n sensor est diretamente relacionada com o processo de comunicao (transmisso, recepo e roteamento de dados). Uma forma encontrada para economizar energia, seria organizar os sensores em cluster distribudos. Conforme Wei e Chan (2005), em cada cluster um n eleito lder para agir como um controlador local, enquanto os outros so ns normais. A estrutura de um cluster consiste em: ns normais, lderes e ns de roteamento. Os ns normais coletam os dados e transmite para os lderes. Os lderes agregam os dados e os enviam para o ponto de acesso. Os ns de roteamento pertencem a mais de um cluster e serve de ponte para os lderes entre vrios clusters (figura 6).
Figura 6. Clusterizao de ns sensores. Fonte: WEI e CHAN (2005, p. 1).
Como dentro de um cluster todos os ns normais enviam os dados para os lderes, a ausncia resultante de rotas mltiplas ou roteamento resultam em economia de energia. Outra caracterstica importante est relacionada ao tamanho do cluster, conforme Wei e Chan (2005), a energia e usada para transmitir uma mensagem de uma fonte para um receptor depende da distncia d entre eles: e = kdc ,(2 < c < 4) Onde k e c so constantes para um sistema sem fio especfico onde normalmente 2 < c < 4, ou seja, quanto menor cluster, menor ser o consumo de potncia deste cluster, pois a distncia entre os sensores ser menor, resultando assim em
21
economia de energia, alm disso, as mudanas dentro de um cluster iro afetar somente aquele cluster. Outra questo o fato de os lderes dentro de um cluster, transmitir, receber e ainda transferir dados dos ns normais para as Base Stations (BS), pois desta forma os lderes consomem mais potncia que os ns normais, para resolver este problema so feitos clculos do consumo de potncia e atravs de rotatividade o n com maior energia dentro do cluster eleito como novo lder.
22
2. ELEMENTOS DE UMA REDE DE SENSORES SEM FIO

Nesta seo sero mostrados os principais elementos de uma RSSF: ns sensores, ns de roteamento (ns gateway) e Base Station (BS).
2.1. NS SENSORES
Ns sensores so dispositivos que tem por objetivo coletar informaes em uma RSSF para que seja monitorado um fenmeno. So vrios os modelos que podem ser construdos dependendo da necessidade da aplicao e caractersticas do dispositivo. Quando os ns formam uma rede ad hoc eles se comunicam entre si e o ambiente a ser monitorado, com objetivo de coletar dados sobre determinados fenmenos. Os ns coletam os dados via sensores, processam os dados coletados e os envia para um usurio ou um ponto de acesso. Em cluster o ponto de acesso pode ser implementado em uma BS. Esta por sua vez pode utilizar um gateway para o envio da informao coletada. Segundo Loureiro (2004), um n na rede tem essencialmente tarefas diferente tais como sensoriamento do ambiente, processamento da informao e tarefas associadas com o trfego em um esquema de retransmisso multi-hop (figura 7). Este tipo de comunicao utilizado para economia no consumo de energia em uma RSSF, pois a energia ideal para comunicao entre dois ns A e B depende da distncia entre eles.
Figura 7. Transmisso multi-hop. Fonte: SILVA (2003, p. 3).
23
Um sensor tipicamente consiste em cinco componentes: unidade de sensoriamento (sensor), memria, bateria, processador embutido e transceptor Rdio Freqncia (RF). A (figura 8) mostra os componentes de um n sensor. Conforme Loureiro (2004), geralmente so utilizados processadores de 8 bits com freqncia de 10 MHz, os transceptores tem largura de banda de 1 Kbit/s a 1 Mbit/s e a capacidade de memria varia de 128 Kbytes 1 Mbyte.
Figura 8. Formao em blocos de um n sensor. Fonte: LOUREIRO (2003, p. 10).
Existem vrios projetos voltados para o desenvolvimento de ns sensores, na qual possibilita a implementao de dispositivos eficientes, pequenos, de baixo custo e em grande escala, contribuindo desta forma para a rea de RSSF. A (figura 9) representa tipos de micros-sensores sem fio que foram feitos em pesquisas acadmicas.
Sensor MicroStain RFID
Sensor Intel Mote
24
JPL: Sensor Webs
Sensor Telos
Figura 9. Dispositivos ns sensores. Fonte: JNIOR (2004, p. 16).
2.2. NS DE ROTEAMENTO (NS GATEWAY)

A comunicao entre dois cluster feita atravs de ns de roteamento (gateway). As mensagens percorrem pelo cluster at chegarem a um gateway na qual ir fazer o roteamanto para que estas mensagens cheguem at uma BS onde roda a aplicao. A figura 10 mostra um exemplo de uma RSSF com ns sensores e dois ns gateway.
Figura 10. Rede RSSF com n gateway. Fonte: OTHMAN (2007)
25
3. DIAGRAMA DE BLOCOS DE UM N SENSOR COM OS MODULOS

Sero abordados nesta seo os conceitos bsicos da composio de um n sensor: unidade de energia, unidade de comunicao sem fio, unidade de sensoriamento e unidade de computao (figura 11).
Figura 11. Componentes de um n sensor sem fio. Fonte: SILVA (2003, p. 2).
Vale ressaltar que a limitao dos recursos dos ns como capacidade da fonte de energia, processador e transceptor, est relacionada com fato de os mesmos serem construdos com pequenas dimenses.
3.1. UNIDADE DE ENERGIA

Unidade mais importante de uma RSSF, a energia deve ser economizada o mximo. Atualmente so implementados protocolos com o objetivo de controlar os dados enviados pela rede, fazendo com que a aplicao se estenda por mais tempo. A energia utilizada por um n sensor consumida no sensoriamento, no processamento e na transmisso de dados, porm esta a que mais consome energia.
26
Normalmente utiliza-se baterias com energia finita para alimentar os componentes de um n sensor. Os tipos mais comuns de bateria a ser utilizado pelos ns sensores so: Ltio Coin Cell, Ltio NR ou linear simples. importante lembrar que existem baterias recarregveis pela prpria energia solar. De acordo com Silva (2003), existem diferentes fontes de energia com quantidade de potncia que cada uma pode prover (quadro 1). Observa-se que clulas solares podem contribuir com 15 mWatts por centmetro quadrado se expostas ao sol e 0,15 mWatts em dias nublados.
Quadro 1: Diferentes fontes energticas. Fonte: SILVA (2003, p. 5).
3.2. UNIDADE DE COMUNICAO

Esta unidade utiliza o espectro eletromagntico para comunicao e consiste em um canal de comunicao sem fio bidirecional composto por amplificador e antena. Conforme Silva (2003), os tipos de comunicao mais utilizados em uma RSSF so: ptica (laser) e Rdio Freqncia (RF), porm pode-se explorar tambm a comunicao com infravermelho (quadro 2). ptica (laser): pode ser dividida em ativa e passiva. O transmissor utiliza raios laser para enviar informaes. Tem como vantagem baixo peso, alta velocidade de transmisso, isolamento eltrico, imunidade eletromagntica e baixo consumo de energia. A desvantagem est relacionada com o fato de que os ns estejam direcionados.
27
Rdio Freqncia (RF): comunicao preferida na maioria dos estudos devido s restries impostas por outros tipos de transceptores. Os rdios empregam faixas de freqncias livre conhecida como Industrial, Cientfica e Mdica (ISM). Utiliza ondas eletromagnticas com freqncias que variam nas faixas de MHz GHz, dependendo do pas e da plataforma utilizada.
Infravermelho: a comunicao infravermelha assim como a comunicao ptica direcional, ou seja, o transmissor e o receptor devem estar alinhados para que os dados sejam transmitidos. Geralmente este tipo de comunicao tem alcance de 1m e no precisa de antena para transmitir.
Quadro 2: Transceptores e suas caractersticas. Fonte: CORREIA (2005, p. 4).
Vale ressaltar que dentre os componentes de hardware de um n sensor, o transceptor o maior consumidor de energia. Mesmo quando est ligado no modo escutando (idle) ou no modo repouso (sllep), o transceptor consome energia (quadro 3).
Quadro 3: Consumo do Mica Motes2. Fonte: CORREIA (2005, p. 3).
28
3.3. UNIDADE DE SENSORIAMENTO

Segundo Silva (2003), sensor um dispositivo que produz uma resposta mensurvel para uma mudana na condio fsica (temperatura, presso, campo magntico, estresse mecnico, presena ou ausncia de movimento, udio, vdeo). Esta unidade composta geralmente por sensores e conversores analgico digital (A/D), onde este responsvel pela converso do sinal analgico produzido pelos sensores para digital. So construdos de acordo com a necessidade da aplicao e o consumo de energia utilizado por este dispositivo depende da grandeza que ser medida e do modo de operao.
3.4. UNIDADE DE COMPUTAO

A memria e o processador so responsveis pelas atividades de computao do n. O consumo de energia depende do clock do processador, ou seja, quanto maior a freqncia do processador maior ser o consumo de energia. O processador realiza a execuo dos protocolos de comunicao e de algoritmos de processamento de sinal dos dados obtidos pelo sensor. A escolha do processador para um n depende do nvel de desempenho que ser utilizado para uma determinada aplicao.
29
4. CLASSIFICAO DE REDES DE SENSORES SEM FIO

A classificao de uma RSSF depende do objetivo e da aplicao. A aplicao influenciar nas funes exercidas pelos ns da rede, na arquitetura, na quantidade de ns que compem a rede, na distribuio da rede e conseqentemente no tipo de vida da rede. Conforme Ruiz (2003), as RSSF podem ser classificadas segundo a configurao, o sensoriamento, o tipo de comunicao, e inclusive o tipo de processamento que executa.
4.1. CONFIGURAO
A configurao de uma RSSF feita de acordo com a sua composio, organizao, mobilidade e distribuio. composio: neste tipo de configurao a rede pode ser composta por ns que possuem o mesmo hardware, ou por ns que possuem caractersticas diferentes de hardware; organizao: os ns so organizados de forma hierrquica ou plana. Em uma organizao hierrquica os ns so organizados em clusters. Dentro de cada cluster haver um n lder que ser eleito de acordo com o protocolo especfico da aplicao. Na organizao plana todos os ns so iguais, ou seja, possuem a mesma funo e no formam clusters; mobilidade: na mobilidade os ns so jogados em um determinado local e l permanecem at que a energia da rede acabe ou ento podem ser movidos do local onde foram jogados inicialmente; distribuio: a distribuio dos ns feita de maneira irregular ou regular Na primeira os ns no so distribudos uniformemente na rea monitorada, j na segunda os ns ficam distribudos uniformemente.
30
4.2. SENSORIAMENTO
As atividades de sensoriamento fazem a percepo do ambiente e a coleta dos dados. Deve-se analisar a aplicao e os sensores que sero usados para que seja feita uma determinao do dado que ser coletado e qual ser o volume de informao envolvida na rede. Como o grande problema de uma rede RSSF a energia, importante avaliar tambm a quantidade de ns ativos, para verificar se a rede tem condies de executar tarefas. A coleta, o processamento e a transmisso de informaes para outros ns da rede ou pontos de acesso o objetivo principal de uma RSSF. Os dados podem ser coletados em intervalos regulares como, por exemplo, em atividades que monitoram cantos de pssaros, em perodos contnuos, quando ocorrem eventos de interesse da rede ou em tempo real, neste caso as aplicaes envolvem risco para vidas humanas.
4.3. COMUNICAO
Os requisitos de preciso de uma RSSF podem ser alcanados de diversas maneiras. Se uma rede bem projetada estes requisitos so atingidos de maneira que o consumo de energia e falhas sejam otimizados. Durante o desenvolvimento de um projeto que envolve comunicao, o projetista deve ser capaz de escolher a infra-estrutura e os protocolos que dar um melhor desempenho na rede. A comunicao existente entre os ns de uma RSSF pode ou no ter o mesmo alcance. Durante a transmisso dos dados os ns podem usar comunicao simplex, half-duplex e full-duplex. A comunicao simplex permite que os dados sejam enviados em um nico sentido, tendo em uma extremidade um dispositivo transmissor e no outro lado um receptor. Neste tipo de comunicao, o receptor no tem a possibilidade de sinalizar que os dados recebidos esto corretos. Na comunicao half-duplex os ns podem transmitir e receber dados em um determinado instante. J na transmisso full-duplex os dados podem ser transmitidos e recebidos ao mesmo tempo em ambos os sentidos.
31
RSSF utiliza alocao de canais de transmisso, isso significa que os ns transmitem os dados em difuso para todos os elementos da rede que esto em seu alcance. Se outro n tentar transmitir no mesmo intervalo de tempo, a comunicao poder sofrer problemas como distoro do sinal ou colises de quadros transmitidos. Para evitar este problema, as redes de sensores sem fio utilizam dois mtodos de alocao de canais: esttica ou dinmica. Na alocao esttica a largura de banda dividida em n partes iguais na freqncia (FDMA Frequency Division Multiple Access), no tempo (TDMA Time Division Multiple Access), no espao (SDMA Space Division Multiple Access) ou ortogonais (OFDM Orthogonal Frequency Division Multiplexing). A alocao dinmica no permite que a largura de banda seja dividida em canais fixos. Neste tipo de alocao os ns disputam o canal para comunicao dos dados.
4.4. PROCESSAMENTO
O processamento de informaes em uma RSSF feito de acordo com o dado coletado pelo n em uma determinada aplicao, esses dados podem sofrer compresso, agregao, fuso, criptografia, etc. O processamento pode ser realizado de acordo com a infra-estrutura da rede ou algum tipo de processamento local bsico como, por exemplo, a traduo dos dados coletados pelos sensores baseado na calibrao. Nesta seo foi verificada a importncia dos requisitos da aplicao a serem desenvolvidas antes de qualquer projeto de RSSF, as restries e caractersticas dos componentes dos ns sensores, bem como as propriedades do ambiente onde uma RSSF ser instalada.
32
5. PROTOCOLOS PARA REDES DE SENSORES SEM FIO

Atualmente novos protocolos tm sido desenvolvidos especificamente para se adequar as limitaes das RSSF. Como RSSF tem grandes limitaes, no interessante usar protocolos de comunicaes de redes ad hoc, pois estes precisam de muitos Kbytes de memria entre outros recursos. Apesar das diferentes formas de comunicao, a organizao dos protocolos utilizada pelos ns, pode ser generalizada em um modelo nico, ou seja, usando a arquitetura TCP/IP como (quadro 4). Camada Aplicao Protocolos SMP, TADAP e SQDDP
Transporte PFSQ, ESRT e RMST Rede Enlace Fsica Difuso Direta, SPIN, LEACH, PEGASIS e CODA B-MAC, S-MAC e D-MAC ptica, Rdio Freqncia (RF) e Infravermelha
Quadro 4: Protocolos para RSSF
5.1. CAMADA FSICA

Esta camada utiliza o espectro eletromagntico para transmisso sob a forma de laser, Rdio Freqncia (RF) e luz infravermelha.
5.1.1. Comunicao ptica

Este tipo de transceptor consome menor quantidade de energia por bit transmitido. Os ns que usam transceptores pticos no necessitam de antena, mas precisam ter visada direta (LoS Line of Sight), ou seja, os ns de origem e destino devem estar alinhados. Por apresentar caracterstica de visada direta, os transceptores pticos no podem ser usados em redes onde no existe uma topologia planejada, como por exemplo, em redes lanadas de maneira aleatria. Um exemplo da utilizao de comunicao ptica o n sensor Smart Dust. Segundo Dust (2004), a comunicao ptica pode ser passiva, atravs de um
33
Corner Cube Reflector (CCR) (0,5 x 0,5 x 0,1 mm3) transmitindo a uma taxa de 10 kbps, utilizando 1 W de energia e com uma rea de alcance de 1km. Outra opo no Smart Dust a transmisso ativa atravs de laser, (1,0 x 0,5 x 0,1 mm3) transmitindo a 1 Mbps, com o gasto de energia de 10mW e rea de alcance de 10km. O volume total de um n sensor Smart Dust chega a 1,5 mm3 e a massa total 5mg, dimenses que tornam invivel o uso de transceptores RF.
5.1.2. Comunicao Rdio Freqncia (RF)

Este tipo de comunicao utiliza ondas eletromagnticas para transmitir dados atravs de freqncias livres - Industrial Cientfica e Mdica (ISM) que variam nas faixas de 314, 433, 868, 915 MHz e 2,4 GHz, dependendo do pas e da plataforma utilizada. Nessas freqncias so utilizadas diversas tcnicas de modulao como, Amplitude Shift Keying (ASK), Frequency Shift Keying (FSK) e Direct Sequence Spread Spectrum (DSSS) que influenciaro na propagao do sinal transmitido. Como alguns sensores tm seu tamanho reduzido, o tamanho da antena passa a ser um fator com limitaes. Segundo Ruiz (2004), para otimizar a transmisso e a recepo, uma antena deve ser pelo menos B/4, onde B o comprimento de onda da freqncia. Geralmente so utilizadas antenas com caracterstica ominidirecionais, onde apresentam um diagrama de radiao com caractersticas prximas de uma antena isotrpica ideal (figura 12).
Figura 12. Diagrama de radiao de uma antena isotrpica ideal. Fonte: CABRINI (2006, p. 10).
34
5.1.3. Comunicao infravermelha

Comunicao direcional, ou seja, para que este tipo de comunicao funcione preciso que os transceptores estejam alinhados em um ngulo de 30 graus, alm disso, so suscetveis s variaes de temperatura e umidade do meio de transmisso. Este problema pode ser corrigido com lentes, fazendo com que o foco do sinal seja ajustado para o receptor.
5.2. CAMADA DE ENLACE

Conforme Akyildiz (2002), a camada de enlace responsvel pela multiplexao do fluxo de dados, controle de acesso ao meio e correo de erros. Garante conexes ponto-a-ponto e multiponto confiveis em uma rede de comunicao. Os protocolos Medium Access Control (MAC) so capazes de criar uma infraestrutura onde diversos ns so espalhados em um campo estabelecendo laos de comunicao para transmisso de dados, alm disso, tem o objetivo de fazer com que os ns tenham uma comunicao eficiente. Foi visto na seo 1.3 que em uma RSSF os ns consomem grande quantidade de energia durante a transmisso de dados, desta forma, a camada de enlace tem uma grande importncia, pois atravs da correo de erros, os pacotes so recebidos e corrigidos sem que haja necessidade de retransmisso. Outro fator importante da camada MAC o fato de ela evitar colises fazendo com que no haja desperdcio de energia em uma RSSF. Redes RSSF tem o mesmo problema de comunicao de uma rede tradicional. Geralmente em grande parte das redes sem fio a comunicao feita no modo HalfDuplex, fazendo com que a transmisso do fluxo de informaes seja bidirecional. O protocolo Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) utilizado pelas redes sem fio para controle de acesso ao meio fazendo com que colises sejam evitadas. Porm, em redes com sensores h uma grande limitao de hardware e software, segundo Ruiz (2004), no existe suporte pelo hardware para deteco de portadora, deteco de coliso, enquadramento especfico,
35
codificao ou balanceamento de energia. O rdio utilizado possui caractersticas de baixa potncia, largura de banda limitada e um nico canal na freqncia base ISM. Diante dos fatos apresentados acima so propostos vrios protocolos de comunicao especficos para cada tipo de aplicao em uma RSSF.
5.2.1. Protocolo B-MAC

Protocolo desenvolvido especificamente para RSSF. Foi implementado com a verso do Sistema Operacional TinyOS. Segundo Polastre (2004), este protocolo foi concebido para permitir que a camada de enlace seja reconfigurada conforme a carga de trabalho, podendo em alguns casos estender o tempo de vida de uma rede em at cinqenta por cento. Atravs de uma heurstica chamada Clear Channel Assessment (CCA), possvel verificar a existncia de atividades em um canal de comunicao, ou seja, se o canal est livre ou ocupado. O CCA utiliza uma tcnica onde canais so julgados de acordo com uma estimativa de rudo do canal obtido pela fora do sinal recebido Received Signal Strenght Indicator (RSSI). A figura 13.a mostra este sinal que equivale ao recebimento de um quadro e a figura 13.b apresenta a sada do sinal aps o ajuste realizado pelo algoritmo CCA.
(a) RSSI
(b) Heurstica CCA Figura 13. RSSI e heurstica CCA. Fonte: POLASTRE (2004, p. 2).
36
5.2.2. Protocolo S-MAC

Primeiro protocolo MAC desenvolvido para RSSF. Segundo Ye (2002), o protocolo Sensor-MAC (S-MAC) um protocolo de controle de acesso ao meio baseado em alocao dinmica de canal, mas que utiliza sincronizao para coordenao dos modos de operao do rdio. Para fazer a comunicao entre os ns, ou seja, para que haja troca de mensagens este protocolo utiliza fluxos broadcast ou unicast. O consumo de energia o principal objetivo deste protocolo, o mesmo procura ser eficiente neste ponto fazendo com que o consumo dos principais eventos responsveis pelo desperdcio de energia seja reduzido. Na alocao dinmica no existe atribuio fixa de canais para os ns da rede, e como os ns trabalham em half-duplex, tem-se a possibilidade de colises durante o envio de dados. Para resolver o problema de coliso o S-MAC utiliza uma funo similar de coordenao distribuda (DCF) usada no IEEE 802.11 e atravs de um dilogo de comunicao os problemas de terminais escondidos, estaes expostas e colises so evitadas. Se ocorrer uma coliso o algoritmo Binary Exponential Backoff (BEB) ser utilizado para aguardar um tempo aleatrio. Quando os ns esto transmitindo os outros ns ficam escutando mesmo que esta transmisso no seja destinada para toda a rede, ou seja, h um overhearing, este problema evitado colocando em repouso os ns enquanto seus vizinhos conversam entre si.
5.2.3. Protocolo D-MAC

Conforme Gang (2004), o protocolo Distributed Energy aware MAC (D-MAC) fornece uma importante economia de energia e baixa latncia de comunicao, seguindo o princpio de construo de uma rvore, onde o n raiz ser o sorvedouro e os ns folhas desta rvore sero os transmissores. Este protocolo emprega alocao esttica de canal, fazendo com que a largura de banda seja dividida em vrios canais, onde cada canal ser distribudo para os ns da rede. Isto faz com que no haja coliso, pois os ns iro transmitir e receber dentro do seu canal de comunicao, alm disso, utiliza a tcnica de mutiplexao TDMA.
37
O algoritmo utilizado pelo D-MAC elege o n com menor quantidade de energia para entrar no modo sleep, isso faz com que os ns com baixa energia sejam utilizados com menor freqncia. Este procedimento de eleio consegue um balanceamento ideal de energia na rede.
5.3. CAMADA DE REDE

De acordo com Ruiz (2004), a principal funo da camada de rede prover o servio de roteamento que pode ser definido como o processo pelo qual a rede consegue identificar o destinatrio das mensagens e encontrar um caminho entre o destino e origem desta mensagem. Como sensores podem ser espalhados densamente em uma rea qualquer, tm-se uma preocupao com a durabilidade das fontes de energia, pois estes dispositivos so menores e provavelmente ficaro em locais onde no poder ser feita a recarga ou troca destas fontes. Segundo Heidemenn (2001), a fuso/agregao dos dados tem sido apontada como uma opo que permite otimizar a operao das RSSF. Desta forma os dados so pr-processados dentro da rede fazendo com que a ocorrncia de redundncias e o nmero de transmisses sejam diminudas, isso faz com que haja uma economia de energia. Em uma RSSF, protocolos de roteamento so divididos em roteamento plano, e roteamento hierrquico. No roteamento plano todos os ns possuem a mesma funo (figura 14.a), j no roteamento hierrquico os ns tm funes diferentes, alguns so responsveis pela coleta de dados e outros pela fuso e envio destes dados (figura 14.b). No roteamento geogrfico so utilizadas tcnicas para que os ns se adaptem s condies atuais da rede e nveis de energia disponvel. Os protocolos de roteamento devem prover de tcnicas para considerar a necessidade de eficincia no consumo de energia em uma RSSF. Sero mostrados neste captulo dois protocolos de roteamento plano e trs protocolos de roteamento hierrquico com esta finalidade.
38
(a) Roteamento plano
(b) Roteamento hierrquico
Figura 14. Diviso de roteamento em uma RSSF.
5.3.1. Protocolo de Difuso Direta

Conforme Intanagonwiwat (2000), o protocolo de Difuso Direta constitudo por vrios ns. Os dados so nomeados atravs de atributos pelos ns transmissores. O n sink divulga em toda a rede quais so os dados de seu interesse (figura 15.a), isto faz com que seja criado dentro da rede um campo de gradiente (figura 15.b) fazendo com que os ns vizinhos propagem os dados at o n sink (figura 15.c).
(a) Interesse de propagao
(b) Criao do gradiente
c) Caminho/entrega dos dados
Figura 15. Exemplo de Difuso Direta. Fonte: INTANAGONWIWAT (2000, p. 56).
5.3.2. Protocolo SPIN

O protocolo (Sensor Protocol for Information via Negotiation) SPIN um protocolo adaptativo para redes de sensores. Segundo Heinzelman (1999), este protocolo divulga informaes entre os sensores de forma eficiente, ou seja, eles utilizam dados descritores de alto nvel chamado de meta-dados com a finalidade de eliminar a transmisso de dados redundantes na rede.
39
Este protocolo no difunde os dados pela rede e sim os meta-dados, pois estes so menores que os dados, possibilitando desta forma uma economia com o gasto de energia. Possuem ainda a capacidade para monitorar os recursos de energia disponvel nos ns fazendo com que os mesmos no sejam desligados.
5.3.3. Protocolo LEACH

De acordo com Heinzelman (2002), Low-Energy Adaptive Clustering Hierarchy (LEACH) um protocolo baseado em cluster que usa randomizao para distribuir uniformemente a carga de energia entre os ns em uma RSSF. O LEACH faz com que dentro de cada cluster um n seja eleito lder atravs de randomizao. Os lderes so responsveis pela compresso e transmisso dos dados do seu cluster para uma BS. Como os lderes consomem mais energia que os outros ns normais, esta rotao peridica faz com que haja uma economia de energia e um aumento de vida til na rede, visto que a funo de lder no ficar apenas com um n. A vantagem do LEACH est no fato de o mesmo fazer rotao aleatria dos lderes, agregao local dos dados e coordenao local para criar e operar os clusters. A desvantagem que o LEACH no verifica a disponibilidade de ns sensores, desta forma quando um lder fica indisponvel todas as mensagens enviadas dos ns normais para o lder sero perdidas durante aquela rodada, alm disso, no garante clusters uniformemente distribudos pela rede.
5.3.4. Protocolo PEGASIS

Conforme Lindsey (2001), Power-Efficient Gathering in Sensor Information Systems (PEGASIS) um melhoramento do protocolo LEACH baseado no conceito de correntes. O PEGASIS faz com que sejam formadas cadeias ao invs de cluster de maneira que cada n transmita e receba apenas com vizinhos mais prximos, alm disso, escolhido apenas um n da cadeia para transmitir as informaes coletadas ao n gateway.
40
Os dados coletados passam de n a n, onde so agregados pelo n lder e enviados para o n gateway (figura 16). Isso faz com que seja reduzida a quantidade de mensagens, diminuindo desta forma o gasto de energia na RSSF.
Figura 16. Funcionamento do PEGASIS.
Conforme Ruiz (2004), o PEGASIS assume o seguinte: O n gateway (estaao base) situa-se estacionado uma distncia fixa da rede; Os ns so capazes de transmitir dados diretamente para o n gateway e para qualquer outro n; Cada n possui informao de localizao dos outros ns; Os ns so homogneos e com o nvel de energia uniforme; Os ns no so mveis. A cada round um n escolhido para transmitir a informao estao base.
5.3.5. Protocolo CODA

Segundo Lee (2006), Cluster-based sef-Organining Data Aggregation (CODA), um protocolo de clusterizao onde a quantidade e a distncia dos ns serve de base para diviso da rede em um cluster. O CODA sincroniza os ns da rede fazendo com que os mesmos participem da clusterizao em intervalos de tempo peridicos. Neste protocolo os lderes so eleitos de acordo com a quantidade de energia de cada n, distncia entre os mesmos e da quantidade de ns existente em um cluster.
41
O algoritmo CODA possui trs fases. A primeira fase chamada de init, nesta fase os lderes so eleitos de acordo com a energia disponvel de cada n e da distncia entre eles. A segunda fase chamada de merge, nesta fase clusters com quantidade de ns menores que a definida pelo usurio so unidos. J a terceira fase chamada de partition responsvel pela partio dos clusters quando o nmero mximo de ns dentro de um cluster ultrapassado do valor definido tambm pelo usurio.
5.4. CAMADA DE TRANSPORTE

Esta camada mantm o fluxo de dados das aplicaes, porm nem sempre necessrio o uso da mesma em RSSF. Geralmente utilizada quando se tm necessidade de acesso internet ou redes externas. Conforme Ruiz (2004), a maioria das aplicaes em redes sensores admite perda de dados, assim um mecanismo elaborado para garantia do envio de dados no justificado. So utilizadas vrias tcnicas em protocolos de roteamento para diminuir a perda de dados, porm certas aplicaes precisam de uma entrega confivel de dados.
5.4.1. Protocolo PSFQ

Conforme Wan (2002), Pump Slowly, Fetch Quickly (PSFQ) um protocolo de transporte confivel adequado para uma nova classe de aplicaes emergentes em redes de sensores sem fio. Atravs de uma confirmao ponto a ponto o PSFQ consegue trabalhar com correo local de erros, alm disso, adaptativo significando que caso a rede apresente quantidade de falhas baixo, o envio ser igual ao repasse tradicional de dados. A transmisso dos dados pelo emissor feita em fragmentos, isso faz com que sejam identificadas perdas de dados. Os ns intermedirios da comunicao recebem os fragmentos e guardam em sua cache fazendo com que sejam identificados fragmentos de mensagens perdidos. So utilizados trs tipos de transmisso pelo PSFQ: push, fetch e report.
42
push: utiliza saltos de n em n no caminho at o destinatrio para enviar fragmentos de mensagens;
fetch: esta operao utilizada quando um n identifica que no recebeu um determinado fragmento. Caso isso acontea feita uma requisio para que seja feita uma retransmisso do fragmento perdido;
report: utilizado nos ns receptores para notificar aos ns transmissores que o recebimento foi notificado.
5.4.2. Protocolo ESRT

Conforme Sankarasubramaniam (2002), Event-to-Sink Reliable Transfer (ESRT) um protocolo de transporte desenvolvido para realizar deteco de eventos confiveis em uma RSSF usando pouca quantidade de energia. Este evento recebido em uma estao base atravs de mensagens de vrios ns. O reconhecimento de um evento confivel feito atravs de uma quantidade de mensagens determinada. Se o nmero de mensagens recebidas for inferior esta quantidade, o evento no reconhecido de forma confivel. Portanto o objetivo do protocolo ESRT fazer com que a taxa de envio de dados seja ajustada para cada n, fazendo com que desta forma o recebimento de pacotes com evento esteja o mais prximo possvel do valor necessrio para o reconhecimento confivel do mesmo.
5.4.3. Protocolo RMST

Segundo Stann (2003), o protocolo Reliable Multi-Segment Transport (RMST) fornece entrega garantida e fragmentao para aplicaes que necessitam deste tipo de entrega. O RMST usa Difuso Direcionada implementando desta forma uma transmisso confivel. Atravs de um cache de dados ligado a Difuso Direcionada garantido que os dados perdidos sejam recuperados localmente. Temporizadores so utilizados para detectar fragmentos perdidos. Conforme RUIZ (2004), se um fragmento no for recebido em um tempo determinado, enviado um Negative Acknowledgement (NACK) para os ns que esto no sentido inverso do gradiente, requisitando os
43
fragmentos perdidos. Os ns que possuem um dos fragmentos em cache, o repassam para o n. Caso o fragmento no esteja em cache, o NACK repassado em sentido contrrio ao gradiente at que o fragmento seja encontrado. O RMST no trata o problema de congestionamento de dados em uma RSSF e no garante a confiabilidade se um n falhar depois de receber e antes de transmitir os dados fragmentados.
5.5. CAMADA DE APLICAO

Apesar de existirem muitas aplicaes para RSSF, esta camada apresenta poucos protocolos em estudo. A principal funo da camada de aplicao fazer com que o hardware e software das camadas inferiores fiquem transparentes para as aplicaes em redes de sensores sem fio. Segundo Akyildiz (2002), so estudados trs possveis protocolos na camada de aplicao: sensor management protocol (SMP), task assignment and data advertisement protocol (TADAP) e sensor query and data dissemination protocol (SQDDP).
5.5.1. Protocolo SMP

O protocolo sensor management protocol (SMP) tem a funo de gerenciar as aplicaes de uma rede de sensores sem fio, fazendo com que a mesma seja isolada das camadas inferiores. Administradores de RSSF utilizam o SMP para interagir com sensores da rede. Como redes RSSF consistem de ns que no possuem identificao o SMP acessa os mesmos atravs de atributos de nomes e endereos baseados em localizao, isso faz com que o software execute algumas tarefas como: Agrupamento de sensores; Gerenciamento de sensores; Turno para sensores: ligado ou desligado; Reconfigurao da rede aps mudanas no estado dos sensores;
44
Realizao de tarefas relacionadas a segurana como: autenticao, chave de segurana e segurana na comunicao de dados.
5.5.2. Protocolo TADAP

O task assignment and data advertisement protocol (TADAP) outro importante protocolo da camada de aplicao para o funcionamento de uma RSSF. Tem a funo de distribuir os interesses dos usurios entre os sensores. Alm disso, o TADAP oferece para os usurios dados disponveis como eventos ou fenmenos em um determinado intervalo de tempo, ou seja, medida que novos dados aparecem nos sensores da rede, os mesmos so informados para o usurio.
5.5.3. Protocolo SQDDP

O protocolo sensor query and data dissemination protocol (SQDDP) serve de interface para o usurio realizar consultas nos ns da rede. Esta consulta feita em um conjunto de ns numa regio que se deseja monitorar. Conforme Shen (2001), Sensor Query and Task Language (SQTL) uma aplicao que utiliza este protocolo. O SQLT define trs tipos de eventos para aplicao: receive, every e expire. O receive usado quando a ocorrncia de um determinado evento detectada por um n. O every define eventos peridicos, informando o estado do sensor em intervalos de tempo regulares. O expire corresponde a eventos que ocorrem aps a expirao de um tempo. Segundo Akyildiz (2002), apesar de ser proposto o SQTL para a camada de aplicao, ainda precisam ser desenvolvidos outros protocolos para fornecer maior nmero de servios.
45
6. SIMULADORES
Um simulador utilizado para desenvolver e analisar os diversos tipos de protocolos existentes em RSSF, desta forma deve-se verificar se o simulador possui as caractersticas que sero usadas na rede de sensores a ser simulada. Simuladores com funcionalidades para simulao de redes convencionais no podem ser utilizados para simulao de redes com sensores devido s caractersticas deste tipo de rede. Por exemplo, um simulador convencional no trata o problema do esgotamento de energia e mobilidade de um n. O uso de simulao apresenta diversas vantagens como: implementao de protocolos, baixo custo e execuo de testes em redes de larga escala. Existem vrios simuladores que podem ser usados para fazer simulaes em redes de sensores. Nesta seo sero mostradas algumas ferramentas utilizadas para fazer simulaes, apresentando caractersticas, vantagens e desvantagens de cada ferramenta.
6.1. TOSSIM
Segundo Lee (2003), o TinyOS Simulator (TOSSIM) um simulador de eventos discretos para um sistema operacional de RSSF denominado TinyOS. Ao invs de compilar uma aplicao do TinyOS para um n sensor, os usurios podem compilar esta aplicao para o ambiente do TOSSIM que executa em um PC. O TOSSIM tem a finalidade de depurar, testar e analisar algoritmos em ambientes controlados. O principal objetivo do TOSSIM simular as aplicaes para o TinyOS, com isso o TOSSIM foca na simulao e execuo deste e no em simulaes do mundo real. O TOSSIM pode ser ainda usado para compreender as causas de comportamento observadas no mundo real, porm ele no consegue capturar todos estes fatos, desta forma o mesmo no deve ser utilizado para avaliaes absolutas. O cdigo executado no TOSSIM compilado diretamente do cdigo TinyOS, isto permite que este cdigo seja executado em um desktop ou laptop. O TOSSIM consegue simular milhares de ns sensores ao mesmo tempo. Durante a simulao, cada n sensor executa o mesmo programa TinyOS.
46
6.2. NS-2
O Network Simulator (NS-2) um simulador de cdigo aberto baseado em eventos discretos implementado em C++ e na linguagem de script OTcl. Foi criado em 1989 para fazer simulaes de redes e ao longo do tempo foram feitas adaptaes criando desta forma o suporte s RSSFs. O NS-2 suporta definio do modelo de energia, raio do sinal do n, tipo de propagao do sinal, degradao do sinal e movimentao dos ns. Atravs da linguagem OTcl o usurio elabora scripts que definem o cenrio e o comportamento das conexes, extraindo desta forma informaes como: topologia da rede, protocolo usado, aplicaes simuladas e dados estatsticos extrados dos arquivos de log.
6.3. ATEMU
Conforme Polley (2004), o ATmel EMUlator (ATEMU) simula operaes de baixo nvel em cada sensor individualmente, isto permite simulao com diferentes aplicaes para cada sensor. Emula operaes do processador, tempo e interface de rdio. Implementado em C, o ATEMU simula apenas sensores do tipo MICA2, porm sua arquitetura permite que outras plataformas de hardware sejam suportadas. Devido ao alto nvel de confiana em relao operao real da rede, as informaes extradas do ATEMU tm um desempenho e escalabilidade comprometida. Desta forma, quando feita uma simulao em redes com mais de 120 ns, tem-se um alto consumo de memria, fazendo com que o ATEMU seja 30 vezes mais lento que o TOSSIM. Um arquivo de configurao Extensible Markup Language (XML) usado para configurar a rede, isto permite que as caractersticas de cada sensor sejam definidas em um nvel mais baixo. Junto com a distribuio do ATEMU existe um front-end chamado de XATDB (figura 17), este faz com que usurios depurem e monitorem a execuo do cdigo assembly ou nesC.
47
Figura 17. Exemplo de depurao com o front-end XATDB. Fonte: POLLEY (2004, p. 149).
6.4. OMNeT++
O OMNeT++ um sistema de simulao de eventos discretos que tem como principal objetivo simular redes de comunicao, porm devido a sua arquitetura ser bastante flexvel, ele pode ser usado em outras reas como simulaes de sistemas complexos em TI ou arquitetura de hardware. Os mdulos do OMNeT++ so escritos em C++ e sua estrutura de composio feita atravs de uma linguagem de alto nvel chamada Network Definition (NED). Esta linguagem define os mdulos e conexes que sero utilizados atravs de uma interface grfica ou textual. Os mdulos podem ser simples ou combinados, alm disso, no definido um limite para hierarquia de componentes, desta forma, podese criar um n na rede com a finalidade de calcular o uso de energia e coletar dados do ambiente.
48
O OMNeT++ suporta duas interfaces grficas: TKENV (figura 18) e CMDENV. Desta forma, usurios podem executar e alterar simulaes neste modelo.
Figura 18. Interface grfica do TKENV. Fonte: http://www.omnetpp.org/external/images/screensh.png
O TKENV recomendado para desenvolvimento de simulaes ou apresentaes, pois consegue detalhar o estado de simulao em qualquer ponto de execuo e acompanhar o que acontece dentro da rede. O CMDENV uma interface de linha de comando utilizada essencialmente para execuo em batch.
49
7. CASTALIA
Castalia um simulador de RSSF baseado em OMNeT++, em que os pesquisadores e desenvolvedores testam atravs de um canal de rdio seus algoritmos distribudos ou protocolos, alm disso, o Castalia pode ser usado tambm para avaliar diversas caractersticas em aplicaes especficas e pode ainda simular uma variedade de plataformas. Principais caractersticas do Castalia: avanado canal de rdio baseado em dados medidos empiricamente; detalhado estado de transio para o rdio, permitindo a transmisso em mltiplos nveis de potncia; um modelo de processo fsico altamente flexvel; dispositivo de sensoriamento de rudo e consumo de energia; variao do clock do n, consumo de energia da Unidade Central de Processamento (CPU); acompanhamento do recurso que ultrapassa o consumo de energia (como memria e CPU); um protocolo MAC com um grande nmero de parmetros para a sintonia; projetado para adaptao e expanso.
A ativao da modularidade, confiabilidade e velocidade no Castalia feita atravs do OMNeT++, por isso deve-se ter uma compreenso dos conceitos bsicos do OMNeT++.
7.1. ESTRUTURA DO CASTALIA

Na estrutura bsica do mdulo do Castalia os ns no se comunicam uns com os outros diretamente. A comunicao feita atravs de um canal de rede sem fio e as
50
mensagens so passadas entre os mdulos atravs das setas (figura 19). Todo pacote enviado por um n ser direcionado para um canal de rede sem fio, que decidir quais os ns recebero este pacote.
Figura 19. Conexes dos mdulos no Castalia. Fonte: http://castalia.npc.nicta.com.au/documentation.php
Os ns so ligados tambm atravs de processos fsicos. Cada processo fsico tem um mdulo que obtm leituras dos sensores. Pode haver vrios processos fsicos com diversos dispositivos sensores e diversos canais de redes sem fio para representar vrias freqncias diferentes ou cdigos que um n pode ter. A estrutura interna de um n formada por mdulos compostos (figura 20). As setas significam mensagens passadas entre as camadas e as setas tracejadas so a interface entre os mdulos. A maioria dos mdulos, por exemplo, possui uma funo que gerncia os recursos, sinalizando desta forma que a energia foi consumida. Se o usurio quiser alterar um algoritmo, deve-se construir um mdulo novo na seqncia do modelo que oferecido no simulador Castalia. Os outros mdulos so sintonizveis por outros parmetros, isso faz com que, geralmente, os usurios no mudem a sua funcionalidade.
51
Figura 20. Composio do mdulo de um n. Fonte: http://castalia.npc.nicta.com.au/documentation.php
Para definir os mdulos, ou seja, definir o nome do mdulo, o parmetro do mdulo e a interface do mdulo, o Castalia utiliza o OMNet++ com a linguagem de alto nvel NED, porm se for um mdulo composto ser preciso definir tambm a estrutura dos submodulos. Os arquivos com extenso .ned contm cdigo da linguagem NED. A estrutura do Castalia baseada na hierarquia dos diretrios. Cada mdulo corresponde a um diretrio que contm sempre um arquivo .ned na qual define o mdulo. Se o mdulo for composto, este possui subdiretrios onde sero definidos os sub-mdulos, porm se for um mdulo simples ser encontrado arquivos .cc e .h feitos em C++ para definir o comportamento do mesmo. Geralmente os usurios no utilizaro os arquivos .ned, porm estes arquivos so carregados dinamicamente e processados atravs do OMNeT++, fazendo com que qualquer mudana no exija a recompilao do Castalia (salvo se aparecer mdulos com novas funcionalidades).
52
7.2. INSTALAO DO OMNeT++

Como o Castalia baseado no OMNeT++, deve-se desta forma instalar o mesmo no Sistema Operacional. Embora o OMNeT++ possa ser instalado no Windows recomendado utilizar o Linux/Unix para um processo de instalao mais limpo, por isso ser utilizado um ambiente com o Debian Etch 4 GNU/Linux. Ser presumido que o Sistema Operacional Debian Etch 4 GNU/Linux e aptitude esto corretamente configurados. Todos os comandos devero ser executados pelo usurio root. O quadro abaixo mostra as caractersticas do ambiente e a verso dos pacotes utilizados: Distribuio Linux (Debian Etch 4) OMNeT++ (omnetpp) Castalia Verso 2.6.18-6-686 3.3 1.3
Quadro 5: Distribuies utilizadas no ambiente operacional
Para compilar e configurar o omnetpp-3.3 e o castalia-1.3 deve-se instalar os seguintes pacotes: # apt-get install gcc, g++, make, xlc, bison, byacc Para que seja feita uma amostragem da simulao atravs de grficos, instalar o gnuplot. Esta ferramenta faz parte do projeto GNU e foi criada para profissionais que desejam plotar grafos e superfcies utilizadas em aplicaes de fsica, matemtica, estatstica, etc. Como a utilizao do gnuplot depende de um gerenciador de janelas, deve-se instalar o x-window-system e KDE. # apt-get install gnuplot # apt-get install gnuplot-x11 # apt-get install x-window-system # apt-get install kde
53
Extrair o arquivo fonte do OMNeT++ digitando: # tar -xvzf omnetpp-3.3-src Ser criado um diretrio omnetpp-3.3 com todo o cdigo fonte. Configurar a bashrc do usurio root inserindo no final do arquivo /root/.bashrc a path: export PATH=$PATH:~/omnetpp-3.3/bin export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/omnetpp-3.3/lib Verificar a configurao do arquivo /omnetpp-3.3/configure.user # vi configure.user Caso seja necessrio alterar o cdigo do simulador, deve-se mudar o parmetro CFLAGS para CFLAGS=g wall, caso contrrio, deixar esta opo default. Como no ser necessrio que o OMNeT++ utilize interface grfica necessrio descomentar a linha: NO_TCL = TRUE Verificar se o parmetro WITH_NETBUILDER est habilitado para que o OMNeT++ seja compilado com a linguagem NED. WITH_NETBUILDER = yes Para configurar e compilar o omnetpp-3.3 execute o comando: # ./configure # make
7.3. INSTALAO DO CASTALIA

Obter o cdigo fonte do Castalia atravs do endereo: http://castalia.npc.nicta.com.au/download.php
54
Extrair o arquivo fonte do Castalia digitando: # tar -xvzf castalia-1.3 Ser criado um diretrio Castalia-1.3 com todo o cdigo fonte. Edite o arquivo /root/Castalia-1.3/config/Castalia.conf. # vi Castalia.config Altere a linha ROOT=$(HOME)/YOUR_PATH_TO_CASTALIA e defina a localizao exata do diretrio do Castalia no disco local. ROOT=$(HOME)/Castalia-1.3 Mude para o diretrio /root/Castalia-1.3 e execute o comando: # ./makemake Aps executar o comando acima, dever aparecer a seguinte mensagem: Regenerating nedfiles.lst Done Ainda no diretrio Castalia-1.3 execute o comando: # make Mude para o diretrio /root/Castalia-1.3/bin para ver se gerou o binrio/executvel CastaliaBin. Se o mesmo estiver no diretrio, o Castalia foi instalado e configurado com sucesso.
7.4. EXECUTANDO UM TESTE DE SIMULAO

Acesse o diretrio /root/Castalia-1.3/Simulations/valuePropagation. Dentro deste diretrio existem dois arquivos: omnetpp.ini e runValProp. O primeiro o arquivo de configurao que define todos os parmetros utilizados pelo OMNeT++ e Castalia. O segundo um script. Execute o script com o comando:
55
# ./runValProp Ser exibida na tela a seguinte mensagem (figura 21):
Figura 21. Mensagem exibida quando executado o script runValProp.
A sada da simulao ser escrita no arquivo chamado Castalia-Primary-Output.txt. Abrir o arquivo e verificar as primeiras linhas (figura 22). # vi Castalia-Primary-Output.txt
Figura 22. Primeiras linhas do arquivo Castalia-Primary-Output.txt.
Se as primeiras linhas do arquivo Castalia-Primary-Output.txt forem iguais a figura 21, significa que o OMNeT++ e o Castalia est instalado, configurado e pronto para ser usado.
56
8. MODIFICAO E DEFINIO DO ALGORITMO

Esta seo abordar os critrios utilizados para realizar uma simulao com Difuso Direta no Castalia.
8.1. ESTRUTURA E FUNCIONAMENTO DO MODELO DE APLICAO

No diretrio /root/Castalia-1.3/src/Node/Application/templateApplication/ existe um arquivo chamado de template_ApplicationModule.cc. Este arquivo define um mdulo do OMNeT++ onde sero feitas as modificaes para execuo de uma nova aplicao. Dentro deste arquivo existem mtodos para inicializar os mdulos, tratar as mensagens recebidas pelos mdulos e para finalizar o mdulo.
8.1.1. Macros
No arquivo template_ApplicationModule.cc so definidas varias macros para que seja feita diversas operaes. Estas macros so mostradas no cdigo abaixo: #include "template_ApplicationModule.h" #define EV ev.disabled()?(ostream&)ev:ev #define CASTALIA_DEBUG (!printDebugInfo)?(ostream&). #define DRIFTED_TIME(time) ((time) * cpuClockDrift) #define MEMORY_PROFILE_STORE(numBytes). #define MEMORY_PROFILE_FREE(numBytes). #define STARTUP_DELAY 0.05 #define APP_SAMPLE_INTERVAL 0.5 #define CIRCUITS_PREPARE_DELAY 0.001 A semntica destas macros : CASTALIA_DEBUG: imprimi informaes para depurar um arquivo nomeado pelo parmetro SN.debugInfoFilename (o padro Castalia-Debug.txt);
57
DRIFTED_TIME: defini o tempo da aplicao de um temporizador; MEMORY_PROFILE_STORY e MEMORY_PROFILE_FREE: defini a faixa de memria RAM utilizada pelo algoritmo. A sua utilizao exige que o programador utilize corretamente liberao e alocao de memria RAM;
STARTUP_DELAY: define um intervalo aleatoriamente onde os ns iro iniciar;
APP_SAMPLE_INTERVAL: defini o sensor de amostragem peridica. Geralmente no utilizado;
CIRCUITS_PREPARE_DELAY: defini um bit extra que serve para iniciar o atraso. Este bit faz com que o mdulo de aplicao, o rdio e o mdulo MAC acordem;
BROADCAST_ADDR: define o endereo de broadcast para os pacotes de dados.
8.1.2. Mdulo de inicializao

O mtodo void template_ApplicationModule::initialize() atribui ao mdulo as variveis independentes self, self_xCoo e self_yCoo. Estas variveis informa a identificao e a localizao exata de cada n e so definidas no arquivo
Template_ApplicationModule.h. void template_ApplicationModule::initialize() { self = parentModule()->index(); self_xCoo = parentModule()->par("xCoor"); self_yCoo = parentModule()->par("yCoor"); .......... .......... cpuClockDrift = resMgrModule->getCPUClockDrift(); .......... .......... maxAppPacketSize = par("maxAppPacketSize"); packetHeaderOverhead = par("packetHeaderOverhead");
58
.......... .......... } Este mtodo ainda obtm o clockDrift responsvel por gerenciar os recursos e l os parmetros maxAppPacketSize e packetHeaderOverhead definidos no omnetpp.ini. Por fim, envia mensagem APP_NODE_STARTUP para o rdio e mdulos MAC atravs das funes sendDelayed e scheduleAt.
8.1.3. Mtodo handleMessage

O mtodo void template_ApplicationModule::handleMessage(cMessage *msg)
contm a maior parte do cdigo. Cada mdulo simples do OMNeT tem um mtodo handleMessage para processar as mensagens que recebe de outros selfs. Cada mdulo fica desabilitado e permanece neste estado at que receba uma mensagem APP_NODE_STARTUP. Quando uma mensagem recebida pelo APP_SELF_REQUEST_SAMPLE ele envia mensagens para o dispositivo sensor fazendo com que o mesmo responda depois de um determinado tempo. Cada mensagem escalonada mais de uma vez, alm disso, mesmo depois da mensagem ser processada recomendvel escalon-las novamente para que seja alcanado o perodo de amostragem definida pelo parmetro APP_SAMPLE_INTERVAL. O APP_DATA_PACKET analisa mensagens dos campos bsicos. Estes campos correspondem ao App_GenericDataPacket que so mensagens definidas no arquivo App_GenericDataPacket.msg. O APP_TIMER_X um temporizador, onde X pode ser de 1 8. Estes temporizadores so definidos pelo OMNeT que tem a funo de escalonar automaticamente as mensagens.
8.1.4. Mdulo de finalizao

O mtodo void template_ApplicationModule::finish() contm a sada do mdulo. Toda sada gravada no arquivo Castalia-Primary-Output. Aps este mtodo temos um mtodo auxiliar para enviar um pacote para o mdulo MAC. Caso queira enviar
59
estruturas mais complexas de dados, deve-se modificar esta funo e o Template_DataPacket.msg.
8.2. DEFININDO UM NOVO MDULO

Para realizar a simulao com Difuso Direcionada no Castalia, primeiro foi executado o script create_new_aplication.sh. Este script cria uma estrutura nova de aplicao para que seja implementado um novo cdigo. Dentro do diretrio /root/Castalia-1.3/src/Node/Application/templatApplication/
execute o script. # ./create_new_aplication DifusaoDireta /root/Castalia-1.3/src/Node/Application/ Este comando vai gerar um diretrio chamado de DifusaoDireta, onde ir conter todos os arquivos necessrios para que seja feita uma nova aplicao.
8.3. MODIFICANDO O ALGORITMO

A implementao foi feita no arquivo DifusaoDireta_ApplicationModule.cc (anexo A) dentro do mtodo void DifusaoDireta_ApplicationModule::handleMessage(cMessage *msg) (linha 72). Neste mtodo foram adicionadas duas estruturas de condies. Uma em APP_NODE_STARTUP (linha 85) e a outra em APP_DATA_PACKET (linha 117). A semntica da primeira estrutura (linhas 92, 94, 96 e 97): if (isSink): pergunta se o n uma BS. Se for entra nesta condio; send2NetworkDataPacket: envia uma mensagem para todos os ns da rede; self_xCoo e self_yCoo: imprime a coordenada da localizao exata em que a BS se encontra. A semntica da segunda estrutura (linhas 131, 133, 134, 135, 136 e 137): if (!isSink): pergunta se o n no uma BS. Se no for entra nesta condio;
60
self: imprime a identificao do n; self_xCoo e self_yCoo: imprime as coordenadas da localizao exata em que os ns se encontram;
theData: imprime a identificao da BS; rssi: indica a fora do sinal recebido em dBm entre o n e a BS.
Depois da implementao em DifusaoDireta_ApplicationModule.cc, o parmetro ALL_WSN_INCLUDES do arquivo /root/Castalia-1.3/config/makemake.conf foi editado para que o mesmo apontasse para o vinculador do sistema Castalia. Ento no final da linha (figura 23) acrescentar: -I$(SRCDIR)/Node/Application/DifusaoDireta
Figura 23. Parmetro que vincula o sistema Castalia.
Ainda no arquivo makemake.conf na seo global [SN.Node] --> Node Compound Module depois da linha (figura 24) acrescentar (figura 25):
Figura 24. Linha que contm a seo global SN.NODE.
61
Figura 25. Linha adicionada seo global SN.NODE.
Aps
configurar
makemake.conf
alterar
arquivo
DifusaoDireta_ApplicationModule.cc, deve-se executar o make para compilar a aplicao. Este comando deve ser executado dentro do diretrio /root/Castalia-1.3. # make
8.4. DEFININDO OS PARAMETROS UTILIZADOS PELO CASTALIA

Para que seja feita uma simulao baseada na modificao do arquivo DifusaoDireta_ApplicationModule.cc, deve-se criar um diretrio chamado
DifusaoDireta dentro do diretrio /root/Castalia-1.3/Simulations. O diretrio criado pode ter qualquer nome, porm para um melhor entendimento foi utilizado o mesmo nome da aplicao. # mkdir DifusaoDireta Para definir os parmetros utilizados pelo OMNeT++ e Castalia foi preciso copiar os arquivos omnetpp.ini e runValProp (script). Estes dois arquivos de configurao ficam dentro do diretrio /root/Castalia-1.3/Simulations/valuePropagation/. # cp omnetpp.ini /root/Castalia-1.3/Simulations/DifusaoDireta/ # cp runValProp /root/Castalia-1.3/Simulations/DifusaoDireta/ Depois de copiar os arquivos de configurao, o script foi renomeado com um nome relacionado ao diretrio DifusaoDireta. # mv runValProp runDifusaoDireta Dentro do script runDifusaoDireta a linha abaixo foi comentada para no gerar mais a mensagem que informa o fim da execuo do script. # echo -e "\n Castalia: All output will be written to Castalia-Primary-Output.txt \n Old Castalia-statistics.sca and Castalia-statistics.vec in the current directory will
62
be deleted.\n Be aware that Castalia-Primary-Output.txt gets *appended* each time you run the script\n" Ainda dentro do script runDifusaoDireta foram adicionadas as linhas: if [ -a Castalia-Primary-Output.txt ]; then rm -f Castalia-Primary-Output.txt fi if [ -a Castalia-Debug.txt ]; then rm -f Castalia-Debug.txt fi O primeiro if remove o arquivo de sada Castalia-Primary-Output.txt antigo quando o script for executado e o segundo remove o arquivo Castalia-Debug.txt. Este arquivo imprime informaes de depurao do Castalia. O outro arquivo omnetpp.ini (anexo B) ser utilizado para definir os parmetros utilizados pelo OMNeT++ e Castalia. Neste arquivo foi alterada a durao do tempo de simulao (linha 7), a largura (linha 20) e comprimento (linha 21) da rea onde os sensores sero depositados, a quantidade de ns jogados na rea a ser simulada (linha 22), o nome da aplicao ativa que ser utilizado na simulao (linhas 37 e 38) e o n sink (linha 72).
63
9. SIMULAES E TESTES COM DIFUSO DIRETA

Este captulo apresenta trs simulaes utilizando a implementao modificada do mdulo DifusaoDireta_ApplicationModule.cc (anexo A) e dos parmetros do arquivo omnetpp.ini para avaliar o desempenho do protocolo de Difuso Direta em uma rede de RSSF.
9.1. SIMULAO 1
Esta simulao foi feita da seguinte maneira: o primeiro passo foi alterar o arquivo omnetpp.ini (anexo B). Nesse arquivo inseriu-se um tempo de durao de simulao de 600ms (linha 7), aps isso, foi definido um cenrio com uma rea de 10m x 10m (linha 20 e linha 21) numa rede contendo 100 ns sensores (linha 22). O n 3 foi definido como estao-base (BS) (linha 72). Depois de alterar os parmetros do arquivo omnetpp.ini, executou-se o script runDifusaoDireta localizado no diretrio /root/Castalia-1.3/Simulations/DifusaoDireta/. # ./runDifusaoDireta Este script gerou os arquivos Castalia-Primary-Output.txt e Castalia-Debug.txt. O arquivo Castalia-Primary-Output.txt informa a posio (x, y) da BS e a posio (x, y), identificao e o RSSI dos ns que transmitiram e receberam pacotes com a BS. O arquivo Castalia-Debug.txt informa a posio (x, y) de todos os sensores depositados na rede, a quantidade de pacotes recebidos, a quantidade de interferncias, colises e erros dos ns sensores. Foi necessrio implementar um script com a funo de gerar os seguintes arquivos: PosicaoSink.txt: informa a posio (x, y) da BS; PosicaoNodos-Dominados.txt: informa a posio (x, y) dos ns que se comunicaram com a BS; PosicaoNodos-NaoDominados.txt: informa a posio (x, y) dos ns que no se comunicaram com a BS;
64
PosicaoNodos.txt: informa a posio (x, y) de todos os ns da rede; SetLabels.txt: informa a identificao dos ns; SetLabelsNodos-Dominados.txt: informa a identificao dos ns que se comunicaram com a BS;
SetLabelsNodos-NaoDominados.txt: informa a identificao dos ns que no se comunicaram com a BS.
Alm disso, foram criados mais trs scripts para plotar os grficos: o gnuplotgrafo.cmd que tem a funo de plotar um grfico com os ns que se comunicaram e no se comunicaram com a BS (figura 26), o gnuplot-grafo-dominados.cmd que tem a funo de plotar um grfico com os ns que se comunicaram com a BS (figura 27) e gnuplot-grafo-no-dominados.cmd que tem a funo de plotar um grfico com os ns que no se comunicaram com a BS (figura 28).
Figura 26. Ns que se comunicaram e no se comunicaram com a BS.
65
Figura 27. Ns que conseguiram se comunicar com a BS.
Figura 28. Ns que no se comunicaram com a BS.
66
Como visto (figura 26) o n 3 est definido como BS (bola vermelha) e est localizado em x = 7.48804 e y = 8.31911. A BS difunde seu interesse na rede atravs de broadcast. Dos 100 ns depositados, apenas 20 (bolas azuis) conseguem se comunicar com a BS numa rea de 10m x 10m. Os outros ns (tringulos verdes) no conseguiram se comunicar devido a falhas (caminhos quebrados entre o n fonte e a BS), interferncias e colises. Toma-se como exemplo o n 16 que apesar de estar mais prximo da BS no consegue se comunicar e o n 70 que mesmo estando mais distante consegue manter uma comunicao com BS.
9.2. SIMULAO 2
Nesta simulao (figura 29) foi definido um tempo de durao de simulao de 600ms, e um cenrio com uma rea de 40m x 40m numa rede contendo 100 ns sensores. O n 3 foi definido como estao-base (BS).
Quando a rea foi aumentada de 10m x 10m (figura 26) para 40m x 40m (figura 29), porm com a mesma quantidade de sensores e mesma BS, verificou-se que dos
67
100 ns depositados na rede apenas 11 (bolas azuis) conseguiram se comunicar com a BS (bola vermelha). Como teve um aumento na rea a ser monitorada a potncia do sinal recebido entre a BS e os alguns ns ficou abaixo do ideal provocando desta forma um erro de comunicao. De acordo com Friis (1946), a equao para calcular a potncia do sinal recebido em um espao livre a uma distncia d do transmissor :
Onde PT a potncia do sinal transmitido, GT e GR so os ganhos de transmisso e recepo da antena. L (L 1) a perda do sistema e o comprimento de onda. Este modelo de espao livre representa uma comunicao com um raio em volta do transmissor. Se o pacote estiver dentro deste raio haver transmisso e recepo entre a BS e os ns, caso contrrio todos os pacotes sero perdidos. Alm disso, alguns ns mais prximos da BS no conseguiram se comunicar devido a falhas (caminhos quebrados entre o n fonte e a BS), interferncias e colises.
9.3. SIMULAO 3
Nesta simulao foi mantido o mesmo tempo de durao de simulao, ou seja, 600ms. O cenrio continuou com 40m x 40m, assim como se manteve em 100 a quantidade de ns depositados na rede. O n 95 foi definido como BS. Verificou-se (figura 32) que quando a BS (bola vermelha) foi mudada do n 3 (figura 29) para o n 95 com localizao em x = 19.8019 e y = 19.4621, a quantidade de ns (bolas azuis) que conseguiram se comunicar com a BS aumentou significativamente para 57. Isso se deve ao fato do n 95 est localizado praticamente no centro da rea a ser monitorada, fazendo com que o raio de alcance do seu sinal atinja maiores quantidade de ns na rede.
68
Os outros ns (tringulos verdes) no conseguiram se comunicar com a BS devido a falhas (caminhos quebrados entre o n fonte e a BS), interferncias e colises.
69
CONSIDERAES
A realizao deste trabalho mostrou o comportamento do protocolo de Difuso Direta em uma RSSF. O protocolo de Difuso Direta difere de outros protocolos de roteamento plano no mecanismo de consulta de dados. Na Difuso Direta a BS pergunta para os ns sensores se um determinado dado est disponvel atravs de broadcast na rede com alguns interesses. Toda a comunicao feita de vizinho para vizinho sem necessidade de endereamento de ns, alm disso, eficiente no consumo de energia devido demanda de consulta e por no necessitar de gerenciamento global da topologia da rede. Porm, a Difuso Direta no pode ser usada em todas as aplicaes de RSSF, devido ao seu modelo de entrega de dados ser baseado em consulta. Este processo de comparao de dados e consultas possui um alto custo. Aplicaes que precisam entregar dados contnuos para a BS no funcionaro com eficincia neste modelo. Um exemplo seria aplicaes de monitoramento ambiental e agricultura. A proposta inicial deste trabalho era alterar e simular o protocolo de clusterizao LEACH para redes de sensores sem fio, porm a dificuldade e pouco tempo para a realizao dos estudos necessrios para a implementao deste protocolo fez com que fosse mudado o escopo do projeto. Todo o trabalho foi feito em cima de software livre. Foi utilizado o Sistema Operacional Debian Etch 4 GNU/Linux para instalao e configurao do simulador de eventos discretos OMNeT++ e Castalia. A linguagem utilizada para implementar o mdulo de aplicao com Difuso Direta foi C++. E por fim, para plotar os grficos foi necessrio instalar o gnuplot. Com as simulaes pode-se verificar que o uso de simuladores para rede de sensores sem fio apresenta diversas vantagens para pesquisadores que desejam desenvolver uma aplicao especfica ou simular os protocolos existentes atuais. Como trabalho futuro, podemos sugerir: realizao de testes para determinar o consumo de potncia dos sensores no protocolo de Difuso Direta; anlise do
70
protocolo SPIN; comparar o desempenho do protocolo SPIN com o protocolo de Difuso Direta; alterar e simular o protocolo de clusterizao LEACH.
71
REFERNCIAS
AKYILDIZ, I. F. SU, W. SANKARASUBRAMANIAM, Y. A survey on sensor networks. IEEE Communication Magazine, v. 40, n. 8, p. 102114, Agosto 2002. AQUINO, J. F. S. Eleio de Clusters Heads em Algoritmos de Roteamento Hierrquico para Redes de Sensores sem Fio, Universidade Catlica do Rio de Janeiro Rio de Janeiro - RJ, 2007. ATEMU. Simulador Sensor ATmel EMUlator (ATEMU). Disponvel em:
<http://www.hynet.umd.edu/research/atemu/>. Acesso em 31/03/2009. CABRINI, F. H. Caracterizao e Anlise de Desempenho de uma Rede de Sensores Sem Fio, Tese de Mestrado, Universidade de So Paulo So Paulo SP, 2006. CABRINI, F. H., Kofuji S. T. Roteamento em Redes de Sensores Sem Fio, Laboratrio de Sistemas Integrveis - Universidade de So Paulo So Paulo SP, 2006. CASTALIA, A Simulator for WSNs. Disponvel em:
<http://castalia.npc.nicta.com.au/>. Acesso em 05/04/2009. CURREN, D. A Survey of Simulation in Sensor Networks, Technical report, University of Binghamton. CORREIA, A. H. L. et all. Uma Taxonomia para Protocolos de Controle de Acesso ao Meio em Redes de Sensores Sem Fio, Universidade Federal de Minas Gerais - Belo Horizonte MG, 2005. DUST, S. Smart Dust: Autonomous sensing and communication in a cubic millimeter. http://robotics.eecs.berkeley.edu/~pister/SmartDust (2004). FRIIS H. T. A note on a simple transmission formula. Proc. IRE, 34, 1946. GANG L. et all. "An Adaptive Energy-Efficient and Low-Latency MAC for Data Gathering in Wireless Sensor Networks", Proc. 18th Intl. Parallel and Distrib. Processing Symp. abril 2004, pg. 224.
72
HEIDEMANN, J., Silva, F., Intanagonwiwat, C., Govindan, R., Estrin, D., and Ganesan, D. (2001). Building efficient wireless sensor networks with low-level naming. In Proceedings of the Symposium on Operating Systems Principles, pages 146-159, Chateau Lake Louise, Banff, Alberta, Canada. HEINZELMAN, W. R, et all, Energy-Efficient Communication Protocol for Wireless Microsensor Networks, IEEE Proc. Hawaii Intl. Conf. Sys. Sci., Jan. 2000. HEINZELMAN, W. R, et all, Adaptive Protocols for Information Dissemination in Wireless Sensor Networks, Massachusetts Institute of Technology Cambridge, 1999. INTANAGONWIWAT, C. et all. A Scalable and Robust Communication Paradigm for Sensor Network, USC / Information Sciences Institute Los Angeles, 2000. JNIOR, C. L. F. Desenvolvimento de Dispositivo N Sensor com Arquitetura Reconfigurvel para Redes de Sensores Sem Fio, Tese de Mestrado, Universidade Federal de Minas Gerais Belo Horizonte MG, 2004. LEE, S. H. K. and Park C. Distributed clustering for wireless sensor networks. International Symposium on Communications and Information Technologies, p. 1113-1117, 2006. LEE, N. and LEVIS P. TOSSIM: A Simulator for TinyOS Networks.
http://www.cs.berkeley.edu/~pal/pubs/nido.pdf, 2003. LINDSEY, S. and Raghavendra, C. S. (2002). Pegasis: Power-efficient gathering in sensor information systems. In Proceeding of the IEEE Aerospace Conference. LOUREIRO, A. A. F. et all. Redes de Sensores Sem Fio, Universidade Federal de Minas Gerais - Belo Horizonte MG, 2003. OMNet++. Simulador OMNET++ (sigla estendida). Disponvel em:
<http://www.omnetpp.org/>. Acesso em: 01/04/2009. OTHMAN, N. Y. et al. A web services-based architecture for the interactions between end-user applications and sink-less wireless sensor networks. 4th
73
IEEE Consumer Communications and Networking Conference, p. 865869, Janeiro 2007. CCNC 2007. PASSOS, R. M. S. Gerenciamento Dinmico de Energia em Redes de Sensores Sem Fio, Tese de Mestrado, Universidade Federal de Minas Gerais - Belo Horizonte BH, 2005. PEREIRA, M. R., AMORIM, C. L. e CASTRO, M. C. S. Tutorial sobre Rede de Sensores, Universidade Estadual do Rio de Janeiro Rio de Janeiro RJ, 2003. POLASTRE, J. et all. Versatile Low Power Media Access for Wireless Sensor Networks, Proceedings of the 2nd international conference on Embedded networked sensor systems, p. 95-107, ACM Press, Baltimore, EUA, Novembro, 2004. POLLEY, J. Blazakis, D. et all. ATEMU: a Fine-grained Sensor Network Simulator, in 'Proc. First Annual IEEE Communications Society Conference on Sensor and Ad Hoc Communications and Networks IEEE SECON 2004', pp. 145--152. RUIZ, L. B. MANNA: Uma Arquitetura para o Gerenciamento de Redes de Sensores Sem Fio, Tese de doutorado, Universidade Federal de Minas Gerais, dezembro de 2003. RUIZ, L. B., et all. Arquitetura para Redes de Sensores Sem Fio, Departamento de Cincia da Computao, Universidade Federal de Minas Gerais, 2004. SANKARASUBRAMANIAM, Y., Akan, O. B., and Akyildiz, I. F. (2003). ESRT: eventto-sink reliable transport in wireless sensor networks. In Proceedings of the 4th ACM international symposium on Mobile ad hoc networking & computing, p. 177-188. ACM Press. SHEN, C., et all. Sensor Information Networking Architecture and Applications, IEEE Pers. Commun., Aug. 2001, p. 5259 SILVA, F. A., RUIZ, L. B., ET all. Tecnologia de Ns Sensores Sem Fio, Universidade Federal de Minas Gerais - Belo Horizonte MG, 2003. SILVA, P. H. G. Survey em Redes de Sensores Sem Fio, M0611 Teleprocessamento e Redes, 10 de Julho de 2007.
74
STANN, F. and Heidemann, J. (2003). Rmst: Reliable data transport in sensor networks. In Proceedings of the First International Workshop on Sensor Net Protoc ols and Applications, p. 102-112, Anchorage, Alaska, USA. IEEE. The Network Simulator - NS-2. Disponvel em: <http://www.isi.edu/nsnam/ns/>. Acesso em: 26/03/2009. VIEIRA, M. A. M. et all. Como obter o Mapa de Energia em Rede de Sensores Sem Fio? Uma Abordagem Tolerante a Falhas, UFMG Belo Horizonte - MG e PUC-PR Curitiba-Paran, 2001. VIEIRA, M. A. M. Uma Plataforma Computacional para Rede de Sensores Sem Fio, Tese de Mestrado, Universidade Federal de Minas Gerais Belo Horizonte MG, 2004. WAN, C.-Y., Campbell, A. T., and Krishnamurthy, L. (2002). PSFQ: a reliable transport protocol for wireless sensor networks. In Proceedings of the 1st ACM international workshop on Wireless sensor networks and applications, pages 1-11. ACM Press. WEI, D. e CHAN, H. A. A Survey on Cluster Schemes in Ad Hoc Wireless Networks, IEEE Mobility Conference - GuangZhou, 2005. YE, W., Heidemann, J., and Estrin, D. (2002). An energy-efficient mac protocol for wireless sensor networks. In Proceedings of the IEEE Infocom, p. 1567-1576, New York, NY, USA. USC/Information Sciences Institute, IEEE.
75
ANEXO A Arquivo DifusaoDireta_ApplicationModule.cc

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 #include "DifusaoDireta_ApplicationModule.h" #define EV ev.disabled()?(ostream&)ev:ev
#define CASTALIA_DEBUG (!printDebugInfo)?(ostream&)DebugInfoWriter:: getStream():DebugInfoWriter::getStream() #define DRIFTED_TIME(time) ((time) * cpuClockDrift) #define MEMORY_PROFILE_STORE(numBytes) resMgrModule->RamStore(numBytes) #define MEMORY_PROFILE_FREE(numBytes) resMgrModule->RamFree(numBytes) #define STARTUP_DELAY 0.05 #define APP_SAMPLE_INTERVAL 0.5 #define CIRCUITS_PREPARE_DELAY 0.001 #include "DifusaoDireta_radioControlImpl.cc.inc" #include "DifusaoDireta_tunableMacControlImpl.cc.inc" Define_Module(DifusaoDireta_ApplicationModule); void DifusaoDireta_ApplicationModule::initialize() { self = parentModule()->index(); self_xCoo = parentModule()->par("xCoor"); self_yCoo = parentModule()->par("yCoor"); cModule *parent = parentModule(); if(parent->findSubmodule("nodeResourceMgr") != -1) { resMgrModule = check_and_cast<ResourceGenericManager*>(parent>submodule("nodeResourceMgr")); } else opp_error("\n[Application]:\n Error in geting a valid reference to nodeResourceMgr for direct method calls."); cpuClockDrift = resMgrModule->getCPUClockDrift(); disabled = 1; const char * tmpID = par("applicationID"); applicationID.assign(tmpID); printDebugInfo = par("printDebugInfo"); priority = par("priority"); maxAppPacketSize = par("maxAppPacketSize"); packetHeaderOverhead = par("packetHeaderOverhead"); constantDataPayload = par("constantDataPayload"); isSink = par("isSink"); char buff[30]; sprintf(buff, "Application Vector of Node %d", self); appVector.setName(buff); double random_startup_delay = genk_dblrand(0) * STARTUP_DELAY + CIRCUITS_PREPARE_DELAY;
76
58 sendDelayed(new App_ControlMessage("Application --> Sensor Dev Mgr 59 [STARTUP]", APP_NODE_STARTUP), simTime() + 60 DRIFTED_TIME(random_startup_delay), "toSensorDeviceManager"); 61 62 sendDelayed(new App_ControlMessage("Application --> Network 63 [STARTUP]", APP_NODE_STARTUP), simTime() + 64 DRIFTED_TIME(random_startup_delay), "toCommunicationModule"); 65 66 scheduleAt(simTime() + DRIFTED_TIME(random_startup_delay), new 67 App_ControlMessage("Application --> Application (self)", 68 APP_NODE_STARTUP)); 69 70 } 71 72 void DifusaoDireta_ApplicationModule::handleMessage(cMessage *msg) 73 { 74 int msgKind = msg->kind(); 75 76 if((disabled) && (msgKind != APP_NODE_STARTUP)) 77 { 78 delete msg; 79 msg = NULL; // safeguard 80 return; 81 } 82 83 switch (msgKind) 84 { 85 case APP_NODE_STARTUP: 86 { 87 disabled = 0; 88 89 scheduleAt(simTime(), new App_ControlMessage("Application 90 self message (request sample)",APP_SELF_REQUEST_SAMPLE)); 91 92 if (isSink) 93 { 94 send2NetworkDataPacket(BROADCAST, self, 0); 95 cout << "\n"; 96 cout << "Localizao da BS (X,Y) = " << self_xCoo << 97 ", " << self_yCoo << "\n""\n"; 98 } 99 100 scheduleAt(simTime(), new App_ControlMessage("timer 1", 101 APP_TIMER_1)); 102 103 break; 104 } 105 106 case APP_SELF_REQUEST_SAMPLE: 107 { 108 requestSampleFromSensorManager(); 109 110 scheduleAt(simTime()+DRIFTED_TIME(APP_SAMPLE_INTERVAL), 111 new App_ControlMessage("Application self message (request 112 sample)", APP_SELF_REQUEST_SAMPLE)); 113 114 break; 115 } 116 117 case APP_DATA_PACKET: 118 {
77
119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179
DifusaoDireta_DataPacket *rcvPacket; rcvPacket = check_and_cast<DifusaoDireta_DataPacket *>(msg); string msgSender(rcvPacket->getHeader().source.c_str());

string msgDestination(rcvPacket-getHeader().destination.c_str());
int theData = rcvPacket->getData(); int sequenceNumber = rcvPacket->getHeader().seqNumber; double rssi = rcvPacket->getRssi();

string pathFromSource(rcvPacket->getCurrentPathFromSource());
if (!isSink) { cout << "Eu sou o n: " << self << "\n"; cout << "Minha localizao (X,Y) = " << self_xCoo << ", " << self_yCoo << "\n"; cout << "A Estacao Base : " << theData << "\n"; cout << "RSSI: " << rssi << "\n""\n"; } break; } case APP_TIMER_1: { /*** *** ADD YOUR CODE HERE (optional) ***/ //Example : how to broadcast a value /* * int data2send = 10000; * send2NetworkDataPacket(BROADCAST_ADDR, data2send, 1); */ break; } case APP_TIMER_2: { /*** *** ADD YOUR CODE HERE (optional) ***/ break; } case APP_TIMER_3: { /*** *** ADD YOUR CODE HERE (optional) ***/ break; }
case SDM_2_APP_SENSOR_READING: { SensorDevMgr_GenericMessage *rcvReading;

rcvReading = check_and_cast<SensorDevMgr_GenericMessage*>(msg);
78
180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240
int sensIndex = rcvReading->getSensorIndex(); string sensType(rcvReading->getSensorType()); double sensValue = rcvReading->getSensedValue(); break; }
case RESOURCE_MGR_OUT_OF_ENERGY: { disabled = 1; break; } case RESOURCE_MGR_DESTROY_NODE: { disabled = 1; break; }
case NETWORK_2_APP_FULL_BUFFER: { CASTALIA_DEBUG << "\n[Application_"<< self <<"] t= " << simTime() << ": WARNING: NETWORK_2_APP_FULL_BUFFER received because the Network buffer is full.\n"; break; }
case NETWORK_2_APP_TREE_LEVEL_UPDATED: { Network_ControlMessage *levelMsg = check_and_cast< Network_ControlMessage *>(msg); //int routingLevel = levelMsg->getLevel(); break; } case NETWORK_2_APP_CONNECTED_2_TREE: { Network_ControlMessage *connectedMsg = check_and_cast< Network_ControlMessage *>(msg); int routingLevel = connectedMsg->getLevel(); int sinkID = connectedMsg->getSinkID(); string parents; parents.assign(connectedMsg->getParents()); break; } case NETWORK_2_APP_NOT_CONNECTED: { break; } default: {
79
241 242
CASTALIA_DEBUG << "\\n[Application_"<< self <<"] t= " << simTime() << ": WARNING: received packet of unknown type";
243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301
break; } } delete msg; msg = NULL; } void DifusaoDireta_ApplicationModule::finish() { EV << "Node [" << self << "] spent energy: " << resMgrModule>getSpentEnergy() << "\n"; DebugInfoWriter::closeStream(); } void DifusaoDireta_ApplicationModule::send2NetworkDataPacket(const char *destID, int data, int pckSeqNumber) { if(!disabled) { DifusaoDireta_DataPacket *packet2Net; packet2Net = new DifusaoDireta_DataPacket("Application Packet Application->Mac", APP_DATA_PACKET); packet2Net->setData(data); packet2Net->getHeader().applicationID = applicationID.c_str(); char tmpAddr[256]; sprintf(tmpAddr, "%i", self); packet2Net->getHeader().source = tmpAddr; packet2Net->getHeader().destination = destID; packet2Net->getHeader().seqNumber = pckSeqNumber; if(constantDataPayload != 0) packet2Net->setByteLength(constantDataPayload + packetHeaderOverhead); else
packet2Net->setByteLength(sizeof(data) + packetHeaderOverhead);
// safeguard
send(packet2Net, "toCommunicationModule"); } } void DifusaoDireta_ApplicationModule::requestSampleFromSensorManager() { SensorDevMgr_GenericMessage *reqMsg; reqMsg = new SensorDevMgr_GenericMessage("app 2 sensor dev manager (Sample request)", APP_2_SDM_SAMPLE_REQUEST); reqMsg->setSensorIndex(0); send(reqMsg, "toSensorDeviceManager"); }
80
ANEXO B Arquivo omnetpp.ini

1 [General] 3 preload-ned-files = *.ned @../../nedfiles.lst 4 include ../Parameter_Include_Files/general_and_RNGs.ini 6 # Duracao do tempo de simulacao. 7 sim-time-limit = 600s 9 # Arquivos de saida. Pode ser escalar ou vetorial. 10 output-vector-file = Castalia-statistics.vec 11 output-scalar-file = Castalia-statistics.sca 13 [Cmdenv] 14 include ../Parameter_Include_Files/omnet_cmdenv_reporting.ini 16 [Parameters] 17 # Nome do arquivo que depura sada de escrita. 18 SN.debugInfoFilename = "Castalia-Debug.txt" 20 SN.field_x = 10 21 SN.field_y = 10 22 SN.numNodes = 100 23 SN.deploymentType = 0 # Largura da rea onde o sensor ser depositado. # Comprimento da rea onde o sensor ser depositado. # Define a quantidade de ns da rede. # Desenvolvimento random uniformeme dentro da rede.
25 # Quantidade de processos fsicos utilizado pela aplicao. 26 SN.numPhysicalProcesses = 1 28 include ../Parameter_Include_Files/physicalProcess_0_node6_asssignedValue40.ini 29 include ../Parameter_Include_Files/resourceMgr_2AAbatteries.ini 30 include ../Parameter_Include_Files/nodeSensorDevMgr_Temperature.ini 31 include ../Parameter_Include_Files/WChannel/Additive_Interference_Modell/WChannel_Realistic.ini 32 include ../Parameter_Include_Files/Radio/TelosB_CC2420/radio_CC2420.ini 33 include ../Parameter_Include_Files/MAC_just_carrierSense.ini 34 include ../Parameter_Include_Files/Routing_bypass.ini 36 # Define o modulo da aplicao utilizada na simulao. 37 SN.node[*].appModuleName = "DifusaoDireta_ApplicationModule" 38 SN.node[*].nodeApplication.applicationID = "DifusaoDireta" 39 SN.node[*].nodeApplication.printDebugInfo = true 40 SN.node[*].nodeApplication.priority = 1 41 SN.node[*].nodeApplication.maxSampleInterval = 60000 42 SN.node[*].nodeApplication.minSampleInterval = 1000 43 SN.node[*].nodeApplication.isSink = false 45 # Total bytes (|*|) 8 + 2 = 10 (aplicacao constante de tamanho de pacote). 46 SN.node[*].nodeApplication.maxAppPacketSize = 30 # em bytes 47 SN.node[*].nodeApplication.packetHeaderOverhead = 8 # em bytes 48 SN.node[*].nodeApplication.constantDataPayload = 2 # em bytes 50 # Define a quantidade de execucoes/simulaes. 51 [Run 1] 52 description = "Run 1" 53 seed-0-mt = 10 54 seed-1-mt = 111 55 seed-2-mt = 211 56 seed-3-mt = 40
81
57 seed-4-mt = 50 58 seed-5-mt = 60 59 seed-6-mt = 70 60 seed-7-mt = 80 61 seed-8-mt = 90 63 SN.wirelessChannel.printDebugInfo = true 65 SN.node[*].networkInterface.Radio.txPowerLevelUsed = 2 66 SN.node[*].networkInterface.Radio.printDebugInfo = true 68 SN.node[*].networkInterface.Network.maxNumberOfParents = 1 69 SN.node[*].networkInterface.Network.rssiBased_NeighborQuality = true 70 SN.node[*].networkInterface.Network.neighbor_RSSIThreshold = -89.3 # Fora do sinal em dBm 72 SN.node[3].nodeApplication.isSink = true

Uma Simulação Do Protocolo de Difusão Direta para Redes de Sensores Sem Fio

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Uma Simulação Do Protocolo de Difusão Direta para Redes de Sensores Sem Fio

Enviado por

Direitos autorais:

Formatos disponíveis

CENTRO UNIVERSITRIO DA BAHIA FACULDADE DE CINCIAS EXATAS E TECNOLOGIA BACHARELADO EM CINCIA DA COMPUTAO

GILDSIO ANTONIO DE OLIVEIRA JNIOR

GILDSIO ANTONIO DE OLIVEIRA JNIOR

GILDSIO ANTONIO DE OLIVEIRA JNIOR

Salvador, 25 de Junho de 2009

LISTA DE SIGLAS E ABREVIATURAS

Figura 1. Aplicabilidade das Redes Sensores. Fonte: JNIOR (2004, p. 1).

(a) Rede com infra-estrutura

(b) Rede sem infra-estrutura

Figura 2. Tipos de Redes Sem Fio. Fonte: LOUREIRO (2004, p. 3).

1.1. EXEMPLOS DE APLICAES

Figura 3. Sensores para detectar militares/viaturas. Fonte: http://web.tagus.ist.utl.pt/~rafael.aranha/WSN/

Figura 4. Sensores fazendo a integrao dos componentes da casa.

Figura 5. Sensor utilizado para monitorar desempenho de atletas. Fonte: http://www.techzine.com.br

1.2. DISTRIBUIO DOS NS SENSORES

1.3. CONSUMO DE ENERGIA

Figura 6. Clusterizao de ns sensores. Fonte: WEI e CHAN (2005, p. 1).

2. ELEMENTOS DE UMA REDE DE SENSORES SEM FIO

Figura 7. Transmisso multi-hop. Fonte: SILVA (2003, p. 3).

Figura 8. Formao em blocos de um n sensor. Fonte: LOUREIRO (2003, p. 10).

Sensor MicroStain RFID

Sensor Intel Mote

JPL: Sensor Webs

Figura 9. Dispositivos ns sensores. Fonte: JNIOR (2004, p. 16).

2.2. NS DE ROTEAMENTO (NS GATEWAY)

Figura 10. Rede RSSF com n gateway. Fonte: OTHMAN (2007)

3. DIAGRAMA DE BLOCOS DE UM N SENSOR COM OS MODULOS

3.1. UNIDADE DE ENERGIA

Quadro 1: Diferentes fontes energticas. Fonte: SILVA (2003, p. 5).

3.2. UNIDADE DE COMUNICAO

Quadro 2: Transceptores e suas caractersticas. Fonte: CORREIA (2005, p. 4).

Quadro 3: Consumo do Mica Motes2. Fonte: CORREIA (2005, p. 3).

3.3. UNIDADE DE SENSORIAMENTO

3.4. UNIDADE DE COMPUTAO

4. CLASSIFICAO DE REDES DE SENSORES SEM FIO

5. PROTOCOLOS PARA REDES DE SENSORES SEM FIO

5.1. CAMADA FSICA

5.1.1. Comunicao ptica

5.1.2. Comunicao Rdio Freqncia (RF)

5.1.3. Comunicao infravermelha

5.2. CAMADA DE ENLACE

5.2.1. Protocolo B-MAC

5.2.2. Protocolo S-MAC

5.2.3. Protocolo D-MAC

5.3. CAMADA DE REDE

(a) Roteamento plano

(b) Roteamento hierrquico

Figura 14. Diviso de roteamento em uma RSSF.

5.3.1. Protocolo de Difuso Direta

(a) Interesse de propagao

(b) Criao do gradiente

c) Caminho/entrega dos dados

Figura 15. Exemplo de Difuso Direta. Fonte: INTANAGONWIWAT (2000, p. 56).

5.3.2. Protocolo SPIN

5.3.3. Protocolo LEACH

5.3.4. Protocolo PEGASIS

Figura 16. Funcionamento do PEGASIS.

5.3.5. Protocolo CODA

5.4. CAMADA DE TRANSPORTE

5.4.1. Protocolo PSFQ

push: utiliza saltos de n em n no caminho at o destinatrio para enviar fragmentos de mensagens;

5.4.2. Protocolo ESRT

5.4.3. Protocolo RMST

DifusaoDireta_DataPacket rcvPacket; rcvPacket = check_and_cast<DifusaoDireta_DataPacket >(msg); string msgSender(rcvPacket->getHeader().source.c_str());