...
- 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).
Create Subscription : client app → ncmp Create Example {
"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"
]}
}
}{
"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-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 1 : Create Subscription request from App
- NCMP receives consumes the create cm subscription event and processes it as follows :
- Persist the subscription and cm-subscription-filter information to db
- Read all CM handles that match the cm-filter-subscription (model matching, cmhandleId matching)
- If a subscription is already ongoing for a cmhandle then separate them from the list for later processing (after the existing ongoing cmhandle subscription has completed).
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. - Merge the existing cmhandle filter (if one exists from a previous subscription) with the new cm-filter-subscription
- 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 contains 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 only for cmhandles that fail to subscribe successfullyresponse on the dmi-cm-avc-subscription-events topic for each cmhandle.
| Usecase | Participants | Request Schema | Request Example |
|---|---|---|---|
| Register Subscriptions | ncmp → dmi | Protocol : REST { | Protocol : REST { |
Table 2 : Register Subscriptions with DMI plugin
5. dmi-plugin loops through the cmhandle subscriptions and creates a new subscription or modifies an existing subscription for the remote 'device' associated with the cmhandle.
6. dmi-plugin calls back to NCMP to notify of the newly created or updated subscription
7. NCMP updates its subscription registry with the new subscription information
| Usecase | participants | Request Schema / Example | NCMP Action |
|---|---|---|---|
| Notify of create subscription request success on passthrough-operational datastore -success case | dmi → ncmp | Protocol : Kafka Event {
|
|
} | register the new subscription data with the cmhandle : 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 in NCMP DB "subscriptions" : { "running" : { # 'local' ncmp subscription is required with the cmhandle - store subId separately? "passthrough-operational" : { |
" "passthrough-running" : { } Once NCMP receives the notification response |
| ||
| Notify of modify subscription request success on passthrough-operational datastore -success case | dmi → ncmp | Protocol : Kafka Event {
|
|
} |
Table 3. DMI plugin sends Subscription Response to NCMP
8.
Update Subscription
Topics
...