Bug 2567

Created attachment 2689 [details]
patch to lte-mi-error-model.cc

In the method LteMiErrorModel::GetTbDecodificationStats, the code from lines 681 to 711 are supposed to search for the closest pre-computed Effective Code Rate (ECR) value in the look-up table BlerCurvesEcrMap corresponding to the actual effective code rate Reff (calculated on line 570), in the case of a HARQ re-transmission.  
The constants MI_QPSK_MAX_ID, MI_16QAM_MAX_ID, MI_64QAM_MAX_ID in lte-mi-error-model.h define the ranges of MCS values for each modulation scheme (0-9 for QPSK, 10-16 for 16QAM and 11-28 for 64QAM). 
However, because there are 3 additional values ECR values in BlerCurvesEcrMap for lower code rates (for each 3 additional HARQ re-transmissions), the range of values used to index the BlerCurvesEcrMap table is 0-12 for QPSK, 13-22 for 16-QAM, and 23-37 for 64QAM.  These ranges are defined by the constants
MI_QPSK_BLER_MAX_ID, MI_16QAM_BLER_MAX_ID, and MI_64QAM_BLER_MAX_ID.  Therefore, on lines 685, 695, 697, 705, and 706, the range of the index i should be constrained by these "BLER_MAX_ID" constants, not the "MAX_ID" constants.  

Fortunately, it seems the code still behaves the way it was intended and the HARQ test suite passes, even when there are these typos where the constants are switched as suggested. This is because the values for the re-TXs in BlerCurvesEcrMap correspond to indices 0,1,2 for QPSK, 13,14,15 for 16QAM and 23,24,25 for 64QAM, and these values fall into the correct range that is searched in each of the 'while' loops.  So as long as the Reff value is closest to one of the re-TX values here, the behavior should still be correct, even though there appear to be these typos.

A patch has been provided, compliments of Marco Miozzo.  Thanks.