Bugzilla – Bug 2782
LteAmc::CreateCqiFeedbacks Checks for an MCS that is out of range
Last modified: 2017-10-03 21:56:39 EDT
Created attachment 2914 [details] Updated source file with the fix In file lte-amc.cc, the following code describes the valid range of MCS from 0 to 28 /** * Table of MCS index (IMCS) and its TBS index (ITBS). Taken from 3GPP TS * 36.213 v8.8.0 Table 7.1.7.1-1: _Modulation and TBS index table for PDSCH_. * The index of the vector (range 0-28) identifies the MCS index. */ static const 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 }; The following code from LteAmc::CreateCqiFeedbacks has a while loop that checks an MCS value that is out of range (0-29) uint8_t mcs = 0; HarqProcessInfoList_t harqInfoList; TbStats_t tbStats = LteMiErrorModel::GetTbDecodificationStats(sinr, rbgMap, (uint16_t)GetTbSizeFromMcs(mcs, rbgSize) / 8, mcs, harqInfoList); while (mcs <= 28) { if (tbStats.tbler > 0.1) { break; } mcs++; tbStats = LteMiErrorModel::GetTbDecodificationStats(sinr, rbgMap, (uint16_t)GetTbSizeFromMcs(mcs, rbgSize) / 8, mcs, harqInfoList); } The attached file provides a correction to check the valid range.
Hi Robert, thanks. Could you please provide the patch file (not the full source)? Thanks, Biljana
I cannot find in ns-3-dev the piece of code that you mention in your comment.
Patch uploaded to http://codereview.appspot.com/321600043
Hi Robert, thanks for the patch. I will take a closer look next week. If I remember correctly the code is doing exactly what the authors of the code wanted to achieve when modeling 10% BER, but I do not know to provide you the exact explanation for it. It would help if you would explain in which situation did you detect the out of range issue. Did simulation finish with segmentation fault? Thanks, Biljana
I am not sure about this; as I read it, the current code will result in the largest MCS that satisfies that tbStats.tbler <= 0.1. The proposed patch will cause it to use the lowest MCS for which tbler exceeds 0.1.
The range of MCS produced by the original code is: 0, 0, 1, ... 28 the range of MCS produced by the modified code is: 0, 1, ... 28
(In reply to Robert Ammon from comment #6) > The range of MCS produced by the original code is: > > 0, 0, 1, ... 28 > > the range of MCS produced by the modified code is: > > 0, 1, ... 28 I don't see the problem. The code is selecting an mcs, not providing a range. The reason that 0 is doubled is that it may be the case that even the lowest MCS value exceeds the target error rate, but in this case, one cannot do any better and just has to select MCS 0. Or it may be the case that MCS 0 meets the target but MCS 1 does not, so again, MCS 0 is selected.
Original issue was based upon a corrupt source file, no error existed and this issue is cancelled.