Throughput in lena-x2-handover-measures.cc

632 views
Skip to first unread message

muhamad arif azizi a

unread,
Nov 13, 2013, 11:09:37 PM11/13/13
to ns-3-...@googlegroups.com
HI All

i wanna ask about throughput in lena-x2-handover-measure.
when i use flow-monitor to see the throughput, there is no throughput for UE (no flow between UE and eNodeB), why?
could anybody explain to me ? please!

Best regards

Arif

Konstantinos

unread,
Nov 14, 2013, 4:44:42 AM11/14/13
to ns-3-...@googlegroups.com
Hi Arif,

If you look at the ns-3 documentation, http://www.nsnam.org/docs/models/html/lte-design.html#epc-data-plane, you can see why you get 0 throughput from UE to eNB when using FlowMonitor.

FlowMonitor captures end-to-end Layer3 (IP) traffic. There is no such traffic between a UE and the eNB in the LENA architecture.
If you want to measure that kind of traffic, use the tracing system it provides, http://www.nsnam.org/docs/models/html/lte-user.html#simulation-output

Madan Pande

unread,
Nov 14, 2013, 1:06:20 PM11/14/13
to ns-3-...@googlegroups.com
Hi,

      I have some concerns about the reply...

2. If one looks at the code, there is an Internet Stack on eNB, which is installed when AddEnb is done. Also with the latest Epc version, one can Install the Flowmon on eNB as well, albeit it is not documented or recommended as per user blog...What I did find is that on adding a UDP / TCP Flow to say lena-simple-epc with flowmon installed on eNB as well, the throughput suffers more but it is still present and can be seen with NetAnim...

3. IMHO, the issue reported on lena-x2-handover-measures giving zero throughput as shown in Flowmon has to have some other explanation. I had checked the lena-x2-measures with NetAnim and there is no packet flow shown either...???

4. These are my doubts too...

With Regards,
madan


Date: Thu, 14 Nov 2013 01:44:42 -0800
From: dinos.k...@gmail.com
To: ns-3-...@googlegroups.com
Subject: Re: Throughput in lena-x2-handover-measures.cc
--
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.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/groups/opt_out.

Konstantinos

unread,
Nov 14, 2013, 1:24:14 PM11/14/13
to ns-3-...@googlegroups.com


On Thursday, November 14, 2013 6:06:20 PM UTC, mador...@hotmail.com wrote:
Hi,

      I have some concerns about the reply...

2. If one looks at the code, there is an Internet Stack on eNB, which is installed when AddEnb is done. Also with the latest Epc version, one can Install the Flowmon on eNB as well, albeit it is not documented or recommended as per user blog...What I did find is that on adding a UDP / TCP Flow to say lena-simple-epc with flowmon installed on eNB as well, the throughput suffers more but it is still present and can be seen with NetAnim...

Your TCP/UDP flows are not from UE to eNB, but from UE to another UE or to a Remote Host. FlowMonitor works with the end points.
There is an internet stack in eNBs, that's why FlowMonitor may not crash, but as you can see in the LTE docs, the end-to-end logical link is not at the eNB.
I don't know if you put an application on the eNB and send traffic there what will happen. 
 

3. IMHO, the issue reported on lena-x2-handover-measures giving zero throughput as shown in Flowmon has to have some other explanation. I had checked the lena-x2-measures with NetAnim and there is no packet flow shown either...???

NetAnim has some limitations in representing LTE traffic, but I do not know exactly now what it can and want it can not show.
  • Animate packets over wired-links and wireless-links (Limited support for LTE traces)

Madan Pande

unread,
Nov 14, 2013, 11:02:49 PM11/14/13
to ns-3-...@googlegroups.com
Hi,
        Thank you for your answers..

 2.       Yes, the static routing is preset for the 7.* network, on which the UEs reside and the Sgw-Pgw node transfers packets from RH to them or between them (if using otherPort is used too). This much is okey...
There is already an application on eNB and another one on Sgw-Pgw
=======================================================
void
EpcEnbApplication::RecvFromLteSocket (Ptr<Socket> socket)
{
  NS_LOG_FUNCTION (this); 
  NS_ASSERT (socket == m_lteSocket);
  Ptr<Packet> packet = socket->Recv ();

  /// \internal
  /// Workaround for \bugid{231}
  SocketAddressTag satag;
  packet->RemovePacketTag (satag);

  EpsBearerTag tag;
  bool found = packet->RemovePacketTag (tag);
  NS_ASSERT (found);
  uint16_t rnti = tag.GetRnti ();
  uint8_t bid = tag.GetBid ();
  NS_LOG_LOGIC ("received packet with RNTI=" << (uint32_t) rnti << ", BID=" << (uint32_t)  bid);
  std::map<uint16_t, std::map<uint8_t, uint32_t> >::iterator rntiIt = m_rbidTeidMap.find (rnti);
  if (rntiIt == m_rbidTeidMap.end ())
    {
      NS_LOG_WARN ("UE context not found, discarding packet");
    }
  else
    {
      std::map<uint8_t, uint32_t>::iterator bidIt = rntiIt->second.find (bid);
      NS_ASSERT (bidIt != rntiIt->second.end ());
      uint32_t teid = bidIt->second;
      SendToS1uSocket (packet, teid);
    }
}

void
EpcEnbApplication::RecvFromS1uSocket (Ptr<Socket> socket)
{
  NS_LOG_FUNCTION (this << socket); 
  NS_ASSERT (socket == m_s1uSocket);
  Ptr<Packet> packet = socket->Recv ();
  GtpuHeader gtpu;
  packet->RemoveHeader (gtpu);
  uint32_t teid = gtpu.GetTeid ();
  std::map<uint32_t, EpsFlowId_t>::iterator it = m_teidRbidMap.find (teid);
  NS_ASSERT (it != m_teidRbidMap.end ());

  /// \internal
  /// Workaround for \bugid{231}
  SocketAddressTag tag;
  packet->RemovePacketTag (tag);
 
  SendToLteSocket (packet, it->second.m_rnti, it->second.m_bid);
}

void
EpcEnbApplication::SendToLteSocket (Ptr<Packet> packet, uint16_t rnti, uint8_t bid)
{
  NS_LOG_FUNCTION (this << packet << rnti << (uint16_t) bid << packet->GetSize ()); 
  EpsBearerTag tag (rnti, bid);
  packet->AddPacketTag (tag);
  int sentBytes = m_lteSocket->Send (packet);
  NS_ASSERT (sentBytes > 0);
}


void
EpcEnbApplication::SendToS1uSocket (Ptr<Packet> packet, uint32_t teid)
{
  NS_LOG_FUNCTION (this << packet << teid <<  packet->GetSize ()); 
  GtpuHeader gtpu;
  gtpu.SetTeid (teid);
  // From 3GPP TS 29.281 v10.0.0 Section 5.1
  // Length of the payload + the non obligatory GTP-U header
  gtpu.SetLength (packet->GetSize () + gtpu.GetSerializedSize () - 8); 
  packet->AddHeader (gtpu);
  uint32_t flags = 0;
  m_s1uSocket->SendTo (packet, flags, InetSocketAddress(m_sgwS1uAddress, m_gtpuUdpPort));
}
===========================================================


3. By that reasoning (appearing valid though), EPC working in NS-3 Simulator. appears confusing...some  questions that I would like to have answers for then are:

a) Is it due to the lack of actual Radio link between eNB and UEs, that the test script for e2e in lte test dir uses a Wifi config, ???

b) if we are doing data transfers with static routing to and fro with UEs under EPC too, then really speaking what advantage have we gained from the earlier LTE module in older NS-3 (ns-3.13), which used to have a lte-multiple-flows.cc example that used to work fine, in the "data-only" config??? is it only the tft and qos spec addition?

c) In the documentation for ns-3 lte module we show the Radio links, so when would do they come in to play in an Epc simulation ... (say in lena-simple-epc.cc or lena-dual-stripe) ?? Is it only for explanatory purposes of EPC and not for simulation of LTE in NS-3??? Ouch ! this would be disturbing...

d) What then is then being achieved by setting Earfcn or Bandwidth, if really no path via eNB comes in to play??? and alternatively, in which cases it does so pl?

With Thanks and Regards,
madan


Date: Thu, 14 Nov 2013 10:24:14 -0800

Madan Pande

unread,
Nov 17, 2013, 10:39:14 PM11/17/13
to ns-3-...@googlegroups.com, Kostantinos Katsaros
Konstantinos,

     To conclude, my take is that the settings for Earfcn and Bandwidth primarily come in to play in simulating the propagation and allied losses, and ofcourse in the real case of using two laptops  having LTE Air interface cards...(albeit drivers may require interfacing for such cards)...

2.For the rest, the packets from Sgw travel via the gtpu interface and are delivered to the LteSocket ...(in NS-2 it is an Air Queue...incidently) and on the return go back to the destinations (another UE or via Sgw to RH) again following the same LteSocket-gtpu tunnel [and p2p] network... Please correct me if I am wrong...

Konstantinos

unread,
Nov 18, 2013, 5:07:03 AM11/18/13
to ns-3-...@googlegroups.com, Kostantinos Katsaros
Dear Madan,

I am not an LTE expert. I will leave this questions to Nicola or Marco.

Regards,
K.
Reply all
Reply to author
Forward
0 new messages