RRC Connection Procedures in 5G NR

1. What an RRC Procedure Is, and the Shape They All Share

TS 38.331 organises its normative behaviour into procedures, and almost every one of them has the same five parts. Learning the shape once means you can read a procedure you have never seen before and know what questions to ask of it:

Table 1. The anatomy of an RRC procedure. Every section from §3 to §13 is organised around these five questions.

Two structural facts about RRC procedures are worth stating before any specific one. First, almost all of them are network-initiated. The UE initiates exactly four: establishment, resume, re-establishment, and the unsolicited reports (MeasurementReport, UEAssistanceInformation, FailureInformation, SCGFailureInformation). Everything else starts at the gNB. Second, there is almost no way to say no. There is no reconfiguration failure message in NR at all: a UE that cannot apply an RRCReconfiguration received on SRB1 reverts to its previous configuration and initiates re-establishment TS 38.331 cl. 5.3.5.8, so the way you learn that a reconfiguration was refused is that the connection restarts. The only explicit negative responses anywhere in the protocol are SecurityModeFailure, SCGFailureInformation and MCGFailureInformation.

2. The Master Message Table

Every RRC message, with the four facts you need before you can read it in a log: which direction it travels, which logical channel and SRB carry it, which procedure owns it, and which timer it starts or stops. Downlink first.

MIB

Paging

RRCSetup

RRCReject

RRCResume

RRCRelease

RRCReestablishment

RRCReconfiguration

SecurityModeCommand

UECapabilityEnquiry

UEInformationRequest

CounterCheck

MobilityFromNRCommand

DLInformationTransfer

DLInformationTransferMRDC

DLDedicatedMessageSegment

LoggedMeasurementConfiguration

Table 2. Downlink RRC messages. Note that only two messages ever travel on DL-CCCH, and both of them are answers to a CCCH request (§9).

RRCSetupRequest

RRCResumeRequest

RRCResumeRequest1

RRCReestablishmentRequest

RRCSystemInfoRequest

RRCSetupComplete

RRCResumeComplete

RRCReestablishmentComplete

RRCReconfigurationComplete

SecurityModeComplete

SecurityModeFailure

UECapabilityInformation

UEInformationResponse

CounterCheckResponse

MeasurementReport

UEAssistanceInformation

FailureInformation

SCGFailureInformation

MCGFailureInformation

ULInformationTransfer

ULDedicatedMessageSegment

MeasurementReportAppLayer

DedicatedSIBRequest

LocationMeasurementIndication

Table 3. Uplink RRC messages. Only five travel on CCCH, all five are fixed-length or nearly so, and all five are sent before the UE has a usable dedicated channel.

3. RRC Connection Establishment

Table 4. RRC connection establishment, TS 38.331 clause 5.3.3.

The interesting field is establishmentCause, because it is the only thing the network knows about the UE's intent before any NAS message arrives, and it drives admission control and prioritisation:

emergency

highPriorityAccess

mt-Access

mo-Signalling

mo-Data

mo-VoiceCall

mps-PriorityAccess

mcs-PriorityAccess

Table 5. EstablishmentCause, TS 38.331 clause 6.3.2. Sixteen enumerated values, four bits, no extension marker -- so the set is frozen for the life of the release.

One structural detail that matters when reading a split-gNB log: RRCSetup is built by the gNB-CU-CP but its masterCellGroup is authored by the gNB-DU and copied in verbatim. A malformed cell group in an RRCSetup is therefore a DU-side problem visible only in a CU-side decode. The companion 13 RRC Overview §12.2 has the full division of labour.

4. RRC Connection Resume

Table 6. RRC connection resume, TS 38.331 clause 5.3.13.

Resume is covered in depth in the companion 14 RRC States, including the key re-derivation, the RAN Notification Area, and the context fetch over Xn when the UE resumes at a different gNB. Two procedure-level points belong here.

A resume response may carry a full configuration. RRCResume is not obliged to restore the stored context unchanged. It can contain a radioBearerConfig, a masterCellGroup and a measConfig, and it can carry fullConfig, which tells the UE to throw the stored configuration away entirely and treat the message as absolute (§8.4). A network that has changed its bearer configuration since the UE was suspended uses exactly this.

The response arrives on SRB1, already protected. The UE restores SRB1 and derives the new keys before it has any response, which is why RRCResume and RRCRelease can be delivered protected on SRB1 while RRCSetup and RRCReject arrive in the clear on SRB0. In a log, the SRB the answer arrives on is a one-glance verdict on whether the stored context was used at all.

5. RRC Connection Release

Table 7. RRC connection release, TS 38.331 clause 5.3.8.

The three steering IEs are worth recognising in a log because each has an effect that outlives the connection by minutes:

redirectedCarrierInfo

cellReselectionPriorities

deprioritisationReq

suspendConfig

Table 8. The four optional IEs of RRCRelease. A release with none of them is a plain release; a release with all four is a mobility policy.

6. RRC Connection Re-establishment

Table 9. RRC connection re-establishment, TS 38.331 clause 5.3.7.

reestablishmentCause has four codepoints -- reconfigurationFailure, handoverFailure, otherFailure and one spare -- so two bits. It is coarse on purpose: the detail lives in the RLF report the UE stores and later surrenders (§12), not in the request it sends before security is available. The 48-bit budget of the request and the shortMAC-I computation are worked through in the companion 16 RLM and RLF §9.

7. RRC Reconfiguration: the Big One

Table 10. RRC reconfiguration, TS 38.331 clause 5.3.5. One message, essentially unlimited scope.

7.1 The IE tree

radioBearerConfig

masterCellGroup

secondaryCellGroup

measConfig

masterKeyUpdate

fullConfig

dedicatedNAS-MessageList

otherConfig

conditionalReconfiguration

Table 11. The IEs of RRCReconfiguration that carry real intent. The Authored by column is what makes reconfiguration bugs hard in a split gNB: one message, three authors.

7.2 The two halves of a bearer change

A single logical change -- "add a DRB" -- requires edits in two different IEs authored by two different nodes. radioBearerConfig carries the PDCP and SDAP configuration and the DRB identity; masterCellGroup -> rlc-BearerToAddModList carries the RLC configuration and the logical channel, with a servedRadioBearer field pointing back at the DRB identity. The two must agree, and nothing in the protocol checks that they do.

7.3 reconfigurationWithSync

This is the only IE in RRC that makes a UE change cell. It lives deep: masterCellGroup -> spCellConfig -> reconfigurationWithSync. Its presence changes the whole character of the procedure -- the UE resets MAC, re-establishes PDCP and RLC, applies a new C-RNTI, runs random access on the target, and sends its RRCReconfigurationComplete in the target cell.

spCellConfigCommon

ServingCellConfigCommon

newUE-Identity

t304

ENUMERATED {ms50, ms100, ms150, ms200, ms500, ms1000, ms2000, ms10000}

rach-ConfigDedicated

smtc

SSB-MTC

Table 12. ReconfigurationWithSync, TS 38.331 clause 6.3.2. Note that newUE-Identity and t304 are mandatory -- there is no cell-change without a pre-assigned identity and a deadline.

7.4 What the first octet tells you

8. Delta Configuration: Add, Modify, Release and the Need Codes

RRC configuration is a delta protocol. An RRCReconfiguration does not describe the configuration the UE should have; it describes the change from the configuration the network believes the UE already has. Two mechanisms express that delta, and misunderstanding either produces bugs that surface several messages later.

8.1 The list mechanism

Every collection in RRC configuration is expressed as a pair of lists: an add-or-modify list keyed by an identity, and a release-or-remove list of bare identities. The rules are simple and the consequences are not:

1. Release lists are processed first. Within each list-based IE the UE handles the ToReleaseList or ToRemoveList before the ToAddModList TS 38.331 cl. 5.3.5.5, 5.3.5.6, 5.5.2. Releasing and re-adding the same identity in one message is therefore a legal, well-defined way to replace an object.

2. An entry in an add-or-modify list whose identity already exists is a modification, not a replacement. Fields present in the entry are applied; fields absent from it follow their own Need codes. It is not a clean slate.

3. An identity absent from both lists is untouched. This is the default and it is why a reconfiguration that adds one bearer can be eighty octets rather than two thousand.

4. The naming is inconsistent across the spec. radioBearerConfig and CellGroupConfig use ToReleaseList; measConfig uses ToRemoveList. Grepping for the wrong one is a genuine and common waste of an afternoon.

8.2 The Need codes

The list mechanism handles collections. Individual optional fields are governed by Need codes, which are ASN.1 comments in TS 38.331 and carry no encoding at all -- they exist only in the specification text, and they define what the absence of a field means:

Table 13. The Need codes, TS 38.331 clause 6.1. These are comments in the ASN.1 and are the entire definition of delta semantics. Two fields side by side in the same SEQUENCE can behave completely differently when absent.

8.3 A worked example

This is where delta configuration is best understood: one starting configuration, one message, and the resulting configuration worked out field by field. Start with a UE that has three DRBs and three measurement identities.

SRBs .................. SRB1, SRB2

DRBs
  DRB 1   pdu-Session 1, QoS flow 1   pdcp: discardTimer ms100,
                                            SN-SizeUL/DL len18bits
  DRB 2   pdu-Session 1, QoS flow 2   pdcp: discardTimer ms50,
                                            SN-SizeUL/DL len12bits
  DRB 3   pdu-Session 2, QoS flow 5   pdcp: discardTimer infinity,
                                            SN-SizeUL/DL len18bits

RLC bearers (in masterCellGroup)
  LCID 4 -> DRB 1     LCID 5 -> DRB 2     LCID 6 -> DRB 3

measConfig
  measObjectId 1   NR, ARFCN 632628 (f1)
  measObjectId 2   NR, ARFCN 646666 (f2)
  reportConfigId 1 eventA3, offset 3 dB, hysteresis 1 dB, TTT 320 ms
  reportConfigId 2 eventA2, threshold -110 dBm
  measId 1  ->  measObjectId 1,  reportConfigId 1
  measId 2  ->  measObjectId 2,  reportConfigId 1
  measId 3  ->  measObjectId 1,  reportConfigId 2

Listing 1. The starting configuration. Everything below is expressed relative to this.

Now the reconfiguration. Note how little it says:

RRCReconfiguration
  rrc-TransactionIdentifier ......... 2
  radioBearerConfig
    drb-ToReleaseList ............... { 2 }
    drb-ToAddModList
      DRB-ToAddMod
        drb-Identity ................ 3        -- exists -> MODIFY
        pdcp-Config
          drb  discardTimer ......... ms100    -- was infinity
               headerCompression ... notUsed
          -- pdcp-SN-SizeUL/DL absent: Cond Setup, so KEPT at len18bits
      DRB-ToAddMod
        drb-Identity ................ 4        -- new -> ADD
        cnAssociation = sdap-Config
          pdu-Session ............... 2
          sdap-HeaderDL/UL .......... present
          mappedQoS-FlowsToAdd ...... { 6 }
        pdcp-Config
          drb  discardTimer ......... ms100
               pdcp-SN-SizeUL/DL .... len18bits   -- mandatory at setup
               headerCompression ... notUsed
  nonCriticalExtension
    masterCellGroup
      rlc-BearerToReleaseList ....... { 5 }     -- the other half of
                                                -- releasing DRB 2
      rlc-BearerToAddModList
        RLC-BearerConfig  logicalChannelIdentity 7
                          servedRadioBearer = drb-Identity 4
  measConfig
    measObjectToRemoveList .......... { 2 }
    measObjectToAddModList
      MeasObjectToAddMod  measObjectId 3, NR ARFCN 620000 (f3)
    reportConfigToAddModList
      ReportConfigToAddMod  reportConfigId 3, eventA5
    measIdToAddModList
      MeasIdToAddMod  measId 4 -> measObjectId 3, reportConfigId 3

Listing 2. The reconfiguration. Six list entries, and note what is not here: no mention of DRB 1, of SRB1 or SRB2, of measId 1, 2 or 3, or of quantityConfig.

And the result, worked out one object at a time:

drb-ToReleaseList { 2 }

rlc-BearerToReleaseList { 5 }

rlc-BearerToAddModList

measObjectToRemoveList { 2 }

measObjectToAddModList

reportConfigToAddModList

measIdToAddModList

Table 14. The resulting configuration, object by object. Sixteen objects, one of which changed without appearing in the message at all.

8.4 fullConfig, and when to reach for it

fullConfig is an ENUMERATED {true} -- one bit -- that switches the message from delta to absolute. When it is present the UE releases the entire dedicated configuration, applies the default configuration from TS 38.331 clause 9.2, and then applies the message. Two things survive: SRB1's PDCP and RLC entities, and the AS security context, because both are needed to have delivered the message in the first place.

Table 15. Delta versus full. fullConfig is the correct answer to "I do not know what this UE has" and the wrong answer to everything else.

8.5 The failure path, and why it is so expensive

If the UE cannot comply with any part of the message it must apply none of it. It continues with the configuration that was in force before the message arrived -- and then, because NR provides no reconfiguration failure message, it initiates the connection re-establishment procedure TS 38.331 cl. 5.3.5.8.

Table 16. What happens when a UE cannot comply, TS 38.331 clause 5.3.5.8. Only the SRB3 case produces a message that names the problem, and only because the SCG failure procedure already existed.

Reversion is atomic and it is the UE's obligation, but the network has no way to confirm it happened. After a refused reconfiguration the two sides should agree on the pre-message configuration -- and if the UE's revert was partial, they do not, and every subsequent delta is computed against a baseline the UE does not have. Since the recovery path is a re-establishment anyway, the target gNB will normally follow RRCReestablishment with a fullConfig reconfiguration: it costs an interruption that has already been paid for, and it guarantees agreement.

9. What the gNB Decides Before It Answers

Three of the five uplink CCCH messages are requests for a connection, and the gNB has to choose its answer before it knows very much. The choice is worth drawing out because the answer is the most informative single field in any access trace.

RRCSetupRequest

RRCSetup

RRCReestablishmentRequest

Table 17. Three requests, and what has to be true for each to be granted. The last column is the diagnostic shortcut: an answer on SRB0 means no stored context was used.

The gNB also chooses between delta and full configuration on every reconfiguration, and the criterion is not load or size but confidence -- see §8.4. In practice three situations force fullConfig: inbound inter-RAT handover, handover between nodes that cannot exchange a delta configuration, and re-establishment or resume at a node that retrieved a context it does not fully trust.

10. Security Mode Command

Table 18. AS security mode command, TS 38.331 clause 5.3.4. Full treatment in the companion 27 AS Security Mode.

The asymmetry in how the two messages are protected is the part worth remembering, because it is a landmark in any log:

SecurityModeCommand

SecurityModeComplete

SecurityModeFailure

Table 19. Protection of the security mode messages, per TS 33.501. Downlink ciphering begins after the gNB receives SecurityModeComplete.

nea0

nia0

nea1

nia1

nea2

nia2

nea3

nia3

Table 20. CipheringAlgorithm and IntegrityProtAlgorithm, TS 38.331 clause 6.3.3. Both are eight-member enumerations, so three bits each on the wire.

11. UE Capability Enquiry and Transfer

Table 21. UE capability transfer, TS 38.331 clause 5.6.1. Full treatment in the companion 26 UE Capability.

rat-Type

nr

eutra-nr

eutra

utra-fdd

Table 22. RAT-Type, TS 38.331 clause 6.3.3. The containers are opaque OCTET STRINGs so that a Rel-15 decoder can pass a Rel-18 capability set through without understanding it.

12. UE Information Request and Response

Table 23. UE information, TS 38.331 clause 5.7.10. The report contents are covered in the companion 16 RLM and RLF.

rlf-ReportReq

connEstFailReportReq

rach-ReportReq

Table 24. What a UE will surrender if asked. Every one of these is pull-only and single-use.

13. The Smaller Procedures

13.1 NAS transport: DL and UL Information Transfer

The simplest procedures in RRC. Both messages are envelopes: they carry a dedicatedNAS-Message, which is an OCTET STRING, and RRC does not look inside it. They exist for NAS PDUs that have no RRC message to piggyback on -- unlike the initial NAS message, which rides in RRCSetupComplete, and unlike accept messages, which often ride in RRCReconfiguration's dedicatedNAS-MessageList.

rrc-TransactionIdentifier

Table 25. The two NAS transport messages. The transaction identifier asymmetry catches people: DLInformationTransfer has one and ULInformationTransfer does not, so the two cannot be paired at RRC level at all.

13.2 Measurement report

MeasurementReport is UE-initiated and unsolicited: no request precedes it and no transaction identifier correlates it. It carries a measResults structure whose first field is the measId that triggered it, and that measId is the only link back to the measConfig that configured the event. Correlate on measId, and keep the measConfig that established it -- a report against a measId you cannot find in your configuration means the configuration you think the UE has is not the one it has. Full treatment in the companion 20 Measurements and Events.

13.3 UE assistance information

UEAssistanceInformation is the UE telling the network what it would prefer. It is UE-initiated and unsolicited -- but only for the report types the network has explicitly enabled in otherConfig. Nothing here is volunteered by default.

delayBudgetReport

overheatingAssistance

overheatingAssistanceConfig

idc-Assistance

idc-AssistanceConfig

drx-Preference

drx-PreferenceConfig

maxBW-Preference

maxBW-PreferenceConfig

releasePreference

releasePreferenceConfig

Table 26. UEAssistanceInformation report types. Every one is gated on a matching configuration in otherConfig, and every one has a prohibit timer that suppresses repeats.

13.4 Counter check

A rarely-used integrity auxiliary. DRBs are usually ciphered but not integrity-protected, which leaves room for an attacker to insert or delete packets: the ciphering keystream stays synchronised only if both sides have processed the same number of PDUs, so an inserted or dropped packet shifts the COUNT. CounterCheck asks the UE to confirm its counters match.

CounterCheck

CounterCheckResponse

Table 27. Counter check, TS 38.331 clause 5.3.6. The MSB-only request and full-value response is deliberate: it makes the check insensitive to normal skew and precise about real divergence.

If the counts differ, TS 38.331 leaves the reaction to the network. In practice a mismatch is treated as evidence of tampering and the connection is released. The procedure is cheap to run and almost never run, which means that when you do see it in a log it is either a conformance test or somebody's security policy, not a routine event.

13.5 Mobility from NR

Table 28. Mobility from NR, TS 38.331 clause 5.4.3.

14. A Whole Session, Procedure by Procedure

Putting the pieces together, this is what a typical session actually runs, with the decisions and the alternatives at each step:

T300

T304

Table 29. A session's procedures in order, with the alternative outcome for each. Steps 1-4 happen once, 5-7 repeat, 8-9 happen only on failure, and 10 happens once.

15. The RRC Timer Landscape

T300

T301

UE-TimersAndConstants

T302

T304

ReconfigurationWithSync t304

T310

UE-TimersAndConstants

T311

UE-TimersAndConstants

T316

T319

UE-TimersAndConstants

T320

CellReselectionPriorities t320

T380

SuspendConfig t380

T390

Table 30. RRC timers, TS 38.331 clause 7.1. Every one of these is the error message for the procedure it bounds -- RRC has no others.

16. Failure Modes and What Each One Means

SecurityModeFailure

RRCReject

Table 31. Procedure failure modes. Five of the twelve are detected by nobody at all -- they have no error message and no timer, and they surface as behaviour that is merely wrong.

17. Configuration Reference (ASN.1)

17.1 RRCReconfiguration and its extension chain

RRCReconfiguration ::= SEQUENCE {
    rrc-TransactionIdentifier  RRC-TransactionIdentifier,
    criticalExtensions         CHOICE {
        rrcReconfiguration         RRCReconfiguration-IEs,
        criticalExtensionsFuture   SEQUENCE {}
    }
}

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
}

-- ... the chain continues through v1540, v1560, v1610 (which adds
-- conditionalReconfiguration and daps-Config), v1640, v1650, v1660,
-- v1700 and beyond.

Listing 3. Abridged from TS 38.331 clause 6.2.2. masterCellGroup lives in the v1530 extension while secondaryCellGroup is a root IE -- an ordering fossil, not a hierarchy.

17.2 The list-based IEs

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
    ...
}

DRB-ToAddMod ::= SEQUENCE {
    cnAssociation CHOICE {
        eps-BearerIdentity  INTEGER (0..15),
        sdap-Config         SDAP-Config
    }                                     OPTIONAL, -- Cond DRBSetup
    drb-Identity          DRB-Identity,   -- INTEGER (1..32)
    reestablishPDCP       ENUMERATED {true} OPTIONAL, -- Need N
    recoverPDCP           ENUMERATED {true} OPTIONAL, -- Need N
    pdcp-Config           PDCP-Config       OPTIONAL, -- Cond PDCP
    ...
}

CellGroupConfig ::= SEQUENCE {
    cellGroupId              CellGroupId,
    rlc-BearerToAddModList   SEQUENCE (SIZE(1..maxLC-ID)) OF
                                 RLC-BearerConfig  OPTIONAL, -- Need N
    rlc-BearerToReleaseList  SEQUENCE (SIZE(1..maxLC-ID)) OF
                                 LogicalChannelIdentity
                                                   OPTIONAL, -- Need N
    mac-CellGroupConfig      MAC-CellGroupConfig   OPTIONAL, -- Need M
    physicalCellGroupConfig  PhysicalCellGroupConfig
                                                   OPTIONAL, -- Need M
    spCellConfig             SpCellConfig          OPTIONAL, -- Need M
    sCellToAddModList        SEQUENCE (SIZE (1..maxNrofSCells)) OF
                                 SCellConfig       OPTIONAL, -- Need N
    sCellToReleaseList       SEQUENCE (SIZE (1..maxNrofSCells)) OF
                                 SCellIndex        OPTIONAL, -- Need N
    ...
}

MeasConfig ::= SEQUENCE {
    measObjectToRemoveList    MeasObjectToRemoveList   OPTIONAL, -- Need N
    measObjectToAddModList    MeasObjectToAddModList   OPTIONAL, -- Need N
    reportConfigToRemoveList  ReportConfigToRemoveList OPTIONAL, -- Need N
    reportConfigToAddModList  ReportConfigToAddModList OPTIONAL, -- Need N
    measIdToRemoveList        MeasIdToRemoveList       OPTIONAL, -- Need N
    measIdToAddModList        MeasIdToAddModList       OPTIONAL, -- Need N
    s-MeasureConfig CHOICE { ssb-RSRP RSRP-Range,
                             csi-RSRP RSRP-Range }     OPTIONAL, -- Need M
    quantityConfig            QuantityConfig           OPTIONAL, -- Need M
    measGapConfig             MeasGapConfig            OPTIONAL, -- Need M
    measGapSharingConfig      MeasGapSharingConfig     OPTIONAL, -- Need M
    ...
}

Listing 4. Abridged from TS 38.331 clause 6.3.2. Note the naming: bearers and cell groups use ToReleaseList, measurements use ToRemoveList. Same mechanism, two words.

17.3 The mobility and synchronisation IEs

SpCellConfig ::= SEQUENCE {
    servCellIndex             ServCellIndex   OPTIONAL, -- Cond SCG
    reconfigurationWithSync   ReconfigurationWithSync
                                              OPTIONAL, -- Cond ReconfWithSync
    rlf-TimersAndConstants    SetupRelease {RLF-TimersAndConstants}
                                              OPTIONAL, -- Need M
    rlmInSyncOutOfSyncThreshold ENUMERATED {n1}
                                              OPTIONAL, -- Need S
    spCellConfigDedicated     ServingCellConfig
                                              OPTIONAL, -- Need M
    ...
}

ReconfigurationWithSync ::= SEQUENCE {
    spCellConfigCommon   ServingCellConfigCommon  OPTIONAL, -- Need M
    newUE-Identity       RNTI-Value,             -- INTEGER (0..65535)
    t304                 ENUMERATED {ms50, ms100, ms150, ms200, ms500,
                                     ms1000, ms2000, ms10000},
    rach-ConfigDedicated CHOICE {
        uplink               RACH-ConfigDedicated,
        supplementaryUplink  RACH-ConfigDedicated
    }                                          OPTIONAL, -- Need N
    ...,
    [[
    smtc                 SSB-MTC                OPTIONAL  -- Need S
    ]]
}

MobilityFromNRCommand-IEs ::= SEQUENCE {
    targetRAT-Type            ENUMERATED {eutra, spare3, spare2,
                                          spare1, ..., utra-fdd-v1610},
    targetRAT-MessageContainer OCTET STRING,
    nas-SecurityParamFromNR   OCTET STRING     OPTIONAL, -- Cond
    lateNonCriticalExtension  OCTET STRING     OPTIONAL,
    nonCriticalExtension      SEQUENCE {}      OPTIONAL
}

RRCReestablishment-IEs ::= SEQUENCE {
    nextHopChainingCount      NextHopChainingCount,  -- INTEGER (0..7)
    lateNonCriticalExtension  OCTET STRING     OPTIONAL,
    nonCriticalExtension      SEQUENCE {}      OPTIONAL
}

Listing 5. Abridged from TS 38.331 clause 6.2.2 and 6.3.2. RRCReestablishment-IEs is shown in full -- it really does carry nothing but the chaining count.

18. Illustrative Message Traces

18.1 The delta reconfiguration of §8.3, as a log

09:15:22.104  [CU-CP RRC-DL] DL-DCCH-Message on SRB1, LCID 1, 88 octets
              c1 = rrcReconfiguration
                rrc-TransactionIdentifier ......... 2
                radioBearerConfig
                  drb-ToReleaseList ............... { 2 }
                  drb-ToAddModList
                    [0] drb-Identity .............. 3   -- MODIFY
                        pdcp-Config.drb.discardTimer  ms100
                        pdcp-Config.drb.headerCompression  notUsed
                    [1] drb-Identity .............. 4   -- ADD
                        cnAssociation.sdap-Config
                          pdu-Session ............. 2
                          mappedQoS-FlowsToAdd .... { 6 }
                        pdcp-Config.drb.pdcp-SN-SizeUL  len18bits
                        pdcp-Config.drb.pdcp-SN-SizeDL  len18bits
                nonCriticalExtension          -- v1530
                  masterCellGroup  (OCTET STRING, 31 octets)
                    cellGroupId ................... 0
                    rlc-BearerToReleaseList ....... { 5 }
                    rlc-BearerToAddModList
                      [0] logicalChannelIdentity .. 7
                          servedRadioBearer = drb-Identity 4
                measConfig
                  measObjectToRemoveList .......... { 2 }
                  measObjectToAddModList
                    [0] measObjectId .............. 3   (NR, 620000)
                  reportConfigToAddModList
                    [0] reportConfigId ............ 3   (eventA5)
                  measIdToAddModList
                    [0] measId 4 -> measObjectId 3, reportConfigId 3

09:15:22.131  [UE RRC] applying, in order:
              drb-ToReleaseList  { 2 }      -> DRB 2 released
              rlc-BearerToRelease { 5 }     -> LCID 5 released
              measObjectToRemove { 2 }      -> measObject 2 removed
                                            -> measId 2 removed as a
                                               consequence (cl. 5.5.2.4)
              drb-ToAddModList              -> DRB 3 modified, DRB 4 added
              rlc-BearerToAddMod            -> LCID 7 added
              measObject/reportConfig/measId add lists applied
              DRB 3 pdcp-SN-Size unchanged (Cond Setup, absent = keep)

09:15:22.138  [UE RRC-UL] rrcReconfigurationComplete  txn 2  on SRB1

-- Resulting measId set: { 1, 3, 4 }.  measId 2 is gone and no list in
-- the message mentioned it. This is the bug class of section 8.3.

Listing 6. The worked example as it appears in a CU-CP log, with the UE's application order shown. The last three lines are the whole point of §8.

18.2 A reconfiguration with sync, and its failure

10:41:07.882  [RRC-UL] measurementReport
                measResults.measId ................ 1
                measResultServingMOList[0] RSRP ... -104 dBm
                measResultNeighCells.measResultListNR
                  [0] physCellId 118, RSRP ........ -96 dBm

10:41:07.905  [RRC-DL] rrcReconfiguration  txn 3  on SRB1, 1412 octets
                nonCriticalExtension.masterCellGroup
                  spCellConfig
                    reconfigurationWithSync
                      spCellConfigCommon
                        physCellId ................ 118
                        downlinkConfigCommon.frequencyInfoDL
                          absoluteFrequencySSB .... 632640
                      newUE-Identity ................ 0x7C12
                      t304 .......................... ms200
                      rach-ConfigDedicated.uplink
                        cfra.occasions ............ (dedicated)
                        cfra.resources.ssb
                          ssb-ResourceList[0]
                            ra-PreambleIndex ...... 48
                  masterKeyUpdate
                    keySetChangeIndicator ........... false
                    nextHopChainingCount ............ 5
              -- T304 (ms200) starts on receipt

10:41:07.912  [UE RRC]  reset MAC; re-establish PDCP+RLC for SRB1, SRB2,
                        DRB 1, DRB 2; derive K_gNB* with NCC 5;
                        apply spCellConfigCommon; C-RNTI := 0x7C12
10:41:07.921  [MAC-UL] PCI 118: CFRA preamble 48, RA-RNTI 1417
10:41:07.929  [MAC-DL] PCI 118: RAR, TA 212, UL grant
10:41:07.938  [RRC-UL] rrcReconfigurationComplete  txn 3  on SRB1
              -- T304 stopped at 33 ms of 200. Handover complete.

-- The same handover, with the CFRA resource unavailable:
11:02:44.610  [RRC-DL] rrcReconfiguration  txn 1
                      reconfigurationWithSync
                        newUE-Identity .............. 0x33A0
                        t304 ........................ ms200
                        rach-ConfigDedicated ........ ABSENT
              -- no dedicated preamble: the UE must use CBRA at the target
11:02:44.620  [MAC-UL] PCI 118: CBRA preamble 19 (random), attempt 1
11:02:44.641  [MAC-UL] PCI 118: CBRA preamble 44, attempt 2
11:02:44.669  [MAC-UL] PCI 118: CBRA preamble 07, attempt 3
11:02:44.810  [UE RRC] T304 expired (200 ms)
              -> revert to the SOURCE configuration
              -> initiate re-establishment: T311 started
              -> store an RLF report, connectionFailureType = hof
11:02:44.980  [RRC-UL] rrcReestablishmentRequest on SRB0, PCI 41,
                       c-RNTI 0x4601, reestablishmentCause handoverFailure

Listing 7. A handover that works, and the same handover without a dedicated preamble. The second one fails on contention, inside a T304 that was sized for contention-free access.

18.3 A reconfiguration the UE refuses, and its real cost

12:18:03.441  [RRC-DL] rrcReconfiguration  txn 0  on SRB1
                radioBearerConfig
                  drb-ToAddModList
                    [0] drb-Identity .............. 5
                        pdcp-Config.drb.pdcp-SN-SizeUL  len18bits
                        pdcp-Config.drb.pdcp-SN-SizeDL  len18bits
                nonCriticalExtension.secondaryCellGroup
                  sCellToAddModList
                    [0] sCellIndex ................ 3
                    [1] sCellIndex ................ 4

12:18:03.459  [UE RRC] evaluating the message
              drb-Identity 5, 18-bit UL SN ......... supported
              sCellIndex 3 ......................... supported
              sCellIndex 4 ......................... NOT supported on
                                                     this band combination
              -> cannot comply with the whole message
              -> revert to the configuration in force before txn 0
                 (DRB 5 is NOT added; SCell 3 is NOT added)

              -> NR has no reconfiguration failure message, so:
              -> initiate re-establishment      (TS 38.331 cl. 5.3.5.8)

12:18:03.463  [UE RRC] T311 started; cell selection
12:18:03.508  [RRC-UL] rrcReestablishmentRequest on SRB0 (same cell)
                c-RNTI ............................ 0x4601
                physCellId ........................ 41
                shortMAC-I ........................ 0x2F81
                reestablishmentCause .............. reconfigurationFailure
              -- two bits of cause value. That is the entire error report.

12:18:03.541  [RRC-DL] rrcReestablishment  txn 0  on SRB1
                nextHopChainingCount .............. 6
              -- and nothing else: SRB2 and every DRB are still suspended
12:18:03.559  [RRC-UL] rrcReestablishmentComplete  txn 0

12:18:03.572  [RRC-DL] rrcReconfiguration  txn 1
                nonCriticalExtension.fullConfig ..... true
                (2088 octets: SRB2, DRB 1, DRB 2, whole masterCellGroup,
                 whole measConfig -- all restated absolutely)
12:18:03.688  [RRC-UL] rrcReconfigurationComplete  txn 1
              -- 247 ms of user-plane outage, for one unsupported SCell

Listing 8. The real cost of a refused reconfiguration: not a failure message but a re-establishment and a full reconfiguration. Note that SCell 3 was not added even though the UE supported it -- the message is applied whole or not at all -- and that reestablishmentCause is the only diagnostic the network ever receives.

18.4 Retrieving the RLF report the handover failure produced

11:03:02.118  [RRC-UL] rrcSetupComplete on SRB1
              -- the UE indicates that an RLF report is available

11:03:02.204  [RRC-DL] ueInformationRequest  txn 1  on SRB1
                rlf-ReportReq ..................... true
                rach-ReportReq .................... true
                connEstFailReportReq .............. true

11:03:02.281  [RRC-UL] ueInformationResponse  txn 1  on SRB1
                rlf-Report
                  measResultLastServCell
                    rsrpResult ................... -118 dBm
                    rsrqResult ................... -19 dB
                  measResultNeighCells
                    [0] physCellId 118, rsrp ..... -96 dBm
                  c-RNTI ......................... 0x4601
                  previousPCellId ................ PCI 41
                  failedPCellId .................. PCI 118
                  connectionFailureType .......... hof
                  timeSinceFailure ............... 18 s
                rach-Report
                  numberOfPreamblesSent .......... 3
                  contentionDetected ............. true
                connEstFailReport ................ ABSENT

-- Read together: the target (PCI 118) was measured at -96 dBm, which is
-- fine, and three contention-based preambles collided. So the handover
-- decision was correct and the execution failed on contention -- which
-- points at the absent rach-ConfigDedicated of 18.2, not at coverage.
-- connEstFailReport is absent because there was no establishment failure,
-- not because the request was refused.

Listing 9. The RLF and RACH reports together, and the conclusion they support. Either report alone would have been misleading.

18.5 UE assistance information, and the prohibit timer

13:44:19.006  [RRC-DL] rrcReconfiguration  txn 2
                nonCriticalExtension.otherConfig
                  overheatingAssistanceConfig = setup
                    overheatingIndicationProhibitTimer  s30
                  releasePreferenceConfig-r16 = setup
                    releasePreferenceProhibitTimer      s10
              -- until this message, the UE was not permitted to send
              -- either report at all

13:47:52.330  [RRC-UL] ueAssistanceInformation on SRB1
                overheatingAssistance
                  reducedMaxCCs
                    reducedCCsDL ................. 1
                    reducedCCsUL ................. 1
                  reducedMaxMIMO-LayersFR1
                    reducedMIMO-LayersFR1-DL ..... 2
              -- prohibit timer s30 starts; no repeat before 13:48:22

13:47:58.114  [UE internal] temperature still rising
              -- a second report would be sent now, but the prohibit
              -- timer suppresses it. The network sees nothing further.

13:48:05.900  [RRC-DL] rrcReconfiguration  txn 3
                sCellToReleaseList ................ { 3, 4 }
              -- gNB honours the request: two SCells released

13:49:31.442  [RRC-UL] ueAssistanceInformation on SRB1
                releasePreference
                  preferredRRC-State ............. inactive
              -- a hint, not a request. The gNB may ignore it entirely.
13:49:31.610  [RRC-DL] rrcRelease  txn 4
                suspendConfig ..................... present
              -- honoured: the UE goes to RRC_INACTIVE

Listing 10. The whole assistance loop: enable, report, prohibit, act. The suppressed second report at 13:47:58 is invisible to the network and reads exactly like the problem resolving itself.

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

Table 32. Procedure changes by release. Feature presence must be confirmed against the capability exchange, never inferred from a successful Complete -- see the companion 26 UE Capability.

20. Reading RRC Procedures in Logs: A Checklist

1. Pair every request with its response, or name the timer. RRC has no generic error message, so a missing response plus an expired timer is the error. §15 maps every procedure to its timer.

2. Match on message type *and* transaction identifier. There are only four identifier values, and a SecurityModeCommand and an RRCReconfiguration can legitimately share one (§2, and the companion 13 RRC Overview §10).

3. Read the SRB the answer arrived on. An answer to a CCCH request on SRB1 means a stored context was found and verified; an answer on SRB0 means it was not. This one check resolves most resume and re-establishment questions instantly (§9).

4. On every reconfiguration, decode the first octet first. In an RRCReconfiguration, two bits of transaction identifier, one CHOICE bit and five presence bits tell you what is in the message before you decode any content (§7.4).

5. Look for a synchronised reconfiguration before anything else. The presence of reconfigurationWithSync turns a configuration change into a cell change, starts T304, and means the Complete will arrive in a different cell (§7.3).

6. Check whether the message is absolute. fullConfig is one bit that changes the message from delta to absolute and costs a PDCP re-establishment on every bearer. In a routine reconfiguration it is a smell (§8.4).

7. For any list-based change, compute the resulting configuration. Release lists apply before add/modify lists, absent fields follow their Need codes, and a measId can vanish because the measObject it pointed at was removed. Do the §8.3 exercise on anything suspicious.

8. Check that bearer changes touch both halves. A DRB lives in radioBearerConfig and its RLC bearer lives in CellGroupConfig, and in a split gNB the two are authored by different nodes (§7.2).

9. Find the first non-zero integrity trailer on SRB1. The first non-zero MAC-I is where AS security actually took effect, regardless of what the SecurityModeComplete claims (§10).

10. When a UE never sends something, check whether it was enabled. UEAssistanceInformation report types need otherConfig; capability responses need a capabilityRequestFilter small enough to encode; RLF reports need somebody to ask (§11, §12, §13.3).

11. Ask for the reports. An RLF report a gNB does not request is gone forever, and no network-side logging replaces it (§12).

21. Glossary

fullConfig

reconfigurationWithSync

rrc-TransactionIdentifier

COUNT

otherConfig

targetRAT-MessageContainer

22. References

• 3GPP TS 38.331 -- NR RRC protocol specification. Clause 5.3.3 (connection establishment and T300), 5.3.4 (AS security mode command), 5.3.5 (connection reconfiguration, including 5.3.5.3 the application order, 5.3.5.5 cell group configuration, 5.3.5.6 radio bearer configuration, and 5.3.5.11 full configuration), 5.3.6 (counter check), 5.3.7 (connection re-establishment), 5.3.8 (connection release), 5.3.13 (connection resume), 5.3.15 (RRCReject), 5.4.3 (mobility from NR), 5.5.2 (measurement configuration, including 5.5.2.4 measurement object removal), 5.6.1 (UE capability transfer), 5.7.4 (UE assistance information), 5.7.10 (UE information), 6.1 (Need codes and general IE conventions), 6.2.2 (message definitions), 6.3.2 (information elements), 7.1 (UE timers and constants), 9.2 (default configurations).
• 3GPP TS 38.300 -- NR and NG-RAN overall description. Clause 9.2 (RRC procedures in the overall architecture, and the interaction with NGAP and XnAP).
• 3GPP TS 33.501 -- Security architecture and procedures for 5G System. Clause 6.7 (security mode command procedure and the protection asymmetry of §10), clause 6.9 (key handling at handover), clause 6.11 (RRC_INACTIVE security).
• 3GPP TS 38.323 -- PDCP specification. The MAC-I field, the 9000-octet maximum SDU size that forces segmentation, and PDCP re-establishment and recovery -- what reestablishPDCP and recoverPDCP actually do.
• 3GPP TS 38.322 -- RLC specification. RLC re-establishment, and the maximum retransmission condition that is one of the RLF triggers.
• 3GPP TS 38.321 -- NR MAC protocol specification. Clause 5.1 (random access, which every CCCH procedure runs first), and logical channel prioritisation, which the SRB priorities feed.
• 3GPP TS 38.473 / TS 38.463 / TS 38.423 / TS 38.413 -- F1AP, E1AP, XnAP and NGAP. RRC messages travel inside all four as opaque containers; see the companion 13 RRC Overview §12.
• 3GPP TS 36.331 -- E-UTRA RRC protocol specification. Needed to decode the targetRAT-MessageContainer of MobilityFromNRCommand (§13.5).
• ITU-T X.680 / X.691 -- ASN.1 notation and Packed Encoding Rules. The preamble bitmaps and extension additions of §7.4.

Companion documents in this set

• 13 RRC Overview -- the layer, the SRBs, unaligned PER, the full message catalogue, transaction correlation, segmentation and the CU/DU split.
• 14 RRC States -- the state machine, suspendConfig, resume in depth, RAN Notification Areas and cell reselection.
• 01 Registration Process -- steps 1 to 4 of §14 in their NAS context, message by message.
• 03 Random Access -- every CCCH procedure begins with a RACH, and the rach-ConfigDedicated of §7.3 is its contention-free form.
• 09 LCP -- logical channel prioritisation, which is what the RLC bearer configuration of §7.2 feeds.
• 11 DRX -- mac-CellGroupConfig -> drx-Config, and the DRX preferences of §13.3.
• 16 RLM and RLF -- T310, T311, T301, shortMAC-I, and the contents of the RLF report that §12 retrieves.
• 17 System Information -- UE-TimersAndConstants, where most of §15's timers are configured, and the UAC barring behind T390.
• 20 Measurements and Events -- measConfig and MeasurementReport in full, including the event definitions behind the worked example of §8.3.
• 21 Measurement Gaps and SMTC -- measGapConfig and the smtc in reconfigurationWithSync.
• 22-25 Handover family -- reconfigurationWithSync in its mobility context, conditional reconfiguration and DAPS.
• 26 UE Capability -- what UECapabilityInformation contains, why it needs segmentation, and why a capability bit is the only proof a feature is active.
• 27 AS Security Mode -- the key hierarchy, masterKeyUpdate, and the algorithms of §10.