## Environment
- nRF Connect SDK v3.4.0-99553055607b, Zephyr v4.4.0-bf801e4e3d19
- SoftDevice Controller on the nRF5340 network core (`ipc_radio`,
`CONFIG_BT_LL_SOFTDEVICE=y`), HCI reports "Standard Bluetooth controller
(0x00) Version 200.12506 Build 888207768"
- Reproduced in BabbleSim (`nrf5340bsim`, `bs_2G4_phy_v1 -dump`). It is also
seen on hardware (nRF5340 Audio DK, BlueZ central), where the link later
ended with 0x28 (Instant Passed) or 0x08.
## Setup
- DUT: peripheral, synchronized to a BIG (10 ms ISO interval, one BIS), PA
synced. No CIS.
- Central: a second device (SDC central in bsim) on a 1001.25 ms (801 units)
connection to the DUT.
- The DUT host asks for 11 units (13.75 ms) through the connection parameter
update procedure. The central sends:
`LL_CONNECTION_UPDATE_IND winSize=1 (1.25 ms) winOffset=0 interval=11
latency=0 timeout=600 (6 s)`.
## Observed (phy dump, link access address 0xE8CB3499)
BIG held at the switch:
```
95.044075 DUT rx link st=1 last packet on the old 801-unit timing
96.045459 CEN tx (no DUT rx window)
97.046709 CEN tx first new 13.75 ms anchor; no DUT rx window
97.047936 DUT rx BIG BIG event 1.2 ms later
97.060458 CEN tx no DUT rx window (clear of the BIG events at .0579/.0679)
97.074208 CEN tx no DUT rx window
... 137 central events from 96.9 s to 99.0 s, 0 DUT receive windows on the link
99.026185 DUT rx link st=1 first window, then about 85 to 95 % of events received
```
Per 0.5 s bin: the central sends 31 to 35 events, and the DUT opens 0 windows
from 96.0 s to 99.0 s. From 99.0 s on it opens 20 to 24 windows and receives
18 to 22.
The same update with the BIG terminated by the host until the new anchors are
on air: the DUT opens a window on the first new anchor (`95.044075 DUT rx link
st=1`, central tx `95.044209`), keeps 27 of 32 events in the next 0.5 s, and
the link stays up with a 2 s timeout.
With `timeout=200` (2 s) and the BIG held, the peripheral disconnects with
0x08 1.0 s after reporting the update. The 2 s supervision timer runs from the
last packet, one old 1 s event before the instant.
## Expected
The BIG has priority over the ACL, so losing the first anchor (window plus
widening overlapping the BIG event) is understood. After that, the 13.75 ms
anchors walk all phases of the 10 ms BIG, and most of them are clear. The
peripheral should keep opening its (widened) window on each following anchor
until it receives a packet, as it does when the BIG is not running. Instead it
schedules nothing on the link for about 2 s (6 s timeout) or until the link
times out (2 s timeout).
## Impact
- A 1 s link moved to a short interval under a synchronized BIG is deaf for
seconds. With 2 s supervision it drops (0x08). With 6 s it survives, but on
hardware a later procedure's instant was then missed (0x28).
- The workaround in our application: never let such an update take effect
while a BIG is synchronized (keep the link on its long interval, or stop the
BIG through the switch), and keep a released BIG off for one old interval
after LE Connection Update Complete, because that event comes up to one old
interval before the new anchors start.
## Questions
1. Is skipping every anchor after a missed post-update transmit window,
while a BIG is synchronized, intended scheduling? Or is the link meant to be
retried on later non-conflicting anchors?
2. Is there a parameter (event priority, window widening policy) that makes
the peripheral keep retrying?
## Reproducer
A 4-node bsim scenario (source, DUT sink, LE Audio phone model, second
central) plus the phy-dump analysis scripts (`anchors.py`, `edge.py`,
`conn_update_ind.py`) are available on request. They live in a private repository.
