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 uses the Bit 4 to indicate if the Seeker supports BLE Device Specification, and uses the Bit 5 to indicate if the Seeker supports 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. 0 otherwise.
  • Bit 4: 1 if the Seeker supports the BLE Device Specification. 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 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 for reference

Message Stream PSM (Protocol Service Multiplexor) Characteristic

To support 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 Yes 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 and MITM diagram 2 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 in adherence to the Bluetooth Adapter Profile (BAP 1.0.1) and Common Audio Profile requirement. 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
  • 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).

LE Audio Device Requirements

Bluetooth Requirements

See Android, LE Audio headset recommendations.

CTKD Support

For dual mode device, CTKD from LE to BR/EDR is mandatory and in alignment with BAP 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 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, it will increase the performance of profile connection, and then soon start CSIP bonding procedure for the other buds.

If the Provider is not a single device but a coordinated set with CSIP 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.

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 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
  • 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

Get passkey from the component being bonded by read

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.