RACS

UE Radio Capability Signalling optimization

Management →
Introduced in Rel-7 Also in: Services

RACS is a feature that optimizes signaling by having the network store UE radio capability information and request updates only when needed, reducing overhead and latency during connection establishment and mobility.

Category
Management
Introduced
Rel-7
Where
Core Network › 5G Core
Also touches
1 segments
Specifications
12 specs
RACS Description Purpose Related Classification Detected Changes Specifications

Description

UE Radio Capability Signalling optimization (RACS) is a network feature designed to minimize the signaling overhead associated with transmitting a User Equipment's (UE) radio capability information. A UE's radio capabilities are a comprehensive set of parameters detailing its supported features, bands, frequency ranges, and technical limits (e.g., maximum number of carriers, supported modulation schemes). Traditionally, this information, contained in the UE Radio Capability ID (UECapabilityInformation), is sent from the UE to the network during initial registration and potentially during each connection setup or inter-RAT mobility, leading to significant signaling load, especially for large-capability containers in advanced UEs.

RACS works by enabling the Core Network (specifically the Access and Mobility Management Function, AMF, in 5GC, or the MME in EPS) to store the UE's radio capability information after the first successful retrieval. The network assigns a UE Radio Capability ID to this stored information. Subsequently, instead of the UE transmitting the full capability set, the network can signal using this much shorter ID. The AMF/MME provides this ID to the Radio Access Network (RAN) node (gNB or eNB). If the RAN node does not have the corresponding capability data cached locally, it can request the full information from the core network using the ID.

The architecture involves coordination between the UE, RAN, and Core Network. Key signaling messages are modified to carry the UE Radio Capability ID. For example, in 5G, the AMF includes the `UE Radio Capability ID` in the `INITIAL CONTEXT SETUP REQUEST` or `UE RADIO CAPABILITY CHECK REQUEST` messages to the gNB. The gNB checks its local storage. If the data is missing or potentially outdated (e.g., after a software update), the gNB can request the AMF to provide the full `UE Radio Capability Information` via a retrieval procedure. The network also manages the lifecycle of this stored data, including mechanisms to detect when capabilities might have changed (e.g., via indication from the UE or a timer-based refresh).

This optimization significantly reduces the size of signaling messages on the radio interface (Uu) and the NG/E1 interfaces. It is particularly beneficial for latency-sensitive procedures like connection resumption from RRC_INACTIVE state and for UEs with extensive capability lists, such as those supporting many NR and LTE bands, carrier aggregation combinations, and features like dual connectivity. By minimizing the amount of data transferred, RACS improves connection setup times, reduces UE battery consumption for signaling, and decreases the processing load on network nodes.

Purpose & Motivation

RACS was introduced to address the growing signaling overhead problem caused by increasingly complex UE radio capabilities. As 3GPP standards evolved through LTE-Advanced and into 5G, the number of supported frequency bands, carrier aggregation combinations, and optional features exploded. Transmitting the full, verbose `UECapabilityInformation` message during every relevant procedure became a significant source of latency and consumed valuable radio resources.

The primary problem RACS solves is the inefficient repetition of large, static data sets. A UE's core radio capabilities change infrequently, typically only after a software update or a major hardware change. Transmitting this multi-kilobyte block repeatedly was wasteful. Prior to RACS, the network had no standardized, efficient way to avoid this repetition, leading to longer call setup times and increased signaling congestion, especially in dense networks.

Its creation was motivated by the need to optimize network performance for massive IoT deployments and enhanced mobile broadband scenarios where fast connection establishment is critical. By shifting to an ID-based model, RACS aligns with general network optimization principles of caching and indirection. It also future-proofs the system for even more complex capability definitions in beyond-5G systems, ensuring that signaling scales efficiently regardless of how detailed UE capabilities become.

Classification

Part ofNGAP
Related approachesAMF

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (35 CRs across 4 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-16 29 changes

In Release 16, the RACS function was newly introduced to optimize UE radio capability signalling, which includes the establishment of a UE Radio Capability ID and the introduction of UCMF (UE Radio Capability Management Function) services. The release specified procedures for UE support signalling, storage of RACS parameters in non-volatile memory, and added a specific RACS capability bit in the UE network capability. Furthermore, it defined handling for NB-IoT across both EPS and 5GS, along with a network-based solution for RACS ID synchronization and support for interworking between EPS and 5GS.

  • EPS architecture supporting RACS TS 23.401CR3510
  • Introduction of RACS: UCMF services TS 23.501CR1037
  • Adding general description of RACS TS 24.301CR3241
  • Signalling of UE support for RACS and of UE radio capability ID TS 24.301CR3242
  • Adding general description of RACS TS 24.501CR1355
  • Signalling of UE support for RACS and of UE radio capability ID TS 24.501CR1356

+ 23 more changes

Rel-17 3 changes

In Release 17, the RACS function was enhanced to ensure its support could be properly detected at the target node during N2, S1, and X2-based handover procedures. Furthermore, specifications were updated to resolve a procedural collision between the Tracking Area Update (TAU) for RACS and the Extended Service Request (ESR) procedure used for Circuit Switched FallBack (CSFB).

  • Detection of RACS support at target during N2/S1 handover [RACS_S1_NG] TS 36.413CR1811
  • Detection of RACS support at target during S1 and X2 handover TS 23.401CR3701
  • Collision of TAU procedure for RACS and ESR procedure for CSFB TS 24.301CR3530
Rel-18 2 changes

In Release 18, the RACS function was enhanced with specific handling procedures for the Tracking Area Update (TAU) and the Registration procedures. These updates defined how the optimization is applied during these critical mobility and registration events. The changes ensure RACS operates efficiently across the complete lifecycle of a UE's network attachment and mobility.

  • TAU procedure handling for RACS TS 24.301CR3909
  • Registration procedure handling for RACS TS 24.501CR5488
Rel-19 1 change

In Release 19, the RACS function was enhanced to introduce a new "PEI Request" procedure. This addition provides a mechanism for the network to specifically request a UE's Permanent Equipment Identifier in the context of radio capability signalling optimization. The update defines the format and usage parameters for this new request within the RACS framework.

Explore further

Broader topics and technologies where RACS plays a role.

Defining Specifications

3GPP specifications that define or reference RACS, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 23.003 vj50 Numbering, addressing and identification in 3GPP Rel-19
TS 23.401 vj50 Evolved Packet System (EPS) Stage 2 Description Rel-19
TS 23.417 v1700 IMS Core Component for NGN Architecture Rel-7
TS 23.501 vk00 5G System Architecture Stage 2 Rel-20
TS 23.517 v1800 IMS Core Component for NGN Architecture Rel-8
TS 24.301 vj60 NAS protocol for Evolved Packet System Rel-19
TS 24.501 vj50 5G NAS Protocols Specification Rel-19
TS 24.523 vj00 NGCN-NGN Interconnection Scenarios Rel-19
TS 24.524 vj00 Hosted Enterprise Services Architecture Rel-19
TS 29.421 v810 IMS Interworking with External IP Networks Rel-8
TS 29.675 vj10 UE Radio Capability Provisioning Service Rel-19
TS 36.413 vj10 S1 Application Protocol (S1AP) Rel-19
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.