Um Protocolo para Gerência de Handoff em Redes PESSOAIS Sem FIo PDF

Universidade Federal de Campina Grande
Centro de Engenharia Eltrica e Informtica

Coordenao de Ps-Graduao em Informtica
Dissertao de Mestrado
Um Protocolo para Gerncia de Handoff em Redes

Pessoais Sem Fio para Aplicaes de Tempo-Real
Loreno Feitosa de Oliveira
Campina Grande, Paraba, Brasil

c
Loreno
Feitosa de Oliveira, Agosto de 2007
Universidade Federal de Campina Grande

Centro de Engenharia Eltrica e Informtica
Coordenao de Ps-Graduao em Informtica
Um Protocolo para Gerncia de Handoff em Redes

Pessoais Sem Fio para Aplicaes de Tempo-Real
Loreno Feitosa de Oliveira
Dissertao submetida Coordenao do Curso de Ps-Graduao em

Cincia da Computao da Universidade Federal de Campina Grande Campus I como parte dos requisitos necessrios para obteno do grau
de Mestre em Cincia da Computao.
rea de Concentrao: Cincia da Computao

Linha de Pesquisa: Engenharia de Software
Angelo Perkusich, DSc.

(Orientador)
Leandro Dias da Silva, DSc.
(Orientador)
Campina Grande, Paraba, Brasil

c
Loreno
Feitosa de Oliveira, Agosto de 2007
O48p
2007
Oliveira, Loreno Feitosa de.

Um Protocolo para Gerncia de Handoff em Redes Pessoais Sem Fio para Aplicaes de Tempo-Real / Loreno Feitosa de Oliveira. - Campina Grande, 2007.
115f: il. color.
Dissertao (Mestrado em Cincia da Computao), Universidade Federal de

Campina Grande, Centro de Engenharia Eltrica e Informtica.
Referncias.
Orientadores: Dr. Angelo Perkusich, Dr. Leandro Dias da Silva.
1. Embutido (embedded). 2. Tempo-Real. 3. Camada Fsica. 4. Handoff.

5. Computao Pervasiva. 6. Computao Ubqua. 7. Computao Mvel. 8.
Multimdia. I. Ttulo.
CDU 004.031.43/.6(043)
Resumo
Redes pessoais sem fio, WPANs (Wireless Personal Area Networks), so redes de curto alcance, em torno de
10 m, cujo centro o usurio. O cenrio de uso geral aquele onde dispositivos dentro da rea de cobertura
da WPAN comunicam-se diretamente entre si ou com recursos do mundo exterior (recursos fora da WPAN)
atravs de pontos de acesso que ofeream esse tipo de encaminhamento de dados.
WPANs vm ganhando ateno nos ltimos anos principalmente devido ao surgimento de novas tecnologias de transmisso sem fio que viabilizam este tipo de rede, particularmente Bluetooth. De fato, o desenvolvimento das WPANs confunde-se com o desenvolvimento do Bluetooth, que tem sido usado como ponto de
partida em diversos estudos e prottipos nesta rea. Sendo a mobilidade de usurios a principal caracterstica
das WPANs, um nmero de questes surge quando se pensa no desenvolvimento de aplicaes direcionadas
para esse novo paradigma. Uma das principais se refere gerncia de handoff. Handoff o processo pelo qual
conexes, rotas de dados, e estados associados proviso de algum servio so transferidos entre pontos de
acesso medida que o usurio se move entre suas reas de cobertura.
Apesar de seu alinhamento com o modelo de rede das WPANs, Bluetooth no possui facilidades para o
gerenciamento de handoffs alm de suas operaes padro para localizao e conexo com dispositivos prximos; inquiry e paging respectivamente. Adicionalmente, o trfego de dados dessas operaes pela interface
Bluetooth possui prioridade sobre o trfego de dados das aplicaes do usurio. Essa caracterstica possui
especial impacto sobre um tipo particular de aplicaes: aquelas que demandam transferncias de dados em
tempo-real, como aplicaes de streaming. Ao tornar o canal sem fio indisponvel para o trfego de dados, seja
pela temporria perda total de conexo com pontos de acesso durante handoffs ou por preempo da interface
para as operaes citadas, aplicaes de tempo-real tm seus desempenhos comprometidos devido quebra de
requisitos temporais associados s suas trocas de dados.
Nesse contexto, neste trabalho proposto um protocolo para gerncia de handoffs em WPANs Bluetooth.
O protocolo apresentado voltado para o uso com aplicaes que demandam transferncias de dados em
tempo-real, sendo demonstrada nesse trabalho sua adequao para esse tipo de aplicao. O protocolo apresentado foi projetado levando-se em considerao as limitaes dos potenciais dispositivos clientes (pequenos
dispositivos mveis com pouco poder de processamento, pouca memria, largura de banda restrita, etc). Assim, so transferidas para os pontos de acesso todas as atividades relativas s transies entre pontos de acesso
dos dispositivos mveis. O protocolo apresentado descarta ainda a necessidade de sinalizaes ou quaisquer
outras trocas de mensagens entre dispositivos mveis e pontos de acesso durante os handoffs. Por utilizar
apenas operaes padronizadas do Bluetooth, viabiliza-se seu uso junto com qualquer dispositivo programvel
equipado com interface Bluetooth de acordo com a especificao, sendo portanto dispensada a necessidade de,
por exemplo, modificar a pilha Bluetooth dos dispositivos.
ii
Abstract
Wireless personal area networks (WPANs), are a mobile short range wireless network, with typical range of
10 meters, where the user is the center. The general usage scenario is where devices within the WPANs range
communicate directly to each other or with resources from the external world (outside the WPAN) through
access points which offer routing service.
WPANs have been gaining attention over the last few years mainly due the emergence and popularization
of novel wireless communication technologies that enable this kind of network, notably Bluetooth. In fact, the
development of WPANs is closely related to the development of Bluetooth, which has been used as starting
point to several studies and prototypes in this field. As the user mobility is the main feature of WPANs,
a number of questions arise when developing applications targeted to this new paradigm. One of the most
important refers to the handoff management. Handoff is the process through which network connections,
routes, and states associated to services in course are seamlessly transferred between access points as the user
moves through their coverage areas.
Despite its alignment with the WPANs network model, Bluetooth has no facilities for aiding the management of handoffs besides its standard operations for querying nearby devices and connect to them, inquiry
and paging respectively. Moreover, the data traffic of these operations has priority over user applications data
traffic. This property has special impact for a particular kind of application: those that require real-time data
transfer, such as streaming applications. When the wireless channel is unavailable for data transfers, with temporary connection loss with access points during handoffs, or interface preemption for the inquiry and paging
operations, real-time applications have their performance compromised in consequence of violation of temporal
requirements.
In this work, a protocol for managing handoffs in Bluetooth-based WPANs is presented. The protocol is
focused on the use of applications that demand real-time data transfers. The adequacy of the protocol to this
kind of application is analyzed through a case study for an audio streaming application. The protocol is designed focusing on the limitations of potential client devices (small portable devices with limited computational
power, memory, bandwidth, battery life, etc). Therefore, all the handoff management operations are transferred
to access points. There is no need of signaling or any other kind of coordination or message exchange between
access points and mobile devices during handoffs. Due to the use of standardized Bluetooth operations, any
programmable device with a standard complaint Bluetooth interface can be used without changes on any underlying software layer, such as the Bluetooth stack. It is also presented a formal modelling and validation of
the protocol to ensure it behaves according to its specification. The formal model is important to understand
the protocol, unanbiguous documentation, and to easy the validation of changes and extension by automatic
simulation and proof of properties.
iii
Agradecimentos
Deus, por me dar a fora necessria para continuar em frente mesmo nos momentos de maior
dificuldade.
Aos meus pais, Evando e Zlia, por todos esforos para me proporcionar uma educao de qualidade. Agradeo a eles por todas as oportunidades dadas, pela compreenso por minhas ausncias
durante o mestrado, pelos ensinamentos, cobranas, incentivo, e confiana.
Aos meus orientadores, Angelo e Leandro, pelo incentivo, apoio, pelas discusses enriquecedoras, pela pacincia diante de minhas dificuldades, pela sabedoria da orientao, e pelos recursos
disponibilizados.
minha namorada, Ana Emlia, por todo seu apoio, suas palavras de incentivo, pela ajuda com
assuntos administrativos aps minha mudana de cidade, por sua compreenso nos momentos difceis
e por dividir comigo as conquistas e momentos felizes. Te agradeo muito por compreender minhas
ausncias durante este longo caminho.
Aos meus colegas de trabalho, e superiores em diferentes momentos, Rmulo, Yuri, e Juliana,
por compreender a minha dificuldade de conduzir um trabalho de mestrado distncia. Os agradeo
por todos os incentivos para que eu pudesse cumprir com minhas obrigaes acadmicas.
todos os amigos que, de alguma forma, me incentivaram ou me deram fora nos momentos
mais problemticos, especialmente os amigos de apartamento Aliandro, Danilo, e toda a turma do
projeto Mercosul na Dataprev.
s pessoas do laboratrio Embedded, em particular a turma da sala do projeto COMPOR,
Glauber, Fred, Milena, Hyggo, Emerson e Leandro Sales, que faziam daquela sala uma das mais
divertidas do laboratrio. Um agradecimento especial para Kyller, por sua valorosa ajuda com a
modelagem em CPN, e a Danilo e Marcus Morais, por todas as suas dicas e palpites sobre meus
problemas e dvidas sobre Bluetooth.
Ao grande guru Odilon, por todas as dicas e lies sobre C++. Dificilmente eu teria conseguido
implementar o prottipo usado nos testes sem a assistncia desse experiente programador e sbio
profissional.
s pessoas que compem a COPIN, em particular Aninha, pessoa espetacular, amiga, compreensiva, atenciosa e prestativa.
iv
Contedo
1
Introduo
1.1
Problemtica e Relevncia da Pesquisa . . . . . . . . . . . . . . . . . . . .
1.2
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3
Estrutura da Dissertao . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fundamentao Terica
2.1
Computao Pervasiva . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
Tecnologias para Transmisso Sem Fio . . . . . . . . . . . . . . . . . . . .
12
2.2.1
WPANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.3
Gerncia de Handoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.4
Aplicaes de Tempo-Real . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.4.1
Aplicaes de Streaming . . . . . . . . . . . . . . . . . . . . . . .
19
Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.5.1
Estabelecendo Conexes Baseband . . . . . . . . . . . . . . . . .
25
2.5.2
A Operao de Inquiry . . . . . . . . . . . . . . . . . . . . . . . .
25
2.5.3
A Operao de Paging . . . . . . . . . . . . . . . . . . . . . . . .
27
2.5.4
Inquiry e Paging X Trfego de Dados em Tempo-Real . . . . . . .
29
2.5
Gerenciando Handoffs para Bluetooth no Contexto de Aplicaes de TempoReal

3.1
3.2
33
Viso Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.1.1
Estados de um DM . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.1.2
O Registro de um DM . . . . . . . . . . . . . . . . . . . . . . . .
35
Gerncia de Handoff - Transies entre EBs . . . . . . . . . . . . . . . . .
37
CONTEDO
3.2.1
Monitorando DMs . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.2.2
Atribuindo Responsabilidades e Configurando Operaes . . . . . .
40
3.3
Gerncia de Handoff - Mantendo Contato com DMs . . . . . . . . . . . .
48
3.4
Discusses Adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
Avaliao da Soluo
57
4.1
Transies entre EBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
4.1.1
O Ambiente de Testes . . . . . . . . . . . . . . . . . . . . . . . .
58
4.1.2
Cenrios de Testes . . . . . . . . . . . . . . . . . . . . . . . . . .
62
Validao do Protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
4.2.1
Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
4.2.2
Validao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
4.2
vi
Consideraes Finais
75
5.1
Concluses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
5.2
Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
5.2.1
Definio de uma Soluo Escalvel . . . . . . . . . . . . . . . . .
78
5.2.2
Integrao com Mecanismos de Mobilidade de Aplicaes . . . . .
79
5.2.3
Localizao e Monitorao dos Estados de Dispositivos . . . . . .
79
5.2.4
Mtodos e Modelos para Calibrao do Sistema . . . . . . . . . . .
80
A Escolhendo Valores para os Parmetros do Paging
90
B Aplicaes
96
B.1 Reproduo de udio e/ou Vdeo em Movimento . . . . . . . . . . . . . .
96
B.2 Visitas Guiadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
B.3 VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
B.4 Push to Talk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
C Escalabilidade e Qualidade de Servio
100
C.1 Os Gargalos de Escalabilidade . . . . . . . . . . . . . . . . . . . . . . . .
100
C.2 Definindo um Sistema Escalvel . . . . . . . . . . . . . . . . . . . . . . .
102
C.2.1
As Estaes Base . . . . . . . . . . . . . . . . . . . . . . . . . . .
104
CONTEDO
vii
C.2.2
Os Dispositivos Clientes . . . . . . . . . . . . . . . . . . . . . . .
105
C.2.3
As Aplicaes Finais . . . . . . . . . . . . . . . . . . . . . . . . .
106
C.2.4
Controle de Admisso . . . . . . . . . . . . . . . . . . . . . . . .
107
C.3 Ilustrando o Funcionamento do Novo Sistema . . . . . . . . . . . . . . . .
109
C.3.1
Entrando no Sistema . . . . . . . . . . . . . . . . . . . . . . . . .
109
C.3.2
Iniciando Transmisses . . . . . . . . . . . . . . . . . . . . . . . .
111
C.3.3
Handoff no Nvel da Aplicao . . . . . . . . . . . . . . . . . . .
114
C.4 Discusses Adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . .
114
Lista de Figuras
2.1
Relacionamento entre a computao pervasiva e as reas de sistemas distribudos e computao mvel (adaptado do trabalho de Mahadev Satyanarayanan em [58]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.2
Redes pessoais sem fio - WPANs . . . . . . . . . . . . . . . . . . . . . . .
14
2.3
Pilha padro Bluetooth. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.4
Impacto do inquiry num fluxo de 400 Kbps. . . . . . . . . . . . . . . . . .
30
2.5
Impacto do paging num fluxo de 400Kbps. . . . . . . . . . . . . . . . . . .
31
2.6
Impacto do inquiry scan num fluxo de 400Kbps. . . . . . . . . . . . . . . .
32
2.7
Impacto do page scan num fluxo de 400Kbps. . . . . . . . . . . . . . . . .
32
3.1
Viso geral do sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.2
Estados e transies de estados associados a DMs. . . . . . . . . . . . . . .
35
3.3
Registros de DMs e suas informaes. . . . . . . . . . . . . . . . . . . . .
36
3.4
Principais entidades lgicas das EBs. . . . . . . . . . . . . . . . . . . . . .
37
3.5
Localizao de dispositivos Bluetooth. . . . . . . . . . . . . . . . . . . . .
38
3.6
Atribuies dos papis de mestre e escravo (adaptado do trabalho de Aman

Kansal em [30]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7
41
Desempenho da operao de paging com diferentes parmetros (extrada do

trabalho de Ming-Chiao Chen et al. em [11]). . . . . . . . . . . . . . . . .
44
3.8
Mantendo o DM conectado durante movimentao. . . . . . . . . . . . . .
51
4.1
Viso geral da estrutura criada para testes. . . . . . . . . . . . . . . . . . .
58
4.2
Estrutura lgica das EBs implementadas para testes. . . . . . . . . . . . . .
60
4.3
Dados de referncia da transmisso do stream de 320 Kbps para o DM, sem

handoff. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
viii
64
LISTA DE FIGURAS
ix
4.4
Dados sobre a chegada dos pacotes RTP aps ajuste dos parmetros do paging. 65
4.5
Dados da transmisso do stream de 320 Kbps para o DM durante handoff. .
4.6
Dados da transmisso do stream de 320 Kbps para o DM durante handoff
66
usando interface CSR. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
4.7
Modelo CPN para o protocolo de handoff entre EBs. . . . . . . . . . . . .
69
4.8
Diagrama de seqencia para exemplo ilustrado na Figura 3.8. . . . . . . . .
72
A.1 Avaliaes para page scan window = 18 slots . . . . . . . . . . . . . . . .
92
A.2 Avaliaes de valores para page scan window = 36 slots . . . . . . . . . . .
93
A.3 Avaliaes de valores para page scan window = 54 slots . . . . . . . . . . .
94
C.1 Registro de EBs com informaes sobre streams em curso. . . . . . . . . .
102
C.2 Nova organizao lgica do sistema. . . . . . . . . . . . . . . . . . . . . .
103
C.3 Interfaces de Proviso de Servio (IPSs) e Interfaces de Ponto de Entrada

(IPEs). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
104
C.4 Fluxograma com as etapas para entrada de DMs no sistema. . . . . . . . .
110
C.5 Etapas para iniciar a recepo de streams. . . . . . . . . . . . . . . . . . .
112
C.6 Etapas para iniciar a transmisso de streams. . . . . . . . . . . . . . . . . .
113
Lista de Tabelas
2.1
Resumo das principais caractersticas das principais tecnologias para WPANs. 15
3.1
Comandos HCI usados. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
3.2
Registros das EBs aps entrada de DM1 no sistema. . . . . . . . . . . . . .
52
3.3
Registros das EBs aps mudana de estado de DM1 para SOB_HANDOFF.
52
3.4
Estados dos registros da EBs antes e depois do repasse da mensagem de

EBE por EBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
3.5
Registros das EBs aps transio de DM1 de EBD para EBB . . . . . . . .
54
3.6
Registros das EBs aps transio de DM1 de EBB para EBC . . . . . . . .
54
3.7
Registros das EBs aps mudana de estado de DM1 de SOB_HANDOFF

para CONECTADO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
Resumo das caractersticas dos dispositivos usados para testes. . . . . . . .
59
A.1 Resumo dos resultados dos testes com diferentes parmetros para o paging.
95
4.1
Lista de Algoritmos
3.1
Monitorando mudanas de estado em DMs. . . . . . . . . . . . . . . . . .
39
3.2
Atualizando registros de DMs . . . . . . . . . . . . . . . . . . . . . . . .
48
C.1 Escalonando requisies de handoff . . . . . . . . . . . . . . . . . . . . .
108
C.2 Escolhendo IPS durante handoff. . . . . . . . . . . . . . . . . . . . . . . .
109
xi
Captulo 1
Introduo
Em 1991 Mark Weiser exps ao mundo sua viso do que seria a computao no sculo
XXI [74], originalmente chamada de computao ubqua e hoje mais conhecida como computao pervasiva [57]. Weiser vislumbrou um mundo no qual diferentes tecnologias estariam embarcadas em objetos do dia a dia como roupas, eletrodomsticos e automveis,
criando assim ambientes inteligentes onde esses objetos seriam capazes de colaborar entre si
para oferecer servios personalizados s pessoas.
As idias de Weiser eram, entretanto, avanadas demais para a poca na qual foram
inicialmente concebidas, considerando a disponibilidade de hardware e software daquela
poca. Em 1991, os dispositivos computacionais disponveis eram grandes demais, caros
demais e com pouco poder de processamento e armazenamento, se comparados aos dispositivos disponveis atualmente. Estes eram, sem dvida, obstculos realizao da computao
pervasiva. Alm disso, outras restries tecnolgicas tais como a ausncia de redes sem fio,
baterias com baixa autonomia e ausncia de softwares adequados [25], tornavam impossvel
a concretizao das idias de Weiser.
Porm, os avanos tecnolgicos dos ltimos anos proporcionaram a miniaturizao
de componentes eletrnicos, possibilitando o desenvolvimento de dispositivos cada vez
menores, ao mesmo tempo que o poder dos processadores aumenta a cada nova gerao.
O espao de armazenamento dos computadores aumentou de poucos kilobytes em 1991 para
centenas de gigabytes, comuns hoje em dia. Baterias para dispositivos mveis tornaram-se
menores e com maior autonomia. Tecnologias para comunicao sem fio como Wi-Fi [72]
e Bluetooth [64] surgiram e amadureceram, enquanto novas tecnologias como ZigBee [79] e
1
2
WiBree [75], continuam a surgir. Essa evoluo veio acompanhada da gradual reduo dos
custos de desenvolvimento e produo em massa de dispositivos que utilizam essas tecnologias, tornando-os mais acessveis e cada vez mais presentes na sociedade. Graas a essas
novas tecnologias, dispositivos como sensores, telefones celulares, smartphones, notebooks,
Internet Tablets, e PDAs 1 , surgiram e/ou evoluram desde 1991. Esses dispositivos so hoje
as peas centrais para a concretizao da computao pervasiva.
Paralelamente ao desenvolvimento da computao pervasiva, um novo paradigma de
rede, focado na comunicao sem fio de curto alcance, vm atraindo pesquisadores e indstria nos ltimos anos. Redes pessoais sem fio [49], WPANs (Wireless Personal Area
Networks), so redes de curto alcance, em torno de 10 m, cujo centro o usurio. O
cenrio de uso geral aquele onde dispositivos dentro da rea de cobertura da WPAN possam comunicar-se diretamente entre si ou com recursos do mundo exterior (recursos de fora
da WPAN) atravs de dispositivos que ofeream esse encaminhamento de dados. Possveis
aplicaes para WPANs incluem monitorao mdica [29; 28], ambientes inteligentes [45;
12], e entretenimento [33].
A pesquisa em torno de WPANs intercala-se com o desenvolvimento do Bluetooth. De
fato, o Bluetooth tm sido o ponto de partida para diversos estudos e prottipos no contexto de WPANs [27; 26]. Originalmente desenvolvido para substituir cabos na troca de
dados de curto alcance entre dispositivos, o Bluetooth est cada vez mais presente em
dispositivos eletrnicos. Dentre as razes que o tornam, atualmente, a tecnologia ideal
para o desenvolvimento de WPANs pode-se citar seu baixo consumo de energia, baixo
preo, e presena de mercado. Sendo a mobilidade de usurios a principal caracterstica das WPANs, e dadas as caractersticas dos potenciais dispositivos clientes (pequenos
dispositivos mveis com pouca capacidade de processamento, pouca memria, largura
de banda restrita, etc), um nmero de dificuldades so identificadas quando se pensa no
desenvolvimento de aplicaes direcionadas para WPANs [49], como por exemplo [43;
44]:
dispositivos clientes, ainda, com diversas restries computacionais e de usabilidade;
adequao de protocolos e formatos de dados para uso com tais dispositivos;
1
Personal Digital Assistant
3
ambientes com mudanas constantes na oferta de servios, sejam estas na disponibilidade de algum servio ou na sua qualidade;
intermitncias na conexo entre provedor e consumidor dos servios, devido movimentao dos dispositivos cliente, e a eventual necessidade de aplicaes poderem
lidar com esses perodos de queda de conexo;
para servios mais complexos, transferncia transparente de servios entre diferentes
pontos de acesso sem fio medida que usurios se movem atravs de suas reas de
cobertura (gerncia de handoff );
segurana e privacidade para dados trocados via conexes sem fio e para o acesso/uso
de informaes sobre o perfil dos usurios;
necessidade de adaptar contedo em tempo de execuo devido heterogeneidade de
dispositivos e/ou mudanas que possam impactar na qualidade do servio oferecido;
tirar proveito da alta disponibilidade de recursos das redes cabeadas, como conexes de
rede mais velozes, espao de armazenamento e capacidade computacional, em benefcio dos pequenos dispositivos mveis clientes.
Dispositivos mveis dentro da rea de cobertura da WPAN podem comunicar-se diretamente entre si ou com recursos do mundo exterior (recursos fora da WPAN) atravs de pontos de acesso que ofeream esse tipo de encaminhamento de dados. Para um uso contnuo
e transparente dos servios oferecidos pelos pontos de acesso, ou por provedores acessados
atravs destes, faz-se necessria a adequada gerncia de handoff. Handoff o processo pelo
qual conexes, rotas de dados, e estados associados proviso de algum servio so transferidos entre pontos de acesso medida que o usurio se move entre suas reas de cobertura [78;
63]. Gerenciar handoffs significa prover os meios pelos quais essas trocas de ponto de
acesso so tornadas transparentes para usurios finais e/ou aplicaes mais altas na pilha
de software.
Solues para gerenciamento de handoffs so desenvolvidas a partir de pilares como:
i) caractersticas da tecnologia de rede sem fio utilizada, e ii) caractersticas/requisitos das
aplicaes e casos de uso finais. Ou seja, o projeto de uma soluo para gerncia de handoffs pode ser mais ou menos rduo conforme a prpria tecnologia de rede sem fio oferea
1.1 Problemtica e Relevncia da Pesquisa
ou no facilidades para o processo de handoff, por exemplo, suporte para medida precisa da
localizao de dispositivos ou reserva antecipada de recursos no novo ponto de acesso. O
projeto de uma soluo para gerenciamento de handoffs fortemente influenciado pelas caractersticas/requisitos das aplicaes finais do sistema. Aplicaes com alguma tolerncia
a eventuais perdas totais de conexo e/ou oscilaes na qualidade da conexo, como e-mail
ou navegao pela web, tendem a no acrescentar muita complexidade soluo final para
gerncia de handoffs. Por outro lado, aplicaes com fortes requisitos quanto disponibilidade de conexo e de sua qualidade trazem complexidade extra ao desenvolvimento da
soluo de handoff. Aplicaes de tempo-real, em especial aquelas que demandam a transferncia de dados via rede em tempo-real (vide Seo 2.4.1), so aplicaes com limites bem
definidos quanto aos intervalos para envios/chegada de dados. Perdas totais de conexo ou
grandes oscilaes na qualidade do canal sem fio tendem a comprometer a eficcia dessas
aplicaes por quebrar requisitos temporais associados s suas trocas de dados. Assim, protocolos bem sucedidos para um determinado cenrio (tecnologia de rede + aplicaes alvo),
podem provar-se inadequados em outros cenrios.
Neste trabalho, o interesse est na gerncia de handoffs entre dispositivos clientes e pontos de acesso em WPANs baseadas em Bluetooth. Mais precisamente, estamos interessados
num protocolo de handoff que viabilize o uso de aplicaes que demandam a troca de dados em tempo-real pelas interfaces Bluetooth. Ao mesmo tempo que esse tipo particular
de aplicao abre caminho para o desenvolvimento de uma srie de novas aplicaes em
ambientes inteligentes, tais quais as descritas no Apndice B, por outro lado aumenta-se
tambm os requisitos sobre a soluo final. Conforme discutido anteriormente, esse trade off
conseqncia das caractersticas desse tipo de aplicao de tempo-real, que demanda o envio/recepo de dados com alguma pontualidade, e so sensveis oscilaes em parmetros
como taxa de perda de dados ou dados fora de tempo.
1.1
Problemtica e Relevncia da Pesquisa
Por ser a mobilidade de usurios e dispositivos a principal caracterstica das WPANs, aplicaes desenvolvidas para esse tipo de ambiente devem ser, desde seu projeto, preparadas
para lidar com problemas relacionados com a constante intermitncia na disponibilidade de
1.1 Problemtica e Relevncia da Pesquisa
recursos. Intermitncias na disponibilidade de recursos incluem, por exemplo, a entrada e

sada de dispositivos na WPAN, levando ou trazendo consigo servios de interesse de outros dispositivos da rede sem fio. A forma de se lidar com essa caracterstica das WPANs
depende dos requisitos das aplicaes finais. Enquanto algumas aplicaes, como e-mail
ou sincronizao de dados, tendem a ser mais tolerantes falta de conexo com a Internet
ou redes locais, aplicaes baseadas na troca de dados em tempo-real, como aplicaes de
streaming (Seo 2.4.1), podem ter seus desempenhos fortemente comprometidos diante da
falta, mesmo que temporria, de conexo com redes externas. Para aplicaes cujos requisitos se encaixem no segundo caso, o suporte de um protocolo de handoff requisito para seu
funcionamento adequado em WPANs.
Apesar de sua adequao para comunicao ad-hoc e alinhamento com o modelo de
rede das WPANs, Bluetooth foi inicialmente desenvolvido para substituir cabos, provendo
um canal sem fio para a comunicao entre dispositivos prximos. Como tal, no possui
facilidades para o gerenciamento de handoffs alm de suas operaes padro para localizao e conexo com dispositivos prximos (inquiry e paging, respectivamente). Alm disso,
o trfego de dados dessas operaes possui prioridade sobre o trfego de dados das aplicaes pela interface Bluetooth. Ou seja, no contexto de aplicaes de tempo-real, tambm
necessrio ponderar o uso dessas operaes sobre o desempenho das aplicaes. O foco
da ateno no projeto do protocolo de handoff, portanto, est em definir as configuraes e
procedimentos necessrios para a troca de conexes entre pontos de acesso com o mnimo
de impacto sobre o desempenho das aplicaes, particularmente, aquelas que demandam a
troca de dados em tempo-real.
O interesse por protocolos de handoff em Bluetooth no recente, onde propostas tm
sendo publicadas desde 2002 [13; 30; 20; 11; 35; 10; 31; 70], sendo a problemtica em
torno desse tema j discutida pelo menos desde 2000 [69; 3]. Entretanto, dentre as propostas
atualmente conhecidas, nenhuma possui experimentos suficientes para comprovar sua adequao para o uso com aplicaes de tempo-real. Por exemplo, dentre os trabalhos mais
expressivos nessa rea, a proposta de Sang-Hun Chung et al. [13] inclui o uso nos dispositivos mveis de operaes no padronizadas pelo Bluetooth, o que pode tornar invivel sua
implantao nesse tipo de dispositivo. Os trabalhos de Aman Kansal [30] e Ming-Chiao
Chen [11], por outro lado, baseiam-se apenas em operaes padronizadas da tecnologia. En-
1.2 Objetivos
tretanto, no primeiro trabalho o procedimento de handoff apenas disparado aps a perda

total de conexo do dispositivo. Alm disso, os dispositivos mveis precisam estar no modo
contnuo de escuta por tentativas de conexo (vide Sees 2.5.3 e A). Isso significa que o dispositivo tm sua largura de banda comprometida, o que causa impacto direto no desempenho
de aplicaes de tempo-real.
Para evitar a perda total de conexo do dispositivo, na proposta de Ming-Chiao Chen
novas conexes so estabelecidas antes que as anteriores sejam perdidas. Os pontos negativos deste trabalho incluem o papel do dispositivo mvel no procedimento de handoff (estes
dispositivos so responsveis por monitorar a necessidade e disparar processos de handoff ),
e o nmero de conexes simultneas que precisam ser mantidas pelo dispositivo. Ou seja,
de acordo com a soluo descrita, cada dispositivo cliente est conectado ao mesmo tempo
no s em um ponto de acesso especfico, mas neste ponto de acesso e em todos os seus
vizinhos ao mesmo tempo. Esse aumento no nmero de conexes reduz a escalabilidade do
sistema, pois mesmo que no esteja em movimento um dispositivo ocupa recursos de todas
os pontos de acesso prximos. Alm disso, no descrito no trabalho o protocolo pelo qual
dispositivos podem se mover atravs das reas de cobertura dos pontos de acesso enquanto
um fluxo de dados com caractersticas de tempo-real transferido pela interface Bluetooth.
O modelo de movimentao assumido neste trabalho assume um padro de movimento de
usurios simplista onde, uma vez iniciado o procedimento de handoff, o usurio/dispositivo
no mais pode mudar de direo. Comum a todos esses trabalhos o fato de que em nenhum
deles foram apresentadas comprovaes sobre sua eficincia no contexto de aplicaes de
tempo-real.
1.2
Objetivos
O objetivo deste trabalho propor um protocolo de handoff para WPANs baseadas em Bluetooth e demonstrar sua adequao para o uso com aplicaes que demandam a troca de dados
via rede em tempo-real. A soluo final deve levar em considerao a escassez de recursos
dos potenciais dispositivos clientes, evitando portanto sobrecarregar esses dispositivos com
tarefas relacionadas gerncia de handoffs. O protocolo deve, por fim, basear-se apenas em
operaes padronizadas pela especificao do Bluetooth, viabilizando assim seu uso com
1.3 Estrutura da Dissertao
qualquer dispositivo programvel equipado com uma interface Bluetooth padronizada.
1.3
Estrutura da Dissertao
O restante deste trabalho est estruturado da seguinte maneira:

No Captulo 2 so introduzidos os principais temas que norteiam este trabalho.
No Captulo 3 apresentada a proposta deste trabalho para atender os objetivos descritos na Seo 1.2.
Em seguida, no Captulo 4 so des-critos aplicaes, cenrios, modelos, e resultados
de experimentos, usados para a validao do protocolo apresentado no Captulo 3.
Por fim, no Captulo 5 so feitas as consideraes finais sobre o trabalho. So apresentadas as concluses e planos de trabalhos futuros.
Captulo 2
Fundamentao Terica
Neste captulo so introduzidos os principais temas relacionados ao trabalho apresentado
nesta dissertao. Na Seo 2.1 apresentada uma viso geral sobre a computao pervasiva, enquanto na Seo 2.2 so discutidas as principais tecnologias para transmisso sem
fio, com enfoque em WPANs. Os principais conceitos envolvendo handoffs e gerncia de
handoffs so discutidos na Seo 2.3. Aplicaes de tempo-real so introduzidas na Seo
2.4, juntamente com uma discusso sobre aplicaes de streaming devido ao seu particular
alinhamento com o trabalho aqui apresentado. Por fim, na Seo 2.5 feita uma introduo
sobre a tecnologia Bluetooth. So discutidas suas principais caractersticas, funcionamento
das camadas da pilha padro, e as operaes de inquiry e paging (principais funes no
contexto do trabalho apresentado), alm de resultados de experimentos reais que ilustram o
impacto dessas operaes sobre o fluxo de dados em tempo-real.
2.1
Computao Pervasiva
A viso geral sobre a computao pervasiva aquela onde a computao embarcada em

objetos do dia-a-dia, como roupas, cmodos/ambientes, automveis e eletrodomsticos. Juntos, estes objetos e ambientes podem colaborar entre si, atravs da troca de diferentes informaes contextuais, em benefcio das pessoas [74; 58]. Por meio do uso da proatividade, de
informaes atuais sobre o contexto dos usurios e de dados sobre os seus perfis, servios
personalizados podem ser oferecidos s pessoas, no lugar e na hora certos.
A computao pervasiva realiza-se atravs dos ambientes inteligentes, ou ambientes per8
2.1 Computao Pervasiva
vasivos [58; 24]. Estes ambientes so caracterizados pela interao entre dispositivos embarcados, dispositivos mveis, infra-estrutura cabeada e usurios. A forma mais comum, e
mais simples, para usurios interagirem com ambientes inteligentes atravs de dispositivos
mveis pessoais, como PDAs ou smartphones, que podem carregar informaes sobre seus
perfis. Pequenos subconjuntos destas informaes podem ser passados, sem interveno humana, para provedores de servios em ambientes pervasivos assim que o usurio se aproxima
ou entra no ambiente. De posse dessas informaes, estes provedores podem ento adequar
seus servios aos desejos/necessidades de cada usurio [53]. Alternativamente, o prprio
ambiente pode j conhecer as preferncias dos seus usurios, e apenas consult-las quando a
presena de algum conhecido percebida atravs de sensores [59]. Independente de como
ambientes inteligentes tomam cincia dos perfis dos usurios ou como eles detectam suas
presenas, o princpio bsico da computao pervasiva tornar a computao invisvel
percepo humana, ou pelo menos torn-la pouco evidente. Em outras palavras, usurios
devem se beneficiar de decises tomadas por estes ambientes sem que para isso precisem ser
consultados a todo momento sobre o que eles gostariam, e como gostariam, que o ambiente
fizesse algo por eles [58].
A computao pervasiva possui um forte relacionamento ancestral com, pelo menos,
duas outra reas da computao [57]: sistemas distribudos e computao mvel. Vrios
dos problemas com os quais a computao pervasiva precisa lidar podem ser mapeados em
problemas j identificados e estudados nestas reas. Da rea de sistemas distribudos herdado todo o conhecimento para lidar, por exemplo, com comunicao remota, tolerncia a
falhas, alta disponibilidade de recursos, acesso remoto a informaes e segurana. Da computao mvel aproveitam-se, por exemplo, as experincias em acesso a redes cabeadas via
dispositivos mveis, sistemas projetados para economizar energia de baterias e localizao
de dispositivos mveis.
Entretanto, mesmo aproveitando solues desenvolvidas em anos de pesquisas nestas
reas, pesquisadores da rea de computao pervasiva ainda precisam resolver problemas
inerentes aos objetivos deste novo paradigma. Tornar-se uma tecnologia que desaparece
requer que a computao pervasiva se integre na vida das pessoas de tal maneira que estas
continuem desempenhando suas tarefas corriqueiras, desta vez assistidas por algum sistema
computacional, mas sem alterar a forma como as tarefas eram realizadas antes, sem auxlio
10
computacional. Ou seja, os sistemas computacionais se adaptam s pessoas, e no o contrrio. A partir do momento que movimento parte integral da vida cotidiana das pessoas,
tais sistemas precisam dar suporte mobilidade de seus usurios. Caso contrrio, usurios
vo tomar cincia da tecnologia assim que perceberem sua ausncia ao se moverem de um
cmodo para outro, por exemplo.
Dentre os novos problemas com os quais a computao pervasiva precisa lidar, podem
ser destacados [57]:
Escalabilidade
medida que ambientes inteligentes tornam-se mais sofisticados, a quantidade de
interao entre os dispositivos mveis dos usurios e os ambientes tende a aumentar.
Isto traz diversas implicaes para os projetos de tais sistemas; e.g., largura de banda
limitada, consumo de energia e capacidade de absoro de clientes. O problema tornase mais complicado quando considera-se um nmero cada vez maior de usurios nestes
ambientes.
Heterogeneidade
Dispositivos mveis modernos so extremamente diferentes entre si tanto em termos
de configurao quanto em termos de recursos. Eles podem ter telas de diferentes
tamanhos, com resolues e nmero de cores distintos. Estes dispositivos podem
ainda diferenciar-se pelo tipo de tecnologia sem fio usada, capacidade de processamento, quantidade de memria, mtodo de entrada, sistema operacional e plataforma
de hardware. Criar sistemas capazes de lidar com tamanha heterogeneidade de dispositivos clientes pode ser uma tarefa rdua a depender das caractersticas do servio
anunciado. Por exemplo, provedores de servios que necessitem instalar nos dispositivos mveis alguma aplicao cliente especfica, provavelmente tero que lidar com
diferentes verses da mesma aplicao cliente, como forma de lidar com a heterogeneidade dos clientes em potencial, o que pode tornar proibitiva a implantao de tal
servio [32].
Invisibilidade
No cenrio ideal vislumbrado por Weiser a computao se torna invisvel percepo
11
humana. Na prtica, atualmente, o que se buscam so sistemas que requerem um mnimo de interveno/distrao humana para realizarem seu trabalho. Humanos podem,
eventualmente, intervir em decises tomadas por algum sistema como forma de calibrar o sistema para uma determinada situao/condio. Entretanto o que se procura
so maneiras pouco intrusivas para a disponibilizao e ajuste de servios. Para atender
continuamente s expectativas das pessoas, ambientes e objetos devem ser capazes de
se auto-ajustarem sem a necessidade de exigirem a ateno das pessoas. Auto-ajustes
e auto-aprendizado podem ser implementados em diferentes nveis. Por exemplo, dispositivos com conexo sem fio podem se auto-configurar quando na presena de algum
ponto de acesso. Isso retira do usurio a tarefa maante de buscar pontos de acesso,
definir endereo de rede, mascaras de rede e gateways padro, por exemplo.
Cincia e Gerncia de Informaes sobre o Contexto
Outro requisito bsico da computao pervasiva a necessidade de ambientes inteligentes perceberem informaes contextuais e raciocinarem sobre elas de maneira
proativa. Esta capacidade de percepo, ou cincia de contexto [16], uma caracterstica intrnseca de ambientes inteligentes. Mas implementar esse tipo de percepo
traz uma sria de complicaes, tais como: localizao de dispositivos e usurios,
processamento de informaes em tempo-real, e mesclagem de dados vindos de diferentes fontes (e.g. sensores e perfis). Decises tomadas automaticamente em ambientes inteligentes devem ser precisas e baseadas em dados atuais, caso contrrio os
erros cometidos podem implicar na distrao dos usurios.
Na Figura 2.1 ilustrado o relacionamento entre a computao pervasiva e as reas de
sistemas distribudos e computao mvel. Na figura no expressa a relao temporal entre
as reas, mas sim ligaes lgicas. A computao pervasiva beneficiou-se de diversas experincias previamente adquiridas nos campos da computao mvel e sistemas distribudos. A
computao mvel, por sua vez, tambm aproveitou conhecimentos adquiridos pela pesquisa
em torno de sistemas distribudos. O que o smbolo multiplicador da figura quer dizer que
a complexidade das solues para os mesmos problemas aumenta medida que estas so
adaptadas para novos requisitos, que no existiam quando as solues foram originalmente
aplicadas.
2.2 Tecnologias para Transmisso Sem Fio

Comunicao Remota
Tolerncia a Falhas
Alta Disponibilidade
Acesso Remoto a Informaes
Segurana
Sistemas
Distribudos
Acesso Mvel a Redes

Acesso Mvel a Informaes
Aplicaes Adaptativas
Economia de Energia
Localizao
12
Computao
Mvel
Computao
Pervasiva
Escalabilidade
Heterogeneidade
Invisibilidade
Cincia e Gerncia de Contexto
Figura 2.1: Relacionamento entre a computao pervasiva e as reas de sistemas distribudos

e computao mvel (adaptado do trabalho de Mahadev Satyanarayanan em [58])
2.2
Tecnologias para Transmisso Sem Fio
Existe atualmente uma grande diversidade na oferta de tecnologias para comunicao sem
fio, cada uma com suas prprias caractersticas e limitaes e voltadas para um nicho de
mercado especfico. Tecnologias sem fio vm sendo empregadas para diversas finalidades,
como conectar computadores, monitorao de ambientes, troca oportunstica de dados, e
telefonia, para citar algumas. Devido incessante demanda da sociedade por novos servios,
servios personalizados, melhor desempenho e melhor qualidade na comunicao sem fio,
a pesquisa em tecnologias para troca de dados sem fio atinge novos patamares a cada nova
tecnologia anunciada.
Como os diferentes usos de tecnologias sem fio podem sugerir (telefones sem fio, telefonia celular, redes metropolitanas sem fio, redes sem fio pessoais, etc), cada tecnologia
direcionada para conjuntos bem definidos de aplicaes. Adquirir e implantar uma infraestrutura GPRS 1 , por exemplo, com certeza no a melhor soluo para o usurio domstico
que quer compartilhar acesso Internet entre os computadores de sua residncia. Portanto,
desde seu projeto, cada nova tecnologia foca as necessidades e caractersticas dos cenrios
de uso finais, como aplicaes, ambiente, e requisitos no funcionais. Durante essa fase de
projeto, provavelmente o primeiro aspecto a ser levado em considerao na especificao de
1
General Packet Radio Service [22]
13
uma nova tecnologia de rede sua abrangncia. Nesse contexto, as principais tecnologias
para transmisso sem fio podem ser classificadas em trs categorias [72]: redes de longo alcance sem fio (Cellular Systems); redes locais sem fio (WLANs 2 ); e redes pessoais sem fio
(WPANs 3 ). Redes celulares so bem conhecidas do pblico desde o incio de sua popularizao na dcada de 80. Elas lidam, essencialmente, com o trfego de voz e so direcionadas
para telefonia [22]. Antenas de redes celulares podem atender clientes que estejam num raio
de dezenas de quilmetros. WLANs podem ser vistas como extenses das j conhecidas
redes locais, LANs, onde a troca de informaes entre um subconjunto dos nodos da rede
acontece via ondas de rdio, ao invs de cabos. Comumente, o alcance de redes WLAN
gira em torno das dezenas de metros para ambientes internos e centenas de metros para ambientes externos. Por fim, por estarem no foco deste trabalho, as WPANs sero discutidas
separadamente a seguir, na Seo 2.2.1.
2.2.1
WPANs
Redes pessoais sem fio, WPANs [50], so um conceito razoavelmente recente. Apesar de, por
exemplo, o IEEE trabalhar na normatizao de redes WPAN desde 1999 [72], apenas mais
recentemente as discusses sobre esse tema tomaram fora. O principal fator motivador para
essa quebra de inrcia foi a popularizao do Bluetooth em diferentes dispositivos, desde
simples celulares computadores de mesa. Alm disso, o modelo de rede das WPANs
tambm possui uma boa relao com requisitos da computao pervasiva, que tambm vm
atraindo atenes e ganhando espao nos ltimos anos [58].
Redes WPAN so redes de abrangncias ainda menores que redes WLAN, e tm no
usurio o ponto central de uma rea de cobertura de poucos metros (tambm conhecida
como POS, ou Personal Operating Space). medida que o usurio se move, sua rede
WPAN move-se junto com ele (Figura 2.2). A idia geral em torno de WPANs que algum
dispositivo mvel carregado pelo usurio estabelea e desfaa conexes com outros dispositivos dentro de sua POS medida que o usurio se move para mais prximo ou mais distante
destes aparelhos. Tais dispositivos podem incluir tanto dispositivos que estejam fixos no ambiente, como impressoras, cmeras, e computadores de mesa, quanto outros dispositivos que
2
3
Wireless Local Area Networks

Wireless Personal Area Networks
14
tambm se encontram em movimento, como celulares, smartphones, tocadores de msica e

aparelhos de GPS 4 que, por exemplo, podem estar nos bolsos de outras pessoas.
~10m
~10m
Figura 2.2: Redes pessoais sem fio - WPANs

Atualmente, a principal tecnologia usada em WPANs Bluetooth. Devido s suas caractersticas, Bluetooth vem ganhando cada vez mais presena no mercado, onde equipa uma diversidade de equipamentos. Tais equipamentos incluem fones de ouvido, telefones celulares,
telefones VoIP 5 , relgios, auto-falantes, smartphones, PDAs, Internet Tablets, computadores
portteis, perifricos (e.g. teclados e mouses), impressoras, multifuncionais, e automveis,
dentre outros. Algumas caractersticas de Bluetooth que contribuem para essa presena de
mercado incluem:
Largura de banda: As verses 1.1 e 1.2 de Bluetooth possuem largura de banda nominal
de 1 Mbps. As verses mais atuais, 2.0 e 2.1, suportam at 3 Mbps de velocidade
mxima.
Baixo custo: Como Bluetooth nasceu para ser um substituto de cabos, cada par de interfaces
no podem custar muito mais que o cabo que elas substituem.
4
5
Global Positioning System.

Voice over IP.
15
Facilidade de uso: Conectar dois dispositivos via Bluetooth precisa ser to simples quando
ligar as extremidades de um mesmo cabo entre eles.
Baixo consumo de energia: Desde seu projeto Bluetooth foi direcionado para uso com dispositivos mveis que possuem autonomia limitada devido o uso de baterias. Assim,
um objetivo fixo no projeto e evoluo de Bluetooth manter baixo o consumo de
energia.
Hardware leve e pequeno: Como Bluetooth foi desde o inicio projetado para ser incorporado em dispositivos mveis, seu hardware foi pensado para ser leve e pequeno. Desta
forma, dificilmente o desenho de algum produto precisar ser alterado devido a incorporao de Bluetooth.
Confiana na transmisso de dados: A camada de enlace do Bluetooth garante entrega
confivel de dados. Conexes sem fio Bluetooth precisam ser to confiveis quanto
os cabos que elas substituem.
Apesar de sua grande presena no mercado, Bluetooth no a nica opo existente
para implementar WPANs. Outras alternativas com fatias menores do mercado de WPANs,
ou ainda em desenvolvimento, incluem ZigBee [79] e WirelessUSB [77]. Mesmo que direcionadas para o mercado de redes sem fio de curto alcance, tanto ZigBee quanto WirelessUSB destacam-se por possuirem caractersticas significativamente mais sofisticadas que
Bluetooth. As principais caractersticas dessas tecnologias so enumeradas na Tabela 2.1.
Freqncia
Largura
Economia
de
de Ener-
Conexes
gia a
Si-
Banda
Mxima
Alcance
Mximo
multneas
Bluetooth 1.1/1.2
2.4 GHz
1 Mbps
??
10 cm - 100 m
Bluetooth 2.0/2.1
2.4 GHz
3 Mbps
??
10 cm - 100 m
ZigBee
2.4 GHz
259 Kbps
?????
at 30 m
65.535
WirelessUSB
3.1 GHz - 10.6 GHz
480 Mbps
??
at 50 m
127
Quanto mais estrelas maior a economia de energia.
Tabela 2.1: Resumo das principais caractersticas das principais tecnologias para WPANs.
2.3 Gerncia de Handoff
16
ZigBee, por exemplo, sobressai-se pelo seu consumo de energia extremamente baixo em
relao ao Bluetooth, que por sua vez j uma tecnologia com baixo consumo de energia.
Em compensao possui largura de banda bem inferior largura de banda do Bluetooth.
WirelessUSB, por outro lado, possui ampla largura de banda enquanto mantm consumo
de energia prximo ao consumo do Bluetooth. Em resposta a estes avanos de tecnologias
similares, o Bluetooth SIG
vm trabalhando na prxima verso do Bluetooth que, assim
como WirelessUSB, usar a especificao UWB 7 [14] como sua camada de acesso ao meio,
obtendo assim o mesmo desempenho que WirelessUSB. Alm disso, j existem trabalhos
em andamento para a integrao entre Bluetooth e WiBree
[75] como forma de reduzir
o consumo de energia, e largura de banda do Bluetooth para nveis prximos aos nveis
praticados pelo ZigBee.
2.3
Gerncia de Handoff
Mobilidade a caracterstica mais importante em sistemas baseados em tecnologias sem fio.

Handoff o processo pelo qual conexes, rotas de dados e estados associados proviso
de algum servio so transferidos entre pontos de acesso medida que o usurio se move
entre suas reas de cobertura [78; 63]. Freqentemente, o disparo do processo de handoff
iniciado pelo dispositivo mvel quando este atravessa um determinado limite de distncia
entre si prprio e seu atual ponto de acesso, ou ainda atravs de heursticas baseadas na
deteriorao da qualidade do sinal da conexo atual.
Existem diversos critrios de classificao de estratgias de handoff. Um dos principais
classifica os handoffs pelo nmero de conexes simultneas com os pontos de acesso de
origem e de destino no momento de sua troca (hard handoffs x soft handoffs). Em hard
handoffs, tambm conhecidos como quebrar antes de conectar, todas as conexes estabelecidas entre o dispositivo mvel e o ponto de acesso de origem precisam ser fechadas antes
que sejam estabelecidas novas conexes entre o dispositivo e o novo ponto de acesso. Em
6
7
Bluetooth Special Interest Group - Consrcio de fabricantes responsveis pela especificao do Bluetooth.
Ultra Wide Band. Especificao de camada fsica para comunicao de alta velocidade em curtas distn-
cias.
8
Tecnologia complementar ao Bluetooth que especifica um modo ultra econmico de consumo de energia
comparvel ao consumo do ZigBee.
2.3 Gerncia de Handoff
17
soft handoffs, tambm conhecidos como conectar e depois quebrar, conexes simultneas
com os dois pontos de acesso so mantidas e usadas simultaneamente durante a troca. A
probabilidade de perda de dados em hard handoffs maior que em soft handoffs devido
temporria ausncia total de conexo.
O projeto de infra-estruturas que suportem soft handoffs depende do uso de interfaces
de rede que suportem mltiplas conexes simultneas ou da disponibilidade de dispositivos
multimodais 9 [55]. O impacto da perda temporria de conexo com a rede depende do tipo
de aplicao usada nos dispositivos mveis. Aplicaes onde o atraso nas respostas de requisies no compromete seu funcionamento: e.g., navegao pela Internet, ou aplicaes
com uso espordico da conexo, como e-mail, so tolerantes a perdas temporrias de acesso
rede, desde que em seu projeto seu comportamento tenha sido configurado para situaes
assim (e.g., aguardar algum intervalo antes de tentar acessar a rede novamente ao invs de,
por exemplo, acusar algum erro para o usurio e entrar num modo off line). Por outro lado,
so comuns atualmente aplicaes onde a menor interrupo no trfego de dados pode prejudicar mais seriamente seu desempenho; e.g., aplicaes de streaming (vide Seo 2.4.1).
Outra grande classe para classificao de handoffs diz respeito s tecnologias de rede
usadas nos pontos de acesso de origem e de destino (handoffs horizontais x handoffs verticais). Handoffs onde a mesma tecnologia de rede sem fio usada nos dois pontos de acesso
so ditos horizontais: por exemplo, conexo com os dois pontos de acesso via Bluetooth.
Caso as tecnologias de rede envolvidas sejam diferentes, como ponto de acesso de origem
usando Bluetooth e de destino usando Wi-Fi, ento o handoff dito vertical. Classificaes
para Handoffs incluem ainda handoffs controlados pelo ponto de acesso ou pelo dispositivo
mvel (mobile controlled x network controlled) [63], e handoff intra-clula, inter-clula, e
inter-regies (micromobility x macromobility x global mobility) [56].
Existem atualmente diversas abordagens e estratgias para gerenciamento de handoff em
redes de comunicao de dados. Diferentes trabalhos propem suas prprias infra-estruturas,
desenvolvidas a partir de suposies distintas sobre seus cenrios de uso finais. Algumas
dessas suposies incluem tipo de tecnologia de rede sem fio [13; 52], tipo de aplicao [5;
52], tipo de dispositivo [42; 3], tipo de protocolo usado pelas aplicaes [66; 62], e dife9
Dispositivos equipados com diversas tecnologias sem fio, e.g. GPRS, Bluetooth, e WiFi, e com capacidade
de decidir qual interface usar em diferentes circunstncias.
2.4 Aplicaes de Tempo-Real
18
rentes padres de movimento [78], dentre outros. A especializao dessas solues de gerenciamento de handoff para cenrios de uso particulares dificulta, ou mesmo inviabiliza, sua
aplicao direta em outros cenrios.
A gerncia de handoff, entretanto, um problema mais amplo, envolvendo diversas camadas de software [63]. A transferncia de conexo fsica entre pontos de acesso apenas
o inicio de uma srie de procedimentos que visam manter virtualmente constante o uso de
algum servio. Aplicaes, ou camadas intermedirias, em algum momento precisam lidar
com os eventos de estabelecimento e/ou perda de conexes com pontos de acesso. Nesse
contexto, existem diversas propostas para executar handoffs no contexto da troca de dados
entre pares numa rede. Estas propostas operam em diferentes camadas da pilha de protocolos de rede. A maioria delas so baseadas em modificaes do Mobile IP [48] e, portanto,
implementadas na camada de rede [40; 47]. Outras propostas para gerncia de handoffs no
nvel de troca de dados incluem estratgias baseadas em SIP 10 [54] (operando na camada de
aplicao) [4; 62] ou em SCTP 11 [67] (operando na camada de transporte) [36].
2.4
Aplicaes de Tempo-Real
Sistemas computacionais de tempo-real [38] so sistemas cujas tarefas dependem no apenas

do resultado lgico da computao, mas tambm do cumprimento de requisitos temporais
para a obteno deste resultado. Ou seja, uma resposta correta mas que desrespeita algum
requisito temporal associado aplicao considerada uma resposta no correta. O no
cumprimento de algum desses requisitos temporais pode causar desde inofensivas pequenas
degradaes de qualidade, como rudos numa ligao telefnica, a conseqncias de maior
magnitude, como acidentes fatais devido falhas no sistema ABS
12
de um automvel. O
requisito bsico de um sistema de tempo-real prover maneiras de assegurar que tarefas

sejam executadas respeitando suas restries temporais.
Sistemas de tempo-real dividem-se entre hard real-time e soft real-time. Nos dois casos
existem restries temporais quanto execuo de alguma tarefa, por exemplo, momento
futuro quando uma resposta aguardada e limites de tolerncia mximo e mnimo para a
10
Session Initiation Protocol.

Stream Control Transmission Protocol.
12
Antilock Braking System.
11
19
chegada dessa resposta. Em sistemas hard real-time, os prazos devem ser cumpridos, sob
pena de um resultado inaceitvel ocorrer. Em sistemas soft real-time, normalmente os prazos
devem ser satisfeitos, mas se um certo nmero de prazos for perdido o sistema ainda pode
ser considerado operacionalmente aceitvel.
Neste trabalho o foco est sobre aplicaes soft real-time cujos requisitos temporais estejam sobre a transmisso e/ou recepo de dados via rede, mais especificamente, pela interface Bluetooth de dispositivos mveis. Provavelmente a classe de aplicaes que melhor
se alinha com o trabalho aqui apresentado a classe de aplicaes baseadas em streaming,
descritas a seguir.
2.4.1
Aplicaes de Streaming
Aplicaes de streaming so aquelas onde contedo, em geral multimdia (udio e/ou vdeo),
transferido e reproduzido em tempo-real entre provedores e consumidores numa rede [34].
Diferente do paradigma tradicional, onde arquivos precisam ser baixados completamente
para os computadores dos clientes para ento serem reproduzidos, contedo multimdia distribudo via streaming reproduzido ao mesmo tempo em que baixado.
Aplicaes multimdia que lidam com a reproduo de udio e vdeo, por exemplo, so
um tipo de aplicao de tempo-real [38]. Como tal, possuem algumas propriedades temporais que precisam ser respeitadas durante sua execuo para que seu papel seja cumprido de
forma adequada. Em aplicaes multimdia como reprodutores de udio e/ou vdeo, a restrio est em manter constante, dentro do software, o fluxo entre o mdulo responsvel por
ler o arquivo com os dados, mdulos intermedirios que decodificam atravs de CODECs
13
a informao lida do arquivo, e o mdulo final, responsvel por desenhar algo na tela ou
tocar algum som nos auto-falantes, por exemplo. Manter o fluxo constante significa controlar a quantidade de informao lida/decodificada por intervalo de tempo. Os dados do
arquivo precisam ser lidos e decodificados na mesma velocidade em que so reproduzidos.
Informao pode ser perdida caso a leitura/decodificao acontea mais rpido que o tempo
necessrio para reproduzi-la (buffer overflow). Perda de informao, nesse contexto, torna-se
13
COders/DECoders. Softwares que implementam diferentes algoritmos para comprimir contedo multim-
dia. CODECs podem implementar algoritmos loss-less, onde nenhum dado perdido durante a compresso,
ou lossy, onde dados so perdidos durante a compresso.
20
perceptvel para o usurio final na forma de rudos no udio sendo tocado ou quadros incompletos e/ou congelamentos no vdeo. De forma anloga, paradas temporrias na reproduo
do udio/vdeo so esperadas caso a taxa de leitura/decodificao seja mais lenta que a taxa
de reproduo (buffer underflow).
Conceber uma aplicao de streaming significa, essencialmente, quebrar a nica aplicao que existia anteriormente para a reproduo de arquivos multimdia locais em duas
aplicaes: uma servidora e outra cliente. Alm disso, novos mdulos precisam ser desenvolvidos e incorporados s cadeias de mdulos das duas aplicaes. Estes novos mdulos
devem prover as funcionalidades de empacotar dados do udio/vdeo lido para envio via
rede e, na outra ponta, ler esses dados a partir da rede e desempacot-los, para ento serem
entregues ao mdulo responsvel pela sua reproduo.
Para o empacotamento dos dados para envio via rede, necessrio dividir a informao
a ser transferida entre diversos pacotes do protocolo de transporte escolhido. Considerado
apenas o uso de redes TCP/IP, as opes atuais de protocolo de transporte so TCP e UDP.
Ambos os protocolos possuem virtudes e problemas que devem ser levados em conta no
momento de sua escolha. A caracterstica comum aos dois que nenhum deles foi projetado
para trabalhar com aplicaes de streaming 14 .
TCP implementa transmisso confivel de dados, garantindo a entrega dos dados na sua
ordem correta. Para cada pacote TCP enviado, o remetente aguarda confirmao de recebimento. Eventuais pacotes perdidos (no confirmados dentro do perodo estipulado) so
re-enviados antes que o prximo pacote da fila de envio seja enviado. Em cada tentativa
frustrada de enviar algum pacote, o TCP aguarda um tempo aleatrio crescente antes de
fazer a prxima tentativa [46]. UDP, por outro lado, implementa entrega no confivel de
dados, o que traz pouca sobrecarga transmisso de dados. Entretanto, no existem garantias nem de que os dados enviados sero, em algum momento, recebidos do outro lado, nem
que esses dados vo chegar na mesma ordem em que foram enviados. Em aplicaes de
streaming, a eventual perda de dados prefervel completa parada da renderizao dos
dados devido atraso no envio de grandes quantidades de informao. Ou seja, se por um
14
Novos protocolos de transporte para a pilha TCP/IP, particularmente DCCP (Datagram Congestion Control
Protocol) e SCTP (Stream Control Transmission Protocol), vm sendo desenvolvidos para atender a demanda
crescente por esse tipo de aplicao.
21
lado a eventual perda de pacotes UDP pode provocar rudos ou quadros incompletos, por
outro lado o atraso de pacotes TCP implica no apenas o atraso de pacotes isolados, mas o
atraso no envio de todos os dados que seguem aquele pacote. Devido s caractersticas dos
dois protocolos, mais as caractersticas de aplicaes de streaming, o UDP freqentemente
escolhido, dentro da pilha TCP/IP, como o protocolo de transporte da aplicao.
Em resumo, numa aplicao de streaming de contedo multimdia, as mesmas restries temporais das aplicaes multimdia convencionais continuam valendo, mas com o
acrscimo de se lidar com a transmisso de dados via redes de melhor esforo
15
, como
UDP/IP. No contexto de aplicaes multimdia as principais conseqncias de se lidar com

esse tipo de rede so: oscilaes de jitter, eventuais perda de dados, dados entregues fora
de ordem, replicao de dados, e, para o caso de aplicaes com requisitos temporais ainda
maiores (e.g. telefonia), atraso. Justamente para atacar alguns dos problemas relacionados transmisso de streams multimdia via redes de melhor esforo foi definida a sute de
protocolos RTP (RTP, RTCP, e RTSP).
O RTP [60], Real-Time Transport Protocol, voltado para o transporte de dados com
caractersticas de tempo-real, como os de aplicaes multimdia. No RTP, cada trilha do
contedo a ser enviado via streaming transmitida numa sesso RTP distinta. Trilhas so
diferentes tipos de mdia (udio, vdeo, legendas, etc) que precisam ser sincronizados no momento da renderizao. Normalmente todas essas trilhas so codificadas juntas num mesmo
arquivo, mas tambm possvel que elas sejam obtidas a partir de origens distintas, como
arquivos diferentes ou cmeras e microfones ao vivo. As facilidades que o RTP acrescenta
ao streaming de contedo multimdia so: identificao do contedo de cada pacote (e.g.
CODEC utilizado), enumerao de pacotes para eventual re-ordenao de dados e eliminao de duplicatas, timestamps pra sincronizao de trilhas, e monitorao do envio de
dados.
O funcionamento ideal de aplicaes de streaming baseadas em RTP envolve, na verdade,
dois protocolos intrinsecamente relacionados: o RTP em si, responsvel pelo transporte dos
dados; e o RTCP (RTP Control Protocol) [60], responsvel por monitorar a presena de participantes e parmetros de qualidade de sesses RTP. Para cada sesso RTP da qual participa,
15
Redes baseadas em datagramas e em servios sem conexo onde no existem garantias quanto entrega
de dados.
2.5 Bluetooth
22
cada participante envia periodicamente para os demais participantes relatrios RTCP sobre
as atuais condies de sua recepo do stream. Assim, cada participante de uma sesso RTP
tm informaes suficientes para inferir mtricas de qualidade sobre o trfego de streams
entre o servidor e qualquer participante da sesso. Em geral, o maior interessado nessas
informaes o prprio servidor, que pode us-las para decidir pela reduo da qualidade
do stream em caso congestionamento na rede (revelado pela taxa de perdas relatadas pelos
membros da sesso).
O ltimo protocolo da sute, RTSP [61] (Real-Time Streaming Protocol), pode ser usado
pelos clientes de sesses RTP para controlar o envio de dados. Para isso, o RTSP oferece
funcionalidade semelhante de um controle remoto, onde o cliente pode comandar o incio de uma transmisso, par-la temporariamente e reiniciar em seguida. Freqentemente,
outros protocolos so usados em conjunto com a sute RTP para a implantao de servios
de streaming mais sofisticados. Por exemplo, o SDP [23] (Session Description Protocol)
usado para descrever sesses RTP antes que o cliente inicie o streaming, e.g. descrevendo
CODECs usados, taxas de transmisso das diferentes trilhas, endereos e portas dos servidores, etc. O SIP [54] tambm encontra seu espao nesta combinao de tecnologias. Projetado para o estabelecimento, modificao, e finalizao de sesses multimdia via Internet,
o SIP pode ser usado em substituio ao RTSP. Entretanto, o uso mais comum do SIP em
combinao com os protocolos da sute RTP, para o convite de novos usurios para sesses
RTP previamente existentes e para gerncia de mobilidade de aplicaes e usurios.
2.5
Bluetooth
Bluetooth, tambm referenciado como padro 802.15.1 do IEEE [2], um padro de tecnologia de rede sem fio desenvolvida para servir como alternativa aos cabos usados para troca
de dados entre dispositivos prximos [7]. Suas caractersticas chave so sua robustez para a
transmisso de dados em canais sem fio, pouca complexidade, baixo custo e baixo consumo
de energia.
O Bluetooth opera na faixa de freqncias no licenciadas ISM 16 que vai de 2.400 MHz
a 2.483,5 MHz na maioria dos pases. Para evitar interferncias com dispositivos prximos
16
Industrial, Scientific, and Medical.
2.5 Bluetooth
23
trabalhando na mesma faixa de freqncias ISM, um esquema de FHSS
17
usado com
freqncias variando de 2.402 + k MHz, onde 0 k 78. A taxa normal de troca de

freqncias so 1600 trocas por segundo. O perodo de tempo entre trocas consecutivas,
onde a interface passa trabalhando numa nica freqncia, chamado de slot.
RFCOMM
l2cap
HCI
LMP
Baseband
Rdio
Figura 2.3: Pilha padro Bluetooth.

O Bluetooth possui uma estrutura padronizada de protocolos, ilustrada na Figura 2.3. Na
figura, os mdulos abaixo da interface HCI 18 so implementados dentro da prpria interface.
Os demais mdulos so implementados via software. Alm das camadas que compem a
estrutura padro de protocolos do Bluetooth, tambm so definidos uma srie de perfis para a
tecnologia. Cada perfil define como um tipo especifico de aplicao pode ser implementada,
descrevendo quais componentes padro da estrutura de protocolos devem ser usados, e como.
A camada baseband controla o rdio da interface. O esquema usado para a troca constante de freqncias definido por essa camada, que tambm toma parte em mecanismos de
baixo nvel para encriptao de dados e segurana de conexes. A seleo de pacotes da camada fsica tambm feita pela camada baseband. Existem dois tipos possveis de conexes
entre dois dispositivos Bluetooth: SCO e ACL. Conexes SCO (Synchronous Connection
Oriented) so essencialmente usadas para trfego de voz. Conexes ACL (Asynchronous
Connection Less) so usadas para troca de dados quaisquer entre aplicaes.
A camada baseband a responsvel pelo estabelecimento e manuteno de conexes
fsicas entre os dispositivos. Para tal, ela a responsvel por operaes como inquiry, para
localizar dispositivos na vizinhana, paging, para sincronizao/conexo entre dispositivos,
17
18
Frequency Hopping Spread Spectrum.

Host Controller Interface.
2.5 Bluetooth
24
e seleo de pacotes de camada fsica de acordo com as condies do canal sem fio. Existem
definidos diversos tipos de pacotes de camada fsica, onde, para cada tipo, variam parmetros
como carga til suportada, tamanho dos cabealhos, e carga extra de dados para correo de
erros. Alm dos canais fsicos de comunicao que so iniciados e mantidos pela camada
baseband quando usurios solicitam conexo com outros dispositivos, a camada baseband
gerencia tambm por padro cinco outros canais padronizados. Esses canais so usados para,
por exemplo, busca de dispositivos prximos e estabelecimento de conexes.
A organizao bsica para a conexo de dispositivos Bluetooth so as piconets. Uma
piconet um grupo de dispositivos que compartilham um mesmo canal fsico. Em Bluetooth
um canal fsico caracterizado pelas freqncias, e o padro de troca delas, utilizadas para
comunicao entre dispositivos. Cada piconet com m dispositivos possui necessariamente
um dispositivo mestre e m 1 escravos. Piconets podem ter at sete escravos conectados ao
mesmo mestre ao mesmo tempo. Dispositivos numa piconet podem comunicar-se entre si
atravs de conexes ACL ou SCO, intermediadas pelo mestre. O acesso ao canal fsico por
cada escravo coordenado pelo mestre, que de tempos em tempos libera o uso do canal para
cada escravo. Na estrutura de protocolos do Bluetooth, a camada LMP
19
a responsvel
pela manuteno das piconets.

O l2cap (Logical Link Control and Adaptation Protocol) o protocolo mais baixo da
pilha padronizada Bluetooth a implementar a comunicao fim a fim entre processos em
diferentes dispositivos Bluetooth. As caractersticas bsicas desse protocolo so a segmentao e re-montagem de dados, e ajustes de alguns parmetros de qualidade de servio. No
primeiro caso, o l2cap automaticamente quebra cada PDU
20
em tamanhos que podem ser
encaixados nas cargas teis dos pacotes de camada fsica. PDUs l2cap podem ser de at
64 Kb enquanto pacotes de camada fsica da verso 2.0 do Bluetooth suportam, no mximo, 1023 Bytes [64]. No processo reverso, vrios pacotes de camada fsica recebidos so
guardados at que uma mensagem l2cap completa possa ser lida a partir deles. O protocolo
l2cap permite ainda que alguns parmetros de qualidade de servio sejam definidos, como
largura de banda de pico, atraso no envio de mensagens, e variaes no atraso no envio de
mensagens. O l2cap prov o servio dentro dos requisitos solicitados desde que as atuais
19
20
Link Manager Protocol.

Protocol Data Unit.
2.5 Bluetooth
25
condies do canal fsico permitam.

Por fim, no Host Controller Interface so definidos todas as funes pelas quais aplicaes controlam a interface Bluetooth. Esse desacoplamento entre especificao e implementao permite que diferentes interfaces sejam usadas sem que o software precise ser
alterado.
2.5.1
Estabelecendo Conexes Baseband
O estabelecimento de conexes em Bluetooth acontece em duas etapas: descoberta de dispositivos; e sincronizao. A etapa de descoberta de dispositivos prximos (operao de
inquiry) necessria quando o endereo do dispositivo ao qual se deseja conectar no
conhecido. Comumente esta operao leva em mdia 10,24 s.
Uma vez descoberto o endereo do dispositivo ao qual se deseja conectar, seja via inquiry
ou via outros meios, o prximo passo a conexo entre os dois dispositivos (operao de
paging). Conectar dois dispositivos, no contexto de Bluetooth, significa fazer com que os
dois dispositivos usem o mesmo padro para a troca de freqncias, ou seja, que tenham
sincronia na troca de freqncias. Numa piconet, os escravos devem ajustar seus relgios
internos para bater no mesmo ritmo que o relgio do mestre, alm de usarem o mesmo
padro de troca de freqncias usado pelo mestre. Os tempos de conexo podem variar
conforme os relgios internos dos dispositivos estejam mais ou menos fora de sincronia e de
acordo com o modo usado pelo dispositivo que responde o paging para escutar tentativas de
conexo.
2.5.2
A Operao de Inquiry
O inquiry a operao definida na especificao do Bluetooth para a busca de outros dispositivos Bluetooth nas proximidades. Para a operao de inquiry, um canal dedicado com
32 freqncias usado para troca de pacotes de consulta e resposta. Para que dispositivos
possam ser descobertos pela operao de inquiry, necessrio que estes entrem periodicamente no estado inquiry scan. Nesse estado, dispositivos suspendem a troca de dados das
aplicaes para escutarem por eventuais pacotes de inquiry no canal dedicado.
O processo de inquiry pode ser descrito conforme segue. Sejam BTinquiry o disposi-
2.5 Bluetooth
26
tivo que inicia o inquiry e BTinquiry_scan o nico dispositivo que ir responder consulta
de BTinquiry . Para poder responder consulta de BTinquiry , BTinquiry_scan deve entrar periodicamente no estado inquiry scan. Por padro, dispositivos Bluetooth entram no estado
inquiry scan por 11,25 ms a cada 2,56 s [64]. Para o processo de inquiry, as 32 freqncias
do canal dedicado a inquiries so divididas entre dois trens de 16 freqncias. O inquiry
funciona a partir do envio, por BTinquiry , de pacotes de inquiry no canal dedicado, usando
um padro de mudana de freqncias duas vezes mais rpido que o padro normal do Bluetooth. Assim, num nico slot so enviados pacotes de inquiry em duas freqncias. No slot
seguinte, BTinquiry aguarda possveis respostas dos dois pacotes que acabaram de ser enviados. Por questes de robustez da busca, os envios de pacotes de inquiry em cada freqncia
so repetidos 256 vezes em quatro rodadas. Ao escutar um pacote de inquiry em um de seus
chaveamentos para o estado inquiry scan, BTinquiry_scan aguarda um tempo aleatrio de at
1.023 slots (640 ms) para ento entrar no estado inquiry response. Caso, enquanto no estado
inquiry response, BTinquiry_scan receba outro pacote de inquiry, ento este ser respondido
para BTinquiry , 1 slot depois, com um pacote com as informaes necessrias por BTinquiry
para estabelecer uma conexo com BTinquiry_scan .
De acordo com os procedimentos descritos pela equipe do Bluetooth SIG em [64], o
tempo total de gasto pela operao de inquiry inquiry pode ser deduzido como:
inquiry = ((
slot
32) 256) 4
2
(2.1)
onde, slot o tamanho do slot Bluetooth, 32 o nmero de freqncias, 256 o nmero

de repeties de transmisses para cada freqncia, e 4 o nmero de rodadas onde o o
envio de dados repetido em todas as freqncias. Substituindo o valor do slot na equao
2.1 tm-se:
inquiry = ((625s 16) 256) 4
(2.2)
= 10.240.000s
(2.3)
= 10, 24s
(2.4)
O nmero de slots usados Tinquiry pode ser encontrado a partir do tempo total gasto.
Partindo de 2.3 tm-se:
2.5 Bluetooth
27
Tinquiry = inquiry s/slot
(2.5)
Tinquiry = 10.240.000s/slot
(2.6)
= 10.240.000s/0, 625s
(2.7)
= 16.384
(2.8)
O custo de se responder inquiries, em termos de uso de slots, dividido entre o tempo

gasto escutando por mensagens de inquiry e respondendo essas mensagens. No seu modo de
operao normal, interfaces Bluetooth periodicamente suspendem o trfego de dados para
escutar eventuais mensagens de inquiry num canal dedicado a cada 2,56 s. Em cada parada
para escutar nesse canal so usado 18 slots (11,25 ms). De acordo com a especificao do
Bluetooth, caso alguma mensagem de inquiry seja captada, a interface aguarda um tempo
aleatrio de at 1.023 slots (640 ms). Ao final desse intervalo, a interface enviar a resposta do inquiry um slot aps receber mais uma mensagem de inquiry. Considerando que
BTinquiry_scan opera em modo normal de escuta por mensagens de inquiry, o nmero de slots
Tinq_resp usados para responder o inquiry pode ser estimado como:
Tinq_resp = Nbackof f + 2 , 0 Nbackof f 1.023
(2.9)
onde Nbackof f o nmero aleatrio de slots que a interface ir aguardar antes de tentar
responder uma mensagem de inquiry recebida, mais os dois slots necessrios para receber
novo pacote de inquiry e enviar a resposta em seguida. Assim, o custo de se responder
inquiries oscila entre 2 e 1.025 slots. O tempo gasto respondendo inquiries inq_resp pode
ser deduzido a partir do nmero de slots usados conforme equao 2.10. Sendo Tinq_resp
uniformemente distribudo entre 2 e 1.025, tm-se que 1, 25ms inq_resp 640ms.
inq_resp = Tinq_resp slot , 2 Tinq_resp 1.025
2.5.3
(2.10)
A Operao de Paging
O paging o processo pelo uma conexo fsica estabelecida entre dois dispositivos Bluetooth. Durante a operao de paging feita a sincronizao dos relgios dos dois disposi-
2.5 Bluetooth
28
tivos, assim como eles passam a trocar as freqncias do canal entre si usando o mesmo
padro pseudo-aleatrio. O procedimento de paging acontece de maneira similar ao procedimento de inquiry. Para estabelecer conexo com outro dispositivo, o dispositivo que inicia
o paging deve transmitir mensagens de page para o dispositivo alvo. Assim como no inquiry, estas mensagens so enviadas usando um padro especial para troca de freqncias,
duas vezes mais rpido que o convencional. Dispositivos para serem conectveis, precisam
tambm, periodicamente, escutar no canal dedicado para pagings por tentativas de conexo
de outros dispositivos. Antes de iniciar o paging, as 32 freqncias do canal dedicado aos
pagings so divididas entre dois trens de 16 freqncias. Diferente do inquiry, no paging
suficiente repetir as transmisses em cada freqncia 128 vezes.
Os chaveamentos da interface para escutar o canal de pagings so regulados por dois
parmetros: page scan interval e page scan window. O primeiro parmetro diz com que
periodicidade a interface ir escutar no canal de pagings. O segundo diz por quanto tempo a
interface permanecer ouvindo no canal de pagings em cada chaveamento. De acordo com
a especificao, o primeiro parmetro pode assumir quaisquer valores entre 18 e 4096 slots,
enquanto o segundo parmetro pode assumir valores entre 17 e 4046 slots, desde que seu
valor seja menor ou igual ao valor do page scan interval.
O processo de paging pode ser descrito da seguinte maneira. Sejam BTpaging o dispositivo que inicia o paging, e BTpage_scan o dispositivo alvo da conexo. Para receber conexes
de outros dispositivos, BTpage_scan periodicamente suspende as transmisses de dados das
aplicaes para escutar o canal dedicado aos pagings. O padro em Bluetooth que dispositivos entrem no estado page scan por 11,25 ms a cada 1,28 s. Enquanto isso, BTpaging
inicia o processo de conexo, transmitindo pacotes de page no canal dedicado e escutando
eventuais respostas no slot seguinte a cada transmisso. Quando BTpage_scan , em um de seus
chaveamentos para o canal de pagings, recebe um pacote de page, o pacote respondido
para BTpaging , seguido de uma troca padronizada de pacotes para a concluso da conexo
entre os dispositivos [7].
O custo em tempo de se fazer um paging depende do quanto sincronizados esto os
dois dispositivos. O nmero de slots necessrios Tpaging para concluir o paging, do lado da
interface que inicia o processo, depende do nmero da tentativa k de envio de mensagem de
paging numa dada freqncia e pode ser calculado segundo 2.11.
2.5 Bluetooth
29
k
Tpaging
= k + 5 , 1 k 4.095
(2.11)
Caso as interfaces estejam em perfeita sincronia, uma mensagem de paging enviada no

primeiro slot do processo ser respondida no slot seguinte e o restante do processo de paging
acontecer com mais 5 trocas de mensagens entre os dispositivos, cada uma em um slot. O
pior caso acontece quando apenas a ltima mensagem enviada, no slot 4.095, respondida.
Os nmero de slots usados portanto varia entre 6 Tpaging 4.100. O custo do paging em
tempo funo do nmero de slots, conforme 2.12. Assim, os tempos podem variar entre
3,75 ms e 2,56 s. Entretanto, empiricamente verifica-se que o tempo mdio de pagings gira
em torno de 1,28 s [13].
paging = Tpaging slot , 6 Tpaging 4.100
(2.12)
Na ausncia de erros no canal, o custo para BTpage_scan responder um pedido de paging

constante, somando um total de Tpage_scan = 5, 5 slots [7]. O total de tempo page_resp gasto
com a interface transmitindo e escutando no canal de paging portanto de aproximadamente
3,4 ms, conforme 2.13.
page_resp = Tpage_scan slot
2.5.4
(2.13)
Inquiry e Paging X Trfego de Dados em Tempo-Real
Como discutido anteriormente, as operaes de paging e inquiry, assim como os procedimentos associados aos respectivos estados de resposta, possuem prioridade no uso da interface Bluetooth. Como resultado, aplicaes que necessitem do uso contnuo da interface
tendem a ser prejudicadas devido multiplexao do canal entre os dois trfegos.
Nesse contexto, alguns experimentos foram conduzidos como forma de ilustrar o impacto
das operaes de paging e inquiry sobre o trfego de dados em tempo-real pelas interfaces
Bluetooth. Para obter os resultados a seguir foram usados trs computadores, BT1 , BT2 ,
e BT3 , cada um com uma interface Bluetooth 2.0. Nos grficos a seguir so plotadas as
2.5 Bluetooth
30
larguras de banda instantneas de um fluxo constante de aproximadamente 400 Kbps passando pelas interfaces Bluetooth. As larguras de banda foram medidas no nvel de recepes
de mensagens num socket l2cap. As operaes de Bluetooth avaliadas foram: iniciar um
inquiry, responder um inquiry, iniciar um paging, e responder um paging.
Figura 2.4: Impacto do inquiry num fluxo de 400 Kbps.

Um exemplo do impacto da operao de inquiry sobre um fluxo constante mostrado na
Figura 2.4. Neste exemplo, BT1 transmite um fluxo para BT2 e inicia, aproximadamente no
momento 10 s, um inquiry com a durao padro de aproximadamente 10 s. Para garantir a
descoberta de todos os dispositivos em sua vizinhana, o inquiry em BT1 consumir 16.384
slots para enviar mensagens de inquiry e escutar eventuais respostas, totalizando 10,24 s
com a interface ocupada com o inquiry. Durante esse tempo, longo para uma aplicao
com caractersticas de tempo-real, a disponibilidade da interface para a aplicao reduzida
devido prioridade da operao de inquiry.
Na Figura 2.5 ilustrado o impacto da operao de paging sobre o mesmo fluxo. Assim
como anteriormente, BT1 transmite um fluxo constante para BT2 . Com o fluxo em curso,
aproximadamente no momento 10 s, BT1 faz um paging para BT3 e as oscilaes na qualidade da transmisso dos dados so medidas sobre dados que chegam em BT2 . Diferente
do inquiry, onde o custo da operao constante
21
, no paging o tamanho da ocupao do
canal varia conforme os dois dispositivos estejam fora de sincronia, dependendo tambm das
configuraes usadas no dispositivo alvo para responder pagings. Especificamente no teste
21
O nmero de slots necessrios pela interface que inicia o inquiry constante considerando que o tempo
padro de busca seja usado como condio de parada.
2.5 Bluetooth
31
retratado na Figura 2.5, perceptvel uma queda no fluxo normal dos dados da aplicao
pouco depois que a operao de paging iniciada.
Figura 2.5: Impacto do paging num fluxo de 400Kbps.

Conforme visto na seo anterior, o nmero de slots necessrios para responder inquiries
e paging muito menor que o nmero de slots necessrios para disparar essas operaes.
Nas Figuras 2.6 e 2.7 so mostrados os grficos com os dados do desempenho do mesmo
fluxo mediante ocupao da interface Bluetooth com respostas para um inquiry e um paging,
respectivamente. Para o teste de resposta de inquiry, BT1 transmite um fluxo para BT2 . No
momento 10 s, BT3 inicia um inquiry, mas somente BT1 est configurado para responder
inquiries. No grfico plotado na Figura 2.6 ilustrado o desempenho do fluxo conforme
verificado em BT2 . Por fim, para o teste de resposta de paging, BT1 transmite o mesmo fluxo
constante para BT2 . No momento 10 s, BT3 inicia um paging para BT1 e o desempenho do
fluxo, conforme verificado em BT2 ilustrado na Figura 2.7. Nesses dois ltimos testes, no
houve mudana perceptvel no desempenho dos fluxos.
2.5 Bluetooth
32
Figura 2.6: Impacto do inquiry scan num fluxo de 400Kbps.
Figura 2.7: Impacto do page scan num fluxo de 400Kbps.
Captulo 3
Gerenciando Handoffs para Bluetooth no
Contexto de Aplicaes de Tempo-Real
Neste captulo apresentada a proposta deste trabalho para atender os objetivos levantados
na Seo 1.2. O ponto chave para a definio da soluo foi definir um protocolo para
gerncia de handoff que minimizasse o impacto das operaes de Bluetooth, necessrias
para o handoff, sobre o trfego de dados em tempo-real.
Na soluo proposta so definidas duas entidades principais: estaes base (EBs), e dispositivos mveis (DMs). Seus papis e organizaes fsicas e lgicas so descritas a seguir.
3.1
Viso Geral
Por ser uma tecnologia desenvolvida para substituir cabos, Bluetooth no oferece nenhuma
facilidade para o gerenciamento de handoff [9]. Dessa forma, eventuais protocolos para
gerenciamento de handoff precisam ser implementados acima da pilha padronizada, usando
funes previamente definidas na interface HCI, ou em perfis j existentes, de forma a tornar
transparente a mudana de ponto de acesso. Uma vez feita a troca de ponto de acesso, cabe s
aplicaes (ou camadas intermedirias) implementar os mecanismos para redirecionamento
de trfego e eventuais tratamentos sobre os dados enviados/recebidos (como dados fora de
tempo, replicados, ou perdidos).
No contexto deste trabalho definimos uma infra-estrutura, ilustrada na Figura 3.1, onde
so representadas as entidades fsicas que compem a soluo final. As EBs so os pontos
33
3.1 Viso Geral
34
de acesso do sistema. Cada EB possui interfaces para ambas as redes cabeada e Bluetooth.
EBs comunicam-se com EBs vizinhas via rede cabeada. Ao posicionar EBs prximas umas
s outras, de forma a sobrepor suas reas de cobertura, aumenta-se o espao fsico contnuo
coberto pelo sistema. rede de todas as EBs que, juntas, cobrem o mesmo espao fsico
contnuo denomina-se domnio de mobilidade. EBs so ditas vizinhas quando existe uma
interseco entre suas reas de cobertura.
Domnio de Mobilidade
EB
EB
DM
EB
Figura 3.1: Viso geral do sistema.

Na soluo introduzida nesse trabalho tira-se proveito da caracterstica de mltiplas
conexes simultneas de Bluetooth para definir um algoritmo de gerncia de soft handoffs,
reduzindo a probabilidade de perda de dados e de grandes oscilaes de jitter. O processo
de handoff disparado e gerenciado pelas EBs quando DMs, devido movimentao dos
usurios, ultrapassam uma determinada distncia limiar entre si prprios e as EBs s quais
esto atualmente conectados. De forma inversa, um processo de handoff bem sucedido termina quando DMs voltam a aproximar-se das EBs.
3.1.1
Estados de um DM
DMs podem assumir diferentes estados enquanto conectados s EBs do domnio de mobilidade. A principal funo dessa representao de estados servir como base para a deciso
3.1 Viso Geral
35
das EBs quanto ao disparo do processo de handoff para algum DM em movimento, ou por
sua sada de algum processo de handoff j ativo. Na Figura 3.2 so representados os estados
e transies de estados associados a DMs.
1
CONECTADO
NO_CONECTADO
4
5
SOB_HANDOFF
Figura 3.2: Estados e transies de estados associados a DMs.

Um dispositivo que no est conectado a nenhuma EB um dispositivo externo ao
sistema e, portanto, encontra-se no estado NO_CONECTADO. Aps conseguir conexo
com alguma EB, o DM passa a assumir o estado CONECTADO (1). Do estado CONECTADO, DMs podem desconectar-se do sistema (retornando ao estado NO_CONECTADO),
eventualmente sem a necessidade de fazer handoffs (2), entretanto, o esperado que DMs
movimentem-se aps o estabelecimento de alguma conexo. Ao ultrapassarem o ponto
a partir do qual o processo de handoff disparado, DMs tm seu estado atualizado para
SOB_HANDOFF (3), onde podem estar conectados a mais de uma EB. DMs retornam ao
estado CONECTADO quando continuam se movendo e perdem contato com uma das EBs
s quais estavam conectados (4). Devido a processos de handoff mau sucedidos, ou ainda
movimentao para regies no cobertas por nenhuma EB, DMs perdero contato total com
as EBs do sistema, voltando ao estado NO_CONECTADO (5).
3.1.2
O Registro de um DM
Para manter controle sobre a movimentao de DMs, as EBs constantemente trocam entre
si informaes sobre DMs monitorados por elas. Estas informaes so usadas por cada
3.1 Viso Geral
36
EB para gerenciar registros numa base de dados local sobre os DMs ligados diretamente a
elas ou em sua vizinhana, ou seja, monitorados por EBs vizinhas (Figura 3.3). Para dar
suporte deciso de participao ou no em handoffs, trs informaes sobre os DMs so
trocadas entre as EBs: identificador do DM; seu estado no sistema (segundo a EB que envia
a notificao); e EBs em contato com o DM.
Registro DM
Registro DM
Registro DM EB
BD_ADDR
Registro DM EB
BD_ADDR
Id EB
BD_ADDR
Id EB
BD_ADDR
Estado
Id EB
Estado
Id EB
Estado
Id
Estado
Id
Figura 3.3: Registros de DMs e suas informaes.

O identificador de um DM seu endereo BD_ADDR. Este endereo, semelhante ao
endereo MAC em redes ethernet, possui 48 bits divididos em 6 octetos que identificam
de forma nica diferentes interfaces Bluetooth. O endereo DB_ADDR de um DM tornase conhecido no sistema quando este conecta-se pela primeira vez em uma EB. O endereo
BD_ADDR usado para agilizar a conexo com novas EBs durante o handoff, sem a necessidade de demorados inquiries (vide Seo 3.2.2). Como um DM pode estar conectado a mais
de uma EB por vez (durante o handoff, excepcionalmente), uma lista de identificadores de
EBs mantida junto com o registro do DM. Um identificador de EB acumula as propriedades
de unicamente identificar EBs na rede cabeada e de servir como base para a comunicao entre elas (ou seja, seu endereo IP). Por fim, no registro mantido o estado atualizado do DM
no sistema, conforme os estados descritos na Seo 3.1.1. O estado NO_CONECTADO
possui tratamento especial na atualizao do estado do DM. Conforme descrito na Seo 3.3,
a notificao do estado NO_CONECTADO serve para atualizar a lista de EBs s quais o
DM est conectado.
3.2 Gerncia de Handoff - Transies entre EBs
3.2
37
Gerncia de Handoff - Transies entre EBs
Toda a coordenao envolvida no processo de monitorao de DMs e gerenciamento de

handoffs ocorre nas EBs, poupando assim os DMs de quaisquer custos envolvidos nestes
processos. Nesse contexto, custos podem ser mapeados para recursos computacionais, e.g.
processamento e memria para executar processos extras, e temporais, e.g. atrasos envolvidos na sinalizao entre DM e EB durante o handoff.
Para gerenciar handoffs, EBs precisam manter controle sobre os DMs em sua vizinhana,
onde manter controle significa manter atualizados registros com as identificaes de DMs e
monitorar suas mudanas de estado e lista de EBs s quais esto conectados. Uma vez conectados a alguma EB do domnio de mobilidade, DMs no precisam seguir nenhum procedimento para manterem-se conectados s EBs do sistema, mesmo durante handoffs. Assim,
apenas so definidas entidades lgicas do lado das EBs, conforme ilustrado na Figura 3.4.
MD
Monitor
Link
Monitor
TCP/IP
MD
Registry
Hardware
Bluetooth
HCI
Figura 3.4: Principais entidades lgicas das EBs.

No MD Registry so mantidos registros, conforme descrito na Seo 3.1.2, sobre DMs
ligados propria EB ou em EBs prximas. O Link Monitor constantemente verifica a
conexo entre DM e EB, reportando o estado atual para um MD Monitor associado ao DM
observado. O funcionamento dessas entidades descrito nas sees seguintes.
3.2.1
Monitorando DMs
Cada EB responsvel por monitorar mudanas de estados em DMs em contato direto com
elas e propagar essas informaes para EBs vizinhas. Uma vez conectado a uma EB, o
DM passa a ter sua localizao constantemente monitorada. So dois os objetivos da moni-
38
torao de DMs: perceber quando o DM cruza o ponto limiar para disparo/cancelamento de

processos de handoff ; e detectar a perda de conexo entre EB e DM.
Idealmente, a monitorao de DMs envolveria informaes precisas sobre suas direes
e velocidades. Entretanto, devido limitaes dos mecanismos atualmente disponveis para
localizao em Bluetooth, o mximo que se pode buscar, sem comprometer recursos das
interfaces, so estimativas da distncia em linha reta entre dois dispositivos [6], conforme
ilustrado na Figura 3.5.
10m
5m
Figura 3.5: Localizao de dispositivos Bluetooth.

Existem diferentes meios para se estimar a distncia entre dois dispositivos Bluetooth,
como RSSI
ou qualidade do canal, conforme discutido por Timothy Bielawa em [6], e
por Javier Garca Castao em [9]. A deteco de perda de conexo tambm dependente
de implementao, freqentemente sendo usadas heursticas baseadas em ajustes do link supervision timeout [70; ?]. Entretanto, a pesquisa em torno de localizao em Bluetooth
vasta e complexa [6], existindo atualmente diversas propostas de abordagens para localizao de dispositivos Bluetooth [18; 19; 17] onde, em cada soluo, variam parmetros como
complexidade, exatido, e viabilidade tcnica. Dessa maneira, e devido o fato de que neste
trabalho o foco definir um procedimento de handoff, sero abstrados aqui quaisquer detalhes relacionados implementao dos mecanismos para estimativa de distncia entre EBs e
DMs e deteco de perda de conexo. Desta forma, define-se um contrato com um mdulo
externo que implementa o comportamento desejado para localizao dos DMs.
1
Received Signal Strength Indication
39
O MD Monitor 2 , cujo funcionamento ilustrado no Algoritmo 3.1, responsvel por

decidir que aes tomar mediante mudanas de estados verificadas em DMs monitorados. A
funcionalidade de detectar as mudanas de estado do DM delegada para um mdulo externo, uma implementao de Link Monitor, de acordo com os estados e transies descritos
na Seo 3.1.1.
Algoritmo 3.1: Monitorando mudanas de estado em DMs.
1 SE ( novoEstadoDM = NO_CONECTADO) ENTAO
2
SE ( e s t a d o A n t e r i o r D M = SOB_HANDOFF) ENTAO
a g u a r d a C o n t a t o D e V i z i n h a O u T i m e o u t ( dadosEB , VERDADEIRO)
SENAO
d e f i n e E s t a d o ( dadosEB , NAO_CONECTADO)
n o t i f i c a E B s V i z i n h a s ( dadosEB )
FIM SE
8 SENAO SE ( e s t a d o A n t e r i o r D M = CONECTADO) E ( novoEstadoDM = SOB_HANDOFF)

ENTAO
9
d e f i n e E s t a d o ( dadosEB , SOB_HANDOFF)
10
11
aguardaEncaminhamentoDeMensagem ( dadosEB , VERDADEIRO)
12 SENAO SE ( e s t a d o A n t e r i o r D M = SOB_HANDOFF) E ( novoEstadoDM = CONECTADO)

ENTAO
13
d e f i n e E s t a d o ( dadosEB ,CONECTADO)
14
15 FIM SE
O algoritmo executado segundo um modelo de callback a partir do Link Monitor. Ao

se conectar pela primeira vez ao sistema, cada DM possui estado CONECTADO. Quando o
DM, devido movimentao do usurio, ultrapassa o raio de distncia da EB a partir do qual
o processo de handoff disparado, o MD Monitor notificado, o estado do DM atualizado
para SOB_HANDOFF e notificado para as EBs vizinhas. A EB tambm se prepara para
repassar a primeira notificao que receber sobre o DM que acabou de iniciar handoff (mais
detalhes so descritos na Seo 3.3).
Caso o DM, aps atravessar o ponto limiar para disparo do handoff, retorne para prximo
de sua EB atual, ento o Link Monitor reportar a mudana de estado, que ser atualizada
2
Mobile Device Monitor.
40
pelo MD Monitor e notificada para as EBs vizinhas como CONECTADO. O comportamento

o mesmo para quando um DM, concluindo um processo de handoff, ingressa na rea de
cobertura de uma nova EB e continua movendo-se em sua direo, perdendo contato com a
EB anterior e mantendo conexo apenas com a EB destino.
Toda mudana de estado de um DM monitorado por uma determinada EB deve ser atualizada na base de dados local daquela EB e comunicada s suas EBs vizinhas. Isso inclui a
perda de conexo com DMs. Dessa forma, mesmo quando uma EB percebe que no mais est
em contato com algum DM, seu estado atualizado localmente para NO_CONECTADO
e propagado para as EBs vizinhas. Uma situao excepcional acontece quando DMs saem
da rea de cobertura da EB aps assumirem estado SOB_HANDOFF. Especificamente, o
procedimento de handoff para um dado DM em movimento pode falhar caso a mensagem
de perda de contato com ele seja recebida pela EB de destino, segundo a trajetria do dispositivo, antes que esta consiga contactar o DM. Para evitar problemas de perda de contato
com o DM devido ordem de troca de mensagens entre EBs (vide Seo 3.3), quando EBs
percebem a perda de contato com DM nessa situao essa mensagem no imediatamente
enviada para suas vizinhas. Ao invs disso, a EB aguarda at que chegue uma mensagem de
contato de uma de suas vizinhas com o DM em questo, ou at que um determinado perodo
de tempo transcorra. O ajuste deste timeout uma configurao de implantao do sistema.
Entretanto, valores entre 5 e 10 segundos so ajustes razoveis para esse parmetro.
No Algoritmo 3.1 so ilustrados os procedimentos tomados pelo MD Monitor mediante
as mudanas de estados de interesse. A execuo do algoritmo envolve apenas a deciso
de que ao deve ser tomada. Como no existem laos nem recurses, o algoritmo possui
complexidade O(1), executando em tempo constante. As complexidades das funes referenciadas no algoritmo so dependentes de implementao.
3.2.2
Atribuindo Responsabilidades e Configurando Operaes
Quem Deve Ser o Mestre?

Ao iniciar a definio de responsabilidades e configuraes das entidades do sistema, a
primeira pergunta a ser respondida quem, dentre EBs e DMs, deve ser mestre nas piconets.
Como j discutido na Seo 2.5, Bluetooth emprega um esquema de pooling para controle
41
de acesso ao meio. Numa piconet, todos os escravos tm seus relgios sincronizados com
o relgio do mestre, de forma a viabilizar a tarefa do mestre de arbitrar os acessos ao meio
de cada dispositivo na rede. Dispositivos Bluetooth podem tambm fazer parte de mais de
uma piconet ao mesmo tempo. Quando isso acontece, o dispositivo negocia com os mestres
de cada piconet quando ir participar de cada uma, alternando perodos onde estar sincronizado com o relgio do mestre de cada piconet [64]. Em termos prticos, isso significa
perda de tempo e, conseqentemente, de largura de banda, para o trfego de dados em cada
piconet. Alm disso, a especificao de Bluetooth bastante vaga quando descreve o comportamento de dispositivos que participam de mais de uma piconet. Apenas exigido que
um esquema de TDM 3 seja empregado para alternar perodos de participao do dispositivo
em cada piconet. Como veremos na Seo 4.1.2, essa flexibilidade da especificao permite
que diferentes fabricantes de interfaces criem mecanismos mais ou menos eficientes para
diviso de tempo entre piconets, o que pode viabilizar ou no diferentes tipos de aplicaes
no contexto do trabalho aqui apresentado.
Mestre
Escravo
Mestre
Escravo
Escravo
Mestre
Escravo
Mestre
Figura 3.6: Atribuies dos papis de mestre e escravo (adaptado do trabalho de Aman
Kansal em [30]).
Conforme j discutido por Aman Kansal em [30], existem vantagens e desvantagens em
definir EBs como mestres e DMs como escravos e vice versa (Figura 3.6). Tornar DMs
mestres nas piconets com EBs significa poupar DMs dos desperdcios relacionados com o
chaveamento entre diferentes piconets, alm de, num primeiro momento, ser a soluo mais
escalvel do ponto de vista do nmero de clientes atendidos pela EB, j que no existem
3
Time Division Multiplexing
42
restries explicitas quanto o nmero de conexes simultneas que um dispositivo pode ter
ativas ao mesmo tempo enquanto escravo. Por outro lado, essa arquitetura transfere para as
EBs o gargalo de desempenho, j que o nmero de DMs conectados ao mesmo tempo numa
EB tende a ser potencialmente maior que o nmero de EBs s quais um DM est conectado
ao mesmo tempo.
Ao definir DMs como escravos nas piconets com EBs, restringe-se o nmero mximo de
clientes conectados ao mesmo tempo s EBs para 7 (restrio j conhecida das piconets) e
transfere-se para os DMs a responsabilidade de chavear seu tempo de escuta entre as EBs
que estiver conectado. Como resultado, DMs precisam chavear seu tempo apenas enquanto
fazem handoff, e entre um nmero reduzido de EBs. Os critrios para diviso de recursos da
EB entre os DMs passam a ser apenas os critrios j conhecidos do Bluetooth, como nmero
de participantes da piconet, tipo de conexo (simtrica ou assimtrica), e tipos de pacotes
escolhidos pela camada fsica [30].
Handoffs sem Inquiries
De acordo com a especificao de Bluetooth, e conforme ilustrado nos experimentos da
Seo 2.5.4, existem custos (de quantidade de slots usados) associados s operaes de
inquiry, paging, e os respectivos estados de resposta. Esses custos podem ser calculados
baseado nas descries destes estados na especificao (conforme as equaes apresentadas
nas Sees 2.5.2 e 2.5.3), apesar de que resultados de experimentos prticos podem diferir
dos resultados esperados ou simulados devido a uma srie de fatores, como condies do
canal sem fio, qualidade das interfaces, interferncia com aparelhos prximos (e.g. fornos
microondas, telefones sem fio, ou pontos de acesso WiFi), etc.
Para o projeto de um protocolo de handoff com baixo impacto sobre o trfego de dados
em tempo-real, necessrio evitar as operaes com alto consumo de slots, particularmente
o inquiry, j que o paging operao obrigatria para a conexo de dispositivos Bluetooth.
No protocolo apresentado na Seo 3.3, o processo de inquiry descartado durante os handoffs. Ao invs disso, EBs trocam entre si, via rede cabeada, a informao sobre o endereo
BD_ADDR do DM sob handoff sendo, ento, necessria apenas a operao de paging, que
iniciada pela EB. Nesse arranjo de responsabilidades a nica tarefa do DM para se manter
conectado ao sistema manter-se no estado page scan, como forma de manter-se conec-
43
tvel durante o handoff.

Reduzindo a Quantidade de Slots Necessrios para os Handoffs
Conforme discutido no tpico anterior, uma vez eliminada a operao de inquiry do processo
de handoff, o custo para o DM durante as transies entre EBs resume-se ao custo de responder o paging da EB. De acordo com a especificao de Bluetooth, e conforme mostrado na
Equao 2.13 da Seo 2.5.3, o custo de responder um paging o menor dentre os estados
relacionados com as operaes necessrias para o handoff. Esse baixo custo reflete-se numa
curta obstruo, da ordem de 5,5 slots (no considerando eventuais erros nas trocas de pacotes entre dispositivos), no trnsito de dados pela interface Bluetooth do DM. Entretanto, o
impacto total no trfego de dados tambm depende da perda de desempenho da interface da
EB durante o processo de paging, que pode variar entre 6 e 4100 slots (Equao 2.11), mas
em mdia 1.28 s (aproximadamente 2048 slots), dependendo do desvio de sincronia entre os
dispositivos.
Para obter handoffs ainda mais eficientes, do ponto de vista do uso de recursos das interfaces Bluetooth das EBs e DMs, a soluo direta diminuir o tempo necessrio para o
procedimento de paging. Para diminuir o nmero de slots usados no paging existem duas
alternativas: ter relgios sincronizados nos dois dispositivos; e/ou configurar a janela e o
intervalo do paging no DM. Como no se pode interferir nos relgios internos das interfaces,
a nica soluo para reduzir os tempos dos pagings calibrar seus parmetros de maneira
apropriada.
Os dois parmetros do paging, page scan interval e page scan window, definem, respectivamente, com que freqncia e por quanto tempo uma interface escutar por tentativas de
paging no canal dedicado para essa operao. Conforme mostrado na Figura 3.7, extrada
do trabalho de Ming-Chiao Chen et al. em [11], os melhores desempenhos para a operao
de paging so alcanados quando se aumenta o page scan window, e se reduz o page scan
interval, onde mudanas no page scan interval parecem ter um impacto muito maior do que
mudanas no page scan window. Ou seja, melhores resultados so alcanados quando se
aumenta o tempo que a interface passa ocupada apenas escutando por pedidos de paging. A
conseqncia direta dessa abordagem seu impacto direto no desempenho de aplicaes de
tempo-real, que vo ter menos slots livres da interface do DM para o trnsito de seus dados.
44
Figura 3.7: Desempenho da operao de paging com diferentes parmetros (extrada do

trabalho de Ming-Chiao Chen et al. em [11]).
Dessa maneira, os ajustes dos parmetros do paging devem ser cuidadosamente
definidos, de forma a alcanar os melhores valores sem comprometer os requisitos temporais
da aplicao do usurio. A definio de valores ideais para esses parmetros, entretanto,
uma tarefa complexa o suficiente para ser tratada num trabalho parte. Por isso, no proposto aqui nenhum modelo para definio de valores timos para os parmetros do paging
levando-se em conta os requisitos de cada fluxo de dados em tempo-real eventualmente em
curso pela interface Bluetooth.
45
Hard ou Soft Handoffs?

Do ponto de vista de nmero de conexes ativas durante a troca de ponto de acesso, handoffs
podem ser divididos entre soft e hard (Seo 2.3). De maneira geral, soft handoffs diminuem
a probabilidade de ruptura total de conectividade durante o handoff, o que tambm diminui a
probabilidade de perda de dados [37]. Em compensao, o custo de se criar infra-estruturas
de suporte a soft handoffs tende a ser mais alto devido complexidade extra das interfaces
sem fio para suportarem mltiplas conexes simultneas. Hard handoffs, por outro lado, exigem interfaces menos complexas, mas precisam acontecer de forma rpida o suficiente para
no serem notados. Soft handoffs relaxam o requisito por handoffs extremamente rpidos dos
hard handoffs, o que traz alguma folga para que, por exemplo, aplicaes tenham tempo
de enviar sinalizaes para o redirecionamento do trfego de dados para o novo ponto de
acesso.
No contexto especfico de Bluetooth, a tecnologia j foi projetada de forma a suportar conexes simultneas, e o baixo custo das interfaces tambm foi um requisito em seu
projeto. As perdas de se lidar com soft handoffs no contexto de Bluetooth dependem do
esquema de TDM usado para multiplexar o acesso s piconets das quais o DM faz parte.
Porm, difcil estimar tais perdas, j que o esquema de TDM utilizado dependente de
implementao e, provavelmente, segredo de negcio do fabricante da interface. Entretanto,
eventuais estratgias ruins de TDM no significam necessariamente um problema do protocolo de handoff como um todo, mas o conjunto de aplicaes finais pode ser influenciado de
alguma maneira devido essa caracterstica das interfaces (vide Sees 4.1.2 e 5.1).
Detectando a Necessidade de Handoff
EBs podem ser as responsveis por monitorar e disparar processos de handoff, assim como
DMs tambm podem. Existem, na verdade, diversas tarefas que precisam ser realizadas para
uma troca transparente de EB durante handoffs, como perceber a necessidade de handoff ou
contactar a EB de destino para solicitar conexo com o DM. Existem inmeras maneiras de
distribuir essas responsabilidades entre as entidades do sistema, onde a deciso dita correta
deve levar em considerao os requisitos do problema e o impacto das decises tomadas
sobre esses requisitos.
46
Em razo do enfoque deste trabalho na caracterstica de mobilidade do problema tratado,

espera-se que os dispositivos clientes de eventuais ambientes inteligentes baseados na infraestrutura aqui proposta sejam pequenos dispositivos pessoais, tais como PDAs, Internet
Tablets, ou smartphones. Uma das caractersticas comuns a esses dispositivos sua baixa
autonomia, devido ao uso de baterias, baixo poder computacional (e.g. memria e processamento), e largura de banda reduzida. Assim, alocar a execuo de funcionalidades relacionadas gerncia de handoff a tais dispositivos significa consumir parte dos recursos j
limitados, alm de um provvel impacto em sua autonomia relacionada ao consumo extra de
energia.
Dessa maneira, optou-se aqui por remover dos DMs o mximo possvel de funcionalidades ligadas ao processo de handoff, jogando para EBs e rede cabeada a maior parte do custo
relacionado gerncia de handoffs em benefcio dos DMs. Dessa maneira, EBs monitoram
o estado de DMs, controlam suas mudanas de estado, trocam entre si, via rede cabeada, informaes sobre essas mudanas de estado e tentam contato com DMs que se movem entre
suas reas de cobertura. Aos DMs, mais precisamente s aplicaes executando nos DMs,
cabe apenas a responsabilidade de perceber o estabelecimento e perda de conexes e lidar
com o tratamento de dados em tempo-real transmitidos/recebidos por, eventualmente, mais
de uma conexo ativa.
Comandos HCI Necessrios
A soluo para handoffs eficientes, do ponto de vista de impactos sobre o trfego de dados em
tempo-real, introduzida neste trabalho, baseia-se apenas em comandos e caractersticas obrigatrios do Bluetooth, de acordo com sua especificao. Os procedimentos descritos neste
trabalho so independentes de dispositivo, bastando que existam nas EBs e DMs interfaces
Bluetooth e uma pilha de acesso ao hardware que implemente, pelo menos, os comandos
HCI padres descritos na Tabela 3.1. Esses comandos so suficientes para a gerncia de
handoff como definido neste trabalho. Outros comandos e eventos HCI so necessrios, por
exemplo, para implementar o Monitor de Link ou o mecanismo usado nos DMs para detectar
o estabelecimento e perda de conexes.

Comando
47
Funo
HCI_Create_Connection
Estabelece
Contexto
uma
conexo
baseband entre dois disposi-
Invocado por EBs durante o

handoff.
tivos (paging).
HCI_Write_Page_Scan_Activity
Define os parmetros do
Pode ser chamado pelos
paging.
DMs para melhorar o desempenho dos pagings.
Tabela 3.1: Comandos HCI usados.

Discusses Adicionais
As configuraes e alocaes de responsabilidades discutidas nesta seo tm como objetivo,
principalmente, reduzir o tempo necessrio para conexo entre DMs e EBs durante o handoff.
Existem, entretanto, outras solues para se buscar handoffs ainda mais rpidos. Segundo os
trabalhos de Aman Kansal [30] e Sang-Hun Chung et al. [13], e prpria especificao do
Bluetooth, uma boa estimativa do tamanho da diferena de sincronizao entre os relgios
dos dois dispositivos (clock offset) pode agilizar o processo de paging entre os dispositivos.
Entretanto, tal ganho no est claro nem na especificao, que no faz comentrios sobre
economia de slots envolvida nesse processo, nem nos trabalhos que tambm propem o
uso de estimativas dos offsets. Nestes trabalhos, o uso de relgios sincronizados sempre
empregado junto com outras estratgias para aumento de desempenho, no ficando claro qual
o ganho de se ter relgios sincronizados. Alm disso, em testes prprios realizados para se
investigar a real utilidade de se usar estimativas de diferena entre relgios, no foi percebida
mudana visvel no desempenho dos pagings.
Outra linha de trabalho, pouco comum, para melhorar o desempenho dos handoffs consiste em usar operaes no padronizadas do Bluetooth para, por exemplo, escolher a EB
mais prxima durante o handoff [13]. Como nestes trabalhos predomina a apresentao de
resultados a partir de dados de simuladores, torna-se fcil aplicar e estudar o sucesso ou
no de operaes no padronizadas. Entretanto, para implantar esse tipo de soluo mudanas podem ser necessrias desde a pilha Bluetooth at o firmware da interface para que
as solues propostas cumpram com suas tarefas. Esse custo extra para implantao destas
solues possui grandes chances de ser uma questo proibitiva, a depender dos cenrios de
3.3 Gerncia de Handoff - Mantendo Contato com DMs
48
uso finais.
Neste trabalho optou-se por definir uma soluo utilizando apenas operaes padro do
Bluetooth, definidas na camada HCI. O objetivo viabilizar a implantao da soluo aqui
proposta em sistemas embarcados, onde uma atualizao de pilha ou de firmware muito
mais complexa que a instalao de softwares em camada de aplicao.
3.3
Gerncia de Handoff - Mantendo Contato com DMs
Adicionalmente s definies de configuraes e responsabilidades discutidos na seo anterior, nesta seo descrito o protocolo pelo qual DMs so mantidos conectados s EBs
medida que movem-se atravs de suas reas de cobertura. O processo de handoff disparado
e/ou mantido por uma determinada EB mediante duas situaes:
1. quando o estado de algum DM em sua vizinhana muda de CONECTADO para
SOB_HANDOFF;
2. quando algum DM est no estado SOB_HANDOFF e ligado, ao mesmo tempo, a duas
de suas EBs vizinhas.
O processo de handoff para um DM termina quando este volta ao estado CONECTADO
ou perde conexo com o sistema (estado NO_CONECTADO). A nica informao que a
EB tem sobre a movimentao do DM uma estimativa da distncia em linha reta entre si
e o DM. Por isso, as notificaes de mudana de estado de DMs so enviadas para todas
as EBs vizinhas. A deciso de participar do handoff de algum DM, ou ainda de cancelar/
manter participao em handoffs j existentes, tomada localmente por cada EB ao receber
notificaes sobre mudanas de estados de DMs em sua vizinhana. O processo pelo qual
EBs atualizam seus registros locais e tomam essas decises descrito no Algoritmo 3.2.
Algoritmo 3.2: Atualizando registros de DMs
1 SE ( aguardandoEncaminhamentoParaDM ( dadosEB ) ) ENTAO
2
aguardaEncaminhamentoParaDM ( dadosEB , FALSO)
4 FIM SE
5 SE ( a g u a r d a n d o C o n t a t o D e V i z i n h a ( dadosEB ) ) ENTAO

6
d e f i n e E s t a d o ( dadosEB , NAO_CONECTADO)
49
8 FIM SE
9 SE ( r e g i s t r o L o c a l . j a E x i s t e R e g i s t r o ( dadosEB ) ) ENTAO
10
e s t a d o A t u a l DM e s t a d o A t u a l ( dadosEB )
11
e s t a d o A n t e r i o r D M r e g i s t r o L o c a l . e s t a d o A t u a l ( dadosEB )
12
e b R e m e t e n t e e b R e m e t e n t e ( dadosEB )
13
/ / a d i c i o n a ou remove a EB r e m e t e n t e como c o n e c t a d a ou no ao DM,

d e p e n d e n d o do e s t a d o r e p o r t a d o . N o t i f i c a e s r e d u n d a n t e s no s o
aplicadas
14
r e g i s t r o L o c a l . a t u a l i z a R e g i s t r o ( dadosEB )
15
SE ( ! l i s t a E B s V i z i n h a s . contem ( e b R e m e t e n t e ) ) ENTAO
16
17
e s c a l o n a d o r H a n d o f f s . c a n c e l a P e d i d o H a n d o f f ( dadosDM )
SENAO SE ( e b R e m e t e n t e 6= ESTA) ENTAO
SE ( e s t a d o A t u a l D M 6= e s t a d o A n t e r i o r D M ) ENTAO
18
19
SE ( e s t a d o A t u a l D M = CONECTADO) OU ( e s t a do A t u a l D M = SOB_HANDOFF
) ENTAO
20
SE ( e s t a d o A n t e r i o r D M = CONECTADO) E ( e st a d o A t u al D M =
SOB_HANDOFF) ENTAO
21
e s c a l o n a d o r H a n d o f f s . g e r a P e d i d o H a n d o f f ( dadosDM )
22
SENAO SE ( e s t a d o A n t e r i o r D M = SOB_HANDOFF) E ( e s t a d o A tu a l D M
= CONECTADO) ENTAO
23
e s c a l o n a d o r H a n d o f f s . c a n c e l a P e d i d o H a n d o f f ( dadosDM )
24
FIM SE
25
SENAO / / e s t a d o A t u a l D M = NO_CONECTADO
26
SE ( ! r e g i s t r o L o c a l . estaConectadoEmAlgumaEB ( dadosEB ) ) ENTAO
27
/ / tambm c a n c e l a e v e n t u a l h a n d o f f em andamento
28
r e g i s t r o L o c a l . r e m o v e R e g i s t r o ( dadosEB )
29
FIM SE
30
FIM SE
31
SENAO SE ( e s t a d o A t u a l D M = e s t a d o A n t e r i o r D M ) E ( e s t a d o A t u a l D M =
SOB_HANDOFF) ENTAO
32
/ / g e r a um p e d i d o novo ou mantm o j e x i s t e n t e
33
e s c a l o n a d o r H a n d o f f s . g e r a P e d i d o H a n d o f f ( dadosDM )
34
35
FIM SE
FIM SE
36 SENAO

37
50
r e g i s t r o L o c a l . a d i c i o n a R e g i s t r o ( dadosEB )
38 FIM SE
A distribuio das informaes que ajudaro EBs a decidirem por sua participao ou
no em algum processo de handoff comea quando DMs entram no sistema. Quando isto
acontece, a EB que recebeu o novo cliente comunica s suas vizinhas que est em contato
com um novo DM, e que este se encontra no estado CONECTADO. Enquanto conectados
a alguma EB, DMs tm seus estados constantemente monitorados conforme descrito no Algoritmo 3.1. Quaisquer mudanas de estado verificadas por EBs so atualizadas localmente
e comunicadas para suas vizinhas. Cada EB vizinha, ao receber essa notificao, compara
o estado notificado para aquele DM contra seu ltimo estado conhecido localmente. Caso
verifiquem uma das situaes onde o processo de handoff disparado, um pedido de handoff
enviado para um escalonador local, responsvel por gerenciar os pedidos de handoff executados por aquela EB. Pedidos de handoff j existentes podem ser mantidos ou cancelados,
de acordo com as notificaes recebidas. De forma excepcional, a EB que percebe o inicio
de um handoff para um DM anteriormente conectado a apenas si prpria, encaminhar para
todas as suas vizinhas a primeira notificao que receber sobre contato de alguma vizinha
com o DM sob handoff. O objetivo evitar que algumas EBs continuem indefinidamente
tentando contato com um DM que j foi contactado por outra EB. Assim como o Algoritmo
3.1, o Algoritmo 3.2 no possui laos nem recurses. Portanto, a complexidade do Algoritmo
3.2 O(1), sendo este sempre executado em tempo constante.
Na Figura 3.8 ilustrado o funcionamento do algoritmo descrito no Algoritmo 3.2. Assim que o dispositivo DM1 consegue conexo com EBD , esta envia uma notificao para
EBA , EBB , EBE , EBG , e EBH , indicando sua conexo com DM1 e seu estado CONECTADO (3.8(a)). Os registros locais das EBs do sistema, aps notificao de EBD , so descritos na Tabela 3.2.
Quando EBD percebe que DM1 ultrapassou o ponto a partir do qual o handoff disparado, o estado daquele DM atualizado em EBD para SOB_HANDOFF e enviado para
as demais EBs (3.8(b)). Cada EB vizinha de EBD recebe a notificao e atualiza sua
base de dados local. Ao perceber a mudana de estado de DM1 de CONECTADO para
SOB_HANDOFF, as EBs EBA , EBB , EBE , EBG , e EBH geram pedidos de handoff locais para aquele dispositivo. EBD , por sua vez, no dispara processo de handoff, pois j est
51
(a) EBD notifica contato com DM1 no estado
(b) EBD mudana de estado de DM1 para
CONECTADO.
SOB_HANDOFF.
(c) EBE notifica contato com DM1 no estado
(d) EBB notifica contato com DM1 no estado
SOB_HANDOFF. DBD encaminha a mensagem
SOB_HANDOFF
recebida.
(e) EBC notifica contato com DM1 no estado
(f) EBC notifica contato com DM1 no estado
SOB_HANDOFF
CONECTADO
Figura 3.8: Mantendo o DM conectado durante movimentao.
52
EB
Registros
Handoff Ativo
EBA
{DM1 , CONECTADO, [EBD ]}
No
EBB
No
EBC
{}
No
EBD
No
EBE
No
EBF
{}
No
EBG
No
EBH
No
EBI
{}
No
Tabela 3.2: Registros das EBs aps entrada de DM1 no sistema.

em contato com DM1 , mas prepara-se para repassar s suas vizinhas a primeira notificao
que receber sobre DM1 . Novo estado dos registros das EBs pode ser visto na Tabela 3.3.
EB
Registros
Handoff Ativo
EBA
{DM1 , SOB_HANDOFF, [EBD ]}
Sim
EBB
Sim
EBC
{}
No
EBD
No
EBE
Sim
EBF
{}
No
EBG
Sim
EBH
Sim
EBI
{}
No
Tabela 3.3: Registros das EBs aps mudana de estado de DM1 para SOB_HANDOFF.
Ao aproximar-se de EBE , DM1 contactado por aquela EB, que envia para suas vizinhas, EBB , EBC , EBD , EBF , EBH , e EBI notificao de contato com DM1 no estado
SOB_HANDOFF (3.8(c)). Neste momento, as EBs EBA , e EBG continuariam tentando
contato com DM1 , pois no so vizinhas de EBE e, por isso, no receberam a notificao
do contato com DM1 (Tabela 3.4(a)). Entretanto, EBD encaminha para suas vizinhas a
primeira notificao recebida de alguma vizinha sobre seu contato com DM1 , neste caso,
a mensagem de EBE . Somente as EBs que no tm contato direto com EBE processam
essa mensagem encaminhada. Segundo o Algoritmo 3.2, EBB e EBH vo processar a
mesma mensagem duas vezes (uma recebida diretamente de EBE e outra encaminhada por
EBD ), o que no deve provocar mudanas no registro de DM1 em cada uma delas. J
53
as EBs EBA e EBG , quando processarem a mensagem repassada por EBD cancelaro o
handoff em andamento para DM1 . Os estados dos registros das EBs no sistema, antes e
depois do repasse da mensagem de EBE por EBD , so descritos nas Tabelas 3.4(a) e 3.4(b),
respectivamente.
EB
Registros
Handoff
EB
Registros
Ativo
EBA
Handoff
Ativo
Sim
EBA
EBB {DM1 , SOB_HANDOFF, [EBD ,EBE ]}
Sim
EBB {DM1 , SOB_HANDOFF, [EBD ,EBE ]}
Sim
EBC
No
EBC
No
EBD {DM1 , SOB_HANDOFF, [EBD ,EBE ]}
No
EBD {DM1 , SOB_HANDOFF, [EBD ,EBE ]}
No
EBE {DM1 , SOB_HANDOFF, [EBD ,EBE ]}
No
EBE {DM1 , SOB_HANDOFF, [EBD ,EBE ]}
No
EBF
{DM1 , SOB_HANDOFF, [EBE ]}
No
EBF
No
EBG
No
No
Sim
EBG
EBH {DM1 , SOB_HANDOFF, [EBD ,EBE ]}
Sim
EBH {DM1 , SOB_HANDOFF, [EBD ,EBE ]}
Sim
EBI
No
EBI
No
(a) Estado dos registros das EBs do sistema antes
(b) Estado dos registros das EBs do sistema aps
do encaminhamento de mensagem de EBE .
encaminhamento de mensagem de EBE .
Tabela 3.4: Estados dos registros da EBs antes e depois do repasse da mensagem de EBE
por EBD .
Continuando sua trajetria, DM1 move-se em direo a EBB , que consegue contato
com DM1 atravs do pedido de handoff ainda ativo para aquele dispositivo. Quando isso
acontece, EBB envia para EBA , EBC , EBD , e EBE notificao sobre seu contato com
DM1 no estado SOB_HANDOFF. Enquanto DM1 se movia, EBD continuou monitorando
o dispositivo. Ao perceber que perdeu contato com DM1 , EBD no envia ainda a notificao
devida para suas vizinhas. Ao invs disso, aguarda notificao de contato de uma de suas
vizinhas com DM1 . Somente aps receber a notificao de EBB , EBD envia para suas
vizinhas a notificao de que perdeu contato com DM1 (3.8(d)). Os estados dos registros
aps essa transio de EBs podem ser vistos na Tabela 3.5.
Neste momento, DM1 pode continuar movendo-se na direo de EBE ou EBB , onde
teria contato perdido naturalmente com a EB oposta e assumiria estado CONECTADO, ou
ainda pode mover-se em direo a EBC ou EBD , que possuem pedidos ativos de handoff
para DM1 . Assumindo que DM1 mova-se na direo de EBC , esta EB notificar EBB ,
EBE , e EBF sobre seu contato com DM1 no estado SOB_HANDOFF, enquanto EBB

EB
54
Registros
Handoff Ativo
EBA
{DM1 , SOB_HANDOFF, [EBB ]}
No
EBB
{DM1 , SOB_HANDOFF, [EBB ,EBE ]}
No
EBC
{DM1 , SOB_HANDOFF, [EBE ,EBB ]}
Sim
EBD
Sim
EBE
No
EBF
No
EBG
{}
No
EBH
No
EBI
No
Tabela 3.5: Registros das EBs aps transio de DM1 de EBD para EBB .
aguardar a primeira mensagem de algum contato com DM1 para ento notificar para EBA ,
EBC , EBD , e EBE sua perda de contato com aquele dispositivo. Os novos estados dos
registros das EBs aps mais essa mudana so descritos na Tabela 3.6. Por fim, DM1 continua sua trajetria em direo a EBC , que percebe sua aproximao e atualiza localmente
o estado local daquele dispositivo para CONECTADO. A mudana ento comunicada s
vizinhas EBB , EBE , e EBF , seguida da notificao de EBE sobre a perda de contato com
DM1 . O resultado a suspenso dos processos de handoff ativos para aquele DM em EBB
e EBF (3.8(f)). Os estados dos registros das EBs do sistema, aps essa ltima mudana, so
descritos na Tabela 3.7.
EB
Registros
Handoff Ativo
EBA
{}
No
EBB
{DM1 , SOB_HANDOFF, [EBC ,EBE ]}
Sim
EBC
No
EBD
No
EBE
No
EBF
Sim
EBG
{}
No
EBH
No
EBI
No
Tabela 3.6: Registros das EBs aps transio de DM1 de EBB para EBC .
3.4 Discusses Adicionais

EB
55
Registros
Handoff Ativo
EBA
{}
No
EBB
{DM1 , CONECTADO, [EBC ]}
No
EBC
No
EBD
{}
No
EBE
No
EBF
No
EBG
{}
No
EBH
{}
No
EBI
{}
No
Tabela 3.7: Registros das EBs aps mudana de estado de DM1 de SOB_HANDOFF para
CONECTADO.
3.4
Um problema adicional naturalmente levantado ao discutir a soluo proposta para gerncia

de handoff em Bluetooth: escalabilidade. natural perceber que medida que se aumenta
a quantidade de DMs fazendo handoff para a mesma EB ao mesmo tempo, aumenta-se a
proba-bilidade de handoff mau sucedido devido atraso da EB para tentar contato com o
cliente. Tambm natural perceber que a capacidade de interfaces Bluetooth de at sete
conexes simultneas no suficiente para evitar uma saturao rpida das EBs. Apesar
da questo de escalabilidade ter tido sua parcela de ateno durante a elaborao deste
trabalho, entendemos que este problema no est diretamente ligado ao foco do trabalho.
Dessa maneira, o conhecimento adquirido sobre como tornar o sistema escalvel, do ponto
de vista de eficincia dos handoffs e capacidade de comportar clientes, no est sendo proposto aqui como parte da soluo. Porm, no Apndice C apresentado um arcabouo de
infra-estrutura, baseada no protocolo aqui proposto, cujo foco so as questes de escalabilidade que acabaram de ser colocadas. A extenso apresentada no Apndice C baseia-se na
possibilidade de aumentar a quantidade de interfaces nas EBs e no acoplamento parcial entre
os processos das EBs para gerncia de handoffs com as aplicaes finais do sistema. Com
o aumento do nmero de interfaces nas EBs aumenta-se tambm a capacidade daquela EB
de atender mais clientes ao mesmo tempo. Diminui-se tambm a probabilidade de handoffs
mau sucedidos devido atraso da EB em processar pedidos simultneos pois, com um maior
nmero de interfaces na EB, vrios handoffs podem ser atendidos ao mesmo tempo. Atravs
3.4 Discusses Adicionais
56
do acoplamento com as aplicaes finais do sistema, pode-se implementar mecanismos para

controle de admisso nas EBs, o que pode evitar tentativas de contato com DMs sob handoff
quando no existem recursos suficientes para aquele dispositivo na EB destino.
Captulo 4
Avaliao da Soluo
Conforme visto no Captulo 3, a apresentao da soluo proposta para a gerncia de handoffs em Bluetooth foi dividida em duas partes: as configuraes e atribuies de responsabilidades entre EBs e DMs para transies diretas de ponto de acesso; e o protocolo pelo
qual EBs disparam/cancelam processos de handoff e mantm DMs conectados ao sistema
enquanto estes se movem.
A avaliao da soluo proposta segue a mesma diviso. Para avaliar a transio direta
entre EBs um prottipo foi implementado, enquanto o funcionamento do protocolo das EBs
foi modelado e verificado utilizando Redes de Petri Coloridas (CPN 1 ). Detalhes da implementao do prottipo e cenrios de testes so descritos na Seo 4.1, enquanto a anlise
sobre o modelo CPN apresentada na Seo 4.2.
4.1
Transies entre EBs
Um prottipo, contemplando as entidades lgicas, configuraes, e responsabilidades

definidas na Seo 3.2, foi implementado para avaliar o real impacto da troca de EBs sobre
fluxos de dados em tempo-real em trnsito pelas interfaces Bluetooth de EBs e DMs. Alm
da implementao do aparato para gerncia de handoffs definido na Seo 3.2, tambm foi
desenvolvido um sistema simples para transmitir streams de um servidor na rede cabeada
para dispositivos mveis que se movem entre as reas de cobertura de duas EBs. De fato, a
infra-estrutura implementada para os testes uma implementao parcial da infra-estrutura
1
Coloured Petri Nets
57
4.1 Transies entre EBs
58
descrita no Apndice C.
Uma viso geral do ambiente desenvolvido para os testes ilustrada na Figura 4.1. No
ambiente montado, EBs e servidor de streams esto ligados mesma rede local. O servidor
armazena e transmite via streaming contedo multimdia pr-gravado. Junto com o software
para gerncia de handoff rodando em cada EB funciona uma aplicao externa, responsvel
por atuar como consumidora do stream em benefcio do DM (vide Seo 4.1.1 e Apndice
C). Tanto o servidor de streams quanto EBs so computadores de mesa convencionais enquanto um notebook foi utilizado como DM. Um resumo das caractersticas fsicas de cada
uma destas entidades descrito na Tabela 4.1.
Servidor
EB2
DM1
EB1
Aplicao
L2cap
HCI
Servidor
Hardware
Bluetooth
Aplic.
TCP/IP
EB2
HoSP
HoSP
HoSP
Servidor
Streams
Aplic.
TCP/IP
L2cap
L2cap
Hardware
Bluetooth
HCI
EB1
Hardware
Bluetooth
HCI
DM1
Figura 4.1: Viso geral da estrutura criada para testes.
4.1.1
O Ambiente de Testes
Todos os softwares usados foram desenvolvidos em C++ [68]. O servidor de streams

utilizado um dos programas exemplo (testMP3Streamer) que acompanham a biblioteca
Live555 [41]. Este programa exemplo l repetidamente um arquivo MP3, jogando na rede
local um stream do seu contedo usando RTP/RTCP num endereo multicast. Nas EBs,
as funcionalidades necessrias para os testes foram divididas em mdulos, quase todos implementadas como componentes de uma mesma aplicao, HoSP (sigla para Handing off
Streams Profile), conforme esquema na Figura 4.2(a), exceo da aplicao responsvel

Entidade
Dispositivo
Servidor
Computador de mesa
59
Configurao
Notas Adicionais
Athlon 64; Ubuntu Linux; Kernel

2.6.15-28; 2GB de RAM; Ethernet 100Mbps
EBs
Computador de mesa
DM
Notebook
Athlon 64; Ubuntu Linux; Kernel
Foram instaladas verses espec-
2.6.22-rc6; 2GB de RAM; eth-
ficas do BlueZ [51] e do Ker-
ernet 100Mbps; Interfaces Blue-
nel, diferentes das verses atual-
tooth 2.0 + EDR Broadcom mod-
mente estveis para o Ubuntu,
elos USB-200 e USB-250; Pilha
para poder usar os recursos de
Bluetooth BlueZ v3.12
EDR das interfaces Bluetooth.
Pentium 4 HT; Ubuntu Linux;

Kernel 2.6.22-rc6; 512MB de
RAM; Interfaces Bluetooth 2.0 +
EDR Broadcom modelos USB200 e USB-250; Interface Bluetooth 2.0 + EDR CSR; Pilha
Bluetooth BlueZ v3.12
Tabela 4.1: Resumo das caractersticas dos dispositivos usados para testes.
por interagir com o servidor de streams. Esta aplicao uma verso modificada de outra
aplicao exemplo (testMP3Receiver) que acompanha a Live555, alterada para encaminhar
para o HoSP os pacotes RTP recebidos a partir do testMP3Streamer.
Nas EBs, os mdulos Status Update Sender e Status Update Listener so usados para,
respectivamente, enviar e escutar mensagens de mudanas de estados em DMs. O MD Monitor foi implementado conforme Algoritmo 3.1. Para implementar o Link Monitor, a medida de RSSI
foi escolhida como heurstica para deteco de mudanas entre os estados
CONECTADO e SOB_HANDOFF. Para os testes realizados, o ponto limiar para disparo do

handoff foi definido em aproximadamente seis metros de distncia a partir da EB, sendo o
valor do RSSI nesse ponto usado para disparar as transies de estado entre CONECTADO
e SOB_HANDOFF. O MD Registry foi implementado como uma lista em memria dos
dispositivos atualmente conectados EB.
Para ter acesso s informaes e conectividade necessria por seus mdulos, o HoSP
2
Receive Signal Strength Indication.
60
HoSP
Status
Update
Sender
MD
Monitor
Link
Monitor
L2cap
HCI
Hardware
Bluetooth
Aplicao
Status
Update
Listener
HoSP
Connection
Connection
Connection
Listener
Listener
Listener
Connection
Monitor
Connection
Monitor
MD
Registry
L2CAP
Aplic.
TCP/IP
Hardware
Bluetooth
HCI
(a) Componentes lgicos das EBs usadas para
(b) Componentes lgicos dos DMs usados para
testes.
testes.
Figura 4.2: Estrutura lgica das EBs implementadas para testes.

tm acesso direto camada HCI e rede local TCP/IP. No enlace com DMs a troca de dados
feita via L2CAP. Por fim, o ltimo mdulo da EB a aplicao responsvel pelo contato com
o servidor de streams. Este mdulo, implementado a partir do testMP3Receiver, encarregase de captar na rede TCP/IP os pacotes RTP transmitidos pelo servidor e pass-los para o
HoSP para que este faa o encaminhamento dos dados via enlace sem fio com o DM.
Os mdulos que compem o software que executa no cliente so ilustrados na Figura
4.2(b).
O Connection Monitor constantemente verifica o estabelecimento e perda de
conexes com EBs. Em sua implementao, o Connection Monitor delega para a ferramenta hcitool, que acompanha o BlueZ, a tarefa de consultar a interface Bluetooth sobre as
conexes atualmente ativas. O Connection Monitor interpreta a sada do hcitool, mantendo
um pequeno histrico de conexes previamente estabelecidas, suficiente para identificar e
lanar eventos de estabelecimento e perda de conexes. O aspecto mais relevante da camada HoSP nos DMs, do ponto de vista dos testes executados, sua capacidade de criar e
destruir Connection Listeners medida que conexes baseband so estabelecidas ou perdidas. Cada Connection Listener escuta dados que chegam pela respectiva conexo baseband,
repassando-os para a aplicao que faz o tratamento apropriado. Por fim, a aplicao final
no implementa nem buffers de recepo nem qualquer mecanismo para renderizao dos
dados recebidos. Os pacotes RTP so processados to logo sejam recebidos, onde o proces-
61
samento consiste em extrair e escrever sua carga til na sada padro.

Cada teste foi acompanhado de uma avaliao subjetiva. No escopo dos testes executados, a avaliao subjetiva consistiu em reproduzir os streams recebidos medida que estes
chegavam no dispositivo cliente. As avaliaes dos streams recebidos so ditas subjetivas pois cabe pessoa que executa o teste acompanhar a reproduo do stream e dar sua
opinio sobre a qualidade da reproduo. Para as avaliaes subjetivas uma outra aplicao,
o gstreamer [21], foi utilizada para a renderizao dos dados. Para a reproduo dos dados pelo gstreamer, a sada da aplicao era direcionada via pipes para a entrada padro
do gstreamer. Nas avaliaes subjetivas o udio recebido no DM era imediatamente reproduzido em seus auto-falantes. A qualidade da reproduo era ento avaliada pelo usurio.
Uma vez discutidos os elementos lgicos implementados/usados/modificados, o funcionamento geral do ambiente de testes pode ento ser descrito. O servidor de streams
continuamente joga na rede local o stream do arquivo MP3 lido usando RTP/RTCP via multicast. Assim que o DM se conecta EB, o Connection Monitor da EB detecta a conexo do
cliente, abre uma conexo L2CAP com aquele dispositivo e solicita aplicao o incio do
repasse do stream. Ao mesmo tempo, so criadas instncias do MD Monitor e do Link Monitor para monitorar mudanas de estado do DM enquanto conectado quela EB. A aplicao
ento comea a escutar a rede cabeada pelos pacotes RTP que esto sendo enviados pelo
servidor. Cada pacote ento repassado para o HoSP, que encapsula os pacotes RTP em
mensagens L2CAP para serem enviadas para o DM. Do lado do DM, cada pacote, assim que
recebido pelo HoSP, repassado para a aplicao. A aplicao verifica o campo Sequence
Number do pacote RTP [60] para checar numa tabela local se aquele pacote j foi recebido.
Caso esta seja a primeira cpia daquele pacote a chegar no DM, seu nmero guardado na
tabela anteriormente consultada e o pacote processado pela aplicao.
Quando o Link Monitor reporta uma mudana no estado do DM para SOB_HANDOFF,
o MD Monitor envia uma mensagem de mudana de estado para a segunda EB com o
BD_ADDR do DM. Por simplicidade, a segunda EB automaticamente dispara o handoff
para o dispositivo com o BD_ADDR indicado, ao invs de comparar circunstncias para o
disparo ou no de handoffs, conforme descrito no Cdigo Fonte 3.2. Assim que consegue
conexo com o DM, o HoSP da segunda EB estabelece conexo L2CAP com o dispositivo,
requisita para a aplicao o repasse dos dados do stream sendo consumido pelo DM, e inicia
62
o encaminhamento dos dados via enlace sem fio. Do lado do cliente, o Connection Monitor
detecta a presena de nova conexo e reporta o evento para o HoSP, que cria um novo Connection Listener para a nova conexo e passa a receber dados vindos da nova EB. Os dados
so repassados para a aplicao, que os trata da maneira descrita anteriormente.
4.1.2
Cenrios de Testes
Nesta seo so apresentados os resultados obtidos a partir de testes no ambiente descrito

na Seo 4.1.1. Para os testes aqui descritos, foi utilizado o mesmo arquivo MP3, codificado numa taxa de 320 Kbps, como fonte do stream consumido pelo DM. Para efeitos de
comparao com os resultados a seguir, na Figura 4.3 so mostrados o grfico da chegada de
pacotes RTP desse stream no DM (Figura 4.3(a)) e o grfico com os atrasos de cada pacote
em relao ao pacote anterior (Figura 4.3(b)). No grfico de chegada de pacotes, Figura
4.3(a), so mostrados os momentos em que chegaram cada pacote RTP durante o tempo que
o teste foi executado. No eixo das ordenadas so representados os nmeros dos pacotes na
seqencia aleatria gerada pelo RTP, e no eixo das abscissas representado o tempo. O
perodo de tempo ilustrado na Figura 4.3(a) inicia-se no momento zero e encerra-se aps 15
segundos de teste. A linha diagonal e sem quebras exibida no grfico demonstra a recepo
perfeita do stream usado nos testes e pode ser usada como parmetro para comparao com
os demais grficos. O resultado do segundo grfico, ilustrado na Figura 4.3(b), complementa
a informao do primeiro grfico. Na Figura 4.3(b) so ilustradas as variaes nos intervalos
de chegada dos mesmos pacotes representados na Figura 4.3(a). Neste grfico, no eixo das
abscissas so representados os nmeros dos pacotes RTP recebidos durante o teste. No eixo
das ordenadas so representados os intervalos entre as chegadas de pacotes consecutivos da
seqencia. Isto , para cada pacote recebido durante o teste foi medida a diferena entre
o momento de sua chegada e o momento da chegada do pacote anterior da seqencia. No
grfico so ilustrados os atrasos de todos os pacotes de seqencia. Naturalmente existe alguma variao entre os tempos de chegada de diferentes pacotes. Entretanto, existe alguma
tolerncia quanto a estas variaes devido ao tempo que o contedo de cada pacote leva pra
ser processado pela aplicao que faz sua reproduo. O resultado ilustrado na Figura 4.3(b)
representa uma reproduo perfeita do stream usado. Estes grficos so utilizados aqui como
medida de comparao. A informao sobre a qualidade da reproduo do stream no de-
63
duzida diretamente a partir do grfico, mas sim da avaliao subjetiva que acompanhou o
teste que gerou os grficos da Figura 4.3, assim como e os demais testes.
Para gerar esses grficos comparativos foram utilizadas tanto no DM quanto na EB interfaces Broadcom modelo USB-200. Os dados recebidos nesse teste foram redirecionados
para o gstreamer, que reproduziu perfeitamente o stream do MP3.
Antes do teste definitivo de handoff, foram feitos alguns experimentos para encontrar
valo-res para o page scan window e page scan interval de forma a manter suave a transmisso do stream e diminuir o tempo de paging durante handoffs. Na Figura 4.4 so ilustrados
os mesmos grficos de chegada de pacotes e de atrasos inter-pacotes, mostrados anteriormente, para os valores escolhidos de page scan window e page scan interval (18 e 256 slots,
respectivamente). Uma relao completa dos testes para determinar os parmetros do paging usados nos testes a seguir pode ser encontrada no Apndice A, junto com uma breve
discusso sobre o critrio usado para a escolha destes valores. Mesmo com o visvel aumento na oscilao nos intervalos entre chegadas de pacotes, a avaliao subjetiva do stream
que originou os grficos da Figura 4.4 revelou uma reproduo suave do udio, sem falhas
perceptveis.
Para o teste de handoff, cada teste aconteceu da seguinte maneira: primeiro o DM
conecta-se primeira EB e inicia a recepo do stream. Um usurio ento move-se junto
com o DM para distante da EB at o ponto onde o handoff era disparado. A primeira EB,
aps notificar para a segunda sobre a mudana de estado do DM, iniciava um temporizador
de 5s para desconecta-la do DM. O usurio conhece o local de sua trajetria onde o handoff disparado, indicado com uma marcao no cho. Uma vez ultrapassado esse ponto, o
usurio mudava sua direo, voltando para prximo da segunda EB.
O resultado do teste mostrado na Figura 4.5. Para esse teste, foram utilizadas interfaces
Broadcom modelo USB-200 tanto nas EBs quanto no DM. Neste teste, o handoff comea
aproximadamente no momento 10s e dura em torno de 5s, quando a conexo com a primeira
EB perdida e o DM permanece conectado apenas segunda EB. Na Figura 4.5(a) so
mostradas as chegadas de cada pacote RTP da seqencia e sua origem (primeira EB ou segunda EB), enquanto na Figura 4.5(b) so mostrados os intervalos entre as chegadas de cada
pacote. Durante o perodo onde o DM est conectado a mais de uma EB, so mostrados tambm na Figura 4.5(a) os pacotes descartados. Conforme os grficos sugerem, se comparados
64
(a) Chegada dos pacotes RTP no DM.
(b) Intervalos entre as chegadas de cada pacote RTP no DM.
Figura 4.3: Dados de referncia da transmisso do stream de 320 Kbps para o DM, sem
handoff.
com os grficos da Figura 4.4, no houve abalo perceptvel na recepo do stream, mesmo
durante o paging e o perodo de handoff. O fluxo de pacotes manteve-se constante enquanto
o DM estava conectado s duas EBs, e a filtragem de pacotes redundantes no DM cumpriu
com seu papel, descartando pacotes RTP que chegaram em duplicata e/ou atrasados. A avali-
65
(a) Chegada de pacotes RTP usando no DM page scan window = 18, e page scan interval = 256
(b) Intervalos entre as chegadas de pacotes RTP usando no DM page scan window = 18, e page scan interval
= 256
Figura 4.4: Dados sobre a chegada dos pacotes RTP aps ajuste dos parmetros do paging.
ao subjetiva confirmou uma reproduo suave do stream, sem alteraes perceptveis no
udio recebido.
Este mesmo teste foi repetido usando interfaces Broadcom modelo USB-250 e o Internet
Tablet N800 da Nokia. Este ltimo possui interface Bluetooth 2.0 + EDR integrada. Nos
66
(a) Chegada dos pacotes RTP no DM durante handoff.
(b) Intervalos entre as chegadas de cada pacote RTP no DM durante handoff.
Figura 4.5: Dados da transmisso do stream de 320 Kbps para o DM durante handoff.
dois casos, os resultados foram semelhantes aos resultados ilustrados na Figura 4.5. Devido
grande semelhana dos grficos gerados a partir desses testes com os grficos da Figura
4.5, sua exposio neste trabalho foi considerada redundante.
Num segundo teste, a interface Bluetooth do DM foi substituda pela interface CSR 3 . Os
3
Cambridge Silicon Radio.
67
resultados desse novo teste, usando o mesmo cenrio descrito anteriormente (com exceo
da interface que foi substituda) so mostrados na Figura 4.6.
(a) Chegada dos pacotes RTP no DM durante handoff usando interface CSR.
(b) Intervalos entre as chegadas de cada pacote RTP no DM durante handoff usando interface CSR.
Figura 4.6: Dados da transmisso do stream de 320 Kbps para o DM durante handoff usando
interface CSR.
Neste experimento, a recepo do stream comea de maneira normal, similar aos testes
anteriores. Entretanto, durante o perodo onde o DM est conectado s duas DMs, a recepo
4.2 Validao do Protocolo
68
de dados alterada por uma reduo na largura de banda de cada conexo. No grfico, a
reduo na largura de banda de recepo do DM revelada pela diminuio da inclinao
da linha do grfico em relao ao eixo das abscissas. Uma linha com menor inclinao
em relao ao eixo x significa que menos pacotes esto sendo recebidos por unidade de
tempo. Durante todo o tempo que o DM esteve conectado a mais de uma EB a largura de
banda de recepo do DM foi reduzida. Esta reduo na largura de banda evidenciada
tambm no segundo grfico, ilustrado na Figura 4.6(b). Nesta figura, os pacotes recebidos
enquanto o DM estava conectado a mais de uma EB apresentam maiores intervalos de interchegadas. Esse aumento ilustrado pelo pico no grfico. A avaliao subjetiva para esse teste
revelou considerveis rudos e pausas na reproduo do udio durante o handoff. A queda na
qualidade das conexes baseband, verificada na Figura 4.6, provavelmente conseqncia
de uma estratgia de TDM fraca implementada na interface CSR, reflexo de uma interface
de m qualidade.
4.2
Validao do Protocolo
Nesta seo so apresentadas a especificao e validao formais, usando modelos de redes

de Petri coloridas, do protocolo proposto na Seo 3.3. Para a edio e anlise dos modelos
foi utilizada a ferramenta CPN Tools 4 . A importncia da especificao formal est no fato
de garantir que o protocolo se comporta da forma esperada em qualquer situao de funcionamento e prever possveis comportamentos emergentes em situaes no previstas na
definio do mesmo. Alm disso, um modelo formal serve de documentao precisa para
divulgao, publicao, reproduo, mudanas, e adaptaes do protocolo, visto que permite
um melhor entendimento deste.
4.2.1
Modelagem
Na modelagem do protocolo, os DMs esto inicialmente desconectados. Eventualmente

estes dispositivos podem conectar-se a uma EB. A partir do momento que o dispositivo
est conectado a uma EB, ele pode se movimentar, eventualmente disparando o processo de
handoff. Como visto no Captulo 3, disparar o processo de handoff envolve procedimentos
4
http://wiki.daimi.au.dk/cpntools/cpntools.wiki
69
de mais baixo nvel, como a estimao da distncia entre EB e DM, que so abstrados do
modelo. modelado, entretanto, o conceito de estado do dispositivo, que acompanhado
atravs dos registros das EBs. Os estados podem ser OFF (desconectado), CONNECTED
(conectado) e HANDOFF. A mudana de estados percebida pela EB onde o DM est
conectado que, por sua vez, atualiza seu registro e comunica as EBs vizinhas. Portanto, so
tratados no modelo a atualizao dos registros e as mensagens de notificao.
[
1
[
d
,
1
[
(
[
d
1
[
d
2
i
u
1
3
N
[
d
[
d
1
e
e
1
n
i
;
s
h
F
,
s
[
d
[
g
i
1
)
e
i
e
L
i
Figura 4.7: Modelo CPN para o protocolo de handoff entre EBs.

Na Figura 4.7 ilustrado o modelo em redes de Petri para o protocolo. O lugar inicial do
modelo Out, significa que o dispositivo est desconectado, ou seja, fora da rede. A transio
Connect representa o procedimento de conexo do dispositivo, o que feito aleatoriamente
a qualquer EB presente no sistema, atravs da distribuio discreta discrete(1,m) onde m o
nmero de EBs presentes no sistema. Neste ponto, o estado do dispositivo atualizado para
conectado no lugar Regs, que armazena os registros com os DMs, seus estados, e EBs onde
esto conectados.
70
Uma vez no estado conectado, o dispositivo pode se des-conectar, evento representado

pelo disparo da transio Disconnect. O dispositivo pode ainda se movimentar e disparar o
processo de handoff, evento representado pelo disparo da transio Start Handoff. Quando
isto ocorre, o estado do dispositivo atualizado para handoff e enviado um conjunto de
notificaes a todas as EBs vizinhas da EB qual o dispositivo est localizado. Desta forma
essas vizinhas tentam se conectar ao dispositivo. No lugar Notification guardada uma
estrutura com a EB na qual o DM est atualmente conectado, mais a lista de todas as EBs
que esto tentando contato com o DM.
Neste ponto o dispositivo pode realizar duas transies: se desconectar, atravs do disparo da transio DiscHO; ou se conectar a um vizinho, atravs do disparo da transio
Connect2. Ao se conectar a um vizinho o registro atualizado para refletir o fato de que o
dispositivo est agora conectado a duas EBs ao mesmo tempo. Alm disso, a lista de EBs
com pedidos de handoff ativos para o DM tambm alterada e passa a ser a interseco
de vizinhos dessas duas estaes base, que mantm ativos seus pedidos de handoff para o
dispositivo em questo.
Quando o dispositivo est conectado a duas estaes base, trs situaes podem ocorrer.
Assim como nos outro casos, o dispositivo pode se desconectar, atravs do disparo da transio DiscFinal. O dispositivo pode ainda finalizar o handoff, ou seja, ficar com apenas uma
conexo ativa, aquela com a EB mais prxima, fato representado pelo disparo da transio
FinishHO. Neste caso, o registro atualizado removendo da lista de estaes base a anterior
e ficando apenas a atual, o estado atualizado para conectado, e a lista de EBs com pedidos de handoff ativos para o DM esvaziada. O ltimo caso acontece quando o dispositivo
continua se movendo, mas no em direo exata vizinha. Neste caso, pode ocorrer de o
dispositivo no finalizar o handoff, sair da rea de cobertura da primeira e entrar na rea de
cobertura de uma terceira estao, que est na interseco das duas primeiras. Este fato
representado pelo disparo da transio Keep Walking, que atualiza o registro do dispositivo
para representar o fato que mudou a lista de estaes base as quais o dispositivo est conectado e, conseqentemente, a lista de notificaes deve ser atualizada para a nova interseco
de vizinhos.
importante notar que o modelo reflete as situaes de que o dispositivo pode se desconectar a qualquer momento do sistema e que pode ficar indefinidamente em handoff sem
71
nunca finalizar um handoff. Este ltimo caso reflete a possibilidade geral de o dispositivo
se movimentar aleatoriamente na rede, nas reas de sombra das estaes base. Apesar de
no termos dados estatsticos da ocorrncia de determinadas situaes em redes sem fio, o
objetivo do protocolo ser genrico e prover conexo em qualquer circunstncias de movimentao, exceto nos casos em que o prprio dispositivo se desconecta da rede ou em que
no existem mais vagas disponveis para conexo na piconet de uma determinada estao
base.
Na prxima seo so apresentados os cenrios e resultados da anlise usando o modelo
de redes de Petri apresentado nesta seo e ilustrado na Figura 4.7.
4.2.2
Validao
A validao do modelo apresentado na Seo 4.2.1, e conseqentemente do protocolo representado por ele, aconteceu em duas etapas: gerao e anlise de diagramas de seqencia de
mensagens, MSCs 5 , para diversos cenrios de simulao; e verificao formal do modelo
por propriedades de interesse.
Cada MSC gerado a partir de um cenrio de simulao do modelo CPN. Cada transio
no modelo CPN convertido em uma seqencia de mensagens nos MSCs. O cenrio de
simulao escolhido para exemplificar a anlise do modelo CPN via MSC o mesmo cenrio
ilustrado na Seo 3.3. Neste cenrio o dispositivo Dev conecta-se inicialmente EB BSD .
O dispositivo move-se ento em direo a BSE , iniciando o processo de handoff, e continua
movendo-se em direo a BSC mas no em linha reta, mas pela borda da rea de cobertura
de BSE . O cenrio da simulao encerra-se quando o Dev aproxima-se de BSC e assume o
estado CONECTADO nesta EB. Na Figura 4.8 mostrado o MSC gerado para este cenrio
a partir do modelo da Seo 4.2.1.
Primeiro, Dev conecta-se ao sistema na EB BSD , evento ilustrado no MSC pela mensagem Connect enviada de Dev para BSD . Aps a conexo de Dev, BSD notifica seus
vizinhos BSA , BSB , BSE , BSG , e BSH sobre seu contato com Dev e que este se encontra
no estado CONECTADO. No MSC essas mensagens so representadas pelas mensagens Dev
connected. Todas essas mensagens no MSC so resultado do disparo da transio Connect
no modelo ilustrado na Figura 4.7. Dev ento comea a se mover pela rea de cobertura de
5
Message Sequence Charts
Figura 4.8: Diagrama de seqencia para exemplo ilustrado na Figura 3.8.
72
73
BSD , at o momento em que atravessa o ponto limiar para o disparo do handoff. Neste ponto,
BSD notifica suas vizinhas sobre a mudana de estado de Dev, evento representado no MSC
pelas mensagens Dev starting handoff. Estas mensagens so geradas quando a transio Start
Handoff disparada no modelo. Como Dev se move em direo a BSE , esta a primeira
EB a conseguir contato com Dev. Uma conexo entre Dev e BSE estabelecida, evento representado pela mensagem Connect no MSC. Aps o estabelecimento desta conexo, BSE
envia uma notificao para todas as suas vizinhas, avisando do seu contato com Dev no estado SOB_HANDOFF (mensagens Dev connected on handoff no MSC). Neste momento,
Dev est conectado ao mesmo tempo com BSD e BSE .
Quando BSD recebe a notificao de BSE ele a repassa s suas vizinhas, evento representado no MSC pelas mensagens Dev connected to another BS. Esta mensagem serve para
que EBs que no so vizinhas de BSE possam cancelar seus pedidos de handoff para Dev.
Neste momento, apenas as EBs que so vizinhas tanto de BSD quanto de BSE , no caso
BSB e BSH , continuam com pedidos de handoff ativos para Dev. No modelo, todas essas
mensagens so geradas junto com o disparo da transio Connect2 do modelo.
Neste momento, Dev comea a mover-se pela rea de sombra de BSE . Em sua trajetria,
Dev entra na interseco entre as reas de cobertura de BSB e BSE , estabelecendo contato
com BSB . Este evento, e a notificao de BSB sobre seu contato com Dev, so indicados
pelas mensagens Connect e Dev connected on handoff no MSC. Adicionalmente, o contato
entre Dev e BSD perdido. Quando isso acontece, BSD notifica suas vizinhas sobre a
perda de contato com Dev, evento representado pelas mensagens Connection with Dev lost
no MSC. Estes eventos so gerados pelo modelo CPN quando a transio KeepWalking
disparada. Esta transio ser disparada mais uma vez, indicando que Dev se moveu da
interseco das reas de cobertura de BSB e BSE para a interseco das reas de cobertura
de BSC e BSE .
Finalmente, o cenrio de simulao encerra-se com o dispositivo totalmente conectado
EB BSC . Primeiro, baseado na aproximao de Dev, BSC notifica seus vizinhos sobre a
mudana de estado de Dev para CONECTADO enviando as mensagens Dev fully connected
no MSC. Em seguida, BSE notifica seus vizinhos sobre a perda de contato com Dev. O
cenrio acaba com o disparo da transio FinishHO.
Como dito anteriormente, o MSC mostrado na Figura 4.8 foi gerado a partir do modelo
74
CPN ilustrado na Figura 4.7. A gerao de MSCs acontece de forma automtica junto com a
simulao do modelo usando a biblioteca apropriada do CPN Tools. As mensagens so automaticamente geradas baseado nos valores das fichas nos lugares de entrada das transies.
Foram gerados diversos MSCs, com diferentes tamanhos e disposies de EBs, e em todos
os casos o comportamento registrado nos MSCs estava de acordo com o comportamento
esperado pela definio do protocolo.
Alm da gerao e anlise dos MSCs, tambm foram feitas verificaes formais sobre o
modelo em busca de certas propriedades. Mais especificamente, foram adicionadas algumas
transies adicionais para que dispositivos, aps perderem contato com as EBs do sistema,
pudessem se conectar novamente. Aps essa alterao, verificou-se que o modelo no possui
marcaes mortas e que sempre possvel retornar marcao inicial. Em outras palavras,
um dispositivo pode sempre conectar-se e desconectar-se das EBs do domnio de mobilidade
sem interrupes em suas conexes com as EBs devido problemas decorrentes do protocolo
de monitorao de DMs. Obviamente, problemas de descontinuidade nas conexes de DMs
podem acontecer em conseqncia de falhas no mdulo para deteco de mudanas de estado
dos DMs ou ainda devido falta de recursos nas EBs de destino.
Captulo 5
Consideraes Finais
Neste captulo so feitas as consideraes finais sobre o trabalho apresentado. So apresentadas discusses sobre os resultados obtidos, assim como uma discusso relativa a possveis
temas futuros de pesquisa, para dar continuidade ao trabalho apresentado ao longo desse
documento.
5.1
Concluses
Neste trabalho foi apresentado um protocolo para gerncia de handoffs em WPANs Bluetooth
no contexto de aplicaes de tempo-real. A soluo introduzida contempla tanto a alocao
de responsabilidades quanto configuraes relacionados transio direta de DMs entre EBs.
Adicionalmente, tambm foi definido o protocolo pelo qual EBs trocam informaes para
manter o DM conectado medida que este se move atravs de suas reas de cobertura.
O protocolo apresentado voltado para o uso com aplicaes que demandam transferncias de dados em tempo-real, sendo sua adequao para esse tipo de aplicao demonstrada atravs de experimentos com uma aplicao de streaming de udio. Os resultados
descritos no Captulo 4 demonstram a viabilidade e encorajam o desenvolvimento de um
nmero de aplicaes sobre o protocolo introduzido, tais quais as descritas no Apndice B.
Considerando que as taxas de transmisso dos streams usados para os testes naquele captulo so razoavelmente altas, em torno de 320 Kbps, resultados ainda melhores devem ser
obtidos quando streams com taxas de transmisso mais realistas sejam usados. Por exemplo, contedo de udio comumente codificado como MP3 numa taxa de 128 Kbps. Em
75
5.1 Concluses
76
aplicaes de telefonia pela Internet, por exemplo, CODECs modernos, como G.729A [73],
conseguem codificar dados para transmisses de at 8 Kbps mantendo-se a mesma qualidade de CODECs com requisitos de banda maiores [73]. Larguras de banda entre 64 e 384
Kbps so comuns e suficientes para streaming de vdeo para dispositivos mveis usando
MPEG4 [76].
O protocolo apresentado foi projetado focando-se as limitaes dos potenciais dispositivos clientes, ou seja, pequenos dispositivos mveis com pouco poder de processamento,
pouca memria, e largura de banda restrita. Dessa forma, todas as atividades relativas
monitorao de DMs e gerncia de handoffs foram transferidas para as EBs. O protocolo
apresentado descarta ainda a necessidade de coordenao, sinalizaes ou quaisquer outras
trocas de mensagens entre DMs e EBs durante os handoffs. O nico requisito sobre a participao do DM em todo o processo que este mantenha-se conectvel enquanto move-se
pelo domnio de mobilidade. Opcionalmente, DMs podem ainda ajustar os parmetros page
scan window e page scan interval. Com ajustes adequados desses valores reduz-se o nmero
de slots da EB de destino necessrios para a conexo com o DM sob handoff, conseguindo
portanto um contato mais rpido com o DM. Com um gasto menor de slots reduz-se ainda
o impacto do paging sobre outros DMs conectados na EB de destino. Por utilizar apenas
operaes padronizadas do Bluetooth, viabiliza-se o uso do protocolo proposto junto com
qualquer dispositivo programvel equipado com interface Bluetooth de acordo com a especificao, sendo portanto dispensada a necessidade de, por exemplo, alteraes em camadas
inferiores de software, como a pilha Bluetooth.
Aplicaes de tempo-real, particularmente aquelas que envolvem transmisso de dados
via rede, possuem fortes requisitos quanto transmisso/recepo de suas informaes.
Gerenciar handoffs levando-se em conta esse tipo de aplicao significa buscar os meios
pelos quais conexes podem ser estabelecidas e desfeitas com o mnimo de impacto sobre a
disponibilidade do canal de comunicao. A soluo aqui introduzida descarta a operao
de inquiry durante os handoffs e explora a capacidade de Bluetooth de mltiplas conexes
simultneas para gerenciar soft handoffs, evitando assim a perda total de conectividade do
DM enquanto este se move atravs das reas de coberturas de diferentes EBs.
O trabalho aqui apresentado discute ainda outras facetas do relacionamento entre
aplicaes de tempo-real e gerenciamento de handoffs em Bluetooth.
Por exemplo,
5.1 Concluses
77
compreendeu-se o relacionamento entre aplicaes de tempo-real e os constantes chaveamentos da interface para escutar por tentativas de pagings e inquiries, assim como os procedimentos de disparo e resposta dessas operaes. Vimos que o simples ajuste dos parmetros do paging suficiente para reduzir o tempo de conexo para algo em torno de 10 ms
(16 slots). Entretanto, temos que na prtica dificilmente esse desempenho ser alcanado
levando-se em conta o trfego de dados em tempo-real pelas interfaces Bluetooth devido ao
impacto dessa configurao na disponibilidade do canal.
Os resultados obtidos com a interface CSR avaliada mostram que interfaces de menor
qualidade podem no ser adequadas para aplicaes de tempo-real mais exigentes, como
telefonia. Entretanto, essas interfaces podem ser utilizadas em aplicaes similares s tradicionais aplicaes de streaming, onde buffers podem ser empregados pois um atraso de alguns segundos na reproduo do stream, ou eventuais paradas para recarregar o buffer, no
comprometem a aplicao. Neste caso, buffers ocultariam das aplicaes finais a queda na
largura de banda disponvel aplicao durante o handoff.
Infelizmente, nenhum dos trabalhos relacionados conhecidos at o momento da escrita
desse trabalho apresentam dados suficientes sobre sua adequao ou no para o funcionamento com aplicaes de tempo-real [13; 30; 20; 11; 35; 10; 31; 3; 70]. Por isso, no
possvel fazer uma anlise comparativa entre os resultados aqui obtidos e os resultados de
outros trabalhos.
Por fim, a modelagem e anlise serviu para validar o protocolo atravs de simulaes,
mostrando que o protocolo se comporta de acordo com o comportamento especificado na
Seo 3.3 para vrios cenrios. Atravs da verificao formal do modelo criado provaram-se
propriedades importantes, a principal delas que o protocolo cumpre seu papel de manter
DMs que se movem pelo domnio de mobilidade conectados a pelo menos uma EB.
A soluo apresentada delega para o Link Monitor a tarefa de implementar as heursticas
necessrias para a localizao de dispositivos. Devido essa delegao de responsabilidade, a
soluo de gerenciamento de handoffs apresentada pode ser afetada por ms implementaes
do Link Monitor. Ou seja, informaes pouco precisas, ou tardias, sobre a localizao de
dispositivos podem causar desde disparos de procedimentos de handoff no necessrios,
total perda de conectividade de DMs em movimento devido ao no envio de mudanas no
seu estado por parte de sua EB de origem.
5.2 Trabalhos Futuros
5.2
78
Trabalhos Futuros
Como visto ao longo deste documento, a questo da gerncia de handoffs um problema

amplo. Para a conduo deste trabalho uma srie de suposies precisaram ser feitas, assim
como uma cuidadosa delimitao do problema a ser resolvido. Nesse contexto alguns tpicos
para trabalhos futuros so discutidos a seguir.
5.2.1
Definio de uma Soluo Escalvel
Como brevemente discutido na Seo 3.4, e mais detalhadamente no Apndice C, escalabilidade uma questo natural num sistema com recursos limitados e onde o nmero de usurios
pode crescer rapidamente. Assim, faz-se necessrio o desenvolvimento do conhecimento sobre como aumentar a disponibilidade de recursos disponveis no sistema, viabilizando um
maior nmero de clientes atendidos de forma simultnea. Ao mesmo tempo, aumenta-se
tambm a disponibilidade de interfaces para atender um nmero maior de handoffs simultneos.
Outra necessidade intrinsicamente ligada questo de escalabilidade consiste no desenvolvimento de mecanismos para controle de admisso nas EBs. Atravs da reduo do
nmero de handoffs simultneos que precisam ser gerenciados por uma EB, solues apropriadas para controle de admisso podem evitar tanto o desperdcio de recursos das EBs
quanto oscilaes na qualidade do servio j em uso por outros DMs. Por exemplo, caso
um DM em handoff para uma determinada EB consuma mais recursos do que os atualmente
disponveis na interface onde ele ser conectado na EB de destino, seu pedido de handoff
alm de consumir tempo para ser processado, prejudicando outros DMs tambm em handoff
para aquela EB, tende a congestionar o enlace sem fio da EB aps a admisso do DM, prejudicando o trfego de dados de todos os demais clientes ligados mesma interface. A idia
ento que dispositivos movendo-se em direo a uma EB que no tem recursos suficientes
para receb-lo devem ter seus pedidos de handoff ignorados, em benefcio de outros DMs
sob handoff para aquela mesma EB.
Nesse contexto, experincias, sucessos, e problemas j conhecidos no trabalho descrito
no Apndice C, podem ser usados como base para a evoluo da atual proposta rumo a um
sistema escalvel.
5.2.2
79
Integrao com Mecanismos de Mobilidade de Aplicaes
O trabalho aqui apresentado contemplou o processo para a troca de conexo fsica entre EBs,
que apenas o comeo de um problema maior e que envolve vrias camadas de software. Por
exemplo, ao mudar de EB, DMs podem ganhar novo endereo IP, exigindo uma atualizao
nas rotas entre o DM e outros computadores com conexes abertas com aquele dispositivo.
No caso de transferncia de dados em tempo-real, por exemplo, em algum momento o trfego
precisa ser redirecionado de uma EB para outra, assim como dados em trnsito (dados que
foram enviados por algum servidor antes deste ter sido notificado sobre a mudana de estado
do DM) precisam ser, de alguma forma, roteados corretamente para o DM aps sua mudana
de ponto de acesso. Tudo isso precisa acontecer de forma rpida, de forma a no prejudicar o
desempenho das aplicaes em curso. De outra maneira, o handoff torna-se perceptvel para
o usurio, comprometendo o funcionamento de aplicaes (por exemplo, aplicaes com
fortes requisitos temporais, como udio e vdeo) e protocolos (TCP por exemplo, devido o
uso de backoffs exponenciais para lidar com congestionamentos na rede).
A pesquisa em torno de mobilidade de aplicaes j tm longa data e diversos resultados
consolidados, como IP Mvel [48] ou Celular IP [8]. Nesse contexto, um ponto a ser investigado seria a expanso da soluo de handoff j existente em direo a camadas mais altas
da pilha de software. Pode-se investigar a integrao com solues j existentes para mobilidade de aplicaes, como as duas citadas anteriormente, ou solues prprias, voltadas para
aplicaes e cenrios especficos, podem ser desenvolvidas e acopladas ao trabalho atual.
5.2.3
Localizao e Monitorao dos Estados de Dispositivos
Outro ponto de trabalho futuro consiste em extender o componente para localizao de dispositivos implementado para os testes tendo em vista solues j existentes para localizao
e monitorao de dispositivos Bluetooth. O objetivo conhecer as vantagens e problemas de
cada alternativa, buscando aquela que melhor se encaixe nas necessidades das aplicaes/ambientes alvo. A exemplo do trabalho apresentado por Shantidev Mohanty et al. em [42],
a soluo adotada deve levar em considerao aspectos com velocidade mdia dos DMs,
atrasos envolvidos na deteco e sinalizao de handoffs, e outros parmetros do sistema,
conforme discutido na Seo 5.2.4.
5.2.4
80
Mtodos e Modelos para Calibrao do Sistema
Por fim, o ltimo tpico sugerido para investigao futura consiste em definir procedimentos
e modelos para calibrao do sistema. Ou seja, existem parmetros que podem melhorar
o funcionamento do sistema apresentado anteriormente, como reduzir o tempo dos pagings
ou a probabilidade de handoffs mau sucedidos. Como visto na Seo 2.5.3, o tempo da
ope-rao de paging pode ser reduzido ou aumentado conforme ajustes nos parmetros page
scan window e page scan interval. Nesse contexto, pode-se buscar modelos que relacionem
o comportamento da interface Bluetooth, junto com os parmetros do paging, mais as caractersticas da aplicao, de forma a sugerir valores timos, ou prximos disso, para a operao
de paging, sem prejudicar o desempenho do fluxo de dados.
Alm do ajuste dos parmetros do paging, outro atributo para calibrao do sistema consiste na busca de heursticas e/ou metodologias para definir um posicionamento timo das
EBs, assim como do ponto limiar para disparo do handoff. Se, por um lado, menos EBs so
necessrias para cobrir uma mesma rea contnua desde que estas estejam suficientemente
distantes umas das outras, por outro esse posicionamento reduz a rea de sombra entre
as EBs, o que aumenta os requisitos sobre o mdulo de localizao e monitorao de DMs,
que agora tem menos tempo de atraso tolerado para reportar a mudana de estado do DM.
O caso inverso tambm possui perdas e ganhos. Ao posicionar EBs muito prximas umas
s outras aumenta-se a rea de sombra entre as EBs, o que diminui as exigncias sobre o
mdulo de monitorao e localizao de DMs mas, em compensao, aumenta-se a quantidade de handoffs que as EBs precisam atender, alm de diminuir a quantidade de recursos no
sistema, pois sero comuns as situaes onde DMs no necessariamente esto se movendo
entre EBs, mas esto conectados a mais de uma ao mesmo tempo, desperdiando recursos.
Bibliografia
[1] Vivek
sena,
Arora,
and
namically
Larry
Agnes
forming
H.
C.
Chang,
Tow.
Seyhan
Method
multimedia
emulated
Civanlar,
and
local
Vikram
apparatus
area
R.
Sak-
for
dy-
networks.
http://www.google.com/patents/pdf/Method_and_apparatus_for_dynamically_for.pdf,
2007. Acessado em Setembro 2007.
[2] IEEE Standards Association.
IEEE 802.15 WPAN Task Group 1 (TG1).
http://www.ieee802.org/15/pub/TG1.html, 2007. Acessado em Setembro 2007.

[3] S. Baatz, M. Frank, R. Gopffarth, D. Kassatkine, P. Martini, M. Schetelig, and
A. Vilavaara. Handoff Support for Mobility with IP over Bluetooth. In Proceedings
of the 25th Annual IEEE Conference on Local Computer Networks (LCN00), pginas
143154. IEEE Computer Society, 2000.
[4] N. Banerjee, W. Wu, K. Basu, and S. Das. Analysis of SIP-based Mobility Management
in 4G Wireless Networks. Computer Communications, 27(8):697707, 2004.
[5] Paolo Bellavista, Antonio Corradi, and Carlo Giannelli. Adaptive Buffering-Based on
Handoff Prediction for Wireless Internet Continuous Services. In Proceedings of the
First International Conference on High Performance Computing and Communications
(HPCC 2005), pginas 10211032, 2005.
[6] Timothy M. Bielawa. Position Location of Remote Bluetooth Devices. Dissertao
de Mestrado, Virginia Polytechnic Institute and State University, Blacksburg, Estados
Unidos, 2005.
[7] Jennifer Bray and Charles F. Sturman. Bluetooth: Connect Without Cables. Prentice
Hall, 1 edio, 2000.
81
BIBLIOGRAFIA
[8] A.
Campbell,
82
J.
Gomez,
C-Y.
Wan,
and
S.
Kim.
Cellular
http://comet.columbia.edu/cellularip/pub/draft-ietf-mobileip-cellularip-00.txt,
IP.
1999.
Acessado em Setembro 2007.

[9] Javier Garca Castao. Algorithms and Protocols Enhancing Mobility Support for
Wireless Sensor Networks Based on Bluetooth and Zigbee. Dissertao de Mestrado,
Department of Computer Science and Electronics, Vsteras, Sucia, 2006.
[10] Wah-Chun Chan, Jiann-Liang Chen, Po-Tsang Lin, and Ka-Chin Yen. Quality-ofService in IP Services over Bluetooth Ad-Hoc Networks. Mobile Networks and Applications, 8(6):699709, 2003.
[11] Ming-Chiao Chen, Jiann-Liang Chen, and Pei-Chun Yao. Efficient Handoff Algorithm
for Bluetooth Networks. In Proceedings of the IEEE International Conference on Systems, Man, and Cybernetics Systems: Networking and Services, pginas 38843889.
IEEE Computer Society, 2005.
[12] S. Chetan, J. Al-Muhtadi, R. Campbell, and M. D. Mickunas. Mobile Gaia: A Middleware for Ad-Hoc Pervasive Computing. In Proceedings of the 2005 Consumer Communications and Networking Conference (CCNC 2005), pginas 223228. IEEE Computer Society, 2005.
[13] S. Chung, H. Yoon, and J. Cho. A Fast Handoff Scheme For IP over Bluetooth. In
Proceedings of the 31th International Conference on Parallel Processing Workshops
(ICPP 2002), pginas 5155. IEEE Computer Society, 2002.
[14] Intel
Corporation.
Ultra-Wideband
http://www.intel.com/technology/comms/uwb/index.htm,
(UWB)
2007.
Technology.
Acessado em
Setembro 2007.
[15] Antonio DeSimone, Joseph Golan, Ashok K. Kuthyar, Bryant Richard Parent, Ram S. Ramamurthy, and David Hilton Shur.
Method for managing
multicast addresses for transmitting and receiving multimedia conferencing.

http://www.google.com/patents/pdf/Method_for_managing_multicast_addresses_.pdf,
BIBLIOGRAFIA
83
[16] Anind Dey. Understanding and Using Context. Personal and Ubiquitous Computing,
5(1):47, 2001.
[17] Silke Feldmann, Kyandoghere Kyamakya, Ana Zapater, and Zighuo Lue. An Indoor Bluetooth-based Positioning System: Concept, Implementation and Experimental Evaluation. In Proceedings of the International Conference on Wireless Networks
(ICWN 2003), pginas 109113. CSREA Press, 2003.
[18] F. Forno, G. Malnati, and G. Portelli. Design and Implementation of a Bluetooth AdHoc Network for Indoor Positioning. IEE PROCEEDINGS SOFTWARE, 152(5):223
228, 2005.
[19] Alessandro Genco, Salvatore Sorce, and Giuseppe Scelfo. Bluetooth Base Station Minimal Deployment for High Definition Positioning. In Proceedings of the The Second
Annual International Conference on Mobile and Ubiquitous Systems: Networking and
Services (MOBIQUITOUS 2005), pginas 454460. IEEE Computer Society, 2005.
[20] M. L. George, L. J. Kallidukil, and J. M. Chung. Bluetooth handover control for roaming system applications. In Proceedings of the 45th Midwest Symposium on Circuits
and Systems (MWSCAS 2002), pginas I404I407. IEEE Computer Society, 2002.
[21] GStreamer.
GStreamer
Open
Source
Multimedia
Framework.
http://gstreamer.freedesktop.org/, 2007. Acessado em Setembro 2007.

[22] Timo Halonen, Javier Romero, and Juan Melero. GSM, GPRS and EDGE Performance:
Evolution Towards 3G/UMTS. John Wiley & Sons, 1 edio, 2003.
[23] M. Handley and V. Jacobson. SDP: Session Description Protocol. RFC 2327, Internet
Engineering Task Force, 1998.
[24] S. Helal, W. Mann, H. El-Zabadani, J. King, Y. Kaddoura, and E. Jansen. The Gator
Tech Smart House: A Programmable Pervasive Space. Computer, 38(3):5060, 2005.
[25] Sumi Helal. Programming Pervasive Spaces. IEEE Pervasive Computing, 4(1):8487,
2005.
BIBLIOGRAFIA
84
[26] P. Johansson, R. Kapoor, M. Kazantzidis, and M. Gerla. Personal Area Networks:

Bluetooth or IEEE 802.11? International Journal of Wireless Information Networks,
9(2):89103, 2002.
[27] P. Johansson, M. Kazantzidis, R. Kapoor, and M. Gerla. Bluetooth: An Enabler for
Personal Area Networking. IEEE Network, 15(5):2837, 2001.
[28] Val Jones, Richard Bults, Dimitri Konstantas, and Pieter AM Vierhout. Healthcare
pans: Personal area networks for trauma care and home care. In Proceedings of the
4th International Symposium on Wireless Personal Multimedia Software Composition
(WPMC 2001), pginas 13691374, 2001.
[29] E. Jovanov, D. Raskovic, J. Price, A. Moore, J. Chapman, and A. Krishnamurthy. Patient monitoring using personal area networks of wireless intelligent sensors. In Proceedings of the 38th Annual Rocky Mountain Bioengineering Symposium, pginas 373
378, 2001.
[30] Aman Kansal. A Handoff Protocol for Mobility in Bluetooth Public Access. Dissertao de Mestrado, Department of Electrical Engineering, Mumbai, ndia, 2002.
[31] Aman Kansal and UB Desai. Handoff Protocol for Bluetooth Public Access. In Proceedings of the 2002 IEEE International Conference on Personal Wireless Communicatons (ICPWC02), pginas 159162. IEEE Computer Society, 2002.
[32] E. Kirda, C. Kerer, M. Jazayeri, and C. Kruegel. Supporting Multi-Device Enabled
Web Services: Challenges and Open Problems. In Proceedings of the 10th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET ICE 2001), pginas 4954. IEEE Computer Society, 2001.
[33] Chul-Seung Lee, Dong-Jun Cho, Young-Hwan You, and Hyoung-Kyu Song. A Solution to Improvement of DS-UWB System in the Wireless Home Entertainment Network. IEEE Transactions on Consumer Electronics, 51(2):529533, 2005.
[34] Jack Y. B. Lee. Scalable Continuous Media Streaming Systems: Architecture, Design,
Analysis and Implementation. John Wiley & Sons, Ltd, 1 edio, 2005.
BIBLIOGRAFIA
85
[35] Won Hee Lee, Yang-Ick Joo, Kyun Hyon Tchah, Yongsuk Kim, and DooSeop Eom.
Handoff Provisioning in Bluetooth Wireless Personal Area Networks. IEEE Transactions on Consumer Electronics, 49(4):10041012, 2003.
[36] M. Li, Y. Fei, V. Leung, and T. Randhawa. A New Method to Support UMTS/WLAN
Vertical Handover Using SCTP. IEEE Wireless Communications, 11(4):4451, 2004.
[37] Yi-Bing Lin and Ai-Chun Pang. Comparing Soft and Hard Handoffs. IEEE Transactions on Vehicular Technology, 49(3):792798, 2000.
[38] Jane W.C. Liu. Real-Time Systems. Prentice Hall, 1 edio, 2000.
[39] Michael R. Macedonia and Donald P. Brutzman. Mbone provides audio and video
across the internet. Computer, 27(4):3036, 1994.
[40] J. McNair and Z. Fang. Vertical Handoffs in Fourth Generation Multinetwork Environments. IEEE Wireless Communications, 11(3):815, 2004.
[41] Live Media. Live555 Streaming Media. http://www.live555.com/liveMedia/, 2007.
[42] Shantidev Mohanty and Ian F. Akyildiz. A Cross-Layer (Layer 2 + 3) Handoff Management Protocol for Next-Generation Wireless Systems. IEEE Transactions on Mobile
Computing, 5(10):13471360, 2006.
[43] Loreno Oliveira, Emerson Loureiro, Hyggo Almeida, and Angelo Perkusich. Encyclopedia of Mobile Computing and Commerce, volume 2, chapter Bridging together
Mobile and Service-Oriented Computing, pginas 17. Idea Group Inc., 2006.
[44] Loreno Oliveira, Leandro Sales, Emerson Loureiro, Hyggo Almeida, and Angelo
Perkusich. Filling the Gap Between Mobile and Service-oriented Computing: Issues
for Evolving Mobile Computing Towards Wired Infrastructures and Vice Versa. International Journal on Web and Grid Services, 2(4):355378, 2006.
[45] MIT Project Oxygen. MIT Project Oxygen - Pervasive, Human-centered Computing.
http://oxygen.csail.mit.edu/, 2007. Acessado em Setembro 2007.
BIBLIOGRAFIA
86
[46] Jitendra Padhye, Victor Firoiu, Don Towsley, and Jim Kurose. Modeling TCP Throughput: A Simple Model and its Empirical Validation. ACM SIGCOMM Computer Communication Review, 28(4):303314, 1998.
[47] C. Perkins. Mobile Networking in the Internet. Mobile Networks and Applications,
3(4):319334, 1998.
[48] C. Perkins. IP Mobility Support. http://www.ietf.org/rfc/rfc2002.txt, 2002. Acessado
em Setembro 2007.
[49] Ramjee Prasad and Liljana Gavrilovska. Research Challenges for Wireless Personal
Area Networks. In Proceedings of the 3rd International Conference on Information,
Communications and Signal Processing (ICICS 2001), 2001.
[50] Ramjee Prasad and Luis Munoz. WLANs and WPANs towards 4G Wireless. Artech
House Publishers, 1 edio, 2003.
[51] BlueZ Project. BlueZ - Official Linux Bluetooth Protocol Stack. http://www.bluez.org/,
[52] Ishwar Ramani and Stefan Savage. SyncScan: Practical Fast Handof for 802.11 Infrastructure Networks. In Proceedings of the 24th Anual Joint Conference of the IEEE
Computer and Communications Societies (Infocom 2005), pginas 675684. IEEE
Computer Society, 2005.
[53] F. Ramparany, O. Boissier, and H. Brouchoud. Cooperating Autonomous Smart Devices. In Proceedings of the Smart Objects Conference (sOc03), pginas 182185,
2003.
[54] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks,
M. Handley, and E. Schooler.
RFC 3261 - SIP: Session Initiation Protocol.
http://www.faqs.org/rfcs/rfc3261.html, 2002. Acessado em Setembro 2007.

[55] McCann
worth
S.,
E.
Groting
Next
W.,
Pandolfi
Generation
A.,
Multimode
and
HepTerminals.
http://www.roke.co.uk/download/papers/next_generation_multimode_terminals.pdf,
BIBLIOGRAFIA
87
[56] D. Saha, A. Mukherjee, I. S. Misra, M. Chakraborty, and N. Subhash. Mobility support

in IP: a survey of related protocols. IEEE Network, 18(6):3440, 2004.
[57] Debashis Saha and Amitava Mukherjee. Pervasive Computing: A Paradigm for the
21st Century. Computer, 36(3):2531, 2003.
[58] M. Satyanarayanan. Pervasive Computing: Vision and Challenges. IEEE Personal
Communications, 8(4):1017, 2001.
[59] Albrecht Schmidt, Martin Strohbach, Kristof van Laerhoven, Adrian Friday, and HansWerner Gellersen. Context Acquisition Based on Load Sensing. In Proceedings of
the Fourth International Conference on Ubiquitous Computing (UbiComp02), pginas
333350. Springer, 2002.
[60] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RTP: A Transport Protocol
for Real-Time Applications. http://rfc.dotsrc.org/rfc/rfc1889.html, 1996. Acessado em
Setembro 2007.
[61] H. Schulzrinne, A. Rao, and R. Lanphier. Real Time Streaming Protocol (RTSP).
ftp://ftp.isi.edu/in-notes/rfc2326.txt, 1998. Acessado em Setembro 2007.
[62] Henning Schulzrinne and Elin Wedlund. Application-layer mobility using SIP. Mobile
Computing and Communications Review, 1(2):4757, 2000.
[63] F. Siddiqui and S. Zeadally. Mobility Management across Hybrid Wireless Networks:
Trends and Challenges. Computer Communications, 29(9):13631385, 2005.
[64] Bluetooth
SIG.
Bluetooth
Specification
Version
2.0
EDR.
http://www.bluetooth.com/NR/rdonlyres/1F6469BA-6AE7-42B6-B5A165148B9DB238/840/Core_v210_EDR.zip, 2007. Acessado em Setembro 2007.

[65] Bluetooth
SIG.
Compare
Bluetooth
with
Other
Technologies.
http://www.bluetooth.com/Bluetooth/Learn/Technology/Compare/, 2007.
sado em Setembro 2007.
Aces-
BIBLIOGRAFIA
88
[66] Alex C. Snoeren and Hari Balakrishnan. An End-to-End Approach to Host Mobility. In
Proceedings of the 6th International Conference on Mobile Computing and Networking
(MobiCom 2000), pginas 155166. ACM Press, 2000.
[67] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson. Stream Control Transmission Protocol.
http://www.ietf.org/rfc/rfc2960.txt, 2000. Acessado em Setembro 2007.
[68] Bjarne Stroustrup. The C++ Programming Language. Addison-Wesley Professional,
3 edio, 2000.
[69] Jean Tourriles. Bluetooth Roaming Proposals. Relatrio Tcnico, HP Laboratories,
2000.
[70] Jean Tourrilhes. On-Demand Bluetooth: Experience Integrating Bluetooth in Connection Diversity. Relatrio Tcnico HPL-2003-178, HP Laboratories Palo Alto, 2003.
[71] Kenneth
Virgile.
Network
bridge
with
multicast
forwarding
table.
http://www.google.com/patents/pdf/Network_bridge_with_multicast_forwarding.pdf,
[72] Bernhard H. Walke, Stefan Mangold, and Lars Berlemann. IEEE 802 Wireless Systems:
Protocols, Multi-hop Mesh/Relaying, Performance and Spectrum Coexistence. John
Wiley & Sons, Ltd, 1 edio, 2007.
[73] Ted Wallingford. Switching to VoIP. OReilly Media, 1 edio, 2005.
[74] Mark Weiser. The Computer for the 21st Century. Scientific American, 265(3):6675,
1991.
[75] WiBree. WiBree. http://www.wibree.com/, 2007. Acessado em Setembro 2007.
[76] Stefan Winkler and Frdric Dufaux. Video quality evaluation for mobile applications.
In Proceedings of the 2003 SPIE Visual Communications and Image Processing Conference, pginas 593603, 2003.
[77] WirelessUSB.
Certified
Wireless
USB
from
the
http://www.usb.org/developers/wusb/, 2007. Acessado em Setembro 2007.
USB-IF.
BIBLIOGRAFIA
89
[78] Qing-An Zeng and Dharma P. Agrawal. Handbook of wireless networks and mobile
computing, chapter Handoff in wireless mobile networks, pginas 125. John Wiley &
Sons, Inc., 2002.
[79] ZigBee. ZigBee: Wireless Control that Simply Works. http://www.zigbee.org, 2005.
Apndice A
Escolhendo Valores para os Parmetros
do Paging
De acordo com a especificao do Bluetooth [64], os parmetros page scan window e page
scan interval podem variar entre 17 e 4096 slots, e entre 18 e 4096 slots, respectivamente.
Ainda de acordo com a especificao, estes valores podem ser definidos livremente dentro
dessas faixas, contanto que o page scan window seja menor ou igual ao page scan interval.
No escopo dos testes executados o objetivo no era encontrar valores timos para esses
parmetros. Como dito anteriormente na Seo 3.2.2, esta uma busca mais complexa, que
envolve diversas variveis e que ainda pode ser influenciada por um componente aleatrio,
no caso, as condies do canal sem fio e as escolhas de pacotes de camada fsica feitas pela
interface mediante essas condies. Ao invs disso, foi buscada apenas uma combinao
de page scan window e page scan interval que reduzisse o tempo de paging, reduzindo
portanto o nmero de slots necessrios pela EB para estabelecer conexo com o DM. Alm
disso, o impacto sobre um fluxo de dados em tempo-real, causado por ajustes dos parmetros
do paging, pode ser ilustrado atravs dos testes feitos para a escolha dos valores desses
parmetros.
Dados os objetivos descritos anteriormente, e para reduzir a quantidade de valores testados para cada parmetro, as combinaes de valores avaliados para os parmetros page scan
window e page scan interval foram escolhidos de acordo com as regras por trs de seu funcionamento (Seo 2.5.3). Conforme descrito por Jennifer Bray e Charles Sturman em [7],
recomendado que o page scan window seja longo o suficiente para que sejam escutadas,
90
91
pelo menos, metade das 32 freqncias disponveis. Assim, a estratgia usada para variar
seu valor foi escolher valores mltiplos de 18. A estratgia para escolher os valores para o
page scan interval consistiu apenas em, partindo do seu valor padro, reduzir seu valor pela
metade.
Nesse contexto, os valores do page scan window escolhidos para avaliao foram 18, 36,
e 54. Estes valores foram combinados com os valores 1024, 512, 256, e 128, escolhidos para
o page scan interval. Para os testes a seguir, assim como na Seo 4.1.2, foi utilizado um
stream de um arquivo MP3 codificado a 320 Kbps. Interfaces Broadcom foram usadas tanto
na EB quanto no DM. Durante esses testes no houve handoff. Em cada teste era alterada
apenas a configurao dos parmetros do paging. Ainda, a qualidade do stream recebido
em cada teste foi verificada via avaliao subjetiva usando o gstreamer, da mesma maneira
descrita na Seo 4.1.1.
Na Figura A.1 so mostrados os grficos da recepo de pacotes e intervalos na chegada
entre pacotes para um page scan window de 18 slots. Nos testes com essa configurao
de page scan window, apenas o experimento com page scan interval de 128 slots (Figuras
A.1(g) e A.1(h)) falhou na avaliao subjetiva. Todos os demais apresentaram reprodues
perfeitas. Mesmo assim, as imperfeies na reproduo do stream desse teste, reveladas pela
avaliao subjetiva, foram muito pequenas e espordicas.
Na Figura A.2 so mostrados os grficos para os testes com ajuste do page scan window
para 36 slots. Nos testes para esse novo valor, os experimentos com page scan interval
de 1024 (Figuras A.2(a) e A.2(b)) mostraram uma reproduo suave do audio, sem falhas
perceptveis. Em compensao, os experimentos com page scan interval de 512 slots (Figuras A.2(c) e A.2(d)), 256 (Figuras A.2(e) e A.2(f)) e 128 slots (Figuras A.2(g) e A.2(h))
falharam. Enquanto as imperfeies ouvidas nos experimentos para os ajustes de 512 e 256
slots eram, assim como o experimento das Figuras A.1(g) e A.1(h), poucas e espordicas, a
avaliao subjetiva do stream com page scan interval de 128 slots revelou uma reproduo
com diversos rudos e curtas interrupes.
Por fim, na Figura A.3 so mostrados os grficos obtidos a partir do ajuste do page
scan window para 54 slots. Todos os experimentos para esse ajuste de page scan window
mostraram falhas na reproduo do audio recebido. Enquanto o experimento com ajuste do
page scan interval para 1024 (Figuras A.3(a) e A.3(b)) slots apresentou apenas pequenas
92
(a) Chegada de pacotes RTP para page scan in-
(b) Intervalos entre as chegadas page scan inter-
terval = 1024 slots
val = 1024 slots
(c) Chegada de pacotes RTP para page scan in-
(d) Intervalos entre as chegadas para page scan
terval = 512 slots
interval = 512 slots
(e) Chegada de pacotes RTP para page scan in-
(f) Intervalos entre as chegadas para page scan
terval = 256 slots
(g) Chegada de pacotes RTP para page scan in-
(h) Intervalos entre as chegadas para page scan
terval = 128 slots
Figura A.1: Avaliaes para page scan window = 18 slots
93
(b) Intervalos entre as chegadas para page scan
terval = 1024 slots
terval = 512 slots
terval = 256 slots
terval = 128 slots
Figura A.2: Avaliaes de valores para page scan window = 36 slots
94
(b) Intervalos entre as chegadas para page scan
terval = 1024 slots
terval = 512 slots
terval = 256 slots
terval = 128 slots
Figura A.3: Avaliaes de valores para page scan window = 54 slots
95
falhas, os experimentos para os ajustes de 512 (Figuras A.3(c) e A.3(d)), 256 (Figuras A.3(e)
e A.3(f)), e principalmente 128 slots (Figuras A.3(g) e A.3(h)), apresentaram muitos rudos
e interrupes durante a reproduo do stream.
Na Tabela A.1 so enumerados os resultados dos testes com os diferentes configuraes
avaliadas para os parmetros do paging. Levando-se em conta o impacto das combinaes
de valores para page scan window e page scan interval avaliados sobre o stream usado, os
valores de 18 e 256 slots, para page scan window e page scan interval respectivamente,
foram escolhidos para os testes da Seo 4.1.2. Usando essa configurao, a EB conseguiu
conexo com o DM em mdia a 258,142 ms (em torno de 413 slots).
page
scan
page scan in-
Tempo Paging (ms)
Nmero Aprox. Slots
Res. Aval. Subjetiva
window
terval
18
1024
721,565
1154
Perfeito
18
512
419,988
672
Perfeito
18
256
258,142
413
Perfeito
18
128
200,419
321
Poucas Falhas
36
1024
736,239
1221
Perfeito
36
512
436,807
699
Poucas Falhas
36
256
282,414
452
Poucas Falhas
36
128
211,516
338
Muitas Falhas
54
1024
733,559
1173
Poucas Falhas
54
512
440,288
704
Muitas Falhas
54
256
285,061
456
Muitas Falhas
54
128
207,727
332
Muitas Falhas
Tabela A.1: Resumo dos resultados dos testes com diferentes parmetros para o paging.
Apndice B
Aplicaes
O enfoque do trabalho apresentado foi a definio de um protocolo de handoff para transio
de conexes fsicas entre pontos de acesso Bluetooth, que viabilizasse o uso de aplicaes
de tempo-real em dispositivos mveis mesmo quando estes se deslocam atravs das reas
de cobertura de diferentes pontos de acesso. Particularmente, as aplicaes de tempo-real
vislumbradas durante o desenvolvimento da soluo so aquelas que precisam transmitir
e/ou receber dados pela rede. Provavelmente a principal classe de aplicaes a se encaixar
nesse requisito so as aplicaes de streaming.
Nesse contexto, nas prximas sees so enumeradas algumas possveis aplicaes futuras do trabalho proposto. Um requisito comum a todos os casos de uso a seguir a necessidade de se manter constante a transmisso dos streams mesmo quando o usurio se move
atravs das reas de cobertura de diferentes pontos de acesso. Ou seja, necessrio fazer a
adequada gerncia de handoff. Idealmente, estas transies entre pontos de acesso devem ser
feitas de forma a no interromper o trnsito dos streams e nem degradar sua qualidade.
B.1
Reproduo de udio e/ou Vdeo em Movimento
Provavelmente esta seja a aplicao mais direta de uma infra-estrutura de streaming para dispositivos mveis. O cenrio geral aquele onde aplicaes rodando em dispositivos mveis
consomem streams disponibilizados por servidores numa rede cabeada, independente se so
streams pr-gravados ou transmisses ao vivo.
Uma vez conectado a algum ponto de acesso, o usurio informa sua aplicao cliente
96
B.2 Visitas Guiadas
97
de streaming preferida o identificador do stream que deseja assistir. Em geral, esse identificador ser uma URI 1 com diversas informaes sobre o stream a ser consumido, como
protocolo usado, endereo e porta onde contactar a aplicao servidora de streams, e identificadores extras para indicar qual dos streams previamente armazenados no servidor dever
ser transmitido (e.g. rtsp://200.222.12.43:7743/VideosF1/silverstone2007).
Aplicaes efetivas para essa abordagem incluem, por exemplo, assistir/ouvir cameras/microfones de segurana instalados em algum local remoto, ou apenas assistir TV
ou ouvir rdio via webcast 2 , por exemplo.
B.2
Visitas Guiadas
Visitas guiadas so exemplos particularmente interessantes de como informaes sobre o

contexto dos usurios e aplicaes de streaming podem se integrar. Por informaes sobre
contexto, neste caso de uso, nos referimos a dados atuais sobre as localizaes dos usurios
e as direes para onde eles se movem.
Como exemplo de aplicao de visita guiada, pode-se imaginar um visitante conhecendo
as instalaes de alguma empresa. Ao entrar na empresa, o visitante pode usar seu smartphone para conectar-se com o sistema de visita guiada daquele local. Enquanto ele ainda se
encontra na sala de entrada da empresa, ele comea a receber em seu smartphone udio e
vdeo pr gravados, dando detalhes sobre o que aquela empresa e o que se faz l. O uso de
uma tecnologia sem fio de curto alcance, como Bluetooth, possibilita que os streams recebidos pelo visitante vo se adequando medida que este caminha pela empresa. Ou seja, ao
caminhar um pouco e entrar num corredor, ser redirecionado para o dispositivo do visitante
um stream explicando o que acontece em cada uma das salas que aquele corredor d acesso.
Ao entrar em alguma sala, o stream mais uma vez pode ser alterado, dessa vez para dar mais
detalhes sobre os projetos e atividades que so desempenhadas naquela sala. O sistema pode
ainda incluir no stream informaes sobre os atuais ocupantes da sala, dizendo quem so e
quais seus cargos/papis.
A idia pode ser mapeada para diferentes negcios, como museus, galerias, ou qualquer
1
2
Universal Resource Identifier

Transmisso de udio e vdeo pela Internet
B.3 VoIP
98
outro ambiente de visitao pblica. Fazendo-se uma mesclagem entre tecnologias de curto
e mdio alcance, possvel ainda criar visitas guiadas para ambientes bem maiores, como
pontos tursticos que ocupem grandes reas, bairros, ou mesmo cidades inteiras.
B.3 VoIP
Nos ltimos anos a tecnologia de telefonia via Internet VoIP vm se firmando como uma alternativa aos servios de telefonia tradicionais, principalmente por causa do seu baixo custo.
Numa viso de longo prazo, quando redes 4G [50] forem predominantes, usurios de smartphones no meio de uma ligao e/ou seo de dados usando uma rede de longo alcance
tarifada podero transferir automaticamente suas sesses de voz e dados para uma infraestrutura de rede local mais barata ou eventualmente gratuita, como Wi-Fi. A idia tirar
proveito das capacidades de dispositivos multimodais [55] e do acesso local a redes sem fio
de baixo custo, e de menor alcance, para economizar dinheiro.
Enquanto este cenrio no se torna realidade, uma opo mais simples e imediata para
o mesmo tipo de economia consiste em usar VoIP, ao invs ligaes via GSM tarifadas, por
exemplo, sempre que este servio estiver disponvel. O cenrio imaginado aquele onde
empresas e residncias, com acesso dedicado Internet, disponibilizem pontos de acesso
sem fio. Usurios poderiam optar, no momento da ligao, usar essas infra-estruturas para
fazer ligaes de baixo custo. reas grandes, obviamente, demandariam mais de um ponto de
acesso para serem totalmente cobertas. Se por um lado tecnologias como Wi-Fi, com alcance
em torno de 100m, reduzem a probabilidade/necessidade de gerenciamento de handoff, por
outro lado elas esgotam mais rapidamente a autonomia dos dispositivos clientes. Tecnologias como Bluetooth, com menor alcance, possuem uma probabilidade/necessidade maior
de gerenciamento de handoff. Em compensao, demandam apenas 20% do consumo de
energia dos seus concorrentes de maior alcance [65].
B.4
Push to Talk
Em aplicaes de Push to Talk (PTT), dispositivos de telefonia, como celulares e smartphones, passam a atuar de forma semelhante aos seus antecessores, os walk talks. Em PTT
B.4 Push to Talk
99
a comunicao passa a acontecer entre grupos de dispositivos, ao invs de apenas dois como
naturalmente acontece em telefonia. Atualmente, o trafego de chamadas via PTT acontece
via conexes de longa distncia usando a infra-estrutura da operadora, o que implica tarifao pelo uso do servio e custo para o cliente.
Assim como discutido na Seo B.3, usurios poderiam se beneficiar da presena de uma
infra-estrutura local sem fios tambm para a comunicao via PTT. A idia seria estabelecer
conexes com pontos de acesso locais, em residncias e empresas, para a comunicao via
PTT. Apesar de ser uma conexo com uma infra-estrutura local, os participantes de um grupo
PTT podem, assim como o PTT oferecido pelas operadoras, estar geograficamente dispersos.
Basta que as infra-estruturas cabeadas, s quais cada usurio do grupo est ligado via algum
ponto de acesso, estejam ligadas a uma mesma rede em comum, como a Internet, para que
os trfegos sejam adequadamente roteados.
Apndice C
Escalabilidade e Qualidade de Servio
A preocupao com questes de escalabilidade natural quando se pensa, por exemplo, em
aplicaes como as discutidas no Apndice B. Mesmo o melhor dos protocolos de handoff
pode ser intil se sistemas baseados em tal soluo saturam com apenas poucos usurios
simultneos. Alm disso, o fato de se lidar com aplicaes com fortes requisitos para a
transmisso constante e pontual de dados significa que, mais uma vez, eventuais decises de
projeto para um sistema escalvel devem ser conciliadas com as aplicaes fins do sistema.
Ou seja, a soluo final deve ser escalvel ao mesmo tempo que no prejudica a qualidade
de servio de usurios j conectados ao sistema.
Durante o desenvolvimento deste trabalho, questes de escalabilidade e qualidade de
servio foram consideradas em diversos momentos. Entretanto, por uma questo de foco do
trabalho sobre o procedimento de handoff em si, algumas questes marginais mas importantes, como escalabilidade, tolerncia a falhas, e definio de mecanismos para localizao
de dispositivos, tiveram prioridade reduzida. Entretanto, neste Apndice so discutidas possveis solues relacionados escalabilidade e qualidade de servio tomando como base
o protocolo proposto no Captulo 3, assim como o arcabouo de uma infra-estrutura para a
evoluo do protocolo original.
C.1
Os Gargalos de Escalabilidade
Analisando o protocolo descrito no Captulo 3, so identificados dois pontos onde o aumento

de demanda causar gargalos de escalabilidade: o nmero de clientes e a quantidade de
100
C.1 Os Gargalos de Escalabilidade
101
pedidos de handoff que podem ser atendidos ao mesmo tempo em cada EB. Como o nmero
de clientes simultneos que cada EB consegue comportar conseqncia da capacidade de
sua interface Bluetooth de estar conectada a mais de um dispositivo ao mesmo tempo, temos
que sete o nmero mximo de clientes servidos por cada EB ao mesmo tempo. Atender
handoffs tambm tende a causar problemas de desempenho. Pelo protocolo atual, para cada
pedido de handoff que a EB precisa atender, tentativas de conexo com o DM em questo
so executadas at que o dispositivo seja contactado ou at que alguma outra EB informe
contato com aquele DM (Seo 3.2). O problema surge quando a EB precisa gerenciar
vrios pedidos de handoff ao mesmo tempo. Nesse caso, cada pedido precisa ser atendido
de forma seqencial, o que pode implicar perda de contato com algum DM cujo pedido de
handoff demorou muito tempo para ser executado pela EB.
Uma outra dimenso para o problema de escalabilidade revelada quando so tambm
considerados os recursos limitados do sistema. Ou seja, apesar de cada interface da EB
poder comportar at sete clientes, sua capacidade de banda tambm limitada
e ainda
precisa ser dividida entre cada DM atualmente conectado. Isto significa que a capacidade
de uma EB pode, por exemplo, saturar com apenas um DM. De forma similar, DMs em
handoff para alguma EB podem no encontrar nela uma disponibilidade de banda suficiente
para suas aplicaes em curso. O resultado desta mudana, considerando que o handoff
seja completado, que o novo DM tende a congestionar o canal sem fio da nova EB, tendo
prejudicada a qualidade de suas aplicaes e a qualidade das aplicaes em curso em outros
DMs tambm conectados quela EB.
Tomando como base o protocolo j existente, a soluo direta para a questo de escalabilidade consiste em aumentar a quantidade de interfaces Bluetooth em cada EB do sistema.
Para ter algum controle sobre a qualidade do servio oferecido pelas EBs, necessrio ainda
definir os mecanismos pelos quais recursos so alocados entre DMs e garantidos enquanto
estes estejam conectados ao sistema. Nesse contexto, as organizaes lgica e fsica da EBs
e DMs, apresentadas no Captulo 3, so estendidas a seguir para acomodar as novas necessidades de escalabilidade e qualidade de servio. As especificaes dos novos elementos
lgicos e fsicos so apresentados a partir da prxima seo. Por questo de simplicidade,
sero focadas aqui essencialmente as diferenas em relao ao que j foi colocado no Cap1
Largura de banda bruta de 1 Mbps para interfaces 1.1 e 1.2, e 3 Mbps brutos para interfaces 2.0 e 2.1.
C.2 Definindo um Sistema Escalvel
102
tulo 3.

A viso geral do novo sistema a mesma apresentada anteriormente na Figura 3.1. Assim
como no protocolo original, as entidades fsicas do sistema continuam sendo EBs e DMs. Os
estados que DMs assumem no sistema tambm so os mesmos definidos na Seo 3.1.1, mas
o registro de DMs em cada EB, descrito na Seo 3.1.2, precisa agora guardar informaes
sobre as trocas de dados atualmente ativas para cada DM (Figura C.1), necessrias para o
controle de admisso descrito na Seo C.2.4.
Registro DM
Registro DM
Registro DM EB
Stream
BD_ADDR
Stream
EB
Stream
BD_ADDR
Id EB
E/S
IdStream
E/S
IdStream
BD_ADDR
Id EB
E/S
IdStream
Stream
E/S
Id Stream
Estado
Requisito
Id EB
E/S
Id
Requisito
E/S
Id
Estado
Requisito
Id
E/S
Id
Requisito
Id
Estado
Requisito E/S
Id
Requisito
Requisito
Requisito
Figura C.1: Registro de EBs com informaes sobre streams em curso.

Arquiteturalmente, as principais mudanas, em relao ao protocolo apresentado, aconteceram nas EBs, onde agora supe-se que existam diversas interfaces Bluetooth ligadas a
elas ao mesmo tempo. Esta suposio pode ser dita realstica dado o atual baixo custo desse
tipo de interface. Para implementar um controle de admisso nas EBs, e assim ter algum controle sobre a qualidade do servio oferecido aos DMs, a camada de software responsvel pelo
gerenciamento dos handoffs cresceu e acoplou-se s aplicaes dos usurios. O arcabouo
da soluo agora apresentada, baseia-se na prpria abordagem usada pelo Bluetooth SIG
para o desenvolvimento de aplicaes especializadas usando o Bluetooth: a criao de perfis.

Perfis encapsulam o comportamento comum a toda uma classe de aplicaes, servindo ento como base para o desenvolvimento de aplicaes finais especializadas. Na prtica, perfis
realizam-se como camadas de software que facilitam o desenvolvimento de novas aplicaes,
oferecendo aos desenvolvedores uma interface mais alto nvel, especializada em algum tipo
2
Bluetooth Special Interest Group - Grupo responsvel pelo desenvolvimento do Bluetooth.
103
de tarefa, e que abstrai as dificuldades do manuseio direto da interface HCI, ou ainda do

uso de servios oferecidos por outros perfis. Assim, e focando num primeiro momento apenas aplicaes de streaming, foi definido um perfil, HoSP (sigla para Handing-off Streams
Profile), independente de aplicao. A implementao deste perfil encapsula a lgica por
trs do gerenciamento de handoff, controle de admisso, comunicao inter-EBs, e a troca
de dados no enlace entre DMs e EB. Parte da responsabilidade da EB, que dependente de
aplicao, delegada para uma aplicao externa, responsvel por representar a aplicao
final do usurio, que roda no DM, junto rede cabeada. Uma viso geral dessa nova organizao ilustrada na Figura C.2. A seguir so descritas as novas entidades fsicas e lgicas
do sistema e suas funes.
Aplicao
L2cap
HCI
Hardware
Bluetooth
Aplic.
TCP/IP
HoSP
HoSP
HoSP
Servidor
Streams
Aplic.
TCP/IP
L2CAP
L2cap
Hardware
Bluetooth
HCI
Hardware
Bluetooth
HCI
Figura C.2: Nova organizao lgica do sistema.

Do lado da EB, a camada HoSP implementa a lgica para monitorar DMs, requisitar
streams, conceder a transmisso de streams, controle de admisso de DMs, escalonamento
de pedidos de handoff, e comunicao entre EBs. No lado do cliente, implementa as regras
para entrada no sistema, interao com a EB para requisio de recepo/transmisso de
streams, monitorao de conexes estabelecidas e perdidas, e gerenciamento de mltiplas
conexes. Para ter acesso s informaes e conectividade necessria por seus mdulos, a
camada HoSP tm acesso direto camada HCI e rede local TCP/IP. No enlace com DMs a
troca de dados feita via L2CAP.
C.2.1
104
As Estaes Base
Em sua nova organizao, EBs possuem vrias interfaces Bluetooth, onde distinguem-se
dois tipos de interfaces (Figura C.3): interfaces de proviso de servio (IPSs); e interfaces de
ponto de entrada (IPEs). Cada EB possui, pelo menos, duas interfaces Bluetooth disponveis.
Neste cenrio mnimo, cada interface ir assumir um dos papis anteriores. Cada tipo de
interface possui uma configurao prpria, definida de acordo com seu papel no sistema.
IPE1
IPE2
HUB USB
IPEn
IPS1
IPS2
IPS3
IPSn
Figura C.3: Interfaces de Proviso de Servio (IPSs) e Interfaces de Ponto de Entrada (IPEs).
Desde que no estejam ocupadas atendendo algum pedido de handoff, IPEs so configuradas para responder tanto inquiries quanto pagings e possuem duas funes: servir como
ponto de entrada no sistema para novos dispositivos; e tentar contato com DMs durante
handoffs. Dispositivos externos ao sistema localizam e conectam-se s EBs atravs das IPEs
(Seo C.3.1). Nenhum trfego til realmente transferido por estas interfaces. O segundo
tipo de interface, IPS, responsvel pelo efetivo trfego de dados entre DMs e servidores.
DMs s podem receber/transmitir dados quando conectados a uma IPS. IPEs podem ter
suas configuraes alteradas em tempo de execuo para no responder nem pagings nem
inquiries como forma de aumentar a disponibilidade da interface durante handoffs (Seo
C.3).
Diferente das IPEs, as IPSs so configuradas para no responderem nem inquiries nem
pagings de outros dispositivos. Assim, isola-se o trfego de dados em tempo-real de grande
parte das perturbaes que eles poderiam sofrer por parte de outros dispositivos Bluetooth
105
prximos. Como IPSs no respondem inquiries/pagings de outros dispositivos, as conexes

entre IPSs e DMs so iniciadas pela EB.
Cada EB pode dispor de quantas IPSs e IPEs quantas forem possveis/necessrias, desde
que existam, pelo menos, uma interface de cada tipo. A forma direta de escalar o sistema,
com relao capacidade de clientes servidos simultaneamente, aumentar a quantidade de
IPSs nas EBs, aumentando assim o nmero de clientes suportados em cada EB e a quantidade
de recursos disponveis para eles. De maneira similar, IPEs ocupadas com pedidos de handoff
tentem a tornar-se um gargalo de desempenho durante esse processo. Assim, a forma de
escalar o sistema com relao capacidade de handoffs simultneos numa mesma EB
aumentar a quantidade de IPEs da mesma. Como visto na Seo 2.5.4, o trfego de dados
em tempo-real sobre Bluetooth consideravelmente afetado pelas operaes de paging e
inquiry. Esta a razo por trs da diferenciao entre IPEs e IPSs.
C.2.2
Os Dispositivos Clientes
Nos DMs, aplicaes finais so desenvolvidas sobre a camada HoSP. Assim como j descrito
na Seo 3.2, toda a monitorao e procedimentos para trocas de EBs so tarefas das EBs.
Continua cabendo aos DMs apenas perceber os estabelecimentos e perdas de conexes
com as EBs e reagir de forma adequada. Considerando ainda o nicho inicial para o qual o
HoSP foi pensado (aplicaes de streaming) e os procedimentos para controle de admisso
(vide Seo C.2.4), temos que o HoSP pode encapsular todo o comportamento comum
gerncia de conexes, trocas de dados no enlace com as EBs, e interao com o controle de
admisso das EBs, deixando para as aplicaes finais apenas o tratamento comum ao trfego
de streaming via redes de melhor esforo (e.g. ordenao de pacotes fora de ordem e descarte
de pacotes muito atrasados ou redundantes) e/ou a gerao de trfego para encaminhamento
na rede cabeada.
Assim, na camada HoSP dos DMs anunciada uma interface, ilustrada abaixo, pela qual
aplicaes especializadas em streaming, e que demandem suporte transparente a handoffs,
podem ser desenvolvidas. Ao construir aplicaes sobre essa interface, aplicaes automaticamente se beneficiam de facilidades codificadas no HoSP quanto troca de dados com
diferentes EBs, e da gerncia de handoffs implementada na rede cabeada.
106
buscarEBs()
abrirConexaoEB( idEstacaoBase )
solicitaRecepcaoStream( idStream, funcaoCallback )
solicitaTransmissaoStream( destinatario, larguraBanda )
envia( idConexao, dados )
Aplicaes clientes usam a funo buscarEBs() para que a camada HoSP faa um inquiry e filtre os resultados, retornando apenas uma lista com os dispositivos prximos que
so estaes base do sistema. A lista retornada por essa funo pode ser iterada pela aplicao, que usa a funo abrirConexaoEB( idEstacaoBase ) para tentar conexo com a EB
escolhida. Uma vez conectados a alguma IPS, DMs podem solicitar streams anunciados por
outros nodos da rede atravs da funo solicitaRecepcaoStream( idStream, funcaoCallback
). Quando invocada, essa funo passa para a camada HoSP da EB o identificador do stream
desejado. Esta, por sua vez, executa os procedimentos necessrios para iniciar ou rejeitar
o stream solicitado pelo DM (vide Seo C.3.2). Caso o stream seja aceito, os dados do
stream so repassados para a camada HoSP do cliente que, para cada pacote recebido, invoca a funo de callback informada quando o stream foi solicitado. Para a transmisso de
streams a partir do DM, as funes solicitaTransmissaoStream( destinatario, larguraBanda
) e envia( idConexao, dados ) so usadas. A aplicao cliente primeiro informaria EB
que quer transmitir algo, informando o consumo estimado de banda. A EB, mais uma vez,
verifica sua disponibilidade de recursos e autorizaria ou no a nova transmisso.
C.2.3
As Aplicaes Finais
As aplicaes finais do sistema so aplicaes de streaming. Estas aplicaes rodam nos

DM e podem tanto transmitir dados para a rede cabeada quanto receber dados de l. Na
organizao proposta, aplicaes clientes so divididas em duas. Uma parte roda no prprio
DM, gerando streams e renderizando dados de streams recebidos, enquanto outra poro
roda junto EB. Esta segunda poro da aplicao trabalharia em conjunto com a EB para
efetivamente interagir com os servidores de streams, e repassar para o HoSP dados recebidos da rede cabeada, para que este os encaminhe para o respectivo DM. De forma inversa,
streams gerados pelos DMs seriam encaminhados para o HoSP da EB, e esta os repassaria
107
para a aplicao, que seria responsvel por encaminhar os dados recebidos na rede cabeada.
Como requisito para a implementao do controle de admisso, a poro da aplicao
final que roda na EB deve implementar dois servios, que so usados pelo HoSP: um para
consultar a descrio de streams; e outro para efetivamente iniciar o stream (vide Seo C.3).
C.2.4
Controle de Admisso
Como forma de ter algum controle sobre a qualidade do servio oferecido aos DMs e reduzir
a probabilidade de handoffs mau sucedidos devido atraso em seu atendimento, foi especificado um mecanismo de controle de admisso nas EBs. O controle de admisso decide se
novos DMs podem ou no conectar-se a uma EB, seja este um DM anteriormente externo ao
sistema ou um DM sob handoff.
Quando usada para atender handoffs, cada IPE configurada para no responder nem
pagings nem inquiries de dispositivos prximos. O objetivo priorizar os recursos de cada
IPE para os handoffs, mesmo que isso atrase a entrada de novos DMs no sistema. A principal
funo do controle de admisso rejeitar pedidos de handoff caso no existam recursos
suficientes para acomodar o novo dispositivo na EB de destino. Tentar contato com DMs
que no podem ter seus handoffs completos, devido falta de recursos (vagas nas piconets
das IPSs e/ou largura de banda nas IPSs disponveis pelo critrio anterior) na EB de destino,
significa aumentar, em vo, o tempo de espera de outros pedidos de handoff na fila. Este
tempo extra de espera pode comprometer o sucesso dos handoffs de outros dispositivos,
que eventualmente demandam menos recursos e que poderiam ser alocados na nova EB.
Dessa forma, conforme ilustrado no Algoritmo C.1, cada pedido de handoff escalonado tm
seus requisitos de uso de banda avaliados antes de serem efetivamente executados, assim
como tambm verificada a disponibilidade de slots nas IPSs disponveis. Apenas caso,
no momento do escalonamento do pedido, existam recursos suficientes em uma das IPSs
da EB, a requisio ser atendida. Caso contrrio, a requisio devolvida para a fila de
requisies e uma nova escolha feita. Na seleo de IPS, ilustrada no Algoritmo C.2,
escolhida a interface que possua slots livres em sua piconet e que tenha a menor largura de
banda disponvel que seja maior ou igual ao requisito de banda do DM sob handoff.
108
Algoritmo C.1: Escalonando requisies de handoff

1 ENQUANTO VERDADEIRO FACA
2
/ / e s c o l h e uma r e q u i s i o da f i l a , ou b l o q u e i a c a s o a f i l a e s t e j a
vazia
reqHandoff escalonaRequisicaoHandoff ( )
/ / v i d e A l g o r i t m o C.2
IPS_ComMenorLarguraDeBanda s e l e c i o n a I P S ( r e q H a n d o f f . dadosEB )
SE ( IPS_ComMenorLarguraDeBanda = NULO) ENTAO
devolveParaFila ( reqHandoff )
CONTINUE
FIM SE
10
ipe escalonaIPE ( reqHandoff )
11
r e s u l t a d o T e n t a t i v a t e n t a C o n e x a o ( r e q H a n d o f f . dadosEB , i p e )
12
SE ( r e s u l t a d o T e n t a t i v a = VERDADEIRO) ENTAO
13
IPS_ComMenorLarguraDeBanda s e l e c i o n a I P S ( r e q H a n d o f f . dadosEB )
14
SE ( IPS_ComMenorLarguraDeBanda = NULO) ENTAO
15
/ / d i s c o n e c t a DM da IPE
16
rejeitaDMPorFaltaDeRecurso ( reqHandoff )
17
SENAO
18
/ / d e s c o n e c t a DM da IPE
19
realocaDM ( IPS_ComMenorLarguraDeBanda , r e q H a n d o f f . dadosEB )
20
d i s p a r a M o n i t o r D M ( r e q H a n d o f f . dadosEB )
21
r e g i s t r o L o c a l . a t u a l i z a R e g i s t r o ( r e q H a n d o f f . dadosEB )
22
n o t i f i c a E B s V i z i n h a s ( r e q H a n d o f f . dadosEB )
23
r e s t a b e l e c e S t r e a m s E n t r a d a ( r e q H a n d o f f . dadosEB . s t r e a m s E n t r a d a )
24
r e s t a b e l e c e S t r e a m s S a i d a ( r e q H a n d o f f . dadosEB . s t r e a m s E n t r a d a )
25
26
27
FIM SE
SENAO
/ / tambm l i b e r a a IPE . Caso s e j a o l t i m o p e d i d o de h a n d o f f
a s s o c i a d o IPE , e l a r e c o n f i g u r a d a p a r a v o l t a r a a c e i t a r
pagins e i n q u i r i e s
28
29
devolveParaFila ( reqHandoff )
FIM SE
30 FIM ENQUANTO
Como no feita a reserva de recursos na IPS antes de iniciar o handoff para um determinado DM, caso seja conseguido contato com o DM o escalonador checa novamente a
C.3 Ilustrando o Funcionamento do Novo Sistema
109
disponibilidade de IPSs. Apesar de existirem recursos para acolher aquele DM no momento

em que seu pedido de handoff foi escalonado, eventualmente parte desses recursos podem
ter sido alocados para outro DM que conseguiu finalizar primeiro seu handoff atravs de
outra IPE da EB. Assim, o handoff para o um DM ainda pode ser rejeitado mesmo aps o
primeiro contato com a EB. EBs vizinhas apenas so notificadas sobre contato de uma outra
EB com um DM sob handoff caso aquela EB consiga re-alocar o DM para uma de suas IPSs.
Algoritmo C.2: Escolhendo IPS durante handoff.
1 menorLarguraDeBandaDisponivel
2 IPS_ComMenorLarguraDeBanda NULO
3 listaDeIPSs listaDeIPSs ()
4 PARA TODOS IPS EM l i s t a D e I P S s FACA
5
l a r g u r a D e B a n d a D i s p o n i v e l l a r g u r a D e B a n d a D i s p o n i v e l ( IPS )
/ / d a d o s s o b r e o DM r e c e b i d o s como p a r m e t r o
SE ( l a r g u r a D e B a n d a D i s p o n i v e l m e n o r L a r g u r a D e B a n d a D i s p o n i v e l ) E (
l a r g u r a D e B a n d a D i s p o n i v e l dadosDM . l a r g u r a D e B a n d a U s a d a ) E (
p o s s u i S l o t L i v r e ( IPS ) ) ENTAO
menorLarguraDeBandaDisponivel larguraDeBandaDisponivel
IPS_ComMenorLarguraDeBanda IPS
10
FIM SE
11 FIM FOR
12 RETORNA IPS_ComMenorLarguraDeBanda

A seguir, o funcionamento do novo sistema ilustrado atravs de alguns cenrios de uso. So
descritos os processos de entrada de novos DMs no sistema, a requisio de streams anunciados na rede cabeada, a requisio para transmitir streams em direo rede cabeada, e o
processo de handoff. O objetivo proporcionar uma viso prtica dos mecanismos pensados
para melhorar a caracterstica de escalabilidade do protocolo original.
C.3.1
Entrando no Sistema
O fluxo de atividades para entrada no sistema ilustrado na Figura C.4.
110
Figura C.4: Fluxograma com as etapas para entrada de DMs no sistema.

Como primeiro passo para entrada no sistema, aplicaes finais, construdas sobre a camada HoSP, solicitam a busca por EBs prximas. A implementao dessa busca na camada
HoSP filtra os resultados, retornando apenas os dispositivos Bluetooth que so EBs. Em
seguida, feita uma tentativa de conexo com uma das EBs retornadas, seja a partir de de
uma deciso automtica da aplicao, ou por escolha do usurio.
O processo de conexo entre DM e EB acontece em duas fases. Como as IPSs so
configuradas para no responderem nem pagings nem inquiries, ento as nicas interfaces
que respondem busca do DM so as IPEs, caso no estejam ocupadas com o handoff de
algum DM. Aps se conectar a alguma das IPEs da EB escolhida, inicia-se a segunda parte
do processo de entrada, onde o DM aguarda uma chamada de callback, vinda de alguma das
IPSs daquela EB. A chamada de callback na verdade uma nova conexo baseband entre
DM e EB, mas desta vez iniciada pela EB a partir de uma de suas IPSs.
Do lado da EB, o primeiro passo ao receber uma conexo de um novo cliente numa de
111
suas IPEs, verificar se existem recursos disponveis para acomodar mais um cliente. Como
no se sabe qual a largura de banda ser usada pelo DM, a deciso por aceitar ou no o
novo DM consiste, neste momento, na disponibilidade de slots em alguma de suas IPSs.
Caso exista pelo menos uma vaga na piconet em uma das IPSs da EB, checada ento a
distncia estimada entre esse novo dispositivo e a EB. Caso o cliente esteja numa posio
alm de onde o processo de handoff disparado, ento sua conexo rejeitada. Caso o
usurio encontre-se antes do ponto a partir do qual o processo de handoff disparado, a
EB prossegue com a conexo e usa uma estratgia gulosa para decidir qual de suas IPSs
o novo DM ser conectado. Neste segundo momento de checagem de recursos, a EB itera
sobre todas as IPSs com vagas em suas piconets, e escolhe aquela que tm maior largura de
banda disponvel. A largura de banda usada por cada IPS estimada baseado nas descries
dos streams atualmente transferidos por aquela EB. Como a EB no sabe, a priori, qual ser
o consumo de banda do novo DM, a estratgia gulosa consiste em alocar o novo DM na IPS
com maior largura de banda disponvel.
Aps decidir para qual IPS o DM ser alocado, a EB guarda temporariamente o endereo
BD_ADDR do DM (disponvel EB assim que foi aceita a conexo baseband entre DM e
IPE). Estas informaes so usadas para, aps desconectar o DM da IPE, estabelecer uma
nova conexo com o dispositivo cliente a partir da IPS escolhida (callback aguardado pelo
DM).
Ao finalizar a chamada de callback, o DM registrado na EB como estando no estado
CONECTADO e sua distncia em relao EB passa a ser monitorada. Neste estado, o
DM est pronto para requisitar ou transmitir streams. Aps cadastrar o DM em sua tabela
prpria de DMs, a EB atual tambm envia para todas as suas EBs vizinhas uma mensagem,
informando que aquele dispositivo est ligado a ela e seu estado CONECTADO. Cada EB
vizinha, ao receber essa mensagem, inclui uma referncia para aquele DM em seu registro
de DMs.
C.3.2
Iniciando Transmisses
Uma vez no estado CONECTADO, DMs podem solicitar s EBs a recepo de streams
anunciados na rede. O processo de requisio de streams ilustrado na Figura C.5. Primeiro,
a aplicao final no DM passa para a EB o identificador do stream desejado. O identificador,
112
que pode ser, por exemplo, uma URL RTSP ou SIP, passado para a aplicao do lado da
EB para que esta interprete seu contedo e interaja com os servidores daquele recurso.
Figura C.5: Etapas para iniciar a recepo de streams.

Na EB, o processo de requisio de streams acontece em duas fases, podendo ser rejeitado. Primeiro, ao receber uma requisio de stream de algum DM ao qual serve, a
EB delega para a respectiva aplicao auxiliar a tarefa de consultar a descrio do stream
de interesse, em particular, a estimativa de largura de banda usada por aquele stream.
Caso no seja possvel descobrir de antemo o consumo mdio de banda da um determinado stream, ento sua requisio rejeitada. Caso contrrio, a EB verifica se a IPS
qual o DM est conectado possui recursos livres suficientes para acomodar aquele stream.
Quando existe banda suficiente, a aplicao auxiliar mais uma vez solicitada, desta vez
para que entre em contato com o servidor do stream e inicie sua transmisso. Para cada
novo stream requisitado aplicao, assumido que seus pacotes sero retransmitidos dentro do domnio de mobilidade como trfego multicast e que o endereo multicast usado
ser retornado para a EB ao final do comando da aplicao para o inicio do stream. Os
detalhes para a realizao desta suposio so abstrados aqui, entretanto, possveis direes para a implementao incluem o MBone [39] e diversas patentes pblicas [1; 15;
113
71]. O endereo multicast do stream, seu tipo (neste caso, stream de entrada), e sua estimativa de banda, so notificados para todas as EBs vizinhas. Com a confirmao do aceite do
seu pedido, o DM estabelece uma conexo com a EB para a transferncia de dados e aguarda
sua chegada. Do lado da EB, assim que a aplicao auxiliar comea a receber os pacotes do
stream, estes so passados para o HoSP, que os encaminha para o DM.
A segunda hiptese, onde o DM inicia uma transmisso, ilustrada na Figura C.6. Antes
de iniciar uma transmisso o DM precisa solicitar o recurso em sua EB. Para a solicitao
o DM informa a estimativa de consumo do stream que pretende transmitir. Assim como no
caso anterior, a EB verifica se a IPS na qual o DM est conectado possui recursos suficientes
para acomodar o novo stream. Em caso afirmativo, o pedido do DM aceito, as EBs vizinhas
so notificadas do trfego do novo stream, e os dados do stream vindos do DM so passados
para a aplicao, que se encarrega de encaminhar os dados na rede cabeada. Sempre que um
stream aceito pela EB, essa informao tambm includa no registro local sobre o DM
antes de ser propagada para as EBs vizinhas.
Figura C.6: Etapas para iniciar a transmisso de streams.
C.4 Discusses Adicionais
C.3.3
114
Handoff no Nvel da Aplicao
Durante o processo de handoff o DM mantm-se conectado a mais de uma EB ao mesmo

tempo. Como no existe informao precisa sobre a direo na qual o usurio se move, fechar
conexo com uma das EBs antes do final do handoff pode causar perda total de conexo caso
a conexo fechada seja justamente a da EB para a qual o DM se movia. Assim, durante os
handoffs, os streams de entrada so repassados para o DM, ao mesmo tempo, por todas as
EBs s quais o DM est conectado, assim como dados de streams de sada so encaminhados
por todas as conexes disponveis. A responsabilidade de se lidar com dados replicados fica
por conta das aplicaes finais, que naturalmente j implementam esse tratamento, assim
como tambm implementam tratamento para outros problemas relacionados ao trfego de
streaming em redes de melhor esforo.
Sob a aplicao cliente, a camada HoSP monitora o estabelecimento e perda de conexes
baseband entre DM e EBs. Cada nova conexo baseband implica no estabelecimento de
conexes fim-a-fim entre DM e EB para cada stream em curso, enquanto a perda de conexes
baseband causa o fechamento destas conexes. No trfego de dados da rede em direo ao
DM, o dispositivo atua como servidor na conexo com a EB. Ou seja, ao ser estabelecida uma
conexo fim-a-fim l2cap entre DM e EB para o encaminhamento de um stream, a aplicao
fornece camada inferior uma funo para callback. Essa funo chamada pela camada
sempre que uma carga til encaminhada pela EB, normalmente um pacote RTP lido da rede
cabeada, chega por completo. Quando mltiplas conexes esto abertas entre o DM e EBs
(durante o handoff ), a camada HoSP inicia diferentes receptores de dados, um para cada
conexo, e repassa para a aplicao as cargas teis recebidas. No trfego de dados do DM
para a rede, o DM atua como cliente na sua conexo com a EB. As cargas teis a serem
transmitidas so passadas da aplicao para a camada HoSP, que por sua vez envia uma cpia
da carga til recebida para cada conexo ativa com diferentes EBs. Cada EB ao receber essa
carga a repassa para a aplicao, que faz seu encaminhamento via rede cabeada.
C.4
Neste Apndice foram discutidas algumas idias preliminares para a expanso do protocolo
original deste trabalho em direo a uma infra-estrutura mais madura do ponto de vista de
C.4 Discusses Adicionais
115
escalabilidade e qualidade de servio. As solues aqui discutidas so um arcabouo do

que pode ser o prximo passo na evoluo do protocolo descrito no Captulo 3. Essencialmente, temos que o sistema to escalvel quanto seja possvel implantar mais interfaces
Bluetooth em cada EB. Ao adicionar mais IPSs aumenta-se tambm a capacidade das EBs
de comportarem mais clientes ao mesmo tempo e a quantidade total de recursos disponveis
naquela EB. De forma anloga, aumentando-se o nmero de IPEs aumenta-se a quantidade
de pedidos de handoff que podem ser atendidos ao mesmo tempo.
Para diminuir a probabilidade de perda de conexes com DMs, devido atrasos no atendimento de seu pedido de handoff, foi tambm descrita uma especificao de um mecanismo
de controle de admisso. Este mecanismo usa informao sobre as aplicaes atualmente em
curso para um DM sob handoff para decidir se vale ou no pena tentar contato com aquele
DM. Caso a EB perceba que no possui vaga em nenhuma de suas IPSs para o novo DM, ou
que, mesmo havendo essa vaga, no existem recursos suficientes para acomodar os streams
em uso pelo DM, ento a EB no executa o pedido de handoff para aquele dispositivo. Assim, reduz-se o nmero de pedidos na fila por uma IPE e, conseqentemente, reduz-se a
probabilidade de que um pedido que realmente pode ser executado seja mau sucedido devido atraso para sua execuo. No controle de admisso tambm so definidos procedimentos
para acomodar a entrada de novos dispositivos, antes externos ao sistema.

Um Protocolo para Gerência de Handoff em Redes PESSOAIS Sem FIo PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Um Protocolo para Gerência de Handoff em Redes PESSOAIS Sem FIo PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade Federal de Campina Grande

Centro de Engenharia Eltrica e Informtica

Um Protocolo para Gerncia de Handoff em Redes

Loreno Feitosa de Oliveira

Campina Grande, Paraba, Brasil

Universidade Federal de Campina Grande

Um Protocolo para Gerncia de Handoff em Redes

Dissertao submetida Coordenao do Curso de Ps-Graduao em

rea de Concentrao: Cincia da Computao

Angelo Perkusich, DSc.

Campina Grande, Paraba, Brasil

Oliveira, Loreno Feitosa de.

Dissertao (Mestrado em Cincia da Computao), Universidade Federal de

1. Embutido (embedded). 2. Tempo-Real. 3. Camada Fsica. 4. Handoff.

Problemtica e Relevncia da Pesquisa . . . . . . . . . . . . . . . . . . . .

Tecnologias para Transmisso Sem Fio . . . . . . . . . . . . . . . . . . . .

Estabelecendo Conexes Baseband . . . . . . . . . . . . . . . . .

Inquiry e Paging X Trfego de Dados em Tempo-Real . . . . . . .

Gerenciando Handoffs para Bluetooth no Contexto de Aplicaes de TempoReal

Gerncia de Handoff - Transies entre EBs . . . . . . . . . . . . . . . . .

Atribuindo Responsabilidades e Configurando Operaes . . . . . .

Gerncia de Handoff - Mantendo Contato com DMs . . . . . . . . . . . .

Transies entre EBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Definio de uma Soluo Escalvel . . . . . . . . . . . . . . . . .

Integrao com Mecanismos de Mobilidade de Aplicaes . . . . .

Localizao e Monitorao dos Estados de Dispositivos . . . . . .

Mtodos e Modelos para Calibrao do Sistema . . . . . . . . . . .

A Escolhendo Valores para os Parmetros do Paging

B.1 Reproduo de udio e/ou Vdeo em Movimento . . . . . . . . . . . . . .

B.2 Visitas Guiadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

B.4 Push to Talk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C Escalabilidade e Qualidade de Servio

C.1 Os Gargalos de Escalabilidade . . . . . . . . . . . . . . . . . . . . . . . .

C.2 Definindo um Sistema Escalvel . . . . . . . . . . . . . . . . . . . . . . .

C.3 Ilustrando o Funcionamento do Novo Sistema . . . . . . . . . . . . . . . .

Handoff no Nvel da Aplicao . . . . . . . . . . . . . . . . . . .

C.4 Discusses Adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Redes pessoais sem fio - WPANs . . . . . . . . . . . . . . . . . . . . . . .

Pilha padro Bluetooth. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Impacto do inquiry num fluxo de 400 Kbps. . . . . . . . . . . . . . . . . .

Impacto do paging num fluxo de 400Kbps. . . . . . . . . . . . . . . . . . .

Impacto do inquiry scan num fluxo de 400Kbps. . . . . . . . . . . . . . . .

Impacto do page scan num fluxo de 400Kbps. . . . . . . . . . . . . . . . .

Viso geral do sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Estados e transies de estados associados a DMs. . . . . . . . . . . . . . .

Registros de DMs e suas informaes. . . . . . . . . . . . . . . . . . . . .

Principais entidades lgicas das EBs. . . . . . . . . . . . . . . . . . . . . .

Localizao de dispositivos Bluetooth. . . . . . . . . . . . . . . . . . . . .

Atribuies dos papis de mestre e escravo (adaptado do trabalho de Aman

Desempenho da operao de paging com diferentes parmetros (extrada do

Mantendo o DM conectado durante movimentao. . . . . . . . . . . . . .

Viso geral da estrutura criada para testes. . . . . . . . . . . . . . . . . . .

Estrutura lgica das EBs implementadas para testes. . . . . . . . . . . . . .

Dados de referncia da transmisso do stream de 320 Kbps para o DM, sem

Dados da transmisso do stream de 320 Kbps para o DM durante handoff. .

Dados da transmisso do stream de 320 Kbps para o DM durante handoff

usando interface CSR. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Modelo CPN para o protocolo de handoff entre EBs. . . . . . . . . . . . .

Diagrama de seqencia para exemplo ilustrado na Figura 3.8. . . . . . . . .

A.1 Avaliaes para page scan window = 18 slots . . . . . . . . . . . . . . . .

A.2 Avaliaes de valores para page scan window = 36 slots . . . . . . . . . . .

A.3 Avaliaes de valores para page scan window = 54 slots . . . . . . . . . . .

C.1 Registro de EBs com informaes sobre streams em curso. . . . . . . . . .