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

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

Download

 

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

Download

 

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

Download

 

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

Download, Revise

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

Download, Revise

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

Download, Revise

 

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

Download

 

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

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