Page Status: Done

Last Reviewed on:

Certified by: @Byung-Woo Jun 

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
.. Copyright 2025 ONAP Contributors

.. _ONAP-architecture:

Executive Summary
=================

The ONAP has evolved from a large, monolithic orchestration platform into a set of
modular, semi-standalone network automation functions under the LFN umbrella. This
evolution reflects the needs of telecom, and cloud providers to:

- Automate complex, multi-domain network at scale
- Reduce operational cost and complexity
- Shorten time-to-market for innovative services
- Align with global standards and emerging cloud-native practices

ONAP provides real-time, policy-driven orchestration and automation of physical,
virtual, and cloud-native network automation functions. Its architecture is:

- Modular and layered, enabling independent component lifecycles and semi-standalone
deployments
- Model- and policy-driven, supporting rapid onboarding of new services and technologies
- Cloud-native and GitOps-ready, using Kubernetes, Helm, ArgoCD, and secure CI/CD
- Standards-aligned, integrating ETSI NFV MANO, 3GPP, TMForum, O-RAN, IETF and other
frameworks
- Security-first, adopting Zero-Trust pricinples, service mesh security, SBOM/CBOM, and
OpenSSF best practices
- AI/GenAI-ready preparation, enabling intent-based automation and domain-specific
LLM integration

With the ONAP Streamlining Evolution and Semi-standalone project model, ONAP components
can be consumed individually or in clustered sets, reused by non-ONAP systems, and
integrated more easily with other LFN projects such as O-RAN SC and Nephio. Recent
releases (Paris and Quebec) further strengthen modularity, GitOps-based deployment,
CPS/NCMP capabilities, Intent-driven UUI, security, and observability.

Architecture
============

ONAP has transformed from a monolithic orchestration platform into a modular,
semi-standalone ecosystem for intelligent network automation. It 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. ONAP is positioned to deliver declarative,
intent-based orchestration, integrate advanced GenAI and ML capabilities, and maintain
strong alignment with global telecom standards. Its modular components are now exposed
as LFN functions, enabling seamless integration with other open-source communities.
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 set of
project REST APIs, enabling model-driven interfaces to the networks.

ONAP's modular and layered architecture improves interoperability and simplifies
integration, enabling support for diverse VNF environments by integrating with
various and multiple VIMs, VNFMs, SDN Controllers, and legacy equipment (PNF).
In addition, the ONAP projects provide seamless orchestration of CNFs. ONAP's
consolidated xNF requirements also support 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>'-

Transformation Target
---------------------

No longer a single platform! ONAP is a collection of network automation functions,
that orchestrate and automate network and edge computing services.

- Offers semi-standalone network automation functions within LFN
- Supports building and deploying ONAP components using CI/CD
- Uses standard, API-based interfaces for easier integration
- Allows ONAP components to run independently via GitOps and CD tools
- Moves toward intent-driven architecture aligned with key industry standards (3GPP, ETSI, TMForum, O-RAN, IETF)
- Shifts resource-level orchestration to external tools like O-RAN SC SMO and Nephio
- Maintains strong security support (Service Mesh, Ingress, OAuth2, IdAM)
- Use Git-based onboarding and runtime automation to trigger ONAP functions

Semi-Standalone ONAP Projects
-----------------------------

- ONAP projects are now semi-standalone, managed independently from build to runtime
- Governance teams (TSC, ARCCOM, SECCOM) and common services (OOM, Document) continue to
provide guidance to projects
- ONAP governance keeps its own consultation and oversight cycles to ensure best practices,
architectural consistency, and strong security
- OOM team provides common services such as Istio, Keycloak, argoCD, Flux CD, secure CI/CD,
Helm support and testing
- Documentation team provides the official documentation for ONAP projects
- Each project defines its own release schedule, no longer tied to half-year ONAP cadence
(ending after the Paris release)
- Projects must report key updates to ONAP governance to ensure interoperability
- Modularization allows flexible selection of ONAP sub-components at or after build time

See the Resource page on https://lf-onap.atlassian.net/wiki/spaces/DW/pages/153059629/ONAP+Semi-Standalone+Project+Evolution

ONAP Organization Chart for Semi-Standalone Projects
----------------------------------------------------

- A new ONAP organization chart is in place
- Governance and common services teams continue to guide projects
- ONAP functions will be exposed individually and directly to consumers
- Each ONAP project must report key updates to ONAP governance committees

|image2|

**Figure 2: ONAP Organization Chart.**

- Project with PTLs:
- Projects are active, with new features continuously being added
- Project PTLs control the project release cycles in an agile manner
- Projects will have their own versions (e.g., Helm Chart versions, release versions) based on features
and development cycles
- Documentation will be updated actively
- Projects without PTLs:
- Projects are not deprecated yet because other ONAP projects still use them
- There are no active feature enhancements, but software packages are updated to mitigate software
vulnerabilities
- DT volunteers to handle software package upgrades for SDC, AAI, DCAE and MultiCloud, for the time being
- Once each project decouples its dependencies from projects without PTLs, these projects could become
candidates for deprecation
- documentation will be officially managed by the Documentation team

|image3|

**Figure 3: ONAP Project Release Cycles.**

Component Value Proposition & Why
---------------------------------

Value Proposition
- Comprehensive Network Automation
- Industry Adoption
- Evolving from Complexity to Modularity
- Security & Compliance
- AI and Intent-based Automation
- Open-Source and Community-Driven

Why Choose Components from ONAP and What We can Do with Them?
- Scalability: Handles large-scale network automation and orchestration
- Flexibility: Supports multi-vendor interoperability
- Efficiency: Reduces operational complexity and costs
- Security: Adheres to industry best practices and security protocols
- Future-Ready: Supports 5G, edge computing, AI-driven automation

Monolithic to Modular Transition
--------------------------------

- Initial Architecture: Centralized, tightly coupled platform for orchestration,
management, and policy enforcement

- Transformation Strategy: Component decoupling, independent lifecycle management,
API-driven integration
- Benefits: Rapid adoption in hybrid environments, flexible deployment patterns,
reduced maintenance overhead

|image4|

**Figure 4: ONAP Monolithic to Modular Transition.**

Semi-Standalone Deployment Model
--------------------------------

- Modular components - SO, SDC, Policy, SDNC, CPS, Portal-NG, UUI, A&AI, DCAE,

MultiCloud - function independently
- Enhanced capability with cloud-native environments
- Interoperability frameworks (Service Mesh for secure inter-module communications
and other common services) designed and maintained by ONAP goverance bodies and OOM

|image5|

**Figure 5: ONAP Semi-Standalone Deployment Model.**

Architectural Foundations
-------------------------

1. Intent-Based orchestration

• Intent Processing: Natural language service requests are translated into automation workflows through domain-specific LLMs.

• Human-Readable Intents: Accepts user intents via GUI or NLP/GenAI interfaces for seamless integration.

• LLM Integration: Collaborates with the Intent Analysis Server and LLM Adaptation layer to convert natural language inputs into structured intent specifications.

• Intent Decomposition: Performs parsing, validation, and decomposition of high-level intents into domain-specific sub-intents across network domains.

2. Standards Alignment

• Standards Compliance: Alignment with ETSI NFV MANO, 3GPP specifications, IETF, TMForum Open APIs, O-RAN standards.

• 5G Network Slicing: Orchestration maps to 3GPP specifications (TS 28.530, TS28.531, TS 28.541) for slice lifecycle management.

• O-RAN SMO integration: Support for O1/O2 interfaces, enabling ONAP to orchestrate RAN elements within an open, disaggregated RAN environment.

• Community Engagement: Active participation (IE Active Participation) within LFN for architecture, security, and CI/CD best practices. 

• Model-Driven Configuration: Adoption of ™ Forum YANG models for service and device configuration via NETCONF/RESTCONF.

• Zero Trust Architecture: Implementation aligned with NIST SP 800-207 principles.

• Software Supply Chain Security: Conformance with OpenSSF best practices and SLSA requirements.

• SBOM Transparency: SBOM generation following the SPDX ISO/IEC standard.

• Cryptography Transparency: Exploration of CBOM (Cryptography Bill of Materials) for enhanced cryptographic visibility and compliance

3. Security-First Design

• Service Mesh Security: Istio-based service mesh with mutual TLS (mTLS 1.3) for secure inter-component communication.

• Authentication and Authorization: OAuth2/OIDC integration with Keycloak for centralized identity and access management.

• Open Source Security Compliance: Alignment with OpenSSF best practices - ONAP CPS and Policy components have achieved OpenSSF Gold Badging.

• Centralized Administration: Portal-NG provides unified and secure administrative access across ONAP components.

• Hardened Deployments: Enforced HTTPS-only communication, non-root pod execution, and proactive CVE mitigation for enhanced runtime security.

4. Cloud-Native Microservices

• Kubernetes Deployment: Managed through OOM and MultiCloud with full support for hybrid and multi-cloud infrastructures.

5. Continuous Delivery and GitOps

• CD-based Deployment and Reconciliation: Utilize ArgoCD, (with FluxCD under future consideration) for automated individual component deployment and seamless runtime orchestration upgrades.

Component Function Summary
--------------------------

ONAP individual component functions are as follows:

- SDC (Service Design and Creation): Service/NS/VNF/CNF onboarding, distribution of service models
- SO (Service Orchestrator): Executes workflows for service instantiation, scaling, and healing;
interacts with Multi-Cloud, SDNC and A&AI
- SDNC (Software Defined Network Controller): Handles network-level orchestration, coordinates with
SO to apply configurations
- Multi-Cloud (Infrastructure Abstraction): Supports virtual and containerized workload and deployments,
plugin-based support for different VIMs and K8s distributions
- DCAE (Data Collection, Analytics, and Events): Streamlining data ingestions, hosting analytics apps,
supports runtime policy triggering
- Policy Framework: Execute rules, triggers actions in SO/SDNC, supports guard policies and runtime
policy evaluation
- CPS (Configuration Persistence Service): Provides a lightweight, scalable, model-driven platform to
store, retrieve, and manage configuration data for network functions and services
- A&AI (Active and Available Inventory): Real-time topology awareness, source of truth for orchestration,
tracks lifecycle state of deployed services
- Portal NG: Central access point for ONAP GUIs
- UUI (User Usecase Interfaces): User-centric graphical interface for service order, monitoring, closed-loop
actions, and NLP & GenAI

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

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

|image6|

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

Support of Git and CD-based ONAP Component Installation

- GitOps-Based Deployments: Since the ONAP Paris release, OOM supports individual
deployments using the GitOps approach with tools such as ArgoCD are already in
use at Deutsche Telekom and are included in the ONAP Paris and Quebec releases.
- For more details, 'refer to the official ONAP documentation: <https://docs.onap.org/projects/onap-oom/en/latest/sections/guides/deployment_guides/oom_argo_release_deploy.html>'-

|image7|
 
**Figure 7. ONAP Individual Deployment.**

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.

|image8|
 
**Figure 8. Security Framework component architecture**

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 geographicallydistributed 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 repositoriesfor 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-readablerules 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 withoutrequiring software code rewrites. This abstraction simplifies the managementand control of complex systems.