Bug 1763

Summary:	Message 3 should be sent using the UL GRANT in the RAR
Product:	ns-3	Reporter:	Nicola Baldo <nicola>
Component:	lte	Assignee:	Nicola Baldo <nicola>
Status:	RESOLVED FIXED
Severity:	enhancement	CC:	mmiozzo, ns-bugs
Priority:	P5
Version:	ns-3-dev
Hardware:	PC
OS:	Linux

Description Nicola Baldo 2013-09-17 07:59:11 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.

Comment 1 Nicola Baldo 2013-09-17 08:10:50 UTC

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?

Comment 2 Marco Miozzo 2013-09-17 09:37:26 UTC

Why doesn't pass regularly through the scheduler as for allocating standard PUSCH TBs? Or am I missing something?!

Comment 3 Nicola Baldo 2013-09-17 12:13:19 UTC

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

Comment 4 Nicola Baldo 2013-09-18 04:26:28 UTC

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

Comment 5 Nicola Baldo 2013-11-08 11:33:58 UTC

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