| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Hanqing, Thanks a lot for your questions, please see my response inline. Best, Jason 发件人: Hanqing Lou [mailto:Hanqing.Lou@xxxxxxxxxxxxxxxx]
Jason, I have several questions regarding your contribution. First, you mentioned “PS160 bit” in you proposed paragraph. If I understand correctly, this is not a bit in the TRS Control subfield. Instead, it is a TXVECTOR parameter. Can you confirm?
“— The RU_ALLOCATION parameter is set to the value of the RU Allocation subfield of the TRS Control subfield. The RU location is specified by the RU_ALLOCATION parameter and a
PS160 bit which is determined based on the RU allocation in the EHT MU PPDU carrying the TRS control subfield according to table 35-xx.” [Jason] The “PS160 bit” itself is not a TXVECTOR parameter. The RU_ALLOCATION is a TXVECTOR parameter, and is indicated by the RU Allocation subfield and a PS160 bit which is determined by the table. I can modify
the text to align with the Trigger case: — The RU_ALLOCATION parameter is set to the value
indicated by the RU Allocation subfield of the TRS Control subfield and a PS160 bit which is determined based on the RU allocation in the EHT MU PPDU carrying the TRS control subfield according
to table 35-x. Second, in the proposed new table (Table 35-xx), the second column is “The location of the 160MHz channel with more data tones of the RU/MRU that carries the frame with the TRS control subfield”. If 4x996 RU is used to carry TRS Control
subfield, how do we determine PS160? [Jason] The 4x996 RU case is excluded, because if the data frame is in a 4x996 RU, then it’s a SU transmission, it is natural to set the ACK Policy to Normal ACK/Implicit BAR to solicit the acknowledgement. I
added a sentence in the end of 35.5.2.2.4: An AP shall not send an EHT MU PPDU with a 4×996-tone
RU that carries a TRS Control subfield. Third, in the proposed new table (Table 35-xx), why do we set PS160=0 when “The location” indicates Low 160MHz; while still set PS160=0 when “The location” indicates High 160MHz as shown in the green highlighted rows. [Jason] This is because 2X996+484 is different from 3×996 or 3×996+484 regarding the PS160 and the location of the 160MHz with more data tones. In the 2X996+484 case, when the 2X996+484 MRU occupies more data tones in the lower 160MHz, the PS160 is 0; In the 3×996 or 3×996+484 case, when the 3×996 or 3×996+484 MRU occupies more data tones in the lower
160MHz, the PS160 is 1; You can check Table 9-53a and Figure 36-14~16 to figure out the relationship. E.g., when the 2X996+484 MRU occupies more data tones in the lower 160MHz, then it could be 2X996+484 MRU 1~6 according to Table 36-14, and the PS160 bit
for 2X996+484 MRU 1~6 is 0 according to Table 9-53a. Similar for 3×996 or 3×996+484. The rationale is: the BA (or majority tones of the BA) is transmitted in the same 160MHz as the data frame (or majority tones of the data).
Table 35-xx – PS160 for RU Allocation in EHT TRS
Best regards, Hanqing From: Chen, Xiaogang C <xiaogang.c.chen@xxxxxxxxx>
Thanks Jason. The confusion was we already have a table 35-1 in D1.4. You may want to change the caption of the new table. In the new table, instead of saying “…the 160MHz channel with more data tones…” it’s much clear to directly use the MRU index. I remember people also asked why not simply use reserved bit to make the 9 bits RU allocation table, but create implicit indication which is much more complicated? BRs, Xiaogang. From: Guoyuchen (Jason Yuchen Guo) <000018696e95f088-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi Xiaogang, There is a newly added table at the end of this subclause which clarifies how the bit PS160 is determined. Best, Jason 发件人: Chen, Xiaogang C [mailto:xiaogang.c.chen@xxxxxxxxx]
Hi Jason Another clarification question. If AP send an RU/MRU > 996x2, how the bit PS160 is conveyed? It’s not clear based on the text below. Table 35-1 is a typo?
— The RU_ALLOCATION parameter is set to the value of the RU Allocation subfield of the TRS Control subfield.
The RU location is specified by the RU_ALLOCATION parameter and a PS160 bit which is determined based on the RU allocation in the EHT MU PPDU carrying the TRS control subfield
according to table 35-1. BRs, Xiaogang. From: Guoyuchen (Jason Yuchen Guo) <000018696e95f088-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi all, An update of the CR document 202 regarding EHT MU operation and EHT TRS is uploaded. https://mentor.ieee.org/802.11/dcn/22/11-22-0202-04-00be-cr-for-eht-ul-mu-operation.docx Please let me know if you have any further comments and suggestions. Best, Jason 发件人: Guoyuchen (Jason Yuchen Guo)
Hi all, This email thread is initiated to discuss the CR document 202 regarding EHT MU operation and EHT TRS. https://mentor.ieee.org/802.11/dcn/22/11-22-0202-02-00be-cr-for-eht-ul-mu-operation.docx Please let me know your comments and suggestions. Best, Jason 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 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 | ||||||||||||||||||||||||