| Hi Jarkko,
Apologies for the late response, I missed this email earlier. Please see my further responses inline.
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.)
[MKH]: The key advantage of setting up r-TWT membership for a STA’s own traffic and/or its P2P traffic is that a STA is allocated resources periodically in corresponding r-SPs without having to signal repeatedly each time it needs to transmit, which is ideally suited for periodic traffic and saves signaling overhead. Having a known/predictable schedule also helps with STA’s power saving.
Further, our proposal is to enable AP assisted TXOP sharing within r-SPs (with MU RTS TXS Trigger) so that AP can assist with p2p traffic. This way, the latency sensitive traffic over the p2p link gets better protection (maybe not perfect due to hidden terminals but still an improvement).
Moreover, this is also a good application of the MU RTS TXS Trigger with TXOP Sharing Mode 2. During previous discussion, one concern was regarding possible use cases of Sharing Mode 2 by the AP. But now, with this rTWT setup and the STA explicitly let AP know this intention, AP can use the TXOP sharing with mode 2 purposefully.
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?
[MKH] Different STAs may want to prioritize certain TIDs among those enabled on a particular link depending on specific requirements, and r-TWT facilitates such prioritization while also providing protection at the start of SP. For this, indication of TIDs deemed latency sensitive have to be indicated during the r-TWT Setup, and hence the bitmaps are added to TWT element as defined in 9.4.2.199 in P802.11beD1.1.
Regards, Kumail.
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
|