LTE module is not defining properly the MCS for the eNB?

[Rafael Fernandes Lopes]

Hi everyone!

I have been conducting some tests in an LTE network considering the following basic scenario:

UE <===> eNB <===> RemoteHost (RH)

I am using a simple OnOffApp for the tests. I have disabled the HARQ and CtrlErrorModel, and I am using the Friis model with a distance of 7000 m from UE to eNB (fixed positions). The Piro AMC model with 25 resource blocks are being used.

My OnOffApp is generating 35 Mbps. When the data are being sent from the UE to RH, the AMC model is being correctly executed (the CQI is transmitted and the MCS is correctly set). In this case, the throughput is limited to 4.88 Mbps, approximately...

However, when the data is sent from the RH to the UE, the throughput is 35 Mbps, what is not possible considering the number of resource blocks and the distance between UE and eNB! Firstly, I was thinking that this could be caused by the greater transmission power from the eNB, but the AMC should guarantee that both nodes (UE and eNB) use the same MCS! Furthermore, the theoretical limit of the throughput for the system is not working! Why the throughput is not being limited in this case?

I am using the FlowMonitor to calculate the throughput.

Best regards,

Rafael

[Tommaso Pecorella]

Hi,

it could be a mistake in your setup. Mind to share the script or shall we keep talking about hypothesis ?

T.

[Rafael Fernandes Lopes]

Hi Tommaso,

I am sending the code now. I though this could be a conceptual question about the framework, this is why I didn't send it before.

Best regards,

Rafael

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/9cTrKVxeoEg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at https://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

--

Rafael Fernandes Lopes

[Rafael Fernandes Lopes]

P.S. The distance between the UE and eNB is 0 in the script. However, the same results appear for big distances.

--

Rafael Fernandes Lopes
CV Lattes: http://lattes.cnpq.br/1972734433460838
=============================================================
Professor Adjunto

Departamento Acadêmico de Informática - DAI
Instituto Federal de Educação, Ciência e Tecnologia do Maranhão - IFMA
http://www.dai.ifma.edu.br

Pesquisador Associado
Instituto de Estudos Avançados em Comunicações - Iecom
http://www.iecom.org.br
=============================================================

[Marco Miozzo]

be careful using Friss propagation loss model, I remember it returns strange results (low losses, transmission till 20-25 km), I would suggest to try with a more realistic propagation loss model.

best,

marco.

You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.

[Tommaso Pecorella]

Perhaps we should check the Friis model ?

If it's unreliable, it must be fixed.

T.

[Marco Miozzo]

Friis model is ok, it should be a matter of LTE transmission parameters. Anyway, I would not suggest to use Friss for realistic LTE simulations, 3GPP suggests other models (Okumura-Hata, COST 231), all of them already included in ns3.

my two cents,

marco

[Rafael Fernandes Lopes]

Tommaso, any idea why this behaviour? In the code I attached, I can send data with 50 mbps in an 18 mbps channel (the same don't happens when the flow is from UE to RH).

Marco, this seems a problem in the AMC system of the eNB, independently of the loss model.

Regards,

Rafael.

[Tommaso Pecorella]

Tbh I have no idea. Yesterday I was way too sleepy to check.

I'd start by checking the number of RB allocated in the downlink. Then you could check the Rx part in the UE, and see what are the outcomes of the error model.

Hope this helps,

T.

[Marco Miozzo]

btw, the AMC model is currently tested by the tests on all schedulers (i.e., the MCS changes for different distance values, with Friss propagation model). I would suggest you to give a look to that tests.

my two cents,

marco.

[Rafael Fernandes Lopes]

Marco,

Apparently, the MCS is being correctly calculated... But not applied to the eNB, which does not affect the throughput...

Regards,

Rafael

[Rafael Fernandes Lopes]

Tommaso,

I am attaching two "DlMacStats" files: one for 0 m distance, and another for 8000 m distance. As can be seem, the MCS value is obtained, but it does not affect the throughput that cames from RemoteHost to UE... On the other hand, the traffic from UE to RemoteHost is correctly affected... Maybe the LTE module is not acting over the traffic from RemoteHost/PGW.

I have no clue from where to start searching in the LTE module code. Any ideas?

Best regards,

Rafael

[Zoraze Ali]

Hi Rafael,

Could you please try the following in your code and confirm your findings again,

//monitor = flowHelper.InstallAll(); *Comment this line in your code

  NodeContainer endpointNodes;
  endpointNodes.Add (ueNodes);
  endpointNodes.Add (remoteHost);
  monitor = flowHelper.Install(endpointNodes);

Regards,
Zoraze

[Tommaso Pecorella]

Hi Marco,

yes, the MCS seems to be affected by the distance change. What seems to be unaffected is the packet (L4) throughput, which is quite disturbing.

Could any of the LTE maintainers take a look at this ?

Thanks,

T.

[Biljana Bojović]

Hi Rafael, Tommasso, and all,

It seems to me that there is some issue in measuring throughput. I would suggest that you try what Zoraze suggested.

To double check, I measured throughput by using PacketSink function GetTotalRx(), and I got the following results:

-  distance=0, totalRx at UE = 20290800 bytes ~= 16.23 Mbps
-  distance=8000m, totalRx at UE = 2943720 bytes ~= 2.35 Mbps

Which is consistent with MAC DL stats that you provided:

- distance = 0, total bits in downlink ~= (2196*8) bits/ms ~= 17.5 Mbps
- distance = 8000m, total in downlink ~= (597*8) bits/ms ~= 4.76 Mbps

So, I would suggest to check if flow monitor in your script is configured properly.

Best regards,
Biljana

[Tommaso Pecorella]

Hi Biljana,

can you send me your script ? I'll triple check the FlowMonitor (I haven't spotted anything wrong in it so far).

Cheers,

T.

[Rafael Fernandes Lopes]

Hi Tomamaso, Marco and Biljana,

The results I got from FlowMonitor are confirmed by the Wireshark measurement from the PCAP. This script I sent is a simplification what me and my team are doing (we are using the tap-bridge and DCE) and the results are equal to those are shown in the script 've sent.

Regards,

Rafael.

[Biljana Bojović]

Hi Tommaso, 

here is the script.
 
Cheers,
Biljana

[Rafael Fernandes Lopes]

Another important detail about my problem is that using DCE/Tap-bridge I can't access the PacketSink object, because the application is not installed directly in the node...

Em 04/02/2016 12:35, "Biljana Bojović" <biljana...@gmail.com> escreveu:

Hi Tommaso, 

here is the script.
 
Cheers,
Biljana

[Rafael Fernandes Lopes]

Zoraze and all,

I have tested Zoraze's suggestion. The results are attached.

I really didn't understood the result.

Regards,

Rafael

[Rafael Fernandes Lopes]

Zoraze and all,

I have tested Zoraze's suggestion. The results are attached.

​

I really didn't understood the result.

Regards,

Rafael

[Rafael Fernandes Lopes]

Zoraze and all,

I have tested Zoraze's suggestion. The results are attached.

I really didn't understood the result.

Regards,

Rafael

[Tommaso Pecorella]

I don't know about the DCE / Tap problem, but I finally figured out what's going on with FlowMonitor: it's a bug.

LTE uses an IP over IP encapsulation and this is driving FlowMonitor crazy.

I'm trying to figure out how to fix it, I'll open a bug tracker for now.

T.

[Tommaso Pecorella]

Once you find the problem, fixing it isn't hard :)

Note: the application-level received bytes count is always less than the IP level, it's the IP + UDP overhead.

I'll iron out the patch and I'll push it in the next few ... minutes. Let's say half an hour max.

Cheers,

T.

00:40:23:~/Development/workspace/ns-3-dev pecos$ ./waf --run "scratch/lena-simple-epc-teste-bb --distance=8000"

Waf: Entering directory `/Users/pecos/Development/workspace/ns-3-dev/build'

[ 907/2412] Compiling scratch/lena-simple-epc-teste-bb.cc

[2378/2412] Linking build/scratch/lena-simple-epc-teste-bb

Waf: Leaving directory `/Users/pecos/Development/workspace/ns-3-dev/build'

Build commands will be stored in build/compile_commands.json

'build' finished successfully (10.508s)

ENB node: 0 position: 0:0:0

UE node: 0 position: 8000:0:0

 Total bytes received: 2943720

Distance: 8000

Flow 1 (1.0.0.2 -> 7.0.0.2)

  Tx Bytes:   63617996

  Rx Bytes:   2999412

  Throughput: 2.29255 Mbps

00:44:36:~/Development/workspace/ns-3-dev pecos$ ./waf --run "scratch/lena-simple-epc-teste-bb --distance=0"

Waf: Entering directory `/Users/pecos/Development/workspace/ns-3-dev/build'

Waf: Leaving directory `/Users/pecos/Development/workspace/ns-3-dev/build'

Build commands will be stored in build/compile_commands.json

'build' finished successfully (4.796s)

ENB node: 0 position: 0:0:0

UE node: 0 position: 0:0:0

 Total bytes received: 20290800

Distance: 0

Flow 1 (1.0.0.2 -> 7.0.0.2)

  Tx Bytes:   63617996

  Rx Bytes:   20674680

  Throughput: 15.7897 Mbps

00:45:53:~/Development/workspace/ns-3-dev pecos$ 

[Tommaso Pecorella]

Pushed right now on ns-3-dev.

Thanks for helping in finding this out !

Cheers,

T.

[Tommaso Pecorella]

The explanation is simple... and complex. If Zoraze really knew what was going on when he gave his suggestion, then he's a genius. An evil genius tho, because he knew and he didn't tell where the bug was.

Let me explain. LTE EPC uses an IP over IP encapsulation (beat me if I know why). This should not be an issue, and it isn't usually, except for FlowMonitor.

FlowMonitor uses ByteTags to keep track of outgoing, forwarded and incoming packets.

The problem is that you can add multiple ByteTags to one packet. When a packet is encapsulated it goes AGAIN through the outgoing tagging, receiving two tags.

Moreover, upon reception, the tag is removed twice. This, however, isn't the worst thing...

The first tag you find is the outer tag, so that one is used in both cases (ouch), complicating further everything.

Last but not least, what happens when you loose some fragments ? (because the outer IP is fragmented)... infinite headaches.

To make the long story short, all the numbers were wrong. 

The solution is simple: now the tags are checked against the relieved packet's IP numbers. If they don't match, the packet is not counted.

Cheers,

T.

[Manuel Requena]

In LTE/EPC, there is an application IP packet between the UE and and the remote host at the application layer. Then, the eNB (in uplink) and the PGW/SGW (in downlink) encapsulates this IP packet into an IP/SCTP/GTP packet. This is the S1 bearer (in the core network). Please, ask the 3GPP guys why this tunnneling :-)

Currently, if you install the flow monitor just in the UE and the remote host, the application IP packets are counted correctly. I think there is a bug in how the ByteTags are handled. There is no sense to have 2 identical ByteTags in the same packet or I'm wrong?

Manuel

NB: In the lte module, UDP is used instead of SCTP

[Konstantinos]

Hi Tommaso,

The solution that Zoraze proposed has been proposed quite a long time ago when installing FlowMonitor on all nodes (eNB included) caused assertions.

That was more than 3yr ago, e.g. https://groups.google.com/d/msg/ns-3-users/teE-cTfkV_Q/t2Bgq4ahJGQJ

I don't know if S1 bearer tunneling was implemented at that time or the addition of the tunneling fixed the assertion but generated the new bug.

The solution in both cases was however to install FlowMonitor only on the end points. 

K.

[Tommaso Pecorella]

Now I remember.

The bug Zoraze was referring to was fixed long time ago (previously FlowMonitor assumed that the L4 header was always present after an IP header).

This was a new thing, and it is fixed now. So it is perfectly safe to install FlowMonitor on all the nodes.

About why you can have more than one ByteTag of the same kind on a packet.... well, as a starting point you can use the same tag to mark different (non overlapping) bytes). However you can also use it to mark multiple times a bunch of bytes.

Let's suppose to have a packet, and this packet has been fragmented and reassembled. You want to track with tags some info about each fragment, but the fragment could contain overlapped bytes (possible in IPv4). This is an example of overlapping tags, and why you need multiple tags of the same kind.

Anyway both bugs are fixed, and now it's safe to use FlowMonitor on all the LTE nodes.

Cheers,

T.

PS: Manuel, I know 3GPP's guys are kinda crazy about tunneling stuff :)

[Rafael Fernandes Lopes]

Tommaso,

The fix is available in the development version?

Anyway, I have another doubts: why the throughput was so low when installing in the end nodes? And why the PCAP throughput was taking me wrong results?

Regards,

Rafael.

[Tommaso Pecorella]

Hi Rafael,

On Friday, February 5, 2016 at 9:38:31 PM UTC+1, Rafael Fernandes Lopes wrote:

Tommaso,

The fix is available in the development version?

Yes, it's live. Just update ns-3-dev and it's there.

 

Anyway, I have another doubts: why the throughput was so low when installing in the end nodes? And why the PCAP throughput was taking me wrong results?

Because PCAP is generated by CSMA or P2P devices, not by the UE (i.e., the LTE device). As a consequence, you see what's flowing in the EPC, but not what's being dropped by the eNB. Since the bottleneck is the eNB... dang :P

Cheers,

T.

[Rafael Fernandes Lopes]

Hmm... ok... What is strange for me is that the UDP transmissions with tap bridge are giving me the correct throughput results with the PCAP (18 mbps)... On the other hand, the TCP is giving me a very low throughput  (but compatible with the measured cwnd values). Those horrible results  (2 ~ 3 mbps), I am also taking with the native TCP implementation and flowmonitor...

Do you have any suggestion on how should I measure the throughput using the tap-bridge, since flow monitor is not available in this case?

Regards,

Rafael.

[Tommaso Pecorella]

The PCAP will be correct if you send the packets from the UE to the remote host (Uplink). In Downlink it would be correct if the PCAP would be there, but it's not.

What you can do is to develop a PacketSink-like application. It's very basic and anyone with a small knowledge of BSD sockets will make it in no more than 1 hour (including the debugging part).

Hope this helps,

T.