Broadcast Isochronous Streams: Decide What Receiver Join and Resynchronization Must Prove
A broadcast receiver is not ready merely because it found periodic advertising. Readiness requires the intended BIG, the selected BIS streams, successful synchronization, usable data paths and valid application data. Keep evidence for each boundary so recovery does not reuse an old stream accidentally.
Applicability: Bluetooth Core 6.1 Broadcast Isochronous Group synchronization and Zephyr 4.2.0 ISO receiver APIs. The procedure targets a supported receiver using HCI data delivery. Audio-profile discovery, codec negotiation and presentation rules are additional contracts, not supplied by generic BIG synchronization. All fixtures are hypothetical and unexecuted.
1. Select the broadcast before creating stream state
Record the authorized broadcast selection, advertiser identity context, advertising SID, periodic-sync object and application generation. A familiar display name alone is not sufficient evidence that the correct broadcast has been selected.
Establish periodic advertising synchronization, then inspect BIGInfo. The LE BIGInfo Advertising Report describes fields such as number of BISes, PHY, framing, SDU interval, maximum SDU and encryption. It reports advertised BIG information, not successful reception of selected stream data.
Keep profile-level metadata separate. Knowing that a BIG contains three BISes does not tell a generic receiver which one represents a desired channel, measurement or language. That selection needs the product’s supported metadata contract.
Read controller capabilities, firmware and resource limits. A supported periodic-advertising path does not imply that the controller can synchronize to the requested number of BISes on the advertised PHY.
2. Make BIS selection and handle ordering explicit
Core’s LE BIG Create Sync command takes an ascending list of distinct BIS numbers. The requested count can be smaller than the total number advertised. Returned connection handles correspond to the requested list’s order.
For a hypothetical BIG with three BISes, request BIS 1 and BIS 3. If the successful event returns handles 0x0040 and 0x0041, the mapping is BIS 1→0x0040 and BIS 3→0x0041. Handle 0x0041 is not evidence that BIS 2 was selected.
The Zephyr parameter API represents selection as a bitfield. BT_ISO_BIS_INDEX_BIT(x) uses bit x-1, so BIS 1 and BIS 3 produce 0x05. Set num_bis to two and provide two channel pointers in the corresponding ascending selection order.
The exact implementation converts the bitfield into an ascending HCI list and checks that the selected-bit count matches num_bis. On success it assigns event handles to the stored channel list in order. Preserve that mapping in diagnostics and downstream consumer registration.
Do not confuse the host-assigned BIG handle, periodic advertising sync handle, BIS number and BIS connection handle. They identify different objects and have different lifetimes.
3. Separate request acceptance from synchronization
A successful command-status result accepts the BIG synchronization procedure. The subsequent LE BIG Sync Established event carries the procedure outcome. Check its Status before using timing fields or connection handles as established state.
In Zephyr 4.2.0, bt_iso_big_sync returns after the command path succeeds and leaves the BIS channels connecting. Its return value alone is not a completed-join signal. The established-event handler separately rejects a failed status or an unexpected BIS count and performs cleanup.
Validate encryption mode against BIGInfo and supply the authorized Broadcast Code when required. Core rejects an encrypted/unencrypted mode mismatch. Protect the code from logs; a received encrypted advertisement does not authorize guessing or exposing broadcast credentials.
Preserve actual failure status. Unsupported PHY, exhausted resources, an already allocated BIG handle and a synchronization timeout require different corrective actions. Repeating an unchanged unsupported request is not useful recovery.
4. Require the data path and first useful SDU
Core section 7.8.109 states that creating a connection does not set up its data paths. Qualify which stack layer installs the receive path and observe its success. For a synchronized receiver, the output direction is controller-to-host; HCI uses Data_Path_ID 0x00.
Use the selected stack’s supported setup interface and avoid issuing a duplicate path setup after another layer already configured it. Record the actual BIS handle, direction and path generation instead of assuming a connected callback implies every consumer is ready.
Then wait for a valid SDU from each required BIS and verify its application format. A loss marker, malformed payload or data from an old generation must not open the readiness gate.
If the application needs several BISes together, define its startup alignment and missing-stream policy. “One stream has data” is insufficient when the useful result requires two synchronized channels. Generic BIG synchronization does not specify the product’s buffering or presentation deadline.
5. Invalidate stream resources on BIG loss
LE BIG Sync Lost distinguishes timeout, remote termination and MIC failure through its reason. Core requires the controller to remove the affected BIS connection handles and data paths. Old handle values are no longer usable data-path identities.
The tagged Zephyr handler disconnects the BIG’s channels and cleans up the BIG. Its disconnected callback occurs before final channel cleanup, and the source warns against reusing or clearing the channel object inside that callback. Schedule recovery through the lifecycle owner after the supported cleanup boundary.
Track periodic advertising synchronization separately from BIG synchronization. A BIG-loss event does not itself prove that the periodic advertising sync was lost. Reuse a still-valid prerequisite only after checking its actual state and refreshing the relevant broadcast information.
On rejoin, allocate a new application generation, revalidate BIS selection and encryption policy, obtain fresh handles, establish data paths and require first valid SDUs again. Never restore readiness by copying the previous handle list.
6. Distinguish loss timeout from the acquisition result
BIG_Sync_Timeout uses ten-millisecond units and governs permitted time between successful BIS receptions. If the requested value is below six ISO intervals when synchronization is established, Core raises the effective timeout to that six-interval minimum.
Initial synchronization has its own specified outcome: if no BIS PDU is received within six BIS events of first listening, the controller generates an unsuccessful established event. Do not describe the configured loss timeout as the only acquisition deadline.
Give product-level join attempts a bounded policy while preserving controller procedure completion and cancellation semantics. LE BIG Terminate Sync can stop an established sync or cancel pending synchronization; pending cancellation also produces an established event with Operation Cancelled by Host.
7. Run the join/loss acceptance matrix
- Periodic sync without usable BIGInfo: remain unready.
- Valid BIGInfo and request acceptance, but failed establishment: retain the failure category without installing handles.
- Select BIS 1 and 3: verify the ordered two-handle mapping and both consumers.
- Successful synchronization with missing data-path setup: diagnose the path boundary rather than claiming RF loss.
- Remote termination, timeout and wrong-code/MIC failure: preserve distinct reasons and invalidate old paths.
- Rejoin while periodic sync remains valid, then repeat after periodic sync is lost.
- Deliver old-generation queued data after rejoin: verify it cannot satisfy startup readiness.
Acceptance requires a complete evidence chain from selected broadcast to usable current-generation data. That chain also gives resynchronization a precise finish line instead of treating any fresh advertising report as restored service.
