path: root/docs/ecosystem/architecture/index.rst

.. This work is licensed under a Creative Commons Attribution
.. 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. Copyright 2017-2018 Huawei Technologies Co., Ltd.
.. Copyright 2019 ONAP Contributors
.. Copyright 2020 ONAP Contributors
.. Copyright 2021 ONAP Contributors
.. Copyright 2022 ONAP Contributors
.. Copyright 2023 ONAP Contributors
.. Copyright 2024 ONAP Contributors
.. Copyright 2025 ONAP Contributors

.. _ONAP-architecture:

Architecture
============
ONAP is a collection of Network Automation functions, including orchestration,
management, and automation of network and edge computing services for network
operators, cloud providers, and enterprises. Its real-time, policy-driven
orchestration and automation of physical, virtual, and cloud native network
functions enable rapid deployment of new services and comprehensive lifecycle
management. These capabilities are critical for 5G and next-generation networks,
enhanced by genAI/ML.

The ONAP projects address the growing need for common network automation
functions among telecommunication, cable, and cloud service providers, along
with their solution providers. They enable the delivery of differentiated network
services on demand, profitably and competitively, while maximizing existing
investments.

The challenge that ONAP addresses is helping network operators manage the scale
and cost of manual changes required to implement new service offerings-ranging
from installing new data center equipment to, in some cases, upgrading
on-premises customer equipment. Many operators aim to leverage SDN and NFV to
accelerate service delivery, simplify equipment interoperability and integration,
and reduce overall CapEx and OpEx costs. Furthermore, the highly fragmented
management landscape makes it challenging to monitor and guarantee
service-level agreements (SLAs).

ONAP addresses these challenges by developing global and large-scale (multi-site
and multi-VIM/multi-Cloud) automation capabilities for physical, virtual, and
cloud-native network elements. It enhances service agility by supporting
data models for rapid service and resource deployment, and offering a common
set of northbound REST APIs, enabling model-driven interfaces to the networks.

ONAP's modular and layered architecture improves interoperability and simplifies
integration, allowing it to support multiple VNF environments by integrating with
various and multiple VIMs, VNFMs, SDN Controllers, and legacy equipment (PNF).
The Service Design & Creation (SDC) project further enables seamless orchestration
of CNFs. Additionally, ONAP's consolidated xNF requirements publication facilitates
the 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 the integration and deployment costs of heterogeneous
equipment-all while minimizing minimizing management fragmentation.

The ONAP enables end-user organizations and their network or cloud providers to
collaboratively instantiate network elements and services in a rapid and dynamic
manner. It also supports a closed control loop process, enabling real-time response
to actionable events. To design, engineer, plan, bill and assure these dynamic services,
three major requirements must be met:

- A robust design function that enables the comprehensive specification of the service,
  including modeling the resources and relationships that constitute the service,
  defining the policy rules guiding the service behavior, specifying the applications,
  analytics and closed control loop events for the elastic management of the service
- An orchestration and control function (Service Orchestrator and Controllers) that
  operates in a recipe- and policy-driven manner to automate service instantiation
  as needed, while dynamically and elastically managing service demands
- An analytic function that continuously monitors the service behavior throughout the
  service lifecycle, using the specified design, analytics and policies. It enables
  the control framework to respond as needed, addressing situations ranging from
  healing issues to scaling resources to accommodate demand variations

To achieve this, ONAP separates the specifics of individual services and supporting
technologies from the common information models, core orchestration platform,
and generic management engines (e.g., for discovery, provisioning, assurance).

Furthermore, it combines the speed and flexibility of a DevOps/NetOps approach with
the formal models and processes required by operators to introduce new services and
technologies. It leverages cloud-native technologies, including Kubernetes, to
manage and rapidly deploy the ONAP functionalities and related components. This
approach contrasts sharply with traditional OSS/Management software platform
architectures, which relied on hardcoded services and technologies and required
lengthy software development and integration cycles to accommodate changes.

The ONAP network automation provides service- and resource-independent capabilities
for design, creation, and lifecycle management, adhering to the following
foundational principles:

- Ability to dynamically introduce full-service lifecycle orchestration (design,
  provisioning and operation) and service APIs for new services and technologies
  without requiring new platform software releases or disrupting operations for the
  existing services
- Scalability and distribution designed to support a large number of services and
  extensive networks
- A metadata-driven and policy-driven architecture that ensures the flexible and
  automated utilization and delivery of capabilities
- The architecture that facilitates the integration of best-in-class components
- Common capabilities developed once and used many times
- Core capabilities designed to support a wide range of services and
  infrastructure types

Furthermore, ONAP includes a functional architecture with defined component and
interfaces, fostering industry alignment in addition to open source code.

Architecture Overview
---------------------

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

   Note: Use the interactive features of the ONAP Architecture Overview below.
   Click to enlarge the figure, then hover your mouse over an element for a short
   description. Click on an element to access a more detailed description

.. image:: media/onap-architecture-overview-interactive-path.svg
   :width: 800

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

ONAP Streamlining Evolution
---------------------------

Rationale
^^^^^^^^^
Previously, ONAP, as a platform, demonstrated end-to-end (e2e) network
automation to the industry. Operators, vendors and enterprises have learned
how service and network automation (encompassing modeling, orchestration,
policy-based closed loop, optimization, and more) functions in both
VM-based and Cloud-native environments. These capabilities have been applied
to VNF, PNF, CNF, NS, Network/RAN slicing, and end-to-end services thru ONAP.

ONAP provides numerous 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, including:

- End-to-End (E2E) Service
- Network Slicing
- RAN Slicing
- Closed-Loop Automation
- ETSI-based NS & VNF Orchestration
- Helm-based CNF Orchestration
- ASD-based (including Helm Charts) CNF Orchestration

Today, operators, vendors and enterprises aim to selectively integrate and apply
specific ONAP functionalities into their portfolios. There is no longer a
requirement to adopt ONAP as a complete monolithic solution.

Goal
^^^^
ONAP Streamlining goals are:

- To continue to support use cases efficiently for deployment in commercial production
  environments and portfolios
- To enable the industry to select desired ONAP component functions, replace certain ONAP
  functions, and seamlessly integrate those functions into their portfolios without requiring
  the full platform
- To streamline ONAP by driving individual components and clusters of components guided
  by use cases, allowing the industry to adopt functions flexibly and dynamically

Directions
^^^^^^^^^^
- Connecting ONAP, O-RAN, Nephio and other communities to achieve larger objectives
- Reusing selected ONAP functions for efficiency and consistency
- Functional delegations to distribute responsibilities effectively

ONAP Streamlining Transformation
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Through ONAP Streamlining, ONAP evolves from being a monolithic platform to
providing various network automation functions and security reference
configuration within LFN. ONAP facilitates the independent development of
functions and the deployment of components using Continuous Delivery (CD).
It will support use cases such as repository-based end-to-end (E2E) services,
network services (NS), Containerized network function (CNF), and cloud-native
application (CNA) onboarding. Additionally, ONAP will enable CD-based triggering
mechanisms for components with abstracted interfaces to support orchestration
and choreography.

The transformation emphasizes standard-based abstracted interfaces with
declarative APIs. Each component will become autonomous and capable of being
invoked from any level of network automation, leveraging CD mechanisms like
GitOps and CD readiness.

ONAP will adopt a more intent-based and declarative approach, integrating
genAI/ML technologies while adhering to industry standards such as 3GPP,
TMForum, ETSI, IETF, and O-RAN. For example, it will include user intent
support via the UUI, AI-driven natural language translation, and the application
of forthcoming 3GPP and TMForum models and APIs. Additionally, ONAP will
delegate resource-level orchestration to external community functions, such as
those from O-RAN SC and Nephio.

In terms of security, ONAP will continue to support features like Service Mesh,
Ingress, OAuth2, and IdAM-based authentication and authorization. It will also
explore sidecar-less solutions for network function (NF) security.

|image2|

**Figure 2. ONAP Streamlining Transformation**

Obstacles, Observations, Challenges
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- ONAP components were primarily designed for ONAP-specific consumption.
  - If a component is not utilized by ONAP use cases, it risks becoming obsolete
  or unmaintained rather than being graduated.
  - ONAP component-specific features may be overlooked if they are not utilized
  by other ONAP components.
- Component dependencies and couplings to other ONAP components are structured in
  an ONAP-specific manner
  - Those dependencies and couplings can be both syntactic and semantic.
  - Many intra-ONAP component interfaces and communications are ONAP-specific
  - Limited APIs standardization efforts are in place, such ETSI MANO APIs,
  ASD, 3GPP.
- Deviating from standards complicates integration with other systems, particularly
  non-ONAP systems.
- CI build and integration processes for vendors/operators might be less compatible
  with ONAP's. Some vendor/operators do not use OOM. In certain cases, a vendor
  maintains an entirely separate set of Helm charts for ONAP components.
- Vendor- or operator-specific security and logging requirements may vary, leading to
  integration challenges.
- The timelines and cadence of ONAP releases are inflexible, making it challenging to
  accommodate different release strategies
  - It is not possible to create a 'Release' in JIRA for individual component releases
  - Branching strategies are not aligned with ONAP's CMO (Current Mode of Operation)
  - This misalignment results in an artificial split in functionality between releases
  - Resolutions:

ONAP Component Design Requirements
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- ONAP components should be designed for both ONAP and non-ONAP consumption.
  - Component design should be generic and extensible in a way that would enable
  it to be used in non-ONAP.
  - If components are more generally applicable, there is the potential to gain
  more traction.
- Dependencies and couplings between ONAP components should be implemented in
  a way that is not specific to ONAP.
  - Making each ONAP component 'stand-alone' emphasizes to potential users that they
  can adopt individual components without committing to the entire ONAP.
- Aligning with standards where possible should be a global requirement.
  - If deviations are necessary, they should be implemented in an extensible manner
  that supports a standard-based approach.
- Each ONAP component should function as a standard module, enabling potential
  users to adopt individual components without requiring the entire ONAP system.
- Interactions between ONAP components should adhere to industry standards and
  be extensible to ensure seamless integration with non-ONAP systems.
- Helm charts for ONAP components in OOM should be structured to allow for
  independent component build and deployment.
  - Component Helm charts in OOM have been rewritten to support the
  individual build and deployment of components, leveraging LFN-compliant CI/CD
- ONAP security mechanisms should align with industry standards or widely
  adopted practices to ensure compatibility with vendor and operator security
  and logging systems.
  - The ONAP security framework, based on Service Mesh, Ingress, and Keycloack,
  supports vendor- and operator-neutral security
- The timelines and cadence of ONAP releases should be flexible to accommodate
  diverse release strategies.
  - The ONAP Streamlining release management supports agile and dynamic component
  lifecycles.

ONAP Streamlining Target Architecture
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The target architecture is as following:

- Modularity & independent management: Support for stand-alone components
- Interface abstraction & loose coupling: Including standardization wherever possible
- Extensibility & interchangeability: Design for adaptability and flexibility
- Scalability: Allowing the addition, update and deletion of components without disruption
- Autonomous self management: Components manage themselves independently
- Design for general use: Suitable for both ONAP and non-ONAP consumers
- Conformance to industry standards: Adhering to security and logging best practices
- Clustering components by use cases: Grouping components based on specific use case
  requirements
  - Best component selection: Choosing the optimal components for specific tasks
  - Responsive integration and delivery: Ensuring seamless integration and timely delivery
  - Reference automation: ONAP can still provide reference automation for coordination

See the Resources page on '<https://lf-onap.atlassian.net/wiki/spaces/DW/pages/16554594/ONAP+Streamlining+Evolution>'-

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.

|image3|

**Figure 3. ONAP Streamlining Component Build and Deployment**

For more details of ONAP streamlining, see the ONAP Streamlining - The Process
page, https://wiki.onap.org/display/DW/ONAP+Streamlining+-+The+Process

Component Function Summary
--------------------------
Note: The following components are deprecated as of the Oslo release:

- Message Bus (MSB)
- VNF SDK
- VVP
- External APIs
- CLI
- Correlation Engine (Holmes)
- Virtual Function Controller (VFC)
- OOF
- Model Utilities
- NBI
- DMaaP

|image4|

**Figure 4: ONAP Architecture Overall Function Descriptions**

Simplified and Individual Functional Overview of the Architecture
-----------------------------------------------------------------

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

#. ONAP Design time environment: Used for onboarding services and resources
   into ONAP and designing required services
#. External API (this is deprecated): Previously provided northbound
   interoperability for ONAP
#. ONAP Runtime environment: Model- and policy-driven orchestration
   and control functions enabling the automated instantiation and configuration
   of services and resources. Multi-VIM/Cloud ensures cloud interoperability for
   ONAP workloads. It also includes an Analytic framework that closely monitors
   service behavior and handles closed-loop control for dynamic handling healing,
   scaling and updates
#. OOM (ONAP Operations Manager): Manages cloud-native installation and
   deployments in Kubernetes-managed cloud environments
#. ONAP Shared Services: Provides shared capabilities for ONAP modules. The ONAP
   Optimization Framework (OOF) (this is deprecated) previously provided a
   declarative, policy-driven approach for creating and running optimization
   applications like homing/placement and change management scheduling. The Security
   Framework uses open-source security tools and patterns, such as Istio, Ingress
   Gateway, oauth2-proxy, and Keycloak, to secure external and inter-component
   communications, as well as 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. ONAP applications handle log generation only, while the
   Logging Framework stack manages the rest. This design enables operators to
   leverage or extend their existing logging stacks
#. ONAP shared utilities provide utility tools to support ONAP components

The information Model and framework utilities continue to evolve to harmonize
topology, workflow, and policy models from various SDOs, including ETSI NFV MANO,
TM Forum SID, 3GPP, ONF Core, OASIS TOSCA, IETF, and MEF.

|image5|

**Figure 5. Simplified Functional View of the ONAP Architecture**

Oslo Release Key Development
----------------------------
- Security Enhancements: ONAP projects have addressed critical security concerns by
  converting ports to HTTPS, removing hard-coded passwords, enabling Kubernetes pods
  to operate with non-root privileges, and mitigating Common Vulnerabilities and
  Exposures (CVEs). These measures have significantly bolstered the platform's security.
  Additionally, by leveraging industry-standard/de facto security security protocol and
  mechanisms such as Istio Service Mesh and Ingress Gateway, ONAP ensures secure
  inter- and intra-component communications.
- Platform Modernization: Components such as the Common Controller Software Development
  Kit (CCSDK), Configuration Persistence Service (CPS), Usecase User Interface (UUI),
  Portal-NG and Policy Framework were upgraded to Java 17. Additionally, various software
  versions updates ensure that ONAP leverages the latest software development
  frameworks.
- ONAP Streamlining Evolution: This initiative makes ONAP components modular and
  independent through interface abstraction,loose coupling and CI/CD. As a result,
  ONAP has evolved into a collection of individual network orchestration functions,
  allowing the industry to pick and choose specific components and enabling flexible
  and dynamic function adoption.
- Intent-based Declarative and GenAI Solutions: Supports generative AI solutions powered
  by large language models (LLMs), and includes data service enhancements (domain-specific
  datasets) of Intent-driven networks.
- Industry Standard-Based Network Interface Upgrade: CCSDK/SDNC now supports an
  RFC8040-compliant network interface.
- OpenSSF Gold Standard Achievement: The CPS and Policy Framework projects have achieved
  the Open Source Security Foundation (OpenSSF) Gold Badging standard, demonstrating
  ONAP's commitment to high-quality, secure, and reliable open-source software
  development.

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 monolithic platform but rather it provides network automation
functions, and security reference configuration in the LFN ecosystem.

Through the evolution of ONAP Streamlining, the ONAP deployment methodology has
been significantly enhanced, enabling individual ONAP components to be selected
and deployed using a chosen Continuous Deployment (CD) tool. This flexibility
is designed to accommodate diverse scenarios and requirements across various
operator environments. Users can also integrate specific ONAP components into
their own systems. For more details on the ONAP Streamlining evolution, see
the ONAP Streamlining evolution session.

The ONAP functions are highly reliable, scalable, extensible, secure and easy
to manage. To meet these goals, ONAP has been designed as a microservices-based
system, with all components packaged as Docker containers, adhering to best
practices to optimize image size. Numerous optimizations such as shared databases
and the adoption ff standardized, lightweight container operating systems, have
further reduced ONAP's overall footprint.

Building on microservice capabilities, ONAP has taken additional steps toward
greater modularity. For instance, the Service Orchestrator (SO) and controllers
have been further modularized, aligning with microservices architecture principles.
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 leverages Kubernetes
with IPv4 and IPv6 support to ensure efficient CPU usage and streamlined ONAP
component deployment. Additionally, OOM enhances ONAP maturity by providing
scalability and resiliency improvements to the components it manages.

As the lifecycle manager for ONAP, OOM utilizes Kubernetes container management
and Consul to deliver the following key functionalities:

#. Deployment: Built-in component dependency management, including support
   for multiple clusters, federated deployments across sites, and anti-affinity
   rules
#. Configuration: Unified configuration across all ONAP components
#. Monitoring: Real-time health monitoring integrated with a Consul GUI and
   Kubernetes
#. Restart: Automatic restart of failed ONAP components
#. Clustering and Scaling: Enables clustering of ONAP services for seamless scaling
#. Upgrade: Facilitates containers or configuration updates with minimal or no service
   disruption
#. Deletion: - Allows for clean up of individual containers or entire deployments

OOM supports a wide variety of cloud infrastructures to meet diverse requirements,
making it a versatile and robust solution for managing the ONAP functions.

Security Framework
^^^^^^^^^^^^^^^^^^
Starting with the Istanbul-R9 release, OOM provides Service Mesh-based mTLS
(mutual TLS) to secure communication between ONAP components, by leveraging Istio.
This new security mechanism, implemented under the Security Framework, replaces
the previously unmaintained AAF functionalities, resulting in AAF is deprecated.

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

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

As the result, unmaintained AAF functionalities have become obsolete and have been
replaced by Istio-based Service Mesh and Ingress starting with the Montreal release.

|image6|

**Figure 6. Security Framework component architecture**

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

Microservices Bus (MSB)
^^^^^^^^^^^^^^^^^^^^^^^
.. warning:: The ONAP :strong:`MSB` project is :strong:`deprecated`.
             As of Release 13 'Montreal' the component is no longer part of the
             ONAP deployment.

The Microservices Bus (MSB) previously provided fundamental microservices support,
including service registration/ discovery, external API gateway, internal API
gateway, client software development kit (SDK), and Swagger SDK. When integrated
with OOM, MSB featured a Kube2MSB registrar, which extracted services information
from Kubernetes metafile and automatically registered services for ONAP components.

Since the London release, ONAP Security Framework components have provided secure
communication capabilities, offering a more Kubernetes-native. Consequently, MSB
had been replaced by the Security Framework, making MSB becomes an obsolete ONAP
component.

In alignment with the global of leveraging microservice capabilities, further steps
have been taken to increase modularity. The Service Orchestrator (SO) and controllers
have enhanced their level of modularity to better align with the microservices
architecture.

Portal-NG
---------
ONAP had a portal project but this project was terminated and archived.
Portal-NG is a GUI platform function that enables the integration of various ONAP
GUIs into a centralized portal. It offers the following features:

- The ability for ONAP components to run within their own infrastructure while
  providing centralized management services and capabilities
- Common functionalities such as application onboarding and management,
  centralized access management, hosting application widgets, context-aware
  UI controls, and a visualization and reporting engine
- SDK capabilities for accessing portal functionalities
- Multi-language support

Portal-NG supports administrative roles for managing the Portal-NG itself and
the on-boarded applications. From the ONAP Portal-NG, administration can:

- Access all functionalities available to regular users
- Manage users and application administrators
- Onboard applications and widgets
- Edit the functional menu

Design Time Components
----------------------
The design time components serve as comprehensive development environments,
providing tools, techniques, and repositories for defining and describing
resources, services, and products. These components enable the reuse of
models, improving efficiently as more models become available over time.

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) to control behavior and process execution. Process specifications
automatically handle the sequencing of instantiation, delivery and lifecycle
management for resources, services, products and the ONAP components.

Some process specifications (i.e., recipes™) and policies are geographically
distributed to optimize performance and enhance autonomous behavior in
federated cloud environments.

Service Design and Creation (SDC)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Service Design and Creation (SDC) provides tools, techniques, and repositories
for defining, simulating, and certifying system assets along with their associated
processes and policies. Each asset is categorized into one of four asset groups:
Resources, Services, Products, or Offers.

SDC supports the onboarding of various package types, including:
- 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)
- PNF packages (ETSI SOL004)

SDC also includes capabilities for modeling 5G network slicing using the standard
properties such as the Slice Profile and Service Template.

Since Kohn-R11 release, SDC supports onboarding of additional CNF-Modeling
package: the Application Service Description (ASD) package. ASD serves as a
deployment descriptor for cloud-native applications and functions. It minimizes
the information required by referencing most resource descriptions directly to
the cloud-native artifacts (e.g., Helm Charts). Its CSAR package adheres to
ETSI SOL004.

The SDC environment supports a diverse range of users through common services
and utilities. Using the design studio, product and service designers onboard,
extend, or retire resources, services and products. Operations teams, engineers,
customer experience managers, and security experts create workflows, policies
and methods to implement closed loop automation and manage elastic scalability.

Vendors can integrate these tools into their CI/CD environments to package VNFs,
CNFs and PNFs, and upload them to the validation engine. Once tested, the VNFs,
CNFs and PNFs can be onboarded through SDC.

The Policy Creation component handles policies, which include rules, conditions,
requirements, constraints, attributes, or needs that must be provided,
maintained, or enforced. At a technical level, policies consist of machine-readable
rules that enable actions to be triggered based on specific conditions or requests.
Policies often consider the conditions in effect, both in triggering specific
policies and in selecting the appropriate outcomes based on those conditions.

Policies enable rapid modification by allowing rules to be updated easily, thus
altering the technical behaviors of the components using those policies without
requiring software code rewrites. This abstraction simplifies the management
and control of complex systems.

VNF SDK
^^^^^^^
.. warning:: The ONAP :strong: 'VNF SDK' project is :strong:'deprecated'.

The VNF SDK previously provided functionality for creating VNF/PNF packages,
testing VNF packages for ONAP compliance, storing VNF/PNF packages, and
uploading or downloading to or from a marketplace.

VVP
^^^
.. warning:: The ONAP :strong: 'VVP' project is :strong:'deprecated'.

The VVP previously provided validation for VNF Heat packages.

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

This enables for the distribution of models and policies across various ONAP
modules, including the Service Orchestrator (SO), Controllers, Data Collection,
Analytics, and Events (DCAE), CPS, Policy Framework and Active and Available
Inventory (A&AI). These ONAP components rely on common services for security
(access control, secure communication), and logging.

Orchestration
^^^^^^^^^^^^^
The Service Orchestrator (SO) component automates processes by executing of
activities, tasks, rules and policies necessary for the on-demand creation,
modification or removal of network, application or infrastructure services
and resources. This includes VNFs, CNFs and PNFs, while adhering to industry
standards such as ETSI, 3GPP, TMF and others.

The SO provides high-level orchestration with an end-to-end perspective on
infrastructure, network, and applications. Examples include BroadBand Service
(BBS) and Cross Domain and Cross Layer VPN (CCVPN).

The SO is modular and hierarchical, designed to manage services and multi-level
resources, and network slicing. It achieves this by leveraging pluggable adapters
and delegating orchestration operations to components such as NFVO (e.g., SO NFVO,
VFC - deprecated), VNFM, CNF Manager, MSMF (Network Slice Management Function),
and NSSMF (Network Slice Subnet Management Function).

Starting from the Guilin release, the SO provides CNF orchestration support
through the integration of a CNF adapter in ONAP SO. Key features included:

- Support for provisioning CNFs using an external Kubernetes Manager
- Helm-based orchestration support
- Utilization of the CNF Adapter to interact with the Kubernetes (K8S) plugin
  in MultiCloud
- Leveraging the capabilities of the K8S orchestrator
- Preparing the groundwork for cloud-native scenarios

In the London release, ONAP SO introduced ASD-based CNF orchestration support
to simplify CNF orchestration and eliminate redundancies in CNF resource attributes
and orchestration process. Key features include:

- Support for ASD-based CNF models and packages
- Introduction of the 'SO CNFM' sub-component for dedicated ASD-based CNF orchestration,
  ensuring separation of concerns by isolating ASD management from other SO components
- Use of ASD for Application Service Lifecycle Management (AS LCM) and associated
  Helm Charts for CNF deployment to selected external Kubernetes (K8S) clusters
- Use of the Helm Client for communicating with external K8S clusters during
  deployment
- Monitoring of deployed K8S resources via Kubernetes APIs

3GPP (TS 28.801) defines a three-layer slice management function consisting of:

- CSMF (Communication Service Management Function)
- NSMF (Network Slice Management Function)
- NSSMF (Network Slice Subnet Management Function)

These three layers can be implemented within ONAP or through external CSMF, NSMF,
or NSSMF components. For ONAP-based network slice management, different
implementation options are available. Currently, ONAP orchestration supports
options #1 and #4.

|image7|

**Figure 7: ONAP Network Slicing Support Options**


Virtual Infrastructure Deployment (VID) - obsolete
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. warning:: The ONAP :strong:`vid` project is :strong:`deprecated`.
             As of Release 12 'London' the component is no longer part of the
             ONAP deployment.

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

Policy-Driven Workload Optimization
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. warning:: The ONAP :strong:'OOF' project is :strong:'deprecated'.

The ONAP Optimization Framework (OOF) previously offered a policy-driven
and model-driven framework for developing optimization applications for a wide
range of use cases. The OOF Homing and Allocation Service (HAS) was a policy
driven workload optimization service that enabled the optimized placement of
services across multiple sites and clouds. This optimization was based on a
variety of policy constraints, including capacity, location, platform
capabilities, and other service specific constraints.

ONAP Multi-VIM/Cloud (MC) and several other ONAP components, such as Policy, SO,
A&AI, previously leveraged OOF-HAS for "Policy-driven Performance/Security-Aware
Adaptive Workload Placement/Scheduling" across cloud sites. OOF-HAS utilizes
cloud-agnostic intent capabilities and real-time capacity checks provided
by ONAP MC to determine the optimal VIM/Cloud instances. These instances are
selected to meet required performance SLAs for workload (e.g., VNF) placement
and scheduling (Homing).

This approach enables operators to realize the true value of virtualization
by optimizing cloud resources at a fine-grained level while ensuring performance
and security SLAs are met.

Controllers
^^^^^^^^^^^
Controllers are applications coupled with cloud and network services that
execute configurations, enforce real-time policies, and manage the state of
distributed components and services. Instead of relying on a single monolithic
control layer, operators can use multiple distinct controller types to
manage resources in their specific execution domains, such as cloud computing
resources (SDN-C).

.. warning:: The ONAP :strong:'appc' project is :strong:'deprecated'.
.. warning:: The ONAP :strong:'VF-C' project is :strong:'deprecated'.

The Virtual Function Controller (VF-C) and SO NFVO previously provided an
ETSI NFV-compliant NFV-O function responsible for the lifecycle management of
virtual services and the associated physical COTS server infrastructure. VF-C
previously offered generic VNFM capabilities, and both VF-C and SO NFVO integrate
with external VNFMs and VIMs as part of the NFV MANO stack.

ONAP includes an application-level configuration and lifecycle management module
called SDN-C. SDN-C provides services for application-level configuration (using
tools like NetConf, Chef, Ansible, RestConf, etc.) and lifecycle management
functions (e.g., Stop, resume, health check). SDN-C shares leverages common code
from the CCSDK repository.

However, there are key differences between these two modules. SDN-C uses CDS
exclusively for onboarding and configuration/LCM flow design.

SDN-C has been used for Layer1-7 network elements. This distinction is somewhat
loose, and over time, better alignment is expected, leading to a common repository
for controller code that supports application-level configuration and lifecycle
management of all network elements (physical or virtual, layer 1-7).

The ONAP Controller Family (SDN-C) configures and maintains the health of L1-7
Network Function (VNF, PNF, CNF) and network services throughout their lifecycle.
Key capabilities include:

- Configure Network Functions (VNF/CNF/PNF)
- Provides programmable network application management platform:
  - Behavior patterns defined via models and policies
  - Standards-based models and protocols for multi-vendor implementations
  - Extensible southbound adapters, such as Netconf, Ansible, Rest API, etc.
  - Operational control, version management, software updates, and more
- Local source of truth
  - Manages inventory within its scope
  - Tracks and stores the state of network functions
  - Supports for configuration audits

Controller Design Studio (CDS)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The Controller Design Studio (CDS) community in ONAP has contributed a
framework to automate resource resolution for instantiation and configuration
provisioning operations, such as Day-0, Day-1 or Day-2 configurations. The
core function of CDS is to create and populate a controller blueprint,
generate a configuration file from this blueprint, and associate this
configuration file (configlet) with a PNF, VNF, or CNF during the
design phase.

CDS eliminates dependence on code releases and the delays they introduce,
empowering service providers to have greater control over their services.
Users can modify models and their parameters with flexibility, allowing
them to retrieve data from external systems (e.g., IPAM) required for
real-world deployments. This approach enables service providers to be more
responsive to their customers' needs and deliver tailored solutions that
better meet customer expectations.

Inventory
^^^^^^^^^
Active and Available Inventory (A&AI) provides real-time views of a system's
resources, services, products, and their relationships, while also maintaining
a historical view. A&AI integrates data managed by multiple ONAP instances,
Business Support Systems (BSS), Operation Support Systems (OSS), and network
applications to create a comprehensive 'top to bottom' view. This view spans
from the products purchased by end users to the underlying resources that serve
as the building blocks for those products.

A&AI serves not only as a registry for products, services, and resources but
also as a dynamic database that maintains up-to-date relationships between
these inventory items. To support the agility required by SDN/NFV, A&AI is
updated in real-time by controllers as changes occur in the network
environment. Additionally, A&AI is metadata-driven, enabling the dynamic and rapid addition
of new inventory types via SDC catalog definitions. This approach eliminates
the need for lengthy development cycles, allowing for faster adaptation to
evolving network and service requirements.

Policy Framework
^^^^^^^^^^^^^^^^
The ONAP Policy Framework is a comprehensive function for policy design,
deployment, and execution. It serves as the decision-making component within
an ONAP system, enabling the specification, deployment, and governance of
features and functions. These can include closed-loop automation, orchestration,
or traditional open-loop use case implementations. The Policy Framework acts
as the single source of truth for all policy decisions.

Since the Istanbul release, the CLAMP was officially integrated into the
Policy component. CLAMP's role in provisioning policies has been expanded to
include support for policy provisioning outside the context of a control loop,
effectively functioning as a Policy UI. For more details, refer to the
Policy - CLAMP section below.

It supports multiple policy engines and can distribute policies through policy
design capabilities in SDC, simplifying the design process. In the Paris release,
it will offer the Policy-OPA-PDP capabilities.

Closed Control Loop Automation Management Platform in Policy (Policy - CLAMP)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. warning:: The ONAP :strong:`CLAMP` function is now part of :strong:`Policy`.

Closed-loop control in ONAP is achieved through the collaboration of various
design-time and run-time elements. The runtime loop begins with data collectors
from the Data Collection, Analytics and Events (DCAE) module. ONAP provides the
following collectors:

- VES (VNF Event Streaming) for events
- HV-VES for high-volume events
- SNMP Collector for SNMP traps
- File Collector for file-based data ingestion
- Restconf Collector for receiving notifications

After the data collection and verification phase, the data flows through a
series of microservices, such as Homes for event detection, Policy for
determining appropriate actions, and controllers and orchestrators for
implementing those actions. The Policy framework also monitors these loops
and manages their lifecycle.

DCAE includes specialized microservices for specific use cases, such as
Slice Analysis and the SON-Handler. Dedicated event processor modules transform
collected data (e.g., SNMP, 3GPP XML, RESTCONF) into VES format and push it into
the data lake.

At the design stage, CLAMP, Policy, and DCAE provide tools to support the
creation of closed-loop processes, ensuring seamless integration and execution.
This automation pattern is referred to as 'Closed Control Loop Automation'
as it provides the necessary automation to proactively respond to network and service
conditions without human intervention. A high-level schematic of 'Closed Control Loop
Automation' and its various phases within the service lifecycle is shown in Figure 5.
Closed control loop functionality is enabled by Data Collection, Analytics, and
Events (DCAE) in conjunction with other ONAP runtime components. Together, they
deliver FCAPS (Fault Configuration Accounting Performance Security) functionality.
DCAE collects performance, usage, and configuration data; computes analytics;
aids in troubleshooting; and publishes events, data and analytics to components
such as Policy, Orchestration, and the Data Lake.
Additionally, the Holmes component connects to DCAE to provide alarm correlation
for ONAP, enhanced data collection capabilities with High Volume VES, and bulk
performance management support. Working with the Policy Framework (and the embedded CLAMP),
these components detect network issues and determine the appropriate remediation.
In some cases, actions are executed automatically by notifying the Service Orchestrator
or a controller. In other cases, as configured by the operator, an alarm is raised
to require human intervention before executing changes. The policy Framework
has been extended with adaptive policy execution to enhance its decision-
making capabilities.

From the Honolulu-R8 release to the Istanbul-R9 release, the CLAMP component was
successfully integrated into the Policy Framework component. Initially introduced
as a proof of concept in the Honolulu-R8 release, it became a fully integrated
component within the Policy Framework component in the Istanbul-R9 release.

CLAMP's role in policy provisioning has been expanded to support policies outside
the context of a Control Loop, effectively serving as a Policy UI. The integration
of CLAMP into the Policy Framework was officially completed in the Istanbul
release.

|image8|

**Figure 8: ONAP Closed Control Loop Automation**

Multi Cloud Adaptation
^^^^^^^^^^^^^^^^^^^^^^
Multi-VIM/Cloud provides an infrastructure adaptation layer for VIMs/Clouds
and Kubernetes (K8s) clusters. It exposes advanced cloud-agnostic intent
capabilities, in addition to standard capabilities, which are utilized by OOF
(deprecated) and other components for enhanced cloud selection, as well as
SO and/or VF-C (deprecated) for cloud-agnostic workload deployment.

The K8s plugin is responsible for deploying CNFs on Kubernetes clusters using
Kubernetes APIs.

Data Collection Analytics and Events (DCAE)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
DCAE provides capabilities for event collection and hosting analytics applications
(DCAE Services). It collects performance, usage, and configuration data from
the managed environment. This data is processed by various analytic applications,
and when anomalies or significant events are detected, the results trigger appropriate
actions, such as publishing to other ONAP components such as Policy, SO, or
Controllers.

Key capabilities include:

- Collecting, ingesting, transforming and storing data as needed for analysis
- Providing a framework for the development of analytics applications

Virtual Function Controller (VFC)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 .. warning:: The ONAP :strong:'VFC' project is :strong:'deprecated'.

VFC previously provided NFVO capabilities to manage the lifecycle of network
services and VNFs in compliance with the ETSI NFV specification.

Data Movement as a Platform (DMaaP)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 .. warning:: The ONAP :strong:'DMaaP' project is :strong:'deprecated'.

DMaaP previously provided data movement services for transporting and processing
data from any source to any target. Its message routing functionality was deprecated
in New Delhi release, with Strimzi and Kafka replacing it. In the Oslo release,
the remaining DMaaP sub-component, Data Routing, was also deprecated.

Use Case UI (UUI)
^^^^^^^^^^^^^^^^^
UUI provides the capability to instantiate blueprint use cases and visualize
their state. It serves as an application portal that enables the management of
ONAP service instances. Customers can create, delete and update service instances,
as well as to monitor their alarms and performance.

The component supports the following functionalities:

- Customer Interaction Management
- Package Management (includes IBN packages)
- Service Instance Management (includes CCVPN, 5G Slicing, Intent-based automation)
- Blueprint Instantiation, handling blueprint use cases instantiation
- Model As A Service (MaaS) for dynamic generative AI modeling services to enhance
  ONAP's genAI; for more details, see <Large Model Capability Exposure and Application Development Based on MaaS (Model as a Service) v2.1 (1).pdf>'-
- Monitoring and Visualization (includes 5G slicing monitor and other events)
- Network Topology Visualization

UUI contains the following sub-components:

- UUI GUI
- UUI Server
- UUI NLP Server (since Istanbul release)
- UUI INTENT ANALYSIS Server (since Kohn release)
- LLM-Adaptation
- Database

See UUI Component Architecture,

|image9|

**Figure 9. UUI Component Architecture**

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.

Its details in
:ref:'CPS - Configuration Persistence Service<onap-cps:architecture>'.

CLI
^^^
.. warning:: The ONAP :strong:'CLI' project is :strong:'deprecated'.

ONAP CLI previously provided a command-line interface for accessing ONAP.

External APIs
^^^^^^^^^^^^^
.. warning:: The ONAP :strong:`externalapi` project is :strong:`unmaintained`.

External APIs were previously used to expose ONAP capabilities.

Shared Services
---------------
.. warning:: The ONAP :strong:'Logging Framework' project is a reference
   implementation PoC.

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

ONAP Shared Services provide shared capabilities for ONAP modules, such as
access management, security enforcement, and logging.

Optimization Framework (OOF)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. warning:: The ONAP :strong:'OOF' project is :strong:'deprecated'.

The Optimization Framework (OOF) previously offered a declarative, policy-driven
approach for creating and executing optimization applications, such as like
Homing/Placement and Change Management Scheduling Optimization.

Security Framework
^^^^^^^^^^^^^^^^^^
The Security Framework utilizes open-source security patterns and tools, including
Istio, Ingress Gateway, oauth2-proxy, and Keycloak. It ensures secure external and
inter-component communications, as well as authentication and authorization.

See the Figure 6. Security Framework component architecture for its architecture.

Logging Framework (PoC)
^^^^^^^^^^^^^^^^^^^^^^^
.. warning:: The ONAP :strong:`Logging Framework` project is a reference
   implementation :strong:`PoC`.

The Logging Framework supports open-source- and standard-based logging. It separates
application log generation from log collection, aggregation, persistence,
visualization, and analysis. In this setup, ONAP applications focus solely on
log generation, while the Logging Framework stack manages the remaining processes.
This approach allows operators to leverage or extend their own logging stacks.

ONAP Modeling
-------------
.. warning:: The ONAP :strong:'ONAP Modeling' project is :strong:'deprecated'.

ONAP previously provided models to assist with service design, the development
of ONAP service components, and the enhancement of standards interoperability.
Models are a critical component of both the design time and runtime framework
development. The ONAP modeling project leverages the expertise of member companies,
standard organizations, and other open source projects to create models that are
simple, extensible, and reusable.

The goal is to meet the requirements of various use cases, guide the development,
ensure consistency across ONAP components, and explore a common model to enhance
ONAP interoperability. ONAP supports various models, as detailed in the Modeling
documentation.

Since the Kohn release, a new CNF modeling descriptor, the Application Service
Description (ASD), has been introduced. This addition simplifies CNF modeling and
orchestration by delegating resource modeling to Kubernetes-based resource
descriptors, such as Helm Charts.

The modeling project previously supported the ETSI catalog component, which
offered parser functionalities and additional package management capabilities.

Industry Alignment
------------------
ONAP's support for and collaboration with other standards and open-source communities
is evident in its architecture: - MEF and TMF Interfaces: Utilization in the External
APIs - ETSI-NFV Models: In addition to the VNFD and NSD models defined by ETSI-NFV, ONAP
supports NFVO interfaces, including: - SOL 005: Between the SO and VFC/SO-NFVO

- SOL 003: From either the SO (thru SOL003 Adapter) or VFC to an external VNFM
- Application Service Descriptor (ASD): The ASD v1.0 specification for CNF is approved,
  and promoted as an O-RAN standard
- 3GPP Interfaces and LLM services: These are utilized in the UUI and other genAI
  capable components Read this white paper for more information:

'The Progress of ONAP: Harmonizing Open Source and Standards <https://www.onap.org/wp-content/uploads/sites/20/2019/04/ONAP_HarmonizingOpenSourceStandards_032719.pdf>'-

ONAP Blueprints
---------------
ONAP can support an unlimited number of use cases, within reason. To provide
concrete examples of how ONAP can solve real-world problems, the community
has developed a set of blueprints. These blueprints not only help users quickly
adopt the ONAP capabilities through end-to-end solutions but also assist the
community in prioritizing their work.

5G Blueprint
^^^^^^^^^^^^
The 5G blueprint is a multi-release initiative focused on the following key
areas:

end-to-end service orchestration, network slicing, PNF/VNF lifecycle management,
PNF integration, and network optimization.

This blueprint addresses the unique requirements brought by the combination of
eMBB (promising peak data rates of 20 Mbps), uRLLC (guaranteeing sub-millisecond
response times), mMTC (supporting 0.92 devices per square foot(, and network
slicing.

First, ONAP must manage the lifecycle of a network slice from creation and
activation to deactivation and termination. Additionally, ONAP needs to optimize
the network using real-time and bulk analytics, place VNFs on the appropriate edge
cloud, scale and heal services, and enable edge automation. ONAP also provides
self organizing network (SON) services, such as physical cell ID allocation for
new RAN sites.

These requirements have driven the five initiatives mentioned above and were
developed in close collaboration with standards and open-source organizations,
including 3GPP, TM Forum, ETSI, and O-RAN alliance.

|image10|

**Figure 10. End-to-end 5G Service**

Read the `5G Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2019/07/ONAP_CaseSolution_5G_062519.pdf>`_
to learn more.

A related initiative outside of ONAP is the 5G Super Blueprint, where
multiple Linux Foundation projects collaborate 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).

|image11|

**Figure 11. 5G Super Blueprint Initial Integration Activity**

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

Residential Connectivity Blueprints
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Two ONAP blueprints, vCPE and BBS, address the residential connectivity use case.

Virtual CPE (vCPE)
""""""""""""""""""
Currently, the services offered to a subscriber are limited to those built into
the broadband residential gateway. In the blueprint, the customer is provided
with a slimmed-down physical CPE (pCPE) connected to a traditional broadband
network, such as DSL, DOCSIS, or PON (Figure 6). A tunnel is then established
to a data center hosting various VNFs, offering a significantly broader range
of services to the subscriber at a much lower cost of the operator.

This blueprint leverages ONAP to support the complex orchestration and management
of open-source VNFs, as well as both virtual and underlay connectivity.

|image12|

**Figure 12. ONAP vCPE Architecture**

Read the `Residential vCPE Use Case with ONAP blueprint <https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_vCPE_112918FNL.pdf>`_
to learn more.

Broadband Service (BBS)
"""""""""""""""""""""""
This blueprint provides multi-gigabit residential internet connectivity
services using PON (Passive Optical Network) access technology. A key
feature of this blueprint is the automatic re-registration of an ONT
(Optical Network Terminal) when the subscriber moves (nomadic ONT) or changes
their service subscription plan.

This blueprint leverages ONAP for the design, deployment, lifecycle management,
and service assurance of broadband services. Additionally, it demonstrates how
ONAP can orchestrate services across different locations (e.g., Central Office,
Core) and technology domains (e.g., Access, Edge).

|image13|

**Figure 13. ONAP BBS Architecture**

Read the `Residential Connectivity Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2019/07/ONAP_CaseSolution_BBS_062519.pdf>`_
to learn more.

Voice over LTE (VoLTE) Blueprint
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This blueprint leverages ONAP to orchestrate a Voice over LTE service. It
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 end-to-end VoLTE
service orchestration, collaborating with VF-C and SDN-C. SDN-C establishes
network connectivity, while the VF-C component completes Network Services and
VNF lifecycle management, including service initiation, termination and manual
scaling, and FCAPS (Fault, Configuration, Accounting, Performance, Security)
management.

This blueprint also demonstrates advanced functionalities such as scaling and
change management.

|image14|

**Figure 14. ONAP VoLTE Architecture Open Network Automation**

Read the `VoLTE Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_VoLTE_112918FNL.pdf>`_
to learn more.

Optical Transport Networking (OTN)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Two ONAP blueprints, CCVPN and MDONS, address the OTN use case. CCVPN focuses
on Layers 2 and 3, while MDONS targets Layers 0 and 1.

CCVPN (Cross Domain and Cross Layer VPN) Blueprint
""""""""""""""""""""""""""""""""""""""""""""""""""
CSPs, such as CMCC and Vodafone, are experiencing strong demand for high-bandwidth,
flat, high-speed OTN (Optical Transport Networks) across carrier networks.
They also aim to offer high-speed, flexible and intelligent services for high-value
customers, as well as instant and adaptable VPN services for SMB companies.

|image15|

**Figure 15. ONAP CCVPN Architecture**

The CCVPN (Cross Domain and Cross Layer VPN) blueprint combines SOTN (Super
high-speed Optical Transport Network) with ONAP, leveraging ONAP's orchestration
capabilities to achieve unified management and scheduling of resources and services.
It enables cross-domain orchestration and ONAP peering across service providers.

In this blueprint, SO handles end-to-end CCVPN service orchestration in
collaboration with VF-C and SDN-C. SDN-C establishes network connectivity, while
VF-C component manages the Network Services and VNF lifecycle. ONAP peering across
CSPs is facilitated through an east-west API, which is aligned with the
MEF Interlude API.

CCVPN, together with the IBN use case, provides intent-based cloud leased line
services. Key innovations in this use case include:

- Physical network discovery and modeling
- Cross-domain orchestration across multiple physical networks
- Cross-operator end-to-end service provisioning and close-loop rerouting for
  cross-domain services
- Support for dynamic changes (.e.g., branch sites, VNFs)
- Intelligent service optimization leveraging AI/ML technologies

Read the `CCVPN Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2019/07/ONAP_CaseSolution_CCVPN_062519.pdf>`_
to learn more.

MDONS (Multi-Domain Optical Network Service) Blueprint
""""""""""""""""""""""""""""""""""""""""""""""""""""""
While CCVPN addresses the automation of networking layers 2 and 3, it does not
cover layers 0 and 1. Automating these layers is equally important, as providing
end-to-end services often involves manual and complex negotiation between CSPs,
including both the business arrangement and actual service design and activation.
Additionally, CSPs may operate multiple networks independently, requiring similar
transactions among their own networks and business units to deliver end-to-end
services.

The MDONS blueprint, developed by AT&T, Orange, and Fujitsu, addresses this
challenge. When used together, MDONS and CCVPN provide a comprehensive solution
to the OTN automation problem.

|image16|

**Figure 16. ONAP MDONS Architecture**

Intent Based Network (IBN) Use Case
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Intent technology can simplify network management by abstracting the intricate
details of the underlying network infrastructure, contributing to more efficient
operations. This use case provides a valuable business function by reducing
management operating expenses (OPEX) through a paradigm shift from complex
procedural operations to declarative intent-driven operations.

|image17|

**Figure 17. ONAP Intent-Based Networking Use Case**

3GPP 28.812, Intent driven Management Service (Intent driven MnS), defines
key concepts utilized in this initiative. The Intent-Based Networking (IBN)
use case includes the development of an intent-driven decision-making mechanism.
This use case was initially demonstrated in a smart warehouse scenario, where
the intent is to increase the output volume of automated guided vehicles (AVG),
with the network automatically scaling in response.

The Intent UI is implemented in UUI, and the components of the intent framework
interact with various ONAP components, including SO, A&AI, Policy, DCAE, and CDS.

vFW/vDNS Blueprint
^^^^^^^^^^^^^^^^^^
The virtual firewall, virtual DNS blueprint is a basic demonstration to verify
the correct installation of ONAP and to provide a basic introduction to its
capabilities. The blueprint consists of five VNFs: vFW, vPacketGenerator,
vDataSink, vDNS and vLoadBalancer. It exercises most aspects of ONAP, including
VNF onboarding, network service creation, service deployment, and closed-loop automation.

Key ONAP components involved in this blueprint are SDC, Policy, SO, and DCAE. In
recent releases, the vFW blueprint has been demonstrated using a mix of CNFs and
VNFs, as well as entirely with 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: doc:`Verified Use Cases<onap-integration:docs_usecases_release>`.

- E2E Network Slicing
- 5G OOF (ONAP Optimization Framework) SON (Self-Organized Network)
- CCVPN-Transport Slicing

Functional requirements
^^^^^^^^^^^^^^^^^^^^^^^
Various use cases have been tested for the release. Examples of these use cases
are listed below. Detailed information on use cases, functional requirements,
and automated use cases can be found here: doc:'Verified Use Cases<onap-integration:docs_usecases_release>'.

- xNF Integration

- ONAP CNF Orchestration - Enhancements
- ONAP ASD-Based CNF Orchestration
- PNF Pre-Onboarding
- PNF Plug & Play

- Lifecycle Management

- Policy-Based Filtering
- Bulk PM / PM Data Control Extension
- Support for xNF Software Upgrade in Association with Schema Updates
- Configuration & Persistency Service

- Security

- CMPv2 Enhancements
- Service Mesh
- Istio Gateway
- Authentication and Authorization Leveraging KeyCloak

- Standard alignment

- ETSI-Alignment
- ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over VES
- Extend ORAN A1 Adapter and add A1 Policy Management
- Striving to align with Linux AI & Data and GenAI Commons (in Research)

Future Considerations
---------------------
The ONAP components offer a comprehensive solution for real-time, policy-
driven orchestration and automation of physical, virtual and cloud-native
network functions. It enables software, network, IT, and cloud providers,
as well as developers, to rapidly automate new services and support complete
lifecycle management.

Key future considerations for ONAP are as follows:

- Ensure ONAP core components are focused and operate independently, from
  build to runtime
  - Argo-CD is a DT choice, but ONAP can allow other CDs, e.g., Flux
  - DT plans to productize some of the selected ONAP core components in their TNAP production environment
- Declarative and Intent-based component operations by the Repository-based
  Network Automation : see the ideas from ONAP Architecture Evolution - Ideas (November 2023)
- Make ONAP core components more autonomous and ready for use by both ONAP,
  LF and other external users
  - During New Delhi and Oslo releases, CPS and Policy achieved the OpenSSF
  Gold Badging status.
  - Continue to promote/facilitate other ONAP core components for the Gold
  Badging status (e.g., UUI, SDNC)
- Incorporate more GenAI capabilities and use cases to the ONAP components,
  and promote the adoption of open-source LLM models and frameworks aligned
  with LF AI & Data and GenAI Commons

  - Collaborate with LF AI & Data GenAI Commons and Nephio GenAI for 5G and 6G
  - Open-source based models and controls
  - AI-based control loop
  - AI Model-As-A-Service
- Foster inter-community collaboration with other LF communities, such as
  O-RAN and Nephio
  - SDNC enhancements (which is used by O-RAN OAM as is)
  - Resource-based Orchestration Pattern (leveraging CD and Operator)
- Ensure the security of ONAP components and operations
  - The latest security mechanism for communications (service mesh enhancements
  leveraging Istio and coming Ambient Mesh)
  - Deprecate unused sub-components and mitigate security vulnerabilities
- Enhance a secure LFN CI/CD pipeline leveraging OpenSSF-associated reference
  tools

Conclusion
----------
The ONAP components offer a comprehensive solution for real-time, policy-
driven orchestration and automation of physical, virtual and cloud-native
network functions. It enables software, network, IT, and cloud providers,
as well as developers, to rapidly automate new services and support complete
lifecycle management.

By unifying member resources, ONAP accelerates the development of a vibrant
ecosystem around a globally shared architecture and implementation for network
automation, with a strong emphasis on open-standards - achieving progress faster
than any single product could independently.

Resources
---------
See the Resources page on `ONAP.org <https://www.onap.org/resources>`_

.. |image2| image:: media/ONAP-Streamlining-Transformation.png
   :width: 800px
.. |image3| image:: media/ONAP-Streamlining-Build-Deployment.png
   :width: 800px
.. |image4| image:: media/ONAP-architecture-functions.png
   :width: 800px
.. |image5| image:: media/ONAP-fncview.png
   :width: 800px
.. |image6| image:: media/ONAP-securityFramework.png
   :width: 800px
.. |image7| image:: media/ONAP-NetworkSlicingOptions.png
   :width: 800px
.. |image8| image:: media/ONAP-closedloop.png
   :width: 800px
.. |image9| image:: media/UUI-Component-Architecture.png
   :width: 800px
.. |image10| image:: media/ONAP-5G.png
   :width: 800px
.. |image11| image:: media/ONAP-5GSuperBP-Integration.png
   :width: 800px
.. |image12| image:: media/ONAP-vcpe.png
   :width: 800px
.. |image13| image:: media/ONAP-bbs.png
   :width: 800px
.. |image14| image:: media/ONAP-volte.png
   :width: 800px
.. |image15| image:: media/ONAP-ccvpn.png
   :width: 800px
.. |image16| image:: media/ONAP-mdons.png
   :width: 800px
.. |image17| image:: media/ONAP-IntentBasedNetworking.png
   :width: 800px