3GPP mobility reference · 4G · 5G · NTN · IoT

Optimisation

Mobility robustness optimisation (MRO)

How NG-RAN detects too-late, too-early and wrong-cell handovers from RLF reports and successful handover reports.

5G

Overview

MRO detects and enables correction of connection failures due to intra-system or inter-system mobility, inter-system unnecessary handover, inter-system handover ping-pong, PSCell change failure, inter-system voice fallback failure, and fast MCG recovery problems. It helps tell these problems apart from coverage problems and other failures unrelated to mobility (TS 38.300 15.5.2.1).

For connection failures the UE makes an RLF report available to the network. The UE stores the latest RLF report until the network fetches it or for 48 hours after the failure is detected, and only provides it if the current RPLMN is one the report allows (TS 38.300 15.5.2.2.1).

Intra-system problems are defined as follows. Too Late Handover: RLF after the UE stayed a long time in the cell, then re-establishment in a different cell. Too Early Handover: RLF shortly after a successful handover, or a handover failure, then re-establishment in the source cell. Handover to Wrong Cell: the same trigger, but re-establishment in a cell that is neither source nor target. For CHO and LTM the same definitions apply to CHO execution and LTM cell switch.

Call flow

  1. 1
    UE

    Connection failure at node A

    The UE stores an RLF report.

  2. 2
    UEtoNode B

    RRC re-establishment or re-connect

    The failure cell ID and C-RNTI let node B identify the UE context.

  3. 3
    Node BtoNode A

    FAILURE INDICATION (Xn)

    Or the Uplink / Downlink RAN configuration transfer procedures over NG when the RLF report is fetched.

  4. 4
    Node A

    Classify the failure

    Using the UE reported timer against a threshold such as Tstore_UE_cntxt.

  5. 5
    Node AtoNode that configured the mobility

    HANDOVER REPORT (Xn)

    For Too Early Handover or Handover to Wrong Cell. May include the RLF report.

Timers and parameters

NameWhereRole
UE reported timerUE reportTime elapsed since the last handover initialisation until connection failure, or since CHO/LTM execution until failure.
Tstore_UE_cntxtNetworkExample threshold against which the UE reported timer is compared.
RLF report storageUEKept until fetched or for 48 hours after the failure.
SHR storageUESuccessful Handover Report kept until fetched or for 48 hours after it is recorded.

Full parameter and timer lookup →

Specifications

SpecWhat it covers
TS 38.300MRO. Connection failure due to intra-system mobility is 15.5.2.2.2, Successful HO is 15.5.2.7.(see clause 15.5.2)
TS 38.331RLF report content determination. The report is requested with rlf-ReportReq and includes timeConnFailure and connectionFailureType.(see clause 5.3.10.5)
TS 38.423XnAP Failure Indication. Handover Report is 8.4.8 and Access And Mobility Indication is 8.4.12.(see clause 8.4.7)

Failure behaviour in the specs

  • Detection rule for Too Late Handover: no recent handover before the failure (UE reported timer absent or larger than the threshold), or CHO/LTM configured but never executed.
  • Detection rule for Too Early Handover: a recent handover or LTM cell switch, and the first re-establishment cell is the cell that served the UE at the last handover initialisation.
  • Detection rule for Handover to Wrong Cell: a recent handover or LTM cell switch, and the first re-establishment cell is neither the last handover's source cell nor the cell where the RLF happened.
  • If RRC re-establishment fails and RRC connection setup succeeds, MRO evaluation may be triggered twice for one failure. Only one failure event should be counted.
  • Successful Handover Report (SHR): the UE may collect it when configured by the network, and it can reveal sub-optimal successful handovers. It is forwarded to the source node with the ACCESS AND MOBILITY INDICATION message, and the same mobility event may also produce an RLF report (TS 38.300 15.5.2.7).

Symptom-based troubleshooting →