Glossary term · Management

RACS

UE Radio Capability Signalling optimization

Management →

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.

Introduced
Rel-7
Specifications
12 specs
Category
Management
Introduced
Rel-7
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

Detected Changes Across Releases

from 3GPP Change Requests

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

Rel-16 19 changes
  • 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
  • Handling of NB-IOT radio capabilities and RACS in EPS TS 23.401CR3526
  • Handling of NB-IOT radio capabilities and RACS in 5GS TS 23.501CR1517

+ 13 more changes

Rel-17 3 changes
  • 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 1 change
  • TAU procedure handling for RACS TS 24.301CR3909

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 vk00 Numbering, Addressing and Identification Rel-20
TS 23.401 vk00 Evolved 3GPP Packet Switched Domain - EPS Rel-20
TS 23.417 v1700 IMS Core Component for NGN Architecture Rel-7
TS 23.501 vk20 5G System Architecture Stage 2 Rel-20
TS 23.517 v1800 IMS Core Component for NGN Architecture Rel-8
TS 24.301 vk00 3GPP TS 24301 vk00: NAS Protocols for EPS Rel-20
TS 24.501 vk00 5G System (5GS) Non-Access Stratum (NAS) Protocol Rel-20
TS 24.523 vj00 NGCN-NGN Interconnection Scenarios Rel-19
TS 24.524 vj00 Hosted Enterprise Services Architecture Rel-19
TS 29.421 v1810 IMS Interworking with External IP Networks Rel-8
TS 29.675 vj20 Nucmf Service Based Interface Protocol Rel-19
TS 36.413 vj20 S1 Application Protocol (S1AP) for E-UTRAN Rel-19