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
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific 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.
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
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).
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.
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.
- PEI Request for RACS TS 24.501CR7106
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.
| Specification | Title | Release |
|---|---|---|
| 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 |