Hi Vishnu,
Thanks for the contribution. I have some questions regarding the CIDs [10008][11594][13589].
I was trying to understand the motivation of the group link and how it works with the existing scheme. I assume you are saying that when a group link is notified,
the AP MLD still schedules the group addressed frames on all the links as in the current spec, but the non-AP MLD is only required to receive the group frames on the group link? Please correct me if my understanding is wrong.
My question is - first, the AP MLD knows exactly whether the non-AP MLD is receiving group frames on one link or not. And the AP MLD’s behaviors are not changed with
a group link since it still schedules group frames on all the enabled links. So there is no need for non-AP MLD to tell AP MLD beforehand which link will be used to receive group frames.
Second, since currently the group addressed frames are buffered on all the links, if the non-AP MLD finds a better link to receive group frames based on different
situations, it is not helpful for it to use a predetermined group link. For example, when the non-AP MLD in EMLSR mode is operating on one link right before the DTIM beacon on this link, there is no need for it to switch to other links. Or like cases where
other links have better link condition than the group link. So why does the non-AP MLD need a group link to limit its flexibility which could possibly reduce its efficiency?
Best regards,
Yousi
发件人: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
发送时间: 2022年9月2日
11:03
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Hi Frank,
Thank you for the question. In my opinion, it will not cause a failure of group addressed frame delivery or reception. Let us take an example. Say the previous
group link was link 1 and the new indicated group link is link 2, and say there is some delay at AP MLD in processing the group link change. The worst that can happen due to the processing delay is that an AP MLD will initiate a frame exchange sequence on
link 1 that overlaps with the beacon transmission time on link 2. Note that the spec text allows a non-AP MLD to not respond to the initial control frame in this case:
- The initial Control frame shall be an MU-RTS Trigger frame or a BSRP Trigger frame. A STA affiliated with a non-AP MLD that is in the listening operation and that
receives an MU-RTS Trigger Frame or BSRP Trigger frame addressed to it shall respond as defined in 35.5.2.2 (Rules for soliciting UL MU frames), except when the frame exchanges initiated by the initial Control frame on one of the EMLSR links overlaps with
group addressed frame transmissions on the other EMLSR link where the non-AP STA intends to receive the group addressed frames
[13587]in which case the non-AP STA may use the other EMLSR link to receive the group addressed frames.
The number of spatial streams for the response to the BSRP Trigger frame shall be limited to one.
Thus this may cause a failure of the frame exchange initiated by the AP MLD on link 1 (since non-AP MLD may not respond to the initial control frame), but it will
not cause failure of reception of group addressed frames. Also given that these group addressed frames are transmitted at most once every TBTT, the likelihood of a processing delay at the AP (which is much smaller than a TBTT) to cause this issue is very unlikely.
Added to that, the group link is not expected to be changed very often. So in my opinion it is not a significant issue to warrant the need for a response frame. Please let me know if I missed anything.
Regards,
Vishnu
From: Frank Hsu (徐建芳)
<frank.hsu@xxxxxxxxxxxx>
Sent: Thursday, September 1, 2022 9:24 PM
To: Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>;
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Hi, Vishnu,
Thanks for the feedback.
Under the condition that group addressed frames are buffered in AP MLD, when AP MLD needs some processing time to update the group link indication (either
link change or termination), and during that period, the protection mechanism may still use previous information to proceed. Do you expect it will cause the group addressed frame delivery failure?
BRs,
Frank
From: Vishnu Ratnam
<vishnu.r@xxxxxxxxxxx>
Sent: Friday, September 2, 2022 1:24 AM
To: Frank Hsu (徐建芳) <frank.hsu@xxxxxxxxxxxx>;
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Hi Frank,
As per the current CR document, the group link indication has no impact on the buffering of group addressed frames at the AP. The AP
still buffers group addressed frames on all the links (as in baseline spec). The indication of group link is to help minimize the number of links on which the AP needs to provide the “protection mechanism” of receiving group-addressed frames, by terminating
frame exchanges with an EMLSR or NSTR non-AP MLD.
If I am not wrong, there was significant discussion in last round CC36 on the topic of whether group addressed frames need to be buffered
on all links (in the context of assigning sequence numbers) and I think the consensus was yes they should.
Regards,
Vishnu
From: Frank Hsu
(徐建芳) <frank.hsu@xxxxxxxxxxxx>
Sent: Thursday, September 1, 2022 1:42 AM
To: Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>;
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Hi, Vishnu,
Thanks for the document.
I have a comment regarding the group link indication.
You mentioned that
“this feature we don’t require a response frame from AP MLD”.
I am considering a scenario where AP MLD buffers group addressed frames for a non-AP MLD based on the previous group link indication, say on link 1,
but before transmission, the AP MLD receives new group link indication which has different link indication from the previous one, say link 2. Depending on the design, AP MLD may not transmit those frames on link 2.
It looks in this scenario, AP MLD needs to notify the non-AP MLD when the latest group link indication is going to be executed by the AP MLD.
That means, a response from AP MLD is necessary, especially when the group link indication is changed.
How do you think?
BRs,
Frank
From: Vishnu Ratnam
<vishnu.r@xxxxxxxxxxx>
Sent: Thursday, September 1, 2022 2:34 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Dear all,
Thank you for discussion during the meeting on CR doc 1335 (Group addressed frame reception in EMLSR/NSTR). I summarize below the comments
discussed on the call, and I look forward to additional feedback which was not discussed during the meeting:
-
CIDs 10434, 12813: The text
“individually addressed frame exchanges“ may be inaccurate. The text “affiliated (non-MLO) upper MAC sublayer functions of the AP MLD (5.1.5.1 General ) served for
the EMLSR links” is controversial. Recommended to delete: “non-AP
MLD with dot11EHTEMLSROptionImplemented equal to true that is associated with an AP MLD with dot11EHTEMLSROptionImplemented equal to true” to
simplify text.
-
CID 13587:
Change the bullet to ensure that it doesn’t preclude listening operation on other EMLSR links when receiving group-addressed frames on one link, i.e.,
the return to listening operation is only for the STA that was receiving group-addressed frames. Also suggested to add that the return to listening is after the EMLSR transition delay.
Kindly let me know if I missed any of the comments on call. I would also appreciate if you can share feedback on CIDs which were not
discussed during the meeting: [10039][10863][12726][12728][12892][13588][13813]
and [10008][11594][13589].
Regards,
Vishnu
From: Vishnu Vardhan
Ratnam <vishnu.r@xxxxxxxxxxx>
Sent: Thursday, August 18, 2022 2:28 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Hi Xiangxin,
Please find my responses inline.
Regards,
Vishnu
From:
顾祥新 (Xiangxin Gu) <Xiangxin.Gu@xxxxxxxxxx>
Sent: Tuesday, August 16, 2022 9:14 PM
To: Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>;
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Hi Vishnu,
Thanks for your response. I make inline reply.
BR,
Xiangxin Gu
Communication Standards Devision
From: Vishnu Ratnam
<vishnu.r@xxxxxxxxxxx>
Sent: Wednesday, August 17, 2022 12:19 AM
To: 顾祥新 (Xiangxin Gu) <Xiangxin.Gu@xxxxxxxxxx>;
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Hi Xiangxin,
Thank you for your comments and initiating the discussion.
-
I personally don’t have a very strong opinion about this, i.e., is a capability indication by the AP MLD necessary or not. Others had suggested that a capability
indication should be used during offline discussions. Without a capability indication, it may be unclear what the AP operation will be if an indication of group-link is provided by an EMLSR non-AP MLD, i.e., will it take action based on it or not.
[// Xiangxin Gu] If this mechanism is incorporated, there is no reason for
an AP MLD not to support this because it make the AP MLD easier to operating with EMLSR/EMLMR mode. So I don’t
understand why the capability indication is needed.
[VR] Since there are conflicting opinions on this, let us discuss this during the call
to see what the group generally prefers. I would be happy to also collect other opinions of this as a response here to see which approach is more preferred.
-
Beacon frames are also included in the list of group addressed frames. So even if no services are running over group-addressed data frames, the proposed
mechanism is still required for protecting beacon frames. Can you elaborate further what case you are referring to and what is your suggestion?
[// Xiangxin Gu] Agree.
Further, an indication on whether there is services over group addressed frames
other than Beacon frames at non-AP MLD side is suggested. Because it is gainful that the duration of transmission of these frames doesn’t
need to be kept away from EML frame exchanges if no such services at non-AP MLD side. These frames occupy much more time than Beacon frame.
Moreover, for EMLMR, in case some RF chains are kept at the STAs on other
links during the EML frame exchange, there is no need for EML frame exchanges to be away from the duration of transmission of group addressed frames on any links. For example, a multi-radio non-AP MLD with 3 affiliated STA1 and STA 2 and STA 3 setups link
1 and 2 and link 3 respectively with AP 1 and AP2 and AP3 affiliated with an AP MLD. All STAs support 2 SS. The non-AP MLD supports EMLMR mode, and has enabled EMLMR mode with 4 SS on link 1 and link 2 and link 3. The EMLMR mode does not use all RF chains
of the non-AP MLD.
[VR] Regarding the indication of group addressed frame services, I see your point, But
I think the issue may be that group addressed management frames are also buffered and transmitted after the DTIM beacon, and they can be meant for all non-AP MLDs. So even if a non-AP MLD is not subscribed to a group addressed service, it may want to decode
the group addressed frames. Note that as of now there is no indication in TIM regarding whether the buffered group-addressed frames are data frames or management frames (there are some CIDs on that topic), so the non-AP MLD may not know if it can stop decoding.
Since many things regarding EMLMR are yet unclear, I removed the clause corresponding
to EMLMR from the document. There are other CIDs for EMLMR section that can be used to extend this procedure for EMLMR. I encourage you to bring this idea up during the resolution of those CIDs.
-
This point was also in debate in offline discussions, and two people suggested that the indication should be in a new EHT action frame. One of the reason
is also that the indication of group link can be provided after switch to EMLSR mode, at any time. So reusing EML Operating Mode Notification frame might in fact reduce flexibility that the indication can only be provided when the switch to EMLSR mode happens.
The EML Operating Mode Notification frame also has a response frame, while for this feature we don’t require a response frame from AP MLD. We can also have an offline discussion on this if you want a more detailed discussion.
[// Xiangxin Gu] Yes, we have to make decision for the tradeoff. Actually
I doubt such flexibility make sense in practice.
[VR] Since there are conflicting opinions on this, let us discuss this during the call
to see what the group generally prefers, I would be happy to also collect other opinions of this as a response here to preemptively see which option is more preferred.
Regards,
Vishnu
From:
顾祥新 (Xiangxin Gu) <Xiangxin.Gu@xxxxxxxxxx>
Sent: Tuesday, August 16, 2022 12:41 AM
To: Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>;
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Hi Vishnu,
Thanks for the contribution document 22/1335r0, I have concerns:
-
With this mechanism, the AP MLD get easier to operating with EMLSR/EMLMR mode. So it is unreasonable to have a capability item on this.
-
The solution doesn’t cover
the case that there is no services running over group addressed frames at non-AP MLD side.
-
It’s better to put the information
in EML Operating Notification frame, which consumes less steps and less signal overhead. I don’t think it’s
a good idea to utilize an inefficient way just because we want to cover NSTR case. Actually no CID is related to NSTR. We can have a separate discussion on NSTR.
BR,
Xiangxin Gu
Communication Standards Devision
From: Vishnu Ratnam
<vishnu.r@xxxxxxxxxxx>
Sent: Friday, August 12, 2022 11:18 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Hi Alfred,
Could you kindly add the following document to the MAC queue. It resolves 13 CIDs.
|
12-Aug-2022 ET |
2022 |
1335 |
0 |
TGbe |
CR for CIDs related to Group-addressed frame Reception in EMLSR/NSTR |
Vishnu Ratnam (Samsung) |
12-Aug-2022 11:13:05 ET |
In addition, I have uploaded the 1201r1 which is a PDT (in place of 1201r0 which was a ppt). As discussed, could you kindly
move that document to the MAC Comment Resolution queue from the contribution queue? It resolves 1 CID.
|
12-Aug-2022 ET |
2022 |
1201 |
1 |
TGbe |
ML traffic indication using A-control |
Vishnu Ratnam (Samsung) |
12-Aug-2022 11:04:33 ET |
Thanking you,
Vishnu
From: Edward Au
<edward.ks.au@xxxxxxxxx>
Sent: Thursday, August 11, 2022 6:52 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
|
Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
|
Dear Alfred and all,
Revision 16 of the comment spreadsheet is posted:
This version updated the status of selected CIDs after the motions on Wednesday, together with a few TTT assignments and PoC reassignment.
Regards,
Edward
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
This email (including its attachments) is intended only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from disclosure. Unauthorized use, dissemination, distribution or copying of this email or the information herein or taking any action in reliance on the contents of this email or the information
herein, by anyone other than the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, is strictly prohibited. If you are not the intended recipient, please do not read, copy, use or disclose any part
of this e-mail to others. Please notify the sender immediately and permanently delete this e-mail and any attachments if you received it in error. Internet communications cannot be guaranteed to be timely, secure, error-free or virus-free. The sender does
not accept liability for any errors or omissions.
本邮件及其附件具有保密性质，受法律保护不得泄露，仅发送给本邮件所指特定收件人。严禁非经授权使用、宣传、发布或复制本邮件或其内容。若非该特定收件人，请勿阅读、复制、
使用或披露本邮件的任何内容。若误收本邮件，请从系统中永久性删除本邮件及所有附件，并以回复邮件的方式即刻告知发件人。无法保证互联网通信及时、安全、无误或防毒。发件人对任何错漏均不承担责任。
This email (including its attachments) is intended only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from disclosure. Unauthorized use, dissemination, distribution or copying of this email or the information herein or taking any action in reliance on the contents of this email or the information
herein, by anyone other than the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, is strictly prohibited. If you are not the intended recipient, please do not read, copy, use or disclose any part
of this e-mail to others. Please notify the sender immediately and permanently delete this e-mail and any attachments if you received it in error. Internet communications cannot be guaranteed to be timely, secure, error-free or virus-free. The sender does
not accept liability for any errors or omissions.
本邮件及其附件具有保密性质，受法律保护不得泄露，仅发送给本邮件所指特定收件人。严禁非经授权使用、宣传、发布或复制本邮件或其内容。若非该特定收件人，请勿阅读、复制、
使用或披露本邮件的任何内容。若误收本邮件，请从系统中永久性删除本邮件及所有附件，并以回复邮件的方式即刻告知发件人。无法保证互联网通信及时、安全、无误或防毒。发件人对任何错漏均不承担责任。
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