RRC States in 5G: Why RRC_INACTIVE Exists

LTE had two RRC states. NR has three. That single addition — RRC_INACTIVE — is one of the more elegant pieces of design in the 5G specification, and it exists because LTE's two states forced a bad trade-off on exactly the traffic pattern that dominates real networks.

Here's the problem. Modern device traffic is bursty: a few kilobytes, then thirty seconds of nothing, then a few kilobytes more. Messaging, notifications, sensor telemetry, background sync.

In LTE you had two options, both bad. Stay in RRC_CONNECTED and drain the battery maintaining a connection that's idle 95% of the time. Or drop to RRC_IDLE and pay a full connection setup — signalling, security establishment, context creation, roughly 50–100 ms — for every 200-byte message.

RRC_INACTIVE is the third option.

---

The three states

RRC_IDLE

The UE is known to the core network but has no RRC connection and no context stored in the RAN. It camps on a cell, monitors paging occasions, performs cell reselection autonomously, and reads system information.

Mobility is entirely UE-controlled — the network isn't tracking it beyond tracking-area granularity. Power consumption is minimal, dominated by the paging cycle. Latency to resume is the worst of the three because everything must be rebuilt.

RRC_CONNECTED

A full RRC connection exists. The UE has a C-RNTI, configured radio bearers, and active context in both the gNB and the core. The network controls mobility through measurement-report-driven handovers.

Data transfer is immediate — no setup delay. Power consumption is highest, though C-DRX (connected mode DRX) substantially reduces it by letting the UE sleep between scheduled monitoring occasions.

Worth stating clearly, because it's a common misconception: RRC_CONNECTED does not mean continuously transmitting. A UE with C-DRX configured may be asleep most of the time while remaining fully connected.

RRC_INACTIVE

The interesting one. The RRC connection is suspended, but the UE context is retained in both the UE and the last serving gNB — now called the anchor gNB. From the core network's perspective, the UE remains in CM-CONNECTED: the NG connection stays up.

The UE behaves much like it does in IDLE — sleeping, reselecting cells autonomously, monitoring paging — but resumes with a lightweight procedure instead of a full setup.

---

The mechanism

Two identifiers make INACTIVE work.

I-RNTI identifies the suspended context and points to the anchor gNB. When the UE resumes, it presents the I-RNTI and the network retrieves the context — no renegotiation.

RAN Notification Area (RNA) is a set of cells within which the UE can move freely without notifying the network. Cross the boundary and the UE performs an RNA update. This is a finer granularity than the core network's tracking area, which is what lets the RAN page the UE directly rather than involving the AMF.

The resume procedure is a three-message exchange: RRCResumeRequest → RRCResume → RRCResumeComplete. If the target gNB isn't the anchor, it fetches the context over Xn. Compare that to the full setup plus security establishment plus bearer configuration that a transition from IDLE requires.

What suspend actually carries

The transition into INACTIVE is an RRCRelease carrying a suspendConfig — the same message that releases a UE to IDLE, distinguished by that one field. Inside it:

• fullI-RNTI and shortI-RNTI — the long form is used when the UE resumes on a cell that must fetch context over Xn; the short form saves bits when resuming on the anchor itself.
• ran-NotificationAreaInfo — the RNA, expressed as a cell list or a list of RAN area codes.
• t380 — the periodic RNA update timer. It fires even when the UE hasn't moved, so the network knows the UE is still reachable.
• ran-PagingCycle — the paging cycle used for RAN paging, which can be shorter than the core network's.

The UE stores its AS context, releases all radio bearers except SRB0, and stops monitoring its C-RNTI. Everything else — security keys, bearer configuration, measurement setup — is kept.

Security on resume is not a formality

This is the part that surprises people coming from LTE. A resume does not reuse the old keys directly.

The RRCResumeRequest carries a shortMAC-I, a truncated integrity check computed over the request using the stored key and the target cell identity. The network validates it before retrieving anything, which stops an attacker replaying a captured I-RNTI on a different cell.

On success, both sides derive a fresh K_gNB using the NCC (Next Hop Chaining Count) supplied in the suspendConfig. Horizontal key derivation if the NCC is unchanged, vertical if it stepped. The point is that each resume produces new keys, so a compromised session doesn't extend across suspensions.

If the MAC-I check fails, the network answers RRCSetup — falling back to a full establishment — rather than rejecting outright. The UE ends up connected either way; it just pays the IDLE-path cost.

---

IDLE vs INACTIVE

They look similar from the device's side and differ fundamentally underneath:

The key structural point: in INACTIVE the core network doesn't know anything changed. The NG connection stays up, so there's no service request procedure, no AMF involvement, no security re-establishment. The RAN handles the whole thing locally.

That's where the saving comes from — not just fewer messages over the air, but an entire layer of core network signalling avoided.

---

State transitions

IDLE → CONNECTED — full setup, triggered by uplink data, signalling, or paging response.

CONNECTED → INACTIVE — network decision, typically after an inactivity timer expires. The UE is told to suspend and given its I-RNTI and RNA.

INACTIVE → CONNECTED — resume procedure. The fast path.

CONNECTED → IDLE — full release, discarding context.

INACTIVE → IDLE — the context is released, either on expiry or by network decision.

Note there's no direct IDLE → INACTIVE transition. INACTIVE is only reachable by suspending an existing connection, because it's defined by the retained context.

---

What it costs to wake up

The practical impact, roughly:

From CONNECTED — data flows on the next scheduling opportunity. Sub-millisecond, or up to the DRX cycle length if the UE is sleeping.

From INACTIVE — the resume exchange. Roughly 10–20 ms.

From IDLE — random access, RRC setup, security establishment, context creation at the AMF, bearer setup. Roughly 50–100 ms, often more.

For a messaging app sending 200 bytes, the difference between 15 ms and 80 ms isn't about user-perceived speed. It's about how long the radio has to stay powered, which is the entire battery argument.

---

When resume fails

The fast path has failure modes worth knowing, because they show up as latency spikes rather than dropped calls:

Context not found at the anchor. The anchor gNB may have discarded the context — restart, load shedding, or its own timer expiry. The target has a valid I-RNTI pointing nowhere. Result: RRCSetup and a full establishment.

Xn unavailable. If the target can't reach the anchor, it cannot retrieve context, so the resume degrades to full setup. In practice this makes Xn health an RRC-latency issue, not just a handover issue.

t380 expiry. If the UE misses periodic RNA updates — deep sleep, poor coverage — the network eventually releases the context. The UE believes it is INACTIVE; the network has moved on. The next resume attempt falls back to setup.

Resume collision. The UE resumes just as the network pages it. Both sides initiate at once. The specification resolves this in the UE's favour, but the transient shows up in traces as a paging record with no matching response.

The pattern in all four is the same: the network never fails the UE outright, it silently falls back to the expensive path. Which is exactly why INACTIVE problems are easy to miss — nothing breaks, the battery just drains faster and latency creeps up.

---

Sending data without leaving INACTIVE

Release 17 added Small Data Transmission (SDT), and it changes the arithmetic for exactly the traffic that motivated INACTIVE in the first place.

The observation is straightforward: if a device wakes up to send 100 bytes, the resume exchange costs more signalling than the payload. SDT lets the UE transmit while remaining in INACTIVE, using the stored context, with no state change at all.

Two flavours:

• RA-SDT — data rides in Msg3 of the random access procedure, or in MsgA for two-step RACH.
• CG-SDT — the UE is given a configured grant before suspension and transmits on it directly, skipping random access entirely.

The network gates this with a data volume threshold and an RSRP threshold: enough data and the UE is resumed properly; poor coverage and it is resumed properly. SDT applies only to the small-and-well-covered case, which is most IoT traffic.

For a sensor reporting hourly, SDT removes the last significant signalling overhead. The device wakes, transmits on a configured grant, and sleeps — never leaving INACTIVE.

---

Where each state fits

Real devices move between states constantly, and the mapping is fairly intuitive once you see it:

Streaming video — CONNECTED throughout, with C-DRX filling the gaps between buffer fills.

Reading an article — CONNECTED during page load, then INACTIVE after the inactivity timer. Tapping a link resumes in ~15 ms.

Phone in a pocket overnight — INACTIVE initially, then IDLE once the RAN releases the context. Occasional wake-ups for background sync.

IoT sensor reporting hourly — INACTIVE between reports if the context survives, otherwise IDLE. This is the case that motivated the feature.

For massive IoT, the arithmetic is stark. A sensor sending 50 bytes hourly, doing a full IDLE-to-CONNECTED transition each time, spends the overwhelming majority of its energy budget on signalling rather than data. INACTIVE cuts that dramatically — and it's why RedCap devices and NR-Light deployments lean on it heavily.

---

Mobility differences

Mobility handling is what distinguishes the states operationally:

CONNECTED — network-controlled. The UE sends measurement reports; the gNB decides and commands handovers. Precise, and the only state where the network directly controls which cell serves the UE.

INACTIVE and IDLE — UE-controlled cell reselection based on broadcast parameters. The network isn't involved per-cell. The difference is the notification boundary: INACTIVE triggers an RNA update, IDLE triggers a tracking area update.

There's a real trade-off in RNA sizing. A large RNA means fewer updates but paging across more cells. A small RNA means precise paging but frequent updates. Operators tune this against their actual mobility patterns, and getting it wrong shows up as either paging load or signalling load.

---

The mental model

IDLE — no RAN context, core-network paging, cheapest power, slowest resume.

CONNECTED — full context, network-controlled mobility, instant data, highest power (mitigated by C-DRX).

INACTIVE — context retained at the anchor gNB, RAN-level paging, near-IDLE power with near-CONNECTED resume speed.

The trick is that the core network never knows the UE went inactive. The NG connection stays up, so resuming skips the entire core signalling path.

RRC_INACTIVE is a good example of a specification change driven by observed traffic rather than theoretical capability. Networks got bursty, the two-state model made that expensive, and the fix was to keep the expensive part — the context — while releasing the cheap part.

---

Further reading

• 3GPP TS 38.331 — RRC protocol specification, states and procedures
• 3GPP TS 38.300 — NG-RAN overall description, RRC_INACTIVE and RNA
• 3GPP TS 38.304 — UE procedures in IDLE and INACTIVE
• 3GPP TS 38.423 — Xn application protocol, context retrieval