Arquitectura de Bluetooth desde cero

La arquitectura de Bluetooth determina cuáles son las funciones que deben estar operativas en una implementación y cómo se deben organizar

Bluetooth está compuesto por múltiples tecnologías, protocolos y elementos. Su relación y cómo se utilizan es compleja, siendo una barrera de entrada a la hora de iniciarse en el estudio de esta tecnología. Este artículo pretende servir como introducción de la arquitectura de un dispositivo de comunicaciones Bluetooth y aclarar qué papel juegan cada uno de sus componentes.

La arquitectura descrita en el extenso estándar de Bluetooth dicta qué funciones deben existir en una implementación y cómo deben estar organizadas, por lo que conocerla facilita en gran medida la comprensión del funcionamiento de un dispositivo, de una base de código o, en general, de Bluetooth como tecnología.

El estándar, sin embargo, tal y como está estructurado no es la mejor documentación de estudio para iniciarse de una manera fácil y sencilla en la tecnología Bluetooth, por lo que se hace necesario una documentación introductoria con intención didáctica sobre este tema.

Este artículo se centrará en explicar tres puntos fundamentales:

• La separación de la arquitectura en dos componentes principales: host y controller.
• La pila de protocolos.
• La arquitectura de Bluetooth en detalle y dónde se encuentra implementada cada capa de la pila de protocolos

Pero antes, es necesario hablar de BR/EDR y LE.

Versiones de Bluetooth: BR/EDR y LE

Antes de entrar en los componentes arquitectónicos de Bluetooth, es conveniente tratar una diferenciación que atraviesa toda la arquitectura, ya que existen dos versiones de Bluetooth disponibles:

• BR/EDR: También llamado Bluetooth Classic, al ser el primero en aparecer.
• LE: Bluetooth Low Energy, nacido con la intención de ser incorporado en dispositivos con bajo consumo energético.

Bluetooth BR (Basic Rate) es la primera versión de Bluetooth, y más tarde fue extendido con EDR (Extended Data Rate), que permite una tasa de transmisión de datos máxima mayor.

Tasa máxima de transferencia en Bluetooth Basic Rate (BR):

• 1 Mbps (megabit por segundo)

Tasas máximas de transferencia en Bluetooth Extended Data Rate (EDR):

• 2 Mbps con EDR 2
• 3 Mbps con EDR 3

BR y EDR son totalmente compatibles, por lo que se considera un único sistema y se le denomina BR/EDR.

Bluetooth LE (Low Energy) se desarrolló después como una alternativa de bajo consumo para dispositivos más simples y baratos, inicialmente con una tasa de transmisión de datos menor a la de BR/EDR aunque en las últimas versiones del protocolo se han incrementado hasta casi igualar las de BR/EDR.

• Tasas máximas de transferencia en Bluetooth Low Energy (BLE):
  • Bluetooth 4.0 y 4.1: 1 Mbps
  • Bluetooth 4.2: 1 Mbps (mejora en la eficiencia de datos y la capacidad de paquetes más grandes)
  • Bluetooth 5.0 y 5.1: 2 Mbps (doblada respecto a versiones anteriores)
  • Bluetooth 5.2: 2 Mbps (mejoras en términos de capacidad de datos, eficiencia y alcance)
  • Bluetooth 5.3 y 5.4: 2 Mbps (mejoras que aumentan la eficiencia, seguridad y funcionalidad)

Aunque ambos tiene un funcionamiento similar a la hora de descubrir dispositivos y establecer conexiones, los mecanismos con los que trabajan son muy diferentes e incompatibles entre sí, por lo que se pueden ver como tecnologías diferentes con nombres similares.

Separación entre host y controller

Un dispositivo Bluetooth está compuesto por dos tipos de elementos: un host y uno o varios controllers.

• Host. Sirve como interfaz para las aplicaciones y el sistema operativo, e implementa los protocolos de las capas más altas, es con lo que se comunican las aplicaciones del OS para realizar tareas con Bluetooth.
• Controller. Implementa las funciones y protocolos más básicos de la pila y da soporte a las diferentes tecnologías de Bluetooth: BR/EDR y LE. Un controlador puede soportar BR/EDR, LE o ambos de forma combinada.

Se puede ver al host como el ordenador ejecutando Windows al que ya le llegan los paquetes Bluetooth ya procesados y se encarga de comunicarse con las aplicaciones de usuario, mientras que el controller sería el dongle USB Bluetooth, que ejecuta un firmware, y que realiza las tareas a más bajo nivel, encargándose de las operaciones de capturar paquetes, anunciar el dispositivo, sincronización de canales, etc. Host y controller se comunican entre sí utilizando el protocolo de envío de paquetes HCI (Host Controller Interface), que permite al host enviar acciones a un controller y recibir eventos en respuesta, controlando a alto nivel el estado de las comunicaciones.

Relación entre host y controladores

Un controller puede soportar BR/EDR, LE o una combinación de ambos, mientras que el host es el mismo para ambas tecnologías. Esto se debe a que las diferencias fundamentales se encuentran en los protocolos de más bajo nivel de la pila (los protocolos físicos y de acceso al medio), cada uno de ellos implementa su propio grupo de comandos y paquetes, mientras que los protocolos de las capas más altas, implementados en el host, no son exclusivos de BR/EDR o de LE y son comunes entre ambos. Por esto, un host puede hablar con cualquier controller en el mismo lenguaje, es el controller el que se tiene que encargar de implementar el soporte de BR/EDR y BLE y es agnóstico del host.

Una consecuencia interesante de la separación en host y controller es que el host no tiene información de todo lo que ocurre en el controller, sólo de lo que el controller le informa mediante paquetes HCI. Esto es especialmente relevante porque, en sistemas complejos, como PCs y teléfonos inteligentes, el host generalmente esta implementado como parte del sistema operativo mientras que el controller se encuentra en el firmware de un periférico hardware separado, del que el sistema operativo no tiene el control directo. Es decir, que, generalmente, un usuario, que sólo interactúa con el host, no tendrá el control ni el conocimiento de lo que ocurre en las capas implementadas en el controller, al ser este un elemento aislado, habitualmente con firmware privado del fabricante.

Pila de protocolos de Bluetooth

El estándar define una pila general de Bluetooth dividida en capas y subcapas. Cada capa implementa un conjunto de funciones relacionadas entre sí y que son necesarias para la capa inmediatamente superior, y, para ello, utiliza las funciones implementadas por la capa directamente inferior. Así, las capas inferiores implementan las funciones a mas bajo nivel, como la interacción con el hardware, y las capas superiores implementan las funciones más cercanas a la aplicación de usuario, como gestionar el descubrimiento de dispositivos, realizar conexiones, etc.

Un paquete de datos Bluetooth es recibido por las capas inferiores, que interpretan el contenido y envían el resultado a las capas superiores, hasta llegar a las capas de usuario.

Capa física de Bluetooth

La capa física en una conexión Bluetooth es la encargada de la transmisión real de datos a través del medio de comunicación, es decir, el aire. Esta capa define los aspectos relacionados con la modulación de señales, las frecuencias de operación y el manejo del espectro de radiofrecuencia. Su función principal es establecer y mantener el enlace físico entre dispositivos Bluetooth, permitiendo la transferencia de bits de datos a través de ondas de radio. En términos simples, es la base que permite que los dispositivos se “escuchen” y “hablen” entre sí mediante señales inalámbricas.

Por ejemplo, es la encargada de determinar en qué frecuencias se emite, la duración de los mensajes y la sincronización en la transmisión de mensajes, para evitar que dos dispositivos transmitan simultáneamente.

Esta capa reparte sus funciones en tres subcapas:

• Transporte Físico: Se encarga de empaquetar los datos y transmitirlos mediante ondas de radio.
• Canal Físico: Define los parámetros de frecuencia y sincronización para el envío de paquetes. Existen distintos tipos de canales físicos, cada uno con diferentes parámetros.
• Enlace Físico: Es una sesión de comunicación establecida entre dispositivos que utiliza un canal físico específico

Capa lógica de Bluetooth

La capa lógica en una conexión Bluetooth es responsable de gestionar cómo se organizan y transmiten los datos entre dispositivos. Esta capa se encarga de funciones como la multiplexación de enlaces, el control de flujo y el manejo de errores. En esencia, la capa lógica asegura que los datos se envíen y reciban de manera ordenada y eficiente, permitiendo una comunicación fiable y coordinada entre los dispositivos Bluetooth.

La capa lógica garantiza a las capas superiores (L2CAP) la estabilidad y fiabilidad de las comunicaciones, y controla aspectos como el tipo de flujo de datos (síncrono o asíncrono), la numeración de los paquetes, la confirmación de recepción de paquetes (mensajes de ack) o la repetición de paquetes perdidos. La capa lógica crea “enlaces lógicos”, que son sesiones de comunicación que garantizan unas condiciones de comunicación concretas entre los dispositivos. Existen diferentes tipos de enlace lógico que proveen requisitos de comunicación diferentes.

Un ejemplo de las funciones de la capa lógica es el enlace lógico ACL (Asynchronous Connection-oriented Link, se utiliza tanto en BR/EDR. como en LE y provee una comunicación con características específicas:

• Comunicación punto a punto: Se comunican sólo dos dispositivos entre sí, no en broadcast.
• Comunicación fiable: Se garantiza la recepción de los paquetes mediante mecanismos como la confirmación de recibo y la repetición del envío de los paquetes perdidos.
• Comunicación bidireccional: Ambos extremos de la comunicación pueden enviar y recibir datos.
• Comunicación orientada a conexión: Hay un proceso de establecimiento de sesión y cierre de sesión, y no se pueden enviar datos fuera de esta.
• Comunicación asíncrona: Los datos se envían en paquetes separados por esperas arbitrarias, al contrario que en la comunicación síncrona, en la que se envía un flujo constante de datos sin esperas intermedias.

Este tipo de enlace se utiliza en BR/EDR para transmitir tramas de control y paquetes, en LE para un 90% de todo el tráfico.

Existen otros tipos de enlaces diferentes para transmitir datos en broadcast o flujos (streams) continuos de datos.

Enlaces:

• SCO (Synchronous Connection-Oriented Link): En Bluetooth BR/EDR para la transmisión de datos de voz en tiempo real.
• eSCO (Extended Synchronous Connection-Oriented Link): evolución de SCO mejorando la calidad del audio.
• LE Coded PHY (Long Range): En Bluetooth LE para mejorar el alcance y la robustez de la conexión de Broadcast
• Isochrone: Introducido en Bluetooth 5.2, utilizado para la transmisión de audio LE (LE Audio).

Capa L2CAP en Bluetooth

La capa L2CAP (Logical Link Control and Adaptation Protocol) permite enviar datos de diferentes aplicaciones a través de un mismo enlace lógico tipo ACL. Proporciona una interfaz común para todos los protocolos de nivel superior en la pila (denominados “de aplicación”), mediante la creación de “canales L2CAP”.

Un canal L2CAP (no confundir con canales físicos) es una abstracción con la que se transmiten datos entre los dos extremos de una comunicación Bluetooth, para no tener que lidiar con los aspectos de los enlaces lógicos, enlaces físicos, etc. Se puede entender como un túnel a nivel de aplicación.

Es un protocolo fundamental que encapsula casi todos los tipos de comunicación en Bluetooth, a excepción de los datos en stream y de broadcast que utilizan otros enlaces lógicos.

En diferentes secciones del estándar se hace referencia al concepto “conexión” y, aunque no hay una definición exacta e inequívoca de lo que significa, se puede deducir que una conexión en Bluetooth se refiere al establecimiento de una sesión de comunicación entre dos o más dispositivos, estableciendo para ello un enlace físico, un enlace lógico y un canal L2CAP.

Relación entre la arquitectura física y la pila de protocolos

Al analizar la arquitectura física de Bluetooth en detalle y relacionarla con la pila de protocolos, se puede observar que las funciones de BR/EDR y LE se implementan de manera diferenciada dentro de la misma estructura. Esto implica que cada uno tiene sus propias características y mecanismos específicos para gestionar la comunicación.

Sin gestión del host y dentro del controller se implementan:

• La capa de transporte física (PHY) en BR/EDR y LE es responsable del empaquetado de los datos, así como de su emisión y recepción a través de la antena en la subcapa de transporte físico.
• El baseband en BR/EDR agrupa muchas de las funciones de Bluetooth y se encarga de la gestión de los canales y enlaces físicos, además de la capa lógica.
• El protocolo LMP (Link Manager Protocol) es un protocolo de control que establece y gestiona el estado de las conexiones entre dos dispositivos. Esto incluye el establecimiento de la conexión, la autenticación, el cifrado, el mantenimiento del enlace y la desconexión, abarcando tanto los enlaces físicos como los lógicos.

Mediante HCI el host puede indicar al controller que inicie o detenga los procedimientos a alto nivel, pero los detalles son gestionados internamente en el controller mediante LMP. Las funciones de seguridad también están delegadas en el controller, y el host únicamente interviene cuando se le solicita material criptográfico como claves o datos sobre el dispositivo remoto y la conexión.

Una estructura similar se encuentra en LE, donde el componente denominado “capa de enlace” (Link Layer) gestiona todos los aspectos relacionados con los canales y enlaces físicos, así como los enlaces lógicos. En este caso también existe un protocolo para gestionar y negociar el estado de una conexión, que se denomina LLCP (Link Layer Control Protocol), pero, a diferencia de LMP, LLCP no controla las funciones de seguridad de la conexión.

Estas funciones de seguridad en LE están implementadas en un protocolo superior a L2CAP, llamado SMP (Security Manager Protocol) . Por otro lado, LLCP no se menciona tan frecuentemente como LMP, ya que usualmente se hace referencia de manera más general a LL (Link Layer Protocol).

El resto de las capas, las que se encuentran implementadas en el host, se encapsulan en L2CAP o utilizan alguno de los enlaces lógicos directamente.

La interfaz HCI, que comunica el host con el controller, permite enviar comandos (HCI commands) y recibir eventos (HCI events) además de encapsular paquetes L2CAP o datos de protocolos de aplicación destinados a los enlaces lógicos, pero no es estrictamente necesario para la implementación de un dispositivo Bluetooth. HCI comunica al host y al controller en sistemas complejos, en los que estos se encuentran en elementos hardware separados y necesitan una interfaz de comunicación estándar. Sin embargo, ambos componentes pueden implementarse en un mismo dispositivo hardware (por ejemplo, en un mismo SoC), de manera que esta interfaz de comunicación no sea necesaria y que puede ser sustituida por una API de programación más simple.

Conclusiones

La complejidad de los protocolos y los elementos de Bluetooth dificulta enormemente el estudio de la tecnología, pero conociendo los elementos fundamentales que la conforman, el resto de las funcionalidades y conceptos suelen ser más fáciles de comprender.

Tras esta introducción a los conceptos básicos de la tecnología, leer documentación, código o el mismo estándar de Bluetooth resultará mucho más sencillo, y será mucho más fácil entender qué papel juega cada elemento dentro de la tecnología.

---