Desenvolvimento de uma Extensão para Transmissão
de Imagens em Redes de Sensores Sem Fio para o
Simulador OMNeT++/Castalia
Lucas Vinícius dos Santos Assis⇤, Daniel G. Costa†
⇤ECOMP-UEFS, Universidade Estadual de Feira de Santana, Brasil †DTEC-UEFS, Universidade Estadual de Feira de Santana, Brasil
Resumo—Algoritmos para sistemas distribuídos, como Redes de Sensores Sem Fio, podem ser analisados e validados com o apoio de ferramentas de simulação. No entanto, a maioria das ferramentas para simulação deste tipo de rede não fornecem funcionalidades adequadas para a utilização de nós sensores com câmera e outras características necessárias para Redes de Sensores Visuais Sem Fio. Este trabalho apresenta o desenvol-vimento de uma extensão para o simulador OMNeT++/Castalia, referida como VisualCastalia, criada para simular transmissões de imagem com nós sensores visuais em Redes de Sensores Sem Fio.
Palavras-chave—Simulação computacional; Redes de Sensores Visuais Sem Fio; Transmissão de imagens; Medição de desempe-nho.
Abstract—Algorithms for distributed systems, like Wireless Sensor Networks, can be analyzed and validated with the support of simulation tools. However, most simulation tools for this kind of network do not provide proper functionalities for using of sensor nodes with camera and other required characteristics for Wireless Visual Sensor Networks. This paper presents the development of an extention for the OMNeT++/Castalia simulator, referred as VisualCastalia, created to simulate image transmissions with visual sensor nodes in Wireless Sensor Networks.
Keywords—Computer simulation; Wireless Visual Sensor Net-works; Image transmission; Performance measurement.
I. INTRODUÇÃO
O
avanço e barateamento de tecnologias para criaçãode circuitos integrados permitiu o desenvolvimento de unidades sensoras cada vez menores, com consumo energético reduzido e com pouco poder de processamento. Dispositivos com essas características, quando equipados com um rádio transmissor de baixa potência e bateria, são chamados de nós sensores e podem ser conectados entre si, em grande quanti-dade, para transmitir informações adquiridas de um ambiente monitorado para um armazenamento central, formando assim, uma Rede de Sensores Sem Fio (RSSF) [1].
Com as RSSF, o desenvolvimento de aplicações nos mais diversos tipos de cenários tornou-se possível, como: rastrea-mento e vigilância de alvos militares, recuperação de áreas em situações de desastres naturais, monitoramento biomédico, ex-ploração de ambientes impróprios para humanos, dentre muitos outros. Contudo, topologias comumente estabelecidas para redes de Internet não podem ser utilizadas em RSSF devido
a questões próprias exigidas pelos nós sensores componentes da rede, como: comunicação desestruturada, baixa taxa de transmissão, baixo poder de processamento e, principalmente, eficiência no gasto energético, pois os nós são alimentados por baterias [2]. Assim, são exigidos novos protocolos e técnicas específicas para lidar com essas questões. Nesse contexto, a validação das RSSF antes de sua implantação em campo pode trazer vantagens, destacando a importância de simulações computacionais para esse tipo de rede.
Nós sensores em RSSF comuns coletam apenas dados escalares, como: temperatura, umidade e pressão. Quando se equipa esses dispositivos com câmeras de baixo custo e pouco consumo energético, para não exaurirem ainda mais os recursos já escassos desse tipo de rede, os dados obtidos pelos sensores escalares podem ser enriquecidos com imagens e/ou vídeos [3]. Redes assim são denominadas de Redes de Sensores Visuais Sem Fio (RSVSF).
As possibilidades para uso de RSVSF compreendem desde a melhora de aplicações tratadas por RSSF comuns até a criação de novos tipos de aplicações, com o uso específico dos dados visuais provenientes das câmeras [3]. Como novos e mais complexos desafios são apresentados, muitas das abordagens empregadas para redes com sensores escalares não são válidas para RSVSF, impulsionando o desenvolvimento de diversas otimizações. Assim como em RSSF, as simulações computaci-onais são um importante recurso para aprovação dos algoritmos distribuídos propostos para as redes visuais.
Questões como resistência a perda de pacotes e economia de energia são muito importantes em RSSF. Devido a isso, os pacotes de dados enviados pela rede possuem um tamanho reduzido. Ao se tomar como exemplo o padrão IEEE 802.15.4, comumente utilizado para esse tipo de rede, os pacotes de dados possuem tamanho máximo de 127 bytes, incluindo nesse valor o conteúdo do cabeçalho [4]. No caso das RSVSF, independente da resolução de uma imagem obtida, o seu tamanho em bytes tende a ser muito maior do que o de dados obtidos com sensores escalares das RSSF.
A fragmentação das imagens em vários pacotes de dados apresenta-se como uma solução para possibilitar a transmissão de imagens em uma RSSF. Tal procedimento, porém, deve levar em consideração a inserção de dados de controle nos pacotes, para permitir a reconstrução correta das imagens no ponto de recepção dos dados, mesmo com a perda de alguns pacotes no processo de transmissão. Esse requisito
pode gerar pacotes contendo partes da imagem classificadas com diferentes relevâncias [5]. Assim, o uso de arquivos de imagens reais nas simulações pode ser necessário para a avaliação da qualidade de transmissão de uma RSVSF. Apesar de necessários, esses serviços básicos de transmissão não estão disponíveis nos principais simuladores de RSSF disponíveis no mercado.
Alguns simuladores de rede foram desenvolvidos ou adapta-dos para serem utilizaadapta-dos em redes de sensores sem fio. Entre eles, simuladores como o NS-2, OMNeT++, NS-3 e Opnet são opções comuns para simulação de diversos aspectos de RSSF, cada um com recursos e detalhes próprios de simulação [6], [7]. Porém, entre os simuladores existentes, o framework Castalia [8], baseado no OMNeT++ [9], destaca-se dos demais por ter sido projetado especificamente para testes de algoritmos e protocolos de redes distribuídas, como as RSSF. O Castalia trabalha também com dados empíricos de sensores e rádios transmissores de baixa potência, o que permite que certos fatores da simulação, como a interferência na transmissão de dados entre os nós sensores, sejam tratados automaticamente pelo programa [8]. Contudo, o Castalia não foi projetado para trabalhar com nada além do que dados escalares, o que impossibilitaria seu uso, sem nenhum complemento, para Redes de Sensores Visuais Sem Fio.
Como as simulações realizadas pelo Castalia já tratavam da maioria das questões necessárias para a simulação de RSSF, algumas extensões foram criadas reaproveitando o seu código como base para simulação de algumas demandas específicas de redes de sensores visuais. Das principais extensões basea-das no Castalia para redes de sensores visuais, destacam-se: Video Castalia [10], Wise-MNet [11] e M3WSN [12]. Esses simuladores trabalham com aplicações direcionadas a redes de sensores com câmeras, porém nenhum deles permite a configuração dos parâmetros da transmissão dos dados visuais de forma simples e transparente ao usuário.
Nesse contexto, é apresentado o projeto e desenvolvimento do VisualCastalia, uma extensão ao framework Castalia que permite a definição de nós visuais para transmissão de ima-gens, configuradas quanto ao seu tipo de codificação, resolução e padrão de cores, na rede. O objetivo principal do trabalho foi criar um mecanismo simples, porém eficiente, para transmissão de imagens em Redes de Sensores Visuais Sem Fio que, de maneira diferente a outras extensões multimídia baseadas no Castalia, realiza a transmissão utilizando como base mecanis-mos de fragmentação e transmissão de pacotes de imagens em RSSF.
O artigo foi dividido nas seguintes seções: II - Fundamen-tação Teórica, onde são apresentadas as revisões da literatura que fundamentaram o desenvolvimento do projeto do Visual-Castalia; III - Metodologia e Experimentos, seção que contém os principais detalhes, procedimentos e métodos da construção da extensão desenvolvida; IV - Resultados e Discussões, onde são apresentados os resultados gerados com o trabalho; Por último, a seção V - Conclusão resume os principais assuntos discutidos ao longo do artigo e apresenta algumas expectativas para trabalhos futuros.
II. FUNDAMENTAÇÃOTEÓRICA
A. Redes de Sensores Sem Fio e Redes de Sensores Visuais Sem Fio
Uma Rede de Sensores Sem Fio é criada através da inter-conexão, por uma rede sem fio, de uma grande quantidade de dispositivos sensores, também conhecidos como nós sensores, com objetivo de cobrir o monitoramento de determinada área. Essa grande quantidade de nós sensores é necessária para uma maior cobertura e confiabilidade dos dados obtidos, pois na maior parte dos casos os sensores são inseridos no ambiente monitorado de maneira aleatória. Também, devido a grande quantidade de dispositivos necessários, recomenda-se que estes sejam pequenos, para facilitar seu transporte e implantação, e baratos, o que consequentemente faz com possuam recursos de processamento e memória limitados [6]. Os nós sensores também precisam ser alimentados por bateria, pois, em ge-ral, nos ambientes monitorados não existe a disponibilidade de nenhuma rede fornecedora de energia elétrica. Devido a isso, esses nós acabam sendo descartáveis e não podem ser recuperados ou reutilizados a não ser que possuam uma fonte de realimentação externa, como uma placa de energia solar, por exemplo. Alguns exemplos de dispositivos sensores podem ser encontrados na Fig. 1
Figura 1: Exemplos de nós sensores. Fonte: [13] Com relação a sua arquitetura, os nós sensores são compos-tos por unidade de processamento, memória, fonte de energia, transmissor e receptor de rádio (em geral tarefas realizadas pela mesma antena), atuador (no caso de sensores móveis) e uma ou mais unidades de sensoriamento [14]. A Fig. 2 demonstra uma arquitetura genérica de um nó sensor.
Os tipos de sensoriamento mais comuns em RSSF escalares incluem: temperatura, gases tóxicos, luminosidade, umidade, fumaça e fogo, pressão, dentre outros. Esses sensores podem ser utilizados nas mais diversas aplicações, como: rastreamento de alvos militares e monitoramento do inimigo, controle de inventário e monitoramento de máquinas em indústrias, detec-ção de poluidetec-ção de mares, detecdetec-ção de incêndios em florestas, dentre outros.
Os dados escalares obtidos pelos nós sensores inseridos no ambiente analisado devem ser transmitidos para o nó central, denominado nó sorvedouro ou nó Sink. O nó Sink é responsável por receber e direcionar as informações obtidas dos demais nós sensores para um banco de dados ou algum sistema de armazenamento através de uma conexão via Internet ou por satélite [13]. A Fig. 3 demonstra como ocorre o processo de obtenção e armazenamento do dado obtido na
Figura 2: Descrição de alto nível de um nó sensor. Fonte: [14]
RSSF. Nela é possível perceber que um nó fonte de dados transmite o dado para o vizinho mais próximo até chegar ao final do agrupamento de nós sensores. Quando o pacote de dados atinge o último agrupamento, o mesmo é enviado para o nó Sink e, por este, será encaminhado para o local de salvamento.
Figura 3: Relação do nó Sink com os demais nós sensores da rede. Fonte: [13]
Algumas das principais restrições no uso de RSSF incluem: eficiência energética, roteamento, localização, cobertura, ge-renciamento de dados, confiabilidade e segurança. Essas ques-tões devem ser levadas em consideração no planejamento de uma RSSF, pois toda a aplicação pode ser prejudicada se alguma dessas características não for executada da maneira mais otimizada possível. A eficiência energética, por exemplo, se caracteriza como um dos fatores mais importantes a serem levados em consideração no projeto de uma RSSF, afinal, os nós sensores são alimentados por bateria e, em geral, quando esta acaba, não existem meios viáveis para sua substituição e o dispositivo é inutilizado. A questão da duração da bateria
em todos os nós sensores da RSSF é de vital importância para determinar o tempo de vida da rede que, quanto maior for, irá oferecer mais dados úteis a quem a estiver monitorando. De fato, apesar do aumento da capacidade energética dos nós sen-sores modernos, ainda é muito importante o desenvolvimento de técnicas para economia de energia [4]. Assim, os algoritmos executados em RSSF devem priorizar o consumo energético, condição que inviabiliza muitas aplicações comuns para redes de Internet, por exemplo, que possuem fonte energética "ili-mitada", com componentes conectados a todo momento a uma fonte de energia, se comparada com os nós sensores.
Outra questão de crucial importância na implantação de uma rede de sensores é como os dados dos pacotes serão entregues ao nó Sink da rede, pois se o roteamento ocorre de forma aleatória, é necessário saber a melhor forma dos nós encontrarem o melhor caminho para enviar as informações por ele geradas através de pacotes de dados, assim como as informações provenientes de seus nós vizinhos por ele retransmitidas. Por isso, os mecanismos de roteamento devem considerar um abordagem multihop, onde os pacotes são repassados de um nó sensor para outro vizinho, considerando sua localização, até que o nó Sink seja alcançado [1]. Questões como retransmissão de dados só devem ser consideradas em RSSF caso o pacote em questão seja de extrema importância, pois o consumo energético para realizar essa ação é alto.
As abordagens convencionais de RSSF requerem que os dados sejam transferidos do nó sensor para a estação base devido ao armazenamento limitado do dispositivo. Assim, técnicas de agregação e compressão são utilizadas para reduzir os custos da comunicação e de consumo energético dos nós sensores, pois uma quantidade menor de dados precisa trafegar pela rede. Na etapa de compressão, os dados podem ser crip-tografados para adicionar maior segurança à transmissão das informações na rede. Desse modo, otimizar o armazenamento nos nós sensores torna-se importante quando dados massivos são gerados e processados a todo tempo [13].
A cobertura é outro ponto importante no projeto de uma RSSF, afinal, é necessário que a área monitorada tenha uma parcela significativa de seu espaço coberto por nós sensores
para que os dados gerados pela rede sejam considerados confiáveis. Porém, levando em consideração a implantação desestruturada dos nós, para alcançar um alto grau de cobertura é necessário que muitos desses dispositivos sejam postos a monitorar um mesmo local. Pois, uma densidade maior de sensores pode produzir redundância suficiente para considerar válidos os dados obtidos. [2].
Quando se equipa um nó sensor com câmeras fotográficas ou de vídeo, uma nova gama de sensoriamento é possível, ao acrescentar-se os dados visuais aos dados escalares obtidos pelos sensores das RSSF [3]. De fato, aplicações que envolvem tarefas de vigilância, rastreamento e controle de tráfego podem melhorar significantemente a qualidade de serviço oferecida ao agregar os dados visuais às informações originais [13]. Na Fig. 4 são apresentados alguns exemplos de câmeras que podem ser equipadas nos nós sensores.
Figura 4: Câmeras de baixa resolução para implantação em nós sensores. Fonte: [13]
Porém, as restrições impostas às RSSF aumentam signifi-cantemente sua complexidade em se tratando de RSVSF. Por exemplo, a transmissão de dados visuais requer muito mais largura de banda de comunicação do que os dados obtidos de sensores escalares, exigindo que os nós sensores gastem mais recursos de processamento, memória e consequentemente energéticos, diminuindo, assim, o tempo de vida da rede como um todo [13]. O tamanho dos pacotes com os dados visuais também não pode estourar as restrições impostas pelos proto-colos de comunicação das RSSF, tornando, assim, necessário o uso de técnicas de fragmentação nas imagens transmitidas para que caibam nos pacotes pequenos [5]. Assim, conclui-se que as RSVSF exigem a construção de algoritmos que tratem as principais questões surgidas com o seu uso, tornando a tarefa de implementação dessas redes significantemente mais desafiadora.
B. Simuladores para Redes de Sensores Sem Fio
Aplicações de RSSF e RSVSF em geral exigem que diversos aspectos sejam considerados antes de sua implantação em campo. O uso de simuladores se torna útil à medida que estes possibilitam o teste de vários cenários de aplicação para verificação da forma de implantação mais otimizada da rede testada.
O módulo simulador desenvolvido neste trabalho foi cons-truído como extensão ao simulador de RSSF Castalia, que é baseado no OMNeT++. Desse modo, é valida a citação do OMNeT++ nessa revisão da literatura, pois alguns de seus
conceitos de simulação são necessários para o entendimento do funcionamento do Castalia.
O OMNeT++ é um framework de simulação de redes genéricas, com estrutura organizada em módulos, que funciona seguindo o paradigma de orientação a objetos e pode ser usado para simulação de vários domínios de problemas relacionado a redes. Esse simulador é suportado em vários tipos de sistemas operacionais, como Windows, Mac OS/X e Linux [9].
Os seguintes conceitos-chave de construção e funciona-mento do OMNeT++ são a base para entendifunciona-mento do fun-cionamento do Castalia, são eles:
• Módulos: caracterizam-se como sendo a unidade básica de execução do OMNeT++. Os módulos podem trocar mensagens entre si e, dependendo da configuração e do conteúdo da mensagem recebida, executar diferentes al-goritmos. Eles podem ser interconectados via portas (que podem ser de entrada ou saída), para assim, poderem trocar mensagens entre si e serem subcomponentes de um módulo composto;
• Mensagens: Essas estruturas podem conter e transportar estruturas de dados por caminhos predefinidos através de portas ou conexões e caracterizam-se como a principal forma de comunicação entre os módulos do OMNeT++; • Linguagem NED: através dessa linguagem, o usuário do simulador pode descrever toda a estrutura dos módulos que serão usados por ele na sua rede. A linguagem NED tem diversas características que permitem o trabalho com projetos complexos e robustos, dentre elas: interfaces, herança, pacotes predefinidos, dentre outras. Essa lin-guagem, porém, representa apenas a estruturação dos módulos componentes da rede, pois o funcionamento dos módulos é descrito, na construção da simulação, em classes escritas na linguagem de programação C++. O simulador Castalia destaca-se por ter sido projetado para testes de algoritmos distribuídos e protocolos de redes de sensores sem fio. Para isso ser possível, o simulador imple-menta um modelo de propagação (interferência, transmissão e recepção de dados em redes sem fio) com resultados obtidos através da análise de dispositivos reais com antenas de baixa potência, o que garante resultados de transmissão e consumo de energia com maior grau de confiabilidade [9]. Essa carac-terística do Castalia lhe garante os melhores resultados em termos de interferência na transmissão, propagação de sinal e sincronização entre os nós sensores.
O Castalia está fundamentado em módulos operacionais básicos, que se comunicam entre si. Esses três módulos, Phy-sicalProcess, Node e WirelessChannel, se comunicam através de mensagens de entrada e saída. Todas essas características, além dos parâmetros de comunicação utilizados na simulação, são descritos numa série de arquivos NED, seguindo o padrão definido no OMNeT++.
A Fig. 5 apresenta a relação entre os três módulos globais da rede do Castalia. O sensoriamento de informações é simulado utilizando o Physical Process (abstração do ambiente monito-rado), que provê dados para os sensores da rede, modelados como Node (abstração de um nó sensor). Um Node transmite pacotes para outros Nodes da rede, através do Wireless Channel (abstração do canal de comunicação sem fio).
Figura 5: Módulos do Castalia. Fonte: [8]
A estrutura interna do Node modelado no Castalia é de-monstrado na Fig. 6. Nessa imagem as mensagens enviadas por módulos são setas cheias, já as chamadas de funções internas dos módulos são descritas por setas tracejadas. É possível notar que a maioria dos módulos chamam funções de gerenciamento de recursos para indicar que a energia foi consumida, demonstrando, por exemplo, a preocupação do simulador com essa funcionalidade [8].
Figura 6: Estrutura de módulo composto do nó sensor do Castalia. Fonte: [8]
As simulações no Castalia são feitas através da configuração de um arquivo nomeado omnetpp.ini, um arquivo texto criado para os usuários estabelecerem os parâmetros da simulação. Utilizando esse arquivo, o simulador irá executar a simulação desejada, que será processada e poderá produzir diferentes resultados.
No geral, usuários podem analisar os resultados da simu-lação em um arquivo, denominado de trace, que contém o passo a passo da simulação da rede. Também é possível gerar, na própria ferramenta, gráficos de desempenho para análise de métricas como consumo de energia, taxa de sucesso no envio e recepção de pacotes, dentre outras [8].
A execução e os resultados do Castalia podem ser obtidos utilizando três scripts distintos presentes em seu código fonte, são eles Castalia: executa as simulações e gera arquivos con-tendo os resultados das mesmas; CastaliaResults: responsável por interpretar os resultados provenientes da simulação execu-tada no Castalia; CastaliaPlot: que cria gráficos utilizando as tabelas de resultados analisados pelo CastaliaResults [8].
O Castalia também oferece ao usuário a possibilidade de criação e teste dos seguintes tipos de protocolos para RSSF: aplicação (utilizado como base na construção desse trabalho), MAC, Roteamento e Gerenciamento de Mobilidade [8].
Assim como o OMNeT++, o Castalia é gratuito e possui código aberto, permitindo a modificação da seu código-fonte para atender diferentes demandas de utilização.
C. Protocolo Timeout MAC
A camada de controle de acesso ao meio (do inglês Medium Access Control Layer ou MAC) participa do processo de comunicação em Rede de Sensores Sem Fio. O protocolo MAC, que gerencia essa camada, nesse tipo de rede tenta se assegurar que os nós sensores não estão interferindo na transmissão um dos outros, e gerencia o conflito quando essa interferência ocorre [15].
Consumo de energia é muito importante em um protocolo desse tipo para RSSF, pois o rádio transmissor em um nó sensor é geralmente o componente que mais usa energia e esse gasto não ocorre somente na transmissão, mas também na recepção, na procura de outros nós para comunicação e até mesmo em períodos de espera por comunicação, esse último tipo de estado consome até 99% do tempo total da comunicação do nó sensor sem realizar nenhuma tarefa útil [15].
Enquanto que protocolos MAC em redes tradicionais são projetados para tornar máxima a vazão de pacotes e minimizar a latência, permitindo que todos os componentes tenham a mesma chance de comunicação (justiça na comunicação), os projetados para RSSF objetivam minimizar o consumo de energia e, para isso, trabalham em conjunto com o protocolo de aplicação ao utilizar os valores nela definidos como aceitáveis, pelo projetista da rede, para a vazão mínima e latência máxima. Justiça na comunicação não é um problema, pois os nós sensores de uma RSSF são tipicamente parte de uma aplicação distribuída e trabalham juntos para um propósito comum [15]. O protocolo Timeout-MAC (T-MAC) é uma implementação de protocolo MAC projetado para RSSF. Neste protocolo são empregadas técnicas que envolvem uso de sincronização entre nós vizinhos, a fim de definir o momento exato para que a transmissão e recepção ocorram com maiores chances de sucesso, e modificação ativa de duty cycle (razão entre o período de trabalho ativo do transmissor com todo o período do clock de funcionamento) que visa adaptá-lo de acordo com o tráfego de pacotes na rede, como pode ser percebido na Fig. 7, onde todas as mensagens recebidas no período de repouso do ciclo, serão armazenadas em buffer, para logo no início do período ativo serem enviadas em rajada. Essas especificações mantém uma entrega alta de pacotes na rede, economizando energia por evitar que os nós permaneçam muito tempo em estado de espera [8].
Figura 7: Comparação do protocolo T-MAC e MAC tradicional com relação ao duty cycle [15].
O simulador Castalia possui uma implementação de módulo MAC do protocolo T-MAC e oferece uma série de variáveis de configuração para o seu uso em suas simulações. Neste trabalho, o protocolo T-MAC foi amplamente utilizado na implementação dos experimentos de simulação por permitir uma maior entrega de pacotes no processo de transmissão e otimização no consumo energético, requisitos necessários para uma aplicação com alto índice de envio de pacotes como a transmissão de imagens em RSSF.
D. Compressão de Imagens em JPEG
O formato de compressão de imagens JPEG foi criado com objetivo de promover um mecanismo de compressão de qualidade que diminuísse consideravelmente o tamanho das imagens digitais que o implementassem sem que estas perdes-sem qualidade visual. O método utiliza compressão baseada na transformada discreta do cosseno (do inglês, Discrete Cosine Transform ou DCT) e por isso, a cada vez que a imagem sofre compressão, apresenta perda em sua qualidade original [16].
O cálculo da transformada discreta do cosseno, utilizado para realizar a compressão JPEG é representado pela equação 1, enquanto que sua transformada inversa pode ser vista
na equação 2, onde C(u)C(v) = p1
2, para u, v = 0 ou
C(u)C(v) = 1, para demais casos. Para maiores detalhes sobre o funcionamento do método de compressão JPEG deve-se consultar a referência [16]. F (u, v) = 1 4C(u)C(v)[ 7 X x=0 7 X y=0 f (x, y)⇤ cos((2x + 1)u⇡ 16 ) cos( (2x + 1)v⇡ 16 )] (1) f (x, y) =1 4[ 7 X u=0 7 X v=0 f (u, v)⇤ cos((2x + 1)u⇡ 16 ) cos( (2x + 1)v⇡ 16 )] (2) As imagens transmitidas pela extensão de simulador desen-volvido nesse trabalho utilizam o formato JPEG. O formato foi escolhido por permitir que as imagens sejam salvas e visualizadas mesmo após elas terem sido corrompidas no processo de transmissão.
E. Peak Signal-To-Noise Ratio
A métrica Peak Signal-To-Noise Ratio (PSNR) é calculada pela diferença entre a potência máxima de um sinal e a potên-cia do sinal corrompido por ruído (ou que sofreu algum tipo de compressão). Em geral, é expressa na escala logarítmica dos decibéis para facilitar a sua utilização em sinais que possuam uma ampla largura de banda. A utilização do PSNR permite, por exemplo, verificar a qualidade de reconstrução de algoritmos de compressão com perdas (por exemplo, a compressão de imagens no formato JPEG) [17].
O seu funcionamento em comparação de imagens, por exemplo, ocorre ao comparar a imagem original com sua representação comprimida ou com a presença de ruído, sendo que, para seu resultado ser válido, as imagens precisam ter a mesma resolução e mesmo conteúdo. A equação 3 demonstra como o cálculo da métrica é realizado, onde MAXi é o valor máximo de pixel da imagem analisada, M e N representam respectivamente a largura e altura das imagens analisadas, e I(i, j) e K(i, j) representam respectivamente as imagens original e sua cópia com ruído [17]. Nota-se que, quando a imagem original e a comparada forem idênticas, ou seja, no caso de ausência de ruído, o PSNR terá seu valor igual a infinito ou indefinido, pois o valor da equação 4 será igual a zero e resultará em uma divisão por zero na equação 3.
P SN R = 20. log10( M AXi p M SE) (3) onde, M SE = 1 M N MX1 i=0 NX1 j=0 (I(i, j) K(i, j))2 (4)
Valores típicos para PSNR aplicado em imagens e vídeos com compressão com perdas estão entre 30 e 50 dB, onde valores maiores indicam que a imagem comprimida possui qualidade mais próxima à imagem original. Valores aceitáveis para transmissões em redes sem fio são considerados entre 20 e 25 dB [18].
III. METODOLOGIA EEXPERIMENTOS
Com o objetivo do desenvolvimento de uma extensão para adição da funcionalidade de transmissão de imagens em RSSF simuladas pelo framework Castalia, este trabalho é a con-tinuidade de dois programas de iniciação científica (IC) na área de simulação computacional em RSVSF. A primeira IC foi fomentada pelo Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPQ) no período 2014/2015 e teve o título de: Otimizações da transmissão, configuração e gerenciamento de Redes Sensores Visuais Sem Fio Utilizando Políticas de QoS e com número de pedido: 800578/2014-7, enquanto que a segunda foi fomentada pela Fundação de Amparo à Pesquisa do Estado da Bahia (FAPESB), no período 2015/2016, de título de Desenvolvimento de um Módulo de Simulação Adaptado para a Transmissão de Dados Visuais em Redes de Sensores Sem Fio e com número de pedido: 1888/2015. Ambas iniciações científicas possibilitaram a cons-trução de uma fundamentação teórica inicial sobre redes sen-sores escalares e visuais, assim como um estudo inicial sobre
o Castalia, o que permitiu também a oferta de um Laboratório na XV ESCOLA REGIONAL DE COMPUTAÇÃO BAHIA – ALAGOAS – SERGIPE (Erbase) com o título: Simulação de Redes de Sensores Sem Fio utilizando o Castalia, utilizando os conhecimentos adquiridos sobre o simulador.
O escopo inicial do projeto, definido para a IC pela CNPQ, envolvia a construção de um simulador completamente novo, onde diversos módulos do Castalia seriam alterados para prover as funcionalidades de transmissão de imagens em RSSF. Planejava-se, por exemplo, alterar o módulo PhysicalProcess para que, ao invés do mesmo gerar dados escalares, pudesse gerar imagens, que seriam capturadas por uma versão alterada, com suporte à captura de imagens, do submódulo SensorMa-nager do módulo Node, para então serem particionadas em pacotes e transmitidas para o nó Sink por um novo submódulo Application, também do módulo Node. Porém a realização dessas alterações iriam requerer modificações profundas em diversos arquivos do código fonte do Castalia, o que poderia prejudicar a execução de suas funcionalidades originais.
Com o estudo mais aprofundado sobre o simulador, percebeu-se que a abordagem de desenvolvimento inicialmente planejada não seria mais necessária para cumprir o escopo inicial do projeto, pois este poderia ser realizado apenas ao mo-dificar o submódulo Application do módulo Node de maneira a permitir que os nós sensores obtivessem as imagens a serem transmitidas de arquivos reais, contidos em pastas presentes no próprio computador onde a simulação fosse executada, para assim, realizar os procedimento necessários para sua transmis-são pela rede do Castalia. Essa nova abordagem foi utilizada, pois o principal objetivo da extensão do simulador não estava associado em como a imagem utilizada na simulação seria gerada ou obtida, mas sim em como seria realizado o seu processo de transmissão pela RSSF.
A definição dos requisitos funcionais da extensão foi a próxima etapa do desenvolvimento do novo módulo Applica-tion do nó sensor do Castalia e teve a premissa básica de possibilitar a transmissão de imagens pelo módulo Node sem afetar o seu funcionamento original. Assim, as seguintes funcionalidades foram definidas para a aplicação:
• Permitir que os usuários especifiquem os detalhes da transmissão de imagens (que devem ser fragmentadas e convertidas transparentemente em pacotes no seu pro-cesso de transmissão) ao oferecer a configuração de parâmetros da captura e codificação;
• Fornecer a opção de transmissão de imagens reais (pre-viamente salvas em uma pasta especificada no arquivo de simulação) ou criadas automaticamente por um al-goritmo próprio da extensão, caso o usuário não queira usar imagens reais;
• Disponibilizar duas modalidades de transmissão de ima-gens na frequência desejada (em imaima-gens por segundo),
sendo elas:Contínua: com envio periódico dos pacotes
e em Rajada: com envio de todos os pacotes gerados
após um certo período de tempo de uma só vez; • Permitir que as imagens transmitidas na rede simulada
possam ser exibidas e analisadas posteriormente à simu-lação, através do seu armazenamento em um diretório de imagens recebidas (previamente especificado pelo
usuário no arquivo de simulação);
• Oferecer novos resultados para métrica de qualidade da
comunicação, sendo eles:PSNR, definido na seção II-E
- Peak Signal-To-Noise Ratio, das imagens recebidas e Latência da transmissão das imagens: valor represen-tado pela diferença entre o tempo de chegada de todos os pacotes válidos de uma imagem no nó Sink subtraído pelo tempo de saída do primeiro pacote da imagem de seu nó fonte;
• Possibilitar que pacotes contendo parte ou todo o ca-beçalho das imagens sejam "marcados como especiais", permitindo tratamento diferenciado na transmissão, acio-nando mecanismos de retransmissão em casos de perdas. A importância dessa priorização deve-se ao fato de que o processo de reconstrução da imagem pelo nó Sink pode ser comprometido ou até mesmo inviabilizado caso algum pacote com dados de cabeçalho de imagem seja perdido no processo de transmissão.
Ao analisar a arquitetura do software Castalia, foi possível definir qual seria a estratégia necessária para adição do novo protocolo de aplicação ao seu código fonte original. Os passos recomendados são resumidos a seguir e necessitaram ser segui-dos sequencialmente para que a nova aplicação desenvolvida fosse reconhecida pelo Castalia e se tornasse funcional. O manual de usuário do Castalia [8] deve ser consultado em caso de dúvidas para a reprodução do processo especificado a seguir.
1) Definição do tipo de protocolo a ser adicionado, classificando-o em uma das seguintes categorias: apli-cação (categoria a qual o VisualCastalia pertence), roteamento, MAC e Gerenciador de Mobilidade (para nós sensores móveis). Essa definição é necessária, pois o Castalia predefine superclasses para cada categoria contendo funcionalidades necessárias ao tipo específico de módulo escolhido, assim como permite o reconheci-mento do novo módulo como parte do seu código fonte original.
2) Criação de um arquivo escrito utilizando a linguagem NED (herança direta do OMNeT++), contendo as es-pecificações estruturais do novo módulo de aplicação que, no caso do VisualCastalia, herda diretamente da superclasse node.application.iApplication do módulo Node do Castalia. O arquivo estrutural desse módulo deve conter explicitamente as variáveis e canais de co-municação definidas na superclasse, além das variáveis específicas da nova aplicação;
3) Criação de classes em linguagem C++ responsáveis por especificar o comportamento do módulo. No caso do VisualCastalia devem herdar diretamente da superclasse VirtualApplication e realizar a sobreposição das funções predefinidas na superclasse para atender aos requisitos do novo módulo;
4) Definição de um tipo especial de pacote de aplicação, que herda da classe ApplicationPacket, para dar suporte à transmissão de fragmentos das imagens geradas; 5) Recompilar o código fonte contendo os arquivos do
Figura 8: Inserção do VisualCastalia na estrutura original do Castalia.
erros de compilação no código fonte do novo módulo. A biblioteca de computação gráfica OpenCV [19], externa ao Castalia, foi utilizada para realizar as etapas que envolviam processamento de imagens na aplicação, retirando do código fonte da mesma essa responsabilidade, o que a tornou um re-quisito para a instalação do VisualCastalia. Das funcionalidade do módulo cobertas pela biblioteca, inclui-se: geração auto-mática de imagens aleatórias para transmissão na rede (caso o usuário não queira inserir imagens originais para a simulação), fragmentação das imagens para transmissão em pacotes de imagem e reconstrução das imagens após recepção de todos os seus fragmentos. Os motivos principais da escolha do OpenCV para o projeto baseiam-se no fato dela ser uma biblioteca de código aberto, muito bem documentada, amplamente testada e com uma expressiva comunidade de desenvolvedores disposta a apresentar soluções para problemas no desenvolvimento com a biblioteca.
Depois da instalação do OMNeT++, Castalia e OpenCV, para utilizar os novos serviços implementados pelo Visual-Castalia, é necessário que o usuário insira os arquivos de código fonte da extensão na estrutura original do Castalia. Essa abordagem de instalação foi utilizada para que os recursos existentes no Castalia continuem sendo acessíveis ao lado das novas funcionalidades do VisualCastalia, pois nenhum arquivo do código fonte do primeiro é apagado ou sobrescrito. A Fig. 8 demonstra como ocorre a atuação do VisualCastalia, que atualmente conta com a aplicação ImageTransmission (em vermelho), na estrutura original do módulo Node do Castalia. Ao todo, a aplicação ImageTransmission do VisualCastalia
conta com oito arquivos de código fonte, presentes na pasta
Di-retórioCastalia/src/node/application/imageTransmission. A seguir é apresentada uma descrição resumida de cada um dos arquivos da extensão:
• ImageTransmission.ned: Define a estrutura do módulo criado. As variáveis nele disponíveis são visíveis ao
usuário no momento da simulação. Esse arquivo permite ao Castalia definir a estrutura da aplicação ImageTrans-mission e identificá-la como parte de seu código fonte original;
• ImageTransmission.h e ImageTransmission.cc: Os ar-quivos definem a classe ImageTransmission que contém o comportamento de uma aplicação do Castalia associ-ada a cassoci-ada nó. Os detalhes de como pacotes de imagens são criados, transmitidos pelos nós fonte e recebidos pelos nós Sink são definidos por essa classe;
• ImagePacket.msg: Define pacotes de dados que irão conter as porções de imagens fragmentadas pela apli-cação ImageTransmission. Contém também parâmetros de cabeçalho usados pelo nó Sink para a agregação dos pacotes relacionados a uma mesma imagem e mesmo nó fonte no momento da reconstrução da imagem original; • SinkNodeManager.h e SinkNodeManager.cc: Essa classe define o comportamento de um nó Sink, e que por isso, precisa receber e agregar os pacotes de imagens, e remontar as imagens dos nós fonte da simulação; • ImageManager.h e ImageManager.cc: Classe onde
são tratados os processos de captura, fragmentação e agregação de imagens reais e aleatórias (geradas pela própria ferramenta) e toda a parte de processamento de imagens.
• ImageTransmissionUtils.cc e ImageTransmissionU-tils.h: Classe responsável por realizar tarefas úteis a todas as demais classes da aplicação como, por exemplo, escrita dos arquivos de Trace e conversões de tipos de dados.
• Dependencies.h: Arquivo que agrega todas as bibliote-cas de C++ utilizadas como dependências das classes da aplicação;
A Relação entre as classes componentes da aplicação Ima-geTransmission entre si e com o módulo Node do Castalia é
demonstrada no diagrama de classes presente na Fig. 9:
Figura 9: Diagrama de classes da aplicação ImageTransmis-sion.
O funcionamento resumido de nós sensores que utilizam a aplicação ImageTransmission é demonstrado a seguir:
• Para Nós Sink:
1) Após ser iniciado, irá criar os arquivos de texto para armazenar os dados das métricas PSNR e Latência das imagens que por ele serão recebidas e irá zerar a pasta de imagens recebidas para evitar deixar imagens de simulações anteriores nessa pasta;
2) Ao receber o primeiro pacote de um mesmo nó fonte e imagem original, irá abrir um buffer que armazenará todos os pacotes relacionados a essa mesma imagem;
3) Quando o último pacote válido de um mesmo nó fonte e imagem original for recebido, ele irá agregar os dados da imagem presente em seu buffer específico, para então salvá-los em um novo arquivo de imagem (na pasta de imagens recebidas correspondente ao nó fonte em questão). Caso um ou mais pacotes relacionados tenham sido perdidos, a aplicação preenche os dados faltosos na agregação com bits de valor zero para tentar gerar a imagem mesmo corrompida (esse processo pode gerar uma imagem danificada ou até mesmo inviabilizar o seu salvamento, caso muitos pacotes sejam perdidos);
4) No momento do salvamento da imagem recebida os seus valores de PSNR e latência são calculados e gravados em seus arquivos correspondentes para posterior análise.
• Para Nós Fonte:
1) O nó obtém uma imagem da pasta de imagens originais;
2) Após calcular quantos pacotes serão necessários, de acordo com o tamanho de pacotes de dados es-pecificado pelo usuário no arquivo de simulação, para enviar toda a imagem pela rede simulada, o nó coloca os fragmentos da imagem em uma pilha de dados e a cada período de tempo, especificado na frequência de transmissão, envia uma parte da imagem atual em um pacote diferente, em direção
ao seu vizinho indicado no arquivo se simulação (os nós sensores são posicionados arbitrariamente no ambiente simulado);
3) Quando todos os fragmentos da imagem atual são extraídos da pilha de dados, o nó fonte obtém uma nova imagem e realiza novamente o processo até que o tempo de simulação se esgote.
• Para Nós Intermediários:
Ao receber um pacote, imediatamente repassa para o seu vizinho indicado no arquivo de simulação. • Todo o processo de execução de qualquer tipo de nó
sensor é gravado no arquivo VisualCastaliaTrace. Para o processo de compilação do Castalia em conjunto com o VisualCastalia, é necessário informar ao simulador que ele deve utilizar as bibliotecas do OpenCV. Para isso, deve ser feita a adição, em um arquivo de nome makemake, presente no diretório raiz do Castalia, da diretiva
de compilação EXTOPTS=-L/usr/local/lib/ -lopencv_core
-lopencv_imgproc -lopencv_highgui -lopencv_imgcodecs
-I/usr/local/include/opencv -I/usr/local/include/opencv2".
Assim, quando for realizada a compilação do Castalia, em conjunto com a extensão VisualCastalia, as bibliotecas do OpenCV serão automaticamente ligadas ao código fonte evitando a ocorrência de erros de compilação.
Após inserir a diretiva de compilação no arquivo makemake, o seguinte comando para compilação do Castalia pelo terminal
Linux: make clean && ./makemake && make, deve ser
executado, estando na pasta raiz do Castalia, no momento da inserção dos arquivos da aplicação ImageTransmission no código fonte do simulador, para que este reconheça o novo módulo inserido.
As simulações do VisualCastalia são realizadas da mesma maneira que no Castalia, ou seja, em um arquivo de script, nomeado de omnetpp.ini, são adicionados todos os parâmetros da simulação desejada, como: número de nós sensores, pro-tocolos utilizados, dentre outros, sendo que a única diferença agora será adicionar os parâmetros de aplicação definidos em ImageTransmission. O objetivo de utilizar a mesma abordagem de simulação é evitar que os usuários já acostumados com as definições de simulação no Castalia sintam dificuldades em utilizar a nova extensão. Na tabela I são apresentados os princi-pais parâmetros de configuração para transmissão de imagens. É possível notar que alguns parâmetros foram aproveitados do Castalia, enquanto outros são da nova aplicação.
O parâmetro imgPckSendingMode é utilizado para indicar o tipo de transmissão de imagens pelo VisualCastalia. Caso seu valor seja 1, os nós sensores transmitem pacotes de forma cíclica e contínua, de acordo com a frequência de transmissão preestabelecida no parâmetro imageFrequency. Com o valor 2, especifica que os pacotes serão transmitidos em rajada (coloca os pacotes em buffer e os envia de uma só vez pela rede),
tão logo sejam criados. Apenas a opção de envio Continuo
foi implantada apropriadamente. O envio em Rajada exigia
que muitos pacotes fossem transmitidos em um curto período de tempo na rede do Castalia, o que resultava em erros como: parada abrupta da simulação e pausa na transmissão após o envio de dez pacotes em rajada, inviabilizando a
Tabela I: Parâmetros de configuração de ImageTransmission
Parâmetro Origem Tipo Default Descrição
packetHeaderOverhead Castalia Integer 27 Define o tamanho do cabeçalho dos pacotes, em bytes constantDataPayload Castalia Integer 100 Define a área útil de dados dos pacotes, em bytes
nextRecipient Castalia String "0" Indica o ID de qual nó sensor deve-se enviar o pacote de dados (Roteamento Estático) isSink VisualCastalia Boolean false Define se o nó sensor é do tipo Sink
imageFormat VisualCastalia String "jpg" Define o formato das imagens que serão transmitidas. Pode ser "jpg", "jp2" originalImagesFolder VisualCastalia String "originalImages" Define o diretório de origem das imagens, a partir do diretório raiz de simulação receivedImagesFolder VisualCastalia String "receivedImages" Define o diretório onde as imagens recebidas pelos nós Sink serão armazenadas numImageSources VisualCastalia Integer 0 Define o número de imagens que serão obtidas da pasta de origem
imageFrequency VisualCastalia Double 0 Define o número de imagens transmitidas por segundo. Se 0, o nó não transmite imagens imgPckSendingMode VisualCastalia String 1 Define o modo de transmissão. 1 para Contínua e 2 para Rajada
selfGeneratedImage VisualCastalia Boolean false Indica se imagens utilizadas serão geradas automaticamente pela Aplicação imgHeight VisualCastalia Integer 64 Se selfGeneratedImage for igual a true, especifica o altura das imagens geradas imgWidth VisualCastalia Integer 64 Se selfGeneratedImage for igual a true, especifica o largura das imagens geradas useColoredImage VisualCastalia Boolean true Define se as imagens transmitidas serão coloridas
funcionalidade.
Para a utilização do VisualCastalia com imagens reais, fornecidas pelo usuário, deve-se criar uma pasta, e informar sua localização pelo parâmetro originalImagesFolder, nome-ando cada imagem, obrigatoriamente, com uma identificação numérica e em ordem crescente (por exemplo, 0.jpg, 1.jpg, 2.jpg, etc). O número de imagens na pasta deve ser maior ou igual a quantidade máxima de fontes de imagens definidas na variável numImageSources do nó fonte. Mais de um nó fonte pode utilizar uma mesma pasta de origem. As imagens resultantes da transmissão são salvas na pasta especificada pela variável receivedImagesFolder em uma subpasta de nome igual ao ID do nó fonte considerado.
O algoritmo 1 demonstra um modelo simples de simula-ção, definido no arquivo omnetpp.ini, que utiliza a aplicação ImageTransmission. A simulação possui o único objetivo de demonstrar o uso dos parâmetros que devem ser configurados para executar o VisualCastalia. A simulação de 3600 segundos de duração (em tempo de simulação), contém dois nós sensores visuais, posicionados em um campo (plano cartesiano) de 25 metros quadrados, sendo o nó sensor de ID = 0, posicionado no ponto (x=0, y=2), um nó Sink e o nó sensor de ID = 1, posicionado no ponto (x=5, y=2), um nó fonte. O nó fonte da simulação envia quatro diferentes tipos de imagens geradas automaticamente pela aplicação, de formato JPEG, com resolução 64x64 pixels, sendo enviadas a uma frequên-cia de 0.2 imagens/segundo. Estabelece-se que pacotes de dados transmitidos terão 100 bytes de payload e 27 bytes de cabeçalho. O processo de roteamento é estático, ou seja, o caminho em que os pacotes de imagem percorrem é indicado diretamente no script de simulação, nesse caso o nó sensor de ID = 0 envia os pacotes diretamente para o nó Sink.
1 [ G e n e r a l ] 2 3 i n c l u d e . . / P a r a m e t e r s / C a s t a l i a . i n i 4 5 sim time l i m i t = 3600 s 6 7 SN . f i e l d _ x = 5 # m e t e r s 8 SN . f i e l d _ y = 5 # m e t e r s 9 SN . f i e l d _ y = 0 # m e t e r s 10 11 SN . numNodes = 2 12
13 SN . node [ 0 ] . xCoor = 0 # NODE 0 14 SN . node [ 0 ] . yCoor = 2
15
16 SN . node [ 1 ] . xCoor = 5 # NODE 1 17 SN . node [ 1 ] . yCoor = 2
18
19 SN . node [ ⇤ ] . Communication . Radio . R a d i o P a r a m e t e r s F i l e =
" . . / P a r a m e t e r s / Radio / CC2420 . t x t "
20
21 SN . node [ ⇤ ] . Communication . Radio . TxOutputPower = " 5
dBm" 22 23 SN . node [ ⇤ ] . A p p l i c a t i o n . packetHeaderOverhead = 27 24 25 SN . node [ ⇤ ] . A p p l i c a t i o n . c o n s t a n t D a t a P a y l o a d = 100 26 27 SN . node [ ⇤ ] . A p p l i c a t i o n . c o l l e c t T r a c e I n f o = t r u e 28
29 SN . node [ ⇤ ] . Communication . MACProtocolName = "TMAC" 30
31 SN . node [ ⇤ ] . Communication . RoutingProtocolName = "
B yp as sR o ut in g " 32 33 SN . node [ ⇤ ] . ApplicationName = " I m a g e T r a n s m i s s i o n " 34 35 SN . node [ 0 ] . A p p l i c a t i o n . i s S i n k = t r u e 36 SN . node [ 1 ] . A p p l i c a t i o n . i s S i n k = f a l s e 37 38 SN . node [ 0 ] . A p p l i c a t i o n . numImageSources = 0 39 SN . node [ 1 ] . A p p l i c a t i o n . numImageSources = 4 40 41 SN . node [ 0 ] . A p p l i c a t i o n . s t a r t u p D e l a y = 0 42 SN . node [ 1 ] . A p p l i c a t i o n . s t a r t u p D e l a y = 1 43 44 SN . node [ ⇤ ] . A p p l i c a t i o n . imgPckSendingType = 1 45 46 SN . node [ 0 ] . A p p l i c a t i o n . imageFrequency = 0 47 SN . node [ 1 ] . A p p l i c a t i o n . imageFrequency = 0 . 2 48 49 SN . node [ 0 ] . A p p l i c a t i o n . n e x t R e c i p i e n t = " 0 " 50 SN . node [ 1 ] . A p p l i c a t i o n . n e x t R e c i p i e n t = " 1 " 51 52 SN . node [ ⇤ ] . A p p l i c a t i o n . imageFormat = " j p g " 53 SN . node [ ⇤ ] . A p p l i c a t i o n . useColoredImages = t r u e 54 SN . node [ ⇤ ] . A p p l i c a t i o n . o r i g i n a l I m a g e s F o l d e r = " o r i g i n a l I m a g e s " 55 SN . node [ ⇤ ] . A p p l i c a t i o n . r e c e i v e d I m a g e s F o l d e r = " r e c e i v e d I m a g e s " 56 SN . node [ ⇤ ] . A p p l i c a t i o n . s e l f G e n e r a t e d I m g = t r u e 57 SN . node [ ⇤ ] . A p p l i c a t i o n . imgHeight = 64
58 SN . node [ ⇤ ] . A p p l i c a t i o n . imgWidth = 64
Algoritmo 1: Exemplo de simulação simples utilizando o VisualCastalia
Após a configuração do arquivo omnetpp.ini, deve-se exe-cutar a simulação com o script Castalia, localizado na pasta DiretórioCastalia/bin junto com os demais scripts de análise de resultados tanto do Castalia quanto do VisualCastalia. Assim como a análise e geração de gráficos com os resultados das simulações do Castalia é feita pelos scripts CastaliaResults e CastaliaPlot respectivamente, o VisualCastalia possui o script VisualCastaliaResults que permite analise e geração de gráficos dos resultados gerados pela sua simulação. Em resumo, os resultados de simulação com o VisualCastalia podem ser dos tipos descritos a seguir:
• Resultados de desempenho do Castalia: geração de tabelas e gráficos com, por exemplo, o consumo de energia e perda de pacotes. Dados que se apresentam como resultados válidos também para transmissões de imagens;
• Resultados de Desempenho do VisualCastalia: gera-ção de tabelas e gráficos com a métrica PSNR (valor por imagem individual e valor médio por nó) das imagens recebidas e Latência da transmissão (valor por imagem individual, valor médio por nó e soma dos valores por nó);
• Castalia e VisualCastalia traces: arquivos de texto contendo informações passo a passo da troca de pacotes entre componentes da simulação e, no caso do Visual-Castalia, todo o processo de fragmentação e transmissão das imagens pela rede. A Fig. 10, demostra um exemplo de Trace do VisualCastalia, cada linha do arquivo é organizada em: tempo de simulação do evento, ID do nó sensor que gerou o evento e ação realizada. • Visualização das imagens criadas: como imagens
re-ais são transmitidas durante a simulação, sendo estas armazenadas, após o seu recebimento pelos nós Sink, em pastas de resultados, as imagens recebidas podem ser diretamente visualizadas e analisadas pelo usuário, que pode, se desejar, até mesmo aplicar métricas de qualidade de imagens ainda não disponíveis no Visu-alCastalia.
O desenvolvimento do VisualCastalia foi realizado em um computador com sistema operacional Linux Fedora 23, utili-zando simuladores Castalia 3.2 e OMNeT++ 4.6 (versões mais novas do OMNeT++ foram testadas, porém não apresentaram boa compatibilidade com a versão do Castalia utilizada), biblioteca OpenCV 3.1. A geração de gráficos pelo script VisualCastaliaResults é feita com auxílio do GNUPLOT 5.0. A extensão VisualCastalia pode ser executada em qualquer máquina contendo um sistema operacional baseado em Unix, como Mac OS e Linux, não tendo seu uso suportado em plataformas Windows.
A documentação do módulo: manuais de instalação e de usuário, e código fonte mais atualizado do VisualCastalia encontram-se disponíveis em versões digitais na página WEB (em inglês): http://netmedia.uefs.br/visualcastalia.html.
Figura 10: Parte de um Trace gerado pelo VisualCastalia.
IV. RESULTADOS EDISCUSSÕES
O VisualCastalia foi construído com o objetivo de ser um sistema para testes de algoritmos distribuídos em Redes de Sensores Visuais Sem Fio. Assim, com o uso da aplicação ImageTransmission, é possível testar diversos tipos de proto-colos, Rádio, MAC, Roteamento, dentre outros, para RSVSF para verificar os impactos, através das métricas de qualidade que a extensão oferece e das imagens reais transmitidas na simulação, que esses protocolos irão causar na rede simulada. Para exemplificar os resultados obtidos, foram especificados três cenários de testes que possuem as seguintes características em comum:
• Tempo de simulação de uma hora;
• Nós sensores que usam o ImageTransmission do Visual-Castalia como protocolo da camada de aplicação (onde são transmitidas quatro tipos diferentes de imagens, no formato JPEG, em loop)
• Rádio transmissor com potência de -5dBm (46.2mW ), para conseguirem um bom alcance de transmissão; • Utilizam o protocolo T-MAC na camada de controle
de acesso ao meio (para possibilitar melhor uso dos recursos energéticos)
• Utilizam o protocolo ByPassRouting na camada de rote-amento (para realizar o roterote-amento estático, onde o nó sensor irá transmitir todos os pacotes recebidos para o seu vizinho indicado no arquivo de simulação); • Os pacotes de imagem possuem uma carga de dados
de 100 bytes, exigindo que a aplicação fragmente as imagens para que sejam transmitidas apropriadamente pela rede.
Todos os cenários foram testados com a transmissão das imagens em duas resolução, e consequentemente tamanhos, diferentes. No primeiro caso as imagens possuíam resolução de 64X64 pixels, enquanto que no segundo caso as imagens estavam configuradas com resolução de 128X128 pixels. Os resultados do uso de dois tamanhos de imagens em cada cenário de teste serviu para o verificação do impacto causado pelo aumento da resolução das imagens no processo de trans-missão. Os detalhes específicos, assim como os resultados de
simulação, de cada cenário de teste são exemplificados nas subseções seguintes.
A. Cenário de Testes 1
O primeiro cenário de teste, cujo esquema de implantação dos nós sensores está definido na Fig. 11, foi projetado para apresentar um ambiente de uma RSVSF simples, com um nó transmissor de imagem, um nó intermediário (que repassa pacotes recebidos) e um nó Sink. Os nós sensores estão separados de seu vizinho mais próximo por uma distância de 10 metros.
Figura 11: Esquema de Fluxo do dados pelos nós sensores na RSVSF no Cenário 1
O consumo de energia, medido em Joules, dos nós sensores nesse cenário de testes, representado pela Fig. 12, apresenta comportamento dentro do esperado, com os nós sensores visuais apresentando gasto energético próximo um do outro, onde o nó Sink (ID = 0) apresenta maior consumo com relação aos demais nós, pois este dispositivo está a todo momento recebendo pacotes de todos os outros nós sensores da rede.
100 110 120 130 140 150 160 170 0 1 2 Energia (J) Identificação do nó sensor Energia consumida (Cenário 1)
64x64 128x128
Figura 12: Energia gasta por nó sensor no cenário 1. Ao comparar o gasto energético que os nós apresentaram ao transmitirem imagens de resolução 64x64 e de resolução 128x128, é possível notar que o aumento da resolução das imagens causou também um aumento no gasto energético dos sensores em geral. Esse comportamento é esperado, pois os nós sensores devem transmitir uma maior quantidade de pacotes com dados das imagens, devido ao aumento do tamanho das
imagens e consequentemente do número de pacotes gerados para cada uma, no mesmo período de tempo que tiveram para transmitir as imagens de menor resolução. Pode-se notar que esse comportamento persiste em todos os cenários especifica-dos nesse trabalho, representaespecifica-dos pelas Fig. 16 e Fig. 21.
O nó fonte desse cenário estava configurado para transmitir a uma frequência de 1imagem/segundo. A latência dessa transmissão, medida em segundos, pode ser verificada nas tabelas apresentadas na Fig. 13, que demonstram um valor de latência média de transmissão de imagem próximo ao valor estipulado. A natureza inerente a erros do meio sem fio, apresentada pelos modelos empíricos de dados do Castalia, acaba fazendo com que o valor de latência apresente-se um pouco maior do que o estipulado.
(a) Com imagens de resolução 64X64
(b) Com imagens de resolução 128X128
Figura 13: Latência média de transmissão no cenário 1. Nota-se que os valores de latência média, medida em segundos, para transmissão de imagens com maior resolução, apresentados na Fig. 13b, são maiores do que os de imagens com menor resolução, apresentados na Fig. 13a. Esse compor-tamento apresenta-se dentro do esperado, pois o maior número de pacotes gerados por uma imagem de maior resolução necessita de mais tempo para percorrer toda a rede, atrasando a entrega e aumentando a latência. Esse comportamento também pode ser verificado para os demais cenários especificados nesse trabalho, demonstrados nas figuras Fig. 17 e Fig. 22.
Em contrapartida com os valores de gasto energético e latência média, o valor de PSNR médio, representado na Fig. 14, diminui com o aumento da resolução das imagens. A razão dessa diminuição de valor ocorre porque o maior número de pacotes gerados pelas imagens de resolução mais alta gera maior número de colisões de pacotes, o que leva a maiores perdas de pacotes, gerando mais erros na reconstrução das imagens pelo nó Sink. A qualidade de imagem perdida de uma resolução para outra é consideravelmente alta se levado em conta que mesmo uma unidade de diferença entre os dois va-lores de PSNR representa uma grande perda, pois essa métrica é medida em escala logarítmica (decibéis). Apenas o PSNR médio das imagens de resolução 64x64: aproximadamente 21 dB, apresenta um valor aceitável para transmissões sem fio (que deve apresentar-se em média entre 20 dB e 25 dB [18]). O comportamento de PSNR especificado para esse cenário se repete nos demais e pode ser comprovado nas figuras Fig. 18
e Fig. 23
(a) Com imagens de resolução 64X64
(b) Com imagens de resolução 128X128
Figura 14: PSNR médio das imagens recebidas no cenário 1.
B. Cenário 2
O segundo cenário, cujo esquema de implantação dos nós sensores está definido na Fig. 15, foi projetado para apresentar um ambiente mais estressante para o nó Sink, onde três nós fonte estão transmitindo para apenas um nó Sink ao mesmo tempo. A frequência de transmissão dos nós fonte era de
0.5imagens/segundo (uma imagem a cada dois segundos é
recebida pelo nó Sink). Os nós sensores estão separados de seu vizinho mais próximo por uma distância de 10 metros.
Figura 15: Esquema de Fluxo do dados pelos nós sensores na RSVSF no Cenário 2.
O gasto de energia dos nós sensores nesse cenário de testes, apresentado na Fig. 16, demonstrou um comportamento dentro do esperado, com o nó Sink (ID = 2) apresentando maior gasto energético que os demais nós sensores por receber pacotes de todos os nós sensores, seguido do nó sensor que funciona tanto como nó intermediário (repassa pacotes dos vizinhos) quanto como nó fonte (ID = 1) e dos dispositivos que se comportam apenas como nós fonte ou nós intermediários por vez, mas não os dois (ID = 0, 3, e 4) que apresentam menor consumo energético. É interessante notar que, mesmo com a diminuição da frequência de imagem dos nós fonte, o aumento do consumo energético médio do nó Sink nesse cenário de teste foi significativo se comparado com os valores gastos pelo nó Sink do Cenário 1, presente na figura 12, saindo de aproximadamente 160J de valor médio máximo para 200J.
80 100 120 140 160 180 200 0 1 2 3 4 Energia (J) Identificação do nó sensor Energia consumida (Cenário 2)
64x64 128x128
Figura 16: Energia gasta por nó sensor no cenário 2. O valor de latência média desse cenário, demonstrado na Fig. 17, apresenta-se em acordo com o demonstrado na explicação da latência média no Cenário 1, onde os nós entregam a imagem com um pouco de atraso se comparado com a frequência de imagem inserida no arquivo de simulação, condição justificada pelos problemas inerentes de comunicação em meio sem fio. Porém, é interessante notar que quanto mais próximo do Nó Sink encontra-se o nó fonte, menor é a latência de transmissão da imagem. 2.25 2.3 2.35 2.4 2.45 2.5 2.55 2.6 2.65 2.7 0 1 2 3 4 Latência (s) Identificação do nó sensor Latência média (Cenário 2)
64x64 128x128
Figura 17: Latência média de transmissão por nó sensor no cenário 2
O valor de PSNR médio para o cenário 2, apresentado na Fig. 18, apresenta-se de acordo com o exemplificado no Cenário 1. É possível notar, porém, que apenas o valor médio de PSNR do nó transmissor de ID = 1 com imagens de resolução 64x64, com valor de aproximadamente 20 dB, está próximo ao aceitável para comunicações sem fio com perdas. Na Fig. 19 é apresentada uma comparação entre uma ima-gem transmitida, e reconstruída com erros, com sua original. A quantidade de reconstruções que resultaram em imagens corrompidas foi alta nesse cenário de testes.
C. Cenário 3
O terceiro cenário, cujo esquema de implantação dos nós sensores está definido na Fig. 20, foi projetado para
4 6 8 10 12 14 16 18 20 22 0 1 2 3 4 PSNR (dB) Identificação do nó sensor PSNR médio (Cenário 2) 64x64 128x128
Figura 18: PSNR médio para imagens recebidas no cenário 2
(a) Imagem original (b) Imagem transmitida pelo VisualCastalia. PSNR = 8.32 dB
Figura 19: Comparação entre uma imagem transmitida no cenário 2 e sua original.
sentar um ambiente onde o trabalho de recepção de dados é distribuído entre três nós Sink diferentes. Os nós fontes estão transmitindo a uma frequência de 0.2imagens/segundo (Uma imagem a cada cinco segundos é recebida pelo nó Sink relacionado). Os nós sensores estão separados de seu vizinho mais próximo por uma distância de 5 metros.
Figura 20: Esquema de Fluxo do dados pelos nós sensores na RSVSF no Cenário 3.
O gasto de energia médio apresentado nesse cenário de teste, demostrado na Fig. 21, ainda apresenta maior gasto energético por parte dos nós Sink, porém, é interessante notar que a diferença de valores entre nós Sink e demais nós
sensores é muito menor se comparado com os cenários de teste anteriores, em especial ao cenário 2, onde o nó Sink sofre uma sobrecarga de pacotes. O que demonstra que essa abordagem pode prolongar o tempo de vida da rede de sensores.
90 100 110 120 130 140 0 1 2 3 4 5 6 7 8 Energia (J) Identificação do nó sensor Energia consumida (Cenário 3)
64x64 128x128
Figura 21: Energia gasta por nó sensor no cenário 3. O valor de latência média desse cenário de testes, demons-trado na Fig. 22, segue em conformidade com a explicação utilizada para exemplificar a latência média demonstrada no Cenário 1. 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 0 1 2 3 4 5 6 7 8 Latência (s) Identificação do nó sensor Latência média (Cenário 3)
64x64 128x128
Figura 22: Latência média de transmissão por nó sensor no cenário 3.
A distribuição dos pacotes nos três nós Sink, também provocou um significativo aumento da qualidade das imagens recebidas, que pode ser comprovado pelo aumento dos valores de PSNR médio, apresentados na Fig. 23, em comparação com os cenários 1 e 2. Nota-se que, na transmissão de imagens com resolução de 64x64, os nós sensores de IDs = 1, 4 e 7 apresentaram valores de PSNR médio de aproximadamente 26, 33 e 27 db respectivamente, bem acima da média para transmissões sem fio com perdas.
A comparação de uma imagem transmitida pelo VisualCas-talia com sua original está presente na Fig. 24. Nota-se que a imagem foi inteiramente reconstruída e é difícil perceber, sem ferramentas especiais, diferenças com sua original.
5 10 15 20 25 30 35 0 1 2 3 4 5 6 7 8 PSNR (dB) Identificação do nó sensor PSNR médio (Cenário 3) 64x64 128x128
Figura 23: PSNR médio para imagens recebidas no cenário 3.
(a) Imagem original (b) Imagem transmitida pelo VisualCastalia. PSNR = 43.41 dB
Figura 24: Comparação entre uma imagem transmitida no cenário 3 e sua original.
V. CONCLUSÕES
O VisualCastalia cumpriu com as principais funcionalida-des definidas no início do projeto. O projeto de iniciação científica que deu origem ao VisualCastalia foi planejado para ser inicialmente uma ferramenta que abordaria todas as etapas de simulação de uma Rede de Sensores Visual Sem Fio, onde todos os principais módulos do simulador Castalia seriam adaptados para fornecer o suporte a esse tipo de rede. Porém, após o início do desenvolvimento, a diminuição do escopo inicial do projeto provou-se mais eficiente para entregar uma funcionalidade importante das RSVSF, a transmissão de imagens.
Ideias para projetos futuros envolvendo melhorias em funci-onalidades da extensão VisualCastalia incluem permitir simu-lações com diferentes formatos de imagem, não somente JPEG, e o envio de pacotes em rajada. Enquanto que em trabalhos futuros com a extensão planeja-se realizar comparações com outros simuladores que permitam a transmissão de imagens em Redes de Sensores Sem Fio.
AGRADECIMENTOS
A Deus que, em sua infinita sabedoria, criou a humanidade e permitiu que ela fizesse coisas maravilhosas, assim como me permitiu ter a curiosidade, força de vontade e saúde para
buscar o conhecimento necessário para completar esse trabalho e superar todos os desafios provenientes dele.
Aos meus pais, pelo amor incondicional, apoio emocional e financeiro, e incetivos dados a mim para me ajudar a completar a jornada que foi o bacharelado em Engenharia de Computação.
À CNPQ e FAPESB por terem fomentado os projetos de Iniciação Científica que iniciaram o desenvolvimento desse projeto.
Ao meu orientador, Daniel Gouveia Costa, por ter me acompanhado, incentivado e corrigido na jornada de conhe-cimento necessária para me tornar um pesquisador em Redes de Sensores Visuais Sem Fio.
E a todos que, mesmo de forma indireta, contribuíram em minha formação acadêmica, o meu muito obrigado.
REFERÊNCIAS
[1] A. A. Loureiro, J. M. S. Nogueira, L. B. Ruiz, R. A. de Freitas Minia, E. F. Nakamura, and C. M. S. Figueiredo, “Redes de sensores sem fio,” Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos, 2003.
[2] J. Yick, B. Mukherjee, and D. Ghosal, “Wireless sensor network survey,” Computer Networks, vol. 52, pp. 2292–2330, Aug. 2008. [3] I. F. AKYILDIZ, T. MELODIA, and K. R. CHOWDHURY, “A survey
on wireless multimedia sensor networks,” Computer Networks, vol. 51, no. 4, pp. 921–960, 2007.
[4] P. Baronti, P. Pillai, V. W. Chook, S. Chessa, A. Gotta, and Y. F. Hu, “Wireless sensor network survey,” Computer Communication, vol. 30, pp. 1655–1695, May. 2007.
[5] D. G. Costa and L. A. Guedes, “A discrete wavelet transform (dwt)-based energy-efficient selective retransmission mechanism for wireless image sensor networks,” Journal of Sensor and Actuator Networks, vol. 1, no. 1, pp. 3–35, 2012.
[6] H. Sudani, H. Li, V. Devabhaktuni, M. Alam, and P. Bhattacharya, “Wireless sensor network simulators: A survey and comparisons,” International Journal Of Computer Networks, vol. 2, pp. 249–265, Nov. 2010.
[7] M. JEVTIC and N. ZOGOVIC, “Evaluation of wireless sensor network simulations,” 17th Telecommunications forum TELFOR 2009, 2009. [8] A. BOULIS. (2011) Castalia – a simulator for wireless sensor
network and body area networks – user’s manual. version 3.2. Accessed: 2016-08-16. [Online]. Available: https://forge.nicta.com.au/ docman/view.php/301/592/Castalia+-+User+Manual.pdf
[9] A. Vargas. (2014) Omnet++ user manual. version 4.6. Accessed: 2016-07-10. [Online]. Available: https://omnetpp.org/doc/omnetpp4/ Manual.pdf
[10] P. CONGDUC. (2015) A video sensor simulation model with omnet++, castalia extension. Accessed: 2016-08-21. [Online]. Available: http: //cpham.perso.univ-pau.fr/WSN-MODEL/wvsn-castalia.html [11] C. NASTASI and A. CAVALLARO, “Wise-mnet: an experimental
environment for wireless multimedia sensor networks,” London, United Kingdom, Sep. 2011.
[12] Z. ZLOGLIANG, “A tutorial of the mobile multimedia wireless sensor network. omnet++ framework,” Proceedings of the “OMNeT++ Com-munity Summit 2015”, 2015.
[13] D. G. Costa, “Otimizações da transmissão de imagens em redes de sensores visuais sem fio explorando a relevância de monitoramento dos nós fontes e codificação dwt,” Ph.D. dissertation, Universidade Federal do Rio Grande do Norte, Natal - RN - Brasil, Abril 2013.
[14] S. A. F. Soares, “Rede de sensores sem fio para localização e moni-toramento de pequenos ruminantes,” Ph.D. dissertation, Universidade Federal do Vale do São Francisco, Juazeiro - BA - Brasil, 2012.
[15] K. L. Tijs van Dam, “An adaptive energy-efficient mac protocol for wireless sensor networks,” SenSys ’03 Proceedings of the 1st internati-onal conference on Embedded networked sensor systems, pp. 171–180, 2003.
[16] G. K. Wallace, “The jpeg still picture compression standard,” IEEE Transactions on Consumer Electronics, vol. 38, no. 1, Feb. 1992. [17] D. Z. Alain Hore, “Image quality metrics: Psnr vs. ssim,” Oct. 2010,
pp. 2366–2369.
[18] X. J. Mohamed Mostafa A. Azim, Wireless Sensor Multimedia Net-works: Architectures, Protocols, and Applications. CRC Press, 2015, iSBN 978-1482253115.
[19] I. Culjak, D. Abram, T. Pribanic, H. Dzapo, and M. Cifrek, “A brief introduction to opencv,” in Proceedings of the 35th International Convention, Opatija, Croatia, 2012, pp. pp: 1725–1730.
