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

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

Hi Minyoung,

 

I’m not clear your intention about following rules for TPC and Link measurement. Do you mean AP MLME shall reject the TPC & Link measurement report sent by the STA?  I understand the confirm primitive responses to a received report frame, not the primitive.

 

 

 

 

An AP affiliated with an AP MLD shall set the ResultCode to REJECT in an MLME-TPCADAPT.confirm primitive in response to an MLME-TPCADAPT.request with a Peer Mac Address parameter corresponding to a STA, affiliated with a non-AP MLD, that is in PS mode. In this case, the MLME shall not construct a TPC Request frame. (#2302)

 

An AP affiliated with an AP MLD shall set the ResultCode to REJECT in an MLME- LINKMEASURE.confirm primitive in response to an MLME- LINKMEASURE.request with a Peer Mac Address parameter corresponding to a STA, affiliated with a non-AP MLD, that is in PS mode. In this case, the MLME shall not construct a Link Measurement Request frame. (#2302)

 

 

Thanks

 

Best Regards

 

Jay Yang

 

From: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Sent: 2021年4月27日 13:07
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [Suspected Marketing Mail] Re: [STDS-802-11-TGBE] Feedback requested for CR related to 35.3.10.4 TIM Indication

 

Hi Minyoung,

 

Thanks for your clarifications and also for highlighting some of my comments during the call. Despite Xiangxin’s comments on the contrary, I still believe AID11 is the right option and closer to your intentions.

 

Regarding the MLE format, I agree with you that technically both approaches will work, but since we already have the MLE Type framework, why not use it, esp. since we can save one element extension ID. I have put together how the new MLE variant would look like in the attached, the text changes are minimal; do take a look.

 

Btw, the other point that we didn’t have time to discuss during the call was regarding having some text for the recommended guidelines for AP MLD regarding the AID Space.

 

Thanks!

 

Regards,

Rojan

 

From: Minyoung Park <mpark.ieee@xxxxxxxxx>
Sent: Tuesday, April 27, 2021 5:40 AM
To: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 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

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