| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Sherief, Thanks for your further response. Please see my further
inline response
below. Regards, Arik From: Sherief Helwa <00002dded7ae4daf-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi Arik, Thanks for you detailed explanation. Please see my response
inline. Regards, Sherief From: Arik Klein <arik.klein@xxxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. 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>
Thanks Arik for preparing the doc. More comments from me follows… 7799/7800/7801/7802:
[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 “ [SH] Ok makes sense. You want to split because for discovery and negotiation the recipient of the frame is different. To have more concise text, can you rephrase to make it one description
and in the same description mention that this MAPC Profile can be included in a MAPC Discovery or MPAC Negotiation frame? I think that will capture your idea without duplicating the field description because the field description is the same. [AK] First, there is a difference in the description between MAPC discovery and MAPC negotiation: in the MAPC discovery case the max value refers to any
AP that supports Co-BF and in case of the MAPC negotiation the Max value corresponds to the recipient AP of the transmitted frame (i.e. the AP with which the AP request or response to perform the MAPC operation).
[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.
[SH] Since they are equivalent can we stick to the original field encoding? [AK] There is not difference in the encoding since the encoding (i.e. the value that is kept in the Number of Supported Sounding Reports field) is always
reduced by 1 from the value of the maximum number of OBSS Sounding Reports. For instance: if the maximum number of OBSS Sounding Reports=4, the value kept in the Number of Supported Sounding Reports field is 3. 7803/67804:
[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). [SH] Let’s check this one with Giovanni Regards, Sherief From: Giovanni Chisci <00002b657bbbbed7-dmarc-request@xxxxxxxxxxxxxxxxx>
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>
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 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 |