You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 34 Next »

This page given an high level overview of Notifications used by CPS/NCMP for communication wit system outside CPS/NCMP about data changes.
There are also notifications used for asynchronous  method calls but there are kept out this overview for the sake of simplicity.

Event Descriptions

#DescriptionSourceTopicDestinationTriggerR12 Work ItemNotes
1CPS-Temporal data updatesCPS-Core

cps.data-updated-events

CPS-TemporalCPS-Core Data UpdateN/A
  1. On by default for all dataspaces! Populate notification.data-updated.filters.enabled-dataspaces to turn it off see CPS-1361 - Getting issue details... STATUS
2NCMP CM-Handle LCM (LifeCycle Management) eventsNCMP

ncmp-events

External (NCMP) ClientsNCMP CM-Handle State Change
(registration use-case)		N/A
  1. See also CM-Handle State Changes and Notifications Overview
  2. On by default, can be disabled using notification.enabled
3NCMP Data AVC (forwarding #5)NCMP
  • determined by ncmp-subscription(s) 
  • 0-n topics possible*
External (NCMP) ClientsDMI Data AVC on passthrough datastore & NCMP Subscription#6a

The notifications should be on the set of topics specified by the union of all relevant subscriptions. This is why there is a difference between the subscription model (visible to a client/subscriber) and the subscription model used internally – The notification should not need to calculate, only look up the set of topics to emit on.
One cm-handle can have 0-many topics
The 'predicate' information is only to be forwarded to the DMI Plugin does not need to be stored (TBC with kieran mccarthy )

4CPS-Core Data AVCCPS-Core
  • determined by cps-core-subscription(s) 
  • 0-n topics possible*
External ClientsData Change & CPS-Core Subscription#7

Any client can subscribe to CPS-Core for any data subscription. The subscription wil include the topic to be used

5DMI Data AVC (Attribute Value Change)DMI-PluginTBDNCMPDepends on DMI-Plugin
  • ONAP: VES Events from Device
#6a
#7
  1. Format (schema) of the Event is defined by (in) NCMP
  2. Topic names is defined by NCMP
  3. For passthrough datastore NCMP will emit a NCMP Data AVC (#3). Do we need to check tHE Datastore or just the cache enabled flag?
  4. If data is cached this event should lead to a CPS-Core(Cache) update and a CPS-Core Data AVC (#4)
6VES EventONAP Devices
ONAP DMI PluginChange on Device#7
  1. Open issue: how to translate an ONAP device ID to a CM Handle ID?!
7Notification Subscription EventDME
(Data Mgmt and Exposure)		cm-avc-subscriptionNCMPUser driven? CRUD operation Notification Subscriptions#6b

See also

The source can be anything that is authorized and knows the subscription event schema. It will be up to the encapsulating 'product' e.g. ONAP to decide if applications should use this interface directly. 

From NCMP perspective this is an access control challenge – If you are authorized to write to the cm-avc-subscription topic, NCMP will react

8Proprietary AVCProprietary DevicesN/AProprietary DMI PluginChange on DeviceN/AIrrelevant to ONAP Solution might not even by an 'event'. As long as it can be converted into a DMI Data AVC (#5)
9VES EventORAN Devices
Proprietary DMI PluginChange on Device

Similar to #6 above. Main fields:

  • href → can be mapped to cm-handle by plugin (without additional information from other fields)
  • path → can be mapped to xpath by plugin 

Component Diagram

CPS Notifications Overview


  • No labels