Close
Close

Published

Momentum mounts behind ONAP, but Amdocs may be the commercial winner

The ONAP (Open Network Automation Protocol) is a major power play by AT&T. Although China Mobile also contributed code and other operators are now involved, the heart of the would-be open source standards came from the US operator, which is therefore helping to establish the rules for the new world of automated, software-defined networks, and how they are managed and orchestrated. But the company which may well make the most commercial hay from ONAP is Amdocs, which helped AT&T design and implement the operator’s original inhouse system, ECOMP, and which is making ONAP the basis of a new integration business.

The software house is preparing a carrier-grade release of the open source ONAP code, which will also be targeted at enterprises. Amdocs aims to cash in on the challenges which operators and enterprises have in implementing open source code in a robust, optimized way – BT is one telco which has pointed out how resource-intensive this process is, and many other organizations will not be prepared to hire teams of staff to ensure that the benefits of an open platform are not negated by a system that is not adequate for the rigors of a telco networks.

Such operators, Amdocs hopes, will turn to integration and consulting services. Its attempts to expand its core BSS business into other areas, from RAN software to media platforms, have been persistent though not always successful. But its ONAP-based offerings come at a good time, when many operators are grappling with the complexities of virtualizing their networks and adopting open source, software-first platforms. And because of its role in creating ONAP’s progenitor, ECOMP, it has a genuine headstart over others, and some real world implementation experience to show off.

ONAP contains modules for creating, monitoring, and orchestrating virtual network functions (VNFs). Angela Logothetis, CTO of Amdocs Open Network, the unit which will run the new integration services, told Light Reading that the company has tested those core modules for security and hardened them for carrier or enterprise use, “taking what’s open source and making it carrier-grade”.

This goes a step beyond commercial packages which Amdocs is already offering based on ONAP. Its next step will be to apply ONAP more specifically to the mobile network as the move towards 5G pushes MNOs to accelerate virtualization initiatives. Logothetis notes that most operators which have embarked on virtualization and SDN in mobile networks have started in the core, which is easier to address than the RAN – though that presents a 5G challenge, since the 5G Next Generation Core Network (NGCN) is not nearly as well-defined as the radio (the first wave of 5G New Radio standards will work with the LTE evolved packet core, not the NGCN).

As well as aiming to push forward the platforms based on the 5G core, Amdocs has several other areas of focus for its ONAP work. These include edge computing, Cloud-RAN and introducing artificial intelligence to the automation and orchestration of networks. The firm is working with Intel on edge computing proofs of concept, at this stage mainly geared to content caching, but with their eyes on future applications in the Internet of Things.

Amdocs signalled its intention to commercialize ONAP clearly in September when it unveiled its Amdocs NFV Powered by ONAP, a range of software tools and professional services harnessing its deep knowledge of the platform’s code base. Then it added its

Virtualized Intercarrier Service Orchestration Solution, which is based on ONAP as well as a set of APIs (application programming interfaces) for Lifecycle Services Orchestration (LSO), supporting connectivity services across multiple global networks. These were developed by the Metro Ethernet Forum as part of its Sonata program.

The Amdocs offering enables operators to support software-defined data services which go beyond their own networks. It will help carriers to support multinational enterprises with service level agreements from end to end – something that requires working with many partners. The solution promises to enable operators to automate traffic scaling across multiple service provider networks using ONAP, says Amdocs, thus ensuring high performance end-to-end connectivity.

“Intercarrier service orchestration solutions are a compelling example of how versatile ONAP’s architecture has already become,” said Arpit Joshipura, general manager of networking and orchestration at The Linux Foundation, which hosts ONAP. “When integrated with MEF’s standards, these type of solutions can be used to solve network traffic management issues across networks. Support for intra and intercarrier operations resolves a major business problem for CSPs today specifically for enterprise customers.”

The system does not just draw on AT&T’s work but also that of a larger group which includes Orange, Colt and others. Their focus has been on the ability to offer dynamically controlled services which cross national borders and individual networks. Their aim is to see the MEF APIs and the ONAP code base established as global standards for inter-carrier services and SDN interoperability, though standards alone will not be enough – these complex systems are likely to need significant integration effort, which is where Amdocs will aim to start building a business, along with partners.

The challenge for Amdocs will be to maintain the advantage that its headstart gives it. Ericsson, Huawei, Nokia and ZTE, as well as IBM, are all platinum members of ONAP and will doubtless be working on their own implementations of the code – which is now available to members in its first release – and on services to accompany that. And they will play to their strengths as companies with deep carrier relationships, intimate knowledge of how RANs work, and experience of large-scale integration projects for carriers.

On the other hand, Amdocs will play the card it has also pushed in RAN software, BSS/OSS and other businesses – that it is network neutral and can support truly multivendor and end-to-end implementations. To counter that claim, the large equipment vendors will need to be very careful to display fully open credentials and support their customers’ deeply held belief that 5G will have to be truly open and multivendor.

Meanwhile, ONAP has made its first software release, called Amsterdam, available, marking a step towards a unified architecture for network automation – a cornerstone of 5G. ONAP says its code is the first open source project to unite most vendors and most major operators around a common automation, management and orchestration (MANO) platform.  It claims that its members manage 55% of the world’s mobile subscribers.

“Amsterdam represents significant progress for both the ONAP community and the greater open source networking ecosystem at large,” said Arpit Joshipura, general manager of networking and orchestration at The Linux Foundation. “By bringing together member resources, Amsterdam is the first step toward realization of a globally shared architecture and implementation for network automation, based on open source and open standards.”

The two specific use cases covered by Amsterdam are a virtualized core to manage VoLTE services, and virtualized residential CPE. The next release will be called Beijing and is scheduled for summer 2018.

It has taken eight months for the raw ingredients of ONAP – mainly AT&T’s ECOMP, but also China Mobile’s Open-O and other contributions – to be turned into the first release. Although there were some doubts about how robust this early code would be for production implementations, initial reception was positive overall.

Amsterdam combines the contributed code of ECOMP and Open-O and removes duplication, but also adds significant new features. These include a correlation engine called Holmes which joins the former ECOMP Data Collection, Analytics and Events (DCAE) module; and a new module called Control Loop Automation Management Platform (CLAMP).

Much of the code is already in use at AT&T, so has some production track record, and some has been in use at China Mobile. Bell Canada plans and Orange plan to use the system soon and other operators are evaluating it (including new recruit Vodafone) or running proofs of concept.

Bell Canada stated: “As a member of ONAP, we look forward to working with our international partners to begin the implementation of Version 1 later this year. We also look forward to the integration of the ONAP Operations Manager expected in the spring.”

“The modular approach makes sense, because nobody is going to rip and replace their existing systems to use ONAP,” said James Crawshaw, senior analyst with Heavy Reading, in a detailed and positive assessment of the new release published in LightReading. “They want to use legacy as much as possible and implement new stuff as it were, where there is a clear opportunity to save costs or be more innovative and agile in coming up with new services.”

The modular approach will help address one criticism of ONAP – that it was too big for most operators to implement comfortably; and that different users, including enterprises, would require a different subset of functionality. Some had been deterred by the sheer volume of ONAP code – about 10m lines of seed code, covering about 30 projects with multiple vendors either within ECOMP or Open-O.

That issue may seem less significant now, but there are still some more negative views, though some come from backers of ONAP’s main rival to be the leading orchestration architecture, ETSI’s Open Source MANO (OSM).

Some claim the software will lack full stability until its third or fourth version. Arash Ashouriha, deputy CTO at Deutsche Telekom (not an ONAP member), told the recent SDN/NFV Congress in The Hague: “A big proportion of the industry has converged toward ONAP but there is still a long way to go because the full industry is not part of it and the first release is not fully usable.”

This is despite the fact that supporters such as Orange said they were supporting ONAP because so much of its code had already been used in anger within AT&T, giving it a level of real world credibility that was lacking in some open source platforms.

Other critics cite the heavy influence of large vendors like Huawei and Amdocs – when a truly open, multivendor environment  is one of the key goals of virtualization for many operators. Another criticism is that ETSI OSM will provide a more collective, and more structured, platform based around a common information model, which will make it easier to mix and match code from different sources.

According to LightReading, ONAP members are losing hope of a multivendor framework. “I’ll see pigs fly out of one of my private parts before we all agree on a common data model,” David Hughes, VP of IP engineering for PCCW, told the paper’s OSS event last month, adding that it was “probably an exercise in futility in getting NFV vendors to come up with the same interfaces.”

Close