Protótipo de Comunicação Bluetooth IEEE 802.15.1 em Tecnologia Móvel - Parte 02

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.

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.

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.

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