RRC States (IDLE & CONNECTED) in LTE 4G

Introduction

The RRC (Radio Resource Control) state is the single most consequential fact about a UE's radio life: it decides whether the eNB holds a context for the phone, who controls its mobility, which identity addresses it, and how long the first packet takes to flow. LTE defines exactly two of them — RRC_IDLE and RRC_CONNECTED — in TS 36.331 and TS 36.300, and every transition between them is driven by a specific, nameable RRC message.

This matters at every stage of the UE lifecycle. A freshly powered phone camps in idle, is paged from the core, and climbs to connected only when there is data to move; an active phone in connected mode is handed between cells under network control; an inactive phone is released back to idle to save battery and free eNB resources. Read a signalling trace and the state you are in — and the message that moved you — is usually the first thing you need to establish before anything else makes sense.

Because each transition is one message (or a short, ordered set), an RRC-state problem almost always lives in one specific step: a RRCConnectionRequest that gets no setup, a RRCConnectionRelease that fires too early, a resume that cannot find its stored context. Knowing which message broke, and in which direction, narrows the root cause enormously.

Why RRC states are needed

Mobile traffic is bursty: short packets separated by long silent gaps. Keeping every UE fully connected would burn battery and pin down eNB resources for phones that are doing nothing most of the time. So LTE keeps most UEs cold — in RRC_IDLE, where the eNB holds no context and the UE handles its own mobility — and only promotes a UE to RRC_CONNECTED when there is something to send or receive. That single split is what lets a network scale to millions of dormant phones cheaply while still giving an active phone full throughput and low latency.

The two-state world

Think of the two states as cold and hot. In RRC_IDLE the network has essentially forgotten you at the radio level — you are cold, and getting online means building the connection from scratch. In RRC_CONNECTED you are hot: the eNB holds your full Access Stratum context, controls your mobility, and data flows immediately in both directions. There is no warm middle state in base LTE, which is exactly the gap that 5G NR later filled with its third state, RRC_INACTIVE. In classic LTE, every wake-up from idle is a full setup — random access, RRC signalling, security activation, and bearer re-establishment before the first byte can move.

The important mental discipline is to keep three layers separate. RRC is the radio layer between the UE and the eNB. Above it sits the NAS, split into a mobility state machine (EMM) and a connection state machine (ECM) that live between the UE and the MME. The two RRC states map cleanly onto the ECM states but only loosely onto EMM, and confusing the three is the single most common LTE-signalling mistake. We will build the two RRC states first, then line them up against EMM and ECM.

RRC_IDLE — cold and camping

In RRC_IDLE the eNB holds no Access Stratum context for the UE. There is no dedicated radio resource, no C-RNTI, and no eNB that "owns" you. The UE simply camps on a suitable cell and handles its own mobility. The core network still knows you exist — the MME keeps your context and your registered Tracking Area — but it knows your location only at Tracking-Area granularity, never per-cell. That coarse location is precisely the deal that makes idle cheap: the UE can roam across many cells without spending a single signalling message, as long as it stays inside its registered Tracking Area List.

An idle UE is not doing nothing. It is running a well-defined set of housekeeping tasks, all specified in TS 36.304 and TS 36.331:

• PLMN selection. The UE (with the NAS) chooses which operator network to attach to, from the PLMN identities broadcast in system information. This is the first decision after power-on and after losing coverage.
• Cell selection and reselection. Having picked a PLMN, the UE runs cell selection to find a suitable cell to camp on (the S-criterion, Srxlev and Squal above zero), then continuously runs cell reselection, ranking neighbours by the R-criterion and hopping to a better cell on its own. The network only influences this through broadcast parameters (qRxLevMin, qHyst, Qoffset, priorities) — it never commands an idle move.
• DRX paging monitoring. The UE monitors its paging occasions using idle-mode DRX (discontinuous reception), waking only on the paging frames and occasions computed from its identity and the broadcast defaultPagingCycle, and sleeping in between.
• System information acquisition. The UE reads the MIB and the SIB schedule (SIB1 plus the SIBs it needs) so it knows how to access the cell, and it re-reads them when a systemInfoModification paging tag or value-tag change tells it the SI has changed.

Because the radio network cannot address you directly in idle, incoming downlink traffic triggers paging from the core: the MME sends a paging message to every eNB in your Tracking Area List, and those eNBs page over the air on the PCCH, addressing you by your S-TMSI. The paging PDSCH is scheduled by a DCI format 1_0 whose CRC is scrambled with the P-RNTI, monitored in the Type2-PDCCH common search space at the UE's computed paging occasions. When the UE is paged, or when it has its own uplink data or signalling to send, it starts a random-access procedure and requests a connection, moving RRC_IDLE → RRC_CONNECTED. Because moving user data needs more than RRC alone, this connection setup is bundled with a NAS Service Request that tells the MME to re-establish the S1 bearers.

RRC_CONNECTED — fully served

In RRC_CONNECTED an RRC context exists in the eNB and the network is in charge. The UE is assigned a C-RNTI — the cell radio network temporary identifier used to address it and to scramble its transmissions on the shared channel — and it holds dedicated radio bearers: at least one signalling radio bearer (SRB1, and SRB2 for NAS transport) plus one or more data radio bearers (DRBs) carrying user traffic. Security is active: AS keys are derived from the K_eNB and both ciphering and integrity protection are running on the SRBs. This is the only state in which active user-plane data transfer happens.

Mobility in connected mode is network-controlled. The eNB configures the UE with measurement objects and reporting events (A1–A6, B1/B2); the UE sends MeasurementReport messages, and the eNB decides when and where to move it with a handover — an RRCConnectionReconfiguration carrying a mobilityControlInfo that hands the UE to the target cell. The UE never chooses its own cell while connected; it goes where it is told. Handover keeps the UE in RRC_CONNECTED throughout — the state does not change, only the serving cell does.

Being connected does not mean the radio is always transmitting. Connected-mode DRX (C-DRX) lets the UE sleep between scheduling opportunities, cycling through on-durations and inactivity timers, but even asleep it monitors the PDCCH (its C-RNTI in the UE-specific search space) far more aggressively than an idle UE monitors paging. If the UE is inactive long enough, an eNB-internal inactivity timer fires and the network releases the UE back to idle with an RRCConnectionRelease, freeing the context and letting the UE sleep deeply again.

How RRC maps to EMM and ECM

RRC is only the radio-level (Access Stratum) view. Above it, the NAS layer between the UE and the MME runs two more state machines, and they are easy to confuse with RRC, so it is worth lining them up explicitly.

EMM (EPS Mobility Management) tracks whether the UE is attached to the network. EMM-DEREGISTERED means not attached — the MME holds no valid location or context for the UE (fresh power-on, or after detach). EMM-REGISTERED means attached — the MME holds a context, knows the Tracking Area, and the default EPS bearer exists. A powered-on, attached phone is EMM-REGISTERED whether or not it is currently exchanging data, so EMM is essentially orthogonal to the RRC state.

ECM (EPS Connection Management) tracks whether a NAS signalling connection exists between the UE and the MME. ECM-IDLE means no NAS connection and no S1-MME connection for that UE; ECM-CONNECTED means the NAS connection is up and the S1-MME association exists. This one maps almost one-to-one onto RRC: a UE in RRC_IDLE is ECM-IDLE, and a UE in RRC_CONNECTED is ECM-CONNECTED. The Service Request (or Attach) that accompanies an idle-to-connected transition is precisely what moves the UE from ECM-IDLE to ECM-CONNECTED and re-establishes the S1-U bearers so user data can flow.

The state diagram and the messages that drive it

Every state change is triggered by a specific RRC message. Learn the message-to-transition mapping and you can read any LTE signalling trace at a glance.

• IDLE → CONNECTED: after random access, the UE sends RRCConnectionRequest; the eNB answers with RRCConnectionSetup; the UE confirms with RRCConnectionSetupComplete, which piggybacks the NAS Service Request (or Attach Request) that re-establishes the S1 bearers. Security is then activated (SecurityModeCommand) and the bearers configured (RRCConnectionReconfiguration).
• CONNECTED → IDLE: the eNB sends RRCConnectionRelease, typically after its inactivity timer expires. The AS context is torn down and the UE returns to camping.
• Within IDLE: the UE moves by its own cell reselection and stays reachable through Tracking Area Updates and paging — no RRC transition is involved.
• Within CONNECTED: the UE moves by network-controlled handover (RRCConnectionReconfiguration with mobilityControlInfo), staying in RRC_CONNECTED throughout.

IDLE → CONNECTED — the setup handshake

This is the transition most "cannot get online" tickets live in. The UE runs random access, sends RRCConnectionRequest on SRB0/CCCH (scheduled under its TC-RNTI during contention resolution), receives RRCConnectionSetup, and confirms with RRCConnectionSetupComplete carrying the NAS Service Request/Attach Request. A failure isolates cleanly to one of those messages.

CONNECTED → IDLE — release

Rel-13 Suspend / Resume — LTE's near-INACTIVE

The one real weakness of the two-state model is that every idle-to-connected trip is a full setup: random access, RRC establishment, security activation, and bearer re-establishment. For a smartphone loading a page that cost is tolerable, but for a battery-powered IoT sensor waking to send a few bytes, the signalling overhead dwarfs the payload. Release 13 addressed this with the RRC Suspend / Resume procedure — often called the light connection — which is LTE's closest analogue to NR's RRC_INACTIVE.

The idea is to release the UE to idle without throwing the context away. When the eNB decides to suspend, it sends an RRCConnectionRelease carrying releaseCause = rrc-Suspend and a resumeIdentity (the resumeID). The UE then goes into idle mode — it camps, reselects, and monitors paging exactly like any idle UE — but it stores its AS context: the security parameters, the bearer configuration, and the resumeID. On the network side, the eNB and the core keep the S1 connection in a suspended state rather than tearing it down.

When data or paging arrives, the UE does not run a fresh setup. It sends an RRCConnectionResumeRequest carrying its resumeID and a short authentication token (a resume MAC-I). The eNB looks up the stored context by resumeID, and answers with RRCConnectionResume, which restores the bearers and re-activates security from the stored keys in a single step; the UE confirms with RRCConnectionResumeComplete. Because the context is reused, the UE is back in RRC_CONNECTED with far fewer messages and far less latency than a cold setup.

Alongside suspend/resume, Release 13 defined the User-Plane CIoT EPS optimisation, which is the machinery that makes suspend/resume useful for cellular IoT: it lets the S1-U bearers be suspended and resumed together with the RRC context, so a resumed UE can send its uplink packet almost immediately. (Its sibling, the Control-Plane CIoT optimisation, instead ships small data inside NAS signalling over SRB, avoiding user-plane bearers altogether — a different answer to the same "tiny packet, big overhead" problem.)

The two states side by side

Get this table straight and the whole LTE state machine falls into place. It pins down the three things that most often trip people up: where the context lives, how mobility is handled, and how the UE is reached.

Notice the paging row. Paging exists only for idle UEs, because only then is the radio network unable to reach the UE directly. The MME distributes the page to every eNB in the UE's Tracking Area List; each eNB broadcasts it on the PCCH at the occasions the UE is known to monitor, addressed by P-RNTI on the PDCCH with the UE's S-TMSI inside the paging record. A connected UE never needs paging — the scheduler already has its C-RNTI and can send it a grant at any time.

Reading state transitions in the logs

Every state change leaves a clean, ordered signature in an RRC trace. The discipline is to read the message names in sequence and confirm each transition landed: if you see RRCConnectionRequest with no RRCConnectionSetup, the UE never left idle; if you see RRCConnectionRelease, note whether it carried rrc-Suspend. The trace below shows a cold idle→connected setup, then a suspend, then a resume.

Representative UE RRC signalling trace — illustrative, values vary by vendor/build:

Summary

LTE has exactly two RRC states, and everything else hangs off which one you are in. RRC_IDLE is cold — no eNB context, S-TMSI identity, UE-controlled reselection, core paging, deepest battery savings but slowest first packet. RRC_CONNECTED is hot — full eNB context, C-RNTI, network-controlled handover, direct PDCCH scheduling, best latency and throughput at the cost of power and resources. The Rel-13 suspend/resume "light connection" is a third mode in behaviour but not in name: it stays formally in RRC_IDLE while keeping the AS context and a resumeID for a fast return.

The fastest way to read any LTE call is to walk the state transitions by message: RRCConnectionRequest → Setup → SetupComplete to climb into connected, RRCConnectionRelease (with or without rrc-Suspend) to fall back out, RRCConnectionResumeRequest → Resume → ResumeComplete to warm-start. Line the radio state up against ECM (one-to-one) and remember EMM is orthogonal, and a "why can't this phone connect / why did it drop / why is it slow to wake" question turns into a specific, testable hypothesis about one message in one direction.

Quick Q&A