| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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 From: huangguogang <huangguogang1@xxxxxxxxxx> Hi Binita, Actually, I had responded this before. I would like to summarize my response again. Please find it inline. Regards Guogang Huang 发件人:
Binita Gupta [mailto:binitagupta@xxxxxx]
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 From: huangguogang <000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx>
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 发件人:
Binita Gupta [mailto:000018fa53b0ef43-dmarc-request@xxxxxxxxxxxxxxxxx]
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 From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Hello all, This is a gentle reminder to all assignees of the deadline below, which was announced during the last Joint telco:
Also 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). Regards,
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
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 |