> [!IMPORTANT] > **Key Point:** The FastPair Low Energy Audio (LEA) capability is exclusively accessible with the Android V(Android 15) release. It is strongly advised to implement Fast Pair BLE Devices specification for LEA-compatible devices. This recommendation stems from our experience with encountering numerous issues with headsets that support LEA but lack the proper Fast Pair over LEA implementation. For further information, kindly refer to the [known issue](https://developers.google.com/nearby/fast-pair/specifications/bledevice#known_issue) section . The FP LEA certification is only available post Android V(Android 15) release. ## Bluetooth Low Energy (BLE) Device The Google Fast Pair Service (GFPS) implementation for BLE devices is compatible with the Bluetooth Core Specification v4.2 or later. The following addendum to the Fast Pair specification will allow the support for Low Energy (LE) only and Low Energy Audio (LEA) devices in GFPS. ### Conformance Levels The keywords "shall", "must", "will", "should", "may", and "can" mentioned in the specification are explained below: | Term | Description | |---|---| | shall | is required to - used to define requirements. | | must | is used to express: a natural consequence of previously stated mandatory requirement OR an indisputable statement of fact (one that is always true regardless of the circumstances). | | will | it is true that - only used in statements of fact. | | should | is recommended that - used to indicate that among several possibiliies one is recommended as particularly suitable, but not required. | | may | is permitted to - used to allow options. | | can | is able to - used to relate statement in a causal manner. | ### Key-based Pairing Characteristic #### Message from Seeker to Provider The Raw Request `type 0x00` of [Key-based Pairing characteristic](https://developers.google.com/nearby/fast-pair/specifications/characteristics#KeyBasedPairing "Key-based pairing characteristic") uses the Bit 4 to indicate if the Seeker supports [BLE Device Specification](https://developers.google.com/nearby/fast-pair/specifications/bledevice), and uses the Bit 5 to indicate if the Seeker supports [LE Audio](https://www.bluetooth.com/learn-about-bluetooth/recent-enhancements/le-audio/). | Octet | Data type | Description | Value | Mandatory? | |---|---|---|---|---| | 0 | `uint8` | Message type | `0x00` = Key-based Pairing Request | Mandatory | | 1 | `uint8` | Flags - Bit 0 (MSB): deprecated and ignored by Seeker. - Bit 1: 1 if the Seeker requests that the Provider shall initiate bonding, and this request contains the Seeker's BR/EDR address. 0 otherwise. - Bit 2: 1 if the Seeker requests that the Provider shall notify the existing name. 0 otherwise. - Bit 3: 1 if this is for [Retroactively writing account key](https://developers.google.com/nearby/fast-pair/specifications/extensions/retroactiveacctkey "Retroactively writing account key"). 0 otherwise. - Bit 4: 1 if the Seeker supports the [BLE Device Specification](https://developers.google.com/nearby/fast-pair/specifications/bledevice). 0 otherwise. - Bit 5: 1 if the Seeker supports LE Audio. 0 otherwise. - Bits 6 - 7 are reserved for future use, and shall be ignored. | *varies* | Mandatory | | 2 - 7 | `uint48` | Either: - Provider's current BLE address - Provider's Identity address | *varies* | Mandatory | | 8 - 13 | `uint48` | Seeker's BR/EDR Address | *varies* | Present only if Flags Bit 1 or 3 is set | | *n* - 15 | | Random value (salt) | *varies* | Mandatory | #### Message from Provider to Seeker When Bit 4 of the request is set, the new response message `type 0x02` for Key-based Pairing characteristic can be used to provide additional bonding options to the Seeker. | Octet | Data type | Description | Value | |---|---|---|---| | 0 | `uint8` | Message type | `0x02` = Key-based Pairing Extended Response | | 1 | `uint8` | Flags - Bit 0 (MSB): 1 if the Provider is LE only device, 0 otherwise. If bit 0 is set to 1, the Seeker will assume that Bit 1 is set to 1. - Bit 1: 1 if the Provider prefers LE bonding, 0 otherwise. - Bit 2: 1 if the address type of second address is Random, 0 if Public. - Bit 3 - 7 are reserved for future use, and shall be ignored. | *varies* | | 2 | `uint8` | Number of the Provider's addresses (in the current version, the number is 1 or 2, because we need to modify block cipher mode to AES-CTR if the number \>= 3) | *varies* | | 3 - 8 or 3 - 14 | | - The first address shall be the Identity address of the primary, and bondable if BR/EDR bonding is preferred - The second address shall be bondable address of the secondary if the secondary is available | *varies* | | 9 - 15 or 15 | | Random value (salt) | *varies* | A Provider which supports [BLE Device Specification](https://developers.google.com/nearby/fast-pair/specifications/bledevice) shall read Bit 4 and Bit 5 to understand the Seeker's capabilities - When Bit 4 is 0, the Provider shall ignore Bit 5 and respond with the `type 0x01` format - When Bit 4 is 1, - For LE-only Provider, it shall respond with `type 0x02` to indicate LE bonding preference. - For dual mode Provider, it can respond with `type 0x02` to indicate either BR/EDR or LE bonding preference. - For LE Audio (LEA) dual mode Provider cases, see [Example: Pairing with LEA dual mode Provider](https://developers.google.com/nearby/fast-pair/specifications/bledevice#example_pairing_with_lea_dual_mode_provider) for reference ### Message Stream PSM (Protocol Service Multiplexor) Characteristic To support [Message stream](https://developers.google.com/nearby/fast-pair/specifications/extensions/messagestream#MessageStream "message stream") for BLE devices, Fast Pair will establish and maintain a BLE L2CAP channel for sending and receiving messages. Fast Pair L2CAP server shall implement LE credit based flow control. This characteristic allows the Seeker to read the PSM value, and then establish secure L2CAP connection by the PSM value. | Fast Pair Service characteristic | Encrypted | Permissions | UUID | |---|---|---|---| | Message Stream PSM | Yes | Read | `FE2C1239-8366-4814-8EB0-01DE32100BEA` | | Octet | Data type | Description | Value | |---|---|---|---| | 0 | `uint8` | State - 0x00 = Unknown. FP Seeker will retry for several times - 0x01 = Ready to connect - 0x02 = Unavailable. FP Seeker won't use this component to connect this time | *varies* | | 1 - 2 | `uint16` | PSM value shall be in the range between 0x80 and 0xFF | *varies* | **Note:** For TWS, there are two components: primary and secondary. The role for these components are interchangeable in certain conditions. Assuming A is primary component and B is secondary component, due to battery drainage on component A , component B needs to take up the primary component role and this scenario is called `role switch`. After `role switch`, If the provider cannot handle Fast Pair message stream, it shall proactively disconnect the existing L2CAP connection. Fast Pair seeker can then re-establish the L2CAP message stream connection with the new primary component. ### Additional Passkey Characteristic This characteristic is to provide MITM protection on the additional components. #### CSIS Fake Member MITM Protection Fast Pair requires MITM protection as part of the pairing procedure. As CSIS does not provide MITM protection, the current design for FP for multiple components needs to be extended to provide MITM protection on the additional components. #### Characteristic Definition | Fast Pair Service Characteristic | Encrypted | Permission | UUID | |---|---|---|---| | Additional Passkey | No | Read,write,notify | FE2C123A-8366-4814-8EB0-01DE32100BEA | #### Messages The message format is applied to read, write and notify operations. ##### Encrypted Data Format The encrypted data is sent using Fast Pair GATT connection. | Octet | Data type | Description | Value | |---|---|---|---| | 0-15 | uint128 | Encrypted additional passkey block | varies | ##### Raw Data Format After decrypting the encrypted data using shared secret, the format is as below | Octet | Data type | Description | Value | |---|---|---|---| | 0 | uint8 | Message type | one of - 0x00 = Seeker's passkey - 0x01 = Provider's passkey | | 1-3 | uint24 | 6-digit passkey | varies | | 4-9 | uint48 | Target bonding component address | varies | | 10 | uint8 | Status code, this is only used by read operation | One of - 0x00 = Success - 0x01 = Pending. FP Seeker retry until timeout - 0x02 = Failure. FP Seeker stop retry | | 11-15 | | Random value (salt) | varies | The primary (first bonded component) is the bridge between Fast Pair Seeker and the additional bonding components. The characteristic shall follow guidelines: - When receiving a write request from Fast Pair Seeker, the Provider shall - Set address of the component which is being bonded - Send the passkey to the component being bonded - Set status code to Pending, 0x01 - When receiving any read request before receiving passkey from the component being bonded, the Provider shall return a message with - Passkey, any value - Address of the component being bonded - Pending status code, 0x01 - Before the Provider sends notification to Fast Pair Seeker, sets the result for the read request with - Passkey from the component being bonded - Address of the component being bonded - Success status code, 0x00 - If any unrecoverable error on the Provider side, set the result - Passkey, any value - Address of the component being bonded - Failure status code, 0x02 See [MITM diagram 1](https://developers.google.com/nearby/fast-pair/specifications/bledevice#mitm_diagram_notification) and [MITM diagram 2](https://developers.google.com/nearby/fast-pair/specifications/bledevice#mitm_diagram_read) for more details. ### LE Device Requirements #### LE Advertising For discoverable mode or non-discoverable mode, the Provider shall use RPA to advertise FastPair data. #### Bonding Capability For LE-capable devices, the Seeker must create bond with the existing LE connection. After passing Fast Pair Key-based Pairing verification, the Provider shall allow bonding with RPA, and set IO capability to DisplayYesNo for Fast Pair Passkey verification. ### LEA Device Requirements #### LEA Advertising For dual mode devices: For discoverable mode, the Provider shall advertise Fast Pair data with Identity address. For non-discoverable mode, the Provider shall advertise Fast Pair data with RPA. It is highly recommended to use legacy advertisement (BT 4.2) to support older devices for backward compatibility. It is required to change IRK whenever the device factory resets. For non dual mode devices: For discoverable mode or non-discoverable mode, the Provider shall use extended advertising (BT 5.0) with RPA to advertise FastPair data. The LE connectable advertisement containing FP service data shall include [CAS UUID](https://www.bluetooth.com/specifications/cas-1-0/) in adherence to the [Bluetooth Adapter Profile (BAP 1.0.1)](https://www.bluetooth.com/specifications/bap-1-0-1/) and [Common Audio Profile](https://www.bluetooth.com/specifications/cap-html/) requirement. The Provider can indicate LEA capability by including the CAS UUID (0x1853) in either the Service Data (AD Type 0x16) or the 16-bit Service Class UUIDs (AD Type 0x02 or 0x03), regardless of the discoverable mode. For non-discoverable advertisement if enough space is not available in legacy advertisement due to inclusion of battery and SASS data, it is mandatory to include CAS UUID in scan response in that case. #### LEA Bonding Capability The Seeker must create bond with the existing LE connection. After passing Fast Pair Key-based Pairing verification, the dual mode Provider shall allow bonding with Identity address and RPA while non-dual mode Provider shall allow bonding with RPA, and set IO capability to DisplayYesNo for Fast Pair Passkey verification. #### Internal communication channel between components The existing GATT connection is kept to perform MITM protection on the additional components. The primary bonded component shall handle message deliveries between Fast Pair Seeker and its remaining components. The internal communication is used for `Initial Pair` and `Subsequent Pair` - When Key-based Pairing procedure passes on the primary component, the primary component shall send a message to change IO capability of its remaining components - When Fast Pair is done, the primary component shall send a message to reset IO capability of its remaining components - When running Additional Passkey procedure, the primary component shall handle passkey deliveries between Fast Pair Seeker and its remaining components #### Time to change IO capability - Change IO capability to DisplayYesNo when Key-based Pairing procedure passed - If the device has multiple components, all components shall be set to DisplayYesNo - One exception that the Provider shall not change IO capability to DisplayYesNo is `Retroactive Pair`, whose Bit 3 of Key-based Pairing Request is set to 1, see [Message from Seeker to Provider](https://developers.google.com/nearby/fast-pair/specifications/bledevice#message_from_seeker_to_provider) - Change IO capability to default setting - Initial pairing - If the LE connection is disconnected, end Fast Pair session - After the primary is bonded, if there is no additional passkey write request in 15 seconds, end Fast Pair session - After additional passkey write request is received, if the component being bonded is not bonded within 15 seconds, end Fast Pair session - After all components are bonded, if there is no account key write request within 15 seconds, end Fast Pair session - After account key write request is received, set timeout 15 seconds to end Fast Pair session - Subsequent pairing - If the LE connection is disconnected, end Fast Pair session - After the primary is bonded, if there is no additional passkey write request within 15 seconds, end Fast Pair session - After additional passkey write request is received, if the component being bonded is not bonded within 15 seconds, end Fast Pair session - When all the components are bonded, end Fast Pair session #### Hide UI Indication When the headset is not ready for pairing, the Provider shall use `type 0b0010` to set hide UI indication for Account Key Data to tell the Seeker not to show subsequent pairing UI (see [Advertising payload: Fast Pair Account Data](https://developers.google.com/nearby/fast-pair/specifications/service/provider#advertising_payload_fast_pair_account_data)). ### LE Audio Device Requirements #### Bluetooth Requirements See [Android, LE Audio headset recommendations](https://developer.android.com/guide/topics/connectivity/ble-audio/overview#le_audio_lea_headset_recommendations). ##### CTKD Support For dual mode device, CTKD from LE to BR/EDR is mandatory and in alignment with [BAP](https://www.bluetooth.com/specifications/specs/basic-audio-profile-1-0/) requirements. ##### Target Announcement A peripheral device shall use Targeted Announcement to solicit a connection from a paired central device. Targeted Announcements is defined in BAP and CAP for connection management according to [CAP 1.0](https://www.bluetooth.com/specifications/specs/common-audio-profile-1-0/) Table 8.4 (p48/58). ##### GATT EATT Server Support EATT allows the central device to send multiple GATT transactions in parallel when the device is bonded. For the device supporting [CSIP](https://www.bluetooth.com/specifications/specs/coordinated-set-identification-profile-1-0-1/), it will increase the performance of profile connection, and then soon start [CSIP](https://www.bluetooth.com/specifications/specs/coordinated-set-identification-profile-1-0-1/) bonding procedure for the other buds. ##### GATT Robust Caching (Strongly Recommended) If the Provider is not a single device but a coordinated set with [CSIP](https://developers.google.com/nearby/fast-pair/specifications/defined%0Ain%20Bluetooth%20LE%20Audio%20Specifications) implementation, to reduce the number of times doing service discovery and speed up the connection, the Provider should implement GATT Caching defined in Bluetooth 5.1. #### Fast Pair Requirements ##### LE Advertising For discoverable mode or non-discoverable mode, if the device has multiple components, Fast Pair data shall be advertised by the primary component. If the device is not ready for subsequent pairing, the secondary component can advertise Fast Pair data for extended features. see [Hide UI Indication](https://developers.google.com/nearby/fast-pair/specifications/bledevice#hide-ui-indication). ##### GATT Service Visibility GATT database shall be the same for all LE transport GATT connections. LE Audio service (0x184E) shall be included in the GATT database of Fast Pair connection. ### Example: Pairing with LEA dual mode Provider #### Scenario 1 - When the Seeker does not support LEA The Provider shall have backward compatibility to the Seeker that does not support LEA. ##### Components - Provider: A2DP/HFP/LEA - Seeker: A2DP/HFP ##### Expected Behavior for Initial Pair / Subsequent Pair - The Provider advertises Fast Pair service data (0xFE2C) with Identity address (initial) or RPA (subsequent). - Use Legacy advertising - The Seeker receives the Provider's advertisement with Identity address for initial or RPA for subsequent pairing - The Seeker sends Key-based Pairing request - The flag bit-5 of Key-based Pairing request is set to 0 - The Provider sends Key-based Pairing response with public address in one of the following: - If message type 0x01 is used, the address shall be public address - If message type 0x02 is used - Bit-0 shall be 0 - Bit-1 shall be 0 - The address shall be public address - The Seeker creates bond with BR/EDR transport - IO capability is set to DisplayYesNo for BR/EDR - The Seeker and the Provider do Fast Pair passkey verification procedure #### Scenario 2 - When the Seeker supports LEA ##### Components - Provider - Support A2DP/HFP/LEA - Single component - Seeker - SupportA2DP/HFP/LEA ##### Expected Behavior for Initial Pair / Subsequent Pair - The Provider advertises Fast Pair service data (0xFE2C) with Identity address (initial) or RPA (subsequent). - Use Legacy advertising - The Seeker sends Key-based Pairing request - The flag bit-5 of Key-based Pairing request is set to 1 - The Provider sends Key-based Pairing response with message type 0x02 - Bit-0 shall be 0 - Bit-1 shall be 1 - The address is Identity address - The Seeker creates bond with the existing LE connection on LE transport - CTKD direction is from LE to BR/EDR - IO capability is set to DisplayYesNo for LE - The Seeker and the Provider do Fast Pair passkey verification procedure #### Scenario 3 - when the Seeker supports LEA and CSIP involved ##### Components - Provider - Support A2DP/HFP/LEA - Multiple components - Primary component is BR/EDR/LE - Secondary component is LE-only - Seeker - Support A2DP/HFP/LEA ##### Expected Behavior for Initial Pair / Subsequent Pair - The primary component advertises Fast Pair service data (0xFE2C) with Identity address (initial) or RPA (subsequent). - Use Legacy advertising - The Seeker sends Key-based Pairing request to the primary component - The flag bit-5 of Key-based Pairing request is set to 1 - The primary component sends Key-based Pairing response with message type 0x02 - Bit-0 shall be 0 - Bit-1 shall be 1 - The address are as below : - First address is the Identity address of the primary component - Second address is the bondable address for the secondary component, the second component also uses this address to do [CSIP](https://www.bluetooth.com/specifications/specs/coordinated-set-identification-profile-1-0-1/) advertisement - The Seeker creates bond with the primary component on the existing LE connection - CTKD direction is from LE to BR/EDR - IO capability is set to DisplayYesNo for LE - The Seeker creates bond with secondary component whose address is from Key-based Pairing Extended Response - IO capability shall be DisplayYesNo, otherwise reject the pairing request - The Seeker and the Provider do MITM protection procedure for pairing the secondary component, the Provider shall implementat both scenarios - [MITM protection - notification](https://developers.google.com/nearby/fast-pair/specifications/bledevice#mitm_diagram_notification) - [MITM protection - read](https://developers.google.com/nearby/fast-pair/specifications/bledevice#mitm_diagram_read) - The Seeker waits until bonded with the secondary component ### Sequential Diagram for MITM This session is to describe the sequence of MITM protection procedure. #### Get passkey from the component being bonded by notification ![](https://developers.google.com/static/nearby/fast-pair/images/bond_second_component_by_fp_get_passkey_by_notification.png) #### Get passkey from the component being bonded by read ![](https://developers.google.com/static/nearby/fast-pair/images/bond_second_component_by_fp_get_passkey_by_read.png) #### Known Issue FP for LEA has been optimized to work with Android V(Android 15). Conversely, we have encountered numerous issues with headsets that support LEA but lack the correct Fast Pair over LEA implementation (i.e. only Fast Pair over Classic). Specifically and for example, when the provider's RPA is not generated by the correct Identity Resolving Key (IRK), and the address cannot be resolved. While we have not been able to test a comprehensive list of headset configurations, our limited testing revealed various issues, including failure to display earbud battery notifications, lack of Audio Switching (SASS) functionality, widespread initial and subsequent pairing failures, and more. Therefore, we strongly advise partners to implement the Fast Pair-LEA specification for both new devices and existing devices in the field (via over-the-air updates) that support dual modes.