5G RRCSetupRequest Message Explained

The RRCSetupRequest message is the first dedicated uplink NR RRC signaling message sent by the UE when it wants to establish an RRC connection in 5G NR. This is one of the most important early-layer messages because it marks the exact point where the UE asks the network to move from idle access conditions toward connected signaling.

In simple terms, RRCSetupRequest tells the gNB that the UE wants a connection and provides two key pieces of information:

  • an initial UE identity for lower-layer contention resolution
  • an establishment cause that explains why the UE is requesting access

This message is small, but it is operationally critical.

Why RRCSetupRequest matters

If you are analyzing a 5G registration, service request, paging response, or emergency access attempt, RRCSetupRequest is one of the first protocol checkpoints that tells you what kind of access the UE is trying to make.

It matters because it:

  • starts the RRC connection establishment procedure
  • is sent before SRB1 exists, so it uses SRB0 on CCCH
  • gives lower layers the UE identity needed for contention resolution
  • gives the gNB the establishmentCause that can influence admission and priority handling
  • leads directly to either RRCSetup or RRCReject

If this message is missing, malformed, or inconsistent with the access scenario, the UE never gets to the later signaling stages.

Where RRCSetupRequest appears in the call flow

A successful 5G NR RRC connection establishment flow is:

  1. UE camps on a suitable cell.
  2. UE acquires essential system information.
  3. UE initiates RRC connection establishment.
  4. UE sends RRCSetupRequest.
  5. gNB responds with RRCSetup.
  6. UE responds with RRCSetupComplete.

If the network cannot handle the request, the alternative flow is:

  1. UE sends RRCSetupRequest.
  2. gNB responds with RRCReject.

That makes RRCSetupRequest the entry point to one of the most fundamental NR control procedures.

Transport characteristics

From a protocol-stack perspective, RRCSetupRequest is transported as follows:

  • Direction: UE to network
  • Signaling radio bearer: SRB0
  • RLC mode: TM
  • Logical channel: CCCH
  • Message class: UL-CCCH

This is important because SRB0 is the pre-connection signaling path. At this stage, the UE has not yet established SRB1, and AS security has not yet been activated.

When the UE sends RRCSetupRequest

The UE initiates the procedure when:

  • upper layers request establishment of an RRC connection
  • the UE is in RRC_IDLE
  • the UE has acquired essential system information

This is an important engineering detail. The UE is not supposed to send RRCSetupRequest blindly. It first needs valid cell information, including the essential system information required to access the cell correctly.

UE actions before transmitting RRCSetupRequest

The standard defines several important preparation steps before transmission.

1. Check access control

If upper layers provide an Access Category and one or more Access Identities, the UE performs the unified access control procedure.

If access is barred, the procedure ends and the message is not sent.

If upper layers provide NSAG information and one or more S-NSSAI values that triggered the access attempt, the UE applies the highest-priority NSAG available in SIB1 for the triggering slice context.

3. Apply initial access-side defaults

Before sending the message, the UE applies:

  • default L1 parameter values, except where SIB1 provides values
  • default MAC Cell Group configuration
  • CCCH configuration
  • timeAlignmentTimerCommon from SIB1

4. Start timer T300

The UE starts T300 before transmitting the message.

T300 is one of the main timers used to supervise connection establishment. If the network never responds appropriately, T300 expiry becomes part of the failure logic.

5. Build and submit the message to lower layers

Once the preparation is complete, the UE constructs the RRCSetupRequest contents and submits the message to lower layers for transmission.

RRCSetupRequest ASN.1 structure

The message is compact. Its structure is:

RRCSetupRequest ::= SEQUENCE {
  rrcSetupRequest RRCSetupRequest-IEs
}

RRCSetupRequest-IEs ::= 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
}

Compared with later RRC messages, this one is intentionally minimal.

Important information elements in RRCSetupRequest

1. ue-Identity

This is the most important field in the message. The spec states that the UE identity is included to facilitate contention resolution by lower layers.

That means the identity is not mainly for full core-network identity management at this stage. Its immediate role is to help the access procedure resolve which UE is actually completing the initial connection attempt.

Two possible forms of ue-Identity

The ue-Identity field is a CHOICE with two options:

  • ng-5G-S-TMSI-Part1
  • randomValue

2. ng-5G-S-TMSI-Part1

If upper layers provide a 5G-S-TMSI, the UE sets ue-Identity to ng-5G-S-TMSI-Part1.

This field carries the rightmost 39 bits of the 5G-S-TMSI.

Why it matters

Using part of the 5G-S-TMSI allows the access procedure to carry a connection-attempt identity tied to an already known UE context.

Practical meaning

In a trace, this usually indicates the UE already has a temporary identity context and is not starting from a completely anonymous situation.

3. randomValue

If upper layers do not provide a 5G-S-TMSI, the UE draws a 39-bit random value in the range 0 .. 2^39 - 1 and uses that as ue-Identity.

Why it matters

This is the fallback identity form used when no temporary 5G identity is available for the request.

Practical meaning

In live logs, a randomValue is common in fresh access scenarios where the UE does not yet have a usable 5G-S-TMSI for the current attempt.

4. establishmentCause

This field tells the network why the UE is trying to establish the RRC connection.

The allowed values are:

  • emergency
  • highPriorityAccess
  • mt-Access
  • mo-Signalling
  • mo-Data
  • mo-VoiceCall
  • mo-VideoCall
  • mo-SMS
  • mps-PriorityAccess
  • mcs-PriorityAccess
  • reserved spare values

Why it matters

This is one of the most important fields for troubleshooting. It tells you whether the attempt is driven by:

  • user-originated signaling
  • user-originated data
  • mobile-terminated access
  • emergency traffic
  • priority-service traffic

Important standards detail

The spec explicitly says the gNB is not expected to reject an RRCSetupRequest due to an unknown cause value used by the UE.

That is a useful interoperability point for decoder writers and protocol testers.

5. spare

The message includes a one-bit spare field.

This does not usually carry operational meaning in trace analysis, but it is still part of the ASN.1 definition and should be decoded correctly.

How the UE sets the message fields

The standards-based logic is straightforward.

ue-Identity selection

The UE sets the message identity like this:

  • if upper layers provide a 5G-S-TMSI, use ng-5G-S-TMSI-Part1
  • otherwise, generate and use a 39-bit randomValue

A useful standards note says that upper layers provide the 5G-S-TMSI if the UE is registered in the tracking area of the current cell.

establishmentCause selection

Normally, the UE sets establishmentCause according to information received from upper layers.

There is one notable special case:

  • if RRC connection establishment is the result of release with redirect with mpsPriorityIndication, the UE sets the cause to mps-PriorityAccess

That is an excellent detail to keep in mind when analyzing unusual priority-access traces.

RRCSetupRequest does not carry the NAS message

This is a very common misunderstanding.

Although the overall RRC connection establishment procedure is used to transfer the initial NAS message from the UE to the network, the RRCSetupRequest message itself does not carry the NAS payload.

Instead:

  • RRCSetupRequest asks for the connection
  • RRCSetup establishes SRB1
  • RRCSetupComplete carries the initial NAS dedicated information or message

For troubleshooting, this distinction is critical. If you are looking for Registration Request, do not expect to find it inside RRCSetupRequest.

RRCSetupRequest vs RRCSetup

  • RRCSetupRequest is sent by the UE to ask for a connection.
  • RRCSetup is sent by the gNB to accept the request and configure SRB1.

RRCSetupRequest vs RRCSetupComplete

  • RRCSetupRequest does not carry NAS.
  • RRCSetupComplete confirms setup and carries the initial NAS message.

RRCSetupRequest vs RRCResumeRequest

  • RRCSetupRequest starts a new connection establishment from RRC_IDLE.
  • RRCResumeRequest is used when resuming a suspended context from RRC_INACTIVE.

RRCSetupRequest vs RRCReestablishmentRequest

  • RRCSetupRequest is for establishing a connection from idle.
  • RRCReestablishmentRequest is for recovering a previously connected UE after certain radio failures.

These distinctions are essential when classifying access procedures from drive-test or protocol-stack logs.

What to verify in a live trace

When you decode RRCSetupRequest, check the following.

1. Was essential system information acquired first?

The UE should have valid and up-to-date essential system information before initiating the procedure.

2. Which form of ue-Identity was used?

Check whether the UE used:

  • ng-5G-S-TMSI-Part1, or
  • randomValue

This helps explain whether the UE had a prior temporary identity context available.

3. Does the establishmentCause match the scenario?

Examples:

  • mo-Signalling for signaling-driven access
  • mo-Data for data-triggered access
  • mt-Access for mobile-terminated access
  • emergency for emergency setup

If this field does not match the scenario, later behavior may look strange or inconsistent.

4. Did the network answer with RRCSetup or RRCReject?

The next message determines whether the request was accepted.

5. Was T300 started and then handled correctly?

Connection-establishment supervision relies on T300. If the request is sent and nothing valid comes back, this timer becomes relevant in failure analysis.

Why this message is important for SEO and decoder databases

Search terms like 5G RRC Setup Request, RRCSetupRequest decode, 3GPP TS 38.331 RRCSetupRequest, and NR RRC connection establishment message all map to this message.

It is one of the most searched and most practical 5G NR control messages because it sits at the entrance to every new RRC connection attempt from idle.

Summary

If you are looking for RRCSetupRequest in 5G NR, the key point is this:

RRCSetupRequest is the uplink NR RRC message sent by the UE on SRB0 and CCCH to request establishment of an RRC connection, carrying an initial UE identity and an establishment cause.

FAQ

What is RRCSetupRequest in 5G NR?

It is the uplink RRC message the UE sends to request establishment of an RRC connection in NR.

What comes after RRCSetupRequest?

The gNB responds with either RRCSetup if the request is accepted or RRCReject if the procedure cannot be handled.

Does RRCSetupRequest carry a NAS message?

No. The initial NAS message is transferred later in RRCSetupComplete, not in RRCSetupRequest.

What identity is used in RRCSetupRequest?

The UE includes either ng-5G-S-TMSI-Part1 when a 5G-S-TMSI is available or a 39-bit randomValue when it is not.

Summary

Uplink NR RRC message sent by the UE on SRB0 and CCCH to request establishment of an RRC connection.