NRR

Non-Aggregated RUCI Report Request

Management →
Introduced in Rel-13

NRR is a request for a detailed, per-UE report on Resource Utilization and Congestion Information from the RAN to support traffic management and optimization.

Category
Management
Introduced
Rel-13
Where
Core Network › Evolved Packet Core
Specifications
2 specs
NRR Description Purpose Detected Changes Specifications

Description

The Non-Aggregated RUCI Report Request (NRR) is a management procedure and message type defined within the 3GPP specifications for the E-UTRAN and NG-RAN. It is initiated by a network management entity, typically an Element Manager (EM) or Network Manager (NM), towards a RAN node, such as an eNB or gNB, via the Itf-N interface. The request commands the RAN node to generate and send a report containing detailed, non-aggregated Resource Utilization and Congestion Information. Unlike aggregated reports, which provide summarized data, a non-aggregated report contains fine-grained information, often on a per-User Equipment (UE) basis or per-specific resource granularity, allowing for deep diagnostics and targeted optimization.

The report generation process is triggered upon receiving the NRR command. The RAN node collects the requested RUCI data from its internal measurements and counters. This data can include metrics such as Physical Resource Block (PRB) usage, scheduler queue lengths, number of active UEs, handover success rates, and congestion indicators for specific cells, slices, or QoS flows. The key aspect of the 'Non-Aggregated' qualifier is that the data is not summarized across a large set of UEs or a long time window; instead, it can provide snapshots or time-series for individual entities. The collected data is then formatted into a report message (a Non-Aggregated RUCI Report) and transmitted back to the requesting management system.

The role of the NRR is critical for performance management, fault management, and self-organizing network (SON) functions. By obtaining non-aggregated data, network operators and management systems can perform root cause analysis of congestion events, understand the resource consumption patterns of specific high-demand users or services, and validate the effectiveness of network configuration changes. It provides the visibility needed for advanced traffic steering, capacity planning, and QoS enforcement, especially in complex scenarios involving network slicing and diverse service requirements. The procedure is part of the broader Performance Assurance (PA) and Configuration Management (CM) frameworks defined by 3GPP for automated network operation and maintenance.

Purpose & Motivation

The NRR was introduced to address the need for granular, on-demand visibility into radio access network performance and resource status, which aggregated performance measurements could not provide. Prior to its standardization, network management systems often relied on predefined, aggregated counters (PM counters) that offered a high-level view but lacked the detail necessary to diagnose specific issues like a single UE causing congestion or a particular network slice experiencing resource starvation. The creation of the NRR procedure was motivated by the increasing complexity of mobile networks, the introduction of network slicing in 5G, and the demand for more sophisticated SON and analytics capabilities.

It solves the problem of opaque RAN performance during specific events or for specific entities. By allowing a management system to request a detailed report for a particular cell, set of UEs, or during a specific time interval, operators can proactively manage network health and service quality. This is particularly important for ensuring Service Level Agreement (SLA) compliance for network slices and for troubleshooting customer-experienced problems. The NRR provides a flexible, query-based mechanism to extract the precise data needed for analysis, moving beyond the limitations of fixed, periodic reporting and enabling a more dynamic and efficient approach to RAN performance management.

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.

Studied in Rel-13, normative work from Rel-15.

Rel-15 1 change

In Release 15, the NRR (Non-Aggregated RUCI Report Request) function was newly introduced to enable congestion reporting over the Np reference point. This addition specifically allows for the monitoring and reporting of congestion events within the policy and charging control architecture. The function operates within the established procedures for session management and interaction between network functions like the PCRF.

  • Clarification of Max-Requested-Bandwidth TS 29.213CR0721
Rel-17 1 change

In Release 17, the NRR (Non-Aggregated RUCI Report Request) function was introduced to enable congestion reporting over the Np reference point, as defined in the PCC architecture. This addition specifically allows for the reporting of congestion information related to a user and PDN, which is managed within the PCRF and impacts procedures such as UE context removal for roaming users with visited access.

  • Correction to enable retrieval of Network Provided Location information in a MESSAGE request TS 29.213CR0747

Explore further

Broader topics and technologies where NRR plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 29.213 vj20 PCC Signalling Flows and QoS Mapping Rel-19
TS 29.217 vj00 Policy and Charging Control (PCC) for Np Interface Rel-19