RRC States in 5G NR: RRC_IDLE, RRC_INACTIVE, RRC_CONNECTED Interview Prep

RRC States in 5G NR — Context, Paging, and Power Trade-offs

Sample interview questions

1. A UE in RRC_INACTIVE state is paged by the network. What procedure resumes the connection, and what is the latency advantage over a UE in RRC_IDLE?
   • A. The UE performs full initial access including RRC Setup, identical to an RRC_IDLE UE — there is no latency advantage.
   • B. The UE issues an RRC Resume Request using its stored I-RNTI; the gNB resumes the stored UE context (and if the UE resumes at a different gNB, that gNB retrieves the context from the last-serving gNB over Xn), restoring AS security and the radio bearers without a full RRC Setup. This avoids the multi-step RRC Setup exchange and the NAS-layer signaling required from RRC_IDLE. ✓
   • C. The UE remains in RRC_INACTIVE and receives downlink data on the paging channel directly, without resuming.
   • D. The UE transitions to RRC_CONNECTED via an NAS-layer registration update, which is faster than RRC procedures.

   Option B describes the RRC_INACTIVE resume procedure correctly. The defining advantage of RRC_INACTIVE is the preserved UE context (AS security keys, DRB configuration, bearer state) that lets the UE resume connectivity with a single RRC Resume Request / Resume / Resume Complete exchange instead of the multi-step Setup procedure that RRC_IDLE requires. Latency context: an RRC_IDLE UE that receives paging must perform RRC Setup (3 messages), then NAS Service Request (more messages routed via the 5GC), then DRB re-establishment. An RRC_INACTIVE UE that receives RAN-initiated paging issues Resume Request and gets back to data plane within a single RRC exchange because the AS context is already on the network side, fetched over Xn from the last-serving gNB if the UE has moved. Option A misses the entire point of RRC_INACTIVE. Option C is wrong — paging notifies the UE but does not carry data on its own. Option D conflates RRC and NAS layers; NAS registration does not replace the RRC Resume procedure. Production reality: RRC_INACTIVE is widely deployed for IoT-style traffic patterns where UEs sleep but expect occasional small uplinks; the resume saves both latency and signaling load on the 5GC.

2. What is the RAN-based Notification Area (RNA), and why does it matter for a UE in RRC_INACTIVE?
   • A. The RNA is the area within which the UE can decode SIB1 — outside it, the UE must perform full re-selection.
   • B. The RNA defines the cells that can perform handover to the UE — outside it, the UE must use conditional handover.
   • C. The RNA is a set of cells across which an RRC_INACTIVE UE can move without notifying the network; if the UE leaves the RNA, it must perform an RNA Update (RNAU) to inform the last-serving gNB so paging continues to work. ✓
   • D. The RNA is identical to the Tracking Area used in RRC_IDLE — there is no functional difference.

   Option C is correct. The RNA is the RAN-layer equivalent of the Tracking Area (TA) used in RRC_IDLE, but it is managed by the RAN (the last-serving gNB) rather than the 5GC. When an RRC_INACTIVE UE moves between cells inside its RNA, no network signaling is required — the UE simply reselects cells in the normal idle-mode-like way. When the UE crosses the RNA boundary, it triggers an RNA Update (RNAU) procedure that informs the last-serving gNB so that subsequent RAN-initiated paging is directed to the right area. Why this matters: a UE that sits in RRC_INACTIVE for hours can accumulate significant mobility. Without the RNA mechanism, paging would either flood the whole network (huge signaling overhead) or miss the UE (paging failures). The RNA bounds the paging area to a size operators can tune for the expected mobility-versus-signaling trade-off. Option A confuses RNA with the cell-coverage area for SIB1 decoding. Option B is wrong — handover is an RRC_CONNECTED procedure and is unrelated to RNA. Option D misses the layer distinction: the TA is a 5GC concept, the RNA is a RAN concept; they may share boundaries in deployment but they are managed differently. Production reality: RNA sizing is an operator-tunable parameter; smaller RNA means more RNAU signaling but less paging overhead, and vice versa.

3. A UE in RRC_CONNECTED state with no data to send has been configured for short-DRX with on-duration of 4 slots and inactivity-timer of 8 slots. The UE receives a PDCCH grant. What state does it then occupy, and when does it return to DRX?
   • A. The UE transitions to RRC_INACTIVE for the duration of the inactivity timer.
   • B. The UE transitions to RRC_IDLE for power saving and resumes when the next grant arrives.
   • C. The UE remains in RRC_CONNECTED but moves to long-DRX immediately because the short-DRX cycle has been violated.
   • D. The UE remains in RRC_CONNECTED but switches from DRX-sleep to PDCCH-monitoring; the inactivity timer resets on every successful PDCCH decode that schedules new data, and the UE returns to DRX-sleep when the inactivity timer expires without a new grant. ✓

   Option D is correct. DRX is a MAC-layer feature within RRC_CONNECTED — the UE remains in CONNECTED state throughout; what changes is whether the UE is actively monitoring PDCCH (during the on-duration plus active inactivity-timer window) or in DRX-sleep (during the off-duration). DRX state is independent of RRC state. Mechanics: the UE wakes for the on-duration, monitors PDCCH. If it decodes a grant for new data, the inactivity timer starts and the UE keeps monitoring PDCCH until that timer expires without a new grant. Then the UE returns to DRX-sleep until the next on-duration. The inactivity timer is what extends active monitoring during a burst. Option A confuses DRX with RRC state transitions — RRC_INACTIVE requires the gNB to release the UE explicitly, not an inactivity timer. Option B is wrong for the same reason and adds an unrelated RRC_IDLE transition. Option C misreads short-DRX vs long-DRX behavior — the long-DRX cycle is typically activated by a separate timer or RRC reconfiguration, not by a violation. Production reality: short-DRX is configured during bursty traffic, long-DRX during low-activity periods; the transition between them is governed by MAC timers and can be reconfigured via RRC Reconfiguration.

Frequently asked questions

What are the RRC states in 5G NR?

NR defines three RRC states: RRC_IDLE, RRC_INACTIVE, and RRC_CONNECTED. RRC_IDLE is the fully detached state — no UE context on the gNB, no AS security, network reaches the UE only via 5GC-initiated paging on the Tracking Area. RRC_INACTIVE is a 5G-specific intermediate state — UE context is preserved in the last-serving gNB, AS security and DRBs are stored, the UE can resume to RRC_CONNECTED with a single RRC Resume exchange, and the network reaches the UE via RAN-initiated paging on the RAN Notification Area. RRC_CONNECTED is the active state — data plane is set up, the UE monitors PDCCH on its configured search spaces, scheduling and HARQ are active. The three-state model is one of the deliberate improvements over LTE, which had only IDLE and CONNECTED.

What is RRC_IDLE?

RRC_IDLE is the fully detached RRC state. The UE has no AS-layer connection to the gNB, no stored AS security keys, no Data Radio Bearers (DRBs) — only the 5GC retains a UE context, anchored at the AMF. The UE performs cell selection or reselection autonomously based on SIB measurements, and the network reaches the UE only through 5GC-initiated paging delivered across the Tracking Area. Transitions out of RRC_IDLE require full RRC Setup followed by NAS-layer signaling (Service Request or similar). RRC_IDLE delivers the deepest power savings because the UE can DRX-sleep on the paging cycle without maintaining any active monitoring; the cost is the highest setup latency when data does arrive.

What is RRC_INACTIVE?

RRC_INACTIVE is a 5G NR addition that sits between IDLE and CONNECTED. The defining property is preserved UE context: when the gNB suspends the UE to RRC_INACTIVE, it stores the AS security context, the DRB configuration, and the bearer state — and the UE stores a matching I-RNTI. When the UE later needs to resume (either because uplink data arrives at the UE or because the network pages it via RAN-initiated paging), it issues an RRC Resume Request, the gNB fetches the stored context (from itself or from a previous serving gNB over Xn), restores the connection in one RRC exchange, and the data plane resumes — no NAS signaling required for the simple case. RRC_INACTIVE was designed for IoT-style and bursty traffic patterns where UEs sleep for long periods but need fast resume when active.

What is RRC_CONNECTED?

RRC_CONNECTED is the active RRC state. The UE has AS security set up with the serving gNB, DRBs are configured, the UE monitors PDCCH on its allocated search spaces, scheduling and HARQ are active, and the data plane carries traffic. Mobility within RRC_CONNECTED is handled by handover procedures driven by RSRP/RSRQ/SINR measurement events. Power saving within RRC_CONNECTED is handled by MAC-layer DRX (short-DRX for bursty active periods, long-DRX for low-activity periods), and the UE can be configured for BWP switching to reduce monitoring bandwidth when full bandwidth is not needed. The UE remains in RRC_CONNECTED until the gNB explicitly releases or suspends it.

What is the RAN-based Notification Area (RNA)?

The RNA is the set of cells over which an RRC_INACTIVE UE can move without informing the network. It is the RAN-layer analog of the 5GC-managed Tracking Area, but it is managed by the last-serving gNB and is used to bound the area over which RAN-initiated paging is delivered. When the UE crosses the RNA boundary while in RRC_INACTIVE, it triggers an RNA Update (RNAU) procedure so the last-serving gNB knows where to direct future paging. Operators tune the RNA size to trade paging signaling load against RNAU signaling load — a smaller RNA means less paging spread but more RNAU events.

How does paging differ between RRC_IDLE and RRC_INACTIVE?

RRC_IDLE paging is 5GC-initiated: when downlink data arrives at the UPF for a UE that is in IDLE, the AMF signals paging across the Tracking Area, and all gNBs in that TA transmit the paging on their paging channels. RRC_INACTIVE paging is RAN-initiated: the last-serving gNB tracks the RNA, and only the gNBs in that RNA transmit paging. RAN-initiated paging is more efficient (smaller area, lower signaling load) but requires the RAN-side context to still be valid; if the UE has moved outside the RNA without an RNAU, paging can fail. The two use different DRX bases: RRC_IDLE follows the CN paging cycle (from SIB/NAS defaults), while RRC_INACTIVE uses a RAN-configured paging cycle — and an inactive UE monitors both RAN- and CN-initiated paging.

How is power saving compared across RRC_IDLE, RRC_INACTIVE, and RRC_CONNECTED with DRX?

RRC_IDLE delivers the deepest power saving because the UE only wakes on its paging DRX cycle and has no RRC monitoring overhead — but the cost is a high setup latency when data arrives (multiple RRC + NAS round-trips). RRC_INACTIVE is nearly as power-efficient because the UE also DRX-sleeps and only wakes for paging, but the resume latency when data arrives is much lower (single RRC Resume). RRC_CONNECTED with DRX is the least power-efficient of the three because the UE must monitor its PDCCH on the configured on-duration and may extend monitoring via the inactivity timer; in exchange, scheduling latency is zero when active. The right state for a given traffic pattern depends on the expected inter-arrival time of data and the latency budget on first packet.

When does the gNB transition a UE between RRC states, and what controls the choice?

RRC state transitions are gNB-controlled and are signaled via RRC messages. The gNB releases a UE from CONNECTED to IDLE (full release, no context retained) typically after extended inactivity and when the UE is unlikely to need fast resume. The gNB suspends a UE from CONNECTED to INACTIVE (release with stored context and I-RNTI) typically after short-to-medium inactivity when the UE is expected to need fast resume. The gNB resumes a UE from INACTIVE to CONNECTED when the UE issues RRC Resume Request or when RAN paging succeeds and the UE responds. The choice between full release and suspend is gNB-implementation policy — operators tune it for the traffic mix and the signaling-load budget on the RAN and 5GC sides.

How does RRC_CONNECTED mobility relate to handover?

Mobility within RRC_CONNECTED is handled by handover — the UE moves to a different cell while preserving the active connection. The procedure involves measurement events (A3 typical), an RRC Reconfiguration with synchronization carrying the target cell's configuration, contention-free RACH at the target, and RRC Reconfiguration Complete. NR supports Xn-based handover (faster, gNB-to-gNB), N2-based handover (AMF-coordinated), and conditional handover (UE-autonomous execution under high-mobility scenarios). See /topics/nr-handover-and-mobility for the full handover procedure, signaling paths, and Mobility Robustness Optimization tuning.

Related topics