bt_conn disconnect callback delay (5–10s) blocking parallel PAwR onboarding for 200+ devices on nRF54L15

[Dinesh Damodar01]

We're implementing a PAwR (Periodic Advertising with Responses) based onboarding flow for a large fleet of devices (target: 200+ nodes, eventually scaling to 1000s) and are hitting a connection-object lifecycle bottleneck. Details below.

SDK / Environment

• nRF Connect SDK version: NRF 3.2.4
• Target chip: nRF54L15

Use case

• We scan for devices matching a fixed name filter.
• Once a batch of ~10 devices is discovered, we spin up parallel threads, each handling one device's onboarding sequence: connect → write PAwR sync timing → disconnect.
• This is repeated across the full device population (200+ now, 1000s eventually).

Problem
After calling bt_conn_disconnect(), it takes approximately 5–10 seconds for the disconnect callback itself to fire and for the underlying bt_conn object to be freed/released. Until that happens, the connection slot is unavailable, and we can't initiate the next connect using it. This severely throttles our parallel onboarding throughput across 200+ devices.

What we've tried

• Manually nulling/dereferencing the bt_conn pointer after calling disconnect — this doesn't force the underlying Zephyr object to free any faster; it just orphans our reference while the pool slot is still held internally, which risks a leak/resource exhaustion.

Questions

1. Is the 5–10 second gap between calling bt_conn_disconnect() and the disconnect callback firing expected on nRF54L15? What determines this duration (e.g., supervision timeout, connection interval, link-layer termination procedure)?
2. Is this delay tunable — e.g., via connection parameters (interval, supervision timeout) negotiated at connect time — so we can shrink it for onboarding-type short-lived connections?
3. Is there a way to detect via callback (bt_conn_cb.recycled) exactly when the connection object/slot is freed, instead of guessing or polling with a fixed delay?
4. For high-parallelism onboarding across large device fleets, is there a recommended pattern for connection-slot pooling in Zephyr (sizing CONFIG_BT_MAX_CONN, using the recycled callback to trigger the next connect immediately once a slot frees) rather than waiting out a fixed delay?
5. Does PAwR/periodic sync teardown add any additional delay on top of the standard disconnect procedure that we should account for?
6. Are there known constraints on how many PAwR subevents/responses can be reliably handled per sync cycle when onboarding devices in parallel batches, that we should account for in our batching strategy?

Any guidance on the correct lifecycle handling here, or pointers to relevant Zephyr BT connection pool internals, would be much appreciated.

Thanks!