Path Switch Request Failure is the AMF-to-NG-RAN message used on the unsuccessful branch of the Path Switch Request procedure when the 5GC cannot switch the NG-U downlink termination point for all requested PDU session resources.
UE-associated NGAP signaling / SCTP carried NGAP unsuccessfulOutcome from AMF to NG-RAN in the Path Switch Request procedure
Typical trigger
After receiving Path Switch Request from the target or new serving NG-RAN, the AMF and 5GC cannot switch the NG-U downlink termination point for all requested PDU session resources.
Main purpose
Tells the NG-RAN that the core path switch failed, identifies the PDU session resources that must be treated as released, and carries per-session failure detail through Path Switch Request Unsuccessful Transfer.
What is Path Switch Request Failure in simple terms?
Path Switch Request Failure is the AMF-to-NG-RAN message used on the unsuccessful branch of the Path Switch Request procedure when the 5GC cannot switch the NG-U downlink termination point for all requested PDU session resources.
Tells the NG-RAN that the core path switch failed, identifies the PDU session resources that must be treated as released, and carries per-session failure detail through Path Switch Request Unsuccessful Transfer.
Why this message matters
Path Switch Request Failure means the UE already moved successfully at radio level, but the core could not finish moving the user-plane path, so the listed PDU sessions must be released.
Where this message appears in the call flow
Unsuccessful outcome of Path Switch Request
Failure branch: the UE already reached the target side, but the core cannot complete the downlink path switch.
Call flow position: After handover arrival has already been confirmed and the NG-RAN sent Path Switch Request, the AMF returns Path Switch Request Failure when the core path update cannot be completed.
Typical state: Radio mobility succeeded, but the core user-plane switch did not. The listed PDU session resources must be treated as released on the NG-RAN side.
Preconditions:
The UE already completed target-side access and Path Switch Request was sent.
The AMF and 5GC attempted to move the downlink NG-U termination point.
The path switch could not be completed for all requested PDU session resources.
Next likely message: NG-RAN-side release handling for the listed QoS flows rather than Path Switch Request Acknowledge
Core path switch fails after handover
Failure branch: the UE already reached the target side, but the core cannot complete the downlink path switch.
Released sessions and QoS flow cleanup
Release branch: the NG-RAN uses the released-session list to clear the corresponding QoS flows after the failed path switch.
Acknowledge versus failure branch
Outcome branch: Path Switch Request Acknowledge means the core path moved successfully, while Path Switch Request Failure means the switch could not be completed.
Domain: UE mobility management and post-handover core path-switch failure handling
Signaling bearer: UE-associated NGAP signaling
Logical channel: SCTP carried NGAP unsuccessfulOutcome from AMF to NG-RAN in the Path Switch Request procedure
Transport / encapsulation: NGAP over SCTP/IP between AMF and NG-RAN
Security context: The message is sent on the existing UE-associated post-handover context. It indicates that radio-level handover completion already happened, but the 5GC could not complete the user-plane path switch for the affected PDU session resources.
Message Structure Overview
Path Switch Request Failure is the AMF-to-NG-RAN unsuccessfulOutcome message for the Path Switch Request procedure.
AMF UE NGAP ID and RAN UE NGAP ID anchor the failure to the existing post-handover UE context.
The mandatory PDU Session Resource Released List is the operational center of gravity because it tells the NG-RAN which sessions are now released.
Each released session item carries Path Switch Request Unsuccessful Transfer, which holds the session-level cause detail engineers should inspect.
This message means radio-level handover reached the target, but the core path switch did not complete successfully.
Decode this message by first matching the AMF UE NGAP ID and RAN UE NGAP ID to the Path Switch Request that failed, then enumerate every item in PDU Session Resource Released List. The per-session reason lives inside Path Switch Request Unsuccessful Transfer, not in the top-level message name alone.
5G NGAP - Path Switch Request Failure - Example Dump
Treat this as a teaching example based on the spec structure, not as a captured trace.
The released-session list is mandatory because the NG-RAN must know which PDU session resources are now treated as released.
Always inspect Path Switch Request Unsuccessful Transfer for session-level interpretation.
Do not misread this as a radio handover failure. It is a post-handover core path-switch failure.
Important Information Elements
IE
Required
Description
Message Type
Yes
Identifies the NGAP PDU as Path Switch Request Failure.
AMF UE NGAP ID
Yes
Mandatory AMF-side UE identifier used to bind the failure to the correct UE context in the core.
RAN UE NGAP ID
Yes
Mandatory NG-RAN UE identifier used to bind the failure to the correct active UE context on the serving side.
PDU Session Resource Released List
Yes
Mandatory list of PDU session resources that the NG-RAN shall regard as released. Each item contains PDU Session ID and Path Switch Request Unsuccessful Transfer.
Criticality Diagnostics
Optional
Optional protocol diagnostics useful when IE handling or abnormal request content contributed to the failure.
Detailed field explanation
Message Type
Identifies the NGAP PDU as Path Switch Request Failure.
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.
AMF UE NGAP ID
Mandatory AMF-side UE identifier used to bind the failure to the correct UE context 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.
RAN UE NGAP ID
Mandatory NG-RAN UE identifier used to bind the failure to the correct active UE context on the serving 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 Released List
Mandatory list of PDU session resources that the NG-RAN shall regard as released. Each item contains PDU Session ID and Path Switch Request Unsuccessful Transfer.
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 useful when IE handling or abnormal request content contributed to the failure.
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 Path Switch Request Failure follows Path Switch Request for the same UE context.
Match AMF UE NGAP ID and RAN UE NGAP ID before interpreting any released-session result.
Decode every item in PDU Session Resource Released List and inspect Path Switch Request Unsuccessful Transfer for each one.
Verify the NG-RAN releases the corresponding QoS flows after the failure.
Check the original request for duplicate PDU Session ID values if abnormal-condition handling is suspected.
Keep this failure distinct from radio-level handover failure messages such as Handover Failure.
Common Issues and Troubleshooting
Trace review treats the event as a failed handover even though the UE reached the target cell.
Likely cause: Path Switch Request Failure is being confused with a radio mobility failure.
What to inspect: Check whether Handover Notify and Path Switch Request already occurred successfully before the failure.
Next step: Debug the core path-switch stage and released-session handling instead of re-opening radio handover analysis first.
The top-level failure is visible, but the actual session-level reason remains unclear.
Likely cause: Review stops at the message name and does not decode Path Switch Request Unsuccessful Transfer.
What to inspect: Read each released PDU session item and decode its unsuccessful transfer payload.
Next step: Use the transfer-level cause to explain why each session was released.
Unexpected released sessions appear after handover.
Likely cause: The 5GC could not complete the downlink path switch for those sessions, or the original request had abnormal content such as duplicate PDU Session IDs.
What to inspect: Compare the released-session list against the original Path Switch Request and inspect clause-8.4.4.4 abnormal-condition triggers.
Next step: Fix request construction or core-side session handling before retrying similar path-switch scenarios.
LTE / 5G / Variant Comparison
Compared with Path Switch Request Acknowledge
Path Switch Request Acknowledge confirms the core path switch completed and returns the new serving-side result. Path Switch Request Failure says the core could not complete the path switch and returns released-session information instead.
Compared with Handover Notify
Handover Notify proves the UE reached the target cell. Path Switch Request Failure shows that the later core user-plane switch still failed.
Why the released-session list is mandatory
The failure is not just informational. The NG-RAN must know exactly which PDU sessions are now released and which QoS flows to clear.
FAQ
What is Path Switch Request Failure in 5G NGAP?
It is the AMF-to-NG-RAN unsuccessful outcome message used when the 5GC cannot complete the path switch after handover.
Who sends Path Switch Request Failure?
The AMF sends Path Switch Request Failure to the NG-RAN node.
When is Path Switch Request Failure used?
It is used after Path Switch Request when the 5GC cannot switch the NG-U downlink termination point for all requested PDU session resources.
What happens after Path Switch Request Failure?
The NG-RAN releases the corresponding QoS flows, and the listed PDU sessions are treated as released.
What is PDU Session Resource Released List in Path Switch Request Failure?
It is the mandatory list of sessions the NG-RAN must regard as released after the failed path switch.
Where is the actual per-session cause carried?
It is carried inside Path Switch Request Unsuccessful Transfer for each released session item.
Can duplicate PDU Session IDs trigger Path Switch Request Failure?
Yes. Clause 8.4.4.4 explicitly says the AMF shall send Path Switch Request Failure if duplicate PDU Session ID values are present in the switched-in-downlink list.
What is the difference between Path Switch Request Acknowledge and Failure?
Acknowledge means the core path switch completed, while Failure means the core could not complete the switch and the listed sessions are released.
Does this mean the radio handover failed?
No. This message appears after successful arrival at the target side. It means the later core user-plane path switch failed.
What happens to the QoS flows after this message?
The NG-RAN releases the QoS flows corresponding to the released PDU sessions identified in the message.
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.
