From 80c5d441e7814016f6799ceffdb4818b4a51d0b4 Mon Sep 17 00:00:00 2001 From: Vickey Morrow Date: Tue, 28 Apr 2026 10:53:27 -0500 Subject: [PATCH 1/5] reformatted file --- .../link-layer-scheduler.md | 175 +++++++----------- 1 file changed, 70 insertions(+), 105 deletions(-) diff --git a/sld272-bluetooth-system-performance/link-layer-scheduler.md b/sld272-bluetooth-system-performance/link-layer-scheduler.md index 60b39d6..2835632 100644 --- a/sld272-bluetooth-system-performance/link-layer-scheduler.md +++ b/sld272-bluetooth-system-performance/link-layer-scheduler.md @@ -1,118 +1,91 @@ # 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). + +This is a Bluetooth Core Specification term; refer to the Core Spec for the formal definition. 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 - collision likelihood. - ------------------------------------------------------------------------- +- 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 +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** +- 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 ------------------------------------------------------------------------ @@ -121,13 +94,12 @@ slot overlap 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. @@ -135,67 +107,60 @@ 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: + +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. +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\ +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. From 96b81081c65489f1e0a6e8e7b1317cfc87728304 Mon Sep 17 00:00:00 2001 From: Vickey Morrow Date: Tue, 28 Apr 2026 17:50:20 -0500 Subject: [PATCH 2/5] formatting fixes --- .../link-layer-scheduler.md | 36 +++++++------------ 1 file changed, 12 insertions(+), 24 deletions(-) diff --git a/sld272-bluetooth-system-performance/link-layer-scheduler.md b/sld272-bluetooth-system-performance/link-layer-scheduler.md index 2835632..5c6a80d 100644 --- a/sld272-bluetooth-system-performance/link-layer-scheduler.md +++ b/sld272-bluetooth-system-performance/link-layer-scheduler.md @@ -6,12 +6,12 @@ Link Layer scheduling defines how Bluetooth radio tasks share airtime on the con 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 +- 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. @@ -40,10 +40,10 @@ Basic scheduling does not attempt to optimize latency or throughput. It ensures Best for: -- Advertising / **Peripheral low‑throughput** applications -- Applications where **latency is not critical** -- **PAwR synchronizers** -- Designs requiring **lowest RAM, flash, and power usage** +- 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 @@ -57,7 +57,7 @@ the initiator Behavior: -- Tries to **maximize airtime for connection events** +- Tries to maximize airtime for connection events - Distributes anchors evenly across the interval for balanced use across connections Tradeoffs: @@ -73,7 +73,7 @@ Enabled when *Bluetooth Controller Anchor Selection* is installed and **Anchors Best for: - Devices acting as **Central + PAwR Advertiser** -- Use cases where **PAwR subevents** and **connections** share the same +- Use cases where PAwR subevents and connections share the same interval Behavior: @@ -87,8 +87,6 @@ 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 @@ -103,8 +101,6 @@ their intervals: A full PAwR use‑case example is available internally. ------------------------------------------------------------------------- - ## Configuration Parameters The *Bluetooth Low Energy Controller* component provides parameters affecting scheduling. @@ -119,22 +115,16 @@ 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. ------------------------------------------------------------------------- - ### 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 scheduled tasks. ------------------------------------------------------------------------- - ## Choosing a Scheduling Algorithm Choose **Basic Scheduling** when: @@ -157,8 +147,6 @@ Choose **Empty Center Anchor Selection** when: - 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. From 12d34d90483ce428bf4e66f750aaa167d69aa490 Mon Sep 17 00:00:00 2001 From: Vickey Morrow Date: Tue, 28 Apr 2026 18:26:04 -0500 Subject: [PATCH 3/5] added tech pub content edits --- .../link-layer-scheduler.md | 103 ++++++++---------- 1 file changed, 46 insertions(+), 57 deletions(-) diff --git a/sld272-bluetooth-system-performance/link-layer-scheduler.md b/sld272-bluetooth-system-performance/link-layer-scheduler.md index 5c6a80d..a2bb854 100644 --- a/sld272-bluetooth-system-performance/link-layer-scheduler.md +++ b/sld272-bluetooth-system-performance/link-layer-scheduler.md @@ -10,55 +10,51 @@ A *task* is any Link Layer radio activity that must occur at scheduled intervals - Advertising - Scanning - Channel Sounding -- Periodic Advertising with Responses (PAwR) transmissions and receptions -- Multiple PAwR trains, each considered a separate task +- Periodic Advertising with Responses (PAwR) transmissions and receptions +- Multiple PAwR trains, where each train counts as a separate task -Tasks have intervals, required runtime, and anchor points. The scheduler divides radio time between tasks while attempting to avoid overlaps. +Each task has an interval, a required runtime, and an anchor point. 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). +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. For the formal definition, see the Core Spec. -This is a Bluetooth Core Specification term; refer to the Core Spec for the formal definition. +Anchor placement matters for the following reasons: -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. +- It affects throughput, latency, and coexistence between tasks. +- Efficient anchor distribution uses radio time without unnecessary conflicts. +- Misaligned anchors can 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. Choose the one that best matches your device role, resource budget, and traffic requirements. ### Basic Scheduling -Enabled when the *Bluetooth Controller Anchor Selection* component is **not installed**. +Basic Scheduling is 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. -Best for: +Use Basic Scheduling for: -- Advertising / Peripheral low‑throughput applications +- Advertising or Peripheral low-throughput applications - Applications where latency is not critical - PAwR synchronizers -- Designs requiring lowest RAM, flash, and power usage +- Designs that require the 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. +This algorithm is enabled when the **Bluetooth Controller Anchor Selection** component is installed and **Anchor selection is done in an even manner** is selected. -Best for: +Use Even Anchor Selection for: -- Local device acting as **Central** connected to multiple peripherals -- Central devices performing **Channel Sounding** where the Central is -the initiator +- A local device acting as **Central** that is connected to multiple peripherals +- Central devices that perform **Channel Sounding** as the initiator Behavior: - Tries to maximize airtime for connection events -- Distributes anchors evenly across the interval for balanced use across connections +- Distributes anchors evenly across the interval to balance use across connections Tradeoffs: @@ -68,87 +64,80 @@ Tradeoffs: ### Empty Center Anchor Selection Algorithm -Enabled when *Bluetooth Controller Anchor Selection* is installed and **Anchors are placed in alternating manner** is selected. +This algorithm is enabled when the **Bluetooth Controller Anchor Selection** component is installed and **Anchors are placed in alternating manner** is selected. -Best for: +Use Empty Center Anchor Selection for: - Devices acting as **Central + PAwR Advertiser** -- Use cases where PAwR subevents and connections share the same -interval +- Use cases where PAwR subevents and connections share the same interval Behavior: -- Places anchors to reserve "center" airtime for PAwR operations -- Works best when all task runtimes fit comfortably inside a single -interval +- 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 +- 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 +- When total runtime is small compared to the interval, the scheduler can space anchors 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 + - Anchor placement becomes constrained. + - Throughput and latency can degrade. + - PAwR slot alignment becomes more difficult. + - Lower-priority tasks can 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 that affect scheduling. ### Bluetooth Controller Minimum Connection Event Duration -Hints the scheduler to reserve a minimum runtime for each connection. - -Example: +Hints to the scheduler to reserve a minimum runtime for each connection. -Transmitting + receiving 251‑byte packets on 1M PHY requires ~4.3 ms. +Example: Transmitting and receiving 251-byte packets on the 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 can 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 -scheduled tasks. +Allows the scanner to abort packet reception if continuing would delay a higher-priority task. Use this setting to prevent extended advertisements from overrunning upcoming scheduled tasks. ## Choosing a Scheduling Algorithm Choose **Basic Scheduling** when: -- Peripheral-only roles -- Low throughput and non‑critical latency -- PAwR synchronizer use cases -- Minimal RAM/flash/power usage required +- The device has Peripheral-only roles. +- Throughput is low and latency is not critical. +- The device acts as a PAwR synchronizer. +- You need minimal RAM, flash, and power usage. Choose **Even Anchor Selection** when: -- Central device with multiple -Peripherals -- Central performing Channel Sounding -- Balanced airtime allocation across connections is needed +- The device is a Central with multiple Peripherals. +- The Central performs Channel Sounding. +- You need balanced airtime allocation across connections. Choose **Empty Center Anchor Selection** when: -- Central + PAwR Advertiser roles -- PAwR and connections share intervals -- Developer can ensure PAwR train timing does not overlap +- The device acts as Central + PAwR Advertiser. +- PAwR and connections share intervals. +- You can ensure that 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. The right 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. From 193a5e63cbda09dbae03ce1d451bf41cada5c809 Mon Sep 17 00:00:00 2001 From: Vickey Morrow Date: Tue, 28 Apr 2026 18:41:43 -0500 Subject: [PATCH 4/5] corrected duplicated text --- .../link-layer-scheduler.md | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/sld272-bluetooth-system-performance/link-layer-scheduler.md b/sld272-bluetooth-system-performance/link-layer-scheduler.md index 838866a..9f29513 100644 --- a/sld272-bluetooth-system-performance/link-layer-scheduler.md +++ b/sld272-bluetooth-system-performance/link-layer-scheduler.md @@ -1,11 +1,9 @@ # 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: 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 @@ -35,7 +33,6 @@ The Bluetooth Link Layer supports three selectable scheduling algorithms. Choose Basic Scheduling is 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. Use Basic Scheduling for: @@ -86,8 +83,7 @@ Multiple PAwR trains: ## Task Runtime Considerations -Scheduling quality depends on the relationship between task runtimes and -their intervals: +Scheduling quality depends on the relationship between task runtimes and their intervals: - When total runtime is small compared to the interval, the scheduler can space anchors optimally. - As total runtime approaches the interval: @@ -144,4 +140,4 @@ Choose **Empty Center Anchor Selection** when: Link Layer scheduling determines how radio airtime is shared between tasks. The right 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. + From 4fbb44d4c4d8f0b01b6e356713111264c3ef94e2 Mon Sep 17 00:00:00 2001 From: Vickey Morrow Date: Tue, 28 Apr 2026 19:14:42 -0500 Subject: [PATCH 5/5] additional minor edits --- .../link-layer-scheduler.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sld272-bluetooth-system-performance/link-layer-scheduler.md b/sld272-bluetooth-system-performance/link-layer-scheduler.md index 9f29513..b56dea8 100644 --- a/sld272-bluetooth-system-performance/link-layer-scheduler.md +++ b/sld272-bluetooth-system-performance/link-layer-scheduler.md @@ -11,7 +11,7 @@ A *task* is any Link Layer radio activity that must occur at scheduled intervals - Scanning - Channel Sounding - Periodic Advertising with Responses (PAwR) transmissions and receptions -- Multiple PAwR trains, where each train counts as a separate task +- Multiple PAwR trains, where each train is considered a separate task Each task has an interval, a required runtime, and an anchor point. The scheduler divides radio time between tasks while attempting to avoid overlaps. @@ -22,7 +22,7 @@ An *anchor point* is the reference time for a repeating Link Layer procedure, su Anchor placement matters for the following reasons: - It affects throughput, latency, and coexistence between tasks. -- Efficient anchor distribution uses radio time without unnecessary conflicts. +- Efficient anchor distribution ensures radio time is used without unnecessary conflicts. - Misaligned anchors can reduce available airtime or increase the likelihood of a collision. ## Scheduling Algorithms @@ -102,7 +102,7 @@ The **Bluetooth Low Energy Controller** component provides parameters that affec Hints to the scheduler to reserve a minimum runtime for each connection. -Example: Transmitting and receiving 251-byte packets on the 1M PHY requires ~4.3 ms. +Example: Transmitting and receiving 251-byte packets on a 1M PHY requires ~4.3 ms. If the Host sets a larger minimum event length, the scheduler uses the larger value. @@ -137,7 +137,7 @@ Choose **Empty Center Anchor Selection** when: ## Summary -Link Layer scheduling determines how radio airtime is shared between tasks. The right 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 most appropriate scheduler depends on your 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.