Hi Kumail,
For following sentence, I think we should have a precondition to say both the AP and STA support TXS feature first(or TXS capable).
If Trigger frame(s) are addressed to an r-TWT scheduled STA by an r-TWT scheduling AP in a
trigger-enabled restricted TWT service period
negotiated with the r-TWT scheduled STA 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
Thanks
Best Regards
Jay Yang
From: NEZOU Patrice <Patrice.Nezou@xxxxxxxxxxxx>
Sent: 2021年10月19日 6:51
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Discussion on 11-21/1224 CC 36 CR for Restricted TWT Setup
Hi Kumail,
Thanks for your answer and your proposals.
My comments in
green below …
Regards
Patrice
Hi Patrice,
Thanks for your comments, my responses are inline.
Thanks for sharing your document.
I have few questions related to your last revision of your document. I think that some misunderstandings remain.
-
About the definition of a new value of Broadcast TWT Recommendation field. What is your intention with this new value ?
As Jarkko said before, today the value 4 is already defined for the transmission of latency sensitive data. For me, peer-to-peer traffics are latency sensitive traffic. For sure, the value 4 need more clarifications about what kind of
traffics are allowed to be transmitted. Why do you define a new one ?
[MKH]: The key difference between value 4 and 5 is that SP is negotiated for p2p+UL/DL traffic in value 5, whereas only for UL/DL in value 4. We further propose in 35.7.4.1that in trigger enabled
r-TWT SPs with value 5, AP also schedules at least one MU RTS TXS trigger with TXOP Sharing Mode 2 for the STA to use for its p2p traffic, whereas there is no such provision for Recommendation value 4 SPs.
The intention is to enable the AP to specifically advertise rTWT schedules during which it is willing to accommodate STA’s p2p traffic as well and allocate resources with MU RTS TXS Trigger. STAs
can also explicitly indicate they need SP for their p2p traffic as well with the Recommendation value 5.
[Patrice NEZOU] Today there is no specification with the Recommendation value 4. It is not reserved for UL/DL traffics. It is also for P2P. No spec text defines the traffics with the Recommendation value
4 in the draft 1.2 . So it is the same mode. Is there a need to define 2 modes ? or perhaps a P2P only mode would be better ?
-
In your doc, it is written : “An r-TWT scheduling AP may limit the usage of a restricted TWT service period for peer-to-peer traffic only, by sending a TWT Response frame with Broadcast TWT Recommendation field equal to 5 and all bits in Restricted TWT DL TID
Bitmap and Restricted TWT UL TID Bitmap subfields equal to 0(#4778).”
This sentence is not clear enough. Do you want to restrict the transmission for P2P traffics only ? If it is, I think that it would be better to define it directly in the table describing the functionality of each value of the Broadcast
TWT Recommendation field.
[MKH]: By definition of Recommendation value 5, both UL/DL and p2p traffic is allowed within such SPs. The intention of this sentence is to specify how an AP, if it wishes, may limit a schedule for
p2p traffic only by using the current signaling. This text was added in response to an offline comment that we should clarify if and how an AP may be able to restrict some schedules for p2p only, for relevant use-cases.
[Patrice NEZOU] In that case, why don’t you specify a P2P only mode with the Recommendation value 5 to be very clear ?
-
In your document, it is written: “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).”
P2P traffics is also allowed through EDCA mode. Why do you use a “shall” ? P2P traffics is transmitted not only after a MU RTS TXS frame.
[MKH]: This sentence is specifically for Triggered access in trigger enabled TWT SPs, and does not prohibit EDCA mode. The intention is that if AP accepts membership from an r-TWT STA with Recommendation
value 5 and SP is trigger enabled, then AP shall schedule at least one MU RTS TXS Trigger which STA can use for its p2p traffic. We propose to revise this sentence as follows (in next rev), based on another comments as well. Let me know if it makes the text
clearer.
"If Trigger frame(s) are addressed to an r-TWT scheduled STA by an r-TWT scheduling AP in a
trigger-enabled restricted TWT service period
negotiated with the r-TWT scheduled STA 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.
The r-TWT scheduling AP is not expected to schedule for transmission MU RTS TXS Trigger frames with TXOP Sharing Mode subfield to 2 that are addressed to an r-TWT scheduled STA which establishes membership in one or more r-TWT schedule(s)
with Recommendation value 5 outside of the corresponding TWT SPs. (#4778)”
[Patrice NEZOU] I agree with your first sentence. It is more clear. But when the trigger bit is set to 1, it is only a recommendation for the AP to solicit STAs with TFs (see 802.11ax-2021 - subclause 9.4.2.199 p.171).
It is not a “shall”. So I would prefer a “should” for the usage of the MU RTS TXS frame to be compliant. And your 2nd sentence is not clear. Do it mean that a STA cannot be scheduled outside the rTWT SPs ?
Globally, the proposed text need more clarifications.
[MKH]: I hope my above responses clarify the proposals. If you have specific suggestions to improve text, please propose.
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
|