Path Switch Request is the NGAP message the new serving NG-RAN sends to the AMF after successful mobility execution to report the new serving node and deliver per-session downlink NG-U tunnel termination information for one or more PDU session resources.
UE-associated NGAP signaling context on the new serving NG-RAN / SCTP carried NGAP initiatingMessage
Typical trigger
The UE has successfully reached the target side, the new serving NG-RAN is ready to become the active serving node, and the core must be told where downlink traffic for each affected PDU session should terminate.
Main purpose
Tells the AMF that the UE is now served by the new NG-RAN node and carries the per-session downlink tunnel information the AMF must relay to each SMF so the user-plane path can follow the move.
Path Switch Request is the NGAP message the new serving NG-RAN sends to the AMF after successful mobility execution to report the new serving node and deliver per-session downlink NG-U tunnel termination information for one or more PDU session resources.
Tells the AMF that the UE is now served by the new NG-RAN node and carries the per-session downlink tunnel information the AMF must relay to each SMF so the user-plane path can follow the move.
Why this message matters
Path Switch Request is the new serving gNB telling the AMF that the UE has moved and that downlink traffic for each affected PDU session now needs to terminate on the new serving side.
Where this message appears in the call flow
Post-handover serving-node update
Serving-node update branch: after the UE is on the target side, the new serving NG-RAN asks the core to move the downlink path.
Call flow position: After the UE has completed the move and the target side is now the serving NG-RAN, the new serving node sends Path Switch Request to the AMF.
Typical state: Radio mobility has already succeeded, but the core still needs the updated per-session downlink path so traffic follows the UE correctly.
Preconditions:
The new serving NG-RAN has an active UE context after the mobility execution branch completed.
At least one PDU session needs the downlink path updated, unless the branch is the special IAB-MT no-session case defined by the specification.
The new serving NG-RAN can provide Path Switch Request Transfer for each affected admitted PDU session item.
Next likely message: Path Switch Request Acknowledge from AMF to the new serving NG-RAN
Mixed session path-switch result reporting
Mixed-result branch: some sessions are switched toward the new serving node while others already fail during the path-switch stage.
Call flow position: The new serving NG-RAN can report one or more switched sessions together with a failed-to-setup list for session items that could not be carried forward cleanly.
Typical state: The overall mobility branch can continue even if not every PDU session survives the path-switch update.
Preconditions:
The new serving NG-RAN evaluated each affected PDU session after the UE moved.
The target-side context is strong enough to continue mobility even if some session items failed path-switch setup.
Next likely message: Path Switch Request Acknowledge plus session-specific recovery or release handling
Special context reporting during path switch
Context branch: the new serving NG-RAN can include resume, capability, or source-AMF context while requesting the path update.
Call flow position: The new serving NG-RAN includes optional context such as RRC Resume Cause, RedCap or eRedCap indication, or Source AMF GUAMI while requesting the path update.
Typical state: The path switch is still a serving-path update, but the AMF is also being reminded about special access or source-AMF context relevant to the moved UE.
Preconditions:
The new serving NG-RAN has optional context that the specification permits it to include in the request.
AMF-side continuation logic benefits from knowing the source AMF or special capability state carried by the request.
Next likely message: Path Switch Request Acknowledge with any follow-on user-plane or UE-context updates
Transport / encapsulation: NGAP over SCTP/IP between new serving NG-RAN and AMF
Security context: The message carries UE Security Capabilities as part of the post-mobility update, but it is not a security-establishment message. Its operational role is to move the downlink user-plane path and align the core with the new serving NG-RAN after mobility execution already succeeded.
Message Structure Overview
Path Switch Request is the new serving NG-RAN to AMF initiatingMessage for the path-switch phase after mobility execution has already succeeded.
The message tells the AMF which node now serves the UE and which per-session downlink tunnel endpoints must be relayed to the relevant SMFs.
The switched-in-downlink list is the core operational payload because each item carries Path Switch Request Transfer from section 9.3.4.8.
The failed-to-setup list is optional but important when mobility succeeded at radio level while one or more session-level path updates did not.
User Location Information and the identity pair anchor the message to the new serving location and the ongoing UE context.
Decode this message in layers: first prove which new serving NG-RAN context is talking by using RAN UE NGAP ID, Source AMF UE NGAP ID, and User Location Information, then inspect the switched-in-downlink list, then inspect any failed session items. Path Switch Request Transfer in section 9.3.4.8 is transparent to the AMF and carries the new downlink NG-U termination information plus accepted QoS flow details for each admitted session, while section 9.3.4.15 gives the failure cause for any rejected path-switch item.
The switched list is not just a session roster. Each admitted item carries Path Switch Request Transfer, where the new serving NG-RAN provides DL NG-U UP TNL Information and the accepted QoS flow list for that session.
The failed list is normal when mobility was radio-successful but some session-level path updates could not be carried forward cleanly.
If Source AMF GUAMI is present, it adds source-AMF identity context to the post-mobility update rather than changing the fundamental message role.
Important Information Elements
IE
Required
Description
RAN UE NGAP ID
Yes
Mandatory NG-RAN UE identifier used by the new serving node to identify the active UE context that now owns the UE after mobility.
Source AMF UE NGAP ID
Yes
Mandatory source-AMF UE identifier that lets the AMF correlate the post-mobility request with the existing core-side UE context.
User Location Information
Yes
Mandatory user location context proving where the UE is now being served when the new serving node requests the path change.
UE Security Capabilities
Yes
Mandatory UE capability context carried with the path-switch request as part of the serving-node update.
PDU Session Resource to be Switched in Downlink List
Yes
Mandatory list of session items whose downlink path should now terminate at the new serving NG-RAN. Each item contains PDU Session ID and Path Switch Request Transfer from section 9.3.4.8.
PDU Session Resource Failed to Setup List
Optional
Optional list of session items that could not be carried forward during the path-switch stage. Each item contains Path Switch Request Setup Failed Transfer from section 9.3.4.15.
RRC Resume Cause
Optional
Optional resume-cause context that can be used by the AMF in the cases described by the specification.
RedCap Indication
Optional
Optional indication that the moved UE should be considered a RedCap UE in the path-switch context.
eRedCap Indication
Optional
Optional indication that the moved UE should be considered an eRedCap UE in the path-switch context.
Source AMF GUAMI
Optional
Optional source-AMF identity information included when the currently serving AMF GUAMI is available at the gNB.
Detailed field explanation
RAN UE NGAP ID
Mandatory NG-RAN UE identifier used by the new serving node to identify the active UE context that now owns the UE after mobility.
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 AMF UE NGAP ID
Mandatory source-AMF UE identifier that lets the AMF correlate the post-mobility request with the existing core-side 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.
User Location Information
Mandatory user location context proving where the UE is now being served when the new serving node requests the path change.
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 capability context carried with the path-switch request as part of the serving-node update.
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 to be Switched in Downlink List
Mandatory list of session items whose downlink path should now terminate at the new serving NG-RAN. Each item contains PDU Session ID and Path Switch Request Transfer from section 9.3.4.8.
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 session items that could not be carried forward during the path-switch stage. Each item contains Path Switch Request Setup Failed Transfer from section 9.3.4.15.
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 Resume Cause
Optional resume-cause context that can be used by the AMF in the cases described by the specification.
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 moved UE should be considered a RedCap UE in the path-switch 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.
eRedCap Indication
Optional indication that the moved UE should be considered an eRedCap UE in the path-switch 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.
Source AMF GUAMI
Optional source-AMF identity information included when the currently serving AMF GUAMI is available at the gNB.
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 request is sent by the new serving NG-RAN after the mobility execution branch completed.
Match RAN UE NGAP ID and Source AMF UE NGAP ID to the ongoing handover context before reading any session details.
Inspect User Location Information to verify the serving location really changed as expected.
Enumerate every item in the switched-in-downlink list and failed-to-setup list before judging whether the path switch was fully or only partially successful.
Inspect Path Switch Request Transfer for each admitted session when downlink tunnel or QoS continuity is under suspicion.
Common Issues and Troubleshooting
Handover completed, but downlink traffic still behaves like it follows the old path or never reaches the new serving cell.
Likely cause: Path Switch Request may be missing, delayed, or carrying the wrong Path Switch Request Transfer information for the affected session.
What to inspect: Correlate the mobility completion point with the presence of Path Switch Request and the per-session DL NG-U information inside each admitted session transfer.
Next step: Debug the path-switch stage and SMF-side update handling before treating the issue as a pure radio failure.
Some PDU sessions survive the move, but others disappear after handover.
Likely cause: The request may contain a mixed result, with some sessions in the switched-in-downlink list and others already placed in the failed-to-setup list.
What to inspect: Read the switched and failed lists together, then inspect the failed item's Path Switch Request Setup Failed Transfer cause.
Next step: Handle the failed sessions as session-level path-switch failures instead of assuming the whole mobility branch was uniformly successful.
The serving node change looks correct, but AMF behavior or later continuity still looks inconsistent.
Likely cause: The UE context correlation or optional context such as Source AMF GUAMI, RRC Resume Cause, or capability indication may not match the expected branch.
What to inspect: Check the identity pair, location, and any optional context IEs against the handover path that actually occurred.
Next step: Fix the post-mobility context alignment before blaming later acknowledgment handling alone.
LTE / 5G / Variant Comparison
Compared with Handover Request Acknowledge
Handover Request Acknowledge proves the target prepared resources before the UE moves. Path Switch Request is sent later, after the UE has moved, to switch the core-side downlink path toward the new serving node.
Compared with Path Switch Request Acknowledge
Path Switch Request asks the AMF and connected SMFs to apply the new serving-path state. Path Switch Request Acknowledge returns the resulting uplink path information and any released-session outcome.
Compared with PDU Session Resource Setup Response
Both can report per-session success and failure semantics, but Path Switch Request is a post-mobility path update and its per-session transfer carries new downlink tunnel termination information rather than initial bearer-establishment results.
FAQ
What is Path Switch Request in 5G NGAP?
It is the new serving NG-RAN to AMF message used after mobility execution to report the new serving node and provide the per-session downlink tunnel information needed to switch the user-plane path.
What are the key fields in Path Switch Request?
The operational core is RAN UE NGAP ID, Source AMF UE NGAP ID, User Location Information, UE Security Capabilities, and the PDU Session Resource to be Switched in Downlink List carrying Path Switch Request Transfer for each admitted session.
Can Path Switch Request include failed session items?
Yes. The PDU Session Resource Failed to Setup List is optional and can appear when some session-level path updates fail even though the UE has already moved successfully.
Why does Path Switch Request matter so much in trace analysis?
Because a clean handover at radio level does not guarantee the downlink path followed the move. Path Switch Request is where the new serving node tells the core how to redirect the user plane.
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.
