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) in the notificationFields 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.


+---x nbrlist-change-notification
+---w input
| +---w fap-service-number-of-entries-changed? uint64
| +---w fap-service* [alias]
| +---w alias string
| +---w cid? string
| +---w phy-cell-id-in-use? uint64
| +---w pnf-name? string
| +---w lte-cell-number-of-entries? uint64
| +---w lte-ran-neighbor-list-in-use-lte-cell-changed* [plmnid cid]
| +---w plmnid string
| +---w cid string
| +---w phy-cell-id? uint64
| +---w pnf-name? string
| +---w blacklisted? boolean
+--ro output
+--ro response-code? string
+--ro response-message? string

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


"body": {
"input": {
"CommonHeader": {
"TimeStamp": "2018-11-30T09:13:37.368Z",
"APIver": "1.0",
"RequestID": "9d2d790e-a5f0-11e8-98d0-529269fb1459",
"SubRequestID": "1",
"RequestTrack": {},
"Flags": {}
"Action": "nbrlist-change-notification",
"Payload": { "fap-service-number-of-entries-changed": 1, "fap-service": [{ "alias": "Chn0000", "cid": "Chn0000", "lte-cell-number-of-entries": 1, "lte-ran-neighbor-list-in-use-lte-cell-changed": [{ "plmnid": "ran-1", "cid": "Chn0001", "phy-cell-id": 1, "pnf-name": "ncserver1", "blacklisted": true }] }] }
"version": "1.0",
"rpc-name": "nbrlist-change-notification",
"correlation-id": "9d2d790e-a5f0-11e8-98d0-529269fb1459-1",
"type": "request"

Please note that YANG model for RPC is aligned with the payload included in the DMAAP message.

6. RuntimeDB/ConfigDB API Interaction

The current ConfigDB implementation code can be found in the github: https://github.com/onap-oof-pci-poc/sdnc/tree/master/ConfigDB/Dublin

Swagger JSON API documentation can be found at: https://github.com/onap-oof-pci-poc/sdnc/blob/master/ConfigDB/Dublin/SDNC_ConfigDB_API_v3.0.0.json

The current ConfigDB implementation is deployed in the WIndriver labs in the VM (, and can be accessed via URL

The ConfigDB API relevant for this POC is for adding neighbor to a cell. API will be invoked by a DG using REST API adapter plugin.

API URL: PUT /api/sdnc-config-db/v3/createNbr/{cellId}

API Payload: 

"ho": true,
"targetCellId": "string"

The CURL for this API is below

curl --location --request PUT '' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--header 'Cache-Control: no-cache' \
--header 'Content-Type: text/plain' \
--data-raw '{
"ho": true,
"targetCellId": "Chn0001"

7. Deployment Considerations

9. CM Notification Testing

10. To Do's

11. Supporting Documents

  • No labels