Handover Request is the NGAP message the AMF sends to the target NG-RAN to request preparation of resources for an incoming UE during handover preparation.
UE-associated NGAP signaling context being prepared on the target side / SCTP carried NGAP initiatingMessage
Typical trigger
AMF has received Handover Required from the source side and now needs the target NG-RAN to admit the UE, allocate resources, and prepare per-session handling for the incoming move.
Main purpose
Requests the target NG-RAN to allocate radio, security, and per-session resources for the incoming UE so handover execution can proceed once preparation succeeds.
Handover Request is the NGAP message the AMF sends to the target NG-RAN to request preparation of resources for an incoming UE during handover preparation.
Requests the target NG-RAN to allocate radio, security, and per-session resources for the incoming UE so handover execution can proceed once preparation succeeds.
Why this message matters
Handover Request is the AMF telling the target gNB to get ready for an incoming UE by loading security, session, and mobility context before the UE is told to move.
Where this message appears in the call flow
AMF-mediated N2 target preparation
Target-preparation branch: the AMF asks the target NG-RAN to prepare the incoming UE after the source started the handover branch.
Call flow position: After the source side asked for handover through Handover Required, the AMF sends Handover Request to the chosen target NG-RAN to prepare resources.
Typical state: The UE is still on the source side, while the target NG-RAN is being asked to allocate radio, session, and security context for arrival.
Preconditions:
AMF has accepted the Handover Required branch and selected the target NG-RAN.
The AMF has the source-provided transparent mobility container and the per-session transfer information.
At least one PDU session item is present unless the procedure is in a special no-session branch such as mobile IAB-MT handling.
Next likely message: Handover Request Acknowledge if the target admits the UE
Target admission and resource reservation
Admission branch: the target evaluates security context, session list, and transparent mobility container before accepting the handover.
Call flow position: The target NG-RAN evaluates whether it can create the requested UE context, radio resources, and per-session handling.
Typical state: Admission is not yet guaranteed; Handover Request is the moment where target-side readiness is decided.
Preconditions:
UE Aggregate Maximum Bit Rate, security information, Allowed NSSAI, and session setup list are present.
The target can parse the Source to Target Transparent Container for its preparation branch.
Next likely message: Handover Request Acknowledge on success or Handover Preparation Failure if preparation is rejected
Inter-RAT or special mobility preparation
Special-mobility branch: the AMF relays source-derived mobility context to a target that must prepare beyond the simplest intra-system case.
Call flow position: The AMF requests target preparation for a branch that may involve inter-system mobility, forwarding decisions, or specialized authorization context.
Typical state: The target side needs both the generic handover request core and the source-provided transparent container to decide whether it can continue.
Preconditions:
Handover Type identifies the intended mobility branch.
The target-side admission logic can interpret the received transparent container and session transfers for that branch.
Next likely message: Handover Request Acknowledge or Handover Preparation Failure depending on target readiness
Transport / encapsulation: NGAP over SCTP/IP between AMF and target NG-RAN
Security context: The message carries UE Security Capabilities and Security Context so the target side can prepare a valid incoming UE context before execution. It does not itself move the UE; it prepares the target for that later step.
Message Structure Overview
Handover Request is the AMF-to-target NG-RAN initiatingMessage used to prepare target resources after Handover Required started the N2 handover branch.
The message combines target-admission control, security preparation, per-session setup data, and the Source to Target Transparent Container.
The PDU Session Resource Setup List is the per-session center of gravity because each item carries the Handover Request Transfer that points to section 9.3.4.1.
Allowed NSSAI and GUAMI give the target additional core-context boundaries for what it is preparing.
If this message is incomplete or the target cannot admit it, the handover fails before the UE is commanded to move.
Decode Handover Request in layers: first the top-level target-admission context, then the security and slice constraints, then the per-session setup items. The session transfer is defined as the PDU Session Resource Setup Request Transfer in section 9.3.4.1, which is transparent to the AMF even though it is carried in the handover branch.
The target-side handover story is spread across the mandatory admission fields and the per-session setup list, not just the message header.
The spec table shows AMF UE NGAP ID, Handover Type, Cause, UE Aggregate Maximum Bit Rate, UE Security Capabilities, Security Context, PDU Session Resource Setup List, Allowed NSSAI, Source to Target Transparent Container, and GUAMI as mandatory.
Each Handover Request Transfer points to the PDU Session Resource Setup Request Transfer in section 9.3.4.1, so per-session transport, QoS, and forwarding details live inside those opaque payloads.
Important Information Elements
IE
Required
Description
AMF UE NGAP ID
Yes
Mandatory AMF-side UE identifier used to correlate the incoming handover preparation with the UE context already known in the core.
Handover Type
Yes
Mandatory mobility type indicator that tells the target which overall handover branch is being prepared.
Cause
Yes
Mandatory reason for the handover so the target can interpret why the move is being prepared.
UE Aggregate Maximum Bit Rate
Yes
Mandatory aggregate bit-rate limit used by the target when preparing the incoming UE context and associated resources.
UE Security Capabilities
Yes
Mandatory UE security capability set used by the target during security and context preparation.
Security Context
Yes
Mandatory security context information that lets the target prepare a valid incoming UE security state.
PDU Session Resource Setup List
Yes
Mandatory per-session preparation list. Each item contains PDU Session ID, S-NSSAI, and Handover Request Transfer, which points to the PDU Session Resource Setup Request Transfer in section 9.3.4.1.
Allowed NSSAI
Yes
Mandatory list of S-NSSAIs permitted by the network, which constrains what slice context the target may continue to serve.
Source to Target Transparent Container
Yes
Mandatory source-provided transparent mobility container that the AMF relays to the target for handover preparation.
GUAMI
Yes
Mandatory AMF identity context carried toward the target as part of the prepared incoming UE context.
New Security Context Indicator
Optional
Optional indicator that refines how the target should treat the prepared security context.
NASC
Optional
Optional NAS container associated with N1 mode handling in the handover branch.
Masked IMEISV
Optional
Optional masked equipment identity value carried when this additional UE identity context is needed.
Mobility Restriction List
Optional
Optional mobility restriction context that can limit or shape target-side mobility handling.
Target RAN Node ID
Optional
Optional target RAN node identifier that can further anchor the intended target-side preparation context.
Detailed field explanation
AMF UE NGAP ID
Mandatory AMF-side UE identifier used to correlate the incoming handover preparation with the UE context already known in the core.
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.
Handover Type
Mandatory mobility type indicator that tells the target which overall handover branch is being prepared.
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.
Cause
Mandatory reason for the handover so the target can interpret why the move is being prepared.
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.
UE Aggregate Maximum Bit Rate
Mandatory aggregate bit-rate limit used by the target when preparing the incoming UE context and associated resources.
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.
UE Security Capabilities
Mandatory UE security capability set used by the target during security and context preparation.
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.
Security Context
Mandatory security context information that lets the target prepare a valid incoming UE security state.
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 Setup List
Mandatory per-session preparation list. Each item contains PDU Session ID, S-NSSAI, and Handover Request Transfer, which points to the PDU Session Resource Setup Request Transfer in section 9.3.4.1.
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.
Allowed NSSAI
Mandatory list of S-NSSAIs permitted by the network, which constrains what slice context the target may continue to serve.
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.
Source to Target Transparent Container
Mandatory source-provided transparent mobility container that the AMF relays to the target for handover preparation.
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.
GUAMI
Mandatory AMF identity context carried toward the target as part of the prepared incoming UE context.
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.
New Security Context Indicator
Optional indicator that refines how the target should treat the prepared security context.
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.
NASC
Optional NAS container associated with N1 mode handling in the 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.
Masked IMEISV
Optional masked equipment identity value carried when this additional UE identity context is needed.
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.
Mobility Restriction List
Optional mobility restriction context that can limit or shape target-side mobility handling.
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 RAN Node ID
Optional target RAN node identifier that can further anchor the intended target-side preparation context.
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 Handover Request follows the matching Handover Required branch and targets the expected gNB.
Read Handover Type, Cause, and UE Aggregate Maximum Bit Rate before interpreting any later target admission result.
Verify UE Security Capabilities and Security Context are present and coherent for the incoming UE.
Enumerate every PDU Session Resource Setup Item and compare the session IDs and S-NSSAIs with the source-side handover intent.
Treat the Source to Target Transparent Container and each Handover Request Transfer as critical preparation payloads even though the AMF does not decode their radio-specific inner meaning.
Common Issues and Troubleshooting
The target rejects preparation before the UE ever gets a handover command.
Likely cause: Target admission failed because the handover request did not provide a usable resource, security, session, or transparent-container context for the chosen target.
What to inspect: Check the mandatory admission fields first, then inspect which session item or target constraint likely blocked preparation.
Next step: Fix target admission or context-transfer problems before looking for RF execution faults, because the UE was never meant to move yet.
Only some sessions survive the prepared handover branch.
Likely cause: One or more PDU Session Resource Setup List items may be incomplete, mismatched, or rejected even if the overall handover branch continues.
What to inspect: Compare the requested session list against later acknowledgment or failure information item by item.
Next step: Debug session-granularity admission, not just the top-level handover state.
Target-side security or context looks inconsistent after preparation.
Likely cause: The target may have received a stale or mismatched Security Context, New Security Context Indicator, or source-provided transparent container.
What to inspect: Correlate the source handover decision, Handover Required container content, and the target preparation branch carried by Handover Request.
Next step: Repair security/context continuity before treating later handover execution as an isolated radio problem.
LTE / 5G / Variant Comparison
Compared with Handover Required
Handover Required is source NG-RAN to AMF and asks the core to start preparation. Handover Request is AMF to target NG-RAN and asks the target to admit and prepare the incoming UE.
Compared with Handover Command
Handover Request is still preparation. Handover Command is the later response path that lets the source side tell the UE to execute the move.
Compared with PDU Session Resource Setup Request
Both carry per-session setup information, but Handover Request carries it inside a mobility preparation branch together with handover type, security context, Allowed NSSAI, and the Source to Target Transparent Container.
FAQ
What is Handover Request in 5G NGAP?
It is the AMF-to-target NG-RAN message used to request preparation of resources for the incoming UE during handover preparation.
What are the key fields in Handover Request?
The operational core is AMF UE NGAP ID, Handover Type, Cause, UE Aggregate Maximum Bit Rate, UE Security Capabilities, Security Context, PDU Session Resource Setup List, Allowed NSSAI, Source to Target Transparent Container, and GUAMI.
Why is this message important in trace analysis?
Because it is where the target gNB decides whether it can actually admit and prepare the incoming UE before the handover command is ever sent back toward the source side.
Where do the per-session details live in Handover Request?
They live inside the PDU Session Resource Setup List items. Each item contains Handover Request Transfer, which points to the PDU Session Resource Setup Request Transfer definition in section 9.3.4.1.
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.
