/
5G - PNF Plug and Play

5G - PNF Plug and Play

Owned by Shekar Sundaramurthy
Last updated: Jan 25, 2022 by Benjamin Cheung

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).

OVERVIEW OF PNF Plug and Play

BUSINESS DRIVERS

This section describes Business Drivers 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.

Business Markets - Plug and Play is 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 PNF Plug and Play.

The following table describes the five stages of Plug and Play

PNP STAGE

DESCRIPTION

STAGE 1:

PNF MODELING

Resources Definition/Services Definition – This is a design time step where the PNF is modeled using SDC. The PNF resource and services are modeled.

SDC: PNF (physical element) Modeling – SDC is used to model the PNF. PNF descriptors and artifacts can be onboarded. The service design is incorporated into the SDC design studio and validated for export.

Distribution of artifacts – The output of design time products is distributed to listeners in other ONAP components.

STAGE 2:

PNF INSTANCE DECLARATION

PNF Infrastructure Service Declaration – A work flow is invoked which will create an A&AI entry for the PNF. The work flow is invoked from a OSS or VID interface.

First part of PNF instantiation – This service instantiation work-flow is invoked which is handled in orchestration with SO.

DCAE & AAI Entry with PNF-name (e.g. MAC address) – The result of this stage of Plug and Play is that an inactive A&AI entry so that ONAP will be prepared when the PNF tries to register.

STAGE 3:

PNF BOOT STRAPPING

PNF Powers up and Boot-straps – Vendor specific steps are performed where the PNF is physically installed, powers up, and performs boot-strapping functions.

PNF performs a “Plug and Play” procedure – The PNF performs vendor specific steps which will allow the PNF to reach a state such that it is ready to contact ONAP.

STAGE 4:

PNF CONTACTS ONAP

PNF connects to ONAP via a Registration Event – The PNF contacts ONAP with a specific sequence of events using a pnfRegistration VES message.

PNF Registration Handler (PRH) processes the event – The PRH receives the VES message and performs ONAP registration functions.

STAGE 5:

PNF ACTIVATION

Connection points configured – ONAP configures transport information.

Second part of PNF service instantiation – The second part of PNF service instantiation is performed and ONAP sends the PNF a service configuration message.

PNF configured and ready to provide service – Any other vendor specific configuration is finished, and the PNF is now ready to provide service.


ACTORS IN PLUG AND PLAY FLOWS

The Actors in the Plug and Play Flow are:

ACTORS

DESCRIPTION

PNF

PHYSICAL NETWORK FUNCTION (PNF) – A Network Function that is hosted on a physical hardware device, not in the cloud infrastructure.

DHCP

DYNAMIC HOST CONFIGURATION PROTOCOL (DHCP) – Protocol to assign IP addresses to a network element (NE). The IP address can be dynamically assigned or static based on MAC address of PNF.

SEGW

SECURITY GATEWAY – Used to set up IPSec tunnels to protects against unsecured traffic entering an internal network of a operator; used by enterprises to protect their users from accessing and being infected by malicious traffic.

CA/RA

CERTIFICATE AUTHORITY / REGISTRATION AUTHORITY – Used to generate a service provider certificate for the PNF.

Initial EM

INITIAL EM – Provides basic configuration and software download services to the PNF. This might be an equipment vendor specific solution. Also, responsible for identifying a PNF.

SDN-C

SOFTWARE DEFINED NETWORK CONTROLLER (SDN-C) – A controller for Layer 0 to 3 devices. Manages transport and network connections.

DCA&E

DATA COLLECTION, ANALYTICS AND EVENTS (DCAE)– Gathers performance, usage, and configuration data from the managed environment.  Collect, store data and provides a basis for analytics within ONAP. For PNF Plug and Play can potentially perform analytics on the Plug and Play process, statistics, logs.

A&AI

ACTIVE & AVAILABLE INVENTORY – The PNF is identified as available inventory and tracked through a key which is the PNF-name. When onboarded the PNF gets an entry in A&AI and can then be tracked, requested, and seen by the ONAP components for service requests or other queries.

SO

SERVICE ORCHESTRATOR – Serves as a mediator and coordinator of service requests.

APP-C

APPLICATION CONTROLLER (APP-C) - A controller for Layer 4 to 7 applications.  Manages the life cycle of virtual applications, virtual network functions (VNFs), and components. APP-C manages the 5G DU & 4G DU.

PNF Registration Handler

PNF Infrastructure Manager – A microservice in DCAE used during PNF Plug-n-Play to process the PNF Registration event.

COMPONENT INTERACTION VIEW OF PLUG AND PLAY

The following diagram shows a component interaction view of Plug and Play.

Each of the STEP numbers corresponds to the Step numbers in the flow diagrams that follow, and are described in much more detail in each of those steps.

What should be noted is that Plug and Play is a complex interchange of the Functional run-time components within ONAP, such as the PRH (PNF Registration Handler), SO (service orchestrator), SDN-C (PNF Controller), A&AI (Active & available inventory), the DMaaP (Data Movement as a Platform) and the PNF. You can readily see that A&AI plays a central role during the Plug and Play procedure as the PNF A&AI entry is created and checked numerous times throughout the process. Also take note that SO and SDN-C are the two coordinating entities during the procedure. Notice that the PNF plays a central role in steps 26 and 28 when it is periodically sending the pnfRegistration VES event.


DESIGN TIME - PNF PLUG AND PLAY

STAGE 1 - DESIGN TIME PNP OVERVIEW

Design time and Plug and Play

The following describe the Design time flow.

The primary things that happen in Design time are:

Resources Definition/Services Definition – This is a design time step where the PNF is modeled using SDC. The PNF resource and services are modeled.

SDC: PNF (physical element) Modeling – SDC is used to model the PNF. PNF descriptors and artifacts can be onboarded. The service design is incorporated into the SDC design studio and validated for export.

Distribution of artifacts – The output of design time products is distributed to listeners in other ONAP components.

STAGE 1 - DESIGN TIME REQUIREMENTS

STEP 1 RESOURCE DEFINITION – The PNF resource it defined.

PNP-1090 [SDC] - SDC/CDS: Load PNF model & Controller blue-print for PNF orchestration and Network communication. Before R3/Casalanca a Preload interim solution was used for Network Assignments.

PNP-1100 [SDC] – SDC shall support definition for the resource. A user on the VID performs a Resource Declaration. This uses the Service definition created in SDC using the Design Studio. The user on the VID can define known information about the PNF.  The user can (optional) provide the following to define the resource definition.

PNF RESOURCE Definition

                Resource Type – Type of Resource. NEW type: PNF (pre-defined in SDC)

                NAME – Name of the PNF type

                CATEGORY – e.g. Infrastructure

                TAGS – User-definable tags (default name of the PNF)

                DESCRIPTION – Textual description

                CONTACT ID – Designer (user of ONAP)

                VENDOR – PNF Vendor (e.g. Nokia)

                VENDOR RELEASE – Vendor release

                VENDOR MODEL NUMBER – PNF Model value (link to A&AI)

                EVENTS – Monitoring Event definitions. Define design-time templates.

                SOFTWARE VERSION – The PNF Expected Software Version


STEP 2 SERVICE DEFINITION – The Service Definition is defined in SDC.

PNP-1200 [SDC] – The following service definition fields shall be supported. Note: in Casablanca (R3) one specific PNF can only be used in one service. There is a one-to-one cardinality between PNF and a Service. It is envisioned that for a 5G RAN network, one 5G DU PNF will have one 5G Service and a collection of PNFs will comprise a network.

SERVICE Definition (uses a PNF)

                NAME – Name of the Service (mandatory)

                CATEGORY – e.g. Network L1…L4, VOIP call Control, Mobility

                TAGS – User-definable tags (default name of the PNF)

                DESCRIPTION – Textual description of service (mandatory)

                CONTACT ID – Designer (user of ONAP) (mandatory)

                PROJECT CODE – ID (mandatory)

                Naming Policy – Policy to be used to assign a name to a service by SO/SDNC 

                SERVICE TYPE – Type of service

                SERVICE ROLE – The Role of this service.

                ENVIRONMENTAL CONTEXT – distributed environments



STEP 3 ARTIFACTS DISTRIBUTION – The artifacts that are defined in SDC are distributed to other components in ONAP once validated.

PNP-1300 [SDC] – SDC shall distribute CSAR package which contains the artifacts & PNF model from the design studio to other components in ONAP. Note: This is existing functionality – Test only requirement.

Note: Package has many catalogs, each application. For example, a model to be consumed by APP-C the model defines how this catalog is called. A publication on DMaaP bus informs that there is an available artifact. The receiving components checks the artifacts and knows what to look for. Each ONAP component gets everything and looks within the package to extract relevant artifacts.

Note: in R3, SDC-UI or CSAR package doesn’t support artifact definitions.

Note: In R3, for the PNF PnP to work, it requires a YAML definition to be manually populated by an operator in the monitoring framework of DCAE, because this can't be supported by SDC yet. These YAML definitions are needed to monitor the NF registration. The YAML definitions includes the registration files for all of the events that the NF can emit.

PNP-1310  [SDC] - [FUTURE] (After R3/Casablanca) - Need NF YAML Definition in the NF CSAR Package. The YAML registration event is necessary to validate what is emitted by the PNF is valid.

PNP-1320 [PNF] - [FUTURE R4] The PNF Vendor shall provide a PNF Descriptor for Design time SDC Design Studio input based on ETSI-NFV-IFA014v242 (see 5G-PNFPlugandPlay-STAGE1-PNFDESCRIPTOR for more details)

PNP-1330 [PNF] - The PNF Vendor MAY provide software Version(s) to be supported by PNF for SDC Design Studio PNF Model. This is set in the PNF Model property software_versions.

PNP-1340 [PNF] - The following VES Events MUST be supported by the PNF for Plug and Play: pnfRegistration 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. 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 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.

MODEL PARAMETER

DESCRIPTION

pnfId*

Identifier of this Pnf information element. CORRELATIONID = PNF-NAME (A&AI)

pnfType (template)*

Type of Resource. NEW type: PNF (pre-defined in SDC)

Category*

PNF category, e.g. infrastructure

Vendor (template)*

Identifies the vendor of the PNF.

Name*

Provides the human readable name of the PNF.

vendorrelease *

Vendor release

vendormodelNumber*

PNF Model value (link to A&AI)

functionDescription*

Describes the PNF function


PNP-1400 [SDC] – SOFTWARE VERSION - SDC shall support the SWversionList in the NF Model. This parameter represents a list of Expected Software to be supported by the NF. This is an optional parameter. As a LIST, this parameter shall support a structured list of software versions (as strings).

Note: The actual software running on a PNF instance is kept in an A&AI parameter for the PNF instance. This “detected Software” can be used in conjunction with this modeling parameter.

Note: This parameter may be used for a wide variety of purposes from network analysis, network planning, modeling analysis, trouble shooting, auditing, correlation, modeling informational, error checking, system evolution, network evolution, life cycle management, regional planning, regional analysis, service provider specific analytics, network management, and PNF feature & functional correlation.


STAGE 1 - PNF DESCRIPTOR

The following table is the PNF descriptor

Attribute

Qualifier

Cardinality

Content

Description

pnfdId

M

1

Identifier

Identifier of this Pnfd information element. It uniquely identifies the PNFD.

functionDescription

M

1

String

Describes the PNF function 

provider

M

1

String

Identifies the provider of the PNFD.

version

M

1

Version

Identifies the version of the PNFD.

pnfdInvariantId

M

1

Identifier

Identifies a PNFD in a version independent manner. This attribute is invariant across versions of PNFD.

name

M

1

String

Provides the human readable name of the PNFD.

pnfExtCp

M

1 … N

PnfExtCpd

Specifies the characteristics of one or more connection points where to connect the PNF to a VL. See clause 6.6.4.

security

M

0..1

SecurityParameters

Provides a signature to prevent tampering.

geographicalLocationInfo

M

0..1

Not specified

It provides information about the geographical location (e.g. geographic

coordinates or address of the building,

etc.) of the PNF. The cardinality 0 is used when the location is unknown.

RUN-TIME PNP FLOWS AND REQUIREMENTS

The following sections describe the flows and requirements for the major phases in Plug and Play during run time.

STAGE 2 RUN-TIME SERVICE INSTANTIATION

In the Service instantiation phase of Plug and Play, three main things happen:

PNF Infrastructure Service Declaration – A work flow is invoked by an operator which will create a request for a PNF to be instantiated. This work flow is invoked from a OSS or VID interface.

First part of PNF instantiation – This service instantiation work-flow is received and handled by the service orchestration (SO) component in ONAP.

DCAE & AAI Entry with PNF-name (e.g. MAC address) – The result of this stage of Plug and Play is that an inactive A&AI entry is created so that ONAP will be prepared when the PNF tries to register. It might also be the case that the A&AI entry was previously created from a different interface, in this case the A&A entry will already be in place.

STAGE 2 – SERVICE INSTANTIATION REQUIREMENTS

STEP 15 – WORK ORDER INITIATED - In this step, a Work Order is initiated from an operator using the VID. The Plug and Play flow requires an A&AI entry to be created so that when the PNF registers ONAP will recognize the unit. This requires that an operator be aware of the elements that need to be deployed into their network.

PNP-2000 [OSS/BSS/VID] – WORK ORDER – An operator processes a work order. The PNF service instantiation will be a result of processing the work order. Note: External ONAP APIs may be used to interface with the OSS/BSS.


STEP 16 – SERVICE INSTANTIATION - In this step, a service instantiation is issued from VID to SO. The operator invokes a service instantiation so that SO can take the necessary steps to create or verify that there is an A&AI entry for the PNF which satisfied the work order.

PNP-2100 [VID] – SERVICE INSTANTIATION - VID shall support the ability to invoke a Service Instantiation request to SO for the creation of a PNF. The operator uses VID to instantiate a Service. The Correlation ID = PNF Name = 3 characters of Vendor + PNF Serial Number are provided in the Service Instantiation request to SO.

Note: Other OSS/BSS systems may be used to instantiate a service.

Note: A service provider may choose to use a different identifier than the [Vendor] + [Serial Number], the corresponding PNF would need to also be configured to emit a matching identifier from the pnfRegistration Event.

PNP-2110 [SO] – SO shall decompose the 5G DU PNF Service. Based on the DU resource type, SO shall determine the appropriate SDC PNF Model for the service instantiation. Note: it is also possible that the Plug and Play (PnP) service instantiation may be part of a larger work-flow (e.g. VCPE work flow), during that larger work flow the PnP flow may happen. This would be handled by the service work-flow designer. Note: it is expected that the SO API shall be used for the service instantiation no matter the source (OSS/BSS or VID).

PNP-2120 [SO] – If SO is unable to perform the service instantiation it shall return an error.

 

STEP 17 – HOMING CHECK - A homing operation can be performed, though in Casablanca this is not used. The homing function by OOF can perform network deployment and network optimization functions. Note: There are optimization use cases that are being invested for development in Casablanca.

PNP-2200 [SO] – SO shall invoke OOF for a homing check.

PNP-2210 [OOF] – OOF shall return an acknowledgement. For the Plug and Play procedure in Casablanca the PNF OOF check has no impact.


STEP 18 – RESOURCE LEVEL FLOW - Resource Level Flow is invoked. The resource level flow is handled by SO to create the A&AI entry for the PNF if necessary.

PNP-2300 [SO] – SO shall invoke a Resource Level flow for the PNF instantiation.

PNP-2310 [SO] – SO checks A&AI for an entry that matches the PNF-Name.


STEP 19 – PNF A&AI ENTRY FOUND - ALT Flow: A&AI Entry found

PNP-2400 [SO] – FUTURE If SO determines that an A&AI entry already exists for the PNF when it performs the query, then SO shall associate the PNF with the service instance and it shall then proceed to step 21.

PNP-2405 [SO] - If SO determines that an A&AI entry already exists for the PNF when it performs the query, and SO will exit out.

PNP-2410 [A&AI] – A&AI shall return a PNF query check using the PNF-Name. If the entry is not found a negative acknowledgement shall be returned.

PNP-2415 FUTURE [SO] - STEP 19A/B (Active/Inactive) A&AI PNF Entry Found


STEP 20 – PNF A&AI ENTRY MISSING - ALT Flow: A&AI Entry missing

PNP-2500 [SO] – SO shall check for the A&AI entry, and SO shall identify if that A&AI entry does not exist, then SO shall proceed to step 21.

PNP-2510 [A&AI] – A&AI shall support responding to a query for an entry for the PNF.


STEP 21 – SUBSCRIBE - Subscribes to VES Event

PNP-2600 [SO] – SO shall subscribe to the DMaaP pnfReady topic. Note: The pnfReady event is published by the PRH after the PNF successfully registers with ONAP (Step 31)

PNP-2610 [SO] – If there is a fault subscribing to the pnfReady topic (DMaaP) the fault shall be logged.


STEP 22 – RESOURCE LEVEL FLOW (RLF) TERMINATES - The Resource Level Flow (RLF) waits

PNP-2700 [SO] – The SO RLF shall terminate and goes into a “wait state” awaiting rehydration after the PRH receives the PNF registration message from the PNF. Note: SO is pending a pnfReady event to be published onto the DMaaP Bus from the PRH to rehydrate this thread.

PNP-2710 [SO] – After SO terminates the RLF, SO shall wait for 2 weeks for the PNF to perform a registration. After 2 weeks passes the Work-flow shall terminate and generate an error which shall be logged and displayed on the OSS.

PNP-2720 [SO] – If there is a fault terminating the RLF, the fault shall be logged.


STAGE 2 - PNF A&AI ENTRY USED BY PNP

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-OAMThis 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.

ACTIVE & AVAILABLE INVENTORY (A&AI) PNF RECORD ADDITIONS FOR R3 CASABLANCA

ATTRIBUTEDESCRIPTION
PNFIPADDRESS-v4This is the IP address (IPv4) for the PNF itself. This is the IPv4 address that the PNF iself can be accessed at.
PNFIPADDRESS-v6This is the IP address (IPv6) for the PNF itself. This is the IPv4 address that the PNF iself can be accessed at.
SOFTWARE_VERSIONS

This is an Array of software versions that currently installed on the PNF. PNFs can have multiple partitions, and this array represents a list of all of the software versions that are currently installed on the PNF.. The Active SW is a boolean (True/False) that indicates that this specific version if the one that is "active" (if True).

software_versions [1…x] (Array)

{

  software_version (String)

  activeSw (Boolean)

}


STAGE 3 - PNP BOOTSTRAPPING

Assumption: Physical management connectivity between ONAP and the PNF is assumed to be setup prior to PNF Plug and Play, e.g. dealing with firewalls. etc.

In this stage, the PNF Boot-straps. This is comprised of two steps

PNF Powers up and Boot-straps – Vendor specific steps are performed where the PNF is physically installed, powers up, and performs boot-strapping functions.

PNF performs a “Plug and Play” procedure – The PNF performs vendor specific steps which will allow the PNF to reach a state such that it is ready to contact ONAP.


It is a requirement from ONAP on the equipment (PNF) vendors that the PNF shall have software capable of performing the PNF Registration. This shall be referred to as ONAP-aware software.

See the section on the ONAP needs to be developed by the PNF Vendors section of this document for more details, entitled “Vendor PNF PNP Deliverables”

Vendor PNF requirements in DOC project (the Appendix of “Vendor PNF PnP Deliverables)

PNP-3010 [PNF] - The PNF MUST support & accept the provisioning of an ONAP contact IP address (in IPv4 or IPv6 format).

Note: It is expected that an external EMS would configure & provision the ONAP contact IP address to the PNF (in either IPv4 or IPv6 format).