Time-Aware Scheduling Capabilities in IEEE 802.11be

Capabilities to support Time-Aware Scheduling in
802.11be
Date:
 2018-12-19
November 2019
Dave Cavalcanti, Intel
Slide 1
Authors:
Abstract
This presentation describes gaps and new capabilities required to enable
Time-Aware scheduling over the 802.11be for time-sensitive and real-time
applications.
The presentation focuses on Time-Aware scheduling as defined by the
802.1Qbv standard, but the concepts and solutions described may also be
applicable more generally.
Slide 2
Dave Cavalcanti, Intel
November 2019
Outline
TSN and Time-Aware scheduling
Issues and new requirements in mapping Time-Aware scheduling over
802.11
Part 1: Time-Aware (802.1Qbv) scheduling configuration over 802.11
Part 2: Time-Aware schedule execution enhancements (latency, jitter, reliability)
Conclusions
Slide 3
Dave Cavalcanti, Intel
November 2019
IEEE 802.1 Time-Sensitive Networking (TSN)
November 2019
Dave Cavalcanti, Intel
Slide 4
TSN Components
Common Standards
Latency
Reliability
Standard Ethernet with Synchronization, small and/or fixed latency, and extremely low packet loss 
Reliability
Ultra reliability:
Frame Replication and Elimination (P802.1CB)
Path Control and Reservation (802.1Qca)
Per-Stream Filtering and Policing (802.1Qci)
Reliability for time sync (P802.1AS-Rev)
Synchronization
Time synchronization:
Time Synchronization (802.1AS)
Resource Mgmt
Dedicated resources &
API
Stream Reservation Protocol (802.1Qat)
TSN configuration (P802.1Qcc)
YANG (P802.1Qcp)
Link-local Registration Protocol (P802.1CS)
Bounded low latency:
Time-Aware traffic shaping (802.1Qbv)
Preemption (802.1Qbu/802.3br)
Cyclic Scheduling (802.1Qch)
Asynchronous Scheduling (802.1Qcr)
Credit: János Farkas, Ericsson
TSNA Conference 2017, http://www.tsnaconference.com/
802.1AS over 802.11
Timing Measurement (TM)
Fine Timing Measurements (FTM)
802.11aa (SRP over 802.11 for AV)
802.11ak (802.11 links in an 802.1Q network)
Time-Aware scheduling (802.1Qbv) over 802.11 (extension to address bounded  latency
for scheduled traffic)
Time-Aware (Qbv) Scheduling – Operation model  &
Assumptions
November 2019
Dave Cavalcanti, Intel
Slide 5
CUC: Central User Configuration
CNC: Central Network Configuration
802.1Qcc Centralized Model
Assumptions:
Time-critical traffic streams (max packet size and inter-arrival time) are known a
priori (at configuration stage)
The IEEE 802.1Qcc std defines management models (the centralized model is
assumed here, other models are also possible)
All TSN devices are synchronized to the same reference clock (through 802.1AS)
The CUC collects the traffic stream requirements from end devices
(Talkers/Listeners) and the CNC discovers the network topology
The CNC computes the 
transmission schedule and the end to end path
 for each
traffic stream and communicate the schedule to the CUC
The CNC configures the schedule at TSN Bridges and the CUC configures the
schedule in the end devices (e.g. via control plane using YANG/NETCONF)
Wireless TSN Domain Considerations
802.11 Access Points can be seen as Wireless TSN Bridges
STAs can be configured as talkers or listeners
The CUC/CNC need to coordinate with the WTSN domain (scheduling over
wireless is within the 802.11 scope, but it needs to align with the overall CNC
schedule)
Control plane (logical connection) between CUC and End Devices
Control plane (logical connection) between CNC and TSN bridges
Parameters and Example Schedule
November 2019
Dave Cavalcanti, Intel
Slide 6
Guard-band
 protects time-critical traffic (the “guard band” behavior is
inherent in the defined behavior of the gates, i.e., no explicit guard band is
defined in the Qbv specification)
Cycle:
 list of gate operations (SetGateStates), where each operation has a time
delay (Gate Open Duration). The sequence of gate operations terminates at the
end of the list and re-starts OperCycleTime after the start of the sequence.
8021.Q Traffic Classes
(defined by PCP field in a
VLAN Tag) to Queues
Mapping on a TSN Bridge
TC#7
TC#6
TC#5
TC#4
TC#3
TC#2
TC#1
TC#0
T0
SetGateStates:
State: C C C C C C C C
TC   : 7  6  5 4  3  2  1 0
T1
T2
SetGateStates:
State: 0 C C C C C C C
TC   : 7  6  5 4  3  2  1 0
SetGateStates:
State: C O O O O O O O
TC   : 7  6  5  4  3  2  1 0
Cycle
Gate Open Duration
for Time-critical
Traffic (TC#7)
Guard band
Time critical traffic can be protected by a 
guard band
Gate Open Duration for
other (non-protected)
traffic classes (TC#0-6)
Time-critical
Traffic
The Time-Aware scheduling behavior must be enforced at the MAC (e.g. 802.3 or 802.11)
The Time-Aware scheduling behavior have to coexist/align with the 802.11 access
mechanisms (e.g. EDCA and trigger-based access)
Features required to support Time-Aware Scheduling
Time synchronization
Support for 802.1AS time synchronization is already enabled by 802.11 TM and FTM
Classification and mapping packets of a traffic stream to a traffic class (aligned with 802.1Q
traffic classification)
802.1Q and TCLAS traffic mapping capabilities defined in the 802.11 spec
Enable a STA to receive a time-aware schedule request from the higher layer at the 802.11 MAC
The schedule is used by the 802.11 MAC to control medium access and serve the traffic streams
The 802.11 MAC may accept or reject the request (the decision is implementation specific)
Enable execution of a time-aware schedule, i.e., deliver packets with certain deadlines (bounded
latency) at requested time intervals
The 802.11 MAC needs to provide predictable access to certain packets (preferably with high reliability)
and enable non-AP STAs to request such service based on a higher layer trigger
The time-aware schedule needs to take into account dynamic link states in 802.11 (negotiation with the
higher layer may be required – topic for collaboration between 802.1 and 802.11)
Slide 7
Dave Cavalcanti, Intel
November 2019
Part 1: Time-Aware Schedule Configuration over 802.11
 
November 2019
Dave Cavalcanti, Intel
Slide 8
Time-Aware Schedule Configuration Extensions
November 2019
Dave Cavalcanti, Intel
Slide 9
CUC: Central User Configuration
CNC: Central Network Configuration
802.1Qcc Centralized Model
Qbv Schedule Computation:
 Traffic requirements are known (max pkt size, inter-arrival time)
 The CNC uses the link speed to create the schedule
 For Ethernet
: The CNC assumes a fixed link speed (e.g. 1
Gbps) to compute the 
gate open duration
 for a given max
packet size;
 For 
wireless/802.11
: the CNC needs an estimate of time-
aware scheduling support provided by the 802.11 MAC
(
worst-case latency for a given max packet size at
predictable time intervals
)
 Information about 802.11 capabilities could be added as part of
Qbv configuration (802.1Qbv parameters wireless links) → 
topic
for collaboration between 802.1TSN and 802.11
 The CNC can define a schedule and request the 802.11 devices (AP
and STAs) to execute it, 802.11 devices need to indicate whether
they can meet the requested schedule
Need a management interface at the 802.11 MAC and
primitives to accept/negotiate a Time-Aware Scheduling
request from the higher (Qbv) layer
Time-Aware Schedule Configuration over 802.11
November 2019
Dave Cavalcanti, Intel
Slide 10
Outside 802.11
scope
802.1Q TSN
mngmt entity
802.11
MLME SAP
Qbv Schedule Config
(e.g. from CNC)
TASched.Request
TASched.Response
Qbv Schedule Config
Response (e.g. to CNC)
The AP 
decides
whether it can serve
the traffic streams
according to the
requested schedule.
Non-AP STAs 
need
to request the AP to
be served according
to the TA Schedule
before responding.
STA initiated Time-Aware Scheduling Request (e.g. STA
Talker scenario)
November 2019
Dave Cavalcanti, Intel
Slide 11
Non-AP STA
 MLME SAP
TASched.Request
TASched.Response
The AP decides
whether it can serve
the traffic streams
according to the
requested schedule.
AP
MLME SAP
TAS.Request (TAS)
TAS.Response ( )
STA responds to the higher layer based on the
result of the negotiation with the AP
Summary of Gaps and Potential Solutions
How to inform the 802.11 MAC of a Time-Aware (Qbv) Schedule request from the SME?
 A new MLME MLME-TA-SCHEDULE.Request (TAS).
How to inform the AP of a STA’s requested schedule?
The STA can use the 
schedule information to generate a request to be served according to a
certain service period (for a max packet size and inter-arrival time)
The STA can use a new procedure or updated procedures (e.g. ADDTS Request/Response, TWT
setup, …)
If the AP agrees to schedule the STA as requested, the STA can confirm the upper layer request,
otherwise, the STA declines the upper layer time-aware scheduling request
The AP is responsible for scheduling DL and UL resources (if trigger-based mode is used), STAs
can apply the schedule on top of their own queues (if non-trigger-based mode is used)
How to ensure packet prioritization and latency bounds are met by the 802.11 MAC?
Introduce the concept of a Time-Awareness within the 802.11 MAC to differentiate and prioritize
channel access based on an agreed Time-Aware schedule
Slide 12
Dave Cavalcanti, Intel
November 2019
Time-aware scheduling support via enhanced AddTS
Request/Response
November 2019
Dave Cavalcanti, Intel
Slide 13
Non-AP STA
 SME
Non-AP STA
 MAC
AP STA
 MAC
AP STA
 SME
MLME-AddTS.Request
(TSPEC,
TCLAS:VID,
TAS
)
AddTS Request
MLME-AddTS.Indication
MLME-AddTS.Response
AddTS Response
MLME-AddTS.Confirm
(TSPEC: TSID
TCLAS: UP)
TAS Cycle
: Guard band
: Gate Open (Time-critical)
: Gate Open (Other traffic)
SP for Time-critical traffic
Indicates that the AP
agrees to serve the STA
according to the requested
schedule.
Additional considerations
Other 802.11 mechanisms could also be used in combination with the time-
aware scheduling support, e.g.
If the STA has time-critical and other types of traffic, the TWT SP could help align the
periods to save power
Note: Traffic prioritization within a TWT SP is still according to the Qbv schedule.
Slide 14
Dave Cavalcanti, Intel
November 2019
TWT SP for time-critical + other traffic
: Guard band
: Gate Open (Time-critical)
: Gate Open (Other traffic)
TWT SP for Time-critical traffic
Part 2: 
Time-Aware Schedule Execution Enhancements
(latency, jitter, reliability) over 802.11
 
November 2019
Dave Cavalcanti, Intel
Slide 15
Issues if the 802.11 MAC is not aware of time-critical
packets and their required transmission schedule
Assuming the high priority AC is selected for the scheduled
time-critical traffic
On average, high priority AC should get faster access, but a
time-critical frame may still wait in some situations, e.g.:
other ACs get access first (as backoffs run independently)
other non-time critical (e.g. voice) frames mapped to the same AC
is ahead in the queue
ongoing (long) TXOP before the scheduled time
Main gaps:
1.
Lack of protection for time-critical traffic, i.e., prevent other traffic from
accessing the medium at certain times
2.
Provide access at scheduled time for time-critical frames with minimal
access delay and jitter
Slide 16
Dave Cavalcanti, Intel
November 2019
Time-sensitive frame
TXOP (AC_VI)
Time-sensitive frame
Making the 802.11 MAC time-aware
Slide 17
November 2019
A Time-Aware schedule is defined by upper layer and passed to
the 802.11 MAC via the SME-MLME-SAP interface
Time-critical traffic identified by a given traffic class is mapped
to a TID associated with a TSN Queue, other traffic is mapped
to other EDCA queues
If multiple flows are time critical, they can share one
queue or multiple TSN queues can be created;
802.11be may define a mapping of TCs to 802.11
TID/TSN Queue when time-aware scheduling is
used
A Time-Aware Shaper (TAS) Function receives the TA Schedule
from the Higher Layer
The TAS Function pauses/resumes EDCAFs to avoid contention
and protect the time-critical traffic according to the TAS (e.g.
when the TSN queue is open, other queues are paused)
A frame selection function (implementation dependent) selects
frame(s) for transmission based on their priorities
Higher (Qbv) Layer (TAS
= GateControlList)
Dave Cavalcanti, Intel
TSN Channel Access
Slide 18
Dave Cavalcanti, Intel
November 2019
The TSN Queue follows access rules to minimize latency and jitter, different modes may be enabled:
Trigger-based
: AP controls access in the DL and UL, STA and AP negotiate on expected service
periods that are aligned with the Qbv schedule
EDCA-based
: regular EDCA access behavior (e.g. access parameters TBD)
TC#7 -> TSN
TC#6 -> VO
TC#5 -> VI
TC#4
TC#3
TC#2
TC#1
TC#0
T0
T1
T2
BE
BK
T3
T4
guard
band
Time-
critical
Example TC to
802.11 Queue
mapping and
Schedule
TSN Access: Trigger based or EDCA
Regular operation, channel access policing is applied by the Time-Aware Shaper Function
Impact of unmanaged BSSs
Time-Aware scheduling operates on managed STAs
Interfering transmissions may impact the capability to guarantee bounded latency
Unmanaged STAs/OBSSs are seen as interference
The AP can take into account the level of interference when
accepting/admitting TA schedules and defining SP durations
Latency bound vs. capacity tradeoffs will depend on the level of interference and
deployment scenario
Slide 19
Dave Cavalcanti, Intel
November 2019
Summary of the new requirements to support Time-
Aware Scheduling over 802.11be
Interface to receive a time-aware schedule request from the higher layer
Mechanism for STAs to request the AP to be served according to a time-aware schedule
Time-awareness for policing channel access according to an agreed time-aware schedule
Low latency access for time-critical frames (once the gate is open) and differentiation from other
traffic classes
trigger based access can help provide predictable access and control worst-case latency
Slide 20
Dave Cavalcanti, Intel
November 2019
Conclusions
Time-Aware scheduling is a key capability to control congestion and worst
case latency
One important requirements for 802.11be is to differentiate (known) time-critical streams
from other traffic and serve them with predictable worst-case latency
This capability will also enable 802.11 to be integrated with Ethernet-based TSN, which is
one of the goals identified in the 802.11be/EHT PAR
The 802.11 MAC can introduce enhancements to better support time-
aware scheduling
Proposed modifications are limited to controlling queues and leveraging trigger-based access
for higher efficiency and lower latency
Slide 21
Dave Cavalcanti, Intel
November 2019
November 2019
Dave Cavalcanti, Intel
Slide 22
References
IEEE Std 802.1Qbv-2015.
Example: Setting up a downlink schedule over 802.11
November 2019
Dave Cavalcanti, Intel
Slide 23
TSN Talker
TSN Listener
802.1Qcc Centralized Model
Example:
Time-critical stream from Talker to (wireless) Listener: 100 bytes every 10 msec
1.
CUC/CNC collect the traffic requirements
2.
The CNC defines a Qbv schedule and configures the gate
control list at the TSN bridges and the TSN AP:
T0
T0+ 10ms
500 
µs
(Guard band)
1 ms
(gate open)
Time-critical
traffic
8.5 ms
(gate open)
Other (Best-Effort)
traffic
3.
The TSN AP confirms (via management interface) that it can
execute the schedule → 
new management interface capability
needed to agree on the schedule over a 802.11 link
4.
CUC configures the Qbv schedule at the end devices, 
including all
the 802.11 STAs in the WTSN domain (not only the listener) an
STAS confirm the reception (through management interface)
5.
TSN bridges, AP and end devices (STAs) start executing the
schedule at the specified time
6.
TSN AP transmits the time-critical DL data to TSN Listener STA at
the scheduled times, and STAs control channel access accordingly
Example Schedule
Example: Setting up an uplink schedule over 802.11
November 2019
Dave Cavalcanti, Intel
Slide 24
TSN Listener
TSN Talker
802.1Qcc Centralized Model
Example time-critical traffic stream:
Talker to (wireless) Listener: 100 bytes every 10 msec
1.
CUC/CNC collect the traffic requirements
2.
CNC defines a Qbv schedule and configures the gate control list
at the TSN bridges and the TSN capable STAs and AP:
T0
T0+ 10ms
500 
µs
(Guard band)
1 ms
(gate open)
Time-critical
traffic
8.5 ms
(gate open)
Other (Best-Effort)
traffic
3.
The TSN AP can execute the schedule for its Ethernet port (as it
doesn’t need to transmit over wireless)
4.
CUC configures the Qbv schedule at the 
Talker STA and other
802.11 STAs in the WTSN domain
5.
The Talker STA can confirm whether it can meet the uplink
schedule → 
802.11 support for a negotiation with the AP is
needed, if scheduled access (e.g. triggered) is used
6.
If in trigger-based mode, the 
AP schedules the UL
transmission at the requested times
. If not trigger-based
access, the Talker STA will try to transmit at the scheduled time
Example Schedule
Slide Note

doc.: IEEE 802.11-yy/xxxxr0

Month Year

John Doe, Some Company

Page

Embed
Share

Describing necessary enhancements to enable Time-Aware Scheduling in IEEE 802.11be for time-sensitive applications. The focus is on aligning with the 802.1Qbv standard to address latency, jitter, and reliability issues, presenting a structured outline of requirements and configurations essential for efficient scheduling over 802.11. The content discusses TSN components, standards, and operational models associated with Time-Aware scheduling within the IEEE framework.

  • Time-Aware Scheduling
  • IEEE 802.11be
  • 802.1Qbv Standard
  • TSN Components
  • Real-Time Applications

Uploaded on Aug 04, 2024 | 1 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.

E N D

Presentation Transcript


  1. November 2019 doc.: IEEE 802.11-19/1933r1 Capabilities to support Time-Aware Scheduling in 802.11be Date: 2018-12-19 Authors: Name Dave Cavalcanti Affiliations Intel Corporation Address Phone email dave.cavalcanti@intel.com 2111 NE 25th Ave, Hillsboro OR 97124, USA Dibakar Das Ganesh Venkatesan Susruth Sudhakaran Shimeon Greenberg Laurent Cariou Submission Slide 1 Dave Cavalcanti, Intel

  2. November 2019 doc.: IEEE 802.11-19/1933r1 Abstract This presentation describes gaps and new capabilities required to enable Time-Aware scheduling over the 802.11be for time-sensitive and real-time applications. The presentation focuses on Time-Aware scheduling as defined by the 802.1Qbv standard, but the concepts and solutions described may also be applicable more generally. Submission Slide 2 Dave Cavalcanti, Intel

  3. November 2019 doc.: IEEE 802.11-19/1933r1 Outline TSN and Time-Aware scheduling Issues and new requirements in mapping Time-Aware scheduling over 802.11 Part 1: Time-Aware (802.1Qbv) scheduling configuration over 802.11 Part 2: Time-Aware schedule execution enhancements (latency, jitter, reliability) Conclusions Submission Slide 3 Dave Cavalcanti, Intel

  4. November 2019 doc.: IEEE 802.11-19/1933r1 IEEE 802.1 Time-Sensitive Networking (TSN) Standard Ethernet with Synchronization, small and/or fixed latency, and extremely low packet loss TSN Components Common Standards Time synchronization: Time Synchronization (802.1AS) 802.1AS over 802.11 Timing Measurement (TM) Fine Timing Measurements (FTM) Ultra reliability: Frame Replication and Elimination (P802.1CB) Path Control and Reservation (802.1Qca) Per-Stream Filtering and Policing (802.1Qci) Reliability for time sync (P802.1AS-Rev) Synchronization Reliability Reliability Latency Bounded low latency: Time-Aware traffic shaping (802.1Qbv) Preemption (802.1Qbu/802.3br) Cyclic Scheduling (802.1Qch) Asynchronous Scheduling (802.1Qcr) Dedicated resources & API Stream Reservation Protocol (802.1Qat) TSN configuration (P802.1Qcc) YANG (P802.1Qcp) Link-local Registration Protocol (P802.1CS) Resource Mgmt Zero congestion loss Time-Aware scheduling (802.1Qbv) over 802.11 (extension to address bounded latency for scheduled traffic) 802.11aa (SRP over 802.11 for AV) 802.11ak (802.11 links in an 802.1Q network) Credit: J nos Farkas, Ericsson TSNA Conference 2017, http://www.tsnaconference.com/ Submission Slide 4 Dave Cavalcanti, Intel

  5. November 2019 doc.: IEEE 802.11-19/1933r1 Time-Aware (Qbv) Scheduling Operation model & Assumptions 802.1Qcc Centralized Model Assumptions: Time-critical traffic streams (max packet size and inter-arrival time) are known a priori (at configuration stage) CNC CUC The IEEE 802.1Qcc std defines management models (the centralized model is assumed here, other models are also possible) All TSN devices are synchronized to the same reference clock (through 802.1AS) The CUC collects the traffic stream requirements from end devices (Talkers/Listeners) and the CNC discovers the network topology The CNC computes the transmission schedule and the end to end path for each traffic stream and communicate the schedule to the CUC The CNC configures the schedule at TSN Bridges and the CUC configures the schedule in the end devices (e.g. via control plane using YANG/NETCONF) End Device End Device TSN Bridge Wired TSN Domain End Device End Device Wireless TSN Access Point Wireless TSN Domain Considerations 802.11 Access Points can be seen as Wireless TSN Bridges STAs can be configured as talkers or listeners The CUC/CNC need to coordinate with the WTSN domain (scheduling over wireless is within the 802.11 scope, but it needs to align with the overall CNC schedule) Wireless TSN Domain CUC: Central User Configuration CNC: Central Network Configuration Control plane (logical connection) between CUC and End Devices Control plane (logical connection) between CNC and TSN bridges Submission Slide 5 Dave Cavalcanti, Intel

  6. November 2019 doc.: IEEE 802.11-19/1933r1 Parameters and Example Schedule SetGateStates: State: C O O O O O O O TC : 7 6 5 4 3 2 1 0 SetGateStates: State: 0 C C C C C C C TC : 7 6 5 4 3 2 1 0 SetGateStates: State: C C C C C C C C TC : 7 6 5 4 3 2 1 0 8021.Q Traffic Classes (defined by PCP field in a VLAN Tag) to Queues Mapping on a TSN Bridge Traffic Class #7 Traffic Class #6 Traffic Class #5 Traffic Class #0 - - T2 T0 T1 Cycle Timing Data Gate Control Time-critical Traffic Gate Gate Gate Gate TC#7 TC#6 Transmission Selection TC#5 TC#4 Cycle: list of gate operations (SetGateStates), where each operation has a time delay (Gate Open Duration). The sequence of gate operations terminates at the end of the list and re-starts OperCycleTime after the start of the sequence. TC#3 TC#2 TC#1 TC#0 Guard-band protects time-critical traffic (the guard band behavior is inherent in the defined behavior of the gates, i.e., no explicit guard band is defined in the Qbv specification) Gate Open Duration for other (non-protected) traffic classes (TC#0-6) Gate Open Duration for Time-critical Traffic (TC#7) Guard band The Time-Aware scheduling behavior must be enforced at the MAC (e.g. 802.3 or 802.11) Time critical traffic can be protected by a guard band The Time-Aware scheduling behavior have to coexist/align with the 802.11 access mechanisms (e.g. EDCA and trigger-based access) Submission Slide 6 Dave Cavalcanti, Intel

  7. November 2019 doc.: IEEE 802.11-19/1933r1 Features required to support Time-Aware Scheduling Time synchronization Support for 802.1AS time synchronization is already enabled by 802.11 TM and FTM Classification and mapping packets of a traffic stream to a traffic class (aligned with 802.1Q traffic classification) 802.1Q and TCLAS traffic mapping capabilities defined in the 802.11 spec Enable a STA to receive a time-aware schedule request from the higher layer at the 802.11 MAC The schedule is used by the 802.11 MAC to control medium access and serve the traffic streams The 802.11 MAC may accept or reject the request (the decision is implementation specific) Enable execution of a time-aware schedule, i.e., deliver packets with certain deadlines (bounded latency) at requested time intervals The 802.11 MAC needs to provide predictable access to certain packets (preferably with high reliability) and enable non-AP STAs to request such service based on a higher layer trigger The time-aware schedule needs to take into account dynamic link states in 802.11 (negotiation with the higher layer may be required topic for collaboration between 802.1 and 802.11) Slide 7 Submission Dave Cavalcanti, Intel

  8. November 2019 doc.: IEEE 802.11-19/1933r1 Part 1: Time-Aware Schedule Configuration over 802.11 Submission Slide 8 Dave Cavalcanti, Intel

  9. November 2019 doc.: IEEE 802.11-19/1933r1 Time-Aware Schedule Configuration Extensions Qbv Schedule Computation: Traffic requirements are known (max pkt size, inter-arrival time) The CNC uses the link speed to create the schedule For Ethernet: The CNC assumes a fixed link speed (e.g. 1 Gbps) to compute the gate open duration for a given max packet size; For wireless/802.11: the CNC needs an estimate of time- aware scheduling support provided by the 802.11 MAC (worst-case latency for a given max packet size at predictable time intervals) Information about 802.11 capabilities could be added as part of Qbv configuration (802.1Qbv parameters wireless links) topic for collaboration between 802.1TSN and 802.11 The CNC can define a schedule and request the 802.11 devices (AP and STAs) to execute it, 802.11 devices need to indicate whether they can meet the requested schedule Need a management interface at the 802.11 MAC and primitives to accept/negotiate a Time-Aware Scheduling request from the higher (Qbv) layer 802.1Qcc Centralized Model CUC CNC End Device TSN Talker End Device TSN Switch Wired TSN Domain End Device End Device Wireless TSN Access Point TSN Listener Wireless TSN Domain CUC: Central User Configuration CNC: Central Network Configuration Submission Slide 9 Dave Cavalcanti, Intel

  10. November 2019 doc.: IEEE 802.11-19/1933r1 Time-Aware Schedule Configuration over 802.11 Outside 802.11 scope 802.1Q TSN mngmt entity 802.11 MLME SAP Qbv Schedule Config (e.g. from CNC) The AP decides whether it can serve the traffic streams according to the requested schedule. TASched.Request TASched.Response Qbv Schedule Config Response (e.g. to CNC) Non-AP STAs need to request the AP to be served according to the TA Schedule before responding. T0 Example TAS T0+ 10ms 1 ms 500 s (Guard band) 8.5 ms (gate open) Other traffic (gate open) Time-critical Dave Cavalcanti, Intel Submission Slide 10

  11. November 2019 doc.: IEEE 802.11-19/1933r1 STA initiated Time-Aware Scheduling Request (e.g. STA Talker scenario) Non-AP STA MLME SAP AP MLME SAP The AP decides whether it can serve the traffic streams according to the requested schedule. TASched.Request TAS.Request (TAS) T0 Example TAS T0+ 10ms 1 ms 500 s (Guard band) 8.5 ms (gate open) Other traffic (gate open) Time-critical TAS.Response ( ) TASched.Response STA responds to the higher layer based on the result of the negotiation with the AP Dave Cavalcanti, Intel Submission Slide 11

  12. November 2019 doc.: IEEE 802.11-19/1933r1 Summary of Gaps and Potential Solutions How to inform the 802.11 MAC of a Time-Aware (Qbv) Schedule request from the SME? A new MLME MLME-TA-SCHEDULE.Request (TAS). How to inform the AP of a STA s requested schedule? The STA can use the schedule information to generate a request to be served according to a certain service period (for a max packet size and inter-arrival time) The STA can use a new procedure or updated procedures (e.g. ADDTS Request/Response, TWT setup, ) If the AP agrees to schedule the STA as requested, the STA can confirm the upper layer request, otherwise, the STA declines the upper layer time-aware scheduling request The AP is responsible for scheduling DL and UL resources (if trigger-based mode is used), STAs can apply the schedule on top of their own queues (if non-trigger-based mode is used) How to ensure packet prioritization and latency bounds are met by the 802.11 MAC? Introduce the concept of a Time-Awareness within the 802.11 MAC to differentiate and prioritize channel access based on an agreed Time-Aware schedule Slide 12 Submission Dave Cavalcanti, Intel

  13. November 2019 doc.: IEEE 802.11-19/1933r1 Time-aware scheduling support via enhanced AddTS Request/Response Non-AP STA MAC AP STA SME AP STA MAC Non-AP STA SME MLME-AddTS.Request (TSPEC, TCLAS:VID, TAS) AddTS Request MLME-AddTS.Indication TAS Cycle MLME-AddTS.Response SP for Time-critical traffic Indicates that the AP agrees to serve the STA according to the requested schedule. AddTS Response MLME-AddTS.Confirm (TSPEC: TSID TCLAS: UP) : Guard band : Gate Open (Time-critical) : Gate Open (Other traffic) Submission Slide 13 Dave Cavalcanti, Intel

  14. November 2019 doc.: IEEE 802.11-19/1933r1 Additional considerations Other 802.11 mechanisms could also be used in combination with the time- aware scheduling support, e.g. If the STA has time-critical and other types of traffic, the TWT SP could help align the periods to save power Note: Traffic prioritization within a TWT SP is still according to the Qbv schedule. TWT SP for time-critical + other traffic TWT SP for Time-critical traffic : Guard band : Gate Open (Time-critical) : Gate Open (Other traffic) Submission Slide 14 Dave Cavalcanti, Intel

  15. November 2019 doc.: IEEE 802.11-19/1933r1 Part 2: Time-Aware Schedule Execution Enhancements (latency, jitter, reliability) over 802.11 Submission Slide 15 Dave Cavalcanti, Intel

  16. November 2019 doc.: IEEE 802.11-19/1933r1 Issues if the 802.11 MAC is not aware of time-critical packets and their required transmission schedule Time-sensitive frame Assuming the high priority AC is selected for the scheduled time-critical traffic On average, high priority AC should get faster access, but a time-critical frame may still wait in some situations, e.g.: other ACs get access first (as backoffs run independently) other non-time critical (e.g. voice) frames mapped to the same AC is ahead in the queue ongoing (long) TXOP before the scheduled time Main gaps: 1. Lack of protection for time-critical traffic, i.e., prevent other traffic from accessing the medium at certain times 2. Provide access at scheduled time for time-critical frames with minimal access delay and jitter Time-sensitive frame TXOP (AC_VI) Submission Slide 16 Dave Cavalcanti, Intel

  17. November 2019 doc.: IEEE 802.11-19/1933r1 Making the 802.11 MAC time-aware A Time-Aware schedule is defined by upper layer and passed to the 802.11 MAC via the SME-MLME-SAP interface Time-critical traffic identified by a given traffic class is mapped to a TID associated with a TSN Queue, other traffic is mapped to other EDCA queues If multiple flows are time critical, they can share one queue or multiple TSN queues can be created; 802.11be may define a mapping of TCs to 802.11 TID/TSN Queue when time-aware scheduling is used A Time-Aware Shaper (TAS) Function receives the TA Schedule from the Higher Layer The TAS Function pauses/resumes EDCAFs to avoid contention and protect the time-critical traffic according to the TAS (e.g. when the TSN queue is open, other queues are paused) A frame selection function (implementation dependent) selects frame(s) for transmission based on their priorities Higher (Qbv) Layer (TAS = GateControlList) SME-MLME SAP Time-Aware Shaper Function Time-sensitive frame selection Pause/Resume EDCAFs TSN Submission Slide 17 Dave Cavalcanti, Intel

  18. November 2019 doc.: IEEE 802.11-19/1933r1 TSN Channel Access The TSN Queue follows access rules to minimize latency and jitter, different modes may be enabled: Trigger-based: AP controls access in the DL and UL, STA and AP negotiate on expected service periods that are aligned with the Qbv schedule EDCA-based: regular EDCA access behavior (e.g. access parameters TBD) TSN Access: Trigger based or EDCA T4 T3 T2 T0 T1 guard band Time- critical TC#7 -> TSN TC#6 -> VO Example TC to 802.11 Queue mapping and Schedule TC#5 -> VI TC#4 BE TC#3 TC#2 BK TC#1 TC#0 Regular operation, channel access policing is applied by the Time-Aware Shaper Function Submission Slide 18 Dave Cavalcanti, Intel

  19. November 2019 doc.: IEEE 802.11-19/1933r1 Impact of unmanaged BSSs Time-Aware scheduling operates on managed STAs Interfering transmissions may impact the capability to guarantee bounded latency Unmanaged STAs/OBSSs are seen as interference The AP can take into account the level of interference when accepting/admitting TA schedules and defining SP durations Latency bound vs. capacity tradeoffs will depend on the level of interference and deployment scenario Submission Slide 19 Dave Cavalcanti, Intel

  20. November 2019 doc.: IEEE 802.11-19/1933r1 Summary of the new requirements to support Time- Aware Scheduling over 802.11be Interface to receive a time-aware schedule request from the higher layer Mechanism for STAs to request the AP to be served according to a time-aware schedule Time-awareness for policing channel access according to an agreed time-aware schedule Low latency access for time-critical frames (once the gate is open) and differentiation from other traffic classes trigger based access can help provide predictable access and control worst-case latency Submission Slide 20 Dave Cavalcanti, Intel

  21. November 2019 doc.: IEEE 802.11-19/1933r1 Conclusions Time-Aware scheduling is a key capability to control congestion and worst case latency One important requirements for 802.11be is to differentiate (known) time-critical streams from other traffic and serve them with predictable worst-case latency This capability will also enable 802.11 to be integrated with Ethernet-based TSN, which is one of the goals identified in the 802.11be/EHT PAR The 802.11 MAC can introduce enhancements to better support time- aware scheduling Proposed modifications are limited to controlling queues and leveraging trigger-based access for higher efficiency and lower latency Submission Slide 21 Dave Cavalcanti, Intel

  22. November 2019 doc.: IEEE 802.11-19/1933r1 References IEEE Std 802.1Qbv-2015. Submission Slide 22 Dave Cavalcanti, Intel

  23. November 2019 doc.: IEEE 802.11-19/1933r1 Example: Setting up a downlink schedule over 802.11 802.1Qcc Centralized Model 1. 2. CUC/CNC collect the traffic requirements The CNC defines a Qbv schedule and configures the gate control list at the TSN bridges and the TSN AP: CUC T0 T0+ 10ms CNC Example Schedule 500 s (Guard band) 1 ms 8.5 ms (gate open) Other (Best-Effort) traffic (gate open) Time-critical traffic End Device TSN Talker End Device TSN Switch Wired TSN Domain 3. The TSN AP confirms (via management interface) that it can execute the schedule new management interface capability needed to agree on the schedule over a 802.11 link CUC configures the Qbv schedule at the end devices, including all the 802.11 STAs in the WTSN domain (not only the listener) an STAS confirm the reception (through management interface) TSN bridges, AP and end devices (STAs) start executing the schedule at the specified time TSN AP transmits the time-critical DL data to TSN Listener STA at the scheduled times, and STAs control channel access accordingly End Device End Device Wireless TSN Access Point 4. TSN Listener Wireless TSN Domain Example: Time-critical stream from Talker to (wireless) Listener: 100 bytes every 10 msec 5. 6. Submission Slide 23 Dave Cavalcanti, Intel

  24. November 2019 doc.: IEEE 802.11-19/1933r1 Example: Setting up an uplink schedule over 802.11 802.1Qcc Centralized Model 1. 2. CUC/CNC collect the traffic requirements CNC defines a Qbv schedule and configures the gate control list at the TSN bridges and the TSN capable STAs and AP: T0 CUC T0+ 10ms CNC Example Schedule 500 s (Guard band) 1 ms 8.5 ms (gate open) Other (Best-Effort) traffic (gate open) Time-critical traffic End Device TSN Listener End Device TSN Switch Wired TSN Domain 3. The TSN AP can execute the schedule for its Ethernet port (as it doesn t need to transmit over wireless) CUC configures the Qbv schedule at the Talker STA and other 802.11 STAs in the WTSN domain The Talker STA can confirm whether it can meet the uplink schedule 802.11 support for a negotiation with the AP is needed, if scheduled access (e.g. triggered) is used If in trigger-based mode, the AP schedules the UL transmission at the requested times. If not trigger-based access, the Talker STA will try to transmit at the scheduled time 4. End Device End Device Wireless TSN Access Point TSN Talker Wireless TSN Domain 5. Example time-critical traffic stream: Talker to (wireless) Listener: 100 bytes every 10 msec 6. Submission Slide 24 Dave Cavalcanti, Intel

Related


More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#