5G - PNF Plug and Play
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-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. |
ACTIVE & AVAILABLE INVENTORY (A&AI) PNF RECORD ADDITIONS FOR R3 CASABLANCA
ATTRIBUTE | DESCRIPTION |
---|---|
PNFIPADDRESS-v4 | This is the IP address (IPv4) for the PNF itself. This is the IPv4 address that the PNF iself can be accessed at. |
PNFIPADDRESS-v6 | This 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).