Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
189 changes: 71 additions & 118 deletions sld272-bluetooth-system-performance/link-layer-scheduler.md
Original file line number Diff line number Diff line change
@@ -1,201 +1,154 @@
# Bluetooth Link Layer Scheduling

Link Layer scheduling defines how Bluetooth radio tasks share airtime on
the controller.\
This document describes the available scheduling algorithms, Link Layer
task types,\
anchor placement concepts, and configuration parameters. The goal is to
help developers\
choose the most appropriate scheduling mode for their application.

------------------------------------------------------------------------
Link Layer scheduling defines how Bluetooth radio tasks share airtime on the controller. This document describes the available scheduling algorithms, Link Layer task types, anchor placement concepts, and configuration parameters. The goal is to help developers choose the most appropriate scheduling mode for their application.

## Link Layer Tasks

A *task* is any Link Layer radio activity that must occur at scheduled
intervals.\
The Bluetooth controller treats the following as tasks:

- One or more **connection events**
- **Advertising**
- **Scanning**
- **Channel Sounding**
- **Periodic Advertising with Responses (PAwR)** transmissions and
receptions
- **Multiple PAwR trains**, each considered a separate task
A *task* is any Link Layer radio activity that must occur at scheduled intervals. The Bluetooth controller treats the following as tasks:

Tasks have intervals, required runtime, and anchor points. The scheduler
divides radio\
time between tasks while attempting to avoid overlaps.
- One or more connection events
- Advertising
- Scanning
- Channel Sounding
- Periodic Advertising with Responses (PAwR) transmissions and receptions
- Multiple PAwR trains, each considered a separate task

------------------------------------------------------------------------
Tasks have intervals, required runtime, and anchor points. The scheduler divides radio time between tasks while attempting to avoid overlaps.

## Anchor Concept

An *anchor point* is the reference time for a repeating Link Layer
procedure\
(such as a connection event).\
This is a Bluetooth Core Specification term; refer to the Core Spec for
the formal definition.
An *anchor point* is the reference time for a repeating Link Layer procedure (such as a connection event).

Why anchors matter:
This is a Bluetooth Core Specification term; refer to the Core Spec for the formal definition.

- Anchor placement affects **throughput**, **latency**, and
coexistence between tasks.
- Efficient anchor distribution ensures radio time is used without
unnecessary conflicts.
- Misaligned anchors may reduce available airtime or increase
collision likelihood.
Why anchors matter:

------------------------------------------------------------------------
- Anchor placement affects throughput, latency, and coexistence between tasks.
- Efficient anchor distribution ensures radio time is used without unnecessary conflicts.
- Misaligned anchors may reduce available airtime or increase the likelihood of a collision.

## Scheduling Algorithms

The Bluetooth Link Layer supports three selectable scheduling
algorithms.\
Developers may choose the most suitable one based on device role,
resource needs,\
and traffic requirements.

------------------------------------------------------------------------
The Bluetooth Link Layer supports three selectable scheduling algorithms. Developers may choose the most suitable one based on device role,
resource needs, and traffic requirements.

### Basic Scheduling

Enabled when the *Bluetooth Controller Anchor Selection* component is
**not installed**.
Enabled when the *Bluetooth Controller Anchor Selection* component is **not installed**.

Basic scheduling does not attempt to optimize latency or throughput.\
It ensures tasks share the radio and resolves conflicts only when
overlaps occur.
Basic scheduling does not attempt to optimize latency or throughput. It ensures tasks share the radio and resolves conflicts only when overlaps occur.

Best for: - Advertising / **Peripheral low‑throughput** applications
- Applications where **latency is not critical**
- **PAwR synchronizers**
- Designs requiring **lowest RAM, flash, and power usage**
Best for:

------------------------------------------------------------------------
- Advertising / Peripheral low‑throughput applications
- Applications where latency is not critical
- PAwR synchronizers
- Designs requiring lowest RAM, flash, and power usage

### Even Anchor Selection Algorithm

Enabled when the *Bluetooth Controller Anchor Selection* component is
installed and\
**Anchor selection is done in an even manner** is selected.
Enabled when the *Bluetooth Controller Anchor Selection* component is installed and **Anchor selection is done in an even manner** is selected.

Best for:

Best for: - Local device acting as **Central** connected to **multiple
Peripherals**
- Local device acting as **Central** connected to multiple peripherals
- Central devices performing **Channel Sounding** where the Central is
the initiator

Behavior: - Tries to **maximize airtime for connection events**
- Distributes anchors evenly across the interval for balanced use across
connections
Behavior:

Tradeoffs: - Uses **more RAM, flash, and power** than Basic Scheduling
- Not recommended for **simple Peripheral-only devices**
- Does **not fully utilize maximum possible radio time**
- Tries to maximize airtime for connection events
- Distributes anchors evenly across the interval for balanced use across connections

------------------------------------------------------------------------
Tradeoffs:

- Uses more RAM, flash, and power than Basic Scheduling
- Not recommended for simple Peripheral-only devices
- Does not fully utilize maximum possible radio time

### Empty Center Anchor Selection Algorithm

Enabled when *Bluetooth Controller Anchor Selection* is installed and\
**Anchors are placed in alternating manner** is selected.
Enabled when *Bluetooth Controller Anchor Selection* is installed and **Anchors are placed in alternating manner** is selected.

Best for:

Best for: - Devices acting as **Central + PAwR Advertiser**
- Use cases where **PAwR subevents** and **connections** share the same
- Devices acting as **Central + PAwR Advertiser**
- Use cases where PAwR subevents and connections share the same
interval

Behavior: - Places anchors to reserve "center" airtime for PAwR
operations
Behavior:

- Places anchors to reserve "center" airtime for PAwR operations
- Works best when all task runtimes fit comfortably inside a single
interval

Multiple PAwR trains: - Each train is treated as a separate task
- Developers must ensure **system‑level timing** prevents PAwR response
slot overlap
Multiple PAwR trains:

------------------------------------------------------------------------
- Each train is treated as a separate task
- Developers must ensure **system‑level timing** prevents PAwR response slot overlap

## Task Runtime Considerations

Scheduling quality depends on the relationship between task runtimes and
their intervals:

- When total runtime is small compared to the interval, anchors can be
spaced optimally
- As total runtime approaches the interval:
- Anchor placement becomes constrained
- Throughput and latency may degrade
- PAwR slot alignment becomes more difficult
- Lower‑priority tasks may lose airtime
- When total runtime is small compared to the interval, anchors can be spaced optimally
- As total runtime approaches the interval:
- Anchor placement becomes constrained
- Throughput and latency may degrade
- PAwR slot alignment becomes more difficult
- Lower‑priority tasks may lose airtime

A full PAwR use‑case example is available internally.

------------------------------------------------------------------------

## Configuration Parameters

The *Bluetooth Low Energy Controller* component provides parameters
affecting scheduling.
The *Bluetooth Low Energy Controller* component provides parameters affecting scheduling.

### Bluetooth Controller Minimum Connection Event Duration

Hints the scheduler to reserve a minimum runtime for each connection.

Example:\
Transmitting + receiving 251‑byte packets on 1M PHY requires \~4.3 ms.
Example:

If the Host sets a larger minimum event length, the scheduler uses the
larger value.
Transmitting + receiving 251‑byte packets on 1M PHY requires ~4.3 ms.

------------------------------------------------------------------------
If the Host sets a larger minimum event length, the scheduler uses the larger value.

### Bluetooth Controller Connection Event Extension

Allows connection events to extend beyond their scheduled window if they
still\
have data to exchange and have not exceeded the maximum connection event
length.\
This may temporarily overrun lower‑priority tasks.

------------------------------------------------------------------------
Allows connection events to extend beyond their scheduled window if they still have data to exchange and have not exceeded the maximum connection event length. This may temporarily overrun lower‑priority tasks.

### Bluetooth Controller Scanner Reception Early Abort

Allows the scanner to abort packet reception if continuing would delay a
higher‑priority task.\
Useful for ensuring extended advertisements do not overrun upcoming
higher‑priority task.. Useful for ensuring extended advertisements do not overrun upcoming
scheduled tasks.

------------------------------------------------------------------------

## Choosing a Scheduling Algorithm

Choose **Basic Scheduling** when: - Peripheral-only roles\
Choose **Basic Scheduling** when:

- Peripheral-only roles
- Low throughput and non‑critical latency
- PAwR synchronizer use cases
- Minimal RAM/flash/power usage required

Choose **Even Anchor Selection** when: - Central device with multiple
Choose **Even Anchor Selection** when:

- Central device with multiple
Peripherals
- Central performing Channel Sounding
- Balanced airtime allocation across connections is needed

Choose **Empty Center Anchor Selection** when: - Central + PAwR
Advertiser roles
- PAwR and connections share intervals\
- Developer can ensure PAwR train timing does not overlap
Choose **Empty Center Anchor Selection** when:

------------------------------------------------------------------------
- Central + PAwR Advertiser roles
- PAwR and connections share intervals
- Developer can ensure PAwR train timing does not overlap

## Summary

Link Layer scheduling determines how radio airtime is shared between
tasks.\
Choosing the correct scheduler depends on device role, task mix,
throughput and\
latency requirements, and resource constraints.
Link Layer scheduling determines how radio airtime is shared between tasks. Choosing the correct scheduler depends on device role, task mix, throughput and latency requirements, and resource constraints.

The anchor selection algorithms allow improved radio‑time distribution
when needed,\
while Basic Scheduling provides the lowest resource footprint.
The anchor selection algorithms allow improved radio‑time distribution when needed, while Basic Scheduling provides the lowest resource footprint.
Loading