Automation in telcos’ networks and operations support environments is mandatory before 5G hits, Arpit Joshipura, General Manager of Networking & Orchestration of the Linux Foundation, told TM Forum members gathered here at Action Week in Vancouver on Monday. That means collaboration among open source projects and standards bodies is also mandatory – and there is little time to waste.
Operators are using fragmented, disjointed and manual processes to deliver cloud, residential, enterprise and internet of things (IoT) services, Joshipura said. “This is today’s biggest problem: You can’t have an IoT device waiting for service – it’s mandatory automation before 5G,” he said. “Data volume will be 1000 times greater than today; there will be 100 times the number of devices; ten times the bandwidth and one-fifth the latency will be required.”
Almost ready for prime time
Transformation of communications service providers’ (CSPs’) businesses is moving toward production-ready end-to-end solutions, according to Joshipura.
“In last five years, this whole disaggregation of networking has led to production-ready components,” he explained. “Today we’re seeing some of the largest networks running on these open source components. Where we’re heading is to more production-ready solutions that are scaled and harmonized and look at it all the way from the data plane to the OSS/BSS layers. That’s why it is very important that we harmonize our views across the industry to accelerate this transformation.”
With Vodafone joining the Open Network Automation Platform (ONAP) project earlier this month, the group now counts 55 percent of telecom operators globally (55 companies) as supporters of the project. The amount of shared technology the group has developed is worth more than $576 million, and 1100 developers are working on the project (see graphic below).
“No single vendor can create that kind of shared technology investment, and no single vendor or company can put 1100 people on a project at the same time,” Joshipura said. “It’s the shared technology and collaboration that is causing disruption.”
ONAP was formed in February when two open source projects, AT&T-led ECOMP and China Mobile-led Open Orchestrator (OPEN-O), joined forces. By consolidating member resources, ONAP has positioned itself to deliver a unified architecture and implementation faster than any one project could on its own.
Release 1 of ONAP, due out in December, is focusing specifically on onboarding virtual network functions. Release 2 in May 2018 will focus on the enterprise and IT side of end-to-end management and will address how to implement container technology.
Joshipura presented another slide (below) showing all the players working on pieces of the end-to-end networking puzzle and explained how they fit together. Projects surrounded by a solid line on the diagram are hosted by the Linux Foundation, while those surrounded by a dotted line are hosted by other groups. Standards, which are shown on the right, do not necessarily focus on all the layers of the network, so not all of the open source projects will need to work with all standards bodies.
“ONAP looks at how you take service orchestration, management and policies, and the entire OSS BSS layer, and automate it in a closed loop and make sure it plugs into the existing systems,” Joshipura explained. “We believe that open source and open standards are critical to harmonizing end user adoption.”
Architecturally there are 11 components to ONAP, the first eight came from ECOMP and the last three from Open-O.
Joshipura joked when he presented the next slide (below) showing the full ONAP architecture that you could tell technologists had created it because they always cover every bit of the page from top to bottom and right to left.
“There is a design feature on the left where you can design a function and then model it and push it down to runtime,” he explained. “There is closed loop automation so that any trigger or fault that happens in any part of the network can be implemented into a policy framework that your systems will act on, which makes services like network on demand and disaster recovery on demand. It’s a building block to AI.”
Now ONAP is trying to figure out how to bring ONAP application program interfaces (APIs) together with APIs developed by other organizations, and that’s what’s led to collaborate with TM Forum. ONAP has also published a white paper on harmonizing open source and standards. The goal, according to Joshipura, is to answer questions like: “Do we write code? Do we write specs? Or do we write both? Which comes first? How do we upstream? How do we downstream? How do we license?”
He concluded: “My call to action here is very significant – we have global participation, a very vibrant diverse community and the service providers are requesting harmonization across open source and open standards. So, our view is to let the technical people, the best minds out there, come up with a good strategy.
“We’ve been through enough technology wars. We don’t want to fight a technology war of ‘my API is better than yours’. Let’s figure out the best answer to this. We’ve done it once in ONAP when we merged the Open-O and ECOMP architectures, so let’s do that here.”