Home / Call Flows / LTE / RRC Connection Reject Procedure

LTE RRC Connection Reject Procedure Call Flow

call-flow LTE | E-UTRAN | RRC | MAC | PHY

LTE RRC Connection Reject is the negative radio-side response sent when the eNB does not admit the UE into connected signaling. It appears after RRC Connection Request and usually leaves the UE in idle behavior with retry or wait-time handling.

If this branch appears, the higher-layer procedure that triggered access does not continue through a normal connected path. The most useful checks are the request context, cell conditions, congestion pattern, and any reject wait time.

Introduction

The LTE RRC Connection Reject procedure covers the failure branch where the eNB decides not to grant a fresh connected signaling context. It is still part of LTE access analysis because it explains why later attach, service request, paging response, or other NAS continuation never appears.

The main nodes are the UE and eNB. The UE sends RRC Connection Request, the eNB evaluates the attempt, and the negative outcome is returned through RRC Connection Reject.

What Is LTE RRC Connection Reject in Simple Terms?

What starts the procedure: The UE asks for connected signaling, but the network does not accept the attempt.
What the UE and network want to achieve: The UE wants access to connected signaling, while the eNB applies admission control and cell policy.
What success looks like: From the network point of view, the reject is delivered cleanly and the UE applies the expected backoff or retry behavior.
What failure means: The UE keeps retrying unexpectedly, retries too early, or the reject pattern hides a deeper access or load problem.

Why this procedure matters

This branch is one of the clearest reasons why a later LTE procedure never begins. It also separates radio admission failure from NAS or EPC failure very quickly.

Quick Fact Sheet

Procedure name	LTE RRC Connection Reject Procedure
Domain	E-UTRAN radio access rejection
Main trigger	The UE requests a new RRC connection, but the eNB does not admit it
Start state	UE is in RRC_IDLE and tries to enter connected signaling
End state	UE remains in RRC_IDLE and applies wait-time or retry behavior
Main nodes	UE, eNB
Main protocols	RRC, MAC, PHY
Main success outcome	The reject is delivered clearly and the UE follows the expected backoff behavior
Main failure outcome	Repeated retries, hidden congestion, or misleading escalation toward later-layer analysis
Most important messages	RRC Connection Request, RRC Connection Reject
Main specs	TS 36.331, TS 36.321, TS 36.300

LTE RRC Connection Reject procedure call flow across UE and eNB — Click the diagram to open the full-size in a new tab.

Preconditions

The UE has selected a suitable LTE cell and has the system information needed for access.
The UE has a reason to request connected signaling, such as attach, paging response, or uplink control activity.
The random-access side of the attempt has progressed far enough for an RRC request to be processed.
The eNB has enough context to decide whether to admit or reject the attempt.

Nodes involved

Node	Role in this procedure
UE	Requests connected signaling and applies the reject wait-time or retry behavior if the attempt is not admitted.
eNB	Evaluates admission, access policy, and load conditions, then returns the reject outcome.

Interfaces used

Interface or channel context	Path	Why it matters here
LTE Uu	UE <-> eNB	Carries the request and reject messages over the radio interface.
CCCH	UE <-> eNB	The reject branch happens before a dedicated DCCH path exists.
MAC access context	UE <-> eNB	Helps explain whether the request reached the stage where the reject could be generated and delivered.

End-to-end call flow

UE                          eNB
|                            |
|-- RRC Connection Request ->|
|                            |
|<- RRC Connection Reject ---|
|                            |
|   wait time / retry later  |

This is the negative branch of fresh RRC connection establishment. No dedicated connected signaling path is created.

Major phases

Phase	What happens
1. Access need appears	The UE decides it must leave idle-only behavior and sends a fresh connection request.
2. Admission decision	The eNB checks load, access policy, barring conditions, and overall request context.
3. Reject delivery	The eNB returns RRC Connection Reject instead of granting RRC Connection Setup.
4. Backoff or retry	The UE remains idle and follows the returned wait-time behavior or later reattempt logic.

Step-by-step breakdown

Step 1: Access trigger

Sender -> receiver: UE internal trigger

Message(s): No RRC message yet

Purpose: Start the attempt to move from idle monitoring into connected signaling.

State or context change: UE prepares a fresh access attempt from RRC_IDLE.

Note: The later rejected procedure often reflects attach, paging response, or uplink control intent rather than a pure radio-only action.

Step 2: RRC Connection Request

Sender -> receiver: UE -> eNB

Message(s): RRC Connection Request

Purpose: Ask the eNB to create a fresh connected signaling path.

State or context change: The eNB now has enough early request context to evaluate the attempt.

Note: The establishment cause is the fastest clue for what the UE was trying to do next.

Step 3: RRC Connection Reject

Sender -> receiver: eNB -> UE

Message(s): RRC Connection Reject

Purpose: Tell the UE that the current attempt is not being admitted.

State or context change: No connected signaling path is created, and the UE remains outside RRC_CONNECTED.

Note: Wait time is usually the most useful field because it explains when a retry becomes valid.

Step 4: Idle hold or retry

Sender -> receiver: UE internal behavior

Message(s): No immediate follow-up RRC success message

Purpose: Keep the UE from reattempting too early and preserve cell-level stability.

State or context change: UE remains in idle behavior until a later valid attempt is made.

Note: If retries happen too quickly, the problem may be UE-side handling or a trace that combines multiple cells or attempts.

Important messages

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
RRC Connection Request	RRC	UE -> eNB	Starts the fresh access attempt.	Establishment cause, retry pattern, and timing of repeated attempts.
RRC Connection Reject	RRC	eNB -> UE	Rejects the request instead of granting connected signaling.	Wait time, reject cadence, and whether congestion or barring is likely.

Important parameters to inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Establishment cause	The request reason sent by the UE.	RRC Connection Request	Shows which higher-layer path was trying to start.	Unexpected emergency or high-priority access category, wrong test assumption.
Wait time	The backoff timer guidance returned by the eNB.	RRC Connection Reject	Explains when the UE is expected to retry.	UE retries too early, field missing in decoded trace, merged attempts.
Serving cell identity	The specific LTE cell handling the rejected attempt.	Around the request and reject	Helps separate cell-specific load from broader network behavior.	Wrong-cell correlation, neighbor confusion, reselection during retries.
Attempt timing	The spacing between repeated request and reject events.	Whole reject sequence	Shows whether the UE follows the expected idle retry pattern.	Retry storm, missing requests, trace capture gaps.
Cell load or barring context	Supporting radio and admission conditions near the reject.	Surrounding radio trace and cell metrics	Often explains why the eNB did not admit the attempt.	Congestion assumed without evidence, barring overlooked, overload hidden in adjacent logs.

Successful completion of the procedure

The procedure is complete when the reject reaches the UE and the UE applies the expected idle behavior instead of forcing an immediate new access attempt. There is no transition into RRC_CONNECTED.

Common failures in LTE RRC Connection Reject

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Repeated reject loop	Persistent congestion, admission policy, or UE retry behavior not honoring wait time.	Reject cadence, wait time, same-cell repeats.	RRC Connection Request, RRC Connection Reject	LTE Uu	Decide whether the loop is network load, barring, or UE retry handling.
No later NAS starts	The higher-layer procedure never got a radio path.	Whether any RRC Connection Setup ever appears after the request.	RRC Connection Request, RRC Connection Reject	LTE Uu	Keep analysis on the radio side before checking MME or EPC logs.
Reject seen only in one trace layer	Partial capture, decode gap, or timing mismatch.	Air trace completeness and repeated request evidence.	RRC Connection Reject	LTE Uu	Confirm the reject really reached the UE before drawing retry conclusions.
Reject appears in unexpected low-load conditions	Cell policy, access class handling, or wrong scenario setup.	Establishment cause, access class, cell policy assumptions.	RRC Connection Request, RRC Connection Reject	LTE Uu	Check admission rules before treating it as unexplained radio instability.

What to check in logs and traces

Confirm the request really started from RRC_IDLE and was aimed at fresh connection establishment.
Inspect the establishment cause before assuming the same root cause for every reject.
Check the reject wait time and compare it with actual retry behavior.
Correlate repeated attempts with the same cell and the same paging or uplink trigger context.
Do not jump into NAS or EPC analysis unless a later successful RRC setup exists.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

Notes

RRC Connection Reject is an access outcome, not a NAS reject. It means the UE never received a fresh connected signaling path in the first place.

The most useful correlation pair is often RRC Connection Request and RRC Connection Reject together with retry timing. That is usually enough to keep the analysis on the radio side.

FAQ

What is LTE RRC Connection Reject?

It is the eNB response that refuses a fresh RRC connection establishment attempt.

Does RRC Connection Reject mean attach failed?

It means attach or another later procedure could not begin through a normal connected radio path.

What should I inspect first?

Start with establishment cause, reject wait time, retry pattern, and cell context.

Does the UE enter RRC_CONNECTED after reject?

No. The UE remains outside a successful connected signaling state.

Why is wait time important?

It tells you when the UE is expected to retry and helps explain retry loops.