Bluetooth

Visión General de una red inalámbrica

Ingeniería Informática

UNIVERSITAT DE VALÈNCIA
Estudi general

17 DE ABRIL DEL 2004

José Ignacio Gil Bailén
INDICE

1 Introducción......................................................................................3
1.1 ¿Qué es el Bluetooth?..........................................................3
1.2 Un poco de historia...............................................................3
2 Protocolos Bluetooth........................................................................3
2.1 Radio Bluetooth………..........................................................4
2.2 Banda Base…………............................................................5
2.3 LMP: Link Manager Protocol................................................12
2.4 L2CAP:Logical Link Control and Adaptation Protocol..........13
2.5 SDP: Service Discovery Protocol.........................................16
2.6 RFCOMM: ...........................................................................18
3 Perfiles Bluetooth.............................................................................20
3.1 Perfil de acceso genérico ....................................................21
3.2 Perfil de Aplicación del Descubrimiento de Servicio………. 21
3.3 Perfil Puerto Serie…..............................................................21
3.4 Perfil genérico de intercambio de objetos…..........................21
3.5 Perfil de Teléfono Inalámbrico...............................................21
3.6 Perfil de Intercomunicación...................................................22
3.7 Perfil de acceso telefónico a redes........................................22
3.8 Perfil de FAX..........................................................................22
3.9 Perfil de Manos Libres............................................................22
3.10 Perfil de Acceso a LAN.........................................................22
3.11 Perfil de Transferencia de Archivos......................................22
3.12 Perfil de Transferencia de Objetos.......................................22
3.13 Perfil de Sincronización........................................................22
4 Aplicaciones y productos Bluetooth................................................22
5 Bibliografía..........................................................................................26

_____________________________________________________________________________________
19/11/2010 2
1. Introducción
1.1 ¿Qué es el Bluetooth?

Bluetooth define un estándar global, tanto hardware como software, de comunicación

inalámbrica. Esta Tecnología posibilita la transmisión de voz y datos entre diferentes equipos
mediante un enlace por radiofrecuencia en distancias cortas, tanto si se refiere a ambientes de
trabajo cerrados (oficinas, despachos, etc.) como si se refiere a espacios públicos.

Uno de los objetivos de esta tecnología es la posibilidad de reemplazar o eliminar la gran

cantidad de cables y conectores que enlazan unos dispositivos con otros. Además esta
tecnología pretende facilitar la interacción y sincronización de los diferentes dispositivos tanto
móviles como fijos que se desee, todo ello sin necesidad de visión directa entre ellos.

Otro objetivo es la de obtener una tecnología de bajo coste y potencia que posibilite
dispositivos baratos.

1.2. Un poco de historia...

Aunque la versión 1.0A de la especificación de Bluetooth fue publicada en Julio de 1999, años
antes más concretamente en 1994 Ericsson inicia un estudio para investigar la posibilidad de
una interfase vía radio, de bajo coste y bajo consumo, para la interconexión entre teléfonos
móviles y otros accesorios con la intención de eliminar cables entre aparatos. El estudio partía
de un largo proyecto que investigaba sobre unos multicomunicadores conectados a una red
celular, hasta que se llegó a un enlace de radio de corto alcance, llamado MC link. Conforme
éste proyecto avanzaba se fue viendo claro que éste tipo de enlace podía ser utilizado
ampliamente en un gran número de aplicaciones, ya que tenia como principal virtud el que se
basaba en un chip de radio relativamente económico.

A comienzos de 1997, según avanzaba el proyecto MC link, Ericsson fue despertando el interés
de otros fabricantes de equipos portátiles. Enseguida se vió claramente que para que el
sistema tuviera éxito, un gran número de equipos deberían estar equipados con ésta
tecnología. Esto fue lo que originó que en Febrero de 1998, la creación de un grupo llamado
Special Interest Group (SIG) formado por 5 promotores que fueron: Ericsson, Nokia, IBM,
Toshiba e Intel. La idea era lograr un conjunto adecuado de áreas de negocio: dos líderes del
mercado de las telecomunicaciones, dos líderes del mercado de los PCS portátiles y un líder de
la fabricación de chips. El propósito principal del consorcio fué y es, el establecer un estándar
para la interface aérea junto con su software de control, con el fin de asegurar la
interoperatibilidad de los equipos entre los diversos fabricantes. Más tarde en diciembre de
1999 se unieron a la iniciativa Microsoft, 3com, Axis Comunication, Compaq, Dell, Motorola,
Xircom, Lucent y otros publicando a su vez una nueva versión de la tecnología conocida como
1.0B. En febrero del 2000 como prueba del gran desarrollo de Bluetooth ya son más de 1500
empresas las adheridas al grupo SIG. Y por supuesto siguen publicándose nuevas versiones
adaptando las nuevas mejoras que van apareciendo, la última publicación se trata de la
versión 2.0.

Los promotores e impulsores de ésta tecnología decidieron ponerle un nombre que se pudiera
hacer popular, en lugar de una nomenclatura técnica. Pensaron en un rey escandinavo, Harald
II apodado Blåtand o “diente-azul” (Bluetooth) que reinó sobre Dinamarca y Noruega en el siglo
X y que unificó varios pueblos y reinos bajo una nueva religión, la cristiana.

2. Protocolos Bluetooth

_____________________________________________________________________________________
19/11/2010 3
Uno de los principales objetivos de la tecnología Bluetooth es conseguir que aplicaciones de
dispositivos diferentes mantengan un dialogo fluido. Para conseguirlo, ambos, deben ejecutarse
sobre la misma pila de protocolos.

Protocolos del núcleo de Bluetooth

La pila esta constituida por dos clases de protocolos. Una primera clase llamada de protocolos
específicos que implementa los protocolos propios de Bluetooth. Y una segunda clase formada
por el conjunto de protocolos adoptados de otras especificaciones. Esta división en clases en el
diseño de la pila de protocolos de Bluetooth permite aprovechar un conjunto muy amplio de
ventajas de ambas. Por un lado, al implementar protocolos específicos de Bluetooth permite
utilizar los beneficios que aporta la adopción de la tecnología Bluetooth. Por otro lado la
utilización de protocolos no específicos ofrece la ventaja de la interacción de esta tecnología
con protocolos comerciales ya existentes. Así como la posibilidad de que Bluetooth este abierto
a implementaciones libres o nuevos protocolos de aplicación de uso común. La pila de
protocolos se puede dividir en cuatro capas lógicas:

- Núcleo de Bluetooth : Radio, Banda Base, LMP, L2CAP, SDP

- Sustitución de cable: RFCOMM
- Protocolos adoptados: PPP, UDP, TCP, IP, OBEX, WAP, IRMC, WAE
- Control de telefonía: TCS-binary, AT-Commands

El llamado de núcleo de Bluetooth, mirar la figura anterior, ha sido implementado en su

totalidad por el SIG, no obstante otros como RFCOMM y TCS-binary pese a ser desarrollados
por el propio SIG, los han desarrollado siguiendo las recomendaciones de otras instituciones de
telecomunicaciones.

El resto de capas lógicas de sustitución de cable, de control de telefonía y de protocolos

adoptados agrupan a los protocolos orientados a aplicación, permitiendo así a las diferentes
aplicaciones existentes o desarrolladas en el futuro poder correr sobre el núcleo de Bluetooth.
Como es una norma abierta en cuanto a los protocolos que corren encima de los protocolos
específicos de transporte, se pueden hacer implementaciones que usen protocolos tan usados
como FTP o HTTP por ejemplo. A partir de aquí se va a realizar una descripción detallada de
los protocolos que emplea Bluetooth en su núcleo, y que constituyen la base de su
funcionamiento.

2.1 Radio Bluetooth (RF)

Bluetooth fue diseñado para operar en un entorno de radio frecuencia ruidoso (LANs, mandos,
hornos microondas), y para ello utiliza un esquema de reconocimiento rápido y saltos de
frecuencia para garantizar la robustez del enlace. Este sistema opera en la banda de frecuencia
de 2.4 GHz, libre para ISM (Industrial, Científica, Medica) más exactamente comenzando en
2.402 GHz y acabando en 2.4835 GHz. Con canales RF de f = 2402 + k MHz siendo k = 0.78.

_____________________________________________________________________________________
19/11/2010 4
El espacio entre canales es de 1 MHz, no obstante es necesario tener unos márgenes de
protección respecto al ancho de banda de trabajo, así pues, el límite superior de protección es
de 2 MHz y un límite inferior es de 3,5 MHz

La distancia nominal del enlace está comprendida entre 10 cm. y 10 m, pero se puede
aumentar a más de 100 m elevando la potencia de transmisión Otro aspecto importante es el
consumo cuyos valores en los estados más habituales son 300uA (máx.), 30uA (standby),
-50uA (hold/park).

Módulo de radio de Ericsson Microelectronics

- Características de la modulación

La modulación que emplea Bluetooth es GFSK (Gaussian Frequency Shift Keying) con un
producto ancho de banda por tiempo BT=0.5. Este tipo de modulación permite un bajo coste. El
índice de modulación debe estar entre 0.28 y 0.35. Un uno binario se representa por una
desviación positiva de frecuencia y un cero binario como una desviación negativa. La
desviación mínima no ha de ser menor de 115 KHz.

- Características del dispositivo receptor

El aspecto más importante en el dispositivo receptor es el nivel de sensibilidad. Para poder

medir una tasa de error de bit, el equipo receptor envía de vuelta la información decodificada.
Para una tasa de error o BER (Bit Error Rate) del 0.1% se define el nivel de sensibilidad de un
receptor Bluetooth mayor o igual a –70dBm.

2.2 Banda Base(BaseBand)

Bluetooth brinda una conexión punto-a-punto o conexión punto-a-multipunto. Dos o más

unidades compartiendo el mismo canal forman una piconet o picored. Cada piconet tiene una
secuencia de salto diferente y como elementos a destacar tenemos un maestro que puede
tener hasta siete esclavos activos, además pueden haber muchos más esclavos en estado
parked o aparcados, en realidad un número ilimitado de ellos. Estos esclavos no están activos
en el canal sin embargo están sincronizados con el maestro con el fin de asegurar una rápida
iniciación de comunicación. El maestro (Master) es el responsable de la sincronización entre los

_____________________________________________________________________________________
19/11/2010 5
dispositivos de la piconet, su reloj y saltos de frecuencia controlan al resto de dispositivos.
Además el maestro es quien, de manera predeterminada, lleva a cabo el procedimiento de
búsqueda y establecimiento de la conexión. Los esclavos simplemente se sincronizan y siguen
la secuencia de saltos determinada por el maestro. En la figura se puede observar una piconet
donde el PC actúa como maestro y los otros dispositivos estan conectados como esclavos.

No obstante los dispositivos esclavos pueden, además de activos o aparcados, estar en otros
dos estados más. Uno es el llamado estado programable de escucha o sniff donde el esclavo
escucha de forma reducida la piconet, este estado depende de la aplicación. El otro estado es
el llamado de retención o contención (hold) que puede ser iniciado por el maestro o solicitado
por el esclavo y se reactiva de forma instantánea en cuanto se abandona el modo la
transferencia de datos.

No obstante un dispositivo no tiene tan solo una función, es decir, ser sólo maestro o sólo
esclavo, sino que en ciertas ocasiones puede actuar en cualquiera de los dos roles tanto de
maestro como de esclavo.

La topología Bluetooth permite la interconexión de varias piconets formando una scatternet,

Aunque no existe sincronización entre piconets, un dispositivo puede pertenecer a varias de
ellas haciendo uso de la multiplexación por división del tiempo (TDD), aunque el dispositivo
solo esta activo en una piconet a la vez.

Dispositivo puede pertenecer a varias piconets

Scatternet

- Técnica TDD (Time Division Duplex)

_____________________________________________________________________________________
19/11/2010 6
El canal físico contiene 79 frecuencias de radio diferentes, las cuales son accedidas de acuerdo
a una secuencia de saltos aleatoria.El valor de saltos estándar es de 1600 saltos/s. El canal
está dividido en timeslots o slots (ranuras de tiempo), cada slot corresponde a una frecuencia
de salto y tiene una longitud de 625 us. Cada secuencia de salto en una piconet está
determinada por la dirección del maestro (48 bits) de la piconet. Todos los dispositivos
conectados a la piconet están sincronizados con el canal en salto y tiempo. En una transmisión,
cada paquete debe estar alineado con el inicio de un slot y puede tener una duración de hasta
cinco timeslots. Durante la transmisión de un paquete la frecuencia es fija. Para evitar fallos en
la transmisión (crosstalk), el maestro inicia enviando en los timeslots pares y los esclavos en
los timeslots impares.

Existen dos tipos de enlaces físicos entre maestros y esclavos:

Enlace SCO (Synchronous Connection-Oriented):

El enlace SCO es una conexión simétrica punto-a-punto con un

ancho de banda fijo entre el maestro y un esclavo específico (El
maestro soporta 3 conexiones SCO con el mismo o diferentes
esclavos).Para lograr la comunicación, el enlace SCO reserva slots
en intervalos regulares en la iniciación, por esto el enlace puede ser
considerado como una conexión de conmutación de circuitos. En
este tipo de enlace no es necesario asegurar la entrega y suele ser
utilizado para comunicaciones de voz.

Enlace ACL (Asynchronous Connection-Less):

El enlace ACL es una conexión simétrica o asimétrica punto-a-

multipunto entre el maestro y uno o más esclavos activos en la
piconet sin reserva de ancho de banda. Este enlace de
comunicación es un tipo de conexión de conmutación de paquetes.
Aquí, a diferencia del anterior, se necesita asegurar la entrega de
datos y es utilizado para transferencia de datos sin requerimientos
temporales.

Ejemplo de tráfico SCO y ACL en una piconet:

_____________________________________________________________________________________
19/11/2010 7
- Formato y descripción general de los paquetes Bluetooth

En Bluetooth todos los datos que se envían a través del canal son fragmentados y enviados en
paquetes. Además la información se encuentra protegida mediante códigos detectores y/o
correctores de errores. En cada ranura solo se puede enviar un paquete. El receptor los
recibirá y los procesará empezando por el bit menos significativo.

Los paquetes se pueden clasificar en diferentes tipos atendiendo al número de slots (ranuras)
que ocupan y dependiendo de si los enlaces son síncronos o asíncronos:

- Enlaces asíncronos: La tasa de transmisión máxima que se consigue se sitúa

alrededor de 723 kbps. El campo de datos es de longitud variable. Hay tres tipos de
paquetes según quepan en 1, 3 o 5 slots.

- Enlaces síncronos: El campo de datos de usuario es fijo. Este tipo de enlaces

soporta full-duplex con unas tasas de transmisión mucho menores que en el caso de
los enlaces asíncronos, alrededor de 64 kbps en los dos sentidos. Sólo hay paquetes
que caben en 1 slot.

Los paquetes que ocupan 3 o 5 slots, son denominados multislots. Estos no utilizan saltos de
frecuencia. Se envían por la misma frecuencia durante todos los slots que ocupe el paquete.
Una vez finalizada la transmisión del paquete se cambia la frecuencia.

Composición del paquete:

Código de acceso (72 bits):. Es usado para sincronización, identificación y compensación.

Todos los paquetes comunes que son enviados sobre el canal de la piconet están precedidos
del mismo código de acceso al canal. Existen tres tipos diferentes de código de acceso o
access code:

_____________________________________________________________________________________
19/11/2010 8
 Channel Access Code o código de acceso al canal (CAC): identifica una piconet. Se
incluye en los paquetes intercambiados en el canal de una piconet

Device Access Code o Código de acceso de dispositivo (DAC): utilizado para procesos
de señalización especiales.

Inquiry Access Code o Código de Acceso de Búsqueda (IAC): utilizado para procesos
de búsqueda de dispositivos. Se llamará IAC general cuando se quiere descubrir a
otras unidades Bluetooth dentro del rango, o IAC dedicado cuando se desea descubrir
unidades de un tipo específico

Cabecera (54 bits): Contiene información del control de enlace con 6 campos:

Dirección o AM_ADDR: dirección temporal de 3 bits que se utiliza para distinguir los
dispositivos activos en una piconet, siendo la dirección 000 la dirección broadcast

Tipo: Define qué tipo de paquete es enviado y cuántos slots va a ocupar.

Flujo o Flow: El bit de control de flujo es usado para notificar al emisor cuándo el buffer
del receptor está lleno y que debe de dejar de transmitir, en ese caso el bit tendrá el
valor “0”.

ARQN: bit de reconocimiento de paquetes recibidos paquetes correcto o incorrecto

(ultimo paquete recibido). Si es un “1· es un ACK, y con un “0” un NAK.

SEQN: bit que se va invirtiendo para evitar retransmisiones en el receptor.

HEC Código de redundancia para comprobar errores en la transmisión.

Campo de datos o carga útil (hasta 2746 bits): Contiene el conjunto de datos que supone la
información a transmitir.

- Establecimiento de conexiones en Bluetooth

Para establecer nuevas conexiones se utilizan los procedimientos de acceso que son los de
búsqueda o paging y los de pregunta o inquiry. Si no se conoce nada sobre el dispositivo
remoto debe seguirse tanto el procedimiento inquiry como el de paging. Si se conocen algunos
detalles del dispositivo remoto sólo será necesario el procedimiento de paging.

Pregunta (Inquiry)

_____________________________________________________________________________________
19/11/2010 9
El procedimiento de “inquiry” permite a un dispositivo descubrir qué dispositivos están en su
zona de cobertura, determinando sus direcciones y el reloj de todos aquellos que respondan
al mensaje de búsqueda. Entonces, si el dispositivo emisor lo desea, establecerá una conexión
con alguno de los dispositivos descubiertos.

El mensaje de búsqueda no contiene ningún tipo de información sobre la fuente emisora del
mensaje, no obstante, puede indicar qué clase de dispositivos deberían responder. Para poder
conseguir esto existe un código de acceso de pregunta (GIAC) para preguntar por algún tipo de
dispositivo en especial, y una serie de códigos de acceso de pregunta dedicados (DIAC) para
tipos de dispositivos.

Así pues un dispositivo que quiera conectar con otro dispositivo en concreto continuamente
transmite el mensaje GIAC en diferentes frecuencias de salto. La secuencia de saltos está
determinada en el parte menos significativa de la dirección del GIAC, incluso cuando se utilizan
los DIAC. Un dispositivo que quiera ser descubierto, cada cierto tiempo entrará en un estado de
escaneo de preguntas llamado “inquiry scan” para atender a estos mensajes.

Una vez atendida la pregunta, el dispositivo destino, entrará en el modo”inquiry response” y

transmite un mensaje de respuesta que consiste en una paquete FHS (Frequency Hop
Synchronization), que tiene los parámetros del dispositivo. El maestro escucha las diferentes
respuestas, pero nada más leer una respuesta continua escaneando por diferentes respuestas.
En el caso de que exista contienda entre diferentes dispositivos, éstos, al no recibir respuesta
del maestro, esperan un número aleatorio de slots y se mantienen a la escucha de un nuevo
mensaje de pregunta del maestro.

Búsqueda (Paging)

El procedimiento de “paging” sigue al de “inquiry”. El procedimiento de paging pregunta por la

dirección de un dispositivo Bluetooth con el que queremos establecer la conexión. Este
identificador del dispositivo se obtenido de las siguientes tres formas:

1) Obtenida en la respuesta de un “inquiry”.

2) Introducida por el usuario.
3) Preprogramada por el fabricante del dispositivo.

Entonces el dispositivo maestro, que se encuentra en el estado page, inicia la transmisión

transmite el código de acceso o DAC (Device Access Code) al dispositivo que deseamos que
sea esclavo de forma repetida en diferentes canales de salto. Debido a que los relojes del
maestro y del esclavo no están sincronizados, el maestro no sabe exactamente cuando y en
qué frecuencia de salto se activará el esclavo por lo tanto maestro se quedará a la escucha
entre los diversos intervalos de transmisión hasta recibir respuesta del esclavo.

Después de haber recibido su propio código de acceso de dispositivo, el esclavo transmite un

mensaje de respuesta, simplemente indicará su código de acceso, y se queda activado en
espera de la llegada del paquete FHS (Frequency Hop Synchronization), Cuando el maestro ha
recibido este paquete ACK, envía un paquete de control con información acerca de su reloj,
dirección, clase de dispositivo, etc. El maestro se queda a la espera de una respuesta.

_____________________________________________________________________________________
19/11/2010 10
El esclavo se activa y responde con un nuevo mensaje ACK donde envía de nuevo su dirección
y a la vez cambia el código de acceso del canal y su reloj, tomando los del maestro incluido en
el paquete FHS. El esclavo establece la conexión usando para ello el reloj y la BD_ADDR del
maestro para determinar la secuencia de salto del canal y el código de acceso.

Si el maestro no obtiene esta respuesta en un determinado tiempo, él reenvía el paquete de

control. Si el esclavo excede el tiempo de espera, entonces vuelve al estado de page scan. Si
es el maestro quien lo excede, entonces vuelve al estado de page e informa a las capas
superiores. Con el ACK, el maestro entra en modo de conexión establecida y usa su BD_ADDR
para cambiar a una nueva secuencia

- Seguridad

La seguridad de Bluetooth es un tema importante y a la vez pendiente en la mayoría de los

dispositivos. Un gran parte de los productos en el mercado sufren la interceptación de
comunicaciones. No obstante las grandes compañías del sector de las telecomunicaciones y
productoras de este tipo de equipos están tomando medidas tanto a nivel de hardware como
software.

Bluetooth debe tener en cuenta dos aspectos fundamentales para ofrecer una conexión segura.
En primer lugar la confianza con el dispositivo con el que se va a conectar. Un dispositivo podrá
acceder a los distintos servicios residentes en otro dependiendo de su grado de confianza con
mayor sea esta, mayor será el acceso a los servicios, en cambio una medida baja de confianza
hará que el dispositivo poco confiable sólo pueda acceder a los llamados servicios básicos o
servicios en abierto del dispositivo receptor.

El segundo aspecto es a que nivel de protocolos se desea que se produzca la seguridad. Si se

desea que la seguridad se base en las capas bajas de la pila de protocolos y el procedimiento
de seguridad se inicie antes de que el canal haya sido establecido entonces se tarta de
seguridad a nivel de enlace. Si en cambio la seguridad es brindada por las capas altas de la
pila y se inicia después de que el canal se haya establecido será seguridad a nivel servicio.

Actualmente han aparecido dos fenómenos que han comprometido la seguridad de los
dispositivos más en concreto de los móviles Bluetooth:

Bluehacking

Es te sistema se basa principalmente en enviar mensajes con texto, a cualquier equipo

Bluetooth sin permiso ni pairing con el mismo. La consecuencia es la aparición de lo que ya se
ha denominado Blue-Spam, tan odiado ya en el correo de los PCs. Su funcionamiento es el
siguiente:

1) Este paso consiste en la creación de un contacto ficticio en la agenda del teléfono.

2) Se inicia el terminal móvil en busca de nuevos móviles en el área próxima.
3) Una vez localizado se le envía el contacto ficticio.

La causa de esta vulnerabilidad es que los terminales Bluetooth se encuentran siempre en

disposición de descubrir y iniciar una conexión con cualquier dispositivo que desee conectarse.
La solución es apagar la conectividad Bluetooth cuando no se utilice y tan sólo conectarla
cuando se desea conectar con un dispositivo conocido.

Este caso el efecto producido por este hacking es mínimo pero si se piensa en el nivel actual
de spam en el correo electrónico puede ser un aspecto de seguridad a tener en cuenta.

_____________________________________________________________________________________
19/11/2010 11
Bluesnarfing

El Bluesnarf es algo más complicado de realizar y sus consecuencias no tan inocentes, y que
ha provocado que empresas como Nokia deba haber realizado modificaciones en sus diseños
de software. El problema es el mismo que en el anterior caso, la vulnerabilidad de que el
teléfono se encuentre en modo “visible”, es decir disponible para interactuar con otros
dispositivos. En este caso ya no se mandan “inocentes” mensajes sino que se actúa
directamente a la funcionalidad de los equipos atacados, robando datos de la agenda, fechas y
citas del calendario, y en algunos caso se inicia la navegación por Internet o la clonación del
teléfono con los perjuicios económicos que lleva esta práctica sobre el terminal afectado.

- Corrección de errores

En la comunicación Bluetooth existen varios esquemas diferentes de corrección de errores:

- FEC tasa 1/3: donde cada bit, en la cabecera, se repite tres veces.

- FEC tasa 1/2: donde en la carga útil se usa un esquema de código de hamming. Los
bits de información son agrupados en secuencias de 10 bits, éstos son enviados como 16 bits
y el algoritmo corrige de un bit y detecta los errores de dos bits.

-Chequeo de la redundancia cíclica (CRC): se usa para detectar errores en la cabecera. La

suma de comprobación CRC está contenida en el campo HEC de la cabecera del paquete. Los
chequeos de redundancia cíclica también se aplican sobre la carga útil en la mayoría de
paquetes.

2.3 LMP: Link Manager Protocol

El siguiente protocolo específico se encarga de la gestión del enlace entre dispositivos

Bluetooth, de la seguridad, del control de paquetes, potencia, calidad del servicio y control de la
piconet (conmutación maestro esclavo).

Formato de LMP

El mensaje LMP se transmite siempre en tan sólo un slot y posee mayor prioridad que los datos
del usuario y no se propaga a capas superiores. Posee tres campos importantes:

1. El identificador de transacción: Nos indica si la PDU que se gestiona pertenece al

maestro o al esclavo.
2. Código de operación: Es un código de 7 bits que nos permite identificar los diferentes
tipos de PDUs.
3. Campo Content: contendrá información específica de la aplicación.

El LMP especifica un conjunto de PDUs obligatorias y opcionales. La transmisión y la recepción

de PDUs obligatorias deben ser necesariamente soportada. Con respecto a las PDUs
opcionales no tienen porque estar implementadas. No obstante es recomendable que se pueda
reconocer este tipo de PDUs.

Establecimiento de conexión

_____________________________________________________________________________________
19/11/2010 12
Tras haberse completado el procedimiento de búsqueda o Paging, ya se está listo para
establecer una conexión LMP. En primer lugar el dispositivo emisor envía la primitiva
LMP_host_connection_req. El dispositivo receptor recibe el mensaje y obtiene información
sobre la conexión que se va a abrir. Este dispositivo remoto puede aceptar (LMP_accepted) o
rechazar (LMP_not_accepted) esa petición de conexión. Una vez establecidas todas las
configuraciones necesarias, los dos dispositivos se mandan LMP_setup_complete. Después de
esto, se procederá a la transmisión de los paquetes de los diferentes canales lógicos que
emplea LMP.

Procedimientos LMP

LMP debe gestionar un gran número de procedimientos que permitan implementar toda su
funcionalidad, esto hace que cada procedimiento tenga sus propias PDUs que se deben
intercambiar entre las dos entidades de comunicación. Vamos a hacer una breve referencia a
los procedimientos LMP:

1. Autenticación
2. Pairing
3. Cambio de la clave de enlace
4. Cambio de la clave de enlace actual
5. Encriptado
6. Petición del offset del reloj
7. Información del offset de slot
8. Petición de información de temporización
9. Información de la versión LMP
10. Información de las características soportadas
11. Conmutación del papel esclavo-maestro
12. Petición de nombre
13. Desconexión
14. Control de potencia
15. Petición modo hold
16. Petición modo sniff
17. Petición modo park
18. Petición calidad de servicio
19. Establecimiento enlaces SCO
20. Control de paquetes multi-slot
21. Supervisión del enlace
22 Repuesta General.

2.4 L2CAP: Logical Link Control and adaption Protocolo

_____________________________________________________________________________________
19/11/2010 13
L2CAP es un protocolo que se encuentra por encima del anterior protocolo (LMP), se encarga
de adaptar los protocolos superiores al protocolo de banda base. Sus tres principales funciones
son:

1) Multiplexación de protocolos de alto nivel

2) Segmentación y reensamblado de paquetes largos (hasta 64 kbytes)
3) Descubrimiento de dispositivos y calidad de servicio

Para cumplir estas funciones la arquitectura L2CAP debe cumplir ciertos requisitos:

a) L2CAP ofrece un servicio orientado a conexión donde el identificador del canal es utilizado
en cada conexión, asumiendo que este canal es full-duplex y fiable, además se tiene que
especificación del flujo de QoS asignada a cada dirección del canal.

b) L2CAP esta basados en datagramas y no en flujos continuos. Se debe notar que en L2CAP,
se conservan los límites del paquete, así como que no se realiza retransmisión ni control de
flujo.

Formato del paquetes L2CAP

L2CAP sigue un modelo de comunicación basado en canales. Un canal representa un flujo de

datos entre entidades L2CAP en dispositivos remotos. Los canales pueden o no ser orientados
a la conexión. Como se pude observar los paquetes tienen tres campos:

• Longitud: Especifica la longitud del campo de datos en bytes.

• CID: Como L2CAP esta basado en el concepto de canales necesitamos identificar a cada
uno de ellos. Por ello utilizamos el CID o identificador de canal que nos permite identificar
el canal a el cual el paquete será entregado. Un identificador de un canal tiene un ámbito
local, por lo que un dispositivo pude asignar identificadores de canal de forma
independiente de otros dispositivos, a excepción de que necesite usar identificadores
reservados. El mismo CID no puede utilizarse simultáneamente para identificar múltiples
canales simultáneos entre un dispositivo local y uno remoto.

• Datos: Contendrá los datos recibidos y enviados a la capa de red, además señalar que el
la MTU limitará el tamaño de este campo de carga útil.

Establecimiento de canales en L2CAP

_____________________________________________________________________________________
19/11/2010 14
Multiplexación de protocolos

L2CAP debe soportar multiplexación de protocolos, debido a que el protocolo debanda base es
incapaz de distinguir a los protocolos de orden superior.

- Fragmentación y reensamblaje

Los paquetes definidos en la banda base tienen cierta limitación de tamaño. Si se usa este
tamaño de paquete con los protocolo de orden superior, resultaría un uso ineficiente del ancho

_____________________________________________________________________________________
19/11/2010 15
de banda, debido a que los protocolos superiores están diseñados para trabajar con paquetes
de tamaño mucho mayor.

Por lo que L2CAP debe actuar de intermediario entre la banda base y el resto de protocolos
superiores. Cuando L2CAP recibe múltiples paquetes que tienen como origen la banda base
L2CAP reensambla esta multitud de paquetes en uno sólo y de mayor tamaño llamado
paquete L2CAP utilizando una comprobación de integridad durante el ensamblado. En el caso
de que L2CAP reciba paquetes de tamaño más grande que provienen de capas superiores
L2CAP debe fragmentar éstos de manera que no excedan el tamaño permitido de la banda
base. A continuación veamos un ejemplo de ensamblaje y fragmentación:

- Calidad de servicio

La calidad de servicio permite el control del buen uso de recursos existentes por parte de los
canales. L2CAP permite el intercambio de información teniendo en cuenta la calidad de servicio
(QoS) esperada entre dos unidades Bluetooth y así monitorizar que no se violen los contratos
de calidad de servicio existentes.

Podemos tener dos tipos de calidad de servicio o el de Best Effort (el mejor esfuerzo) o el
llamado guaranteed. Las opciones configurables de calidad servicio son el ratio de tokens,
latencia, tamaño del pozal, los picos de ancho de banda de la aplicación o las variaciones de
retraso

2.5 SDP: Service Discovery Protocol

SDP proporciona un mecanismo que permite a las aplicaciones descubrir cuales son los
servicios disponibles en su entorno y determinar las propiedades específicas de éstos. Los
servicios disponibles cambian continuamente debido al dinamismo existente en el entorno, por
lo que la búsqueda de servicios en Bluetooth difiere de la búsqueda de servicios en un red fija
tradicional.

_____________________________________________________________________________________
19/11/2010 16
SDP debe proporcionar las siguientes funcionalidades en su versión 1.0:

• SDP debe permitir la búsqueda de servicios basados en atributos específicos

• SDP debe permitir que los servicios sean descubiertos basándose en la clase de servicio.
• SDP debe permitir averiguar las características de un servicio sin tener conocimiento a
priori de dicho servicio..
• SDP debe proporcionar medios para descubrir nuevos servicios (proximidad de un nuevo
dispositivo, arranque de una aplicación) así como para indicar la no disponibilidad de
servicios inicialmente visibles.
• SDP debe permitir el almacenar información sobre servicios de forma temporal para
mejorar la eficiencia del protocolo.
• SDP debe descubrir la información de los servicios de forma incrmental para evitar las
transferencias excesivas de información sobre servicios no vyan a utilizarse.
• SDP proporcionar complejidad adecuada para ser utilizado en dispositivos conj
prestaciones limitadas.

No obstante SDP debe proporcionar los siguientes servicios en las sucesivas versiones:

• No se proporciona acceso a los servicios, sólo acceso a la información sobre los servicios.
• No aparece negociación de parámetros de servicio.
• No se proporcionan mecanismos para la tarificación por el uso de los servicios.
• No se proporciona al cliente la capacidad de controlar o cambiar la operación de un
servicio.
• No se proporciona notificación de eventos para los casos en que los servicios no estén
disponibles o cuando se modifican los atributos de los servicios.
• SDP 1.0 no define un API (Application Programming Interface).
• No se soportan agentes que realicen funciones tales como darse de alta en un servicio.

- Registro de un servicio

El registro de servicio está formado por un conjunto de atributos que describen un servicio
determinado. Existen dos tipos de atributos, los llamados atributos universales que son
comunes a todos los tipos de servicio y los llamados atributos específicos que tal como indica
el nombre son específicos a una clase de servicio.

Cada atributo de un registro de servicio consta de dos partes, un identificador de propiedad y

un valor de propiedad. El identificador de propiedad es un único número de 16 bits que
distingue cada propiedad de servicio de otro dentro de un registro. El valor de propiedad es un
campo variable que contiene la información.

Un servidor SDP estructura los servicios en registros y mantiene una lista de apuntadores
(Service Record Handle) a cada uno de ellos.

- Funcionamiento de SDP

_____________________________________________________________________________________
19/11/2010 17
Tal como se ve en la figura, la comunicación SDP implica un servidor SDP y un cliente SDP. Se
pueden dar dos escenarios posibles para que el cliente realice una petición de un servicio.

1) El cliente busca un servicio en un dispositivo en particular al cual el usuario se ha

conectado “conscientemente”.
2) El cliente realizando conexiones “inconscientemente” con los dispositivos vecinos.

Vistos estos dos escenarios se pueden definir varios mensajes de petición /repuesta por parte
tanto del cliente como del servidor:

Mensajes de petición del cliente:

a) Petición de búsqueda de servicio: el cliente genera una petición para localizar los
registros de servicio que concuerden con un patrón de búsqueda dado como
parámetro.

b) Petición de propiedad de servicio: Una vez el cliente ya ha recibido los servicios

deseados, puede obtener mayor información de unote ellos dando como parámetros el
registro de servicio y la lista de propiedades deseadas.

c) Petición de búsqueda y propiedad de servicio: se suministran un patrón de servicio con

servicios deseados y una lista de propiedades deseadas que concuerden con la
búsqueda.

Mensajes de respuesta del servidor:

a) Repuesta a búsqueda de servicio: se genera por el servidor después de recibir uan

petición de búsqueda de servicio válida.

b) Repuesta a propiedad de servicio: el SDP genera una respuesta a una petición de

propiedad de servicio. Ésta contiene una lista de propiedades de registro requerido.

c) Repuesta de búsqueda y propiedad de servicio: como resultado se puede obtener una

lista de servicios que concuerden con un patrón dado y las propiedades deseadas de
estos servicios.

Algunas apreciaciones sobre el funcionamiento es que un dispositivo Bluetooth puede actuar

tanto cliente SDP como servidor SDP. Otro aspecto importante es que cuando el servidor deja
de estar en la zona de acción del cliente, no realiza ninguna notificación vía SDP, por lo que el
cliente en este caso deducirá que no está porque ya no recibe las respuestas del servidor ante
sus continuas peticiones.

2.5 RFCOMM

El protocolo RFCOMM permite emular el funcionamiento de los puertos serie sobre el protocolo
L2CAP .Se basa en el estándar ETSI TS 07.10, tomando de éste un subconjunto con las partes
más relevantes y realizando algunas adaptaciones.

_____________________________________________________________________________________
19/11/2010 18
RFCOMM permite emular los nueve circuitos de la norma RS-232(ETIATIA-232.E).Soporta
hasta 60 conexiones simultáneas entre dos dispositivos Bluetooth.

Ante una configuración RFCOMM nos encontramos básicamente con dos tipos de dispositivos:

• Tipo 1: Se trata de dispositivos terminales de comunicación, como los ordenadores las

impresoras.

• Tipo 2: Son aquellos que forman parte de un segmento de comunicación, como por
ejemplo, los módems.

RFCOMM no hace distinción entre ambos tipos, pero el acomodarse a ellos tiene sus
consecuencias en el protocolo. Por lo tanto, la transferencia de información entre dos entidades
RFCOMM se define tanto para los dispositivos tipo 1 y 2. Una parte de la información sólo se
necesitará para el segundo tipo, mientras que otra se pretende que sea usada por ambos.
Debido a que un dispositivo no es consciente del tipo del otro dispositivo en el camino de
comunicación, cada uno debe pasar toda la información disponible especificada por el
protocolo.

- Emulación de múltiples puertos serie

Entre dos dispositivos

Dos dispositivos Bluetooth usando RFCOMM en su comunicación pueden abrir múltiples

puertos serie. RFCOMM soporta hasta 60 puertos emulados abiertos, aunque esto es
fuertemente dependiente de la implementación específica.

El identificador de Conexión de Datos de Enlace (DLCI) será el encargado de identificar la

conexión entre una aplicación cliente y una servidora. El DLCI se representa con 6 bits pero su
rango útil es [2,61], debido a que en TS 07.10 DLCI = 0 es el canal de control dedicado, DLCI
=1 no es útil y DLCI = 62-63 se encuentran reservados. El DLCI es único para una sesión
RFCOMM establecida entre dos dispositivos. Para tener en cuenta que tanto la aplicación
cliente como la servidora pueden residir en ambos lados de una sesión RFCOMM, con clientes
en cualquier extremo realizando conexiones independientes, el valor del DLCI se divide entre
los dos dispositivos que se comunican.

Con múltiples dispositivos Bluetooth

_____________________________________________________________________________________
19/11/2010 19
Si un dispositivo Bluetooth soporta emulación de múltiples puertos serie y las conexiones
realizadas son con puntos terminales en diferentes dispositivos Bluetooth, entonces la entidad
que implementa RFCOMM debe ser capaz de correr múltiples sesiones TS 07.10
multiplexadas, cada una con su propio identificador de canal L2CAP.

Esta capacidad de multiplexación es un elemento opcional a la hora de implementar RFCOMM,

según la Especificación de Bluetooth.

3. Perfiles Bluetooth
Son un conjunto de mensajes y procedimientos de la especificación Bluetooth para una
situación de uso concreta del equipo. Los perfiles se encuentran asociados con las
aplicaciones. Los perfiles permiten que no sea necesario implementar en un determinado
dispositivo toda la pila de protocolos, sólo la parte que va a necesitar. Si el dispositivo tiene
muy poca memoria y/o capacidad de procesamiento y implementamos en él toda la pila de
protocolos con la carga de proceso y espacio que ello implica puede que provoquemos que el
dispositivo sea totalmente ineficiente para la comunicación, por ejemplo ratones, auriculares.

Además de la ventaja anterior el concepto de perfil se utiliza para asegurar la interoperatibilidad

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.
Cuando dos dispositivos deben ínter operar, es decir, comunicarse entre ellos, deben tener un
perfil compartido. Si por ejemplo quiere transferir un archivo desde un ordenador preparado
para Bluetooth a otro, ambos ordenadores deben admitir el perfil de transferencia de archivos.

Todos los dispositivos Bluetooth deben soportar el perfil de acceso genérico (Generic
Access Profile) como mínimo. Este perfil en particular define el descubrimiento o hallazgo de
dispositivos, procedimientos de conexión y procedimientos para varios niveles de seguridad.
También se describen algunos requerimientos de interfaz al usuario. Otro perfil universal,
aunque no es requerido, es el perfil de acceso a descubrimiento de servicios (Service
Discovery Access Profile), el cual define los protocolos y parámetros asociados requeridos para
acceder a los perfiles. Un número de perfiles han sido definidos incluyendo TCS, RFCOMM y
OBEX. Algunos de estos requieren la implementación de otros, y todos ellos requieren la
implementación de perfiles genéricos.

_____________________________________________________________________________________
19/11/2010 20
3.1 Perfil de acceso genérico. (GAP).

Este perfil define los procedimientos generales para el descubrimiento y establecimiento de

conexión entre dispositivos Bluetooth. El GAP maneja el descubrimiento y
establecimiento entre unidades que no están conectadas y asegura que cualquier par de
unidades Bluetooth, sin importar su fabricante o aplicación, puedan intercambiar
información a través de Bluetooth para descubrir qué tipo de aplicaciones soportan las
unidades. También define aspectos relacionados con los niveles de seguridad

3.2 Perfil de Aplicación del Descubrimiento de Servicio (SDAP).

Este define las características y los procedimientos que un dispositivo Bluetooth usa para
descubrir los servicios registrados en otros dispositivos de Bluetooth y para recuperar cualquier
información disponible deseada pertinente a estos servicios. El SDAP es dependiente del GAP.

3.3 Perfil de Puerto Serie. (SPP)

El Serial Port Profile (SPP) define los requerimientos específicos para posibilitar la emulación
del puerto serie en los dispositivos Bluetooth usando el protocolo RFCOMM entre parejas de
dispositivos.

3.4 Perfil genérico de intercambio de objetos. (GOEP)

Este perfil define como los dispositivos Bluetooth deben soportar los modelos de intercambio de
objetos, incluyendo el perfil de transferencia de archivos, el de carga de objetos y el de
sincronización. Los dispositivos más comunes que usan este perfil son las agendas
electrónicas, PDAs y teléfonos móviles.

3.5 Perfil de Teléfono Inalámbrico.

Este perfil define cómo un teléfono móvil puede ser usado para acceder a un servicio de
telefonía de red fija a través de una estación base. Es usado para telefonía inalámbrica de
hogares u oficinas pequeñas. El perfil incluye llamadas a través de una estación base,
haciendo llamadas de intercomunicación directa entre dos terminales y accediendo
adicionalmente a redes externas. Es usado por dispositivos que implementan el llamado
“teléfono 3-en-1”.

_____________________________________________________________________________________
19/11/2010 21
3.6 Perfil de Intercomunicación.(IP)

El Intercom Profile (IP) define los requerimientos necesarios por parte de los dispositivos
Bluetooth para soportar comunicaciones entre parejas de teléfonos con soporte Bluetooth.
Estos requerimientos son expresados en términos de servicios para el usuario final.
Popularmente, este perfil se conoce con el nombre de "Walkie-Talkie".

3.7 Perfil de acceso telefónico a redeso perfil de networking de marcación (DNP)

Este perfil define los protocolos y procedimientos que deben ser usados por dispositivos que
implementen el uso del modelo llamado Puente Internet. Este perfil es aplicado cuando un
teléfono o modem es usado como un modem inalámbrico.

3.8 Perfil de FAX.(FP)

El perfil Fax Profile define los requerimientos necesarios para que los dispositivos Bluetooth
adquieran soporte de transferencia de Fax. Permitirá que teléfonos Bluetooth puedan enviar y
recibir faxes.

3.9 Perfil de Manos Libres o de casco telefónico.

Este perfil define los requerimientos, para dispositivos Bluetooth, necesarios para soportar el
uso de manos libres. En este caso el dispositivo puede ser usado como unidad de audio
inalámbrico de entrada/salida. El perfil soporta comunicación segura y no segura.

3.10 Perfil de Acceso a LAN.(LAP)

El perfil de acceso a LAN define cómo pueden acceder a los servicios de una LAN mediante el
protocolo PPP, los dispositivos que utilizan la tecnología inalámbrica Bluetooth. De esta
manera pueden crearse puntos de acceso inalámbricos.

3.11 Perfil de Transferencia de Archivos.

Este ofrece la capacidad de transferir un archivo de un dispositivo Bluetooth a otro, inclusive

permite navegar por el contenido de las carpetas del dispositivo.

3.12 Perfil de Transferencia de Objetos

Este ofrece la capacidad de transferir un objeto de un dispositivo Bluetooth a otro

3.13 Perfil de Sincronización.

Este perfil provee sincronización dispositivo a dispositivo de programas de gestión de

información personal, como agendas telefónicas, calendario, mensajes y notas de información.

4. Aplicaciones y productos Bluetooth

“Imagínese que pudiera liberarse de las limitaciones y del desorden de los cables“, Decían los
vendedores en las ferias de tecnología allá por el año 2000. Pero no se imaginaban lo cierta
que iba a ser esa frase pocos años después.

La tecnología Bluetooth comenzó con unos inciertos balbuceos, pese que grandes empresas
como Ericsson, Intel o Motorota estaban detrás de esta potente forma de comunicarse y que a
priori era una tecnología revolucionaria.

_____________________________________________________________________________________
19/11/2010 22
Este mal inicio tenía varias razones de peso:

• Insuficiente velocidad y alcance o cobertura.

• Alto consumo de los circuitos que lo implementan.
• Demasiadas interferencias en la banda de 2,4 GHz.
• La necesidad de que el ingeniero que integra esta tecnología en un producto debe
tener experiencia en diseño de equipos de radiofrecuencia.
• Una estructura software compleja (stack) en vez un hardware sencillo.
• El coste es demasiado alto.

No obstante a finales del 2001 pese los problemas de seguridad, de compatibilidad y de

interferencias siguen presentes, la especificación Bluetooth 1.1 ha conseguido la mayoría de
edad como para ver, dentro de poco, multitud de dispositivos con esta tecnología en su interior.
En parte, esto es debido a que por fin van apareciendo soluciones Bluetooth en un único
circuito integrado, tal y como se esperaba desde hace tiempo. No obstante ahora se encuentra
ya no con obstáculo de tecnología sino un obstáculo económico, los prohibitivos precios de los
productos a principios de 2002 hacían que Bluetooth no fuera una realidad.

Todos estos problemas a fecha de hoy prácticamente han sido solucionados y la realidad
Bluetooth está más presente cada día y prueba de ello son los múltiples productos y a precio
razonable que existen hoy día. En esta sección se va a mostrar algunos de los productos
Bluetooth que están disponibles.

Telefonía

Sony T68i Sony P800

Sony P900 Sony 610

_____________________________________________________________________________________
19/11/2010 23
 N-Cage 6600

3650 7650

6310i 8910i

Impresoras

Impresora HP Deskjet Impresora HP Deskjet

995c 450cbi

Impresora Zebra QL320

_____________________________________________________________________________________
19/11/2010 24
Auriculares

Auricular Jabra Auricular Innovi

BT250 FreeSpeak BlueTrek G2

Auricular Bluetooth Auricular Sony

Logitech Ericsson HBH-200

Manos Libres

Manos libres Parrot Manos libres

DriveBlue Bluetooth de ECHO

Altavoz manos Sistema manos

libres Motorola libres Parrot
HF800 CK3000

PCs/Tablet/Mac

TabletPC Acer PC Portatil Acer

Travelmate C111Tci Ferrari M3000

_____________________________________________________________________________________
19/11/2010 25
 PC Portátil Fujitsu- HP Compaq Tablet
Siemens Amilo PC TC1100
D7830 2,8Ghz 256MB/30 GB TFT
XGA de 10,4

4. Bibliografía
• Documentos

- Redes de Área de Local. Tema 11.Bluetooth. Facultad de Informática

Profesor Juan Vte Capella
- Bluetooth: Conceptos Básicos y nuevas soluciones. Juan José. Ing
Telecomunicaciones.
- Bluetooth: Dominique Chomienne & Michel Eftimakis. NewLogic
- Bluetooth. Ramón Ferrus. Universidad Politécnica de Cataluña.
- Tecnología Bluetooth, Nathan J. Muller Primera edición en español 2002.
Serie de Telecomunicaciones. McGraw-Hill
- Bluetooth: Iván Enrique Morales Joaquín García Ramírez.
- Tecnología Inalámbrica Bluetooth. Ing Patricia Helena Fierro e Ing.
Bibiana Suárez Otero. Universidad Pontificia Bolivariana, Bucaramanga.2001
- Bluetooth Tutorial: Radio, Baseband, L2CAP and LMP Specifications.
Apurva Kumar. Research Staff Member. IBM India Research Lab.
- Bluetooth: Redes personales. Jaime Guerra del Olmo y María Miranda
García
- Tema 8.Redes personales inalámbricas. Comunicaciones Móviles.Dpto
Informática UCLM Albacete
- Módulos Bluetooth de Ericsson. Henrik Arfwedson y Rob Sneddon.
- Implementación de una red Inalámbrica Bluetooth. Oscar Dario
Rodríguez Calvachi e Ricardo Andrés Maya Coral.
- Bluetooth Specification Version 1.0.A.SIG
- Reporte sobre tecnología Bluetooth. Instituto Nacional de Astrofísica
Óptica y Electrónica. Iván Enrique Morales y Joaquín García Ramírez. 2003

_____________________________________________________________________________________
19/11/2010 26