about fixing RLF failure handling and handover with errors

[Bob]

I looked into "lte-ue-rrc.cc". When receiving RRC connection reestaglishment, upon handover or RLF failure, would the below modification fix RLF/handover limitations? The only modification I made is to leave connected mode and switch back to IDLE_CAMPED_NORMALLY. This way the UE should remain connected to the current eNB, which is what the eNB is expecting.

An additional question I have is about DoRecvRrcConnectionRelease() function below, empty right now. I included some lines of code below for comments (changes are in red).   

/* code  */

void 

LteUeRrc::DoRecvRrcConnectionReestablishment (LteRrcSap::RrcConnectionReestablishment msg)

{

  NS_LOG_FUNCTION (this << " RNTI " << m_rnti);

  switch (m_state)

    {

    case CONNECTED_REESTABLISHING:

      {

        /**

         * \todo After receiving RRC Connection Re-establishment, stop timer

         *       T301, fire a new trace source, reply with RRC Connection

         *       Re-establishment Complete, and finally switch to

         *       CONNECTED_NORMALLY state. See Section 5.3.7.5 of 3GPP TS

         *       36.331.

         */

         LeaveConnectedMode (); // will switch to IDLE_CAMPED_NORMALLY.  

      }

      break;

    default:

      NS_FATAL_ERROR ("method unexpected in state " << ToString (m_state));

      break;

    }

}

void 

LteUeRrc::DoRecvRrcConnectionReestablishmentReject (LteRrcSap::RrcConnectionReestablishmentReject msg)

{

  NS_LOG_FUNCTION (this << " RNTI " << m_rnti);

  switch (m_state)

    {

    case CONNECTED_REESTABLISHING:

      {

        /**

         * \todo After receiving RRC Connection Re-establishment Reject, stop

         *       timer T301. See Section 5.3.7.8 of 3GPP TS 36.331.

         */

        LeaveConnectedMode ();

      }

      break;

    default:

      NS_FATAL_ERROR ("method unexpected in state " << ToString (m_state));

      break;

    }

}

void 

LteUeRrc::DoRecvRrcConnectionRelease (LteRrcSap::RrcConnectionRelease msg)

{

  NS_LOG_FUNCTION (this << " RNTI " << m_rnti);

  /// \todo Currently not implemented, see Section 5.3.8 of 3GPP TS 36.331.

  NS_LOG_FUNCTION (this << m_imsi);

  m_asSapUser->NotifyConnectionReleased ();

  m_cmacSapProvider->RemoveLc (1);

  std::map<uint8_t, Ptr<LteDataRadioBearerInfo> >::iterator it;

  for (it = m_drbMap.begin (); it != m_drbMap.end (); ++it)

    {

      m_cmacSapProvider->RemoveLc (it->second->m_logicalChannelIdentity);

    }

  m_drbMap.clear ();

  m_bid2DrbidMap.clear ();

  m_srb1 = 0;

  SwitchToState (IDLE_CELL_SEARCH);

}

void 

LteUeRrc::LeaveConnectedMode ()

{

  NS_LOG_FUNCTION (this << m_imsi);

  m_asSapUser->NotifyConnectionReleased ();

  m_cmacSapProvider->RemoveLc (1);

  std::map<uint8_t, Ptr<LteDataRadioBearerInfo> >::iterator it;

  for (it = m_drbMap.begin (); it != m_drbMap.end (); ++it)

    {

      m_cmacSapProvider->RemoveLc (it->second->m_logicalChannelIdentity);

    }

  m_drbMap.clear ();

  m_bid2DrbidMap.clear ();

  m_srb1 = 0;

  SwitchToState (IDLE_CAMPED_NORMALLY);

}

[Nicola Baldo]

Thanks for looking into this, it would be really great if you could come with a patch fixing RLF, many people need it!

I don't think that your proposed implementation would fix RLF.
The proper way of handling RLF is explained in TS 36.331 section 5.3.11 "Radio link failure related actions"
The involved PHY layer indications are defined in TS 36.133 section 7.6 "Radio Link Monitoring"
a nice presentation that explains everything can be found here
https://www.academia.edu/4506089/102203228_10_a_Drop_Call_Analysis_v1_7

In my opinion, the modifications required to LENA are:

1. Add two methods to LteUeCphySapUser: NotifyInSync and NotifyOutOfSync
2. Add two attributes to LteUePhy: Qin and Qout and set the default values as per TS 36.133 section 7.6
3. Add some code within LteUePhy::GenerateCtrlCqiReport that compares the SINR with Qin and Qout and fires NotifyInSync and NotifyOutOfSync as specified in TS 36.133 section 7.6
4. Implement LteUeRrc::DoNotifyInSync() and teUeRrc::DoNotifyOutOfSync() as per TS 36.331 section 5.3.11.1 and 5.3.11.2. To implement T310, have a look at how T300 is currently implemented in LteUeRrc, i.e., the member variables m_t300 and m_connectionTimeout, and do something similar, i.e., declare new variables "Time m_t310;" and "EventId m_radioLinkFailureDetected;", and associated the latter with a new method LteUeRrc::RadioLinkFailureDetected ()
5. Implement the new method LteUeRrc::RadioLinkFailureDetected () as per TS 36.331 section 5.3.11.3. As a simplification, you might skip connection reestablishment and call LeaveConnectedMode () immediately.
   
   

If you would like to work on this, I'd be glad to review and provide feedback to your development, in the perspective of merging this feature in ns-3-dev.

[Roberto]

Thanks Nicola for helping. I will take a look into the slides and the code as I'm not an expert about LENA module.

Thanks,

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

[Mitsuo SAKAMOTO]

Hello Nicola,

I have a question about your third proposal.
According to TS36.133 section 7.6, the downlink quality for Qout is estimated over the last 200ms. it seems that the downlink quality (=SINR) for Qout is averaged with 200ms. For Qin case, the averaging time seems to be 100ms. Is this correct? In other words, is Layer 1 filtering for the SINR necessary?
if yes, new timers instead of m_rsrpSinrSamplePeriod should be defined in LteUePhy::GenerateCtrlCqiReport and it should be scheduled like LteUePhy::ReportUeMeasurements?

I would like to understand the appropriate process to calculate SINR which is compared with Qin and Qout. Can you advice it?
After that, I would like to think how to apply the layer-3 filtering.

thanks,

Mitsuo

[Mitsuo SAKAMOTO]

Sorry, it was my wrong understanding. I should take into account N310 and N311.
http://telecomcoach.com/rrc-connection-supervision-lte/

Mitsuo

2015年2月2日月曜日 16時55分39秒 UTC+9 Mitsuo SAKAMOTO: