Arquitectura: transporte de datos

El sistema de transferencia de datos Bluetooth funciona mediante una arquitectura de capas. A continuación se describen las capas de transferencia básicas y los canales L2CAP. Los distintos modos operativos dentro de la tecnología Bluetooth siguen la misma arquitectura de transferencia.

Por cuestiones relacionadas con la eficacia y las aplicaciones heredadas, la arquitectura de transferencia de la capa lógica se subdivide para distinguir entre enlaces lógicos y comunicaciones lógicas. El enlace lógico permite una comunicación independiente entre dos o más dispositivos. La comunicación lógica es necesaria para describir la interdependencia entre algunos enlaces lógicos, principalmente por el funcionamiento de las aplicaciones heredadas.

La especificación Bluetooth 1.1 define los enlaces ACL y SCO como enlaces físicos. No obstante, con la incorporación del enlace SCO ampliado (eSCO) y puestos a considerar futuras ampliaciones, resulta más conveniente tratar estos enlaces como lógicos ya que este tipo obedece mejor a su finalidad. La independencia no es tan grande como cabría esperar debido al uso compartido de recursos como LT_ADDR y el patrón de confirmación y repetición automática (ARQ). Por esta razón, la arquitectura es incapaz de representar estas comunicaciones lógicas en una única capa de comunicación. Para compensarlo, una capa adicional describe este proceder.

Portadores de tráfico

La denominación de los enlaces lógicos se realiza añadiendo a la comunicación lógica asociada un sufijo que indica el tipo de datos que se están transfiriendo: C para enlaces de control que transportan mensajes LMP, U para enlaces L2CAP que transfieren datos del usuario (unidades PDU de la capa L2CAP) y S para enlaces de flujo que transmiten datos síncronos o isócronos sin formato. Resulta habitual eliminar el sufijo del enlace lógico sin que se induzca a error. Puede entenderse que una referencia al enlace lógico ACL significa un enlace lógico ACL-C cuando se trate del protocolo LMP, o un enlace lógico ACL-U cuando se esté en el contexto de la capa L2CAP.

La asignación de un tipo de transferencia a los portadores del núcleo del sistema Bluetooth se realiza basándose en las características que comparten el tráfico y el portador. Este método de asignación es bastante recomendable, ya que permite una transferencia de datos más natural y eficaz de acuerdo con las características de la información.

Una aplicación o implementación del núcleo del sistema Bluetooth podrá seleccionar un portador de datos distinto u otro método de asignación para conseguir un resultado similar. Por ejemplo, en una piconet con un único esclavo, el maestro puede decidir si realiza las difusiones L2CAP a través del enlace lógico ACL-U en lugar de por los enlaces ASB-U o PSB-U. Esta operación puede ser más acertada en términos de ancho de banda si la calidad del canal físico no está muy mermada. La utilización de rutas de comunicación alternativas es una solución aceptable sólo si se mantienen las características del tipo de tráfico de la aplicación.

Los tipos de tráfico de la aplicación permiten clasificar los datos que se pueden enviar al núcleo del sistema Bluetooth. El tipo de tráfico inicial puede no coincidir con el recibido por el núcleo del sistema Bluetooth, si algún proceso intermedio lo modifica. Por ejemplo, los datos de vídeo se generan a una velocidad constante, pero un proceso de codificación intermedio podría convertir esta velocidad en variable (codificación MPEG4). En el contexto del núcleo del sistema Bluetooth, sólo interesan las características de los datos enviados.

Transferencia de tramas de datos

Los canales de conexión L2CAP pueden crearse para la transferencia de datos por unidifusión (punto a punto) entre dos dispositivos Bluetooth. Un canal L2CAP sin conexión está destinado a la difusión de datos. En el caso de las topologías de piconet, el dispositivo maestro es siempre el emisor de los datos de difusión y los dispositivos esclavos serán los receptores. El tráfico del canal de difusión L2CAP es unidireccional. A este respecto, los canales de unidifusión L2CAP pueden ser unidireccionales o bidireccionales.

Los canales L2CAP están configurados con un parámetro de calidad de servicio (QoS) que define limitaciones para el envío de tramas de datos. Esta configuración QoS puede utilizarse para indicar, por ejemplo, que los datos son isócronos y que, por consiguiente, tienen un periodo de validez limitado a efectos de envío o bien que los datos son fiables y deben entregarse sin errores, sin importar el tiempo que tarden en enviarse.

El gestor del canal L2CAP es responsable de organizar la transferencia de tramas de datos por el canal L2CAP a través del enlace lógico correspondiente de la banda base. Para ello, se puede recurrir al multiplexado en el enlace lógico con otros canales L2CAP de características similares.

Volver al principio

Transferencia de datos sin tramas

El núcleo del sistema Bluetooth admite la transferencia directa de datos isócronos de la aplicación con una velocidad constante (velocidad en bits o en tramas) mediante un enlace lógico SCO-S o eSCO-S. Los enlaces lógicos reservan ancho de banda del canal físico y ofrecen una velocidad de transferencia constante sincronizada con el reloj de la piconet. Los datos se transfieren en paquetes de un tamaño fijo en intervalos establecidos. Tanto el tamaño de los paquetes como los intervalos se determina durante la creación del canal. Los enlaces eSCO admiten una selección más amplia de velocidades de transferencia en bits y son más fiables, ya que realizan una retransmisión limitada en caso de error. La transferencia de datos mejorada (EDR) es compatible con las comunicaciones lógicas eSCO pero no con las SCO. Ambas comunicaciones lógicas son incompatibles con los enlaces lógicos multiplexados y con otras capas del núcleo del sistema Bluetooth. Una aplicación puede apilar en una capa un número de flujos dentro del flujo SCO/eSCO enviado, siempre que éste tenga una velocidad de transferencia constante.

La aplicación seleccionará el enlace lógico más apropiado de la banda base y, a continuación, creará y configurará el modo de transferencia del flujo de datos para iniciarla en cuanto se termine el proceso. Por lo general, la aplicación también utilizará un canal de unidifusión L2CAP en tramas para transferir información del plano C (control) sin formato a la aplicación paralela del dispositivo remoto.

Si los datos son isócronos y de velocidad variable, esta operación sólo podrá realizarse a través del canal de unidifusión L2CAP, por lo que serán tratados como datos en tramas.

Fiabilidad de los portadores de tráfico

En las comunicaciones lógicas ACL, los resultados del algoritmo de detección de errores se interpretan para generar un protocolo ARQ simple. Así, se consigue una fiabilidad mayor al retransmitirse los paquetes a los que no se aplica el algoritmo del receptor para la comprobación de errores. Este patrón de repetición automática puede modificarse para admitir paquetes sensibles a la latencia. Para ello, se descartan los enviados incorrectamente y cuya duración o periodo de validez haya expirado. Los enlaces eSCO utilizan una versión modificada de este patrón y mejoran la fiabilidad de las transmisiones al permitir su repetición un determinado número de veces.

La fiabilidad que aporta este patrón ARQ dependerá de la capacidad de los códigos HEC y CRC para detectar errores. En la mayoría de los casos, basta con estos códigos. No obstante, se ha demostrado que, para paquetes de mayor tamaño, la probabilidad de que un error quede sin detectar es demasiado alta para las aplicaciones estándar, especialmente para las que transfieren gran cantidad de datos.

La capa L2CAP proporciona un mayor control de los errores, al detectar aquellos que pasan inadvertidos en la banda base para, a continuación, solicitar el reenvío de los datos afectados. De esta forma, se garantiza el nivel de fiabilidad esperado de las aplicaciones Bluetooth.

Los enlaces de difusión no tienen ruta de retroalimentación, por lo que no pueden utilizar el patrón ARQ, aunque el receptor podrá detectar los errores en los paquetes recibidos. En su defecto, cada paquete se envía varias veces suponiendo que el receptor recibirá al menos una de las copias correctamente. A pesar de estas medidas, no existen garantías reales de que la entrega se realice correctamente. Por tanto, la fiabilidad de estos enlaces es bastante cuestionable.

En resumen, un enlace o canal se considera fiable cuando el receptor puede detectar errores en los paquetes entregados y solicita la repetición de la transmisión hasta que lleguen sin problemas. Según el sistema de detección utilizado, los datos recibidos podrían contener algunos errores de tipo residual. Para los canales L2CAP, el nivel de fiabilidad es comparable al de otros sistemas de comunicación. Si bien, en los enlaces lógicos, la posibilidad de que persistan ciertos errores es algo mayor.

El transmisor podría eliminar paquetes de la cola de envío, por lo que no se entregaría la secuencia completa. Si esto ocurre, la capa L2CAP se encargará de localizar los paquetes que faltan.

En un enlace poco fiable, el receptor puede detectar errores en los datos recibidos, pero no solicitar un nuevo envío. Los paquetes transmitidos al receptor podrán llegar sin errores, pero no hay certeza de que se entreguen todos los que comprenden la secuencia de información. De ahí la nula fiabilidad de estos enlaces. Estos enlaces sólo tienen ciertos usos que, por lo general, dependen de la repetición continua de los datos desde las capas superiores mientras son válidos.

Los enlaces de flujo se pueden considerar fiables o no según las condiciones en que operen.

Volver al principio

Entidades de la arquitectura de comunicación

Estructura genérica de los paquetes Bluetooth

Los paquetes sólo suelen incluir los campos necesarios para representar las capas implicadas en la transmisión. Así, una solicitud de detección o inquiry a través de un canal físico de búsqueda no crea ni necesita ningún enlace lógico ni ninguna capa superior, por lo que se compone tan sólo del código de acceso al canal (asociado al canal físico). Las comunicaciones normales en una piconet se realizan con paquetes en los que se especifican todos los campos, ya que se utilizan todas las capas de la arquitectura.

Todos los paquetes incluyen el código de acceso al canal. De esta forma, se identifican las comunicaciones del canal físico al que van dirigidos y se excluyen los paquetes de canales diferentes que estén utilizando la misma portadora de RF en las proximidades.

La estructura de paquetes Bluetooth no tiene ningún campo que represente directamente la información relacionada con los enlaces físicos. Esta información está implícita en la dirección de comunicación lógica (LT_ADDR) ubicada en la cabecera del paquete.

La mayoría de los paquetes tienen una cabecera, imprescindible cuando la transmisión de datos se efectúa por canales físicos que admiten enlaces físicos, comunicaciones lógicas y enlaces lógicos. La cabecera contiene el campo LT_ADDR para que cada dispositivo receptor pueda determinar si el paquete le está destinado. Asimismo, este campo se utiliza para dirigir el paquete internamente.

Otro de los datos especificados en la cabecera es el protocolo LC que opera por comunicación lógica, excepto para las comunicaciones ACL y SCO, que comparten un protocolo LC transmitido por cualquiera de estos enlaces lógicos.

Los paquetes EDR especifican el intervalo de guarda y la secuencia de sincronización antes de la carga útil. Este campo se utiliza para que la capa física pueda cambiar la secuencia de modulación.

La cabecera de carga útil aparece en todos los paquetes de las comunicaciones lógicas compatibles con varios enlaces lógicos. Esta cabecera incluye un identificador de enlace lógico, que dirige la carga útil, y un campo en el que se especifica la longitud de esta carga. Algunos paquetes incluyen, además, un código de comprobación CRC tras la carga útil con el que se detectan la mayoría de los errores recibidos. Los paquetes EDR tienen una cola o tráiler tras este código CRC.

La carga útil del paquete sirve para transferir los datos del usuario, que se interpretarán conforme al tipo de identificador de enlace o comunicación lógica. Los mensajes LMP y las señales L2CAP de las comunicaciones lógicas ACL se transportan en la carga útil del paquete, junto con los datos genéricos del usuario de las aplicaciones. En el caso de las comunicaciones lógicas SCO y eSCO, la carga útil contiene los datos del usuario para el enlace lógico.

Canales físicos

Dos dispositivos Bluetooth utilizan un canal físico común para comunicarse. Para ello, los transmisores deben estar sintonizados en la misma radiofrecuencia y dentro de sus alcances nominales respectivos.

Dado que el número de portadoras de RF es limitado y que muchos dispositivos Bluetooth podrían funcionar de forma autónoma en la misma franja de espacio-tiempo, existe una posibilidad bastante alta de que sus transmisores sintonicen la misma portadora de RF, lo que ocasionaría un choque de canales físicos. Para contrarrestar los efectos de este choque, las transmisiones de cada canal físico comienzan con un código de acceso correlativo para los distintos dispositivos en sintonía. Este código de acceso es una característica del canal físico y se encuentra siempre al principio de cada paquete transmitido.

En la tecnología Bluetooth, se definen cuatro canales físicos, cada uno de ellos optimizado para un fin distinto. Los canales físicos básicos y adaptados de la piconet permiten la comunicación entre los dispositivos conectados y se asocian a una piconet concreta. El resto de canales se utiliza para detectar dispositivos Bluetooth (canal de búsqueda) y para conectarlos (canal de paginación).

Un dispositivo Bluetooth sólo puede emplear uno de estos canales físicos en un momento dado. Para realizar varias operaciones a la vez, el dispositivo recurre al multiplexado por división de tiempo entre los canales. De esta forma, parecerá que funciona simultáneamente en varias piconets y quedará listo para su detección y conexión.

Siempre que un dispositivo Bluetooth está sincronizado con el reloj, la frecuencia y el código de acceso de un canal físico, se dice que el dispositivo está “conectado” a este canal, con independencia de si participa activamente o no en las comunicaciones que estén teniendo lugar. La especificación Bluetooth presupone que un dispositivo no puede conectarse a más de un canal físico al mismo tiempo. Sin embargo, los dispositivos con tecnología avanzada pueden conectarse simultáneamente a más de uno, si bien esto no aparece recogido en la especificación.

Volver al principio

Canal básico de la piconet

Descripción

Características

El canal se divide en ranuras de tiempo, cada una dedicada a una frecuencia de salto RF. Los saltos consecutivos corresponden a distintas frecuencias de salto RF. Las ranuras de tiempo se enumeran según el reloj del dispositivo Bluetooth maestro. Los dispositivos Bluetooth de la piconet transmiten los paquetes ubicados en los límites de las ranuras. La primera información del paquete será el código de acceso al canal, que vendrá dado por la dirección del dispositivo maestro.

En el canal básico de la piconet, el maestro controla el acceso. Para ello, empieza a transmitir datos sólo en las ranuras de tiempo pares. Los paquetes transmitidos por el maestro se sitúan en el principio de la ranura y establecen la sincronización de la piconet. Por otra parte, estos paquetes podrán ocupar hasta cinco ranuras dependiendo del tipo al que pertenezcan.

Las transmisiones de los dispositivos maestros consisten en paquetes de información enviados a través de comunicaciones lógicas. A modos de respuesta, los dispositivos esclavos podrán transmitir datos en el canal físico. La forma en que esto se haga dependerá de la comunicación lógica a la que vaya dirigida la respuesta.

Por ejemplo, en la comunicación lógica destinada a la conexión asíncrona, el dispositivo esclavo receptor responde enviando un paquete para la misma comunicación lógica, que en principio se encuentra al inicio de la siguiente ranura (con número impar). El tipo de paquete enviado podrá ocupar hasta cinco ranuras de tiempo. En una comunicación de difusión lógica, no se permite la respuesta de ningún esclavo.

Una característica especial del canal físico básico de la piconet es el uso de ranuras reservadas para transmitir balizas o beacons. Estos paquetes de control se utilizan si hay esclavos conectados al canal físico de la piconet en modo park o de espera. En este contexto, el maestro transmite un paquete por medio de las ranuras reservadas para las balizas y el esclavo utiliza la información transmitida para volverse a sincronizar con el canal físico de la piconet. El maestro puede utilizar cualquier comunicación lógica para transmitir paquetes por estas ranuras, siempre que haya una transmisión en curso en cada una de ellas. En caso de haber información de difusión del dispositivo esclavo en espera (PSB) pendiente de transmisión a través de una comunicación lógica, ésta se envía mediante las ranuras de baliza y tienen prioridad sobre cualquier otra comunicación lógica.

Topología

En este sentido, las comunicaciones lógicas admitidas por la piconet están limitadas. Aunque no existe ninguna limitación teórica respecto a la cantidad de dispositivos Bluetooth que pueden compartir un canal, sólo un cierto número de ellos podrá participar activamente en el intercambio de datos con el maestro.

Capas compatibles

Canal adaptado de la piconet

Descripción

Los canales adaptados y básicos son a menudo iguales, ya que ambos pueden tener la misma sincronización y código de acceso. Así, los esclavos de estos dos canales cuentan con una ventaja adicional al poder ajustar su sincronización con la del maestro.

La topología y las capas compatibles del canal físico adaptado de la piconet son iguales a las del canal físico básico.

Volver al principio

Canal de búsqueda

Descripción

Características

El código de acceso usado en el canal de búsqueda se selecciona de un conjunto reservado de códigos de acceso compartidos por todos los dispositivos Bluetooth. Existe un código de acceso para búsquedas generales y varios códigos de acceso reservados para búsquedas concretas. Cada dispositivo puede acceder a distintos canales de búsqueda. Puesto que estos canales comparten el mismo patrón de salto, un dispositivo podrá ocupar más de un canal de búsqueda si es capaz de relacionar varios códigos de acceso a la vez.

Un dispositivo que utiliza uno de sus canales de búsqueda permanece en estado pasivo hasta que recibe un mensaje de otro dispositivo Bluetooth, que se identifica con el código de acceso de búsqueda apropiado. El dispositivo susceptible de detección seguirá el procedimiento de respuesta y enviará un mensaje al dispositivo que realiza la búsqueda.

Para realizar la detección, el dispositivo debe enviar solicitudes de búsqueda a través de los canales correspondientes. Al no conocerse con anterioridad los dispositivos que se van a detectar, no se pueden saber las características exactas del canal de búsqueda.

El número reducido de frecuencias de salto y la ralentización de salto en los canales de búsqueda facilita el proceso. El dispositivo que inicia el proceso de detección envía solicitudes de búsqueda a todas las frecuencias de salto y queda a la espera de recibir una respuesta. Este procedimiento se realiza a una velocidad superior, por lo que el dispositivo podrá abarcar todas las frecuencias de búsqueda en un plazo razonable.

Topología

Capas compatibles

Canal de paginación

Descripción

Características

Los dispositivos que utilizan sus canales de paginación permanecen pasivos hasta que reciben una solicitud de conexión de otros dispositivos Bluetooth. Esta solicitud se identifica con el código de acceso al canal de paginación. Los dispositivos participantes se conectarán una vez completado el proceso. Cuando la conexión se realiza correctamente, ambos dispositivos pasan al canal básico de la piconet en el que el responsable de iniciar la conexión hará las veces de maestro.

Para que un dispositivo se conecte a otro con tecnología Bluetooth, las solicitudes de conexión se envían a través del canal de paginación del receptor. Si el dispositivo responsable de iniciar el proceso de conexión (dispositivo de paginación) no conoce la fase del canal de paginación del receptor, tampoco podrá saber su frecuencia de salto. Por ello, envía solicitudes en cada frecuencia de salto del canal de paginación y queda a la espera de recibir una respuesta. En este proceso, la velocidad de salto es mayor para abarcar, así, todas las frecuencias de conexión en un plazo razonable.

El dispositivo de paginación podría tener datos del reloj del dispositivo Bluetooth al que van dirigidas las solicitudes de búsqueda, bien por un proceso de detección anterior o porque ambos dispositivos hayan participado en una piconet. Con estos datos, se puede predecir la fase del canal de paginación del dispositivo receptor, lo que facilita la sincronización del proceso y acelera el establecimiento de la conexión.

Topología

Capas compatibles

Enlaces físicos

En el sistema Bluetooth, un enlace físico es un concepto virtual sin representación en la estructura de paquetes transmitidos. Los campos del código de acceso, el reloj y la dirección del dispositivo maestro Bluetooth se utilizan para identificar los canales físicos. No obstante, en los paquetes de datos no hay ningún segmento que identifique directamente estos enlaces. En su defecto, estos enlaces se asocian con la comunicación lógica, ya que este tipo de comunicaciones se produce sólo en los enlaces físicos.

Las propiedades de algunos enlaces físicos se pueden modificar, como la potencia de transmisión. En cambio, otros enlaces físicos no pueden alterar sus propiedades. Cuando existe la posibilidad de realizar cambios, el protocolo LMP se utiliza para adaptar las propiedades que se van a modificar. El protocolo LMP opera en las capas superiores (a través de un enlace lógico), por lo que el enlace físico apropiado se identifica a partir del enlace lógico que transporta la señalización LMP.

Cuando una transmisión se difunde por varios enlaces físicos, se seleccionan parámetros adecuados para todos estos enlaces.

Volver al principio

Enlaces compatibles con el canal físico básico y adaptado de la piconet

Enlace físico activo

Un enlace físico activo tiene asociadas características de potencia de transmisión de radio en ambas direcciones. Las transmisiones de los dispositivos esclavos al maestro se realizan a través del enlace físico activo y la potencia de transmisión usada es característica del enlace para las comunicaciones en esa dirección. Las transmisiones que parten del maestro se pueden conducir a través de un enlace físico activo simple, cuando se comunica con un esclavo concreto, o a través de varios enlaces físicos cuando se comunica con un grupo de esclavos de la piconet. En las transmisiones punto a punto, el maestro utiliza una potencia de transmisión adaptada al enlace físico en cuestión. En las transmisiones multipunto, el maestro utilizará la potencia adecuada para comunicarse con todos los dispositivos.

Los enlaces físicos activos podrán cambiarse al modo de retención (hold) o de escucha reducida (sniff). De esta forma, se modifican los intervalos en los que el enlace físico está activo y admite tráfico. Las comunicaciones lógicas programadas no se ven afectadas por estos modos y siguen con su esquema predefinido. La comunicación lógica ACL predeterminada y otros enlaces sin características de programación están sujetos al cambio de modo del enlace físico activo.

Enlace físico en modo park o de espera

Para que un esclavo pase al modo de espera, se utiliza un procedimiento por el que el enlace dejará de estar activo. El maestro no podrá hacer que un esclavo entre en espera si éste tiene una comunicación lógica creada por el usuario y admitida por el enlace físico. Primero, hay que eliminar estas comunicaciones lógicas así como los canales L2CAP creados con estas comunicaciones. La comunicación lógica de difusión y las comunicaciones lógicas ACL predeterminadas no se consideran creadas por el usuario, por lo que no se eliminan explícitamente. Cuando se sustituye un enlace activo por un enlace en espera, la comunicación lógica ACL predeterminada queda eliminada. Los enlaces lógicos y los canales L2CAP compatibles permanecen, pero en modo suspendido. Así, estos enlaces y canales no podrán transferir la señalización ni los datos mientras falte el enlace activo.

Un esclavo en espera podrá pasar al modo activo realizando el proceso inverso. Para ello, el esclavo solicita al maestro que inicie el proceso desde una ventana de acceso. Una vez concluido, el enlace físico cambia al modo activo y se restaura la comunicación lógica ACL predeterminada. Los canales L2CAP que estaban en suspenso se asocian con la nueva comunicación lógica ACL predeterminada y se vuelven a activar.

Los enlaces en espera no admiten el control de la potencia de radio, ya que no hay ruta de retroalimentación desde los dispositivos esclavos en espera hasta el maestro de la piconet que pueda utilizarse para indicar la potencia de la señal recibida en el esclavo o para que el maestro mida la potencia de la señal emitida por éste. Las transmisiones se realizan a una potencia nominal en los enlaces en espera.

Los enlaces en espera utilizan el mismo canal físico que los enlaces activos asociados. Si un maestro gestiona una piconet con esclavos en espera, tanto en el canal físico básico como en el adaptado, deberá establecer una comunicación lógica de difusión del dispositivo esclavo en espera y las comunicaciones asociadas para cada uno de los canales físicos.

Un esclavo en espera podrá usar los periodos de inactividad de la comunicación lógica PSB para ahorrar energía o para realizar actividades en otros canales físicos que no pertenezcan a la piconet en la que está en modo de espera.

Enlaces compatibles con los canales físicos de búsqueda

Comunicaciones y enlaces lógicos

La cabecera del paquete o de la carga útil indica el tipo de comunicación lógica y la señalización en tiempo real (control del enlace). El protocolo LMP se encarga de la señalización de control que no requiere tiempos de respuesta en una única ranura.

La siguiente tabla enumera los tipos de comunicaciones lógicas, enlaces lógicos compatibles, enlaces y canales físicos admitidos y una breve descripción de la finalidad de la comunicación lógica.

Volver al principio

Los nombres de los enlaces y de las comunicaciones lógicas reflejan algunas de las definiciones usadas en la versión 1.1 del estándar Bluetooth, a fin de ofrecer cierto grado de familiaridad y continuidad con los términos. No obstante, estos nombres no siguen un esquema coherente, como se expone a continuación.

La clasificación de los enlaces se realiza a partir de un proceso de selección que engloba tres categorías.

Difusión

• Enlaces unidifusión: Los enlaces unidifusión se dan entre dos extremos. El tráfico se envía en ambas direcciones. Todos los enlaces de unidifusión dependen de una conexión, es decir, es necesario un proceso de conexión para que el enlace pueda utilizarse. Para los enlaces ACL predeterminados, la conexión es un paso implícito del proceso de paginación normal usado para crear piconets de comunicación directa (ad-hoc).
• Enlaces de difusión: Los enlaces de difusión se establecen entre un dispositivo emisor y uno o varios dispositivos receptores (incluso puede no haber ningún dispositivo receptor). El tráfico es unidireccional, por lo que sólo se envía información desde los dispositivos emisores a los receptores. Los enlaces de difusión no requieren conexión, es decir, no es necesario proceso alguno para crearlos y los datos pueden enviarse a través de ellos en cualquier momento. Este tipo de enlaces no es fiable y no existen garantías de que se recibirán los datos.

Patrón de programación y confirmación

La segunda categoría de enlaces tiene relación con el patrón de programación y confirmación, y hace referencia al tipo de tráfico admitido por el enlace, que puede ser síncrono, isócrono o asíncrono. La versión 1.2 del estándar Bluetooth no define enlaces isócronos específicos, aunque el enlace ACL predeterminado se puede configurar para funcionar de esta forma.

• Enlaces síncronos: Los enlaces síncronos ofrecen un método para asociar el reloj de la piconet a los datos transferidos. Para ello, se reserva una ranura con cierta periodicidad en el canal físico y se transmiten paquetes de un tamaño determinado a esos intervalos regulares. Estos enlaces son indicados para la transferencia de datos isócronos a una velocidad constante.
• Enlaces asíncronos: Los enlaces asíncronos proporcionan un método de transferencia de datos que no obedece a ninguna configuración de tiempo. Por lo general, se espera que los datos se retransmitan hasta que se reciban correctamente. Una vez recibidas, las entidades de datos se pueden procesar en cualquier momento sin hacer referencia alguna a cuándo se recibió la entidad anterior o siguiente del flujo. Esto es posible siempre que se conserve el orden de las entidades de datos.
• Enlaces isócronos: Los enlaces isócronos permiten transferir datos conforme a una configuración de tiempo. Los datos se seguirán transmitiendo hasta que se reciban o expiren. La velocidad de transferencia del enlace no tiene que ser constante, a diferencia de los enlaces síncronos.

Clase de datos

La última categoría de enlaces hace referencia a la clase de datos transportados por el enlace, bien datos de control (LMP) o del usuario. La categoría de datos del usuario se subdivide en datos L2CAP (en tramas) y datos de flujo (sin tramas).

• Enlaces de control: Los enlaces de control sólo se utilizan para la transferencia de mensajes LMP entre dos gestores de enlaces. Estos enlaces pasan inadvertidos por encima de la capa de la banda base y no pueden ser configurados, iniciados ni creados a instancia de las aplicaciones, a no ser que utilicen los servicios de conexión y desconexión que realizan estas operaciones de forma implícita. Los enlaces de control están siempre multiplexados en una comunicación lógica ACL con un enlace L2CAP equivalente. De acuerdo con las reglas del patrón ARQ, el tráfico en el enlace de control es preferente al del enlace L2CAP.
• Enlaces L2CAP: Los enlaces L2CAP se utilizan para transportar unidades PDU de la capa L2CAP, compatibles con el canal de señalización L2CAP (sólo en el enlace lógico ACL-U predeterminado), o los datos del usuario en tramas enviados a los canales L2CAP a instancia del usuario. Las tramas L2CAP enviadas a la banda base pueden ser mayores que los paquetes de banda base disponibles. Un protocolo de control de enlace incluido en el campo LLID conserva la semántica de inicio y continuación de tramas cuando éstas se transfieren fragmentadas al receptor.
• Enlaces de flujo: Los enlaces de flujo se utilizan para transferir datos del usuario sin trama interna que deba preservarse durante el envío de los mismos. Los datos perdidos pueden reemplazarse con otros de relleno en el receptor.

Conexión asíncrona (ACL)

Cuando un dispositivo se conecta al canal físico básico de la piconet, se crea la comunicación ACL predeterminada entre el maestro y el esclavo. El maestro de la piconet asigna a esta ACL predeterminada una dirección de transferencia lógica (LT_ADDR), que se empleará, además, para identificar el enlace físico activo cuando sea necesario. Por tanto, también podrá usarse como identificador de los componentes activos de la piconet.

La dirección LT_ADDR de la ACL predeterminada se vuelve a utilizar para las comunicaciones lógicas de conexión síncrona entre el mismo maestro y esclavo. Esto se debe a razones de compatibilidad con especificaciones Bluetooth anteriores. De este modo, la dirección LT_ADDR no puede identificar por sí sola la ACL predeterminada. No obstante, los paquetes usados en la comunicación ACL son distintos a los empleados en la comunicación lógica de conexión síncrona. Por tanto, la comunicación ACL lógica se puede identificar gracias al campo LT_ADDR de la cabecera y al campo del tipo de paquete.

La ACL predeterminada se empleará para la transferencia de datos isócronos previa configuración de la misma para desechar automáticamente paquetes una vez que han expirado.

Si la ACL predeterminada se elimina del enlace físico activo, también se suprimirán el resto de comunicaciones lógicas existentes entre el maestro y esclavo. En el supuesto de una pérdida imprevista de la sincronización con el canal físico de la piconet, el canal físico y todas las comunicaciones y enlaces lógicos dejarán de existir de inmediato.

Un dispositivo puede eliminar su ACL predeterminada y, por extensión, su enlace físico activo, y seguir sincronizado con la piconet. Este procedimiento es el que se conoce como “modo park o de espera” y no es otra cosa que un dispositivo sincronizado con la piconet que, al no tener enlace físico activo, pasa a un estado de espera dentro de ésta.

Cuando el dispositivo pasa a este estado de espera, los enlaces lógicos ACL predeterminados de la comunicación lógica ACL predeterminada siguen existiendo pero quedan suspendidos. La transferencia de datos a través de enlaces lógicos suspendidos no es posible. Cuando el dispositivo regresa al estado activo, se establece una nueva comunicación lógica ACL predeterminada, que podrá tener una dirección LT_ADDR distinta a la anterior. Asimismo, los enlaces lógicos en suspenso se vinculan a la nueva ACL predeterminada y vuelven a estar activos.

Conexión síncrona (SCO)

Cada enlace lógico SCO-S se transmite por una comunicación lógica SCO simple, a la que se asignará el mismo campo LT_ADDR que el designado para la comunicación lógica ACL entre los dispositivos. Por ello, para identificar el destino de un paquete recibido no basta el campo LT_ADDR. Puesto que los enlaces SCO se sirven de ranuras reservadas, el dispositivo debe emplear las direcciones LT_ADDR, los números de ranura (propiedad del canal físico) y los tipos de paquetes para identificar las transmisiones realizadas en estos enlaces.

La utilización del campo LT_ADDR de la ACL predeterminada para las comunicaciones lógicas SCO obedece al proceder de las aplicaciones heredadas de la versión 1.1 de la especificación Bluetooth. En esta versión anterior, el campo LT_ADDR se conocía como la dirección de componente activo y servía para identificar el componente de la piconet relacionado con cada transmisión. Esto no permitía ampliar fácilmente y activar, por tanto, más enlaces lógicos, por lo que se volvió a definir la finalidad de este campo para las nuevas funciones. Sin embargo, algunas funciones de la versión 1.1 del estándar Bluetooth no se ajustan convenientemente a la arquitectura de topología más formal.

Aunque hay ranuras reservadas para la comunicación SCO, es posible utilizar una de ellas para el tráfico procedente de otro canal con mayor prioridad. Esto podría ser necesario debido a la configuración QoS, o bien para enviar la señalización LMP a través de la ACL predeterminada cuando el ancho de banda del canal físico está totalmente ocupado por las comunicaciones SCO. Debido a que estas comunicaciones pueden transferir distintos tipos de paquetes a las comunicaciones ACL, el tipo de paquete, el número de ranura y el campo LT_ADDR sirven para identificar el tráfico SCO. En la especificación principal Bluetooth no se definen más capas de arquitectura que utilicen enlaces SCO. Los flujos de datos de 64 Kbps tienen una serie de formatos estándar, aunque se permite un flujo sin formato cuando es la aplicación la encargada de interpretar la codificación del flujo.

Conexión síncrona ampliada (eSCO)
La comunicación lógica de conexión síncrona ampliada (eSCO) es un enlace asimétrico, o bien un enlace asimétrico y de punto a punto, entre el maestro y un esclavo específico. La comunicación lógica eSCO reserva ranuras en el canal físico, por lo que puede considerarse una conexión de conmutación entre el maestro y el esclavo. Los enlaces eSCO permiten ampliar los enlaces SCO estándar mediante combinaciones más flexibles de tipos de paquetes y selecciones más diversas de contenido de datos e intervalos de ranura. De este modo, se pude disponer de una serie de valores de transferencia síncrona en bits.

Además, los enlaces eSCO, a diferencia de los SCO, pueden volver a transmitir los paquetes. Si es necesario retransmitir paquetes, el proceso se realiza en las ranuras siguientes a las reservadas. De lo contrario, las ranuras pueden utilizarse en otras operaciones de tráfico.

Cada enlace lógico eSCO-S es transportado por una comunicación lógica eSCO simple identificada por una dirección LT_ADDR exclusiva en la piconet durante el tiempo que tenga lugar esta comunicación. Los enlaces eSCO-S se crean mediante señalización LMP y siguen reglas de programación similares a las de los enlaces SCO-S.

En la especificación principal Bluetooth no se definen más capas de arquitectura que utilicen enlaces eSCO-S. En su lugar, las aplicaciones pueden utilizar el flujo de datos para el fin que pretendan, siempre que las características de comunicación del flujo sean adecuadas para los datos que se están transfiriendo.

Volver al principio

Difusión del dispositivo esclavo activo (ASB)

La comunicación lógica ASB no es, de por sí, fiable debido a la falta de proceso de confirmación. Para contrarrestarlo, cada paquete se transmite varias veces. Un número de secuencia idéntico ayuda a filtrar las retransmisiones en el dispositivo esclavo.

La comunicación lógica ASB se identifica por una dirección LT_ADDR reservada, que también utiliza la comunicación lógica PSB. Un esclavo activo recibirá tráfico en ambas comunicaciones lógicas y no podrá distinguirlas de inmediato. Ya que en la comunicación lógica ASB no hay tráfico LMP, un esclavo activo podrá ignorar los paquetes recibidos por el enlace lógico LMP de esta comunicación lógica. No obstante, los esclavos activos también reciben el tráfico L2CAP transmitido por la comunicación lógica PSB, y no pueden diferenciarlo del tráfico L2CAP enviado por la comunicación ASB.

En cada piconet se crea una comunicación ASB implícita y siempre hay una comunicación ASB asociada a cada canal físico básico y adaptado de esta red. Debido a las semejanzas entre los canales físicos básicos y adaptados de la piconet, los dispositivos esclavos no pueden distinguir el canal ASB utilizado para transmitir los paquetes. Este hecho incrementa la falta de fiabilidad de los canales ASB. Aunque, en realidad, no son menos fiables que la pérdida de paquetes.

Un dispositivo maestro puede optar por usar sólo uno de los dos canales ASB posibles (físico básico y adaptado), si con un determinado número de retransmisiones se puede llegar a ambos grupos de esclavos en el mismo canal ASB.

El canal ASB nunca se utiliza para transferir señales de control LMP ni L2CAP.

Difusión del dispositivo esclavo en espera (PSB)

La comunicación lógica PSB es más compleja que otras comunicaciones lógicas, ya que comprende un número de fases, cada una con una finalidad distinta: la fase de información de control para el enlace lógico LMP, la fase de información del usuario para el enlace lógico L2CAP y la fase de acceso para la señalización de la banda base. Las fases de información de control y difusión suelen excluirse entre sí porque sólo una de ellas puede realizarse en cada intervalo de balizas. Aun cuando no haya fase de información del usuario controlador, el maestro deberá transmitir un paquete en las ranuras de baliza para que los esclavos que están a la espera se puedan volver a sincronizar. La fase de acceso casi siempre está presente, a menos que se cancele mediante un mensaje de información de control.

La fase de información de control sirve para que el maestro informe a los esclavos en espera de posibles modificaciones en las características de la comunicación PSB y en las balizas. Mediante esta fase, el maestro también podrá solicitar al esclavo que cambie su estado para volver al modo activo. Esta información de control se incluye en los mensajes LMP transportados por el enlace lógico LMP. La fase de información de control también se utiliza cuando hay una fase de información del usuario que precisa más de un paquete de banda base.

Los paquetes de la fase de información de control siempre se transmiten por las ranuras de baliza del canal físico. La información de control se recoge en un único paquete DM1 y se repite en cada ranura de baliza dentro de cada intervalo de control. Si no hay información de control, puede que alguna fase de información del usuario utilice las ranuras de baliza. Ahora bien, si no se utiliza ninguna de estas fases, las ranuras de baliza servirán para el tráfico de comunicación lógica o para los paquetes nulos.

En la fase de información del usuario, el maestro envía paquetes L2CAP a los esclavos de la piconet. La información del usuario puede ocupar uno o varios paquetes de banda base. Si sólo ocupa uno, éste se repetirá en cada ranura de baliza de los canales de la piconet.

En caso contrario, los paquetes de información del usuario se transmitirán en las ranuras siguientes a la de la baliza (ventana de búsqueda de la difusión). Igualmente, las ranuras de baliza servirán para transmitir mensajes de las fases de información de control que contengan las características de sincronización de la ventana de búsqueda de la difusión. Este proceso es necesario para que los esclavos en espera permanezcan conectados al canal físico de la piconet y puedan recibir información del usuario.

La fase de acceso suele estar presente, a menos que se cancele mediante un mensaje de control transmitido en la fase de difusión de información de control. La ventana de acceso se compone de una secuencia de ranuras que siguen a la baliza. Para que un esclavo en espera pase a estar activo en la piconet, debe enviar una solicitud de acceso al maestro durante la aparición de la ventana de acceso. Los esclavos en espera reciben una dirección de solicitud de acceso (que no tiene por qué ser exclusiva) con la que se controla en qué instante de la ventana se debe realizar la solicitud de acceso.

La comunicación lógica PSB se identifica con una dirección LT_ADDR reservada de valor 0. La comunicación lógica ASB también utilizará esta dirección. Los esclavos en espera no suelen confundir el uso duplicado de la dirección LT_ADDR, ya que sólo están conectados al canal físico de la piconet cuando se produce una comunicación PSB.

Enlaces lógicos

Enlace lógico de control ACL (ACL-C)

Enlace lógico isócrono o asíncrono del usuario (ACL-U)

Enlaces lógicos síncronos o síncronos ampliados del usuario (SCO-S y eSCO-S)

Los enlaces lógicos SCO-S y eSCO no pueden transmitir datos isócronos de velocidad variable. Estos datos se transmitirán en enlaces lógicos ACL-U, que utilizan paquetes con una cabecera de carga útil. La tecnología Bluetooth tiene algunas limitaciones a la hora de transmitir datos isócronos de velocidad variable simultáneamente con datos fiables del usuario.

Canales L2CAP

Un identificador de canal (CID) indica los extremos del canal L2CAP a los clientes. El protocolo L2CAP asigna un identificador diferente a cada extremo de los canales L2CAP del dispositivo.

Los canales L2CAP se pueden configurar para ofrecer a la aplicación un valor de calidad de servicio (QoS) apropiado. El protocolo L2CAP asigna el canal al enlace lógico ACL-U.

Este protocolo admite canales de conexión y de grupo. Los canales de grupo se pueden asignar a un enlace lógico ASB-U o implementar como una transmisión iterada en cada componente de un enlace lógico ACL-U.

Además de la creación, configuración y eliminación de canales, el cometido principal del protocolo L2CAP es el multiplexado de las unidades de datos (SDU) desde los clientes del canal a los enlaces lógicos ACL-U. También realiza una programación sencilla seleccionando las SDU según su prioridad relativa.

El protocolo L2CAP puede ofrecer un control de flujo por canal en la capa L2CAP paralela. La aplicación seleccionará esta opción cuando se establezca el canal. Este protocolo ofrece, además, una detección de errores y retransmisión mejorada a fin de reducir la probabilidad de que se reciban errores sin detectar en la aplicación y de recuperar datos perdidos de los usuarios que la capa de la banda base haya desechado en el enlace lógico ACL-U.

Si existe una interfaz HCI, este protocolo también es necesario para segmentar convenientemente las unidades de datos L2CAP destinadas al búfer de la banda base, así como para transmitir una señal de paso basada en el procedimiento de control de flujo que tiene lugar en la interfaz HCI. Para ello, se procederá al envío de fragmentos de datos a la banda base cuando resulte posible. Esta acción podría afectar al algoritmo de programación.

Volver al principio