Home / Call Flows / 5G / VoLTE Fallback / Voice Continuity Comparison

5G VoLTE Fallback / Voice Continuity Comparison

call-flow 5G | VoNR | VoLTE | EPS Fallback | SRVCC

VoLTE Fallback / Voice Continuity Comparison is a decision page for mixed 5G and LTE voice environments.

Its purpose is simple: help you identify whether the network really used native VoNR, EPS fallback, or another voice continuity branch before you start debugging.

Introduction

In many live networks, the user symptom is the same but the serving voice branch is different. A missed call, slow setup, or broken audio can happen on native VoNR, on fallback to VoLTE, or during continuity movement between them.

This page gives you a structured way to classify the branch first, then choose the right family of call-flow pages and troubleshooting paths.

What Is VoLTE Fallback / Voice Continuity Comparison in Simple Terms?

What starts the procedure: A voice event appears while the subscriber has 5G coverage in a mixed voice environment.
What the UE and network want to achieve: Select the right voice branch and maintain usable voice continuity.
What success looks like: The active branch is understood clearly and the correct troubleshooting path is chosen.
What failure means: Different voice models are mixed together and the diagnosis goes in the wrong direction.

Why this procedure matters

This comparison saves time. If you misclassify the branch, every later trace conclusion becomes less trustworthy.

Quick Fact Sheet

Procedure name	5G VoLTE Fallback / Voice Continuity Comparison
Domain	Comparison of native VoNR, EPS fallback, and LTE voice continuity branches
Main trigger	Engineers need to classify which voice path the network is actually using in a mixed 5G/LTE environment
Start state	A subscriber is on 5G coverage and a voice-service event appears
End state	The active voice path is understood as native VoNR, EPS fallback, VoLTE continuity, or SRVCC-style continuity
Main nodes	UE, gNB, eNB, AMF, EPC, IMS core
Main protocols	VoNR signaling, EPS fallback mobility, VoLTE service continuity, SRVCC comparison points
Main success outcome	Engineers identify the correct voice branch and troubleshoot the right layer
Main failure outcome	Different voice branches are mixed together, leading to wrong diagnosis and wrong design decisions
Most important messages	INVITE, paging, service request, inter-RAT move, BYE, SRVCC continuity signals
Main specs	TS 23.502, TS 23.401, TS 24.229, TS 23.216

VoLTE fallback and voice continuity comparison

Preconditions

The deployment can use more than one voice path across 5G and LTE.
The UE and network capabilities are known or can be inferred from the trace.
There is enough trace context to determine whether the call stayed on NR or moved to LTE.
IMS call-control behavior can be compared with the serving access branch.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	May stay on VoNR, move to LTE by EPS fallback, or continue through other voice-continuity mechanisms depending on capability and coverage.
gNB and AMF	Control the native NR branch and participate in fallback decisions.
eNB and EPC	Take over when the service path moves to LTE for VoLTE or continuity handling.
IMS core	Provides a common SIP service layer across different radio and core continuity branches.

Interfaces used

Interface	Path	Role
NR-Uu and N2	UE <-> gNB / AMF	Show whether the call starts and stays in the native 5G branch.
LTE Uu and EPC path	UE <-> eNB / EPC	Show when the voice path is really being served through LTE continuity.
IMS SIP path	UE <-> IMS	Common call-control layer used across voice branches.
Inter-RAT continuity path	5G side <-> LTE side	Explains where EPS fallback or continuity handling changes the serving access.

End-to-End Call Flow

Voice event on 5G
       |
       +--> stays on NR: native VoNR
       |
       +--> moves to LTE before or for call setup: EPS fallback / VoLTE continuity
       |
       +--> changes during active call: continuity / SRVCC-style comparison

Major Phases

Phase	What happens
1. Voice event appears on 5G coverage	A call, paging event, or service request begins while the UE has 5G access.
2. Branch selection	The network decides whether to stay native on VoNR or use LTE continuity.
3. Serving-path confirmation	The trace reveals whether voice really stayed on 5G or moved to LTE.
4. Voice continuity outcome	The active branch is validated by call setup, media continuity, and later mobility behavior.

Step-by-Step Breakdown

Start by classifying the voice event and network capability

Sender -> receiver: UE capability, network policy, coverage context

Message(s): Voice trigger and support context

Purpose: Understand whether native VoNR is even expected in this scenario.

State or context change: The analysis moves from generic user complaint into branch-selection logic.

Note: Many wrong diagnoses begin because engineers assume VoNR when the network actually intended fallback all along.

Check whether the voice path stayed on 5G or moved to LTE

Sender -> receiver: 5G access path versus LTE continuity path

Message(s): Paging, service request, inter-RAT move, LTE landing

Purpose: Separate native 5G voice from continuity branches such as EPS fallback.

State or context change: The real serving voice path becomes visible.

Note: This is the core split: native VoNR problems and EPS fallback problems rarely have the same root cause.

Compare the voice-service layer on top of the selected branch

Sender -> receiver: IMS SIP and media behavior

Message(s): INVITE, progress responses, 200 OK, ACK, media continuity

Purpose: Confirm whether the selected branch actually delivered working voice service.

State or context change: The call is judged by service continuity rather than by radio-state assumptions alone.

Note: IMS can look similar across branches, so always read SIP together with the serving access path.

Use continuity behavior to choose the right troubleshooting family

Sender -> receiver: End-to-end comparison outcome

Message(s): Observed branch: VoNR, EPS fallback, VoLTE continuity, or SRVCC-like handoff

Purpose: Put the case in the right operational bucket before deeper debugging.

State or context change: The comparison becomes actionable for design, monitoring, and troubleshooting.

Note: This page is a decision aid. Its main job is to prevent engineers from chasing the wrong family of failures.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
Paging and Service Request	RRC / NAS	Network <-> UE	Help reveal whether the service stayed on NR and restored normally.	Useful in MT or idle-return cases before assuming fallback.
Inter-RAT move indicators	Mobility	5G side -> LTE side	Show that the service branch moved away from native VoNR.	This is the clearest split between VoNR and EPS fallback style handling.
INVITE and 200 OK	SIP	UE <-> IMS	Show the call-control outcome on top of whichever serving path was chosen.	Useful, but only after the serving branch is identified.
Continuity or handover indicators	Cross-layer	Between access and service states	Explain whether ongoing voice continuity relied on LTE or circuit-switched fallback style logic.	Important for comparing EPS fallback with SRVCC-style continuity expectations.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Serving RAT during call setup	Whether the voice branch stayed on NR or moved to LTE.	Setup and continuity stages	This is the first decision point in any comparison.	Wrong RAT assumptions break the whole analysis.
Voice support capability	Whether native VoNR was possible at all.	Before branch selection	Explains whether fallback is expected behavior or failure behavior.	Capability mismatch is a common source of confusion.
Continuity trigger	Why the service moved or stayed put.	Branch-selection stage	Distinguishes policy-driven, coverage-driven, or capability-driven behavior.	If the trigger is misunderstood, root cause will be too.
IMS behavior on the chosen branch	How call-control proceeded after branch selection.	SIP setup stage	Needed because IMS signaling alone cannot tell you the branch.
Post-call mobility behavior	Whether later movement changed the active continuity model.	During or after the call	Useful for distinguishing setup fallback from in-call continuity such as SRVCC-style cases.	A single static snapshot may miss the true continuity mechanism.

Success Criteria

The active voice branch is identified correctly.
The trace is separated into access-branch choice and IMS service outcome.
Fallback and continuity mechanisms are not mixed together.
The right detailed procedure pages can be used next.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Native VoNR is assumed when the call actually used fallback	The serving branch was misidentified.	Serving RAT, branch indicators, and continuity trigger.	Early trace context	Cross-layer analysis	This is the most common analytical failure this page tries to prevent.
EPS fallback is blamed for a pure IMS call-control issue	The serving-path decision was correct but the real failure was later in IMS.	Branch confirmation first, then SIP progression.	Branch indicators, INVITE	IMS versus mobility split	Always classify the branch before blaming it.
SRVCC and EPS fallback are mixed together	Setup fallback and in-call continuity were treated as the same thing.	Continuity timing and serving-path transitions.	Continuity indicators	Mobility continuity	These are related but operationally different mechanisms.
Voice continuity quality is evaluated without knowing the branch	Media symptoms were analyzed with no serving-context baseline.	Serving RAT and handover history.	Media + mobility timing	User plane and mobility	The same symptom can mean different things on different branches.

What to Check in Logs and Traces

Start with the serving RAT during call setup.
Look for any inter-RAT move before blaming SIP.
Use IMS signaling only after the voice branch is known.
If the call moved during the active session, compare it with SRVCC-style continuity rather than setup fallback alone.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

FAQ

What is this comparison page for?

It helps engineers decide whether a voice case used native VoNR, EPS fallback, LTE continuity, or another continuity mechanism before troubleshooting.

Why compare VoNR and VoLTE continuity together?

Because mixed 5G/LTE deployments often use multiple voice paths, and wrong branch classification wastes time quickly.

What should I inspect first?

Start with the serving RAT and whether the call moved from NR to LTE at any point.

Where does SRVCC fit here?

SRVCC is best treated as a related continuity model to compare against EPS fallback and VoLTE continuity, especially for in-call movement.

What proves the comparison is correct?

A trace that shows the serving branch clearly and aligns that branch with the later IMS and media behavior.