Contention Resolution
How Random Access Collisions Get Settled
Contention-based random access exists because the network cannot pre-assign a dedicated preamble to every idle UE. Instead, each UE that wants to access the cell randomly selects one preamble from a shared pool (in 5G NR there are 64 sequences per PRACH occasion, partitioned between contention-based and contention-free groups). Whenever two or more UEs in the same cell happen to choose the same preamble on the same time and frequency RACH occasion, they collide. The base station hears one combined energy detection, replies with a single Msg2 random access response addressed to the RA-RNTI of that occasion, and grants one uplink resource. Both colliding UEs then transmit their Msg3 in the same PUSCH allocation, and the procedure must decide which device actually obtains the connection.
That decision is contention resolution. The discriminator is the UE identity carried in Msg3. For a device already in RRC_CONNECTED, Msg3 includes the C-RNTI MAC CE, so the gNB simply schedules Msg4 on the PDCCH using that C-RNTI; only the addressed UE decodes it and considers contention resolved. For a device in RRC_IDLE or RRC_INACTIVE with no C-RNTI, Msg3 carries a CCCH SDU containing a randomly generated identity. The gNB copies the first 48 bits of that Msg3 verbatim into the UE Contention Resolution Identity MAC CE in Msg4. Each contending UE compares the echoed bits against what it transmitted: a match means it won, a mismatch means it lost and must restart.
Timing governs the whole exchange. After sending Msg3 the UE starts the contention resolution timer and listens for Msg4 on the PDCCH. If Msg4 arrives with a matching identity before expiry, the UE stops the timer, sends HARQ ACK, and the random access procedure completes successfully. If the timer expires, or the echoed identity does not match, the UE flushes the HARQ buffer, increments PREAMBLE_TRANSMISSION_COUNTER, draws a uniform backoff from the window advertised in the backoff indicator, and reattempts. After reaching the configured maximum preamble transmissions the MAC declares a random access problem to upper layers.
Contention Resolution in 2-Step RACH
5G NR adds a 2-step RACH that folds the preamble and the Msg3-equivalent payload into a single MsgA uplink transmission, with MsgB carrying the response. Contention resolution still applies: a successful MsgB delivers the C-RNTI together with the contention resolution identity, while a fallback MsgB pushes the UE back into the 4-step path to send Msg3 on PUSCH. The contention resolution identity in MsgB serves the same role as in 4-step access, confirming which UE owns the granted resource. Because 2-step access removes one full round trip, it shortens the effective resolution window, which is valuable at mmWave where beam dwell times and slot durations are short.
Governing Relations
Success → ContentionResolutionIDrx = first 48 bits of Msg3tx, received before timer expiry
Collision probability for n contending UEs over R preambles:
Pcollision = 1 − (1 − 1/R)n−1 ≈ 1 − e−(n−1)/R
Backoff wait after a failed attempt:
Tbackoff = Uniform(0, BI) × SCALING_FACTOR_BI, BI ∈ {0, 5, 10, 15, 25, 30, 40, 60, 80, 120, 160, 240, 320, 480, 960, 1920} ms
Where R = number of contention-based preambles (≤ 64 per occasion), n = simultaneously contending UEs, BI = backoff indicator value mapped from the BI subheader in Msg2 (the 3GPP TS 38.321 table is non-uniform, capped at 1920 ms), and SCALING_FACTOR_BI is the per-beam scaling factor applied during power ramping. Example: R = 54, n = 20 → Pcollision ≈ 1 − e−19/54 ≈ 0.30.
Resolution Mechanisms Compared
| Scenario | UE State | Msg3 / MsgA identity | Resolution mechanism | Typical timer |
|---|---|---|---|---|
| Initial access | RRC_IDLE | CCCH SDU (random UE ID) | UE Contention Resolution Identity MAC CE (48 bits) in Msg4 | 8 to 64 subframes |
| Connection re-establish | RRC_INACTIVE | CCCH SDU + resume ID | Identity MAC CE echo in Msg4 | 8 to 64 subframes |
| UL sync recovery | RRC_CONNECTED | C-RNTI MAC CE | PDCCH addressed to C-RNTI (no echo needed) | 8 to 64 subframes |
| 2-step success | Idle or connected | MsgA payload | C-RNTI + contention resolution ID in MsgB success RAR | msgB-ResponseWindow |
| Contention-free | Handover / beam failure | Dedicated preamble | None required (no collision possible) | N/A |
Frequently Asked Questions
What is the difference between Msg4 and the contention resolution timer?
Msg4 is the downlink message that actually resolves the collision; the contention resolution timer (ra-ContentionResolutionTimer) is the deadline for waiting on it. The UE starts the timer after Msg3 and monitors the PDCCH. A matching Msg4 before expiry means success; expiry means failure, triggering backoff and a reattempt. In 5G NR the timer is signaled in subframes from {8, 16, 24, 32, 40, 48, 56, 64}, scaled for the active subcarrier spacing.
When does the UE use C-RNTI versus the Contention Resolution Identity MAC CE?
It depends on whether the UE already holds a valid C-RNTI. A UE in RRC_CONNECTED sends a C-RNTI MAC CE in Msg3, and the gNB resolves contention by addressing Msg4 on the PDCCH with that C-RNTI; no echoed identity is needed. A UE doing initial access from RRC_IDLE or RRC_INACTIVE has no C-RNTI, so Msg3 carries a CCCH SDU and the gNB echoes its first 48 bits in the UE Contention Resolution Identity MAC CE in Msg4. A bit match confirms the winner.
How does contention resolution differ between 4-step and 2-step RACH?
4-step RACH resolves contention across Msg3 and Msg4: the UE sends Msg3 on PUSCH after Msg2, then waits for Msg4. 2-step RACH bundles preamble and PUSCH payload into MsgA, and MsgB carries the resolution; a success MsgB gives the C-RNTI plus the contention resolution identity, while a fallback MsgB drops the UE into the 4-step Msg3 path. 2-step removes about one round trip, which matters at mmWave where slot and beam windows are short.
What backoff applies when contention resolution fails?
On failure the UE reads the backoff indicator value carried in the Msg2 random access response, draws a uniform random delay between 0 and that value (the indicator maps to milliseconds from 0 up to 1920), waits, then reselects a preamble and retransmits. The preamble transmission counter increments and the power ramps up by the configured step; after the maximum number of attempts the MAC reports a random access problem to RRC.