RRC Overview in 5G NR

1. What RRC Is For, and What Would Break Without It

Every layer below RRC in the NR access stratum arrives at the UE unconfigured. PHY does not know which bandwidth part to use, MAC does not know which logical channels exist or what their priorities are, RLC does not know whether a bearer is acknowledged or unacknowledged mode, and PDCP does not know its sequence number length or whether to cipher. None of those layers has any way to ask. RRC is the single mechanism that tells them, and it is the only protocol in the access stratum with the authority to do so.

That gives RRC an unusual shape for a protocol. It is not a data transport -- it moves almost no bytes. It is a configuration language with a small transaction protocol wrapped around it. The bulk of TS 38.331 is not procedure text at all; it is roughly 800 pages of ASN.1 describing the configuration a gNB may hand a UE. The procedures that carry that configuration -- setup, reconfiguration, resume, release, re-establishment -- fit into a couple of dozen pages, and are the subject of the companion 15 RRC Procedures.

Three consequences follow, and all three show up in logs:

• RRC is bootstrap-critical. The very first RRC exchange happens before any security context exists, before the UE has a permanent identity, and before any bearer other than a transparent one exists. That is why SRB0 exists at all, and why it is the strange bearer it is (§4).
• RRC is version-critical. A Rel-15 UE and a Rel-18 gNB must interoperate on the very first message. The encoding rules and the extension conventions in §6 to §8 exist entirely to make that work, and when they fail they fail silently.
• RRC is where the NAS rides. The gNB never interprets a NAS message; it copies an octet string from an RRC IE into an NGAP IE and back. That relationship is what makes §13 confusing in practice -- two independent state machines, one carried inside the other.

2. RRC's Responsibilities, and Which Document Covers Each

TS 38.300 clause 7 enumerates the functions. Rather than restate them, here is the same list with a pointer to where in this document set each one is treated in depth, because RRC is broad enough that no single document can carry all of it:

Paging

UEAssistanceInformation

Table 1. RRC functions per TS 38.300 cl. 7, with the companion document that carries each one. This document covers the layer, the encoding and the architecture; the state machine and the procedures have documents of their own.

3. RRC in the Control-Plane Stack

RRC is a layer-3 peer entity: one instance in the UE, one in the gNB-CU-CP. Below it, the control plane reuses exactly the same PDCP, RLC, MAC and PHY entities as the user plane -- with different configuration and, for one bearer, with layers missing.

Two differences from the user plane are worth stating explicitly, because both change what you can conclude from a log:

• There is no SDAP in the control plane. SDAP exists to map QoS flows onto DRBs. Signalling has no QoS flows, so an SRB starts at PDCP.
• RRC messages are never segmented by RLC in a way you can ignore. SRB1-4 run RLC-AM, so a long RRC message is segmented, retransmitted and reassembled below RRC and reaches RRC intact or not at all. But above RLC there is a hard ceiling: PDCP supports a maximum SDU size of 9000 octets TS 38.323, and an RRC message larger than that cannot be sent at all without the RRC-level segmentation of §11.

4. Signalling Radio Bearers: SRB0 Through SRB4

There are five signalling radio bearers in NR and they are not variants of one thing -- each exists to solve a problem the others cannot. The ordering SRB0 -> SRB1 -> SRB2 is a security timeline: SRB0 is the bearer you use when you have nothing, SRB1 is the bearer that carries the transition into having something, and SRB2 is the bearer that exists only once you already have it. SRB3 and SRB4 are later additions with narrower jobs.

Table 2. The five SRBs. Priorities are the default logicalChannelConfig values in TS 38.331 cl. 9.2.1; a gNB may override them per bearer with logicalChannelConfig set to explicitValue.

4.1 Why SRB0 is built the way it is

SRB0 has to work when the UE has no C-RNTI, no security keys, no PDCP state and no configuration beyond what it read from SIB1. Every layer that would need per-UE state is therefore removed: no PDCP means no sequence number to synchronise and no key to have; RLC transparent mode means no header at all, so no reassembly state; and CCCH is a common channel, so no dedicated logical channel needs to have been configured. What is left is a bare octet string handed to MAC.

The cost is that SRB0 messages must be small and are unprotected. Small, because with no RLC segmentation a message must fit one transport block -- which is why RRCSetupRequest is exactly 48 bits and RRCResumeRequest1 exactly 64 (§7). Unprotected, because there is nothing to protect with -- which is why RRCReestablishmentRequest and the resume requests carry a shortMAC-I computed with the old key instead of relying on PDCP integrity (see the companion 16 RLM and RLF for how shortMAC-I is computed).

4.2 Why SRB2 exists at all

SRB1 could carry every NAS message. SRB2 exists for two reasons, and only the second is about security. The first is priority: NAS signalling is not latency-critical in the way RRC signalling is. A large NAS PDU on SRB1 would compete on equal terms with a MeasurementReport or an RRCReconfigurationComplete, and could delay a handover. Putting NAS on a lower-priority logical channel means logical channel prioritisation in MAC drains RRC first TS 38.321 cl. 5.4.3.1 -- see the companion 09 LCP. The second is a structural guarantee: because SRB2 is only ever configured after SecurityModeCommand, anything you see on SRB2 was, by construction, integrity-protected and ciphered. There is no plaintext-on-SRB2 case to reason about.

4.3 SRB3 and the split-signalling case

In NR-DC the UE has two RRC-capable nodes: a Master Node and a Secondary Node. Most signalling goes through the MN, which embeds SN-originated RRC in an MN message. SRB3 short-circuits that: it is a DCCH terminated at the SN, so the SN can reconfigure its own cell group without an MN round trip. It is configured by the MN (srb3-ToRelease / the SN's RRCReconfiguration inside secondaryCellGroup) but keyed by the SN, and it may only carry a restricted subset of messages -- an SN cannot, for example, release the connection.

5. What PDCP Does to an RRC Message

On SRB1-4 the RRC PDU is a PDCP SDU. PDCP prepends a two-octet header carrying a 12-bit sequence number -- SRBs always use a 12-bit SN, there is no 18-bit option as there is for DRBs -- ciphers the data part, and appends a four-octet MAC-I computed over the header and the plaintext data TS 38.323 cl. 6.2.2.1.

6. ASN.1 and Unaligned PER: Why RRC Is Encoded This Way

RRC messages are defined in ASN.1 and encoded with unaligned Packed Encoding Rules ITU-T X.691, as mandated by TS 38.331 clause 8. Unaligned means exactly what it says: fields are packed bit-adjacent with no padding to octet boundaries, anywhere, ever. A 4-bit enumeration followed by a 39-bit bit string followed by a 2-bit choice index occupies 45 consecutive bits starting wherever the previous field ended.

The choice was not arbitrary. Compare the alternatives:

Table 3. Why unaligned PER. The RRCSetupRequest case is the binding constraint: it must fit inside MSG3, which the gNB sizes before it knows anything about the UE. See the companion 03 Random Access.

Three properties of unaligned PER decide everything about how you read RRC in a log:

• You cannot decode a byte without the schema. There is no tag, no length prefix on most fields, and no alignment to anchor on. A one-bit error in your assumed ASN.1 version shifts every subsequent field, and the result is usually a plausible-looking wrong answer rather than a decode failure.
• Field sizes are minimal, not natural. An INTEGER (0..3) is two bits. An ENUMERATED with sixteen members and no extension marker is four bits. A CHOICE with two alternatives costs one bit of index. OPTIONAL fields cost one bit each in a preamble bitmap at the front of the enclosing SEQUENCE.
• Extensibility is bought with open types. A field after an extension marker is encoded as a length-prefixed octet string, so a decoder that does not know the field can still skip exactly the right number of bytes. That is the whole mechanism of §8, and the length prefix is the only place in an RRC message where you get a free anchor.

7. Decoding Unaligned PER by Hand: RRCSetupRequest, Bit by Bit

RRCSetupRequest is the right message to learn on. It is the only RRC message with a genuinely fixed length -- 48 bits, always, by design so that the 48-bit CCCH LCID codepoint and the UE Contention Resolution Identity MAC CE both work -- and it exercises choice indices, bit strings, enumerations and padding in six octets.

UL-CCCH-Message ::= SEQUENCE {
    message        UL-CCCH-MessageType
}

UL-CCCH-MessageType ::= CHOICE {
    c1  CHOICE {
        rrcSetupRequest             RRCSetupRequest,
        rrcResumeRequest            RRCResumeRequest,
        rrcReestablishmentRequest   RRCReestablishmentRequest,
        rrcSystemInfoRequest        RRCSystemInfoRequest
    },
    messageClassExtension  SEQUENCE {}
}

RRCSetupRequest ::= SEQUENCE {
    ue-Identity           InitialUE-Identity,
    establishmentCause    EstablishmentCause,
    spare                 BIT STRING (SIZE (1))
}

InitialUE-Identity ::= CHOICE {
    ng-5G-S-TMSI-Part1    BIT STRING (SIZE (39)),
    randomValue           BIT STRING (SIZE (39))
}

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

Listing 1. Verbatim from TS 38.331 clause 6.2.2, apart from line breaks. Note that RRCSetupRequest has no extension marker -- that is deliberate and is what makes the 48-bit length permanent.

7.1 The bit budget

7.2 The bits themselves

Reading it back out of the six octets 17 E5 43 38 96 E6:

Six octets on the wire:   17 E5 43 38 96 E6

  bit   0        8        16       24       32       40     47
        |        |        |        |        |        |      |
        00010111 11100101 01000011 00111000 10010110 11100110

Field by field, in encoding order:

    bits   n   field
-------- ---   ------------------------------------------------------
       0   1   UL-CCCH-MessageType CHOICE index = 0  -> c1
   1 - 2   2   c1 CHOICE index = 0                   -> rrcSetupRequest
       3   1   InitialUE-Identity CHOICE index = 1   -> randomValue
  4 - 42  39   randomValue = 0 0111 1110 0101 0100 0011 0011 1000
                             1001 0110 111   = 0x3F2A19C4B7
 43 - 46   4   establishmentCause = 3                -> mo-Signalling
      47   1   spare = 0
-------- ---   ------------------------------------------------------
   total  48   = 6 octets exactly, nothing left over

-- Sanity checks that catch a wrong-schema decode:
--   * total length is exactly 6 octets, no more, no less
--   * the spare bit is 0 (a 1 here means you are off by some bits)
--   * establishmentCause index 10..15 are spare6..spare1 and must not
--     appear from a compliant UE

Listing 2. Hand-decoding the six octets. The three sanity checks at the bottom are the practical value of this exercise: they tell you whether your bit offset is right without needing a decoder.

8. Extension Markers, Critical and Non-Critical Extensions

A Rel-15 UE will be handed messages built by Rel-18 gNBs for the next decade. TS 38.331 handles this with three distinct mechanisms, and confusing them is the source of a whole class of interoperability bugs. All three appear in the same messages, and they behave differently on failure.

Table 4. The three forward-compatibility mechanisms in TS 38.331. Only the middle one loses the whole message, and it is the only one that produces no observable error.

8.1 The nonCriticalExtension chain

This is the idiom you will actually see in decoded logs, and it looks strange the first time. Each release appends its new fields inside a new nested SEQUENCE hung off the previous release's nonCriticalExtension, producing a chain that gets one level deeper every release:

RRCReconfiguration-IEs ::= SEQUENCE {
    radioBearerConfig          RadioBearerConfig          OPTIONAL, -- Need M
    secondaryCellGroup         OCTET STRING (CONTAINING CellGroupConfig)
                                                          OPTIONAL, -- Need M
    measConfig                 MeasConfig                 OPTIONAL, -- Need M
    lateNonCriticalExtension   OCTET STRING               OPTIONAL,
    nonCriticalExtension       RRCReconfiguration-v1530-IEs OPTIONAL
}

RRCReconfiguration-v1530-IEs ::= SEQUENCE {
    masterCellGroup            OCTET STRING (CONTAINING CellGroupConfig)
                                                          OPTIONAL, -- Need M
    fullConfig                 ENUMERATED {true}          OPTIONAL, -- Need N
    dedicatedNAS-MessageList   SEQUENCE (SIZE(1..maxDRB)) OF
                                   DedicatedNAS-Message   OPTIONAL, -- Need N
    masterKeyUpdate            MasterKeyUpdate            OPTIONAL, -- Need N
    dedicatedSIB1-Delivery     OCTET STRING (CONTAINING SIB1)
                                                          OPTIONAL, -- Need N
    dedicatedSystemInformationDelivery  OCTET STRING
                                   (CONTAINING SystemInformation)
                                                          OPTIONAL, -- Need N
    otherConfig                OtherConfig                OPTIONAL, -- Need M
    nonCriticalExtension       RRCReconfiguration-v1540-IEs OPTIONAL
}

RRCReconfiguration-v1540-IEs ::= SEQUENCE {
    otherConfig-v1540          OtherConfig-v1540          OPTIONAL, -- Need M
    nonCriticalExtension       RRCReconfiguration-v1560-IEs OPTIONAL
}

-- ... and so on through v1560, v1610, v1640, v1650, v1660, v1700, ...

Listing 3. Abridged from TS 38.331. Note where masterCellGroup lives: in the v1530 extension, not the base IEs. The most important IE in the message is one level down the chain because it was added after the base structure was frozen.

8.2 What a Rel-15 UE does with a Rel-17 IE

Concretely: a Rel-18 gNB sends RRCReconfiguration containing a Rel-17 IE inside nonCriticalExtension -> ... -> RRCReconfiguration-v1700-IEs. A Rel-15 UE decodes the base IEs, reaches nonCriticalExtension, finds its presence bit set, and decodes as far as RRCReconfiguration-v1560-IEs -- the last version it knows. At that point it hits that SEQUENCE's own nonCriticalExtension presence bit, does not recognise the type, and uses the open-type length determinant to step over the remainder. It then applies everything it did understand and answers with RRCReconfigurationComplete. The gNB gets a success it must not over-interpret.

lateNonCriticalExtension is the odd sibling. It is an OCTET STRING rather than a typed SEQUENCE, and exists so a later release can add fields to an earlier release's structure -- a field that logically belongs in the v1530 block but was only invented in Rel-16 goes here. It is rare in practice and, being an octet string, will show up in a log as an undecoded blob unless your decoder has the inner schema.

9. The RRC Message Catalogue, by Direction and Logical Channel

Every RRC message belongs to exactly one of seven top-level PDU types, and the PDU type determines the logical channel, which determines the SRB, which determines the security treatment. Knowing which bucket a message is in tells you, without looking anything up, whether it can be ciphered, whether it can be segmented, and whether it can be lost silently.

BCCH-BCH-Message

BCCH-DL-SCH-Message

PCCH-Message

Paging

DL-CCCH-Message

DL-DCCH-Message

UL-CCCH-Message

UL-CCCH1-Message

UL-DCCH-Message

Table 5. The seven RRC PDU types, TS 38.331 cl. 6.2.1. The CHOICE width column is the number of bits the message-type index costs in unaligned PER, and it is the first thing you decode in any RRC PDU.

The c1 CHOICE in DL-DCCH-MessageType and UL-DCCH-MessageType is full -- sixteen alternatives, four bits, all consumed. Every message added since is reached through messageClassExtension -> c2, a second CHOICE layer:

c2

ULDedicatedMessageSegment

c2

DedicatedSIBRequest

c2

MCGFailureInformation

c2

UEInformationResponse

c2

SidelinkUEInformationNR

c2

ULInformationTransferIRAT

c2

IABOtherInformation

c2

MBSInterestIndication

c2

UEPositioningAssistanceInfo

c2

MeasurementReportAppLayer

Table 6. Messages beyond the first sixteen. The asymmetry is an accident of history: the uplink c1 filled up in Rel-15 and the downlink one did not, so uplink additions are one CHOICE layer deeper. Later Rel-17/18 additions continue in c2.

10. rrc-TransactionIdentifier and Request/Response Correlation

RRC-TransactionIdentifier is an INTEGER (0..3) -- two bits, four values, and that is all the transaction state RRC has. The network picks a value for a downlink message that expects a reply; the UE echoes the same value in the reply. There is no sequence number, no timestamp and no nonce.

RRCRelease

DLInformationTransfer

ULInformationTransfer

MeasurementReport

Table 7. Which messages carry rrc-TransactionIdentifier. The pattern is exact: network-initiated request/response pairs carry it, UE-initiated and unsolicited messages do not.

One further correlation subtlety: the transaction identifier is scoped to the procedure, not to the SRB. A SecurityModeCommand with rrc-TransactionIdentifier = 1 and an RRCReconfiguration with rrc-TransactionIdentifier = 1 are unrelated transactions that happen to share a value, and both may be outstanding simultaneously. Match on message type and identifier, never on identifier alone.

11. RRC Segmentation, and Why Large Reconfigurations Need It

PDCP supports a maximum SDU size of 9000 octets. Until Rel-16, an RRC message larger than that simply could not be delivered. That was tolerable in Rel-15 and stopped being tolerable almost immediately, for two reasons pulling in the same direction:

• The capability response outgrew it. A UE supporting many bands, many band combinations, carrier aggregation, dual connectivity and several feature sets can encode tens of kilobytes into a single UECapabilityInformation. The combinatorics are multiplicative, so this scales badly -- see the companion 26 UE Capability.
• Reconfigurations outgrew it too. An RRCReconfiguration carrying a secondaryCellGroup with many SCells, a large measConfig and a reconfigurationWithSync all in one message is routinely several kilobytes, and a full configuration for an NR-DC UE with dedicated SIB delivery can exceed the limit.

Rel-16 added a segmentation container in each direction: ULDedicatedMessageSegment and DLDedicatedMessageSegment. Both work the same way and both are ordinary RRC messages on SRB1, which is the key structural point -- the segments themselves get RLC-AM delivery guarantees, PDCP ciphering and integrity protection, exactly like any other RRC message.

Table 8. RRC segmentation behaviour. Note the absence of any negative acknowledgement: every failure path here is silent.

12. RRC Across a Split gNB: F1AP, E1AP and What Each Log Shows

In a split deployment the RRC entity does not live in the same box as the radio. TS 38.401 clause 6 defines the split: a gNB-CU hosts RRC and PDCP, one or more gNB-DUs host RLC, MAC and PHY, and the CU is itself optionally split into a gNB-CU-CP (RRC and PDCP-C) and one or more gNB-CU-UPs (SDAP and PDCP-U). This is not an implementation detail you can ignore, because it decides which log file contains which half of the truth.

Table 9. Where RRC appears on each interface. If you are looking for the contents of an RRC message and you only have an F1-U or NG-U capture, you are looking in the wrong place.

12.1 The F1AP RRC message transfer procedures

There are exactly three F1AP procedures whose job is to move an RRC message, plus two UE-context procedures that can carry one as a passenger TS 38.473 cl. 8.4, 8.3:

Table 10. F1AP procedures that carry RRC. The RRC-Container is always an opaque octet string to F1AP -- and on SRB1+ it is a PDCP PDU, not a decodable RRC PDU.

12.2 Who owns which part of the configuration

The division of labour inside masterCellGroup is the part that surprises people. The CU-CP owns the RRC message, but it does not author the lower-layer configuration inside it. The DU does, and the CU-CP copies it in verbatim:

Table 11. Who authors what. A configuration mismatch between the CU's view and the DU's is possible and is the most annoying class of bug in a split gNB, because each side's log looks internally consistent.

13. RRC State, Registration State and Connection Management State

This is the classic confusion in the whole control plane, and it comes from the fact that there are three state machines, not one, in two different specifications, with names that partly overlap:

Table 12. Three state machines. TS 23.501 calls the CM states CM-IDLE and CM-CONNECTED; TS 24.501 calls the same things 5GMM-IDLE and 5GMM-CONNECTED. They are the same states, differently named, which does not help.

The relationship between them is nearly one-to-one but not quite, and the gaps are where the confusion lives:

• Connected does not imply registered. During initial registration the UE is RRC_CONNECTED and 5GMM-DEREGISTERED for the whole time between RRCSetupComplete and Registration Accept. That is normal and it is where the companion 01 Registration Process starts.
• Inactive implies CM-CONNECTED. From the AMF's point of view the UE never left; the N2 association and the UE context in the core are untouched. TS 24.501 names this 5GMM-CONNECTED with RRC inactive indication. This is why suspending a UE to RRC_INACTIVE generates no core-network signalling at all -- which is most of the point of the state.
• Idle with CM-CONNECTED is a transient inconsistency, and it is real. After an RLF the UE goes to RRC_IDLE immediately; the AMF learns nothing until the gNB tells it. During that window the AMF will happily send downlink data that has nowhere to go. This is the window that paging exists to close -- see the companion 19 Paging.
• Identities are per-state and per-layer. In RRC_IDLE the UE has no AS identity at all but retains a NAS 5G-GUTI. In RRC_INACTIVE it has an I-RNTI. In RRC_CONNECTED it has a C-RNTI. The companion 14 RRC States has the full identity table.

14. The RRC Timer Landscape: an Index

RRC's timers are scattered across the procedures they bound, and TS 38.331 clause 7.1 collects them. This is the index; each timer is treated where it does its work.

T300

T301

UE-TimersAndConstants

T302

T304

ReconfigurationWithSync

T310

UE-TimersAndConstants

T311

UE-TimersAndConstants

T319

UE-TimersAndConstants

T320

T380

SuspendConfig

T390

UAC-BarringInfoSet uac-BarringTime

T316

T331

Table 13. The RRC timers, TS 38.331 cl. 7.1. Values are the ASN.1 enumeration members; the configured value is per-cell in UE-TimersAndConstants in SIB1 unless stated otherwise. This table is an index -- each timer's real behaviour is in the companion document named in the last column.

15. Failure Modes and What Each One Means

RRC's failure modes are unusual in one specific way: most of them are silent. There is no general-purpose RRC error message. A UE that cannot make sense of a message discards it and says nothing, and the network learns only from the absence of the expected reply.

Table 14. RRC failure modes. Most of these are invisible on the air. The only explicit negative responses anywhere in RRC are SecurityModeFailure, SCGFailureInformation and MCGFailureInformation -- a reconfiguration the UE cannot apply produces a re-establishment, not a failure message.

16. Configuration and Structure Reference (ASN.1)

16.1 SRB configuration

RadioBearerConfig ::= SEQUENCE {
    srb-ToAddModList          SRB-ToAddModList          OPTIONAL, -- Need N
    srb3-ToRelease            ENUMERATED {true}         OPTIONAL, -- Need N
    drb-ToAddModList          DRB-ToAddModList          OPTIONAL, -- Need N
    drb-ToReleaseList         DRB-ToReleaseList         OPTIONAL, -- Need N
    securityConfig            SecurityConfig            OPTIONAL, -- Need M
    ...
}

SRB-ToAddMod ::= SEQUENCE {
    srb-Identity              SRB-Identity,          -- INTEGER (1..3)
    reestablishPDCP           ENUMERATED {true}         OPTIONAL, -- Need N
    discardOnPDCP             ENUMERATED {true}         OPTIONAL, -- Need N
    pdcp-Config               PDCP-Config               OPTIONAL, -- Need M
    ...,
    [[
    srb-Identity-v1700        SRB-Identity-v1700        OPTIONAL  -- Need N
    ]]                                          -- Rel-17: adds SRB4
}

SecurityConfig ::= SEQUENCE {
    securityAlgorithmConfig   SecurityAlgorithmConfig   OPTIONAL, -- Need M
    keyToUse                  ENUMERATED {master, secondary}
                                                        OPTIONAL, -- Need M
    ...
}

Listing 4. Abridged from TS 38.331. Two things worth noting: srb-Identity is INTEGER (1..3), so SRB4 had to be added by a Rel-17 extension addition group rather than by widening the range -- and there is no srb-ToReleaseList, because SRB1 and SRB2 are never released while the connection lives.

16.2 The extension idiom, in ASN.1

-- 1. Extension marker inside a SEQUENCE.
--    Costs one bit; everything after it is length-prefixed.
SomeConfig ::= SEQUENCE {
    fieldA        INTEGER (0..7),
    ...,                              -- extension marker
    [[                                -- extension addition group
    fieldB-r16    INTEGER (0..15)      OPTIONAL  -- Need R
    ]],
    [[
    fieldC-r17    ENUMERATED {true}    OPTIONAL  -- Need R
    ]]
}

-- 2. Critical extension. If the decoder picks the Future branch it
--    cannot interpret the body at all.
SomeMessage ::= SEQUENCE {
    rrc-TransactionIdentifier  RRC-TransactionIdentifier,
    criticalExtensions         CHOICE {
        someMessage                SomeMessage-IEs,
        criticalExtensionsFuture   SEQUENCE {}
    }
}

-- 3. Non-critical extension chain. Each release hangs its additions
--    off the previous release's nonCriticalExtension.
SomeMessage-IEs ::= SEQUENCE {
    field1                     Field1,
    lateNonCriticalExtension   OCTET STRING              OPTIONAL,
    nonCriticalExtension       SomeMessage-v1610-IEs     OPTIONAL
}

-- Need codes, TS 38.331 cl. 6.1:
--   Need M  absent -> maintain the currently configured value
--   Need N  absent -> no action; the field is a one-shot instruction
--   Need R  absent -> release the corresponding configuration
--   Need S  absent -> the value is specified elsewhere

Listing 5. The three mechanisms side by side, plus the Need codes -- which are the single most important annotation in TS 38.331 and are comments, not ASN.1. They define delta-configuration semantics; the companion 15 RRC Procedures works through what each one means in practice.

17. Illustrative Message Traces

17.1 The same message at four layers

One RRCSetupRequest, seen as the DU's MAC sees it, as the DU's F1AP sees it, as the CU-CP's RRC sees it, and as a decoder sees it. All four views are the same six octets.

09:41:02.118  [DU MAC-UL]  C-RNTI 0x4601  TB 8 octets
              subheader  R/F/LCID = 0/0/52   -- CCCH, 48 bits, no L field
              SDU ...................... 17 E5 43 38 96 E6
              -- RLC-TM: no header, so the SDU is the RLC PDU is the RRC PDU

09:41:02.119  [DU F1AP-TX] INITIAL UL RRC MESSAGE TRANSFER
              gNB-DU UE F1AP ID ........ 41
              NR CGI ................... plmn + nci (cell identity)
              C-RNTI ................... 0x4601
              RRC-Container ............ 17 E5 43 38 96 E6   -- 6 octets
              DU to CU RRC Information
                cellGroupConfig ........ (OCTET STRING, 118 octets)
              SUL Access Indication .... absent

09:41:02.121  [CU-CP F1AP-RX] INITIAL UL RRC MESSAGE TRANSFER
              -> allocate gNB-CU UE F1AP ID 1907
              -> create UE context, bind (1907, 41)
              -> hand RRC-Container to RRC as an SRB0 CCCH PDU

09:41:02.121  [CU-CP RRC]  UL-CCCH-Message decoded
              c1 = rrcSetupRequest
                ue-Identity
                  randomValue .......... 0x3F2A19C4B7      -- 39 bits
                establishmentCause ..... mo-Signalling
                spare .................. 0
              -- 48 bits consumed, 0 remaining: length check passes

Listing 6. The same six octets at four layers. Note that the F1AP RRC-Container here is byte-identical to the MAC SDU, because SRB0 has no PDCP. From RRCSetupComplete onward that stops being true.

17.2 A downlink reconfiguration, with the extension chain visible

09:41:02.284  [CU-CP RRC-DL] DL-DCCH-Message on SRB1, LCID 1
              c1 = rrcReconfiguration
                rrc-TransactionIdentifier ......... 1
                criticalExtensions = rrcReconfiguration
                  radioBearerConfig
                    srb-ToAddModList
                      SRB-ToAddMod  srb-Identity ... 2
                    drb-ToAddModList
                      DRB-ToAddMod
                        cnAssociation = sdap-Config
                          pdu-Session ............. 1
                          sdap-HeaderDL ........... present
                          sdap-HeaderUL ........... present
                          mappedQoS-FlowsToAdd .... { 1 }
                        drb-Identity ............... 1
                        pdcp-Config
                          drb  discardTimer ....... ms100
                               pdcp-SN-SizeUL ..... len18bits
                               pdcp-SN-SizeDL ..... len18bits
                          t-Reordering ............ ms50
                  nonCriticalExtension                -- v1530
                    masterCellGroup ................ (OCTET STRING, 214 octets)
                    dedicatedNAS-MessageList
                      [0] ......................... (NAS PDU, 96 octets)
                    nonCriticalExtension            -- v1540
                      otherConfig-v1540
                        overheatingAssistanceConfig  present

09:41:02.301  [CU-CP RRC-UL] UL-DCCH-Message on SRB1
              c1 = rrcReconfigurationComplete
                rrc-TransactionIdentifier ......... 1   -- matches
              -- transaction 1 closed

Listing 7. masterCellGroup -- the largest and most important IE in the message -- sits two levels down the nonCriticalExtension chain, and otherConfig-v1540 one level below that. Depth here records standardisation history, not importance.

17.3 Two failures, one silent and one loud

10:07:55.402  [CU-CP RRC-DL] DL-DCCH-Message on SRB1
              c1 = ueCapabilityEnquiry
                rrc-TransactionIdentifier ......... 2
                criticalExtensions = criticalExtensionsFuture
                  -- gNB encoded a critical extension this UE does not have

10:07:55.417  [UE RRC]  DL-DCCH-Message received on SRB1, 4 octets
              c1 index .......................... 6 -> ueCapabilityEnquiry
              rrc-TransactionIdentifier ......... 2
              criticalExtensions CHOICE index ... 1 -> criticalExtensionsFuture
              -- TS 38.331 cl. 10: message not comprehended -> ignore it
              -- no response is generated, and no failure is reported

10:07:55.417  ... nothing on SRB1 in either direction ...
10:08:00.402  [CU-CP RRC]  no UECapabilityInformation for transaction 2
              -- gNB-internal guard timer expired after 5000 ms
              -- gNB proceeds with a default capability assumption

-- Contrast with a refused configuration, on a different procedure:
10:12:31.884  [CU-CP RRC-DL] rrcReconfiguration  txn 3
                radioBearerConfig -> drb-ToAddModList -> DRB 2
                  pdcp-Config -> drb -> pdcp-SN-SizeUL len18bits
10:12:31.902  [UE RRC]      cannot comply: 18-bit UL SN is not supported
                            on this band combination
              -> continue with the configuration in force before txn 3
              -> initiate re-establishment       (TS 38.331 cl. 5.3.5.8)
10:12:31.903  [UE RRC-UL]   rrcReestablishmentRequest on SRB0
                            reestablishmentCause reconfigurationFailure
              -- there is NO RRCReconfigurationFailure message in NR.
              -- The re-establishment IS the error report, and the cause
              -- field is the only hint you get.

Listing 8. Two failure paths for comparison. The first produces nothing observable at all; the second produces a re-establishment in some cell, with reestablishmentCause = reconfigurationFailure as the only clue. Neither tells you which field was the problem.

17.4 A segmented uplink capability response

10:22:14.006  [CU-CP RRC-DL] ueCapabilityEnquiry  txn 0
                ue-CapabilityRAT-RequestList
                  [0] rat-Type ............ nr
                  [1] rat-Type ............ eutra-nr
                  [2] rat-Type ............ eutra

10:22:14.188  [UE RRC]  encoded UECapabilityInformation = 12418 octets
              -- exceeds the 9000-octet PDCP SDU limit
              -- ul-RRC-Segmentation supported -> segment at 6144 octets

10:22:14.190  [RRC-UL] ulDedicatedMessageSegment  (c2, Rel-16)
                segmentNumber ..................... 0
                rrc-MessageSegmentType ............ notLastSegment
                rrc-MessageSegmentContainer ....... 6144 octets
10:22:14.226  [RRC-UL] ulDedicatedMessageSegment
                segmentNumber ..................... 1
                rrc-MessageSegmentType ............ notLastSegment
                rrc-MessageSegmentContainer ....... 6144 octets
10:22:14.241  [RRC-UL] ulDedicatedMessageSegment
                segmentNumber ..................... 2
                rrc-MessageSegmentType ............ lastSegment
                rrc-MessageSegmentContainer ....... 130 octets

10:22:14.242  [CU-CP RRC] reassembled 6144+6144+130 = 12418 octets
              PER-decode as UL-DCCH -> c1? no -> messageClassExtension
                                       -> c2 -> ueCapabilityInformation
                rrc-TransactionIdentifier ......... 0   -- matches the enquiry
                ue-CapabilityRAT-ContainerList ..... 3 containers

Listing 9. A three-segment capability response. The transaction identifier lives in the reassembled message, not in the segments -- so until reassembly completes there is nothing to correlate the segments against, which is why interleaving two segmented messages is unrecoverable.

17.5 The RRC / NAS state mismatch after RLF

11:03:47.551  [UE RRC]   T310 expired -> Radio Link Failure declared
              RRC state ......... RRC_CONNECTED -> (re-establishment)
              5GMM state ........ 5GMM-REGISTERED, 5GMM-CONNECTED  (unchanged)
11:03:47.551  [UE RRC]   T311 started (ms10000), cell selection begins

11:03:47.560  [CU-CP]    UE 1907: no uplink for 9 ms; RLC max retx not yet hit
              -- the gNB does not yet know anything is wrong
11:03:47.560  [AMF]      UE is CM-CONNECTED; downlink NAS may still be sent

11:03:52.118  [UE RRC]   T311 expired, no suitable cell found
              -> to RRC_IDLE, release cause = rrc-Connection-Failure
              -> RLF report stored for later retrieval
              5GMM state ........ still 5GMM-REGISTERED, 5GMM-CONNECTED

11:03:54.900  [CU-CP]    RLC max retransmissions on SRB1 -> UE unreachable
11:03:54.901  [CU-CP]    NGAP UE CONTEXT RELEASE REQUEST, cause = radio
                         connection with UE lost
11:03:54.930  [AMF]      NGAP UE CONTEXT RELEASE COMMAND
              -- AMF now moves the UE to CM-IDLE. Mismatch window: ~7.4 s

11:04:09.220  [UE RRC]   RRCSetupRequest, establishmentCause mo-Signalling
                         (NAS Service Request follows in RRCSetupComplete)

Listing 10. Seven and a half seconds during which the UE is in RRC_IDLE and the AMF believes it is CM-CONNECTED. Downlink data arriving in that window is buffered or discarded with no indication to anyone. This is a normal consequence of two state machines, not a fault.

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

Table 15. RRC changes by release. Feature presence must always be confirmed against the capability exchange rather than inferred from a successful reconfiguration -- see the companion 26 UE Capability.

19. Reading RRC in Logs: A Checklist

1. Establish which log you are holding. A DU log has timing, sizes and scheduling but no RRC message bodies once security is on. A CU-CP log has bodies but timestamps that do not line up with radio events. Decide which question you are answering before you start reading (§12).

2. Build the identifier map first. From the INITIAL UL RRC MESSAGE TRANSFER, record the (gNB-CU UE F1AP ID, gNB-DU UE F1AP ID, C-RNTI) triple. The C-RNTI disappears from F1AP after that message; the F1AP ID pair is the only identifier present in both logs.

3. Read the SRB, not just the message. SRB0 means no security and a message you can decode in full anywhere. SRB1 means the container is a PDCP PDU. SRB2 means the message is NAS and, by construction, was protected. SRB3 means the SN's keys, not the MN's (§4).

4. Check the integrity trailer at the security boundary. A zeroed MAC-I before SecurityModeComplete is correct. The first non-zero one is your landmark for where AS security actually took effect (§5).

5. Match every request to its response by transaction identifier *and* message type. There are only four rrc-TransactionIdentifier values. If a Complete cannot be attributed, look for identifier reuse across multiple outstanding transactions -- there are only four values (§10).

6. When a reply is missing, name the timer. RRC has no general error message, so a missing reply plus an expired timer is the error. Use the index in §14 to find which timer bounds the procedure you are watching.

7. Distinguish the three silent failures. A PER decode failure, a criticalExtensionsFuture selection and a segment reassembly gap all look identical from outside: nothing happens. Tell them apart by checking (a) the container length against the encoder's, (b) the criticalExtensions CHOICE index in the encoded message, (c) the segmentNumber sequence (§15).

8. Do not read a successful Complete as full compliance. The UE applied what it understood. Check the capability exchange before concluding a Rel-16 or Rel-17 feature is active (§8.2).

9. Read extension depth as history, not importance. masterCellGroup sits two levels down inside nonCriticalExtension and is the most important IE in the message (§8.1).

10. Keep the RRC and 5GMM state machines in separate columns. An RRC_IDLE UE that the AMF still believes is CM-CONNECTED is normal for several seconds after an RLF. Do not chase it as a bug (§13).

20. Glossary

nonCriticalExtension

MAC-I

rrc-TransactionIdentifier

RRC-Container

21. References

• 3GPP TS 38.331 -- NR Radio Resource Control (RRC) protocol specification. Clause 4.2.1 (RRC states), 4.2.2 (signalling radio bearers), 6.1 (general and the Need codes), 6.2.1 (message class definitions and the seven PDU types), 6.2.2 (message definitions, including RRCSetupRequest and RRCReconfiguration), 6.3.2 (RadioBearerConfig, SRB-ToAddMod, SecurityConfig), 7.1 (UE timers and constants), 8 (protocol data units and encoding), 9.2.1 (default SRB configurations), 10 (handling of unknown, unforeseen and erroneous protocol data).
• 3GPP TS 38.300 -- NR and NG-RAN overall description. Clause 7 (RRC functions and states), clause 6 (protocol stack and bearers).
• 3GPP TS 38.323 -- PDCP specification. Clause 6.2.2.1 (Control plane PDCP Data PDU format), clause 6.3.4 (MAC-I), and the maximum supported PDCP SDU size.
• 3GPP TS 38.322 -- RLC specification. Transparent mode (used by SRB0) and acknowledged mode (used by SRB1-4).
• 3GPP TS 38.321 -- MAC specification. Clause 5.4.3.1 (logical channel prioritisation, which is what SRB priorities feed), Tables 6.2.1-1 and 6.2.1-2 (LCID codepoints for DL-SCH and UL-SCH).
• 3GPP TS 38.401 -- NG-RAN architecture description. Clause 6 (functional split, F1 and E1, and the RRC message transfer flows).
• 3GPP TS 38.473 -- F1 application protocol (F1AP). Clause 8.3 (UE context management) and clause 8.4 (RRC message transfer).
• 3GPP TS 38.463 -- E1 application protocol (E1AP). Bearer context management.
• 3GPP TS 38.413 -- NG application protocol (NGAP). NAS transport and UE context release.
• 3GPP TS 38.423 -- Xn application protocol (XnAP). RRC containers during handover and UE context retrieval.
• 3GPP TS 24.501 -- Non-Access-Stratum (NAS) protocol for 5G System. Clause 5.1.2 (registration management states), 5.1.3 (connection management states, including 5GMM-CONNECTED with RRC inactive indication).
• 3GPP TS 23.501 -- System architecture for the 5G System. Clause 5.3.2 and 5.3.3 (RM and CM states, under the CM-IDLE / CM-CONNECTED naming).
• ITU-T X.680 / X.691 -- ASN.1 notation and Packed Encoding Rules. X.691 is the normative definition of unaligned PER, including open types, length determinants and extension additions.

Companion documents in this set

• 14 RRC States -- the state machine this document only sketches: every state in depth, every transition, suspendConfig, RAN notification areas and context fetch over Xn.
• 15 RRC Procedures -- the procedure-by-procedure reference, including delta configuration worked through with add/mod/release lists.
• 01 Registration Process -- what the NAS payload inside RRCSetupComplete goes on to do, and the security activation timeline SRB0 -> SRB1 -> SRB2 mirrors.
• 06 Channel Mapping -- the CCCH / DCCH / DTCH to transport channel chain below the stack in §3.
• 07 MAC PDU and Control Elements -- the LCID codepoint space and the subheader shapes that carry CCCH and DCCH.
• 09 LCP -- logical channel prioritisation, which is what the SRB priorities in §4 actually feed.
• 16 RLM and RLF -- shortMAC-I, re-establishment, and the RLF report that UEInformationRequest retrieves.
• 17 System Information / 18 MIB and SIB1 IEs -- the broadcast side of RRC, including UE-TimersAndConstants and the UAC barring configuration behind T390.
• 19 Paging -- how the network reaches a UE in the states where RRC has no dedicated channel to it.
• 20 Measurements and Events -- measConfig and MeasurementReport, the largest single consumer of RRCReconfiguration.
• 22-25 Handover family -- reconfigurationWithSync, T304, and the Xn and NG signalling that wraps them.
• 26 UE Capability -- why UECapabilityInformation needs segmentation, and why a capability bit is the only reliable proof a feature is active.
• 27 AS Security Mode -- SecurityModeCommand, the keys behind the MAC-I in §5, and what keyToUse selects.