Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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.
[// 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.
[// Xiangxin Gu] Yes, we have to make decision for the tradeoff. Actually I doubt such flexibility make sense in practice. Regards, Vishnu From:
顾祥新 (Xiangxin Gu) <Xiangxin.Gu@xxxxxxxxxx>
Hi Vishnu, Thanks for the contribution document 22/1335r0, I have concerns:
1)
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.
2)
The solution doesn’t cover the case that there is no services running over group addressed frames at non-AP MLD side.
3)
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. 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.
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 |