Telecom engineering reference for protocols, messages, call flows, troubleshooting, releases, and tools.
Menu
LTE RRCLTEUE -> eNodeB3GPP TS 36.331
LTE - RRCConnectionRequest
Uplink LTE RRC message sent by the UE on SRB0 and UL-CCCH to request establishment of an RRC connection.
Message Fact Sheet
Protocol
lte-rrc
Network
lte
Spec
3GPP TS 36.331
Spec Section
5.3.3.1, 5.3.3.2, 5.3.3.3, 6.2.2
Direction
UE -> eNodeB
Message Type
Connection Control
Full message name
LTE - RRCConnectionRequest
Protocol
LTE-RRC
Technology
LTE
Direction
UE -> eNodeB
Interface
Uu
Signaling bearer / channel
SRB0 / UL-CCCH
Typical trigger
Upper layers request an RRC connection while the UE is in RRC_IDLE and has already acquired the required broadcast information for the serving cell.
Main purpose
Starts LTE RRC connection establishment and provides the initial UE identity and establishment cause needed for admission, prioritization, and later contention resolution handling.
Main specification
3GPP TS 36.331, 5.3.3.1, 5.3.3.2, 5.3.3.3, 6.2.2
Release added
Release 8
Procedures where used
RRC Connection Establishment, Initial Access, Paging Response from Idle, Mobile Originated Signalling, Mobile Originated Data, Emergency Access
Uplink LTE RRC message sent by the UE on SRB0 and UL-CCCH to request establishment of an RRC connection.
Starts LTE RRC connection establishment and provides the initial UE identity and establishment cause needed for admission, prioritization, and later contention resolution handling.
Why this message matters
RRCConnectionRequest is the UE asking the eNodeB for a new LTE RRC connection. It carries just enough identity and cause information for the network to decide whether setup should continue.
Where this message appears in the call flow
LTE initial access
In the initial access path, RRCConnectionRequest appears after system information and random access, then leads into setup or reject.
Call flow position: First dedicated uplink RRC message after random access completes and UL resources are granted for Msg3.
Typical state: UE is in RRC_IDLE and is requesting transition into connected signaling.
Preconditions:
The UE has selected a suitable cell.
Required broadcast information has been acquired.
Random access has progressed far enough to carry Msg3.
Next likely message: RRCConnectionSetup or RRCConnectionReject
Paging response path
In the paging response path, fresh LTE access still uses RRCConnectionRequest after paging-driven wake-up and random access progression.
Call flow position: Entry message used after idle-mode paging when the UE needs fresh access rather than already having a dedicated context.
Typical state: UE is in RRC_IDLE and has been triggered to resume service through fresh access.
Preconditions:
Paging and idle-mode monitoring context are valid.
The UE must perform new access rather than continue an existing connected context.
Next likely message: RRCConnectionSetup
Call flow position
Previous message(s): Random Access Response and Msg3 grant handling, MIB, SIB1, and SIB2 acquisition
The practical reading order is simple: first determine whether the UE used s-TMSI or randomValue, then inspect establishmentCause and place it in the access scenario.
randomValue is normal when the UE does not have usable S-TMSI context.
If s-TMSI is present, compare it with the mobility-management context expected for that UE.
The message does not carry NAS. Initial NAS content appears later in RRCConnectionSetupComplete.
Important Information Elements
IE
Required
Description
ue-Identity
Yes
Initial UE identity used for early access handling and contention resolution support.
s-TMSI
Optional
Temporary identity form used when the UE already has S-TMSI context from earlier registration.
randomValue
Optional
Forty-bit random value used when S-TMSI is not available.
establishmentCause
Yes
Indicates why the UE is requesting the RRC connection, such as mobile-originated signaling, data, mobile-terminated access, emergency, or high-priority access.
spare
Yes
Reserved spare bit included by the ASN.1 message definition.
Detailed field explanation
ue-Identity
Initial UE identity used for early access handling and contention resolution support.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
s-TMSI
Temporary identity form used when the UE already has S-TMSI context from earlier registration.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
randomValue
Forty-bit random value used when S-TMSI is not available.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
establishmentCause
Indicates why the UE is requesting the RRC connection, such as mobile-originated signaling, data, mobile-terminated access, emergency, or high-priority access.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
spare
Reserved spare bit included by the ASN.1 message definition.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
What to check in logs and traces
Check whether the message appears after MIB, SIB1, SIB2, and random access progression.
Verify whether ue-Identity uses s-TMSI or randomValue.
Inspect establishmentCause and compare it with the expected scenario.
Confirm T300 behavior matches the request and following response.
Correlate the request with RRCConnectionSetup or RRCConnectionReject.
Common Issues and Troubleshooting
RRCConnectionRequest is missing.
Likely cause: The UE may still be blocked in broadcast acquisition, access barring, or random access before Msg3 is sent.
What to inspect: Check system information, access control, PRACH activity, Random Access Response, and Msg3 grant handling.
Next step: Validate the access path before looking for later dedicated RRC messages.
The network rejects or deprioritizes the request.
Likely cause: The establishment cause may indicate access that is barred, deprioritized, or not expected for the scenario.
What to inspect: Check establishmentCause, access-class handling, barring context, and compare with a successful attempt.
Next step: Verify whether the cause matches the trigger under test.
Later setup fails even though RRCConnectionRequest was sent.
Likely cause: The break point may be in RRCConnectionSetup, SRB1 creation, or the later setup-complete path rather than in the request itself.
What to inspect: Use this message as the entry point, then walk forward through setup, setup complete, and security-related control.
Next step: Inspect the next dedicated downlink RRC message and the UE response path.
LTE / 5G / Variant Comparison
Compared with NR RRCSetupRequest
The LTE and NR messages play the same early access role, but LTE uses s-TMSI or a 40-bit random value in InitialUE-Identity and stays inside the LTE TS 36.331 connection-establishment model.
FAQ
What is RRCConnectionRequest in LTE?
It is the uplink LTE RRC message the UE sends to request establishment of an RRC connection.
What comes after RRCConnectionRequest?
The eNodeB responds with either RRCConnectionSetup if the request is accepted or RRCConnectionReject if the procedure cannot continue.
Does RRCConnectionRequest carry NAS?
No. The initial NAS message is carried later in RRCConnectionSetupComplete, not in RRCConnectionRequest.
What identity is used in RRCConnectionRequest?
The UE includes either s-TMSI when it has valid temporary identity context or a 40-bit randomValue when it does not.
Decode this message with the 3GPP Decoder, inspect the related message database, or open the matching call flow to see where this signaling step fits in the full procedure.
