Path Switch Request is the target-NG-RAN-to-AMF message used after successful handover so the 5GC can switch the NG-U downlink termination point to the new target-side termination point.
UE-associated NGAP signaling / SCTP carried NGAP initiatingMessage from target NG-RAN to AMF in the Path Switch Request procedure
Typical trigger
The UE has already reached the target NG-RAN after handover, the target has confirmed arrival, and the core network now needs to switch the NG-U downlink termination point to the target-side path.
Main purpose
Asks the 5GC to switch the downlink user-plane path to the target NG-RAN, updates the AMF with the UE's new location and security-related context, and carries per-session path-switch transfer information for the affected PDU sessions.
Path Switch Request is the target-NG-RAN-to-AMF message used after successful handover so the 5GC can switch the NG-U downlink termination point to the new target-side termination point.
Asks the 5GC to switch the downlink user-plane path to the target NG-RAN, updates the AMF with the UE's new location and security-related context, and carries per-session path-switch transfer information for the affected PDU sessions.
Why this message matters
Path Switch Request is the target NG-RAN telling the AMF that the UE already moved successfully and that the core must now move the downlink user-plane path for the affected PDU sessions.
Where this message appears in the call flow
Post-handover path-switch request
Request branch: after the UE is on the target side and Handover Notify has completed, the target NG-RAN asks the core to move the downlink path.
Call flow position: After the UE completed handover to the target side and the target NG-RAN reported arrival with Handover Notify, the target asks the AMF to move the downlink user-plane path.
Typical state: Radio mobility is already complete, but the core user-plane path still needs to be switched toward the new serving side.
Preconditions:
The UE already reached the target NG-RAN and the target has an active UE context.
The target NG-RAN has confirmed arrival with Handover Notify.
At least one PDU session resource needs the NG-U downlink termination point switched.
Next likely message: Path Switch Request Acknowledge on success or Path Switch Request Failure on unsuccessful completion
Target side requests the core path move
Request branch: after the UE is on the target side and Handover Notify has completed, the target NG-RAN asks the core to move the downlink path.
Per-session switching detail in the request
Session branch: each affected PDU session is represented in the switched-in-downlink list and carries Path Switch Request Transfer.
Success and failure outcomes after the request
Outcome branch: the request leads to either Path Switch Request Acknowledge or Path Switch Request Failure depending on whether the core can complete the path switch.
Call flow position
Previous message(s):Handover Notify, Target-side handover completion, UE arrival confirmed at the target side
Domain: UE mobility management and post-handover core path-switch initiation
Signaling bearer: UE-associated NGAP signaling
Logical channel: SCTP carried NGAP initiatingMessage from target NG-RAN to AMF in the Path Switch Request procedure
Transport / encapsulation: NGAP over SCTP/IP between target NG-RAN and AMF
Security context: The message is sent after radio-level handover completion and carries UE security capabilities together with optional security-context-related information. Its job is to move the core-side user-plane path, not to perform the handover itself.
Message Structure Overview
Path Switch Request is the target-NG-RAN-to-AMF initiatingMessage sent after successful radio-level handover completion.
Its core job is to ask the 5GC to switch the NG-U downlink termination point to the target-side path.
AMF UE NGAP ID, RAN UE NGAP ID, User Location Information, and UE Security Capabilities anchor the message to the correct post-handover UE context.
The PDU Session Resource To Be Switched In Downlink List is the operational center of gravity because each item carries Path Switch Request Transfer for a specific session.
The next branch is either Path Switch Request Acknowledge or Path Switch Request Failure, so the request should always be read together with its per-session follow-up result.
ASN.1 for 5G NGAP - Path Switch Request
PathSwitchRequest ::= SEQUENCE {
protocolIEs ProtocolIE-Container { {PathSwitchRequest-IEs} },
...
}
PathSwitchRequest-IEs NGAP-PROTOCOL-IES ::= {
{ AMF UE NGAP ID, mandatory } |
{ RAN UE NGAP ID, mandatory } |
{ User Location Information, mandatory } |
{ UE Security Capabilities, mandatory } |
{ PDU Session Resource To Be Switched In Downlink List, mandatory } |
{ UE Aggregate Maximum Bit Rate, optional } |
{ Allowed NSSAI, optional } |
{ Security Context, optional } |
{ New Security Context Indication, optional } |
{ NR CGI, optional } |
{ TAI, optional } |
{ CN Assisted RAN Parameters Tuning, optional } |
{ RRC Inactive Transition Report Request, optional },
...
}
PDU Session Resource To Be Switched In Downlink Item ::= SEQUENCE {
pduSessionID PDU Session ID,
pathSwitchRequestTransfer OCTET STRING,
...
}
How to read this ASN.1
Decode this message in layers: first bind the UE context with AMF UE NGAP ID, RAN UE NGAP ID, and User Location Information, then read the PDU Session Resource To Be Switched In Downlink List item by item. Path Switch Request Transfer is where the per-session switch detail lives, so trace interpretation should never stop at the top-level message name.
Treat this as a teaching example based on the spec structure, not as a captured trace.
The session list is the most important payload because it tells the core which PDU sessions need their downlink path switched.
Path Switch Request Transfer carries the per-session switch detail, so decode it before assuming you understand the request outcome.
The request itself does not say whether the procedure will succeed or fail. That comes from Path Switch Request Acknowledge or Path Switch Request Failure.
Important Information Elements
IE
Presence
Description
Message Type
Mandatory
Identifies the NGAP PDU as Path Switch Request.
AMF UE NGAP ID
Mandatory
Mandatory AMF-side UE identifier used by the AMF to correlate the request with the correct UE context.
RAN UE NGAP ID
Mandatory
Mandatory target-NG-RAN UE identifier used to bind the request to the active target-side UE context.
User Location Information
Mandatory
Mandatory updated UE location at the target side after handover.
UE Security Capabilities
Mandatory
Mandatory UE-supported security capability information relevant to continued service after the move.
PDU Session Resource To Be Switched In Downlink List
Mandatory
Mandatory list of PDU sessions whose downlink path must be switched to the target-side termination point. Each item contains PDU Session ID and Path Switch Request Transfer.
UE Aggregate Maximum Bit Rate
Optional
Optional UE aggregate maximum bit rate context.
Allowed NSSAI
Optional
Optional allowed-slice information returned in the broader path-switch handling context.
Security Context
Optional
Optional security-context-related information carried with the request context.
New Security Context Indication
Optional
Optional indication that the security context handling changed.
NR CGI
Optional
Optional target cell identity when represented separately from the broader location IE.
TAI
Optional
Optional tracking area identity when represented separately from the broader location IE.
CN Assisted RAN Parameters Tuning
Optional
Optional CN-assisted tuning information relevant to target-side continuation.
RRC Inactive Transition Report Request
Optional
Optional request affecting later reporting behavior after the path switch branch.
Detailed field explanation
Message Type
Identifies the NGAP PDU as Path Switch Request.
Presence: Mandatory
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 by the AMF to correlate the request with the correct UE context.
Presence: Mandatory
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-NG-RAN UE identifier used to bind the request to the active target-side UE context.
Presence: Mandatory
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 updated UE location at the target side after handover.
Presence: Mandatory
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-supported security capability information relevant to continued service after the move.
Presence: Mandatory
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 PDU sessions whose downlink path must be switched to the target-side termination point. Each item contains PDU Session ID and Path Switch Request Transfer.
Presence: Mandatory
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
Optional UE aggregate maximum bit rate 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.
Allowed NSSAI
Optional allowed-slice information returned in the broader path-switch handling 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.
Security Context
Optional security-context-related information carried with the request 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.
New Security Context Indication
Optional indication that the security context handling changed.
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.
NR CGI
Optional target cell identity when represented separately from the broader location IE.
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.
TAI
Optional tracking area identity when represented separately from the broader location IE.
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.
CN Assisted RAN Parameters Tuning
Optional CN-assisted tuning information relevant to target-side continuation.
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 Inactive Transition Report Request
Optional request affecting later reporting behavior after the path switch 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.
Match AMF UE NGAP ID and RAN UE NGAP ID to the correct UE context before reading session details.
Verify User Location Information reflects the target-side location.
Decode every item in PDU Session Resource To Be Switched In Downlink List and inspect the Path Switch Request Transfer payload.
Check the request for duplicate PDU Session ID values because that can trigger Path Switch Request Failure.
Follow the request into either Path Switch Request Acknowledge or Path Switch Request Failure and correlate any released-session results.
Common Issues and Troubleshooting
The trace shows Handover Notify, but engineers assume the core path was already switched.
Likely cause: Handover Notify and Path Switch Request are being treated as the same step.
What to inspect: Check whether Path Switch Request was sent after Handover Notify and whether the AMF returned acknowledge or failure.
Next step: Separate radio-level handover completion from the later core path-switch stage.
The request is present, but continuity still fails for one or more sessions.
Likely cause: The per-session Path Switch Request Transfer content may be wrong, incomplete, or later rejected.
What to inspect: Decode the switched-in-downlink list item by item and correlate each one with the later acknowledge or failure result.
Next step: Debug the per-session transfer content and follow-on branch instead of treating the request as a generic success marker.
The AMF rejects the procedure unexpectedly.
Likely cause: The request may contain abnormal content such as duplicate PDU Session IDs, or later slice-related conditions may fail on the response side.
What to inspect: Validate the request list for duplicates and compare follow-on handling against the abnormal-condition rules.
Next step: Correct request construction and then re-check the success or failure branch.
LTE / 5G / Variant Comparison
Compared with Handover Notify
Handover Notify confirms the UE reached the target cell. Path Switch Request is the next step that asks the core to move the user-plane path to the target side.
Compared with Path Switch Request Acknowledge
Path Switch Request initiates the core path update. Path Switch Request Acknowledge is the successful response that returns post-switch session and context information.
Compared with Path Switch Request Failure
Path Switch Request starts the procedure. Path Switch Request Failure reports that the core could not complete the downlink path switch and returns released-session information instead.
FAQ
What is Path Switch Request in 5G NGAP?
It is the target-NG-RAN-to-AMF message used after successful handover so the 5GC can switch the NG-U downlink termination point to the target-side path.
Who sends Path Switch Request?
The target NG-RAN node sends Path Switch Request to the AMF.
When is Path Switch Request used?
It is used after the UE has already reached the target side and the target needs the core to move the downlink user-plane path.
What is the difference between Handover Notify and Path Switch Request?
Handover Notify confirms arrival at the target cell, while Path Switch Request asks the core to switch the user-plane path afterward.
What is PDU Session Resource To Be Switched In Downlink List?
It is the mandatory list of PDU sessions whose downlink termination point should be switched to the target-side path.
What does Path Switch Request Transfer carry?
It carries the per-session switch details the core needs in order to perform the path switch for that PDU session.
What happens after Path Switch Request?
The next branch is either Path Switch Request Acknowledge on success or Path Switch Request Failure on unsuccessful completion.
What causes Path Switch Request Failure?
It happens when the 5GC cannot switch the downlink termination point for all requested PDU session resources or when abnormal request content triggers failure handling.
Can duplicate PDU Session IDs break the procedure?
Yes. The abnormal-condition text explicitly says duplicate PDU Session ID values in the switched list cause the AMF to send Path Switch Request Failure.
Does Path Switch Request mean the radio handover already succeeded?
Yes. This message belongs to the post-handover stage, so radio-level handover completion has already occurred.
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.
