Enhancements for QoS and Low Latency in IEEE 802.11be
Explore the August 2020 document IEEE 802.11-20/1350r1, focusing on improving Quality of Service (QoS) and reducing latency in 802.11be networks. The document addresses congestion-related latency issues, EHT capabilities, and tools for latency optimization. Learn about the scope, goals, and approach for latency enhancements in IEEE 802.11be R1.
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
August 2020 doc.: IEEE 802.11-20/1350r1 Enhancements for QoS and low latency in 802.11be R1 Date: 2020-10-12 Authors: Name Dave Cavalcanti Affiliations Intel Corporation Address Phone email Dibakar Das Chittabrata Gosh Laurent Cariou Submission Slide 1 Dave Cavalcanti, Intel Corporation
August 2020 doc.: IEEE 802.11-20/1350r1 Introduction This contribution builds on the QoS management (Doc#418r3) for low latency reliable services (LLRS) The proposed simple enhancements address the worst-case latency and jitter issues caused by congestion and can be enabled in R1 The concepts in this contribution are aligned with Doc#1046r5 Minimum basic support in R1 is required to ensure no coexistence issues between R1 and R2 EHT STAs Submission Slide 2 Dave Cavalcanti, Intel Corporation
August 2020 doc.: IEEE 802.11-20/1350r1 Problem: how to protect low latency data that have a deadline from congestion delay It is difficult to guarantee access to a given STA(s) at certain times, due to A general solution applicable in all conditions is challenging (not the goal of this contribution) Focus on EHT capabilities Unlicensed band Legacy devices Need to enable the 802.11 MAC to provide more predictable low latency Leverage 802.11be and previous tools Introduce new tools that enables the network to optimize for latency Contention-based channels access Submission Slide 3 Dave Cavalcanti, Intel Corporation
August 2020 doc.: IEEE 802.11-20/1350r1 Scope and goals for latency enhancements in 11be Our goal in R1 is to provide minimal support to avoid creating a new category of EHT legacy devices that do NOT coexist with EHT R2 low latency/channel access enhancements Need to avoid coexistence issues between R1 and R2 EHT devices There are many tools already in 802.11be (and previous specs) to improve latency such as MLO, TWT, TF that reduces the impact of intra-BSS congestion on low latency traffic In R1, we intend to mostly leverage and propose simple enhancements to those tools and improve latency for traffic that can be identified/classified through QoS negotiation Further performance enhancements can be introduced in R2 Submission Slide 4 Dave Cavalcanti, Intel Corporation
August 2020 doc.: IEEE 802.11-20/1350r1 Approach: Enable periods of time during which low latency traffic can be protected from intra-BSS congestion Normal operation outside Low latency traffic is prioritized/ protected from congestion Minimal Spec requirements in R1 Non-AP STA and AP negotiate establishment of or participation in a protected period If negotiation is successful, non-AP STA is a member of the protected period AP advertises the protected period(s) (Broadcast TWT can be reused/enhanced) Access rules for all associated EHT STAs during the protected periods: STAs shall finish their TXOPs before the period If a STA is not a member, it shall not transmit during the period Submission Slide 5 Dave Cavalcanti, Intel Corporation
August 2020 doc.: IEEE 802.11-20/1350r1 Example: Restricted SP set up and operation 1. QoS negotiation, traffic requirements Traffic requirements: SI= 10 msec Latency bound = 2msec PDR = 99.9% EHT STA EHT QoS AP MLD (e.g. Gaming, AR/VR, ...) 2. AP advertises Restricted service periods Low latency traffic is protected 1ms 1ms 10 ms 3. All EHT STAs follow access rules within Restricted SPs Dave Cavalcanti, Intel Corporation Submission Slide 6
August 2020 doc.: IEEE 802.11-20/1350r1 Access Rules for Participating EHT STAs Announced by the AP Normal operation (any TID and EDCA access resumed) Normal operation (no changes) Restricted service period (allowed STAs/TIDs and access rules) Configuration 1: Configuration 2: Trigger-enabled AP triggers STAs and prioritize allowed traffic (including P2P) Trigger SU PPDU would help make this mode more used Non-trigger-enabled EDCA access between members of the protected period (including P2P) Submission Slide 7 Dave Cavalcanti, Intel Corporation
August 2020 doc.: IEEE 802.11-20/1350r1 Conclusions We presented an approach to protect low latency traffic from intra-BSS congestion and avoid coexistence issues between R1 and R2 EHT STAs The approach leverages existing tools and capabilities The Spec changes required include Announcement and negotiation of restricted service periods Access rules for EHT STAs during the restricted service periods Further enhancements to address legacy and OBSS can be considered Submission Slide 8 Dave Cavalcanti, Intel Corporation
August 2020 doc.: IEEE 802.11-20/1350r1 SP #1 Do you agree to add to the TGbe SFD (in R1) A mechanism for defining restricted service periods for low latency traffic where AP and STA negotiate the creation of or the participation in a restricted service period Submission Slide 9 Dave Cavalcanti, Intel Corporation
August 2020 doc.: IEEE 802.11-20/1350r1 SP #2 Do you agree to add to the TGbe SFD (in R1) A mechanism for AP and STA to negotiate the creation of or the participation in a restricted service period for low latency traffic If negotiation is successful, non-AP STA is a member of the restricted service period AP advertises the protected period(s) in beacons Submission Slide 10 Dave Cavalcanti, Intel Corporation
August 2020 doc.: IEEE 802.11-20/1350r1 BACKUP Submission Slide 11 Dave Cavalcanti, Intel Corporation
August 2020 doc.: IEEE 802.11-20/1350r1 Simulation scenario 1 Single BSS: 6 STAs (2 Low Latency, 4 BE - 6 Mbps), 20 MHz channel LL traffic streams: 10Mpbs streaming video DL, Periodic 100 Byte every 4 ms UL LLS: low latency traffic using AC_VO + protected windows 1 ms windows every 5 ms VO: low latency streams using AC_VO Channel access: EDCA + Protected window for LLRS traffic Submission Slide 12 Dave Cavalcanti, Intel Corporation
doc.: IEEE 802.11-20/1350r1 August 2020 Scenario 1 - Results (20 MHz) LLS: low latency streams with protected windows VO: low latency as AC_VO (no protected windows) Submission Slide 13 Dave Cavalcanti, Intel Corporation
doc.: IEEE 802.11-20/1350r1 August 2020 Scenario 1 - Results (80 MHz) LLS: low latency streams with protected windows VO: low latency as AC_VO (no protected windows) Submission Slide 14 Dave Cavalcanti, Intel Corporation
doc.: IEEE 802.11-20/1350r1 August 2020 Scenario 1 - Results (40 MHz) LLS: low latency streams with protected windows VO: low latency as AC_VO (no protected windows) Submission Slide 15 Dave Cavalcanti, Intel Corporation
August 2020 doc.: IEEE 802.11-20/1350r1 Simulation scenario 2 Single BSS: 6 STAs (2 Low Latency, 4 BE - 6 Mbps), 20 MHz channel LL traffic streams: 100Bytes every 4 ms LLS: low latency traffic using AC_VO + protected windows 500 microseconds windows every 4 ms VO: low latency traffic using AC_VO Case 1: EDCA in protected window (AP and STAs contend) Case 2: Trigger based in protected window Submission Slide 16 Dave Cavalcanti, Intel Corporation
doc.: IEEE 802.11-20/1350r1 August 2020 Scenario 2- Case 1 Results LLS: low latency stream with protected windows VO: low latency as AC_VO (no protected windows) Submission Slide 17 Dave Cavalcanti, Intel Corporation
doc.: IEEE 802.11-20/1350r1 August 2020 Scenario 2 - Case 2 Results LLS: low latency stream with protected windows VO: low latency as AC_VO (no protected windows) Submission Slide 18 Dave Cavalcanti, Intel Corporation
August 2020 doc.: IEEE 802.11-20/1350r1 Scenario 2 with different non-compliancy levels (Case 1) LLS 0 = Low latency service with all Background STAs complying with the PW rules (limit TXOP before PW start and restrict access to LL traffic) LLS 2/4 = Low latency service w/ 2 or 4 (out of 4) Background STAs not complying with PW rules LLS 4b = 4 (out of 4) Background STAs still limiting their TXOP before the PW start time, but not complying with PW restricted access VO = no protection, low latency uses AC_VO Submission Slide 19 Dave Cavalcanti, Intel Corporation
August 2020 doc.: IEEE 802.11-20/1350r1 Scenario 2 with different non-compliancy levels (Case 2) LLS 0 = Low latency service with all Background STAs complying with the PW rules (limit TXOP before PW start and restrict access to LL traffic) LLS 2/4 = Low latency service w/ 2 or 4 (out of 4) Background STAs not complying with PW rules VO = no protection, low latency uses AC_VO Submission Slide 20 Dave Cavalcanti, Intel Corporation
