This page describes how to get the release A version of NonRTRIC up and running locally with two separate NearRT-RIC simulator docker containers.
All four components of the NonRTRIC repo run inside docker containers and communicate via a docker network. Details of the architecture can be found in the link: from Release A page.
Table of Contents |
---|
Project Requirements
...
Download the nonrtric repo:
git clone "https://gerrit.o-ran-sc.org/r/nonrtric" -b Amber
Configure policy-agent
To support local test with two separate NearRT-RIC simulator instances the following modifications must be done:
...
- The following step is required only if you want to run more than the default ric1 nearRT-RIC simulator instance
- replace the content of nonrtric/policy-agent/config/application_configuration.yaml json with the configuration below
- any defined ric names must match the given docker container names in nearRT-RIC simulator startup - port is always the simulator's internal 8085
...
Code Block | ||||
---|---|---|---|---|
| ||||
{ "config": { "//description": "Application configuration", "ric": [ { "name": "ric1", "baseUrl": "http://ric1:8085/", "managedElementIds": [ "kista_1", "kista_2" ] }, { "name": "ric2", "baseUrl": "http://ric2:8085/", "managedElementIds": [ "kista_3", "kista_4" ] } ] } } |
...
Verify dashboard configuration
Note also that nonrtric/dashboard/webapp-backend/src/main/resources/application.properties default property value policycontroller.url.prefix = http://policy-agent-container:8081 assumes that policy agent is started with name policy-agent-container and exposes port 8081 (as is done below)!
Build the code and create docker images
To build all non RT-RIC components.docker images of sdnc-a1-controller, policy-agent, near-rt-ric-simulator and nonrtric-dashboard:
Code Block | ||
---|---|---|
| ||
cd nonrtric
mvn clean install -Dmaven.test.skip=true |
Run A1 Controller Docker Container
- A1 Controller must be started first to set up docker network
- Change directory to:
cd nonrtric/sdnc-a1-controller/oam/installation/src/main/yaml
- Run docker container using the command below
docker-compose up -d a1-controller
- the container is ready once message "Healthcheck Passed in XX seconds." appears
- note that certificate-related errors "cp: can't stat '/opt/opendaylight/current/certs/*': No such file or directory" and "Error: File not found in path entered" can be ignored
- The Karaf logs of A1 controller can be seen using the following commands:
docker exec -it a1-controller-container sh
cd opt/opendaylight/data/log/
tail -f karaf.log
...
- Start docker containers for each ric defined in nonrtric/policy-agent/config/application_configuration.yaml json in previous steps using following commands (in this example for ric1 and ric2):
docker run -p 8085:8085 --network=nonrtric-docker-net --name=ric1 o-ran-sc/near-rt-ric-simulator:1.0.1-SNAPSHOT
docker run -p 8086:8085 --network=nonrtric-docker-net --name=ric2 o-ran-sc/near-rt-ric-simulator:1.0.1-SNAPSHOT - Change directory to:
cd nonrtric/near-rt-ric-simulator/ric-plt/a1
- Put an example policy_type into all the started near-rt-ric-simulator instances by running these curl commands (in this example to ric1 exposed to port 8085 and ric2 exposed to port 8086):
curl -X PUT -v "http://localhost:8085/policytypes/STD_QoSNudging_0.2.0" -H "accept: application/json" \
-H "Content-Type: application/json" --data-binary @policy_type_STD_QoSNudging_0.2.0.json
curl -X PUT -v "http://localhost:8086/policytypes/STD_QoSNudging_0.2.0" -H "accept: application/json" \
-H "Content-Type: application/json" --data-binary @policy_type_STD_QoSNudging_0.2.0.json
...
- Run docker container using this command once A1 Controller and simulators have been fully started (see note below)::
docker run -p 8081:8081 --network=nonrtric-docker-net --name=policy-agent-container o-ran-sc/nonrtric-policy-agent:1.0.0-SNAPSHOT
Note on automatic A1 Client selection
After starting Once policy-agent is up and running, it establishes connections to all configured NearRT-RICs. Policy-agent It has multiple A1 clients to select from and selection is done dynamically based on connectivity. Selection of A1 client is not clearly visible for user and poli, but policy-agent logs can be grepped to see which client was selected.
E.g. here's 2 example grepping where either SDNC The two grepping examples below show how either SDNC_OSC A1 client or STD A1 client was selected i.e. option - these translate into options A and B described on the Testing End to End call in release A page.
Code Block | ||||
---|---|---|---|---|
| ||||
$ docker logs policy-agent | grep ", protocol version:" 2020-03-30 05:33:21.765 DEBUG 1 --- [or-http-epoll-2] o.o.policyagent.clients.A1ClientFactory : Recover ric: ric2, protocol version:SDNC_OSC 2020-03-30 05:33:21.784 DEBUG 1 --- [or-http-epoll-1] o.o.policyagent.clients.A1ClientFactory : Recover ric: ric1, protocol version:SDNC_OSC |
...
Code Block | ||||
---|---|---|---|---|
| ||||
$ docker logs policy-agent | grep ", protocol version:" 2020-04-03 12:06:54.548 DEBUG 1 --- [or-http-epoll-1] o.o.policyagent.clients.A1ClientFactory : Recover ric: ric1, protocol version:STD_V1 2020-04-03 12:06:54.552 DEBUG 1 --- [or-http-epoll-2] o.o.policyagent.clients.A1ClientFactory : Recover ric: ric2, protocol version:STD_V1 |
...