1. Background
CMNotify is a RESTFUL notification that supports the 3GPP fields defined for sending notifications when managed objects are created, deleted or modified. Any configuration changes (such as, neighbor list change) in the underlying RAN network will be communicated via CM REST notifications, and will trigger any follow-on activities, such as closed-loop automation (e.g. SON use cases). This is a POC effort to demonstrate how CM Notification could be supported in ONAP.
2. High-Level Architecture and Use Cases
Please refer to the presentation for detailed architecture considerations for CM Notification support. The below picture depicts the workflow for this POC effort.
The workflow for POC effort:
3a: Publish CM Notification DMAAP message that includes relevant VES payload. For testing, DMAAP message will be published via Postman or CURL, onto CM-NOTIFICATION topic
4a: SDNR to consume DMAAP message, and trigger pertinent DG to update RuntimeDB/ConfigDB platform
4b: Update RuntimeDB/ConfigDB using REST API
3. VES Message Format
This POC does not use VES messages, but would leverage the configuration change payload that should be included in the VES message notificationFields. This POC assumes that appropriate DMAAP message will be published by relevant ONAP components (VES Collector/DCAE) that will include the configuration change payload. It is also expected that payload aligns with the YANG model defined for respective notifications.
For this POC, following VES message is assumed, and also includes configuration change payload (neighbor list change) highlighted in YELLOW below.
{ "event": { "commonEventHeader": { "version": "4.0.1", "vesEventListenerVersion": "7.0.1", "domain": "notification", "eventName": "Notif_RansimAgent-Wipro_RanPCIProblem", "eventId": "Notif000001", "sequence": 1, "priority": "High", "reportingEntityId": "de305d54-75b4-431b-adb2-eb6b9e546014", "reportingEntityName": "ncserver1", "sourceId": "cc305d54-75b4-431b-adb2-eb6b9e541234", "sourceName": "Chn0001", "startEpochMicrosec": 1451772223000000, "lastEpochMicrosec": 1451772403000000, "timeZoneOffset": "UTC-05:30", "nfNamingCode": "RansimAgent", "nfVendorName": "Wipro" }, "notificationFields": { "notificationFieldsVersion": "2.0", "changeType": "Neighbour list changed", "changeIdentifier": "ncserver1", "additionalFields": { "networkId": "NTWK005", "configurationChange": "{ \"fap-service-number-of-entries-changed\":1, \"fap-service\":[ { \"alias\":\"Chn0001\", \"cid\":\"Chn0001\", \"lte-cell-number-of-entries\":1, \"lte-ran-neighbor-list-in-use-lte-cell-changed\":[ { \"plmnid\":\"ran-1\", \"cid\":\"Chn0002\", \"phy-cell-id\":4, \"pnf-name\":\"ncserver1\", \"blacklisted\":false } ] } ] }" } } } } |
|---|
4. North-bound RPC YANG Model
The YANG model to support CM Notification for neighbor list change can be found at: https://gerrit.onap.org/r/gitweb?p=ccsdk/features.git;a=blob;f=sdnr/northbound/CMNotify/model/src/main/yang/CM-NOTIFY-API.yang;h=834dc71ec77d8aea450e389e77016e6f9a97fdd2;hb=refs/heads/master
The YANG tree is below, and it is expected that any configuration change payload in the DMAAP message aligns with this YANG model for efficient end to end system engineering.
module: CM-NOTIFY-API rpcs: |
|---|
5. DMAAP Message Format
DMAAP Message from VES Collector/DCAE or pertinent Micro Service to SDNR Indicating configuration change and the need to update RuntimeDB
Topic: CM-NOTIFICATION { |
|---|
Please note that YANG model for RPC is aligned with the payload included in the DMAAP message.