skip to main content
Close Icon We use cookies to improve your website experience.  To learn about our use of cookies and how you can manage your cookie settings, please see our Cookie Policy.  By continuing to use the website, you consent to our use of cookies.

Omdia view


The Open Network Automation Platform (ONAP) project is in its third year. AT&T remains committed, but many operators and vendors are confused about how ONAP overlaps with other standards activities such as ETSI Network Functions Virtualization (NFV) and MEF Lifecycle Service Orchestration (LSO). We see a role for ONAP as a reference implementation of multiple standards, bridging the gap between generic specifications and actual code, thereby improving interoperability.

ONAP version 6 released but some skepticism remains

Linux Foundation Networking (LFN) recently announced the sixth release of its ONAP. Initially launched in February 2017, ONAP comprises service design (modelling resources, specifying policies, and applications), service deployment (automated instantiation through orchestration) and service operations (such as healing and scaling). It could be thought of as a “soup-to-nuts,” next-generation OSS for the NFV and telco cloud era.

ONAP’s architecture is modular so operators can choose to implement just one function, such as active and available inventory, rather than the whole shebang. The ONAP community also defines more easily digestible “blueprints” for popular use cases such as broadband services, VoLTE, and vCPE.

The ONAP project has been enthusiastically embraced by operators such as Bell Canada, Orange, and Vodafone and continues to be supported by the original seed code providers AT&T and China Mobile. However, the traditional telecoms equipment and OSS vendor community have tended to be more wary. Furthermore, many of those in communication service provider (CSP) CTO positions are more enthusiastic about other initiatives with similar aims such as the MEF’s LSO, the TM Forum’s Open Digital Architecture, and a rival open source project hosted by ETSI (and ardently supported by Telefonica R&D) – Open Source MANO.

Samsung replaces Huawei as number two contributor, behind AT&T

According to the Bitergia dashboard for ONAP (, the number of code commits in the year ending June 2020 was around 24,600, down around 29% from the prior year and down 15% from the year before that. It still seems like a healthy number; less propitious for a community project is the continued dominance of AT&T in new code commits (44% in the year ending June 2020; 36% in the year before). Interestingly, Huawei is no longer the second largest contributor (as it was in the year ending June 2018 with 18% and 2019 with 10%). Instead, Samsung has leapt into the number two position with 9% of the commits in the most recent year, from nowhere in prior years. Samsung is followed by Ericsson (6%), China Mobile (6%), and Nokia (5%). Previous top five contributors such as ZTE, Amdocs, and IBM have been less active of late, as measured by the number of code commits.

Mixed views on how best to consume ONAP

The proof of the pudding is in the eating, so it was intriguing to read the recent paper (see Further reading) by the LFN End User Advisory Group, which discusses the different ways in which ONAP is being “consumed.” Contributors to the report came from AT&T, China Mobile, Orange, STC, Telecom Argentina, TIM, and Vodafone. Of particular interest was a poll that asked how CSPs planned to use ONAP. The question only had only 11 affirmative responses, plus a further three that were unsure, and one that had no near-term plans to use ONAP. So, Omdia asked a similar question on a LinkedIn survey in the hope of getting a bigger sample. The Omdia survey (see Further reading) received 41 votes allocated as follows:

  • A (39%): Build a complete ONAP system in-house

  • B (17%): Outsource the building of an ONAP system

  • C (15%): Use a professionally supported distribution of ONAP

  • D (29%): Treat ONAP as a reference implementation.

Among the respondents was the CTO of a new Asian mobile operator, the head of technology innovation at a tier-one European operator, the chief IT systems architect at a tier-one multinational operator, and the head of group network strategy at a global tier-one operator. Surprisingly, our survey showed even greater support for the “build in-house” approach than the LFN’s poll (39% vs. 27%). It showed less support for the outsourcing approach (17% vs. 36%), a bit more support for distributions (15% vs. 9%) and about the same support for the reference implementation approach (29% vs. 27%).

ONAP’s key value may be as a reference implementation

Despite the poll results, Omdia’s view is that few operators outside of AT&T, Bell Canada, and Orange will build a complete ONAP system themselves due to a lack of resources. Any that do are likely to be narrow in scope, for example, for a single line of business in a single country in a specific domain (e.g., Open RAN). We are skeptical that many will outsource an ONAP implementation to a vendor, such as Amdocs or Nokia, or a systems integrator, such as Accenture or Tech Mahindra, due to the cost involved.

The supported distribution option does not appear viable at first glance. The obvious candidates of Red Hat and Canonical do not offer an ONAP distribution. Aarna Networks does but this is a company with less than 10 employees. However, LFN tells us that Accenture and IBM plan to offer generic ONAP distributions and other vendors plan to offer “customer-specific” distributions (which somewhat undermines the whole idea of an open source distribution).

This leaves the option of treating ONAP as a reference implementation. The idea is that standards bodies such as 3GPP, ETSI, MEF, and TM Forum only provide guidelines for how their standards and interfaces should work. The implementation is left up to each individual vendor. Each vendor can claim compliance with the standard but provide a solution that is not fully interoperable with its competitors, thereby increasing customer stickiness. The ONAP community is now providing actual code for how to do things such as VNF onboarding (that are described generically in ETSI standards). CSPs are now asking for ONAP compliance to shortlist vendors and ensure their interoperability. The ONAP community is a vehicle for operators to bypass the obstacles to interoperability that vendors lay in the traditional standards-setting process. If it succeeds it could help the industry simplify operations so that resources can be invested in service innovation instead of IT plumbing.


Further reading

ONAP’s 6th Release, ‘Frankfurt,’ Available Now (June 2020)

ONAP Bitergia Dashboard

ONAP Consumption Models Whitepaper (June 2020)

LinkedIn Poll on ONAP (July 2020)

Market Landscape: NFV technology, SPT002-000354 (July 2020)

“Verizon membership establishes ONAP as the de facto platform for service automation,” SPT002-000039 (January 2018)


James Crawshaw, Principal Analyst, Service Provider Operations & IT

[email protected]

Recommended Articles