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

Re: [STDS-802-11-TGBE] Discussion on 802.11-22/1535r1-P2P Comm. with EMLSR Peer in Triggered TXOP Sharing



Hi Ronny,

 

Thank you for initiating this discussion. I did not comment during your presentation, but I looked at it offline and I have some thoughts that I believe were not covered by other reviewers.

 

First let’s clarify that we are only considering TDLS on a single-link, as this the only mode the spec currently defines.

So, using your example, STA2 operates in EMLSR (with AP MLD1) on Link1 and LinkX, and STA1 has a TDLS link with STA2 on Link1.

How efficient and friendly for the other devices which operate on the same channel as Link1 would be for STA2 to use TDLS (or any other P2P) on this channel? At the times STA2 commits to LinkX, it will not be able to listen or receive on Link1, which means that TDLS/P2P will only opportunistically get the STA2 to respond/ack its frames.

To make this worse, when the AP reserves the TxOp on Link1, the NAV will be reserved from the point of view of STA2, and that increases the chances STA2 initiates a TxOp on LinkX, which means it will definitely not be available on Link1.

 

Kind regards,

Michail

 

From: Ronny Yongho Kim [mailto:ronny1004@xxxxxxxxx]
Sent: 15 November 2022 09:23
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Discussion on 802.11-22/1535r1-P2P Comm. with EMLSR Peer in Triggered TXOP Sharing

 

Hi, All

 

I would like to initiate discussion on P2P communication with EMLSR P2P Peer.

Thank you, Minyoung, Morteza, Pascal and Yong for the feedback during the presentation yesterday.

I would like to continue discussion with members interested in this issue. 

Summary of the yesterdays discussion is as follows.

[Minyoung] EMLSR P2P peer can operate in normal mode(not EMLSR mode) during the triggered TXOP sharing period since P2P communication is pre-scheduled. Because P2P communication operation is decoupled from a infrastructure operation, we dont need to worry about infrastructure mode during P2P communication operation.

·        AP MLD is able to know STA1s P2P peers during P2P(TDLS) setup. AP MLD might know when STA1 will start P2P communication but AP can not know which is STA1s P2P recipient since STA1 might have other P2P peers. I think P2P communication is not decoupled from infrastructure mode operation, P2P communication is more independent of infrastructure mode operation, which means a P2P STA can perform P2P communication at any time regardless whether the P2P STA is working with AP or not.

[Morteza] Peer STAs need to exchange control frames for EMLSR parameters such as transition delay.

·        If STA is allowed to transmit ICT to EMLSR STA, EMLSR parameters exchange between STAs is required. As Pascal pointed out, another solution might be AP engagement. AP might be engaged to make EMLSR P2P STA operate in EMLSR operation. Once the direction is decided, EMLSR related procedure between STAs shall be considered.

[Pascal]  AP can take an action for this case

·        AP based solution is also possible. In r0 version, I proposed several options. I need some feedback which option is most preferable.

[Option 1] AP assisted mode change

image.png

 

[Option 2] New TXS mode (STA2 overhears MU-RTS TXS mode 3)

image.png

 

[Option 3] Allow a P2P sender to transmit ICF (same procedure in R1)

image.png

 

[Yong]  AP can also transmit Data to STA2 at the same time.

·        During the time(TXOP) shared with STA1, AP can not transmit data to STA2 since it's within APs TXOP and STA2 is also an associated STA. 

 

Best Regards,

Ronny Yongho Kim

 


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