| Hi Kumail,
Thank you for your responses. I would still like to understand the need for this new rTWT Flow type.
The 802.11be allows STA to signal the SCS Flow and its QoS needs for AP, if STA wants to make AP aware of its P2P transmissions. I think information like this is enough to get P2P transmissions done. P2P triggering may be done at any time without TWT, in individual TWT or in most of the BC TWT recommendations. (Some of the BC-TWT recommendations (values 1 & 2) are very hard to use and only meant for ?signaling?. I am not sure are they relevant.)
I think the STA knows the best what UL traffic is the most urgent and needs to be transmitted next. Similarly AP knows the most urgent DL traffic. There are already means to control TIDs that may be transmitted in a link (TID-to-link-mapping). Why do we need so many control mechanisms for the same operation?
Hi Jarkko,
Thanks for your comments. Please see my responses inline.
Hi Kumail, thank you for your submission and taking the questions/comments.
All operations of TWT Recommendation value 5 flow are possible with a value 4 flow. I am wondering why we need the value 5 option?
[MKH]: Proposed text in 1224r6 (SC 35.7.4.1) specifies: "If Trigger frame(s) are addressed to an r-TWT
scheduled STA by an r-TWT scheduling AP in a restricted TWT service period with
Broadcast TWT Recommendation field equal to 5, then at least one Trigger frame
shall be an MU RTS TXS Trigger frame with TXOP Sharing Mode subfield equal to
2(#4778).”
This provision is specifically for accommodating STA’s p2p traffic and does not apply to r-TWT SP with Recommendation Value 4.
Another advantage is that such a distinction allows AP to advertise specific schedules in which it is willing to accommodate p2p traffic. For schedules with Recommendation Value 4, the AP will accommodate r-TWT requests for UL/DL traffic only.
- P2P transmissions have own clock that synchronize these transmissions. It is very hard to synchronize the AP clock and the P2P clock.
Using rTWT for p2p does not require clock level synchronization or time synchronization. The peer-to-peer link would have to manage its schedule (which can be done at large granularity level) to benefit from the AP assisted approach. If the schedule doesn’t fit, STA can choose not to setup r-TWT for its p2p. - The UL and DL TID limitations allow AP to dictate what traffic is transmitted in the rTWT SP. This is causes poor SP utilization, complicates STA scheduling and degrades overall QoS.
UL/DL TID bitmaps identify which traffic is deemed latency sensitive, which is desired to be delivered with higher priority and is the key reason an r-TWT is setup. I fail to see how prioritizing this traffic in r-TWT would degrade overall QoS? Regarding your concern about poor SP utilization, current r-TWT spec does not limit/restrict transmissions within an r-SP to latency sensitive TIDs only. How traffic is prioritized within an r-SP is ongoing discussion in the group (21/1115); however, that is beyond the scope of this doc (setup).
Moreover, the UL and DL TID bitmaps are not strictly dictated by the AP. These are indicated during r-TWT setup for latency sensitive traffic identification and a STA can also indicate these TIDs in the r-TWT Request.
JKN: The overall QoS is about all TIDs. Here only some TIDs seem important. Other TIDs that are not included will get very poor service. I see no value to restrict the traffic in rTWT SPs.
Regards, Kumail.
Cheers, Jarkko <Screen Shot 2021-09-30 at 08.23.30.png>
Hello all,
Following up on the discussion in today’s call. There were several people still in the queue; I noted Rubayet, Jarkko, Guogang, Liwen, Liangxiao, Stephane and Qi. Please let me know your comments/questions and appreciate the feedback!
Kumail.
Hello all,
I received several comments since Rev.4 was posted and had offline discussions as well. Based on feedback, the doc is updated to Rev.6 11-21/1224 CC 36 CR for Restricted TWT Setup. Please review and let me know if there are any further comments/questions.
Best regards, Kumail
Hello all,
Best regards, Kumail
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
|