ONAP's sixth release, Frankfurt, checks off key boxes across 5G network slicing, blueprints for scaling 5G and cloud-native network functions (CNFs.)
LF Networking's Open Networking Automation Platform (ONAP) has also increased its collaboration with open source groups and standards development bodies in the Frankfurt release including 3GPP, ETSI, GSMA, MEF, O-RAN and TM Forum.
"It's the most comprehensive and secure release yet," said the Linux Foundation's Arpit Joshipura, general manager, networking, edge and IoT. "One of the biggest features is obviously the end-to-end 5g network slicing into the ONAP software."
AT&T's Catherine Lefevre, AVP for network cloud and SDN platform integration, and the chair of ONAP Technical Steering Committee, said operators that worked on the 5G network slicing primarily included AT&T, Deutsche Telekom, Telecom Italia, China Telecom and KDDI.
"We met with Telecom Italia probably one year ago and they said they wanted ONAP in production, but what they really missed from ONAP was the network slicing," She said. "So they were really pleased to participate. With the carriers that are supporting this feature, we have additional requirements brought by them for training as well as more on the work aspect of slicing."
ONAP was formed in early 2017 after the Linux Foundation combined ECOMP, which was developed by AT&T, with OPEN-O, which was backed by China Mobile. ONAP is a platform for end-to-end orchestration, management and automation of network and edge computing elements for service providers, cloud providers and enterprises.
While ONAP was decried as too complex in earlier software releases, Joshipura said those issues were resolved in later software releases. Four operators—AT&T, China Mobile, Orange and Bell Canada—are among the top-10 contributors of code to ONAP while Swisscom, T-Mobile Telstra and Verizon have also pitched in.
ONAP now includes 27 sub-projects across 34 organizations and more than 400 developers, which it gives it scale and cohesiveness that were lacking from earlier open-source efforts around automation.
"The bottom line is the community is making it very easy to deploy because northbound and southbound are all standards=based," Joshipura said. "So you can just go to a brownfield deployment and put it in."
For O-RAN, Frankfurt includes Increased support for the O1 interface for fault, performance, and configuration management and initial support for the A1 interface.
Frankfurt also features orchestration and management of multi-cloud CNFs and cloud-native applications across multiple Kubernetes clouds. Frankfurt introduces new functionality and advances in S3P (stability, security, scalability, performance) as well as the 5G blueprint.
Frankfurt also includes the first implementation of Multi-Domain Optical Network Services (MDONS), which was developed by Fujitsu Partners, Orange and other Tier 1 service providers. The MDONS blueprint uses Open ROADM, Open Networking Foundation's Transport API (TAPI), and MEF standards to enable multi-vendor and multiple domain operation.
The newly added ONAP optical services capabilities will allow for the development of enhanced service offerings and applications customized to the needs of service providers, which will in turn drive network automation at the optical layer. With the optical element, Joshipura said ONAP now enables automation across Layers 0-7.
ONAP put the finishing touches on the Frankfurt release during the coronavirus pandemic, which meant its global members had to align their work-from-home capabilities to wrap up the release.
"I want to highlight the fact that I was really impressed by the level of commitment by the team during this time," Lefevre said. "We have been cautious so there was an additional delay by a little bit. A lot of effort has been made.
"It's not just a community. It's a booming community. I'm really proud of the team. "
The next ONAP release, "Guilin," is slated for release the second half of this year. Guilin will increase the support for 5G in areas of network slicing and O-RAN integration, ETSI, as well as the cloud-native journey including deeper integration with K8s. The release after Guilin is called "Honolulu."
"It's (Guilin) going to be a cloud-native heavy release for sure because we're going to have deeper integration, but there's definitely O-RAN and 3GPP work," Joshipura said. "The team is also looking at a much smaller, faster release that we can get out in four months."