| 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.
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.
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.
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 Hello all,
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
|