O-RAN alliance rApps and xApps typology

 An extract from the Open RAN RIC and Apps report and workshop.

1.    O-RAN defined rApps and xApps

1.1.        Traffic steering rApp and xApp

Traditional RAN provides few mechanisms to load balance and force traffic on specific radio paths. Most deployments see overlaps of coverage between different cells in the same spectrum, as well as other spectrum layered in, allowing performance, coverage, density and latency scenarios to coexist. The methods by which a UE is connected to a specific cell and a specific channel are mostly static, based on location of the UE, signal strength, service profile and the parameters to handover a connection from one cell to another, or within the same cell from one bearer to another or from one sector to another. The implementation is vendor specific and statically configured.

Figure 9: Overlapping cells and traffic steering

Non-RT RIC and rApps offer the possibility to change these handover and assignments programmatically and dynamically, taking advantage of policies that can be varied (power optimization, quality optimization, performance or coverage optimization…) and that can change over time. Additionally, the use of AI/ML technology can provide predictive input capability for the selection or creation of policies allowing a preferable outcome.

The traffic steering rApp is a means to design and select traffic profile policies and to dynamically allow the operator to instantiate these policies, either per cell, per sector, per bearer or even per UE or per type of service. The SMO or the Non-RT RIC collect RAN data on traffic, bearer, cell, load, etc. from the E2 nodes and instruct the Near-RT RIC to enforce a set of policies through the established parameters.

1.2.       QoE rApp and xApp

This rApp is assuming that specific services such as AR/VR will require different QoE parameters that will need to be adapted in a semi dynamic fashion. It proposes the use of AI/ML for prediction of traffic load and QoE conditions to optimize the traffic profiles.

UE and network performance data transit from the RAN to the SMO layer over the O1 interface, QoE AI/ML models are trained, process the data and infer the state and predict its evolution over time, the rApp transmits QoE policy directives to the Near-RT RIC via the Non-RT RIC.

1.3.       QoS based resource optimization rApp and xApp

QoS based resource optimization rApp is an implementation of network slicing optimization for the RAN. Specifically, it enables the Non-RT RIC to guide the Near-RT RIC in the allocation of Physical Resource Blocks to a specific slice or sub slice, should the Slice Level Specification not be satisfied by the static slice provisioning.

1.4.       Context-based dynamic handover management for V2X rApp and xApp

Since mobile networks have been designed for mobile but relatively low velocity users, the provision of high speed, reliable mobile service along highways requires specific designs and configurations. As vehicles become increasingly connected to the mobile network and might rely on network infrastructure for a variety of uses, Vehicle to infrastructure (V2X) use cases are starting to appear primarily as research and science projects. In this case, the App is supposed to use AI/ML models to predict whether a UE is part of a V2X category and its trajectory in order to facilitate cell handover along its path.

1.5.       RAN Slice Assurance rApp and xApp

3GPP has defined the concept of creating a connectivity product with specific attributes (throughput, reliability, latency, energy consumption) applicable to specific devices, geographies, enterprises… as slices. In an O-RAN context, the Non-RT RIC and Near-RT RIC can provide optimization strategies for network slicing. In both cases, the elements can monitor the performance of the slice and perform large or small interval adjustments to stay close the slice’s Service Level Agreement (SLA) targets.

Generally speaking, these apps facilitate the allocation of resource according to slice requirements and their dynamic optimization over time.

1.6.       Network Slice Instance Resource Optimization rApp

The NSSI rApp aims to use AI/ML to model traffic patterns of a cell through historical data analysis. The model is then used to predict network load and conditions for specific slices and to dynamically and proactively adjust resource allocation per slice.

1.7.       Massive MIMO Optimization rApps and xApps

Massive MIMO (mMIMO) is a key technology to increase performance in 5G. It uses complex algorithms to create signal beams which minimize signal interference and provide narrow transmission channels. This technology, called beamforming can be configured to provide variations in the vertical and horizontal axis, azimuth and elevation resulting in beams of different shapes and performance profiles. Beamforming and massive MIMO are a characteristic of the Radio Unit, where the DU provides the necessary data for the configuration and direction of the beams.

In many cases, when separate cells overlap a given geography, for coverage or density with either multiple macro cells or macro and small cells mix, the mMIMO beams are usually configured statically, manually based on the cell situation. As traffic patterns, urban environment and interference / reflection, change, it is not rare that the configured beams lose efficiency over time.

In this instance, the rApp collects statistical and measurement data of the RAN to inform a predictive model of traffic patterns. This model, in turn informs a grid of beams that can be applied to a given situation. This grid of beams is transmitted to the DU through the Near-RT RIC and a corresponding xApp, responsible for assigning the specific PRB and beam parameters to the RU. A variant of this implementation does not require grid of beams or AI/ML, bit a list of statically configured beams that can be selected based on specific threshold or RAN measurements.

Additional apps leveraging unique MIMO features such as downlink transmit power, Multiple User MIMO and Single User MIMO allow, by reading UE performance to adjust the transmit power or the beam parameters to improve the user experience or the overall spectral efficiency.

1.8.       Network energy saving rApps and xApps

These apps are a collection of methods to optimize power consumption in the open RAN domain.

    Carrier and cell switch off/on rApp:

A simple mechanism to identify within a cell the capacity needed and whether it is possible to reduce the power consumption by switching off frequency layers (carriers) or the entire cell, should sufficient coverage / capacity exist with other adjoining overlapping cells. AI/ML model on the Non- RT RIC might assist in the selection and decision, as well as provide a predictive model. The prediction in this case is key, as one cannot simply switch off a carrier or a cell without gracefully hand over its traffic to an adjoining carrier or cell before to reduce quality of experience negative impact.

    RF Channel reconfiguration rApp:

mMIMO is achieved by the combination of radiating elements to form the beams. A mMIMO antenna array 64 64 transceivers and receivers (64T64R) can be configured to reduce its configuration to 32, 16 or 8 T/R for instance, resulting in a linear power reduction. An AI/ML model can be used to determine the optimal antenna configuration based on immediate and predictive traffic patterns.

Why was virtualized RAN started?

 

Traditional RAN equipment vendors have developed and deployed RAN solutions in every band, in every generation, for any network configuration. This doesn’t happen without an extremely well industrialized process, with rigid interfaces and change management. This cumulative intellectual property, together with the capacity to deploy in a few months a new generation of network is what operators have been valuing until now.

The creation of a new Radio platform is a large investment, in the range of tens of millions, with a development timeframe extending from 18 to 30 months. Because it is a complex solution, underpinned with large hardware dependencies, it requires very good planning and development management only available to highly industrialized companies. The development of subsequent radios on the same platform might take less time and costs, but essentially the economics remain the same, you need at least 10,000 units of firm order, for a radio to be economically viable.

It is expensive because it works. As long as you don’t mind being essentially dependent of your vendor for all professional services associated with their product, they can guarantee it will work. This part is key, because taking sole responsibility for deployment, operation and maintenance of a radio system is a huge undertaking. Essentially, the traditional vendors are selling together with equipment and services an insurance policy in the form of onerous Service Level Agreements (SLA), willing to undertake penalties and damages in case of failure.

Unfortunately, most network operators find themselves in a situation where, with the reduction of their Average Revenue per User (ARPU) combined with the perpetual traffic growth and appetite for video streaming, they see their costs steadily increase and their margins compressed. Connectivity seems increasingly like a commodity from a customer standpoint, with easy availability and low friction to change provider, whereas it comes at an increasing cost for its operators.

Changing the cost structure of buying capacity is a must for all networks operators to survive, and it touches all aspects of their network.

Fortunately, there are a few markets that have seen similar needs in the past and solutions have emerged. Particularly, the internet giants, video streaming services and social networks, have had to face explosive growth of traffic, with essentially flat pricing or advertising-based revenue models which forced them to reimagine how to scale their network capacity.

From there have emerged technologies such as network virtualization, Software Defined Networking (SDN) and their higher levels of abstraction leading to the cloud computing market as we know it.

Applying these methods and technologies to the RAN market seemed like a sensible and effective way to change its cost structure.

What RICs and Apps developers need to succeed

 

We spoke a bit about my perspective on the Non and Near-Real Time RIC likely trajectories and what value rApps and xApps have for operators and the industry. As I conclude the production of my report and workshop on Open RAN RICs and Apps, after many discussions with the leaders in that field, I have come with a few conclusions.

There are many parameters for a company to be successful in telecoms, and in the RIC and Apps area, there are at least three key skill sets that are necessary to make it.

Artificial Intelligence is a popular term many in the industry use as a shorthand for their excel macros linear projection and forecast mastery. Data literacy is crucial here, as big data / machine learning / deep learning / artificial intelligence terms are bandied around for marketing purposes. I am not an expert in the matter, but I have a strong feeling that the use cases for algorithmic fall into a few categories. I will try to expose them in my terms, apologies in advance to the specialists as the explanation will be basic and profane.

• Anomaly / pattern detection provide a useful alarming system if the system's behavior has a sufficiently long time series and the variance is somewhat reduced or predictable. This does not require more than data knowledge, it is a math problem.
• Optimization / correction should allow, provided the anomaly / pattern detection is accurate to pinpoint specific actions that would allow a specific outcome. This where RAN knowledge is necessary. It is crucial to be able to identify from the inputs whether the output is accurate and to which element it corresponds. Again, a long time series of corrections / optimizations and their impact / deviation is necessary for the model to be efficient.
• Prediction / automation is the trickiest part. Ideally, given enough knowledge of the system's patterns, variances and deviations, one can predict with some accuracy its behavior over time in steady state and when anomalies occur and take a preemptive /corrective action. Drawn to its logical conclusion, full automation and autonomy would be possible. This is where most companies overpromise in my mind. The system here is a network. Not only is it vast and composed of millions of elements (after all that is just a computing issue), it is also always changing. Which means that there no steady state and that the time series is a collection of dynamically changing patterns. Achieving full automation under these conditions seems impossible. Therefore, it is necessary to reframe expectations, especially in a multi vendor environment and to settle for pockets of automation, with AI/ML augmented limited automation.

Platform and developer ecosystem management is also extremely important in the RIC and Apps segment if one wants to deploy multi vendor solutions. The dream of being able to instantiate Apps from different vendors and orchestrate them harmoniously is impossible without a rich platform, with many platform services attributes (lifecycle management, APIs, SDK, Data / messaging bus, orchestration...). This does not necessarily require much RAN knowledge and this why we are seeing many new entrants in this field.

The last, but foremost, in my mind, is the RAN knowledge. The companies developing RAN Intelligent Controllers and apps need to have deep understanding of the RAN, its workings and evolution. Deep knowledge may probably not necessary for the most pedestrian use cases around observability and representation of the health and performance of the system or the network, but any App that would expect a retro feedback and to send instruction to the lower elements of the architecture needs understanding of not only of the interfaces, protocols and elements but also their function, interworking and capabilities. If the concept of RICs and Apps is to be successful, several Apps will need to be able to run simultaneously and ideally from different vendors. Understanding the real-life consequences of an energy efficiency App and its impact on quality of service, quality of experience, signaling is key in absolute. It becomes even more crucial to understand how Apps can coexist and simultaneously, or by priority implement power efficiency, spectrum optimization and handover optimization for instance. The intricacies of beamforming, beam weight, beam steering in mMIMO systems, together with carrier aggregation and dynamic spectrum sharing mandate a near / real time control capability. The balance is delicate and it is unlikely that scheduler priorities could conceivably be affected by an rApp that has little understanding of these problematics. You don't drive a formula one car while messing about the gear settings.

If you want to know how I rank the market leaders in each of these categories, including Accelleran, Aira technologies, Airhop, Airspan, Capgemini, Cohere technologies, Ericsson, I-S Wireless, Fujitsu, Juniper, Mavenir, Nokia, Northeastern University, NTT DOCOMO, Parallel Wireless, Radisys, Rakuten, Rimedo Labs, Samsung, VIAVI, vmware and others, you'll have to read my report or register for my workshop.

The 5G letdown

 I have often written about what I think are the necessary steps for network operators to grow and prosper in our digital world. Covid, the changes in work modes, the hiring gluttony of the GAFAs, the geopolitical situation, between the banning of untrusted vendors and the consequences of a European conflicts have created quite a different situation today. 

Twitter or X reorganization and mass layoffs signaled the tech industry that it was ok to look for productivity and profitability and that over-hiring without a clear mission or reorienting companies entire strategies on far fetched, unproven concepts (web3, metaverse, crypto...) had very costly consequences. Fast forward to this summer of 2023, most GAFAs have been refocusing their efforts into their core business, with less intent on changing the telecoms landscape. This lull has allowed many network operators to post healthy growth and profits, while simultaneously laying off / fast tracking early retirement for some of their least adequately skilled personnel.

I think that a lot of these positive telco results are conjunctural, rather than structural and one crucial issue remains for operators (and their suppliers). 5G is a bust. So far.

The consumer market is not really looking for more speed at this time. The main selling proposition of 5G seems to have a 5G logo on your phone. I have 4G and 5G phones and I can't really tell the difference from a network user experience standpoint. 

No real 5G use case has emerged to justify the hype, and all in all, consumers are more likely to fork out 1000s of $ for a new device, rather than an additional 10 per month for a "better" connectivity. Especially since, us, telco literati know that 5G Non Stand Alone, is not really 5G, more like a 4G +. Until 5G Stand Alone emerges dominantly, the promises of 5G wont be fulfilled.  

The promise and business case of 5G was supposed to revolve around new connectivity services. Until now, essentially, whether you have a smartphone, a tablet, a laptop, a connected car, an industrial robot and whether you are a working from home or road warrior professional, all connectivity products are really the same. The only variable are the price and coverage.

5G was supposed to offer connectivity products that could be adapted to different device types, verticals and industries, geographies, vehicles, drones,... The 5G business case hinges on enterprises, verticals and government adoption and willingness to pay for enhanced connectivity services. By and large, this hasn't happened yet. There are several reasons for this, the main one being that to enable these, a network overall is necessary.

First, a service-based architecture is necessary, comprising 5G Stand Alone, Telco cloud and Multi-Access Edge Computing (MEC), Service Management and Orchestration are necessary. Then, cloud-native RAN, either cloud RAN or Open RAN (but particularly the RAN Intelligent Controllers - RICs)  would be useful. All this "plumbing" to enable end to end slicing, which in turn will create the capabilities to serve distinct and configurable connectivity products.

But that's not all... A second issue is that although it is accepted wisdom that slicing will create connectivity products that enterprises and governments will be ready to pay for, there is little evidence of it today. One of the key differentiators of the "real" 5G and slicing will be deterministic speed and latency. While most actors of the market are ready to recognize that in principle a controllable latency would be valuable, no one really knows the incremental value of going from variable best effort to deterministic 100, 10 or 5 millisecond latency.

The last hurdle, is the realization by network operators that Mercedes, Wallmart, 3M, Airbus... have a better understanding of their connectivity needs than any carrier and that they have skilled people able to design networks and connectivity services in WAN, cloud, private and cellular networks. All they need is access and a platform with APIs. A means to discover, reserve, design connectivity services on the operator's network will be necessary and the successful operators will understand that their network skillset might be useful for consumers and small / medium enterprises, but less so for large verticals, government and companies.

My Telco Cloud + Edge Computing and Open RAN workshops examine the technologies, use cases, implementations, strategies, operators and vendors who underlie the key growth factors for telco operators' and vendors' success in the "real" 5G.

Open RAN technical priorities release 3

The Open RAN technical priorities release 3, was published in March 2023 by Deutsche Telekom, Orange, Telefonica, TIM and Vodafone as part of the Open RAN MoU group at the Telecom Infra Project.

A review of the mandatory, highest priority unanimous requirements shed lights on what the big 5 operators consider essential for vendors to focus on this year, and more importantly highlights how much efforts are still necessary by the industry to meet markets expectations.

Scenarios

In this section, the big 5 regard virtualized DU and CU with open Front Haul on site as a must, for Macro and indoor / outdoor small cell deployments. This indicates that 7.2.x remains the interface of choice, despite recent attempts by other vendors to change its implementation. It also shows that as a first step, at least, they are looking at deploying Open RAN in the conventional fashion, replacing traditional e/g Node  B with like-for-like O-RU, DU. CU on site. The benefits of resource pooling due to disaggregation and virtualization, enabling either CU or CU and DU to be centralized is the highest priority by the majority of operators, but not all yet. Network sharing of O-RU and vDU/CU is also a highest priority for the majority of operators.

Security

The security requirements have increased dramatically in this latest version, with the vast majority of the requirements (166 out of 180) considered highest priority by al the MoU operators. This evolution marks the effort that have been dedicated to the topic over the last 24 months. Open RAN has been openly criticized and accused of lax security and the O-RAN alliance has dedicated a working group to assess and shore up criticism in that space. My assessment is that most of the security concerns of Open RAN are either linked to virtualization / O-Cloud implementation or just mechanically a result of having more open interfaces, providing more attack surfaces. Open RAN is not inherently more or less secure than 3GPP implementation and the level of security by design necessary to satisfy the criticisms we have seen in the media is not today implemented by traditional RAN vendors either. Having said that, the requirements now spell out exhaustively the level of admission control, authentication, encryption, certification necessary for each interface, for each infrastructure block and for their implementation in a cloud native containerized environment.

O-Cloud Infrastructure (CaaS)

The O-Cloud requirements are focused on ensuring a cloud-native architecture, while allowing acceleration hardware whenever necessary. As a result, the accent is put on bare metal or IaaS implementations of Kubernetes, with FPGA, eAsic, GPU acceleration support and management. The second theme that is prevalent in O-Cloud unanimous high priority requirements is the lifecycle management features which indicate a transition from the lab to more mature commercial implementations going forward.

CU and DU requirements

First and foremost the big 5 unanimously are looking at virtualized and containerized implementations of O-CU/O-DU with both look-aside and inline acceleration (this is contradictory, but I assume either one is acceptable). The next requirements are the usual availability, scalability, and performance related requirements we find in generic legacy RAN systems. All O-RAN interfaces support are mandatory.

Interestingly, power consumption targets are now spelled out per scenario.

RU requirements

The Radio Units requirements area good illustration of the difficulty to create a commercially viable Open RAN solution at scale. While all operators claim highest urgent priority for a variety of Radio Units with different form factors (2T2R, 2T4R, 4T4R, 8T8R, 32T32R, 64T64R) in a variety of bands (B1, B3, B7, B8, B20, B28B, B32B/B75B, B40, B78...) and with multi band requirements (B28B+B20+B8, B3+B1, B3+B1+B7), there is no unanimity on ANY of these. This leads vendors trying to find which configurations could satisfy enough volume to make the investments profitable in a quandary. There are hidden dependencies that are not spelled out in the requirements and this is where we see the limits of the TIP exercise. Operators cannot really at this stage select 2 or 3 new RU vendors for an open RAN deployment, which means that, in principle, they need vendors to support most, if not all of the bands and configurations they need to deploy in their respective network. Since each network is different, it is extremely difficult for a vendor to define the minimum product line up that is necessary to satisfy most of the demand. As a result, the projections for volume are low, which makes the vendors only focus on the most popular configurations. While everyone needs 4T4R or 32T32R in n78 band, having 5 vendor providing options for these configurations, with none delivering B40 or B32/B75 makes it impossible for operators to select a single vendor and for vendors to aggregate sufficient volume to create a profitable business case for open RAN.

The other RU related requirements helpfully spell out the power consumption, volume and weight targets for each type of configuration.

Open Front Haul requirements

There are no changes in the release 3, which shows the maturity of the interface implementation.

RAN features

The RAN features of the highest priority unanimously required by the big 5 operators remain mostly unchanged and emphasize the need for multi connectivity. Dual connectivity between 4G and 5G is essential for any western european operator to contemplate mass deployment of open RAN or replacement of their Chinese RAN vendor. The complexity does not stop to the support of the connectivity, but also necessitate advanced features such as Dynamic Spectrum Sharing (DSS) and Carrier Aggregation (CA) which is a complexity multiplier when associated with the RU band support requirements. These advanced features are probably some of the highest barriers to entry for new vendors in the space, as they have been developed for years by traditional vendors and require a high level of technological maturity and industrialization.

Near-RT RIC

The requirements for the Near-Real Time RAN Intelligent Controller are extremely ambitious. While they technically would enable better control of a multi-vendor RAN operation, they are unlikely to succeed in the short to medium term, in my opinion, as per previous analysis.

SMO and Non-RT RIC

The requirements for Service Management and Orchestration and Non-Real Time RIC are fairly mature and provide a useful framework for RAN domain automation and lifecycle management. The accent in this release is put on AI/ML support and management, which shows that the operators have been seduced by the promises of the technology, allowing a zero touch, automated, network, relying on historical analysis and predictive algorithms. The requirements are fairly high level, suggesting that the operators themselves might not have yet very clear targets in terms of algorithmics policy, performance and management.

In conclusion, this document provides useful data on Open RAN maturity and priorities. While the release 3 shows great progress in many aspects, it still fails to provide sufficient unanimous guidance from a commercial standpoint on the minimum set of end to end capabilities a vendor could reasonably develop to be selected for deployment at scale in these western european networks.

Near real time RIC and xApps market considerations

An extract from my upcoming report "Open RAN RIC and Apps 2023"   

As mentioned, near real time RIC and xApps capabilities are today embedded in gNodeB and RU/CU/DU code. The constraints of developing applications that have an actual effect in milliseconds on the RAN offer two main challenges, one technical, the second commercial.

The technical challenge associated with the development and roll out of xApps and the near real time RIC itself is related to the RAN Scheduler. The RAN scheduler, within the radio architecture is extremely processing intensive and is responsible, among other operations of the real time the uplink and downlink radio decoding and encoding.

Running concurrently with the L1/Phy, RLC and running on the MAC layer, the scheduler reads data from the upstream RLC and transmits to the downstream PHY. The scheduler effectively determines the number of bytes to transmit to each UE in real time.

Since the scheduler is in essence a real time forwarding engine, it is instantiated in the DU and the fronthaul connectivity should have less than 1ms latency to the RU. This stringent latency envelope requires extremely tight integration between the DU, the RU and the near real time RIC (and its associated xApps). While theoretically functionally feasible, the level of integration between all these vendors necessary to realize xApp with the appropriate level of control and performance is generally not there.

The vendors, naturally, first prioritize integration between their own products and in this case, the DU vendors are in control of that value chain.

Understanding that today, there is a very limited number of DU vendors, who are all in the process of realizing the O-RAN first generation implementation and integration, and understanding that all their resources are mobilized on commercial deployments where the priority is the functional, stable and performing implementation of RU, CU and DU, it is not a surprise that we do not see much multi vendor activity on near real time RIC, xApps integration with real RU and CU DU.

 

While we have several examples of trials with either non MIMO CU DU RU or proof of concepts with RU, CU, DU emulators, we are still far from real end to end deployment even in trial situation of a an end to end implementation close to commercial grade.

The second impediment to near real time RIC xApp multi vendor implementation is commercial and can be found in the report.

RICs and Apps executive summary

I first came across open RAN as a concept in 2016, as one of the teams I was supporting at Telefonica was looking into connecting the unconnected in Latin America. After ascertaining the demand, the primary problem to solve was affordability. It just wasn’t economical to deploy traditional RAN networks designed for dense urban environment in the middle of the jungle. The team came out with an interesting idea, the disaggregation of the RAN into components, allowing to pool resources and enabling multiple vendors to compete for different parts of the deployment.

After a few iterations and field trials, the team went on to write the first Open RAN RFI, jointly with Vodafone, released at TIP. From this idea, an ecosystem was born, with a community of operators and vendors, issuing specifications at the Open RAN alliance, elaborating and testing blueprints, issuing requirements and roadmap at the Telecom Infra Project and commercial deployments slowly spreading from Japan to Western Europe and North America.

As the first layer of disaggregation has split the gNodeB into the Radio Units, Centralized Units and Distributed Units, an ecosystem of vendors has emerged, addressing each or all the parts of this new architecture. That first layer of disaggregation was aimed at disrupting the traditional RAN ecosystem, breaking the oligopoly of vendors that have come to dominate the market.

The next stage of disaggregation is aimed at disrupting further the market, by introducing elements of vendor-independent centralized management, optimization, visualization and orchestration with the introduction of the Radio Interface Controllers (RICs). Two RICs have been defined, and although they share the same name, they are quite different in nature and ambition.

The non real time RIC is part of the Service Management and Orchestration layer and is the evolution of Self Organizing Networks (SON) and the RAN OSS / Element management. Features instantiated on the non real time RIC can be deployed as rApps, a standard-defined set of interfaces for multiple vendors to deploy.

The near real time RIC is a feature set belonging to the RAN layer and aimed at disaggregating it further. It extracts capabilities today embedded in the gNodeB, or the RU, CU, DU and provides a layer of abstraction and platform for multiple vendors to theoretically pilot and tune the Radio Network. xApps are the applications that can be developed to be deployed on near real time RIC.

From my experience at Telefonica, as an operator or at Bell Canada or Deutsche Telekom as advisor and consultant or from my time at NEC as global VP Product Management overlooking the development and partnerships surrounding open RAN products, or as an independent analyst researching the market, I have derived a unique perspective on the maturity and effectiveness of open RAN, RICs and Apps. 

This report examines the architecture, strength, drawbacks of open RAN RICs and apps as well as provides an inventory of the main players in the space.

The RICs - brothers from a different mother?

As you might know, if you have been an erstwhile reader of my previous blogs and posts, I have been a spectator, advocate and sometime actor in telecoms open and disaggregated networks for quite some time.

From my studies on SDN /NFV, to my time with Telefonica, the TIP forum, the ONF or more recently my forays into Open RAN at NEC, I have been trying to understand whether telecom networks could, by adopting cloud technologies and concepts, evolve towards more open and developer friendly entities.

Unfortunately, as you know, we love our acronyms in telecom. It is a way for us to reconcile obtuse technology names into even more impenetrable concepts that only "specialists" understand. So, when you come across acronyms that contain other acronyms, you know that you are dealing with extra special technology.

Today, let's spend some time on the RICs. RIC stands for RAN (Radio Access Network) Intelligent Controller. The RICs are elements of open RAN, as specified by the O-RAN alliance. The O-RAN alliance is a community of telecoms actors looking at opening and disaggregating the RAN architecture, one of the last bastions of monolithic, proprietary naughtiness in telecoms networks. If you want to understand more about why O-RAN was created, please read here.  There are two types of RIC, a non real time and a near real time.

O-RAN logical architecture

The RICs are frameworks with standardized interfaces to each others, and the other elements of the SMO,  the cloud and the RAN. They are supposed to be platforms onto which independent developers would be able to develop RAN specific features, packaged as Apps that would theoretically be deployable on any standard compliant RIC. The Apps are called rAPPs for non RT and xApps for near RT RIC.

Although the RICs share the same last name, they are actually quite different and are more distant cousins than siblings, which makes the rApps and xApps unlikely to be compatible in a multivendor environment.

The non real time RIC and the rApps

The non RT RIC is actually not part of the RAN itself, it is part of the Service Management and Orchestration (SMO) framework. The non-real time aspect means that it is not intended to act on the O-RAN subsystems (Near RT RIC, Centralized Units (CU), Distributed Units (DU), Radio Units (RU)) with a frequency much lower than once per second. Indeed, the non RT RIC can interface with these systems even in the range of minutes or days. 

Its purpose is a combination of an evolution of SON (Self Organizing Networks) and the creation of a vendor-agnostic RAN OSS. SON was a great idea initially. It was intended to provide operators with a means to automate and optimize RAN configuration. Its challenges raised from the difficulty to integrate and harmonize rules across vendors. One of O-RAN's tenets is to promote multi vendor ecosystems, thereby providing a framework for RAN automation. As part of the SMO, the non RT RIC is also an evolution of the proprietary OSS and Element Management Systems, which for the first time provide open interfaces for RAN configuration.

Because of its dual legacy from OSS and SON, and its less stringent integration needs, the non RT RIC has been the first entity to see many new entrant vendors, either from the OSS or the SON or the transport or the cloud infrastructure management communities. 

Because of their non real time nature (and because many non RT RIC and rApps vendors are different from the RAN vendors, the rApps have somewhat limited capabilities in multivendor environments. Most vendors provide visualization / topology / dashboards capabilities and enhancements revolving around neighbouring and handover management.

The near real time RIC and the xApps

The near real time RIC is part of the RAN and comprises a set of functionalities that are, in a traditional RAN implementation part of the feature set of the gNodeB base station. O-RAN has separated these capabilities into a framework, exposing open interfaces to the RAN components, theoretically allowing vendor agnostic RAN automation and optimization. The near real-time would infer sub-second frequency of interaction between the elements. And..here's the rub.

Millisecond adjustments are necessary in the RAN to account for modulation, atmospheric or interference conditions. This frequency requires a high level of integration between the CU, DU and RU to not lose performance. As often in telecoms,  the issue is not with the technology, but rather the business model. O-RAN's objective is to commoditize and disrupt the RAN, which is an interesting proposition for its consumers (the operators) and for new entrants, less so for legacy vendors. The disaggregation of the RAN with the creation of near RT RIC and xApps goes one step further, commoditizing the RU, CU and DU and extracting the algorithmic value and differentiation in the xApps. The problem with disruption is that it only works in mature, entrenched market segments. While traditional RAN might be mature enough for disruption, it is uncertain that open RAN itself has the degree of maturity whereas new entrants in RU, CU and DU would be commoditized by xApps.

For this reason, it is likely that if near RT RIC and xApps are to be successful, only the dominant RU, CU, DU vendors will be able to develop it and deploy it, which will lead to some serious dependencies against vendor independence.

 I am currently working on my next report on Open RAN and RIC and will provide more updates as I progress there.