In the Open RAN, one of the key aspects of Open RAN is going to be the fact that the intelligence in the RAN can now be supplied by a variety of vendors, as opposed to earlier generations and in the traditional RAN where all the RAN intelligence or most of the RAN intelligence was provided by the same single RAN vendor that is providing the rest of the infrastructure. In contrast to that, in Open RAN it is possible for multiple third parties to provide various RAN intelligence features.
The way the O-RAN Alliance is operationalizing this is by defining and standardizing a RAN intelligent controller which should be the platform for these third-party applications.
The RAN Intelligence Controller (RIC) would interface with the RAN, the radio access network on the southern side, and on the northbound, it’ll provide APIs for developers to build various RAN intelligence features as applications. So the RIC platform is essentially that layer that makes it possible for third-party applications, the third party developed RAN intelligence features to be inserted into an operational RAN without making the third parties worry about integrating directly with the RAN itself.
What is the RIC?
O-RAN ALLIANCE aims to realize such a vision by designing and operating a network while utilizing AI / ML, assuming “Open RAN” that allows a free combination of base station equipment provided by different vendors. At the center of the realization of this intelligent RAN is a function called “RIC (RAN Intelligent Controller)” defined by O-RAN ALLIANCE.
O-RAN ALLIANCE’s RAN architecture defines a function called RAN Intelligence Controller (RIC) RIC as a logical node for realizing intelligent network operations utilizing AI / ML. RIC plays the role of automatically optimizing parameter design and operation, and consists of two types, “Non-RT (Real-Time) RIC” and “Near-RT RIC”, which have different control cycles.
- RIC as a project of the ORAN software community has formally started in June 2019.
- The first formal release will be O-RAN SC’s “Amber” (end of November 2019) with requirements listed in “O-RAN SC Ver A SW Requirements.
So, what are these RAN intelligent features that app developers might want to build, what are the capabilities and what are the characteristics? the various ways of categorizing these applications, one way to categorize them would be in terms of their latency requirements.
What is the difference between Near-RT (xAPPs) and Non-RT (rAPPs)?
When we are talking about the difference, we can ask How fast do these applications need to run? Do they need to operate at time scales of milliseconds or tens of milliseconds or hundreds of milliseconds, anywhere under one second?
If yes, then these are what, these would be what is known as near-real-time applications or xApps, that is the O-RAN Alliance terms for near real-time applications. These would be xApps, xApps are those applications that need to execute at timescales of less than a second. Under the ORAN architecture, xAPP and near-RT RIC are the core of the computing framework. In addition to being responsible for millisecond-level calculations, it is also a window that actually communicates the results of operations.
But if it’s an application that only needs to execute at timescales of greater than a second, maybe 30 seconds, maybe minutes, maybe even hours, then it would be a non-real-time application. It would be a rApps. Non-RT RIC uses rAPPs to analyze various information and generate policies. The rApp and the non-RT RIC platform are connected by the R1 interface specified by O-RAN ALLIANCE.
Again, that is the O-RAN Alliance term for a non-real-time application that needs to execute only at timescales greater than a second. So timescale of execution is one way of categorizing these applications.
Examples of xAPPs and rAPPs
An application that would optimize the handovers in a network would be an example of a near real-time application or a xApps. What this application would do for example is when let’s say we are having a call and at the same time we are doing streaming video. There is an algorithm running in the network which decides when should this user be handed over from one cell tower to the next cell tower.
And this algorithm cannot run the order of minutes because then it might be too late to do the handovers. In the meantime, the user would’ve lost connectivity because it went out of coverage of the previous cell tower that it was connected to. So this algorithm needs to be running typically on the order of tens of milliseconds, most often under a hundred milliseconds. So this would be an example of a near real-time application.
As opposed to this, let’s say there’s an application that is setting the transmit power of a cell tower, for example, transmit power is not something that you would want to be changing every hundred milliseconds. That is something that you would change much slower. Typically on the order of hours, maybe on the order of minutes. So transmit power optimization would be an example of a non-real-time application or a rApp.
Conclusion
The RIC split into near-RT RIC and non-RT RIC. The former is responsible for handling the near-RT RRM/SON functions (on a timescale between >10 ms and <1 s), such as Mobility Management, IM, etc. The latter handles the high-level/orchestration functions and provides policies to near-RT RIC over the A1 interface.
Note that the real-time RRM is still there, embedded in O-DU (e.g., MAC scheduler). The scheduler can be controlled by near-RT RIC only via general policies. To summarize, there are three control loops, RT (<10 ms) handled by O-DU, near RT (>10 ms, <1 s) handled by near-RT RIC, and Non-RT (>1 s) handled by non-RT RIC. It is a hierarchical design, which allows for the separation of resource handling concerns. Near-RT RIC, being responsible for RAN control and optimization, incorporates RRM/SON algorithms (through xApps) and bases its operation on UE- and cell-specific metrics.