Limited number of used CQI/MCS

[Oleksandr]

Hi all,

I've seen some topic about CQI, but I was not able to found discussion on this problem previously. Does anyone tried to trace all possible CQI?
In the attachment you can find a bit modified lena-cqi-threshold.cc from lte/examples. The scenario is very simple, The UE is moving away from NodeB with 10m step and then I just pick MCS values from DlMacStats.txt. From this trace can be seen that only 10 CQI are in use. (out of 16 in total).
You can find the figure with MCS distribution in the attachment.

When I started to debug this situation, I realized some strange values for the "b" and "c" parameter in the BLER calculation:
The following equation can be found in the code in LteMiErrorModel::MappingMiBler function or in the "LTE Simulator Documentation, Release M5" page 16

bler = 0.5*( 1 - erf((mib-b)/(sqrt(2)*c)) );

In the same file (lte-mi-error-model.cc) you can find array with "b" and "c" values that were taken from link level simulator.

There are three main question of this topic:

1) Does anyone tried to trace CQI previously?
2) Could someone try to reproduce this problem?
3) Is it possible to reproduce "b" and "c" values from link level simulator?

Regards,

Oleksandr Puchko

[Marco Miozzo]

Hi Oleksandr,

1) and 2) based on my knowledge no one keep track of the CQIs; however, we have several cases where people done something similar with MCSs, you may find a bug-fix here:
https://www.nsnam.org/bugzilla/show_bug.cgi?id=1508

If you try to run the script, you may see that MCSs are pretty well distributed according to the decreasing SNR.

Looking at the figure you reported, it would be interesting to know the simulation parameters you used in order to understand the simulation scenario and the statistical inference.

3) Yes it is possible, by means of the LTE Vienna Simulator and the guidelines in the documentation:
http://www.nt.tuwien.ac.at/about-us/staff/josep-colom-ikuno/lte-a-downlink-link-level-simulator

Regards,
marco.

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Oleksandr]

Hi Marco,

Thanks for your reply.
Today I've downloaded newest version of LENA branch from:

hg clone http://lena.cttc.es/hg/lena/

Then I run script from bug fix that you mentioned: https://www.nsnam.org/bugzilla/show_bug.cgi?id=1508
After that I modified this script to have all possible MCSs, i.e. from 0 to 28

In the attachment you can find these two scripts, postprocessing scripts, which I used to plot the figures and figures itself. 
I've also attached renamed DlMacStats.txt from two simulations, however you can obtained them by yourself. 
The figures show MCS versus distance and TBsize versus distance for 1 and 5 km.
To use postprocessing scripts you should have gnuplot and bash.

As you will see from the figures for 5km distance, there are only 11MCS is used, but for my opinion it should be equal to the amount of CQI, i.e 16.

Regards,
Oleksandr Puchko

[Marco Miozzo]

Hi Oleksandr,

the behavior you are perceiving might have two sources.
From UE side, the PHY layer is generating the CQIs according to TS 36.213 section 7.2.3, where CQI indexes are defined as function of the TB error rate. In this case, depending on the error model might be that some spectral efficiencies are not suitable for transmitting at certain TB sizes. I would suggest you to check this behavior for both in-band and wide-band CQIs.

From eNB side, the schedulers use inband o wideband CQIs for evaluating the MCSs in rather simplistic fashion (i.e., always the worst CQI is used in PfFfMacScheduler for selecting the MCS); therefore this might further prune the number of MCS used.

Best regards,
marco.

[Oleksandr]

Hi, Marco,

Maybe I am wrong, but I think that the arrays for "b" and "c" values for mi-error-model is wrong and it cause this problem. I will run the same scenarios, but with another error model(Piro) and send results to you.
For my opinion, if the results would be the same(i.e only 11MCS will be in use) then the problem somewhere else, but if the results with Piro error model will show usage of all possible CQI, then the problem in mi-error-model.
What do you think about it?

P.S. Does anyone can reproduce BLER curves for 16QAM modulation to compare them to the curves in the lte-sim-document?

Regards,
Oleksandr Puchko

[Marco Miozzo]

Hi Oleksandr,

The b and c values are plotted in (red dotted lines):
http://www.nsnam.org/docs/release/3.16/models/html/lte-design.html#data-phy-error-model

According to the graphs they behave like expected.

Therefore the problem, might be in the intrinsic simplicity of the algorithm for selecting the CQIs at UE side (and let me add eNB too), I would suggest you to test it better (probably a unit test might help) in order to highlight its limitations (or maybe, even, bugs).

We did not perform optimization/performance test on this algorithm right now, we only quantitatively validated its functionality since we it is out of scope of LENA project this kind of optimization.

Best regards,
marco.

[Oleksandr]

Hi Marco,

Here is the set of figures that I've got from simulator. Basically it should be the same as in http://www.nsnam.org/docs/release/3.16/models/html/lte-design.html#data-phy-error-model, however not all the MCSs are the same.

Take a look at figures: 11, 15, 18 and 19. These figures are completely different from the document and from logical point of view.

So maybe b and c values should be regathered. 

Regards,

Oleksandr

[Marco Miozzo]

Hi Oleksandr,

I realized that the figures in the doc are not the right ones, in fact the ones for low MCS are rather conservative respect to the one used in the tests, as you can see from:
http://lena.cttc.es/manual/lte-testing.html
This problem might due to the change in the ECRs we included more then one year ago, which has been reflected in the testing documentation and not in the design documentation.

I will correct the design documentation accordingly asap and I will check your figures with the real ones (from a quick test it seems to me that they are in-line with your ones).

Thanks for your comment.

Regards,
marco.

[Oleksandr]

Hi Marco,

Thanks for your answer, however I think there is still some misunderstanding between us.

The link adaptation and physical error model tests, from the http://lena.cttc.es/manual/lte-testing.html , used LteAmc::PiroEW2010 and I was talking about LteAmc::MiErrorModel. I've checked all the tests, and no one used MiErrorModel, so maybe in future it would be nice to have test for LteAmc::MiErrorModel, after this model will be fixed.

[Marco Miozzo]

Hi Oleksandr,

Yes it uses the LteAmc::PiroEW2010 but only for the purpose of imposing an ad-hoc AMC selection mode ("for making it less robust to channel conditions") and check the correctness of the LteMiErrorModel as detailed in the documentation. However, the MCSs you mentioned above are not tested, so we would need to extend the tests.

Best regards,
marco.

[Oleksandr]

Hi Marco,

Please take a look at this function: LteAmc::CreateCqiFeedbacks (const SpectrumValue& sinr, uint8_t rbgSize)
In this function we calculate CQI based on AMC model. If AMC is PiroEW2010, then we calculate spectral efficiency from the SINR and get CQI from this spectral efficiency. When we are using MiErrorModel, then we get CQI from MCS, which was chosen as the most efficient(higher) MCS with bler>0.1 (or 10%). Further, bler for each MCS calculates according to the function from my first e-mail:

bler = 0.5*( 1 - erf((mib-b)/(sqrt(2)*c)) );

where for my opinion b and c value for MCS  11, 15, 18 and 19 are wrong.


Regards,
Oleksandr

On Tuesday, April 16, 2013 10:32:01 AM UTC+3, Marco wrote:

Hi Oleksandr,

Best regards,
marco.

[Marco Miozzo]

Hi Oleksandr,

I've updated the figures in the lena repository (the ones for low MCSs were erroneous) and checking the behavior you reported. I can confirm that there is a bug in the coefficient "b" and "c" of the Gaussian cumulative approximation used in the simulator for what concern MCS 11, 15, 18, 19 (where they behave different to what reported in the figures in the documentation). Many thanks for your effort in discovering the bug.

The bug has been reported in bugzilla, here the link:
https://www.nsnam.org/bugzilla/show_bug.cgi?id=1628

We will work on this issue in the following weeks and, as usual, contributions and/or patches on this bug are more than welcome!!!

Best regards,
marco.

[Oleksandr]

Hi Marco,

Thanks for taking care of this issue. I think, that I will not be able to put more effort on this issue since it will require obtaining new b and c value for 16QAM from link level simulator, with which I am not familiar.

Regards,
Oleksandr

On Friday, April 19, 2013 2:55:50 PM UTC+3, Marco wrote:

Hi Oleksandr,

I've updated the figures in the lena repository (the ones for low MCSs were erroneous) and checking the behavior you reported. I can confirm that there is a bug in the coefficient "b" and "c" of the Gaussian cumulative approximation used in the simulator for what concern MCS 11, 15, 18, 19 (where they behave different to what reported in the figures in the documentation). Many thanks for your effort in discovering the bug.

The bug has been reported in bugzilla, here the link:
https://www.nsnam.org/bugzilla/show_bug.cgi?id=1628

We will work on this issue in the following weeks and, as usual, contributions and/or patches on this bug are more than welcome!!!

Best regards,
marco.

[Marco Miozzo]

Hi Oleksandr,

the bug have been solved, you can find the code in lena repository, it will be merged in ns-3 within the ns3.18 release process.

Let me thanks Marco Mezzavilla for the support in fixing the bug.

Best regards,
marco.

[Songlin Liu]

Hi Oleksandr,

    sorry to bother you.

    could you please tell me how did you get the bler-sinr figures.in other words,what simulator did you use to do lte link simulation.

    

    Regards,

    Liu Songlin

在 2013年4月15日星期一 UTC+8下午7:36:13，Oleksandr写道：