Re: [STDS-802-11-TGBE] Feedback requested for CR related to 35.3.10.4 TI

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

On Mon, Apr 26, 2021 at 2:38 AM 顾祥新 (Xiangxin Gu) <Xiangxin.Gu@xxxxxxxxxx> wrote:

Hi Minyoung,

Thanks for the contribution.

Additional comments is added in the attached file.

BR,

Xiangxin

Unisoc Technologies Co., Ltd.

+86 21 20360600 3324

From: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Sent: Monday, April 26, 2021 4:25 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Feedback requested for CR related to 35.3.10.4 TIM Indication

Dear Minyoung,

Thank you preparing the CRs for this important topic. I was under the impression that this topic was agreed to be in R2; I also remember that Abhi had a somewhat different proposal on the same topic. Nonetheless, I have added my comment in the attached for your considerations, please take a look. I have copied some of the important ones in the email for easier discussions:

1) Fig 35-xyz1 (Example of Multi-Link Traffic element construction) : The example assumes intelligent AID Space planning by the AP MLD but no explanation is made of it. This deserves some explanation and perhaps should even be a recommended behavior for AP MLDs; if such AID planning is not used, lots of unnecessary per-link Traffic indication bitmap fields will be needed for legacy STAs/non-AP MLDs that do not require link recommendations.

2) ML Traffic element: We can consider using a new Type of ML element instead to save one element ID extension. The ML Traffic control field can be in the common Info field while the Per-link Traffic Indication List can be in the Link Info field.

3) AID offset field: Why not simplify by directly signaling the first AID11 that needs the per-lInk Traffic indication bitmaps? It will also save unnecessary per-link Traffic indication bitmaps for AIDs that do not need them (e.g. legacy STAs or non-AP MLDs with default TID mapping that may occur in the beginning portion of Octet N) and make the computation simpler for non-AP MLDs. Anyway there are 4 unused reserved bits left in the field.

4) Per-Link Traffic Indication Bitmap: The link on which the TIM element is transmitted need not be explicitly signaled in the Per-link traffic indication bitmap since the bit in the PVM in the TIM element itself can act as the implicit indication for the transmitting link (the link in which the TIM element is transmitted) if the transmitting link is recommended. For e.g., if AP MLD has 2 links (IDs: 0, 1) and the TIM element is transmitted on link 0, per-link TIB can be just 1 bit (i.e. m = 0). If the bit is set to 1, link 1 is recommended; else link 0 is implicitly recommended. We can save 1 bit per per-link TIB which can add up to savings of several octets.

Regards,

Rojan

From: Minyoung Park <mpark.ieee@xxxxxxxxx>
Sent: Saturday, April 24, 2021 6:19 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Feedback requested for CR related to 35.3.10.4 TIM Indication

Dear all,

Here is a CR doc 612r0 on 35.3.10.4 TIM Indication:

https://mentor.ieee.org/802.11/dcn/21/11-21-0612-00-00be-cc34-cr-tim-indication.docx

Please let me know if you have any questions/comments.

Thanks,

Minyoung

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