Uplink NR RRC message sent by the UE on SRB0 and CCCH to request re-establishment of an existing RRC connection after radio link failure, handover failure, or reconfiguration failure.
Message Fact Sheet
Protocol
rrc
Network
5g
Spec
3GPP TS 38.331
Spec Section
5.3.7.1, 5.3.7.2, 5.3.7.4, 6.2.2
Direction
UE -> gNB
Message Type
Connection Recovery
Full message name
5G NR - RRC Reestablishment Request
Protocol
RRC
Technology
5G
Direction
UE -> gNB
Interface
Uu
Signaling bearer / channel
SRB0 / UL-CCCH
Typical trigger
Radio link failure, handover failure, or reconfiguration failure after the UE already had an existing protected access-stratum context.
Main purpose
Requests the network to recover the UE's previous access-stratum context and continue the existing RRC connection. If the context cannot be found or verified, the network may fall back to a fresh RRCSetup procedure.
Main specification
3GPP TS 38.331, 5.3.7.1, 5.3.7.2, 5.3.7.4, 6.2.2
Release added
Release 15
Procedures where used
RRC Connection Re-establishment, Radio Link Failure Recovery, Handover Failure Recovery, RRC Reconfiguration Failure Recovery, Fallback to New RRC Connection Establishment
Related timers
T301
What is RRC Reestablishment Request in simple terms?
Uplink NR RRC message sent by the UE on SRB0 and CCCH to request re-establishment of an existing RRC connection after radio link failure, handover failure, or reconfiguration failure.
Requests the network to recover the UE's previous access-stratum context and continue the existing RRC connection. If the context cannot be found or verified, the network may fall back to a fresh RRCSetup procedure.
Why this message matters
RRCReestablishmentRequest is the UE asking the network to recover an old connected radio context after something failed, instead of starting from zero.
Where this message appears in the call flow
RRC Connection Re-establishment
Call flow position: Opening recovery message from the UE after connected-mode failure.
Typical state: UE previously had a connected context and is trying to recover it rather than starting from scratch.
Preconditions:
A previous AS security context existed.
Re-establishment is still allowed by the failure and cell conditions.
Next likely message: RRCReestablishment or fallback RRCSetup
Call flow position
Previous message(s): Radio link failure / out-of-sync sequence, Failed handover or reconfiguration path
Transport / encapsulation: RRC recovery signaling over CCCH on RLC TM
Security context: The message is transmitted on SRB0 but depends on the previously established AS security context because shortMAC-I is derived from that earlier context.
Message Structure Overview
The ue-Identity container is actually the operational core because it groups c-RNTI, physCellId, and shortMAC-I for context lookup and verification.
reestablishmentCause tells the network what kind of connected-mode failure led to this recovery attempt.
This message is short, but it assumes a great deal of prior context from the failed connection.
Unlike a fresh setup request, this message only makes sense when the network can match the supplied c-RNTI, source physical cell, and shortMAC-I against an existing security-backed context.
5G NR - RRC Reestablishment Request - Example Dump
shortMAC-I is one of the first fields to inspect because it tells you whether the recovery request can be validated against the old security context.
physCellId should refer to the source or failing PCell that the UE is trying to recover from.
handoverFailure versus reconfigurationFailure versus otherFailure changes the interpretation of the surrounding trace.
Important Information Elements
IE
Required
Description
ue-Identity
Yes
Identity container used by the target cell to retrieve UE context and support lower-layer contention resolution.
c-RNTI
Yes
The C-RNTI from the source PCell, or from the PCell where the failure that triggered re-establishment occurred.
physCellId
Yes
The physical cell identity of the PCell the UE was connected to before the failure.
shortMAC-I
Yes
A 16-bit verification value used to identify and verify the UE during re-establishment. It is derived from the previous AS security context.
reestablishmentCause
Yes
Indicates why re-establishment was triggered. The UE sets it to reconfigurationFailure, handoverFailure, or otherFailure.
spare
Yes
Reserved spare bit present in the ASN.1 definition.
Detailed field explanation
ue-Identity
Identity container used by the target cell to retrieve UE context and support lower-layer contention resolution.
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.
c-RNTI
The C-RNTI from the source PCell, or from the PCell where the failure that triggered re-establishment occurred.
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.
physCellId
The physical cell identity of the PCell the UE was connected to before the failure.
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.
shortMAC-I
A 16-bit verification value used to identify and verify the UE during re-establishment. It is derived from the previous AS security context.
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.
reestablishmentCause
Indicates why re-establishment was triggered. The UE sets it to reconfigurationFailure, handoverFailure, or otherFailure.
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 present in the ASN.1 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
Confirm that the UE really had a prior connected context and that re-establishment is allowed in this scenario.
Inspect c-RNTI, physCellId, and shortMAC-I together.
Check the reestablishmentCause against the actual trigger seen earlier in the trace.
Correlate the request with preceding out-of-sync, failure, or handover events.
Verify whether the network responds with RRCReestablishment or falls back to RRCSetup.
Common Issues and Troubleshooting
The network ignores or rejects the re-establishment attempt.
Likely cause: The old UE context cannot be found or shortMAC-I verification fails.
What to inspect: Check c-RNTI, physCellId, shortMAC-I, and whether the target cell has access to the required old context.
Next step: Determine whether fallback to fresh RRCSetup is the expected behavior.
The UE sends re-establishment when a fresh setup would have been expected.
Likely cause: The UE may believe a recoverable AS context still exists after a failure.
What to inspect: Review the preceding failure cause and UE state assumptions.
Next step: Compare behavior against spec conditions for re-establishment eligibility.
Recovery loops repeat without stable reconnection.
Likely cause: The context recovery path is failing repeatedly due to mismatch, wrong target, or stale security context.
What to inspect: Look at repeated shortMAC-I validation attempts, target cell choice, and fallback handling.
Next step: Break the loop by validating whether a fresh setup path should be used instead.
LTE / 5G / Variant Comparison
Compared with fresh RRCSetupRequest
RRCSetupRequest starts a brand-new connection with only minimal identity and cause context. RRCReestablishmentRequest tries to recover a previous protected context and therefore depends on shortMAC-I, old c-RNTI, and source cell identity.
FAQ
What is RRCReestablishmentRequest in 5G NR?
It is the uplink NR RRC recovery message the UE sends to request re-establishment of an existing RRC connection after a connected-mode failure.
Does RRCReestablishmentRequest use SRB0 or SRB1?
It is sent on SRB0 using CCCH and RLC TM, not on SRB1.
What is shortMAC-I in RRCReestablishmentRequest?
shortMAC-I is a 16-bit verification value derived from the previous AS security context and used by the network to identify and validate the UE during re-establishment.
What comes after RRCReestablishmentRequest?
If the network can retrieve and verify the UE context, it responds with RRCReestablishment and the UE then sends RRCReestablishmentComplete. If not, the network may fall back to RRCSetup followed by RRCSetupComplete.
Can any connected UE send RRCReestablishmentRequest?
No. The UE initiates re-establishment only when the required AS security and bearer conditions are satisfied.
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.