| Protocol | rrc | Network | 5g |
|---|---|---|---|
| Spec | 3GPP TS 38.331 | Spec Section | 5.3.7, 6.2.2 |
| Direction | UE -> gNB | Message Type | Connection Recovery |
| Full message name | 5G NR - RRC Reestablishment Complete |
|---|---|
| Protocol | RRC |
| Technology | 5G |
| Direction | UE -> gNB |
| Interface | Uu |
| Signaling bearer / channel | SRB1 / UL-DCCH |
| Typical trigger | Used when the UE successfully applies the RRC Reestablishment message. |
| Main purpose | Confirms successful completion of the reestablishment path so normal protected connected-mode operation can continue. |
| Main specification | 3GPP TS 38.331, 5.3.7, 6.2.2 |
| Release added | Release 15 |
| Procedures where used | RRC Reestablishment, Radio Link Failure Recovery |
| Related timers | None highlighted |
RRC Reestablishment Complete is the UE-to-network NR RRC message confirming that reestablishment succeeded and the recovered context is active.
Confirms successful completion of the reestablishment path so normal protected connected-mode operation can continue.
RRC Reestablishment Complete tells the network that recovery succeeded.
Call flow position: Final UE confirmation after successful reestablishment.
Typical state: UE has recovered the RRC context and confirms it.
Preconditions:
Next likely message: Normal connected-mode signaling or later reconfiguration
Previous message(s): RRC Reestablishment
Next message(s): RRC Reconfiguration, Normal connected signaling
Security context: Sent after reestablishment has restored the connected signaling context.
RRCReestablishmentComplete ::= SEQUENCE {
criticalExtensions CHOICE {
rrcReestablishmentComplete RRCReestablishmentComplete-IEs,
...
}
}
The main value is procedural: this message confirms that the recovery path completed.
UL-DCCH-Message
message: rrcReestablishmentComplete
| IE | Required | Description |
|---|---|---|
lateNonCriticalExtension | Optional | Extension field for later releases. |
lateNonCriticalExtensionExtension field for later releases.
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.
Likely cause: The UE may send the complete, but the recovered context may still be unstable.
What to inspect: Check later reconfiguration, measurement, or failure messages after the complete.
Next step: Treat this as the recovery completion point and investigate what broke next.
It means the UE successfully completed the reestablishment procedure.
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.