Hi Kumail,
Thank you for your quick response. Now, I see.
Regards,
From: Muhammad Kumail Haider <kumail.ieee@xxxxxxxxx>
Sent: Friday, November 12, 2021 5:21 PM
To: Kiseon Ryu <kryu@xxxxxxxxxx>; BARON Stephane <Stephane.BARON@xxxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBE] Discussion on 11-21/1855: P2P Support in Restricted TWT: Use Cases and Signaling Design
Stephane, thanks for expressing support and hope to work together on this.
Kiseon, thanks for your comments. My responses are inline.
Regards,
Kumail.
Hi Kumail,
Thank you for your clarification contribution. I have one question
for clarification in your slides.
In slide 7 example usage scenario, an AP advertises an r-TWT schedule supporting p2p in a Beacon frame first, and then a STA receiving the Beacon frame requests a membership of the r-TWT by sending a TWT req.
Q1: If the AP does not receive a TWT request from any STA after sending the bTWT IE with recommendation value 5 (i.e., no member STA of the TWT for p2p support), shall the AP send at least one MU RTS TXS Trigger during the r-TWT SP for
this case as proposed in slide 6?
[MKH]: AP doesn’t need to send the trigger frame in this case. As mentioned in the following text (from slide 6), establishing membership in the schedule is required for the rule for MU RTS TXS Trigger scheduling to be applicable.
“If both the r-TWT scheduling AP and r-TWT scheduled STA have the Triggered TXOP Sharing Support subfield in EHT Capabilities element to 1, and if Trigger frame(s) are addressed to the
r-TWT scheduled STA by the AP in a trigger-enabled restricted TWT service period
negotiated with the 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."
Q2: Shall the member STA of the bTWT ID i with recomm value 5 buffer the latency sensitive p2p traffic instead of transmission using
EDCA access until a TXOP is shared by the AP using an MU RTS TXS Trigger frame during an rTWT SP?
[MKH]: Yes, the member STA should (not shall as it’s a recommendation) wait until the allocated TXOP to transmit its p2p LST. It is beneficial for the STA as well, as it gets a periodic and predictable TXOP within the SP,
and doesn’t need to contend using EDCA for channel access. That’s the key motivation and advantage of setting up rTWT.
Best,
Kiseon
Hi Kumail,
Thank you for the clarification.
I fully support the approach you have and I would also add that one major advantage (side 6) for non AP sta having P2P latency sensitive traffic is that using rTWT is the only way to have a predictable medium access for its traffic.
This predictable medium access was not achievable for UL traffic until 11be, and to me, this is the reason why 11be introduced rTWT.
This is exactly why P2P station will be eager to use it.
So this is clearly a win win situation. On one hand, the AP will control the allocated time and will face less interferences from the P2P STA, and on the other hand, the P2P STA will have predictable medium access for its latency
sensitive traffic.
Regards.
Stéphane.
Hi all,
Resolution of several p2p related CIDs was proposed in 21/1224 but was deferred to allow further discussion. Key comments that we received during the presentation and offline are as follows:
-
Clarify with examples of use-case and signaling
-
Clarify distinction between Recommendation Values 4 and 5
-
MU RTS TXS Trigger scheduling provisions for p2p need further clarification; also specify both AP and STA support the feature.
1855 presents an example use-case scenario and also examples of how the proposed signaling may be used. We have also suggested spec text to specify that for MU RTS TXS Trigger scheduling, both AP and STA need to support Triggered TXOP Sharing.
Please let me know further comments in this thread and hope we can work together to converge on this topic.
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
|