d and the architecture for developing the same is detailed. An example of functionality in phase three is HSS (home subscriber server) provisioning agent that sends SOAP (simple object access protocol) triggers to HSS and also updates a common sub- scriber store based on a generic user profile for a converged network. The functionalities added are in line with SOA. This ensures that the addi- tions will not require changes in the generic solution. The specialized functions can be managed as separate services. The fourth phase involves customization specific to IMS, like the log format with IMS log parameters and registers for IMS per- formance data collection based on 3GPP standards. The discussion on NGNM is followed by an analysis of the adoption strategies for working on the NGNM framework. 34.3 Legacy NMS The various modules in a typical legacy NMS are (see Figure 34.1): a. Platform components: These components include object persistence, logging framework, libraries, and SO on that are required by most of the management function implementation modules. b. Data collection components: Based on the NMS protocol supported on the network element, these components collect data from the network elements. In some management paradigms this component may not be part of the NMS and will be a separate solution called EMS. Fundamentals of EMS, NMS and OSS/BSS GUI components Management function components Data collection components Figure 34.1 Simplified legacy NMS. C. Management function components: These components use the data col- lected from the network elements to provide FCAPS (fault, configuration, accounting, performance, and security) and other specialized management functionality. d. Northbound interface components: These components provide management data to the northbound interfaces like another NMS or operations support systems (OSS). e. GUI components: These provide user interaction screens that enable a user to perform operations on the various modules in the NMS. 34.4 Issues with Legacy NMS From the persp