Page History

5G use case covers a few independent use cases which improves the ONAP capabilities on PNF management.  

Key use cases which are supported in ONAP Frankfurt release:

• PNF software version onboarding
• PNF sotware upgrade Using direct Netconf/Yang interface with PNF
• PNF sotware upgrade Using Ansible protocol with EM
• PNF sotware upgrade using Netconf/Yang interface with EM 
• PNF PNP enhancement 
• E2E Network Slicing
• O-RAN Harmonization

E2E Network Slicing

(a new E2E use case for Frankfurt, we'd also like to apply to publish a separate Blueprint White Paper for E2E Network Slicing use case, same as the community did for other use cases in every release)

5G Network Slicing is one of the key features of 5G. The essence of Network Slicing is in sharing network resources (PNFs, VNFs, CNFs) while satisfying

E2E Network Slicing

(a new E2E use case for Frankfurt, we'd also like to apply to publish a separate Blueprint White Paper for E2E Network Slicing use case, same as the community did for other use cases in every release)

5G Network Slicing is one of the key features of 5G. The essence of Network Slicing is in sharing network resources (PNFs, VNFs, CNFs) while satisfying widely varying and sometimes seemingly contradictory requirements to different customers in an optimal manner. Same network is expected to provide different Quality of Experience to different consumers, use case categories and industry verticals including factory automation, connected home, autonomous vehicles, smart cities, remote healthcare, in-stadium experience and rural broadband. An End-to-End Network Slice consists of RAN, Transport and Core network slice sub-nets. This Use Case intends to demonstrate the modeling, orchestration and assurance of a simple network slice (e.g. eMBB). While 3GPP standards are evolving and 5G RAN and core are being realized, this Use Case will start with realizing an E2E Network Slice with a simple example of a 5G RAN, Core and Transport Network Slice sub-nets. It will also align with relevant standard bodies (e.g., 3GPP, ETSI, TM Forum) as well as other open initiatives such as O-RAN where relevant, with respect to both interfaces as well as the functional aspects.

Key features in Frankfurt:

• Tenants and network operators can order slice-based services
• Enables network slice creation as well as reuse
• Supports many of the slice lifecycle management operations

Key capabilities added for ONAP Frankfurt release:

• ONAP Frankfurt provides basic capabilities for Network Slice Orchestration
• Supports Network Slice lifecycle operations of E2E Slice Design and Creation, Activation, Deactivation and Termination
• Provides CSMF and NSMF functionality implemented within ONAP
• Supports E2E Slice design including design of Communication Service, Service Profile and Network Slice Template
• Supports selection of suitable NST and suitable NSI, covering the scenario of new NSI creation by providing suitable slice profile
• Interacts with an external Core NSSMF

This use case is a multi release effort and we will continue to provide more enhancements and features based on what we've implemented in Frankfurt in the subsequent releases.

1. The ONAP based E2E Network Slicing solution allows a service provider to manage the slices and its constituents by leveraging ONAP existing capabilities.
2. enables the slice-consumer to request for and activate a network slice on-demand without being concerned about network internals, which is very essential for industry-verticalAn operation guidance will be provided on ONAP wiki in which explicit instructions are provided to help any interested parties to experience ONAP based E2E Network slicing management.-vertical
3. An operation guidance will be provided on ONAP wiki in which explicit instructions are provided to help any interested parties to experience ONAP based E2E Network slicing management.

PNF software updates are routine for network upgrades to support new features, improve efficiency or increase capacity on the field, and to eliminate bugs. This use case positions ONAP as a vantage point in orchestrating and managing PNF software upgrades inline with the business and service objectives.  

Deployment and orchestration of new network services over both VNFs and PNFs in a model and software driven way simplifies the network management. As 5G networks will host a large number of PNFs from multiple vendors, streamlining service upgrades that involve PNF software changes through ONAP will reduce the OPEX substantially. 

The following upgrade scenarios are supported in ONAP Frankfurt release: 

• PNF sotware upgrade Using direct Netconf/Yang interface with PNF
• PNF sotware upgrade Using Ansible protocol with EM
• PNF sotware upgrade using Netconf/Yang interface with EM 

PNF software version onboarding

PNF software version onboarding is a key feature to onboard the vendor provide PNF software version into the ONAP internal PNF descriptor. This PNF software version information will be used by ONAP Run Time components for the purpose of PNF life cycle management. 

Adding two extension functions / sub use cases for Frankfurt.

1. End-to-end E-LINE services across the domains over OTN NNI handover. The Frankfurt demonstration includes L1(OTN) and L2(ETH) Topology discovery from multiple domains controllers with in an operator and provide VPN service provision in OTN and ETH network. Use case specific developments have been realized in SO, OOF, A&AI, SDN-C and U-UI components
2. Multi-Domain Optical Network Service(MDONS). The MDONS sub use-case aims to automate the design, activation & operations resulting from an optical transport (L0/L1) service request exchange between service providers and/or independent operational entities within a service provider network by delivering E2E optical orchestration capabilities into ONAP.Use case specific developments have been realized in SDC, SO, A&AI, SDN-C and U-UI components

1. E-LINE over OTN NNI extends upon the CCVPN use case by incorporating support for L1/L2 network management capabilities leveraging open standards& common data models such as the IETF ACTN-based transport YANG models.
2. MDONS extends upon the CCVPN use-case by incorporating support for L0/L1 end customer services that span service provider domains, with a plan to support inter-carrier optical services.
3. MDONS defines a unified optical service model based upon OpenROADM, T-API, MEF 63, and MEF 64 models, and allows integration of optical domain controllers using either the Open ROADM or TAPI service models.

1. Establishment of a subscriber's HSIA (High Speed Internet Access) service from an ONT to the Internet drain

2. Support the change of location for ONT devices (Nomadic ONT devices)

2.1 PNF (Re-)Registration for an ONT
2.2 Service location modification that is detected by ONAP's analytic and enforced by APEX policy engine

PNF support

• vFW Traffic Distribution Use Case changed into vFW In-Place Upgrade with Traffic Distribution with possibility to run only vFW Traffic Distribution
  
  • Enhanced workflows that demonstrate different LCM operations of APPC
  • Workflow utilizes new mechanisms in APPC for Ansible LCM operations: running LCM commands on v-server, vf-module or vnfc level without the need to specify NodeList parameter - it is auto enerated from information in AAI and LCM request identifiers.
• PNF software upgrade without schema update

Significant progress in supporting

• Distributed Applications and Distributed network functions.
• Multi-tenancy 
• Multi party K8s Clusters 
• Provider networks and Multiple Virtual networks on per Cluster
• Complex applications
• Various deployment intents (Generic Placement intent, Network workload intent)
• Logical Clouds for  network slices with soft-isolation.

Integration with Macro instantiation flow and with CDS for vFW Use Case

• New Use Case - vFW CNF CDS. Use case demonstrates E2E Automation for instantiation via SO building, MultiCloud & CDS for CNF. 
• Improvements and bug fixes to support Macro flow instantiation of helm package
• Override parameters can be specified in Instantiation API - profile is not required for the same purpose
• Default profile created - does not have to be created before instantiation
• SDC helm package distribution is improved - many helm packages allowed in one CSAR package - decoupling of CNF into separate vf-modules (helm packages)
• Integration with CDS allows to generate instantiation time parameters for helm package like names, IP addresses etc. and it allows to automatically upload to Multicloud profile for helm package - when required.

• Now supports Ansible Playbooks in addition to Netconf for controller configuration of VNF
• Now supports dynamic configuration of VNF through CDS