CPS-2166: Forwarding CM Data Notifications based on Subscription

References

CPS-2166 - Getting issue details... STATUS

	Assumption	Notes	Sign-off
1	One client can have multiple subs		02 Apr 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	02 Apr 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	02 Apr 2024 kieran mccarthy

Issue

Notes

Decision

1

Choose alternative for forwarding

Alternatives
NCMP forwards the CM Data Notification:

as multiple CM Data Notifications on a common external topic with a special header indicating the client-id so the client can filter
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)
to topic(s) registered by client(s) during Subscription creation

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

02 Apr 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

	Interface	Requirement	Additional Information	Signoff
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. 22 Apr 2024 kieran mccarthy to confirm and revert
2	Client-defined topic	Client application shall ONLY receive notification they subscribed on		02 Apr 2024 kieran mccarthy Toine Siebelink
3	Client-defined topic	Client application shall not see notification they did not subscribed on		02 Apr 2024 kieran mccarthy Toine Siebelink
4	Client-defined topic	~~Subscription-id shall be in the event header~~	~~Also, this mean multiple event to the same topic.~~	02 Apr 2024 agreed NOT to support this for performance reasons and clients can always create multiple subs. if needed

	Scenario	Expected Behavior	Notes
1	Subscription ID format not correct i.e. cannot extract out a valid topic name
2	topic does not exist
3	no write access to topic
4	cannot find subscription based on cm handle/path in event

	Parameter	Expectation	Notes
1	incoming CM notification change events	150M Events / day	~1,736 Events / second! per NCMP instance!
2	outgoing CM notification change events	200M Events / day	caused by overlapping subscriptions
3	NCMP shall support horizontal scaling to support >> 150M CM notification change events (Daily)		Do we need to define a maximum ? Do we need to define an acceptable overhead ie 2 instance will (probably) NOT process 2 x 150M = 300M Events day
4	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)
5	Consider Peak load ? ie. 100M events in 1h

Subscription Merge Example

CM Data Notifications Overview
Which are of interest to which Client (subscription ID)

	Cm Handle	Path	A-10	B-52
1	CH-1	/p/c1	Yes	No
2	CH-1	/p/c2	Yes	Yes
3	CH-1	/p/c3	No	Yes
4	CH-4	/p/c2	No	Yes
5	CH-4	/p/c3	No	Yes
6	CH-1	/p/c4	No	No

NCMP (currently) listens to all CM Data Notifications (on an 'internal' topic
NCMP queries its own persistence service to find out which Client(s) are interested in the notifications A-10 and/or B-52