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.