Admission Control xApp
This page will provide documentation of the AC xApp that is an example of an xApp that controls the execution of a gNB.
Additional documentation related to the Amber release version of the xApp can be found here.
Background
AC xApp is responsible for:
Subscription for SgNBAdditionRequest message in the gNB
Executing logic to determine if a dual connection should be accepted or rejected and generating the RIC CONTROL message
Update metrics: dual connections accepted/rejected
Control via A1 type (pre-standard) interface
The following 4 parameters can be set via the control interface
Parameter 1: enforce , type = Boolean, description = whether to apply admission control or not
Parameter 2: window length , type = number , description = range over which to measure request volume
Parameter 3: trigger threshold, type = number , description = threshold above which to trigger blocking
Parameter 4: Blocking rate , type = number, description = percentage of requests to reject
A policy sent to the Admission Control xAPP must be a JSON that conforms to the xAPP Policy Schema maintained by A1 Mediator. The Admission Control instance of the schema is
An example of received policy : { "enforce":true, "window_length":10, "blocking_rate":20, "trigger_threshold":10 }
Example of response from Admission Control xAPP on successful application of policy : { "status":"SUCCESS", "message":"Config applied" }
Deployment
On the RIC, the Admission Control xAPP can be deployed using xApp Manager REST API interface
Or, appmgrcli command provided by xApp Manager:
appmgrcli -h appmgr-service p 8080 deploy admin xapp
Or, curl-command:
curl -X POST http://appmgr-service:8080/ric/v1/xapps -d '{"name:" "admin xapp}'
The Admission Control xAPP provides a configuration json and schema in its helm chart, conforming to the template structure dictated by the xAPP Manager
The configuration descriptor is
The configuration descriptor describes the RMR messages that the xAPP expects to consume, send as well as a static route table for preliminary testing.
In addition, it exposes key configuration parameters under the 'env' block which can be used to configure behaviour of the xAPP. Notable 'env' parameters are :
GNODEBID : Specifies the gNodeB connection identifier (as defined by the E2 manager when setting up connection) to which to send subscription request
VES_COLLECTOR_URL : URL of VES collector to which the xapp sends metrics
VES_MEASUREMENT_INTERVAL : How often to post metrics
LOG_LEVEL : Log level to set for testing/production
TEST_MODE : If this key is defined (value does not matter), then the xAPP will send a subscription request, wait for VES_MEASUREMENT_INTERVAL and then send a subscription delete request. It will continue to process any E2AP indication messages independent of the subscription flow.
The schema of the descriptor is
The latest docker image for deployment is available at snapshot.docker.ranco-dev-tools.eastus.cloudapp.azure.com:10001/ric-app-admin:0.1.2
Helm Chart for deployment is stored in the Helm repo specified by Integration team. Linked here for convenience
Testing :
The admission control xAPP has 3 interfaces which can be tested :
A1- interface to get/set policies
VES interface to report metrics
E2 interface to interact with RAN. On this interface it currently supports
E2AP subscription request/delete messages
E2AP indication/control messages
A simple script can be run in the RIC K8 environment to report if the Admission Control xAPP has successfully received/posted messages for each of these interfaces.
Note : The script does not (currently) identify any RMR related routing issues.
Metrics
The Admission Control xAPP collects metrics related to dual connections accepted/rejected and reports them via VES protocol to VES Collector. The URL of the VES collector and the interval for posting metrics can be configured in the XAPP configuration descriptor during deployment. The metrics posted are a JSON body that conforms to
An example JSON of posted metric is