1 .. This work is licensed under a Creative Commons Attribution
2 .. 4.0 International License.
3 .. http://creativecommons.org/licenses/by/4.0
4 .. Copyright 2017-2018 Huawei Technologies Co., Ltd.
5 .. Copyright 2019 ONAP Contributors
6 .. Copyright 2020 ONAP Contributors
7 .. Copyright 2021 ONAP Contributors
8 .. Copyright 2022 ONAP Contributors
9 .. Copyright 2023 ONAP Contributors
10 .. Copyright 2024 ONAP Contributors
12 .. _ONAP-architecture:
16 ONAP is no longer a platform, rather it provides various network automation
17 functions, and security reference configuration in LFN.
19 ONAP provides network automation functions for orchestration, management, and
20 automation of network and edge computing services for network operators, cloud
21 providers, and enterprises. Real-time, policy-driven orchestration and
22 automation of physical, virtual, and cloud native network functions enables
23 rapid automation of new services and complete lifecycle management critical for
24 5G and next-generation networks, with Intent-based automation and genAI/ML.
26 The ONAP project addresses the need for automation functions for
27 telecommunication, cable, and cloud service providers—and their solution
28 providers—to deliver differentiated network services on demand, profitably and
29 competitively, while leveraging existing investments.
31 The challenge that ONAP meets is to help network operators keep up with the
32 scale and cost of manual changes required to implement new service offerings,
33 from installing new data center equipment to, in some cases, upgrading
34 on-premises customer equipment. Many are seeking to exploit SDN and NFV to
35 improve service velocity, simplify equipment interoperability and integration,
36 and to reduce overall CapEx and OpEx costs. In addition, the current, highly
37 fragmented management landscape makes it difficult to monitor and guarantee
38 service-level agreements (SLAs).
40 ONAP is addressing these challenges by developing global and massive scale
41 (multi-site and multi-VIM) automation capabilities for physical, virtual, and
42 cloud native network elements. It facilitates service agility by supporting
43 data models for rapid service and resource deployment and providing a common
44 set of northbound REST APIs that are open and interoperable, and by supporting
45 model-driven interfaces to the networks. ONAP’s modular and layered nature
46 improves interoperability and simplifies integration, allowing it to support
47 1) multiple VNF environments by integrating with multiple VIMs, VNFMs, SDN
48 Controllers, as well as legacy equipment (PNF) and 2) Cloud Native environments
49 by integrating Kubernetes, CNFMs and other controllers. The Service Design &
50 Creation (SDC) project also offers seamless orchestration of CNFs. ONAP’s
51 consolidated xNF requirements publication enables commercial development of
52 ONAP-compliant xNFs. This approach allows network and cloud operators to
53 optimize their physical, virtual and cloud native infrastructure for cost and
54 performance; at the same time, ONAP’s use of standard models reduces
55 integration and deployment costs of heterogeneous equipment. All this is
56 achieved while minimizing management fragmentation.
58 The ONAP allows end-user organizations and their network/cloud providers to
59 collaboratively instantiate network elements and services in a rapid and
60 dynamic way, together with supporting a closed control loop process that
61 supports real-time response to actionable events. In order to design, engineer,
62 plan, bill and assure these dynamic services, there are three major
65 - A robust design framework that allows the specification of the service in all
66 aspects – modeling the resources and relationships that make up the service,
67 specifying the policy rules that guide the service behavior, specifying the
68 applications, analytics and closed control loop events needed for the elastic
69 management of the service
70 - An orchestration and control framework (Service Orchestrator and Controllers)
71 that is recipe/ policy-driven to provide an automated instantiation of the
72 service when needed and managing service demands in an elastic manner
73 - An analytic framework that closely monitors the service behavior during the
74 service lifecycle based on the specified design, analytics and policies to
75 enable response as required from the control framework, to deal with
76 situations ranging from those that require healing to those that require
77 scaling of the resources to elastically adjust to demand variations.
79 To achieve this, ONAP decouples the details of specific services and supporting
80 technologies from the common information models, core orchestration components,
81 and generic management engines (for discovery, provisioning, assurance etc.).
83 Furthermore, it marries the speed and style of a DevOps/NetOps approach with
84 the formal models and processes operators require to introduce new services and
85 technologies. It leverages cloud-native technologies including Kubernetes to
86 manage and rapidly deploy the ONAP and related components. This is in
87 stark contrast to traditional OSS/Management software architectures,
88 which hardcoded services and technologies, and required lengthy software
89 development and integration cycles to incorporate changes.
91 The ONAP enables service/resource independent capabilities for design,
92 creation and lifecycle management, in accordance with the following
93 foundational principles:
95 - Ability to dynamically introduce full service lifecycle orchestration
96 (design, provisioning and operation) and service API for new services and
97 technologies without the need for new software releases or without
98 affecting operations for the existing services
99 - Scalability and distribution to support a large number of services and large
101 - Metadata-driven and policy-driven architecture to ensure flexible and
102 automated ways in which capabilities are used and delivered
103 - The architecture shall enable sourcing best-in-class components
104 - Common capabilities are ‘developed’ once and ‘used’ many times
105 - Core capabilities shall support many diverse services and infrastructures
107 Further, ONAP comes with a functional architecture with component definitions
108 and interfaces, which provides a force of industry alignment in addition to
109 the open source code.
111 Architecture Overview
112 ---------------------
114 The ONAP architecture consists of a design time and run time functions, as well
115 as functions for managing ONAP itself.
117 Note: Use the interactive features of the below ONAP Architecture Overview.
118 Click to enlarge it. Then hover with your mouse over an element in the
119 figure for a short description. Click the element to get forwarded to a more
120 detailed description.
122 .. image:: media/onap-architecture-overview-interactive-path.svg
125 **Figure 1: Interactive high-level view of the ONAP architecture with its
126 microservices-based components. Click to enlarge and discover.**
128 The figure below provides a simplified functional view of the architecture,
129 which highlights the role of a few key components:
131 #. ONAP Design time environment provides onboarding services and resources
132 into ONAP and designing required services.
133 #. External API provides northbound interoperability for the ONAP.
134 #. ONAP Runtime environment provides a model- and policy-driven orchestration
135 and control framework for an automated instantiation and configuration of
136 services and resources. Multi-VIM/Cloud provides cloud interoperability for
137 the ONAP workloads. Analytic framework that closely monitors the service
138 behavior handles closed control loop management for handling healing,
139 scaling and update dynamically.
140 #. OOM provides the ability to manage cloud-native installation and deployments
141 to Kubernetes-managed cloud environments.
142 #. ONAP Shared Services provides shared capabilities for ONAP modules. The ONAP
143 Optimization Framework (OOF) provides a declarative, policy-driven approach
144 for creating and running optimization applications like Homing/Placement,
145 and Change Management Scheduling Optimization. The Security Framework uses
146 open-source security patterns and tools, such as Istio, Ingress Gateway,
147 oauth2-proxy, and Keycloak. This Security Framework makes ONAP secure
148 external and inter-component communications, authentication and
150 Logging Framework (reference implementation PoC) supports open-source- and
151 standard-based logging. It separates application log generation from log
152 collection/aggregation/persistence/visualization/analysis; i.e., ONAP
153 applications handle log generation only and the Logging Framework stack will
154 handle the rest. As a result, operators can leverage/extend their own
156 #. ONAP shared utilities provide utilities for the support of the ONAP
159 Microservice BUS (MSB) is obsolete from Montreal release. Its function has
160 been replaced by Istio Service Mesh, Ingress and IdAM (Keycloak) for secure
161 internal and external communications and security authentication and
164 Information Model and framework utilities continue to evolve to harmonize
165 the topology, workflow, and policy models from a number of SDOs including
166 ETSI NFV MANO, ETSI/3GPP, O-RAN, TM Forum SID, ONF Core, OASIS TOSCA, IETF,
171 **Figure 2. Functional view of the ONAP architecture**
173 Introduction of ONAP Streamlining evolution
174 -------------------------------------------
177 Previously, ONAP as a platform had shown e2e network automation to the
178 industry. Operators, vendors and enterprises have learned how service/network
179 automation (modeling, orchestration, policy-based closed loop, optimization,
180 etc.) works on VM and Cloud-native environments for VNF, PNF, CNF, NS,
181 Network/RAN slicing and e2e service thru ONAP.
182 In ONAP, there are numerous valuable use cases, that leverage and coordinate
183 clusters of ONAP component functions (e.g., SDC, SO, A&AI, DCAE, SDNC, SDNR,
184 CPS, CDS...) to achieve objectives, such as:
190 - ETSI-based NS & VNF orchestration
191 - Helm-based CNF orchestration
192 - ASD-based (including Helm) CNF orchestration
194 Now, the operators, vendors and enterprises want to select and apply ONAP
195 functions to their portfolio. No one needs to take ONAP as a whole.
199 The goal is to continue to support the current ONAP use cases efficiently for
200 use in commercial production environments and portfolio. We expect the industry
201 wants to pick and choose desired ONAP component functions, swap some of the
202 ONAP functions, and integrate those functions into their portfolio seamlessly,
203 without bringing in a whole ONAP platform.
204 ONAP Streamlining, which drives individual components and clusters of
205 components guided by use cases, will enable the flexible and dynamic function
206 adoption by the industry
208 ONAP Streamlining Transformation
209 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
210 Thru ONAP Streamlining, ONAP is no longer a platform, rather it provides
211 various network automation functions, and security reference configuration in
212 LFN. ONAP enables individual ONAP function build, and component deployment
213 thru CD. It will build use cases for repository-based E2E service, NS, CNF and
214 CNA onboarding, and CD-based ONAP component triggering mechanism with
215 abstracted interfaces for choreography. It will boost standard-based abstracted
216 interfaces with declarative APIs, i.e., each component will be autonomous and
217 invoked from any level of network automation, by leveraging CD mechanisms, such
218 as GitOps and CD readiness.
220 ONAP will become more intent-based and declarative, and bring in genAI/ML,
221 conforming to standards such as 3GPP, TMForum, ETSI, IETF, O-RAN, etc. For
222 example, UUI user intent support and AI-based natural language translation, on
223 top of that, applying coming 3GPP and TMForum models and APIs. Also, it will
224 delegate resource-level orchestration to functions from the external community,
225 such as O-RAN SC and Nephio.
227 For security, ONAP continues to support the Service Mesh, Ingress, OAuth2,
228 IdAM-based authentication and authorization, and considers sidecar-less
229 solutions for NF security.
233 **Figure 3. ONAP Streamlining evolution**
235 ONAP Component Design Requirements
236 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
237 - ONAP components should be designed not only for ONAP but also non-ONAP
239 - ONAP component dependencies and couplings to other ONAP components should
240 not be in an ONAP-specific way.
241 - Making each ONAP component should be 'stand-alone', so potential users can
242 take a single component, without getting involved in the whole of ONAP.
243 - ONAP component interactions should be based on standards and extensible to
244 facilitate integration with other systems, especially for non-ONAP.
245 - ONAP component Helm charts in OOM should be re-written to build/deploy a
246 component individually.
247 - ONAP Security mechanisms should be industry standard/de facto-based to
248 integrate with vendor/operator security and logging.
249 - Timelines and cadence of the ONAP release should be flexible for
250 accommodating different release strategies.
252 ONAP Component Design, Build & Deployment
253 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
254 ONAP components are independently deployable pieces of software, built out of
255 one more microservices:
258 - Extensible and substitutional
260 ONAP Network Automation processes will manage more intent-based operations
262 - Manage use and other intents and translations
263 - Study on TMForum and 3GPP intent models and APIs
265 ONAP components conform to the standards and de facto specifications to enable
266 plug- and-play and pick-and-choose facilitation.
268 ONAP repository-based SW management enables smaller imperative actions that
269 can be triggered by different events in the orchestration and SW LCM flow.
270 Events can trigger different types of deployment automation jobs or chains of
271 automation jobs (pipelines).
273 In Jenkins ONAP OOM build scripts will be used for ONAP component builds and
274 will store built ONAP components into the Artifact Repository (e.g., Nexus).
275 This can be changed. CD (e.g., ArgoCD, Flux, others) will be used to
276 pick-and-choose ONAP components.
280 **Figure 4. ONAP Streamlining Component Build and Deployment**
282 For more details of ONAP streamlining, see the ONAP Streamlining - The Process
283 page, https://wiki.onap.org/display/DW/ONAP+Streamlining+-+The+Process
285 Microservices Support
286 ---------------------
287 As a cloud-native application that consists of numerous services, ONAP requires
288 sophisticated initial deployment as well as post- deployment management.
290 ONAP is no longer a platform, rather it provides network automation functions,
291 and security reference configuration in LFN.
293 Thru ONAP Streamlining evolution, the ONAP deployment methodology has been
294 enhanced, allowing individual ONAP components can be picked up through a chosen
295 CD (Continuous Deployment) tool. This enhancement should be flexible enough to
296 suit the different scenarios and purposes for various operator environments.
297 Users may also want to select a portion of the ONAP components to integrate
298 into their own systems. For more details of ONAP Streamlining evolution, see
299 the ONAP Streamlining evolution session.
301 The provided ONAP functions are highly reliable, scalable, extensible, secure
302 and easy to manage. To achieve all these goals, ONAP is designed as a
303 microservices-based system, with all components released as Docker containers
304 following best practice building rules to optimize their image size. Numerous
305 optimizations such as shared databases and the use of standardized lightweight
306 container operating systems reduce the overall ONAP footprint.
308 In the spirit of leveraging the microservice capabilities, further steps
309 towards increased modularity have been taken. Service Orchestrator (SO) and the
310 controllers have increased its level of modularity, by following Microservices.
312 ONAP Operations Manager (OOM)
313 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
314 The ONAP Operations Manager (OOM) is responsible for orchestrating the
315 end-to-end lifecycle management and monitoring of ONAP components. OOM uses
316 Kubernetes with IPv4 and IPv6 support to provide CPU efficiency and ONAP
317 component deployment. In addition, OOM helps enhance ONAP maturity by providing
318 scalability and resiliency enhancements to the components it manages.
320 OOM is the lifecycle manager of the ONAP and uses the Kubernetes
321 container management system and Consul to provide the following functionality:
323 #. Deployment - with built-in component dependency management (including
324 multiple clusters, federated deployments across sites, and anti-affinity
326 #. Configuration - unified configuration across all ONAP components
327 #. Monitoring - real-time health monitoring feeding to a Consul GUI and
329 #. Restart - failed ONAP components are restarted automatically
330 #. Clustering and Scaling - cluster ONAP services to enable seamless scaling
331 #. Upgrade - change out containers or configuration with little or no service
333 #. Deletion - clean up individual containers or entire deployments
335 OOM supports a wide variety of cloud infrastructures to suit your individual
338 OOM provides Service Mesh-based mTLS (mutual TLS) between ONAP components to
339 secure component communications, by leveraging Istio.
341 In addition to Service Mesh-based mTLS, OOM also provides inter-component
342 authentication and authorization, by leveraging Istio Authorizaiton Policy.
343 For external secure communication, authentication (including SSO) and
344 authorization, OOM configures Ingress, oauth2-proxy, IAM (realized by
347 As the result, Unmaintained AAF functionalities are obsolete and substituted
348 by Istio-based Service Mesh and Ingress, as of Montreal release.
352 **Figure 5. Security Framework component architecture**
354 For OOM enhancements for ONAP Streamlining evolution, see the ONAP Streamlining
357 Microservices Bus (MSB)
358 ^^^^^^^^^^^^^^^^^^^^^^^
360 .. warning:: The ONAP :strong:`MSB` project is :strong:`deprecated`.
361 As of Release 13 'Montreal' the component is no longer part of the
364 Microservices Bus (MSB) used to support service registration/ discovery,
365 external API gateway, internal API gateway, client software development
366 kit (SDK), and Swagger SDK. When integrating with OOM, MSB used to have
367 a Kube2MSB registrar which can grasp services information from k8s metafile
368 and automatically register the services for ONAP components.
370 In London release, ONAP Security Framework components provide secure
371 communication capabilities. This approach is a more Kubernetes-native approach.
372 As a result, MSB functions has been replaced by the Security Framework, and MSB
373 becomes an optional component.
377 ONAP had a portal project but this project was terminated and archived.
378 Portal-NG is a new component and fills the gap. It provides a state of the art
379 web-based GUI that services as the first discovery point for the ONAP, its
380 existing web applications and functions.
381 Onboard users with an adaptive GUI following a "grow as you go" approach
382 covering "playful discovery" up to expert mode. Wherever possible hide
383 complexity of network automation by guiding the user.
384 The Portal-NG supports new ONAP Security framework for user administration,
385 authentication and authorization. For more details, see the Portal-NG section.
387 Design Time Components
388 ----------------------
389 The design time components are a comprehensive development environment with
390 tools, techniques, and repositories for defining/ describing resources,
391 services, and products.
393 The design time components facilitate reuse of models, further improving
394 efficiency as more and more models become available. Resources, services,
395 products, and their management and control functions can all be modeled using a
396 common set of specifications and policies (e.g., rule sets) for controlling
397 behavior and process execution. Process specifications automatically sequence
398 instantiation, delivery and lifecycle management for resources, services,
399 products and the ONAP components themselves. Certain process specifications
400 (i.e., ‘recipes’) and policies are geographically distributed to optimize
401 performance and maximize autonomous behavior in federated cloud environments.
403 Service Design and Creation (SDC)
404 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
405 Service Design and Creation (SDC) provides tools, techniques, and repositories
406 to define/simulate/certify system assets as well as their associated processes
407 and policies. Each asset is categorized into one of four asset groups: Resource
408 , Services, Products, or Offers. SDC supports the onboarding of Network
409 Services packages (ETSI SOL007 with ETSI SOL001), ONAP proprietary CNF packages
410 (embedding Helm Chart), ASD-based CNF packages (ETSI SOL004 and embedding Helm
411 Chart), VNF packages (Heat or ETSI SOL004) and PNF packages (ETSI SOL004). SDC
412 also includes some capabilities to model 5G network slicing using the standard
413 properties (Slice Profile, Service Template).
415 Since Kohn-R11 release, SDC supports the onboarding of another CNF-Modeling
416 package, Application Service Description (ASD) package. ASD is a deployment
417 descriptor for cloud native applications/functions. It minimizes information
418 needed for the CNF orchestrator, by referencing most resource descriptions to
419 the cloud native artifacts (e.g., Helm Chart). Its CSAR package adheres to
422 The SDC environment supports diverse users via common services and utilities.
423 Using the design studio, product and service designers onboard/extend/retire
424 resources, services and products. Operations, Engineers, Customer Experience
425 Managers, and Security Experts create workflows, policies and methods to
426 implement Closed Control Loop Automation/Control and manage elastic
429 Vendors can integrate these tools in their CI/CD environments to package VNFs
430 and upload them to the validation engine. Once tested, the VNFs can be onboarded
431 through SDC. ONAP supports onboarding of CNFs and PNFs as well.
433 The Policy Creation component deals with policies; these are rules, conditions,
434 requirements, constraints, attributes, or needs that must be provided,
435 maintained, and/or enforced. At a lower level, Policy involves machine-readable
436 rules enabling actions to be taken based on triggers or requests. Policies
437 often consider specific conditions in effect (both in terms of triggering
438 specific policies when conditions are met, and in selecting specific outcomes
439 of the evaluated policies appropriate to the conditions).
441 Policy allows rapid modification through easily updating rules, thus updating
442 technical behaviors of components in which those policies are used, without
443 requiring rewrites of their software code. Policy permits simpler
444 management / control of complex mechanisms via abstraction.
449 .. warning:: The ONAP :strong: 'VNF SDK' project is :strong:'deprecated'.
451 VNF SDK provides the functionality to create VNF/PNF packages, test VNF
452 packages and VNF ONAP compliance and store VNF/PNF packages and upload to/from
458 .. warning:: The ONAP :strong: 'VVP' project is :strong:'deprecated'.
460 VVP provides validation for the VNF Heat package.
464 The runtime execution components execute the rules and policies and other
465 models distributed by the design and creation environment.
467 This allows for the distribution of models and policy among various ONAP
468 modules such as the Service Orchestrator (SO), Controllers, Data Collection,
469 Analytics and Events (DCAE), Active and Available Inventory (A&AI). These
470 components use common services that support security (access control,
471 secure communication), logging and configuration data.
475 The Service Orchestrator (SO) component executes the specified processes by
476 automating sequences of activities, tasks, rules and policies needed for
477 on-demand creation, modification or removal of network, application or
478 infrastructure services and resources, this includes VNFs, CNFs and PNFs,
479 by conforming to industry standards such as ETSI, TMF, 3GPP.
480 The SO provides orchestration at a very high level, with an end-to-end view
481 of the infrastructure, network, and applications. Examples of this include
482 BroadBand Service (BBS) and Cross Domain and Cross Layer VPN (CCVPN).
483 The SO is modular and hierarchical to handle services and multi-level
484 resources and Network Slicing, by leveraging pluggable adapters and delegating
485 orchestration operations to NFVO (SO NFVO, VFC), VNFM, CNF Manager, NSMF
486 (Network Slice Management Function), NSSMF (Network Slice Subnet Management
489 Starting from the Guilin release, the SO provides CNF orchestration support
490 through integration of CNF adapter and other CNF managers in ONAP. SO:
492 - Support for provisioning CNFs using an external K8S Manager
493 - Support the Helm-based orchestration
494 - Leverage the CNF Adapter to interact with the K8S Plugin in MultiCloud, or
495 leverage the CNF Manager to interact with the K8S to control CNFs (e.g., ASD)
496 - Bring in the advantage of the K8S orchestrator and
497 - Set stage for the Cloud Native scenarios
499 In London, ONAP SO added ASD-based CNF orchestration support to simplify
500 CNF orchestration and to remove redundancies of CNF resource attributes and
501 orchestration process.
503 - Support for onboarding of ASD-based CNF models and packages in runtime
504 - Support the SO sub-component 'SO CNFM' for ASD-dedicated CNF orchestration
505 to isolate ASD management from other SO components - separation of concerns
506 - Use of ASD for AS LCM, and use of associated Helm Charts for CNF deployment
507 to the selected external K8s Clusters
508 - Use of Helm Client to communicate with external K8S clusters for CNF
510 - Monitoring deployed K8S resources thru Kubernetes APIs
512 3GPP (TS 28.801) defines three layer slice management function which include:
514 - CSMF (Communication Service Management Function)
515 - NSMF (Network Slice Management Function)
516 - NSSMF (Network Slice Subnet Management Function)
518 To realize the three layers, CSMF, NSMF and/or NSSMF are realized within ONAP,
519 or use the external CSMF, NSMF or NSSMF. For ONAP-based network slice
520 management, different choices can be made as follows. Among them, ONAP
521 orchestration currently supports options #1 and #4.
525 **Figure 6: ONAP Network Slicing Support Options**
528 Virtual Infrastructure Deployment (VID) - obsolete
529 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
531 .. warning:: The ONAP :strong:`vid` project is :strong:`deprecated`.
532 As of Release 12 'London' the component is no longer part of the
535 The Virtual Infrastructure Deployment (VID) application enables users to
536 instantiate infrastructure services from SDC, along with their associated
537 components, and to execute change management operations such as scaling and
538 software upgrades to existing VNF instances.
540 Policy-Driven Workload Optimization
541 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
543 .. warning:: The ONAP :strong:'OOF' project is :strong:'deprecated'.
545 The ONAP Optimization Framework (OOF) provides a policy-driven and model-driven
546 framework for creating optimization applications for a broad range of use
547 cases. OOF Homing and Allocation Service (HAS) is a policy driven workload
548 optimization service that enables optimized placement of services across
549 multiple sites and multiple clouds, based on a wide variety of policy
550 constraints including capacity, location, other service capabilities and
553 ONAP Multi-VIM/Cloud (MC) and several other ONAP components such as Policy, SO,
554 A&AI etc. play an important role in enabling “Policy-driven Performance/
555 Security-Aware Adaptive Workload Placement/ Scheduling” across cloud sites
556 through OOF-HAS. OOF-HAS uses cloud agnostic Intent capabilities, and real-time
557 capacity checks provided by ONAP MC to determine the optimal VIM/Cloud
558 instances, which can deliver the required performance SLAs, for workload
559 (VNF, etc.) placement and scheduling (Homing). Operators now realize the true
560 value of virtualization through fine grained optimization of cloud resources
561 while delivering performance and security SLAs.
565 Controllers are applications which are coupled with cloud and network services
566 and execute the configuration, real-time policies, and control the state of
567 distributed components and services. Rather than using a single monolithic
568 control layer, operators may choose to use multiple distinct controller types
569 that manage resources in the execution environment corresponding to their
570 assigned controlled domain such as cloud computing resources (SDN-C).
571 The Virtual Function Controller (VF-C) and SO NFVO provide an ETSI NFV
572 compliant NFVO function that is responsible for lifecycle management of
573 virtual services and the associated physical COTS server infrastructure. VF-C
574 provides a generic VNFM capability, and both VF-C and SO NFVO integrate with
575 external VNFMs and VIMs as part of an NFV MANO stack.
577 .. warning:: The ONAP :strong:`appc` project is :strong:`deprecated`.
578 As of Release 12 'London' the component is no longer part of the
580 .. warning:: The ONAP :strong:'VF-C' project is :strong:'deprecated'.
582 ONAP used to have two application level configuration and lifecycle management
583 modules called SDN-C and App-C. App-C is no longer part of ONAP deployment.
584 SDN-C provides controller services (application level configuration using
585 NetConf, Chef, Ansible, RestConf, etc.) and lifecycle management functions
586 (e.g., stop, resume, health check, etc.).
587 SDN-C uses common code from CCSDK repo, and it uses CDS only for onboarding and
588 configuration / LCM flow design.
589 SDN-C has been used for Layer1-7 network elements. ONAP Controller configures
590 and maintains the health of L1-7 Network Function (VNF, PNF, CNF) and network
591 services throughout their lifecycle:
593 - Configures Network Functions (VNF/PNF)
594 - Provides programmable network application management:
596 - Behavior patterns programmed via models and policies
597 - Standards based models & protocols for multi-vendor implementation
598 - Extensible SB adapters such as Netconf, Ansible, Rest API, etc.
599 - Operation control, version management, software updates, etc.
600 - Local source of truth
601 - Manages inventory within its scope
602 - Manages and stores state of NFs
603 - Supports Configuration Audits
605 Controller Design Studio (CDS)
606 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
607 The Controller Design Studio (CDS) community in ONAP has contributed a
608 framework to automate the resolution of resources for instantiation and any
609 config provisioning operation, such as day0, day1 or day2 configuration. The
610 essential function of CDS is to create and populate a controller blueprint,
611 create a configuration file from this Controller blueprint, and associate at
612 design time this configuration file (configlet) to a PNF/VNF/CNF during the
613 design phase. CDS removes dependence on code releases and the delays they cause
614 and puts the control of services into the hands of the service providers. Users
615 can change a model and its parameters with great flexibility to fetch data from
616 external systems (e.g., IPAM) that is required in real deployments. This makes
617 service providers more responsive to their customers and able to deliver
618 products that more closely match the needs of those customers.
622 Active and Available Inventory (A&AI) provides real-time views of a system’s
623 resources, services, products and their relationships with each other, and also
624 retains a historical view. The views provided by A&AI relate data managed by
625 multiple ONAP instances, Business Support Systems (BSS), Operation Support
626 Systems (OSS), and network applications to form a “top to bottom” view ranging
627 from the products end users buy, to the resources that form the raw material
628 for creating the products. A&AI not only forms a registry of products,
629 services, and resources, it also maintains up-to-date views of the
630 relationships between these inventory items.
632 To deliver the promised dynamism of SDN/NFV, A&AI is updated in real time by
633 the controllers as they make changes in the network environment. A&AI is
634 metadata-driven, allowing new inventory types to be added dynamically and
635 quickly via SDC catalog definitions, eliminating the need for lengthy
638 Multi Cloud Adaptation
639 ^^^^^^^^^^^^^^^^^^^^^^
640 Multi-VIM/Cloud provides and infrastructure adaptation layer for VIMs/Clouds
641 and K8s clusters in exposing advanced cloud agnostic intent capabilities,
642 besides standard capabilities, which are used by OOF and other components
643 for enhanced cloud selection and SO/VF-C for cloud agnostic workload
644 deployment. The K8s plugin is in charge of deploying CNFs on the Kubernetes
645 clusters using Kubernetes APIs.
647 Data Collection Analytics and Events (DCAE)
648 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
649 DCAE provides the capability to collect events, and host analytics applications
650 (DCAE Services). It gathers performance, usage, and configuration data from
651 the managed environment. Data is fed to various analytic applications, and if
652 anomalies or significant events are detected, the results trigger appropriate
653 actions, such as publishing to other ONAP components such as Policy, SO, or
656 - Collect, ingest, transform and store data as necessary for analysis
657 - Provide a framework for development of analytics
661 The Policy framework is a comprehensive policy design, deployment,
662 and execution environment. The Policy Framework is the decision making
663 comopnent in an ONAP system. It allows to specify, deploy, and execute
664 the governance of the features and functions in ONAP system, support
665 the closed loop, orchestration, or more traditional open loop use case
668 Since the Istanbul release, the CLAMP is officially integrated into the
669 Policy component. CLAMP's functional role to provision Policy has been
670 enhanced to support provisioning of policies outside of the context of
671 a Control Loop and therefore act as a Policy UI. For CLAMP details, see
672 the Policy - CLAMP section.
674 It supports multiple policy engines and can distribute policies through policy
675 design capabilities in SDC, simplifying the design process.
677 Closed Control Loop Automation Management Platform in Policy (Policy - CLAMP)
678 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
680 .. warning:: The ONAP :strong:`CLAMP` function is now part of :strong:`Policy`.
682 Closed loop control is provided by cooperation among a number of design-time
683 and run-time elements. The Runtime loop starts with data collectors from Data
684 Collection, Analytics and Events (DCAE). ONAP includes the following collectors
685 : VES (VNF Event Streaming) for events, HV-VES for high-volume events, SNMP
686 for SNMP traps, File Collector to receive files, and RESTCONF Collector to
687 collect the notifications. After data collection/verification phase, data move
688 through the loop of micro-services like Homes for event detection, Policy
689 for determining actions, and finally, controllers and orchestrators to
690 implement actions. The Policy framework is also used to monitor the loops
691 themselves and manage their lifecycle. DCAE also includes a number of
692 specialized micro-services to support some use-cases such as the Slice Analysis
693 or SON-Handler. Some dedicated event processor modules transform collected data
694 (SNMP, 3GPP XML, RESTCONF) to VES format and push the various data into data
695 lake. CLAMP, Policy and DCAE all have design time aspects to support the
696 creation of the loops.
698 We refer to this automation pattern as “Closed Control loop automation” in that
699 it provides the necessary automation to proactively respond to network and
700 service conditions without human intervention. A high-level schematic of the
701 “Closed control loop automation” and the various phases within the service
702 lifecycle using the automation is depicted in Figure 4.
704 Closed control loop control is provided by Data Collection, Analytics and
705 Events (DCAE) and one or more of the other ONAP runtime components.
706 Collectively, they provide FCAPS (Fault Configuration Accounting Performance
707 Security) functionality. DCAE collects performance, usage, and configuration
708 data; provides computation of analytics; aids in troubleshooting; and publishes
709 events, data and analytics (e.g., to policy, orchestration, and the data lake).
710 Another component, Holmes, connects to DCAE and provides alarm correlation
711 for ONAP, new data collection capabilities with High Volume VES, and bulk
712 performance management support.
714 Working with the Policy Framework (and embedded CLAMP), these components
715 detect problems in the network and identify the appropriate remediation.
716 In some cases, the action will be automatic, and they will notify the
717 Service Orchestrator or one of the controllers to take action.
718 In other cases, as configured by the operator, they will raise an alarm
719 but require human intervention before executing the change. The policy
720 framework is extended to support additional policy decision capabilities
721 with the introduction of adaptive policy execution.
723 Starting with the Honolulu-R8 and concluding in the Istanbul-R9 release, the
724 CLAMP component was successfully integrated into the Policy component initially
725 as a PoC in the Honolulu-R8 release and then as a fully integrated component
726 within the Policy component in Istanbul-R9 release.
727 CLAMP's functional role to provision Policy has been enhanced to support
728 provisioning of policies outside of the context of a Control Loop and therefore
729 act as a Policy UI. In the Istanbul release the CLAMP integration was
734 **Figure 7: ONAP Closed Control Loop Automation**
736 Virtual Function Controller (VFC)
737 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
739 .. warning:: The ONAP :strong:'VFC' project is :strong:'deprecated'.
741 VFC provides the NFVO capability to manage the lifecycle of network service and
742 VNFs, by conforming to ETSI NFV specification.
744 Data Movement as a Platform (DMaaP)
745 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
747 .. warning:: The ONAP :strong:'DMaaP MR' project is :strong:'deprecated'.
749 DMaaP provides data movement services that transports and process data from
750 any source to any target. Its message routing is deprecated in New Delhi release
751 and replaced by Strimzi and Kafka. The data routing is still part of New
752 Delhi release, but it will be deprecated in Oslo release.
756 UUI provides the capability to instantiate the blueprint User Cases and
757 visualize the state. UUI is an application portal which provides the ability
758 to manage ONAP service instances. It allows customers to create/delete/update
759 service instances, as well as monitoring, alarms and performance of
762 The component supports the following functionalities:
763 - Customer Management
764 - Package Management (including IBN packages)
765 - Service Management (including CCVPN, 5G Slicing, Intent-based automation)
768 UUI contains the following sub-components:
771 - UUI NLP Server (since Istanbul release)
772 - UUI INTENT ANALYSIS server (since Kohn release)
774 See UUI Component Architecture,
778 **Figure 8. UUI Component Architecture**
783 .. warning:: The ONAP :strong:'CLI' project is :strong:'deprecated'.
785 ONAP CLI provides a command line interface for access to ONAP.
790 .. warning:: The ONAP :strong:`externalapi` project is :strong:`unmaintained`.
792 External APIs provide services to expose the capability of ONAP.
797 .. warning:: The ONAP :strong:'Logging Framework' project is a reference
800 ONAP provides a set of operational services for all ONAP components including
801 activity logging, reporting, common data layer, configuration, persistence,
802 access control, secret and credential management, resiliency, and software
803 lifecycle management.
805 ONAP Shared Services provide shared capabilities for ONAP modules. These
806 services handle access management and security enforcement, data backup,
807 configuration persistence, restoration and recovery. They support standardized
808 VNF interfaces and guidelines.
810 Optimization Framework (OOF)
811 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
813 .. warning:: The ONAP :strong:'OOF' project is :strong:'deprecated'.
815 OOF provides a declarative, policy-driven approach for creating and running
816 optimization applications like Homing/Placement, and Change Management
817 Scheduling Optimization.
821 The Security Framework uses open-source security patterns and tools, such as
822 Istio, Ingress Gateway, oauth2-proxy, and KeyCloak. This Security Framework
823 provides secure external and inter-component communications, authentication,
826 For more details, see the Figure 5.
828 Logging Framework (PoC)
829 ^^^^^^^^^^^^^^^^^^^^^^^
831 .. warning:: The ONAP :strong:`Logging Framework` project is a reference
832 implementation :strong:`PoC`.
834 Logging Framework supports open-source and standard-based logging. It separates
835 the application log generation from the log collection/aggregation/persistence/
836 visualization/analysis; i.e., ONAP applications handle log generation only, and
837 the Logging Framework stack will handle the rest. As a result, operators can
838 leverage/extend their own logging stacks.
840 Configuration Persistence Service (CPS)
841 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
842 The Configuration Persistence Service (CPS) provides storage for real-time
843 run-time configuration and operational parameters that need to be used by ONAP.
844 Several services ranging from SDN-C, DCAE and the network slicing use case
845 utilize CPS for these purposes. In Montreal release, a CPS sub-component CPS-
846 Temporal is removed because its function is no longer needed.
847 Its details in :ref:`CPS - Configuration Persistence Service<onap-cps:architecture>`.
852 .. warning:: The ONAP :strong:'ONAP Modeling' project is :strong:'deprecated'.
854 ONAP provides models to assist with service design, the development of ONAP
855 service components, and with the improvement of standards interoperability.
856 Models are an essential part for the design time and runtime framework
857 development. The ONAP modeling project leverages the experience of member
858 companies, standard organizations and other open source projects to produce
859 models which are simple, extensible, and reusable. The goal is to fulfill the
860 requirements of various use cases, guide the development and bring consistency
861 among ONAP components and explore a common model to improve the
862 interoperability of ONAP.
864 ONAP supports various models detailed in the Modeling documentation.
866 A new CNF modeling descriptor, Application Service Description (ASD), has been
867 added to ONAP since the Kohn release. It is to simplify CNF modeling and
868 orchestration by delegating resource modeling to Kubernetes-based resource
869 descriptors (e.g., Helm Chart).
871 The modeling project includes the ETSI catalog component, which provides the
872 parser functionalities, as well as additional package management
877 ONAP support and collaboration with other standards and open source communities
878 is evident in the architecture.
880 - MEF and TMF interfaces are used in the External APIs
881 - In addition to the ETSI-NFV defined VNFD and NSD models mentioned above, ONAP
882 supports the NFVO interfaces (SOL005 between the SO and VFC, SOL003 from
883 either the SO or VFC to an external VNFM).
884 - Further collaboration includes 5G/ORAN & 3GPP Harmonization, Acumos DCAE
885 Integration, and CNCF Telecom User Group (TUG).
887 Read this whitepaper for more information:
888 `The Progress of ONAP: Harmonizing Open Source and Standards <https://www.onap.org/wp-content/uploads/sites/20/2019/04/ONAP_HarmonizingOpenSourceStandards_032719.pdf>`_
892 ONAP can support an unlimited number of use cases, within reason. However, to
893 provide concrete examples of how to use ONAP to solve real-world problems, the
894 community has created a set of blueprints. In addition to helping users rapidly
895 adopt the ONAP through end-to-end solutions, these blueprints also
896 help the community prioritize their work.
900 The 5G blueprint is a multi-release effort, with five key initiatives around
901 end-to-end service orchestration, network slicing, PNF/VNF lifecycle management
902 , PNF integration, and network optimization. The combination of eMBB that
903 promises peak data rates of 20 Mbps, uRLLC that guarantees sub-millisecond
904 response times, MMTC that can support 0.92 devices per sq. ft., and network
905 slicing brings with it some unique requirements. First ONAP needs to manage the
906 lifecycle of a network slice from initial creation/activation all the way to
907 deactivation/termination. Next, ONAP needs to optimize the network around real
908 time and bulk analytics, place VNFs on the correct edge cloud, scale and heal
909 services, and provide edge automation. ONAP also provides self organizing
910 network (SON) services such as physical cell ID allocation for new RAN sites.
911 These requirements have led to the five above-listed initiatives and have been
912 developed in close cooperation with other standards and open source
913 organizations such as 3GPP, TM Forum, ETSI, and O-RAN Software Community.
917 **Figure 9. End-to-end 5G Service**
919 Read the `5G Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2019/07/ONAP_CaseSolution_5G_062519.pdf>`_
922 A related activity outside of ONAP is called the 5G Super Blueprint where
923 multiple Linux Foundation projects are collaborating to demonstrate an
924 end-to-end 5G network. In the short-term, this blueprint will showcase
925 three major projects: ONAP, Anuket (K8S NFVI), and Magma (LTE/5GC).
929 **Figure 10. 5G Super Blueprint Initial Integration Activity**
931 In the long-term, the 5G Super Blueprint will integrate O-RAN-SC and LF Edge
934 Residential Connectivity Blueprints
935 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
936 Two ONAP blueprints (vCPE and BBS) address the residential connectivity use
941 Currently, services offered to a subscriber are restricted to what is designed
942 into the broadband residential gateway. In the blueprint, the customer has a
943 slimmed down physical CPE (pCPE) attached to a traditional broadband network
944 such as DSL, DOCSIS, or PON (Figure 6). A tunnel is established to a data
945 center hosting various VNFs providing a much larger set of services to the
946 subscriber at a significantly lower cost to the operator. In this blueprint,
947 ONAP supports complex orchestration and management of open source VNFs and both
948 virtual and underlay connectivity.
952 **Figure 11. ONAP vCPE Architecture**
954 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>`_
957 Broadband Service (BBS)
958 """""""""""""""""""""""
959 This blueprint provides multi-gigabit residential internet connectivity
960 services based on PON (Passive Optical Network) access technology. A key
961 element of this blueprint is to show automatic re-registration of an ONT
962 (Optical Network Terminal) once the subscriber moves (nomadic ONT) as well as
963 service subscription plan changes. This blueprint uses ONAP for the design,
964 deployment, lifecycle management, and service assurance of broadband services.
965 It further shows how ONAP can orchestrate services across different locations
966 (e.g. Central Office, Core) and technology domains (e.g. Access, Edge).
970 **Figure 12. ONAP BBS Architecture**
972 Read the `Residential Connectivity Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2019/07/ONAP_CaseSolution_BBS_062519.pdf>`_
975 Voice over LTE (VoLTE) Blueprint
976 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
977 This blueprint uses ONAP to orchestrate a Voice over LTE service. The VoLTE
978 blueprint incorporates commercial VNFs to create and manage the underlying
979 vEPC and vIMS services by interworking with vendor-specific components,
980 including VNFMs, EMSs, VIMs and SDN controllers, across Edge Data Centers and
981 a Core Data Center. ONAP supports the VoLTE use case with several key
982 components: SO, VF-C, SDN-C, and Multi-VIM/ Cloud. In this blueprint, SO is
983 responsible for VoLTE end-to-end service orchestration working in collaboration
984 with VF-C and SDN-C. SDN-C establishes network connectivity, then the VF-C
985 component completes the Network Services and VNF lifecycle management
986 (including service initiation, termination and manual scaling) and FCAPS
987 (fault, configuration, accounting, performance, security) management. This
988 blueprint also shows advanced functionality such as scaling and change
993 **Figure 13. ONAP VoLTE Architecture Open Network Automation**
995 Read the `VoLTE Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_VoLTE_112918FNL.pdf>`_
998 Optical Transport Networking (OTN)
999 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1000 Two ONAP blueprints (CCVPN and MDONS) address the OTN use case. CCVPN addresses
1001 Layers 2 and 3, while MDONS addresses Layers 0 and 1.
1003 CCVPN (Cross Domain and Cross Layer VPN) Blueprint
1004 """"""""""""""""""""""""""""""""""""""""""""""""""
1005 CSPs, such as CMCC and Vodafone, see a strong demand for high-bandwidth, flat,
1006 high-speed OTN (Optical Transport Networks) across carrier networks. They also
1007 want to provide a high-speed, flexible and intelligent service for high-value
1008 customers, and an instant and flexible VPN service for SMB companies.
1012 **Figure 14. ONAP CCVPN Architecture**
1014 The CCVPN (Cross Domain and Cross Layer VPN) blueprint is a combination of SOTN
1015 (Super high-speed Optical Transport Network) and ONAP, which takes advantage of
1016 the orchestration ability of ONAP, to realize a unified management and
1017 scheduling of resources and services. It achieves cross-domain orchestration
1018 and ONAP peering across service providers. In this blueprint, SO is responsible
1019 for CCVPN end-to-end service orchestration working in collaboration with VF-C
1020 and SDN-C. SDN-C establishes network connectivity, then the VF-C component
1021 completes the Network Services and VNF lifecycle management. ONAP peering
1022 across CSPs uses an east-west API which is being aligned with the MEF Interlude
1023 API. CCVPN, in conjunction with the IBN use case, offers intent based cloud
1024 leased line service. The key innovations in this use case are physical network
1025 discovery and modeling, cross-domain orchestration across multiple physical
1026 networks, cross operator end-to-end service provisioning, close-loop reroute
1027 for cross-domain service, dynamic changes (branch sites, VNFs) and intelligent
1028 service optimization (including AI/ML).
1030 Read the `CCVPN Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2019/07/ONAP_CaseSolution_CCVPN_062519.pdf>`_
1033 MDONS (Multi-Domain Optical Network Service) Blueprint
1034 """"""""""""""""""""""""""""""""""""""""""""""""""""""
1035 While CCVPN addresses the automation of networking layers 2 and 3, it does not
1036 address layers 0 and 1. Automating these layers is equally important because
1037 providing an end-to-end service to their customers often requires a manual and
1038 complex negotiation between CSPs that includes both the business arrangement
1039 and the actual service design and activation. CSPs may also be structured such
1040 that they operate multiple networks independently and require similar
1041 transactions among their own networks and business units in order to provide an
1042 end-to-end service. The MDONS blueprint created by AT&T, Orange, and Fujitsu
1043 solves the above problem. MDONS and CCVPN used together can solve the OTN
1044 automation problem in a comprehensive manner.
1048 **Figure 15. ONAP MDONS Architecture**
1050 Intent Based Network (IBN) Use Case
1051 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1052 Intent technology can reduce the complexity of management without getting into
1053 the intricate details of the underlying network infrastructure and contribute
1054 to efficient network management. This use case performs a valuable business
1055 function that can further reduce the operating expenses (OPEX) of network
1056 management by shifting the paradigm from complex procedural operations to
1057 declarative intent-driven operations.
1061 **Figure 16. ONAP Intent-Based Networking Use Case**
1063 3GPP 28.812, Intent driven Management Service (Intent driven MnS), defines
1064 some key concepts that are used by this initiative. The Intent Based Networking
1065 (IBN) use case includes the development of an intent decision making. This use
1066 case has initially been shown for a smart warehouse, where the intent is to
1067 increase the output volume of automated guided vehicles (AVG) and the network
1068 simply scales in response. The intent UI is implemented in UUI and the
1069 components of the intent framework interact with many components of ONAP
1070 including SO, A&AI, Policy, DCAE and CDS.
1074 The virtual firewall, virtual DNS blueprint is a basic demo to verify that ONAP
1075 has been correctly installed and to get a basic introduction to ONAP. The
1076 blueprint consists of 5 VNFs: vFW, vPacketGenerator, vDataSink, vDNS and
1077 vLoadBalancer. The blueprint exercises most aspects of ONAP, showing VNF
1078 onboarding, network service creation, service deployment and closed-loop
1079 automation. The key components involved are SDC, CLAMP, SO, APP-C, DCAE and
1080 Policy. In the recent releases, the vFW blueprint has been demonstrated by
1081 using a mix of a CNF and VNF and entirely using CNFs.
1083 Verified end to end tests
1084 -------------------------
1087 Various use cases have been tested for the Release. Use case examples are
1088 listed below. See detailed information on use cases, functional requirements,
1089 and automated use cases can be found here:
1090 :doc:`Verified Use Cases<onap-integration:docs_usecases_release>`.
1092 - E2E Network Slicing
1093 - 5G OOF (ONAP Optimization Framework) SON (Self-Organized Network)
1094 - CCVPN-Transport Slicing
1096 Functional requirements
1097 ^^^^^^^^^^^^^^^^^^^^^^^
1098 Various functional requirements have been tested for the Release. Detailed
1099 information can be found in the
1100 :doc:`Verified Use Cases<onap-integration:docs_usecases_release>`.
1104 - ONAP CNF orchestration - Enhancements
1105 - ONAP ASD-based CNF orchestration
1109 - Lifecycle Management
1111 - Policy Based Filtering
1112 - Bulk PM / PM Data Control Extension
1113 - Support xNF Software Upgrade in association to schema updates
1114 - Configuration & Persistency Service
1118 - CMPv2 Enhancements
1120 - Standard alignment
1122 - ETSI-Alignment for Guilin
1123 - ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over VES
1124 - Extend ORAN A1 Adapter and add A1 Policy Management
1126 - NFV testing Automation
1128 - Support for Test Result Auto Analysis & Certification
1129 - Support for Test Task Auto Execution
1130 - Support for Test Environment Auto Deploy
1131 - Support for Test Topology Auto Design
1135 The ONAP provides a comprehensive functions for real-time, policy-
1136 driven orchestration and automation of physical and virtual network functions
1137 that will enable software, network, IT and cloud providers and developers to
1138 rapidly automate new services and support complete lifecycle management.
1140 By unifying member resources, ONAP will accelerate the development of a vibrant
1141 ecosystem around a globally shared architecture and implementation for network
1142 automation —with an open standards focus— faster than any one product could on
1147 See the Resources page on `ONAP.org <https://www.onap.org/resources>`_
1149 .. |image1| image:: media/ONAP-architecture.png
1151 .. |image2| image:: media/ONAP-fncview.png
1153 .. |image3| image:: media/ONAP-Streamlining-Build-Deployment.png
1155 .. |image4| image:: media/ONAP-Streamlining-Build-Deployment.png
1157 .. |image5| image:: media/ONAP-securityFramework.png
1159 .. |image6| image:: media/ONAP-NetworkSlicingOptions.png
1161 .. |image7| image:: media/ONAP-closedloop.png
1163 .. |image8| image:: media/UUI-Component-Architecture.png
1165 .. |image9| image:: media/ONAP-5G.png
1167 .. |image10| image:: media/ONAP-5GSuperBP-Integration.png
1169 .. |image11| image:: media/ONAP-vcpe.png
1171 .. |image12| image:: media/ONAP-bbs.png
1173 .. |image13| image:: media/ONAP-volte.png
1175 .. |image14| image:: media/ONAP-ccvpn.png
1177 .. |image15| image:: media/ONAP-mdons.png
1179 .. |image16| image:: media/ONAP-IntentBasedNetworking.png