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

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