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. |
...
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-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 logical operation or 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".
...
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
...
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.
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.
PNF PLUG AND PLAY with LICENSING MANAGEMENT
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) | R5/R6 ElAlto/Frankfurt PnP EnhancementsFRANKFURT (R6) 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
...
Document | Description | Source |
---|---|---|
Zero Touch | IETF definition of Zero Touch Deployment | https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-29 |
Call Home | ZTP Call Home RFC (IETF RFC8071) | https://tools.ietf.org/html/rfc8071 |
3GPP TS32-501 | Defines PnP Use Case (U/C) | http://www.3gpp.org/ftp//Specs/archive/32_series/32.501/32501-f00.zip |
3GPP TS32-508 | Defines PnP Procedure | http://www.3gpp.org/ftp//Specs/archive/32_series/32.508/32508-f00.zip |
3GPP TS32-509 | Defines PnP Formats | http://www.3gpp.org/ftp//Specs/archive/32_series/32.509/32509-f00.zip |
ETSI Zero Touch Network Service Management | https://www.etsi.org/technologies/zero-touch-network-service-management | |
ONAP WIKI PNF Model | Example: PNF in AAI |