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

Re: [STDS-802-11-TGBN] LB291 - CR for 9.4.2.355 MAPC element



Hi Sherief,

 

Thanks for your comments.

Please see my inline response below.

 

Please let me know if you have any further comments.

 

Regards,

Arik

 

From: Sherief Helwa <00002dded7ae4daf-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: יום ו 06 מרץ 2026 01:36
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] LB291 - CR for 9.4.2.355 MAPC element

 

Thanks Arik for preparing the doc. More comments from me follows…

 

7799/7800/7801/7802:

  • Why are we calling out the description of the fields twice; once for the MAPC Discovery Req/Resp and another for MAPC Negotiation Req/Resp?

[AK] The problems with the current text (as reflected in these CIDs) are as follows: (1) The term in “The AP can store for this Co-BF pair…” is incorrect in case that the MAPC element is carried in the MAPC Discovery Request/ Response frames. There is no “pair AP for Co-BF” since at this stage no Co-BF MAPC agreement is being established. (2) The term in “The AP can store for this Co-BF pair…” is not clear to which pair you refer in case that the MAPC element is carried in the MAPC Negotiation Request/ Response frames.

My proposed solution (in 410r2) for these issues is: (1) in case of MAPC Discovery Request/ Response frames the sentence is revised to “the AP can receive and store for OBSS non-AP STAs associated with a further non-colocated AP for which the Co-BF Supported field is equal to 1 “
(2) In case of MAPC Negotiation Request/ Response frames, the sentence is revised to “the AP can receive and store for OBSS non-AP STAs associated with the recipient AP of the frame “

  • Also why did you redefine the encoding of the fields? That is not needed and will require defining the maximum that you are subtracting from.

[AK] The original sentence includes 2 different issues: description for the indication of this field and the encoding of this field. The CIDs 7799, 7801 proposed (for better readability) to split the sentence into 2 separate sentences.
Besides, the revised sentence “ The encoding of the field (i.e. the Number of Supported Sounding Reports field ) is set to the maximum number of supported OBSS Sounding reports minus 1“ is equivalent to “ The maximum number of OBSS Sounding Reports  is equal to the value of the
Number of Supported Sounding Reports field plus 1 “ so no redefinition is required here.

 

7803/67804:

  • Can you please clarify the intention of that change? I am not clear on the changes proposed.

[AK] The modification clarifies the exact case where the MAPC Scheme Request field is included in the Co-BF/Co-SR profile – when the MAPC element is carried in MAPC Negotiation Request/ Response frames (as requested by the commenter).

 

Regards,

Sherief

 

From: Giovanni Chisci <00002b657bbbbed7-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, March 5, 2026 2:08 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] LB291 - CR for 9.4.2.355 MAPC element

 

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Thanks for the document Arik.

 

Some comments here:

 

7798: keep the definitions e.g. ‘Co-RTWT profile’ in 3.2 as well (add missing ones in 3.2).

 

10474: I the sentence is removed, where is it clarified that only one profile per scheme can be added?

 

7791: not convinced that this is a wording improvement, I would refrain from changing in this way.

 

Best,

Giovanni

 

 

From: Arik Klein <0000177967a59511-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Sunday, February 22, 2026 3:09 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] LB291 - CR for 9.4.2.355 MAPC element

 

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi all / MAPC TTTs

 

I’ve uploaded 11-26/0410r0 (29 CIDs) on the mentor.

Your review and comments are highly appreciated.

 

Regards,

Arik

 


To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1


To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1


To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1


To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1