Skip to end of banner
Go to start of banner

ONAP consumption models whitepaper - Consumption model section

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »


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 ?


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 ModelProsConsExamples

    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 -
      1. Either be developed in house or
      2. An external System Integrator / Principal Vendor can do it for CSPs
      3. 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



  • No labels