Lte RACH procedure: Message 3

[Michele Polese]

Hi everybody.

In the documentation of LTE module in ns-3 it is written that 

• Message 3: in real LTE systems, this is an RLC TM SDU sent over resources specified in the UL Grant in the RAR. In the simulator, this is modeled as a real RLC TM RLC PDU whose UL resources are allocated by the scheduler upon call to SCHED_DL_RACH_INFO_REQ.

However in the following code (which is part of RecvRaResponse in LteUeMac class)

  const uint8_t lc0Lcid = 0;

  std::map <uint8_t, LcInfo>::iterator lc0InfoIt = m_lcInfoMap.find (lc0Lcid);

  NS_ASSERT (lc0InfoIt != m_lcInfoMap.end ());

  std::map <uint8_t, LteMacSapProvider::ReportBufferStatusParameters>::iterator lc0BsrIt

    = m_ulBsrReceived.find (lc0Lcid);

  if ((lc0BsrIt != m_ulBsrReceived.end ())

      && (lc0BsrIt->second.txQueueSize > 0))

    {

      NS_ASSERT_MSG (raResponse.m_grant.m_tbSize > lc0BsrIt->second.txQueueSize, 

                     "segmentation of Message 3 is not allowed");

      lc0InfoIt->second.macSapUser->NotifyTxOpportunity (raResponse.m_grant.m_tbSize, 0, 0); 

      lc0BsrIt->second.txQueueSize = 0;

    }

the condition lc0BsrIt != m_ulBsrReceived.end () is always false (at least in my observations) and the NotifyTxOpportunity is therefore never called. Thus the DoNotifyTxOpportunity of LteRlcTm is never called after the reception of RAR.

Is it a problem of my scenario (which is lena-simple with 5 UEs and 1 eNB) or is it a bug? Can someone explain me how m_ulBsrReceived is filled?

Thank you very much

[Tommaso Pecorella]

Hi,

bugs are always possible. Please get in touch with the LTE maintainers for further analysis.

Cheers,

T.

[Michele Polese]

Thank you for your reply. I know that a bug should be filed on bugzilla, but first I would like to check that this is not me not understanding how the system should behave. I'll wait for the lte maintainers reply.
Thank you very much,
Michele

[Michele Polese]

Does anybody have an answer?

[Michele Polese]

I guess that the cause of this behavior is the fact that as a default RRC protocol messages are ideal messages. Therefore when in LteUeMac the NotifyRandomAccessSuccessful() method is called, it actually sends the message 3 as an ideal RRC connection request message and does not use any RLC TM SDU. 

Use this

  Config::SetDefault ("ns3::LteHelper::UseIdealRrc", BooleanValue(false));

in your script and NotifyTxOpportunity() in LteUeMac::RecvRaResponse(..) is called. 

Thank you for your attention

Michele

Il giorno lunedì 10 agosto 2015 18:34:32 UTC+2, Michele Polese ha scritto:

Does anybody have an answer?