Re: [STDS-802-11-TGBE] Discussion on 802.11-22/1535r1-P2P Comm. with EML

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

Hi Ronny,

Thank you for the response. I think we agree on most of the anticipated inefficiencies; the disagreement is on whether your proposal brings material improvements.

[Ronny] This is also inefficiency with EMLSR P2P. However, because the scenario you mentioned is STA2’s uplink transmission case, I think this would not happen quite often during that allocated TXOP sharing period.

Why do you expect this to not happen often? STA2 may have uplink transmissions; TDLS does not change this in any meaningful way, right?

I admit that I do not have any good suggestions to mitigate the issues or improve your proposal. Often implementations realise the issues and choose to not use a feature even if it is allowed by the specification. TDLS is an option for STA1 and STA2, STA2 can deny the TDLS Setup or initiate a TDLS Teardown when it operates in EMLSR; the path via the BSS will still be available. Alternatively, STA2 also has the option to disable EMLSR when it sets up TDLS and enabled alter when TDLS is torn down.

To clarify, I am not taking a position against your proposal. I find that it does not address the major issues anticipated with using TDLS with EMLSR and I am trying to raise awareness.

Kind regards,

Michail

From: 용호 김 [mailto:ronny1004@xxxxxxxxx]
Sent: 16 November 2022 01:12
To: Michail Koundourakis <m.koundou@xxxxxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Discussion on 802.11-22/1535r1-P2P Comm. with EMLSR Peer in Triggered TXOP Sharing

HI Michail,

Thanks for your comment. I understand the inefficiency that you pointed out. However, we need some kind of mechanism to enable P2P with EMLSR peer while minimizing inefficiency. If you have any good suggestion, I am open for that.

My replies inline.

보낸 사람: Michail Koundourakis
보낸 날짜: 2022년 11월 15일 화요일 오후 5:32
받는 사람: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
제목: 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.

[Ronny] This is evident inefficiency we have with EMLSR P2P. In order to minimize the wasting time on Link1due to STA2’s EMLSR operation on LinkX, STA1 has to know all the STA2’s EMLSR activities but this is not a feasible solution.

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 yesterday’s 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 don’t need to worry about infrastructure mode during P2P communication operation.

1. AP MLD is able to know STA1’s P2P peers during P2P(TDLS) setup. AP MLD might know when STA1 will start P2P communication but AP can not know which is STA1’s 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.

1. 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

1. 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

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

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

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

1. During the time(TXOP) shared with STA1, AP can not transmit data to STA2 since it's within AP’s 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