Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Issues & Decisions

#IssueNotes Decision
1Possible 'timeframe' period for timeoutDMI to NCMP response timeout

30 sec (Configurable param/property)

2Response in two steps or in a single step should be discussed with shareholders.from DMI to NCMP responses

Is the ACK would be required? No

DMI-Plugin would publish actual response to NCMP

3Response schema should be decided

from DMI to NCMP response schemas should be decided for both two steps response and single step response

Should DMI Plugins detail cm-hande IDs in response?

Accept or Decline


4Subscription event outcome schema should be decided

from DMI to Client Apps

  • Possible options for initial response and further updates
    1. Status only: COMPLETED / PARTIALLY_COMPLETED
    2. Status and % -completed based on # Participating DMI-plugins
    3. Status and %-completed based on #cm-handle-ids  registered (and participating) per Plugin
    4. Status and list of m-handle ids for which NCMP got a response

We include : 

Initial Response : 

  1. Status only: COMPLETED / PARTIALLY_COMPLETED 
  2. Pending cm handle ids for PARTIALLY_COMPLETED or Empty in case of COMPLETED.
  3. List of declined cm handles
  4. Un-registerred cm handles list


Update Responses that comes after timeframe (30 sec) : 

  1. Status only: COMPLETED / PARTIALLY_COMPLETED 
  2. Pending cm handle ids for PARTIALLY_COMPLETED or Empty in case of COMPLETED.
  3. List of declined cm handles

Note : Avoid for wild card * (for all cm handles)

...

#SourceContentTopic NameDestination
1Client AppsSubscription Create Eventcm-avc-subscriptionNCMP
2NCMPForwarded Subscription Create Event

ncmp-dmi-cm-avc-subscription-{DMI-DATA-SERVICE-NAME}


DMI Plugins

3DMI PluginsForwarded Subscription Create Event Responsedmi-ncmp-cm-avc-subscriptionNCMP
4NCMPSubscription Create Event Outcomecm-avc-subscription-responseClient Apps

Implementation Details

  1. Client apps e.g. DME would publish Subscription Create Event to the topic cm-avc-subscription. 
    Message Format (Client → NCMP):

    Code Block
    languagetext
    titleCreate Event from Clients
    collapsetrue
    {
      "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": {
                       “targets” :  [“sdsd”, “slada”, “ccde3”]     #  cmhandle targets
            "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//”  
     
        }
    }


  2. The NCMP would consume the messages from cm-avc-subscription topic, and  create Forwarded Subscription Event.

    Message Format (NCMP→ DMI Plugin):

    Code Block
    languagetext
    titleNCMP to DMI Message Format
    collapsetrue
    {
      "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.dmi:cm-network-avc-event.rfc8641",
          "schemaVersion": "1.0"
        },
        "predicates": {
          "targets": [{
            "cmhandle": "sdsd",
            "cmhandle - properties": {
              "prop1": "prop - value"
            }
          },
            {
              "cmhandle": "slada",
              "cmhandle - properties": {
                "prop - x": "prop - valuex"
              }
            },
            {
              "cmhandle": "ccde3",
              "cmhandle - properties": {
                "prop - y": "prop - valuey"
              }
            }
          ],
          "datastore": "passthrough-operational",
          "datastore-xpath-filter": "//_3gpp-nr-nrm-gnbdufunction:GNBDUFunction/",
          "_3gpp-nr-nrm-nrcelldu": "NRCellDU",
          "_3gpp-nr-nrm-gnbcuupfunction": "GNBCUUPFunction",
          "_3gpp-nr-nrm-nrsectorcarrier": "NRSectorCarrier"
        }
      }
    }


    TBD Further with external team: Putting predicates back to NCMP does not sense.  Since, the predicates and CM Handles are clashing. 

  3. The communication between NCMP and DMI-Plugin would be synchronously. 
  4. The DMI-Plugin would publish responses in a single step. ACK feature is not feasible as of now.
  5. Then, the NCMP would wait a response(s) within the timeframe (timeout) agreed on e.g. 30 seconds via once-off timer.
    1. Response in a single step
      1. Process result response: 2 out of 3 DMI has responded. (The percentage is %66.)
      2. In order to calculate the response ratio, CPS inventory CmHandleQueries could be used.
  6. Finally, the NCMP create outcome message, and publish it to the topic cm-avc-subscription-response.
    The outcome message format could be like:

    Code Block
    languagetext
    collapsetrue
    Possible options for initial response and further updates
    	Status only: COMPLETED / PARTIALLY_COMPLETED
    	Status and % -completed based on # Participating DMI-plugins
    	Status and %-completed based on #cm-handle-ids  registered (and participating) per Plugin
    	Status and list of m-handle ids for which NCMP got a response


...