RRC Resume / Small Data Transmission — Lightweight Return from RRC Inactive¶

Learning objectives¶

• Explain the three-state model of RRC (RRC_IDLE / RRC_INACTIVE / RRC_CONNECTED).
• Accurately explain the relationship that when in RRC_INACTIVE, from the core's viewpoint the UE remains CM-CONNECTED.
• Explain the flow of the RRC Resume procedure (present I-RNTI → restore UE context → Path Switch only when necessary).
• Explain, as concepts, the positioning of Small Data Transmission (SDT, Rel-17) and its two schemes CG-SDT / RA-SDT.
• Explain the difference from the radio-led lightweight return that the sister page Service Request marked as "out of scope."
• Compare the point that EPC (4G/LTE) has no RRC_INACTIVE state, and the similarity with LTE's Suspend/Resume and EDT (to be confirmed).

Prerequisites¶

• Service Request — full connection resumption from CM-IDLE. The direct sister of this chapter.
• Paging — the foundation for understanding the difference between core-originated Paging and RAN Paging.
• PDU Session — the prerequisite for the U-Plane path (N3).
• Registration — the prerequisite for CM states and registration.
• N2 / N3 — the interfaces between the core and the (R)AN.
• AMF — the core NF that manages the UE context and CM state.

What you'll learn in this chapter¶

In scope: the RRC three-state model, the relationship between RRC_INACTIVE and the core's CM-CONNECTED, the conceptual flow of the RRC Resume procedure, the positioning of SDT (the two schemes CG-SDT / RA-SDT, concept only), the difference from the Service Request chapter, and the EPC comparison. The focus is on the involvement and impact as seen from the core (5GC).

Out of scope: the bit-level details of RRC messages, the state-transition decision algorithms inside the RAN, and the radio physical-layer / scheduling details of SDT. These are radio (RAN) led, and since this site is a 5GC core textbook, they are kept at the conceptual level plus to be confirmed.

Why — why RRC Inactive / RRC Resume is necessary¶

Smartphones and IoT terminals repeat a behavior of frequently exchanging small amounts of traffic and then resting. Here, if the UE shuttles between CM-IDLE ↔ CM-CONNECTED every time and re-establishes the connection with a full Service Request (see Service Request), then re-establishing NAS/NGAP, re-establishing AS security, and so on make the signaling heavy and increase the terminal's power consumption.

So 5G introduced an intermediate state called RRC_INACTIVE. It puts only the radio side into a light suspension, while keeping the connection as seen from the core (CM-CONNECTED / N2 / UE context) maintained. On return, the UE can go back to RRC_CONNECTED lightly with RRC Resume. Furthermore, Rel-17's Small Data Transmission (SDT) dispenses with even full connection establishment when merely sending a small amount of data.

Analogy: RRC_IDLE is the state of "having checked out of the hotel and taken all your luggage home." To stay again, you need the full procedure at the front desk (Service Request). RRC_INACTIVE is the state of "going out without checking out, having only deposited your room key card." When you come back, just showing the I-RNTI (= the key card) lets you return to your room quickly (RRC Resume). SDT is the image of a lightness like "handing over just the luggage in the lobby without stopping by the front desk."

Overview¶

flowchart LR
  A["UE (RRC_INACTIVE / CM-CONNECTED)"] --> B{"How much data to send?"}
  B -->|Small| C["SDT: CG-SDT / RA-SDT
(sends while in RRC_INACTIVE, to be confirmed)"]
  B -->|Normal| D["RRC Resume
RRC_INACTIVE → RRC_CONNECTED"]
  D --> E["Path Switch only when necessary (N2/N3 update)"]
  C -.->|If not applicable| D

Basic Concept — a beginner-friendly explanation¶

1. The RRC three-state model¶

The RRC of 5G NR has three states.

• RRC_IDLE: no radio connection. Return requires RRC Setup (full). Broadly corresponds to CM-IDLE in the core.
• RRC_INACTIVE: the radio is suspended but the gNB retains the UE context. In the core it remains CM-CONNECTED.
• RRC_CONNECTED: radio connection present, communicating normally. In the core it is CM-CONNECTED.

2. RRC_INACTIVE and the core's CM-CONNECTED¶

This is the most important point of this chapter. When in RRC_INACTIVE, from the core's (AMF's) viewpoint the UE remains CM-CONNECTED, and the N2/NGAP connection and the UE context are maintained. Only the radio side enters a light suspension.

• The gNB retains the UE context, and the UE can move within a RAN Notification Area (RNA) without core Paging.
• For movement across RNA boundaries, an RNAU (RAN Notification Area Update) is performed.
• Incoming reachability is done not by core-originated Paging but by RAN Paging (gNB-led) (details are radio led, to be confirmed).

3. RRC Resume and Small Data Transmission¶

• RRC Resume: the UE presents an I-RNTI, and the gNB restores the UE context (held locally, or obtained from the old gNB over Xn) and returns to RRC_CONNECTED.
• SDT (Small Data Transmission, Rel-17): an extension that sends small data lightly without fully transitioning to RRC_CONNECTED. There are two schemes, CG-SDT (Configured Grant based) and RA-SDT (Random Access based) (radio led; details to be confirmed).

Architecture¶

flowchart TB
  UE["UE (RRC_INACTIVE)"] -->|"Uu: RRC (radio)"| GNBc["gNB (current)"]
  GNBc -.->|"Xn: Retrieve UE Context (when necessary)"| GNBl["gNB (last serving)"]
  GNBc -->|"N2: NGAP (Path Switch only when necessary)"| AMF["AMF"]
  GNBc -->|"N3: GTP-U (path update when necessary)"| UPF["UPF"]
  AMF -->|"control"| UPF

  classDef core fill:#d5f5e3,stroke:#1e8449,color:#145a32;
  class AMF,UPF core;

Key point: core involvement is minimal. The N2/N3 update happens only when necessary (e.g. when returning at a gNB different from the old one and switching the U-Plane path). If the UE context is not at the current gNB, it is obtained from the last serving gNB via Xn: Retrieve UE Context (RAN-deployment dependent, to be confirmed).

Network Function (the NFs that appear)¶

Interface / Protocol¶

Procedure — Call Flow¶

sequenceDiagram
  participant UE as UE
  participant GC as gNB (current)
  participant GL as gNB (last serving)
  participant AMF as AMF
  participant UPF as UPF

  Note over UE,GC: UE is RRC_INACTIVE / core is CM-CONNECTED
  UE->>GC: RRC Resume Request (present I-RNTI)
  Note right of GC: TS 38.331 (to be confirmed)
  alt UE context held by current gNB
    GC->>GC: Restore context locally
  else Return at a different gNB
    GC->>GL: Xn: Retrieve UE Context Request
    Note right of GL: TS 38.423 XnAP (to be confirmed)
    GL-->>GC: Retrieve UE Context Response
  end
  GC->>UE: RRC Resume
  UE->>GC: RRC Resume Complete
  opt U-Plane path update only when necessary
    GC->>AMF: NGAP Path Switch Request
    Note right of AMF: TS 38.413 (to be confirmed)
    AMF->>UPF: N3 path update (via N4, when necessary)
    AMF-->>GC: NGAP Path Switch Request Ack
  end
  Note over UE,GC: UE moves to RRC_CONNECTED

Step-by-step explanation

1. RRC Resume Request: the UE requests return from RRC_INACTIVE and presents its I-RNTI to let itself be identified against its context.
2. UE context restoration: if the current gNB holds it, restore locally. If not, obtain it from the last serving gNB via Xn: Retrieve UE Context.
3. RRC Resume: the gNB accepts the return and returns the information needed to resume the AS (radio led; details to be confirmed).
4. RRC Resume Complete: the UE notifies of return completion. At this point it is RRC_CONNECTED.
5. Path Switch (only when necessary): when returning at a different gNB and the U-Plane path changes, the N3 path of the AMF/UPF is updated via NGAP Path Switch.

SDT (concept only, small flow)

sequenceDiagram
  participant UE as UE
  participant GC as gNB
  Note over UE,GC: UE remains in RRC_INACTIVE (to be confirmed)
  alt CG-SDT
    UE->>GC: Send small data on the Configured Grant
  else RA-SDT
    UE->>GC: Send piggybacked on the Random Access procedure
  end
  GC-->>UE: Response / additional exchange (scheme dependent, to be confirmed)

There are two schemes, CG-SDT (uses a pre-allocated Configured Grant) and RA-SDT (piggybacks on Random Access). Both are radio led and their details are to be confirmed. The scope of impact on the core (5GC) is also to be confirmed.

Signal Flow¶

State Machine¶

stateDiagram-v2
  [*] --> RRC_IDLE
  RRC_IDLE --> RRC_CONNECTED: RRC Setup (full)
  RRC_CONNECTED --> RRC_INACTIVE: gNB suspends
  RRC_INACTIVE --> RRC_CONNECTED: RRC Resume
  RRC_INACTIVE --> RRC_IDLE: release / timer expiry
  RRC_CONNECTED --> RRC_IDLE: RRC Release

The core CM-state mapping for each state:

• RRC_IDLE … the core is broadly CM-IDLE. Return is via a full Service Request.
• RRC_INACTIVE … the core is CM-CONNECTED (N2/UE context maintained). This is the new 5G state.
• RRC_CONNECTED … the core is CM-CONNECTED, communicating normally.

Packet Analysis (Wireshark)¶

Key Display Filters¶

Points to note when decoding¶

• Whether Path Switch family messages appear in NGAP tells you whether there is core involvement (N2/N3 update).
• Check inter-gNB context transfer with the XnAP Retrieve UE Context family (to be confirmed).

The message nesting structure¶

• N2: SCTP → NGAP. N3: UDP → GTP-U → inner IP. Xn: SCTP → XnAP (to be confirmed).

The radio segment (RRC/Uu) is usually hard to capture = implementation dependent. RRC messages such as RRC Resume Request do not appear in a typical core-side capture.

Configuration¶

Only the structural level is shown. The decision to transition to RRC_INACTIVE, the RNA configuration, the inactivity timer, and the SDT-related timers are radio-side / implementation dependent, and the core-side configuration is limited (equivalent to RRC Inactive assistance information, to be confirmed).

Trouble Shooting¶

Comparison with EPC¶

Release differences¶

3GPP Specification¶

FAQ¶

Summary¶

• RRC has three states, RRC_IDLE / RRC_INACTIVE / RRC_CONNECTED, and RRC_INACTIVE is a new 5G state.
• When in RRC_INACTIVE, from the core's viewpoint the UE remains CM-CONNECTED, and the N2/UE context is maintained.
• RRC Resume is a lightweight return: present I-RNTI → restore UE context (local or Xn retrieval) → Path Switch only when necessary.
• SDT (Rel-17) is a signaling-saving extension that sends small data without full connection establishment (CG-SDT / RA-SDT; details to be confirmed).
• RRC / RRC Resume / SDT are radio (RAN) led, and core involvement is minimal. Specific values are to be confirmed.

Reference specs (section numbers are to be confirmed): TS 38.331 / TS 38.300 / TS 23.501 §5.3 series / TS 23.502 / TS 38.423 / TS 38.413.

Practice — comprehension check and exercises¶

Comprehension check¶

Exercises¶

The main RRC Resume steps below have been shuffled. Reorder them into the correct sequence.

A. RRC Resume Complete
B. RRC Resume Request (present I-RNTI)
C. N3 path update via NGAP Path Switch, only when necessary
D. UE context restoration (local or Xn retrieval)
E. RRC Resume

Next Step¶

• Service Request — the direct sister (full return from CM-IDLE).
• Paging — the contrast between core Paging and RAN Paging.
• PDU Session — the prerequisite for the U-Plane path.
• Related NFs: AMF / SMF / UPF
• Related IFs: N2 / N3
• Dictionaries: Message Dictionary / Timer Dictionary / Cause Dictionary / Protocol Dictionary / NF Dictionary / Interface Dictionary