Open Network Automation Protocol (ONAP) was once seen as a shining pioneer of open source platforms in telecoms networks as they started to become virtualized and software-defined. Now, industry opinion is divided. Some operators remain convinced ONAP is a strong open framework for managing all the functions and components of a virtualized network. Others think it has become far too cumbersome, and that many of its approaches will be superseded by the lighter frameworks that come with containerization.
Undeterred, ONAP is onto its sixth release, codenamed Frankfurt, which is focused on some of the key trends of the day, including 5G network slicing and cloud-native network functions (CNFs).
Arpit Joshipura, general manager for networking, edge and IoT at the Linux Foundation, which hosts ONAP, said: “One of the biggest features is obviously the end-to-end 5G network slicing into the ONAP software.” The operators which worked on this key capability included AT&T, Deutsche Telekom, Telecom Italia, China Telecom and KDDI.
Leading vendors in ONAP include Amdocs, Accenture, Ericsson, Fujitsu, Huawei, IBM, Intel, Lumina, Matrixx, Netcracker, Nokia, Openet, Pantheon.tech, and Robin.io.
Catherine Lefevre, AVP for network cloud at AT&T, and chair of the ONAP technical steering committee, said Telecom Italia had identified slicing as a key missing element in ONAP about a year ago.
Joshipura claims many of the issues of over-complexity and excessive overhead have been addressed in the recent ONAP releases, although this might be belied by the fact the initiative now includes 27 sub-projects across 34 organizations and over 400 developers. That implies a high level of scale and innovation, but also an awful lot of code. AT&T and China Mobile, which contributed the original sourcecode for ONAP, are still in the top 10 contributors of code, along with Orange and Bell Canada, plus six vendors or other non-telcos. Swisscom, T-Mobile, Telstra and Verizon are also significant contributors.
Frankfurt indicates the increasing alignment with the O-RAN Alliance to address multiple layers of an open network – which will be essential for slicing. The release includes support for O-RAN’s A1 interface, between the orchestration layer (ONAP or other MANO) and O-RAN’s RAN Intelligent Controller (see separate item). It also features increased support for the O-RAN O1 interface for fault, performance and configuration management.
Other additions include:
- orchestration and management of multi-cloud CNFs and cloud-native applications across multiple Kubernetes clouds.
- new functionality in S3P (stability, security, scalability, performance)
- the first implementation of Multi-Domain Optical Network Services (MDONS), which was developed by Fujitsu, Orange and others. This will support the development of enhanced service offerings and applications to drive network automation at the optical layer, meaning that ONAP now supports automation in Layers 0 to 7.
The next ONAP release, Guilin, is scheduled for the second half of this year. It will build on Frankfurt’s work in 5G slicing and O-RAN integration, and will also include results from deeper cooperations with other organizations such as 3GPP and ETSI.
TelecomTV provided a useful list of some of the operator deployments of ONAP (https://www.telecomtv.com/content/orchestration/onap-takes-hold-in-the-carrier-community-as-need-for-automation-grows-38968/). They include:
- China Mobile uses customized ONAP components for its NFV orchestrator, and for NFV product certification and procurement testing.
- Orange mandates ONAP support for 5G and any VNFs/CNFs. It makes a full ONAP deployment available to developers and has been a leader in PoCs and other developments.
- China Telecom is launching a new OSS based on ONAP.
- Verizon is working on ONAP-based service orchestration involving multiple VNFs and is driving the development of ETSI MANO-compliant interfaces.
- Deutsche Telekom has more than 10 ONAP instances in its labs and is conducting tests on the automation of virtual EPC, 5G core and slicing processes.
- Turk Telekom has ONAP code deployed to support SD-WAN.
- Reliance Jio is evaluating ONAP for automation and cloud-native strategies, particularly VNF and CNF on-boarding.
- Swisscom is using ONAP in its broadband service and CPE management.
- Telecom Italia is working on ONAP orchestration for its 5G core and combining ONAP and Kubernetes/CNF orchestration.
- Microsoft has ONAP running on Azure as part of its telecom strategy.