THE RAN AUTOMATION JOURNEY
Part 3 – Market vision meets reality
Written by Alejandro Medina, CTO
This is the final post in a three-part series about RAN automation and how the Open RAN RIC, powered by AI, will enable MNOs to realise the vision of a programmable, intelligent RAN that will be self-configuring, self-optimising and self-healing. The RIC has the potential to grow a global community of third-party rApp and xApp developers who will deliver innovative RAN automation solutions that MNOs need to improve service coverage, capacity, and quality – at scale – compared to existing networks.
This post examines the nature of RIC platform programming interfaces and the ramifications for rApp/xApp developers working on different RIC platforms operating in different vendor environments. Industry observers expect MNOs to eventually be able to source rApps and xApps from a “RIC App store”. You can read more about that here and here and here. The key takeaway? It gets messy when market vision meets reality.
Today more than a dozen companies offer Open RAN RIC platforms – either a Non-RT RIC for rApps and/or a Near-RT RIC for xApps – and there are many more companies developing rApps and xApps. Some of these players have experience with C-SON Apps and platforms, while others are new market entrants, enticed by the prospect of a more open, multi-vendor RAN ecosystem. This has the makings of a flourishing community of third-party rApp/xApp developers, but there’s a hitch.
The difficulty lies in the difference between the open interfaces defined in the O-RAN ALLIANCE specifications vs. the programming interfaces defined by RIC platform providers. To ensure multi-vendor interoperability, the former interfaces must be standard, while vendors are free to implement the latter as they see fit. Another complicating factor is that aspects of the O-RAN RIC specifications are not yet fully defined, so by necessity, vendors must fill the gaps with non-standard implementations.
Consider the case of a third-party developer with a differentiated, AI-driven approach for RAN automation that is a good fit for a broad segment of the MNO market. This developer will be delivering rApps and xApps on multiple RIC platforms provided by different vendors and running them in RAN environments with different vendor ecosystems. This means that they will have to be customised for each RIC platform and target environment to accommodate vendor-specific dependencies:
- RIC platforms may support different programming languages and different types of APIs, including different methods and functions for collecting RAN data.
- Processing RAN data is challenging for software developers. Common data types can be represented and encoded differently across different environments. Similarly, named data types might even have different semantics.
This type of rApp/xApp customisation is non-trivial, costly and time-consuming. Also, as the number of RIC platforms and vendor-specific dependencies in the underlying RAN infrastructure increase, developers will be increasingly burdened by updating rApps and xApps to keep current with any changes impacting the programming interface.
If the market develops along these lines, then a RIC App store would consist of multiple versions of the same rApps and xApps, each adapted for specific RIC platforms and customised for different RAN ecosystems. This would be sub-optimal for third-party developers and confusing for MNO customers. Another possibility is multiple vendor-dependent RIC App stores, each supporting a specific RIC platform and target vendor environment. This might be simpler for customers but not any better for third-party developers, who would still have to develop and maintain multiple versions of each rApp and xApp.
However, there is a better way.
What if third-party developers could write a single version of an rApp or xApp, which could then be installed on different RIC platforms and run without modification in different RAN environments? This would be possible via an efficient abstraction layer that shields programmers from the complexity of vendor-specific dependencies. This abstraction layer would support a single, common API decoupling rApps and xApps from vendor-specific RIC platform programming languages and APIs. It would also automatically normalise all RAN data, with a common method for representing and encoding data types, including RAN telemetry, KPIs and configuration parameters.
The widespread adoption of such an abstraction layer would give rise to a scenario in which a RIC App store would offer only one version of each third-party developer rApp or xApp, which would be readily portable across various operational environments. Developers would benefit from access to a larger market of target customers. MNOs would be free to select the rApps and xApps that best meet their requirements without having to navigate a complex maze of vendor dependencies.
What if we could take this abstraction layer concept one step further so it could also facilitate porting a C-SON App running on one vendor’s C-SON platform to an rApp running on a different vendor’s Non-RT RIC? Or vice versa?
Some RIC rApp/xApp developers have been developing C-SON Apps for years. High-value C-SON Apps are currently running in LTE networks that MNOs will also want to run as rApps in 5G environments. The converse is also true. New rApps developed for 5G will also be valuable for LTE networks.
RAN automation software developers face the same set of challenges in both C-SON and Open RAN RIC environments: different programming languages, APIs, data collection methods and vendor-specific data dependencies. Extending the abstraction layer to both environments would result in a different kind of RIC App store – one with highly portable RAN automation Apps capable of running – without modification – in both legacy C-SON and Open RAN RIC environments. Could this happen?
Stay tuned!
