Random Access

Msg3/4 —
RRC Setup and Contention Resolution

Msg3 carries the first real uplink data — an RRCSetupRequest identifying the UE. Msg4 resolves any preamble collision and delivers the RRCSetup message, which configures the UE with its dedicated radio bearers and moves it to RRC_CONNECTED. This section covers both messages and the transition to connected state.

TS 38.321 §5.1.5 TS 38.331 §5.3.3 TS 38.212 §6.1.3

Msg3 — RRCSetupRequest

Using the UL grant received in the RAR (RBs 0–5, MCS 4) and the corrected uplink timing (TA=31), the UE transmits Msg3 on the PUSCH. Msg3 contains the RRCSetupRequest message which identifies the UE and states why it is connecting.

The UE shall submit the CCCH SDU (RRCSetupRequest) to lower layers for transmission using the UL grant provided in the Random Access Response, applying the Temporary C-RNTI provided in the Random Access Response.

3GPP TS 38.331, Section 5.3.3.2

RRCSetupRequest — our UETS 38.331 §6.2.2

// RRCSetupRequest ASN.1:
RRCSetupRequest ::= SEQUENCE {
  ue-Identity:
    randomValue = 0x3F2A1C   ← 39-bit random number
    // (no valid IMSI-derived identity yet)

  establishmentCause = mo-Data
    // Other values: emergency, highPriorityAccess,
    // mt-Access, mo-Signalling, mo-VoiceCall...
}

// Transport: CCCH (Common Control Channel) logical channel
// Physical: PUSCH, RBs 0–5, slot 3 (after TA applied)
// RNTI: TC-RNTI = 0x3A7F (from RAR)

Contention resolution — the hidden problem

Recall from 6.1: two UEs may have picked the same preamble. Both received the same RAR. Both sent Msg3 at the same time, on the same resources. Their transmissions collided at the gNB.

The gNB may have partially decoded one of them. Msg4 contains a contention resolution identity — the UE's own identity from Msg3. Each UE compares this against what it sent. Only one matches. The other UE declares failure and retries RACH.

The UE shall consider the contention resolution to be successful if the MAC CE containing the UE Contention Resolution Identity matches the CCCH SDU transmitted in Msg3. Otherwise, the UE shall consider the contention resolution to have been unsuccessful.

3GPP TS 38.321, Section 5.1.5

Msg4 — RRCSetup (Contention Resolution)

Msg4 is delivered on the PDSCH, addressed by the TC-RNTI = 0x3A7F. It contains two things packed together in a MAC PDU:

Msg4 MAC PDU structure TS 38.321 §6.1.3.3, TS 38.331 §6.2.2

RRCSetup — what it contains

The RRCSetup message is the most important RRC message for initial access. It provides the complete radio bearer and channel configuration the UE needs to operate in RRC_CONNECTED state.

RRCSetup — key fieldsTS 38.331 §6.3.2

// RRCSetup ASN.1 (key fields):
RRCSetup ::= SEQUENCE {
  rrc-TransactionIdentifier = 0,

  criticalExtensions:
    rrcSetup:
      // Radio Bearer Configuration
      radioBearerConfig:
        srb-ToAddModList:
          SRB1 → established
          // SRB0: used for Msg3/4 (CCCH)
          // SRB1: first dedicated bearer → RLC-AM → PDCP

      // Master Cell Group configuration
      masterCellGroup:
        cellGroupId = 0

        // RLC bearer config for SRB1
        rlc-BearerToAddModList:
          logicalChannelId = 1   ← DCCH (Dedicated Control Channel)
          rlc-Config: am        ← Acknowledged Mode
          mac-LogicalChannelConfig: priority=1

        // MAC config
        mac-CellGroupConfig:
          bsr-Config: periodicBSR-Timer = sf10
          sr-Config:  ← Scheduling Request config

        // Physical layer config
        physicalCellGroupConfig:
          p-NR-FR1 = 23 dBm   ← UE max power

        // Serving cell config
        spCellConfig:
          servingCellIndex = 0
          spCellConfigDedicated:
            // Initial UL BWP
            uplinkConfig:
              initialUplinkBWP:
                pucch-Config: ...
                pusch-Config: ...
            // PDSCH/PDCCH for connected mode
            pdsch-ServingCellConfig: ...
}

After Msg4 — what changes

Once the UE successfully receives and decodes Msg4 with matching contention resolution identity, a series of state transitions happen simultaneously:

Contention resolution confirmed

Contention resolution MAC CE contains identity matching the UE's Msg3 (randomValue = 0x3F2A1C). Contention resolved. TC-RNTI 0x3A7F is now promoted to full C-RNTI.

SRB1 established

Signalling Radio Bearer 1 is now active — an RLC Acknowledged Mode bearer with full retransmission. From this point, RRC messages use SRB1 instead of the common CCCH channel.

State: RRC_CONNECTED

UE transitions from RRC_IDLE to RRC_CONNECTED. It now has a dedicated C-RNTI, configured bearers, and a scheduled uplink resource. It can send and receive user data after NAS registration completes.

Send RRCSetupComplete → NAS Registration

UE sends RRCSetupComplete on SRB1 including the NAS Registration Request message. The gNB forwards this to the AMF. NAS registration assigns a 5G-GUTI and establishes PDU sessions for data. Full connectivity follows.

Complete RACH timeline — Msg1 through RRC_CONNECTED TS 38.321 §5.1, TS 38.331 §5.3.3

RACH complete — UE is now RRC_CONNECTED

C-RNTI → 0x3A7F (TC-RNTI confirmed as C-RNTI)

SRB1 → established (RLC-AM)

Timing Advance → TA=31 (uplink aligned)

State → RRC_CONNECTED

Next → NAS Registration → 5G-GUTI → PDU session → data

← PreviousMsg2 — RAR Next →RRC States