Hi Sigurd,
Please see my reply below.
Thanks
Yan
From: Sigurd Schelstraete <sschelstraete@xxxxxxxxxxxxx>
Sent: Thursday, July 16, 2020 10:39 AM
To: Yan(msi) Zhang <yan.zhang_5@xxxxxxx>; STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: RE: [EXT] Re: [STDS-802-11-TGAX] HE MU PPDU NHE-LTF Rx proposal
Caution: EXT Email
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?
[Yan]: It is not clear to me if it is the intention or poor wording in the draft for HE MU PPDU transmission. However, for HE-LTF support for HE TB PPDU is very clear in the spec. Based
on the following spec text, it is mandatory for non-AP STA to support transmit 8 HE-LTF symbols for HE TB PPDU using UL MU-MIMO transmission if the non-AP STA support UL MU-MIMO. Furthermore, text in 27.3.11.10 HE-LTF implies that non-AP STA should support
8 HE-LTF symbols transmission. So based on those texts, I believe it is the intention to make non-AP STA support of 8 HE-LTFs mandatory for at least UL transmission.
27.3.3.2.4 Maximum number of spatial streams in UL MU-MIMO
A non-AP STA that supports UL MU-MIMO shall support transmitting an HE TB PPDU using MU-MIMO
where:
—
The number of spatial streams allocated to the non-AP STA ranges from 1 to
N, where
N
is the
smaller of 4 and the maximum number of spatial streams supported by the non-AP STA for transmitting
HE SU PPDUs.
—
The number of total spatial streams (summed over all users) is less than or equal to 8.
The maximum number of spatial streams supported by a STA for the transmission of an HE SU PPDU is
indicated in the Supported HE-MCS And NSS Set field in the HE Capabilities element.
All the requirements in this subclause on the per user and total number of spatial streams are applicable to
both full bandwidth and partial bandwidth MU-MIMO.
27.3.11.10 HE-LTF
For an OFDMA HE TB PPDU
NHE-LTF
may be 1, 2, 4, 6 or 8, which is greater than or equal to the maximum value
of the initial number of HE-LTF symbols for each RU
r, which is calculated
as a function of NSTS,r,total,
separately
based on Table 21-13 (Number of VHT-LTFs required for different numbers of space-time streams)
in 21.3.8.3.5 (VHT-LTF definition), replacing
NVHT-LTF
by
NHE-LTF.
- Isn’t it always the case that the transmitter should respect whatever constraints the receiver has indicated, even if that is not explicitly stated?
[Yan]: It is true that the transmitter should respect whatever constraints the receiver has indicated. But if it is not explicitly stated, different implementations may have
different interpretations. By reading text in HE-LTF regarding NHE-LTF support for HE MU PPDU with more than one RU, some AP implementations assume that all non-AP STA can support receiving 8 HE-LTF symbols, while some implementations may interpret based on
Beamformee STS support. We just want to make it clear to the AP on non-AP STA NHE-LTF Rx support.
- 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?
[Yan]: In normal situation,
Beamformee STS does indicate the max number of HE-LTFs that a STA can process/receive. But in some implementations, non-AP STA want to receive more HE-LTF symbols in preamble to help channel estimations.
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.
[Yan]: I agree that it is kind of late in the 11ax development to add a new capability. But by clarifying the text, it still affects APs already deployed which assumes that non-AP STA can support receiving 8
HE-LTF symbols.
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
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