Near-Real-Time RIC (Near-RT RIC)

The defining characteristic of the Near-RT RIC is its control loop execution window of 10 milliseconds to 1 second. This latency envelope enables it to handle procedures that are too fast for the Non-RT RIC's policy-based guidance but do not require the sub-millisecond timing of the DU's physical layer scheduler.

• Per-TTI optimization: Can influence scheduling decisions on a per-Transmission Time Interval basis
• UE-specific control: Manages per-User Equipment radio resource allocation in real-time
• Fast feedback: Processes UE and cell-level measurements within hundreds of milliseconds to adjust beamforming and load balancing

xApps are the microservice-based applications that execute on the Near-RT RIC platform. Each xApp runs in an isolated container and performs a specific optimization function:

• Independent lifecycle: xApps can be deployed, upgraded, and terminated without affecting others
• Shared data access: All xApps consume a common data lake via the Shared Data Layer (SDL)
• Conflict mitigation: A dedicated conflict resolution manager arbitrates when multiple xApps issue contradictory control actions
• Polyglot development: xApps can be written in any language and communicate via RESTful APIs or message buses

The A1 interface connects the Near-RT RIC to the Non-RT RIC within the SMO framework. It is used exclusively for policy-based guidance rather than real-time control:

• Policy declaration: The Non-RT RIC declares declarative policies (e.g., 'maximize energy efficiency while maintaining QoE > 4.0')
• Enrichment information: Provides ML model updates, UE mobility predictions, and traffic forecasts
• Feedback loop: The Near-RT RIC reports policy effectiveness metrics back to the Non-RT RIC for continuous refinement

This separation ensures the Non-RT RIC's >1-second loop does not interfere with the Near-RT RIC's sub-second execution.

The Near-RT RIC is deployed at the far edge of the network, co-located with or in close proximity to the CU to minimize transport latency:

• Regional scope: Typically manages a cluster of cells within a single geographic area
• Edge compute requirements: Requires low-latency compute infrastructure, often on Kubernetes clusters at telco edge sites
• Resilience: Operates independently of the centralized SMO; continues functioning even if the A1 connection to the Non-RT RIC is temporarily lost
• Scalability: Multiple Near-RT RIC instances can be deployed across a network, each managing its own domain

A critical architectural component of the Near-RT RIC is the conflict mitigation function. Since multiple xApps may simultaneously request conflicting actions on the same RAN resources, the platform must arbitrate:

• Priority-based resolution: Each xApp is assigned a priority level; higher-priority requests override lower ones
• Resource locking: Prevents race conditions when xApps target the same UE or cell
• Composite actions: Where possible, the RIC merges non-conflicting requests into a single control message
• Audit trail: All arbitration decisions are logged for post-hoc analysis and xApp performance evaluation

A core challenge in the Near-RT RIC is managing conflicts between multiple concurrently running xApps. Since different xApps may attempt to control the same parameters (e.g., handover offset) for different goals (e.g., load balancing vs. energy saving), a conflict mitigation function is essential. This module coordinates and arbitrates between xApp requests using a coordination policy defined by the operator. Techniques include priority-based resolution, joint optimization, and safe-action set computation to ensure that the combined control actions do not destabilize the network.