Bug 1840

I think the best approach to fix is to move to the LteAmc class the conversion from UL SINR to CQI, or possibly directly to MCS, and make it parametric, so that one can choose which AMC scheme is used similarly to what we currently support in the downlink.

For example, we could add a new method
int 
LteAmc::GetCqiFromUlSinr (double sinr)
copying part of the code from LteAmc::CreateCqiFeedback (), and maybe having a separate m_dlBer and m_ulBer parameters to allow different target BERs for UL and DL using the Piro model. 


Some practical notes: 

- all scheduler classes need to be modified (though the code is the same)

- if we change the default UL AMC behavior to make it less pessimistic (which makes sense), we will have to change the UL test vectors for all the scheduler tests.

- integrating as well the Vienna model into the UL AMC would be nice, but more invasive on the UL scheduler


Unfortunately I am not currently able to dedicate effort to this issue, if some could propose a patch it would be very much appreciated.

Hi Nicola,

Thanks for opening the bug. Your proposed patch to add separate methods for uplink within lte-amc.cc appears reasonable. I can volunteer to add support for UL based functions within the UL scheduler and lte-amc.cc. That said, I am not entirely sure how the patch process works. Should I submit a prototype of the modifications to the schedulers and lte-amc on the same email thread?

Also, I would like to mention that the mapping of the parameter Imcs to Itbs in LTE is slightly different between uplink and downlink. The difference is mapping is as shown below [the first array is existing LENA implementation which is the correct mapping for downlink, and the array McstoItbsUl is the correct mapping for uplink. 

// Table 7.1.7.1-1 of 3GPP TS 36.213 v8.8.0
int McsToItbs[29] = {
  0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 9, 10, 11, 12, 13, 14, 15, 15, 16, 17, 18,
  19, 20, 21, 22, 23, 24, 25, 26
};

// Added, Vikram Chandrasekhar
// Table 8.6.1-1 of 3GPP TS 36.213 v8.8.0
int McsToItbsUl[29] = {
    0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 10, 11, 12, 13, 14, 15, 16, 17, 18,
    19, 19, 20, 21, 22, 23, 24, 25, 26
};


Finally, do you think we should also look at integrating the MI error model (which is invasive on the UL scheduler as you mention) so that the uplink and downlinks can be made symmetrical. I guess currently the UL schedulers do not support the SpectrumValue data type so calling the MI error model based CQI computation is more difficult.

Hi Nicola and Vikram,

interesting solution Nicola, definitely more clean respect to the one implemented. I agree that the evaluation of the UL-CQI should be moved to LteAmc in order to make it compatible with the LteAmc scheme used.
Unfortunately, I'm quite busy too at this stage, but I can review a patch in case we are going to have a proposal.
Regarding Vikram's comments, I have a couple of comments, too. See in-line.


(In reply to Vikram Chandrasekhar from comment #2)
> Hi Nicola,
> 
> Thanks for opening the bug. Your proposed patch to add separate methods for
> uplink within lte-amc.cc appears reasonable. I can volunteer to add support
> for UL based functions within the UL scheduler and lte-amc.cc. That said, I
> am not entirely sure how the patch process works. Should I submit a
> prototype of the modifications to the schedulers and lte-amc on the same
> email thread?

I see a couple of solutions:
- submit a patch to this bugzilla
- open a repository with the code and ask for a review (e.g., rietveld)

> 
> Also, I would like to mention that the mapping of the parameter Imcs to Itbs
> in LTE is slightly different between uplink and downlink. The difference is
> mapping is as shown below [the first array is existing LENA implementation
> which is the correct mapping for downlink, and the array McstoItbsUl is the
> correct mapping for uplink. 
> 
> // Table 7.1.7.1-1 of 3GPP TS 36.213 v8.8.0
> int McsToItbs[29] = {
>   0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 9, 10, 11, 12, 13, 14, 15, 15, 16, 17, 18,
>   19, 20, 21, 22, 23, 24, 25, 26
> };
> 
> // Added, Vikram Chandrasekhar
> // Table 8.6.1-1 of 3GPP TS 36.213 v8.8.0
> int McsToItbsUl[29] = {
>     0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 10, 11, 12, 13, 14, 15, 16, 17, 18,
>     19, 19, 20, 21, 22, 23, 24, 25, 26
> };

The curves for the BLER mapping are based on the DL MCS. By changing the Itbs you might use an erroneous curve for evaluating the error of a certain TB, this should happen especially for the MCSs close to the changing of modulation order (which is the main reason that the tables changes between DL and UL). The problem is that at the time we developed that code, we were not able to find any good model for obtaining the curves of BLER for UL, so we decided to use the DL one as an approximation.
In case you would like to update McstoItbsUl you should take in consideration this, and ideally include the correct UL MCS BLER curves.

> 
> 
> Finally, do you think we should also look at integrating the MI error model
> (which is invasive on the UL scheduler as you mention) so that the uplink
> and downlinks can be made symmetrical. I guess currently the UL schedulers
> do not support the SpectrumValue data type so calling the MI error model
> based CQI computation is more difficult.

The DL and UL are rather symmetrical right now (even too much!). The MI Error model is not properly invasive to the scheduler, it is used by the LteAmc for obtaining en estimation of the BLER with the CQIs reported to the scheduler via the static method GetTbDecodificationStats().
I did not get the comment on the SpectrumValue. The scheduler does not support SpectrumValue; while, according to the FF-API, it supports different feedback in terms of channel condition:
- in DL the standard CQIs.
- in UL an approximation of the SINR perceived by the eNB (with fixed point notation).
This twofold nature is the cause of the spurious conversion in the scheduler.

Hi Marco,

Thanks for the explanation. I shall address the patch as soon as possible.
If I understand correctly, here are two fundamental areas where NS3 differs from TS36.213: 

1. The parameter Imcs have different interpretations in the LTE specification for UL versus DL. For example, over UL, the parameter Imcs <= 20 results in 16 QAM, whereas on the DL, choosing Imcs>=17 results in 64 QAM. In NS3, the meaning of Imcs stays the same whether it is UL or DL.
2. the mapping of Imcs to Itbs is different over UL and DL. In NS3, identical mapping is used.

Since as you say, the BLER curves in the MI model are obtained for downlink only, I believe we should assume that the Imcs values and the mapping between Imcs to Itbs stays the same for UL and DL (even though in LTE, they are not one and the same). I guess for purposes of fixing the bug, some simple changes to lte-amc and updates to scheduler code should suffice, with the understanding that link adaptation on UL and DL are modeled identically. 

To round off, I wanted to ask whether in future, there are any plans to accurately model the differences in UL versus DL.

Sorry for the long-winded email; I just wanted to make sure we understand all corner cases correctly :-)

Finally, just to clarify, regarding SpectrumValue, what I meant to say was that if we wanted to map SINR to CQI using the MI error model, we need to call the corresponding method inside Lte-amc.cc, which however requires the SpectrumValue data type.

- Vikram

You understand correctly: the Itbs mapping is the same for DL and UL since they use the same BLER curves. Therefore, for updating the Itbs for UL the UL BLER curves has to be integrated.
Regarding the latter, at this stage, we have no plan to work on it.

Finally, instead of the SpectrumValue I would go for a new interface of LteAmc as the one proposed by Nicola (i.e., LteAmc::GetCqiFromUlSinr (double sinr)) in order to do no modify the scheduler FF-APIs.

Hi guys,

I posted a code review request at the url https://codereview.appspot.com/214360043/

It is a proposal for patching this bug.

- Danilo