Audio Switch

As users increasingly utilize multiple audio source devices to perform their daily tasks, there's growing demand for a simpler solution to manage headset use across devices. Audio switch seamlessly transitions headset connections between devices based on user activity (e.g. starting a movie) and prioritized events (e.g. an incoming call).

UX Principles

1. Connection switching should be fast and based on user action.
2. Connection switching should be transparent to users, allowing users to control/revert if the switching is undesirable.
3. Switching should respect user privacy.

Roles

Audio Switch Seeker: The Seeker is an audio source device (for example, a phone or tablet), looking for a nearby headset to connect with when applicable.

Audio Switch Provider: The Provider is normally a headset advertising its presence and connection status for Seekers to make switching decisions.

Requirements Overview

To achieve smart switching, Providers must adhere to the following requirements:

Advertising payload

The Provider shall include its current connection status in the advertisement, built on top of the Fast Pair Account data described in Advertising: When not discoverable.

Note that the version of table 4.2 is 0x1.

Connection Status Field

Recommend the LE Audio Provider should handle all of the context types specified in Assigned Numbers 6.12.3 (unless the Provider explicitly does not support a given context type) and map the context type to the connection state as below.

• Conversational: 0x9
• Media: 0x8
• Game: 0x7
• Instructional: 0x7
• Voice Assistants: 0x9
• Live: 0x9
• Sound Effects: 0x2
• Notifications: 0x2
• Ringtone: 0x9
• Alerts: 0x7
• Emergency Alarm: 0x9

For the mixed LE Audio context type scenario such as playing media during the call, Provider shall use the connection state with highest priority, i.e. use 0x9 (call) for above scenario instead of 0x8 (media).

Connected Device Bitmap

To avoid undesired connection switching, the Seeker may need to know which device(s) the headset is currently connected to. For example, when the headset is connected to the phone, the user doesn't want to be interrupted by the connection switching when one of their family members starts YouTube on the tablet.

Note that this bitmap is anonymous, the Seeker is unable to know what other devices are bonded with the Provider. For example, take 5 bonded devices:

• 0: laptop (0bx0000000)
• 1: phoneA (0b0x000000)
• 2: phoneB (0b00x00000)
• 3: tablet (0b000x0000)
• 4: TV (0b0000x000)

If the current connected devices are a laptop and a tablet, the value of the bitmap will be 0b10010000. The order change is acceptable if it is unavoidable, e.g. when users factory reset the headset or when the bonded device count reaches the upper limit.

Random Resolvable Advertisement

To avoid tracking and respect user privacy, the Provider should rotate and encrypt the field by the account key using AES-CTR:

 encrypted_connection_status_field = connection_status_raw_data ^ AES(Key, IV)

where

1. Key is derived from the in use account key, which is defined in the next section.

   • Key is generated by the HKDF function, IETF RFC 5869, using the SHA-256 hash function.

       Key = HKDF(account_key, NULL, UTF8("SASS-RRD-KEY"),16)
     

   • Provider shall use the original account key here, i.e. the first byte of the key is 0x04, not included in use pattern.

2. IV (initial vector) is the 2-byte salt of Account Key Data with zero padding, i.e. IV is concat(salt, 14-byte ZEROs).

3. Connection status raw data is defined in table 4.1, if the connection status changes, the salt and RPA should be regenerated at the same advertising time frame.

This makes the encrypted connection status field rotate at the same time as the Account Key Data rotates.

The BLE advertisement will be structured as below:

As an example, if the Random Resolvable Data contains an encrypted connection status field, the decrypted result will be the connection status field.

To prevent tampering, the Account Key Data above should be slightly modified when the Random Resolvable Data is included in the advertisement. Normally, when building the account key filter, a value V is produced by combining the account key filter with a salt. Instead, when Random Resolvable Data is also being advertised, the value V should be constructed as:

 V = concat(account_key, salt, random_resolvable_data)

If both Battery Data and Random Resolvable Data are being advertised, V should be constructed as:

 V = concat(account_key, salt, battery_data, random_resolvable_data)

In Use Account Key

The connection switching is account-based, so the Provider should include the account information of the current connection in the BLE advertisement. If the current connected device is a Audio switch Seeker, the Provider should be able to get the account key associated with this Seeker, and use this account key to encrypt the connection status field. If the connected audio source is non-Audio switch Seeker, the Provider should use the most recently used account key.

Before computing the account key filter, the Provider should modify the first byte of the account keys to include one of the following in use patterns:

1. 0b00000100
   This account key is not in use.
   This is the default one (see Account key).
2. 0b00000101
   This account key is the most recently used account key.
   The connection status field is encrypted by this account key. There is no account key information of the current connection state, it could mean no devices connected or the connected device is not an Audio switch Seeker.
3. 0b00000110
   This account key is the in use account key.
   The connection status field is encrypted by this account key, and the current connected device is associated with this account key.

Schematic for Audio switch payload

The figure below shows the schematic for Audio switch payload.

Messages

When connected, Seeker and Provider can use the Message stream to sync Audio switch capability, trigger a connection switch, set and get the switching preference, notify connection status and so on. We create a message group and message codes specific for Audio switch as below.

Additional details for each message code are included in the following sections.

To provide message authentication, all Audio switch messages with additional data sent from Seeker to Provider require a Message Authentication Code. When a message with MAC is received, it should be acknowledged so that the Seeker knows whether or not the Provider has reacted to the message.

If message authentication succeeds, the Provider shall send the ACK for the message:

If it fails, the Provider shall send the NAK for the message:

Note that, if the Provider is the sender, MAC is not required.

Get capability of Audio switch

Both the Audio switch Provider and Seeker can check if the connected Fast Pair Seeker/Provider supports Audio switch or not by using the below message:

Upon receiving get capability of Audio switch message code, the Audio switch Seeker/Provider will respond with one of the following flags:

Upon receiving this message, the Provider shall respond by the message code 0x34, notify connection status.

Notify connection status

As defined in BLE advertising payload, for multipoint Providers, if the connection status changes, except for changing advertising packet, the Provider should also notify the connected Seekers which are using the same account key about the change. If the Provider is connected with an Audio switch Seeker and a non-Audio switch Seeker, if the non-Audio switch Seeker is active, the Provider should also notify the connected Audio switch Seeker about the connection status (using the Seeker's account key).

 encrypted_connection_status = connection_status_raw_data ^ AES(Key, IV)

• Key is derived from the in use account key, see Random Resolvable Advertisement.

   Key = HKDF(account_key, NULL, UTF8("SASS-RRD-KEY"),16)
  

• IV is concat(Session_nonce, Message_nonce)

• connection_status_raw_data = concat(connection_state, custom_data, connected_devices) which is defined in BLE advertising payload Note that the byte for field length and type should not be included since we have message code and data length here.

Notify Audio switch initiated connection

Audio switch Providers may need to know if the connection switching is triggered by Audio switch to have different reactions, e.g. disable earcons for Audio switch events. The Seeker sends a message to notify the Provider that this connection was an Audio switch initiated connection.

See Nearby embedded SDK library for the reference implementation