LE Audio CAP Commander - BAP Broadcast Assistant design

[iulia-tanasescu]

Topics about designing the BAP Broadcast Assistant role (CAP Commander role) in BlueZ:

General ideas:

• The BAP Broadcast Assistant role implements the BASS Client role.
• The BAP Scan Delegator role implements the BASS Server role.
• The Broadcast Assistant (BASS Client) application needs to be aware of the available Broadcast Sources and of the Broadcast Sources known by a connected Scan Delegator (BASS Server).
• A user interface is needed for issuing commands from the Broadcast Assistant (BASS Client) to connected Scan Delegators (BASS Servers) via the BASS control point characteristic: Add Source, Set Broadcast_Code etc.

Design/implementation ideas on how to handle connections with Scan Delegators:

• Each time a new session is added with a Scan Delegator (BASS Server), the BASS plugin should register a DBus interface containing properties about the peer.

• After connection, the Broadcast Assistant (BASS Client) performs service discovery with the Scan Delegator (BASS Server) and it populates its BASS rdb with Broadcast Sources discovered on the peer (information contained in Broadcast Receive State characteristics).

• After service discovery has completed, having the DBus interface registered for the connected Scan Delegator, the Broadcast Assistant should iterate through its rdb and emit property changed with information about the Broadcast Sources discovered on the peer.

• For each discovered source, the Source ID (Broadcast Source identifier on the BASS Server), the Broadcast ID (global identifier advertised by the Broadcast Source) and the encryption field of the Broadcast Receive State characteristic should be notified via property changed on the Scan Delegator DBus interface.

• Each time a Broadcast Receive State notification is received from a Scan Delegator (meaning that parameters of a Broadcast Source stored on the BASS Server have changed, or that a Broadcast Source was added or deleted), the Broadcast Assistant updates its BASS rdb and should emit property changed on the Scan Delegator DBus interface.

• A Delegator interface needs to implement methods for the BASS Remote Scan Started and Remote Scan Stopped control point operations.

• A Delegator interface needs to implement methods for BASS control point operations related to updating Broadcast Sources already stored on the Scan Delegator: Modify Source and Set Broadcast_Code, Remove Source.

• A new menu can be added in bluetoothctl, to detect Scan Delegator proxies, to print the properties as they are updated and to send commands.

Design/implementation ideas on how to handle available Broadcast Sources:

• The BASS plugin should register a profile for the BCAA service, to probe scanned Broadcast Sources.
• The Broadcast Assistant should perform short-lived PA sync with each probed Broadcast Source, to discover the Broadcast Source capabilities by parsing the BASE.
• The Broadcast Assistant should try to match Broadcast Source capabilities with Scan Delegator capabilities contained in the BAP PACS characteristic.
• For each match between a Broadcast Source and a Scan Delegator, the Broadcast Assistant should register a DBus interface to be detected by the user application process (bluetoothctl).
• Each match interface should implement a method that the user process can call to send the information about the Broadcast Source to the matched Scan Delegator (the BASS Add Source control point operation).

[Vudentz]

@iulia-tanasescu we should probably think about the use cases first, for instance is that really useful the use a BASS Client in BlueZ, or that targeting only headless (no UI) devices which cannot start scan procedure by itself? BASS server in the other hand is probably what I would imagine to be more important for BlueZ to support and I would imagine we would like bluetoothctl to help the client with the interface of selecting broadcasters, actually to avoid having rogue BASS client just using the interface to make the radio busy we probably first need to implement some authorization mechanism for BASS operations, perhaps something like org.bluez.MediaAgent which application like bluetoothctl could implement to start scanning and then do the enumeration of the MediaTransport objects it had found.

[iulia-tanasescu]

@Vudentz A use case could be the following:

• The BASS Server is a no UI sink device (headphones) that cannot scan broadcasters by itself.
• The BASS Client is a mobile phone that has the UI to start scanning, connect to a BASS Server, enumerate broadcasters and select broadcaster information to send to the Server.

On the BASS Client, indeed we need a DBus interface, like org.bluez.MediaAgent, for the UI application (bluetoothctl) to communicate with BASS Client in BlueZ.

The main BASS operations that need to be handled are Add Source and Set Broadcast Code.

• For the Add Source operation, the BASS Client in BlueZ needs to probe broadcasters and enumerate objects similar to MediaTransports for each BIS - we could use MediaAgent objects. A MediaAgent interface should implement a "select" method, similar to transport acquire, so bluetoothctl can instruct the BlueZ BASS Client to send the BIS information to the Server via GATT.
• For the Set Broadcast Code operation, the Client in BlueZ receives GATT notifications in which the Server asks for the Broadcast Code to sync to a broadcaster. We can use a MediaAgent property to be updated on each received notification - something like "Encryption" prop. This will be visible in bluetoothctl UI and the user can choose to call the "set_bcode" method on the MediaAgent, to instruct the BASS Client in BlueZ to provide the Broadcast Code to the Server via GATT.

[PJ-Pranjal]

@Vudentz and @iulia-tanasescu Broadcast assistant requires scanning support for extended LE advertisements.
For this scanning support, we need to set the LE Set Extended Advertising Parameters, do you know how we do it in BlueZ?

I'm new to BlueZ, and have tried passive scanning but I'm only seeing regular advertising message and not the extended one.

[Vudentz]

@Vudentz and @iulia-tanasescu Broadcast assistant requires scanning support for extended LE advertisements. For this scanning support, we need to set the LE Set Extended Advertising Parameters, do you know how we do it in BlueZ?

I guess you are talking about LE Set Extended Scan Parameters rather than Advertising, the Scanning_PHY would be actually setup based on what the controller supports.

I'm new to BlueZ, and have tried passive scanning but I'm only seeing regular advertising message and not the extended one.

Well that is weird then, are you sure the problem is not at the advertising end? If you are using BlueZ you might need the following change:

ea242fb

[iulia-tanasescu]

Some updated ideas:

[Vudentz]

Interesting ideia, so we don't really need something like assitant.scan since the general scan can cache the existing broadcasters? I guess that could work but don't we end up enumerating the objects twice if we do that? We first create the MediaTransport and then later the MediaSetup? Maybe that is fine since they are used for different purposes, and can actually coexist if the user decide to sync locally as well, that said Id probably use MediaAssistant as name to be consistent with bluetoothctl menu name.

[iulia-tanasescu]

After scanning a Broadcast Source, MediaTransports are only created if the user registered a local Broadcast Sink PAC (after short-lived PA sync, Broadcast Sink PACs are searched to match BIS caps).

So for a Broadcast Assistant, unless the user also registers a Broadcast Sink PAC, only MediaAssistants will be created for scanned BISes. It could be possible for a Broadcast Assistant to also act as a Broadcast Sink, but I think most use cases do not require this.

Either way, MediaTransports and MediaAssistants are used for different purposes and they could coexist if that's the case, but most likely MediaTransports won't be needed on a Broadcast Assistant.