Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBE] Clarifications on QoS management contribution (418r3)

Hi Jay Yang,

 

Thanks for the questions. Please see my responses in line.

 

Best,

Dave

 

 

From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Sent: Thursday, June 25, 2020 11:32 PM
To: Cavalcanti, Dave <dave.cavalcanti@xxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: Clarifications on QoS management contribution (418r3)

 

Hi Dave,

 

It’s good to re-use TID8-15 for the new coming flow in the further. I have some question on your presentation.

  1. How do you consider the EDCA ACs on TID8-15? Do you want to reuse current AC mechanisms(BE,BK,VI,VO) or create a new AC mechanisms(BE,BK,VI,VO,LLRS1,LLRS2…)? For the latter option, how many ACs do you want to create to map TID8-15? And what’s the new AC parameter and rules?

[DC] As we indicated in the SP and shown in the example in slide 12, the traffic streams using TIDs 8 – 15 can be mapped to the existing ACs. The new QoS parameters associated to these TIDs can be used to prioritize the data when mapped to some of the existing ACs. The topic of creating new AC is beyond the scope of this contribution, it could be considered in the future, but we’re trying to focus on the basic changes required in R1 at this point.

 

  1. In Slide16,(simulation scenario1), what’s the meaning of “protected windows”?

[DC] The simulation tries to illustrate what could be done if the low latency traffic can be classified (even if it is mapped to existing AC_VO). By knowing the traffic requirements of the low latency streams, the AP could define periods of time during which the low latency traffic is prioritized. The protected window in this example is a period of time that only low latency data streams are transmitted. It is just one example to illustrate what could be done once the traffic in classified and traffic profile information is provided through the QoS mechanism.

 

Thanks

 

Best Regards

 

Jay Yang

 

From: Cavalcanti, Dave <dave.cavalcanti@xxxxxxxxx>
Sent: 2020年6月26日 5:19
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [Suspected Marketing Mail] [STDS-802-11-TGBE] Clarifications on QoS management contribution (418r3)

 

All,

 

Since we were not able to cover all the questions during the discussion in MAC call earlier this week, we have uploaded a revision (418r3) with a few clarifications (see new slides 9, 10, 11). We have also updated the proposed SP#1 as follows:

 

  • Do you support defining a QoS mechanism so that the AP MLD and non-AP MLD can:
    1. Announce new QoS capabilities (for LLRS) of the MLD
    2. Provide traffic stream QoS description to enable classification across the MLD
    3. Use TIDs 8 - 15 to indicate a new class of QoS data streams (e.g. LLRS streams) mapped to EDCA ACs with associated QoS parameters (as defined in item 2.)
      • Note: the TID values are signaled in the QoS Control field of corresponding Data frames
      • Note: if an AP is not part of an AP MLD (legacy AP), the same mechanism would be used between the AP and a non-AP STA

 

Additional considerations:

  1. There is a need to enable differentiation for more than 2 traffic streams per access category (limitation in the current spec). For instance, voice, gaming, AV/VR, control/automation streams in a single device/AP will need differentiation beyond VO and VI traffic classes. See limitations in existing mechanisms in slides 9 and 10.
  2. The re-use of TIDs 8 to 15 to identify traffic streams will enable the prioritization based on new metrics (e.g. latency bound, jitter, reliability) and can be dynamically mapped to ACs
  3. HCCA, ADDTS, TSPEC provide QoS negotiation, but they are unlikely to be implemented as defined in the current spec. We propose a simplified QoS negotiation approach in the context of 11be that also incorporates/leverages MLO and enables traffic stream differentiation with the typical EDCA implementations.

 

Hopefully, this helps address some of the questions, but we welcome any further discussion.

 

Thanks,

 

Dave

 

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

Dave Cavalcanti, PhD

Principal Engineer

Wireless Communications Research, Intel Labs

Intel Corporation

dave.cavalcanti@xxxxxxxxx

 

 

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1