Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Ensung, Greg, Arik and all, Thank you for reviewing the CR and sharing your thoughts/suggestions. I’m aggregating the email threads and responses together as they’re related. Please see my response to your individual question/comments
inline. As the next step, I agree with the suggestions from Arik and Greg that the reserved bits B56-B62 in the EHT Common User Info field needs to be renamed. Please see the proposed changes on pages 14 and 20 tagged with “R0” in the attached
and let me know if you have any additional comments/suggestions. Thanks, Yanjun From: Eunsung Park <esung.park@xxxxxxx> WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Yanjun, Thanks for preparing the CR document. I have a question on several subfields of the EHT variant Common Info field which were changed to Reserved
subfields. In my understanding, the EHT variant Common Info field can be also used to solicit HE TB PPDU. However, some subfields are reserved now in your proposed change, for example, UL STBC subfield is reserved. In that case, how do we solicit HE TB PPDU
where UL STBC is applied by using EHT variant Common Info field? Could you please clarify this? [YS]
You brought up a good question that is worth more clarification. In R1, if a non-AP STA decodes an EHT variant Common Info field, the STA cannot
transmit an HE TB PPDU as response, based on the motioned text in 21/1233r3 and the following text in D1.1: “If the dot11EHTBaseLineFeaturesImplementedOnly is equal to true, then an EHT AP shall not transmit a Trigger frame that solicits both an HE TB PPDU
and an EHT TB PPDU” [YS] So the scenario you brought up (i.e., HE TB PPDU in response to EHT variant Common Info field)
could only occur beyond R1 and therefore it’s safe to mark MU-MIMO HE LTF, UL STBC, Doppler as reserved in R1. Best regards, Eunsung From: Greg Geonjung Ko
greg.ko@xxxxxxxxxxxxxx Also I suggest changing the subfield name of B56-B62, because 9.2.2 of the baseline spec mentions about reserved subfields as below. "Reserved fields and subfields defined in this clause are set to 0 upon transmission and are ignored upon reception" Based on the baseline text mentioned above, it may be redundant to say that the MU-MIMO EHT-LTF Mode, UL STBC, Doppler subfields are set to 0, if the draft spec already says those bits are reserved. [YS] Thank you for the helpful inputs and the suggestion looks reasonable to me. How about renaming them back to ‘Unused Reserved’ subfield and setting all of them to 1 by an R1 EHT AP?
From: Arik Klein <arik.klein@xxxxxxxxxx>
Thanks for sharing the document. I’ve attach my comments in the enclosed doc. Please review it and respond. [YS] Thank you for the suggestions. I’ve summarized the key points below so that other folks can follow all the discussions in a single email thread: You suggested to merge B56-B62 and B63 (Reserved subfield) into one subfield or to rename B56-B62.
You suggested to rename ‘Special User Info Field Present’ with ‘Special User Info Field Absent’
Regards, Arik From: Yanjun Sun [mailto:yanjuns@xxxxxxxxxxxxxxxx]
Hi folks, We’ve tried to address the comments related to Common Info field format in
21/1333. Many thanks for the co-authors, especially Lei, for the helpful early inputs. Please let me know if you have any comments/suggestions. Thanks, Yanjun 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 |
Attachment:
11-21-1333-00-00be-cr-trigger-frame-common-info-field-format-update1.docx
Description: 11-21-1333-00-00be-cr-trigger-frame-common-info-field-format-update1.docx