# Daily Note 16/07/2020 ###### tags: `Daily Notes` , `O-RAN` , `Acumos` ## Name : Christofel Rio Goenawan ## University : Bandung Institute of Technology (ITB) --- ## Schedule: 1. Study detailed works of xApp in Near- RT RIC 2. Study about open APIs for xApps 3. Study detailed Acumos AI Design and Process. ## Outcome : 1. Explain the detailed architectures and works of xApp in Near- RT RIC. 2. Explain detailed works open APIs for xApps. 3. Explain detailed Acumos AI Design and Process. ## Further Plan : - Study more detailed of Near- RT RIC interfaces - Study more detailed about AIO Installation in Kubernets - Try to deploy Acumos AIO in NTUST server --- ## Daily Log ### 1. Study detailed works of xApp in Near- RT RIC. <mark>(9.00)</mark> - Study more detail explanation in [Work Group's Notes](https://www.o-ran.org/specification-access) and other resources. ### 2. Study about open APIs for xApps.<mark>(10.00)</mark> - Study more detail explanation in [Work Group's Notes](https://www.o-ran.org/specification-access) and [Ferlinda's Notes](https://hackmd.io/@ferlinda/SkvEbeWRI). ### 3. Study detailed Acumos AI Design and Process. <mark>(12.00)</mark> - Study more detail explanation in [Zhui Sao's Paper](https://drive.google.com/file/d/1zKe5CBkIy35jH2PFl2hngqndKHMbpmjo/view?usp=sharing). --- ## Report ### 1. How xApp works in Near- RT RIC ? In this note Writer use [WG3 - The Near-real-time RIC and E2 Interface Workgroup](https://www.o-ran.org/specification-access) and [Ferlinda's Notes](https://hackmd.io/@ferlinda/SkvEbeWRI) as study sources. #### What xApp ? From reference , xApps is **an application designed to run on the Near-RT RIC, is also likely to consist of one or more microservices and at the point of on-boarding will identify which data it consumes and which data it provides**. The application is **independent** of the Near-RT RIC and may be provided by any third party. **E2** enables a direct association between the xApp and the RAN functionality. xApps consists of two main components as below. 1. **xApp Descriptor** 2. **xApp Image** #### xApp Descriptor xApp descriptor describes the packaging format of xApp image. Provides component as below. 1. **xApp management** services with necessary information for the LCM of xApps, such as deployment, deletion, upgrade etc. Includes the basic information of xApp for LCM, including name, version, provider, URL of xApp image, virtual resource requirements (e.g. CPU), etc. 2. **Extra parameters** related to the health management of the xApps, such as **auto scaling** when the load of xApp is too heavy and **auto healing** when xApp becomes unhealthy. 3. **FCAPS** and **control parameters** to xApps when xApp is launched. - Includes the FCAPS management specifications that specify the options of configuration, performance metrics collection, etc. for the xApp. - Includes the control specifications that specify the data types consumed and provided by the xApp for control capabilities (e.g. PM data that the xApp subscribes, the message type of control messages). #### xApp Image xApp image is **the software package that contains all the files needed to deploy an xApp**. An xApp can have multiple versions of xApp image, which are tagged by the xApp image version number. --- ### 2. Open APIs for xApps > In this note Writer use [WG3 - The Near-real-time RIC and E2 Interface Workgroup](https://www.o-ran.org/specification-access) as study sources. #### General Architectures General Architectures of Open APIs for xApps can be shown as below. ![](https://i.imgur.com/FlafS6K.png) #### Detailed Functionality From Ferlinda's Notes, the detailed functionality can be seen as below. 1. **A1 related APIs**: the APIs between xApps and A1 Termination. - Provide value added services based on the policies or enrichment information or both which are transferred through A1 interface by non-RT RIC. - Enable the exchange of information between xApps and A1 termination, which includes: - **Policy Enforcement API**: used for policy enforcement request/response. - **Enrichment Information API**: used for enrichment information transfer/response. 2. **E2 related APIs**: the APIs between xApps and E2 Termination. 3. **Management APIs**: the APIs between xApps and management related functions, such as O1 termination, management services and logging, tracing, metrics collection. - **xApp life-cycle management** related APIs include the following functions: - ML Model Deployment Request. - ML Model Update Request. - ML Model Uninstall Request. - **FCAPS related APIs** include the following functions: - Configuration API: The xApp is configured by SMO via O1 interface. The API transfers the configurations from SMO to xApp. - PM API: xApps provide PM related data to O1 PM Consumer via PM API. - FM API xApps provide faults and events information to O1 FM Consumer via FM API. 4. **Control APIs**: the APIs between xApps and the functions which are responsible for control, such as conflict mitigation, xApp subscription management, etc. 5. **SDL APIs**: the APIs between xApps and Shared Data Layer. - Provide a simple yet flexible way to store and retrieve data while hiding details such as type and location of database, management operations of database layer such as high availability, scaling, load-balancing. - Allow multiple xApps to access the data independently of each other. - Includes: - Register API: xApps can register at SDL for the permissions to access the database. - Deregister API: xApps can request to delete the API which has been registered in SDL. - Modify API: It allows to modify or delete data from the database. - Fetch API: It allows the xApps to fetch data from the database. - Store API: It allows the xApps to store data in the database. - Notification API: The database can notify the xApps the update information on the database via the notification API. The database will ignore the notification to the xApp when update occurs if the notification API is not registered by the xApp. --- ### 3. Design and Process in Acumos AI > In this note Writer use [Zhui Sao's Paper](https://drive.google.com/file/d/1zKe5CBkIy35jH2PFl2hngqndKHMbpmjo/view?usp=sharing) as study sources. #### Acumos AI Ecosystems There are 3 main stakeholders in Acumos AI ecosystems as below. 1. **Acumos Platform** 2. **Contributor** 3. **End User** The simple scheme of Acumos AI Process can be shown as below. ![](https://i.imgur.com/NJWOBk5.png) The Acumos Platform maintains the platform and enforces standards of sharing models. :::info **A contributor can also be an end user** and the platform can also be used **to house models and microservices for your own use**, as well as to share them with others. ::: #### Acumos AI Processes There are three main processess in Acumos AI as below. 1. ***Uploading***: This starts with a contributor (i.e., modeler, data scientist) uploads a pre-trained local model onto Acumos. A contributor is able to use a variety of existing ML libraries to build and train his/her ML model. The flexibilty to use the language and ML toolkit of choice is beneficial, because data scientists are often reluctant to change their preferred ML environment . 2. ***Publishing***: Once uploaded, the models are stored in a private area, where only the contributor can access them. Then the contributor can choose when and how to share his/her model. Since the model is encapsulated and exists as something of a ”black box”, the contributor is required to describe the model’s metadata when publishing, such as the function description, input and output format and model category. Other users can search the models based on the metadata and find the suitable ones. 3. ***Predicting***: The Acumos platform will pack the uploaded model as a **microservice** in a Docker image, which is ready to be deployed and perform its function (prediction, classification, etc.). Consumers can download and directly deploy the Dockerized service to the cloud or to any local hardware that supports Docker. Once deployed, users can send input to this running microservice and receive the its output via a RESTful API. --- ## Reference 1. https://www.zdnet.com/article/what-is-v2x-communication-creating-connectivity-for-the-autonomous-car-era/ 2. https://drive.google.com/file/d/1zKe5CBkIy35jH2PFl2hngqndKHMbpmjo/view?usp=sharing