LTE RRC Connection Reestablishment Reject

Message Fact Sheet

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

Full message name	LTE RRC Connection Reestablishment Reject
Protocol	LTE-RRC
Technology	LTE
Direction	eNodeB -> UE
Interface	Uu
Signaling bearer / channel	SRB0 / DL-CCCH
Typical trigger	The network cannot continue LTE re-establishment after receiving RRCConnectionReestablishmentRequest.
Main purpose	Ends the LTE re-establishment attempt so the UE can leave the failed recovery branch and move into the next fallback behavior.
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 Reject in simple terms?

Downlink LTE RRC message sent by the network when the re-establishment attempt is not accepted.

Ends the LTE re-establishment attempt so the UE can leave the failed recovery branch and move into the next fallback behavior.

Why this message matters

RRCConnectionReestablishmentReject means the LTE network did not accept the UE recovery attempt.

Where this message appears in the call flow

Radio link failure recovery

Call flow position: Network rejection step that ends the LTE re-establishment attempt.

Typical state: UE is in the recovery branch but the earlier connected context is not being restored.

Preconditions:

RRCConnectionReestablishmentRequest was received.
The network cannot accept recovery.

Next likely message: Fresh access signaling or idle fallback behavior

Handover failure recovery

Call flow position: Recovery-reject message used when the failed mobility path cannot be recovered through re-establishment.

Typical state: UE is leaving the recovery branch and must move into a fallback path.

Preconditions:

The mobility-related failure path reached re-establishment.
The network cannot continue recovery.

Next likely message: Fresh setup or other fallback behavior

Call flow position

Previous message(s): RRCConnectionReestablishmentRequest

Next message(s): Fresh connection setup path, Idle-side fallback behavior, Later release or access retry behavior

Message direction and transport

Sender and receiver: eNodeB -> UE

Interface: Uu

Domain: Access-side radio control recovery

Signaling bearer: SRB0

Logical channel: DL-CCCH

Transport / encapsulation: RRC over CCCH during recovery failure handling

Security context: Sent while the UE is trying to recover a broken connected context, before any restored dedicated path exists.

Message Structure Overview

RRCConnectionReestablishmentReject is structurally simple and mainly valuable because of what it means procedurally.
The useful reading path is not inside the payload. It is the next fallback behavior after recovery is denied.
This message is the boundary between failed recovery and the following fresh-access or idle-side branch.

ASN.1 for LTE RRC Connection Reestablishment Reject

RRCConnectionReestablishmentReject ::= SEQUENCE {
  criticalExtensions CHOICE {
    c1 CHOICE {
      rrcConnectionReestablishmentReject-r8 RRCConnectionReestablishmentReject-r8-IEs,
      spare3 NULL,
      spare2 NULL,
      spare1 NULL
    },
    criticalExtensionsFuture SEQUENCE {}
  }
}

RRCConnectionReestablishmentReject-r8-IEs ::= SEQUENCE {
  nonCriticalExtension RRCConnectionReestablishmentReject-v8a0-IEs OPTIONAL
}

How to read this ASN.1

The message is intentionally small. The main analysis value comes from the fact that recovery was denied and the UE must move into a fallback path.

LTE RRC Connection Reestablishment Reject - Example Dump

DL-CCCH-Message
  message c1 : rrcConnectionReestablishmentReject : {
    criticalExtensions c1 : rrcConnectionReestablishmentReject-r8 : {
    }
  }

How to read this dump

The main significance is procedural, not payload-heavy.
After this message, the useful next read is the fallback path rather than the reject structure itself.
If the UE later starts fresh access, that is usually expected behavior after the reject.

Important Information Elements

IE	Required	Description
`criticalExtensions`	Yes	Top-level wrapper for the reject message.
`nonCriticalExtension`	Optional	Release-extension branch for later additions.

Detailed field explanation

`criticalExtensions`

Top-level wrapper for the reject message.

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.

`nonCriticalExtension`

Release-extension branch for later additions.

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 follows RRCConnectionReestablishmentRequest.
Check what fallback behavior follows next.
Correlate the reject with the earlier failure cause and candidate-cell assumptions.
If a fresh access path starts next, treat that as the main continuation.
Do not stop at the reject; follow the next branch.

Common Issues and Troubleshooting

Recovery is attempted but the network rejects it.

Likely cause: The earlier connected context may no longer be recoverable, the identity may not match, or the recovery path may not be allowed.

What to inspect: Check the earlier failure path, UE identity assumptions, and the cell where recovery was attempted.

Next step: Follow the fallback path into fresh setup or idle behavior.

The reject appears after handover failure.

Likely cause: The failed mobility path may no longer be recoverable through re-establishment.

What to inspect: Read the reject together with the earlier mobility failure and what the UE does next.

Next step: Move from recovery analysis into fallback access analysis.

The trace ends at the reject.

Likely cause: The most useful part of the story may be missing after the reject.

What to inspect: Check whether the trace captured the later fresh access or idle fallback behavior.

Next step: Extend the trace window beyond the reject.

LTE / 5G / Variant Comparison

Compared with RRCConnectionReestablishment

RRCConnectionReestablishment accepts recovery. RRCConnectionReestablishmentReject ends the recovery attempt.

Compared with RRCConnectionRequest

After reject, the UE often has to move into a fresh access path that starts with RRCConnectionRequest.

FAQ

What is RRCConnectionReestablishmentReject in LTE?

It is the downlink LTE RRC message the network sends when the re-establishment attempt is not accepted.

What usually comes after RRCConnectionReestablishmentReject?

The UE usually moves into a fresh access path or another fallback behavior.

What should I inspect first in RRCConnectionReestablishmentReject?

Start with the earlier failure context and then follow the fallback path that comes after the reject.

Does the reject carry a detailed cause?

No. The message is structurally small, so the useful clues come from the wider procedure 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.