Bugzilla – Bug 2048
LTE schedulers allocate data even when CQI==0 (out of range)
Last modified: 2016-11-23 06:44:34 UTC
See pf-ff-mac-scheduler.cc line 1126: uint8_t cqi1 = sbCqi.at (0); uint8_t cqi2 = 1; if (sbCqi.size () > 1) { cqi2 = sbCqi.at (1); } if ((cqi1 > 0)||(cqi2 > 0)) // CQI == 0 means "out of range" (see table 7.2.3-1 of 36.213) { if (LcActivePerFlow ((*it).first) > 0) the issue that when only one layer is used (SISO) cqi2 is always 1, hence ((cqi1 > 0)||(cqi2 > 0)) is always true, and the flow is allocated, in spite of the fact that a CQI == 0 was reported. the proposed fix is to initialize cqi2 = 0; This reasoning was done on PF, but it seems that other schedulers are affected as well.
I've added to the tests for each scheduler a new test case like this: // DOWNLINK - DISTANCE 100000 -> CQI == 0 -> out of range -> 0 bytes/sec // UPLINK - DISTANCE 100000 -> CQI == 0 -> out of range -> 0 bytes/sec AddTestCase (new LenaPfFfMacSchedulerTestCase1 (1,100000,0,0,errorModel), TestCase::QUICK); and the results of test.py are: FAIL: TestSuite lte-pf-ff-mac-scheduler PASS: TestSuite lte-rr-ff-mac-scheduler FAIL: TestSuite lte-fdbet-ff-mac-scheduler PASS: TestSuite lte-tdmt-ff-mac-scheduler FAIL: TestSuite lte-tdbet-ff-mac-scheduler FAIL: TestSuite lte-fdmt-ff-mac-scheduler FAIL: TestSuite lte-tta-ff-mac-scheduler FAIL: TestSuite lte-pss-ff-mac-scheduler FAIL: TestSuite lte-fdtbfq-ff-mac-scheduler FAIL: TestSuite lte-cqa-ff-mac-scheduler FAIL: TestSuite lte-tdtbfq-ff-mac-scheduler The code with the new test cases is here: http://code.nsnam.org/nbaldo/ns-3-bug2048/ Marco, can you please comment on the proposed fix (initializing cqi2 = 0;)? Zoraze, can you please provide a patch and comment on other related issues you might find?
Definitely, it is a bug, the fix is fine with me.
Hi all, I have tried to implement the fix and started with Proportional Fair scheduler. The recent tests added by Nicola for Pf scheduler passes but the test in lte-cqi-generation written by Piotr fails. Following is public repository which contains the patch for pf only (for now) plus test results for lte-cqi-generation. It contains also the NS logs from the failed test in both cases i.e. with patch(cqi2=0) and without patch (cqi2=1). https://bitbucket.org/zoraze/repo_patch In the log file Testlogcqi2_1 it can be found that scheduler is assigning MCS 0 with CQI == 0. I am trying to understand the cause for test to fail but it will be helpful if Piotr can have a look so we can resolve it bit fast. Kind regards, Zoraze
The problem is in LteCqiGenerationDlPowerControlTestCase. There are two cells and two UEs in the middle between two eNBs. In each test case different pairs of PdschConfigDedicated.P_A are configured for all UEs in cells. I have noticed that the problem appears when one eNB transmit PDSCH with much higher power than the other one (ie. eNB1 has P_A = 0dB and eNB2 has P_A = -6dB). UE in cell2 has very poor channel and its CQI_1 is 0 (and now also CQI_2 = 0), so eNB2 is not transmitting PDSCH to UE2. As a result, there are no interferences on PDSCH and UE1 in cell1 has CQI = 28. There is simple solution. UE2 should be moved closer eNB2. It will have better downlink channel, so there will be transmission in DL direction, which will interfere to Cell 1 and UE1 CQI will decrease to expected value. One drawback of this solution is that, expected UL MCS has to be updated for each test case. But there is second solution. Do not move UE2, but add third UE which is closer to eNB2: ... enbNodes.Create (2); ueNodes1.Create (1); ueNodes2.Create (2); ... positionAlloc->Add (Vector (0.0, 0.0, 0.0)); // eNB1 positionAlloc->Add (Vector (1000, 0.0, 0.0)); // eNB2 positionAlloc->Add (Vector (500.0, 0.0, 0.0)); // UE1 positionAlloc->Add (Vector (500, 0.0, 0.0)); // UE2 positionAlloc->Add (Vector (950, 0.0, 0.0)); // UE3 There will be always transmission in DL direction to UE3 (which will produce interferences to Cell 1) and UE2 will transmit PUSCH as before, so expected UL MSC values do not change.
Thank you so much for your detailed explaintion.
I updated my repo with the proposed scheduler fix (cqi2 = 0;) as well as with Piotr's fix for the lte-cqi-generation test code here: http://code.nsnam.org/nbaldo/ns-3-bug2048/ List of FAILed tests: lte-cqa-ff-mac-scheduler lte-fdbet-ff-mac-scheduler lte-fdtbfq-ff-mac-scheduler lte-pss-ff-mac-scheduler lte-tdbet-ff-mac-scheduler lte-tdtbfq-ff-mac-scheduler Anyone with some spare cycles to have a further look at while the above tests still fail?
I have applied both patches from Nicola's repository (Piotr's fix for the test and Nicola's fix for schedulers) to the latest ns-3-dev code, I tested it, all tests pass. I guess that some bug fix in between solved also these schedulers tests failing issue. I proceeded and pushed these two changesets into: 12416:b6c94d1ded03 and 12417:f55df977de28. Thanks to Nicola, Zoraze and Piotr.
Ok, I was too optimistic. I didn't pull Nicola's patch for tests, as they seem to be added to Nicola's repo during the merge: http://code.nsnam.org/nbaldo/ns-3-bug2048/rev/76beac9fbf5f Thanks Zoraze for noticing this. Bug reopened.
I created a patch for schedulers and pushed it into: 12418:d6014b340a14, and I added Nicola's tests that I mentioned in the previous post. I slightly modified them and pushed into 12419:adcc54e11049. Basically, the issue was that it was missing in all these schedulers a check if CQI is non zero. I have added this patch, so schedulers will not schedule these UEs. Maybe we should think in future to add some additional checks in the model, e.g. when we try to obtain MCS from CQI that is 0. Currently, this function in lte-amc returns MCS=0, which is valid value for MCS, and should return some indication of invalid value CQI value, e.g. -1, or to catch this with some assert. However, this is independent topic, since the schedulers anyway must do their part of work and be aware of CQIs while scheduling.