In the first of this two-part blog, learn what “rApps” are and how you can develop them to bring your innovation to the mobile RAN.
Last week, VMware launched the VMware RIC SDK Partner Program to invite partners to develop rApps and xApps for the VMware RAN Intelligent Controller (RIC). To learn more about the program, please read the announcement.
Traditionally, the mobile radio access network (RAN) has been closed and proprietary, as a result of which competition among vendors is severely limited, and innovation is excruciatingly slow. However, that is now changing. Led by communications service providers (CSPs) around the world, the industry is rallying behind an open RAN architecture which seeks to disaggregate the RAN with the aim of diversifying the vendor supply chain, increasing competition and accelerating innovation.
A key component of the open RAN architecture is the RAN Intelligent Controller (RIC). The RIC makes the RAN software defined and programmable by third parties. Two flavors of the RIC – the Non-Real-Time RIC and the Near-Real-Time RIC – have been defined to provide 3rd-party developers with programmable access to the management plane and control plane of the RAN, respectively.
VMware is on a mission to make the RAN developer friendly. It aims to create an arena where developers can thrive, compete and innovate in helping CSPs automate, optimize and monetize their RAN. To that end, VMware Centralized RIC and VMware Distributed RIC, which are VMware’s commercial-grade offerings of the Non-RT RIC and the Near-RT RIC respectively, are now generally available. Now, through the VMware RIC SDK Partner Program, VMware is offering software development kits (SDKs) to partners to help them develop and operationalize what are known as “rApps” and “xApps”, applications that run with the Non-RT RIC and the Near-RT RIC respectively.
In the first of this two-part blog, we dive deeper into what rApps are and how you can develop rApps to bring your innovation to the RAN.
What are rApps?
The Non-Real-Time RIC offers a set of services to observe, analyze and optimize the RAN at time scales greater than one second. These services can be extended by what are known as rApps: self-contained applications that may be provided by third parties, that consume one or more Non-Real-Time RIC services and contain the intelligence to analyze and/or optimize the RAN.
rApps interact with their environment using what’s called the R1 Interface. R1 is being standardized by Working Group 2 in the O-RAN Alliance. The process is not yet complete, thus R1 is not yet fully mature. VMware Centralized RIC currently provides a pre-standard implementation of R1 that supports expected R1 use cases in open RAN while also enabling interaction with legacy RAN.
rApps operate by consuming contextual information from the RAN itself, other rApps, or external sources to analyze them (open loop) and/or construct changes in RAN policy or configuration that will optimize the RAN (closed loop). The changes could be applied either over the O-RAN A1 interface to set policy at the Near-RT RIC, or over the O-RAN O1 interface or via mediated access to “legacy” RAN Element Management Systems to change configuration of RAN nodes, e.g., CU or DU. Each rApp can have the role of producer of data, consumer of data, or both. For example, one rApp may consume traffic data and analyze it against a machine learning model to produce predictions about future traffic. Another rApp may consume those predictions to proactively optimize capacity and coverage by adjusting cell parameters.
Software Development Kit for rApp Developers
VMware provides a software development kit to assist in the development of rApps. It includes:
- Architecture Overview: Documentation describing how the VMware Centralized RIC is structured as a service-based cloud-native application consisting of a suite of interacting microservices, and the series of steps that an rApp takes to utilize those services.
- OpenAPI Specifications: Detailed documentation of the APIs used by the R1 services, with request and response examples. The OpenAPI specs may also be used to generate sample or stub client code in rApps under development.
- Kubernetes Custom Resource Definition: With VMware Centralized RIC 2.0, rApps are packaged and deployed as a custom resource. The custom resource definition (CRD) and a sample to be used as a starting point are included.
- Sample rApp and Library: rApps can be developed using any programming language. In the current release, VMware has provided a sample rApp in Python that demonstrates the several modes of R1 interaction by reading historical Performance Management data and reading and writing Configuration Management data. This rApp makes use of “rapplib”, a Python library for interacting with R1 services. Both can be used as starting points for new applications. A simple testing server that confirms an rApp can join an R1 environment is also included.
Hello World
An rApp is packaged as a Kubernetes pod with one or more replicas, using the CRD mentioned above. How an rApp is launched will depend on how the VMware Centralized RIC is deployed, but somewhere under the covers the YAML that describes the rApp will be applied to a namespace in a target Kubernetes cluster, and the process or processes that make up the rApp will begin. The following gives a general overview. For more details, please see the development kit.
Once launched, every rApp has a small number of required steps to get started. An rApp must be configured with the location of the Bootstrap Service. A request to that service will return the current location of the Service Registry at which the rApp registers itself, is authenticated, and discovers other necessary services.
{
"services": {
"service": {
"href": "http://dms.vmware-cric.svc.cluster.local:8088/dms/service/v0alpha1"
}
}
} After registration as a service, an rApp that is only consuming data needs to discover data-types that are available for consumption. If the data-types it needs exist, it can then proceed to create jobs as well as use direct methods for acquiring required data. For example, an rApp that wants to consume the pmhistory type will list the available types, get the details of the pmhistory type and submit a job to the Data Management Service (DMS). The following job sample asks for PM counter data for one counter, for all available cell ids, in a specific window of time.
{
"info_type_id": "pmhistory",
"job_owner": "owner56",
"job_result_uri": "http://some.domain.local/jobs",
"job_definition": {
"technology": "nr",
"start": 1654015290000,
"end": 1654016411000,
"counter_names": [
"RRC_ConnEstabSucc"
]
}
} The DMS is VMware Centralized RIC’s implementation of the R1 Data Management and Exposure (DME) service. When it receives a job, it will locate an appropriate producer of the type indicated by info_type_id and dispatch the job to that producer. In this case the producer is the PM History Service. When that service is ready to provide results, the consumer is notified via job_result_uri with the location from which to retrieve results.
We call this style of data retrieval the job-request model. There are other models already implemented in the VMware Centralized RIC, and more are likely to be added as the R1 standard evolves and matures.
Once an rApp has consumed some data it has a few options of what to do with it:
- Produce more data: an rApp can aggregate the acquired data, analyze and correlate it with other data, and produce new data to be consumed by other rApps.
- Update RAN Configuration: an rApp can suggest changes in configuration of RAN network elements, e.g., CU, CU-CP, CU-UP, DU, gNB, eNB. These changes are applied by the VMware Centralized RIC via mediated access to RAN Element Management Systems or, in the future, via the O-RAN O1-CM interface.
- Update RAN Policies: In the future when the VMware Centralized RIC supports A1-related services, an rApp will be able to suggest policies for groups of cells in the network. These policies will be passed on to the Near-Real-Time RICs that are responsible for managing those cells, over the O-RAN A1 interface.
- Publish metrics: All rApps in VMware Centralized RIC 2.0 are scraped for Prometheus metrics which can be consumed in a variety of ways, including presentation in the VMware RIC Management System (RMS), making them available to operators and external systems.
For access to the VMware Centralized RIC development kit, please reach out to your VMware contact and sign up for the VMware RIC SDK Partner Program. The development kit is an evolving product that will be improved by input from customers and partners. We welcome your questions, comments, and suggestions.
Stay tuned for the second part of this blog where we will dive deeper into what xApps are and how you can develop xApps to program the deeper layers of the RAN and take your innovation to the next level.
