'(6$552//2 '( $3/,&$&,21(6 %/8(7227+ 87,/,=$1'2 (/ $3, -$9$ -65 '(9(/230(17 2) %/8(7227+ $33/,&$7,216 86,1* 7+( -$9$ $3,

-65
0$5< /8= &+,&$1*$1$ ),*8(52$ Universidad del Cauca Grupo W@PColombia marluzch@unicauca.edu.co -$,52 )$%,$1 %$672 3$5('(6 Universidad del Cauca Grupo W@PColombia fbiam@unicauca.edu.co -$9,(5 $/(;$1'(5 +857$'2 *8$&$ Universidad del Cauca Grupo de Ingeniera Telemtica Grupo W@PColombia javhur@unicauca.edu.co 5HVXPHQ La plataforma de desarrollo de Java ofrece constantemente nuevas herramientas a los desarrolladores, para ello cuenta con un proceso ordenado al que se le ha dado el nombre de Java Community Process o simplemente JCP. Una de tantas especificaciones a brindado la posibilidad, a los desarrolladores, de acceder a una nueva tecnologa de comunicaciones como lo es Bluetooth. El desarrollo de aplicaciones Java que involucran la especificacin Bluetooth es un campo an en exploracin contrario al que ya han recorrido otros lenguajes de programacin como C. 3DODEUDV FODYHV DSOLFDFLRQHV EOXHWRRWK PyYLOHV MPH MVH MDYD MDEZW MVU MFS GLVSRVLWLYRV  ,1752'8&&,1 Existen actualmente dos conceptos tecnolgicos ampliamente difundidos, la red ,QWHUQHW y las FRPXQLFDFLRQHV LQDOiPEULFDV. Ambas son cada vez ms utilizadas en el mundo actual, hecho que ha contribuido a la aparicin de tecnologas inalmbricas tales como 'DWRV SRU ,QIUDUURMR ,QIUDUHG 'DWD ,U'$ y %OXHWRRWK que se presentan como alternativas para la interconexin de equipos de red, dispositivos personales e Internet en lo que se ha definido como una Red de rea Personal (Personal Area Network PAN). Sin embargo, la tecnologa Bluetooth presenta ciertas ventajas frente a IrDA en caractersticas tan importantes como el ser un sistema omnidireccional y un mayor ancho de banda. Adems, cuenta con el respaldo de ms de 1300 empresas, entre las que se encuentran Ericsson, IBM, Intel, Nokia, Toshiba, 3Com/Palm, Compaq, Dell, Motorola y Xircom. Este hecho atrae inmediatamente el inters hacia ella pues se trata de un estndar de facto en la industria. Si las perspectivas frente a esta nueva tecnologa se mantienen muy seguramente veremos en muy poco tiempo como ira surgiendo un nuevo entorno para el desarrollo de aplicaciones telemticas. El inters es tal, que por iniciativa de algunas empresas han surgido especificaciones de APIs

$EVWUDFW Java development platform offers new tools to the developers, with an ordered process named Java Community Process or simply JCP. One of these specifications has left to access to a new communication technology like Bluetooth. Java application development, involving the bluetooth specification, is a field in exploration yet, different of the other programming languages like C. .H\ ZRUGV DSSOLFDWLRQV EOXHWRRWK PRELOH GHYLFHV MPH MVH MDYD MDEZW MVU MFS

Bluetooth soportado en lenguajes como Visual C, Delphi o Java, este ltimo, el lenguaje de programacin ideal para futuros desarrollos que involucren diferentes arquitecturas hardware. Con el presente trabajo de investigacin, el Grupo de Ingeniera Telemtica a travs del Grupo de Inters en Desarrollo de Aplicaciones Mviles W@PColombia, enfatiza su esfuerzo en la exploracin de las posibilidades que la tecnologa Bluetooth ofrece para la creacin de nuevos servicios completamente personalizados, utilizando herramientas de desarrollo de software libre que pueden interactuar, por que no, con los futuros sistemas de telecomunicacin de tercera y cuarta generacin. En la primera seccin se expone el proceso de evolucin de la tecnologa Java y su filosofa de desarrollo abierta, en la seccin dos se presentan los fundamentos de la especificacin Bluetooth como tecnologa de soporte para aplicaciones, en la seccin tres se hace la presentacin del API Java para Bluetooth correspondiente al JSR 82 como herramienta de desarrollo y as en la seccin cuatro mostrar su utilizacin mediante el diseo e implementacin de una aplicacin y finalmente en las ltimas dos secciones se presentan las conclusiones y el trabajo a futuro en esta rea.  /$ &2081,'$' -$9$ El desarrollo de Java como tecnologa depende de la direccin que Sun Microsystems determine. Para ello, se organiz un grupo de trabajo que fue denominado el Proceso de Comunidad Java (JCP, Java Community Process) liderado por la Sun y que es el organismo que actualmente regula la evolucin de Java. El JCP es una organizacin totalmente abierta conformada por desarrolladores de Java de diferentes pases y por comerciantes de productos Java, cuya misin es desarrollar y revisar las especificaciones de la tecnologa Java, las implementaciones de referencia, y los kits de compatibilidad de la tecnologa. Tanto la tecnologa Java como el JCP fueron creados originalmente por Sun Microsystems, sin embargo, el JCP ha evolucionado bastante desde el proceso informal que Sun comenz a utilizar en 1995, hasta convertirse actualmente en un proceso formal bajo la supervisin de representantes de algunas organizaciones importantes a travs de la Comunidad Java. El JCP define su propio funcionamiento y las normas por las cuales se rige desde su creacin en diciembre de 1998. [1] El JCP es el responsable de los Requerimientos de Especificacin Java (JSR, Java Specification Request). [2] Los JSR son documentos que contienen las descripciones actuales de propuestas y de especificaciones para la plataforma Java realizadas o lideradas por terceros bajo la supervisin del JCP. En todo momento existen numerosos JSR

en proceso de revisin y aprobacin. La lista de todos los JSR actualizada se puede consultar en http://jcp.org/en/jsr/all. Dentro de estos JSR surgi el JSR 82 Java APIs para Bluetooth como una iniciativa del fabricante de telfonos mviles Motorola para estandarizar un conjunto de APIs Java para que los dispositivos con capacidades Java se puedan integrar en entornos Bluetooth. De igual manera, Bluetooth es un estndar relativamente reciente para la integracin inalmbrica de pequeos dispositivos. Como tal, el JSR 82 es solo una especificacin y su versin final o final release fue publicado en abril del 2002 con una implementacin de referencia del API que sirve como demo de su funcionalidad pero no es prctico para desarrollo. Hasta mediados del 2003 no existan implementaciones comerciales similares. Solo hasta el 30 de Octubre de 2003 se dio la noticia de que la implementacin JavaBluetooth stack es una implementacin 100% de las especificaciones de Bluetooth en su versin 1.1 que actualmente soporta HCI, L2CAP y SDP. Asimismo, estn en proyecto soporte para RFCOMM, TCS y SCO, as como implementaciones de perfiles especficos de Bluetooth como el perfil de manos libres o el perfil de distribucin de audio y video. [3] Algo verdaderamente interesante acerca de esta API es que, aunque implementa el JSR-82 que, tericamente fue pensado para que las aplicaciones puedan acceder desde dispositivos J2ME, el Stack de JavaBluetooth puede ser utilizado sin ningn inconveniente desde aplicaciones J2SE. Otra de las caractersticas a destacar es su arquitectura distribuida que permite compartir un nico chip Bluetooth desde varias aplicaciones. Es importante, antes de abordar el tema del desarrollo de aplicaciones utilizando Bluetooth, conocer un poco mejor esta tecnologa inalmbrica.  %/8(7227+ Bluetooth se define como un estndar global de comunicacin inalmbrica, que permite la transmisin de voz y datos entre diferentes equipos mediante un enlace de radiofrecuencia. Los principales objetivos que se pretenden conseguir con esta norma son: Facilitar las comunicaciones entre equipos mviles y fijos. Eliminar cables y conectores entre stos. Ofrecer la posibilidad de crear pequeas redes inalmbricas y facilitar la sincronizacin de datos entre equipos personales.

La tecnologa Bluetooth comprende hardware, software y requerimientos de interoperabilidad, por lo que para su desarrollo ha sido necesaria la participacin de los principales fabricantes de los sectores de las telecomunicaciones y la informtica.  2UtJHQHV GH OD WHFQRORJtD El origen de la tecnologa bluetooth se remonta al ao 1994 cuando en Ericsson se inici un estudio para investigar la viabilidad de crear una interfaz va radio, de bajo costo y bajo consumo, para la interconexin entre sus telfonos mviles y otros accesorios, como el manos libres, con la intencin de eliminar cables entre dispositivos. Este estudio se inici a partir de un largo proyecto llamado MC link, que investigaba sobre multicomunicadores conectados a una red celular hasta llegar a un enlace de radio de corto alcance, conforme ste proyecto avanzaba se fue viendo claro que ste tipo de enlace poda ser utilizado ampliamente en un gran nmero de aplicaciones, ya que tenia como principal virtud el hecho de que se basaba en un chip de radio relativamente econmico. Posteriormente, a comienzos de 1997, segn avanzaba el proyecto MC link, Ericsson fue despertando el inters de otros fabricantes de equipos porttiles. Sin embargo, para que el sistema tuviera xito, tena que buscar la manera de que un gran nmero de dispositivos estuvieran equipados con sta tecnologa. Esto fue lo que origin a principios de 1998, la creacin de un grupo de inters especial constituido por cinco fabricantes: Ericsson, Nokia, IBM, Toshiba e Intel. La idea del grupo era lograr un conjunto adecuado de reas de negocio compuesta por dos lderes del mercado de las telecomunicaciones, dos lderes del mercado de los PC porttiles y un lder en la fabricacin de chips y de esta manera establecer un estndar para la interfaz area junto con su software de control, con el fin de asegurar la interoperabilidad de los equipos entre los diversos fabricantes. Uno de los inconvenientes a resolver inicialmente fue que el sistema debera operar en todo el mundo, para ello es necesaria una banda de frecuencia abierta a cualquier sistema de radio independientemente del lugar del planeta donde nos encontremos. Slo la banda ISM (Mdico-Cientfica Internacional) de 2,45 Ghz cumple con ste requisito, y solo presenta algunas restricciones en pases como Francia, Espaa y Japn. En el caso de Colombia el Ministerio de Comunicaciones reglamenta su uso de esta manera: Las bandas, 902 - 924 MHz, 2 400 - 2 483,5 MHz y 5 725 - 5 850 MHz se atribuyen a ttulo secundario, conforme con la resolucin 3382 de 15 de diciembre de 1995, para los sistemas de espectro ensanchado. [4] Otro aspecto fue el relacionado con el emisor de radio, este debera consumir poca energa ya que debe integrarse en equipos alimentados por bateras como telfonos mviles o

Asistentes Digitales Personales (PDA), al igual que evitar la gran cantidad de interferencias que se pudieran producir debido a la utilizacin de una banda de uso libre que puede ser compartida por otras redes como por ejemplo, algunos telfonos inalmbricos que trabajan en esta banda de frecuencias. Para ello, en los sistemas de radio Bluetooth se suele utilizar el mtodo de 6DOWR GH )UHFXHQFLD ()UHFXHQF\ +RSSLQJ) debido a que sta tecnologa puede ser integrada en equipos de baja potencia y bajo costo y da solucin al problema de posibles interferencias. Con este sistema se divide la banda de frecuencia en varios canales de salto y los transreceptores, durante la conexin, van cambiando de uno a otro canal de salto de manera pseudo-aleatoria. De esta manera se consigue que el ancho de banda instantneo sea bastante pequeo pero con una gran inmunidad a las interferencias. En el Salto de Frecuencia se utilizan 79 canales de radio con un ancho de banda de 1 Mhz cada uno y una rata mxima de smbolos de 1 MSmbolo/s. Despus de que cada paquete es enviado en una determinada frecuencia de transmisin, sta cambia a otra de las 79 frecuencias. El rango tpico de operacin de Bluetooth es menor a 10 m, sin embargo se pueden alcanzar distancias de hasta 100 m con el uso de amplificadores.  6WDFN GH SURWRFRORV %OXHWRRWK

Figura 1. Stack de protocolos Bluetooth La figura 1 muestra el stack de protocolos de Bluetooth. Los componentes bsicos se muestran en color gris y los componentes especficos aparecen en color verde claro. Empezamos por los componentes bsicos. [5] La capa de comunicacin ms baja es llamada %DQGD %DVH. Esta capa implementa el canal fsico real cuya principal caracterstica es el Salto en Frecuencias, emplea una secuencia aleatoria de saltos a travs de 79 frecuencias de radio diferentes. Los paquetes son enviados sobre el canal fsico en una frecuencia de salto diferente. La Banda Base

controla la sincronizacin de las unidades Bluetooth y la secuencia de saltos en frecuencia, adems es la responsable de la informacin para el control del enlace a bajo nivel como el reconocimiento, control de flujo y caracterizacin de la carga til. Soporta dos tipos de enlaces: 6tQFURQR 2ULHQWDGR D OD &RQH[LyQ (Synchronous Connection Oriented SCO), para datos y $VtQFURQR 1R 2ULHQWDGR D OD &RQH[LyQ (Asynchronous Connectionless ACL), principalmente para audio. Los dos pueden ser multiplexados para usar el mismo enlace de radio frecuencia. Usando ancho de banda reservado, los enlaces SCO soportan trfico de voz en tiempo real. El /LQN 0DQDJHU 3URWRFRO (LMP) o Protocolo de Gestin de Enlace es el responsable de la autenticacin, cifrado, control y configuracin del enlace. El LMP tambin se encarga del manejo de los modos y consumos de potencia, adems soporta los procedimientos necesarios para establecer un enlace SCO. El +RVW &RQWUROOHU ,QWHUIDFH (HCI) o Interfaz del Controlador de Servidor brinda un mtodo de interfaz uniforme para acceder a los recursos hardware de Bluetooth. ste contiene una interfaz de comando para el controlador banda base y la gestin de enlace y para acceder al hardware. El /RJLFDO /LQN &RQWURO DQG $GDSWDWLRQ 3URWRFRO (L2CAP) o Protocolo de Control y Adaptacin de Enlace Lgico, corresponde a la capa de enlace de datos. sta brinda servicios de datos orientados y no orientados a la conexin a las capas superiores. L2CAP multiplexa los protocolos de capas superiores con el fin de enviar varios protocolos sobre un canal banda base. Con el fin de manipular paquetes de capas superiores ms grandes que el mximo tamao del paquete banda base, L2CAP los segmenta en varios paquetes banda base. La capa L2CAP del receptor reensambla los paquetes banda base en paquetes ms grandes para la capa superior. La conexin L2CAP permite el intercambio de informacin referente a la calidad de la conexin, adems maneja grupos, de tal manera que varios dispositivos pueden comunicarse entre s. El protocolo 5)&200 ofrece emulacin de puertos seriales sobre el protocolo L2CAP. RFCOMM emula seales de control y datos RS-232 sobre la banda base Bluetooth. ste ofrece capacidades de transporte a servicios de capas superiores que usan una lnea serial como mecanismo de transporte. RFCOMM soporta dos tipos de comunicacin: 'LUHFWD HQWUH 'LVSRVLWLYRV actuando como terminales y 'LVSRVLWLYR 0yGHP 'LVSRVLWLYR, adems tiene un esquema para emulacin de QXOO PRGHP. El 6HUYLFH 'LVFRYHU\ 3URWRFRO (SDP) o Protocolo de Descubrimiento de Servicio define cmo acta una aplicacin de un cliente Bluetooth para descubrir servicios disponibles de servidores Bluetooth, adems de proporcionar un mtodo para determinar las caractersticas de dichos servicios.

El &RQWURO GH 7HOHIRQtD %LQDULR (TCS binario) es un protocolo que define la sealizacin de control de llamadas, para el establecimiento y liberacin de una conversacin o una llamada de datos entre unidades Bluetooth. Adems, ste ofrece funcionalidad para intercambiar informacin de sealizacin no relacionada con el progreso de llamadas. La capa de $XGLR es una capa especial, usada slo para enviar audio sobre Bluetooth. Las transmisiones de audio pueden ser ejecutadas entre una o ms unidades usando muchos modelos diferentes. Los datos de audio no pasan a travs de la capa L2CAP, sino directamente despus de abrir un enlace directo entre dos unidades Bluetooth. Entre los componentes especficos tenemos: &RQWURO GH WHOHIRQtD &RPDQGRV $7. Bluetooth soporta un nmero de comandos AT para el control de telefona a travs de emulacin de puerto serial (RFCOMM). 3URWRFROR 3XQWR D 3XQWR (PPP). El PPP es un protocolo orientado a paquetes y por lo tanto debe usar un mecanismo serial para convertir un flujo de paquetes de datos en una corriente de datos seriales. Este protocolo corre sobre RFCOMM para lograr las conexiones punto a punto. 3URWRFRORV 8'37&3 ,3. Los estndares UDP/TCP e IP permiten a las unidades Bluetooth conectarse, por ejemplo a Internet, a travs de otras unidades conectadas. Por lo tanto, el dispositivo puede actuar como un puente para Internet. La configuracin TCP/IP/PPP est disponible como un medio de transporte para WAP. :LUHOHVV $SSOLFDWLRQ 3URWRFRO (WAP) o Protocolo de Aplicacin Inalmbrica. WAP es una especificacin de protocolo inalmbrica que trabaja con una amplia variedad de tecnologas de red inalmbricas conectando dispositivos mviles a Internet. Bluetooth puede ser usado como portador para ofrecer el transporte de datos entre el cliente WAP y su servidor de WAP adyacente. Adems, las capacidades de red de Bluetooth dan a un cliente WAP posibilidades nicas en cuanto a movilidad comparada con otros portadores WAP. Un ejemplo de WAP sobre Bluetooth sera un almacn que transmite ofertas especiales a un cliente WAP cuando ste entra en el rango de cobertura. [6] 3URWRFROR 2%(; 2%MHFW (;FKDQJH. El Protocolo de Intercambio de Objetos es un protocolo opcional de nivel de aplicacin diseado para permitir a las unidades Bluetooth soportar comunicacin infrarroja para intercambiar una gran variedad de datos y comandos. ste usa un modelo clienteservidor y es independiente del mecanismo de transporte. OBEX usa RFCOMM como principal capa de transporte. Este stack de protocolos define el comportamiento y las posibilidades de un dispositivo Bluetooth que puede ser

entendido mediante estados. Es importante entender este comportamiento puesto que influye igualmente en las aplicaciones desarrolladas para Bluetooth.  &RPSRUWDPLHQWR GH XQ 'LVSRVLWLYR %OXHWRRWK En Bluetooth se manejan dos conceptos relacionados con la conformacin de redes: las SLFRQHW y las VFDWWHUQHW. Dos o ms dispositivos Bluetooth que comparten el mismo canal de conexin conforman una SLFRQHW. Esta se establece a travs de enlaces punto multipunto, en donde uno de los dispositivos cumple el rol de maestro mientras los dems actan como esclavos como se observa en la figura 2. Una piconet puede tener un mximo de siete esclavos activos. Si un equipo se encuentra dentro del radio de cobertura de otro, stos pueden establecer conexin entre ellos.

Una vez entendidos estos conceptos, podemos analizar cual es el comportamiento de un dispositivo Bluetooth que obedece a un comportamiento descrito por estados como se aprecia en la figura 4.
Espera Espera Inspeccin Inspeccin

Paginacin Paginacin

Conectado Conectado

Transmisin De Datos

Hold Hold

Sniff Sniff

Park Park

Figura 4. Estados en un dispositivo Bluetooth En primera instancia, cuando dos elementos dispositivos coinciden dentro del alcance de sus radios, cada uno empieza a inspeccionar qu otro elemento se encuentra a su alcance, qu servicios ofrece y cul es su direccin fsica. Esto ocurre dentro de un estado de inspeccin denominado ,148,5< o ,QVSHFFLyQ. Una vez se ha conformado la piconet sta debe tener establecido un canal para comunicarse. Para regular el trfico en dicho canal, uno de los dispositivos asume el papel de maestro, y los dems elementos de la red sern esclavos. Una vez terminada la fase de inspeccin ya se tienen las direcciones de los dispositivos y estos pueden empezar a transmitir, no sin antes realizar un PAGING o SDJLQDFLyQ, mediante la cual se establece la conexin con algn dispositivo encontrado. El estado de CONNECTION o FRQH[LyQ es realmente el momento en el que se transfieren los datos y una vez terminada la transferencia, se puede retornar al estado de STANDBY o HVSHUD, bien quedar en alguno de los estados especiales de bajo consumo de energa del dispositivo Bluetooth: SNIFF, estado en el cual el esclavo y el maestro se ponen de acuerdo para transmitir y recibir en slots de tiempo determinados; HOLD, estado en el que el dispositivo se mantiene inactivo durante un intervalo de tiempo, sin importar que llegue o no informacin y PARK, estado del dispositivo en el que deja de participar en la Piconet y queda en un estado de actividad mnima, pero no abandona por completo la receptividad de eventos. Este es otro mecanismo para proporcionar bajo consumo de potencia, y por ello estos tres estados se diferencian en qu tan reactivo se vuelve el sistema ante seales externas y qu consumo de potencia requiere.

Figura 2. Ejemplo de una piconet Sin embargo, slo aquellas unidades que realmente quieran intercambiar informacin comparten un mismo canal creando la piconet. Este hecho permite que se creen varias piconets en reas de cobertura superpuestas. A un grupo de piconets se le llama VFDWWHUQHW, como se aprecia en la figura 3, el PC A interacta en la piconet A con otro PC y en la piconet B con un punto de acceso a una Red de rea Local. [7] Hay que tener en cuenta que cuantas ms piconets se aaden a la scatternet, el rendimiento del sistema de salto en frecuencia disminuye poco a poco, existiendo una reduccin por termino medio del 10%. Sin embargo el rendimiento que finalmente se obtiene de mltiples piconets supera al de una simple piconet. [8]

Figura 3. Ejemplo de una scatternet

 0RGHORV GH XVR %OXHWRRWK Los modelos de uso son escenarios donde pueden tener lugar las aplicaciones Bluetooth, es decir, la tecnologa Bluetooth adems de ofrecer la posibilidad de reemplazar los cables que se usan para transmisin de datos entre distintos dispositivos digitales como computadores, impresoras, telfonos mviles, PDAs, FAX entre otros, brinda tambin la capacidad de crear redes entre personas que tienen sus propios equipos habilitados para Bluetooth. De esta manera se definen algunos modelos de uso comunes entre los cuales se pueden mencionar: &RPSXWDGRU VLQ FDEOHV Es el escenario que mejor describe la concepcin de Bluetooth como una tecnologa para reemplazar cables que transportan datos. Un ejemplo del gran volumen que ocupan estos cables se puede ver en un simple computador de escritorio. En este caso, los perifricos, tales como el ratn, teclado, impresoras, dispositivos de juegos, parlantes, escneres, etc. podran tener un alto grado de libertad al no estar conectados por cables y en cambio hacer uso de enlaces de radio con el PC. +HDGVHWV Los Manos Libres o Headsets son dispositivos que se usan para permitirle a una persona mantener una conversacin telefnica sin tener que sostener el equipo telefnico en sus manos, pero usualmente estos dispositivos tambin estn sujetos a cables, restringiendo la movilidad del usuario; este tambin es un escenario que contempla Bluetooth, dado que soporta explcitamente aplicaciones de voz. 7HOpIRQR  HQ  Un telfono celular tres en uno esta equipado con Bluetooth y puede interactuar de 3 maneras: como celular normal, como inalmbrico usando la lnea telefnica a travs de un punto de acceso de voz, como radio telfono para comunicarse con otro igual en las proximidades. 3XHQWH D ,QWHUQHW Existen dos mtodos para el uso de Bluetooth como un puente inalmbrico para establecer comunicacin con LANs Internet: marcacin telefnica donde se suprime la presencia del cable entre el mdem y el PC, y acceso directo a la red por medio de un punto de acceso Bluetooth.

dependencia se ilustra en la Figura 5, aqu es posible observar como un perfil depende del perfil o perfiles en los que se encuentra contenido directamente e indirectamente. Por ejemplo, el perfil de Acceso a una LAN es dependiente de los perfiles Puerto serial y Acceso Genrico.

Figura 5. Estructura de los perfiles Bluetooth  $3, -$9$ %/8(7227+ -65  Las APIs representan una forma sencilla de programar al abstraer muchas de las operaciones complejas de bajo nivel. Esta API es el resultado de una investigacin realizada por el grupo JSR-82, en la cual se define un paquete de desarrollo para la tecnologa inalmbrica Bluetooth basado en la plataforma 2 de Java Micro Edicin (J2ME, Java 2 Micro Edition). El objetivo de esta especificacin es definir la arquitectura y las APIs asociadas para permitir un entorno de desarrollo abierto para nuevas aplicaciones que empleen la tecnologa Bluetooth como medio para su comunicacin. El grupo experto que desarroll la especificacin est compuesto por Extended Systems, IBM, Mitsubishi Electric, Motorola (Lder de la especificacin), Newbury Networks, Nokia, Parthus Technologies, Research in Motion, Rococo Software, Sharp Laboratories of America, Sony Ericsson Mobile Communications, Smart Fusion, Smart Network Devices, Sun Microsystems, Symbian, Telecordia, Vaultus y Zucotto. El enfoque primordial de las APIs son los dispositivos con capacidad de procesamiento limitada, poca memoria y que operan con batera. Adems, como la especificacin Bluetooth se encuentra en un continuo proceso de desarrollo, a medida que se adicionan nuevos perfiles, es necesario tener en cuenta que los nuevos perfiles Bluetooth puedan construirse sobre estas APIs usando el lenguaje de programacin Java, siempre y cuando el ncleo de la especificacin no cambie.

 3HUILOHV %OXHWRRWK Los perfiles de Bluetooth se han desarrollado para describir cmo se ejecutan las aplicaciones de los modelos de uso, estos perfiles son definidos como parte de la especificacin Bluetooth y tienen como fin principal hacer que las aplicaciones puedan enmarcarse en tales perfiles y de esta manera disminuir el riesgo de problemas de interoperabilidad entre productos y aplicaciones de fabricantes diferentes. Un perfil es dependiente de otro perfil si reutiliza partes de ese perfil, referencindolos implcitamente o explcitamente. La

 $UTXLWHFWXUD GH OD (VSHFLILFDFLyQ -65 Basados en el alcance de esta especificacin la funcionalidad ofrecida por la misma se clasifica en tres categoras funcionales, como se puede observar en la figura 6.

sobre un dispositivo con soporte para el Perfil de Informacin del Dispositivo Mvil (MIDP, Mobile Information Device Profile), el API JSR 82 no depende de las APIs de MIDP, y en trminos generales puede funcionar tambin sobre J2SE.

Figura 6. Funcionalidad ofrecida por JSR-82 Descubrimiento: Esta categora incluye el descubrimiento del dispositivo, descubrimiento del servicio y registro del servicio. Comunicacin: incluye establecimiento de conexiones entre dispositivos y el uso de estas conexiones para la comunicacin Bluetooth entre las aplicaciones. Gestin de Dispositivos: permite manejar y controlar las conexiones establecidas. Figura 8. Arquitectura JSR-82 y MIP El bloque del primer nivel en la figura 8 es el software del sistema o el sistema operativo del servidor. El sistema operativo del servidor tiene la parte del servidor del stack de protocolos de Bluetooth y otras bibliotecas que son utilizadas internamente y por las aplicaciones nativas del sistema. Las aplicaciones nativas de Bluetooth interactan con el sistema operativo directamente. [9] Aunque el pensamiento inicial era definir un API basado en los perfiles de Bluetooth, el grupo de expertos JSR-82 pens que el nmero de los perfiles de Bluetooth estara creciendo constantemente. El grupo de expertos decidi entonces proporcionar solo el soporte para los protocolos y los perfiles bsicos en lugar de introducir nuevos elementos al API para cada perfil de Bluetooth. Aunque es difcil predecir las necesidades de los perfiles futuros de Bluetooth, la esperanza es que el diseo del JSR-82 permitir que los perfiles de Bluetooth sean escritos en el lenguaje de programacin Java.  $3/,&$&,1 -$9$ %/8(7227+ La aplicacin permite a un usuario de un dispositivo mvil conectarse a una Red de rea Local y utilizar los servicios que en ella se ofrecen; en una segunda versin se utiliz un equipo porttil con una tarjeta bluetooth conectada por puerto serial para comunicarse con los diferentes puntos de acceso que existan. Para efectos didcticos, tambin se busc que en la aplicacin involucrada se puedan apreciar los procedimientos de conexin y comunicacin relacionados con Bluetooth. Figura 7. Estructura de paquetes de la API La figura 8 muestra un ejemplo de cmo JSR 82 se ajusta dentro de la arquitectura de J2ME. Aunque aqu se muestra El Prototipo de la aplicacin para Bluetooth esta basado en la plataforma Java y en las herramientas que esta ofrece, de acuerdo con la especificacin Bluetooth 1.1, teniendo en

 3DTXHWHV Dentro de la especificacin se encuentran definidos dos paquetes: el paquete MDYD[EOXHWRRWK y el paquete MDYD[REH[. Se debe tener claro que la API OBEX esta definida independientemente de la capa de transporte Bluetooth y se empaqueta por separado, esto implica que cualquier aplicacin, puede incluir alguno de los dos paquetes o los dos. El primer paquete hace referencia a la API central de Bluetooth y el segundo paquete contiene las APIs para OBEX. La Figura 7 muestra la estructura de paquetes donde se muestra la dependencia del paquete MDYD[PLFURHGLWLRQLR.

cuenta adems, los perfiles especficos descritos en ella. Se hizo el diseo y la implementacin de la aplicacin modularmente empleando para ello la implementacin del API Java Bluetooth basado en la especificacin JSR 82 implementado por Christ Lorentz. [10] que adems de brindar soporte para dispositivos mviles J2ME, permite desarrollar para aplicaciones de escritorio J2SE. La aplicacin tiene las siguientes caractersticas: Permita al usuario de un dispositivo mvil ya sea un porttil, una PDA o un telfono celular, conectarse a travs de un punto de acceso a una Red de rea Local LAN y ser autorizado para usar los servicios que ella ofrece. La aplicacin permite la bsqueda de los dispositivos que prestan el servicio de acceso a una LAN. Realiza la validacin de usuarios para poder hacer uso de los servicios que son prestados.  &DVRV GH 8VR Toda aplicacin desarrollada sobre la tecnologa Bluetooth, empleando Java, debe implementar los siguientes casos de uso bsicos como se aprecia en la figura 9.

Cada uno de los casos de uso corresponde con los diferentes pasos que toda aplicacin bluetooth debe llevar a cabo para utilizar un servicio o cumplir con su funcionalidad.

Figura 9. Diagrama de casos de uso &DVR GH XVR ,QLFLDU 6WDFN Establecimiento de parmetros de configuracin para la conexin e inicializacin de los componentes del API: Configuracin de puerto, Modo de Encriptacin y Autenticacin, Tiempo mximo de establecimiento de la conexin, Tiempo mximo de respuesta a paginacin,

Clase de Dispositivo, Nombre del Dispositivo, Modo de Escaneo. &DVR GH XVR 3XEOLFDU 6HUYLFLRV Se establece una conexin para almacenamiento de servicios en el dispositivo local, con el fin de que otros dispositivos puedan encontrar los servicios que se est en capacidad de suministrar. Para cada servicio que se registra deben registrarse sus atributos especficos; aquellos por los cuales ser interrogado en caso de que otro dispositivo desee acceder a este servicio. Estos Atributos son: Nombre del servicio, los protocolos que emplea para poder ejecutarse y los atributos especiales de estos protocolos de acuerdo con el servicio en cuestin. &DVR GH XVR %XVFDU 'LVSRVLWLYRV Ejecuta la bsqueda de dispositivos en el entorno y permanece en estado de espera de respuestas. En caso de que un dispositivo remoto conteste la solicitud, se ejecuta otra solicitud para conocer el nombre de dicho dispositivo; una vez establecida la conexin de datos con el dispositivo remoto el sistema presenta al usuario el nombre y la direccin del dispositivo remoto con el cual se ha establecido la conexin. %XVFDU 6HUYLFLRV Preguntar al dispositivo remoto si tiene disponible el servio que cumple con un patrn definido. En caso de que el dispositivo remoto cuente con el servicio que coincide con el patrn de bsqueda, responder devolviendo los identificadores de este servicio que se ha almacenado con anterioridad en su base de datos. Para cada uno de los identificadores de servicio devueltos por el dispositivo remoto, se indaga tambin acerca de sus caractersticas de servicio; estas caractersticas corresponden al Nombre del servicio, los protocolos que emplea para poder ejecutarse y los atributos especiales de estos protocolos de acuerdo al servicio en cuestin. &RQHFWDU 6HUYLFLR A partir del registro del servicio obtenido, se obtiene los requerimientos de conexin que exige dicho servicio para conectarse con l, a partir de este se crea la conexin y se inicia el uso del servicio. (QYLDU 'DWRV Este corresponde al servicio de envo de mensajes entre el cliente y el servidor; es decir corresponde a la lgica del servicio que se quiere prestar. 7UDQVIHULU DUFKLYR Brinda la posibilidad de transferir archivos entre terminales que el cliente puede compartir una vez se conecte al servicio. [11]

 0RGR GH IXQFLRQDPLHQWR La aplicacin consta de dos mdulos bsicos, el modulo del cliente y el mdulo del servidor ambos dentro de la misma aplicacin. Una aplicacin bluetooth tiene la caracterstica de actuar tanto como cliente como servidor dependiendo del

contexto en el que se ejecute o del papel que desempee dentro de una piconet. La figura 10 ilustra los elementos que componen la aplicacin en ambos mdulos.

&OLHQWH
$SOLFDFLyQ &OLHQWH

6HUYLGRU
$SOLFDFLyQ 6HUYLGRU

Los servicios VHUYLFLR y VHUYLFLR del lado del cliente se encargan de la lgica que corresponde para alcanzar la conexin con el servidor del servicio correspondiente empleando algn protocolo como SPP o L2CAP. El mdulo del servidor se compone de la aplicacin del servidor del servicio que se encarga del registro y publicacin de los servicios que se desean ofrecer a los clientes y, finalmente de crear los hilos de ejecucin para cada uno de los servicios ofrecidos. Igualmente, los servicios VHUYLFLR y VHUYLFLR del lado del servidor corresponden a la lgica que ofrece cada servicio (son hilos que quedan esperando por la conexin de clientes) Los servicios que se implementaron fueron el de mensajera tipo chat y la transferencia de archivos, entre PCs utilizando tarjetas bluetooth. Finalmente, el stack de protocolos Bluetooth es el camino que se utiliza para la comunicacin entre los clientes y servidores de cada servicio y que es abstrado por el API Java. Sintetizando, las responsabilidades bsicas de un Servidor de Aplicaciones Bluetooth son: Crear un registro de servicio que describa el servicio ofrecido por la aplicacin. Agregar un registro de servicio a la SDDB del servidor para que el servicio quede disponible a otros dispositivos. Establecer las medidas de seguridad asociadas a este servicio para fortalecer la conexin con los clientes. Aceptar las conexiones de los clientes que solicitan el servicio ofrecido por la aplicacin. Actualizar el registro del servicio en la SDDB del servidor cada vez que las caractersticas del servicio cambien. Borrar o desactivar el registro del servicio de la SDDB del servidor cuando el servicio no ha estado disponible por algn tiempo.

6HUYLFLR

6HUYLFLR

6HUYLFLR

6HUYLFLR

6WDFN %OXHWRRWK

6WDFN %OXHWRRWK

Figura 10. Mdulos de la aplicacin Un servicio Bluetooth es una aplicacin que acta como un servidor el cual proporciona algn tipo de asistencia a dispositivos clientes a travs de comunicaciones Bluetooth, generalmente esta asistencia es una capacidad o funcin que no est disponible localmente en el dispositivo cliente. Teniendo en cuenta los perfiles Bluetooth se pueden encontrar ejemplos de Servidores de Aplicaciones Bluetooth como: Servidores de Acceso a una LAN, Servidores de Objetos y Archivos, Sincronizacin de Servicios y as sucesivamente. Se pueden definir Servidores de Aplicaciones Bluetooth adems de los especificados en los perfiles y hacer que stos se encuentren disponibles a clientes remotos definiendo un registro de servicio que describa el servicio y agregando este a la base de datos de descubrimiento del servicio (SDDB, Service Discovery Data Base) del dispositivo local. De esta forma, una aplicacin Bluetooth debe realizar cinco tareas fundamentales: Inicializacin del stack de Protocolos, Gestin de dispositivos, Descubrimiento del dispositivo, Descubrimiento del Servicio y el Establecimiento de una comunicacin. Una vez el registro de servicio ha sido almacenado en la SDDB, la aplicacin servidor espera por una aplicacin cliente para iniciar el contacto con el servidor de acceso al servicio, de esta manera la aplicacin cliente y la aplicacin servidor establecen una conexin Bluetooth para negociar sus requerimientos. El modulo del cliente esta compuesto por: La aplicacin del cliente del servicio que se encargada de la inicializacin del stack de protocolos, de la bsqueda de dispositivos y la bsqueda de los servicios en los dispositivos remotos y, finalmente de la creacin de hilos de ejecucin para cada uno de los clientes de los servicios especficos.

Las responsabilidades bsicas de una Aplicacin Cliente Bluetooth son: Usar el SDP para indagar a una SDDB remota acerca de algn servicio deseado. Establecer las medidas de seguridad asociadas a este servicio para fortalecer la conexin con el servidor. Iniciar conexiones a servidores que ofrecen los servicios deseados.

Opcionalmente, revisar la SDDB para determinar si el servicio ha cambiado o no esta disponible.

Las responsabilidades de la pila de protocolos de Bluetooth con aplicaciones Servidor Bluetooth son: Proporcionar un lugar para los registros del servicio que permiten a los servidores adicionar, actualizar y eliminar sus propios registros de servicio. Permitir el establecimiento de conexiones lgicas con las aplicaciones del cliente.

El Paquete Datos de Aplicacin Punto de Acceso_BT incluye la definicin de las entidades de datos con las cuales se relacionan las dems clases, que en el contexto de la aplicacin se ven referenciadas en la base de datos con la que se pretende trabajar. Debido a lo extenso de la documentacin, se presentan solo las caractersticas de anlisis y diseo mas relevantes. El diagrama de clases para el caso de uso Establecer conexin
<<Interfaz>> ListaDisposit
0RVWUDU /LVWD GH 'LVSRVLWLYRV

<<Entidad>> Dispositivo GetDireccin() GetNombre() SetDireccin() SetNombre()

Las responsabilidades de la pila de protocolos de Bluetooth con aplicaciones Cliente Bluetooth son: Permitir la bsqueda y recuperacin de registros de servicios almacenados en la SDDB del servidor. Permitir el establecimiento de conexiones lgicas con las aplicaciones del servidor.

InsertDisposit() BorrarTodo() MostrarDisposit()

*HVWLRQD 'LVSRVLWLYRV

0RVWUDU ,QWHUID] %XVFDU 'LVSRVLWV %XVFDU 6HUYLFLRV 5HJLVWUDU 6HUYLF

<<Interfaz>> PA_IDialogo ConectarClick() RegistServClick() ServiciosClick() DesconecClick() CerrarClick() MostrarInterfaz() MostrarDispositivo() MostrarInfo()
,QIRUPDU HYHQWRV GHO XVXDULR

<<Control>> PA_CDialogo startInquiry() OnConnect() deviceDiscovered() servicesDiscovered() Registrar()

<<Entidad>> Conexin IntroducirInfoServ() IntroducirInfoConx() ExtraerInfoServ() ExtraerInfoConx()

*HVWLRQD ,QIR GH &RQH[LyQ

Usuario
(from Use Case Vi ew)

MensjConfirm Sin embargo, la movilidad en los dispositivos inalmbricos implica la Activar() AceptarClick() necesidad de encontrar una forma para Desactivar() conectarse a otros dispositivos y aprender acerca de lo que dichos dispositivos pueden llegar a hacer. Afortunadamente, la especificacin JSR-82 proporciona APIs que permiten descubrir dispositivos, encontrar servicios y ofrecer servicios a otros dispositivos

<<Interfaz>>

&RQILUPDFLyQ

)XQFLRQHV $3, *HVWLRQD 6HUYLFLRV

API Bluetooth
0RVWUDU /LVWD GH 6HUYLFLRV

<<Interfaz>> ListaServic InsertServicios() BorrarTodo() MostrarServic()

<<Entidad>> Servicio
<<Control>> Disp_Remote getBluetoothAddressRemote() getFriendlyNameRemote() getRemoteDevice()

CrearServicio() GetServicio() ModServicio() ElimiServicio()

se muestra en la figura 12. Figura 12. Clases del Caso de Uso Establecer conexin  ,QLFLDOL]DFLyQ GHO 6WDFN GH SURWRFRORV El stack de protocolos de Bluetooth es el directo responsable del control de los dispositivos, y es por esta razn que antes de hacer cualquier cosa se debe inicializar. El proceso de inicializacin comprende varios pasos con los cuales se debe obtener el dispositivo que se encuentre listo para establecer una comunicacin inalmbrica. Desafortunadamente la especificacin Bluetooth permite que la inicializacin del stack sea diferente de acuerdo a cada fabricante por ello en algunos dispositivos puede ser una Interfaz de Usuario, mientras que en otros pueden ser unas variables preestablecidas y que no pueden ser modificar por el usuario. A continuacin se muestra la solucin para la inicializacin del Stack utilizada en la aplicacin implementada, sin embargo es de anotar que cada fabricante lo puede hacer de una forma diferente y esto puede afectar principalmente el desarrollo de aplicaciones en dispositivos j2me:  )LMDU HO QXPHUR GHO SXHUWR %&&VHW3RUW1XPEHU &20 

 &ODVHV Empleando el paradigma Modelo Vista Control MVC muy utilizado en Java, se dividi el sistema en los tres paquetes bsicos presentados en la figura 11.

Figura 11. Diagrama de paquetes de anlisis. El Paquete Interfaz de Aplicacin Punto de Acceso_BT contiene todas las clases de interfaz que interactan directamente con los usuarios de la aplicacin. El Paquete Control de Aplicacin Punto de Acceso_BT incluye todas las clases de control que ejecutan las acciones de visualizacin, adicin, modificacin, consulta y eliminacin desde y hacia las bases de datos del sistema. Estas clases permiten obtener la funcionalidad deseada del sistema en general.

 )LMDU OD YHORFLGDG HQ EDXGLRV %&&VHW%DXG5DWH  )LMDU HO PRGR FRQHFWDEOH %&&VHW&RQQHFWDEOHWUXH  )LMDU HO PRGR GH GHVFXEULPLHQWR  SDUD XQ FyGLJR GH $FFHVR D ,QGDJDFLyQ OLPLWDGR %&&VHW'LVFRYHUDEOH'LVFRYHU\$JHQW/,$&  'HVFXEULPLHQWR GHO GLVSRVLWLYR Una aplicacin puede obtener una lista de los dispositivos que estn dentro de su rango de cobertura usando los mtodos VWDUW,QTXLU\()o UHWULHYH'HYLFHV(), los cuales estn dentro de la clase 'LVFRYHU\$JHQW del paquete -DYD[%OXHWRRWK. Para utilizar el mtodo VWDUW,QTXLU\() se requiere que la aplicacin especifique una clase que permanentemente este escuchando (listener); entonces este listener notifica cuando se encuentran nuevos dispositivos a travs de una indagacin. Si una aplicacin no desea esperar por la respuesta a una indagacin, la API proporciona el mtodo UHWULHYH'HYLFHV() el cual retorna la lista de dispositivos que ya se haban encontrado en una indagacin anterior, es decir, dispositivos clasificados como ya conocidos, este mtodo no realiza una indagacin, pero proporciona una manera rpida de conseguir una lista de dispositivos que puedan estar dentro del rea. Una vez que se descubre un dispositivo, se inicia una bsqueda de servicio. El diagrama de secuencia para el proceso de descubrimiento del dispositivo se muestra en la figura 13 y permite una mejor comprensin del proceso mediante el intercambio de mensajes entre las clases que actan y el API Java para Bluetooth.
: PA_IDialogo : Usuario
ConectarClick( )
startInquiry( )
Buscar Disp. remotos
BorrarTodo( )
Esperar Respuesta
Resp. disp. remotos

 'HVFXEULPLHQWR GHO VHUYLFLR Un cliente puede descubrir algunos servicios que se encuentran disponibles sobre un servidor de descubrimiento del servicio. La clase 'LVFRYHU\$JHQW proporciona los mtodos para buscar los servicios sobre un dispositivo servidor Bluetooth e iniciar las transacciones relacionadas con el descubrimiento del dispositivo y del servicio. El proceso por el cual un cliente puede descubrir los servicios esta descrito en el Perfil de Aplicacin de Descubrimiento del Servicio (SDAP, Service Discovery Agent Profile). Esta especificacin soporta las siguientes funcionalidades SDAP: Buscar servicios de una clase de servicio en particular. Recuperar los atributos del servicio. Simultneamente buscar servicios y recuperar sus atributos. Terminar una transaccin de bsqueda del servicio.

Para descubrir los servicios que se encuentran disponibles en un servidor de descubrimiento del servicio, la aplicacin del cliente primero recupera un objeto que encapsula la funcionalidad SDAP, dicho objeto adems de ser de tipo 'LVFRYHU\$JHQW es un objeto global. El cdigo que permite recuperar el 'LVFRYHU\$JHQW se muestra a continuacin:
'LVFRYHU\$JHQW GD /RFDO'HYLFHJHW/RFDO'HYLFHJHW'LVFRYHU\$JHQW

: PA_CDialogo

: Dispositivo

: ListaDisposit

: API Bluetooth

: Disp_Remote

Tratar respuesta
SetDireccin( )
Solicitud Nom.Disp.Remoto
getFriendlyNameRemote( )
Nombre Remoto
SetNombre( )
MostrarDisposit( )

Nombre Remoto

El mayor inconveniente a resolver fue la carencia de soporte del API Java para el protocolo RFCOMM que fue resuelta gracias a la implementacin de referencia con versin acadmica ofrecida por la empresa Rococo Software. [12] Las pruebas de esta versin de la aplicacin fueron realizadas sobre el sistema operativo Linux Mandrake 9.1 y J2SE 1.4.1, y sobre el sistemas operativo Windows 2000 con J2SE 1.4.1. En ambos casos se consigui encontrar el dispositivo local, el dispositivos remoto y descubrir los servicios publicados por el servidor bluetooth remoto a distancias de 3 a 5 metros, a mayores distancias se perda la conexin. El diagrama de secuencia que ilustra el proceso de descubrimiento del servicio se muestra en la figura 14.

MostrarNombDispos
Select Dispositivo
Solicitar Cx de Datos
Resp. Disp. Remoto

Aviso Solic. Cx Datos

Resp. Solicit.

Confirmar Cx de Datos

Tratar Respuesta

Figura 13. Diagrama de secuencia: Descubrimiento de dispositivos


: PA_IDialogo : Usuario SearchServices Buscar Servicios : PA_CDialogo : Conexin : Servicio : ListaServic : API Bluetooth

setDiscoverable() : Este mtodo puede fijar el modo en que funciona el dispositivo local (descubrible o no descubrible). updateRecord() : Este mtodo actualiza el registro del servicio en la Base de Datos local.

BorrarTodo( ) Busqueda Inicializada Patrones de Busqueda Resp. Busqueda Tratar respuesta CrearServicio( ) IntroducirInfoConx( ) Solic. Atrib. Servicio Resp. Atrib. Servicio Tratar Respuesta ModServicio( ) IntroducirInfoServ( ) InsertServicios( ) MostrarServicio

 &ODVH 'LVSB5HPRWR La Clase 'LVSB5HPRWR representa un dispositivo Bluetooth Remoto. Esta proporciona informacin bsica sobre un dispositivo remoto incluyendo su direccin y su nombre. Implementa los siguientes mtodos: authenticate() : Este mtodo intenta autenticar al dispositivo remoto, es decir verificar la identidad del mismo. authorize() : Este mtodo determina si el dispositivo remoto debe ser habilitado para acceder al servicio local proporcionado por la conexin. encrypt() : Este mtodo va ha ser el encargado de fijar en on o en off el cifrado para una conexin existente. equals() : Este mtodo determina si dos dispositivos remotos son iguales, es decir si tienen la misma direccin Bluetooth. getBluetoothAddressRemote() : Este mtodo es el encargado de recuperar la direccin Bluetooth del dispositivo remoto. getFriendlyNameRemote() : Este mtodo es el encargado de recuperar el nombre del dispositivo remoto. getRemoteDevice(): Este mtodo recupera el dispositivo Bluetooth que est en el otro lado de una conexin de Puerto Serial, una conexin L2CAP o una conexin OBEX sobre RFCOMM. isAuthenticated(): Este mtodo determina dispositivo remoto ha sido autenticado. si el

Figura 14. Diagrama de secuencia: Descubrimiento de servicios Otro de los elementos importantes en este tipo de aplicaciones son las clases que representan a los dispositivos local y remoto.  &ODVH 'LVSB/RFDO La Clase 'LVSB/RFDO define las funciones bsicas que proporciona el nivel mas bajo de la interfaz en la pila de protocolos Bluetooth y permite el control y el acceso al dispositivo Bluetooth local. Implementa los siguientes mtodos: getBluetoothAddress() : Este mtodo es el encargado de recuperar la direccin Bluetooth del dispositivo local. getDeviceClass() : Este mtodo es el encargado de recuperar las clases que representan el VHUYLFLR y las FODVHV GH GLVSRVLWLYRV del dispositivo local. getDiscoverable() : Este mtodo recupera el modo en que esta funcionando el dispositivo local (descubrible o no descubrible). getFriendlyName() : Este mtodo es el encargado de recuperar el nombre del dispositivo local en lugar de emplear su direccin bluetooth. getProperty(): Este mtodo recupera las propiedades del sistema Bluetooth, tales como la versin del API JAVA para la tecnologa Bluetooth que se soporta, el mximo numero de dispositivos conectados que se soportan, etc.

isAuthorized(): Este mtodo determina si el dispositivo remoto ha sido previamente autorizado por el dispositivo local para intercambiar datos relacionados al servicio asociado con la conexin. isEncrypted(): Este mtodo determina si los datos intercambiados con el dispositivo remoto ha sido encriptado.

La interfaz principal de la aplicacin se puede apreciar en la figura 15 ejecutada sobre un equipo con sistema operativo windows xp.

 &21&/86,21(6 Este tipo de aplicaciones an cuenta con algunas restricciones debido principalmente al manejo de puertos que efecta el sistema operativo. En el caso de windows XP, su misma filosofa de seguridad no permite el correcto funcionamiento de las aplicaciones bluetooth java. La mejor opcin de comunicacin con la interfaz bluetooth (tarjeta) en un equipo porttil (computador de escritorio) y desarrollando con otros lenguajes diferentes a Java es la del puerto USB debido a que el sistema operativo no restringe el acceso de la aplicacin al puerto como sucede con los puertos seriales. En Java se debe trabajar con los puertos seriales porque aun no existe una implementacin confiable de una API para puerto USB. La nica implementacin existente es conocida como jUSB [14] y est en versin beta para linux, y un intento de implementacin limitado para windows [15]. El desarrollo de Aplicaciones Java para Bluetooth es sin lugar a dudas un nuevo mundo de posibilidades dentro de la sociedad de la informacin y ms aun ahora que se cuenta con la tecnologa hardware que le brinda soporte. En Colombia ya es posible encontrar un sin nmero de dispositivos con soporte para bluetooth como telfonos mviles y PDAs, al igual que los chips bluetooth de ericsson para la construccin de tarjetas propias. El desarrollo de aplicaciones Java Bluetooth no es para nada complejo como se podra pensar, gracias al esfuerzo que realiz el grupo de trabajo del JSR-82, ya que esta especificacin permite abstraer al mximo el complejo conjunto de protocolos que maneja la especificacin Bluetooth.  5()(5(1&,$6
[1] El proceso del Java Community Process V2.6. http://jcp.org/aboutJava/communityprocess/first/jsr215/JCP2_6.pd f [2] Java Specification Request. Java Community Process. http://jcp.org/en/jsr/overview [3] Noticia en el portal JavaHispano. http://www.javahispano.org/news.item.action?id=1264210633 [4] &XDGUR 1DFLRQDO GH $WULEXFLyQ GH %DQGDV GH )UHFXHQFLD. Ministerio de Comunicaciones de Colombia. http://www.mincomunicaciones.gov.co/Archivos/Sectorial/Cuadro Atribucion.pdf

Figura 15. Interfaz principal de la aplicacin java bluetooth Como se aprecia, la idea central de la aplicacin es la de servir como herramienta didctica para el entendimiento de los diferentes procesos involucrados en el funcionamiento de aplicaciones bluetooth que utilizan el lenguaje Java para su desarrollo. Para ello, se cuenta con una serie de botones que sern habilitados en serie de acuerdo a la secuencia apropiada de procesos para la comunicacin de dos dispositivos bluetooth.  75$%$-2 $ )87852 Gracias al trabajo de la Universidad del Valle relacionado con redes inalmbricas Bluetooth [13], ahora se espera implementar una red Bluetooth propia que permita realizar pruebas con aplicaciones Java Bluetooth en un entorno bajo condiciones reales. Igualmente sera posible implementar nuevas aplicaciones basadas en la API comercial Java de Rococo Soft sobre plataforma Linux para realizar pruebas de interoperabilidad con aplicaciones basadas en el API Java Bluetooth de Christ Lorentz y comprobar su funcionamiento sobre la red Bluetooth. Finalmente, realizar nuevos desarrollos y pruebas de interoperabilidad entre diferentes plataformas y APIs de desarrollo de otros lenguajes como C++ y Delphi con las aplicaciones Java.

[5] Java Specification http://jcp.org/en/jsr/detail?id=82

Request

for

Bluetooth

[6] WAP Forum. 2003. http://www.wapforum.com [7] Concepto de Piconet. http://www.bluetooth.org [8] Concepto de Scatternet. http://www.bluetooth.org [9] Developing Bluetooth Applications in Java: Part 1. http://www.iapplianceweb.com/story/OEG20040117S0021 [10] The Java Bluetooth Stack http://javabluetooth.chris-lorenz.com/ de Chirst Lorentz.

universidad y Coordinador del Grupo W@PColombia. Sus reas de inters y nfasis son Desarrollo de Aplicaciones y Servicios Telemticos bajo plataforma web y para Dispositivos Mviles, Sistemas de Informacin, Sistemas distribuidos basados en Agentes, Interoperabilidad de Aplicaciones y Redes Inalmbricas.

[11] Chicangana, Mary Luz. Basto, Jairo Fabin. 'LVHxR GH XQ SURWRWLSR GH 6HUYLFLR 7HOHPiWLFR SDUD %OXHWRRWK EDVDGR HQ OD SODWDIRUPD -DYD, Monografa de trabajo de grado, Universidad del Cauca, Popayn, 2004. [12] Bluetooth Toolkit for Java. http://www.rococosoft.com/products/tlk.html Rococo Software.

[13] Maya Coral, Ricardo Andrs. Rodrguez Calvachi, Oscar Daro. ,PSOHPHQWDFLyQ GH XQD UHG LQDOiPEULFD %OXHWRRWK. Monografa de Trabajo de Grado. Facultad de Ingeniera. Universidad del Valle. Cali. 2003. [14] jUSB: Java USB. http:// jusb.sourceforge.net/

[15] An implementation attempt to provide jUSB for Windows 2000/XP. http://www.steelbrothers.ch/jusb/

&9 0DU\ /X] &KLFDQJDQD Ingeniero en Electrnica y Telecomunicaciones 2004, Universidad del Cauca. Actualmente es miembro del Grupo de Inters en Desarrollo de Aplicaciones para Dispositivos Mviles W@PColombia parte del Grupo en Ingeniera Telemtica de la Universidad del Cauca. Sus reas de inters y nfasis son el desarrollo de aplicaciones Java y Tecnologas Inalmbricas de Corto Alcance. -DLUR )DELiQ %DVWR 3DUHGHV Ingeniero en Electrnica y Telecomunicaciones 2004, Universidad del Cauca. Actualmente es miembro del Grupo de Inters en Desarrollo de Aplicaciones para Dispositivos Mviles W@PColombia parte del Grupo en Ingeniera Telemtica de la Universidad del Cauca. Sus reas de inters y nfasis son el desarrollo de aplicaciones Java y Tecnologas Inalmbricas de Corto Alcance. -DYLHU $OH[DQGHU +XUWDGR *XDFD Ingeniero en Electrnica y Telecomunicaciones 2001. Especialista en Redes y Servicios Telemticos 2004, Universidad del Cauca. Actualmente se desempea como profesor del Departamento de Telemtica. Miembro del Grupo en Ingeniera Telemtica de la misma