Bugzilla – Bug 1763
Message 3 should be sent using the UL GRANT in the RAR
Last modified: 2013-11-08 11:33:58 UTC
Message 3 (i.e., RRC CONNECTION REQUEST) should be sent using the UL GRANT contained in the MAC RAR, not the UL DCI, which is what's actually used. This can be reproduced with the test posted in Bug 1762 for the RngRun = 3 case. The symptom is that the LteRlcTm at the UE (LCID 0) will see a NotifyTxOpportunity only after receiving an UL DCI, which is allocated by the scheduler after receiving a Buffer Status Report (BSR) for LCID 0. Instead, the TxOpportunity shall be issued as a consequence of the UL GRANT reception (see lte-ue-phy.cc around line 810), and no BSR shall be issued for this case.
Marco, could you please take a look? I wonder if it could suffice to add a call to NotifyTxOpportunity of LCID 0 from within LteUeMac::RecvRaResponse() though I am not sure if in this way there would be a correct timing w.r.t. the previous call to QueueSubChannelsForTransmission() lte-ue-phy.cc around line 810 or maybe we could just create an UL DCI structure on the fly based on the UL GRANT in the RAR?
Why doesn't pass regularly through the scheduler as for allocating standard PUSCH TBs? Or am I missing something?!
after some private discussion with Marco we identified the fix, which I just pushed to lena-dev changeset: 10196:bf05b75cfcf7 tag: tip user: Nicola Baldo <nbaldo@cttc.es> date: Tue Sep 17 18:02:32 2013 +0200 summary: fixed Bug 1763 - Message 3 should be sent using the UL GRANT in the RAR will mark this as resolved if the fix is confirmed to be ok and after it gets merged into ns-3-dev
after applying the patch one test fails: FAIL: lte-rr-ff-mac-scheduler FAIL 15 UEs, distance 20000 m 11.320 Message: Unfair Throughput!, Condition: (double)dlDataRxed.at (i) / statsDuration (actual) < m_thrRefDl (limit) + m_thrRefDl * tolerance (tol) && (double)dlDataRxed.at (i) / statsDuration (actual) > m_thrRefDl (limit) - m_thrRefDl * tolerance (tol), Actual: 12800, Limit: 24320 +- 2432, File: ../src/lte/test/lte-test-rr-ff-mac-scheduler.cc, Line: 273
the RR scheduler issue was fixed in this change: changeset: 10199:80818f755bd9 user: Nicola Baldo <nbaldo@cttc.es> date: Tue Oct 08 19:09:36 2013 +0200 summary: lte-rr-ff-mac-scheduler test: consider that RR scheduler does not handle retx properly all the fixes related to this bug have been pushed to ns-3-dev