Downlink NR RRC message used by the network to reject an RRC connection establishment attempt or an RRC connection resumption attempt.
Tells the UE that the current setup or resume attempt is not being accepted and may impose a wait time before the UE tries again.
Why this message matters
RRCReject means the network is not accepting the current RRC setup or resume attempt. The most important thing to read is the waitTime, because it tells the UE how long to wait before trying again.
Where this message appears in the call flow
5G RRC Connection Setup
Call flow position: Negative network response after RRCSetupRequest during connection establishment.
Typical state: UE is trying to move from RRC_IDLE toward connected signaling.
Preconditions:
UE sent RRCSetupRequest.
The network chose not to admit the connection attempt.
Next likely message: A fresh access retry after wait time or after barring conditions change
5G RRC Resume
Call flow position: Negative response after RRCResumeRequest or RRCResumeRequest1 during resume or RNA update handling.
Typical state: UE is in RRC_INACTIVE and is trying to resume or perform an RNA update.
Preconditions:
UE attempted to resume a suspended RRC connection.
The network chose not to resume the current context.
Next likely message: Paging monitoring continues while T302 runs, or the UE retries later
Next message(s): New access attempt after wait time expiry, RRC_IDLE stay or continued paging monitoring depending on scenario
Message direction and transport
Sender and receiver: gNB -> UE
Interface: Uu
Domain: Access-side radio control
Signaling bearer: SRB0
Logical channel: DL-CCCH
Transport / encapsulation: RRC over CCCH on RLC TM before connected-mode dedicated control is active
Security context: Delivered on SRB0. It is not an AS-security-protected connected-mode DCCH message.
Message Structure Overview
RRCReject is intentionally small. In practice, almost all troubleshooting starts with waitTime and the context of the rejected procedure.
Unlike NAS reject messages, NR RRCReject does not carry a standardized reject cause field that explicitly tells you why the network rejected the attempt.
Engineers must infer the reason from the attempt type, access category, barring state, resume context, and surrounding radio/core events.
The practical point is simple: the message is structurally minimal, and waitTime is the field engineers care about most. The spec indicates that waitTime is the timer value in seconds for T302.
waitTime: 8 means the UE should run T302 for 8 seconds before retrying the barred attempt path.
If this reject follows RRCSetupRequest, think setup rejection. If it follows RRCResumeRequest, think resume rejection.
There is no explicit reject cause IE in the message body, so do not expect a NAS-style cause value here.
Important Information Elements
IE
Required
Description
waitTime
Yes
Reject wait time value in seconds. It is the key operational field and drives timer T302 at the UE.
lateNonCriticalExtension
Optional
Release-evolution extension container for later backward or forward compatibility handling.
nonCriticalExtension
Optional
Non-critical extension branch used for future additions without changing the base reject message semantics.
Detailed field explanation
waitTime
Reject wait time value in seconds. It is the key operational field and drives timer T302 at the UE.
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.
lateNonCriticalExtension
Release-evolution extension container for later backward or forward compatibility handling.
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.
nonCriticalExtension
Non-critical extension branch used for future additions without changing the base reject message semantics.
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 which message triggered the reject: RRCSetupRequest, RRCResumeRequest, or RRCResumeRequest1.
Read the waitTime value and correlate it with T302 behavior at the UE.
Check whether T300, T319, and T302 behave as expected around the reject.
Inspect the preceding establishmentCause or resumeCause because it often helps explain the rejection context.
Correlate with access barring, overload, paging/resume, or RNA update context.
Check whether the UE remains in or returns to the expected state after rejection.
Common Issues and Troubleshooting
UE receives RRCReject immediately after RRCSetupRequest.
Likely cause: The access attempt may be barred, deprioritized, or temporarily not admitted by the cell or gNB.
What to inspect: Check access category, establishmentCause, barring state from SIB1, cell load, and waitTime.
Next step: Validate whether the UE should retry after T302 or whether barring / admission conditions need to change.
UE receives RRCReject during resume from RRC_INACTIVE.
Likely cause: The network may not accept the resume attempt, the inactive context may no longer be usable, or RNA update handling may be rejected.
What to inspect: Check whether the triggering message was RRCResumeRequest or RRCResumeRequest1, and inspect T319/T302 handling.
Next step: Walk the resume procedure and verify whether fallback or later retry is expected.
Engineers cannot find a reject cause value in the message.
Likely cause: This is expected. RRCReject does not contain an explicit reject cause IE.
What to inspect: Use the surrounding procedure, waitTime, barring information, and preceding request context.
Next step: Shift troubleshooting from 'cause decode' to 'context inference'.
UE retries too early or behaves unexpectedly after reject.
Likely cause: T302 handling or UE state transition may be wrong.
What to inspect: Check waitTime, T302 start/stop behavior, and whether the reject followed setup or resume.
Next step: Validate timer handling against TS 38.331 procedure behavior.
LTE / 5G / Variant Comparison
Compared with LTE RRCConnectionReject
LTE also uses an RRC-level reject concept during connection establishment, but this page covers the NR message defined in TS 38.331. In NR, engineers should pay special attention to the dual use of RRCReject for both setup and resume rejection.
FAQ
What does RRCReject mean in 5G NR?
It means the network rejected the current RRC setup or RRC resume attempt.
Who sends RRCReject?
The gNB sends RRCReject to the UE.
What is the most important field in RRCReject?
waitTime is the most important field because it drives T302 and tells the UE how long to wait before retrying.
Does 5G NR RRCReject include reject causes?
No. RRCReject does not include a standardized explicit reject-cause IE.
What are the common reasons for RRCReject?
Typical reasons include access barring, temporary admission rejection, overload, or a resume attempt that the network does not accept.
What happens after RRCReject?
The UE stops the current setup or resume supervision timers, handles T302 if waitTime is present, and retries later if appropriate.
Is RRCReject used only for connection establishment?
No. In NR it can also reject RRC connection resumption.
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.