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.
OVERVIEW OF PNF Plug and Play
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 ID (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 ID. 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-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.
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 (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 ID (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 ID = 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 ID.
STEP 19 – PNF A&AI ENTRY FOUND - ALT Flow: A&AI Entry found
PNP-2400 [SO] – 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-2410 [A&AI] – A&AI shall return a PNF query check using the PNFID. If the entry is not found a negative acknowledgement shall be returned.
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 – 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. |
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 | 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. |
MANAGER IP ADDRESS | adds ipaddress-v4-oam; ipaddress-v6-oam This is the “manager IP Address” which for a DU might be a CU IP address; (FYI/ ipaddress-v4-loopback-0). |
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. |
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)
STAGE 4 RUN-TIME PNF REGISTRATION
In this phase of Plug and Play the PNF Registers with ONAP
STAGE 4 – PNF REGISTRATION ONAP REQUIREMENTS
This section describes the PNF registration steps. In this stage of the PnP procedure, the PNF is registering with ONAP. The PNF periodically sends up a PNF registration event. PRH is receiving these events and waiting for the SO instantiation to happen.
STEP 25 AUTHENTICATION – In this step a series of steps occur for the PNF to authenticate with ONAP. This may include TLS1.2 security exchanges, certificate exchanges, and User name/password exchanges. This should be tested. the generalized detailed requirements for security are covered in the security sub-committee.
PNP-4100 [AAF] AAF shall authenticate the PNF. Note: This requirement is here for testing purposes, the detailed requirements for PNF to ONAP security shall be detailed in the security sub-committee.
PNP-4110 [AAF] AAF shall be able to inboard the security keys for vendor certificate validation.
ACTION #@# Check w/ Linda
STEP 26 PNF SENDS PNF REGISTRATION – The PNF (5G DU) sends a PNF registration message which is received by the PNF Registration Handler in ONAP. This message is sent by the PNF periodically.
PNP-4200 [PNF] – The PNF shall have the IP address to which to contact ONAP provisioned. Note: it is expected that an ONAP operator can ascertain the ONAP IP address or the security gateway to reach ONAP on the VID or ONAP portal GUI.
PNP-4210 [PNF] – The PNF shall send the pnfRegistration VES event detailed in the “PNF Registration VES Event” section of this document. Note: See the Vendor PNF PNP Deliverables (in the ONAP DOC Project)
PNP-4220 [PRH] – When the PNF sends a VES event, PRH shall periodically check the DMaaP bus for the VES event for the PRH. [DCAE/DMaaP/DR] DCAE shall publish the VES event received from the PRH onto the DMaaP/DR. The VES event should be using the pnfRegistration domain (Casablanca)
PNP-4230 [DMaaP] – There shall be created a static pnfRegistration DmaaP Topic. Note: That a static as opposed to a dynamic DMaaP topic is needed because it is not known what PNF service will be needed when the PNF registers.
PNP-4240 [PRH] – If the PRH is unable to read from DMaaP on the pnfRegistration domain it shall return an error.
PNP-4250 [DMaaP] In DMaaP, end-points need to be configured (topic creation). And PRH needs to have these end-points configured as well. PRH needs to pick up this configuration (cloudify module). And if they are not properly configured, PRH is unable to get the pnfRegistration message off of the DMaaP bus. What would happen is that the DMaaP end-point does not exist; thus an HTTP error response is returned to the PRH. It would require an operator to deduce that this problem has occurred.
PNP-4260 [PRH] - if the PRH is unable to read the pnfRegistration VES message. In this case the schema might be incorrect which results in a mismatch with what the PNF sends and what the PRH expects. Thus, the PRH is unable to process the VES event properly. The PRH shall logs this error.
STEP 27 PRH DOES INVENTORY QUERY – PRH performs an A&AI inventory query when it receives the pnfRegistration VES event from PNF to see if the entry exists.
PNP-4300 [PRH] – The PRH shall perform an A&AI inventory query when it receives the pnfRegistration VES event. In this case, the A&AI entry does not exist yet. PRH will continue to wait, pending the SO resource instantiation flow. Note: The expectation is that the PNF will continue to send VES events periodically. This would be a vendor requirement upon the PNF. Note: ONAP will wait up to 2 weeks for the PNF to register from the point in time that first service instantiation is created for the PNF.
PNP-4310 [PRH] – (Error Case) If the PRH is unable to perform an inventory query from A&AI it shall log the error.
STEP 28 PNF SENDS PNF REGISTRATION – PNF continues to send a PNF registration event
PNP-4400 [PRH] - PRH shall periodically check the DMaaP bus checking for the pnfRegistration domain for VES events related to PRH handling. Because the PNF is continuing to periodically send pnfRegistration events, PRH should continue to receive them.
Note: it is expected that the PNF shall continue to send these until it receives the service configuration request.
Note: It is expected that each vendor will enforce some sort of PNF timeout period, the PNF cannot wait indefinitely as there may also be a technician on-site trying to complete installation & commissioning. The management of the VES event exchange is also a requirement on the PNF to be developed by the PNF vendor.
PNP-4410 [DCAE] – The pnfRegistration VES event from the PRH shall be received by DCAE.
PNP-4420 [DMaaP] – The pnfRegistration VES event shall be published on the DMaaP bus with the appropriate PNF ID on the pnfRegistration domain. The DCAE VES Collector puts the pnfRegistration VES event received by the PNF with the PNF-ID (concatenation of the Vendor & Serial Number) onto the DMaaP bus.
Note: This will have been a statically created domain before this event arrives in ONAP.
PNP-4430 [DCAE] – The VES event that is received by the PNF shall follow the appropriate fields and corresponding information. These are further detailed in the PNF Registration VES Event section. DCAE shall receive the event and check the header in the VES event. Note: The composition of the appropriate VES event is also requirement on the PNF to be developed by the PNF vendor.
STEP 29 INVENTORY QUERY - PRH performs an A&AI inventory query when it receives the VES event to see if exists.
PNP-4500 [PRH] – The PRH shall perform an A&AI inventory query when it receives the pnfRegistration VES event from the PNF. Note: it is expected that the PNF shall continue to send the VES event until it receives the service configuration request. After the Stage 2 Run-Time Service Instantiation occurs, there shall be an inactive A&AI entry for the PNF. This allows PRH to find that inactive A&AI entry and proceed with the rest of the Plug and Play procedure. PRH shall use the PNF ID (or correlation ID) to find the appropriate PNF A&AI entry.
PNP-4510 [A&AI] – A&AI shall return the entry for the PNF ID when queried. If not found A&AI shall return a negative acknowledgement. See the section on the A&AI PNF entry for more details about the fields that are relevant for the PNF.
STEP 30 UPDATE PNF ENTRY – PRH finds the PNF A&AI entry and updates it with the PNF IP address
PNP-4600 [PRH] – If PRH finds an A&AI entry for the PNF, it shall populate the IP address for that entry with the IP address provided in the pnfRegistration VES event sent from the PNF.
Note: The PNF is the master of its IP address and would over-write the IP address in the PNF A&AI entry with the one provided in the VES event.
PNP-4610 [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-4620 [PRH] – (Error Case) If the PRH is unable to update the A&AI entry with the PNF information it shall log the error.
STEP 31 PNF READY EVENT – PRH issues a pnfReady event.
PNP-4700 [PRH] – After the PRH write the IP address of the PNF in the A&AI entry, the PRH shall publish a pnfReady event on the DMaaP topic. Note: This pnfReady event shall be processed by SO to proceed with the Plug and Play procedure.
PNP-4710 [DMaaP] – There shall be created a static pnfReady DMaaP Topic.
PNP-4720 [PRH] – (Error Case) If the PRH is unable to publish the pnfReady event onto the DMaaP topic it shall log the error.
STAGE 3 - PNF REGISTRATION VES EVENT
Field | Type | Required? | Description |
Version | number | Yes | Version of the event header (currently: 3.0): 3.0 |
eventName | string | Yes | pnfRegistration_vendor_pnfName where pnfName is specified by the vendor and is a PNF type; e.g. pnfRegistration_Nokia_gDu |
domain | string | Yes | Event domain enumeration: ‘fault’, ‘heartbeat’, ‘measurementsForVfScaling’, ‘mobileFlow’, ‘other’, ‘sipSignaling’, ‘stateChange’, ‘syslog’, ‘thresholdCrossingAlert’, ‘voiceQuality’, ‘pnfRegistration’ |
eventId | string | Yes | Event key that is unique to the event source registration_yyyyyyyy where yyyyyyyy is an integer starting at 0 and incremented by 1 for every pnfRegistration event sent by this PNF. The key must be unique within notificaiton life cycle similar to EventID from 3GPP. It could be a sequential number, or a composite key formed from the event fields, such as domain_sequence. The eventId should not include whitespace. |
eventType | string | No | pnfRegistration |
nfcNamingCode | string | No | Network function component type: 3 characters (aligned with vfc naming standards). This is not used |
nfNamingCode | string | No | Network function type: 4 characters (aligned with vnf naming standards) Not used |
sourceId | string | No | UUID identifying the entity experiencing the event issue (note: the AT&T internal enrichment process shall ensure that this field is populated) Not used |
sourceName | string | Yes | Name of the entity experiencing the event issue PNFid (unique PNF instance ID = PNF correlation ID = pnf-name stored in AAI ; e.g. NOK6061ZW3) |
reportingEntityId | string | No | UUID identifying the entity reporting the event, for example an OAM VM (note: the AT&T internal enrichment process shall ensure that this field is populated) Not used |
reportingEntityName | string | Yes | Name of the entity reporting the event, for example, an EMS name. May be the same as the sourceName. For synthetic events generated by DCAE, it is the name of the app generating the event. PNFid (unique PNF instance ID = PNF correlation ID = pnf-name stored in AAI ; e.g. NOK6061ZW3) |
priority | string | Yes | Processing priority enumeration: ‘High’, ‘Medium’, ‘Normal’, ‘Low’ Normal |
startEpochMicrosec | number | Yes | the earliest unix time aka epoch time associated with the event from any component--as microseconds elapsed since 1 Jan 1970 not including leap seconds current time |
lastEpochMicrosec | number | Yes | the latest unix time aka epoch time associated with the event from any component--as microseconds elapsed since 1 Jan 1970 not including leap seconds current time |
sequence | integer | Yes | Ordering of events communicated by an event source instance (or 0 if not needed) 0 |
internalHeader Fields | Internal Header Fields | No | Fields (not supplied by event sources) that the VES Event Listener service can use to enrich the event if needed for efficient internal processing. This is an empty object which is intended to be defined separately by each provider implementing the VES Event Listener. Empty. Not used |
vesEventListenerVersion | string | Yes | Version of the VES event listener API Spec that this event is compliant with (As "#" or "#.#" or "#.#.#" where # is a digit. |
timeZoneOffset | string | No | Offset to GMT to indicate local time zone for device formatted as 'UTC+/-hh.mm'; see https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations for UTC offset examples |
Field | Type | Required? | Description |
pnfRegistration FieldsVersion | number | Yes | Version of the pnfRegistrationFields block as "#.#", where # is a digit (currently: 1.0). See the VES Event Specification for the correct digits to use. |
serialNumber | string | Yes | TS 32.692 serialNumber = serial number of the unit; e.g. 6061ZW3 |
vendorName | string | Yes | TS 32.692 vendorName = name of manufacturer; e.g. Nokia. Maps to AAI equip-vendor. |
oamV4IpAddress | string | No1 | IPv4 m-plane IP address to be used by the manager to contact the PNF. Maps to AAI ipaddress-v4-oam. |
oamV6IpAddress | string | No1 | IPv6 m-plane IP address to be used by the manager to contact the PNF. Maps to AAI ipaddress-v6-oam. |
macAddress | string | No | MAC address of OAM interface of the unit. |
unitFamily | string | No | TS 32.692 vendorUnitFamilyType = general type of HW unit; e.g. BBU. |
unitType | string | No | TS 32.692 vendorUnitTypeNumber = vendor name for the unit; e.g. Airscale. Maps to AAI equip-type. |
modelNumber | string | No | TS 32.692 versionNumber = version of the unit from vendor; e.g. AJ02. Maps to AAI equip-model. |
softwareVersion | string | No | TS 32.692 swName = active SW running on the unit; e.g. 5gDUv18.05.201. |
manufactureDate | string | No | TS 32.692 dateOfManufacture = manufacture date of the unit in ISO 8601 format; 2016-04-23. |
lastServiceDate | string | No | TS 32.692 dateOfLastService = date of last service in ISO 8601 format; e.g. 2017-02-15. |
additionalFields | hashMap | No | Additional registration fields if needed, provided as key-value pairs. |
STAGE 5 - RUN-TIME PNF ACTIVATION
In the last Stage, the PNF is given network assignments, configures, and becomes active and available for service.
STAGE 5 - PNF ACTIVATION REQUIREMENTS
This section describes the PNF activation requirements. In this stage of PNP, the PNF has sent the PNF registration event and it has been received by the PRH successfully, and now in the PnP procedure, SO coordinates with the PNF controller and SDN-C to give the network assignments and service configuration for the PNF.
The major outcome of Stage 5 of the Plug and Play procedure is:
Connection points configured – SDN-C in ONAP configures the PNF 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. Also, ONAP updates the network assignment information, starts the service, and monitors the service provided by the PNF.
PNF configured and ready to provide service – Any other vendor specific configuration is finished, and the PNF is now ready to provide service.
STEP 34 UPDATE PNF WORKFLOW – DCAE rehydrates the SO Work-flow. In Step 31, the PRH has published a pnfReady onto the DMaaP Bus.
PNP-5000 [DCAE] - DCAE rehydrates the SO Resource-Level flow. The pnfReady topic on the DMaaP bus is used by SO to rehydrate the Resource-level flow.
PNP-5010 [SO] – SO monitors for the pnfReady topic on the DMaaP bus and shall invoke the update PNF work-flow for the PNF with the PNF ID given in the pnfReady event.
PNP-5020 [SO] – SO shall query A&AI upon receipt of the pnfReady Event
PNP-5030 [SO] – (Error Case) If there is an error in invoking the Work-flow an error shall be logged.
STEP 35 NETWORK ASSIGNMENTS – SDN-C performs the Network Assignments
PNP-5100 [SDN-C] - SDN-C shall perform the Network Assignments.
STEP 36 CONFIGURE CONTROLLER – SO configures the Controller
PNP-5200 [SO] – SO shall configure the PNF controller with the information that needs to be sent to the PNF.
STEP 37 SERVICE CONFIGURATION – ONAP sends a Service Configuration to the PNF
PNP-5300 [CONTROLLER] – The PNF Controller shall sends a Service Configuration to the PNF.
PNP-5310 [CONTROLLER] – The following parameters are optional parameters that shall be supported by the ONAP Controller that might be sent to the PNF if they are configured.
SERVICE CONFIGURATION PARAMETER | DESCRIPTION |
Configuration Parameter (optional) | SDN-R/APP-C gives the Controller IP@ to the DU. In R3, SDN-R/APP-C may pass configuration parameter(s) to the 5G DU, this will also give a configuration parameter (e.g. CU IP@). |
OAM IP address (optional) | The permanent OAM IP address is given to the PNF. The IP address may come from vAAA, or drawn local pool of IP addresses. SDN-C performs the IP address selection. SDN-C knows if a permanent IP address should be assigned. |
Transport configuration (optional) | Transport configuration is given to the PNF. |
Location (optional) | the Location configuration may be given to the PNF. |
Software Version (optional) | In Casablanca it could be specified a Software Version. |
PNP-5320 (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-5330 (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-5340 (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.
STEP 38 UPDATED NETWORK ASSIGNMENTS – Network assignments from SDN-C are updated
PNP-5400 [SO] – SO shall update the Network assignments information from SDN-C into PNF entry in A&AI.
PNP-5410 [A&AI] – A&AI shall support an update of the Network Assignments with the appropriate fields. For more information see the A&AI section on PNF A&AI entry
PNP-5420 [SO] – (Error Case) If there is an error in update it shall log the error.
STEP 39 CONTROLLER REPLIES – The Controller replies to SO
PNP-5500 [Controller] – The Controller shall return a response to SO after service configuration
STEP 40 SERVICE RUNNING – The PNF service is running and available to provide service
PNP-5600 [SO] – SO shall send a service running on DCAE.
STEP 41 MONITOR SERVICE – ONAP can now monitor the Service
PNP-5700 [DCAE] – DCAE shall monitor the new service
STEP 42 INFORM OSS – An operator at the OSS can now see that the service is available.
PNP-5800 [SO] – SO shall inform the OSS that the PNF service is available and ready.
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. |
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. |
ROADMAP - PNP Plug and Play Evolution per Release
PnP Flow STEP | BEIJING (R2) | CASABLANCA (R3) | DUBLIN (R4) |
1 Resource Definition | Initial Development | No S/W Change; First Integration | |
2 Service Definition | Initial Development | SDC: new PNF model parameters | |
3 Type Modeling Artifacts | Initial Development | No S/W Change; First Integration | FM, PM Dictionary artifacts |
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 | |
13 ONAP Compliant S/W | Initial Development | No S/W Change; First Integration | |
15 Work Order to SO | Initial Development | SO: First R2 Integration | |
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 | |
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 | |
26, 28 PNF Registration VES Events | Initial Development | New pnfRegistration domain, Static DMaaP topics | |
27 Inventory Query | Initial Development | New pnfRegistration domain | |
29 Inventory Query | 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 | |
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 |
DEVELOPMENT STATUS
Development Status
Project | PTL | JIRA | Description |
---|---|---|---|
DCAE | Lusheng Ji | PNF PnP - PNF Registration Handler | |
Support VES Version 6.0 specification and new Registration domain (new Casablanca scope) | |||
DMaaP | Ram Koya | Static set-up of DMaaP topics - PNF PnP (EPIC) | |
TBD | PNF PnP topics: "REGISTRATION" & "PNF_READY" (Story) | ||
VNFRQTS | Steven Wright | TBD: | |
VID | Jira VID-203 | VIR Support for PnP Plug and Play, with vCPE Flow. |
TESTING - PNF PLUG AND PLAY INTEGRATION & TESTING
- 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.
DEPLOYMENT DIAGRAM
TEST CASES
PnP Flow STEP | TEST CASE SECTION | TEST STATUS |
1 Resource Definition | PnP1 Resource Definition | NOT TESTED |
2 Service Definition | PnP2 Service Definition | NOT TESTED |
3 Type Modeling Artifacts | PnP3 Type Modeling Artifacts | NOT TESTED |
4 Resource Declaration | PnP4 Resource Declaration | NOT TESTED |
5 Create A&AI PNF Entry | PnP5 Create A&AI PNF Entry | NOT TESTED |
13 ONAP Compliant S/W | PnP13 ONAP Compliant S/W | NOT TESTED |
15 Work Order to SO | PnP15 Work Order to SO | NOT TESTED |
16 Service Instantiation | PnP16 Service Instantiation | NOT TESTED |
17 Homing OOF Sniro | PnP17 Homing OOF Sniro | NOT TESTED |
18 Resource RLF | PnP18 Resource RLF | NOT TESTED |
19 Check A&AI Entry | PnP19 Check A&AI Entry | NOT TESTED |
20 Create A&AI Entry | PnP20 Create A&AI Entry | NOT TESTED |
21 Subscribe VES Event | PnP21 Subscribe VES Event | NOT TESTED |
22 RLF Thread Terminates | PnP22 RLF Thread Terminates | NOT TESTED |
25 Authenticates PNF Connection | PnP25 Authenticate PNF Connection | NOT TESTED |
26 PNF Registration VES Events | PnP26 PNF Registration VES Events | NOT TESTED |
27 Inventory Query | PnP27 Inventory Query | NOT TESTED |
29 Inventory Query | PnP29 Inventory Query | NOT TESTED |
30 Update PNF Entry | PnP30 Update PNF Entry | NOT TESTED |
31 PNF Ready | PnP31 PNF Ready | NOT TESTED |
34 Update PNF WF | PnP34 Update PNF WF | NOT TESTED |
35 Network Assignments | PnP35 Network Assignments | NOT TESTED |
36 Configure | PnP36 Configure | NOT TESTED |
37 Service Configuration | PnP37 Service Configuration | NOT TESTED |
38 SO Updates w/ Assginments | PnP38 SO Updates w/ Assginments | NOT TESTED |
39 Controller Replies | PnP39 Controller Replies | NOT TESTED |
40 Service Running | PnP40 Service Running | NOT TESTED |
41 Monitors Service | PnP41 Monitors Service | NOT TESTED |
42 Inform OSS | PnP42 Inform OSS | NOT TESTED |
APPENDIX - A VNF TO PNF COMPARISON
TOPIC | VNF | PNF |
Concept | Application fulfills the role of a network function. | It is a network element, a physical entity, which can implement the role of a network function. |
Physical Characteristic | Application without dedicated hardware; Virtualized applications require specific capabilities; Run on different vendor servers. SRIOV, Inter-PNP-DPDK. Hardware capabilities. | Has an actual physical asset that is deployed and associated directly with the PNF. |
On-boarding | To onboard a VNF is to “bring it into ONAP” i.e. the VNF images, component VNF-C provide descriptors of these NFs. Deployment model, # components, functions. Configuration parameters. VNF is not tied or optimized for a specific hardware, only requiring perhaps some capability to be supported. | For PNF provide the descriptors. Only provide the meta-data. PNF S/W specifically optimized to run on dedicated hardware. (Now) Not the software image. (Future) ONAP will provide the software image repository. |
Plug and Play | The model triggers the orchestration. | (See this slide package for PNF Plug and Play) at the end of PnP the PNF can provide service. |
Characteristics | 5G CU could be a VNF since there is no need to have an association to a physical environment. | 5G DU must be PNF. PNFs are Elements which may need to interact with the physical environment. PNF is “High-Touch” technology. E.g. Emit radio waves in a geographical area. |
Configurability & Deployment | Easily adaptable to functions that you expect. E.g. Packet gateway to reconfigure as different NFs. Services easily create instances reconfigures including deployments (for different applications). Use a different instance of the VNF to provide a new service. For a VNF you can easily “delete” and “create” a new VNF to perform a new function. Configured dynamically. | PNF has a “fixed” set of capabilities but can’t easily reconfigure it. One PNF in multiple services. Different capabilities exposed by the PNF. Reuse the same PNF with different services configuration. For a PNF you would not “destroy” a PNF but rather re-configure it. Can be configured dynamically. |
ONAP Interaction | ONAP is started with VNF. VNF is “deployed” on-demand. Control from the ONAP perspective when a deployment of a VNF happens. DCAE – same Configure – Chef, Ansible | PNF do not “deploy” application. Do not use multi-VIM. Only “configure” the application, the PNF is deployed. A technician goes to site and “deploys” a PNF. DCAE – same Configure –Implementation of PNF client. Communication protocol, Client |
Design Time Modeling | Model VNF. Templates. Onboarded before. In Run-time. Make sure properly identify specific PNF instance already deployed versus a dynamically created instance. VNF instances could be created & instantiated dynamically. SDC may assumed instantiation of network function. | PNF cannot be instantiated, a PNF is only instantiated when it “powers up” and connects to ONAP. Service Orchestration. PNF is instantiated by nature of a PNF installation & commission procedure. |
Service Orchestration | VNF cloud, #VM resources consumption, define components implement different functions. Where & What will be deployed. | Physical location, pre-provisioned capabilities, performance monitoring. Components installed. RUs for specific functions. |
Resources | VNF dynamically assigned resources. | PNF statically associated (hardware) resources. |
Capacity | VNF Capacity can be dynamically changed | PNF is static (number of cells supported) |