Traducción 3

Reporte industrial
Bluetooth:
Tecnología para aplicaciones
inalámbricas de corto alcance
L
os dispositivos portátiles están volviéndose rápidamente una parte íntegra
de nuestras vidas diarias, y muchos guerreros del camino ya llevan un
teléfono celular, una computadora de mano, y una computadora portátil
con ellos. En la mayoría los casos, estos dispositivos no tienen interfaces de
datos compatibles o, si lo tienen, la interfaz requiere conexiones embarazosas de
cables y procedimientos de configuración. Una solución obvia es librarse de los
cables y usar enlaces inalámbricos de corto alcance para facilitar la conectividad en
demanda entre los dispositivos. Una solución ideal y también barata, sería,
habilitando las aplicaciones compulsivas, y que los vendedores del dispositivo las
adopten universalmente.
En 1998, cinco grandes compañías (Ericsson, Nokia, IBM, Toshiba, e Intel)
formaron un grupo para crear una tecnología libre de licencia para conectividad
universal inalámbrica en el mercado portátil. El resultado es Bluetooth, una
tecnología nombrada después así, en memoria de un rey del siglo X que puso tribus
guerreras Vikingas bajo una regla común. Las especificaciones de Bluetooth, 1,2 de
Bluetooth actualmente en versión 1.1, definen una radio frecuencia (RF) como
interfaz de comunicación inalámbrica, un set asociado de protocolos de
comunicación y perfiles de uso.
La velocidad de enlace, el rango de comunicación, y el nivel de potencia de
transmisión para Bluetooth fueron escogidos para soportar bajos costos, potenciaeficaz, un solo chip, para aplicaciones de la tecnología actual. De hecho, Bluetooth
es el primer esfuerzo de hacer un solo chip de radio que pueda operar en 2.4-GHz
ISM (industrial, científico, y médico) de la banda de RF. Mientras la mayoría de las
más recientes soluciones de Bluetooth son de chip dual, los vendedores han
anunciado recientemente las versiones de un solo chip. En esta apreciación global
de la tecnología, yo primero describiré las capas más bajas del stack de protocolos
de Bluetooth. Yo también describiré brevemente su protocolo de descubrimiento
de servicio y, finalmente, cómo las capas del stack protocolos encajan juntas desde
el punto de vista de una aplicación.
Especificaciones de Bluetooth
Las especificaciones de Bluetooth 1.1 fueron anunciadas en febrero de 2001. La
especificación consiste en dos partes: de core y perfiles.
Bluetooth
Especificaciones de core
Las especificaciones de core definen todas las capas del stack 1 de protocolos de
Bluetooth. Como se muestra en la Figura 1, el stack de Bluetooth difiere del
modelo clásico de siete-capas que conecta una red de computadoras en algunas
maneras. Estas diferencias son principalmente soportar la conectividad ad hoc
entre los nodos participantes, mientras ahorra potencia y adapta dispositivos que
carecen de recursos para soportar todas las capas del stack clásico de una red de
computadoras.
Radio es la capa más baja. La especificación de este interfaz define las
características de la capa radio inicio-fin, bandas de frecuencia, arreglos de canal,
niveles de potencia de transmisión permisibles, y nivel de sensibilidad del receptor.
La siguiente capa es baseband, la cual está conformada por la capa física (PHY) y el
control de acceso al medio (MAC) procesado. Esto incluye las tareas como el
descubrimiento del dispositivo, establecimiento del enlace, y la comunicación
síncrona y asíncrona entre pares. Los pares de Bluetooth deben intercambiar
algunos mensajes de control con el propósito de configurar y manejar las
conexiones de la capa baseband. Estas definiciones del mensaje son parte del
protocolo de manejo de enlace (LMP). La entidad funcional responsable de llevar a
cabo el proceso asociado con LMP se llama Link Manager.
Bluetooth es único ofreciendo RF de inicio-fin procesamiento integrado con
el módulo de baseband. La integración del On-chip baja el costo del interfaz de la
red,
Figura 1 La arquitectura de protocolos Bluetooth y el chip. El diseño soporta la
integración de un radio analógico inicio-fin, elementos de procesamiento de
señales, y el controlador baseband en un solo chip.
y su pequeño tamaño hace fácil embeber los chips Bluetooth en dispositivos
como: teléfonos celulares y PDAs. Un chip de Bluetooth puede ser conectado a su
procesador host usando USB, UART, o las interfaces de la tarjeta del PC.
Reporte industrial
La especificación del interfaz controladora del host (HCI) define un método
interfaz-independiente de comunicarse con el chip Bluetooth. El stack del software
en el procesador del host se comunica con el hardware de Bluetooth usando
comandos HCI. Puesto que ningún conocimiento hardware-específico es
necesitado, el stack de software de Bluetooth puede ser fácilmente puesto de un
chip Bluetooth a otro. La capa HCI es parte del stack de Bluetooth, pero esta no
constituye una capa de comunicación peer-to-peer puesto que el comando HCI y
mensajes de contestación no fluyen sobre el enlace aéreo.
La especificación del control de enlace lógico y protocolo de adaptación
(L2CAP) puede verse como la capa de enlace de Bluetooth. Usualmente, L2CAP y
las capas sobre esta, están implementadas en software. L2CAP entrega los paquetes
recibidos desde las capas superiores al otro lado del enlace. Los dispositivos de
Bluetooth pueden establecer una conexión L2CAP tan pronto como ellos estén en
el rango de otros dispositivos. Un dispositivo cliente necesita descubrir entonces
los servicios proporcionados por el dispositivo servidor.
El protocolo de descubrimiento de servicio (SDP) define los medios por los
que el dispositivo cliente puede descubrir los servicios así como sus atributos. El
diseño de SDP se ha perfeccionado para Bluetooth. Sólo define los mecanismos de
descubrimiento; los métodos para acceder a esos servicios están fuera de su alcance.
La especificación de RFCOMM define un método de emulación de conexión
de cable RS-232 arriba del enlace aéreo de Bluetooth. RFCOMM apoya el legado
de aplicaciones que usan el puerto COM para comunicarse con el host par. Por
ejemplo, protocolos punto-a-punto (PPP) que esperan una interfaz de línea serial
de la capa más baja. Puesto que PPP proporciona un interfaz orientado a paquete a
las capas más altas, toda la red basada en paquete y protocolos de transporte,
incluyendo, TCP/IP, puede apoyarse sobre PPP. Métodos más eficaces para
ejecutar IP sobre Bluetooth están actualmente bajo desarrollo.
Especificaciones del perfil
Los vendedores pueden usar los servicios ofrecidos por el stack de Bluetooth para
crear una variedad de aplicaciones.
Porque la interoperabilidad es crucial para el funcionamiento de Bluetooth, el SIG
de Bluetooth ha definido especificaciones de perfil para apoyar esto. 2 Las
especificaciones actuales incluyen 13 perfiles listados en la tabla1 (próxima página).
Los perfiles especifican controlador y stack de parámetros escogidos así
como los rasgos y procedimientos requeridos para el trabajo interno entre los
dispositivos Bluetooth .Todas las implementaciones del vendedor de estos perfiles
se espera que sean interoperables. La autoridad de certificación de Bluetooth usa
los perfiles para probar y certificar la complacencia, y uso de concesiones del
logotipo de Bluetooth
Bluetooth
sólo a productos que conforman los métodos y procedimientos definidos en los
perfiles.
Radio Inicio Fin.
La banda ISM de 2.4-GHz en que Bluetooth opera está globalmente disponible
para el uso sin licencia. Europa y los Estados Unidos asignan 83.5 MHz a esta
banda, pero España, Francia, y Japón asignan menos. Acomodar estas diferencias,
79 canales espaciados 1 MHz aparte se definen para Europa y EE.UU., y 23 canales
de RF espaciados
Tabla 1. Perfiles definidos en Bluetooth 1.1 Especificaciones
Descripción
Procedimientos genéricos para descubrimiento y manejo del enlace de conexión a dispositivos Bluetooth
Características y procedimientos para la aplicación de un dispositivo Bluetooth, para descubrir servicios
registrados en otros dispositivos
Teléfono Inalámbrico Características y procedimientos para la interoperabilidad entre diferentes unidades activas en un teléfono
“3 en 1”
Intercomunicación
Requerimientos para soportar la funcionalidad de intercomunicación dentro de un teléfono “3 en 1”
Puerto Serial
Requerimientos para establecer conexiones de cable serial emulado utilizando RFCOMM entre dos
dispositivos pares.
Auricular
Requisitos de servicio de usuario final e interoperabilidad para dispositivos Bluetooth implementados en
auriculares
Dial-up
Requisitos de servicio de usuario final e interoperabilidad para dispositivos Bluetooth implementados en
una red de trabajo Dial-up.
Fax
Requisitos de servicio de usuario final e interoperabilidad para dispositivos Bluetooth implementados en
servicios de Fax
Acceso LAN
Definición de cómo un dispositivo Bluetooth puede acceder a un servicio LAN utilizando PPP y como los
Mecanismos PPP forman una red.
Intercambio de
Requerimientos para que un dispositivo Bluetooth soporte el cambio de objetos usando modelos.
objetos Genéricos
Empujón del objeto
Requisitos de aplicación para que un dispositivo Bluetooth soporte el empujón del objeto usando modelos.
Transferencia de
Requisitos de aplicación para que un dispositivo Bluetooth soporte transferencia de archivos usando
Archivos
modelos.
Sincronización
Requerimientos para que un dispositivo Bluetooth soporte la sincronización usando modelos.
Casos de Uso
Acceso Genérico
Servicio de entrega
1 MHz son definidos para España, Francia y Japón. Estos esfuerzos son la manera
de abrir todo el ancho del espectro en España y Francia, así como también en
Japón, a fin de que los dispositivos Bluetooth funcionen a nivel mundial.
Bluetooth es un sistema de “Espectro Expandido por Salto de Frecuencia”.
Es una forma de saltos de radio a través de todo el espectro por 79 o 23 canales RF
usando una secuencia de salto seudo aleatoria. La tasa de saltos es de 1600 saltos
por segundo dando una buena inmunidad contra otras fuentes de interferencia en
la banda de 2.4 GHz. La velocidad de comunicación es de 1 Mbps, la cual es
fácilmente conseguida usando una simple técnica de modulación (Gaussian
frequency Shift Keying o GFSK). Una técnica de modulación más compleja podría
Reporte industrial
conseguir tasa elevada, pero GFSK conserva el diseño simple del radio y los costos
bajos.
La parte frontal de la radio es usualmente la parte más costosa en una
interfaz de red inalámbrica. Dentro de un típico receptor de radio hay, filtros RF,
osciladores y mezcladores de procesos de señales de entradas a frecuencias altas.
Tales circuitos requieren materiales caros. Para conservar los costos bajos,
Bluetooth recomienda cambiar las señales de entrada bajando a una frecuencia
intermedia (IF, alrededor de 3 MHZ), lo cual permite sobre el chip la construcción
de filtros de bajo potencia usando materiales CMOS. Cambiando a la IF baja, sin
embargo, se crean nuevos problemas, tales como la reducida sensibilidad del
receptor. La sensibilidad del receptor recomendada para Bluetooth es de -70 dBm o
mejor. El número comparable para LANs Inalámbricas IEEE802.11 es
aproximadamente -90dBm. De tal manera que para la misma potencia de
transmisión, el rango para Bluetooth es mas corto que para WLAN 802.11.
Piconets y Scatternets.
Un conjunto de dispositivos Bluetooth compartiendo un canal común es llamado
una piconet. Como se muestra en la figura 2, una piconet es una configuración de
conformado principal en la cual el dispositivo del centro desempeña el rol de
maestro y todos los otros dispositivos operan como esclavos. Siete esclavos
máximos pueden esta activos y servidos simultáneamente por el maestro. Si el
maestro necesita comunicarse con más que siete dispositivos, este lo primero que
hace es instruir al dispositivo esclavo activo para cambiar al modo low-power park
y luego invitar a otro dispositivo parqueado a convertirse en activo en la piconet.
Este procedimiento puede ser repetido, el cual permite a un maestro servir a un
gran numero de esclavos.
Otras aplicaciones de Bluetooth ideadas involucran las comunicaciones
locales entre grupos pequeños de dispositivos. Una configuración de piconet
consiste de dos, tres o más hasta ocho dispositivos idealmente para satisfacer
apropiadamente las necesidades de las comunicaciones de tales aplicaciones.
Cuando muchos grupos de dispositivos necesitan ser simultáneamente activados,
cada grupo puede formar una piconet separada. Los nodos esclavos en cada
piconet permanecen sincronizados con el reloj del maestro y saltan acorde a una
secuencia de salto de canal que es una función de la dirección del nodo del maestro.
Puesto que la secuencia de salto de canal es seudo aleatoria, la probabilidad de
colisiones entre piconet es pequeña. Piconets con coberturas sobrelapadas pueden
coexistir y operar independientemente. Sin embargo cuando el grado de
sobrelapado es alto, el performance de cada piconet comienza a degradarse.
Estos usos son dentro de un mismo escenario, sin embargo, dispositivos en
diferente piconets pueden necesitar comunicarse con cada otro dispositivo.
Bluetooth
FIGURA 2. Piconet (izquierda) y Scatternet (derecha)
El dispositivo maestro en el centro de una piconet puede servir a siete esclavos;
miembros de dos o más piconets son llamados nodos puente, cada uno soporta
comunicación entre las piconets.
Bluetooth define una estructura llamada Scatternet para facilitar la comunicación
entre piconets.
Una Scatternet esta formada por múltiples piconets
interconectadas. Como muestra al lado derecho de la figura 2, las conexiones están
formadas por nodos puente, cada uno es miembro de dos o más piconets. Un
nodo puente participa como miembro en cada piconet en base a un tiempo
compartido. Después de permanecer en una piconet por cierto tiempo, el puente
puede cambiarse a otra piconet de conmutación para su secuencia de salto. A
través del ciclo de todos los miembros de las piconets, los nodos puente pueden
enviar y recibir paquetes en cada piconet y también almacenar paquetes de una
piconet en otra.
Un nodo puente puede ser un esclavo en ambas piconets o ser un esclavo en
una y ser un maestro en otra. Por ejemplo se considera un cuarto lleno de gente,
donde cada persona tiene un teléfono celular y un auricular sin cable, cuando los
usuarios hablan en sus ariculares, solo el teléfono celular que está emparejado con
los auriculares debería receptar la señal. En este ejemplo, cada par de auricular y
teléfono celular, constituye una piconet separada. Ahora suponga que estos
usuarios también quieren enviar mensajes de texto desde sus teléfonos celulares a
otros. Esto será posible solo si todas las piconets son interconectadas para formar
una amplia Scatternet. La técnica para formar Scatternets es todavía de bajo
desarrollo.
Inquiry y Paging
Bluetooth usa un procedimiento conocido como inquiry para el descubrimiento de
otros dispositivos; este usa paging para establecer conexiones subsecuenciales con
estos. Ambos, inquiry y paging son procedimientos asimétricos. En otras palabras,
ellos involucran a los dispositivos indagadores y los indagados
(bien como buscador o como buscado), para llevar a cabo diferentes acciones.
Reporte industrial
Esto implica que cuando dos nodos establecen una conexión, cada uno necesita
empezar desde un estado inicial diferente, de otro modo, ellos nunca podrían
descubrir a cada otro. Las especificaciones del perfil juegan aquí un rol importante,
definiendo el estado inicial requerido para cada dispositivo en todos los escenarios
de uso. Un procedimiento simétrico para el establecimiento de conexiones es un
tema de investigación en marcha.
Inquiry y paging son conceptualmente operaciones simples, pero la
naturaleza del salto de frecuencia de de la capa física hace los detalles de bajo nivel
bastante complejos. Dos nodos no pueden cambiar mensajes hasta que ellos
concuerden en una secuencia común de salto de canal como bien sea la fase
correcta dentro de la selección de frecuencia. Bluetooth resuelve estos problemas
simplemente mandando el uso de una secuencia específica de salto de indagación
conocida a todos los dispositivos. Durante inquiry, ambos nodos (uno es el
receptor y otro es el transmisor) saltan usando la misma secuencia; pero el
transmisor salta más rápido que receptor, transmitiendo una señal en cada canal y
escuchando entre transmisiones de una respuesta. Cuando más de un receptor está
presente, sus respuestas pueden chocar. Para evitar las colisiones, los receptores
aplazan sus respuestas hasta la expiración del tiempo aleatorio de retroceso (back
off). Eventualmente el dispositivo transmisor colecta cierta información básica de
los receptores, tal como la dirección del dispositivo y los offsets del reloj. Esta
información es subsecuentemente usada para el page del dispositivo receptor
seleccionado.
Los pasos para la comunicación durante el procedimiento de paging son
similares, excepto que el mensaje de paging es unicast para la selección del receptor,
pero el receptor no necesita back off antes responder. El transmisor también tiene
una mejor estimación del reloj del receptor, el que permite comunicarse con el
receptor casi instantáneamente. En el recibimiento de un ACK para el mensaje de
paging, el transmisor se convierte en maestro y el receptor en esclavo de la piconet
recientemente formada, y ambos conmutan para la secuencia de salto de canal de la
piconet. Después, si es necesario, los papeles del maestro y esclavo pueden ser
cambiados entre ellos.
Los pasos para admitir un nuevo esclavo dentro de una piconet existente,
son ligeramente más complejos. El maestro tampoco puede empezar descubriendo
nuevos nodos en esta vecindad e invitarlos a incorporarse a la piconet, o a su vez
esperar en estado de scan y ser descubierto por otros nodos. En ambos casos, la
comunicación en la piconet original tiene que ser suspendida en la duración de los
procesos de inquiry y paging. La latencia para admitir a un nuevo nodo dentro de
la piconet puede ser larga si el maestro no es conmutado frecuentemente a los
modos de inquiry o scan. Esta latencia puede ser reducida solo al costo de cierta
capacidad de la piconet. Este estudio es otro tema de investigación en marcha.
Bluetooth
Tabla 2. Canales de Throughput para diferentes tamaños de paquetes
Tamaño de Paquete (en ranuras)
throughput en Kbps (con FEC)
Throughput en Kbps (no FEC)
Esclavo
Maestro
Esclavo
Maestro
Esclavo
Maestro
1
1
108.8
108.8
172.8
172.8
3
1
387.2
54.4
585.6
86.4
5
1
477.8
36.3
723.2
57.6
Modos de bajo consumo de potencia
Bluetooth ofrece diferentes modos de potencia bajo para mejorar la vida de la
batería. Piconets se forman a petición cuando la comunicación entre dispositivos
esta lista a dar lugar. En todos los otros tiempos, los dispositivos pueden ser uno u
otro desactivados o programados para despertarse periódicamente para enviar o
recibir mensajes de inquiry.
Cuando una piconet es activada, los esclavos permanecen activados en la
comunicación con el master. Es posible cambiar a un esclavo en un modo de bajo
consumo de potencia haciendo que duerma la mayoría del tiempo y se despierta
sólo periódicamente.
Tres tipos de modos de bajo consumo de potencia han estado definidos:
El modo Hold es usado cuando un dispositivo debería verse obligado a dormir por
un intervalo de tiempo especificado. Como se describió anteriormente, el master
puede poner a todos sus esclavos en el modo oled para suspender actividad en la
piconet en uso, mientras va en busca de miembros nuevos y les invita a ellos que se
asocie.
El modo Sniff es usado para poner a un esclavo en un modo reducido su ciclo
obligatorio, para que se despierte periódicamente a comunicarse con el master.
El modo Park es similar al modo sniff, pero se usa para quedarse sincronizado con
el master sin ser un miembro activo del piconet.
El modo parqueo faculta al master a admitir más de a siete esclavos en su piconet.
Piconet Channel
Tan pronto como un piconet se forma, la comunicación entre el master y los nodos
del esclavo pueden comenzar.
El canal del piconet está dividido en intervalos de 625 microsegundos, llamadas
ranuras, donde una frecuencia de salto diferente sirve para cada ranura. El canal es
compartido entre el master y los nodos del esclavo usando un salto de
Reporte industrial
frecuencia/duplexacion de división de tiempo (FH/TDD) por medio de la cual las
comunicaciones esclavo- maestro y maestro-esclavo toman turnos. La
comunicación esclavo- esclavo no es soportado por la capa piconet. Si dos esclavos
necesitan comunicarse directamente, entonces ellos, pueden formar una piconet
separada o usar un protocolo de capa superior como IP sobre PPP, (vea la Figura
1), para transmitir los mensajes por el master.
En una velocidad del enlace de 1Mbps, un tiempo de la ranura de 625
microsegundos es equivalente al tiempo de transmisión de 625 bits. Sin embargo, el
tamaño del paquete en una sola ranura en Bluetooth es sólo 366 bits. Esto reserva
bastante tiempo de guarda para dejar que los sintetizadores de frecuencia salten a
la siguiente frecuencia del canal y se estabilicen. Descontando espacio para los
encabezados deja 30 bytes para la carga útil del usuario.
Enlace síncrono
Para transmitir voz en tiempo real, una aplicación debe reservar una ranura en
ambas direcciones en intervalos regulares.
En terminología Bluetooth, éste es llamado un enlace síncrono (SCO). Un enlace
SCO puede transportar voz de grado telefónico. El codificador de discurso genera
10 bytes cada 1.25 Desde un paquete de banda base puede llevar mas de 30 bytes
en cada ranura, solo una ranura por cada dirección es necesaria cada 3.75
milisegundos. (o cada sexta ranura). El tipo del paquete que lleva 30 bytes de voz es
llamado un paquete del HV3. Este paquete es transmitido sin codificación o
protección, y no es retransmitida si está perdida.
Tener suficiente fuerza frente a bits errados cuando las condiciones del canal
no son perfectas, alguna corrección anticipada de errores (FEC) debería agregarse
para la carga útil de voz. Un paquete del HV2 transmite 20 bytes de voz y 10 bytes
de datos redundantes (el código 2/3 FEC). Desde 20 bytes de discurso es generado
en 2.5 milisegundos., el enlace SCO debería reservar una ranura en cada dirección
cada 2.5 milisegundos. (o cada cuarta ranura). Hacer frente a las condiciones
extremas del canal, la especificación de banda base también define un paquete del
HV1 que lleva sólo 10 bytes de discurso y 20 bytes de código FEC. Un enlace HV1
SCO gasta la aptitud entera del canal. Esto quiere decir que todas las sesiones de
transferencia de datos serán suspendidas cuando una conexión HV1 SCO está de
progreso.
Enlace asíncrono
La comunicación de datos entre un par esclavo-maestro implica un set diferente de
consideraciones. Por ejemplo, la carga útil de datos debe estar protegida por una
prueba de redundancia cíclica (CRC a fin de que el receptor puede determinar si
los bits recibidos tienen error. Cuando las pérdidas ocurren, la capa de banda base
debería retransmitir los datos. Además, para hacer uso eficiente del canal del
piconet, las ranuras deberían ser ubicadas a petición, en lugar de estar reservadas
Bluetooth
para la duración de uso. Un camino de datos entre un par del esclavo -maestro
responsabilizándose por todo estos requisitos es llamado un enlace de datos
asincrónico (ACL). Los enlaces SCO tienen una prioridad sobre los datos. Así que
ACLs solamente pueden reclamar slots sin usar. Solamente un ACL puede existir
entre un amo y un esclavo.
El amo es responsable de distribuir slots disponibles entre todos los ACLs.
Este esquema tiene dos ventajas:
- El amo puede asegurar que las transmisiones del esclavo no colisionen; y
- Los slots pueden ser asignados para satisfacer la calidad de servicio (QoS)
requerida en cada ACL. El amo puede conceder más ancho de banda a un esclavo
sondeándolo más frecuentemente o cambiando el tamaño de paquete.
La especificación de banda base no da instrucciones del uso de ningún esquema de
localización de slot específico. Los distribuidores de chip pueden escoger cualquier
política que se ajuste a sus aplicaciones destinadas.
Como con paquetes de SCO, el tamaño de carga útil de paquetes de ACL de
un simple slot es limitado a 30 bytes. Después de descontar el espacio para los
encabezamientos de capa más altas y el CRC, solamente quedan 27 bytes para
transportar los datos de aplicación. Cuando FEC es añadido, el espacio disponible
baja a 17 bytes.
Para mejorar la eficiencia de canal, la especificación de banda base ha definido
paquetes multislot, los cuales son de longitud de tres o cinco slots y se transmiten
en slots consecutivos. El transmisor se queda fijo en un salto de frecuencia durante
la duración de transmisión de paquete y las omite los saltos perdidos después de
que la transmisión se completa. Esto reduce la velocidad de salto de canal efectiva,
pero incrementa la eficiencia de canal debido a muy pocos saltos
El Cuadro 2 indica el rendimiento alcanzable en las direcciones amo esclavo y esclavo - amo como una función del tamaño de paquete, con y sin FEC.
Aunque la velocidad de enlace es 1 Mbps, el caudal de proceso y transferencia total
alcanzable puede extenderse de 217.6 Kbps a 780.8 Kbps. La presencia de un HV3
o el enlace de SCO de HV2 reducen el rendimiento alcanzable de uno ACL
significativamente.
Protocolo de Control y adaptación de enlace lógico
L2CAP puede ser visto como el nivel de datos de la capa de enlace de Bluetooth
(ver Figura 3). Ya que el tamaño de paquete de banda base es demasiado pequeño
para transportar paquetes de capa superior, una capa fina es necesitada para
exportar un tamaño de paquete más grande a las capas más altas. Mientras varios
protocolos de segmentación y reensamblaje genéricos podían ser usados o
adaptados para el uso sobre ACLs, Bluetooth SIG definió L2CAP en su lugar, el
Reporte industrial
cual es altamente optimizado para trabajar en conjunción con la capa de banda
base.
Figura 3 Parte más baja del snack. L2CAP puede ser vista como el plano de datos
de la capa enlace de Bluetooth
Por ejemplo, L2CAP no soporta chequeos de integridad porque los paquetes de
banda base ya son protegidos con CRC. Igualmente, se supone que la capa más
baja entrega paquetes tanto fiables y en secuencia. Estas dos suposiciones
simplifican el diseño de la segmentación y la lógica de reensamblaje
significativamente. Lo único que hay que tomar en cuenta es que L2CAP no
trabajará si se usa sobre otro entorno aparte de la banda base Bluetooth.
El multiplexaje y demultiplexaje de protocolos de capa superior es
soportado usando canales, múltiples ejemplos de cuáles pueden ser creados entre
cualquier de dos puntos finales L2CAP. Cada protocolo de capa superior o flujo de
datos son traídos en un canal diferente. Los canales de L2CAP son orientados a
conexión en el sentido de que requieren una fase explícita para establecer el canal,
durante la cuál ambos finales escojan un nombre local (identificador de canal) y lo
comuniquen al otro. Posteriormente, cada paquete enviado sobre el canal es
etiquetado con el identificador de canal, dentro del contexto del receptor identificar el origen así como el protocolo que esta siendo transportado sobre el
canal.
La especificación de L2CAP también define un canal sin conexión para la
transmisión de soporte y la comunicación de grupo de multicast, pero esta
característica todavía no esta completamente desarrollada.
Protocolo de Servicio de Descubrimiento
Ambos terminales de un enlace de Bluetooth deben soportar grupos compatibles
de protocolos y aplicaciones para intercambiar datos con éxito. En algunos casos
podría ser también necesario arreglar protocolos y ajustes de parámetro de pila
antes de que las aplicaciones puedan ser puestas en marcha. Tales ajustes de
configuración no pueden ser escogidos estáticamente, ya que algunos parámetros
pueden requerir ajuste para corresponder las características y servicios soportados
por los dispositivos pares Bluetooth.
El SDP de Bluetooth provee unos estándares dirigidos a dispositivos
Bluetooth para consultar y descubrir servicios soportados por un dispositivo
Bluetooth
semejante Bluetooth. SDP es un protocolo cliente-servidor. El servidor mantiene
actualizado una lista de hojas de servicios, que describe las características de
servicios ofrecidos al servidor. Con la emisión de preguntas SDP, un cliente puede
chequear todo los registros de servicios disponibles mantenidos en el servidor o
recupera valores específicos del atributo del registro de un servicio.
Además se define protocolos de preguntas y respuestas, la especificación
SDP también define un método normalizado para describir atributos del servicio.
Los atributos del servicio son representados usando < identificador, valor> par. La
especificación 1.1 define algunos servicios comúnmente usados, pero diseñadores
tienen la libertad de definir nuevas sub clases de los servicios normalizados o crear
propios servicios nuevos.
Puesto que definiciones nuevas del servicio no requieren alguna
coordinación con el Bluetooth SIG autoridad numerante, es necesario asegurar que
los dos servicios creados independientemente no tengan conflicto.
Se evitan colisiones asociando cada servicio definido con un identificador universal
único (UUID) que es generado una sola vez cuando el servicio es definido. UUIDs
de los servicios definidos por el Bluetooth SIG estan incluidos en la asignación de
los numerales del documento.
Si el cliente ya sabe el UUID del servicio que busca, puede preguntar al
servidor SDP por atributos del servicio específicos. Alternadamente, el cliente
puede chequear la lista de servicios disponibles y seleccionar de la lista. Éstas son
sólo dos opciones de búsqueda de soporte SDP. Aunque otro IP-based
descubridor de servicios, tal como SLP y Jini, provee la descripción del esquema del
servicio más alta y capacidades de la búsqueda más poderosas, el Bluetooth SDP
tiene dos ventajas:
 La mayoría de versiones 1.1 cumplen con los dispositivos Bluetooth no
serán dispositivos IP. Requiriendo ellos el soporte IP sólo por el soporte
SLP sería costoso.
 SDP es optimizado para correr sobre L2CAP. Su capacidades de la búsqueda
limitadas y no casadas en texto, atributo-id y atributo-valor preste una eficaz
y pequeña huella para implementación de pequeños dispositivos.
SDP provee un mecanismo sólo para recuperar información del servicio de otros
dispositivos. Métodos de invocar estos servicios esta fuera de la mira de SDP.
LINK MANAGER PROTOCOL
Antes de que un aparato pueda establecer el canal L2CAP, el link manager debe
llevar a cabo varias acciones especificadas en banda base, tal como creación de la
piconet, asignaciones del papel maestro-esclavo, y configuración del link. Estas
funciones corresponden al plano de control de la capa enlace de Bluetooth y
requiere que el link manager intercambie mensajes LMP sobre el enlace de aire.
Dependiendo del ambiente de operación, el link manager debe ajustar un número
de piconets y los parámetros específicos para la conexión. Por ejemplo, en un
Reporte industrial
enlace de pares, el controlador puede dar instrucciones para unirlo a un modo de
bajo consumo de potencia, ajustar su nivel de poder, incrementar el tamaño del
paquete y pedir el cambio de QoS en un ACL.
La seguridad puede ser también configurada usando mensajes LMP. Antes
de que un intercambio de voz o datos pueda comenzar, aparatos Bluetooth deben
poder autenticar al uno al otro. Igualmente, transmisión sobre el enlace de aire
deberá ser encriptada para proveer protección. Ambos objetivos son fácilmente
alcanzables cuando una asociación segura existe entre un para de dispositivos. El
link manager puede usar el secreto de la llave compartida para verificar la
autenticidad de un par de dispositivos tanto para negociar una conexión segura y
para encripción. Una sesión típica entre dos dispositivos Bluetooth empieza con la
formación de un piconet, seguido por el intercambio de mensajes LMP primero
para autenticación y luego para negociar llaves de encripción nuevas con el
dispositivo par. Sólo una realización exitosa del LMP handshake puede tener lugar
el intercambio datos o la comunicación de voz.
El nivel de seguridad construido dentro de las especificaciones de la versión
1.1 son muy satisfactorias como al inicio las asociaciones de seguridad son
computadas de modo seguro. Las especificaciones banda base y LMP también
definen un método, llamado “pairing”, por crear una nueva asociación de seguridad
entre dos aparatos cuando se unen por primera vez. El método usa un canal fuerade-banda para crear una asociación de seguridad, que se usa entonces como una
semilla computada, un grafico criptográfico afianza la llave secreta compartida. Por
fuera del canal de banda base quiero decir un usuario tipeando un número
randómico numero PIN escogido en ambos dispositivos. Claramente, la seguridad
de una fase de “pairing” es limitada por la habilidad de un usuario al escoger
números PIN buenos. En escenarios cuando un dispositivo del par no tiene un
teclado numérico, la seguridad se puede comprometer si el PIN escogido es
trasmitido a otro aparato en texto claro.
Poniendo los pedazos juntos
El último objetivo de las especificaciones de Bluetooth es permitir que las
aplicaciones del multivendor interoperen. Diferentes aplicaciones pueden correr en
diferentes dispositivos aparatos, y cada dispositivo puede usar un snack de
protocolo de un vendedor y un chip Bluetooth de otro. Sin embargo la
interoperabilidad entre aplicaciones es alcanzada cuando implementaciones
diferentes coinciden con las mismas especificaciones core y perfiles. En la capa
más baja, los chips Bluetooth de diferentes vendedores interoperan sobre el enlace
de aire porque todos los chips Bluetooth implementan la banda base y las
especificaciones de LMP. Los stacks de Bluetooth, que pueden ser implementados
de ambas maneras firmware o software, incluyen el L2CAP, SDP, y capas de
RFCOMM. Es relativamente fácil pasar un stack Bluetooth de una plataforma a
otro porque la capa más baja del interfaz del stack Bluetooth con un chip de
Bluetooth
Bluetooth une a un interfaz de estándar HCI que también es una parte de las
especificaciones 1.1.
Pasar una aplicación de Bluetooth de un stack a otro, sin embargo, es más
difícil. La aplicación puede usar cualquier estándar API para acceder a IP, PPP,
OBEX, o capas de RFCOMM del stack de Bluetooth, pero no hay ningún estándar
API para acceder a las funciones de control proporcionadas por es stack de
Bluetooth. Por ejemplo, si una aplicación fuera a comenzar una pregunta de
Bluetooth para descubrir a los otros dispositivos vecinos, debe usar un API
específico del stack del vendedor para acceder a esas funciones.
Sólo se ha mantenido soporte para RFCOMM por razones de
compatibilidad hacia atrás. Aplicaciones del legado que corren sobre cable serial,
como OBEX y PPP, trabajarán sobre cualquier stack Bluetooth sin modificación
alguna. Así, la sincronización y las aplicaciones basadas en IP ya desarrolladas por
los vendedores pueden estar inmediatamente disponibles cuando PDAs, teléfonos
celulares, y computadoras portátiles están en modo Bluetooth enable. El próximo
lanzamiento de especificaciones de Bluetooth tendrá un mejor soporte de IP (sin
pasar a través de PPP y capas de RFCOMM), así aumentará la portabilidad de
aplicaciones basadas en IP frente a todas las plataformas de Bluetooth. La
estandarización de control API, sin embargo, ha sido una tarea inconclusa que no
se ha despegado todavía por ninguna organización de estándares.
Conclusión
Si Bluetooth mantendrá su promesa o no, dependerá de varios factores, algunos de
los cuales involucran las fuerzas del mercado en lugar de los problemas técnicos.
Por ejemplo, a menos que la adopción inicial de Bluetooth sea alta, será difícil
encontrar el objetivo de precios bajos.
La seguridad también es un tema abierto que está en casi todas aplicaciones
de Internet. El flujo libre de información es deseable en algunos escenarios, pero en
general, se requieren garantías adecuadas para prevenir el goteo desautorizado de
información. El Bluetooth SIG está dirigiéndose a los problemas de seguridad
asociados con los escenarios de uso inicial, pero las nuevas aplicaciones de
Bluetooth requerirán una mirada más íntima a las amenazas potenciales de
seguridad.
Un problema técnico es el de la interoperabilidad basada en el perfil, es fácil
de manejar cuando el número de perfiles es pequeño, pero las predicciones del
mercado indican que más de mil millones dispositivos se equipará con chips
Bluetooth por el 2005. Este número es significativamente mayor que el número de
hosts conectados al Internet hoy. Cuando las personas encuentran usos
innovadores de esta tecnología, se necesitarán los nuevos perfiles. Conllevar el
cumplimiento con un rápido crecimiento en el número de perfiles probablemente
será difícil de mantener en el futuro. Una solución buena a este problema sería
Reporte industrial
estandarizar rápidamente una especificación IP encima de Bluetooth, desde la
interoperabilidad hasta la capa de IP que traduciría automáticamente la
interoperabilidad a la capa de las aplicaciones. Algunos esfuerzos ya han empezado
dentro del Bluetooth SIG así como en el IETF para resolverse este problema.
Bluetooth ha captado la atención de consumidores porque esto los habilitaría
para hacer cosas que son por otra parte incomodas o no posibles: la sincronización
de datos entre los teléfonos celulares, computadoras portátiles, y PDAs; los
teléfonos celulares usados como teléfonos inalámbricos en casa; y PDAs que unen
a la LAN de la oficina. El valor de la propuesta es por consiguiente fuerte. El
desafío para vendedores es encontrar estas expectativas.
Referencias
1.
Specification
of
the
Bluetooth
System
—
Core;
available
online
http://www.bluetooth.com/developer/specification/Bluetooth_11_Specifications_Book.pdf.
at
2.
Specification
of
the
Bluetooth
System
—
Profiles;
available
online
at
http://www.bluetooth.com/developer/specification/Bluetooth_11_Profiles_Book.pdf.
3. G. Miklos et al., “Performance Aspects of Bluetooth ScatternetFormation,” poster presentation at Mobile Ad Hoc
Networks and Computing (MobiHOC 2000), IEEE/ACM workshop, Aug. 2000.
4. T. Salonidis et al., “Distributed Topology Construction of Bluetooth Personal Area Networks,” Proc. IEEE
Infocom 2001, IEEE Communication Society, New York, 2001.