Dispositivo Bluetooth de bajo consumo (BLE)
La implementación del servicio de Vinculación rápida de Google (GFPS) para dispositivos BLE es compatible con la especificación principal de Bluetooth v4.2 o posterior.
El siguiente apéndice de la especificación de Vinculación rápida permitirá la compatibilidad con dispositivos de solo bajo consumo (LE) y de audio de bajo consumo (LEA) en GFPS.
Niveles de conformidad
A continuación, se explican las palabras clave “shall”, “must”, “will”, “should”, “may” y “can” que se mencionan en la especificación:
| Término | Descripción |
|---|---|
| shall | is required to: Se usa para definir requisitos. |
| debe | se usa para expresar: una consecuencia natural de un requisito obligatorio establecido previamente O una declaración de hecho indiscutible (una que siempre es verdadera, independientemente de las circunstancias). |
| will | it is true that: Solo se usa en declaraciones de hechos. |
| should | is recommended that: Se usa para indicar que, entre varias posibilidades, una se recomienda como particularmente adecuada, pero no es obligatoria. |
| mayo | is permitted to: Se usa para permitir opciones. |
| podemos | is able to: Se usa para relacionar una declaración de manera causal. |
Característica de vinculación basada en claves
Mensaje del Buscador al Proveedor
La solicitud sin procesar type 0x00 de la característica de vinculación basada en claves usa el bit 4 para indicar si el buscador admite la especificación de dispositivos BLE y el bit 5 para indicar si el buscador admite LE Audio.
| Octet | Tipo de datos | Descripción | Valor | ¿Es obligatorio? |
|---|---|---|---|---|
| 0 | uint8 |
Tipo de mensaje | 0x00 = Solicitud de vinculación basada en claves |
Obligatorio |
| 1 | uint8 |
Marcas
|
varía | Obligatorio |
| 2 - 7 | uint48 |
Puedes elegir una de estas opciones:
|
varía | Obligatorio |
| 8 - 13 | uint48 |
Dirección BR/EDR del buscador | varía | Solo se presenta si se establece el bit 1 o 3 de las marcas |
| n - 15 | Valor aleatorio (sal) | varía | Obligatorio |
Mensaje del proveedor al buscador
Cuando se establece el bit 4 de la solicitud, se puede usar el nuevo mensaje de respuesta type 0x02 para la característica de vinculación basada en claves para proporcionar opciones de vinculación adicionales al buscador.
| Octet | Tipo de datos | Descripción | Valor |
|---|---|---|---|
| 0 | uint8 |
Tipo de mensaje | 0x02 = Respuesta extendida de la vinculación basada en claves |
| 1 | uint8 |
Marcas
|
varía |
| 2 | uint8 |
Cantidad de direcciones del proveedor (en la versión actual, la cantidad es 1 o 2, ya que debemos modificar el modo de algoritmo de cifrado por bloques a AES-CTR si la cantidad es >= 3) |
varía |
| De 3 a 8 o de 3 a 14 |
|
varía | |
| 9-15 o 15 | Valor aleatorio (sal) | varía |
Un Proveedor que admita la especificación de dispositivos BLE debe leer los bits 4 y 5 para comprender las capacidades del Buscador.
- Cuando el bit 4 es 0, el proveedor debe ignorar el bit 5 y responder con el formato
type 0x01 - Cuando el bit 4 es 1,
- En el caso del proveedor que solo admite LE, debe responder con
type 0x02para indicar la preferencia de vinculación de LE. - En el caso del proveedor de modo dual, puede responder con
type 0x02para indicar la preferencia de vinculación de BR/EDR o LE.
- En el caso del proveedor que solo admite LE, debe responder con
- Para los casos de Proveedor de modo dual de LE Audio (LEA), consulta Ejemplo: Vinculación con un Proveedor de modo dual de LEA como referencia.
Característica de PSM (multiplexor de servicio de protocolo) del flujo de mensajes
Para admitir el flujo de mensajes en dispositivos BLE, la Vinculación rápida establecerá y mantendrá un canal L2CAP de BLE para enviar y recibir mensajes. El servidor L2CAP de Vinculación rápida debe implementar el control de flujo basado en créditos de LE.
Esta característica permite que el buscador lea el valor de PSM y, luego, establezca una conexión L2CAP segura con el valor de PSM.
| Característica del servicio de Vinculación rápida | Encriptado | Permisos | UUID |
|---|---|---|---|
| PSM del flujo de mensajes | Sí | Leer | FE2C1239-8366-4814-8EB0-01DE32100BEA |
| Octet | Tipo de datos | Descripción | Valor |
|---|---|---|---|
| 0 | uint8 |
Estado
|
varía |
| 1 - 2 | uint16 |
El valor de PSM debe estar en el rango entre 0x80 y 0xFF | varía |
Nota: En el caso de los TWS, hay dos componentes: principal y secundario. El rol de estos componentes es
intercambiable en ciertas condiciones. Suponiendo que A es el componente principal y B es el secundario, debido al agotamiento de la batería en el componente A, el componente B debe asumir el rol de componente principal, y esta situación se denomina role switch.
Después de role switch, si el proveedor no puede controlar el flujo de mensajes de la Vinculación rápida, debe desconectar de forma proactiva la conexión L2CAP existente. Luego, el buscador de Vinculación rápida puede restablecer la conexión del flujo de mensajes de L2CAP con el nuevo componente principal.
Característica adicional de las llaves de acceso
Esta característica es para proporcionar protección contra MITM en los componentes adicionales.
Protección contra MITM de miembros falsos de CSIS
La Vinculación rápida requiere protección contra MITM como parte del procedimiento de vinculación. Como CSIS no proporciona protección contra MITM, el diseño actual de FP para varios componentes debe extenderse para proporcionar protección contra MITM en los componentes adicionales.
Definición de característica
| Característica del servicio de Vinculación rápida | Encriptado | Permiso | UUID |
|---|---|---|---|
| Llave de acceso adicional | No | Lectura, escritura y notificación | FE2C123A-8366-4814-8EB0-01DE32100BEA |
Mensajes
El formato del mensaje se aplica a las operaciones de lectura, escritura y notificación.
Formato de datos encriptados
Los datos encriptados se envían con la conexión GATT de Vinculación rápida.
| Octet | Tipo de datos | Descripción | Valor |
|---|---|---|---|
| 0-15 | uint128 | Bloque de llave de acceso adicional encriptado | varía |
Formato de datos sin procesar
Después de desencriptar los datos encriptados con el secreto compartido, el formato es el siguiente:
| Octet | Tipo de datos | Descripción | Valor |
|---|---|---|---|
| 0 | uint8 | Tipo de mensaje | uno de
|
| 1-3 | uint24 | Llave de acceso de 6 dígitos | varía |
| 4-9 | uint48 | Dirección del componente de vinculación de destino | varía |
| 10 | uint8 | Código de estado, que solo se usa en la operación de lectura | Uno de los siguientes:
|
| 11-15 | Valor aleatorio (sal) | varía |
El componente principal (primer componente vinculado) es el puente entre el buscador de Vinculación rápida y los componentes de vinculación adicionales. La característica debe seguir los lineamientos que se indican a continuación:
- Cuando reciba una solicitud de escritura del buscador de Vinculación rápida, el proveedor deberá hacer lo siguiente:
- Establece la dirección del componente que se está vinculando
- Envía la clave de acceso al componente que se está vinculando.
- Establece el código de estado en Pendiente, 0x01
- Cuando reciba cualquier solicitud de lectura antes de recibir la clave de acceso del componente que se está vinculando, el proveedor deberá devolver un mensaje con
- Llave de acceso, cualquier valor
- Dirección del componente que se está vinculando
- Código de estado pendiente, 0x01
- Antes de que el proveedor envíe una notificación al buscador de Vinculación rápida, establece el resultado de la solicitud de lectura con
- Llave de acceso del componente que se está vinculando
- Dirección del componente que se está vinculando
- Código de estado de éxito, 0x00
- Si se produce un error irrecuperable en el lado del proveedor, establece el resultado
- Llave de acceso, cualquier valor
- Dirección del componente que se está vinculando
- Código de estado de error, 0x02
Consulta el diagrama 1 de MITM y el diagrama 2 de MITM para obtener más detalles.
Requisitos de los dispositivos con LE
LE Advertising
Para el modo detectable o no detectable, el Proveedor debe usar la RPA para anunciar los datos de Vinculación rápida.
Capacidad de vinculación
En el caso de los dispositivos compatibles con LE, el Buscador debe crear una vinculación con la conexión LE existente. Después de pasar la verificación de la vinculación basada en claves de la Vinculación rápida, el proveedor debe permitir la vinculación con la RPA y establecer la capacidad de E/S en DisplayYesNo para la verificación de la clave de acceso de la Vinculación rápida.
Requisitos de los dispositivos de LEA
Publicidad de LEA
En el caso de los dispositivos de modo doble, para el modo detectable, el proveedor debe anunciar los datos de Vinculación rápida con la dirección de identidad. En el modo no detectable, el Proveedor debe anunciar los datos de Vinculación rápida con RPA. Se recomienda usar el anuncio heredado (BT 4.2) para admitir dispositivos más antiguos y garantizar la retrocompatibilidad. Se requiere cambiar la IRK cada vez que se restablece la configuración de fábrica del dispositivo.
En el caso de los dispositivos que no son de modo doble: Para el modo detectable o no detectable, el proveedor debe usar anuncios extendidos (BT 5.0) con RPA para anunciar los datos de Vinculación rápida.
El anuncio conectable de LE que contiene datos del servicio de FP debe incluir el UUID de CAS de conformidad con los requisitos del Perfil de adaptador de Bluetooth (BAP 1.0.1) y del Perfil de audio común.
El proveedor puede indicar la capacidad de LEA incluyendo el UUID de CAS (0x1853) en los datos de servicio (tipo de anuncio 0x16) o en los UUID de clase de servicio de 16 bits (tipo de anuncio 0x02 o 0x03), independientemente del modo detectable.
Para los anuncios no detectables, si no hay suficiente espacio disponible en el anuncio heredado debido a la inclusión de datos de batería y SASS, es obligatorio incluir el UUID de CAS en la respuesta de análisis en ese caso.
Capacidad de vinculación de LEA
El buscador debe crear un vínculo con la conexión de LE existente. Después de pasar la verificación de la vinculación basada en claves de la Vinculación rápida, el proveedor de modo doble debe permitir la vinculación con la dirección de identidad y la RPA, mientras que el proveedor de modo no doble debe permitir la vinculación con la RPA y establecer la capacidad de E/S en DisplayYesNo para la verificación de la clave de acceso de la Vinculación rápida.
Canal de comunicación interno entre componentes
La conexión GATT existente se mantiene para realizar la protección contra MITM en los componentes adicionales. El componente vinculado principal debe controlar las entregas de mensajes entre el buscador de Vinculación rápida y los componentes restantes.
La comunicación interna se usa para Initial Pair y Subsequent Pair
- Cuando el procedimiento de vinculación basada en claves se pasa al componente principal, este debe enviar un mensaje para cambiar la capacidad de E/S de los componentes restantes.
- Cuando se complete la Vinculación rápida, el componente principal enviará un mensaje para restablecer la capacidad de E/S de los componentes restantes.
- Cuando se ejecuta el procedimiento de clave de acceso adicional, el componente principal debe controlar las entregas de claves de acceso entre el buscador de Vinculación rápida y los componentes restantes
Es hora de cambiar la capacidad de IO
- Cambiar la capacidad de E/S a DisplayYesNo cuando se aprueba el procedimiento de vinculación basada en claves
- Si el dispositivo tiene varios componentes, todos se deben establecer en DisplayYesNo.
- Una excepción en la que el proveedor no debe cambiar la capacidad de IO a DisplayYesNo es
Retroactive Pair, cuyo bit 3 de la solicitud de vinculación basada en claves se establece en 1, consulta Mensaje del buscador al proveedor
- Cambia la capacidad de E/S al parámetro de configuración predeterminado
- Vinculación inicial
- Si se desconecta la conexión LE, finaliza la sesión de Vinculación rápida.
- Después de que se vincule el dispositivo principal, si no hay ninguna solicitud de escritura de llave de acceso adicional en 15 segundos, finaliza la sesión de Vinculación rápida.
- Después de que se reciba la solicitud de escritura de clave de acceso adicional, si el componente que se está vinculando no se vincula en un plazo de 15 segundos, finaliza la sesión de Vinculación rápida.
- Después de que se vinculen todos los componentes, si no hay una solicitud de escritura de clave de cuenta en un plazo de 15 segundos, finaliza la sesión de Vinculación rápida.
- Después de que se reciba la solicitud de escritura de la clave de la cuenta, establece un tiempo de espera de 15 segundos para finalizar la sesión de Vinculación rápida.
- Vinculación posterior
- Si se desconecta la conexión LE, finaliza la sesión de Vinculación rápida.
- Después de que se vincule el dispositivo principal, si no hay una solicitud de escritura de clave de acceso adicional en un plazo de 15 segundos, finaliza la sesión de Vinculación rápida.
- Después de que se reciba la solicitud de escritura de clave de acceso adicional, si el componente que se está vinculando no se vincula en un plazo de 15 segundos, finaliza la sesión de Vinculación rápida.
- Cuando todos los componentes estén vinculados, finaliza la sesión de Vinculación rápida.
- Vinculación inicial
Ocultar indicación de la IU
Cuando los auriculares no estén listos para la vinculación, el proveedor usará type 0b0010 para establecer la indicación de ocultar la IU para los datos de la clave de cuenta y, así, indicarle al buscador que no muestre la IU de vinculación posterior (consulta Carga útil de publicidad: Datos de la cuenta de Vinculación rápida).
Requisitos de los dispositivos de audio LE
Requisitos de Bluetooth
Consulta Android, Recomendaciones de auriculares con LE Audio.
Compatibilidad con CTKD
Para el dispositivo de modo doble, la CTKD de LE a BR/EDR es obligatoria y está alineada con los requisitos de BAP.
Anuncio de Target
Un dispositivo periférico debe usar el anuncio segmentado para solicitar una conexión desde un dispositivo central vinculado. Los anuncios segmentados se definen en BAP y CAP para la administración de conexiones según la Tabla 8.4 (pág. 48/58) de CAP 1.0.
Compatibilidad con el servidor GATT EATT
EATT permite que el dispositivo central envíe varias transacciones de GATT en paralelo cuando el dispositivo está vinculado. En el caso del dispositivo que admite CSIP, aumentará el rendimiento de la conexión del perfil y, luego, iniciará el procedimiento de vinculación de CSIP para los otros auriculares.
Almacenamiento en caché sólido de GATT (muy recomendado)
Si el Proveedor no es un solo dispositivo, sino un conjunto coordinado con la implementación de CSIP, para reducir la cantidad de veces que se realiza el descubrimiento de servicios y acelerar la conexión, el Proveedor debe implementar el almacenamiento en caché de GATT definido en Bluetooth 5.1.
Requisitos de la Vinculación rápida
LE Advertising
En el modo detectable o no detectable, si el dispositivo tiene varios componentes, el componente principal anunciará los datos de la Vinculación rápida. Si el dispositivo no está listo para la vinculación posterior, el componente secundario puede anunciar datos de Vinculación rápida para funciones extendidas. Consulta Ocultar indicación de la IU.
Visibilidad del servicio de GATT
La base de datos de GATT debe ser la misma para todas las conexiones de GATT de transporte de LE. El servicio de LE Audio (0x184E) se debe incluir en la base de datos de GATT de la conexión de Vinculación rápida.
Ejemplo: Vinculación con un proveedor de modo doble de LEA
Situación 1: Cuando el buscador no admite LEA
El Proveedor debe tener retrocompatibilidad con el Buscador que no admite LEA.
Componentes
- Proveedor: A2DP/HFP/LEA
- Buscador: A2DP/HFP
Comportamiento esperado para la vinculación inicial y las vinculaciones posteriores
- El proveedor anuncia los datos del servicio de Vinculación rápida (0xFE2C) con la dirección de identidad (inicial) o la RPA (posterior).
- Usa la publicidad heredada
- El Buscador recibe el anuncio del Proveedor con la dirección de identidad para la vinculación inicial o la RPA para la vinculación posterior.
- El buscador envía una solicitud de vinculación basada en claves
- El bit 5 de la marca de la solicitud de vinculación basada en claves se establece en 0.
- El proveedor envía la respuesta de vinculación basada en claves con la dirección pública en uno de los siguientes casos:
- Si se usa el tipo de mensaje 0x01, la dirección debe ser pública.
- Si se usa el tipo de mensaje 0x02
- El bit 0 debe ser 0.
- El bit 1 debe ser 0.
- La dirección debe ser pública.
- El buscador crea un vínculo con el transporte BR/EDR
- La capacidad de IO se establece en DisplayYesNo para BR/EDR
- El buscador y el proveedor realizan el procedimiento de verificación de la llave de acceso de la Vinculación rápida.
Situación 2: Cuando el Seeker admite LEA
Componentes
- Proveedor
- Compatibilidad con A2DP, HFP y LEA
- Componente único
- Buscador
- SupportA2DP/HFP/LEA
Comportamiento esperado para la vinculación inicial y las vinculaciones posteriores
- El proveedor anuncia los datos del servicio de Vinculación rápida (0xFE2C) con la dirección de identidad (inicial) o la RPA (posterior).
- Usa la publicidad heredada
- El buscador envía una solicitud de vinculación basada en claves
- El bit 5 de la marca de la solicitud de vinculación basada en claves se establece en 1
- El proveedor envía la respuesta de vinculación basada en claves con el tipo de mensaje 0x02.
- El bit 0 debe ser 0.
- El bit 1 debe ser 1.
- La dirección es la dirección de identidad
- El Seeker crea un vínculo con la conexión de LE existente en el transporte de LE.
- La dirección de CTKD es de LE a BR/EDR
- La capacidad de IO se establece en DisplayYesNo para LE
- El buscador y el proveedor realizan el procedimiento de verificación de la llave de acceso de la Vinculación rápida.
Situación 3: Cuando el Seeker admite LEA y CSIP
Componentes
- Proveedor
- Compatibilidad con A2DP, HFP y LEA
- Varios componentes
- El componente principal es BR/EDR/LE
- El componente secundario es solo de LE
- Buscador
- Compatibilidad con A2DP, HFP y LEA
Comportamiento esperado para la vinculación inicial y las vinculaciones posteriores
- El componente principal anuncia los datos del servicio de Vinculación rápida (0xFE2C) con la dirección de identidad (inicial) o la RPA (posterior).
- Usa la publicidad heredada
- El buscador envía una solicitud de vinculación basada en claves al componente principal.
- El bit 5 de la marca de la solicitud de vinculación basada en claves se establece en 1
- El componente principal envía la respuesta de vinculación basada en claves con el tipo de mensaje 0x02.
- El bit 0 debe ser 0.
- El bit 1 debe ser 1.
- La dirección es la siguiente:
- La primera dirección es la dirección de identidad del componente principal.
- La segunda dirección es la dirección vinculable para el componente secundario, que también usa esta dirección para realizar el anuncio de CSIP.
- El Seeker crea un vínculo con el componente principal en la conexión de LE existente.
- La dirección de CTKD es de LE a BR/EDR
- La capacidad de IO se establece en DisplayYesNo para LE
- El Buscador crea un vínculo con el componente secundario
cuya dirección proviene de la respuesta extendida de vinculación basada en claves
- La capacidad de E/S debe ser DisplayYesNo; de lo contrario, se debe rechazar la solicitud de vinculación.
- El buscador y el proveedor realizan el procedimiento de protección contra MITM para vincular el componente secundario. El proveedor debe implementar ambas situaciones.
- El buscador espera hasta que se vincula con el componente secundario.
Diagrama secuencial para MITM
En esta sesión, se describe la secuencia del procedimiento de protección contra MITM.
Obtén la llave de acceso del componente que se vincula por notificación

Obtén la llave de acceso del componente que se vincula por lectura

Problema conocido
La FP para LEA se optimizó para funcionar con Android V (Android 15).
Por el contrario, tuvimos muchos problemas con los auriculares que admiten LEA, pero que no tienen la implementación correcta de Vinculación rápida a través de LEA (es decir, solo Vinculación rápida a través de Classic). Específicamente y, por ejemplo, cuando la RPA del proveedor no se genera con la clave de resolución de identidad (IRK) correcta y no se puede resolver la dirección. Si bien no pudimos probar una lista completa de configuraciones de auriculares, nuestras pruebas limitadas revelaron varios problemas, como la falta de visualización de las notificaciones de batería de los auriculares, la falta de funcionalidad de cambio de audio (SASS), fallas generalizadas de vinculación inicial y posterior, y mucho más.
Por lo tanto, recomendamos que los socios implementen la especificación de LEA de Vinculación rápida para los dispositivos nuevos y los existentes en el campo (a través de actualizaciones inalámbricas) que admitan modos duales.