Bugzilla – Bug 1660
Handover at certain subframe produces longer delay
Last modified: 2013-05-03 00:50:29 UTC
A typical handover takes around 5 ms in ideal RRC protocol and 20 ms in real (these are the time difference between LteEnbRrc/HandoverStart and LteEnbRrc/HandoverEndOk trace sources). But when the handover is started at a certain subframe, the time can extend to 6 ms longer. One way to observe the bug is by using the lena-x2-handover.cc example. Find the following line in the main function: // X2-based Handover lteHelper->HandoverRequest (Seconds (0.100), ueLteDevs.Get (0), enbLteDevs.Get (0), enbLteDevs.Get (1)); Then change the first argument to: {0.100, 0.101, 0.102, ..., 0.109}. This will vary the subframe to the all possible 10 subframes. Then run a simulation for each value. The LteEnbRrc/HandoverEndOk trace source will be fired on the following times: {0.119, 0.120, 0.121, 0.122, 0.123, 0.130, 0.131, 0.126, 0.127, 0.128}. Notice that the 6th and 7th entries show 6 ms longer time elapsed than the others. This behavior is found in the latest revision (as of the bug submission time) of lena-dev repository (a84215f782d6).
Created attachment 1579 [details] Proposed patch (changeset 9435:a84215f782d6 of lena-dev)
Created attachment 1580 [details] Test suite for the bug to verify handover delays in different subframes To be placed in src/lte/test and in wscript.
In my attempt to analyze, I found out that LteUePhy has discarded the RAR message because the RA RNTI that the UE expects and the RA RNTI that the RAR message has do not match (refer to LteUePhy::ReceiveLteControlMessageList function). I suspect the computation of RA RNTI of the RAR message is wrong, which is in LteEnbMac::DoSchedDlConfigInd. I attached my proposed fix, proposed-patch.diff, which is a simple fix of underflow check. I also attached a simple test script test-lte-random-access.cc which can be used for verification.
Hi Budi, thanks for the detailed bug report and the fix. I confirm both the buggy behaviour and the correctness of the patch (i.e., the fix in the determination of the RA-RNTI at the EnbMac). Also the test suite that you provided is very much appreciated. I am in principle ok with accepting this patch, however before doing this I would kindly ask you to do some further minor modifications: 1) for consistency, I suggest to rename LteRandomAccessTestSuite -> LteHandoverDelayTestSuite and test-lte-random-access -> test-lte-handover-delay 2) please add a new section in src/lte/doc/source/lte-testing.rst describing the new test that you added. Please cover in particular how the test vector (in your case, the max handover delay values) is determined, and what are the conditions upon which the test passes/fails. 3) please generate a complete patch including all the changes As a final note, since the bug also affects ns-3-dev, I think it is actually preferable to commit the change there first, so that it can be possibly included in the ns-3.17 release.
Created attachment 1583 [details] Complete patch (changeset 9736:da5e3a6c4029 of ns-3-dev) Hi Nicola, Please find attached the complete patch as you requested. One important note that I want to inform you is that the build of Sphinx wasn't successful. There were some errors because of missing figures, which I list down below: - lte-arch-data-rrc-pdcp-rlc.dia - lte-enb-architecture.dia - lte-ue-architecture.dia Those figures were deleted from ns-3-dev at changeset 9335. And I don't see those figures are used anywhere in the whole ns-3 source code. So I decided to modify doc/models/Makefile, deleting the entries of those figures. After that, the build for HTML ran successful, but the build for PDF failed for some other errors that I still have no clue at the moment. This is my first time building documentation, so maybe I did it incorrectly. I simply used "./waf sphinx". Please advise. -budi-
Also note that I didn't include my changes of doc/models/Makefile into the patch, because I'm not sure whether it would be the correct thing to do to fix this issue.
Thanks for the revised patch. I checked and I think it is ready for commit. Tom, what about pushing this now, so that it is included in ns-3.17? About the issue of the failure of "./waf sphinx", I've just filed it as a separate bug (the new Bug 1667). In fact, I think that it is not related with this patch: the errors occurs also before the patch, and the new section in the documentation added by Budi correctly show up when generating the stand-alone LTE documentation (e.g., with "cd src/lte/docs; make html").
(In reply to comment #7) > Thanks for the revised patch. I checked and I think it is ready for commit. > Tom, what about pushing this now, so that it is included in ns-3.17? Yes, please push it. > > About the issue of the failure of "./waf sphinx", I've just filed it as a > separate bug (the new Bug 1667). In fact, I think that it is not related with > this patch: the errors occurs also before the patch, and the new section in the > documentation added by Budi correctly show up when generating the stand-alone > LTE documentation (e.g., with "cd src/lte/docs; make html"). OK, please feel free to fix that also. I started to fix it and noticed there was a missing figure file referenced in the test but not there (lte-arch-ue-data).
changeset: 9738:972234cd8646