LTE RRC Connection Reestablishment Complete

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 Complete
Protocol	LTE-RRC
Technology	LTE
Direction	UE -> eNodeB
Interface	Uu
Signaling bearer / channel	SRB1 / UL-DCCH
Typical trigger	The UE successfully applies RRCConnectionReestablishment and is ready to confirm that the recovered connected context is usable.
Main purpose	Confirms that the LTE re-establishment path completed and that the recovered connected context can continue with later dedicated signaling.
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 Complete in simple terms?

Uplink LTE RRC message sent by the UE to confirm that re-establishment recovery was completed successfully.

Confirms that the LTE re-establishment path completed and that the recovered connected context can continue with later dedicated signaling.

Why this message matters

RRCConnectionReestablishmentComplete is the UE confirming that LTE recovery finished successfully.

Where this message appears in the call flow

Radio link failure recovery

Call flow position: UE completion step sent after the network accepted re-establishment and the recovered context was applied successfully.

Typical state: UE is in the recovery success branch and is confirming the restored connected context.

Preconditions:

RRCConnectionReestablishment was received.
The UE could apply the recovered configuration successfully.

Next likely message: Recovered connected-mode LTE signaling

Handover failure recovery

Call flow position: Completion step sent after the mobility-recovery branch succeeded and the restored context is usable.

Typical state: UE is in recovered connected mode after a failed mobility path.

Preconditions:

The recovery-accept message was received.
The UE could continue with the restored context.

Next likely message: Later connected-mode continuation

Call flow position

Previous message(s): RRCConnectionReestablishment

Next message(s): Recovered connected-mode LTE RRC signaling, Later security, bearer, or mobility continuation depending on the scenario

Message direction and transport

Sender and receiver: UE -> eNodeB

Interface: Uu

Domain: Access-side radio control recovery

Signaling bearer: SRB1

Logical channel: UL-DCCH

Transport / encapsulation: RRC over DCCH on the restored dedicated signaling path after re-establishment has been accepted

Security context: Sent after the recovery-accept step on the restored dedicated signaling path.

Message Structure Overview

RRCConnectionReestablishmentComplete is a compact confirmation message in the recovery success branch.
Its practical value is procedural: it confirms that the restored connected context actually completed.
If this message is missing, the network should not assume the recovery path finished successfully.

ASN.1 for LTE RRC Connection Reestablishment Complete

RRCConnectionReestablishmentComplete ::= SEQUENCE {
  rrc-TransactionIdentifier RRC-TransactionIdentifier,
  criticalExtensions CHOICE {
    c1 CHOICE {
      rrcConnectionReestablishmentComplete-r8 RRCConnectionReestablishmentComplete-r8-IEs,
      spare3 NULL,
      spare2 NULL,
      spare1 NULL
    },
    criticalExtensionsFuture SEQUENCE {}
  }
}

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

How to read this ASN.1

The message is structurally simple. The useful checks are transaction pairing and whether later recovered behavior matches a successful recovery path.

LTE RRC Connection Reestablishment Complete - Example Dump

UL-DCCH-Message
  message c1 : rrcConnectionReestablishmentComplete : {
    rrc-TransactionIdentifier 2,
    criticalExtensions c1 : rrcConnectionReestablishmentComplete-r8 : {
    }
  }

How to read this dump

Check that the transaction identifier matches the earlier RRCConnectionReestablishment.
The main significance is that the UE finished the recovery-accept path successfully.
If later behavior still fails, treat this message as the checkpoint that recovery at least completed formally.

Important Information Elements

IE	Required	Description
`rrc-TransactionIdentifier`	Yes	Transaction identifier matching the preceding RRCConnectionReestablishment.
`criticalExtensions`	Yes	Versioned wrapper for the completion message.
`nonCriticalExtension`	Optional	Release-extension branch for later additions.

Detailed field explanation

`rrc-TransactionIdentifier`

Transaction identifier matching the preceding RRCConnectionReestablishment.

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.

`criticalExtensions`

Versioned wrapper for the completion 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 RRCConnectionReestablishment.
Verify the transaction identifier matches the acceptance message.
Check whether later connected behavior reflects a stable recovered context.
Correlate the message with the earlier failure cause and later continuation.
If the message is missing, do not assume recovery succeeded.

Common Issues and Troubleshooting

RRCConnectionReestablishment is present but the complete message never appears.

Likely cause: The UE may have failed to apply the recovered configuration or the recovery path may have broken again before completion.

What to inspect: Check the recovery-accept content, the radio behavior after acceptance, and whether the UE had a chance to send the completion.

Next step: Use the missing completion as the strongest sign that recovery did not finish cleanly.

The complete message is present but later behavior still fails.

Likely cause: Recovery may have completed formally, but the restored context may still be unstable or misaligned with the wider procedure.

What to inspect: Compare the recovered behavior with the earlier failure cause and the restored configuration.

Next step: Continue forward into the recovered connected path instead of re-debugging only the request stage.

Recovery completes after handover failure but service remains unstable.

Likely cause: The UE may have recovered the connected context, but the mobility aftermath may still be problematic.

What to inspect: Read the completion together with the earlier handover failure and the later connected-mode continuation.

Next step: Treat this as recovered-but-unstable behavior.

LTE / 5G / Variant Comparison

Compared with RRCConnectionReestablishment

RRCConnectionReestablishment is the network acceptance of recovery. RRCConnectionReestablishmentComplete is the UE confirmation that the accepted recovery finished.

Compared with RRCConnectionSetupComplete

Both are UE completion messages, but one confirms fresh setup and the other confirms recovery of an earlier broken context.

FAQ

What is RRCConnectionReestablishmentComplete in LTE?

It is the uplink LTE RRC message the UE sends to confirm that re-establishment recovery completed successfully.

What should I inspect first in RRCConnectionReestablishmentComplete?

Start with the transaction identifier, the earlier recovery-accept message, and whether later connected behavior is stable.

What does it mean if RRCConnectionReestablishmentComplete is missing?

It is a strong clue that the recovery branch did not finish cleanly.

Does this message guarantee that everything is healthy again?

No. It confirms formal completion of recovery, but later connected behavior can still fail or remain unstable.

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.