Path Switch Request Acknowledge is the NGAP message the AMF sends to the new serving NG-RAN to confirm that the path switch completed in the 5GC, provide the per-session uplink tunnel information, return the updated security context, and identify any PDU sessions that were released instead of switched.
UE-associated NGAP signaling context on the new serving NG-RAN / SCTP carried NGAP successfulOutcome
Typical trigger
The AMF and connected 5GC functions have completed the required updates for at least one affected PDU session in response to Path Switch Request, and the new serving NG-RAN now needs the confirmed uplink path and completion result.
Main purpose
Confirms that the 5GC completed the path switch, gives the new serving NG-RAN the per-session uplink NG-U termination information and updated security context, and reports any PDU sessions that were released during the completion stage.
What is Path Switch Request Acknowledge in simple terms?
Path Switch Request Acknowledge is the NGAP message the AMF sends to the new serving NG-RAN to confirm that the path switch completed in the 5GC, provide the per-session uplink tunnel information, return the updated security context, and identify any PDU sessions that were released instead of switched.
Confirms that the 5GC completed the path switch, gives the new serving NG-RAN the per-session uplink NG-U termination information and updated security context, and reports any PDU sessions that were released during the completion stage.
Why this message matters
Path Switch Request Acknowledge is the AMF telling the new serving gNB that the core path switch finished, here is the new uplink path information, here is the security context to use, and here are any sessions that were released instead of kept.
Where this message appears in the call flow
Core confirms successful path switch
Completion branch: the AMF confirms the path switch and returns the new-serving-side uplink session information.
Call flow position: After Path Switch Request has been processed and the core-side updates are finished for at least one PDU session, the AMF sends Path Switch Request Acknowledge to the new serving NG-RAN.
Typical state: The radio move and the core-side path update have both succeeded enough to continue stable target-side service.
Preconditions:
The new serving NG-RAN already sent Path Switch Request.
The AMF and related SMF-side updates completed for at least one affected PDU session resource.
The AMF is ready to return the updated Security Context and any per-session Path Switch Request Acknowledge Transfer information.
Next likely message: Source-side cleanup or continued service on the new serving side
Per-session uplink path confirmation
Mixed-result branch: the overall procedure succeeds while some PDU sessions are explicitly released.
Call flow position: The switched list returns the per-session completion details needed by the new serving NG-RAN to transmit uplink user-plane traffic correctly.
Typical state: The new serving NG-RAN can now store the returned UL NG-U information and related QoS parameters for each switched session.
Preconditions:
A session item was accepted during the core path-switch phase.
The AMF can return Path Switch Request Acknowledge Transfer for the switched PDU session item.
Next likely message: Live service continuation or PDU Session Resource Notify if returned QoS-related parameters cannot be accepted
Released-session reporting during completion
Context branch: the completion result can refresh security, slice, and RRC_INACTIVE-related UE state on the new serving side.
Call flow position: The AMF can also tell the new serving NG-RAN which session items were released instead of kept through the path-switch completion.
Typical state: The overall path switch completed, but one or more PDU sessions must be treated as released on the new serving side.
Preconditions:
At least one session item could not remain active through the path-switch completion result.
The AMF includes PDU Session Resource Released List with Path Switch Request Unsuccessful Transfer causes for the released items.
Next likely message: NG-RAN releases the affected session QoS flows and continues only with the remaining switched sessions
Transport / encapsulation: NGAP over SCTP/IP between AMF and the new serving NG-RAN
Security context: This message is operationally important because the AMF returns a mandatory Security Context and can optionally refine it with UE Security Capabilities and a New Security Context Indicator. The message closes the core-side path-switch phase and equips the new serving NG-RAN to use the correct uplink user-plane endpoints and current security state.
Message Structure Overview
Path Switch Request Acknowledge is the AMF-to-new-serving-NG-RAN successfulOutcome message that completes the 5GC side of the path-switch procedure.
The mandatory Security Context, switched-session list, and Allowed NSSAI are the operational center of gravity of the message.
Each switched-session item carries Path Switch Request Acknowledge Transfer from section 9.3.4.9, where the uplink NG-U information and related QoS-return data live.
The optional released-session list is important because the overall message can still be successful while individual PDU sessions are explicitly released.
Many optional context refresh fields can appear, but they do not change the main job: confirm path-switch completion and arm the new serving NG-RAN with the right post-switch state.
ASN.1 for 5G NGAP - Path Switch Request Acknowledge
Decode this message in layers: first confirm the AMF UE NGAP ID and RAN UE NGAP ID pair, then read the mandatory Security Context and Allowed NSSAI, then inspect switched and released session lists together. Path Switch Request Acknowledge Transfer in section 9.3.4.9 is transparent to the AMF and can return UL NG-U UP TNL Information, Security Indication, additional uplink tunnel information, and QoS flow parameters for each switched session, while section 9.3.4.20 gives the cause for each released session item.
5G NGAP - Path Switch Request Acknowledge - Example Dump
Each switched item can return the uplink NG-U endpoint that the new serving NG-RAN must store and use for that PDU session.
The released list does not contradict the top-level successfulOutcome. It means the overall procedure completed while one or more PDU sessions were explicitly released.
If QoS-related parameters returned in the acknowledge transfer cannot be accepted by the NG-RAN, the specification allows the NG-RAN to keep old values if available and notify the AMF with PDU Session Resource Notify.
Important Information Elements
IE
Required
Description
AMF UE NGAP ID
Yes
Mandatory AMF-side UE identifier used to correlate the completion result with the existing UE context in the core.
RAN UE NGAP ID
Yes
Mandatory new-serving-node UE identifier that anchors the acknowledge to the correct active NG-RAN UE context.
Security Context
Yes
Mandatory security context returned by the AMF for the new serving NG-RAN to store and use after the path switch completes.
PDU Session Resource Switched List
Yes
Mandatory list of PDU sessions that remain switched through the new serving node. Each item contains PDU Session ID and Path Switch Request Acknowledge Transfer from section 9.3.4.9, with optional PDU Session Expected UE Activity Behaviour.
Allowed NSSAI
Yes
Mandatory set of S-NSSAIs permitted by the network for the moved UE on the new serving side.
UE Security Capabilities
Optional
Optional UE security capability set that can accompany the returned security context.
New Security Context Indicator
Optional
Optional indication that refines how the returned security context should be handled on the new serving side.
PDU Session Resource Released List
Optional
Optional list of PDU sessions that were released instead of kept through the path-switch completion. Each item contains Path Switch Request Unsuccessful Transfer from section 9.3.4.20.
Core Network Assistance Information for RRC INACTIVE
Optional
Optional core assistance information the new serving NG-RAN stores for RRC_INACTIVE decisions, paging, and related behavior.
RRC Inactive Transition Report Request
Optional
Optional reporting request that can instruct the NG-RAN to send RRC inactive transition reports after the path switch completes.
Criticality Diagnostics
Optional
Optional diagnostics that can help explain unusual protocol handling around the completion result.
UE Radio Capability ID
Optional
Optional radio capability identifier that the new serving NG-RAN can store and use after the completion result.
AMF UE NGAP ID 2
Optional
Optional additional AMF-side UE identifier that the new serving NG-RAN can store for later Xn handovers.
Detailed field explanation
AMF UE NGAP ID
Mandatory AMF-side UE identifier used to correlate the completion result with the existing 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 new-serving-node UE identifier that anchors the acknowledge to the correct active NG-RAN 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.
Security Context
Mandatory security context returned by the AMF for the new serving NG-RAN to store and use after the path switch completes.
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 Switched List
Mandatory list of PDU sessions that remain switched through the new serving node. Each item contains PDU Session ID and Path Switch Request Acknowledge Transfer from section 9.3.4.9, with optional PDU Session Expected UE Activity Behaviour.
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 set of S-NSSAIs permitted by the network for the moved UE on the new 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.
UE Security Capabilities
Optional UE security capability set that can accompany the returned 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.
New Security Context Indicator
Optional indication that refines how the returned security context should be handled on the new serving 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.
PDU Session Resource Released List
Optional list of PDU sessions that were released instead of kept through the path-switch completion. Each item contains Path Switch Request Unsuccessful Transfer from section 9.3.4.20.
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.
Core Network Assistance Information for RRC INACTIVE
Optional core assistance information the new serving NG-RAN stores for RRC_INACTIVE decisions, paging, and related behavior.
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 reporting request that can instruct the NG-RAN to send RRC inactive transition reports after the path switch completes.
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.
Criticality Diagnostics
Optional diagnostics that can help explain unusual protocol handling around the completion 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.
UE Radio Capability ID
Optional radio capability identifier that the new serving NG-RAN can store and use after the completion 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.
AMF UE NGAP ID 2
Optional additional AMF-side UE identifier that the new serving NG-RAN can store for later Xn handovers.
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
Match the acknowledge with the earlier Path Switch Request before reading any per-session outcome.
Capture the returned Security Context and any New Security Context Indicator because the new serving NG-RAN must store and use them.
Enumerate the switched-session list and released-session list together before deciding the post-handover continuity outcome.
Inspect Path Switch Request Acknowledge Transfer for each switched session when uplink path continuity or QoS behavior matters.
Check Allowed NSSAI and any optional RRC_INACTIVE or radio-capability context when the target-side service behavior looks different after the path switch.
Common Issues and Troubleshooting
The UE moved successfully, but uplink traffic still does not behave correctly on the new serving node.
Likely cause: The new serving NG-RAN may not have received, stored, or used the UL NG-U information returned inside Path Switch Request Acknowledge Transfer.
What to inspect: Correlate the switched-session list with each acknowledge transfer and verify the returned UL NG-U UP TNL Information was applied for the affected session.
Next step: Debug the completion-result handling on the new serving NG-RAN before blaming only the earlier Path Switch Request.
Some sessions disappear even though the path switch finished successfully at message level.
Likely cause: The acknowledge may include PDU Session Resource Released List, meaning some sessions were explicitly released during completion.
What to inspect: Read switched and released lists together, then inspect the Path Switch Request Unsuccessful Transfer cause for each released session.
Next step: Treat those sessions as released-session outcomes, not as mysterious user-plane loss after a supposedly full success.
Post-handover service is up, but target-side behavior around RRC inactive, paging, or policy looks unexpectedly different.
Likely cause: Optional context in the acknowledge such as Core Network Assistance Information for RRC INACTIVE, Allowed NSSAI, or updated capability/security context changed the stored UE state.
What to inspect: Compare the returned completion context with the UE behavior seen after the path switch, especially around RRC state handling and slice permissions.
Next step: Debug the stored post-switch UE context, not only the user-plane endpoint values.
LTE / 5G / Variant Comparison
Compared with Path Switch Request
Path Switch Request is the new serving NG-RAN asking the core to move the path. Path Switch Request Acknowledge is the AMF confirming the core-side switch completed and returning the per-session uplink path details plus updated UE context.
Compared with Handover Request Acknowledge
Handover Request Acknowledge belongs to target preparation before the UE moves. Path Switch Request Acknowledge belongs after the move and closes the 5GC-side serving-path update.
Compared with PDU Session Resource Notify
Path Switch Request Acknowledge provides the intended post-switch result. PDU Session Resource Notify becomes relevant later if the NG-RAN cannot accept some returned QoS-related values and needs to tell the AMF.
FAQ
What is Path Switch Request Acknowledge in 5G NGAP?
It is the AMF-to-new-serving-NG-RAN message that confirms the path switch was completed in the 5GC and returns the per-session completion data the new serving node must use.
What are the key fields in Path Switch Request Acknowledge?
The operational core is AMF UE NGAP ID, RAN UE NGAP ID, mandatory Security Context, mandatory PDU Session Resource Switched List, mandatory Allowed NSSAI, and the optional PDU Session Resource Released List.
Can this message release some sessions even though it is a successfulOutcome message?
Yes. The procedure can still complete successfully while the PDU Session Resource Released List identifies session items that the new serving NG-RAN must treat as released.
Why is the acknowledge transfer important?
Because it can carry the UL NG-U endpoint and related QoS information that the new serving NG-RAN must store and use for uplink traffic after the path switch.
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.
