Ricardo Augusto Rabelo Oliveira Uma API para Integrac‚aoŸ

Ricardo Augusto Rabelo Oliveira

Uma API para Integracao e Gerenciamento de Redes Wi-Fi eBluetooth

Dissertacao apresentada ao curso de Pos-Graduacaoem Ciencia da Computacao da Universidade Federalde Minas Gerais, como requisito parcial para aobtencao do grau de Mestre em Ciencia daComputacao.

Instituto de Ciencias ExatasUniversidade Federal de Minas Gerais

Belo Horizonte28 de abril de 2004

”Da minha aldeia vejo quanto da terra se pode ver no Universo...Por isso a minha aldeia e tao grande como outra terra qualquerPorque eu sou do tamanho do que vejoE nao do tamanho da minha altura...”Fernando Pessoa

i

Resumo

A reducao do tempo de desenvolvimento e uma das caracterısticas mais importantes nacriacao de software. Uma das estrategias com essa finalidade e o uso de uma interface deprogramacao, API, Application Programming Interface, cujo objetivo e descrever como ocorrea interacao entre as diversas partes de um sistema. O objetivo deste trabalho e desenvolver umaAPI para monitoramento e analise de duas das principais tecnologias de redes sem fio usadas nacomputacao movel: as WLANs, com o IEEE 802.11, e as WPANs, com o Bluetooth. A APIproposta acessa as informacoes das interfaces de um dispositivo, assim como possibilita a suareconfiguracao de acordo com as necessidades da aplicacao. Nesta dissertacao sao apresentadosa especificacao, projeto, implementacao e foi desenvolvida uma aplicacao para a avaliacao destaAPI.

Abstract

An important trend in software development is to reduce its development time. An importantstrategy employed by programmers with this aim is the use of APIs, Application ProgrammingInterface, which are sets of protocols, routines and tools for building software applications. Inthis work we present an API for monitoring and analyzing two of the most important wirelessnetwork technologies: 802.11 for WLANs Wireless Local Area Networks, and Bluetooth forWPANs Wireless Personal Area Networks. The proposed API can access information in bothcommunication interfaces and can configure them in order to attend specific application needs.

ii

A Deus, a minha famılia e a todos que me acompanharam nessa jornada. . .

iii

Agradecimentos

Tento registrar aqui, em poucas linhas, os meus agradecimentos, mesmo sabendo que naosao suficientes para expressar a importancia de todos nessa minha jornada. Agradeco a todos quecontribuıram direta, ou indiretamente, para a concretizacao deste trabalho:

• A Deus, pelos desafios do dia-a-dia e, principalmente, pela forca para enfrenta-los;• Aos meus pais, Saul e Gorette, pelo apoio incondicional, pelo carinho e compreensao e

por tudo;• Aos meus irmaos, Marcelo e Marina, pela amizade e o incentivo em todas as horas;• Aos meus amigos da lista Hellmans: Dlaivison, Erico, Eliziane, Marcelo, Leonardo, Mi-

riam, Naiara, Andre, Juliana e Jose Roberto, pelos incentivos, pela atencao e carinho dis-pensados desde o ınicio dessa jornada. E tambem pela companhia e pelas viagens namaionese;

• Aos meus amigos, em especial, Fernando Augusto, Leo Claudino, Cristiane Oliveira Cotta,Ana Elisa Ribeiro pelos incentivos em todos os momentos, pelas conversas e apoios, e,principalmente, pela amizade;

• A minha namorada, Kariny, pelo apoio e compreensao em diversos momentos mais difıceis,e por tornar os bons momentos ainda mais felizes;

• A todos os amigos e colegas da UFMG - a turma 972, em especial: Patricia Correa, JulianoPalmieri, Rainer, pelas conversas e pelo incentivo;

• Aos meus amigos e colegas do SIAM;• Aos professores da UFMG pela oportunidade de conviver e aprender um pouco mais, den-

tro e fora das salas de aula;• Ao meu orientador, o Professor Antonio Alfredo Ferreira Loureiro, por sua orientacao e

ter confiado no meu potencial;• A SISMED, pelo apoio durante o inicio do mestrado;• Ao CNPq, agencia financiadora deste trabalho;

A voces, meu Muito obrigado.

Sumario

1 Introducao 1

1.1 APIs para Computacao Movel . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Tecnologias de redes sem fio: WPANs e WLANs . . . . . . . . . . . . . . . . . 3

1.3 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.5 Organizacao do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Interfaces de redes sem fio 10

2.1 Camada Fısica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.1 Direct Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.2 Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.3 Modulacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.4 Propagacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Camada de Enlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.1 Caracterizacao dos Protocolos da Camada de Acesso ao Meio . . . . . . 14

2.2.2 Descricao dos protocolos de acesso ao meio . . . . . . . . . . . . . . . . 15

iv

SUMARIO v

2.2.3 Comparacao de desempenho entre diferentes protocolos MAC . . . . . . 16

2.3 Informacoes da camada de enlace . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.1 Contexto de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3.2 Mobilidade e Conectividade . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Wi-Fi 21

3.1 Descricao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Camada Fısica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3 Camada de Enlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3.1 Procedimento de Acesso ao Meio . . . . . . . . . . . . . . . . . . . . . 24

3.3.2 Retransmissao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3.3 No Escondido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3.4 Virtual Carrier Sense . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3.5 Tipos de quadro e fragmentacao . . . . . . . . . . . . . . . . . . . . . . 27

3.4 Gerenciamento da camada de enlace . . . . . . . . . . . . . . . . . . . . . . . . 27

3.4.1 Funcoes de Gerenciamento . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.4.2 Sincronizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4.3 Gerencia da conexao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.4.4 Gerenciamento de Energia . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.5 Parametros para Ajuste de Desempenho . . . . . . . . . . . . . . . . . . . . . . 33

3.6 Padroes IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.7 Interfaces 802.11 no Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

SUMARIO vi

3.7.1 Orinoco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4 Bluetooth 41

4.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2 IEEE 802.15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3 Pilha de Protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.3.1 Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.3.2 Baseband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.3.3 Link Manager Protocol - LMP . . . . . . . . . . . . . . . . . . . . . . . 55

4.3.4 Host Controller Interface - HCI . . . . . . . . . . . . . . . . . . . . . . 56

4.3.5 Logical Link Control and Adaptation Protocol - L2CAP . . . . . . . . . 57

4.3.6 Service Discovery Protocol - SDP . . . . . . . . . . . . . . . . . . . . . 58

4.4 Perfis de Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.5 Bluetooth no Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.6 Kits Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.6.1 Interface de programacao para o Bluetooth . . . . . . . . . . . . . . . . 62

5 Implementacao 65

5.1 Arquitetura da API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.2 Gerenciamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.3 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.3.1 Estruturas de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.3.2 Funcoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

SUMARIO vii

6 Testes e Resultados 79

6.1 Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.2 Analise da Interferencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.3 Analise da mobilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7 Conclusoes e Trabalhos Futuros 93

7.1 Conclusoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

7.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Lista de Figuras

1.1 Conjuntos de dispositivos formando WPANs . . . . . . . . . . . . . . . . . . . . 4

1.2 Posicionamento das tecnologias sem fio, WPAN e WLAN . . . . . . . . . . . . 5

2.1 Diagrama Funcional da interface sem fio . . . . . . . . . . . . . . . . . . . . . . 10

3.1 Modos de funcionamento do IEEE 802.11. Infra-estruturado e ad hoc . . . . . . 22

3.2 Organizacao da pilha do IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . 22

3.3 CSMA/CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4 No Escondido: Mecanismo de RTS/CTS . . . . . . . . . . . . . . . . . . . . . . 26

3.5 Virtual Carrier Sense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.6 Etapa de escolha e associacao com pontos de acesso . . . . . . . . . . . . . . . . 31

3.7 Dados relativos ao cartao PCMCIA da interface Wi-Fi . . . . . . . . . . . . . . 37

4.1 Pilha de Protocolos do Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2 As maneiras de comunicacao no Bluetooth. [1] . . . . . . . . . . . . . . . . . . 42

4.3 Pacote de um slot de 625 µS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.4 Exemplo de pacotes multi-slots. [1] . . . . . . . . . . . . . . . . . . . . . . . . 46

4.5 Estrutura do pacote. [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

viii

LISTA DE FIGURAS ix

4.6 Maquina de Estados da Baseband . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.7 Esquema do funcionamento do HCI . . . . . . . . . . . . . . . . . . . . . . . . 57

4.8 Perfis de Funcionamento do Bluetooth. [1] . . . . . . . . . . . . . . . . . . . . . 59

4.9 Blocos de acesso do Affix. [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.10 Golden Range do receptor Bluetooth. [1] . . . . . . . . . . . . . . . . . . . . . . 64

5.1 Arquitetura Funcional da API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.1 Informacoes da Interface Bluetooth. . . . . . . . . . . . . . . . . . . . . . . . . 81

6.2 Informacoes da Interface Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.3 Qualidade dos canais Bluetooth (pacote DH1 e trafego CBR) e 802.11 (taxa detransmissao de 1MB e trafego FTP). . . . . . . . . . . . . . . . . . . . . . . . . 83

6.4 Distribuicao acumulada da qualidade dos canais Bluetooth e 802.11 (taxa detransmissao de 1MB). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6.5 Forca do sinal nos canais Bluetooth e 802.11 (taxa de transmissao de 1MB). . . . 85

6.6 Qualidade do link 802.11 (interferencia Bluetooth com pacote DH5). . . . . . . . 85

6.7 Largura de banda do link 802.11 para FTP sem interferencia e com interferenciado Bluetooth com pacote DH5. . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6.8 Qualidade dos canais durante uma queda de conexao do canal 802.11 (inter-ferencia do Bluetooth com pacote DH1) . . . . . . . . . . . . . . . . . . . . . . 86

6.9 Forca do sinai dos canais durante uma queda de conexao do canal 802.11 (inter-ferencia do Bluetooth com pacote DH1) . . . . . . . . . . . . . . . . . . . . . . 87

6.10 Qualidade dos links Bluetooth e 802.11 afastando-se do ponto de comunicacao. . 88

6.11 Forca do sinal dos canais Bluetooth e 802.11 afastando-se do ponto de comunicacao. 88

6.12 Qualidade dos links Bluetooth e 802.11 aproximando-se do ponto de comunicacao. 89

LISTA DE FIGURAS x

6.13 Forca sinal Bluetooth e 802.11 aproximando-se do ponto de comunicacao. . . . . 89

6.14 Qualidade dos canais Bluetooth e 802.11 movimentando-se a esquerda do pontode comunicacao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.15 Forca sinal Bluetooth e 802.11 movimentando-se a esquerda do ponto de comunicacao. 90

6.16 Qualidade dos canais Bluetooth e 802.11 movimentando-se a direita do ponto decomunicacao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.17 Forca sinal Bluetooth e 802.11 movimentando-se a direita do ponto de comunicacao. 91

6.18 Qualidade do link Bluetooth afastando-se do ponto de comunicacao para os 6tipos de pacotes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Lista de Tabelas

3.1 Consumo de energia de uma interface IEEE 802.11b . . . . . . . . . . . . . . . 32

3.2 Operacoes basicas efetuadas no driver atraves do ioctl . . . . . . . . . . . . . 39

3.3 Operacoes de desempenho efetuadas no driver atraves do ioctl . . . . . . . . 39

3.4 Operacoes de vinculacao ao Ponto de Acesso no driver atraves do ioctl . . . . 39

3.5 Operacoes de seguranca e do chipset efetuadas no driver atraves do ioctl . . . 40

3.6 Operacoes de estatıstica do driver atraves do ioctl . . . . . . . . . . . . . . . 40

4.1 Classe de dispositivos suportados pelo Bluetooth . . . . . . . . . . . . . . . . . 43

4.2 Classe de dispositivos Bluetooth. [1] . . . . . . . . . . . . . . . . . . . . . . . . 45

4.3 Tipos de pacotes do Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.4 Velocidade e capacidade dos pacotes do Bluetooth . . . . . . . . . . . . . . . . 49

4.5 Tempos usados no estabelecimento de conexao . . . . . . . . . . . . . . . . . . 52

4.6 Consumo de energia do Bluetooth, medidas do chipset da Ericsson, R0K 101007. [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.7 Alguns comandos do HCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.1 Nomenclatura utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

xi

Capıtulo 1

Introducao

1.1 APIs para Computacao Movel

A reducao do tempo de desenvolvimento e uma das caracterısticas mais importantes nacriacao de software. Uma das estrategias com essa finalidade e o uso de uma interface deprogramacao, API, Application Programming Interface, que consiste de um conjunto de rotinas,protocolos e ferramentas que disponibiliza todos os elementos basicos necessarios a programacaode um sistema. Durante o desenvolvimento de um software, muitas de suas partes necessitamusar os recursos dos dispositivos a seu dispor, de forma que os programadores precisam sabercomo acessa-los, um fator que tem um alto custo, se for proporcional a complexidade de aprendi-zado. Dessa maneira, uma API diminui o tempo de aprendizado, atraves da definicao do acessoe uso dos recursos e funcionalidades de um sistema, simplificando sua programacao e aumen-tando a produtividade no seu perıodo de implementacao. Como exemplos mais comuns de APIs,estao as de comunicacao atraves de interfaces de rede como Sockets, que abstraem o conceitode comunicacao da rede, atraves de descritores de arquivos, e RPC, Remote Procedure Call,que possibilita chamadas a procedimentos remotos, sem a necessidade de acessar diretamente ainterface de rede.

Existem alguns tipos de aplicacoes nas quais diversos recursos sao escassos, uma situacaomuito comum no ambiente de computacao movel. Este e conhecido por ter dispositivos depequena capacidade computacional que utilizam interfaces sem fio para a comunicacao. Acomputacao movel tem seus conceitos relacionados com a mobilidade de software, hardwaree dados num ambiente computacional.

Essa mobilidade introduz restricoes que eram inexistentes no ambiente de computacao tradi-cional. Algumas destas sao geradas durante a comunicacao entre as unidades, como a variacaoda velocidade do canal, interferencias do ambiente, questoes relativas a localizacao da estacao

1

CAPITULO 1. INTRODUCAO 2

movel e a duracao da bateria. A desconexao do dispositivo movel, comum neste cenario, podeocorrer de forma voluntaria ou ser devida a variacoes na qualidade do canal e energia disponıvelna bateria, entre outras. As caracterısticas do computador movel, como peso e tamanho, limitama disponibilidade de recursos como memoria e capacidade de processamento.

Dentre as aplicacoes criadas para esse ambiente, algumas necessitam de uma maior adapta-bilidade aos dispositivos que as executam. Essa adaptabilidade pode estar direcionada tanto aoconteudo no qual a aplicacao trabalha, como vıdeo, voz e dados, quanto ao acesso a diversostipos de informacoes, como a capacidade dos dispositivos, localizacao e posicionamento, da-dos de extrema relevancia para a computacao movel. Uma API para a computacao movel devecontemplar esses requisitos de adaptabilidade, oferecendo as opcoes para tal.

Nesse ambiente, e possıvel identificar dois grupos de aplicacoes: no primeiro grupo, asinformacoes sobre o canal de comunicacao sem fio e as capacidades dos dispositivos sao vistasde maneira transparente, independentes da aplicacao. Neste caso, uma infra-estrutura e utilizadacomo uma interface para o sistema, servindo como suporte a aplicacao no computador movel.Este tipo de infra-estrutura tambem e conhecido como middleware, que esconde os detalhes dascamadas inferiores ao proprio middleware e do sistema operacional. Os desenvolvedores des-sas aplicacoes podem escrever codigos para aplicacoes centralizadas, sem se preocupar com asdistribuicoes na rede, escalonamento, etc, de maneira que as aplicacoes desenvolvidas sobre omiddleware sao facilmente portaveis. Um exemplo desta classe de interface sao as plataformasde desenvolvimento .NET [4], da Microsoft [5], e o J2ME [6], da SUN [7], onde uma camada desoftware cria um ambiente isolado para os dispositivos e suas aplicacoes. O desenvolvimento deaplicacoes e a distribuicao e feita de maneira transparente, e muitas vezes o desenvolvedor naoprecisa se preocupar com os detalhes dos computadores que serao utilizados.

No segundo grupo estao as aplicacoes que necessitam de informacoes para seu funciona-mento. Neste grupo, a aplicacao e integrada ao hardware, com uma utilizacao menos gene-ralizada dos recursos disponıveis. Esta integracao possibilita um controle mais robusto pelaaplicacao, diminuindo a abstracao gerada pela quantidade de camadas de software entre aaplicacao e o hardware envolvido. O acesso a essas informacoes permite que a aplicacao sejadesenvolvida de maneira a otimizar o uso dos recursos envolvidos. Por exemplo, aplicacoes quecriam um fluxo multimıdia, como vıdeo/voz, podem ter medidas de qualidade de servico e ummelhor provimento dos dados, atraves da escolha de protocolos e metodos de transmissao maiseficientes, por conhecer a largura de banda disponıvel. Aplicacoes de agendas e navegacao aInternet podem adaptar o conteudo a ser mostrado e armazenado localmente, de acordo com asinformacoes de capacidades de vıdeo e memoria.

Outro exemplo deste tipo de aplicacao sao os sistemas de gerencia e sensoreamento remotos.Os sistemas de gerencia sao responsaveis pela informacao e possibilidade de manutencao da redede comunicacao, coletando o status das estacoes, e reportando diversas caraterısticas e alteracoesno seu funcionamento. Nas redes sem fio, onde os dispositivos de baixa capacidade podem ser amaioria na comunicacao envolvida, os parametros de suas interfaces de comunicacao e das capa-


cidades locais sao vitais. Atraves destas interfaces, tambem e possıvel coletar os nıveis de quali-dade da comunicacao entre os elementos, um tipo de informacao que possibilita que softwares degerencia possam ter informacoes sobre a presenca dos elementos nas redes, identificando padroesde mobilidade, conectividade dos elementos e ate mesmo casos de interferencias ou destruicaode componentes. Uma caracterıstica importante das aplicacoes de gerencia e que estas podematuar de maneira ativa sobre as interfaces das estacoes da rede sem fio, alterando alguns dos seusparametros de funcionamento, como valores de transmissao e parametros dos temporizadoresinternos. Ja as aplicacoes de sensoreamento remotos, muito conhecidas por trabalharem comambientes de computacionais com severas restricoes de energia, necessitam dessas informacoespara que o funcionamento do dispositivo seja prolongado.

1.2 Tecnologias de redes sem fio: WPANs e WLANs

O enfoque deste trabalho cobre duas das principais tecnologias de redes sem fio usadas nacomputacao movel: a Wireless Personal Area Network, WPAN [8], rede de acesso pessoal semfio, e a Wireless Local Area Network, WLAN [9], a rede de acesso local sem fio. Os dois tipos deredes foram desenvolvidos com objetivos especıficos e atendem a diferentes tipos de dispositivos.

As WPANs sao redes sem fio com elementos comunicantes proximos do usuario, sendo mui-tos deles de uso pessoal. Neste tipo de rede e possıvel uma integracao dos dispositivos queestejam ao alcance pessoal, de forma que possam atuar diretamente uns com os outros. Asprincipais caracterısticas deste tipo de dispositivo sao possuir baixa capacidade computacional,pouca capacidade de energia e serem de uma implementacao mais simples. Essas caracterısticastornam proibitivo o uso dos outros padroes de comunicacao sem fio que visam atender redes semfio mais dispendiosas, como as WLANs. Um dos cenarios mais comuns previstos nas WPANssao as redes estabelecidas entre os dispositivos de um usuario, como celulares, PDAs, relogiose fones de ouvido, permitindo um acesso condizente com as caracterısticas destes, tanto de seusdados como os diferentes tipos de servicos oferecidos. Um PDA pode utilizar o servico de te-lefone do celular para acessar a Internet atraves do acesso discado, enquanto utiliza o fone deouvido para tocar os sons de musicas armazenadas e ainda sincroniza com um notebook, repas-sando todas as informacoes utilizadas, numa configuracao semelhante a mostrada na figura 1.1.Cada um dos dispositivos fornece um servico que e compatıvel com suas caracterısticas, comopor exemplo o fone de ouvido, que atende a servicos de audio, e pode atender ao celular e aqualquer outro que gere um trafego de audio. As WPANs sao caracterizadas por terem menorescapacidades de transmissao, menor mobilidade entre os dispositivos e menores distancias.


Figura 1.1: Conjuntos de dispositivos formando WPANs

As WLANs sao conhecidas como a extensao das redes de acesso local sem fio. A maiormotivacao para a sua criacao foi permitir a mobilidade de usuarios das redes conhecidas comoLANs, onde os usuarios da rede podem se mover com certas restricoes e acessar as redes fixase as infra-estruturas existentes e sem necessidade de modificacoes nas instalacoes. Outro fatorfoi a possibilidade de diversos dispositivos poderem ter um acesso tambem irrestrito, sem anecessidade de cabos ou uma infra-estrutura de suporte, criando redes ad hoc.

Em comparacao com outros metodos de comunicacao sem fio, como a rede celular, e por te-rem seu funcionamento inspirado nas LANS, as WLANs possuem aspectos unicos. Por exemplo,diferente da comunicacao de uma rede celular, em que as frequencias e os canais de comunicacaosao alocados de acordo com a necessidade dos usuarios e disponibilidade de recursos na rede,nas WLANs a comunicacao de dados e feita atraves de troca de quadros, em um meio decomunicacao sem compartilhamento previo, tambem conhecido como contencao do canal. Nestaregra de comunicacao, as estacoes necessitam alocar todo o canal de comunicacao para si, an-tes e durante o envio dos dados. Apesar da nao existencia de canais previamente alocados, osdispositivos na rede WLAN tendem a ter mais flexibilidade de uso, maior as velocidades decomunicacao, alem de ser um tipo de rede de infra-estrutura e manutencao mais baratos. Comrelacao as WPANs, elas privilegiam o acesso rapido a rede, em detrimento do consumo de recur-sos. A figura 1.2 mostra seu posicionamento com outras tecnologias, no que se refere as suascapacidades de comunicacao, taxas de transmissao e mobilidade entre os dispositivos.


Figura 1.2: Posicionamento das tecnologias sem fio, WPAN e WLAN

1.3 Motivacao

As diferentes tecnologias para a comunicacao sem fio se distinguem por suas capacidades detransmissao, qualidade de recepcao e a maneira como utilizam os recursos disponıveis. As in-terfaces sem fio possuem diversas aplicacoes e objetivos, indo desde comunicacoes celulares delongo alcance ate a comunicacao entre sensores. Das diversas tecnologias sem fio mais difundi-das, este trabalho enfoca duas que mais se destacam, por serem financiadas por varias empresasde grande porte e terem finalidades distintas: Wi-Fi [9], e Bluetooth [10]. O Wi-Fi, do padraoIEEE 802.11, e voltado para as Wireless LANs, com alcance de ate 300 metros e largura de bandade 2 a 54 Mbps. Seu funcionamento e muito semelhante ao das redes Ethernet tradicionais,sendo muito utilizado para comunicacao de medio alcance, como por exemplo em escritorios epredios. O Bluetooth foi criado inicialmente para substituir cabos de perifericos e, em seguida,foi englobado pelas definicoes da WPAN. Com taxas de transmissao de ate 1 Mbps e alcance de10 metros, o Bluetooth foi planejado para trabalhar com dispositivos de capacidades variadas,desde fone de ouvido ate computadores pessoais, adaptando o seu metodo de funcionamento deacordo com os diferentes tipos de dispositivos envolvidos.

A adaptabilidade das aplicacoes para estes dois padroes de comunicacao sao fontes de di-versos estudos. Em [11], e analisado o desempenho de transmissao de vıdeo em redes Wi-Fie, sao definidas as diretrizes para o desenvolvimento de algoritmos adaptativos dessa classe deaplicacao, que sao baseadas na variacao de diversos parametros da interface de comunicacao. O


estudo descrito em [12] analisa a degradacao da taxa de transmissao nas redes Wi-Fi de acordocom a mobilidade das estacoes, tambem variando os parametros de funcionamento das interfacesde radio-comunicacao. Para que as aplicacoes possam dispor do uso destes recursos, e necessariauma API de acesso a estes parametros. A propria informacao das possibilidades de trabalho comesses parametros e vital para a aplicacao, uma vez que muitos destes nao estao presentes emtodas as interfaces.

Por contemplarem cenarios complementares, os protocolos Wi-Fi e Bluetooth tambem po-dem trabalhar em conjunto, atendendo as disponibilidades da aplicacao e maximizando acomunicacao. Em [13] e proposta uma arquitetura de interoperabilidade entre as duas interfaces,para uso em redes domesticas. Cenarios mesclados sao normalmente utilizados para acompa-nhar a disponibilidade de uma ou outra infra-estrutura de comunicacao ou para o tipo de servicoe dados que a aplicacao utiliza. Estudos destes tipos de cenario envolvem o handoff vertical,no qual as pilhas de protocolos sao trocadas de acordo com as necessidades da aplicacao. Porexemplo, em [14] e mostrado um sistema em que as interfaces Bluetooth e Wi-Fi sao utilizadasem momentos diferentes e atendem de maneira transparente as aplicacoes envolvidas.

Um estudo de utilizacao em conjunto de diferentes padroes e feito em [15], no qual o uso deuma interface de infra-vermelho com Wi-Fi economiza o consumo de energia das estacoes. Umestudo semelhante e feito, usando as duas tecnologias, no qual as etapas de comunicacao e osdados que sao utilizados sao diferenciados para cada aplicacao [16].

Em aplicacoes em que os recursos de energia sao muito limitados, como no caso das redesde sensores sem fio, a transmissao de dados deve ser bem avaliada. Apesar de muitas aplicacoesde redes de sensores necessitarem de interfaces de rede sem fio especializadas e desenvolvidasespecialmente para elas, algumas outras podem utilizar estes padroes de comunicacao. Nesteponto, apesar de nao atenderem a todos os requisitos das aplicacoes de sensoreamento, o Wi-Fi eo Bluetooth tem sido avaliados como interfaces de comunicacao para redes de sensores. O projetoSmart-Its [3] propoe o uso do Bluetooth em algumas aplicacoes de sensoreamento remoto [17],avaliando o tempo de conexao, consumo de energia e viabilidades de desenvolvimento. Variacoesdo modo de funcionamento do IEEE 802.11 sao propostas na criacao de novos protocolos para acamada de enlace, como por exemplo o SMAC-Sensor Medium Access Protocol [18].

Este trabalho tem como objetivo especificar, projetar, implementar e avaliar uma API parautilizar os recursos das duas tecnologias de maneira integrada, permitindo que as aplicacoesdisponham de acesso transparente ao controle das duas interfaces sem fio. A API proposta acessaas informacoes de seus dispositivos e de outros que estejam comunicando, assim como possibilitaa reconfiguracao do dispositivo de acordo com as necessidades da aplicacao. O contexto em queas aplicacoes trabalham deve ser considerado, pois influencia fortemente o funcionamento darede e dos nos.

Um exemplo de utilizacao dessa API e no roteamento de redes ad hoc e na formacao detopologias de redes sem fio. Estes dois problemas sao importantes em redes, nos quais os nos


comunicam entre si sem o uso de uma infra-estrutura de apoio, como estacoes base, ou coordena-dores de celulas de comunicacao. Varios algoritmos de roteamento ad hoc [19, 20, 21, 22] foramdesenvolvidos com o objetivo de coordenar a formacao destas redes, atendendo a demandas deaplicacoes e funcionando de maneira transparente. O desenvolvimento desse tipo de algoritmodeve levar em consideracao o tipo de interface que utiliza. Normalmente o desenvolvimento deum algoritmo de roteamento nao leva em consideracao certas funcionalidades e recursos presen-tes nas interfaces sem fio, desenvolvidas exatamente para lidar com as dificuldades desse meio.No caso do Bluetooth, os algoritmos de roteamento ad hoc sao especıficos para a formacao deum tipo de rede denominado scatternet, enquanto que no Wi-Fi apesar da formacao ser maislivre, algumas caracterısticas da rede possibilitam alteracoes no funcionamento dos algoritmoscitados. A formacao das scatternets e algoritmos que facam isso de forma eficiente e uma areade pesquisa muito abordada em diversos estudos [23, 24, 25, 26, 27, 28].

Devido a constante perda e renovacao de conexoes, os algoritmos ad hoc precisam ter a nocaode como os nos estao atuando na rede e tambem informacoes de suas proprias capacidades.O interfaceamento com a camada MAC e vital para o melhor funcionamento dos algoritmos.Atraves da API desenvolvida neste trabalho, as aplicacoes podem acessar as informacoes sobreo uso do dispositivo local e consumo de recursos e gerenciar a qualidade da transmissao e asconexoes. Esta API tem como objetivo possibilitar a integracao das duas tecnologias, definindoum gerenciamento comum entre elas.

Este trabalho descreve os principais pontos para a criacao dessa API. Para o estudo do funci-onamento das interfaces e o desenvolvimento da API, foi utilizado o sistema operacional Linux,com o kernel na versao 2.4.18. A escolha do Linux se deve a facilidade de acesso ao codigo defuncionamento dos drivers das interfaces e a possibilidade de alteracoes e desenvolvimento. Ascaracterısticas de configuracao e portabilidade do Linux tambem permitem que a API seja utili-zada em dispositivos como notebooks, Palms e outros que suportem versoes do Linux Embutido.

Informacoes sobre a rede sao mantidas em uma base de dados usando XML [29], que pos-sui uma descricao dos tipos de tecnologias usadas na camada de acesso ao meio e as principaisdistincoes entre elas. Nesta base tambem sao apontados os detalhes importantes sobre o compor-tamento dos dispositivos e da rede e como eles contribuem para as aplicacoes envolvidas.

1.4 Trabalhos Relacionados

O estudo e criacao de APIs voltadas para a comunicacao sem fio tem crescido recentementedevido a propostas de protocolos de rotamento para redes ad hoc e aplicacoes em sistemas em-butidos e de gerencia.

Em [30], e descrito um ambiente de teste de algorimos de roteamento ad hoc, chamado APE


- Ad Hoc Protocol Evaluation testbed, utilizando o sistema operacional Linux. Uma API para ainterface Wi-Fi e fornecida como ferramenta de coleta de informacoes de conectividade na redead hoc formada. Com estas informacoes, mais as estatısticas de perdas de pacotes e atrasos detransmissao, os protocolos ad hoc podem ter informacoes mais reais com relacao as conexoesenvolvidas.

Em [31], e proposta uma API de comunicacao, que estende algumas funcionalidades doAPE, sendo possıvel a implementacao de suas funcionalidades nos sistemas operacionais Win-dows e Windows CE. A proposta deste trabalho e a mais generica possıvel, possibilitando umaprogramacao multiplataforma, sem extrair muitas informacoes das interfaces de comunicacaosem fio.

Em [32], foi desenvolvida uma API integrada para o Bluetooth, definida BlipNet, no qualum elemento definido como BlipServer, esta conectado a rede Ethernet e a diversos elementosBlipNodes. Estes elementos possuem interfaces Bluetooth e coletam as informacoes sobre oselementos que desejam conectar a eles. O BlipServer coleta informacoes sobre estes dispositivose fornece uma API de programacao, usando J2ME, para que as aplicacoes controlem as conexoesvindas pelos BlipNodes. Dessa maneira as aplicacoes podem coordenar o acesso destes elemen-tos a rede fixa, fornecendo os servicos da Internet para esses dispositivos, de acordo com suascaracterısticas. Esta implementacao foi feita tanto para Linux quanto para Windows.

1.5 Organizacao do Documento

O restante da dissertacao esta organizado conforme a descricao a seguir.

No Capıtulo 2 sao apresentados os princıpios basicos e a estrutura de funcionamento deuma interface para redes sem fio, sendo o ponto de partida para o projeto da API. E mostradauma descricao geral para interfaces deste tipo, onde sao levantados os requisitos basicos e ascaracterısticas de funcionamento. Sao enumerados os tipos de camada fısica e os detalhes dacamada de enlance, mostrando as diferencas e as possıveis utilizacoes desse tipo de interface.Tambem sao mostradas as informacoes relevantes para as aplicacoes que utilizam essa interfacecomunicacao.

Nos Capıtulos 3 e 4 sao apresentados, respectivamente, o Wi-Fi e o Bluetooth, seus princıpiosde funcionamento basicos e suas principais caracterısticas. Sao identificados os diversos padroesde comunicacoes envolvidos e as informacoes relevantes para a comunicacao das WLANs e dasWPANs. Tambem sao identificados os modos de funcionamento e as tecnicas de acesso as suasinformacoes no sistema Operacional Linux e os pontos basicos para a sua programacao.

No Capıtulo 5 e apresentada a arquitetura da API e as funcoes de acesso as interfaces. O


projeto e construıdo baseado na descricao do funcionamento basico das duas interfaces e a ma-neira de acesso aos seus dados. No Capıtulo 6 e apresentada uma aplicacao que efetua algunstestes sobre as funcionalidades fornecidas pela API. Por fim, no Capıtulo 7 sao apresentadas asconclusoes e as descricoes de possıveis trabalhos futuros.

Capıtulo 2

Interfaces de redes sem fio

Na descricao do modelo OSI da ISO [33], a interface para a comunicacao sem fio encontrase nas duas primeiras camadas, a camada fısica e a de enlace, divididas, respectivamente, nomodem de radio transmissao, responsavel por enviar e receber os dados, e o controlador deacesso ao meio, que coordena o trafego de dados. A figura 2.1 mostra como e a estrutura de umainterface de comunicacao sem fio e sua visao interna.

Figura 2.1: Diagrama Funcional da interface sem fio

As principais caracterısticas do modem de radio sao o controle da frequencia de transmissao,a taxa de sinalizacao, a modulacao e a potencia de transmissao. A parte digital, responsavel pelocontrole dessas funcionalidades, se encontra na Bandabase, que funciona como a interface coma camada de enlace, fornecendo essas informacoes para o controlador de acesso ao meio. Nomodem, encontra-se a parte analogica da comunicacao, onde e feita a modulacao dos dados paraa transmissao.

10

CAPITULO 2. INTERFACES DE REDES SEM FIO 11

A camada de controle de acesso ao meio, MAC, e responsavel por executar o protocolo deacesso ao meio. Ela coordena o espaco de memoria limitado para os buffers e os dados deconfiguracao e estatısticas, e responsavel pelo formato e definicao dos quadros, pelo controle deacesso ao meio e algumas caracterısticas de gerenciamento de rede. O host interface prove acomunicacao entre o software, normalmente o driver da placa, com o MAC.

2.1 Camada Fısica

A camada fısica das interfaces sem fio podem utilizar tanto a comunicacao atraves de radio-frequencia, como dispositivos oticos, como comunicacao em infra-vermelho. Este trabalho efocado na primeira classe. As interfaces de radio utilizam para a comunicacao a banda conhecidacomo ISM (Industrial, Scientific and Medical), sendo utilizadas as faixas de frequencia de 900MHz a 2.4GHz. Essa banda e liberada para esse tipo de trafego, sendo nao licenciadas para ouso. Mas as empresas que produzem produtos para elas estao sobre certas regras, que determinamlimites de potencias de transmissao e tecnicas de envio de dados. A tecnica definida para o usoe o Spread Spectrum, que possui uma maior confiabiliadade na transmissao. O Spread Spectrumutiliza mais largura de banda para transmitir do que e realmente necessario, reduzindo o impactodas interferencias localizadas. Na banda de 2.4GHz, a regulamentacao especifica que os sistemasdevem utilizar dois tipos de tecnicas de transmissao: Direct Sequence e Frequency Hopping.

2.1.1 Direct Sequence

O princıpio de funcionamento do Direct Sequence consiste em espalhar o sinal sobre umabanda de transmissao, multiplexando o sinal com uma assinatura de identificacao. Cada bit e mo-dulado por um codigo que cobre grande parte do canal de transmissao. Para uma taxa de 2Mb/s,normalmente utilizada na WLAN, o sinal e espalhado sobre 22MHz da banda. Dessa maneira,interferencias em determinados canais sao minimizadas, e a demodulacao consegue restaurar ossinais recebidos. O Direct Sequence permite uma modulacao rapida, mas a implementacao doseu radio modem e mais complicada. Em contrapartida, o uso de um canal fixo de transmissao fazcom que as camadas superiores nao precisem gerenciar a utilizacao desses canais, como acontececom o Frequency Hopping. Por usar canais muito largos, os sistemas desse tipo utilizam poucoscanais presentes na banda, (no caso do Wi-Fi apenas tres, em frequencias totalmente diferentes).Esses canais sao totalmente separados, de forma que nao geram interferencia uns com os outros.


2.1.2 Frequency Hopping

O Frequency Hopping (FH) utiliza um conjunto de canais de largura pequena e transmite acada momento em um deles, seguindo uma sequencia. No caso da banda ISM de 2.4GHz, ela edividida em 79 canais de 1 MHz. Periodicamente, num intervalo entre 20 a 400 ms, o sistemaefetua um salto para um canal diferente, a partir de um padrao pre-determinado, evitando assimas interferencias, pois permanece pouco tempo no mesmo canal.

A principal vantagem desse funcionamento, com relacao ao Direct Sequence e que uma inter-ferencia localizada em determinado canal de frequencia e prontamente evitado pela utilizacao deoutros canais livres. Assim, diversos sistemas de FH podem comunicar sem se sobrepor, mesmoestando a um curto alcance de transmissao. O Bluetooth permite que ate 79 elementos possamse comunicar diretamente, a uma curta distancia, e sem degradar a qualidade da comunicacao,enquanto que no DS, a taxa de transmissao degrada devido as colisoes. Quando a comunicacaochega ao limite, as colisoes comecam acontecer, porque diversos sistemas utilizam os mesmoscanais ao mesmo tempo interferindo uns com os outros. Estes casos diminuem consideravel-mente a vazao do sistema, pois a falha nao e recuperada. Se a recepcao do sinal tiver muito ruıdoem diferentes canais, o modem que utiliza o FH nao tem a capacidade de reconstrucao do sinalcomo no DS.

Existem diversos casos de interferencia entre os dois padroes. Alguns estudos analisam ainterferencia entre o Wi-Fi e o Bluetooth [34], em cenarios onde duas ou mais redes Bluetoothinterferem fortemente na comunicacao de elementos Wi-Fi. E outros em que uma certa quanti-dade de elementos Wi-Fi comunicam em presenca de uma piconet interferindo na comunicacao.Uma das solucoes encontradas, para evitar a interferencia entre os dois padroes [8], e o uso deum metodo FH adaptativo ao ruıdo, onde os canais mais ruidosos sao descartados das sequenciasde saltos.

Outra desvantagem, e o nıvel de complexidade que o uso do FH impoe a camada de enlace.O procedimento de localizacao de busca da rede no momento da inicializacao, a sincronizacaoentre os nos e a gerencia dos saltos de frequencia. Essa complexidade influencia diretamente nodesempenho, tanto devido ao overhead desse controle, quanto ao tempo perdido a cada salto defrequencia.

O modem que trabalha com o FH e relativamente mais simples que o que usa o DS, sendoseu custo de implementacao mais barato, compensando o custo de uma camada de enlace maisrobusta.


2.1.3 Modulacao

Para a modulacao da transmissao, existe uma troca entre a velocidade de modulacao e aqualidade do sinal recebido. Quanto mais rapido for o sistema de modulacao, mais forte deve sero sinal recebido. Para compensar essas flutuacoes, os sistemas normalmente trabalham com asduas abordagens mescladas, trocando para taxas menores caso o sinal recebido tenha um nıvelmais fraco.

2.1.4 Propagacao

A propagacao do sinal e influenciada por diversos fatores, desde absorcao do sinal porobstaculos ate interferencias por diversos tipos de ruıdo. Dessa maneira e dıficil prever, comprecisao, o comportamento das transmissoes em diferentes cenarios. Nao existe um padrao, oumetodo conhecido para medir o alcance da propagacao de maneira correta. As melhores metricaspara definir a qualidade da propagacao do sinal sao relativas a potencia de transmissao e a sensi-bilidade do sinal recebido.

A potencia de transmissao define a forca das emissoes dos sinais. Valores maiores implicamem sinais que sao mais fortes que a interferencia, apesar de consumirem significativamente maisbateria. E sinais de grande potencia podem interferir em outros canais de frequencia proximosinterferindo na sua comunicacao.

A sensibilidade e a medida do sinal mais fraco que pode ser corretamente recebido pelomodem. Ele indica o desempenho da parte de recepcao do modem, e quanto menor o valor,melhor a qualidade do receptor.

Com esses dois valores e possıvel calcular a atenuacao do sinal, medida a cada recepcaodos pacotes, sendo essa a diferenca do valor do sinal transmitido pelo recebido. Outro fatordiretamente relacionado com a recepcao e a razao Signal to Noise Ratio (SNR), que define adiferenca da potencia de um sinal e um ruıdo, no momento da recepcao. Dessa forma valorespequenos de SNR significam uma melhor sensibilidade a recepcao.

2.2 Camada de Enlace

Presentes na camada de enlace, encontram-se os protocolos de acesso ao meio. Eles saoimplementados pelo modulo de controle de acesso ao meio e controlam todo o funcionamentoda interface de rede. Os protocolos de acesso ao meio, para redes sem fio, foram desenvolvidosvisando cobrir os requisitos de diferentes tipos de aplicacoes e dispositivos. Desta forma, cada


protocolo possui caracterısticas proprias que levam em consideracao os diversos fatores das redessem fio de maneira diferenciada.

2.2.1 Caracterizacao dos Protocolos da Camada de Acesso ao Meio

Em [35], e feita uma caracterizacao qualitativa de diversos protocolos da camada de acessoao meio, explorando os pontos em comum entre eles. A primeira classificacao e com relacao asarquiteturas que podem ser formadas, e em seguida com relacao aos modos de operacao e acessoao meio sem fio. Tal metologia foi aplicada na comparacao das duas camadas.

Basicamente, existem dois tipos de arquiteturas para as redes sem fio: distribuıdas e cen-tralizadas. As redes sem fio distribuıdas, tambem conhecidas como redes ad hoc, nao possuemnenhum tipo de administracao central e, portanto, todos os terminais podem se comunicar dire-tamente entre si. Sendo assim, como nao existe nenhum no especial para traduzir transmissoesde uma frequencia para outra, qualquer transmissao ou recepcao de dados devem estar na mesmabanda de frequencia. Por este motivo, todas redes sem fio distribuıdas operam com Time DivisionDuplex, (TDD).

As redes sem fio centralizadas, tambem conhecidas como redes last-hop, sao geralmenteextensoes das redes cabeadas. Estas redes possuem um estacao base (EB) que atua como umainterface de comunicacao entre a rede cabeada e a rede sem fio. A existencia desta EB permiteuma grande flexibilidade no projeto de protocolos MAC, uma vez que o papel de controlar oacesso ao meio pode ser totalmente realizado pela EB.

Uma primeira caracterizacao destes protocolos e descrita a seguir:

• Acesso aleatorio: os nos fazem a contencao na hora de efetuar o acesso ao meio. Quandoapenas um no tenta efetuar a transmissao, ela ocorre com sucesso. Mas no momento emque mais de um tenta acessar o meio, ocorre uma colisao e os protocolos de acesso aleatoriotentam resolver este problema com um conjunto de regras de acesso ao meio ordenado;

• Acesso garantido: neste caso os nos acessam o meio de maneira ordenada, usualmente emround robin. Existem duas maneiras de efetuar essa transmissao: a primeira e atraves daconfiguracao mestre-escravo, no qual o mestre nomeia os nos que irao transmitir, e estesretornam os dados necessarios. A segunda e atraves de tokens, na qual somente a estacaopossuidora do token efetua a transmissao;

• Acesso hıbrido: e feita uma mistura das duas tecnicas. Um no efetua um processo derequisicao para transmissao de dados. Este processo e feito de maneira aleatoria. Em se-guida, o outro analisa as capacidades necessarias vindas na requisicao, retornando uma


confirmacao para iniciar a transmissao de dados. Neste momento, todos os recursos ne-cessarios a essa transmissao ja foram reservados pelo transmissor, sendo liberados deacordo com padroes pre-determinados de QoS ou mesmo de maneira aleatoria.

2.2.2 Descricao dos protocolos de acesso ao meio

O funcionamento de protocolos da camada de acesso ao meio em redes sem fio, seja atravesde transmissao via radio ou infravemelho, deve considerar diversos fatores que as diferenciamdas redes fixas. Abaixo segue uma breve descricao dessas diferencas:

• Operacao em Half-duplex: quando um no transmite os dados, uma fracao da energia do si-nal interfere com o sistema de recepcao, efeito denominado auto-interferencia. Isto ocorreporque os nıveis de energia para transmissao e recepcao podem diferir em diversas ordensde magnitude. A transmissao do sinal e tipicamente muito maior do que o sinal recebido,impossibilitando efetuar a recepcao do sinal no momento da transmissao. Dessa forma ficaimpossivel a aplicacao do Full Duplex, caso a frequencia de recepcao e transmissao seja amesma;

• Canal variante no tempo: os sinais de radio propagam de acordo com tres mecanismos:reflexao, difracao e dispersao. O sinal recebido pelo no e a superposicao de diferentes e ate-nuadas versoes do sinal transmitido, muitas vezes refletidas em diversos obstaculos. Comoresultado, a potencia do sinal recebido varia como funcao do tempo. Este fenomeno e cha-mado de propagacao multipath. Para verificar o canal normalmente e usada uma tecnica dehandshaking que verifica a qualidade do enlace. Quando dois nos querem comunicar entresi, eles trocam pequenas mensagens para testar o canal e, em caso de sucesso, o processonormal de comunicacao ocorre;

• Erros em rajada: Como consequencia da variacao do canal no tempo e da variacao daenergia do sinal, os erros surgem em rajadas devido ao distanciamento dos nos, uma vezque a qualidade do canal entre eles decai. A perda de pacotes devido a rajadas de errospode ser minimizada atraves do uso das seguintes tecnicas:

– Pacotes pequenos– Codigos FEC para correcao de erros– Metodos de retransmissao

sendo este ultimo metodo o mais usado, atraves de quadros de confirmacao usados paradetectar os erros;

• Deteccao do canal: A sensibilidade do canal de transmissao e uma funcao da posicaodo no em relacao ao transmissor. Esta caracterıstica acarreta as seguintes dificuldades nomomento da transmissao:


– Nos escondidos(hidden node): e um no que se encontra mais proximo do no dedestino, mas fora do alcance do no de origem. Dessa forma esse terceiro elementonao percebe a transmissao que esta ocorrendo e comeca a transmitir, interferindo noprocesso;

– Nos expostos: neste caso o no se encontra proximo do no transmissor, mas fora doalcance do destino. Assim o terceiro elemento detecta o inicio da transmissao, masnao efetua a sua transmissao, apesar de nao atrapalhar na recepcao do primeiro. Dessaforma a banda fica subutilizada;

– Captura: a captura ocorre quando um receptor recebe claramente a transmissao si-multanea de dois nos, e a captura do sinal ocorre no que possuir maior potencia. Osprotocolos da camada MAC devem ser ajustados para controlar essa percepcao dosinal.

Alem destes fatores, os protocolos MAC geralmente tratam tambem de outros aspectos, comoseguranca e gerenciamento de energia, de forma a garantir que os servicos ofertados pelos siste-mas sem fio sejam tao confiaveis e eficientes quantos os ofertados pelos sistemas cabeados.

2.2.3 Comparacao de desempenho entre diferentes protocolos MAC

Uma vez que os protocolos da camada MAC sem fio sao desenvolvidos com diferentes ob-jetivos e voltados para diferentes aplicacoes, uma comparacao dos pontos comuns e necessariapara descreve-los em um mesmo grupo. E suas diferentes implementacoes implicam em com-portamentos diferenciados para cada aplicacao. Abaixo e feita uma enumeracao dessas metricas:

• Atraso: o atraso e definido como o tempo medio dispendido por um quadro na fila dacamada MAC, a partir do momento que e enfileirado ate a sua transmissao completa. Suascaracterısticas sao devidas ao trafego e ao protocolo utilizado. Dessa forma a comparacaodo atraso deve ser feita sob as mesmas condicoes de trafego.

• Vazao: usado para medir a fracao do canal usada para transmissao de dados. O objetivodo protocolo da camada MAC e maximizar a taxa de transferencia enquanto minimiza oatraso do acesso, produzindo um valor de vazao aceitavel para as aplicacoes Se o tamanhomedio de uma mensagem e de P bits, o tempo de transmissao de cada pacote e T segundose C bps e a capacidade do canal, a vazao e dada por P/TC;

• Justica (Fairness): o protocolo MAC deve apresentar condicoes de preferencia de escolhade canal no momento que mais de um no decide transmitir no canal, caso contrario ocorre omau uso da banda passante. Quando o trafego multimıdia e suportado, ele deve apresentaruma polıtica diferenciada de acesso;


• Estabilidade: devido ao overhead no protocolo, o sistema deve ser habilitado para con-trolar cargas que sao muito menores que a capacidade de transmissao do canal;

• Robustez: o meio de comunicacao sem fio e muito propenso a erros, e o sinal de trans-missao e muito variante, de forma que um protocolo da camada MAC deve ter polıticas detratamento destes comportamentos instaveis;

• Consumo de energia: a maioria dos dispositivos sem fio possuem capacidade de arma-zenamento de energia limitada, os protocolos da camada MAC tem o suporte a diferentesmetodos de economia de energia, sendo que eles podem influenciar nas caracterısticas dotrafego gerado;

• Suporte para dados multimıdia: este tipo de suporte e caracterizado por mecanismosque tratam os pacotes de varias aplicacoes, a partir de restricoes associados ao atraso detransmissao. Duas polıticas comuns nestes casos sao a prioridades de acesso e o escalona-mento. As prioridades de acesso proveem um servico diferenciado permitindo que certosnos tenham acesso aos servicos de rede com maior probabilidade do que outros. O escalo-namento efetua o controle do acesso ao meio de maneira ordenada, alocando os recursospreferencialmente para os pacotes multimıdia.

2.3 Informacoes da camada de enlace

Como mostrado neste capıtulo, as funcoes de transmissao e recepcao do controle de acessoao meio comunicam diretamente com a interface de radio. Todo o controle feito pelo protocoloMAC ao meio sem fio fornece o ferramental para o gerencimento e configuracao desse tipo deinformacao, de forma que diminui a abstracao existente entre as camadas de software.

O primeiro ponto e com relacao as informacoes locais, como a identificacao do hardwaredo dispositivo, as frequencias de funcionamento, capacidades de armazenamento, entre outros.Neste caso, aplicacoes com utilidade de gerencia e seguranca podem dispor de todos os detalhesdos elementos envolvidos na conexao e verificar se a informacao e coerente. Informacoes deta-lhadas sobre o padrao de comunicacao utilizado e os detalhes do fabricante da placa sao relevatespara aplicacoes de sistemas embutidos e de alto desempenho. Em camadas de acesso ao meioonde a qualidade de servico e uma funcionalidade intrinseca, a aplicacao pode trabalhar controlaro funcionamento deste de maneira direta, e programar o tipo de acesso.

Atraves da informacao da qualidade do canal de comunicacao, a aplicacao pode estipularo comportamento da rede e dos seus elementos vizinhos. Variacoes bruscas na qualidade dosinal podem significar interferencias entre os elementos ou entao o distanciamento entre eles.Com essa medida, associada a cada elemento que o no estiver trocando mensagem, e possıvelque a aplicacao estipule um nıvel de stress em cada conexao, trabalhando e prevendo a sua


perda. Normalmente as camadas MAC ja fornecem o controle de erro de transmissao, masexistem situacoes, como de interferencia entre diferentes tecnologias, mobilidade em redes adhoc, desligamento de determinados elementos, que essa informacao e vital para a aplicacao.

2.3.1 Contexto de Rede

A informacao obtida atraves do contexto de rede e a descricao que as aplicacoes e algoritmospossuem sobre o ambiente de rede em que estao executando, relativas a comunicacao direta comseus vizinhos. No caso da comunicacao sem fio, sao os dados relativos as constantes mudancasque ocorrem durante a comunicacao, abrangendo os cenarios das redes infra-estruturadas e dasad hoc. Como descrito em [30], onde foi desenvolvido uma plataforma de testes de algoritmos deroteamento ad hoc, a avaliacao do funcionamento de aplicacoes e algoritmos nesse ambiente deveidentificar as metricas quantitativas e qualitativas, sendo que estas sao fortemente influenciadaspelo contexto de rede. Este pode ser descrito a partir de alguns parametros, definidos em [36]:

• Tamanho da rede. Medida em numero de elementos.

• Mobilidade. Esse fator pode ter influencia direta na mudanca da topologia e na conectivi-dade dos elementos da rede

• Conectividade da rede. Mede a densidade da rede, baseada na quantidade media de vizi-nhos por no.

• Capacidade do canal. A capacidade de transmissao do canal sem fio, medida embits/segundo.

As camadas de enlace sem fio fornecem o ferramental para se extrair os dados necessariospara estes parametros, a partir das medidas do nıvel de sinal ruıdo, os nıveis de potencia detransmissao e a recepcao dos pacotes. Estes possuem uma influencia diretamente na qualidadeda comunicacao. Atraves dessa informacao da qualidade, mais a quantidade de perdas e re-transmissoes de pacotes, permitem que a aplicacao determine se o canal e viavel, e possa tomarprovidencias, como uma fragmentacao dos pacotes, aumento da sensibilidade de recepcao, ou sefor possıvel, variacoes na potencia de transmissao.

2.3.2 Mobilidade e Conectividade

A mobilidade dos elementos na rede pode ser interpretada atraves de determinados padroesnas flutuacoes do sinal recebido em cada no. Mas essas alteracoes nos valores do sinal recebido


podem ser devido a interferencias, absorcao de sinais por obstaculos, e nao necessariamenteligada a mudanca de posicao com relacao ao transmissor. Assim e necessario uma metrica paradeterminar se os padroes de flutuacoes descrevem aproximadamente a mobilidade dos elementos.Cada tipo de rede, WLAN e WPAN, utiliza um tipo proprio de amostragem, sendo necessariosolucoes especificas para cada uma.

No caso das WLANs, alguns estudos de mobilidades no cenario ad hoc tem sido feitos, prin-cipalmente para a avaliacao de algoritmos de roteamento. Em [37], e desenvolvido um modelode mobilidade adhoc, onde um estudo probabilıstico define padrao de movimentacao dos ele-mentos numa rede Wi-Fi. Em [30], essa mobilidade e dada pelas flutuacoes dos valores de SNRe qualidade do sinal atraves de um determinado tempo. A razao entre a distancia e a atenuacaodo sinal e dada pela equacao 2.1:

Dj(nodej) = 4 ∗ 1040−0.9xQj(nodej)

33 (2.1)

onde Q e o valor da qualidade do sinal em dB, D e o valor da distancia em metros, e nodej oidentificador do no que esta transmitindo. A partir de diversas amostragens em determinadosintervalos de tempo, e possıvel determinar as variacoes e o comportamento do no, se esta ocor-rendo um distanciamento ou aproximacao deste. Com essa informacao e possıvel estipular oposicionamento relativo dos elementos na rede, atraves de determinadas referencias, mas esteposicionamento pode ser afetado pela presenca de obstaculos em determinados pontos.

No caso do Bluetooth, alguns trabalhos [38, 39, 40] estudam a possibilidade de criacao de sis-temas de posicionamento e descricao de mobilidades a partir das medidas da qualidade do sinal.Apesar de trabalhar com uma baixa resolucao da amostragem do sinal, de 8 bits, a delimitacaodas regioes e util para determinar as melhores fontes de comunicacao e estipular uma localizacaoaproximada.

A princıpio, a conectividade de um elemento na rede e dada pela quantidade de elementoscom que ele comunica diretamente. Considerando a topologia de uma rede fixa como um grafo,seria a quantidade de vertices que saem de um no. Numa rede sem fio, a comunicacao ocorresomente se os elementos estao no alcance de transmissao uns dos outros, e a camada de enlacepermite uma comunicacao entre eles. Dessa forma, a conectividade de um elemento na rede edada pelo numero de elementos que estao no seu alcance de transmissao.

Mas em alguns casos, a rede sem fio contempla a mobilidade, o que acaba interferindo nosvalores de conectividade, fazendo com que estes sejam dinamicos. Para uma primeira analise daconectividade, a mobilidade nao deve ser considerada. Dessa forma, a conectividade pode serconsiderada nesses tres casos: o melhor, onde valor da conectividade e maximo quando todos oselementos estao proximos o suficiente uns dos outros, ou seja comunicacao com os outros n1 nosda rede; o pior, onde apenas um elemento no alcance de comunicacao; e o caso medio, onde e


necessario estabelecer um padrao de mobilidade e distribuicao dos elementos para que esta sejadescrita como uma funcao de probabilidade. Em cenarios onde ocorre a mobilidade dos nos, aprobabilidade do no se encontrar dentro da area de alcance varia com o tempo.

A conectividade em uma rede propicia uma visao local das conexoes envolvidas, permitindouma visao qualitativa de suas conectividade com os elementos vizinhos. As medidas da quali-dade do sinal descrevem a conectividade do no com relacao aos seus vizinhos, sendo possıveldeterminar se este elemento esta se afastando da rede, ou perdendo a conexao devido a algumafonte de ruıdo proxima. Assim se um no tem as informacoes de mobilidade de seus vizinhos, epossıvel descrever o comportamento da conectividade de cada um.

Capıtulo 3

Wi-Fi

O grupo de trabalho do IEEE 802.11 [9] e responsavel pelo desenvolvimento de um padraode comunicacao de WLAN (Wireless Local Area Network), tambem conhecido como Wi-Fi.Opadrao IEEE 802.11 foi criado em 1989 e no final da decada de 90 comecou a se destacar nomercado. Diversas empresas se associaram na producao das placas de rede, criando a designacaoWi-Fi [41], dada aos produtos que implementam o IEEE 802.11b, sendo este uma extensao dopadrao original, com capacidade de transmissao de 11Mbps. O principal objetivo desse grupo ehomologar a conformidade da implementacao destas interfaces com a especificacao criada peloIEEE.

3.1 Descricao

A especificacao do IEEE 802.11 define uma camada MAC e diversas camadas fısicas, possi-bilitando uma variedade de caracterısticas de acesso ao meio. Basicamente ele trabalha em duasconfiguracoes, como mostrado na figura 3.1:

• Independente (ad hoc): as estacoes comunicam diretamente umas com as outras, seminfra-estrutura de suporte, formando as redes ad hoc. Neste modo eles efetuam acomunicacao ponto a ponto com os elementos que se encontram mais proximos do alcanceda antena.

• Infra-estruturada: as estacoes comunicam via pontos de acesso, os quais sao parte de umsistema de distribuicao de comunicacao, cobrindo uma area maior. Os pontos de acessocoordenam o funcionamento e a comunicacao com as estacoes, controlando a autenticacao,o acesso e a troca de acessos.

21

CAPITULO 3. WI-FI 22

A comunicacao basica de diversos nos e denominada Basic Service Set, (BSS), onde edefinido que um determinado grupo de estacoes podem comunicar umas com as outras. Acomunicacao independente e definida como Independent Basic Service Set, (IBSS) e a infra-estruturada e Infrastructure BSS. A interconexao de um ou mais BSS, atraves de um outro meio,como a rede fixa forma o Extented Service Set, (ESS). Cada BSS e identificada pelo seu numerode endereco, definido como network id (NWID).

Figura 3.1: Modos de funcionamento do IEEE 802.11. Infra-estruturado e ad hoc

O protocolo 802.11 cobre a camada de enlace e a camada fısica, sendo definida uma camadade enlace sobre tres camadas fısicas, como pode ser visto na figura 3.2

Figura 3.2: Organizacao da pilha do IEEE 802.11

3.2 Camada Fısica

Para a comunicacao sao definidos tres tipos de modem de radio, dois usando radio trans-missao, atraves do spread spectrum, sobre a banda ISM, e um usando infravermelho. A seguir,uma breve descricao dos tres:


• Frequency Hop Spread Spectrum (FHSS): Trabalha sobre a banda ISM, na faixa decomunicacao de 2400 a 2483.5 GHz, sobre 79 canais de frequencia com largura de bandade 1 Mhz, permitindo ate 26 redes sobrepostas. A modulacao utilizada e a Gaussian-shaped Frequency Shift Keying, (GFSK) nıveis 2 e 4, onde atinge taxas de transmissao de1 e 2Mbps. Devido a modulacao GFSK nıvel 4 a taxa de transmissao e maior, mas emcontrapartida e mais sensıvel a erros;

• Direct Sequence Spread Spectrum (DSSS): Tambem sobre a banda ISM, em multiploscanais, de 2.4 a 2.4835 GHz, com uma separacao entre os canais de 30MHz. Essaconfiguracao permite ate tres redes comunicando em proximidade umas com as outrassem interferencias maiores. Ele atinge a taxa de transmissao de 1 e 2Mbps, utilizandoa modulacao DQPSK e DBPSK e a potencia de transmissao e de 1000mW, com pos-sibilidades de ajuste ate valores de 100mW. Uma extensao a esse padrao, chamado deHigh-Rate Direct Sequence Spread Spectrum, (HR/DSSS), que utiliza o ComplementaryCode Keying(CCK), permite valores de conexoes que vao de 5.5 a 11 Mbps. Essa extensaotambem e conhecida como 802.11b, e e a mais utilizada atualmente no mercado;

• Infravermelho (IR): Infravermelho difuso, usando transmissao de 1 e 2Mbps. A modulacaoe por posicao de pulso (PPM) Pulse Position Modulation, 16-PPM e 4-PPM.

Como descrito na secao 2.1, a deteriorizacao da comunicacao devido ao aumento da distanciaou a diversos fatores de ruıdo e absorcao de sinal, as modulacoes utilizadas podem variar paracondicoes mais robustas, necessarias para sinais de baixa intensidade, mas implicando con-sequentemente numa diminuicao da taxa de transmissao. Assim, interfaces que implementamo modo de funcionamento do IEEE 802.11b, variam suas taxas de transmissao de 11Mbps, nasmelhores condicoes de transmissao, a 1Mbps, onde o sinal recebido e consideravelmente debaixa intensidade.

Um fator a ser levado em conta e que o desempenho da rede como um todo e fortementeinfluenciado pela posicionamento das estacoes, e como sera mostrado adiante, o IEEE 802.11nao preve a diferenciacao de servicos. Um estudo da degradacao da taxa de transmissao e dadiferenciacao de servicos e feito em [12]. De acordo com esse trabalho, a diminuicao da taxade transmissao em funcao da distancia pode levar a perdas de informacoes de servicos de altaprioridade, sem nenhum tipo de distincao entre os trafegos utilizados. Este e um ponto que seraressaltado novamente, mais ao final do capıtulo.

3.3 Camada de Enlace

A camada de acesso ao meio descrita pelo 802.11 possui diversas funcionalidades defragmentacao de quadros, retransmissao e controle de confirmacao. Ela prove dois mecanismos


de acesso basico, o Distributed Coordination Function, (DCF), onde existe o compartilhamentoeficiente do meio de acesso usando contencao do canal, e o, Point Coordination Function, (PCF),um metodo de acesso de polling, onde um coordenador seleciona qual elemento tem o direito detransmissao. O modo de uso do PCF e opcional e estabelece um metodo de acesso ao meio semcontencao.

3.3.1 Procedimento de Acesso ao Meio

O procedimento de acesso ao meio usando o DCF e conhecido como o Carrier Sense MultipleAccess with Collision Avoidance,(CSMA/CA), [42]. O CSMA tambem e utilizado na Ethernet,definida pelo padrao IEEE 802.3, onde a estacao que deseja mandar alguma mensagem detectase o meio esta livre, senao espera por um tempo definido, para novamente tentar efetuar a trans-missao. No caso da Ethernet, o CSMA e usado com um sistema de deteccao de colisao, CollisionDetection, formando o CSMA/CD. A deteccao de colisao e inviavel na transmissao de radio, poisa transmissao influencia na recepcao do sinal, e nem todas as estacoes podem ouvir umas as ou-tras.

No caso do CSMA/CA, quando vai comecar a transmitir, a estacao escuta o canal para detec-tar se existe alguma outra estacao transmitindo. Se o meio esta sem desocupado por um tempomaior que o DCF InterFrame Space, (DIFS), a estacao comeca a transmitir. Caso contrario, atransmissao e atrasada ate que ele esteja liberado. Este controle e feito atraves de um tempo-rizador denominado backoff timer, sendo iniciado com um intervalo aleatorio, definido comobackoff interval. Ele e decrementado a medida que a estacao percebe que o canal esta liberado, equando estiver zerado, ela transmite. Se ocorrer alguma transmissao durante o descrescimo, estee parado e reativado se o canal estiver liberado de novo apos um tempo maior que o DIFS.

A variacao dos tempos utilizados no intervalos entre os frames muda o nıvel de prioridade datransmissao, dando preferencia para alguns tipos de trafego. O DIFS, usado no DCF, e o tempomınimo para a transmissao de servicos baseados em contecao, onde as estacoes tem acesso livreapos o seu termino.

Os outros tempos sao o Short InterFrame Space (SIFS), para as transmissoes de alta priori-dade como os quadros de ack e a sequencia RTS/CTS, o Point-coordination Function InterframeSpace, (PIFS), usado no modo PCF durante a operacao de liberacao de contencao, e o ExtendedInterframe Space, (EIFS), o maior de todos e usado apenas quando os frames recebidos peloMAC possuem algum tipo de erro, permitindo um tempo para a correcao destes. A figura 3.3mostra o esquema temporal dos intervalos.

O DCF adota uma tecnica chamada slotted binary exponential backoff. A estacao podetransmitir apenas no inicio de cada slot de tempo, cujo valor e igual ao tempo necessario paraqualquer estacao detectar alguma transmissao no meio. O backoff timer e escolhido uniforme-


Figura 3.3: CSMA/CA

mente no intervalo (0,CW-1) definido como Backoff Window (Contention Window). Na primeiratentativa de transmissao, CW = CWmin, e e dobrado a cada tentativa ate um valor CWmax.Este algoritmo reduz a probabilidade de colisoes e mantem a estabilidade da transmissao quandoa carga de transmissao esta muito alta.

3.3.2 Retransmissao

Cada quadro enviado possui dois contadores associado a ele, sendo essa associacao emfuncao do seu tamanho. Caso o quadro seja menor que um limite determinado, chamado deRTS Threshold, o contador short retry count e associado, caso contrario e o long retry count.Quando a transmissao falha, os contadores sao incrementados, e o quadro retransmitido. Assimque os contadores atingem um determinado limite, o quadro e considerado descartado e a camadasuperior e notificada da perda.

Caso chegue alguma confirmacao, os contadores sao resetados. Para cada contador existe umcaso especifico em que eles sao zerados. No short retry quando ocorre a recepcao de um quadroCTS, e no long retry com a chegada da confirmacao de um quadro maior que o RTS Threshold.

O uso de dois contadores e devido ao ajuste de desempenho da rede, como sera descrito maisadiante.

3.3.3 No Escondido

O problema da impossibilidade dos nos nao ouvirem uns aos outros, o hidden node, surge dofato que a atenuacao entre alguns elementos e forte o suficiente para diminuir a comunicacao en-


tre eles. Mas isso, somado com a comunicacao deles com um terceiro elemento, que se encontranuma posicao intermediaria, pode causar uma interferencia entre as transmissoes. Isso acon-tece por que os nos so possuem informacoes locais sobre o canal estar livre, impossibilitando atransmissao para um no em um local em comum.

Para contornar esse problema e utilizado um mecanismo de handshaking, chamadoRTS/CTS. Neste processo sao trocadas duas mensagens entre os nos comunicantes, Request ToSend, (RTS) e Clear To Send, (CTS). Ambos os quadros informam o tamanho da transmissao,onde os outros elementos da rede sabem por quanto tempo o canal sera utilizado. Quando o canalesta liberado, um quadro de controle RTS e enviado, anunciando que a estacao deseja transmi-tir. Este quadro e respondido com um quadro CTS, indicador da estacao receptora, informandoque esta preparada para receber os dados. A figura 3.4 ilustra o esquema de funcionamento,considerando dois nos efetuando uma transmissao para uma estacao base.

Figura 3.4: No Escondido: Mecanismo de RTS/CTS

3.3.4 Virtual Carrier Sense

O Carrier Sensing e o metodo no qual as estacoes determinam se o canal esta livre para atransmissao. O 802.11 utiliza dois tipos de deteccao do canal: um fisico e um virtual. O fısicoescuta o meio e atraves do sinal recebido informa sobre a possibilidade de transmissao dos dados.Mas devido ao problema do hidden node, essa solucao nao e completa. Nesse caso entra o outrotipo de deteccao, onde e utilizado um mecanismo de transmissao chamado Virtual Carrier Sense,atraves do uso de uma tabela de alocacao de tempo, chamada de Network Allocation Vector, NAV.O NAV e um temporizador que indica quanto tempo o meio de comunicacao estara reservado.No momento que uma estacao vai enviar um dado, ela seta seu NAV para o tempo necessariopara o envio, enquanto as outras esperam por esse mesmo tempo, decrementando o valor de seusNAV. Quando zera, o meio de transmissao e considerado livre.


Atraves do uso do NAV, operacoes atomicas podem acontecer sem serem interrompidas,como no caso do RTS/CTS. O envio do CTS atinge a todas as estacoes no alcance, de formaque os outros elementos recebem e atualizam suas informacoes sobre a transmissao dos nos noNAV. Assim os nos que recebem o RTS e o CTS entram em modo de espera, determinado noNAV. Caso mais de um no envie o RTS ao mesmo tempo, ocorrera a colisao dos quadros, naoacontecera o envio do CTS, interrompendo o resto da transmissao. A figura 3.5 mostra os inter-valos de tempo dos envios dos RTS/CTS e a atualizacao dos NAV dos outros nos na proximidade.

Figura 3.5: Virtual Carrier Sense

3.3.5 Tipos de quadro e fragmentacao

Sao tres tipos de quadros definidos nesse padrao, todos diferenciados pelos cabecalhos decontrole e pelo tamanho: quadros de dados, controle e gerencia.

Os canais sem fio possuem caracterısticas que limitam o envio dos quadros. O controladorMAC efetua a fragmentacao dos quadros de dados, enviando-os em diferentes segmentos. Cadasegmento enviado em rajada tem a sua confirmacao de envio efetuada. Dessa forma, para cadaquadro de acknowledge nao enviado, e feito o random backoff e a retransmissao deste quadro.

3.4 Gerenciamento da camada de enlace

Devido as dificuldades e caracterısticas do meio de transmissao, na camada de enlace dopadrao 802.11 foram definidas algumas funcoes de gerenciamento de sua utilizacao. O usodestas informacoes e funcionalidades definidas formam a base para o desenvolvimento da APIproposta, considerando a interface Wi-Fi. Como sera descrito no decorrer desta secao, diversasdestas caracterısticas auxiliam a avaliar e controlar a comunicacao que esta acontecendo.


3.4.1 Funcoes de Gerenciamento

As funcoes de gerenciamento sao divididas em tres grupos:

• Sincronizacao: funcoes de informacao das carecterısticas do funcionamento das redes ede sincronizacao do relogio entre as estacoes;

• Gerencia da conexao: o estabelecimento e controle da conexao envolve os processos deroaming e associacao, que tratam da movimentacao da area de cobertura de um BSS paraa area de outro, sem que aconteca perdas de conexao. Tambem tratam da localizacao deBSS que estejam no alcance e com qualidade de sinal aceitavel. A associacao trata desteultimo caso, sendo responsavel pela escolha de pontos de acesso de melhor qualidade.

• Controle de energia: funcoes de controle e economia de energia, como desligamentoperiodico e armazenamento de dados;

Parte desse gerenciamento e feito atraves do uso de quadros de sinalizacao. Apesar dooverhead substancial causado pelo seu envio, eles fornecem muitas informacoes importantespara o funcionamento e gerenciamento da WLAN, como por exemplo no momento em que ospontos de acesso enviam os dados para o reconhecimento de outras estacoes. As interfaces derede das estacoes ficam em modo de escuta em diversos canais, e quando recebem esse quadro,as informacoes necessarias para a comunicacao com o ponto de acesso sao atualizadas.

Os quadros de sinalizacao tem cinco bytes e possuem o endereco de destino setado parabroadcast, de maneira que todas as estacoes no alcance o recebam. As funcoes de controle a asinformacoes estao organizadas dentro do seu cabecalho da seguinte maneira:

• Intervalo: representa o intervalo entre as transmissoes dos quadros de sinalizacao. Eletambem informa as funcoes de gerenciamento de energia o momento em que as estacoesdevem ser ativadas para efetuar a sincronizacao;

• Timestamp: e o valor utilizado pelas estacoes para atualizar seus relogios com o ponto deacesso ou outras estacoes;

• Service Set Id (SSID): este e o identificador da BSS que esta funcionando de maneira ativa.Por exemplo, antes de comunicarem com o ponto de acesso, as estacoes devem possuir oseu SSID. Assim, por default, os pontos de acesso incluem o valor do SSID nos quadrosde sinalizacao, de forma que as estacoes detectem estes valores e atualizem suas interfacesde rede. A utilizacao dessa opcao nao e padrao devido aos riscos de seguranca envolvidos,como o identificador do BSS sendo divulgado indiscriminadamente;


• Taxas suportadas: os valores das taxas que as estacoes e pontos de acesso suportam eestao utilizando. Com essa informacao, as estacoes podem avaliar quais os pontos deacesso podem ser utilizados para a comunicacao, de acordo com a performance desejada;

• Parametros de transmissao: este campo identifica qual a parte da especificacao da ca-mada fısica esta sendo utilizado (DS, FH, etc.). Caso seja o FH, ele informa qual o padraode saltos utilizado e o tempo para o acesso;

• Capacidade de Informacao: representa quais os requerimentos necessarios para asestacoes participarem da comunicacao com a LAN, como por exemplo o uso deinformacoes de seguranca;

• Traffic Indication Map (TIM): informacao enviada periodicamente pelo ponto de acessopara as estacoes, indicando entre as que estao em modo de economia de energia as quepossuem dados armazendos nos buffers.

Em resposta aos quadros de sinalizacao, as estacoes enviam quadros do mesmo tipo, com asinformacoes desejadas. Em muitos casos, este tipo de quadro pode ser utilizado para acessar asinformacoes de pontos de acesso, como no caso dos sniffers de rede [43].

Os outros quadros do gerenciamento sao relativos a associacao e autenticacao das estacoesna rede, usados para o estabelecimento da conexao entre os nos e os pontos de acesso.

3.4.2 Sincronizacao

A sincronizacao e fundamental para a comunicacao entre as estacoes, sendo atraves delaque e efetuado o seu reconhecimento. Estando elas na mesma regiao, esta etapa coordena oenvio e recepcao da mensagem, assim como os eventos envolvidos, atraves da sincronizacao dosrelogios das camadas de enlace. No momento do estabelecimento da conexao, essa sincronizacaoatualiza as capacidades das redes envolvidas, como os metodos e taxas de transmissao utilizados,os identificadores da rede e os relogios das estacoes. Para manter os relogios da camada de enlacesincronizados, as estacoes utilizam as transmissoes periodicas de sinalizadores para calibra-los.

Cada BSS possui um timestamp pre-determinado, que e distribuıdo entre as estacoes. No casodas redes infra-estruturadas, os pontos de acesso enviam sinalizadores com as informacoes deseus relogios, atualizando todos as estacoes que participam da BSS. Estes quadros de sinalizacaosao escalonados com um intervalo de tempo pre-determinado, mas que pode ser atrasado devidoao CSMA. Dessa forma, apos o envio de alguns sinalizadores, a sincronia do escalonamento erenegociada. Intervalos muito grandes entre os sinalizadores diminuem o overhead, mas dimi-nuem o tempo de sincronizacao, aumentando a chance das estacoes perderem a conexao. Emcontrapartida um tempo maior, alem de aumentar o overhead de envio, possibilita o aumento


do consumo de energia, diminuindo o tempo de espera que as estacoes permanecem desligadas.Normalmente esse intervalo e setado para 100ms.

Nas redes ad hoc, como nao ha pontos de acesso, uma das estacoes envolvidas assume oidentificador SSID da rede e envia o sinalizador. Depois de receberem o quadro de sinalizacao,as estacoes esperam pelo tempo determinado no intervalo, e caso nao recebam outro sinalizador,assumem a funcao e enviam o seu sinalizador.

Scanning

Para que uma estacao comece a comunicacao em uma IBSS ou com um ponto de acessonuma BSS e necessario fazer o processo de Scanning, que pode ser ativo ou passivo. O passivoconsiste em ouvir os trafegos de outras estacoes o que minimiza o consumo de energia, mastem um gasto de tempo maior. Neste processo a estacao escuta periodicamente os canais dis-ponıveis para detectar a presenca de sinalizadores, extraindo as informacoes sobre cada BSS quepercebem, e em funcao da qualidade do sinal de cada recepcao, decide qual sera conectado.

No modo ativo as estacoes enviam sinalizadores atraves dos canais disponıveis e esperampela resposta. Apos receberem as respostas, eles enviam de novo, com o valor do SSID do pontode acesso ou da estacao ad hoc. Caso algum ponto de acesso possua o valor de SSID semelhante,ele retorna um quadro com a informacao para a conexao.

3.4.3 Gerencia da conexao

O processo de conexao no IEEE 802.11 envolve etapas de autenticacao, associacao e ro-aming. A autenticacao e o procedimento que permite a identificacao entre as estacoes e umaWLAN, e apesar de poder ser utilizada entre quaisquer duas estacoes, ela apresenta um fa-tor de seguranca na conexao com os pontos de acesso. Sao utilizados dois algoritmos paraa autenticacao. Open System Authentication, onde nenhuma verificacao e feita, e as estacoescomecam a comunicar assim que entram em contato, e o Shared Key Authentication, que usa acriptografia WEP, onde atraves da troca de mensagens de identificacao usando uma chave WEPas estacoes sao autenticadas. Atualmente este sistema de seguranca e conhecido como falho,pois outras estacoes podem utilizar as informacoes do SSID, que sao trocados entre os pontos deacesso e as estacoes moveis durante a sinalizacao, e com isso ganhar acesso aos dados da rede.

A associacao e o mecanismo que prove uma mobilidade transparente para as estacoes, eocorre apos a autenticacao. O padrao nao descreve politicas de como as estacoes podem escolherquais os melhores pontos de acesso para associarem. A figura 3.6 mostra como normalmentee estabalecida associacao entre a estacao movel e os pontos de acesso. A associacao e restrita a


apenas um ponto de acesso, sendo logicamente semelhante a conexao de um cabo. De forma quetambem nao e previsto seu uso no modo ad hoc. Mas como sera mostrado nas proximas secoes,a extracao da informacao de qualidade do canal pode ser de alta relevancia para as aplicacoes nomodo ad hoc.

Normalmente, o processo usado e o seguinte: a estacao, usando as informacoes do ReceiverSignal Strength Indicator, RSSI, do Carrier Sense e consumo de energia, atraves da potenciautilizada, detecta se o sinal da comunicacao com o ponto de acesso esta fraco e decide procuraroutro. Nesse ponto e feito roaming da estacao.

Figura 3.6: Etapa de escolha e associacao com pontos de acesso

O roaming entre diferentes celulas e definido de forma superficial no padrao, deixando paracada fabricante os detalhes de implementacao. Desta forma, para tornar possıvel a interopera-bilidade do roaming entre equipamentos de diferentes fabricantes, foi definido o Inter-AccessPoint Protocol, (IAPP), adotado por um grupo de empresas. Comparando com o que e feito emredes de telefonia celular a principal diferenca e que por ser um sistema de comunicacao que usaquadros, as perdas de conexao e retransmissao dos quadros devem ser tratados pelos protocolosdas camadas superiores, de maneira que afeta o desempenho da comunicacao.

3.4.4 Gerenciamento de Energia

O IEEE 802.11 define quatros estados de funcionamento, e dois destes sao voltados paraminimizar o uso de energia da estacao. Nao e definido qual o momento em que a mudanca entreos estados de nıvel de energia mais baixos devem ocorrer, e sim as regras para a mudanca. Todosos estados sao relacionados aos modos de transmissao e recepcao dos dados, sendo estes:


• Estado de dormencia (Sleep): a interface esta parcialmente desligada;

• Estado ocioso (Idle): a interface utiliza o carrier sense para detectar se alguma transmissaode sinal esta ocorrendo na regiao;

• Estado de recepcao (Rx): a recepcao e reconstrucao do sinal e efetuada;

• Estado de transmissao (Tx): os dados sao transmitidos;

A tabela 3.1 mostra a relacao de consumo de energia medio de cada estado, para o padraoWi-Fi (IEEE 802.11b). Placas da Lucent, chipset PrismII.

Estado Potencia (mW)Dormencia 50

Ocioso 740Rx 900Tx 1350

Tabela 3.1: Consumo de energia de uma interface IEEE 802.11b

No estado de dormencia, a interface mantem suas funcionalidades de recepcao e transmissaode dados desligadas, sendo este o modo de funcionamento mais economico, apesar de possuiralgumas restricoes de utilizacao. A transicao para os outros estados de maior consumo de ener-gia e custoso, devido a ativacao dos amplificadores e os circuitos do modem de radio. Mas ofator principal e a necessidade de um elemento que efetue uma gerencia externa, coordenando omomento em que ocorrera essa transicao entre os modos de energia.

Seu funcionamento e melhor organizado no caso do acesso infra-estruturado, por causa dapresenca do ponto de acesso. Este controla as estacoes atraves do uso dos quadros de sinalizacao,pois apos um intervalo pre-determinado, as estacoes voltam ao modo ocioso e escutam o canal,recebendo as informacoes atraves destes quadros de sinalizacao. Quando os pontos de acessonecessitam encaminhar quadros para as estacoes que estao em modo de dormencia, eles armaze-nam estes quadros em buffers internos, e no envio do proximo sinalizador, reportam as estacoes aexistencia dessas pendencias. Assim essas vao aos modos necessarios para a recepcao dos dados.Caso nao exista nenhuma pendencia, continuam no modo de economia maxima.

No acesso ad hoc, as estacoes nao possuem um elemento coordenador de funcionamento,sendo necessario que os nos vizinhos sejam responsaveis por armazenar os quadros destinadosa outros que estejam em estado de dormencia. Esta e uma situacao ineficiente neste cenariode comunicacao, sendo so possıvel com a ajuda de mecanismos de controle, nao previstos naespecificacao. Em [44] e analisado um metodo de economia de energia em redes ad hoc atravesda dormencia, sendo melhor aplicada em redes nas quais a aplicacao fica sem trocar informacao


por um tempo consideravel. Neste caso, o custo do uso de um mecanismo de controle e mi-nimizado pelos ganhos do consumo de energia. Mas de maneira geral, o modo de dormencianao e explicitamente utilizado, sendo considerado o estado ocioso como o de maior economia deenergia.

O estado ocioso gasta valores de energia aproximados ao de recepcao por estar ouvindoo canal a todo momento, a espera de novos quadros. No modo de recepcao, o aumento deconsumo de energia e caracterizado pela demodulacao do sinal, onde a interface processa ossinais recebidos, verificando se e um quadro, e demodulando a informacao para a construcao dosquadros.

Devido aos amplificadores de potencia e a necessidade de minimizar a atenuacao do sinal, omodo de transmissao e o que possui o maior consumo de energia. Algumas interfaces permitemo ajuste destes valores de potencia de transmissao, pois quando as estacoes estao relativamenteproximas, o nıvel de ruıdo e baixo de maneira que a atenuacao do canal nao e acentuada, a energiagasta na transmissao do sinal pode ser economizada significativamente, diminuindo tambemproblemas de interferencias devido a sinais muito fortes. Mais a frente sera discutida a utilizacaodestas caracterısticas do modo de gerenciamento de energia no desenvolvimento da API.

3.5 Parametros para Ajuste de Desempenho

Um dos pontos principais das redes Wi-Fi e serem configuraveis, permitindo um ajuste nodesempenho do seu funcionamento. Este fator e vital, pois devido as questoes de mobilidadee dificuldade de comunicacao, certas caracterısticas sao essencias para a sintonia do funciona-mento. Alguns trabalhos de avaliacao de desempenho usam esses parametros [11, 12], propondomaneiras de melhorar a qualidade da comunicacao e do servico oferecido. A acessibilidade aesses parametros e um dos focos de uso da API. Alguns desses parametros sao:

• Fragmentacao: A fragmentacao de mensagens em quadros e controlada pelo parametroFragmentation Threshold, cujo valor padrao e 2346 bytes. Seu valor influencia direta-mente na perda de quadros, pois quanto maior for, maior sera a chance de colisoes e inter-ferencias;

• Requisicao do canal: Este parametro define o tamanho maximo de um quadro sem queseja executada alguma autorizacao previa. Dessa forma, se quadros maiores que RTS Th-reshold forem enviados, a unidade ira trocar as mensagens RTS/CTS, evitando as colisoes,e so apos enviar o quadro. O valor default e de 2347 bytes, e quanto menor for seu va-lor, maior sera a utilizacao do mecanismo RTS/CTS, que reduz o aproveitamento da rede,apesar de evitar a perda de quadros devido a colisao;


• Retransmissao: o reenvio de quadros acontece antes sem que ele seja dado como perdido.Assim ele e reenviado um numero de vezes antes de retornar para a camada superior comoquadro perdido. Os valores de controle sao vinculados ao RTS Threshold, onde sao relacio-nados dois parametros, o Short Retry Limit, para quadros menores que o RTS Threshold e oLong Retry Limit para os maiores, sendo seus valores default 4 e 7 vezes respectivamente;

• Potencia de transmissao: o padrao preve diversos nıveis de potencia para uma mesmainterface, mas nem todas as interfaces permitem esse ajuste. Pouca potencia implica emredes mais densas e menos consumo de energia, enquanto um valor maior permite umalcance mais ajustado;

• Sensibilidade ao canal: as interfaces sem fio possibilitam um ajuste aos nıves deidentificacao do sinal recebido possibilitando a recepcao de sinais com fraca energia. Emcontrapartida a sensibilidade aos ruıdos aumetna consideravelmente.

O acesso a estes parametros depende da implementacao dos chipsets das interfaces, deacordo com o grau de conformidade com a especificacao. E interessante notar que as diferentesimplementacoes, muitas vezes com caracterısticas unicas do fabricante, podem ter influencia nodesempenho [11].

3.6 Padroes IEEE 802.11

O padrao 802.11 contempla um grupo de subpadroes com o objetivo de estender algumasfuncionalidades do padrao original, com relacao a seguranca, velocidade e QoS.

• 802.11a: a camada fısica preve o funcionamento na faixa de 5 GHz, com oitos canais defrequencia, um fator que diminui a interferencia de outros elementos. A taxa maxima docanal e de 54 Mbps. Padrao finalizado em 1999;

• 802.11b: definicao da camada fısica para funcionamento na faixa de 2.4 GHz, com trescanais de frequencia. A taxa maxima do canal e 11 Mbps. Em redes com muitos elementosativos a velocidade tende a cair, e os tres canais podem ter nıveis de interferencia entre si.Padrao finalizado em 1999 e e a versao que e mais difundida no mercado atualmente;

• 802.11d: Trecho suplementar do padrao da camada de enlace, onde define regras de fun-cionamento em paıses com restricoes no uso do canal de comunicacoes. Os padroes do802.11 nao podem funcionar legalmente em alguns paıses e o 802.11d define as restricoese alguns recursos. Desenvolvimento em andamento;


• 802.11e: parte suplementar para a camada MAC que prove suporte a QoS para diversasaplicacoes, permitindo classes de servico diferenciadas e nıveis de gerencia para diferentestipos de dados. Ele sera utilizado com os padroes da camada fısica definidos nos 802.11a,be g. Padrao finalizado em 2002;

• 802.11f: um documento que define as regras de funcionamento de pontos de acesso dediferentes fabricantes, fazendo com que os pontos de acesso possam trocar informacoessobre as estacoes que estao fazendo handover entre eles. Esta especificacao serve paraminimizar os problemas entre produtos de diferentes fabricantes. Padrao em finalizacao;

• 802.11g: Uma definicao para a camada fısica nas WLANs que operam em ambos canais,2.4GHz e 5 GHz, com o uso de tres canais de radio. A taxa maxima e de 54 Mbps, paraambas as frequencias. Ele utiliza modulacao OFDM, e por questoes de compatibilidade su-porta a CCK, usada no 802.11b, que atinge as taxas de 11 Mbps. Para as taxas mais rapidas,ele trabalha com o Packet Binary Convolutional Coding (PBCC). E um padrao maiscomplexo, por trabalhar com tres tipos de modulacao, mas com o custo compensatoriose considerar para produtos que planejam suportar os dois modos. Padrao finalizado em2002;

• 802.11h: Este padrao e suplementar a camada de enlace com regras de uso para as WLANsque trabalham na faixa de frequencia de 5 GHz. Este padrao segue as regras europeias deuso, que requer que os produtos nessa faixa de frequencia tenham controle da transmissaode potencia (TPC) e selecao dinamica do uso da frequencia (DFS). O TPC limita a potenciado sinal transmitido para o valor mınimo que alcance o usuario mais proximo. O DFS se-leciona o canal de frequencia que possua menos interferencia com outros sistemas. padraofinalizado em 2003;

• 802.11i: Suplementar a camada de enlace, com objetivo de aumentar a seguranca. Ele seaplica aos padroes 802.11 a,b e g, provendo alternaticas ao WEP com novos metodos deautenticacao e criptografia. A seguranca e um dos pontos mais fracos do padrao 802.11,inclusive afetando sua expansao no mercado, atualmente. As atualizacoes do 802.11ipreveem atualizacao em diversos nıveis de seguranca das WLANs, como por exemploo uso do TemporalKeyIntegrityProtocol, (TKIP).

• 802.11x: Um framework para regular o controle do acesso das estacoes clientes atravesde metodos de autenticacao, sendo uma importante parte para aumentar a seguranca.Aplicavel aos padroes 802.11a, b e g.

3.7 Interfaces 802.11 no Linux

O desenvolvimento de drivers para as interfaces 802.11 no Linux faz parte do projeto LinuxWavelan IEEE driver, criado no inicio da decada de 90, e e desenvolvido sobre as regras GPL


[45] de projetos open-source. Seu objetivo e a criacao de drivers para as diversas interfaces dopadrao 802.11 e suas diferentes implementacoes, que por vezes possuem detalhes proprios dofabricante e um certo grau de conformidade com o padrao. Por ter contribuicoes de diversasempresas e entusiastas, o seu desenvolvimento e orientado a maior transparencia possıvel, fatoressencial para o estudo e desenvolvimento deste trabalho. Como de praxe no desenvolvimentode drivers para Linux, quanto mais informacoes sobre o hardware envolvido, mais detalhesdo funcionamento serao possıveis. Uma lista contendo quais as placas e seus firmwares edivulgada pelos desenvolvedores do projeto, uma vez que nem todas as interfaces de WLANstem o suporte no Linux. Atualmente, os dois dos principais chipsets, que contem as definicoesdo controlador MAC, sao o PrismII da Intersil [46] e o Hermes da Agere(Lucent)[47]. Umponto importante a ser ressaltado que a API deste trabalho foi desenvolvida sobre os drivers dasestacoes e nao dos pontos de acesso, os quais tem como principal funcao atuarem como Bridges

para as LANs e/ou outros tipos de redes.

Para o chipset da Intersil, existe um quadro linux-wlan-ng desenvolvido pela empresa Abso-lute Value Systems [48], responsavel pelo driver e por ferramentas de configuracao do acesso.O seu principal driver e o prism2 cs para a comunicacao PCMCIA, e o wlancfg para alterar asconfiguracoes da interface e acessar a base de informacoes desta. Sua distribuicao e funciona-mento estao nos kernel 2.0 e 2.2, mas nao fazia parte integral do Linux. Para este trabalho foiescolhido o driver da Orinoco/Lucent que possui um alto grau de compatibilidade com o chipsetPrism2. Este driver possui mais funcionalidades e sera descrito a seguir.

3.7.1 Orinoco

A partir da versao 2.4 do kernel, os drivers e o suporte a configuracao das WLANs fizeramparte integral do sistema operacional. Por sua implementacao ser leve e sem muito consumo derecursos, sua portabilidade para versoes do Linux para sistemas embutidos e relativamente facil.Diversos projetos como o Intimate Linux [49], respectivamente voltados para roteadores de baixacapacidade computacional e dispositivos como Palm´s e PocketPCs, utilizam suas funcionalida-des.

As interfaces Wi-Fi deste trabalho usam o barramento PCMCIA, cujo suporte tambem jaesta integrado ao kernel do Linux a partir da versao 2.4. Seu sistema de controle e responsavelpor identificar a interface e carregar o driver apropriado. Os modelos de cartao PCMCIA utili-zados foram os Intersil PrismI LinkSYS e o Lucent Wavelan-IEEE/Orinoco, compatıveis como IEEE 802.11b, mas sem todas as funcionalidades, como um modo ad hoc de funcionamentonao totalmente compatıvel com a especificacao. A descricao do perfil de uma das placas podemser vistas na figura 3.7 abaixo, informacoes como versao do chipset (vers 1 1.0), veloci-dades alcancadas (lan speed) e endereco MAC (lan node id), foram extraıdas atraves docomando de gerencia do barramento PCMCIA, dump cis.


Figura 3.7: Dados relativos ao cartao PCMCIA da interface Wi-Fi

A implementacao do chipset nas placas influencia diretamente na escolha do driver, poismuitas vezes o chipset pode nao ser compatıvel com o padrao, como nas primeiras placas queimplementavam parcialmente o protocolo MAC. Vale ressaltar que os fabricantes lancam algu-mas atualizacoes constantes dos firmwares dos chipsets, sendo que algumas funcoes de acessosao modificadas, devido a maior integracao do circuito como tambem uma regularizacao com aespecificacao, ou mesmo devido as funcionalidades especıficas dos fabricantes. Isto acarreta umcenario em que e relativamente comum placas de diferentes fabricantes nao comunicarem entresi. Neste caso entra o grupo Wi-Fi, que verifica a conformidade dos chipsets com a especificacaoe garante a comunicacao entre estas.

O chipset utilizado e o Hermes da Lucent, que possui algumas diferencas em algumas ca-racterısticas de diferentes versoes, o que altera o acesso as funcionalidades do driver, mas naointerfere na comunicacao com outras interfaces. O driver utilizado foi o Orinoco, da serie deplacas Wavelan IEEE/Orinoco, que alem de ser compatıvel com as placas Wi-Fi utilizadas, e umdos mais comuns e robustos atualmente. O Linux possui tres drivers distintos que conseguemutilizar os recursos dessa placa:

• wavelan2 cs: criado com base no wavelan cs, um dos primeiros drivers, feito para asprimeiras placas que implementavam uma radio LAN, com um suporte basico ao padrao802.11. Possui diversas funcionalidades e e mantido pela Lucent, que nao disponibilizatodo o seu codigo de funcionamento. E considerado um avanco do wavelan cs, cujosuporte foi descontinuado a partir do kernel 2.3.15. ;


• wlan cs: este driver foi o primeiro a oferecer total suporte ao 802.11b, sendo compatıvelcom o chipset Hermes da Lucent, que oferece toda a implementacao do protocolo da ca-mada de enlace, com uso opcional do RTS/CTS, fragmentacao, roaming, escolha de taxade transmissao automatica, e suporte aos funcionamentos estruturados e ad hoc. Por tersido originalmente desenvolvido pela Lucent, que nao disponibiliza todo o seu codigo, eter caracteristicas legadas com o wavelan cs, parte de seus desenvolvedores o descontinu-aram em favor do orinoco cs;

• orinoco cs: considerado o driver mais robusto, atendendo as funcionalidades daespecificacao do 802.11b. E mantido por diversos entusiatas e membros de diferentes em-presas possuindo o codigo totalmente aberto e faz parte do kernel do Linux desde a versao2.4.3. Tambem e um dos poucos que possibilita o suporte a medida de qualidade de sinalno modo ad hoc, caso previsto na especificacao apenas para o modo infra-estruturado. Eletrabalha com diferentes tipos de dispositivos, que possuem o mesmo controlador MAC,como os dispositivo Lucent Wavelan-IEEE/Orinoco, e o Intersil PrismI.

Configuracoes

A configuracao das interfaces Wi-Fi e feita atraves de ferramentas, executadas na linha decomando, que acessam os drivers e executam comandos sobre estes, modificando alguns deseus parametros, ou recuperando informacoes desejadas. O funcionamento dessas ferramentase a base para o desenvolvimento da API, de forma que as aplicacoes possam executar essescomandos.

O metodo utilizado no Linux, para acessar os parametros de uma interface de rede e atraves dafuncao ioctl, uma chamada de sistema que trabalha sobre um descritor de arquivo, um socketassociado a essa interface. Os drivers de cada dispositivo definem as operacoes que podemser executadas, atraves de constantes especıficas para o acesso. Assim, na chamada da funcaoioctl sao definidas as operacoes que sao efetuadas sobre o dispositivo. Dessas operacoespodem ser agrupadas as seguintes:

• Operacoes basicas: modos basicos de configuracao e funcionamento, como definicoes deparametros da interface, como nome e modo de operacao. Descritos na tabela 3.2;


Constantes DefinicaoSIOCSIWFREQ define o canal de frequencia (Hz)SIOCGIWNWID define o network idSIOCSIWMODE define o modo de operacao (Ad Hoc, Managed)SIOCSIWSENS define o nıvel de sensibilidade ao canal (dBm)SIOCSIWAP obtem o endereco do ponto de acesso proximo

SIOCSIWESSID obtem o SSID da redeSIOCSIWNICKN seta o nickname do no

Tabela 3.2: Operacoes basicas efetuadas no driver atraves do ioctl

• Operacoes de desempenho: acesso aos parametros descritos na secao 3.5, setados atravesdo driver. Descritos na tabela 3.3;

Constantes DefinicaoSIOCSIWRATE define a taxa utilizada (bps)SIOCSIWRTS define o valor do RTS ThresholdSIOCSIWFRAG define o valor do Fragmentation ThresholdSIOCSIWTXPOW define o valor da potencia de transmissaoSIOCSIWRETRY define os valores para a retransmissaoSIOCSIWPOWER parametros do gerenciamento de energia

Tabela 3.3: Operacoes de desempenho efetuadas no driver atraves do ioctl

• Operacoes do modo infra-estruturado: sequencias de operacoes que possibilitam oscanning de novos pontos de acesso, e informacoes para a associacao da estacao comeles. Descritos na tabela 3.4;

Constantes DefinicaoSIOCGIWAP define o endereco MAC do ponto de acesso

SIOCGIWAPLIST define o novo ponto de acesso encontrado no scanningSIOCGIWSCAN lista e define os resultados do scanning

Tabela 3.4: Operacoes de vinculacao ao Ponto de Acesso no driver atraves do ioctl

• Operacoes de seguranca e proprietarias: essas operacos definem o modo de autenticacaoem que a interface trabalha, e definem operacoes especıficas de cada chipset. Descritos natabela 3.5


Constantes DefinicaoSIOCSIWENCODE define o modo de autenticacao e codificacaoSIOCIWFIRSTPRIV executa comandos especıficos do chipsetSIOCIWLASTPRIV executa comandos especıficos do chipset

Tabela 3.5: Operacoes de seguranca e do chipset efetuadas no driver atraves do ioctl

• Operacoes de estatıstica e seguranca: operacoes que permitem a analise da qualidade darecepcao de quadros e do sinal recebido, possibilitando observar o comportamento de de-terminado canal de comunicacao. Na tabela 3.6;

Constantes DefinicaoSIOCGIWSTATS obtem as estatisticas no /proc/net/wirelessSIOCGIWSPY define o modo de observacao de outros nos

Tabela 3.6: Operacoes de estatıstica do driver atraves do ioctl

Dessa forma, basicamente o funcionamento do Wireless Extensions mescla o uso de chama-das da funcao ioctl, com os parametros de configuracao dos drivers e as informacoes estatis-ticas no diretorio /proc/net/wireless.

A pilha de rede do Linux utiliza uma estrutura (struct device) que mantem asinformacoes sobre o funcionamento do dispositivo no sistema, como os parametros de enderecosde I/O, endereco IP, buffers, e os callbacks do dispositivo, como as funcoes de envio dequadro e de inicializacao. A implementacao do driver orinoco contempla um callbackget wireless stats para pegar as estatısticas armazenadas no /proc/net/wireless,retornando uma estrutura (struct iw statistics) que contem todos os campos definidosna entrada /proc da interface.

O modo espiao funciona para as estacoes no ad hoc, mas necessitam antes fazer uma consultaa tabela arp local, permitindo identificar o endereco MAC das unidades. Caso contrario, a adicaodo endereco e manual.

Capıtulo 4

Bluetooth

4.1 Introducao

O Bluetooth e uma tecnologia que permite a comunicacao de voz e dados atraves de umenlace de radio de baixo consumo de energia e curto alcance. Essa tecnologia foi desenvolvidapela Ericsson, em 1994, com o objetivo inicial de substituicao dos cabos associados a dispositivosperifericos, sendo focada para atender os requisitos de uma comunicacao segura, robusta e barata.Desde entao sua abordagem tem sido estendida, de forma que pudesse atender diferentes tiposde dispositivos, entrando no conceito das Wireless Personal Area Network, WPANs. Em 1999,diversas empresas de computacao e telecomunicacoes criaram um grupo de interesse, o SIG,[10], e a partir dele definiram as funcionalidades do Bluetooth, de maneira mais abrangente.Como seu projeto teve como objetivo atender dispositivos de baixa capacidade, o seu custo deproducao e sua simplicidade de implementacao foram os principais focos.

A especificacao do Bluetooth [1] define um sistema completo a partir da camada de enlaceate a camada de aplicacao, sendo a pilha de protocolos implementada parcialmente em hardwaree software, como mostrado na figura 4.1. O seu nucleo e formado pela Baseband, que controla oenlace de radio-frequencia (RF), o Link Manager Protocol (LMP), responsavel pela configuracaodo enlace estabelecido e os modos de economia de energia e os estados operacionais dos dispo-sitivos, o Logical Link Control and Adaptation Protocol (L2CAP), responsavel pela adaptacaodos dados provenientes das camadas superiores da pilha de protocolos de forma que possamser manipulados pelas camadas inferiores, e o Service Discovery Protocol (SDP), que gerenciaos servicos oferecidos pela interface, informando aos outros elementos sobre as capacidades dodispositivo. No decorrer deste capıtulo serao mostrados os detalhes da pilha de protocolos e amaneira que interagem entre si.

41

CAPITULO 4. BLUETOOTH 42

Figura 4.1: Pilha de Protocolos do Bluetooth

Em sua configuracao basica, o Bluetooth forma pequenas redes, definidas como piconets.Uma piconet pode ser descrita como uma rede onde um no central, denominado mestre, se comu-nica ativamente com os outros nos, chamados de escravos, formando uma topologia em estrela.Segundo a especificacao, e possıvel ter no maximo oito elementos ativos dentro de uma piconet,incluindo o mestre. Dentro de uma piconet apenas nos considerados mestres podem comuni-car com os nos considerados escravos. Caso algum escravo precise comunicar diretamente comoutro escravo, sera necessario criar uma outra piconet onde um dos dois sera o mestre. As pi-conets possuem as caracterısticas de uma rede ad hoc, uma vez que o mestre nao precisa estarassociado a uma infra-estrutura, e qualquer elemento pode se tornar mestre de uma piconet. Aespecificacao tambem preve a intercomunicacao dessas piconets, atraves de elementos em co-mum, criando uma scatternet. A figura 4.2 mostra algumas das configuracoes possıveis daspiconets: (a) piconet com um unico escravo (b) piconet multi-escravo (c) scatternet.

Figura 4.2: As maneiras de comunicacao no Bluetooth. [1]


Como descrito anteriormente, o foco do Bluetooth sao os usuarios, de forma que os servicosdos dispositivos atendam as suas necessidades. Cada um dos dispositivos, presente numa pico-net, fornece um servico que e compatıvel com suas caracterısticas, como por exemplo o fone deouvido, que atende a servicos de som. Assim, a cada interface Bluetooth e associado um identi-ficador da classe dos dispositivo, de forma que durante os procedimentos de criacao da piconet,o mestre ja saiba das capacidades possıveis dos escravos antes que estes estejam conectados. Anomenclatura da classe e definida num grupo maior, que define os tipos de dispositivos, comocomputadores ou fones de ouvido, e dentre estes, as subclasses, como desktops ou handheld. Ecada uma das classes de dispositivos possui um conjunto de servicos associados. A Tabela 4.1mostra os identificadores e os tipos de dispositivos envolvidos

Identificador Tipo de dispositivosMaior computer, phone, audioMenor desktop, laptop, handheld, server

Tabela 4.1: Classe de dispositivos suportados pelo Bluetooth

4.2 IEEE 802.15

Em 1998, o IEEE 802.11 criou o grupo de estudos do WPAN (WPAN-SG), para investigara necessidade da criacao de um padrao de comunicacao que focasse no consumo de energiasignificativamente pequeno, de pouca complexidade que permitisse uma conectividade no nıvelPersonal Operating Space (POS). Este e um espaco que envolve uma distancia de 10 metros apartir de um indivıduo, cobrindo assim todos os dispositivos utilizados, sejam estes carregadosou proximos a ele. Em marco de 1999 foi proposta a criacao do 802.15, que organizou uma novaespecificacao sobre a versao da WPAN proposta pelo Bluetooth, corrigindo alguns problemas epropondo novas solucoes, de acordo com as classes e objetivos dos dispositivos. O IEEE 802.15e dividido em alguns subgrupos de trabalho responsaveis pelo desenvolvimento do padrao. Saoos seguintes:

• Task Group 1 (TG1): responsavel por rever e adapar o padrao Bluetooth, versao 1.1, deacordo com os modelos do IEEE. Esta padronizacao tambem inclui um teste de verificacaopara a implementacao do protocolo, provendo uma descricao da especificacao na lingua-gem SDL. Os resultados desde grupo de trabalho foram reutilizados pelas empresas desen-volvedoras do Bluetooth, sendo que o documento principal do padrao ja esta finalizado;

• Task Group 2 (TG2): este grupo de trabalho e responsavel pela coexistencia entre ospadroes das WPANs e as WLANs. O grupo esta desenvolvendo um modelo de coe-xistencia que permite quantificar a interferencia mutua entre os dois padroes, e a partir


disso desenvolver os mecanismos para impedir as interferencias. Um dos metodos de-senvolvidos pelo padrao, o adaptative frequency hopping ja esta sendo adotado em novoschipsets Bluetooth;

• Task Group 3 (TG3): desenvolve o conceito da WPAN High Rate, que permite taxas detransmissao acima dos 20Mbps, mas provendo baixo custo e baixo consumo de energia,sendo voltado para as aplicacoes multimıdias de dispositivos portateis, como streammingde video, voz e imagens;

• Task Group 4 (TG4): este grupo e responsavel pelo desenvolvimento de WPAN Low Rate,com o foco voltado para aumentar o tempo de vida das baterias para meses ou anos, sendouma solucao mais simplificada. Este padrao define duas camadas fisicas, nas faixas de900Mhz, com taxas de 20kbps e a de 2.4Ghz, com taxas de 250kbps, ambas utilizando oDSSS. Sua aplicacao principal sao as redes de sensores e automacao.

4.3 Pilha de Protocolos

A especificacao do Bluetooth, versao 1.1, define uma pilha de protocolos que descreve ofuncionamento e as comunicacoes dos seus dispositivos, como pode ser visto na figura 4.1.Devido ao seu projeto ser inicialmente para a substituicao de cabos, alguns elementos da suapilha sao voltados para a emulacao do funcionamento destes, como por exemplo as definicoes daRFCOMM , que permite a emulacao de uma porta serial e a comunicacao de audio feita de ma-neira direta. Durante a sua criacao optou-se por reutilizar ao maximo os protocolos ja existentesnas camadas mais altas, provendo uma reutilizacao e adaptacao as aplicacoes ja existentes. E se-gundo este modelo que as aplicacoes devem ser desenvolvidas, mas sem necessariamente utilizartodas as camadas, executando algumas fatias verticais dessa pilha. No restante dessa secao seraodescritas as caracterısticas das camadas inferiores da pilha, responsaveis pelo seu funcionamentobasico e que sao implementadas nas interfaces Bluetooth.

4.3.1 Radio

O radio do Bluetooth opera na faixa de frequencia de 2.4 GHz, utilizando o FH com 79 canaisde 1 MHz, a partir de 2.402GHz ate o 2.480GHz. Em alguns paıses, como Franca e Japao, devidoas legislacoes locais, esse conjunto de canais e reduzido para 23. A taxa de saltos de frequenciae de 1600 hops/seg no modo conectado e 3200 hops/seg no modo de procura/sincronizacao.Esse esquema completo e chamado de Frequency Hoppping Code Division Multiple Access,FHCDMA.


No que se refere a potencia de transmissao e alcance, cada dispositivo e classificado dentrode tres classes de potencia, mostrados na Tabela 4.2.

Classe Potencia (dbm) Alcance (m)1 20 1002 4 103 0 0.1

Tabela 4.2: Classe de dispositivos Bluetooth. [1]

Um transmissor que seja capaz de efetuar o controle de potencia do sinal deve medir a suacapacidade de recepcao, atraves do RSSI. A partir disso, ele pode gerar comandos que controlema potencia do sinal, atraves da camada LMP. A precisao do RSSI prevista na especificacao e deaproximadamente ± 6dB.

Para a modulacao o radio utiliza o Gaussian Frequency Shift Keying (GFSK), onde os valoresbinarios sao representados por desvios positivos e negativos dos valores da frequencia, permi-tindo uma acuracia de 75kHz.

4.3.2 Baseband

A Baseband define o nucleo de comunicacoes do Bluetooth. Como descrito na secao 2.1.2, acamada de enlace usada em um sistema de FH e mais complexa, uma vez que as frequencias uti-lizadas necessitam de sincronizacao e controle para permitir o acesso e a Baseband e responsavelpor essa coordenacao, estabelecendo a conexao entre os elementos e definindo as regras de usodo canal.

A sequencia do FH e definida pelo endereco da interface de rede do mestre e pelo valor do seurelogio. Estes dois parametros sao utilizados numa funcao que gera a sequencia de frequenciasutilizadas, de maneira pseudo aleatoria. Como um dos focos da transmissao e a robustez, e feitoum espacamento entre as frequencias adjacentes, com o objetivo de minimizar o uso de possıveisfrequencias ruidosas.

Durante a comunicacao, e utilizado o Time Division Duplex (TDD), que possibilita o suportea comunicacao duplex. Para cada um dos canais e definido um slot temporal de 625 µS, nu-merado de acordo com o valor de relogio do mestre. Os pacotes enviados cobrem cada slot,de forma que o mestre e os escravos comunicam de maneira alternada. A figura 4.3 mostra acomunicacao entre um mestre e um escravo, onde o primeiro canal fk e usado pelo mestre parao envio do pacote, e o fk+1 e usado pelo escravo.


Figura 4.3: Pacote de um slot de 625 µS

Tambem sao previstos pacotes que ocupam mais de um slot de tempo. Neste caso, quandoestes pacotes sao transmitidos, nao acontece o salto para a proxima frequencia, sendo o canalalocado ate o final do ultimo slot e ao fim da transmissao, o canal e alterado para o que estavaprevisto. Este esquema permite que a vazao de comunicacao aumente, pois o tempo para efetuaro salto de frequencias e minimizado, mas em contrapartida as chances de perdas de pacotesaumenta, uma vez que o canal de frequencia no pacote multi-slot tem mais probabilidade desofrer interferencia. A figura 4.4 mostra a utilizacao de 1, 3 e 5 slots.

Figura 4.4: Exemplo de pacotes multi-slots. [1]

Canais Logicos

Durante a comunicacao do Bluetooth, sao definidos alguns tipos de canais logicos, para con-trole e transmissao de dados, sendo entre eles os mais importantes, um orientado a conexao o


Synchronous Connection Oriented (SCO), usado exclusivamente para comunicacao de voz e ou-tro orientado a pacote Asynchronous Connectionless (ACL), usado para transmissao de dados. Ocanal SCO e um canal ponto a ponto entre um mestre e um escravo, estabelecido pela reserva deslots duplex durante intervalos regulares. O canal ACL e um canal ponto a multiponto que e alo-cado dinamicamente de acordo com a demanda. A versao 1.2 da especificacao determina um tipode canal eSCO, que funciona como uma versao extendida do SCO, permitindo uma transmissaodos dados de voz de maneira mais eficiente.

Tipos de pacotes

O formato dos pacotes no Bluetooth seguem a seguinte estrutura mostrada na figura 4.5:

Figura 4.5: Estrutura do pacote. [1]

• Access Code: Os access code sao utilizados para a sincronizacao temporal e nos proces-sos de descoberta e sincronizacao. Exitem tres tipos: o Channel Access Code (CAC),responsavel por identificar uma unica piconet, o Device Access Code (DAC), usado noprocedimento de sincronizacao (paging) e suas respostas, e o Inquiry Access Code (IAC),utilizado durante a descoberta de novos dispositivos, no procedimento de Inquiry;

• Header: o cabecalho contem as informacoes de reconhecimento/aceitacao do pacote, anumeracao utilizada para a ordenacao, o controle de fluxo, o endereco do escravo e o crc;

• Payload: A carga contem as informacoes do usuario, como voz e/ou dados. No caso dosdados e dos tipo de pacote, ele tambem possui um cabecalho proprio.

Os tipos de pacotes numa piconet sao relacionados aos canais logicos, podendo ser utilizadosde acordo com as necessidades do trafego. A Tabela 4.3 mostra a utilizacao dos pacotes em cadatipo de canal.


Nome Numero de Slots Canal ACL Canal SCOID 1 - -NULL 1 X XPOLL 1 X XFHS 1 X XDM1 1 X XDH1 1 X -HV1 1 - XHV2 1 - XHV3 1 - XDV 1 - XDM3 3 X -DH3 3 X -DM5 5 X -DH5 5 X -

Tabela 4.3: Tipos de pacotes do Bluetooth

Estes pacotes podem ser agrupados em tres conjuntos:

• Controle: os pacotes que sao utilizados em todos os canais logicos sao: ID, FHS, NULL,POLL e DM1. O ID e o FHS sao utilizados durante os procedimentos de estabelecimentode conexao, e contem as informacoes necessarias as etapas de sincronizacao. Os pacotesNULL e POLL nao possuem payload e sao usados durante o modo conectado para os nosmanterem a sincronia do mestre com o escravo. Os pacotes do estilo DM1 sao usados paraas mensagens de controle e dados possuindo um bit indicador de sua natureza e prioridade;

• Dados: sao os pacotes usados no canal ACL, transmitidos de forma assincrona e contendoinformacoes de dados e controle. Sao os pacotes DM1, DH1, DM3, DH3, DM5 e DH5. Ospacotes DM sao os Data Medium Rate e contem um codigo de correcao 2/3 FEC. Os pacotesDH sao os Data High Rate e nao possuem o codigo FEC, permitindo a transmissao de maisdados. Os pacotes DM1 e DH1 usam um slot, os DH3 e DM3 usam tres slots, e os DM5 eDH5 usam 5 slots. A vazao maxima, de 752kbps, e alcancada quando utiliza o pacote DH5.

• Audio: os pacotes HV e DV sao utilizados para o transporte sıncrono de dados do canalSCO, normalmente para uma velocidade de 64kbps para a transmissao de voz. Os pacotesHV contem apenas audio, nao possuem CRC e nunca sao retransmitidos, sendo divididosem tres subtipos, o HV1, com 10 bytes de informacao, HV2, com 20 bytes e HV3, com 30bytes. O pacote DV contem voz e dados em campos separados e a parte de dados contemum CRC, podendo ser retransmitida.


Na Tabela 4.4 e mostrado o tamanho pacotes, a sua utilizacao dos slots e a prioridade detransmissao define o uso da banda passante. Os payloads dos pacotes de dados variam de zeroate o tamanho maximo de cada tipo. Como citado anteriormente, os pacotes de maior uso deslots propiciam as melhores taxas, mas sao mais sensıveis a falhas e ruıdos.

Nome Payload (bytes) FEC Taxa max. Simetrica (kbps) Taxa max. Assimetrica (kbps)ID na na na naNULL na na na naPOLL na na na naFHS 18 2/3 na naDM1 0-17 2/3 108.8 108.8DH1 0-27 - 172.8 172.8DM3 0-121 2/3 258.1 387.2DH3 0-183 - 390.4 585.6DM5 0-224 2/3 286.7 477.8DH5 0-339 - 433.9 723.2HV1 10 1/3 64.0 -HV2 20 2/3 64.0 -HV3 30 - 64.0 -DV 10+(0-9) 2/3 64.0+56.0(dados) -

Tabela 4.4: Velocidade e capacidade dos pacotes do Bluetooth

Estabelecimento da Conexao

Como os dispositivos da rede Bluetooth assumem regras distintas, um mestre e os outrosescravos, o estabelecimento de conexao deve envolver etapas de reconhecimento e sincronizacao,descritos na figura 4.6:


Figura 4.6: Maquina de Estados da Baseband

Todos os estados que envolvem os processos de Inquiry, Page e Connection podem voltar aoestado de Standby, onde nao ocorre comunicacao efetiva. Estas transicoes possibilitam a unidadeuma flexibilidade de estabelecer conexao com uma piconet, e tentar encontrar e sincronizar comoutras unidades na regiao.

• Standby: neste estado a unidade nao esta comunicando efetivamente com nenhuma pico-net, e nenhum no;

• Inquiry: o procedimento de inquiry habilita um dispositivo a descobrir quais outros estaoa seu alcance, descobrindo seus enderecos e informacoes adicionais, como o clock e onumero identificador do dispositivo. E dividido nos estados Inquiry, executado pelo mes-tre, e Inquiry Scan, Inquiry Response pelo escravo;

• Page: no procedimento de paging, apenas o endereco do dispositivo Bluetooth e requeridopara fazer a conexao. As informacoes sobre o clock aceleram o processo de iniciacao. Nopaging os nos mestre e escravo passam pelos estados Page e PageScan respecitvamente.Apos a primeira identificacao, eles vao para os estados Master Response e Slave Response;

• Connection: estado onde ocorre a troca de informacoes das aplicacoes envolvidas. Nesteestado o frequency hopping acontece sobre 73 canais, a uma velocidade de 1600 saltos


por segundo, e a sequencia e pseudo-aleatoria, gerada a partir do numero identificador domestre da piconet.

Inicialmente todos os nos usam um conjunto fixo de frequencias para comunicacao, sendoas sequencias determinadas pelo seu clock local. No sistema que trabalha com 79 frequencias,este conjunto possui 32. Um no, que se encontra no estado inquiry, faz o broadcast de pacotes deinquiry e a cada transmissao, espera por respostas no slot de recepcao. Para que elas ocorram, nasimediacoes devem existir nos que se encontrem no estado inquiry scan e respondam o inquiry.Eles tambem usam o mesmo conjunto de frequencias, mas com a sequencia tambem definida peloseu clock local. Dessa forma, ate que aconteca a recepcao do pacote, surge uma fase de incerteza,que dura ate que as frequencias se coincidam. Para minimizar este problema os nos fazem o hopde frequencia em diferentes velocidades, onde o no em inquiry scan usa uma taxa de variacaode frequencias menor, 1600 hops/s e o em inquiry, que esta a 3200 hops/s. O no mestre sai doinquiry caso o tempo de procura, TinquiryTO, esgote ou obtenha um numero de respostas desejado.O que se encontra no inquiry scan sai deste estado quando a janela de tempo de inquiry scan,Twinqscan termina, ou recebe uma mensagem de inquiry. A figura 4.6 mostra a maquina de estadosusada para o processo de estabelecimento de conexao.

Com isso surge um atraso no estabelecimento de conexao, pois apos receber uma mensagem,o escravo espera durante um tempo aleatorio, evitando o problema de colisoes. Apos este in-tervalo muda para o estado inquiry response, e espera por outra mensagem do mestre. Caso elachegue antes do perıodo de timeout, ele envia um pacote contendo um identificador de inquiry,chamado de Inquiry Access Code (IAC) e o valor de seu clock. Do contrario, ele volta para ostandby.

Ao receber a resposta, o no que se encontra em inquiry muda para o estado page, enquanto osque se encontravam em inquiry scan mudam para page scan. Nesses estados os nos estabelecema sincronizacao. Utilizando a informacao do clock, os nos tentam estimar qual e a fase do outrono. Caso esse procedimento ocorra imediatamente apos o inquiry, a sincronizacao e imediata.Do contrario, ela so ocorrer apos um atraso ate que seja estimada qual a frequencia do no que seencontra em page/page scan.

Os principais tempos usados nos estabelecimentos de conexao sao descritos na tabela 4.5


Parametro DescricaoTinquiryTO N. maximo de slots que o estado inquiry esperaTinquiryscan Tempo de intervalo entre os estados de inquiry scanTwinqscan N. maximo de slots que o estado inquiry scan pode esperarTinqrespTO N. maximo de slots que o inquiry scan pode perder, apos o Random BackoffTpageTO N. maximo de slots que o estado page pode esperarTpagescan Tempo entre o comeco de dois page scans consecutivosTwpagescan N. maximo de slots que o page scan esperaTpagerespTO N. de slots em espera pelo pacote FHS, no estado slave responseTholdTO Tempo em que o escravo pode ficar no modo Hold

Tabela 4.5: Tempos usados no estabelecimento de conexao

De acordo com [50], o atraso existente no processo de inquiry entre dois nos pode ser apro-ximado por:

Atraso = 2SF + RB

• Sincronizacao da frequencia, SF, tempo necessario para que os nos estejam trabalhandosobre a mesma frequencia

• Random Backoff, RB, tempo de espera para o envio da resposta

onde RB e uma variavel aleatoria distribuıda em [0, rmax], e rmax assume um valor de 1024 slotsde tempo, aproximadamente 639 ms. SF tambem e uma variavel aleatoria distribuıda em [0, T ],onde T, segundo [50], no sistema de 32 frequencias, assume valores em torno de 20 ms. Dessaforma, em um ambiente sem interferencias e erros, este atraso poderia assumir no maximo 659ms.

Se, logo apos a descoberta, os dois nos passam para os estados de page e page scan a conexaopode ser estabelecida quase imediatamente. Mas, caso nao ocorra, o atraso existente no pagingtambem sera somado.

O procedimento de paging e semelhante ao de inquiry, com a diferenca de em vez de efetuar obroadcast dos pacotes para todos os nos, ele os envia diretamente ao futuro escravo. Ele tambemtrabalha sobre o mesmo conjunto de frequencias, mas usa os valores do clock e do identificadordo escravo, para aumentar as chances de sincronizacao.

Sao apresentados em [51] alguns problemas com relacao aos valores de temporizacao nosestados de inquiry e page, definidos na especificacao. Se o TinquiryTO, definido em 1,28 s, ocorra


antes que o escravo comece o inquiry scan, de 2,56 s, eles nao irao se sobrepor. Caso TinquiryTO

seja no mınimo de 2,56 s, isto nao ocorre. Outro e que pode ocorrer um timeout no page antesdo escravo iniciar o page scan. Para evitar isso, o TpageTO deve ser maior do que o tempo de pagescan.

Se ainda houver algum escravo pendente para entrar no paging, o mestre nao inicializa acomunicacao efetiva com este no e volta para o processo de paging para estabelecer comunicacaocom os outros. Se nao houver sucesso na localizacao, ele volta ao modo ativo e passa o controleda conexao para as camadas superiores.

Estados da conexao

Quando um dispositivo Bluetooth se encontra no estado connection, ele e capaz de efetuaro gerenciamento dos canais de comunicacao que esta utilizando. O modo Active estabelece ouso completo do canal, no Sniff apenas o mestre manda mensagens para o escravo em temposregulares, enquanto estes funcionam em modo de baixa energia, e no Park o escravo retira-seda piconet, mas ainda mantem sincronizado e pode retornar caso existam canais liberados. Nomodo Hold, o escravo ainda e um membro ativo da piconet, mas nao estabelce nenhum tipo decomunicacao.

Como o modo Hold permite com que o escravo se desligue da piconet original, sem perderas informacoes do mestre desta, ele e usado no momento que o escravo for efetuar a conexaocom outras piconets, pois pode voltar a conectar ativamente com a piconet original, formando ascatternet.

Consumo de energia no Bluetooth

O estado default do Bluetooth e o standby, onde parte dos componentes internos, exceto orelogio interno, esta desligada. Os modos de economia de energia apresentam um trade-off entreo consumo de energia e o tempo de resposta dos elementos. Como esses modos sempre saonegociados com o mestre, eles sao aplicaveis quando a aplicacao le/recebe dados de maneiraperiodica. Caso a geracao de dados seja espontanea, os nos Bluetooth devem sempre manter acomunicacao ativa.

O primeiro estudo feito sobre o Bluetooth para avaliar seu uso em redes de sensores foidesenvolvido no projeto SmartIts [3]. Nesse projeto, foi criado um dispositivo dotado de sensorese um processador acoplados a um modulo de comunicacoes Bluetooth da Ericsson. Essa solucaoe fechada, e implementa toda a pilha, com funcionalidades mais basicas, como a formacao depiconets, mas sem ter o gerenciamento de energia e a formacao de scatternets.


O consumo de energia dos dispositivos Bluetooth da Ericsson pode ser visto na tabela 4.6.

Estado Potencia (mW)Standby 20

Inquiry Scan 100Inquiry 160

Modo ativo transmitindo 86Modo ativo recebendo 86

Tabela 4.6: Consumo de energia do Bluetooth, medidas do chipset da Ericsson, R0K 101 007.[3]

O procedimento de inquiry e caro, em questao de consumo de energia, por utilizar um enviode pacotes mais intenso e devido ao grande delay durante o processo de sincronizacao, por causado frequency hopping e diferencas no relogio dos elementos envolvidos.

Seguranca

A seguranca no Bluetooth e consideravelmente robusta, caso comparada com a oferecidapelo Wi-Fi. Com a taxa de FH a 1600 saltos por segundo, o uso de sniffers para capturar pacotesdo canal de comunicacao e dificil, sendo considerado praticamente seguro contra o uso de taltecnica. E mesmo se o hardware envolvido for capaz de efetuar a captura dos pacotes em temporeal, o Bluetooth oferece servicos de autenticacao e autorizacao atraves de troca de chave denumeros identificadores e uso de chaves de criptografias de 128 bits. Apesar do valor da chavenao ser muito grande, os dispositivos podem troca-lo durante a sessao de comunicacao. NaBaseband tambem e possıvel configurar os dispositivos de maneira que a descoberta e a conexaoentre eles pode ser desabilitada. A conexao pode ser feita de maneira seletiva, atraves da escolhada classe do dispositivo que esta comunicando, e os servicos podem ser habilitados apenas paradeterminado tipo de dispositivo.

Scatternets

Um dos tipos de conexoes previstos no Bluetooth, e a conexao interpiconet, denominadascatternet. A scatternet pode prover conectividade entre os dispositivos ao longo de distanciasainda maiores que o alcance dos radios. Devido ao fato de o Bluetooth mesclar o TDD como FHCDMA, a comunicacao interpiconet tras diversas peculiariedades como a necessidade desincronizacao e descobrimento entre as piconets vizinhas. A comunicacao interpiconets e feitautilizando-se os modos de economia de energia, onde os elementos que pertencem a mais deuma piconet negociam os intervalos de conexao ativa entre elas. Apesar de serem previstas na


especificacao, esta nao define nenhum metodo de organizacao ou formacao das scatternets, sendouma area de pesquisa em aberto.

A formacao das scatternets pode ser caracterizada de duas formas: (i) como um evento con-trolado, onde uma aplicacao, utilizando funcionalidades de diversas piconets conhecidas, criauma scatternet para fazer acesso a elas, ou (ii) de maneira ad hoc, onde algum tipo de servicoe requerido e nao se encontra em nenhuma piconet conhecida. O ultimo caso requer duas fun-cionalidades: a roteacao, onde os nos possuem a capacidade de encaminhamento de pacotesentre diferentes piconets e a descoberta de servicos, onde e necessario verificar as capacidades efuncionalidades dos nos comunicaveis entre as diferentes piconets.

Um dos pontos principais na formacao das scatternets sao as topologias, uma vez que osdispositivos passam por procedimentos de descoberta e formacao de enlaces ponto-a-ponto demaneira explıcita. E a sincronizacao entre esses elementos e necessaria para o controle do usoda banda passante.

4.3.3 Link Manager Protocol - LMP

O Link Manager Protocol, (LMP) e usado para controlar e negociar todos os aspectos daoperacao de conexao entre dois elementos no Bluetooth. Isto inclui a inicializacao e o controledos canais logicos e fısicos e se aplicam apenas ao mestre e escravo que estao se comunicandodiretamente. Em cada dispositivo existe um modulo denominado Link Manager, LM que utilizaas mensagens e regras definidas no LMP. O LM recebe todas essas mensagens e as trata direta-mente, sem propagar para outras camadas. Os pacotes do LMP trafegam sobre o canal ACL, epara a maior eficiencia, e por serem pacotes de controle, eles possuem uma prioridade maior doque os outros da Baseband.

Atraves da LMP, as camadas superiores coordenam as funcionalidades da Baseband. Osconjuntos de funcoes da LMP sao as seguintes:

• Propriedades dos dispositivos: descrevem as funcionalidades da especificacao que a in-terface Bluetooth implementa, como suporte ao canal logico SCO, capacidade de efetuaro RSSI, tipos de pacotes suportados, capacidades de transmissao multi-slot, controle depotencia de transmissao, suporte aos modos de economia de energia;

• Controle da Conexao: coordena a conexao entre as unidades, efetuando diversasoperacoes sobre esta, como: a criacao, que ocorre apos o processo de paging, afinalizacao, o controle da potencia de transmissao das unidades envolvidas, a supervisao dacomunicacao, que detecta falhas na comunicacao devido a distanciamento entre as unida-des, capacidade de ajuste do tipo de pacote a qualidade do canal de transmissao e suportea QoS;


• Seguranca: descreve as funcoes de controle de seguranca da unidade: autenticacao, crip-tografia, controle de chave por canal, pairing das chaves;

• Informacoes Remotas: suporte a troca de informacoes das propriedades dos dispositivos;

4.3.4 Host Controller Interface - HCI

O Host Controller Interface, HCI, cria uma interface de comandos para a Baseband e oLM, possibilitando o acesso ao status do hardware e registros de controle. Essencialmente essainterface prove um metodo uniforme de acesso as funcionalidades da Baseband e da LM, deforma a deixar seu acesso transparente para os drivers e aplicacoes que a estejam acessando. Atabela 4.7 mostra alguns dos comandos interpretados pelo HCI.

Comando DescricaoHCI reset Reinicia o dispositivos

HCI create connection Cria uma conexao ACLHCI read BD ADDR Le o endereco do dispositivoHCI disconnect Desconecta o canalHCI inquiry Efetua o InquiryHCI HoldMode Entra em modo Hold

Tabela 4.7: Alguns comandos do HCI

A implementacao do HCI se encontrar em tres partes da unidade Bluetooth: no firmware,onde acessa as funcoes da Baseband e do LMP, alem dos registros de eventos e controle, nodriver de acesso, implementado no driver do dispositivo e responsavel por notificar a aplicacao sealgum evento relacionado as camadas inferiores acontece, e por fim o Host Controller TransportLayer, responsavel pela comunicacao entre os dois. Este ultimo e necessario, uma vez queentre o hardware da interface Bluetooth e seu driver podem existir outras interfaces, como USB,PCMCIA e UART. Essa propriedade foi considerada, uma vez que os dispositivos Bluetoothpodem utilizar dessas interfaces para serem conectados em quaisquer tipos de maquinas. Afigura 4.7 mostra como e estruturada a implementacao do HCI nos dispositivos.


Figura 4.7: Esquema do funcionamento do HCI

4.3.5 Logical Link Control and Adaptation Protocol - L2CAP

O Logical Link Control and Adaptation Protocol, L2CAP, e responsavel por controlar osfluxo de dados das camadas superiores, provendo servicos orientados a conexao e a pacotes. Eleutiliza apenas os canais logicos ACL, sobre os quais cria seus proprios canais para a transmissao,suportando capacidades de multiplexacao, segmentacao e remontagem dos dados que trafegam.O L2CAP nao possui suporte para os canais SCO.

O L2CAP cria uma interface entre a camada da Baseband e os outros protocolos decomunicacao, como o Bluetooth Service Discovery Protocol (SDP), RFCOMM e o TelephonyControl (TCS), permite que esses possam transmitir massas de dados acima de 64kb, e habilitaum controle de fluxo e retransmissao de dados por cada canal de dados criado. Ele tambempermite um nıvel de seguranca, onde os dados oriundos de outras fontes nao identificadas saodescartadas, impedindo ataques de interceptacao e mudanca dos dados.


4.3.6 Service Discovery Protocol - SDP

As etapas envolvidas no descobrimento de servicos no Bluetooth, onde o conjunto de servicossao disponıveis de acordo a proximidade e mobilidade dos dispositivos, sao diferentes do desco-brimento de servicos usados nos ambientes de redes tradicionais. O Service Discovery Protocol(SDP) atende o descobrimento de servicos voltado especıficamente para o ambiente de funcio-namento do Bluetooth, sendo otimizado para a natureza de comunicacao dinamica. O SDP focana descoberta dos servicos disponıveis nos dispositivos Bluetooth, e informando quais as carac-terısticas disponıveis nestes servicos. Mas nao define nenhum metodo de acesso, sendo que, umavez descobertos, eles podem ser acessados de maneira dependente do tipo de servico, incluindoo uso de outros tipos de descoberta de servico.

4.4 Perfis de Funcionamento

Desde seu projeto inicial, o Bluetooth foi criado para atender um certo numero de dispositi-vos diferenciados por suas capacidades computacional e de armazenamento, consumo de energiae funcionalidades oferecidas. Dessa forma, ele pode ser configurado para ter um perfil de fun-cionamento se estiver sendo considerado uma comunicacao de audio em um fone de ouvido eum outro se estiver efetuando troca de arquivos entre um PDA e um notebook. Cada um dessesperfis descreve a maneira que os elementos da pilha do Bluetooth devem funcionar, a quantidadede memoria alocada e a coordenacao dos canais de comunicacao.

Esses perfis de funcionamento podem estar implementados tanto nas aplicacoes, quanto nosistema operacional, deixando o Bluetooth como uma interface de acesso aos perifericos des-ses. As aplicacoes envolvidas diretamente com o Bluetooth devem trabalhar com esses perfis defuncionamento, caracterizando os dispositivos envolvidos e as suas capacidades de transmissao.

O principal perfil de funcionamento e o Generic Access Profile, GAP, responsavel pelas re-gras do estabelecimento de conexao entre dois elementos. A partir dele, os outros perfis tem asua base de funcionamento, como por exemplo o perfil de acesso a comunicacao serial, SerialPort Profile, SPP, que apos estabelecida a conexao, inicia o emulador de comunicacao RS-232,o RFCOMM e cria uma porta serial sobre a comunicacao Bluetooth. Caso for iniciado o perfilde comunicacao a acesso discado, o Dial-Up Networking Profile, DUN, ele utiliza a conexaoestabelecida pelo SPP e inicializa um servico de conexao a Internet. A figura 4.8 mostra todosos perfis previstos na especificacao. Como alguns dispositivos Bluetooth nao atendem a todos osperfis descritos, como os fones de ouvido, a implementacao do hardware dessas interfaces naoprecisa conter todos os elementos da pilha, no que se refere as camadas superiores, diminuindoassim ainda mais o tamanho e consumo de energia dessas interfaces.


Figura 4.8: Perfis de Funcionamento do Bluetooth. [1]

4.5 Bluetooth no Linux

Muitas implementacoes de interfaces Bluetooth para o uso e desenvolvimento estao dis-ponıveis no mercado, mas muitas delas sao solucoes fechadas e de alto custo. Por ser umatecnologia muito recente, alguns dos problemas dessas implementacoes e nao estarem integra-das a muitos produtos, onde os softwares de diversas empresas nao reconhecem hardwares deoutras empresas. Nesse caso, as solucoes de software de codigo aberto sao mais eficientes, poispermitem um desenvolvimento comum das diferentes tecnologias, e a GPL permite o desenvol-vimento de novas aplicacoes de maneira livre. Atualmente existem quatro projetos de codigoaberto de desenvolvimento de pilhas Bluetooth para o Linux. Estes projetos sao paralelos, apesarde diversas funcionalidades sao reaproveitadas entre alguns:

• The AXIS OpenBT Bluetooth

• IBM BlueDrekar Bluetooth

• BlueZ Bluetooth[52]

• Affix Bluetooth Protocol Stack for Linux[2]

A seguir, e feita uma breve descricao de cada um, e as definicoes da escolha de qual foiutilizado neste trabalho.


The AXIS OpenBT Bluetooth

Esta pilha do procotolo Bluetooth foi a primeira a aderir ao software de codigo aberto. Foioriginalmente desenvolvida pela empresa AXIS Communications, sendo desenvolvida para aten-der aos produtos de hardware desenvolvidos pela empresa, como pontos de acesso e interfacespara acesso a perifericos. Dentre suas caracterısticas estao:

• suporte a versao 1.0b da especificacao;

• suporte basico ao L2CAP, SDP e RFCOMM;

• suporte aos perfis de porta serial e acesso discado;

• sem suporte para o canal SCO

Apesar de ser a primeira de todas, e a menos robusta, com diversos problemas deprogramacao e esta com seu desenvolvimento interrompido desde 2001.

IBM BlueDrekar Bluetooth

Esta pilha do protocolo foi desenvolvida pela IBM, com o proposito original de criar umaimplementacao de referencia para diversos outros dispositivos Bluetooth. Ela possui suporte paraa versao 1.1 da especificacao, mas trabalha somente com os modulos Bluetooth que utilizam acomunicacao UART. Em abril de 2002, seu desenvolvimento foi interrompido pela IBM.

BlueZ Bluetooth Stack

O BlueZ [52] e a pilha oficial do Linux, sendo incluıda no Kernel do Linux. Originalmentedesenvolvida pela Qualcomm, ela faz parte do kernel oficial desde a versao 2.4. Ela e compostade diversos modulos que permitem um funcionamento flexivel. Algumas de suas principaiscaracterısticas:

• suporte a todas as camadas do protocolo Bluetooth;

• implementacao flexıvel e modular;

• suporte a diversos tipos de dispositivos Bluetooth;


• suporte para o L2CAP, SCO, RFCOMM e SDP;

• suporte a diversos perfis de funcionamento: GAP, DUN, LAN, PAN e Head-Set.

• possui um emulador de dispositivo, sobre o HCI, um modulode deteccao de funcionamentoe teste;

Por ser considerada a pilha oficial, o seu desenvolvimento e bem ativo, com desenvolvedoresatuando, sendo uma das que mais evolui.

Em seu projeto, esta pilha trata a interface Bluetooth como um dispositivo periferico, comoum USB sem fio, onde as comunicacoes com as aplicacoes e feita atraves desse acesso aos dispo-sitivos perfifericos do sistema operacional. Ela fornece um conjunto de ferramentas e bibliotecasque possibilitam o acesso total a interface Bluetooth, permitindo sua configuracao e ajuste.

Affix Bluetooth Protocol Stack for Linux

O Affix [2] foi inicialmente desenvolvido pelo centro de pesquisa da Nokia, e atende a diver-sos tipos de dispositivos Bluetooth, possuindo diversas caracterısticas semelhantes ao BlueZ. Suaprincipal diferenca e o projeto considerar que a interface Bluetooth e um dispositivo de acesso arede, ao inves de um acesso a perifericos. Dessa maneira, sua arquitetura prove um as funciona-lidades de comunicacao semelhantes a de outras interfaces de redes, como o uso de sockets paraas diversas camadas de comunicacao, e ferramentas de controle e analise de interfaces de redes,como o Ethereal [53]. A sua documentacao e bem detalhada, facilitando consideravelmente seuuso. O seu desenvolvimento ocorre de maneira ativa, mas com menos desenvolvedores envolvi-dos, como no caso do BlueZ. A sua instalacao pode entrar em conflito com as funcionalidadesdo BlueZ, sendo necessario desativa-lo para que o Affix funcione corretamente.

Algumas das suas principais caracterısticas sao:

• suporte a todas as funcionalidades das camadas HCI, L2CAP, RFCOMM, SDP;

• suporte ao canal SCO;

• interface de Socket para a L2CAP, RFCOMM e o canal SCO;

• independente de plataforma: i386,ARM, PowerPC, Sparc;

• independente do hardware do modulo Bluetooth, possibilitando seu uso em interfacesUART, USB, PCI e PCMCIA.


Devido as essas caracterısticas, e principalmente, pela sua arquitetura considerar a interfaceBluetooth como um dispositivo de rede, o Affix foi escolhido como plataforma base neste tra-balho. O uso desse suporte permite o desenvolvimento de aplicacoes que desejam utilizar oBluetooth como interface de rede, sem tanta transparencia, como a oferecida no BlueZ. O uso dosuporte de rede do Affix facilita parte do desenvolvimento da API, possibilitando diversos tiposde testes e comunicacoes com as interfaces.

Mas como desenvolvimento da API nao utiliza todas as funcionalidades especıficas do Affix,trabalhando diretamente na sua interface do HCI, sendo assim tambem portavel, com algumasmodificacoes, para a pilha oficial do Linux, o BlueZ.

4.6 Kits Bluetooth

Neste trabalho foram utilizados alguns dispositivos de diferentes fabricantes e chipsets. En-tre estes dispositivos, dois deles sao produtos comerciais, um ponto de acesso Bluetooth parauma rede do tipo LAN, da WidComm, e uma interface Bluetooth-USB da TDK, que permiteconectar a interface Bluetooth numa porta USB de um PC, e os outros sao partes integrantes dokit de desenvolvimento da Ericsson, o Ericsson Bluetooth Application Toolkit. Este kit e cons-tituıdo de quatro elementos Bluetooth, que possuem interfaces de comunicacao USB e UART.Eles utilizam os chipsets R0K 101 007 [54], que implementa a versao 1.1 da especificacao, ee capaz de comunicacoes com ate quatro elementos, e o ROK 101 008 [55], que por sua vezimplementa a versao 1.0b da especificacao, e com capacidade de comunicacao com apenas umelemento. Este ultimo modulo nao contempla toda a especificacao, versao 1.0b, possuindo ape-nas as funcionalidades basicas da especificacao [56]. A interface Bluetooth-USB e o ponto deacesso utilizam o chipset BlueCore, da CSR [57], que implementa a versao 1.1, com diversasfuncionalidades, apesar de permitir apenas uma conexao por vez.

Os kits de desenvolvimento comerciais possuem modulos de software para o uso no Win-dows, mas grande parte do seu codigo e fechado, sendo voltados para o desenvolvimento deaplicacoes mais alto nıvel. Dessa maneira, todos os elementos Bluetooth trabalharam com apilha do Affix, que consegue acessar todas as funcionalidades dos chipsets utilizados.

4.6.1 Interface de programacao para o Bluetooth

O desenvolvimento da API sobre o Bluetooth utiliza as funcionalidades basicas implemen-tadas pelo Affix. Este e responsavel por identificar o dispositivo na sua interface com o sistema(USB, UART, PCMCIA) e carregar os drivers respectivos do HCI e as camadas de acesso. Afigura 4.9 mostra o funcionamento dos modulos da pilha Affix.


Atraves destas camadas, a API acessa as funcoes do driver HCI, como as bibliotecas que seencontram no espaco do usuario que acessam a HCI Socket Interface, de maneira que possibilitao acesso a essas informacoes no espaco do usuario, possibilitando a programacao e os acessos ainterface Bluetooth.

Figura 4.9: Blocos de acesso do Affix. [2]

A comunicacao com o driver Bluetooth e feita de maneira semelhante a do Wi-Fi, descrita nasecao 3.7.1, atraves do uso das funcao ioctl e as constantes que definem as funcoes da HCI.Como cada funcao utiliza um conjunto de parametros, estes sao agrupados de acordo com as ca-racterısticas destas, como por exemplo a funcao HCI Inquiry, que recebe como parametros otempo maximo de inquiry e uma lista que sera preenchida com os enderecos das unidades encon-tradas na regiao. As informacoes do contexto da rede, descritas na secao 2.3.1, sao feitas a partirde um conjunto de funcoes que possibilitam a coleta de informacoes do canal de comunicacoes,as quais sao:


• Leitura do nıvel da potencia de transmissao, (HCI ReadTransmitPowerLevel): re-torna a potencia de transmissao entre os dois elementos comunicantes;

• Qualidade do canal de comunicacao, (HCI ReadQualityInfo): este comando retornaa qualidade do canal entre o modulo local e o dispositivo remoto, sendo este valor entre 0 e255. O calculo desta metrica e especıfica do fabricante do hardware, podendo ser baseadana vazao dos dados, na taxa;

• Nıvel de RSSI, (HCI ReadRSSI): o Bluetooth trabalha com um conceito de regiao dealcance, onde, se os elementos se encontram numa regiao definida com Golden Range, afuncao de medida do RSSI retorna 0. Se estiver fora desse alcance, ela retorna valoresentre -1 e -127, e se estiver muito proximo da estacao emissora, ou acontecer algum tipode sobrecarga na recepcao, ela retorna valores entre 1 e 128. Dessa maneira, nesse tipo deinterface, e possıvel determinar as regioes de mobilidade. A figura 4.10 mostra os valores,em dB da regiao do Golden Range.

Figura 4.10: Golden Range do receptor Bluetooth. [1]

Capıtulo 5

Implementacao

Este capıtulo descreve a implementacao da API proposta no trabalho. A secao 5.1 descreve aarquitetura projetada, a secao 5.2 discute as questoes de gerenciamento com a API e a secao 5.3apresenta a implementacao da API.

5.1 Arquitetura da API

As principais operacoes sobre essas interfaces podem ser agrupadas em funcoes de leiturasdo desempenho e de ajuste da configuracao. Entretanto, e necessario o uso de funcoes auxiliares,pois as especificacoes das interfaces da WPANs e WLANs determinam diversas funcionalidadesde controle e gerencia, cuja implementacao pode ser opcional e nem sempre sao adotadas pelosfabricantes. Sendo assim foi definido um conjunto de funcoes que descreve as caraterısticas daimplementacao da interface utilizada.

Sobre as informacoes do contexto da rede foram criados mais dois grupos de funcoes: as quemedem os parametros e estatısticas locais e as que avaliam a qualidade do canal. As funcoes doprimeiro grupo sao relativas ao funcionamento da interface local, e passıveis de reconfiguracao,onde os seus valores influenciam em fatores como vazao dos dados e numeros de retransmissoes.O segundo grupo avalia o comportamento dos nos vizinhos, verificando a qualidade das conexoesatraves das medidas do RSSI e do nıvel de ruıdo do sinal, fornecidos pelo modem de radio, sendopossıvel estabelecer o nıvel de conectividade e mobilidade.

Para a gerencia das informacoes, foram definidas funcoes que criam arquivos no padraoXML, a partir das estruturas de dados criadas para a manipulacao das interfaces. Dessa ma-neira, as funcoes foram agrupadas em blocos, de acordo com as suas definicoes. A Figura 5.1

65

CAPITULO 5. IMPLEMENTACAO 66

mostra a divisao desses blocos da API.

Figura 5.1: Arquitetura Funcional da API

• Informacoes do Dispositivo: identifica as operacoes existentes nos drivers das interfa-ces e as funcionalidades implementadas nestas. Nas interfaces Wi-Fi, identifica quaisas caracterısticas de controle sao acessıveis, a versao e o fabricante do chipset e quaisparametros podem ser configurados. Nas interfaces Bluetooth, informa o fabricante, aversao da especificacao utilizada, quais as operacoes HCI sao acessiveis e as configuracoesdo radio modem;

• Configuracao: este bloco acessa todas as configuracoes da interface, desde as que permi-tem seu funcionamento basico, ate o ajuste de parametros para otimizar o desempenho.Tanto no Wi-Fi quanto no Bluetooth sao informacoes de ajuste dos temporizadores uti-lizados, dos pacotes e das medidas de potencia de sinal transmitido e a sensibilidade dainterface;

• Contexto de Rede: este bloco de funcoes acessa os dados referentes ao contexto decomunicacao da rede, sendo o ponto de partida para a inferencia do comportamento dodispositivo na rede. Ele foi divido em dois subblocos:

– Qualidade do Canal: coleta as medidas da qualidades dos canais de comunicacao,atraves de amostragens temporais das medidas do RSSI, do nıvel de qualidade docanal e da potencia de transmissao da interface. A partir desses valores e possiveldeterminar o nıvel de conectividade e mobilidade do dispositivo, e num conjunto deamostragens temporais desses valores criar um historico desses parametros. Por meiodisso, e possıvel estipular um determinado comportamento da qualidade da conexao,uma vez que a analise desse historico e baseada em estudos estatısticos de primeira


ordem, como o calculo da media e da variancia dos dados, aproximando-se assimuma descricao da distribuicao desses dados. No Wi-Fi, essas medidas sao relativas aqualidade do canal, e os nıves de RSSI, enquanto que no Bluetooth, as medidas saoassociadas as regioes em que o dispositivo se encontra, como descrito na secao 4.6.1.E as funcoes para o estudo dos dados sao as mesmas para as duas interfaces;

– Estatısticas Locais: efetua as medidas do uso da interface durante a comunicacao,como por exemplo, a quantidade de pacotes retransmitidos e os erros de transmissaoe recepcao. No Bluetooth sao as medidas do canal ACL e no Wi-Fi sao associadosaos quadros;

• Interface XML: O bloco XML e responsavel por coletar as informacoes geradas pelosoutros blocos, e criar uma base de informacoes de acordo com os DTDs pre-determinados.

5.2 Gerenciamento

Um sistema que faca uma gerencia eficiente para estes dois tipos de redes deve ter acessoas informacoes de todos os recursos presentes nas duas interfaces. Em uma WLAN com acessoinfra-estruturado, dados como, capacidades de transmissao e nıveis de seguranca, somados com aconfiguracao de alguns parametros que afetem o desempenho das unidades moveis, possibilitamque sistemas de gerencia possam coordenar o acesso e configurar as estacoes de maneira maiseficiente. Outras informacoes, relativas ao contexto da rede, como a qualidade da comunicacaoentre os elementos, tambem habilitam que o sistema de gerencia atue de maneira pro-ativa, de-tectando problemas relativos a interferencias e mobilidade dos elementos.

No caso do Bluetooth, alem dos pontos comuns as WLANs, o descobrimento de servicos nasunidades pode ser efetuado de maneira centralizada por meio da descoberta seletiva de diferentesclasses de dispositivos, ou mesmo no trafego das informacoes do Service Discovery Protocol(SDP) utilizado pelas unidades para se informarem de quais servicos estao disponıveis. O sistemade gerencia efetua o trafego desses dados, informando a outras unidades a localizacao destesservico e permitindo sua utilizacao. Assim, e possıvel determinar quais as unidades com melhorcapacidade de comunicacao, inclusive a sua localizacao.

O gerenciamento integrado destas duas tecnologias permite a ambas trabalharem de ma-neira complementar, uma vez que abrangem cenarios diferentes. Um dispositivo que possui asduas interfaces, pode dar preferencia pela economia de energia atraves do acesso as interfacesWPANs, enquanto outros podem utilizar a velocidade da WLAN para efetuar a localizacao deoutros elementos numa regiao de maior alcance. Outro fator importante e a simplificacao daimplementacao atraves de um sistema de gerencia unico capaz de trabalhar com as diferentesinterfaces.


O uso do XML como metodo para a manipulacao da informacao em ambientes moveis e deextrema importancia, pois e possıvel um mapeamento das funcionalidades de maneira flexıvel,onde os recursos e servicos disponıveis podem ser descritos de maneira independente da tecno-logia. O XML permite a definicao de tags e uma estruturacao das informacoes contidas neles,permitindo um acesso estruturado a essas. O Resource Discovery Framework, RDF [58], e umadescricao de uma terminologia, que usada em conjuncao com o XML, permite uma descricao euso de servicos e recursos das unidades. Assim e possıvel que interfaces remotas possam ter con-trole da natureza dos dispositivos na rede, como suas configuracoes e a qualidade da comunicacaode cada interface vizinha.

5.3 Implementacao

Nesta secao serao descritos os detalhes da implementacao, as principais estrutura de dados eas funcoes criadas para a API.

5.3.1 Estruturas de Dados

As estruturas de dados foram baseadas no funcionamento dos drivers e nas funcionalidadesacessıveis em cada uma das tecnologias e foram organizadas de maneira que a aplicacao queutilize a API tenha acesso transparente a essas informacoes. O acesso aos dados dessas estruturase feito atraves das funcoes do bloco de Informacoes, uma vez que essas efetuam a leitura dosdrivers e os escrevem nessas estruturas. Na inicializacao da API, e criada uma sessao com osdrivers das interfaces sem fio presentes nos dispositivos, que carrega os dados que a interfacedisponibiliza, nas estruturas. Como descrito na secao 5.1, o bloco de informacoes da API eresponsavel por fazer essa carga incial.

Todas as informacoes coletadas sao armazenadas nas estruturas das interfaces e numa estru-tura, struct wdev list que e responsavel pelas informacoes mais genericas das interfacesde redes. Com isso, essa estrutura que engloba o funcionamento das outras, e o ponto de par-tida para todas as funcoes da API, que a utilizam como referencia para o acesso aos dados dasinterfaces. Os principais campos dessa estrutura sao descritos a seguir:

• dev number: quantidade de interfaces de comunicacao sem fio presentes;

• wdev info: referencia aos dados das interfaces presentes

• skfd: socket utilizado para a comunicacao com o driver da interface;

• wifi info: referencia aos dados da interface Wi-Fi;


• bt info: referencia aos dados da interface Bluetooth;

• net context: informacoes do contexto de rede da interface;

• maxsamples: quantidade maxima de amostragens das medidas do canal decomunicacao;

• mac sample: as medidas do comportamento da interface, amostradas maxsamplesvezes.

A seguir as descricoes das estruturas especıficas das duas interfaces.

Wi-Fi

As estruturas de acesso ao driver Wi-Fi, possuem os seguintes campos:

• ifname: identificador da interface no Linux, descrito na secao 3.7;

• macaddr: endereco mac da interface;

• manufac: nome do chipset da interface;

• nwid: o identificador da rede, descrito na secao 3.1;

• essid: a identificacao da rede extendida, descrito na secao 3.1;

• mode: modo de operacao, descrito na secao 3.1;

• freq: a frequencia de funcionamento, descrito na secao 3.2;

• bitrate: a taxa de transmissao utilizada, descrito na secao 3.2;

• power: modo de gerencia de energia, descrito na secao 3.4.4;

• key, key size e key flags: as chaves utilizadas no modo de seguranca, descritona secao 3.4.3;

• nickname: nome dado a estacao que utiliza a interface;

• ap addr: endereco do ponto de acesso, descrito na secao 3.4.2;

• sens: nıvel de sensibilidade ao canal, descrito na secao 3.5;

• rts: limite do tamanho do pacote para o uso do RTS/CTS, descrito na secao 3.5;


• frag: limite para a fragmentacao em bytes, descrito na secao 3.5;

• txpower: valor da potencia de transmissao, descrito na secao 3.5;

• retry: numero de tentativas para a restransmissao, descrito em 3.5;

• stats: estatısticas locais dos pacotes, como retransmissoes e erros.

Bluetooth

As estruturas de acesso ao driver Bluetooth possuem os seguintes campos:

• ifname: identificador da interface no Linux;

• localname: nome do dispositivo que possui a interface;

• bda: endereco de rede da interface

• amaddr: endereco de rede da interface na Piconet, descrito na secao 4.1;

• policy: modo de gerenciamento de energia, descrito na secao 4.3.2;

• numconn: numero de conexoes ativas;

• pkttype: tipo de pacote utilizado, descrito na secao 4.3.2;

• class cod: classe do dispositivo, descrito na secao 4.1;

• scan action, scan mode: regras de conexao, que determinam se a interface podeser conectada e se vai efetuar o Inquiry ou o Inquiry Scan, descrito na secao 4.3.2;

• role deny, role become master: regras para a criacao de scatternets atraves datroca de mestre e escravo, descrito na secao 4.3.2;

• auth, encr: configuracoes do modo de seguranca, descrito na secao 4.3.2;

• page to: controle do tempo maximo no estado Paging, descrito na secao 4.3.2

• hci version, lmp version: identificador da versao da especificacao e do chipsetimplementado;

• manufac: nome do fabricante da interface;

• pkt feat: tipos de pacotes suportados pela interface, descritos na secao 4.3.2


• radio feat: caracterısticas da interface de radio e possibilidade de suporte ao RSSI,descrito na secao 4.3.1

• audio feat: modos de funcionamento de audio suportados, descritos na secao 4.3.2

• policy feat: modos de gerencia de energia suportados, descritos na secao 4.3.2

• encryp feat: tipo de criptografia e seguranca suportados, descritos na secao 4.3.2

• power feat: capacidades de gerencia de transmissao suportados, descritos na secao4.3.1

• link buffers: tamanhos e quantidade de buffers dos canais logicos (ACL, SCO), des-crito na secao 4.3.2

5.3.2 Funcoes

Para que a API tenha uma comunicacao com os drivers das interfaces foram criadas funcoesque inicializam e terminam esse processo, estabelecendo sessoes com os drivers presentes. Essasfuncoes detectam a presenca das interfaces no computador e criam as estruturas necessarias. Notermino de sua utilizacao, sao chamadas as funcoes que finalizam essa comunicacao com osdrivers e liberam toda a memoria alocada.

Assim que a sessao e criada, e retornado um handle para as estruturas alocadas. A cadachamada das funcoes da API, esse e utilizado como argumento para que as funcoes tenham umacesso coordenado a esses dados.

As funcoes de controle da sessao com os drivers sao as seguintes:

• create Session wifi(wdev List *wdevlist): detecta os drivers e as interfa-ces Wi-Fi presentes, verifica as funcionalidades implementadas e inicializa a comunicacaocom esses;

• create Session bt(wdev List *wdevlist): detecta os drivers e as interfacesBluetooth presentes, verifica as funcionalidades implementadas e inicializa a comunicacaocom esses;

• terminate Session bt(wdev List *wdevlist): termina a comunicacao comos drivers Bluetooth presentes e libera a memoria alocada;

• terminate Session wifi(wdev List *wdevlist): termina a comunicacaocom os drivers Wi-Fi presentes e libera a memoria alocada.


O controle de erros da API e vinculado aos controles de erros dos drivers, sendo retornadosos erros e as mensagens pelo valor de retorno das funcoes e pela saıda stderr, para facilitar ainterpretacao dos erros.

Para cada conjunto de funcoes dos blocos foi estabelecida uma nomenclatura, de acordo como bloco e a tecnologia envolvida, sendo estes identificados pelos prefixos das funcoes. A Tabela5.1 mostra a organizacao dessa nomenclatura.

Tipo de Funcao Prefixo Bluetooth Prefixo Wi-FiInformacao do Dispositivo inf bt XXXXX inf wf XXXXX

Configuracoes conf bt XXXXX conf wf XXXXXContexto de Rede nc bt XXXXX nc wf XXXXX

Interface XML xml bt XXXXX xml wf XXXXX

Tabela 5.1: Nomenclatura utilizada

No caso do Bluetooth, caso a funcoes atue sobre elementos conectados, e adicionado o pre-fixo LinkManager, para indicar as funcoes que acessam a camada LMP.

A seguir serao descritas as funcoes presentes em cada um dos blocos. No total, sao 80 funcoesdistribuıdas entre os blocos, totalizando em aproximadamente 4800 linhas de codigo.

Informacoes do Dispositivo

Wi-Fi

• inf wf ESSID(wdev Info *winfo,char *tmp): retorna o valor do ESSID dainterface Wi-Fi, descrito na secao 3.1;

• inf wf Nome(wdev Info *winfo,char *tmp): retorna o nickname da interfaceWi-Fi;

• inf wf ifname(wdev Info *winfo, char *ifname): retorna o nome da in-terface do dispositivo no Linux;

• inf wf NWID (wdev Info *winfo,char *tmp): retorna o NWID da interface,descrito na secao 3.1;

• inf wf Mode(wdev Info *winfo,char *tmp): retorna o modo de funciona-mento,(ad hoc ou infra-estruturado), descrito na secao 3.1;


• inf wf Freq(wdev Info *winfo,char *tmp): retorna o valor da frequencia,ou canal, utilizados, descrito na secao 3.2;

• inf wf AP Addr(wdev Info *winfo,char *tmp): retorna o endereco do pontode acesso, descrito na secao 3.4.2;

• inf wf BitRate(wdev Info *winfo,char *tmp): retorna o valor da taxa detransmissao utilizada, descrito na secao 3.2;

• inf wf TXPower(wdev Info *winfo,char *tmp): retorna o valor da potenciade transmissao utilizada, descrito na secao 3.5;

• inf wf Sens(wdev Info *winfo,char *tmp): retorna o valor do nıvel de sen-sibilidade da interface, descrito na secao 3.5;

• inf wf RTS(wdev Info *winfo,char *tmp): retorna o valor do tamanho do pa-cote para o RTS, descrito na secao 3.5;

• inf wf Frag(wdev Info *winfo,char *tmp): retorna o valor do tamanho dopacote para a fragmentacao, descrito na secao 3.5;

• inf wf Key(wdev Info *winfo,char *tmp): retorna o valor da chave utilizada,descrito na secao 3.4.3;

• inf wf Power(wdev Info *winfo,char *tmp): retorna o tipo de polıtica deeconomia de energia utilizada, descrito na secao 3.4.4;

• inf wf macaddr(wdev Info *winfo, char *bda,int size): retorna oendereco mac da interface Wi-Fi;

Bluetooth

• inf bt pageto(wdev Info *winfo,int *page to): retorna o valor do time-out do estado Page, descrito na secao 4.3.2;

• inf bt localname(wdev Info *winfo, char *localname,int size):retorna o nickname da interface Bluetooth;

• inf bt bda(wdev Info *winfo, char *bda,int size): retorna oendereco mac da interface Bluetooth;

• inf bt LinkManager amaddr(wdev Info *winfo, char *amaddr,intsize): retorna o endereco da conexao da interface Bluetooth, descrito em 4.1;

• inf bt LinkManager numConn(wdev Info *winfo, int numconn,intsize): retorna o numero de conexoes ativas, descrito em 4.1;


• inf bt ifname(wdev Info *winfo, char *ifname): retorna o nome da in-terface no Linux;

• inf bt class(wdev Info *winfo, char *class name): retorna a classe dodispositivo utilizada, descrito na secao 4.1;

• inf bt packettypes(wdev Info *winfo, char *pkt types): retorna otipo de pacote utilizado, descrito na secao 4.3.2;

• inf bt manufacture(wdev Info *winfo, char *manufac,int size):informa o nome do fabricante da interface, descrito na secao 4.5;

• inf bt version(wdev Info *winfo, char *version,int size): re-torna qual a versao da especificacao a interface implementa, descrito na secao 4.5;

• inf bt features packet(wdev Info *winfo, char *pkt feat,intsize): retorna quais os tipos de pacotes suportados pela interface, descrito na secao4.3.2;

• inf bt feature radio(wdev Info *winfo, char *radio feat,intsize): retorna quais as caracterısticas do radio sao suportadas, descrito na secao 4.3.1;

• inf bt feature policy(wdev Info *winfo, char *policy feat,intsize): retorna os tipo de economia de energia suportados pela interface, descrito nasecao 4.3.2

• inf bt features encr(wdev Info *winfo): retorna o tipo de criptografia su-portado, descrito na secao 4.3.2;

• inf bt feature audio(wdev Info *winfo, char *audio feat,intsize): retorna o suporte a servico de audio, descrito na secao 4.3.2;

• inf bt feature power(wdev Info *winfo): retorna quais as potencias supor-tadas pela interface, descrito na secao 4.3.1;

• inf bt buffer acl(wdev Info *winfo, int *num,int *size): retornao tamanho do buffer para o canal ACL, descrito na secao 4.3.2;

• inf bt buffer sco(wdev Info *winfo, int *num,int *size): retornao tamanho do buffer para o canal SCO, descrito na secao 4.3.2;

• inf bt security mode(wdev Info *winfo, char *mode map,intsize): retorna o modo de seguranca utilizado pela interface, descrito na secao 4.3.2;

• inf bt LinkManager role deny(wdev Info *winfo): retorna as regras deconexao utilizadas para a criacao de scatternet, no caso se o elemento pode se tornar mestreda nova piconet, descrito na secao 4.3.2;


• inf bt LinkManager role bemaster(wdev Info *winfo): retorna regras deconexao utilizadas para a criacao de scatternet, no caso se o escravo da piconet podeefetuar a troca de funcoes com o mestre, se tornando mestre desta. Descrito na secao4.3.2;

• inf bt scan mode(wdev Info *winfo): retorna se a interface pode entrar no es-tado Inquiry, descrito na secao 4.3.2;

• inf bt scan action(wdev Info *winfo): retorna se a interface pode estabele-cer novas conexoes, descrito na secao 4.3.2;

Configuracoes

Wi-Fi

• conf wf Mode(wdev Info *winfo,char *tmp): altera o modo de funciona-mento da interface, descrito em 3.1;

• conf wf NWID(wdev Info *winfo,char *tmp): altera o valor do NWID da in-terface, descrito em 3.1;

• conf wf Freq(wdev Info *winfo,char *tmp): altera a frequencia utilizada.Tambem e possıvel alterar pelo numero do canal associado a essa frequencia. Descrito em3.2;

• conf wf Sens(wdev Info *winfo,int tmp): ajusta o nıvel de sensibilidade dainterface. Os valores vao de 1/3 a 3/3. Descrito em 3.5

• conf wf ESSID(wdev Info *winfo,char *tmp): ajusta o nome do ESSID dainterface. Descrito em 3.1;

• conf wf AP(wdev Info *winfo,char *tmp): altera o valor do ponto de acessoda interface, descrito em 3.4.2;

• conf wf Nome(wdev Info *winfo,char *tmp): altera o nickname da interface;

• conf wf BitRate(wdev Info *winfo,char *tmp): altera a taxa de trans-missao utilizada. Os valores variam de 1Mbps, 2Mbps e 11Mbps para o 802.11b. Descritoem 3.2 e 3.6;

• conf wf RTS(wdev Info *winfo, char *tmp):altera o tamanho do limite parao RTS/CTS, descrito na secao 3.5;


• conf wf Frag(wdev Info *winfo, char *tmp): altera o tamanho do pacoteque pode ser fragmentado, descrito na secao 3.5;

• conf wf TxPower(wdev Info *winfo, double tmp): altera o valor dapotencia de transmissao, descrito em 3.5;

• conf wf Power(wdev Info *winfo, double tmp): altera o modo de econo-mia de energia, descrito em 3.4.4;

• conf wf Retry(wdev Info *winfo,char *tmp): altera os valores para a re-transmissao, descrito em 3.5;

Bluetooth

• conf bt nickname(wdev Info *winfo, char* localname): altera o nick-name da interface;

• conf bt scan mode(wdev Info *winfo,int disc,int conn): altera omodo de descoberta da interface, permitindo ou nao que essa possa ser descoberta ouentrar em procedimento de conexao, descrito em 4.3.2;

• conf bt role(wdev Info *winfo,int deny,int master): altera as regrasde formacao da scatternet, permitindo que o elemento possa conectar e efetuar a transicaomestre/escravo na piconet, descrito em 4.3.2;

• conf bt class of device(wdev Info *winfo,char* class): altera aclasse do dispositivo da interface, permitindo a configuracao para o tipo desejado pelaaplicacao, descrito em 4.1;

• conf bt pkt type(wdev Info *winfo, char *pkt type): altera o tipo depacote utilizado pela interface, descrito em 4.3.2;

• conf bt timeout pageto(wdev Info *winfo, int pageto): altera o valordo timeout do estado Page

• conf bt security mode(wdev Info *winfo, char* sec mode map): al-tera o modo de seguranca utilizado, descrito em 4.3.2;

• conf bt LinkManager policy(wdev Info *winfo, int policy): alterao modo de gerencia de energia do canal, descrito em 4.3.2;

• conf bt LinkManager Switch(wdev Info *winfo,int role): efetua atroca mestre e escravo na piconet, descrito em 4.3.2;


Contexto de rede - Informacoes Locais

Wi-Fi

• nc wifi localstats(wdev Info *winfo, struct stats *Stats): re-torna o valor das estatısticas locais;

Bluetooth

• nc bt stats acl(wdev Info *winfo,int *rx acl,int *tx acl): re-torna as estatısticas associadas ao canal ACL, descrito em 4.3.2;

• nc bt stats sco(wdev Info *winfo,int *rx sco,int *tx sco): re-torna as estatısticas associadas ao canal SCO, descrito em 4.3.2;

• nc bt stats bytes(wdev Info *winfo,int *rx bytes,int*tx bytes): retorna a quantidade de bytes utilizados, durante o procedimento dedescoberta e na conexao;

• nc bt stats dropped(wdev Info *winfo,int *rx dropped,int*tx dropped): retorna a quantidade de pacotes descartados;

• nc bt stats errors(wdev Info *winfo,int *rx errors,int*tx errors): retorna a taxa de erros dos dados, nao corrigidos pelo FEC;

• nc bt stats cmds(wdev Info *winfo,int *tx cmds): retorna a quantidadede comandos LMP enviados pela interface, descrito em 4.3.2;

• nc bt update(wdev Info *winfo): atualiza a leitura dos valores da estatıstica lo-cal;

Contexto de rede - Qualidade do canal

Os valores da qualidade do canal sao armazenados na estrutura mac sample e acessadosatraves das funcoes de calculo da amostragem.

Wi-Fi: no Wi-Fi as informacoes da qualidade do canal estao associadas a todos os pacotesque chegam na interface, sendo necessario selecionar o endereco MAC das interfaces vizinhasque se deseja ter informacoes.


• nc wf add QualityInfo(wdev Info *wdev info, char *mac): selecionaqual o endereco da interface

• nc wf QualityInfo(wdev Info *wdev info): retorna os valores de RSSI equalidade do canal a partir dos pacotes recebidos;

• nc wf calc qualinfo(wdev info *wdev info, struct *stats): efetuao calculo da media e da variancia dos dados amostrados;

Bluetooth: no Bluetooth as informacoes de qualidade do canal estao associadas aos elemen-tos conectados, sendo necessarios estarem dentro da piconet para serem executados. Futurasversoes ja preveem o uso dessas medidas durante o processo de descoberta e conexao.

• nc bt RSSI(wdev Info *winfo): retorna o valor do RSSI da interface, descrito em4.6.1;

• nc bt QualInfo: le o valor da qualidade do canal, descrito em 4.6.1;

• nc bc calc qualinfo(wdev info *wdev info, struct *stats): efetuao calculo da media e da variancia dos dados amostrados;

• nc bt LinkManager GetHandle(wdev Info *winfo, char *macaddr):retorna o handle da conexao com o endereco informado, descrito na secao 4.3.2;

XML

• xml wf savedata(wdev Info *winfo): salva os valores das estruturas em um ar-quivo XML;

• xml bt savedata(wdev Info *winfo) salva os valores das estruturas em um ar-quivo XML;

Capıtulo 6

Testes e Resultados

6.1 Experimentos

Para demonstrar a API desenvolvida foi criada uma aplicacao que cria uma serie de testescom os dois ambientes de estudo: Bluetooth e 802.11. Os primeiros testes incluem a analisede interferencia de um ambiente sobre outro e seu impacto no desempenho das aplicacoes. Asegunda bateria de testes relaciona-se as caracterısticas do canal sob condicoes de mobilidade.Os valores das medidas da qualidade do canal foram amostrados em intervalos de 100ms e, a cada1 segundo, foram feitos os calculos estatısticos sobre estes. Dessa maneira, atraves da analiseda variancia desses valores no ponto e possıvel estipular se algum comportamento diferenciadoesta ocorrendo, como um acrescimo na interferencia ou na mobilidade. E numa amostragemmaior dos pontos, e possıvel determinar uma tendencia nos comportamentos. Dentre as diversasinformacoes que se pode obter atraves da API, decidimos nos concentrar em tres medidas:

• Qualidade do canal: e a qualidade da recepcao dos dados. Os seus valores e a sua metricae dependente do fabricante da interface. Na interface 802.11 utilizada este valor varia de 0a 92, enquanto que na interface Bluetooth, varia de 0 a 255;

• Forca do sinal de recepcao: O valor da potencia do sinal do pacote recebido na interface.Na interface 802.11 este valor varia 0 a 255. No Bluetooth, os valores do RSSI estaoexplicados na secao 4.6.1;

• Vazao: e a quantidade de bytes recebidos pela aplicacao em um determinado instante.

A seguir o codigo da aplicacao-teste:

79

CAPITULO 6. TESTES E RESULTADOS 80

#include <stdio.h>#include "iw_se.h"

void main() {//Estrutura de acesso as interfaceswdev_List wdevlist;int i,j;

//Cria a sessao com a interface Wi-Fiif(!create_Session_wifi(&wdevlist)){perror("Erro ao iniciar interface Wi-Fi");exit(1);}//Adiciona a analise de qualidade no endereco MACnc_wf_add_QualityInfo(&wdevlist,"00:60:1D:03:37:25");

//Cria a sessao com a interface Bluetoothif(!create_Session_bt(&wdevlist)){perror("Erro ao iniciar interface Bluetooth");exit(1);

}//Adiciona a analise de qualidade na conexaonc_bt_LinkManager_GetHandle(&wdevlist,"00:80:37:14:59:4f");

//Amostra os valores de contexto de redefor(j=0;j<240;j++){for(i=0;i<10;i++){//Le a informacao da interface wi-finc_wf_QualityInfo(&wdevlist);

//Le a informacao da interface Bluetoothnc_bt_RSSI(&wdevlist);nc_bt_QualInfo(&wdevlist);

//Intervalo de 100msusleep(100000);

}//Calcula a dispersao dos dados

calcQualityInfo(&wdevlist,"wf");calcQualityInfo(&wdevlist,"bt");calcRSSI(&wdevlist,"wf");calcRSSI(&wdevlist,"bt");

}//XMLxml_wf_savedata(&wdevlist);xml_bt_savedata(&wdevlist);terminate_Session_bt(&wdevlist);terminate_Session_wf(&wdevlist);

};


Ao fim dos experimentos foram gerados os arquivos XML descrevendo as caracaterısticas dasinterfaces presentes nas maquinas de teste. Essas informacoes sao essenciais para a analise dosdados, uma vez que informam as capacidades de cada um dos elementos. A Figura 6.1 mostra asinformacoes coletadas da interface Bluetooth e a Figura 6.2 as informacoes da interface Wi-Fi.

Figura 6.1: Informacoes da Interface Bluetooth.


Figura 6.2: Informacoes da Interface Wi-Fi

6.2 Analise da Interferencia

Para estes experimentos, utilizamos o sistema operacional Suse Linux 7.1, kernel 2.4.18,em um notebook Compaq Armada, Pentium II, 365 MHz, 128MB e dois desktops, Pentium II,400MHz e 256 MB de memoria. As interfaces 802.11 utilizadas foram uma placa PCMCIAInterlink, com o chipset Prism I, e uma placa PCMCIA Wavelan, com o chipset Hermes 1. Ainterface do Bluetooth foi o kit da Ericsson, com os chipsets, ROK 101 007 e ROK 101 008, ea interface USB-Bluetooth da TDK, com o chipset da Cambridge Silicon Systems, o Bluecore.Tambem foram utilizados dois pontos de acesso, um Bluetooth da WidComm, o Bluegate 2100,e um ponto de acesso 802.11, que utilizou a placa Wavelan.

A placa Interlink e a interface USB-Bluetooth foram colocados no notebook, caracterizandouma situacao de interferencia intensa, uma vez que as duas interfaces estavam muito proximas.E o desktop, com a interface Bluetooth, e o ponto de acesso, com a interface 802.11, foram colo-cados a 15 cm de distancia do notebook, de maneira a interferirem diretamente na comunicacao.

Os graficos 6.3(a) e 6.3(b) representam a qualidade dos sinais quando submetidos a umtrafego CBR no canal Bluetooth e um trafego FTP no canal 802.11. No inıcio de monitoracao(tempo 0 s), somente o trafego Bluetooth ocupa o canal, portanto a qualidade obervada atinge o


ponto maximo em ambos os canais: 255 no Bluetooth e 92 no 802.11. Ao iniciar da aplicacaoFTP, a qualidade do canal Bluetooth reduz, oscilando entre 210 e 235 ate o fim da monitoracao(tempo 120 s). Pela figura 6.3(b), podemos notar que a qualidade do canal 802.11 sofre alteracoesainda maiores. Nos instantes iniciais, a qualidade mantem-se estavel em seu valor maximo,porem se torna menor e com grandes oscilacoes a partir do inıcio da transferencia de dados. Aconclusao, ja prevista, e que a transmissao de dados em um canal exerce grande impacto sobreo desempenho do outro canal. Entretanto, e interessante notar que a variacao da qualidade docanal 802.11 e muito superior aquela observada no canal Bluetooth, o que se deve a forma comoos protocolos utilizam o meio. Uma vez que o Bluetooth foi feito tendo a robustez como guia, ede se esperar que sofra menos impacto que as tecnologias 802.11. A amostragem desses dadose feita a cada 100ms e cada ponto corresponde ao valor medio e a variancia de 10 amostragensconsecutivas, ou seja, a cada 1 segundo.

205

210

215

220

225

230

235

240

245

250

255

260

0 20 40 60 80 100 120

Qua

lidad

e do

Can

al

Tempo (s)

Inicio FTP

Inicio FTP

Bluetooth

(a) Bluetooth.

-20

0

20

40

60

80

100

120

0 20 40 60 80 100 120

Qua

lidad

e do

Can

al

Tempo (s)

Inicio FTP 802.11

(b) 802.11.

Figura 6.3: Qualidade dos canais Bluetooth (pacote DH1 e trafego CBR) e 802.11 (taxa detransmissao de 1MB e trafego FTP).

A seguir analisaremos o efeito de variacoes de parametros no canal Bluetooth e suas con-sequencias no canal 802.11. Como explicado na secao 4.3.2, a protocolo Bluetooth pode serconfigurado para transmitir dados a diferentes taxas, cada qual relacionada a um tipo de pacotedistinto (tabela 4.4). As figuras 6.4(a) e 6.4(b) demonstram o efeito do uso desses diferentes ti-pos de pacotes sobre a qualidade observada nos dois canais de comunicacao quando submetidosa transferencia de dados descrita no exemplo anterior. Os graficos representam a distribuicaoacumulada dos valores de qualidade observada em cada experimento. Como podemos notar nafigura 6.4(a), os tipos de pacotes DH1 e DM1 sao os que mais apresentam valores reduzidos paraqualidade do canal Bluetooth: 90% dos valores observados estao abaixo de 231 para o DH1 eabaixo de 227 para o DM1. E interessante notar, tambem, que o tipo de pacote DH5 e aquele queapresenta a melhor distribuicao de valores na faixa aceitavel para comunicacao (200 e 255). Essecomportamento tambem tem reflexos no canal 802.11. No grafico da figura 6.4(b), podemos verque os tipos de pacotes DM1 e DH1 sao os que mais degradam a qualidade do canal 802.11,sendo o DH5 aquele que possui a maior quantidade de pontos no valor maximo de qualidade.Isso e um dado animador pois, alem de apresentar a maior taxa de transmissao de dados, o DH5


e o que menos afeta os outros ambientes de comunicacao e, portanto, o que menos degrada o de-sempenho de outros canais. Compreender os efeitos dos diferentes tipos de carga e configuracoese extremamente importante para se definir polıticas de acesso em ambientes compartilhados. Nonosso caso, poderıamos definir uma mudanca automatica do tipo de pacote para DH5 no mo-mento em que o dispositivo movel detectar uma comunicacao semelhante a que foi modeladanesse experimento.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

210 215 220 225 230 235 240 245 250 255

Dis

tribu

icao

acu

mul

ada

Qualidade do link Bluetooth

DH1DH3DH5DM1DM3DM5

(a) Bluetooth.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 10 20 30 40 50 60 70 80 90 100

Dis

tribu

icao

acu

mul

ada

Qualidade do link 802.11

DH1DH3DH5DM1DM3DM5

(b) 802.11.

Figura 6.4: Distribuicao acumulada da qualidade dos canais Bluetooth e 802.11 (taxa de trans-missao de 1MB).

Os graficos 6.5(a) e 6.5(b) ilustram a forca do sinal para os ambientes estudados para a mesmacarga descrita acima. Nota-se que, no Bluetooth, ha uma clara distincao entre a forca de sinalpara os pacotes da classe DH (valores inferiores) para os da classe DM (valores superiores).Nesse grafico, quanto menor o valor da escala, maior e a forca de recepcao do sinal. Para oambiente 802.11, a forca do sinal possui uma maior variacao. No grafico 6.5(b), quanto maior ovalor da escala, mais fraco e o sinal de recepcao do canal. Nesse ultimo caso, nao ha uma relacaoclara entre o tipo de pacote do canal Bluetooth com a forca do sinal no canal 802.11. Para todosos testes, a faixa de valores e aproximadamente a mesma e suas variancias sao sempre elevadas.

Mudancas na configuracao do ambiente 802.11 tambem alteram o comportamento da qua-lidade dos canais. Os graficos das figuras 6.6(a) e 6.6(b) refletem a qualidade do canal 802.11quando alteramos a sua taxa de transmissao de 1MB para 2MB e geramos o mesmo trafego an-terior, com tipo de pacote DH5 no canal Bluetooth. Podemos notar que a taxa de transmissaomais alta e menos afetada pela inteferencia do Bluetooth, o que impacta diretamente no desem-penho das aplicacoes nos dois ambientes. As figuras 6.7(a) e 6.7(b) ilustram a vazao medida pelaaplicacao FTP no dispositivo movel sem interferencia no canal Bluetooth e com a interferenciadescrita acima. O valor medio da vazao sem interferencia e cerca de 240 kbps para taxa de tran-missao de 1 MBps e cerca de 320 kbps para taxa de transmissao de 2 MBps, porem esses valorescaem para 127 kbps e 208 Kbps sob efeitos de interferencia, respectivamente. Apesar da quedavisıvel no valor medio, e interessante notar que a qualidade alta do canal no caso de taxa detransmissao de 2MB permite picos de vazao proximos aos valores sem intereferencia. O mesmo


0

2

4

6

8

10

12

14

16

18

0 20 40 60 80 100 120

RS

SI

Tempo (s)

DM1

DH5

DH3

DH1DM3

DM5

DH1DH3DH5DM1DM3DM5

(a) Bluetooth.

60

70

80

90

100

110

120

130

140

150

0 20 40 60 80 100 120

RS

SI

Tempo (s)

DH1DH3DH5DM1DM3DM5

(b) 802.11.

Figura 6.5: Forca do sinal nos canais Bluetooth e 802.11 (taxa de transmissao de 1MB).

nao acontece no caso de taxa de 1 MB: a qualidade do canal e tao degradada que o troughputmaximo chega a apenas 82% do valor medio sem interferencia.

-20

0

20

40

60

80

100

120

0 20 40 60 80 100 120

Qua

lidad

e do

Can

al

Tempo (s)

802.11

(a) Taxa de transmissao de 1MB no 802.11.

-20

0

20

40

60

80

100

120

0 200 400 600 800 1000 1200

Qua

lidad

e do

Lin

k

Tempo (s)

802.11

(b) Taxa de transmissao de 2MB no 802.11.

Figura 6.6: Qualidade do link 802.11 (interferencia Bluetooth com pacote DH5).

Apesar de obter uma qualidade melhor e um througput maior, a taxa de transmissao de 2MBe mais susceptıvel a perdas de conexoes que a de 1MB. O grafico da figura 6.8(a) ilustra umaqueda de conexao do canal 802.11 em um cenario de taxa de transmissao de 2MB e interferenciaBluetooth com tipo de pacote DH1. As quedas de conexoes sao mais frequentes para os tiposde pacotes DH1 1 DM1. A analise deste comportamento e um fator crucial para se determi-nar polıticas que avaliam tanto o desempenho quanto a confiabilidade de comunicacao de umaaplicacao em um ambiente compartilhado. A figura 6.8(b) reflete o aumento na qualidade dosinal do canal Bluetooth no momento de desconexao. Os graficos das figuras 6.9(a) e 6.9(b) ilus-tram o que acontece com a forca do sinal durante todo o processo. Nos graficos 6.8(a) e 6.9(a) epossıvel ver claramente as propriedades que caracterizam uma desconexao no ambiente sem fio:qualidade do sinal reduzida e forca de recepcao do sinal fraca.


0

50000

100000

150000

200000

250000

300000

0 20 40 60 80 100

Larg

ura

de B

anda

(bits

/s)

Tempo (s)

FTPFTP com Bluetooth DM5

(a) Taxa de transmissao de 1MB no 802.11.

0

50000

100000

150000

200000

250000

300000

350000

400000

0 20 40 60 80 100

Larg

ura

de B

anda

(bits

/s)

Tempo (s)

FTPFTP com Bluetooth DM5

(b) Taxa de transmissao de 2MB no 802.11.

Figura 6.7: Largura de banda do link 802.11 para FTP sem interferencia e com interferencia doBluetooth com pacote DH5.

-20

0

20

40

60

80

100

120

0 20 40 60 80 100 120

Qua

lidad

e do

Lin

k

Tempo (s)

Queda de conexao

802.11

(a) 802.11.

205

210

215

220

225

230

235

240

245

250

255

260

0 20 40 60 80 100 120

Qua

lidad

e do

Lin

k

Tempo (s)

Queda de conexao

Bluetooth

(b) Bluetooth.

Figura 6.8: Qualidade dos canais durante uma queda de conexao do canal 802.11 (interferenciado Bluetooth com pacote DH1)


40

60

80

100

120

140

160

180

0 20 40 60 80 100 120

RS

SI

Tempo (s)

802.11

(a) 802.11.

0

1

2

3

4

5

6

7

8

9

10

0 20 40 60 80 100 120

RS

SI

Tempo (s)

Bluetooth

(b) Bluetooth.

Figura 6.9: Forca do sinai dos canais durante uma queda de conexao do canal 802.11 (inter-ferencia do Bluetooth com pacote DH1)

6.3 Analise da mobilidade

Nesta secao serao analisados alguns resultados obtidos durante a avaliacao dos ambiente802.11 e Bluetooth na presenca de mobilidade. Foram utilizados um notebook Compaq Armada,Pentium II, 365 MHz, 128MB, a interface 802.11, placa PCMCIA Interlink, a interface USB-Bluetooth da TDK e os pontos de acesso das duas interfaces. As medidas foram feitas sem apresenca de interferencia na transmissao.

Para verificar as medidas de sinal na mobilidade, foi percorrida uma distancia de 60 metrosem linha reta, adiante aos pontos de acesso, e na direcao horizontal, a esquerda e direta, umadistancia de 30 metros dos pontos de acesso.

As figuras 6.10(a) e 6.10(b) representam a qualidade dos canais Bluetooth e 802.11 ao seafastarem perpendicularmente do ponto de comunicacao. Podemos notar uma queda acentudadana qualidade do canal 802.11 e uma queda mais suavizada para o Bluetooth. Tambem e possıvelnotar um pequeno aumento e estabilizacao de valores nos momentos de paradas. Os graficos6.11(a) e 6.11(b) ilustram os valores da forca do sinal durante o movimento. Podemos notar que,para o ambiente 802.11, essa ultima curva acompanha a curva de qualidade do sinal e decai amedida que se afasta do ponto de comunicacao. Tambem e possıvel notar o aumento relativodos valores nos momentos de parada. Ja no caso do Bluetooth, notamos que a forca do sinal caiabruptamente para proximo do menor valor possıvel, indicando uma possıvel saıda da area decobertura.

As figuras 6.12(a) e 6.12(b) referem-se as qualidades dos canais em um movimento deaproximacao do ponto de comunicacao. E interessante notar tambem o mesmo comportamentodos graficos anteriores: os momentos de parada sao marcados pelo aumento do valor da qua-


0

50

100

150

200

250

0 50 100 150 200 250

Qua

lidad

e do

link

Tempo (s)

Bluetooth

(a) Bluetooth.

-10

0

10

20

30

40

50

60

70

80

90

100

0 50 100 150 200 250

Qua

lidad

e do

link

802

.11

Tempo (s)

802.11

(b) 802.11.

Figura 6.10: Qualidade dos links Bluetooth e 802.11 afastando-se do ponto de comunicacao.

-130

-128

-126

-124

-122

-120

-118

0 50 100 150 200 250

RS

SI

Tempo (s)

Bluetooth

(a) Bluetooth.

0

50

100

150

200

250

300

0 50 100 150 200 250

RS

SI

Tempo (s)

802.11

(b) 802.11.

Figura 6.11: Forca do sinal dos canais Bluetooth e 802.11 afastando-se do ponto de comunicacao.


lidade do canal e posterior estabilizacao. Os graficos das figuras 6.13(a) e 6.13(a) indicam aforca do sinal durante o movimento. Assim como nos graficos anteriores, o aumento dessa me-dida para o ambiente 802.11 e gradativo enquanto que, para o ambiente Bluetooth, e abrupto. Ocomportamento dos padroes da qualidade do sinal e da forca do sinal nos graficos acima dife-rem daqueles presentes nos graficos de interferencia, o que pode indicar uma possıvel solucaopara aplicacoes que desejam distinguir entre movimentacao e interferencia externa durante to-madas de decisoes. Nesse caso, o auxılio de uma ferramenta que faca a monitoracao contınuados ambientes e essencial.

200

210

220

230

240

250

260

0 50 100 150 200 250

Qua

lidad

e do

link

Tempo (s)

Bluetooth

(a) Bluetooth.

-10

0

10

20

30

40

50

60

70

80

90

100

0 20 40 60 80 100 120 140 160Q

ualid

ade

do li

nk 8

02.1

1Tempo (s)

802.11

(b) 802.11.

Figura 6.12: Qualidade dos links Bluetooth e 802.11 aproximando-se do ponto de comunicacao.

-160

-140

-120

-100

-80

-60

-40

-20

0

20

40

0 50 100 150 200 250

RS

SI

Tempo (s)

Bluetooth

(a) Bluetooth.

0

50

100

150

200

250

300

0 20 40 60 80 100 120 140 160

RS

SI

Tempo (s)

802.11

(b) 802.11.

Figura 6.13: Forca sinal Bluetooth e 802.11 aproximando-se do ponto de comunicacao.

Nas movimentacoes na direcao horizontal aos pontos de acesso e possıvel notar dois padroesde comportamento. A medida que o notebook foi afastando do ponto de acesso, a qualidade caiuconsideravelmente, mas no momento em que o caminho de volta comecou a ser percorrido, eo notebook foi colocado diretamente voltado para a antena do ponto de acesso, a qualidade dacomunicacao recuperou consideravelmente, mesmo antes do deslocamento voltar a acontecer.Esse recuperacao da qualidade e descrita pela rapida alteracao dos valores num curto espaco de


tempo, numa ascendente dos valores medidos. E possıvel notar este comportamento nos graficosde qualidade do canal, visto nas figuras 6.14(a), 6.14(b), 6.16(a) e 6.16(b), e nos que descrevem oseu nıvel de comunicacao, visto nas figuras 6.15(a), 6.15(b), 6.17(a) e 6.17(b), ambos ocorrendoem torno de 1200 ms.

E interessante notar a robustez da conexao do Bluetooth, vista em todos os graficos, onde avariancia das medidas de qualidade do canal e do nıvel do sinal e consideravelmente pequena,em comparacao com os valores da conexao do Wi-Fi.

Nas figuras 6.14(a) e 6.16(a) as curvas da qualidade da conexao do Bluetooth apresentamuma pequena estabilizacao, descrita pelas curvas com concavidade invertida. O mesmo compor-tamento pode ser visto na conexao Wi-Fi, descrito nas figuras 6.14(b) e 6.16(b), mas a varianciadas medidas e significativamente maior, o que descreve uma pior qualidade da conexao.

120

140

160

180

200

220

240

260

0 500 1000 1500 2000 2500

Qua

l

Time

"nc_bt_qual_vmob.dat" using 1:2:3

(a) Bluetooth.

-10

0

10

20

30

40

50

60

70

80

90

100

0 200 400 600 800 1000 1200 1400 1600 1800 2000

Qua

l

Time

"nc_wifi_vm.dat" using 1:2:3

(b) 802.11.

Figura 6.14: Qualidade dos canais Bluetooth e 802.11 movimentando-se a esquerda do ponto decomunicacao.

-160

-140

-120

-100

-80

-60

-40

-20

0

20

0 500 1000 1500 2000 2500

RS

SI

Time

"nc_bt_rssi_vm.dat" using 1:2:3

(a) Bluetooth.

0

50

100

150

200

250

300

0 200 400 600 800 1000 1200 1400 1600 1800 2000

RS

SI

Time

"nc_wifi_rssi_vm.dat" using 1:2:3

(b) 802.11.

Figura 6.15: Forca sinal Bluetooth e 802.11 movimentando-se a esquerda do ponto decomunicacao.


140

160

180

200

220

240

260

0 500 1000 1500 2000 2500

Qua

l

Time

"nc_bt_qual_vmob.dat" using 1:2:3

(a) Bluetooth.

0

10

20

30

40

50

60

70

80

90

100

0 500 1000 1500 2000 2500

Qua

l

Time

"nc_wifi_vm.dat" using 1:2:3

(b) 802.11.

Figura 6.16: Qualidade dos canais Bluetooth e 802.11 movimentando-se a direita do ponto decomunicacao.

-140

-120

-100

-80

-60

-40

-20

0

20

0 500 1000 1500 2000 2500

RS

SI

Time

"nc_bt_rssi_vm.dat" using 1:2:3

(a) Bluetooth.

-50

0

50

100

150

200

250

0 500 1000 1500 2000 2500

RS

SI

Time

"nc_wifi_rssi_vm.dat" using 1:2:3

(b) 802.11.

Figura 6.17: Forca sinal Bluetooth e 802.11 movimentando-se a direita do ponto de comunicacao.


Na secao 6.1 foi dito que o desempenho e a qualidade dos canais 802.11 e do Bluetoothsao minimizados quando se usam os tipos de pacotes DM1 e DH1 para comunicacao no canalBluetooth. Isso poderia levar ao uso indiscriminado de pacotes do tipo DH5 ou semelhantepara transferencia de dados. No entanto, o uso de pacotes DM1 e DH1 e indicado quando sedeseja manter a conexao Bluetooth ativa por mais tempo, pois possuem um suporte mais robustoque os outros. Os pontos do grafico da figura 6.18 representam a qualidade do canal Bluetoothmedido no dispositivo movel quando nos afastamos de seu ponto de comunicacao. E possıvelnotar que a comunicacao com pacotes DM1 e DH1 suportam nıveis mais baixos de qualidade,o que possibilita manter a conexao ativa por mais tempo. Nesse experimento as conexoes compacotes do tipo DH5 e DM5 foram rompidas entre 10 a 15 metros do ponto de comunicacao. Asconexoes com tipo de pacote DH1 e DM1 foram rompidas somente apos 20 metros.

200

210

220

230

240

250

260

0 5 10 15 20 25 30 35 40 45

Qua

lidad

e do

link

Tempo (s)

DH1DH3DH5DM1DM3DM5

Figura 6.18: Qualidade do link Bluetooth afastando-se do ponto de comunicacao para os 6 tiposde pacotes.

Capıtulo 7

Conclusoes e Trabalhos Futuros

7.1 Conclusoes

Neste trabalho e apresentada a primeira versao de uma API que possibilita o acesso e aprogramacao de diversas funcionalidades das interfaces sem fio Wi-Fi e Bluetooth, que estao emfranca expansao, com perspectivas de se tornarem as mais difundidas para a comunicacao movel.

Foram mostrados os princıpios basicos de funcionamento de uma interface para redes semfio e os pontos em comum entre as diferentes interfaces deste tipo, criando os conceitos basicospara a arquitetura da API. A identificacao destes elementos permitiu que o projeto da API fosseutilizada de maneira comum em duas diferentes interfaces para a comunicacao sem fio.

Tambem foram apresentados os detalhes e funcionalidades das duas interfaces, identificandoquais sao os pontos relevantes para a interatividade com as aplicacoes e como configurar seuacesso. Um estudo de sua utilizacao no sistema operacional Linux permitiu identificar os modosde funcionamento e o projeto da programacao da API, de maneira integrada aos drivers utilizadospelo sistema. Tambem foi estudado o uso da funcao ioctl como ponto vital para o acesso asinformacoes contidas nos diferentes tipos de drivers

E mostrado tambem a implementacao simples do acesso as informacoes das interfaces,atraves da criacao de sessoes de comunicacao com cada tipo de interface.

Dentro desse acesso as informacoes, foi proposto o uso do contexto de rede como fonte deinformacao do comportamento da vizinhanca no processo de comunicacao, atraves das medidasde sinal e ruıdo da comunicacao. As funcoes do contexto de rede foram utilizadas como verifi-cador das funcionalidades da API, onde uma aplicacao, atraves da analise dos dados coletados,pode determinar os comportamentos de interferencia e mobilidade das estacoes envolvidas.

93

CAPITULO 7. CONCLUSOES E TRABALHOS FUTUROS 94

As medidas dos sinais, amostradas pela API, mostram o comportamento e possibilitam queas aplicacoes possam predizer o funcionamento da comunicacao. O estudo da variancia dosdados amostrados permite informar se aquele comportamento e instavel ou nao, identificando arobustez da transmissao.

Nos cenarios de interferencia, e possıvel que as aplicacoes possam reconfigurar o funciona-mento da transmissao de dados. Como foi mostrado, nestes cenarios de interferencia o funci-onamento do Bluetooth utilizando o pacote DH5 e o mais satisfatorio para a comunicacao, aocontrario do uso do pacote DM1. Em cenarios de mobilidade, onde nao existe a interferencia, aopcao de uso dos pacotes e a inversa, onde os pacotes DM1 possuem maior alcance.

7.2 Trabalhos Futuros

Esta e a primeira versao da API, onde foram identificados os princıpios basicos de funcio-namento e os detalhes relevantes para a sua implementacao. Para os trabalhos futuros seriamanalisadas as tecnicas para aumentar a seguranca na utilizacao das duas interfaces, tanto atravesdas funcoes de seguranca comuns, como as informacoes de contexto de rede, ou mesmo emcenarios do uso integrado das duas interfaces.

As informacoes da mobilidade e interferencia tambem colaboram para a criacao de funcoesque permitem uma localizacao dos elementos da rede, permitindo que as aplicacoes usem essainformacao para fornecer ou acessar servicos e recursos de maneira facilitada.

Outro ponto futuro e o teste da API em diversos tipos de dispositivos, como os construidosno projeto SmartIts, e mesmo em PDAs e celulares com interfaces Wi-Fi e Bluetooth. Tambemo teste em diversos tipos de chipsets e seus respectivos drivers.

Referencias Bibliograficas

[1] Bluetooth Specification. http://www.bluetooth.org.

[2] Affix. Affix bluetooth protocol stack for linux. http://affix.sourceforge.net/.

[3] Smart-Its. http://www.smart-its.org.

[4] .NET. http://www.microsoft.com/net/.

[5] Microsoft. Microsoft corporation. http://www.microsoft.com.

[6] J2ME java 2 micro edition. http://java.sun.com/j2me/.

[7] SUN. http://java.sun.com.

[8] IEEE 802.15. http://grouper.ieee.org/groups/802/15/.

[9] IEEE 802.11. http://grouper.ieee.org/groups/802/11/.

[10] Bluetooth Forum. http://www.bluetooth.com.

[11] Arlindo Flavio da Conceicao and Fabio Kon. Adaptacao de fluxos contınuos udp sobreredes ieee 802.11b. In Anais do V Workshop de Comunicacao sem Fio, 2003.

[12] Juliana Freitag, Nelson L. S. da Fonseca, and Omar C. Branquinho. Diferenciacao deservicos em redes 802.11 sob degradacao da taxa de transmissao. In Anais do V Workshopde Comunicacao sem Fio, 2003.

[13] Pietro Manzoni and Juan Carlos Cano. Providing interoperability between ieee 802.11and bluetooth protocols for home area networks. Computer Networks: The InternationalJournal of Computer and Telecommunications Networking, 42(1):23–37, 2003.

[14] Jean Tourrilhes and Casey Carter. P-handoff: A protocol for fine grained peer-to-peervertical handoff. In Proceedings of PIMRC 2002, 2003.

[15] Jean Tourrilhes and Venky Krishnan. Co-link configuration: Using wireless diversity formore than just connectivity. In Proceedings of WCNC 2003, 2003.

95

REFERENCIAS BIBLIOGRAFICAS 96

[16] Jean Tourrilhes. On-demand bluetooth: Experience integrating bluetooth in connectiondiversity. Technical report, Mobile and Media System Laboratory HP Laboratories PaloAlto, March 2003.

[17] O. Kasten and M. Langheinrich. First experiences with bluetooth in the smart-its distributedsensor network. In Proc of the Workshop on Ubiquitous Computing and Communications(PACT), October 2001.

[18] W. Ye, J. Heidemann, and D. Estrin. An energy-eficient mac protocol for wireless sensornetworks. IEEE Infocom 2002, pages 1567–1576, June 2002.

[19] Philipe Jacquet and Richard G. Ogier. Optimized link state routing protocol. Internet Draft,March 2001.

[20] J.Broch, D.B. Johnson, and D.A Maltz. The dynamic source routing protocol for mobile adhoc networks. Internet Draft, October 1999.

[21] C.E. Perkins and E.M. Royer. Ad hoc on demand distance vector (aodv). Internet Draft,March 2001.

[22] V.Park and S.Corson. Temporally -ordered routing algorithm (tora). Internet Draft, No-vember 2000.

[23] Simon Baatz, Matthias Frank, Carmen Kuhl, Peter Martini, and C. Scholz. Adaptive scatter-net support for bluetooth using sniff mode. In Proceedings of the 26th Annual Conferenceon Local Computer Networks, LCN 2001, pages 112–120, November 2001.

[24] Simon Baatz, Christoph Bieschke, Matthias Frank, Carmen Kuhl, Peter Martini, andC. Scholz. Building Efficient Bluetooth Scatternet Topologies from 1-Factors. In Procee-dings of the IASTED International Conference on Wireless and Optical Communications,WOC 2002, Banff, Alberta, Canada, July 2002.

[25] Simon Baatz, Matthias Frank, Carmen Kuhl, P. Martini, and C. Scholz. Bluetooth scatter-nets: An enhanced adaptive scheduling scheme. In Proceedings 21st Annual Joint Confe-rence of the IEEE Computer and Communications Societies, INFOCOM 2002., 2002.

[26] Ching Law, Amar K. Mehta, and Kai-Yeung Siu. Performance of a new bluetooth scatternetformation protocol. In Proceedings of the 2nd ACM international symposium on Mobile adhoc networking computing, pages 183–192. ACM Press, 2001.

[27] Bhaskaran Raman, Pravin Bhagwat, and Srinivasan Seshan. Arguments for cross-layeroptimizations in bluetooth scatternets. In Proceedings of Symposium on Applications andthe Internet, pages 176–184, 2001.

[28] Godfrey Tan. Self-organizing bluetooth scatternets. Master’s thesis, Department of Elec-trical Engineering and Computer Science Massachusetts Institute of Technology, January2002.


[29] XML. Extensible markup language (xml). http://www.w3.org/XML/.

[30] Erik Nordstrom. Ape - a large scale ad hoc network testbed for reproducible performancetests. Master’s thesis, Information Technology Department of Computer Systems UppsalaUniversity, june 2002.

[31] Carlos M. T. Calafate and Pietro Manzoni. A multi-platform programming interface forprotocol development. In 11th Euromicro Conference on Parallel Distributed and Networkbased Processing in Genoa, 2003.

[32] BlipNet. http://www.blipsystems.com/.

[33] Andrew S. Tanenbaum. Computer Networks. Prentice-Hall, fourth edition, 2002.

[34] Stepehn Hollar, Hatem Mohamed, Jeff Swearingen, and Paul Suh. The interference ofbluetooth and ieee 802.11b wireless technologies in the 2.4 ghz ism band. Technical report,North Carolina State University, April 2003.

[35] Ajay Chandr, V. Gummalla, and John O. Limb. Wireless medium access control protocols.IEEE Communication Survey´s Tutorials, 2:15, july 2000.

[36] S. Corson and J. Macker. Mobile ad hoc networking (manet): Routing protocol perfor-mance issues and evaluation considerations. Request for Comments document, rf2501,January 1999.

[37] A. Bruce and Taieb Znafi. Path availability model for wireless ad-hoc networks. In Proce-edings of Wireless Communications and Networking Conference, 1999.

[38] Marcus Nilsson, Josef Hallberg, and Kare Synnes. Positioning with bluetooth. In 10thInternational Conference on Telecommunications ICT’2003, 2003.

[39] Kiran Thapa and Steven Case. An indoor positioning service for bluetooth ad hoc networks.In In Proceedings of 36 Midwest Instruction and Computing Symposium, 2003.

[40] Silke Feldmann, Kyandoghere Kyamakya, Ana Zapater, and Zighuo Lue. An indoorbluetooth-based positioning system: concept, implementation and experimental evaluation.In In Proceedings of ICWN’03, 2003.

[41] Wi-Fi. http://www.wi-fi.org/.

[42] Matthew Gast. 802.11 Wireless Networks: The Definitive Guide. O´Reilly, 2002.

[43] Kismet Security Tool for WLANs. http://www.kismet.net/.

[44] Daniel de O. Cunha, Luıs Henrique M. K. Costa, and Otto Carlos M. B. Duarte. Umaanalise do consumo de energia em redes ad hoc. In Anais do V Workshop de Comunicacaosem Fio, 2003.


[45] GPL. http://www.gnu.org/copyleft/gpl.html.

[46] Intersil. http://www.intersil.com.

[47] Agere. http://www.agere.com.

[48] Absolute Value Systems Linux-WLan Project. http://www.linux-wlan.com/.

[49] Intimate Linux. http://intimate.handhelds.org/.

[50] Theodoros Salonidis, Pravin Bhagwat, Leandors Tassiulas, and Richard LaMaire. Distri-buted topology construction of bluetooth personal area network. Infocom 2001, 2001.

[51] Ivana Maric. Connection establishment in the bluetooth system. Master’s thesis, The StateUniversity of New Jersey, WINLAB, October 2000.

[52] Bluez. Bluez official linux bluetooth protocol stack.

[53] Ether Real Network Analyzer. http://www.ethereal.com/.

[54] Ericsson. ROK 101 007 Bluetooth Module Data sheet. Ericsson, 2001.

[55] Ericsson. ROK 101 008 Bluetooth PtP Module Data sheet. Ericsson, 2001.

[56] Ericsson. Ericsson hci implemented features and limitations for baseband. Technical report,Ericsson, 2001.

[57] CSR Cambridge Silicon Radio. http://www.csr.com.

[58] RDF. Resource discovery protocol (rdf). http://www.w3.org/RDF/.

Documents

Ricardo Augusto Rabelo Oliveira Uma API para Integrac‚aoŸ