Bluetooth

UNIVERSIDAD CENTRAL DE VENEZUELAFacultad de Ciencias

Postgrado en Ciencias de la ComputaciónLecturas de Docencia

Redes de Área Local y Personal Inalámbricas:

Bluetooth

Profesora Agregado Maria Elena Villapol

Diciembre del 2006.

Redes Inalámbricas de Área Local y Personal: Bluetooth

1. Fundamentos de Bluetooth

Bluetooth es una tecnología de radio frecuencia (RF) que ofrece conectividad a corta distancia para equipos personales, portables, PDAs, entre otros. Inicialmente, fue pensado para reemplazar los cables que conectan diversos dispositivos. Se caracteriza por ser de bajo costo y “amigable”.

Bluetooth se enfoca en lo siguiente:

Reemplazo del cable: substitución de interfaces tradicionales, tales como RS-232 y conectores propietarios.

Punto de acceso de voz y data: proporciona una interfaz uniforme para acceder servicios de voz y datos. También se puede usar para proporcionar acceso a una WAN usando un gateway personal tal como un teléfono celular.

Redes ad hoc: proporciona comunicación sin infraestructura, que se puede usar para el soporte a grupos colaborativos (reuniones, conferencias).

El desarrollo de Bluetooth se inicia finales del invierno de 1998. Ercisson, IBM, Intel, Nokia y Toshiba formaron el Bluetooth Special Industry Group (SIG). Su intención era desarrollar una tecnología inalámbrica de corto alcance que debía funcionar en la banda de 2.4 GHZ (ISM).

El nombre de Bluetooth viene del Rey Danes Harald Blatand o Harold Bluetooth en inglés quien es conocido por haber unificado la gente de Scandinavia durante el siglo 10. Fue un nombre dado de forma temporal a ésta tecnología, aunque nunca se ha cambiado.

La especificación fue ofrecida sin royalty a quienes la adoptaran. En Mayo de 1998 había aproximadamente 70 adoptadores. Ahora hay más de 3000. En 1999 se libera la primera especificación (1.0A). Actualmente se encuentra la disponible la especificación de la versión 2.0.

En Diciembre de 1999, se habían incorporado al SIG 3Com, Lucent, Microsoft y Motorola. En Marzo de 1999 se creo el grupo IEEE 802.15 para desarrollar estándares para WPAN. La especificación de Bluetooth fue elegida como documento base para el estándar IEEE 802.15.1.

1.1. Pila de Protocolos

Una especificación de Bluetooth incluye:

Especificación Núcleo (Core specification): describe los detalles de los diversos protocolos que conforman la pila de protocolos. Especificación de perfiles (Profile specification): incluye los detalles del uso de la tecnología Bluetooth para soportar varias aplicaciones. Indica cuales de los aspectos de la especificación del núcleo son obligatorios, opcionales y no aplicables.

2 / 23


La Ilustración 1 muestra la pila de protocolos que conforman el estándar. La misma divide los protocolos en los siguientes niveles:

Protocolos fundamentales de Bluetooth (protocolos del núcleo): son específicos de la tecnología inalámbrica Bluetooth y han sido desarrollados por el SIG Bluetooth. Protocolos de sustitución de cable: suministran señalización de control que emulan el tipo de señalización que se asocia usualmente con los enlaces de cable. Protocolos de control de telefonía: definen la señalización de control de llamada para establecer llamadas de voz y datos con dispositivos Bluetooth. También define un protocolo (Comandos AT) que definen como pueden controlarse un MODEM y un teléfono móvil. Protocolos adoptados: son protocolos existentes desarrollados por otros que se utilizan para diversos fines en las capas superiores.

Bluetooth Radio

Baseband

Link Manager Protocol (LMP)

Logical Link Control and Adaptation Prottocol (L2CAP)

RFCOMMAudio Control

PPP

IP

UDP/TCP

OBEX

vCard/VCal

WAP

WAEComandos AT

TCS Bin SDP

Interfaz de Control del Host

Pro

toco

los d

e tra

nsp

ort

eP

roto

co

los

mid

dle

wa

re

Protocolos del núcleo

Protocolos de sustitución del cable Protocolos de control de telefonía

Protocolos adoptados

Bluetooth Radio

Baseband

Link Manager Protocol (LMP)

Logical Link Control and Adaptation Prottocol (L2CAP)

RFCOMMAudio Control

PPP

IP

UDP/TCP

OBEX

vCard/VCal

WAP

WAEComandos AT

TCS Bin SDP

Interfaz de Control del Host

Pro

toco

los d

e tra

nsp

ort

eP

roto

co

los

mid

dle

wa

re

Protocolos del núcleo

Protocolos de sustitución del cable Protocolos de control de telefonía

Protocolos adoptados

Ilustración 1: Pila de Protocolos de Bluetooth

1.2. Capa de Especificación de Radio

La especificación de Bluetooth establece el uso de la frecuencia de 2.4 GHz (ISM). La banda de frecuencia en la mayoría de países es de 2.4 – 2.4835 GHZ., definiéndose 79 canales físicos de 1 MHz sobre esta banda (Ver Tabla 1).

Área Rango Regulatorio Canales RFEstados Unidos, mayoría de países de Europa y muchos otros países.

2,4 – 2,4835 GHz f = 2,402 + n MHz, n= 0,…,78

Japón 2,471 – 2,497 GHz f = 2,473 + n MHz, n= 0,…,22

España 2,445 – 2,475 GHz f = 2,449 + n MHz, n= 0,…,22

Francia 2,4465 – 2,4835 GHz f = 2,454 + n MHz, n= 0,…,22

3 / 23


Tabla 1: Reservación de las Frecuencias de Bluetooth a nivel Internacional

Los radios Bluetooth viene en 3 clases dependiendo de su potencia de transmisión (Ver Tabla 2).

La técnica de modulación usada en Bluetooth es la Gaussian Frecuency-Shift-Keying (GPSK), siendo la tasa de baudios de 1 Msps. Pero ya que el tiempo de bit es 1 ms, la tasa de transmisión es 1 Mbps. Adicionalmente, Bluetooth emplea FHSS a 1600 hops/sec. Los saltos se producen entre los 79 canales de 1 MHz de forma pseudo-aleatoria.

Clase Máxima Potencia de

Salida (Pmax)

Potencia de salida

Nominal

Potencia de Salida Mínima (Pmin)

Control de Potencia

1 1000 mW (20 dBm)

N/A 1 mW (0 dBm) Pmin <+4 dBm a Pmax

Opcional:Pmin a Pmax

2 2,5 mW (4 dBm)

1 mW (0 dBm) 0,25 mW (-6 dBm)

Opcional:Pmin a Pmax

3 1 MW (0 dBm) N/A N/A Opcional:Pamin a Pmax

Tabla 2: Potencias de transmisión de los equipos Bluetooth

1.3. Capa de Especificación Baseband

La especificación de la banda base (baseband) define los procedimientos claves para permitir la comunicación entre dispositivos. Relacionados a esta capa existen una serie de conceptos que veremos a continuación, antes de describir su funcionamiento.

1.3.1. Piconets y Scatternets

Una piconet es una colección de dispositivos que pueden comunicarse. La piconet se forma de una forma ad hoc y contiene un dispositivo maestro y a lo sumo 7 dispositivos esclavos (Ver Ilustración2).

4 / 23


Maestro

Esclavo

Maestro

Esclavo

Ilustración 2: Ejemplo de una piconet

Un dispositivo en una piconet puede ser parte de otra piconet (como maestro o esclavo). Esta especie de solapamiento se conoce como scatternet (Ver Ilustración 3).

Maestro

Esclavo

Maestro

Esclavo

Ilustración 3: Ejemplo de una scatternet

1.3.2. Salto de Frecuencia

En Bluetooth el ancho de banda disponible es dividido en 79 canales físicos de 1 MHz. El salto ocurre de una frecuencia a otra en forma seudo aleatoria. La secuencia de salto es compartida entre todos los dispositivos de una piconet. Ya que la tasa de salto es de 1600 saltos/seg cada canal es ocupado por 0,625 ms. Este período es llamado slot. Los slots están numerados secuencialmente.

Los dispositivos (radios) se comunican usando Time Division Duplex (TDD). La data es transmitida en una dirección a la vez y la transmisión se alterna entre las dos direcciones. Ya que más de dos dispositivos usan el medio se está hablando de FDMA. Siendo el acceso a la piconet: FH-TDD-FDMA (ver Ilustración 4).

5 / 23


Ilustración 4: Salto de Frecuencia de Bluetooth

La transmisión de un paquete se inicia al comienzo de un slot. Si un paquete requiere más de un slot, el radio permanece en la misma frecuencia. Después retorna a la frecuencia requerida por la secuencia de salto (Ver Ilustración 5)

Ilustración 5: Transmisión de paquetes que ocupan múltiples slots.

La frecuencia de salto es determinada por el maestro. Ya que piconets diferentes en la misma área tienen diferentes maestros, tendrán diferentes frecuencias de salto. La mayoría de la veces las transmisiones en diferentes piconets ocurrirá en diferentes frecuencias. Ocasionalmente, puede haber colisiones porque dos transmisiones de dos piconets distintas (en la misma área) usando la misma frecuencia. Dichas colisiones son tratadas con la técnica de detección/corrección de errores y mecanismos ARQ.

1.3.3. Tipos de Enlaces

Existen dos tipos de enlaces que se pueden establecer entre el maestro y un esclavo:

1.- Sincrono Orientado a Conexión (SCO): es orientado al tráfico con restricciones de tiempo (audio). En dicha conexión se reserva un ancho de banda fijo en una conexión punto-a-punto (M/E) a intervalos regulares de tiempo. El maestro reserva slots (en pares, uno por cada dirección). Los

6 / 23


paquetes SCO no son retransmitidos, pero se pueden usar mecanismos de detección/corrección de errores (FEC).2.- Asíncrono no Orientado a Conexión (ACL): está destinado a tráfico best effort. La comunicación se realiza en slots no reservados para tráfico SCO. Los paquetes pueden ser retransmitidos.

1.3.4. Paquetes

La Ilustración 6 muestra la estructura de un paquete y a continuación se describe el mismo:

Código de acceso

Encabezado Carga Útil

LSB 68/72 54 0-2745 MSB

Preámbulo Sync Word Cola

LSB 4 64 4 MSB

Código de acceso

Encabezado Carga Útil

LSB 68/72 54 0-2745 MSB


LSB 4 64 4 MSB


LSB 4 64 4 MSB

Ilustración 6: Formato de Paquete Baseband Bluetooth

Código de Acceso (AC): existe un código corto (68 bits) y otro largo (72 bits). El AC corto es usado para sincronismo, compensación del desplazamiento DC e identificación e identifica todos los paquetes en un canal físico. Los paquetes enviados por un mismo canal físico deben tener el mismo AC. Hay tres tipos de Código de Acceso (AC):

Código de acceso del Canal (CAC): identifica un piconet. Todos los paquetes enviados en la misma piconet tienen el mismo CAC.

Código de Acceso del Dispositivo (DAC): usado para búsquedas (paging) y subsecuentes respuestas.

Código de Acceso de Indagación (IAC): puede ser general o dedicado. El primero se usa para descubrir dispositivos que estén en el alcance. El segundo es usado para un grupo dedicado de dispositivos.

Adicionalmente, el AC incluye los siguientes campos:

Preçambulo: tiene un patrón fijo de 4 símbolos y es usado para compensar el DC. Su valor depende del LSB de la palabra de sincronización (sync word).

Cola: tiene un patrón fijo de 4 símbolos y es usado para extender compensación del DC junto con los tres MSB del syncword. Su valor depende del MSB de la palabra de sincronización (syncword).

SyncWord: cada dispositivo Bluetooth tiene una dirección de 48 bits. Los 24 bits menos significativos son llamados parte de la dirección menos significativa (LAP). El LAP es usado para forma la syncword. Para el CAC, la dirección LAP del maestro es usada. Para

7 / 23


el GIAC o el DIAC, los LAPs reservados y dedicados son usados. Para la DAC, la dirección LAP del esclavo es usada.

La palabra syncword se forma de la siguiente forma:

o Sumar bits al LAP.o Generar la secuencia PN.o Hacer el XOR de resultante paso 1 y parte secuencia PN.o Generar un código de error de 34 bits para el bloque de

información anterior y colocarlo al comienzo.o Hacer XOR de la PN y la secuencia de 64 bits producida en

paso 4.

Encabezado del paquete: esta formado por los siguientes campos:

o LT-ADDR: dirección de transporte lógica para el paquete. Es la dirección temporal asignada al esclavo en dicha piconet.

o Tipo: identifica el tipo de paquete.o Flujo: proporciona un mecanismo para el control de flujo de un solo

bit para el tráfico ACL.o ARQN: proporciona un mecanismo de reconocimiento de 1 bit para

tráfico ACL protegido por un CRC.o SEQN: proporciona un esquema de numeración secuencial de 1-bit.

Los paquetes transmitidos son etiquetados con 1 o 0.o HEC: Un código de detección de error para proteger el encabezado.

LT_ADDR Tipo Flujo ARQNSEQN HEC

LSB MSB3 4 1 1 1 8

LT_ADDR Tipo Flujo ARQNSEQN HEC

LSB MSB3 4 1 1 1 8

Ilustración 7: Formato del campo de encabezado del paquete.

Carga Útil del Paquete: hay dos tipos de campos:

o Campo sincrono: transporta paquetes SCO. Esta formado por el cuerpo y un campo CRC de 16 bits.

o Campo asíncrono: transporta paquetes ACO. Esta formado por: el encabezado, cuya longitud es de 8 bits para paquetes de un slot y 16 bits para paquetes multi slots; el cuerpo que contiene información del usuario y el CRC de 16 bits para la carga útil excepto en paquetes de tipo AUX1. El encabezado esta formado a su vez por el LLID que identifica el canal lógico (por ejemplo, mensaje L2CAP no fragmentado, continuación de un mensaje L2CAP fragmentado), un campo indicador de flujo y la longitud: del cuerpo.

1.3.5. Mecanismos de Corrección de Errores

Los siguientes son los mecanismos para la corrección de errores definidos por el estándar Bluetooth:

8 / 23


o 1/3 FEC: envía tres copias del mismo bit.o 2/3 FEC: basado en código de Hamming (ver [1])).o ARQ: usa para la detección de errores el CRC/FEC. Utiliza ACKs

positivos para reconocer tramas recibidas exitosamente y retransmite paquetes después que se ha vencido el correspondiente timeout. Adicionalmente, un receptor que recibe un paquete dañado puede enviar un ACK negativo. El emisor al recibir este debe retransmitir el paquete (Ver Ilustración 8).

Ilustración 8: Ejemplo del intercambio de paquetes usando ARQ

1.3.6. Canales Lógicos

Bluetooth defines los siguientes tipos de canales de data lógicos:

o Control de Enlace (LC): transporta información de control de enlace de datos tal como ARQ, control de flujo y caracterización de la carga útil.

o Gestión de Enlace (LM): soporta trafico LMP y es transportado en paquetes SCO y ACL.

o Usuario Asíncrono (UA): transporta data del usuario asíncrona.o Usuario Isócrono (UI): transporta data de usuario isócrona.o Usuario Sincrono (US): transporta data del usuario sincronía

1.3.7. Establecimiento de la Conexión

Los estado envueltos en el establecimiento de la conexión se muestran en la Ilustración 9, el cual ha sido tomado de la especificación de Bluetooth [1].

9 / 23


Ilustración 9: Estado que intervienen en el establecimiento de una conexión.

Dichos estados se agrupan en estado de Prevenido (Standby), estado de Indagación (Inquiry), estado de Page y estado de Conexión (Connection). El estado de standby es el estado inicial en que se encuentra un dispositivo el cual no ha establecido una conexión. En el estado de inquiry, un dispositivo colecta información acerca de otros dispositivos cercanos para obtener información básica, tal como la dirección Bluetooth del dispositivo y valores del reloj. Esta compuesto por varios sub estados; el de inquiry, ejecutado por el potencial maestro y los estados de inquiry scan y inquiry response ejecutados por los potenciales esclavos.

En el sub estado de inquiry, un potencial maestro transmite paquetes de indagación los cuales son recibidos por los esclavos en el sub estado de inquiry scan. Ya que durante el procedimiento de establecimiento de una conexión bandabase, los roles del maestro y del esclavo no están definidos, se denomina un potencial maestro aquel dispositivo que inicia un proceso de indagación destinado a establecer una conexión. En el sub estado de inquiry scan, un dispositivo busca mensajes de inquiry enviados por un potencial maestro. Una vez recibido un mensaje de inquiry un potencial esclavo debe entrar al estado de inquiry response.

En el estado de page, un dispositivo invita a otro a juntarse a su piconet. Similarmente al estado de indagación, el estado de page está compuesto por varios sub estados. Los sub estados de page y master response los cuales son ejecutado por el potencial maestro y los de page scan y slave response ejecutados por los esclavos. En el sub estado de page, un maestro activa y puede conectarse a un esclavo que esta en el sub estado de page scan. Un esclavo entra en el sub estado de slave response cuando recibe un mensaje de page. En este estado el esclavo espera recibir un mensaje de master response. Después de recibir dicho mensaje, responde con otro mensaje y entra al estado de connection (es decir, está conectado con el dispositivo maestro). En el sub estado de

10 / 23


page scan, el esclavo escucha por mensajes de page del esclavo. Un maestro entra en el estado de master response una vez recibido un mensaje de page response del esclavo. El maestro transmite un paquete conteniendo la información necesaria para que el esclavo pueda entrar en el estado de connection. Una vez que recibe una respuesta del esclavo, el maestro puede entrar al estado de connection. El estado de park fue descrito anteriormente.

1.3.8. Conexión

La Ilustración 10 muestra los estados en que puede estar un dispositivo una vez establecida una conexión. Estos se describen a continuación:

Ilustración 10: Estados de una Conexión.

Active: participa en una piconet. En este estado escucha, transmite y recibe paquetes. Sniff: escucha en slots específicos. Hold: no soporta paquetes ACL. Es un estado de potencia reducida. Puede aún participar en el intercambio de paquetes SCO. Park: no participa en la piconet, pero es retenido como parte de la piconet.

1.4. Seguridad

La especificación banda base define una facilidad para proporcionar seguridad entre dos dispositivos Bluetooth que están estableciendo una conexión. La misma consiste de los siguientes elementos:

Autenticación: tiene como finalidad verificar identidades de las unidades involucradas en el procedimiento. Cifrado: la información del usuario puede ser protegida cifrando el paquete; sin embargo, el código de acceso y el encabezado del paquete nunca se cifran.

Para mantener la seguridad a nivel de enlace, se usan cuatro parámetros:

Dirección del dispositivo Bluetooth (BD_ADDR): es única y tiene una longitud de 48 bits. Es asignada por la IEEE. Clave privada de autenticación de usuario: tiene una longitud fija de 128 bits.

11 / 23


Clave privada de cifrado: esta clave de usuario tiene longitud variable (entre 8 y 128 bits) y se obtiene durante el proceso de autenticación, a partir de la clave de autenticación. Número aleatorio (RAND): se obtiene de un proceso pseudo aleatorio que se llevará a cabo en el dispositivo Bluetooth. Este número cambiará periódicamente.

1.4.1. Autenticación

La entidad encargada de la autenticación, realiza la misma, usando una rutina convencional de desafío/respuesta, lo cual se realiza para asegurar que la entidad tratada posee su clave secreta. Esta clave de enlace es compartida por los dispositivos que se van a comunicar. La clave de enlace (de autenticación) es un número aleatorio de 128 bits que se comparte entre dos o más dispositivos, que además de ser usada durante el proceso de autenticación, forma parte de los parámetros usados para crear la clave de cifrado.

En la Ilustración 11 se muestra el esquema de desafío-respuesta para Bluetooth. El demandante transmite su dirección de 48 bits exigida por el verificador. Entonces el verificador retorna al demandante un desafío en la forma de un número aleatorio de 128 bits (AU_RAND), el cual junto con una clave de enlace secreta compartida de 128 bits y la dirección del demandante (BD_ADDR), forman parte de la entrada a una función Hash, dando como salida una firma de 32 bits (SRES). Esta firma producida por el demandante es enviada al verificador, quien compara ese resultado con su propio Hash (SRES’), sólo si ambos números calculados son los mismos, la autenticación habrá tenido éxito. Lo que quiere decir que quien emitió el desafío, procederá con el establecimiento de la conexión. El algoritmo E1 además de la salida SRES’, también da como resultado el parámetro ACO (Authenticated Ciphering Offset), que será utilizado para generar la clave de cifrado en el proceso de encriptación.

Ilustración 11: Autenticación usando un esquema de Desafío- Respuesta.

12 / 23


Si el proceso de autenticación falta, debe pasar un tiempo antes de intentarlo nuevamente. Este tiempo se incrementa exponencialmente, para que así, el tiempo que transcurra después de un intento fallido sea por ejemplo el doble de tiempo de espera antes de ese fallo. Por otro lado, el tiempo de espera decrecerá exponencialmente cuando no haya fallos en un determinado período de tiempo.

1.4.2. Cifrado

El proceso de cifrado usa un algoritmo que se llama E0. El procedimiento se muestra en la Ilustración 12 y la Ilustración 13 que se explica a continuación. Para cada transmisión de un paquete se genera una nueva clave de cifrado de la siguiente forma. Se combinan en una función RAND compleja, la dirección del dispositivo, un número de 26 bits que representa el reloj maestro y la clave secreta de cifrado. Esta clave es usada como una entrada para E0 para producir un flujo continuo de bits llamado z en la figura. El algoritmo E0 se implementa usando cuatro LFSRs (Linear Feedback Shift Registers), cuyas longitudes son de 25, 31, 33, 39 sumando en total 128 bits. La cadena z es sumada módulo-2 a los datos que se van a cifrar. Como el valor del reloj cambia por cada cifrado una cadena de cifrado distinta es usada cada vez mejoerando la seguridad.

El desencriptado se realizará exactamente de la misma manera usando la misma clave que se usó para la encriptación.

Ilustración 12: Proceso de cifrado en Bluetooth

Ilustración 13: Proceso de Cifrado en Bluetooth

1.5. Especificación del Manejador del Enlace (LMP)

13 / 23


Esta capa es la encargada de gestionar diversos aspectos del enlace de radio entre el maestro y el esclavo. Para ellos utiliza una serie de mensajes (PDUs), que se distribuyen en 24 áreas funcionales y los cuales son intercambiados en la forma de LMP PDUs. Estos mensajes son siempre enviados en un slot.

A continuación se describen las funciones del protocolo:

1.5.1. Funciones de Respuesta General

LMP define dos tipos de PDUs para responder a otro PDU: aceptado (accepted) o no aceptado (not_accepted).

1.5.2. Servicio de Seguridad

Estos servicios incluyen los siguientes:

o Autenticacióno Emparejamientoo Cambio de la clave de enlaceo Cambio de la clave de enlace en cursoo Encriptamiento

1.5.3. Sincronismo

LMP proporciona mecanismos de sincronismo en la diferentes piconets participantes:

o Requerimiento de desplazamiento de relojo Información de desplazamiento del sloto Requerimiento de información de la exactitud del temporizador

1.5.4. Capacidades de la Estación

LMP incluye información que se intercambia acerca de los dispositivos que se están comunicando:

o Versión de LMPo Características soportadas

1.5.5. Control de Modos

Bluetooth soporta cierto número de estados y modos los cuales son manejados a través de las siguientes funciones:

o Intercambio del rol de esclavo/maestroo Requerimiento de nombreo Desconexióno Coloca el enlace entre un maestro y un esclavo en modo de holdo Entrar en el modo sniff

14 / 23


o Coloca a un esclavo en modo Parko Permite el cambio de un canal entre un modo protegido con un

código 2/3 FEC o no protegido con ningún FECo Define dos parámetros de QoSo Establecimiento de enlaces SCOo Arbitra el máximo número máximo de slots de tiempo que un

paquete puede cubriro Determina el esquema de paging a ser usado entre dispositivos en

la piconeto Supervisión de enlace para declararlo como que tiene alguna falla

L2CAP es un protocolo de la capa de enlace entre entidades con un número de servicios. Confía en protocolos de las capas más bajas para control de error y flujo. Hace uso de los enlaces ACL pero no soporta enlaces SCO. Proporciona los siguientes servicios, los cuales pueden ser usados por los protocolos de las capa superiores:

o No orientado a conexión: soporte a un servicio no orientado a la conexión. Cada canal es unidireccional. Usado del maestro a múltiples esclavos.

o Orientado a la conexión: soporte a un servicio orientado a la conexión. Cada canal es bidireccional.

o Señalización: provee el intercambio de mensajes de señalización entre entidades L2CAP.

1.6. Protocolos Middleware

Algunos de los protocolos que usan los servicios de los protocolos de transporte descritos anteriormente se describen a continuación (Ver Ilustración 1):

1.6.1. Protocolo de Descubrimiento de Servicios (Service Discovery Protocol, SDP)

Permite que un dispositivo Bluetooth pregunte acerca de los servicios que otro dispositivos conectados pueden tener y como accederlo. SDP no proporciona los mecanismos para accederlos. SDP soporta las siguientes indagaciones:

o Búsqueda según clase de servicioo Búsqueda según los atributos de los servicioso Navegación por los servicios

Algunos de los protocolos que usan los servicios de los protocolos de transporte descritos anteriormente se describen a continuación (Ver Ilustración 35):

1.6.2. Protocolo de RFCOMM

Permite que aplicaciones que han sido diseñadas e implementadas para operar sobre cables eriales corran sobre Bluetooth sin ser

15 / 23


modificadas. Este protocolo emula las señales sobre los nueve hilos de un cable de interconexión RS-232.

1.6.3. Protocolo de Señalización de Control de Telefonía (Telephony Control Signaling, TCS)

Soporta funciones de telefonía normales entre las que se encuentran iniciación y terminación de una llamada, reconocer una llamada entrante, aceptar una llamada. El soporta comunicación punto a punto y punto a multipunto.

1.6.4. Otros Protocolos

Incluyen protocolos adoptados de otras organizaciones. El protocolo PPP (Point-to-Point Protocol) es un estándar del IETF para soportar la comunicaron IP sobre líneas seriales. El OBEX (Object Exchange Protocol) desarrollado por IrDA para el transporte de objetos entre dispositivos.

Los perfiles de Bluetooth definen los protocolos y las características que soporta un modelo de uso. Un modelo de uso es un conjunto de protocolos que implementan una aplicación particular basada en Bluetooth. Los perfiles se pueden dividir en [3] generales y específicos.

1.7. Especificación de los Perfiles de Bluetooth

Los Perfiles Generales incluyen:

o Perfil de acceso genérico (Generic Access Profile, GAP).o Perfil del puerto en serial (Serial Port Profile, SPP).o Perfil de aplicación de descubrimiento de servicios (Service

Discoveryo Application Profile, SDAP).o Perfil genérico de intercambio de objetos (Generic Object

Exchange Profile, GOEP).

Los Perfiles Específicos incluyen:

o Perfil de transferencia de archivos (File Transfer Profile).o Perfil de acceso a una LAN (LAN Access Profile).o Perfil de sincronización (Synchronization Profile).o Perfil de telefonía inalámbrica (Cordless Telephony Profile)o Perfil de auriculares (Headset Profile).o Perfil de fax (Fax profile).o Perfil de inter comunicación (Intercom Profile)o Perfil de acceso telefónico a redes (Dial-UP Networking Profile)o Perfil de acceso de carga de objetos

La siguiente Ilustración 14 muestra la relación de dependencia entre los perfiles mencionados:

16 / 23


Perfil de TelefoníaInalámbrica

Perfil deIntercomunicación

Perfil de Acceso Telefónico a Redes

Perfil de TransferenciaDe Archivos

Perfil de Cargade Objetos

Perfil de Sincronización

Perfil de Fax

Perfil de Auriculares

Perfil de Acceso a Redes LAN

Perfil de Acceso Genérico

Perfil de Descubrimiento de Servicios

Perfiles Basados en TCS-Bin

Perfil Genérico de Intercambio de Objetos

Perfil de Puerto Serial

Perfil de TelefoníaInalámbrica

Perfil deIntercomunicación

Perfil de Acceso Telefónico a Redes

Perfil de TransferenciaDe Archivos

Perfil de Cargade Objetos

Perfil de Sincronización

Perfil de Fax

Perfil de Auriculares

Perfil de Acceso a Redes LAN

Perfil de Acceso Genérico

Perfil de Descubrimiento de Servicios

Perfiles Basados en TCS-Bin

Perfil Genérico de Intercambio de Objetos

Perfil de Puerto Serial

Ilustración 14: Relación entre los perfiles de Bluetooth

1.7.1. Perfil de Acceso Genérico

Este perfil define los procedimientos genéricos para descubrir dispositivos Bluetooth y aspectos relacionados a la gestión de enlace para dispositivos que están estableciendo una conexión. El perfil de acceso genérico describe el uso de las capas inferiores tal como la LC y LMP, describe las alternativas de seguridad incluyendo las de las capas superiores tales como L2CAP, RFCOMM y OBEX. La Ilustración 15 muestra los protocolos cubiertos por este perfil.

Ilustración 15: Pila de Protocolos cubiertos por el perfil de acceso genérico

1.7.2. Perfil del Puerto Serial

Este perfil está construido sobre el perfil de acceso genérico y establece como deben configurarse los dispositivos Bluetooth para emular una conexión serial usando RFCOMM. Las aplicaciones que utilizan este perfil son normalmente aplicaciones heredadas que utilizan la comunicación serial y que no deben estar al tanto que la comunicación se esta realizando sobre el un enlace Bluetooth.

17 / 23


Banda base

L2CAP LMP

RFCOMM SDP

Emulación del puerto serial

Aplicación A

Banda base

LMP L2CAP

RFCOMM SDP


Aplicación B

Banda base

L2CAP LMP

RFCOMM SDP


Aplicación A

Banda base

L2CAP LMP

RFCOMM SDP


Aplicación A

Banda base

LMP L2CAP

RFCOMM SDP


Aplicación B

Banda base

LMP L2CAP

RFCOMM SDP


Aplicación B

Ilustración 16: Pila de protocolos para el perfil del puerto serial

1.7.3. Perfil de Aplicación de Descubrimiento de Servicios:

Este perfil describe como un dispositivo puede descubrir servicios registrados en otros dispositivos Bluetooth al igual que otra información acerca de estos servicios. La Ilustración 17 muestra la pila de protocolos para este perfil.

Banda base

Capa L2CA

Aplicación deDescubrimiento de

Servicio

SDP (cliente)

BT-module-Cntrl

LM

ACL

CO

Banda base

Capa L2CA

SDP (cliente)

BT-module-Cntrl

LM

ACL

CO

Base de datos de requisitos de

servicios

Banda base

Capa L2CA


Servicio

SDP (cliente)

BT-module-Cntrl

LM

ACL

CO

Banda base

Capa L2CA


Servicio

SDP (cliente)

BT-module-Cntrl

LM

ACL

CO

Banda base

Capa L2CA

SDP (cliente)

BT-module-Cntrl

LM

ACL

CO

Base de datos de requisitos de

servicios

Ilustración 17: Pila de Protocolos para el perfil de aplicación de descubrimiento de servicios

1.7.4. Perfil Genérico de Intercambio de Objetos

Este perfil define como los objetos pueden ser intercambiados usando el protocolo OBEX. El perfil indica los requerimientos expresados en términos de las características y procedimientos que son requeridos para la interoperabilidad entre dispositivos Bluetooth en el modelo de uso del intercambio de objetos. Dependiendo de este perfil (ver Ilustración18), hay perfiles para sincronizar información de gestión personal (PIM), transferencia de archivos y carga de objetos (como por ejemplo tarjetas de negocios). La Ilustración 18 muestra la pila de protocolos para éste perfil:

18 / 23


Banda base

L2CAP LMP

RFCOMM SDP

OBEX

Aplicación Cliente

Banda base

LMP L2CAP

RFCOMM SDP

OBEX

Aplicación Servidora

Lado del cliente Lado del servidor

Banda base

L2CAP LMP

RFCOMM SDP

OBEX

Aplicación Cliente

Banda base

L2CAP LMP

RFCOMM SDP

OBEX

Aplicación Cliente

Banda base

LMP L2CAP

RFCOMM SDP

OBEX


Banda base

LMP L2CAP

RFCOMM SDP

OBEX



Ilustración 18: Pila de protocolos para el perfil genérico de intercambio de objetos

1.7.5. Perfil de Transferencia de Archivos:

Este perfil ofrece la capacidad de transferir objetos de datos de un dispositivo a otro tales como hoja de cálculo, presentaciones, imágenes. La Ilustración 19 muestra la pila de protocolos de este perfil:

Banda base

L2CAP LMP

RFCOMM SDP

OBEX

Aplicación Cliente de Transferencia de Archivos

Banda base

LMP L2CAP

RFCOMM SDP

OBEX

Aplicación Servidor de Transferencia de Archivos


Banda base

L2CAP LMP

RFCOMM SDP

OBEX


Banda base

L2CAP LMP

RFCOMM SDP

OBEX


Banda base

LMP L2CAP

RFCOMM SDP

OBEX


Banda base

LMP L2CAP

RFCOMM SDP

OBEX



Ilustración 19: Pila de Protocolos del Perfil de Transferencia de Archivos

1.7.6. Perfil de Acceso a una LAN:

Este perfil le permite a un dispositivo Bluetooth acceder a una LAN, tal como si estuviera conectado a la red, usando PPP. En este modelo los dispositivos utilizan un punto de acceso a una LAN como conexión inalámbrica a la LAN. La Ilustración 20 muestra la pila de protocolos para este perfil. Note que ME es una entidad de gestión (managment entity) que coordina procedimientos durante la inicialización, configuración y gestión de la conexión.

19 / 23


Banda base

L2CAP

RFCOMM

TCP / UDP

IP

PPP

SDPME

Aplicaciones

LMP

Banda base

L2CAP

SDP

PPP

RFCOMM

LMP

PPP networking

ME

LAN

TCP / UDP

IP

Aplicaciones

LAN

Dispositivo Bluetooth Punto de acceso LAN LAN

Banda base

L2CAP

RFCOMM

TCP / UDP

IP

PPP

SDPME

Aplicaciones

LMP

Banda base

L2CAP

SDP

PPP

RFCOMM

LMP

PPP networking

ME

LAN

TCP / UDP

IP

Aplicaciones

LAN

Dispositivo Bluetooth Punto de acceso LAN LAN

Ilustración 20: Pila de Protocolos de Perfil de Acceso a una LAN

1.7.7. Perfil de Sincronización

Este perfil define los requerimientos de la aplicación para los dispositivos Bluetooth para el soporte del modelo de uso de sincronización. La Ilustración 21 muestra la pila de protocolos de este perfil:

Banda base

L2CAP LMP

RFCOMM SDP

OBEX

Aplicación IrMC

Banda base

LMP L2CAP

RFCOMM SDP

OBEX

Aplicación Servidor IrMC


Banda base

L2CAP LMP

RFCOMM SDP

OBEX

Aplicación IrMC

Banda base

L2CAP LMP

RFCOMM SDP

OBEX

Aplicación IrMC

Banda base

LMP L2CAP

RFCOMM SDP

OBEX


Banda base

LMP L2CAP

RFCOMM SDP

OBEX



Ilustración 21: Pila de Protocolos de Perfil de Sincronización

1.7.8. Perfil de Telefonía Inalámbrica

Este perfil define los procedimientos para la realización de llamadas a través de una estación base y la realización de llamadas en forma directa. También permite el acceso de servicios complementarios provistos por una red general de conmutación externa. La Ilustración22muestra la pila de protocolos de este perfil. El gateway es el dispositivo que proporciona acceso a la red pública tal como un MODEM y el terminal de data es el dispositivo que usa los servicios de telefonía del gateway.

20 / 23


TCS

Banda base

L2CAP

Control de Sincronización de

la llamada

Aplicación de telefonía

SDP

Control dellamadas

Discriminación de protocolos

SCO

CLCO

LMP

ACL

Gestión del GrupoCL

TCS

Banda base

L2CAP


la llamada


SDP

Control dellamadas


SCO

CLCO

LMP

ACL

Gestión del GrupoCL

Ilustración 22: Pila de Protocolos y Procedimientos de Perfil de Telefonía Inalámbrica.

1.7.9. Perfil de Auriculares

Este perfil define los protocolos y procedimientos para soportar el uso de auriculares. El auricular debe actuar como entrada de audio e interfaz de salida de un dispositivo. El mismo debe ser capaz de responder llamadas entrantes y finalizarlas sin uso del teclado del teléfono. La Ilustración 23muestra la pila de protocolos para este perfil. El control del auricular es responsable por la señalización de control específica de los auriculares esta basado en comandos AT. El nivel de emulación del puerto de audio emula el puerto de audio en un teléfono celular o en un PC. El controlador de audio es el software en los auriculares.

Banda base

L2CAP LMP

RFCOMM SDP

Control del Auricular

Aplicación (Emulación de

puerto de audio)

Banda base

LMP L2CAP

RFCOMM SDP


Aplicación (Controlador de audio)

Lado del gatewayde audio

Lado del auricular

Banda base

L2CAP LMP

RFCOMM SDP


Aplicación (Emulación de

puerto de audio)

Banda base

LMP L2CAP

RFCOMM SDP


Aplicación (Controlador de audio)

Lado del gatewayde audio

Lado del auricular

Ilustración 23: Pila de Protocolos del Perfil de Auriculares

1.7.10. Perfil de Fax

Este perfil define los protocolos y procedimientos para el soporte del caso de uso del Fax. Un teléfono celular o un MODEM con Bluetooth instalado pueden ser usados por una PC como MODEM-fax inalámbrico. La Ilustración 24 muestra la pila de protocolos de este perfil. El nivel de marcación y control define los comandos y procedimientos para la marcación y control automáticos del enlace serie asíncrono proporcionado

21 / 23


por los niveles inferiores. El nivel de emulación de MODEM es la entidad responsable de emular el MODEM y el controlador del MODEM es el software controlador en el Terminal de datos.

Banda base

L2CAP LMP

RFCOMM SDP

Marcación y control

Aplicación (Emulación del

MODEM)

Banda base

LMP L2CAP

RFCOMM SDP


Aplicación (Controlador del MODEM)

Lado del gateway Lado del terminalde datos

Banda base

L2CAP LMP

RFCOMM SDP



MODEM)

Banda base

LMP L2CAP

RFCOMM SDP




Ilustración 24: Pila de protocolos del perfil de Fax

1.7.11. Perfil de Intercomunicación

Este perfile soporta el uso de escenarios que implican un enlace vocal directo tales como dos usuarios de teléfonos que establezcan una comunicación sobre una conexión Bluetooth. La Ilustración 25 muestra la pila de protocolos de este perfil:

TCS

Banda base

L2CAP


la llamada


SDP

Control dellamadas


SCO

CLCO

LMP

ACL

TCS

Banda base

L2CAP


la llamada


SDP

Control dellamadas


SCO

CLCO

LMP

ACL

Ilustración 25: Pila de Protocolos del perfil de intercomunicación

1.7.12. Perfil de Acceso Telefónico a Redes

Este perfil define los procedimientos y protocolos usados por dispositivos tales como MODEM y teléfonos celulares para implementar el modelo de uso denominado puente Internet. Por ejemplo el uso de un teléfono celular como MODEM inalámbrico para conectar una PC o PDA a una servidor de acceso telefónico a Internet. La Ilustración 26 muestra la pila de protocolos de éste perfil:

22 / 23


Banda base

L2CAP LMP

RFCOMM SDP



MODEM)

Banda base

LMP L2CAP

RFCOMM SDP




Banda base

L2CAP LMP

RFCOMM SDP



MODEM)

Banda base

LMP L2CAP

RFCOMM SDP




Ilustración 26: Pila de Protocolos del perfil de acceso telefónico a redes.

1.7.13. Perfil de Carga de Objetos

Este perfil define los requisitos de aplicación para soportar el modelo de uso de carga de objetos entre dispositivos Bluetooth. Este perfil permite a un dispositivo cargar un objeto (tal como una tarjeta de negocios o una cita) en la carpeta de entrada de otro dispositivo. El dispositivo también pude descargarse una tarjeta desde otro dispositivo Bluetooth. Dos dispositivos pueden también intercambiar objetos. La Ilustración 27 muestra la pila de protocolos de este perfil.

Banda base

L2CAP LMP

RFCOMM SDP

OBEX

Aplicación (Cliente de carga)

Banda base

LMP L2CAP

RFCOMM SDP

OBEX

Aplicación (Servidor de carga)

Cliente de carga Servidor de carga

Banda base

L2CAP LMP

RFCOMM SDP

OBEX

Aplicación (Cliente de carga)

Banda base

LMP L2CAP

RFCOMM SDP

OBEX

Aplicación (Servidor de carga)

Cliente de carga Servidor de carga

Ilustración 27: Pila de Protocolos del perfil de Carga de Objetos.

[1]Bluetooth SIG, Inc. Specification of the Bluetooth System version 2.0. 05 November 2003.

[2]Bisdikian C. An Overview of the Bluetooth Wireless Technology. IEEE Communications Magazine. December 2002. pp 86-95.

[3]Muller N. Tecnología Bluetooth. McGraw-Hill Professional. España, 2002.

i.

23 / 23

Documents

Bluetooth