LTE downlink transport blocks received at UE's Phy layer but dropped at RLC layer.

Akhila Rao

unread,

Aug 24, 2017, 10:22:06 AM8/24/17

to ns-3-users

Hi,

I have an LTE network with one eNodeB and a few (I tried 5- 20) UEs. All UEs are in coverage region of the eNodeB. A remote host connected to the eNodeB sends data flows to each UE. I am using the MyApp traffic generator example shown in examples/tutorials/fifth.cc to generate pkts with random inter-pkt delay. I have enabled trace sources and observe the trace source saved by default as "DlRxPhyStats.txt". I see that almost all pkts transmitted at eNodeB are being received at the Phy layer without error. I know this by looking at the correct bit in the trace file. So far so good . . But when I look at the trace file "DlRlcStats.txt" , the PDU drop rate is in the range 0.4-1.0 with the average being around 0.7. So this means that a lot of transport blocks were received at the Phy layer of the UE but were dropped by the RLC layer of the UE. Why would this happen ? The input data rate of the flow to each UE is 1.5Mbps.

What am I missing ?

Always grateful for help

Regards

Akhila

Biljana Bojović

unread,

Aug 24, 2017, 10:31:28 AM8/24/17

to ns-3-users

I guess that you are using RLC UM. Can you check what is the RLC buffer size in your configuration and try to dimension it according to your scenario?

Cheers,
Biljana

Akhila Rao

unread,

Aug 24, 2017, 10:38:33 AM8/24/17

to ns-3-...@googlegroups.com

Hi,

Yes I am using RLC UM. But I would be surprised if the buffer overflowed for a 1.5 Mbps data stream. Could you please explain which higher layer could delay the processing to cause this buffer overflow ? While I attempt to observe the buffer occupancy. . .

I use the PacketSinkHelper to install a sink on each UE node.

Thank you for the quick reply.

Regards

Akhila

--
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/UbrCu6Mr5TE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+unsubscribe@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.

--

Regards

Akhila

Biljana Bojović

unread,

Aug 24, 2017, 10:57:07 AM8/24/17

to ns-3-users

Can you share these trace files (PHY and RLC)?

Thanks,
Biljana

On Thursday, August 24, 2017 at 4:38:33 PM UTC+2, Akhila Rao wrote:

Hi,

Yes I am using RLC UM. But I would be surprised if the buffer overflowed for a 1.5 Mbps data stream. Could you please explain which higher layer could delay the processing to cause this buffer overflow ? While I attempt to observe the buffer occupancy. . .
I use the PacketSinkHelper to install a sink on each UE node.

Thank you for the quick reply.
Regards
Akhila

On 24 August 2017 at 16:31, Biljana Bojović <biljana...@gmail.com> wrote:

I guess that you are using RLC UM. Can you check what is the RLC buffer size in your configuration and try to dimension it according to your scenario?

Cheers,
Biljana

On Thursday, August 24, 2017 at 4:22:06 PM UTC+2, Akhila Rao wrote:
Hi,

I have an LTE network with one eNodeB and a few (I tried 5- 20) UEs. All UEs are in coverage region of the eNodeB. A remote host connected to the eNodeB sends data flows to each UE. I am using the MyApp traffic generator example shown in examples/tutorials/fifth.cc to generate pkts with random inter-pkt delay. I have enabled trace sources and observe the trace source saved by default as "DlRxPhyStats.txt". I see that almost all pkts transmitted at eNodeB are being received at the Phy layer without error. I know this by looking at the correct bit in the trace file. So far so good . . But when I look at the trace file "DlRlcStats.txt" , the PDU drop rate is in the range 0.4-1.0 with the average being around 0.7. So this means that a lot of transport blocks were received at the Phy layer of the UE but were dropped by the RLC layer of the UE. Why would this happen ? The input data rate of the flow to each UE is 1.5Mbps.

What am I missing ?

Always grateful for help
Regards
Akhila

--
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/UbrCu6Mr5TE/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.

--
Regards
Akhila

Akhila Rao

unread,

Aug 24, 2017, 11:04:37 AM8/24/17

to ns-3-users

Yes. Here they are.

Meanwhile I am trying to observe the trace source

Config::Connect ("/NodeList/*/DeviceList/*/LteUeRrc/DataRadioBearerMap/*/LteRlc/RxPDU",
MakeBoundCallback (&Lte_RlcDlRxPDU, rlcRxstream));

To see if it matches what I got for each epoch using the RlcStatsCalculator (It writes into DlRlcStats.txt file).

Thank you

Regards

Akhila

DlRxPhyStats.txt

DlRlcStats.txt

Akhila Rao

unread,

Aug 24, 2017, 11:39:58 AM8/24/17

to ns-3-users

Hi Biljana,

I checked the trace logs from the config path I mentioned before

Config::Connect ("/NodeList/*/DeviceList/*/LteUeRrc/DataRadioBearerMap/*/LteRlc/RxPDU",
MakeBoundCallback (&Lte_RlcDlRxPDU, rlcRxstream));

Its trace log is attached as "dlRlcRx.txt". The column headings are (time_micro_s, ue_id, lcid, pkt_size_Bytes, delay)

The values for measured RLC throughput I see from this file "dlRlcRx.txt" is different from what I see in "DlRlcStats.txt". It does not seem to have the problem of pkts received at Phy but dropped at RLC. However, I notice that out of the 5 UEs that were part of the simulation, this file only reports entries for 4 of them (UE ID 6 is missing !). I remember now that this is the reason I shifted to using RadioBearerStatsCollector that prints in "DlRlcStats.txt" in the first place !!! This seems like such a mess !

Super confused

Regards

Akhila

Ok.

dlRlcRx.txt

Biljana Bojović

unread,

Aug 24, 2017, 12:29:58 PM8/24/17

to ns-3-users

It seems that UE with ID 6 does not get to connect. Did you randomize the start of applications?

Cheers,
Biljana

Akhila Rao

unread,

Aug 24, 2017, 12:46:31 PM8/24/17

to ns-3-...@googlegroups.com

Yes. I tried that. This is my traffic source and sink code

for (uint32_t u = 0; u < ueNodes.GetN (); ++u)

{

Ptr<UniformRandomVariable> uv = CreateObject<UniformRandomVariable> ();

uint16_t trafficClass = trafficClass_array[u];

PacketSinkHelper serverHelper ("ns3::UdpSocketFactory", InetSocketAddress (Ipv4Address::GetAny (), dlPort));

serverApps.Add (serverHelper.Install (ueNodes.Get(u)));

Address sinkAddress (InetSocketAddress (ueIpIface.GetAddress (u), dlPort));

Ptr<Socket> ns3UdpSocket = Socket::CreateSocket (remoteHost, UdpSocketFactory::GetTypeId ());

Ptr<MyApp> dlClient = CreateObject<MyApp> ();

dlClient->Setup (ns3UdpSocket, sinkAddress,

packetLengths[trafficClass], num_pkts_to_send, DataRate (bitRates[trafficClass]));

remoteHost->AddApplication (dlClient);

dlClient->SetStartTime (Seconds (uv->GetValue(1.0,3.0)));

}

I enabled logging on lte-rlc.cc

export NS_LOG=LteRlc=level_all

I increased the number of UEs in the simulation as 2, 3, 4, 5.

For #UEs = 2,3,4 all UEs have entries in the dlRlcRx.txt file. But when increased to 5, one of them is missed.

The log prints also look suspicious. When a UE does not get added to the trace, I see that there is an LteRlc:DoDispose as soon as I start the simulation, which should not happen till the end of simulation. In case of #UEs 2,3,4 I do not see this DoDispose till the end of simulation.

This is what I see as soon as I start the simulation when #UEs = 5

'build' finished successfully (4.032s)

LteRlc:LteRlc(0x24e3c50)

LteRlc:SetLteMacSapProvider(0x24e3c50, 0x24e3050)

LteRlc:SetRnti(0x24e3c50, 0)

LteRlc:SetLcId(0x24e3c50, 0)

LteRlc:GetLteRlcSapProvider(0x24e3c50)

LteRlc:GetLteMacSapUser(0x24e3c50)

LteRlc:LteRlc(0x24e6ed0)

LteRlc:SetLteMacSapProvider(0x24e6ed0, 0x24e62d0)

LteRlc:SetRnti(0x24e6ed0, 0)

LteRlc:SetLcId(0x24e6ed0, 0)

LteRlc:GetLteRlcSapProvider(0x24e6ed0)

LteRlc:GetLteMacSapUser(0x24e6ed0)

LteRlc:LteRlc(0x24e9c40)

LteRlc:SetLteMacSapProvider(0x24e9c40, 0x24e9040)

LteRlc:SetRnti(0x24e9c40, 0)

LteRlc:SetLcId(0x24e9c40, 0)

LteRlc:GetLteRlcSapProvider(0x24e9c40)

LteRlc:GetLteMacSapUser(0x24e9c40)

LteRlc:LteRlc(0x24eca30)

LteRlc:SetLteMacSapProvider(0x24eca30, 0x24ebe30)

LteRlc:SetRnti(0x24eca30, 0)

LteRlc:SetLcId(0x24eca30, 0)

LteRlc:GetLteRlcSapProvider(0x24eca30)

LteRlc:GetLteMacSapUser(0x24eca30)

LteRlc:LteRlc(0x24ef810)

LteRlc:SetLteMacSapProvider(0x24ef810, 0x24eec10)

LteRlc:SetRnti(0x24ef810, 0)

LteRlc:SetLcId(0x24ef810, 0)

LteRlc:GetLteRlcSapProvider(0x24ef810)

LteRlc:GetLteMacSapUser(0x24ef810)

LteRlc:LteRlc(0x2529160)

LteRlc:SetLteMacSapProvider(0x2529160, 0x24d9880)

LteRlc:SetRnti(0x2529160, 1)

LteRlc:SetLcId(0x2529160, 0)

LteRlc:GetLteMacSapUser(0x2529160)

LteRlc:LteRlc(0x252d1e0)

LteRlc:SetLteMacSapProvider(0x252d1e0, 0x24d9880)

LteRlc:SetRnti(0x252d1e0, 1)

LteRlc:SetLcId(0x252d1e0, 1)

LteRlc:GetLteRlcSapProvider(0x252d1e0)

LteRlc:SetLteRlcSapUser(0x252d1e0, 0x24c0ce0)

LteRlc:GetLteMacSapUser(0x252d1e0)

LteRlc:GetLteRlcSapProvider(0x2529160)

LteRlc:LteRlc(0x24dd790)

LteRlc:SetLteMacSapProvider(0x24dd790, 0x24d9880)

LteRlc:SetRnti(0x24dd790, 2)

LteRlc:SetLcId(0x24dd790, 0)

LteRlc:GetLteMacSapUser(0x24dd790)

LteRlc:LteRlc(0x2535d90)

LteRlc:SetLteMacSapProvider(0x2535d90, 0x24d9880)

LteRlc:SetRnti(0x2535d90, 2)

LteRlc:SetLcId(0x2535d90, 1)

LteRlc:GetLteRlcSapProvider(0x2535d90)

LteRlc:SetLteRlcSapUser(0x2535d90, 0x24c0e70)

LteRlc:GetLteMacSapUser(0x2535d90)

LteRlc:GetLteRlcSapProvider(0x24dd790)

LteRlc:LteRlc(0x253f330)

LteRlc:SetLteMacSapProvider(0x253f330, 0x24d9880)

LteRlc:SetRnti(0x253f330, 3)

LteRlc:SetLcId(0x253f330, 0)

LteRlc:GetLteMacSapUser(0x253f330)

LteRlc:LteRlc(0x253e870)

LteRlc:SetLteMacSapProvider(0x253e870, 0x24d9880)

LteRlc:SetRnti(0x253e870, 3)

LteRlc:SetLcId(0x253e870, 1)

LteRlc:GetLteRlcSapProvider(0x253e870)

LteRlc:SetLteRlcSapUser(0x253e870, 0x2484220)

LteRlc:GetLteMacSapUser(0x253e870)

LteRlc:GetLteRlcSapProvider(0x253f330)

LteRlc:LteRlc(0x2547f70)

LteRlc:SetLteMacSapProvider(0x2547f70, 0x24d9880)

LteRlc:SetRnti(0x2547f70, 4)

LteRlc:SetLcId(0x2547f70, 0)

LteRlc:GetLteMacSapUser(0x2547f70)

LteRlc:LteRlc(0x25474b0)

LteRlc:SetLteMacSapProvider(0x25474b0, 0x24d9880)

LteRlc:SetRnti(0x25474b0, 4)

LteRlc:SetLcId(0x25474b0, 1)

LteRlc:GetLteRlcSapProvider(0x25474b0)

LteRlc:SetLteRlcSapUser(0x25474b0, 0x24d1dc0)

LteRlc:GetLteMacSapUser(0x25474b0)

LteRlc:GetLteRlcSapProvider(0x2547f70)

LteRlc:LteRlc(0x2550bb0)

LteRlc:SetLteMacSapProvider(0x2550bb0, 0x24d9880)

LteRlc:SetRnti(0x2550bb0, 5)

LteRlc:SetLcId(0x2550bb0, 0)

LteRlc:GetLteMacSapUser(0x2550bb0)

LteRlc:LteRlc(0x25500f0)

LteRlc:SetLteMacSapProvider(0x25500f0, 0x24d9880)

LteRlc:SetRnti(0x25500f0, 5)

LteRlc:SetLcId(0x25500f0, 1)

LteRlc:GetLteRlcSapProvider(0x25500f0)

LteRlc:SetLteRlcSapUser(0x25500f0, 0x24db460)

LteRlc:GetLteMacSapUser(0x25500f0)

LteRlc:GetLteRlcSapProvider(0x2550bb0)

LteRlc:SetRnti(0x24e3c50, 3)

LteRlc:SetRnti(0x24e6ed0, 1)

LteRlc:SetRnti(0x24e9c40, 4)

LteRlc:SetRnti(0x24ef810, 2)

LteRlc:LteRlc(0x2559cb0)

LteRlc:SetLteMacSapProvider(0x2559cb0, 0x24d9880)

LteRlc:SetRnti(0x2559cb0, 3)

LteRlc:SetLcId(0x2559cb0, 3)

LteRlc:GetLteRlcSapProvider(0x2559cb0)

LteRlc:SetLteRlcSapUser(0x2559cb0, 0x24ff2b0)

LteRlc:GetLteMacSapUser(0x2559cb0)

LteRlc:LteRlc(0x255a7f0)

LteRlc:SetLteMacSapProvider(0x255a7f0, 0x24d9880)

LteRlc:SetRnti(0x255a7f0, 1)

LteRlc:SetLcId(0x255a7f0, 3)

LteRlc:GetLteRlcSapProvider(0x255a7f0)

LteRlc:SetLteRlcSapUser(0x255a7f0, 0x24f05d0)

LteRlc:GetLteMacSapUser(0x255a7f0)

LteRlc:LteRlc(0x255ab30)

LteRlc:SetLteMacSapProvider(0x255ab30, 0x24d9880)

LteRlc:SetRnti(0x255ab30, 4)

LteRlc:SetLcId(0x255ab30, 3)

LteRlc:GetLteRlcSapProvider(0x255ab30)

LteRlc:SetLteRlcSapUser(0x255ab30, 0x2421f50)

LteRlc:GetLteMacSapUser(0x255ab30)

LteRlc:LteRlc(0x255aef0)

LteRlc:SetLteMacSapProvider(0x255aef0, 0x24d9880)

LteRlc:SetRnti(0x255aef0, 2)

LteRlc:SetLcId(0x255aef0, 3)

LteRlc:GetLteRlcSapProvider(0x255aef0)

LteRlc:SetLteRlcSapUser(0x255aef0, 0x252a3a0)

LteRlc:GetLteMacSapUser(0x255aef0)

LteRlc:LteRlc(0x255b320)

LteRlc:SetLteMacSapProvider(0x255b320, 0x24e3050)

LteRlc:SetRnti(0x255b320, 3)

LteRlc:SetLcId(0x255b320, 1)

LteRlc:GetLteRlcSapProvider(0x255b320)

LteRlc:SetLteRlcSapUser(0x255b320, 0x2421fa0)

LteRlc:GetLteMacSapUser(0x255b320)

LteRlc:GetLteRlcSapProvider(0x24e3c50)

LteRlc:LteRlc(0x2563530)

LteRlc:SetLteMacSapProvider(0x2563530, 0x24e3050)

LteRlc:SetRnti(0x2563530, 3)

LteRlc:SetLcId(0x2563530, 3)

LteRlc:GetLteRlcSapProvider(0x2563530)

LteRlc:SetLteRlcSapUser(0x2563530, 0x2528540)

LteRlc:GetLteMacSapUser(0x2563530)

LteRlc:LteRlc(0x2563680)

LteRlc:SetLteMacSapProvider(0x2563680, 0x24e62d0)

LteRlc:SetRnti(0x2563680, 1)

LteRlc:SetLcId(0x2563680, 1)

LteRlc:GetLteRlcSapProvider(0x2563680)

LteRlc:SetLteRlcSapUser(0x2563680, 0x2444d80)

LteRlc:GetLteMacSapUser(0x2563680)

LteRlc:GetLteRlcSapProvider(0x24e6ed0)

LteRlc:LteRlc(0x256b890)

LteRlc:SetLteMacSapProvider(0x256b890, 0x24e62d0)

LteRlc:SetRnti(0x256b890, 1)

LteRlc:SetLcId(0x256b890, 3)

LteRlc:GetLteRlcSapProvider(0x256b890)

LteRlc:SetLteRlcSapUser(0x256b890, 0x242ef60)

LteRlc:GetLteMacSapUser(0x256b890)

LteRlc:LteRlc(0x256bb20)

LteRlc:SetLteMacSapProvider(0x256bb20, 0x24e9040)

LteRlc:SetRnti(0x256bb20, 4)

LteRlc:SetLcId(0x256bb20, 1)

LteRlc:GetLteRlcSapProvider(0x256bb20)

LteRlc:SetLteRlcSapUser(0x256bb20, 0x24c7d30)

LteRlc:GetLteMacSapUser(0x256bb20)

LteRlc:GetLteRlcSapProvider(0x24e9c40)

LteRlc:LteRlc(0x2573d30)

LteRlc:SetLteMacSapProvider(0x2573d30, 0x24e9040)

LteRlc:SetRnti(0x2573d30, 4)

LteRlc:SetLcId(0x2573d30, 3)

LteRlc:GetLteRlcSapProvider(0x2573d30)

LteRlc:SetLteRlcSapUser(0x2573d30, 0x24ff1e0)

LteRlc:GetLteMacSapUser(0x2573d30)

LteRlc:LteRlc(0x25740d0)

LteRlc:SetLteMacSapProvider(0x25740d0, 0x24eec10)

LteRlc:SetRnti(0x25740d0, 2)

LteRlc:SetLcId(0x25740d0, 1)

LteRlc:GetLteRlcSapProvider(0x25740d0)

LteRlc:SetLteRlcSapUser(0x25740d0, 0x24d9630)

LteRlc:GetLteMacSapUser(0x25740d0)

LteRlc:GetLteRlcSapProvider(0x24ef810)

LteRlc:LteRlc(0x257c2e0)

LteRlc:SetLteMacSapProvider(0x257c2e0, 0x24eec10)

LteRlc:SetRnti(0x257c2e0, 2)

LteRlc:SetLcId(0x257c2e0, 3)

LteRlc:GetLteRlcSapProvider(0x257c2e0)

LteRlc:SetLteRlcSapUser(0x257c2e0, 0x24c7c20)

LteRlc:GetLteMacSapUser(0x257c2e0)

LteRlc:LteRlc(0x2583be0)

LteRlc:SetLteMacSapProvider(0x2583be0, 0x24d9880)

LteRlc:SetRnti(0x2583be0, 6)

LteRlc:SetLcId(0x2583be0, 0)

LteRlc:GetLteMacSapUser(0x2583be0)

LteRlc:LteRlc(0x2583d50)

LteRlc:SetLteMacSapProvider(0x2583d50, 0x24d9880)

LteRlc:SetRnti(0x2583d50, 6)

LteRlc:SetLcId(0x2583d50, 1)

LteRlc:GetLteRlcSapProvider(0x2583d50)

LteRlc:SetLteRlcSapUser(0x2583d50, 0x2583a60)

LteRlc:GetLteMacSapUser(0x2583d50)

LteRlc:GetLteRlcSapProvider(0x2583be0)

LteRlc:SetRnti(0x24eca30, 6)

LteRlc:LteRlc(0x258dba0)

LteRlc:SetLteMacSapProvider(0x258dba0, 0x24d9880)

LteRlc:SetRnti(0x258dba0, 6)

LteRlc:SetLcId(0x258dba0, 3)

LteRlc:GetLteRlcSapProvider(0x258dba0)

LteRlc:SetLteRlcSapUser(0x258dba0, 0x257e8b0)

LteRlc:GetLteMacSapUser(0x258dba0)

LteRlc:LteRlc(0x258e1d0)

LteRlc:SetLteMacSapProvider(0x258e1d0, 0x24ebe30)

LteRlc:SetRnti(0x258e1d0, 6)

LteRlc:SetLcId(0x258e1d0, 1)

LteRlc:GetLteRlcSapProvider(0x258e1d0)

LteRlc:SetLteRlcSapUser(0x258e1d0, 0x24fec80)

LteRlc:GetLteMacSapUser(0x258e1d0)

LteRlc:GetLteRlcSapProvider(0x24eca30)

LteRlc:LteRlc(0x25963e0)

LteRlc:SetLteMacSapProvider(0x25963e0, 0x24ebe30)

LteRlc:SetRnti(0x25963e0, 6)

LteRlc:SetLcId(0x25963e0, 3)

LteRlc:GetLteRlcSapProvider(0x25963e0)

LteRlc:SetLteRlcSapUser(0x25963e0, 0x258ced0)

LteRlc:GetLteMacSapUser(0x25963e0)

LteRlc:DoDispose(0x25500f0)

LteRlc:~LteRlc(0x25500f0)

LteRlc:DoDispose(0x2550bb0)

LteRlc:~LteRlc(0x2550bb0)

To unsubscribe from this group and all its topics, send an email to ns-3-users+unsubscribe@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.

--

Regards

Akhila

Biljana Bojović

unread,

Aug 24, 2017, 12:52:01 PM8/24/17

to ns-3-users

Ok, this seems fine to me. Please check alos the RRC logs, what happens with UE 5, does it enter CONNECTED_NORMALLY state?

Akhila Rao

unread,

Aug 24, 2017, 1:09:40 PM8/24/17

to ns-3-...@googlegroups.com

No. UE with IMSI = 4 does not show CONNECTED_NORMALLY

New Data Radio Bearer

LteUeRrc:SwitchToState(0x1bcf180, "CONNECTED_NORMALLY")

0x1bcf180 IMSI 1 RNTI 3 UeRrc IDLE_CONNECTING --> CONNECTED_NORMALLY

LteUeRrc:DoRecvRrcConnectionSetup(0x1bd2400, " RNTI ", 1)

LteUeRrc:ApplyRadioResourceConfigDedicated(0x1bd2400)

0x1bd2400 IMSI 2 adding/modifying DRBID 1 LC 3

New Data Radio Bearer

LteUeRrc:SwitchToState(0x1bd2400, "CONNECTED_NORMALLY")

0x1bd2400 IMSI 2 RNTI 1 UeRrc IDLE_CONNECTING --> CONNECTED_NORMALLY

LteUeRrc:DoRecvRrcConnectionSetup(0x1bd5170, " RNTI ", 4)

LteUeRrc:ApplyRadioResourceConfigDedicated(0x1bd5170)

0x1bd5170 IMSI 3 adding/modifying DRBID 1 LC 3

New Data Radio Bearer

LteUeRrc:SwitchToState(0x1bd5170, "CONNECTED_NORMALLY")

0x1bd5170 IMSI 3 RNTI 4 UeRrc IDLE_CONNECTING --> CONNECTED_NORMALLY

LteUeRrc:DoRecvRrcConnectionSetup(0x1bdad40, " RNTI ", 2)

LteUeRrc:ApplyRadioResourceConfigDedicated(0x1bdad40)

0x1bdad40 IMSI 5 adding/modifying DRBID 1 LC 3

New Data Radio Bearer

LteUeRrc:SwitchToState(0x1bdad40, "CONNECTED_NORMALLY")

0x1bdad40 IMSI 5 RNTI 2 UeRrc IDLE_CONNECTING --> CONNECTED_NORMALLY

LteUeRrc:DoRecvRrcConnectionReconfiguration(0x1bcf180, " RNTI ", 3)

haveMobilityControlInfo == false

LteUeRrc:ApplyRadioResourceConfigDedicated(0x1bcf180)

request to modify SRB1 (skipping as currently not implemented)

0x1bcf180 IMSI 1 adding/modifying DRBID 1 LC 3

request to modify existing DRBID

LteUeRrc:ApplyMeasConfig(0x1bcf180)

measObjectId 1 is new, adding entry

reportConfigId 1 is new, adding entry

Also about the log from lte-rlc.cc I shared previously. The DoDispose only happens for the rlc of the UE that does not connect. When I tried with 2,3,4 #UEs I did not see the DoDispose at the beginning of the simulation. So it seems that the Rlc of the Problem UE is being disposed off soon after it is created.

To unsubscribe from this group and all its topics, send an email to ns-3-users+unsubscribe@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.

--

Regards

Akhila

Akhila Rao

unread,

Aug 24, 2017, 1:24:32 PM8/24/17

to ns-3-users

Hi Biljana,

I just noticed something. I am attaching the full log file. I see that CONNECTED_NORMALLY does appear for IMSI=4, except it happens a little bit late. Maybe it's lateness is the problem ?

Thanks for all the help

log_rrc.txt

Akhila Rao

unread,

Aug 24, 2017, 2:10:11 PM8/24/17

to ns-3-users

Hi,

I think I fixed it !! This is what I did. A few months ago I had a problem with connecting this trace source.

Config::Connect ("/NodeList/*/DeviceList/*/LteUeRrc/DataRadioBearerMap/*/LteRlc/RxPDU",

MakeBoundCallback (&Lte_RlcDlRxPDU, rlcRxstream));

I remember that You and another person named Rediet helped me solve this problem. The problem was posted under title "Cannot successfully connect LteRlc RxPDU trace source in LTE, even though I have verified the context correctly"

The solution that finally worked was putting a time delay to the RLC trace source connection till the RRC connection was established (It was suggested to me based on Rediet's test simulation that this was 23 ms)

So I did this.

Simulator::Schedule (MilliSeconds(25), &ConnectDataRadioBearerTraceSourceUe, dlRlcRxStream, dlPdcpRxStream);

But I suppose the time it takes for the RRC connections to be established depends on the number of UEs in the simulation. When I increased this to 100 ms. The missing UE appeared in my dlRlcRx logs !! I am attaching the rlc debug log and the dlRlRx file here after the fix.

I wonder, if I use something like 20-30 UEs will it take a really long time to connect ? I will update this thread once I find out.