ONAP and the telecom industry’s open-source journey

The majority of new 5G services and use cases involve the digitalization of other industries, and bringing them to market requires new partnerships along with significant innovation in the telecom business model. Automation is one of the most important enablers. Better versions of current processes will not be good enough – an autonomous realization of customer needs and operational objectives is required. Current operations-support environments are silo based and not optimal to efficiently support the necessary level of automation that is required to manage the massively scalable next-generation networks. Generally, a low level of industrialization with highly bespoke solutions across the operation support domain makes traditional IT transformation challenging from both time and cost perspectives. 

To escape the limitations of business-as-usual, the telecom industry has embarked on an open-source journey to establish a new way to innovate, simplify industry collaboration and accelerate efficiency. The Open Networking Automation Platform (ONAP) is an open-source networking project hosted by the Linux Foundation Networking (LFN), with the objective of developing a widely-used platform for orchestrating and automating physical and virtual network elements, with full lifecycle management. 

In addition to creating a more harmonized IT environment, ONAP is also driving the harmonization of interfaces toward multi-vendor network systems by defining protocols and reference points between management systems and network entities. This accelerates the alignment of modelling and the data technologies to use, which in turn enables crossdomain automation and innovation. The success of ONAP depends on the establishment of a fruitful development community and an effective approach to incorporating the outcome of the collaboration into daily business.

In the past decade the telecom industry has seen rapidly growing demand (more users, devices and applications) coupled with rising expectations in terms of speed and service performance. This has led to a massive technology revolution with several new technologies across the stack. As a result, networks have become massive and increasingly complex to manage. The current operations support systems paradigm is not capable of efficiently managing the continuously accelerating number of network nodes, technologies, software entities, devices, users, slices and so on, without a dramatic increase in operating expenses. The only way to avoid management costs that rise in proportion to the growth in the numbers of entities, is to leverage automation. Adaptive policy decisions based on artificial intelligence (AI) and machine learning (ML) can further optimize the automation. 

Beyond doing more with less, one of the key benefits of automation is that it helps to boost innovation by turning data and insights into actions and business impact. Understanding and predicting the needs of individual users makes it possible to better orchestrate resources and realize an optimal experience. The ability to produce unique services and offerings at mass market scale bring possibilities to shape new market categories and explore business in new digital ecosystems. Automation shifts the focus of operations support from directly managing resources and services to providing rules at different levels of abstraction to jointly realize the customer experience of services, as shown in Figure 1.

The telecom industry can learn a great deal from the way that leading internet and cloud providers have applied digital technologies to create new markets, step-change efficiency and add value through new and personalized experiences. As the telecom industry is a highly regulated one with a market structure that is mainly defined by national borders, though, it will be necessary to make a similar transition, but in a different way. We must work collectively to establish a common foundation for the greater good, while at the same time maintaining healthy commercial incentives for business to prosper.

Managing technologies of varying levels of maturity

Until recently, hardware and software were pinned together in such a way that it was not possible to change network capacity and topology by configuration only. In recent years, however, virtualization technologies, SDN, MANO and NFVi have been used to transform both fixed and mobile networks. The separation of hardware and software, and a softwarebased realization of the logical network, has created a fundamentally new starting point for automation. The industry is in a far better position today than it was just a few years ago to reap the full benefits of automation. Furthermore, the flexibility provided by the new networks creates a complexity that means automation has moved from an option to a necessity. 

It is, however, important to recognize that for the foreseeable future, networks will consist of physical and virtual technologies of different generations that need to be seamlessly managed. Both customer-facing and network-facing services will utilize modern and legacy network resources in order to serve end users, and by implication, automation and orchestration systems need to manage both. Closed-loop automation is needed across several OSS areas such as experience management, service creation, service assurance and monitoring. 

Policy-aided AI and ML will play a key role in closed-loop automation. T deliver end-to-end service management and automation, the management systems need to correlate data across physical, virtual and software-defined networks throughout the full networking stack. The correlation requirement also ranges from real time to near-real time and historical data in order to reach the higher levels of predictive closed-loop automation.

The internet experience introduced by new digital technology players has set the current standard for what is expected from IT and telecom solutions. Services should be designed and tailored to individual needs and made available significantly more quickly and easily than in the past. This puts new requirements on the underlying technologies and forces a rethink of the management processes. For network and service management this means designing for automation.

For automation to be applicable there is a need for convergence in several forms. Firstly, IT and telecom solutions must further converge. Vendors and operators must work closer together to overcome obstacles in technology and processes. With the advent of 5G, which will be a platform for multi-industry innovations and further expansion of communication possibilities, convergence with digitalized industries will be needed to form true end-to-end applications.

We expect the term cloud infrastructure to be less frequently referred to in the future, simply because it will be the undebatable standard for how large parts of the lower level of networks are built (beyond physical elements in access and transport). This paves the way for cloud-native functions (CNF) using best practices to become elastic, resilient and dynamically composed with automated management. Practices include, but are not limited to, continuous deployment, containers and microservices.

A key attribute of a CNF is that its life-cycle management is fully automated. Examples of automated actions include automatic placement of services, auto scaling, auto healing, and update/upgrade. However, an individual instance of an application does not have access to all network information, so it is equally important that it can be orchestrated by a common operating environment or an external management system to be included in a wider network context such as a network slice.

One key to automation is to achieve separation of concern by dividing the network into separate autonomous layers. Issues should be resolved, and optimization should be performed, at the lowest possible level. Automated decisions should be made as close to the source as possible to reduce system complexity and to increase speed.

Standards and regulations

Because the telecommunications industry is highly regulated, mission-critical telecom services composed of infrastructure and applications supplied by IT and telecom vendors must live up to very demanding ISP (In Service Performance) requirements. Standards organizations like 3GPP, ETSI serves a necessary purpose to converge on architecture, protocols, and interfaces for all mobile network generations. However, convergence has been less successful in the area of management and that calls for complementary and faster modes of collaboration – for example, through open-source reference code. Standardization could actually benefit from independent reference implementations in open source providing important feedback. Furthermore, abstraction and harmonization of the basic parts of network management is necessary to promote cost efficiency and free up resources and budget for functions that provide added value to the solution.

An open-source code initiative offers a complementary way of working that has been proven to work well for designs where a group of people have a common interest to contribute to and work together on a single implementation. The purpose, when it applies to industry sponsored initiatives, is to create code that serves an important common interest, but where most of the business opportunities lie outside that specific code base. The idea is to avoid duplicate implementations of basic functionality and to ensure a well reviewed and widely accepted solution.

Standards and open-source initiatives must complement each other to create a tight ecosystem, avoid fragmentation and maintain the necessary focus to drive automation forward for telecommunications.

The direction of ONAP

The ONAP project was created with the intention of producing an open-source reference implementation of a network automation platform. As a platform, ONAP focuses on the automation of networking resources to provide a particular service or serve a specific purpose. The network resources cover transport resources and virtual network functions, and support for physical network functions is being introduced. It also covers customer premises equipment and networking resources. ONAP is an enabler for the shift from managing resources to managing services and ultimately network automation. ONAP does not address subscriber or product/offering management as other industry initiatives are focused on this problem. Figure 2 illustrates the scope of ONAP automation.

There are at least two interpretations of what a reference implementation is, and ONAP's continued success will depend, in part, on its ability to accommodate both. One interpretation of a reference implementation is that it is a technology source that provides open-source implementations of functions that can be used in products. These open-source implementations are designed to facilitate a larger ecosystem at the same time that they are a part of it. Examples include design and creation functionality (such as onboarding and service creation), mediation functionality, analytics platform functionality, orchestration functionality and so on. This approach is particularly relevant when the technology is considered sufficiently common and mature. 

Another, arguably more impactful, interpretation of a reference implementation is related to industry alignment, where ONAP provides a commonly agreed architecture with well identified functional blocks and clear interfaces. This interpretation offers three main benefits:

1. rapid innovation and competitive alignment
2. the survival of the strong functions of the ecosystem, ensuring that they are not constrained by lagging functions (these will simply be replaced)
3. the use of certain functions independent of the rest of the automation platform

Rapid innovation is enabled by separating the adoption of the architecture and interfaces from the technology in terms of code. This is a powerful concept that has been leveraged by standards driven approaches for decades. It enables new and innovative approaches to solve the implementation of the defined functions, where there is economic motivations for doing so. Adhering to well defined interfaces allows such innovation without impacting on the rest of the automation platform ecosystem. The most economic approach for any particular function will drive the alignment. 

Successful open-source projects have a vibrant ecosystem, and a vibrant ecosystem thrives on facilitating innovation. For ONAP, the strongly defined interfaces and architecture enable specific innovation in the projects that are within the scope of the ONAP platform, by allowing selected parts of ONAP to be used in other contexts and innovation on how to use the platform. 

ONAP can generate even greater value when it is leveraged to create new applications that are beyond its scope. Examples include analytics applications, AI applications, service design and creation workflow flexibility, optimization and assurance capabilities, assign and design innovations, and domain-specific enhancements (evolved packet core, transport, radio access network). 

ONAP is currently focused on service and resource automation for telecommunication service providers. However, in the long term, it has the potential to achieve greater momentum by scaling beyond its current focus into new enterprise use cases and IoT segments. This is why it is so important that the ONAP platform is truly model driven with the capability to be flexibly applied to unforeseen use cases. The models for the basic resource level management of a network function will be delivered by the network functions themselves, which allows the cadence of the delivery of, for example, resource assurance, to be delivered with the same cadence of the network functions themselves. 

The possibility in ONAP to selectively enable innovation for a range of stakeholders and business interests will also be critical to achieving a sustainable scale. This is true both in terms of providing common functions and capabilities applied for innovation across a broad range different use cases as well as for functions provided for highly specialized applications. Another aspect of achieving scale is demonstrating how ONAP can be an open-source realization of standards, serving as a deployment channel that leverages the alignment and concepts created in standards and further focusing of the industry. 

The implications ONAP has for industry alignment go beyond operational support systems: it also has implications for network functions. The need to rapidly introduce new services implies the need to rapidly introduce new or upgraded resources such as network functions. This has led to an effort to align the management interfaces towards the network functions, which requires a balance between avoiding unnecessary mechanical integration while still allowing for the innovation in the capabilities of the network functions. To help achieve this balance, ONAP provides aligned requirements on the protocols used to connect a network function and modelling languages to describe the network functions application information. There will be further alignment around the model for basic system functionality such as health check, start, restart and so on. 

ONAP market momentum

Adoption is key to the long-term viability of any open-source project, and ONAP is no exception. Growing adoption stimulates new players to engage at the core of the open-source community and attracts innovation in the associated business ecosystems, fueling a positive spiral of ongoing progress. The most important driver of ONAP adoption in the short to medium term is uptake in the global telecom operator community. Several leading operators are actively contributing to the open-source project but it will take significant time before they have a major share of their OSS environment based on ONAP.  Most other operators are currently taking a more cautious stance and await the outcome and learnings from ONAP forerunners. 

The hesitation is likely due to lack of a sufficient level of trust. Seeing is believing and many are waiting to see concrete examples of ONAP code being used to realize compelling use cases. The industrialization of the code itself is equally important, including the buildup of required life-cycle management and support capabilities. While these are important enablers for adoption, they go beyond the scope of the open-source project itself. There are a few different options to facilitate uptake. In some cases, operators can undertake the industrialization and integration themselves. Otherwise, a common practice for open source is the establishment of distributors to cater for these needs. Another project delivery option is reaching the market through integration into the solutions of existing providers, following established industrialization models. 

The environment for ONAP is complex and evolving rapidly. Networks are becoming more complicated with the introduction of SDN, virtualization technologies (such as VMs and containers) and microservice based architecture. Despite efforts to consolidate in recent years, a significant share of implementations in the OSS domain remain silo based. Furthermore, there are separate management systems for mobile networks, transport networks and fixed networks. With the introduction of cloud infrastructure, several new management systems are introduced to manage the cloud infrastructure. Horizontally, there are EMS and NMS solutions. Added to this, MANO functions such as G-VNFM, S-VNFM and NFVO are increasingly deployed in operator's network. ONAP should be able to consolidate some of these layers and also interwork with them to provide flexibility to operators. Alignment with standards is crucial since many of the OSS systems follow  standard protocols, principles and architectural framework from standards. 

Since physical, virtual and software defined networks will coexist for the foreseeable future, key services need to be created across modern and legacy networks and ONAP has to be able to interwork with legacy network, EMS and NMS systems to deploy services across the hybrid networks. It is not a viable approach to immediately replace these existing management systems when introducing an ONAP based management system. 

Gradually certain open-source software or modules of ONAP can be introduced and integrated with existing systems. It may be orchestrator (service/resource) or SDC – Service Design and Configuration. Similarly, it will be possible to integrate individual ONAP modules with service providers' existing OSS systems. As ONAP matures and start introducing features to manage the different use cases, operators can take different modules of ONAP and integrate them with their management systems. 

Bringing ONAP to the market needs to be done in a highly modular way to successfully cater to these needs. Our view is that only very few telecom operators will be willing to take the ONAP project deliveries and transform them into a stable, workable OSS implementation. The growth and adoption of ONAP, and its usefulness in brownfield situations, is highly dependent upon its ability to support all the aspects mentioned above. 

Neither the ONAP releases themselves nor industrialized distributions of them will be sufficient to meet the requirements of most operators. The complexity, level of legacy and industry standards dependencies demand a distribution model that is well aligned with the current industry realities. As ONAP evolves we foresee that current OSS solutions will adapt to its architectural principles, guidelines and interfaces. This creates the fastest path to ONAP interoperability across OSS and is the easiest way to increase the presence of ONAP code and use cases in the OSS domain.

As shown in Figure 3, the gradual increase of ONAP components and code into different vendors' solutions will be a key adoption driver and create a more efficient code base for the industry in the long term. More importantly, this will also result in easier and faster solution implementation and a gradual reduction of integration efforts and life-cycle management costs as the industry gradually incorporates ONAP as a common platform. 

Another way to boost adoption and scale is for ONAP to develop and support use cases for the IoT industries. Collaboration with adjacent LF projects (such as Akraino, Acumos, ODL and Kubernetes), as well as other projects such as Openstack, will also play an important role. 

Beyond telecom

There are several use cases beyond telecom where key ONAP capabilities can be an excellent approach for digitalization in other industries. Many industries are undergoing transformations similar to telecom where resources are virtualized, programable and orchestrated in real-time operations and provided in new business models. 5G is a key enabler for this development. Several ONAP capabilities within the management layers – such as automation, AI/ML, adaptive policy, information models, and an orchestration layer that can configure and manage end-to-end services across legacy and modern networks – are candidates for future use in models and use cases in other industries as well.

Furthermore, the digital ecosystem around 5G can benefit from an extended use of ONAP with commonalities across operations environments. New business can prosper where infrastructure services evolve as a result ofindustry applications and models on top of ONAP. Key use cases can be found within IoT, connected transportation, immersive technologies such as AR/VR, and other mission critical use cases. Reaching out a wider circle of business opportunities would also promote ONAP as an attractive platform for application developers. 

It is important to maintain a long-term perspective in ONAP that is wider than the original purpose, and gradually engage key stakeholders from other industries to explore future opportunities. History shows that technology with wide commercial prospects is more likely to prevail than one that solely relies on technical supremacy. If successful, it will offer possibilities to accelerate momentum and create a more powerful way to increase the value that telecom networks can bring into the increasingly digital world economy.

Looking forward, we expect ONAP to increasingly act as a force of industry alignment, in synergy with traditional standardization for automation in the OSS. By embracing and leveraging standardized concepts, interfaces and architectures, ONAP will bring vital acceleration to the industry, leading toward one multi-domain automation solution. Ultimately, ONAP's success depends on fruitful developer community collaboration, and an established ecosystem of applications for operation, network and user services. This, in turn, depends on a healthy adoption of ONAP across the industry, to efficiently channel value back to the ecosystem, and create value on top of ONAP. For the foreseeable future we believe that the wider operator community will benefit from ONAP through their vendors with architectural compliance and increasing use of ONAP code in OSS solutions.

1. Open source networking
2. Network automation
3. Cloud infrastructure
4. ONAP Developer Wiki

The contributors to Ericsson's opinion on this topic are Magnus Buhrgard, Stephen Terrill, Balaji Ethirajulu and Patrik Regårdh.