Hi Minyoung,
Thanks for the explanation. It makes sense to me that an AP needs to respond with an EML Operating Mode Notification frame to indicate that the AP is ready to support.
As for your first point, I am having some trouble understanding the changes that you are proposing. Could you maybe provide a modified version of the following sentences (particularly the second sentence in the paragraph below) that are currently in your doc 11-22/1204r0? The second sentence reads to me that the EML Operating Mode Notification frame sent by the AP is “as an acknowledgement” to the EML Operating Mode Notification frame transmitted by the non-AP STA. Maybe I will understand it better with the complete context?
Thanks!
When a non-AP MLD with dot11EHTEMLSROptionImplemented equal to true intends to (#12675)enable the EMLSR mode on the EMLSR links, a STA affiliated with the non-AP MLD shall transmit an EML Operating Mode Notification frame with the EMLSR Mode subfield of the EML Control field of the frame set to 1 to an AP affiliated with an AP MLD with dot11EHTEMLSROptionImplemented equal to true. An AP affiliated with the AP MLD that received the EML Operating Mode Notification frame from the STA affiliated with the non-AP MLD should transmit an EML Operating Mode Notification frame (#11456)with the EML Control field set to the same value as the EML Control field in the received EML Operation Mode Notification frame to one of the STAs affiliated with the non-AP MLD within the timeout interval indicated in the Transition Timeout subfield in the EML Capabilities subfield of the Basic Multi-Link element starting at the end of the PPDU transmitted by the AP affiliated with the AP MLD as an acknowledgement to the EML Operating Mode Notification frame transmitted by the STA affiliated with the non-AP MLD. After the successful transmission of the EML Operating Mode Notification frame on one of the EMLSR links by the STA affiliated with the non-AP MLD, the non-AP MLD shall operate in the EMLSR mode and the STAs on the other links of the EMLSR links shall transition to active mode after the transition delay indicated in the Transition Timeout subfield in the EML Capabilities subfield of the Basic Multi-Link element (#13414, 13412, 13811)that was received from an AP affiliated with the AP MLD or after the transition delay indicated in the Transition Timeout subfield in the EML Capabilities subfield of the Basic Multi-Link element that was sent by a STA affiliated with the non-AP MLD after receiving an EML Operating Mode Notification frame from one of the APs operating on the EMLSR links and affiliated with the AP MLD.
Best regards,
Xiaofei Clement Wang
Principal Engineer | InterDigital
T: (631) 622.4028
E: Xiaofei.wang@xxxxxxxxxxxxxxxx
From: Minyoung Park <mpark.ieee@xxxxxxxxx>
Sent: Friday, August 5, 2022 4:39 PM
To: Xiaofei Wang <Xiaofei.Wang@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] TGbe CR submission
Hi Xiaofei,
Thanks for the comment. The highlighted 'as an acknowledgement..." is pointing to the PPDU transmitted by the AP affiliated with the AP MLD, which is an immediate response (i.e., ack frame), as highlighted in green below.
"...starting at the end of the PPDU transmitted by the AP affiliated with the AP MLD as an acknowledgement to the EML Operating Mode Notification frame transmitted by the STA affiliated with the non-AP MLD."
Having said that, we can remove the confusion by replacing "an acknowledgement" to "an immediate acknowledgement" to make it clear that the PPDU is the immediate ack that follows the EML OMN frame sent by the non-AP MLD and not confused with the another EML OMN action frame sent by the AP MLD within the timeout interval. Please let me know if this would resolve the issue.
For the second comment, the reason for the AP MLD sending another EML OMN action frame with the same content is to get confirmation from the AP MLD that received the EML OMN action frame that it is ready to serve the non-AP MLD that is enabling the EMLSR mode. If we remove the EML OMN action frame transmission from the AP MLD, the AP MLD has to support the non-AP MLD that enabled the EMLSR mode right after transmitting the immediate acknowledgement and during the discussion in TGbe some members indicated that such an immediate support of EMLSR enable/disable was not possible for an AP MLD.
Please let me know if you have any questions/comments.
Best regards,
Minyoung
On Fri, Aug 5, 2022 at 11:58 AM Xiaofei Wang <Xiaofei.Wang@xxxxxxxxxxxxxxxx> wrote:
Hi Minyoung,
Thanks for the explanation. I think part of the confusion is caused by the second sentence as indicated below in red, it states that the EML Operating Mode Notification frame from the AP is transmitted “as an acknowledgement to the EML Operating Mode Notification frame” received from the non-AP STA. I think this use of language can easily cause confusion and we may want to revise that language.
“An AP affiliated with the AP MLD that received the EML Operating Mode Notification frame from the STA affiliated with the non-AP MLD should transmit an EML Operating Mode Notification frame (#11456)with the EML Control field set to the same value as the EML Control field in the received EML Operation Mode Notification frame to one of the STAs affiliated with the non-AP MLD within the timeout interval indicated in the Transition Timeout subfield in the EML Capabilities subfield of the Basic Multi-Link element starting at the end of the PPDU transmitted by the AP affiliated with the AP MLD as an acknowledgement to the EML Operating Mode Notification frame transmitted by the STA affiliated with the non-AP MLD.”
Also, if a non-AP STA will change operating mode after receiving an ACK to its transmitted EML Operating Mode notification frame anyway (without waiting for the EML Operating Mode Notification frame from the AP MLD), why does the AP need to send another EML Operating mode notification frame with exactly the same setting? Maybe we can delete this sentence all together?
Best regards,
Xiaofei Clement Wang
Principal Engineer | InterDigital
T: (631) 622.4028
E: Xiaofei.wang@xxxxxxxxxxxxxxxx
From: Minyoung Park <mpark.ieee@xxxxxxxxx>
Sent: Friday, August 5, 2022 1:13 PM
To: Xiaofei Wang <Xiaofei.Wang@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] TGbe CR submission
Hi Xiaofei,
Thanks for the comment.
The EML OMN (operating mode notification) frame is an action frame that requires an immediate acknowledgement (i.e. ack frame as an immediate response). The successful transmission of an EML OMN frame is confirmed with an immediate acknowledgement that follows the EML OMN frame.
The 'should' highlighted applies to another EML OMN action frame that 'should' be transmitted from the AP MLD to the non-AP MLD as a response to the received EML OMN frame before the timeout timer expires.
Basically the frame exchange sequence will look as follows:
EML OMN frame (STA to AP) |SIFS| Ack (AP to STA) ...... EML OMN frame (AP to STA)|SIFS| Ack (STA to AP)...............[timeout timer expires here]
Please let me know if you have any questions.
Best regards,
Minyoung
On Fri, Aug 5, 2022 at 7:58 AM Xiaofei Wang <Xiaofei.Wang@xxxxxxxxxxxxxxxx> wrote:
Hi Minyoung,
I have some concerns on the CR for CID 11582 and 10130. As you indicated, a successful transmission is defined in the baseline as “successful transmission: A transmission and the reception of its expected immediate response or a
transmission for which no immediate response is expected.”
However, it does not really apply here.
The current language is “An AP affiliated with the AP MLD that received the EML Operating Mode Notification frame from the STA affiliated with the non-AP MLD should transmit an EML Operating Mode Notification frame (#11456)with the EML Control field set to the same value as the EML Control field in the received EML Operation Mode Notification frame to one of the STAs affiliated with the non-AP MLD within the timeout interval indicated in the Transition Timeout subfield in the EML Capabilities subfield of the Basic Multi-Link element starting at the end of the PPDU transmitted by the AP affiliated with the AP MLD as an acknowledgement to the EML Operating Mode Notification frame transmitted by the STA affiliated with the non-AP MLD.”
Since an AP “Should” transmit a response, it is not clear whether a response can be expected. In addition, since a response may arrive “within the timeout interval indicated in the Transition Timeout subfield in the EML Capabilities subfield of the Basic Multi-Link element starting at the end of the PPDU transmitted by the AP”, can such a response be considered as “immediate response” as stated in the definition of “successful transmission”? For many readers, “immediate response” is a response that will be expected within a SIFS time after the end of the PPDU, and not a response that “may” arrive within a specified timeout interval.
I think it is better to clearly state what is considered as a successful transmission of the EML Operating Mode Notification frame.
Also, the phrase “transmitted by the AP affiliated with the AP MLD” highlighted in yellow above is a bit confusing to me, shouldn’t it be “transmitted by the non-AP STA affiliated with the non-AP MLD”, since it is a time reference for the timeout interval? Otherwise, it is not clear to which PPDU that the AP transmits this is referring.
Best regards,
Xiaofei Clement Wang
Principal Engineer | InterDigital
T: (631) 622.4028
E: Xiaofei.wang@xxxxxxxxxxxxxxxx
From: Minyoung Park <mpark.ieee@xxxxxxxxx>
Sent: Thursday, August 4, 2022 8:06 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] TGbe CR submission
Hi Alfred,
I've uploaded doc 11-22/1204r0 (now 36 CIDs) - EMLSR part 2. I've added 16 more CIDs.
All - please review and let me know if you have any comments.
Thanks,
Minyoung
On Tue, Jul 26, 2022 at 5:29 PM Minyoung Park <mpark.ieee@xxxxxxxxx> wrote:
Hi Alfred,
Please add 11-22/1204r0 (20 CIDs) to the MAC queue.
Thanks,
Minyoung
On Tue, Jul 26, 2022 at 3:38 PM Huang, Po-kai <po-kai.huang@xxxxxxxxx> wrote:
Hi Alfred,
Please 11-22/1054r0 (46 CIDs) to the MAC queue.
Best,
Po-Kai
From: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Sent: Sunday, July 24, 2022 4:14 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] TGbe CR submission
Hi Alfred,
Please add 11-22/1174r0 (7 CIDs) to the MAC queue.
Best,
Po-Kai
From: Minyoung Park <mpark.ieee@xxxxxxxxx>
Sent: Friday, July 22, 2022 5:52 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] TGbe CR submission
Hi Alfred,
Please add 11-22/1181r0 to the MAC queue (will be ready to review on 1st week of August). The CR doc resolves 31 comments.
Thanks,
Minyoung
On Fri, Jul 22, 2022 at 4:39 PM Yanjun Sun <yanjuns@xxxxxxxxxxxxxxxx> wrote:
Hi Alfred,
Could you help add 22/1177r0 (CR on 35.2.2, 15 CIDs) to the join queue? I’ll upload the document soon.
Thanks
Yanjun
From: Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>
Sent: Thursday, July 21, 2022 6:59 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] TGbe CR submission
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Alfred,
Could you please help to add CR document 22/1165r0 resolving comments related to Annex-B to the Joint queue? The document can be found at: https://mentor.ieee.org/802.11/dcn/22/11-22-1165-00-00be-lb266-cr-document-resolving-comments-related-to-annex-b.docx
Thanks.
Best Regards,
Rajat.
From: Yanyi Ding <yanyi.ding@xxxxxxxxxxxxxxxx>
Sent: Friday, 22 July 2022 9:54 am
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] TGbe CR submission
Hi Alfred,
Could you please add the following CR to the joint queue? Thanks.
13-Jul-2022 ET
2022
1120
0
TGbe
LB266 CR for CIDs of 4.3.16a
Yanyi Ding (Panasonic)
19-Jul-2022 22:10:34 ET
Best regards,
Yanyi
From: Yanjun Sun <yanjuns@xxxxxxxxxxxxxxxx>
Sent: Thursday, July 21, 2022 1:58 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] TGbe CR submission
Hi Alfred and all,
Could you help add the following CR to the joint queue?
1124
1
TGbe
LB266 CR for 9.3.1.22 MISC
I’ve revised the resolution based on inputs from Greg, Dibakar, Liwen and Ross. Based on Srini’s inputs, I’ve also added some discussion text on the context.
Thanks
Yanjun
From: 李雅璞(Yapu) <00001b0ec2563bd4-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, July 20, 2022 1:40 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] TGbe PHY CR submission
Hi, Alfred
Could you add the following document to the PHY queue?
20-Jul-2022 ET
2022
1169
0
TGbe
LB266-CR-on-CID 12138-12139-12140
Yapu Li (OPPO)
20-Jul-2022 04:28:05 ET
Thanks
Yapu
发件人: Yan(MSI) Zhang <yan.zhang_5@xxxxxxx>
发送时间: 2022年7月19日 2:55
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGBE] TGbe PHY CR submission
Hi Alfred, Siguard, Tianyu,
Can you add the following documents to the PHY queue?
18-Jul-2022 ET
2022
1163
0
TGbe
11be lb266 CR for clause 36.3.14 Packet Extension
Yan Zhang (NXP)
18-Jul-2022 ET
2022
1164
0
TGbe
11be lb266 CR for Clause 36.3.11 Mathematical description of signals
Yan Zhang (NXP)
Thanks
Yan
From: humengshi <0000179fd8c5ace5-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, July 12, 2022 5:49 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [EXT] [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe PHY ad-hoc Session -Monday PM2- Cancellation Notice
Caution: EXT Email
Hi Alfred,
Could you add the following documents to the PHY queue?
11-Jul-2022 ET
2022
1063
0
TGbe
LB266 CR for 36.3.16 Transmit Requirements
Mengshi Hu (Huawei)
12-Jul-2022 08:37:40 ET
11-Jul-2022 ET
2022
1064
0
TGbe
LB266 CR for 9.4.2.313.5 EHT PPE Thresholds Field
Mengshi Hu (Huawei)
12-Jul-2022 08:38:18 ET
11-Jul-2022 ET
2022
1076
0
TGbe
LB266 CR for 36.2.2 RU_ALLOCATION
Mengshi Hu (Huawei)
12-Jul-2022 08:38:44 ET
Best regards,
Mengshi Hu
发件人: Kanke Wu <kankew@xxxxxxxxxxxxxxxx>
发送时间: 2022年7月12日 12:48
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] TGbe PHY ad-hoc Session -Monday PM2- Cancellation Notice
Hi Alfred,
Can you add the following document to the PHY queue?
11-Jul-2022 ET
2022
1080
0
TGbe
LB266 CR on EHT PHY Introduction-1
Kanke Wu (Qualcomm)
12-Jul-2022 00:44:59 ET
Thanks,
Kanke
From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: Monday, July 11, 2022 6:48 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] TGbe PHY ad-hoc Session -Monday PM2- Cancellation Notice
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hello all,
PHY ad-hoc has finished processing the CR queue and hence Monday PHY PM2 session is cancelled.
Please let us know if you have any submissions to be added to the PHY queue.
Regards,
Alfred
--
Alfred Asterjadhi, PhD
IEEE802.11 TGbe Chair,
Qualcomm Technologies Inc.
Cell #: +1 858 263 9445
Office #: +1 858 658 5302
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
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
OPPO
本电子邮件及其附件含有OPPO公司的保密信息，仅限于邮件指明的收件人使用（包含个人及群组）。禁止任何人在未经授权的情况下以任何形式使用。如果您错收了本邮件，请立即以电子邮件通知发件人并删除本邮件及其附件。
This e-mail and its attachments contain confidential information from OPPO, which is intended only for the person or entity whose address is listed above. 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 e-mail 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
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
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