SON stands for Self Organizing Network. The idea is that the network configures and tunes many of its own parameters, instead of an engineer doing it cell by cell. Some SON functions run only between network nodes, like the automatic neighbour relation or the PCI selection. But the most interesting part in NR is where the UE helps. The UE records what happened during a random access, a radio link failure or even a successful handover, and reports it later. The gNB uses this to tune its mobility and RACH parameters.
This page goes through those UE assisted SON functions from Release 16 to Release 18: the RACH report, the RLF report, MRO (Mobility Robustness Optimization), SHR (Successful Handover Report) and SPR (Successful PSCell change / addition Report). All of these reports are retrieved with the same UE Information procedure that Logged MDT uses. That procedure and the MDT side of the story are described in the MDT for NR page.
- What is SON ?
- UE Reports for SON
- RACH Report
- RLF Report
- MRO - Mobility Robustness Optimization
- SHR - Successful Handover Report
- SPR - Successful PSCell Change or Addition Report
- Release Evolution
- Reference
What is SON ?
Why we need SON ? A modern network has a huge number of cells, and every cell has many parameters: neighbour lists, PCI, handover offsets, time to trigger, PRACH configuration and so on. Each of them may need to change when traffic, interference or the neighbouring cells change. Doing this by hand does not scale. SON tries to let the network detect the problem and correct the parameter by itself, within the limits that OAM allows.
TS 38.300 clause 15 splits SON into two groups. Self-configuration is about bringing up a new node: setting up NG-C and Xn, discovering Xn addresses, and building the neighbour relations (ANR). Self-optimisation is about tuning a running network. It includes MLB (Mobility Load Balancing), MRO, RACH optimization, CCO (Coverage and Capacity Optimisation) and PCI optimisation. Energy saving is listed as well.
Then where does the UE come in ? Most of these functions only need information that the gNBs already have or can exchange over Xn. MRO and RACH optimization are different. A gNB cannot see what went wrong inside the UE. For example, a gNB only sees that a UE disappeared. It does not know whether the UE had a radio link failure, which beam it was on, or which cell it went to after that. Only the UE knows. So these functions depend on reports from the UE, and that is the focus of this page.
Self-configuration : NG-C and Xn setup, Xn TNL address discovery, ANR. ANR uses the normal measurement report and CGI reporting, not a new SON report.Self-optimisation : MLB, MRO, RACH optimization, CCO, PCI optimisation. MRO and RACH optimization are the ones that depend on UE reports.All changes stay inside the OAM limits : for MRO, OAM sets the maximum deviation of the handover trigger and the minimum time between two changes.
There is one exception in the self-configuration group, and it is a good example of how a UE can help without any special SON report. ANR builds the Neighbour Cell Relation Table of a cell. A UE in RRC_CONNECTED sends a normal measurement report about a cell that the gNB does not know. The report has only the PCI. So the gNB asks the UE to read the system information of that cell and report its NCGI, TAC, PLMN IDs and gNB ID length (reportCGI). With the global ID, the gNB can add the neighbour relation, look up the transport address and set up Xn if needed. The UE only reads and reports what the cell broadcasts. The decision to add the relation is in the gNB.
The reports in this page are different from that. ANR uses the normal measurement report in RRC_CONNECTED. The SON reports below describe events that happened in the past, often while the UE could not send anything, and they need their own storage and retrieval in the UE.
UE Reports for SON
Before going into each report, it is useful to see what they have in common. Every one of them is created by the UE at the moment something happens, kept in a UE variable, and reported only when a gNB asks for it. This is a little strange at first. Why doesn't the UE just send the report immediately ? The reason is that most of these events happen when the UE cannot send anything. After an RLF, there is no connection. After a failed RACH, there is no uplink. So the UE has to keep the information until it gets a connection again, often in a different cell.
The table below summarizes the reports. The availability flag is the bit the UE puts in UE-MeasurementsAvailable-r16, and the request flag is the bit the gNB sets in UEInformationRequest. Both are listed in detail in How network retrieves the log ? on the MDT page.
Report |
Created when |
Availability flag |
Request flag |
Rel |
RA report |
RA procedure completes, on-demand SI acquisition ends, RA-SDT ends |
none |
ra-ReportReq |
16 |
RLF report |
RLF or handover failure |
rlf-InfoAvailable |
rlf-ReportReq |
16 |
CEF report |
RRC setup or resume fails (T300 / T319 expiry) |
connEstFailInfoAvailable |
connEstFailReportReq |
16 |
SHR |
Handover succeeds, but a configured timer threshold is exceeded |
successHO-InfoAvailable |
successHO-ReportReq |
17 |
SPR |
PSCell change or addition succeeds, but a configured timer threshold is exceeded |
successPSCell-InfoAvailable |
successPSCell-ReportReq |
18 |
There is one more common point, and it is the important one for SON. The gNB that gets the report is often not the gNB that needs it. The UE fails in a cell of gNB A and comes back in a cell of gNB B. gNB B gets the RLF report, but the parameter that caused the failure belongs to gNB A, or to the gNB that handed the UE over to gNB A. So the report has to be forwarded over Xn. Figure 1 shows this flow for the RLF report.
Figure 1. Retrieval and forwarding of an RLF report. The UE gives the report to whichever gNB it reconnects to, so the report travels over Xn to the gNB whose parameters caused the failure.
Steps 2 to 5 are the same for every report : the availability flag goes in the Complete message, and the report comes in UEInformationResponse. Only the flag names change.FAILURE INDICATION goes to the last serving node : gNB B sends it to gNB A, the node that controls the cell where the failure happened. If gNB B does not know which node that is, it can send it to every node that uses the PCI that the UE reported. Over NG, the Uplink / Downlink RAN Configuration Transfer procedures do the same job.gNB A finds the UE context with the C-RNTI : the RLF report carries the C-RNTI of the failed cell, and gNB A uses it together with the failed cell ID to find its own record of the UE.HANDOVER REPORT goes to the node that made the mistake : when gNB A decides that the handover was too early or went to the wrong cell, the mistake is in the cell that started the handover. So gNB A informs gNB C. It includes the C-RNTI used in the source cell, and the RLF report itself can be included.SHR and SPR use another message : they are forwarded with ACCESS AND MOBILITY INDICATION over Xn, because they are not failures.
RACH Report
RACH looks simple when it works. UE sends a preamble, gets a RAR and moves on. But how many preambles did it actually send before it succeeded ? On which SSB ? Did it collide with another UE ? The gNB sees only the preamble that it detected. It does not see the preambles that it missed, and it does not know which SSB the UE wanted to use. The RACH report (RA report, RA-Report-r16) is the UE's record of these details.
One thing that confuses people is when the RA report is created. It is created after a successful random access. Then where does a failed random access go ? It goes into another report. If the RA fails in RRC_CONNECTED, it becomes an RLF with cause randomAccessProblem, and the RA details go into the RLF report. If it fails during RRC setup or resume, the details go into the CEF report. The exceptions are on-demand SI acquisition and RA-SDT, which create an RA report whether they succeed or fail.
The UE keeps up to 8 entries (maxRAReport-r16) in VarRA-Report. It may discard them 48 hours after the last stored procedure. Unlike the RLF report, there is no availability flag for the RA report, so the gNB has to send ra-ReportReq without knowing whether the UE has anything.
Following is based on
RA-ReportList-r16 ::= SEQUENCE (SIZE (1..maxRAReport-r16)) OF RA-Report-r16 RA-Report-r16 ::= SEQUENCE { cellId-r16 CHOICE { cellGlobalId-r16 CGI-Info-Logging-r16, pci-arfcn-r16 PCI-ARFCN-NR-r16 }, ra-InformationCommon-r16 RA-InformationCommon-r16 OPTIONAL, raPurpose-r16 ENUMERATED {accessRelated, beamFailureRecovery, reconfigurationWithSync, ulUnSynchronized, schedulingRequestFailure, noPUCCHResourceAvailable, requestForOtherSI, msg3RequestForOtherSI-r17, lbt-Failure-r18, ltm-r19, spare6, spare5, spare4, spare3, spare2, spare1}, ..., [[ spCellID-r17 CGI-Info-Logging-r16 OPTIONAL ]], [[ sdt-Failed-r18 ENUMERATED {true} OPTIONAL ]], [[ sdt-FailureCause-r19 ENUMERATED {t319a-expiry, maxRetxThreshold, preambleTransMax, configuredGrantTimer, cg-SDT-TimeAlignmentTimer, cellReselection, spare2, spare1} OPTIONAL, sdt-DL-Rsrp-Info-r19 RSRP-Range OPTIONAL, sdt-UL-DataVolume-r19 INTEGER (0..96000) OPTIONAL, timeSinceSdt-Execution-r19 TimeSinceSdt-Execution-r19 OPTIONAL ]] } PerRAInfoList-r16 ::= SEQUENCE (SIZE (1..200)) OF PerRAInfo-r16 PerRAInfo-r16 ::= CHOICE { perRASSBInfoList-r16 PerRASSBInfo-r16, perRACSI-RSInfoList-r16 PerRACSI-RSInfo-r16 } PerRASSBInfo-r16 ::= SEQUENCE { ssb-Index-r16 SSB-Index, numberOfPreamblesSentOnSSB-r16 INTEGER (1..200), perRAAttemptInfoList-r16 PerRAAttemptInfoList-r16 } PerRACSI-RSInfo-r16 ::= SEQUENCE { csi-RS-Index-r16 CSI-RS-Index, numberOfPreamblesSentOnCSI-RS-r16 INTEGER (1..200) } PerRAAttemptInfoList-r16 ::= SEQUENCE (SIZE (1..200)) OF PerRAAttemptInfo-r16 PerRAAttemptInfo-r16 ::= SEQUENCE { contentionDetected-r16 BOOLEAN OPTIONAL, dlRSRPAboveThreshold-r16 BOOLEAN OPTIONAL, ..., [[ fallbackToFourStepRA-r17 ENUMERATED {true} OPTIONAL ]] }
cellId : the cell where the preamble was sent, as a global cell ID with TAC if available, otherwise PCI and ARFCN.spCellID-r17 : when the RA was on an SCell, this tells the PCell or PSCell that the SCell belonged to. Without it, the gNB that receives the report may not know which node the SCell belongs to.raPurpose : why the RA was triggered. The values follow the RA triggers of TS 38.321, plus on-demand SI. Release 17 adds Msg3 based SI request, Release 18 adds LBT failure recovery, and Release 19 adds LTM.perRAInfoList : the core of the report. It is a chronological list per beam. Each entry gives the SSB (or CSI-RS) index and how many preambles were sent on it in a row before the UE moved to another beam or finished.contentionDetected : per attempt on contention based resources. It is true when contention resolution failed for that preamble. In other words, another UE won.dlRSRPAboveThreshold : per attempt. It tells whether the RSRP of the selected SSB was above rsrp-ThresholdSSB (or msgA-RSRP-ThresholdSSB for 2-step). If it is false, the UE had no SSB above the threshold and picked one anyway.fallbackToFourStepRA-r17 : in 2-step RA, the attempt fell back to 4-step.sdt-Failed-r18 : the RA was for SDT and the SDT failed. Release 19 adds the cause and the RSRP / data volume at the time of the SDT decision.
RA-InformationCommon
RA-InformationCommon-r16 is the part that the RA report shares with the RLF report and the CEF report. It tells where the RACH resources were in frequency, and then it carries the per-attempt list. Why does the UE report the frequency location ? Because the report may be read by a gNB that does not know which BWP and which PRACH configuration the UE used. The listing grew a lot over the releases, so pay attention mainly to the first block and to the 2-step block.
Following is based on
RA-InformationCommon-r16 ::= SEQUENCE {
absoluteFrequencyPointA-r16 ARFCN-ValueNR,
locationAndBandwidth-r16 INTEGER (0..37949),
subcarrierSpacing-r16 SubcarrierSpacing,
msg1-FrequencyStart-r16 INTEGER (0..maxNrofPhysicalResourceBlocks-1) OPTIONAL,
msg1-FrequencyStartCFRA-r16 INTEGER (0..maxNrofPhysicalResourceBlocks-1) OPTIONAL,
msg1-SubcarrierSpacing-r16 SubcarrierSpacing OPTIONAL,
msg1-SubcarrierSpacingCFRA-r16 SubcarrierSpacing OPTIONAL,
msg1-FDM-r16 ENUMERATED {one, two, four, eight} OPTIONAL,
msg1-FDMCFRA-r16 ENUMERATED {one, two, four, eight} OPTIONAL,
perRAInfoList-r16 PerRAInfoList-r16,
...,
[[
perRAInfoList-v1660 PerRAInfoList-v1660 OPTIONAL
]],
[[
msg1-SCS-From-prach-ConfigurationIndex-r16 ENUMERATED {kHz1dot25, kHz5, spare2, spare1} OPTIONAL
]],
[[
msg1-SCS-From-prach-ConfigurationIndexCFRA-r16 ENUMERATED {kHz1dot25, kHz5, spare2, spare1} OPTIONAL
]],
[[
msgA-RO-FrequencyStart-r17 INTEGER (0..maxNrofPhysicalResourceBlocks-1) OPTIONAL,
msgA-RO-FrequencyStartCFRA-r17 INTEGER (0..maxNrofPhysicalResourceBlocks-1) OPTIONAL,
msgA-SubcarrierSpacing-r17 SubcarrierSpacing OPTIONAL,
msgA-RO-FDM-r17 ENUMERATED {one, two, four, eight} OPTIONAL,
msgA-RO-FDMCFRA-r17 ENUMERATED {one, two, four, eight} OPTIONAL,
msgA-SCS-From-prach-ConfigurationIndex-r17 ENUMERATED {kHz1dot25, kHz5, spare2, spare1} OPTIONAL,
msgA-TransMax-r17 ENUMERATED {n1, n2, n4, n6, n8, n10, n20, n50, n100, n200} OPTIONAL,
msgA-MCS-r17 INTEGER (0..15) OPTIONAL,
nrofPRBs-PerMsgA-PO-r17 INTEGER (1..32) OPTIONAL,
msgA-PUSCH-TimeDomainAllocation-r17 INTEGER (1..maxNrofUL-Allocations) OPTIONAL,
frequencyStartMsgA-PUSCH-r17 INTEGER (0..maxNrofPhysicalResourceBlocks-1) OPTIONAL,
nrofMsgA-PO-FDM-r17 ENUMERATED {one, two, four, eight} OPTIONAL,
dlPathlossRSRP-r17 RSRP-Range OPTIONAL,
intendedSIBs-r17 SEQUENCE (SIZE (1..maxSIB)) OF SIB-Type-r17 OPTIONAL,
ssbsForSI-Acquisition-r17 SEQUENCE (SIZE (1..maxNrofSSBs-r16)) OF SSB-Index OPTIONAL,
msgA-PUSCH-PayloadSize-r17 BIT STRING (SIZE (5)) OPTIONAL,
onDemandSISuccess-r17 ENUMERATED {true} OPTIONAL
]],
[[
usedFeatureCombination-r18 ReportedFeatureCombination-r18 OPTIONAL,
triggeredFeatureCombination-r18 ReportedFeatureCombination-r18 OPTIONAL,
startPreambleForThisPartition-r18 INTEGER (0..63) OPTIONAL,
numberOfPreamblesPerSSB-ForThisPartition-r18 INTEGER (1..64) OPTIONAL,
attemptedBWP-InfoList-r18 SEQUENCE (SIZE (1..maxNrofBWPs)) OF AttemptedBWP-Info-r18 OPTIONAL,
numberOfLBT-Failures-r18 INTEGER (1..128) OPTIONAL,
perRAInfoList-v1800 PerRAInfoList-v1800 OPTIONAL,
intendedSIBs-r18 SEQUENCE (SIZE (1..maxSIB)) OF SIB-Type-r18 OPTIONAL
]]
}
absoluteFrequencyPointA / locationAndBandwidth / subcarrierSpacing : the UL BWP that carried the RACH resources.msg1-FrequencyStart / msg1-FDM / msg1-SubcarrierSpacing : where the RACH occasions were. The CFRA versions are for contention free resources, which can be configured separately.msgA-... -r17 : the same information for 2-step RA, plus the MsgA PUSCH resources. msgA-TransMax is the switching point to 4-step, and dlPathlossRSRP is the RSRP that the UE measured when it decided the RA type.msgA-PUSCH-PayloadSize-r17 : how much data the UE had in its buffer when it started 2-step RA. This helps to see whether the MsgA PUSCH size was right.intendedSIBs / ssbsForSI-Acquisition / onDemandSISuccess -r17 : for an on-demand SI request, which SIBs the UE wanted, on which SSBs it got them, and whether it worked.usedFeatureCombination / triggeredFeatureCombination -r18 : in Release 18, the RACH resources can be partitioned by feature (RedCap, SDT, slicing, Msg3 repetition and so on). The UE tells which features triggered the RA and which partition it actually used, if they differ.attemptedBWP-InfoList / numberOfLBT-Failures -r18 : for NR-U. How many preamble attempts were blocked by LBT, and on which BWPs consistent LBT failure was triggered.
How gNB uses the RA report
The report gives the raw material, but the gNB has to turn it into a parameter change. TS 38.300 does not specify the algorithm. It only says that RACH optimization uses the UE reported information and the PRACH parameters exchanged between NG-RAN nodes. So what follows is my understanding of the typical use, not a specified behavior.
Many contentionDetected = true : too many UEs pick the same preamble on the same RACH occasion. The gNB may give more preambles to contention based access, or more RACH occasions per SSB.Many dlRSRPAboveThreshold = false : UEs often do not find any SSB above rsrp-ThresholdSSB. Either the threshold is too high for this coverage, or the beam coverage has a hole.Many preambles on one SSB before success : the preamble power ramping may be too slow, or the initial target power too low, on that beam.PRACH conflicts with neighbours : a neighbour cell using the same root sequence and the same RACH occasions can make preambles detected in the wrong cell. The PRACH configuration of neighbours is exchanged between NG-RAN nodes so that this can be avoided.
RLF Report
The RLF report is the oldest and the most important UE report for SON. When the connection fails, the UE writes down what it knew at that moment: which cell it was on, how good the signal was, what the neighbours looked like, why it failed and how long ago the last handover was. It then keeps this in VarRLF-Report until a gNB asks for it, or for 48 hours.
What counts as a failure here ? There are two types, and connectionFailureType tells which one. rlf is a radio link failure in a cell where the UE was already connected, for example T310 expiry. hof is a handover failure, which means T304 expired before the UE could access the target. The difference is important for MRO, because a failure during the handover points to a different problem than a failure some time after it.
The UE indicates rlf-InfoAvailable when it comes back to RRC_CONNECTED, but only if the current RPLMN is the RPLMN or an EPLMN at the time of failure. The UE keeps only the latest failure. If a new failure happens before the report is fetched, the old one is replaced. The exception is CHO and DAPS, where two consecutive failures can be kept together (Release 17).
Following is based on
RLF-Report-r16 ::= CHOICE { nr-RLF-Report-r16 SEQUENCE { measResultLastServCell-r16 MeasResultRLFNR-r16, measResultNeighCells-r16 SEQUENCE { measResultListNR-r16 MeasResultList2NR-r16 OPTIONAL, measResultListEUTRA-r16 MeasResultList2EUTRA-r16 OPTIONAL } OPTIONAL, c-RNTI-r16 RNTI-Value, previousPCellId-r16 CHOICE { nrPreviousCell-r16 CGI-Info-Logging-r16, eutraPreviousCell-r16 CGI-InfoEUTRALogging } OPTIONAL, failedPCellId-r16 CHOICE { nrFailedPCellId-r16 CHOICE { cellGlobalId-r16 CGI-Info-Logging-r16, pci-arfcn-r16 PCI-ARFCN-NR-r16 }, eutraFailedPCellId-r16 CHOICE { cellGlobalId-r16 CGI-InfoEUTRALogging, pci-arfcn-r16 PCI-ARFCN-EUTRA-r16 } }, reconnectCellId-r16 CHOICE { nrReconnectCellId-r16 CGI-Info-Logging-r16, eutraReconnectCellId-r16 CGI-InfoEUTRALogging } OPTIONAL, timeUntilReconnection-r16 TimeUntilReconnection-r16 OPTIONAL, reestablishmentCellId-r16 CGI-Info-Logging-r16 OPTIONAL, timeConnFailure-r16 INTEGER (0..1023) OPTIONAL, timeSinceFailure-r16 TimeSinceFailure-r16, connectionFailureType-r16 ENUMERATED {rlf, hof}, rlf-Cause-r16 ENUMERATED {t310-Expiry, randomAccessProblem, rlc-MaxNumRetx, beamFailureRecoveryFailure, lbtFailure-r16, bh-rlfRecoveryFailure, t312-expiry-r17, spare1}, locationInfo-r16 LocationInfo-r16 OPTIONAL, noSuitableCellFound-r16 ENUMERATED {true} OPTIONAL, ra-InformationCommon-r16 RA-InformationCommon-r16 OPTIONAL, ..., [[ csi-rsRLMConfigBitmap-v1650 BIT STRING (SIZE (96)) OPTIONAL ]], [[ lastHO-Type-r17 ENUMERATED {cho, daps, ltm-v1900, choWithCandidateSCG-v1900} OPTIONAL, timeConnSourceDAPS-Failure-r17 TimeConnSourceDAPS-Failure-r17 OPTIONAL, timeSinceCHO-Reconfig-r17 TimeSinceCHO-Reconfig-r17 OPTIONAL, choCellId-r17 CHOICE { cellGlobalId-r17 CGI-Info-Logging-r16, pci-arfcn-r17 PCI-ARFCN-NR-r16 } OPTIONAL, choCandidateCellList-r17 ChoCandidateCellList-r17 OPTIONAL ]], [[ pSCellId-r18 CHOICE { cellGlobalId-r18 CGI-Info-Logging-r16, pci-arfcn-r18 PCI-ARFCN-NR-r16 } OPTIONAL, mcg-RecoveryFailureCause-r18 ENUMERATED {t316-Expiry, scg-Deactivated, spare2, spare1} OPTIONAL, scg-FailureCause-r18 ENUMERATED {t310-Expiry, randomAccessProblem, rlc-MaxNumRetx, synchReconfigFailureSCG, scg-ReconfigFailure, srb3-IntegrityFailure, scg-lbtFailure, beamFailureRecoveryFailure, t312-Expiry, bh-RLF, beamFailure, spare5, spare4, spare3, spare2, spare1 } OPTIONAL, elapsedTimeSCG-Failure-r18 ElapsedTimeSCG-Failure-r18 OPTIONAL, voiceFallbackHO-r18 ENUMERATED {true} OPTIONAL, measResultLastServCellRSSI-r18 RSSI-Range-r16 OPTIONAL, measResultNeighFreqListRSSI-r18 MeasResultNeighFreqListRSSI-r18 OPTIONAL, bwp-Info-r18 AttemptedBWP-Info-r18 OPTIONAL, elapsedTimeT316-r18 ElapsedTimeT316-r18 OPTIONAL, scg-FailedAfterMCG-r18 ENUMERATED {true} OPTIONAL ]], [[ measResultL1-LastServCell-r19 MeasResultL1-r19 OPTIONAL, measResultL1-NeighCells-r19 MeasResultList3NR-r19 OPTIONAL, ltm-RecoveryCellId-r19 CHOICE { cellGlobalId-r19 CGI-Info-Logging-r16, pci-arfcn-r19 PCI-ARFCN-NR-r16 } OPTIONAL, measResultLastServPSCell-r19 MeasResultRLFNR-r16 OPTIONAL, cho-WithCandidateSCGInfoList-r19 CHO-WithCandidateSCGInfoList-r19 OPTIONAL, distanceFromReference1-r19 INTEGER(0.. 65535) OPTIONAL ]] }, eutra-RLF-Report-r16 SEQUENCE { failedPCellId-EUTRA CGI-InfoEUTRALogging, measResult-RLF-Report-EUTRA-r16 OCTET STRING, ..., [[ measResult-RLF-Report-EUTRA-v1690 OCTET STRING OPTIONAL ]] } }
There are a lot of fields in this report. For MRO, the most important ones are the cell identities and the timers, because these are what the gNB uses to decide whether a handover was too early or too late. The radio measurements and location are more for the coverage analysis, which is the MDT side described in MDT Information in RLF Report.
failedPCellId : the PCell where the RLF happened, or the target PCell of the failed handover.previousPCellId : the source PCell of the last handover that the UE received before the failure.reestablishmentCellId : the cell where the UE tried re-establishment after the failure.reconnectCellId / timeUntilReconnection : if the re-establishment failed, the cell where the UE later came back to RRC_CONNECTED, and how many seconds that took.c-RNTI : the C-RNTI in the PCell at RLF, or in the source PCell at HOF. This is the key that lets the failed node find its UE context.timeConnFailure : the time from the last handover (or MCG LTM cell switch) execution until the failure, in units of 100 ms, up to 102.3 s. This is the "UE reported timer" of the MRO rules in 38.300.timeSinceFailure : seconds from the failure until the report is sent. The gNB uses it to know how old the information is.rlf-Cause : why the RLF happened. lbtFailure-r16 is for NR-U, bh-rlfRecoveryFailure is for IAB, and t312-expiry-r17 is the fast RLF timer.ra-InformationCommon : included when the cause is randomAccessProblem or beamFailureRecoveryFailure. It has the same format as in the RA report.eutra-RLF-Report-r16 : a UE capable of cross-RAT RLF reporting can give an LTE RLF report to a gNB. The LTE report is carried as an OCTET STRING, and the gNB can forward it to the eNB over NG.
Release 17 additions for CHO and DAPS
CHO and DAPS change the meaning of "the last handover". With CHO, the UE got the handover command long before it executed it. With DAPS, the UE was connected to both the source and the target at the same time. So the old fields alone cannot tell the full story. Release 17 adds the fields below, and it also allows the report to hold two consecutive failures. For the CHO mechanism itself, see the CHO page and the DAPS page.
lastHO-Type-r17 : whether the last handover was CHO or DAPS. The ltm-v1900 and choWithCandidateSCG-v1900 values were added in Release 19.timeSinceCHO-Reconfig-r17 : for HOF, the time between receiving the CHO configuration and starting the execution. For RLF, the time between the RLF and receiving the latest CHO configuration. A long value means the CHO configuration was old when it was used.choCellId-r17 / choCandidateCellList-r17 : the candidate cell the UE selected for CHO recovery, and the list of candidates the UE had.timeConnSourceDAPS-Failure-r17 : for DAPS, the time from the DAPS handover start until the failure at the source.Consecutive failures : for example, the UE fails in the source, picks a CHO candidate for recovery and fails there too. Both failures are stored and reported.
Release 18 additions
Release 18 mainly covers the cases that the earlier RLF report could not describe at all. These are failures that involve the SCG, the fast MCG recovery, the voice fallback to LTE, and the LBT behavior of NR-U. The point is the same in each case. Without these fields, the gNB sees an MCG failure but cannot tell what led to it.
pSCellId-r18 / scg-FailureCause-r18 / elapsedTimeSCG-Failure-r18 / scg-FailedAfterMCG-r18 : the PSCell at the time of failure, and the SCG failure that happened before or after the MCG failure, with the time between them.mcg-RecoveryFailureCause-r18 / elapsedTimeT316-r18 : the UE tried fast MCG recovery through the SCG (T316), and it failed. The cause is T316 expiry or a deactivated SCG.voiceFallbackHO-r18 : the failure happened during a handover triggered by voice fallback (EPS fallback). This is how the "inter-system mobility failure for voice fallback" of MRO is detected.measResultLastServCellRSSI-r18 / measResultNeighFreqListRSSI-r18 / bwp-Info-r18 : RSSI and BWP information for NR-U, so that the gNB can tell an LBT problem from a coverage problem.
MRO - Mobility Robustness Optimization
Now we have the RLF report at the right gNB. What does that gNB actually do with it ? This is MRO. The goal is to find handovers that were triggered at the wrong time or toward the wrong cell, and to correct the handover parameters of the responsible cell. The hard part is that the gNB never sees the handover decision going wrong. It only sees the result, a failure, and it has to work backwards from the cell IDs and the timer in the report.
TS 38.300 defines three intra-system failure types. A Too Late Handover means the UE stayed too long in a cell and failed there, then reconnected in a different cell. A Too Early Handover means the UE failed shortly after a handover, or during it, and reconnected in the source cell. A Handover to Wrong Cell means the UE failed shortly after a handover, or during it, and reconnected in a third cell that was neither the source nor the target. In CHO and LTM, the same names apply to the CHO execution and to the LTM cell switch.
How does the gNB know what "shortly after" means ? It compares the UE reported timer, timeConnFailure, with a threshold configured by OAM, Tstore_UE_cntxt. Figure 2 shows the decision.
Figure 2. MRO classification of an intra-system connection failure. The timer decides whether a handover is to blame at all, and the cell where the UE came back decides which kind of mistake it was.
No recent handover means Too Late : the timer is absent or larger than Tstore_UE_cntxt, and the UE reconnected in a different cell. The cell where the UE failed should have handed it over earlier. With CHO or LTM configured, it also counts as too late when the execution was never started before the failure.Back to the source means Too Early : the target could not hold the UE, and the source was still good enough. The source cell started the handover too early. For DAPS, falling back to the source configuration counts the same way.A third cell means Wrong Cell : the handover was needed, but toward another cell. The source cell has the wrong neighbour priority or offsets.Too Late is handled locally, the others are reported : for Too Early and Wrong Cell, the responsible cell is the source of the last handover. gNB A sends HANDOVER REPORT over Xn to that node, as in Figure 1.One failure, one count : if re-establishment fails and RRC setup then succeeds, MRO evaluation can be triggered twice for the same event. Only one should be counted.
So far this sounds clean, but there is one thing to remember. The "successful handover" in these definitions is from the UE point of view. It means the RA procedure in the target completed. For RACH-less LTM, it means the UE knows the network received its first UL data. A failure 300 ms after the RA completed is a failure after a successful handover, even if the network side has not finished the path switch yet.
Inter-system MRO
The same logic is extended to mobility between 5GS and EPS. There are two more problems here that do not exist inside NR. One is that a handover to LTE can be unnecessary even when nothing fails. The other is ping-pong between the two systems. Neither of them produces an RLF, so they need other detection methods.
Too Late / Too Early inter-system HO : the same idea as above, but the UE comes back to an E-UTRAN cell. A too early case is reported to the eNB with Uplink RAN Configuration Transfer over NG.Mobility failure for voice fallback : a failure during or shortly after an NR to LTE handover for voice fallback. The RLF report shows it with voiceFallbackHO-r18.Unnecessary HO : the UE was moved from NR to LTE even though NR was good enough. The gNB puts coverage and quality thresholds in HANDOVER REQUIRED. The eNB keeps measuring NR cells for the UE for a while. If NR stayed above the thresholds in all reports, it sends a report back to the gNB.Ping-pong : the UE goes 5GS to EPS and back within a short time while the 5GS coverage was enough. This is detected from the UE History Information in HANDOVER REQUIRED. Voice fallback is not counted as ping-pong.
SHR - Successful Handover Report
MRO based on failures has an obvious limit. It only learns when something has already failed. But many handovers succeed only barely. The UE accessed the target just before T304 expired, or the source was already in T310 when the handover started. These are failures that almost happened. If the network could see them, it could correct the parameters before real failures start. This is the motivation for the SHR, added in Release 17.
The SHR is not created for every handover. That would be far too much data. The source cell configures thresholds with successHO-Config-r17 in otherConfig, and the UE creates an SHR only when a handover succeeds but one of the thresholds is exceeded. Each threshold is a percentage of a timer. The UE compares how much of the timer was used with the configured percentage, as shown in Figure 3.
Figure 3. SHR trigger by timer threshold. The values are an example. Any one timer that passes its threshold is enough to store an SHR, and the SHR cause tells which one it was.
T304 : the ratio of the elapsed T304 to its configured value, from the reconfigurationWithSync that the UE executed. A high ratio means the RA in the target took almost all the allowed time.T310 : T310 was running in the source when the handover was executed, and the elapsed part is above the threshold. The source radio link was already failing. This points to a handover that came late.T312 : T312 associated with the measurement identity of the target was running, and the elapsed part is above the threshold. The UE was close to the fast RLF trigger.sourceDAPS-FailureReporting : for DAPS, an RLF in the source while T304 was running. The handover succeeded, but the source link broke during it. This is the one case where an SHR detects a Too Late handover.
Following is based on
SuccessHO-Config-r17 ::= SEQUENCE {
thresholdPercentageT304-r17 ENUMERATED {p40, p60, p80, spare5, spare4, spare3, spare2, spare1} OPTIONAL, --Need R
thresholdPercentageT310-r17 ENUMERATED {p40, p60, p80, spare5, spare4, spare3, spare2, spare1} OPTIONAL, --Need R
thresholdPercentageT312-r17 ENUMERATED {p20, p40, p60, p80, spare4, spare3, spare2, spare1} OPTIONAL, --Need R
sourceDAPS-FailureReporting-r17 ENUMERATED {true} OPTIONAL, --Need R
...
}
SuccessHO-Report-r17 ::= SEQUENCE {
sourceCellInfo-r17 SEQUENCE {
sourcePCellId-r17 CGI-Info-Logging-r16,
sourceCellMeas-r17 MeasResultSuccessHONR-r17 OPTIONAL,
rlf-InSourceDAPS-r17 ENUMERATED {true} OPTIONAL
},
targetCellInfo-r17 SEQUENCE {
targetPCellId-r17 CGI-Info-Logging-r16,
targetCellMeas-r17 MeasResultSuccessHONR-r17 OPTIONAL
},
measResultNeighCells-r17 SEQUENCE {
measResultListNR-r17 MeasResultList2NR-r16 OPTIONAL,
measResultListEUTRA-r17 MeasResultList2EUTRA-r16 OPTIONAL
} OPTIONAL,
locationInfo-r17 LocationInfo-r16 OPTIONAL,
timeSinceCHO-Reconfig-r17 TimeSinceCHO-Reconfig-r17 OPTIONAL,
shr-Cause-r17 SHR-Cause-r17 OPTIONAL,
ra-InformationCommon-r17 RA-InformationCommon-r16 OPTIONAL,
upInterruptionTimeAtHO-r17 UPInterruptionTimeAtHO-r17 OPTIONAL,
c-RNTI-r17 RNTI-Value OPTIONAL,
...,
[[
targetCell-PCI-ARFCN-r17 PCI-ARFCN-NR-r16 OPTIONAL
]],
[[
eutra-TargetCellInfo-r18 SEQUENCE {
targetPCellId-r18 CHOICE {
cellGlobalId-r18 CGI-Info-Logging-r16,
pci-arfcn-r18 PCI-ARFCN-EUTRA-r16
},
targetCellMeas-r18 MeasQuantityResultsEUTRA OPTIONAL
} OPTIONAL,
measResultServCellRSSI-r18 RSSI-Range-r16 OPTIONAL,
measResultNeighFreqListRSSI-r18 MeasResultNeighFreqListRSSI-r18 OPTIONAL,
eutra-C-RNTI-r18 EUTRA-C-RNTI OPTIONAL,
timeSinceSHR-r18 TimeSinceSHR-r18 OPTIONAL
]],
[[
sourceCellMeasL1-r19 MeasResultL1-r19 OPTIONAL,
targetCellMeasL1-r19 MeasResultL1-r19 OPTIONAL,
neighCellsMeasL1ListNR-r19 MeasResultList3NR-r19 OPTIONAL,
rach-Less-r19 ENUMERATED {true} OPTIONAL,
sourcePSCellInfo-r19 SEQUENCE {
sourcePSCellId-r19 CGI-Info-Logging-r16,
sourcePSCellMeas-r19 MeasResultSuccessHONR-r17 OPTIONAL
} OPTIONAL,
cho-WithCandidateSCGInfoList-r19 CHO-WithCandidateSCGInfoList-r19 OPTIONAL,
targetPSCellID-r19 CHOICE {
cellGlobalId-r19 CGI-Info-Logging-r16,
pci-arfcn-r19 PCI-ARFCN-NR-r16
} OPTIONAL
]]
}
SHR-Cause-r17 ::= SEQUENCE {
t304-cause-r17 ENUMERATED {true} OPTIONAL,
t310-cause-r17 ENUMERATED {true} OPTIONAL,
t312-cause-r17 ENUMERATED {true} OPTIONAL,
sourceDAPS-Failure-r17 ENUMERATED {true} OPTIONAL,
...
}
sourceCellInfo / targetCellInfo : the source and target PCell with the cell and beam level RSRP, RSRQ and SINR collected up to the moment the UE sent RRCReconfigurationComplete. So the gNB can see how the two cells compared at the moment of the handover.shr-Cause : which threshold triggered the report. More than one flag can be set.timeSinceCHO-Reconfig : for CHO, the time from receiving the CHO configuration of the target until the execution, in units of 100 ms.ra-InformationCommon : the RA in the target cell. With a T304 cause, this shows why the access took so long.upInterruptionTimeAtHO : for DAPS, the gap between the last PDCP PDU from the source and the first new PDCP PDU from the target. It shows how well DAPS kept its zero interruption promise.c-RNTI : the C-RNTI assigned by the target PCell, so that the target can find the UE context.eutra-TargetCellInfo-r18 / timeSinceSHR-r18 : Release 18 extends SHR to the handover from NR to E-UTRA (MobilityFromNRCommand), with T310 and T312 triggers. Since the UE may return to NR much later, timeSinceSHR tells how long ago the handover was.
Who gets the SHR ? The UE gives it to whatever gNB asks, usually the target. If the cause is T310 or T312, the problem is in the source cell. So the target node forwards the SHR to the source node with ACCESS AND MOBILITY INDICATION over Xn, or over NG. If the node that fetches the SHR is neither the source nor the target, it forwards it to the node that configured the threshold. One more practical point: a handover that succeeds and then fails shortly after can create both an SHR and an RLF report. The node may decide to ignore the SHR in that case, because the RLF report already describes the event.
SPR - Successful PSCell Change or Addition Report
SHR covers the PCell. But in NR-DC and EN-DC, the PSCell also changes, and a PSCell change can also succeed just barely. Release 18 applies the same idea to the SCG and calls it SPR. The configuration and the trigger rules are almost a copy of SHR, with timers of the SCG. The new difficulty is that two nodes are involved, the MN and the SN, and either of them may have started the change.
Why does it matter who started it ? Because the T310 and T312 thresholds must come from the node that owns the measurement that triggered the change. The flag sn-InitiatedPSCellChange-r18 tells this. If the change was SN initiated, the UE uses the T310 and T312 thresholds configured by the source PSCell. If not, it uses the thresholds configured by the PCell. The T304 threshold works the same way in both cases.
Following is based on
SuccessPSCell-Config-r18 ::= SEQUENCE {
thresholdPercentageT304-SCG-r18 ENUMERATED {p40, p60, p80, spare5, spare4, spare3, spare2, spare1} OPTIONAL, --Need R
thresholdPercentageT310-SCG-r18 ENUMERATED {p40, p60, p80, spare5, spare4, spare3, spare2, spare1} OPTIONAL, --Need R
thresholdPercentageT312-SCG-r18 ENUMERATED {p20, p40, p60, p80, spare4, spare3, spare2, spare1} OPTIONAL, --Need R
...
}
SuccessPSCell-Report-r18 ::= SEQUENCE {
pCellId-r18 CGI-Info-Logging-r16,
sourcePSCellInfo-r18 SEQUENCE {
sourcePSCellId-r18 CHOICE {
cellGlobalId-r18 CGI-Info-Logging-r16,
pci-arfcn-r18 PCI-ARFCN-EUTRA-r16
},
sourcePSCellMeas-r18 MeasResultSuccessHONR-r17 OPTIONAL
} OPTIONAL,
targetPSCellInfo-r18 SEQUENCE {
targetPSCellId-r18 CHOICE {
cellGlobalId-r18 CGI-Info-Logging-r16,
pci-arfcn-r18 PCI-ARFCN-NR-r16
},
targetPSCellMeas-r18 MeasResultSuccessHONR-r17 OPTIONAL
},
measResultNeighCells-r18 SEQUENCE {
measResultListNR-r18 MeasResultList2NR-r16 OPTIONAL,
measResultListEUTRA-r18 MeasResultList2EUTRA-r16 OPTIONAL
} OPTIONAL,
spr-Cause-r18 SPR-Cause-r18 OPTIONAL,
timeSinceCPAC-Reconfig-r18 TimeSinceCPAC-Reconfig-r18 OPTIONAL,
locationInfo-r18 LocationInfo-r16 OPTIONAL,
ra-InformationCommon-r18 RA-InformationCommon-r16 OPTIONAL,
sn-InitiatedPSCellChange-r18 ENUMERATED {true} OPTIONAL,
...,
[[
cho-WithCandidateSCGInfoList-r19 CHO-WithCandidateSCGInfoList-r19 OPTIONAL,
targetPCellID-r19 CHOICE {
cellGlobalId-r19 CGI-Info-Logging-r16,
pci-arfcn-r19 PCI-ARFCN-NR-r16
} OPTIONAL,
c-RNTI-r19 RNTI-Value OPTIONAL
]]
}
SPR-Cause-r18 ::= SEQUENCE {
t304-cause-r18 ENUMERATED {true} OPTIONAL,
t310-cause-r18 ENUMERATED {true} OPTIONAL,
t312-cause-r18 ENUMERATED {true} OPTIONAL,
...
}
successPSCell-Config-r18 : configured in OtherConfig-v1800. It is a SetupRelease, so the network can switch it on and off.pCellId : the PCell at the time of the PSCell change. This tells which MN was in charge.sourcePSCellInfo : absent for a PSCell addition, because there was no source PSCell.timeSinceCPAC-Reconfig-r18 : for conditional PSCell addition or change (CPAC), the time from receiving the conditional configuration until the execution.spr-Cause : which of the three SCG timers exceeded its threshold.
The UE makes the SPR available to gNBs, and keeps it for 48 hours. When a gNB fetches it, it forwards the SPR to the MN that was serving the UE when the SPR was generated, using ACCESS AND MOBILITY INDICATION over Xn or the RAN configuration transfer over NG. The MN can then decide whether to involve the SN. A failed PSCell change is a different story. It is reported in SCGFailureInformation, and the MN analyses it and passes the result to the SN, as described in TS 37.340.
Release Evolution
Most of the UE side SON in NR came in Release 16, in the same work item as NR MDT. Release 17 and Release 18 mostly followed the new mobility features. Every time 3GPP added a new type of handover, such as CHO, DAPS, CPAC or LTM, the SON reports needed new fields to describe its failures and its near misses. The table below shows this pattern. Release 19 items in the latest ASN.1 are listed in the last row only for reference.
Release |
SON related additions in NR |
Rel-16 |
RA report for 4-step RA, NR RLF report and cross-RAT LTE RLF report, CEF report, MRO for intra-system and inter-system mobility, MLB and RACH optimization, mobility history report, LBT failure as an RLF cause for NR-U |
Rel-17 |
SHR (T304, T310, T312 and DAPS source failure triggers), RLF report for CHO and DAPS with two consecutive failures, 2-step RA and on-demand SI information in the RA report, spCellID in the RA report, T312 expiry as an RLF cause |
Rel-18 |
SPR for PSCell change and addition, SCG failure and fast MCG recovery information in the RLF report, voice fallback failure indication, SHR for NR to E-UTRA handover, NR-U RSSI and LBT information, RA report for SDT, feature combination information in the RA report |
Rel-19 |
LTM and CHO with candidate SCG in the RLF report, SHR and SPR, L1 measurement results, SDT failure cause in the RA report |
Reference
- 3GPP TS 38.300 V19.4.0 : NR; NR and NG-RAN Overall description; Stage-2. Clause 15 (Self-Configuration and Self-Optimisation)
- 3GPP TS 38.331 V19.4.0 : NR; Radio Resource Control (RRC) protocol specification. Clause 5.7.10 (UE Information)
- 3GPP TS 37.320 V19.4.0 : Radio measurement collection for Minimization of Drive Tests (MDT); Overall description; Stage 2
- MDT for NR (ShareTechnote)
- CHO, DAPS, LTM, RACH (ShareTechnote)