In December 2017, ETSI launched its Zero touch automation group – with Deutsche Telekom in the driving seat. OS-MANO is a longer standing ETSI project backed by the likes of Telefonica for the management of NFV networks. The OS stands for open source. TM Forum, the voice of telco OSS, also has a zero touch operational programme – ZOOM – of its own.
Then there’s ONAP, another open source programme under the Linux Foundation that was originally formed by AT&T and China Telecom combining their separate efforts to develop network automation software.
As networks disaggregate, virtualise and functions within them get distributed, operators may need an automated means of managing the control of the NFVi (NFV Infrastructure), as well as the VNFs (Virtual Network Functions – eg vEPC) running on that infrastructure, and then mapping that to the software that operates the networks.
I have noticed that in the last six months different initiatives have been aligning, to some extent.
That’s the massive ambition that AT&T took on with its E-COMP, now ONAP, software initiative. The other projects named have all taken on aspects of that overall push to automation. What they have all realised is that there needs to be maximum openness within the technology stack, or the integration pain will be immense, and operators will be limited in their choices of VNF, say. The industry has seen a move from the traditional standards path to the adoption of open source development.
Ragu Masilamany, VP & Head of ECOMP/ONAP, Amdocs sees ONAP as the consolidating factor right now. Perhaps that’s not surprising, as Amdocs is a founder vendor contributor to ONAP and has worked with operators such as AT&T, Orange and Bell Canada on trials and deployments.
“I have noticed that in the last six months different initiatives have been aligning, to some extent. This is in response to operator concerns that there are too many ways of doing things. Look at 3GPP – sort of the bible for mobile operators – putting out a study of ONAP. They have not done that before.
Although ETSI often sends out liaison statements (for instance to IEEE), Masilamany said, “Traditional standards organisations develop specs based on the consensus of their own members – it’s unusual to reach out.”
I am very bullish about where this is going to end up.
For Masilamany it’s a sign that ETSI’s members see the need to take a closer look at ONAP. He is emboldened in that view by Verizon and Turkcell recently joining ONAP, meaning that operators committed in some way to ONAP now account for 60% of the global mobile subscriber base. “I am very bullish about where this is going to end up,” he said.
You don’t join just to keep an eye on this, Masilamany noted. “Verizon joining tells me that they will commit, they’re not there to watch. You can watch already without being there.”
The real cache for ONAP in harnessing Verizon’s commitment is that it was one operator that had previously said it would look elsewhere. “They have changed their minds,” said Masilamany. “The company had stated its intentions and made vendor choices on orchestration, for example with Ericsson, but now it will go more ONAP.”
So.. why?
“I think they see the potential as a framework for the automation capabilities that they need. Verizon sees ONAP as a whole giving a framework to where they want to go”
Masilamany says that ONAP also brings advantages to VNF vendors, by providing a pre-destined compatibility with the automation and management framework the operator has adopted. He sees vendor moves to verify against ONAP as another driver.
ONAP talks the language of an operator, it talks change management with an operational link
“The VNF vendors have a vested interest in making sure their functions are ONAP compatible. So that when they go to sell they can say our functions work with ONAP. This is what operators want – to standardise the way that functions work so they can reduce the cost to automate. So getting vendors to standardise gives operators business drivers to do this.”
For the Amdocs man, one reason operators are pushing for open source is that ETSI stopped short of describing the entire network and service automation capability. It looked at VNF management and the automation of functions, but that then “represents 20% of operators” interest.
“You can virtualise any function, automate the life cycle, however you are still to do the SDN automation and do a mental map between the two. If you can scale a function, spin up a VNF, migrate it, everything’s no good until you can network it. This is what ONAP brings to the table. A single model for SDN-NFV. ETSI stopped at functions and did not think about SDN. ONAP talks the language of an operator, it talks change management with an operational link that has some meaning that operators understand.”
But we can’t ignore the parallel momentum of ETSI OS-MANO. “Yes it will work. There are multiple ways of doing this. I’ve been in business long enough to know there will be a few ways of getting things done.
“OSM is an interesting push, and we have to see zero touch from Deutsche Telekom: they believe there’s not enough automation capability anywhere, so they will push.
“My concern is that its an operator coming and saying, ‘There’s not enough automation I am going to start another way.’ It could push back other operators who wait to see again. This is my concern because every day operators wait somebody else is eating their lunch.”
Beijing and 5G
So what next? Well, if the first ONAP release, Amsterdam ,was a full release with vVoLTE and vCPE use cases added to it as proof points, then the next one, Beijing, due out at the end of April, will move towards operators’ 5G requirements.
“The driver for Amsterdam was to pipe clean the platform. Beijing will be slightly different; without saying it will deliver 5G use cases it says, ‘What are operator priorities for 5G, and to achieve those what are the capabilities we have to test on the platform.’ So it’s about platform capabilities to support 5G core, 5GNR, to manage radio software, BBUs,and the core in an elastic manner.”
“5G is great driver for NFV because you have to start thinking about about network slicing.And then you have to think about the automation of virtualised functions at scale. The 5G use cases that demand the most of the network – in terms of scale or latency – for those use cases to get rolled out I can’t see how they can be sustained without an automated, elastically-scalable network.”
And for Amdocs, how will it leverage its position within ONAP? Outside of its work directly with operators, Masilamany’s view is that the Amdocs ecosystem brings in vendor partners to be compatible with ONAP: the vendors are interested in being certified and also for a small vendor it acts as a market-place for them.
As Vice President and Head of ECOMP/ONAP at Amdocs, Ragu Masilamany is leading the development of NFV/SDN Orchestration Platform and contribution to open source ONAP programme.
