Non-RT RIC Information Coordination Service
Information Coordination Service
The Information Coordination Service (ICS) is a generic service that maintains data subscriptions. Its main purpose is to decouple data consumers and data producers in a multi vendor environment. A data consumer does not need to know anything about the producers of the data.
This product is a part of NONRTRIC.
The following terms are used:
Data Consumer, is a subscriber of data. Subscription is done by creating an “Information Job”. A data consumer can for instance be an R-App (using the R1 API) or a NearRT-RIC consuming Enrichment Information (and uses the A1-EI API provided by this service).
Information Type, is a type of information. This defines an interface between consumers and producers. Each information type defines which parameters can be used for creating an information job. These parameters are defined by a Json schema connected to the Information Type. These parameters may include:
Parameters related to data delivery (for instance a callback URL if REST is used or a Kafka stream). These are different for different delivery protocols.
Filtering or other information for data selection.
Periodicy
Other info used for aggregation
Data Producer is a producer of data. A producer will get notified about all information jobs of its supported types. This also means that filtering is done at the producer (ideally at the source of the data). A data producer can for instance be an R-App.
One information type can be supported by zero to many data producers and can be subscribed to by zero to many data consumers. For example, there can be two data producers for a type of data; one from one vendor (handling a part of the network) and another from a different vendor. A data consumer is agnostic about this.
Information Jobs and types are stored persistently by ICS in a local database. This can be either using Amazon S3 - Cloud Object Storage or file system.
To restrict which data that can be consumed and by whom there is support for finegrained access control. When data subscriptions/jobs are modified or read, an access check can be performed. ICS can be configured to call an external authorizer. For example, this can be Open Policy Agent (OPA) which can grant or deny accesses based on an access token (JWT) used by the calling data consumer. In addition to this the information type, accesstype (read/write) and all type specific parameters can be used by access rules.
The URL to the authorization component is defined in the application.yaml file and the call invoked to by ICS is described in API documentation.
Key Requirements
Multiple producers, posibly from different vendors, should be able to produce the same type of data.
The system should allow for arbitrary installation, upgrade, scaling up, scaling down, and restarting of software, in any order.
ICS should decouple data producers from data consumers. Consumers should not be aware of producers, their endpoints, or the number of producers. Upgrades, scaling, and other changes to producers should not affect consumers. That also means that a producer can be replaced by another one.
Data consumers should be able to start subscriptions at any time, including before a producer is installed, or during a producer’s upgrade, restart, or scaling up/down.
The system should impose as few restrictions as possible on how software is implemented. Applications may, for example, be implemented as multiple identical executing entities for load sharing.
The lifecycle of a data type in the system should not be controlled by a single producer. There may be data types and subscriptions for data types that have no producers, such as during an upgrade scenario.
A data type specification should contain all the information needed to implement both producers and consumers. The data type specification forms the API between these. It must define the ID of the data type, all possible parameters used at subscription creation (such as filter constructions), and all details about the delivered format and the delivery mechanism. This is comparable to a Managed Object Model.
ICS should mediate data type versioning and choose compatible data producers. For example, if there are two producers, one producing dataType version 1.5.0 and another producing version 1.4.0, and a consumer subscribes to data version 1.1.0, both these producers should be involved (since version 1.4.0 and version 1.5.0 are backwards compatible with version 1.1.0). The system should be able to handle these versioning scenarios automatically.
A consumer shall be able to retrieve its jobs after a restart. Therefore it must be possible to group the jobs based on a label “owner” which is defined by the consumer. This must be unique, which suggests that it should be based on UUIDS, but this is up to the consumer. This “owner” can be a POD, an application etc. ICS should not restrict that.
Summary of principles
ICS provides APIs for control of data subscriptions, but is not involved in the delivery of data. This means that any delivery protocol can be used.
Data for one Information type can be produced by many producers from different vendors.
Data filtering is done by the producer. ICS does not restrict how data selection/filtering is done.
A Data Consumer can create a data subscription (Information Job) regardless of the status of the data producers. The producers can come and go without any need for the Data Consumer to take any action. A subscription indicates the need for a type of data and the system should do its best to fulfill this.
ICS is by design not aware of any subscribable data types.
When a consumer creates a subscription/job, ICS shall choose the information type version with the lowest available compatible version. All producers that have registered a type that is compatible with the chosen version are included. Example, if a consumer creates a job with type version 1.1.0, the chosen type may 1.2.0 and a producer supporting version 1.9.0 will be included (but not a producer that supports version 2.0.0).
Example
In the example, there is one subscription and the type of data is supported by two producers. That means that both producers are aware of the information job and will delver data directly to the subscriber.
So a typical sequence is that:
An Information Type is registered.
Producers of the Information Types are registered
A Consumer creates an Information Job of the type and supplies the type specific parameters for data delivery and filtering etc.
The producers gets notified of the job and will start producing data.
If a new producer is started, it will register itself and will get notified of all jobs of its supported types.
Implementation
Implemented as a Java Spring Boot application.
Developer Guide
This document provides a quickstart for developers of the Non-RT RIC Information Coordinator Service.
Additional developer guides are available on the O-RAN SC NONRTRIC Developer wiki.
The Information Coordinator Service is a Java 11 web application built using the Spring Framework. Using Spring Boot dependencies, it runs as a standalone application.
Its main functionality is to act as a data subscription broker and to decouple data producer from data consumers.
See the ./config/README file in the information-coordinator-service directory Gerrit repo on how to create and setup the certificates and private keys needed for HTTPS.
Start standalone
The project uses Maven. To start the Information Coordinator Service as a freestanding application, run the following command in the information-coordinator-service directory:
mvn spring-boot:run
There are a few files that needs to be available to run. These are referred to from the application.yaml file. The following properties have to be modified:
server.ssl.key-store=./config/keystore.jks
app.webclient.trust-store=./config/truststore.jks
app.vardata-directory=./target
Start in Docker
To build and deploy the Information Coordinator Service, go to the “information-coordinator-service” folder and run the following command:
mvn clean install
Then start the container by running the following command:
docker run nonrtric-information-coordinator-service
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
Here we describe the API to access the Non-RT RIC Information Coordination Service.
Information Coordinator Service
See A1 Information Information Coordination Service API for full details of the API.
The API is also described in Swagger-JSON and YAML:
API name |
|
|
|---|---|---|
A1 Information Coordination Service API |
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 Non-RT RIC Information Coordination Service.
Version history Information Coordinator Service
Date |
Ver. |
Author |
Comment |
2020-12-03 |
1.0.0 |
Henrik Andersson |
Cherry Release |
2021-06-23 |
1.1.0 |
Henrik Andersson |
D Release |
2021-12-13 |
1.2.0 |
Henrik Andersson |
E Release Renamed and minor improvements |
2022-02-07 |
1.2.1 |
Henrik Andersson |
E Maintenance Release Non root user in Docker |
2022-06-28 |
1.3.0 |
Henrik Andersson |
F Release |
2022-08-25 |
1.3.1 |
Patrik Buhr |
F Maintenance Release |
2022-12-12 |
1.4.0 |
Henrik Andersson |
G Release |
2023-02-10 |
1.4.1 |
Yennifer Chacon |
G Maintenance Release |
2023-06-16 |
1.5.0 |
John Keeney |
H Release |
Release Data
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 |
D
Project |
Non-RT RIC |
Repo/commit-ID |
nonrtric/dd3ebfd784e96919a00ddd745826f8a8e074c66f |
Release designation |
D |
Release date |
2021-06-23 |
Purpose of the delivery |
Improvements |
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. |
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 Information Coordinator Service |
Repo/commit-ID |
nonrtric/plt/informationcoordinatorservice/ 9d9519c5d9de072aa6676ce83042870a9fb8aec0 |
Release designation |
F |
Release date |
2022-06-28 |
Purpose of the delivery |
Moved to separate repo. Minor improvements |
F Maintenance Release
Project |
Non-RT RIC Information Coordinator Service |
Repo/commit-ID |
nonrtric/plt/informationcoordinatorservice/ 8b580aa39781ea7a05062aec76e09cc161bc59f2 |
Release designation |
F |
Release date |
2022-08-25 |
Purpose of the delivery |
Minor improvements |
G Release
Project |
Non-RT RIC Information Coordinator Service |
Repo/commit-ID |
nonrtric/plt/informationcoordinatorservice/ a18d40cef8ec6a2b709f3f280a6017eca06d5f92 |
Release designation |
G |
Release date |
2022-12-12 |
Purpose of the delivery |
Improved logging, NBI feature, S3 storage, fine grained authorization |
G Maintenance Release
Project |
Non-RT RIC Information Coordinator Service |
Repo/commit-ID |
nonrtric/plt/informationcoordinatorservice/ 88d81a5b7d15e68bbb2e0ea7c05203bfc1afd11f |
Release designation |
G |
Release date |
2023-02-10 |
Purpose of the delivery |
Minor improvements |
H Release
Project |
Non-RT RIC Information Coordinator Service |
Repo/commit-ID |
nonrtric/plt/informationcoordinatorservice/ 175df231e7b86fcfcb57ac21bb9987f4d04694ff |
Release designation |
H |
Release date |
2023-06-16 |
Purpose of the delivery |
|