BUSINESS DRIVERS

This section describes Business Drivers for this Use Case.

Executive Summary - 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.

Business Impact - 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.

Business Markets - Carriers both in the mobile and fixed-line space host PNFs at the edge of the network. New 5G deployments as well as legacy 4G systems in the mobile carrier space should be considered as target markets.

Funding/Financial Impacts - Orchestrating PNF software updates via an ONAP deployment will enable better service planning, faster introduction of new network services over field-deployed PNFs, and reduce the operational costs.

Organization Mgmt, Sales Strategies - Harmonizing PNF and VNF software management in a model and workflow driven manner is essential in 5G systems where PNFs will continue to exist in large numbers and they are expected to have more frequent software upgrades (as they will have more capabilities that can be controlled or upgraded via software). Thus ONAP can be the "go-to" solution if this harmonization can be done successfully.

Current Status of PNF Software Upgrade

PNF in place software upgrade is supported in Casablanca and updated in Dublin

With the support of an EM
Ansible protocol only
Plan to use LCM API with existing SO building blocks
Impacts on SDNC only (not E2E solution yet)

More details, 5G - PNF Software Update & 5G - PNF SW Upgrade (Casablanca carry-over items)

PNF Software Upgrade Scenarios

Scenarios	Descriptions	Service level impacts	PNF software upgrade	Schema updates	Controller API	Protocols	EM	Proposed by	Target releases
1. Using direct Netconf/Yang interface with PNF	Support direct PNF NETCONF interface with the vendor-specific YANG model. Enhance SO in-place software upgrade workflow with generic SO building blocks, which can be used for workflow design in the design time. Using CDS self-service API between SO and controller with the support of PNF in-place software upgrade Enhance VID to demonstrate single PNF in-place software upgrade Enhance SO procedure to support AAI update after the software upgrade completion.	No	one PNF instance	No	CDS self-service	Netconf / YANG between controller and PNF	No	Ericsson	Frankfurt
2. Enable service level LCM operations	Updating the design time service template using vendor provided onboarding package Upgrading a run time service instance based on the updated service template Updating the run time catalog at software upgrade completion	Yes	One or more PNF instances	Yes	CDS self-service	Netconf / YANG between controller and PNF	No	Ericsson	Frankfurt+
3. Using Ansible protocol with EM	Enhancement and additions of PNF in-place software update Using LCM API Using Ansible protocol With EM	No	one PNF instance	No	LCM API	Ansible between controller and EM	Yes	Huawei	Frankfurt
4. Using Netconf/Yang interface with EM	NETCONF interface with EM Using CDS self-service API	No	one PNF instance	No	CDS self-service	Netconf between controller and EM	Yes	Huawei	Frankfurt

SO workflow

Development Status

Key	Summary	T	Created	Updated	Assignee	Reporter	P	Status	Resolution	Sub-Tasks	Fix Version/s

Loading...

Refresh

TBC

Test Status

TBD

Reference

Discussion Materials

This section is to review slides for discussion.

Space shortcuts

Page tree

Table of Contents