Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Wookbong, I thing you are still mixing up “STS” with “N_HELTF”? Beamformee STS capability implies how many rows in the compressed V matrix that the beamformee is able to feedback (bundled with “max N_LTF.total” value in DLMUMIMO PPDU, carried over
from 11ac). For non-OFDMA SU-MIMO or DL-MUMIMO these two have 1on1 mapping per Table21-13. In the case of DLOFDMA, pls refer to Junghoon’s example below. I believe a large portion of existing STAs do support receiving 8 HELTFs in DLOFDMA (even if SU-MIMO)—due to the quoted text below. However here the discussion is purely an interpretation the text (that Yan’s CR is addressing), not perceptions
of what AP or STA should implement. Thanks, Hongyuan From: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx> Hi Hongyuan and Yan, What you quote is fine. “In an HE MU PPDU with more than one RU,
NHE-LTF, may take a value 1, 2, 4, 6 or 8 that is
greater than or equal to the maximum value of the initial number of HE-LTF symbols for each RU, where the initial number of HE-LTF symbols is calculated as a function of NSTS,r,total.” But I believe when AP select Nsts for each RU, it should consider capabilities of each users as in MU-MIMO. And I believe the capabilities should be same as in Beamformee STS. It is weird that a non-AP STA can process 8 LTFs if all of RUs are SU-MIMO and can’t process 8 LTFs if some of RUs are MU-MIMO.
Best regards, Wook Bong Lee From: Hongyuan Zhang [mailto:hongyuan.zhang@xxxxxxx]
Hi Wookbong, There is nothing wrong with the text you quote, which all talks about number of spatial streams NSTS in different cases. However I am not sure how it is related to our discussion, because here the issue is number of HE-LTFs. In the context
of DLOFDMA, these two numbers could be different per current spec, pls refer to below text: “In an HE MU PPDU with more than one RU,
NHE-LTF, may take a value 1, 2, 4, 6 or 8 that is
greater than or equal to the maximum value of the initial number of HE-LTF symbols for each RU, where the initial number of HE-LTF symbols is calculated as a function of NSTS,r,total.” Hongyuan From: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx>
On Behalf Of Wook Bong Lee Hi Sigurd, Hongyuan, Junghoon and Yan, I agree with Sigurd. Please see following text in spec. A non-AP HE STA shall support the following features:
— Reception of an HE MU PPDU consisting of a single RU spanning the entire PPDU bandwidth and utilizing MU-MIMO (DL MU-MIMO). The maximum number
of spatial streams per user the non- AP STA can receive in the DL MU-MIMO transmission shall be equal to the minimum of 4 and the maximum number of spatial streams supported for reception of HE SU PPDUs.
The non-AP STA shall be able to receive its intended spatial streams in a DL MU-MIMO transmission with a total number of spatial streams across all users of at least 4.
— Responding with the requested beamforming feedback in an HE sounding procedure with the maximum number of space-time streams in the HE sounding NDP that the
non-AP STA can respond to being at least 4. A non-AP HE STA may support the following:
— MU-MIMO reception on an RU in an HE MU PPDU where the RU does not span the entire PPDU bandwidth (DL MU-MIMO within OFDMA). The maximum number
of spatial streams per user in the DL MU-MIMO within OFDMA transmission that the non-AP STA can receive shall be a minimum of 4 and the maximum number of spatial streams supported for reception of HE SU PPDUs.
The total number of spatial streams (across all users) in the DL MU-MIMO within OFDMA transmission that the non-AP STA can receive shall be at least 4. Spec says non-AP STA shall be able to receive its intended spatial streams with a total number of spatial streams across all users of at least 4.
Spec also says non-AP STA can respond to at least 4 Nsts HE sounding NPD. In PHY capabilities, we have Best regards, Wook Bong Lee From: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx]
On Behalf Of Sigurd Schelstraete Hi Hongyuan, See below. Regards, Sigurd From: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx>
On Behalf Of Hongyuan Zhang [External Email]: This email arrived from an external source - Please exercise caution when opening any attachments or clicking on links. Hi Sigurd, Junghoon was right on the original line of thoughts when we made up this text in 11ax draft. This also answers your question-1, I think this sentence is somewhat intentional considering the scenario that Junghoon mentioned. Otherwise there is a big loophole that is hard to be missed : one RU could need up to 8 HELTFs so all users
in other RUs would also need to receive 8 HELTFs, how can AP make sure that all the non-AP STAs in this DLMU PPDU are “capable” of receiving 8 HELTFs,
if it is not mandatory and no capability either? [Sigurd] That appears to be the crux of the disagreement:
Either way, your proposal is to introduce a capability. I agree that a capability is needed, rather than assuming that 8 HE-LTF is mandatory. Looks like we only need to decide whether the current HE capabilities
fields have what we need or a new capability is warranted. From: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx>
On Behalf Of Junghoon Suh Hi, Sigurd and Yan I am sorry to cut in the discussion between you two parties. But, the summary of the issues emailed by Sigurd looks quite clear to me and I feel like answering at least the Summary Item 3, below
based on my technical common sense. Regards Junghoon From: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx]
On Behalf Of Sigurd Schelstraete Hi Yan, Let’s try to boil it down to a number of questions:
[Junghoon] I think there is no relevance in 11ax, at least in multiple RU based transmission. Different RU may have different N_sts per RU, but the number of HE-LTF always depends on the maximum number N_sts
in any scheduled RU. So, the maximum number of HE-LTF does not always follow the N_sts in any specific RU which may have been constrained by the Beamformee STS constraint.
In my mind, this issue is a matter of clarification. I’d say the best way forward is to do the clarifying within the existing framework. Adding a new capability with large number of devices already deployed in the field and the amendment
only months away from final approval doesn’t sound like the right approach. Regards, Sigurd From: Yan(msi) Zhang <yan.zhang_5@xxxxxxx>
[External Email]: This email arrived from an external source - Please exercise caution when opening any attachments or clicking on links. Hi Sigurd, We both agree that some additional texts are needed for AP scheduling based on NHE-LTF Rx capability. I also have some notes in the proposed text as well. But Beamformee STS capability value ties with Max Nr required in compressed beamforming
reports, and other DL MU Rx processing constraints. So non-AP STA may be able to receive more HE-LTF symbols in DL OFDMA transmission than it claims in Beamformee STS capability. For example, non-AP STA claims that Beamformee STS is 3 instead of 7 due to beamforming
feedback constraint or DL MU RX processing constraints, but it can receive up to 8 HELTF symbols. If we limit the number of HELTF symbols by Beamformee STS capability, AP will not be able to schedule this STA in a OFDMA transmission with more than 4 HE-LTF
symbols. If we add the HE MU PPDU Max Rx NHE-LTF capability, STA can set this value to 8, so that it can be scheduled in DL OFDMA transmission on a RU without MU-MIMO, with 8 HELTF symbols. By receiving more HELTF symbols, the non-AP STA channel estimation
may be improved. Also this allows more flexible OFDMA scheduling. Let’s discuss more in tomorrow ax conference call. Thanks Yan From: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx>
On Behalf Of Sigurd Schelstraete Caution: EXT Email
Hi Hongyuan, I don’t believe it was ever the intention to make support of 8 HELTFs reception mandatory. I don’t read it that way either, since I think the Beamformee STS capability indication provides (or should provide) an additional constraint that
the AP has to consider when choosing the number of HE-LTF symbols. The proposed change to the Beamformee STS definition is intended to clarify that. I’m not sure where the proposed change conflicts with the draft. I’m guessing you may be referring to the wording “In an HE MU PPDU with more than one RU,
NHE-LTF, may take a value 1, 2, 4, 6 or 8 that is greater than or equal to the maximum value of the initial number of HE-LTF symbols for each RU, where the initial number
of HE-LTF symbols is calculated as a function of NSTS,r,total”. If so, as stated earlier, I believe this statement is further constrained by the Beamformee STS capability. If that’s not clear, we can
address that explicitly. For instance: “In an HE MU PPDU with more than one RU,
NHE-LTF, may take a value 1, 2, 4, 6 or 8 that is greater than or equal to the maximum value of the initial number of HE-LTF symbols for each RU, where the initial number
of HE-LTF symbols is calculated as a function of NSTS,r,total.
The final value of NHE-LTF
is still subject to the Beamformee STS capabilities of all STAs addressed in the HE MU PPDU.”. Regards, Sigurd From: Hongyuan Zhang <hongyuan.zhang@xxxxxxx>
[External Email]: This email arrived from an external source - Please exercise caution when opening any attachments or clicking on links. Hi Sigurd, I think Beamformee STS capability does mean STS in NDP or DLMUMIMO PPDUs, because it is not just preamble/LTF processing but also imply other capabilities such as dimension of feedback beamforming matrix calculation and compression, as
well as handling the total number of streams in a DLMUMIMO PPDU (both intended and interference). In current draft, it is mandatory for non-AP STAs to receive up to 8 HELTFs in the case of DLOFDMA Rx, regardless how many STS it can process. While your proposed change is ok for DLMUMMO over the whole BW, in the case of DLMUMIMO
in one RU, your change still conflicts with the current draft. This is part of the issue that Yan is trying to address in her CR document. Thanks, Hongyuan From: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx>
On Behalf Of Sigurd Schelstraete Caution: EXT Email
Hi Yan, Thanks for your presentation and the discussion in the TGax call this morning. Regardless of the outcome of the proposed change, it appears there is an issue with the description of the Beamformee STS capability field: This field describes the number of “streams” a STA can receive, either as part of a sounding frame or as part of MU-MIMO frame.
The purpose of this field appears to be to indicate the (total) number of streams a STA supports in terms of
preamble processing, not for data processing. Indeed, the stream/MCS capabilities for data processing are separately indicated in the “Supported HE-MCS And NSS Set” field.
When it comes to preamble processing, the only way the number streams affects the preamble is through the number of HE-LTF symbols. In 11ac, the number of streams (be it sounding streams or total number of streams in an MU packet) maps
uniquely to a number of VHT-LTF symbols (see Table 21-13). This is not the case for 11ax MU PPDUs, which can lead to issues. For instance, if a STA supports processing of up to 4 HE-LTF, it would probably indicate 4 as Beamformee STS capability. However, such
a STA may fail to receive even a single stream if it was sent using 8 HE-LTF symbols.
To be correct in all cases, it looks like the Beamformee STS field should talk about the number of HE-LTF symbols more directly (rather than talking about it indirectly through the number of streams). A quick solution could be to add the following note to the Beamformee STS capability field: NOTE: the maximum number of space-time streams for which support is indicated can not be sent using more HE-LTF symbols than the corresponding entry in Table 21-13. FYI – Table 21-13 is given by: I believe that might even fully address the issue you were trying to resolve. If you feel it doesn’t, we can discuss further. Either way, I believe it would be good to provide this clarification about the interpretation of the Beamformee
STS field. Regards, Sigurd To unsubscribe from the STDS-802-11-TGAX list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1 To unsubscribe from the STDS-802-11-TGAX list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1 To unsubscribe from the STDS-802-11-TGAX list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1
To unsubscribe from the STDS-802-11-TGAX list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1 To unsubscribe from the STDS-802-11-TGAX list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1 To unsubscribe from the STDS-802-11-TGAX list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1 To unsubscribe from the STDS-802-11-TGAX list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1 To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1 |