| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Folks, I’ve updated
21/1333r4 based on inputs from last week’s call and the changes are tagged with R4 in comments:
As the 5 CIDs related to the two reserved subfields (B56-B62 and B63) seem to need more discussion, I’ve moved them to the end of the CID list for more focused discussion and highlighted the related text by R4. Thanks, Yanjun From: HUANG LEI <000013c45bbec18b-dmarc-request@xxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Yanjun, Thanks. Attached please find my additional comments. Best regards, Lei From: Yanjun Sun <yanjuns@xxxxxxxxxxxxxxxx>
Hi folks, Fyi, I’ve made editorial updates on the description of the reserved bits in
21/1333r2, tagged by R2 in comments on pages 18, 19, 21, so that the text is aligned with the frame format. Please let me know if you have any additional comments/suggestions on this CR. Thanks, Yanjun From: Yanjun Sun <yanjuns@xxxxxxxxxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Rojan, Thank you for sharing your thoughts. Based on Greg’s inputs below that a Reserved field has default value of 0 according to the baseline 11me spec, B56-B62 cannot be simply put into a subfield named Reserved. This is because they need to be set to 1s, consistent with HE AP’s
behavior, so that they can be redefined later for future expansion. Based on Arik and Greg’s comments, I’ve assigned a new name to these bits. “Unused Reserved” and “UL Reserved” were what I considered, and new suggestions on the name will be appreciated. Thanks, Yanjun From: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
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 sharing; the changes look good to me in general except that the field name “unused reserved” for the reserved bits B56-B62, seems a bit odd to me. “Reserved” by definition means unused, why not simply rename as reserved? We could
even combine with B63 as Yanyi mentioned. Regards, Rojan From: Yanjun Sun <yanjuns@xxxxxxxxxxxxxxxx>
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 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
OPPO 本电子邮件及其附件含有OPPO公司的保密信息，仅限于邮件指明的收件人使用（包含个人及群组）。禁止任何人在未经授权的情况下以任何形式使用。如果您错收了本邮件，请立即以电子邮件通知发件人并删除本邮件及其附件。 This e-mail and its attachments contain confidential information from OPPO, which is intended only for the person or entity whose address is listed above. Any
use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify
the sender by phone or email immediately and delete it! 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 |