Bluetooth: Channel Sounding: Add several channel sounding HCI commands

[olivier-le-sage]

Adds HCI support for:

• LE CS Read Remote Supported Capabilities
• LE CS Read Remote FAE Table
• LE CS Test

[jhedberg]

I'd like to see some kind of high-level architectural picture/plan for this feature. At the moment it seems like you're mapping HCI 1:1 to new Zephyr Bluetooth APIs, but that's not necessarily the most suitable or convenient abstraction for higher-level users (e.g. GATT services or whatever else will be the consumer of these APIs).

[theob-pro]

I'd like to see some kind of high-level architectural picture/plan for this feature. At the moment it seems like you're mapping HCI 1:1 to new Zephyr Bluetooth APIs, but that's not necessarily the most suitable or convenient abstraction for higher-level users (e.g. GATT services or whatever else will be the consumer of these APIs).

From my understanding it's best to have a direct access to those HCI commands like that, the "real" work will be done by the profile. It's best to avoid doing too much magic in the Host so it can stay as simple as possible.

[jhedberg]

From my understanding it's best to have a direct access to those HCI commands like that, the "real" work will be done by the profile. It's best to avoid doing too much magic in the Host so it can stay as simple as possible.

I agree that it's often the case, but not necessarily always. It'd help a lot to see the API used in practice (not just in the shell). What we have now is a new API with no in-tree users (not counting the shell commands). There are no sample applications or tests in this PR. This is the second CS PR, and I assume there are still more to come - I just wonder at what point the "big picture" will start to emerge.

[theob-pro]

I agree that it's often the case, but not necessarily always. It'd help a lot to see the API used in practice (not just in the shell). What we have now is a new API with no in-tree users (not counting the shell commands). There are no sample applications or tests in this PR. This is the second CS PR, and I assume there are still more to come - I just wonder at what point the "big picture" will start to emerge.

I understand your concern and that's exactly why imo, the less the Host do, the more it will be able to fit in the different use cases that the users will come with. I agree with you, having use cases from user would be better but CS is quite new and until someone implement the profile there will be no real users.
In the worst case the API is marked as experimental and can be changed at any time if we realize that there is something fundamentally wrong with what we have done.

[bugo-nordic]

It is a bit inconsistent that we stopped mapping the bits into booleans beyond this member. Is it intentional?

Should we instead always use the full value and just add bitmask macros?

[jhedberg]

That's a fair point. What's the rationale here?

[olivier-le-sage]

I'd like to see some kind of high-level architectural picture/plan for this feature. At the moment it seems like you're mapping HCI 1:1 to new Zephyr Bluetooth APIs, but that's not necessarily the most suitable or convenient abstraction for higher-level users (e.g. GATT services or whatever else will be the consumer of these APIs).

For the LE CS Test command at least, there's no upper layers that build upon it afaik. It's largely independent from the rest of the feature. I expect it will be used for demo applications and regression/interop testing (or similar) so I expect this part of the API to be used directly in apps.

But let me try to give some more info about our plans so that it's hopefully more clear what comes next after this PR. In general our vision for this work is to implement relatively little logic in the zephyr BLE host for this feature. We're implementing:

• HCI wrappers and callbacks for the commands and events
• Subevent result recombination
• Some basic samples to demonstrate setting up CS Test and ACL-based CS.

In the nordic fork we'll be implementing the Ranging Profile (RAP https://www.bluetooth.com/specifications/specs/ranging-profile/ ) and Ranging Service (RAS https://www.bluetooth.com/specifications/specs/ranging-service/) used to exchange CS data over ACLs, so we will also be working to ensure these APIs are as useful as possible to upper layers. There are some good diagrams in those documents showing some interactions between host and controller