LE Isochronous Data Loss: Distinguish Missing SDUs from Late Application Processing

A late sample is not necessarily a radio loss, and an ISO receive callback is not necessarily carrying usable data. Preserve the controller’s SDU status, the host delivery boundary and the consumer deadline decision as separate evidence.

Applicability: Bluetooth Core 6.1 HCI ISO data and ISOAL concepts, plus Zephyr 4.2.0 host ISO receive APIs. The worked diagnostic uses a supported connected ISO receive path with data delivered over HCI. Controller capabilities, firmware and data-path configuration must be established on the target. No ISO stream or timing experiment was executed.

1. Define the SDU and its useful deadline

Record stream generation, channel identity, configured SDU interval, maximum SDU size, direction and selected data path. Do not infer ISO support from ordinary BLE connection success or from the presence of an ISO API in a header.

Define what one SDU means to the product and when it becomes too late to use. That deadline can be a playback, measurement-processing or control-interface requirement. It is not automatically equal to the radio interval or the time the host callback occurs.

Use a stream-generation identifier in addition to the numeric handle and sequence number. Reconnection or recreation can reuse identifiers, and old queued data must not be compared with a new stream as though continuity were preserved.

Keep the initial experiment narrow: one receiving stream, one consumer and a known workload. Add concurrent streams only after the observation ledger explains the single-stream case.

2. Preserve the controller’s status classification

Core 6.1 section 5.4.5 defines three received HCI ISO status values. Valid data means the complete SDU was received correctly. Possibly invalid data can contain errors or have missing content. Lost data indicates parts were not received correctly.

For the lost-data status, the controller sends no data, marks the packet as a complete SDU and sets ISO_SDU_Length to zero. Do not classify that empty report as an ordinary zero-valued sample or reject it before accounting for the loss indication.

These flags describe the controller’s ISO receive result. They do not prove that an application consumed a valid sample before its deadline. Conversely, a consumer timeout cannot rewrite a previously valid controller status into a radio-loss result.

The Zephyr receive metadata exposes VALID, ERROR and LOST flag bits, plus a separate TS flag. Preserve the distinction in counters and downstream records. A possibly invalid payload requires an explicit product policy; it must not quietly enter a parser that assumes all input bytes are trustworthy measurements.

3. Separate HCI fragments from radio fragments

An HCI ISO Data packet can contain a whole SDU or one fragment. HCI fragmentation is separate from ISOAL fragmentation over the radio. Counting HCI packets as lost SDUs therefore gives the wrong denominator.

The first or complete HCI fragment carries the SDU sequence number, total SDU length and status, with an optional timestamp. Intermediate and final fragments omit those fields. A trace decoder must associate fragments with the current handle and reassembly state.

The tagged Zephyr bt_iso_recv implementation extracts metadata from the first or single fragment, accumulates continuation data and invokes the channel receive callback through the assembled buffer path. Unexpected fragment ordering and insufficient buffer space have separate reset/drop branches.

A sequence gap visible only at the application can therefore have several explanations: controller-reported loss, an HCI/reassembly failure, host resource pressure or a dropped application queue entry. Locate the earliest boundary where the SDU disappears before assigning a cause.

Use the 16-bit sequence field with wrap-aware, generation-scoped analysis. Record explicit lost indications separately from inferred gaps, and do not count the same expected SDU once as a gap and again as a received loss marker.

4. Keep controller and host time domains explicit

The HCI timestamp is a 32-bit microsecond field whose timing semantics are defined by ISOAL section 3. It is not a host monotonic-clock reading. Establish a clock mapping and uncertainty before subtracting it from an application timestamp.

Zephyr says the timestamp is usable only when BT_ISO_FLAGS_TS is set. The inspected receive code assigns zero when the field is absent. That zero is an implementation placeholder, not proof that the SDU originated at time zero.

Record host monotonic times independently at callback entry, queue admission and consumer completion. Those timestamps can establish host-side residence time even when no trustworthy controller-to-host clock mapping exists.

Account for timestamp wrap in any longer capture. Preserve the mapping generation and avoid carrying an old clock offset through a controller restart without requalification.

5. Diagnose a three-record hypothetical trace

Suppose SDU 100 arrives with VALID status at host time 1002 ms, is admitted to the queue at 1003 ms and finishes consumption at 1014 ms. If its product deadline is 1012 ms, it is two milliseconds late despite a valid transport result.

Suppose SDU 101 arrives with LOST status and zero data length. Count a controller-reported loss indication and apply the product’s missing-sample policy. Do not calculate a normal payload-processing duration for nonexistent data.

Suppose SDU 102 arrives with ERROR status and nonempty data. Preserve “possibly invalid” rather than calling it either a clean sample or necessarily a wholly missing SDU. The consumer may discard or conceal it under its explicit policy.

These are illustrative records, not measurements. Their value is the classification: transport-valid but late, transport-lost, and transport-possibly-invalid. Keep a fourth category for local queue rejection when a callback delivered valid data but the application could not retain it.

6. Separate two fault experiments

1. Capture a baseline with supported settings, bounded callback work and a consumer that meets its deadline.
2. Deliberately slow only the consumer in an isolated test. Observe queue residence, overflow policy and deadline misses while retaining controller status unchanged.
3. Restore the consumer, then use an authorized controlled RF impairment. Observe controller status and HCI evidence without assuming every missing callback is RF loss.
4. Exercise host buffer pressure and fragmented SDUs separately to expose local reassembly or allocation losses.
5. Repeat without timestamp presence and across sequence/timestamp wrap boundaries in a supported replay harness.
6. Recreate the stream while old work is queued; verify generation separation and safe buffer retirement.

The metadata pointer’s lifetime is linked to its net_buf. Copy the small diagnostic fields before deferred processing, and use the stack’s documented buffer ownership rules if retaining payload storage. Avoid blocking the receive callback while waiting for the consumer.

Acceptance requires separate counts for valid, possibly invalid and lost SDUs, local delivery/queue failures, and consumer deadline misses. That record directs remediation toward RF, HCI transport, host resources or application scheduling instead of hiding every failure behind one “ISO packet loss” percentage.