4 - Modelagem em Castalia

Este captulo explica como Castalia modela os diferentes aspectos de uma rede de sensores sem fio de comunicao para processo fsico. Ele tambm d uma descrio detalhada de todos os mdulos no-compostos e seus parmetros. Este captulo a sua referncia para entender como usar os diferentes mdulos e o que voc pode fazer com eles. A nica coisa comum que podemos citar para todos os mdulos no-composto em Castalia que todos eles tm um parmetro chamado collectTraceInfo. Este definido por padro como "false". Se definido como "true", o mdulo ir produzir informaes de rastreamento que ser escrito no arquivo CastaliaTrace.txt. J vimos exemplos disso no Captulo 3. Comunicao o aspecto mais cuidadosamente modelado do simulador Castalia. Do canal sem fio para o comportamento do rdio e a implementao de diferentes protocolos MAC, ns tentamos capturar a essncia e muitos detalhes de suas contrapartes reais.

4.1. O canal Wireless

O canal sem fio um meio notoriamente difcil para modelar, especialmente quando se leva em conta os ns mveis, um ambiente em mudana (por exemplo, no caso BAN: o corpo em movimento) e comunicaes de broadband (banda larga). Embora haja um corpus grande de resultados tericos e medidas experimentais para comunicao sem fio em geral, eles tendem a afetar praticamente reas com mais impacto comercial, como a comunicao celular e, recentemente, WiMAX. As redes mveis ad hoc e redes de sensores sem fio no ganharam tanto com os avanos de modelagem de comunicao sem fio. Existem vrias razes para isso, as principais so: 1) problema mais complicado, 2) comparativamente menores benefcios comerciais imediatos e tangveis para permitir o trabalho caro e tedioso de medidas detalhadas e modelagem, e 3) pesquisadores oriundos principalmente do CS, networking background (segundo plano de rede), sem um profundo conhecimento e interesse na camada fsica. No entanto, alguns pesquisadores na comunidade assumiram o papel to necessrio e produziram modelos que se encaixam dados experimentais, pelo menos para alguns aspectos importantes. O interesse recente com Body Area Networks e os prximos padres IEEE BAN criou outro momento importante. Por exemplo, na NICTA, criamos bancos de ensaio experimental para capturar centenas de milhares de medies. Essas medies so analisadas para fornecer modelos precisos para ambas, as perdas caminho mdio em torno do corpo, e mais importante, o comportamento da variao temporal do canal. Estamos confiantes para afirmar que, relativo ao canal wireless, Castalia o simulador mais realista que pode-se encontrar para RSSF e BAN. A palavra "realista" aqui usado no sentido de que o simulador est fazendo as disposies necessrias para capturar vrias caractersticas importantes do canal wireless. Para se ter resultados que refletem com preciso a realidade seria necessrio apropriados parmetros de entrada e arquivos de entrada. Em palavras simples, preciso "ajustar" o simulador direito. Nos exemplos de simulao fornecidos com a distribuio de Castalia, muitos dos parmetros so definidos em valores razoveis que refletem uma situao real, embora alguns - especialmente grandes arquivos de entrada de modelagem variao temporal - no so livremente disponveis e so propriedade intelectual da NICTA. NICTA est interessado em vrias formas de colaborao, por isso voc est convidado a nos contatar a respeito de arquivos de entrada mais precisos.

4.1.1 Modelagem de perda caminho mdio

4.1.2 Permitindo a mobilidade dos ns

4.1.3 Modelagem de variao temporal

4.1.4 Entregando os sinais para o mdulo de rdio 4.1.5 Escolhendo modelos naive (ingnuo, simples) pag 59 Seria til para definir os modelos mais simples (at o modelo de disco bastante simplista) de modo que os resultados da simulao podem ser comparados com resultados de outros simuladores e mais importante, de modo que o usurio pode testar diferentes hipteses sobre o porqu de um algoritmo distribudo no funciona (ou est aqum) quando as suposies mais realistas so tidos em conta. Isto especialmente verdade com os modelos de comunicao, especialmente os de nvel inferior (canal e rdio). Em um arquivo omnetpp.ini, podemos fazer o canal wireless mais simples simplesmente definindo: SN.wirelessChannel.sigma = 0 SN.wirelessChannel.bidirectionalSigma = 0 Desta forma, todos ns a uma certa distncia de um transmissor obtm a fora do sinal exatamente a mesma e todas os links so perfeitamente bidirecional (ou seja, a qualidade de AB a mesma que a qualidade de BA). Se ns podemos tambm fornecer limiares ntidos para a recepo de rdio (ou seja, recepo perfeita de um pacote ou no recepo em todos), ento vamos acabar com o modelo de disco de unidade simples. De fato, para todos os rdios que temos definido, ns fornecemos um modo especial com um esquema de modulao ideal. Para escolh-la, basta definir: SN.node[*].Communication.Radio.mode = "IDEAL" Assim, definindo os dois sigmas do canal wireless para 0 e o modo de rdio para "IDEAL" um usurio pode emular o naive - mas ainda prevalente - unit disk communication mode (ou seja, as transmisses dentro de um determinado intervalo de um transmissor so perfeitamente recebidas, e fora deste intervalo no recebe nada). Quando adotando um unit disk model, um usurio pode controlar a faixa do disco, controlando o parmetro SN.wirelessChannel.PLd0. Suponha que voc precisa de um intervalo do disco sendo 50m, ento voc deve definir PLd0 = (TxPowerUsed_dBm - max (receiverSensitivity, noisefloor 5 dBm)) - 10 * pathLossExponent * log (50). O usurio pode ainda jogar com o parmetro collisionModel do mdulo de rdio para obter modelos mais simples. Vamos explicar isso na seo 4.2.3.

4.2. O Rdio
O mdulo de rdio tenta capturar muitas caractersticas de um rdio real de baixa potncia, um que susceptvel de ser utilizado em plataformas de rede de sensores sem fio. As principais caractersticas do nosso mdulo de rdio so: Mltiplos estados: transmitir, receber/ouvir, mltiplos (configurvel) estados de sono. Atrasos de transio de um estado para outro. Mltiplos (configurvel) nveis de transmisso de energia. Consumo de energia diferente para os diferentes estados e nveis Tx usado.

Mltiplos modos de operao (definidos pela modulao, datarate, largura de banda, noise floor (piso de rudo) e outros parmetros) que pode mudar dinamicamente. Mltiplos esquemas de modulao suportados nativamente (FSK, PSK, DiffQPSK, DiffBPSK, modulao Ideal com limiar de 5 dB). Capacidade de definir esquemas de modulao personalizada, definindo o mapeamento SNRBER. Clculo contnuo de RSSI (Received Signal Strength Indicator) Capacidade CCA (Channel Clear Assessment-canal de avaliao limpa); interrupes para o mdulo MAC. Clculo de interferncia fine-grain (muda dinamicamente durante a recepo de pacotes) e clculo de erros de bit exato em um pacote.

4.2.1 O arquivo de parmetros do rdio Para definir os principais parmetros de operao de um rdio ns usamos um arquivo que segue um formato especfico. Ns j definimos 3 rdios que voc pode encontrar em Simulations/Parameters/Radio/. Estes so: BANRadio.txt , CC1000.txt e CC2420.txt. BANRadio descreve o narrowband radio(rdio de banda estreita) proposto no IEEE 802.15 Task Group 6 documents. CC2420 e CC1000 e definem os rdios reais de mesmo nome pelo Texas Instruments. O parmetro RadioParametersFile do mdulo de rdio aponta para este arquivo. O mdulo ir l-lo e analis-lo. Aqui o formato de um arquivo de Parmetros de Radio do Castalia: Qualquer linha que comea com "#" considerado um comentrio. Os arquivos devem conter 5 sees cada uma comeando com a linha RX MODES TX LEVELS DELAY TRANSITION MATRIX POWER TRANSITION MATRIX SLEEP LEVELS As sees podem aparecer em qualquer ordem. Nos rdios temos definido seguindo a ordem mostrada acima. Seo RX MODES contm uma ou mais linhas no seguinte formato: Name, dataRate(kbps), modulationType, bitsPerSymbol, bandwidth(MHz), noiseBandwidth(MHz), noiseFloor(dBm), sensitivity(dBm), powerConsumed(mW) Todas as quantidades so nmeros com exceo de Name, que uma string arbitrria e modulationType que pode levar apenas os seguintes valores: FSK, PSK, DIFFBPSK, DIFFQPSK, IDEAL, CUSTOM. Aqui est um exemplo de CC2420.txt: normal, 250, PSK, 4, 20, 194, -100, -95, 62 Seo TX_LEVELS deve ter duas linhas. A primeira linha comea com a string "Tx_dBm" seguido por n nmeros (separados por espaos). A segunda linha comea com a string "Tx_mW" tambm seguido por n nmeros separados por pelo menos um espao. Como voc pode entender, a primeira linha lista a potncia de sada dos nveis de transmisso diferentes em dBm e a segunda linha quanta energia o rdio est gastando durante a transmisso em um nvel de potncia. A ordem dos nveis de potncia deve ser mantido o mesmo em ambas as linhas. Nos arquivos de rdio ns j definimos, optamos por ir do maior para menor. Aqui est um exemplo de CC2420.txt definindo os 8 nveis de potncia de transmisso possvel: Tx_dBm 0 -1 -3 -5 -7 -10 -15 -25 Tx_mW 57.42 55.18 50.69 46.2 42.24 36.3 32.67 29.04

61

4.3. MAC
O protocolo Controle de Acesso Mdio uma parte importante do comportamento do n, portanto, h um mdulo separado que o define. Em Castalia temos quatro mdulos principais MAC implementadas: 1) TunableMAC, um MAC duty-ciclo que expe muitos parmetros para o usurio e a aplicao (pedido de?) para tuning (ajuste). De TunableMAC tambm temos o comportamento de um simples protocolo MAC CSMA/CA. 2) o popular TMAC. De TMAC podemos tambm obter S-MAC definindo apenas um par de parmetros (T-MAC um aprimoramento do S-MAC permitindo extensveis tempos ativos). 3) IEEE 802.15.4 MAC. Este o padro para redes sem fio de baixa potncia, embora no seja predominante em RSSF. 4) IEEE 802.15.6 MAC, projeto de proposta para Redes de Corpo (BAN).

4.3.1. Tunable MAC

4.3.2. T-MAC and S-MAC

4.3.3. IEEE 802.15.4 MAC O padro IEEE para comunicao sem fio de baixa potncia de curto alcance de (802.15.4) define, parte (separado?) da camada fsica, a funcionalidade de um MAC. Temos implementado funcionalidades principais desta MAC em Castalia e ns oferecemo-la comeando com Castalia verso 2.2. Castalia 2.3 inclui a importante funcionalidade GTS (uma forma de TDMA). Ns concentramos nossos esforos na implementao das funes do MAC que iria ajudar com Body Area Networks (BAN) e outros deixaram unimplemented devido aos recursos limitados. Mais especificamente implementamos: Funcionalidade CSMA-CA (slotted e unslotted) Beacon-enabled PANs com a associao (auto associado) Modo de transferncia direta de dados Garantia de slots de tempo (GTS). Recursos que no esto implementados: Non-beacon PANs Modo de transferncia indireta de dados Topologias Multihop PAN

4.3.4. Linha de Base BAN MAC Body Area Networks um campo em rpida evoluo de redes de sensores sem fio baixa potncia. Colocamos um esforo considervel fazendo de Castalia um simulador adequado para

BAN, e o MAC uma rea importante que nos concentramos. O mdulo BaselineBANMac nossa implementao de proposta do projeto IEEE 802.15.6 para um padro em BAN MAC [8]. Sugere-se que voc leia a proposta para obter uma compreenso do MAC. Voc pode encontrar a descrio do mdulo em: src/node/communication/mac/baselineBanMac/BaselineBANMac.ned

4.4 Roteamento
Roteamento em Castalia recebe menos ateno em comparao com outros mdulos de comunicao. Mesmo que a camada de roteamento goza de um nvel similar de abstrao para definir seu prprio protocolo como as outras camadas (por exemplo, App, MAC), h menos protocolos implementados e lanado em Castalia. Isto devido s nossas prprias necessidades de pesquisa, que no incidem sobre o roteamento, ento naturalmente h menos apoio de roteamento em Castalia. No entanto, ns reconhecemos a necessidade de roteamento e ns fornecemos toda infra-estrutura para essa camada e um protocolo de roteamento simples para usar (chamado multipathRings). Ns estamos esperando que no futuro, atravs das contribuies de entidades externas ns seremos capazes de lanar o popular Collection Tree Protocol (CTP). Primeiro suporte de Castalia para roteamento veio com a verso 1.2. Em 1.3 lanamos dois protocolos de roteamento o simpleTreeRouting e multipathRingsRouting que se manteve ativo at 2.3b verso. Aps a grande reformulao do Castalia em verso 3.0 o multipathRings foi escrito quase do zero e simpleTree no foi includo, uma vez que precisava de maior refatoramento. Em Castalia 3.2 ns ainda s fornecem multipathRings e bypassRouting (um mdulo que como o nome sugere no implementa qualquer roteamento). Todos os mdulos de roteamento compartilham 4 parmetros herdados da interface iRouting.ned e funcionalidade herdada da classe VirtualRouting. Os 4 parmetros so: 1) collectTreceInfo o parmetro padro que encontramos em todos os mdulos Castalia; 2) maxNetFrameSize determina o tamanho mximo do pacote de roteamento pode lidar (0 ou menos significa sem limite); 3) netDataFrameOverhead define o overhead (processamento ou armazenamento em excesso) adicionado aos pacotes de aplicao; 4) netBufferSize especifica o tamanho do buffer (regio de memria temporria utilizada para escrita e leitura de dados) encontrado no mdulo. BypassRouting no define novos parmetros. multipathRingsRouting define dois novos parmetros em cima dos quatros padres. Vamos descrever a forma bsica que multpathRings funciona. Em multipathRingsRouting ns no tm um pai (origem) especfico. Um n s fica um nmero de nvel (ou nmero de anel) durante o setup (configurao). O primeiro pacote de setup enviado do sink tem nvel 0. Qualquer n que recebe adiciona 1 para o nvel e retransmite ele. O processo continua em cada n adicionando 1 para o nvel do pacote recebido. Eventualmente todos os ns conectados ter um nmero de nvel (h tambm uma possibilidade para ns desconectados). Quando um n quer enviar um pacote para o sink ele no envia para um n particular, mas retransmite-o, anexando seu nmero de nvel. Qualquer n com um nmero de nvel menor ir retransmiti-lo. O processo continua at que o sink seja atingido. Voc pode ver com esse algoritmo que muitos caminhos para o sink podem ser tomados. O algoritmo pode ser mais robusto em comparao com algoritmos de rota nica, mas se o trfego ultrapassa certo limiar baixo (if the traffic is passes a certain low threshold), o congestionamento pode matar a performance.

Como definido um n sink? Poderamos definir um parmetro no mdulo de roteamento que deu os IDs dos ns sink. Temos a questo: este o trabalho do mdulo de roteamento? No. Seja ou no um n um n sink depende do application. A aplicao deve saber onde a informao deve acabar. Diversas aplicaes j em Castalia est definindo um parmetro chamado isSink. O parmetro assume valores true/false e definida para cada n (como cada n tem um mdulo de aplicao). MultipathRings olha para este parmetro de aplicao-nvel para determinar se o n um n sink e se o mdulo de roteamento naquele n particular deve iniciar a configurao dos anis de roteamento. Assim, se voc estiver usando multipathRings, seu aplicativo deve tambm definir o parmetro isSink. Se voc est definindo o seu prprio mdulo de roteamento, voc naturalmente livre para mudar essa dependncia, mas tenha em mente que os mdulos de roteamento normalmente levam entrada da aplicao. Estes so os dois parmetros extras que multipathRings define:

O tamanho de uma mensagem de controle especfica para configurao dos anis

Especifica um tempo limite quando a criao da rvore de rede (ou informaes de nvel) est ocorrendo. Se um n particular no recebe informaes a tempo ele pode declar-la a si mesmo "no conectado" e relata isso para o aplicativo com uma mensagem. Com infra-estrutura de mdulos de roteamento ns tambm especificamos um formato genrico para o frame (quadro) da rede. Isso inclui informaes de cabealho: source/fonte (string), destino (string), e applicationID (string). Uma string foi escolhida para permitir a maior flexibilidade na definio de destinos e fontes. Por exemplo, protocolos de roteamento poderiam ter os seguintes destinos: sink1, parent (pai), ponto (23,56), areacircle (12, 35, 5), arearectangle (0,0 10, 40). MultipathRings suporta apenas o destino "SINK" (que tambm definida como o macro SINK_NETWORK_ADDRESS em CastaliaMessages.h).

4.5. O Processo Fsico

4.8. O Resource Manager

O mdulo resource manager mantm o controle da energia gasta pelo n e tambm possui algumas quantidades node-specific, tais como o clock drift e o consumo de energia de base (voc pode pensar nisso como a energia mnima que o n consome). Existem algumas disposies para track memory ou para definir diferentes consumos de energia para o processador, mas eles no esto totalmente operacionais. Mdulos que modela dispositivos de hardware (ou seja, o rdio e o sensor manager) enviam mensagens para o Resource manager em ordem para sinalizar a quantidade de energia que atualmente desenham. O resource manager, em seguida, tem uma viso completa da potncia total desenhadas e com base neste calcula a energia consumida de cada vez ns temos uma mudana no power ou periodicamente (se uma mudana de power no aconteceu por algum tempo). O clculo do consumo de energia peridica feito com base neste parmetro:
double periodicEnergyCalculationInterval = default (1000);

Temos tambm um consumo de energia de base, como dissemos, dada por: double baselineNodePower = default (6); Atualmente, alm deste desenho de energia constante, apenas o rdio desenha energia (o sensor manger no foi ajustado para o novo modelo de mensagens power-drawn e requer alguma remodelao para faz-lo). O oramento inicial de energia de um n dado por: double initialEnergy = default (18720); 18.720 Joules a energia tpica de duas pilhas AA. Energia linearmente subtrada com base no desenho de energia geral e no tempo decorrido, porm com base na modelagem de mensagens power-drawn ns podemos ter mais modelos de consumo de energia avanado, que levam em conta a histria da energia consumida para determinar a energia deixada em clulas de bateria. Finalmente, o clock drift do n armazenado no resource manager e pode ser adquirido chamando o mtodo pblico getCPUClockDrift(). O drift (desvio) determinado pelo desenho de uma zero-mean Gaussian random variable. O sigma dada pelo parmetro: double sigmaCPUClockDrift = default (0.00003);

O drift atualmente limitado a 3sigma (por isso um nivelado Gaussian estamos desenho). Voc pode pensar da cap (tampa/capa) como parte da garantia de qualidade desses clocks/quartzes. Se no nivelada a esquerda, muito provvel para obter valores de drift muito grande 1-2 para algumas seeds/cases (quando executamos milhares de simulaes) que pode resultar em alguns protocolos MAC sem funcionar corretamente para essas seeds/cases.