By: Mark Abolafia

The road to virtualization has been a long one in many ways, and the devil is certainly in the details—networking challenges, organizational processes, costs and BSS/OSS integration concerns are many aspects to be considered. One industry buzzword that holds many promises for streamlining and simplifying that journey is ONAP. But will it stand up to the hype?

The open source platform could transform service provider networks, which would have a positive trickle-down effect for enterprises, if its potential unfolds. ONAP is well-positioned to boost support systems and make networks worldwide more agile, efficient and prepared to leverage the latest technologies.

Luckily, the stars have already started to align. You could say that ONAP is having a moment, but we think it will be more than just 20 minutes of fame.

The ONAP Vision

The whole idea behind the Linux Foundation’s Open Network Automation Platform (ONAP) is to speed up, automate and standardize virtualization initiatives. When ONAP announced its inaugural platform release—called Amsterdam—in November 2017, it claimed to be “transforming the service delivery lifecycle for network, cable and cloud providers” with “the first open source project to unite the majority of operators (end users) with the majority of vendors (integrators) in building a real service automation and orchestration platform.”

ONAP helps to build virtual network functions (VNFs) and software-defined networks (SDN), from design and orchestration to monitoring and life-cycle management, with a closed-loop automation platform. So many people are working on these software-defined projects to some extent; why not pool resources, talent and ideas to move the industry forward in an orchestrated fashion?

The open source software platform “uses cloud technologies and network virtualization to offer services, achieving both faster development and greater operational automation,” according to its developer Wiki. It’s providing the software framework to allow service providers to quickly deploy new features and reduce OpEx. And it “creates a level playing field for carriers and equipment providers,” the Wiki states.

ONAP is one of many open source initiatives, and it certainly hasn’t been without its fair share of controversy and skepticism. But it’s constantly gaining recognition and new advocates, and its origin story is rooted in reputable companies and projects. ONAP was born in February 2017 when AT&T’s Enhanced Control Orchestration, Management and Policy (ECOMP) merged with the Open Orchestrator Project (OPEN-O).

Of course, it’s not the only game in town; ETSI’s Open Source MANO (OSM) project has gained significant support, especially from European operators such as Telefonica and BT.

What Has ONAP Accomplished So Far?

But it seems like there’s a new ONAP application, deployment or partnership announced every week. ONAP is supporting more than 60 percent of the world’s mobile subscribers, and its membership base is growing, with 60+ backers, including Cisco, Equinix, Ericsson, IBM, Orange, Red Hat, Vodafone and a few more of the biggest telecom carriers and vendors in the world that we’ll get to below. Nearly 460 individuals have added code to the project, this Linux Foundation blog points out.

The platform is already starting to make waves, which is impressive considering it just celebrated its official one-year birthday in March. According to SDxCentral, Bell Canada is using ONAP in production networks, and China Telecom plans to leverage the code for vCPE and VoLTE applications.

At Open Networking Summit in March, a Colt network architect said he anticipates that ONAP will “become as much of an industry standard as OpenStack has become for NFV infrastructure,” Light Reading reported. In March, AT&T and the Open Networking Foundation (ONF) announced their partnership to use ONAP to merge ONF’s work on multi-gigabit passive optical networks (PON), according to FierceTelecom. On the vendor side, Ciena has integrated ONAP into its Blue Planet platform, FierceTelecom reports.