Fallback

Description

Fallback is a fundamental concept in 3GPP service provisioning that governs how a network or user equipment (UE) selects between multiple proposed services when not all can be supported simultaneously. The term was introduced in Release 2 (Rel-2) and has been maintained across all subsequent releases up to Rel-19. The core definition states: 'when two services (multimedia and speech) are proposed but only one of them is available or wanted, only the service available (preferred or less preferred) is selected, and the other one is discarded.' This mechanism is particularly relevant in scenarios where a UE requests both a multimedia service (e.g., video telephony) and a speech service (e.g., voice call), but the network can only support one due to resource constraints, capability limitations, or user preference.

The fallback procedure operates during session establishment or modification. When a UE initiates a service request that includes multiple media components, the network evaluates the availability of each component based on factors such as radio access capabilities, core network support, and policy constraints. If one component cannot be supported, the network may either reject the entire request or accept only the available component, discarding the other. The decision to fallback can be triggered by the UE, the network, or both, depending on the specific service and configuration. For example, in the case of a multimedia telephony service (MMTel) that includes both voice and video, if the video component is not available due to insufficient bandwidth, the network may fallback to voice-only service, ensuring that the user can still communicate.

The fallback mechanism is closely tied to the concept of service preferences. The definition mentions 'preferred or less preferred' service, indicating that the selection may consider the user's or operator's preference order. If the preferred service is unavailable, the less preferred service may be selected as a fallback. This is particularly important in emergency situations where voice service must be prioritized over multimedia. The fallback decision is typically made during the negotiation phase of session setup, using protocols such as SIP (Session Initiation Protocol) for IMS-based services or NAS (Non-Access Stratum) for EPS/5GS services.

In terms of architecture, fallback involves interactions between the UE, the radio access network (RAN), and the core network (CN). The UE indicates its service requirements in the session request, and the network responds with the granted services. If fallback occurs, the network may send a modified session description that includes only the available service. The UE must then adapt its application to the fallback service. This process is standardized in specifications such as 3GPP TS 23.172 (Technical realization of Circuit Switched (CS) multimedia service; UDI/RDI fallback and service modification) and TS 33.204 (3G Security; Network Domain Security (NDS); Transaction Capabilities Application Part (TCAP) user security). These specs define the procedures and message flows for fallback in circuit-switched and packet-switched domains.

Fallback is essential for ensuring service continuity and user experience. Without fallback, a UE requesting multiple services might face complete rejection if one service is unavailable, leading to a failed session. Fallback allows the network to gracefully degrade the service to what is supported, maintaining basic connectivity. It also enables efficient use of network resources by avoiding over-provisioning. As networks evolve towards 5G and beyond, fallback mechanisms continue to be relevant, especially in interworking scenarios between different radio access technologies (e.g., fallback from 5G NR to LTE for voice services, known as EPS fallback). The concept has been extended to various domains, including voice fallback, where a UE falls back from 5G to 4G for voice calls when 5G voice (VoNR) is not available.

Purpose & Motivation

The fallback concept was introduced to address the challenge of service negotiation when multiple services are requested but not all can be supported. In early mobile networks (2G/3G), users might request both voice and data services simultaneously, but network capabilities or resource limitations could prevent simultaneous support. Without a fallback mechanism, the entire service request would fail, leading to poor user experience. Fallback allows the network to select the most appropriate available service, ensuring that the user receives at least a basic level of service.

Historically, fallback became particularly important with the advent of multimedia services in 3G networks, where video telephony and other rich services were introduced. The network needed a way to handle cases where a UE requested multimedia but the radio access network could only support voice. The fallback mechanism provided a standardized way to downgrade the service to voice-only, which was defined in 3GPP TS 23.172. This ensured interoperability between different vendors and networks.

In modern networks, fallback has evolved to include scenarios like EPS fallback for voice over 5G, where a UE falls back to LTE for voice calls when 5G NR does not support voice natively. This demonstrates the enduring relevance of the fallback concept in ensuring service continuity across generations. The fallback mechanism solves the problem of service availability mismatch and provides a flexible framework for service adaptation.