xApp DevOps Evolution
This documentation aims to provide insights into the diverse perspectives and benefits associated with managing the lifecycles of xApp.
Introduction
In the O-RAN ecosystem, each network component, such as E2-Node, RIC, xApp, and rApp, follows its own independent DevOps lifecycle. The evolution from xApp to rApp is a significant milestone for Open RAN stack developers, network maintainers, vertical users, and business intelligence (e.g., data analysts). This evolution is facilitated by an independent xApp lifecycle, which serves as a crucial link between xApp and rApp.
Key perspectives covered by the independent xApp lifecycle include:
- Accelerating innovative xApp development
- Operating xApp dynamically through Service Management and Orchestration (SMO)
- Leading the way of xApp evolution in the O-RAN Ecosystem
- Bridging xApp and rApp seamlessly
- Enabling a smooth transition from RAN to data:
By emphasizing these aspects,
the independent xApp lifecycle plays a crucial role in enhancing the overall adaptability and collaboration within the O-RAN ecosystem.
This independent xApp lifecycle consists of four distinct stages,
each reflecting a different perspective as illustrated in the below figure.
Detailed explanations will be provided in the following section.
Diverse Perspectives of xApp
Binary xApp
- Overview: This category caters to developers from vendors, focusing on R&D activities. Mastery of NearRT-RIC APIs is essential, while SMO API knowledge is not required. Developers are tasked with creating new features and are expected to program in C/C++, Python, or Go. Additionally, they manage manual network configurations and static implementations.
- Code-Based DevOps pipeline: This phase includes planning, coding, building. testing, and optimizing stages.
- Examples:
Containerized xApp
- Overview: Designed for maintainers from operators, this category is utilized mainly for test and measurement purposes. It requires a moderate understanding of NearRT-RIC APIs and fundamental knowledge of SMO APIs. Essential activities involve interacting with the network, coding in Python or Go, automating network setup, and executing static deployments.
- Code-Based DevOps pipeline: This step involves identifying, collecting, processing, and storing data.
- Example:
Integrated xApp
- Overview: This is directed at end-users of xApp from application provider, predominantly for production use. It requires basic understanding of NearRT-RIC APIs and advanced knowledge of SMO APIs. The main responsibilities are to set up and enforce policies, using Python or Go for programming, and to manage automatic and dynamic network configurations and deployment processes.
- Data-Based Machine Learning Usage: This stage covers the data identification, collection, process and sotre.
- Examples:
rApp
- Overview: Designed for professionals in business intelligence and data analytics, rApps are used for analysis and optimization tasks. They do not require knowledge of NearRT-RIC APIs, but do necessitate expertise in SMO APIs. The aim is to establish network intention and create policies. Any programming language can be used, with a focus on automated network setups and adaptable deployments.
- Data-Based Machine Learning Usage: This phase is about exploring and extracting data, training models, and refining algorithms.
- Examples:
Prototype
The four stages are depicted within a network deployment, as illustrated in the below figure.
xApp Developer - Binary xApp
As an xApp developer capable of developing and debugging xApp.c on a local machine,
you can compile it into a binary program to test its functionalities within a deployed network.
For instance, xApp developers should adhere to the following steps:
- Modify
xApp.cto send a control message to a specific E2-Node with NodeB ID 50:
+ if (nodes.n[i].id.nb_id.nb_id == 50)
+ control_sm_xapp_api(&nodes.n[i].id, SM_RC_ID, &rc_ctrl);
- Compile the codes
make -j
- Update the xApp configuration
# Retrieve NearRT-RIC's IP from the cluster
cli extract port flexric.ric.massachusetts --port e42ap
# Update NearRT-RIC's IP in xApp.conf
vim xApp.conf
NearRT_RIC_IP = {flexric.ric.ip}
- Execute the xApp
./path/to/binary/xApp -c ./path/to/config/xApp.conf
xApp Maintainer - Containerized xApp
As an xApp maintainer capable of overseeing xApps deployed in the cloud via xApp.yaml,
you can use specific commands within the containerized xApp's terminal on your local machine
to manage how the xApp communicates with other network components for testing its functionalities within the deployed network.
Consider the case of an interactive xApp; maintainers are recommended to follow these steps:
- Deploy xApp by the following
xApp.yaml
apiVersion: athena.trirematics.io/v1
kind: Network
metadata:
name: massachusetts
namespace: trirematics
spec:
edge:
- name: ric
stack: 5g-sa
model: mosaic5g/flexric-large
- name: interactive-xapp
stack: 5g-sa
model: mosaic5g/interactive
profiles:
- mac-sm
- slice-sm
- kpm-sm
- database
- name: sdl
stack: 5g-sa
model: mosaic5g/xapps-sdl
- Access to the interactive xApp
cli cic interactive.interactive-xapp.massachusetts run --follow -- python-xapp
- Execute xApp based on the provided functions
# Initialize xApp
>>> xapp.init("/path/to/xapp/conf")
# Print the connected E2-Nodes to get the index
>>> xapp.print_e2_nodes()
# Subscribe KPM SM to the connected E2-Nodes by giving the index 0
>>> xapp.subscribe_sm(0,xapp.ServiceModel.KPM,xapp.SubTimeInterval.ms1000,xapp.ex_kpm_actions_gnb_du)
# Subscribe SLICE SM to the connected E2-Nodes by giving the index
>>> xapp.subscribe_sm(0,xapp.ServiceModel.SLICE,xapp.SubTimeInterval.ms100,0)
# Print the subscribed KPM states of E2-Node with index 0
>>> xapp.print_kpm_stats(0)
# Print the subscribed SLICE states of E2-Node with index 0
>>> xapp.print_slice_stat(0)
# Send slice control message to create slice in E2-Node with index 0
>>> xapp.send_slice_ctrl(0,xapp.SliceType.ADDMOD,xapp.ex_slice_conf_addmod_nvs_cap2)
# Send slice control message to associate UE's slice in E2-Node with index 0
>>> xapp.send_slice_ctrl(0,xapp.SliceType.ASSOC_UE,xapp.ex_slice_conf_assoc_ue)
# Finish xApp
>>> xapp.end()
xApp Vertical User - Integrated xApp
As vertical users of xApps, you have the ability to define network objectives using intent.yaml,
which facilitates the deployment of dynamic xApps in the cloud.
These dynamic xApps are configured by the NonRT-RIC based on your specified network goals.
To effectively deploy and utilize dynamic xApps, vertical users should adhere to the following guidelines:
- Write
intent.yamlto describe the desired measurement names for different network components
apiVersion: odin.trirematics.io/v1
kind: MonitoringJob
metadata:
name: intent
namespace: trirematics
spec:
tasks:
- networksMetricsMap:
boston.massachusetts:
- Physical Resource Utilization
- Data Volume
springfield.massachusetts:
- Physical Resource Utilization
- Data Volume
- Throughput
- Deploy xApp
cli install network intent.yaml
xApp Business Intelligence - rApp
As a business intelligence professional, you possess the capability to specify your preferred tasks for xApps through rApp.yaml,
a description that serves as a more abstract version of intent.yaml.
Upon receipt of rApp.yaml, the Operation and Maintenance (OAM) will deploy an rApp in the cloud.
This rApp communicates with the NonRT-RIC, which in turn deploys dynamic xApps to fulfill the specified tasks.
To illustrate, consider the deployment of a cell manager rApp; business intelligence personnel are recommended to follow these procedures:
- Write
rApp.yamlto describe the desired jobs
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: cell-manager-rapp
namespace: trirematics
rules:
- apiGroups:
- odin.trirematics.io
resources:
- monitoringjobs
- policyjobs
verbs:
- "*"
- Deploy rApp
cli install network rapp.yaml