5G NR RRC States - RRC_IDLE, RRC_CONNECTED, and RRC_INACTIVE

Overview

In 3GPP TS 38.331, the state model is simple but very practical. RRC_IDLE is the low-activity state where the UE relies on broadcast system information and paging. RRC_CONNECTED is the active control state for dedicated signaling, measurements, and mobility. RRC_INACTIVE keeps enough UE context to return quickly when service resumes.

State model at a glance

The useful mental model is straightforward: the state tells you what the UE can do, the procedure tells you what the network is trying to achieve, and the message tells you which exchange is carrying that step.

RRC_IDLE
  -> RRC Connection Setup
  -> RRC_CONNECTED
  -> RRC Suspend or Release
  -> RRC_INACTIVE or RRC_IDLE
  -> RRC Resume
  -> RRC_CONNECTED

RRC_IDLE

RRC_IDLE is the state engineers see most often during camped but not connected behavior. The UE is not running an active dedicated RRC connection, so the network reaches it through broadcast and paging behavior rather than connected-mode signaling.

• The UE acquires MIB and SIB1 first, then uses other system information as needed.
• The UE can perform cell selection and cell reselection while staying out of dedicated signaling.
• Paging monitoring is active in this state, so the network can find the UE later.
• Access initiation from idle usually leads into RRC connection setup.

In practice, idle-state analysis starts with broadcast coverage, paging behavior, and whether the UE has enough system information to attempt access cleanly.

RRC_CONNECTED

RRC_CONNECTED is the active signaling state. Once the UE reaches this state, the gNB can apply dedicated radio configuration, the UE can report measurements, and mobility changes can be controlled through connected-mode signaling.

• Dedicated control signaling is available between UE and gNB.
• The network can change configuration with RRC reconfiguration.
• Measurement reporting and handover preparation are typically handled here.
• Radio link issues in this state may lead to reestablishment or release.

If a connected trace looks unstable, the first question is usually whether the break is in the measurement, security, reconfiguration, or recovery path.

RRC_INACTIVE

RRC_INACTIVE keeps enough access stratum context for a faster return to service than a fresh setup. It is the state to check when paging arrives and the UE should resume rather than rebuild the connection from the beginning.

• The UE can be paged while inactive.
• Resume is the normal return path when context is still valid.
• The inactive state sits between fully idle behavior and a fully active connection.
• Related control flows are covered in RRC suspend and RRC resume.

For troubleshooting, inactive-state problems usually mean the context was not preserved, the paging response did not lead to resume, or the resume attempt failed before the UE returned to connected state.

State transitions

The value of the state model is in the transition, not just the label. In a trace, the last valid state often tells you which procedure should have happened next.

Procedures by state

States define what is possible. Procedures define how the UE and gNB move the connection from one condition to another.

Message cues engineers inspect first

States do not carry the signaling by themselves. The signaling is exchanged through RRC messages, and the message family often tells you which state transition should be happening.

The most common messages to check are RRCSetup, RRCReconfiguration, MeasurementReport, SecurityModeCommand, ULInformationTransfer, SIB1, and Paging.

Trace checklist

When a state issue shows up in logs or traces, start with the smallest useful set of questions.

• What was the last confirmed state before the break?
• Did the UE enter idle, connected, or inactive behavior as expected?
• Was paging observed when the UE should have been reached from idle or inactive?
• Did setup, resume, release, or reestablishment proceed in the expected order?
• Did the trace show a state change without the message that should have triggered it?
• Is the issue tied to one UE, one cell, or a repeatable mobility condition?

For deeper failure analysis, pair this page with the 5G RRC failure causes page and the relevant call-flow view.

How the state hub fits the rest of the RRC section

State -> tells you where the UE is
Procedure -> tells you what the network is doing
Message -> carries the signaling exchange
IE -> carries the configuration detail

In practice, this is how most RRC work gets done. First confirm the state, then open the procedure that should be happening there, and only then go down to the message and the IEs if you need the exact configuration detail.

Related 5G topics

RRC sits above the lower radio layers and beside the broader access and paging flows. Keep the surrounding context visible when you are reading traces.

FAQ