NCS 3.3.0 - BLE QoS channel survey

[longo92]

In the nRF Connect SDK v3.3.0 release notes, I noticed that the QoS Channel Survey feature has transitioned from experimental to supported (i.e., production-ready).

From what I understand, it can be enabled via the following Kconfig option:
github.com/.../Kconfig

For one of our client products based on the nRF52833 and using BLE Long Range (Coded PHY S=8), we expect operation in potentially congested RF environments. As such, this feature could be relevant for improving link robustness and channel utilization.

Each device is both central/peripheral. Each central connects to the same device using coded PHY.

Each device transmits two advertisements carrying the same payload:

• A legacy advertisement (on 1M PHY) with an associated scan response, to maintain compatibility with smartphones.
• An extended advertisement on the Coded PHY. Thanks to the increased payload capacity of extended advertising, the data typically placed in the legacy scan response is instead included directly within the extended advertising packet.

Could you clarify:

• • Whether QoS Channel Survey is fully supported and stable when using Coded PHY (S=8)?
  • Is this feature intended for the central role (as stated here: https://github.com/nrfconnect/sdk-nrfxlib/blob/v3.3.0/softdevice_controller/README.rst).Could you please clarify how it works in detail? 
  • Any limitations or considerations when using it in long-range configurations?
  • Recommended configuration or integration approach for this use case?
  • Given that the device is battery-powered, what is the expected impact on power consumption when this feature is enabled?
  • From an implementation perspective, is enabling CONFIG_BT_CTLR_SDC_QOS_CHANNEL_SURVEY=y sufficient, or is additional application-level code required to start, manage, and process the survey data?
  • Is there a sample i can use as reference?

Thanks,

Alessandro

[Edvin]

Hello,

The QoS doesn't really care about what PHY you are using. It measures energy (noise/traffic) on the different channels, and provides them in an event: BLE_GAP_EVT_QOS_CHANNEL_SURVEY_REPORT when QoS is enabled.

It is then up to the application to analyze these events and take action. It does not happen automatically.

To answer your questions regarding central/peripheral: It really makes the most sense to run this on the central of the application, because this is the device that ultimately decides the channel map for that connection. I guess you could run it on a peripheral, and request a channel map update, but the best would be to run it on the central for that connection.

Again, it doesn't really care what PHY you are using. It measures how much traffic there is on the different channels, so that would apply to all PHYs, really.

Regarding battery consumption: This will make the device use the radio more than when it is not enabled. It is a low-priority task, so it shouldn't affect the link quality, since it will be scheduled for whenever it has time, and it will be down-prioritized if the scheduler detects collisions. But it will use the radio. I am not sure about the numbers, but you could measure this using the Power Profiler kit.

From an implementation perspective, is enabling CONFIG_BT_CTLR_SDC_QOS_CHANNEL_SURVEY=y sufficient, or is additional application-level code required to start, manage, and process the survey data?

The short answer is "no", but I guess we already covered this.

Is there a sample i can use as reference?

I think there isn't any samples showing how this is used. In fact, no samples in NCS have CONFIG_BT_CTLR_SDC_QOS_CHANNEL_SURVEY=y. The only reference I could find was this, from my colleague, Hung:
RE: Cannot enable BLE HCI survey

Best regards,

Edvin

[longo92]

Thanks for the detailed response. All clear.

I can update the channel map in similar way like in github.com/.../ble_qos.c ? (In this case QoS on connection report is used, but should have same approach I think)