Hi Binita,
I don’t see many benefits to add QoS Characteristics element into the TWT setup frame. Let alone the SCS mechanism has been already defined.
And I don’t think it will introduce much impact on the Spec to add the TWT element within the SCS Request/Response frames.
Regards
Guogang Huang
Hi Guogang,
Thanks for your follow-up response.
As I mentioned, the proposal aims to cover use cases when an rTWT TID carries a single traffic flow or maybe multiple traffic flows with similar QoS characteristics. For most use cases for LST (e.g. AR/VR use cases), the STA would typically map flows with different QoS characteristics to different TIDs to be able to provide QoS differentiation at the MAC layer. The proposal aims to optimize such scenarios. Other use cases where a single TID carries multiple traffic flows with different QoS characteristics may not be that common for AR/VR scenarios, hence I don’t see the need to optimize those.
Regarding your suggestion of adding TWT element in the SCS Request/Response frame, here are my thoughts – I see SCS and rTWT/TWT as two distinct features which can be used independently as well as complementary. SCS provides signaling for traffic classification (TCLAS), setting up QoS priority/UP and specifying QoS characteristics for UL/DL traffic flows. rTWT provides enhanced medium access protection and resource reservation to achieve predictable latency for low latency traffic. To me technically it does not make sense to combine rTWT and SCS features by attaching TWT setup with SCS messaging, since each feature is distinct with different purpose. Any such attempt will cause unnecessary changes to the existing SCS and TWT features with much bigger impact in the spec, which is not desirable IMO.
My goal in 22/34r1 is to enable flexibility for the STA to provide QoS characteristics for rTWT TIDs along with the rTWT setup when applicable/possible to optimize rTWT setup for those scenarios, with minimal changes to the existing spec.
Hope this clarifies.
Thanks,
Binita
Hi Binita,
Actually, I had responded this before. I would like to summarize my response again. Please find it inline.
Regards
Guogang Huang
Hi Guogang,
Thanks for your feedback on CR doc 22/34r1. Please find my inline response below.
Also, in the earlier email, I missed providing a summary of the proposal for members consideration (adding below).
Summary of CR doc 22/34r1 proposal:
CR doc 22/34r1 proposes enabling a non-AP STA to optionally include one or more QoS Characteristics element to provide traffic characteristics for the UL and/or DL r-TWT TIDs along with the r-TWT setup. This is beneficial for cases when a TID carries a single traffic flow (e.g. for dedicated AR/VR devices) as it enables a non-AP STA to provide QoS characteristics for that traffic flow along with the rTWT setup, avoiding two separate transactions (SCS then rTWT setup), which minimizes signaling overhead and provides faster rTWT setup for such latency sensitive traffic. The proposed change is quite simple – allow optionally including QoS Characteristics element(s) in TWT setup frame.
[Guogang Huang]Your proposed resolution only can cover this case: a TID carries a single traffic flow. Hence, its benefit is minor. If you really want to avoid two separate transactions (SCS then rTWT setup) and minimize the signaling overhead, you can add the TWT element into the SCS request/response frames.
Also, if a STA maps multiple traffic flows with different QoS characteristics to same TID, then CR doc mentions that the STA should use SCS procedure to provide QoS Characteristics for those traffic flows to the AP. So, the STA has the flexibility to choose the best suited mechanism for providing QoS Characteristics for latency sensitive traffic flows to the AP.
[Guogang Huang]So you also agree that your proposed resolution cannot completely replace the SCS mechanism.
All,
Please let me know if you have any comments/questions on the proposal.
Thanks,
Binita
Hi Binita,
For this CR document, I had ever discussed with you. I would like to summarize the reason I don’t support this resolution.
Based on the current text, it’s allowed to map several SCS streams with different QoS Characteristic elements to the same TID. The QoS characteristic element contains a set of parameters that define the characteristics and QoS expectations of a traffic flow, rather than a TID. Hence, the proposed resolution doesn’t make sense.
[Binita] As the proposal mentions, the STA can choose to provide QoS Characteristics elements in the rTWT setup if the r-TWT TIDs carries a single traffic flow for faster rTWT setup and minimize signaling overhead. In other cases when multiple SCS streams are mapped to the same TID with different QoS characteristics, then STA should use SCS procedure to provide QoS characteristics as mentioned in the CR doc as well. The STA has the flexibility to choose the best suited mechanism for providing QoS Characteristics to the AP.
Before we discuss the above issue clearly, it’s better to defer this SP.
Regards
Guogang Huang
Hi Alfred,
Could you please queue the CR doc 11-22/34r1 for the MAC queue? It addresses 2 CIDs.
All,
Please let me know if you have any comments/questions on 11-22/34r1.
Thanks,
Binita
Hello all,
This is a gentle reminder to all assignees of the deadline below, which was announced during the last Joint telco:
- Provide DCNs and ETAs for unresolved CIDs: Deadline: April 5th, 2022.
- Afterwards, CIDs assigned to unresponsive assignees to be reassigned.
1) if there are any reassignments of CIDs among members please make sure to let me and Edward know of it so that the spreadsheet can be updated, and
2) also ensure that resolution documents do not mix CIDs that have a status of "Assigned" (these are CIDs with a resolution that has not yet been presented) and a status of "Resolution Drafted" (these are CIDs with a resolution that has already been presented).
Please let me know of any questions.
I wish everybody a nice weekend and happy holidays (noting that TGbe has no conference calls on Monday).
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
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