• A new release of the Open Networking Automation Platform (ONAP) is available
• ‘Frankfurt’ is the sixth iteration of the LFN-hosted open source project’s stack
• ONAP elements are embedded at the automated heart of many Tier 1 operators
• It’s even more of a telco software swiss army knife than before

In terms of releases rather than birthdays, ONAP is six and has adopted the name of a German city, Frankfurt. The open source telco software stack, designed to enable the automated management of telco network elements and processes, has come a long way since the Linux Foundation took AT&T’s ECOMP (Enhanced Control, Orchestration, Management & Policy) and China Mobile’s Open Orchestrator (Open-O) projects and merged them in early 2017. Now, more than three years later, it’s at the beating, intelligent, software-defined heart of multiple Tier 1 operator systems that, it is hoped, will be able to deal with the challenges and opportunities afforded by the 5G and telco cloud era.  

According to LF Networking, the branch of the Linux Foundation responsible for the open source projects in which the TelecomTV community is likely most interested, the Frankfurt release is capable of almost anything other than making a steaming hot, put-hairs-on-your-chest triple espresso (though if it can do that too we’d very much to know about it…)

The official release of Frankfurt references “end-to-end 5G network slicing, security, deployment-ready automation… integration with O-RAN, orchestration and management of multi-cloud cloud native network functions (CNFs), and cloud native applications across multiple Kubernetes clouds” and more. That’s just some of the new stuff – there’s a long list of functionality from the previous five versions too, of course.  

You can check out the very extensive list of capabilities, links to the work of other specifications and standards bodies, enhancements to CI/CD processes that make deployments much easier, and so much more, in the LF Networking official release announcement, which is detailed, extensive and creditable.

Ultimately, though, all of the work done on ONAP development is pointless unless it’s put to work and deployable: In the early days, with the early versions, the main criticism of ONAP was that it was cumbersome – millions of lines of code that only the very largest operators or integrators would be able to work with and/or make sense of. That criticism was taken on board, ONAP was broken down into more manageable components and that helped it to become more relevant for test, proofs of concept and deployments.

Now ONAP code is not only driving the latest generation systems at AT&T and another long-time operator supporter, Bell Canada (which uses ONAP code for “a significant amount of manual configuration, recovery, and provision work” in its production network), but also at multiple other operators. Here are just a few examples of how ONAP is being put to use by major carriers (note, this is not a full list and doesn’t mention all ONAP-related efforts and developments):

China Mobile: Using customized ONAP components for its NFV orchestrator, for NFV product certification and procurement testing.

Orange: A long time supporter, the French operator mandates ONAP support in its RFPs for 5G and any virtual/cloud native functions, runs an OpenLab with a full ONAP deployment made available to developers, uses ONAP components in multiple PoCs (eg WAN automation) and leads ONAP projects in the LNF community.

China Telecom: Is launching a new OSS based on ONAP and has multiple 5G-related integration and testing efforts underway using ONAP code.  

Verizon: Working on ONAP-based service orchestration involving multiple virtual network functions and is driving the development of ETSI MANO compliant interfaces that will enable interoperability with various ONAP components.

Vodafone: Regards ONAP as “a crucial platform for standardization across various areas for Telco Cloud adoption” and is a leading player in function on-boarding work and in leading the OPNFV Verification Program (OVP) Compliance and Verification Committee (CVC) working group. (Acronym hell, right?)

Deutsche Telekom: Has more than 10 ONAP instances in its labs, is working on making its ONAP functionality ready for its production network and is conducting tests on the automation of virtual EPC, 5G core and slicing processes.

Turk Telekom: Has had ONAP code deployed to support its SD-WAN since last year and has multiple use cases being tested in its labs. 

Reliance Jio: ONAP “plays an important role in our network automation and transformation,” and is looking at ONAP for its cloud native strategy, including VNF and CNF onboarding.

Swisscom: Is using ONAP in its broadband service and CPE management.

TIM (Telecom Italia): Is working on ONAP orchestration for its 5G core and combining ONAP and Kubernetes/cloud native function orchestration functionality, among many other developments.

Other operators with ONAP PoCs, lab trials and tests include Telstra, Telecom Argentina, Comcast, China Unicom, KDDI, Equinix (including collaboration with Ciena), while Microsoft has ONAP running on its Azure public cloud as part of the ‘Telecom Strategy’ that now also includes the acquisitions of Affirmed Networks and Metaswitch. 

ONAP’s commercial vendor ecosystem is now extensive, and includes specific developments from the likes of Amdocs (which has long seen a revenue opportunity from supporting and helping to develop ONAP), Accenture (including a plug-in for orchestrating VNFs on AWS), Ericsson, Fujitsu, Huawei, IBM, Intel, Lumina, Matrixx Software, Netcracker, Nokia, Openet, Pantheon.tech, and Robin, among many others. 

So it’s hard to imagine that, as a software stack focus on telco cloud automation, that ONAP isn’t going to make it to a ripe old number of versions: But is there a better alternative? Is ONAP still too ‘heavy’ – too many bricks and not enough lego pieces? One for debate during the upcoming digital event debating season!

- Ray Le Maistre, Editorial Director, TelecomTV