Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Thanks that is quite clear now!
Ben
From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Sent: Wednesday, August 31, 2022 3:28 PM To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx> Subject: Re: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted Hi Ben,
The intention is to apply the same delay (EMLSR transition delay) to both cases. Does the following answer your question?
Thanks, Gaurang
From: Benjamin Rolfe <ben@xxxxxxxxxxxxxx>
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi All, Potentially this question has already been covered, but in the response [13587], "following the reception of an indication from the AP MLD that there is no more boffered non-GCR-SP..." in the first part we define (precisely?) what "following" means (duration of EMLSR transition delay). Do you mean to apply the same duration to the second condition, or is "following" meaning some other (hopefully bounded) delay value? Thanks Ben
From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Hi Vishnu,
Pls see the suggested change for CID 13587 as I mentioned during the call.
Also, there regarding the term ‘individually addressed’ in the resolution for CID 10434, I suggest making the following change to make the intention clear.
I believe you also made live changes during the call for CID 10434. Could you please upload the version with those changes?
Thanks, Gaurang
From: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. 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>
Hi Xiangxin,
Please find my responses inline.
Regards, Vishnu
From:
顾祥新 (Xiangxin Gu) <Xiangxin.Gu@xxxxxxxxxx>
Hi Vishnu,
Thanks for your response. I make inline reply.
From: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
Hi Xiangxin,
Thank you for your comments and initiating the discussion.
[// 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.
[// 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.
[// 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>
Hi Vishnu,
Thanks for the contribution document 22/1335r0, I have concerns:
From: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
Hi Alfred,
Could you kindly add the following document to the MAC queue. It resolves 13 CIDs.
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.
Thanking you, Vishnu
From: Edward Au <edward.ks.au@xxxxxxxxx>
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, 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 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 |