5G SSC Mode Change / Session Continuity Handling Call Flow
5G SSC Mode Change / Session Continuity Handling explains how an active session adapts during mobility or policy events while trying to preserve the running service.
The central engineering question is whether the user experience stayed continuous, not merely whether the network exchanged the right control-plane messages.
Introduction
This procedure matters when a 5G session must survive an operational change such as mobility, route adjustment, or continuity-policy handling.
The best way to analyze it is to anchor on the intended continuity behavior, then compare the applied session changes against live traffic after the event.
What Is SSC Mode Change / Session Continuity Handling in Simple Terms?
- What starts the procedure: Mobility or policy requires an active session to adapt without losing service.
- What the UE and network want to achieve: Preserve usable service continuity while session behavior changes.
- What success looks like: The session adapts and the application stays usable.
- What failure means: Control signaling completes but continuity, correctness, or service quality is lost.
Why this procedure matters
Continuity problems are easy to misdiagnose because the control plane often looks acceptable. The real truth is in whether the active service survived the change cleanly.
Quick Fact Sheet
| Procedure name | 5G SSC Mode Change / Session Continuity Handling |
|---|---|
| Domain | 5G NR + 5GC session continuity and mobility-aware session behavior |
| Main trigger | Mobility, policy, or service behavior requires session continuity handling or SSC-related change |
| Start state | An active session exists and may need continuity-preserving adaptation |
| End state | The session continues with behavior aligned to the required continuity model and service expectations |
| Main nodes | UE, gNB, AMF, SMF, UPF, PCF |
| Main protocols | NAS, NGAP, PFCP, policy-driven session handling |
| Main success outcome | Service continuity is preserved while session behavior is updated correctly |
| Main failure outcome | Continuity handling is misapplied, causing session break, stale paths, or unexpected service change |
| Most important messages | Session modification or mobility-related signaling, updated QoS and path state |
| Main specs | TS 23.501, TS 23.502, TS 24.501 |
Preconditions
- An active PDU session already exists.
- A mobility or policy event requires continuity-aware session handling.
- The network has a clear continuity model or intended service behavior.
- The user-plane path can be adapted without full service teardown where possible.
Nodes and Interfaces
Nodes involved
| Node | Role in this procedure |
|---|---|
| UE | Maintains application service while adapting to continuity-related session changes. |
| gNB | Carries the access-side implications of mobility or continuity handling. |
| AMF | Coordinates control-path signaling tied to mobility and continuity decisions. |
| SMF | Owns the continuity model and applies session updates needed to preserve service. |
| UPF | Maintains or shifts the user-plane path according to continuity handling. |
| PCF | Provides policy decisions that influence continuity-related behavior. |
Interfaces used
| Interface | Path | Role |
|---|---|---|
| NR-Uu | UE <-> gNB | Carries the radio-side continuity implications of the session. |
| N1 | UE <-> AMF | Carries session updates related to continuity handling when needed. |
| N2 | gNB <-> AMF | Coordinates access-side changes during mobility-related continuity events. |
| N11 | AMF <-> SMF | Applies continuity decisions to the active session. |
| N4 / N3 | SMF <-> UPF and gNB <-> UPF | Maintain or adapt the user-plane path during continuity handling. |
End-to-End Call Flow
UE gNB AMF SMF / UPF / PCF
| | | |
|==== active service over session =========================>|
| |<-- mobility / policy event ---------- |
|<-- continuity-related update --------------------------- |
|==== service should continue across updated path ========>|Major Phases
| Phase | What happens |
|---|---|
| 1. Continuity-sensitive event occurs | Mobility or policy creates a need to preserve service while adapting session behavior. |
| 2. Continuity decision | The network decides how the session should continue under the current SSC or service model. |
| 3. Session/path adaptation | Session and user-plane state are updated to preserve service continuity. |
| 4. UE and access alignment | The UE and access side absorb the updated behavior. |
| 5. Service continuity validation | Real traffic proves the session remained usable across the change. |
Step-by-Step Breakdown
A continuity-affecting event appears
Sender -> receiver: Mobility event, policy event, or service behavior change
Message(s): Mobility and continuity trigger
Purpose: Recognize that the session must adapt without losing the running service.
State or context change: The active session becomes continuity-sensitive.
Note: This procedure is about preserving service, not about simply rebuilding a broken session from scratch.
The network chooses the continuity treatment
Sender -> receiver: AMF <-> SMF <-> PCF
Message(s): Continuity-aware session decision
Purpose: Determine how the session should behave after the event.
State or context change: The session is mapped to the continuity model that should keep the service usable.
Note: Documenting the intended continuity model is critical before reading the later trace outcomes.
The path and session state are updated
Sender -> receiver: SMF <-> UPF and access path
Message(s): PFCP and session update handling
Purpose: Preserve service while adapting the active path or policy treatment.
State or context change: The session evolves rather than being fully re-created.
Note: The main engineering question is whether continuity was preserved, not merely whether an update occurred.
The UE applies the continuity-related change
Sender -> receiver: Network -> UE
Message(s): Related session modification signaling
Purpose: Align UE behavior with the updated continuity treatment.
State or context change: The UE keeps the service alive through the session transition.
Note: Watch for application-visible interruption even when the signaling looks clean.
Traffic proves whether continuity really worked
Sender -> receiver: UE <-> service path
Message(s): Live application traffic across the continuity event
Purpose: Validate the operational success of the continuity handling.
State or context change: The session remains usable from the application viewpoint.
Note: This is the real result, and it matters more than neat control-plane signaling.
Important Messages in This Flow
| Message | Protocol | Direction | Purpose in this procedure | What to inspect briefly |
|---|---|---|---|---|
| Related session modification signaling | NAS | UE <-> Network | Carries the updated session behavior tied to continuity handling. | Use it to understand what the network expected the UE to do. |
| Mobility-related access signaling | NGAP / RAN | gNB <-> AMF | Shows why continuity handling was needed. | Helps connect radio movement to session behavior. |
| PFCP updates | PFCP | SMF <-> UPF | Adapt the data path to preserve service continuity. | Critical for proving path continuity beyond NAS. |
| Application continuity observation | User plane | UE <-> service | Reveals whether the service actually survived the event. | Best final validation. |
Important Parameters to Inspect
| Parameter | What it is | Where it appears | Why it matters | Common issues |
|---|---|---|---|---|
| Continuity model or intent | Expected service-continuity behavior for the session. | Decision phase | Provides the baseline for judging success. | Without it, you cannot judge whether the result is correct. |
| Affected PDU Session ID | Session being adapted. | All related control and user-plane traces | Prevents confusion when multiple sessions exist. | Mis-correlation is common in mobility-heavy traces. |
| Path change details | What changed in the user-plane anchor or forwarding behavior. | PFCP and mobility state | Critical for continuity troubleshooting. | Unclear path changes hide the true cause of interruption. |
| QoS and policy after change | Updated service treatment after continuity handling. | Post-change session state | Shows whether the service profile remained correct. | Wrong QoS can look like continuity failure. |
| Observed service interruption | Application-visible effect of the change. | Post-event validation | Separates true continuity success from theoretical continuity. | Small outages matter here. |
Success Criteria
- The correct active session is adapted for the continuity event.
- Path or policy updates match the intended continuity model.
- The UE remains aligned with the updated session behavior.
- Application traffic remains usable across the change.
Common Failures and Troubleshooting
| Symptom | Likely cause | Where to inspect | Relevant message(s) | Relevant interface(s) | Likely next step |
|---|---|---|---|---|---|
| Continuity handling chooses the wrong behavior | The session adapts in a way that does not match the service need. | Continuity intent versus actual applied state. | Control-plane updates | N11, policy | This is a design-correctness failure. |
| Control plane succeeds but the path breaks | The user-plane continuity was not preserved operationally. | PFCP updates and live traffic. | Post-change traffic | N3, N4 | Common when signaling looks cleaner than the transport reality. |
| Service becomes unstable after the change | Continuity was technically preserved but quality became poor. | QoS profile and application behavior. | Post-change traffic | NR-Uu, N3 | Continuity includes usable quality, not only packet survival. |
| Wrong session is adapted | The continuity logic touched the wrong active session. | PDU Session ID across all related traces. | All related signaling | N1, N11 | Always verify this first in multi-session environments. |
What to Check in Logs and Traces
- Write down the intended continuity model before analyzing the trace.
- Correlate all related signaling by the affected PDU Session ID.
- Inspect PFCP and path updates to see how continuity was actually implemented.
- Compare pre-event and post-event QoS to catch degraded but not fully broken continuity.
- Validate with real application traffic across the event, not only with control-plane completion.
Related Pages
Related sub-procedures
- 5G PDU Session Modification
- 5G Session Recovery after Mobility / Path Switch
- 5G N2 Handover
- 5G Inter-AMF Mobility
Related message reference pages
Related troubleshooting pages
Notes
Continuity is an end-user outcome. The session is only truly healthy if the service stayed usable across the change.
FAQ
What is SSC Mode Change / Session Continuity Handling?
It is the 5G session behavior used to preserve service continuity when mobility or policy requires the session to adapt.
Is it a brand-new session procedure?
Usually no. It is more often an adaptation of an existing active session.
What proves success?
The service remains usable across the event and the session profile still matches the intended continuity model.
What should I inspect first?
Start with the continuity intent, then the affected session ID, then the path changes and live traffic result.
Why can clean signaling still hide failure?
Because continuity is ultimately judged by user-plane service behavior, not just by control-plane completion.