Core Spec v6.2 Channel Sounding — is Amplitude-based NADM supported on nRF54L15, and in which SDC/NCS version?

Setup

- nRF54L15DK running the hci_uart sample as an external HCI controller over H4 UART
- Host is a third-party BLE host (not Zephyr), driving CS over standard HCI
- NCS v3.3.1 (nrf/VERSION = 3.3.1), SoftDevice Controller from nrfxlib in that tree
- CS runs successfully end-to-end: initiator and reflector roles, mode-0/2 steps, ~130 steps/procedure, 4 antenna paths available

What we observe

On HCI_LE_CS_Read_Local_Supported_Capabilities and HCI_LE_CS_Read_Remote_Supported_Capabilities_Complete, the controller reports:

NADM_Sounding_Capability = 0x0000
NADM_Random_Capability = 0x0000

i.e. neither bit 0 (Phase-based NADM) nor bit 1 (Amplitude-based NADM) is set.

What the documentation says

1. nrfxlib/softdevice_controller/doc/channel_sounding.rst, table "CS feature support for the |controller|": Normalized Attack Detection
Metric is listed in the Not Supported column. "RTT with Sounding Sequence" is also Not Supported.
2. nrf/samples/bluetooth/channel_sounding/ipt_initiator/README.rst documents the expected output as phase_based_nadm_sounding_supported: no
and phase_based_nadm_random_supported: no, so zero NADM appears to be the intended behaviour.
3. However, nrfxlib/softdevice_controller/CHANGELOG.rst states under NCS v3.2.0: "The Version field in the LL_VERSION_IND packet now
contains the value 0x10 to indicate compatibility with Bluetooth Core Specification v6.2 (DRGN-26598)", and under NCS v3.3.1: value 0x11
for v6.3 (DRGN-28241).

Our questions

1. Bluetooth Core Spec v6.2 introduced exactly one new Channel Sounding feature: Channel Sounding Amplitude-based Attack Resilience, whose
entire host-visible surface is bit 1 of NADM_Sounding_Capability / NADM_Random_Capability (RFU in v6.0/v6.1). Does the SoftDevice
Controller implement this feature on any device today? If not, how should we interpret the v6.2/v6.3 LL_VERSION_IND claim — does it denote
full feature compliance, or only the Link Layer version field value?
2. Is Phase-based NADM (bit 0) implemented or planned on any nRF SoC? If planned, which SDC/NCS release and which device?
3. Is Amplitude-based NADM (bit 1, the v6.2 feature) on the roadmap? Which release and which device?
4. Is the absence of NADM a silicon/radio-DSP limitation of the nRF54L series, or a firmware-only gap that a future SDC release could fill
on existing nRF54L15 hardware? This determines whether we need different hardware.
5. NADM_Sounding_Capability concerns NADM on a CS_SYNC carrying a sounding sequence, and your table also lists "RTT with Sounding Sequence"
as Not Supported. Is NADM_Sounding_Capability therefore permanently blocked by that dependency, while NADM_Random_Capability could in
principle become non-zero independently?
6. Is there any currently shipping nRF SoC + SDC version combination that reports a non-zero value in either NADM capability field? If so,
we would like to obtain that hardware for interoperability testing.
7. Does the answer differ when the device is used as an external HCI controller via the hci_uart sample versus a Zephyr-host SoC
application? We assume not, since these are controller capabilities, but we would like that confirmed.

  • There is a difference between features and Bluetooth version numbers.

    To be compatible with a new version you need to be compliant with all mandatory features and this is typically all errata fixes. This means you also need to test with a new compliance test version.

    1. The stack is compliant with all mandatory features in Bluetooth 6.3. NADM is an optional feature and as you can see, we state we do not support it.

    2. Please contact your RSM, we do not share roadmap information on DevZone

    3. See above

    4 See above

    5. We do not support Sounding Sequences so any item requiring this will not be supported.

    6. None of the Nordic devices support NADM today, for roadmap issues contact your RSM.

    7. No, the limitations are in the controller side so will be same for internal or external host.

Related