RRC 5G UE -> gNB 3GPP TS 38.331

5G NR - RRC Reestablishment Request

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.
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
Related cause values	reconfigurationFailure, handoverFailure, otherFailure
Main specification	3GPP TS 38.331, 5.3.7.1, 5.3.7.2, 5.3.7.4, 6.2.2

What this message does 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 is used

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

Full Procedure Context

Previous message(s): Radio link failure / out-of-sync sequence, Failed handover or reconfiguration path

Next message(s): RRCReestablishment, RRCSetup

Message Direction and Transport

Sender and receiver: UE -> gNB

Interface: Uu

Domain: Access-side radio recovery

Signaling bearer: SRB0

Logical channel: UL-CCCH

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.

ASN.1 for 5G NR - RRC Reestablishment Request

RRCReestablishmentRequest ::= SEQUENCE {
  rrcReestablishmentRequest RRCReestablishmentRequest-IEs
}

RRCReestablishmentRequest-IEs ::= SEQUENCE {
  ue-Identity           ReestabUE-Identity,
  reestablishmentCause  ReestablishmentCause,
  spare                 BIT STRING (SIZE (1))
}

ReestabUE-Identity ::= SEQUENCE {
  c-RNTI      C-RNTI,
  physCellId  PhysCellId,
  shortMAC-I  ShortMAC-I
}

How to read this ASN.1

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.

Decoded Message Dump

UL-CCCH-Message
  message: rrcReestablishmentRequest
    rrcReestablishmentRequest:
      ue-Identity:
        c-RNTI: 0x46A1
        physCellId: 321
        shortMAC-I: 0x9C7E
      reestablishmentCause: handoverFailure
      spare: 0

How to read this 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.

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

`c-RNTI`

The C-RNTI from the source PCell, or from the PCell where the failure that triggered re-establishment occurred.

Presence: Required

`physCellId`

The physical cell identity of the PCell the UE was connected to before the failure.

Presence: Required

`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

`reestablishmentCause`

Indicates why re-establishment was triggered. The UE sets it to reconfigurationFailure, handoverFailure, or otherFailure.

Presence: Required

`spare`

Reserved spare bit present in the ASN.1 definition.

Presence: Required

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.

Detailed explanation

5G NR - RRC Reestablishment Request

The RRCReestablishmentRequest message is the 5G NR uplink RRC recovery message used when a UE was already connected, had an existing protected access-stratum context, and then encountered a failure that requires connection recovery instead of a brand-new setup.

This message is important because it decides whether the network can resume the old UE context or whether the procedure must fall back to a fresh RRCSetup flow.

Message sequence

Successful re-establishment

UE                              gNB
 |                               |
 |--- RRCReestablishmentRequest ->|
 |                               |
 |<-- RRCReestablishment --------|
 |                               |
 |--- RRCReestablishmentComplete ->|
 |                               |

Fallback path

UE                              gNB
 |                               |
 |--- RRCReestablishmentRequest ->|
 |                               |
 |<-- RRCSetup ------------------|
 |                               |
 |--- RRCSetupComplete --------->|
 |                               |

Why this message matters

5G NR RRC Reestablishment Request is one of the most important recovery messages in the RRC layer. It is commonly seen after:

radio link failure
handover failure
RRC reconfiguration failure
other connected-mode recovery scenarios

Unlike RRCSetupRequest, this message is not asking the gNB to create a brand-new UE context. It is asking the network to identify the UE, verify it using shortMAC-I, and recover the previous RRC connection if possible.

Transport characteristics

Direction: UE to network
Signaling radio bearer: SRB0
RLC mode: TM
Logical channel: CCCH
Message class: UL-CCCH

These transport details are important in live traces because they help separate RRCReestablishmentRequest from later recovery messages such as RRCReestablishmentComplete, which are sent on SRB1/DCCH.

When the UE sends RRCReestablishmentRequest

A UE does not send this message in every failure case. It is used in the RRC connection re-establishment procedure when the UE has a valid prior context and the failure scenario allows recovery.

Typical trigger scenarios include:

MCG radio link failure
handover failure
reconfiguration with sync failure
RRC reconfiguration failure

If the network can retrieve and verify the old UE context, it answers with RRCReestablishment. If not, it may respond with RRCSetup and start a fresh connection-establishment procedure.

ASN.1 structure

RRCReestablishmentRequest ::= SEQUENCE {
  rrcReestablishmentRequest RRCReestablishmentRequest-IEs
}

RRCReestablishmentRequest-IEs ::= SEQUENCE {
  ue-Identity ReestabUE-Identity,
  reestablishmentCause ReestablishmentCause,
  spare BIT STRING (SIZE (1))
}

ReestabUE-Identity ::= SEQUENCE {
  c-RNTI RNTI-Value,
  physCellId PhysCellId,
  shortMAC-I ShortMAC-I
}

ReestablishmentCause ::= ENUMERATED {
  reconfigurationFailure,
  handoverFailure,
  otherFailure,
  spare1
}

Important information elements

1. ue-Identity

This IE is used by the network to retrieve the UE context and support lower-layer contention resolution.

2. c-RNTI

The c-RNTI points to the C-RNTI of the source PCell, or the PCell where the triggering failure occurred.

3. physCellId

The physCellId identifies the physical cell identity of the source PCell the UE was connected to before the failure.

4. shortMAC-I

shortMAC-I is a compact verification value derived from the previous AS security context. It is one of the most important fields in the message because it helps the network identify and validate the UE during re-establishment.

5. reestablishmentCause

The reestablishmentCause field tells the network why recovery was triggered. In practical decoding, this field quickly tells you whether the issue was related to mobility, reconfiguration, or another connected-mode failure.

What to verify in a live trace

When analyzing 5G NR RRC Reestablishment Request, check the following:

Is the message on SRB0 / CCCH / TM?
Does reestablishmentCause match the earlier failure event?
Do c-RNTI and physCellId line up with the source serving cell?
Is shortMAC-I present?
Does the next network response become RRCReestablishment or RRCSetup?

Example decode

UL-CCCH-Message
  message: rrcReestablishmentRequest
  rrcReestablishmentRequest:
    ue-Identity:
      c-RNTI: 0x46A1
      physCellId: 321
      shortMAC-I: 0x9C7E
    reestablishmentCause: handoverFailure
    spare: 0

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.

Summary

If you are searching for 5G NR RRC Reestablishment Request, NR RRCReestablishmentRequest decode, RRC Reestablishment Request shortMAC-I, or 3GPP TS 38.331 RRCReestablishmentRequest, this is the key point:

RRCReestablishmentRequest is the uplink 5G NR recovery message sent by the UE on SRB0 and CCCH to request continuation of an existing RRC connection after failures such as radio link failure, handover failure, or reconfiguration failure.

Advanced Engineer Notes

This message is tiny on the air but deeply dependent on history: old c-RNTI, old physical cell, and old security context.
A fallback RRCSetup after this message is not automatically a bug; it can be the correct recovery behavior when context retrieval fails.
shortMAC-I problems usually point to context or security continuity issues rather than generic radio setup issues.

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.

Related Messages

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.