Hi Sigurd,
“I believe this statement is further constrained by the Beamformee STS capability”--
I thought it was the other way around, the sentence you quote (highlighted below) says that N_HELTF could be more that that constrained by NSTS.totalàNHELTF mapping (Table 21-13), which implies
non-AP STAs, when operating in DLMU Rx mode (and more than one RU), need to be ready to receive NHELTF up to 8. In another word, this sentence means that N_HELTF is NOT constrained by NSTS.total (in current “Beamformee STS Capability” field).
As you said, if we make change per your suggestion, it conflicts with this sentence, so we also need to revise this sentence.
By the way, the original issue is for the cases with single user in an RU (i.e. DLOFDMA without DLMUMIMO), so “Beamformee STS Capability” is not in the picture, therefore we still need to address the other half of the problem.
Thanks,
Hongyuan
From: Sigurd Schelstraete <sschelstraete@xxxxxxxxxxxxx>
Sent: Wednesday, July 15, 2020 10:57 AM
To: Hongyuan Zhang <hongyuan.zhang@xxxxxxx>; STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: [EXT] RE: [STDS-802-11-TGAX] HE MU PPDU NHE-LTF Rx proposal
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>
Sent: Wednesday, July 15, 2020 1:34 AM
To: Sigurd Schelstraete <sschelstraete@xxxxxxxxxxxxx>;
STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGAX] HE MU PPDU NHE-LTF Rx proposal
[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
Sent: Tuesday, July 14, 2020 6:49 PM
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: [EXT] [STDS-802-11-TGAX] HE MU PPDU NHE-LTF Rx proposal
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
This email, including its contents and any attachment(s), may contain confidential information of ON Semiconductor and is solely for the intended recipient(s). If you may have received this in error, please contact the sender and permanently delete this email,
its contents and any attachment(s).
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