Description
The Successful Handover Report (SHR) is a key enabler for advanced mobility management and Self-Organizing Network (SON) functionalities in 5G NR and evolved LTE networks. It is a structured message generated by the target node (gNB or eNB) upon the successful completion of a handover and sent back to the source node. Unlike basic handover completion signals, the SHR contains a rich set of contextual data about the radio conditions and configuration at the moment of handover execution. This report is defined within the context of the Xn Application Protocol (XnAP) and NG Application Protocol (NGAP) for inter-gNB and inter-system communication, as referenced in specifications like TS 38.423 and TS 38.413.
The report's content is comprehensive. It typically includes the Cell Radio Network Temporary Identifier (C-RNTI) assigned to the User Equipment (UE) in the target cell, detailed measurement results reported by the UE just before the handover (e.g., Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ)), and the specific configuration of the radio bearers that were successfully established. Furthermore, it can contain timestamps and identifiers for the specific handover command. This granular data allows the source node to build a historical record of handover outcomes correlated with the radio conditions that triggered the handover decision.
Architecturally, the SHR flows over the Xn interface between gNBs or the NG interface between an eNB and a 5GC. Its generation and consumption are integral to Mobility Robustness Optimization (MRO) algorithms. By analyzing sequences of SHRs (and their counterpart, the Handover Failure Report), the network can detect issues like too-early, too-late, or handovers to wrong cells. The source node can then adjust its handover control parameters, such as hysteresis margins, time-to-trigger, or cell individual offsets, in an automated or semi-automated manner. This closed-loop optimization is vital for maintaining seamless mobility in dense, heterogeneous 5G deployments with complex interference scenarios.
Purpose & Motivation
The SHR was introduced to address the limitations of earlier mobility management systems, which often relied on simplistic success/failure indicators or required extensive drive testing and manual analysis to optimize handover parameters. In 4G LTE, SON features began automating optimization, but the data exchange was often less detailed. The advent of 5G, with its use of higher frequencies (mmWave), ultra-dense networks, and demanding use cases like ultra-reliable low-latency communication (URLLC), created a pressing need for more intelligent and data-driven mobility management.
The primary problem SHR solves is the lack of visibility for the source node into the *result* of its handover decision. Before SHR, a source node would command a handover and might receive an acknowledgment of completion, but not the detailed context of *why* it succeeded under those specific radio conditions. This made troubleshooting suboptimal handovers and fine-tuning algorithms inefficient. The SHR provides this crucial feedback, enabling the source node to learn from every handover event. Its creation was motivated by the desire to enhance SON capabilities, reduce operational expenditure (OPEX) by minimizing manual optimization, and fundamentally improve mobility robustness—a critical factor for user experience and network performance in advanced 5G systems.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (110 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 15, the SHR (Successful Handover Report) function was enhanced to support new reporting mechanisms and integration with broader network management services. Specifically, it was integrated into the trace and reporting framework, allowing SHR data to be reported via file-based or stream-based methods alongside other reports like RLF and RRC reports. The release also introduced clearer configuration and control parameters for these reports within the TraceJob and PerfMetricJob management objects.
- CR on U-plane handling for handover TS 38.300CR0029
- CR on message content in inter-RAT handover TS 38.300CR0030
- Delay budget report and MAC CE adaptation for NR for TS 38.300 TS 38.300CR0042
- Successful acknowledgement of RRCConnectionRelease for BL and CE UE TS 36.331CR3324
- CR for security handling upon handover to eLTE in 36.331 TS 36.331CR3583
- Access barring check after handover for eLTE TS 36.331CR3593
+ 39 more changes
In Release 16, the enhancements for the SHR (Successful Handover Report) function included specific corrections and clarifications for reporting within the TraceJob framework, such as refinements to RLF report storage and reporting configurations. The release also introduced new capabilities for reporting, including the option for stream-based reporting alongside file-based methods, with detailed attributes like `traceReportingConsumerUri` for defining streaming targets. Furthermore, it standardized the association of reports using a `jobId` and allowed for more granular control over the reporting process, including the handling of reporting periods and administrative states for performance measurement jobs.
- Support of inter-RAT handover from NR to EN-DC in TS 36.331 TS 36.331CR4232
- Correction and clarification of reporting in TraceJob (stage2) TS 28.622CR0115
- Allowing PDCP version change without handover TS 36.331CR4262
- Correction on UAI during handover TS 36.331CR4454
- Capability for beam level NR early measurement reporting TS 36.331CR4463
- Introducing power sharing for DAPS handover TS 36.331CR4517
+ 16 more changes
In Release 17, specific corrections were made to refine the Successful Handover Report (SHR) function for NR mobility. The release included a correction specifically for intra-NR mobility scenarios within the SHR. These updates were part of broader enhancements to measurement and reporting procedures, such as those for event-triggered measurements.
- On introducing height information reporting in MDT reports [LTE-Height-MDT] TS 36.331CR4756
- Introduction of gNB ID length reporting in the NR CGI report [gNB_ID_Length] TS 36.331CR4821
- Introduction of gNB ID length reporting in the NR CGI report [gNB_ID_Length] TS 38.300CR0474
- Support of Multiple CSI Subframe Sets on CQI-ReportPeriodicScell TS 36.331CR4899
- Correction on definition of ta-Report TS 36.331CR4933
- SHR correction TS 38.300CR0608
+ 4 more changes
In Release 18, the SHR (Successful Handover Report) function was enhanced by introducing a UE capability for **A4 A5 ReportOnLeave**, allowing more detailed event-triggered reporting. Furthermore, corrections were made to ensure proper **transfer of PDU Set Information during data forwarding for Xn handover** and to clarify the usage of **reportAmount** attributes within Immediate MDT configurations for both LTE and NR.
- Report Amount for M4, M5, M6 and M7 measurements in LTE TS 28.622CR0272
- Rel-18 CR TS 28.622 Report Amount parameter in NR TS 28.622CR0288
- Rel-18 CR TS 28.622 Aligning ReportAmount LTE parameters with ImmediateMDT datatype TS 28.622CR0287
- Rel-18 CR 28.622 Clarification on usage of reportAmount attributes in ImmediateMdtConfig TS 28.622CR0383
- Correction on QoE measurements release at successful handover from LTE/5GC to NR TS 36.331CR5062
- Correction to NR Beam Reporting in LTE RRC TS 36.331CR5069
+ 13 more changes
In Release 19, the SHR function was enhanced by introducing the capability to trace new RRC reports and adding RRC reports to missing IOCs (Information Object Classes). This included support for both file-based and stream-based reporting methods for these reports, configurable via the `rrcReportType` and `traceReportingFormat` attributes. Additionally, corrections were made to the handling of RRC reporting and PDU sets during handover procedures.
- Rel-19 CR 28.622 Trace new RRC reports TS 28.622CR0438
- Rel-19 CR TS 28.622 Add RRC report in missing IOCs TS 28.622CR0526
- Rel-19 CR 32.421 Trace new RRC reports TS 32.421CR0138
- Introduction of ANR reporting of HSDN cells [ANR_HSDN] TS 36.331CR5110
- Support Aerial UE Flight Information Reporting TS 38.300CR1031
- Rel-19 CR 28.622 Corrections for tracing of RRC reports TS 28.622CR0473
+ 8 more changes
Explore further
Broader topics and technologies where SHR plays a role.
Defining Specifications
3GPP specifications that define or reference SHR, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 28.622 vk20 | Telecommunication Management; Generic NRM Information Service | Rel-20 |
| TS 32.421 vj30 | Subscriber & Equipment Trace Concepts & Requirements | Rel-19 |
| TS 32.422 vk00 | Telecom Management: Trace Control & Configuration | Rel-20 |
| TS 36.331 vj00 | LTE RRC Protocol Specification | Rel-19 |
| TS 38.300 vj00 | NG-RAN Overall Description | Rel-19 |