Content Comparison

...

#	Issue	Notes	Decision
1	List scenarios	Need to clarify scenarios	Refer to Internal study
2	Topics	what topics are used in what scenario (topic for each Datastore ?)	See Topics section below. All NCMP notifications to be published on the public cm-events topic by default regardless of data type, notification type or datastore the change came from. This topics acts as the TBAC_ALL topic. cm-events topic name should be configurable in deployment settings. Future : In future NCMP shall publish the notification based on TBAC where the notification is published on the appropriate target group topic cm-events[-<target-group-name>] matching the target group(s) the data type(s) is associated with. Not in scope of this story.
3	Handle unknown event schemas	Wrap event?	Unsupported for now. Thrown exception and log error.
4	Event Flow Overview (Flow 1 and 2 )	We will need for ONAP specific solution for that and we need to check with E2E Slicing Team on how the DMI would receive the Network Changle Cm Notification ( via message bus or something else ) , how will it look.. etc etc. We have add/remove and attribute-value changes(AVCs) . A&AI supports add/remove part. Need to check for AVCs.
5	CM Avc Subscriptions Event Structure	Cm Subscription Event schema is been dictated by ORAN-DME (onap component which dictates event schema) so NCMP shall adhere to the schema.	We have to make up something similar( since this schema may/ may not be ready yet ) and check with Kieran on details here.
6	E2E Slicing needs to persist the data	We need to check if we need to persist the data in flow-point #5 (Also depends on question #4)
7	Scope of the notifications ?	Need to check if these are only AVCs ( as the schema name suggests) Or CRUD or both.

Event Flow Overview

CM Event Specification Outline

...

Operation	Description
create	create a new data resource if it does not already exist. If it already exists, return an error
delete	delete a data resource if it already exists. If it does not exists, return an error
insert	Delete Insert a new user-ordered data resource if it already exists. If it does not exists,
merge	Merge the edit value with the target data resource; create if it does not already exist
move	Reorder the target data resource
replace	Replace the target data resource with the edit value
remove	Remove a data resource if it already exists

...

Code Block

language	xml
title	Proposed CM Event (paylaod example)
collapse	true

{
  "eventId"                : "9999",                                         # some generic event uuid generated by DMI Plugin
  “eventCorrelationId”     : “cmhandleId-001”,                               # cmhandleId used for event correlation
  "eventTime"              : "2021-11-16T16:42:25-04:00",
  "eventSource"            : "ncmp-datastore:passthrough-operational",       # eventSource always specifies the datastore where the event is emanating from                                      
  "eventType"              : "org.onap.ncmp.cm-network-avc-event",           # event type 
  ”eventSchema”            : “org.onap.ncmp:cm-network-avc-event.rfc8641",   # event schema   
  ”eventSchemaVersion”     : “1.0",                                          # event schema version

  "event": {

"push-change-update" : {
    "datastore-changes" : {
      "ietf-yang-patch:yang-patch" : {
          "patch-id" : "34534ffd98",  # Some unreadable patch id generated by the machine 
          "edit" : [
               {
                  "edit-id" : "ded43434-1",
                  "operation" : "create",
                   "target" : "/_3gpp-common-managed-element:ManagedElement=Kista-001/_3gpp-nr-nrm-gnbdufunction:GNBDUFunction=1/_3gpp-nr-nrm-nrcelldu:NRCellDU=1",
                   "value" : {
                          "_3gpp-nr-nrm-nrcelldu:NRCellDU" :  [
                               {
                                 "id" : 1,
                              }
                           ]
                      }
              },

               {
                  "edit-id" : "ded43434-1-1",
                  "operation" : "create",
                   "target" : "/_3gpp-common-managed-element:ManagedElement=Kista-001/_3gpp-nr-nrm-gnbdufunction:GNBDUFunction=1/_3gpp-nr-nrm-nrcelldu:NRCellDU=1/attributes",
                   "value" : {
                          "attributes" :  {
                                  "cId" : 511,
                                  "userLabel" : "some-cell-label",
                                  ...
                              }
                      }
              },


              {
                  "edit-id" : "ded43434-2",
                  "operation" : "create",
                   "target" : "/_3gpp-common-managed-element:ManagedElement=Kista-001/_3gpp-nr-nrm-gnbdufunction:GNBDUFunction=1/_3gpp-nr-nrm-nrcelldu:NRCellDU=1/attributes/pLMNIdList=35301",
                   "value" : {
                         "_3gpp-nr-nrm-nrcelldu:pLMNIdList" : [
                               {
                                      "mcc" : 353,
                                      "mnc" : "01",
                                      ...

                                 }

                              }
                         ]
                      }
              },
              {
                  "edit-id"   : "ded43434-3",
                  "operation" : "merge",
                   "target" : "/_3gpp-common-managed-element:ManagedElement=Kista-001/_3gpp-nr-nrm-gnbdufunction:GNBDUFunction=1/_3gpp-nr-nrm-nrcelldu:NRCellDU=3/attributes",
                   "value" : {
                         "attributes" : 
                               {               
                                  "cId" : 412,
                                  "userLabel" : "yet-another-cell-label",
                                   ...
                              }
                    }
              },
              {
                  "edit-id" : "ded43434-4",
                  "operation" : "delete",
                   "target" : "/_3gpp-common-managed-element:ManagedElement=Kista-001/_3gpp-nr-nrm-gnbdufunction:GNBDUFunction=1/_3gpp-nr-nrm-nrcelldu:NRCellDU=4"
            }
        ]
     }
   }
 }

    }
}

...

CM AVC Event

...

Subscriptions

A client app may subscribe on change notification on different datastores. From a client app perspective each client subscription will be treated independently BUT internally the subscriptions will be merged and published on one or more collective CM topics based on target groups. The CM ALL target group is the default and ALL CM notifications are directed to the associated cm-events topic.
iiiimmmm

...

Subscription

...

The Create Subscription flow is as follows :

Image Removed

...

Steps

...

NCMP is configured at startup with the cm subscription topic information (cm topic name, kafka addressing info).

Some app sends a 'CreateSubscription' event to the public cm subscription topic (cm-event-subscription).

Usecase

Participants

Schema

Example

Create Subscription

client app → ncmp

Protocol : Kafka Event
Topic : cm-avc-subscription

Code Block

language	xml
title	Event Schema
collapse	true

{
  "version": "<event type version>",
  "eventType": "subscriptionCreated",
  "event": {
    "subscription": {
      "clientID": "<unique identifier for the client >",
      "name": "<unique subscription name per client>",
      "isTagged": "<yes|no>, optional parameter, default is no"
    },
    "dataType": {
      "dataspace": "<data space>",
      "dataCategory": "<data category type>",
      "dataProvider": "<data provider type>"
      "schemaName": "<schema name>"
      "schemaVersion": "<schema version>"
    },
    "predicates": {
      "<parameter>": "<value>",
      "param2": [
        "value21",
        "value22"
      ]

    }
  }
}

Code Block

language	xml
title	Create Example
collapse	true

{
  "version": "1.0",
  "eventType": "subscriptionCreated",
  "event": {
    "subscription": {
      "clientID": "SCO-9989752",
      "name": "cm-subscription-001"
    },
    "dataType": {
      "dataspace": "ALL",
      "dataCategory": "CM",
      "dataProvider": "CM-SERVICE"
      "schemaName": "org.onap.ncmp:cm-network-avc-event.rfc8641"
      "schemaVersion": "1.0"
    },
    "predicates": {
        "datastore": “passthrough-operational",
        "datastore-xpath-filter": "//_3gpp-nr-nrm-gnbdufunction:GNBDUFunction/ 
             _3gpp-nr-nrm-nrcelldu:NRCellDU/ | //_3gpp-nr-nrm-gnbcuupfunction:GNBCUUPFunction// |
            //_3gpp-nr-nrm-gnbcucpfunction:GNBCUCPFunction/_3gpp-nr-nrm-nrcelldu:NRCellCU// |
            //_3gpp-nr-nrm-nrsectorcarrier:NRSectorCarrier//”  

    }
  }
}

Table 1 : Create Subscription request from App

NCMP receives consumes the create cm subscription event and processes it as follows :
1. Persist the subscription and cm-subscription-filter information to db
2. Read all CM handles that match the cm-filter-subscription (model matching, cmhandleId matching)
3. If a subscription is already ongoing for the same cmhandle datastore then separate them from the list for later processing (after the existing ongoing cmhandle subscription has completed - See table 3 below, administrativeState : running->active).
  Use the administrativeState of cmhandle 'subscriptions' as shown in table 3 below. This can be used to know if a cmhandle subscription update is ongoing.
4. Merge the existing cmhandle filter (if one exists from a previous subscription) with the new cm-filter-subscription
5. Record the cmhandles whose existing cm subscription filter has been modified after filter merging in step c)
For the cmhandle(s) with a new or modified subscription filter, group them according to their controlling dmi-plugin and send one or more bulk subscription request(s) to the appropriate dmi-plugin(s).
- Change the subscription administrativeState to 'updating' for the associated datastore. Do not modify the other subscription attributes (e.g. datastore-xpath-filter) until after successful response received from dmi.
- send the a bulk subscription REST request to each dmi-plugin containing either a 'create' (where no previous subscription exists on the cmhandle) or an 'update' subscription info for each cmhandle as per table 2 below
- the REST request to the dmi-plugin is asynchronous. The dmi-plugin shall process the each of the subscription requests per cmhandle and send an event response on the dmi-cm-avc-subscription-events topic for each cmhandle.

...

Usecase participants Request Schema / Example NCMP Updates

Notify of create subscription request success
on passthrough-operational datastore -
success case

dmi → ncmp

Protocol : Kafka Event
Topic : dmi-cm-avc-subscription

Code Block

collapse
language	xml
title	dmi-cm-avc-subscription schema

true



  "eventId"

:

               : "00001",   (M)


  "eventCorrelationId     : "cmhandle-001" (M)


  "eventTime"

 "2021-11-16T16:42:25-04:00",                          (M)


  "eventSource"

:

  : "ncmp-datastore:passthrough-operational",             (M)

"eventType"

 "org.onap.ncmp:cm-avc-subscription-event.response",   (M)

”eventSchema” :


  ”eventSchema”           : “org.onap.ncmp:cm-avc-subscription-event",            (M)


  "eventSchemaVersion"

 "1.0"

(M)


  "event":

{
“cmHandleId” : “cmhandle-001”

 {
         “cmHandleId”                     : “cmhandle-001”,(M)


         "subscriptionResponse"

: {                         (M)


             "subscriptionType"           : "created",     (M)

“subscriptionRequestStatus” :


             “subscriptionRequestStatus”  : “success”,     (O)

“subscriptionId” : “cc77765sddf”, (O - Mandatory if


             “subscriptionId”             : “cc77765sddf”, (O - Mandatory if subscriptionRequestStatus=success)


             "predicates" : {


                 "datastore" : "passthrough-operational",


                 "datastore-xpath-filter" : ""

NCMP register the new cmhandle subscription data.

Store the datastore subscription data in the cmhandle. Also store the administrativeState that may be used to prevent race conditions between parallel subscriptions being applied.

Code Block

language	xml
title	cmhandle data in NCMP DB
collapse	true


     "cmhandleId" : <cmhandle-id>



     "subscriptions" :  {


          "operational" : {    # 'local' ncmp subscription is required with the cmhandle - store separately?


                 "administrativeState" : "active",


                 "datastore-xpath-filter" : <xpath-filter>

},



          "running" : {   # 'local' ncmp subscription is required with the cmhandle - store subId separately?


                 "administrativeState" : "active",


                 "datastore-xpath-filter" : <xpath-filter>

},



          "passthrough-operational" : {


                 "administrativeState" : "updating",   # if 'updating' then block/queue new sub's until 'active'


                 "subscriptionId" : "cc77765sddf",


                 "datastore-xpath-filter" : <xpath-filter>

},



          "passthrough-running" : {


                 "administrativeState" : "active",


                 "subscriptionId" : <sub-id-of-device">,


                 "datastore-xpath-filter" : <xpath-filter>

Once NCMP receives the subscription response if shall update the cmhandle subscription state attributes as described in step 7.

Notify of modify subscription request success
on passthrough-operational datastore -
success case

dmi → ncmp

{

"eventId" :

Protocol : Kafka Event
Topic : dmi-cm-avc-subscription-events

Code Block

language	xml
title	dmi-cm-avc-subscription-events schema
collapse	true

{

  "eventId"               : "00001",   (M)


  "eventCorrelationId     : "cmhandle-001" (M)

"eventTime"

:

    : "2021-11-16T16:42:25-04:00",                          (M)


  "eventSource"

:

  : "ncmp-datastore:passthrough-operational",             (M)

     
  "eventType"

:

  : "org.onap.ncmp:cm-avc-subscription-event.response",   (M)

”eventSchema” :


  ”eventSchema”           : “org.onap.ncmp:cm-avc-subscription-event",            (M)


  "eventSchemaVersion"

 "1.0"

(M)


  "event":

{
“cmHandleId” : “cmhandle-001”

 {
         “cmHandleId”                     : “cmhandle-001”,(M)


         "subscriptionResponse" : {                         (M)


             "subscriptionType"           : "modify",     (M)

“subscriptionRequestStatus” :


             “subscriptionRequestStatus”  : “success”,     (O)

“subscriptionId” : “cc77765sddf”, (O - Mandatory if


             “subscriptionId”             : “cc77765sddf”, (O - Mandatory if subscriptionRequestStatus=success)


             "predicates" : {


                 "datastore" : "passthrough-operational",


                 "datastore-xpath-filter" : "....."

Table 3. DMI plugin sends Subscription Response to NCMPto NCMP

Create Subscription

Detailed flow Create Subscription

Image Added

Queued Subscriptions

Any cmhandle subscription requests that were queued during an ongoing subscription request on the same datastore shall be processed once the previous subscription has completed (cmhandle.subscriptions.<datastore>.administrativeState goes to active).
The cmhandle subscription filters will need to be re-merged with the newly registered cmhandle subscription filters before being applied to the appropriate datastore.

Update Subscription

Update is quite similar to the create case above. The only difference is the eventType = subscriptionUpdated

Usecase

Participants

Subscription Schema

Subscription Updated Example

Modify Subscription

client app → ncmp

Protocol : Kafka Event
Topic : cm-avc-subscription

Code Block

language	xml
title	cm-avc-subscription schema
collapse	true


  "version": "<event type version>",


  "eventType": "subscriptionUpdated",


  "event": {


    "subscription": {


      "clientID": "<unique identifier for the client >",


      "name": "<unique subscription name per client>",


      "isTagged": "<yes|no>, optional parameter, default is no"

},


    "dataType": {


      "dataspace": "<data space>",


      "dataCategory": "<data category type>",


      "dataProvider": "<data provider type>"


      "schemaName": "<schema name>"


      "schemaVersion": "<schema version>"

},


    "predicates": {


      "<parameter>": "<value>",


      "param2": [


        "value21",


        "value22"

}{

Code Block

language	xml
title	Subscription Updated Example
collapse	true

{
  "version": "1.0",


  "eventType": "subscriptionUpdated",


  "event": {


    "subscription": {


      "clientID": "SCO-9989752",


      "name": "cm-subscription-001"

},


    "dataType": {


      "dataspace": "ALL",


      "dataCategory": "CM",


      "dataProvider": "CM-SERVICE"


      "schemaName": "org.onap.ncmp.cm-notification-event"


      "schemaVersion": "1.0"

},


    "predicates": {


        "datastore": “passthrough-operational",


        "datastore-xpath-filter": "//_3gpp-nr-nrm-gnbdufunction:GNBDUFunction/


             _3gpp-nr-nrm-nrcelldu:NRCellDU/ | //_3gpp-nr-nrm-gnbcuupfunction:GNBCUUPFunction// |


            //_3gpp-nr-nrm-gnbcucpfunction:GNBCUCPFunction/_3gpp-nr-nrm-nrcelldu:NRCellCU// |


            //_3gpp-nr-nrm-nrsectorcarrier:NRSectorCarrier//”

Table 4 Update Subscription request from client app

...

See below Request example showing the update-delete example (in green bold)

Usecase

Participants

Request Schema

Request Example

Register Subscriptions

ncmp → dmi

Protocol : REST
Method : POST
URI : /ncmpInventory/v1/subscriptions
Async : true

Request Body:

{

Code Block

language	xml
title	Request Body
collapse	true

{
  "subscriptions" : [


          "cmhandleId" : "<cmhandle-id>",


          "subscriptionType": "subscriptionCreated | subscriptionUpdated | subscriptionDeleted",


          "existingSubscriptionId" : "<existing subscription-id on remote device>,


                                                      optional, required for subscriptionUpdated | subscriptionDeleted",


          "schemaName": "<schema name>, default is org.onap.ncmp.cm-notification-event",


          "schemaVersion": "<schema version>, default is latest",


          "isTagged": "<yes|no>, optional parameter, default is no",


          "predicates": {


               "<parameter>": "<value>",


               "param2": [


                      "value21",


                      "value22"

},


          "cmhandleProperties"  : [


                  <all-cmhandle-properties-as-per-normal-crud-request>

Response :

202 Accepted

{ }

Protocol : REST
Method : POST
URI : /ncmpInventory/v1/subscriptions
Async : true

Code Block

language	xml
title	Request

Body

:


collapse	true


  "subscriptions" : [


          "cmhandleId" : "e34553",              (M)


          "subscriptionType": "create",        (M)


          "schemaName": "org.onap.ncmp:cm-network-avc-event.rfc8641",    (O)


          "schemaVersion": "1.0"    (O)


          "isTagged": "yes",             (O)


          "predicates"  :   {              (O)


                "datastore": “passthrough-operational",  (O)


                "datastore-xpath-filter": "//_3gpp-nr-nrm-gnbdufunction:GNBDUFunction/


                       _3gpp-nr-nrm-nrcelldu:NRCellDU/ | //_3gpp-nr-nrm-gnbcuupfunction:GNBCUUPFunction// |


                      //_3gpp-nr-nrm-gnbcucpfunction:GNBCUCPFunction/_3gpp-nr-nrm-nrcelldu:NRCellCU// |


                     //_3gpp-nr-nrm-nrsectorcarrier:NRSectorCarrier//”

},


          "cmhandleProperties"  : [          (M)


                  <all the cmhandle properties>

},


          "cmhandleId" : "gg8769",             (M)


          "subscriptionType": "update",        (M)


          "existingSubscriptionId" : "6738462g3494hw9",   (O)


          "schemaName": "org.onap.ncmp:cm-network-avc-event.rfc8641",    (O)


          "schemaVersion": "1.0"    (O)


          "isTagged": "yes",             (O)


          "predicates"  :   {              (O)


                "datastore": “passthrough-operational",  (O)


                "datastore-xpath-filter" : "//_3gpp-nr-nrm-gnbdufunction:GNBDUFunction/


                       _3gpp-nr-nrm-nrcelldu:NRCellDU/ | //_3gpp-nr-nrm-gnbcuupfunction:GNBCUUPFunction// |


                      //_3gpp-nr-nrm-gnbcucpfunction:GNBCUCPFunction/_3gpp-nr-nrm-nrcelldu:NRCellCU// |


                     //_3gpp-nr-nrm-nrsectorcarrier:NRSectorCarrier//”

},


          "cmhandleProperties"  : [          (M)


                  <all the cmhandle properties>

},


          "cmhandleId" : "ff56743",             (M)


          "subscriptionType": "delete",    (M)


          "subscriptionId" : "6738462g3494hw9",   (O but must be set for update or delete subscriptionType)


          "cmhandleProperties"  : [            (M)


                  <all the cmhandle properties>

Response :

202 Accepted

{ }

CM AVC Subscription Response - delete dmi subscription case

Usecase participants Request Schema / Example NCMP Updates

Notify of delete subscription request success
on passthrough-operational datastore -
success case

dmi → ncmp

:

Protocol : Kafka Event
Topic : dmi-cm-avc-subscription

{

"eventId"

Code Block

language	xml
title	Schema
collapse	true

{

  "eventId"               : "00001",   (M)


  "eventCorrelationId     : "ff56743" (M)

"eventTime"

 "2021-11-16T16:42:25-04:00",                          (M)


  "eventSource"

:

: "ncmp-datastore:passthrough-operational",             (M)

"eventType"

 "org.onap.ncmp:cm-avc-subscription-event.response",   (M)

”eventSchema” :


  ”eventSchema”           : “org.onap.ncmp:cm-avc-subscription-event",            (M)


  "eventSchemaVersion"

 "1.0"

(M)


  "event":

{
“cmHandleId” : “ff56743”,(M)
"subscriptionResponse" : { (M)
"subscriptionType" :

 {
         “cmHandleId”                     : “ff56743”,     (M)
         "subscriptionResponse"           : {              (M)
             "subscriptionType"           : "delete",      (M)

“subscriptionRequestStatus” :


             “subscriptionRequestStatus”  : “success”,     (O)

“subscriptionId” : “cc77765sddf”, (O - Mandatory if


             “subscriptionId”             : “cc77765sddf”, (O - Mandatory if subscriptionRequestStatus=success)

NCMP register the new cmhandle subscription data.

Store the datastore subscription data in the cmhandle. Also store the administrativeState that may be used to prevent race conditions between parallel subscriptions being applied.

cmhandle data

Code Block

language	xml
title	CmHandle Data in NCMP DB
collapse	true

"cmhandleId" : <cmhandle-id>


     "subscriptions" :  {


          "operational" : {    # 'local' ncmp subscription is required with the cmhandle - store separately?


                 "administrativeState" : "active",


                 "datastore-xpath-filter" : <xpath-filter>

},


          "running" : {   # 'local' ncmp subscription is required with the cmhandle - store subId separately?


                 "administrativeState" : "active",


                 "datastore-xpath-filter" : <xpath-filter>

},


          "passthrough-operational" : {


                 "administrativeState" : "running"             →   'inactive'


                 "subscriptionId" : "cc77765sddf",          →   remove or set to ""


                 "datastore-xpath-filter" : <xpath-filter>  →  remove or set to ""

},


          "passthrough-running" : {


                 "administrativeState" : "active",


                 "subscriptionId" : <sub-id-of-device">,


                 "datastore-xpath-filter" : <xpath-filter>

Once NCMP receives the subscription response if shall update the cmhandle subscription state attributes as described in step 7.

Topics

Topic types

Topic Name	Description	Direction
cm-avc[-<targetgroup>]	topic for publication of events from NCMP to clients (suggest to rename existing topic from 'ncmp-events' to cm-avc). In preparation to future needs the there may be separate topics for different security groups. NCMP solution should consider this in its design this upfront. By default cm-avc is the default topic where ALL events are published by default. Different client may subscribe to different topics (ALL and/or target group specific). It is their responsibility to subscribe to the appropriate topics as new target groups come into existance. For now the only topic in scope of this story is the 'cm-avc' topic.	ncmp → client consumer
dmi-cm-events	internal topic for communications between dmi-plugin ↔ ncmp for avc and subscription events	ncmp→ dmi
cm-avc-subscription	topic for avc event subscriptions. This topic may be (pre)defined external to NCMP. If externally defined topic then it shall be possible to tell NCMP the topic name and where to find it.	client → ncmp
dmi-cm-avc-subscription	topic for avc event subscriptions event toward dmi plugin(s). This topic is internally defined by NCMP. All CM AVC subscriptions will be sent from NCMP to DMI plugins via this topic.	ncmp → dmi for subscription LCM dmi → ncmp register device subscription in cmhandle

...

Topic partitioning

All events for the same cmhandleId should be sent to the same partition. This will guarantee ordering. Ordering is only guaranteed per topic, not across topic (future consideration).

DataBase Design

...

, Subscription and Filter Tables

The client subscriptions may be stored in a simple Subscriptions table.

...

CmHandle related tables in the DB will be updated to store the subscription state for the appropriate cmhandle datastores

Subscription Data

Data similar to the below needs to be reflected in the related cmhandle data model

...

Version	Old Version 33	New Version Current
Changes made by	Priyank Maheshwari	Priyank Maheshwari
Saved on	Aug 10, 2022	Nov 22, 2022

Versions Compared

Key

Event Flow Overview

CM Event Specification Outline

CM AVC Event

Subscriptions

Subscription

Steps

Create Subscription

Queued Subscriptions

Update Subscription

CM AVC Subscription Response - delete dmi subscription case

Topics

Topic types

Topic partitioning

DataBase Design

, Subscription and Filter Tables

Subscription Data