s CM Notification Event Proposal Project Impacts for

s CM Notification - Event Proposal - Project Impacts for supporting the Proposal Nokia Proposal October 24, 2019

Configuration Management Notification Delivery to ONAP • 3 GPP and O-RAN have endorsed a RESTFUL interface for CM Notifications - notify. MOICreation - notify. MOIDeletion - notify. MOIAttribute. Value. Change • The content of these notifications are associated with configuration changes - It is likely that the consumers of CM Notifications are different than the consumers of other notifications - There are likely multiple consumers for the data (controller, data lake manager, SON Analytics Application, etc. ) - Latency is critical. Consumers of this data often need to be able to quickly act on configuration changes. 2

Proposal New VES Event for CM Notifications • New domain cm. Notify is proposed to readily identify and route CM Notifications to separate topic. • 3 GPP fields as defined in TS 28. 532 Rel 16 are contained in the payload of the event • Event Name will identify the type of notification being produced. Thesis: In this case a new domain is appropriate as the content of this event is very different from the existing notification, latency constraints are tighter, consumers are very different.

Evaluation Criteria for the creation of a new Domain • We understand that it is important to create new domains in ONAP only when necessary. • Nokia ONAP team proposed criteria to evaluate when a new Domain should be added Ten critical evaluation criteria proposed (agreed upon key criteria highlighted in yellow) 1. 2. 3. 4. Is there already a VES event that functionally serves the purpose of the new event stream? What is the level of re-use compared to the existing domain/event? What are the impacted Applications? What set of consumer applications are expected to subscribe to the new event stream as compared to the existing event? 5. What is the level of consumption of the new event (how many applications expected to subscribe)? 6. What is the volume of the new event as compared to the existing events? 7. What is the traffic profile for the events (steady, peaked)? 8. What is the latency requirements on the data? 9. What are the event replication requirements for the new domain? 10. What is the impact to the Data Model?

Analysis comparing file. Ready suitability for CM Notifications – Alok’s assessment 5

Factors supporting the creation of a new cm. Notify Domain • The cm. Notify event as defined is fully aligned with 3 GPP --- need to consult with 3 GPP representatives and ensure no further harmonization is needed. - Similar to fault notifications, it is more efficient for the producers of the information to populate the mandatory fields rather than creating a hash. Map and pushing all the data into a single field. • Efficient data delivery is critical with low latency since analytics applications may need to take further action based on configuration changes that occur. - The use of a cm. Notify Domain allows the collector to send CM notifications to a separate topic based on the domain field in the common header - While DCAE may be evolved to be able to route the events based on more complex algorithms, it would be inefficient to require the collector to examine the contents of the Event fields to determine where to route the data. - subscribers of this information can readily find the notifications without the need to parse through a number of notifications they may not be interested in. • CM Notifications will likely be subscribed to by a different set of applications than subscribe to a generic notification. - Controllers, SON Analytics applications, Policy control etc. • The effort to introduce a new domain in DCAE is well understood.

cm. Notify Event Proposed Common Header Content Field Type version string Yes Version of the event header (currently: 4. 1) “ 4. 1” event. Name string Yes domain enum Yes Cm. Notify_nf. Type_NFVendor_notification. Type, where nf. Type is defined by the NF provider e. g. 5 g. Cu, 5 g. Bts etc. and notification. Type is the type of cm notification being raised. —example “Cm. Notify_gnb-Nokia_notify. MOICreation” Event domain enumeration: ‘fault’, cm. Notify’ ‘heartbeat’, ‘measurement’, ‘mobile. Flow’, ‘other’, ‘pnf. Registration’, ‘sip. Signaling’, ‘state. Change’, syslog’, threshold. Crossing. Alert’, voice. Quality, “cm. Notify” event. Id string Yes event. Type string No Event key that is unique to the event source. This value does not change until a fault is cleared. This is used to correlate multiple reporting of the same fault instance from onset to clear—this is valuable for analytics applications cm. Notifyyyy “cm. Notify 1” Not used nfc. Naming. Code nf. Naming. Code string No No Network function component type: 3 characters (aligned with vfc naming standards) Not Used Network function type: 4 characters (aligned with vnf naming standards) Not Used source. Id bytes No UUID identifying the entity experiencing the event issue (note: the AT&T internal enrichment process shall ensure that this field is populated) Not Used source. Name string Yes reporting. Entity. Id bytes No reporting. Entity. Name string Yes priority enum Yes start. Epoch. Microsec number (uint 64) string Yes number (uint 32) ves. Event. Listener. Versio String n Yes Name of the entity experiencing the event issue NF Name(pnf-name or vnf-name ) as entered in A&AI uniquely identifying this instance of the NF Nokserial number of the pnf for example—TBD UUID identifying the entity reporting the event, for example an OAM VM (note: the AT&T internal enrichment process shall ensure that this field is populated) Not Used Name of the entity reporting the event, for example, an EMS name. May be the same as the source. Name. For synthetic events generated by DCAE, it is the name of the app generating the event. If NF raised the notification would be same as source. Name if EMS raised the notification would the entry for the EMS Processing priority enumeration: is High, Medium, Normal, Low’ “Medium” the earliest unix time aka epoch time associated with the event from any component--as microseconds elapsed since 1 Jan 1970 not including leap seconds Event time that the notification occurred the latest unix time aka epoch time associated with the event from any component--as microseconds elapsed since 1 Jan 1970 not including leap seconds Event time that the notification occurred (same as start. Epoch. Microsec) Offset to GMT to indicate local time zone for device “+06: 00” Ordering of events communicated by an event source instance (or 0 if not needed) “ 0” Version of the Ves. Event Listener. “ 7. 1” last. Epoch. Microsec time. Zone. Offset sequence Required? Description Yes No Yes Possible values populated in “green”

cm. Notify Event Definiton—this event is used for notify. MOICreation, notify. MOIDeletion and notify. MOIAttribute. Value. Change Field Name cm. Notify. Fields. Version Man/opt Description comments M version of the cm. Notify fields block additional. Fields O Additional Information DN M Managed Object raising the alarm object. Class, object. Instance String A Distinguished Name (DN) is used to uniquely identify a MO within a name space as defined by ITU-T notification. Type M Type of notification raised String The expected types of CM notifications from 28. 532 are notify. MOICreation, notify. MOIDeletion, notify. MOIAttribute. Value. Change notification. Id M 3 GPP defined unique identifier for this occurrence of the notification source. Indicator M Indicates the source of the operation that led to the generation of the notification. String There is an ENUM defined in 28. 532 (resource. Operation —internal operation of resource, management. Operation—response to management operation, s. ONOperation—result of SON, unknown-- can’t determine why event. Time M Time event occurred We may be able to eliminate this since it is in the Event header in VES consult with 3 GPP reps. system. DN M The DN of management service providers. String correlated. Notifications O Set of all notifications to which this notification is considered to be correlated as defined in ITU-T Rec. X. 733 [4] hash. Map (notificationid-Type, source) additional. Text O attribute. List CM hash. Map String Notification identifier as defined in ITU-T Rec X. 733(4) String Attribute Name and values (attribute. Name(string), new. Attribute. Value(any type), old. Attribute. Value(any type) This is Mandatory for notify. MOIAttribute. Value. Change. 3 GPP defines it as options for Creation and Deletion. Array named. Hash. Map (attribute. Name(string) hash. Map (new. Attribute. Value(any type), old. Attribute. Value(any type))—should provide the attributes affected by this notification e. g. for the notify. MOIAttribute. Value. Change it should include all attributes that were modified.

ONAP Project impacts to support cm. Notify Event • DCAE: Implement new cm. Notify VES Event and introduce new cm. Notify domain. • DMaa. P: Add support for cm. Notify. • VES specification and registration documents must be updated

s Thank you