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

[STDS-802-11-TGBE] Technical Discussion on doc 20/651



Hello 11be PHY colleagues,

 

Following the discussion during the presentation of contribution 20/651r2 (Further Thoughts on EHT-LTF PAPR in 802.11be) on Monday June 1st , I would like to clarify and emphasize the main issue respective to whether PAPR reduction can be applied to the EHT-LTF sequences in a manner transparent to the receiver.

We showed that PAPR reduction should be applied to EHT-LTF sequences for specific Multi-RU cases and we claim it should be standardized to ensure both Tx and Rx side are aware of the exact transformation applied to the transmitted signal.

 

Explicit spec definition of this mechanism is required for several reasons:

1.       During NDP transmission, the beamformee is mandated by the spec (802.11n and beyond) to compensate/undo the CSD in order to ensure the physical channel is estimated. If the LTFs within the NDP undergo some type of transformation, it may yield a non-continuous equivalent channel as seen by the receiver, and hence smoothing CHEST cannot be used.  This means that the PAPR reduction method should be either known to the receiver (so it can ‘remove’ it) or should not prevent the application of smoothing CHEST. For example, our proposed solution in 20/651 might be configured to allow channel smoothing application at the receiver (see slide 8).    

2.       Moreover, the transmission of an NDP (specifically, the BW used and the value of N_SS) is not necessary aligned with the precoded data packets that follow it. For example, the used BW (e.g. RU used for the STA) may change between the NDP (where, for example in the case of punctured NDP, 242+484 tones can be used) and the following precoded data packet (where only a 242-tone RU may be used). The application of the same PAPR reduction scheme during both NDP and data PPDU phases may be detrimental to the performance.

3.       Focusing on the data PPDU only (ignoring the NDP), some receivers may apply channel estimation & smoothing methods (and/or time/tap domain processing). These methods can overcome (compensate) a single linear phase applied to the entire BW which results in shift of the channel taps in tap-domain. However, a general PAPR reduction method may be seen as convolution with an arbitrary filter in the tap domain which cannot be compensated when the filter is unknown to receiver. This means – again – that PAPR reduction may limit channel smoothing gain or even ruin the data detection.

In the figure below we show a noiseless estimation of a simple 3-taps channel, where the red curve corresponds to an MRU (242+484 tones) with no PAPR reduction, the blue curve corresponds to the same signal with PAPR reduction (based on linear phase per-RU suggested in 20/651) and the green curve corresponds to channel taps with single linear phase after compensation in the receiver.  In this case (if the receiver is not aware of the sequence used at the transmitter side) channel smoothing gain will be significantly lower. 

 

Moreover assuming a general PAPR reduction method, it might result in a composite impulse response that is much longer than the CP which is ¼ symbol duration (see figure below). This means smoothing filter up to ¼ of OFDM symbol samples (typical for WiFi), will be unable to compensate for this response and this will severely impact the performance.

 

 

We can see that the application of a generalized PAPR reduction scheme didn’t (cyclically) shift the channel taps – as would happen with a single linear phase applied in frequency domain – but instead created a more ‘complicated’ channel for which it may be impossible to apply smoothing CHEST.

However, if the receiver knows the sequence used at the transmitter side, it can ‘remove’ it (similar to ‘removing’ CSD on the NDP) and perform CHEST.

Based on the above, we believe that PAPR reduction mechanism, applied on the specific cases of Multi-RU EHT-LTF with high PAPR, cannot be transparent to the receiver side and the spec should hence define the specific solution, be it whatever we agree it should be.

 

 

Your comments and/or insights will be appreciated.

 

 

Genadiy Tsodik

Algorithm Expert

Huawei TLV Research Center

Genadiy.tsodik@xxxxxxxxxx

Office: +972-74-7198101 | Mobile: +972-526773161 | fax: +972-9-9511218   

 

signature

 


To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1