RRC — Radio resource control — the configuration protocol
The protocol stack
Where it sits
What it is
What it is. The control-plane protocol that configures everything else. TS 38.331, and at 1 884 pages it is the largest specification this folder touches by a wide margin.
Why it matters to a physical-layer reader: almost every parameter named in the other notes —
dmrs-AdditionalPosition, mcs-Table, rateMatchPattern, nrofHARQ-ProcessesForPDSCH,
cqi-Table, csi-InferencePrediction-r19 — is defined in TS 38.331, not in the physical-layer
specifications that use them. TS 38.214 says what a parameter does; TS 38.331 says what values it
may take and how it is signalled.
The three states, from TS 38.300 clause 7.2:
| State | Who pages the device | Context stored? | What the radio is doing |
|---|---|---|---|
| RRC_IDLE | The core network (5GC) | No | Cell re-selection, system information, DRX configured by NAS. No connection exists. |
| RRC_INACTIVE | The radio network (RAN paging) | Yes — the UE Inactive AS context is kept in NG-RAN and the UE | Cell re-selection within a RAN notification area; the 5GC connection stays up. Small transmissions possible without resuming fully. |
| RRC_CONNECTED | — | Yes | Unicast transfer, network-controlled mobility with measurements. Everything in the other notes assumes this state. |
RRC_INACTIVE is the state worth understanding, because it exists for the traffic pattern that broke LTE's assumptions: a device that sends a little, often. Full idle-to-connected setup costs signalling and time; staying connected costs battery. Keeping the context on both sides and resuming it is the compromise, and it is why the state was added.
Read on
This concept was first written up in ref-stack, which reads the whole group as one argument.
Before this concept, the hierarchy says to learn the following — the full chain, in order: