Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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 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. [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. Kind regards, Michail From: Ronny Yongho Kim [mailto:ronny1004@xxxxxxxxx] 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 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 |