Menu
Latest
12 meetings · Prague, Jeju · 12–16 Oct
Reports
RAN1#126-bis · SA2#177

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
Where
Core Network › 5G Core
Specifications
12 specs
Also in
Services
RACS Description Purpose What changed Neighbours 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.

What changed in its specifications

The latest release-to-release comparison of specifications that define RACS. Each summary describes the whole specification, not only this term.

TS 23.003Rel-18 → Rel-19

Rel-19 adds clauses 31.1 to 31.7 to TS 23.003 defining identifier and information structures for Ambient IoT devices and areas, plus new normative references. It also adds SNPN support to ProSe identifiers, including an optional NID part in the PLMN ID and a revised temporary identity length.

Full comparison in TS 23.003 →
TS 23.401Rel-18 → Rel-19

Rel-19 adds Disaster Roaming in EPS, which covers disaster-roaming procedures and attach, tracking area update and mobility signalling. It also adds Time Reference Information Distribution Indication to subscription data and the MME-to-eNB path, along with Store and Forward Satellite operation text.

Full comparison in TS 23.401 →

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
  • 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
  • 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
  • TAU procedure handling for RACS TS 24.301CR3909
  • Registration procedure handling for RACS TS 24.501CR5488
Rel-19 1 change

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 vk10 Numbering, Addressing and Identification Rel-20 read
TS 23.401 vk10 Evolved Packet System Architecture Rel-20 read
TS 23.417 v700 IMS Core Component for NGN Architecture Rel-7 read
TS 23.501 vk30 5G System Architecture Rel-20 read
TS 23.517 v800 IMS Core Architecture for TISPAN NGN Rel-8 read
TS 24.301 vk10 EPS NAS Mobility and Session Management Rel-20 read
TS 24.501 vk10 5GS NAS Protocol Specification Rel-20 read
TS 24.523 vj00 NGCN-NGN Interconnection Scenarios Rel-19 read
TS 24.524 vj00 Hosted Enterprise Services Architecture Rel-19 read
TS 29.421 v810 IMS Interworking with External IP Networks Rel-8 read
TS 29.675 vj20 Nucmf Service Based Interface Protocol Rel-19 read
TS 36.413 vj20 S1 Application Protocol (S1AP) for E-UTRAN Rel-19 read