ONAP is no longer a platform, rather it provides various network automation functions, and security reference configuration in LFN.

ONAP provides network automation functions for orchestration, management, and automation of network and edge computing services for network operators, cloud providers, and enterprises. Real-time, policy-driven orchestration and automation of physical, virtual, and cloud native network functions enables rapid automation of new services and complete lifecycle management critical for 5G and next-generation networks.

The ONAP project addresses the need for automation functions for telecommunication, cable, and cloud service providers—and their solution providers—to deliver differentiated network services on demand, profitably and competitively, while leveraging existing investments.

The challenge that ONAP meets is to help network operators keep up with the scale and cost of manual changes required to implement new service offerings, from installing new data center equipment to, in some cases, upgrading on-premises customer equipment. Many are seeking to exploit SDN and NFV to improve service velocity, simplify equipment interoperability and integration, and to reduce overall CapEx and OpEx costs. In addition, the current, highly fragmented management landscape makes it difficult to monitor and guarantee service-level agreements (SLAs). These challenges are still very real now as ONAP creates its eighth release.

ONAP is addressing these challenges by developing global and massive scale (multi-site and multi-VIM) automation capabilities for physical, virtual, and cloud native network elements. It facilitates service agility by supporting data models for rapid service and resource deployment and providing a common set of northbound REST APIs that are open and interoperable, and by supporting model-driven interfaces to the networks. ONAP’s modular and layered nature improves interoperability and simplifies integration, allowing it to support 1) multiple VNF environments by integrating with multiple VIMs, VNFMs, SDN Controllers, as well as legacy equipment (PNF) and 2) Cloud Native environments by integrating Kubernetes, CNFMs and other controllers. The Service Design & Creation (SDC) project also offers seamless orchestration of CNFs. ONAP’s consolidated xNF requirements publication enables commercial development of ONAP-compliant xNFs. This approach allows network and cloud operators to optimize their physical, virtual and cloud native infrastructure for cost and performance; at the same time, ONAP’s use of standard models reduces integration and deployment costs of heterogeneous equipment. All this is achieved while minimizing management fragmentation.

The ONAP allows end-user organizations and their network/cloud providers to collaboratively instantiate network elements and services in a rapid and dynamic way, together with supporting a closed control loop process that supports real-time response to actionable events. In order to design, engineer, plan, bill and assure these dynamic services, there are three major requirements:

  • A robust design framework that allows the specification of the service in all aspects – modeling the resources and relationships that make up the service, specifying the policy rules that guide the service behavior, specifying the applications, analytics and closed control loop events needed for the elastic management of the service

  • An orchestration and control framework (Service Orchestrator and Controllers) that is recipe/ policy-driven to provide an automated instantiation of the service when needed and managing service demands in an elastic manner

  • An analytic framework that closely monitors the service behavior during the service lifecycle based on the specified design, analytics and policies to enable response as required from the control framework, to deal with situations ranging from those that require healing to those that require scaling of the resources to elastically adjust to demand variations.

To achieve this, ONAP decouples the details of specific services and supporting technologies from the common information models, core orchestration components, and generic management engines (for discovery, provisioning, assurance etc.).

Furthermore, it marries the speed and style of a DevOps/NetOps approach with the formal models and processes operators require to introduce new services and technologies. It leverages cloud-native technologies including Kubernetes to manage and rapidly deploy the ONAP and related components. This is in stark contrast to traditional OSS/Management software architectures, which hardcoded services and technologies, and required lengthy software development and integration cycles to incorporate changes.

The ONAP enables service/resource independent capabilities for design, creation and lifecycle management, in accordance with the following foundational principles:

  • Ability to dynamically introduce full service lifecycle orchestration (design, provisioning and operation) and service API for new services and technologies without the need for new software releases or without affecting operations for the existing services

  • Scalability and distribution to support a large number of services and large networks

  • Metadata-driven and policy-driven architecture to ensure flexible and automated ways in which capabilities are used and delivered

  • The architecture shall enable sourcing best-in-class components

  • Common capabilities are ‘developed’ once and ‘used’ many times

  • Core capabilities shall support many diverse services and infrastructures

Further, ONAP comes with a functional architecture with component definitions and interfaces, which provides a force of industry alignment in addition to the open source code.

Architecture Overview

The ONAP architecture consists of a design time and run time functions, as well as functions for managing ONAP itself.

Note: Use the interactive features of the below ONAP Architecture Overview. Click to enlarge it. Then hover with your mouse over an element in the figure for a short description. Click the element to get forwarded to a more detailed description.


Figure 1: Interactive high-level view of the ONAP architecture with its microservices-based components. Click to enlarge and discover.

The figure below provides a simplified functional view of the architecture, which highlights the role of a few key components:

  1. ONAP Design time environment provides onboarding services and resources into ONAP and designing required services.

  2. External API provides northbound interoperability for the ONAP.

  3. ONAP Runtime environment provides a model- and policy-driven orchestration and control framework for an automated instantiation and configuration of services and resources. Multi-VIM/Cloud provides cloud interoperability for the ONAP workloads. Analytic framework that closely monitors the service behavior handles closed control loop management for handling healing, scaling and update dynamically.

  4. OOM provides the ability to manage cloud-native installation and deployments to Kubernetes-managed cloud environments.

  5. ONAP Shared Services provides shared capabilities for ONAP modules. The ONAP Optimization Framework (OOF) provides a declarative, policy-driven approach for creating and running optimization applications like Homing/Placement, and Change Management Scheduling Optimization. The Security Framework uses open-source security patterns and tools, such as Istio, Ingress Gateway, oauth2-proxy, and Keycloak. This Security Framework makes ONAP secure external and inter-component communications, authentication and authorization. Logging Framework (reference implementation PoC) supports open-source- and standard-based logging. It separates application log generation from log collection/aggregation/persistence/visualization/analysis; i.e., ONAP applications handle log generation only and the Logging Framework stack will handle the rest. As a result, operators can leverage/extend their own logging stacks.

  6. ONAP shared utilities provide utilities for the support of the ONAP components.

Microservice BUS (MSB) is obsolete from Montreal release. Its function has been replaced by Istio Service Mesh, Ingress and IdAM (Keycloak) for secure internal and external communications and security authentication and authorization.

Information Model and framework utilities continue to evolve to harmonize the topology, workflow, and policy models from a number of SDOs including ETSI NFV MANO, ETSI/3GPP, O-RAN, TM Forum SID, ONF Core, OASIS TOSCA, IETF, and MEF.


Figure 2. Functional view of the ONAP architecture

Introduction of ONAP Streamlining evolution


Previously, ONAP as a platform had shown e2e network automation to the industry. Operators, vendors and enterprises have learned how service/network automation (modeling, orchestration, policy-based closed loop, optimization, etc.) works on VM and Cloud-native environments for VNF, PNF, CNF, NS, Network/RAN slicing and e2e service thru ONAP. In ONAP, there are numerous valuable use cases, that leverage and coordinate clusters of ONAP component functions (e.g., SDC, SO, A&AI, DCAE, SDNC, SDNR, CPS, CDS…) to achieve objectives, such as:

  • E2E Service

  • Network Slicing

  • RAN Slicing

  • Closed Loop

  • ETSI-based NS & VNF orchestration

  • Helm-based CNF orchestration

  • ASD-based (including Helm) CNF orchestration

Now, the operators, vendors and enterprises want to select and apply ONAP functions to their portfolio. No one needs to take ONAP as a whole.


The goal is to continue to support the current ONAP use cases efficiently for use in commercial production environments and portfolio. We expect the industry wants to pick and choose desired ONAP component functions, swap some of the ONAP functions, and integrate those functions into their portfolio seamlessly, without bringing in a whole ONAP platform. ONAP Streamlining, which drives individual components and clusters of components guided by use cases, will enable the flexible and dynamic function adoption by the industry

ONAP Streamlining Transformation

Thru ONAP Streamlining, ONAP is no longer a platform, rather it provides various network automation functions, and security reference configuration in LFN. ONAP enables individual ONAP function build, and component deployment thru CD. It will build use cases for repository-based E2E service, NS, CNF and CNA onboarding, and CD-based ONAP component triggering mechanism with abstracted interfaces for choreography. It will boost standard-based abstracted interfaces with declarative APIs, i.e., each component will be autonomous and invoked from any level of network automation, by leveraging CD mechanisms, such as GitOps and CD readiness.

ONAP will become more intent-based and declarative, and bring in AI/ML, conforming to standards such as 3GPP, TMForum, ETSI, IETF, O-RAN, etc. For example, UUI user intent support and AI-based natural language translation, on top of that, applying coming 3GPP and TMForum models and APIs. Also, it will delegate resource-level orchestration to functions from the external community, such as O-RAN SC and Nephio.

For security, ONAP continues to support the Service Mesh, Ingress, OAuth2, IdAM-based authentication and authorization, and considers sidecar-less solutions for NF security.


Figure 3. ONAP Streamlining evolution

ONAP Component Design Requirements

  • ONAP components should be designed not only for ONAP but also non-ONAP consumption.

  • ONAP component dependencies and couplings to other ONAP components should not be in an ONAP-specific way.

  • Making each ONAP component should be ‘stand-alone’, so potential users can take a single component, without getting involved in the whole of ONAP.

  • ONAP component interactions should be based on standards and extensible to facilitate integration with other systems, especially for non-ONAP.

  • ONAP component Helm charts in OOM should be re-written to build/deploy a component individually.

  • ONAP Security mechanisms should be industry standard/de facto-based to integrate with vendor/operator security and logging.

  • Timelines and cadence of the ONAP release should be flexible for accommodating different release strategies.

ONAP Component Design, Build & Deployment

ONAP components are independently deployable pieces of software, built out of one more microservices: - Modular - Autonomous - Extensible and substitutional

ONAP Network Automation processes will manage more intent-based operations using AI/ML. - Manage use and other intents and translations - Study on TMForum and 3GPP intent models and APIs

ONAP components conform to the standards and de facto specifications to enable plug- and-play and pick-and-choose facilitation.

ONAP repository-based SW management enables smaller imperative actions that can be triggered by different events in the orchestration and SW LCM flow. Events can trigger different types of deployment automation jobs or chains of automation jobs (pipelines).

In Jenkins ONAP OOM build scripts will be used for ONAP component builds and will store built ONAP components into the Artifact Repository (e.g., Nexus). This can be changed. CD (e.g., ArgoCD, Flux, others) will be used to pick-and-choose ONAP components.


Figure 4. ONAP Streamlining Component Build and Deployment

For more details of ONAP streamlining, see the ONAP Streamlining - The Process page,

Microservices Support

As a cloud-native application that consists of numerous services, ONAP requires sophisticated initial deployment as well as post- deployment management.

ONAP is no longer a platform, rather it provides network automation functions, and security reference configuration in LFN.

Thru ONAP Streamlining evolution, the ONAP deployment methodology has been enhanced, allowing individual ONAP components can be picked up through a chosen CD (Continuous Deployment) tool. This enhancement should be flexible enough to suit the different scenarios and purposes for various operator environments. Users may also want to select a portion of the ONAP components to integrate into their own systems. For more details of ONAP Streamlining evolution, see the ONAP Streamlining evolution session.

The provided ONAP functions are highly reliable, scalable, extensible, secure and easy to manage. To achieve all these goals, ONAP is designed as a microservices-based system, with all components released as Docker containers following best practice building rules to optimize their image size. Numerous optimizations such as shared databases and the use of standardized lightweight container operating systems reduce the overall ONAP footprint.

In the spirit of leveraging the microservice capabilities, further steps towards increased modularity have been taken. Service Orchestrator (SO) and the controllers have increased its level of modularity, by following Microservices.

ONAP Operations Manager (OOM)

The ONAP Operations Manager (OOM) is responsible for orchestrating the end-to-end lifecycle management and monitoring of ONAP components. OOM uses Kubernetes with IPv4 and IPv6 support to provide CPU efficiency and ONAP component deployment. In addition, OOM helps enhance ONAP maturity by providing scalability and resiliency enhancements to the components it manages.

OOM is the lifecycle manager of the ONAP and uses the Kubernetes container management system and Consul to provide the following functionality:

  1. Deployment - with built-in component dependency management (including multiple clusters, federated deployments across sites, and anti-affinity rules)

  2. Configuration - unified configuration across all ONAP components

  3. Monitoring - real-time health monitoring feeding to a Consul GUI and Kubernetes

  4. Restart - failed ONAP components are restarted automatically

  5. Clustering and Scaling - cluster ONAP services to enable seamless scaling

  6. Upgrade - change out containers or configuration with little or no service impact

  7. Deletion - clean up individual containers or entire deployments

OOM supports a wide variety of cloud infrastructures to suit your individual requirements.

OOM provides Service Mesh-based mTLS (mutual TLS) between ONAP components to secure component communications, by leveraging Istio.

In addition to Service Mesh-based mTLS, OOM also provides inter-component authentication and authorization, by leveraging Istio Authorizaiton Policy. For external secure communication, authentication (including SSO) and authorization, OOM configures Ingress, oauth2-proxy, IAM (realized by KeyCloak) and IdP.

As the result, Unmaintained AAF functionalities are obsolete and substituted by Istio-based Service Mesh and Ingress, as of Montreal release.


Figure 5. Security Framework component architecture

For OOM enhancements for ONAP Streamlining evolution, see the ONAP Streamlining evolution section.

Microservices Bus (MSB) - Obsolete


The ONAP MSB project is unmaintained. As of Release 13 ‘Montreal’ the component is no longer part of the ONAP deployment.

Microservices Bus (MSB) used to support service registration/ discovery, external API gateway, internal API gateway, client software development kit (SDK), and Swagger SDK. When integrating with OOM, MSB used to have a Kube2MSB registrar which can grasp services information from k8s metafile and automatically register the services for ONAP components.

In London release, ONAP Security Framework components provide secure communication capabilities. This approach is a more Kubernetes-native approach. As a result, MSB functions has been replaced by the Security Framework, and MSB becomes an optional component.


ONAP had a portal project but this project was terminated and archived. Portal-NG is a new component and fills the gap. It provides a state of the art web-based GUI that services as the first discovery point for the ONAP, its existing web applications and functions. Onboard users with an adaptive GUI following a “grow as you go” approach covering “playful discovery” up to expert mode. Wherever possible hide complexity of network automation by guiding the user. The Portal-NG supports new ONAP Security framework for user administration, authentication and authorization. For more details, see the Portal-NG section.

Design Time Framework

The design time framework is a comprehensive development environment with tools, techniques, and repositories for defining/ describing resources, services, and products.

The design time framework facilitates reuse of models, further improving efficiency as more and more models become available. Resources, services, products, and their management and control functions can all be modeled using a common set of specifications and policies (e.g., rule sets) for controlling behavior and process execution. Process specifications automatically sequence instantiation, delivery and lifecycle management for resources, services, products and the ONAP components themselves. Certain process specifications (i.e., ‘recipes’) and policies are geographically distributed to optimize performance and maximize autonomous behavior in federated cloud environments.

Service Design and Creation (SDC)

Service Design and Creation (SDC) provides tools, techniques, and repositories to define/simulate/certify system assets as well as their associated processes and policies. Each asset is categorized into one of four asset groups: Resource , Services, Products, or Offers. SDC supports the onboarding of Network Services packages (ETSI SOL007 with ETSI SOL001), ONAP proprietary CNF packages (embedding Helm Chart), ASD-based CNF packages (ETSI SOL004 and embedding Helm Chart), VNF packages (Heat or ETSI SOL004) and PNF packages (ETSI SOL004). SDC also includes some capabilities to model 5G network slicing using the standard properties (Slice Profile, Service Template).

Since Kohn-R11 release, SDC supports the onboarding of another CNF-Modeling package, Application Service Description (ASD) package. ASD is a deployment descriptor for cloud native applications/functions. It minimizes information needed for the CNF orchestrator, by referencing most resource descriptions to the cloud native artifacts (e.g., Helm Chart). Its CSAR package adheres to ETSI SOL004.

The SDC environment supports diverse users via common services and utilities. Using the design studio, product and service designers onboard/extend/retire resources, services and products. Operations, Engineers, Customer Experience Managers, and Security Experts create workflows, policies and methods to implement Closed Control Loop Automation/Control and manage elastic scalability.

To support and encourage a healthy VNF ecosystem, ONAP provides a set of VNF packaging and validation tools in the VNF Supplier API and Software Development Kit (VNF SDK) and VNF Validation Program (VVP) components. Vendors can integrate these tools in their CI/CD environments to package VNFs and upload them to the validation engine. Once tested, the VNFs can be onboarded through SDC. In addition, the testing capability of VNFSDK is being utilized at the LFN Compliance Verification Program to work towards ensuring a highly consistent approach to VNF verification. ONAP supports onboarding of CNFs and PNFs as well.

The Policy Creation component deals with policies; these are rules, conditions, requirements, constraints, attributes, or needs that must be provided, maintained, and/or enforced. At a lower level, Policy involves machine-readable rules enabling actions to be taken based on triggers or requests. Policies often consider specific conditions in effect (both in terms of triggering specific policies when conditions are met, and in selecting specific outcomes of the evaluated policies appropriate to the conditions).

Policy allows rapid modification through easily updating rules, thus updating technical behaviors of components in which those policies are used, without requiring rewrites of their software code. Policy permits simpler management / control of complex mechanisms via abstraction.


VNF SDK provides the functionality to create VNF/PNF packages, test VNF packages and VNF ONAP compliance and store VNF/PNF packages and upload to/from a marketplace.


VVP provides validation for the VNF Heat package.

Runtime Components

The runtime execution components execute the rules and policies and other models distributed by the design and creation environment.

This allows for the distribution of models and policy among various ONAP modules such as the Service Orchestrator (SO), Controllers, Data Collection, Analytics and Events (DCAE), Active and Available Inventory (A&AI). These components use common services that support security (access control, secure communication), logging and configuration data.


The Service Orchestrator (SO) component executes the specified processes by automating sequences of activities, tasks, rules and policies needed for on-demand creation, modification or removal of network, application or infrastructure services and resources, this includes VNFs, CNFs and PNFs, by conforming to industry standards such as ETSI, TMF, 3GPP. The SO provides orchestration at a very high level, with an end-to-end view of the infrastructure, network, and applications. Examples of this include BroadBand Service (BBS) and Cross Domain and Cross Layer VPN (CCVPN). The SO is modular and hierarchical to handle services and multi-level resources and Network Slicing, by leveraging pluggable adapters and delegating orchestration operations to NFVO (SO NFVO, VFC), VNFM, CNF Manager, NSMF (Network Slice Management Function), NSSMF (Network Slice Subnet Management Function).

Starting from the Guilin release, the SO provides CNF orchestration support through integration of CNF adapter and other CNF managers in ONAP. SO:

  • Support for provisioning CNFs using an external K8S Manager

  • Support the Helm-based orchestration

  • Leverage the CNF Adapter to interact with the K8S Plugin in MultiCloud, or leverage the CNF Manager to interact with the K8S to control CNFs (e.g., ASD)

  • Bring in the advantage of the K8S orchestrator and

  • Set stage for the Cloud Native scenarios

In London, ONAP SO added ASD-based CNF orchestration support to simplify CNF orchestration and to remove redundancies of CNF resource attributes and orchestration process.

  • Support for onboarding of ASD-based CNF models and packages in runtime

  • Support the SO sub-component ‘SO CNFM’ for ASD-dedicated CNF orchestration to isolate ASD management from other SO components - separation of concerns

  • Use of ASD for AS LCM, and use of associated Helm Charts for CNF deployment to the selected external K8s Clusters

  • Use of Helm Client to communicate with external K8S clusters for CNF deployment

  • Monitoring deployed K8S resources thru Kubernetes APIs

3GPP (TS 28.801) defines three layer slice management function which include:

  • CSMF (Communication Service Management Function)

  • NSMF (Network Slice Management Function)

  • NSSMF (Network Slice Subnet Management Function)

To realize the three layers, CSMF, NSMF and/or NSSMF are realized within ONAP, or use the external CSMF, NSMF or NSSMF. For ONAP-based network slice management, different choices can be made as follows. Among them, ONAP orchestration currently supports options #1 and #4.


Figure 6: ONAP Network Slicing Support Options

Virtual Infrastructure Deployment (VID) - obsolete


The ONAP vid project is unmaintained. As of Release 12 ‘London’ the component is no longer part of the ONAP deployment.

The Virtual Infrastructure Deployment (VID) application enables users to instantiate infrastructure services from SDC, along with their associated components, and to execute change management operations such as scaling and software upgrades to existing VNF instances.

Policy-Driven Workload Optimization

The ONAP Optimization Framework (OOF) provides a policy-driven and model-driven framework for creating optimization applications for a broad range of use cases. OOF Homing and Allocation Service (HAS) is a policy driven workload optimization service that enables optimized placement of services across multiple sites and multiple clouds, based on a wide variety of policy constraints including capacity, location, other service capabilities and constraints.

ONAP Multi-VIM/Cloud (MC) and several other ONAP components such as Policy, SO, A&AI etc. play an important role in enabling “Policy-driven Performance/ Security-Aware Adaptive Workload Placement/ Scheduling” across cloud sites through OOF-HAS. OOF-HAS uses cloud agnostic Intent capabilities, and real-time capacity checks provided by ONAP MC to determine the optimal VIM/Cloud instances, which can deliver the required performance SLAs, for workload (VNF, etc.) placement and scheduling (Homing). Operators now realize the true value of virtualization through fine grained optimization of cloud resources while delivering performance and security SLAs.


Controllers are applications which are coupled with cloud and network services and execute the configuration, real-time policies, and control the state of distributed components and services. Rather than using a single monolithic control layer, operators may choose to use multiple distinct controller types that manage resources in the execution environment corresponding to their assigned controlled domain such as cloud computing resources (SDN-C). The Virtual Function Controller (VF-C) and SO NFVO provide an ETSI NFV compliant NFVO function that is responsible for lifecycle management of virtual services and the associated physical COTS server infrastructure. VF-C provides a generic VNFM capability, and both VF-C and SO NFVO integrate with external VNFMs and VIMs as part of an NFV MANO stack.


The ONAP appc project is unmaintained. As of Release 12 ‘London’ the component is no longer part of the ONAP deployment.

ONAP used to have two application level configuration and lifecycle management modules called SDN-C and App-C. App-C is no longer part of ONAP deployment. SDN-C provides controller services (application level configuration using NetConf, Chef, Ansible, RestConf, etc.) and lifecycle management functions (e.g., stop, resume, health check, etc.). SDN-C uses common code from CCSDK repo, and it uses CDS only for onboarding and configuration / LCM flow design. SDN-C has been used for Layer1-7 network elements. ONAP Controller configures and maintains the health of L1-7 Network Function (VNF, PNF, CNF) and network services throughout their lifecycle:

  • Configures Network Functions (VNF/PNF)

  • Provides programmable network application management:

    • Behavior patterns programmed via models and policies

    • Standards based models & protocols for multi-vendor implementation

    • Extensible SB adapters such as Netconf, Ansible, Rest API, etc.

    • Operation control, version management, software updates, etc.

  • Local source of truth - Manages inventory within its scope - Manages and stores state of NFs - Supports Configuration Audits

Controller Design Studio (CDS)

The Controller Design Studio (CDS) community in ONAP has contributed a framework to automate the resolution of resources for instantiation and any config provisioning operation, such as day0, day1 or day2 configuration. The essential function of CDS is to create and populate a controller blueprint, create a configuration file from this Controller blueprint, and associate at design time this configuration file (configlet) to a PNF/VNF/CNF during the design phase. CDS removes dependence on code releases and the delays they cause and puts the control of services into the hands of the service providers. Users can change a model and its parameters with great flexibility to fetch data from external systems (e.g., IPAM) that is required in real deployments. This makes service providers more responsive to their customers and able to deliver products that more closely match the needs of those customers.


Active and Available Inventory (A&AI) provides real-time views of a system’s resources, services, products and their relationships with each other, and also retains a historical view. The views provided by A&AI relate data managed by multiple ONAP instances, Business Support Systems (BSS), Operation Support Systems (OSS), and network applications to form a “top to bottom” view ranging from the products end users buy, to the resources that form the raw material for creating the products. A&AI not only forms a registry of products, services, and resources, it also maintains up-to-date views of the relationships between these inventory items.

To deliver the promised dynamism of SDN/NFV, A&AI is updated in real time by the controllers as they make changes in the network environment. A&AI is metadata-driven, allowing new inventory types to be added dynamically and quickly via SDC catalog definitions, eliminating the need for lengthy development cycles.

Policy Framework

The Policy framework provides policy based decision making capability and supports multiple policy engines and can distribute policies through policy design capabilities in SDC, simplifying the design process.

Multi Cloud Adaptation

Multi-VIM/Cloud provides and infrastructure adaptation layer for VIMs/Clouds and K8s clusters in exposing advanced cloud agnostic intent capabilities, besides standard capabilities, which are used by OOF and other components for enhanced cloud selection and SO/VF-C for cloud agnostic workload deployment. The K8s plugin is in charge of deploying CNFs on the Kubernetes clusters using Kubernetes APIs.

Data Collection Analytics and Events (DCAE)

DCAE provides the capability to collect events, and host analytics applications (DCAE Services)

Closed Control Loop Automation Management Platform in Policy (Policy - CLAMP)


The ONAP CLAMP function is now part of Policy.

Closed loop control is provided by cooperation among a number of design-time and run-time elements. The Runtime loop starts with data collectors from Data Collection, Analytics and Events (DCAE). ONAP includes the following collectors : VES (VNF Event Streaming) for events, HV-VES for high-volume events, SNMP for SNMP traps, File Collector to receive files, and RESTCONF Collector to collect the notifications. After data collection/verification phase, data move through the loop of micro-services like Homes for event detection, Policy for determining actions, and finally, controllers and orchestrators to implement actions. The Policy framework is also used to monitor the loops themselves and manage their lifecycle. DCAE also includes a number of specialized micro-services to support some use-cases such as the Slice Analysis or SON-Handler. Some dedicated event processor modules transform collected data (SNMP, 3GPP XML, RESTCONF) to VES format and push the various data into data lake. CLAMP, Policy and DCAE all have design time aspects to support the creation of the loops.

We refer to this automation pattern as “Closed Control loop automation” in that it provides the necessary automation to proactively respond to network and service conditions without human intervention. A high-level schematic of the “Closed control loop automation” and the various phases within the service lifecycle using the automation is depicted in Figure 4.

Closed control loop control is provided by Data Collection, Analytics and Events (DCAE) and one or more of the other ONAP runtime components. Collectively, they provide FCAPS (Fault Configuration Accounting Performance Security) functionality. DCAE collects performance, usage, and configuration data; provides computation of analytics; aids in troubleshooting; and publishes events, data and analytics (e.g., to policy, orchestration, and the data lake). Another component, Holmes, connects to DCAE and provides alarm correlation for ONAP, new data collection capabilities with High Volume VES, and bulk performance management support.

Working with the Policy Framework (and embedded CLAMP), these components detect problems in the network and identify the appropriate remediation. In some cases, the action will be automatic, and they will notify the Service Orchestrator or one of the controllers to take action. In other cases, as configured by the operator, they will raise an alarm but require human intervention before executing the change. The policy framework is extended to support additional policy decision capabilities with the introduction of adaptive policy execution.

Starting with the Honolulu-R8 and concluding in the Istanbul-R9 release, the CLAMP component was successfully integrated into the Policy component initially as a PoC in the Honolulu-R8 release and then as a fully integrated component within the Policy component in Istanbul-R9 release. CLAMP’s functional role to provision Policy has been enhanced to support provisioning of policies outside of the context of a Control Loop and therefore act as a Policy UI. In the Istanbul release the CLAMP integration was officially released.


Figure 7: ONAP Closed Control Loop Automation

Virtual Function Controller (VFC)

VFC provides the NFVO capability to manage the lifecycle of network service and VNFs, by conforming to ETSI NFV specification.

Data Movement as a Platform (DMaaP)

DMaaP provides data movement service such as message routing and data routing.

Use Case UI (UUI)

UUI provides the capability to instantiate the blueprint User Cases and visualize the state.


ONAP CLI provides a command line interface for access to ONAP.

External APIs


The ONAP externalapi project is unmaintained.

External APIs provide services to expose the capability of ONAP.

Shared Services

ONAP provides a set of operational services for all ONAP components including activity logging, reporting, common data layer, configuration, persistence, access control, secret and credential management, resiliency, and software lifecycle management.

ONAP Shared Services provide shared capabilities for ONAP modules. These services handle access management and security enforcement, data backup, configuration persistence, restoration and recovery. They support standardized VNF interfaces and guidelines.

Optimization Framework (OOF)

OOF provides a declarative, policy-driven approach for creating and running optimization applications like Homing/Placement, and Change Management Scheduling Optimization.

Security Framework

The Security Framework uses open-source security patterns and tools, such as Istio, Ingress Gateway, oauth2-proxy, and KeyCloak. This Security Framework provides secure external and inter-component communications, authentication, and authorization.

Logging Framework (PoC)


The ONAP Logging Framework project is a reference implementation PoC.

Logging Framework supports open-source and standard-based logging. It separates the application log generation from the log collection/aggregation/persistence/ visualization/analysis; i.e., ONAP applications handle log generation only, and the Logging Framework stack will handle the rest. As a result, operators can leverage/extend their own logging stacks.

Configuration Persistence Service (CPS)

The Configuration Persistence Service (CPS) provides storage for real-time run-time configuration and operational parameters that need to be used by ONAP. Several services ranging from SDN-C, DCAE and the network slicing use case utilize CPS for these purposes. In Montreal release, a CPS sub-component CPS- Temporal is removed because its function is no longer needed. Its details in CPS - Configuration Persistence Service.

ONAP Modeling

ONAP provides models to assist with service design, the development of ONAP service components, and with the improvement of standards interoperability. Models are an essential part for the design time and runtime framework development. The ONAP modeling project leverages the experience of member companies, standard organizations and other open source projects to produce models which are simple, extensible, and reusable. The goal is to fulfill the requirements of various use cases, guide the development and bring consistency among ONAP components and explore a common model to improve the interoperability of ONAP.

ONAP supports various models detailed in the Modeling documentation.

A new CNF modeling descriptor, Application Service Description (ASD), has been added to ONAP since the Kohn release. It is to simplify CNF modeling and orchestration by delegating resource modeling to Kubernetes-based resource descriptors (e.g., Helm Chart).

The modeling project includes the ETSI catalog component, which provides the parser functionalities, as well as additional package management functionalities.

Industry Alignment

ONAP support and collaboration with other standards and open source communities is evident in the architecture.

  • MEF and TMF interfaces are used in the External APIs

  • In addition to the ETSI-NFV defined VNFD and NSD models mentioned above, ONAP supports the NFVO interfaces (SOL005 between the SO and VFC, SOL003 from either the SO or VFC to an external VNFM).

  • Further collaboration includes 5G/ORAN & 3GPP Harmonization, Acumos DCAE Integration, and CNCF Telecom User Group (TUG).

Read this whitepaper for more information: The Progress of ONAP: Harmonizing Open Source and Standards

ONAP Blueprints

ONAP can support an unlimited number of use cases, within reason. However, to provide concrete examples of how to use ONAP to solve real-world problems, the community has created a set of blueprints. In addition to helping users rapidly adopt the ONAP through end-to-end solutions, these blueprints also help the community prioritize their work.

5G Blueprint

The 5G blueprint is a multi-release effort, with five key initiatives around end-to-end service orchestration, network slicing, PNF/VNF lifecycle management , PNF integration, and network optimization. The combination of eMBB that promises peak data rates of 20 Mbps, uRLLC that guarantees sub-millisecond response times, MMTC that can support 0.92 devices per sq. ft., and network slicing brings with it some unique requirements. First ONAP needs to manage the lifecycle of a network slice from initial creation/activation all the way to deactivation/termination. Next, ONAP needs to optimize the network around real time and bulk analytics, place VNFs on the correct edge cloud, scale and heal services, and provide edge automation. ONAP also provides self organizing network (SON) services such as physical cell ID allocation for new RAN sites. These requirements have led to the five above-listed initiatives and have been developed in close cooperation with other standards and open source organizations such as 3GPP, TM Forum, ETSI, and O-RAN Software Community.


Figure 8. End-to-end 5G Service

Read the 5G Blueprint to learn more.

A related activity outside of ONAP is called the 5G Super Blueprint where multiple Linux Foundation projects are collaborating to demonstrate an end-to-end 5G network. In the short-term, this blueprint will showcase three major projects: ONAP, Anuket (K8S NFVI), and Magma (LTE/5GC).


Figure 9. 5G Super Blueprint Initial Integration Activity

In the long-term, the 5G Super Blueprint will integrate O-RAN-SC and LF Edge projects as well.

Residential Connectivity Blueprints

Two ONAP blueprints (vCPE and BBS) address the residential connectivity use case.

Virtual CPE (vCPE)

Currently, services offered to a subscriber are restricted to what is designed into the broadband residential gateway. In the blueprint, the customer has a slimmed down physical CPE (pCPE) attached to a traditional broadband network such as DSL, DOCSIS, or PON (Figure 6). A tunnel is established to a data center hosting various VNFs providing a much larger set of services to the subscriber at a significantly lower cost to the operator. In this blueprint, ONAP supports complex orchestration and management of open source VNFs and both virtual and underlay connectivity.


Figure 10. ONAP vCPE Architecture

Read the Residential vCPE Use Case with ONAP blueprint to learn more.

Broadband Service (BBS)

This blueprint provides multi-gigabit residential internet connectivity services based on PON (Passive Optical Network) access technology. A key element of this blueprint is to show automatic re-registration of an ONT (Optical Network Terminal) once the subscriber moves (nomadic ONT) as well as service subscription plan changes. This blueprint uses ONAP for the design, deployment, lifecycle management, and service assurance of broadband services. It further shows how ONAP can orchestrate services across different locations (e.g. Central Office, Core) and technology domains (e.g. Access, Edge).


Figure 11. ONAP BBS Architecture

Read the Residential Connectivity Blueprint to learn more.

Voice over LTE (VoLTE) Blueprint

This blueprint uses ONAP to orchestrate a Voice over LTE service. The VoLTE blueprint incorporates commercial VNFs to create and manage the underlying vEPC and vIMS services by interworking with vendor-specific components, including VNFMs, EMSs, VIMs and SDN controllers, across Edge Data Centers and a Core Data Center. ONAP supports the VoLTE use case with several key components: SO, VF-C, SDN-C, and Multi-VIM/ Cloud. In this blueprint, SO is responsible for VoLTE end-to-end service orchestration working in collaboration with VF-C and SDN-C. SDN-C establishes network connectivity, then the VF-C component completes the Network Services and VNF lifecycle management (including service initiation, termination and manual scaling) and FCAPS (fault, configuration, accounting, performance, security) management. This blueprint also shows advanced functionality such as scaling and change management.


Figure 12. ONAP VoLTE Architecture Open Network Automation

Read the VoLTE Blueprint to learn more.

Optical Transport Networking (OTN)

Two ONAP blueprints (CCVPN and MDONS) address the OTN use case. CCVPN addresses Layers 2 and 3, while MDONS addresses Layers 0 and 1.

CCVPN (Cross Domain and Cross Layer VPN) Blueprint

CSPs, such as CMCC and Vodafone, see a strong demand for high-bandwidth, flat, high-speed OTN (Optical Transport Networks) across carrier networks. They also want to provide a high-speed, flexible and intelligent service for high-value customers, and an instant and flexible VPN service for SMB companies.


Figure 13. ONAP CCVPN Architecture

The CCVPN (Cross Domain and Cross Layer VPN) blueprint is a combination of SOTN (Super high-speed Optical Transport Network) and ONAP, which takes advantage of the orchestration ability of ONAP, to realize a unified management and scheduling of resources and services. It achieves cross-domain orchestration and ONAP peering across service providers. In this blueprint, SO is responsible for CCVPN end-to-end service orchestration working in collaboration with VF-C and SDN-C. SDN-C establishes network connectivity, then the VF-C component completes the Network Services and VNF lifecycle management. ONAP peering across CSPs uses an east-west API which is being aligned with the MEF Interlude API. CCVPN, in conjunction with the IBN use case, offers intent based cloud leased line service. The key innovations in this use case are physical network discovery and modeling, cross-domain orchestration across multiple physical networks, cross operator end-to-end service provisioning, close-loop reroute for cross-domain service, dynamic changes (branch sites, VNFs) and intelligent service optimization (including AI/ML).

Read the CCVPN Blueprint to learn more.

MDONS (Multi-Domain Optical Network Service) Blueprint

While CCVPN addresses the automation of networking layers 2 and 3, it does not address layers 0 and 1. Automating these layers is equally important because providing an end-to-end service to their customers often requires a manual and complex negotiation between CSPs that includes both the business arrangement and the actual service design and activation. CSPs may also be structured such that they operate multiple networks independently and require similar transactions among their own networks and business units in order to provide an end-to-end service. The MDONS blueprint created by AT&T, Orange, and Fujitsu solves the above problem. MDONS and CCVPN used together can solve the OTN automation problem in a comprehensive manner.


Figure 14. ONAP MDONS Architecture

Intent Based Network (IBN) Use Case

Intent technology can reduce the complexity of management without getting into the intricate details of the underlying network infrastructure and contribute to efficient network management. This use case performs a valuable business function that can further reduce the operating expenses (OPEX) of network management by shifting the paradigm from complex procedural operations to declarative intent-driven operations.


Figure 15. ONAP Intent-Based Networking Use Case

3GPP 28.812, Intent driven Management Service (Intent driven MnS), defines some key concepts that are used by this initiative. The Intent Based Networking (IBN) use case includes the development of an intent decision making. This use case has initially been shown for a smart warehouse, where the intent is to increase the output volume of automated guided vehicles (AVG) and the network simply scales in response. The intent UI is implemented in UUI and the components of the intent framework interact with many components of ONAP including SO, A&AI, Policy, DCAE and CDS.

vFW/vDNS Blueprint

The virtual firewall, virtual DNS blueprint is a basic demo to verify that ONAP has been correctly installed and to get a basic introduction to ONAP. The blueprint consists of 5 VNFs: vFW, vPacketGenerator, vDataSink, vDNS and vLoadBalancer. The blueprint exercises most aspects of ONAP, showing VNF onboarding, network service creation, service deployment and closed-loop automation. The key components involved are SDC, CLAMP, SO, APP-C, DCAE and Policy. In the recent releases, the vFW blueprint has been demonstrated by using a mix of a CNF and VNF and entirely using CNFs.

Verified end to end tests

Use cases

Various use cases have been tested for the Release. Use case examples are listed below. See detailed information on use cases, functional requirements, and automated use cases can be found here: Verified Use Cases.

  • E2E Network Slicing

  • 5G OOF (ONAP Optimization Framework) SON (Self-Organized Network)

  • CCVPN-Transport Slicing

Functional requirements

Various functional requirements have been tested for the Release. Detailed information can be found in the Verified Use Cases.

  • xNF Integration

    • ONAP CNF orchestration - Enhancements

    • ONAP ASD-based CNF orchestration

    • PNF PreOnboarding

    • PNF Plug & Play

  • Lifecycle Management

    • Policy Based Filtering

    • Bulk PM / PM Data Control Extension

    • Support xNF Software Upgrade in association to schema updates

    • Configuration & Persistency Service

  • Security

    • CMPv2 Enhancements

  • Standard alignment

    • ETSI-Alignment for Guilin

    • ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over VES

    • Extend ORAN A1 Adapter and add A1 Policy Management

  • NFV testing Automation

    • Support for Test Result Auto Analysis & Certification

    • Support for Test Task Auto Execution

    • Support for Test Environment Auto Deploy

    • Support for Test Topology Auto Design


The ONAP provides a comprehensive functions for real-time, policy- driven orchestration and automation of physical and virtual network functions that will enable software, network, IT and cloud providers and developers to rapidly automate new services and support complete lifecycle management.

By unifying member resources, ONAP will accelerate the development of a vibrant ecosystem around a globally shared architecture and implementation for network automation —with an open standards focus— faster than any one product could on its own.


See the Resources page on