Table of Contents | ||
---|---|---|
|
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 and Re-registration Flow
Gliffy Diagram | ||||
---|---|---|---|---|
|
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
- 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.
- The determination if this event is a registration or registration for starts of if the PNF has already registered with ONAP. If so the UpdateServiceMSvc is invoked.
30) For
the
PNF
re-registration,
the
UpdateServiceMSvc
invokes
a
policy
to
update
the
services
associated
with
the
PNF and issues a pnfUpdate event to the SOPNF
40) Ultimately the UpdateServiceMSvc issues a pnfUpdate event to the SO
50) SO pnfUpdate API initiates the service re-provisioning procedure per ONT location change.
DCAE
PNF Registration Event
VES Mapper converts the ONT Registration notification JSON message from DMAAP into the following PNF Registration event.
Code Block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
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: oltName: <OLT name> oltPONSlot: <OLT PON Slot> oltPONPort: <OLT PON Port> |
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 pnfUpdate Event
This event is the output of PRH active service detection and is consumed by BBS MS.
Code Block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
Nomadic ONT Event/DCAE_CL_OUTPUT Event (WIP)
This event triggers Policy engine to call SO API to modify the associated HSIA service.
DCAE_CL_OUTPUT Event
Code Block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
{ "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.service-instance-id" : "service-instance-id-example", "pnf.ontSN" : "ontSN-example" //...what ever this is }, "closedLoopAlarmStart": 1484677482204798, "closedLoopEventStatus": "ONSET", "closedLoopControlName": "ControlLoop-BBS-2179b738-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.
Update Service Micro-service
A new micro-service, ONAP Micro-Service or ONAP SM SDK, that handles RG Online (or activation) notification will be introduced to consume a new type of VES event. This event is converted from RG Activation notification by VES Mapper.
The characters of this generic micro- service could be the following:
- hold a set of REST APIs
- consume VES events from DMAAP and the consumed event types will be configurable at both the design time and run time
- publish VES events to DMAAP and the published event types will be configurable at both the design time and run time
- run A&AI query A&AI enrichment logic
The Update Service MS could be built on top of DCAE service SDK ( https://gerrit.onap.org/r/#/admin/projects/dcaegen2/services/sdk - R4). A MS blueprint is defined at DCAE-DS and this service can be deployed from CLAMP or can be instantiated as a standalone container when DCAE is deployed.
Both pnfUpdate and CPE Authentication events will be consumed by this micro-service. HSIA re-provisioning action is triggered through Policy executing Nomadic ONT operational policy, while CPE Authentication event triggers HSIA service update by marking it as activated.
RG Activation(CPE Authentication) Event
This event is converted from the RG Activation notification by VES Mapper. Upon receiving this event UpdateService MS will look up for the associated HSIA service and trigger Policy engine to mark (calling SO API?) the service as activated.
Example in VES StateChange domain
The CPE Authentication Event is defined here in VES StateChange domain. It indicates if the ONT/CPE is successfully authenticated at the Edge after the ONT/CPE relocation is completed.
Policy
Apex Engine Triggering
PDP-A Configuration (JSON)
Code Block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
Policy Schema
Logic Artifacts
Pdp-D Option
Operational Policy
Code Block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
ontrolLoop: version: 2.0.0 controlLoopName: ControlLoop-BBS-2179b738-fd36-4843-a71a-a8c24c70c88b trigger_policy: unique-policy-id-16-ServiceModify timeout: 3600 abatement: false policies: - id: unique-policy-id-16-ServiceModify name: Connectivity Reroute description: actor: SO recipe: serviceModification target: type: VM retry: 3 timeout: 1200 success: final_success failure: final_failure failure_timeout: final_failure_timeout failure_retries: final_failure_retries failure_exception: final_failure_exception failure_guard: final_failure_guard |
SO Recipe
Design Time
DCAE-DS
Micro-service Blueprints
Code Block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
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.