Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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)

Table of Contents

Project Requirements

  • Java 11 (make sure that JAVA_HOME environment variable points to correct Java version)

  • Maven 3.6 (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 (london) to the current directory, then replace/amend the configuration with the sample demo configuration 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 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 (in the name and baseUrl for each ric entry) must match the given docker container names in near-RT-RIC simulator startup - port is always the simulator's internal port 8085 for http or 8185 for https.

  • 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.

    Info
    titleAlternative: 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
    • 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.


Sample application configuration

Code Block
languageyml
titleSample: application_configuration.json
linenumberstrue
{
  "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"
         ]
      }
    ]
  }
}

...

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


Code Block
languageyml
titleSample Application Configuration - bypassing the A1-Controller
linenumberstrue
collapsetrue
{
  "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 (london))

...

For more information on configuring the A1-Policy Management Service please see Montreal - 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.

ComponentRelease image and version tagStaging images and version tagManual snapshot (only available if manually built)
and version tag
A1 Policy Management Service

nexus3.onap.org:10002/onap/ccsdk-oran-a1policymanagementservice:1.5.0

nexus3.onap.org:10004/onap/ccsdk-oran-a1policymanagementservice:1.5.1-STAGING-latest

onap/ccsdk-oran-a1policymanagementservice:1.5.1-SNAPSHOT

SDNC imagenexus3.onap.org:10002/onap/sdnc-image:2.5.5nexus3.onap.org:10004/onap/sdnc-image:2.5.5-STAGING-latestonap/sdnc-image:2.5.5-SNAPSHOT

Run A1-enabled Controller

Info
titleAlternative: 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.

...

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):

    Code Block
         (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.5.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.5.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.5.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.5.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 ..... )

  • 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.
    (Note the format for A1 Policy Type Definitions (JSON) differs for different A1-Interface profiles)

    Code Block
    languagejs
    titlept1.json
    collapsetrue
    {
      "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 8085 and ric2 exposed to port 8086):

      Code Block
      languagebash
      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.0A1 Simulators instances.
    (Note the format for A1 Policy Type Definitions (JSON) differs for different A1-Interface profiles)

    Code Block
    languagejs
    titlestd_qos2_0.0.1.json
    collapsetrue
    {
        "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):

      Code Block
      languagebash
      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 H) and OSC A1 Simulator Documentation (H 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.
    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.

    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:

    Code Block
    languagebash
    titleDocker: 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:1.5.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)

    Code Block
    languagebash
    titleOptional: Enable TRACE level logging in A1 Policy Management Service
    collapsetrue
    curl -X POST  http://localhost:8081/actuator/loggers/org.onap.ccsdk.oran.a1policymanagementservice -H "Content-Type:application/json" -d {\"configuredLevel\":\"trace\"}


  • 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 RICs has been established successfully via A1 Controller.

...

Code Block
languagebash
docker logs a1policymanagmentservice  | grep "checked" 
	2022-03-16 14:15:03.805 DEBUG 1 --- [or-http-epoll-5] o.o.c.o.a.tasks.RicSupervision           : Ric: ric1 checked OK
	2022-03-16 14:15:03.816 DEBUG 1 --- [or-http-epoll-6] o.o.c.o.a.tasks.RicSupervision           : Ric: ric3 checked OK
	2022-03-16 14:15:03.835 DEBUG 1 --- [or-http-epoll-1] o.o.c.o.a.tasks.RicSupervision           : Ric: ric2 checked OK
	2022-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

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).

...

Code Block
languagebash
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.

...

For more examples of using the NONRTRIC Control panel see Montreal - Testing end-to-end call (Copy)