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.