What is ONAP?

ONAP was created as an open-source automation platform for the telecom community. ONAP provided many network automation use cases and functionalities to the telecom industry. ONAP was structured to deliver a platform, but now ONAP is a collection of network automation functions.

• ONAP allows Operators/Vendors/communities to pick-and-choose desired ONAP functions, based on ONAP Streamlining evolution:

• Component modularity

• CD-based pick-and-choose component deployment

• Individual and autonomous component building

• Simplified and agile-based release process

• ONAP has been aligned with industry / de facto standards

• AI/ML intent-based network automation, based on 3GPP, TMForum, ETSI...

• Network slicing support, based on 3GPP

• Security enhancements thru Ingress, IAM, Service Mesh and Kubernetes

• ETSI NFV-aligned models, APIs and functions

ONAP TSC Initiative Action Points

ONAP TSC defined three major initiative action points:

• ONAP TSC is setting up ONAP strategies and roadmaps for ONAP future focus areas and releases

  • Lightweight ONAP Core with function aggregation capabilities

  • Component interface normalization and/or standardization

• Evaluate innovative solutions and technologies to ensure that ONAP remains the best fit

  • Secure CI/CD, Repository-based, Declarative intents

  • AI/ML-based network provisioning configuration, optimization…

• Collaborate with other communities and standard organizations for complete and secure network automation solutions

  • O-RAN, O-RAN SC, Nephio, 5G Super Blueprint

  • 3GPP, TMForum, ETSI, IETF, others

ONAP Focus Areas

Manage “Right-size & Focused” functions, which can be used by operators/vendors, and industry

• Continuation of ONAP Streamlining evolutions

• Removal of unmaintained ONAP components

• Removal of any dependencies of unmaintained ONAP components

• Component interface normalization / standardization for functional aggregations, based on use cases

• Component catalogs / documentation to guide functional aggregations on demand

Seek collaborations with other open-source projects, especially O-RAN, O-RAN SC and Nephio

• Use cases, interface models and specifications for interacting with O-RAN SC and Nephio

• For core components such as DCAE, Policy Framework, CPS, SDN-C/R, UUI, AI/ML Intent-driven network automation, SO and A1 Adapter. Update them with normalized interfaces, possibly AI-based intents

• Enhancements of streamlining OOM scripts for security and CD-based individual component deployment

• Becoming an integral part of initiatives such as the O-RAN SC, Nephio and 5G Super Blueprint

ONAP Core Components

Oslo ONAP Component Architecture

The following diagram depicts Oslo ONAP Component Architecture:

Open

ONAP Core Components

ONAP Core Component Interfaces and Relationships

The remaining ONAP components/projects are now ONAP Core components:

• Portal-NG : is a GUI platform provides the ability to integrate different ONAP GUIs

• Use-Case UI (UUI) : provides the capability to instantiate the blueprint Use Cases and visualize the state. It also provides intent-based network management, leveraging genAI/ML

• SDC : provides a design time tool for common model/catalog onboarding design and distribution

• Policy Framework : provides the ability for the creation and management of policies. Its CLAMP (Closed Loop Automation Management Platform) provides the run-time control loop management

• SO : Service Orchestrator and its modular sub-components provide the service orchestration, network service, network slicing and VFN/CNF/PNF in the ONAP architecture

• AAI : provides real-time views of Resources and Services and their relationships. It also provides services to register externally used services

• CPS : provides storage for real-time configuration and operational parameters

• DCAE : provides the capability to collect events, and host analytics applications (supporting VES events)

• Multi-VIM/Cloud : provides mediation capabilities to connect to different infrastructure providers (including K8s plugin for CNF)

• CDS : is a framework to automate resource resolution for instantiation and configuration (Day 0, Day 1, Day 2)

• CCSDK : provides a common set of reusable code that can be used across multiple controllers (for building/plug-in controller personas)

• SDNC : provides a network controller capability for establishing network connections and configuring VNFs/CNFs. It is based on CCSDK

ONAP Core Component Interface Abstraction

• ONAP component interfaces should be designed/used for/by not only ONAP but also non-ONAP.

• ONAP component functions can be substituted and/or extended by vendors/operators

• Component dependencies and couplings to other ONAP components should be removed.

• Those dependencies and couplings could be both syntactic and semantic

• Intra-ONAP component interfaces and communications should not be ONAP-specific.

• Aligning with standards where possible (e.g., ETSI NFV MANO, ASD, 3GPP SA5…) should be global requirements

• If there must be a deviation, that can be done in an extensible way that enables the standard-based approach

• The exposed service interfaces should be for both ONAP and non-ONAP; promote ONAP component interfaces as LFN de facto standards

• If exposed service interfaces conform to industry standards (e.g., ETSI SOL005, ETSI SOL003, 3GPP SA5), the interactions between the service provider and consumer would be simplified (e.g., VFC case in this diagram)

• For now, the service consumers can use “adapters” which choose a desired service interface

• Action Points:

  • Promote ONAP Component API models and interfaces as open-source de facto APIs

  • Event Handler / operator façade can be used trigger ONAP components as the previous slide

ONAP Shared Services

• Security Framework : provides security capabilities for external and inter-component secure communications, authentication and authorization

• Logging Framework (PoC) : provides general-purpose logging collection/aggregation/persistence/visualization, by leveraging open-source log collector, aggregator, database and visualizer (e.g., FluentBit, FluentD, ElasticSearch, Kibana)

ONAP Infrastructure Service

• Infrastructure Service supports the foundation of ONAP applications to run and includes computing, networking, storage, security and other essential resources. In ONAP, Service Mesh is placed in the Infrastructure Service layer for secured ONAP application communications

• Service Mesh is an infrastructure layer to handle communication between microservices in a distributed system. In ONAP, Istio Service Mesh with Envoy proxies as the sidecars manages all incoming and outgoing network/application traffic for ONAP applications with mTLS, authentication and authorization

Repository-Based ONAP Core Integration (Future topic)

The following diagram depicts a possible CD/CD Repository-based Network Automation Choreography use cases.

Open

• ONAP CI/CD and Repository mechanisms can be substituted by vendor/operator mechanisms.

• Repository holds artifacts, intents and other models.

• ONAP components and vendor / operator components send their intents to the Repository.

• OSS Client sends their intents to the Repository thru Intent Manager, or UUI or else.

• User-level Intents will be translated in UUI.

• System-level Intents will be handled by Intent Manager.

• CD monitors the Repository and reconciles for events

• Thru CD, the corresponding intents will be delivered to the ONAP components thru the operators.

• The operators will work as façade to trigger ONAP component functions (it would be an optional path, based on use cases).

• ONAP components do their business decisions and handles actuations.

• The actuations can result in actions and/or another-level of intents, which will be stored back to the Repository for next events.

• Images and/or Helm Charts and others will be stored thru the CI pipelines, which to be used by ONAP components, as needed.

• ONAP components can leverage the existing ONAP interfaces, based on their needs – a hybrid mode between declarative and imperative APIs will be supported.

• ONAP ends up having smaller imperative actions that can be triggered by different events.