RCEF

RRC Connection Establishment Failure

Management →
Introduced in Rel-11

RCEF is a key performance indicator measuring the failure rate of attempts by a user device to establish a Radio Resource Control connection with the network.

Category
Management
Introduced
Rel-11
Where
Management
Specifications
7 specs
RCEF Description Purpose Related Classification Detected Changes Specifications

Description

RRC Connection Establishment Failure (RCEF) is a critical performance measurement defined in 3GPP specifications for network management and optimization. It quantifies the proportion of failed attempts by a User Equipment (UE) to transition from RRC_IDLE or RRC_INACTIVE state to RRC_CONNECTED state. The establishment procedure is initiated by the UE sending an RRCConnectionRequest message, typically triggered by events like initial access, mobile-originated data, or responding to a paging message. The network responds with an RRCConnectionSetup message if resources are available and conditions permit. A failure is counted when this process does not complete successfully, and the UE does not enter the connected state.

The failure can occur due to various reasons categorized in the specifications. Common causes include radio link failures during the procedure, such as poor signal quality (e.g., low RSRP/RSRQ), high interference, or sudden signal degradation. Failures can also stem from network rejection, where the eNB/gNB sends an RRCConnectionReject message, often due to congestion, lack of radio resources, or admission control policies. Other causes include timer expiries (like T300) before setup completion, contention resolution failures on random access channels, or internal UE issues. The specific failure causes are often logged for detailed root cause analysis.

From an architectural perspective, RCEF is measured at the Radio Access Network (RAN) node—the eNB in LTE or gNB in 5G NR. The management system collects these measurements via defined interfaces and performance management counters specified in documents like 32.421 and 32.422. Operators use RCEF KPIs to assess network accessibility, a fundamental aspect of quality of service. High RCEF rates directly impact user experience, as devices cannot register or initiate sessions. Therefore, continuous monitoring and minimization of RCEF are central to radio network planning, optimization, and troubleshooting workflows, ensuring reliable initial access for subscribers.

Purpose & Motivation

The purpose of defining RCEF as a standardized KPI is to provide operators with a consistent, quantifiable metric to evaluate and ensure network accessibility. Before such standardized measurements, operators relied on disparate, vendor-specific indicators, making cross-vendor network benchmarking and holistic optimization challenging. RCEF addresses the need for an objective measure of how successfully users can attach to the network, which is the foundational step for any mobile service.

Its creation was motivated by the increasing complexity of mobile networks and the critical importance of user-perceived service availability. As networks evolved through 3GPP releases, supporting more devices and diverse services, the initial access procedure became a potential bottleneck. High failure rates could indicate underlying problems like coverage holes, excessive interference, cell overload, or misconfigured parameters. By standardizing RCEF, 3GPP enabled automated performance management systems to detect, locate, and help diagnose these issues efficiently.

RCEF solves the problem of opaque initial access failures. It transforms a critical network event into a measurable and actionable KPI. This allows operators to set performance thresholds, trigger alarms, and drive optimization campaigns—such as antenna tilting, power adjustments, or parameter tuning—to improve accessibility. Ultimately, it contributes to meeting service level agreements, reducing customer complaints, and ensuring a reliable first point of contact between the user and the network.

Classification

Part ofKPI

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (2 CRs across 2 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-15 1 change

In Release 15, the RCEF (RRC Connection Establishment Failure) reporting function was formally introduced as a new, distinct type of trace metric and reportable data kind within the management system. It was integrated into the TraceJob framework, where the `jobType` attribute can now be specifically set to `RCEF_REPORT`, and it is configured using the same `mdtConfig` parameters as other MDT and failure reporting jobs. This addition aligned the requirements for RCEF reports with the broader specifications for trace data collection as defined in TS 32.422.

  • Add the missing requirements on RCEF reports to align with TS 32.422 TS 32.421CR0077
Rel-17 1 change

In Release 17, the key enhancement for the RCEF (RRC Connection Establishment Failure) function was an explicit broadening of its scope, as indicated by the Change Request title. The grounding context confirms that RCEF reports were formally integrated as a distinct and configurable trace metric type, placing them alongside other established reports like RLF and RRC within the management data and jobType enumeration for trace collection.

  • Enhancement of scope regarding RCEF TS 32.421CR0106

Explore further

Broader topics and technologies where RCEF plays a role.

Defining Specifications

3GPP specifications that define or reference RCEF, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 28.622 vk20 Telecommunication Management; Generic NRM Information Service Rel-20
TS 28.627 vj00 SON Policy NRM IRP: Requirements Rel-19
TR 28.837 vi00 Technical Report on Trace/MDT Management Rel-18
TS 32.421 vj30 Subscriber & Equipment Trace Concepts & Requirements Rel-19
TS 32.422 vk00 Telecom Management: Trace Control & Configuration Rel-20
TS 32.442 vj00 Trace Management IRP: Information Service Rel-19
TS 32.836 vc00 NM Centralized Coverage and Capacity Optimization Study Rel-12
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.