Handover Request Acknowledge is the NGAP message the target NG-RAN sends to the AMF to report the prepared target resources, admitted PDU sessions, failed session items, and the transparent container needed for the later handover command path.
UE-associated NGAP signaling context being prepared on the target side / SCTP carried NGAP successfulOutcome
Typical trigger
The target NG-RAN has finished evaluating Handover Request, has allocated a target UE context, and must report back which handover resources are ready and which per-session items failed.
Main purpose
Confirms which target-side handover resources are prepared, which PDU session items were admitted or rejected, and provides the Target to Source Transparent Container that the AMF can later relay toward the source side.
What is Handover Request Acknowledge in simple terms?
Handover Request Acknowledge is the NGAP message the target NG-RAN sends to the AMF to report the prepared target resources, admitted PDU sessions, failed session items, and the transparent container needed for the later handover command path.
Confirms which target-side handover resources are prepared, which PDU session items were admitted or rejected, and provides the Target to Source Transparent Container that the AMF can later relay toward the source side.
Why this message matters
Handover Request Acknowledge is the target gNB telling the AMF that the target is ready, which sessions were admitted, which sessions failed, and what target-side container must be sent back toward the source side.
Where this message appears in the call flow
Target-ready confirmation in N2 handover
Target-ready branch: the target confirms the incoming UE context is prepared and returns the target-assigned context identifiers and container.
Call flow position: After receiving Handover Request, the target NG-RAN sends Handover Request Acknowledge to confirm that the incoming UE context and admitted resources are prepared.
Typical state: The UE is still on the source side, but the target has created enough context for AMF to continue toward Handover Command.
Preconditions:
Handover Request was accepted and processed by the target NG-RAN.
The target allocated a new RAN UE NGAP ID for the incoming UE context.
At least one admitted PDU session item is available in the normal successful branch.
Next likely message: Handover Command from AMF toward the source NG-RAN
Mixed session admission during handover preparation
Mixed-result branch: some PDU sessions are admitted while others fail during target preparation.
Call flow position: The target can admit some session items while rejecting others, and the acknowledge reports both results together.
Typical state: The overall handover branch may still continue even though some PDU sessions need release or follow-on cleanup.
Preconditions:
The target evaluated each requested PDU session item independently.
The procedure needs to distinguish admitted sessions from failed ones before the UE is moved.
Next likely message: Handover Command plus follow-on handling for any sessions that could not be admitted
Special target capability reporting
Capability branch: the target can return extra access or capability indicators while confirming preparation.
Call flow position: The target includes additional capability or access context such as NPN access or RedCap indications while confirming preparation.
Typical state: The handover branch is ready enough to continue, but the target returns extra context that can affect how the source/core interpret the prepared UE.
Preconditions:
The target has relevant NPN or reduced-capability context to expose.
Core-side continuation logic needs the extra indicators as part of the prepared result.
Next likely message: Handover Command carrying the target-derived transparent container and admitted session outcome
Call flow position
Previous message(s):Handover Request, Target-side admission and reservation, AMF-mediated handover preparation
Next message(s): Handover Command, Handover Preparation Failure, Source-side execution branch
Message direction and transport
Sender and receiver: Target NG-RAN -> AMF
Interface: N2 / NG-C
Domain: Target-access to core reporting of handover preparation outcome
Signaling bearer: UE-associated NGAP signaling context being prepared on the target side
Transport / encapsulation: NGAP over SCTP/IP between target NG-RAN and AMF
Security context: The acknowledge reports the result of target-side preparation on the incoming UE context. It does not move the UE itself; it confirms that the target has prepared resources and related per-session transport context for the later execution branch.
Message Structure Overview
Handover Request Acknowledge is the target NG-RAN to AMF result message for the handover resource allocation phase.
The target-assigned RAN UE NGAP ID is operationally important because it proves the target created an incoming UE context before execution.
The admitted list is the main success payload, and each admitted item carries Handover Request Acknowledge Transfer from section 9.3.4.11.
The failed list is optional but critical when the target admits the handover branch only partially.
Target to Source Transparent Container is mandatory because the source side still needs target-derived execution information before the UE can be told to move.
Decode this message in three layers: first the target-confirmation context with AMF UE NGAP ID and target RAN UE NGAP ID, then the admitted and failed session lists, then the Target to Source Transparent Container that feeds the later command path. Handover Request Acknowledge Transfer in section 9.3.4.11 carries the target-side NG-U and forwarding details for admitted sessions, while section 9.3.4.19 carries cause-only failure context for rejected items.
5G NGAP - Handover Request Acknowledge - Example Dump
The target-side RAN UE NGAP ID is newly allocated at the target and should be preserved for later correlation with execution and path switch activity.
Each admitted session item points to section 9.3.4.11, where the target provides DL NG-U UP TNL Information, QoS Flow Setup Response List, and optional forwarding-related information.
Each failed session item points to section 9.3.4.19, which is intentionally small and carries the failure cause plus optional criticality diagnostics.
Important Information Elements
IE
Required
Description
AMF UE NGAP ID
Yes
Mandatory AMF-side UE identifier used to correlate the acknowledge with the ongoing handover preparation branch.
RAN UE NGAP ID
Yes
Mandatory target-assigned NG-RAN UE identifier that represents the new UE context prepared at the target side.
PDU Session Resource Admitted List
Yes
Mandatory admitted-session list in the normal successful branch. Each item contains PDU Session ID and Handover Request Acknowledge Transfer from section 9.3.4.11.
PDU Session Resource Failed to Setup List
Optional
Optional list of PDU session items that the target could not admit. Each failed item contains Handover Resource Allocation Unsuccessful Transfer from section 9.3.4.19.
Target to Source Transparent Container
Yes
Mandatory transparent container the AMF can later include toward the source side when building the command path back to the UE-serving node.
Criticality Diagnostics
Optional
Optional protocol diagnostics that can help explain unusual handling or decode conditions around the acknowledge.
NPN Access Information
Optional
Optional non-public-network access context that the target can report as part of the prepared result.
RedCap Indication
Optional
Optional indication that the prepared UE context is associated with RedCap handling on the target side.
eRedCap Indication
Optional
Optional enhanced RedCap indication returned by the target when applicable.
Detailed field explanation
AMF UE NGAP ID
Mandatory AMF-side UE identifier used to correlate the acknowledge with the ongoing handover preparation 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.
RAN UE NGAP ID
Mandatory target-assigned NG-RAN UE identifier that represents the new UE context prepared at the target side.
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 Resource Admitted List
Mandatory admitted-session list in the normal successful branch. Each item contains PDU Session ID and Handover Request Acknowledge Transfer from section 9.3.4.11.
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 Resource Failed to Setup List
Optional list of PDU session items that the target could not admit. Each failed item contains Handover Resource Allocation Unsuccessful Transfer from section 9.3.4.19.
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 to Source Transparent Container
Mandatory transparent container the AMF can later include toward the source side when building the command path back to the UE-serving 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.
Criticality Diagnostics
Optional protocol diagnostics that can help explain unusual handling or decode conditions around the acknowledge.
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.
NPN Access Information
Optional non-public-network access context that the target can report as part of the prepared result.
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.
RedCap Indication
Optional indication that the prepared UE context is associated with RedCap handling on the target side.
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.
eRedCap Indication
Optional enhanced RedCap indication returned by the target when applicable.
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
Confirm the acknowledge belongs to the expected Handover Request and target node.
Capture the target-assigned RAN UE NGAP ID because it anchors the prepared target context for later trace steps.
Enumerate the admitted-session list and failed-session list together before deciding whether preparation was fully successful or mixed.
Inspect Handover Request Acknowledge Transfer for admitted sessions when forwarding or NG-U tunnel details matter.
Preserve the Target to Source Transparent Container correlation because it is needed when the command path returns toward the source side.
Common Issues and Troubleshooting
The handover branch continues, but some PDU sessions disappear after the move.
Likely cause: Handover Request Acknowledge may have reported a mixed result, with some session items admitted and others already marked failed before execution.
What to inspect: Compare admitted and failed lists item by item instead of treating the acknowledge as a blanket success.
Next step: Debug the missing sessions from the failed list and the follow-on release handling rather than blaming the final execution step alone.
The source receives a later command, but execution details look wrong or incomplete.
Likely cause: The Target to Source Transparent Container or the admitted-session transfer data may not align with the target preparation that actually occurred.
What to inspect: Correlate the acknowledge container and admitted-session transfer payloads with the later Handover Command branch.
Next step: Fix the target-derived execution context before treating the issue as a pure radio move failure.
Target preparation looked successful at a glance, but the UE still never had full service continuity.
Likely cause: Admitted sessions may have had constrained forwarding or tunnel information, or some session items may already have failed during target preparation.
What to inspect: Check section 9.3.4.11-derived details such as DL NG-U UP TNL Information, QoS Flow Setup Response List, and forwarding-related fields for the admitted items.
Next step: Treat the issue as a per-session preparation result problem, not only as a handover execution problem.
LTE / 5G / Variant Comparison
Compared with Handover Request
Handover Request asks the target to prepare the incoming UE. Handover Request Acknowledge reports which resources were actually prepared and returns the target-derived transparent container.
Compared with Handover Preparation Failure
Handover Request Acknowledge is the success-side result with admitted resources. Handover Preparation Failure is the failure-side message that stops the preparation branch.
Compared with PDU Session Resource Setup Response
Both are result-style messages with admitted and failed session semantics, but Handover Request Acknowledge is embedded inside a mobility branch and adds the target-to-source transparent container plus target-assigned RAN UE NGAP ID.
FAQ
What is Handover Request Acknowledge in 5G NGAP?
It is the target NG-RAN to AMF message that reports the prepared resources at the target and provides the data needed to continue toward handover execution.
What are the key fields in Handover Request Acknowledge?
The operational core is AMF UE NGAP ID, target-assigned RAN UE NGAP ID, PDU Session Resource Admitted List, optional PDU Session Resource Failed to Setup List, and Target to Source Transparent Container.
Can this message include both admitted and failed PDU session items?
Yes. The admitted list is the normal success payload, and an optional failed list can appear at the same time if some sessions could not be prepared at the target.
Why does the Target to Source Transparent Container matter?
Because the source side still needs target-derived execution context before the UE can be commanded to move, and this container is the bridge that carries that information back through the AMF.
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.
