| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Hanqing, Thanks for the follow-up questions, please check my responses inline. Best, Jason 发件人: Hanqing Lou [mailto:Hanqing.Lou@xxxxxxxxxxxxxxxx]
Jason, Thanks a lot for the detailed explanation. Regarding PS160 bit, I think we might need some internal parameter defined since MAC does not know PS160 (With TF case, MAC knows that from TF explicitly, but here MAC has to get the information from PHY based on the table). [Jason] Agree that some internal processing is needed at the MAC, but it’s simple according to the table. For 4x996 RU, could it be MU-MIMO? [Jason] For 4x996 RU, MU-MIMO is also excluded per Liwen’s suggestion. I kind of agree with Xiaogang’s comment, using RU/MRU index to implicitly indicate PS160 may be easier. Or using the reserved bit to explicitly indicate PS160 may give us more flexibility to allocate resources. With explicit signaling,
we don’t have to restrict us to allocate the UL response in the same 160MHz channel. [Jason] I have clarified with Xiaogang that using the RU/MRU index may be more complicated,
because the 2nd column of this table is referring to
the location of the 160MHz channel with more data tones of the RU/MRU that carries the frame with the TRS control sub-field (which 160 carries more data tones of the Data frame), it’s
not referring to an RU/MRU. Regarding using the reserved bit, it was part of the discussions before, many people think that the implicit way also works, and there is only one reserved bit left,
we’d better reserve it for future use. Best regards, Hanqing From: Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>
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 | ||||||||||||||||||||||||