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 :
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)
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.
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.
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
Below table provides pros & cons of each model
| ONAP Consumption Model | Pros | Cons | Examples |
|---|---|---|---|
Build competency & deliver ONAP in-house |
|
| AT&T, Bell Canada (any other ?) |
Engage with a System Integrator / Principal Vendor who can do it for them |
|
| Amdocs, Accenture (any one else ?) |
Look for distribution by professional outfits |
|
| 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 |
|
| 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