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
...
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. 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.
...
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. |
...
| 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:
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.
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:
(1) REHOMING - When a PNF is "rehomed" to a new NMS, or managing region it may go through re-registration. Rehoming can be a (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".
...
PNP-6590 [Controller] – The PNF Controller shall update the PNF A&AI Entry with updated configuration information.
...
PNF PLUG AND PLAY
...
with LICENSING MANAGEMENT
The follow describes a summary of the Casablanca Enhancements for Plug and Play
...
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.
WHAT: The Licensing Service exchange happens external to ONAP. This solution and message exchange is optional. An external Licensing management solution (e.g. vendor specific solution) will vary with the installed network elements of a vendor and service provider. For more information see the Licensing Management Use Case Page: xNF Licensing Management
WHY: Why is this relevant to Plug and play? Because during the Plug and Play process and registration & orchestration, the xNF can request and obtain licenses from a Licensing services.
WHEN: The interchange can happen any time after stage 3 in the Plug and Play flow.
HOW: The following diagram shows the Licensing Service exchange with the xNF:
The following table describes the steps involved in Licensing Managment.
Note: The interchange can happen any time after stage 3 in the Plug and Play flow
| STEP | DESCRIPTION |
|---|---|
| x | REQUEST LICENSES - The PNF, for example 5G RAN PNF (DU) contacts the License Service to request licenses. Note: This step is optional. This step is labeled "X" because it can be initiated any time after stage 3 in the Plug and Play flow. |
| y | RESPONSE WITH LICENSES - The License Service responds to the request for licenses to the originating PNF. Note: This step is optional. This step is labeled "Y" because it can be initiated any time after stage 3 in the Plug and Play flow. |
SUMMARY OF R3 CASABLANCA PLUG AND PLAY ENHANCEMENTS
The follow describes a summary of the Casablanca Enhancements for Plug and Play
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. |
PNF Onboarding / Package | PNF Package - Defining PNF Onboarding Package. Extending framework to work with PNFs. Defining PNF Package framework. The PNF package artifacts will be delivered in Dublin such as the PM dictionary and FM Yaml dictionary. The definition of these are explored in Casablanca. |
Plug and Play Overview Slides, Demos and Talks (R2-R9)
The following table has some of the Plug and Play overview slides, demos and talks
| Description | File |
|---|---|
PnP Overview Presentation & Talk (from R7 Guilin Release) | |
| PnP Overview Presentation & Talk | Use Case Realization Call: February 19, 2020 |
ROADMAP - PNP Plug and Play Evolution per Release (R2 Beijing - R8 Honolulu)
The following table are Links to the PnP in different releases:
| Release | Wiki Link |
|---|---|
| R2/R3 Beijing Casablanca | 5G - PNF Plug and Play (This base page) |
| R4 Dublin | 5G - PNF Plug and Play (Casablanca carry-over items) |
| R5 El Alto | Maintenance Release |
| R6 Frankfurt | PNF PLUG and PLAY in R6 Frankfurt |
| R7 Guilin | R7 PNF Plug and Play PnP |
| R8 Honolulu | R8 PNF Plug and Play Use Case |
| R9 Istanbul | (No new development) |
| R10 Jakarta | (No new development) |
| R11 Kohn | (No new development) |
The following table show the PnP Roadmap
...
PNF Onboarding / Package
PNF Package - Defining PNF Onboarding Package. Extending framework to work with PNFs. Defining PNF Package framework. The PNF package artifacts will be delivered in Dublin such as the PM dictionary and FM Yaml dictionary. The definition of these are explored in Casablanca.
...
PnP Flow STEP | BEIJING (R2) | CASABLANCA (R3) | DUBLIN (R4) 5G - PNF Plug and Play (Casablanca carry-over items) | FRANKFURT (R6 Frankfurt PnP Enhancements) PNF PLUG and PLAY in R6 Frankfurt |
1 Resource Definition | Initial Development | No S/W Change; First Integration | This is now handled with the PNF Pre-onboarding/Onboarding use case: | |
2 Service Definition | Initial Development | SDC: new PNF model parameters | ||
3 Type Modeling Artifacts | Initial Development | No S/W Change; First Integration | ||
4 Resource Declaration | Initial Development | Alt Operator`s Inventory Management system supported | ||
5 Create A&AI PNF Entry | Initial Development | Alt Operator`s Inventory Management system supported | PNF Schema change from PNFID (new) and redacting (PNF-name old) | |
13 ONAP Compliant S/W | Initial Development | No S/W Change; First Integration | ||
15 Work Order to SO | Initial Development | SO: First R2 Integration | VID enhancements with new Presentation Layer Controller to NF association architecture (development in El Alto) | |
16 Service Instantiation | Initial Development | SO: First R2 Integration | ||
17 Homing OOF Sniro | Initial Development | SO: First R2 Integration | ||
18 Resource RLF | Initial Development | SO: First R2 Integration | ||
19 Check A&AI Entry | Initial Development | SO: First R2 Integration | A&AI Schema update using PNF-ID instead of PNF-name | |
20 Create A&AI Entry | Initial Development | SO: First R2 Integration | ||
21 Subscribe VES Event | Initial Development | SO: First R2 Integration | ||
22 RLF Thread Terminates to Wait State | Initial Development | SO: First R2 Integration | ||
25 Authenticates PNF Connection | Initial Development | Enhanced ONAP Security developed. TLS, Certificate support, Authentication | Certificate Authentication for HTTPS/TLS | |
26, 28 PNF Registration VES Events | Initial Development | New pnfRegistration domain, Static DMaaP topics | A new EPIC the PNF Re-Registration Use Case is introduced (see this Wiki) | |
27 Inventory Query (A&AI) | Initial Development | New pnfRegistration domain | A&AI Schema update using PNF-ID instead of PNF-name | |
29 Inventory Query (A&AI) | Initial Development | New pnfRegistration domain | ||
30 Update PNF Entry | Initial Development | New pnfRegistration domain | ||
31 PNF Ready | Initial Development | New pnfRegistration domain | ||
34 Update PNF WF | Initial Development | SO: First R2 Integration | ||
35 Network Assignments | Initial Development | SDN-C: PNF PnP Development | ||
36 Configure | Initial Development | SO: First R2 Integration | ||
37 Service Configuration | Initial Development | PNF Controller development | Controller to NF association architecture (development in El Alto) New API between SO to SDNC. NETCONF support for Configuration (see the Netconf Use Case) | |
38 SO Updates w/ Assignments | Initial Development | No S/W Change; First Integration | ||
39 Controller Replies | Initial Development | No S/W Change; First Integration | ||
40 Service Running | Initial Development | No S/W Change; First Integration | ||
41 Monitors Service | Initial Development | No S/W Change; First Integration | ||
42 Inform OSS | Initial Development | No S/W Change; First Integration |
The Dublin PnP Enhancements can e found on this wiki:
5G - PNF Plug and Play (Casablanca carry-over items)
DEVELOPMENT STATUS
Development Status
...
- WHO IS TESTING - what company, team, and people will be doing the testing & responsibilities for testing.
- TEST ENVIRONMENT - which does the lab & test environment.
- RESOURCES NEEDED - what resources are needed.
- WHO IS CONTRIBUTING RESOURCES - what resources will be provided and by whom/what company.
- NETWORK CONNECTIVITY - How will a PNF make connectivity to ONAP DCAE VES Event Listener.
TEST & INTEGRATION
| PNF PnP Integration Test Cases | 5G - PNF PnP - Integration Test Cases |
| Testing Status | Dublin 5G - PNF PnP - Test Status |
| R6 Integration Status Page | 2: Frankfurt Release Integration Testing Status |
DEPLOYMENT DIAGRAM
TEST CASES
...