Prot�tipo de Comunica��o Bluetooth IEEE 802.15.1 em Tecnologia M�vel

Na seç�o 3 ser� abordado a descriç�o metodol�gica utilizada, especificando o modelo de comunicaç�o, desenvolvimento e interface do prot�tipo, objetivando prover gerenciamento e tratamento de aç�es e eventos.

Nesta mesma seç�o, tamb�m ser�o abordadas as ferramentas de programaç�o utilizadas para os dispositivos m�veis; tem-se C++ e J2ME (Java 2 Micro Edition). Na linguagem J2ME (Java 2 Micro Edition), ser�o mostradas basicamente duas especificaç�es, a CLDC (Conected Limited Device Configuration) e a MIDP (Mobile Information Device Profile), abordando tamb�m dentre as 70 JSRs (Java Specifications Requests) dispon�veis para dispositivos m�veis, uma escolhida neste prot�tipo.

3. Descriç�o Metodol�gica

Ap�s o estudo do dispositivo Bluetooth IEEE 802.15.1, pode-se notar que este � um protocolo com muitas especificaç�es e bem extenso, o Bluetooth SIG (Special Interest Group) espec�fica o padr�o em cerca de 1200 p�ginas, buscando as principais caracter�sticas deste projeto, neste momento ser� apresentado o funcionamento do prot�tipo com as suas aç�es e eventos, especificando como o trabalho ser� desenvolvido e qual linguagem de programaç�o ser� utilizada na criaç�o dos m�todos de comunicaç�o do ambiente.

3.1 Modelo de Comunicaç�o do Prot�tipo

A proposta no modelo de comunicaç�o fornece uma id�ia de relacionamento de eventos e aç�es em ambientes m�veis, dentro destes ambientes existem nodos com dispositivos Bluetooth IEEE 802.15.1, ao serem inseridos no ambiente os nodos s�o tratados com perfis, e passam a ter interaç�o com o ambiente, cada perfil pode indicar algum evento ou aç�o espec�fica.

O n�mero de informaç�es a serem cruzadas depender� da evoluç�o do dispositivo e da JSR-82(Java Specification Request), a autenticaç�o ser� implementada de forma que exista uma chave prim�ria do usu�rio relacionada ao endereço MAC, desta forma � poss�vel detectar, por exemplo, que um determinado usu�rio trocou de aparelho.

Outra funcionalidade que ser� explorada est� na quest�o da especificaç�o do endereço MAC pelo IEEE, onde os tr�s primeiros bytes s�o definidos pelo fabricante, com isso pode-se ter uma lista pr� cadastrada com os modelos e serviços suportados pelos dispositivos, ent�o seria poss�vel explorar uma funcionalidade ativando um evento espec�fico e incluindo o usu�rio em um perfil, por exemplo, autorizado a receber mensagem de �udio, pois foi detectado que seu dispositivo suporta mensagens de �udio.

� mostrado na Figura 5 uma id�ia b�sica de um relacionamento, status e tipos de aç�es e eventos, tratando o mesmo por Piconet ou Scatternet.

Figura 5. Modelo de Comunicaç�o

Dentro deste modelo de comunicaç�o o papel do computador BlueGw ser� de gerenciar o ambiente, validando os dados e disponibilizando os serviços e aplicaç�es. Existir� uma aplicaç�o Servlet rodando no BlueGw e ela estar� se comunicando via TCP/IP com a aplicaç�o Java do Servidor que cont�m o Bando de Dados com todas as informaç�es de hist�rico dos dispositivos.

O pooling de atualizaç�o de cada BlueGw ser� definido pelo n�mero de nodos presentes na piconet e o n�mero de BlueGw ativos, quanto maior o n�mero de nodos ativos em uma piconet, maior ser� o tempo de atualizaç�o, para contextualizar o pooling de atualizaç�o ser� utilizada a seguinte f�rmula, evitando assim poss�veis problemas de tr�fego.


            TpoolingBLGw(N) =    ((TsServidor + TsBlueGw)*(Nro BlueGw Piconets))_                 

                                           Nro BlueGw Piconets_- Nro Nodos Ativos(KnP)

TpoolingBLGw(N) informa o tempo de Pooling de cada Piconet em segundos.
TsServidor e TsBlueGw informa o respectivo tempo de serviço para atender um pedido do Servidor e do BlueGw.
Nro. BlueGw Piconets e Nro Nodos Ativos(KnP) define o n�mero de piconets e o n�mero de nodos ativos na piconet espec�fica.

O objetivo desta f�rmula � sugerir um best effort, caso o n�mero de piconets aumente, o tempo de pooling ir� aumentar tamb�m, mas caso o n�mero de piconects seja igual ao n�mero de nodos na piconet espec�fica, a decis�o do tempo de pooling ser� definido pelo tempo de serviço do BlueGw e do Servidor relacionado ao n�mero de piconets.

Est� f�rmula n�o t�o complexa para este prot�tipo, foi baseada no tempo m�ximo de 2.56 segundos (BLS, 2003) que � necess�rio para se efetuar uma conex�o entre dispositivos, j� existem trabalhos relacionados de algoritmos para otimizar este tempo no Bluetooth IEEE 802.15.1 (SIE,ROH 2003). A comunicaç�o e atualizaç�o dos nodos do ambiente n�o pode ser freq�ente, devido a quest�es como consumo de energia desta operaç�o e tamb�m da necessidade do usu�rio informar dados no dispositivo, podendo uma atualizaç�o mais peri�dica prejudicar esta interface, abaixo ser� mostrado a fase de desenvolvimento e interface com o usu�rio, bem como as operaç�es envolvidas.

3.2 Desenvolvimento do Prot�tipo

O trabalho utilizar� a linguagem de programaç�o J2ME (Java 2 Micro Edition) proveniente da tecnologia Java (J2SE e J2EE) para criar um sistema de comunicaç�o que ir� se basear em uma plataforma de computaç�o distribu�da, isto �, um servidor ir� se comunicar via rede estruturada atrav�s do protocolo TCP/IP com uma estaç�o, esta estaç�o possui um dispositivo Bluetooth IEEE 802.15.1 conectado com a finalidade de monitorar e gerenciar eventos em um ambiente.

A comunicaç�o da estaç�o com o servidor, ser� realizada atrav�s de duas aplicaç�es (Cliente/Servidor) em Java, utilizando um banco de dados MySql para armazenar todas as informaç�es dos dispositivos.

Na comunicaç�o da estaç�o com o dispositivo m�vel, ser� utilizado uma Midlet utilizando J2ME (Java 2 Micro Edition) com a configuraç�o CLDC (Connected Limited Device Configuration) e o profile MIDP 2.0, juntamente com a API JSR 82 (JSR,2002) para capturar informaç�es deste dispositivo via Bluetooth IEEE 802.15.1.

Abaixo s�o especificadas as funcionalidades e aç�es do Prot�tipo:

Descobrir os dispositivos Bluetooth(s) IEEE 802.15.1 que entraram no ambiente atrav�s de t�cnicas de inquiry, utilizando as classes da API JSR-82 que trabalha sobre profile SDP (Service Discovery Protocolo), cadastrando assim em um banco de dados central o endereço MAC e o ambiente que foram localizados.
Autenticar a entrada do dispositivo no ambiente utilizando LMP(Link Manager Protocol).
Definir perfis de aç�es para cada dispositivo e tratar os eventos por perfis.
Descobrir o poss�vel fabricante do dispositivo atrav�s do endereço MAC, pois conforme especificaç�o IEEE 802.15.1 no site os tr�s primeiros bytes do endereço MAC s�o reservados ao fabricante do aparelho, utilizando assim uma base pr�-cadastrada dos tr�s bytes dos endereços MAC de alguns dispositivos.
Descobrir os serviços que o dispositivo suporta.
Criar um canal de comunicaç�o com o dispositivo Bluetooth IEEE 802.15.1.
Utilizar o serviço de comunicaç�o Bluetooth IEEE 802.15.1 para fazer disseminaç�o de uma aplicaç�o para o ambiente com base nos perfis.
Verificar o status dos dispositivos no ambiente.
Verificar a �ltima vez que o dispositivo esteve no determinado ambiente.
Tratar eventos, como a troca de ambiente do dispositivo e aç�es neste dispositivo por localizaç�o no ambiente.
Tratar eventos como avisos ao dispositivo quando ele entrar no ambiente.
Criar uma base de dados com o hist�rico dos dispositivos e eventos associados.

Na Figura 6 � mostrada a interface de comunicaç�o, com os eventos e aç�es acima citados, separando a parte do Servidor e Serviços BlueGw da parte do Usu�rio.

Figura 6. Interface de Comunicaç�o

Todas estas aç�es e eventos de acesso ao dispositivo ser�o implementadas conforme a especificaç�o do J2ME (Java 2 Micro Edition), a escolha desta linguagem para implementaç�o do prot�tipo teve como base algumas consideraç�es do modelo de comunicaç�o e da linguagem que ser�o explicadas a seguir.

A linguagem de programaç�o J2ME (Java 2 Micro Edition), espec�fica um conjunto de configuraç�es, perfis e pacotes opcionais que preenchem as necessidades para a maioria dos dispositivos m�veis do mercado. A finalidade principal � tratar quest�es como mem�ria, processamento, I/O e interface com o usu�rio.

As configuraç�es definem uma m�quina virtual KVM(Kylobyte Virtual Machine) suficientemente pequena para suportar as restriç�es de mem�ria destes dispositivos. S�o especificados dois tipos de configuraç�o:

CLDC (Connected Limited Device Configuration) o qual trata das configuraç�es de dispositivos que necessitam de conex�es intermitentes, processadores de 16 ou 32 bits, com baixo desempenho e pouca mem�ria, que variam de 128 Kbytes a 512 Kbytes para aplicaç�es Java.
CDC (Connected Device Configuration) servem para dispositivos com mais de 512 Kbytes de mem�ria e mais altos recursos de processamento, por tanto n�o foram levados em consideraç�o.

No prot�tipo, a tecnologia de programaç�o que mais se adequou utilizando os recursos do dispositivo Bluetooth IEEE 802.15.1, foi a tecnologia J2ME (Java 2 Micro Edition), os seguintes motivos pesquisados e confirmados (KNU,2003) levaram a esta conclus�o:

Possuir CLDC (Connected Limited Device Configuration) baseada em uma KVM (Kylobyte Virtual Machine) suficientemente pequena para suportar as restriç�es de mem�ria.
O dispositivo m�vel possuir suporte nativo ao MIDP (Mobile Information Device Profile).
Possuir atualmente 70 JSRs (Java Specification Request) na linguagem J2ME (Java 2 Micro Edition) especificamente para dispositivos m�veis.
Possuir uma JSR (Java Specification Request) espec�fica para tratar quest�es de comunicaç�o com Bluetooth IEEE 802.15.1 (JSR,2002).
Possuir uma ferramenta completa de desenvolvimento Nokia Developer Su�te 2.1 for J2ME, com emuladores distribu�dos junto com o SDK, criaç�o de classes, m�todos, pacotes de aplicaç�o com suporte a geraç�o MIDP 1.0 e 2.0 e uma ferramenta para desenho da interface gr�fica da aplicaç�o

A combinaç�o do MIDP (Mobile Information Device Profile) com o CLDC (Connected Limited Device Configuration) utilizando as JSRs (Java Specification Request) fornece um ambiente completo para programaç�o m�vel, com um espectro grande de customizaç�o e configuraç�o para este trabalho.

Conforme pesquisa realizada sobre as ferramentas de programaç�o C++ para ambientes m�veis, n�o foi encontrado um conjunto extenso de ferramentas de programaç�o como os que J2ME (Java 2 Micro Edition) apresenta, algumas ferramentas que est�o dispon�veis no mercado e possuem recursos interessantes s�o comerciais (COD,2005), isto �, existe um custo.

Tamb�m foi constatado que a programaç�o em C++ necessitaria de um conhecimento muito mais profundo das t�cnicas de comunicaç�o no dispositivo Bluetooth IEEE 802.15.1, al�m de t�cnicas para alocaç�o de mem�ria em dispositivos m�veis, quando que, em J2ME (Java 2 Micro Edition) j� existem classes para estas finalidades, facilitando a concepç�o do modelo de comunicaç�o e da interface do sistema.

3.3 Modelo da Interface

A interface de utilizaç�o com o usu�rio ser� do tipo reativa. Ap�s o usu�rio entrar no ambiente, ocorrer�o eventos, muitas vezes informativos ou que necessitar�o de autorizaç�o do usu�rio para sua realizaç�o. Estes eventos envolver�o autorizaç�es para entrar no ambiente, capturar informaç�es ou at� mesmo para instalar alguma aplicaç�o no dispositivo. Todos estes eventos ser�o trabalhados no conceito de ambiente, piconet e scatternet, facilitando assim, m�ltiplos eventos.

Quando um evento do tipo piconet for disparado, somente os membros desta piconet receber�o o evento, tamb�m no sistema ser� previsto, a ocorr�ncia de somente uma piconet por ambiente, evitando assim a formaç�o de uma piconet entre dois ambientes. Da mesma forma quando um evento scatternet for disparado, todos os membros de todas as piconets receberam o evento, podendo com a evoluç�o do sistema de comunicaç�o ser tratado para scatternets entre N ambientes.

Figura 7. Modelo UML Uses Case de Interface Usu�rio e BlueGw

Na Figura 7 acima � mostrado um modelo UML b�sico �uses cases� (JES, 2003) do usu�rio e do BlueGw, com seus respectivos atributos e m�todos , associados ao perfil do usu�rio e tamb�m as poss�veis aç�es que o BlueGw poder� ter.

4. Resultados

Dentre os resultados esperados, pretende-se coletar v�rios tipos de informaç�es atrav�s de MIDP utilizando a JSR 82, podendo relacionar os mesmos em diversos ambientes, mapeando poss�veis alternativas para gerar novos eventos e aç�es, como todo o prot�tipo n�o foi desenvolvido ainda, pretende-se tamb�m mais tarde passar a utilizar a JSR 179 (Location API), agregando recursos novos de mapeamento geogr�fico, mas para isso ainda existe a necessidade da difus�o maior desta API, visto que poucos dispositivos a possuem e o material de desenvolvimento ainda n�o � totalmente difundido.

A id�ia de detectar nodos pode ser aplicada em diversos ambientes, a proposta inicial de gerenciar e mapear ambientes por Bluetooth IEEE 802.15.1, partiu de monitorar quartos de um Hotel, caracterizando o projeto como BlueHotel, onde todos os ambientes do Hotel, desde o registro do usu�rio com seu endereço MAC do dispositivo associado ao n�mero do quarto, at� a sua entrada no quarto seriam facilitados pela utilizaç�o e disponibilizaç�o de serviços neste dispositivo, como por exemplo, em um hotel existem v�rios ambientes, sala de jogos, sala de gin�stica, restaurante, entre outros. O dispositivo Bluetooth IEEE 802.15.1 do celular poderia ser utilizado como localizador nos ambientes do hotel, atrav�s do uso de gateways BlueGw de varredura ligados a um sistema central, esta foi uma id�ia inicial que talvez com os resultados obtidos do projeto possa a vir ser implementada com algumas funcionalidades.

5. Limitaç�es

Sempre � necess�rio reconhecer as poss�veis limitaç�es da implementaç�o, partindo deste preceito, talvez seja necess�rio em algum m�dulo dos algoritmos que ser�o desenvolvidos utilizar aplicaç�es agentes em C++, isso pelo fato de n�o ter total depend�ncia das informaç�es formatadas das classes J2ME e JSR 82 e tamb�m para que possa ser estendida a portabilidade nos dispositivos, sendo assim, ser� necess�rio uma integraç�o destas duas linguagens.

Tamb�m existe o fato de alguns aparelhos que possuem o padr�o Bluetooth IEEE 802.15.1 n�o possu�rem a API JSR 82, mas isto pode ser contornado atrav�s de uma aplicaç�o agente em C++ para coletar os dados, sendo assim pode existir uma certa limitaç�o para coletar alguns dados.

O meio de comunicaç�o entre o servidor central de armazenamento e o BlueGw que controla cada ambiente, pode ser rompido, mas nada impede que sejam implementadas formas de comunicaç�o sobre IEEE 802.11b/g.

Certas informaç�es podem ser perdidas por problemas como poss�veis perda de sinal, dispositivos incompat�veis, falta de bateria, problemas de tr�fego. A disseminaç�o de um sinal em um ambiente n�o pode se expandir para outros ambientes, podendo prejudicar a identificaç�o de dispositivos, pois o mesmo neste caso ir� participar de 2 piconets em ambientes diferentes, mas isto pode ser resolvido, com bloqueadores de sinais de r�dio ou colocando o monitor BlueGw em locais espec�ficos.

6. Conclus�o

Neste artigo foi apresentado uma t�cnica de comunicaç�o e monitoramento de nodos Bluetooth IEEE 802.15.1, constatou-se que a tecnologia evoluiu bastante desde sua criaç�o, a concepç�o de novos profiles vem incrementando a pilha de protocolos e agregando features que podem contribuir em muito para a coleta de dados deste prot�tipo, atualmente as restriç�es se d�o pela limitaç�o de velocidade e pela falta de algumas implementaç�es nativas que deveriam ser incorporadas ao dispositivo Bluetooth IEEE 802.15.1, sem a depend�ncia de uma JSR 82 incorporada ao aparelho m�vel.

Com a atual uni�o dos esforços do Bluetooth SIG (Special Interest Group) com a UWB (Ultra Widebands), pretende-se aguardar e propor trabalhos futuros nesta �rea, implementaç�es novas agregadas a pilha de protocolos e aos profiles, incorporando altas taxas de transmiss�o do UWB(Ultra Wideband).

7. Refer�ncias

Deitel, H. M. ; Deitel, P.J.; Nieto, T. R. E Steinbuhler, K., �Wireless Internet & Mobile Business � How To Program�, Prentice Hall Inc., Estados Unidos, 2002.
Jesse Chonoles, Michael; A. Schardt, James,�UML 2 for Dummies�, Julho 2003.
Knudsen, Jonathan. �Wireless Java � Developing with J2ME�. Second Edition. Editora Apress, 2003.
Miller, M. �Discovering Bluetooth�, Sybex Inc., Estados Unidos, 2001.
Tara M. Swaminatha; Charles R. Elden �Wireless Security and Privacy � Best Practices and Design Techniques�. Pearson Education, Inc., Boston � Estados Unidos, 2002.
Taurion, Cezar. �Internet M�vel Tecnologias, Aplicaç�es e Modelos�. Rio de Janeiro-RJ. Editora Campus, 2002.
Tanenbaum, Andrew S. �Redes de Computadores�. Rio de Janeiro-RJ. 4� Ediç�o, Editora Campus, 2003.

Refer�ncias On Line

BLE (2002) �Bluetooth Security White Paper � Bluetooth SIG Security Expert Group�, Revis�o 1.0, 19 Abril 2002 - Dispon�vel para membros.
BLS (2003) �Bluetooth Specification�, Volume 3, Vers�o 1.2. 05 Novembro 2003 - Dispon�vel para membros, BLU (2005) e ALU(2005).
BLU (2005) �Site Bluetooth Special Interest Group�.
BLT (2003) �Bluetooth Technology Overview�, Vers�o 1.0. 4 Abril 2003 - Dispon�vel somente para membros do Bluetooth SIG. Acesso (BLU,2005) desde 01/03/2005.
CIT(2005)�Scientific Literature Digital Library�.
HEA (2005) Srdjan Krco, David Cleary, Daryl Parker �P2P Mobile Sensor Networks�
IEEE Computer Society
SIE,ROH (2003) Siegemund, Frank; Rohs, Michael - Swiss Federal Institute of Technology Rendezvous Layer Protocols for Bluetooth-Enable Smart Devices

Prot�tipo de Comunica��o Bluetooth IEEE 802.15.1 em Tecnologia M�vel - Parte 02

Veja a descrição metodológica utilizada, especificando o modelo de comunicação, desenvolvimento e interface do protótipo, objetivando prover gerenciamento e tratamento de ações e eventos.