Bug 2339 - PUSCH transmit power is scaled incorrectly when uplink power control is enabled.
PUSCH transmit power is scaled incorrectly when uplink power control is enabled.
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: lte
unspecified
All All
: P5 critical
Assigned To: Marco Miozzo
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-17 08:02 UTC by Alexander Krotov
Modified: 2018-09-07 08:25 UTC (History)
4 users (show)

See Also:


Attachments
Proposed patch (1.68 KB, patch)
2016-03-17 08:02 UTC, Alexander Krotov
Details | Diff
Patch to disable UE power in LTE scheduler tests (10.32 KB, patch)
2016-03-17 08:09 UTC, Alexander Krotov
Details | Diff
Patch to change expected values in frequency reuse tests (9.81 KB, patch)
2016-03-17 08:13 UTC, Alexander Krotov
Details | Diff
Updated patch (4.69 KB, patch)
2018-09-07 05:50 UTC, Zoraze Ali
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Krotov 2016-03-17 08:02:28 UTC
Created attachment 2342 [details]
Proposed patch

LteUePowerControl::CalculatePuschTxPower returns total transmit power over all RBs used by PUSCH, but LteSpectrumValueHelper::CreateTxPowerSpectralDensity expects transmit power over the whole bandwidth. Therefore, the result of CalculatePuschTxPower should be re-scaled before storing it in m_txPower.

PUSCH power, as calculated by LteUePowerControl::CalculatePuschTxPower, is proportional to the bandwidth used (LteUePowerControl::m_M_Pusch), as specified in 3GPP TS 36.213. But then it is divided by the whole bandwidth to calculate spectral density. As a result, spectral density of transmitted signal decreases as UEs gets smaller part of the whole bandwidth, while it should remain constant.

Commit with bugfix is attached. Another solution would be to rescale m_txPower before passing it to LteSpectrumValueHelper::CreateTxPowerSpectralDensity, but this will change behavior when power control is disabled: instead of constant spectral density, UEs will use constant power.

Bug description from commit message:
"""
According to 3GPP TS 36.213 V 13.0.1 (Section 5.1 Uplink power control), the transmit power, as calculated by LteUePowerControl::CalculatePuschTxPower, should be "split equally across the antenna ports on which the non-zero PUSCH is transmitted".
    
The variable m_txPower stores the transmit power, which is later used by LteSpectrumValueHelper::CreateTxPowerSpectralDensity as the `powerTx' parameter, that is "the total power in dBm over the whole bandwidth".
    
Therefore, the value returned by LteUePowerControl::CalculatePuschTxPower should be rescaled from PUSCH bandwidth to the whole bandwidth before storing in m_txPower.
    
Similar changes for PUCCH and SRS are not required, as PUUCH consumes zero bandwidth in NS-3 and SRS uses the whole bandwidth.
"""
Comment 1 Alexander Krotov 2016-03-17 08:09:56 UTC
Created attachment 2343 [details]
Patch to disable UE power in LTE scheduler tests

When the proposed patch is applied, some of the tests fail. Note that tests that involve only one UE are not affected, as in this case UE receives the whole bandwidth.

This patch disables power control in all scheduler tests. It seems that tests were introduced when power control did not exist or was disabled by default, as they set TxPower for all UEs manually, but it is overwritten by power control:
uePhy->SetAttribute ("TxPower", DoubleValue (23.0));

The patch adds the following line each time TxPower is set manually:
uePhy->SetAttribute ("EnableUplinkPowerControl", BooleanValue (false));
Comment 2 Alexander Krotov 2016-03-17 08:13:14 UTC
Created attachment 2344 [details]
Patch to change expected values in frequency reuse tests

As a result of applying proposed patch, all the values increased. I have no way to check that they are "correct", so I just updated them with results I got.
Comment 3 Zoraze Ali 2018-04-13 08:05:20 UTC
Hi, 

I agree the total transmit power should be distributed among the active RBs. However, this behavior should also be maintained when power control is disabled.

One way do this is to have a separate function for computing UL power spectral density, e.g., LteSpectrumValueHelper::CreateUlTxPowerSpectralDensity and do, 

double txPowerDensity = (powerTxW / (activeRbs.size() * 180000));

rather than the whole bandwidth.

There is one more change we need to make if we adopt this idea, that is the kind of UL CQI the scheduler will use to compute MCS. If ALL_UL_CQI is used, i.e. SRS plus PUSCH based, there will be oscillations in MCS values due to the difference in SINR values caused by their different Tx power levels. My suggestion is to remove the ALL_UL_CQI filter and keep only PUSCH_UL_CQI and SRS_UL_CQI. Depending on the nature of the application user can choose what fits the best.

If there are no further comments I will try to submit the patch over the weekend. 

Kind regards,
Zoraze
Comment 4 Zoraze Ali 2018-09-07 05:50:31 UTC
Created attachment 3182 [details]
Updated patch

Hi, 

Attached are the new patches as per the description in my previous comment. To summarize, the PSD calculation in uplink will now only consider the active RBs. This is irrespective of if power control is enabled or not. 

Update on patches provided by Alexander: 

I have not used any of his patches since the behavior is not only restricted to the power control only. There is no need to apply the patch for the schedulers after configuring the SRS based CQI filter.
 
The patch to change the expected values in frequency reuse tests was not used as well. The problem is not the test values, it is the fixed uplink bandwidth (25 RBs) used to extract the power from the PSD. As per the new change, we should use the total number of active RBs, instead of total bandwidth. 

Moreover, thanks to Biljana, we now know that there are MATLAB scripts available in :

src/lte/test/reference/lte_frequency_reuse.m
src/lte/test/reference/path_loss.m

which can be used to verify the power levels.

Kind regards,
Zoraze
Comment 5 Zoraze Ali 2018-09-07 08:25:18 UTC
Thanks all you for reporting and providing the feedback. The final patch is pushed to the changeset 13796:7ece2769e345

Kind regards,
Zoraze