Hi Yan,
Let’s try to boil it down to a number of questions:
- Do we believe that it was the intention to make support of 8 HE-LTFs mandatory or is this poor wording in the draft?
- Isn’t it always the case that the transmitter should respect whatever constraints the receiver has indicated, even if that is not explicitly stated?
- Does the Beamformee STS constraint have any relevance in setting the max number of HE-LTFs that a STA can process/receive?
- Beamformee STS already controls a number of capabilities that could have been signaled independently (similar to what you argue below, there’s no a priori reason that “Max Nr” constraint
and “DL MU Rx processing constraints” should have to be the same). Given that it was a conscious decision to keep these together, do we want to decouple STS/HE-LTF capabilities now?
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>
Sent: Wednesday, July 15, 2020 12:03 PM
To: Sigurd Schelstraete <sschelstraete@xxxxxxxxxxxxx>; STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: RE: [EXT] 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,
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
Sent: Wednesday, July 15, 2020 10:57 AM
To: 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
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