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 Yan,

Understood.

As you mentioned, some STA may be able to process NLTF = 8 while some STA don’t.

Some STA may be able to do this for SU-MIMO while some don’t.

These are implementation choice.

Agree that if we have separate capabilities, then it may help AP to include more STAs in a certain HE MU PPDU.

But don’t know what will be percentage improvement.

Problem is there are already STAs mixed these two implementations.

As Huizhao mentioned if non-AP STA does not update its HE capabilities, there will be huge confusion.

How AP knows which STA included that field and which STA does not?

Reserved bit is 0. This means the updated AP will interpret the non-AP’s STA’s capability is NLTF=8 if the non-AP didn’t update its capability bit setting.

Best regards,

Wook Bong Lee

From: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx] On Behalf Of Yan(msi) Zhang
Sent: Friday, July 17, 2020 10:25 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 Wook Bong,

I think some implementations may report a lower Beamfomee STS due to sounding capability (e.g., beamforming feedback max(Nr) constraint). But it is able to receive more HELTF symbols in data transmission so long the NSTS for the STA is <=Beamformee STS. This is similar to 11ac standard where for MU transmission, there is a capability Maximum Nsts_total in Supported VHT-MCS and NSS Set subfields to decouple Sounding capability and data processing capability

maximum value for NSTS,total

The maximum value for NSTS,total that can be sent to the STA in a VHT MU PPDU if the STA is MU beamformee capable

If not MU beamformee capable, set to 0.

If MU Beamformee capable and different from 0, indictates the maximum value for NSTS,total minus 1 that can be sent to the STA in a VHT MU PPDU. In this case, the value shall be equal to or larger than the value communicated in the Beamformee STS Capability subfield of the VHT capabilities Info field.

If MU Beamformee capable and equal to 0, this indicates that the maximum value for NSTS,total is equal to the value communicated in the Beamformee STS Capability subfield of the VHT capabilities Info field.

This was proposed by Sigurd in 802.11-15/0057 MU Beamformee capabilities indication in VHT. As he pointed out that Forming of MU groups is constrained by STAs with the lowest value of Beamformee STS capability if Beamfomee STS also determines data processing capability.

Our proposal actually solves the similar issue here for OFDMA grouping. I think an additional capability to indicate data processing is beneficial for AP flexible OFDMA scheduling.

Thanks

Yan

From: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx> On Behalf Of Wook Bong Lee
Sent: Friday, July 17, 2020 8:45 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 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]
Sent: Thursday, July 16, 2020 10:55 PM
To: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>; STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: RE: [EXT] Re: [STDS-802-11-TGAX] HE MU PPDU NHE-LTF Rx proposal

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:

Hongyuan

From: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx> On Behalf Of Wook Bong Lee
Sent: Thursday, July 16, 2020 9:36 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 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
Sent: Thursday, July 16, 2020 4:22 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 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