The PNF PnP flow is method, which allows to register within ONAP/AAI a PNF resource instance. This PNF resource instance is correlated with an existing service instance.
Once a PNF resource is registered, the infrastructure service instantiation flows are able to continue the service instantiation, by calling controllers, which in turn configure the PNF instance.

While this page was created in the R2 "Beijing" release, it is the "Base" Plug and Play page and applies for R2 through R9 (Honolulu).

Table of Contents

OVERVIEW OF PNF Plug and Play

BUSINESS DRIVERS

...

This section describes Business Drivers needs, Scenarios.
of this use case:

Executive Summary - Plug and Play provides a means for a service provider to work with their vendors to have their PNFs be "discovered" by their ONAP deployment through a PNF registration message.

Business Impact - For service providers to discover and deploy a network, Physical Network Functions (PNF) are needed to be deployed and discovered by their network. This serves as a foundation to create a wireless, optical, or wire-line network efficiently. The ability to deploy, discover, manage and incorporate PNFs efficiently is vital to business operations. Without Plug and Play, a service provider and their operator technicians would need to manually create the PNFs into their network which entails a high OPEX and would be very time-consuming and prone to error. For example, Wireless Service Providers will need to roll out tens of thousands of base stations across a nation/world, and the possible and potential business cost savings and expenditures related to rolling out, deploying, and incorporating PNFs to be recognized into a service provider's network encounters vast economies of scale which make Plug and play a vital business imperative.

STAGES OF PLUG AND PLAY

PNF Business Markets - Plug and Play is used to register a PNF when it comes on-line. This use case is intended to be applicable to a variety of PNFs such as routers and 5G base stations. The steps and descriptions have been drafted to be as general as possible and to be applicable to a relatively wide variety of PNFs. However, the use case was originally developed with consideration for 5G PNF Distributed Units (DU).applicable to multiple domains, and different kinds of PNFs and applies to any service providers networks.

Funding/Financial Impacts - Without Plug and Play, a service provider and their technicians would need to manually create and deploy PNFs into their network which entails a high OPEX particularly in a 5G RAN wireless network, where it is expected that there will be approximately 10-fold the number of base stations compared to 4G LTE.

Organization Mgmt, Sales Strategies - There is no additional organizational management or sales strategies for this use case outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider.

STAGES OF PLUG AND PLAY

PNF Plug and Play is used to register a PNF when it comes on-line. This use case is intended to be applicable to a variety of PNFs such as routers and 5G base stations. The steps and descriptions have been drafted to be as general as possible and to be applicable to a relatively wide variety of PNFs. However, the use case was originally developed with consideration for 5G PNF Distributed Units (DU).

The following diagram shows the five major phases of The following diagram shows the five major phases of PNF Plug and Play.

The following table describes the five stages of Plug and Play

...

PNP-1340 [PNF] - The following VES Events MUST be supported by the PNF for Plug and Play: pnfRegistration VES Event, HVol VES Event, and Fault VES Event. These are onboarded via the SDC Design Studio. Note: these VES Events are emitted from the PNF to support PNF Plug and Play, High Volume Measurements, and Fault events respectively.

STAGE 1 - PNF MODEL

. A PNF MUST support the pnfRegistration VES event which is required to integrate with ONAP’s PNF Plug and Play capabilities.

STAGE 1 - PNF MODEL

The following describes the PNF model The following describes the PNF model in SDC in the Beijing (R2) release. The following parameter are already supported in Beijing (R2) but because the PnP Use Case was not delivered, these will see their first operational use in the Casablanca (R3) release.

...

ACTIVE & AVAILABLE INVENTORY (A&AI) PNF RECORD
PNF-NAME	“pnf-name”. The pnf-name is the Key in AAI. The pnf-id is the first three letters of the Vendor and the PNF serial number. This is a unique identifier for the PNF instance. It is also referred to as the Correlation ID. It can serve as a unique key for the PNF. Note: The MAC address and serial number are not unique across vendors; but are unique per vendor, hence the Vendor name is added to insure uniqueness. Note: in R4/R6 there was a request to use PNF-id instead of PNF-name but that proposal has been rejected.
EQUIP-TYPE	The equip-type parameter gives the type of the PNF.
EQUIP-VENDOR	The equip-vendor is an optional parameter which indicates the vendor for the PNF. For example, Nokia or Ericsson.
EQUIP-MODEL	The equip-model is an optional parameter which indicates the model of the PNF.
PNF-ID	This is the UUID which is a service provider assigned number from for example a network planner..
IPADDRESS V4-OAM	This is the Manager IP Address in IPv4 for the PNF. For a DU, this might be a CU IP address; (FYI/ ipaddress-v4-loopback-0).
IPADDRESS v6-OAM	This is the Manager IP Address in IPv6 for the PNF. For a DU, this might be a CU IP address;
MAC ADDRESS	This is the MAC address of the PNF. This is a service field.
SERIAL NUMBER	This is the serial number of the PNF. This is a service field.
PROXY IP ADDRESS	This field contains the proxy IP address for the PNF.

...

Note: See the Vendor PNF PNP Deliverables (in the ONAP DOC Project) URL/Wiki: https://onap.readthedocs.io/en/latest/submodules/vnfrqts/requirements.git/docs/Chapter7/PNF-Plug-and-Play.html

Note: ONAP sends back a "normal" Acknowledgement (ACK) to the pnfRegistration VES event (HTTP or HTTPS)

STEP 26A pnfREGISTRATION EVENT ONTO DMAAP

...

A&AI PNF ENTRY	BASED ON pnfREGISTRATION VES FIELD
serial-number	serialNumber
equip-vendor	vendorName
equip-model	modelNumber
equip-type	unitType
pnf-name	sourceName
pnf-id	(PNF-ID is NOT used)
ipaddress-v4-oam	oamV4IpAddress
ipaddress-v6-oam	oamV6IpAddress
software_versions	software_versions [1] { softwareVersion (from pnfRegistration) activeSw = "True" } Note: During PNF Registration only the Active S/W is reported by the PNF. And so only the entry of the PNF A&AI array with the "activeSw" = True would be updated. The PNF S/W upgrade management U/C will update the entire array through the operations of S/W management.

...

PNP-5800 [SO] – SO shall inform the OSS that the PNF service is available and ready.

PNP REREGISTRATION USE CASE

This use case is intended to cover a new Epic or Use Case or "Story" for Plug and Play. In all of these situations for this use case, the PNF will go through Plug and Play registration again, hence "PNF Re-registration". In this case, the PNF has already ungone the basic Plug and Play is registering again with the same PNF registration procedure, except that ONAP already recognizes the PNF and it already has an A&AI entry.

The following diagram depicts basic Re-registration situations:

Image Removed

PNF DOWNLOAD & ACTIVATION

The final steps of PNF Plug and Play occur after the PNF has been registered. The ONAP PNF Software Use Case is also executed to update the software if necessary.

Image Added

STEP 44 CONFIGURATION – The PNF can have additional configuration or parameters that can be sent to the PNF from ONAP or an external Element Management System. Additioanl configuration exchanges can happen between the PNF and ONAP through the standard Defined VES event as introduced by this use case: ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over VES

STEP 45 PNF SOFTWARE UPGRADE – Software download occurs which is described in this use case: 5G - PNF Software Update

STEP 45 READY FOR SERVICE – The PNF is ready for service.

PNP REREGISTRATION USE CASE

This use case is intended to cover a new Epic or Use Case or "Story" for Plug and Play. In all of these situations for this use case, the PNF will go through Plug and Play registration again, hence "PNF Re-registration". In this case, the PNF has already ungone the basic Plug and Play is registering again with the same PNF registration procedure, except that ONAP already recognizes the PNF and it already has an A&AI entry.

The following diagram depicts basic Re-registration situations:

Image Added

(1) REHOMING - When a PNF is "rehomed" to a new NMS, or managing region it may go through re-registration. Rehoming can be a logical operation or a physical operation. The PNF may now have a new manager, an external manager. The PNF may also now have a new ONAP installation "(1) REHOMING - When a PNF is "rehomed" to a new NMS, or managing region it may go through re-registration. Rehoming can be a logical operation or a physical operation. The PNF may now have a new manager, an external manager. The PNF may also now have a new ONAP installation "home".

(2) DISCONNECTION/RECONNECTION - It is conceivable that a PNF may be powered off for a period of time and then is powered on again. A PNF only goes through base Plug and Play once. So a power cycle, or a disconnection/reconnection should not be considered a brand new Plug and Play. For ONAP purposes, this is tracked by the fact that the A&AI will already have a PNF entry. Note in this case, it is expected that the PNF is in the same physical location as before.

...

A&AI PNF ENTRY	BASED ON pnfREGISTRATION VES FIELD
serial-number	serialNumber
equip-vendor	vendorName
equip-model	modelNumber
equip-type	unitType
pnf-name	sourceName
pnf-id
ipaddress-v4-oam	oamV4IpAddress
ipaddress-v6-oam	oamV6IpAddress
software_versions	software_versions [1] { softwareVersion (from pnfRegistration) activeSw = "True" }

PNP-6250 [PRH] – If the PRH encounters a situation that there is a PNF entry in A&AI (without IP address), but the VES event itself does not have an PNF IP address it shall log the error.
Note: if the PNF does not send its IP address in the VES event this could be from a variety of reasons from a software error to a communication failure.

PNP-6260 [PRH] – (Error Case) If the PRH is unable to update the A&AI entry with the PNF information it shall log the error.

STEP 7 pnfUpdate EVENT = SERVICE UPDATE PROCEDURE - PRH sends pnfUpdate event

PNP-6270 [PRH] - PRH shall treat a PNF that is sending a pnfRegistration VES Event that already has an A&AI entry as a PNF that is re-registering. If the PRH has been identified as a PNF that is re-registering, PRH shall publish a pnfUpdate event on the DMaaP bus. This will call the Service Update Micro-Service (that is listening for pnfUpdate event). PRH shall pass the pnf-ID of the re-registering PNF so that the Service Update Micro-Service can identify the PNF. The Update Service Micro-service is listening for the pnfUpdate event.

Note: for the BBS Use Case, the additionalFields in the pnfRegistration message contains vital application information that needs to be preserved. This information should either be copied into a new field in the A&AI entry for the PNF, or it should be passed to the UpdateService Micro-service when PRH calls it. This information is copied in to the pnfUpdate event. This is an API change between PRH and consumer of the pnfUpdate event.

Note: The exact criteria, when to classify a pnfRegistration message as "initial registration" or "re-registration" are stored here: PNF Re-Registration criteria

PNP-6410 [DMaaP] – There shall be created a static pnfUpdate DMaaP Topic.

STEP 8 MICROSERVICE ANALYSIS - Microservice is invoked

PNP-6280 [UpdateServiceMSvc] - The purpose of the Update Service Micro-service is that it can identify an associated resource (PNF, VNF) of a service given the identifier, and process a reregistration procedure by updating the service associated with that resource. For example, suppose a PNF have been moved, the associated service needs to be updated. The Update Service Micro-service is listening for the pnfUpdate event.

STEP 9 POLICY USE - A policy framework is invoked

PNP-6290 [Policy] - The Update Service Micro-service issues a special EVENT which will be consumed by POLICY framework. A policy is invoked which performs the service update. The Policy Framework will find a specific policy to handle the request based on the PNF that is being updated. And it will call SO with a (new) Service Update API. The Policy has the responsibility of:

(1) determining that a PNF is reregistering

(2) identifying the PNF with its appropriate PNF-ID

(3) Finding the associated service(s) that is/are associated with the PNF and

(4) updating the service with the information passed from PRH.

(5) Publishing on the DMaaP bus the pnfUpdate Event which will cause SO to update the Service.

STEP 10 MODIFY SERVICE INSTANCE - Policy calls SO through a Modify Service API

PNP-6400 [Policy] – Policy invokes a Modify Service API towards SO. This has the effect to directly calling SO to perform the final steps of the service update associated with the PNF undergoing re-registration.

PNP-6420 [Policy]– (Error Case) If the PRH is unable to publish the pnfReady event onto the DMaaP topic it shall log the error.

STEP 11 QUERY A&AI - A&AI Query

PNP-6430 [SO] – SO shall query A&AI upon invocation of the Modify Service API (from Policy). SO queries A&AI for a valid PNF entry associated with the pnf-Id in the pnfReady event. SO subscribes to certain events, it performs a get off the DMaaP bus, and the pnfUpdate event and has a BPMN recipe associated with that pnfUpdate event. Note: In design-time a service designer creates a (set) of BPMN recipes for SO.

STEP 12 BPMN RECIPE - SO processes the Modify Service request (from Policy) Event

PNP-6440 [SO] -SO will process a BPMN Recipe for the Modify Service request from Policy. The purpose of this is to determine that the PNF is re-registering, and the invoke the appropriate actions to process a the modify service. This means that

(1) it will determine that this is an existing PNF that is reregistering. See the description of the reregistration use case to see why a reregistration occurs: (A) Rehoming (B) Disconnection/Reconnection (C) Physical Relocation (D) Nomadic PNF.

(2) Identify services that are currently depending on this service(s)

(3) Update the states for that PNF. This means that the associated resources of the associated service(s) of that PNF need to be updated (i.e. the PNF is now available). An analysis must be done that says that this PNF is no longer associated with the service (a policy rule with an algorithm assessment would be used to determine this).

(4) Identify the appropriate controller for that PNF.

Note: the Controller might be updated when the PNF re-registered.

STEP 13 RECONFIGURE PNF - PNF configuration is invoked

PNP-6450 [SO] – SO shall lookup through Controller-to-NF association, the appropriate Controller for the PNF. Then, SO shall invoke the PNF controller to request a PNF configuration exchange to happen.

Note: SO interacts with the PNF controller with the Understanding the the GENERIC-RESOURCE-APIs

STEP 14 PNF CONFIGURATION - Controller to PNF interaction

PNP-6500 [CONTROLLER] – The PNF Controller shall sends a Service Configuration to the PNF.

Note: For each associated API there is an associated Directed Graph (which playbook should be called).

PNP-6510 (CONTROLLER) – (Error Case) If there is an error encountered trying to send the Service Configuration command exchange to the PNF, the Controller shall log the fault.

PNP-6520 (CONTROLLER) – (Recovery Case) If there is an error encountered trying to send the Service Configuration command exchange to the PNF, the Controller shall attempt to retry.

PNP-6530 (CONTROLLER) – (Recovery Case) If there is not acknowledgment or response from the PNF while trying to perform a service configuration exchange, the controller shall wait for a time-out period before aborting this attempt. Note: This might be caused by a transient network issue.

PNP-6540 [PNF] - The PNF MUST support the Anible protocol for a Service Configuration message exchange between the PNF and PNF Controller (in ONAP).

Note: this exchange may be either Ansible, Chef, or NetConf depending on the PNF. Note: The PNF Controller may be VF-C, APP-C or SDN-C based on the PNF and PNF domain. Note: for R3 (Casablanca) only Ansible is supported.

PNP-6550 [PNF] - The PNF MUST support the NetConf protocol for a Service Configuration message exchange between the PNF and PNF Controller (in ONAP).

PNP-6560 [PNF] - When the PNF receives a Service configuration from ONAP, the PNF shall cease sending the pnfRegistration VES Event.

PNP-6570 [PNF] - The PNF MAY support the optional parameters for Service Configuration Parameters.

STEP 14A NOTIFICATION FROM PNF

A new notification event is sent from the PNF. This was first used by the BBS Use Case.

After the PNF has received a configuration update, the PNF sends a state change event, which informs ONAP is has successfully connected and serving customer-facing services (CFS).

This is an existing state change notification event (not a new event). An identifier is used within the event.

See the related Wiki pages: CPE Authentication Notification#CPEAuthenticationVESEvent

and CPE Authentication Notification (CPE Authentication Flow)

STEP 15 CONFIGURATION RESPONSE - Configuration Response

PNP-6580 [Controller] – The Controller shall return a response to SO after service configuration

STEP 16 A&AI UPDATE - A&AI Update

PNP-6590 [Controller] – The PNF Controller shall update the PNF A&AI Entry with updated configuration information.

SUMMARY OF CASABLANCA PLUG AND PLAY ENHANCEMENTS

The follow describes a summary of the Casablanca Enhancements for Plug and Play

Image Removed

...

TOPIC

...

DESCRIPTION

...

PNF Registration Handler (PRH) Improvements

...

pnfRegistration Domain - New VES Event domain for PNF registration with corresponding support in VES collector, DMaaP and PRH.

PRH & AAF Integration – intra-ONAP security improvements

Integration – Integration of Beijing software deliveries.

DU Simulator Update – Support of new domain and updates to the DU simulator to match changes made in Casablanca.

...

SO Workflow enhancements

...

Integration - Introduction of dedicated 5G use case work-flow. While the PnP Work-flow was coded in Beijing it was not delivered in that time frame.

PNF Controller Interaction – SO to the PNF controller interaction is developed in Casablanca (R3).

...

Service Configuration Improvement

...

PNF Controller – Service configuration improvements from PNF Controller to PNF after PNF registration to PRH. Five optional parameters are requested to be supported with the Casablanca release (R3).

...

Security Enhancements

...

Security Enhancements – Authentication, Certificates, User name & password and intra-ONAP security are used by the Plug and Play Use case.

...

Modeling enhancements

...

PNF Model – Modeling enhancements to support 5G PNF in ONAP with support for the new SoftwareVersionList parameter.

– If the PRH encounters a situation that there is a PNF entry in A&AI (without IP address), but the VES event itself does not have an PNF IP address it shall log the error.
Note: if the PNF does not send its IP address in the VES event this could be from a variety of reasons from a software error to a communication failure.