This interview discusses the evolution of network optimization technologies. Per Kangru, Strategy Director, VIAVI Strategy Office delves into the transition from Self-Optimizing Networks (SON) to the promising RAN Intelligent Controller (RIC).  

Can you explain why SON was considered a significant development in the first place? 

When SON, or Self-Optimizing Networks, emerged, it was a game-changer. Back then, network configurations were largely manual. It was a labor-intensive process to integrate new base stations or set up an entirely new network. SON promised to automate much of this, which was a big deal. SON was a leap from manual to automated network management. But where did it fall short? 

SON was excellent in theory. It made integration and configuration easier, but as networks grew and diversified, a multi-vendor problem arose. Different vendors provided various self-healing capabilities, but they didn’t always work seamlessly together. 

So, SON struggled with vendor compatibility. What about the vision of fully autonomous networks? 

That’s an interesting point. Many hoped that SON would create networks that self-optimized and self-healed without human intervention. However, in practice, this wasn’t always the case. It worked better for networks with a significant opportunity to improve but had limited incremental value for already efficient ones. So, the practicality of SON fell short of expectations in reality.  

C-SON, or Centralized SON, aimed to build applications using network data. This required substantial server capacity and posed challenges in harmonizing algorithms across different vendors. It also meant limited scalability when multiple use cases from different vendors were desired. Integration costs soared as you had to duplicate efforts for each vendor’s use cases. So, the issue was more about the vendor ecosystem and compatibility.  

How does the RAN Intelligent Controller (RIC) address these challenges? 

RIC has brought significant improvements. It allows easy configuration changes for optimal performance and efficiency, without the integration hassles faced by a separate SON system. RIC comprises the RIC itself, third-party rApps and xApps, and Service Management and Orchestration (SMO). These components fundamentally address the previous vendor compatibility and platform scalability issues.  

RIC decouples the platform vendor from the App vendors, creating an innovative ecosystem. This separation empowers network operators to choose the best-of-breed solutions for their specific needs, avoiding the one-size-fits-all approach while leveraging a single data platform. 

Legacy networks remain a concern, nevertheless. While Open RAN and O-RAN are making strides, existing networks must also be considered. Some RIC and SMO platforms can support both legacy RAN interfaces and modern Cloud RAN / O-RAN interfaces. However, their success in integration is still under evaluation. 

So, RIC is solving many issues, but challenges remain. How can network operators ensure a successful RIC deployment? 

To ensure success, operators should: 

  • Evaluate RIC, rApps/xApps, and algorithms in a controlled lab environment to mitigate conflicts and security risks. Discover how.
  • Carefully select a platform that meets performance, agility, and flexibility needs. You must support your existing legacy and your future network all round. Consider how you will interface with certain core network data where the interface is interconnecting core network intelligence into the RIC.
  • Ensure a developer-friendly toolkit for App development and lifecycle management. 
  • Opt for an open platform to support diverse network actions. Your legacy vendors need to have the relevant support to feed their existing RAN Trace, FM, PM data or possibly other streaming interfaces. When all these vendors move to Cloud RAN (which doesn’t necessarily have to be Open RAN), those interfaces will have to be supported as well.
  • Benchmark RIC infrastructure vendors for performance and data support.
  • Evaluate your RIC infrastructure vendor, the level of data they provide, the SMO on the RIC, and how it receives the data. This is all standardized by the O-RAN ALLIANCE but make sure that all is supported. End-to-End testing in the lab allows to exercise diverse traffic scenarios that generate different data sets received by the RIC and the Apps. 
  • Implement automated IT lifecycle management for continuous updates. the Apps and the platform will require software updates which might change characteristics, leading to simple issues like having to retrain AI and ML algorithms, or to more serious ones such as network failures due to security breaches. Lifecycle management needs to be built in an impeccable way with a fully automated CI-CD-CT loop. This is where RIC test can help.
  • Incorporate Service Assurance capabilities for network health and rollback procedures. Have a network guardian capability in the RIC and SMO to take the recommended changes in live mode and validate them against a Digital Twin. 

Working together with AirHop, Juniper Networks, VIAVI Solutions and VMware, the partners completed a RAN closed-loop optimization Proof of Concept (PoC) within Deutsche Telekom’s lab environment in a multi-vendor setup based on ONAP & O-RAN specifications.

VIAVI provides solutions to elevate RAN intelligence in all areas listed above, ensuring a successful RIC deployment. Our expertise and tools can help operators navigate this transformative journey. 

This is the second blog post from the new series “RAN Intelligence solutions: from standard, to highly intelligent open networks”. Stay tuned for more!

About The Author

Close