How ONAP is blurring network boundaries

Telecom operators will soon be able to expand their networks by running virtualised network functions in the public cloud. This follows work by Amdocs to port the open-source Open Network Automation Platform (ONAP) onto Microsoft’s Azure cloud service.

Source: Amdocs, Linux Foundation

According to Craig Sinasac, network product business unit manager at Amdocs, several telecom operators are planning to run telecom applications on the Azure platform, and the software and services company is already working with one service provider to prepare the first trial of the technology.    

Deploying ONAP in the public cloud blurs the normal understanding of what comprises an operator’s network. The development also offers the prospect of web-scale players delivering telecom services using ONAP.

ONAP  

ONAP is an open-source network management and orchestration platform, overseen by the Linux Foundation. It was formed in 2017 with the merger of two open-source orchestration and management platforms: AT&T’s ECOMP platform, and Open-Orchestrator (Open-O), a network functions virtualisation platform initiative backed by companies such as China Mobile, China Telecom, Ericsson, Huawei and ZTE.  

The ONAP framework’s aim is the become the telecom industry’s de-facto orchestration and management platform. 

Craig SinasacAmdocs originally worked with AT&T to develop ECOMP as part of the operator’s Domain 2.0 initiative. 

“Amdocs has hundreds of people working on ONAP and is the leading vendor in terms of added lines of code to the open-source project,” says Sinasac.

Amdocs has make several changes to the ONAP code to port it onto the Azure platform. 

The company is using Kubernetes, the open-source orchestration system used to deploy, scale and manage container-based applications. Containers, used with micro-services, offer several advantages compared to running networks functions on virtual machines. 

Amdocs is also changing ONAP components to make use of TOSCA cloud generic descriptor files that are employed with the virtual network functions. The descriptor files are an important element to enable virtual network functions from different vendors to work on ONAP, simplifying the operator effort needed for their integration.  

“There are also changes to the multiVIM component of ONAP, to enable Azure cloud control,” says Sinasac. MultiVIM is designed to decouple ONAP from the underlying cloud infrastructure.

Further work is needed so that ONAP can manage a multi-cloud environment. One task is to enable closed-loop control by completing work already underway to the ONAP Data Collection, Analytics, and Events (DCAE) component to run in containers. The DCAE is a component of ONAP that is of interest to several operators that recently joined ONAP.

Amdocs is making its changes available as open-source code. 

Business opportunities

For Microsoft, porting ONAP onto Azure promises new operator customers. Microsoft is also keen for vendors like Amdocs to use Azure for their own development work.

Telecom operators could use the Azure platform in several ways. An operator running ONAP on its own cloud-based network could use the platform to spin up additional network functions on the Azure platform. This could be to expand network capacity, restore the network in case of a fault, or to host location-sensitive network functions where the operator has no presence. 

A telco could also use Azure’s data centres to expand into regions where it has no presence.

Amdocs says cloud players could offer telecom and over-the-top services using ONAP. “As long as they have connectivity to their customers,” says Sinasac.