Re: [STDS-802-11-TGAX] [EXT] Re: [STDS-802-11-TGAX] HE MU PPDU NHE-LTF R

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Hi Hongyuan,

See below.

Regards,

Sigurd

From: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx> On Behalf Of Hongyuan Zhang
Sent: Thursday, July 16, 2020 11:48 AM
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAX] [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,

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:

You believe it’s mandatory
I believe there is a capability implied in Beamformee STS

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
Sent: Thursday, July 16, 2020 11:34 AM
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAX] [EXT] Re: [STDS-802-11-TGAX] HE MU PPDU NHE-LTF Rx proposal

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
Sent: July 16, 2020 1:39 PM
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAX] [EXT] Re: [STDS-802-11-TGAX] HE MU PPDU NHE-LTF Rx proposal

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?

[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.

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