Re: [RFC] ranging: starting a Channel Sounding session for a peer without a Ranging Service

[Cheng Jiang <cheng.jiang@oss.qualcomm.com>]

Hi Luiz,

Could you please help to review this proposal? Thank you!

On 10/29/2026 6:23 PM, Cheng Jiang wrote:
> Hi Luiz,
> 
> I would like to ask about the intended design before sending any code.
> 
> Background
> ==========
> 
> profiles/ranging/rap.c creates the CS session (rap_data, the HCI state
> machine and the org.bluez.ChannelSounding1 object) from the RAP profile
> probe, i.e. only for a peer that exposes the Ranging Service (0x185B).
> 
> Channel Sounding itself is a Link Layer feature and does not depend on a
> GATT service. GAP.TS 4.7.11 (GAP/CS/BV-01-C) only requires that the
> Lower Tester has the CS feature bit and that the link is encrypted. The
> Lower Tester in that test exposes GAP/GATT only, so no RAP probe ever
> runs, no ChannelSounding1 object appears for the device, and bluetoothctl
> "cs" has nothing to call "start" on.
> 
> What a CS start needs from the host, besides the RAS path:
> 
>   - a peer whose Controller supports CS (LE feature bit 46, Core 6.2
>     Vol 6 Part B 4.6);
>   - the ACL connection handle;
>   - for LE CS Security Enable (Vol 4 Part E 7.8.133): an encrypted link
>     (otherwise 0x2F), the local Controller being Central (otherwise
>     0x0C, since the Central's Link Layer starts the Security Start
>     procedure, Vol 6 Part B 5.1.23), and the local Channel Sounding
>     (Host Support) bit 47 being set (otherwise 0x0C).
> 
> Question 1: where should this live?
> ===================================
> 
> The session is tied to a btd_service today, and is torn down by
> rap_remove(). A session that has no RAP service is not owned by any
> btd_service, so it needs its own teardown (e.g. on device removal) and
> its own lookup of the connection handle. That works against the usual
> profile model.
> 
> Is profiles/ranging the right home for a use that is independent of any
> GATT service, or should the "peer supports CS" knowledge and the session
> creation sit at adapter/device level, with the profile only consuming it?
> 
> Question 2: what should trigger the session?
> ============================================
> 
> I see three options and would like your preference:
> 
>   a) Automatically, when the peer's LE features show the CS bit.
>      No user action, but a ChannelSounding1 object appears for every
>      CS-capable peer whether or not anybody wants to range, and it relies
>      on observing the remote-features completion event.
> 
>   b) No new API. org.bluez.ChannelSounding1 is registered on the device
>      object automatically whenever the device is connected and the local
>      Controller supports CS, no longer only after a RAP probe. This is
>      only a D-Bus object: it sends no HCI command and does not read the
>      peer's features. The CS state (HCI state machine, connection handle)
>      is created lazily when StartMeasurement() is called, and that call
>      fails if the link is gone. The link does not have to be encrypted
>      yet: as today, LE CS Security Enable is deferred until the
>      Encryption Change event. The cost is that the interface shows up on
>      every connected device of a CS-capable adapter, without checking
>      the peer.
> 
>   c) A new method that creates the session on demand, e.g.
>      Adapter1.StartChannelSounding(object device), as RemoveDevice()
>      already takes a device path. Nothing is registered on the device
>      before the call; afterwards ChannelSounding1 appears on the device
>      object and is used as today. It fails with NotConnected if the
>      device has no ACL connection. A client such as bluetoothctl can
>      hide the two steps behind its existing "start" command. I found no
>      existing call that could carry this without a new entry point, so
>      true on-demand costs one new D-Bus method.
> 
> GAP.TS 4.7.11 has the Upper Tester order the IUT to start the CS
> procedure after connection and encryption, so an explicit trigger from
> the user (b or c) fits that test.
> 
> I lean towards (b) because it adds no new API and no hidden state beyond
> the interface itself. If an interface on every connected device is not
> acceptable, (c) is my fallback. Which would you prefer?
> 
> What I am not proposing
> =======================
> 
> No change to the RAS-triggered path, and no behaviour change for existing
> users. Defaults such as the CS PHY are out of scope here.
> 
> I have a working implementation of (a) as part of certification work, but
> I do not think it is what you would want upstream, so I am holding it
> back until the direction is agreed.
> 
> Thanks,
> Cheng Jiang