Redes de Área Local e Interconexión de Redes

Bluetooth Introduccion Bluetooth es la especificación técnica de una nueva tecnología de comunicación inalámbrica, que posibilita la transmisión de voz y datos entre diferentes equipos mediante un enlace por radiofrecuencia. El principal objetivo que se pretende conseguir con esta norma es facilitar la comunicación entre equipos móviles y fijos, eliminando cables y conectores entre éstos. Está previsto adoptar a Bluetooth como el estándar IEEE 802.15 dentro del grupo PAN (Personal Area Networks) de la organización IEEE. La tecnología Bluetooth comprende hardware, software y requerimientos de interoperabilidad, por lo que para su desarrollo ha sido necesaria la participación de los principales fabricantes de sectores tan importantes como los de telecomunicaciones e informática. Las marcas que han participado son principalmente Ericsson, Nokia, Toshiba, IBM e Intel. Se prevé que empresas de otros sectores (tales como fabricantes de juguetes, ocio, electrodomésticos) vayan incorporándola a sus productos, debido a sus características de bajo coste y consumo. Bluetooth se utiliza para la creación de pequeñas redes de comunicación inalámbrica, con lo que cualquier equipo móvil podrá intercambiar información con otro. Pero además de cámaras, PDAs, fijos y portátiles, sus características de bajo coste y consumo la hacen adecuada para un gran número de quipos de otros sectores (automóviles, juguetes, maquinaria...), con lo que se abre un horizonte de posibilidades muy amplio. La versión actual de la especificación Bluetooth es la 1.1, del 22 de febrero de 2001, posterior a la 1.0 y 1.0b. Bluetooth se trata de una norma abierta en constante revisión y mejora, y se esperan nuevas revisiones según se avance en la incorporación de nuevos productos y escenarios de uso. Periódicamente, además, tiene lugar un evento organizado por el SIG (el UnPlugFest) donde los fabricantes y desarrolladores tienen la oportunidad de probar sus equipos mediante unas sesiones de test, para asegurar la plena interoperabilidad con equipos de otros fabricantes.

Especificación Bluetooth La especificación Bluetooth se divide en 2 volúmenes: El núcleo y los perfiles. La especificación Bluetooth puede obtenerse de la página web creada por el SIG, www.bluetooth.org, que mantiene actualizados tanto los perfiles como las versiones de la especificación Bluetooth. En la especificación del núcleo se describe las características de radio, la jerarquía de protocolos y la funcionalidad. Los perfiles son un conjunto de mensajes y procedimientos para una situación de uso concreta del equipo. El concepto de perfil se utiliza para asegurar la interoperabilidad entre varias unidades Bluetooth que cumplan los mismos perfiles. Cada dispositivo Bluetooth tiene al menos un perfil, es decir, una aplicación para la cual se puede utilizar el dispositivo. Para que pueda interoperar con otro equipo, debe tener un perfil compartido. Algunos ejemplos de perfiles son:

• Generic Access Profile (GAP). • Service Discovery Application Profile (SDAP). • Cordless Telephony Profile (CTP). • Serial Port Profile (SPP). • Dial-up networking Profile (DUN).

Veremos primero una introducción a la pila de protocolos Bluetooth, y después analizaremos capa a capa las características de Bluetooth. Nos centraremos para cada capa en los aspectos que sean más importantes para el desarrollo de las practicas. La pila de protocolos Bluetooth La pila de protocolos Bluetooth confiere al sistema de una versatilidad perfecta para el trabajo en entornos heterogéneos. La figura 1 muestra los principales componentes. Figura 1. Pila de protocolos Bluetooth Veamos una pequeña introducción a ellos antes de entrar de lleno en la especificación.

• Bluetooth Radio (RF): Es la capa física y consta de un simple chip de radio de baja potencia, bajo consumo y bajo coste. El chip tiene tres modos de ahorro de energía llamados Sniff, Hold y Park. Esta capa permite un rápido mecanismo de salto en frecuencia y una gran protección a interferencias de otros dispositivos.

Dispone también de un rápido ARQ con mecanismo de control de errores (FEC).

• Bluetooth Baseband: Permite el enlace físico de las capas RF de distintos dispositivos formando una piconet. Esta capa controla la sincronización y la secuencia de salto en frecuencia. Los dos tipos diferentes de enlaces definidos en Bluetooth, los enlaces de sincronización de conexión orientada (SCO) para audio y los enlaces asíncronos de baja conexión (ACL) para datos, son manejados en este nivel.

• Link Manager Protocol (LMP): Es responsable de la configuración del enlace entre dispositivos Bluetooth. Controla y negocia el tamaño de los paquetes usados al transmitir datos y los modos del chip de radio, el consumo de energía y el estado del dispositivo en una piconet. La capa LMP también controla los mecanismos de autenticación y encriptación.

• Host Controller Interface (HCI): La capa HCI proporciona una interface para acceder a las posibilidades del hardware, proporcionando comandos para acceso a las capas Baseband y LMP.

• Logical Link Control and Adaptation Protocol (L2CAP): La L2CAP es la capa de transporte de la pila. Las principales tareas que lleva a cabo incluyen multiplexación de protocolos, segmentación y reensamblado, calidad de servicio y manipulación de grupos. La capa de sesión puede contener diferentes protocolos. Así, por ejemplo, pueden enviarse paquetes TCP/IP con Bluetooth.

• Service Discovery Protocol (SDP): Define cómo una aplicación cliente puede descubrir servidores disponibles y sus características. El SDP proporciona medios al cliente para buscar y descubrir servicios basados en atributos concretos sin conocimiento anterior de ellos, y también para detectar cuándo un servicio ya no está disponible.

Bluetooth Radio El sistema Bluetooth opera en la banda ISM de los 2.4 GHz. En la gran mayoría de países del mundo el rango de esta banda de frecuencia es 2400-2483.5 MHz y no requiere licencia (con restricciones en Francia, España y Japón). En España, el visto bueno a su uso se recoge en el Suplemento del Numero 164 del BOE (Boletín Oficial del Estado), siendo la autoridad que lo aprobó el Cuadro Nacional De Atribución de Frecuencias. Y con el objetivo de tratar el problema de las interferencias se incluye un algoritmo de salto en frecuencia, cambiándola cada 645 µs y consiguiendo así una velocidad de cambio de frecuencia de 1600 saltos/seg. La capa RF define 79 canales como f=2402 + kMHz, k=0,...,78 Es decir, el primer canal comienza en 2.402 con una banda inferior de protección de 2MHz. Cada canal está separado del siguiente por 1Mhz de frecuencia y el último canal, situado en los 2.48 GHz, dispone de una banda de protección superior de 3.5 MHz. En aquellos países con limitaciones en este rango de frecuencias, como Francia, España y Japón, los canales se definen como f= 2454 + kMhz, k=0,...,22. En cuanto a las características de transmisión, existen para Bluetooth tres clases de energía con distintas características. En la tabla 2 se muestran estas tres clases de energía, junto a su potencia máxima y mínima y su rango de alcance.

Clase

Máximan energía desalida (Pmax)

Mínima energía desalida (Pmin)

Control de la energía

Alcance

1

100 mW (20 dBm)

1 mW (0 dBm)

Pmin to Pmax Pmin<+4 dBm to Pmax

100m

2

2.5 mW (4 dBm)

0.25 mW (-6 dBm)

Pmin to Pmax

10m

3

1 mW (0 dBm)

N/A

Pmin to Pmax

6m

Tabla 2. Características de energía de los dispositivos Bluetooth El control de energía es obligatorio para los equipos de la clase 1 y se usa para limitar la energía transmitida sobre 0dBm. Los equipos de clase 1 que tienen una energía máxima de transmisión de +20dBm deben ser capaces de controlarla por debajo de los 4dBm. Para las otras dos clases es opcional y puede ser usada para optimizar el consumo de energía y el nivel de interferencia. El asunto de las clases de energías es clave para el buen funcionamiento de algunas funciones. Así, mientras se realiza una inquiry o un page ("preguntar" o "llamar" a otros dispositivos Bluetooth) se recomienda el empleo de la clase 2 o 3, pues sería posible que un dispositivo de clase 1 no obtuviera respuesta. Esto es debido a que el umbral de sensibilidad de un receptor de radio Bluetooth se define en el punto en el que el BER de los datos entrantes es menor o igual al 0.1%, lo que ocurre aproximadamente a un nivel de entrada de -70dBm. Así, un equipo de la clase 1 buscando a vecinos que se encuentran muy próximos a él puede crear una energía de entrada mayor que la requerida. Se usa la modulación binaria de FM GFSK (Gaussian Frequency Shift Keying) con una frecuencia de corte BT = 0.5. Un uno binario se representa por una desviación positiva de la frecuencia y un cero binario por una desviación negativa de la frecuencia. Para cada canal de transmisión, la desviación mínima de la frecuencia que corresponde a la secuencia 1010 no debería ser menor de ±80% de la frecuencia de desviación que corresponde a la secuencia 00001111. Figura 2. Actual modulación de transmisión Además, la desviación mínima no debe ser nunca menor de 115kHz. Tiene una razón de símbolos de 1Ms/s, y la diferencia entre el periodo de símbolos ideal y el tiempo

medido (que en la Figura 2 aparece como Zero Crossing Error) debe ser menor que ± 1/8 de un periodo de símbolo. Baseband Specification Bluetooth trata de reemplazar los cables que conectan dispositivos electrónicos portátiles o fijos con un enlace de radio de corto alcance. Sus características principales son su robustez, baja complejidad, bajo coste y bajo consumo de energía. Opera en la banda ISM en los 2.4 GHz, y añade un transceptor de salto en frecuencia para combatir las interferencias y modulación FM para reducir la complejidad del transceptor. Los canales con que trabaja Bluetooth se ranuran en tamaños de 625 µs. En un canal, la información se intercambia mediante paquetes, donde cada uno se transmite en un salto diferente de frecuencia. Un paquete cubre una ranura, pero puede extenderse para cubrir hasta cinco ranuras, que pueden reservarse para paquetes síncronos. Bluetooth puede soportar un canal de datos asíncrono, hasta tres canales síncronos de voz o un canal que soporte simultáneamente datos asíncronos y voz síncrona. Cada canal de voz soporta una transmisión de 64 kb/s, mientras en un canal asimétrico pueden soportarse como máximo 723.2 Kb/s de forma asimétrica o 433.9 kb/s de forma simétrica. El sistema Bluetooth consta de una unidad de radio (ya presentada), una unidad de control de enlace, una unidad de soporte para el control del enlace y funciones de interface con el host (ver Figura 3).

Figura 3. Bloques funcionales en el sistema Bluetooth Este sistema proporciona una conexión punto-a-punto o punto-a-multipunto. En este último caso, el canal se comparte entre varias unidades, formando una piconet. Una unidad Bluetooth actúa como maestra de la piconet, mientras el resto actúan como esclavas. Hasta siete esclavos pueden estar activos en una piconet, pudiendo ser muchos más en estado parked, que permanecen sincronizados con el maestro. Tanto para los esclavos activos como parked, el canal de acceso está controlado por el maestro. Y múltiples piconets que superponen su área de cobertura forman una scatternet. Así, los esclavos pueden participar en diferentes piconets usando multiplexación basada en el tiempo. Además, un maestro en una piconet puede ser esclavo en otra.

Canal y enlace físico El canal se representa por una secuencia de salto pseudo-aleatoria entre los 79 o 23 canales RF. La secuencia de salto es única para la piconet y está determinada por la dirección del dispositivo maestro mientras la fase está determinada por el reloj del mismo. El canal está dividido en ranuras de tiempo donde cada ranura se corresponde con un salto de frecuencia RF y tienen una longitud de 625 µs. Se numeran en función del reloj del maestro y la numeración va desde 0 hasta 227 - 1 de forma cíclica. Para permitir que maestro y esclavo transmitan de forma alternativa, el maestro debe comenzar su transmisión en las ranuras pares y el esclavo en las impares, usando un esquema TDD (ver figura 4). Así como para los paquetes simples, el salto en frecuencia se deriva por el valor del reloj actual, para paquetes con múltiples ranuras, se deriva del valor del reloj de la primera ranura del paquete. En la figura 5 se muestra la definición de salto en paquetes de una y múltiples ranuras.

Figura 4. Transmisión mediante TDD

Figura 5. Salto en paquetes con una y múltiples ranuras

Hay que diferenciar además los diferentes tipos de enlaces que pueden establecerse entre el maestro de una piconet y los esclavos. Dos tipos se han definido en la especificación Bluetooth:

• Synchronous Connection-Oriented (SCO) : Se trata de un enlace punto-a-punto entre un esclavo y un maestro, donde éste mantiene el enlace SCO usando ranuras reservadas en intervalos fijos. Es el tipo de paquete usado para transportar audio y voz.

• Asynchronous Connection-Less (ACL): Se trata de un enlace punto-a-

multipunto entre el maestro y todos los esclavos. Un enlace SCO se emplea normalmente para información de tiempo crítico como el audio. Un maestro puede llegar a tener tres enlaces SCO con uno o varios esclavos. Y un esclavo puede tener tres enlaces SCO con el mismo maestro o hasta dos con diferentes maestros. Los paquetes se envían por el canal a intervalos regulares de un número de ranuras Tsco. El enlace se establece por el maestro enviando un mensaje de configuración a través del protocolo LM que contiene los parámetros Tsco y el offset Dsco para especificar las ranuras reservadas. Este mensaje de configuración LM contiene un flag que indica si se usará el procedimiento de inicialización 1 o el 2, dependiendo de si el MSB del reloj actual del maestro (CLK27) es 0 o 1, respectivamente. Las ranuras maestro-a-esclavo se reservan siguiendo la siguiente ecuación: Para la inicilización1 : CLK27-1 mod Tsco = Dsco Para la inicialización 2: (not(CLK27), CLK26-1 ) mod Tsco = Dsco Las ranuras esclavo-a-maestro deben seguir directamente las ranuras maestro-a-esclavo reservadas. Y una vez inicializado, el valor de reloj, CLK(k+1), para la siguiente ranura se consigue añadiendo Tsco a la anterior: CLK(k+1) = CLK(k) + Tsco Por otro lado, los enlaces ACL pueden soportar servicios síncronos y asíncronos y se usa retransmisión de paquetes para asegurar la integridad de los datos. Un esclavo sólo puede devolver un paquete ACL si y sólo si ha sido direccionado en la anterior ranura de tiempo. Si en la cabecera del paquete no decodifica su dirección, no se le permite transmitir, salvo que no se haya enviado a ningún esclavo en concreto y sea interpretado como un mensaje de broadcast que todos los esclavos deben responder. Paquetes Bluetooth Los datos en una piconet son transportados en paquetes que tienen la estructura general que se muestra en la figura 6. Cada paquete consta de tres campos ( el código de acceso o access code, la cabecera o header y la "carga útil" o payload ) pudiendo consistir el paquete únicamente del access code, del access code y header, o de los tres campos. El access code y el header tienen un tamaño fijo de 72 bits y 54 bits respectivamente, mientras que el payload puede ir desde cero hasta 2745 bits.

Figura 6. Paquetes en Bluetooth Veamos uno por uno los campos que componen los paquetes Bluetooth: Access Code: Es usado para sincronización, compensación del offset e identificación. Todos los paquetes enviados en la misma piconet están precedidos por el mismo access code. Es usado también en los procedimientos de paging e inquiry, y donde se utiliza como señalización y no hay cabecera ni payload. Hay tres diferentes códigos de acceso definidos que se usan en diferentes modos: Channel Access Code (CAC) : Identifica una piconet y es incluido en todos los paquetes intercambiados en el canal de la piconet. Device Access Code (DAC) : Usado para procedimientos de señalización especiales (por ejemplo, paging, respuesta al paging...). Inquiry Access Code (IAC) : Hay dos variaciones. El general (GIAC) es común a todos los dispositivos y puede ser usado para descubrir las unidades Bluetooth cercanas. El IAC dedicado (DIAC) es común a las unidades de un grupo que comparten unas características. El CAC está compuesto de un preámbulo (preamble), una palabra de sincronización (sync word) y una cola final (trailer), como se muestra en la figura X. Figura 7. Estructura del Access Code Los diferentes tipos de access code usan diferentes LAPs (Lower Access Parts) para construir la palabra de sincronización. En la tabla 3 se muestra un resumen de los diferentes códigos de acceso:

Tipo de código LAP Longitud del código CAC Master 72 DAC Paged Unit 68/72 GIAC Reserved 68/72 DIAC Dedicated 68/72 Tabla 3. Resumen de los tipos de códigos de acceso Packet Header: Contiene información de control de enlace y consta de 6 campos, como se muestra en la figura 8. Figura 8. Formato de la cabecera AM_ADDR (Active Member Address) : Representa una dirección temporal de 3 bits usada para distinguir entre los miembros activos de una piconet. Aquellos esclavos que se desconectan o están en modo parked renuncian a su AM_ADDR y reciben una nueva al volver a conectarse. La dirección con todo ceros está reservada para paquetes de broadcast de un maestro a los esclavos. Una excepción es el paquete FHS que puede usar la dirección con todo ceros y no ser un mensaje de broadcast. TYPE: Pueden ser distinguidos seis diferentes tipos de paquetes. Los 4 bits del campo TYPE especifican cuál es usado y su interpretación depende del tipo de enlace físico asociado. Así, primero debe determinarse si el paquete se está enviando por un enlace SCO o ACL o luego el tipo de paquete SCO o ACL. El campo TYPE también revela el número de ranuras que el paquete ocupará. FLOW : Este bit se usa para el control del flujo sobre enlaces ACL. Cuando el buffer de recepción del enlace ACL está lleno, se devuelve un indicador de STOP (FLOW = 0) para cortar la transmisión de datos temporalmente. Esto afecta únicamente a los enlaces ACL, ya que aquellos que tienen información de control (paquetes ID, POLL y NULL, que veremos a continuación) o paquetes SCO pueden aún ser recibidos. Cuando el buffer de recepción se vacía, se devuelve una indicación de GO (FLOW =1). ARQN: Este bit de reconocimiento se usa para informar de una transferencia correcta de datos con CRC, y puede ser un reconocimiento positivo ACK o negativo NAK. Si no se devuelve nada, se asume implícitamente un NAK. SEQN: Proporciona un esquema de numeración secuencial para ordenar el flujo de datos. Para cada nuevo paquete transmitido que contiene datos con CRC, el bit SEQN se invierte. Esto es necesario para descartar retransmisiones en el destino, comparando el SEQN de paquetes consecutivos. Para paquetes de broadcast, se usa un método de numeración modificado. HEC : Cada cabecera tiene un HEC para comprobar su integridad, descartando completamente los paquetes en los que no coincide. Consiste en una palabra de 8 bits generada por el polinomio representado en octal como 647. Para la inicialización en paquetes FHS en estado "master page response", se usa la parte superior del esclavo

(UAP), mientras que para aquellos en estado "inquiry response" se usa una inicialización por defecto. En el resto de casos, se usa la UAP del dispositivo maestro. Una vez inicializado, se calcula el HEC de los 10 bits de cabecera. Formato del Payload: Dos campos se distinguen en el payload, el campo síncrono de voz y el campo asíncrono de datos. El primero tiene una longitud fija, siendo para los paquetes HV de 240 bits y para los DV de 80 bits. En el caso del campo de datos se pueden encontrar tres segmentos: Payload header, de uno o dos bytes. Payload body, que incluye información del host y determina la productividad efectiva. CRC : Son 16 bits generados por el CRC-CCITT con el polinomio 210041, y se genera de forma similar al HEC. Los diferentes tipos de paquetes hacen referencia a los enlaces físicos usados, los SCO o ACL. Cuatro tipos de paquetes serán comunes a los dos enlaces habiendo hasta doce definidos para cada tipo de enlace. Los tipos de paquetes se han clasificado en cuatro segmentos. El primero está reservado a los cuatro tipos comunes a los dos enlaces. El segundo a paquetes de una sola ranura de tiempo. El tercero a los que ocupan 3 ranuras y el cuarto a los que ocupan 5. Un resumen de los tipos de paquetes se muestra en la Tabla 4. Segmento Campo TYPE Número de slots Enlace SCO Enlace ACL 1

0000 1 NULL NULL 0001 1 POLL POLL 0010 1 FHS FHS 0011 1 DM1 DM1

2

0100 1 No def. DH1 0101 1 HV1 No def. 0110 1 HV2 No def. 0111 1 HV3 No def. 1000 1 DV No def. 1001 1 No def. AUX1

3

1010 3 No def. DM3 1011 3 No def. DH3 1100 3 No def. No def. 1101 3 No def. No def.

4

1110 5 No def. DM5 1111 5 No def. DH5

Tabla 4. Paquetes definidos para enlaces SCO y ACL Además de los cuatro paquetes comunes mostrados en la tabla 4, hay otro no listado, el paquete ID. Resumamos las características de cada uno de estos paquetes: ID packet (Identity packet): Consiste en un DAC o un IAC de 68 bits de longitud. Es un tipo de paquete muy robusto y es usado para la búsqueda de dispositivos Bluetooth (inquiry, paging...)

NULL packet: Tiene una longitud de 126 bits y no tiene payload. Se usa para devolver información de enlace con respecto al éxito de una transmisión previa (ARQN), o del estado del buffer de recepción (FLOW). Como ya se comentó, no necesita reconocimiento. POLL packet: Es muy similar al anterior , pero necesita confirmación. Puede ser usado para realizar un sondeo entre los esclavos, que han de responder aunque no tengan información que transmitir. FHS packet: Es un paquete de control especial que revela, entre otras cosas la dirección del dispositivo Bluetooth y el reloj del emisor. El payload tiene 144 bits de información con un código CRC de 16 bits. La figura 9 ilustra el formato y contenidos del payload de un paquete FHS. Figura 9. Formato del payload FHS El payload consta de once campos descritos a continuación en la tabla 5. Los paquetes FHS se usan en la respuesta a un page o en el cambio maestro-esclavo, donde se retransmite hasta obtener reconocimiento o exceder el timeout. También se usa en la respuesta a una inquiry, donde no se espera reconocimiento. DM1 packet : Soporta mensajes de control en cualquier tipo de enlace, aunque también puede transportas datos. Desde que el paquete DM1 se reconoce en un enlace SCO, se interrumpe la información síncrona para enviar información de control. Campo Descripción Parity bits

Los 34 bits de paridad forman la primera parte de la palabra desincronización (sync word) del access code de la unidad que envíael paquete FHS

LAP

Los 24 bits de este campo contienen la parte baja de la unidad que envía el paquete FHS

Undefined

Estos 2 bits están reservados para usos futuros y deben ser cero

SR

Estos dos bits indican la repetición de búsqueda y marca el intervaloentre dos búsquedas consecutivas.

SP

Los 2 bits de este campo indican el periodo en que el modo de page scan obligatorio se aplica después de la transmisión de unarespuesta de inquiry

UAP Los 8 bits contienen la parte superior de la dirección del emisor. NAP

Son los 16 bits de la parte no significativa de la unidad que envía el paquete FHS

Class of device

Este campo de 24 bits contiene la clase de dispositivo de la unidadque manda el paquete FHS y cuyos números están definidos en laespecificación.

AM_ADDR

Estos 3 bits se usan si el paquete FHS es de configuración o de cambio de rol maestro-esclavo, y contiene la dirección que el destinatario debe usar. Un esclavo contestando a un maestro o unapetición de inquiry debe tener este campo todo a cero, pero no debe interpretarse como de broadcast.

CLK27-2

Los 26 bits contienen el valor del sistema de reloj nativo de launidad que envía el paquete, con una resolución de 1.25 ms (eltiempo de dos ranuras de tiempo). Para cada transmisión seactualiza este campo para reflejar el valor real del reloj.

Page scan mode

Estos 3 bits indican que el modo de escaneo se usa por defecto porel emisor del paquete FHS.

Tabla 5. Descripción de los campos del payload del paquete FHS Veamos ahora las características de los paquetes que no son comunes a los dos tipos de enlaces. Estas se recogen en las tablas 6 y 7.

Tipo de paquete ACL

Payload Header (Bytes)

User Payload (Bytes)

FEC CRC Transmisión simétrica (max Kbps)

Transmisión asimétrica (max Kbps)Up Down

DM1

1

0-17

2/3

Si

108.8

108.8

108.8

DH1

1

0-27

0

Si

172.8

172.8

172.8

DM3

2

0-120

2/3

Si

258.1

387.2

54.4

DH3

2

0-180

0

Si

390.4

585.6

86.4

DM5

2

0-224

2/3

Si

286.7

477.8

36.4

DH5

2

0-338

0

Si

433.9

723.2

57.6

Tabla 6. Tipos de paquetes ACL

Tipo de paquete SCO

Payload Header(Bytes)

User Payload (Bytes)

FEC CRC Transmisión simétrica (Kbps)

HV1 Na 10 1/3 No 64.0 HV2 Na 20 2/3 No 64.0 HV3 Na 30 no No 64.0 DV Na 10+(0-9)D 2/3D si D 64.0 + 57.6 D Tabla 7. Tipos de paquetes SCO

Comentar para acabar la explicación de esta capa las tres clases de corrección de errores definidos en Bluetooth: FEC de ratio 1/3: Simple esquema que usa triple repetición de los bits, como se ilustra en la figura 10 Figura 10. Código FEC: 1/3 FEC de ratio 2/3: Es un (15,10) código de Hamming acortado, donde el polinomio generador es g(D) = (D+1)(D4+D+1). En la figura 11 se muestra la generación del código de forma abreviada. Figura 11. Código FEC: 2/3 Esquema ARQN: Sólo funciona en el payload del paquete y el header. Llos payload de voz no están protegidos con el esquema ARQN. En la figura 12 se presenta el funcionamiento del esquema ARQN.

Figura 12. Esquema ARQN

Link Manager Protocol (LMP) Los mensajes de esta capa se usan para la configuración del enlace y para su seguridad y control, y se distinguen por el campo L_CH de la cabecera del payload. Los mensajes son filtrados e interpretados en el receptor y no son transmitidos a niveles superiores. Además, tienen una prioridad mayor que los que transportan datos de usuario, con lo que el tráfico L2CAP no debe retrasar su transmisión. Figura 13. LMP en la pila Bluetooth LC solo garantiza que tratará de comunicarse con cada esclavo cada periodo de ranuras Tpoll, pero no garantiza el tiempo requerido para la entrega de un mensaje ni el retraso entre la entrega del mensaje y la recepción de su reconocimiento (ACK), con lo que hay que ser consciente de las limitaciones para sincronizar el cambio de estado entre maestro y esclavo. El criterio que se sigue para poder rehusar una dirección AM_ADDR después de la desconexión de un esclavo se basa en la recepción del reconocimiento de la capa baseband. La sincronización del cambio maestro-esclavo o el comienzo del estado hold utiliza el reloj del maestro que la capa LM lee de la LC. Procedimientos LMP Las PDUs LM son enviadas siempre como paquetes de una sola ranura sobre enlaces ACL (en paquetes DM1) o SCO (en paquetes DV). La cabecera del payload es de un byte, donde los dos bits menos significativos determinan el canal lógico. El bit FLOW es siempre 1 y tiene además un campo llamado OpCode (que identifica de forma única diferentes tipos de PDUs) y un identificador de transacción. Este Id es 0 cuando son enviadas por el maestro y 1 si son enviadas por el esclavo. El proceso general de los procedimientos LMP se describe como una secuencia de envíos y recepciones de PDUs de distinta naturaleza. Figura 14. Esquema general de un procedimiento LMP

Hay definidas dos PDUs de respuesta a otras PDUs en varios procedimientos LMP: LMP_accepted y LMP_not_accepted. El primero se usa para indicar en la inicialización que el comando LM se ha aceptado mientras el segundo indica que no se ha aceptado y además indica cual es la razón. Los procedimientos más importantes que desarrolla LMP son: Autenticación: El procedimiento de autenticación se basa en el intercambio de un número aleatorio. El equipo que verifica envía al que lo solicita una PDU usada para autenticación (LMP_au_rand) que contiene un número aleatorio. Al recibirla, el equipo que la solicitó calcula la respuesta, que es una función de ese número, de su BD_ADDR y de una clave secreta. La respuesta, que es una PDU del tipo LMP_res, se devuelve al otro equipo (que puede ser tanto un maestro como un esclavo), que verifica si la respuesta es correcta o no. Si es correcta, los dos dispositivos ya comparten una clave secreta. Encriptación: Puede ser usada sólo si se ha realizado al menos una autenticación anteriormente, y se deben llevar a cabo los siguientes pasos para llevarla a cabo: Primero de todo maestro y esclavo deben estar de acuerdo en si usar encriptación o no y en si debe aplicarse sólo a paquetes transmitidos punto-a-punto o también a los de broadcast. Para ello, se detiene las transmisiones L2CAP y se envía la PDU LMP_encryption_mode_req. Si se llega a un acuerdo sobre su uso, el otro dispositivo detiene la transmisión L2CAP y responde con LMP_accepted. A partir de aquí, el maestro continúa dando información más detallada de la encriptación. El siguiente paso es determinar el tamaño de la clave de encriptación. El maestro envía el mensaje LMP_encryption_key_size incluyendo el tamaño sugerido Lsug,m que es inicialmente igual a L max,m Si L min,s ≤ L sug, m y el esclavo soporta L sug, m , responde con un LMP_accepted y se usará como tamaño de clave. Si no se cumple alguna de las dos condiciones, el esclavo devuelve un LMP_encryption_key_size incluyendo una clave sugerida por él, L sug, s , siendo ahora el maestro el que realiza el proceso para ver si la acepta. Esto se realiza hasta llegar a un acuerdo o hasta que se descubra que no es posible llegar a tal acuerdo. (Ver figuras 15 y 16) Figura 15. Negociación del tamaño de la clave con éxito Figura 16. Negociación del tamaño de la clave sin éxito

Finalmente, la encriptación ya puede empezar. Esto se realiza en tres pasos: El maestro se configura para no transmitir paquetes encriptados, pero sí para recibirlos. El esclavo se configura tanto para recibir como para transmitir paquetes encriptados. Finalmente, se configura el maestro también para transmitir paquetes encriptados. Detener la encriptación también es posible con los mensajes LMP_encryption_mode_req con el modo de encriptación 0. Si es aceptado por el otro extremo, recibirá LMP_accepted y sino LMP_not_accepted. Pairing (Emparejamiento): Puede llevarse a cabo antes de la autenticación y encriptación si los dos dispositivos no tienen una clave de enlace común. Ésta se calcula en base a un PIN, un número aleatorio y una BD_ADDR. Se comienza con el envío de LMP_in_rand que tiene el número aleatorio usado para calcular la clave. Cambio de rol Maestro-Esclavo: Aunque es el dispositivo que hace el paging el que se convierte en maestro de la piconet, a veces es necesario un cambio de rol. El proceso puede ser iniciado por el esclavo o por el maestro: Si el proceso lo empieza el esclavo, detiene la transmisión L2CAP y envía un LMP_slot_offset seguido de un LMP_switch_req. Si el maestro acepta, detiene su transmisión de la capa L2CAP y responde con un LMP_accepted. En caso contrario, el mensaje de respuesta es LMP_not_accepted, y en ambos casos se retoma la transmisión L2CAP con el nuevo rol de cada uno (si se llegó al acuerdo) o con el antiguo (si no se llegó a un acuerdo). Si es el maestro quien inicia el procedimiento, el proceso es similar. Finaliza las transmisiones de la L2CAP, envía LMP_switch_req y el esclavo devuelve LMP_slot_offset y LMP_accepted (si se ha aceptado) o solo LMP_not_accepted ( si no se aceptó el cambio de rol). Finalmente, se retoman las transmisiones L2CAP. Hold Mode: Un enlace ACL entre dos dispositivos puede ser aparcado en modo hold durante un periodo de tiempo determinado en el que no habrá transmisión de paquetes ACL por parte del maestro. Normalmente se usa este modo cuando no hay necesidad de enviar datos durante un periodo relativamente largo, con lo que el transceptor puede ser desconectado ahorrando energía. Pero el modo hold también se puede usar si un dispositivo quiere descubrir o ser descubierto por otros, o quiere conectar otras piconets. Para este procedimiento, la LMP ofrece los mensajes LMP_hold y LMP_hold_req que contienen ambos como parámetros el instante en que quiere hacerse efectivo el modo hold. Tanto maestro como esclavo pueden forzar el modo hold, o incluso ambos. Sniff Mode: Para entrar en modo sniff, debe negociarse en los dos extremos el intervalo y offset (Tsniff y Dsniff), de modo que el offset determina la primera ranura de sniff, y a partir de ahí se sigue periódicamente a intervalos Tsniff. Cuando un enlace entra en este modo, el maestro puede empezar una transmisión sólo en una ranura de sniff, y se controla la escucha del esclavo con dos parámetros: sniff attempt (cuantas ranuras debe escuchar el esclavo) y sniff timeout (cuantas ranuras adicionales debe escuchar si continua recibiendo sólo paquetes con su propia dirección AM).

Park Mode: Si un esclavo no necesita participar en un canal, pero debe permanecer sincronizado, puede entrar en modo park. En este modo el dispositivo pierde su AM_ADDR pero todavía permanece sincronizado en el canal. Todas las PDUs enviadas por el maestro para dejar esclavos en modo parked son broadcast. Estas PDUs (LMP_set_broadcast_scan_window, LMP_modify_beacon, LMP_unpark_BD_addr_req y LMP_unpark_PM_addr_req) son las únicas PDUs que pueden ser mandadas a un esclavo en modo park y las únicas PDUs que pueden ser broadcast. Por esto, se trata de hacer los paquetes tan pequeños como sea posible, haciendo que el paquete no tenga siempre los parámetros alineados por byte o haciendo la longitud de la PDU variable. El maestro puede forzar a un esclavo al modo park y también ambos pueden preguntar al otro extremo si es conveniente que el esclavo entre en este modo, pero sólo el maestro puede devolverlos a la actividad. Calidad de Servicio (QoS): La capa LM proporciona comandos para garantizar calidad de servicio. En concreto, LMP_quality_of_service y LMP_quality_of_service_req, siendo posible que los dos dispositivos pidan QoS o que sea el maestro el que notifique al esclavo la necesidad de garantizar QoS, no siendo posible entonces que el esclavo acepte la petición. Enlace SCO: Cuando una conexión se establece entre dos dispositivos Bluetooth se trata de un enlace ACL. Es entonces cuando uno o más enlaces SCO se pueden crear. Los enlaces SCO reservan ranuras separadas por Tsco y que comienzan por Dsco. Tanto maestro como esclavo puede iniciar un enlace SCO (con la PDU LMP_SCO_link_request, siendo necesaria una retransmisión de la misma en el caso en que es el esclavo el que pide y el maestro el que acepta), así como cambiar los parámetros del enlace (LMP_SCO_link_request con el manejador del enlace que se quiere modificar), o deshacer el enlace (LMP_remove_SCO_link_req) Otros procedimientos como: Control de energía: Un dispositivo Bluetooth puede incrementar o decrementar la energía de salida del otro dispositivo. Detach: Se envía con un LMP en que se explica el motivo por el que la conexión va a ser cerrada. Control de paquetes multi-ranura: Un dispositivo permite al otro usar un número máximo de ranuras . Esquema de paging: además del esquema principal de paging, Bluetooth define otros opcionales. Supervisión del enlace: Se realiza una supervisión del enlace cada cierto tiempo. Este timeout puede ser modificado con mensajes LMP. Hay otros procedimientos definidos, que pueden ser consultados en la especificación Bluetooth.

2.6. Logical Link Control and Adaptation Protocol Specification (L2CAP) 2.6.1. Descripción general Este protocolo se sitúa en la capa de enlace, sobre el protocolo baseband, y hace de interface de otros protocolos de comunicación como el Service Discovery Protocol (SDP), RFCOMM, y Telephoy Control(TCS) Está definido únicamente para los enlaces ACL, excepto para los paquetes de tipo AUX1, que al no disponer de CRC no garantiza la protección de la información.

Figura 17. L2CAP entre las capas Bluetooth La L2CAP soporta multiplexación de protocolos de más alto nivel, segmentación y reensamblado de paquetes, gestión de grupos y transmisión de información garantizando calidad de servicio (QoS). Multiplexación de protocolos: L2CAP debe ser capaz de distinguir entre protocolos superiores, ya que la capa baseband no dispone de ningún campo que identifique estas capas. Segmentación y reensamblado (SAR): Comparado con otros medios físicos, los paquetes de datos definidos por la capa Baseband están limitados en tamaño, con lo que se limita el uso eficiente del ancho de banda para protocolos superiores diseñados para usar paquetes mayores. Grandes paquetes L2CAP deben segmentarse en múltiples paquetes Baseband pequeños antes de ser transmitidos por el aire. De forma parecida, muchos paquetes Baseband recibidos deben reensamblarse en un paquete L2CAP grande. Así, la funcionalidad SAR es imprescindible. Quality of Service: El proceso de conexión L2CAP permite el intercambio de información garantizando la calidad de servicio (QoS) requerida por las unidades Bluetooth. Gestión de grupos: Muchos protocolos incluyen el concepto de grupo de direcciones, como en la capa baseband el concepto de piconet (grupo de dispositivos síncronos usando el mismo reloj). La L2CAP introduce el concepto abstracto de grupo, con lo que protocolos superiores no necesitan acudir a niveles inferiores para la gestión eficiente de sus grupos.

La L2CAP está creada sobre el concepto de "canal" donde cada extremo del mismo es un identificador del canal (channel identifiers o CIDs). En la tabla 8 pueden verse las definiciones de CIDs CID Descripción 0x0000 Identificador nulo

0x0001

Canal de señalización

0x0002

Canal de recepción de la conexión

0x0003-0x003F

Reservado

0x0040-0xFFFF Asignado dinámicamente

Tabla 8. Definiciones de CIDs Comentar que las capas situadas sobre la L2CAP, pueden ser identificadas por un valor PSM (Protocol Service Multiplexor). Así, cada capa sobre L2CAP tiene su propio PSM, como se muestra en la tabla 9. Capa sobre L2CAP PSM SDP 0x0001 RFCOMM 0x0003 TCS-BIN 0x0005 TCS-BIN_CORDLESS 0x0007 Tabla 9. Valores PSM definidos Otra característica interesante que ofrece la L2CAP es la calidad de servicio (QoS), que en los paquetes de la L2CAP de configuración tiene el tipo 0x03. 2.6.2. Estados, eventos y acciones La implementación de la L2CAP puede verse como una máquina de estados en la que se produce la comunicación de dos dispositivos a través de una secuencia de mensajes generados por los eventos y acciones que ofrece esta capa. En la figura 18 se muestra un ejemplo en que el emisor crea el primer canal L2CAP entre dos dispositivos. Ambos extremos comienzan en el estado CLOSED, y después de recibir la petición de la capa superior, el dispositivo pide a la capa inferior establecer un enlace físico. Si este no existe, se usan comandos LMP para crearlo, y una vez establecido el enlace físico, las señales L2CAP pueden ser enviadas sobre él.

Figura 18. Ejemplo de la máquina de estados L2CAP 2.6.3. Primitivas L2CAP Veamos ahora algunos de los servicios ofrecidos por la L2CAP en cuanto a primitivas y parámetros: CONNECT: Esta primitiva inicia el envío de un mensaje L2CAP_ConnectReq recibiendo como parámetros de entrada la dirección BD_ADDR del dispositivo remoto y el protocolo al que va destinado (PSM), con el fin de crear un canal que represente una conexión lógica a esa dirección física. Si se tiene éxito, se devuelve el identificador de canal (CID) asignado y en caso contrario un 0. CONNECT RESPONSE: Esta primitiva representa al mensaje L2CAP_ConnectRsp y proporciona una respuesta a un evento de petición de conexión. Los principales parámetros de entrada son los 48 bits de la BD_ADDR del dispositivo remoto, el CID local y el código de respuesta (conexión exitosa, rehusada, pendiente...) , siendo el parámetro de salida el resultado del envío. CONFIGURE: Inicia el envío de un mensaje L2CAP_ConfigReq con el que se pretende configurar (o reconfigurar) los parámetros de un canal. Se reciben datos como

el CID local, la nueva MTU, timeouts, ... y se recibe el resultado de la configuración junto con la MTU aceptada y otros parámetros. CONFIGURE RESPONSE: Implementa la respuesta a un evento de petición de configuración, enviando el CID local y parámetros como la MTU de transmisión. DISNECT: El mensaje L2CAP_DisconnectReqCCONNECT: El mensaje L2CAP_DisconnectReq recibe el CID que representa el canal local y una vez desconectado, ningún proceso será capaz de leer o escribir en el CID, aunque las escrituras en proceso, evidentemente, deben continuar hasta ser procesadas. WRITE: El uso de esta primitiva crea una petición de transferencia de datos a través del canal (mensaje L2CAP_DataWriteReq). La transmisión de una cantidad de datos mayor que el OutMTU configurado no da error, si bien sólo los primeros OutMTU bytes son transmitidos. READ: Solicita la recepción de los datos disponibles en un enlace (mensaje L2CAP_DataRead). Si no hay suficiente información disponible, se espera que lleguen más datos o que el enlace termine, y si hay demasiada, sólo una parte será leída, descartando el resto. PING: El servicio L2CAP_Ping pide realizar un echo, con la BD_ADDR del dispositivo sobre el que se quiere realizar. Otros enfocados a conexiones con múltiples dispositivos, como GROUP CREATE (crear una conexión múltiple), GROUP CLOSE (clausura de un grupo), GROUP ADD MEMBER (añadir un miembro al grupo), GROUP REMOVE MEMBER (eliminar un miembro del grupo) o GET GROUP MEMBERSHIP (informe de los miembros de un grupo).

2.7. Service Discovery Protocol (SDP) 2.7.1. Descripción general El protocolo SDP proporciona medios a las aplicaciones tanto para descubrir qué servicios están disponibles en un servidor Bluetooth como para determinar las características de estos servicios . Las características de un servicio se representan en forma de atributos, donde se incluye el tipo de servicio ofrecido y el mecanismo necesario para utilizarlo. En la figura 19 se muestra una configuración simplificada de la interacción cliente-servidor que se lleva a cabo, en la que se usa un modelo de preguntas y respuestas con PDUs. Figura 19. SDP: Interacción Cliente-Servidor. Así, el servidor mantiene una lista de registros de servicios que describen las características de los servicios asociados a él, conteniendo cada registro información de un solo servicio. Y si el cliente, o una aplicación asociada con el cliente, decide usar uno de ellos , debe descubrirlos a través de los mecanismos que la capa SDP proporciona, y crear una conexión distinta con el servidor para poder utilizar el servicio solicitado. El conjunto de servidores SDP disponibles para un cliente SDP puede cambiar de forma dinámica según la proximidad entre ellos, y cuando un servidor pasa a estar disponible, todo cliente potencial debe ser notificado por un medio distinto al SDP, que puede entonces usarse para preguntar al servidor sobre sus servicios. De forma similar, cuando un servidor se aleja o está indisponible por cualquier razón, no hay ninguna notificación vía SDP para el cliente. Sin embargo, el cliente puede usar el SDP para buscar servidores o poder deducir que un servidor no está disponible si no hay respuesta durante un largo periodo de tiempo. Un servicio puede ser implementado por hardware, software, o en combinación de ambas, y toda su información se almacena en un registro identificado por un manejador de 32 bit. Y sólo uno de estos manejadores, el 0x00000000 mantiene el mismo significado en todos los servidores SDP. Este manejador se refiere al mismo servidor SDP, y contiene sus atributos y los protocolos que soporta. Así, estos registros son los que contienen los atributos que definen una característica del servicio, que a su vez, están compuestos por: El identificador de atributo, que es un entero de 16 bits usado para distinguir cada atributo de otros en el mismo registro y para identificar la semántica del valor del atributo asociado.

El valor del atributo, que es un campo de tamaño variable cuyo significado viene determinado por el identificador asociado y por el manejador del registro en el que se encuentra el atributo. 2.7.2. Búsqueda de servicios Una vez el cliente dispone del manejador de un registro de atributos, puede acceder fácilmente a las características del servicio, pero... ¿cómo un cliente obtiene este manejador? La posibilidad de búsqueda de registros de servicios se refiere únicamente a la búsqueda de los atributos cuyos valores son UUIDs (Universally Unique Identifiers). Y una lista de UUIDs usadas para situar aquellos registros que pueden emparejarse (si uno contiene una parte de otro) es lo que se conoce como una patrón de búsqueda de servicios. Aunque normalmente un cliente busca servicios que cumplan unas características (representadas por UUIDs), hay veces en que es deseable descubrir los tipos de servicios sin ningún tipo de información previa. Para esta búsqueda se comparte un atributo llamado BrowseGroupList, cuyo valor es una lista de UUIDs. Cuando un cliente quiere buscar servicios sin información previa, crea un patrón de búsqueda de servicios que representa el grupo de búsqueda raíz y todos los servicios que pueden ser vistos en el nivel superior se hacen miembros del grupo raíz poniendo en BrowseGroupList el valor del UUID del grupo raiz. Así se van organizando de forma jerárquica los servicios ofrecidos por el servidor SDP. En la tabla 10 de la siguiente hoja se muestran ejemplos de atributos de servicios ofrecidos por SDP. Atributo Descripción ServiceRecordHandle Es un número de 32 bits que identifica cada registro

en un servidor SDP ServiceClassIDList Identifica el tipo de servicio representado por el

registro ServiceRecordState Entero que facilita el uso de referencias rápidas a los

atributos ServiceID Es un UUID que Identifica unívocamente una

instancia específica de un servicio ProtocolDescriptorList Especifica la pila de protocolos que debe usarse para

utilizar un servicio BrowseGroupList Secuencia de elementos donde cada uno representa

el UUID del grupo de búsqueda al que pertenece elservicio.

LanguajeBaseAttributeIDList Para permitir la lectura de los atributos en múltiples idiomas.

ServiceInfoTimeToLive Número de segundos en que la información delregistro es válida.

BluetoothProfileDescriptorList Secuencia de elementos en que cada uno es undescriptor de un perfil que el servicio acepta.

DocumentationURL URL que apunta a la documentación del servicio. ClientExecutableURL URL que apunta a la aplicación que puede ser usada

para utilizar el servicio

ServiceAvailability Indica la posibilidad de aceptar a clientes. ProviderName El nombre de la organización o persona que

proporciona el servicio IconURL Especifica una URL que apunta a un icono usado

para representar el servicio ServiceName Texto que contiene el nombre del servicio ServiceDescription Texto que describe el servicio Tabla 10. SDP: Ejemplos de atributos

2.8. Host Contoller Interface (HCI) 2.8.1. Descripción general Se describe a este nivel el modo de controlar por completo el dispositivo Bluetooth desde el ordenador, proporcionando el protocolo HCI comandos de interface para el control de enlaces, para el acceso al estado del hardware y para el control de la capa baseband, Se proporcionan los mecanismos para hacer posible el envío de comandos HCI, datos ACL, datos SCO y también para la recepción de eventos HCI y de datos ACL o SCO. Los paquetes para comandos HCI tienen la estructura mostrada en la figura 20 , utilizan el prefijo 0x01 y el significado de cada campo es el siguiente: OpCode: 2bytes para identificar los distintos tipos de comandos. Se divide en el OGF (OpCode Group Field) que ocupa los 6 bits de mayor peso y el OCF(OpCode Command Field) que ocupa los 10 bits de menor peso. Parameter_Total_Lenght: Longitud en bytes de todos los parámetros del paquete. Parameters 0-N: Los parámetros del comando que viene determinado por el OpCode. Cada comando tiene un número distinto de parámetros asociados a él, así como un tamaño distinto de estos.

Figura 20. HCI: Paquete de comandos HCI Los paquetes de eventos HCI tienen la estructura mostrada en la figura 21, y el ordenador debe ser capaz de aceptar paquetes de eventos HCI con más de 255 bytes de datos (sin contar la cabecera). Utilizan el prefijo 0x04 y el significado de cada campo es: Event_Code: Cada evento tiene asignado un byte que identifica los distintos tipos de eventos. Parameter_Total_Lenght: Longitud en bytes de todos los parámetros del paquete.

Event_Parameters: Los parámetros del evento que viene determinado por el Event_Code. Cada comando tiene un número distinto de parámetros asociados a él, así como un tamaño distinto de estos. Figura 21. HCI: Paquete de eventos Por último, los paquetes de datos usados para el intercambio de información se componen de los campos mostrados en la figura 22 para los paquetes ACL (utilizan el prefijo 0x02) y de los mostrados en la figura 23 para los SCO (utilizan el prefijo 0x03). Su significado es el siguiente: Connection_Handle: Manejador de la conexión usada para la transmisión de datos ACL o SCO, según el caso. Data_Total_Lenght: tamaño en bytes de los datos. Y además, para los paquetes ACL: Packet_Boundary_Flag: Indica si es el primer paquete de un mensaje de protocolo superior (valor del campo "10") o si es una continuación de otro (valor del campo "01"). Los valores "00" y "11" están reservados para usos futuros. Broadcast_Flag: Para paquetes desde el ordenador al HC, indica si es una transmisión punto-a-punto (valor del campo "00"), si se trata de una difusión a los esclavos activos (valor del campo "01") o si se realiza la difusión a esclavos activos o en modo park (valor del campo "10"). El valor "11" se reserva para usos futuros. Y para los paquetes que van desde el HC al ordenador, el "00" indica punto-a-punto, el "01" indica la recepción de un paquete por un esclavo activo, mientras que el "10" indica la recepción en modo park. El valor "11" se reserva para usos futuros. Y los característicos de los paquetes SCO: Reserved: 4 bits reservados para usos futuros. Figura 22. HCI: Paquete de datos ACL

Figura 23. HCI: Paquete de datos SCO 2.8.2. Comandos HCI Veamos en primer lugar los comandos que permiten controlar conexiones a otros dispositivos Bluetooth. Para estos paquetes, el OGF definido es el 0x01. HCI_Inquiry: Provoca que un dispositivo Bluetooth entre en el Inquiry Mode , que permite descubrir a otros equipos cercanos. Los parámetros que recibe son el LAP usado para derivar el código de acceso, la duración de la búsqueda y el número de respuestas que pueden recibirse. Cuando finaliza la inquiry, se envía un evento Inquiry_Complete que contiene la información de los dispositivos que han contestado. HCI_Inquiry_Cancel: Provoca la finalización del inquiry actual, siendo necesario para usarlo que se haya usado antes un HCI_inquiry y que no haya ocurrido un evento de Inquiry_Complete (no haya pasado el tiempo especificado en la inquiry). HCI_Periodic_Inquiry_Mode: Se usa para configurar el dispositivo Bluetooth de forma que lleve a cabo una inquiry automática en un periodo de tiempo determinado. Se especifica también el tiempo y el número de respuestas de la inquiry. HCI_Exit_Periodic_Inquiry_Mode: Usado para finalizar la realización periódica de inquiries tras ejecutar el comando Periodic_Inquiry_Mode. HCI_Create_Connection: Crea una conexión ACL con el dispositivo cuya BD_ADDR se especifica en los parámetros de entrada. HCI_Disconnect: Usada para finalizar una conexión existente. HCI_Add_SCO_Connection: Crea una conexión SCO usando la conexión ACL especificada por su manejador. HCI_Accept_Connection_Request: Usada para aceptar una petición de conexión. HCI_Reject_Connection_Request: Usada para rechazar una petición de conexión.

HCI_Link_Key_Request_Reply: Permite contestar a un evento Link_Key_Request especificando la clave que será usada para la conexión con otro dispositivo. HCI_Link_Request_Negative_Reply: Permite contestar a un evento Link_Key_Request indicando que no dispone de una clave para la conexión. HCI_PIN_Code_Request_Reply: Permite contestar a un evento PIN_Code_Request y especifica el PIN usado para la conexión. HCI_PIN_Code_Reques_Negativet_Reply: Permite contestar a un evento PIN_Code_Request indicando que no dispone de PIN para ser usado en la conexión. HCI_Change_Connection_Packet_Type: Usado para cambiar el tipo de paquetes que pueden ser usados en una conexión establecida. HCI_Authentication_Requested: Usado para activar la autenticación entre dos dispositivos que están conectados. HCI_Set_Connection_Encryption: Permite habilitar o deshabilitar la encriptación a nivel de enlace. HCI_Change_Connection_Link_Key: Usado para forzar a dos dispositivos conectados a generar una nueva clave de conexión. HCI_Master_Link_Key: Fuerza a dos dispositivos conectados a usar la clave del maestro de la piconet. HCI_Remote_Name_Request: Permite obtener el nombre de otro dispositivo Bluetooth. HCI_Read_Remote_Supported_Features: Solicita una lista de características de un dispositivo remoto. HCI_Read_Remote_Version_information: Solicita información de la versión de un dispositivo remoto. HCI_Read_Clock_Offset: Lee el offset de reloj de un dispositivo remoto. Una vez visto como el protocolo HCI gestiona las conexiones, veamos los mecanismos que ofrece para el manejo de piconets y scatternets. Nos centraremos especialmente en cómo se consigue forzar un determinado modo.. Para estos paquetes, el OGF definido es el 0x02. HCI_Hold_Mode: Se usa para alterar el comportamiento de la capa LM, con el fin de forzar a una conexión ACL e entrar en modo hold. La conexión se trata de la especificada por el manejador que se pasa como parámetro de entrada del comando. Además, se define la cantidad de tiempo en que se trata de conseguir que el dispositivo entre en modo hold (parámetros Hold_Mode_Max_Interval). Así, se lleva a cabo una negociación entre las dos partes y si el comando tiene éxito, se devuelve como parámetro del evento Mode_Change el intervalo de hold. Este comando no puede usarse

en conexiones SCO ni si el manejador de conexión se usa para una operación de broadcast. HCI_Sniff_Mode: De la misma forma, se trata de forzar a una conexión ACL a entra en modo sniff. Además de parámetros similares a los del comando anterior (manejador de la conexión, cantidad de tiempo permitida para lograr el modo sniff,...) añade dos parámetros (sniff_Attempt y Sniff_Timeout) usados para conexiones en modo sniff. Tampoco es válido para conexiones SCO ni para conexiones usadas para broadcast. HCI_Park_Mode: Se usa para alterar el comportamiento de la capa LM, con el fin de forzar a la conexión ACL a entrar esta vez en modo park. Los parámetros son similares a los explicados anteriormente y como única diferencia se contempla la posibilidad de que el HCI genere automáticamente un unpark para la transmisión de datos o para supervisión. HCI_Exit_Sniff_Mode: Finaliza el modo sniff de una conexión. HCI_Exit_Park_Mode: Finaliza el modo park, devolviendo la conexión a modo activo. HCI_QoS_Setup: Permite especificar los parámetros de calidad de servicio de una conexión. HCI_Role_Discovery: Descubre el rol de un dispositivo específico en una determinada conexión. HCI_Switch_Role: Permite cambiar el rol actual que un dispositivo tiene en una conexión. HCI_Read_Link_Policy_Settings: Lee los parámetros,permitiendo especificar qué modos pueden usarse para una conexión. HCI_Write_Link_Policy_Settings: Escribe los parámetros,permitiendo igualmente especificar qué modos pueden usarse para una conexión. Y con el fin de acceder y controlar las capacidades del hardware, se proporcionan comandos para el control del HCI, siendo el OGF definido en este caso el 0x03. Veamos algunos ejemplos de comandos en este nivel: HCI_Set_Event_Mask: Controla los eventos generados por el HCI. HCI_Reset: Inicializa el HCI, LM y el módulo de radio. HCI_Set_Event_Filter: Especifica diferentes filtros de evento, pudiendo llamarse a este comando múltiples veces. HCI_Flush: Descarta todo los datos pendientes actualmente de transmisión. HCI_Read_PIN_Type: Descubre si se soporta variabilidad en el PIN o sólo PINs estáticos.

HCI_Write_PIN_Type: Especifica variabilidad o estaticidad en el PIN. HCI_Create_New_Unit_Key: Crea una nueva clave. HCI_Read_Stored_Link_Key: Proporciona la posibilidad de leer una o más claves de enlace almacenados en el HCI. HCI_Change_Local_Name: Permite modificar el nombre con el que se conoce al dispositivo Bluetooth. Write_Page_Timeout: Permite configurar el parámetro timeout al hacer un page, definiendo así el periodo de tiempo en que una petición de conexión esperará la respuesta de algún equipo remoto. Write_Inquiry_Scan_Activity: Evalúa el intervalo de inquiry, así como otros parámetros de configuración. Write_Authentication_Enable: Usado para requerir autenticación en cada conexión. Write_Envryption_Mode: Usado para requerir encriptación en cada conexión. Además, hay otras utilidades relacionadas con el control de la energía de transmisión, el tamaño de datos SCO o ACL, el número de retransmisiones en un broadcast, etc.