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

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

Hi Rojan,

Thanks for your comments/suggestions.

The TID-to-Link mapping is in R1 (see  546r5, page 41, the last row).

Please see my responses inline below .

Regards,
Minyoung


On Mon, Apr 26, 2021 at 1:25 AM Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx> wrote:

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.

[MP] Good suggestion. I'll add a few sentences on this in the next revision. 

 

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.

[MP] We could. I guess the question is whether we want to save one element ID extension and design as a new Type of ML element (the 2 octet ML Control field seems to be redundant) or use one element ID extension and do a straightforward design.      

 

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.

[MP] Good suggestion. AID11 also works. I probably thought AID needs 13 bits. 

 

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.

[MP] A bit in the PVM in the TIM indicates buffered BUs for a non-AP MLD, not a STA, so I don't think this will work. 

 

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