EPS fallback is the way a 5G SA network handles an IMS voice call when it does not want to carry the voice over NR. The UE starts the call on 5G. At the moment the network tries to set up the voice QoS flow, the gNB refuses it and moves the UE to LTE. The call then completes over EPS, as a normal VoLTE call.

So from the user's point of view, it is just a voice call on a 5G phone. But in the log, a single call setup crosses two systems. If you see a 5G call that suddenly ends up on LTE, this is usually the first mechanism to check.

• Why we need EPS Fallback ?
• What has to be in place before the call ?
• Signaling Sequence
  • Handover or Redirection
  • After the Call
• How EPS Fallback Shows Up in a Log
• EPS Fallback, RAT Fallback and VoNR
• Reference

Why we need EPS Fallback ?

Why would a 5G network send a voice call back to LTE ? The reason is that voice is the service operators trust least on a new radio. VoNR needs good NR coverage everywhere, tuned voice features on the gNB, and a lot of testing. VoLTE already has all of this. So in the early phase of 5G SA, many operators keep the data on 5G and run the voice on LTE.

But the UE is registered on 5GC, not on EPC. It has to register in IMS through a 5G PDU session, and it has to see a 5G network that supports IMS voice. Otherwise it would not even try to make an IMS call while camping on NR. EPS fallback solves this conflict. The network tells the UE that IMS voice is supported in 5GS, lets the IMS call setup start on 5G, and then moves the UE to EPS only when the voice bearer is actually needed.

This timing is the key point. The fallback does not happen when the user presses the call button. It happens when the network tries to set up the QoS flow for voice, which is in the middle of the SIP call setup. Until then, the UE is a normal 5G UE.

• Data stays on 5G, voice goes to LTE : EPS fallback lets an operator launch 5G SA before VoNR is ready.
• The UE still sees IMS voice as supported in 5GS : otherwise it would not start the IMS call on NR.
• The trigger is the voice QoS flow : the gNB moves the UE when the network asks for the voice flow, not earlier.

What has to be in place before the call ?

EPS fallback is not something the gNB decides from nothing. Several things have to be set up during registration and context setup, long before the call. If one of them is missing, the call takes a different path, or fails. 23.502 clause 4.13.6.1 lists them at the start of the procedure.

The gNB itself also has to be configured to support EPS fallback. When the voice flow request arrives, the gNB weighs UE capabilities, the AMF indication, the N26 configuration and the radio conditions. If it decides not to fall back, the procedure stops, and the voice flow can be set up on NR as VoNR.

• The decision belongs to the gNB : the core only asks for a voice QoS flow, and the gNB chooses to refuse it and move the UE.
• N26 shapes the rest of the procedure : with N26 the context moves between AMF and MME, without it the UE attaches again in EPS.
• Redirection can be forbidden by the AMF : the Redirection for Voice EPS Fallback IE carries possible or not-possible.

Signaling Sequence

Now let's put the steps together. The following diagram follows 23.502 Figure 4.13.6.1-1 with the actual message names you would look for on each interface. Read it from top to bottom, and pay attention to the moment where the gNB answers the voice QoS flow request with a rejection instead of a setup.

Figure 1. EPS fallback for IMS voice, drawn after 23.502 Figure 4.13.6.1-1. The gNB rejects the voice QoS flow with a fallback cause, moves the UE to E-UTRA, and the SMF+PGW-C sets up the voice bearer again in EPS.

• Step 1 : the UE is on NR with its PDU sessions, and an MO or MT IMS voice call setup starts.
• Step 2 : the network-initiated PDU session modification for the voice QoS flow reaches the gNB as an N2 PDU Session Request.
• Step 3 : the gNB decides to fall back to EPS. It may first ask the UE to measure E-UTRA.
• Step 4 : the gNB rejects the voice flow toward the SMF via the AMF, with an indication that mobility due to fallback is ongoing. The SMF keeps the PCC rules for the voice flow.
• Step 5 : the gNB starts a handover to EPS, or releases the UE with redirection to E-UTRA.
• Step 6 : the UE arrives in EPS with a TAU, or with an Attach when there is no N26.
• Step 7 : the SMF+PGW-C sets up the dedicated bearer for voice again, mapping the 5G QoS to EPC QoS.

One thing you would notice is that the SMF does not forget the voice request in step 4. It keeps the PCC rules. This is why the voice bearer appears in EPS in step 7 without the IMS side having to start over. From the SIP point of view, the call setup just takes longer than usual.

Handover or Redirection

Step 5 and step 6 have two variants each, and the combination decides how long the fallback takes. The gNB picks the RRC method, and the presence of N26 picks what the UE does after arriving in LTE.

So which one is faster ? A handover keeps the UE connected the whole time, and the PDU session context moves over N26. A redirection releases the UE, so it has to find an LTE cell and connect again. Without N26 the UE even has to attach again. This is why the Redirection for Voice EPS Fallback IE exists. It lets the AMF tell the gNB whether redirection is acceptable for this UE at all.

After the Call

Once the UE is on LTE, 23.502 makes one firm rule for the duration of the call. The E-UTRAN is configured not to trigger any handover to 5GS while the voice call is ongoing. Otherwise the call would bounce between the two systems.

What happens after the call ends is not part of this clause. My understanding is that the return to 5G is left to normal mobility and network configuration. Many networks release the UE with a redirection to NR right after the call, which is often called fast return. If the network does nothing special, the UE goes back to NR through normal cell reselection in idle mode, which can take longer.

• Handover is the fastest path : the UE stays connected, and the context moves over N26.
• Redirection without N26 is the slowest : the UE has to attach again in EPS before the voice bearer can come up.
• No handover back to 5GS during the call : the return to NR happens only after the call.

How EPS Fallback Shows Up in a Log

Then how can you tell from a log that a call used EPS fallback rather than something else ? There are three markers, one per layer. Each of them says directly that the event was a voice fallback, so you do not have to guess from the RAT change alone.

The first marker is in NGAP. The gNB reports the failed voice QoS flow in the PDU SESSION RESOURCE MODIFY RESPONSE, or the SETUP RESPONSE, with the cause value IMS voice EPS fallback or RAT fallback triggered. 38.413 describes this cause as the setup of the QoS flow failing due to EPS fallback or RAT fallback for IMS voice, using handover or redirection.

The second marker is in RRC. From Release 16, both the MobilityFromNRCommand and the RRCRelease can carry voiceFallbackIndication. In the RRCRelease, it tells the UE that the release is for EPS fallback for IMS voice. In the MobilityFromNRCommand, it marks the handover as triggered by EPS fallback.

Following is based on 38.331 v19.4.0 (Release 19)

RRCRelease-v1610-IEs ::=            SEQUENCE {
    voiceFallbackIndication-r16        ENUMERATED {true}                             OPTIONAL, -- Need N
    measIdleConfig-r16                 SetupRelease {MeasIdleConfigDedicated-r16}    OPTIONAL, -- Need M
    nonCriticalExtension               RRCRelease-v1650-IEs                          OPTIONAL
}

MobilityFromNRCommand-v1610-IEs ::=     SEQUENCE {
    voiceFallbackIndication-r16             ENUMERATED {true}                                       OPTIONAL,   -- Need N
    nonCriticalExtension                    SEQUENCE {}                                             OPTIONAL
}

The third marker is the UE capability. The field voiceFallbackIndicationEPS-r16 in IMS-ParametersCommon says that the UE supports voiceFallbackIndication in both messages. 38.306 adds that a UE including this field shall support IMS voice over NR and IMS voice over E-UTRA via EPC. So the gNB includes the indication only for a UE that can understand it.

• NGAP cause : IMS voice EPS fallback or RAT fallback triggered, on the failed voice QoS flow.
• RRC indication : voiceFallbackIndication-r16 in the MobilityFromNRCommand or the RRCRelease.
• UE capability : voiceFallbackIndicationEPS-r16 in IMS-ParametersCommon.
• The SIP flow keeps going : the INVITE transaction continues across the RAT change, so the SIP log alone shows only a slow call setup.

EPS Fallback, RAT Fallback and VoNR

EPS fallback is one of three ways a 5G SA UE can make an IMS voice call. They are easy to mix up, because all three start the same way, with an IMS call setup on NR. The difference is what the gNB does with the voice QoS flow request.

This is also why the NGAP cause has a combined name, EPS fallback or RAT fallback. The core sees the same rejection in both cases. Only the target of the mobility is different. For emergency calls, the network may also use either fallback when it is configured to.

• All three start on NR : the difference appears only when the voice QoS flow is requested.
• RAT fallback stays in 5GC : the UE moves to E-UTRA but keeps 5GC as its core network.
• EPS fallback changes the core network : the voice call completes as a normal VoLTE call over EPC.

Reference

The procedure on this page was checked against 23.502, and the RAN-side signals against 38.413, 38.331 and 38.306.

• 23.502 : Procedures for the 5G System. EPS fallback for IMS voice in clause 4.13.6.1 and Inter RAT fallback in 5GC for IMS voice in clause 4.13.6.2. The version read was v20.3.0 (Release 20).
• 38.413 : NG Application Protocol. The QoS flow failure cause IMS voice EPS fallback or RAT fallback triggered, and the Redirection for Voice EPS Fallback IE in clause 9.3.1.116. The version read was v19.4.0 (Release 19).
• 38.331 : Radio Resource Control protocol specification. Source for voiceFallbackIndication in RRCRelease and MobilityFromNRCommand. The version read was v19.4.0 (Release 19).
• 38.306 : UE radio access capabilities. Source for the meaning of voiceFallbackIndicationEPS-r16. The version read was v19.4.0 (Release 19).
• 24.501 : the IMS-VoPS-3GPP bit of the 5GS network feature support IE in clause 9.11.3.5. The version read was v20.1.0 (Release 20).
• 5G Voice Standardization Completion - ZTE