Non-RT RIC¶
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, RAN analytics and model-training for the near-RealTime RICs. 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.
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 Service Exposure Security Architecture Prototyping. Documentation site.
DMaaP/Kafka Information Producer Adapters. Documentation site adapter. Documentation site mediator.
-
“Helloworld” O-RU Fronthaul Recovery use case. Documentation site.
“Helloworld” O-DU Slice Assurance use case. Documentation site.
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:
Frontend: Angular framework
Repo: portal/nonrtric-controlpanel
Wiki to set up in your local environment.
Documentation at the NONRTRIC-Portal documentation site.
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:
Implemented as a Java Spring Boot application.
Repo: nonrtric/plt/informationcoordinatorservice.
Documentation at the Information Coordination Service site.
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:
Implemented as a Java Spring Boot application.
Repo: nonrtric/plt/a1policymanagementservice.
Documentation at the A1 Policy Management Service documentation site.
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:
Repo: nonrtric/plt/sdnca1controller
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:
Implemented as a Python application.
Repo: sim/a1-interface.
Documentation at the A1 Simulator documentation site.
(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 .
Support dynamic registration and exposure of service interfaces to Non-RT-RIC applications (& NONRTRIC Control panel).
The architecture and componets are defined in Non-RT RIC Security Architecture Prototyping (Documentation site).
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:
Implementation in Java Spring (DMaaP Adapter), repo: nonrtric/plt/dmaapadapter, see DMaaP Adapter documentation site.
Implementation in Go (DMaaP Mediator Producer), repo: nonrtric/plt/dmaapmediatorproducer, see DMaaP Mediator Producer documentation site.
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:
Implemented as a Java Spring Boot application.
Repo: nonrtric/plt/rappcatalogue
Documentation at the rApp Catalogue documentation site.
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:
Implemented as a Java Spring Boot application.
Repo: nonrtric/plt/helmmanager
Documentation at the Helm Manager documentation site.
Service Management and Exposure¶
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:
Implemented in Go
Repo: nonrtric/plt/sme
Documentation at the Service Management & Exposure (SME) documentation site.
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.
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
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:
Implemented in Go, Java and Python
Repo: nonrtric/plt/ranpm
Documentation at the Non-RT RIC RAN PM Usecase / Functions documentation site.
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.
Developer Guide¶
This document provides a quickstart for developers of the Non-RT RIC parts.
Additional developer guides are available on the O-RAN SC NONRTRIC Developer wiki.
Kubernetes deployment¶
Non-RT RIC can be also deployed in a Kubernetes cluster, it/dep repository. hosts deployment and integration artifacts. Instructions and helm charts to deploy the Non-RT-RIC functions in the OSC NONRTRIC integrated test environment can be found in the ./nonrtric directory.
For more information on installation of NonRT-RIC in Kubernetes, see Deploy NONRTRIC in Kubernetes.
For more information see Integration and Testing documentation in the O-RAN-SC.
API-Docs¶
Descriptions of the APIs to the Non-RT RIC functions can be found in the repos for the functions.
Use Cases¶
To support the use cases defined for the Non-RT RIC, there are implementations provided in the Non RT-RIC project.
Health Check¶
The Health Check use case for the Non-RT RIC is a python script that regularly creates, reads, updates, and deletes a policy in all Near-RT RICs that support the type used by the script. A self refreshing web page provides a view of statistics for these regular checks.
For more information about it, see the README file in repo.
O-RU Front-Haul Recovery¶
This use case is a non-real-world closed-loop use case to demonstrate automated recovery when the front-haul connection between an O-DU and O-RU is reset. An application in the NONRTRIC senses the fault from the O-RU (O1-FM) and initiates a NETCONF reset operation (O1-CM) using the OAM controller. More details about the use case can be found on the O-RAN SC wiki: RSAC and OAM.
Non-RT RIC provides multiple implementation versions of the recovery part of the use case. One in the form of a python script, one utilizing the ONAP Policy Framework, and one Go version that utilizes Information Coordination Service (ICS).
The code is available in the use case repo
Standalone Script Solution¶
The script version consists of a python script that performs the tasks needed for the use case. There are also two simulators. One message generator that generates alarm messages, and one SDN-R simulator that receives the config change messages sent from the script and responds with alarm cleared messages to MR.
All parts are Dockerized and can be started as individual containers, in the same network, in Docker.
ONAP Policy Solution¶
There is also another solution for performing the front-haul recovery that is based on ONAP Policy Framework. A TOSCA Policy has been created that listens to DMaaP Message Router, makes a decision on an appropriate remedy and then signals the decision as a configuration change message via REST call to the OAM controller.
There is a docker-compose available in the nonrtric repo for bringing up the complete standalone version of ONAP Policy Framework.
The detailed instructions for deploying and running this policy are provided in the wiki.
ICS Consumer Solution¶
The ICS Consumer solution is implemented in Go and instead of polling MR itself, it registers as a consumer of the “STD_Fault_Messages” job in ICS.
Requirements for the Non-RT RIC project¶
Find detailed description of what Non-RT RIC is on this page.
The NONRTRIC project (and the O-RAN Non-RealTime RIC function) can be considered from a number of different viewpoints. This page presents some of these views:
Scope 1: A1 Controller (Mediator, Endpoint)
Southbound: Provide termination point for A1 interface(s) - REST endpoint for messages to/from Near-RealTime RIC
Northbound: Provide a more generic interface for A1 operations - provide interface to rApps, without the need for A1 message generation, addressing, coordination, mediation, etc.
O1 interfaces do not terminate in NONRTRIC function (but may terminate in same controller host/instance)
Scope 2: Coordinate/Host A1 Policy Management Services
Map high level RAN goal/intent directives to finely-scoped A1 Policies towards individual Near-RT RIC instances
Informed by observed RAN context (provided over O1 via OAM functions), and other external context (via other SMO functions)
Dynamically coordinate life cycles of A1 Policies in individual Near-RT RICs as contexts change
Scope 3: Coordinate ML/AI Models - In RAN (“E2 nodes” & Near-RT RICs) and NONRTRIC (future)
Acts as model-training host
May act as model-inference host (others: Near-RT RICs, “E2 nodes”)
Dynamically coordinate ML/AI model lifecycle management (e.g. re-train, re-deploy, etc)
Models are (always?) deployed over O1 interface
Scope 4: Enrichment Data Coordinator
Additional context that is unavailable to Near-RT RICs (e.g. RAN data, SMO context, External context)
Dynamically coordinate access and pass data to appropriate Near-RT RICs (e.g. for use in ML/AI model inference)
Scope 5: rApp Host & rApp Coordinator
rApps may act as, or form part of, NONRTRIC- or SMO-level applications
rApps, via rApp host function, may consume many other services - some from the NONRTRIC platform, some from the SMO platform, and some from other rApps
Dynamically coordinate rApp lifecycle management
Scope 6: Provide R1 interface for rApps
rApps may only consume services over the R1 interface (from NONRTRIC platform, or from SMO platform, or from other rApps)
Platform services and services optionally provided by rApps must be exposed over the R1 Interface
These services may be “standardized” R1 services or R1 extensions (some may be proprietary)
Installation Guide¶
Abstract¶
This document describes how to install the Non-RT RIC components, their dependencies and required system resources.
Software Installation and Deployment¶
Install with Docker¶
Docker compose files are provided, in the “docker-compose” folder, to install the components. Run the following command to start the components:
docker-compose -f docker-compose.yaml -f policy-service/docker-compose.yaml -f ics/docker-compose.yaml
The example above is just an example to start some of the components. For more information on running and configuring the functions can be found in the README file in the “docker-compose” folder, and on the wiki page
Install with Helm¶
Helm charts and an example recipe are provided in the it/dep repo, under “nonrtric”. By modifying the variables named “installXXX” in the beginning of the example recipe file, which components that will be installed can be controlled. Then the components can be installed and started by running the following command:
bin/deploy-nonrtric -f nonrtric/RECIPE_EXAMPLE/example_recipe.yaml
Release-Notes¶
This document provides the release notes for the release of the different parts of the Non-RT RIC.
Prior to release F several functions were homed in this repository, and released from here. Currently the only function released from here is the “Auth Token Fetch” utility image (see below).
Functions, previously here, but now with their own repos have their own release notes:
DMaaP/Kafka Information Producer Adapters. DMaaPAdapter. DMaaP Mediator Producer.
Use Cases:
Bronze¶
Project |
Non-RT RIC |
Repo/commit-ID |
nonrtric/2466f9d370214b578efedd1d3e38b1de17e6ca1c |
Release designation |
Bronze |
Release date |
2020-06-18 |
Purpose of the delivery |
Improved stability |
Bronze Maintenance¶
Project |
Non-RT RIC |
Repo/commit-ID |
nonrtric/5d4f252a530a0d9abbf2a363354c5e56e8f2f33e |
Release designation |
Bronze |
Release date |
2020-07-29 |
Purpose of the delivery |
Introduce configuration of certificates |
Cherry¶
Project |
Non-RT RIC |
Repo/commit-ID |
nonrtric/90ce16238dd6970153e1c0fbddb15e32c68c504f |
Release designation |
Cherry |
Release date |
2020-12-03 |
Purpose of the delivery |
Introduction of Enrichment Service Coordinator and rAPP Catalogue |
D¶
Project |
Non-RT RIC |
Repo/commit-ID |
nonrtric/dd3ebfd784e96919a00ddd745826f8a8e074c66f |
Release designation |
D |
Release date |
2021-06-23 |
Purpose of the delivery |
Improvements Introduction of initial version of Helm Manager |
D Maintenance¶
Project |
Non-RT RIC |
Repo/commit-ID |
nonrtric/973ae56894fb29a929fba9e344cae42e7607087b |
Release designation |
D |
Release date |
2021-08-10 |
Purpose of the delivery |
Minor bug fixes |
E Release¶
Project |
Non-RT RIC |
Repo/commit-ID |
nonrtric/b472c167413a55a42fc7bfa08d2138f967a204fb |
Release designation |
E |
Release date |
2021-12-13 |
Purpose of the delivery |
Improvements and renaming. Introduction of more usecase implementations. |
E Maintenance Release¶
Project |
Non-RT RIC |
Repo/commit-ID |
nonrtric/4df1f9ca4cd1ebc21e0c5ea57bcb0b7ef096d067 |
Release designation |
E |
Release date |
2022-02-09 |
Purpose of the delivery |
Improvements and bug fixes |
F Release¶
Project |
Non-RT RIC |
Repo/commit-ID |
nonrtric/46f2c66ed30ceef4cedd7992b88c9563df0f24a5 |
Release designation |
F |
Release date |
2022-08-18 |
Purpose of the delivery |
First version of nonrtric-plt-auth-token-fetch |
H Release¶
Project |
Non-RT RIC |
Repo/commit-ID |
nonrtric/3db8626c0900dc391b8e810541de9761c78043d8 |
Release designation |
H |
Release date |
2023-06-16 |
Purpose of the delivery |
nonrtric-plt-auth-token-fetch:1.1.1 Updated Springboot version |
Security Architecture Prototyping¶
Introduction¶
The O-RAN (Open Radio Access Network) security architecture is a framework for securing the communication between different components of an open system. It is designed to ensure the confidentiality, integrity, and availability of data and services, while also providing protection against potential security threats. This involves securing the communication between different components, including encryption, authentication, and access control. The O-RAN security architecture is designed to be flexible, scalable, and interoperable, enabling different vendors to integrate their solutions into the O-RAN ecosystem while maintaining security.
Here are some key features provided by the platform:
MTLS provides secure encrypted communication and mutual authentication of peers.
Users are authenticated using a client via the OpenID Connect (OIDC) protocol.
OAuth 2.0 is a framework that controls authorization for access of services.
Apps (rApps) need to use Service Management & Orchestration (SMO) services and provide services to other Apps. Apps & SMO services may be multivendor. The goal of the Security Architecture is to provide selective & controlled exposure of these services.
Ensure that services cannot be accessed without a valid token.
Ensure that inter-services communication is done using mTLS.
Ensure the automated setup and configuration of security prior to app deployment.
This product is a part of NONRTRIC.
Components¶
Istio¶
App security relies on Istio service mesh to enforce mTLS between applications. The applications running in the cluster are not required to implement mTLS, instead this is done by attaching an Istio sidecar to the running containers. mTLS communication is done between the sidecars.
Keycloak¶
Keycloak is an open-source identity and access management tool. It is used to issue access tokens to the apps. The access token comes in the form of a JWT which includes claims or fields which are used to determine the access level to grant to a particular app.
Access tokens (JWT) are retrieved using Keycloak clients.
Access token has limited lifetime (needs to be refreshed).
Access token is sent in the HTTP header is each REST call.
This is an example of a JWT payload:
{
"exp": 1683628065,
"iat": 1683627765,
"jti": "b61ae49d-5a73-4e91-96f2-de3b400a5779",
"iss": "https://keycloak:8443/realms/demo",
"sub": "e7709f80-61bd-4440-a265-d51c4fed8ece",
"typ": "Bearer",
"azp": "demoprovider-cli",
"session_state": "89ac7390-2865-4e07-bd1a-aea43c43827a",
"scope": "email",
"sid": "89ac7390-2865-4e07-bd1a-aea43c43827a",
"clientHost": "127.0.0.6",
"clientId": "demoprovider-cli",
"email_verified": false,
"clientRole": [
"provider-viewer"
],
"clientAddress": "127.0.0.6"
}
Postgres¶
Postgres is used as the back-end database for Keycloak, it will persistent the Keycloak objects that have been created.
Cert Manager¶
Cert Manager is used to provide both server and client certificates for Keycloak. It also provides certificates for the webhook server.
Chart Museum¶
Chart museum is used to stores the Helm charts for the apps.
Helm Installer¶
Helm installer is used to automate the installation of the Helm charts. Each chart contains an app configuration section in the values.yaml file which is used by Istio manager and Keycloak manager.
Istio Manager¶
Istio manager is used to automate the setup of Gateways, Virtual Services, Authorization Policies and Request Authentication polices for the apps. The exact configuration required is read from the values.yaml file in the Helm chart.
Keycloak Manager¶
Keycloak manager is used to automate the setup of realms, clients, users, role mappings and authentication flows. Keycloak provides REST API endpoints for creating and deleting these objects. The exact configuration required is read from the values.yaml file in the Helm chart.
JWT Proxy Controller¶
The Jwt Proxy Admission Controller determines whether to attach a jwt proxy sidecar to the app container based on the app label. If permitted the exact configuration required is read from the values.yaml file in the Helm chart.
Request Flow¶
Provider App¶
When a provider app is installed using Helm manager, all the necessary security is automatically setup prior to deployment.
- Helm manager calls Istio manager and sets up the following Istio services:
Gateway: a load balancer operating at the edge of the mesh receiving incoming or outgoing HTTP/TCP connections.
VirtualService: routes request from the gateway to the app.
RequestAuthentication: verifies the issuer and jwksUri of the JWT.
AuthorizationPolicy: authorizes incoming requests based on claims in the JWT.
- Helm manager calls Keycloak manager and sets up the following Keycloak objects:
Realm : represents a set of users, credentials, roles, groups and clients. Realms can be used to isolated different apps from each other.
Client: used to authenticate a user and retrieve a JWT.
Role Mapper: maps the user role(s) to the token. These role(s) are used during app authorization.
- Clients support 4 authenticator types:
Client Secret
x509 certificate
JWT signed with certificate
JWT signed with secret
Depending on the app configuration it will either setup an x509 client, a jwt client or a secret client.
Note
If the app is configured to use the x509 authenticator, a direct flow grant for x509 is also setup to check fields in x509 certificate against some pre-defined value(s).
Invoker App¶
When an invoker app is installed using Helm manager, the app label is used to determine whether to inject the deployment with a jwt proxy sidecar. If the app label has been whitelisted the proxy is added to the container. The jwt proxy sidecar will automatically retrieve the token required to access the app provider and include it in the request header.
This is an example of a provider and invoker running in a cluster:
Note
Security for service registry and management using the 3GPP Common API framework is available here: Service Management & Exposure (SME) documentation site.