Guilin Release Key Updates

First steps towards realizing Machine Learning (ML) based SON. Offline trained ML model used to provide additional inputs for PCI optimization. Provides interface for fetching PM data to determine additional inputs for optimization related to SON.

Benefits of OOF SON use case: A modular and generic control-loop based framework to realize various SON functions. The interfaces and network models are aligned with 3GPP and O-RAN.

Increment in Guilin

Enables onboarding ML models to realize ML-based SON use cases. This facilitates use of ML to determine the optimization model to be used, and to provide additional inputs for the optimization engine.

This use case incorporated the 5G RAN Wireless Network Resource Model (NRM) into ONAP.

The 5G NRM is defined from the 3GPP standards 3GPP TS28.540 & 3GPP TS28.541 which builds upon the FNIM, UIM specified in 3GPP TS28.620 and TS28.622

The 5G NRM is a common vendor agnostic network model inspired from the standards which provides a common basis for all wireless vendors to have a set of parameters that are in common across the vendor so that service providers have a more uniform set of objects, parameters and models to represent a wireless network.

Development of support for Standard Defined (stndDefined) VES Event. This new domain of a VES event would allow ONAP to support many more standards based & standards defined messages.

It opens the possibility for ONAP to support a wide variety of messaging from Optical, Wireless, Core and Transport standards.

"stndDefined" is a new VES domain. And it is described in the VES 7.2 specification VES 7.2 and also in the readthedocs. It also introduces a new field "namespace" to be published onto the DMaaP bus which allows for internal routing of the information coming from xNFs. For example 3GPP_Configuration would indicate a CM type information coming from an xNF.

• Added support for standardized A1 protocol (O-RAN A1-AP v1.1) - now supports multiple A1 versions - and new versions can be added easily
• Added A1 Policy Management Service
  
  • Query A1 Policy Types in near-RT-RICs
  • Create/Query/Update/Delete A1 Policy Instances in near-RT-RICs
  • Query Status for A1 Policy Instances
  • Maintain transient cache of RAN’s A1 Policy information
• Added support for multiple near-RT-RICs (with multi-version support)
• Added Unified REST & DMaaP NBI for A1 Policy Management
• Add support for TLS/HTTPS REST for southbound A1 interfaces (and NBIs)
• Converged ONAP & O-RAN-SC A1 Adapter/Controller functions in ONAP SDNC/CCSDK

CCSDK/SDNC now supports managing A1 Policies, multiple A1 targets in the RAN, multi-version support for different A1 targets, converged DMaaP & REST interfaces, and secure communication (to/from RAN and to/from ONAP functions.

Functionality is now available for use in further use cases in ONAP H+.

Functionality available for standalone use, or in a larger ONAP deployment.

Available for use in O-RAN OSC.

• Realization of RAN, Core and Transport NSSMFs within ONAP, supporting the respective NSSI creation, activation, deactivation and termination. RAN and Core NSSMF interfaces are aligned with 3GPP, while Transport NSSMF's interfaces are aligned with IETF TSCi.
• Supporting connectivity to an external RAN NSSMF outside ONAP.
• Basic model provisioning including NSST, sliceProfiles and E2E connection information.
• Support of a simple Closed Loop scenario involving RAN domain
• Support of a simple offline trained ML model for Intelligent Slicing in the RAN domain
• First steps towards KPI monitoring by the operator/slice tenant
• First steps towards Core NF configuration 
• Core NF Simulator and RAN NF Simulator enhancement

• Enables different deployment options and greater interoperability of Slice Management functions through a loosely-coupled architecture supporting standards-based interfaces.
• Supports 2 different deployment configurations for RAN Slicing functionality.
• Enables new Closed Loop functionalities to be realized with the existing framework.
• Enables ONAP to directly set up and configure Network Functions.

PM data collection control provides 5G network operators with a dynamic and more efficient way to configure performance measurement collection on a selected subset of  PNFs/VNFs in the network and complements the existing PM data collection and processing capabilities in ONAP/DCAE. An initial version has been delivered in Rel 6 (5G / Bulk PM / PM Control - REQ-129). Planned enhancements for Rel 7 intend to further increase the capability and the dynamicity of this feature.

PM control is a critical business function because it is vital to enable the PM data collection in ONAP

• Support 5G slice creation by intent based network，

  Use intent based network to create 5G slice.

• Support Intent instance LCM operations，provide functions for intent instance create, terminate

• Support User intent idendify

• Support User Intent Translation

• Support User Intent Decision

• It simplifies the complexity for users to activate 5G slices
• Improves the efficiency of service activation
• Improves the user experience of the system

Development of Building Blocks in SO to support PNF Plug and Play Flow.

Migration of BPMN Workflow to Building Blocks (BB). These include the "AssignPnfBB", "WaitForPnfReadyBB", "ConfigAssignPnfBB" and "ConfigDeployPnfBB", "ActivatePnfBB". Note: that in R8 will see the development of the VID work to compliment the SO BB work completed in R7.

Modeling analysis of Geolocation and Place objects driven from RFC6225 and MEF TM GB922 standards. Model contributions have been approved.

Internal SO development to streamline execution of PNF Plug and Play.

Migration of BPMN Workflow to Building Blocks allows for much more streamlined management of SO workflow execution.

Enhanced entire package security

Aligned now with ETSI SOL004 standrads.

Deployment and orchestration of new services over CNFs,  VNFs and PNFs in a model and software driven way simplifies the network management. Enables operators and service providers to manage the Life Cycle of a Network Service. Assuring continuity of operation of services is crucial for production and carrier grade environments. The actualization or upgrades of software and in consequence required changes in the service model is a natural part of service instance life cycle. Without the support of ONAP service update with schema change, service life cycle management by ONAP can be very difficult which can impact the quality and continuity of services.

(Note this has been renamed to Configuration Persistence Service)

CPS PROOF OF CONCEPT

Proof of Concept developed in R7 to demonstrate key concepts in CPS and also to lay foundational software for CPS. 

The PoC has:

• Demonstrated write/read operations for YANG data fragments using CPS and store them in a generic DB with a very simple generic schema
• Demonstrated ability to deploy / upgrade YANG models at run-time
• Demonstrated CPS behavior driven by YANG models
• Provided an architecture vision and roadmap for a target architecture, supported use cases, non-functional requirements towards an ONAP Project
• Got early performance indication for querying the generic schema
• Architectural decisions and issues were resolved through regular team meetings: Issues decisions and assumptions

CPS STAND ALONE PROJECT (in R8)

Presented Project proposal at architecture sub-committee and TSC: Configuration Persistence Service Project in R7 timeframe. Is has been approved to  be a stand-alone project in R8 (Honolulu Release)

STATE MANAGEMENT POC

State Management PoC was created to store the current state of the network elements in a network.

BENEFITS OF CPS

CPS introduces a data layer into ONAP to store and manage Network Element Data. CPS provides a centralized, single, persistent data across all vendors. It allows for the data to be exposed such that different upper level applications (e.g. SON, orchestration, LCM functions) can use CPS data. The CPS is real-time and up-to-date. It facilitates the push & pull of configuration data that is policy driven. CPS is an embodiment of "Golden configurations" which is a solution for an up-to-date unified configuration database sending configuration changes. Before CPS existed, service providers have to struggle with many disparate databases which begs to be harmonized and integrated.

BENEFITS OF CPS PROOF OF CONCEPT

Proof of Concept developed in R7 to demonstrate key concepts in CPS and also to lay foundational software for CPS.

BENEFITS OF CPS AS STAND ALONE PROJECT

CPS as a stand-alone project in R8 Honolulu will allow CPS to have its own stand-alone repository and facilitate component interaction to CPS.

BENEFITS OF STATE MANAGEMENT POC

State information facilitates the recovery of failed assets and tracking the states of elements in a service provider's network.

CMPv2 is a standardized certificate based exchange protocol to introduced enhanced security in ONAP. It allows for intra-component security and affect many components.

CMP is a protocol for X.509 digital certificate management in a PKI described in RFC4210. And is one of the protocols used for Certificate Request Message Format (CRMF) described in RFC4211.

xNF Licensing Management enhancements allows for ONAP to work with an external licensing service. Link to high level description of the solution.

Integrated flow into Plug and Play Use Case. 5G - PNF Plug and Play

Possibility to use external licensing service allows for greater interoperability between service providers & vendors, and enables various types of xNF commercial licensing models: simpler, more complex, vendor specific and operator specific models.

Improvements on MDONS use-case with additional features

• Support for Inter Domain Link (IDL)/Path Optimization for OTN links across multiple optical domains
• Added support for asynchronous response handling to enable OpenROADM based OTN service creation
• Incorporated support for closed loop operations 

MDONS blueprint is enhanced with additional functionality that enables policy-driven automated service operations. The optimization framework facilitates improved service lifecycle management across cross-carrier optical domains enabling vendor interoperability. 

The following ETSI-Alignment enhancements are made:

• ETSI SOL 2.5.1/2.7.1 support 
• SDC enhancements 
  • SOL007 NS package design
  • SOL004 VNF/PNF package onboarding validation
  • SOL001 NSD mapping to SDC AID DM
• Addition of SO NFVO for hierarchical orchestration, as one of the NFVO options 
  • Support SOL005 NBI and SOL003 SBI
  • NS LCM orchestration support
• SOL003 Adapter enhancements for SO NFVO 
• ETSI Catalog Manager enhancements for direct interface between SDC and ETSI Catalog Manager

ONAP supports SOL007 NS design which enables hierarchical orchestration by conforming ETSI NS and VNF standards.

ONAP NS and NsVirtualLink are now conforming to ETSI standards.

SO NFVO enables plugin-based extension of NFVO functions on top of default NFVO functions.

For Guilin release there are introduced key changes that deployment of CNFs with ONAP more operational and they enable Day-0/1 CNF operations. The changes include:

• Native distribution of Helm package from SDC
• Native support for Helm package enrichment in Controller Design Studio.
• Native orchestration of Helm package in the SO
• Exposure of APIs for monitoring of resources deployed on K8s cluster

The introduced changes bring the following benefits:

• Native distribution of Helm package in SDC enabled native orchestration of CNF in SO and allows the addition of Helm validation or Helm properties recognition in the future
• Native support for Helm package enrichment in CDS allows the flexible generation of Helm override parameters and enables easy modification of on-boarded Helm package for each service instance. It is very important for the deployment of complex 5G Core CNFs that require heavy customization for each deployed service instance.
• Native orchestration of Helm package in the SO enables further synchronization of ONAP inventory with information from k8s cluster or easier execution of Day-2 operations on CNFs
• Exposure of APIs for monitoring of resources deployed on K8s cluster enables verification of the status of k8s resources deployed in k8s cluster. Currently, such API can be easily integrated with CNF blueprint created for Controller Design Studio.

The Control Loop sub committee led the functional requirement to add a new Filter Guard Policy Type. In addition, the subcommittee ensured that the Native Policy Type work developed in Frankfurt was fully tested through the CLAMP interface.

The sub committee continues to support the DCAE Project Self-Serve control loop enhancements Proof-of-Concept. The PoC made improvements to MOD (NiFi) and configuration for dynamic topic support.

A new Proof-of-Concept was started by the subcommittee to define TOSCA-Based Control Loops. This work was demonstrated at the fall LFN Technical Conference.

The new Filter Guard Policy Type is another guard policy available for ONAP users to use in addition to the others that have been available since Dublin. This allows filters to build more flexible constraints to both whitelist and/or blacklist vnf types, specific vnf id's, services, etc.

In defining a TOSCA specification for Control loops, users can now encapsulate all the details of a control loop within one specification. These specifications are re-usable. CLAMP will eventually be able to be fed a TOSCA specification, and with minimal effort be able to configure and deploy a control loop into the runtime environment.

The modeling subcommittee updates the ONAP VNFD model to align with ETSI NFV IFA011 v2.7.1, supporting key features like virtual ip, VNF exposed interface, etc.

The subcommittee also adds a new model for location information. Taking consideration of multiple existing standards, including ETSI NFV SOL001, RFC4776 and RFC6225, the new model enables an entity to provide its geographical location information.

Update of the VNFD model to the latest ETSI NFV spec allows ONAP to incooperate new features defined in standards.

The new locations model enables entity such as PNF to provide its geographical information, allowing further scheduling and optimization procedures.

The subcommittee continued efforts on upgrading packages to the SECCOM recommended versions as well as upgrading the java (v8 → v11) and python (v2.7 → 3.8) versions. 

CII Badging information:

1)  https://wiki.onap.org/display/Meetings/PTL+2020-11-16?preview=%2F92998580%2F93000904%2FCelebrate-CII-Badging.pdf
and

2) http://tlhansen.us/onap/cii.html

Progress with package and Java, Python upgrades

Progress with decrease of pods running as root

Migration towards https and default use of https

Open Lab 

Network slicing would be able to deploy in 5G by using ONAP, with internal nd external NSSMFs, CSMF and NSMF;

any combination of PNF, VNF, CNF would be applicable for any use case

deployment will be enabled by standardized ETSI SOL functionalities

• Native support for Helm package enrichment by CDS
• CDS Designer Enhancements 
  • Package List/Search
  • Package Import 
  • Package Creation
    • Meta Data
    • Template & Mapping with Velocity, JINJA support
    • Script
    • File Import
      
      • Save & Deploy 
      • Save 
    • Manual Enrichment

• Native support for Helm package enrichment in CDS allows the flexible generation of Helm override parameters and enables easy modification of on-boarded Helm package for each service instance. It is very important for the deployment of complex 5G Core CNFs that require heavy customization for each deployed service instance.
• Delivered MVP (minimal viable product) Functionality to support Package Designer capabilities for design & creation of the CBA package. 

• Exposure of APIs for monitoring of resources deployed on K8s cluster
• Improvements in configuration API for modification of existing resources
• Improvements in profiling (helm enrichment) mechanisms

• Exposure of APIs for monitoring of resources deployed on K8s cluster enables verification of the status of k8s resources deployed in k8s cluster. Currently, such API can be easily integrated with CNF blueprint created for Controller Design Studio.
• Change in Configuration API allows modification of existing resources created before by helm package.  The mechanisms can be used for standard Day2 operation, like modification of configmaps, deployment, or for upgrading purposes.
• Modification of the profiling mechanism enables the use of one definition and profile for the creation of many instances of CNF.  Before, for each instance, a separate profile was required.