RRC Connection Procedures in LTE 4G

Introduction

Radio Resource Control (RRC) is the top of the LTE control-plane stack (TS 36.331). It is the layer that decides what radio configuration a UE runs with: which bearers exist, which measurements are active, which cell the UE is camped or connected on, and which security keys protect the link. Everything a UE does in RRC_CONNECTED — from the first attach to a mid-call handover to the final release — is driven by an RRC message pair.

These procedures sit directly on top of random access. The moment contention-based random access assigns the UE a temporary C-RNTI, the very next thing that happens is an RRC procedure: the UE sends RRCConnectionRequest as Msg3. From there RRC governs the entire connected lifecycle — setup, reconfiguration (adding bearers, arming measurements, commanding handover), re-establishment after a radio-link failure, and release back to idle. Rel-13 adds a suspend/resume fast path that is the direct ancestor of NR's RRC_INACTIVE.

Because each procedure is a small, fixed exchange — a request or command, an optional reply, and a complete — a signalling failure almost always lives in one identifiable message. Knowing which message is missing, malformed, or unacknowledged narrows the root cause enormously, which is exactly why reading these flows message by message pays off in the field.

Why RRC procedures are needed

Concretely, RRC exists because the radio link has to be built up in stages, each stage unlocking the next. The first message must leave the UE before any security context exists, so it rides an unsecured bearer. Once the eNB grants a dedicated bearer, the UE can carry its identity and NAS payload to the core. Once the core authenticates and AS security is switched on, data radio bearers and lower-priority NAS can be added. And because radio conditions and mobility constantly disturb this arrangement, RRC also needs procedures to repair a broken link (re-establishment), move it to a better cell (handover inside reconfiguration), and park it efficiently (release, suspend/resume). Each procedure is a controlled transition between well-defined states, which is what makes the connection predictable enough to debug.

Signalling Radio Bearers: which pipe each message rides

RRC messages never travel on a bare channel. Each one rides a Signalling Radio Bearer (SRB), and the SRB fixes the logical channel it uses, the RLC mode underneath it, and whether it is secured. Learn the three SRBs first and every flow below reads like a story rather than a wall of message names.

One more subtlety governs how RRC and NAS share these bearers. RRC can piggyback a NAS message inside an RRC message — the way RRCConnectionSetupComplete carries the initial NAS payload in dedicatedInfoNAS — or it can carry standalone NAS later in a DLInformationTransfer (downlink) or ULInformationTransfer (uplink) on SRB1 or SRB2. High-priority NAS, and any NAS sent before SRB2 exists, rides SRB1; once security is up and SRB2 is configured, ordinary NAS is steered onto SRB2 so it never competes with time-critical RRC signalling for the same bearer. This priority split is precisely why the standard bothered to define two secured SRBs instead of one.

RRC Connection Setup: from idle to connected

A UE in RRC_IDLE that wants to send data or signalling first establishes an RRC connection. This three-message handshake is the one you will meet more often than any other, and it directly follows the random-access exchange that assigned the UE a temporary C-RNTI.

After winning contention-based random access, the UE sends RRCConnectionRequest as Msg3 on SRB0/CCCH. Its ue-Identity is either the s-TMSI — if the UE holds a valid one from a prior registration — or a 40-bit randomValue drawn locally. It also carries an establishmentCause such as mo-Data, mo-Signalling, mt-Access, emergency, highPriorityAccess, or (Rel-11/13) delayTolerantAccess / mo-VoiceCall. That cause is what the eNB uses to apply admission control and prioritisation; under load it may admit an emergency request while rejecting an mo-Data one. This message also starts the UE's T300 timer, which bounds the whole wait for a Setup or Reject.

The eNB answers with RRCConnectionSetup as Msg4, still on SRB0/CCCH. This message carries a radioResourceConfigDedicated that establishes SRB1 (its logicalChannelConfig and RLC-AM parameters) and configures the lower layers — MAC main configuration, physical-channel configuration, and the C-RNTI already handed out during random access. Once the UE applies this, it stops T300 and has a dedicated control bearer for the first time.

Now that SRB1 exists, the UE replies with RRCConnectionSetupComplete as Msg5 on SRB1/DCCH. This message carries selectedPLMN-Identity (an index into the PLMN list broadcast in SIB1), the registeredMME if the UE knows one from a previous attach, and crucially the dedicatedInfoNAS — the initial NAS message, typically an Attach Request or Service Request. The eNB extracts that NAS payload and forwards it to the MME inside the S1AP Initial UE Message, which creates the UE-associated S1 signalling connection at the core. Note that at this instant SRB1 is not yet ciphered — AS security has not been activated, so the setup handshake completes in the clear.

Reading connection setup in the logs

On a UE-side trace, connection setup is three RRC PDUs in quick succession with the C-RNTI already assigned by RACH. The fields that matter for debugging are the identity and cause in the Request, the SRB1 configuration in the Setup, and the NAS payload in the Complete.

Representative UE RRC log (LTE initial access) — illustrative, values vary by vendor/build:

RRC Connection Reconfiguration: bearers, measurements, and handover

This is the workhorse of the connected state. Almost every change to a connected UE — adding a data bearer, configuring measurements, or moving to a new cell — arrives as an RRCConnectionReconfiguration on SRB1, and the UE always answers with RRCConnectionReconfigurationComplete.

To set up user data, the eNB sends RRCConnectionReconfiguration with a radioResourceConfigDedicated whose drb-ToAddModList adds one or more DRBs (each mapping an EPS bearer to an RLC/PDCP/logical-channel configuration), and it typically adds SRB2 in the same message via srb-ToAddModList. To configure measurements, the same message carries a measConfig that holds three linked lists: measObjectToAddModList (what to measure — EUTRA carriers, inter-RAT frequencies), reportConfigToAddModList (when to report — event A1–A6, B1/B2, periodic), and measIdToAddModList (which object is tied to which report). The UE combines these into active measurements whose reports drive later mobility decisions.

For a handover, the message additionally includes mobilityControlInfo. This is the field that turns an ordinary reconfiguration into an intra-LTE handover command: it names the targetPhysCellId, the target carrierFreq, a newUE-Identity (the C-RNTI to use in the target cell), a rach-ConfigDedicated that may reserve a contention-free RACH preamble, and a t304 guard timer. On receiving it, the UE detaches from the source cell, synchronises to the target, performs RACH there (contention-free if a dedicated preamble was given), and only then sends RRCConnectionReconfigurationComplete to the target eNB. If t304 expires first, the UE declares handover failure and moves to re-establishment.

Two properties of reconfiguration are easy to miss but matter in practice. First, it uses delta signalling: the message describes only what changes, so an "add" list such as drb-ToAddModList sits alongside "release" lists like drb-ToReleaseList, and anything not mentioned keeps its current value. Second, the procedure is strictly acknowledged — the network treats the configuration as applied only when RRCConnectionReconfigurationComplete arrives. If the UE cannot comply with the received configuration, it does not send a Complete; instead it triggers re-establishment, which is why a malformed or unsupported reconfiguration shows up in logs as an RLF-like recovery rather than an explicit error message.

Reading reconfiguration / handover in the logs

The single most useful thing to spot in a reconfiguration trace is whether mobilityControlInfo is present, and if so, whether the UE completed RACH on the target before t304. A Complete sent on the target cell is the signature of a successful handover.

Representative log (intra-LTE handover) — illustrative, values vary by vendor/build:

RRC Connection Release: going back to idle

When the network wants to free the connection, it sends RRCConnectionRelease on SRB1. A couple of optional fields decide not just that the UE goes idle, but exactly where it lands afterwards.

The redirection fields matter operationally. redirectedCarrierInfo is a hard steer — the UE camps on the named carrier immediately — whereas idleModeMobilityControlInfo is a softer bias, adjusting the priorities the UE weighs during autonomous reselection and running for a bounded t320 validity time. Together they let a network shape idle-mode distribution without any UE-specific signalling once the UE has actually gone idle.

RRC Connection Re-establishment: recovering from failure

When the radio link breaks — radio link failure (RLF), handover failure, mobility-from-EUTRA failure, or an integrity-check failure — the UE does not want to start over from a fresh setup if it can avoid it. Re-establishment is the fast-recovery path, and it hinges on the network still holding the UE's context.

On detecting failure the UE starts timer T311, searches for a suitable cell, and if it finds one before T311 expires it sends RRCConnectionReestablishmentRequest on SRB0/CCCH and starts T301. Its ue-Identity is a triplet: the c-RNTI it held in the source cell, the source physCellId, and a shortMAC-I — a 16-bit truncated authentication token computed over the source cell identity, the source C-RNTI, and the target cell identity using the stored integrity key. The reestablishmentCause distinguishes reconfigurationFailure, handoverFailure, and otherFailure. The chosen cell uses the triplet to look up the prepared UE context; if the shortMAC-I verifies, it replies with RRCConnectionReestablishment carrying a radioResourceConfigDedicated that restores SRB1 and a nextHopChainingCount so the UE re-derives its keys. The UE sends RRCConnectionReestablishmentComplete, and the network then almost always follows with an RRCConnectionReconfiguration to restore SRB2 and the DRBs, since re-establishment alone brings back only SRB1.

The limits are strict and worth memorising. Re-establishment only succeeds if the target cell has a prepared context for this UE — typically a cell the source eNB primed over X2, or the source cell itself. If the selected cell has no context, or the shortMAC-I fails to verify, or T301 expires waiting for a reply, the cell sends RRCConnectionReestablishmentReject (or the UE times out), and the UE goes to RRC_IDLE and must perform a full fresh setup, followed by NAS recovery (Service Request / TAU). Likewise, if T311 expires before any suitable cell is found, recovery is abandoned and the UE falls back to idle. Re-establishment is therefore a best-effort optimisation, not a guarantee.

Reading re-establishment in the logs

The re-establishment story is a timer race: T311 to find a cell, then T301 to get an answer. The ue-Identity triplet and the reestablishmentCause tell you what broke and whether the chosen cell could recognise the UE.

Representative UE log (RLF → re-establishment) — illustrative, values vary by vendor/build:

Suspend and Resume: the Rel-13 fast path

Rel-13 added a lighter idle transition for machine-type and bursty traffic: rather than fully releasing the UE, the network can suspend the connection and let the UE resume it later without repeating the full setup and security exchange. It is the LTE ancestor of NR's RRC_INACTIVE.

To suspend, the eNB sends an RRCConnectionRelease with releaseCause set to rrc-Suspend and a resumeIdentity (some material calls this the RRCConnectionSuspend action). The UE moves to RRC_IDLE but, unusually, stores its AS context — the security keys, the bearer configuration, and the resumeIdentity — instead of discarding them. The eNB stores the matching context too.

To resume, the UE sends RRCConnectionResumeRequest on SRB0/CCCH, carrying the resumeIdentity, a resumeCause, and a shortResumeMAC-I that authenticates against the stored context. The eNB looks up the context, and if the token verifies it replies with RRCConnectionResume, which restores SRB1, SRB2, and the DRBs in one shot and refreshes keys via a nextHopChainingCount. The UE applies the restored configuration and answers with RRCConnectionResumeComplete. Because the bearers and security come back together, resume reaches the data-ready state in far fewer messages than a cold setup — exactly the win for a sensor that wakes, sends a few bytes, and sleeps again. If the context is gone or the token fails, the eNB falls the UE back to a normal setup.

The full message map

Put the procedures side by side and the pattern is clear: a request or command message, an optional network reply, and a complete from the UE. The tables below are the ones worth keeping on a cheat sheet — the procedure map, the establishmentCause values, and the SRB each message rides.

LTE ↔ NR

The shape of every procedure survives into 5G NR (TS 38.331), but the message names lose the "Connection" infix and one whole state is added.

Summary

The fastest way to read any LTE signalling log is to recognise which RRC procedure you are inside, then walk its fixed message pair. Setup is Request → Setup → SetupComplete on SRB0 then SRB1, guarded by T300, and it is where the first NAS message reaches the MME. Reconfiguration is the connected-state workhorse: no mobilityControlInfo means stay and reconfigure, presence means hand over under t304. Release parks the UE, optionally steering it with a redirect. Re-establishment is the context-based fast repair bounded by T311 then T301, and it only works if a prepared context and a valid shortMAC-I line up. Suspend/Resume is the battery-saving shortcut that replays a stored context in one command.

Because each procedure is a small, acknowledged exchange, a failure almost always localises to one message: a missing Setup (admission or coverage), an unacknowledged Reconfiguration (a config the UE could not comply with), a rejected Reestablishment (no context or bad token). Identify the procedure, find the message that did not complete, and the field that did not line up is usually the root cause.