Skip to content

Commit 580ca75

Browse files
silabs-juhasilabs-juha
authored
Changes from Balint for the review (#5)
1 parent f1443b5 commit 580ca75

1 file changed

Lines changed: 181 additions & 17 deletions

File tree

‎sld272-bluetooth-system-performance/link-layer-scheduler.md‎

Lines changed: 181 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -1,37 +1,201 @@
11
# Bluetooth Link Layer Scheduling
22

3-
It is possible to choose between three different scheduling algorithms depending from the different use cases.
3+
Link Layer scheduling defines how Bluetooth radio tasks share airtime on
4+
the controller.\
5+
This document describes the available scheduling algorithms, Link Layer
6+
task types,\
7+
anchor placement concepts, and configuration parameters. The goal is to
8+
help developers\
9+
choose the most appropriate scheduling mode for their application.
410

5-
## Basic Scheduling
11+
------------------------------------------------------------------------
612

7-
Basic scheduling is enabled by default, when the `Bluetooth Controller Anchor Selection` component is **not** installed.
13+
## Link Layer Tasks
814

9-
Basic scheduling without using the anchor selection algorithm does not try to improve throughput or latency. It ensures that all tasks can share the radio, and it resolves scheduling conflicts if there is an overlap. This is good for advertising / peripheral low throughput applications where latency is not an issue. It is also fit for PAwR synchronizers.
15+
A *task* is any Link Layer radio activity that must occur at scheduled
16+
intervals.\
17+
The Bluetooth controller treats the following as tasks:
18+
19+
- One or more **connection events**
20+
- **Advertising**
21+
- **Scanning**
22+
- **Channel Sounding**
23+
- **Periodic Advertising with Responses (PAwR)** transmissions and
24+
receptions
25+
- **Multiple PAwR trains**, each considered a separate task
26+
27+
Tasks have intervals, required runtime, and anchor points. The scheduler
28+
divides radio\
29+
time between tasks while attempting to avoid overlaps.
30+
31+
------------------------------------------------------------------------
32+
33+
## Anchor Concept
34+
35+
An *anchor point* is the reference time for a repeating Link Layer
36+
procedure\
37+
(such as a connection event).\
38+
This is a Bluetooth Core Specification term; refer to the Core Spec for
39+
the formal definition.
40+
41+
Why anchors matter:
42+
43+
- Anchor placement affects **throughput**, **latency**, and
44+
coexistence between tasks.
45+
- Efficient anchor distribution ensures radio time is used without
46+
unnecessary conflicts.
47+
- Misaligned anchors may reduce available airtime or increase
48+
collision likelihood.
49+
50+
------------------------------------------------------------------------
51+
52+
## Scheduling Algorithms
53+
54+
The Bluetooth Link Layer supports three selectable scheduling
55+
algorithms.\
56+
Developers may choose the most suitable one based on device role,
57+
resource needs,\
58+
and traffic requirements.
59+
60+
------------------------------------------------------------------------
61+
62+
### Basic Scheduling
63+
64+
Enabled when the *Bluetooth Controller Anchor Selection* component is
65+
**not installed**.
66+
67+
Basic scheduling does not attempt to optimize latency or throughput.\
68+
It ensures tasks share the radio and resolves conflicts only when
69+
overlaps occur.
70+
71+
Best for: - Advertising / **Peripheral low‑throughput** applications
72+
- Applications where **latency is not critical**
73+
- **PAwR synchronizers**
74+
- Designs requiring **lowest RAM, flash, and power usage**
75+
76+
------------------------------------------------------------------------
1077

1178
### Even Anchor Selection Algorithm
1279

13-
Enabled when the `Bluetooth Controller Anchor Selection` component is installed and `Anchor selection is done in an even manner` selected, this is the component default setting.
80+
Enabled when the *Bluetooth Controller Anchor Selection* component is
81+
installed and\
82+
**Anchor selection is done in an even manner** is selected.
1483

15-
Even anchor selection algorithm is best for single central multi peripheral use case where all connections have the same intervals. It tries to give connections the most airtime without interfering with other link layer tasks.
84+
Best for: - Local device acting as **Central** connected to **multiple
85+
Peripherals**
86+
- Central devices performing **Channel Sounding** where the Central is
87+
the initiator
88+
89+
Behavior: - Tries to **maximize airtime for connection events**
90+
- Distributes anchors evenly across the interval for balanced use across
91+
connections
92+
93+
Tradeoffs: - Uses **more RAM, flash, and power** than Basic Scheduling
94+
- Not recommended for **simple Peripheral-only devices**
95+
- Does **not fully utilize maximum possible radio time**
96+
97+
------------------------------------------------------------------------
1698

1799
### Empty Center Anchor Selection Algorithm
18100

19-
Enabled when the `Bluetooth Controller Anchor Selection` component is installed and `Anchors are placed in alternating manner` selected.
101+
Enabled when *Bluetooth Controller Anchor Selection* is installed and\
102+
**Anchors are placed in alternating manner** is selected.
103+
104+
Best for: - Devices acting as **Central + PAwR Advertiser**
105+
- Use cases where **PAwR subevents** and **connections** share the same
106+
interval
107+
108+
Behavior: - Places anchors to reserve "center" airtime for PAwR
109+
operations
110+
- Works best when all task runtimes fit comfortably inside a single
111+
interval
112+
113+
Multiple PAwR trains: - Each train is treated as a separate task
114+
- Developers must ensure **system‑level timing** prevents PAwR response
115+
slot overlap
116+
117+
------------------------------------------------------------------------
118+
119+
## Task Runtime Considerations
120+
121+
Scheduling quality depends on the relationship between task runtimes and
122+
their intervals:
123+
124+
- When total runtime is small compared to the interval, anchors can be
125+
spaced optimally
126+
- As total runtime approaches the interval:
127+
- Anchor placement becomes constrained
128+
- Throughput and latency may degrade
129+
- PAwR slot alignment becomes more difficult
130+
- Lower‑priority tasks may lose airtime
131+
132+
A full PAwR use‑case example is available internally.
133+
134+
------------------------------------------------------------------------
135+
136+
## Configuration Parameters
137+
138+
The *Bluetooth Low Energy Controller* component provides parameters
139+
affecting scheduling.
140+
141+
### Bluetooth Controller Minimum Connection Event Duration
142+
143+
Hints the scheduler to reserve a minimum runtime for each connection.
144+
145+
Example:\
146+
Transmitting + receiving 251‑byte packets on 1M PHY requires \~4.3 ms.
147+
148+
If the Host sets a larger minimum event length, the scheduler uses the
149+
larger value.
150+
151+
------------------------------------------------------------------------
152+
153+
### Bluetooth Controller Connection Event Extension
154+
155+
Allows connection events to extend beyond their scheduled window if they
156+
still\
157+
have data to exchange and have not exceeded the maximum connection event
158+
length.\
159+
This may temporarily overrun lower‑priority tasks.
160+
161+
------------------------------------------------------------------------
162+
163+
### Bluetooth Controller Scanner Reception Early Abort
164+
165+
Allows the scanner to abort packet reception if continuing would delay a
166+
higher‑priority task.\
167+
Useful for ensuring extended advertisements do not overrun upcoming
168+
scheduled tasks.
169+
170+
------------------------------------------------------------------------
20171

21-
Empty center anchor selection algorithm is best for PAwR advertiser use case. This algorithm is best when the PAwR subevent and connections have the same interval. The algorithm relies on the runtime of the tasks, and it works best if there is enough time for all the tasks to execute within one interval.
172+
## Choosing a Scheduling Algorithm
22173

23-
### Configuration Parameters
174+
Choose **Basic Scheduling** when: - Peripheral-only roles\
175+
- Low throughput and non‑critical latency
176+
- PAwR synchronizer use cases
177+
- Minimal RAM/flash/power usage required
24178

25-
- `Bluetooth Low Energy Controller` component has some configuration parameters related to Link Layer Scheduling under `Bluetooth Controller Configuration`.
179+
Choose **Even Anchor Selection** when: - Central device with multiple
180+
Peripherals
181+
- Central performing Channel Sounding
182+
- Balanced airtime allocation across connections is needed
26183

27-
- `Bluetooth Controller Minimum Connection Event Duration` is helpful to give some idea to the link layer’s scheduling algorithm to reserve the minimum runtime for each connection.
184+
Choose **Empty Center Anchor Selection** when: - Central + PAwR
185+
Advertiser roles
186+
- PAwR and connections share intervals\
187+
- Developer can ensure PAwR train timing does not overlap
28188

29-
For example if the system designer knows that they will be transmitting and receiving the 251 bytes for all connections and they are all using 1M PHY, then the minimum event length configuration should be ~4.3ms.
30-
31-
This configuration acts as the bare minimum for the connection event length. If the host set a different minimum connection event length when creating the connection, then the link layer will use the bigger of `Bluetooth Controller Minimum Connection Event Duration` and minimum connection event length.
189+
------------------------------------------------------------------------
32190

33-
- `Bluetooth Controller Connection Event Extension` allows connections to overrun lower priority tasks as long as there is data to transmit or receive on the connection, and the maximum connection event length is not reached.
191+
## Summary
34192

35-
- `Bluetooth Controller Scanner Reception Early Abort` feature allows the controller to control the scanner to abort the reception of a packet if it will conflict with another scheduled higher priority task.
193+
Link Layer scheduling determines how radio airtime is shared between
194+
tasks.\
195+
Choosing the correct scheduler depends on device role, task mix,
196+
throughput and\
197+
latency requirements, and resource constraints.
36198

37-
This configuration is useful to ensure that reception of extended advertisements over secondary advertising channels won’t overrun the next scheduled task.
199+
The anchor selection algorithms allow improved radio‑time distribution
200+
when needed,\
201+
while Basic Scheduling provides the lowest resource footprint.

0 commit comments

Comments
 (0)