LTE RRC Connection Reestablishment Request

Message Fact Sheet

Protocol	lte-rrc	Network	lte
Spec	3GPP TS 36.331	Spec Section	5.3.7, 6.2.2, Annex B
Direction	UE -> eNodeB	Message Type	Connection Recovery

Full message name	LTE RRC Connection Reestablishment Request
Protocol	LTE-RRC
Technology	LTE
Direction	UE -> eNodeB
Interface	Uu
Signaling bearer / channel	SRB0 / UL-CCCH
Typical trigger	The UE detects a re-establishment-eligible failure such as radio link failure, handover failure, or another condition that allows LTE RRC re-establishment.
Main purpose	Starts the LTE re-establishment procedure so the UE can recover a broken connected RRC context without going through a full fresh connection setup immediately.
Main specification	3GPP TS 36.331, 5.3.7, 6.2.2, Annex B
Release added	Release 8
Procedures where used	RRC Re-establishment, Radio Link Failure Recovery, Handover Failure Recovery

What is LTE RRC Connection Reestablishment Request in simple terms?

Uplink LTE RRC message sent by the UE to request re-establishment after radio link failure, handover failure, or other re-establishment-eligible failure conditions.

Starts the LTE re-establishment procedure so the UE can recover a broken connected RRC context without going through a full fresh connection setup immediately.

Why this message matters

RRCConnectionReestablishmentRequest is the LTE UE asking the network to recover a broken connected RRC context.

Where this message appears in the call flow

Radio link failure recovery

Call flow position: First uplink message in the LTE re-establishment recovery path after the connected context breaks.

Typical state: UE is no longer able to continue normal connected-mode signaling and is attempting recovery.

Preconditions:

The UE had an earlier connected context.
A re-establishment-eligible failure condition was detected.
The UE selected a candidate cell for the recovery attempt.

Next likely message: RRCConnectionReestablishment or RRCConnectionReestablishmentReject

Handover failure recovery

Call flow position: Recovery request sent when mobility continuation failed and the UE falls into the LTE re-establishment path.

Typical state: UE is recovering from a failed connected mobility transition.

Preconditions:

The earlier handover-related path did not complete cleanly.
Re-establishment is still allowed for the UE context.

Next likely message: RRCConnectionReestablishment or fallback to fresh access

Call flow position

Previous message(s): Connected-mode LTE RRC signaling before failure, Failure detection and re-establishment decision

Next message(s): RRCConnectionReestablishment, RRCConnectionReestablishmentReject, Fresh connection setup if re-establishment does not continue

Message direction and transport

Sender and receiver: UE -> eNodeB

Interface: Uu

Domain: Access-side radio control recovery

Signaling bearer: SRB0

Logical channel: UL-CCCH

Transport / encapsulation: RRC over CCCH during re-establishment access before a new dedicated SRB1 context is rebuilt

Security context: Triggered from a failed connected context, but sent on CCCH during the recovery attempt rather than as normal protected SRB1 signaling.

Message Structure Overview

RRCConnectionReestablishmentRequest is a compact request message used only at the start of the recovery path.
The practical reading path is the cause value, the UE identity, and what the network does next.
This message is most useful when read as the boundary between failure detection and recovery outcome.

ASN.1 for LTE RRC Connection Reestablishment Request

RRCConnectionReestablishmentRequest ::= SEQUENCE {
  criticalExtensions CHOICE {
    rrcConnectionReestablishmentRequest-r8 RRCConnectionReestablishmentRequest-r8-IEs,
    criticalExtensionsFuture SEQUENCE {}
  }
}

RRCConnectionReestablishmentRequest-r8-IEs ::= SEQUENCE {
  ue-Identity           ReestabUE-Identity,
  reestablishmentCause  ReestablishmentCause,
  spare                 BIT STRING (SIZE (2))
}

How to read this ASN.1

The message is structurally small. The useful checks are the re-establishment cause, the UE identity used for recovery, and the next network response.

LTE RRC Connection Reestablishment Request - Example Dump

UL-CCCH-Message
  message c1 : rrcConnectionReestablishmentRequest : {
    criticalExtensions rrcConnectionReestablishmentRequest-r8 : {
      ue-Identity {
        c-RNTI 0x1234,
        physCellId 205,
        shortMAC-I 0x7A1F
      },
      reestablishmentCause handoverFailure,
      spare '00'B
    }
  }

How to read this dump

Start with reestablishmentCause because it explains why the UE entered the recovery path.
The UE identity fields are critical for correlating the request with the earlier connected context.
The next useful read is whether the network accepts recovery with RRCConnectionReestablishment or rejects it.

Important Information Elements

IE	Required	Description
`ue-Identity`	Yes	Short identity information that helps the network correlate the recovery attempt with the earlier UE context.
`reestablishmentCause`	Yes	Cause field showing whether the re-establishment attempt follows reconfiguration failure, handover failure, or other failure.
`spare`	Optional	Reserved bits with no main troubleshooting value.

Detailed field explanation

`ue-Identity`

Short identity information that helps the network correlate the recovery attempt with the earlier UE 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`

Cause field showing whether the re-establishment attempt follows reconfiguration failure, handover failure, or other 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.

`spare`

Reserved bits with no main troubleshooting value.

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.

What to check in logs and traces

Confirm the message appears after a real connected-mode failure and not during normal setup.
Check the reestablishmentCause value.
Inspect the UE identity fields and candidate-cell context.
Correlate the request with the next response: re-establishment, reject, or fallback to fresh access.
If recovery fails, keep following the path into fresh setup or release behavior.

Common Issues and Troubleshooting

The UE loses connection but no re-establishment request appears.

Likely cause: The failure may not qualify for re-establishment, the UE may restart with fresh access, or the trace may miss the recovery attempt.

What to inspect: Check the failure type, the re-establishment eligibility assumptions, and the next access behavior.

Next step: Determine whether the UE should have attempted re-establishment at all.

RRCConnectionReestablishmentRequest is sent but the network rejects recovery.

Likely cause: The earlier context may no longer be recoverable, the identity may not match, or the target cell may not accept the request.

What to inspect: Check UE identity, candidate-cell assumptions, and the following reject or fallback path.

Next step: Move into the next recovery outcome instead of stopping at the request.

The cause shows handoverFailure but the wider path is unclear.

Likely cause: The mobility path may have broken earlier than expected.

What to inspect: Read the earlier handover-related signaling and compare it with the recovery cause.

Next step: Treat the re-establishment request as the start of the recovery branch, not the start of the problem.

LTE / 5G / Variant Comparison

Compared with RRCConnectionRequest

RRCConnectionRequest starts a fresh LTE connection. RRCConnectionReestablishmentRequest tries to recover an earlier broken connected context.

Compared with RRCConnectionReestablishment

RRCConnectionReestablishmentRequest is the UE recovery request. RRCConnectionReestablishment is the network acceptance that continues the recovery path.

FAQ

What is RRCConnectionReestablishmentRequest in LTE?

It is the uplink LTE RRC message the UE sends to request recovery of a broken connected RRC context.

What usually comes after RRCConnectionReestablishmentRequest?

The network usually responds with RRCConnectionReestablishment or RRCConnectionReestablishmentReject.

What should I inspect first in RRCConnectionReestablishmentRequest?

Start with reestablishmentCause, the UE identity fields, and the next recovery outcome.

How is it different from RRCConnectionRequest?

RRCConnectionRequest starts a fresh connection. RRCConnectionReestablishmentRequest tries to recover an earlier broken connected context.

Related message pages

Related Procedures

Related Tools

Use This Reference in Practice

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.