Reduce time to start channel sounding

[nikeub]

We have an application where response time is critical, and we are trying to minimize the time from advertising to an active channel sounding session.

What we have already optimized:

• Connection interval set to 7.5 ms
• Advertising interval reduced to 100 ms (can't go lower to remain within power constraints)
• Skip GATT discovery by hard-coding the GATT handles
• Bonding enabled to reduce secure connection setup time

This brings us down to around ~450 ms.

Now we are looking at what else we can do, and hope you can clarify what's possible.

• CS config/capabilities exchange takes ~100 ms.
  • Our understanding is that per BLE specification, this can be avoided by pre-storing a known configuration on both sides.
  • Does Noridc stack support or plan to support this?
• MTU exchange takes ~37 ms.
  • Default MTU size is 23 and we must increase it for faster data exchange between reflector and initiator.
  • Is there any way to hard-code the MTU size beforehand?
• CS security (bt_le_cs_security_enable) takes ~30 ms
  • Is there anything we can do to reduce this? E.g. piggy-backing on the existing secure connection, skipping DRBG?

[Simonr]

Hi

It does not seem to be possible to cache the MTU exchange and CS security within the BLE specification at least, but some more information on the CS capabilities. It should be possible to use the LE CS Write Cached Remote Supported Capabilities command if the peer's capabilities are known. It's also possible to use the LE CS Create Config command with Create_Context=0 if both devices create a pre-defined identical configuration.

Any further changes I think might be breaking with the BLE specification. What's the target time you're looking at for getting a Channel Sounding session started? And is this just one to one pairing, or are you planning on having multiple devices being tracked regularly which is why the timing is critical?

Best regards,

Simon

[nikeub]

The timing is critical since this is used for an access control use case. We need to determine quickly if a person is close. From scan to connect we are aiming for something closer to 300 ms.

I tried compile-time hardcoding the capabilities struct and calling HCI_LE_CS_Write_Cached_Remote_Supported_Capabilities on both sides, but then bt_le_cs_procedure_enable fails with status 0x1E. Should this be possible, or does at least one capabilities exchange need to happen after reboot before calling write cached?

I also noticed that even if I optimize everything before the CS functions, I eventually get capped by bt_le_cs_security_enable. It seems like it’s blocked on something underlying that the SDC is doing.

As a test, I stripped the path down to bare minimum to rule stuff out (no capabilities exchange, config, subscribe, discovery, etc.) and just called bt_le_cs_security_enable, but it took ~82 ms. If I add delay ~100 ms sleep before calling it, the time to execute it drops to ~27 ms. Any idea what could be causing that?