5G RRC Setup Message Explained

The RRC Setup message is one of the first dedicated signalling messages a UE receives after requesting an RRC connection in 5G NR. For radio engineers, protocol testers, and log analysts, this is the message that tells you whether the network has accepted the initial connection attempt and how it wants the UE to build the first connected-mode control-plane configuration.

In practical terms, RRC Setup creates SRB1, gives the UE the initial CellGroupConfig, and transitions the procedure toward RRC_CONNECTED. It does not yet set up user-plane data radio bearers, and it is not the message that carries the UE’s initial NAS message toward the core. That NAS payload is sent by the UE in RRC Setup Complete.

Why RRC Setup matters

If you decode 5G call traces, RRC Setup is the message that confirms the gNB is admitting the UE into connected mode. It is a critical checkpoint because it shows:

  • the network accepted the UE’s RRCSetupRequest
  • the gNB created the first signalling bearer (SRB1)
  • the UE now has the initial serving-cell and MAC/PHY control configuration
  • the procedure can move forward to RRC Setup Complete and then AS security activation

When RRC Setup is missing, malformed, or inconsistent with later messages, the entire attach, registration, service request, or resume fallback flow can fail.

Where RRC Setup appears in the 5G call flow

A typical sequence is:

  1. The UE camps on the cell and acquires essential system information.
  2. The UE initiates connection establishment and sends RRCSetupRequest.
  3. The gNB either rejects the attempt with RRCReject or accepts it with RRC Setup.
  4. The UE applies the configuration from RRC Setup.
  5. The UE sends RRC Setup Complete with the initial NAS message.
  6. The network continues with Security Mode Command and later RRC Reconfiguration.

This message can also appear in a fallback case. If the UE tries RRC Resume or RRC Re-establishment and the network cannot recover or verify the context, the network may respond with RRC Setup instead of continuing the old context.

Transport characteristics

For troubleshooting and decoder design, the transport details matter:

  • Direction: gNB to UE
  • Signalling radio bearer: SRB0
  • Logical channel: CCCH
  • RLC mode: TM
  • Message class: DL-CCCH

This is important because SRB0 is the pre-SRB1 signalling path. Since AS security is not yet activated on SRB0, engineers should not expect RRC Setup to be ciphered or integrity protected like later DCCH signalling.

What RRC Setup does at the UE

After receiving RRC Setup, the UE performs the initial connected-mode configuration work needed to continue the procedure. Operationally, the UE:

  • processes the received masterCellGroup
  • applies the radioBearerConfig
  • stops establishment-related timers such as T300
  • enters RRC_CONNECTED
  • sends RRC Setup Complete

That means RRC Setup is not just an acceptance message. It is also the first message that materially changes the UE’s RRC state and bearer setup.

Simplified message structure

A readable view of the message is:

RRCSetup
└── rrc-TransactionIdentifier
└── criticalExtensions
    └── rrcSetup
        ├── radioBearerConfig
        ├── masterCellGroup
        ├── lateNonCriticalExtension        (optional)
        └── nonCriticalExtension            (optional)

This is the structure most engineers care about during trace analysis.

Important information elements in RRC Setup

1. rrc-TransactionIdentifier

This field links the message to the active RRC transaction. In NR, the transaction identifier is a small integer used together with the message type to identify the procedure instance. When you correlate downlink and uplink control signalling, this field helps match RRC Setup with the related UE response.

Why it matters in logs: If the transaction identifier is inconsistent across request-response pairs, decoders and protocol stacks can mis-handle procedure completion.

2. criticalExtensions

This is the RRC versioning wrapper. It allows the message definition to evolve across releases without breaking backward compatibility. In everyday trace analysis, you usually see the normal rrcSetup branch, but the wrapper is still important because it defines how release-specific extensions are interpreted.

Why it matters in logs: If a decoder does not handle the extension tree correctly, it may parse only the base release fields and miss later-release additions.

3. radioBearerConfig

This IE provides the radio bearer configuration included in the message. In RRC Setup, the gNB is restricted to configuring only SRB1. This is a crucial point for anyone debugging early call setup: if you expect DRBs here, you are looking at the wrong phase of the procedure.

Note: Confirm that SRB1 is added correctly and that no decoder falsely interprets later connected-mode bearers as part of this message.

4. masterCellGroup

This is the most operationally important container in the message. It carries the initial CellGroupConfig used by the UE to move into connected operation. For RRC Setup, the configured scope is intentionally narrow and focused on early control-plane bring-up:

  • the RLC bearer for SRB1
  • mac-CellGroupConfig
  • physicalCellGroupConfig
  • spCellConfig

This is where you should look for initial MAC and physical-layer behaviour that affects uplink alignment, cell-group activation, and serving-cell operation.

If the UE fails after receiving RRC Setup, the first place to inspect is whether the masterCellGroup content is complete, internally consistent, and supported by the UE capability profile.

5. lateNonCriticalExtension

This optional container is mainly about compatibility between releases and implementations. It usually does not drive the first-level operational behaviour of the procedure, but it matters when analysing interoperability or vendor-specific evolution across releases.

6. nonCriticalExtension

This is the normal release-extension branch used to add later features without changing the base message. In later releases, additional fields can appear here, especially for special cases such as relay-related operation.

RRC Setup vs RRC Setup Complete

This is a common source of confusion in field logs:

  • RRC Setup is the network-to-UE message that accepts the connection and configures SRB1.
  • RRC Setup Complete is the UE-to-network response that confirms the procedure and carries the dedicated NAS message.

So if you are searching for the UE’s Registration Request or Service Request, do not look in RRC Setup. Look in RRC Setup Complete.

What to verify in a live trace

When validating a 5G attach or connection establishment log, check these points:

Verify that the procedure is really connection establishment

Make sure the sequence is:

  • essential SI acquired
  • RRCSetupRequest
  • RRC Setup
  • RRC Setup Complete

If the network sends RRCReject, the problem is admission or barring, not configuration.

Confirm SRB1 creation

RRC Setup should establish SRB1. If SRB1 is missing, later DCCH messages such as SecurityModeCommand cannot proceed correctly.

Check the masterCellGroup content

Look for a sensible initial serving-cell setup, MAC cell-group configuration, and physical cell-group configuration. Many early failures come from invalid or unsupported initial configuration.

Do not expect user-plane setup here

RRC Setup is an early control-plane message. DRBs and richer dedicated radio configuration normally arrive later, typically in RRC Reconfiguration.

Remember that SRB0 is unsecured

Since RRC Setup is carried on SRB0, lack of AS ciphering or integrity at this point is normal. Security starts later in the procedure.

Watch for fallback behaviour

If a UE attempted RRC Resume or RRC Re-establishment and receives RRC Setup, it usually means the network could not continue with the old context and chose full connection establishment instead.

Common troubleshooting scenarios

RRC Setup received but no RRC Setup Complete

Possible causes include:

  • UE failed to parse or apply masterCellGroup
  • bearer setup inconsistency for SRB1
  • UE capability mismatch with the delivered configuration
  • timers or lower-layer issues during the transition to connected mode

Repeated RRC Setup after failed resume

This often indicates that context retrieval at the network failed, so the network is forcing a fresh connected-mode setup.

Security starts failing later

If SecurityModeCommand fails after a clean RRC Setup / RRC Setup Complete exchange, the problem is usually not in RRC Setup itself, but in the later AS security activation stage.

FAQ

What is RRC Setup in 5G NR?

RRC Setup is the downlink RRC message that the gNB sends to establish SRB1 during RRC connection establishment.

What comes before RRC Setup?

The UE first sends RRCSetupRequest after initial access and random access preparation.

What comes after RRC Setup?

The UE applies the received configuration, enters connected mode, and responds with RRCSetupComplete. The network then typically proceeds with SecurityModeCommand.

Does RRC Setup configure DRBs?

No. In NR, RRC Setup is limited to the initial connected-mode configuration and only SRB1 can be configured here.

Summary

Downlink NR RRC message sent by the gNB to establish SRB1 and move the UE into the connected RRC procedure.