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 Bluetooth Core v4.2 o una versión posterior.

El siguiente anexo a la especificación de Vinculación rápida permitirá que se admita para dispositivos de audio de bajo consumo (LEA) y bajo consumo (LEA) en GFPS

Niveles de cumplimiento

A continuación, se explican las palabras clave “deberá”, “debe”, “deberá”, “debe”, “podría” y “puede” que se mencionan en la especificación:

Término	Descripción
deberá	se requiere para: Se usa para definir los requisitos.
imprescindible	se utiliza para expresar: una consecuencia natural de un requisito obligatorio establecido anteriormente O una declaración de hecho indiscutible (que siempre es verdadera, independientemente de las circunstancias).
la	es cierto y solo se usan como verdades absolutas.
should	se recomienda que: Se usa para indicar que, entre varias posibilidades, uno se recomienda como particularmente adecuado, aunque no obligatorio.
mayo	se permite: Se usa para permitir opciones.
lata	puede: Se usa para relacionar un enunciado 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 Seeker admite la especificación de dispositivos BLE y usa el Bit 5 para indicar si el Seeker admite LE Audio.

Octeto	Tipo de datos	Descripción	Valor	¿Obligatorio?
0	uint8	Tipo de mensaje	0x00 = Solicitud de vinculación basada en claves	Obligatorio
1	uint8	Marcas Bit 0 (MSB): obsoleto e ignorado por Seeker. Bit 1: 1 si el Buscador solicita que el Proveedor inicie la vinculación y esta solicitud contiene la dirección BR/EDR del Buscador. De lo contrario, 0. Bit 2: 1 si el Buscador solicita que el Proveedor notifique el nombre existente. De lo contrario, 0. Bit 3: 1 si es para escribir la clave de cuenta de forma retroactiva. De lo contrario, 0. Bit 4: 1 si el Seeker admite la especificación de dispositivos BLE. De lo contrario, 0. Bit 5: 1 si el Seeker admite audio de bajo consumo. De lo contrario, 0. Los bits 6 a 7 están reservados para uso futuro y deben ignorarse.	varía	Obligatorio
Entre 2 y 7	uint48	Puedes elegir una de las siguientes opciones: Dirección BLE actual del proveedor Dirección de identidad del proveedor	varía	Obligatorio
8 a 13	uint48	Dirección en BR/EDR del solicitante	varía	Presente solo si se establecieron los bits 1 o 3 de las marcas
n: 15		Valor aleatorio (sal)	varía	Obligatorio

Mensaje del proveedor al buscador

Cuando se configura el bit 4 de la solicitud, el nuevo mensaje de respuesta type 0x02 para La característica de vinculación basada en claves se puede usar para proporcionar una vinculación adicional opciones al Buscador.

Octeto	Tipo de datos	Descripción	Valor
0	uint8	Tipo de mensaje	0x02 = Respuesta extendida de vinculación basada en claves
1	uint8	Marcas Bit 0 (MSB): 1 si el proveedor es un dispositivo solo de LE, de lo contrario, 0. Si el bit 0 se fija en 1, el buscador supondrá que el bit 1 está establecido en 1. Bit 1: 1 si el proveedor prefiere la vinculación LE; de lo contrario, 0. Bit 2: 1 si el tipo de dirección de la segunda dirección es Al azar, 0 si es Pública. Los bits 3 a 7 están reservados para uso futuro y deben ignorarse.	varía
2	uint8	Cantidad de direcciones del proveedor (en la versión actual, el número es 1 o 2 porque necesitamos modificar el modo de cifrado por bloques a AES-CTR si el número es >= 3)	varía
De 3 a 8 o de 3 a 14		La primera dirección debe ser la dirección de identidad de la principal y debe vincularse si se prefiere la vinculación BR/EDR. La segunda dirección debe ser la dirección de la secundaria si la secundaria está disponible.	varía
9-15 o 15		Valor aleatorio (sal)	varía

Un proveedor compatible con la especificación de dispositivo BLE debe leer el bit 4 y el bit 5. para entender 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 usa LE, responderá con type 0x02 para indicar LE de unión tradicional.
  • En el caso del proveedor de modo dual, puede responder con type 0x02 para indicar Preferencia de vinculación BR/EDR o LE.
• Para casos de proveedores de modo dual de LE Audio (LEA), consulta Ejemplo: Vinculación con el proveedor de modo dual de LEA como referencia

Característica de PSM (multiplexor de servicios de protocolo) de transmisión de mensajes

Para admitir el flujo de mensajes en dispositivos BLE, la Vinculación rápida establecerá y mantienen un canal BLE L2CAP para enviar y recibir mensajes. Vinculación rápida El servidor L2CAP deberá implementar el control de flujo basado en créditos de LE.

Esta característica permite que el Seeker 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 de transmisión de mensajes	Sí	Leer	FE2C1239-8366-4814-8EB0-01DE32100BEA

Octeto	Tipo de datos	Descripción	Valor
0	uint8	Estado 0x00 = Desconocido El buscador de FP volverá a intentarlo varias veces 0x01 = Listo para conectar 0x02 = No disponible FP Seeker no usará este componente para conectarse esta vez	varía
1 - 2	uint16	El valor de PSM debe estar en el intervalo entre 0x80 y 0xFF	varía

Nota: En el caso de TWS, existen dos componentes: primarios y secundarios. Los roles de estos componentes intercambiables en ciertas condiciones. Suponer que A es el componente principal y que B es componente secundario, debido al agotamiento de la batería del componente A , el componente B necesita para asumir la función del componente principal, y esta situación se llama role switch.

Después de role switch, si el proveedor no puede manejar el flujo de mensajes de Vinculación rápida, debe desconectar proactivamente el conexión L2CAP existente. El buscador de Vinculación rápida puede restablecer L2CAP de transmisión de mensajes con el nuevo componente principal.

Característica adicional de la llave de acceso

Esta característica es para proporcionar protección contra MITM en los beneficios o los componentes de la solución.

Protección contra MITM para miembros falsos del CSIS

La Vinculación rápida requiere protección MITM como parte del procedimiento de vinculación. Como CSIS no ofrece protección contra MITM, el diseño actual de FP para varios componentes deben extenderse para brindar protección contra MITM en los o los componentes de la solución.

Definición de la característica

Característica del servicio de vinculación rápida	Encriptado	Permiso	UUID
Llave de acceso adicional	Sí	Leer,escribir,notificar	FE2C123A-8366-4814-8EB0-01DE32100BEA

Mensajes

El formato del mensaje se aplica a operaciones de lectura, escritura y notificación.

Formato de datos encriptados

Los datos encriptados se envían usando la conexión GATT de Vinculación rápida.

Octeto	Tipo de datos	Descripción	Valor
0-15	uint128	Bloqueo de llave de acceso adicional encriptado	varía

Formato de datos sin procesar

Después de desencriptar los datos encriptados con un secreto compartido, el formato es el siguiente

Octeto	Tipo de datos	Descripción	Valor
0	uint8	Tipo de mensaje	uno de 0x00 = Llave de acceso del buscador 0x01 = Llave de acceso del proveedor
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 utiliza en la operación de lectura	Uno de 0x00 = Éxito 0x01 = Pendiente. Reintento del buscador de FP hasta que se agote el tiempo de espera 0x02 = Falla. Reintento de detención del buscador de FP
11-15		Valor aleatorio (sal)	varía

El principal (primer componente vinculado) es el puente entre la Vinculación rápida. Seeker y los componentes de unión adicionales. La característica debe sigue los lineamientos:

• Al recibir una solicitud de escritura del Buscador de Vinculación rápida, el Proveedor deberá
  • Establecer la dirección del componente que se enlaza
  • Envía la llave de acceso al componente que se vincula
  • Establecer el código de estado en Pendiente, 0x01
• Cuando se recibe una solicitud de lectura antes de recibir la llave de acceso del componente unido, el Proveedor devolverá un mensaje con
  • Llave de acceso, cualquier valor
  • Dirección del componente que se vincula
  • 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 para la solicitud de lectura con
  • Llave de acceso del componente que se vincula
  • Dirección del componente que se vincula
  • Código de estado de éxito, 0x00
• Si se produce un error irrecuperable del lado del proveedor, establece el resultado.
  • Llave de acceso, cualquier valor
  • Dirección del componente que se vincula
  • Código de estado de falla, 0x02

Consulta el diagrama 1 de MITM y Para obtener más detalles, consulta el diagrama 2 de MITM.

Requisitos de los dispositivos de bajo consumo

LE Advertising

En el modo detectable o el modo no detectable, el Proveedor deberá usar la RPA para lo siguiente: anunciar datos de FastPair.

Capacidad de vinculación

En el caso de los dispositivos compatibles con LE, el Seeker debe crear un vínculo con el Conexión de bajo consumo. Después de aprobar la verificación de Vinculación rápida basada en claves, el El Proveedor deberá permitir la vinculación con RPA y establecer la capacidad de IO en DisplayYesNo para verificar la llave de acceso con Vinculación rápida.

Requisitos de los dispositivos de LEA

LEA Advertising

Para dispositivos de modo dual: Para el modo detectable, el Proveedor debe anunciar datos de Vinculación rápida con Identity. web. En el caso del modo no detectable, el Proveedor deberá anunciar los datos de Vinculación rápida con el RPA. Es muy recomendable usar publicidad heredada (BT 4.2) para admitir y dispositivos compatibles con versiones anteriores. Es necesario cambiar IRK cada vez que se restablece la configuración de fábrica del dispositivo.

Para dispositivos que no están en modo dual: Para el modo detectable o el modo no detectable, el proveedor debe usar publicidad (BT 5.0) con RPA para publicitar datos de FastPair.

El anuncio conectable de LE que contiene datos del servicio de FP debe incluir UUID de CAS de conformidad con el el perfil del adaptador de Bluetooth (BAP 1.0.1) y Perfil de audio común un requisito de seguridad. Para anuncios no detectables si no hay suficiente espacio disponible en los anuncios heredados debido a la inclusión de datos de batería y SASS, es obligatorio incluir un UUID de CAS en la respuesta del análisis en ese caso.

Capacidad de vinculación LEA

El Seeker debe crear un enlace con la conexión de LE existente. Después de aprobar Verificación de la vinculación basada en claves de Vinculación rápida, el proveedor de modo dual debe permitir la vinculación con la dirección de identidad y el RPA, mientras que el Proveedor de modo no doble deberá vincular con el RPA y configurar la capacidad de IO en DisplayYesNo para la vinculación rápida Verificación con llave de acceso.

Canal de comunicación interna entre componentes

Se conserva la conexión GATT existente para brindar protección MITM en el componentes adicionales. El componente vinculado principal debe administrar entre el Buscador de Vinculación rápida y sus componentes restantes.

La comunicación interna se usa para Initial Pair y Subsequent Pair.

• Cuando el procedimiento de vinculación basada en claves pasa en el componente principal, el principal debe enviar un mensaje para cambiar la capacidad de E/S de los componentes
• Cuando finalice la Vinculación rápida, el componente principal enviará un mensaje para restablecerla Capacidad de E/S de los componentes restantes
• Cuando se ejecuta el procedimiento de llave de acceso adicional, el componente principal debe manejar entregas de llaves de acceso entre el Buscador de Vinculación rápida y sus componentes restantes

Es hora de cambiar la capacidad de E/S

• Cambiar la capacidad de IO a DisplayYesNo cuando se aprobó el procedimiento de vinculación basada en claves
  • Si el dispositivo tiene varios componentes, todos deben configurarse en DisplayYesNo
  • El Proveedor deberá la capacidad de IO a DisplayYesNo es Retroactive Pair, cuyo bit 3 de Vinculación de claves se establece en 1, consulta Mensaje del buscador al proveedor
• Cambia la capacidad de E/S a la configuración predeterminada
  • Vinculación inicial
    • Si se desconecta la conexión de LE, finaliza la sesión de Vinculación rápida
    • Después de que se vincula la principal, si no hay llaves de acceso adicionales de escritura en 15 segundos, finaliza la sesión de Vinculación rápida
    • Después de que se recibe una solicitud adicional de escritura de la llave de acceso, si el componente la vinculación no se hace en 15 segundos, finaliza la sesión de Vinculación rápida
    • Cuando todos los componentes están unidos, si no hay escritura de clave de cuenta en 15 segundos, finaliza la sesión de Vinculación rápida
    • Luego de recibir la solicitud de escritura de clave de cuenta, establece el tiempo de espera de 15 segundos en finalizar sesión de Vinculación rápida
  • Vinculación posterior
    • Si se desconecta la conexión de LE, finaliza la sesión de Vinculación rápida
    • Después de que se vincula la principal, si no hay llaves de acceso adicionales de escritura en 15 segundos, finaliza la sesión de Vinculación rápida
    • Después de que se recibe una solicitud adicional de escritura de la llave de acceso, si el componente la vinculación no se hace en 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

Ocultar indicación de IU

Cuando los auriculares no estén listos para la vinculación, el Proveedor debe usar type 0b0010 para configurar la opción de ocultar la indicación de la IU para los datos clave de la cuenta a fin de indicarle al buscador que no muestre IU de vinculación posterior (consulta Carga útil de publicidad: datos de cuenta de vinculación rápida).

Requisitos de los dispositivos de audio de bajo consumo

Requisitos de Bluetooth

Consulta las recomendaciones de auriculares de Android LE Audio.

Asistencia de CTKD

Para dispositivos de modo dual, el CTKD de LE a BR/EDR es obligatorio y está alineado con BAP.

Anuncio de objetivos

Los dispositivos periféricos deben usar anuncios orientados para solicitar una conexión desde un dispositivo central vinculado. Los anuncios orientados se definen en BAP y CAP. para la administración de conexiones de acuerdo con la Tabla 8.4 de CAP 1.0 (p48/58).

Compatibilidad con servidores GATT EATT

EATT permite que el dispositivo central envíe varias transacciones GATT en paralelo cuando el dispositivo está vinculado. En el caso de los dispositivos compatibles con CSIP, aumentará el rendimiento de la conexión del perfil y, pronto, comenzará la vinculación de CSIP procedimiento 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 detectando servicios y acelerando la conexión, el Proveedor debería implementar el almacenamiento en caché GATT, como se define en Bluetooth 5.1

Requisitos de Vinculación rápida

LE Advertising

En el modo detectable o el no detectable, si el dispositivo tiene varios los datos de Vinculación rápida deben anunciarse en el componente principal. Si el botón el dispositivo no está listo para la vinculación posterior, el componente secundario puede Anunciar datos de Vinculación rápida para funciones extendidas ver Ocultar indicación de IU.

Visibilidad del servicio GATT

La base de datos GATT será la misma para todas las conexiones GATT de transporte de LE. Audio de bajo consumo (0x184E) debe incluirse en la base de datos GATT de la conexión de Vinculación rápida.

Ejemplo: Vinculación con el proveedor de modo dual de LEA

Situación 1: Cuando el Seeker no admite LEA

El Proveedor tendrá retrocompatibilidad con el Buscador que no admiten la LEA.

Componentes

• Proveedor: A2DP/HFP/LEA
• Buscador: A2DP/HFP

Comportamiento esperado para el par inicial / el par posterior

• El proveedor anuncia el servicio de Vinculación rápida. (0xFE2C) con la dirección de identidad (inicial) o RPA (posterior).
  • Cómo usar la publicidad heredada
• El buscador recibe el token del proveedor anuncio con dirección de identidad para la vinculación inicial o RPA para la vinculación posterior
• El buscador envía una solicitud de vinculación basada en claves
  • La marca bit-5 de la solicitud de vinculación basada en claves se establece en 0.
• El proveedor envía una respuesta de vinculación basada en claves con una dirección pública en uno de lo siguiente:
  • Si se usa el tipo de mensaje 0x01, la dirección debe ser dirección pública.
  • Si se usa el tipo de mensaje 0x02
    • Bit-0 debe ser 0
    • Bit-1 debe ser 0
    • La dirección debe ser una dirección pública
• The Seeker crea un vínculo con el transporte BR/EDR
  • La capacidad de IO está configurada en DisplayYesNo para BR/EDR.
• El Buscador y el proveedor realizan el procedimiento de verificación de llaves de acceso de Vinculación rápida

Situación 2: Cuando el Seeker admite LEA

Componentes

• Proveedor
  • Compatibilidad con A2DP/HFP/LEA
  • Componente único
• Buscador
  • CompatibilidadA2DP/HFP/LEA

Comportamiento esperado para el par inicial / el par posterior

• El proveedor anuncia el servicio de Vinculación rápida. (0xFE2C) con la dirección de identidad (inicial) o RPA (posterior).
  • Cómo usar la publicidad heredada
• El buscador envía una solicitud de vinculación basada en claves
  • La marca bit-5 de la solicitud de vinculación basada en claves se establece en 1.
• El proveedor envía una respuesta de vinculación basada en claves con el tipo de mensaje 0x02
  • Bit-0 debe ser 0
  • Bit-1 debe ser 1
  • La dirección es Dirección de identidad
• The Seeker crea lazos con el mundo Conexión de LE en el transporte LE
  • La dirección de CTKD es de LE a BR/EDR
  • La capacidad de IO está configurada en DisplayYesNo para LE
• El Buscador y el proveedor realizan el procedimiento de verificación de llaves de acceso de Vinculación rápida

Situación 3: Cuando el Seeker involucra a LEA y CSIP

Componentes

• Proveedor
  • Compatibilidad con A2DP/HFP/LEA
  • Varios componentes
    • El componente principal es BR/EDR/LE
    • El componente secundario solo está disponible para usuarios de bajo consumo
• Buscador
  • Compatibilidad con A2DP/HFP/LEA

Comportamiento esperado para el par inicial / el par posterior

• El componente principal anuncia la Vinculación rápida datos del servicio (0xFE2C) con la dirección de identidad (inicial) o RPA (posterior).
  • Cómo usar la publicidad heredada
• El buscador envía una solicitud de vinculación basada en claves al componente principal
  • La marca bit-5 de la solicitud de vinculación basada en claves se establece en 1.
• El componente principal envía una respuesta de vinculación basada en claves con el tipo de mensaje 0x02
  • Bit-0 debe ser 0
  • Bit-1 debe ser 1
  • Las direcciones son las siguientes :
    • 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 el segundo componente también usa esta dirección para crear anuncios de CSIP
• El buscador crea lazos con el principal en la conexión de LE existente
  • La dirección de CTKD es de LE a BR/EDR
  • La capacidad de IO está configurada en DisplayYesNo para LE
• El Buscador crea lazos con las secundarias componente cuya dirección es de la respuesta extendida de la vinculación basada en claves
  • La capacidad de IO será DisplayYesNo; de lo contrario, se rechazará la solicitud de sincronización.
• El Seeker y el proveedor realizan un procedimiento de protección de MITM para vincular componente secundario, el Proveedor implementará ambas situaciones
  • Protección contra MIT: Notificación
  • Protección contra MITM: lectura
• El Buscador espera hasta que se una al componente secundario

Diagrama secuencial de MITM

Esta sesión describe la secuencia del procedimiento de protección MITM.

Obtén una llave de acceso del componente que se vincula con la notificación

Obtén una llave de acceso del componente que se une con lectura

Problema conocido

FP para LEA se optimizó para funcionar con Android V(Android 15).

Por el contrario, hemos detectado varios problemas con auriculares que admiten LEA. pero no cuentan con la implementación correcta de Vinculación rápida en lugar de LEA (es decir, solo con la Vinculación rápida clásica). Específicamente y por ejemplo, cuando no se genera la RPA del proveedor la clave de resolución de identidad (IRK) correcta y la dirección no se puede resolver. Aunque no pudimos probar una lista completa de auriculares, de configuraciones, nuestras pruebas limitadas revelaron varios problemas, incluidos errores para mostrar las notificaciones de la batería del auricular, la falta de cambio de audio (SASS) errores de vinculación iniciales y posteriores, y mucho más.

Por lo tanto, recomendamos a los socios implementar la Vinculación rápida de LEA. específica para dispositivos nuevos y existentes en el campo (mediante actualizaciones inalámbricas) compatibles con modos duales.