Deep Dive into Bluetooth LE Audio's BIS and BIG: Synchronization, Retransmission, and Buffer Management in Unreliable Channels
Bluetooth Low Energy (LE) Audio, ratified in Bluetooth Core Specification v5.2, revolutionizes wireless audio by introducing the Isochronous Adaptation Layer (ISOAL) and the concepts of Broadcast Isochronous Streams (BIS) and Broadcast Isochronous Groups (BIG). Unlike classic Bluetooth Audio (A2DP/AVRCP), which relies on point-to-point synchronous connections, LE Audio leverages a broadcast model for true one-to-many audio distribution. This is the backbone of Auracast. However, the unreliable nature of the 2.4 GHz ISM band—rife with interference from Wi-Fi, Zigbee, and microwave ovens—demands robust synchronization, retransmission, and buffer management strategies. This article dissects the inner workings of BIS and BIG, focusing on the timing-critical mechanisms that ensure glitch-free audio delivery over flaky channels.
1. The BIS/BIG Architecture: Timing and Frame Structure
A BIS (Broadcast Isochronous Stream) carries a single logical audio stream (e.g., left channel, right channel, or a mixed mono stream). A BIG (Broadcast Isochronous Group) aggregates one or more BIS streams that share a common timing reference. The key is the BIG Anchor Point—a periodic event (every ISO_Interval) that defines the start of a transmission window. Inside this window, each BIS gets a dedicated sub-event slot.
The timing is dictated by three parameters:
- ISO_Interval: The time between successive BIG anchor points (in 1.25 ms units, range 5 ms to 4 s). For audio, typical values are 10 ms (for 100 Hz delivery) or 20 ms.
- BIS_Space: The gap between consecutive BIS sub-events within a BIG event (in microseconds).
- Sub-Event Length: Maximum duration of a single BIS sub-event, including preamble, access address, PDU, and CRC.
The critical challenge: the receiver must lock onto the BIG anchor point with microsecond precision. The transmitter uses BIG Channel Map and BIG Channel Index to hop across 40 BLE channels (0-39, with 3 advertising channels excluded for isochronous). The receiver must track this hopping sequence in lockstep.
2. Synchronization Mechanism: The BIG Anchor Point Lock
When a receiver (scanner) discovers a BIG, it must synchronize to the anchor point. The process begins with the BIGInfo Advertising Data sent on the primary advertising channels (37, 38, 39). This data contains:
BIG_Offset: Time offset from the advertising event to the first BIG anchor point.BIG_Sync_Timeout: Maximum time the receiver will attempt to sync before declaring failure.BIS_Sync_Info: Per-BIS parameters like SDU interval, framing mode (unframed vs. framed), and codec ID.
The receiver uses a windowed correlator to detect the BIG anchor point's access address (a 32-bit value unique to the BIG). Once detected, it enters a tracking phase where it adjusts its clock based on the observed drift. The spec mandates a maximum clock drift of ±50 ppm, but over a 10-second sync timeout, this can accumulate to ±500 µs—a significant fraction of a 10 ms ISO_Interval.
Code snippet: A simplified BIG sync state machine in C:
#include <stdint.h>
#include <stdbool.h>
typedef enum {
BIG_SYNC_IDLE,
BIG_SYNC_SEARCHING,
BIG_SYNC_TRACKING,
BIG_SYNC_LOCKED,
BIG_SYNC_FAILED
} big_sync_state_t;
typedef struct {
uint32_t anchor_point_us; // Expected anchor point in us
uint16_t iso_interval_us; // ISO_Interval in us
uint8_t bis_count; // Number of BIS in BIG
uint8_t current_channel; // Channel index (0-39)
int32_t clock_drift_ppm; // Estimated drift
big_sync_state_t state;
} big_sync_t;
bool big_sync_update(big_sync_t *sync, uint32_t rx_time_us, uint8_t channel) {
switch (sync->state) {
case BIG_SYNC_IDLE:
// Start search: wait for BIGInfo advertising
sync->state = BIG_SYNC_SEARCHING;
break;
case BIG_SYNC_SEARCHING:
// Correlate received access address
if (access_address_match(rx_time_us)) {
sync->anchor_point_us = rx_time_us;
sync->current_channel = channel;
sync->state = BIG_SYNC_TRACKING;
return true;
}
break;
case BIG_SYNC_TRACKING:
// Verify next anchor point within window
uint32_t expected = sync->anchor_point_us + sync->iso_interval_us;
int32_t delta = (int32_t)(rx_time_us - expected);
if (abs(delta) > MAX_SYNC_WINDOW_US) {
sync->state = BIG_SYNC_FAILED;
return false;
}
// Update drift estimate using low-pass filter
sync->clock_drift_ppm += (delta * 1000) / sync->iso_interval_us;
sync->anchor_point_us = rx_time_us;
sync->current_channel = channel;
sync->state = BIG_SYNC_LOCKED;
break;
case BIG_SYNC_LOCKED:
// Track continuously; adjust for drift
uint32_t predicted = sync->anchor_point_us + sync->iso_interval_us
+ (sync->clock_drift_ppm * sync->iso_interval_us) / 1000000;
// Open receive window early/late based on drift
if (abs((int32_t)(rx_time_us - predicted)) > MAX_TRACK_ERROR_US) {
sync->state = BIG_SYNC_FAILED;
return false;
}
sync->anchor_point_us = rx_time_us;
sync->current_channel = channel;
break;
default:
break;
}
return true;
}3. Retransmission Strategy: The BIG Retransmission Buffer
Unlike LE Audio's connected isochronous streams (CIS), which use ARQ (Automatic Repeat reQuest) with acknowledgment, BIS is a broadcast—there is no feedback channel. Retransmissions are proactive and based on a BIG Retransmission Buffer. The transmitter stores the last N SDUs (Service Data Units) and repeats them in subsequent sub-events. The receiver uses a sliding window to reconstruct the original order.
The key parameters are:
- BIG_Retransmission_Count: Number of retransmission attempts per SDU (0-15). Typical values: 2-4 for audio.
- BIG_Retransmission_Mode: Either "sequential" (retransmit immediately after the original) or "interleaved" (distribute across multiple ISO intervals).
- BIS_SDU_Interval: Time between consecutive SDUs on a given BIS (e.g., 7.5 ms for 48 kHz/16-bit stereo).
Consider a 10 ms ISO_Interval with 2 retransmissions. The transmitter sends the same SDU in sub-event slots 0, 1, and 2 of the same BIG event. The receiver must handle duplicates—it uses a sequence number (embedded in the BIS PDU header) to deduplicate. If all three copies are lost, the receiver faces a gap, which must be handled by concealment (e.g., packet loss concealment in LC3 codec).
Performance analysis: The probability of losing an SDU after R retransmissions is:
- P_loss_single = channel packet error rate (PER), e.g., 10% (0.1).
- P_loss_after_R = (PER)^(R+1). For R=2, P = 0.1^3 = 0.001 (0.1%).
- For R=4, P = 0.1^5 = 0.00001 (0.001%).
However, retransmissions increase airtime and power consumption. The optimum R balances PER against latency budget. For a 10 ms ISO_Interval and 2 retransmissions, the maximum delay from first transmission to last retransmission is 3 × sub-event length (e.g., 3 × 400 µs = 1.2 ms). This is well within the 20-40 ms end-to-end latency budget for Auracast.
4. Buffer Management: Jitter and Underrun Protection
The receiver must buffer incoming SDUs to smooth out jitter caused by retransmissions, channel hopping, and clock drift. The buffer is a circular FIFO with a depth of D SDU frames. The fill level varies:
- Minimum fill: When retransmissions succeed early, the buffer is near empty.
- Maximum fill: When retransmissions consume all slots, the buffer fills up.
The buffer management algorithm must prevent underrun (buffer empty when audio engine requests data) and overrun (buffer full, causing dropped SDUs). The classic approach is a playout delay—the receiver waits until the buffer reaches a target fill level (e.g., 80% of D) before starting audio playback. This adds a fixed latency but ensures continuity.
Code snippet: A simplified buffer manager for one BIS:
#include <stdint.h>
#include <stdbool.h>
#define BUFFER_DEPTH 16 // Number of SDU slots
#define TARGET_FILL 12 // 75% of depth
typedef struct {
uint8_t sdu[240]; // Max SDU size for LC3 (240 bytes for 48 kHz/16-bit)
uint16_t seq_num; // Sequence number from PDU
bool valid; // True if SDU is present
} sdu_slot_t;
typedef struct {
sdu_slot_t slots[BUFFER_DEPTH];
uint8_t write_idx; // Next insertion point (mod BUFFER_DEPTH)
uint8_t read_idx; // Next read point for audio engine
uint8_t fill_level; // Number of valid SDUs
bool started; // True if playback has begun
} bis_buffer_t;
bool bis_buffer_insert(bis_buffer_t *buf, uint8_t *sdu, uint16_t seq_num, uint16_t sdu_len) {
// Check for duplicate (already have this seq_num)
for (int i = 0; i < BUFFER_DEPTH; i++) {
if (buf->slots[i].valid && buf->slots[i].seq_num == seq_num) {
return false; // Duplicate, ignore
}
}
// Insert at write index
memcpy(buf->slots[buf->write_idx].sdu, sdu, sdu_len < 240 ? sdu_len : 240);
buf->slots[buf->write_idx].seq_num = seq_num;
buf->slots[buf->write_idx].valid = true;
buf->write_idx = (buf->write_idx + 1) % BUFFER_DEPTH;
buf->fill_level++;
// Start playback once target fill reached
if (!buf->started && buf->fill_level >= TARGET_FILL) {
buf->started = true;
// Signal audio engine to begin consumption
}
return true;
}
bool bis_buffer_read(bis_buffer_t *buf, uint8_t *out_sdu, uint16_t *seq_num) {
if (!buf->started || buf->fill_level == 0) {
return false; // Underrun condition
}
// Find the oldest valid SDU by sequence number (assumes monotonic)
uint8_t oldest_idx = buf->read_idx;
uint16_t oldest_seq = buf->slots[oldest_idx].seq_num;
for (int i = 0; i < BUFFER_DEPTH; i++) {
if (buf->slots[i].valid &&
(buf->slots[i].seq_num < oldest_seq || !buf->slots[oldest_idx].valid)) {
oldest_idx = i;
oldest_seq = buf->slots[i].seq_num;
}
}
if (!buf->slots[oldest_idx].valid) {
return false; // No valid SDU (should not happen if fill_level > 0)
}
memcpy(out_sdu, buf->slots[oldest_idx].sdu, 240);
*seq_num = buf->slots[oldest_idx].seq_num;
buf->slots[oldest_idx].valid = false;
buf->fill_level--;
buf->read_idx = (oldest_idx + 1) % BUFFER_DEPTH;
return true;
}5. Performance Analysis: Latency vs. Robustness Trade-offs
We evaluate a typical Auracast scenario: 48 kHz/16-bit stereo (96 kbps per channel) using LC3 codec at 10 ms frame size. The ISO_Interval is 10 ms, with 2 retransmissions per SDU. The channel PER is 10% (typical for indoor environments with Wi-Fi interference).
- Raw PER per SDU: 10% (single transmission).
- Effective PER after 2 retransmissions: 0.1^3 = 0.1%.
- Average retransmission delay: 0.5 × (sub-event length) per retransmission. With sub-event length = 400 µs, total average delay = 1.2 ms.
- Jitter (standard deviation of arrival time): Due to variable retransmission success, jitter can be up to 1.2 ms. The buffer depth D=16 frames (160 ms) provides a playout delay of 12 frames (120 ms) to absorb this.
- End-to-end latency: 10 ms (codec frame) + 1.2 ms (retransmission) + 120 ms (buffer) ≈ 131 ms. This is acceptable for public address systems but too high for gaming. Reducing buffer to D=8 frames (80 ms) gives 91 ms latency but increases underrun risk to 1% (for the same PER).
Throughput overhead: With 2 retransmissions, the total airtime per SDU is 3× the original. For a 400 µs sub-event, this is 1.2 ms per 10 ms interval, yielding 12% duty cycle. At 96 kbps, the raw data rate is 96 kbps × 3 = 288 kbps over the air. This is efficient compared to classic Bluetooth's 1 Mbps SBC.
6. Advanced Topics: Channel Diversity and Adaptive Retransmission
Modern LE Audio stacks implement channel quality estimation to adapt retransmission count per BIG event. The receiver measures RSSI and PER on each of the 37 data channels and reports this via the BIG Channel Quality Report (a vendor-specific HCI command). The transmitter can then:
- Increase retransmission count on noisy channels.
- Skip retransmissions on high-quality channels to save power.
- Remap the channel map to avoid persistently bad channels.
This dynamic approach reduces average airtime by 20-30% compared to fixed retransmission, as shown in experimental studies (e.g., IEEE 802.15.1-2021 testbed).
Conclusion
BIS and BIG in Bluetooth LE Audio represent a sophisticated trade-off between synchronization precision, retransmission robustness, and buffer-induced latency. The broadcast nature eliminates the pairing overhead of classic Bluetooth, but demands careful clock drift compensation and proactive retransmission. For developers, the key takeaway is that a well-tuned buffer depth (typically 10-15 frames) combined with 2-3 retransmissions yields a PER below 0.1% at a latency of 100-150 ms—perfect for public address, assistive listening, and multi-room audio. As LE Audio evolves, we can expect adaptive algorithms that dynamically adjust these parameters based on real-time channel conditions, pushing the boundaries of wireless audio reliability.
常见问题解答
问： How does a Bluetooth LE Audio receiver achieve microsecond-precision synchronization to a BIG anchor point in the presence of channel interference?
答： The receiver synchronizes by first decoding the BIGInfo advertising data on primary advertising channels (37, 38, 39), which includes the BIG_Offset specifying the time from the advertising event to the first BIG anchor point. Once locked, the receiver tracks the BIG anchor point using the BIG Channel Map and BIG Channel Index to follow the frequency-hopping sequence across 40 BLE channels. The receiver maintains a local timer that aligns with the ISO_Interval, and it uses the CRC and access address in received sub-events to validate timing. If a packet is missed due to interference, the receiver relies on the known sub-event timing and hopping sequence to stay synchronized, with the BIG_Sync_Timeout defining the maximum period it will attempt to re-sync before declaring failure.
问： What retransmission mechanisms are used in BIS/BIG to handle packet loss over unreliable channels, and how do they affect audio latency?
答： Bluetooth LE Audio BIS/BIG uses a retransmission scheme based on the concept of sub-event slots within a BIG event. Each BIS sub-event can be retransmitted in subsequent sub-events within the same BIG event or in later BIG events, depending on the configuration. The transmitter may schedule multiple retransmission opportunities (e.g., up to 3 retransmissions) per audio frame, using a sliding window approach. Retransmissions increase the probability of successful delivery but add latency proportional to the number of retransmission attempts and the ISO_Interval. For example, if a packet is lost and retransmitted in the next sub-event slot (BIS_Space apart), the added latency is typically a few microseconds to milliseconds. However, if retransmission spans multiple BIG events, latency can increase by multiples of the ISO_Interval (e.g., 10 ms per event). Buffer management at the receiver must account for this jitter by maintaining a playout buffer that delays audio playback to absorb retransmission variability.
问： How does buffer management in BIS/BIG receivers handle jitter caused by retransmissions and channel fading in LE Audio?
答： Receivers implement a playout buffer (often called a jitter buffer) that temporarily stores decoded audio frames before playback. The buffer depth is configured based on the expected worst-case jitter, which includes retransmission delays (e.g., up to 3 retransmissions across multiple sub-events) and channel fading-induced gaps. The buffer management algorithm uses timestamps from the ISOAL (Isochronous Adaptation Layer) to reorder frames and discard duplicates. It also employs a feedback mechanism to adjust the buffer size dynamically: if packet loss increases, the buffer may grow to accommodate more retransmissions, increasing latency; if the channel improves, the buffer shrinks to reduce latency. The SDU interval (e.g., 10 ms) and framing mode (unframed vs. framed) influence buffer sizing. Typically, the buffer is set to hold 2-5 audio frames to balance latency and robustness, with a target of under 50 ms for real-time applications.
问： What role does the BIG Channel Map play in frequency hopping for BIS, and how does it affect reliability in congested 2.4 GHz environments?
答： The BIG Channel Map defines the set of BLE channels (0-39, excluding advertising channels 37, 38, 39) that the transmitter uses for frequency hopping in a BIG. The map can be updated dynamically by the transmitter to exclude channels with high interference (e.g., Wi-Fi overlapping channels 1, 6, 11). This adaptive channel selection improves reliability by avoiding congested frequencies. The receiver must track the same channel map and hopping sequence (based on the BIG Channel Index) to lock onto sub-events. If a channel is excluded, the hopping sequence skips it, reducing the probability of packet loss. However, a smaller channel set increases the chance of repeated collisions if interference is widespread. The transmitter may also use channel classification from link-layer statistics to optimize the map, balancing between robustness and spectral efficiency.
问： How does the ISO_Interval parameter impact synchronization and retransmission performance in BIS/BIG for low-latency audio applications?
答： The ISO_Interval (range 5 ms to 4 s, typically 10-20 ms for audio) defines the period between BIG anchor points. A shorter ISO_Interval (e.g., 5 ms) allows more frequent retransmission opportunities within a given time window, reducing latency for retransmitted packets but increasing overhead and power consumption. A longer interval (e.g., 20 ms) reduces overhead but increases the time between retransmission attempts, potentially causing higher jitter. For synchronization, a shorter interval makes it easier for receivers to maintain lock because anchor points occur more frequently, reducing drift errors. However, it also requires tighter timing precision (microsecond-level) to avoid missing sub-events. In practice, low-latency applications (e.g., hearing aids) use ISO_Interval of 10 ms or less, with retransmission budgets of 1-2 attempts per frame, while broadcast applications (e.g., Auracast) may use 20 ms intervals with more retransmissions to balance reliability and power.
💬 欢迎到论坛参与讨论： 点击这里分享您的见解或提问
