No Speech-call capability

Description

No Speech-call capability (NS) is a User Equipment (UE) capability parameter defined across numerous 3GPP specifications. It is a boolean indicator that signals to the network whether the UE is capable of establishing and maintaining a traditional circuit-switched (CS) voice call. When a UE registers with the network and indicates NS capability, it is explicitly informing the core network—specifically the Mobility Management Entity (MME) in EPS or the Access and Mobility Management Function (AMF) in 5GS—that it cannot be paged for or serviced by CS-domain services like Voice over CS (VoCS).

Architecturally, the NS flag influences the network's mobility and session management procedures. In a 4G EPS network, which is packet-switched only, the presence of CS fallback (CSFB) for voice services is common. A UE without NS capability would typically use CSFB to revert to a 2G/3G network for a voice call. However, a UE declaring NS capability is treated as a 'CS voice not supported' device. The network will not attempt CSFB procedures for it. Instead, voice service, if required, must be delivered via packet-switched methods like Voice over LTE (VoLTE) using IMS or, in 5G, Voice over NR (VoNR). For data-only or IoT devices, NS is a permanent characteristic, and the network will only provide packet-switched data services.

The role of NS in the network is critical for efficient resource management and service delivery. It prevents the network from wasting signaling resources attempting to deliver CS services to a device that cannot use them. It also guides policy decisions; for instance, a UE with NS set might be barred from attaching to certain radio access technologies (RATs) that are primarily CS-oriented or might be steered towards network slices optimized for massive IoT (mIoT) where voice is irrelevant. The capability is exchanged during initial registration (ATTACH or REGISTRATION REQUEST) and is stored in the subscriber's context within the core network, influencing subsequent mobility and session management commands.

Purpose & Motivation

The NS capability exists to explicitly communicate a device's service limitations to the network, solving the problem of inefficient and failed service delivery attempts. In early mobile networks, all UEs were assumed to support voice calls. With the advent of data-centric devices like dongles, tablets, and later a vast array of IoT sensors, this assumption became invalid. Without an explicit indicator, the network would wastefully attempt to page these devices for voice calls or trigger complex CS fallback procedures, leading to signaling congestion and failed service attempts.

Historically, the capability was formalized as networks evolved towards all-IP, packet-switched architectures like LTE and 5G NR. It addresses the limitations of the previous implicit model by providing a clear, binary signal. This allows for optimized network behavior: data-only devices can be managed more efficiently, and the network can seamlessly offer alternative voice solutions (like VoLTE) to devices that support them while avoiding legacy CS paths for those that do not. Its creation was motivated by the need for scalable, efficient machine-type communication and the clear separation between voice-centric and data-centric device profiles in modern telecommunications.

Key Features

• Binary UE capability indicator exchanged during network registration
• Prevents network from initiating circuit-switched (CS) service procedures for the UE
• Influences mobility management decisions (e.g., no CSFB triggering)
• Essential for data-only and IoT device classification and handling
• Stored in core network subscriber context (MME/AMF) for session duration
• Enables network optimization by avoiding unnecessary signaling for unsupported services

Evolution Across Releases

Defining Specifications