Purpose of this wiki

The purpose of this wiki is to have the architecture text that needs to be modified. The source of this is the London Architecture in read-the-docs.

The text should be release independent, then copied back to read-the-docs.

Architecture text

.. 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

.. _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

|image1|



**Figure 1: a high-level view of the ONAP architecture and its microservice-based components. 
            Click to enlarge and explore.**


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

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

Obstacles, Observations, Challenges and Resolutions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

- 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
  - Resolutions: ONAP component functions should be designed for use not only ONAP 
    but also in non-ONAP environments
    - 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
- 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
  - Resolutions: Making each ONAP component 'stand-alone' emphasizes to potential 
    users that they can adopt individual components without committing to the entire 
    ONAP
- Deviating from standards complicates integration with other systems, particularly
  non-ONAP systems
  - Resolutions: Aligning with standards where possible should be a global requirement
  - Resolutions: If deviations are necessary, they should be implemented in an 
    extensible manner that supports a standard-based approach
- 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
  - Resolutions: Component Helm charts in OOM have been rewritten to support the 
    individual build and deployment of components, leveraging LFN-compliant CI/CD
- Vendor- or operator-specific security and logging requirements may vary, leading to 
  integration challenges. 
  - Resolutions: The ONAP security framework, based on Service Mesh, Ingress, and 
    Keycloack, supports vendor- and operator-neutral security
- 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: The ONAP Streamlining release management supports agile and dynamic 
    component lifecycles



ONAP Streamlining Target Architecture
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

- 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 '<ONAP Streamlining Evolution>'-

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






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

Figure 2 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.

|image2|




**Figure 2. A simplified functional view of the ONAP architecture **

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

Its deployment methodology must be flexible enough to accommodate various 
scenarios and purposes across diverse operator environments. Users may
also choose to integrate only a subset of ONAP components into their
own systems. Additionally, the platform must be highly reliable, scalable, 
secure, and easy to manage. 

To meet these objectives, ONAP is designed as a microservices-based system, 
with all components packaged as Docker containers, adhering to best practice
for optimizing image size. Various optimizations, such as shared databases 
and the use of standardized lightweight container operating systems, help 
minimize ONAP's overall footprint.

ONAP Operations Manager (OOM)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The ONAP Operations Manager (OOM) is responsible for orchestrating the
end-to-end lifecycle management, security handling and monitoring of ONAP 
components. OOM utilizes Kubernetes with IPv4 and IPv6 support to ensure CPU 
efficiency and platform deployment. Additionally, OOM enhances the ONAP 
components maturity by providing scalability and resiliency improvements for 
the components it manages.

As the lifecycle manager of the ONAP functions, OOM uses the Kubernetes
container management system and Consul to provide the following 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. 

|image3|

  
**Figure 3. Security Framework component architecture**



Microservices Bus (MSB)
^^^^^^^^^^^^^^^^^^^^^^^

.. warning:: The ONAP :strong: 'MSB' project is :strong:'deprecated'.

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
------

.. warning:: The ONAP :strong: 'portal' project is :strong:'unmaintained'.

Note: A new Portal-NG replaces the existing Portal.

ONAP provides a unified, consistent user experience across design-time and
runtime environments, tailored to the user's role. Role changes are configured
within a single ONAP instance. This experience is managed through the ONAP 
Portal, which grants access to design, analytics, and operational 
control/administration functions via a shared, role-based menu or dashboard. 

The portal architecture previously offered web-based capabilities such as 
application onboarding and management, centralized access management through 
the Authentication and Authorization Framework (AAF), dashboards, and hosted 
application widgets. It also provided an SDK to ensure consistent UI development 
across multiple teams, leveraging built-in capabilties (Services/ API/ UI 
controls), tools, and technologies. 

For operators who require it, ONAP used to include a Command Line Interface (CLI), 
allowing integration with scripting environments. Additionally, ONAP SDKs used to 
enable operations, security, third parties (e.g., vendors and consultants), and 
other experts to define and redefine new collections, analytics, and policies
(including recipes for corrective or remedial actions) through the ONAP Design
Portal function.

Portal-NG
---------

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.

|image 4|

**Figure 4: ONAP Networking Slicing Support Options**

Virtual Infrastructure Deployment (VID)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. warning:: The ONAP :strong:'vid' project is :strong:'deprecated'.
.. warning:: The ONAP :strong:'vid' component is no longer part of the ONAP
   deployment from the London release.

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. 


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

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. 

|image5|
**Figure 5: ONAP Closed Control Loop Automation**


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


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.

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




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:'deprecated'.

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 3. Security Framework component architecture for its architecture.


Logging Framework (PoC)
^^^^^^^^^^^^^^^^^^^^^^^

.. warning:: The ONAP :strong:'Logging Framework' project is a reference 
implementation 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.

|image6|

**Figure 6. 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).

|image 7|

** Figure 7. 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. 

|image8| 

**Figure 8. 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>'- 


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). 

|image9| 

**Figure 9. 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. 

|image10| 

**Figure 10. ONAP VoLTE Architecture Open Network Automation Platform** 

Read the 'VoLTE Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_VoLTE_112918FNF.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. 

|image11| 

**Figure 11. 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. 

|image12|

**Figure 12. 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.

|image 13|

**Figure 13. 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. 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
  - DT finishes Argo-CD based component independent deployment
    - Argo-CD is a DT choice, but ONAP can allow other CDs, e.g., Flux 
      (need contributors)
    - DT plans to productize some of the selected ONAP core components 
      early next year 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. 


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

.. |image1| image:: media/ONAP-architecture.png
   :width: 800px
.. |image2| image:: media/ONAP-fncview.png
   :width: 800px
.. |image3| image:: media/ONAP-securityFramework.png
   :width: 800px
.. |image4| image:: media/ONAP-NetworkSlicingOptions.png
   :width: 800px
.. |image5| image:: media/ONAP-closedloop.png
   :width: 800px
.. |image6| image:: media/ONAP-5G.png
   :width: 800px
.. |image7| image:: media/ONAP-5GSuperBP-Integration.png 
   :width: 800px
.. |image8| image:: media/ONAP-vcpe.png
   :width: 800px
.. |image9| image:: media/ONAP-bbs.png
   :width: 800px
.. |image10| image:: media/ONAP-volte.png
   :width: 800px
.. |image11| image:: media/ONAP-ccvpn.png
   :width: 800px
.. |image12| image:: media/ONAP-mdons.png 
   :width: 800px 
.. |image13| image:: media/ONAP-IntentBasedNetworking.png 
   :width: 800px

Browser not supported