1 Introduction
2 BBS Flows Cross Reference
3 PNF Registration Flow
4 PNF Re-registration Flow
5 DCAE
- 5.1 PNF Registration Event
  - 5.1.1 pnfRegistration Event
- 5.2 PRH Extension
  - 5.2.1 PNF Re-registration Detection
  - 5.2.2 PNF for ONT in A&AI
  - 5.2.3 PNF unauthenticated.PNF_UPDATE Event
    - 5.2.3.1 PNF Update Event
  - 5.2.4 Nomadic ONT Event/DCAE_CL_OUTPUT Event
    - 5.2.4.1 DCAE_CL_OUTPUT Event
      - 5.2.4.1.1 DCAE Control Loop Event
    - 5.2.4.2 A&AI Enrichment
6 Policy
- 6.1 Apex Engine Triggering
  - 6.1.1 PDP-A Configuration (JSON)
    - 6.1.1.1 ApexConfig.json
  - 6.1.2 NomadicONT Policy Model (WIP)
    - 6.1.2.1 NomadicONTPolicyModel.apex
  - 6.1.3 Logic Artifacts
    - 6.1.3.1 Nomadic ONT Apex Policy
  - 6.1.4 Schema
    - 6.1.4.1 Schema Aritifacts
- 6.2 Operational Policy High Level
  - 6.2.1 Operational Policy
    - 6.2.1.1 Nomadic ONT Operation Policy
  - 6.2.2 SDNC API/Recipe
    - 6.2.2.1 SDNC API for BBS Nomadic ONT
  - 6.2.3 A&AI APIs
    - 6.2.3.1 A&AI APIs Called Directly By Operational Policy
      - 6.2.3.1.1 Service Status Update
    - 6.2.3.2 A&AI APIs Called Indirectly Through SO/SDNC
      - 6.2.3.2.1 Update PNF
      - 6.2.3.2.2 Update service meta data
7 Design Time Artifacts
- 7.1 DCAE-DS
  - 7.1.1 Micro-service Blueprints
    - 7.1.1.1 MS Blueprints
- 7.2 CLAMP
  - 7.2.1 Control Loop (Micro-service) Orchestration
8 Notes:

Introduction

The PNF Registration and Re-registration Notification is generated whenever the a CPE is plugged into the network either for the first time (registration) or whenever the CPE is plugged into a different interface of an access node in the network (re-registration).

Upon reception of the notification within ONAP by a DCAE collector, the notification is mapped into a VES event and placed on the DMaaP bus for processing by the DCAE/PRH uS.

BBS Flows Cross Reference

The PNF Registration notification is used within the following use case scenarios:

PNF Registration Flow

The PNF Registration Flow is documented here for the BBS use case.

PNF Re-registration Flow

Figure 1. BBS PNF Registration and Re-registration Notification Flow Diagram

Here are the flow by steps:

10) Access SDN M&C reports the PNF registration event to DCAE/PRH

1. This notification may be sent to the Restconf VES collector for translation and mapping into the PNF registration VES event as described here.

20) DCAE/PRH then processes the PNF registration event logic where PRH determines if the event is a registration or re-registration event.

1. The determination if this event is a registration or registration is documented here.
2. If the ONT/PNF is re-registered, a PNF_UPDATE event with the additional fields from the VES registration event is produced by PRH onto DMAAP.

30) For the PNF re-registration, the BBS uS:

30.1) consumes PNF_UPDATE event from DMAAP,

30.2) looks up the service-instance-id by the pnf-name, checks PON UNI attachment point in 'additionalFields' against the attachment point in the PNF.

30.3) looks up a list of resources to be updated

30.4) triggers the Nomadic ONT policy

40) Updates the orchestration status of the CFS service instance in A&AI where an event is then emitted to indicates the resources of the service still need updated

50) SDNC API conducts the service resource re-provisioning upon the ONT location change. The PNF attachment point is updated upon successful provisioning.

60) Updates the orchestration status of the CFS service instance in A&AI where an event is then emitted to indicate the resources of the service have been updated

Note: In this release steps 40-60 implement the Steps 9 to end of the PNF re-registration event.

DCAE

PNF Registration Event

The BBS Use uses the ONAP pnfRegisration event with additional fields to identify the Access Node UNI to which the CPE is attached.

pnfRegistration Event

This pnfRegistration Event definition can be found at link:
https://wiki.onap.org/display/DW/5G+-+PNF+Plug+and+Play#id-5G-PNFPlugandPlay-STAGE3-PNFREGISTRATIONVESEVENT

The field definitions use for the BBS Use case for ONT Registration:
	eventName: pnfRegistration_<vendorName>_cpe
	eventId: unique per CPE proxied – incremented as described
	sourceName: <PNF-name/PNF correlation ID>: Format string: <Manufacturer
	OUI>-<SerialNumber> or <Manufacturer OUI>-<Model>-<SerialNumber>
	reportingEntityName:<thirdparty-sdnc-id> from esr request
	additionalFields:
		attachment-point: Format: "<oltName>/<oltSlot>/<oltPort>"  <x> denotes element
        remote-id: Format: string - This represents the Remote ID within the DHCP Option 82 (Optional)
        c-vlan: Format: int - This represents the Customer VLAN associated with the attachment point (Optional)
        s-vlan: Format: int - The represents the Service VLAN of network interface connected to the attachment point (Optional)

PRH Extension

PNF Re-registration Detection

Refer to PNF Re-registration detection logic handled in 5G use case by extension of PRH micro-service.

PNF for ONT in A&AI

Refer to ONT/PNF definition in ONT modeling.

PNF unauthenticated.PNF_UPDATE Event

This event is the output of PRH mS when it detects a PNF re-registration event. The event is consumed by the BBS mS.

PNF Update Event

{ 
 "nf-role":"role",
 "equip-type":"Equipment-Type-1",
 "equip-vendor":"Vendor",
 "equip-model":"E-model-1",
 "serial-number":"SN1234",
 "sw-version":"SW-version-1",
 "correlationId":"PNF-correlation",
   "additionalFields": {
     "attachment-point": "olt1-1-1",
     "cvlan": "1005",
     "svlan": "100",
     "remote-id": "some-remote-id"
  }
 }

Nomadic ONT Event/DCAE_CL_OUTPUT Event

This event triggers Policy engine to call SO API to modify the associated HSIA service.

DCAE_CL_OUTPUT Event

DCAE Control Loop Event

{
    "closedLoopEventClient": "DCAE.BBS_mSInstance",
    "policyVersion": "1.0.0.5",
    "policyName": "Nomadic_ONT",
    "policyScope": "service=HSIAService,type=SampleType,closedLoopControlName=CL-NomadicONT-d925ed73-8231-4d02-9545-db4e101f88f8",
    "target_type": "VM",
    "AAI": {
        "service-information.hsia-cfs-service-instance-id" : "service-instance-id-example",
		"attachmentPoint" : "olt1-1-1",
		"remoteId" : "some-remote-id",
        "cvlan" : "example cvlan-id",
        "svlan" : "example svlan-id"
    },
    "closedLoopAlarmStart": 1484677482204798,
    "closedLoopEventStatus": "ONSET",
    "closedLoopControlName": "ControlLoop-NomadicONT-fd36-4843-a71a-a8c24c70c88b",
    "version": "1.0.2",
    "target": "vserver.vserver-name",
    "requestID": "97964e10-686e-4790-8c45-bdfa61df770f",
    "from": "DCAE"
}

A&AI Enrichment

The moving ONT associated (through pnfName) service ID is looked up in A&AI and enriched in the A&AI portion of the above DCAE_CL_OUTPUT Event which trigger the operational policy in the operational policy defined below.

Policy

There are two options to author and execute the Nomadic ONT policy - Apex PDP(Pdp-A) or Drools PDP(Pdp-D).

Apex Engine Triggering

Apex PDP engine is configured to consumes the Nomadic ONT event/DCAE-CL_OUTPUT event from DMAAP and call the SDNC Rest API to take resource re-provisioning actions in the original design in Dublin. Later on, a workaround approach is taken for the BBS MS to consume the pnfUpdate event produced by PRH and eventually calls SNDC API to proceed the service associated resource re-provisioning after certain A&AI query and update. Therefore, the policy engine configuration and policy definition becomes very simple for the time being. The only reason for now to keep a no action policy is for the completeness of the control loop so that to the BBS workflow it is actually an open loop so that a CL can be defined and managed by CLAMP through which DCAE micro-services, such as, Restconf Collector, VES Mapper, PRH as well as the BBS MS can be orchestrated centralized.

PDP-A Configuration (JSON)

Simplified Apex Configuration:

ApexConfig.json

Apex Policy for Nomadic ONT is created as following. It can be on-board as part of the service Tosca module at design time, distributed to an Apex PDP engine by the policy distribution engine through SDC.

NomadicONT Policy Model (WIP)

This is the Apex Policy state machine for Nomadic ONT. An open loop operational policy is going to be defined here to support the completeness of control loop in BBS use case in Dublin.

NomadicONTPolicyModel.apex

Logic Artifacts

Nomadic ONT Apex Policy

Schema

Schema Aritifacts

Operational Policy High Level

Operational Policy

A simple open loop operation policy to support the completeness of BBS control loop.

Nomadic ONT Operation Policy

SDNC API/Recipe

SDNC API for BBS Nomadic ONT

A&AI APIs

A&AI APIs Called Directly By Operational Policy

API for updating the service-instance is the same as before and only this one need to be called twice during ONT Relocation Policy execution.

Service Status Update

A&AI APIs Called Indirectly Through SO/SDNC

To update the attachment point of the PNF, when the old logical-link object is deleted, it should be automatically removed from the pnf relationship-list, then create a new logical-link object and PUT it into the pnf relationship-list, e.g. as the following

Update PNF

To update the metadata on the service-instance, use the PUT on the metadatum objects. If there are new objects, then add them to the relationship-list on the cp/pnf/generic-vnf, etc, e.g. as the following

Update service meta data

Design Time Artifacts

DCAE-DS

Micro-service Blueprints

MS Blueprints

CLAMP

Control Loop (Micro-service) Orchestration

There are basically 2 ways of CL creation and micro-service orchestration in BBS Nomadic ONT scenario.

Restconf collector + VES Mapper + PRH + Policy Engine
VES Collector + PRH + Policy Engine

Notes:

Interestingly, this is the first case where DCAE/Policy seem playing roles together in a non-closed/loop or service assurance in sense of usage/solution in ONAP domain, However, this does not really matter in the sense of micro services since service is a service as long as it provides the functionality that meets the requirements in a solution, An argument could be that Policy engine does not have to be introduced in this case, However, the important functionality for policy engine is to decouple action takers from the trigger pullers and ultimately establish robust policy driving on this platform w/o code change.