Summary

The Non-RealTime RIC (RAN Intelligent Controller) is an Orchestration and Automation function described by the O-RAN Alliance for non-real-time intelligent management of RAN (Radio Access Network) functions.

The primary goal of the Non-RealTime RIC is to support non-real-time radio resource management, higher layer procedure optimization, policy optimization in RAN, and providing guidance, parameters, policies and AI/ML models to support the operation of near-RealTime RIC functions in the RAN to achieve higher-level non-real-time objectives.

Non-RealTime RIC functions include service and policy management and RAN analytics for the RAN. The Non-RealTime RIC platform hosts and coordinates rApps (Non-RT RIC applications) to perform Non-RealTime RIC tasks. The Non-RealTime RIC also hosts the new R1 interface (between rApps and SMO/Non-RealTime-RIC services).

The O-RAN-SC (OSC) NONRTRIC project provides concepts, architecture and reference implementations as defined and described by the O-RAN Alliance architecture. The OSC NONRTRIC implementation communicates with near-RealTime RIC elements in the RAN via the A1 interface. Using the A1 interface the NONRTRIC will facilitate the provision of policies for individual UEs or groups of UEs; monitor and provide basic feedback on policy state from near-RealTime RICs; provide enrichment information as required by near-RealTime RICs; and facilitate ML model training, distribution and inference in cooperation with the near-RealTime RICs. The OSC NONRTRIC hosts rApps, and coordinates all interactions between the rApp and underlying SMo by way of the R1 Interface.

Image: O-RAN SC - NONRTRIC Overall Architecture

Find detailed description of the NONRTRIC project see the O-RAN SC NONRTRIC Project Wiki.

NONRTRIC components

These are the components that make up the Non-RT-RIC:

Non-RT-RIC Control Panel / NONRTRIC Dashboard

Graphical user interface.

  • View and Manage A1 policies in the RAN (near-RT-RICs)

  • Graphical A1 policy creation/editing is model-driven, based on policy type’s JSON schema

  • View and manage producers and jobs for the Information coordinator service

  • Configure A1 Policy Management Service (e.g. add/remove near-rt-rics)

  • Interacts with the A1-Policy Management Service & Information Coordination Service (REST NBIs) via Service Exposure gateway

Implementation:

Information Coordination Service

The ICS is a data subscription service which decouples data producers from data consumers. A data consumer can create a data subscription (Information Job) without any knowledge of its data producers (one subscription may involve several data producers). A data producer has the ability to produce one or several types of data (Information Type). One type of data can be produced by zero to many producers.

A data consumer can have several active data subscriptions (Information Job). One Information Job consists of the type of data to produce and additional parameters, which may be different for different data types. These parameters are not defined or limited by this service.

Maintains a registry of:

  • Information Types / schemas

  • Information Producers

  • Information Consumers

  • Information Jobs

The service is not involved in data delivery and hence does not put restrictions on this.

Implementation:

A1 Policy Management Service (from ONAP CCSDK)

A1 Controller Service above A1 Controller/Adapter that provides:

  • Unified REST & DMaaP NBI APIs for managing A1 Policies in all near-RT-RICs.

    • Query A1 Policy Types in near-RT-RICs.

    • Create/Query/Update/Delete A1 Policy Instances in near-RT-RICs.

    • Query Status for A1 Policy Instances.

Maintains (persistent) cache of RAN’s A1 Policy information.

  • Support RAN-wide view of A1 Policy information.

  • Streamline A1 traffic.

  • Enable (optional) re-synchronization after inconsistencies / near-RT-RIC restarts.

  • Supports a large number of near-RT-RICs (& multi-version support).

  • Converged ONAP & O-RAN-SC A1 Adapter/Controller functions in ONAP SDNC/CCSDK (Optionally deploy without A1 Adapter to connect direct to near-RT-RICs).

  • Support for different Southbound connectors per near-RT-RIC - e.g. different A1 versions, different near-RT-RIC version, different A1 adapter/controllers supports different or proprietary A1 controllers/EMSs.

Implementation:

A1/SDNC Controller & A1 Adapter (Controller plugin)

Mediation point for A1 interface termination in SMO/NONRTRIC.

  • Implemented as CCSDK OSGI Feature/Bundles.

  • A1 REST southbound.

  • RESTCONF Northbound.

  • NETCONF YANG > RESTCONF adapter.

  • SLI Mapping logic supported.

  • Can be included in an any controller based on ONAP CCSDK.

Implementation:

A1 Interface / Near-RT-RIC Simulator

Stateful A1 test stub.

  • Used to create multiple stateful A1 providers (simulated near-rt-rics).

  • Supports A1-Policy and A1-Enrichment Information.

  • Swagger-based northbound interface, so easy to change the A1 profile exposed (e.g. A1 version, A1 Policy Types, A1-E1 consumers, etc).

  • All A1-AP versions supported.

Implementation:

(Spring Cloud) Service Gateway

Support Apps to use A1 Services.

  • Spring Cloud Gateway provides the library to build a basic API gateway.

  • Exposes A1 Policy Management Service & Information Coordinator Service.

  • Additional predicates can be added in code or preferably in the Gateway yaml configuration.

Implementation:

  • Implemented as a Java Spring Cloud application.

  • Repo: portal/nonrtric-controlpanel.

Service Exposure Security Architecture Prototyping

Support Apps to use NONRTRIC, SMO and other App interfaces. A building block for coming releases as the R1 Interface concept matures .

DMaaP Information Producer Adapters (Kafka)

Configurable mediators to take information from DMaaP and Kafka and present it as a coordinated Information Producer.

These mediators/adapters are generic information producers, which register themselves as information producers of defined information types in Information Coordination Service (ICS). The information types are defined in a configuration file. Information jobs defined using ICS then allow information consumers to retrieve data from DMaaP MR or Kafka topics (accessing the ICS API).

There are two alternative implementations to allow Information Consumers to consume DMaaP or Kafka events as coordinated Information Jobs.

Implementation:

Initial App Catalogue

Register for Non-RT-RIC Apps.

  • Non-RT-RIC Apps can be registered / queried.

  • Limited functionality/integration for now.

  • More work required in coming releases as the rApp concept matures.

Implementation:

Initial Kubernetes Helm Chart LCM Manager

Onboard, start, stop, and modify Non-RT-RIC App µServices as Helm Charts. A building block for coming releases as the R-APP concept matures.

  • Interfaces that accepts Non-RT-RIC App µServices Helm Charts.

  • Support basic LCM operations.

  • Onboard, Start, Stop, Modify, Monitor.

  • Initial version co-developed with v. similar functions in ONAP.

  • Limited functionality/integration for now.

Implementation:

Service Management and Exposure (CAPIF)

An initial implementation of the CAPIF Core service. It implements the following CAPIF APIs:

  • API Provider Management

  • Publish Service

  • Discover Service

  • API Invoker Management

  • Security

  • Events

Implementation:

Authentication Support (Keycloak)

The auth-token-fetch provides support for authentication. It is intended to be used as a sidecar and does the authentication procedure, gets and saves the access token in the local file system. This includes refresh of the token before it expires. This means that the service only needs to read the token from a file.

It is tested using Keycloak as authentication provider.

_images/AuthSupport.png

So, a service just needs to read the token file and for instance insert it in the authorization header when using HTTP. The file needs to be re-read if it has been updated.

The auth-token-fetch is configured by the following environment variables.

  • CERT_PATH - the file path of the cert to use for TSL, example: security/tls.crt

  • CERT_KEY_PATH - the file path of the private key file for the cert, example: “security/tls.key”

  • ROOT_CA_CERTS_PATH - the file path of the trust store.

  • CREDS_GRANT_TYPE - the grant_type used for authentication, example: client_credentials

  • CREDS_CLIENT_SECRET - the secret/private shared key used for authentication

  • CREDS_CLIENT_ID - the client id used for authentication

  • OUTPUT_FILE - the path where the fetched authorization token is stored, example: “/tmp/authToken.txt”

  • AUTH_SERVICE_URL - the URL to the authentication service (Keycloak)

  • REFRESH_MARGIN_SECONDS - how long in advance before the authorization token expires it is refreshed

RApp Manager Service

Early version of a service to manage rApps and rApp instances.

  • Manages the entire lifecycle and state of rApp and thie instances

  • Integrated with NONRTRIC Data Management & Exposure functions (ICS)

  • Integrates with NONRTRIC Service registration and discovery functions (SME CAPIF)

  • Also add new ONAP ACM participants to handle rApp composition elements

Implementation:

RAN Performance Monitoring Functions (File-based PM)

Functions to collect/parse/filter/store/forward file-based & event-based RAN PM data:

  • End-to-end tool-chain to collection, parsing, filtering and delivery of file-based RAN PM observability data

  • PM report data format defined by 3GPP (TS 32.432 and 3GPP TS 32.435)

  • High performance, fully scalable

  • Subscribers (e.g. rApps) can subscribe for chosen measurement types from specific resources in the network

Implementation:

Non-RT-RIC Test Framework

A full test environment with extensive test cases/scripts can be found in the test directory in the nonrtric source code.

Non-RT-RIC Use Cases

“Helloworld” O-RU Fronthaul Recovery use case

A very simplified closed-loop rApp use case to re-establish front-haul connections between O-DUs and O-RUs if they fail. Not intended to to be ‘real-world’.

Implementation:

  • One version implemented in Python, one in Go as an Information Coordination Service Consumer, and one as an apex policy.

  • Repo: nonrtric/rapp/orufhrecovery

  • Documentation at the O-RU Fronthaul Recovery documentation site.

“Helloworld” O-DU Slice Assurance use case

A very simplified closed-loop rApp use case to re-prioritize a RAN slice’s radio resource allocation priority if sufficient throughput cannot be maintained. Not intended to to be ‘real-world’.

Implementation:

  • One version implemented in Go as a micro service, one in Go as an Information Coordination Service Consumer.

  • Repo: nonrtric/rapp/ransliceassurance

  • Documentation at the O-DU Slice Assurance documentation site.