Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBE] Discussion on 11-21/1855: P2P Support in Restricted TWT: Use Cases and Signaling Design



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?  
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?

Best,
Kiseon

From: BARON Stephane <Stephane.BARON@xxxxxxxxxxxx>
Sent: Friday, November 12, 2021 8:32 AM
To: 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
 
You don't often get email from stephane.baron@xxxxxxxxxxxx. Learn why this is important

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.

 

From: Muhammad Kumail Haider <kumail.ieee@xxxxxxxxx>
Sent: vendredi 12 novembre 2021 02:03
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Discussion on 11-21/1855: P2P Support in Restricted TWT: Use Cases and Signaling Design

 

Hi all,

 

I have posted 11-21-1855-00-00be-p2p-support-in-restricted-twt-use-cases-and-signaling-design-discussion to Mentor. This slide deck is intended to continue discussion on p2p support in rTWT by providing some examples and clarifications as requested.

 

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.

 

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