ONAP consumption models whitepaper - Consumption model section

Section 3 of white paper :

Consumption Model

Section Contributors : AT&T (Brian Freeman, Scott Blandford ), Bell Canada (Marc-Alexandre Choquette), Vodafone (Atul Purohit), China Mobile (Lei Huang)

From an end user perspective, within the CSP – what are the key considerations, methods for adoption (technical, organizational, operational, etc…)

Reference Models for Consumption

Plan :

• AT&T & Bell to share the model that they are using (Publically sharable), format 1 page bullet points & preferably a diagram (Editable, so that MAC can change as per standard format)
• Vodafone to share the possible variants / models that are there in total (with examples), which will form part of beginning of the section (with a diagram for each option)
• We need within a CSP roles, parts of the organization that will consume ONAP - ops, technical teams etc...and relevance / consideration points for consuming ONAP (here the points can be generic, ONAP can come in to address them)
• China Mobile can help with pros - cons of various models, what works what requires work, various considerations around it
• Anything else ?

How to consume ONAP in organizations

The Future services of a Digital Communication Providers will be principally very different from those existing today.

Understanding of those requirements are fundamental to enable service providers and businesses to develop, deploy and scale next-generation networks and services.

The future services delivery must be automated, flexible and reliable that can scale massively with out any coupling with the underlying infrastructure.

It is for these reasons that ONAP has gained lot of traction in the recent years delivering value to end users through service delivery simplification, cost reduction and agile services creation on the fly.

Many CSPs & active members of ONAP project are now experiencing and learning to use and integrate the “whole ONAP Stack ” in their existing environments.

Physical, virtual and software defined networks will coexist for the foreseeable future, key services needs to be created across modern and legacy networks and ONAP has to be able to inter-work with legacy network, EMS / NMS, OSS / BSS systems to deploy services across the hybrid networks; while also utilizing private and public cloud capabilities. 

Starting from key use cases to deliver quick value, ONAP's final target is to act as end to end global service management platform to design and deliver services and to operate the hybrid network across data centers in an efficient manner i.e. to enable a 2-sided platforms model. 

Considering the early experience of 5G by communication providers, it is clear that the future use cases are more pronounced in industry verticals and in enabling other adjacencies which are part of "Now Economy" ecosystem.

Such a capability requires a platforms play, for which ONAP seems to cater to quite well. While many operators embrace & participate in creation of capabilities in and around ONAP and considers it to be a key reference architecture to evolve towards; there has not been a very wide-spread adoption of ONAP so far. 

There are multiple options that CSPs should consider while thinking to integrating ONAP into their existing environments, some such considerations are : ( >>Lei : These cosideration options may need specify and more descriptions)

• Integrated solutions with carrier-grade versions of individual ONAP modules
• Service models, applications and micro-services built to run in ONAP environments
• Compliant networking infrastructure (physical/virtual), including PNFs, VNFs, domain controllers, etc. that can plug into ONAP
• Operational changes which are required to run and manage ONAP
• Set of developers, testers and designers required to deliver & operate services though ONAP
• Ensuring ONAP is a secure product by design and striking a fine balance between services they want on ONAP while keeping ONAP on the current version of release
• and many such unknowns 

It could be complex to introduce ONAP into an existing service provider environment, the challenge will be not just to manage this incremental shift towards adopting ONAP modules / components but also in having them co-exist with existing management systems.

ONAP definitely shows promises in parts, consider the fact that ONAP framework is reusable and its capabilities for management and operations viz. automation, AI/ML, adaptive policy, information models, service orchestration are candidates for future use in service models and use cases which can be enabled in other industry verticals as well.

ONAP integration in a production environment

Since the release of ONAP first commercial release Amsterdam in 2017 the community has progressed a lot to cover wide range of integration and use case requirements.

However, the modular nature of ONAP has worried operators with no rich R&D and software development capabilities.

Certainly, this perception of complexity and too much open is a major hindrance in ONAP wide adoption.

Taking a holistic view of future varying business needs and a solution that can scale and serve different verticals requires a solution that is modular and layered.

This will allow CSPs to describe/integrate every single component of a service within the platform itself and to define custom business process models to orchestrate the service deployment.

The modular way is definitely the right approach to meet the requirements of many CSPs (especially in brownfield situations, which many of the providers are in) that have in their network a high level of legacy and industry standard dependencies.

Imagining various service providers set up scenarios, if we can define ONAP's integration evolution to address this integration conundrum, this should address inter-operability across EMS, NMS, OSS as well as the BSS; and this is the path of least resistance to increase the adoption and presence of ONAP platform.

( >>Lei : We think SDO is not very relevant to production environment, maybe we could consider move this content into other chapter.  LFN white paper have some info about ONAP and  SDOs , which could be a reference. )

Several CSPs have a strong dependency on standard solutions and it is usually a common strategy for a collaborative network (Ex - 3GPP compliant solutions or GSMA aligned specifications); SDOs can assist with architecture, quality and inter-operability of Open Source projects, as well as enhance the overall vitality of the mobile value chain.

[[[[[ Identify ONAP v/s SDO relationship diagram ]]]]]

Therefore ONAP has to take into consideration its integration also with other SDOs especially with 3GPP, ETSI ISGs (NFV, ENI, ZSM), TM Forum and MEF and with Open Communities too.

ONAP community is aware of the importance of this collaboration and it is doing the best to keep alignment and coordination. Indeed the following picture developed by LFN provides an overview of current landscape and relationship among Open Source Projects and SDOs:

Having said this the end user community believes that still there is a requirement to benchmark and define standard MVP products for Telco’s to select their vendors.

It is because the early adoption of ONAP in Carrier networks proved that engineered solutions from vendors are not aligned with ONAP framework and cannot deliver long term value consider unique business requirements and use cases in the 5G and Edge service era .

Following this approach is the best direction and will enable industry as a whole to select and combine different solutions and modules from different vendors in the ONAP framework achieving agility, efficiency and robustness required for future network services.

Quick wins and Commercial models for ONAP

As is the case with all new technology’s adoption, we should define the MVP and how much is enough capabilities for ONAP based on use cases to drive a positive business case . This will allow to define different flavors of ONAP depending on adoption level , organization maturity and business drivers for transformation.

As a matter of fact Defining the phases of ONAP adoption is vital for an innovative initiative like ONAP , ONAP EUAG community believes Telco’s should start a journey bottom up to solve integration and interworking issues of South bound and NE’s with ONAP first . It should be followed by global SO initiative to orchestrate and deliver services across operators foot prints  crossing  the boundaries and final value creation should be operational efficiency combine by value addition using new innovations like ML and AI in the networking industry .

ONAP with its Dublin release, delivered on July 2019, showed both the growth of many technical accomplishments and a better maturity of ONAP Community especially in terms of relationship between carriers and vendors that have demonstrated strong cooperation in many areas, like development, security , testing and integration.  This is the best way to ensure a commercial deployment of ONAP solution where CSPs provide their requirements and vendors help them in the implementation and integration.

Since the release of ONAP first commercial release Amsterdam in 2017 the community has progressed a lot to cover wide range of integration and use case requirements. However, the modular nature of ONAP has worried Telco operators who has no rich R&D and development capabilities. Certainly, this perception of complexity and too much open is a major hindrance in ONAP wide adoption.

However taking a holistic view of future varying business needs and a solution that can scale and serve different verticals requires a solution that is modular and layered  that will allow CSPs to describe/integrate every single component of a service within the platform itself and to define custom business process models to orchestrate the service deployment. The modular way is the right approach

To support both the consumption and integration of ONAP in the Telco environment it is important to define the reference models for consumption as will be described in the following sections

We need 2 breakout calls between 4 of us before next meeting i.e. on 19th November. Ideally a 4-5 pager section 3 should be ready (Draft) by then.

Also look for Saad's initial view, useful areas can be incorporated here

• Vodafone to share the possible variants / models that are there in total (with examples), which will form part of beginning of the section (with a diagram for each option)

1. A project like ONAP can be consumed within a CSP in multiple ways -
   1. Build competency & deliver ONAP in-house
   2. Engage with a system integrator / principal who can do it for them
   3. Look for distribution by professional outfits
   4. Look at ONAP as a reference implementation, and choose a partner/vendor which does similar or all of the same functionalities

2. Below table provides pros & cons of each model

   ONAP Consumption Model	Pros	Cons	Examples
   Build competency & deliver ONAP in-house	CSPs are in complete control of the code ONAP out of the box functionality is not suited, CSPs can customize / enhance / change it CSPs becomes more software culture oriented CSPs will have to be much more involved in forum & exchange of information, contributions, involvements increase	Identifying software capabilities & building teams takes time & effort Mind-Set change is the biggest impediment Operating model (in-fact entire organizational construct) needs changing, which may be challenging	AT&T, Bell Canada (any other ?)
   Engage with a System Integrator / Principal Vendor who can do it for them	This is an outsourced model, where an identified System Integrator / Principal Vendor takes the ownership of development, testing & deployment - means CSPs are still in control, but are doing it in a "Delegated" mode Risk of delivery problems reduces, since professional System Integrators / Principal Vendors does "Delivery" for a living, they are more mature by design	CSPs have to keep track of changes, identify possible enhancements, requirements and get them delivered via identified System Integrator / Principal Vendor Complacency may creep in if the "Delegated" partners are doing most of the heavy lifting - CSPs may becomes too dependent	Amdocs, Accenture (any one else ?)
   Look for distribution by professional outfits	Similar to OpenStack distributions which are out there, ONAP can potentially have "Distro" professional outfits - who would provide a hardened (tested, fit for purpose) and well maintained software asset - which can then be - Either be developed in house or An external System Integrator / Principal Vendor can do it for CSPs Or, the "Distro" providing professional outfit can do it as part of their "Professional" services Onus of keeping up with forum's workings, bug fixes in "Productized" version of ONAP etc...can be taken care by "Distribution" Professional Outfit	If chosen delivery option is not the same as the professional outfit, friction in delivery may creep in Wholesome commitment of professional outfit to ONAP may need some monitoring	Aarna Networks ( ?) Anyone else ?
   Look at ONAP as a reference implementation, and choose a partner/vendor which does similar or all of the same functionalities	There are multiple SDOs that ONAP adheres to, For Ex - TMF, 3GPP, ETSI, GSMA etc..., this model absolves CSPs from asking ala-carte SDO compliance to vendors while choosing their products; and instead place ONAP as a reference-able architecture (& for compliance) in front of vendors and get a product that best complies to standards Depending on the chosen vendor, strengths of the vendor and up-keep of the application is complete owned by the vendor	Software culture does not kick in Dependency on vendor still high	Many

On 4 model diagrams, use a tablet to scribble and create a sketch, we will request MAC artists to help with appropriate diagrams / AP on Atul