BACHARELADO EM ENGENHARIA DE COMPUTAÇÃO
MOAB RODRIGUES DE JESUS
UMA ANÁLISE COMPARATIVA DE SIMULADORES COMPUTACIONAIS PARA REDES DE SENSORES MULTIMÍDIA SEM FIO
FEIRA DE SANTANA 2015
UMA ANÁLISE COMPARATIVA DE SIMULADORES COMPUTACIONAIS PARA REDES DE SENSORES MULTIMÍDIA SEM FIO
Trabalho de Conclusão de Curso apresentado ao Colegiado do curso de Engenharia de Computação como requisito parcial para obtenção do grau de Bacharel em Engenharia de Computação pela Universidade Estadual de Feira de Santana.
Orientador: Daniel Gouveia Costa
FEIRA DE SANTANA 2015
A Deus pelo puro e simples dom da vida.
Aos meus pais, Agenario e Seilde, pelo incentivo, suporte, atenção e paciência. A Marcos e Margarida, por ouvirem aparentemente focados, ideias mirabolantes que nunca tornaram-se projetos.
Ao meu orientador, Daniel, pela oportunidade concedida e paciência.
Por fim, agradeço aos obstáculos, companheiros imateriais fiéis que tanto me fizeram crescer.
O uso de redes de sensores sem fio tem crescido muito nos últimos anos. Esse crescimento se deve, entre outros fatores, ao avanço nos métodos de fabricação destes sensores, favorecendo o surgimento de novas áreas de pesquisa. Diversos setores tem aplicado esse tipo de rede para melhorar o desempenho na realização de tarefas. Medicina, agricultura, monitoramento ambiental, segurança civil e militar são alguns dos setores que têm se beneficiado com esta nova tecnologia. Sendo uma tecnologia relativamente nova, muitos desafios surgem no momento que tais redes devem ser implementadas. Para minimizar o risco de fracasso, diversos simuladores computacionais foram desenvolvidos, no intuito de fornecer dados confiáveis acerca da aplicabilidade das redes. Diversos softwares de simulação de redes de sensores sem fio de propósito especifico e geral surgiram, o que pode implicar dificuldades no momento de escolher qual o melhor software para simular determinada rede. Alguns softwares oferecem simulações de redes de sensores sem fio escalares, outros oferecem a possibilidade de simular sensores multimídia, ou mesmo sensores com nós moveis. Outra importante característica a ser analisada antes de realizar uma simulação são as limitações do software, quais parâmetros podem ser variados durante a simulação, quais protocolos podem ser utilizados, qual o desempenho e gasto computacional, qual o tamanho máximo das redes que podem ser simuladas, se o software é capaz de simular em tempo real, entre outros fatores. Estas são algumas características que devem ser analisadas antes de uma simulação de alto nível e são elas que servirão de parâmetro para comparar os softwares de simulação de redes de sensores multimídia sem fio. Neste trabalho diferentes Redes de Sensores Multimídia Sem Fio serão simuladas em diferentes softwares, a fim de obter dados consistentes que possam facilitar a escolha do software mais indicado para as redes simuladas. Palavras-chave: Rede de Sensores Sem Fio. Simulações. Redes de Sensores Multimídia Sem Fio. Análise de redes Sem Fio, Análise de Simuladores
The use of wireless sensor networks has been growing in the last years. This growth is due to the advances in methods of making of the sensors and with that many new areas with possible applications have emerged. Various sectors have been using this type of network to enhance the performance in the execution of tasks. Medicine, agriculture, environmental monitoring, civil and military security are some of the sectors that have been using the benefits of this technology. Being a relatively new technology, many challenges emerge upon the implementation of such networks. To minimize the risk of failure, several computer simulators were developed, with the goal of provide trustworthy data about the applicability of these networks. Several wireless sensor network simulation softwares of general and specific purposes were developed, and this creates a difficult on which one is the most adequate to simulate a particular network. Some softwares offer simulation of scalar wireless sensor networks, others offer the possibility of simulate multimedia sensors, or even sensors with mobile nodes. Other important features to be analyzed before performing a simulation are the limitation of the software, which parameters can vary during the simulation, which protocols can be used, what is the performance and computational cost, what is the maximum size of network that can be simulated, if the software is capable of real time simulation, etc. These are some questions that are made before a high level simulation e they are the ones used as parameters to compare the multimedia wireless sensor network simulation softwares. In this work, different multimedia wireless sensor networks will be simulated in different softwares, aiming to obtain consistent data and elect the software most adequate to the networks simulated.
Keywords: Wirelles Sensor Networks. Simulations. Wireless Multimedia Sensor Networks. Analysis of Wireless Networks. Analysis of Simulators
Figura 1 Estrutura de um Rede de Sensores sem Fio 17
Figura 2 Estrutura de scripts no NS-2 26
Figura 3 Sequência para descrição de topologias no ambiente NS-3 28
Figura 4 Rede de sensores sem fio ad hoc organizada em forma de matriz. 35
Figura 5 Rede de sensores sem fio hierarquizada. 36
Figura 6 Criação de variáveis de simulação e instância de simulador no NS-2 38
Figura 7 Criação e configuração da topologia no NS-2 39
Figura 8 Criação dos agentes de simulação no NS-2 40
Figura 9 Criação de nós, canal de propagação, camadas de enlace e rede no
NS-3 41
Figura 10 Criação e configuração da camada de aplicação no NS-3 42
Figura 11 Formatação de topologia matricial no Castalia 43
Figura 12 Configuração de camada MAC, aplicação e roteamento no Castalia 44
Figura 13 Modificação de código-fonte do Castalia 45
Figura 14 Arquivo de rastreamento do Evalvid no NS-3 51
Figura 15 Topologia criada no Castalia e visualizada através de ambiente gráfico
Figura 17 Ferramenta de geração de gráficos do NS-2 54
Figura 18 Aplicação da primeira derivada utilizando ferramenta de geração de
gráficos do NS-2 55
Figura 19 Aplicação da segunda derivada utilizando ferramenta de geração de
gráficos do NS-2 55
Figura 20 Tela do NAM no NS-3 56
Figura 21 Geração de gráficos no NS-3 57
Figura 22 Geração de gráficos no Castalia 58
Figura 23 Comando top do Ubuntu 60
Figura 24 Comparação entre Tempo real versus Tempo de virtual 61
Figura 25 Consumo de memória versus número de nós 63
Figura 26 Relação entre tempo de processamento e número de nós 64
Figura 27 Relação número de nós e consumo de memória utilizando DSDV para
NS-2 e NS-3 66
Figura 28 Relação número de nós e tempo de processamento da simulação
utilizando DSDV no NS-2 e NS-3 66
Figura 29 Mensagem de estouro de memória do NS-2 67
Figura 30 Relação entre número de nós e tempo de processamento em rede com
IEEE 802.11 e AODV 69
Figura 32 Relação entre tempo de processamento e tempo configurado na
simulação com IEEE 802.11 e DSDV 70
Figura 33 Relação entre consumo de memória e número de nós em simulação
Tabela 1 Tabela com especificação dos métodos de pesquisa aplicados 33
Tabela 2 Casos de testes com rede ad hoc disposta em forma de matriz. 37
Tabela 3 Resumo das principais características e funcionalidades dos softwares
avaliados 59
Tabela 4 Extrapolação para tempos de simulação 62
Tabela 5 Resultado das simulações com NS-3 para topologia matricial com
DSDV 64
Tabela 6 Resultado das simulações com NS-2 para topologia matricial com
RSSF Rede de Sensores Sem Fio
RSMSF Rede de Sensores Multimídia Sem Fio
AODV Ad hoc On-Demand Distance Vector
DSR Dynamic Source Routing
DSDV Destination-Sequenced Distance-Vector
GPS Global Positioning System
DCT Discrete Cossine Transform
DWT Discrete Wavelet Transforms
CCP Coverage Configuration Protocol
DFSSP Differentiated Surveillance Service Protocol
QoS Quality of Service
NAM Network Animator
POO Programação Orientada a Objetos
NED Network Description
RTP Real-time Transport Protocol
RTCP Real Time Control Protocol
QoE Quality of Experience
UDP User Datagram Protocol
1 INTRODUÇÃO. . . 12
2 FUNDAMENTAÇÃO TEÓRICA . . . 15
2.1 REDE DE SENSORES SEM FIO . . . 15
2.1.1 ARQUITETURA DE UMA REDE DE SENSORES SEM FIO . . . 15
2.1.2 PADRÕES DA CAMADA DE REDE . . . 16
2.1.3 PROTOCOLOS DE ROTEAMENTO . . . 18 2.1.3.1 PROTOCOLO AODV . . . 19 2.1.3.2 PROTOCOLO DSR . . . 19 2.1.3.3 PROTOCOLO DSDV . . . 20 2.1.4 SERVIÇOS . . . 20 2.1.4.1 LOCALIZAÇÃO E COBERTURA . . . 20 2.1.4.2 SEGURANÇA E CONFIABILIDADE . . . 21
2.2 REDE DE SENSORES MULTIMÍDIA SEM FIO . . . 22
2.2.1 COMPRESSÃO E AGREGAÇÃO . . . 22
2.2.2 COBERTURA DE MONITORAMENTO . . . 23
2.2.3 QUALIDADE DE EXPERIÊNCIA E QUALIDADE DE SERVIÇO . . . 23
2.3 SIMULADORES DE REDES . . . 24
2.3.1 SOFTWARES DE SIMULAÇÃO . . . 25
2.3.1.1 NS-2 . . . 25
2.3.1.2 NS-3 . . . 27
2.3.1.3 OMNET++ . . . 28
2.3.2 EXTENSÕES DOS SIMULADORES DE REDES . . . 29
2.3.2.1 CASTALIA . . . 29 2.3.2.2 EVALVID . . . 30 3 METODOLOGIA . . . 32 3.1 MODELOS DE RSMSF UTILIZADOS . . . 33 3.2 MODELAGEM DE RSMSF . . . 36 3.2.1 NS-2 . . . 37 3.2.2 NS-3 . . . 40 3.2.3 OMNET++ . . . 42
3.3 AVALIAÇÃO DOS USUÁRIOS . . . 45
4.1.1 DISCUSSÃO DE RESULTADOS SOBRE FUNCIONALIDADES GERAIS . 47
4.1.1.1 SUPORTE A PROTOCOLOS DE ROTEAMENTO . . . 47
4.1.1.2 SUPORTE A PADRÕES MAC . . . 48
4.1.1.3 SUPORTE MULTIMÍDIA . . . 48
4.1.1.4 DOCUMENTAÇÃO OFICIAL E COMUNIDADE DE USUÁRIOS . . . 48
4.1.1.5 FERRAMENTAS DISPONIBILIZADAS . . . 49
4.1.2 SUPORTE A SIMULAÇÕES COM TRANSMISSÃO DE VÍDEO . . . 50
4.1.3 SUPORTE VISUAL E GRÁFICO . . . 52
4.1.3.1 NS-2 . . . 52
4.1.3.2 NS-3 . . . 55
4.1.3.3 OMNET++ COM CASTALIA . . . 57
4.1.4 SUMARIZAÇÃO DE RESULTADOS . . . 58
4.2 ETAPA DE RESULTADOS NUMÉRICOS DAS SIMULAÇÕES . . . 60
4.2.1 ANÁLISE DE TESTE DE CARGA: TOPOLOGIAS COM IEEE 802.15.4 . . . 60
4.2.2 ANÁLISE DE TESTE DE CARGA: TOPOLOGIAS COM IEEE 802.11 . . . . 67
4.2.3 DISCUSSÃO DE RESULTADOS PARA TESTES DE CARGA . . . 71
4.3 ETAPA DE AVALIAÇÃO PELOS USUÁRIOS . . . 72
5 CONSIDERAÇÕES FINAIS . . . 74
REFERÊNCIAS . . . 75
Anexo A FORMULÁRIO OBJETIVO PARA AVALIAÇÃO DE SIMULADOR DE REDE . . . 78
1 INTRODUÇÃO
Redes de Sensores Multimídia Sem Fio (RSMSF) têm despertado muita atenção nos últimos anos. Essas redes podem fornecer uma grande gama de dados de monitoramento para diversas aplicações, revolucionando a forma como interagimos com o ambiente e objetos. Sistemas ubíquos e cidades inteligentes serão uma realidade num futuro próximo, apoiados em tecnologias como as RSMSF (AKYILDIZ; MELODIA; CHOWDHURY, 2006). Contudo, essas redes apresentam muitos desafios devido a sua complexidade e inter-relação de componentes, alto consumo energético, baixa largura de banda, produção de grande volume de dados são alguns do desafios mais comuns ao se implementar uma RSMSF, sendo bastante complexo o desenvolvimento de aplicações otimizadas e com resultados ótimos para todos os cenários. Dessa forma torna-se necessário um planejamento que envolva a realização de cálculos para eliminar redundâncias na captura de imagens, no processamento de algoritmos para compressão, na operação de protocolos eficientes e na minimização dos gastos energéticos.
Existem algumas formas de validar um modelo de rede. Em geral, se pode realizar uma implementação física minimalista da rede, utilizar modelos matemáticos ou empregar simulações computacionais usando softwares de propósito específico. A implementação física de um modelo de rede tem o propósito de aferir sua coerência e corretude pode trazer resultados muito próximos dos reais e o modelo pode ser validado com segurança. No entanto, implementar uma rede apenas para validá-la pode implicar na necessidade de muitos recursos, pois há gastos com material, projetistas, equipamentos, testes, entre outros, o que pode acabar inviabilizando um projeto. Modelos matemáticos de redes, por outro lado, são outro método de validação confiável, apesar de apresentar vantagens e desvantagens que devem ser cuidadosamente avaliadas. Dentre as principais desvantagens está a grande complexidade para desenvolvimento do modelo matemático da rede. Por fim, o método de simulação por meio de softwares específicos apresenta-se como uma opção viável para validação de sistemas, uma vez que não incorre em gastos com implementação física, unindo a praticidade de (virtualmente) montar uma rede com a possibilidade de realizar verificações com resultados próximos daqueles obtidos por uma implementação física da rede. Como consequência, o tempo gasto com validação diminui drasticamente, bem como o gasto de recursos humanos e de materiais.
Os simuladores de redes de sensores sem fio são ambientes adaptáveis, que permitem realizar simulações complexas de sensores escalares. No entanto, outras
areas como a de RSMSF vem crescendo rapidamente, graças ao desenvolvimento de novos dispositivos eletrônicos (sensores) que consomem menos energia, ou seja, dispositivos mais energeticamente eficientes (YICK; MUKHERJEE; GHOSAL, 2008), o que consequentemente irá exige simuladores capazes de simular redes com transmissão de vídeo.
Os simuladores de RSSF não tem acompanhado o avanço tecnológico no que diz respeito ao suporte aos diferentes tipos de redes, dificultando simulações realistas das RSMSF e outras. Embora existam diversos simuladores que possibilitam a simulação de redes de sensores sem fio, existem poucos recursos quando se trata de sensores multimídia. Essa deficiência pode ser explicada pelo fato da área ser relativamente nova, ou mesmo devido à complexidade de transmissões multimídia em redes com baixa capacidade de transmissão, cujas potencialidades são limitadas em função do baixo poder de processamento, vida útil da bateria, velocidade de transmissão e armazenamento, inerentes as redes de sensores (ALMALKAWI et al., 2010).
Embora recente, as RSMSF possuem uma lista de problemas técnicos muito bem definidos. Alta demanda por largura de banda, alto consumo energético, compressão de dados, cobertura, confiabilidade, segurança, flexibilidade, integração com redes IP e roteamento de dados são alguns dos problemas enfrentados por aqueles que desenvolvem aplicações para RSMSF (AKYILDIZ; MELODIA; CHOWDHURY, 2006). Dadas as dificuldades técnicas citadas, é necessário utilizar simuladores, testar parâmetros e avaliar resultados. Embora existam vários simuladores capazes de simular redes de sensores sem fio, poucos oferecem suporte a multimídia e, muitos destes, quando o fazem, apresentam grandes entraves técnicos, como necessidade de instalar módulos adicionais que requerem esforço extra do projetista da rede. Outro fator que consome tempo e consequentemente recursos está associado à escolha do ambiente de simulação. Muitos simuladores possuem uma curva de aprendizagem muito íngreme, além das dificuldades técnicas referentes a própria instalação do ambiente de simulação. A dificuldade de escolha se torna ainda mais evidente quando o projeto em questão necessita que o ambiente de simulação atenda à características peculiares, como, por exemplo, o uso de um protocolo recém desenvolvido. Nesse caso, o simulador deveria permitir a inclusão de novos protocolos à sua biblioteca. Entretanto, deve-se determinar se é possível adicionar um novo protocolo verificando a documentação do simulador.
de RSMSF. Este trabalho apresenta uma análise das ferramentas disponíveis, cujo objetivo foi indicar quais são os melhores simuladores para projetos que envolvem redes de sensores multimídia sem fio. A análise em questão abrangeu três dos simuladores mais utilizados e citados no meio acadêmico, a saber NS-2 (NS-2, 2011), NS-3 (NS-3, 2014) e OMNeT++ (OMNET++, 2014).
2 FUNDAMENTAÇÃO TEÓRICA
Nesta seção são descritos alguns conceitos básicos para o desenvolvimento do trabalho. Nas próximas seções, será feito um apanhado geral sobre RSSF , RSMSF e simuladores de redes sem fio a fim de formar a base teórica necessária para a construção de redes, simulações e análise de resultados oriundos das simulações.
2.1 REDE DE SENSORES SEM FIO
As Redes de Sensores Sem Fio têm se popularizado devido às inovações tecnológicas nos últimos anos e sua gama de aplicabilidade. Sensores estão consumindo cada vez menos energia, ao mesmo tempo que ocorre uma diminuição dos seus respectivos valores além de apresentarem à possibilidade de implementação em aplicações de usos variados.
Redes de Sensores Sem Fio são tipicamente formadas por um conjunto de nós sensores que trabalham juntos com o propósito de obterem dados de um ambiente (YICK; MUKHERJEE; GHOSAL, 2008). As unidades de sensoriamento presentes nos nós podem medir as condições do ambiente, tais como temperatura, umidade, pressão, luminosidade ou qualquer outra grandeza física escalar, transformando o sinal aferido em um sinal elétrico equivalente (ALMALKAWI et al., 2010). As Redes de Sensores Sem Fio são aplicadas em monitoramento remoto de ambientes e pacientes, aplicações de segurança civil, militares entre outros.
Uma RSSF é projetada obedecendo à uma hierarquia de aquisição, controle e envio de dados. Esta hierarquia proporciona economia de recursos, como consumo de energia e diminuição da quantidade de pacotes a serem enviados (redução do fluxo). Uma rede típica é formada por nós sensores, sinks (sorvedouros) e estação base. Nas próximas seções serão detalhados os componentes de uma rede de sensores sem fio típica.
2.1.1 Arquitetura de uma Rede de Sensores Sem Fio
Conforme mencionado nas seções anteriores, as Redes de Sensores Sem Fio tipicamente adotam a hierarquia de nós, sorvedouros (sinks) e estações base. Os nós são usualmente formados por dispositivos digitais tais como microcontroladores, módulos de transmissão sem fio e unidades de sensoriamento. Existem diferentes tipos de sensores, sendo comum em RSSF o uso de sensores escalares. Em contrapartida, RSMSF utilizam sensores visuais (câmeras) e de áudio em conjunto,
podendo um único nó conter diferentes tipos de unidades de sensoriamento. Isso depende exclusivamente da natureza da aplicação e dos dispositivos empregados, já que quanto mais funcionalidades, maior será o consumo energético. Os nós necessitam de uma unidade de processamento, geralmente formada por um microcontrolador, os quais possuem algoritmos embarcados para regular os intervalos de aquisição de dados e envio de informações para o sink. O envio é realizado por um módulo de transmissão wireless, o qual pode ser acoplado ao microcontrolador (AKYILDIZ; MELODIA; CHOWDHURY, 2006).
Sinks ou sorvedouros são pequenas estações que exercem "controle" sobre um conjunto de nós, e encaminham pacotes provenientes de seu conjunto de nós para a estação base (BARONTI et al., 2007). Os sinks podem comunicar-se com os nós sob seu domínio, informar operações, requisitar dados, ou simplesmente reenviar os dados coletados pelos nós. Em abordagens recentes, que variam conforme a natureza das aplicações, os sinks incorporam mais tarefas, sendo algumas delas a de agregar o conteúdo recebido dos nós e comprimir os dados em pacotes a fim de enviá-los à estação base (AKYILDIZ; MELODIA; CHOWDHURY, 2006).
A estação base é o ponto mais alto da hierarquia de uma RSSF, pois é nela que os dados são reunidos. Geralmente um computador central conecta-se aos sinks e recebe destes as informações outrora adquiridas pelos sensores. Neste terminal o usuário pode invocar operações programadas nos nós, permitindo atualizações de informações de um possível banco de dados (SOARES, 2012) ou requisitar novas medições. Uma estrutura genérica para as RSSF pode ser visualizada na Figura 1.
2.1.2 Padrões da Camada de Rede
Em geral, RSSF diferem de redes IP tradicionais. Este tipo de rede possui características que dificultam o uso de métodos e tecnologias usadas em redes de multicamadas (TCP/IP). Devido à grande limitação de recursos, largura de banda, processamento, armazenamento e principalmente vida útil da bateria que alimenta todos os recursos do nó, é comum empregar padrões que se atentem para estas características, por exemplo, protocolos que misturam as camadas (cross-layer ), o qual tem por objetivo melhorar o máximo possível as características citadas (YICK; MUKHERJEE; GHOSAL, 2008).
Desenvolver um protocolo confiável e de baixo consumo energético é importante para permitir que diferentes aplicações possam utilizá-lo (YICK; MUKHERJEE; GHOSAL, 2008). Os protocolos utilizados em RSSF têm sido
Figura 1: Estrutura de um Rede de Sensores sem Fio hierarquizada. Nós conectam-se a sinks que por sua vez conectam-se a uma estação base.
Fonte: Próprio Autor
desenvolvidos sempre com a máxima de baixo consumo energético, uma vez que em uma rede composta por centenas ou milhares de nós, um nó pode estar conectado a outros nós e a um sink. Dessa forma, muito da energia utilizada pelo nó será gasta na troca de dados entre os nós imediatamente conectados a ele.
Algumas abordagens acerca dos protocolos de comunicação em RSSF propõe o uso de camadas similares a pilha de protocolos TCP/IP, contendo as camadas de transporte, rede e enlace. Em contrapartida têm surgido propostas que encorajam o uso de camadas cruzadas, originalmente conhecida como cross-layer.
A cross-layer mistura as camadas tradicionais buscando maximizar a eficiência da rede. As funções definidas nas camadas de transporte, rede e enlace se misturam para diminuir a sobrecarga entre as camadas. Trabalhos recentes sugerem que o uso de cross-layer é o mais indicado para RSMSF (ALMALKAWI et al., 2010).
Existem outras preocupações envolvendo padrões além de protocolos durante o projeto de uma RSSF. Segurança e processos como compactação e otimização dos dados por meio de eliminação de redundâncias são fatores importantes. Aplicações de natureza médica, militar ou de segurança civil requerem confiabilidade dos dados obtidos pelos nós. O que requer métodos eficientes para proteger tais dados e prover aos usuários das aplicações os serviços idealizados com segurança (AKYILDIZ; MELODIA; CHOWDHURY, 2006).
Nos padrões das camadas de Rede, Enlace e Roteamento são definidas as funções de uma rede. Serviços e protocolos de comunicação são componentes fundamentais de um padrão. Quando se trabalha com RSSF os requerimentos destes exigidos para estes componentes são muito complexos, pois eles devem consumir o mínimo possível de energia, e garantir que as funções sejam cumpridas.
A seguir são descritos alguns padrões desenvolvidos para RSSF e algumas de suas principais características.
• IEEE 802.15.4 – Proposto para redes pequenas, este padrão especifica o suporte a camadas de enlace e rede. A camada física suporta frequências de transmissão que variam de 800 a 900 MHz para baixa largura de banda, a até 2.4 GHz para alta largura de banda. O padrão foca no baixo custo de desenvolvimento, baixa complexidade e baixo consumo de energia (YICK; MUKHERJEE; GHOSAL, 2008).
• ZigBee – Provê uma camada extra de alto nível e com alto grau de abstração para a comunicação, esta construída sobre o padrão IEEE 802.15.4. O ZigBee é um padrão wireless, de baixo custo e baixo consumo de energia tradicionalmente usado em dispositivos embarcados (BARONTI et al., 2007).
• WirelessHart – Este padrão, assim com o ZigBee, também baseia-se no IEEE 802.15.4. Ele opera na frequência de 2.4 GHz e é compatível com todos os dispositivos, ferramentas e sistemas que padrão IEEE 802.15.4, além de ser confiável, seguro e energeticamente eficiente. O WirelessHart oferece suporte a redes mesh e sincronização de mensagens. As comunicações na rede são asseguradas através de encriptação, verificação, autenticação e gerenciamento de pacotes (YICK; MUKHERJEE; GHOSAL, 2008).
• IEEE 802.11 (Wi-Fi) - Este padrão foi idealizado para redes locais, pequenos núcleos de acesso ao qual um número reduzido de dispositivos podem se conectar a altas taxas de transmissão. Existem diversas variações do 802.11, sendo 802.11b, 802.11g e 802.11n as mais comuns. Seu uso não é recomendado em redes de sensores, pois não emprega funções de economia de energia como desligamento e ligamento automático. No entanto, pode ser utilizado se configurado para baixas taxas de transmissão (IEEE, 2012).
2.1.3 Protocolos de Roteamento
Redes de sensores sem fio são conglomerados estáticos ou dinâmicos de dispositivos que trocam dados através de transmissores/receptores de alcance
finito. Quando tratamos de RSSF alocadas em posições fixas e que possuem nós intermediários (encaminhadores) é possível aplicar protocolos simplificados para rotear os dados, a fim de garantir a integridade das transmissões. No entanto, é muito comum que as redes apresentem mobilidade ou mesmo não tenha uma estrutura hierárquica definida com roteadores entre os nós e seus sorvedouros. Neste caso a estrutura fica conhecida como Ad Hoc e por consequência é necessário utilizar protocolos de roteamento capazes de descobrir a localização de vizinhos e de sorvedouros.
2.1.3.1 Protocolo AODV
O protocolo AODV (Ad hoc On-Demand Distance Vector) possibilita alterações dinâmicas da tabela de rotas, auto descobrimento de nós, roteamento multihop entre nós móveis que desejam estabelecer e manter uma conexão ad hoc (IETF, 2003). Este protocolo foi especialmente desenvolvido para atender especificidades encontradas em redes móveis, dessa forma, características especiais como verificação e atualização da tabela de rotas são indispensáveis já que um nó pode desaparecer do raio de alcance de outro nó rapidamente. Para garantir o funcionamento nestes casos, o AODV implementa um “sub-protocolo” para realizar uma verificação e atualização da tabela de rotas. Quando um nó faz parte de uma rota ativa, isto é, uma rota que há tráfego de dados, ele envia uma mensagem broadcast a cada intervalo de tempo, desta forma ele pode identificar possíveis falhas de conectividade na rede. Outro importante aspecto deste protocolo é a composição de sua tabela de rotas, que armazena apenas o próximo salto para determinado destino.
O protocolo AODV é indicado para redes com baixa taxa de transmissão, como as RSSF. Redes de Sensores Multimídia Sem Fio podem enfrentar problemas utilizando este tipo de roteamento devido à demanda por altas taxas de transmissão.
2.1.3.2 Protocolo DSR
Especificado no RFC 4728, o DSR (Dynamic Source Routing) é um protocolo reativo utilizado em redes de baixo tráfego de dados, no qual emprega-se um número reduzido de nós, pois as tabelas de roteamento utilizadas neste protocolo armazenam todo o caminho até o destino (IETF, 2007). O DSR apresenta melhor desempenho que o AODV quando empregado em redes pequenas e de baixa velocidade. Entretanto, quando o tamanho da rede cresce, o DSR perde eficiência devido o grande número de
rotas armazenadas em suas tabelas de roteamento. A forma de armazenar as rotas é a principal diferença entre o AODV e o DSR.
2.1.3.3 Protocolo DSDV
O protocolo de roteamento DSDV (Destination-Sequenced Distance-Vector) foi apresentado em PERKINS e BHAGWAT (1994). Neste artigo o autor explica o funcionamento do protocolo e suas vantagens frente aos protocolos de mesmo propósito. No DSDV todos os nós possuem um tabela de roteamento com o endereço do nó de destino, o número de saltos (hop) até o destino e um número de sequência, cujo objetivo é diferenciar rotas que tenham o mesmo destino (PERKINS; BHAGWAT, 1994). Sendo um protocolo pró-ativo o mesmo não espera ocorrência de inconsistências na rede para verificar possíveis falhas de transmissão; a atualização da tabela é feita periodicamente. A principal métrica para escolha de uma rota é a distância (menor caminho) e o número de saltos até o destino. Não existem implementações comerciais deste protocolo e especificação de RFC, embora seja possível encontrar algumas soluções acadêmicas ou implementações para simuladores (NS-2, 2011; NS-3, 2014).
2.1.4 Serviços
O conjunto de protocolos e algoritmos embarcados em um nó deve prover serviços para RSSF, tais como localização, armazenamento, segurança, compressão e agregação, cobertura e sincronização.
2.1.4.1 Localização e Cobertura
Quando se utilizam métodos de distribuição ad hoc, cria-se a necessidade de determinar a posição dos nós. Diante desta necessidade alguns modelos de localização foram criados, como o uso de GPS (Global Positioning System) e o método do mínimo máximo (SOARES, 2012), o qual empregas técnicas como o cálculo da intensidade do sinal (YICK; MUKHERJEE; GHOSAL, 2008). O problema da localização afeta o desempenho da rede, podendo comprometer a aplicação de modo que impossibilite a execução da tarefa idealizada. Portanto, é importante que o padrão utilizado possua suporte a técnicas de localização eficientes.
O uso de GPS simplifica o processo de localização dos nós adjacentes e também permite determinar a cobertura de cada nó. Entretanto, este método exige o uso de módulos GPS para determinação da posição, gerando desta forma maiores
gasto com energia e maiores custos para o projeto. Outro fator importante neste tipo de método é a precisão do módulo para determinar a localização exata de um nó. A precisão pode variar de centímetros até vários metros (GPS, 2015). As distâncias obtidas podem ser posteriormente analisadas por algoritmos de roteamento, e por meio destas análises criar rotas. No entanto, a imprecisão das medidas pode ocasionar degradação de desempenho na rede em casos de baixa precisão dos módulos de GPS, pois rotas imprecisas ou muito longas podem ser estabelecidas.
O método do mínimo máximo utiliza nós de referência para estimar a posição de um nó qualquer (PATWARI, 2005; SOARES, 2012). Para realizar a estimativa cada nó de referência calcula a intensidade do sinal recebido de outros nós de referência e do nó que se deseja estimar a localização. A partir desta estimativa os nós de referência traçam quadrados cujo lado é duas vezes a distância estimada. Os nós de referência são localizados no centro de seus respectivos quadrados. Realizado os cálculos, a localização do nó é determinada como a intersecção de todos os quadrados (SOARES, 2012).
Um outro problema oriundo do método de distribuição ad hoc, no qual os nós são distribuídos no ambiente sem localização estritamente definida, é a cobertura. Para casos como estes alguns estudos propõe o uso de GPS ou mesmo de alguns algoritmos para calcular qual a máxima cobertura com o mínimo de nós (SOARES, 2012; YICK; MUKHERJEE; GHOSAL, 2008). Este campo não está resolvido na área de RSSF e é de fundamental importância, pois o uso inadequado de sensores representa aumento de custos, bem como a sobreposição de informações.
2.1.4.2 Segurança e Confiabilidade
A natureza de algumas aplicações exige dos padrões utilizados em RSSF alta confiabilidade em todas as etapas, desde a aquisição de informações, transporte e armazenamento. Aplicações militares e médicas são exemplos de aplicações que demandam alto grau de confiabilidade. É importante garantir que durante a transmissão, nós não pertencentes à rede enviem informações maliciosas, comprometendo desta forma a execução da aplicação. Em casos como estes, os quais segurança e confiabilidade dos dados são importantes, o padrão pode utilizar métodos de criptografia e reconhecimento de posição dos nós, por exemplo, para casos em que um nó não pertencente à rede tente enviar informações, cenário que poderia ser utilizado para sabotar uma rede militar.
2.2 REDE DE SENSORES MULTIMÍDIA SEM FIO
RSMSF são redes mais complexas que RSSF tradicionais. Isso porque estas redes possuem nós equipados com sensores visuais (câmeras) e de áudio (microfones) que consomem mais energia, além de produzirem dados muito mais complexos. De fato, o tipo de sensor acoplado aos nós é a diferença fundamental entre uma RSSF comum com sensores escalares e uma RSMSF, embora outras mudanças significativas como as formas de organização das camadas (pilha de protocolos) adicionadas aos nós possam ser desenvolvidas especialmente para este tipo de rede. Mais complexas, as Redes de Sensores Multimídia Sem Fio diferem pouco das RSSF no que tange a arquitetura. No entanto, existem propostas para aperfeiçoar processos internos (cross-layer ) (COSTA; GUEDES, 2011) e novas arquiteturas criadas especialmente para RSMSF (AKYILDIZ; MELODIA; CHOWDHURY, 2006).
2.2.1 Compressão e Agregação
Vídeos são naturalmente grandes, pois possuem informações visuais e sonoras as quais são geralmente armazenadas em formatos de matrizes. Os dados visuais e de áudio demandam processamento através de algoritmos de compressão. Algumas técnicas permitem compressão com perdas ou sem perdas, sendo consequentemente mais complexas, e exigindo maior gasto energético com processamento. Dados grandes podem implicar congestionamento na rede, pois é necessário enviar muitos pacotes para cada frame, acarretando em um maior gasto com energia, largura de banda, armazenamento e processamento (YICK; MUKHERJEE; GHOSAL, 2008). Algumas práticas de compressão e agregação permitem que uma grande quantidade de dados seja reduzida por meio de algoritmos como a DCT (Discrete Cossine Transform) e DWT (Discrete Wavelet Transforms) (ALMALKAWI et al., 2010; TAVLI et al., 2012).
Existem outras técnicas para diminuir a quantidade de dados a serem transmitidos. Técnicas como intra-frame e inter-frame utilizados por muitos codecs de vídeo, exploram dados estatísticos para reduzir a taxa de transmissão. O intra-frame explora a correlação espacial em um mesmo frame, enquanto o inter-frame explora a correlação espacial e temporal entre diferentes frames, ambas com o objetivo de eliminar redundâncias (COSTA; GUEDES, 2011).
2.2.2 Cobertura de Monitoramento
Ao projetar uma RSMSF é muito importante que cada nó esteja posicionado em um local que otimize a cobertura do sensor de vídeo, ou seja, a posição do nó e seu sensor devem garantir máxima visualização do cenário evitando redundâncias, sobreposição de imagens, e consequentemente informações repetidas. Mesmo em redes onde deseja-se diversas visualizações de uma mesma cena é importante o correto posicionamento dos nós sensores (AKYILDIZ; MELODIA; CHOWDHURY, 2006).
Existem pesquisas focadas em cobertura de monitoramento e dentro desta área têm-se pesquisas voltadas para a confiabilidade da cobertura, enquanto outras preocupam-se em oferecer uma abordagem que reduza o gasto energético da rede (YICK; MUKHERJEE; GHOSAL, 2008). Algumas pesquisas que visam a redução do consumo energético empregam a técnica de "adormecer" o nó enquanto determinado evento chave não ocorrer, ou seja, o sensor de vídeo e áudio só são ativados quando algum evento chave é disparado, por exemplo, uma rede instalada em uma floresta com o objetivo de monitorar visualmente uma espécie animal, neste caso os nós sensores podem conter um sensor de movimento o qual ao ser acionado ativa o sensor de vídeo. Outras linhas de pesquisa com foco em confiabilidade da cobertura procuram formas de otimizar a área visualizada.
A fim de de reduzir o problema de cobertura alguns protocolos foram propostos, o CCP (Coverage Configuration Protocol) e o DFSSP (Differentiated Surveillance Service Protocol) (YICK; MUKHERJEE; GHOSAL, 2008). O CCP é um protocolo descentralizado que provê uma configuração para a rede, buscando aplicar os preceitos de confiabilidade e redução do consumo energético. Ele realiza ajustes na cobertura podendo aumentar o grau de cobertura ou diminui-lo, isto é, o CCP atua em tempo de execução ativando e desativando certas funções do nó. O DFSSP atua de forma semelhante ao CCP, ativando e desativando recursos em momentos estratégicos. O ponto chave deste protocolo são os estados dos nós, operação e espera. Os estados refletem o nível de cobertura da rede, pois nós no estado espera não contribuem no monitoramento enquanto que nós no estado operação contribuem para o aumento da cobertura da rede.
2.2.3 Qualidade de Experiência e Qualidade de Serviço
Qualidade de Experiência ou simplesmente QoE (Quality of Experience) em RSMSF, diz respeito a qualidade de áudio e vídeo percebidos pelo usuário.
Qualidade de Serviço ou QoS (Quality of Service) está relacionado a parâmetros técnicos concernentes aos serviços de transmissão, recepção, processamento e armazenamento empregados na rede, ou seja, os dados referentes ao QoS fornecem uma visão técnica da rede de forma que o desenvolvedor possa identificar problemas e propor soluções (YICK; MUKHERJEE; GHOSAL, 2008).
Apesar de ambos apresentarem conceitos para análise qualitativa de uma rede, o QoE apresenta-se com maior importância em RSMSF, pois ao visualizar o vídeo um usuário pode avaliar diretamente o impacto de problemas relacionados a perdas de pacotes, jitter, delay e outros parâmetros de avaliação. Dados tipicamente numéricos como delay, número de pacotes perdidos, jitter e outros são métricas de avaliação de QoS, os quais podem ou não afetarem de maneira significativa a experiência do usuário.
Quando uma aplicação possui garantias de QoS, significa que a mesma consegue manter uma quantidade mínima de qualidade nos serviços oferecidos, ou seja, independente das adversidades enfrentadas uma qualidade mínima é assegurada, isto é, jitter, delay, e perda de pacotes são controlados. Em um sistema que ofereça QoE o usuário terá uma qualidade mínima final atendida, ou seja, travamentos em vídeos ou cortes no áudio não devem ocorrer periodicamente de modo que comprometa a experiência visual do usuário.
2.3 SIMULADORES DE REDES
Simuladores são softwares específicos, cujo propósito é executar virtualmente um processo real que foi descrito em software por meio de um script ou linguagem de programação. Simuladores de redes são especializados em redes de computadores, podendo simular as diversas camadas presente em uma rede; pilhas de protocolo, meio de transmissão (cabeado ou wireless), aplicações de usuários entre outros. Dentro do universo dos simuladores de redes existem ainda os simuladores genéricos e alguns simuladores especialmente desenvolvidos para simular apenas um tipo de rede. Simuladores de redes genéricos podem ou não simular redes de telefonia, redes de sensores com ou sem fio, redes móveis, redes locais, entre outras (SUNDANI et al., 2009).
Dentre a grande variedade de simuladores de RSSF, alguns são altamente flexíveis permitindo simulações de redes escalares, multimídia ou mesmo com requisitos de mobilidades. Em contrapartida, existem simuladores mais específicos, não oferecendo a possibilidade de simular redes não escalares.
Existem ainda ambientes que permitem simular redes e/ou emular redes. Simulação diz respeito a etapa de testes e depuração realizada sob um ambiente virtual a qual não utiliza implementações dos dispositivos, apenas processos entre camadas e diferentes protocolos. A emulação envolve o uso de firmware e hardware virtual para realizar uma simulação, ou seja, a emulação é uma simulação com especificações técnicas em firmware e softwares que se aproximam dos dispositivos reais. Emular uma rede garante maior confiabilidade nos resultados, pois a emulação é mais próxima da situação real (WEINGARTNER; LEHN; WEHRLE, 2009).
2.3.1 Softwares de Simulação
Nas próximas seções serão apresentadas descrições generalistas das principais características dos simuladores que foram utilizados durante o trabalho.
2.3.1.1 NS-2
O NS-2 é um dos ambientes de simulação de redes mais populares entre os pesquisadores, isso graças a uma soma de fatores, entre eles estão, versatilidade e vasta documentação oficial. O NS-2 é um simulador de eventos discretos focado em pesquisas na área de redes de computadores e sistemas de comunicação (NS-2, 2011).
Esse simulador tem foco generalista em relação as redes que podem ser simuladas. Ele oferece suporte a uma vasta gama de protocolos e é possível adicionar outros protocolos, desenvolvidos por usuários da comunidade científica ou pelo pesquisador para um fim mais específico. Ele surgiu de uma evolução do Real Simulator Network e desde então foi constantemente aprimorado. O NS-2 é disponibilizado gratuitamente e possui código aberto, portanto é possível desenvolver novos protocolos, modificações e extensões. O ambiente de simulação do software é acessível por interface textual, assim como a exibição dos resultados de simulações, embora seja possível exibir resultados e animações com o NAM (Network AniMator) (NS-2, 2011). Os modelos desenvolvidos sob o NS-2 são escritos através de scripts para o interpretador OTcl, frontend do simulador.
O NS-2 não possui suporte nativo para simular redes de sensores multimídia sem fio. De fato, a simulação de transmissão de vídeo nesta plataforma, mesmo em redes IP usando protocolos RTP/RTCP, são insatisfatórias (ZHOU; JANG, 2008), ou seja, não oferecem o conjunto de informações necessárias para uma avaliação qualitativa do processo. Por isso alguns pesquisadores propõe modificações de
protocolos como apresentado em (BOURAS; GKAMAS; KIOUMOURTZIS, 2008), o qual implementa uma modificação no protocolo RTP/RTCP afim de obter melhores resultados nas transmissões de vídeo.
Sabe-se que RSMSF são complexas e possuem topologia e características únicas, o que impossibilita que tais redes sejam tratadas da mesma forma que redes IP convencionais. Neste caso a mudança de um protocolo não é suficiente para atender toda a demanda de novas situações as quais redes como estas estão expostas em seus ambientes de atuação (WANG et al., 2014). Nesses casos se faz necessário o desenvolvimento de extensões que permitam a simulação de diversos eventos a fim de garantir relevância e confiabilidade aos resultados. A exemplo podemos citar as extensões Miracle (MIRACLE, 2008) e o Evalvid (EVALVID, 2011), o qual utiliza complementos como o GPAC (GPAC, 2015a) e MP4Box (GPAC, 2015b), usados como suporte para adequação dos arquivos de vídeo ao formato suportado pelo Evalvid. O principal foco do Evalvid é transmitir um stream de bytes oriundos de um arquivo de vídeo. O Evalvid também permite análise de QoS .
O NS-2 possui organização simples e usa OTcL, o que permite a elaboração de scripts pequenos e de fácil leitura. A hierarquia para construção de um script é bastante objetiva, conforme podemos observar na figura 2.
Figura 2: Estrutura para construção de scripts no NS-2.
Fonte: Próprio Autor
Ao trabalhar com o NS-2 é necessário criar uma instância do simulador em cada script. Essa instância será chamada sempre que for necessário, criar nós, agentes e indicar instantes de tempo que determinado eventos deverão ocorrer. A declaração da instância do simulador é seguida pela declaração de variáveis. Estas variáveis indicam para o simulador quais padrões serão utilizados (protocolos de roteamento, MAC, modelo de antena, potência da transmissão, modelo de propagação, bateria e carga da bateria), essas variáveis devem ser adicionadas a configuração do simulador através de um comando específico. Após criar e configurar o simulador, deve-se criar os nós e organiza-los num terreno, indicando explicitamente as coordenadas que cada
um deles deve ocupar num espaço cartesiano. Por fim, adiciona-se os agentes, os quais são aplicações (UDP, TCP, FTP ou outros).
Dentre a gama de aplicações, protocolos e padrões estão os diferentes protocolos de roteamento e MAC. Alguns protocolos de roteamento suportados são AODV, AOMDV, DSDV, DSR, OLSR, TORA, Puma, MPLS e outros. Alguns protocolos MAC utilizados são IEEE 802.11, 802.3, 802.15.4, TMAC e outros.
2.3.1.2 NS-3
O NS-3 é um software voltado para simulação de redes, tendo surgido, no geral, para cumprir demandas não atendidas pelo seu antecessor (NS-2). Foi desenvolvido em C++ e possui interface de entrada para modelos em C/C++ e Python (abandonando a linguagem OTcl usada na versão anterior). Assim como o NS-2, o NS-3 é gratuito e de código aberto, possibilitando a criação de módulos e modificação do software e seus protocolos, bem como a adição de extensões.
O NS-3 possui suporte nativo para simulação de RSSF, ou seja, simula diversas características que são particulares a este tipo de rede. Para simulações de RSMSF é possível adicionar extensões como o Evalvid (EVALVID, 2011), que possui versões para NS-2 e NS-3 e proporciona ao usuário a capacidade de avaliar resultados com maior clareza.
Embora possua suporte natural ao C++ e Python, a utilização de Python ainda é limitada, pois nem todos os recursos podem ser livremente utilizados quando as topologias são desenvolvidas nesta linguagem.
Os modelos desenvolvidos no NS-3 podem descrever redes cabeadas ou sem fio e os resultados de alguns modelos podem ser visualizados através do NAM (NS-3, 2014).
Os códigos escritos em C++ ou Python para o simulador NS-3 seguem uma sequência de criação e principalmente de adição para a formação de uma topologia. A figura 3 apresenta o sequenciamento de adição das camadas no NS-3, a ordem de adição segue a orientação da seta.
A possibilidade de desenvolver os códigos em C++ pode ser bastante desafiador para aqueles que nunca tiveram contato com este tipo de linguagem, já que códigos escritos para o NS-3 fazem uso intenso de estruturas (structs), ponteiros, callbacks e conceitos de POO (Programação Orientada a Objetos). Em contrapartida, a possibilidade de elaborar os códigos em C++ concede grande poder de otimização e configurabilidade dos cenários desenvolvidos.
Figura 3: Estrutura para construção de topologias por meio de scripts no NS-3.
Fonte: Próprio Autor
Códigos NS-3 em C++ seguem o padrão da própria linguagem, imports, função main e conteúdo. A organização do código pode ser feita de acordo com a necessidade do autor, no entanto, todo código deve conter nós e a cada nós devem ser adicionadas características que o permita funcionar. Após criar um nó, deve-se adicionar uma camada física e camada de enlace, as camadas de rede e aplicação podem ser personalizadas de acordo com as necessidades do desenvolvedor e suporte oferecidas pelas camadas física e de enlace escolhidas.
O nó é a entidade básica e fundamental de uma simulação no NS-3. A ele são adicionadas características que permitem variações comportamentais dentro de uma determinada topologia. Ao criar um nó o mesmo deve receber especificações técnicas que o permita interagir com outros nós e sorvedouros na rede. O nó precisa de um dispositivo para comunicação, o qual ao ser especificado determinará o meio de propagação dos sinais gerados e recebidos pelo nó. Definido o meio de propagação do sinal as camadas de enlace e rede podem ser adicionadas, seguida pela camada de aplicação. Na camada de aplicação o usuário deve definir qual o propósito da topologia, como ela deve funcionar em conjunto e como cada nó funcionará individualmente.
O NS-3 tem aumentado rapidamente o conjunto de protocolos de roteamento e MAC disponibilizados. Dentre eles podemos encontrar AODV, DSDV, DSR, OLSR, IEEE 802.11, IEEE 802.15.4 entre outros.
2.3.1.3 OMNeT++
Com o aumento gradativo do uso e diversidade de aplicações das redes de computadores, torna-se necessário avaliar estruturas antes de implementa-las. É com o objetivo de atender as diversas demandas no que tange a variedade de redes e suas aplicações que o OMNet++ foi desenvolvido (ROSARIO et al., 2013).
Eclipse GUI (ECLIPSE, 2015) para visualização de modelos e codificação. Tem como propósito o suporte a pesquisas acadêmicas e industriais, e possibilita a simulação de diversas redes com ou sem fio através de sua gama de protocolos nativos ou adicionados por meio de módulos. O OMNet++ possui ainda grande suporte gráfico, sendo possível verificar em tempo real o tráfego de pacotes em uma rede. O programa é disponibilizado para diversas plataformas como Windows, Linux e MAC OS.
O desenvolvimento de protocolos, aplicações e algoritmos para OMNeT++ requer conhecimento de C++ e uma linguagem de scripts desenvolvida especialmente para o OMNeT++, a NED (Network Description). Com a junção do C++ e NED é possível desenvolver aplicação e protocolos que facilitam a produção de modelos derivados, ou seja, após desenvolver uma aplicação é possível facilmente adapta-lá para outros cenários, permitindo inclusive o uso de arquivos .ini. Estes arquivos são normalmente nomeados como omnetpp.ini, neles são descritos as topologias que serão simuladas.
Os scripts .ini não possuem sequenciamento de adição tão rígido quanto os scripts desenvolvidos para NS-2 e NS3, isso permite a criação de scripts dinâmicos. É possível criar diversos cenários (parâmetros variados) num mesmo script e ao executar a simulação escolher qual cenário deve ser simulado, ou seja, é possível desenvolver em um único script uma topologia que use diferentes protocolos de roteamento, por exemplo, e ao executar o script escolher qual protocolo deve ser utilizado para aquela simulação. Essa capacidade confere ao OMNeT++ versatilidade e comodidade ao usuário, o qual pode realizar comparações entre parâmetros sem a necessidade de realizar alterações para cada caso.
2.3.2 Extensões dos Simuladores de Redes
Alguns software para simulação de RSSF permitem a adição de módulos (extensões). Estas extensões conferem a estes simuladores a capacidade de simular diferentes aspectos de uma rede, ou mesmo simular tipos de redes não concebidas pelo conjunto de ferramentas nativas do software. Dentre as várias extensões com diferentes propósitos o Castalia se destaca, pois é uma extensão voltada para RSSF.
2.3.2.1 Castalia
É um software para simulação de RSSF baseado no OMNeT++ com foco em dispositivos de baixo consumo energético. Permite a simulação realista de redes wireless com grande número de parâmetros. É utilizado na avaliação de algoritmos de
rede devido sua alta precisão (CASTALIA, 2014).
O Castalia é um software altamente especializado em RSSF. Ele possui implementações de sensores como acelerômetro e de temperatura que podem ser adicionados aos nós. É possível desenvolver e adicionar módulos ao software, de modo que o mesmo possa simular outros tipos de redes como RSMSF. A transmissão multimídia sob ambiente Castalia é possível graças a adição de um módulo adicional não oficial (PHAM, 2014). Possui ainda documentação oficial que abrange um grande número de situações, concedendo ao utilizadores muitas informações importantes para o desenvolvimento de scripts ou mesmo para criação de novos protocolos e aplicações.
Usuários do Castalia podem utilizar os protocolos de roteamento ByPass, Multipath Rings disponibilizados nativamente e o protocolo AODV por meio de adição posterior. Os padrões disponibilizados para a camada MAC são Baseline BANMAC, Tunable MAC, IEEE 802.15.4, TMAC e ByPass MAC.
Como desvantagens o Castalia conta com um número reduzido de protocolos de roteamento e enlace. Por fim, o último lançamento de versão ocorreu em Março de 2011 (CASTALIA, 2014), desde então o projeto não recebeu nenhuma atualização importante.
2.3.2.2 Evalvid
O Evalvid é uma extensão originalmente desenvolvida para NS-2, e posteriormente adaptada para o NS-3. Ele oferece a possibilidade de avaliar transmissão de vídeo. Ferramentas complementares como GPAC e MP4Box mencionados na seção 2.3.1.1 auxiliam o usuário no processo de encoder/decoder do arquivo de vídeo (EVALVID, 2011), pois o software exige características bem definidas para o arquivo de vídeo a ser transmitido.
O Evalvid encaixa-se ao scripts do NS-2 e NS-3 como uma camada de aplicação. Esta camada permite que um arquivo de vídeo previamente armazenado no computador seja serializado e transmitido de um nó fonte que possui a aplicação Evalvid até um nó destino que receberá o fluxo de bytes e salvará um arquivo de rastreamento. O arquivo de vídeo deve obedecer uma série de requisitos para que a transmissão seja realizada corretamente; formato, codec e taxa de frames são alguns deles. Cumpridos os requisitos o vídeo pode ser transmitido por meio de um stream de bytes. O nó destino recebe os bytes e registra informações sobre porcentagem de perda e atrasos. O usuário pode após a simulação abrir o arquivo recebido e salvo
pelo nó destino em um editor de textos txt. O arquivo fornece ao usuário informações importantes para QoS.
3 METODOLOGIA
Nesta seção serão apresentados os procedimentos utilizados para o desenvolvimento de testes e modelos de avaliação para os softwares descritos na seção 2.3.
Foram idealizados três métodos para análise dos softwares sendo eles: revisão bibliográfica e análise de recursos, comparação de resultados numéricos e avaliação por parte dos usuários (Tabela 1). Por meio da revisão bibliográfica realizada no Capítulo 2. A avaliação dos resultados numéricos dos softwares ocorreu de forma direta, com realização de simulações para medição do uso de memória e tempo para processar uma simulação. O último recurso de avaliação foi a verificação de parâmetros não técnicos subjetivos das ferramentas, medidos através de um formulário com perguntas para usuários dos softwares testados.
Embora o objetivo deste trabalho seja analisar, comparativamente, os softwares sem focar em desenvolvimento de códigos, em determinados momentos faremos inserções de códigos utilizados e/ou desenvolvidos especialmente para as análises, mantendo o objetivo de facilitar as explicações dos métodos utilizados.
Tabela 1: Tabela com especificação dos métodos de pesquisa aplicados.
Metodologia Descrição
Revisão bibliográfica
Análise de conteúdo teórico disponibilizado por meio de manuais oficiais das ferramentas, e artigos
científicos publicados em periódicos e/ou eventos reconhecidos. Realizada esta análise, os principais recursos oferecidos pelos softwares serão devidamente sumarizados em uma tabela.
Resultados numéricos
O objetivo desta etapa é aferir a performance dos softwares para diferentes quantidades de nós,
protocolos e períodos de tempo das simulações. Desta forma se pode determinar, qual ferramenta oferece melhor desempenho utilizando diferentes parâmetros. Para realização
dos testes, a topologia e parâmetros de testes são devidamente especificadas
nas seções 3.1 e 3.2.
Avaliação pelos usuários
A avaliação da satisfação dos usuários será realizada através da
aplicação de formulários com questões objetivas sobre características importantes
das ferramentas escolhidas. Os usuários deverão quantificar sua satisfação sobre determinada funcionalidade por meio de uma escala, a qual deverá variar entre 1 à 5, sendo 1
péssimo e 5 excelente. Fonte: Próprio Autor
3.1 MODELOS DE RSMSF UTILIZADOS
Existem diversas formas de simular uma rede sem fio utilizando simuladores. Algumas publicações exibem técnicas que permitem transmitir um stream de vídeo de um nó para outro e visualizar tal fluxo após a simulação (KE, 2006). Estas técnicas, no entanto, são complexas, pois exigem adições e modificações do simulador. Em alguns casos, como no NS-2, por exemplo, a simples transmissão de vídeo exige
uma série de modificações no código-fonte do software (KE, 2006). A fim de evitar tais entraves, abstrações podem ser realizadas para simular transmissões aproximadas, por exemplo, implementando uma rede cujo nós geram pacotes com tamanho constante, além de utilizar os padrões de transmissão para vídeos.
Uma topologia hipotéticas foi desenvolvidas com o propósito de explorar as possibilidades de simulação utilizando os três softwares, artefatos primordiais deste trabalho. Situações variadas foram exploradas nas simulações, a fim de evidenciar as potencialidades de cada software e o quanto cada um deles pode se aproximar de situações reais. Em cada rede, parâmetros de avaliação de desempenho do software são aferidos, sendo eles: uso de memória RAM, tempo de simulação e sua relação com a quantidade de tempo a ser simulado, quantidade de nós, protocolo utilizado e extensões. Esses parâmetros são descritos a seguir:
• Uso de memória RAM - A avaliação deste parâmetro ocorreu de forma direta, com aferições do uso da memória por meio do comando top disponibilizado no ambiente Ubuntu/Linux. As aferições de valores foram realizadas para verificar a relação do uso de memória e o número de nós presentes na topologia, o tempo de simulação, o protocolo de roteamento utilizado e a camada MAC.
• Tempo de simulação - O tempo de simulação foi utilizado como variável para analisar a inter-relação entre diferentes parâmetros, ou seja, a fim de estabelecer a relação entre os tempo de simulação e o tempo necessário para processar a simulação, bem como verificar o impacto de um tempo maior de simulação com o uso de memória.
• Quantidade de nós - A variação deste parâmetro visa relacionar o tempo de processamento da topologia e o uso de memória do software durante a simulação.
• Protocolos - O uso de diferentes protocolos têm por objetivo verificar o impacto dos protocolos em medidas diretas da simulação, ou seja, verificar se o tempo de processamento sofre alterações, o uso de memória e outros fatores como a compatibilidade entre camadas utilizando diferentes protocolos.
• Extensões - Neste parâmetro são avaliadas as funcionalidades virtualmente melhoradas ou adicionadas ao simulador.
A topologia matricial proposta na Figura 4 é bastante generalista, podendo ser facilmente adequada a variados protocolos, a cada nova simulação. Esta rede foi idealizada para trabalhar com variações nos protocolos de roteamento, número de nós presentes na rede, protocolos de transmissão (802.11, 802.15.4) e extensões.
Neste tipo de distribuição os nós enviam os dados através de "hops" até que o pacote chegue ao sorvedouro. As simulações com topologias em formato de matriz utilizadas neste trabalho obedecem as seguintes especificações.
Figura 4: Rede de sensores sem fio com distribuição espacial uniforme. Cada nó mantém a mesma distância de seus nós vizinhos.
Fonte: Próprio Autor
• Para redes de 10 nós a rede deve ter formato 3x4 (colunas e linhas), com as posições 11 e 12 ficando vazias. Redes com 100 nós devem ter distribuição 10x10. Topologias com 1000 nós devem ter distribuição 10x100.
• O tamanho do campo deve ser de 500x500 metros para redes com 10 nós e de 1000x1000 metros para redes de 100 ou 1000 nós.
• A potência de transmissão do sinal de cada nó foi fixada em -5 dBm.
• A antena deve ser Omni-directional (as ondas se propagam em todas as direções).
• A banda de transmissão do canal deve ser de 256 Kilobits por segundo (restrição imposta pelo protocolo MAC IEEE 802.15.4).
• O tamanho dos pacotes de dados deve ser de 100 bytes.
• A taxa de transmissão dos nós fontes é de 10 pacotes por segundo.
A escolha do parâmetros acima se devem a necessidade de normalizar requisitos para que sejam realizáveis na topologia matricial (Figura 4), para por todos os protocolos que foram testados. Todos os protocolos utilizaram a mesma organização com diferenças sutis de arquitetura (mudança de protocolo). Portanto,
parâmetros como distância, potência e tipo de antena são justificados pelo fato de serem compatíveis com todos os protocolos utilizados, sendo o valor de potência arbitrado e a distância ajustada de forma que os nós possam localizar aqueles dentro do raio de cobertura. A banda de transmissão foi fixada em 256 Kilobits por segundo, por limitações do padrão IEEE 802.15.4 enquanto que valores de tamanho de pacotes e taxa de transmissão foram assim definidas por apresentarem a abstração da transmissão de um stream de vídeo de baixa resolução, tipicamente utilizados em redes com muitos nós.
Modelos ad hoc são muito usuais, porém apresentam problemas decorrentes de seu espalhamento espacial. Estes problemas são facilmente resolvidos com a utilização de redes hierarquizadas (Figura 1). Este tipo de topologia emprega nós sorvedouros entre o nó fonte e a base. O modelo apresentado na Figura 5 ilustra uma topologia que pode ser facilmente implementada para cada um dos simuladores utilizados, se tomarmos como base os códigos para redes matriciais.
Figura 5: Rede de sensores sem fio com hierarquia pré-definida. Os nós comunicam-se com os sinks por meio de transmissão wireless.
Fonte: Próprio Autor
3.2 MODELAGEM DE RSMSF
A fim de organizar os testes e relaciona-los corretamente com os resultados, classificamos cada teste em versões. A Tabela 2 apresenta as características utilizadas em cada topologia e suas variações.
Tabela 2: Casos de testes utilizados com a rede ad hoc organizada em forma de matriz. Topologia MAC Protocolo de Roteamento Número de Nós Duração da simulação (minutos) Matriz 1 802.11 AODV 10, 100, 1000 10, 60, 600 Matriz 2 802.11 DSDV 10, 100, 1000 10, 60, 600 Matriz 3 802.11 DSR 10, 100, 1000 10, 60, 600 Matriz 4 802.15.4 AODV 10, 100, 1000 10, 60, 600 Matriz 5 802.15.4 DSDV 10, 100, 1000 10, 60, 600 Matriz 6 802.15.4 DSR 10, 100, 1000 10, 60, 600
Fonte: Próprio Autor
Para cada teste realizado, foi verificado o uso de memória RAM, possibilidade de visualização gráfica da simulação para a topologia proposta, facilidade de leitura dos resultados, tempo gasto para simular a rede e criação de gráficos que relacionam grandezas, por exemplo, uso de memória e número de nós. Além das informações técnicas aferidas, outros métodos de análise indireta foram utilizados, por exemplo, facilidade de uso, instalação, alterações e adição de extensões.
Para modelar os testes da tabela 2 foram necessárias implementações de códigos para cada um dos simuladores. Cada simulador possui especificações únicas que exigem por sua vez abordagens diferentes para o desenvolvimento de cada algoritmo, embora o objetivo e especificações de parâmetros de cada teste sejam idênticas.
Para realização de simulações com extensões e avaliação de ferramentas extras como construção de gráficos, foram utilizadas as topologias disponibilizadas nos códigos de exemplos de cada software.
3.2.1 NS-2
O NS-2 propõe uma estrutura bem definida e ordenada para o desenvolvimento de scripts para simulação (para sequência de inclusão de código no NS-2 ver Figura 2). A fim de tornar os códigos mais facilmente legíveis e mutáveis é indicado declarar variáveis de configuração no inicio do código, pois caso seja necessário realizar alguma mudança na configuração da topologia estas serão facilmente localizadas e acessadas. A versão utilizada foi a 2.35 disponibilizada pelo site oficial (NS-2, 2011).
A Figura 6 engloba a primeira camada de descrição estrutural contida na Figura 2. Nela é possível localizar a linha de código número 24, na qual a instância do simulador é criada. Criada a instância do simular é possível realizar chamadas a funções especificas do simulador, por exemplo, chamar métodos em tempos específicos da simulação, criar e destruir nós, criar conexões entre nós entre outros.
Com a criação da instância de simulação o usuário está apto a adicionar arquivos de rastreamento, os quais permitem registrar ocorrências de eventos durantes as simulações e salvar tais registros em um arquivo de texto após o termino da simulação.
Figura 6: Trecho de código do NS-2. Na figura observa-se a criação de variáveis e a criação de uma instância de simulação.
Fonte: Próprio Autor
Na Figura 7 verifica-se a criação da topologia. A criação de nós, definição do tamanho do campo da simulação e configuração dos parâmetros internos do nó são realizados no código apresentado na Figura 7. É possível adicionar parâmetros de mobilidade, adicionando um ponto de início e fim, além de definir a velocidade de locomoção do nó. Com isso é possível avaliar diversos fatores que influenciam na perda de pacotes na topologia, entre eles a variação da distância.
Figura 7: Criação e configuração da topologia no NS-2.
Fonte: Próprio Autor
Por fim temos a criação da camada de aplicação que no NS-2 é chamada de agentes (Figura 8). Os agentes são responsáveis por realizar as tarefas de alto nível e são eles que caracterizam unicamente uma topologia, ou seja, são os agentes e a forma como estes são conectados a outros nos que concedem uma configuração personalizada da rede, tornando-a capaz de realizar uma tarefa especifica.
Figura 8: Criação dos agentes de simulação no NS-2.
Fonte: Próprio Autor
3.2.2 NS-3
Códigos escritos para o NS-3 versão 3.22 são desenvolvidos em C++ ou Python. Códigos em C++ diferentemente do NS-2 e OMNeT++ precisam ser compilados a cada modificação em seu conteúdo. A compilação agrega alguns prejuízos ao desenvolvedor como, por exemplo, o atraso ao compilar códigos muito grandes.
A Figura 9 apresenta a construção de uma topologia no NS-3 utilizando a linguagem C++. A topologia desenvolvida na figura é a matriz 4 contida na tabela 2. Observamos na figura a criação dos nós, canal de comunicação, dispositivos de comunicação, camada de enlace e rede. A uso do padrão IEEE 802.15.4 no NS-3 obriga a adição do protocolo IPv6, adicionalmente ele não possui suporte ao uso de baterias o que não nos permitiu, durante a realização deste trabalho, realizar medições do consumo de energia.
Figura 9: Criação de nós, canal de propagação, camadas de enlace e rede no NS-3.
Fonte: Próprio Autor
A Figura 10 apresenta a criação e configuração da camada de aplicação no NS-3. Talvez um dos pontos mais fortes do NS-3 seja a grande capacidade de personalização da camada de aplicação. Na camada de aplicação é possível utilizar Callbacks, personalizando códigos das aplicações utilizadas, mas sem modificar o código fonte da aplicação. Por exemplo, é possível adicionar um método a camada de aplicação UDP para realizar alguma ação sempre que pacotes forem recebidos, sem a necessidade de alterar o código fonte da aplicação UDP do NS-3.
Figura 10: Criação e configuração da camada de aplicação no NS-3.
Fonte: Próprio Autor
3.2.3 OMNeT++
Para a execução dos casos de teste descritos pelas topologias das Figuras 4 e 5 foi utilizado o OMNeT++ versão 4.6 com a extensão voltada para RSSF, o Castalia versão 3.2. Portanto, sempre que citarmos o uso do Castalia salientamos que o mesmo usa o núcleo do OMNeT++ e as avaliações serão feitas sobre o conjunto OMNeT++/Castalia.
O Castalia é um simulador exclusivamente desenvolvido para RSSF, construído sob o OMNeT++, graças a isso herda características interessantes para produção de scripts como, por exemplo, capacidade de executar diferentes cenários com um único script. Scripts no Castalia podem conter diferentes variações de um mesmo cenário. Estas variações são úteis para gerar resultados com modificações na topologia, mas sem a necessidade de executar o código várias vezes.
A maior parte dos scripts de exemplo disponibilizados no Castalia seguem um padrão parecido com o NS-2, portanto seguiremos estes padrões para o desenvolvimento de scripts das redes matriciais propostas anteriormente (seção 3.2). O usuário deve adicionar os nós, tamanho do campo, definições de cada nó e adicionar uma aplicação para cada nó. Entretanto, o Castalia apresenta alguns desafios para elaboração de código voltados para redes ad hoc, pois o número de protocolos de roteamento disponíveis é bastante reduzido, e caso não seja disponibilizado nativamente, torna-se necessário desenvolver o protocolo ou procurar versões em comunidades e fóruns na internet. Este caso acontece quando tentamos simular as redes proposta na tabela 2, pois o Castalia não oferece suporte nativo ao protocolo
IEEE 802.11 e protocolos de roteamento AODV, DSDV e DSR.
O protocolo AODV pode ser encontrado em (FERNANDES, 2012). Implementações dos protocolos DSR e DSDV não são foram encontrados para o Castalia até o fechamento deste trabalho. Após o processo de instalação do protocolo ao Castalia, foi dado início ao desenvolvimento do script.
Figura 11: Declaração de variáveis, organização da topologia e configurações básicas de uma transmissão sem fio no Castalia.
Fonte: Próprio Autor
Na Figura 11 podemos observar, da linha 11 a 15, a configuração da topologia matricial de 1000 nós. As linhas seguintes apresentam a configuração de bateria e transmissão sem fio.
Figura 12: Configuração da camada de aplicação, MAC e protocolo de roteamento.
Fonte: Próprio Autor
A Figura 12 apresenta a adição das camadas de aplicação, MAC e roteamento, respectivamente. Neste ponto é importante salientar que a configuração escolhida exigiu mudanças no código fonte da aplicação ThroughputTest. Esta aplicação gera um fluxo contínuo de bytes e originalmente não é possível desativar tal fluxo. Ao mesmo tempo que gera o fluxo ela encaminha os pacotes gerados e recebidos de outros nós para o sink da rede. Este modelo de aplicação funcionaria bem para topologias em que todos os nós estão transmitindo informações, mas o caso de teste usado até o momento (conforme mencionado na seção 3.2) exige que apenas um nó transmita dados na rede. Impedido de prosseguir, foi então realizada uma pequena alteração no código-fonte da classe ThroughputTest.
O código-fonte da classe ThroughputTest foi estudado e o método responsável pela geração de pacotes recebeu a adição de uma variável booleana. Caso a variável seja falsa o nó não gera pacotes, caso contrário o trafego é gerado normalmente. Na linha 36 presente da Figura 12 é possível observar a desativação da geração de pacotes de todos os nós, com exceção do nó 0 (zero).
Na Figura 13 é possível observar a variável generate a qual foi adicionada para possibilitar que certos nós não produzam dados.
