iscussed next. The previous discussion on generic framework and functions specifies the use of xml files for customizing the function module. There is certain level of customization of generic functions required when applying it for a specific network. Again IMS is taken as an example in this report. The standards specified in 3GPP TS 32.111-2 for the fault management in an IMS network can be used in customizing the parameters in the alarms displayed. All the alarms will be having the attributes as mentioned in Section 5.5.1 of the 3GPP TS 32.111-2 document. It specifies that an alarm needs to have two parts, the notificationHeader and alarmInformation-Body. Some of the parameters in the notificationHeader are: managedObjectClass: Class specific to managed object. managedObjectInstance: Instance of the managed object. notificationId: Unique id that can differentiate two alarm notifications raised for the same problem scenario on the same managed object. eventTime: The time at which the event occurred. Some of the parameters in the alarmInformationBody are: probableCause: It provides information that supplements the eventType on the cause of the event. perceivedSeverity: The severity of the alarm. proposedRepairActions: How to fix the problem specified in the alarm. additionalInformation: Information like the time the alarm was acknowledged. There is another 3GPP document for performance parameters. The standards specified in 3GPP TS 32.409 can be adopted for defining the performance management parameters to be collected for network elements in IMS network. 34.6 Adoption Strategy Adoption strategy is a discussion of how the NGNM framework can be adopted without doing away with the existing legacy NMS solution. 34.6.1 Using Mediation Layer This approach is suitable when the current architecture uses multiple NMS solu- tions to manage different networks. In this case, migration of each external appli- cation to an NGNM framework is not a cost-effective approach. So it is suggested Report: NGNM Framework and Adoption