RIC in O-RAN: Architecture and Power Savings

• RIC is a core element of O-RAN that aggregates KPI data from distributed E2 nodes, enabling modular and programmable network control via xApps.
• Empirical analysis shows that increasing E2 nodes and KPI granularity causes linear rises in power consumption, highlighting redundant KPI traffic as an energy bottleneck.
• Optimization techniques like eliminating duplicate transmissions and granular KPI aggregation can yield up to 87% power savings in large-scale deployments.

The Radio Access Network Intelligent Controller (RIC) is a foundational element of Open Radio Access Network (O-RAN) architectures, conceived to centralize network intelligence and enable modular, programmable control via standardized interfaces and applications (xApps/rApps). A critical aspect impacting the scalability and sustainability of O-RAN is the power consumption of the RIC, particularly as it relates to the monitoring and processing of Key Performance Indicators (KPIs) at scale. The paper (Lima et al., 16 Jan 2025) provides the first quantitative evaluation of how KPI monitoring dynamics drive RIC power profiles, identifies scalability bottlenecks, and introduces novel optimization strategies for significant power savings.

1. Architecture and KPI Monitoring Workflow in RIC

The RIC aggregates metrics from distributed E2 nodes over the E2 interface, primarily for consumption by modular control applications (xApps). KPI reporting follows periodic subscriptions (typically every 10 ms), where each E2 node transmits operational statistics up to the RIC server. These statistics underpin closed-loop control and analytics functions. As the deployment scales—i.e., more E2 nodes and more granular KPIs per node—the aggregate traffic and internal computation required by the RIC increases linearly, driving up both data movement and processing energy.

RIC hosts are typically multi-core servers with substantial baseline/idle (static) power overhead (~34.5 W, see Table below), to which dynamic consumption (processing incremental KPI messages) is added as network scale increases.

2. Experimental Quantification: Methodology & Findings

A dual-server hardware testbed forms the foundation for the analysis:

• RIC Server: Intel Xeon E5-2640, hosting the RIC and xApp instances.
• RAN Server: Intel Xeon Gold 6154, synthesizing E2 node traffic, connected at 10 Gbps Ethernet.

KPI traffic is generated using the OAI FlexRIC KPI Monitoring xApp, conforming to O-RAN standards. System metrics—traffic (SAR tool, 1 s interval) and power (Turbostat, RAPL counters, 1 s interval)—are collected under workloads where both the number of E2 nodes (up to 26, projected 60) and number of KPIs per node (7 to 80, projected higher) are systematically varied.

Key results:

• Scaling E2 nodes: RIC power consumption increases linearly; at 60 nodes, power is ~55 W (+60% over static).
• Scaling KPIs per node: Beyond 80 KPIs per node, power exceeds 50 W for 4 E2 nodes; traffic ~35 MBps.
• Static RIC (platform idle) is 34.5 W; dynamic increments are due directly to KPI message load.

3. RIC Scalability Bottlenecks and Power Implications

• Both the frequency and diversity of KPI updates—from many nodes and for many metrics—result in a proportional rise in total inbound traffic and in per-cycle CPU utilization.
• Large-scale deployments (hundreds of nodes; tens to hundreds of KPIs per node) threaten the energy efficiency and operational sustainability of RIC-centric O-RAN architectures, irrespective of application-specific (i.e., advanced xApp or ML) overhead: the core operational RIC workload alone can oversaturate available power budgets.
• The RIC can become the system bottleneck not due to control or AI complexity, but due to naive KPI aggregation and duplicate transmission—a critical design consideration for CSPs targeting greenfield or scale-out deployments.

4. Optimization Techniques for KPI Transmission

The default O-RAN implementation merges only fully identical subscription requests, neglecting cases where subsets of KPIs requested by different xApps overlap or where apps require different reporting periods for the same KPI. This results in redundant KPI transmission, unnecessary computational load, and wasted power. The paper formalizes several practical enhancements:

1. Elimination of Redundant KPI Transmissions: Each KPI is analyzed across subscriptions. If requested by multiple xApps at the same reporting interval, it is shared. If intervals differ, the system samples at the highest required rate, enforcing a temporal sensitivity constraint:
   • Temporal sensitivity: $$\Delta t_{max} = \min(T_i, T_j) - \mathrm{GCD}(T_i, T_j)$$
   • Merge if $\Delta t_{max} < \Delta t_m$ (where $\Delta t_m$ is the xApp’s tolerance to outdated data).
   • Sample count logic:

   $$S_{\mathrm{gcd}} = \frac{\mathrm{LCM}(T_i, T_j)}{\mathrm{GCD}(T_i, T_j)}$$

   $$S_{T_{i/j}} = \frac{\mathrm{LCM}(T_i, T_j)}{T_{i/j}}$$

• Merge subscriptions whenever $S_{\mathrm{gcd}} < S_{T_i} + S_{T_j}$.

1. Identical Subscription Removal: Subscriptions requesting identical KPI sets at the same period are consolidated, minimizing database and wireload.
2. Granular KPI Selection: For non-identical sets/periods, KPIs are aggregated if all xApp temporal sensitivity constraints are met.
3. Dimensionality Reduction (e.g., PCA): Reduces KPI space to only those metrics directly required by xApps, lowering the traffic and computational base.

These mechanisms can be implemented as a dedicated microservice within the RIC or as an extension to the existing Subscription Manager.

5. Quantitative Impact of Optimizations

The paper models three deployment scales (see Table below):

Deployment	Gross Power	Max Savings	% Savings	Notes
Small	44 W	8.4 W	~20%	Dominated by static power
Medium	268 W	210 W	~80%	10% duplication: 23 W (8.7%)
Large	1.4 kW	1.2 kW	~87%	Massive scaling benefit

• In large-scale scenarios with hundreds of E2 nodes and hundreds of KPIs per node, eliminating duplicate and partial redundant transmissions offers up to 87% gross RIC power savings (>1.2 kW absolute), equating to the operational budget of dozens of pico RAN sites.
• Even modest improvements—removal of 10% redundancy—yield tens to hundreds of watts savings.
• This suggests that KPI subscription and reporting optimization is not merely an engineering refinement but a prerequisite for practical, scalable O-RAN deployments capable of meeting energy targets.

6. Practical Implementation and Extension beyond Standards

• The described optimizations extend current practice (and standards) but require only minimal protocol updates—chiefly to message formats and Subscription Manager behavior.
• Microservice-based integration allows modular enhancement without disrupting existing application logic or xApp onboarding processes.
• These techniques are foundational for future Open RAN energy models and broader optimization frameworks, including those targeting dynamic dimensionality reduction or further temporal aggregation.

7. Implications for Real-World RIC Design and Future Directions

• Unoptimized, unmanaged KPI monitoring can dominate RIC resource profiles in scale-out Open RAN networks, independently of application layer complexity. The RIC becomes a scalability and sustainability bottleneck, threatening the feasibility of Open RAN as an energy-efficient platform.
• Substantial power savings—up to 87%—are possible through intelligent KPI aggregation and reporting period alignment, with additional gains expected from further dimensionality reduction and advanced xApp design.
• Real-world adoption will require CSPs to prioritize KPI reporting management in both protocol engineering and RIC microservice deployments, balancing fidelity of network observation with the aggregate operational cost.
• Future work should address dynamic, context-aware subscription management (potentially leveraging ML-based prediction of xApp requirements), continuously adaptive dimensionality reduction, and seamless integration across multi-vendor environments.

---

Summary Table: Deployment Scale vs. Power Savings

Deployment Scale	Gross Power	Max Achievable Savings	%
Small (10 nodes, 20 KPIs)	44 W	8.4 W	20
Medium (100 nodes, 50 KPIs)	268 W	210 W	80
Large (300 nodes, 100 KPIs)	1.4 kW	1.2 kW	87

---

The RAN Intelligent Controller’s ability to scale effectively for power and performance in Open RAN is contingent upon practical, protocol-level optimizations in KPI monitoring and reporting. The results substantiate that energy-efficient, high-density deployment of RIC-based architectures is approachable when redundant KPI traffic and period mismatches are systematically eliminated via straightforward, standards-compatible methods.