Desarrollo de un Control Remoto para PC vía Bluetooth

Texto completo

(1)Universidad Central “Marta Abreu” de Las Villas Facultad de Ingeniería Eléctrica Departamento de Telecomunicaciones y electrónica. TRABAJO DE DIPLOMA Desarrollo de un Control Remoto para PC vía Bluetooth Autor: Damián Alejandro Bartumeu Rodríguez. Tutor: MSc. David Beltrán Casanova. Santa Clara 2012 "Año 54 de la Revolución".

(2) Universidad Central “Marta Abreu” de Las Villas Facultad de Ingeniería Eléctrica Departamento de Automática y Sistemas Computacionales. TRABAJO DE DIPLOMA Desarrollo de un Control Remoto para PC vía Bluetooth Autor: Damián Alejandro Bartumeu Rodríguez e-mail: dbartumeu@uclv.edu.cu tel.: 0152203999. Tutor: MSc. David Beltrán Casanova Prof. Dpto. de Telecomunicaciones y Electrónica Facultad de Ing. Eléctrica. UCLV. e-mail: beltran@uclv.edu.cu Santa Clara 2012 "Año 54 de la Revolución".

(3) Hago constar que el presente trabajo de diploma fue realizado en la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de estudios de la especialidad de Ingeniería en Telecomunicaciones y Electrónica, autorizando a que el mismo sea utilizado por la Institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos, ni publicados sin autorización de la Universidad.. Firma del Autor Los abajo firmantes certificamos que el presente trabajo ha sido realizado según acuerdo de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.. Firma del Autor. Firma del Jefe de Departamento donde se defiende el trabajo. Firma del Responsable de Información Científico-Técnica.

(4) i. TAREA TÉCNICA. 1. La realización de un estudio que permita determinar las herramientas de software a utilizar. 2. Caracterizar las herramientas de simulación y diseño. 3. Crear las clases básicas que permitan desarrollar aplicaciones cliente-servidor para la comunicación Bluetooth. 4. Desarrollar una aplicación de ejemplo que utilice las clases creadas. 5. Crear una aplicación práctica que demuestre el funcionamiento de dichas clases, específicamente un control remoto. 6. Probar el funcionamiento de la aplicación en dispositivos reales.. Firma del Autor. Firma del Tutor.

(5) ii. RESUMEN. En el presente trabajo se hace un estudio del estándar Bluetooth y las tecnologías necesarias para el desarrollo de aplicaciones, además se exponen conceptos básicos de programación orientada a dispositivos con características limitadas y conectividad Bluetooth. Para darle cumplimiento a los objetivos propuestos se desarrolló una aplicación con fines docentes capaz de controlar los periféricos de una computadora a través de un dispositivo móvil utilizando Bluetooth. El trabajo constituye un importante aporte a los contenidos de la asignatura Comunicaciones Móviles, especialmente al enriquecimiento de sus prácticas de laboratorio..

(6) iii. TABLA DE CONTENIDOS. TAREA TÉCNICA ..................................................................................................................i RESUMEN ............................................................................................................................ ii INTRODUCCIÓN .................................................................................................................. 1 Organización del informe ................................................................................................... 3 CAPÍTULO 1.. Bluetooth ................................................................................................... 5. 1.1. Arquitectura Bluetooth ............................................................................................. 5. 1.2. Piconets y Scatternet ................................................................................................ 8. 1.3. Establecimiento de la conexión .............................................................................. 10. 1.3.1. Descubrimiento de Dispositivos y Servicios .................................................. 11. 1.4. Servicios Bluetooth ................................................................................................ 12. 1.5. Perfiles Bluetooth ................................................................................................... 13. CAPÍTULO 2. 2.1. Tecnologías utilizadas ............................................................................. 16. Java Micro Edition (J2ME) .................................................................................... 16. 2.1.1. Configuraciones y perfiles .............................................................................. 16. 2.1.1.1. Configuración CLDC .............................................................................. 18. 2.1.1.2. Perfil MIDP ............................................................................................. 19. 2.1.2. MIDlets ........................................................................................................... 19. 2.1.3. API Java Bluetooth JSR-82 ............................................................................ 21.

(7) iv 2.2. Programación JSR-82............................................................................................. 22. 2.2.1. Administración de dispositivos ....................................................................... 22. 2.2.2. Registro de servicios ....................................................................................... 23. 2.2.3. Descubrimiento Bluetooth .............................................................................. 24. 2.2.3.1. Descubrimiento de dispositivos. .............................................................. 25. 2.2.3.2. Descubrimiento de servicios.................................................................... 27. 2.2.4. 2.2.4.1. Solicitudes de seguridad en la cadena de conexión del Servidor ............ 28. 2.2.4.2. Solicitudes de seguridad en la cadena de conexión del Cliente .............. 30. 2.2.5. 2.3. Seguridad ........................................................................................................ 28. Conexión ......................................................................................................... 30. 2.2.5.1. Servidor SPP ............................................................................................ 31. 2.2.5.2. Cliente SPP .............................................................................................. 32. Infraestructura ........................................................................................................ 32. 2.3.1. Entornos de desarrollo integrado (IDEs) ........................................................ 32. 2.3.2. Simuladores .................................................................................................... 33. 2.3.3. Teléfonos móviles ........................................................................................... 34. CAPÍTULO 3.. Diseño del Control Remoto Bluetooth .................................................... 36. 3.1. Consideraciones generales ..................................................................................... 36. 3.2. Diseño e implementación de la aplicación en el servidor ...................................... 37. 3.2.1. Interfaz del servidor ........................................................................................ 37. 3.2.2. Implementación de la conexión en el servidor ............................................... 38. 3.2.3. Implementación del Robot .............................................................................. 40. 3.3. Diseño e implementación de la aplicación cliente ................................................. 41. 3.3.1. Interfaz del cliente .......................................................................................... 41.

(8) v 3.3.2 3.4. Implementación de la conexión en el cliente .................................................. 43. Simulación, Distribución e Instalación de la aplicación ........................................ 45. CONCLUSIONES Y RECOMENDACIONES ................................................................... 47 Conclusiones ..................................................................................................................... 47 Recomendaciones ............................................................................................................. 48 REFERENCIAS BIBLIOGRÁFICAS ................................................................................. 49 GLOSARIO .......................................................................................................................... 52 ANEXOS .............................................................................................................................. 56 Anexo I:. Estructura del informe ................................................................................. 56. Anexo II:. Lista de Atributos de Servicio conocidos.................................................... 57. Anexo III:. Estructura básica de un MIDlet ................................................................... 58. Anexo IV:. Estructura de un MIDlet Bluetooth ............................................................. 59. Anexo V:. MIDlet Bluetooth para el descubrimiento de Dispositivos y Servicios ...... 60. Anexo VI:. Estructura de un Servidor RFCOMM ......................................................... 64. Anexo VII: Estructura de un Cliente RFCOMM ........................................................... 65.

(9) INTRODUCCIÓN. 1. INTRODUCCIÓN. Hoy en día es innegable el alcance y la aceptación que ha tenido la telefonía móvil; tanto así que ha llegado a convertirse en una necesidad para millones de usuarios en todo el mundo. A medida que esto ha venido ocurriendo las compañías patrocinadoras han percibido que los dispositivos son más atractivos mientras mayores sean las tecnologías de valor añadido que los acompañan. Bluetooth fue una de esas tecnologías que con mayor rapidez se le fue añadiendo a los diferentes dispositivos móviles como una vía más de comunicación inalámbrica, hasta llegar a la actualidad donde la mayoría lo implementan, aunque para aplicaciones de corta distancia. Desde el surgimiento del estándar, varios estudiosos e investigadores se han detenido a abordar el tema en diversos materiales que generalmente parten de su caracterización y que constituyen antecedentes teóricos muy útiles para la presente investigación. De ellos vale destacar “Implementación de una topología de red de dispositivos Bluetooth capaz de acceder a Internet a través de una Red LAN” de los autores Juan Guillermo Torres Hurtado y Álvaro Bernal Noreña y “Comunicación entre dispositivos Bluetooth” de Juan pablo Sevilla Martin y Pablo García Sánchez. En este último es importante señalar el estudio de la especificación JSR-82 donde se abordan temas de gran relevancia como la fase de descubrimiento, administración de dispositivos y comunicación Bluetooth, pero sin detenerse en aspectos clave como la implementación de dichos métodos, vitales para el resultado final de este trabajo. Además de estos autores no se pueden dejar de mencionar a Bruce Hopkins y Ranjith Antony con su texto “Bluetooth for Java”, el cual fue un importantísimo pilar que sustentó la investigación. En el se describe cómo crear aplicaciones Java usando Bluetooth para una variedad de plataformas, incluyendo una vista general de las API de Java, así como el.

(10) INTRODUCCIÓN. 2. desarrollo de aplicaciones Bluetooth basadas en el modelo cliente-servidor y ciertos aspectos de seguridad que resultaron muy valiosos. Pese al gran uso que ha alcanzado Bluetooth entre los usuarios, aún no se explota al máximo su utilidad, la mayoría limita la tecnología al simple intercambio de archivos con otros dispositivos, desaprovechando así todo el potencial que el estándar pudiera ofrecer. El presente trabajo, con un carácter de servicio científico-tecnológico, justamente pretende explotar un poco más dicho estándar con el desarrollo de aplicaciones que permitan una comunicación más interactiva. Para ello, se ha propuesto como objetivo general: . Crear una aplicación que utilice Bluetooth como vía de comunicación entre dispositivos para su aplicación en la asignatura Comunicaciones Móviles que se imparte en la carrera de Ingeniería en Telecomunicaciones y Electrónica.. Y como objetivos específicos: 1. Describir el estándar Bluetooth enfocado al desarrollo de aplicaciones. 2. Estudiar la programación de aplicaciones Bluetooth que utilicen el API JAVA JSR82. 3. Determinar las tecnologías necesarias para la programación de aplicaciones Bluetooth. 4. Desarrollar un control remoto para PC a través de un dispositivo móvil vía Bluetooth. Debido a la ausencia de investigaciones y proyectos en la FIE de la UCLV asociados directamente al estudio de las potencialidades que brinda Bluetooth y las posibles aplicaciones implementadas de este tipo y teniendo en cuenta además, la conveniencia e importancia de este tema, se planteó el siguiente problema científico: ¿Cómo desarrollar aplicaciones Bluetooth, que contribuyan desde el punto de vista académico a una mejor comprensión del estándar? Y como interrogantes científicas: 1. ¿Cómo elaborar una aplicación que utilice el estándar Bluetooth? 2. ¿Qué tipo de aplicación se necesita? 3. ¿Cómo debe funcionar? 4. ¿Qué materiales (Hardware/software) se necesitan para desarrollar la aplicación?.

(11) INTRODUCCIÓN. 3. Con el fin de dar solución al problema e interrogantes científicas planteadas, además de cumplir con los objetivos propuestos se realizaron para la investigación una serie de tareas, como fueron: la realización de un estudio que permitiera determinar las herramientas de software a utilizar, la creación de las clases básicas que permiten desarrollar aplicaciones cliente-servidor para la comunicación Bluetooth y el desarrollo de una aplicación de ejemplo que utiliza las clases creadas, entre otras. Se decidió además utilizar la tecnología Java, tanto el lenguaje de programación como su máquina virtual, ya que esta ofrece dos características que se consideraron fundamentales: estar presente en la mayoría de los dispositivos móviles existentes y ofrecer una implementación libre del estándar Bluetooth. La pertinencia de este estudio se sustenta fundamentalmente en su aplicabilidad. Desde el punto de vista docente se podrían desarrollar aplicaciones que utilicen Bluetooth para comprender mejor el funcionamiento del estándar. El control remoto posibilita desarrollar aplicaciones que no solo controlen una PC sino también otros dispositivos como un televisor, por citar un ejemplo. Además, con el debido uso de estas tecnologías se podrían implementar redes TCP/IP que funcionen sobre Bluetooth, sin dejar de mencionar las disímiles aplicaciones como salas de chat y juegos interactivos que pudiesen desdoblarse utilizando el estándar. La investigación resulta también de gran significación en tanto puede contribuir al desarrollo de prácticas de laboratorio en la asignatura de Comunicaciones Móviles; así como la realización de una guía para el futuro desarrollo de aplicaciones de este tipo. Igualmente constituye una base sobre la cual sentar futuras investigaciones que amplíen interrogantes científicas en el campo de las comunicaciones inalámbricas y la telefonía móvil. Organización del informe CAPITULO I: Se dedicará a la caracterización del estándar Bluetooth orientado a la programación de aplicaciones. CAPITULO II: Hará referencia a las tecnologías necesarias para programar aplicaciones Bluetooth y cómo se programa el estándar..

(12) INTRODUCCIÓN. 4. CAPITULO III: Se dedica al software diseñado, a la descripción de su funcionamiento y al análisis de los resultados obtenidos después de haber sido probado. En el Anexo I:. Estructura del informe se presenta una tabla donde se muestran los. capítulos con sus epígrafes y sub-epígrafes y la correspondencia que posee cada capítulo con los objetivos propuestos..

(13) CAPÍTULO 1. Bluetooth. 5. CAPÍTULO 1. Bluetooth. En este capítulo se pretende ofrecer una breve introducción a la tecnología Bluetooth. Explicar los aspectos fundamentales de su arquitectura y describir cómo se llevan a cabo los procesos de descubrimiento y selección. También se hará referencia a algunos detalles importantes sobre la publicación de servicios y los perfiles Bluetooth. De manera tal que cuando el lector haya leído el capítulo, posea suficiente conocimiento de la tecnología como para poder comprender cómo se programa. 1.1 Arquitectura Bluetooth Bluetooth es una tecnología de radio de corto alcance (10 metros aproximadamente) que permite la conectividad inalámbrica entre dispositivos. Se diseñó pensando básicamente en tres objetivos: pequeño tamaño, mínimo consumo y bajo precio. Además debía funcionar a nivel global, por lo que utiliza la banda de frecuencia no licenciada ISM (Industrial, Scientific and Medical). Es ideal para periféricos de ordenador o dispositivos limitados por el consumo de potencia como PDAs, teléfonos móviles, Pocket PCs, etc. Al ser un protocolo de comunicación inalámbrica puede ser utilizado para comunicar dos o más dispositivos homólogos. Posee una arquitectura de tipo cliente-servidor donde generalmente el dispositivo que inicia la conexión (el cliente) actúa como maestro y el que la recibe (el servidor) funciona como esclavo [1]. La principal ventaja de Bluetooth es la habilidad de manejar trasmisión de voz y datos simultáneamente, con capacidad de soportar un canal de datos asíncrono y hasta tres canales de voz síncronos. Esta habilidad combinada con conexiones de tipo Ad Hoc, unida a una aplicación capaz de detectar los servicios que prestan los diferentes dispositivos de la.

(14) CAPÍTULO 1. Bluetooth. 6. red, la convierte en una excelente solución de comunicación para dispositivos móviles y aplicaciones de Internet [2] La especificación Bluetooth define un canal de comunicaciones con una velocidad máxima de transmisión de datos de 1 Mbps [3] con un alcance máximo en función de la potencia de transmisión. La mayoría de los dispositivos transmiten con una potencia nominal de salida de 0 dBm que les permite cubrir una distancia de aproximadamente 10 metros. La frecuencia de trabajo se encuentra en el rango de 2.4 a 2.48 GHz utilizando un sistema FH/TDD (salto de frecuencia/división de tiempo dúplex) con un máximo de 1600 saltos por segundos. Estos saltos se dan entre un total de 79 frecuencias con intervalos de 1 MHz. El canal queda divido entonces en intervalos de 625 µs, llamados slots, donde cada salto de frecuencia es ocupado por un slot. Sin embargo, las especificaciones de radio no son suficientes para lograr establecer una conexión exitosa entre dos dispositivos, el estándar Bluetooth está constituido por una serie de protocolos que proveen las funciones de descubrimiento, exploración de servicios y la forma de consumir estos servicios. Así como también el establecimiento de la conexión y la posterior comunicación. El Centro de Control Bluetooth (BCC), mostrado en la figura 1.1 puede ser dividido en dos: el Host Bluetooth y el Controlador Bluetooth (este último constituye el módulo de radio). El HCI (Host Controller Interface) ofrece un método de interfaz para acceder a los recursos de hardware de Bluetooth. Como es la capa que separa al hardware del software, todas las capas por encima del HCI son implementadas a nivel de software mientras que las capas que quedan por debajo son implementadas a nivel de hardware, sin embargo, cabe mencionar que existen dispositivos en los que las capas inferiores son implementadas a nivel de hardware/firmware..

(15) CAPÍTULO 1. Bluetooth. Figura 1.1. Centro de Control Bluetooth. Tomado de: Bluetooth for Java de Bruce Hopkins y Ranjith Antony. 7. [1]. Como no es necesario para el desarrollo de aplicaciones el conocimiento a fondo de todos los protocolos que conforman el estándar Bluetooth, se hará una breve descripción de aquellos que se consideraron más importantes para la investigación (resaltados en negrita en la figura 1.1). No obstante, se puede encontrar información adicional acerca de las capas que conforman el conjunto de protocolos en Bluetooth for Java de Hopkins y Antony [1] y en el sitio web de la especificación [4]. La capa de comunicación más baja del conjunto de protocolos es llamada Banda Base. Esta capa implementa el canal físico real y su característica fundamental es el salto de frecuencias. Controla la sincronización de las unidades Bluetooth y la secuencia de los saltos, además es la responsable del control del enlace a bajo nivel: como el reconocimiento, control de flujo y caracterización de la carga útil [3]..

(16) CAPÍTULO 1. Bluetooth. 8. El Protocolo de Gestión de Enlace (LMP) es el responsable de la autenticación, cifrado, control y configuración del enlace y administra aspectos de seguridad como encriptación y autenticación. El Protocolo de Control y Adaptación de Enlace Lógico (L2CAP) corresponde a la capa de enlace de datos. Esta capa brinda servicios de datos a las capas superiores. Multiplexa los protocolos de capas superiores con el fin de enviar varios protocolos sobre un canal banda base. Segmenta en el transmisor los paquetes de capas superiores que son más grandes que el tamaño máximo del paquete banda base. Maneja además información relativa a la calidad de la conexión y administra grupos, de tal manera, que varios dispositivos pueden comunicarse entre sí. El protocolo RFCOMM ofrece la emulación de puertos seriales sobre el protocolo L2CAP. RFCOMM emula señales de control y datos RS-232 sobre la banda base de Bluetooth. Además, ofrece capacidades de transporte a servicios de capas superiores que usan una interfaz serial como mecanismo de transporte. El Protocolo de Descubrimiento de Servicio (SDP) define cómo actúa una aplicación de un cliente Bluetooth para descubrir servicios disponibles de servidores Bluetooth, además de proporcionar un método para determinar las características de dichos servicios [3]. El Protocolo de Intercambio de Objetos (OBEX) es un protocolo opcional de nivel de aplicación que usa RFCOMM como principal capa de transporte. Fue adoptado para permitir a las unidades Bluetooth emular la comunicación infrarroja (al igual que emula la comunicación serie) para intercambiar una gran variedad de datos y comandos. Este usa un modelo cliente-servidor y es independiente del mecanismo de transporte. Todos los dispositivos Bluetooth poseen una dirección única, que consiste en un identificador de 48 bits similar a la dirección MAC (Media Acces Control) usada por las tarjetas de interfaz de red (NIC). La dirección Bluetooth no solo se usa como identificación, sino también para sincronizar los saltos de frecuencia entre los dispositivos [5]. 1.2 Piconets y Scatternet Si un equipo se encuentra dentro del radio de cobertura de otro, estos pueden establecer conexión entre ellos. Como se ha citado anteriormente cada dispositivo tiene una dirección.

(17) CAPÍTULO 1. Bluetooth. 9. única de 48 bits, basada en el estándar IEEE 802.11 para WLAN. En principio, solo son necesarias un par de unidades con las mismas características de hardware para establecer un enlace. Dos o más dispositivos Bluetooth que comparten el mismo canal de comunicación conforman una piconet. Esta se establece a través de enlaces punto multipunto, donde uno de los dispositivos cumple el rol de maestro mientras los demás actúan como esclavos [6]. Una piconet puede tener un máximo de siete esclavos activos. Si un equipo se encuentra dentro del radio de cobertura de otro, estos pueden establecer conexión entre ellos. Sin embargo, solo aquellas unidades que realmente quieran intercambiar información comparten un mismo canal creando la piconet como se muestra en la figura 1.2.. Figura 1.2. Conformación de una Scatternet. Tomado de: Developing Applications with the Java APIs for Bluetooth™ (JSR-82) de Sony [7]. Los equipos que comparten un mismo canal solo pueden utilizar una parte de su capacidad. Aunque los canales tienen un ancho de banda de 1 Mbps, por cada nuevo usuario que se incorpore a la piconet, disminuye la capacidad aproximadamente en un 10%. Para poder enfrentar este problema se adoptó una solución de la que nace el concepto de scatternet. A un grupo de piconets se le llama scatternet. El rendimiento de una scatternet es mayor que el que tiene un grupo de usuarios de una piconet cuando participan en un.

(18) CAPÍTULO 1. Bluetooth. 10. mismo canal de 1 Mbps. Además, estadísticamente se obtienen ganancias por multiplexación y rechazo de canales de salto. Debido a que individualmente cada piconet tiene un salto de frecuencia diferente, disímiles piconets pueden usar simultáneamente distintos canales de salto [8]. 1.3 Establecimiento de la conexión Cuando dos dispositivos coinciden dentro del alcance de sus radios, cada uno comienza a inspeccionar el medio para descubrir si otro dispositivo se encuentra a su alcance, qué servicios ofrece y cuál es su dirección física. La conexión entre dispositivos Bluetooth se establece a través de un mensaje PAGING, no obstante antes que se produzca alguna conexión, se dice que todos los dispositivos están en estado STANDBY. Si la dirección es desconocida, antes del mensaje PAGING se necesitará un mensaje INQUIRY como se muestra en la figura 1.3.. Figura 1.3. Estados Bluetooth. Tomado de: Java 2 Micro Edition: Soporte Bluetooth de Pedro Daniel Borches. [3]. Un dispositivo en estado STANDBY se despierta cada 1.28 segundos para escuchar posibles mensajes PAGING/INQUIRY. Cada vez que un dispositivo se despierta, escucha en una de las 32 frecuencias de salto definidas. Un mensaje de tipo PAGING, será enviado en 32 frecuencias diferentes. Primero el mensaje es enviado en las primeras 16 frecuencias (128 veces), y si no se recibe respuesta, el maestro mandará el mensaje PAGING en las 16 frecuencias restantes (128 veces). El tiempo máximo de intento de conexión es de 2.56 segundos [2]..

(19) CAPÍTULO 1. Bluetooth. 11. En el estado CONNECTION o conectado, es donde realmente se transfieren los datos de un dispositivo a otro y una vez terminada la transferencia, se puede retornar al estado de STANDBY (véase figura 1.3), o bien quedar en alguno de los estados especiales de bajo consumo de energía siguientes: . SNIFF: en este estado, el tiempo de actividad durante el cual el dispositivo esclavo escucha se reduce. Esto significa que el maestro sólo puede iniciar una transmisión en unos slots de tiempo determinados.. . HOLD: en el estado conectado, el enlace con el esclavo puede ponerse en espera. Durante este modo, el esclavo puede hacer otras cosas, como escanear en busca de otros dispositivos y atender otra piconet.. . PARK: en este estado, el esclavo no necesita participar en la piconet, por lo que deja de ser miembro de esta, pero aún necesita seguir sincronizado con el canal. Lo cual resulta de gran utilidad por si hay más de siete dispositivos que necesitan participar ocasionalmente en la piconet. 1.3.1. Descubrimiento de Dispositivos y Servicios. Como se ha citado anteriormente, la especificación Bluetooth define el descubrimiento de dispositivos como un estado denominado INQUIRY. Los dispositivos deben hacerse visibles para poder pasar a este estado. Una vez que se está en este modo, cada dispositivo pasa más tiempo en cada canal, es decir, los saltos de frecuencia se generan más lentamente, por lo que se incrementa la probabilidad de que un dispositivo pueda escuchar mensajes INQUIRY de otros dispositivos. En este estado se usa además un código de acceso denominado IAC (Inquiry Access Code). Existen dos tipos de IACs el GIAC (General Inquiry Access Code) y el LIAC (Limited Inquiry Access Code). El modo GIAC es usado cuando un dispositivo es visible por un período indefinido de tiempo, mientras el modo LIAC es usado cuando el dispositivo es visible por un período de tiempo limitado. Como diferentes dispositivos Bluetooth ofrecen diferentes tipos de servicios, un dispositivo Bluetooth necesita descubrir servicios de otros dispositivos remotos para poder obtener información de los servicios disponibles en cada uno. El proceso de búsqueda de servicios utiliza el protocolo SDP para descubrir los servicios disponibles. Un cliente SDP realiza una petición al servidor que este devuelve con una lista de servicios disponibles y cierta.

(20) CAPÍTULO 1. Bluetooth. 12. información asociada a cada uno denominada atributos del servicio. La búsqueda de servicios normalmente devuelve todos los servicios asociados a un dispositivo, aunque es muy común que la búsqueda se realice para buscar un servicio específico, al cual se desea conectar y desechar los demás. 1.4 Servicios Bluetooth Los dispositivos Bluetooth mantienen la información referente a sus servicios almacenada en una base de datos denominada SDDB (Service Discovery Data Base) como se muestra en la Figura 1.4.. Figura 1.4. Base de Datos de Descubrimiento de Servicios. Tomado de: J2ME Bluetooth Programming de André N. Klingsheim [5]. Los dispositivos remotos devuelven tanto los servicios almacenados en su SDDB como toda la información necesaria para describir dichos servicios durante el proceso de descubrimiento de servicios. En la figura 1.4 se puede apreciar que un servicio puede tener asociado varios atributos, sin embargo para que el servicio sea almacenado en la SDDB son indispensables dos atributos el ServiceRecordHandle (attribute ID 0x0000) y el ServiceClassIDList (attribute ID 0x0001). Pueden existir numerosos atributos adicionales para describir un servicio en particular y brindar así mayor información acerca de este. Diferentes atributos contienen datos de diferente tipo y valor como muestra el Anexo II: Lista de Atributos de Servicio conocidos. Como consecuencia de esto se utiliza una estructura de datos denominada elemento de dato (Data Element) para almacenar los valores. Un elemento de dato está formado por un encabezado y un campo de dato como se muestra en la figura 1.5. El encabezado contiene información acerca del tipo y el tamaño del dato, mientras que el campo de datos contiene la información que será enviada. Por consiguiente, el dispositivo remoto necesita conocer el tipo y la cantidad de datos que debe recibir a la hora de obtener los atributos de servicio de otro dispositivo..

(21) CAPÍTULO 1. Bluetooth. Figura 1.5. Estructura del Elemento de Dato. Tomado de: J2ME Bluetooth Programming de André. 13. Klingsheim [5]. 1.5 Perfiles Bluetooth Antes de comenzar a hacer referencia a los perfiles Bluetooth es necesario preguntarse cuáles son los escenarios donde pueden tener lugar las aplicaciones Bluetooth. Es decir, la tecnología Bluetooth además de ofrecer la posibilidad de reemplazar los cables que se usan para la transmisión de datos entre los distintos dispositivos digitales como PCs, impresoras, teléfonos móviles, PDAs, FAX entre otros, brinda también la capacidad de crear redes entre personas que tienen sus propios equipos habilitados para Bluetooth. De esta manera se definen algunos modelos de uso común entre los cuales se pueden mencionar: . PC sin Cables: es el escenario que mejor describe la concepción de Bluetooth como una tecnología para reemplazar cables que transportan datos. En este caso, los periféricos, tales como el ratón, teclado, impresoras, dispositivos de juegos, parlantes, escáneres, etc. podrían tener un alto grado de libertad al no estar conectados por cables y en cambio hacer uso de enlaces de radio con el PC.. . Manos Libres o Headsets: son dispositivos que se usan para permitirle a una persona mantener una conversación telefónica sin tener que sostener el equipo telefónico en sus manos, usualmente estos dispositivos también están sujetos a cables, restringiendo la movilidad del usuario; este también es un escenario que contempla Bluetooth, dado que soporta explícitamente aplicaciones de voz [3].. . Puente a internet: existen dos métodos para el uso de Bluetooth como un puente inalámbrico para establecer comunicación con LANs o Internet: marcación telefónica donde se suprime la presencia del cable entre el módem y el PC, y acceso directo a la red por medio de un punto de acceso Bluetooth.. Los perfiles definen las características que debe soportar el conjunto de protocolos Bluetooth para poder realizar una función específica [1]. Son definidos como parte de la.

(22) CAPÍTULO 1. Bluetooth. 14. especificación Bluetooth y tienen como fin principal describir como se ejecutan las aplicaciones de los modelos de uso y hacer que estas puedan enmarcarse dentro de dichos perfiles y de esta forma, disminuir considerablemente el riesgo de problemas de interoperabilidad entre productos y aplicaciones de diferentes fabricantes.. Figura 1.6. Interdependencia de los perfiles Bluetooth. Tomado de: Bluetooth for Java de Bruce Hopkins y Ranjith Antony [1]. La figura 1.6 muestra la interdependencia de los perfiles Bluetooth, un perfil es dependiente de otro perfil si reutiliza partes de ese perfil, referenciándolos implícitamente o explícitamente [7]. A continuación se hará una breve descripción de los perfiles que fueron tratados durante la investigación (señalados en negrita en la Figura 1.6). Se podrá encontrar información adicional acerca de los perfiles Bluetooth en Bluetooth Programming de.

(23) CAPÍTULO 1. Bluetooth. 15. Klingsheim [5] y en Developing Applications with the Java APIs for Bluetooth™ (JSR-82) de Sony [7]. . Generic Access Profile (GAP): Este perfil define el uso de las capas inferiores del conjunto de protocolos incluyendo la administración de dispositivos remotos y es obligatoria su utilización en todas las implementaciones de Bluetooth.. . Service Discovery Application Profile (SDAP): Describe las especificaciones de cómo las aplicaciones deben usar el SDP, el protocolo L2CAP y las capas inferiores para el descubrimiento de servicios.. . Serial Port Profile (SPP): Define los requerimientos de interoperabilidad entre los protocolos RFCOMM, L2CAP, SDP y las capas inferiores para la emulación de puerto serie..

(24) CAPÍTULO 2. Tecnologías utilizadas. 16. CAPÍTULO 2. Tecnologías utilizadas. En el presente capítulo el lector podrá conocer qué se necesita para la programación de la tecnología Bluetooth, así como los pasos fundamentales para desarrollar una aplicación de tipo cliente - servidor. Se describen las características fundamentales de Java Micro Edition haciendo énfasis en las configuraciones y los perfiles, la creación de Midlets, su relación con el API JSR-82 y su implementación. En secciones posteriores se hace referencia a cómo desarrollar Midlets que implementen JSR-82, así como la infraestructura necesaria para crear, simular e instalar aplicaciones de este tipo. 2.1 Java Micro Edition (J2ME) Java Platform, Micro Edition o Java ME, también conocido como Java 2 Platform, Micro Edition o J2ME, es una colección de APIs (Application Programming Interface) para el desarrollo de software para dispositivos con pocos recursos, como PDAs, teléfonos móviles y similares. Es formalmente una especificación desarrollada bajo el Java Comunity Process como JSR-68 (Java Specification Request - 68), aunque es muy común utilizar el término para referirse a las implementaciones de esta especificación. 2.1.1. Configuraciones y perfiles. J2ME introduce dos conceptos: las configuraciones y los perfiles. Las configuraciones proporcionan la funcionalidad básica para un conjunto de dispositivos que comparten características similares. Estas forman el set de APIs (Application Programming Interface) de bajo nivel, que definen las características de ejecución de un ambiente particular J2ME. Son responsables de definir las clases del núcleo Java, las características del lenguaje de programación y las características de la máquina virtual; mientras que los perfiles identifican un grupo de dispositivos por la funcionalidad que proporcionan y el tipo de.

(25) CAPÍTULO 2. Tecnologías utilizadas. 17. aplicaciones que se ejecutaran en ellos. Se ocupan además, de funciones más específicas como la interfaz de usuario, los mecanismos de almacenamiento de datos y el uso de puertos de entrada/salida para el intercambio de información entre dispositivos [9]. Las configuraciones y los perfiles proveen una separación en la arquitectura J2ME (véase la figura 2.1) condicionada, tanto por la necesidad de portabilidad como por la necesidad de dar soporte a una gran variedad de dispositivos. Las configuraciones prestan servicio para aumentar la portabilidad de muchos dispositivos diferentes, mientras que los perfiles atienden las características de un dispositivo específico o un grupo de dispositivos similares.. Figura 2.1. Configuraciones y Perfiles de la especificación J2ME. Tomado de: J2ME in a Nutshell de Kim Topley [10]. En la figura 2.1 se muestran las configuraciones y los perfiles que componen la especificación J2ME. Como se puede apreciar existen dos configuraciones: la configuración CLDC (Connected Limited Device Configuration) a la cual se asocian dos perfiles: el perfil MIDP (Mobile Information Device Profile) y el perfil PDA y la configuración CDC que trae asociados el resto de los perfiles de la especificación..

(26) CAPÍTULO 2. Tecnologías utilizadas. 18. En epígrafes posteriores serán tratados la configuración CLDC y el perfil MIDP por la importancia que poseen para la investigación. No obstante, el lector podrá encontrar información complementaria de las configuraciones y los perfiles J2ME en “MIDP Style Guide for the Java™ 2 Platform, Micro Edition” de Bloch y Wagner [11] y en “Java 2 Microedition. Java in Small Thing” de White y Hemphill [9]. 2.1.1.1 Configuración CLDC La configuración CLDC ha sido diseñada para dispositivos con procesadores lentos, memoria limitada y conexiones de red intermitente. Está orientada a dispositivos que, como recursos mínimos, posean un procesador de 16 bit a 16 MHz, entre 160 y 512 Kb de memoria no volátil disponible para la plataforma Java, alimentación limitada, normalmente basada en batería y conectividad intermitente a algún tipo de red [12].. Figura 2.2. Posición de la configuración CLDC dentro de la plataforma J2ME. Tomado de: J2ME Bluetooth Programming de André N. Klingsheim [5]. La figura 2.2 muestra cómo la configuración CLDC ha sido creada para ser la base de uno o más perfiles, definiendo un subconjunto de funcionalidades mínimas de la plataforma J2ME. CLDC no define en ningún momento las funcionalidades específicas de un dispositivo, pero sí las librerías básicas y las funcionalidades disponibles de la máquina virtual. Normalmente no se desarrollan programas basados en los paquetes provistos por la configuración CLDC solamente, que ofrecen sólo la funcionabilidad básica de J2SE (Java Plataform Estándar Edition). Descargar un programa de Java basado solo en CLDC para un teléfono móvil es realmente imposible, ya que estos dispositivos dan soporte a las aplicaciones basadas en el perfil MIDP; por lo cual el desarrollo de una aplicación implica la combinación de MIDP y CLDC [5]..

(27) CAPÍTULO 2. Tecnologías utilizadas. 19. 2.1.1.2 Perfil MIDP El perfil MIDP es un set de APIs que reside encima del CLDC como se muestra en la figura 2.3, proporcionando características como la interfaz de usuario, soporte de red y almacenamiento persistente. Existen dos versiones de MIDP, MIDP 1.0 y MIDP 2.0.. Figura 2.3. Posición del perfil MIDP dentro de la plataforma J2ME. Tomado de: J2ME Bluetooth Programming de André N. Klingsheim [5]. El perfil MIDP combinado con CLDC provee una plataforma más enfocada a los dispositivos móviles, como teléfonos móviles y PDAs. Además, proporciona la integración vertical requerida para hacer el ambiente Java runtime aplicable a estos dispositivos. Actualmente es soportado por muchos entornos de desarrollo integrados (IDE) y se ha convertido en una plataforma ampliamente aceptada, que ha sido implementada en innumerables dispositivos móviles alrededor del mundo. Está diseñado para dispositivos con las siguientes características mínimas1: . Pantalla: 96x54.. . Profundidad de bits: 1 bit.. . Memoria: 128 Kb de memoria no volátil para los componentes MIDP, 8 Kb de memoria no volátil para datos persistentes y 32 Kb de memoria volátil para la pila de Java. 2.1.2. MIDlets. Los MIDlets son aplicaciones construidas usando el perfil MIDP. Un MIDlet pasa por 3 estados de ejecución: activo, pausado y destruido como se muestra en la figura 2.4. Estos. 1. Note que además de cumplir con las características mínimas necesarias para usar MIDP, hay que cumplir con las características mínimas necesarias para usar CLDC..

(28) CAPÍTULO 2. Tecnologías utilizadas. 20. estados son controlados por un gestor de aplicaciones llamado AMS (Application Management Software).. Figura 2.4. Transición de estados del ciclo de vida de un MIDlet. Tomado de: Programming Java 2 Micro Edition on Symbian OS de Martin de Jode [13]. La interfaz gráfica de un MIDlet se estructura en base a pantallas, donde cada pantalla contiene tareas posibles a ejecutar. Para acceder a las funcionalidades de la aplicación hay que navegar a través de las distintas pantallas, ya que en un determinado momento solo puede mostrarse una única pantalla en el LCD (Liquid Crystal Display) del dispositivo. Para la distribución son necesarios dos archivos: un archivo JAR (Java ARchive) conteniendo el bytecode (o conjunto de clases compiladas) del programa y un archivo JAD (Java Application Descriptor) que describe los contenidos del archivo JAR. Un MIDlet tiene que cumplir los siguientes requisitos para poder funcionar en un dispositivo móvil: . La clase principal necesita ser una subclase de javax.microedition.midlet.MIDlet.. . El MIDlet necesita ser empaquetado dentro de un archivo JAR.. . El archivo JAR necesita ser preverificado usando un preverificador.. Se puede encontrar información adicional sobre la distribución de MIDlets y los archivos JAD y JAR en J2ME Bluetooth Programing de Klingsheim [5]..

(29) CAPÍTULO 2. Tecnologías utilizadas. 2.1.3. 21. API Java Bluetooth JSR-82. El API Java Bluetooth JSR-82 es el resultado de una investigación realizada por el grupo JSR-82, en la cual se define un paquete de desarrollo para la tecnología inalámbrica Bluetooth basado en J2ME. El objetivo de esta especificación es definir la arquitectura y las funciones asociadas para permitir un entorno de desarrollo abierto para nuevas aplicaciones que empleen la tecnología Bluetooth como medio de comunicación. El enfoque principal son los dispositivos con capacidad de procesamiento limitada, poca memoria y que operan con batería, aunque no existe ningún tipo de problema en utilizar una implementación de JSR-82 en ambientes de escritorio.. Figura 2.5. Posición que ocupa JSR-82 dentro de la plataforma J2ME. Tomado de: J2ME Bluetooth Programing de André N. Klingsheim [5]. La figura 2.5 muestra cómo se inserta JSR-82 dentro de la arquitectura J2ME. Como se puede observar las aplicaciones nativas Bluetooth no hacen uso de JSR-82, sino que manejan directamente el conjunto de protocolos Bluetooth del sistema operativo; por lo que el uso de aplicaciones nativas puede disminuir en gran medida la portabilidad de la aplicación, que sí es garantizada por JSR-82. Debido a que la especificación Bluetooth cubre muchas capas y perfiles, se decidió proporcionar solo el soporte para los protocolos y los perfiles básicos, en lugar de introducir nuevos elementos al API para cada perfil de Bluetooth. El API Java Bluetooth JSR-82 se enmarca finalmente dentro de las siguientes áreas: I.. Tipo de Transmisión: a. Transmisión de datos, no de voz..

(30) CAPÍTULO 2. Tecnologías utilizadas. II.. 22. Protocolos: a. L2CAP. b. SDP. c. RFCOMM. d. OBEX.. III.. Perfiles: a. Perfil de acceso Genérico (GAP). b. Perfil de puerto serie (SPP). c. Perfil de intercambio de objetos (OBEX).. IV.. Proveer las siguientes funciones: a. Descubrimiento de dispositivos y servicios. b. Administración de dispositivos. c. Establecimiento de conexiones RFCOMM, L2CAP y OBEX. d. Realizar todas las funciones de forma segura.. En acápites posteriores se le dará un tratamiento especial a la funcionalidad que ofrece JSR82, al ser considerado una parte fundamental de la investigación. 2.2 Programación JSR-82 La implementación de esta API ofrece una serie de funciones y métodos para proporcionar el control del conjunto de protocolos Bluetooth y así poder desarrollar tareas más complejas como la administración de dispositivos, el descubrimiento de dispositivos y servicios y el establecimiento de la conexión. Además, adiciona cierto grado de seguridad a la ejecución de cada tarea y queda a elección del programador su uso o no. En esta sección se pretende describir las funcionalidades básicas del API Java JSR-82 que permiten el desarrollo de aplicaciones Bluetooth, ya sea para dispositivos móviles o para computadoras personales. 2.2.1. Administración de dispositivos. Las clases javax.bluetooth.localDevice (localDevice) y javax.bluetooth.remoteDevice (remoteDevice) representan los objetos esenciales de Bluetooth, proporcionando características para la administración de dispositivos que forman parte del perfil de acceso genérico. Los métodos que proporcionan el control del dispositivo se encuentran en la clase.

(31) CAPÍTULO 2. Tecnologías utilizadas. 23. localDevice, mientras que las funciones necesarias para obtener información sobre dispositivos remotos se encuentran contenidas en la clase remoteDevice. Además, existen dos clases que dan soporte a la clase localDevice: la clase DeviceClass y la clase BluetoothStateEception. La primera, proporciona los métodos para recuperar los valores que describen las propiedades de un dispositivo y la segunda, sirve como notificador de errores para la aplicación. 2.2.2. Registro de servicios. Desde la perspectiva general de la especificación Bluetooth el registro de servicio es un proceso que comprende lo siguiente: . Crear un registro de servicio que describa el servicio ofrecido por la aplicación.. . Añadir el registro de servicio creado a la SDDB.. . Registrar las medidas de seguridad asociadas al servicio creado.. . Aceptar conexiones desde clientes que soliciten el servicio ofrecido.. . Actualizar el registro de servicio en la SDDB si las características del servidor cambian.. . Eliminar el registro de servicio de las SDDB cuando el servicio no esté disponible.. De acuerdo a la implementación del JSR-82 al que se hace referencia en este capítulo, el registro de servicio es un esfuerzo colaborativo entre tres entidades: la aplicación servidora, la implementación del API y la pila Bluetooth, como se muestra en la Figura 2.6. En la figura 2.6 se puede apreciar que cuando la aplicación del servidor llama al método Open() con una cadena de conexión URL como argumento, la implementación crea un nuevo serviceRecord. Cada vez que el servidor llama al método acceptAndOpen() un registro de servicio nuevo es añadido a la SDDB por la implementación. Además, la aplicación servidora puede obtener su propio registro de servicio a través del método getRecord() y puede modificarlo invocando al método updateRecord() que incide directamente sobre la SDDB. Finalmente, la aplicación puede retirar el servicio haciendo una petición de close() al notifier (notificador) y este a su vez borra el registro de servicio de la SDDB..

(32) CAPÍTULO 2. Tecnologías utilizadas. 24. Figura 2.6. Colaboración entre la aplicación servidora, la implementación del API y la pila Bluetooth para el registro de servicios. Tomado de: Comunicación entre dispositivos Bluetooth de Sevilla Martín, Juan Pablo [12]. En Bluetooth for Java de Hopkins y Antony [1] se describen cada uno de los métodos mencionados anteriormente, se explica de forma muy completa el proceso de registro de servicio y se ofrecen varios ejemplos que el lector podrá utilizar en caso de necesitar mayor información acerca del tema. 2.2.3. Descubrimiento Bluetooth. Como se ha mencionado anteriormente los dispositivos Bluetooth, de acuerdo a su naturaleza móvil, necesitan una forma de encontrar otros dispositivos y una manera de aprender a interactuar con ellos. El API Java JSR-82 proporciona los métodos para el.

(33) CAPÍTULO 2. Tecnologías utilizadas. 25. descubrimiento de dispositivos y servicios y la publicación de estos últimos, los cuales serán tratados a continuación. 2.2.3.1 Descubrimiento de dispositivos. Existen dos funciones a partir de las cuales una aplicación puede obtener una lista de dispositivos StartInquiry() o RetrieveDevices(). La primera necesita que la aplicación implemente un listener (escuchador), el cual será avisado cada vez que se encuentre un nuevo dispositivo en el proceso de búsqueda. Si no es necesario realizar una búsqueda para obtener la lista de dispositivos, el API incluye la segunda función (método RetrieveDevices()) que devuelve la lista de dispositivos encontrados en búsquedas anteriores o los dispositivos que hayan sido clasificados como preconocidos2. Por tanto, este método no realiza una exploración para detectar dispositivos, pero proporciona una manera rápida de obtener una lista de dispositivos que pudieran estar en el área. El uso de esta función exige sumo cuidado, en ocasiones serán devueltos dispositivos que no se encuentran en el área de cobertura. Además de los métodos mencionados existen dos clases especialmente diseñadas para el descubrimiento de dispositivos en el JSR-82: la interfaz javax.bluetooth.DiscoveryListener y la clase javax.bluetooth.DiscoveryAgent [14]. La interfaz debe ser implementada por el programador y permite a la aplicación poseer un listener que responderá a eventos relacionados con la búsqueda de dispositivos. Los métodos de la interfaz son mostrados en el Anexo IV:. Estructura. de. un. MIDlet. Bluetooth, donde se puede observar que el método deviceDiscovered() se llama cada vez que se descubre un dispositivo durante una investigación, mientras que el método inquiryCompleted() es llamado al finalizar la búsqueda o al detener la misma y este recibe la causa de dicha finalización a partir de los valores INQUIRY_COMPLETED, INQUIRY_ERROR o INQUIRY_TERMINATED [15]. La clase javax.bluetooth.DiscoveryAgent proporciona los métodos para el descubrimiento, ya sea de dispositivos o de servicios. Las funciones startInquiry() y RetrieveDevices() que. 2. Los dispositivos preconocidos son aquellos que están definidos en el BCC como dispositivos con los que el dispositivo local contacta frecuentemente..

(34) CAPÍTULO 2. Tecnologías utilizadas. 26. han sido tratadas anteriormente pertenecen a dicha clase. Es importante señalar que, además de las funciones mencionadas, esta clase proporciona un método para detener la búsqueda llamado cancelInuiry() [1].. Figura 2.7. Diagrama de estados del descubrimiento de dispositivos. Tomado de: Java Programming Techniques for Games de Andrew Davison [16]. La figura 2.7 muestra cómo se desarrolla el proceso de descubrimiento de dispositivos a partir de su diagrama de estado. Primeramente se inicia la aplicación y posteriormente se pasa al estado de inicialización de la clase DiscoveryAgent. Luego se transita por los estados más importantes del proceso: inicio, descubrimiento y finalización de la búsqueda. Mientras se sigan descubriendo dispositivos, la aplicación se mantiene en el estado de “dispositivo descubierto”. Una vez terminada la exploración, la aplicación llama al método inquiryComplete() implementado por la interfaz DiscoveryListener y se pasa a un segundo estado, definido por la aplicación que normalmente es el descubrimiento de servicios y será tratado en secciones posteriores..

(35) CAPÍTULO 2. Tecnologías utilizadas. 27. 2.2.3.2 Descubrimiento de servicios Las clases definidas para el descubrimiento de servicios son la clase javax.bluetooth.UUID, la clase javax.bluetooth.DataElement y la interfaz javax.bluetooth.ServiceRecord. También intervienen en el descubrimiento de servicios la clase javax.bluetooth.DiscoveryAgent y la interfaz javax.bluetooth.DiscoveryListener utilizando un procedimiento similar al descrito para el descubrimiento de dispositivos. El método servicesDiscovered() es llamado cada vez que se descubre un servicio, mientras que el método serviceSearchCompleted() es llamado al finalizar la búsqueda de servicios o al cancelar la misma y al igual que en la búsqueda de dispositivos este método recibe porqué se finaliza la búsqueda. La clase javax.bluetooth.UUID se utiliza para representar un identificador único y universal que es utilizado como valor para un atributo de servicio. Puede encapsular valores de 16, 32 o 128 bits y solo los atributos representados por UUIDs pueden ser buscados por el SDP Bluetooth. La clase javax.bluetooth.DataElement está diseñada para contener los tipos de datos que un atributo de servicio puede tomar, ya sean enteros, con o sin signo entre 1 y 128 bits, cadenas, bolean, UUID o secuencias de cada uno de ellos, en dependencia del grado de descripción que se le pretenda dar a un servicio en particular. La interfaz javax.bluetooth.ServiceRecord define un par ID, value donde ID es un entero sin signo de 16 bits y value es un elemento de dato autodescriptivo de uno de los tipos de datos mencionados anteriormente. La figura 2.8 muestra que el proceso de descubrimiento de servicios es un poco más complejo que el descubrimiento de dispositivos. El descubrimiento de servicios se inicia cuando se termina el descubrimiento de dispositivos. El ciclo comienza por el primer dispositivo descubierto cuando la aplicación invoca al método searchService(), mientras se sigan encontrando servicios en un dispositivo la aplicación se mantendrá en el estado de “servicio descubierto”. Una vez descubiertos todos los servicios en el dispositivo actual, se pasa a explorar el siguiente dispositivo y así consecutivamente hasta que todos sean inspeccionados. La implementación del API se encarga de devolver todos los servicios existentes en un dispositivo específico y transitar automáticamente hacia el estado de “búsqueda terminada”. En el Anexo V: MIDlet Bluetooth para el descubrimiento de.

(36) CAPÍTULO 2. Tecnologías utilizadas. 28. Dispositivos y Servicios se muestra un ejemplo de cómo realizar búsquedas Bluetooth utilizando la implementación del API JSR-82, no obstante el lector podrá encontrar otros ejemplos del uso del API en [14] [15] [17].. Figura 2.8. Diagrama de estados del proceso de descubrimiento de servicios. Tomado de: Java Programming Techniques for Games de Andrew Davison [16]. 2.2.4. Seguridad. En esta sección se describen los métodos disponibles en la implementación del API para solicitar comunicaciones Bluetooth seguras. Las aplicaciones pueden añadir parámetros de forma opcional a la cadena de conexión para especificar la seguridad requerida en las conexiones. Estos parámetros pueden ser usados para establecer medidas de seguridad al mismo tiempo que se establece la conexión. 2.2.4.1 Solicitudes de seguridad en la cadena de conexión del Servidor Los parámetros opcionales que se pueden utilizar en la cadena de conexión por parte del servidor para ofrecer cierto grado de seguridad en la conexión son: autenthicate, encrypt, authorize y master. Estos parámetros serán tratados a continuación por la importancia que presentan..

(37) CAPÍTULO 2. Tecnologías utilizadas. 29. La autenticación Bluetooth es la verificación por parte del servidor de la identidad del dispositivo remoto y se realiza como un procedimiento de encuesta-respuesta donde se genera una llave de 128 bits a partir de un código PIN compartido por ambos dispositivos. El parámetro autenthicate es el encargado de solicitar la autenticación y puede o no estar presente en la cadena de conexión. En caso de estar presente, todavía puede tener dos interpretaciones: verdadero o falso. Si autenthicate es verdaero (autenthicate = true) entonces se confirma la identidad, de lo contrario no se verifica. Es de suma importancia señalar que no todos los dispositivos Bluetooth soportan autenticación; por lo tanto, si se quiere desarrollar una aplicación con elevada compatibilidad es recomendable no usar estos parámetros. La encriptación Bluetooth es la codificación especial de la información a transmitir y es aplicada a la transferencia de datos en ambas direcciones sobre el enlace encriptado. El parámetro encrypt es el que realiza la petición de encriptación y funciona en correlación con el parámetro autenthicate, ya que para la encriptación es requerida una llave compartida para la codificación-decodificación de los datos. Una notificación de error será enviada a la aplicación en caso de querer usar encrypt sin autenthicate. La autorización es un procedimiento mediante el cual un usuario de un dispositivo servidor concede acceso a un servicio específico de un dispositivo cliente específico [5]. La implementación de la autorización puede involucrar que se le pregunte al usuario del dispositivo servidor si al dispositivo cliente debería permitírsele acceder al servicio, o la consulta de una lista de dispositivos definidos “confiables” a los cuales se les permite el acceso al servicio. El parámetro authorize=true en la cadena de conexión fuerza a la implementación a consultar con el BCC para determinar si el cliente que solicita la conexión está autorizado o no a acceder al servicio. Al igual que en los demás parámetros el efecto de authorize=false es el mismo que si no estuviera presente en la cadena de conexión. Similar a como ocurre con la encriptación se obtendrá un error si se intenta utilizar authorize sin la presencia del parámetro autenthicate. En una red Bluetooth un dispositivo puede ser tanto maestro como esclavo. El dispositivo que inicia la formación de un enlace de datos generalmente asume el papel de maestro. La implementación proporciona un procedimiento para que un dispositivo esclavo solicite un.

(38) CAPÍTULO 2. Tecnologías utilizadas. 30. intercambio maestro/esclavo a través del parámetro master. El parámetro master = true fuerza a que el cliente y el servidor intercambien sus papeles para que el servidor se convierta en master. No todos los dispositivos soportan el cambio de papel, por lo que se debe tener mucho cuidado a la hora de utilizar este parámetro. 2.2.4.2 Solicitudes de seguridad en la cadena de conexión del Cliente Los clientes también pueden utilizar parámetros de seguridad en la cadena de conexión, pero solo autenthicate, encrypt y master. Cuando autenthicate = true la implementación intenta verificar la identidad del servidor. Cuando encrypt = true la implementación codifica todas las comunicaciones desde y hacia el servicio conectado y al igual que en el servidor encrypt = true implica autenthicate = true. Cuando master = true el cliente debe no solo asumir el papel de maestro de la red sino rechazar los intentos del servidor de realizar un intercambio de papeles. Al igual que en el servidor, el efecto de los parámetros en falso es el mismo que si no estuvieran presentes en la cadena de conexión. Con la utilización del API JSR-82, el único dispositivo que necesita conceder permiso para utilizar un servicio es el propio dispositivo que ofrece el servicio, por lo cual el parámetro authorize no se permite en las conexiones cliente. Cuando un cliente intenta conectarse al servicio ofrecido por un servidor ambos dispositivos (el servidor y el cliente) definen sus parámetros de conexión. Casi todas las combinaciones válidas de estos parámetros proveen una conexión exitosa, excepto que en ambos dispositivos se especifique master = true donde la conexión jamás procede. 2.2.5. Conexión. Para utilizar un servicio en un dispositivo Bluetooth remoto, el dispositivo local debe comunicarse usando el mismo protocolo que el servidor remoto. Como las aplicaciones pueden acceder a una amplia gama de servicios el API Java Bluetooth JSR-82 proporciona métodos para permitir conexiones que utilizan los protocolos RFCOMM, L2CAP y OBEX. En el desarrollo posterior del informe solo se hará referencia a las conexiones que utilicen el protocolo RFCOMM y el perfil SPP. El protocolo RFCOMM, como se ha mencionado anteriormente, proporciona la emulación del puerto serie (RS-232) entre dos dispositivos Bluetooth. Las direcciones Bluetooth de los.

(39) CAPÍTULO 2. Tecnologías utilizadas. 31. dos puntos finales identifican una sesión RFCOMM. Solo una sesión RFCOMM puede existir entre cualquier par de dispositivos a la vez, aunque una sesión puede tener más de una conexión, donde el número de conexiones simultáneas que pueden establecerse está determinado por el dispositivo Bluetooth. Una aplicación que ofrece un servicio basado en el perfil puerto serie (SPP) es un servidor SPP, mientras que una aplicación que inicia una solicitud de conexión a un servidor SPP es un cliente SPP. La conexión entre un servidor y un cliente SPP se realiza de la siguiente forma: . Como parte del proceso de registro de servicio, un identificador de canal de servicio se añade al serviceRecord.. . Un cliente localiza el servicio usando el protocolo de descubrimiento de servicio.. . El cliente se puede conectar al servicio especificando la dirección del servidor y el identificador del canal de servicio.. . La negociación de los parámetros de conexión y control se manejan automáticamente por la implementación.. . Después de establecer la conexión los datos pueden ser trasmitidos en ambas direcciones. 2.2.5.1 Servidor SPP. Un servidor SPP puede crear un objeto de tipo StremConnectionNotifier de dos formas diferentes: usando la cadena apropiada para un servidor SPP como argumento de Connector.Open() o realizando un casting del resultado obtenido de Connector.Open() a la interfaz StremConnectionNotifier. En el Anexo VI: Estructura de un Servidor RFCOMM se muestra un ejemplo de cómo crear un servidor SPP. La. URL. de. conexión. para. el. servidor. queda. de. la. siguiente. forma:. btspp://loclhost:UUID[;Parametros del Servidor] donde UUID es el identificador universal del servidor y los Parámetros del Servidor son una serie de valores separados por “;” con la siguiente estructura: param = boolean. El servicio SPP puede aceptar múltiples conexiones de diferentes clientes creando un nuevo objeto StremConnection para cada conexión aceptada. Cada cliente accede al mismo.

(40) CAPÍTULO 2. Tecnologías utilizadas. 32. seviceRecord y se conecta al servicio usando el mismo canal RFCOMM del servidor siempre y cuando este soporte conexiones múltiples. 2.2.5.2 Cliente SPP Antes de que un cliente SPP pueda establecer una conexión con un servicio SPP, debe descubrirlo primero. Una conexión cliente incluye la dirección Bluetooth del dispositivo del servidor y el identificador de canal del servidor para ese servicio. El método getConnectionURL() en la interfaz ServiceRecord se usa para obtener esta URL, mientras que invocando el método Connector.Open() desde un cliente SPP, se obtiene un objeto StremConnection que representa la conexión SPP desde el lado del cliente. El cliente utiliza una URL de forma similar a como se utiliza en el servidor quedando de la siguiente manera: btspp//Dirección:Canal[;parámetros del Cliente] donde Dirección es una cadena de 12 dígitos en hexadecimal y Canal es un número del uno al 30 que identifica una conexión con el servidor, mientras que los parámetros del Cliente son los mismos que los del servidor. Por tanto, para establecer una conexión con un servicio identificado por el identificador de canal 2 en un dispositivo con dirección “0050C000321B” se debe utilizar la sentencia: StreamConnection con = (StreamConnection) Connector.open(“btspp://0050C000321B:2”). 2.3 Infraestructura Para desarrollar cualquier tipo de software es necesario seleccionar la plataforma y las herramientas de desarrollo adecuadas. En este apartado se describe la infraestructura necesaria para desarrollar aplicaciones Bluetooth con Java. El desarrollo de estas aplicaciones necesita de un Entorno de Desarrollo Integrado para compilar y preverificar los MIDlets, la utilización de emuladores de teléfonos móviles y de conexiones Bluetooth y por último, dispositivos móviles donde probar las aplicaciones creadas. 2.3.1. Entornos de desarrollo integrado (IDEs). En la actualidad existen numerosos IDEs para el desarrollo de aplicaciones J2SE, mas no queda claro cuántos de ellos pueden ser utilizados para programar aplicaciones J2ME. Por.

(41) CAPÍTULO 2. Tecnologías utilizadas. 33. razones de objetivo y tiempo solo dos IDEs fueron explorados en la presente investigación: NetBeans versión 6.9.1 [18] y Eclipse versión 3.0.2 [19]. NetBeans es un IDE fácil de utilizar y provee las funcionalidades básicas para la programación java: completamiento de código, organización de proyectos e incluso la posibilidad de mostrar la documentación Java mientras se autocompleta el código. Además, el proceso de instalación y el de integración de nuevas funcionalidades es muy sencillo y ofrece excelente compatibilidad con los simuladores Java Wireless Toolkit e Impronto Simulator. Eclipse es un excelente IDE para el desarrollo de aplicaciones Java, es código abierto y está disponible de forma libre. Una de las ventajas que posee es que es altamente portable y no necesita ser instalado. Sin embargo, posee algunas dificultades para la programación J2ME al no traer incluido en sus módulos por defecto uno que permita preverificar este tipo de aplicaciones. Además no se integra a los simuladores disponibles para poder realizar el debug de las aplicaciones desarrolladas. La aplicación desarrollada como parte de la presente investigación fue escrita, compilada y preverificada con NetBeans 6.9.1. 2.3.2. Simuladores. Además de los IDEs se utilizaron dos simuladores para probar el funcionamiento de las aplicaciones Bluetooth desarrolladas: Impronto Simulator y JavaTM Wireless Toolkit versión 2.2 (WTK 2.2) [20]. El Java™ Wireless Toolkit 2.2 [21] se trata de un entorno de desarrollo de aplicaciones J2ME. Este entorno implementa una gran cantidad de JSRs, entre ellos el JSR-82. La implementación del JSR-82 del WTK 2.2 es virtual, es decir, no usa hardware Bluetooth, sino que lo emula. Para simular un entorno de dispositivos Bluetooth simplemente tendremos que ejecutar nuevas instancias del simulador de móviles y cada instancia se podrá comunicar con las demás a través del API Bluetooth como si de un entorno real se tratara. Sin embargo, WTK 2.2 no permite simulación de dispositivos que no contengan perfil MIDP y configuración CLDC. Es decir, no permite simulación de conexiones Bluetooth entre PC’s o PC-Celular..

(42) CAPÍTULO 2. Tecnologías utilizadas. 34. Impronto [22] es un simulador de entorno Bluetooth diseñado por la empresa Rococosoft. A través de su interfaz gráfica podemos añadir y configurar dispositivos virtuales. Podemos usarlo tanto para simular aplicaciones J2ME como aplicaciones J2SE, funcionalidad que no cumple el WTK de Sun. 2.3.3. Teléfonos móviles. Dos teléfonos móviles se utilizaron para probar el funcionamiento de la aplicación creada, el Nokia 2760 y el Nokia N95. El Nokia 2760 es un teléfono celular de banda dual GSM de tipo clamshell. Sus funciones son pantalla TFT de 65k colores, cámara VGA, Bluetooth, Radio FM, navegador WAP, Organizador y altoparlante. Tabla 2.1. Características técnicas del Nokia 2760. Característica. Descripción. Fabricante. Nokia. Procesador. -. Memoria. Max User Storage: 11 MB.. Pantalla. 128x160 pixeles, 65k colores.. Bandas. GSM 900/1800, GPRS, EDGE.. Conectividad. USB 2.0, Bluetooth 2.0, WAP.. Ringtones. Polifónicos, Mp3.. Dimensiones. 87x44x20 mm.. Peso. 80 g.. El Nokia N95 admite video-llamada, multiconferencia, PPH, número fijo de marcación (solo permite las llamadas a los números predefinidos). En cuanto a la mensajería de texto admite SMS concatenados, postales electrónicas y listas de distribución de SMS. Para la mensajería multimedia combina imágenes, video, texto y secuencias de audio para enviarlas como MMS a un PC o teléfono compatible. Además del correo, lee documentos en formato .doc, .xls, .pps y PDF y dispone de compresor de archivos ZIP. Dispone.

(43) CAPÍTULO 2. Tecnologías utilizadas. 35. también de función de copia de seguridad del contenido de la memoria principal en la tarjeta de expansión o alternativamente hacia el PC conectado. Tabla 2.2. Características técnicas del Nokia N95. Característica. Descripción. Fabricante. Nokia. Procesador. Dual 332 MHz Texas Instruments OMAP 2420 (ARM11-based).. Memoria. Max User Storage: 160 MB, NAND Mem.: 256 MB, SDRAM Mem.: 64 MB, MicroSD max 12 GB.. Pantalla. 2.6 pulgadas, 40x53 mm, 240x320 pixeles, 16.7 millones de colores.. Bandas. HSDPA (3.5G), GSM850/900/1800/1900, GPRS, EDGE. Conectividad. USB 2.0, Bluetooth 2.0, Wi-Fi b/g, Infrarrojos.. Ringtones. Polifónicos, Mp3.. Dimensiones. 99x53x21 mm.. Peso. 120g..

(44) CAPÍTULO 3. Diseño del Control Remoto Bluetooth. 36. CAPÍTULO 3. Diseño del Control Remoto Bluetooth. En el presente capítulo se abordan los métodos de diseño utilizados para desarrollar el control remoto Bluetooth, así como el funcionamiento general de la aplicación, la implementación de las interfaces cliente y servidor, el análisis de la conexión y los resultados alcanzados durante el desarrollo de la investigación. 3.1. Consideraciones generales. La aplicación desarrollada es un conjunto de tipo cliente-servidor que contiene dos módulos independientes que interactúan entre ellos como se muestra en la figura 3.1. PC (Servidor). Móvil (Cliente). Sistema operativo. Aplicación MIDP. JRE 1,6,0 Servidor Bluetooth. MIDP Robot. Bluecove. Stack Bluetooth. JSR-82. Cliente Bluetooth. CLDC Sistema operativo Nativo + Stack Bluetooth. Figura 3.1. Diagrama general de la aplicación..