Description
The Random Access Channel (RACH) is a fundamental uplink transport channel in 3GPP radio access networks (UTRAN, E-UTRAN, and NG-RAN). It is a contention-based channel, meaning multiple User Equipments (UEs) may attempt to access it simultaneously, potentially leading to collisions that require resolution procedures. The primary purpose of the RACH is to allow a UE, which is not yet time-synchronized with the network's uplink timing, to request an initial connection, perform handover, re-establish a connection after radio link failure, or request uplink resources for scheduling requests (SR) when no dedicated SR resources are configured.
The RACH procedure, often called Random Access (RA), is a multi-step process. In LTE and NR, it exists in two primary forms: Contention-Based Random Access (CBRA) and Contention-Free Random Access (CFRA). In CBRA, the UE randomly selects a preamble (a specific signal sequence) from a set broadcast by the gNB/eNB and transmits it on the physical random access channel (PRACH). The network, upon detecting the preamble, responds with a Random Access Response (RAR) message containing a temporary identifier (TC-RNTI), timing advance command for synchronization, and an initial uplink grant for the UE to send a scheduled message (like an RRC Connection Request). If multiple UEs select the same preamble simultaneously, a collision occurs, which is resolved in subsequent message exchanges. CFRA is used in scenarios like handover, where the network pre-assigns a dedicated preamble to the UE to avoid contention.
Architecturally, the RACH is mapped to the Physical Random Access Channel (PRACH). The PRACH configuration, including available preamble formats, time/frequency resources (RACH occasions), and root sequences, is broadcast in system information (SIB1/SIB2 in LTE, SIB1 in NR). The UE's physical layer handles the preamble transmission, while higher layers (MAC and RRC) manage the procedure's logic, backoff, and failure handling. The design of preamble formats (e.g., with different lengths) supports various cell sizes and deployment scenarios, from small cells to large rural cells, by accommodating different round-trip time delays.
In the overall network operation, RACH is the critical first step for a UE transitioning from idle (RRC_IDLE) or inactive (RRC_INACTIVE) state to connected (RRC_CONNECTED) state. It is also vital for uplink synchronization maintenance, as the timing advance provided in the RAR ensures orthogonal uplink transmissions from multiple UEs, preventing interference. In 5G NR, enhancements like 2-step RACH were introduced, where the UE combines the preamble (MsgA) and the scheduled message (like Msg3) into a single transmission, reducing latency for access, which is crucial for ultra-reliable low-latency communication (URLLC) use cases.
Purpose & Motivation
The RACH was created to solve the fundamental problem of how an unsynchronized UE can initially contact a cellular network without prior coordination. In early mobile systems, without a mechanism for uplink synchronization, simultaneous transmissions from multiple UEs would cause severe interference, making network access unreliable. The RACH provides a structured, contention-managed method for this initial contact, enabling efficient sharing of the radio medium.
Its design addresses the challenge of random access in a shared medium (the air interface). By using short, detectable preamble sequences, the network can efficiently detect access attempts even with poor timing alignment. The contention resolution mechanism allows the network to handle collisions gracefully, which is inevitable in a system with many potential users. This is far more efficient than dedicated signaling channels for each potential UE, which would waste precious radio resources.
Over generations, the purpose has expanded beyond mere initial access. It now supports critical mobility functions like handover, where a UE needs to quickly synchronize to a new cell. It also serves uplink scheduling requests when a UE has data to send but no dedicated control channel. The evolution towards lower latency, especially in 5G, has driven enhancements like the 2-step RACH, directly addressing the need for faster connection setup in mission-critical and industrial IoT applications.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (44 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 15, the RACH procedure was enhanced with corrections and clarifications for power control in TDD, the use of PRACH resources for Early Data Transmission (EDT), and RACH configuration during handover. It also introduced specifications for carrier selection for random access and clarifications for RACH operations in Carrier Aggregation (CA) scenarios. Furthermore, the release addressed the monitoring of PDCCH for ordering PRACH on a Secondary Cell (SCell) and the handling of simultaneous transmission and reception of uplink and downlink channels.
- Clarification on CRC attachment for DL-SCH and PCH transport channels in NB-IoT TS 36.212CR0285
- Corrections to random access power control for TDD in 36.331 TS 36.331CR3580
- Correction on the use of PRACH resource pool for EDT TS 36.331CR3769
- Correction to simultaneous reception of DL Channels TS 38.202CR0006
- CR on inclusion of TC-RNTI for monitored RNTI for UL-SCH and inclusion of monitoring PDCCH ordering PRACH on SCell TS 38.202CR0007
- CR on simultaneous transmission of UL channels TS 38.202CR0008
+ 10 more changes
In Release 16, the primary new development for the RACH function was the introduction of a two-step random access procedure. This new capability provided an alternative to the traditional four-step RACH process, aiming to reduce latency. The change is explicitly noted in the provided Change Request titles as the "Introduction of two-step RACH."
- Introduction of two-step RACH TS 38.202CR0009
- Introduction of two-step RACH TS 38.212CR0031
- Introduction of 2-step RACH TS 38.300CR0197
- Mapping of Uplink Traffic to Backhaul RLC Channels TS 38.300CR0255
- DL Channel Combination associated with DCI format 2_6 monitoring TS 38.202CR0017
- Correction on Sidelink Broadcast channel TS 38.212CR0062
+ 3 more changes
In Release 17, the RACH (Random Access Channel) saw enhancements including the introduction of RACH partitioning and the optimization of RACH procedures for the EN-DC secondary cell. The release also provided clarifications on slice-based RACH configuration and on PDCCH ordered RACH for the SCell. Furthermore, new RACH triggers were introduced for timing advance (T_ADV) in NR E-CID positioning.
- Introduction of RACH triggers for T_ADV in NR E-CID [NRTADV] TS 38.300CR0407
- RACH optimisation in EN-DC secondary cell TS 36.300CR1366
- Correction on simultaneous reception of SDT and other channels in TS 38.202 TS 38.202CR0026
- CR on ChannelAccess-Cpext in Fallback DCI TS 38.212CR0118
- CR on channel access type indication in non-fallback DCI TS 38.212CR0125
- Corrections on intra-UE multiplexing and semi-static channel occupancy TS 38.212CR0136
+ 5 more changes
In Release 18, the RACH function was enhanced with a generalization of RACH-less handover support and the introduction of mechanisms for RACH resources during an ongoing SDT (Small Data Transmission) procedure. The release also included corrections and clarifications for the PRACH retransmission indicator and PRACH association indicator within the PDCCH order for random access. These updates refined the physical channel procedures for scenarios like handover and connected-mode transmissions.
- RACH-less support generalization [RACH-lessHO] TS 38.300CR0799
- Corrections on PRACH association indicator in PDCCH order in 38.212 TS 38.212CR0192
- CR on the PRACH retransmission indicator field included in the PDCCH order TS 38.212CR0213
- Correction on RACH-less HO Use Case [RACH-lessHO] TS 38.300CR0904
- RACH resources while SDT procedure is ongoing TS 38.300CR0806
- Correction on Transport Channels TS 38.300CR0892
In Release 19, the RACH procedure was updated to support Subband Full Duplex (SBFD) operation in conjunction with Carrier Aggregation (CA). The release also provided clarifications for the configuration of RACH Occasions (ROs) in SBFD for the case where a UE operates with two Timing Advance (TA) groups.
Explore further
Broader topics and technologies where RACH plays a role.
Defining Specifications
3GPP specifications that define or reference RACH, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TR 21.905 vj00 | 3GPP Technical Terms and Definitions | Rel-19 |
| TS 23.171 v1300 | LCS Stage 2 Specification for UMTS | Rel-4 |
| TS 23.271 vj00 | LCS Stage 2 Specification | Rel-19 |
| TS 25.101 vj00 | UTRA FDD UE RF Requirements | Rel-19 |
| TS 25.102 vj00 | UTRA TDD RF Characteristics | Rel-19 |
| TS 25.201 vj00 | UTRA Physical Layer General Description | Rel-19 |
| TS 25.202 vj00 | 7.68Mcps TDD Option Technical Specification | Rel-19 |
| TS 25.211 vj00 | UTRA FDD Layer 1: Transport & Physical Channels | Rel-19 |
| TS 25.212 vj00 | UTRA FDD Layer 1 Multiplexing & Channel Coding | Rel-19 |
| TS 25.213 vj00 | UTRA FDD Spreading and Modulation | Rel-19 |
| TS 25.214 vj00 | UTRA FDD Physical Layer Procedures | Rel-19 |
| TS 25.221 vj00 | UTRA TDD Physical Layer Specification | Rel-19 |
| TS 25.222 vj00 | UTRA TDD Multiplexing & Channel Coding | Rel-19 |
| TS 25.223 vj00 | UTRA Physical Layer TDD Spreading & Modulation | Rel-19 |
| TS 25.224 vj00 | UTRA TDD Physical Layer Procedures | Rel-19 |
| TS 25.225 vj00 | UTRA TDD Physical Layer Measurements | Rel-19 |
| TS 25.301 vj00 | UE-UTRAN Radio Interface Protocol Architecture | Rel-19 |
| TS 25.302 vj00 | UTRA Physical Layer Services | Rel-19 |
| TS 25.321 vj00 | MAC Protocol Specification for UTRAN | Rel-19 |
| TS 25.322 vj00 | RLC Protocol Specification | Rel-19 |
| TS 25.331 vj00 | UTRAN RRC Protocol Specification | Rel-19 |
| TS 25.401 vj00 | UTRAN Overall Architecture | Rel-19 |
| TS 25.402 vj00 | UTRAN Synchronisation Mechanisms | Rel-19 |
| TS 25.420 vj00 | Iur Interface Introduction for UTRAN | Rel-19 |
| TS 25.423 vj00 | UTRAN RNSAP Specification | Rel-19 |
| TS 25.424 vj00 | UTRAN Iur Interface Data Transport & Signalling | Rel-19 |
| TS 25.425 vj00 | UTRAN Iur Interface User Plane Protocols | Rel-19 |
| TS 25.430 vj00 | Introduction to Iub Interface Specifications | Rel-19 |
| TS 25.433 vj00 | Node B Application Part (NBAP) Protocol | Rel-19 |
| TS 25.434 vj00 | UTRAN Iub Interface Data Transport and Signalling | Rel-19 |
| TR 25.912 vj00 | Evolved UTRA and UTRAN Technical Report | Rel-19 |
| TR 25.931 vj00 | UTRAN Signalling Procedures Examples | Rel-19 |
| TS 28.628 vj00 | SON Policy NRM IRP Information Service | Rel-19 |
| TS 31.121 vi50 | UICC-terminal interface test specification | Rel-18 |
| TS 32.401 vj00 | Performance Management Concept & Requirements | Rel-19 |
| TS 36.133 vj20 | E-UTRA RRM Requirements | Rel-19 |
| TS 36.212 vj10 | LTE Multiplexing and Channel Coding | Rel-19 |
| TS 36.300 vj00 | E-UTRAN Radio Interface Protocol Architecture Overview | Rel-19 |
| TS 36.302 vj00 | E-UTRA Physical Layer Services | Rel-19 |
| TS 36.306 vj00 | E-UTRA UE Radio Access Capability Parameters | Rel-19 |
| TS 36.331 vj00 | LTE RRC Protocol Specification | Rel-19 |
| TR 36.902 v931 | SON Use Cases and Solutions for LTE | Rel-9 |
| TS 38.133 vj20 | 5G UE Radio Requirements for RRC_IDLE Mobility | Rel-19 |
| TS 38.202 vj00 | 5G NR Physical Layer Services | Rel-19 |
| TS 38.212 vj10 | NR Multiplexing and Channel Coding | Rel-19 |
| TS 38.300 vj00 | NG-RAN Overall Description | Rel-19 |
| TS 38.523 vj20 | 5G NR UE Conformance Testing: Idle/Inactive | Rel-19 |
| TS 38.811 vf40 | Study on NR Support for Non-Terrestrial Networks | Rel-15 |
| TR 38.889 vg00 | NR-based access to unlicensed spectrum study | Rel-16 |
| TR 38.903 vj00 | Test Tolerances & Measurement Uncertainties | Rel-19 |
| TS 52.402 vj00 | GSM Performance Management Measurements | Rel-19 |