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.
Key Features
- Contention-based and contention-free access modes
- Uplink timing synchronization via Timing Advance command
- Collision detection and resolution mechanisms
- Configurable preamble formats for different cell sizes
- Support for initial access, handover, and scheduling requests
- Low-latency 2-step random access procedure (5G NR)
Evolution Across Releases
Introduced the basic RACH concept for UMTS (UTRAN) as an uplink transport channel. It used a slotted ALOHA-based approach with preamble power ramping. The physical layer used a dedicated PRACH slot structure, and the procedure involved preamble transmission, acquisition indicator, and message part.
Re-defined for LTE (E-UTRAN) with a new physical layer design (PRACH) using Zadoff-Chu sequences for preambles. Introduced the 4-step Contention-Based Random Access procedure (Msg1: Preamble, Msg2: Random Access Response, Msg3: Scheduled Transmission, Msg4: Contention Resolution) and Contention-Free Random Access for handovers.
Enhanced for 5G NR with support for wider subcarrier spacings and multiple numerology-compatible PRACH formats. Introduced the foundational framework for 2-step RACH (Type-2 random access) as a study item, aiming to reduce latency by combining Msg1 and Msg3 into MsgA.
Formally standardized the 2-step RACH (Type-2) procedure for NR. Enhanced reliability for industrial IoT (URLLC) and unlicensed spectrum (NR-U) operations. Introduced improvements for integrated access and backhaul (IAB) nodes performing random access.
Further enhancements for 2-step RACH, including improved fallback to 4-step RACH and reliability mechanisms. Introduced support for reduced capability (RedCap) NR devices, with possible simplifications to the RACH procedure to lower complexity and power consumption.
Defining Specifications
| Specification | Title |
|---|---|
| TS 21.905 | 3GPP TS 21.905 |
| TS 23.171 | 3GPP TS 23.171 |
| TS 23.271 | 3GPP TS 23.271 |
| TS 25.101 | 3GPP TS 25.101 |
| TS 25.102 | 3GPP TS 25.102 |
| TS 25.201 | 3GPP TS 25.201 |
| TS 25.202 | 3GPP TS 25.202 |
| TS 25.211 | 3GPP TS 25.211 |
| TS 25.212 | 3GPP TS 25.212 |
| TS 25.213 | 3GPP TS 25.213 |
| TS 25.214 | 3GPP TS 25.214 |
| TS 25.221 | 3GPP TS 25.221 |
| TS 25.222 | 3GPP TS 25.222 |
| TS 25.223 | 3GPP TS 25.223 |
| TS 25.224 | 3GPP TS 25.224 |
| TS 25.225 | 3GPP TS 25.225 |
| TS 25.301 | 3GPP TS 25.301 |
| TS 25.302 | 3GPP TS 25.302 |
| TS 25.321 | 3GPP TS 25.321 |
| TS 25.322 | 3GPP TS 25.322 |
| TS 25.331 | 3GPP TS 25.331 |
| TS 25.401 | 3GPP TS 25.401 |
| TS 25.402 | 3GPP TS 25.402 |
| TS 25.420 | 3GPP TS 25.420 |
| TS 25.423 | 3GPP TS 25.423 |
| TS 25.424 | 3GPP TS 25.424 |
| TS 25.425 | 3GPP TS 25.425 |
| TS 25.430 | 3GPP TS 25.430 |
| TS 25.433 | 3GPP TS 25.433 |
| TS 25.434 | 3GPP TS 25.434 |
| TS 25.912 | 3GPP TS 25.912 |
| TS 25.931 | 3GPP TS 25.931 |
| TS 28.628 | 3GPP TS 28.628 |
| TS 31.121 | 3GPP TR 31.121 |
| TS 32.401 | 3GPP TR 32.401 |
| TS 36.133 | 3GPP TR 36.133 |
| TS 36.212 | 3GPP TR 36.212 |
| TS 36.300 | 3GPP TR 36.300 |
| TS 36.302 | 3GPP TR 36.302 |
| TS 36.306 | 3GPP TR 36.306 |
| TS 36.331 | 3GPP TR 36.331 |
| TS 36.902 | 3GPP TR 36.902 |
| TS 38.133 | 3GPP TR 38.133 |
| TS 38.202 | 3GPP TR 38.202 |
| TS 38.212 | 3GPP TR 38.212 |
| TS 38.300 | 3GPP TR 38.300 |
| TS 38.523 | 3GPP TR 38.523 |
| TS 38.811 | 3GPP TR 38.811 |
| TS 38.889 | 3GPP TR 38.889 |
| TS 38.903 | 3GPP TR 38.903 |
| TS 52.402 | 3GPP TR 52.402 |