UNIVERSIDADE DO RIO GRANDE DO NORTEFEDERAL

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

CENTRO DE TECNOLOGIA

PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA E

DE COMPUTAÇÃO

Ambiente Híbrido para Avaliação de RedesSem-fio

Gilles Velleneuve Trindade Silvano

Orientador: Prof. Dr. Ivanovich Medeiros Dantas da Silva

Dissertação de Mestrado apresentada aoPrograma de Pós-Graduação em EngenhariaElétrica e de Computação da UFRN (área deconcentração: Engenharia de Computação)como parte dos requisitos para obtenção dotítulo de Mestre em Ciências.

Número de ordem PPgEEC: M502Natal, RN, setembro de 2017

Universidade Federal do Rio Grande do Norte – UFRNSistema 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 Trin-

dade 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 deComputaçã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

Agradecimentos

Ao meu orientador Ivan e ao professor Madruga, sou muito grato pela orientação e apoiono 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.

Resumo

Redes sem-fio têm evoluído consideravelmente nos últimos anos e consequentementetem sido aplicadas nos mais diversos cenários, desde redes locais sem-fios até redes desensores sem-fios para Internet das Coisas (Internet of Things - IoT). Cada nova aplicaçãoapresenta suas próprias características, especificidades e consequentemente novos desa-fios que devem ser vencidos para que ela se torne viável e seja enviada para produção eembarcada em dispositivos reais.

Porém, os simuladores de redes em geral não fornecem algumas importantes funcio-nalidades para as simulações e avaliações de aplicações de redes sem-fio. Por exemplo, ossimuladores exigem implementação da aplicação direcionada para o ambiente do simu-lador exigindo o dobro de esforço dos desenvolvedores e problemas de integração entreas tecnologias utilizadas durante os testes e as utilizadas para embarcar a aplicação emdispositivos reais. Além disso, os simuladores devem dar suporte a em cenários maiscomplexos de redes sem-fio como ambientes com alta mobilidade ou alta densidade denós. Por fim, o comportamento simulado por softwares e não na análise de dispositivosreais utilizando código final, compilado para os dispositivos reais finais, não fornece amelhor visualização do comportamento da aplicação simulada.

Para preencher essas lacunas desenvolvemos o LVWNet: um ambiente e simulaçãobaseado em virtualização Linux para a avaliação de aplicações de redes sem-fio que ofe-rece suporte a simulação de código real e ambiente híbrido de integração entre nós virtuaise dispositivos reais, além de flexibilidade e baixo consumo de recursos. Nesse trabalhosã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íbridocom suporte a mobilidade, no qual foram desenvolvidos testes para avaliar a autenticidadedos dados de simulação obtidos durante os testes que comprovaram sua eficiência comoambiente de avaliação de redes sem-fios.

Palavras-chave: Análise de Desempenho, Internet das Coisas, Simuladores de Rede,Virtualização.

Abstract

Wireless networks have evolved considerably in recent years and have consequentlybeen applied in a wide range of scenarios, from wireless local area networks to Internet-of-Things (IoT) wireless sensor networks. Each new application presents its own charac-teristics, specificities and consequently new challenges that must be overcome in orderfor it to become viable and be sent to production and shipped to real devices.

However, network simulators generally do not provide some important functionalitiesfor the simulations and evaluations of wireless applications. For example, simulators re-quire implementation of the application targeted to the simulator environment requiringtwice the effort of the developers and problems of integration between the technologiesused 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 envi-ronments with high mobility or high node density. Finally, software-simulated behaviorrather than real device analysis using final code, compiled for the final real devices, doesnot provide the best visualization of simulated application behavior.

To fill these gaps we have developed LVWNet: a Linux-based virtualization-basedsimulation and environment for evaluating wireless network applications that supportsreal-world simulation and hybrid integration between virtual nodes and real devices, aswell as flexibility and low resource consumption. This paper presents the implementationdetails of the LVWNEt and its basic functionalities through the simulation of an IEEE802.11s wireless network in a hybrid environment with mobility support, in which testswere developed to evaluate the authenticity of the simulation data obtained during thetests that have proven their efficiency as evaluation environment of wireless networks.

Keywords: Internet o Things, Network Simulators, Performance Analysis, Virtuali-zation.

Sumário

Sumário i

Lista de Figuras iii

Lista de Tabelas v

1 Introdução 11.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Lista de Símbolos e Abreviaturas 1

2 Visão Geral e Motivação 32.1 NS-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Wmediumd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 FIT IoT-Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Proposta: Linux Virtual Wireless Network 113.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 O Protocolo LVWNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3 Estado Atual e Desenvolvimento Futuro . . . . . . . . . . . . . . . . . . 14

3.3.1 Exportação de Dados . . . . . . . . . . . . . . . . . . . . . . . . 153.3.2 Modelo de Erros . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3.3 Modelo de Consumo de Energia . . . . . . . . . . . . . . . . . . 163.3.4 Suporte ao IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . 16

4 Preparação do Ambiente 174.1 Preparando o Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1.1 Ambiente Totalmente Virtual . . . . . . . . . . . . . . . . . . . . 194.1.2 Ambiente Híbrido . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2 Simulação de Mobilidade . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5 Experimentos e Resultados 215.1 Comunicação em um Ambiente Híbrido . . . . . . . . . . . . . . . . . . 215.2 Mobilidade e Registro Dinâmico de Nós . . . . . . . . . . . . . . . . . . 225.3 Consumo de Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

i

6 Conclusão 25

Referências bibliográficas 27

Lista de Figuras

2.1 Módulos NS-3 em camadas. . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Namespace de rede no Linux. . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Envio de dados no Mac80211_hwsim com diferentes namespaces. . . . . 72.4 Arquitetura do Netlink. Fonte: adaptado de [15] . . . . . . . . . . . . . . 72.5 c©Inria: à esquerda WifiBot, à direita TurtleBot e no teto hardwares de IoT. 9

3.1 Arquitetura LVWNet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2 Arquitetura híbrida do LVWNet. . . . . . . . . . . . . . . . . . . . . . . 123.3 Interceptação das mensagens pelos módulos do LVWNet. . . . . . . . . . 143.4 Mensagem de registro de nós do LVWNet. . . . . . . . . . . . . . . . . . 143.5 Registro dinâmico no LVWNet. . . . . . . . . . . . . . . . . . . . . . . 153.6 Mensagens de informação do LVWNet. . . . . . . . . . . . . . . . . . . 15

5.1 Terminal no dispositivo 4. . . . . . . . . . . . . . . . . . . . . . . . . . . 225.2 Movimento do dispositivo 3 e as áreas de alcance dos rádios. . . . . . . . 235.3 Consumo de processamento. . . . . . . . . . . . . . . . . . . . . . . . . 245.4 Consumo de memória RAM. . . . . . . . . . . . . . . . . . . . . . . . . 245.5 Consumo de largura de banda dos nós (à esquerda RX e à direita TX). . . 24

iii

Lista de Tabelas

4.1 Diretórios importantes do projeto LVWNet. . . . . . . . . . . . . . . . . 184.2 Diretório /lvwnet/scripts . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.1 Dispositivos criados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.2 Representação de 6 marcos durante o movimento do dispositivo 3. Célu-

las verdes demarcam enlaces ponto-a-ponto estabelecidos. . . . . . . . . 22

v

Capítulo 1

Introdução

Redes sem fio tem evoluído consideravelmente nos anos recentes e tem sido aplicadasa vários diferentes cenários, e cada nova aplicação possui suas próprias características erequisitos a serem validados antes que as aplicações se mostrem viáveis para serem em-barcadas e chegarem ao usuário final [3] [11] [10]. O processo de validação se tornamais complexo quando se trata de aplicações para a Internet das Coisas (IoT) por causade requisitos apresentados por redes com grande densidade de nós ou com alta mobili-dade [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 bancadaoferecem uma infraestrutura física similar ao cenário alvo para a execução de protótiposdas aplicações e coleta de informações de performance utilizados para avaliar o compor-tamento da aplicação antes que seja embarcados em dispositivos reais, assegurando quea aplicação funcionará como esperado e preencherá os requisitos estabelecidos, expondofalhas inesperadas a tempo de desenvolver correções. Já os simuladores são softwares quesimulam o comportamento de redes sem fio e fornecem mecanismos para a execução detestes e validação e análise de desempenho de novas aplicações.

Ambas abordagens possuem suas vantagens e desvantagens como métodos de vali-dação de aplicações para redes sem-fio. Os testes de bancada fornecem as vantagens deutilizarem equipamentos e ambientes reais, o que normalmente leva à resultados maisfies e consistentes, principalmente pois a aplicação desenvolvida e validada será a mesmautilizada para produção. Porém, alguns cenários são mais difíceis de replicar em testesde bacada, como por exemplo os cenários de alta mobilidade e alta densidade de nós. Oprimeiro pois os dispositivos de rede não possuem mecanismos autônomos para se movi-mentar e no segundo caso pois a quantidade de dispositivos a serem adquiridos para queo 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 nacomunicaçã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 am-biente, obtenção dos dados e são somente limitados pelos recursos computacionais, o quefacilita a criação de ambientes onde há uma grande densidade de nós [12]. As simulaçõesde ambientes com nós móveis também são facilitadas através da criação de scripts queautomatizem a movimentação dos nós. Porém, como a simulação é feita por software,

2 CAPÍTULO 1. INTRODUÇÃO

a aplicação desenvolvida para testes não é a mesma utilizada na produção, degradandoo a qualidade das validações e duplicando o esforço de desenvolvimento. Porém, ambasabordagem não fornecem sozinhas uma solução final para a validação de aplicações de re-des sem-fio. Isso se torna mais evidente quando as aplicações a serem validadas possuemrestrições específicas, principalmente para aplicações de IoT.

Portanto, a solução ideal para testes e análises de aplicações mais complexas deveoferecer, pelo menos: uma arquitetura híbrida, possibilitando a comunicação entre dispo-sitivos reais e virtuais em uma infraestrutura virtualizada; mesmo código utilizado duranteos testes em ambientes de simulação ou híbridos devem ser capazes de serem embarcadosem dispositivos reais; flexibilidade para customização que possibilite a criação de mode-los melhores e a adição de novos modelos para situações específicas e para suporte à novastecnologias; 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çãode Redes, chamado Linux Virtual Wireless Network (LVWNet).

1.1 ObjetivoPerante 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 Avali-ação de Redes sem-fio, LVWNet, e descrevendo o processo de simulações de aplicaçõesem ambientes híbridos utilizando código nativo para testes e para produção. Os testesvalidarão a eficácia e eficiência do LVWNet para aplicações de redes sem-fio com altamobilidade e alta densidade de nós.

1.2 Organização do TrabalhoO restante desse trabalho está organizado da seguinte maneira: no capítulo 2, levan-

tamento 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 pre-enchidas pelo LVWNet. O capítulo 3 detalha a proposta desse trabalho, o Ambiente deHíbrido para Avaliação de Redes Sem-fio, LVWNet, bem como o protocolo criado utili-zado para a comunicação entre os elementos de sua arquitetura. O capítulo 4 apresentaa metodologia de testes desenvolvida para a validação das características que o LVWNetse propõe a fornecer. No capítulo 6, são debatidos os resultados dos testes, o estado atualdo desenvolvimento e trabalho futuro previsto para a evolução do projeto. E, por fim, nocapítulo 7, conclusões e considerações finais com relação ao proposto por esse trabalho.

Capítulo 2

Visão Geral e Motivação

Enquanto as redes sem-fios avançam, novas tecnologias são propostas, testadas e en-tão, após o processo de validação, lançadas para serem embarcadas em dispositivos reaiscomo parte dos seus sistemas embarcados. A fase de validação é um processo importanteque garante que a tecnologia proposta se comportará como esperado e estará segura paraentrar em produção. Em outras palavras, se os resultados das simulações preencheremos requisitos, a aplicação usada para testes será então usada como base para desenvolveruma aplicação diferente que irá rodar na arquitetura alvo. Essa nova aplicação agora podeser testada em dispositivos reais ou, dependendo da acurácia dos modelos utilizados e daconfiabilidade dos testes, enviados diretamente para produção.

Por outro lado, softwares simuladores de redes tem seus pontos negativos, por exem-plo, para aplicações críticas os modelos de simulação podem não ser satisfatórios para ga-rantir que as simulações assegurem o seu correto funcionamento. Adicionalmente, proje-tar modelos para aquisição de informações de sensores IoT (e.g.: consumo de energia, me-mória, e poder de processamento) requerem análise analítica baseada em conhecimentomatemá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 deaquisição de peças de hardware e esforço humano [13]. Alternativamente, as simulaçõessão mais baratas e fornecem bons resultados com melhor custo-benefício para validar aperformance e a segurança das tecnologias propostas. Simulações são comumente utili-zadas para testar a capacidade planejada de redes e para testar se a aplicação cumpre osrequerimentos básicos [4]. Por outro lado, diferentes simuladores apresentam diferentescaracterísticas, que devem ser validados de modo a definir como escolher o melhor simu-lador para determinados requisitos. Existem basicamente duas características importantesoferecidas pelos simuladores de redes [5]:

• Reprodutibilidade – a aplicação deve ser facilmente traduzida de tecnologias detestes 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 tempogasto para desenvolver as aplicações de testes com o contraponto de que é neces-sário implementar a última versão de testes de sucesso em outra linguagem paraa versão final do produto. Esta é uma desvantagem pois diferentes tecnologias deprogramação podem ser incompatíveis e os programadores devem possuir habilida-des com todas as tecnologias envolvidas ou possuir uma equipe grande suficiente

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 mani-pular como os nós se conectam. Assim como devem também fornecer ferramentaspara modelagem e mudança de parâmetros de simulação e mecanismos para expor-tação de dados para observação e análise.

Alguns dos ambientes de simulação mais importantes para novas aplicações de IoT se-rão abordados nos próximos tópicos: Network Simulator 3 (NS-3), Wmediumd, e a FITIoT-Lab, este último sendo um ambiente para testes de bancada para pesquisa e será dis-cutido como uma alternativa além dos ambientes de simulação. Por fim, as desvantagensde todos os simuladores apresentados serão discutidas como motivação para a criação deum novo ambiente de simulação para validação e prototipagem de aplicações IoT, o LinuxVirtual Wireless Network (LVWNet).

2.1 NS-3O 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 redordo mundo que mantêm a vasta documentação online atualizada. O simulador ainda su-porta uma grande variedade de protocolos e permite simulações para tecnologias em redescabeadas 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 geren-ciar o comportamento dos nós, e scripts OTcl para controlar outros aspectos como porexemplo a topologia da rede em tempo real. A descontinuidade quando transitando dasimulaçã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 dadospara a extração de informações sobre as simulações [5] foram as principais motivaçõespara 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 eo NS-2: substituição da OTcl pelo Python como linguagem de programação oficial parascripts devido a Python ser uma linguagem de maior abrangência, de múltiplos propósitose 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 reagemgerando eventos que são armazenados em uma fila por tempo limitado, e então são pro-cessados pelo laço principal do simulador. Então, as simulações agem como uma máquinade 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 umprograma 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

2.2. WMEDIUMD 5

módulo, como demonstrado na Figura 2.1, que são carregados independentemente noscódigos fonte. O mesmo processo acontece para os códigos em Python. O módulo Com-mon implementa classes importantes como Packets, Packets Tags, Packet Headers, e asclasses Pcap/ascii para escrita em arquivos. O módulo Simulator implementa as classesque controlam o comportamento da simulação como Events, Scheduler e classes relaci-onadas a aritmética de tempo. Ambos os módulos são implementados sobre um móduloprincipal chamado Core, que implementa detalhes de baixo nível como variáveis aleató-rias, atributos, callbacks e rastreamento. Os módulos restantes adicionam característicasextras, como: modelos de mobilidade estática ou modelos de mobilidade baseados emrandom walk, filas, diferentes tipos de endereços (e.g.: IPv4, MAC), e funções da pilhaTCP/IP do Linux.

Figura 2.1: Módulos NS-3 em camadas.

2.2 WmediumdA 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 todosos 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]. Emoutras palavras, o núcleo, rodando no espaço do núcleo, gerencia as aplicações do espaçodo usuário e, cada vez que uma aplicação do espaço do usuário precisa de uma operaçãode CPU, ela deve requisitar ao núcleo invocando funções especiais chamadas chamadasde sistema.

Por outro lado, as chamadas de sistema tomam tempo para executar e, em sistemascríticos, a concorrência com outras aplicações de espaço de usuário forçam os processosa aguardar algum tempo para ser escalonadas e então processadas pela CPU. Então, algu-mas aplicações implementam seus códigos dentro do núcleo implementando seus códigospara rodar como parte integral do núcleo ou como Loadable núcleo Modules (LKM). Es-ses módulos podem ser carregados por demanda e seu código é agregado ao código donúcleo no espaço do núcleo. Como uma aplicação de espaço de núcleo, LKMs não nece-sitam de chamadas de sistema para ter acesso à CPU e possuem acesso direto memória donúcleo. Isso torna o desenvovimento de LKMs mais cuidadoso visto que problemas apre-sentados por aplicações de espaço de núcleo levam à inconsistência do seu funcionamentoe interrupção abrupta de suas funcionalidades. Por outro lado, o núcleo Linux implementauma funcionalidade que isola certos recursos do sistema, chamado de Namespaces. Após

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 re-cursos de rede (i.e.: pilha de rede, regras de roteamento, sockets), sendo possível tambémcriar várias interfaces virtuais de redes independentes [16], como ilustrado pela Figura2.2, onde os namespaces de rede Linux e seus próprios recursos e regras de roteamentopodem ser identificados independentemente, onde também está ilustrado uma instânciado processo Apache2 ligado ao socket 80/tcp para cada Namespace.

Namespace de rede #1

Processos:

Endereços IP:

Roteamento:

Namespace de rede #2

Processos:

Endereços IP:

Roteamento:

Namespace de rede #3

Processos:

Endereços IP:

Roteamento:

Namespace de rede #4

Processos:

Endereços IP:

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 paracriar interfaces de rede virtuais independentes sob demanda. O mac8022_hwsim possi-bilita simulações com qualquer número de interfaces IEEE 802.11, fazendo uso do fra-mework padrão IEEE 802.11, já que o mac802211_hwsim se comporta exatamente comouma placa de rede IEEE 802.11. Desse modo, mac802211_hwsim fornece as mesmascaracterísticas de cenários em testes de bancadas para desenvolvedores de tecnologias deredes sem-fios que não possuem recursos para construir tal cenário de testes, ou ondeos testes de bancada reais não são seguros suficientes para a aplicação alvo ou ainda, dealguma forma, infringem as leis em questão.

O mac802211_hwsim funciona lendo as comunidações de canais virtuais configura-dos 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. Interfacesvirtuais configuradas em outros canais não irão receber quadros de outros canais, comodemonstrado pela Figura 2.3.

Essa técnica é útil para simples simulações e nos testes de novos protocolos. Por outrolado, em simulações reais, mac80211_hwsim possui alguns problemas na implementaçãode modelos matemáticos para representar seguramente variáveis do mundo real, pelo mo-tivo de que ele somente encaminha os quadros de uma interface virtual para outra sem

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 Cozy-bit desenvolveu o Wmediumd, um emulador de mídia sem-fio que suporta o envio dequadros 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 domac80211_hwsim [6].

O Wmediumd age com um ataque "homem no meio", interceptando todo tráfego derede entre o espaço de núcleo e o espaço de usuário, inserindo taxas de erros nas transmis-sões, enviando quadros baseados na distância virtual entre os nós, e outras característicasde emulação. Esse processo é feito através da utilização da API (Application Program-ming Interface) chamada Netlink (Figura 2.4), uma estrutura projetada para transferirinformaçõ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]

8 CAPÍTULO 2. VISÃO GERAL E MOTIVAÇÃO

2.3 FIT IoT-LabSimuladores e emuladores são comumente utilizados para prototipagem de novos pro-

tocolos para IoT. Contudo, eles são apenas alternativas para testes de bancadas reais, quepossibilitam que as simulações se comportem exatamente com as mesmas característicasdos cenários onde a aplicação desenvolvida será aplicada. Para sobrepor esses desafiosprincipais, pesquisadores decidiram construir testes de bancadas ao redor do mundo paraoferecer uma plataforma representativa, em larga escala, para moldar, analisar e otimizarprotocolos, aplicações e serviços para IoT. Um dos mais importantes testes de bancadaatualmente é o FIT IoT-LAB [20] [8] que oferece acesso aberto para milhares de nóssem-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 eexperimentação para novas aplicações em IoT. IoT-LAB é parte do projeto FIT (FutureInternet of Things) [7] e é coordenada pela Universidade Pierre et Marie Curie e com-posta pela Inria, Icube laboratory da Universidade de Strasbourg, Institut mInes-Télécome CNRS. Os tipos disponíveis de nós são TI MSP430, ARM Cortex e ARM Cortex A8, eos 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 de-puraçã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 decomunicaçã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ãoDos 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çõesdevem ser feitos utilizando tecnologias específicas para as simulações, e não tecnologiascorrelatas às utilizadas para embarcar as aplicações. O desenvolvimento movido pelacomunidade dos modelos se demonstrou uma maneira razoável de estar em constanteevolução e de manter o projeto ativo, contudo esse processo pode levar a modelos nãoconfiáveis [19].

2.4. DISCUSSÃO 9

Figura 2.5: c©Inria: à esquerda WifiBot, à direita TurtleBot e no teto hardwares de IoT.

Os métodos utilizados pelo mac80211_hwsim e Wmediumd deixam o processamentodos 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 vistoque eles são tratados pelo núcleo da mesma maneira que seriam tratados caso fossemprovenientes de interfaces reais. Porém, falta ao Wmediumd a implementação de novosmodelos de mobilidade e a habilidade de interação entre interfaces virtuais e testes debancadas reais para a organização de ambientes híbridos flexíveis para testes e prototipa-gens. Esse módulo é parte importante da LVWNet e é utilizado na criação de interfacesde rede sem-fio virtuais.

Já o FIT IoT-LAB se mostra como uma alternativa interessante na tentativa forneceruma ambiente seguro para protótipos, caso o hardware alvo e o Sistema Operacional este-jam da lista de itens suportados. O projeto também oferece ferramentas para a análise dedados, robôs para mobilidade a uma vasta documentação incluindo documentos técnicospara 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 tem-peratura) não são gerenciáveis, dificultando a reprodução de cenários onde as condiçõesambientais sejam fatores limitantes. Além disso, como se trata de um teste de bancadacompartilhado com acesso aberto, não há garantia de que os recursos necessários estarãodisponíveis sempre que um teste precisar ser iniciado.

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

Capítulo 3

Proposta: Linux Virtual WirelessNetwork

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; co-municação direta entre nós; código criado em máquinas virtuais pode ser compilado eembarcado na maioria dos dispositivos sem-fios; registro dinâmico de nós, dispositivosvirtuais móveis, e uma arquitetura híbrida que possibilita dispositivos reais serem partede uma topologia virtual.

3.1 ArquiteturaA arquitetura do LVWNet é composta por dois elementos: nós sem-fios e um con-

trolador de topologia. Nós sem-fios podem ser tanto dispositivos reais, parte de umainfraestrutura configurada, quanto dispositivos virtuais, como máquinas virtuais Linuxhospedadas por um monitor de máquina virtual. Assim como o WMediumd, o LVWNetfoi projetado para rodar como um módulo, sendo composto por dois módulos: o lvw-net_node e o lvwnet_topology.

O controlador de topologia necessita que o mesmo barramento físico dos nós na topo-logia seja o mesmo, enquanto os nós LVWNet utilizam uma bridge Linux1 para comunicarcom outros nós e com o controlador de topologia, como ilustrado pela figura 3.1. Alémdisso, o controlador de topologia é responsável pela simulação da infraestrutura físicasem-fio, gerenciamento o registro dinâmico de nós novos e os mecanismos de suporte amobilidade dos nós virtuais e de nós reais na topologia virtual. Esse módulo necessita sercarregado antes de qualquer nó LVWNet.

Para a comunicação com dispositivos reais, a bridge Linux precisa ser conectada auma interface real que esteja conectada ao host, com suporte ao protocolo de comunicaçãoutilizado na simulação (e.g.: IEEE 802.11s). Portando, conectar nós LVWNet a um testede bancada real se torna tão simples quanto conectar o host monitor de máquina virtual

1Estruturas internas do Linux que operam na camada 2 do modelo OSI e possuem comportamentosimilar ao de um switch.

12 CAPÍTULO 3. PROPOSTA: LINUX VIRTUAL WIRELESS NETWORK

Nó deTopologia

NóLVWNet

NóLVWNet

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íbridafornecida 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 en-dereço MAC do controlador de topologia e o posicionamento 3-D virtual do nó. Esseposicionamento é utilizado pelo controlador de topologia para validar se o nó está apto aenviar 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çapara o nó, para que ele tenha os endereços de todos os seus vizinhos na topologia virtualque serão utilizados no envio direto de pacotes, sem a interferência do controlador detopologia.

A maioria dos parâmetros editáveis dos nós e do controlador de topologia são expor-tados através de sysfs2 [14] e alguns podem ser alterados, como por exemplo, o posicio-namento 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ãoenviada para o controlador de topologia que calculará a nova vizinhança e a enviará parapara os nós envolvidos.

O método utilizado para criar enlaces ponto-a-ponto3 entre dois nós é baseada napotência de transmissão, na sensibilidade de recepção e na distância entre os nós calculada

2Sistema de arquivos virtual fornecida pelo núcleo do Linux.3Um enlace ponto a ponto é formado quando dois nós estão comunicáveis um com o outro.

3.2. O PROTOCOLO LVWNET 13

pelas suas posições 3-D virtuais. O modelo utilizado é chamado de Perda de CaminhoLivre (Free-space Loss - FSL) [18] e é dado pela equação 3.1 onde D refere-se a distânciaeuclidiana (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ídoem versões futuras do LVWNet por modelos mais adequados.

LFS = 20log10

(4πD

λ

)(3.1)

D =√

x2 + y2 + z2 (3.2)

λ =cf

, c = 3×108m/s (3.3)

Com base nas equações 3.1, 3.2, e 3.3, a equação de FSL pode ser resumida por3.4, onde Srecep e Ptrans são respectivamente a sensitividade de recepção e potência detransmissão.

Srecep ≥ Ptrans −LFS (3.4)

3.2 O Protocolo LVWNetQuando um quadro IEEE 802.11 é enviado por uma aplicação, o módulo do lvw-

net_node intercepta o quadro, encapsula-o em um quadro IEEE 802.3 Ethernet com0x0808 como valor do campo tipo, hexadecimal utilizado para identificar quadros LVW-Net. Na recepção, o módulo lvwnet_node recebe todos os quadros IEEE 802.3 Ethernettipados como 0x0808 e desencapsula o quadro LVWNet. Então, após o processamentodo quadro LVWNet, o quadro é injetado novamente na pilha de rede do núcleo para serprocessado naturalmente pelo núcleo, como se estivesse sendo recebido por uma interfacede 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 dispositivoscarrega a posição dos dispositivos, potência de transmissão, sensitividade de recepção, e ocanal de transmissão utilizado, como demonstrado pela Figura 3.4. Essa mensagem é en-viada por qualquer nó LVWNet que deseje fazer parte da topologia LVWNet. Após enviaressa mensagem, o nó aguarda uma mensagem do controlador de topologia contendo osendereços de seus vizinhos. Então, todas as mensagens podem ser entregues diretamenteentre os nós participantes e seus respectivos vizinhos. A Figura 3.5 ilustra o processo deregistro dinâmico.

14 CAPÍTULO 3. PROPOSTA: LINUX VIRTUAL WIRELESS NETWORK

App pede para o núcleo enviar

lvwnet_node en-capsula em umEthernet e envia

80211 recebe os dadosnormalmente

lvwnet_node rece- be 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 deenlace ponto-a-ponto é enviada do controlador de topologia para os nós LVWNet. Essamensagem 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 camadassuperiores, processo ilustrado em Figura 3.6.

3.3 Estado Atual e Desenvolvimento FuturoCom 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 umamelhor visualização dos resultados das simulações, um modelo de erro para simplificaçãoda interferência ambiental na propagação do sinal, um modelo de consumo de energiapara melhorar a análise de sensores remotos, e finalmente, o suporte para os protocolosmais adequados para o IoT.

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 importantenas avaliações de aplicações. Os dados exportados por simuladores de rede precisam serlegíveis e facilmente manipulados. Assim, a modelagem desta extensão pode ajudar osdesenvolvedores a usar o LVWNet para analisar mais profundamente o comportamentodas aplicações em execução no ambiente de simulação. Inicialmente, os dados exportadosestão relacionados ao uso de recursos internos e uso de rede:

• Carga na largura de banda da interface – uma porcentagem da largura de banda totalsendo 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

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 ManagementProtocol (SNMP), APIs REST e XML.

3.3.2 Modelo de ErrosO 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 de-gradam o sinal e causam erros de transmissão. Para obter resultados mais confiáveis, osimulador precisa emular o meio com modelos de erros precisos, imitando o que acon-teceria em cenários reais. Assim, para a maioria dos cenários IoT (por exemplo, cidadesinteligentes), 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 errosexternos na transmissão do nó LVWNet. Inicialmente, o modelo oferecerá a possibili-dade de erros nas transmissões, individualmente para cada lvwnet_node. A implemen-tação desta extensão permitirá trabalhos futuros a implementar modelos mais complexosde adição de erros por mudanças nas características ambientais. As informações estatísti-cas sobre os erros de transmissão inferidos pelo simulador estarão disponíveis através daextensão da exportação de dados.

3.3.3 Modelo de Consumo de EnergiaA 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 precisamde sua própria fonte de energia (ou seja, baterias de lítio, células solares). Alguns recursosimplementados por aplicativos e protocolos consomem energia de sensores, reduzindo avida útil dos dispositivos. Uma solução viável para este problema é diminuir o consumode 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 oconsumo de energia dos dispositivos virtuais por meio de modelos confiáveis para avaliarde forma segura aplicativos ou protocolos de WSNs. Assim, esta extensão permitirá queo 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ãode exportação de dados.

3.3.4 Suporte ao IEEE 802.15.4Atualmente, 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, chamado802.11ah [1], apesar de que o protocolo que melhor se adaptam à maioria das aplicaçõesIoT serem o IEEE 802.15.4 (ZigBee) [22] e o protocolo LoRa [2].

Capítulo 4

Preparação do Ambiente

Atualmente, o LVWNet é um simulador redes sem-fio voltado para a simulação deaplicações IoT capaz de comunicar nós virtuais com equipamentos reais dentro da mesmaestrutura virtual. Além disso, o simulador oferece suporte à mobilidade e associaçãodinâmica de nós, com consumo reduzido de recursos, possibilitando melhor simulaçãode ambientes de alta densidade e também oferece alta escalabilidade visto que é possívelagregar 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ódigofoi disponibilizado no github (https://github.com/lodantas/lvwnet) e seu desenvolvimentoestá aberto para colaboração. O repositório é composto pelos diretórios listados na tabelaabaixo (Tabela 4.1):

Além disso, uma série de scripts foram criados para melhor administrar tanto os nóscontroladores quanto os nós sem-fio virtuais. Esses scripts são versões iniciais utilizadassomente em ambientes de teste do LVWNet e futuramente serão melhorados e agrega-dos às funcionalidades internas do LVWNet. Os scripts estão descritos na tabela abaixo(Tabela 4.2):

4.1 Preparando o AmbienteO LVWNet foi estritamente desenvolvido para Linux, e todos os testes foram executa-

dos 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 pri-meiros testes e a única completamente suportada na versão atual do LVWNet para virtu-alização foi a Qemu/KVM, que pode ser instalada em sistemas Fedora com o comandoabaixo (Código 4.1):

1 # su −c " dnf 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 carregadosno núcleo do Fedora 25. Para executar o download do código mais recente do projetodisponí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 wne t . g i t

Após efetuar o download, serão necessários alguns programas e dependências paraa compilação e carregamento dos módulos LVWNet (lvwnet_node e lvwnet_controller).

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-storageContêiner de armazenamento do monitor de máquina virtuallibvirt (padrão) onde estão localizadas as máquinas virtuais.

/lvwnet/inboxDiretório onde estão os arquivos de configuração dos nós.Cada arquivo possui parâmetros necessários para a execuçãodos nós e que podem ser manipulados.

/lvwnet/outboxDiretório onde estão os arquivos de configuração dos nósapós serem processados (evita que dois nós utilizem o mesmoarquivo).

/lvwnet/inbox/template

Conjunto de arquivos que auxiliam na criação de novosarquivos de configuração em lote (editar o arquivo generate.shpara mudar parâmetros como, por exemplo a posição máximados nós.

/lvwnet/modulesMódulos lvwnet_node.ko e lvwnet_controller.ko que serãoexecutados 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 descritonos Códigos 4.1 e 4.1. Outras distribuições podem seguir o mesmo padrão com algumasespecificidades e alterações pontuais.

1 # dnf 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 −modulesr 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 hmacca lc n c u r s e s−d e v e l newt−d e v e l numact 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 xml to python−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 umaControladora LVWNet, o módulo lvwnet_controller, e quando se tratar de um nó LVW-Net, lvwnet_node. Esse processo pode ser executado tanto em equipamentos reais quantoem máquinas virtuais, desde que todas os nós estejam conectadas à mesma LAN.

1 # cd . / l vw ne t2 # insmod modules / mac80211 . ko3 # insmod modules / l vw ne 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}4 # insmod modules / lvwne t_node . ko \5 e t h e r n i c _ n a m e =${NIC} \

4.1. PREPARANDO O AMBIENTE 19

Tabela 4.2: Diretório /lvwnet/scriptsScripts em /lvwnet/scripts Descrição

create_clones.sh

Script que cria clones a partir do domínio template01_lvwnet_f25 (sempre manter esse domínio desligado).Para alterar a quantidade de clones, alterar a variávelnumber_of_clones.

shutdown_all_nodes.sh Envia um pedido de desligamento para todos os nós virtuais.

poweroff_all_nodes_forced.shEnvia 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.shCancela o registro do libvirt e remove o disco de todos os nós,exceto o nó template template01_lvwnet_f25.

load_controller_at_all.shCarrega todos os módulos necessários para o controllere para o nó físico.

unload_controller.shDescarrega todo os módulos necessários para o controllere para o nó físico.

init_controller.shScript executado pelo load_controller_at_all paracarregar somente o controlador LVWNet.

init.shScript que é executado por todos os nós virtuais quandosão ligados. Aqui é possível colocar tarefas para seremexecutadas imediatamente quando ele é inicializado.

6 c t r l _ h o s t _ a d d r =${MAC_CONTROLLER} \7 x_pos=${X_POS} \8 y_pos=${Y_POS} \9 z_pos =${Z_POS} \

10 i s _ c o n t r o l l e r =0 \11 power_tx_dbm=${POWER_TX_DBM} \12 sens_rx_dbm=${SENS_RX_DBM}

4.1.1 Ambiente Totalmente Virtual

Em casos onde a simulação totalmente virtual é mais interessante (Qemu/KVM) (Fi-gura 3.1), templates devem ser criados para suportar alterações em uma grande quantidade

20 CAPÍTULO 4. PREPARAÇÃO DO AMBIENTE

de nós facilitando sua implantação, principalmente para ambientes onde haja uma grandedensidade 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 con-trolar os nós, ou seja, o processo pode ser executado manualmente sem a necessidade dosscripts.

4.1.2 Ambiente HíbridoEm casos onde se deseja validar aplicações IoT em ambientes híbridos, faz-se neces-

sária a conexão do monitor de máquina virtual (Qemu/KVM) com os nós reais (Figura3.2). Porém, o processo é o mesmo seguindo a instalação das dependências (Código4.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 MobilidadeO 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, umafunçã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 aestrutura se reorganiza. Essa técnica foi pensada para facilitar que scripts possam alteraras posições dos nós facilmente, tornando as simulações mais fáceis e a obtenção de dadosmais ágil.

Capítulo 5

Experimentos e Resultados

A análise e a validação do LVWNet foram avaliadas através de um cenário híbridocom dois dispositivos virtuais, o controlador de topologia e um dispositivo real. Emborao LVWNet possa ser usado em dispositivos reais, devido aos benefícios fornecidos pelavirtualização, recomenda-se o uso de máquinas virtuais leves para facilitar a criação denovos nós. O monitor de máquina virtual usado neste trabalho foi o Virtual Machinebaseado em núcleo, KVM, com núcleo com memória compartilhada que permite o com-partilhamento de memória entre as máquinas virtuais. Cada máquina virtual foi criadacom 256 MB de memória RAM e um processador genérico de um núcleo. O dispositivoreal usou uma interface sem fio Intelbrás WBN900 USB, que suporta o protocolo IEEE802.11s - usado para testar a comunicação entre os dispositivos usando a infraestruturasem fio fornecida pelo LVWNet.

Tabela 5.1: Dispositivos criados.Endereço MAC Posição (m)ID Tipo Ethernet (ens9) WLAN (wlan0) IPv4 x y z

1 Virtual aa:aa:aa:00:01:01 02:00:00:00:01:01 10.1.1.11/8 500 500 102 Virtual aa:aa:aa:00:01:02 02:00:00:00:01:02 10.1.1.12/8 600 1300 103 Virtual aa:aa:aa:00:01:03 02:00:00:00:01:03 10.1.1.13/8 1200 500 104 Real fe:54:00:32:3d:dc 00:1a:3f:a5:74:e7 10.1.1.99/8 700 800 10

5.1 Comunicação em um Ambiente Híbrido

Os dispositivos virtuais foram definidos com 20 dBm de potência de transmissão e -75dB de sensibilidade de recepção visto que esses valores são comuns nas comunicações deredes sem-fios IEEE 802.11s. Isso resulta em transmissões com -95 dB a uma distânciamáxima de aproximadamente 556 metros 3.4. O dispositivo real foi posicionado paraestabelecer dois enlaces dos nós, com os dispositivos virtuais 1 e 2. O dispositivo virtual3 no início está posicionado além do limite para a transmissão de outros dispositivospropositalmente para testar o registro dinâmico de dispositivos e mobilidade.

22 CAPÍTULO 5. EXPERIMENTOS E RESULTADOS

Figura 5.1: Terminal no dispositivo 4.

5.2 Mobilidade e Registro Dinâmico de NósDepois 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 comseus vizinhos, conforme ilustrado pela Figura 5.1. Para testar a simulação de dispositivosmóveis, iniciamos o dispositivo virtual 3 sem enlaces dos nós e o transferimos para 6marcos 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élulasverdes demarcam enlaces ponto-a-ponto estabelecidos.

Dispositivo 3 Dispositivo 1 Dispositivo 2Marco x(m) y(m) z(m) Signal (dBm) Distância (m) Enlaces Sinal (dBm) Distância (m) Enlaces ponto-a-ponto

1 1200 500 10 -97 700 -100 10002 700 500 10 -86 200 x -98 8063 900 700 10 -93 447 x -96 6704 700 800 10 -91 360 x -94 509 x5 900 1300 10 -99 894 -89 300 x6 900 1800 10 -99 894 -89 300 x

O estado dos enlaces dos nós foi calculado usando a equação 3.4, e foram estabele-cidos quando os dispositivos estavam próximos o suficiente, baseado em seu poder detransmissão e sensibilidade de recepção. A figura 5.2 ilustra o movimento do dispositivo3 nas dimensões x e y, o alcance do rádio dos dispositivos 1 e 2 e 6 marcos.

5.3 Consumo de RecursosO LVWNet foi desenvolvido com intuito de fornecer grande escalabilidade, princi-

palmente pensando em fornecer capacidade de simulação de aplicações com grande den-sidade de nós, e também para que não houvesse nenhum impacto de performance nassimulações. Para alcançar isso, o simulador foi desenvolvido para consumir a menorquantidade de recursos computacionais (Memória, CPU e Rede) possível. Para mensu-rar os recursos consumidos foram executados testes com a criação de 50 nós LVWNet eforam amostras dos recursos foram coletados durante o processo de criação e funciona-mento básico do simulador. Cada amostra foi coletada 10 vezes e a média foi utilizadapara 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

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 1GHze 256 GB de memória RAM.

Como pode ser observado na Figura 5.3, o consumo de processamento aumentou con-forme os nós iam sendo criados, como esperado. Porém o impacto de 50 nós não chegoua 1% do poder de processamento da CPU do monitor de máquina virtual. Nessas configu-raçõ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, alo-car 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áquinavirtual 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 de320 MB de memória por nó LVWNet. Por fim, o consumo de largura de banda causadopela 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 dadosrecebidos (RX) e 1.076 kb de dados transmitidos (TX) pela controladora LVWNet. Essevalor é muito pequeno e comprova que o impacto na comunicação entre os nós é irrisórioe não afeta a performance das simulações em geral.

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).

Capítulo 6

Conclusão

Neste trabalho foram discutidos problemas na avaliação de aplicações para redes sem-fios, 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ãotão importantes hoje em dia, apesar de carecem de recursos para atender aos requisitos erestrições de aplicações sem-fio mais complexas. Como motivação, foram discutidos pro-blemas de alguns dos mais importantes e relevantes simuladores de redes: NS-3, WMe-diumd e FIT IoT-LAB, cada um representando um tipo especial de simulador e enquantoforam discutidas suas desvantagens.

A proposta desse trabalho foi apresentada na sequência, o LVWNet, onde foi descritaa sua importância como uma alternativa para a criação de testes híbridos para aplicaçõesIoT 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, umcontrolador de topologia centralizado, comunicações diretas entre nós, o código criadopara máquinas virtuais pode ser compilado de forma cruzada para dispositivos reais e dearquitetura 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 umsimulador de rede para aplicativos IoT e avaliação detalhada de tecnologias de redes semfio.

Para a validação das funcionalidades do LVWNet, foram executados dois tipos detestes, um envolvendo mobilidade de nós em um ambiente híbrido, onde um nó se mo-vimentava através de uma infraestrutura híbrida enquanto enlaces se formaram com osdiferentes nós com base nos modelos utilizados para o cálculo do alcance do rádio. OLVWNet se comportou como esperado e demonstrou estar em conforme com o compor-tamento que seria demonstrado em um cenário real de produção. Além disso, todos oscódigos foram embardados em dispositivos reais sem nenhuma alteração com relação aoscódigos utilizados nos nós virtuais. O segundo teste foi um teste de carga onde foi dimen-sionado o processo de criação excessiva de nós visando a simulação de um ambiente comalta densidade onde o LVWNet se comportou como esperado, tendo como únicos fatoreslimitantes os recursos computacionais.

Portanto, o LVWNet é, atualmente, uma alternativa muito interessante para alcançarsimulaçõ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 equipamentosreais, diminuindo o tempo de execução de testes e otimizando a mão de obra dos desen-

26 CAPÍTULO 6. CONCLUSÃO

volvedores. Além disso, oferece a capacidade de simulação híbrida, onde equipamentosreais podem fazer parte de um ambiente virtual, interessante para cenários de difícil si-mulação como dispositivos de alta mobilidade ou para analisar o comportamento de umequipamento 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 umasolução para cenários onde é necessário simular uma grande quantidade de nós. Por fim, oLVWNet é um projeto recente porém com grande potencial, que precisa ser desenvolvidoe aprimorado. O desenvolvimento das extensões discutidas no início deste trabalho é opróximo passo para alcançar maturidade necessária para se tornar um importante simula-dor de rede, especializado em avaliações IoT complexas.

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 Com-munications 21(6), 144–152.

[2] Augustin, Aloÿs, Jiazi Yi, Thomas Clausen and William Mark Townsley [2016], ‘Astudy of lora: Long range & low power networks for the internet of things’, Sensors16(9), 1466.

[3] Bhushan, Naga, Junyi Li, Durga Malladi, Rob Gilmore, Dean Brenner, AleksandarDamnjanovic, Ravi Sukhavasi, Chirag Patel and Stefan Geirhofer [2014], ‘Networkdensification: the dominant theme for wireless evolution into 5g’, CommunicationsMagazine, IEEE 52(2), 82–89.

[4] Bilalb, Sardar M, Mazliza Othmana et al. [2013], ‘A performance comparison ofnetwork simulators for wireless networks’, arXiv preprint arXiv:1307.4129 .

[5] Chaudhary, Rachna, Shweta Sethi, Rita Keshari and Sakshi Goel [2012], ‘A study ofcomparison of network simulator-3 and network simulator-2’, IJCSIT) InternationalJournal 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 amature campus-wide wireless network’, Computer Networks 52(14), 2690–2712.

[11] Jain, Kamal, Jitendra Padhye, Venkata N Padmanabhan and Lili Qiu [2005], ‘Im-pact of interference on multi-hop wireless network performance’, Wireless networks11(4), 471–487.

[12] Jin, Jiong, Jayavardhana Gubbi, Slaven Marusic and Marimuthu Palaniswami[2014], ‘An information framework for creating a smart city through internet ofthings’, Internet of Things Journal, IEEE 1(2), 112–121.

27

28 REFERÊNCIAS BIBLIOGRÁFICAS

[13] Khan, Atta R, Sardar M Bilal and Mazliza Othman [2012], A performance compari-son 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 Kerneland C Library, "O’Reilly Media, Inc.".

[15] Martínez Illán, Alberto [2013], Medium and mobility behaviour insertion for 802.11emulated networks, Dissertação de mestrado, Universitat Politècnica de Catalunya.

[16] Nakauchi, Kiyohide [2010], Introduction to network virtualization technologies infuture 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 Raoand Brian Zill [2005], Estimation of link interference in static multi-hop wirelessnetworks, em ‘Proceedings of the 5th ACM SIGCOMM conference on Internet Me-asurement’, USENIX Association, pp. 28–28.

[18] Phillips, Chris, Douglas Sicker and Dirk Grunwald [2013], ‘A survey of wirelesspath loss prediction and coverage mapping methods’, Communications Surveys &Tutorials, IEEE 15(1), 255–270.

[19] Rampfl, Sebastian [2013], Network simulation and its limitations, em ‘Proceedingzum Seminar Future Internet, Innovative Internet Technologien und Mobilkommu-nikation 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 Inter-national Conference on Distributed Computing in Sensor Systems’, IEEE, pp. 263–268.

[21] Watteyne, Thomas, Xavier Vilajosana, Branko Kerkez, Fabien Chraim, Kevin Wee-kly, Qin Wang, Steven Glaser and Kris Pister [2012], ‘Openwsn: a standards-basedlow-power wireless development environment’, Transactions on Emerging Telecom-munications Technologies 23(5), 480–493.

[22] Zanella, Andrea, Nicola Bui, Angelo Castellani, Lorenzo Vangelista and MicheleZorzi [2014], ‘Internet of things for smart cities’, IEEE Internet of Things Journal1(1), 22–32.