PROPUESTA DE UN SISTEMA PORTÁTIL E …148.206.53.84/tesiuami/UAMI13387.pdf · En ese sentido, los trabajos de investigación están orientados a desarrollar mejores sistemas de adquisición

UNIVERSIDAD AUTÓNOMA METROPOLITANAUNIDAD IZTAPALAPA

PROPUESTA DE UN SISTEMA PORTÁTIL E

INALÁMBRICO PARA LA ADQUISICIÓN DE SONIDOS

RESPIRATORIOS.

Estrada Mestre Eduardo.

Licenciatura en Ingeniería Biomédica.

Asesores:

Dr. Ramón González Camarena.

Dr. Tomás Ángel Aljama Corrales.

Seminario de Proyectos I y II.

PROPUESTA DE UN SISTEMA PORTÁTIL E

INALÁMBRICO PARA LA ADQUISICIÓN DE SONIDOS

RESPIRATORIOS.

Estrada Mestre Eduardo.

Licenciatura en Ingeniería Biomédica.

Dr. Tomás Ángel Aljama Corrales

Asesor.

Dr. Ramón González Camarena

Asesor.

Ing. Gerardo Edmundo Urbina Medal

Coordinador de la Licenciatura en

Ingeniería Biomédica.

SEMINARIO DE PROYECTOS

ÍNDICE DE CONTENIDO: I.- OBJETIVOS DEL PROYECTO............................................................................................. 1 II.- TECNOLOGÍAS UTILIZADAS. .......................................................................................... 3

II.1.- BLUETOOTH..................................................................................................................... 3 II.1.1.- Introducción. ........................................................................................................... 3 II.1.2.- Conceptos Clave. ..................................................................................................... 3

II.1.2.1.- Maestros y Esclavos. ......................................................................................................3 II.1.2.2.- Frecuency Hopping Spread Spectrum (FHSS) y Time Division Duplexing (TDD)....4 II.1.2.3.- Piconets y Scatternets. ...................................................................................................5

II.1.3.- Especificación del Núcleo. ...................................................................................... 6 II.1.3.1.- Descripción.....................................................................................................................6 II.1.3.2.- Radio. .............................................................................................................................8 II.1.3.3.- Protocolos Nucleares de Bluetooth. ..............................................................................9

II.1.3.3.1.- Baseband................................................................................................................9 II.1.3.3.2.- LMP......................................................................................................................26 II.1.3.3.3.- HCI. ......................................................................................................................33 II.1.3.3.4.- L2CAP..................................................................................................................36 II.1.3.3.5.- SDP.......................................................................................................................41 II.1.3.3.6.- RFCOMM............................................................................................................46 II.1.3.3.7.- BNEP....................................................................................................................52

II.1.3.4.- Protocolos de Control de Telefonía. ............................................................................52 II.1.3.4.1.- TCS.......................................................................................................................52 II.1.3.4.2.- Comandos AT......................................................................................................53

II.1.3.5.- Protocolos Adoptados...................................................................................................53 II.1.3.5.1.- HID.......................................................................................................................53 II.1.3.5.2.- PPP. ......................................................................................................................53 II.1.3.5.3.- TCP/UDP/IP. .......................................................................................................53 II.1.3.5.4.- WAP. ....................................................................................................................54 II.1.3.5.5.- OBEX. ..................................................................................................................54

II.1.3.6.- Protocolos Adicionales.................................................................................................55 II.1.3.6.1.- AVCTP.................................................................................................................55 II.1.3.6.2.- AVDTP.................................................................................................................55

II.1.4.- Especificación de Perfiles. .................................................................................... 55 II.1.4.1.- Descripción...................................................................................................................55 II.1.4.2.- Perfiles Fundamentales. ..............................................................................................57 II.1.4.3.- Perfiles de Aplicación. .................................................................................................59

II.1.5.- Aspectos Adicionales. ............................................................................................ 66 II.1.5.1.- Administración de energía...........................................................................................66 II.1.5.2.- Seguridad. ....................................................................................................................67

III.2.- PDA. ............................................................................................................................ 72 III.- SISTEMA PROPUESTO. .................................................................................................. 75

III.1.- HARDWARE. ................................................................................................................. 75 III.1.1.- PDA. ..................................................................................................................... 75 III.1.2.- Módulo Bluetooth. ............................................................................................... 76 III.1.3.- Microcontrolador................................................................................................. 77 III.1.4.- Micrófono............................................................................................................. 78

III.2.- SOFTWARE. .................................................................................................................. 78 III.2.1.- Programación del Microcontrolador. ................................................................. 78 III.2.2.- Programación del PDA........................................................................................ 81

III.2.2.1.- Descripción de la Solución en Java. ..........................................................................81 III.2.2.2.- Programación de Aplicaciones. .................................................................................85

III.3.- CONSIDERACIONES ADICIONALES............................................................................... 92 ANEXO A ................................................................................................................................... 96

Sistema portátil e inalámbrico para la adquisición de sonidos respiratorios


ÍNDICE DE FIGURAS: Figura I: Sistema actual de adquisición de sonidos respiratorios. .............................................. 1 Figura II.1.2.2: FHSS y TDD.II .................................................................................................... 5 Figura II.1.2.3: Piconet y Scatternet.II ......................................................................................... 6 Figura II.1.3.1: Pila de protocolos de Bluetooth. ........................................................................ 7 Figura II.1.3.2: Patrones de fase para las modulaciones π/4-DQPSK y 8DPSK.X ..................... 9 Figura II.1.3.3.1.a: Cálculo del salto en frecuencia.XI .............................................................. 10 Figura II.1.3.3.1.b: Estructura de un paquete Bluetooth en el modo BR.IX.............................. 12 Figura II.1.3.3.1.c: Estructura de un paquete Bluetooth en el modo EDR.IX ........................... 12 Figura II.1.3.3.1.d: Estructura del código de acceso.IX............................................................. 13 Figura II.1.3.3.1.e: Estructura del encabezado de paquete.IX ................................................... 14 Figura II.1.3.3.1.f: Estructuras de la carga útil de los paquetes.IX ........................................... 15 Figura II.1.3.3.1.g: Transiciones necesarias para establecer y finalizar un enlace Bluetooth.II..................................................................................................................................................... 22 Figura II.1.3.3.4: Canales del L2CAP entre tres dispositivos diferentes.II................................ 39 Figura II.1.3.3.5: Mapeo del campo Class of Device/Service.VIII .............................................. 44 Figura II.1.4: Interdependencias de los perfiles de Bluetooth.III ............................................... 57 Figura II.1.5.2.a: Generación de la clave Kinit.VIII ..................................................................... 68 Figura II.1.5.2.b: Generación de la clave Kab.VIII ...................................................................... 69 Figura II.1.5.2.c: Proceso de autentificación.VIII ....................................................................... 70 Figura II.1.5.2.d: Proceso de encriptación.VIII .......................................................................... 71 Figura III.1.1: PDA Dell Axim X51v .XVIII ................................................................................. 76 Figura III.1.2: Módulo Bluegiga Wrap Thor WT11 con antena integrada.XIX.......................... 77 Figura III.1.4: Micrófono utilizado en el sistema actual de adquisición de sonidos respiratorios. ............................................................................................................................... 78 Figura III.2.1: Pila iWRAP.XX ................................................................................................... 79 Figura III.3.1: Graficas y espectros de la señal original y la recibida. .................................... 93 Figura III.3.2: Gráfica de la coherencia entre la señal original y la recibida.......................... 94



ÍNDICE DE TABLAS:

Tabla II.1.3.2: Clasificación de dispositivos Bluetooth según su potencia. ................................ 8 Tabla II.1.3.3.1.a: Tipos de paquetes SCO y eSCO. .................................................................. 18 Tabla II.1.3.3.1.b: Tipos de paquetes ACL. ............................................................................... 19 Tabla II.1.3.3.1.c: Tipos de paquetes Bluetooth. ....................................................................... 20 Tabla II.1.3.3.4: Definiciones de los CIDs del L2CAP.............................................................. 38 Tabla II.1.3.3.5: Relación entre los bits del campo Service Class y los servicios genéricos. ... 45 Tabla II.1.3.3.6: Códigos y nombres de los nueve circuitos de una interfaz RS-232. ............... 47 Tabla II.1.5.2: Formato de la lista de dispositivos de confianza............................................... 71



I.- OBJETIVOS DEL PROYECTO. Desde los albores de la medicina, la auscultación de los sonidos producidos durante las acciones de inspiración y espiración ha sido fundamental en el diagnóstico de la mayoría de las patologías propias del sistema respiratorio. Conforme los métodos o técnicas disponibles y las habilidades propias del clínico mejoran, aumenta la relevancia de la información recabada a través de la exploración física del tórax. En ese sentido, los trabajos de investigación están orientados a desarrollar mejores sistemas de adquisición y procesamiento de la señal acústica, así como también entender los mecanismos involucrados en la génesis de diversas patologías respiratorias (estenosis traqueal, asma, enfermedad pulmonar obstructiva crónica, síndrome de apnea obstructiva del sueño, fibrosis pulmonar, entre otras) y en la evaluación del análisis acústico del sonido respiratorio como herramienta diagnóstica y de seguimiento. Con el análisis computarizado es factible tipificar el sonido, además de cuantificar y ubicar su localización en el ciclo respiratorio, que pueden adquirirse varias señales acústicas simultáneas, proceso conocido como mapeo acústico del tórax.I Es precisamente a partir de estas observaciones que la Universidad Autónoma Metropolitana, en colaboración con el Instituto Nacional de Enfermedades Respiratorias, está desarrollando un proyecto de investigación orientado a la adquisición de sonidos respiratorios con base en un enfoque novedoso. Dicho proyecto parte de un sistema de mapeo acústico torácico que utiliza 64 micrófonos conectados a través de cables a una tarjeta de adquisición especialmente diseñada, la cual envía la información a una computadora para ser procesada mediante una aplicación creada con el paquete Matlab. Dicho sistema es el resultado de la unión de varios proyectos individuales que aún se encuentran en una etapa de acoplamiento. La siguiente imagen muestra el sistema actual:

1Figura I: Sistema actual de adquisición de sonidos respiratorios.

Sistema portátil e inalámbrico para la adquisición de sonidos respiratorios 1


Resulta obvio el hecho de que, al tener 64 cables en un estudio que implica por lo menos el movimiento derivado de los esfuerzos inspiratorios y espiratorios del paciente, los artefactos producidos por el roce de los cables y la tensión que estos ejercen sobre los micrófonos, así como los posibles efectos capacitivos e inductivos, reducen la calidad de las señales adquiridas y limitan la cantidad de información útil que se puede obtener de estas a través del procesamiento. Al mismo tiempo, la interacción física del conjunto de cables con el paciente restringe la libertad y naturalidad de sus movimientos, limitando en gran medida la gama de estudios posibles a realizar, tanto para investigación como para un futuro uso clínico. Más aún, este enfoque depende de una plataforma fija o de mínima movilidad, por lo que cualquier estudio estará sujeto a su vez a ciertas condiciones derivadas de la ubicación del equipo, lo que implica que tanto el usuario como el paciente deberán adecuarse a dichas condiciones, cuando lo ideal sería que fuera el equipo el que se adaptara a las necesidades de ambos. Precisamente de esta reflexión se desprenden los objetivos principales del proyecto terminal presentado en este documento:

• Eliminar los numerosos cables necesarios en el sistema actual de adquisición de sonidos respiratorios, disminuyendo con esto los artefactos en las señales registradas y permitiendo una mayor libertad y dinamismo al diseñar los protocolos de estudio, así como una mayor comodidad para el paciente.

• Generar un sistema compacto y portátil capaz de realizar el procesamiento de los datos

adquiridos. En las siguientes páginas se explorará una propuesta que tiene como cimientos dos tecnologías actuales, cada una planteada como plataforma de solución para uno de los objetivos establecidos.



II.- TECNOLOGÍAS UTILIZADAS. A partir de los objetivos expuestos en la sección anterior y, tras una evaluación de la gama de ofertas tecnológicas de última generación realizada durante el servicio social, se han elegido dos tecnologías que, una vez combinadas, prometen cumplir con ambos requisitos a la perfección: una es la tecnología de comunicación inalámbrica Bluetooth, diseñada precisamente para eliminar cables y crear redes de corto alcance, teniendo en cuenta las restricciones inherentes a los dispositivos portátiles, mientras que la otra consiste en el sistema más compacto que emula las características de una PC, es decir el PDA.

II.1.- Bluetooth. II.1.1.- Introducción. Bluetooth es un standard de comunicación inalámbrica que utiliza la banda ISM (Industrial, Scientific and Medical), la cual esta globalmente disponible sin necesidad de licencia. Aunque fue originalmente concebido como una tecnología de reemplazamiento de cables, se ha convertido en una especificación diseñada para soportar una lista de aplicaciones abierta y creciente. Al ser una tecnología de corto alcance y bajo consumo de poder con velocidades de transmisión de 1 Mbps en el modo de velocidad básica o BR (Basic Rate) y de 2 a 3 Mbps de velocidad de transmisión aérea total en el modo de velocidad mejorada o EDR (Enhanced Data Rates), resulta ideal para establecer redes ad-hoc (espontáneas) de tipo PAN (Personal Area Network). La versión actual de la especificación de Bluetooth es la 2.0 + EDR (aunque ya está en desarrollo la versión 2.1), la cual fue adoptada en noviembre del 2004 y comprende dos partes:

1. La especificación del núcleo (core specificacion), que define la pila de protocolos (protocol stack) de Bluetooth.

2. La especificación de perfiles, que define modelos de uso para varios tipos de

aplicaciones. La primera describe el funcionamiento de la tecnología, es decir su arquitectura, mientras que la segunda describe como esta tecnología es utilizada, es decir la manera en que diferentes partes de la especificación pueden ser usadas para desempeñar una determinada función deseada para un dispositivo Bluetooth. Antes de describir cada una de estas partes, se explicarán algunos conceptos fundamentales para entender la tecnología Bluetooth. II.1.2.- Conceptos Clave. II.1.2.1.- Maestros y Esclavos. Todos los dispositivos Bluetooth deben operar ya sea como maestro o como esclavo. Un dispositivo maestro es aquel que inicia la comunicación con otro dispositivo Bluetooth. El dispositivo maestro gobierna tanto el vínculo como el tráfico de las comunicaciones entre sí mismo y los dispositivos esclavos asociados con él. Un dispositivo esclavo es aquél que



responde al dispositivo maestro. Los dispositivos esclavos deben sincronizar su transmisión y recepción con las de los maestros. Adicionalmente, éstos gobiernan las transmisiones de los esclavos, de manera que un esclavo sólo puede empezar su transmisión en el periodo inmediato a aquel en el que el maestro se ha dirigido a él, o en periodos explícitamente reservados para uso del dispositivo esclavo. II.1.2.2.- Frecuency Hopping Spread Spectrum (FHSS) y Time Division Duplexing (TDD). Bluetooth emplea una técnica de salto en frecuencia para garantizar una comunicación segura y robusta. Éste patrón de salto, conocido como FHSS, es tal que el dispositivo salta de un canal de 1 MHz de ancho a otro de manera pseudo-aleatoria; en total existen 79 canales de 1 MHz definidos. El dispositivo permanecerá en un mismo canal durante un periodo de 625 µs llamado ranura (slot), al final del cual realizará un salto hacia un canal diferente. Tanto el transmisor como el receptor deben seguir dicho patrón para poder comunicarse exitosamente. Cualquier interferencia encontrada en una frecuencia en particular será rápidamente detectada y muy probablemente el problema será resuelto al saltar a la siguiente. Sin embargo, a partir de la versión 1.2 de la especificación de Bluetooth se adoptó la técnica AFH (Adaptive Frecuency Hopping) para aumentar la resistencia a la interferencia y asegurar la coexistencia con el estándar de comunicación inalámbrica 802.11b. Dicha variante permite distribuir un mapa de los canales de salto a los dispositivos que forman una red, el cual es actualizado dinámicamente, permitiendo evitar el uso de frecuencias saturadas. De esta forma, la transmisión de paquetes a través de canales con altos niveles de interferencia es reasignada a canales que tengan niveles menores, aumentando la proporción de transmisiones exitosas, lo que se traduce en una mejora en la eficiencia y la velocidad de la comunicación, además de una reducción del nivel de interferencia del transceptor Bluetooth hacia otros dispositivos. La tecnología asegura una comunicación dúplex completa, es decir bidireccional simultánea, mediante un sistema TDD. Esto significa que un dispositivo Bluetooth debe alternar entre transmitir y recibir (o por lo menos esperar) datos de una ranura a otra. La especificación de Bluetooth facilita este sistema TDD mediante el uso de ranuras numeradas de acuerdo al reloj del dispositivo maestro y estableciendo que los maestros deben empezar sus transmisiones en ranuras pares y los esclavos en ranuras impares. El inicio del paquete a transmitir deberá estar alineado con el inicio de la ranura de tiempo. La siguiente figura ilustra el FHSS y el TDD:



2Figura II.1.2.2: FHSS y TDD.II

II.1.2.3.- Piconets y Scatternets. La tecnología Bluetooth favorece el concepto de redes ad-hoc, en las cuales los dispositivos que se encuentren al alcance unos de otros pueden formar dinámicamente una red localizada de duración infinita. Las redes ad-hoc de Bluetooth en las que todos los dispositivos miembros comparten el mismo canal son llamadas piconets. Una piconet puede consistir de hasta ocho dispositivos: un solo maestro y hasta siete dispositivos esclavos. Todos los dispositivos que forman parte de la misma piconet saltan en sincronía. La secuencia de salto está basada en la BD_ADDR del maestro y por consiguiente es única para cada piconet. Varias piconets pueden coexistir en una misma área, sin embargo, conforme su número aumenta la probabilidad de colisión crece, degradando el rendimiento de las comunicaciones. Las scatternets son creadas cuando un dispositivo se convierte en un miembro activo de más de una piconet. El dispositivo colindante comparte sus ranuras de tiempo entre las diversas piconets mediante la multiplexación de tiempo. Múltiples piconets pueden estar ligadas para formar una scatternet. Sin embargo, conforme aumenta el número de piconets, el rendimiento total de la scatternet disminuye. Una unidad Bluetooth puede actuar como un esclavo en varias piconets, pero sólo en una como maestro. Las piconets que conforman una scatternet retienen sus propias secuencias de salto en frecuencia y permanecen como entidades distintas. Las scatternets ofrecen dos ventajas principales sobre las redes ad-hoc tradicionales:

1. Debido a que cada piconet conserva su propia secuencia de salto en frecuencia, el ancho de banda disponible para los dispositivos de cada una de las piconets no se ve degradado por la presencia de otras piconets, aunque la probabilidad de colisiones puede aumentar.



2. Los dispositivos pertenecientes a diferentes piconets pueden prestarse servicios entre sí mientras estén en la misma scatternet.

La siguiente figura muestra ejemplos de piconets y scatternets:

3Figura II.1.2.3: Piconet y Scatternet.II

II.1.3.- Especificación del Núcleo. II.1.3.1.- Descripción. El objetivo de esta especificación consiste en establecer los protocolos que deben seguir las compañías al manufacturar y desarrollar tanto software como hardware. Para lograr interoperabilidad, aplicaciones afines en dispositivos remotos deben ejecutarse en pilas de protocolos idénticas. Aplicaciones diferentes podrán ejecutarse en pilas de protocolos distintas, pero todas tendrán un factor imperativo que les permitirá ser interoperables: el uso de un enlace para datos (data link) y una capa física comunes. Las diferentes capas que conforman la



especificación del núcleo de Bluetooth se dividen en dos secciones lógicas: las tres capas inferiores abarcan el módulo Bluetooth (es decir el hardware), mientras que las capas superiores conforman el anfitrión (host). La interfaz entre estas dos agrupaciones lógicas es llamada HCI (Host Controller Interface) y conforma en sí una capa distinta. A continuación se presenta un esquema que ilustra la organización de la pila de protocolos de Bluetooth:

4Figura II.1.3.1: Pila de protocolos de Bluetooth.

Las aplicaciones se ejecutan sobre una o más secciones verticales de esta pila de protocolos, es decir que no todas las aplicaciones harán uso de todos los protocolos disponibles. Una de las reglas principales al desarrollar la arquitectura de los protocolos de Bluetooth fue la maximización y reutilización de protocolos existentes para distintos propósitos en las capas superiores. La ventaja principal es que aplicaciones existentes o heredadas pueden ser adaptadas para funcionar con la tecnología Bluetooth. La arquitectura de los protocolos permite también la implementación de protocolos de aplicaciones de uso común encima de los protocolos específicos de Bluetooth. La clasificación de las diferentes capas de la pila de protocolos consta de cuatro conjuntos, señalados en la figura por medio de colores:

1. Radio (morado). 2. Protocolos nucleares de Bluetooth (azul + amarillo). 3. Protocolo de control de telefonía (naranja). 4. Protocolos adoptados (rojo)

A continuación se describirá a detalle cada uno de estos grupos.



II.1.3.2.- Radio. Los dispositivos Bluetooth operan en la banda ISM de 2.4 GHz con un ancho de banda de 83.5 MHz, dividida por la especificación en 79 canales de 1 Mhz cada uno y bandas de guarda tanto inferior de 2 MHz, como superior de 3.5 MHz. La banda ISM está repleta de emisores de radiofrecuencia que van desde generadores aleatorios de ruido hasta aplicaciones bien definidas, por lo que no es un medio confiable. La tecnología Bluetooth supera los obstáculos presentados por este ambiente contaminado empleando técnicas que aseguren la robustez de los datos transmitidos. Específicamente, Bluetooth hace uso del salto en frecuencia combinado con paquetes de datos razonablemente cortos y técnicas adaptivas de control de potencia para asegurar la integridad de los datos transmitidos. Las frecuencias de los canales están definidas como:

( )Mhzk+2402 donde .78,...,1,0=k

Para maximizar el ancho de banda disponible en cada canal, la velocidad de transmisión para los canales de radiofrecuencia es de 1 Mbps. La especificación del radio define tres clases de dispositivos según su potencia. Cada clase está asociada con un radio nominal de transmisión y una potencia de salida máxima. A continuación se presenta esta clasificación:

Control de potencia

mW dBm dBm

1 100 100 20 4 - 20 / -30 - 0 (opcional)

2 10 2.5 4 -30 - 0 (opcional)

3 3 1 0 -30 - 0 (opcional)

Clase de potencia

Radio de transmisión

(m)

Potencia de salida máxima

Tabla1 II.1.3.2: Clasificación de dispositivos Bluetooth según su potencia.

La potencia de salida nominal es de 1 mW (0 dBm) para las tres clases. Opcionalmente, cada dispositivo puede variar su potencia de transmisión. La optimización de la potencia de salida en un enlace se hace mediante comandos del LMP (explicados más adelante), midiendo el indicador de la fuerza de la señal del receptor o RSSI (Receiver Signal Strength Indicador) y reportando si la potencia debería ser aumentada o disminuida. Se utiliza como sistema de modulación el denominado GFSK (Gaussian Frecuency Shift Keying), en el que el 1 binario es definido como una desviación en frecuencia positiva (+160 KHz) con respecto a la frecuencia portadora y el 0 como una desviación negativa (-160 KHz). De esta manera se codifica un bit por símbolo, y como la velocidad de símbolos es de 1 MSímbolo/s, se obtiene una velocidad de transmisión de datos de 1 Mbit/s. Adicionalmente, se utilizan otros dos tipos de modulación para el modo EDR. La primera, que es obligatoria, es la π/4-DQPSK (Differential Quadrature Phase-shift Keying), que consiste en variar la fase de la portadora, existiendo cuatro posibles posiciones de fase para cada símbolo con una separación de π/2 entre si (+π/4, +3π/4, -π/4 y -3π/4), lo que permite codificar dos bits por símbolo según la diferencia entre la posición actual y la anterior, proporcionando una velocidad de transmisión de datos de 2 Mbits/s. La segunda, que es opcional, la 8DPSK (Differential Phase-shift Keying), que es muy similar a la π/4-DQPSK excepto que permite



ocho posiciones de fase con una separación de π/4 entre sí (0, +π/4, +π/2, +3π/4, ±π, -π/4, -π/2 y -3π/4), lo que permite codificar tres bits por símbolo, proporcionando una velocidad de transmisión de datos de 3 Mbits/s. La siguiente figura ilustra las posiciones de fase y sus codificaciones en bits para estos dos esquemas de modulación:

5Figura II.1.3.2: Patrones de fase para las modulaciones π/4-DQPSK y 8DPSK.X

II.1.3.3.- Protocolos Nucleares de Bluetooth. II.1.3.3.1.- Baseband. El término Banda Base o (Baseband), se refiere a la gama de frecuencias ocupada por la información antes de modular a la portadora. Ésta capa es por mucho la más compleja de la especificación de Bluetooth. A continuación se presenta una breve descripción de los aspectos clave de la capa de la banda base.

Direccionamiento de dispositivos. Al transceptor de radio en cada dispositivo Bluetooth se le asigna al momento de la manufactura una dirección de dispositivo Bluetooth o BD_ADDR (Bluetooth Device Address) única de 48 bits. Esta dirección se divide en un campo de 24 bits conocido como LAP (Lower Address Portion), un campo de 16 bits conocido como NAP (Non-significant Address Portion) y un campo de 8 bits conocido como UAP (Upper Address Portion). Se utilizan porciones de esta dirección para generar tres tipos de códigos de acceso: el código de acceso del dispositivo o DAC (Device Access Code), el código de acceso del canal o CAC (Channel Acces Code) y el código de acceso de encuesta o IAC (Inquiry Acces Code). El DAC es derivado de la LAP del propio dispositivo y es usado en procedimientos de llamado o paginación (paging), mientras que el IAC se utiliza en procedimientos de encuesta o detección (inquiry). El IAC puede ser dedicado (DIAC), es decir para dispositivos específicos, o genérico (GIAC), es decir para todos los dispositivos. El CAC se especifica para toda la piconet y es derivado de la LAP del dispositivo maestro. Es usado como preámbulo de todos los paquetes intercambiados en la piconet. En cuanto a los dispositivos esclavos de una piconet, existen otras tres direcciones de interés. La primera es la dirección de miembro activo o AM_ADDR (Active Member Address), conocida también como dirección MAC (Media Access Control), que consta de 3 bits asignados a un dispositivo esclavo activo en la piconet; puesto que una piconet



puede tener siete esclavos activos, la AM_ADDR de un esclavo lo identifica únicamente dentro de su piconet. La segunda es la dirección de miembro aparcado o PM_ADDR (Parked Member Address), que consta de 8 bits asignados a un dispositivo que está aparcado, es decir que no está activo dentro de la piconet pero permanece sincronizado con su maestro. La tercera es la dirección de solicitud de acceso o AR_ADDR (Access Request Address), que es usada por un esclavo aparcado para determinar la mitad de la ranura de tiempo, dentro de la ventana de acceso correspondiente a la comunicación esclavo-maestro, durante la cual se le permite enviar mensajes de solicitud; cabe mencionar que esta dirección no es necesariamente única. Un dispositivo esclavo activo pierde su AM_ADDR al momento de aparcarse. De manera similar, un dispositivo aparcado que se vuelve activo pierde inmediatamente tanto su PM_ADDR como su AR_ADDR y obtiene una AM_ADDR. Es importante notar que un dispositivo reactivado no necesariamente recibirá la misma AM_ADDR que tenía antes de ser aparcado. Salto en frecuencia.

Típicamente un salto ocurre al inicio de cada ranura de tiempo. Debido a que cada ranura de tiempo tiene una duración de 625 µs, la frecuencia nominal de salto es de 1600 saltos por segundo; esto es válido para paquetes que ocupan una sola ranura de tiempo, para aquellos que ocupan tres o cinco se utiliza el mismo canal de radiofrecuencia durante la transmisión de todo el paquete. La secuencia del salto en frecuencia de la piconet es determinada por la dirección de dispositivo Bluetooth (BD_ADDR) del dispositivo maestro, mientras que su reloj determina la fase de dicha secuencia. En el momento en que se establece una piconet, la dirección y el reloj del dispositivo maestro son comunicados a todos los dispositivos esclavos de la piconet. Los esclavos usan esta información para sincronizar sus secuencias de salto y determinar el offset entre sus relojes y el del maestro. De esta forma, cada dispositivo perteneciente a la piconet puede realizar el cálculo del salto en frecuencia, como se muestra en la siguiente figura:

6Figura II.1.3.3.1.a: Cálculo del salto en frecuencia.XI

Ya que puede haber múltiples piconets operando en proximidad cercana unas de otras, es importante minimizar las colisiones entre los dispositivos en diferentes piconets. La especificación ataca este problema de dos formas. Primero, el algoritmo pseudo-aleatorio de selección de salto esta diseñado para generar la máxima distancia entre canales de salto adyacentes. Segundo, la duración de las ranuras de tiempo es muy corta, de manera que aún si ocurre una colisión, esta no durará mucho; es poco probable



que se dé otra colisión durante la siguiente ranura de tiempo ya que la piconet habrá saltado a un canal de radiofrecuencia distinto. Estrictamente, la especificación de la banda base define una secuencia de salto diferente para distintos tipos de operaciones. La descripción anterior corresponde a la secuencia de salto de canal, que utiliza los 79 canales de radiofrecuencia disponibles y define un canal físico único para la piconet. Sin embargo, las otras secuencias de salto, asociadas con procedimientos de detección de dispositivos, utilizan sólo 32 canales de radiofrecuencia. Tipos de enlaces.

La especificación de la banda base define tres tipos de enlaces entre dispositivos Bluetooth:

1. Enlace orientado a conexión síncrona o SCO (Synchronous Connection Oriented): Este es un enlace bidireccional simétrico (64 Kbps en cada sentido) punto a punto entre un maestro y un solo esclavo de la piconet. Utiliza un esquema de conexión por conmutación de circuitos o CS (Circuit Switched). El maestro mantiene el enlace SCO utilizando ranuras de tiempo reservadas a intervalos regulares. Las ranuras son reservadas como pares consecutivos: una para transmisiones del maestro hacia el esclavo y otra para transmisiones en el sentido opuesto, El maestro puede mantener hasta tres enlaces SCO simultáneamente. Un esclavo puede mantener hasta tres enlaces SCO simultáneos con un solo maestro, o, si es el dispositivo colindante en una scatternet, puede mantener hasta dos enlaces SCO simultáneos con dos maestros diferentes. Los enlaces SCO son utilizados para intercambiar información del usuario vinculada al tiempo (por ejemplo voz). Los paquetes enviados en estos enlaces nunca son retransmitidos. Estos enlaces sólo soportan el modo de transferencia BR.

2. Enlace orientado a conexión síncrona extendido o eSCO (Extended

Synchronous Connection Oriented): Definidos a partir de la versión 1.2 de la especificación de Bluetooth, los enlaces eSCO permiten ampliar los enlaces SCO estándar mediante combinaciones más flexibles de tipos de paquetes y selecciones más diversas de contenido de datos e intervalos de ranura. De este modo, se puede disponer de una serie de valores de transferencia síncrona en bits. Además, los enlaces eSCO, a diferencia de los SCO, pueden volver a transmitir los paquetes. Si es necesario retransmitir paquetes, el proceso se realiza en las ranuras siguientes a las reservadas. De lo contrario, las ranuras pueden utilizarse en otras operaciones de tráfico. Estos enlaces soportan tanto el modo de transferencia BR como el EDR.

3. Enlace asíncrono no orientado a conexión o ACL (Asynchronous

Connectionless): Este es un enlace punto a multipunto entre el maestro y todos los esclavos de una piconet. Utiliza un esquema de conexión por conmutación de paquetes o PS (Packet Switched). Un enlace ACL puede utilizar cualquier paquete y ranura que no estén reservados para un enlace SCO, utilizando un esquema de acceso por sondeo (polling). El maestro puede intercambiar paquetes con cualquier esclavo en la piconet una vez por ranura de tiempo, incluyendo aquellos con los cuales tiene establecido un enlace SCO. Solamente puede existir un enlace ACL



entre cada par maestro-esclavo. Los enlaces ACL son usados en el intercambio de información de control y datos de usuario, por lo que la retransmisión es aplicada a paquetes ACL recibidos con errores. Estos enlaces sólo soportan tanto el modo de transferencia BR como el EDR.

Definiciones de paquetes.

La especificación de la banda base define el formato y estructura de los varios tipos de paquetes usados en el sistema Bluetooth. Un paquete típico en el modo de transferencia BR utiliza exclusivamente la modulación GFSK y consiste de un código de acceso (access code) de 68 ó 72 bits, un encabezado (header) de 54 bits y una carga útil (payload) de longitud variable entre 0 y 2744 bits. La siguiente figura ilustra esta estructura:

7Figura II.1.3.3.1.b: Estructura de un paquete Bluetooth en el modo BR.IX

En el modo de transferencia EDR, la estructura de los paquetes es muy similar. El código de acceso y el encabezado son idénticos y utilizan la misma modulación. La diferencia radica en la modulación de la carga útil (π/4-DQPSK o 8DPSK) y la introducción de un tiempo de guarda (guard time) y una secuencia de sincronización (synchronization sequence). El tiempo de guarda permite la transición entre un esquema de modulación y otro. Tiene una duración de 4.75/5.25 µs y comienza al final del último símbolo GFSK del encabezado, terminando al inicio de de la secuencia de sincronización. Dicha secuencia tiene una modulación DPSK idéntica tanto para el esquema π/4-DQPSK como para el 8DPSK, y es usada para completar la adquisición antes de demodular la carga útil. Tiene una duración de 11 µs y está compuesta de un símbolo de fase de referencia seguido de diez símbolos DPSK. Adicionalmente se insertan al final dos símbolos de terminación (trailer). La siguiente figura ilustra esta estructura:

8Figura II.1.3.3.1.c: Estructura de un paquete Bluetooth en el modo EDR.IX

Código de acceso. Cada paquete debe comenzar con un código de acceso, el cual es usado para sincronización, compensación de offset e identificación, así como procedimientos de llamado y encuesta, ya sea a nivel de dispositivo (DAC / IAC) o a nivel de piconet (CAC). El código de acceso consta de:



1. Preámbulo (preamble): Está formado por cuatro bits, lo que es útil para detectar los límites de los paquetes. Consiste en una secuencia fija, ya sea 0101 o 1010 dependiendo del valor del primer bit de la palabra de sincronización, de manera que se forme una secuencia de cinco bits conocida. Esto permite tener el umbral de DC y la recuperación del reloj.

2. Palabra de Sincronización (synchronization word): Está hecha a partir de la

LAP de la BT_ADDR, utilizando un algoritmo que involucra la palabra de paridad BCH (Bose-Chaudhuri-Hocquenghem) y la secuencia Barker.

3. Terminación: Se utiliza al final del código de acceso en caso de existir una

carga útil y su objetivo es dar mayor precisión al umbral de DC y a la recuperación del reloj.

En la siguiente ilustración se muestra la estructura del código de acceso:

9Figura II.1.3.3.1.d: Estructura del código de acceso.IX

Encabezado. El encabezado de paquete contiene información de control de enlace, por lo que es importante asegurar su integridad. Esto se logra aplicando un sistema FEC (Forward Error Correction) de 1/3 a todo el encabezado. El encabezado de paquete consiste en 18 bits divididos en seis campos diferentes:

1. AM_ADDR (3 bits): Este campo contiene la AM_ADDR del esclavo que transmitió el paquete o, si fue el maestro el que lo envió, la del esclavo al cual fue dirigido. Un valor de ceros implica que el paquete es de difusión (broadcast), es decir que su transmisión es masiva y generalizada, de manera que será recibido por todos los dispositivos.

2. Type (4 bits): Este campo identifica el tipo de tráfico transportado por el paquete.

3. Flow (1 bit): Este campo es usado para proporcionar información de control



de flujo en un enlace ACL. Un valor de 0 (STOP) indica una petición al dispositivo transmisor para que deje de enviar información, mientras que un valor de 1 (GO) indica que el dispositivo receptor está de nuevo listo para recibir paquetes adicionales. Si no se reciben paquetes del dispositivo receptor, se asume implícitamente un GO.

4. ARQN (1 bit): Este campo es usado para confirmación (acknowledgement) de

datos de carga útil acompañados por un CRC (Cyclic Redundancy Check). Si los datos fueron recibidos sin errores, un reconocimiento positivo (ACK), correspondiente a un valor de 1, es enviado; de lo contrario, se envía un reconocimiento negativo (NACK), correspondiente a un valor de 0. Nótese que el valor por omisión es NACK y es implícitamente asumido.

5. SEQN (1 bit): Este campo es usado en un sistema de numeración secuencial muy simple para los paquetes transmitidos. El bit SEQN es invertido por cada nuevo paquete transmitido que contenga una carga útil acompañada de un CRC. Este campo es requerido para filtrar retransmisiones en el dispositivo destinatario.

6. HEC (8 bits): Este campo, correspondiente a la comprobación de error en el encabezado (Header Error Check), constituye un mecanismo CRC simple y es usado para verificar la integridad del encabezado. Si el encabezado es recibido con errores, el paquete entero es ignorado.

En la siguiente ilustración se muestra la estructura del encabezado de paquete:

10Figura II.1.3.3.1.e: Estructura del encabezado de paquete.IX

Carga útil. La porción del paquete correspondiente a la carga útil es usada para transportar información ya sea de voz o de datos. Típicamente, los paquetes transmitidos en enlaces SCO transportan información de voz (con la excepción del paquete DV, el cual contiene tanto voz como datos) y aquellos transmitidos en enlaces ACL transportan datos. En el caso de los paquetes ACL, el estándar EDR introduce modificaciones en la estructura de la carga útil, con el fin de transmitir paquetes más largos. De esta forma, existen dos diferentes estructuras para la carga útil de los paquetes ACL. Sin embargo,



ambas son de longitud variable y están segmentadas en tres partes: encabezado, cuerpo y CRC. El encabezado de carga útil consta de tres campos principales y tiene una longitud de uno o dos bytes para el modo BR y de dos bytes para el modo EDR. El primer campo (modo BR: 3 bits / modo EDR: 2 bits) es el de canal lógico o L_CH (Logical Channel), que identifica el canal en el cual la carga útil debe ser transportada. El segundo (1 bit) corresponde a la bandera de flujo (flow), que provee información de control de flujo para el canal especificado. El tercero (modo BR: 8 bits / modo EDR: 10 bits) es el de longitud (length), que indica el tamaño del cuerpo de carga útil. El resto de los bits (modo BR: 4 bits / modo EDR: 3 bits) están reservados para la transmisión de los paquetes EDR o, como en el caso de el modo BR, no son usados. En el modo BR, la única diferencia entre los encabezados de carga útil de uno y dos bytes es que los de dos bytes usan más bits para especificar la longitud del cuerpo de carga útil. El cuerpo de carga útil simplemente contiene los datos transportados y el campo de CRC en esencia es un código de 16 bits agregado al paquete para realizar una comprobación de errores en el cuerpo de carga útil. En el modo EDR se agrega al final un par de símbolos DPSK de terminación (trailer), que corresponden a 4 bits = 00, 00 para la modulación π/4-DQPSK y 6 bits = 000, 000 para la modulación 8DPSK. La siguiente figura ilustra la estructura de la carga útil de los paquetes ACL para ambos modos (BR y EDR):

11Figura II.1.3.3.1.f: Estructuras de la carga útil de los paquetes.IX

En cuanto a los enlaces SCO, la diferencia radica en que, mientras los paquetes eSCO (tanto en modo BR como EDR) tienen una estructura similar a los ACL, la carga útil de los paquetes SCO carece tanto de encabezado como de CRC y tiene una longitud fija de 30 bytes (con la excepción del paquete DV).



Tipos de paquetes. Como resulta evidente de la longitud del campo Type en el encabezado de paquete (4 bits), se pueden definir hasta 16 tipos de paquetes para el sistema Bluetooth. Hasta la especificación 1.1 de Bluetooth, se tenían definidos 15 tipos de paquetes (de los cuales sólo 14 ocupan un código Type). Sin embargo, se agregaron 3 nuevos tipos de paquetes correspondientes al enlace eSCO en la versión 1.2, y luego 10 más correspondientes al modo EDR en la versión 2.0. Para evitar problemas de compatibilidad hacia atrás al cambiar el formato del encabezado, la solución adoptada consistió en definir diferentes modos de operación para el enlace y crear un nuevo mensaje que los dispositivos compatibles con el modo EDR intercambian para cambiar de modo. Los paquetes pueden ser clasificados en cuatro grupos: paquetes de control, de una ranura, de tres ranuras y de cinco ranuras. Los paquetes de una, tres y cinco ranuras están definidos de manera distinta para los tres tipos de enlace (SCO, eSCO y ACL) y los dos modos de transferencia (BR y EDR), mientras que los paquetes de control son comunes. Los cinco paquetes de control definidos en la especificación, todos de una ranura, son:

1. ID: Este paquete de 68 bits es usado en rutinas de llamado, encuesta y respuesta; esencialmente consta del DAC o el IAC del dispositivo y carece de encabezado, por lo que no tiene un código TYPE asignado.

2. NULL: Este paquete de 126 bits consiste solamente en el CAC del dispositivo y el encabezado del paquete; es utilizado para regresar información del enlace a la fuente tras la recepción de un paquete, así como en ausencia de datos para transmitir cuando se establece un enlace, y no necesita respuesta.

3. POLL: Este paquete, similar al anterior, es usado por el maestro para encuestar a los dispositivos esclavos en una piconet, los cuales deben responder aún si no tienen información para mandar.

4. FHS: El paquete de selección de salto en frecuencia (Frecuency Hop Selection) es usado para identificar la secuencia de salto antes de establecer una piconet o cuando una piconet existente se transforma en una nueva como resultado de un cambio en el rol maestro/esclavo. Este paquete de control contiene la BD_ADDR y el reloj del dispositivo transmisor, además de la AM_ADDR que deberá ser asignada al dispositivo receptor y otra información necesaria para establecer una piconet. La carga útil del paquete puede contener hasta 144 bits de información, seguida de un CRC, ambos codificados con un sistema FEC de 2/3.

5. DM1: Este paquete es usado para respaldar información de control en cualquier enlace. En un enlace ACL, este paquete puede ser usado para transportar datos de usuario. La carga útil del paquete puede contener hasta 18 bytes de información, seguida de un CRC, ambos codificados con un sistema FEC de 2/3.

En cuanto a los paquetes definidos específicamente para enlaces SCO, todos son de una ranura y tienen una carga útil de 30 bytes. Los primeros tres paquetes SCO están diseñados para transportar información de voz de alta calidad o HV (High-quality Voice) a 64 kbps, carecen tanto de CRC (lo que implica que los campos flow, ARQN y SEQ son irrelevantes) como de encabezado de carga útil y están definidos como sigue:



1. HV1: Este paquete contiene 10 bytes de datos, está protegido por un FEC de 1/3 y usa toda la capacidad del canal (esto implica que todas las sesiones de transferencia de datos serán suspendidas cuando se utilice este paquete); debido a que un paquete puede transportar hasta 1.25 ms de conversación, los paquetes HV1 necesitan ser transmitidos una vez cada dos ranuras de tiempo.

2. HV2: Este paquete contiene 20 bytes de datos y está protegido por un FEC de 2/3; debido a que un paquete puede transportar hasta 2.25 ms de conversación, los paquetes HV2 sólo necesitan ser transmitidos una vez cada cuatro ranuras de tiempo.

3. HV3: Este paquete contiene 30 bytes de datos y carece de la protección de un sistema de corrección de error; debido a que un paquete puede transportar hasta 3.75 ms de conversación, los paquetes HV3 necesitan ser transmitidos solamente una vez cada seis ranuras de tiempo.

El último paquete definido para el enlace SCO es el de datos y voz combinados o DV (combined Data and Voice), el cual contiene un campo para voz de 10 bytes y otro para datos de entre 0 y 9 bytes. El campo de datos está codificado con un sistema FEC de 2/3 y protegido por un CRC que permite su retransmisión (lo que implica que los campos flow, ARQN y SEQ son utilizados), a diferencia del campo de voz que carece de ambos. Los dos campos son manejados completamente por separado, de manera que la información de voz, que es síncrona, nunca es retransmitida, mientras que los datos son retransmitidos en caso de error. Adicionalmente, se han definido 7 tipos de paquetes correspondientes al enlace eSCO, todos protegidos por un CRC que permite su retransmisión, los primeros tres para el modo de transferencia BR y los siguientes cuatro para el EDR:

1. EV3: Este paquete contiene de 1 a 30 bytes de datos, carece de la protección de un sistema de corrección de error, ocupa una ranura y está diseñado para el modo de transferencia BR.

2. EV4: Este paquete contiene de 1 a 120 bytes de datos, está protegido por un FEC de 2/3, ocupa tres ranuras y fue diseñado para el modo de transferencia BR.

3. EV5: Este paquete contiene de 1 a 180 bytes de datos, carece de la protección de un sistema de corrección de error, ocupa tres ranuras y está diseñado para el modo de transferencia BR.

4. 2-EV3: Este paquete contiene de 1 a 60 bytes de datos, carece de la protección

de un sistema de corrección de error, ocupa una ranura y está diseñado para el modo de transferencia EDR con modulación π/4-DQPSK.


de un sistema de corrección de error, ocupa tres ranuras y está diseñado para el modo de transferencia EDR con modulación π/4-DQPSK.


de un sistema de corrección de error, ocupa una ranura y está diseñado para el modo de transferencia EDR con modulación 8DPSK.




de un sistema de corrección de error, ocupa tres ranuras y está diseñado para el modo de transferencia EDR con modulación 8DPSK

La siguiente tabla presenta un resumen de los tipos de paquetes definidos para los enlaces SCO y eSCO junto con sus características:

HV1 N/A 10 1/3 No 64.0HV2 N/A 20 2/3 No 64.0HV3 N/A 30 No No 64.0DV 1 10 + (0-9)D 2/3 D Sí D 64.0 + 57.6DEV3 N/A 1 - 30 No Sí 64.0EV4 N/A 1 - 120 2/3 Sí 256.0EV5 N/A 1 - 180 No Sí 384.0

2-EV3 N/A 1 - 60 No Sí 128.02-EV5 N/A 1 - 360 No Sí 768.03-EV3 N/A 1 - 90 No Sí 192.03-EV5 N/A 1 - 540 No Sí 1152.0

Enlace

SCO BR

eSCO BR

eSCO EDR

TipoEncabezado de carga útil

(bytes)

Carga útil (bytes)

FEC CRCMáxima velocidad

de transmisión simétrica (Kb/s)

Tabla2 II.1.3.3.1.a: Tipos de paquetes SCO y eSCO.

Por otra parte, se han definido seis tipos de paquetes específicamente para el enlace ACL en el modo de transferencia BR, todos diseñados para transportar datos. Se distinguen unos de otros según dos criterios básicos:

1. Codificación con un sistema FEC: Los paquetes codificados son denominados paquetes de mediana velocidad de datos o DM (Medium Data rate), mientras que los no codificados son denominados paquetes de alta velocidad de datos o DH (High Data rate).

2. Nº de ranuras de tiempo: Es posible encontrar paquetes de una (D*1), tres (D*3) y cinco (D*5) ranuras; obviamente, entre mayor sea la longitud del paquete, mayor será la cantidad de datos que puede transportar.

Existen dos tipos de paquetes DM definidos exclusivamente para el enlace ACL, el DM3 (121 bytes de información) y el DM5 (224 bytes de información), ambos protegidos por un FEC de 2/3. Es necesario recordar que el DM1 (17 bytes de información) está definido como un paquete de control que en un enlace ACL puede ser usado para transportar datos Se han definido tres tipos de paquetes DH: DH1 (27 bytes de información), DH3 (183 bytes de información) y DH5 (339 bytes de información). Todos estos paquetes pueden transportar más datos que sus contrapartes DM ya que no dedican espacio a la codificación.



El sexto tipo de paquete definido para el enlace ACL en el modo de transferencia BR es el paquete auxiliar AUX1, el cual es muy similar al DH1, con la excepción de que tanto el esquema FEC como el código CRC son opcionales, por lo que puede transportar hasta 29 bytes de información. Finalmente, se han definido 6 tipos de paquetes para el enlace ACL en el modo de transferencia EDR, todos protegidos por un CRC que permite su retransmisión pero carentes de la protección de un sistema de corrección de error:

1. 2-DH1: Este paquete contiene de 0 a 54 bytes de datos, ocupa una ranura y utiliza la modulación π/4-DQPSK.

2. 2-DH3: Este paquete contiene de 0 a 367 bytes de datos, ocupa tres ranuras y

utiliza la modulación π/4-DQPSK.

3. 2-DH5: Este paquete contiene de 0 a 679 bytes de datos, ocupa cinco ranuras y utiliza la modulación π/4-DQPSK.

4. 3-DH1: Este paquete contiene de 0 a 83 bytes de datos, ocupa una ranura y

utiliza la modulación 8DPSK.

5. 3-DH3: Este paquete contiene de 0 a 552 bytes de datos, ocupa tres ranuras y utiliza la modulación 8DPSK.

6. 3-DH5: Este paquete contiene de 0 a 1021 bytes de datos, ocupa cinco ranuras y

utiliza la modulación 8DPSK. La siguiente tabla presenta un resumen de los tipos de paquetes definidos para el enlace ACL junto con sus características:

Directa ReversaDM1 1 0 - 17 2/3 Sí 108.8 108.8 108.8DH1 1 0 - 27 No Sí 172.8 172.8 172.8DM3 2 0 - 121 2/3 Sí 258.1 387.2 54.4DH3 2 0 - 183 No Sí 390.4 585.6 86.4DM5 2 0 - 224 2/3 Sí 286.7 477.8 36.3DH5 2 0 - 339 No Sí 433.9 723.2 57.6

AUX1 1 0 - 29 Opcional Opcional 185.6 185.6 185.62-DH1 2 0 - 54 No Sí 345.6 345.6 345.62-DH3 2 0 - 367 No Sí 782.9 1174.4 172.82-DH5 2 0 - 679 No Sí 869.1 1448.5 115.23-DH1 2 0 - 83 No Sí 531.2 531.2 531.23-DH3 2 0 - 552 No Sí 1177.6 1766.4 265.63-DH5 2 0 - 1021 No Sí 1306.9 2178.1 117.1

ACL BR

ACL EDR

Máxima velocidad de transmisión (Kb/s)

AsimétricaSimétrica

Encabezado de carga útil

(bytes)

Carga útil (bytes)

FEC CRCTipoEnlace

Tabla3 II.1.3.3.1.b: Tipos de paquetes ACL.



Puesto que ningún paquete EDR emplea un esquema FEC, se extiende el algoritmo CQDDR (Channel Quality Driven Data Rate) existente para cambiar automáticamente a paquetes BR con FEC cuando sea necesario. La siguiente tabla presenta un resumen de todos los tipos de paquetes disponibles, junto con sus respectivos códigos Type, según el tipo de enlace y el modo de transferencia:

Enlace SCO BR

Enlace eSCO BR

Enlace eSCO EDR

Enlace ACL BR

Enlace ACL EDR

0000 NULL NULL NULL NULL NULL0001 POLL POLL POLL POLL POLL0010 FHS -- -- FHS FHS0011 DM1 -- -- DM1 DM10100 -- -- -- DH1 2-DH10101 HV1 -- -- -- --0110 HV2 -- 2-EV3 -- --0111 HV3 EV3 3-EV3 -- --1000 DV -- -- -- 3-DH11001 -- -- -- AUX1 AUX11010 -- -- -- DM3 2-DH31011 -- -- -- DH3 3-DH31100 -- EV4 2-EV5 -- --1101 -- EV5 3-EV5 -- --1110 -- -- -- DM5 2-DH51111 -- -- -- DH5 3-DH5

GrupoCódigo Type

Nombre

Tres ranuras

Cinco ranuras

Control

Una ranura

Tabla4 II.1.3.3.1.c: Tipos de paquetes Bluetooth.

Canales lógicos.

La especificación de Bluetooth define cinco canales lógicos para transportar ya sea información de control y gestión de enlace o datos de usuario. Existen dos canales que transportan información relacionada al enlace: el canal de control de enlace o LC (Link Control) y el canal de administración de enlace o LM (Link Management). El canal lógico LC está mapeado en el encabezado de cada paquete intercambiado en un enlace Bluetooth, salvo por el paquete ID, y transporta información de enlace de bajo nivel. El canal lógico LM es transportado típicamente en paquetes DM protegidos y puede utilizar ambos tipos de enlace. Un paquete usado para el canal LM es identificado por un valor L_CH de 11 en el encabezado. El canal LM contiene tráfico LMP, es decir información de control intercambiada por los administradores de enlace del maestro y los esclavos, por lo que tiene prioridad sobre canales de datos de usuario. Tres canales lógicos han sido definidos para transportar datos de usuario: el canal asíncrono de usuario o UA (User Asynchronous), el canal isócrono de usuario o UI (User Isochronous) y el canal síncrono de usuario o US (User Synchronous).



Normalmente, los canales UA y UI están mapeados en la carga útil de paquetes transmitidos a través de un enlace ACL, pero también pueden estar mapeados en el campo de datos del paquete DV en un enlace SCO. Ambos transportan datos de usuario, asíncronos e isócronos respectivamente, transparentes a la capa L2CAP. El canal US transporta datos de usuario síncronos transparentes (por ejemplo voz) y está mapeado en la carga útil de paquetes transmitidos a través de un enlace SCO. Control de canales.

El control de canales rige el establecimiento de una piconet y los procesos para agregar o quitar dispositivos. La especificación define dos estados primarios para un dispositivo Bluetooth: en espera (standby) y conectado (connected). El estado de espera es un estado de baja energía asumido por defecto, en el cual sólo el reloj nativo está corriendo y no hay interacción con ningún dispositivo. Un dispositivo esta en estado conectado cuando es miembro de una piconet, es decir, cuando está sincronizado a la secuencia de salto de una piconet; en este estado los dispositivos pueden hacer uso de todos los recursos disponibles para comunicarse e interactuar. Los dispositivos no efectúan una transición directa del estado de espera al estado conectado o viceversa. De hecho, la especificación describe siete subestados por los cuales debe pasar un dispositivo para cambiar de un estado primario al otro. Estos subestados están asociados con procedimientos de encuesta y llamado requeridos para que los dispositivos esclavos abandonen o se incorporen a una piconet. La única transición directa se da en caso de un reinicio (reset) brusco y va del estado conectado al de espera. La siguiente figura ilustra las transiciones necesarias para pasar de un estado primario a otro:



12Figura II.1.3.3.1.g: Transiciones necesarias para establecer y finalizar un enlace Bluetooth.II

El procedimiento de encuesta permite descubrir que dispositivos están dentro del rango de alcance, así como determinar sus direcciones y relojes. Este procedimiento sólo es necesario si no existe información conocida sobre el dispositivo remoto. Posteriormente, se establece una conexión real mediante el procedimiento de llamado. El dispositivo que inicia dicho procedimiento automáticamente se convierte en el maestro de la conexión. Ambos procedimientos utilizan secuencias de salto específicas de 32 frecuencias. En la secuencia de encuesta, la frecuencia es calculada utilizando el IAC del dispositivo que inicia el procedimiento, mientras que su reloj determina la fase. En el caso de la secuencia de llamado, se utiliza la BD_ADDR del dispositivo al que se está llamando para calcular la frecuencia y un estimado de su reloj para determinar la fase. A continuación se describe cada uno de los subestados involucrados en los procedimientos de encuesta y llamado: Encuesta:

1. Encuesta (Inquiry): Un dispositivo entra en este subestado cuando desea descubrir nuevos dispositivos, difundiendo paquetes de encuesta (paquetes ID) que contienen su IAC; a su vez, en



este subestado el dispositivo puede recibir respuestas a su encuesta (paquetes FHS).

2. Exploración de encuesta (Inquiry scan): Un dispositivo entra en este subestado cuando desea recibir paquetes de encuesta.

3. Respuesta a la encuesta (Inquiry response): En este subestado, un dispositivo que haya recibido un paquete de encuesta podrá mandar una respuesta.

Llamado:

4. Llamado (Page): Un dispositivo entra en este subestado cuando busca otros dispositivos, difundiendo paquetes de llamado (paquetes ID) que contienen el DAC del dispositivo con el que desea comunicarse.

5. Exploración de llamado (Page scan): Un dispositivo entra en este subestado

cuando desea recibir paquetes de llamado, por lo que se dedica a detectar secuencias que contengan su propio DAC.

6. Respuesta del esclavo (Slave response): En este subestado, un dispositivo

que haya recibido un paquete de llamado con su propio DAC podrá mandar una respuesta (que de hecho consiste de nuevo en un paquete ID con su DAC); posteriormente, tras haber recibido un paquete FHS, el dispositivo enviará de nuevo una respuesta para finalmente adoptar los parámetros del canal del dispositivo remoto, convirtiéndose en su esclavo.

7. Respuesta del maestro (Master response): En este subestado, un dispositivo

que haya recibido una respuesta a su mensaje de llamado original enviará de vuelta un paquete FHS; posteriormente, tras haber recibido una segunda respuesta confirmando la recepción del paquete FHS, se convertirá en el maestro del dispositivo remoto.

El estado conectado inicia con el envío de un paquete POLL por parte del maestro para verificar que el esclavo haya adoptado los parámetros de su canal. El esclavo puede responder con cualquier tipo de paquete.



Modos de conexión. Un dispositivo Bluetooth en el estado conectado puede estar en cualquiera de cuatro modos, tres de los cuales son de baja energía. A continuación se describe cada uno de estos modos:

• Modo activo: En el modo activo la unidad Bluetooth participa activamente en el canal. El maestro administra la transmisión basado en demandas de tráfico hacia y desde los diferentes esclavos. Adicionalmente soporta transmisiones regulares para mantener a los esclavos sincronizados con el canal. Los esclavos activos pueden recibir paquetes en las ranuras dedicadas a tráfico maestro-esclavo; si el maestro no se dirige a él, el esclavo puede descansar hasta su siguiente transmisión.

• Modo de olfateo (Sniff):

También conocido como modo de escucha reducida, es el menos eficiente de los tres modos de baja energía. Los esclavos pueden ser puestos en modo de olfateo ya sea por orden del maestro o por demanda propia. En este modo el esclavo reduce el ritmo de detección, utilizando periodos de olfateo programables según la aplicación. Es importante notar que las ranuras reservadas para enlaces SCO no son afectadas por este modo. Para entrar en el modo de olfateo, maestro y esclavo negocian un intervalo de olfateo (sniff interval) o Tsniff y un offset de olfateo (sniff offset) o Dsniff que especifica la temporización de las ranuras de olfateo. El offset determina el inicio de la primera ranura de olfateo; posteriormente, las ranuras de olfateo se suceden periódicamente según el intervalo de olfateo. Cuando el enlace esta en modo de olfateo el maestro sólo puede iniciar una transmisión en la ranura de olfateo. Dos parámetros controlan la actividad de escucha (listening) en el esclavo. El parámetro intento de olfateo (sniff attempt) determina el número de ranuras durante las cuales el esclavo debe escuchar, empezando en la ranura de olfateo, aún si no recibe un paquete con su propia AM_ADDR. El parámetro interrupción de olfateo (sniff timeout) determina el número de ranuras adicionales durante las cuales el esclavo debe seguir escuchando en caso de continuar recibiendo solamente paquetes con su propia AM_ADDR.

• Modo de retención (Hold): Este modo tiene una eficiencia intermedia dentro de los tres modos de baja energía. Los esclavos pueden ser puestos en modo de retención ya sea por orden del maestro o por demanda propia. En este modo el enlace ACL entre el maestro y el esclavo es suspendido temporalmente, funcionando sólo un reloj interno en el esclavo. Por el contrario, los enlaces SCO entre el maestro y los esclavos permanecen intactos. El periodo de espera es estipulado previamente a la suspensión del enlace. Cuando una unidad sale de este modo la transmisión de datos reinicia instantáneamente. Típicamente se entra al modo de retención cuando no hay necesidad de enviar datos por un tiempo relativamente largo. El transceptor puede entonces ser apagado para ahorrar energía. Adicionalmente, puesto que el esclavo es liberado, el modo de retención puede ser usado en caso de que un dispositivo quiera descubrir o ser descubierto por otros dispositivos Bluetooth, así como en caso de querer unirse a otras piconets.

• Modo de aparcamiento (Park):

Es el más eficiente de los tres modos de baja energía. Si un esclavo no tiene necesidad de participar en un canal, pero aún así debería permanecer sincronizado al salto en frecuencia, puede ser aparcado. A diferencia de los



modos anteriores, los dispositivos aparcados ya no son considerados miembros activos de una piconet, por lo que renuncian a su dirección MAC (AM_ADDR), recibiendo a cambio las direcciones PM_ADDR y AR_ADDR. La PM_ADDR es utilizada cuando la reconexión es iniciada por el maestro, mientras que la AR_ADDR se utiliza cuando ésta es iniciada por el esclavo. Si el valor de la PM_ADDR es de ceros, el dispositivo deberá ser reactivado usando su BD_ADDR, lo que permite mantener un número virtualmente ilimitado de esclavos aparcados. En este modo, el dispositivo aún se resincroniza al canal y revisa los mensajes difundidos por el maestro al reactivarse en los instantes baliza (beacon instants), separados por el intervalo de baliza (beacon interval). Dicho intervalo, junto con un offset de baliza (beacon offset) y una bandera que indica el método de cálculo determinan el primer instante baliza. Posteriormente los instantes baliza se suceden periódicamente según el intervalo de baliza predeterminado. La ventaja es que la reincorporación de un dispositivo aparcado a la piconet es mucho más rápida que la de un dispositivo que haya sido relegado al estado de espera.

Comprobación y corrección de errores.

Los paquetes Bluetooth pueden ser inspeccionados para detectar errores en tres niveles consecutivos:

1. Se checa el CAC del paquete inmediatamente después de ser recibido; si el código del paquete no corresponde al de la piconet, entonces el paquete fue recibido con errores o estaba destinado a otra piconet, por lo que es descartado.

2. Se checa el HEC del paquete; si éste indica que la información del encabezado del paquete tiene errores irremediables, el paquete es descartado.

3. Se checa el CRC para comprobar la integridad de la carga útil. El sistema Buetooth también hace uso de tres diferentes sistemas de corrección de error. Los primeros dos son de tipo FEC, de 1/3 y 2/3 respectivamente. El primero consiste en repetir cada bit tres veces, interpretando el conjunto según el valor de la mayoría (2 de 3 por ejemplo). El segundo utiliza un generador polinomial para codificar una secuencia de 10 bits en una de 15 (código Hamming acortado [15,10]). El uso de estos dos sistemas hace posible corregir errores de bits sin tener que retransmitir el paquete. Sin embargo, si la carga útil no puede ser recuperada a pesar del uso de estos dos sistemas de corrección o si no se utilizó un FEC, entonces se utiliza un sistema ARQ (Automatic Retransmission request) para solicitar la retransmisión del paquete. La retransmisión se da hasta que se recibe un reconocimiento positivo o se excede el límite de tiempo, en cuyo caso el sistema Bluetooth desecha el paquete y continúa con el siguiente. Control de flujo.

El protocolo de la banda base recomienda el uso de colas FIFO (First In, First Out) en enlaces ACL y SCO tanto para transmisión como para recepción. El administrador de enlace llena estas colas y el controlador de enlace las vacía automáticamente. Si estas colas de recepción están llenas, se utiliza el control de flujo para evitar la pérdida de paquetes y la congestión. Si no se pueden recibir datos, una indicación de paro (stop) es transmitida, insertada por el administrador de enlace del dispositivo receptor en el encabezado del paquete de respuesta. Cuando el dispositivo transmisor recibe esta indicación congela sus colas FIFO. Si el dispositivo receptor está liso envía un paquete de continuación (go) que reanuda el flujo.



Sincronización. La temporización promedio de transmisión de paquetes del maestro no debe variar a más de 20 ppm en relación a la temporización de la ranura ideal, es decir 625 µs. La fluctuación de la temporización promedio debe ser menor a 1 µs. La piconet es sincronizada por el reloj del sistema del maestro. Para transmitir en la piconet son necesarios tres datos: la secuencia de salto de canal (derivada de la BD_ADDR del maestro), la fase de la secuencia (derivada del reloj del sistema del maestro) y el CAC (derivado de la BD_ADDR del maestro). Los esclavos adaptan sus relojes nativos con un offset de temporización (timing offset) para igualar el reloj del maestro, proporcionándoles un valor estimado del reloj. Obviamente, este offset es nulo para el maestro. El bit menos significativo o LSB (Least Significant Bit) de los relojes Bluetooth debe avanzar en unidades de 312.5 µs, lo que implica una frecuencia de reloj de 3.2 KHz. Se permite una ventana de incertidumbre alrededor del tiempo exacto de recepción de 20 µs, lo que permite al receptor buscar el CAC correcto y sincronizarse con el transmisor. Cuando un esclavo regresa del modo de retención, puede utilizar una ventana de incertidumbre mayor hasta que no se traslapen las ranuras. Un esclavo aparcado realiza una exploración periódica para detectar mensajes del maestro y resincronizar el offset de su reloj.

Además de estas importantes funciones, la capa de la banda base es responsable de otros aspectos, incluyendo el procedimiento de aleatorización de datos a través de un sistema conocido como “Data Whitening” y la codificación de la información de audio para su transmisión en enlaces Bluetooth. II.1.3.3.2.- LMP. El Protocolo de Administración de Enlace o LMP (Link Manager Protocol) es responsable de establecer y mantener los enlaces ACL y SCO, así como establecer, administrar y terminar las conexiones entre diferentes dispositivos. El LMP provee un mecanismo para que los administradores de enlace (LMs) en dispositivos separados intercambien mensajes que contienen información de administración de enlace. Estos mensajes son enviados como unidades de datos de protocolo o PDUs (Protocol Data Units) del LMP y son transportados en la carga útil de paquetes de una sola ranura (por lo general DM1, excepto cuando un enlace SCO está usando paquetes HV1 y el contenido es menor a 9 bytes, en cuyo caso se usan paquetes DV) transmitidos en el canal lógico LM. Las PDUs del LMP tienen una prioridad muy alta, por lo que pueden ser transmitidas durante ranuras de tiempo reservadas para un enlace SCO. La PDU contiene tres campos:

1. Identificación de transacción (1 bit): Especifica si la transacción de administración de enlace fue iniciada por el maestro (0) o por el esclavo (1).

2. Código de operación (7 bits): También conocido como opcode, identifica la PDU y proporciona información sobre su carga útil.

3. Carga útil: Contiene la información necesaria para administrar el enlace.



Una buena parte de las PDUs utiliza una dinámica de solicitud (request) y respuesta (response). Algunas deben estar soportadas obligatoriamente, mientras que otras sólo de manera opcional. A continuación se presenta una breve lista de los tipos de PDUs disponibles y su función:

Respuesta General. LMP_Accepted / LMP_Not_Accepted (obligatorias) Estas PDUs son utilizadas como mensajes de respuesta a otras PDUs en diferentes procedimientos, por lo que contienen el opcode del mensaje al que responden. LMP_Accepted corresponde a una respuesta afirmativa mientras que LMP_Not_Accepted corresponde a una respuesta negativa. Autentificación.

LMP_Au_Rand / LMP_Sres (obligatorias) El procedimiento de autentificación está basado en un esquema de desafío/respuesta. El verificador envía al pretendiente una PDU de tipo LMP_Au_Rand que contiene un número aleatorio de 128 bits, el cual constituye el desafío. El pretendiente calcula una respuesta, que es función de su BD_ADDR, el desafío y una clave secreta. La respuesta es enviada al verificador, el cual evalúa si es correcta o no. El cálculo exitoso de la respuesta de autentificación requiere que dos dispositivos compartan una clave secreta. Al final de esta transacción, el verificador y el pretendiente pueden intercambiar papeles para autentificar el enlace en el sentido opuesto. Tanto el maestro como el esclavo pueden ser verificadores. Emparejamiento.

LMP_In_Rand / LMP_Au_Rand / LMP_Sres / LMP_Comb_Key / LMP_Unit_Key (obligatorias) Cuando dos dispositivos carecen de una clave de enlace común, se crea una clave de inicialización o Kinit basada en un PIN (Personal Identification Number) y un número aleatorio. Una vez que ambos dispositivos han calculado dicha clave, se crea la clave de enlace y finalmente se realiza una autentificación mutua. El procedimiento de emparejamiento comienza con el envío de LMP_In_Rand por uno de los dispositivos. Cambio de clave de enlace.

LMP_Comb_Key (obligatoria) Si la clave de enlace deriva de claves de combinación y la clave de enlace actual es la clave de enlace semi-permanente, la clave de enlace puede ser cambiada. Si la clave de enlace es una clave de unidad, las unidades deben pasar por el procedimiento de emparejamiento para cambiar la clave de enlace. El contenido de LMP_Comb_Key está protegido por una XOR bit a bit con la clave de enlace actual.



Cambio de clave de enlace actual. LMP_Temp_Rand / LMP_Temp_Key / LMP_Use_Semi_Permanent_Key (obligatorias) La clave de enlace actual puede ser una clave semi-permanente o una clave temporal. Puede ser cambiada temporalmente, pero el cambio es válido sólo durante la sesión. Para que la piconet soporte difusiones encriptadas es necesario el cambio a una clave de enlace temporal. Encriptación.

LMP_Encryption_Mode_Req / LMP_Encryption_Key_Size_Req / LMP_Start_Encryption_Req / LMP_Stop_Encryption_Req (opcionales) Si al menos una autentificación ha sido realizada, es posible utilizar la encriptación. Esta transacción inicia con el envío de LMP_Encryption_Mode_Req con el propósito de determinar el modo de encriptación, ya sea aplicada solamente a un enlace punto a punto o también a paquetes difundidos. Si la solicitud es aceptada, los dispositivos negocian el tamaño de la clave de encriptación a utilizar, intercambiando PDUs de tipo LMP_Encryption_Key_Size_Req. Una vez determinado el tamaño de la clave, los dispositivos comienzan el proceso de encriptación enviando LMP_Start_Encryption_Req; para detenerla se usa LMP_Stop_Encryption_Req. Si el maestro requiere que todos los esclavos en la piconet usen los mismos parámetros de encriptación, debe emitir una clave temporal o Kmaster y convertirla en la clave de enlace actual para todos los esclavos de la piconet antes de iniciar la encriptación. Esto es necesario si los paquetes difundidos debieran estar encriptados. Solicitud del offset del reloj.

LMP_Clkoffset_Req / LMP_Clkoffset_Res (obligatorias) Cuando un esclavo recibe el paquete FHS se calcula la diferencia entre su propio reloj y el del maestro. El offset del reloj (clock offset) también es actualizado cada vez que se recibe un paquete del maestro. El maestro puede solicitar este offset del reloj en cualquier momento durante la conexión. Al guardar este offset del reloj, el maestro sabe en qué canal atenderá el esclavo un nuevo llamado tras haber dejado la piconet, lo que puede ser usado para disminuir el tiempo de llamado. Solicitud del offset de la ranura de tiempo.

LMP_Slot_Offset (opcional) Con LMP_Slot_Offset, la información acerca de la diferencia entre los límites de las ranuras en diferentes piconets es transmitido. Esta PDU transporta a su vez la BD_ADDR del maestro de otra piconet. El offset de la ranura de tiempo (slot offset) es calculado como la diferencia entre el tiempo (µs) del inicio de la ranura de transmisión del maestro de la piconet en la que se transmite la PDU y aquel del dispositivo apuntado por la PDU, modulo 1250. Antes de realizar un intercambio del papel maestro/esclavo, esta PDU deberá ser transmitida por el dispositivo que se convertirá en maestro. La PDU también puede ser útil en comunicaciones entre piconets.



Solicitud de información sobre la exactitud de la temporización. LMP_Timing_Accuracy_Req / LMP_Timing_Accuracy_Res (opcionales) El LMP soporta solicitudes sobre la exactitud de la temporización, información que puede ser utilizada para minimizar la ventana de exploración al regresar del modo de retención, así como para extender el máximo período de reserva. También puede ser utilizada para minimizar la ventana de exploración al buscar las ranuras del modo de olfateo o los paquetes baliza (beacon packets) del modo de aparcamiento. Los parámetros de exactitud de la temporización son fijos para cada dispositivo. Versión del LMP.

LMP_Version_Req / LMP_Version_Res (obligatorias) La capa LMP soporta solicitudes sobre la versión del protocolo del LM. El dispositivo encuestado enviará una respuesta con tres parámetros: VersNr, Compld y Sub-VersNr. VersNr indica la versión de la especificación del LMP de Bluetooth que soporta el dispositivo. Compld es usado para rastrear posibles problemas con las capas inferiores de Bluetooth, por lo que todas las compañías que generen una implementación única del LM deberán tener su propio Compld. La misma compañía es a su vez responsable de la administración y mantenimiento del Sub-VersNr; se recomienda que cada compañía tenga un único Sub-VersNr para cada implementación de radiofrecuencia, banda base y LM. Características soportadas.

LMP_Features_Req / LMP_Features_Res (obligatorias) Cuando un dispositivo desea conocer las características soportadas por el LM de otro dispositivo, envía LMP_Features_Req; además de solicitar una lista de dichas características, esta PDU puede contener información acerca de las características opcionales soportadas por el dispositivo local. Cuando el dispositivo remoto recibe esta solicitud, envía LMP_Features_Res al dispositivo local, informándole así sobre las características opcionales que soporta. Un dispositivo no podrá enviar otros paquetes además de ID, FHS, NULL, POLL, DM1 y DH1 antes de conocer las características soportadas por el otro dispositivo. Después de que la solicitud de características ha sido llevada a cabo, la intersección los paquetes soportados por ambos dispositivos también podrá ser transmitida. Siempre que se haga una solicitud tendrá que ser compatible con las características soportadas por el otro dispositivo. Intercambio del papel maestro/esclavo.

LMP_Switch_Req / LMP_Slott_Offset (opcionales) Puesto que el dispositivo que inicia las comunicaciones siempre se convierte en el maestro, a veces es necesario un intercambio en el papel maestro/esclavo. El dispositivo que inicia el intercambio finaliza la transmisión del mensaje L2CAP actual y entonces envía LMP_Switch_Req. De ser el esclavo el que inicia el intercambio, deberá enviar LMP_Slot_Offset antes de LMP_Switch_Req; en caso de que el intercambio sea iniciado por el maestro, éste enviará LMP_Switch_Req antes de recibir LMP_Slot_Offset. Si el intercambio es aceptado, el otro dispositivo finalizará la transmisión del mensaje L2CAP actual y responderá con LMP_Accepted.



Solicitud de nombre. LMP_Name_Req / LMP_Name_Res (obligatorias) El LMP soporta solicitudes de nombre a otros dispositivos Bluetooth. Este es un nombre amigable al usuario asociado con el dispositivo Bluetooth y consiste de un máximo de 248 bytes codificados de acuerdo al estándar UTF-8. El nombre está fragmentado en uno o varios paquetes DM1. Separación.

LMP_Detach (obligatoria) La conexión entre dos dispositivos Bluetooth puede cerrarse en cualquier momento tanto por el maestro como por el esclavo. La PDU LMP_Detach no puede ser rechazada y el enlace es finalizado inmediatamente. Un parámetro conocido como razón es incluido en el mensaje para informar a la otra parte el porque de la cancelación de la conexión. Modo de retención.

LMP_Hold / LMP_Hold_Req (opcionales) El enlace ACL de una conexión entre dos dispositivos Bluetooth puede ser puesto en modo de retención por un período determinado. El maestro puede forzar a un esclavo a entrar en el modo de retención enviando LMP_Hold. Alternativamente, el esclavo puede entrar en este modo, ya sea por solicitud del maestro o propia, mediante el envío de LMP_Hold_Req. Las actividades realizadas por un dispositivo durante el período de reserva no son determinadas por este mensaje, sino por el propio dispositivo. Modo de olfateo.

LMP_Sniff / LMP_Sniff_Req / LMP_Unsniff_Req (opcionales) El maestro puede forzar a un esclavo a entrar en el modo de olfateo enviando LMP_Sniff. Alternativamente, el esclavo puede entrar en este modo, ya sea por solicitud del maestro o propia, mediante el envío de LMP_Sniff_Req. La operación inversa se logra con LMP_Unsniff_Req. Modo de aparcamiento.

LMP_Park_Req / LMP_Unpark_PM_ADDR_Req / LMP_Unpark_BD_ADDR_Req / LMP_Set_Broadcast_Scan_Window / LMP_Modify_Beacon (opcionales) Todos las PDUs enviadas del maestro a los esclavos aparcados son difundidas. Estas PDUs son las únicas que pueden ser enviadas a un esclavo aparcado y las únicas que pueden transmitirse por difusión. El esclavo puede entrar en este modo, ya sea por solicitud del maestro o propia, mediante el envío de LMP_Park_Req. En el instante baliza, el maestro puede activar nuevamente al esclavo aparcado o permitir a los esclavos aparcados solicitar acceso al canal (LMP_Unpark_PM_ADDR_Req / LMP_Unpark_BD_ADDR_Req), modificar los parámetros del modo de aparcamiento



(LMP_Modify_Beacon) y transmitir información sobre la difusión (LMP_Set_Broadcast_Scan_Window). Control de Potencia.

LMP_Incr_Power_Req / LMP_Decr_Power_Req / LMP_Max_Power / LMP_Min_Power (opcionales) Si el RSSI difiere demasiado del valor óptimo de un dispositivo Bluetooth, éste puede solicitar un incremento o decremento de la potencia de transmisión del otro dispositivo. Al recibir este mensaje, la potencia de transmisión es variada un nivel. La potencia de transmisión de un maestro es completamente independiente para varios esclavos, por lo que la solicitud de un esclavo sólo afectará la potencia de la transmisión del maestro para ese esclavo en particular. Las solicitudes de ajuste de potencia pueden realizarse en cualquier momento posterior a un procedimiento de llamado de la banda base exitoso. La presencia del soporte para solicitudes de control de potencia es indicada en la lista de características soportadas. Cambio de canal según la calidad.

LMP_Auto_Rate / LMP_Preferred_Rate (opcionales) El rendimiento de la transmisión de datos para un tipo de paquete dado depende de la calidad del canal de radiofrecuencia (DM o DH). Las mediciones de calidad en el receptor de un dispositivo pueden ser utilizadas para controlar dinámicamente el tipo de paquete transmitido desde el dispositivo remoto para optimizar el rendimiento. Si un dispositivo desea que el dispositivo remoto tenga este control, le enviará LMP_Auto_Rate una vez. El dispositivo remoto puede entonces enviarle LMP_Preferred_Rate cuando desee que éste cambie el tipo de paquete que transmite. Esta PDU tiene un parámetro que determina la codificación preferida (con o sin FEC de 2/3) y el tamaño preferido (en ranuras de tiempo) de los paquetes. El dispositivo que reciba esta PDU no esta obligado a cambiar al tipo de paquete especificado y no podrá enviar un paquete que exceda el número máximo de ranuras permitido aún si el tamaño preferido es mayor. Calidad del servicio.

LMP_Quality_Of_Service / LMP_Quality_Of_Service_Req (obligatorias) El LM provee capacidades relacionadas con la calidad del servicio. Un intervalo de encuesta, definido como el máximo tiempo entre transmisiones subsecuentes del maestro a un esclavo en particular, es usado para soportar la asignación del ancho de banda y el control de la latencia. Adicionalmente, maestro y esclavo negocian el número de repeticiones para paquetes difundidos. Enlaces SCO.

LMP_SCO_Link_Req / LMP_Remove_SCO_Link_Req (opcionales) Cuando una conexión ha sido establecida entre dos dispositivos Bluetooth, esta consiste de un enlace ACL. Uno o más enlaces SCO pueden ser establecidos. El enlace SCO



reserva ranuras separadas por el intervalo SCO o TSCO. La primera ranura reservada para el enlace SCO es definida por TSCO y el retraso SCO o DSCO. Posteriormente, las ranuras SCO se suceden periódicamente según el intervalo SCO. Cada enlace SCO se distingue de los demás por un apuntador SCO. Control de paquetes multi-ranura.

LMP_Max_Slot / LMP_Max_Slot_Req (obligatorias) El número de ranuras utilizadas por un dispositivo puede ser limitado. Un dispositivo permite al dispositivo remoto usar un número máximo de ranuras al enviar la PDU LMP_Max_Slot, indicando el parámetro max slots. Cada dispositivo puede solicitar el uso del máximo número de ranuras enviando la PDU LMP_Max_Slot_Req, indicando el parámetro max slots. Tras una nueva conexión el valor asumido por defecto es una ranura. Las PDUs usadas para el control de paquetes multi-ranura pueden ser enviadas en cualquier momento posterior a la configuración de la conexión. Esquema de llamado.

LMP_Page_Mode_Req / LMP_Page_Scan_Mode_Req (opcionales) Además del esquema de llamado obligatorio, el sistema Bluetooth define esquemas de llamado opcionales. El LMP provee medios para negociar el esquema de llamado que será utilizado la próxima vez que una unidad sea llamada. Supervisión del enlace.

LMP_Supervision_Timeout (obligatorias) Cada enlace Bluetooth posee un cronómetro que es usado para su supervisión. Ésta información es utilizada para detectar pérdidas de enlace causadas por el movimiento de dispositivos fuera del rango de comunicación, una baja en la energía del dispositivo u otras causas de falla similares. Se emplea un procedimiento de LMP para establecer el valor de interrupción de la supervisión. Establecimiento de la conexión.

LMP_Host_Connection_Req / LMP_Setup_Complete (obligatorias) Cuando el dispositivo que efectúa el llamado desea crear una conexión que involucre capas superiores al LM, envía LMP_Host_Connection_Req. Cuando el otro dispositivo recibe este mensaje, el anfitrión es informado sobre la conexión entrante. El dispositivo remoto puede aceptar o rechazar la solicitud de conexión enviando una PDU de respuesta general. Si la solicitud es aceptada, los procedimientos de seguridad del LMP (emparejamiento, autentificación y encriptación) pueden ser invocados. Una vez finalizados los procedimientos de seguridad, el dispositivo envía LMP_Setup_Complete. Cuando ambos dispositivos han enviado esta PDU, el primer paquete correspondiente a un canal lógico diferente del LMP puede ser transmitido.



Modo de prueba. LMP_Test_Activate / LMP_Test_Control (obligatorias) El LMP posee PDUs para soportar diferentes modos de prueba, que son utilizados para certificación y análisis de compatibilidad del radio y la banda base. Manejo de errores.

LMP_Not_Accepted (obligatorias) Si el LM recibe una PDU con un opcode no reconocido, responde con LMP_Not_Accepted con el código de razón unknown LMP PDU. A su vez se reenvía el opcode no reconocido. Si el LM recibe una PDU con parámetros no válidos, responde con LMP_Not_Accepted con el código de razón invalid LMP parameters. Si el tiempo de respuesta máximo es excedido o si se detecta una pérdida de enlace el dispositivo que espera la respuesta llegará a la conclusión de que el procedimiento fue finalizado de manera no exitosa. Los mensajes erróneos del LMP pueden ser causados por errores en el canal o errores sistemáticos en la transmisión. Para detectar éstos últimos, el LM deberá supervisar el número de mensajes erróneos y desconectarse si éste excede un cierto umbral, el cual depende de la implementación.

Aunque no todas las transacciones de administración de enlace definidas en la especificación son obligatorias, el LM de cada dispositivo Bluetooth debe ser capaz de reconocer y responder a cada una de ellas. II.1.3.3.3.- HCI. La Interfaz de Control del Anfitrión o HCI (Host Controller Interface) provee una interfaz de mando para el controlador de la banda base y el LM, así como acceso a información del hardware y a los registros de control. En esencia, esta interfaz provee un método uniforme de acceso a las capacidades de la banda base de Bluetooth. La HCI existe a través de tres secciones: el anfitrión (host), la capa de transporte (transport layer) y el controlador del anfitrión o HC (Host Controller).

Entidades funcionales. La HCI está compuesta funcionalmente de tres partes:

• Firmware: Está localizada en el HC, es decir en el hardware Bluetooth. El Firmware implementa los comandos de la HCI dirigidos al hardware mediante comandos de la banda base, comandos del LM, registros de status del hardware, registros de control y registros de eventos.

• Controlador (Driver): Está localizado en el anfitrión, es decir en la entidad de software. El anfitrión recibirá notificaciones asíncronas de eventos de la HCI. Al descubrir que un evento ha ocurrido, analiza el paquete asociado para determinar su naturaleza.

• Capa de transporte del HC: La comunicación entre el firmware y el controlador



se da por medio de esta capa, que corresponde a la definición de varias capas que pueden existir entre ambos. Dichas capas intermedias deben permitir la transferencia de datos sin necesidad de un conocimiento detallado sobre estos. Se pueden usar varias capas de transporte del HC, de las cuales tres han sido definidas inicialmente para Bluetooth: USB (Universal Serial Bus), UART (Universal Asynchronous Receiver-Transmitter) y RS232. Las notificaciones de eventos de la HCI al anfitrión deberán ser independientes de la capa de transporte del HC utilizada.

Comandos.

La HCI provee un método uniforme de mando para acceder a las capacidades del hardware Bluetooth. Los comandos de enlace de la HCI dan al anfitrión la habilidad de controlar las conexiones con otros dispositivos al nivel de la capa de enlace. Estos comandos normalmente implican el intercambio de comandos del LMP con dispositivos remotos. Los comandos de política de la HCI son usados para modificar el comportamiento del LM local y del remoto, ofreciendo al anfitrión métodos para influenciar la manera en que el LM administra la piconet. Los comandos del HC, de la banda base, los informativos y los de status dan al anfitrión acceso a varios registros en el HC. Intercambio de información específica de la HCI. La capa de transporte del HC permite el intercambio transparente de información específica de la HCI. Estos mecanismos de transporte dan al anfitrión la habilidad de enviar comandos al HC, así como recibir notificaciones de eventos por parte del HC. También permiten el intercambio de datos de ambos tipos de enlace (ACL y SCO) entre el anfitrión y el HC. La especificación de la HCI determina el formato de estas operaciones. Comandos de control de enlace. Estos comandos permiten al HC controlar las conexiones con otros dispositivos. Cuando son utilizados, el LM controla la manera en que las piconets y scatternets son establecidas y mantenidas. Estos comandos instruyen al LM para crear y modificar conexiones al nivel de capa de enlace con dispositivos remotos, realizar encuestas a dispositivos dentro del rango de alcance y otros comandos del LMP.

Comandos de política de enlace. Estos comandos proveen métodos para que el anfitrión influya en la manera en que el LM administra la piconet. Al ser usados, el LM aún controla la manera en que las piconets y scatternets son establecidas y mantenidas, pero su acción depende de parámetros de política ajustables. Estos comandos modifican el comportamiento del LM, lo que puede resultar en cambios en las conexiones al nivel de capa de enlace con dispositivos remotos.



Comandos del HC y la banda base. Estos comandos proveen acceso y control a varias capacidades del hardware Bluetooth. Estos parámetros permiten el control de los dispositivos Bluetooth y de las funciones del HC, el LM y la banda base. El anfitrión puede usar estos comandos para modificar el comportamiento del dispositivo local. Parámetros informativos. Estos parámetros son fijados por el fabricante del hardware Bluetooth y proporcionan información sobre el dispositivo y las capacidades del HC, el LM y la banda base. El anfitrión no puede modificar estos parámetros. Parámetros de status. El HC modifica todos los parámetros de status. Estos parámetros proporcionan información sobre el estado actual del HC, del LM y la banda base. El anfitrión no puede modificar estos parámetros más que para reinicializar ciertos parámetros específicos. Comandos de prueba. Estos comandos son utilizados para proveer la habilidad de probar varias funciones del hardware Bluetooth. A su vez, permiten configurar varias condiciones de prueba. Eventos, códigos de error y control de flujo.

Control de flujo. El control de flujo es usado por el anfitrión para dirigir al HC, con el fin de evitar que se saturen sus buffers de datos con información de enlace ACL destinada a un dispositivo remoto que no responde. De hecho es el anfitrión quien controla los buffers de datos del HC. Eventos. Un cierto número de eventos están definidos para la capa de la HCI. Estos proveen un método para reportar parámetros y datos asociados con cada evento. Se han implementado hasta ahora 32 eventos distintos, desde el evento de encuesta completada (inquiry complete) hasta el evento de cambio del modo de repetición de exploración de llamado (page scan repetition mode change). Códigos de error. Un gran número de códigos de error han sido definidos para la capa de la HCI. Cuando un comando falla, se devuelven códigos de error para indicar la razón de la falla. Se han implementado hasta ahora 35 códigos de error distintos, desde el comando de la HCI desconocido (unknown HCI command) hasta PDU del LMP no permitida (LMP PDU not allowed).



Capas de transporte del HC definidas para Bluetooth. UART. El objetivo de la capa de transporte UART de la HCI es hacer posible el uso de la HCI de Bluetooth en una interfaz serial entre dos UARTS en la misma PCB (Printed Circuit Board). Dicha capa asume que la comunicación de la UART no presenta errores de línea. Paquetes tanto de eventos como de datos fluyen a través de esta capa, aunque sin ser decodificados por ella. RS232. El objetivo de la capa de transporte RS232 de la HCI es hacer posible el uso de la HCI de Bluetooth en una interfaz RS232 física entre el anfitrión y el HC. Paquetes tanto de eventos como de datos fluyen a través de esta capa, aunque sin ser decodificados por ella. USB. El objetivo de la capa de transporte USB de la HCI es utilizar una interfaz de hardware USB para un dispositivo Bluetooth. Se utiliza un código de clase específico para todos los dispositivos USB de Bluetooth. Esto permite la carga de la pila de controladores (driver stack) correcta, independientemente del fabricante. También permite que los comandos de la HCI sean diferenciados de los inherentes al USB a través de la terminal de control.

II.1.3.3.4.- L2CAP. El Protocolo de Control y Adaptación Lógica del Enlace o L2CAP (Logical Link Control and Adaptation Protocol) se encuentra sobre el protocolo de la banda base y reside en la capa del enlace de datos. El L2CAP sirve para aislar los protocolos de capas superiores (incluyendo protocolos no específicos de Bluetooth) de los protocolos de transporte de capas inferiores. El L2CAP proporciona servicios de datos, ya sea orientados a conexión o no, a protocolos de capas superiores que posean capacidades de multiplexación de protocolos, operación de segmentación y reensamble, así como abstracciones de grupo. El L2CAP permite a los protocolos de nivel superior y a las aplicaciones transmitir y recibir paquetes de datos de hasta 64 KB. Este protocolo está definido sólo para los enlaces ACL y hasta el momento no se planea que soporte enlaces SCO.

Requisitos funcionales. El L2CAP soporta varios requisitos importantes de otros protocolos: Multiplexación de protocolos. El L2CAP debe soportar la multiplexación de protocolos ya que el protocolo de la banda base no considera ningún campo TYPE para identificar el protocolo de capa superior que esta siendo multiplexado sobre él. El L2CAP debe ser capaz de distinguir protocolos de capas superiores (como el SDP y el RFCOMM).



Segmentación y reensamble. En comparación con otros medios físicos alámbricos, los paquetes de datos definidos por el protocolo de la banda base tienen un tamaño restringido. El exportar una máxima unidad de transmisión o MTU (Maximum Transmission Unit) asociada con la mayor carga útil de la banda base (341 bytes para paquetes DH5) limita el uso eficiente del ancho de banda para protocolos de capas superiores que están diseñados para usar paquetes más grandes. Dichos paquetes deben ser segmentados en varios paquetes más pequeños de la banda base antes de su transmisión. De manera similar, varios paquetes recibidos de la banda base pueden ser reensamblados en un sólo paquete más grande tras una simple comprobación de integridad. La funcionalidad de segmentación y reensamble o SAR (Segmentation and Reassembly) es absolutamente necesaria para soportar protocolos que utilizan paquetes más grandes que los de la banda base. Calidad del servicio. El proceso de establecimiento de conexión del L2CAP permite intercambiar información referente a la calidad del servicio o QoS (Quality of Service) esperada entre dos unidades Bluetooth. Cada implementación del L2CAP debe supervisar los recursos utilizados por el protocolo y garantizar que los acuerdos sobre la QoS sean respetados. Grupos. Varios protocolos incluyen el concepto de un grupo de direcciones. El protocolo de la banda base lo utiliza en las piconets. La abstracción de grupo del protocolo L2CAP permite a las implementaciones mapear eficientemente grupos de protocolos en las piconets. Sin una abstracción de grupo, los protocolos de niveles superiores necesitarían ser expuestos al protocolo de la banda base y a la funcionalidad del LM para administrar grupos eficientemente. Operación general.

PDUs del L2CAP. Los mensajes de esta capa son enviados como PDUs del L2CAP, las cuales son transportadas en paquetes de enlace ACL en el canal lógico asíncrono. Debido a que estas PDUs pueden ser transportadas en paquetes multi-ranura, el campo L_CH del encabezado de carga útil de los paquetes de enlace ACL es usado para indicar si el paquete actual es el inicio (valor L_CH de 10) o la continuación (valor L_CH de 01) de una PDU del L2CAP. La capa del L2CAP no garantiza por si misma la transmisión confiable de las PDUs. Se asume que la función de retransmisión de paquetes provista por la banda base es suficiente para asegurar un canal de comunicación confiable. Canales. Toda comunicación entre capas del L2CAP en diferentes dispositivos ocurre a través de enlaces lógicos denominados canales. Estos canales son identificados por las dos terminales (una en cada dispositivo) del enlace. A cada terminal se le asigna un identificador de canal o CID (Channel Identifiers) único de 16 bits. Los CIDs son asignados localmente, es decir que a la terminal local de un dispositivo en particular le



es asignado su CID por la capa del L2CAP del mismo dispositivo. A su vez, estas terminales están asociadas de manera exclusiva con algún destinatario (por ejemplo un protocolo de capa superior), al cual va dirigida la carga útil de la PDU del L2CAP. Las implementaciones son libres de administrar los CIDs como mejor les convenga, con la condición de que ningún CID sea reutilizado como una terminal local para múltiples canales L2CAP simultáneos entre el dispositivo local y un dispositivo remoto. La asignación de los CIDs es relativa a cada dispositivo; un dispositivo puede asignar CIDs independientemente de otros, con la excepción de ciertos CIDs reservados para canales específicos. A continuación se presenta una tabla con las definiciones de los CIDs del L2CAP:

CID hex Descripción0000 Identificador nulo (NULL)0001 Canal de señalamiento 0002 Canal de recepción CL

0003-003F Reservado0040-FFFF Dinámicamente asignado

Tabla5 II.1.3.3.4: Definiciones de los CIDs del L2CAP. La especificación de Bluetooth define tres tipos de canales del L2CAP:

1. Canal orientado a conexión o CO (Connection-oriented): Este es un canal persistente que soporta comunicación bidireccional punto a punto y requiere el intercambio de información de señalización entre el dispositivo local y el remoto para poder ser establecido, configurado o terminado. En este canal se asigna dinámicamente un CID único a cada terminal.

2. Canal no orientado a conexión o CL (Connectionless):

Este es un canal no persistente que soporta comunicación unidireccional punto a multipunto y se usa típicamente para mensajes difundidos. Si un dispositivo desea responder a una transmisión del L2CAP hecha en un canal CL, deberá utilizar otro canal. Adicionalmente, los canales CL permiten a la capa del L2CAP proporcionar servicios de multiplexación de protocolos. Un sólo CID es asignado dinámicamente para todo tráfico saliente de datos CL y está usualmente conectado a varios dispositivos que juntos forman un grupo lógico. A su vez, existe un canal reservado para todo tráfico entrante de datos CL, llamado canal de recepción CL. Debido a que este tipo de canal prescinde de conexión y no necesita ser configurado, toda la información de configuración proveniente de canales de niveles superiores es pasada como parte del paquete de datos.

3. Canal de señalización (signaling channel):

Este canal es muy similar al CO, excepto que su CID, así como otros parámetros de canal, son fijos, por lo que no es necesario el intercambio de información de señalización para establecerlo. De hecho, este canal es usado precisamente para intercambiar este tipo de información, con el fin de crear y establecer canales CO, así como para negociar cambios en sus características (siendo los parámetros de QoS los más importantes) e incluso terminarlos.



La siguiente figura ilustra un ejemplo de comunicación a través de canales del L2CAP entre tres dispositivos:

13Figura II.1.3.3.4: Canales del L2CAP entre tres dispositivos diferentes.II

Nótese que cada una de las terminales en las entidades L2CAP tiene asociados de manera exclusiva un CID y una aplicación externa al protocolo. Operación entre capas. Las implementaciones del L2CAP siguen la arquitectura general descrita a continuación:

• Las implementaciones deben transferir datos entre protocolos de capas superiores y los protocolos de las capas inferiores.

• Cada implementación debe soportar un conjunto de comandos de señalización

(signaling commands) para su uso entre ellas.

• Las implementaciones deben estar preparadas para aceptar ciertos tipos de eventos de las capas inferiores y generar eventos para las capas superiores; la manera en que dichos eventos son transferidos entre capas es un proceso que depende de la implementación.

Operaciones SAR. Las operaciones SAR son usadas para mejorar la eficiencia al soportar un tamaño de MTU mayor que el paquete más grande de la banda base. Esto reduce la tara (overhead)1 al diseminar los paquetes usados por protocolos de capas superiores en varios paquetes de la banda base. Todos los paquetes del L2CAP pueden ser

1 Conjunto de bits que no llevan información de usuario pero son necesarios para efectos de sincronización, control de errores, etc. pudiendo consumir una parte importante de la capacidad de canal.



segmentados para su transferencia en paquetes de la banda base. El protocolo en sí no realiza operaciones SAR, pero el formato de los paquetes soporta su adaptación a armazones físicos de menor tamaño. El protocolo simplemente proporciona información sobre la longitud de los paquetes a los protocolos de capas superiores, permitiéndoles segmentar o reensamblar los paquetes intercambiados con la capa del L2CAP. En el dispositivo transmisor los paquetes son segmentados, para posteriormente ser reensamblados por el dispositivo receptor. Otras características.

Formato de los paquetes de datos. El L2CAP está basado en paquetes, aunque de sigue un modelo de comunicación basado en canales. Todos los campos de los paquetes usan el esquema Little Endian1. Señalización. Varios comandos de señalización pueden ser intercambiados entre dos entidades L2CAP en dispositivos remotos. Todos son enviados al CID 0x0001 (el canal de señalización). La implementación del L2CAP debe ser capaz de determinar la BD_ADDR del dispositivo que envió los comandos. Múltiples comandos pueden ser enviados en un solo paquete del L2CAP. El intercambio de información de señalización ocupa un mecanismo de solicitud y respuesta. Los comandos de señalización usados para efectuar transacciones relacionada a enlaces CO son:

• Establecimiento: L2CAP_Connection_Req / L2CAP_Connection_Res • Configuración: L2CAP_Configuration_Req / L2CAP_ Configuration _Res

• Terminación: L2CAP_Disconnection_Req / L2CAP_Disconnection_Res

Existen comandos adicionales de señalización definidos en la especificación; sin embargo estos son los más relevantes. Opciones de los parámetros de configuración. Estas opciones son un mecanismo para extender la habilidad de negociar diferentes requisitos de conexión. Las opciones son transmitidas como elementos de información que comprenden un tipo de opción (option type), una longitud de opción (option length) y uno o más campos de datos de opción (option data fields). Primitivas de servicio. Varios servicios son ofrecidos por el L2CAP en términos de primitivas (unidades básicas de instrucción de máquina) y parámetros. La interfaz de servicio es requerida para realizar pruebas. Se incluyen primitivas para:

• Conexión: organizar (setup) / configurar / desconectar 1 El byte de menor peso es almacenado en la dirección más baja y el byte de mayor peso en la más alta.



• Datos: leer / escribir

• Grupo: crear / cerrar / agregar miembro / eliminar miembro /obtener membresía

• Información: ping1 / obtener info / solicitar una notificación (callback) al

ocurrir un evento

• Trafico CL: habilitar / deshabilitar II.1.3.3.5.- SDP. El Protocolo de Descubrimiento de Servicios o SDP (Service Discovery Protocol) provee medios a las aplicaciones para conocer los servicios disponibles y sus características. Un SDP específico es necesario en el ambiente Bluetooth ya que el conjunto de servicios disponibles cambia dinámicamente según la proximidad de los dispositivos en movimiento (redes ad-hoc), lo que marca una diferencia importante con respecto al descubrimiento de servicios en ambientes basados en redes tradicionales (estáticas). El SDP definido en la especificación de Bluetooth está planeado según las características de este particular ambiente, permitiendo la actualización dinámica de los servicios disponibles. El SDP utiliza un modelo de cliente y servidor. Los clientes son dispositivos que buscan servicios, mientras que los servidores son aquellos que los proporcionan. Estos papeles son completamente intercambiables, es decir que cualquier dispositivo puede desempeñarse ya sea como cliente o servidor dependiendo de si está utilizando o prestando un servicio remoto. El SDP requiere que todos los dispositivos, en su papel de servidores, mantengan un registro con información sobre los servicios que ofrecen. Es importante resaltar que el SDP en sí no provee el servicio solicitado por el cliente: si el cliente desea conectarse al servicio, deberá utilizar otro protocolo para lograrlo.

Organización del protocolo. El SDP es un protocolo simple con requisitos de transporte subyacente mínimos. Este protocolo usa un modelo de solicitud y respuesta en el que cada transacción consiste en una PDU de cada tipo. Cuando el SDP es usado junto con el protocolo de transporte L2CAP, sólo una PDU de solicitud del SDP por conexión puede estar pendiente en un instante dado. En otras palabras, un cliente debe recibir una respuesta a cada solicitud antes de enviar una nueva a través de la misma conexión del L2CAP. Esto provee una forma simple de control de flujo. Formato de las PDUs. El descubrimiento de servicios es llevado a cabo a través de transacciones del SDP. La información de dichas transacciones es comunicada por medio de PDUs del SDP. Cada PDU del SDP consiste en un encabezado seguido de parámetros específicos. El encabezado contiene tres campos:

1. PDU ID: Este campo identifica el tipo de PDU, es decir su significado, así como los parámetros específicos.

2. TransactionID: Este campo identifica únicamente a las PDUs de solicitud y es

usado para hacer corresponder ambos tipos de PDUs. 1 Comando utilizado para verificar el estado de las conexiones.



3. ParameterLength: Este campo especifica la longitud en bytes de todos los parámetros contenidos en la PDU.

Además de varios parámetros específicos de cada PDU, se puede incluir uno de estado de continuación (descrito en el apartado siguiente). Respuestas parciales y estado de continuación (continuation state). Algunas solicitudes del SDP pueden requerir respuestas que son mayores que el tamaño mismo de la PDU. En ese caso, el servidor del SDP generará una respuesta parcial junto con un parámetro de estado de continuación. Este parámetro puede ser suministrado por el cliente en una solicitud subsecuente para recuperar la siguiente porción de la respuesta. Manejo de errores. Cada transacción consiste en una PDU de solicitud y una de respuesta. Generalmente cada tipo de PDU de solicitud tiene un tipo correspondiente de PDU de respuesta. Sin embargo, si el servidor determina que el formato de una solicitud es erróneo, o si por alguna razón no puede responder con el tipo apropiado de PDU, enviará una PDU de error (SDP_ErrorResponse).

Servicios del SDP.

Para que el descubrimiento de servicios funcione adecuadamente, es necesario que los servicios sean representados con un formato estándar que pueda ser utilizado tanto por el cliente como por el servidor. Para representar un servicio, el SDP utiliza un identificador universalmente único o UUID (Universally Uniqe Identifier), lo que implica la garantía de ser único en todo espacio y todo tiempo. Los UUIDs son valores de 128 bits que pueden ser creados independientemente y de manera distribuida. No se necesita un registro central de UUIDs asignados. Esta sección describe la manera en que las características individuales de diferentes dispositivos son almacenadas. Registro de servicio (service record). Un servicio es cualquier entidad que pueda proveer información, realizar una acción o controlar un recurso en representación de otra entidad. Un servicio puede ser implementado como software, hardware o una combinación de ambos. Toda la información concerniente a un servicio mantenido por un servidor del SDP es contenida dentro de un solo registro de servicio. A su vez, dicho registro consiste en una lista de atributos que describen características de un servicio. Atributo de servicio (service attribute). Cada atributo describe una sola característica del servicio. A continuación se presenta una lista de los atributos disponibles:

• Service Name.

• Service Description.

• Provider Name.

• Service Record Handle.



• Service Class ID List.

• Service Record State.

• Service ID.

• Protocol Description List.

• Browse Group List.

• Language Base Attribute ID List.

• Service Info Time to Live.

• Service Avaliability.

• Bluetooth Profile Descriptor List.

El SDP especifica dos tipos de atributo de servicio:

• Atributos de servicio universales: Estos pueden aplicarse a cualquier clase de servicio (por ejemplo de telefonía, impresión, acceso a LAN (Local Area Network), etc.).

• Atributos específicos de servicio: Estos tienen sentido sólo en el contexto de una

clase particular de servicio. Los atributos de servicio universales no son necesariamente obligatorios. De hecho, la especificación define solamente dos atributos universales que deben estar soportados:

• Service Class ID List: Este identifica la clase de servicio. • Service Record Handle: Este apunta al registro del servicio en cuestión.

Algunas definiciones de atributos son comunes a todos los registros de servicio, pero los proveedores de servicios también pueden definir sus propios atributos. Un atributo de servicio consta de dos componentes:

• ID de atributo: Se trata de un entero de 16 bits sin signo que distingue cada atributo de servicio de los demás dentro de un registro de servicio. A su vez, identifica la semántica del valor de atributo asociado.

• Valor de atributo: Este es un campo de longitud variable cuyo significado es

determinado por la ID de atributo asociada a él y por la clase de servicio del registro que contiene al atributo. En el SDP, un valor de atributo es representado como un elemento de datos.

Clase de servicio. Cada servicio corresponde a uno de los casos contenidos en una clase. La definición de clase de servicio provee a su vez las definiciones de todos los atributos contenidos en los registros de servicio que representan casos de una clase. Cada definición de atributo especifica el valor numérico de su ID, el uso planeado de su valor de atributo y su formato. Un registro de servicio contiene atributos que son específicos de una clase de servicio, así como atributos universales que son comunes a todos los servicios.



Los servicios genéricos descritos por la clase de servicio de un dispositivo son:

• Positioning (Identificación de posición). • Networking (LAN, ad-hoc, etc.).

• Rendering (Impresión, bocinas, etc.)

• Capturing (Scanner, micrófono, etc.)

• Object Transfer (v-Inbox, v-Folder, etc.)

• Audio (Bocinas, micrófonos, etc.)

• Telephony (Telefonía inalámbrica, módem, etc.)

• Information (servidores WEB, WAP, etc.)

Para dar a conocer los servicios genéricos que soporta un dispositivo Bluetooth, este incorpora en el encabezado de nivel de banda base de sus paquetes el campo Class of Device/Service, dentro del cual existe a su vez un apartado para identificar la clase del servicio. Dicho campo se compone de 24 bits, de los cuales 11 (del bit 23 al 13) corresponden al campo Service Class. La siguiente figura ilustra el mapeo del campo Class of Device/Service:

14Figura II.1.3.3.5: Mapeo del campo Class of Device/Service.VIII

En la versión 1.1 de la especificación de la banda base de Bluetooth se describe la siguiente relación entre los bits marcados en el campo Service Class y los servicios genéricos soportados por el dispositivo:



Nº de bit Clase de servicio13 Limited discoverable mode14 (reservado)15 (reservado)16 Positioning17 Networking18 Rendering19 Capturing20 Object Transfer21 Audio22 Telephony23 Information

Tabla6 II.1.3.3.5: Relación entre los bits del campo Service Class y los servicios genéricos. A cada clase de servicio le es asignado un identificador único. Este identificador de clase es contenido en el valor del atributo Service Class ID List y es representado como un UUID. Descubrimiento de servicios.

El propósito principal del SDP es permitirle a los dispositivos Bluetooth descubrir los servicios ofrecidos por otros dispositivos. Típicamente se requiere de dos transacciones para que un cliente obtenga información de los servicios de un servidor:

1. Búsqueda de servicios: Esta transacción es iniciada por el cliente al enviar una PDU SDP_Service_Search_Req al servidor, quien responde con una PDU SDP_Service_Search_Res. La PDU de respuesta contiene una lista de apuntadores de registro de servicio que coinciden con el servicio solicitado por el cliente. Aún en caso de que el servidor no soporte el servicio solicitado, debe responder al cliente entregando una lista vacía.

2. Búsqueda de atributos de servicio:

Inmediatamente después de completar la transacción anterior, el cliente comienza la búsqueda de atributos de servicio al enviar una PDU SDP_Service_Attribute_Req al servidor, quien responde con una PDU SDP_Service_ Attribute_Res. La PDU de solicitud tiene como parámetros el apuntador del registro correspondiente al servicio de interés y las IDs de los atributos deseados por el cliente. La PDU de respuesta contiene una lista de atributos (tanto sus IDs como sus valores) recabada del registro correspondiente al apuntador suministrado por el cliente. Al final de esta transacción, el cliente debería tener suficiente información para conectarse al servicio.

A su vez, el SDP permite dos tipos de búsqueda:

• Búsqueda específica de servicios (service search): Esta transacción permite al cliente obtener los apuntadores a registros de servicio particulares, basándose en los valores de los atributos contenidos dentro de esos registros. La capacidad de buscar registros de servicio a partir de



valores de atributos arbitrarios no está provista. Los atributos importantes que pueden ser usados para buscar un servicio son representados como UUIDs, por lo que sólo se puede realizar la búsqueda de atributos cuyos valores sean UUIDs. Se utilizan patrones de búsqueda (search patterns) de servicio, es decir listas de UUIDs, para encontrar registros de servicio coincidentes, localizando por lo tanto el servicio deseado.

• Búsqueda generalizada de servicios (service browse):

Este proceso consiste en buscar cualquier servicio ofrecido. En el SDP, el mecanismo para realizar este proceso está basado en un atributo compartido por todas las clases de servicio. Dicho atributo es denominado BrowseGroupList. El valor de este atributo contiene una lista de UUIDs, cada una de las cuales representa un grupo con el cual puede asociarse un servicio con el propósito de realizar la búsqueda. Cuando un cliente desea explorar los servicios ofrecidos por un servidor, crea un patrón de búsqueda de servicio que contiene el UUID que representa el grupo raíz. Todos los servicios que puedan ser explorados en el nivel superior son convertidos en miembros del grupo raíz al incluir el UUID del grupo raíz en el atributo BrowseGroupList.

Representación de datos.

Como ya se ha mencionado, en el SDP un valor de atributo es representado como un elemento de datos, el cual consta de dos campos: Encabezado de elemento de datos. Este campo a su vez está compuesto de dos partes:

• Descriptor de tipo: El tipo de elemento de datos es representado como un descriptor de 5 bits contenido en la sección más significativa del primer byte del encabezado.

• Descriptor de tamaño: El descriptor del tamaño del elemento de datos es representado como un índice de tamaño de 3 bits contenido en la sección menos significativa del primer byte del encabezado, seguido de 0, 8, 16 o 32 bits.

Campo de datos. Los datos constituyen una secuencia de bytes cuya longitud es especificada en el descriptor de tamaño y cuyo significado es parcialmente especificado por el descriptor de tipo.

II.1.3.3.6.- RFCOMM. El RFCOMM es un protocolo de transporte simple que provee emulación de puertos seriales RS-232 sobre el protocolo L2CAP. El nombre RFCOMM es derivado de RF (radiofrecuencia) y COMM, que es la manera en que son designados los puertos seriales de una PC. Por lo tanto RFCOMM hace referencia a la capa de la pila de protocolos que define una implementación inalámbrica de un puerto serial virtual. El RFCOMM provee una estructura basada en PDUs para emular las señales de control y de datos del RS-232 sobre la banda base. El protocolo está basado en el estándar TS 07.10 de la ETSI (European Telecommunications Standards Institute).



Sólo un subconjunto de este estándar es utilizado y algunas adaptaciones del protocolo están descritas en la especificación de Bluetooth.

Descripción general. Para propósitos del RFCOMM, una vía de comunicación completa incluye dos aplicaciones corriendo en dispositivos distintos (terminales de comunicación) y un segmento de comunicación entre ellos. Tipos de dispositivos. Existen básicamente dos tipos de dispositivos que el RFCOMM debe incluir:

• Dispositivos de tipo 1: Estos son terminales de comunicación (por ejemplo, computadoras).

• Dispositivos de tipo 2: Estos forman parte del segmento de comunicación (por

ejemplo, módems).

Aunque el RFCOMM no hace una distinción entre estos dos tipos de dispositivos en el protocolo, el incluirlos impacta sobre este. La información transferida entre dos entidades del RFCOMM ha sido definida para soportar ambos tipos de dispositivo. Cierta información es requerida solamente para dispositivos de tipo 2, mientras que otra está planeada para ser usada por ambos. Puesto que el dispositivo no está conciente del tipo del otro dispositivo en la vía de comunicación, cada uno debe transmitir toda información disponible que esté especificada por el protocolo. Señales de control. El RFCOMM emula los 9 circuitos de una interfaz RS-232. Dichos circuitos están listados en la siguiente tabla:

Código Nombre102 Signal Common103 Transmit Data (TD)104 Received Data (RD)105 Request to Send (RTS)106 Clear to Send (CTS)107 Data Set Ready (DSR)108 Data Terminal Ready (DTR)109 Data Carrier Detect (DCD)125 Ring Indicator (RI)

Tabla7 II.1.3.3.6: Códigos y nombres de los nueve circuitos de una interfaz RS-232.



Emulación de Null Modem. En lo que respecta a la transferencia de los estados de los circuitos que no son de datos, el TS 07.10 no distingue entre dispositivos DTE (Data Terminal Equipment)1 y DCE (Data Circuit-terminating Equipment)2. Las señales de control del RS-232 son enviadas como un número de señales DTE o DCE independientes. La forma en que el TS 07.10 transfiere las señales de control del RS-232 crea una configuración null modem implícita cuando dos dispositivos del mismo tipo se interconectan. No existe un esquema de cableado null modem que funcione siempre; sin embargo, la configuración ofrecida en el RFCOMM debería funcionar en la mayoría de los casos. Emulación de múltiples puertos seriales. Dos dispositivos Bluetooth que usen el RFCOMM en su comunicación pueden utilizar múltiples puertos seriales emulados. El RFCOMM soporta hasta 60 puertos emulados activos; sin embargo, el número de puertos que en realidad pueden ser usados en un dispositivo depende de la implementación. Un identificador de conexión de enlace de datos o DLCI (Data Link Connection Identifier) identifica una conexión en curso entre aplicaciones de cliente y servidor. El DLCI es representado por un valor de 6 bits, pero su rango útil se encuentra entre 2 y 61. El DCLI es único dentro de una sesión del RFCOMM entre dos dispositivos. Como es posible que aplicaciones tanto de cliente como de servidor pueden residir en ambos extremos de una sesión de RFCOMM, lo que permite que clientes en ambos lados efectúen conexiones independientes entre sí, el rango de valores de DLCI se dividido entre dos dispositivos comunicados usando el concepto de canales de servidor junto con un bit de dirección (D). Si un dispositivo Bluetooth soporta múltiples puertos seriales emulados y está permitido que las conexiones tengan terminales en dispositivos diferentes, entonces la entidad RFCOMM debe ser capaz de ejecutar múltiples sesiones de multiplexor del TS 07.10. Cabe resaltar que cada sesión de multiplexor utiliza su propio CID del L2CAP. La habilidad de ejecutar múltiples sesiones de multiplexor es opcional para el RFCOMM. Adaptaciones del TS 07.10 para el RFCOMM.

Adaptación de medios. Las banderas de apertura y cierre de la trama3 básica de opciones del TS 07.10 no son utilizadas en el RFCOMM; en su lugar sólo se intercambian entre las capas del L2CAP y el RFCOMM los campos contenidos entre dichas banderas. Siempre existe exactamente una trama del RFCOMM contenida en cada trama del L2CAP. Procedimientos de inicialización y cierre del multiplexor del TS 07.10. Los procedimientos de inicialización y cierre descritos en la sección 5.7 del TS 07.10 no están soportados. En su lugar, la especificación del RFCOMM indica que, en cualquier instante, debe haber a lo sumo una sesión del RFCOMM entre cualquier par de

1 Equipos informáticos que fungen ya sea como receptor final o como emisor original de datos. 2 Equipos que participan en la comunicación entre dos dispositivos sirviendo como acoplamiento entre un DTE y el circuito o canal de comunicación, realizando funciones como conversión y codificación de señales. 3 Unidad lógica básica de transmisión.



dispositivos. Una sesión está identificada por la BD_ADDR de ambas terminales. Al establecer una nueva conexión de enlace de datos o DLC (Data Link Connection), la entidad que inicia debe comprobar si ya existe una sesión del RFCOMM con el dispositivo remoto, en cuyo caso deberá establecer la nueva DLC en esa sesión; de lo contrario, deberá crear una sesión con ese dispositivo. A continuación se describen los procedimientos de inicialización, cierre y manejo de pérdida de enlace establecidos en el RFCOMM:

• Inicialización: El dispositivo que abre la primera conexión de puerto serial emulado entre dos dispositivos es responsable de establecer el canal de control del multiplexor. Esto implica dos pasos, después de los cuales se pueden establecer DLCs para tráfico de datos de usuario. El primero consiste en establecer un canal del L2CAP con la entidad par (peer entity) del RFCOMM usando las primitivas de servicio del L2CAP. El segundo implica poner en marcha el multiplexor del RFCOMM, enviando el comando Set Asynchronous UnBalanced Mode (SABM) al canal de control (DLCI de valor 0) y esperando una respuesta UA (User Asynchronous) de la entidad par. El SABM es un paquete de comando de bajo nivel usado por el RFCOMM para iniciar un enlace entre dos dispositivos.

• Cierre:

El dispositivo que cierra la última DLC de una sesión particular del RFCOMM es responsable de parar el multiplexor, lo que se logra a su vez cerrando el canal del L2CAP correspondiente. El multiplexor puede ser detenido enviando un comando DISConnect (DISC), que es una trama de comando de bajo nivel usada para terminar una conexión del RFCOMM. Aunque este procedimiento es opcional, el mandar la respuesta UA correcta al DISC es obligatorio.

• Manejo de pérdida de enlace: Al recibir una notificación del L2CAP de pérdida de enlace, la entidad local del RFCOMM es responsable a su vez de mandar una notificación a la entidad de emulación de puerto (proxy) por cada DLC activa. Como resultado, todos los recursos asociados con la sesión del RFCOMM son liberados.

Asignación de DLCIs con canales de servidores. El canal de servidor del RFCOMM es un subconjunto de bits en el campo del DLCI de la trama TS 07.10. A las aplicaciones de servidor que se registran con una interfaz de servicio del RFCOMM se les asigna un número de canal de servidor que toma valores entre 1 y 30. Al dispositivo que inicia una sesión del RFCOMM se le asigna un valor de D de 1, mientras que a los otros dispositivos se les asigna un valor de 0. Al establecer una nueva DLC en una sesión del RFCOMM existente, el D es usado en conjunto con el número de canal de servidor para determinar el DLCI que será usado para conectarse a una aplicación específica. Este DLCI es derivado de la combinación del número de canal de servidor para la aplicación en el dispositivo remoto y el inverso de su propio D en la sesión. El DLCI es por lo tanto utilizado para la transmisión bidireccional de todos los paquetes entre las terminales. Comandos de control del multiplexor. En el TS 07.10, algunos comandos de control del multiplexor pertenecientes a DLCIs específicos pueden ser intercambiados en el canal de control antes de que la DLC



correspondiente haya sido establecida A continuación se presentan los comandos de control del multiplexor usados en las sesiones del RFCOMM:

• Comando de negociación de puerto remoto o RPN (Remote Port Negotiation): Este comando puede ser usado antes de que una nueva DLC sea abierta y debe ser utilizado cada vez que cambie la configuración del puerto.

• Comando de status de línea remota o RLS (Remote Line Status):

Este comando es usado para indicar el status de la línea del puerto remoto.

• Comando de negociación de parámetros de DLC o PN (DLC Parameter Negotiation): El uso de este comando es obligatorio para implementaciones del RFCOMM que cumplen con la versión 1.1 o superiores de la especificación de Bluetooth. Este comando debe ser usado por lo menos antes de la creación de la primera DLC de una sesión del RFCOMM y el dispositivo que la inicie debe tratar de activar el uso del control de flujo basado en créditos.

Métodos de control de flujo.

Los puertos alámbricos comúnmente usan un control de flujo como el RTS/CTS. Por otra parte, el control de flujo entre las capas del RFCOMM y el L2CAP depende de la interfaz de servicio soportada por la implementación. Adicionalmente, el RFCOMM tiene sus propios mecanismos de control de flujo. Control de flujo del L2CAP. El control de flujo en el L2CAP depende de los mecanismos proporcionados por la capa del LM en la banda base. El mecanismo de control de flujo entre las capas del RFCOMM y el L2CAP es específico de cada implementación. Control de flujo de puertos seriales alámbricos. El control de flujo de puertos seriales alámbricos consta de dos clases:

• Control de flujo por software: Emplea caracteres tales como XON/XOFF.

• Control de flujo por hardware: Emplea circuitos RTS/CTS o DTR/DSR. Estos métodos pueden ser usados ya sea por ambos lados de un enlace alámbrico o solamente en una dirección. Control de flujo del RFCOMM. El RFCOMM provee dos mecanismos de control de flujo:

• El RFCOMM contiene comandos de control de flujo que operan en el flujo de datos agregado entre dos entidades del RFCOMM, por lo que todos los DLCIs son afectados.



• El comando de status del módem es el mecanismo de control que opera en DLCIs individuales.

Entidad de emulación de puerto: control de flujo serial. En dispositivos de tipo 1 algunos controladores de puerto (entidades de emulación de puerto más RFCOMM) deberán proveer servicios de control de flujo como los especificados en la API (Application Programming Interface) que están emulando. Una aplicación puede solicitar un mecanismo de control de flujo particular como XON/XOF o RTS/CTS y esperar que el controlador del puerto maneje el control de flujo. En dispositivos de tipo 2 el controlador de puerto puede necesitar realizar control de flujo en la parte de la vía de comunicación que no corresponde al RFCOMM, es decir el puerto RS-232 físico. Este control de flujo es especificado a través de parámetros de control enviados por la entidad par del RFCOMM (usualmente un dispositivo de tipo 1). Como resultado, el controlador de puerto no realizará el control de flujo. Control de flujo basado en créditos. Esta es una característica obligatoria que no existía en el RFCOMM en la especificación de Bluetooth versión 1.0B y anteriores. Por lo tanto, su uso está sujeto a negociación previa al establecimiento de la primera DLC. Las implementaciones que cumplan con esta especificación deben soportarlo y tratar de utilizarlo al conectarse con otros dispositivos. La característica de control de flujo basado en créditos provee control de flujo por cada DLC. Cuando se utiliza, ambos dispositivos involucrados en una sesión del RFCOMM sabrán, para cada DLC, cuantas tramas del RFCOMM es capaz de aceptar el otro dispositivo antes de que sus buffers (para esa DLC) se saturen. Una entidad transmisora podrá enviar tantas tramas en una DLC como créditos posea; si su cuenta de créditos alcanza el cero, deberá detenerse y esperar más créditos de la entidad par. Siempre es permitido enviar tramas que no contengan datos de usuario (campo de longitud = 0) cuando el control de flujo basado en créditos está en uso. Este mecanismo opera independientemente para cada DLC y para cada dirección. No se aplica al DLCI 0 o a tramas que no sean UIH (Unnumbered Information with Header error check). Interacción de otras entidades.

Entidades de emulación de puerto y de proxy de puerto.

• Entidad de emulación de puerto: Esta entidad mapea una interfaz de comunicación específica del sistema (API) a los servicios del RFCOMM.

• Entidad de proxy de puerto:

Esta entidad retransmite datos del RFCOMM a una interfaz RS-232 externa asociada con un DCE. Los parámetros de comunicación de la interfaz RS-232 son configurados de acuerdo a los comandos RPN recibidos.



Registro y descubrimiento de servicios. El registro de aplicaciones o servicios individuales, junto con la información necesaria para accesarlos, es responsabilidad de cada aplicación respectivamente. Confiabilidad. El RFCOMM usa los servicios del L2CAP para establecer canales de este tipo con entidades del RFCOMM en otros dispositivos. Se usa un canal del L2CAP para la sesión del multiplexor del RFCOMM/TS 07.10. Algunos tipos de tramas (SABM y DISC) así como tramas UIH con comandos de control del multiplexor enviados al canal de control requieren siempre una respuesta de la entidad remota, por lo que se envía una confirmación a nivel del RFCOMM (aunque no retransmitidos en ausencia de ésta). Las tramas de datos no requieren respuesta alguna en el protocolo del RFCOMM, por lo que no son confirmados. De esta forma, el RFCOMM requiere que el L2CAP proporcione canales de máxima confiabilidad para asegurar que todas las tramas sean entregadas en orden y sin duplicaciones. Si un canal del L2CAP no cumple con este requisito, el RFCOMM esperará una notificación de pérdida de enlace. Modos de baja energía. Si todos los canales del L2CAP hacia un cierto dispositivo están ociosos (idle) por un determinado periodo de tiempo, se podrá tomar la decisión de poner a ese dispositivo en un modo de baja energía. Esto será hecho sin interferencia alguna del RFCOMM. El RFCOMM puede exponer sus requisitos de latencia al L2CAP, información que posiblemente será usada por capas inferiores para decidir que modo de baja energía usar. El RFCOMM como protocolo no sufre de retrasos de latencia incurridos por modos de baja energía, razón por la cual la especificación no indica ningún requisito de máxima latencia por parte del RFCOMM. La sensibilidad a la latencia depende de los requerimientos de la aplicación, lo que sugiere que una implementación de interfaz de servicio del RFCOMM puede incluir un mecanismo para que las aplicaciones expongan dichos requerimientos, para ser comunicados al L2CAP por medio de esa implementación.

II.1.3.3.7.- BNEP. El Protocolo de Encapsulamiento de Red de Bluetooth o BNEP (Bluetooth Network Encapsulation Protocol) se utiliza para transportar protocolos de red comunes, como IPv4 o IPv6, entre los distintos medios de transmisión Bluetooth. El formato del paquete se basa en la trama EthernetII (estándar DIX) según se establece en la norma IEEE 802.3 y se transmiten a través de la capa del L2CAP. El perfil de redes de área personal (PAN) utiliza este protocolo. II.1.3.4.- Protocolos de Control de Telefonía. II.1.3.4.1.- TCS. El Protocolo de Control de Telefonía o TCS (Telephony Control Protocol) define las señales de control para el establecimiento de llamadas de voz y datos entre dos dispositivos Bluetooth. En otras palabras, este protocolo se utiliza para enviar señales de control a dispositivos que deseen emplear las capacidades de audio de Bluetooth. Adicionalmente, define los procedimientos de



administración de movilidad para coordinar grupos de dispositivos del TCS de Bluetooth. Este protocolo, también llamado TCS Binary o TCS BIN por ser orientado a bits, utiliza comandos AT estándar. La razón por la que no es llamado TCP es para evitar confusiones con el protocolo de control de transmisión usado para comunicación por internet. El TCS admite el establecimiento de llamadas de voz y datos en configuraciones punto a punto y punto a multipunto. Este protocolo se ejecuta directamente sobre la capa L2CAP. El TCS está basado en el estándar Q.931, que es un protocolo de control de teléfonos desarrollado para el control de llamadas en la red pública de teléfonos. El Q.391 define los tipos y formatos de mensajes de control que son generados por la terminal de comunicación (por ejemplo, un teléfono o un FAX). Debido a que el Q.391 ha sido utilizado exitosamente en el sistema telefónico por mucho tiempo, el sistema de Bluetooth adaptó muchos de los mensajes de este protocolo para procesamiento de llamadas (configuración, conexión y desconexión). II.1.3.4.2.- Comandos AT. Los comandos AT son instrucciones codificadas que conforman un lenguaje de comunicación con los módems. El juego de comandos AT fue desarrollado en 1977 por Dennis Hayes como un interfaz de comunicación con el Smartmodem 2400 que permitiera configurarlo y darle instrucciones. Posteriormente fueron las compañías Microcomm y US Robotics las que siguieron desarrollando y expandiendo el juego de comandos hasta universalizarlo. La denominación de estos comandos deriva de la abreviatura de attention. Aunque la finalidad principal de los comandos AT es la comunicación con módems, la telefonía móvil GSM también ha adoptado este lenguaje como estándar de comunicación con sus terminales. Este juego de instrucciones permite acciones tales como realizar llamadas de datos o de voz, leer y escribir en la agenda de contactos y enviar mensajes SMS, además de muchas otras opciones de configuración de la terminal. La implementación de estos comandos es responsabilidad del dispositivo GSM y no depende del canal de comunicación a través del cual sean enviados, en este caso Bluetooth. II.1.3.5.- Protocolos Adoptados. II.1.3.5.1.- HID. El Protocolo de Dispositivo de Interfaz Humana o HID (Human Interface Device), originalmente definido en la especificación del USB, indica las reglas y directivas para transmitir información hacia y desde dispositivos de interfaz humana (por ejemplo, teclados). II.1.3.5.2.- PPP. El Protocolo de Punto a Punto o PPP (Point to Point Protocol) es el estándar de la IETF (Internet Engineering Task Force) utilizado en comunicaciones seriales de internet. El PPP define la manera en que los módems intercambian paquetes de datos con otros sistemas en internet. En Bluetooth, el PPP está diseñado funcionar sobre el RFCOMM. II.1.3.5.3.- TCP/UDP/IP. Estos protocolos definidos por la IETF son usados frecuentemente en comunicaciones a través de internet. Las pilas TCP/IP (Transmission Control Protocol / Internet Protocol) son usadas



ampliamente para la interconexión de redes heterogéneas en numerosos dispositivos. La implementación del sistema Bluetooth permite la conexión con cualquier dispositivo conectado a internet, siempre y cuando se cuente con un punto de acceso, ya sea integrado en el dispositivo Bluetooth o disponible como un puente. Por su parte, el UDP (User Datagram Protocol) es un protocolo de transporte que permite el envío de datagramas1 a través de la red sin que se haya establecido previamente una conexión, siendo particularmente apropiado para el transporte de voz. II.1.3.5.4.- WAP. El Protocolo de Acceso a Redes Inalámbricas o WAP (Wireless Access Protocol) constituye la especificación de un entorno de aplicación y de conjunto de protocolos de comunicaciones para normalizar el modo en que los dispositivos inalámbricos pueden para acceder a cierto tipo de servicios (por ejemplo, correo electrónico). La ventaja principal de usar el WAP en el sistema Bluetooth es la creación de portales que funjan como mediadores entre servidores WAP y las aplicaciones. Este protocolo es compatible con distintas tecnologías y proporciona acceso a Internet desde dispositivos móviles. La tecnología Bluetooth puede actuar como puente y transmitir los datos entre el cliente y el servidor WAP a través de un portador. Además, al permitir la creación de redes ad-hoc, el dispositivo cliente dispone de una libertad adicional que no ofrecen otros portadores WAP. II.1.3.5.5.- OBEX. El Protocolo de Intercambio de Objetos u OBEX (Object Exchange Protocol) fue desarrollado originalmente por la IrDA (Infrared Data Association), siendo su nombre formal IrOBEX. Se trata de un protocolo basado en sesiones cuyo fin consiste en intercambiar objetos de manera simple y espontánea. El OBEX provee básicamente la misma funcionalidad que el HTTP pero de manera mucho más sencilla. Se basa en un modelo cliente/servidor, ajeno a los mecanismos de transporte y al transporte en la API. El dispositivo cliente es aquél que pretende establecer una sesión de comunicación OBEX con otro dispositivo, que de aceptar se convertiría en servidor. A su vez, utiliza un modelo de carga/descarga (push/pull) para la transferencia de objetos, siendo el dispositivo cliente el que realiza éstas operaciones, contando con la aprobación del servidor. El OBEX permite tanto escenarios de conexión rápida o de transferencia-desconexión, como el establecimiento de sesiones en las que las transferencias tienen lugar durante un período de tiempo, manteniendo la conexión incluso cuando esté inactiva. Este protocolo de transferencia define los tipos de objetos y la sintaxis de comunicación que deben utilizar dos dispositivos para intercambiar objetos de datos. Se definen mensajes que contemplan, entre otros, los procesos de conexión (Connect) y desconexión (Disconnect), así como comandos de solicitud de carga (PUT) y descarga (GET) de información. Este protocolo también define un objeto de listado de carpetas que es utilizado para explorar el contenido de carpetas de dispositivos remotos. En la pila de protocolos de Bluetooth, el OBEX utiliza al RFCOMM como capa principal de transporte.

1 Paquetes de longitud finita con suficiente información para ser enrutados independientemente desde la fuente al destino sin el aval de transmisiones previas.



II.1.3.6.- Protocolos Adicionales. II.1.3.6.1.- AVCTP. El Protocolo de Control de Audio y Vídeo o AVCTP (Audio/Video Control Transport Protocol) describe los mecanismos de transferencia para intercambiar mensajes que permitan controlar los dispositivos de audio y vídeo. II.1.3.6.2.- AVDTP. El Protocolo de Distribución de Audio y Vídeo o AVDTP (Audio/Video Distribution Transport Protocol) detalla los procedimientos de negociación, establecimiento y transmisión del flujo de audio y vídeo. II.1.4.- Especificación de Perfiles. II.1.4.1.- Descripción. Para que un dispositivo pueda utilizar la tecnología inalámbrica Bluetooth, debe ser capaz de interpretar los perfiles que describen las distintas aplicaciones o modelos de uso previstos. Un perfil puede ser descrito una sección vertical de la pila de protocolos que define opciones y rangos de parámetros obligatorios para cada capa. A su vez, constituyen guías que indican los mensajes específicos y procedimientos usados para implementar un servicio particular. El concepto de perfil es usado para reducir el riesgo de problemas de interoperabilidad entre productos de diferentes fabricantes, ya que al seguir las directrices proporcionadas en la especificación de perfiles de Bluetooth, los desarrolladores pueden crear aplicaciones compatibles con otros dispositivos que se ajusten a este estándar. Es importante resaltar que esta parte de la especificación no limita a los desarrolladores únicamente al uso de los perfiles definidos en ella; simplemente provee referencias para usar la tecnología Bluetooth para diferentes tipos de aplicaciones. De hecho, conforme se proyectan más aplicaciones para esta tecnología, el número de perfiles aumenta, en gran medida gracias a los diseños de particulares. Cada perfil incluye, como mínimo, información sobre las siguientes cuestiones:

• Dependencia de otros perfiles.

• Propuestas de formato de interfaz de usuario.

• Características concretas de la pila de protocolos. Algunas características son obligatorias mientras que otras pueden ser opcionales. Los perfiles se pueden dividir en dos tipos: los perfiles fundamentales y los perfiles de aplicación. Los primeros constituyen una base para los otros, de manera que todos los perfiles de aplicación heredan características y funciones de por lo menos un perfil fundamental. Los cuatro perfiles fundamentales son:

• GAP.

• GOEP.

• SDAP.

• SPP.



Sobre estos, se definen los diferentes perfiles específicos para modelos de uso, descritos en la especificación Bluetooth 1.0:

• CTP.

• DUN.

• FP.

• FTP.

• HSP.

• ICP.

• LAP.

• OPP.

• SP.

• SPP.

Adicionalmente, los siguientes perfiles de aplicación han sido recientemente aprobados o están en fase de desarrollo:

• A2DP.

• AVRCP.

• BIP. • BPP.

• CIP.

• ESDP.

• GAVDP.

• HCRP.

• HFP.

• HID.

• PAN.

• SAP.

• VDP.

La siguiente figura ilustra la estructura de los perfiles y sus interdependencias. Un perfil depende de otro si hereda parte de él, ya sea por referencia explícita o implícita. En la figura, un perfil depende de aquel en el que esté contenido, directa e indirectamente:



15Figura II.1.4: Interdependencias de los perfiles de Bluetooth.III

II.1.4.2.- Perfiles Fundamentales.

GAP. El Perfil de Acceso Genérico o GAP (Generic Access Profile) proporciona las bases para los demás perfiles y define los procedimientos para descubrir dispositivos Bluetooth, así como los procedimientos de gestión de enlace para establecer una conexión entre dos dispositivos. Este perfil incluye las siguientes cuestiones:

• Funciones que deben implementarse en todos los dispositivos Bluetooth. • Procedimientos generales para detectar y conectar dispositivos. • Terminología básica de la interfaz de usuario.

El GAP describe el uso de las capas inferiores de la pila de protocolos de Bluetooth para asegurar que los dispositivos puedan descubrirse y conectarse entre sí de manera confiable. Adicionalmente, este perfil describe los procedimientos de seguridad correspondientes a las capas superiores de la pila. Por otra parte, este perfil define modos de operación tanto opcionales como obligatorios. EL GAP debe implementarse en cualquier dispositivo Bluetooth para asegurar la interoperabilidad básica y la coexistencia con otros dispositivos, independientemente del tipo de aplicación que soporten. También facilita la tarea de los desarrolladores a la hora de concretar nuevos perfiles, ya que aprovecha las definiciones existentes. Los dispositivos que además cumplan otro perfil Bluetooth pueden emplear adaptaciones de los procedimientos



genéricos, tal como se especifiquen en ese perfil. Sin embargo, deben seguir siendo compatibles con el GAP a nivel de dichos procedimientos. Además de gestionar la detección y el establecimiento de la conexión entre dispositivos no conectados, este perfil indica las operaciones que son comunes y, por consiguiente, pueden ser utilizadas por los perfiles que se remiten a él o por los dispositivos con múltiples perfiles. El GAP permite que dos dispositivos con tecnología Bluetooth, independientemente de su fabricante y aplicaciones, puedan intercambiar información para identificar el tipo de aplicaciones compatibles. Los dispositivos Bluetooth que no se ajusten a ningún perfil concreto deberán adecuarse al GAP para garantizar una compatibilidad mínima.

GOEP. El Perfil Genérico de Intercambio de Objetos o GOEP (Generic Object Exchange Profile) define cómo deben soportar los dispositivos Bluetooth los modelos de uso de intercambio de objetos, tales como imágenes, documentos, tarjetas de visita, etc. Este perfil utiliza modelos de servidor/cliente y carga/descarga según las definiciones del protocolo OBEX. Las aplicaciones que utilizan este perfil dan por sentado que los enlaces y los canales se han establecido según se indica en el GAP. Así mismo, este perfil depende del SPP. El GOEP proporciona un esquema general a los perfiles que utilizan el protocolo OBEX. Sin embargo, no describe la manera en que las aplicaciones deben identificar los objetos del intercambio ni cómo realizarlo. Esta información se precisa en los perfiles que dependen del GOEP, tales como OPP, FTP o SYNC. Bajo el GOEP, un cliente carga o inserta objetos de datos en un servidor mediante la operación PUT, o bien descarga o extrae objetos de datos desde un servidor mediante la operación GET. Los dispositivos con tecnología Bluetooth que suelen utilizar este perfil son portátiles (por ejemplo, PDAs, teléfonos móviles, etc.).

SDAP. El Perfil de Aplicación de Descubrimiento de Servicios o SDAP (Service Discovery Application Profile) describe las características y procedimientos utilizados para que una aplicación utilice el SDP para descubrir servicios registrados en otros dispositivos Bluetooth y obtener información acerca de esos servicios. El perfil SDAP se ocupa de que cualquier aplicación pueda localizar los servicios disponibles en el dispositivo conectado. Controla la búsqueda tanto de servicios específicos ya conocidos como de cualquier otro servicio nuevo. Se definen cuatro abstracciones de primitivas de servicio (service primitive abstractions):

• ServiceBrowse: Usada por el dispositivo local al conducir una búsqueda generalizada de servicios disponibles en un conjunto de dispositivos remotos.

• ServiceSearch: Usada por el dispositivo local al conducir una búsqueda específica de un servicio en un conjunto de dispositivos remotos.

• EnumerateRemDev: Usada por el dispositivo local para buscar dispositivos remotos en su rango de acción.



• TerminatePrimitive: Usada para terminar las operaciones iniciadas por las otras tres primitivas.

El procedimiento de descubrimiento de servicios en dispositivos próximos no es automático: se requiere que el usuario invoque específicamente al SDP mediante la Aplicación de Descubrimiento de Servicios, que debe encontrarse en el dispositivo Bluetooth. Esta aplicación actúa como interfaz entre el perfil y otros dispositivos con ésta tecnología, gestionando el envío y la recepción de solicitudes de búsqueda de servicios. Una vez que se crea el enlace con un dispositivo determinado, se pueden localizar los servicios que ofrece y estos pueden ser seleccionados a través de la interfaz de usuario según el tipo de aplicación que se desee ejecutar. El perfil SDP depende y reutiliza secciones del GAP.

SPP. El Perfil de Puerto Serial o SPP (Serial Port Profile) describe la configuración de los dispositivos Bluetooth para emular una conexión a través de un cable serial. EL SPP utiliza el protocolo RFCOMM para emular los puertos seriales. La meta del SPP es garantizar la transparencia, es decir que una aplicación que utilice un puerto serial emulado no debe ser capaz de distinguirlo de un enlace físico. Este perfil se emplea para reemplazar cables por canales inalámbricos orientados a conexión en las aplicaciones de comunicación y aplicaciones heredadas que utilicen una señalización de control derivada de conexiones seriales RS-232. A su vez, el SPP sienta las bases de los perfiles DUN, FAX, HSP y LAN. Este perfil admite una velocidad de transmisión de hasta 128 kbits por segundo. El SPP depende únicamente del GAP.

II.1.4.3.- Perfiles de Aplicación.

A2DP. El Perfil de Distribución de Audio Avanzado o A2DP (Advanced Audio Distribution Profile) describe cómo transferir sonido estéreo de alta calidad de una fuente de sonido a un dispositivo receptor. En el caso de un reproductor de música, por ejemplo, este sería la fuente de sonido y el auricular inalámbrico el receptor. El A2DP establece los protocolos y procedimientos que realizarán la distribución del contenido de audio de alta calidad en modo mono o estéreo a través de los canales ACL. El término “audio avanzado” debe, por lo tanto, diferenciarse de “audio Bluetooth”, que se refiere a la distribución de señales de voz de banda estrecha a través de canales SCO según se indica en la especificación de la banda base. El A2DP está basado en el GAVDP y admite, como es obligatorio, la codificación sub-banda o SBC (Sub-band Codec) de baja complejidad, así como los formatos MPEG-1, 2 Audio, MPEG-2, 4 AAC y ATRAC.

Los datos de sonido se comprimen en un formato apropiado para su correcto funcionamiento en un ancho de banda limitado. La distribución de sonido envolvente no se recoge en este perfil.

AVRCP. El Perfil de Control Remoto de Audio y Vídeo o AVRCP (Audio/Video Remote Control Profile) proporciona una interfaz estándar para manejar cualquier equipo electrónico,



permitiendo que un único control remoto o cualquier otro tipo de mando controle todo equipo de audio y vídeo al que el usuario tenga acceso. Puede utilizarse en conjunción con el A2DP o el VDP. El AVRCP indica cómo controlar las características de transferencia continua de archivos de imagen y sonido, entre otras las funciones de pausa, stop y play de la reproducción y el control del volumen, así como otras funciones de control remoto. Este perfil especifica el conjunto de comandos de la interfaz digital de control de audio y vídeo (A/V C) que debe aplicarse, por lo que facilita la implementación y el funcionamiento posterior. Utiliza el modelo de dispositivo y de formato de comandos A/V C para los mensajes de control y aquellos transferidos por el AVCTP. El perfil distingue dos roles: el controlador y el dispositivo de destino. El controlador suele ser un mando de control remoto y el dispositivo de destino el equipo electrónico. En un reproductor de música, por ejemplo, el controlador sería el auricular que permite cambiar de pista y el dispositivo de destino el reproductor en sí. En el AVRCP, el controlador traduce la acción detectada y la convierte en una señal de control de audio y vídeo, que después transmite al dispositivo con tecnología Bluetooth. En este protocolo también pueden incluirse las funciones disponibles para controles remotos con tecnología de infrarrojos. Los controles remotos descritos en este protocolo se han diseñado exclusivamente para audio y vídeo.

BIP. El Perfil Básico de Imagen o BIP (Basic Image Profile) establece cómo puede controlarse remotamente un dispositivo de imagen, así como la forma de enviarle órdenes de impresión y de transferencia de imágenes a un dispositivo de almacenamiento. También incluye funciones para cambiar el tamaño y modificar las imágenes de forma que se ajusten al dispositivo receptor. Un ejemplo de este perfil es un teléfono móvil que se utiliza para controlar el obturador de una cámara digital.

El BIP puede desglosarse en las siguientes partes:

• Envío de imágenes: Permite enviar imágenes desde el dispositivo que controla

el usuario.

• Recepción de imágenes: Permite ojear las imágenes desde un dispositivo remoto y capturarlas en éste.

• Impresión de imagen avanzada: Imprime las imágenes mediante opciones

avanzadas que utilizan el formato DPOF.

• Copia de archivos automática: Permite realizar copias de seguridad automáticas de las nuevas imágenes de un dispositivo de destino.

• Control remoto de la cámara: Permite manejar una cámara digital a distancia.

• Presentación a distancia: Permite enviar imágenes para que se muestren en otro

dispositivo.



BPP. El Perfil Básico de Impresión o BPP (Basic Printing Profile) permite enviar mensajes de texto, de correo electrónico, tarjetas de visita electrónicas e imágenes, entre otras cosas, a las impresoras disponibles, dependiendo de las tareas de impresión. A diferencia del HCRP, éste no requiere controladores de impresión específicos, por lo que es más indicado para dispositivos que no pueden actualizarse fácilmente con controladores específicos de cada fabricante, como móviles o cámaras digitales. Este perfil permite a los dispositivos Bluetooth identificar las impresoras disponibles, obtener la información necesaria para comunicarse con ellas y ajustar el formato de la información enviada. Este perfil diferencía entre emisor e impresora. El emisor suele ser un dispositivo móvil (como una PDA o un teléfono) desde el que se quiere imprimir sin tener que instalar ningún controlador. La impresora es el dispositivo al que se envía la información para su impresión. Suele tratarse de una impresora física o de un ordenador que actúa como intermediario entre la impresora a la que está conectado y el dispositivo, normalmente a través de un medio físico (como un cable USB).

CIP. El Perfil de Acceso ISDN Común o CIP (Common ISDN Access Profile) establece cómo se deben transferir las señales de la Red Digital de Servicios Integrados o ISDN (Integrated Services Digital Network) a través de una conexión inalámbrica Bluetooth. Proporciona acceso sin restricciones a los servicios, datos y señales de la ISDN. Con este perfil se persigue:

• Indicar cómo las aplicaciones deben acceder a los servicios de la ISDN

mediante la tecnología Bluetooth.

• Permitir acceso sin restricciones a los servicios, datos y señales de la ISDN siempre que sea posible.

• Asegurar que las aplicaciones de la ISDN heredadas siguen funcionando sin modificaciones internas.

• Establecer cómo compatibilizar el acceso a la ISDN de las distintas especificaciones Bluetooth.

• Mostrar cómo la conexión de la ISDN a través de la tecnología Bluetooth puede coexistir con los servicios presentes en una aplicación.

CTP. El Perfil de Telefonía Inalámbrica o CTP (Cordless Telephony Profile) describe la implementación de un teléfono inalámbrico a través de un enlace Bluetooth. Este perfil puede utilizarse tanto para teléfonos móviles como para teléfonos inalámbricos que necesitan una estación base. Se espera que los teléfonos móviles puedan utilizar una puerta de enlace del CTP de Bluetooth para conectarse indistintamente a la línea fija de teléfono o a la red móvil cuando se esté fuera del radio de alcance de la línea doméstica. Este perfil es fundamental para las funciones de teléfono 3 en 1 de la tecnología Bluetooth: celular, inalámbrico e intercomunicador.



DUN. El Perfil de Red de Marcado o DUN (Dial-up Networking Profile) proporciona un acceso telefónico estándar a Internet y a otros servicios de marcado a través de una conexión Bluetooth. Se utiliza, por ejemplo, al acceder a Internet desde un portátil utilizando un teléfono móvil como módem, siendo éste el que realiza la función de marcado de forma inalámbrica. A este modelo se le denomina Puente a Internet (Internet Bridge). Este perfil se basa en el SPP y permite adaptar los productos existentes de forma relativamente sencilla al utilizar las características comunes con los protocolos seriales alámbricos que realizan la misma función, como el conjunto de comandos AT y el PPP. El perfil DUN distingue entre el dispositivo de la puerta de enlace y el dispositivo terminal. El dispositivo que actúa como puerta de enlace proporciona acceso a la red al dispositivo terminal.

Como en otros perfiles de capas superiores al SPP, las capas inferiores de la pila del protocolo Bluetooth crean un enlace serial virtual que es visible para todas las aplicaciones que utilizan el perfil DUN. Así, el controlador del módem del dispositivo terminal no advierte que la comunicación se está realizando a través de la tecnología Bluetooth. La aplicación utilizada para ello tampoco repara en que no hay cable físico alguno que una el dispositivo terminal al dispositivo de la puerta de enlace.

ESDP. El Perfil de Descubrimiento de Servicios Ampliado o ESDP (Extended Service Discovery Application Profile) describe cómo se lleva a cabo la función plug and play a través de una conexión inalámbrica Bluetooth.

FP / FAX. El Perfil de fax o FP (Fax Profile), también conocido como FAX, define los protocolos y procedimientos necesarios para que un dispositivo terminal pueda utilizar a otro como puerta de enlace para la transmisión de faxes. Pretende ofrecer una interfaz entre un móvil o teléfono fijo y un ordenador con un programa de fax instalado. Para ello, es necesaria la compatibilidad con comandos AT ITU T.31 e ITU T.32 AT establecidos por la ITU (International Telecommunication Union). Se emplea, por ejemplo, cuando un ordenador personal utiliza un teléfono móvil como puerta de enlace para enviar documentos de fax a un receptor cualquiera.

FTP. El Perfil de Transferencia de Archivos o FTP (File Transfer Profile) utiliza el protocolo OBEX File Transfer (a través del GOEP), el cual ofrece la capacidad de transferir objetos de datos (archivos y carpetas) de un dispositivo Bluetooth a otro, así como navegar por los contenidos de las carpetas del dispositivo remoto. Los dispositivos que implementan el FTP pueden actuar como cliente o como servidor. El dispositivo cliente es aquel que inicia la operación de envío o extracción de objetos al y desde el dispositivo servidor. El servidor es el dispositivo remoto que proporciona un servicio de intercambio de objetos a través de los comandos del protocolo OBEX. Los servidores pueden imponer políticas de restricción de permisos de lectura y escritura, para evitar la creación y borrado de carpetas y archivos.



Se definen las siguientes operaciones en el FTP:

• Navegar por la jerarquía de carpetas. • Listar el contenido de una carpeta. • Extraer objetos mediante el comando GET.

• Enviar objetos mediante el comando PUT.

• Borrar objetos.

GAVDP. El Perfil de Distribución Genérica de Audio y Vídeo o GAVDP (Generic Audio Video Distribution Profile) sienta las bases de los perfiles A2DP y VDP, pilar de los sistemas diseñados para la transmisión de sonido e imagen mediante la tecnología Bluetooth. Distingue entre dos elementos: el iniciador y el aceptador. Por ejemplo, un reproductor de música sería el iniciador y el auricular el aceptador. Este perfil especifica los procedimientos de transmisión de señales entre dos dispositivos para configurar, finalizar y reconfigurar los canales de transferencia. Los parámetros y características de codificación y decodificación de la transmisión se incluyen en los perfiles A2DP y VDP.

HFP. El Perfil Manos Libres o HFP (Hands-Free Profile) describe cómo un dispositivo que actúa como puerta de enlace puede utilizarse para realizar y recibir llamadas a través de un dispositivo manos libres. Un caso típico sería un vehículo que se sirve de un teléfono móvil como dispositivo de puerta de enlace. En el automóvil, el equipo de sonido hace las veces de altavoz y las señales de audio se envían mediante un micrófono instalado en el coche. Este perfil también se utiliza en ordenadores que funcionan como altavoces del teléfono móvil en la oficina o en el hogar. El perfil se sirve de comunicaciones SCO para transportar un canal de audio mono de tipo PCM (Pulse-code Modulation).

HCRP. El Perfil de Sustitución de Cable de Copia Impresa o HCRP (Hardcopy Cable Replacement Profile) describe cómo imprimir archivos mediante un enlace inalámbrico Bluetooth utilizando controladores en el proceso. Distingue entre dispositivo cliente y servidor. El cliente es el dispositivo que tiene el controlador de impresión del servidor desde el que se quiere imprimir. En el caso de un ordenador con los controladores de una impresora con tecnología Bluetooth, éste sería el cliente y la impresora, el servidor. Se trata de una alternativa sencilla y eficaz para eliminar los cables entre cualquier dispositivo y una impresora. El perfil no establece un estándar de comunicación con la impresora, por lo que se requieren los controladores específicos del modelo utilizado o, en algunos casos, de cualquier otro de la misma gama. Por ello, no es apropiado para dispositivos en los que resulta complicado actualizar los controladores. El perfil se ejecuta directamente en la capa L2CAP para evitar la implicación de los protocolos RFCOMM y OBEX.



HSP. El Perfil de Auricular o HSP (Headset Profile) define los protocolos y procedimientos para el modelo de uso que permite utilizar un dispositivo auricular de última generación como interfaz remota de entrada y salida de audio de otro dispositivo, independientemente de los fabricantes. Este perfil también describe las opciones de control del auricular. Se definen dos roles para los dispositivos que implementan este perfil: pasarela de audio y auricular. El dispositivo pasarela de audio es aquel que inicia el procedimiento de conexión, mientras que el dispositivo auricular se define como el que actúa como mecanismo de entrada y salida de audio remotas para la pasarela de audio. El HSP requiere que los dos dispositivos involucrados soporten enlaces SCO. Por ello, solamente se admite una conexión de audio en cada momento entre el auricular y la pasarela de audio. La pasarela de audio controla el establecimiento y la liberación del enlace SCO. El auricular conecta y desconecta directamente los flujos internos de audio durante el establecimiento y liberación del enlace SCO. Una vez que el enlace está establecido, existe una transferencia válida de audio sobre el enlace SCO en ambas direcciones. A su vez, el perfil se sirve de un subconjunto de comandos AT conforme a la especificación GSM 07.07 para realizar ciertas funciones básicas de control, como la posibilidad de realizar y contestar llamadas, colgar o ajustar el volumen.

HID. El Perfil de Dispositivo de Interfaz Humana o HID (Human Interface Device) recoge los protocolos, procedimientos y características empleados por las interfaces de usuario más comunes, tales como teclados, para permitirles comunicarse con los sistemas con los que interactúan. Desde luego, este perfil está basado en el protocolo homónimo. Este perfil agrupa a los dispositivos de acuerdo a su clase; cada clase tiene sus controladores. También permite identificar las funciones de dispositivos HID, así como la manera en que los dispositivos Bluetooth pueden utilizar sus servicios a través de la capa L2CAP. Está diseñado para permitir la inicialización y el control de los dispositivos que se describen a sí mismos, además de para proporcionar un enlace con baja latencia y requisitos de potencia mínimos. Los dispositivos HID pueden ser agregados o removidos en cualquier momento sin causar problemas al sistema.

ICP. El Perfil de Intercomunicador o ICP (Intercomm Profile) establece cómo conectar dos teléfonos móviles con tecnología Bluetooth dentro la misma red sin utilizar la red telefónica pública. También se le conoce como perfil walkie-talkie. Se basa en la especificación TCS y utiliza canales SCO para transmitir el sonido.

LAP. El Perfil de Acceso a LAN o LAP (LAN Access Profile) define la manera en que los dispositivos Bluetooth pueden acceder a los servicios de una LAN utilizando el protocolo PPP sobre RFCOMM. También explica cómo puede utilizarse el mismo PPP para conectar en red dos dispositivos. En este modelo de uso, varias terminales de datos utilizan un punto de acceso a la red como conexión inalámbrica a una LAN, de forma que operan como si estuviesen conectados a la red directamente. Aunque PPP es capaz



de soportar varios protocolos de red (IP, IPX, etc.), el LAP no obliga al uso de ningún protocolo en particular.

OPP. El Perfil de Carga de Objetos u OPP (Object Push Profile) utiliza el protocolo OBEX Object Push (a través del GOEP), el cual ofrece la capacidad de cargar y descargar objetos de datos de un dispositivo Bluetooth a otro utilizando un modelo de cliente/servidor. Inicialmente, el OPP se centraba en un reducido número de formatos de objeto, tales como citas en formato vCalendar o tarjetas de visita en formato vCard, para aumentar la interoperabilidad. Actualmente, el perfil conserva esta funcionalidad, aunque también se utiliza para transferencia rápida de archivos.

PAN.

El Perfil de Red de Área Personal o PAN (Personal Area Network) describe cómo dos o más dispositivos con tecnología Bluetooth pueden formar una red ad-hoc y cómo ese mismo mecanismo permite acceder a la red de forma remota a través de un punto de acceso. El perfil diferencía entre el punto de acceso a la red, la red ad-hoc y el usuario de la red de área personal. Los puntos de acceso pueden ser puntos de acceso a redes de área local normales. Las redes ad-hoc representan a un grupo de dispositivos que sólo se relacionan entre sí. La red de área personal permite utilizar el protocolo BNEP en protocolos de tercera capa para realizar las comunicaciones a través de un enlace Bluetooth.

SAP. El Perfil de acceso SIM o SAP (SIM Access Profile) permite a dispositivos con transmisores GSM integrados, como los sistemas de teléfono de los automóviles, conectarse a la tarjeta SIM (Subscriber Identity Module) de un móvil equipado con tecnología Bluetooth. De esta forma, el teléfono del automóvil no requiere ninguna otra tarjeta SIM.

SP / SYNC. El Perfil de Sincronización o SP (Synchronization Profile), también conocido como SYNC, define los requisitos para los protocolos y procedimientos utilizados por las aplicaciones que proporcionan el modelo de uso de sincronización. El modelo proporciona sincronización dispositivo a dispositivo de programas de gestión de la información personal o PIM (Personal Information Management). La información que manejan estos programas consiste normalmente en una agenda de teléfonos de contactos, calendario, mensajes y notas. Los dispositivos que implementan el SP pueden actuar como cliente y servidor. Este perfil depende del GOEP. Las unidades activas en el modelo de uso de sincronización deben soportar tres funciones:

• La función de sincronización en Bluetooth debe soportar al menos una de las siguientes clases de aplicación:

o Sincronización de agendas telefónicas o Sincronización de calendarios o Sincronización de mensajes



o Sincronización de notas

Para conseguir la interoperabilidad a nivel de aplicación, se definen formatos de contenido específicos para cada unidad activa, que son: vCard, vCalendar, vMessage y vNote.

• La función de comando de sincronización permite a un dispositivo cliente trabajar como un servidor y recibir un comando de sincronización desde otro dispositivo cliente.

• La función de sincronización automática permite a un dispositivo cliente iniciar

la sincronización cuando el dispositivo servidor entra dentro de su rango de cobertura. Al nivel de la banda base, esto significa que el cliente realiza una búsqueda del servidor a intervalos regulares y cuando detecta que éste ha entrado en su rango de cobertura comienza la sincronización.

VDP. El Perfil de Distribución de Video o VDP (Video Distribution Profile) dicta los pasos que deben seguir los dispositivos con tecnología Bluetooth para la transferencia continua de vídeos. Esto permite, por ejemplo, visualizar en reproductores portátiles los vídeos almacenados en aplicaciones multimedia de cualquier ordenador o transferir las imágenes desde una videocámara digital a la televisión. El perfil proporciona las instrucciones de adecuación a la norma H.263. Opcionalmente, los dispositivos pueden admitir perfiles MPEG-4 y los perfiles 3 y 8 del estándar H.263, que también aparecen recogidos en este perfil VDP.

II.1.5.- Aspectos Adicionales. II.1.5.1.- Administración de energía. La tecnología Bluetooth está motivada por el deseo de proveer una interfaz universal para los dispositivos portátiles que funcionan a base de baterías. Como tal, esta tecnología posee características para una administración efectiva de la energía que permita su conservación. Algunas de las más importantes están implementadas a nivel micro. La primera de dichas características está relacionada con el salto en frecuencia. El mecanismo para el salto en frecuencia está diseñado de tal manera que no es necesario el intercambio de datos de relleno (dummy data) para mantener al maestro y al esclavo sincronizados entre sí. Esto elimina la necesidad de que los transceptores de ambos dispositivos se activen periódicamente y transmitan paquetes de relleno (dummy packets). La segunda es inherente al formato de los paquetes. Puesto que los paquetes Bluetooth comienzan con el código de acceso de la piconet a la cual van dirigidos, un dispositivo que escucha en la frecuencia de salto de la piconet durante su ranura de recepción puede determinar rápidamente si el paquete transportado en la frecuencia de salto actual está dirigido a su propia piconet. Si el dispositivo determina que el paquete no está dirigido a su piconet, su transceptor puede desactivarse durante el resto de la ranura de tiempo. Más aún, el encabezado de paquete contiene información sobre el tamaño de la carga útil, de manera que si ésta es muy pequeña, el dispositivo no tiene que mantener activo su transceptor durante toda la ranura de tiempo, pudiendo desactivarlo tan pronto como haya completado la recepción de la carga útil.



Además de las características de administración de energía a nivel micro, Bluetooth proporciona soporte para su administración a nivel macro, permitiendo el control de la potencia de transmisión y definiendo tres modos de baja energía. II.1.5.2.- Seguridad. El sistema Bluetooth incorpora varios mecanismos de seguridad que lo convierten en uno de los protocolos de comunicaciones más seguros y robustos frente a ataques y capturas de datos. Se definen mecanismos de seguridad en las siguientes capas de protocolo:

• Seguridad a nivel de banda base:

o FHSS.

• Seguridad a nivel de enlace:

o Autentificación.

o Autorización.

o Encriptación.

FHSS.

La técnica de saltos de frecuencia empleada por Bluetooth garantiza, en principio, la participación exclusiva de dispositivos autorizados en una piconet y una comunicación libre de escuchas por parte de usuarios ajenos a la misma. Cualquier dispositivo que no pertenezca a la piconet no podrá participar en la comunicación, ya sea enviando paquetes o escuchando tráfico, debido a que no dispone de la tabla con la secuencia de saltos utilizada. Además, la probabilidad de adivinar cual de todos los canales puede ser empleado para la comunicación en cada instante de tiempo es mínima. Sin embargo, si un atacante pudiera disponer de la tabla de frecuencias generada por el dispositivo maestro de una piconet, éste podría sincronizar su módulo Bluetooth con el resto de dispositivos de la piconet y participar en la comunicación. Puesto que el intercambio de las tablas de secuencias de saltos se lleva a cabo en una frecuencia conocida, un dispositivo malicioso podría estar escuchando constantemente y capturar estas tablas de saltos de frecuencia para sincronizarse con una piconet. Por otro lado, aunque actualmente los módulos Bluetooth convencionales no permiten la escucha en más de un canal del espectro de frecuencias, es posible que exista determinado hardware especializado capaz de barrer todo el espectro de frecuencias empleado por Bluetooth y capturar paquetes en más de un canal a la vez. Esto permitiría a un atacante escuchar todo el intercambio de paquetes entre dispositivos de una piconet y comprometer la confidencialidad de la comunicación. No obstante, se trata de módulos Bluetooth especiales que no resultan accesibles para la mayoría de los usuarios y cuyo coste es elevado.

Autentificación.

La autentificación es el proceso por el cual un dispositivo Bluetooth verifica la identidad de otro dispositivo antes de permitirle acceder a los servicios que ofrece. Todas las funciones de seguridad de nivel de enlace están basadas en el concepto de claves de enlace, las cuales son números pseudoaleatorios de 128 bits almacenados individualmente por cada par de dispositivos Bluetooth. La autentificación no requiere la intervención del usuario; implica un esquema de desafío/respuesta entre cada par de



dispositivos que emplea una clave de enlace secreta común de 128 bits. Consecuentemente, este esquema se utiliza para autentificar dispositivos, no usuarios. La primera vez que dos dispositivos intentan comunicarse, se utiliza el procedimiento de inicialización denominado emparejamiento (pairing) para crear una clave de enlace común de una forma segura. Para la primera conexión entre dos dispositivos, el procedimiento estándar de emparejamiento requiere que el usuario de cada dispositivo introduzca un PIN de hasta 16 bytes de longitud que debe ser el mismo en los dos casos. Éste código se introduce una sola vez. Cuando se tienen requisitos de baja seguridad, es posible que aquellos dispositivos que carezcan de interfaz de usuario que permita la introducción manual del código, incorporen un PIN prefijado de fábrica. A partir del PIN, se obtiene la clave de enlace común a dos dispositivos del siguiente modo:

1. Se genera una clave de inicialización o Kinit usando el algoritmo E22 a partir del

PIN, su longitud, la BD_ADDR y un número aleatorio IN_RAND.

16Figura II.1.5.2.a: Generación de la clave Kinit.VIII

2. Se genera la clave de enlace o Kab usando el algoritmo E21. Los dispositivos usan la Kinit para intercambiar dos nuevos números aleatorios de 128 bits, conocidos como LK_RAND A y LK_RAND B. Cada dispositivo genera un número aleatorio que es sometido a una operación XOR bit a bit con la Kinit y posteriormente enviado al otro dispositivo. Dado que ambos dispositivos conocen la Kinit, cada dispositivo conoce ambas LK_RAND. A partir de la dirección BD_ADDR y el LK_RAND, el algoritmo E21 obtiene la Kab.



17Figura II.1.5.2.b: Generación de la clave Kab.VIII

3. La clave de enlace común se almacena temporalmente en los dispositivos emparejados. Mientras esta clave de enlace esté almacenada en ambos dispositivos, no será necesario repetir el emparejamiento en futuras conexiones.

Una vez que los dispositivos emparejados disponen de la clave de enlace, utilizan esta clave común para autentificarse automáticamente en las sucesivas conexiones. El proceso de autentificación está basado en el esquema desafío/respuesta y transcurre de la siguiente forma:

1. El dispositivo reclamante envía su dirección BD_ADDR al dispositivo

verificador.

2. El verificador devuelve un desafío aleatorio de 128 bits al demandante. 3. El reclamante usa el algoritmo E1 para generar la respuesta de autentificación

(SRES) de 32 bits, usando como parámetros de entrada la dirección BD_ADDR del reclamante, la Kab almacenada y el desafío. El verificador realiza la misma operación en paralelo.

4. El reclamante devuelve la respuesta SRES al verificador.

5. El verificador comprueba la respuesta SRES recibida por el reclamante con la

respuesta SRES calculada por él.

6. Si los valores de SRES coinciden, el verificador establece la conexión.



18Figura II.1.5.2.c: Proceso de autentificación.VIII

La especificación de Bluetooth establece que si se produce un fallo durante el proceso de autentificación, para prevenir que un atacante pruebe claves de enlace aleatorias en un ataque de fuerza bruta, debe transcurrir cierto período de espera antes de que se pueda llevar a cabo un nuevo intento de autentificación. Para cada sucesivo intento fallido, el tiempo de espera aumenta exponencialmente.

Autorización.

La autorización es el procedimiento que determina los derechos que tiene un dispositivo Bluetooth para acceder a los servicios que ofrece un sistema. El mecanismo de autorización en dispositivos Bluetooth se lleva a cabo mediante niveles de confianza. Los dispositivos tienen tres niveles de confianza, los cuales determinan la capacidad de acceso a los servicios: total, parcial o restringida y nula.

• Un dispositivo de confianza mantiene una relación de emparejamiento y

dispone de acceso sin restricciones a todos los servicios.

• Un dispositivo de confianza restringida mantiene una relación de emparejamiento y sólo dispone de acceso restringido a uno o varios servicios, pero no a todos.

• Un dispositivo no confiable es aquel que puede o no mantener tener una relación de emparejamiento pero no se le permite el acceso a ningún servicio.

En el caso de que un determinado dispositivo de confianza intente acceder a un servicio autorizado, no se requiere ningún procedimiento de confirmación, por lo que accede de forma transparente. En el caso de que un determinado dispositivo no confiable intente acceder a un servicio restringido, se requiere un procedimiento explícito de confirmación por parte del usuario para permitir o denegar el acceso a ese dispositivo durante la sesión de conexión actual. Para algunos servicios, es posible conceder permisos de acceso temporal a dispositivos no emparejados previamente.



Todo dispositivo Bluetooth dispone de una base de datos interna con su lista de dispositivos de confianza y que tiene el siguiente formato:

Campo Tipo

BD_ADDR ObligatorioNivel de confianza Obligatorio

Clave de enlace Kab ObligatorioNombre Opcional

Tabla8 II.1.5.2: Formato de la lista de dispositivos de confianza.

En la mayoría de dispositivos es posible configurar manualmente la lista de dispositivos de confianza.

Encriptación.

La encriptación de datos protege la información que se transmite en un enlace entre dispositivos Bluetooth y garantiza la confidencialidad del mensaje transmitido, de forma que si el paquete es capturado por un usuario que no posea la clave de descifrado, el mensaje le resultará ininteligible. Su implementación es opcional y requiere una autentificación previa. Se emplea el motor de encriptación SAFER (Secure and Fast Encryption Routine). El maestro y el esclavo deben acordar el uso de la encriptación. De ser utilizada, también deberán determinar el tamaño de la clave de cifrado, para lo cual maestro y esclavo intercambian mensajes hasta alcanzar un acuerdo. No siempre es posible llegar a un acuerdo sobre el tamaño de dicha clave, en cuyo caso se indica a las unidades Bluetooth que no se les permite comunicarse utilizando encriptación en el enlace. Tras esta negociación comienza el proceso de encriptación: el maestro genera una clave de cifrado KC de 128 bits usando el algoritmo E3, el cual requiere como parámetros de entrada un número aleatorio de 128 bits, la Kab generada durante el procedimiento de emparejamiento y el número COF (Ciphering Offset) de 96 bits basado en el valor temporal ACO (Authenticated Ciphering Offset) calculado durante el procedimiento de autentificación.

19Figura II.1.5.2.d: Proceso de encriptación.VIII



Una vez que la clave de cifrado se ha generado con éxito, el maestro se encuentra en condiciones de transmitir datos cifrados, para lo cual debe detener temporalmente el tráfico de datos de los niveles superiores y así evitar la recepción de datos corruptos.

Modos de seguridad Bluetooth a nivel de enlace.

Una vez descritos los tres mecanismos que emplea Bluetooth para reforzar la seguridad a nivel de enlace, se definen tres modos de seguridad en este nivel en función de la implementación de dichos mecanismos:

• Modo 1: Ausencia de seguridad, es decir que todos los mecanismos de

seguridad están deshabilitados. Además, el dispositivo se sitúa en modo promiscuo, permitiendo que todos los dispositivos Bluetooth se puedan conectar a él. Este modo lo emplean dispositivos que no tienen aplicaciones críticas. Ninguna parte del tráfico de datos es encriptada.

• Modo 2: Proporciona seguridad en los servicios a nivel del L2CAP. Utiliza

mecanismos de seguridad (autorización) después de establecerse el canal de comunicación. Un gestor de seguridad controla el acceso de los dispositivos a los diferentes servicios, en función de su nivel de confianza. La interacción con el usuario se limita a solicitar confirmación de la autorización de acceso a servicios restringidos por parte de dispositivos no autorizados. El tráfico de difusión no está encriptado, mientras que el tráfico punto a punto se encripta según las claves individuales generadas durante la conexión.

• Modo 3: Proporciona seguridad en el dispositivo a nivel del LMP. Utiliza

mecanismos de seguridad (autentificación) antes de establecerse el canal de comunicación. Requiere emparejamiento de dispositivos y existencia de clave de enlace compartida para validar la conexión entre dispositivos. La interacción con el usuario consiste en la introducción de un código PIN para llevar a cabo el emparejamiento de dispositivos. Todo el tráfico se encripta con la clave de cifrado generada.

III.2.- PDA. Un asistente digital personal o PDA (Personal Digital Assitant) es un dispositivo handheld que constituye una plataforma computacional multipropósito completa en un sistema compacto y portátil, incorporando procesamiento, interfaz de comunicación con el usuario, capacidad de almacenamiento tanto interno como extraíble y conectividad alámbrica e inalámbrica. Puesto que se trata de un dispositivo de uso común y se encuentra disponible para el público en general, resulta factible y práctico adoptar un esquema de diseño que lo utilice como núcleo y aproveche sus capacidades, evitando así el proceso de diseño de la plataforma de procesamiento y permitiendo enfocar los esfuerzos al desarrollo de la aplicación en sí. Los modelos más avanzados cuentan con características similares a las de una PC, desde capacidades de procesamiento y ejecución, hasta sistemas operativos inspirados en versiones hechas para las computadoras actuales, dándoles por consiguiente un grado de versatilidad similar y ofreciendo la posibilidad de implementar soluciones de instrumentación virtual, es decir orientadas a software, minimizando así la dependencia del diseño hacia el hardware.



Los procesadores más poderosos para estos dispositivos pertenecen a la gama Intel XScale Bulverde PX270, alcanzando velocidades de reloj de hasta 624 MHz, aunque ya se encuentra en vías de comercialización la familia de procesadores Monahan que promete velocidades de 1.25 GHz. Esto, aunado al desarrollo de las tecnologías de memoria, como el diseño de discos duros miniaturizados (algunos del tamaño de una ficha de dominó y con una capacidad de 4GB), augura niveles de desempeño futuros que permitirían la implementación de aplicaciones cada vez más complejas, resultando incluso en la importación de aquellas que actualmente se efectúan en los ordenadores de escritorio. Actualmente, los PDAs utilizan diferentes sistemas operativos, cada uno usualmente relacionado estrechamente con una arquitectura particular que no depende exclusivamente del procesador implementado, aunque recientemente los problemas de compatibilidad tienden a desaparecer, al menos para los modelos más avanzados. Los principales sistemas operativos para estos dispositivos son:

• Windows Mobile, desarrollado por Microsoft con base en el kernel Windows CE. • Palm OS, desarrollado por PalmSource.

• Varios sistemas operativos basados en el kernel Linux.

Los dos primeros son los más importantes y generan una de las principales divisiones entre los PDAs, siendo el de Microsoft más común en modelos recientes y estando normalmente asociado a los dispositivos de alto desempeño, favoreciendo la implementación de características similares a las de una PC. Palm OS, por su parte, es mucho más simple y se encuentra mayoritariamente en PDAs más baratos y de menores prestaciones. En lo que respecta a Linux, se han desarrollado varios proyectos, la mayoría abiertos, que buscan satisfacer las demandas de una comunidad creciente de usuarios que, familiarizados con las virtudes que ofrece este sistema operativo en su versión para la PC (tales como la disponibilidad de software libre), desean tener acceso a ellas en sus PDAs. Por desgracia, hasta el momento ninguno de estos poco homogéneos desarrollos posee un enfoque lo suficientemente maduro para ser competitivo, además de que aún no han podido superar la barrera de la compatibilidad, quedando restringidos a una gama específica de modelos. Sin embargo, PalmSource y su actual empresa matriz Access han anunciado que el sistema operativo que reemplazará al Palm OS será de hecho una versión de Linux para PDA, llamada Access Linux Platform o ALP, con lo cual se pretende cumplir con las necesidades y expectativas de este grupo de usuarios, generando convergencia a través de la introducción de una solución seria y mucho más evolucionada que aproveche la experiencia de PalmSource en el diseño de sistemas operativos para PDAs, lo que a su vez reestructurará el actual campo de batalla comercial en el cual PalmSource pierde terreno frente a Microsoft. De esta forma se incrementa el grado de similitud entre los PDAs y las computadoras de escritorio. Por otra parte, la propia naturaleza de estos dispositivos permite, en conjunto con las tecnologías actuales de comunicación inalámbrica (tales como el propio Bluetooth y el Wi-Fi), diseñar soluciones de tipo personal, de manera que la mayoría de las herramientas de diagnóstico, así como los portales de acceso a toda clase de información y servicios, acompañen al médico, transformando el ambiente clínico, de ser dependiente de la distribución espacial de los equipos y la infraestructura, a girar en torno a cada uno de los usuarios de esta tecnología. Los PDAs han un probado tener gran impacto en el ejercicio de la medicina, al proveer acceso a múltiples servicios tanto externos como internos al hospital. Por ejemplo, las compañías Skyscape y Epocrates, así como el servicio gratuito provisto por ABXGuide, ofrecen recursos tales como información sobre medicamentos, opciones de tratamiento, información basada en evidencia (como casos documentados) y noticias que incluyen alertas de seguridad tanto para medicamentos como para procedimientos médicos. A su vez, existen programas diseñados



específicamente para ayudar al médico en el ambiente clínico, tales como el austero programa para seguimiento de pacientes WardWatch, así como algunos no enfocados estrictamente al ambiente clínico pero que aportan grandes ventajas, como el sofisticado HandBase y el ampliamente utilizado Pendragon, ambos dirigidos al manejo de bases de datos. Recientemente se ha incrementado el número de propuestas que implementan varias aplicaciones de ingeniería biomédica utilizando como base estos dispositivos, comprobando así que sus características y rendimiento hacen factibles este tipo de diseños. Dichas aplicaciones incluyen:

• Sistemas de interfaz y control de dispositivos biomédicos. XIII • Sistemas de monitoreo para telemedicina y home-care. XIV • Sistemas de monitoreo a distancia e integración de bases de datos para hospitales. XV, XVI

En los últimos años ha surgido una raza híbrida de dispositivos que combinan las características de un PDA y un teléfono celular, denominados Cellular PDAs o Smartphones dependiendo del enfoque predominante. La mayoría de las proyecciones tecnológicas y de mercado afirman que, en un futuro no muy lejano, los PDAs e incluso la mayoría de los celulares, serán absorbidos por este segmento en expansión. Sin embargo, actualmente los handhelds híbridos carecen de la sofisticación y prestaciones propias de los mayores exponentes de los PDAs, por lo que se considera precisamente a estos últimos en el enfoque propuesto. Aún así, es importante tener en mente que una vez que los dispositivos híbridos evolucionen lo suficiente, no sólo abarcaran el mercado y desplazarán a los PDAs como núcleo de este tipo de soluciones, sino que aportarán nuevas e interesantes posibilidades de diseño a este esquema, empezando por el uso de la telefonía celular para establecer canales de comunicación global enfocados a la medicina, aspecto que ya ha sido explorado en algunas propuestas a través del envío de mensajes SMS utilizando la tecnología GSM. XVII



III.- SISTEMA PROPUESTO. La figura contenida en el Anexo A ilustra el diagrama a bloques del sistema propuesto. En dicho diagrama se observa cada uno de los elementos que conforman ambos tipos de terminales: la del maestro, correspondiente el PDA, y la del esclavo, correspondiente a los micrófonos. La propuesta a implementar en base al actual sistema de adquisición de sonidos respiratorios cubre dos aspectos fundamentales: las herramientas físicas, o hardware, y las herramientas de programación, o software.

III.1.- Hardware. Los elementos necesarios para establecer la comunicación giran en torno a ambas terminales: por un lado la del dispositivo maestro, que consiste en el PDA, y por el otro la del dispositivo esclavo, que estará conformada por un módulo Bluetooth, un microcontrolador y un micrófono. III.1.1.- PDA. En el caso del PDA, se adquirió el modelo Axim X51v de Dell, que, entre otras, presenta las siguientes características:

• Procesador: Intel XScale Bulverde PXA270 a 624MHz. • Sistema Operativo: Microsoft Windows Mobile 5.0. • Memoria: 64MB de SDRAM y 256MB de Flash ROM.

• Pantalla: LCD de 3.7’’ táctil TFT transflexiva de 16 bits de color y resolución de

480 x 640 pixels a 65,536 colores (VGA).

• Gráficas: Acelerador multimedia Intel 2700G con 16MB de video.

• Ranuras de Expansión: CompactFlash tipo II y Secure Digital / SDIO Now! / MMC.

• Puertos y Conectores: Puerto infrarrojo estándar v1.2, conector de sincronización/base de 36 pines y conector de 3.5 mm para auriculares.

• Audio: Chip de sonido WM8750, micrófono y bocinas integrados con conversión

estéreo de 16 bits y 8, 11.025, 22.05 y 44.1 KHz de frecuencia de muestreo. • Inalámbricos: Conectividad 802.11b y Bluetooth integradas, con soporte para los

perfiles GAP, SDAP, SPP, GOEP, DUN, OPP y HID.

La siguiente figura ilustra este modelo de PDA:



20Figura III.1.1: PDA Dell Axim X51v .XVIII

Para más información sobre el PDA Axim X51v se recomienda consultar el sitio correspondiente en Dell.XVIII III.1.2.- Módulo Bluetooth. El módulo Bluetooth propuesto es el Bluegiga Wrap Thor WT11, cuyas características principales son:

• Bluetooth v 2.0 + EDR, CE y FCC. • Dispositivo clase 1 (hasta 100 m). • Modos de modulación de 2 y 3 Mbps.

• Interfaces UART con modo de bypass, USB v2.0, SPI, PCM y PIO.

• Soporte para coexistencia con 802.11.

• 8 Mbits de memoria Flash. • Soporte para los perfiles SPP, DUN, HFP, así como funcionalidad de los protocolos

OBEX y HCI.

• Dimensiones reducidas (35.3mm x 14mm x 2.3mm).

• Montaje de superficie.

• Consumo de energía moderado (alimentación: 3.3± 1VDC y máximo 170mA).

• Blindaje para evitar interferencia por radiofrecuencia.



La versión a utilizar de este módulo, cuyo código es WT11-A-AI, cuenta con dos características especiales que resultan esenciales para esta aplicación:

• Antena integrada.

• Firmware de interfaz de comando para Bluetooth iWRAP. La siguiente figura ilustra este módulo Bluetooth:

21Figura III.1.2: Módulo Bluegiga Wrap Thor WT11 con antena integrada.XIX

Para información más detallada sobre el módulo WT11 se recomienda revisar su documento de especificaciones.XIX III.1.3.- Microcontrolador. En lo que respecta al microcontrolador, no se ha definido un modelo específico, sino una lista de las características principales requeridas para esta aplicación:

• Conversión A/D de por lo menos 12 bits.

• Memoria integrada tanto para programa como para datos.

• Interfaz UART. Mientras que los puntos anteriores deberán ser cumplidos obligatoriamente, los siguientes criterios permitirán escoger la mejor opción a partir de la amplia gama de modelos ofrecidos por varios fabricantes:

• Bajo consumo de energía.

• Dimensiones reducidas.

• Bajo costo. En particular, la familia de microcontroladores de Microchip provee varias soluciones que se apegan a los distintos requisitos del proyecto, además de proporcionar un ambiente de desarrollo familiar debido a la interacción previa de los alumnos con estos dispositivos a lo largo de distintas asignaturas. Por esta razón, se considera que la opción más viable sería la elección de un PIC.



III.1.4.- Micrófono. El sistema actual de adquisición de sonidos respiratorios ya cuenta con un modelo de micrófono, el BT-1834 de la compañía Knowles, cuyas características son:

• Alimentación: 1.3 VDC (funcional hasta 20 VDC) y 50 µA máx. • Impedancia de salida: De 2000 a 6000 Ω (3500 Ω nominal).

• Dimensiones: 5.59 x 4.14 x 7.92 mm máx. y 28gr de peso nominal.

• Sensibilidad nominal: -58.0 dB a 100 Hz.

-57.0 dB a 1000 Hz. -53.5 dB a 10000 Hz.

La siguiente figura ilustra este micrófono:

22Figura III.1.4: Micrófono utilizado en el sistema actual de adquisición de sonidos respiratorios.

III.2.- Software. Es necesario escribir dos programas para establecer la comunicación: el primero, correspondiente al dispositivo esclavo, escrito en lenguaje de bajo nivel y ejecutado por el microcontrolador para digitalizar la señal del micrófono y controlar su envío a través del módulo Bluetooth; el segundo, correspondiente al dispositivo maestro, escrito en lenguaje de alto nivel y ejecutado por el PDA para controlar la comunicación. III.2.1.- Programación del Microcontrolador. Una de las características más importantes del módulo Bluegiga WT11 es el firmware iWRAP. Este firmware, ejecutado exclusivamente en el procesador RISC de los módulos Wrap Thor, implementa la pila de protocolos de Bluetooth completa. El procesador anfitrión se comunica con el iWRAP a través de una interfaz física usando comandos ASCII, con los cuales puede



acceder a la funcionalidad de Bluetooth ignorando la complejidad de la pila de protocolos. La siguiente figura ilustra la organización de la pila iWRAP:

23Figura III.2.1: Pila iWRAP.XX

Si no se necesita controlar al firmware o el sistema anfitrión carece de procesador, el iWRAP puede ser configurado para ser totalmente transparente, únicamente aceptando conexiones o automáticamente abriéndolas. Esto le permitiría actuar autónomamente como un dispositivo Bluetooth de reemplazo de cables. Sin embargo, no toda la funcionalidad estará disponible en este modo. El iWRAP tiene dos modos operacionales: el modo de comando y el modo de datos. Es posible cambiar de modo en cualquier momento siempre y cuando haya por lo menos una conexión activa. El modo de comando es el asumido por omisión cuando se inicializa el iWRAP o en ausencia de conexiones. En este modo, se pueden enviar comandos ASCII al iWRAP para realizar distintas funciones. Los datos entrantes provenientes de dispositivos remotos son enviados a un buffer cuando el iWRAP se encuentra en el modo de comando. El modo de datos es el asumido por omisión cuando existen conexiones activas que permiten el envío o recepción de información, y de hecho sólo está disponible en este caso. En este modo, todos los datos son enviados de manera transparente de la interfaz UART a otro dispositivo y viceversa, a través de un enlace del RFCOMM de Bluetooth. A partir de la versión 2.1.0 del iWRAP, está disponible un modo especial denominado modo de multiplexación. En este modo el firmware no tiene que separar los modos de comando y de datos, pero los datos, comandos y eventos son manejados en un solo modo. Sin embargo existe



un protocolo especial para separar comandos y eventos de los datos. La ventaja del modo de multiplexación es que varias conexiones Bluetooth pueden ser manejadas simultáneamente sin necesidad de perder tiempo en cambiar entre lo modos de comando y de datos. A continuación se presentan algunos detalles técnicos relacionados al uso del iWRAP:

• Nº máximo de conexiones ACL simultáneas: 4. • Nº máximo de conexiones SCO simultáneas: 1.

• Nº máximo de emparejamientos simultáneos: 16.

• Máxima velocidad de transmisión de datos: 650 Kbps (con adaptador Bluetooth v2.0).

570 Kbps (con módulos WT12 o WT11). 450 Kbps (con dispositivo Bluetooth v1.x).

• Máxima velocidad de transmisión a través de la interfaz UART: 921600 bps. • Mínimo retraso de transmisión: De 8 a 15 ms.

• Longitud del PIN: Configurable de 0 a 16 caracteres.

• Longitud del nombre de dispositivo: Configurable de 0 a 248 caracteres.

• Longitud de la encriptación: Configurable de 0 a 128 bits.

• Tamaño de los paquetes RFCOMM: Configurable de 21 a 1008 bits.

• Perfiles Bluetooth soportados: GAP, SPP, OPP, DUN y HFP.

• Modos de baja energía soportados: Sniff, Park y Deep Sleep1.

A continuación se presentan los diferentes comandos ASCII mediante los cuales el dispositivo anfitrión puede controlar al módulo WT11 a través del firmware iWRAP:

• BER: Este comando regresa la Tasa de Error por Bit o BER (Bit Error Rate) del enlace proporcionado como parámetro.

• CALL: Este comando es usado para iniciar conexiones con dispositivos remotos. • CLOSE: Este comando es utilizado para terminar conexiones previamente abiertas. • HELP: Este comando es utilizado para obtener ayuda sobre un tema o aspecto. • INFO: Este comando despliega información sobre la versión y las características del

iWRAP. • INQUIRY: Este comando es usado para efectuar el descubrimiento de dispositivos. • IC: Este comando es usado para cancelar el proceso de descubrimiento actual (Inquiry

Cancel).

1 Modo agresivo de ahorro de energía de los módulos Wrap Thor.



• LIST: Este comando muestra información sobre las conexiones activas. • NAME: Este comando es usado para recuperar el nombre de un dispositivo. • RSSI: Este comando regresa el RSSI del enlace proporcionado como parámetro. • RESET: Este comando es usado para reinicializar el iWRAP. • SCO: Este comando permite establecer enlaces SCO con dispositivos remotos. • SDP: Este comando puede ser usado para explorar los servicios disponibles en otros

dispositivos Bluetooth. • SELECT: Este comando es usado para cambiar al modo de datos. • SET: Este comando se usa para desplegar o configurar diferentes parámetros del

iWRAP. • SLEEP: Este comando forzará al dispositivo a entrar en el modo de ahorro de energía

Deep Sleep. • TESTMODE: Este comando permite el modo de prueba de Bluetooth. • TXPOWER: Este comando puede ser usado para revisar el nivel de potencia de

transmisión de un enlace activo. Estos comandos deben terminar con un caracter LF (Line Feed) “\n”. Para información más detallada sobre el firmware iWRAP se recomienda revisar la guía de usuario.XX III.2.2.- Programación del PDA. En la literatura revisada se proponen dos soluciones distintas para generar un código que controle la comunicación Bluetooth desde el PDA: la primera utiliza como base el lenguaje Windows CE.NET de Microsoft, mientras que la segunda hace uso del lenguaje Java. En esta propuesta se adopta la segunda opción por varias razones que se explicarán conforme se describa dicha solución. III.2.2.1.- Descripción de la Solución en Java. Actualmente, Java cuenta con tres plataformas diseñadas para cubrir distintas necesidades o adaptarse a diferentes escenarios:

• J2ME (Java 2 Platform, Micro Edition). • J2SE (Java 2 Platform, Standard Edition).

• J2EE (Java 2 Platform, Enterprise Edition).

El J2ME, que es la versión utilizada en esta propuesta, es el más compacto de los tres. Comparte la filosofía “write once, run anywhere”, lo que implica que el código generado trasciende



plataformas tanto de hardware (arquitectura del sistema) como de software (sistema operativo), siempre y cuando se cuente con una JVM (Java Virtual Machine). El J2ME es una colección de tecnologías y especificaciones que los desarrolladores pueden escoger y combinar para construir un entorno de ejecución Java que se adapte a los requerimientos de una gama particular de dispositivos o aplicaciones. Cada combinación es optimizada según la memoria, el poder de procesamiento y las capacidades de entrada/salida de la categoría de dispositivos correspondiente. El J2ME está dividido en tres niveles:

• Configuraciones (configurations): Éstas son especificaciones que describen una máquina virtual y un conjunto básico de librerías que proporcionan las APIs (Application Programming Interface) necesarias que pueden ser usadas con una cierta clase de dispositivo. Las configuraciones proveen la funcionalidad básica de una gama particular de dispositivos que comparten características similares, como conectividad y memoria. La máquina virtual puede ser una JVM completa o una sección de ésta. El conjunto de APIs normalmente es un subconjunto de las APIs del J2SE. Actualmente existen dos configuraciones del J2ME: la CDC (Connected Device Configuration), que corresponde a dispositivos con acceso a redes de comunicación incluyendo dispositivos integrados (embedded), y la CLDC (Connected Limited Device Configuration), que corresponde a dispositivos con recursos limitados.

• Perfiles (profiles): Éstos complementan una configuración agregando APIs más

específicas con el fin de crear un entorno de ejecución para implementar aplicaciones en una categoría específica de dispositivos. Un perfil es un conjunto de APIs de nivel superior que describe más a fondo el modelo de aplicación, la interfaz de usuario, el almacenamiento y el acceso a las propiedades específicas del dispositivo.

• Paquetes opcionales (optional packages): Éstos extienden la plataforma J2ME

agregando funcionalidad a la pila de tecnologías que incluye una configuración y perfiles asociados. Creados para cumplir con requisitos de aplicación muy específicos, los paquetes opcionales ofrecen APIs estándar para usar tecnologías tanto existentes como emergentes. Debido a que estos paquetes son modulares, los fabricantes pueden evitar la sobrecarga de una funcionalidad innecesaria al incluir sólo los paquetes que realmente necesita la aplicación. Los paquetes opcionales pueden ser implementados junto con virtualmente cualquier combinación de configuraciones y perfiles.

Las APIs de Java para Bluetooth fueron desarrolladas a través del JCP (Java Community Process) y descritas en un JSR (Java Specification Request). El JSR 82 es el primer estándar abierto y libre para desarrollar aplicaciones Bluetooth usando el lenguaje de programación Java. Éste esconde la complejidad de la pila de protocolos de Bluetooth detrás de un conjunto de APIs



que permiten al desarrollador enfocarse en la aplicación y no en los detalles de bajo nivel de Bluetooth. Las APIs de Java para no implementan la especificación de Bluetooth, sino que proveen métodos para acceder y controlar los dispositivos. El JSR 82 está basado en la versión 1.1 de la especificación de Bluetooth. Sus APIs pueden funcionar con pilas de Bluetooth tanto nativas como de Java. En el primer caso, las APIs utilizan la máquina virtual como interfaz con la pila nativa; en el segundo, las APIs se comunican con la pila directamente. Es posible que los dispositivos Bluetooth que implementen estas APIs permitan la ejecución concurrente de múltiples. El BCC (Bluetooth Control Center) impide que las aplicaciones se dañen entre sí. Consiste en un conjunto de funciones que permite al usuario o al OEM (Original Equipment Manufacturer) resolver solicitudes conflictivas de aplicaciones al definir valores específicos en ciertos parámetros de configuración de la pila de Bluetooth. El BCC puede ser una aplicación nativa, una aplicación con una API independiente o simplemente un grupo de ajustes que son especificados por el fabricante y no pueden ser modificados. El JSR 82 está diseñado para trabajar en dispositivos con las siguientes características:

• 512KB de memoria total (RAM y ROM) mínima (los requisitos de la aplicación son adicionales).

• Implementación del J2ME compatible con la configuración CLDC.

Puesto que la configuración CLDC es un subconjunto de la CDC, las aplicaciones que usen estas APIs deberían funcionar correctamente en dispositivos CDC. De hecho, si se implementa el paquete opcional para J2SE llamado Generic Connection Framework (JSR 197), las APIs del JSR 82 deberían funcionar en esta plataforma. El sistema Bluetooh sobre el cual se implementarán las APIs de Java debe a su vez cumplir con ciertos requisitos:

• El sistema debe soportar y permitir el acceso a los protocolos L2CAP, SDP y RFCOMM.

• El sistema debe soportar los perfiles GAP, SDAP y SPP.

• El sistema debe proveer un BCC.

Por su parte, la arquitectura de las APIs del JSR 82 está diseñada en torno a las siguientes características:

• Provee soporte básico para los protocolos y perfiles de Bluetooth, es decir que no incluye a todos los perfiles ya que la lista crece continuamente.

• Incorpora los protocolos SDP, L2CAP, RFCOMM y OBEX. • Incorpora los perfiles GAP, SDAP, SPP y GOEP

• Permite a los desarrolladores utilizar el lenguaje Java para construir nuevos perfiles a

partir de éstas APIs, siempre y cuando la especificación de las capas del núcleo no cambie.

• Para promover la flexibilidad y extensibilidad, la especificación no está restringida

únicamente a APIs que implementen perfiles de Bluetooth.



El JSR 82 consiste en dos paquetes opcionales que dependen del paquete javax.microedition.io de la plataforma J2ME y son explicados a continuación:

javax.bluetooth: la API nuclear de Bluetooth. Interfaces.

• DiscoveryListener: Permite a una aplicación recibir eventos de descubrimiento de dispositivos y servicios.

• L2CAPConnection: Representa un canal L2CAP orientado a conexión.

• L2CAPConnectionNotifier: Provee un notificador de conexión L2CAP.

• ServiceRecord: Describe las características de un servicio.

Clases.

• DataElement: Define los distintos tipos de datos que puede tener el valor de un atributo de servicio.

• DeviceClass: Representa el registro de clase de dispositivo o CoD (Class of

Device).

• DiscoveryAgent: Provee métodos para realizar el descubrimiento de dispositivos y servicios.

• LocalDevice: Define las funciones básicas del administrador de Bluetooth.

• RemoteDevice: Representa un dispositivo Bluetooth remoto.

• UUID: Define los UUIDs.

Excepciones.

• BluetoothConnectionException: Es arrojada cuando una conexión Bluetooth no puede ser establecida exitosamente.

• BluetoothStateException: Es arrojada cuando se le hace una solicitud al

sistema Bluetooth que no puede ser soportada en ese momento.

• BluetoothRegistrationException: Es arrojada cuando una conexión

existe una falla al agregar un registro de servicio a la base de datos local de descubrimiento de servicio o SDDB (Service Discovery Database), o al modificar registro de servicio existente en la SDDB.



javax.obex: la API del protocolo OBEX.

Interfaces.

• Authenticator: Provee una manera para responder al desafío de autentificación y a los encabezados de respuesta de autentificación.

• ClientSession: Provee métodos para solicitudes OBEX.

• HeaderSet: Define los métodos para asentar y obtener los valores de los

encabezados OBEX.

• Operation: Provee medios para manipular una única operación PUT o GET. • SessionNotifier: Define un notificador de conexión para las conexiones

OBEX del lado del servidor.

Clases.

• PasswordAuthentication: Contiene combinaciones de nombre de usuario y passwords.

• ResponseCodes: Contiene la lista de códigos de respuesta válidos que pueden

ser enviados por el servidor a un cliente.

• ServerRequestHandler: Define un detector de eventos (event listener) que responderá a las solicitudes OBEX hechas al servidor.

La API del protocolo OBEX es independiente del medio de transporte, por lo que puede ser usada sin la correspondiente a Bluetooth. El protocolo OBEX puede ser soportado ya sea en el sistema Bluetooth subyacente o por la implementación de la API. III.2.2.2.- Programación de Aplicaciones. La anatomía de una aplicación de Bluetooth consta de seis partes:

Inicialización de la pila. La pila de Bluetooth es responsable de controlar al dispositivo, por lo que es necesario inicializarla antes de poder efectuar cualquier otra operación. Este proceso comprende un cierto número de pasos cuyo propósito es preparar al dispositivo para la comunicación inalámbrica. Desafortunadamente, la especificación de Bluetooth deja la implementación del BCC a los fabricantes, lo que implica que cada uno maneja la inicialización de la pila de manera distinta. Administración de dispositivos.



Las APIs de Java para Bluetooth contienen las clases LocalDevice y RemoteDevice, las cuales proporcionan capacidades de administración de dispositivos definidas en el GAP. La clase LocalDevice depende en la clase javax.bluetoot.DeviceClass para recabar información sobre el tipo del dispositivo local y los servicios que ofrece. La clase RemoteDevice representa un dispositivo remoto dentro del rango de alcance del local y provee métodos para recabar información sobre el dispositivo, incluyendo su BD_ADDR y su nombre. El método estático LocalDevice.getLocalDevice () regresa un objeto LocalDevice para su uso. Para obtener la BD_ADDR del dispositivo local se utiliza el comando getBluetoothAddress () con dicho objeto. Si se desea que el dispositivo local pueda ser descubierto por otros, se llama al método setDiscoverable () con el mismo objeto. El siguiente segmento de código recaba información sobre el dispositivo local:

... // retrieve the local Bluetooth device object LocalDevice local = LocalDevice.getLocalDevice(); // retrieve the Bluetooth address of the local device String address = local.getBluetoothAddress(); // retrieve the name of the local Bluetooth device String name = local.getFriendlyName(); ...

XXIII

Se puede obtener la misma información sobre un dispositivo remoto:

... // retrieve the device that is at the other end of // the Bluetooth Serial Port Profile connection, // L2CAP connection, or OBEX over RFCOMM connection RemoteDevice remote = RemoteDevice.getRemoteDevice( javax.microedition.io.Connection c); // retrieve the Bluetooth address of the remote device String remoteAddress = remote.getBluetoothAddress(); // retrieve the name of the remote Bluetooth device String remoteName = local.getFriendlyName(true); ...

XXIII

La clase RemoteDevice también provee métodos para autentificar, autorizar y encriptar datos transferidos entre el dispositivo local y el remoto. Descubrimiento de dispositivos.

Debido a que los dispositivos inalámbricos son móviles es necesario un mecanismo que permita encontrar otros dispositivos y ganar acceso a sus capacidades. La clase DiscoveryAgent y la interfaz DiscoveryListener de la API nuclear de Bluetooth proporcionan los servicios de descubrimiento necesarios.



Un dispositivo Bluetooth utiliza un objeto DiscoveryAgent para obtener una lista de dispositivos accesibles de dos maneras distintas:

• El método DiscoveryAgent.startInquiry () pone al dispositivo en modo de encuesta. Para aprovechar este modo, la aplicación debe especificar un detector de eventos que responderá a eventos relacionados con la encuesta. DiscoveryListener.deviceDiscovered es llamado por la JVM cada vez que una encuesta encuentra un dispositivo, devolviendo un objeto RemoteDevice que lo representa. Cuando una encuesta es completada o cancelada, se invoca a DiscoveryListener.inquiryCompleted. Éste método no bloquea al dispositivo local, lo que le permite realizar otras tareas mientras espera el resultado de la encuesta. El siguiente fragmento de código ilustra este planteamiento:

... // retrieve the discovery agent DiscoveryAgent agent = local.getDiscoveryAgent(); // place the device in inquiry mode boolean complete = agent.startInquiry(); ...

XXIII

• Si el dispositivo local no desea esperar a que los dispositivos remotos sean

descubiertos, puede emplear el método DiscoveryAgent.retrieveDevices para obtener una lista existente. Dependiendo del parámetro pasado, éste método regresará ya sea una lista de los dispositivos que fueron encontrados en una encuesta previa, o bien, una lista de dispositivos ya conocidos (pre-known devices) que el dispositivo local ha informado al BCC que contactará a menudo. A continuación se ilustran ambas variantes:

... // retrieve the discovery agent DiscoveryAgent agent = local.getDiscoveryAgent(); // return an array of pre-known devices RemoteDevice[] devices = agent.retrieveDevices(DiscoveryAgent.PREKNOWN); ...

XXIII

... // retrieve the discovery agent DiscoveryAgent agent = local.getDiscoveryAgent(); // return an array of devices found in a previous inquiry RemoteDevice[] devices = agent.retrieveDevices(DiscoveryAgent.CACHED); ...

XXIII



Descubrimiento de servicios. Una vez que el dispositivo local ha descubierto al menos un dispositivo remoto, puede comenzar a buscar servicios disponibles, es decir aplicaciones Bluetooth que puede usar para realizar diferentes tareas. Puesto que el descubrimiento de servicios es muy similar al descubrimiento de dispositivos, la clase DiscoveryAgent también proporciona el método searchServices () para llevar a cabo este proceso. Es importante resaltar que la API provee mecanismos para buscar servicios en dispositivos remotos más no en el dispositivo local. En caso de haberse implementado la interfaz DiscoveryListener, la JVM llamará a servicesDiscovered () cuando se encuentren servicios. Éste método también regresa un objeto ServiceRecord que pertenece al servicio buscado y permite conectarse al dispositivo remoto que originó este objeto:

... String connectionURL = servRecord[i].getConnectionURL(0, false); ...

XXV

Registro de servicios.

Antes de que un dispositivo Bluetooth cliente pueda realizar el descubrimiento de servicios en un dispositivo Bluetooth servidor, este último debe registrar sus servicios internamente en la SDDB. El servidor es responsable de

• Crear un registro de servicio que describa el servicio ofrecido. • Agregar el registro de servicio a la SDDB para que sea visible y esté disponible

a clientes potenciales.

• Registrar las medidas de seguridad de Bluetooth asociadas con el servicio.

• Aceptar conexiones de clientes.

• Actualizar el registro de servicio en la SDDB cada vez que los atributos del servicio cambien.

• Eliminar o deshabilitar el registro de servicio en la SDDB cuando el servicio

deje de estar disponible. A continuación se presentan los pasos necesarios en el proceso de registro de servicios:

1. Llamar a Connector.open () con el URL (Uniform Resource Locator) de una conexión de servidor como argumento y enviar el resultado (Connection) a un StreamConnectionNotifier. Connector.open () crea un nuevo ServiceRecord y establece algunos atributos.

2. Usar el objeto LocalDevice y el StreamConnectionNotifier para obtener

el ServiceRecord creado por el sistema. Opcionalmente se pueden modificar sus atributos.



3. Usar el StreamConnectionNotifier y llamar a acceptAndOpen () para indicar que el servicio está listo para aceptar una conexión de cliente. El sistema crea un registro de servicio en la SDDB. Posteriormente se debe esperar a que un cliente descubra el servicio y se conecte ya que acceptAndOpen () bloquea al dispositivo.

4. Cuando el servidor está listo para salir, llamar a close () en el

StreamConnectionNotifier para cerrar la conexión. El sistema elimina el registro de servicio de la SDDB.

Tanto StreamConnectionNotifier como Connector provienen del paquete javax.microedition.io. A continuación se presenta un fragmento de código que ilustra estos pasos:

... // step #1 // the String url will already be defined with the // correct url parameters notifier = (StreamConnectionNotifier)Connector.open(url); // step #2 // we will get the LocalDevice if not already done so localdevice = LocalDevice.getLocalDevice(); servicerecord = localdevice.getRecord(notifier); // step #3 // this step will block the current thread until // a client responds this step will also cause the // service record to be stored in the SDDB notifier.acceptAndOpen(); // step #4 // this causes the service record to be removed // from the SDDB notifier.close(); ...

XXV

Comunicación.

Para que un dispositivo local pueda usar un servicio disponible en un dispositivo remoto, ambos deben compartir un protocolo de comunicaciones común. Con el fin de que las aplicaciones puedan acceder a una gran variedad de servicios de Bluetooth, las APIs de Java para esta tecnología proporcionan mecanismos que permiten conexiones a cualquier servicio que utilice como protocolo el L2CAP, el RFCOMM o el OBEX. Si un servicio utiliza otro protocolo instalado sobre estos, la aplicación puede tener acceso al servicio siempre y cuando implemente el protocolo adicional usando el Generic Connection Framework de la configuración CLDC. En esta sección sólo se cubrirá la comunicación utilizando el protocolo RFCOMM a través del perfil SPP. Algunas capacidades y limitaciones de la comunicación mediante este perfil deben ser conocidas:

• Dos dispositivos pueden compartir solamente una sesión RFCOMM a la vez.



• Hasta 60 conexiones seriales lógicas pueden ser multiplexadas en esta sesión.

• Un dispositivo Bluetooth puede tener hasta 30 servicios RFCOMM activos.

• Un dispositivo puede soportar solamente una conexión de cliente a un servicio

dado a la vez. Para que un servidor y un cliente se comuniquen usando el SPP, cada uno debe realizar algunos simples pasos. En el caso del servidor, se debe:

1. Construir un URL que indique como conectarse al servicio y almacenarlo en el registro de servicio.

2. Asegurarse de que el registro de servicio está disponible para el cliente.

3. Aceptar la conexión del cliente.

4. Enviar y recibir datos hacia y desde el cliente.

Cabe resaltar que este proceso es muy parecido al utilizado para el registro de servicios. El URL asentado en el registro de servicio puede ser algo como esto: btspp://102030405060740A1B1C1D1E100:5 De esta forma se indica que el cliente deberá usar el SPP de Bluetooth (btspp) para establecer una conexión con este servicio, que está identificado con el canal de servidor 5 en un dispositivo cuya dirección es 102030405060740A1B1C1D1E100, que a su vez corresponde a un UUID que puede ser de 32 o 128 bits. El siguiente extracto de código ilustra el procedimiento de apertura de una conexión con el SPP par un servidor:

... // assuming the service UID has been retrieved String serviceURL = "btspp://localhost:"+serviceUID.toString()); // more explicitly: String ServiceURL = "btspp://localhost:10203040607040A1B1C1DE100;name=SPP Server1"; try // create a server connection StreamConnectionNotifier notifier = (StreamConnectionNotifier) Connector.open(serviceURL); // accept client connections StreamConnection connection = notifier.acceptAndOpen(); // prepare to send/receive data byte buffer[] = new byte[100]; String msg = "hello there, client"; InputStream is = connection.openInputStream();



OutputStream os = connection.openOutputStream(); // send data to the client os.write(msg.getBytes()); // read data from client is.read(buffer); connection.close(); catch(IOException e) e.printStackTrace(); ...

XXIII

En el extremo opuesto, el cliente debe:

1. Iniciar un descubrimiento de servicios para obtener el registro de servicio. 2. Construir un URL de conexión a partir del registro de servicio.

3. Abrir una conexión con el servidor.

4. Enviar y recibir datos hacia y desde el servidor.

A continuación se presenta un segmento de código que ilustra el procedimiento de establecimiento de una conexión con el SPP par un cliente:

... // (assuming we have the service record) // use record to retrieve a connection URL String url = record.getConnectionURL( record.NOAUTHENTICATE_NOENCRYPT, false); // open a connection to the server StreamConnection connection = (StreamConnection) Connector.open(url); // Send/receive data try byte buffer[] = new byte[100]; String msg = "hello there, server"; InputStream is = connection.openInputStream(); OutputStream os = connection.openOutputStream(); // send data to the server os.write(msg.getBytes); // read data from the server is.read(buffer); connection.close(); catch(IOException e) e.printStackTrace(); ...

XXIII

Para información más detallada sobre la implementación de Bluetooth con Java se recomienda revisar el libro que propone esta solución.XXII



III.3.- Consideraciones Adicionales. En la aplicación propuesta se utilizarán dos perfiles:

• SDAP (service discovery application profile) para iniciar la comunicación e identificar los micrófonos.

• SPP (serial port profile) para realizar la transmisión de los datos.

Actualmente se cuenta con los recursos tanto físicos como logísticos para abordar el problema desde la perspectiva del PDA. Para implementar la solución propuesta se necesitan cuatro elementos:

• Dispositivos Bluetooth (al menos dos). • Anfitrión de Bluetooth (sistema que controlará a los dispositivos Bluetooth). • Pila de Bluetooth (implementada en el anfitrión). • API de Java para Bluetooth (utilizada por el anfitrión).

Uno de los dispositivos Bluetooth podría considerarse como integrado en el propio PDA, mientras que el otro puede ser uno de los dos adaptadores USB adquiridos previamente. El anfitrión de Bluetooth es de hecho el PDA, aunque para fines prácticos se podría atacar inicialmente el problema utilizando como sistema anfitrión a la computadora que utilice el adaptador. Se asume que la pila de Bluetooth será la incluida (nativa) en el propio PDA. La API de Java está disponible para ser descargada libremente, junto con las plataformas necesarias para utilizarla (J2ME y adicionalmente J2SE si se desea emplearla en una PC), en Java Sun Developper Network (SDN) en el sitio:

http://java.sun.com/downloads/. En el caso de los micrófonos, se cuenta con información sobre el firmware iWRAP, la cual incluye ejemplos de código que podrían ser utilizados como base para construir el programa correspondiente. Sin embargo, no se han adquirido ni el microcontrolador ni el módulo, y existe información adicional sobre el uso del último que sólo puede ser revisada por clientes de la compañía, es decir que será accesible una vez que se realice la compra. Por lo tanto, esta sección de la implementación aún no puede ser atacada. Una vez perfeccionada la comunicación, será necesario construir el programa principal, el cual contará con una GUI (interfaz gráfica de usuario) capaz de controlar remotamente la adquisición de las señales y proveer diversas opciones de despliegue y procesamiento de las mismas, así como de almacenamiento local y en medios extraíbles. Este programa utilizaría el código creado en Java como una función para acceder al hardware de transmisión/recepción y adquirir las señales. Las opciones para construir este programa se ven drásticamente limitadas a la versión de C para Windows Mobile debido a la falta de interés de la mayoría de las empresas por desarrollar lenguajes científicos de programación para este tipo de plataformas. Afortunadamente, existe una excepción: la compañía suiza de desarrollo de software Calerga Sarl proporciona como alternativa el LME for Pocket PC, el cual es un lenguaje derivado de otro de sus productos (Sysquake) que permite utilizar comandos y funciones compatibles con Matlab en plataformas que utilicen el sistema operativo Windows Mobile, soportando incluso compatibilidad con C. Este es un producto en desarrollo, lo que implica que aún tiene ciertas



restricciones y problemas, siendo los más notables aquellos que afectan las capacidades gráficas y de creación de interfaces. Aún así, esta podría ser una opción que simplifique en gran medida la construcción del programa principal, sobre todo si se contara en un futuro no muy lejano con la versión comercial definitiva. Para más información sobre el software LME for Pocket PC se recomienda consultar el sitio correspondiente.XXVI Actualmente se han efectuado varias pruebas de transmisión entre dos PCs a través de los adaptadores USB, utilizando archivos correspondientes a registros de sonidos respiratorios, con el fin de evaluar las características de la tecnología Bluetooth y sus posibles efectos en la integridad de estas señales. Empleando el paquete Matlab, se obtuvo, posteriormente a la transmisión, el espectro en frecuencia de los archivos ubicados en cada terminal, es decir de la versión original y de la recibida. La siguiente figura muestra un ejemplo de los resultados obtenidos con este método:

0 5000 10000 15000-200

-100

0

100

200

Tiempo (ms)

Voltaje (V)

Señal de sonido respiratorio original

0 5000 10000 15000-200

-100

0

100

200

Tiempo (ms)

Voltaje (V)

Señal de sonido respiratorio recibida

0 500 1000 1500 20000

1000

2000

3000

4000

5000

Frecuencia (Hz)

Amplitud

FFT de la señal de sonido respiratorio original

0 500 1000 1500 20000

1000

2000

3000

4000

5000

Frecuencia (Hz)

Amplitud

FFT de la señal de sonido respiratorio transmitida

24Figura III.3.1: Graficas y espectros de la señal original y la recibida.

Se observa claramente que ambas señales, junto con sus espectros, son idénticas entre sí. Sin embargo, para no depender de un juicio subjetivo, se empleó la función de coherencia para comparar ambas señales. Dicha función indica el índice de coincidencia entre dos señales mediante un número entre cero y uno, en donde el uno corresponde a la igualdad del contenido en esa frecuencia. La siguiente figura presenta la gráfica correspondiente a partir del ejemplo anterior:



0 200 400 600 800 1000 1200 1400 1600 1800 20000

0.2

0.4

0.6

0.8

1

Frecuencia (Hz)

Coherencia

Coherencia entre la señal original y la recibida

25Figura III.3.2: Gráfica de la coherencia entre la señal original y la recibida.

Una vez más, de acuerdo con los resultados de la función de coherencia, se llega a la conclusión de que ambas señales son idénticas. A partir de este desarrollo, por medio del cual se obtuvieron resultados similares en el 100% de las pruebas, se comprueba que la tecnología Bluetooth no tiene efecto alguno sobre el contenido de los archivos transmitidos, particularmente en el caso de los registros de sonidos respiratorios, por lo que la propuesta es viable. Sin embargo, debido a que la naturaleza de este proyecto demanda conocimientos que no son propios de la formación de un Ing. Biomédico, se recurrirá a la asesoría de diversos actores que puedan acelerar el proceso de implementación de este diseño, ya sea ofreciendo la experiencia obtenida en proyectos similares o su conocimiento en áreas específicas involucradas en la creación de este prototipo, particularmente en materia de programación. Adicionalmente, se contempla la posibilidad de adquirir un kit de desarrollo diseñado por uno de los autores del libro que propone la solución para Java: Bruce Hopkins. El kit JB-22 Standard tiene un costo de US$ 320 (incluyendo el envío a México) y consta de:

• Dos adaptadores Bluetooth versión 2.0+EDR de interfaz USB. • Un CD de instalación del hardware para Windows. • Un CD con el software de desarrollo JB-22 basado en Java (APIs del JSR 82 y código

de ejemplo). • Una copia del libro “Bluetooth for Java”. • Una copia del manual “JB-22 Getting Started Guide”.XXVII



Mediante el uso de este kit se buscará acelerar el proceso de aprendizaje y obtener la experiencia práctica inicial necesaria para enfrentar adecuadamente los problemas que pueda implicar este diseño.




ANEXO A

Diagrama a Bloques del Sistema Propuesto.

BLUETOOTH Transmisor /

Receptor de Bluetooth

(integrado)

MAESTROESCLAVO

PDA

Programa en Java

Programa en ensamblador

Microcontrolador Módulo

Interfaz Transmisor / Receptor A/D de UART Bluetooth

Micrófono


REFERENCIAS:

I. - “Nuevas Perspectivas en la Evaluación Automatizada de los Sonidos Respiratorios”, Georgina Chi Lem, Ramón González Camarena, Rev. Inst. Nal. Enf. Resp. Mex. [online], oct. / dic. 2001, vol.14, no.4. Disponible para consulta electrónica en la Revista del Instituto Nacional de Enfermedades Respiratorias en el sitio: http://scielo-mx.bvs.br/scielo.php?pid=S0187-75852001000400001&script=sci_arttext.

II. - “Wireless Internet Handbook: Technologies, Standards, and Applications”, Borko Furht (Editor), Mohammad Ilyas (Editor), CRC Press. Disponible para consulta electrónica a través de la membresía de la UAM en books24x7 en el sitio: http://www.books24x7.com. Capítulo 13: “Wireless Communications using Bluetooth”, Oge Marques, Nitish

Barman.

III. - “Bluetooth Tutorial”. Disponible para consulta electrónica en Palo Wireless: Bluetooth Resource Center en el sitio: http://www.palowireless.com/infotooth/tutorial.asp.

IV. - “Bluetooth Glossary”. Disponible para consulta electrónica en Palo Wireless: Bluetooth Resource Center en el sitio: http://www.palowireless.com/infotooth/glossary.asp.

V. - “Funcionamiento de la tecnología Bluetooth”. Disponible para consulta electrónica en el Sitio Web oficial de la tecnología Bluetooth: http://spanish.bluetooth.com/Bluetooth/Learn/Works/.

VI. - “Bluetooth for Java”, Bruce Hopkins, Ranjith Antony, Apress. Disponible para consulta electrónica a través de la membresía de la UAM en books24x7 en el sitio: http://www.books24x7.com. Capítulo 2: “Bluetooth 1.1”.

VII. - “Introduction to Bluetooth: Technology, Market, Operation, Profiles, and

Services”, Lawrence Harte, Althos. Disponible para consulta electrónica a través de la membresía de la UAM en books24x7 en el sitio: http://www.books24x7.com.



VIII. - “Especificación de Bluetooth”, Alberto Moreno Tablado. Disponible para consulta electrónica en El Blog de Gospel en el sitio: http://gospel.endorasoft.es/especificacion-bluetooth/estandar-bluetooth/index.html.

IX. - “Complexity and performance analysis of the digital modem for the Enhanced Data Rate Bluetooth standard”, Alberto Gozzi. Disponible en formato electrónico (PDF) en la Università di Pisa: Sistema ETD en el sitio: http://etd.adm.unipi.it/theses/available/etd-06112004-110434/. Capítulo 2: “Bluetooth Baseband Specifications”.

X. - “Taking a Walk Inside Bluetooth EDR”, David McCall, Cambridge Silicon

Radio (CSR). Disponible para consulta electrónica en Wireless Net DesignLine en el sitio: http://www.wirelessnetdesignline.com/howto/showArticle.jhtml;jsessionid=DBH3XF3NW3NKKQSNDLOSKHSCJUNN2JVN?articleId=55800398&pgno=1.

XI. - “Bluetooth Tutorial”, Dennis Sweeney, Max Robert. Disponible en formato electrónico (PDF) en MPRG (The Mobile and Portable Research Group) en el sitio: http://www.mprg.org/publications/presentations/bt_tut.pdf.

XII. - “Glosario de Telecomunicaciones (actualizado a Febrero de 2006)”, Ermanno Pietrosemoli, Universidad de los Andes de Mérida (Venezuela). Disponible en formato electrónico (PDF) en WiLAC: Tecnologías Inalámbricas para el Desarrollo en América Latina en el sitio: http://www.wilac.net/descargas/documentos/glosario%20telecomunicaciones.pdf.

XIII. - “Wireless Real-Time Head Movement System Using a Personal Digital Assistant (PDA) for Control of a Power Wheelchair”, D. A. Craig, H. T. Nguyen, Proceedings of the 2005 IEEE Engineering in Medicine and Biology 27th Annual Conference Shanghai, China, September 1-4, 2005.

XIV. - “A PDA-Based ECG Beat Detector for Home Cardiac Care”, K. W. Goh, J. Lavanya, Y. Kim, E. K. Tan, C. B. Soh, Proceedings of the 2005 IEEE Engineering in Medicine and Biology 27th Annual Conference Shanghai, China, September 1-4, 2005.

XV. - “A Wireless Physiological Signal Monitoring System with Integrated Bluetooth and WiFi Technologies”, Sung-nien Yu, Jen-Chieh Cheng, Proceedings of the 2005 IEEE Engineering in Medicine and Biology 27th Annual Conference Shanghai, China, September 1-4, 2005.

XVI. - “Indoor Telemedicine in Hospital: a PDA-Based Flexible Solution for Wireless Monitoring and Database Integration”, Diego Salamon, Mauro Grigioni, Matteo Gianni, Micaela Liberti, Stefano De Luca, Andrea Bei, Guglielmo



D’Inzeo, Proceedings of the 2005 IEEE Engineering in Medicine and Biology 27th Annual Conference Shanghai, China, September 1-4, 2005.

XVII. - “EasiMed: A Remote Health Care Solution”, Ze Zhao, Li Cui, Proceedings of the 2005 IEEE Engineering in Medicine and Biology 27th Annual Conference Shanghai, China, September 1-4, 2005.

XVIII. - “Dell Axim X51v Details”. Disponible para consulta electrónica en Dell en el sitio: http://www.dell.com/content/products/productdetails.aspx/axim_x51v?c=us&cs=19&l=en&s=dhs.

XIX. - “WT11 Data Sheet Version 2.1”. Disponible en formato electrónico (PDF) en Bluegiga Technologies en el sitio: http://www.bluegiga.com/default.asp?file=238.

XX. - “iWRAP 2.1.0 User Guide Version 1.5”. Disponible en formato electrónico (PDF) en Bluegiga Technologies en el sitio: http://www.bluegiga.com/default.asp?file=210.

XXI. - “Java ME Technologies at a Glance”. Disponible para consulta electrónica en Java Sun Developper Network (SDN) en el sitio: http://java.sun.com/javame/technologies/index.jsp.

XXII. - “Bluetooth for Java”, Bruce Hopkins, Ranjith Antony, Apress. Disponible para consulta electrónica a través de la membresía de la UAM en books24x7 en el sitio: http://www.books24x7.com. Capítulo 3: “Before You Get Started”.

XXIII. - “Part II: The Java APIs for Bluetooth Wireless Technology”, Qusay H.

Mahmoud. Disponible para consulta electrónica en Java Sun Developper Network (SDN) en el sitio: http://developers.sun.com/techtopics/mobility/midp/articles/bluetooth2/index.html.

XXIV. - “JSR 82 Bluetooth API and OBEX API”. Disponible para consulta electrónica en Sun Microsystems en el sitio: http://java.sun.com/javame/reference/apis/jsr082/.

XXV. - “Getting Started with Java and Bluetooth”, Bruce Hopkins. Disponible para consulta electrónica en Java.net: the source for Java Technology Colaboration en el sitio:



http://today.java.net/pub/a/today/2004/07/27/bluetooth.html?page=last&x-maxdepth=0.

XXVI. - “LME for Pocket PC”. Disponible para consulta electrónica en Calerga Sarl en el sitio: http://www.calerga.com/products/LMECE/index.html.

XXVII. - “JB-22 Development Kit”. Disponible para consulta electrónica en Java Bluetooth.com en el sitio: http://www.javabluetooth.com/jb22.html.


Documents

PROPUESTA DE UN SISTEMA PORTÁTIL E …148.206.53.84/tesiuami/UAMI13387.pdf · En ese sentido, los trabajos de investigación están orientados a desarrollar mejores sistemas de adquisición