O-RAN Policy Control for Cross-RIC xApp Conflict Mitigation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing O-RAN networks face challenges in detecting and mitigating indirect and implicit conflicts among operations of near-RT RICs, which can lead to network instability and security vulnerabilities, particularly when conflicts occur across different or neighboring near-RT RICs.

Innovation Solution

A non-RT RIC generates policies based on activity logs and operational intents to manage conflicts by allowing or restricting parameter updates in near-RT RICs, using machine learning to detect and mitigate direct, indirect, and implicit conflicts, both intra- and inter-domain.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If multiple xApps are allowed to operate autonomously in near-RT RICs, then network flexibility and functionality are improved, but conflicts between xApps lead to network instability and security vulnerabilities

Engineering Contradiction:
Improvenetwork flexibilityVSAvoidnetwork stability
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

A policy management system is introduced as an intermediary between xApps and near-RT RICs. This system generates and enforces policies that govern parameter updates, preventing conflicts while maintaining xApp autonomy. The policy acts as a mediator that allows multiple xApps to operate simultaneously without causing network instability.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

Policies are generated in advance by the non-RT RIC based on activity logs and operational intents, before conflicts occur in near-RT RICs. This preliminary policy generation prevents conflicts by establishing rules ahead of time, allowing xApps to operate flexibly within defined boundaries without causing network instability.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If centralized policy control is implemented to prevent conflicts, then network stability is improved, but system complexity and response time increase

Engineering Contradiction:
Improvenetwork stabilityVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The control system is segmented into two layers: non-RT RIC for policy generation and near-RT RICs for policy execution. This segmentation distributes complexity across multiple components, with each handling specific functions. The non-RT RIC focuses on policy creation using machine learning, while near-RT RICs focus on real-time policy enforcement, reducing overall system complexity despite centralized control.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The policy management system uses machine learning to automatically generate policies from activity logs, eliminating the need for manual policy creation. This self-service approach reduces operational complexity and allows the system to adapt automatically to changing network conditions without increasing human management overhead.

Inventive Principle:
Principle #25Self-service

3Difficulty of detecting and measuring

If machine learning is used to generate policies, then automated conflict detection capability is improved, but computational resource consumption increases

Engineering Contradiction:
Improveconflict detection capabilityVSAvoidcomputational resource consumption
Core Design Contradiction:
Difficulty of detecting and measuringVSUse of energy by moving object

Solution Approach 1:

The machine learning model processes activity logs selectively, focusing on relevant patterns that indicate potential conflicts rather than analyzing all possible data. This partial processing approach maintains high conflict detection capability while reducing computational resource consumption by avoiding unnecessary analysis of irrelevant data.

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

The system uses activity logs as simplified copies of actual network operations to train and generate policies. Instead of processing real-time network data for policy generation, the system works with logged historical data, which requires significantly less computational resources while maintaining effective conflict detection capability.

Inventive Principle:
Principle #26Copying

4Object-affected harmful factors

If policies restrict parameter updates to prevent conflicts, then network security is improved, but network adaptability and optimization capability deteriorate

Engineering Contradiction:
Improvenetwork securityVSAvoidnetwork adaptability
Core Design Contradiction:
Object-affected harmful factorsVSAdaptability or versatility

Solution Approach 1:

Policies are dynamically generated and updated based on machine learning analysis of activity logs and changing operational intents. Rather than using static restrictions, the system adapts policies in real-time to allow necessary parameter updates while preventing conflicts. This dynamic approach maintains network security without sacrificing adaptability.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The policy management system monitors and adjusts policy parameters based on network conditions and detected conflict patterns. By changing policy parameters dynamically, the system can tighten restrictions when conflicts are detected and relax them when safe, maintaining both network security and adaptability through parameter optimization.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS12556972B2Automated detection and mitigation of intra- and interdomain conflicts in open radio access networks
Publication Date: 2026.02.17 INTERNATIONAL BUSINESS MACHINE CORPORATION
  • US12556972B2 patent drawing
  • US12556972B2 patent drawing
  • US12556972B2 patent drawing

AI summary

A computer-implemented method for addressing conflicts in a radio access network (RAN) includes generating, by a non-Real-Time RAN Intelligent Controller (non-RT RIC), a policy for a near-Real-Time RAN Intelligent Controller (near-RT RIC) by analyzing an activity log of several xApps, which are being executed by the near-RT RIC. The method further includes sending, by the non-RT RIC the policy to the near-RT RIC to cause the near-RT RIC, in response to receiving a request from an xApp from the several xApps to update a parameter of the RAN. The policy specifies an update the parameter based on the policy allowing the xApp to update the parameter. The policy further specifies maintaining the parameter unchanged based on the policy restricting the xApp to update the parameter.