Handover Request Acknowledge is the XnAP message the target NG-RAN node sends to the source NG-RAN node to report the prepared resources at the target and confirm that the handover branch is ready to continue.
The target NG-RAN node has finished evaluating Handover Request, has prepared incoming UE resources, and must inform the source NG-RAN node whether the handover branch is now in prepared state.
Main purpose
Confirms that the target NG-RAN node prepared the incoming UE context, reports admitted and not-admitted PDU session resources, and returns the target-to-source transparent container and any conditional-handover acknowledge data needed for the next branch.
What is Handover Request Acknowledge in simple terms?
Handover Request Acknowledge is the XnAP message the target NG-RAN node sends to the source NG-RAN node to report the prepared resources at the target and confirm that the handover branch is ready to continue.
Confirms that the target NG-RAN node prepared the incoming UE context, reports admitted and not-admitted PDU session resources, and returns the target-to-source transparent container and any conditional-handover acknowledge data needed for the next branch.
Why this message matters
Handover Request Acknowledge is the target gNB telling the source gNB over Xn that target preparation succeeded and which resources are actually ready.
Where this message appears in the call flow
Prepared handover confirmation
Prepared-handover branch: the target confirms resources are ready, the source stops TXnRELOCprep, and immediate handover branches move into prepared state.
Call flow position: After receiving Handover Request, the target NG-RAN node sends Handover Request Acknowledge to confirm that resources are prepared at the target.
Typical state: The UE is still on the source side, but the source now has a prepared handover on this Xn UE-associated signaling branch.
Preconditions:
Handover Request was accepted and processed by the target NG-RAN node.
The target built the incoming UE context and any associated target-side bearer state it could admit.
The source can still correlate the procedure using the source-side UE XnAP ID.
Next likely message: Source-side handover command or later Xn mobility follow-on signaling
Mixed PDU session admission result
Mixed-result branch: the target returns admitted and not-admitted PDU session resources in the same successful outcome.
Call flow position: The target reports which requested PDU session resources were admitted and which were not admitted during preparation.
Typical state: The overall handover branch can still continue if at least one required resource branch is accepted, but per-session results matter.
Preconditions:
The request contained PDU Session Resources To Be Setup List and the target evaluated those resources.
The target can distinguish successful setup results from not-admitted ones.
Next likely message: Source-side execution using admitted resources plus possible later cleanup for non-admitted ones
Conditional handover acknowledge
CHO branch: when the request was conditional handover, the success path includes Conditional Handover Information Acknowledge and remains a CHO preparation result.
Call flow position: When the original request contained Conditional Handover Information Request, the target must include Conditional Handover Information Acknowledge in the successful outcome.
Typical state: The branch remains a conditional-handover preparation path rather than a plain immediate handover path.
Preconditions:
The Handover Request concerned conditional handover.
The target is returning a successful outcome for that CHO preparation branch.
Next likely message: Source-side storage and later use of the prepared CHO branch
Transport / encapsulation: XnAP over SCTP/IP between target and source NG-RAN nodes
Security context: The acknowledge reports the result of target-side preparation. It does not execute the handover itself, but it confirms the target has prepared the UE context and associated bearer state needed for later execution.
Message Structure Overview
Handover Request Acknowledge is the target-to-source successfulOutcome for Xn Handover Preparation.
When the source receives it, the source stops TXnRELOCprep and terminates the Handover Preparation procedure.
If the branch is an immediate handover, the source then starts TXnRELOCoverall and is defined to have a Prepared Handover for that Xn UE-associated signaling.
The main success payload is the combination of the target-assigned UE XnAP ID, admitted and not-admitted PDU session result lists, and the target-to-source transparent container.
If the original request concerned conditional handover, the successful outcome must also carry Conditional Handover Information Acknowledge.
The stable core is simple: source UE ID, target UE ID, admitted resource list, optional not-admitted list, and the target-to-source transparent container. The most important conditional branch is CHO, where Conditional Handover Information Acknowledge becomes part of the success path.
5G XnAP - Handover Request Acknowledge - Example Dump
Read the acknowledge in this order: source UE ID, target UE ID, admitted resources, not-admitted resources, then the transparent container.
On reception of the acknowledge, the source stops TXnRELOCprep. For immediate handover it then starts TXnRELOCoverall and now has a Prepared Handover.
If Conditional Handover Information Acknowledge is present, keep the branch labeled as CHO preparation rather than normal immediate execution.
Important Information Elements
IE
Required
Description
Source NG-RAN node UE XnAP ID
Yes
Mandatory source-side UE identifier used to correlate the acknowledge with the earlier Handover Request.
Target NG-RAN node UE XnAP ID
Yes
Mandatory target-assigned UE XnAP identifier representing the prepared UE context at the target NG-RAN node.
PDU Session Resources Admitted List
Yes
Mandatory list reporting the requested PDU session resources that the target prepared successfully.
PDU Session Resources Not Admitted List
Optional
Optional list of requested PDU session resources that the target could not admit during preparation.
Target NG-RAN node To Source NG-RAN node Transparent Container
Yes
Mandatory transparent container carrying the target-derived execution context the source will need for the later handover command branch.
Criticality Diagnostics
Optional
Optional protocol diagnostics returned with the successful outcome.
Conditional Handover Information Acknowledge
Optional
Mandatory in the successful outcome when the original request concerned a conditional handover branch.
Direct Forwarding Path Availability
Optional
Optional indication that helps the source understand whether direct forwarding is available between source and target.
RRC Config Indication
Optional
Optional RRC-configuration mode indication relevant to prepared handover interpretation.
Detailed field explanation
Source NG-RAN node UE XnAP ID
Mandatory source-side UE identifier used to correlate the acknowledge with the earlier Handover Request.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Target NG-RAN node UE XnAP ID
Mandatory target-assigned UE XnAP identifier representing the prepared UE context at the target NG-RAN node.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
PDU Session Resources Admitted List
Mandatory list reporting the requested PDU session resources that the target prepared successfully.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
PDU Session Resources Not Admitted List
Optional list of requested PDU session resources that the target could not admit during preparation.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Target NG-RAN node To Source NG-RAN node Transparent Container
Mandatory transparent container carrying the target-derived execution context the source will need for the later handover command branch.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Criticality Diagnostics
Optional protocol diagnostics returned with the successful outcome.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Conditional Handover Information Acknowledge
Mandatory in the successful outcome when the original request concerned a conditional handover branch.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Direct Forwarding Path Availability
Optional indication that helps the source understand whether direct forwarding is available between source and target.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
RRC Config Indication
Optional RRC-configuration mode indication relevant to prepared handover interpretation.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
What to check in logs and traces
Match the acknowledge to the earlier Handover Request using Source NG-RAN node UE XnAP ID first.
Capture the Target NG-RAN node UE XnAP ID because later Xn mobility procedures depend on the prepared target context.
Enumerate PDU Session Resources Admitted List and PDU Session Resources Not Admitted List together before deciding whether preparation was fully clean or mixed.
Preserve the target-to-source transparent container because it bridges target preparation into the later command path.
If the branch is CHO, confirm Conditional Handover Information Acknowledge is present and read it before collapsing the trace into a normal immediate handover story.
Common Issues and Troubleshooting
The target looked ready, but some PDU sessions disappear after the move.
Likely cause: The acknowledge may have reported a mixed result with admitted and not-admitted PDU session resources.
What to inspect: Compare PDU Session Resources Admitted List and PDU Session Resources Not Admitted List item by item instead of treating the acknowledge as blanket success.
Next step: Debug the missing sessions from the not-admitted list and any later cleanup instead of blaming only the execution stage.
The source times out even though the target says preparation succeeded.
Likely cause: The acknowledge may have arrived too late, after TXnRELOCprep expiry handling already started at the source.
What to inspect: Sequence Handover Request send time, TXnRELOCprep expiry, Handover Request Acknowledge reception, and any later Handover Cancel.
Next step: Separate explicit target success from late-arriving success that was already operationally unusable.
Conditional handover traces are hard to interpret after a successful preparation.
Likely cause: The successful outcome may be a CHO-specific acknowledge rather than an immediate-handover result.
What to inspect: Read Conditional Handover Information Acknowledge and correlate it with the target cell and earlier CHO request context.
Next step: Keep the branch modeled as CHO preparation until later execution really selects or replaces a candidate.
LTE / 5G / Variant Comparison
Compared with Handover Request
Handover Request asks the target to prepare incoming UE resources. Handover Request Acknowledge reports what the target actually prepared and returns the target-derived execution container.
Compared with Handover Preparation Failure
Handover Request Acknowledge creates a prepared handover state at the source. Handover Preparation Failure stops the branch before that state exists.
Compared with NGAP Handover Request Acknowledge
NGAP Handover Request Acknowledge is target NG-RAN to AMF over N2. XnAP Handover Request Acknowledge is target NG-RAN to source NG-RAN directly over Xn.
FAQ
What is Handover Request Acknowledge in 5G XnAP?
It is the target NG-RAN node to source NG-RAN node message that reports the prepared resources at the target and confirms the handover branch is ready to continue.
What happens to TXnRELOCprep when the source receives this message?
The source stops TXnRELOCprep on reception of Handover Request Acknowledge. If the branch is an immediate handover, the source then starts TXnRELOCoverall.
Can the message include both admitted and not-admitted PDU session resources?
Yes. The successful outcome can contain a mandatory admitted list plus an optional not-admitted list.
How is conditional handover reflected in the acknowledge?
If the original Handover Request concerned conditional handover, the successful outcome includes Conditional Handover Information Acknowledge.
Decode this message with the 3GPP Decoder, inspect the related message database, or open the matching call flow to see where this signaling step fits in the full procedure.
