CPS-2166: Forwarding CM Data Notifications based on Subscription

1

One client can have multiple subs

Apr 2, 2024 @kieran mccarthy, @Toine Siebelink  

2

Topic is setup correctly (by clients) and NCMP will have write access

Maybe not by client but definitely NOT NCMP responsibility

Apr 2, 2024 @kieran mccarthy, @Toine Siebelink  

3

CM Events contain CM Handle IDs (and NOT alternate IDs) so the correct  subscriptions can be identified 

This could change in the future but has lower priority

Apr 2, 2024 @kieran mccarthy 

1

Choose alternative for forwarding

Alternatives
NCMP forwards the CM Data Notification:

1. as multiple CM Data Notifications on a common external topic with a special header indicating the client-id so the client can filter

2. as one CM Data Notification on a common external topic with a special header containing ALL  client-ids (Array or String with special token separation)

3. to topic(s) registered by client(s) during Subscription creation

Apr 2, 2024 @kieran mccarthy and @Toine Siebelink

Option 3 further expanded as functional requirements 2 & 3

2

Even if clients specify the topic upon subscription creation, can multiple client share the same topic?

Only applies to alternative #3 above

Apr 2, 2024 @kieran mccarthy NO, see also assumption 1

3

Characteristics wil be discussed  after functional delivery and some performance test

Kakfa is assume NOT to be a limiting factor

Apr 2, 2024 @kieran mccarthy , @Toine Siebelink 

1

Client-defined topic

Topic used for forwarding notification should be based on the client-id which can be extracted from the subscription-id 

Need to agree and document the format of the subscription-id

Proposed by CPS

"<topic-name>---<unique-id>

eg. a client then would create (or own) a topic 'our.cm-channel'

then by convention they can create subscription ids like so:

'our.cm-channel---0001'

'our.cm-channel---0002'

'our.cm-channel---4g-cell-subscription'

'our.cm-channel---5g-cell-subscription"

Assumption - We'll get a subscriptionId and topicname

tbc, @kieran mccarthy / @Csaba Kocsis  to review and come back.

Currently NCMP receives event and it doesn't contain Topic name.

Issue - NCMP still need topic name.
Apr 22, 2024  @kieran mccarthy to confirm and revert 

May 17, 2024 

Event format shall be subscriptionId and topicname@kieran mccarthy @Kolawole Adebisi-Adeolokun @Priyank Maheshwari @Csaba Kocsis 

long term focus shall be on the rest interface(push) for rapps

May 21, 2024 

Deperio. this as well on the release page till we get around discussing the new subscriotion epic.

2

Client-defined topic

Client application shall ONLY receive notification they subscribed on

Apr 2, 2024 @kieran mccarthy @Toine Siebelink  

3

Client-defined topic

Client application shall not see notification they did not subscribed on

Apr 2, 2024 @kieran mccarthy @Toine Siebelink 

Client-defined topic

Subscription-id shall be in the event header

Also, this mean multiple event to the same topic. 

Apr 2, 2024 agreed NOT to support this for performance reasons and clients can always create multiple subs. if needed

Subscription ID format not correct i.e. cannot extract out a valid topic name

topic does not exist

no write access to topic

cannot find subscription  based on cm handle/path in event

incoming CM notification change events

150M Events / day

~1,736 Events / second! per NCMP instance! 

outgoing CM notification change events

200M Events / day

caused by overlapping subscriptions 

NCMP shall support horizontal scaling to support >> 150M CM notification change events (Daily)

1. Do we need to define a maximum ?

2. Do we need to define an acceptable overhead ie 2 instance will  (probably) NOT process 2 x 150M = 300M Events day

NCMP shall support processing CM notification change events with the following subscription profile :

• 40% of subscriptions shall process 5% of all network change notification events

• 30% of subscriptions shall process 10% of all network change notification events

• 15% of subscriptions shall process 30% of all network change notification events

• 9% of subscriptions shall process 50% of all network change notification events

• 5% of subscriptions shall process 70% of all network change notification events

• 1% of subscriptions shall process 100% of all network change notification events

This breakdown does NOT really affect NCMP performance and does not need to be 'mocked' or simulated exactly for testing purposes
BUT we should test with multiple subscription and 1 out of 3 events wil go to 2 different topics (as per #2)

Consider Peak load ? ie. 100M events in 1h