RRC States (Idle / Inactive / Connected) in 5G NR

1. Why NR Has Three States and Not Two

LTE had two RRC states, and for the traffic LTE was designed around -- web pages, downloads, voice -- two were enough. What changed was not the radio; it was the traffic. A modern handset with thirty background applications generates a near-continuous stream of small, frequent, independent transactions: a keep-alive, a presence update, a push acknowledgement, a few hundred bytes of telemetry. Each one is far too small to justify a connection and far too frequent to leave the connection up between them.

Both two-state options are bad. Keeping the UE in RRC_CONNECTED between bursts burns UE battery on PDCCH monitoring and burns gNB resources on a context that is doing nothing. Releasing to RRC_IDLE means the next burst pays for a full RRC establishment, a NAS Service Request through the AMF, AS security re-activation and a bearer reconfiguration -- roughly twenty messages and a couple of hundred milliseconds to move four hundred bytes.

RRC_INACTIVE splits the difference by separating two things LTE conflated: the radio connection and the access-stratum context. In RRC_INACTIVE the radio connection is gone -- no C-RNTI, no dedicated channels, no PDCCH monitoring except at paging occasions, so the power profile is essentially that of RRC_IDLE. But the AS context, including the security keys and the whole bearer configuration, is retained at both the UE and the last serving gNB. Resuming therefore does not re-negotiate anything; it re-attaches to something that never went away.

The cost is the complexity this document exists to describe. A context held in two places must be kept consistent, findable and securely verifiable across cell changes the network does not control. Everything from §8 onwards is machinery for that one problem.

2. The State Machine at a Glance

T300

T319

T319

Table 1. The seven transitions. Only two of them are UE-initiated state entries, and neither of those is an entry into RRC_INACTIVE -- suspension is always a network decision.

3. RRC_IDLE, in Detail

RRC_IDLE is the state with the least state. No AS context exists anywhere in the RAN -- if the UE were to vanish, no gNB would notice, because no gNB is holding anything for it. What survives is entirely at NAS level: assuming the UE completed registration, it is 5GMM-REGISTERED and holds a 5G-GUTI, and the AMF holds a registration context for it. There is no UE-associated N2 logical connection, so the AMF is CM-IDLE for that UE.

3.1 What the UE does

• Monitors paging. The UE computes its paging frame and paging occasion from its 5G-S-TMSI and the PCCH-Config in SIB1, and monitors PDCCH for the P-RNTI there. The cycle is defaultPagingCycle (rf32, rf64, rf128 or rf256 -- 320 ms to 2.56 s) or the UE-specific DRX cycle if NAS configured one. See the companion 19 Paging.
• Reads system information. MIB, SIB1 and whichever other SIBs the UE needs, including on-demand SI requests via RRCSystemInfoRequest on SRB0 or a MSG1-based request. See the companion 17 System Information.
• Measures and reselects. Entirely autonomously, per TS 38.304 (§13). The network has no visibility of which cell an idle UE is camped on, which is exactly why paging must be broadcast across a whole tracking area.
• Performs access barring checks. Unified Access Control gates every access attempt by access category and access identity, using the uac-BarringInfo in SIB1, with T390 per category on failure.
• Optionally logs measurements. A MeasIdleConfig received while connected (Rel-16) makes the UE measure and log in RRC_IDLE under T331, and report the results on its next transition to RRC_CONNECTED. See the companion 20 Measurements and Events.

3.2 What the UE cannot do

It cannot send or receive user data, cannot be reached by any dedicated signalling, and cannot be handed over -- there is nothing to hand over. To do anything it must run the establishment procedure of §7.1, and that is unavoidably expensive because it rebuilds everything from nothing: RRC connection, AS security, bearers.

4. RRC_INACTIVE, in Detail

This is the state worth understanding properly, because it is the one where a mismatch between the UE's belief and the network's belief is possible -- in RRC_IDLE there is nothing to mismatch, and in RRC_CONNECTED there is an active link to detect it. In RRC_INACTIVE two parties hold a copy of the same context and neither is talking to the other.

4.1 What suspendConfig actually configures

Everything about the state is set up by one IE inside the RRCRelease that puts the UE there. It is small, and every field in it matters:

fullI-RNTI

BIT STRING (SIZE(40))

shortI-RNTI

BIT STRING (SIZE(24))

ran-PagingCycle

ENUMERATED {rf32, rf64, rf128, rf256}

rf128

ran-NotificationAreaInfo

t380

ENUMERATED {min5, min10, min20, min30, min60, min120, min360, min720}

min60

nextHopChainingCount

INTEGER (0..7)

sl-UEIdentityRemote

RNTI-Value

ran-ExtendedPagingCycle

Table 2. SuspendConfig, TS 38.331 clause 6.3.2. Four of the six Rel-15 fields are mandatory, which tells you that the state has no usable default configuration -- it is entirely explicit.

4.2 Two I-RNTIs, and why there are two

The UE is always given both, and which one it uses is decided by the cell it resumes in, not by the anchor. If that cell's SIB1 contains useFullResumeID, the UE sends RRCResumeRequest1 carrying the 40-bit fullI-RNTI; if not, it sends RRCResumeRequest carrying the 24-bit shortI-RNTI TS 38.331 cl. 5.3.13.3. The reason is purely an encoding-length one: RRCResumeRequest must fit the 48-bit CCCH codepoint that MSG3 can carry cheaply, and 40 bits of identity plus 16 bits of MAC-I plus a cause does not fit. RRCResumeRequest1 uses the 64-bit CCCH1 codepoint instead (§9.2).

4.3 The stored UE Inactive AS Context: kept and discarded

On suspension the UE stores what TS 38.331 clause 5.3.8.3 calls the UE Inactive AS Context. What is in it, and what is deliberately left out, decides what a resume has to redo:

Table 3. The UE Inactive AS Context, TS 38.331 cl. 5.3.8.3. The pattern is consistent: anything describing a relationship to a specific cell is discarded; anything describing the bearer and security state is kept.

4.4 The RAN Notification Area

The RNA is the area inside which the anchor gNB believes it can page the UE. It exists because RAN paging is not broadcast network-wide: the anchor sends an XnAP RAN PAGING message to the gNBs covering the RNA and those gNBs page over the air. Outside the RNA, nobody pages, so a UE that reselects out of its RNA must tell the network -- that is the RNA update of §12.

There are two ways to express an RNA, and they scale differently:

Table 4. RAN-NotificationAreaInfo, TS 38.331 clause 6.3.2. A RAN area is signalled in SIB1 per cell (ran-AreaCode inside the tracking area information), so a UE can evaluate membership without a cell list.

4.5 RAN paging and CN paging

A UE in RRC_INACTIVE monitors for both, at possibly different cycles, and the two mean completely different things:

Table 5. RAN versus CN paging for a UE in RRC_INACTIVE. The full paging-occasion arithmetic is in the companion 19 Paging.

For DRX purposes the UE uses the shortest applicable cycle, so configuring a long ran-PagingCycle does not lengthen the UE's monitoring interval if the cell's defaultPagingCycle is shorter TS 38.304 cl. 7.1. That asymmetry catches people trying to tune inactive-mode power consumption: the RAN cycle can only ever be the binding constraint if it is the shortest of the three.

5. RRC_CONNECTED, in Detail

RRC_CONNECTED is the state where the network is in charge. The UE has a C-RNTI, dedicated logical channels, an active security context and a scheduler that knows about it. Crucially, mobility inverts: the UE no longer decides which cell to use. It measures what it is told to measure, reports when a configured event fires, and moves when it receives an RRCReconfiguration containing reconfigurationWithSync.

• Identity. A 16-bit C-RNTI, scoped to one cell and reassigned at every handover. Possibly also a CS-RNTI for configured grants, an MCS-C-RNTI, and group RNTIs (SFI-RNTI, INT-RNTI, TPC-*-RNTI).
• Channels. PDCCH in its configured search spaces for its own C-RNTI; DCCH on SRB1/SRB2 (and SRB3/SRB4 if configured); DTCH per DRB; SSB and CSI-RS for measurement and beam management; the RLM reference signals.
• Still monitors paging -- but for Short Message only, carrying systemInfoModification and etwsAndCmasIndication. A connected UE is not paged for itself.
• DRX. Connected-mode DRX if configured, which is a completely different mechanism from paging DRX: drx-onDurationTimer, drx-InactivityTimer, short and long cycles. See the companion 11 DRX.
• Radio Link Monitoring is active. N310 out-of-sync indications start T310; if N311 in-sync indications do not arrive before it expires, the UE declares Radio Link Failure (§7.3). See the companion 16 RLM and RLF.

6. The Three States Side by Side, and What Each Costs

Table 6. The three states across every dimension that matters when reading a log. The RRC_INACTIVE column is almost always the middle value -- except for the anchor-gNB row, which has no analogue in either neighbour and is where the complexity lives.

6.1 What each state costs to leave

The five-to-nine ratio on the air understates the benefit. The real saving is the nine-plus NGAP messages and the AMF and SMF processing behind them, which is where most of the two hundred milliseconds and essentially all of the core-network load sit. Multiply by the number of handsets in a busy cell and by the transaction rate of a background notification service, and RRC_INACTIVE is the difference between a core network that copes and one that does not.

7. RRC_IDLE and RRC_CONNECTED: Setup, Release and the RLF Path

7.1 IDLE to CONNECTED: RRCSetup

Triggered by upper layers -- a NAS Service Request, a registration procedure, an answer to CN paging -- the UE runs random access and sends RRCSetupRequest in MSG3 on SRB0. T300 starts when the request is submitted to lower layers and stops on RRCSetup or RRCReject.

RRCSetupRequest

RRCSetup

RRCReject

RRCSetupComplete

Table 7. RRC connection establishment. Everything after step 3 -- security, capability, bearers -- is separate procedures; see the companion 15 RRC Procedures and 01 Registration Process.

T300 expiry is not a radio link failure. The UE resets MAC, releases the connection, stores a connEstFailReport and returns to RRC_IDLE to reselect. That report is retrievable later via UEInformationRequest and is the intended way to diagnose repeated establishment failures -- see the companion 16 RLM and RLF.

7.2 CONNECTED to IDLE: RRCRelease

A network decision, delivered on SRB1. Without suspendConfig the UE releases everything and enters RRC_IDLE. Three optional IEs make an ordinary release into a mobility instruction, and all three are worth recognising in a log:

redirectedCarrierInfo

cellReselectionPriorities

deprioritisationReq

suspendConfig

Table 8. RRCRelease-IEs, TS 38.331 clause 6.2.2. The message is only "just a release" when none of these are present.

7.3 CONNECTED to IDLE the hard way: radio link failure

The UE can also leave RRC_CONNECTED unilaterally. N310 consecutive out-of-sync indications from Radio Link Monitoring start T310; if N311 in-sync indications do not arrive before it expires, the UE declares Radio Link Failure. It then starts T311 and attempts re-establishment: select a suitable cell, send RRCReestablishmentRequest with a shortMAC-I, and hope the target can retrieve the context. If T311 expires with no suitable cell, or if T301 expires after the request, the UE goes to RRC_IDLE with release cause RRC connection failure and stores an RLF report.

8. Suspend: RRC_CONNECTED to RRC_INACTIVE

The trigger is always a gNB decision, almost always an inactivity timer, and the message is an ordinary RRCRelease on SRB1 with suspendConfig present. What makes it interesting is the sequence of internal actions on the UE side, because they determine what a resume has to do.

1. Store the UE Inactive AS Context -- keys, ROHC/EHC state, QoS flow mapping, source C-RNTI, source PCI and cellIdentity, and the rest of the configuration (§4.3).

2. Reset MAC and release the default MAC cell group configuration.

3. Re-establish the RLC entity for SRB1 and apply the default SRB1 configuration. This is the step people miss: SRB1 is left in a state from which it can be brought back cheaply, precisely so the resume response can be delivered on it.

4. Suspend SRB1, SRB2 and every DRB. SRB0 stays -- it is the only bearer that survives, and it is what carries the resume request.

5. Indicate PDCP suspend to lower layers for all DRBs.

6. Start the periodic update timer. T380 runs if t380 was configured -- and does not exist at all if it was not.

7. Enter the state and select a cell. The UE is now in RRC_INACTIVE and performs cell selection per TS 38.304.

One consequence of the suspension being silent at NGAP level is that the anchor gNB is now holding resources -- the context, the N3 tunnel endpoint, the I-RNTI allocation -- with no protocol timer forcing it to let go. T380 is a UE timer that makes the UE check in; if t380 was not configured, nothing at all obliges the UE to contact the anchor again. Every implementation therefore runs its own context ageing timer, and how long it is set to is one of the most important undocumented parameters in the system (§16).

9. Resume: RRC_INACTIVE to RRC_CONNECTED

Triggered by uplink data, uplink signalling, or RAN paging. The UE runs random access and sends its resume request in MSG3 on SRB0, starting T319.

9.1 What the UE does before and after sending the request

The subtlety in the resume procedure is that the UE restores SRB1 before it has any response TS 38.331 cl. 5.3.13.3. It re-establishes PDCP and RLC for SRB1, applies the default SRB1 configuration, derives the new keys, and configures lower layers to apply integrity protection and ciphering with them. Only then does it wait. This is why RRCResume and RRCRelease -- both DL-DCCH messages -- can be the response, while RRCSetup and RRCReject -- both DL-CCCH -- are also possible answers on SRB0.

RRCResume

RRC_CONNECTED

RRCRelease

RRCSetup

RRCReject

Table 9. The five possible outcomes of a resume request. Two arrive protected on SRB1 and two arrive in the clear on SRB0, and that difference is itself diagnostic: an SRB0 answer means the network could not or would not use the stored context.

9.2 RRCResumeRequest1 bit by bit

Both resume requests are fixed-length by design, for the same reason RRCSetupRequest is: they have to fit a CCCH codepoint that MSG3 can carry without a length field. RRCResumeRequest is 48 bits and uses UL-SCH LCID 52; RRCResumeRequest1 is 64 bits and uses LCID 0 (the CCCH1 channel).

9.3 Key handling on resume, and why it looks backwards

This is the part that reliably confuses people, and the confusion is reasonable: the resume request is integrity-protected under the old key while the new key is derived in parallel, and the response arrives protected under the new key. Both things happen before either side has confirmed anything to the other.

1. The UE computes the resume MAC-I with the old integrity key. resumeMAC-I is the 16 least significant bits of a MAC-I computed over VarResumeMAC-Input -- the source PCI, the target cell's CellIdentity and the source C-RNTI -- using the integrity algorithm and key that were in force in the source cell TS 38.331 cl. 5.3.13.3. This proves two things at once: that the UE holds the old key, and that it is resuming into this cell and not replaying a request captured elsewhere.

2. In parallel, the UE derives the new key. It computes a fresh K_gNB from the nextHopChainingCount it stored from suspendConfig, together with the target cell's physical cell identity and downlink ARFCN, exactly as in a handover TS 33.501 cl. 6.11. If the stored NCC differs from the one associated with the current key, the derivation is vertical and uses a fresh Next Hop from the AMF's chain; if it is the same, the derivation is horizontal and chains from the current K_gNB.

3. From that it derives the four AS keys. K_RRCint, K_RRCenc, K_UPint and K_UPenc all come from the new K_gNB, and SRB1 is configured to use them.

4. The network does the same two things independently. It verifies resumeMAC-I with the stored old key -- which requires the anchor, since only the anchor has it -- and derives the same new K_gNB from the NH and NCC.

5. The response arrives protected under the new keys. RRCResume is integrity protected and ciphered with them, and the UE's ability to decode and check it is the implicit confirmation that both sides derived the same key. There is no explicit key confirmation message.

10. Context Fetch over Xn When the UE Resumes Elsewhere

A UE in RRC_INACTIVE reselects freely inside its RNA, so by the time it resumes it is often camped on a cell belonging to a different gNB than the one holding its context. The whole reason fullI-RNTI is 40 bits is to make this case solvable: implementations encode the anchor's identity into part of the I-RNTI, so the receiving gNB can work out whom to ask.

RRCResumeRequest1

RETRIEVE UE CONTEXT REQUEST

RETRIEVE UE CONTEXT RESPONSE

UE CONTEXT RELEASE

Table 10. Resume with context fetch, TS 38.423 and TS 38.413. The pattern is Xn handover's, reused: retrieve, re-key, switch the path, release. See the companion 23 Xn Handover.

11. The Four Answers to a Resume Request

RRC_IDLE

RRC_INACTIVE

RRCReject

RRC_IDLE

Table 11. Every answer to a resume request and its cost. Note that RRCReject is the only one that preserves the stored context, which makes it the cheapest rejection available to a loaded gNB.

There is one further INACTIVE-to-IDLE path that does not involve a resume request at all: a Paging message whose paging record contains the UE's ng-5G-S-TMSI rather than its fullI-RNTI. That is CN paging, and it means the AMF believes the UE is CM-IDLE. The UE enters RRC_IDLE, informs upper layers, and establishes with RRCSetupRequest (§4.5).

12. The RAN Notification Area Update: INACTIVE to INACTIVE

An RNA update is a full resume followed by an immediate re-suspend, and it exists so the anchor knows the UE is still reachable and still inside a set of cells the anchor can page. There are two triggers:

• Periodic, on T380 expiry. The UE has not moved out of the RNA but the anchor has not heard from it for t380, so it checks in.
• Mobility, on reselection to a cell outside the configured RNA. The UE evaluates membership from the cell's cellIdentity (for a cellList RNA) or from the tracking area code and ran-AreaCode broadcast in SIB1 (for a ran-AreaConfigList RNA).

Both use resumeCause = rna-Update, and both are answered by an RRCRelease carrying a fresh suspendConfig -- which restarts T380 and, in the mobility case, carries a new RNA appropriate to where the UE now is. If the anchor changed (the update was received by a different gNB, which fetched the context over Xn), the new gNB becomes the anchor and issues new I-RNTIs.

The trade is reachability confidence against signalling. A short t380 means the anchor learns quickly when a UE has gone away, so it can release the context and free the N3 tunnel. A long t380 means the anchor may hold a context for a UE that was switched off eleven hours ago, and will discover this only when a RAN paging attempt goes unanswered.

13. Cell Reselection in RRC_IDLE and RRC_INACTIVE

In both non-connected states the UE chooses its own cell, using the rules in TS 38.304. The network's only influence is the parameters it broadcasts, plus per-UE cellReselectionPriorities handed out in an RRCRelease (§7.2). Understanding the shape of the decision matters because it explains cell changes that no network log records.

13.1 The S-criteria: is a cell usable at all?

Before ranking anything, a cell must be suitable. That is the S-criteria, evaluated on the measured RSRP and RSRQ:

Srxlev = Q_rxlevmeas - (q-RxLevMin + q-RxLevMinOffset)
                     - P_compensation - Qoffset_temp

Squal  = Q_qualmeas  - (q-QualMin  + q-QualMinOffset)
                     - Qoffset_temp

A cell is suitable when   Srxlev > 0   AND   Squal > 0

  Q_rxlevmeas       measured RSRP of the cell
  Q_qualmeas        measured RSRQ of the cell
  q-RxLevMin        minimum required RSRP, broadcast in SIB1/SIB2/SIB4
  q-QualMin         minimum required RSRQ
  q-RxLevMinOffset  offset applied only when evaluating a higher-priority
                    PLMN while camped elsewhere
  P_compensation    max(p-Max - P_PowerClass, 0) -- an uplink-limited
                    correction, so a cell can be inaudible in the uplink
                    despite a strong downlink
  Qoffset_temp      a temporary penalty applied after a failed access

13.2 The reselection decision

Three cases, evaluated in this order TS 38.304 cl. 5.2.4.5:

t-ReselectionNR

t-ReselectionNR

Table 12. The three reselection cases. Note the asymmetry: going up in priority needs only the target to be good enough, while going down needs the serving cell to be bad as well.

13.3 What the UE can skip, and mobility state scaling

Measuring costs power, so the UE is allowed to skip measurements when the serving cell is comfortably good. If Srxlev_s > s-IntraSearchP and Squal_s > s-IntraSearchQ, intra-frequency measurements may be skipped; s-NonIntraSearchP and s-NonIntraSearchQ do the same for inter-frequency and inter-RAT measurements of equal or lower priority -- higher-priority frequencies must always be measured, which is the mechanism that makes priority steering reliable.

The UE also scales t-ReselectionNR by its own estimated mobility state. It counts reselections in a sliding window (t-CrMax): more than n-CellChangeMedium puts it in medium-mobility state, more than n-CellChangeHigh in high-mobility state, and each applies a scaling factor from t-ReselectionNR-SF -- typically shortening the timer so a fast-moving UE reselects sooner.

For a UE in RRC_INACTIVE there is one extra step after every reselection: check whether the new cell is inside the RNA, and if not, start an RNA update (§12). That check is the only thing that distinguishes inactive-mode reselection from idle-mode reselection; everything else in this section applies identically to both.

14. Rel-17 Small Data Transmission: Sending Without Leaving INACTIVE

RRC_INACTIVE made resuming cheap. Rel-17 asked the obvious follow-up question: for a payload of a few hundred bytes, why transition at all? Small Data Transmission lets a UE in RRC_INACTIVE send user data -- and receive a response -- without ever entering RRC_CONNECTED. Two flavours exist:

Table 13. The two SDT variants. CG-SDT is dramatically cheaper and dramatically more fragile -- losing timing alignment or changing cell invalidates it.

The UE may use SDT only when several conditions all hold:

• The data volume is below the configured threshold. A data-volume threshold broadcast by the cell bounds what counts as "small"; a larger buffer forces an ordinary resume.
• The measured RSRP is above the configured threshold. SDT is transmitted before any closed-loop power control or link adaptation, so it is only allowed in good coverage -- the same reasoning that gates 2-step random access on msgA-RSRP-Threshold, in the companion 03 Random Access.
• Every radio bearer with pending data is SDT-enabled. The network marks specific bearers as usable for SDT. If any bearer with buffered data is not on that list, the UE must resume normally -- so a single background bearer can disable SDT for the whole UE.
• For CG-SDT, the timing advance must still be valid. Otherwise the UE falls back to RA-SDT or to an ordinary resume.

The network's response decides what happens next, and this is the part that changes how you read logs. It may send a downlink response and leave the UE in RRC_INACTIVE; it may keep the SDT procedure open for further transmissions; it may send RRCRelease to end it; or it may send RRCResume and pull the UE into RRC_CONNECTED after all -- for instance because more data arrived than the UE declared. A Rel-17 SDT timer bounds the procedure in the same way T319 bounds a resume.

15. Timers, Counters and Parameter Reference

T300

T302

RRCReject waitTime

T319

T320

T380

ran-PagingCycle

SuspendConfig

defaultPagingCycle

nextHopChainingCount

SuspendConfig

INTEGER (0..7)

useFullResumeID

q-RxLevMin

q-Hyst

t-ReselectionNR

cellReselectionPriority

INTEGER (0..7)

Table 14. Parameters governing the three states and the transitions between them. Timer enumerations are from TS 38.331 clause 7.1 and 6.3.2; reselection parameters are from TS 38.331 SIB2 / SIB4 and are evaluated per TS 38.304.

16. Failure Modes and What Each One Means

Table 15. State-transition failure modes. Four of the eleven manifest as an RRCSetup in response to a resume request, and telling them apart is most of the diagnostic work.

17. Configuration Reference (ASN.1)

17.1 RRCRelease and SuspendConfig

RRCRelease-IEs ::= SEQUENCE {
    redirectedCarrierInfo    RedirectedCarrierInfo     OPTIONAL, -- Need N
    cellReselectionPriorities CellReselectionPriorities OPTIONAL, -- Need R
    suspendConfig            SuspendConfig             OPTIONAL, -- Need R
    deprioritisationReq      SEQUENCE {
        deprioritisationType   ENUMERATED {frequency, nr},
        deprioritisationTimer  ENUMERATED {min5, min10, min15, min30}
    }                                                  OPTIONAL, -- Need N
    lateNonCriticalExtension OCTET STRING              OPTIONAL,
    nonCriticalExtension     RRCRelease-v1540-IEs      OPTIONAL
}

SuspendConfig ::= SEQUENCE {
    fullI-RNTI               I-RNTI-Value,          -- BIT STRING (SIZE(40))
    shortI-RNTI              ShortI-RNTI-Value,     -- BIT STRING (SIZE(24))
    ran-PagingCycle          PagingCycle,           -- rf32|rf64|rf128|rf256
    ran-NotificationAreaInfo RAN-NotificationAreaInfo OPTIONAL, -- Need M
    t380                     PeriodicRNAU-TimerValue  OPTIONAL, -- Need R
    nextHopChainingCount     NextHopChainingCount,  -- INTEGER (0..7)
    ...,
    [[
    sl-UEIdentityRemote-r17  RNTI-Value               OPTIONAL, -- Need M
    srs-PosRRC-Inactive-r17  SetupRelease {SRS-PosRRC-Inactive-r17}
                                                      OPTIONAL, -- Need M
    ran-ExtendedPagingCycle-r17 ExtendedPagingCycle-r17
                                                      OPTIONAL  -- Need R
    ]]
}

PeriodicRNAU-TimerValue ::= ENUMERATED {
    min5, min10, min20, min30, min60, min120, min360, min720 }

RAN-NotificationAreaInfo ::= CHOICE {
    cellList            PLMN-RAN-AreaCellList,
    ran-AreaConfigList  PLMN-RAN-AreaConfigList,
    ...
}

PLMN-RAN-AreaCell ::= SEQUENCE {
    plmn-Identity   PLMN-Identity                        OPTIONAL,
    ran-AreaCells   SEQUENCE (SIZE (1..32)) OF CellIdentity
}

RAN-AreaConfig ::= SEQUENCE {
    trackingAreaCode  TrackingAreaCode,
    ran-AreaCodeList  SEQUENCE (SIZE (1..32)) OF RAN-AreaCode  OPTIONAL
}                                             -- RAN-AreaCode 0..255

Listing 1. Abridged from TS 38.331 clause 6.2.2 and 6.3.2. ... marks extension markers and omitted members. The [[ ]] block is a Rel-17 extension addition group.

17.2 The resume requests and what the MAC-I is computed over

RRCResumeRequest ::= SEQUENCE {
    resumeIdentity   ShortI-RNTI-Value,      -- BIT STRING (SIZE(24))
    resumeMAC-I      BIT STRING (SIZE (16)),
    resumeCause      ResumeCause,
    spare            BIT STRING (SIZE (1))
}                                            -- 48 bits total

RRCResumeRequest1 ::= SEQUENCE {
    resumeIdentity   I-RNTI-Value,           -- BIT STRING (SIZE(40))
    resumeMAC-I      BIT STRING (SIZE (16)),
    resumeCause      ResumeCause,
    spare            BIT STRING (SIZE (1))
}                                            -- 64 bits total

ResumeCause ::= ENUMERATED {
    emergency, highPriorityAccess, mt-Access, mo-Signalling,
    mo-Data, mo-VoiceCall, mo-VideoCall, mo-SMS, rna-Update,
    mps-PriorityAccess, mcs-PriorityAccess,
    spare1, spare2, spare3, spare4, spare5 }

-- The input the 16-bit resumeMAC-I is computed over, using the
-- K_RRCint and integrity algorithm in force in the SOURCE cell:
VarResumeMAC-Input ::= SEQUENCE {
    sourcePhysCellId    PhysCellId,      -- INTEGER (0..1007)
    targetCellIdentity  CellIdentity,    -- BIT STRING (SIZE (36))
    source-c-RNTI       RNTI-Value       -- INTEGER (0..65535)
}

RRCResume-IEs ::= SEQUENCE {
    radioBearerConfig   RadioBearerConfig                OPTIONAL, -- Need M
    masterCellGroup     OCTET STRING (CONTAINING CellGroupConfig)
                                                          OPTIONAL, -- Need M
    measConfig          MeasConfig                        OPTIONAL, -- Need M
    fullConfig          ENUMERATED {true}                 OPTIONAL, -- Need N
    lateNonCriticalExtension  OCTET STRING                OPTIONAL,
    nonCriticalExtension      RRCResume-v1560-IEs         OPTIONAL
}

Listing 2. Abridged from TS 38.331 clause 6.2.2 and 6.3.2. Note that RRCResume can carry a whole radioBearerConfig and masterCellGroup -- resume is not obliged to restore the stored configuration unchanged, and fullConfig forces the UE to discard it entirely and start from the message.

18. Illustrative Message Traces

18.1 The suspension

14:22:08.114  [gNB]      UE 0x4601: inactivity timer expired (10 s)
              policy .................. suspend (bursty traffic profile)
              allocate fullI-RNTI ..... 0x0A1234C05F
              allocate shortI-RNTI .... 0x1234C0
              NCC to signal ........... 3

14:22:08.116  [RRC-DL]   DL-DCCH-Message on SRB1, LCID 1
              c1 = rrcRelease
                rrc-TransactionIdentifier ....... 2
                criticalExtensions = rrcRelease
                  suspendConfig
                    fullI-RNTI ................. 0x0A1234C05F
                    shortI-RNTI ................ 0x1234C0
                    ran-PagingCycle ............ rf128     -- 1.28 s
                    ran-NotificationAreaInfo
                      cellList
                        PLMN-RAN-AreaCell[0]
                          ran-AreaCells ........ 12 CellIdentity values
                    t380 ....................... min60
                    nextHopChainingCount ....... 3

14:22:08.131  [UE RRC]   RRCRelease with suspendConfig -> suspend
              store UE Inactive AS Context:
                K_gNB, K_RRCint ......... retained
                ROHC / EHC state ........ retained
                QoS flow -> DRB map ..... retained (1 flow -> DRB 1)
                source C-RNTI ........... 0x4601
                source PCI .............. 41
                source cellIdentity ..... (36 bits)
                reconfigurationWithSync . DISCARDED
                SCell configuration ..... DISCARDED (2 SCells released)
              reset MAC; re-establish RLC for SRB1; suspend SRB1/SRB2/DRB1
              start T380 (min60); enter RRC_INACTIVE; run cell selection

-- nothing on NGAP. The AMF is unchanged: 5GMM-CONNECTED with RRC
-- inactive indication, N2 up, N3 still terminating at this gNB.

Listing 3. A suspension end to end. The two DISCARDED lines are the ones worth noting: an NR-DC or carrier-aggregated UE loses that configuration and has to be given it again after resume.

18.2 A successful resume at the anchor

14:26:41.902  [UE RRC]   uplink data on DRB 1, 412 bytes
              volume above sdt threshold -> ordinary resume
              SIB1 of this cell contains useFullResumeID
              -> use RRCResumeRequest1 with the 40-bit fullI-RNTI

14:26:41.904  [MAC-UL]   RA preamble 17, RA-RNTI 1204
14:26:41.911  [MAC-DL]   RAR: TA 189, UL grant, TC-RNTI 0x51A3

14:26:41.916  [MAC-UL]   MSG3 on PUSCH, TC-RNTI 0x51A3, 10 octets
              subheader  LCID 0        -- CCCH1, 64-bit form
              SDU ..................... 0A 24 68 98 0B F9 C4 E1
              UL-CCCH1-Message
                c1 = rrcResumeRequest1
                  resumeIdentity ...... 0x0A1234C05F
                  resumeMAC-I ......... 0x9C4E
                  resumeCause ......... mo-Data
                  spare ............... 0
              start T319 (ms1000)

14:26:41.917  [UE RRC]   re-establish PDCP and RLC for SRB1
              derive K_gNB* from stored NH, NCC 3, target PCI 41
              derive K_RRCint / K_RRCenc; apply to SRB1

14:26:41.919  [gNB RRC]  I-RNTI 0x0A1234C05F -> local context (anchor = self)
              recompute resumeMAC-I over VarResumeMAC-Input:
                sourcePhysCellId ...... 41
                targetCellIdentity .... (this cell, 36 bits)
                source-c-RNTI ......... 0x4601
              computed 0x9C4E, received 0x9C4E -- MATCH
              derive the same K_gNB* from NH with NCC 3

14:26:41.926  [MAC-DL]   PDSCH to TC-RNTI 0x51A3
              LCID 62  UE Contention Resolution Identity  (echoes MSG3)
              LCID 1   SRB1: DL-DCCH-Message, PDCP SN 0, MAC-I non-zero
                c1 = rrcResume
                  rrc-TransactionIdentifier ... 0
                  criticalExtensions = rrcResume
                    masterCellGroup ........... (OCTET STRING, 96 octets)
              -- TC-RNTI 0x51A3 promoted to C-RNTI

14:26:41.927  [UE RRC]   stop T319; restore the stored context;
                         resume SRB1, SRB2 and DRB 1;
                         discard the UE Inactive AS Context
14:26:41.934  [RRC-UL]   rrcResumeComplete  txn 0  on SRB1
14:26:41.941  [MAC-UL]   DRB 1: 412 bytes on DTCH

-- 37 ms from data arrival to data on the air. No NGAP, no Xn.

Listing 4. A resume at the anchor. Note the MAC-I on the very first downlink SRB1 PDU: unlike the setup case, security is already active on the first protected message, under keys derived independently by both sides.

18.3 A resume that falls back to setup

16:55:02.338  [RRC-UL]   rrcResumeRequest1
                resumeIdentity .......... 0x0A1234C05F
                resumeMAC-I ............. 0x71B0
                resumeCause ............. mo-Data
              start T319 (ms1000)

16:55:02.341  [gNB RRC]  fullI-RNTI decodes to anchor gNB-ID 0x0A12
                         which is not this node -> retrieve over Xn
16:55:02.342  [XnAP-TX]  RETRIEVE UE CONTEXT REQUEST
                I-RNTI .................. 0x0A1234C05F
                resumeMAC-I ............. 0x71B0
                new cell NR CGI ......... (this cell)

16:55:02.389  [XnAP-RX]  RETRIEVE UE CONTEXT FAILURE
                cause ................... unknown-or-already-allocated-
                                          gNB-CU-UE-F1AP-ID / context not
                                          available
              -- the anchor aged this context out 4 minutes ago;
              -- its local inactivity ageing timer is 30 min, t380 was 60

16:55:02.392  [RRC-DL]   DL-CCCH-Message on SRB0
              c1 = rrcSetup
                rrc-TransactionIdentifier ... 0
                radioBearerConfig -> srb-ToAddModList -> srb-Identity 1
                masterCellGroup ............. (OCTET STRING, 208 octets)
              -- note: SRB0, in the clear. That alone tells the UE the
              -- stored context was not usable.

16:55:02.395  [UE RRC]   RRCSetup received while T319 running
              -> stop T319
              -> discard the stored UE Inactive AS Context
              -> inform upper layers: RRC connection was NOT resumed;
                 a NAS Service Request is required
              -> apply the RRCSetup as an establishment from RRC_IDLE

16:55:02.408  [RRC-UL]   rrcSetupComplete on SRB1
                dedicatedNAS-Message ........ (NAS Service Request)
              -- SecurityModeCommand, UECapabilityEnquiry and a full
              -- RRCReconfiguration all follow. Cost: ~9 more messages.

Listing 5. The fallback path, with its root cause visible: the anchor's own context ageing timer was shorter than the t380 it signalled, so the UE was checking in on a schedule the anchor had already stopped waiting for.

18.4 An RNA update, and a CN page received while inactive

15:22:08.118  [UE RRC]   T380 expired (min60 since 14:22:08)
                         -> initiate RAN Notification Area Update
15:22:08.140  [RRC-UL]   rrcResumeRequest1
                resumeIdentity .......... 0x0A1234C05F
                resumeMAC-I ............. 0x2D77
                resumeCause ............. rna-Update      -- not mo-Data
              start T319
15:22:08.166  [RRC-DL]   DL-DCCH-Message on SRB1
              c1 = rrcRelease
                suspendConfig
                  fullI-RNTI ............ 0x0A1234C05F    -- unchanged
                  shortI-RNTI ........... 0x1234C0
                  ran-PagingCycle ....... rf128
                  ran-NotificationAreaInfo  ABSENT  -- Need M: keep the
                                                    -- existing RNA
                  t380 .................. min60
                  nextHopChainingCount .. 4               -- incremented
15:22:08.171  [UE RRC]   stop T319; store the new suspendConfig;
                         restart T380; remain in RRC_INACTIVE
              -- five messages on the air, no NGAP, no state change

-- Two hours later, a different story:

17:41:19.002  [MAC-DL]   PDCCH / P-RNTI at a CN paging occasion
17:41:19.003  [RRC-DL]   PCCH-Message
                paging
                  pagingRecordList
                    PagingRecord[0]
                      ue-Identity = ng-5G-S-TMSI ..... matches this UE
                      accessType .................... non3GPP absent
              -- CN paging, NOT RAN paging: the record carries the NAS
              -- identity, not the fullI-RNTI
17:41:19.004  [UE RRC]   matching ng-5G-S-TMSI while in RRC_INACTIVE
              -> enter RRC_IDLE
              -> discard the UE Inactive AS Context
              -> inform upper layers about the paging
17:41:19.088  [RRC-UL]   rrcSetupRequest
                ue-Identity = ng-5G-S-TMSI-Part1
                establishmentCause ...... mt-Access
              -- diagnostic: the AMF believed this UE was CM-IDLE, so the
              -- anchor must already have sent NGAP UE CONTEXT RELEASE
              -- REQUEST. Find out why it gave up on the context.

Listing 6. Two INACTIVE events with opposite meanings. The RNA update is routine housekeeping; the CN page proves the RAN and the core had already diverged about this UE's state.

18.5 A silent key mismatch

18:02:44.511  [RRC-UL]   rrcResumeRequest1  resumeCause mo-Data
                resumeIdentity .......... 0x0A1234C05F
                resumeMAC-I ............. 0x2D77
              start T319 (ms1000)
              UE derives K_gNB* using its stored NCC = 3

18:02:44.519  [gNB RRC]  context found; resumeMAC-I verifies
                         (it is computed with the OLD K_RRCint, which
                          both sides still agree on)
              gNB derives K_gNB* using NCC = 4
              -- the last suspendConfig it sent carried NCC 4; the UE
              -- never received it and is still using NCC 3

18:02:44.526  [RRC-DL]   rrcResume on SRB1, PDCP SN 0, MAC-I 0x8A31F0C2
              -- ciphered and integrity-protected under the gNB's keys

18:02:44.528  [UE PDCP]  SRB1 PDCP SN 0: integrity check FAILED
              -> discard the PDU; indicate the failure to upper layers
              -> RRC never sees a message, so RRC does nothing
              -- there is no RRC-level way to report this

18:02:44.529  [gNB RRC]  RRCResume sent; waiting for RRCResumeComplete
18:02:45.511  [UE RRC]   T319 expired
              -> RRC_IDLE, release cause RRC resume failure
              -> discard the stored UE Inactive AS Context
18:02:45.98x  [gNB RRC]  no RRCResumeComplete; guard timer expires
              -> release the UE context, NGAP UE CONTEXT RELEASE REQUEST

-- Signature: resumeMAC-I verified (so the OLD keys matched) but the
-- response was never acknowledged (so the NEW keys did not). That pair
-- of facts together points at nextHopChainingCount and nothing else.

Listing 7. The NCC mismatch, which is the hardest resume failure to diagnose because the gNB's log shows every step succeeding. The combination of a verified resumeMAC-I and an absent RRCResumeComplete is the only evidence, and it is conclusive.

19. Release Deltas: Rel-15 to Rel-18

Table 16. State-model changes by release. Rel-17 SDT is the one that changes how logs must be read; the rest add parameters and cases.

20. Reading RRC States in Logs: A Checklist

1. Check every release message for a suspend configuration. RRCRelease is the same message either way, and the presence of suspendConfig is the whole difference between RRC_IDLE and RRC_INACTIVE. Getting this wrong invalidates everything downstream (§8).

2. Record the I-RNTI pair and the NCC from each suspend. The values inside suspendConfig are the only handles you have on the suspended UE. The NCC in particular is the value you will need if a later resume fails silently (§9.3).

3. On a resume, read the cause before anything else. A resumeCause of rna-Update is housekeeping that legitimately ends in RRCRelease; mo-Data, mt-Access and the rest are real resumes that should end in RRCResume. Mixing them corrupts every resume-success KPI (§12).

4. Note which SRB the response arrived on. RRCResume and RRCRelease come back protected on SRB1, meaning the context was used. RRCSetup and RRCReject come back in the clear on SRB0, meaning it was not. That is a one-glance verdict on whether the state machine worked (§9.1).

5. For every fallback setup, determine which of the four causes it was: the anchor discarded the context, there is no Xn to the anchor, the resumeMAC-I did not verify, or the I-RNTI width was wrong. All four produce an identical RRCSetup on the air and have four different fixes (§16).

6. Compare the resume timer against your Xn context-fetch round-trip time. If a fetch can take longer than T319, resumes at non-anchor gNBs will fail under load and succeed when idle -- which reads as a capacity problem and is a timer problem (§16).

7. Compare the anchor's context ageing timer against the periodic update timer. If the ageing timer is shorter than t380, every long-lived suspended UE eventually resumes into a context that is not there (§18.3).

8. When a resume looks successful at the gNB but the Complete never arrives, suspect the NCC. A verified resumeMAC-I plus a missing RRCResumeComplete is the signature of a key mismatch and of nothing else (§18.5).

9. Treat CN paging answered from the inactive state as an alarm. A UE in RRC_INACTIVE that answers a CN page proves the anchor had already released the context while the UE still believed it had one (§4.5).

10. Audit the resume-identity flag and the Xn topology against every configured RNA. useFullResumeID and Xn connectivity are both per-cell facts that RNAs assume and neither is checked anywhere. This is the highest-yield configuration audit in the state machine (§4.2, §10).

11. Once SDT is enabled, stop inferring state from RACH. A completed random access from RRC_INACTIVE may leave the UE exactly where it was (§14).

21. Glossary

RRC_IDLE

RRC_INACTIVE

RRC_CONNECTED

I-RNTI

resumeMAC-I

NCC

nextHopChainingCount

NH

Treselection

22. References

• 3GPP TS 38.331 -- NR RRC protocol specification. Clause 4.2.1 (RRC states), 5.3.3 (RRC connection establishment and T300), 5.3.8 (RRC connection release, including 5.3.8.3, suspension), 5.3.13 (RRC connection resume, including 5.3.13.3 request contents and resumeMAC-I, and 5.3.13.6 reception of RRCReject), 5.3.15 (RRCReject), 6.2.2 (RRCRelease, RRCResumeRequest, RRCResumeRequest1, RRCResume), 6.3.2 (SuspendConfig, RAN-NotificationAreaInfo, CellReselectionPriorities), 7.1 (UE timers and constants), 7.4 (VarResumeMAC-Input).
• 3GPP TS 38.304 -- UE procedures in idle mode and RRC_INACTIVE state. Clause 5.2.3 (cell selection criterion S), 5.2.4 (cell reselection, priorities, ranking and Treselection), 5.2.4.3 (measurement rules and the search thresholds), clause 7 (paging occasions and the DRX cycle a UE in RRC_INACTIVE uses).
• 3GPP TS 38.300 -- NR and NG-RAN overall description. Clause 4.2.3 (RRC states and the state model), clause 9.2.2 (RRC_INACTIVE state management, RAN paging and RNA).
• 3GPP TS 33.501 -- Security architecture and procedures for 5G System. Clause 6.8 (AS key derivation, horizontal and vertical), clause 6.11 (RRC_INACTIVE state security, including key handling on suspend and resume).
• 3GPP TS 38.423 -- Xn application protocol (XnAP). Retrieve UE Context, RAN Paging, and UE Context Release procedures.
• 3GPP TS 38.413 -- NG application protocol (NGAP). Path Switch Request, Paging, and UE Context Release procedures.
• 3GPP TS 24.501 -- NAS protocol for 5G System. Clause 5.1.3 (connection management states, including 5GMM-CONNECTED with RRC inactive indication).
• 3GPP TS 38.321 -- NR MAC protocol specification. Clause 5.1 (random access, which every resume runs), and the CCCH / CCCH1 LCID codepoints that make the two resume-request lengths matter.

Companion documents in this set

• 13 RRC Overview -- the layer, the SRBs, unaligned PER, the message catalogue, and the RRC-versus-5GMM state cross-product.
• 15 RRC Procedures -- setup, resume, release, reconfiguration and the rest, procedure by procedure, with delta configuration worked through.
• 01 Registration Process -- what the NAS side of an IDLE-to-CONNECTED transition actually costs.
• 03 Random Access -- every resume begins with a RACH; the triggers table there lists resume among them.
• 11 DRX -- connected-mode DRX, which is a different mechanism from the paging DRX of §3 and §4.
• 16 RLM and RLF -- T310, T311, T301, re-establishment and the RLF report: the other way out of RRC_CONNECTED (§7.3).
• 17 System Information -- SIB1, UE-TimersAndConstants, useFullResumeID and the reselection parameters of §13.
• 19 Paging -- paging frames and occasions, and the RAN-versus-CN paging distinction of §4.5 in full.
• 20 Measurements and Events -- connected-mode measurement reporting, and the Rel-16 idle/inactive measurement logging that crosses the boundary.
• 23 Xn Handover -- the procedures §10 reuses: context transfer, key re-derivation and path switch.
• 26 UE Capability -- what is discarded and what is retained across suspension is partly capability-dependent.
• 27 AS Security Mode -- the key hierarchy, K_gNB, the NH chain and the NCC that §9.3 depends on.