Issue using real RRC messages

[pe.f...@gmail.com]

Hi everyone,

I am simulating one LTE cell with EPC and IPv4 networking and two remote servers. I am particularly interested in the radio interface delay.
I would like to see the impact using real rrc signaling with the following attribute:

lteHelper->SetAttribute("UseIdealRrc", BooleanValue(false));

Adding this line code make the simulation fail with the following error:

msg="Removing unexpected header ", file=../../src/network/model/packet-metadata.cc, line=703                                                                                    
terminate called without an active exception                                             
Command ['/home/pefiole/repos/ns-3-allinone/ns-3-dev/build/debug/scratch/NANSim/NANSim', '--nRtus=3
'] terminated with signal SIGIOT. Run it under a debugger to get more information (./waf --run <program>
--command-template="gdb --args %s <args>").

I looked into the packet metedata class and it seems the problem happens in this function:

void PacketMetadata::RemoveHeader (const Header &header, uint32_t size)
{
  uint32_t uid = header.GetInstanceTypeId ().GetUid () << 1;
  NS_LOG_FUNCTION (this << &header << size);
  NS_ASSERT (IsStateOk ());
  if (!m_enable)
    {
      m_metadataSkipped = true;
      return;
    }
  struct PacketMetadata::SmallItem item;
  struct PacketMetadata::ExtraItem extraItem;
  uint32_t read = ReadItems (m_head, &item, &extraItem);
  if ((item.typeUid & 0xfffffffe) != uid ||
      item.size != size)
    {
      if (m_enableChecking)
        {
          NS_FATAL_ERROR ("Removing unexpected header ");
        }
      return;
    }

The TypeId of the concerned header is ns3::RrcAsn1Header.
And the error is triggered because the size of the "item"(value: 28) after using the "ReadItems" function is not the same as the parameter "size"(value: 29) give to the function "RemoveHeader"

I have no idea why I get this problem, could someone advise me where to look to solve this ?

My thanks in advance,

PE

[Manuel Requena]

Hi,

Could you give more details about your simulation environment? ns-3 version? Which simulation program you are running? Did you make any modification to the lte module? Did you modify the RRC packet? How can we reproduce the problem?

Manuel

--
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 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 https://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

[pe.f...@gmail.com]

Hi Manuel,

here is my script attached (I commented some parts related to the callback functions I created but I still have the same error).
I hope this will help you reproduce the problem.

I did not do any modification on the RRC packets, I only added some LOG components in some lte classes to help me understand how it was working but that's it.
I downloaded ns-3 in Sep 2015 and it was the ns-3-dev version (it was before the ns-3.24). I am still using this one. Do you think I should update to ns-3.24.1 ?
If you need more details, feel free to ask.

Best regards,

PE

[pe.f...@gmail.com]

Hi everyone,

did you manage to reproduce it with the script I sent you ?
would you advise me to update to the latest ns-3 version ?

On my side I tried to deactivate the Packet Metadata (just comment lines 403-404) and here is the result:
As I don't try to print the packets and its headers anymore, I don't have the previous issue. However, the simulation is still not running and I have the following error:

assert failed. cond="it != m_teidRbidMap.end ()", file=../../src/lte/mode
l/epc-enb-application.cc, line=281                                                                

terminate called without an active exception

It seems to come from the bearer configuration as the EpcEnbApplication cannot recover the teid (Tuneling Endpoint ID) but I cannot manage to find an error in my script.
Do you have an idea of what I got wrong ?

Thanks in advance,

PE

[pe.f...@gmail.com]

One other update to see if it helps solving the problem.
Maybe it is more like a question on LENA and perhaps I should open a new topic (please tell me if so).

The question is about the fragmentation done on the RLC layer of LTE stack, let me start with an example to be clear:
In my simulation I use the trace source ns3::LteSpectrumPhy::TxStart and call the method packet->print( ) to obtain the following result:

ns3::LteRlcHeader (Len=4 FI=3 E=1 SN=153 E=0 LI=17 ) Payload Fragment [995:1012] ns3::LtePdcpHeader (D/C=1 SN=21) ns3::Ipv4Header (tos 0x0 DSCP Default ECN Not-ECT ttl 64 id 12 protocol 17 offset (bytes) 0 flags [none] length: 540 7.0.0.103 > 7.0.0.102) ns3::UdpHeader (length: 520 ,49153 > 3101) ns3::SeqTsHeader ((seq=12 time=26.237)) Payload Fragment [0:82]

We can see here that there are two different parts : the Last fragment of one message "Payload Fragment [995:1012]" and then the first fragment of the next message "Payload Fragment [0:82]" with the list of standard headers for LTE packets using Ipv4 and UDP.
My question is now, how such packet is handeled by the simulator? The attribute ns3::Packet::Uid is the same as the Packet created by the application corresponding to the first payload fragment. But does it still know of the other fragment?

Could it be the source of the Tunneling Endpoint (TEID) Problem I signaled in my earlier message? I mean, if the two fragment are allocated different QoS it could be the case. Please tell me what you think about this.

Any Help to better understand this fragmentation mechanism would be most welcome !

PE

[Biljana Bojović]

Hi Pierre,

I tried your script and the problem disappears if PacketMetadata is disabled. So, the issue seems to be related to the bug https://www.nsnam.org/bugzilla/show_bug.cgi?id=2308.  At the same link you may find the patch with solution proposed by Natale Patriciello. This patch is currently under evaluation for inclusion in ns-3 release version.

Best regards,
Biljana