This is the wiki for contributions/discussions related to the 5G Use Case for the ONAP Dublin Release.

5G DUBLIN USE CASE PROPOSALS

TITLE	DESCRIPTION	CATEGORY	WIKI
BULK PM	Performance Measurements 5G RAN Bulk Upload, Casablanca Carry-over items	Data Collection 5G FCAPS	5G - Bulk PM (Casablanca carry-over items)
PNF PRE-ONBOARDING & ONBOARDING Use Case	PNF Package delivery, Pre-onboarding and PNF Onboarding via SDC in Dublin.	PNF Support Discovery	5G - PNF Pre-Onboarding & Onboarding
CONFIGURATION WITH NETCONF	Enhancement to NETCONF support in ONAP supporting 5G and other use cases.	PNF Support Communications 5G FCAPS	5G - Configuration with NETCONF
5G FM META DATA & 5G PM DICTIONARY	Support for handling FM Meta Data & support for PM Dictionary & PM Schema (from standards)	PNF Support Data Collection 5G FCAPS	5G - FM Meta Data / 5G - PM Dictionary
OOF & PCI	Optimization and PCI (SON) development. Casablanca Carry-over items	5G Operational Optimization	5G - OOF and PCI (Casablanca carry-over items)
PNF Plug and Play	PNF Plug and Play support for PNF discovery, Casablanca Carry-over items, support by PRH (PNF Registration Handler)	PNF Support (Carry Over) Discovery	5G - PNF Plug and Play (Casablanca carry-over items)
PNF S/W UPGRADE	PNF Software upgrade to update the software on a PNF, Casablanca Carry-over items	PNF Support 5G FCAPS	5G - PNF SW Upgrade (Casablanca carry-over items)
NETWORK SLICING	Advanced 5G functionality, for Network Slicing development and early steps in long-lead development.	5G Operational Optimization	5G - Slicing

Portal Project & Database/Data Layer

USE CASES BY CATEGORY

Use Case	PNF Support	5G FCAPS	Opera-tional	Commun-ications	Discovery	STAGE
Bulk PM		PM, Data Collection				2
PNF Pre-Onboarding/ Onboarding	XXXX				XXXX	1 (start-up)
Configuration with NetConf		CM		XXXX		2 (configuration)
PM Dictionary FM Meta Data		PM FM				2 (configuration)
OOF PCI			XXXX			3 (operational)
PNF Plug and Play	XXXX				XXXX	1 (start-up)
PNF S/W Upgrade	XXXX	CM				2 (configuration)
Network Slicing			XXXX			3 (operational)

The discussion in the 5G Use Case sub-committee was to think about the lifecycle of a PNF in "stages"

This is artificial, but was used to help us think about certain categories that Use Cases might fit into:

STAGE 1 START UP - Stage 1 is related to design time, pre-onboarding/onboarding, discover & plug and play. It relates to activities to "start up" a PNF, recognize and define the PNF, and describe resources. Those design time activities that are done to define a PNF to be used.

STAGE 2 CONFIGURATION - This represents activities that occur AFTER the PNF has been discovered. Some configuration, or S/W upgrade for example. Activities that are typically done in configuring or sending operational information to the PNF, or prepare the PNF before it goes into full operation; or reconfiguration after the PNF is up and running.

STAGE 3 OPERATIONAL - Use Cases that deal with a PNF after Start up and Configuration.

USE CASES BY COMMITMENT & INTEGRATION LEADS

USE CASE	Integration Leads	Lab	Interested Companies	Overall Commitment
Bulk PM	user-3784d Liam Burke (Verified Jan 28, 2019)	Wind River (WR) Lab	AT&T, Ericsson*	High
PNF Pre-Onboarding/ Onboarding	VNF SDK: Marcin Przybysz Krzysztof Kuzmicki SDC: Andy Walshe (Verified Feb 11, 2019)	WR Lab	AT&T, Huawei, Ericsson, Nokia	High
Configuration with NetConf	Rahul Tyagi Eric Moore (Verified Feb 11, 2019)	WR Lab	AT&T, Ericsson*	High
FM Meta Data PM Dictionary & Schema	Marcin Przybysz Krzysztof Kuzmicki (Verified Feb 7, 2019)	WR Lab	AT&T, Ericsson, Nokia*	High
OOF & PCI	krishna moorthy	Rutgers WinLab	AT&T, Wipro, Tech Mahindra	High
PNF Plug and Play	Marcin Przybysz Krzysztof Kuzmicki (Verified Jan 28, 2019)	WR Lab	AT&T, Huawei, Ericsson, Nokia*	High
Network Slicing	Borislav Glozman Modeling only (no Integration)	N/A	AT&T, Amdocs*, Ericsson	Modeling only (High)
PNF Software Upgrade	yaoguang wang	WR Lab	AT&T, Huawei*, Ericsson	High

The COMPANIES Column in the above table represents the primary companies that are involved with the Use Case. They may be involved to various degrees. It doesn't assign a "degree" of involvement or work, but rather they are involved or intend to contribute or have contributed or are working the use case actively.

* = Companies providing the sw contribution in Dublin timeframe

5G U/C COMMITMENTS BY PROJECT:

The following table indicates commitment by project. The impacts have been accepted and are supported by the PTL of each ONAP Platform component and corresponding Jira Tickets are in place.

There are three states: "N/A" means that there is no interaction, no dependency, and no work for that Use Case for that component.

"?" means that there is not final commitment from the PTL for that project, and no Jira ticket exists yet.

YES means that (1) PTL INFORMED & COMMITTED - has agreed to support the changes needed for that Use Case, (2) DEVELOPMENT SUPPORT - there is development (company) support (3) JIRA TICKETS - and a Jira ticket exists. Please see the corresponding WIKI page for that Use Case to find out more details on impact, PTL support and Jira Ticket(s).

U/C	SDC	VID	Port	SO	AAI ESR	SDNC/ CCSDK	APPC	DCAE	OOF	Policy	CLAMP	DMaaP	AAF	VNF SDK	REQ	MODEL COM	OOM	VIM	Pomba Panda	CIA	CLI	Consul
Bulk PM		N/A	N/A	N/A	N/A	N/A	N/A	YES	N/A	N/A	N/A	YES	N/A	N/A	YES	N/A	N/A	N/A	N/A	N/A	N/A	N/A
Onboarding	YES	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	YES	YES	N/A	N/A	N/A	N/A	N/A	N/A	N/A
NetConf	N/A	N/A	N/A	YES	N/A	YES	N/A	N/A	N/A	N/A	N/A	N/A	N/A¹	N/A	YES	N/A	N/A	N/A	N/A	N/A	N/A	N/A
FM PM Dict	YES	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	YES	N/A	N/A	N/A	N/A	N/A	N/A	N/A
OOF PCI	N/A	N/A	N/A	N/A	N/A	YES	N/A	YES	YES	YES	N/A	N/A	N/A	N/A	YES	N/A	N/A	N/A	N/A	N/A	N/A	N/A
PNF PnP	N/A	YES	YES	YES	YES	YES	N/A	YES	N/A	N/A	N/A	N/A	YES	N/A	YES	N/A	N/A	N/A	N/A	N/A	N/A	N/A
S/W Upg	N/A	N/A	N/A	N/A	N/A	YES	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A
Slicing	YES	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	YES	N/A	N/A	N/A	N/A	N/A	N/A

REQ = VNF Requirements Project. The VNF-RQTS project applies to both VNFs and PNFs. A "YES" here means that there are new requirements for the vendors. (Moved to Wed 10AM)

MODCOM = Modelling Subcommittee.

Ctrl = This includes all of the controllers in ONAP including SDN-C, SDN-R, APP-C and VF-C

Stretch Goal (N/A) but if extra resources are available some changes may be made.

Note (1): Two options have been investigated for NETCONF/TLS client certificate generation: 1) manually outside of ONAP 2) by AAF. For Dublin option (1) will be supported. Option (2) is a possible extension for future release.

Note (3): Most of the PNF S/W Upgrade Use Case has been descope out of R4/Dublin and pushed to R5/El Alto release. In discussion with Change Management team, nothing major in R4 can be done, but may want to update the Playbooks distribute through SDC, distribute with roll-back API. Some discussion w/ 3GPP S/W mgmt API and what has been done in Change management U/C and how to bridge the gap. NetConf support in R4 and 5G API. See the Use Case Realization call for Wed Feb 20, 2019: USE CASE REALIZATION MEETING (Notes 2019-02-20)

Unit, Functional testing, Pair-wise testing. Where should we document the test cases prior to submission and passing on to integration. 3rd party/vendor domain external controllers.

API IMPACTS SUMMARY

The following table summarizes the expected API impacts for each of the 5G Use Cases.

These are needed for the M3 R4 Milestone (Mar 14)

USE CASE	API Impacts
Bulk PM	DMaaP DR API Updates. See the Wiki page for details on the Data Router Changes: 5G - Bulk PM (Casablanca carry-over items) Next Steps: Confirming API details.
Configuration with NetConf	For communication between SO and the CDS Blueprint Processor, a new API has been defined by CDS. This U/C will use that new API to request configuration as the last step of the extended PNF workflow. The API request and response format is defined in the following file: BlueprintProcessorData.kt The blueprint processor allows requests to be sent using either plain HTTP with JSON or gRPC over HTTP/2. The client in SO will use the gRPC option. This API doesn't have pre-defined actions and payloads. Instead they will be defined as part of U/C. For initial configuration (both VNF and PNF), the following actions will be used: config-assign and config-deploy. Payload format and contents have now been proposed for both actions.
OOF / PCI	API changes are needed. Config DB API, SDN-R. APIs for individual nodes record updates in Config DB. Bulk APIs for updating. API associated with SDN-C project. SON MS & Policy & OOF. Keep in sync with the corresponding Yang Model. OOF API: micro-service calls (optimization and passes data). Freeze on API changes. Next Steps: JSON swagger document being produced. (in progress)
PNF S/W Upgrade	Roll-back API. From SO to SDN-C (Controller). South-bound changes (captured in the Ansible Playbooks), impacting the external controller rather than the ONAP platform. Data pushed from API so south-bound APIs will have right data (in the payload). Reusing LCM API (between SO to SDN-C) which already has the rollback in there. The Rollback action is already specified in SDN-C. In the yang model for LCM.Yang (in CCSDK repository) file. Mandatory/generic header fields need to make them optional so that we can use them as a generic API to pass specific 5G info in the Payload. Currently Rollback function was not implemented yet (so no one is currently using this API). Next Steps: API definition details in progress. Changing field options, and defining the payload.
USE CASES WITH NO API IMPACT
PNF Plug and Play	New API for the Update Micro-service to SO (from the pnfUpdate event trigger) from Policy for the Reregistration Story. The "user" will be the BBS Micro-service U/C. Next Steps: Ajay in DCAE has accepted this micro-service. Final details of the new service-update API is being defined in conjunction with SO project (Seshu).
PNF Pre-onboarding / Onboarding	No API Impacts.
5G FM Meta Data 5G PM Dictionary	No API changes
Network Slicing	(Modeling only) - No API Changes