| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
According to 11be_D2.3, non-AP STA on other link (i.e., the link that the notification frame from the non-AP MLD is not transmitted on) may be in power save before and duration the red box, although the non-AP MLD may not send a frame with PM=1 during the red box.With the proposed change, the non-AP MLD essentially needs to enter power at the beginning of the red box, and cannot be in power save during the entire duration of the red box (which can be as long as 128 TUs), while the AP MLD will be in EMLSR starting at the end of the red box. This puts additional restriction on non-AP MLD’s power save during the transition, which again can be as long as 128 TUs.Regards,QiOn Jan 15, 2023, at 4:18 PM, Xiaogang Chen <xiaogang.chen@xxxxxxxx> wrote:Hi Minyoung, Gaurang,Thanks for the discussions. In this sense, my understanding is that within the red marked duration of 1st figure, although non-AP MLD is not in EMLSR mode, any frame exchange, not only the EML OMN, needs to be preceded with initial control frame. This’s better to be clarified in D3.0.In addition, for the 2nd figure (AP doesn’t send EML OMN), any frame exchange during the red marked interval also needs to be preceded with initial control frame. Let me know your thoughts. Thanks.<image004.png><image001.png>BRs,Xiaogang.From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Sent: Saturday, January 14, 2023 3:56 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] EMLSR doc 1756r7Hi Minyoung, Xiaogang,Thank you for the discussions.Regarding the text on AP MLD sending an initial Control frame prior to the EML OMN frame, the intention is to harmonize the two interpretations of the spec text – the one that Minyoung is saying and the one that Xiaogang interpreted. The initial Control frame before the EML OMN ensures that the non-AP MLD can receive the EML OMN frame.Thanks,GaurangFrom: Minyoung Park <mpark.ieee@xxxxxxxxx>
Sent: Friday, January 13, 2023 4:51 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] EMLSR doc 1756r7WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Xiaogang,On 1: that wasn't the intention we have a 'comma' for that and sure we can further clarify the text to clarify the intention but probably in the next round.On 2: Qi is working on this part in her contribution 2175 by removing large transition timeout values from the table and adding a condition.Thanks,MinyoungOn Fri, Jan 13, 2023 at 3:41 PM Xiaogang Chen <xiaogang.chen@xxxxxxxx> wrote:Thanks Minyoung. Several follow ups:
- I interpreted the sentence as after AP MLD send ACK as a response to the EML OMN sent by the non-AP MLD (successful transmission). The Non-AP MLD is in EMLSR mode already. In the meanwhile, any links not in active mode need to transition to active before the timer expire or EML OMN sent by AP MLD… if that’s not the intension, it’s better to swap the green and blue part. Not sure how the group think.
After the successful transmission of the EML Operating Mode Notification frame (#13411)(#11454)(#14000)by the (#12242)non-AP STA affiliated with the non-AP MLD, after the (#13414)timeout interval indicated in the Transition Timeout subfield in the EML Capabilities subfield of the Basic Multi-Link element, the non-AP MLD shall operate in the EMLSR mode and the other STAs operating on the corresponding EMLSR links shall transition to active mode
- If the non-AP MLD is not in EMLSR mode, during the red marked period, which could be a long duration depends on the time out timer, the non-AP STAs can firstly go to doze by set PM=1 and then be active before the timer expire for power saving. This won’t break the EMLSR operation because it’s not in EMLSR yet. However, the following sentence prevent non-AP STA doing so…
Any of the other STAs operating on the corresponding EMLSR link shall not transmit a frame with the Power Management subfield set to 1 before receiving the EML Operating Mode Notification frame from (#13415)one of the APs operating on the EMLSR links and affiliated with the AP MLD or before the end of the timeout interval.BRs,Xiaogang.From: Minyoung Park <mpark.ieee@xxxxxxxxx>
Sent: Friday, January 13, 2023 1:51 PM
To: Xiaogang Chen <xiaogang.chen@xxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] EMLSR doc 1756r7Hi Xiaogang,After the successful transmission of the EML OMN frame, (The EMLSR mode is enabled AND the power state of the other link is changed to active) AFTER (the timer expires OR the action frame is received by the AP). I color coded below.Based on the current draft, the non-AP MLD is not in the EMLSR mode yet since the timer hasn't expired yet.Regards,MinyoungOn Fri, Jan 13, 2023 at 1:38 PM Xiaogang Chen <xiaogang.chen@xxxxxxxx> wrote:Hi Minyoung,I didn’t get time to explain my comments in the call. Even with these two new sentences, the issue below is still not clear to me.During the period marked red, if AP MLD want to do frame exchange with non-AP MLD, should AP MLD assume the non-AP MLD in EMLSR state or not in EMLSR state?The figure is saying EMLSR disabled, but sentence below is saying after successful transmission of EML OMN, non-AP MLD is in EMLSR state.In addition, during that marked period, if link 1 is not in PS/doze but active, then EMLSR mode will be enabled instead of disabled as in the figure?After the successful transmission of the EML Operating Mode Notification frame (#13411)(#11454)(#14000)by the (#12242)non-AP STA affiliated with the non-AP MLD, the non-AP MLD shall operate in the EMLSR mode and the other STAs operating on the corresponding EMLSR links shall transition to active mode after the (#13414)timeout interval indicated in the Transition Timeout subfield in the EML Capabilities subfield of the Basic Multi-Link element<image001.png>BRs,Xiaogang.From: Minyoung Park <mpark.ieee@xxxxxxxxx>
Sent: Friday, January 13, 2023 10:53 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] EMLSR doc 1756r7Hi Sindhu, all,Thanks for the feedback in the call.Liwen - the general comments during the call on the following sentence "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." were that this restriction is not needed with what Sindhu explained below and some comments in the chat window from Matt. Please let me know if you still believe this sentence is needed or if you have any other suggested changes to the text.Gaurang - there were some questions on having the initial control frame before the action frame transmitted by the AP during the EMLSR enable procedure. "The EML Operating Mode Notification frame transmitted by the AP affiliated with the AP MLD shall be preceded by an initial Control frame." Could you please share your intention with the group to add this sentence so that the group can have better understanding? I tried in the meeting but maybe it is better for you to explain.I would also appreciate any other suggestions from the group to move forward.Best regards,MinyoungOn Fri, Jan 13, 2023 at 5:02 AM Sindhu Verma <000011381223f2e2-dmarc-request@xxxxxxxxxxxxxxxxx> wrote: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,SindhuOn 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,MinyoungOn 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,SindhuTo 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
ZEKU
信息安全声明：本邮件包含信息归发件人所在组织ZEKU所有。 禁止任何人在未经授权的情况下以任何形式（包括但不限于全部或部分披露、复制或传播）使用包含的信息。若您错收了本邮件，请立即电话或邮件通知发件人，并删除本邮件及附件。
Information Security Notice: The information contained in this mail is solely property of the sender's organization ZEKU. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it.
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
<oledata.mso>
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