| Hi Jarkko,
My further responses are in-line.
Regards, Kumail.
Hi Kumail, thank you for your responses. There is a lot of text that jumps to a solution. I am still trying to understand the basic logic.
Are you saying that new broadcast TWT recommendation (=5) is needed to be able to limit the traffic (TIDs) that can be transmitted within these SPs? - STAs that do not participate to rTWT may receive and transmit frames from any TID, but STAs that have setup this new rTWT SP type are allowed only to receive and transmit from the limited set of TIDs? - Why is it beneficial for a STA to limit the data that it can transmit or receive? - For instance, if TID=7 is not allowed to transmit in rTWT SP, then isn’t this causing lower priority traffic transmission before the highest priority traffic? (Priority inversion) - How a STA in rTWT SP receives or transmits data from the left-out / excluded TIDs?
I think there may be a misunderstanding; the proposed Recommendation value 5 does not limit/restrict traffic within an r-SP to latency sensitive TIDs only. The added text is only to differentiate value 5 from value 4: which is that p2p traffic exchange is allowed within schedules with Recomm value 5 and AP also schedules at least one MU RTS TXS Trigger with Sharing Mode 2, whereas that is not allowed in Recomm value 4. As we discussed in our offline chat/meetings, Traffic prioritization/restriction discussion is covered by 21/1115 and we plan to follow up with traffic prioritization rules in separate doc soon. Hope that clarifies that we are not proposing traffic restriction in this doc(21/1224) with Recommendation value 5.
- I did not find any response why we need both TID-to-link mapping and this new rTWT flow type.
I don’t see how TID-to-link mapping is relevant to this discussion. As I mentioned, TIDs are indicated as latency sensitive in UL/DL TID bitmaps in Restricted TWT Traffic Info subfield, as defined in 9.4.2.199 in P802.11D1.1.
The P2P traffic related response seems to say that r-TWT helps on Protecting P2P transmissions - Is the target here to say that P2P transmissions are more important to infrastructure transmissions and all associated STAs in BSS should terminate their TXOPs before some possible P2P transmissions? - This may have severe impact to STAs performance that expect to get good UL and DL service from the associated AP. - Wouldn’t it be better to do P2P in other channel, so that the P2P transmissions are not eating infrastructure transmissions capacity and the total system capacity could be increased? - I agree that rTWT does not help against hidden nodes or OBSS STAs.
The objective is to enable a STA to schedule and use r-TWT for both its UL/DL traffic and p2p traffic, where the p2p traffic can benefit from AP assistance in TXOP sharing and any channel access protection rule (the SP start). This is motivated by a consensus within the group to assist STA’s traffic with peer STA "The 802.11be amendment shall define mechanism(s) for an AP to assist a STA that communicates with another STA. [Motion 22, [9] and [157]]. It is up to AP’s discretion to allocate resources for p2p, if it has available, but the framework should allow/enable such operation.
Regarding using a different channel for p2p, additional channel may not always be available and it depends on STA’s p2p operation — if operating on a different and clean channel is possible, then by all means, the STA associated with the AP doesn’t need to use this rTWT to protect its p2p. The spec doesn’t force the STA to do so. It’s only when the STA has to, and wants to, and AP agrees to support it, then here is the tool to use and provide the benefit.
With rTWT support, STA gets more predictable times (i.e., within r-SP) when it can do p2p transmissions and enables AP to manage medium access (with MU RTS TXS Trigger).
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
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
|