Non-Aggregated RUCI Report Request

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.

Key Features

• Triggers the generation of a detailed, non-aggregated report on resource utilization and congestion
• Requested by management systems (EM/NM) from RAN nodes (eNB/gNB) via the Itf-N interface
• Provides granular data, potentially per-UE or per-resource unit, unlike aggregated PM data
• Supports on-demand and potentially event-triggered reporting for targeted investigation
• Essential for advanced network analytics, root cause analysis, and SLA monitoring for network slicing
• Integrates into the 3GPP-defined Performance Management (PM) and Self-Organizing Network (SON) frameworks

Evolution Across Releases

Defining Specifications