Daily Note 20/07/2020

# Daily Note 20/07/2020 ###### tags: `Daily Notes` , `O-RAN` , `Acumos` ## Name : Christofel Rio Goenawan ## University : Bandung Institute of Technology (ITB) --- ## Schedule: 1. Study detailed works of Admission Control xApp. 2. Study detailed works of KPI Monitor xApps. 3. Company Meeting with Compal 4. Study detailed works of UE Measurement Campaign xApps. ## Outcome : 1. Explain the detailed works of Admission Control xApp. 2. Explain detailed works of KPI Monitor xApps. 3. Explain detailed works of Measurement Campaign xApps. ## Further Plan : - Study more detailed about current xApps - Study more detailed about AIO Installation in Kubernets - Try to deploy Acumos AIO in NTUST server --- ## Daily Log ### 1.Study detailed works of Admission Control xApp. (9.00) - Study more detail explanation in [Documentation](https://wiki.o-ran-sc.org/display/RICA/Admission+Control+xApp)and other resources. ### 2.Study detailed works of KPI Monitor xApps. (12.00) - Study more detail explanation in [Documentation](https://docs.o-ran-sc.org/projects/o-ran-sc-ric-app-kpimon/en/latest/overview.html). ### 3. Company Meeting with Compal (14.00) - ### 4. Study detailed works of UE Measurement Campaign xApps. (15.00) - Study more detail explanation in [Documentation](https://wiki.o-ran-sc.org/display/RICA/Measurement+Campaign+xApp) and other resources. --- ## Report ### 1. How Admission Control xApps works ? >In this note Writer use [Documentation](https://wiki.o-ran-sc.org/display/RICA/Admission+Control+xApp) as study sources. #### What is Admission Control xApps ? Admission Control xApps ( usually called AC xApps ) are xApps that responsible for task as below. 1. Subscription for **SgNBAdditionRequest** message in the gNB. 2. Executing logic to determine if a dual connection should be accepted or rejected and generating the RIC CONTROL message. 3. Update metrics: dual connections accepted/rejected. #### Functionality From refernce, control via **A1 interface** can be configure by following 4 parameters as below. - **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 adm-ctrl-xapp-schema.json :::info - 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 There are 3 ways to deploy AC xApps as below. 1. On the RIC, the Admission Control xAPP can be deployed using xApp Manager REST API interface. 2. Use ``appmgrcli`` command provided by xApp Manager: ```appmgrcli -h appmgr-service p 8080 deploy admin xapp``` 3. Use 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 **config-file.json**. The descrition can be seen as below. - 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. The schema of the descriptor is **schema.json**. --- ### 2. KPI MOnitor xApps > In this note Writer use [Documentation](https://docs.o-ran-sc.org/projects/o-ran-sc-ric-app-kpimon/en/latest/overview.html) as study sources. #### What is KPI MOnitor xApps ? KPI Monitor xApps are first step towards an xApp that collects **metrics** from CU and DU and stores them inside the RIC for other xApps to consume. #### Functionality - LTE eNB and 5G NR gNB produce data that can be monitored and analyzed to measure the system’s effectiveness. - The near Real-Time RIC can gather the radio and **system Key Performance Indicators (KPI)** from E2 Nodes and can utilize the metrics for closed-loop control. - The KPI includes but not limited as below. - UE measurement - E2 Node Measurement - E2 Node Load-related measurement. - The KPIMON xApp provides the first step towards the successful closed-loop control, through the monitoring E2 Node’s performance metrics, and writing it into Redis DB. - With the near real-time reporting KPIs, the near Real-Time RIC can immediately control E2 Nodes. #### System Limitations - The xAPP currently does not support A1 Interface, so policy updates is not implemented in the xAPP. All the GNB to be subscribed needs to be specified initially. - The xAPP currently only supports messages from CU. - The subscription request parameters (RAN Function ID etc) cannot be changed. :::info Writer don't find many source about KPI Monitor xApp in internet other than documenation. ::: --- ### 3. Measurement Campaign xApps > In this note Writer use [Documentation](https://wiki.o-ran-sc.org/display/RICA/Measurement+Campaign+xApp) as study sources. #### What is Measurement Campaign xApps ? Measurement Campaign xApps ( usually called MC xApps ) are xApps that calculates a number of metrics and KPIs based on X2 messages formatted as protobufs as defined in ``/ric-plt/streaming-protobufs``. In the MC xApp, we compute 5G KPIs at customized fine-grained granularities as below. - On a per-UE per-bearer basis - On a per-UE basis - On a UE-group basis - On an NR cell-wide basis - On an NR gNB-wide basis The key 3GPP EN-DC X2AP procedures that we handle in the MC xApp as below. - SgNB Addition - SgNB Release - SgNB Modification - RRC Transfer - Secondary RAT Data Usage Report #### Architectures From reference , the main components of MC xApps can be shown as below. 1. **mc-core/*** contains the source of core MC xApp container. - **+ mc-core/mc/queries/** contains a set of queries computing the output metrics and KPIs. - **+ mc-core/mc/data_gen/** contains a generator of X2 messages to run MC in standalone simulation mode without UEEC. 3. **sidecars/** contains the source code the RMR listener container responsible for listeting to UEEC messages and forwarding them to mc-core. 4. **docs/** contains the documentation. #### Functionality From the components above the functionality can be shown as below. - The metrics are reported periodically as VES events and include metrics such as number of dual connected UEs, duration of dual connections, and signal strength metrics. - Internally, MC xApp uses the **gs-lite stream processing engine** (com/gs-lite). - The protobufs are received as RMR messages from UEEC. - If no such data producer is available, MC xApp can be run in a simulated mode where the protobuf content is generated locally by the UEEC simulator running in the same container. --- ## Reference 1. https://wiki.o-ran-sc.org/display/RICA/Admission+Control+xApp 2. https://docs.o-ran-sc.org/projects/o-ran-sc-ric-app-kpimon/en/latest/overview.html 3. https://wiki.o-ran-sc.org/display/RICA/Measurement+Campaign+xApp