Extensões ao Projeto LVWNet: Mobilidade, interação com equipamentos reais, comunicação direta, e registro dinâmico de nós

Transcrição

1 Universidade Federal do Rio Grande do Norte Centro de Ciências Exatas e da Terra Departmento de Informática e Matemática Aplicada Programa de Pós-Graduação em Sistemas e Computação Mestrado Acadêmico em Sistemas e Computação Extensões ao Projeto LVWNet: Mobilidade, interação com equipamentos reais, comunicação direta, e registro dinâmico de nós Leonardo Dantas de Oliveira Natal-RN Junho de 2014

2 Leonardo Dantas de Oliveira Extensões ao Projeto LVWNet: Mobilidade, interação com equipamentos reais, comunicação direta, e registro dinâmico de nós Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Sistemas e Computação. Linha de pesquisa: Sistemas Distribuídos Orientador Dr. Marcos César Madruga Alves Pinheiro PPgSC Programa de Pós-Graduação em Sistemas e Computação DIMAp Departamento de Informática e Matemática Aplicada CCET Centro de Ciências Exatas e da Terra UFRN Universidade Federal do Rio Grande do Norte Natal-RN Junho de 2014

3 Dissertação de Mestrado sob o título Extensões ao Projeto LVWNet: Mobilidade, interação com equipamentos reais, comunicação direta, e registro dinâmico de nós apresentada por Leonardo Dantas de Oliveira e aceita pelo Programa de Pós-Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte, sendo aprovada por todos os membros da banca examinadora abaixo especificada: Dr. Marcos César Madruga Alves Pinheiro Presidente DIMAp Departamento de Informática e Matemática Aplicada UFRN Universidade Federal do Rio Grande do Norte Dr. Augusto José Venâncio Neto Examinador DIMAp Departamento de Informática e Matemática Aplicada UFRN Universidade Federal do Rio Grande do Norte Dr. Flávio de Oliveira Silva Examinador Externo à Instituição FACOM Faculdade de Computação UFU Universidade Federal de Uberlândia Natal-RN, 05 de Junho de 2014.

4 UFRN / Biblioteca Central Zila Mamede Catalogação da Publicação na Fonte Oliveira, Leonardo Dantas de. Extensões ao projeto LVWNet: mobilidade, interação com equipamentos reais, comunicação direta, e registro dinâmico de nós. / Leonardo Dantas de Oliveira. Natal, RN, f.: il. Orientador: Prof. Dr. Marcos César Madruga Alves Pinheiro. Dissertação (Mestrado) Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Programa de Pós -Graduação em Sistemas e Computação. 1. Wireless Dissertação. 2. Posicionamento - Dissertação. 3. IEEE Dissertação. 4. LVWNet Dissertação. 5. Free-space Dissertação. 6. Path Loss Dissertação. 7. Linux Dissertação. 8. Testbed Dissertação. 9. Prototipação Dissertação. I. Pinheiro, Marcos César Madruga Alves. II. Universidade Federal do Rio Grande do Norte. III. Título. RN/UF/BCZM CDU 004.7

5 A minha esposa Karla e minha filha Rebecca, pela compreensão nesses dias de ausência.

6 Agradecimentos Primeiro a Deus, por ter me dado saúde e força para superar as dificuldades. Ao meu orientador, Dr. Marcos Madruga, pelo empenho ímpar dedicado à elaboração deste trabalho. Aos professores Dr. Augusto Venâncio e Dr. Flávio de Oliveira pelo paciente trabalho de revisão e avaliação e por suas importantíssimas sugestões. A Marcos Luporini e Juliano Prado, pelos mecanismos que foram essenciais para a elaboração desse trabalho. Também à comunidade ao redor do Linux, que com sua excelente organização, provê toda a documentação e ferramental necessário para o seu uso.

7 O medo não é algo ruim, ele lhe mostra suas fraquezas. Gildarts Clive

8 Extensões ao Projeto LVWNet: Mobilidade, interação com equipamentos reais, comunicação direta, e registro dinâmico de nós Autor: Leonardo Dantas de Oliveira Orientador: Prof. Dr. Marcos César Madruga Alves Pinheiro Resumo Com o crescimento constante da utilização de redes sem fio em ambientes domésticos, empresariais e até industriais, aparecem novos desafios. A prototipação de novos protocolos nesses ambientes tipicamente é restrita a ambientes de simulação, onde existe a necessidade de uma dupla implementação, uma no ambiente de simulação, onde se realiza uma prova de conceito inicial e outra em um ambiente real. Além disso, uma vez que se parta para ambientes reais, não é trivial a criação de um testbed para redes sem fio de alta densidade, dada a necessidade de uso de vários equipamentos reais, e uso de atenuadores, redutores de potência, para tentar reduzir o espaço físico necessário para criação desses laboratórios. Nessa lacuna, o projeto LVWNet (Linux Virtual Wireless Network) foi inicialmente concebido para criação de testbeds completamente virtuais para redes IEEE sobre o sistema operacional Linux. Este trabalho tem como objetivo extender o atual projeto LVWNet adicionando a ele os recursos de possibilitar a interação com hardwares wireless reais, dar um suporte inicial à mobilidade através do posicionamento dos nós em um ambiente de coordenadas no espaço baseado em metros, já com cálculos de perda decorrente da atenuação em espaço livre, aumentar a escalabilidade com a criação de um mecanismo que permita a comunicação direta entre os nós sem necessidade de um host intermediário além do registro dinâmico de nós, de modo que novos nós podem ser inseridos na rede com a mesma já em operação. Palavras-chave: Posicionamento, IEEE , LVWNet, Free-space Path Loss, Wireless, Linux, Testbed, prototipação.

9 Extensions of LVWNet project: mobility, interaction with real hardware, direct communication and dynamic registration of nodes Author: Leonardo Dantas de Oliveira Supervisor: Dr. Marcos César Madruga Alves Pinheiro Abstract Due to the constantly increasing use of wireless networks in domestic, business and industrial environments, new challenges have emerged. The prototyping of new protocols in these environments is typically restricted to simulation environments, where there is the need of double implementation, one in the simulation environment where an initial proof of concept is performed and the other one in a real environment. Also, if real environments are used, it is not trivial to create a testbed for high density wireless networks given the need to use various real equipment as well as attenuators and power reducers to try to reduce the physical space required to create these laboratories. In this context, LVWNet (Linux Virtual Wireless Network) project was originally designed to create completely virtual testbeds for IEEE networks on the Linux operating system. This paper aims to extend the current project LVWNet, adding to it the features like the ability to interact with real wireless hardware, provides a initial mobility ability using the positioning of the nodes in a space coordinates environment based on meters, with loss calculations due to attenuation in free space, enables some scalability increase by creating an own protocol that allows the communication between nodes without an intermediate host and dynamic registration of nodes, allowing new nodes to be inserted into in already in operation network. Keywords: IEEE , LVWNet, LFS, Wireless, Linux, Testbed, Prototyping.

10 Lista de figuras 1 IEEE e o modelo de referência OSI de 7 camadas p Problema do hidden terminal em redes CSMA/CA p Conexões de uma rede mesh 3 x 3 conforme visto pelas máquinas virtuais. p Conexões reais de uma rede mesh 3 x 3 criada pelo LVWNet p Cabeçalho LVWNet usado para registro do nó p Cabeçalho LVWNet usado para informar um nó das configurações dos seus vizinhos p Disposição dos nós do diagrama de troca de mensagens da figura 8... p Diagrama de troca de mensagens com os nós 01, 02 e 03 alcançáveis entre si p Disposição dos nós do diagrama de troca de mensagens da figura 10.. p Diagrama de troca de mensagens com os nós 01, 02 alcançáveis entre si, nós 03 e 04 também, mas não entre eles p Diagrama de sequência de chamadas de funções entre os módulos mac80211 e lvwnet_node p Amostra de tráfego do tipo data capturado na ethernet p Definindo a interface real como sendo do tipo mesh p Peer links do host real com as máquinas virtuais p Teste básico de conectividade e tabela de encaminhamento layer 2... p Estado do nó 03 no milestone 01 (sem nenhum peer link) p Estado do nó 03 no milestone 02 (peer link com o nó 01) p Estado do nó 03 no milestone 04 (peer link com o nó 01 e nó 02).... p. 70

11 19 Estado do nó 03 no milestone 05 (peer link com o nó 01 e nó 02). O peer link com o nó 01 está aguardando ser excluído p Estado do nó 03 no milestone 05 (peer link com o nó 02). O peer link com o nó 01 foi excluído após 1800 segundos p Caminho percorrido pelo nó 03 entre os 6 milestones p. 71

12 Lista de tabelas 1 Endereços MAC Ethernet e WLAN dos nós para teste de inserção de um nó real p Posições iniciais dos nós virtuais e do real p IPs e endereços MAC ethernet e WLAN dos nós p Posições iniciais dos nós p Posições de cada um dos milestones do nó p. 68

13 Lista de abreviaturas e siglas ARP Address Resolution Protocol IEEE Institute of Electrical and Electronics Engineers LVWNet Linux Virtual Wireless Network MAC Media Access Control PHY Physical Layer STA Station LLC Logical Link Control ISM Industrial, Scientific and Medical ITU-R International Telecommunication Union - Radiocommunication Sector DSS Digital Spread Spectrum OFDM Orthogonal Frequency Division Multiplexing MIMO Multiple-Input Multiple-Output BSA Basic Service Area BSS Basic Service Set AP Access Point DS Distribution System ESA Extended Service Area ESS Extended Service Set WPA WiFi Protected Access WEP Wired Equivalent Privacy CSMA/CA Carrier Sense Multiple Access/Collision Avoid CSMA/CD Carrier Sense Multiple Access/Collision Detect

14 NAV Network Allocation Vector ESS-Mesh Extended Service Set Mesh BSS Basic Service Set AP Access Point MP Mesh Point MBSS Mesh Basic Service Set HWMP Hybrid Wireless Mesh Protocol PREQ Path Request PREQ Path Reply RANN Root Announcement MLME Media Access Control Sublayer Management Entity TSF Timing Synchronization Function KVM Kernel Virtual Machine KSM Kernel SamePage Merging FSL Free Space Loss ACK Acknowledgement

15 Lista de Códigos 5.1 Struct da mensagem de registro do LVWNet p Apontador do payload do skb para o struct da mensagem de registro.. p Struct da mensagem de informações de vizinhos do LVWNet p Registro do ethertype 0x0808 e sua função manipuladora..... p Exemplo de como carregar o módulo lvwnet_node p. 61 A.1 git clone do projeto LVWNet p. 78 A.2 Executando o make do projeto LVWNet p. 79 A.3 Executando o make da versão modificada do mac p. 79

16 Sumário 1 Introdução p Motivação p A importância de implementar o posicionamento dos nós no espaço p A importância de integrar uma rede IEEE real com uma virtual p Objetivos p Organização do trabalho p Fundamentação Teórica p O protocolo IEEE p Camada Física p Definições do IEEE p Camada MAC p O protocolo IEEE s p O Módulo mac p Trabalhos Relacionados p Network Simulator p Projeto NCTUns p Projeto mac80211_hwsim p Projeto Wmediumd p Visão Geral do Projeto LVWNet p. 35

17 4.1 LVWNet original p Máquina controladora de topologia p Nó participante da rede p Hypervisor p Componentes Modificados do LVWNet p Posicionamento dos nós no espaço p Protocolo de Registro e Informações dos Nós p Mensagem de registro de nós p Mensagem de informações de nós p Diagramas de trocas de mensagens p Caso 1: 3 nós são alcançáveis entre si p Caso 2: Nó 01 e 02 são alcançáveis entre si, nós 03 e 04 também, mas não entre eles p Interação da rede LVWNet Virtual com hardwares reais..... p Detalhes de Implementação p Ingresso de máquinas com hardware sem fio real em uma rede LVWNet p Tomadas de decisões para o projeto p Implementação p A pilha de rede do Linux p Módulo mac80211 modificado p Módulo lvwnet_node p Módulo lvwnet_controller p O protocolo de registro e informações de nós na rede p O processo de registro dos nós p O protocolo de informações sobre vizinhos p Comunicação direta entre os nós p. 57

18 5.5 Uso dos Módulos p Carga dos módulos p Informações disponbilizadas via sysfs p Análise do LVWNet p Criação automática de peer links com dispositivos reais p Simulação de mobilidade de um nó p Considerações finais p Principais contribuições p Limitações p Trabalhos futuros p Mobilidade p Modificação do radiotap no quadro IEEE p Uso de erro e latência na transmissão de quadros p Uso de replay de quadros para uso de máquinas sem modificação p. 74 Referências p. 75 Apêndice A -- Download e Compilação do Projeto LVWNet p. 78

19 18 1 Introdução Iniciada em 1997, a especificação do protocolo IEEE permitiu uma inovação até então reservada a protocolos fechados: a mobilidade à uma razoável largura de banda. Desde então, o seu uso cresceu de forma que hoje não é mais possível imaginar um mundo sem um protocolo aberto de comunicação sem fio. Contudo, junto com novas facilidades surgem novos desafios. Hoje temos adendos ao IEEE que permitem velocidades acima de até 1 Gbp/s em redes sem fio (NOJIMA et al., 2012), além de protocolos que permitam extender a rede além do controle centralizado, utilizando técnicas Ad-Hoc auto organizáveis, como por exemplo o IEEE s, que será visto com um pouco mais de detalhes no próximo capítulo. Testes de validação e robustez destes protocolos são razoavelmente fáceis de se realizar para uma pequena quantidade de nós, contudo, como pode-se imaginar, essa dificuldade cresce a medida que é necessário realizar testes em escala maior. Atualmente, para testarmos novos protocolos, podemos recorrer a sistemas de simulação, onde é possível criar sua implementação nesse mesmo ambiente, e realizar testes em escalas maiores. Contudo, quando precisamos testar as implementações desses protocolos em ambientes reais, ou seja, fora da simulação, ainda caimos no problema anterior de custo e espaço. Além disso, o código escrito para um simulador dificilmente é totalmente aproveitado para um equipamento real, havendo a necessidade de sua reescrita. Existem alguns trabalhos que permitem a emulação de protocolos, embora quase todos em ambientes muito controlados, com várias limitações sob este ambiente. No capítulo de trabalhos relacionados serão mostrados alguns desses trabalhos e como eles se relacionam com o LVWNet. Hoje, com a facilidade de criação de máquinas virtuais através de hypervisors e hardwares já prontos e preparados para virtualização, entendemos que uma boa estratégia é utilizar esse poder computacional para criar um ambiente de testes. Desse modo, pode-se utilizar máquinas virtuais para realizar os testes de protocolos e suas implementações em

20 19 ambientes o mais próximos possível da realidade. Com essa proposta, em 2011 surgiu o projeto LVWNet, que tinha como objetivo inicial o uso de redes IEEE s em máquinas virtuais. O LVWNet cria uma placa de rede sem fio virtual IEEE s e emula o comportamento do meio físico sem fio, de modo que para toda a pilha IEEE é como se existisse de fato uma interface real na máquina. Para isso, é definido um esquema de comunicação para encaminhar os quadros entre as máquinas virtuais que encapsula os quadros IEEE em quadros Ethernet. Os quadros transmitidos por cada placa sem fio virtual são de fato primeiro encaminhados para uma máquina especial (também virtual) que controla quem deve receber o quadro, e o reencaminha para as devidas máquinas, levando em consideração as definições do nível físico dessa rede. Embora evidentemente não permita uma avaliação completa dos protocolos, uma vez que existem diversas questões do nível físico que impactam no funcionamento dos protocolos, e só podem ser testadas em ambientes reais, o LVWNet permite que diversas outras questões sejam analisadas. Em especial é possível, por exemplo, analisar diversas questões referentes aos protocolos de encaminhamento de quadros do IEEE s, como a corretude do seu mecanismo de descoberta de rotas, sua adaptação quando nós ou enlaces falham, volume de mensagens transmitidas, entre outras. Vale ressaltar, que embora algumas questões possam ser analisadas por simuação, com o LVWNet pode-se testar a implementação real do código executado pelos sistemas operacionais. Isso é especialmente importante quando novos protocolos estão sendo desenvolvidos, pois o código escrito durante a fase de análise e testes é totalmente aproveitado. 1.1 Motivação Na sua versão original o LVWNet apresenta algumas limitações que restringem os cenários nos quais ele pode ser utilizado. Nessa seção apresentaremos as quatro principais limitações que motivaram o desenvolvimento desse trabalho. A primeira limitacão é que todos os nós da rede precisam ser conhecidos e cadastrados na máquina de topologia previamente, ou seja, antes do início da execução das máquinas virtuais. A máquina de topologia é responsável por realizar os cálculos de distância entre nós e eventualmente encaminhar os quadros para os outros nós, dependendo do seu modo de operação, que será explicado durante este trabalho. Portanto, apesar de suportar a emulação de falhas nos links ou nós, o LVWNet não

21 20 suporta uma rede dinâmica onde os nós entrem ou deixem a rede ao longo do tempo. Fazse necessário portanto, um mecanismo que permita que novos nós entrem (ou deixem) a rede a qualquer momento. A segunda limitação é que no LVWNet existe uma máquina, chamada de Máquina de Topologia que é a responsável por emular o comportamento do meio físico, e por onde todos os quadros enviados pelós nós devem passar de modo a serem reencaminhados aos seus destinos. Tal fato gera uma sobrecarga que limita a escalabilidade da rede, uma vez que se existir um número muito elevado de nós isso pode gerar problemas de desempenho. É interessante portanto, criar um mecanismo que limite as informações encaminhadas para a máquina de topologia, apenas às informações de controle da rede virtual, deixando o tráfego de dados propriamente dito ser encaminhado diretamente entre as máquinas. A terceira limitação se refere a forma como alcance do sinal de um nó é definida no LVWNet. O alcance do sinal define para cada nó quais outros nós da rede devem receber seus quadros, e no LVWNet isso é feito de modo estático, através da especificação dos endereços MAC dos nós. Desse modo, para cada nó é mantida uma lista com um ou mais endereços MAC dos nós que estão no alcance de sinal do referido nó. Vale ressaltar, que essa lista é uma estrutura interna do LVWNet e não é vista pela pilha IEEE Embora esse modelo de definição do alcance do sinal permita a criação das topologias desejadas, ele possui duas principais limitações. A primeira é que todos os nós que participam da rede devem ser conhecidos previamente, dificultando, por exemplo, a inserção de novos nós com a rede já em operação. O segundo ponto, é a dificuldade para inserir suporte à mobilidade dos nós. É necessário usar um modelo de alcance do sinal mais próximo da realidade, ou seja, que considere questões como potência de sinal, sensitividade do receptor e posicionalmento dos nós no espaço. Além disso, esse mecanismo deve ser dinâmico de modo que novos nós possam ser inseridos na rede a qualquer momento. A quarta limitação do LVWNet é que mesmo que ele possa ser utilizado com máquinas reais ao invés das virtuais, as interfaces de rede wifi continuariam a ser virtuais. Desse modo, não é possível integrar um equipamento real, que possui uma interface de rede wifi real, na rede virtual criada pelo LVWNet. Esse trabalho propõe soluções para essas quatro limitações, e as duas seções seguintes discutem em mais detalhes a importância de se abordar a terceira e a quarta limitação.

22 1.1.1 A importância de implementar o posicionamento dos nós no espaço 21 Embora comunicação sem fio e mobilidade não sejam a mesma coisa, uma vez que podemos ter equipamentos sem fio que não possuem mobilidade, nas redes atuais suporte à mobilidade é uma característica cada vez mais desejada nesses ambientes, onde dispositivos como smartphones, notebooks e qualquer outro equipamento que faça uso do protocolo IEEE normalmente estão em movimento. Fogem a essa regra equipamentos como pontos de acesso que estão em lugares fixos. Contudo, já temos pontos de acesso móveis com baterias e celulares que também funcionam como ponto de acesso, que faz com que não possamos afirmar que todos os pontos de acesso são fixos. Desse modo, para iniciar um mecanismo de suporte à mobilidade no LVWNet é preciso substituir seu mecanismo de controle do alcance de sinal dos nós (baseado no endereço MAC) por um que se aproxime mais da realidade e considere a posição física dos nós. Em redes sem fio reais, o posicionamento de um nó ou de um ponto de acesso sem fio é muito importante para a boa recepção, seja para fugir de uma possível área de sombra, seja por causa da distância, ou seja por causa de obstáculos existentes entre dois pontos que desejem se comunicar. Contudo na proposta de solução para esse problema, que será apresentada posteriormente, foram considerados apenas aspectos referentes a potência de transmissão, sensitividade de recepção e distância entre dois nós, não levando em consideração posssíveis obstáculos e interferências. Com a mobilidade de nós implementada em redes virtuais é possível verificar por exemplo como um protocolo ou aplicação sem comporta no caso de uma reconfiguração da rede advinda de uma movimentação dos nós participantes da rede. Dada a natureza virual da rede, é possível fazer isso em uma centena de nós, sem um esforço excessivo A importância de integrar uma rede IEEE real com uma virtual Uma vez que o projeto LVWNet está funcional, um questionamento comum seria: Por que é importante integrar uma rede virtual com uma rede real, sabendo-se que hoje com virtualização pode-se resolver uma quantidade muito vasta de problemas. A resposta pode parecer simples, mas é justamente para testar equipamentos reais, incluindo neste teste o software e hardware. Principalmente quando é necessário simular a conexão de um (ou vários) equipamentos reais com dezenas ou centenas de máquinas

23 22 virtuais. Como exemplos práticos de uma aplicação temos a análise do consumo de bateria de um dispositivo móvel quando conectado a uma rede com outras 100 estações. Como a autonomia desse dispositivo será impactada sendo necessária a análise e eventual reposta à mensagens de broadcast dessa centena de máquinas? Sendo o consumo de bateria algo crítico em dispositivos móveis, tais testes poderiam ajudar a determinar limites para implementação do firmware desses equipamentos, ou até mesmo subsidiar alterações no próprio hardware. Outro exemplo é a análise da capacidade de processamento e memória necessária para um dispositivo (por exemplo, um roteador ou um access point) atender a uma quantidade determinada de clientes. Esses recursos podem ser facilmente esvaídos quando temos uma tabela de rotas ou até mesmo uma grande tabela ARP para gerenciar. Também podem ser gastos facilmente com pedidos constantes de mensagens de broadcast geradas por centenas de máquinas que façam parte de uma mesma rede mesh ou em infraestrutura. A interligação entre laboratórios de testes reais é algo possível com as modificações realizadas. Dois laboratórios separados, onde não exista a possibilidade de chegada de um sinal de rádio entre eles, poderiam ser facilmente interligados utilizando duas máquinas como gateways, permitindo que se forme um único domínio de broadcast em uma rede IEEE Isso é especialmente interessante para redes IEEE s, uma vez que diversos laboratórios (testbeds) reais fisicamente distantes uns dos outos, podem ser interligados de modo a criar uma grande rede em malha sem fio que possui apenas alguns poucos enlaces virtuais. Ainda nessa linha de interligar equipamentos reais através de nós virtuais é possível testar a compatibilidade da implementação do software de equipamentos diferentes. Supondo que só se dispõe de um modelo de equipamento pode-se criar uma rede virtual para conectá-lo a outro equipamento que se encontra em um lugar remoto. 1.2 Objetivos De acordo com o que foi exposto na seção de motivação, o objetivo desse trabalho é extender a versão original do LVWNet incorporando os seguintes recursos: Definir um protocolo para o registro dinâmico dos nós na rede; implementar a comunicação direta entre os nós;

24 23 definir um novo mecanismo para o cálculo do alcance do sinal dos nós de modo a suportar mobilidade; permitir a integração de equipamentos IEEE reais com a rede virtual. 1.3 Organização do trabalho Neste capítulo inicial, foi apresentada uma introdução ao trabalho, mostrando como ele está organizado, a motivação que levou ao desenvolvimento do mesmo e os objetivos que procuramos alcançar. No capítulo dois, é apresentada uma fundamentação teórica sobre o protocolo IEEE e o protocolo IEEE s, necessária para um bom entendimento do trabalho realizado. Uma breve lista de trabalhos relacionados ao nosso projeto é apresentada no terceiro capítulo, discutindo como eles contribuíram ou ainda podem contribuir para o amadurecimento da solução. No quarto capítulo é fornecida inicialmente uma visão geral do projeto LVWNet, apresentando como funciona seu mecanismo de encapsulamento de quadros IEEE em quadros Ethernet, e apresentando todos os componentes necessários para a criação de uma rede virtual. Após isso, são apresentadas todas as modificações realizadas no projeto original, incluindo o novo esquema de posicionamento dos nós no espaço e alcance do sinal, bem como uma descrição completa do mecanismo criado para a utilização de interfaces de rede reais no projeto LVWNet. O quinto capítulo apresenta as questões relacionadas a implementação de todos os novos recursos. No sexto capítulo são apresentados os testes realizados para para validar a solução, bem como as metodologias adotadas nesses testes e seus consequentes resultados. Finalmente no sétimo e último capítulo, temos a conclusão sobre o que foi apresentado no trabalho, e são relacionadas questões em aberto para serem tratadas por trabalhos futuros.

25 24 2 Fundamentação Teórica 2.1 O protocolo IEEE Definido pelo IEEE através do padrão Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications (SOCIETY, 2012), ele traz em seu escopo a necessidade de definir uma estrutura para controle de acesso ao meio, MAC, e toda a camada física ( PHY ) wireless para equipamentos fixos e móveis, estes últimos chamados pelo padrão como Station (STA ) dentro de uma área de cobertura. Além disso, também está dentro dos objetivos do padrão regulamentar e padronizar o acesso a frequências e bandas dentro dessas frequências. Dentro do modelo de referência OSI de 7 camadas, o protocolo IEEE esta na camada de enlace de dados, conforme ilustra a figura 1. Figura 1: IEEE e o modelo de referência OSI de 7 camadas.

26 Camada Física A camada física do IEEE corresponde bem à camada física do modelo de referência OSI de 7 camadas, contudo a camada de enlace é dividida em duas subcamadas, como visto na figura 1. Na primeira subcamada temos o Logical Link Control (LLC ), que é o responsável por abstrair as diferenças entre as diferentes variações do IEEE , como por exemplo b, n, ac etc (TANENBAUM; WETHERALL, 2011). Na camada física, temos várias técnicas utilizadas para modulação do sinal, conforme iremos observar adiante. O IEEE utiliza frequências da banda Industrial, Scientific and Medical (ISM ), definida pela ITU-R normalmente como sendo na faixa de 900 MHz, 2.4 GHz e 5.8GHz, contudo de forma mais precisa usando as frequências de MHz, GHz e GHz(TANENBAUM; WETHERALL, 2011), que são frequências que podem ser usar sem qualquer necessidade de regulamentação prévia. Entre essas técnicas de modulação, o IEEE b, que tem taxas de transferência entre 1 e 11 Mbp/s utiliza Digital Spread Spectrum (DSS ), ou sequência direta de espalhamento espectral, que espalha a potência do sinal sobre várias frequências simultaneamente. Já o IEEE a utiliza Orthogonal Frequency Division Multiplexing (OFDM ), onde múltiplos sinais são enviados em diferentes frequências, em diferentes modulações. Finalmente, o IEEE n, que chega a taxas de 600 Mbp/s e o IEEE ac, que pode chegar em taxas agregadas PHY de até 6.7 Gbp/s, utilizam o Multiple-Input Multiple- Output (MIMO ), que é um conjunto de técnicas de transmissão que utiliza múltiplas antenas para transmissão e recepção, aproveitando inclusive sinais gerados por reflexão, que antes eram considerados interferências, para melhorar a qualidade de transmissão e recepção Definições do IEEE O IEEE tem uma abordagem de corbetura de áreas baseadas em células, onde cada célula é chamada de Basic Service Area (BSA ). Quem irá determinar o tamanho de uma célula (BSA) é a potência dos transmissores, sensitividade dos receptores das estações, além de agentes externos que possam causar interferência, como por exemplo outros transmissores concorrendo na mesma frequência, ou até mesmo barreiras físicas, como prédios ou árvores (FILHO LUIZ FERNANDO SOARES, 2007). Podemos simplificar o signifcado de uma BSA como sendo a cobertura da célula. Além do BSA, temos algumas outras definições que valem ser mencionadas, como o

27 26 Basic Service Set (BSS ), que podemos definir como sendo um conjunto de estações (STA) associadas a um ponto de acesso. O ponto de acesso, ou access point é quem atua como controlador da infraestrutura e da comunicação das estações. A mais básica BSS possível é composta por uma STA e um AP (Access Point). Também temos no IEEE o Distribution System (DS ), que é a representação de uma infraestrutura de comunicação que interliga várias BSAs, de forma que possa permitir uma comunicação entre várias células (SIRUFO, 2005). Usando o conceito de DS previamente estabelecido, temos a definição de Extended Service Area (ESA ) e Extended Service Set (ESS ). Na primeira, temos a interligação de várias BSAs, usando justamente o DS previamente criado através de APs. Já no segundo, repsenta um conjunto de STAs formado pela união de vários BSSs, conectados por um mesmo DS. Além dessas definições, o IEEE prevê o conceito de services(society, 2012). Entres esses serviços, os principais são: 1. Association É usado por estações móveis para conectá-las a um Ponto de Acesso. Quando uma estação entra no raio de cobertura de um ponto de acesso (AP), ela analisa a identidade e os recursos do ponto de acesso através dos beacon frames, ou realizando consultas direto ao ponto de acesso. 2. Reassociation A reassociação faz uma estação sair de um AP para outro. Usada para facilitar a movimentação das STAs dentro de áreas de cobertura de diferentes pontos de acesso, permitindo a mobilidade dessa STA. 3. Disassociation A disassociação interrompe um relacionamento entre um AP e uma STA. Uma STA deve utilizar esse serviço antes de desligar-se ou deixar a rede. Um AP também pode usar esse serviço antes de entrar em manutenção. 4. Authentication Antes de começar a enviar frames por um AP, as STA devem autenticar-se. Nesse momento é que entra o conceito de uma rede aberta, onde qualquer usuário pode autenticar-se sem restrição, ou uma rede fechada, onde temos mecanismos para

28 27 restringir os usuários tipicamente através de autenticação. Exemplos de esquemas de autenticação é o WiFi Protected Access (WPA ), implementado no IEEE i, ou ainda Wired Equivalent Privacy (WEP ), usado bem antes do WPA e já superado. Vale mencionar que como será visto no service privacy, os protocolos WPA e WEP também provêm criptografia além da autenticação. 5. Distribution Uma vez que quadros comecem a chegar em um AP, temos o serviço de distribuição, que determina como os quadros irão chegar em outras STAs ou no próprio AP. 6. Integration Completamente relacionado ao serviço de distribuição, ele é o responsável por encaminhar os quadros para redes que não sejam IEEE Normalmente, isso significa a entrega de quadros IEEE em Ethernet, claro realizando-se as modificações necessárias no quadro. 7. Data delivery Este serviço é o responsável por fazer as STAs transmitir e receber quadros, utilizando os quadros definidos no IEEE QoS traffic scheduling De forma a podermos manipular os quadros quanto a diferentes prioridades, usamos o serviço de QoS. Presumidamente, o IEEE é um protocolo do tipo besteffort, ou seja, entrega baseada em melhor esforço. Contudo, com o serviço de QoS, podemos criar prioridades para determinados protocolos que precisem de tratamento diferenciado, como por exemplo tráfego de voz ou vídeo. 9. Privacy O serviço de privacidade é responsável pela criptografia dos dados. Eventualmente confunde-se com o serviço de autenticação, pois os protocolos tipicamente usados para ambos os serviços, normalmente são os mesmos. Como exemplos de protocolos que trabalham nesse service estão WPA e WEP. 10. Transmit power control O serviço de controle de potência de transmissão impede que as estações excedam os limites regulatórios do país ou região. Por exemplo, no Brasil, para a faixa de frequência ISM, usada pelo IEEE , a potência máxima prevista em lei é de 1 Watt (ANATEL, 2008).

29 Dynamic frequency selection Finalmente, o último serviço é o de seleção de frequência dinâmica. Ele é responsável por ajudar a STA a evitar frequências de uso específico, como por exemplo a de 5GHz, usada por radares (IEEE, 2007) Camada MAC O método de controle de acesso ao meio utilizado pelo IEEE é o Carrier Sense Multiple Access/Collision Avoid, ou CSMA/CA, que conceitualmente é semelhante ao Carrier Sense Multiple Access/Collision Detect, ou CSMA/CD utilizado no ethernet. No CSMA/CA a estação antes de transmitir verifica se o meio está ocupado (de forma análoga ao CSMA/CD), e caso o meio não esteja livre espera por um tempo aleatório, definido no protocolo. Caso o transmissor não receba o ACK do receptor, ele dobra o tempo de espera e envia novamente. Essa característica do CSMA/CA é chamada de exponential backoff. Uma das situações que gera possíveis problemas ao CSMA/CA é o hidden terminal, ou estação oculta. Para comparação, o CSMA/CD foi desenvolvido de forma que todas as estações possam escutar umas as outras (além da atenuação, esse é o principal motivo da distância máxima de 100 metros do ethernet). Já em ambientes wireless, isso não é completamente possível. No hidden terminal, como nem todas as estações estão no alcance uma das outras, uma transmissão vinda de parte de uma célula, pode não ser escutada por outra parte dessa mesma céula. A figura 2 exemplifica esse problema. Quando a STA 1 tenta enviar para a STA 2, ela verifica o meio para analisar se existem transmissões ao alcance. Contudo, a STA 3 que já estava transmitindo, estava fora de alcance da STA 1. Figura 2: Problema do hidden terminal em redes CSMA/CA. Uma técnica que minimiza o problema do hidden terminal é a utilização combinada de escuta do canal virtual e física juntamente com os quadros RTS e CTS. A física é a escuta descrita anteriormente no CSMA/CA. Já a virtual, descrita como virtual sensing

30 29 em (TANENBAUM; WETHERALL, 2011), acontece quando cada estação mantém um registro de quando o canal está em uso através da análise dos campos NAV (Network Allocation Vector). Cada quadro trás um campo NAV, que diz quão longa a sequência de que esse quadro faz parte irá demorar. Com isso, a estação tem como estimar quanto tempo o canal irá ficar ocupado. 2.2 O protocolo IEEE s O grupo de estudos para criação do IEEE s foi iniciado em setembro de 2003 (IEEE, Setembro de 2003) com o nome de ESS-Mesh, e o grupo de trabalho com o objetivo de criar os primeiros Drafts do protocolo foi formado em Maio de 2004 (IEEE, Maio de 2004). Em junho de 2011, o último Draft foi fechado (IEEE, Julho de 2011), e o padrão foi incorporado ao IEEE em sua versão (nesse momento, a mais recente). O principal objetivo do IEEE s é permitir a criação de um mecanismo de comunicação utilizando múltiplos saltos, que é conhecido como uma rede em malha. Na infraestrutura convencional do IEEE as estações (STA) se comunicam com um dispositivo central chamado ponto de acesso, que provê um BSS (Basic Service Set). No IEEE s não existe a função de AP. Cada nó da rede, ou mesh STA, que é chamado de Mesh Point, ou MP, pode se conectar a qualquer outro MP. Desse modo, em uma rede mesh, temos a formação de um BSS diferente, chamado de MBSS (Mesh Basic Service Set). Conforme citado, nesse Basic Service Set específico, não há a presença de access points, e sim somente STAs mesh. Logo, fica claro que uma estação mesh IEEE s não pode comunicar-se com uma STA baseada em infraestrutura (AP) de forma direta. Para existir essa interação entre BSS e MBSS, temos a necessidade de um componente adicional, chamado Mesh Gate. Um Mesh Gate nada mais é do que uma STA mesh que tenha acesso a mais de um distribution system(ds), uma delas sendo pelo menos uma MBSS e outra BSS (HENRY, 2011). Em (NWUP; AKANDE, 2009), temos uma larga definição de alguns detalhes do IEEE s que iremos tratar nesse documento de forma resumida. Em redes mesh, algo que normalmente tem uma complexidade razoável para os nós participantes da rede é o cálculo de caminhos para os outros participantes da rede. O IEEE s utiliza por padrão o Hybrid Wireless Mesh Protocol (HWMP ) como protocolo de roteamento em layer 2 para nós que não são seus vizinhos imediatos.

31 30 O HWMP pode trabalhar de duas formas distintas. No primeiro modo, chamado de sob demanda, sempre que um nó precisa se comunicar com outro, e este não está na sua tabela de vizinhos, e tampouco tem algum caminho conhecido na sua tabela de roteamento layer 2, ele envia uma mensagem em broadcast com um pedido chamado Path Request (PREQ ). Todos os nós que não conhecem o endereço MAC para quem está sendo solicitado o path reenviam essa mensagem. Uma vez que algum nó tenha em sua tabela de vizinhos esse endereço MAC, ele prepara uma outra mensagem, chamada de Path Reply (PREP ) com a informação solicitada. Em todo nó que passe essa mensagem PREP, é incrementado um contador de quantidade de nós, de forma que o solicitante saiba qual a distância até o nó solicitado. Isso é importante, pois é provável que mais de um nó responda a mensagem, e ele deverá determinar qual o caminho mais curto. Já no segundo modo, chamado de modo proativo, temos a figura de um nó central chamado root, responsável por manter caminhos para todos os nós. Esse nó root envia periodicamente uma mensagem chamada de Root Announcement (RANN ), de forma que todos os nós que recebam essa mensagem são capazes de construir um caminho até o nó root, de forma análoga ao que acontece no PREP. Quando outros nós quaisquer que não sejam root desejem comunicar-se, e ambos não tem caminhos conhecidos, eles enviam o primeiro quadro diretamente para o nó root, e este encaminha para o nó correto, pois já deve ter a lista de todos os MACs participantes da rede, uma vez que recebeu respostas do RANN enviado anteriormente. Quando nó recebe do root uma mensagem de dados de outro nó, eles podem opcionalmente trocar mensagens de PREP e PREQ para criar um caminho mais eficiente (BARI; ANWAR; MASUD, 2012) que através do nó raiz. É possível ver na prática esses caminhos criados através do comando no Linux iw dev mesh0 mpath dump, onde ele mostrará uma lista de endereços conhecidos, e o caminho (endereço MAC de vizinhos) para chegar até eles. Pode-se notar que no ponto de vista do cliente essa é uma estratégia gulosa, ou míope, pois ele só precisa conhecer seus vizinhos imediatos, não precisando conhecer todo o caminho até determinado nó. Embora existam diversos outros detalhes a respeito do IEEE (incluindo o adendo IEEE s), nessa seção foram apresentados apenas os pontos principais para compreensão de como essas redes podem ser emuladas usando o trabalho aqui proposto O Módulo mac80211 No Linux, temos dois tipos de implementações possíveis para hardwares baseados em IEEE A primeira e mais antiga é chamada de FullMAC. Nesse tipo de implemen-

32 31 tação, a Media Access Control Sublayer Management Entity, ou MLME é completamente implementada na camada PHY, ou seja, no firmware da placa de rede sem fio. Nesses casos, o fabricante é quem normalmente disponibiliza o firmware e tem o trabalho de implementar toda a camada MAC (ROSEN, 2009). Entre as funções normalmente executadas pela MLME, temos: Autenticação, Associação, Envio e recebimento de beacons, Timing Synchronization Function (TSF ). Já nas implementações baseadas em SoftMAC, temos o uso do módulo mac80211 para realizar essas funções da MLME. O mac80211 começou a ser desenvolvido em 2001 e foi incorporado à mainline 1 do Kernel do Linux em sua versão , em Julho de Como é percebido, no caso de se usar SoftMAC, o fabricante só precisa se preocupar com a camada PHY, e quando existir interação entre a camada MAC e a PHY, realizar chamadas para o mac Tal modelo simplifica bastante o desenvolvimento de drivers para interfaces de rede wireless além de garantir uma melhor implementação da camada MAC. Outra vantagem da utilização do SoftMAC ao invés do FullMAC é a padronização. Uma vez que todas as interfaces de rede sem fio usem esse módulo para implementação do MLME, alterações e novas funções adicionadas nesse módulo estarão disponíveis para todos os hardwares que façam uso desse módulo. Nesse caso em especial, será visto mais a frente que utilizamos exatamente dessa vantagem para realizar as modificações necessárias somente no módulo mac80211, permitindo o uso de uma vasta quantidade de interfaces que o usam, inclusive virtuais. No caso do SoftMAC, além de interfaces físicas, temos a possibilidade de uso do mac80211_hwsim, que é um módulo que cria interfaces sem fio virtuais, mas por concepção, dentro de uma mesma máquina. Como ele também faz uso do SoftMAC para implementação da MLME, também foi possível usá-lo como base para esse trabalho, como será visto adiante. 1 mainline é como é chamada a árvore principal de desenvolvimento do kernel do Linux, que é mantida pelos principais desenvolvedores

33 32 3 Trabalhos Relacionados Neste capítulo temos como objetivo relatar todos os trabalhos relacionados ao nosso atual projeto, bem como sua influência e importância na implementação e definição do nosso trabalho. 3.1 Network Simulator Network Simulator é um simulador de redes baseado em eventos discretos desenvolvido primariamente para uso educacional e em pesquisas. NS-3 é um software livre, licenciado sob a licença GNU GPLv2, e está disponível para pesquisa, desenvolvimento e uso (ANDREEV; BOYKO, 2010). O NS-3 (versão 3 do Network Simulator) tem uma abordagem estritamente de simulação, ou seja, não existe emulação do meio para fora do ambiente do NS-3 no que se refere a comunicação sem fio. Ele possui um conjunto próprio de classes desenvolvido em C++. Um objetivo alcançado pelo NS é o grande conjunto de protocolos incorporados por suas classes, permitindo a simulação por exemplo, desde redes ethernet até redes WiMax (IEEE )(IEEE, 2012b). Ele não se relaciona diretamente com o LVWNet pois como já mencionado, não oferece emulação do meio físico sem fio para máquinas virtuais ou reais, que é o principal objetivo do LVWNet. 3.2 Projeto NCTUns Com uma grande quantidade de definições em (WANG; HUANG, 2012), o projeto NC- Tuns tem uma abordagem distinta tanto do LVWNet como do NS. Como o NS, ele é um simulador de redes, onde os quadros ou pacotes percorrem somente dentro do seu

34 33 ambiente interno. Contudo, ele também trabalha como emulador de redes, uma vez que é possível interagir com o ambiente criado internamente no próprio NCTuns com máquinas reais ou virtuais. Além do ambiente de emulação provido pelo NCTuns, ele tem a possibilidade de uma abordagem distribuída, de forma a dividir o processamento de uma grande simulação em vários hosts. Entretanto, apesar de também ser um emulador de redes, sua principal diferença para o LVWNet, é que ele tende a gerar tráfego de forma artificial, sem utilizar máquinas virtuais, nem tampouco permite o uso de hardwares reais. 3.3 Projeto mac80211_hwsim O módulo mac80211_hwsim é um simulador de interfaces de rádio que utilizem o protocolo IEEE sob a camada MLME do mac Com ele é possível gerar uma grande quantidade de interfaces de radio IEEE em uma mesma máquina de modo que se possa testar uma grande variedade de funcionalidades e ferramentas em user space. Pode-se, por exemplo, criar duas interfaces de rede para testar o hostapd e o wpa_supplicant, que seriam utilizadas para criar um ponto de acesso sem fio e um cliente para esse ponto de acesso, respectivamente. O principal objetivo do mac80211_hwsim é facilitar o trabalho dos desenvolvedores na hora de testar novas implementações do mac80211, hostapd e wpa_supplicant. Os radios simulados não têm limitações do hardware real, então é simples gerar ambientes de testes que sempre reproduzam o mesmo resultado. Ainda aproveitando que a operação dos rádios é simulada, qualquer canal pode ser usado para testes, independente de regras regulatórias do país (WIRELESS, 2014). Contudo, esse projeto trás lacunas relativas justamente à interação com equipamentos e hardwares reais, e também ao seu uso de forma distribuída (em vários computadores). Tais lacunas pretendem ser preechidas pelo LVWNet. 3.4 Projeto Wmediumd Uma vez que o módulo mac80211_hwsim não provê nenhuma técnica de simulação de atraso, perda ou erros no meio até o momento, o projeto wmediumd se encaixa

35 34 justamente nessa lacuna. O wmediumd foi criado para possibilitar a emulação de ambientes sem fio especificamente para o mac80211_hwsim. Com essa emulação do meio, o projeto busca permitir a programadores de drivers para dispositivos IEEE criarem um ambiente de desenvolvimento e testes em um único computador, economizando tempo e dinheiro (ILLáN, 2013). A versão atual somente emula o comportamento do meio criando perdas dependendo de probabilidades, mas não permite o uso de padrões de mobilidade entre os rádios, sendo mencionado no documento (ILLáN, 2013) como sugestões para trabalhos futuros. Ele utiliza a interface Netlink para inserir atrasos e erros inerentes a comunicações no mac80211_hwsim. Contudo, ele faz isso para todas as interfaces dentro do mesmo host. O projeto LVWNet elimina essa restrição permitindo o uso de várias máquinas, cada uma com sua interface de rede.

36 35 4 Visão Geral do Projeto LVWNet Como já brevemente mencionado na introdução, o projeto Linux Virtual Wireless Network (LVWNet), que este trabalho utilizou como base e estendeu suas funcionalidades, tem como objetivo inicial a criação de uma rede mesh utilizando uma infraestrutura de máquinas virtuais, de forma a permitir testes utilizando qualquer protocolo que possa fazer uso da pilha de rede dessas máquinas, facilitando o estudo e desenvolvimento de novos protocolos e aplicações. Ele pode ser encontrado no github, no endereço na forma de um projeto aberto (público), contudo com commits controlados. O LVWNet original tem em sua arquitetura duas peças principais, que são o controlador de topologia e o nó participante da rede. O controlador de topologia é o responsável pela emulação do meio físico (no caso, o ar), e o nó participante da rede é uma máquina virtual que executa uma versão modificada do mac80211_hwsim (módulo que permite a criação de interfaces wireless compatíveis com IEEE ), versão essa que encaminha todos os quadros que deveriam ir para a camada PHY para o controlador de topologia. Isso é feito encapsulado os quadros IEEE em quadros ethernet. Foi utilizado um código de tipo (campo Tipo do quadro Ethernet) específico para identificar esses quadros. Já a máquina controladora de topologia, ao receber um quadro de um nó, verifica que outros nós estão na vizinhança dele (ou seja, no alcance do sinal), e encaminha o quadro para todos eles, novamente encapsulados em um quadro ethernet. Quando o nó recebe um quadro ethernet com o código do LVWNet no campo de Tipo, ele verifica se veio do nó controlador de topologia, desencapsula o quadro, e o envia novamente para a pilha IEEE , como se tivesse sido recebido pela camada PHY. O objetivo inicial dessas modificações era permitir a criação de uma rede em malha para testes do IEEE s, onde teríamos uma configuração em grade x, y, para criação de uma rede de por exemplo 3x3 (com 9 nós), ou 4x4 (com 16 nós). Para permitir a criação de uma malha em mesh de alta densidade, o LVWNet utiliza

37 36 técnicas de virtualização de máquinas, onde o hardware real é compartilhado, permitindo a execução de diversas máquinas virtuais no mesmo hardware. A peça principal dessa infraestrutura é o hypervisor, que faz o controle de acesso ao hardware (quando existe hardware já pronto para virtualização que permita tais funções) ou até mesmo a emulação de itens quando não há hardware pronto para virtualização. Apesar de inicialmente ser focado em redes mesh, não há nenhum impedimento na utilização dessa infraestrutura para qualquer protocolo derivado do IEEE , que seja implementado pelo módulo mac80211 do Linux. Conforme já citado no capítulo 1, este trabalho estendeu as funcionalidades do projeto original do LVWNet inserindo novos recursos. Na próxima seção são apresentados maiores detalhes do funcionamento do LVWNet original e na seção 4.2 os novos recursos propostos nesse trabalho são apresentados em detalhes. 4.1 LVWNet original Nesta seção serão descritos os componentes de uma rede LVWNet que segue o modelo original, ou seja, sem modificações, bem como a interação entre eles. Também serão tratados aqui as lacunas e suas possíveis melhorias a serem implementadas Máquina controladora de topologia A máquina controladora de topologia é a responsável por simular o meio físico sem fio. Os nós participantes da rede não tem conhecimento da existência dela (na perspectiva da pilha IEEE ), uma vez que somente o módulo LVWNet que está carregado nessas máquinas sabe de sua existência. Para isso, na carga desse módulo deve-se informar o parâmetro ctrladdr=xx:xx:xx:xx:xx:xx, onde xx:xx:xx:xx:xx:xx é o endereço MAC ethernet da máquina de controle de topologia. Essa máquina controladora de topologia host tem uma tabela onde guarda os endereços MAC das interfaces ethernet e sua posição no formato de um grid (X,Y ). A definição do alcance de sinal de cada nó é feita utilizando os endereços Ethernet. Desse modo, e com a configuração em grid que é suportada, ela somente encaminha os quadros entre os vizinhos de acordo com a posição no grid. Na figura 3 temos um exemplo de uma rede em grid de tamanho 3 x 3. Uma vez o módulo LVWNet dessa máquina recebe um quadro ethernet identificado

38 37 como sendo de um nó participante, ele verifica o endereço MAC ethernet da origem, e busca em sua tabela quais os vizinhos desse nó. Depois disso, ele modifica o cabeçalho ethernet, coloca seu próprio endereço MAC como origem, e cria uma cópia do quadro para cada nó de destino, de modo a simular o alcance entre os nós em uma rede IEEE Um possível problema nessa abordagem é a saturação da máquina de controle de topologia, pois todos os quadros IEEE necessariamente serão encaminhados para ela Nó participante da rede Uma estação ou nó se torna participante dessa rede através do encaminhamento dos quadros para a máquina de topologia. Ela só conhece seus vizinhos, pois como já mencionado, a máquina controladora de topologia só encaminha os quadros para os vizinhos. Ela não tem conhecimento direto da existência do controlador de topologia, pois o módulo LVWNet deixa isso completamente transparente para o restante da pilha IEEE Observa-se que na imagem 3 não existe a figura da máquina controladora de topologia, contudo na figura 4, que é a representação em camada de enlace ethernet, layer 2 quando usado como referência o modelo OSI de 7 camadas, vemos a existência do controlador de topologia, e como ele está conectado a uma rede com o mesmo domínio de broadcast dos demais nós participantes. Figura 3: Conexões de uma rede mesh 3 x 3 conforme visto pelas máquinas virtuais.

39 38 Todo quadro que deveria ser enviado através da interface wlan0 é redirecionado e encapsulado em um quadro ethernet, de ethertype 1 0x0808, uma vez que esse é o valor utilizado para indicar quadros do LVWNet. No payload do quadro ethernet enviado é adicionado um pequeno cabeçalho, antes do quadro IEEE encapsulado. Esse cabeçalho nessa versão original do LVWNet serviu apenas como um campo de reserva para uso futuro. Portanto, não era de fato utilizado. Como será mostrado mais adiante nesse texto, ele passou a ser fundamental para a implementação dos novos recursos. Figura 4: Conexões reais de uma rede mesh 3 x 3 criada pelo LVWNet. Quando o quadro Ethernet reencaminhado pela máquina controladora de topologia chega ao nó de destino, o LVWNet retira o quadro IEEE que está encapsulado dentro do quadro ethernet e o envia para a pilha IEEE como se tivesse sido recebido por um dispositivo wireless real Hypervisor Embora o LVWNet possa ser utilizado em computadores reais, dada a grande facilidade proporcionada pela virtualização é recomendado que sejam utilizadas máquinas virtuais para a criação das redes. Isso facilita inclusive a criação de uma rede com uma grande densidade de nós. 1 Ethertype: campo do quadro ethernet IEEE que sinaliza o tipo do protocolo encapsulado dentro do payload do quadro ethernet

40 39 Estamos utilizando para nossos testes máquinas virtuais criadas com o KVM. Contudo, provavelmente qualquer outro hypervisor pode ser utilizado, apesar dessa afirmação carecer de testes mais profundos. Em nossos testes, utilizamos uma máquina virtual com recursos bem reduzidos, pois o objetivo era testar somente a pilha de rede, com aplicações simples baseadas em console. Nessa nossa configuração, utilizamos máquinas com 256 Mb de RAM e um processador com 1 core. Além da configuração reduzida de memória, também utilizamos o KSM (MACHINE, 2014), que permite o compartilhamento de páginas de memória de processos que estejam sendo executados em um host. Isso nos permitiu a execução de pouco mais de 20 máquinas virtuais em um host com apenas 4Gb de RAM. 4.2 Componentes Modificados do LVWNet Tendo como objetivo eliminar as limitações do LVWNet, foram realizadas diversas modificações no projeto original que serão detalhadas nas sub-seções a seguir. De modo resumido, as alterações foram: i) Criar um protocolo que permita o registro dinâmico dos nós na rede; ii) Permitir a interação da rede virtual com nós com hardware real de modo a possibilitar a utilização de nós com interfaces de rede reais em uma rede LVWNet; iii) Definir um esquema de posicionamento dos nós no espaço utilizando coordenadas x, y e z para permitir que se obtenha liberdade no posicionamento dos nós, antes limitados a uma grade x, y. Tal esquema é fundamental para a implementação de suporte a mobilidade; iii) Melhorar a comunicação entre os nós, uma vez que a forma de emulação do meio físico original faz com que todos os quadros passem pelo controlador de topologia. Nessa configuração, é de se esperar que uma grande quantidade de nós gere uma limitação decorrente da largura de banda ou até mesmo da capacidade de processamento da máquina de topologia. Para isso foi criado um mecanismo de comunicação descentralizado, mais semelhante a um meio real, onde cada nó envia os quadros diretamente para os seus vizinhos alcançáveis, que são identificados através de uma tabela local de vizinhos. Essa tabela é mantida através do protocolo de registro e de envio de informações (citado no item i). Nesse novo modelo proposto para o LVWNet (OLIVEIRA; PINHEIRO, 2014) ainda será utilizada uma máquina de controle de topologia, porém ela terá um uso mais restrito. Sua função será calcular o alcance de sinal de cada nó e, desse modo, informar ao respectivo nó quem deve receber seus quadros. Esse cálculo considera diversos parâmetros, como o

41 40 posicionamento do nó no espaço, e questões referentes a potência de transmissão, entre outras. Cada nó da rede ao ter o módulo LVWNet carregado se registra na máquina de topologia informando esses parâmetros. A comunicação entre os nós se dará de forma direta, sem passar pela máquina de controle de topologia Posicionamento dos nós no espaço O projeto orinalmente tratava o posicionamento dos nós como uma grade X, Y, onde os quadros só eram encaminhados para seus respectivos vizinhos. Exemplificando, o nó posicionado em x = 1 e y = 1, em uma rede de tamanho 3x3, seria capaz de transmitir quadros somente para os nós localizados em x = 1,y = 2 e x = 2,y = 1. Agora para o posicionamento dos nós não existe mais uma grade 2D, e sim um espaço em 3D (X, Y e Z) onde o nó está, e não existe mais a figura do vizinho direto. Para o encaminhamento dos quadros, a máquina de controle de topologia calcula quais máquinas são alcançáveis pelo nó, usando para esse cálculo a potência do transmissor, a sensitividade do receptor e a perda em espaço livre. As questões relativas às antenas (ganhos, características de transmissão como lóbulo) não foram levadas em consideração. O valor padrão da sensitividade dos receptores foram definidos como -75 dbm, que é um valor comum encontrado na maioria dos receptores fisicos. Como padrão na potência de envio, utilizamos 20 dbm, que seria equivalente a 100 mwatts, que também é um valor comum encontrados em transmissores físicos. Ambos os valores podem ser facilmente alterados através de parâmetros na inicialização do módulo. Perda em espaço livre, ou Free Space Loss (FSL ), é uma função que leva em consideração a frequência de transmissão e a distância (RACKLEY, 1995). O cálculo da perda em espaço livre é feito através da equação 4.1, onde D é a distância entre os nós em metros, e λ é a largura da onda de acorcom com a frequência. ( ) 4πD L F S = 20log 10 λ (4.1) λ também pode ser dada pela equação 4.2 onde c é a velocidade da luz no váculo em metros por segundo e f é a frequência em Hertz. Assumimos c como uma constante de valor 3x10 8 m/s.

42 41 λ = c f (4.2) Podemos simplificar ambas as equações 4.2 e 4.1, e já usando c como constante de 3x10 8 m/s, temos uma equação resultante simplificada como mostrada em 4.3. Nessa equação, a frequência é dada em MHz e D em quilômetros. L F S = log 10 (f) + 20log 10 (D) (4.3) Exemplificando, em uma transmissão a 2.4GHz no primeiro canal disponível que tem frequência de exatamente 2412MHz, à uma distância de 80 metros, temos o valor de 78dB, como visto na equação 4.4. L F S = log 10 (2412) + 20log 10 (0.08) = ( ) = (4.4) De forma à demonstrar a influência da frequência na perda em espaço livre, está exemplificado a seguir também em 5.8GHz, usando a mesma distância, no canal 165, que tem a frequência de exatamente 5825M Hz. L F S = log 10 (5825) + 20log 10 (0.08) = ( ) = (4.5) Como visto em 4.5, temos uma atenuação de 85dBm para a mesma distância, em uma frequência bem superior. Essa diferença de quase 8dBm é bastante alta, tendo em vista que a cada 3dBm temos um aumento ou diminuição equivalente ao dobro da potência em miliwatts. Já o cálculo da distância no espaço é feito através da equação da distância em linha reta entre dois pontos, dada por 4.6. D = x 2 + y 2 + z 2 (4.6)

43 42 Onde temos que x, y e z são dados pela relação 4.7. x = x 1 x 2 y = y 1 y 2 (4.7) z = z 1 z 2 O cálculo para verificação se um nó consegue enxergar outro é a simples relação dada por 4.8 que deve ser verdadeira. S recep P trans L F S (4.8) Na relação 4.8, S recep é a sensitividade de recepção da interface de rede, P trans é a potência de transmissão do parceiro, e L F S é a perda em espaço livre inerente a frequência e distância da transmissão. Contudo, existe uma proposta de melhoria do cálculo do L F S, que leva em consideração outras varíaveis, como mostrado em (LAU et al., 2011). Em trabalhos futuros, principalmente no caso da implementação de padrões de mobilidade para os nós, o uso dessas novas propostas de cálculos deverão ser levadas em consideração Protocolo de Registro e Informações dos Nós Nesta sub-seção será tratado o protocolo de registro e informacões dos nós que permite a adição de novos nós na rede de forma dinâmica. Vale ressaltar é que por causa das informações trasmitidas por esse protocolo que também é possível realizar a comunicação direta entre os nós e os cáculos referentes a alcance de sinal. As mensagens de registro de nós e de informações vizinhos serão especificadas abaixo Mensagem de registro de nós A primeira mensagem que um nó envia ao iniciar é a de registro, que é enviada para o host controlador de topologia. Ela serve para informar ao controlador de topologia sobre a existência do nó e todas as suas características. O primeiro campo dessa mensagem, chamado de TdM, é relativo ao tipo da mensagem, que tem valor em hexadecimal 0x02. Os campos seguintes, pos_x, pos_y e pos_z são relativos à posição do nó no espaço, na suas coordenadas x, y e z respectivamente. Essas coordenadas deverão ser dadas em metros, e necessariamente deverão ter valores positivos.

44 43 Após os campos relativos às posições do nó, o campo power_tx_dbm é responsável por informar a potência de transmissão do nó. Esse valor deverá ser informado em dbm, e poderá ser positivo ou negativo. Um valor comum encontrado em adaptadores para desktops ou notebooks é 20dBm, o que seria equivalente a 100 miliwatts. O próximo campo, o sens_rx_dbm tem como função informar qual a sensitividade do receptor que está se registrando, em dbm. Esse campo também pode receber valores positivos ou negativos, apesar dos valores encontrados em interfaces são comumente negativos (por volta de -70dBm, em interfaces sem fio para desktops ou notebook por exemplo). O último campo dessa mensagem aqui definida é o channel, que representa o canal em seu id de acordo com o IEEE Isso significa que nesse campo não deve ser informada a frequência. Por exemplo, no caso de se usar a frequência de 2412 MHz, deverá ser informado o canal IEEE correspondente, que nesse caso é 1. Apesar de estar sendo enviado, ainda não está implementado completamente no código como será visto na seção de implementação. Figura 5: Cabeçalho LVWNet usado para registro do nó. O nó envia a primeira mensagem de envio tão logo o módulo esteja carregado. Depois disso, ele periodicamente (definida através do #define LVWNET_REG_TIMER) reenvia mensagens de registro. Tais transmissões apesar de redundantes, são importantes pois não são realizados procedimentos de confirmação de recebimento de mensagens (ACK ) Mensagem de informações de nós Uma vez que o controlador de topologia já tenha ao menos dois nós que sejam comunicáveis entre si em sua lista, ele começa o envio de mensagens de informações dos vizinhos. Por vizinhos, entenda-se como os nós que estão no alcance de sinal do referido nó.

45 44 Essa mensagem, como pode ser vista na figura 6, utiliza o tipo 0x06 como identificador de mensagem LVWNet. Esse TdM, assim como na mensgem de registro identifica o tipo de mensagem que está logo após esse campo. Após o TdM, o campo peer_mac traz o endereço MAC ethernet do vizinho a qual essa mensagem corresponde. Tal endereço é aprendido pelo controlador de topologia ao nó se registrar pela primeira vez usando o campo de endereço de origem do quadro ethernet. O terceiro campo power_rx_dbm, informa com que potência o nó consegue receber o sinal do vizinho. Essa potência é calculada através da sensitividade do receptor do nó que está recebendo esta mensagem, a potência de transmissão do nó vizinho e a perda decorrente da distância (perda em espaço livre). O último campo, aqui chamado de delay informa o atraso inerente ao meio e à eletrônica. Essa última funcionalidade de atraso está prevista na mensagem, contudo ainda não implementada, não havendo diferença na transmissão, independente do tempo de atraso enviado. No campo de potência de recepção, dada a unidade de potência dbm poder ser positiva ou negativa, foi necessário usar dois bytes, do contrário estaríamos limitados a -127 a +127 dbm, que apesar de ser um range bem elástico, possível de se alcançável dependendo da sensitividade e potência do transmissor. Já no caso do atraso, é do tipo unsigned, o que nos dá um range entre 0 e Tendo em vista que a unidade aqui são milissegundos, teríamos um tempo máximo de atraso de 65 segundos para uma possível transmissão. As mensagens são enviadas em cada inclusão de novos nós na infraestrutura. Também são enviadas periodicamente informações sobre todos os vizinhos de todos os nós. O tempo em que isso ocorre é definido no #define LVWNET_INFO_TIMER. Um estado especial dentro da mensagem de informação sobre vizinhos é quando a potência de RX enviada é menor ou igual a -256dBm. Nesse caso, o nó entende que esse vizinho agora é inalcançável, e é removido de sua lista local de vizinhos Diagramas de trocas de mensagens De forma a facilitar o entendimento e documentar a implementação de forma adequada, temos 2 diagramas de trocas de mensagens entre os nós e o controlador, com uma visão de sequência entre cada uma das mensagens.

46 45 Figura 6: Cabeçalho LVWNet usado para informar um nó das configurações dos seus vizinhos Caso 1: 3 nós são alcançáveis entre si No primeiro diagrama da figura 7, temos 3 nós e um controlador. Nesses três nós, a potência de transmissão, diminuida da perda em espaço livre ainda é maior que a sensitividade de transmissão para todos os nós, ou seja, todos os 3 nós são alcançáveis entre si. Figura 7: Disposição dos nós do diagrama de troca de mensagens da figura 8. Assumimos que os 3 nós são ligados sucessivamente, de forma a exemplificar de forma mais detalhada o processo de registro, envio de informações sobre vizinhos e troca de dados entre todos os nós. Quando o nó 01 envia uma mensagem de registro, nenhum outro nó está registrado no controlador, o que faz com que ele somente armazene a informação de registro, sem nenhuma ação imediata. A ação de registro iniciada pela mensagem de registro do nó 02 faz com que o controlador realize os cálculos de distância entre os nós existentes, nesse caso somente 2, e de alcance de potência. Uma vez determinado que os nós 01 e 02 são alcançáveis entre si, ele envia uma mensagem para cada um informando sobre seus vizinhos, e detalhes como possíveis atrasos inerentes a distância ou à interface de rede sem fio e a potência de recepção calculada mais cedo.

47 46 Figura 8: Diagrama de troca de mensagens com os nós 01, 02 e 03 alcançáveis entre si. Uma vez que os nós 02 e 01 se conhecem, começam a trocar dados de forma direta, sem participação ativa da máquina de controle de topologia. Após o nó 03 se registrar no controlador de topologia, é calculada a distância e potência de alcance dos nós já existentes, e como nesse exemplo pressupomos que todos os nós são alcançáveis entre si, esta é suficiente para que os nós 1, 2 e 3 façam parte de uma mesma rede. Após esse cálculo, é enviado para o nó 01 e 02 uma mensagem com informações sobre o novo vizinho, o nó 03. E para o nó 03 são enviadas 2 mensagens, uma contendo informações sobre o nó 01, e outra contendo informações sobre o nó 02. Uma vez que todos os nós são alcançáveis, podem realizar trocas de quadros encapsulados em quadros ethernet Caso 2: Nó 01 e 02 são alcançáveis entre si, nós 03 e 04 também, mas não entre eles Nesse caso em específico, temos dois clusters, cada um com 2 nós, isolados entre si. No primeiro temos o nó 01 e 02, e no segundo cluster temos o nó 03 e 04.

48 47 Na figura 9 temos a uma possível representação de como esses nós poderiam estar dispostos, deixando clara a não comunicação entre os dois agrupamentos de nós. Já na figura 10, temos o diagrama completo de troca de mensagens de todos os nós. Figura 9: Disposição dos nós do diagrama de troca de mensagens da figura 10. No início, temos o registro dos nós 01, 02 e 03 no controlador de topologia. Contudo, nesse momento ao calcular a distância entre os nós, é verificado pelo controlador que os nós 01 e 02 não tem potência ou sensitividade suficiente para comunicar-se com o nó 03, e vice-versa. Dessa forma, o nó 03 não recebe nenhuma mensagem de informação de vizinhos nesse momento, e o nó 01 recebe informações sobre o nó 02, e o nó 02 recebe informações sobre o nó 01, como esperado. Figura 10: Diagrama de troca de mensagens com os nós 01, 02 alcançáveis entre si, nós 03 e 04 também, mas não entre eles.

49 48 Uma vez que o nó 04 registra-se no controlador de topologia, este ao realizar os cálculos de potência e verificar que os nós 03 e 04 estão próximos o suficiente para poder comunicar-se, envia uma mensagem para o nó 03, contendo informações sobre o nó 04, e outra mensagem ao nó 04, contendo informações sobre o nó 03. Em nenhum momento o nó 03 e 04 recebem qualquer mensagem de informações do nó 01 ou 02 e vice-versa Interação da rede LVWNet Virtual com hardwares reais A interação com equipamentos reais permite que diversas máquinas reais que possuem apenas interfaces Wifi físicas, ou seja reais, participem da rede virtual. Para isso, uma (ou mais) máquina que possui uma interface Wifi real, e uma interface Ethernet, deve executar o software LVWNet de modo a fazer a interligação da rede real com a virtual. Pode existir diversas outras máquinas reais (e que não usam o LVWNet) interconectadas a esse host que faz a ligação com a rede virtual, formando, por exemplo, uma rede em malha sem fio. Nessa situação, o host real estabelece peer-links tanto com os guests virtuais que estão executando o módulo do LVWNet como com os outros hosts reais que não tem qualquer modificação. A máquina controladora de topologia não sabe da existência dessas máquinas, mas elas conseguem se comunicar com as máquinas virtuais, sem saber que elas são de fato virtuais. Essa máquina que faz a interligação das duas redes aparecerá para a rede virtual como se fosse também uma máquina virtual. Ou seja, para a máquina controladora de topologia não existe diferenca entre essa máquina real ou uma máquina virtual. Desse modo, quando a máquina real é inicializada ela se registra na máquina de topologia do mesmo modo que qualquer outra máquina virtual faz, e sua interface Wifi real não é vista por ela. É importante observar que nesse caso não será criada um interface Wifi virtual quando o módulo LVWNet é carregado na máquina real, uma vez que será utilizada a interface Wifi real. Pode-se observar que existem três situações para tratamento de quadros, que são descritas a seguir. A primeira situação se refere ao caso onde a máquina real recebe um quadro em sua interface Ethernet vindo da rede virtual. Nesse caso, o quadro IEEE encapsulado no Ethernet deve ser encaminhado para processamento pelo mac80211 da máquina como se tivesse sido recebido pela sua interface Wifi real.

50 49 A segunda situação se refere ao caso onde a máquina real recebe um quadro em sua interface Wifi real, vindo portanto, de alguma máquina da rede sem fio real onde ele está conectado. Nesse caso, não existe nenhum procedimento especial a ser feito, de modo que o quadro IEEE é encaminhado para processamento pelo mac80211 da máquina local. A terceira situação é a mais interessante e se refere ao caso onde a máquina real gera um quadro IEEE para ser retrasnmitido. Nesse caso além de enviar o quadro normalmente pela sua interface Wifi real, deve-se também gerar uma cópia do mesmo, encapsular esse quadro em um quadro LVWNet e transmití-lo pela interface Ethernet. Naturalmente, esse quadro encapsulado será transmitido para todos os nós que são alcancáveis por essa máquina na rede virtual

51 50 5 Detalhes de Implementação Nesse capítulo serão apresentados os detalhes de implementação de todas as propostas de alteração no LVWNet, como a parte relativa ao ingresso de máquinas com interfaces de rede sem fio reais em uma rede virtual LVWNet, a implementação do protocolo de registro e suas mensagens. Protocolo esse que permitiu o posicionamento de nós no espaço além da comunicação direta entre nós, elimitando a necessidade de encaminhamento de quadros para o host de topologia. 5.1 Ingresso de máquinas com hardware sem fio real em uma rede LVWNet Nessa seção serão apresentados os detalhes de implementação relativos a porção do código destinada a realizar a inserção do host com interfaces sem fio reais em uma rede com várias máquinas virtuais Tomadas de decisões para o projeto Como já mencionado no capítulo introdutório, o projeto tem como um de seus objetivos permitir a interação de uma rede mesh IEEE real, com uma rede criada pelo LVWNet, para que com isso possamos aumentar a funcionalidade do projeto, permitindo testes mais extensos e com hardwares reais. Para atender tal objetivo, duas estratégias poderiam ser adotadas. A primeira seria a criação de uma interface do tipo monitor, que funciona de forma promíscua, ou seja, ela encaminha para a camada superior da pilha de protocolos todos os quadros recebidos, mesmo que não tenham como destino a própria interface ou endereços de broadcast. Nessa abordagem, teríamos um processo em espaço de usuário que seria encarregado de analisar essa interface, e encaminhar para uma interface real os quadros recebidos. De

52 51 forma análoga, teríamos que utilizar a mesma estratégia também na interface real, sendo necessário na verdade a criação de duas interfaces do tipo monitor. Sua principal vantagem seria a facilidade de implementação, pois toda a programação seria feita em espaço de usuário, podendo inclusive se utilizar de linguagens de alto nível de abstração, como Phyton, onde temos um conjunto de módulos chamado Scapy(COMMUNITY, Abril 2010), que permite a manipulação de quadros IEEE Por outro lado, a principal desvantagem dessa abordagem é justamente a redução do desempenho decorrente da utilização do espaço de usuário para o desenvolvimento. Desse modo, poderíamos ter problemas de escalabilidade em redes de grande porte. Outra desvantagem seria a dificuldade de embarcar tal solução em equipamentos com poder de processamento e armazenamento limitados, como pontos de acesso ou roteadores. Tais equipamentos normalmente não trazem nenhuma ou quase nenhuma implementação do python dentro deles, impossibilitando ou dificultando muito seu uso de forma embarcada. A outra estratégia possível de ser utilizada seria a programação em kernel space, criando-se um módulo para o kernel e realizando-se modificações onde fossem necessário dentro de sua árvore principal. Essa foi a estratégia adotada para o projeto pois resolve as duas limitações existentes na estratégia anterior. Desse modo, o módulo LVWNet se registra como manipulador do protocolo tipo 0x0808, desencapsula o quadro IEEE e o injeta na interface wireless real. Vale ressaltar que 0x0808 foi o valor escolhido para indicar a presença de um quadro LVWNet no payload do Ethernet. Para o recebimento através da rede ethernet do quadro, foi somente necessária a criação de um módulo para tal. Já no envio de um quadro através da interface de rede real wireless, seria necessário realizar uma interceptação desse quadro antes dele ser enviado e liberado, encapsulá-lo dentro de um quadro ethernet de ethertype 0x0808, e dependendo da versão do LVWNet, encaminhá-lo para o controlador de topologia, ou diretamente para os vizinhos e posteriormente permitir que esse quadro prossiga seu caminho natural, sendo enviado para a camada MLME da interface de rede sem fio. Para tal procedimento, foi necessária a modificação do módulo mac80211 original, sendo inseridos algumas funções que nos permitissem a criação da cópia do quadro e encaminhamento para outro módulo. Como será visto, tentamos realizar o mínimo de alterações dentro do módulo original, concentrando o desenvolvimento em nosso próprio módulo.

53 Implementação Como utilizamos a estratégia de programação em espaço de kernel, foi criado um módulo, chamado de lvwnet_node, em referência a ser um nó, e não um controlador para o projeto LVWNet. Ele tem como dependência somente o módulo mac80211 em sua versão modificada, pois faz referência a chamadas externas exportadas pelo mac A pilha de rede do Linux Pode-se afirmar que uma das estruturas mais importantes da pilha de rede do linux são os socket buffers, ou simplesmente skb (MILLER, 2000). skb é a estrutura mais básica da pilha de rede no Linux, todos os quadros 1, pacotes 2, e TPDUs, ou Transport PDU 3 são manipulados através dessa estrutura. Quando um quadro é recebido por uma interface rede, ele é colocado dentro dessa estrutura chamada skbuffer, e então passada para as camadas superiores, sempre a mesma estrutura e o mesmo ponteiro (WELTE, 2000). Então cada camada só usa a parte que lhe cabe, percorrendo no ponteiro a área que é de sua responsabilidade. Esse tipo de estratégia evita que o quadro seja repetidamente copiado podendo gerar problemas de performance ou até mesmo memory leak, e quando isso é realmente necessário (uma cópia), a implementação da pilha de rede do Linux dá as ferramentas apropriadas, como a função skb_copy, que permite a cópia de forma atômica do skb para outra variável Módulo mac80211 modificado Como base para desenvolvimento, inicialmente usamos o kernel que já trouxe algumas modificações em relação ao último kernel marcado como long term 4 no módulo mac As principais modificações foram nas funções que liberam o skb. Contudo atualmente já estamos utilizando o último kernel disponível no fedora, que é o 1 quadro é a PDU da camada de enlace (TANENBAUM; WETHERALL, 2011) 2 pacotes é a PDU da camada de rede (TANENBAUM; WETHERALL, 2011) 3 TPDU é a PDU da camada de transporte (TANENBAUM; WETHERALL, 2011) 4 kernels marcados como long term são aqueles que além de estáveis, são lançados somente 1 long term por ano, e tem seu desenvolvimento com correções e garantidas por pelo menos dois anos (ORGANIZATION, 2014)

54 para todos os projetos, tanto o LVWNet em si, como para o mac80211 e para o mac80211_hwsim. Para permitir a comunicação entre máquinas virtuais com interfaces também virtuais com hosts reais utilizando interfaces reais, foram feitas alterações nas funções do mac Essa abordagem, como já mencionado, tem uma pequena limitação, que é restringir seu uso a somente hardwares compatíveis com a implementação SoftMAC, onde a camada MLME é toda implementada no módulo mac Contudo, hoje já existem muitas interfaces compatíveis com esse padrão, como por exemplo as baseadas em chipset Atheros, Richtec (linha RT8XXX e acima) etc. No mac80211, foi modificada a função ieee80211_tx(), que é responsável pelo envio do sk_buff para a camada PHY. Antes do envio efetivo para a camada PHY, o sk_buff é copiado e enviado para o módulo lvwnet_node através de apontadores de memória, encapsulado em um quadro ethernet e enviado para os seus nós vizinhos. Detalhes desses procedimentos serão vistos adiante, onde temos um diagrama de sequência com as chamadas de funções envolvidas na transmissão. Já no recebimento do quadro IEEE , não existe a necessidade de modificação do módulo mac80211 diretamente, e sim a chamada da função ieee80211_rx_irqsafe(), que insere o quadro recebido via ethernet diretamente na pilha IEEE Também serão tratados detalhes maiores sobre isso no diagrama de sequência adiante Módulo lvwnet_node O módulo lvwnet_node é o que fica carregado no host, seja real ou virtual. Ele é responsável tanto por receber os quadros encaminhados via ethernet e injetá-los na pilha IEEE , como por receber os sk_buff do mac80211 modificado, encapsulá-los em um quadro ethernet e enviá-lo para os hosts vizinhos. Também é sua função receber as mensagens de informações sobre nós, atualizando a sua tabela interna de vizinhos, como também enviar as informações de registros e de modificação de posição do nó. Como base para o seu desenvolvimento foi tomado o módulo mac80211_hwsim modificado pela versão inicial do projeto LVWNet Módulo lvwnet_controller O módulo lvwnet_controller é o responsável por coordenar a comunicação entre os nós, atualizando suas tabelas de vizinhos, ou até mesmo encaminhando quadros,

55 54 dependendo do seu modo de operação. É sua responsabilidade o envio de mensagens com informações sobre vizinhos para os nós participantes da rede, e também a manipulação das mensagens de registro recebidas, realizando os cálculos de proximidade entre os nós determinando se existe ou não comunicação entre eles. 5.3 O protocolo de registro e informações de nós na rede Nessão seção serão apresentados os detalhes de implementação do protocolo desenvolvido para o projeto LVWNet. Iremos abordar as estruturas de dados utilizadas e as funções que são chamadas durante o processo de registro e envio de informações para os nós. Como citado anteriormente, o protocolo desempenha duas funções separadas, sendo utilizado pelas máquinas para se registrarem no controlador de topologia, e pela máquina de topologia para transmitir para os nós as informações sobre quem são seus vizinhos O processo de registro dos nós Como já abordado com mais detalhes anteriormente, o protocolo de registro é utilizado por cada nó para transmitir ao controlador informações sobre o nó, como sua posição no espaço (dada em coordenadas x, y e z), a potência de transmissão e sensibilidade de recepção da interface sem fio. De forma a aproveitar a utilização da estrutuda de dados sk_buff da pilha de rede do Linux, criamos um struct com os campos da mensagem (código 5.1), exatamente na ordem em que são enviados os dados na rede. Além da ordem, é importante o uso do atributo packed no final do struct, de forma a orientar o compilador a não tentar otimizar a alocação de memória do struct, e sim fazer sua alocação linear. Isso é importante para que quando formos apontar o struct para o começo do payload do sk_buff (código 5.2), a ordem dos dados seja preservada, da forma como está no código struct lvwnet_reg_omni_header 2 { 3 uint8_t message_code; //1 byte 4 uint32_t pos_x; //4 bytes 5 uint32_t pos_y; //4 bytes 6 uint32_t pos_z; //4 bytes 7 int16_t power_tx_dbm; //2 bytes 8 int16_t sens_rx_dbm; //2 bytes

56 55 9 uint16_t channel; //2 bytes 10 } attribute ((packed)); Código 5.1: Struct da mensagem de registro do LVWNet No struct mostrado no código 5.1, pode-se observar que algumas variáveis como message_code, as variáveis reponsáveis pelas coorenadas x, y e z, e o canal são todas do tipo unsigned, o que significa que nenhum bit do do tipo (por exemplo, o tipo uint8_t tem 1 byte) é utilizado para alocação do sinal, e por definição todos os valores são positivos. Contudo, informações como potência em dbm, necessariamente tem que ser tratadas usando valores tanto negativos como positivos. 1 struct lvwnet_reg_omni_header* lh_reg_omni=null; 2 //... 3 lh_reg_omni = (struct lvwnet_reg_omni_header *) skb_recv->data; 4 //... Código 5.2: Apontador do payload do skb para o struct da mensagem de registro Ao se carregar o módulo, o timer inicia com um tempo de 5 segundos, o que significa que depois de iniciado, ele irá esperar 5 segundos para enviar a primeira mensagem de registro para o controlador de topologia. Depois do primeiro timer, ele é redefinido de forma que a próxima mensagem de registro seja enviada depois de TIMER_SEND_REG 5 segundos O protocolo de informações sobre vizinhos Inicialmente o projeto LVWNet previa que toda comunicação entre os nós necessariamente deveriam passar pelo host controlador de topologia. Contudo, isso pode gerar problemas de escalabilidade em redes com grandes quantidades de nós. Um dos motivos da criação do protocolo para registro de nós e de envio de informações sobre vizinhos foi justamente a retirada dessa limitação, permitindo que os nós possam comunicar-se entre si diretamente. Desse modo, o controlador de topologia age apenas como um supervisor, que informa aos nós o alcance do seu sinal, para que os quadros possam ser encaminhados diretamente para os seus vizinhos. Temos uma função no controlador de topologia responsável por calcular os vizinhos de cada nó. Essa função é chamada em duas ocasiões. Na primeira, quando um novo nó é inserido na lista de nós do controlador de topologia, ou seja, quando existe um novo pedido de registro, e na segunda, quando o timer é disparado, que tem o tempo definido 5 valor definido no arquivo lvwnet_proto.h em com o valor de 120

57 56 em LVWNET_SEND_INFO_NODES 6 em segundos, é alcançado. Após esse tempo, uma mensagem informando quem são os vizinhos do nó é enviada (para cada nó da rede). O struct que representa a mensagem da figura 6 está no código 5.3. Pelo mesmo motivo do struct do código 5.1, ele tem a propriedade packed, de forma a orientar ao compilador não tentar otimizar a organização das variáveis na memória (FOUNDATION, 2002), ocupando o mínimo de memória possível. Um detalhe de implementação que vale ser mencionado, foi a impossibilidade de chamadas da biblioteca math.h dentro do módulo. Chamadas para essa biblioteca não são possíveis em kernel space. Isso dificultou de forma razoável o cálculo dos vizinhos dos nós, tendo em vista que os cálculos de L F S envolvem funções de log, que não são simples de ser realizadas somente com operações básicas, como as disponíveis kernel space. Uma estratégia utilizada foi o cálculo prévio da perda em espaço livre de todas as frequências em uma faixa de distância entre 1 metro a 100 Km. Dada a característica logarítima do dbm, para cada frequência, tivemos por volta de 120 valores possíveis de perda em espaço livre. Esse cálculo foi realizado também para cada uma das frequências reguladas pelo IEEE , indexada pelo número do canal da frequência, de forma a facilitar a busca, evitando percorrer o vetor de frequências sempre. Uma vez explicado esse detalhe de implementação, fica claro que nosso módulo só pode realizar simulações para uma distância máxima de 100 Km. Contudo, em situações reais isso já é bem aceitável, dado que em grandes distâncias a comunicação sem fio em frequências da ordem da utilizada pelo IEEE (entre 2.4 e 5.8 GHz) é muito suscetível a interferências e a atenuações decorrentes da característica concêntricas das zonas de Fresnel. O resultado desses cálculos foram todos encapsulados no arquivo lvwnet_lfs.h. Lá também estão as funções de cálculo de distância e de busca desses valores nos vetores e estruturas definidas. 1 struct lvwnet_peers_info_header 2 { 3 uint8_t message_code; //1 byte 4 unsigned char peer_mac[eth_alen]; //6 bytes 5 int16_t power_rx_dbm; //2 bytes 6 uint16_t delay; //2 bytes - in ms 7 } attribute ((packed)); Código 5.3: Struct da mensagem de informações de vizinhos do LVWNet 6 valor definido no arquivo lvwnet_proto.h em com o valor de 60

58 Comunicação direta entre os nós Anteriormente, já tratamos como os nós realizam seus registros no controlador de topologia, detalhando as mensagens envolvidas e seus procedimentos internos no módulo lvwnet_controller e lvwnet_node. Também foi tratado com detalhes como o controlador de topologia envia informações sobre os vizinhos de cada nó, de forma que o nó possa enviar os dados diretamente para as interfaces ethernet dos seus vizinhos, sem passar mais pelo controlador de topologia. Nesse momento serão observadas as chamadas de funções realizadas pelos módulos para que seja concretizada a troca de dados entre dois vizinhos. Na figura 11, temos um diagrama de sequência que mostra as chamadas das funções mais importantes quando é realizado um envio de dados entre dois vizinhos. Assumimos que os dois nós já se conhecem (sabem que são vizinhos), de modo que não existe mais a necessidade de nenhuma outra intervenção por parte do controlador de topologia. Além disso, é assumido que se trata de uma mensagem partindo do nó 01 para o 02. Quando uma aplicação em user space envia um pedido de envio de dados para a pilha de rede do Linux, e uma vez verificado que o módulo adequado para manipulação do pedido é o mac80211, a função ieee80211_tx() é chamada. Essa função é responsável por fazer algumas verificações básicas no skb, como o tamanho, por exemplo, e inicializar as estruturas de transmissão. Depois disso, a função faz uma chamada a uma outra função cujo nome é ieee80211_tx(), que não é exportada, ou seja, só pode ser vista internamente no módulo. Essa função é quem realmente faz as chamadas à camada PHY. Imediatamente antes da chamada da função ieee80211_tx(), onde há a liberação e modificação do skb, é chamada a função lvwnet_send_skb_from_mac80211(). Essa função lvwnet_send_skb_from_mac80211() é responsável por enviar o quadro skb do módulo mac80211 para o módulo lvwnet_node. Esta função envia o apontador do começo do endereço de memória do skb para o módulo lvwnet_node, não antes de verificar se o módulo já está carregado. Uma vez que isso é sempre feito através de apontadores, o atraso gerado por esses procedimentos são mínimos. O que poderá gerar um maior atraso na verdade é a transmissão via ethernet, apesar desta também ser assíncrona. Uma vez que o quadro já está disponível no módulo lvwnet_node, o nó verifica seus vizinhos, e envia o quadro para os que forem alcançáveis. Esse envio é feito através

59 58 Figura 11: Diagrama de sequência de chamadas de funções entre os módulos mac80211 e lvwnet_node. da função ethernic_send(). Como parâmetros ele recebe o skb, o endereço MAC de destino, e o dispositivo de rede por onde ele deve ser enviado, que deve ser a interface ethernet usada para transmissão dos quadros IEEE encapsulados. Algumas verificações básicas são realizadas na função ethernic_send(). Uma delas é verificar se o skb tem espaço reservado disponível para agregação do cabeçalho ethernet. Vale lembrar que esse cabeçalho, que tem 14 bytes, é composto por 6 bytes do endereço MAC de origem, mais 6 bytes do endereço MAC de destino (recebido como parâmetro da função) e mais 2 bytes reservados ao ethertype/length, que é responsável por informar que tipo de protocolo está encapsulado no quadro ethernet ou o tamanho do payload/data do quadro. Caso esse número seja menor ou igual a 1500 (representação hexadecimal 0x05DC), esse campo será considerado como tamanho do campo data do quadro, caso seja maior ou igual a 1536 (representação hexadecimal 0x600), o campo será considerado como ethertype. Em (IEEE, 2012c) a partir da página 56, temos mais detalhes sobre esse campo. No caso do projeto LVWNet, estamos usando o ethertype de número 0x0808, que atualmente não está em uso por nenhum protocolo, apesar de reservado para a Xerox (IEEE, 2012a). A título de exemplo, todo quadro que tiver o ethertype definido como 0x0800 é um quadro com o protocolo IP encapsulado. Uma vez que o skb tenha tido o cabeçalho ethernet adicionado com as informações para o novo host, é feita a chamada à função dev_queue_xmit(), que é responsável por colocar o quadro na fila de transmissão.

60 59 1 static struct packet_type pkt_type_lvwnet = { 2.type = htons(0x0808), 3.func = ethernic_recv, 4 }; 5 /** (...) */ 6 static int init init_lvwnet(void) 7 { 8 /** (...) */ 9 dev_add_pack(&pkt_type_lvwnet); 10 /** (...) */ 11 } Código 5.4: Registro do ethertype 0x0808 e sua função manipuladora Nesse ponto, o quadro efetivamente deixa o nó 01 com destino ao nó 02. A função responsável pela recepção de quadros de ethertype 0x0808 é a ethernic_recv(). Essa função é registrada através da inicialização dos valores da estrutura packet_type, que é definida no arquivo netdevice.h. Uma vez que os valores são colocados na iniciação da estrutura, ela deve ser registrada através da função dev_add_pack(), que é chamada junto com a inicialização do módulo, realizada pela função interna do LVWNet init_lvwnet(). A forma como essas funções são usadas dentro do nosso projeto pode ser vista no código 5.4. Dentro da função ethernic_recv(), são realizadas verificações, de forma a analisar a consistência do quadro. Após essas verificações, é feita a identificação do quadro, ou seja, se ele é um quadro de registro, de informações ou de dados. Isso é feito ao inspecionar-se o primeiro byte do campo data do skb. No nosso caso em específico, estamos analisando a troca de mensagens de dados, logo o primeiro byte é o que está no #define LVWNET_CODE_DATA. Isso pode ser observado na figura 12. Figura 12: Amostra de tráfego do tipo data capturado na ethernet. Nessa figura 12, temos uma comunicação entre o host aa:aa:aa:00:01:01 enviando um quadro de dados para o host aa:aa:aa:11:00:00. O payload do quadro

61 60 Ethernet consiste do quadro IEEE precedido pelo cabeçalho LVWNet. Desse modo, pode-se observar que se trata de uma mensagem de broadcast, pois o primeiro endereço definido no quadro IEEE é o ff:ff:ff:ff:ff:ff, e o segundo endereço é o ea:aa:aa:00:01:01, que é o endereço MAC da interface wireless desse host. Uma vez que o módulo lvwnet_node já analisou o quadro e o classificou como do tipo data, sabe-se que o cabeçalho LVWNet é composto apenas por um byte no começo do payload. Para obter o quadro IEEE encapsulado deve-se então retirar esse byte. Para isso, o skb tem seu campo data, que aponta para o início do payload, decrementado em um byte. Isso é feito através da função skb_pull(). Após isso, o campo data é uma representação fiel do quadro IEEE transmitido pelo nó 01, e que chegou no nó 02. Para injetá-lo novamente na pilha de rede, de modo que possa ser processado pelo mac80211, usamos a função ieee80211_rx_irqsafe(), que é a mesma usada pela camada PHY do driver para injetar quadros que chegaram através do hardware comum. Como pode-se observar, não há diferenciação de quadros que chegaram via a camada PHY comum, e quadros que chegaram através do LVWNet, via rede ethernet. Uma vez que o quadro é injetado na pilha de rede o próprio módulo mac80211 agora é o responsável por tratar os quadros, e enviá-los às aplicações adequadas, com a análise da estrutura skb nas camadas superiores. 5.5 Uso dos Módulos Nessa seção será apresentada a forma como os usuários devem utilizar os módulos do LVWNet, ressaltando os parâmetros que podem ser definidos e como obter informações dos módulos através do sysfs. Detalhes de como baixar e compilar o código atual podem ser vistos no Apêndice A Carga dos módulos Uma vez que as dependências já foram resolvidas, para carregar utiliza-se os parâmetros a seguir. Naturalmente, os diversos módulos do LVWNet não utilizam os mesmos parâmetros. Abaixo são mostrados os parâmetros suportados pelo módulo lvwnet_node. x_pos=int define a posição x do nó (em metros);

62 61 y_pos=int define a posição y do nó (em metros); z_pos=int define a posição z do nó (em metros); power_tx_dbm=int define a potência de transmissão do nó (em dbm); sens_rx_dbm=int define a sensitividade de recepção do nó (em dbm); channel=int define o canal em que o nó opera (deve-se usar o número do canal, não a frequência); ethernic_name=string informa qual o nome da interface de rede ethernet que o host deve usar para comunicação e encapsulamento dos quadros IEEE (ex.: eth0, ens9 etc); send_all_to_controller=(1 0) informa ao módulo se ele ao invés de enviar as mensagens diretamente para os vizinhos, deve enviar para o controlador de topologia. Essa configuração é útil quando se deseja ter um ponto central para inspecionar todas as mensagens trafegadas, ou se deseja comunicação entre as versões anteriores do LVWNet, que tinham esse comportamento por padrão; ctrl_host_addr=mac_address informa o endereço MAC ethernet do controlador. Não deve-se usar ponto, dois pontos ou espaços para dividir os octetos do endereço MAC. Desses parâmetros, o único que não é obrigatório é o channel. Por padrão, este é definido como 1. Contudo, apesar de aceitar esses parâmetros, o cabeçalho radiotap ainda não é formado usando essas informações. Um exemplo de uma carga do lvwnet_node é dada no código [leo@nabucodonosor ~]\$ sudo insmod lvwnet_node.ko ethernic_name=ens9 \ 2 ctrl_host_addr=aaaaaa \ 3 x_pos=100 y_pos=200 z_pos=300 \ 4 power_tx_dbm=20 sens_rx_dbm=-75 Código 5.5: Exemplo de como carregar o módulo lvwnet_node Nessa linha de comando, o endereço MAC do controlador é o AA:AA:AA:11:00:00, a posiçao x do nó é 100 (metros), a y é 200 e a z é 300 (metros). A potência de transmissão assumida é de 20 dbm e a de sensitividade de recepção é de -75 dbm. O módulo lvwnet_controller não tem nenhum parâmetro por padrão, e também não tem nenhuma dependência de outros módulos, pois ele realiza um trabalho somente

63 62 de coordenação dos nós, realizando cálculos e enviando mensagens de posicionamento de nós Informações disponbilizadas via sysfs O sysfs é um sistema de arquivos em memória que é muito utilizado pelo kernel para disponibilizar informações do kernel space para o user space de modo simples. Seu modo de operação é bastante simples. Ao se ler um arquivo do sysfs se consegue obter informações do kernel, e ao se gravar um dada informação em um arquivo do sysfs se está enviando a referida informação para o kernel. Os módulos do LVWNet utilizam o sysfs para disponibilizar acesso à informações sobre os seus estados, fornecendo alguns dados, como por exemplo os vizinhos recebidos, quantidade de mensagens por tipo etc. O raiz dos arquvos do sysfs do LVWNet é /sys/kernel/lvwnet. Temos alguns arquivos diferentes dependendo se o host opera como um nó ou como controlador. No caso do módulo lvwnet_node, ou seja, o host operando como nó, temos a lista de arquivos abaixo e o que cada um representa. qtd_peers: informa quantos vizinhos o nó tem; oper_mode: informa se o host trabalha como nó (saída do arquivo node) ou como controlador (saída do arquivo controller); peers_list: tem como saída uma lista de todos os vizinhos do nó, com a potência; qtd_data_msg: quantidade de mensagens de dados recebida pelo nó; qtd_info_msg: quantidade de mensagens de informações sobre vizinhos recebida pelo nó; qtd_all_msg: quantidade de mensagens recebidas, independente do tipo. Já no caso do host estar trabalhando como um controlador, os arquivos são os seguintes: qtd_nodes informa quantos nós estão registrados no controlador;

64 63 oper_mode informa se o host trabalha como nó (saída node) ou como controlador (saída controller); nodes_list tem como saída uma lista de todos os nós que se registraram no controlador com a potência de transmissão, sensitividade de recepção, e posição x, y e z; nodes_gnu_plot tem como saída todos os nós em formato pronto para plotagem do gnuplot, de forma a dar uma idéia de posicionamento em 3D dos nós registrados neste controlador; qtd_reg_omni_msg quantidade de mensagens de registro de nós usando a mensagem de registro de nó omnidirecional;

65 64 6 Análise do LVWNet Este capítulo tem como objetivo relatar as abordagens e metodologias utilizadas para realização de testes, com objetivo de validar a construção do projeto concebido e detalhado nos capítulos anteriores. 6.1 Criação automática de peer links com dispositivos reais Para os testes de inserção de um nó com hardware real em uma rede LVWNet, utilizamos uma interface wireless USB compatível com SoftMAC. O modelo escolhido foi o WBN900 da Intelbras. Ele é compatível com IEEE s (mesh), que foi o tipo de rede escolhida para a realização dos testes. Foi criada uma rede com 3 nós virtuais e 1 real. A tabela 1 traz a lista de todos os endereços MAC e dos endereços IP dos nós envolvidos. Tabela 1: Endereços MAC Ethernet e WLAN dos nós para teste de inserção de um nó real Nó Ethernet(ens9) WLAN (wlan0) IPv4 nó 01 aa:aa:aa:00:01:01 02:00:00:00:01: /8 nó 02 aa:aa:aa:00:01:02 02:00:00:00:01: /8 nó 03 aa:aa:aa:00:01:03 02:00:00:00:01: /8 nó real fe:54:00:32:2d:dc 00:1a:3f:a5:74:e /8 A posição inicial dos 4 nós (3 virtuais e 1 real) no espaço é especificada na tabela 2. O nó real foi propositalmente colocado em um espaço de interseção dos nós 01 e 02, de forma que ele deva estabelecer dois peer links individuais com cada um desses hosts. O nó 03 não tem comunicação com nenhum outro nó. Para os testes, utilizaremos uma rede IEEE s simples, mas que permite constatar a criação dos peer links e realizar testes básicos de conectividade.

66 65 Tabela 2: Posições iniciais dos nós virtuais e do real Nó x y z nó m 500m 10m nó m 1300m 10m nó m 500m 10m nó real 700m 800m 10m Na máquina real, uma vez carregados o módulo mac80211 modificado, o lvwnet_node e inserida a interface de rede USB (que realiza a carga dos módulos necessários automaticamente), é preciso definir a interface como sendo do tipo mesh. Tal tarefa está mostrada na figura 13, onde deve-se observar que a interface Wifi dessa máquina, que havíamos citado como wlan0, é de fato chamada de wlp0s26f7ulu3. Figura 13: Definindo a interface real como sendo do tipo mesh. Uma vez que a interface está definida corretamente e é realizado o scan inicial, é possível observar os peer links criados com os nós virtuais na figura 14. Finalmente, pode-se realizar um teste de conectividade básico com ping, e verificar a tabela de encaminhamento de layer 2 do mesh na figura 15.

67 66 Figura 14: Peer links do host real com as máquinas virtuais. Figura 15: Teste básico de conectividade e tabela de encaminhamento layer Simulação de mobilidade de um nó O objetivo desse teste é verificar o estabelecimento e o cancelamento de peer links a medida que um nó (virtual) se movimenta. A alteração das coordenadas que indicam a posição do nó será feita utilizando o sysfs. Nesse experimento, temos apenas 3 nós de forma a facilitar a visualização dos links estabelecidos entre eles decorrentes da mobilidade. Os endereços dos nós são mostrados na Tabela 3. Tabela 3: IPs e endereços MAC ethernet e WLAN dos nós Nó Ethernet(ens9) WLAN (wlan0) IPv4 nó 01 aa:aa:aa:00:01:01 02:00:00:00:01: /8 nó 02 aa:aa:aa:00:01:02 02:00:00:00:01: /8 nó 03 aa:aa:aa:00:01:03 02:00:00:00:01: /8 Todos os nós estão com a mesma coordenada z, o que implica em um deslocamento 2D, como em um espaço plano. Serão realizados alguns cálculos para encontrar o alcance máximo de um nó, assumindo que todos eles tem uma potência de transmissão de 20dBm e sensitividade de recepção de 75dBm.

68 67 Como já visto no capítulo 4, a equação de cálculo de perda no espaço livre, já simplificada é dada por 6.1. L F S = log 10 (f) + 20log 10 (D) (6.1) Uma vez que sabe-se tanto a potência de transmissão como sensitividade de recepção, e se quer encontrar o alcance de um determinado nó, pode-se modificar a equação de forma como está apresentada na equação 6.2. L F S = log 10 (f) + 20log 10 (d) 20log 10 (d) = L F S log 10 (f) (6.2) Como já é conhecida a potência de transmissão (20dBm) e a sensitividade de recepção é de 75dBm, logo a maior perda no espaço livre possível para essas duas características será de 95dBm. Para a frequência de 2412 MHz, temos a equação dada em 6.3. L F S = log 10 (f) + 20log 10 (d) 20log 10 (d) = log 10 (2412) 20log 10 (d) = ( ) 20log 10 (d) = d = m (6.3) Vê-se na equação 6.3 que a distância onde se tem uma perda de exatamente 95dBm é de aproximadamente 556 metros. Em um ambiente real esse valor seria bem menor, pois teríamos outros fatores de interferência, como objetos no caminho, outras transmissões em frequências próximas etc. Além disso, isso seria um valor limítrofe entre um estado de comunicação e não comunicação. Contudo, em transmissores reais quanto menor a potência do sinal, menor também a taxa de transmissão, que no pior caso de se estar muito próximos do limite de 556 metros, também se estaria na menor taxa de transferência possível. Entretanto, nenhum desses fatores é levado em consideração nesse ambiente. Em nosso teste, o primeiro nó está localizado na posição x = 500, y = 500 e z = 10 metros. Já o segundo nó está na posição x = 600, y = 1300 e z = 10 metros. Eles estão propositalmente afastados o suficiente para que se possa observar como um nó estabelece os peer links a medida que se movimenta no espaço. Ambos os nós 01 e 02 estão fixos e localizados à 806 metros um do outro, e tem uma perda em espaço livre entre eles de 98dBm. Já o terceiro nó, irá iniciar na posição x = 1200, y = 500 e z = 10 metros. Ele está

69 68 na mesma coordenadad y do nó 01, mas afastado exatamente 700 metros na coordenada x (L F S = 97dBm) o que torna ele inalcançável pelo nó 01 neste momento. Na tabela 4 temos as coordenadas de todos os nós antes do nó 03 começar a se movimentar. Tabela 4: Posições iniciais dos nós Nó x y z nó 01 (fixo) 500m 500m 10m nó 02 (fixo) 600m 1300m 10m nó 03 (móvel) 1200m 500m 10m Nessa configuração, não há nehuma comunicação entre os nós. Definimos as posições para análise do nó 03 como milestones. No milestone 01, ele está na posição x, y, z = 1200, 500, 10 metros. Na tabela 5, temos uma lista de todos as posições do nó 03. Tabela 5: Posições de cada um dos milestones do nó 03 Milestone x y z Sinal nó 01 Sinal nó 02 milestone m 500m 10m -97dBm (700m) -100dBm (1000m) milestone m 500m 10m -86dBm (200m) -98dBm (806m) milestone m 700m 10m -93dBm (447m) -96dBm (670m) milestone m 800m 10m -91dBm (360m) -94dBm (509m) milestone m 1300m 10m -99dBm (894m) -89dBm (300m) milestone m 1800m 10m -99dBm (894m) -89dBm (300m) Figura 16: Estado do nó 03 no milestone 01 (sem nenhum peer link). 03. A Figura 21, que aparece no final dessa seção, mostra o movimento realizado pelo nó Analisando a partir do milestone 01, temos que neste primeiro, o nó 03 não tinha comunicação com nenhum dos outros 2 nós. A perda em espaço livre para ambos os

70 69 nós a partir do nó 03 era de 97dBm e 100dBm para os nós 01 e 02 respectivamente. Como já mencionado antes, para haver comunicação a atenuação máxima gerada pela perda em espaço livre deve ser de 95dBm, dada as características definidas de potência de transmissão e sensitividade de recepção definidas na carga do módulo. O estado do nó 03 enquanto ainda não está estabelecido nenhum peer link pode ser visto no screen do host da figura 16. Já no segundo momento do milestone 02, o nó 03 entrou na área de cobertura do nó 01, com uma perda em espaço livre de 86dBm, bem menor que os 95dBm necessários para que exista comunicação. Ainda no milestone 02, não existe comunicação entre o nó 03 e o 02, pois a atenuação é de 98dBm. Os peer links criados podem ser vistos na figura 17. O milestone 03 é somente uma continuação do segundo, tendo em vista que não há mudanças dos links estabelecidos, somente uma atenuação maior dada a distância também maior. Por isso, não será mostrada nenhuma figura para esse caso. Figura 17: Estado do nó 03 no milestone 02 (peer link com o nó 01). No quarto milestone, o nó 03 entra em uma pequena zona de interseção entre a área de cobertura do nó 01 e do nó 02. Nesse momento, ele consegue estabelecer um peer link tanto com o nó 01 como com o nó 02, como mostra a figura 18. Nessa zona de interseção, a atenuação é de 93dBm e de 94dBm (muito próxima do limite de 95dBm) para os nós 01 e 02 partindo do nó 03 respectivamente. No próximo milestone, o nó 03 saiu da área de cobertura do nó 01. Apesar disso, para o nó 03, o nó 01 ainda está com um peer link estabelecido, como pode ser visto na figura

71 70 Figura 18: Estado do nó 03 no milestone 04 (peer link com o nó 01 e nó 02). 19. Figura 19: Estado do nó 03 no milestone 05 (peer link com o nó 01 e nó 02). O peer link com o nó 01 está aguardando ser excluído. Figura 20: Estado do nó 03 no milestone 05 (peer link com o nó 02). O peer link com o nó 01 foi excluído após 1800 segundos. Isso se deve à implementação do mesh do módulo mac Nessa implementação, a função responsável por realizar possíveis limpezas de links não mais disponíveis é a ieee80211_mesh_housekeeping. Ela é chamada por um timer com tempo de expiração de 60 segundos (através do define IEEE80211_MESH_HOUSEKEEPING_INTERVAL (60 * HZ)). Contudo, essa função só limpa peer links com tempo de inatividade maior que 1800 segundos (30 minutos). Esse tempo está informado no módulo mac80211 através do define IEEE80211_MESH_PEER_INACTIVITY_LIMIT (1800 * HZ). Ou seja, o

72 71 peer link só será removido entre 1800 e 1860 segundos depois do nó não estar mais disponível. Essa operação pode ser vista na figura 20. Na esquerda da figura, temos o link ainda estabelecido com o peer 02:00:00:00:01:01, mas com o tempo já de pouco mais de 1800 segundos. Após alguns segundos, o peer link desaparece, e resta somente o com o nó 02:00:00:00:01:02, que está ao alcance do host. Figura 21: Caminho percorrido pelo nó 03 entre os 6 milestones. No sexto e último milestone, temos o nó saindo do alcance dos nós 01 e 02. Existe a mesma característica do milestone 5, onde é necessário esperar o tempo de 1800 segundos para que o peer link não esteja mais disponível. Contudo da mesma forma do caso anterior, a comunicação já não é mais possível a partir do momento que ocorre a mobilidade. Na figura 21 é possível observar todo o caminho percorrido pelo nó 03, bem como uma disposição aproximada de como os 3 nós estão no espaço. Também é possível observar através da linha tracejada o caminho percorrido pelo nó 03.