Ambiente híbrido para avaliação de redes sem-fio

Texto

(1)UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE. U NIVERSIDADE F EDERAL DO R IO G RANDE DO N ORTE C ENTRO DE T ECNOLOGIA P ROGRAMA DE P ÓS -G RADUAÇÃO EM E NGENHARIA E LÉTRICA E DE C OMPUTAÇÃO. Ambiente Híbrido para Avaliação de Redes Sem-fio. Gilles Velleneuve Trindade Silvano. Orientador: Prof. Dr. Ivanovich Medeiros Dantas da Silva. Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Engenharia Elétrica e de Computação da UFRN (área de concentração: Engenharia de Computação) como parte dos requisitos para obtenção do título de Mestre em Ciências.. Número de ordem PPgEEC: M502 Natal, RN, setembro de 2017.

(2) Universidade Federal do Rio Grande do Norte – UFRN Sistema de Bibliotecas – SISBI Catalogação da Publicação na Fonte - Biblioteca Central Zila Mamede Silvano, Gilles Velleneuve Trindade. Ambiente híbrido para avaliação de redes sem-fio / Gilles Velleneuve Trindade Silvano. - 2017. 28 f. : il. Dissertação (mestrado) - Universidade Federal do Rio Grande do Norte, Centro de Tecnologia, Programa de Pós-Graduação em Engenharia Elétrica e de Computação. Natal, RN, 2017. Orientador: Prof. Dr. Ivanovich Medeiros Dantas da Silva 1. Redes sem fio – Dissertação. 2. Análise de desempenho - Dissertação. 3. Internet das coisas - Dissertação. 4. Simuladores de rede - Dissertação. 5. Virtualização - Dissertação. I. Silva, Ivanovich Medeiros Dantas da. II. Título. RN/UF/BCZM. CDU 004.73.

(3)

(4)

(5) Agradecimentos. Ao meu orientador Ivan e ao professor Madruga, sou muito grato pela orientação e apoio no desenvolvimento do trabalho. Aos demais colegas de pós-graduação, pelas críticas e sugestões. À minha família pelo apoio durante esta jornada..

(6)

(7) Resumo. Redes sem-fio têm evoluído consideravelmente nos últimos anos e consequentemente tem sido aplicadas nos mais diversos cenários, desde redes locais sem-fios até redes de sensores sem-fios para Internet das Coisas (Internet of Things - IoT). Cada nova aplicação apresenta suas próprias características, especificidades e consequentemente novos desafios que devem ser vencidos para que ela se torne viável e seja enviada para produção e embarcada em dispositivos reais. Porém, os simuladores de redes em geral não fornecem algumas importantes funcionalidades para as simulações e avaliações de aplicações de redes sem-fio. Por exemplo, os simuladores exigem implementação da aplicação direcionada para o ambiente do simulador exigindo o dobro de esforço dos desenvolvedores e problemas de integração entre as tecnologias utilizadas durante os testes e as utilizadas para embarcar a aplicação em dispositivos reais. Além disso, os simuladores devem dar suporte a em cenários mais complexos de redes sem-fio como ambientes com alta mobilidade ou alta densidade de nós. Por fim, o comportamento simulado por softwares e não na análise de dispositivos reais utilizando código final, compilado para os dispositivos reais finais, não fornece a melhor visualização do comportamento da aplicação simulada. Para preencher essas lacunas desenvolvemos o LVWNet: um ambiente e simulação baseado em virtualização Linux para a avaliação de aplicações de redes sem-fio que oferece suporte a simulação de código real e ambiente híbrido de integração entre nós virtuais e dispositivos reais, além de flexibilidade e baixo consumo de recursos. Nesse trabalho são apresentados os detalhes de implementação do LVWNEt e suas funcionalidades básicas através da simulação de uma rede sem-fio IEEE 802.11s em um ambiente híbrido com suporte a mobilidade, no qual foram desenvolvidos testes para avaliar a autenticidade dos dados de simulação obtidos durante os testes que comprovaram sua eficiência como ambiente de avaliação de redes sem-fios. Palavras-chave: Análise de Desempenho, Internet das Coisas, Simuladores de Rede, Virtualização..

(8)

(9) Abstract. Wireless networks have evolved considerably in recent years and have consequently been applied in a wide range of scenarios, from wireless local area networks to Internetof-Things (IoT) wireless sensor networks. Each new application presents its own characteristics, specificities and consequently new challenges that must be overcome in order for it to become viable and be sent to production and shipped to real devices. However, network simulators generally do not provide some important functionalities for the simulations and evaluations of wireless applications. For example, simulators require implementation of the application targeted to the simulator environment requiring twice the effort of the developers and problems of integration between the technologies used during the tests and those used to ship the application to real devices. In addition, simulators must support in more complex scenarios of wireless networks such as environments with high mobility or high node density. Finally, software-simulated behavior rather than real device analysis using final code, compiled for the final real devices, does not provide the best visualization of simulated application behavior. To fill these gaps we have developed LVWNet: a Linux-based virtualization-based simulation and environment for evaluating wireless network applications that supports real-world simulation and hybrid integration between virtual nodes and real devices, as well as flexibility and low resource consumption. This paper presents the implementation details of the LVWNEt and its basic functionalities through the simulation of an IEEE 802.11s wireless network in a hybrid environment with mobility support, in which tests were developed to evaluate the authenticity of the simulation data obtained during the tests that have proven their efficiency as evaluation environment of wireless networks. Keywords: Internet o Things, Network Simulators, Performance Analysis, Virtualization..

(10)

(11) Sumário. Sumário. i. Lista de Figuras. iii. Lista de Tabelas. v. 1. 1 2 2. Introdução 1.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . .. Lista de Símbolos e Abreviaturas. 1. 2. . . . .. 3 4 5 8 8. 3. 4. 5. Visão Geral e Motivação 2.1 NS-3 . . . . . . . . . 2.2 Wmediumd . . . . . 2.3 FIT IoT-Lab . . . . . 2.4 Discussão . . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. Proposta: Linux Virtual Wireless Network 3.1 Arquitetura . . . . . . . . . . . . . . . 3.2 O Protocolo LVWNet . . . . . . . . . . 3.3 Estado Atual e Desenvolvimento Futuro 3.3.1 Exportação de Dados . . . . . . 3.3.2 Modelo de Erros . . . . . . . . 3.3.3 Modelo de Consumo de Energia 3.3.4 Suporte ao IEEE 802.15.4 . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 11 11 13 14 15 16 16 16. Preparação do Ambiente 4.1 Preparando o Ambiente . . . . . . . 4.1.1 Ambiente Totalmente Virtual 4.1.2 Ambiente Híbrido . . . . . 4.2 Simulação de Mobilidade . . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 17 17 19 20 20. Experimentos e Resultados 5.1 Comunicação em um Ambiente Híbrido . . . . . . . . . . . . . . . . . . 5.2 Mobilidade e Registro Dinâmico de Nós . . . . . . . . . . . . . . . . . . 5.3 Consumo de Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 21 21 22 22. i. . . . .. . . . ..

(12) 6. Conclusão. Referências bibliográficas. 25 27.

(13) Lista de Figuras. 2.1 2.2 2.3 2.4 2.5. Módulos NS-3 em camadas. . . . . . . . . . . . . . . . . . . . . . . . . Namespace de rede no Linux. . . . . . . . . . . . . . . . . . . . . . . . . Envio de dados no Mac80211_hwsim com diferentes namespaces. . . . . Arquitetura do Netlink. Fonte: adaptado de [15] . . . . . . . . . . . . . . c Inria: à esquerda WifiBot, à direita TurtleBot e no teto hardwares de IoT.. 3.1 3.2 3.3 3.4 3.5 3.6. Arquitetura LVWNet. . . . . . . . . . . . . . . . . . . . Arquitetura híbrida do LVWNet. . . . . . . . . . . . . . Interceptação das mensagens pelos módulos do LVWNet. Mensagem de registro de nós do LVWNet. . . . . . . . . Registro dinâmico no LVWNet. . . . . . . . . . . . . . Mensagens de informação do LVWNet. . . . . . . . . .. . . . . . .. . . . . . .. . . . . . .. 12 12 14 14 15 15. 5.1 5.2 5.3 5.4 5.5. Terminal no dispositivo 4. . . . . . . . . . . . . . . . . . . . . . . . . Movimento do dispositivo 3 e as áreas de alcance dos rádios. . . . . . Consumo de processamento. . . . . . . . . . . . . . . . . . . . . . . Consumo de memória RAM. . . . . . . . . . . . . . . . . . . . . . . Consumo de largura de banda dos nós (à esquerda RX e à direita TX).. . . . . .. . . . . .. 22 23 24 24 24. iii. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 5 6 7 7 9.

(14)

(15) Lista de Tabelas. 4.1 4.2. Diretórios importantes do projeto LVWNet. . . . . . . . . . . . . . . . . Diretório /lvwnet/scripts . . . . . . . . . . . . . . . . . . . . . . . . . .. 18 19. 5.1 5.2. Dispositivos criados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Representação de 6 marcos durante o movimento do dispositivo 3. Células verdes demarcam enlaces ponto-a-ponto estabelecidos. . . . . . . . .. 21. v. 22.

(16)

(17) Capítulo 1 Introdução. Redes sem fio tem evoluído consideravelmente nos anos recentes e tem sido aplicadas a vários diferentes cenários, e cada nova aplicação possui suas próprias características e requisitos a serem validados antes que as aplicações se mostrem viáveis para serem embarcadas e chegarem ao usuário final [3] [11] [10]. O processo de validação se torna mais complexo quando se trata de aplicações para a Internet das Coisas (IoT) por causa de requisitos apresentados por redes com grande densidade de nós ou com alta mobilidade [22]. Para satisfazer esses requisitos, pesquisadores e desenvolvedores validam suas aplicações através do uso de testes de bancada ou software simuladores. Os testes de bancada oferecem uma infraestrutura física similar ao cenário alvo para a execução de protótipos das aplicações e coleta de informações de performance utilizados para avaliar o comportamento da aplicação antes que seja embarcados em dispositivos reais, assegurando que a aplicação funcionará como esperado e preencherá os requisitos estabelecidos, expondo falhas inesperadas a tempo de desenvolver correções. Já os simuladores são softwares que simulam o comportamento de redes sem fio e fornecem mecanismos para a execução de testes e validação e análise de desempenho de novas aplicações. Ambas abordagens possuem suas vantagens e desvantagens como métodos de validação de aplicações para redes sem-fio. Os testes de bancada fornecem as vantagens de utilizarem equipamentos e ambientes reais, o que normalmente leva à resultados mais fies e consistentes, principalmente pois a aplicação desenvolvida e validada será a mesma utilizada para produção. Porém, alguns cenários são mais difíceis de replicar em testes de bacada, como por exemplo os cenários de alta mobilidade e alta densidade de nós. O primeiro pois os dispositivos de rede não possuem mecanismos autônomos para se movimentar e no segundo caso pois a quantidade de dispositivos a serem adquiridos para que o cenário de simulação pode encarecer o projeto como um todo. Além disso, a replicação de condições ambientais em um ambiente de testes (i.e. umidade), importantes na comunicação em redes sem fio [17], não são facilmente gerenciáveis. Já os ambientes de simulação por software fornecem flexibilidade na criação do ambiente, obtenção dos dados e são somente limitados pelos recursos computacionais, o que facilita a criação de ambientes onde há uma grande densidade de nós [12]. As simulações de ambientes com nós móveis também são facilitadas através da criação de scripts que automatizem a movimentação dos nós. Porém, como a simulação é feita por software,.

(18) 2. CAPÍTULO 1. INTRODUÇÃO. a aplicação desenvolvida para testes não é a mesma utilizada na produção, degradando o a qualidade das validações e duplicando o esforço de desenvolvimento. Porém, ambas abordagem não fornecem sozinhas uma solução final para a validação de aplicações de redes sem-fio. Isso se torna mais evidente quando as aplicações a serem validadas possuem restrições específicas, principalmente para aplicações de IoT. Portanto, a solução ideal para testes e análises de aplicações mais complexas deve oferecer, pelo menos: uma arquitetura híbrida, possibilitando a comunicação entre dispositivos reais e virtuais em uma infraestrutura virtualizada; mesmo código utilizado durante os testes em ambientes de simulação ou híbridos devem ser capazes de serem embarcados em dispositivos reais; flexibilidade para customização que possibilite a criação de modelos melhores e a adição de novos modelos para situações específicas e para suporte à novas tecnologias; e mecanismo de exportação de dados para validação detalhada das simulações. Então, para satisfazer esses requerimentos, foi proposto um ambiente de Simulação de Redes, chamado Linux Virtual Wireless Network (LVWNet).. 1.1. Objetivo. Perante as lacunas existentes na validação de novas aplicações para redes sem-fios, esse trabalho tem como objetivo mostrar o projeto de um Ambiente Híbrido para Avaliação de Redes sem-fio, LVWNet, e descrevendo o processo de simulações de aplicações em ambientes híbridos utilizando código nativo para testes e para produção. Os testes validarão a eficácia e eficiência do LVWNet para aplicações de redes sem-fio com alta mobilidade e alta densidade de nós.. 1.2. Organização do Trabalho. O restante desse trabalho está organizado da seguinte maneira: no capítulo 2, levantamento das alternativas para simulação de redes sem-fios onde, ao final do capítulo, é descrito como as lacunas identificadas (motivação para a criação do LVWNet) são preenchidas pelo LVWNet. O capítulo 3 detalha a proposta desse trabalho, o Ambiente de Híbrido para Avaliação de Redes Sem-fio, LVWNet, bem como o protocolo criado utilizado para a comunicação entre os elementos de sua arquitetura. O capítulo 4 apresenta a metodologia de testes desenvolvida para a validação das características que o LVWNet se propõe a fornecer. No capítulo 6, são debatidos os resultados dos testes, o estado atual do desenvolvimento e trabalho futuro previsto para a evolução do projeto. E, por fim, no capítulo 7, conclusões e considerações finais com relação ao proposto por esse trabalho..

(19) Capítulo 2 Visão Geral e Motivação. Enquanto as redes sem-fios avançam, novas tecnologias são propostas, testadas e então, após o processo de validação, lançadas para serem embarcadas em dispositivos reais como parte dos seus sistemas embarcados. A fase de validação é um processo importante que garante que a tecnologia proposta se comportará como esperado e estará segura para entrar em produção. Em outras palavras, se os resultados das simulações preencherem os requisitos, a aplicação usada para testes será então usada como base para desenvolver uma aplicação diferente que irá rodar na arquitetura alvo. Essa nova aplicação agora pode ser testada em dispositivos reais ou, dependendo da acurácia dos modelos utilizados e da confiabilidade dos testes, enviados diretamente para produção. Por outro lado, softwares simuladores de redes tem seus pontos negativos, por exemplo, para aplicações críticas os modelos de simulação podem não ser satisfatórios para garantir que as simulações assegurem o seu correto funcionamento. Adicionalmente, projetar modelos para aquisição de informações de sensores IoT (e.g.: consumo de energia, memória, e poder de processamento) requerem análise analítica baseada em conhecimento matemático sólido. Embora as implementações reais promovam resultados realísticos, a implementação física demanda tempo e recursos financeiros já que irão necessitar de aquisição de peças de hardware e esforço humano [13]. Alternativamente, as simulações são mais baratas e fornecem bons resultados com melhor custo-benefício para validar a performance e a segurança das tecnologias propostas. Simulações são comumente utilizadas para testar a capacidade planejada de redes e para testar se a aplicação cumpre os requerimentos básicos [4]. Por outro lado, diferentes simuladores apresentam diferentes características, que devem ser validados de modo a definir como escolher o melhor simulador para determinados requisitos. Existem basicamente duas características importantes oferecidas pelos simuladores de redes [5]: • Reprodutibilidade – a aplicação deve ser facilmente traduzida de tecnologias de testes para tecnologias de produção, as que são embarcadas em dispositivos reais. Implementações utilizando linguagens de alto nível diminuem o custo pelo tempo gasto para desenvolver as aplicações de testes com o contraponto de que é necessário implementar a última versão de testes de sucesso em outra linguagem para a versão final do produto. Esta é uma desvantagem pois diferentes tecnologias de programação podem ser incompatíveis e os programadores devem possuir habilidades com todas as tecnologias envolvidas ou possuir uma equipe grande suficiente.

(20) 4. CAPÍTULO 2. VISÃO GERAL E MOTIVAÇÃO com especialistas em todas as áreas; • Fácil configuração, implementação e instrumentação – Simuladores de rede devem agir como uma camada invisível que coleta dados e promovem controles para manipular como os nós se conectam. Assim como devem também fornecer ferramentas para modelagem e mudança de parâmetros de simulação e mecanismos para exportação de dados para observação e análise.. Alguns dos ambientes de simulação mais importantes para novas aplicações de IoT serão abordados nos próximos tópicos: Network Simulator 3 (NS-3), Wmediumd, e a FIT IoT-Lab, este último sendo um ambiente para testes de bancada para pesquisa e será discutido como uma alternativa além dos ambientes de simulação. Por fim, as desvantagens de todos os simuladores apresentados serão discutidas como motivação para a criação de um novo ambiente de simulação para validação e prototipagem de aplicações IoT, o Linux Virtual Wireless Network (LVWNet).. 2.1. NS-3. O Network Simulator versão 3 (NS-3) é um simulador de rede voltado para a pesquisa acadênica e para o desenvolvimento de tecnologias para redes em geral. O simulador é extensível devido ao seu modelo de código aberto e por possuir contribuidores ao redor do mundo que mantêm a vasta documentação online atualizada. O simulador ainda suporta uma grande variedade de protocolos e permite simulações para tecnologias em redes cabeadas e sem-fio. A sua versão anterior, NS-2, vem sendo utilizada tanto na pesquisa quanto na educação. As simulações são programadas em C++, a mesma linguagem utilizada para gerenciar o comportamento dos nós, e scripts OTcl para controlar outros aspectos como por exemplo a topologia da rede em tempo real. A descontinuidade quando transitando da simulação a experimentação, a falta de suporte para criação de simulações complexas, documentação desatualizada e a necessidade de análise complexa de arquivos de dados para a extração de informações sobre as simulações [5] foram as principais motivações para o desenvolvimento do NS-3. Contudo, o NS-2 ainda é utilizado em projetos legados. Durante o projeto do NS-3, foram apresentadas as seguintes diferenças entre ele e o NS-2: substituição da OTcl pelo Python como linguagem de programação oficial para scripts devido a Python ser uma linguagem de maior abrangência, de múltiplos propósitos e de alta manutenibilidade; Network Animator (NAM) como mecanismo para visualização dos dados e análise da simulação; e geração de arquivos Package Capture (.pcap), compatíveis com a maioria dos analisadores de tráfego de rede (e.g.: Wireshark). NS-3 é um Simulador de Redes de eventos discretos. Portanto, as aplicações reagem gerando eventos que são armazenados em uma fila por tempo limitado, e então são processados pelo laço principal do simulador. Então, as simulações agem como uma máquina de estados, movendo do último estado para o próximo e assim por diante. Além disso, NS-3 é um conjunto modular de bibliotecas que podem estar estaticamente ligadas a um programa principal em C++ ou, alternativamente, importados por um código em Python. Os módulos estão organizados hierarquicamente baseados nas dependências de cada.

(21) 2.2. WMEDIUMD. 5. módulo, como demonstrado na Figura 2.1, que são carregados independentemente nos códigos fonte. O mesmo processo acontece para os códigos em Python. O módulo Common implementa classes importantes como Packets, Packets Tags, Packet Headers, e as classes Pcap/ascii para escrita em arquivos. O módulo Simulator implementa as classes que controlam o comportamento da simulação como Events, Scheduler e classes relacionadas a aritmética de tempo. Ambos os módulos são implementados sobre um módulo principal chamado Core, que implementa detalhes de baixo nível como variáveis aleatórias, atributos, callbacks e rastreamento. Os módulos restantes adicionam características extras, como: modelos de mobilidade estática ou modelos de mobilidade baseados em random walk, filas, diferentes tipos de endereços (e.g.: IPv4, MAC), e funções da pilha TCP/IP do Linux.. Figura 2.1: Módulos NS-3 em camadas.. 2.2. Wmediumd. A arquiteutra Linux divide o sistema de memória em duas áreas, o espaço do núcleo e o espaço do usuário. O espaço do núcleo é onde o núcleo é executado, bem como todos os processos dentro desse espaço são executados em modo núcleo. No espaço do usuário, as aplicações rodam em modo CPU e tem uma porção limitada de memória [14]. Em outras palavras, o núcleo, rodando no espaço do núcleo, gerencia as aplicações do espaço do usuário e, cada vez que uma aplicação do espaço do usuário precisa de uma operação de CPU, ela deve requisitar ao núcleo invocando funções especiais chamadas chamadas de sistema. Por outro lado, as chamadas de sistema tomam tempo para executar e, em sistemas críticos, a concorrência com outras aplicações de espaço de usuário forçam os processos a aguardar algum tempo para ser escalonadas e então processadas pela CPU. Então, algumas aplicações implementam seus códigos dentro do núcleo implementando seus códigos para rodar como parte integral do núcleo ou como Loadable núcleo Modules (LKM). Esses módulos podem ser carregados por demanda e seu código é agregado ao código do núcleo no espaço do núcleo. Como uma aplicação de espaço de núcleo, LKMs não necesitam de chamadas de sistema para ter acesso à CPU e possuem acesso direto memória do núcleo. Isso torna o desenvovimento de LKMs mais cuidadoso visto que problemas apresentados por aplicações de espaço de núcleo levam à inconsistência do seu funcionamento e interrupção abrupta de suas funcionalidades. Por outro lado, o núcleo Linux implementa uma funcionalidade que isola certos recursos do sistema, chamado de Namespaces. Após.

(22) 6. CAPÍTULO 2. VISÃO GERAL E MOTIVAÇÃO. o núcleo 2.6.24, existiram seis Namespaces diferentes: user, network, UTS, mount, IPC, e PID. O Namespace relevante para esse trabalho é o Network Namespace que isola os recursos de rede (i.e.: pilha de rede, regras de roteamento, sockets), sendo possível também criar várias interfaces virtuais de redes independentes [16], como ilustrado pela Figura 2.2, onde os namespaces de rede Linux e seus próprios recursos e regras de roteamento podem ser identificados independentemente, onde também está ilustrado uma instância do processo Apache2 ligado ao socket 80/tcp para cada Namespace.. Namespace de rede #1. Namespace de rede #2. Processos:. Processos:. Endereços IP:. Endereços IP:. Roteamento:. Roteamento:. Namespace de rede #3. Namespace de rede #4. Processos:. Processos:. Endereços IP:. Endereços IP:. Roteamento:. Roteamento:. Figura 2.2: Namespace de rede no Linux. Portanto, utilizando essa característica do Linux, pesquisadores desenvolveram o mac80211_hwsim, um LKM emulador IEEE 802.11 que utiliza um mecanismo baseado em Namespaces para criar interfaces de rede virtuais independentes sob demanda. O mac8022_hwsim possibilita simulações com qualquer número de interfaces IEEE 802.11, fazendo uso do framework padrão IEEE 802.11, já que o mac802211_hwsim se comporta exatamente como uma placa de rede IEEE 802.11. Desse modo, mac802211_hwsim fornece as mesmas características de cenários em testes de bancadas para desenvolvedores de tecnologias de redes sem-fios que não possuem recursos para construir tal cenário de testes, ou onde os testes de bancada reais não são seguros suficientes para a aplicação alvo ou ainda, de alguma forma, infringem as leis em questão. O mac802211_hwsim funciona lendo as comunidações de canais virtuais configurados em cada interface wireless virtual. Se um quadro é enviado para a interface virtual, o mesmo quadro é replicado para cada outra interface virtual no mesmo canal. Interfaces virtuais configuradas em outros canais não irão receber quadros de outros canais, como demonstrado pela Figura 2.3. Essa técnica é útil para simples simulações e nos testes de novos protocolos. Por outro lado, em simulações reais, mac80211_hwsim possui alguns problemas na implementação de modelos matemáticos para representar seguramente variáveis do mundo real, pelo motivo de que ele somente encaminha os quadros de uma interface virtual para outra sem.

(23) 2.2. WMEDIUMD. 7. Canal 6. Canal 11. Figura 2.3: Envio de dados no Mac80211_hwsim com diferentes namespaces.. nenhuma emulação de mídia. Devido a esses problemas, uma companhia chamada Cozybit desenvolveu o Wmediumd, um emulador de mídia sem-fio que suporta o envio de quadros enviados do espaço de núcleo para o espaço do usuário e os envia para a aplicação, aplicando perdas baseadas em modelos probabilísticos a cada quadro proveniente do mac80211_hwsim [6]. O Wmediumd age com um ataque "homem no meio", interceptando todo tráfego de rede entre o espaço de núcleo e o espaço de usuário, inserindo taxas de erros nas transmissões, enviando quadros baseados na distância virtual entre os nós, e outras características de emulação. Esse processo é feito através da utilização da API (Application Programming Interface) chamada Netlink (Figura 2.4), uma estrutura projetada para transferir informações entre os processos do espaço do usuário e o espaço do núcleo Linux.. Aplicação A. Aplicação B. API de Socker do Núcleo. Subsitema Netlink Barrramento Genérico Netlink Controlador Usuário X. Usuário Y. Figura 2.4: Arquitetura do Netlink. Fonte: adaptado de [15].

(24) 8. CAPÍTULO 2. VISÃO GERAL E MOTIVAÇÃO. 2.3. FIT IoT-Lab. Simuladores e emuladores são comumente utilizados para prototipagem de novos protocolos para IoT. Contudo, eles são apenas alternativas para testes de bancadas reais, que possibilitam que as simulações se comportem exatamente com as mesmas características dos cenários onde a aplicação desenvolvida será aplicada. Para sobrepor esses desafios principais, pesquisadores decidiram construir testes de bancadas ao redor do mundo para oferecer uma plataforma representativa, em larga escala, para moldar, analisar e otimizar protocolos, aplicações e serviços para IoT. Um dos mais importantes testes de bancada atualmente é o FIT IoT-LAB [20] [8] que oferece acesso aberto para milhares de nós sem-fios e uma dúzia de robôs móveis utilizados para testes de mobilidade (Figura 2.5), além de ferramentas científicas para auxílio no projeto, desenvolvimento, otimização e experimentação para novas aplicações em IoT. IoT-LAB é parte do projeto FIT (Future Internet of Things) [7] e é coordenada pela Universidade Pierre et Marie Curie e composta pela Inria, Icube laboratory da Universidade de Strasbourg, Institut mInes-Télécom e CNRS. Os tipos disponíveis de nós são TI MSP430, ARM Cortex e ARM Cortex A8, e os usuários podem selecionar funcionalidades adicionais para cada nó (e.g.: mobilidade, acelerômetro, magnetômetro e giroscópio [9]). Outros serviços oferecidos pelo IoT-LAB: • Acesso remoto total aos nós servidos – usuários podem formatar qualquer firmware, linguagem ou Sistema Operacional para projetar, desenvolver e compilar aplicações; • Acesso direto ao servidor de depuração – cada nó envia dados para o servidor de depuração para viabilizar a deputação (e.g.: pontos de parada na execução do código) centralizada e remota aos nós; • Acesso às portas dos dispositivos (e.g.: porta serial); • Possibilidade de acessar cada nó individualmente utilizando IPv6 (6LoWPAN); • Módulo de GPS para nós A8; • Documentação detalhada e tutoriais, suporte aos diversos Sistemas Operacionais (e.g.: Contiki, FreeRTOS, TinyOS e RIOT), pilhas de protocolos, bibliotecas de comunicação (e.g.: OpenWSN [21]); • captura de pacotes e analisador em cada nó; • Infraestrutura estensível na qual usuários podem fisicamente plugar seus próprios dispositivos de hardware.. 2.4. Discussão. Dos simuladores apresentados, o NS-3 é o que se apresenta mais próximo ao esperado de um simulador para redes sem-fios. Porém, os testes a serem executados nas simulações devem ser feitos utilizando tecnologias específicas para as simulações, e não tecnologias correlatas às utilizadas para embarcar as aplicações. O desenvolvimento movido pela comunidade dos modelos se demonstrou uma maneira razoável de estar em constante evolução e de manter o projeto ativo, contudo esse processo pode levar a modelos não confiáveis [19]..

(25) 2.4. DISCUSSÃO. 9. c Figura 2.5: Inria: à esquerda WifiBot, à direita TurtleBot e no teto hardwares de IoT. Os métodos utilizados pelo mac80211_hwsim e Wmediumd deixam o processamento dos quadros para o núcleo do Linux utilizando núcleo Namespaces e a API Netlink. É um comportamento natural para o processo de transmissão e recepção de quadros visto que eles são tratados pelo núcleo da mesma maneira que seriam tratados caso fossem provenientes de interfaces reais. Porém, falta ao Wmediumd a implementação de novos modelos de mobilidade e a habilidade de interação entre interfaces virtuais e testes de bancadas reais para a organização de ambientes híbridos flexíveis para testes e prototipagens. Esse módulo é parte importante da LVWNet e é utilizado na criação de interfaces de rede sem-fio virtuais. Já o FIT IoT-LAB se mostra como uma alternativa interessante na tentativa fornecer uma ambiente seguro para protótipos, caso o hardware alvo e o Sistema Operacional estejam da lista de itens suportados. O projeto também oferece ferramentas para a análise de dados, robôs para mobilidade a uma vasta documentação incluindo documentos técnicos para bibliotecas suportadas pela maioria dos sistemas e protocolos de IoT. Por outro lado, o ambiente de IoT-LAB não é controlado e suas variáveis ambientais (i.e.: umidade e temperatura) não são gerenciáveis, dificultando a reprodução de cenários onde as condições ambientais sejam fatores limitantes. Além disso, como se trata de um teste de bancada compartilhado com acesso aberto, não há garantia de que os recursos necessários estarão disponíveis sempre que um teste precisar ser iniciado..

(26) 10. CAPÍTULO 2. VISÃO GERAL E MOTIVAÇÃO.

(27) Capítulo 3 Proposta: Linux Virtual Wireless Network. Para preencher as lacunas identificadas pelos simuladores de rede e testes de bancada, criamos o projeto Linux Virtual Wireless Network (LVWNet), um ambiente de simulação de redes sem-fios híbrida para experimentação de protocolos e aplicações sem-fios. As principais características do simulador são: controlador de topologia centralizado; comunicação direta entre nós; código criado em máquinas virtuais pode ser compilado e embarcado na maioria dos dispositivos sem-fios; registro dinâmico de nós, dispositivos virtuais móveis, e uma arquitetura híbrida que possibilita dispositivos reais serem parte de uma topologia virtual.. 3.1. Arquitetura. A arquitetura do LVWNet é composta por dois elementos: nós sem-fios e um controlador de topologia. Nós sem-fios podem ser tanto dispositivos reais, parte de uma infraestrutura configurada, quanto dispositivos virtuais, como máquinas virtuais Linux hospedadas por um monitor de máquina virtual. Assim como o WMediumd, o LVWNet foi projetado para rodar como um módulo, sendo composto por dois módulos: o lvwnet_node e o lvwnet_topology. O controlador de topologia necessita que o mesmo barramento físico dos nós na topologia seja o mesmo, enquanto os nós LVWNet utilizam uma bridge Linux1 para comunicar com outros nós e com o controlador de topologia, como ilustrado pela figura 3.1. Além disso, o controlador de topologia é responsável pela simulação da infraestrutura física sem-fio, gerenciamento o registro dinâmico de nós novos e os mecanismos de suporte a mobilidade dos nós virtuais e de nós reais na topologia virtual. Esse módulo necessita ser carregado antes de qualquer nó LVWNet. Para a comunicação com dispositivos reais, a bridge Linux precisa ser conectada a uma interface real que esteja conectada ao host, com suporte ao protocolo de comunicação utilizado na simulação (e.g.: IEEE 802.11s). Portando, conectar nós LVWNet a um teste de bancada real se torna tão simples quanto conectar o host monitor de máquina virtual 1 Estruturas. internas do Linux que operam na camada 2 do modelo OSI e possuem comportamento similar ao de um switch..

(28) 12. CAPÍTULO 3. PROPOSTA: LINUX VIRTUAL WIRELESS NETWORK. Nó LVWNet. Nó LVWNet. Nó de Topologia. Bridge Linux MONITOR DE MÁQUINA VIRUTAL. Figura 3.1: Arquitetura LVWNet. a um teste de bancada real já configurado. A Figura 3.2 ilustra a arquitetura híbrida fornecida pelo LVWNet e seus elementos.. Figura 3.2: Arquitetura híbrida do LVWNet. Quando o módulo lvwnet_node é carregado, dois parâmetros são obrigatórios: o endereço MAC do controlador de topologia e o posicionamento 3-D virtual do nó. Esse posicionamento é utilizado pelo controlador de topologia para validar se o nó está apto a enviar pacotes para os outros nós, que formam uma estrutura de vizinhança para cada nó. Após calcular a vizinhança, o controlador de topologia envia uma tabela de vizinhança para o nó, para que ele tenha os endereços de todos os seus vizinhos na topologia virtual que serão utilizados no envio direto de pacotes, sem a interferência do controlador de topologia. A maioria dos parâmetros editáveis dos nós e do controlador de topologia são exportados através de sysfs2 [14] e alguns podem ser alterados, como por exemplo, o posicionamento dos nós os quais podem ser alterados por scripts para simulação de nós móveis, muito úteis em simulações para aplicações específicas de IoT. A nova posição será então enviada para o controlador de topologia que calculará a nova vizinhança e a enviará para para os nós envolvidos. O método utilizado para criar enlaces ponto-a-ponto3 entre dois nós é baseada na potência de transmissão, na sensibilidade de recepção e na distância entre os nós calculada 2 Sistema 3 Um. de arquivos virtual fornecida pelo núcleo do Linux. enlace ponto a ponto é formado quando dois nós estão comunicáveis um com o outro..

(29) 3.2. O PROTOCOLO LVWNET. 13. pelas suas posições 3-D virtuais. O modelo utilizado é chamado de Perda de Caminho Livre (Free-space Loss - FSL) [18] e é dado pela equação 3.1 onde D refere-se a distância euclidiana (quilômetros), calculada pela equação 3.2 e λ para a velocidade da luz no vácuo (metros por segundo) dividido pela frequência do canal utilizada para transmitir os sinais (Mega Hertz) (equação 3.3). O FLS foi utilizado por simplicidade e deve ser substituído em versões futuras do LVWNet por modelos mais adequados.. LFS = 20log10. D=. λ=. p. c , f. 4πD λ. ! (3.1). x2 + y2 + z2. (3.2). c = 3 × 108 m/s. (3.3). Com base nas equações 3.1, 3.2, e 3.3, a equação de FSL pode ser resumida por 3.4, onde Srecep e Ptrans são respectivamente a sensitividade de recepção e potência de transmissão. Srecep ≥ Ptrans − LFS. 3.2. (3.4). O Protocolo LVWNet. Quando um quadro IEEE 802.11 é enviado por uma aplicação, o módulo do lvwnet_node intercepta o quadro, encapsula-o em um quadro IEEE 802.3 Ethernet com 0x0808 como valor do campo tipo, hexadecimal utilizado para identificar quadros LVWNet. Na recepção, o módulo lvwnet_node recebe todos os quadros IEEE 802.3 Ethernet tipados como 0x0808 e desencapsula o quadro LVWNet. Então, após o processamento do quadro LVWNet, o quadro é injetado novamente na pilha de rede do núcleo para ser processado naturalmente pelo núcleo, como se estivesse sendo recebido por uma interface de rede sem-fio virtual. Os processos de envio e recepção estão descritos pela Figura 3.3. O protocolo LVWNet é composto por três quadros diferentes: registro de dispositivos, enlaces ponto-a-ponto e mensagens diretas entre dispositivos. O registro de dispositivos carrega a posição dos dispositivos, potência de transmissão, sensitividade de recepção, e o canal de transmissão utilizado, como demonstrado pela Figura 3.4. Essa mensagem é enviada por qualquer nó LVWNet que deseje fazer parte da topologia LVWNet. Após enviar essa mensagem, o nó aguarda uma mensagem do controlador de topologia contendo os endereços de seus vizinhos. Então, todas as mensagens podem ser entregues diretamente entre os nós participantes e seus respectivos vizinhos. A Figura 3.5 ilustra o processo de registro dinâmico..

(30) 14. CAPÍTULO 3. PROPOSTA: LINUX VIRTUAL WIRELESS NETWORK. App pede para o núcleo enviar. 80211 recebe os dados normalmente. lvwnet_node encapsula em um Ethernet e envia. lvwnet_node recebe o quadro. Figura 3.3: Interceptação das mensagens pelos módulos do LVWNet.. Figura 3.4: Mensagem de registro de nós do LVWNet. Para atualização de todos os nós, uma mensagem periódida chamada mensagem de enlace ponto-a-ponto é enviada do controlador de topologia para os nós LVWNet. Essa mensagem contém o endereço MAC, relação sinal-ruído (SNR), endereços dos vizinhos, e o atraso que pode ser utilizado para o envio de quadros do LVWNet para camadas superiores, processo ilustrado em Figura 3.6.. 3.3. Estado Atual e Desenvolvimento Futuro. Com base no estado atual de outros simuladores e no estado atual do LVWNet, alguns outros recursos extras são interessantes: um modelo de exportação de dados para uma melhor visualização dos resultados das simulações, um modelo de erro para simplificação da interferência ambiental na propagação do sinal, um modelo de consumo de energia para melhorar a análise de sensores remotos, e finalmente, o suporte para os protocolos mais adequados para o IoT..

(31) 3.3. ESTADO ATUAL E DESENVOLVIMENTO FUTURO. 15. Figura 3.5: Registro dinâmico no LVWNet.. Figura 3.6: Mensagens de informação do LVWNet.. 3.3.1. Exportação de Dados. Em cenários de IoT complexos, a análise de dados é um processo muito importante nas avaliações de aplicações. Os dados exportados por simuladores de rede precisam ser legíveis e facilmente manipulados. Assim, a modelagem desta extensão pode ajudar os desenvolvedores a usar o LVWNet para analisar mais profundamente o comportamento das aplicações em execução no ambiente de simulação. Inicialmente, os dados exportados estão relacionados ao uso de recursos internos e uso de rede: • Carga na largura de banda da interface – uma porcentagem da largura de banda total sendo consumida pelos quadros transmitidos e recebidos; • Carga de memória – uma porcentagem da memória total utilizada pelo nó LVWNet; • Carga da CPU – uma porcentagem do total de processamento sendo utilizado pelo nó LVWNet; e.

(32) 16. CAPÍTULO 3. PROPOSTA: LINUX VIRTUAL WIRELESS NETWORK • Erros de transmissão – erros inseridos pelo simulador nas transmissões; • Arquitetura modular para a coleta de dados – permitir que outros trabalhos ampliem ainda mais a exportação de dados do LVWNet, como Simple Network Management Protocol (SNMP), APIs REST e XML.. 3.3.2. Modelo de Erros. O ambiente de simulação esconde características importantes de IoT e redes sem fio, por exemplo, as comunicações sem fio do mundo real podem sofrer interferência que degradam o sinal e causam erros de transmissão. Para obter resultados mais confiáveis, o simulador precisa emular o meio com modelos de erros precisos, imitando o que aconteceria em cenários reais. Assim, para a maioria dos cenários IoT (por exemplo, cidades inteligentes), esta emulação é uma parte importante da avaliação de novas aplicações IoT. Esta extensão permitirá que o LVWNet ofereça a capacidade de inserir modelos de erros externos na transmissão do nó LVWNet. Inicialmente, o modelo oferecerá a possibilidade de erros nas transmissões, individualmente para cada lvwnet_node. A implementação desta extensão permitirá trabalhos futuros a implementar modelos mais complexos de adição de erros por mudanças nas características ambientais. As informações estatísticas sobre os erros de transmissão inferidos pelo simulador estarão disponíveis através da extensão da exportação de dados.. 3.3.3. Modelo de Consumo de Energia. A maioria das aplicações IoT são desenvolvidas para serem executadas na estrutura de redes de sensores sem fio (WSN). Os sensores são dispositivos autônomos que precisam de sua própria fonte de energia (ou seja, baterias de lítio, células solares). Alguns recursos implementados por aplicativos e protocolos consomem energia de sensores, reduzindo a vida útil dos dispositivos. Uma solução viável para este problema é diminuir o consumo de energia. Os sensores utilizam o poder energizando o hardware periférico, por exemplo, ao processar quadros de rede ou ao executar operações da CPU. Os ambientes de simulação devem ser capazes de produzir dados estatísticos sobre o consumo de energia dos dispositivos virtuais por meio de modelos confiáveis para avaliar de forma segura aplicativos ou protocolos de WSNs. Assim, esta extensão permitirá que o LVWNet infira no consumo de energia de lvwnet_nodes assistindo seu recurso (isto é, processamento de carga, uso de rede) e exportando esta informação através da extensão de exportação de dados.. 3.3.4. Suporte ao IEEE 802.15.4. Atualmente, o LVWNet oferece suporte para a família de protocolos IEEE 802.11 o qual possui uma variante utilizado em aplicações de IoT de baixa potência, chamado 802.11ah [1], apesar de que o protocolo que melhor se adaptam à maioria das aplicações IoT serem o IEEE 802.15.4 (ZigBee) [22] e o protocolo LoRa [2]..

(33) Capítulo 4 Preparação do Ambiente. Atualmente, o LVWNet é um simulador redes sem-fio voltado para a simulação de aplicações IoT capaz de comunicar nós virtuais com equipamentos reais dentro da mesma estrutura virtual. Além disso, o simulador oferece suporte à mobilidade e associação dinâmica de nós, com consumo reduzido de recursos, possibilitando melhor simulação de ambientes de alta densidade e também oferece alta escalabilidade visto que é possível agregar outros nós presentes em outras LANs (i.e.: interconexão através de VPN). Para possibilitar uma melhor integração e desenvolvimento do LVWNet, o seu código foi disponibilizado no github (https://github.com/lodantas/lvwnet) e seu desenvolvimento está aberto para colaboração. O repositório é composto pelos diretórios listados na tabela abaixo (Tabela 4.1): Além disso, uma série de scripts foram criados para melhor administrar tanto os nós controladores quanto os nós sem-fio virtuais. Esses scripts são versões iniciais utilizadas somente em ambientes de teste do LVWNet e futuramente serão melhorados e agregados às funcionalidades internas do LVWNet. Os scripts estão descritos na tabela abaixo (Tabela 4.2):. 4.1. Preparando o Ambiente. O LVWNet foi estritamente desenvolvido para Linux, e todos os testes foram executados na distribuição Fedora 25. Contudo, é possível que, com a maturidade da plataforma, outras distribuições Linux possam ser suportadas. A tecnologia utilizada durante os primeiros testes e a única completamente suportada na versão atual do LVWNet para virtualização foi a Qemu/KVM, que pode ser instalada em sistemas Fedora com o comando abaixo (Código 4.1): 1. # s u −c " d n f i n s t a l l @ v i r t u a l i z a t i o n ". Além disso, os módulos do LVWNet precisam ser baixados, compilados e carregados no núcleo do Fedora 25. Para executar o download do código mais recente do projeto disponível no GitHub, basta executar o comando abaixo: 1. # g i t c l o n e h t t p s : / / g i t h u b . com / l o d a n t a s / l v w n e t . g i t. Após efetuar o download, serão necessários alguns programas e dependências para a compilação e carregamento dos módulos LVWNet (lvwnet_node e lvwnet_controller)..

(34) 18. CAPÍTULO 4. PREPARAÇÃO DO AMBIENTE. Tabela 4.1: Diretórios importantes do projeto LVWNet. Caminho Descrição /lvwnet Diretório raíz para os principais arquivos do LVWNet. /lvwnet/libvirt-storage. Contêiner de armazenamento do monitor de máquina virtual libvirt (padrão) onde estão localizadas as máquinas virtuais.. /lvwnet/inbox. Diretório onde estão os arquivos de configuração dos nós. Cada arquivo possui parâmetros necessários para a execução dos nós e que podem ser manipulados.. /lvwnet/outbox. Diretório onde estão os arquivos de configuração dos nós após serem processados (evita que dois nós utilizem o mesmo arquivo).. Conjunto de arquivos que auxiliam na criação de novos arquivos de configuração em lote (editar o arquivo generate.sh /lvwnet/inbox/template para mudar parâmetros como, por exemplo a posição máxima dos nós. /lvwnet/modules. Módulos lvwnet_node.ko e lvwnet_controller.ko que serão executados pelos nós físicos e virtuais.. /lvwnet/working/main. Código fonte do LVWNet.. /lvwnet/scripts. Conjunto de scripts auxiliares.. No Fedora 25, a compilação e o carregamento dos módulos segue o processo descrito nos Códigos 4.1 e 4.1. Outras distribuições podem seguir o mesmo padrão com algumas especificidades e alterações pontuais. 1. # d n f i n s t a l l −y n c l e o −d e v e l n c l e o −h e a d e r s n c l e o −m o d u l e s r p m d e v t o o l s yum− u t i l s a u d i t −l i b s −d e v e l b i n u t i l s −d e v e l e l f u t i l s − d e v e l h m a c c a l c n c u r s e s −d e v e l newt−d e v e l n u m a c t l −d e v e l o p e n s s l −d e v e l p c i u t i l s −d e v e l p e r l p e s i g n x m l t o p y t h o n −d e v e l a s c i i d o c p e r l − E x t U t i l s −Embed b i s o n p e r l −g e n e r a t o r s. O processo descrito no Código 4.1 deve ser feito em parte, quando se tratar de uma Controladora LVWNet, o módulo lvwnet_controller, e quando se tratar de um nó LVWNet, lvwnet_node. Esse processo pode ser executado tanto em equipamentos reais quanto em máquinas virtuais, desde que todas os nós estejam conectadas à mesma LAN. 1 2 3 4 5. # # # #. cd . / l v w n e t insmod m o d u l e s / mac80211 . ko insmod m o d u l e s / l v w n e t \ _ c o n t r o l l e r e t h e r n i c _ n a m e =$ {NIC_CONTROLLER} insmod m o d u l e s / l v w n e t _ n o d e . ko \ e t h e r n i c _ n a m e =$ {NIC} \.

(35) 4.1. PREPARANDO O AMBIENTE. 19. Tabela 4.2: Diretório /lvwnet/scripts Scripts em /lvwnet/scripts Descrição Script que cria clones a partir do domínio template01_ lvwnet_f25 (sempre manter esse domínio desligado). create_clones.sh Para alterar a quantidade de clones, alterar a variável number_of_clones.. 6 7 8 9 10 11 12. shutdown_all_nodes.sh. Envia um pedido de desligamento para todos os nós virtuais.. poweroff_all_nodes_forced.sh. Envia um sinal de desligamento para todos os nós virtuais (útil em caso de inconsistência de núcleo generalizado).. reboot_all_nodes.sh. Envia um pedido de reinicialização para todos os nós virtuais.. start_all_nodes.sh. Envia um pedido de inicialização para todos os nós virtuais.. remove_all_nodes.sh. Cancela o registro do libvirt e remove o disco de todos os nós, exceto o nó template template01_lvwnet_f25.. load_controller_at_all.sh. Carrega todos os módulos necessários para o controller e para o nó físico.. unload_controller.sh. Descarrega todo os módulos necessários para o controller e para o nó físico.. init_controller.sh. Script executado pelo load_controller_at_all para carregar somente o controlador LVWNet.. init.sh. Script que é executado por todos os nós virtuais quando são ligados. Aqui é possível colocar tarefas para serem executadas imediatamente quando ele é inicializado.. c t r l _ h o s t _ a d d r =$ {MAC_CONTROLLER} \ x _ p o s =$ {X_POS} \ y _ p o s =$ {Y_POS} \ z _ p o s =$ {Z_POS} \ i s _ c o n t r o l l e r =0 \ power_tx_dbm =$ {POWER_TX_DBM} \ s e n s _ r x _ d b m =$ {SENS_RX_DBM}. 4.1.1. Ambiente Totalmente Virtual. Em casos onde a simulação totalmente virtual é mais interessante (Qemu/KVM) (Figura 3.1), templates devem ser criados para suportar alterações em uma grande quantidade.

(36) 20. CAPÍTULO 4. PREPARAÇÃO DO AMBIENTE. de nós facilitando sua implantação, principalmente para ambientes onde haja uma grande densidade de nós. O script que criará os nós será o create_clones.sh, e após esse processo, um outro script irá auxiliar na inicialização de todos os nós criados, start_all_nodes.sh (Tabela 4.2). Esses scripts simplesmente se utilizam das funcionalidades do Qemu/KVM para controlar os nós, ou seja, o processo pode ser executado manualmente sem a necessidade dos scripts.. 4.1.2. Ambiente Híbrido. Em casos onde se deseja validar aplicações IoT em ambientes híbridos, faz-se necessária a conexão do monitor de máquina virtual (Qemu/KVM) com os nós reais (Figura 3.2). Porém, o processo é o mesmo seguindo a instalação das dependências (Código 4.1), o download da versão mais recente do LVWNet dos repositórios públicos do Github (Código 4.1) e, por fim, do carregamento do módulo do nó LVWNet (Código 4.1).. 4.2. Simulação de Mobilidade. O LVWNet se utiliza de arquivos x_pos, y_pos e z_pos disponibilizados no diretório /sys/module/lvwnet_node/parameters. Caso algum desses arquivos sofra uma escrita, uma função recebe o valor escrito e envia uma mensagem para o controlador de topologia, alterando sua posição no espaço 3D virtual. Assim, novos vizinhos são calculados e a estrutura se reorganiza. Essa técnica foi pensada para facilitar que scripts possam alterar as posições dos nós facilmente, tornando as simulações mais fáceis e a obtenção de dados mais ágil..

(37) Capítulo 5 Experimentos e Resultados. A análise e a validação do LVWNet foram avaliadas através de um cenário híbrido com dois dispositivos virtuais, o controlador de topologia e um dispositivo real. Embora o LVWNet possa ser usado em dispositivos reais, devido aos benefícios fornecidos pela virtualização, recomenda-se o uso de máquinas virtuais leves para facilitar a criação de novos nós. O monitor de máquina virtual usado neste trabalho foi o Virtual Machine baseado em núcleo, KVM, com núcleo com memória compartilhada que permite o compartilhamento de memória entre as máquinas virtuais. Cada máquina virtual foi criada com 256 MB de memória RAM e um processador genérico de um núcleo. O dispositivo real usou uma interface sem fio Intelbrás WBN900 USB, que suporta o protocolo IEEE 802.11s - usado para testar a comunicação entre os dispositivos usando a infraestrutura sem fio fornecida pelo LVWNet.. ID. Tipo. 1 2 3 4. Virtual Virtual Virtual Real. 5.1. Tabela 5.1: Dispositivos criados. Endereço MAC IPv4 Ethernet (ens9) WLAN (wlan0) aa:aa:aa:00:01:01 02:00:00:00:01:01 10.1.1.11/8 aa:aa:aa:00:01:02 02:00:00:00:01:02 10.1.1.12/8 aa:aa:aa:00:01:03 02:00:00:00:01:03 10.1.1.13/8 fe:54:00:32:3d:dc 00:1a:3f:a5:74:e7 10.1.1.99/8. Posição (m) x y z 500 500 10 600 1300 10 1200 500 10 700 800 10. Comunicação em um Ambiente Híbrido. Os dispositivos virtuais foram definidos com 20 dBm de potência de transmissão e -75 dB de sensibilidade de recepção visto que esses valores são comuns nas comunicações de redes sem-fios IEEE 802.11s. Isso resulta em transmissões com -95 dB a uma distância máxima de aproximadamente 556 metros 3.4. O dispositivo real foi posicionado para estabelecer dois enlaces dos nós, com os dispositivos virtuais 1 e 2. O dispositivo virtual 3 no início está posicionado além do limite para a transmissão de outros dispositivos propositalmente para testar o registro dinâmico de dispositivos e mobilidade..

(38) 22. CAPÍTULO 5. EXPERIMENTOS E RESULTADOS. Figura 5.1: Terminal no dispositivo 4.. 5.2. Mobilidade e Registro Dinâmico de Nós. Depois de carregar o módulo do nó LVWNet nos dispositivos virtuais, é possível verificar no dispositivo real 4 a presença de enlaces dos nós criados automaticamente com seus vizinhos, conforme ilustrado pela Figura 5.1. Para testar a simulação de dispositivos móveis, iniciamos o dispositivo virtual 3 sem enlaces dos nós e o transferimos para 6 marcos diferentes em ordem para criar e destruir enlaces dos nós de outros dispositivos. A tabela 5.2 mostra o estado dos enlaces dos nós com os dispositivos 1 e 2. Tabela 5.2: Representação de 6 marcos durante o movimento do dispositivo 3. Células verdes demarcam enlaces ponto-a-ponto estabelecidos. Marco 1 2 3 4 5 6. Dispositivo 3 x(m) y(m) 1200 500 700 500 900 700 700 800 900 1300 900 1800. z(m) 10 10 10 10 10 10. Dispositivo 1 Signal (dBm) Distância (m) -97 700 -86 200 -93 447 -91 360 -99 894 -99 894. Enlaces x x x. Sinal (dBm) -100 -98 -96 -94 -89 -89. Dispositivo 2 Distância (m) Enlaces ponto-a-ponto 1000 806 670 509 x 300 x 300 x. O estado dos enlaces dos nós foi calculado usando a equação 3.4, e foram estabelecidos quando os dispositivos estavam próximos o suficiente, baseado em seu poder de transmissão e sensibilidade de recepção. A figura 5.2 ilustra o movimento do dispositivo 3 nas dimensões x e y, o alcance do rádio dos dispositivos 1 e 2 e 6 marcos.. 5.3. Consumo de Recursos. O LVWNet foi desenvolvido com intuito de fornecer grande escalabilidade, principalmente pensando em fornecer capacidade de simulação de aplicações com grande densidade de nós, e também para que não houvesse nenhum impacto de performance nas simulações. Para alcançar isso, o simulador foi desenvolvido para consumir a menor quantidade de recursos computacionais (Memória, CPU e Rede) possível. Para mensurar os recursos consumidos foram executados testes com a criação de 50 nós LVWNet e foram amostras dos recursos foram coletados durante o processo de criação e funcionamento básico do simulador. Cada amostra foi coletada 10 vezes e a média foi utilizada para desenhar os gráficos. O monitor de máquina virtual utilizado possui um Intel(R) Xeon(R) X5690 @ 3.47GHz com 24 núcleos de processamento e 94 GB de memória.

(39) 5.3. CONSUMO DE RECURSOS. 23. Figura 5.2: Movimento do dispositivo 3 e as áreas de alcance dos rádios. RAM. A máquina virtual de template possui um processador virtual genérico com 1GHz e 256 GB de memória RAM. Como pode ser observado na Figura 5.3, o consumo de processamento aumentou conforme os nós iam sendo criados, como esperado. Porém o impacto de 50 nós não chegou a 1% do poder de processamento da CPU do monitor de máquina virtual. Nessas configurações e através do estudo do comportamento do gráfico de consumo de processamento, com os nós ociosos, é possível predizer que seria possível, com essas configurações, alocar mais de 500 nós LVWNet em uma simulação. Já com o consumo de memória (Figura 5.4), a memória livre do monitor de máquina virtual era, inicialmente, 26% e decresceu até chegar aproximadamente em 9%, ou seja, um decréscimo de 17% de 96 GB, totalizando 16 GB de memória consumido ou cerca de 320 MB de memória por nó LVWNet. Por fim, o consumo de largura de banda causado pela troca de mensagens entre os nós utilizando o protocolo LVWNet (Figura 5.4) alcançou, no seu pico de utilização (ao se instanciar os 50 nós LVWNet) 41.636 kb de dados recebidos (RX) e 1.076 kb de dados transmitidos (TX) pela controladora LVWNet. Esse valor é muito pequeno e comprova que o impacto na comunicação entre os nós é irrisório e não afeta a performance das simulações em geral..

(40) 24. CAPÍTULO 5. EXPERIMENTOS E RESULTADOS. Figura 5.3: Consumo de processamento.. Figura 5.4: Consumo de memória RAM.. Figura 5.5: Consumo de largura de banda dos nós (à esquerda RX e à direita TX)..

(41) Capítulo 6 Conclusão. Neste trabalho foram discutidos problemas na avaliação de aplicações para redes semfios, principalmente quando apresentam uma grande quantidade ou mobilidade de nós, apresentando desvantagens de testes de bancadas e por que os simuladores de redes são tão importantes hoje em dia, apesar de carecem de recursos para atender aos requisitos e restrições de aplicações sem-fio mais complexas. Como motivação, foram discutidos problemas de alguns dos mais importantes e relevantes simuladores de redes: NS-3, WMediumd e FIT IoT-LAB, cada um representando um tipo especial de simulador e enquanto foram discutidas suas desvantagens. A proposta desse trabalho foi apresentada na sequência, o LVWNet, onde foi descrita a sua importância como uma alternativa para a criação de testes híbridos para aplicações IoT e seus detalhes de implementação. As principais características implementadas até o momento são: o registro dinâmico de nós, sistema de mobilidade incorporado, um controlador de topologia centralizado, comunicações diretas entre nós, o código criado para máquinas virtuais pode ser compilado de forma cruzada para dispositivos reais e de arquitetura híbrida que permite comunicações de dispositivos virtuais e reais. Por fim, discutimos as extensões que poderiam melhorar a aplicabilidade do LVWNet como um simulador de rede para aplicativos IoT e avaliação detalhada de tecnologias de redes sem fio. Para a validação das funcionalidades do LVWNet, foram executados dois tipos de testes, um envolvendo mobilidade de nós em um ambiente híbrido, onde um nó se movimentava através de uma infraestrutura híbrida enquanto enlaces se formaram com os diferentes nós com base nos modelos utilizados para o cálculo do alcance do rádio. O LVWNet se comportou como esperado e demonstrou estar em conforme com o comportamento que seria demonstrado em um cenário real de produção. Além disso, todos os códigos foram embardados em dispositivos reais sem nenhuma alteração com relação aos códigos utilizados nos nós virtuais. O segundo teste foi um teste de carga onde foi dimensionado o processo de criação excessiva de nós visando a simulação de um ambiente com alta densidade onde o LVWNet se comportou como esperado, tendo como únicos fatores limitantes os recursos computacionais. Portanto, o LVWNet é, atualmente, uma alternativa muito interessante para alcançar simulações mais próximas do cenário real e que também oferece a capacidade de compilação e execução do mesmo código utilizado na fase de testes e simulação em equipamentos reais, diminuindo o tempo de execução de testes e otimizando a mão de obra dos desen-.

(42) 26. CAPÍTULO 6. CONCLUSÃO. volvedores. Além disso, oferece a capacidade de simulação híbrida, onde equipamentos reais podem fazer parte de um ambiente virtual, interessante para cenários de difícil simulação como dispositivos de alta mobilidade ou para analisar o comportamento de um equipamento real em uma rede com alta densidade de nós. Além disso, o simulador é leve e tem muito pouco impacto nos recursos do ambiente de simulação tornando-o uma solução para cenários onde é necessário simular uma grande quantidade de nós. Por fim, o LVWNet é um projeto recente porém com grande potencial, que precisa ser desenvolvido e aprimorado. O desenvolvimento das extensões discutidas no início deste trabalho é o próximo passo para alcançar maturidade necessária para se tornar um importante simulador de rede, especializado em avaliações IoT complexas..

(43) Referências Bibliográficas. [1] Adame, Toni, Albert Bel, Boris Bellalta, Jaume Barcelo and Miquel Oliver [2014], ‘Ieee 802.11 ah: the wifi approach for m2m communications’, IEEE Wireless Communications 21(6), 144–152. [2] Augustin, Aloÿs, Jiazi Yi, Thomas Clausen and William Mark Townsley [2016], ‘A study of lora: Long range & low power networks for the internet of things’, Sensors 16(9), 1466. [3] Bhushan, Naga, Junyi Li, Durga Malladi, Rob Gilmore, Dean Brenner, Aleksandar Damnjanovic, Ravi Sukhavasi, Chirag Patel and Stefan Geirhofer [2014], ‘Network densification: the dominant theme for wireless evolution into 5g’, Communications Magazine, IEEE 52(2), 82–89. [4] Bilalb, Sardar M, Mazliza Othmana et al. [2013], ‘A performance comparison of network simulators for wireless networks’, arXiv preprint arXiv:1307.4129 . [5] Chaudhary, Rachna, Shweta Sethi, Rita Keshari and Sakshi Goel [2012], ‘A study of comparison of network simulator-3 and network simulator-2’, IJCSIT) International Journal of Computer Science and Information Technologies 3(1), 3085–3092. [6] Cozybit [2013], ‘Wmediumd’, https://github.com/cozybit/wmediumd. [7] FIT-Equipex [n.d.], url=https://www.fit-equipex.fr/. Accessed: 2017-03-28. [8] FIT/IoT-LAB: Very large scale open wireless sensor network testbed [n.d.], url=https://www.iot-lab.info/. Accessed: 2017-03-28. [9] Fleury, Eric, Nathalie Mitton, Thomas Noel and Cédric Adjih [2015], ‘Fit iot-lab: The largest iot open experimental testbed’, ERCIM News (101), 4. [10] Henderson, Tristan, David Kotz and Ilya Abyzov [2008], ‘The changing usage of a mature campus-wide wireless network’, Computer Networks 52(14), 2690–2712. [11] Jain, Kamal, Jitendra Padhye, Venkata N Padmanabhan and Lili Qiu [2005], ‘Impact of interference on multi-hop wireless network performance’, Wireless networks 11(4), 471–487. [12] Jin, Jiong, Jayavardhana Gubbi, Slaven Marusic and Marimuthu Palaniswami [2014], ‘An information framework for creating a smart city through internet of things’, Internet of Things Journal, IEEE 1(2), 112–121. 27.

(44) 28. REFERÊNCIAS BIBLIOGRÁFICAS. [13] Khan, Atta R, Sardar M Bilal and Mazliza Othman [2012], A performance comparison of open source network simulators for wireless networks, em ‘Control System, Computing and Engineering (ICCSCE), 2012 IEEE International Conference on’, IEEE, pp. 34–38. [14] Love, Robert [2013], Linux System Programming: Talking Directly to the Kernel and C Library, "O’Reilly Media, Inc.". [15] Martínez Illán, Alberto [2013], Medium and mobility behaviour insertion for 802.11 emulated networks, Dissertação de mestrado, Universitat Politècnica de Catalunya. [16] Nakauchi, Kiyohide [2010], Introduction to network virtualization technologies in future internet research, em ‘Asia FI Summer School (August 26, 2010) www. asiafi. net/meeting/2010/summerschool/p/nakauchi. pdf’. [17] Padhye, Jitendra, Sharad Agarwal, Venkata N Padmanabhan, Lili Qiu, Ananth Rao and Brian Zill [2005], Estimation of link interference in static multi-hop wireless networks, em ‘Proceedings of the 5th ACM SIGCOMM conference on Internet Measurement’, USENIX Association, pp. 28–28. [18] Phillips, Chris, Douglas Sicker and Dirk Grunwald [2013], ‘A survey of wireless path loss prediction and coverage mapping methods’, Communications Surveys & Tutorials, IEEE 15(1), 255–270. [19] Rampfl, Sebastian [2013], Network simulation and its limitations, em ‘Proceeding zum Seminar Future Internet, Innovative Internet Technologien und Mobilkommunikation und Autonomous Communication Networks’, Vol. 57. [20] Tonneau, Anne-Sophie, Nathalie Mitton and Julien Vandaele [2014], A survey on (mobile) wireless sensor network experimentation testbeds, em ‘2014 IEEE International Conference on Distributed Computing in Sensor Systems’, IEEE, pp. 263– 268. [21] Watteyne, Thomas, Xavier Vilajosana, Branko Kerkez, Fabien Chraim, Kevin Weekly, Qin Wang, Steven Glaser and Kris Pister [2012], ‘Openwsn: a standards-based low-power wireless development environment’, Transactions on Emerging Telecommunications Technologies 23(5), 480–493. [22] Zanella, Andrea, Nicola Bui, Angelo Castellani, Lorenzo Vangelista and Michele Zorzi [2014], ‘Internet of things for smart cities’, IEEE Internet of Things Journal 1(1), 22–32..

(45)