Re: [STDS-802-11-TGBE] EMLSR CIDs #13413,13414,13811 in 1756r4

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

Hi Minyoung,

Thanks for the explanation. I have concerns about this restriction as I think it does not help the intended purpose.

Specifically, consider the following possible intended behaviors/cases at the non-AP MLD after the echoed EML OMN frame is received on a Link_x:

Link_x is supposed to move to doze state after this EML OMN frame reception per the original EML OMN frame: In this case, the AP MLD will anyway not continue any transaction on Link_x after receiving the acknowledgement to the EML OMN frame as it goes to doze.
Link_x is supposed to move to or stay in active state after this EML OMN frame reception: If the non-AP MLD is already awake on Link_x (to be able to receive the EML OMN frame), there are no further transitions necessary and hence, no required delay. There can be subsequent exchanges in the same TXOP on Link_x.
Link_y is supposed to move to doze state after this EML OMN frame reception: The AP MLD will anyway not send any frames on Link_y in this TXOP or a subsequent TXOP since it has already completed the transition. So, there is no delay needed.
Link_y is supposed to move to active state after this EML OMN frame reception: Curtailing the TXOP on Link_x only increases the chances of a TXOP starting immediately on Link_y and the delay can be as small as 25-50us.

Further,

There is already an allowance of SIFS+Ack time that the non-AP MLD gets after receiving the EML OMN frame from the AP MLD
The delay provided by curtailing the TXOP is not deterministic (For example, >=43us for AC_BE, >=25us for AC_VO, etc )
The non-AP MLD, while sending the request, would need to make necessary arrangements to perform the corresponding transitions. For example, if it intends for a certain link to become active or to go to doze and sends the EML OMN frame to the AP MLD, it would need to consider the deterministic delays required for the transition instead of depending on a random delay provided after transmitting acknowledgement to the EML OMN frame received from the AP MLD

Regards,

Sindhu

On Wed, Jan 11, 2023 at 10:32 PM Minyoung Park <mpark.ieee@xxxxxxxxx> wrote:

Hi Sindhu,

Liwen can explain more on this part but the intention is to give more time for a non-AP STA to process the received EML OMN action frame. Currently, a non-AP MLD enables/disables EMLSR mode right after transmitting acknowledgement as a response to the received EML OMN action frame and in some implementation processing an action frame could take longer time. So if another frame exchange sequence doesn't happen in the same TXOP with the EML OMN action frame, this helps the non-AP MLD to process the action frame, enable/disable EMLSR mode and be ready to receive the right PPDU/frame types in time.

Regards,
Minyoung

On Wed, Jan 11, 2023 at 6:21 AM Sindhu Verma <000011381223f2e2-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Hi Minyoung,

I wanted to ask you regarding the motivation behind the following proposed change in document 1756r6 (LB266 Comment Resolution Clause 35.3.17 EMLSR Part4) which has been added to both EMLSR enable and disable procedures:
“(#13413, 13414, 13811)The AP affiliated with the AP MLD that transmitted the EML Operating Mode Notification frame to the non-AP STA affiliated with the non-AP MLD in a TXOP shall not start another frame exchange sequence with the non-AP STA in the same TXOP.”

If the non-AP MLD is supposed to remain in active mode (following the EMLSR enable/disable) on the link that received the EML OMN frame from the AP MLD, it can receive any subsequent frames from the AP in the same TXOP. It is only if the non-AP MLD is supposed to transition to doze state on that link after transmitting the acknowledgement, that the non-AP MLD should not be expected to continue frame exchanges in that TXOP. Is this the reason the text has been added? If that is the case, the AP MLD is anyway not expected to continue any frame exchanges with the non-AP MLD on the link that is in the doze state as a part of the legacy PS mode behavior. So, the added sentence is not necessary even for the latter case.

Regards,
Sindhu

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