A UE is receiving data from one cell and then appears on another. What moved: the beam, the serving cell, the gNB, or even the core-network path? Those cases can produce similar radio logs but very different messages on Xn, NG and F1. This note follows the decision from measurements to target access and then to data-path cleanup. It starts with NR standalone (SA) in RRC_CONNECTED. NSA and inter-system mobility are separated later so that an SgNB change is not mistaken for a 5GC handover.
- What counts as mobility in NR ?
- What causes a handover decision ?
- How Xn-based handover works ?
- How N2-based handover works ?
- What if both cells belong to one gNB ?
- What does the UE receive ?
- How does user data survive ?
- How conditional handover works ?
- How DAPS handover works ?
- How L1/L2 triggered mobility differs ?
- What about NSA and inter-system mobility ?
- What happens when handover fails ?
- How to read a handover trace ?
- Key ASN.1 structures
- Reference
What counts as mobility in NR ?
The word mobility covers several different changes. A beam switch can keep the same serving cell. A cell handover changes the UE's serving PCell. A gNB change adds context transfer between nodes, and perhaps a new route from the UPF. Before reading any message name, locate the boundary that the UE crossed.
Cell mobility and beam mobility
TS 38.300 separates cell-level mobility from beam-level mobility for an RRC_CONNECTED UE. A beam change can be controlled at PHY/MAC while the cell and RRC connection remain in place. Inter-cell beam management may even use a TRP with another PCI for UE-dedicated transmission; that alone does not prove that the PCell changed.
A cell-level handover normally applies a target-cell RRC configuration and changes the serving PCell. The UE may use a new C-RNTI, synchronize with a new cell and perform random access. The source and target may still be inside one gNB. If so, the UE performs a radio handover but no inter-gNB XnAP HANDOVER REQUEST appears. L1/L2 Triggered Mobility (LTM) is a distinct MAC-triggered cell-switch mechanism, described later, so a PCell change does not always begin with an immediate RRC handover command.
Which handover path applies ?
For a planned cell change in NR SA, first determine who controls the source and target cells. Then look for the interface that prepares the target. A link shown in a topology drawing does not prove that a particular UE used that link for its handover.
Case | Preparation | Core completion |
|---|---|---|
Intra-gNB | Internal gNB control; F1AP if source and target DUs differ | No inter-gNB Xn or N2 handover; an NG-U endpoint update depends on implementation and architecture |
Inter-gNB, Xn-based | Source and target exchange XnAP HANDOVER REQUEST / ACKNOWLEDGE | Target sends NGAP PATH SWITCH REQUEST to AMF after UE arrival |
Inter-gNB, N2-based | Source sends NGAP HANDOVER REQUIRED to AMF; AMF requests target resources | Target sends NGAP HANDOVER NOTIFY; no Xn-style path-switch step |
There is no rule that every NR SA handover uses Xn. Xn-based and N2-based are alternatives for inter-gNB preparation, not two mandatory legs of one procedure. Also, an intra-gNB handover is not synonymous with an inter-DU move: both cells can reside in one DU, or in different DUs under the same gNB-CU.
Cell change is not necessarily node change : inspect the gNB-CU boundary.Beam change is not necessarily handover : verify a PCell change and its trigger.Xn and N2 are alternatives : identify where target preparation occurred.
What causes a handover decision ?
The UE does not normally choose a target gNB for an immediate network-controlled handover. It measures, sends the configured reports, and follows the command from the network. The source gNB combines those measurements with policy, load, coverage, restrictions and target availability before it prepares a move.
Measurements and events
NR RRC MeasConfig connects a measurement object to a reporting configuration and a measurement identity. The object says which frequency and cells to measure. The report configuration defines an event or periodic reporting rule. For example, an A3 event can report a neighbour that becomes better than the serving cell by an offset. An A5 event can require the serving cell to fall below one threshold and the neighbour to rise above another.
The UE may report cell-level and beam-level quantities based on SSB or CSI-RS, such as RSRP, RSRQ or SINR. One report is evidence for the source gNB, not a command to move. Filtering, hysteresis and time-to-trigger can delay a report, while the gNB's own RRM decision can consider information that is not visible in the UE log.
The source gNB decision
The source checks whether the target can serve the UE's PDU sessions, slices and QoS flows. It may also consider UE capabilities, mobility restrictions, target-cell load and the availability of an Xn relation. The target makes its own admission decision during preparation; a good radio measurement does not guarantee admission.
This distinction is useful when debugging a trace. A MeasurementReport with a strong neighbour may be followed by no handover because the source does not select it. An XnAP HANDOVER REQUEST can fail because the target rejects resources. A prepared target can still never receive the UE because radio execution fails. Those are three different failure points and they need different evidence.
Measurement is input : the gNB decides whether to start preparation.Admission is another decision : the target can decline a requested PDU session or the whole handover.Execution is separate : preparation success does not prove that the UE reached the target.
How Xn-based handover works ?
Consider a UE moving between two gNBs that can communicate directly over Xn. The gNBs prepare the UE without involving the 5GC in the preparation and radio execution phases. The target contacts the AMF only after the UE has arrived, to move the core-network user-plane route.
Figure 1 keeps Xn-C, NR Uu, Xn-U and NG-C separate. The arrows show the principal successful path, not every optional forwarding or security message. Read the vertical order as preparation, execution and completion.
Figure 1. The target prepares the radio move over Xn, then asks the 5GC to redirect downlink traffic after the UE arrives.
The following steps use one synthetic UE: PLMN 001-01, source UE XnAP ID 12001, target UE XnAP ID 54002, PDU session 10 and DRB 1. Each JER block is a selected-IE excerpt of a decoded message, not a complete on-the-wire PDU. Encapsulated RRC and transfer containers remain hex OCTET STRINGs at the outer protocol layer.
Step 1. Source requests target admission
The source sends XnAP HANDOVER REQUEST for target NR cell 0x123456789. IE 73 ties the request to the source UE context; IE 78 identifies the target cell; IE 83 carries the UE context, including the requested PDU session.
XnAP HandoverRequest, selected-IE JER; synthetic values.
{ "initiatingMessage": { "procedureCode": 0, "criticality": "reject", "value": { "protocolIEs": [
{ "id": 73, "criticality": "reject", "value": 12001 },
{ "id": 7, "criticality": "reject", "value": { "radioNetwork": "handover-desirable-for-radio-reasons" } },
{ "id": 78, "criticality": "reject", "value": { "nr": { "plmn-id": "00f110", "nr-CI": "1234567890" } } },
{ "id": 83, "criticality": "reject", "value": { "ng-c-UE-reference": 1870000001,
"pduSessionResourcesToBeSetup-List": [ { "pduSessionId": 10, "s-NSSAI": { "sst": "01" } } ] } }
] } } }
Step 2. Target returns an admitted configuration
The target allocates UE XnAP ID 54002 and admits session 10. XnAP HANDOVER REQUEST ACKNOWLEDGE carries its target-to-source transparent container as encoded bytes; the source later extracts the UE-facing radio command from that container.
XnAP HandoverRequestAcknowledge, selected-IE JER; synthetic values.
{ "successfulOutcome": { "procedureCode": 0, "criticality": "reject", "value": { "protocolIEs": [
{ "id": 73, "criticality": "ignore", "value": 12001 },
{ "id": 79, "criticality": "ignore", "value": 54002 },
{ "id": 42, "criticality": "ignore", "value": [ { "pduSessionId": 10,
"pduSessionResourceAdmittedInfo": { "qosFlowsAdmitted-List": [ { "qfi": 9 } ] } } ] },
{ "id": 77, "criticality": "ignore", "value": "0140a8804a21c801" }
] } } }
Step 3. Source commands the UE and transfers status
The source sends RRCReconfiguration on Uu. The UE sees target C-RNTI 0x4A21 and T304 = 100 ms in the separately decoded masterCellGroup. For a bearer requiring PDCP continuity, the source also sends XnAP SN STATUS TRANSFER; optional Xn-U packet forwarding is GTP-U, not ASN.1.
NR RRCReconfiguration and decoded CellGroupConfig, then XnAP SNStatusTransfer; selected-IE JER.
{ "rrc-TransactionIdentifier": 1, "criticalExtensions": { "rrcReconfiguration": {
"nonCriticalExtension": { "masterCellGroup": "0408094424" } } } }
{ "cellGroupId": 0, "spCellConfig": { "reconfigurationWithSync": {
"newUE-Identity": 18977, "t304": "ms100" } } }
{ "initiatingMessage": { "procedureCode": 1, "criticality": "ignore", "value": { "protocolIEs": [
{ "id": 73, "criticality": "reject", "value": 12001 },
{ "id": 79, "criticality": "reject", "value": 54002 },
{ "id": 12, "criticality": "ignore", "value": [ { "drbID": 1,
"pdcpStatusTransfer-DL": { "pdcp-sn-18bits": { "cOUNTValue": {
"pdcp-SN18": 104, "hfn-PDCP-SN18": 0 } } } } ] }
] } } }
Step 4. UE accesses the target
The UE synchronizes and completes any required random access, then sends RRCReconfigurationComplete to the target. PRACH itself is a physical-layer procedure with no ASN.1 JER. The completion repeats transaction identifier 1 and confirms radio execution.
NR RRCReconfigurationComplete JER; synthetic values.
{ "rrc-TransactionIdentifier": 1,
"criticalExtensions": { "rrcReconfigurationComplete": {} } }
Step 5. Target switches the core path
The target sends NGAP PATH SWITCH REQUEST for the newly served UE and session 10. The AMF and 5GC update the downlink route, then return PATH SWITCH REQUEST ACKNOWLEDGE. A successful acknowledgement is the checkpoint before the target orders source release.
NGAP PathSwitchRequest and PathSwitchRequestAcknowledge, selected-IE JER.
{ "initiatingMessage": { "procedureCode": 25, "criticality": "reject", "value": { "protocolIEs": [
{ "id": 85, "criticality": "reject", "value": 54002 },
{ "id": 100, "criticality": "reject", "value": 1870000001 },
{ "id": 76, "criticality": "reject", "value": [ { "pDUSessionID": 10,
"pathSwitchRequestTransfer": "00010a0a02141234abcd" } ] }
] } } }
{ "successfulOutcome": { "procedureCode": 25, "criticality": "reject", "value": { "protocolIEs": [
{ "id": 10, "criticality": "ignore", "value": 1870000001 },
{ "id": 85, "criticality": "ignore", "value": 54002 },
{ "id": 77, "criticality": "ignore", "value": [ { "pDUSessionID": 10,
"pathSwitchRequestAcknowledgeTransfer": "00010a0a640a00ab1201" } ] }
] } } }
Step 6. Target releases the source context
The target sends XnAP UE CONTEXT RELEASE with both UE XnAP IDs. Those IDs identify the prepared source context to remove; releasing the UE context does not tear down the gNB-to-gNB Xn association.
XnAP UEContextRelease, selected-IE JER.
{ "initiatingMessage": { "procedureCode": 6, "criticality": "reject", "value": { "protocolIEs": [
{ "id": 73, "criticality": "reject", "value": 12001 },
{ "id": 79, "criticality": "reject", "value": 54002 }
] } } }
Preparation between gNBs
The source sends XnAP HANDOVER REQUEST with the target cell global ID, a cause, the serving AMF identity and UE context. The context includes AS security information, PDU session resources, QoS flow information and a transparent RRC context. The target performs admission control and answers with HANDOVER REQUEST ACKNOWLEDGE. Its response includes admitted PDU sessions, a target-side XnAP UE ID and the target-to-source transparent container holding the UE's handover command.
If the target cannot accept the handover, it returns HANDOVER PREPARATION FAILURE with a cause. The source must not treat a request sent on Xn as proof that target radio resources were reserved. It also must distinguish rejected individual PDU sessions from rejection of the complete UE move.
UE execution and status transfer
The source forwards the target-generated RRCReconfiguration over NR Uu. The UE applies the target configuration, synchronizes and accesses the target cell. On success it sends RRCReconfigurationComplete to the target. For an ordinary handover, the source may forward buffered downlink data over Xn-U and sends XnAP SN STATUS TRANSFER where PDCP status preservation applies.
The status message is not the handover command. It tells the target which PDCP COUNT values and receive state belong to the transferred DRBs. The forwarding tunnel is not an XnAP message either. In a trace, separate the Xn-C SCTP association from Xn-U GTP-U packets before reasoning about packet loss.
5GC path switch and source release
After target access, the target sends NGAP PATH SWITCH REQUEST on NG-C. The AMF coordinates the 5GC user-plane change; the UPF starts sending new downlink packets toward the target. NGAP PATH SWITCH REQUEST ACKNOWLEDGE confirms the switch. The target then sends XnAP UE CONTEXT RELEASE to the source so the old UE radio and control-plane context can be freed.
The Xn peer relation itself stays available. Also, forwarded packets can still arrive after the path switch while end markers and old tunnels are being drained. Do not equate the first packet at the target with completion of the whole handover. In TS 38.300 clause 9.2.3.2.1, the release follows the path-switch acknowledgement.
Xn prepares : the source and target exchange the UE context directly.NR Uu executes : the UE receives RRCReconfiguration and accesses the target.NG completes : the target requests path switch before source context release.
How N2-based handover works ?
An inter-gNB handover can use the 5GC to prepare the target instead of using Xn between the gNBs. This is called N2-based or NG-based handover. It is relevant when direct Xn preparation is unavailable or unsuitable, and it can support a core-network control-plane change. The exact core-internal sequence depends on whether AMF or UPF relocation is needed.
Figure 2 shows a same-AMF example. It deliberately shows the AMF between the gNBs: the source does not send an XnAP HANDOVER REQUEST to the target in this path.
Figure 2. N2 preparation routes through the AMF, so successful target arrival is reported with HANDOVER NOTIFY rather than an Xn-style path-switch request.
These N2 examples reuse AMF UE ID 1870000001 and PDU session 10 but show a separate, core-assisted path. The JER excerpts select the fields that explain each arrow; a production PDU contains additional mandatory context and transfer details. At NGAP level, transparent containers are encoded OCTET STRINGs.
Step 1. Source asks the AMF to initiate handover
NGAP HANDOVER REQUIRED identifies the UE, the target gNB and the affected session. The source-to-target container passes encoded radio context through the AMF; this is not an XnAP exchange.
NGAP HandoverRequired, selected-IE JER; synthetic values.
{ "initiatingMessage": { "procedureCode": 12, "criticality": "reject", "value": { "protocolIEs": [
{ "id": 10, "criticality": "reject", "value": 1870000001 },
{ "id": 85, "criticality": "reject", "value": 12001 },
{ "id": 29, "criticality": "reject", "value": "intra5gs" },
{ "id": 105, "criticality": "reject", "value": { "targetRANNodeID": {
"globalRANNodeID": { "globalGNB-ID": { "pLMNIdentity": "00f110",
"gNB-ID": { "gNB-ID": { "length": 24, "value": "000023" } } } },
"selectedTAI": { "pLMNIdentity": "00f110", "tAC": "000102" } } } },
{ "id": 61, "criticality": "reject", "value": [ { "pDUSessionID": 10,
"handoverRequiredTransfer": "00" } ] },
{ "id": 101, "criticality": "reject", "value": "0102a03b5c90" }
] } } }
Step 2. AMF requests target admission
The AMF sends NGAP HANDOVER REQUEST to the target. Its session list requests PDU session 10 and slice SST 1; the target uses the transferred context to allocate radio resources and a target-side UE association.
NGAP HandoverRequest, selected-IE JER.
{ "initiatingMessage": { "procedureCode": 13, "criticality": "reject", "value": { "protocolIEs": [
{ "id": 10, "criticality": "reject", "value": 1870000001 },
{ "id": 29, "criticality": "reject", "value": "intra5gs" },
{ "id": 73, "criticality": "reject", "value": [ { "pDUSessionID": 10,
"s-NSSAI": { "sST": "01", "sD": "010203" },
"handoverRequestTransfer": "00010a0a640a00ab1201" } ] },
{ "id": 101, "criticality": "reject", "value": "0102a03b5c90" }
] } } }
Step 3. Target admits the UE
NGAP HANDOVER REQUEST ACKNOWLEDGE returns target RAN UE ID 54002, the admitted session and a target-to-source transparent container. The AMF relays that radio container to the source in the next step.
NGAP HandoverRequestAcknowledge, selected-IE JER.
{ "successfulOutcome": { "procedureCode": 13, "criticality": "reject", "value": { "protocolIEs": [
{ "id": 10, "criticality": "ignore", "value": 1870000001 },
{ "id": 85, "criticality": "ignore", "value": 54002 },
{ "id": 53, "criticality": "ignore", "value": [ { "pDUSessionID": 10,
"handoverRequestAcknowledgeTransfer": "00010a0a02141234abcd" } ] },
{ "id": 106, "criticality": "reject", "value": "0140a8804a21c801" }
] } } }
Step 4. AMF commands the source; source commands the UE
NGAP HANDOVER COMMAND returns the accepted session and target radio container to the source. The source sends its extracted RRCReconfiguration on Uu. The outer RRC JER shows the encoded masterCellGroup; the separate CellGroupConfig decoding identifies the target C-RNTI and T304.
NGAP HandoverCommand, selected-IE JER.
{ "successfulOutcome": { "procedureCode": 12, "criticality": "reject", "value": { "protocolIEs": [
{ "id": 10, "criticality": "reject", "value": 1870000001 },
{ "id": 85, "criticality": "reject", "value": 12001 },
{ "id": 59, "criticality": "ignore", "value": [ { "pDUSessionID": 10,
"handoverCommandTransfer": "00010a0a0214" } ] },
{ "id": 106, "criticality": "reject", "value": "0140a8804a21c801" }
] } } }
{ "rrc-TransactionIdentifier": 1, "criticalExtensions": { "rrcReconfiguration": {
"nonCriticalExtension": { "masterCellGroup": "0408094424" } } } }
{ "cellGroupId": 0, "spCellConfig": { "reconfigurationWithSync": {
"newUE-Identity": 18977, "t304": "ms100" } } }
Step 5. UE arrives and target notifies the AMF
The UE performs target access and sends RRCReconfigurationComplete with transaction 1. The target then reports its new UE association and target NR location in NGAP HANDOVER NOTIFY. Physical random access has no ASN.1 JER message.
NR RRCReconfigurationComplete and NGAP HandoverNotify, selected-IE JER.
{ "rrc-TransactionIdentifier": 1,
"criticalExtensions": { "rrcReconfigurationComplete": {} } }
{ "initiatingMessage": { "procedureCode": 11, "criticality": "ignore", "value": { "protocolIEs": [
{ "id": 10, "criticality": "reject", "value": 1870000001 },
{ "id": 85, "criticality": "reject", "value": 54002 },
{ "id": 121, "criticality": "ignore", "value": { "userLocationInformationNR": {
"nR-CGI": { "pLMNIdentity": "00f110", "nRCellIdentity": "1234567890" },
"tAI": { "pLMNIdentity": "00f110", "tAC": "000102" } } } }
] } } }
Step 6. AMF orders old context release
After core path handling, the AMF sends NGAP UE CONTEXT RELEASE COMMAND to the source. It identifies the source-side NGAP UE association and gives a handover-related cause. Unlike Xn handover, this is an N2 command, not XnAP UE CONTEXT RELEASE.
NGAP UEContextReleaseCommand, selected-IE JER.
{ "initiatingMessage": { "procedureCode": 41, "criticality": "reject", "value": { "protocolIEs": [
{ "id": 114, "criticality": "reject", "value": { "uE-NGAP-ID-pair": {
"aMF-UE-NGAP-ID": 1870000001, "rAN-UE-NGAP-ID": 12001 } } },
{ "id": 15, "criticality": "ignore", "value": {
"radioNetworkCause": "successful-handover" } }
] } } }
The AMF prepares the target
The source sends NGAP HANDOVER REQUIRED with the UE's AMF and RAN NGAP IDs, target ID, cause, PDU session resource information and a source-to-target transparent container. The AMF selects or reaches the target and sends NGAP HANDOVER REQUEST. The target receives security context, allowed slice information and the PDU sessions to establish. It admits resources and returns NGAP HANDOVER REQUEST ACKNOWLEDGE with the admitted list and a target-to-source transparent container.
The AMF sends NGAP HANDOVER COMMAND to the source. Its transparent container carries the radio command generated for the target. If preparation fails, a HANDOVER PREPARATION FAILURE or HANDOVER FAILURE appears on the relevant N2 leg instead of a usable command. The two messages named HANDOVER REQUEST on Xn and NG are different protocol messages; always read their interface and sender.
The UE moves to the target
The source transmits the NR RRCReconfiguration handover command. The UE synchronizes to the target cell, obtains uplink timing if required and sends RRCReconfigurationComplete to the target. An N2-based handover can use direct or indirect data forwarding when arranged by the network, but that forwarding is a user-plane path, not an XnAP preparation transaction.
The target-generated RRC configuration reaches the UE through two control-plane relays: target to AMF, then AMF to source. The UE does not see this distinction on Uu. That is why an isolated RRC trace cannot tell whether target preparation used Xn or N2; a gNB or AMF trace is needed.
Completion is not an Xn path switch
After the UE arrives, the target sends NGAP HANDOVER NOTIFY to the AMF. The 5GC completes the session and user-plane update, including any needed SMF and UPF actions. The AMF later orders the old source context to be released with NGAP UE CONTEXT RELEASE COMMAND. An XnAP UE CONTEXT RELEASE is not expected, because XnAP did not prepare this handover.
Do not look for NGAP PATH SWITCH REQUEST as the mandatory completion message here. That request belongs to the Xn-prepared path, where the core first learns that the UE moved after target access. In N2 handover, the AMF participated from the beginning. The distinction is especially useful when a trace starts only at the completion phase.
HANDOVER REQUIRED identifies N2 preparation : it runs from source to AMF.HANDOVER NOTIFY identifies arrival : it runs from target to AMF.No XnAP request is required : do not infer one from the RRC handover command.
What if both cells belong to one gNB ?
A gNB can implement multiple cells. It can also split its control plane into a gNB-CU and one or more gNB-DUs. Thus, intra-gNB handover means that the source and target cells remain under one logical gNB; it does not necessarily mean one DU or one physical box. The UE still sees a target-cell radio change.
Figure 3 distinguishes two useful cases. The same-DU move is largely local inside the gNB. An inter-DU move needs F1 control and user-plane updates, even though it does not become an inter-gNB Xn or N2 handover.
Figure 3. The CU boundary, not the number of cells or DUs, decides whether a move is still intra-gNB.
Figure 3 is an architecture view rather than a message timeline. Read it as two preparation choices followed by the same UE-facing switch. The compact JER examples below show the target-cell radio command; only the inter-DU branch needs F1AP between the CU and a different target DU.
Step 1. Prepare the target cell
For a same-DU move, the gNB prepares Cell B locally. For an inter-DU move, the CU can request target UE context setup on the target DU. The F1AP IDs identify the CU and target DU context; SpCell ID identifies the target NR cell. This is not XnAP preparation.
Inter-DU F1AP UEContextSetupRequest, selected-IE JER; synthetic values.
{ "initiatingMessage": { "procedureCode": 5, "criticality": "reject", "value": { "protocolIEs": [
{ "id": 40, "criticality": "reject", "value": 3001 },
{ "id": 63, "criticality": "reject", "value": {
"pLMN-Identity": "00f110", "nRCellIdentity": "1234567890" } }
] } } }
The target DU responds with its DU UE F1AP ID when it has reserved radio resources. Subsequent F1-U routing is internal to the gNB; it does not imply a core-network path switch.
Inter-DU F1AP UEContextSetupResponse, selected-IE JER.
{ "successfulOutcome": { "procedureCode": 5, "criticality": "reject", "value": { "protocolIEs": [
{ "id": 40, "criticality": "reject", "value": 3001 },
{ "id": 41, "criticality": "reject", "value": 7201 }
] } } }
Step 2. Send and complete the cell-change command
The CU sends the UE an RRCReconfiguration for Cell B. Its masterCellGroup OCTET STRING decodes to a CellGroupConfig with the new target C-RNTI and T304. After target access, the UE sends RRCReconfigurationComplete with the same transaction identifier.
NR RRC command, decoded target configuration and completion JER.
{ "rrc-TransactionIdentifier": 2, "criticalExtensions": { "rrcReconfiguration": {
"nonCriticalExtension": { "masterCellGroup": "0408094424" } } } }
{ "cellGroupId": 0, "spCellConfig": { "reconfigurationWithSync": {
"newUE-Identity": 18977, "t304": "ms100" } } }
{ "rrc-TransactionIdentifier": 2,
"criticalExtensions": { "rrcReconfigurationComplete": {} } }
Same gNB-DU
When the source and target cells belong to one DU, the gNB can prepare the change locally. The CU may still manage the UE's RRC and bearer configuration over F1, but there is no target peer gNB to receive XnAP HANDOVER REQUEST. The UE receives a target-cell RRCReconfiguration and performs the indicated synchronization or access procedure.
Do not confuse a PCell handover with an SCell activation. Carrier aggregation can add or activate a secondary cell while the PCell stays where it is. A true handover changes the serving PCell context. Conversely, a beam or TRP switch can change the radio transmission point without changing the PCell at all.
Different gNB-DUs under one CU
If the target cell belongs to another DU under the same CU, the CU prepares resources on that target DU. F1AP UE CONTEXT SETUP or modification and F1-U tunnel changes may appear; the CU then sends the handover command to the UE and releases the old DU context after success. The exact F1 sequence depends on deployment and procedure variant.
This is the distinction a DU trace makes visible. There may be F1AP signalling even though there is no XnAP inter-gNB handover. If the source and target also share a CU-UP, the NG-U endpoint toward the UPF may remain stable while internal F1-U routing changes. Do not assert that every intra-gNB move needs an NGAP path switch.
Intra-gNB is a logical boundary : multiple DUs and cells may sit beneath one CU.F1 is not Xn : an inter-DU move can be visible on F1 without any inter-gNB XnAP request.
What does the UE receive ?
Whether the target was prepared internally, over Xn or through the AMF, the UE needs a radio command it can apply. For an ordinary NR RRC handover, that command is an RRCReconfiguration with target-cell configuration. The UE's response is RRCReconfigurationComplete after it has reached the target.
The target-generated RRC command
The RRCReconfiguration can carry a CellGroupConfig in its masterCellGroup container. Inside the SpCell configuration, reconfigurationWithSync gives the UE information for the target PCell: a new UE identity (C-RNTI), timer T304 and optionally dedicated RACH configuration. The target also provides the radio configuration needed to access without first reading the full target broadcast configuration.
For inter-gNB handover, the target creates the target-side configuration and passes it back in a transparent container. The source delivers it on Uu. The same RRC message name can therefore appear in both Xn and N2 handovers. Its presence does not identify the network-side preparation path. The source/target cell identities, the reconfigurationWithSync content and the matching XnAP or NGAP exchange provide that distinction.
Target access and random access
The UE synchronizes to the target's downlink and obtains an uplink opportunity. The command can provide dedicated contention-free RACH resources associated with SSB or CSI-RS beams. Otherwise the UE may use common RACH resources. Successful random access establishes target timing; the UE then sends RRCReconfigurationComplete to the target gNB.
Some configured cases avoid random access, such as supported RACH-less handover or RACH-less LTM. Do not treat the absence of a PRACH transmission as proof that no cell switch occurred. Conversely, a PRACH alone does not prove handover: initial access, beam recovery and other procedures use PRACH too. In a radio trace, correlate PRACH with the preceding RRC or MAC trigger and the later completion message.
The target configuration is the key : look forreconfigurationWithSync, target cell and new UE identity.RACH is conditional : check the particular handover or LTM variant.RRC alone does not name Xn or N2 : pair it with network-interface messages.
How does user data survive ?
Radio handover can succeed while user data is lost, duplicated or delivered out of order. The network therefore separates three jobs: forwarding packets already on the old path, preserving PDCP sequence state where needed, and changing the UPF's downlink destination. These jobs occur at different times and on different interfaces.
Forwarding is not path switch
The source may send buffered or newly arriving downlink data to the target while the UPF still routes packets to the source. In Xn-based handover, this can use Xn-U GTP-U tunnels. In N2-based handover, direct or indirect forwarding depends on the available paths. Forwarding protects an interval of data; it does not itself change the core-network route.
A forwarding endpoint is signalled in the admission outcome for the relevant PDU session, QoS flow or DRB. A tunnel may carry packets before the UE reaches the target and may continue briefly afterward. Read its TEID and destination separately from the normal NG-U tunnel toward the UPF.
PDCP status and sequence numbers
For bearers requiring status preservation, the source sends SN STATUS TRANSFER so the target knows the next downlink PDCP COUNT and the missing uplink PDCP SDUs. COUNT combines the PDCP sequence number with the hyper-frame number. The target uses this information to avoid repeating already delivered data or skipping outstanding packets.
The rule varies with RLC mode, PDCP re-establishment, security change and special handover modes. In ordinary Xn handover, the status transfer is an XnAP message. In DAPS or conditional handover, its timing can differ because the source may continue serving or forwarding longer. A trace reader should not assume that every bearer has an identical status item.
The new NG-U route
After an Xn-prepared UE arrives, NGAP PATH SWITCH REQUEST makes the target the new downlink endpoint. The 5GC updates the UPF path and acknowledges the request. The UPF may send end markers on the old tunnel to help the RAN distinguish packets that belonged to the old route. Only then does the target release the old source UE context.
For N2 handover, the AMF and session-management functions arrange the path as part of the core-assisted procedure, and target arrival is reported by HANDOVER NOTIFY. For intra-gNB moves, internal F1-U or CU-UP routing may change without a new inter-gNB path switch. Always identify which endpoint actually changes before looking for a particular NGAP message.
Forwarding covers in-flight packets : it is temporary and may use Xn-U.Status protects sequence continuity : it is control information, not user data.Path switch changes the core route : its message depends on the handover path.
How conditional handover works ?
In an ordinary handover, the network prepares one target and then sends a command for immediate execution. A fast-changing radio link can fail before the command reaches the UE. Conditional Handover (CHO) moves target preparation earlier and lets the UE execute a stored target configuration when its configured condition becomes true. This changes the timing of execution, not the need for target admission.
Figure 4 shows the important gap between configuration and execution. During that gap the UE remains connected to the source while it evaluates the candidate conditions.
Figure 4. CHO separates early network preparation from the later UE-triggered radio execution.
The CHO example uses candidate ID 3 and a configured measurement ID 5. JER snippets show the control messages relevant to the timing in Figure 4. The target's RRC command is nested as encoded bytes inside the conditional configuration, so it is decoded separately below.
Step 1. Prepare candidate resources over Xn
The source sends XnAP HANDOVER REQUEST for the candidate cell before the UE's execution condition becomes true. The target returns HANDOVER REQUEST ACKNOWLEDGE with its allocated UE ID and a candidate radio container. Preparation alone does not switch the UE.
XnAP preparation request and acknowledgement, selected-IE JER.
{ "initiatingMessage": { "procedureCode": 0, "criticality": "reject", "value": { "protocolIEs": [
{ "id": 73, "criticality": "reject", "value": 12001 },
{ "id": 78, "criticality": "reject", "value": { "nr": {
"plmn-id": "00f110", "nr-CI": "1234567890" } } },
{ "id": 158, "criticality": "reject", "value": {
"cho-trigger": "cho-initiation" } }
] } } }
{ "successfulOutcome": { "procedureCode": 0, "criticality": "reject", "value": { "protocolIEs": [
{ "id": 73, "criticality": "ignore", "value": 12001 },
{ "id": 79, "criticality": "ignore", "value": 54002 },
{ "id": 77, "criticality": "ignore", "value": "0140a8804a21c801" },
{ "id": 159, "criticality": "reject", "value": {
"requestedTargetCellGlobalID": { "nr": {
"plmn-id": "00f110", "nr-CI": "1234567890" } } } }
] } } }
Step 2. Source installs the condition at the UE
The source sends RRCReconfiguration containing conditionalReconfiguration. Candidate ID 3 binds measurement ID 5 to a stored RRC command. The source-side RRCReconfigurationComplete only acknowledges storage; it is not evidence of target access.
NR RRC conditional configuration and source-side completion, selected-field JER.
{ "rrc-TransactionIdentifier": 2, "criticalExtensions": { "rrcReconfiguration": {
"nonCriticalExtension": { "nonCriticalExtension": { "nonCriticalExtension": {
"nonCriticalExtension": { "conditionalReconfiguration-r16": {
"condReconfigToAddModList-r16": [ { "condReconfigId-r16": 3,
"condExecutionCond-r16": [ 5 ],
"condRRCReconfig-r16": "0140a8804a21c801" } ] } } } } } } } }
{ "rrc-TransactionIdentifier": 2,
"criticalExtensions": { "rrcReconfigurationComplete": {} } }
Step 3. UE executes the stored command
When measurement condition 5 is satisfied, the UE applies candidate 3's stored command and accesses its target cell. The nested command includes target C-RNTI 0x4A21 and T304 = 100 ms. The UE's later completion is sent to the target, not back to the source.
Separately decoded candidate CellGroupConfig and target-side completion JER.
{ "cellGroupId": 0, "spCellConfig": { "reconfigurationWithSync": {
"newUE-Identity": 18977, "t304": "ms100" } } }
{ "rrc-TransactionIdentifier": 1,
"criticalExtensions": { "rrcReconfigurationComplete": {} } }
Prepare candidates before the condition
The source may prepare one or more candidate cells, possibly at different gNBs. Each candidate target returns its own configuration. The source sends the UE an RRCReconfiguration containing candidate configurations and execution conditions. The UE acknowledges this configuration to the source but does not move yet.
TS 38.300 permits CHO conditions built from A3 or A5 events. A candidate can have one or two trigger conditions; the source determines the conditions while the candidate target determines its radio configuration. An XnAP HANDOVER REQUEST for CHO carries CHO-specific information. CHO is not supported for NG-C-based handover in Release 19, and a CHO candidate configuration cannot contain DAPS handover configuration.
The UE selects the moment to execute
The UE stays on the source while checking the configured conditions. Once a candidate condition is satisfied, the UE applies that stored target configuration, leaves the source and sends RRCReconfigurationComplete to the selected target. The target can inform the source of success. The source can then cancel unused candidate preparations and complete status transfer or forwarding for the chosen target.
Two traces can therefore show different times for the same handover: the Xn preparation may be much earlier than the UE's target access. If the UE never satisfies the condition, a prepared candidate may never become the serving cell. Do not count a CHO preparation message alone as a successful handover.
Prepared is not executed : the UE remains on the source until its condition is met.Several candidates may exist : only the selected target gets the UE.CHO is not DAPS : their candidate configurations cannot be combined.
How DAPS handover works ?
An ordinary break-before-make handover can interrupt user data while the UE leaves the source and accesses the target. Dual Active Protocol Stack (DAPS) handover reduces that interruption for configured DRBs. The UE keeps a source-side user-plane stack during target access, then releases it only after target success. DAPS is not simply a second normal handover running in parallel.
Figure 5 highlights the overlap interval. Control-plane signalling moves to the target, but source user-plane reception or transmission can continue under the DAPS rules until the target link is ready.
Figure 5. DAPS keeps selected source DRBs active until target success and an explicit source release.
Figure 5 is a timeline, so the steps below identify the messages at its three control checkpoints. The example uses DRB 1 for DAPS; other DRBs need not be DAPS bearers. The JER blocks select the DAPS-related fields and UE identifiers rather than attempting to show a complete bearer configuration.
Step 1. Prepare DAPS and command the UE
The source requests DAPS for DRB 1 in XnAP HANDOVER REQUEST. The target accepts that DRB in HANDOVER REQUEST ACKNOWLEDGE. The UE-facing RRCReconfiguration carries a radio bearer configuration whose decoded DRB item has daps-Config-r16 set to true.
XnAP DAPS preparation, selected-IE JER; synthetic values. DAPS request is nested under session forwarding information.
{ "initiatingMessage": { "procedureCode": 0, "criticality": "reject", "value": { "protocolIEs": [
{ "id": 73, "criticality": "reject", "value": 12001 },
{ "id": 83, "criticality": "reject", "value": {
"pduSessionResourcesToBeSetup-List": [ { "pduSessionId": 10,
"dataforwardinginfofromSource": { "qosFlowsToBeForwarded": [
{ "qosFlowIdentifier": 9, "dl-dataforwarding": "dl-forwarding-proposed",
"ul-dataforwarding": "ul-forwarding-proposed" } ],
"sourceDRBtoQoSFlowMapping": [ { "drb-ID": 1,
"qosFlows-List": [ { "qfi": 9 } ],
"iE-Extension": [ { "id": 163, "criticality": "ignore",
"value": { "dapsIndicator": "daps-HO-required" } } ] } ] } } ] } }
] } } }
{ "successfulOutcome": { "procedureCode": 0, "criticality": "reject", "value": { "protocolIEs": [
{ "id": 73, "criticality": "ignore", "value": 12001 },
{ "id": 79, "criticality": "ignore", "value": 54002 },
{ "id": 164, "criticality": "reject", "value": [ { "drbID": 1,
"dapsResponseIndicator": "daps-HO-accepted" } ] }
] } } }
Separately decoded NR RadioBearerConfig excerpt for the UE.
{ "drb-ToAddModList": [ { "drb-Identity": 1,
"daps-Config-r16": "true" } ] }
Step 2. UE keeps source data while accessing target
The UE retains source-side user-plane reception while it establishes the target link. After target access it sends RRCReconfigurationComplete. The target sends XnAP HANDOVER SUCCESS to the source, naming the prepared UE and selected target cell. Neither PRACH nor the user packets are ASN.1 JER messages.
NR RRC completion and XnAP HandoverSuccess, selected-IE JER.
{ "rrc-TransactionIdentifier": 1,
"criticalExtensions": { "rrcReconfigurationComplete": {} } }
{ "initiatingMessage": { "procedureCode": 29, "criticality": "ignore", "value": { "protocolIEs": [
{ "id": 73, "criticality": "reject", "value": 12001 },
{ "id": 79, "criticality": "reject", "value": 54002 },
{ "id": 161, "criticality": "reject", "value": { "nr": {
"plmn-id": "00f110", "nr-CI": "1234567890" } } }
] } } }
Step 3. Target orders explicit source release
Once the target path is working and final status has been transferred, the target sends the UE an RRCReconfiguration with daps-SourceRelease-r16. This releases the retained source cell and ends the overlap. Its transaction identifier is new; the UE confirms this release reconfiguration separately.
NR RRC source-release command and completion, selected-field JER.
{ "rrc-TransactionIdentifier": 2, "criticalExtensions": { "rrcReconfiguration": {
"nonCriticalExtension": { "nonCriticalExtension": { "nonCriticalExtension": {
"nonCriticalExtension": { "daps-SourceRelease-r16": "true" } } } } } } }
{ "rrc-TransactionIdentifier": 2,
"criticalExtensions": { "rrcReconfigurationComplete": {} } }
Keep the source user plane during access
The source requests DAPS for selected DRBs during target preparation, and the target indicates whether it accepts. On receipt of the handover command, the UE creates target-side MAC and RLC state for those DRBs while retaining source-side user-plane operation. For DAPS DRBs, PDCP handles the two lower-layer paths with separate security and ROHC functions.
The UE can continue downlink reception from the source until source release and uplink transmission to the source until successful target random access (TS 38.300 clause 9.2.3.1). Source and target PCells are the two active cells for DAPS. The source may send EARLY STATUS TRANSFER before the normal SN STATUS TRANSFER; the timing differs from ordinary handover because source PDCP SN assignment can continue during the overlap.
Release the source only after target success
The target sends XnAP HANDOVER SUCCESS after the UE reaches it. The source then sends the required status and stops source-side delivery as the bearer procedure requires. The target explicitly tells the UE to release the source cell. DAPS is complete only after that release, not merely after target RRCReconfigurationComplete.
If target access fails while the source link is still available, the UE can fall back to its source configuration instead of immediately starting RRC re-establishment. This is one reason the source is retained. DAPS and CHO are not configured together, and TS 38.300 v19.4.0 does not support FR2-to-FR2 DAPS handover.
Overlap is per configured DRB : do not assume every bearer uses DAPS.Target access is not final release : an explicit source-cell release ends the overlap.Failure can return to source : only while the retained source link remains usable.
How L1/L2 triggered mobility differs ?
NR also supports L1/L2 Triggered Mobility (LTM). Unlike an ordinary L3 handover, the network prepares candidate cell configurations with RRC and later triggers a cell switch using a MAC control element. This can reduce the control-plane delay at the instant of the switch. It is still cell-level mobility, not merely a beam change.
Figure 6 separates candidate preparation from the short execution command. The same prepared candidates can support subsequent switches, subject to the configured rules and updates.
Figure 6. RRC prepares LTM candidates; a later MAC CE selects the target at execution time.
The example uses LTM candidate ID 2 and PCI 144. RRC candidate configuration is ASN.1 and therefore has JER; the LTM cell switch command is a MAC control element with its own binary fields, so presenting it as ASN.1 JER would be incorrect. The UE's completion is again an RRC message.
Step 1. RRC installs candidate 2
The gNB sends RRCReconfiguration with ltm-Config-r18. Its candidate entry binds ID 2 to PCI 144 and an encoded candidate RRCReconfiguration. The UE stores the candidate, then acknowledges the configuration while still served by the source cell.
NR RRCReconfiguration, selected-field JER; synthetic values.
{ "rrc-TransactionIdentifier": 1, "criticalExtensions": { "rrcReconfiguration": {
"nonCriticalExtension": { "nonCriticalExtension": { "nonCriticalExtension": {
"nonCriticalExtension": { "nonCriticalExtension": { "nonCriticalExtension": {
"ltm-Config-r18": { "setup": { "ltm-CandidateToAddModList-r18": [ {
"ltm-CandidateId-r18": 2, "ltm-CandidatePCI-r18": 144,
"ltm-CandidateConfig-r18": "0140a8804a21c801" } ] } } } } } } } } } } }
{ "rrc-TransactionIdentifier": 1,
"criticalExtensions": { "rrcReconfigurationComplete": {} } }
Step 2. Optional early synchronization
Before a switch, the UE may synchronize with candidate downlink beams and obtain target uplink timing advance. Those actions use physical-layer measurements and MAC procedures. If early UL synchronization is configured, its RRC candidate field remains an encoded OCTET STRING at this level of JER.
LTM candidate early-UL field, selected JER excerpt.
{ "ltm-CandidateId-r18": 2, "ltm-CandidatePCI-r18": 144,
"ltm-EarlyUL-SyncConfig-r18": "20018a44" }
Step 3. MAC CE selects candidate 2
The gNB sends an LTM cell switch command MAC CE selecting the prepared candidate and beam state. This is not ASN.1 and has no JER encoding. The readable field example below is deliberately not labelled JER. An actual trace contains binary MAC CE fields, not the table text.
| MAC CE field | Example | Meaning |
|---|---|---|
| Target configuration ID | 2 | Select stored LTM candidate 2 |
| Target beam indication | TCI state 7 | Use the prepared target beam state |
| Target TA | Valid | RACH-less switch may be possible |
Step 4. UE completes the switch
The UE applies candidate 2, performs RACH only if the selected branch requires it, and sends RRCReconfigurationComplete in the target cell. The transaction identifier matches the stored candidate RRC command, not the preceding MAC CE, which has no RRC transaction identifier.
Target-cell NR RRCReconfigurationComplete JER.
{ "rrc-TransactionIdentifier": 3,
"criticalExtensions": { "rrcReconfigurationComplete": {} } }
Candidate preparation and early synchronization
The network supplies candidate cell configurations before execution. It can activate target-cell TCI states early so the UE can synchronize to candidate downlink beams. It can also arrange early uplink timing-advance acquisition. These preparations make the later cell switch shorter, but the candidates are not yet serving cells.
TS 38.300 v19.4.0 supports intra- and inter-gNB LTM, including intra-frequency and inter-frequency licensed-spectrum cases. An inter-gNB case still needs context coordination between nodes; the over-the-air trigger being MAC does not eliminate network preparation. Conditional LTM (CLTM) lets the UE execute when configured conditions are met, but its supported scope is narrower: intra-gNB without dual connectivity in this release.
MAC-triggered cell switch
The gNB sends an LTM cell switch command MAC CE with a target configuration ID and beam indication. It may include target timing advance. The UE applies the stored target configuration and switches cells. With a valid target TA, RACH-less LTM can use a configured or dynamic uplink grant; without one, the UE performs RACH-based LTM. The UE sends RRCReconfigurationComplete to the target cell.
The MAC CE is the execution trigger, not the earlier RRC candidate message. After a switch, the UE resets MAC. RLC and PDCP handling depend on the network configuration. A reader should therefore not apply the ordinary RRC-handover bearer-reset rules to every LTM switch. The same candidate set may be reused for later switches rather than being rebuilt after each execution.
RRC prepares : candidate configurations exist before the switch.MAC triggers : the cell switch command selects the target configuration.RACH may be skipped : a valid TA enables the RACH-less branch.
What about NSA and inter-system mobility ?
The word 5G can mean an NR radio leg added to LTE, or an NR SA connection anchored in the 5GC. Those deployments do not use the same mobility messages. A change of NR secondary cell in NSA is not automatically an NR SA handover, and a move between 5GS and EPS changes more than a radio cell.
NSA secondary-node changes
In EN-DC, the LTE eNB is the master node connected to the EPC; the NR en-gNB is a secondary node connected to the master over X2. The UE can change its NR PSCell or SgNB while the LTE master cell remains unchanged. That procedure uses X2AP SgNB modification or change and NR RRC configuration, not an NGAP PATH SWITCH REQUEST to an AMF.
With NGEN-DC, an ng-eNB is the master on the 5GC side and a gNB is the secondary node. Their coordination uses Xn. In NR-DC, a gNB master and gNB secondary node also use Xn. The same-looking NR radio change can therefore involve X2 or Xn depending on the architecture. TS 37.340 defines the MR-DC node roles and secondary-node procedures; the Xn page shows the EN-DC and NGEN-DC messages side by side.
Handover between 5GS and EPS
Inter-system handover between NR/5GS and LTE/EPS can change the core network, security context and bearer representation in addition to the radio access node. The source cannot treat an LTE eNB as an ordinary target gNB on Xn. The core-network procedures coordinate the transfer and any supported data forwarding; the exact sequence depends on the direction and whether interworking between AMF and MME is available.
Keep three cases separate in a log: NR SA gNB-to-gNB mobility within 5GS, EN-DC secondary NR movement while LTE remains the master, and 5GS-to-EPS or EPS-to-5GS inter-system handover. Their handover commands, bearer identifiers and core-side messages differ. For example, PDU session ID and QFI belong to 5GS, while E-RAB and EPS bearer identities belong to EPS.
Architecture selects the interface : EN-DC uses X2; 5GC-based MR-DC uses Xn.Secondary-cell movement is not always master handover : check which node retains the core control-plane anchor.Inter-system adds core translation : do not read it as only a PCell change.
What happens when handover fails ?
A failed handover has at least two very different meanings. The target may reject the request before the UE receives a command, or the UE may fail to reach a target that was already prepared. The recovery action depends on which phase failed and whether the source radio link still works.
Failure before the UE moves
For Xn preparation, the target can answer HANDOVER PREPARATION FAILURE with a cause, such as resource or configuration problems. The source's preparation timer also protects against a missing outcome. For N2 preparation, target allocation can fail and the AMF returns a failure toward the source. In both cases the UE may remain on the source, because no usable target command was delivered.
Check whether rejection concerns the entire handover or only selected PDU sessions. A target can admit some resources and reject others based on its slice and QoS support. If the source later chooses a different target or route, that is a new decision, not the successful completion of the rejected request.
Failure during target access
After the RRC handover command, the UE starts the target synchronization and access procedure. T304 bounds this execution. A timeout or radio-link problem may lead to RRC connection re-establishment, which is a recovery procedure rather than the planned handover completing. The UE can select a cell for recovery that differs from both the original source and prepared target.
Special modes have exceptions. In DAPS, the UE can resume the retained source link when target access fails and source radio is still usable. In configured CHO recovery, the UE may try a stored candidate once under the specified conditions. LTM can similarly try an eligible candidate with RACH-based recovery if configured; otherwise re-establishment follows. These branches are why a failure trace must include the UE's configuration, not only the final cell identity.
For diagnosis, mark the last successful checkpoint: target acknowledgement, RRC command delivery, random access, RRCReconfigurationComplete, core path update or old-context release. A missing message after that point narrows the problem. A preparation failure should not be reported as a radio-access failure, and a target-access failure should not be blamed on an Xn request that succeeded.
Before command : inspect admission, cause and preparation timer.After command : inspect T304, target synchronization, PRACH and RRC completion.After arrival : inspect path switch or handover notify and old-context release.
How to read a handover trace ?
One UE can have several identifiers at the same time, and each interface may rename the transaction. Start from the radio command and correlate outward rather than searching for a single universal UE ID. The example below is synthetic; its values only show how to align messages across Uu, Xn and NG.
Correlate the UE across interfaces
On NR Uu, the source and target can use different C-RNTIs, and the RRC transaction identifier helps pair reconfiguration with completion. On Xn, source and target NG-RAN node UE XnAP IDs form a pair for the peer transaction. On NG, AMF-UE-NGAP-ID and RAN-UE-NGAP-ID identify the core-facing UE context. The target can allocate a new RAN-UE-NGAP-ID when it takes over.
Use PDU Session ID, DRB ID and QFI to follow the affected user plane. They answer different questions: which core session, which radio bearer and which QoS flow. A forwarding GTP-U TEID is another identifier, not a replacement for any of those. It identifies a tunnel endpoint for packets on a particular path.
Message checkpoints
Suppose a UE with source XnAP ID 420 and target XnAP ID 891 is handed over. A reader can walk the following checkpoints in order. The values are illustrative, not a capture and not fixed 3GPP assignments.
Time | Interface and message | What it proves |
|---|---|---|
10:00:00.000 | Uu MeasurementReport; neighbour PCI 321 | The source received a measurement, not yet a handover decision. |
10:00:00.018 | Xn-C HANDOVER REQUEST; source XnAP ID 420, target CGI | Inter-gNB Xn preparation began. |
10:00:00.031 | Xn-C HANDOVER REQUEST ACKNOWLEDGE; target XnAP ID 891 | The target admitted resources and supplied its radio container. |
10:00:00.038 | Uu RRCReconfiguration; target PCI 321, new C-RNTI | The UE received the execution command. |
10:00:00.052 | Uu RRCReconfigurationComplete at target | Target radio access succeeded. |
10:00:00.064 | NG-C PATH SWITCH REQUEST / ACKNOWLEDGE | The 5GC redirected the downlink path. |
10:00:00.070 | Xn-C UE CONTEXT RELEASE; IDs 420 / 891 | The source can free its old UE context. |
If the corresponding core message were HANDOVER REQUIRED before the radio command and HANDOVER NOTIFY after arrival, this would instead suggest N2 preparation. If F1AP changes appeared without XnAP or NGAP handover preparation, the move might remain inside one gNB. Always confirm the topology before choosing the interpretation.
Correlate IDs, not names alone : HANDOVER REQUEST exists on both XnAP and NGAP.Mark the preparation outcome : it is distinct from UE arrival.Mark the core outcome : radio success can precede path completion.
Key ASN.1 structures
The procedure names tell us which messages to find, but the IEs explain what each side actually knows. The listings below use the latest published Release 19 text checked for this note: TS 38.331, 38.423 and 38.413 v19.4.0. They are specification definitions, not decoded packets. Optional fields absent in one capture are not necessarily a protocol error.
NR RRC target synchronization
The ReconfigurationWithSync type sits inside the target cell-group configuration carried by RRCReconfiguration. Its mandatory newUE-Identity and t304 fields are especially useful in a handover trace. Dedicated RACH configuration and later-release options are conditional or optional, so a real command need not show all of them.
Following is based on
ReconfigurationWithSync ::= SEQUENCE {
spCellConfigCommon ServingCellConfigCommon OPTIONAL, -- Need M
newUE-Identity RNTI-Value,
t304 ENUMERATED {ms50, ms100, ms150, ms200, ms500, ms1000, ms2000, ms10000},
rach-ConfigDedicated CHOICE {
uplink RACH-ConfigDedicated,
supplementaryUplink RACH-ConfigDedicated
} OPTIONAL, -- Need N
...,
[[
smtc SSB-MTC OPTIONAL -- Need S
]],
[[
daps-UplinkPowerConfig-r16 DAPS-UplinkPowerConfig-r16 OPTIONAL -- Need N
]],
[[
sl-PathSwitchConfig-r17 SL-PathSwitchConfig-r17 OPTIONAL -- Cond DirectToIndirect-PathSwitch
]],
[[
rach-LessHO-r18 RACH-LessHO-r18 OPTIONAL, -- Need N
sl-IndirectPathMaintain-r18 ENUMERATED {true} OPTIONAL -- Cond MP
]],
[[
ltm-SchedulingRequestInfo-r19 LTM-SchedulingRequestInfo-r19 OPTIONAL, -- Cond LTM
earlyCSI-Acquisition-r19 EarlyCSI-Acquisition-r19 OPTIONAL -- Need N
]]
}
The extension groups show why an old decoder can miss a new option even when it decodes the basic handover. For example, rach-LessHO-r18 concerns RACH-less operation, while the Release 19 fields add LTM scheduling-request and early CSI support. Neither field means that every handover uses that variant.
XnAP preparation and release
The XnAP response exposes the target-side UE identifier, admitted PDU sessions and the transparent container sent onward to the UE. Later, status transfer addresses DRBs rather than PDU sessions, and UE CONTEXT RELEASE uses the source/target XnAP ID pair. That difference helps separate preparation, continuity and cleanup in a capture.
Following is based on
HandoverRequestAcknowledge ::= SEQUENCE {
protocolIEs ProtocolIE-Container {{HandoverRequestAcknowledge-IEs}},
...
}
HandoverRequestAcknowledge-IEs XNAP-PROTOCOL-IES ::= {
{ ID id-sourceNG-RANnodeUEXnAPID CRITICALITY ignore TYPE NG-RANnodeUEXnAPID PRESENCE mandatory }|
{ ID id-targetNG-RANnodeUEXnAPID CRITICALITY ignore TYPE NG-RANnodeUEXnAPID PRESENCE mandatory }|
{ ID id-PDUSessionResourcesAdmitted-List CRITICALITY ignore TYPE PDUSessionResourcesAdmitted-List PRESENCE mandatory }|
{ ID id-PDUSessionResourcesNotAdmitted-List CRITICALITY ignore TYPE PDUSessionResourcesNotAdmitted-List PRESENCE optional }|
{ ID id-Target2SourceNG-RANnodeTranspContainer CRITICALITY ignore TYPE OCTET STRING PRESENCE mandatory }|
{ ID id-UEContextKeptIndicator CRITICALITY ignore TYPE UEContextKeptIndicator PRESENCE optional }|
{ ID id-CriticalityDiagnostics CRITICALITY ignore TYPE CriticalityDiagnostics PRESENCE optional }|
{ ID id-DRBs-transferred-to-MN CRITICALITY ignore TYPE DRB-List PRESENCE optional }|
{ ID id-DAPSResponseInfo-List CRITICALITY reject TYPE DAPSResponseInfo-List PRESENCE optional }|
{ ID id-CHOinformation-Ack CRITICALITY reject TYPE CHOinformation-Ack PRESENCE optional }|
{ ID id-MBS-SessionInformationResponse-List CRITICALITY ignore TYPE MBS-SessionInformationResponse-List PRESENCE optional }|
{ ID id-RRCConfigIndication CRITICALITY ignore TYPE RRCConfigIndication PRESENCE optional }|
{ ID id-PDUSetbasedHandlingIndicator CRITICALITY ignore TYPE PDUSetbasedHandlingIndicator PRESENCE optional }|
{ ID id-LTMHandoverInformationRequestAcknowledge CRITICALITY ignore TYPE LTMHandoverInformationRequestAcknowledge PRESENCE optional }|
{ ID id-EarlySyncInformationResponse CRITICALITY ignore TYPE EarlySyncInformation PRESENCE optional }|
{ ID id-LTMKeptCandidateCellList CRITICALITY ignore TYPE LTMKeptCandidateCell-List PRESENCE optional },
...
}
Following is based on
SNStatusTransfer ::= SEQUENCE {
protocolIEs ProtocolIE-Container {{SNStatusTransfer-IEs}},
...
}
SNStatusTransfer-IEs XNAP-PROTOCOL-IES ::= {
{ ID id-sourceNG-RANnodeUEXnAPID CRITICALITY reject TYPE NG-RANnodeUEXnAPID PRESENCE mandatory }|
{ ID id-targetNG-RANnodeUEXnAPID CRITICALITY reject TYPE NG-RANnodeUEXnAPID PRESENCE mandatory }|
{ ID id-DRBsSubjectToStatusTransfer-List CRITICALITY ignore TYPE DRBsSubjectToStatusTransfer-List PRESENCE mandatory }|
{ ID id-CHOConfiguration CRITICALITY ignore TYPE CHOConfiguration PRESENCE optional }|
{ ID id-MobilityInformation CRITICALITY ignore TYPE MobilityInformation PRESENCE optional },
...
}
UEContextRelease ::= SEQUENCE {
protocolIEs ProtocolIE-Container {{UEContextRelease-IEs}},
...
}
UEContextRelease-IEs XNAP-PROTOCOL-IES ::= {
{ ID id-sourceNG-RANnodeUEXnAPID CRITICALITY reject TYPE NG-RANnodeUEXnAPID PRESENCE mandatory }|
{ ID id-targetNG-RANnodeUEXnAPID CRITICALITY reject TYPE NG-RANnodeUEXnAPID PRESENCE mandatory },
...
}
The optional CHO, DAPS and LTM entries are important because they show that later mobility variants extend the same XnAP procedure family. The mandatory IDs still correlate the peer UE context. For fully decoded synthetic XnAP and RRC message examples, see the Xn handover examples.
NGAP core-assisted preparation
NGAP HANDOVER REQUIRED is the source-to-AMF trigger for N2 handover. The AMF and RAN UE NGAP IDs identify the core-facing context, while TargetID and the source-to-target container identify where and how the UE should be prepared. The optional direct-forwarding indication does not make XnAP preparation mandatory.
Following is based on
HandoverRequired ::= SEQUENCE {
protocolIEs ProtocolIE-Container {{HandoverRequiredIEs}},
...
}
HandoverRequiredIEs NGAP-PROTOCOL-IES ::= {
{ ID id-AMF-UE-NGAP-ID CRITICALITY reject TYPE AMF-UE-NGAP-ID PRESENCE mandatory }|
{ ID id-RAN-UE-NGAP-ID CRITICALITY reject TYPE RAN-UE-NGAP-ID PRESENCE mandatory }|
{ ID id-HandoverType CRITICALITY reject TYPE HandoverType PRESENCE mandatory }|
{ ID id-Cause CRITICALITY ignore TYPE Cause PRESENCE mandatory }|
{ ID id-TargetID CRITICALITY reject TYPE TargetID PRESENCE mandatory }|
{ ID id-DirectForwardingPathAvailability CRITICALITY ignore TYPE DirectForwardingPathAvailability PRESENCE optional }|
{ ID id-PDUSessionResourceListHORqd CRITICALITY reject TYPE PDUSessionResourceListHORqd PRESENCE mandatory }|
{ ID id-SourceToTarget-TransparentContainer CRITICALITY reject TYPE SourceToTarget-TransparentContainer PRESENCE mandatory },
...
}
Do not identify this NGAP message only by the word HANDOVER. Its sender is the source gNB and its receiver is the AMF. The AMF then sends NGAP HANDOVER REQUEST to the target. For the Xn path, the source instead sends XnAP HANDOVER REQUEST directly to the target, and the target later sends NGAP PATH SWITCH REQUEST after UE arrival.
RRC carries the target radio configuration :newUE-Identityandt304are key fields.XnAP carries peer context : source/target IDs, admission result and status transfer are separate.NGAP carries core-assisted preparation : HANDOVER REQUIRED begins the N2 route.
Reference
- TS 38.300 v19.4.0 - NR and NG-RAN overall description; Stage 2
- TS 38.331 v19.4.0 - NR Radio Resource Control (RRC)
- TS 38.423 v19.4.0 - NG-RAN Xn Application Protocol (XnAP)
- TS 38.413 v19.4.0 - NG Application Protocol (NGAP)
- TS 38.473 v19.4.0 - F1 Application Protocol (F1AP)
- TS 37.340 v19.3.0 - Multi-connectivity; Overall description; Stage 2