This page describes how to get the New-Delhi release version of A1-Policy functions up and running using Docker.

The A1 Policy Management Service and the (optional) A1-enabled Controller (SDNC with A1-Adapter) will run in a local demonstrative deployment with four near-RT-RIC A1 simulator instances (docker containers). These simulators will be configured to emulate devices implementing either the "OSC_2.1.0" version or "STD_2.0.0" version of the O-RAN A1 interface. (For more information on the OSC A1 Simulator functions see OSC NONRTRIC Wiki page (Release K)

All components run as docker containers and communicate via a private docker network. Details of the architecture can be found from "Oslo" Release page.

Note: Version numbers used in this page may not be the most recent ... you should verify the latest version numbers for released pre-built components in the docker image repository (https://nexus3.onap.org)

Project Requirements

Java 17 (make sure that JAVA_HOME environment variable points to correct Java version)
Maven 3.8+ (make sure you have configured maven to access the ONAP maven repositories)
Docker and docker-compose (latest)

Create Configuration for A1 Policy Management Service

Configure the A1 Policy Management Service

To support local test with four separate near-RT-RIC simulator instances:

Copy the default configuration file oran/a1-policy-management/config/application_configuration.json (oslo) to the current directory, then replace/amend the configuration with the sample demo configuration below. (Note - downloaded version is different from the versions below)
(Note the configuration below is just a sample, and should be updated to match particular deployments.
The deployment below assumes 4 near-RT-RICs exist - addressable at the URLs given.
See the step "Run OSC Near-RT-RIC/A1 Simulator Docker Containers" below)
The controller URL (hostname, port), username and password values to access the A1 Controller (SDNC + A1 Adapter) must match the values configured for the SDNC-A1-Controller. (See the step "Run A1 Controller" further below). The port number for http here is 8181.
(Note the configuration below is just a sample, and should be updated to match particular deployments.
The deployment below assumes an A1 Controller function (SDNC) exists - addressable at the url given, using the authentication credentials given.)
Any defined ric host names values (in the name and baseUrl parameters for each ric entry) must match the given docker container names in near-RT-RIC simulator startup.
Here the port the simulator's internal port 8085, for http or 8185 for https.
Note: The A1 Policy Management service can entirely by-pass the A1-Controller (SDNC + A1 Adapter) if desired - it is optional to access the near-RT-RIC through an A1-Controller/SDNC. (See 'Alternative' below)

Sample application configuration

Sample: application_configuration.json

{
  "description": "Application configuration",
  "config": {    
    "controller": [
      {
        "name": "controller1",
        "baseUrl": "http://sdnc_controller:8181",
        "userName": "admin",
        "password": "Kp8bJ4SXszM0WXlhak3eHlcse2gAw84vaoGGmJvUy2U"
      }
    ],
    "ric": [
      {
        "name": "ric1",
        "baseUrl": "http://ric1:8085/", 
        "managedElementIds": [
        ]
      },
      {
        "name": "ric2",
        "baseUrl": "http://ric2:8085/",       
        "managedElementIds": [
          "kista_3",
          "kista_4"
        ]
      },
       {
        "name": "ric3",
        "baseUrl": "http://ric3:8085/",
        "controller": "controller1", 
        "managedElementIds": [
          "kista_5",
          "kista_6"
        ]
      },
       {
        "name": "ric4",
        "baseUrl": "http://ric4:8085/",
        "controller": "controller1", 
        "managedElementIds": [
          "kista_7",
          "kista_8",
          "kista_9",
          "kista_10",
          "kista_11"
         ]
      }
    ]
  }
}

Alternative: Bypass the A1-Controller - connect direct from A1-Policy Management Service

There is no functional gain in accessing the near-RT-RIC through an A1-Controller.

To bypass the A1-Controller (SDNC + A1 Adapter), where the A1-Policy Management Service connects directly to the A1 Interface:

In the configuration the "controller" property is optional in the "ric" objects. Remove this entry to by-pass SDNC/A1-Adapter.
If all configured rics bypass the A1-Controller (do not have "controller" values) then the "controller" object at the top of the configuration can be omitted.
If all configured rics bypass the A1-Controller there is no need to start an A1-Controller (SDNC + A1 Adapter).

Sample Application Configuration - bypassing the A1-Controller

{
  "description": "Application configuration",
  "config": {
    "ric": [
      {
        "name": "ric1",
        "baseUrl": "http://ric1:8085/",
        "managedElementIds": []
      },
      {
        "name": "ric2",
        "baseUrl": "http://ric2:8085/",
        "managedElementIds": [
          "kista_3",
          "kista_4"
        ]
      },
      {
        "name": "ric3",
        "baseUrl": "http://ric3:8085/",
        "managedElementIds": [
          "kista_5",
          "kista_6"
        ]
      },
      {
        "name": "ric4",
        "baseUrl": "http://ric4:8085/",
        "managedElementIds": [
          "kista_7",
          "kista_8",
          "kista_9",
          "kista_10",
          "kista_11"
        ]
      }
    ]
  }
}

JSON Schema for the application configuration

The configuration must comply to the following JSON schema. There are several publicly available tools (e.g. online) where it is possible to validate JSON objects against their schema.
The schema is available in the gerrit repo (application_configuration_schema.json (oslo))

application_configuration_schema.json

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "properties": {
    "config": {
      "type": "object",
      "properties": {
        "//description": {
          "type": "string"
        },
        "description": {
          "type": "string"
        },
        "controller": {
          "type": "array",
          "items": [
            {
              "type": "object",
              "properties": {
                "name": {
                  "type": "string"
                },
                "baseUrl": {
                  "type": "string"
                },
                "userName": {
                  "type": "string"
                },
                "password": {
                  "type": "string"
                }
              },
              "required": [
                "name",
                "baseUrl",
                "userName",
                "password"
              ],
              "additionalProperties": false
            }
          ]
        },
        "ric": {
          "type": "array",
          "items": [
            {
              "type": "object",
              "properties": {
                "name": {
                  "type": "string"
                },
                "baseUrl": {
                  "type": "string"
                },
                "controller": {
                  "type": "string"
                },
                "customAdapterClass": {
                  "type": "string"
                },
                "managedElementIds": {
                  "type": "array",
                  "items": [
                    {
                      "type": "string"
                    },
                    {
                      "type": "string"
                    }
                  ]
                }
              },
              "required": [
                "name",
                "baseUrl",
                "managedElementIds"
              ],
              "additionalProperties": false
            }
          ]
        }
      },
      "required": [
        "ric"
      ],
      "additionalProperties": true
    }
  },
  "required": [
    "config"
  ]
}

For more information on configuring the A1-Policy Management Service please see Oslo - Component configuration

Running the functions

Note: Version numbers used in this page may not be the most recent ... you should verify the latest version numbers for released pre-built components in the docker image repository (https://nexus3.onap.org), and check the version number in appropriate POM files if building manually.

Component	Release image and version tag	Staging images and version tag	Manual snapshot (only available if manually built) and version tag
A1 Policy Management Service	nexus3.onap.org:10002/onap/ccsdk-oran-a1policymanagementservice:2.0.0	nexus3.onap.org:10004/onap/ccsdk-oran-a1policymanagementservice:2.0.1-STAGING-latest	onap/ccsdk-oran-a1policymanagementservice:2.0.1-SNAPSHOT
SDNC image	nexus3.onap.org:10002/onap/sdnc-image:3.0.2	nexus3.onap.org:10004/onap/sdnc-image:3.0.3-STAGING-latest	onap/sdnc-image:3.0.3-SNAPSHOT

Run A1-enabled Controller

Alternative: Bypass the A1-Controller - connect direct from A1-Policy Management Service

If you choose to bypass the A1-Controller (SDNC + A1-Adapter), there is no need to start it, so you can skip this step.

To use the A1 Controller function (SDNC + A1-Adapter) you need to run the SDNC docker image. This image has few other docker image dependencies but not all are important for A1 Policy functions. To run a cut-down SDNC container for A1 Policy testing a number of the unneeded services can be removed from the docker compose file. (It is often difficult to get a full SDNC deployment up & running; removing unneeded components makes this easier)

Download and edit the docker compose file, oam/installation/src/main/yaml/docker-compose.yaml (oslo) and keep only sdnc and maria db images. The rest of the images are not needed for A1 Policy testing.
In addition, remove or comment out the following two entries for sdnc in the docker-compose file: '- ansible' and '- ansible:ansiblehost'.
(However if you want to change the SLI DG graphs or run your own SLI DG graphs, then keep the dgbuilder image.)

If you have built the images locally you don't need any other change, however if the images have not been built locally, versions should be modified, from latest to the version that you would like to use, for example: nexus3.onap.org:10002/onap/sdnc-image:3.0.2

Locally built	Release image from nexus
sdnc: image: onap/sdnc-image:latest	sdnc: image: nexus3.onap.org:10002/onap/sdnc-image:3.0.2

There is also a file named docker configuration sdnc-basic.yml (Gerrit - montreal) that can be used instead, it only includes maria db and sdnc so it only needs to be modified when images have not been built locally so versions need to be updated from latest to a specific version, for example nexus3.onap.org:10002/onap/sdnc-image:3.0.2. In this case when using a different docker compose file you will use docker-compose -f sdnc-basic.yml up instead of the normal docker-compose up command in the code block below)

The docker-compose files above requires several environment variables to be set according to your environment.
Sample settings for these environment variables can be found here (montreal), but first check if these values are suitable for your environment.

export MTU=1500
docker network create nonrtric-docker-net
docker-compose up

   (In a new shell) 
docker network connect nonrtric-docker-net sdnc_controller

The SDNC image will take quite a while to install all features into the Karaf Server. You can check the logs of the server at /opt/opendaylight/data/log/karaf.log

Another useful log to check is /opt/opendaylight/data/log/A1-Adapter.log to see log entries related to the SLI DG operation inside the A1-Adapter.

The SDNC/ODL API GUI is also handy, where the internal A1-Policy APIs can be seen/tested. (It may take several minutes before the URLs work as expected as the SDNC/ODL component loads)

http://localhost:8282/apidoc/explorer/index.html (or) http://<yourclusterloginip>/apidoc/explorer/index.html
Username / password: admin / Kp8bJ4SXszM0WXlhak3eHlcse2gAw84vaoGGmJvUy2U
(Note: Username & password are defined in the environment variables used when starting the controller using docker-compose above)
(Note: This A1-Adapter API is not intended for public use. It is used for internal communication only - between the A1 Policy Management Service and the A1-Adapter. This API may change/disappear without notice. This API should only be used for verification/debugging)

(Note these instructions create an A1 Controller deployment scenario aligned towards the sample A1 Policy configuration given above)

If the steps above are unsuccessful more help can be found from the CCSDK/SDNC Developer teams: CCSDK Project & SDNC Project

Run OSC Near-RT-RIC/A1 Simulator Docker Containers

Start docker containers for each near-RT-RIC defined in oran/a1-policy-management/config/application_configuration.json in the step "Configure the A1 Policy Management Service" above.
Different Simulators can use different A1-Interface profiles, for example OSC_2.1.0 and STD_2.0.0 below. Start each simulator instance with the following commands (use separate shells):
```
     (Each in a new shell) 
docker run -p 8085:8085 -p 8185:8185 -e A1_VERSION=OSC_2.1.0 -e ALLOW_HTTP=true --network=nonrtric-docker-net --name=ric1 nexus3.o-ran-sc.org:10002/o-ran-sc/a1-simulator:2.8.0
docker run -p 8086:8085 -p 8186:8185 -e A1_VERSION=OSC_2.1.0 -e ALLOW_HTTP=true --network=nonrtric-docker-net --name=ric2 nexus3.o-ran-sc.org:10002/o-ran-sc/a1-simulator:2.8.0
docker run -p 8087:8085 -p 8187:8185 -e A1_VERSION=STD_2.0.0 -e ALLOW_HTTP=true --network=nonrtric-docker-net --name=ric3 nexus3.o-ran-sc.org:10002/o-ran-sc/a1-simulator:2.8.0
docker run -p 8088:8085 -p 8188:8185 -e A1_VERSION=STD_2.0.0 -e ALLOW_HTTP=true --network=nonrtric-docker-net --name=ric4 nexus3.o-ran-sc.org:10002/o-ran-sc/a1-simulator:2.8.0
```
- (Note these commands create a deployment scenario aligned towards the sample A1 Policy configuration given above)
  (Note these commands can be run in the background - all in one shell - by using docker run -d -p ..... )
- These commands start 4 simulator instances ("ric1", "ric2", "ric3", "ric4"), with REST endpoints at ports 8085 and 8185.
  Other docker containers using the same docker network ("nonrtric-docker-net") can address containers by name, and directly access those REST endpoints. e.g.:
  - (ric1) → ric1:8085 & ric1:8185
  - (ric2) → ric2:8085 & ric2:8185
  - (ric3) → ric3:8085 & ric3:8185
  - (ric4) → ric4:8085 & ric4:8185
- Ports 8085 & 8185 are also exposed outside the network for all 4 simulator instances.
  These ports are mapped to local ports on the host, corresponding to:
  - Port 8085 on ric1 →localhost:8085 and Port 8085 on ric1 →localhost:8185
  - Port 8085 on ric2 →localhost:8086 and Port 8185 on ric2 →localhost:8186
  - Port 8085 on ric3 →localhost:8087 and Port 8185 on ric3 →localhost:8187
  - Port 8085 on ric4 →localhost:8088 and Port 8185 on ric4 →localhost:8188

For the OSC.2.1.0 simulators create a new A1 Policy Type policy type definition (JSON), and load it into each of the OSC.2.1.0 A1 Simulators instances. (policy_type_id = 1)
(Note the format for A1 Policy Type Definitions (JSON) differs for different A1-Interface profiles)

pt1.json

{
  "name": "pt1",
  "description": "pt1 policy type",
  "policy_type_id": 1,
  "create_schema": {
    "$schema": "http://json-schema.org/draft-07/schema#",
    "title": "OSC_Type1_1.0.0",
    "description": "Type 1 policy type",
    "type": "object",
    "properties": {
      "scope": {
        "type": "object",
        "properties": {
          "ueId": {
            "type": "string"
          },
          "qosId": {
            "type": "string"
          }
        },
        "additionalProperties": false,
        "required": [
          "ueId",
          "qosId"
        ]
      },
      "qosObjectives": {
        "type": "object",
        "properties": {
          "priorityLevel": {
            "type": "number"
          }
        },
        "additionalProperties": false,
        "required": [
          "priorityLevel"
        ]
      }
    },
    "additionalProperties": false,
    "required": [
      "scope", "qosObjectives"
    ]
  }
}

Insert the example policy type into the started OSC_2.1.0 A1 Simulator instances by running these curl commands (in this example to ric1 exposed to port localhost:8085 and ric2 exposed to port localhost:8086 as described above):

curl -X PUT -v "http://localhost:8085/a1-p/policytypes/1" -H "accept: application/json" -H "Content-Type: application/json" --data-binary @pt1.json
curl -X PUT -v "http://localhost:8086/a1-p/policytypes/1" -H "accept: application/json" -H "Content-Type: application/json" --data-binary @pt1.json

For the STD_2.0.0 simulators create a new A1 Policy Type policy type definition (JSON), and load it into each of the STD_2.0.0 A1 Simulators instances. (policy_type_id = "STD_QOS2_0.1.0")
(Note the format for A1 Policy Type Definitions (JSON) differs for different A1-Interface profiles)

std_qos2_0.0.1.json

{
    "policySchema": {
      "$schema": "http://json-schema.org/draft-07/schema#",
      "title": "STD_QOS2_0.1.0",
      "description": "STD QOS2 policy type",
      "type": "object",
      "properties": {
        "scope": {
          "type": "object",
          "properties": {
            "ueId": {
              "type": "string"
            },
            "qosId": {
              "type": "string"
            }
          },
          "additionalProperties": false,
          "required": [
            "ueId",
            "qosId"
          ]
        },
        "qosObjectives": {
          "type": "object",
          "properties": {
            "priorityLevel": {
              "type": "number"
            }
          },
          "additionalProperties": false,
          "required": [
            "priorityLevel"
          ]
        }
      }
    },
    "statusSchema": {
      "$schema": "http://json-schema.org/draft-07/schema#",
      "title": "STD_QOS_0.2.0",
      "description": "STD QOS policy type status",
      "type": "object",
      "properties": {
        "enforceStatus": {
          "type": "string"
        },
        "enforceReason": {
          "type": "string"
        },
        "additionalProperties": false,
        "required": [
          "enforceStatus"
        ]
      }
    }
  }

Insert the example policy type into the started STD_2.0.0 A1 Simulator instances by running these curl commands (in this example to ric3 exposed to port 8087 and ric4 exposed to port 8088):

curl -X PUT -v "http://localhost:8087/policytype?id=STD_QOS2_0.1.0" -H "accept: application/json" -H "Content-Type: application/json" --data-binary @std_qos2_0.0.1.json
curl -X PUT -v "http://localhost:8088/policytype?id=STD_QOS2_0.1.0" -H "accept: application/json" -H "Content-Type: application/json" --data-binary @std_qos2_0.0.1.json

For more details about running the OSC A1 Simulator see the related OSC NONRTRIC Wiki page (Release J) and OSC A1 Simulator Documentation (J Release)

Run ONAP A1 Policy Management Service Docker Container

Run A1 Policy Management Service docker container using the command below, after the A1-Controller and simulators have been fully started.
The configuration file (application_configuration.json described above) must be mounted as a volume into the container, so absolute path and name of the file must be substituted in the following command:
Docker: Run the A1 Policy Management Service
```
docker run -p 8081:8081 --network=nonrtric-docker-net --name=a1policymanagmentservice --volume **<Absolute path to application_configuration.json created above>**:/opt/app/policy-agent/data/application_configuration.json nexus3.onap.org:10002/onap/ccsdk-oran-a1policymanagementservice:2.0.0
```
Note: Version numbers used in this page may not be the most recent ... you should verify the latest version numbers for released pre-built components in the docker image repository (https://nexus3.onap.org)
Note: Make sure to give the full/absolute path to the configuration file. Docker will need this full path to find the file to mount it as a volume. Otherwise Docker will instead create an empty directory as the volume inside the container.
- This command starts the A1 Policy Management Service, using the configuration specified above, with its REST endpoint available at ports 8081
  Other docker containers using the same docker network ("nonrtric-docker-net") can address this container by name, and directly access its REST endpoints. i.e.:
  a1policymanagmentservice:8081
- Ports 8081 is also exposed outside the network , mapped to a local port on the host. i.e.:
  Port 8081 in a1policymanagmentservice container →localhost:8081

It may be useful to set the logging level to TRACE level, where you can verify the A1-Controller, A1-Simualtors and A1 Policy Management Service is fully up and running.

Optional: Enable TRACE level logging in A1 Policy Management Service

curl -i -X POST "http://localhost:8081/actuator/loggers/org.onap.ccsdk.oran.a1policymanagementservice" -H "Content-Type:application/json" -d {\"configuredLevel\":\"trace\"}
curl -i -X GET "http://localhost:8081/actuator/loggers/org.onap.ccsdk.oran.a1policymanagementservice"

Once the Policy Management Service is up and running, it establishes connections to all configured near-RT-RICs (ric1, ric2, ric3, ric4) via the A1 Controller.
If the a1policymanagmentservice container is configured to log at TRACE level, the following logs entries should appear indicating that connection to the configured near-RT-RICs has been established successfully (via A1 Controller if enabled).

docker logs a1policymanagmentservice  | grep "checked" 
	202x-03-16 14:15:03.805 DEBUG 1 --- [or-http-epoll-5] o.o.c.o.a.tasks.RicSupervision           : Ric: ric1 checked OK
	202x-03-16 14:15:03.816 DEBUG 1 --- [or-http-epoll-6] o.o.c.o.a.tasks.RicSupervision           : Ric: ric3 checked OK
	202x-03-16 14:15:03.835 DEBUG 1 --- [or-http-epoll-1] o.o.c.o.a.tasks.RicSupervision           : Ric: ric2 checked OK
	202x-03-16 14:15:03.851 DEBUG 1 --- [or-http-epoll-2] o.o.c.o.a.tasks.RicSupervision           : Ric: ric4 checked OK

A1 Policy Management Service Swagger API

For troubleshooting/verification purposes you can view/access the A1 Policy Management Service swagger API from url: http://localhost:8081/swagger-ui.html
Note: the hostname may be different depending on your environment, port 8081 is configured in the docker command above

Check A1-Policy types and Status of the simulated near-RT-RICs

Allow 1 minute for the A1-Policy Management Service to correctly synchronize with the simulated near-RT-RICs (e.g. automatically identify which A1-Policy Types are supported in the "ric").

A1-Policy Management Service - Check “rics”
docs.onap.org: (oslo): API: operation/getRics
```
curl localhost:8081/a1-policy/v2/rics
```
A1-Policy Management Service - Get A1-Policy Types
docs.onap.org: (oslo): API: operation/getPolicyTypes
```
curl localhost:8081/a1-policy/v2/policy-types
```

A1-Policy Management Service - Get A1-Policy Type details
docs.onap.org: (oslo): API: operation/getPolicyType

curl localhost:8081/a1-policy/v2/policy-types/1                 # For A1 Policy Type 1 described above
curl localhost:8081/a1-policy/v2/policy-types/STD_QOS2_0.1.0    # For A1 Policy Type “STD_QOS2_0.1.0” described above

Create some A1-Policy instances using CURL

The deployments above contains 4 near-RT-RICs ("ric1", "ric2", "ric3", "ric4"), accessible via the deployed A1-Policy Management Service.

A1-Policy Type “STD_QOS2_0.1.0” is supported in 2 simulators ("ric3", "ric4"), and A1-Policy Type 1 is supported in 2 simulators ("ric1", "ric2").

Sample A1-Policy Instance data that corresponds to A1-Policy Type “STD_QOS2_0.1.0” is shown below. This can be used to create a new A1-Policy instance on "ric3" or "ric4".

Instance#1: policy_data payload: Type: "STD_QOS2_0.1.0"

{
    "scope": {
        "ueId": "ue5000",
        "qosId": "qos5000"
    },
    "qosObjectives": {
        "priorityLevel": 5000
    }
}

The payload to create a new A1-Policy Instance (policy_id:"aa8feaa88d") of type “STD_QOS2_0.1.0” on "ric3" is shown below

Instance#1: instance_1.json (policy_id:aa8feaa88d)

{
    "ric_id": "ric3",
    "policy_id": "aa8feaa88d",
    "service_id": "myapp",
    "policytype_id": "STD_QOS2_0.1.0",
    "policy_data": {
        "scope": {
            "ueId": "ue5000",
            "qosId": "qos5000"
        },
        "qosObjectives": {
            "priorityLevel": 5000
        }
    }
}

docs.onap.org: (newdelhi): API: operation/putPolicy

curl -X PUT -v "http://localhost:8081/a1-p/policies" -H "accept: application/json" -H "Content-Type: application/json" --data-binary @instance_1.json
curl "http://localhost:8081/a1-p/policies"
      Result: 
       {"policy_ids":["aa8feaa88d"]}
curl "localhost:8081/a1-policy/v2/policies/aa8feaa88d944d919ef0e83f2172a5000"       
      Result: 
       {"ric_id":"ric3","policy_id":"aa8feaa88d","service_id":"controlpanel","policy_data":{"scope":{"ueId":"ue5000","qosId":"qos5000"},"qosObjectives":"priorityLevel":5000}},"status_notification_uri":null, "policytype_id":"STD_QOS2_0.1.0","transient":false}

Sample A1-Policy Instance data that corresponds to A1-Policy Type 1 is shown below. This can be used to create a new A1-Policy instance on "ric1" or "ric2".

Instance#2: policy_data payload: Type: 1

{
    "scope": {
        "ueId": "ue6000",
        "qosId": "qos6000"
    },
    "qosObjectives": {
        "priorityLevel": 6000
    }
}

The payload to create a new A1-Policy Instance (policy_id:"172a5100") of type “STD_QOS2_0.1.0” on "ric2" is shown below

Instance#2: instance_2.json (policy_id:"172a5100")

{
    "ric_id": "ric2",
    "policy_id": "172a5100",
    "service_id": "myapp",
    "policytype_id": "1",
    "policy_data": {
        "scope": {
            "ueId": "ue6000",
            "qosId": "qos6000"
        },
        "qosObjectives": {
            "priorityLevel": 6000
        }
    }
}

docs.onap.org: (oslo): API: operation/putPolicy

curl -X PUT -v "http://localhost:8081/a1-p/policies" -H "accept: application/json" -H "Content-Type: application/json" --data-binary @instance_2.json
curl "http://localhost:8081/a1-p/policies"
     Result: 
      {"policy_ids":["172a5000", "aa8feaa88d"]}
curl "localhost:8081/a1-policy/v2/policies/172a5000"
     Result: 
      {"ric_id":"ric2","policy_id":"172a5000","service_id":"myapp","policy_data":{"scope":{"ueId":"ue6000","qosId":"qos6000"},"qosObjectives":"priorityLevel":6000}},"status_notification_uri":null,"policytype_id":"1","transient":false}

Run OSC Non-RT RIC Control Panel Docker Container

The OSC Non-RT RIC Control Panel uses two docker images, one is the Control Panel API Gateway (backend) and the Non-RT RIC Control Panel (frontend).

In order to start the Control Panel API gateway, an configuration file is needed to specify the routes and paths accepted by the gateway and where those requests will be redirect to, so the following example can be used:

application-nonrtricgateway.yaml

server:
  port: 9090
spring:
  cloud:
    gateway:
      httpclient:
        ssl:
          useInsecureTrustManager: true
        wiretap: true
      httpserver:
        wiretap: true
      routes:
      - id: A1-Policy
        uri: http://a1policymanagmentservice:8081
        predicates:
        - Path=/a1-policy/**
management:
  endpoint:
    gateway:
      enabled: true
  endpoints:
    web:
      exposure:
        include: "gateway,loggers,logfile,health,info,metrics,threaddump,heapdump"
logging:
  level:
    ROOT: ERROR
    org.springframework: ERROR
    org.springframework.cloud.gateway: INFO
    reactor.netty: INFO
  file:
    name: /var/log/nonrtric-gateway/application.log

The configuration, application_nonrtricgateway.yaml must be mounted as a volume to the container.

Run docker container using this command:

It is important to provide absolute path of the application_nonrtricgateway.yaml file!

docker run -p 9090:9090 --network=nonrtric-docker-net --name=nonrtric-gateway --volume <Absolute path to application_nonrtricgateway.yaml created above>:/opt/app/nonrtric-gateway/config/application.yaml:ro nexus3.o-ran-sc.org:10002/o-ran-sc/nonrtric-gateway:1.2.0

Example:

docker run -p 9090:9090 --network=nonrtric-docker-net --name=nonrtric-gateway --volume /home/infra/workspace/application-nonrtricgateway.yaml:/opt/app/nonrtric-gateway/config/application.yaml:ro nexus3.o-ran-sc.org:10002/o-ran-sc/nonrtric-gateway:1.2.0

In order to run docker container for control panel use the following command:

docker run -p 8080:8080 --network=nonrtric-docker-net --name=nonrtric-control-panel nexus3.o-ran-sc.org:10002/o-ran-sc/nonrtric-controlpanel:2.5.0

Open NONRTRIC / A1 Policy Control Panel UI

The Control Panel UI can be accessed by pointing the web-browser to this URL: http://localhost:8080/ (or) http://<yourclusterloginip>:8080/
Note: the hostname may be different depending on your environment. The port number is defined using the docker command above.

Example:

For each managed "RIC" (A1-Simulator) should be visible in the Control Panel display, with each of the A1 Policy Types defined & loaded above.
(Note: A1 Policy Types can only be created or deleted directly in the near-RT-RIC (or simulators), which will then be synchronized in the A1 Policy Management Service, and can seen in the Control Panel display when refreshed.)
A1 Policy instances for those A1 Policy Types can now be created, updated and deleted in the managed "RIC".

For more examples of using the NONRTRIC Control panel see Oslo - Testing call to A1 Interface

Browser not supported