Bug 1508

Summary:	too aggressive AMC results in 100% RLC PDU loss
Product:	ns-3	Reporter:	Nicola Baldo <nicola>
Component:	lte	Assignee:	Marco Miozzo <mmiozzo>
Status:	RESOLVED FIXED
Severity:	normal	CC:	nicola, ns-bugs
Priority:	P5
Version:	ns-3-dev
Hardware:	All
OS:	All
Attachments:	Simulation script for 97 m scenario. Throughput example graph after bug-fix Simulation script for throughput testing after bug-fix

Description Nicola Baldo 2012-10-04 08:11:12 UTC

See this thread by Longhao on ns-3-users:
https://groups.google.com/d/topic/ns-3-users/lZBKbPVUtto/discussion

and in particular look at the throughput figure first, and then at the MAC and RLC stats results for the 97m simulation.

I suspect that the AMC is too aggressive at 97m, so it still chooses MCS 28 when it should actually go for a lower MCS.

Comment 1 Nicola Baldo 2012-10-04 08:11:57 UTC

Marco, could you please take a look at this?

Comment 2 Marco Miozzo 2012-10-08 06:46:15 UTC

Created attachment 1453 [details]
Simulation script for 97 m scenario.

Comment 3 Marco Miozzo 2012-10-08 06:47:07 UTC

It's quite strange, cause I've tried to run the simulation script for distances equal to 97, 98 and 99, and in the simulation the error rate is mostly 0. I used the same simulation script, I've just modified the first position in order to speed up the test (I do not have with me a machine with enough performance for running the whole scenario), in attachment the script I used.

Comment 4 Nicola Baldo 2012-10-17 10:52:19 UTC

I confirm what said by Marco, the 97m script works ok. I tested it both with ns-3-dev changeset:   9109:a09a1899429d and with lena-dev changeset:   9070:db6d857a07f0. 

Hence, I am closing this bug as invalid. If someone can provide a simulation program that reproduce this bug, we can reopen it.

Comment 5 Marco Miozzo 2013-01-25 04:19:34 UTC

After further tests I've found the problem, in the configuration of the script I've been using the problem appears at 300 m. instead of 97. There was a bug in lte.amc.cc in the selection of the CQI when using MCS 27 and 28. 
The bug has been solved in lena-dev repository, changeset:   9401:50fa71b511ed.

Now still remains one minor slope variations around 270 m. (see thr.eps) which is due to the fact that in this region the BLER of the RBG (which is the one used for evaluating the CQIs) is very close to 0.1 and when a UE sends a TB with 50 RBs the TB error rate increases. In fact, the codeblocks involved in the actual transmission are more than the ones used in the BLER evaluation of the single RBG (6 codeblocks instead of 2), which implies that the resulting combined BLER for a TB of 50 RBs is greater then the one of the single RBG (3 RBs) and pass the 0.1 threshold.

In attachment I've put also the simulation script updated to the latest version of lena I've used for generating the graph (lteepc-moving-ue-4-new.cc).

For porting the bug-fix in standard ns3, you have to refer to lte-amc.cc file, we are going to do it asap, jointly with new code.

Comment 6 Marco Miozzo 2013-01-25 04:23:40 UTC

Created attachment 1503 [details]
Throughput example graph after bug-fix

Throughput figure after bug-fix.

Comment 7 Marco Miozzo 2013-01-25 04:26:26 UTC

Created attachment 1504 [details]
Simulation script for throughput testing after bug-fix

New simulation script for testing throughput after bug fixing.

Comment 8 Nicola Baldo 2013-02-01 09:43:48 UTC

Thanks Marco for the fix and the further testing. I am reopening this just because the patch is on the LENA dev tree only, and hence the bug is still present in ns-3-dev. I propose to leave it open until the latest LENA code is merged with ns-3-dev.

Comment 9 Nicola Baldo 2013-04-30 09:30:51 UTC

the fix was included in ns-3-dev with the recent LENA merge