Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Overview |
---|
|
Pre requisite |
---|
# kubectl get pods -n ricplt # There should be ~16 pods running in the ricplt namespace. |
Step 1: Prep Tasks (Preparing for xApp on-boarding) |
---|
Each xApp is required to provide a "descriptor". The descriptor is used by the Near RT RIC xApp On-boarder to generate a Helm chart and other deployment related artifacts for the xapp. At this step we are preparing for API calls into the xApp On-Boarder by providing thee locations of the xApp descriptors. Run ... $ sudo -i |
Step 2: Onboard xApps |
---|
Now we invoke API calls into the xApp On-boarder, providing it the locations of the xApp descripters. Run: $ curl --location --request POST "http://$(hostname):32080/onboard/api/v1/onboard/download" --header 'Content-Type: application/json' --data-binary "@./onboard.ts.url |
Step 3: Deploy xApp |
---|
At this step, we deploy the xApps by invoking the xApp Manager's API. Note that the names of the xApp to be deployed must match with what the on-boarder has. Once receiving the deploy API call, the xApp Manager will make API call into Helm/Kubernetes to deploy the xApp's Helm chart. The Routing Manager is also involved if the xApp is to process RMR messages, – it will compote the routes and send out route updates. Run ... $ curl --location --request POST "http://$(hostname):32080/appmgr/ric/v1/xapps" --header 'Content-Type: application/json' --data-raw '{"xappName": "qp"}' |
Step 4: Populate the Database with test RAN data |
---|
This step is needed for the phase one of the Traffic Steering use case. In phase one, the RAN data is artificial and the data points need to be injected into RNIB database. After these artificial data points are injected, we should see the Traffic Steering xApp starting to process these data, using the default threshold of 0. Run ... $ git clone http://gerrit.o-ran-sc.org/r/ric-app/ts -b bronze |
Step 5: Create a Policy Type |
---|
Here we define a new policy type and call the A1 mediator to create such a policy type. Run ... $ cd ~/dep/ |
Step 6: List Policy Types |
---|
We now should see the newly created policy type when querying the A1 mediator. Run ... $ curl -X GET --header "Content-Type: application/json" --header "accept: application/json" http://$(hostname):32080/a1mediator/a1-p/policytypes |
Step 7: Create a Policy Instance |
---|
Policy type is merely a declaration. Now we create a policy instance, filling the properties with actual values. This is also carried out by the A1 mediator. A1 mediator will distribute the new policy instance to the Traffic Steering xApp. And then we should see that the TS xApp receives this policy instancee and its behavior of "filtering RAN data by threshold" changing to using the new threshold value. Run... $ POLICY_ID="tsapolicy145" |
Helpful Hints |
---|
Kubectl commads: kubectl get pods -n nampespace - gets a list of Pods running kubectl get logs -n namespace name_of_running_pod |
Complete these tasks to get started
Recent space activity
Recently Updated | ||||||||
---|---|---|---|---|---|---|---|---|
|
Space contributors
Contributors | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|