RRC_INACTIVE State in 5G NR
- Venkateshu
- Nov 29
- 11 min read
1. Introduction
The RRC_INACTIVE state represents a fundamental architectural innovation in 5G New Radio (NR), introduced to address critical latency and signaling overhead challenges that plagued LTE networks. In LTE, frequent transitions between RRC_IDLE and RRC_CONNECTED states created substantial network signaling load and introduced latency penalties during service resumption, particularly problematic for modern smartphone usage patterns characterized by frequent small data transmissions. The RRC_INACTIVE state bridges the gap between full connectivity and complete disconnection, enabling rapid service resumption while maintaining power efficiency and reducing core network signaling.
2. Why RRC_INACTIVE State is Needed
LTE Limitations and 5G Requirements
In LTE networks, extended user inactivity triggers transition to RRC_IDLE state for power conservation. However, resuming activity requires complete RRC connection re-establishment, involving extensive RRC signaling and introducing significant latency. Modern mobile applications generate frequent bursts of small data packets—social media updates, instant messaging, IoT sensor data—resulting in repetitive IDLE-CONNECTED-IDLE transitions that burden both the radio interface and core network.
Key Benefits of RRC_INACTIVE
The RRC_INACTIVE state delivers three primary advantages:
Reduced signaling overhead: The Access Stratum (AS) context is stored by both UE and gNB, eliminating the need for complete RRC re-establishment procedures during service resumption
Lower latency transitions: State transition from INACTIVE to CONNECTED occurs significantly faster than IDLE to CONNECTED because radio bearer configurations are preserved
Maintained core network connectivity: The UE remains in CM-CONNECTED state with respect to the 5G Core (5GC), meaning the NG interface connection between gNB and AMF remains active
3. RRC State Architecture in 5G NR
Three-State Model
5G NR implements three distinct RRC states:
RRC_IDLE: No RRC connection exists; UE performs cell selection/reselection and monitors paging. The AS context is released at both UE and network
RRC_INACTIVE: RRC connection is suspended with AS context preserved; UE monitors paging within configured RAN Notification Area (RNA) while behaving similarly to IDLE for power saving
RRC_CONNECTED: Active RRC connection with dedicated resources allocated; UE exchanges user plane and control plane data
Connection Management States
From a 5G Core perspective, the Non-Access Stratum (NAS) connection management states interact with RRC states as follows:
CM-IDLE: Corresponds to RRC_IDLE state; no NG connection exists between gNB and AMF
CM-CONNECTED: Maps to both RRC_CONNECTED and RRC_INACTIVE states; NG signaling connection remains active between gNB and AMF
4. Transition from RRC_CONNECTED to RRC_INACTIVE
4.1. RRCRelease Message with suspendConfig
The gNB initiates transition from RRC_CONNECTED to RRC_INACTIVE by transmitting an RRCRelease message containing the suspendConfig Information Element (IE). This occurs when no higher-layer data traffic is present for a configured duration.
RRCRelease Message Structure
DL-DCCH-Message ::= {
message c1: rrcRelease: {
rrc-TransactionIdentifier 1,
criticalExtensions rrcRelease: {
suspendConfig {
fullI-RNTI '0A1B2C3D4E'H,
shortI-RNTI '1A2B'H,
ran-PagingCycle rf128,
ran-NotificationAreaInfo {
cellList {
physCellId 100,
physCellId 101,
physCellId 102
}
},
t380 min5,
nextHopChainingCount 0
},
deprioritisationReq {
deprioritisationType frequency,
deprioritisationTimer min5
}
}
}
}
Key suspendConfig IE Parameters
fullI-RNTI (40 bits): The Inactive Radio Network Temporary Identifier uniquely identifies the suspended UE context in RRC_INACTIVE state. The network uses this identifier to address the UE in paging messages. The full I-RNTI comprises the AMF Set ID, AMF Pointer, and 5G-Temporary Mobile Subscriber Identity (5G-TMSI) components.
shortI-RNTI (16 bits): A shortened version of the I-RNTI used for efficient identification during the resume procedure. The UE includes this in RRCResumeRequest messages to enable the gNB to quickly locate the stored UE context.
ran-PagingCycle: Defines the discontinuous reception (DRX) cycle for monitoring paging in RRC_INACTIVE state. Values range from rf32 (32 radio frames = 320ms) to rf256 (2560ms). Example: rf128 indicates the UE monitors paging every 1280ms.
ran-NotificationAreaInfo: Specifies the RNA configuration using one of three methods:
Cell list: Explicit list of physical cell IDs constituting the RNA
RAN area code list: List of RAN Area Codes
Tracking area code list: List of 5GC tracking area codes
t380: Periodic RAN Notification Area Update (RNAU) timer. When this timer expires, the UE performs a periodic RNA update to inform the network it remains reachable. Values range from min5 (5 minutes) to min180 (180 minutes). This serves as a keep-alive mechanism.
nextHopChainingCount: Security parameter used for deriving the next security keys during the resume procedure.
4.2. UE Actions Upon Receiving RRCRelease with suspendConfig
According to TS 38.331, the UE performs the following actions:
Resets MAC and releases the default MAC Cell Group configuration
Applies the received suspendConfig (except nextHopChainingCount which is stored)
Re-establishes RLC entities for SRB1
Suspends all RBs except SRB0
Stores the current cell identity in the UE Inactive AS context
Enters RRC_INACTIVE state and performs cell selection as per TS 38.304
Starts timer T380 if configured for periodic RNAU
Example UE Log: Transition to INACTIVE
[RRC] Received RRCRelease message on SRB1
[RRC] Message contains suspendConfig IE
[RRC] Storing UE context:
- fullI-RNTI: 0x0A1B2C3D4E
- shortI-RNTI: 0x1A2B
- Current Cell: PCI=100, CGI=001-01-1A2B3C-00064
[RRC] Configuring RNA with 3 cells: [100, 101, 102]
[RRC] Configured ran-PagingCycle: rf128 (1280ms)
[RRC] Starting T380 timer: 5 minutes (300000ms)
[MAC] Resetting MAC entity
[RLC] Re-establishing SRB1 RLC entity
[RLC] Suspending DRB1, DRB2
[RRC] State transition: RRC_CONNECTED → RRC_INACTIVE
[RRC] Initiating cell selection procedure
RRC_INACTIVE State Behavior and Mobility
E Behavior in INACTIVE State
While in RRC_INACTIVE, the UE operates in a power-saving mode similar to RRC_IDLE:
Monitors paging messages according to the configured ran-PagingCycle DRX cycle
Performs cell reselection based on measurements
Stores the UE Inactive AS context including security keys, radio bearer configurations, and RRC configuration
Does not have an allocated C-RNTI or dedicated resources
4.3 RAN Notification Area (RNA) Concept
RNA represents a geographic area consisting of a single cell or group of cells belonging to one or multiple gNBs, confined within the 5GC registration area. When the last serving gNB receives downlink data from the User Plane Function (UPF) or signaling from the AMF, it transmits paging messages to every cell in the RNA. This enables precise UE location tracking at the RAN level without core network involvement.
RAN Notification Area Update (RNAU) Procedure
The UE triggers RNAU under two conditions:
Cell reselection outside RNA: When the cell reselection procedure selects a cell not belonging to the configured RNA
Periodic RNAU: When timer T380 expires, requiring periodic location update even if the UE remains within the RNA
RNAU Procedure Flow
The UE initiates RNAU by transmitting an RRCResumeRequest message with resumeCause set to 'rna-Update':
UL-CCCH-Message ::= {
message c1: rrcResumeRequest: {
rrcResumeRequest {
resumeIdentity '1A2B'H, // shortI-RNTI from suspendConfig
resumeMAC-I 'E8A7'H, // Message authentication code
resumeCause rna-Update,
spare '0'B
}
}
}
The new gNB uses the provided I-RNTI to retrieve the UE context from the last serving gNB via Xn interface (if the gNBs differ). The network responds with either RRCRelease with updated suspendConfig or RRCResume if data transfer is required.
5. Transition from RRC_INACTIVE to RRC_CONNECTED
Resume Triggers
The resume procedure from RRC_INACTIVE to RRC_CONNECTED can be initiated by:
Mobile-originated (MO) data: UE has uplink data to transmit
Mobile-terminated (MT) data: Network pages the UE for downlink data delivery
RNA Update: As described above, which may transition to CONNECTED if the network decides
Resume indication: Network includes resumeIndication in suspendConfig, triggering automatic resume
5.1 Resume Procedure Messages
The complete resume procedure consists of three messages:
RRCResumeRequest (UE → gNB on SRB0)
RRCResume (gNB → UE on SRB1)
RRCResumeComplete (UE → gNB on SRB1)
RRCResumeRequest Message
The UE transmits RRCResumeRequest after completing the Random Access (RACH) procedure:
UL-CCCH-Message ::= {
message c1: rrcResumeRequest: {
rrcResumeRequest {
resumeIdentity '504601'H,
resumeMAC-I 'F474'H,
resumeCause mo-Data,
spare '0'B
}
}
}
resumeIdentity: Contains the shortI-RNTI value received in suspendConfig. This enables the gNB to retrieve the stored UE context.
resumeMAC-I (16 bits): Message Authentication Code for Integrity protection. Calculated using stored security keys to prevent replay attacks and unauthorized access.
resumeCause: Indicates the reason for resume:
mo-Data: Mobile-originated data transmission
mo-Signalling: Mobile-originated signaling
mt-Access: Response to paging (mobile-terminated access)
mo-VoiceCall: Voice call initiation
rna-Update: RAN Notification Area update
mps-PriorityAccess/mcs-PriorityAccess: Priority access scenarios
Example UE Log: Resume Request Transmission
[APP] Uplink data available in buffer (128 bytes)
[RRC] RRC_INACTIVE state detected, initiating Resume procedure
[RRC] Resume cause: mo-Data
[RRC] Retrieving stored UE context:
- shortI-RNTI: 0x504601
- Stored security keys present
[RRC] Calculating resumeMAC-I using stored keys
[RRC] resumeMAC-I calculated: 0xF474
[MAC] Initiating Random Access procedure
[PHY] Msg1: PRACH preamble transmitted on PRACH occasion
[PHY] Msg2: RAR received, UL grant allocated
[MAC] Msg3: Preparing RRCResumeRequest on SRB0
[RRC] Transmitting RRCResumeRequest:
resumeIdentity: 0x504601
resumeMAC-I: 0xF474
resumeCause: mo-Data
[RRC] Waiting for RRCResume or RRCSetup response
5.2 RRCResume Message
The gNB responds with RRCResume message on SRB1 if the UE context is successfully retrieved and validated:
DL-DCCH-Message ::= {
message c1: rrcResume: {
rrc-TransactionIdentifier 0,
criticalExtensions rrcResume: {
radioBearerConfig {
srb-ToAddModList {
srb-Identity 2,
reestablishPDCP
},
drb-ToAddModList {
drb-Identity 1,
reestablishPDCP,
cn-Association eps-BearerIdentity: 5,
pdcp-Config { ... }
}
},
masterCellGroup {
cellGroupId 0,
rlc-BearerToAddModList { ... },
mac-CellGroupConfig { ... },
physicalCellGroupConfig { ... },
spCellConfig { ... }
},
measConfig { ... },
fullConfig (OPTIONAL)
}
}
}
radioBearerConfig: Contains PDCP and SDAP configurations for SRBs and DRBs. The reestablishPDCP flag indicates whether PDCP should be re-established (resetting sequence numbers) or resumed (continuing from stored state).
masterCellGroup: Provides RLC bearer configuration, MAC configuration, and physical layer configuration. This IE contains the complete radio resource configuration needed for RRC_CONNECTED operation.
fullConfig: Optional flag indicating full configuration. When present, the UE releases all existing radio configurations and applies the new configuration from scratch. According to TS 38.331, when fullConfig is included, drb-ToAddModList becomes mandatory.
Example UE Log: Processing RRCResume
[RRC] Received RRCResume message on SRB1
[RRC] RRC Transaction ID: 0
[RRC] Validating message integrity and security
[RRC] Message authentication successful
[RRC] Processing radioBearerConfig:
- SRB2: reestablishPDCP
- DRB1: reestablishPDCP, EPS Bearer ID=5
[PDCP] Reestablishing PDCP for SRB2
[PDCP] Reestablishing PDCP for DRB1
- TX_NEXT: 0, RX_NEXT: 0, RX_DELIV: 0
[RRC] Processing masterCellGroup (CellGroupId=0)
[RLC] Configuring RLC bearers:
- SRB1: AM mode, t-PollRetransmit=80ms
- SRB2: AM mode, t-PollRetransmit=80ms
- DRB1: AM mode, t-PollRetransmit=80ms
[MAC] Configuring MAC parameters:
- C-RNTI: 0x4A5B
- BSR timer: periodicBSR-Timer=20ms
- PHR timer: periodicPHR-Timer=50ms
[PHY] Configuring physical layer:
- Serving cell PCI: 100
- DL BWP: 106 PRBs, SCS=30kHz, carrier=640MHz
- UL BWP: 106 PRBs, SCS=30kHz, carrier=520MHz
[RRC] Applying measurement configuration
[RRC] State transition: RRC_INACTIVE → RRC_CONNECTED
[RRC] Preparing RRCResumeComplete message
5.3. RRCResumeComplete Message
The UE confirms successful application of the RRCResume configuration by transmitting RRCResumeComplete:
text
UL-DCCH-Message ::= {
message c1: rrcResumeComplete: {
rrc-TransactionIdentifier 0,
criticalExtensions rrcResumeComplete: {
dedicatedNAS-Message '7E00...'H, // Optional NAS message
selectedPLMN-Identity 1
}
}
}
dedicatedNAS-Message: Optional NAS layer message piggybacked on RRCResumeComplete for efficient signaling.
selectedPLMN-Identity: Identifies which PLMN the UE selected (when multiple PLMNs are broadcast).
Example UE Log: Resume Complete
[RRC] RRCResume configuration applied successfully
[RRC] All radio bearers established
[RRC] Generating RRCResumeComplete message
[NAS] Piggybacking NAS Service Request message
[RRC] Transmitting RRCResumeComplete on SRB1:
rrc-TransactionIdentifier: 0
dedicatedNAS-Message: present (42 bytes)
[RRC] Resume procedure completed successfully
[RRC] Current state: RRC_CONNECTED
[RRC] Data transmission can proceed
[APP] Transmitting buffered uplink data (128 bytes)
6. Transition from RRC_INACTIVE to RRC_IDLE
Transition Triggers
The UE transitions from RRC_INACTIVE to RRC_IDLE under specific conditions:
Network command: Receiving RRCRelease without suspendConfig
Resume rejection: Network sends RRCRelease instead of RRCResume in response to RRCResumeRequest
Failure scenarios: Failure to receive expected response (RRCResume/RRCRelease) after RRCResumeRequest
PLMN/SNPN selection: UE selects a new PLMN or Standalone Non-Public Network
NAS-triggered: Higher layer (NAS) commands RRC to release the connection
6.1. RRCRelease Message (Without suspendConfig)
When the network decides to move the UE to RRC_IDLE, it transmits RRCRelease without the suspendConfig IE:
DL-DCCH-Message ::= {
message c1: rrcRelease: {
rrc-TransactionIdentifier 1,
criticalExtensions rrcRelease: {
deprioritisationReq {
deprioritisationType frequency,
deprioritisationTimer min10
}
}
}
}
The absence of suspendConfig signals that the UE should enter RRC_IDLE state and release all stored AS context.
UE Actions for INACTIVE to IDLE Transition
Upon receiving RRCRelease without suspendConfig or other triggers, the UE:
Stops timer T380 if running (periodic RNAU timer becomes irrelevant in IDLE state)
Releases the stored UE Inactive AS context including I-RNTI, security keys, and radio configurations
Resets MAC and releases all radio bearers
Enters RRC_IDLE state
Initiates cell selection procedure
Performs NAS procedures (e.g., Tracking Area Update if required)
Example UE Log: INACTIVE to IDLE Transition
[RRC] Received RRCRelease message on SRB1
[RRC] suspendConfig IE not present
[RRC] Triggering transition to RRC_IDLE
[RRC] Stopping T380 timer (periodic RNAU)
[RRC] Releasing UE Inactive AS context:
- Deleting fullI-RNTI: 0x0A1B2C3D4E
- Deleting shortI-RNTI: 0x1A2B
- Clearing stored security keys
- Releasing RNA configuration
[MAC] Releasing C-RNTI (not assigned in INACTIVE)
[RLC] Releasing all RLC bearers
[PDCP] Releasing all PDCP entities
[RRC] State transition: RRC_INACTIVE → RRC_IDLE
[RRC] Initiating cell selection
[NAS] Evaluating need for Tracking Area Update
[NAS] Current TAI matches registered TAI list
[NAS] No TAU required
[RRC] UE in RRC_IDLE state, monitoring paging on default DRX cycle
7. Paging in RRC_INACTIVE State
Paging Mechanism
The network pages UEs in RRC_INACTIVE state when mobile-terminated data or signaling arrives. The gNB transmits paging messages to all cells within the configured RNA. The UE wakes up periodically according to the ran-PagingCycle configured in suspendConfig to monitor for paging.
Paging Message Structure
PCCH-Message ::= {
message c1: paging: {
pagingRecordList {
{
ue-Identity fullI-RNTI: '0A1B2C3D4E'H,
accessType 3gpp
}
},
lateNonCriticalExtension (OPTIONAL)
}
}
The paging message contains one or more paging records, each identifying a UE using either fullI-RNTI (for INACTIVE UEs) or 5G-S-TMSI (for IDLE UEs).
UE Response to Paging
Upon detecting a paging message with matching fullI-RNTI, the UE initiates the resume procedure with resumeCause set to 'mt-Access':
[RRC] Paging DRX: Waking up at SFN=512
[PHY] Decoding PDCCH on paging search space
[PHY] DCI detected, PDSCH allocated for paging
[MAC] PDSCH received, delivering to RRC
[RRC] Decoding Paging message
[RRC] Paging record found:
ue-Identity: fullI-RNTI=0x0A1B2C3D4E
Matches stored fullI-RNTI
[RRC] Mobile-terminated access detected
[RRC] Initiating Resume procedure with cause=mt-Access
[MAC] Triggering Random Access procedure
8. Security Considerations
Key Derivation and Integrity Protection
During the resume procedure, security keys are derived from the stored AS security context. The resumeMAC-I field in RRCResumeRequest provides message integrity protection using a 16-bit Message Authentication Code calculated with the stored KgNB (gNB key).
Key derivation process:
UE and gNB store security keys (KgNB) and nextHopChainingCount (NCC) during suspension
Upon resume, both derive new keys if needed based on NCC
resumeMAC-I calculation: HMAC-SHA256 truncated to 16 bits using derived keys
This mechanism prevents unauthorized resume attempts and replay attacks.
9. Comparison: INACTIVE vs IDLE vs CONNECTED
Aspect | RRC_IDLE | RRC_INACTIVE | RRC_CONNECTED |
AS Context | Released at UE and network | Stored at UE and gNB | Active |
CM State | CM-IDLE | CM-CONNECTED | CM-CONNECTED |
NG Connection | None | Maintained (gNB-AMF) | Active |
UE Identifier | 5G-S-TMSI | I-RNTI (full and short) | C-RNTI |
Paging Area | Tracking Area | RNA (RAN-controlled) | Not applicable |
Mobility Procedure | TAU (core network) | RNAU (RAN-controlled) | Handover |
Transition Latency | High (full RRC setup) | Low (context resume) | N/A |
Power Consumption | Lowest | Low | Highest |
10. Network Configuration Guidelines
RNA sizing: Configure RNA to balance paging overhead and RNAU frequency. Larger RNAs reduce RNAU signaling but increase paging overhead. Typical deployments use 5-20 cells per RNA.
T380 timer: Set periodic RNAU timer based on expected UE mobility and network capacity. Values of 5-30 minutes are common. Longer timers reduce signaling but increase uncertainty about UE reachability.
ran-PagingCycle: Configure DRX cycle considering latency requirements and power saving needs. Shorter cycles (rf32-rf64) provide lower latency but higher power consumption. IoT devices may use longer cycles (rf128-rf256).
UE Implementation Considerations
Context storage: Maintain complete UE Inactive AS context including security keys, I-RNTI values, RNA configuration, and radio bearer parameters.
Cell reselection: Implement efficient cell reselection while monitoring RNA membership to minimize unnecessary RNAU procedures.
Timer management: Properly handle T380 timer, ensuring it stops during INACTIVE-to-IDLE transitions to avoid signaling in inappropriate states.
11. Conclusion
The RRC_INACTIVE state represents a sophisticated balance between connectivity, latency, and power efficiency in 5G NR networks. By maintaining AS context and core network connectivity while allowing UEs to operate in a power-saving mode, this state addresses the fundamental challenge of supporting diverse 5G use cases—from ultra-reliable low-latency communications requiring rapid state transitions to massive IoT deployments demanding extended battery life. The detailed message flows involving RRCRelease with suspendConfig, RRCResumeRequest, RRCResume, and RRCResumeComplete, along with RNA-based mobility management, provide network operators with flexible tools to optimize their 5G deployments for specific application requirements and user behavior patterns
12. References
Comments