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/1224 CC 36 CR for Restricted TWT Setup



Hi Kumail,

 

Thank you very much for your response. Please see my comments inline.

 

Best

Rubayet

 

From: Muhammad Kumail Haider <kumail.ieee@xxxxxxxxx>
Sent: Wednesday, September 29, 2021 6:55 PM
To: Rubayet Shafin <r.shafin@xxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Discussion on 11-21/1224 CC 36 CR for Restricted TWT Setup

 

Hi Rubayet,

 

Thanks for the feedback.

 

I have revised the doc to rev.6 on the server and I hope that clarifies further on peer-to-peer support. 

 

To answer your questions, our proposal is p2p allowed, not p2p only. So interpretation 1 is correct for schedules that indicate p2p is allowed. 

 

What TIDs are used for p2p link are p2p link side's configuration. The STA sending TWT Request frame with p2p indication requests certain resources (wake time, duration, TWT interval) and it is on AP’s discretion if it wants to assist the P2P link and allocate those resources. If the STA uses those resources (e.g., time allocated in MU RTS TXS sharing frame with TXOP Sharing Mode 2 which allows p2p) for its latency tolerant traffic, then its latency sensitive traffic won’t get the r-TWT protection. 

 

Rubayet: This is exactly the problem. Restricted TWT is broadcast in nature, i.e. the same schedule is shared by multiple STAs. What one STA is doing within the SP can affect other STAs. For instance, assume that three STAs, STA1, STA2, and STA3, have obtained membership of an rTWT schedule. Since you ‘allow’ p2p with UL/DL in the same schedule, if STA1 is transmitting latency-tolerant traffic over the peer-to-peer link, and STA2 and STA3 are using the schedule for UL/DL communication (which, by existing spec, is for latency-sensitive traffic only), then it won’t be fair for STA2 and STA3 to share the same schedule with STA1. Do you agree?

 

 

So from a scheduling point, the idea is to enable AP to assist a STA’s p2p traffic if it can allocate resources (by advertising schedules which support p2p) and then deciding using TWT parameters how much resources are allocated to a STA for its UL/DL and p2p traffic, and not to control TIDs on p2p link.

 

Rubayet: As explained above, it is not only that particular P2P STA’s issue, but also issue of other UL/DL STAs that are member of the same rTWT schedule and can only send latency-sensitive traffic within the rTWT SP.

 

How to do the setup for peer-to-peer? Does only one of the peer-to-peer STAs need to establish rTWT  membership with the associated rTWT scheduling AP or both peer-to-peer STAs need to establish rTWT membership in order to utilize the rTWT schedule for peer-to-peer communication?

 

Only one STA needs to establish membership. It is not required that both peer STAs of the p2p link are associated with the r-TWT scheduling AP.

 

 

Regards,

Kumail.

 

 

On Sep 29, 2021, at 10:51 AM, Rubayet Shafin <r.shafin@xxxxxxxxxxx> wrote:

 

Hi Kumail,

 

Thanks so much for sharing the document.

 

For the peer-to-peer part, some clarification would be helpful. Current text seems to be open for interpretation. For instance, when you say once peer-to-peer bit is set to 1, it would mean that AP ‘allows’ the rTWT schedule for peer-to-peer communication. A few cases can happen here—

 

1.      Interpretation 1: The same rTWT schedule is used for both UL/DL communication and  peer-to-peer communication.

-        Now, there is some control for UL/DL communication through TID (latency-sensitive) negotiation using existing spec. But the concern is that there is no such control for peer-to-peer communication. When you mix UL/DL and peer-to-peer for the same schedule, the peer-to-peer STAs can transmit any kind of traffic (latency-tolerant) while the STAs involved in UL/DL transmission are latency-sensitive traffic-only within the same rTWT SP, which is not fair for the latter group of STAs, right?

-        Some other questions—

o   How to do the setup for peer-to-peer? Does only one of the peer-to-peer STAs need to establish rTWT  membership with the associated rTWT scheduling AP or both peer-to-peer STAs need to establish rTWT membership in order to utilize the rTWT schedule for peer-to-peer communication?

2.      Interpretation 2: Separate rTWT schedules are used for UL/DL transmission and for peer-to-peer transmission

-        How to control the TIDs so that only latency sensitive TIDs are allowed for transmission over the peer-to-peer link?

 

If you could clarify overall peer-to-peer operation, that would be great.

 

Best

Rubayet

 

 

From: Muhammad Kumail Haider <kumail.ieee@xxxxxxxxx> 
Sent: Monday, September 20, 2021 2:44 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Discussion on 11-21/1224 CC 36 CR for Restricted TWT Setup

 

Hello all,

 

I have updated 11-21/1224 CC 36 CR for Restricted TWT Setup to Rev.4 based on feedback from the group and offline discussions. Please let me know if there are any further comments/questions. 

 

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