 informa- tion/data model: The NMS should not be hardwired to the protocol used by the EMS from which it collects data. The functionalities in NMS must be implemented for a standard format unlike the way it is done in legacy NMS. Nonscalable architecture: There are multiple functionalities that are supported in an NMS and in most cases these functionalities may not be implemented by the same vendor. Legacy NMS is not based on scalable architecture like SOA, which makes addition of functionality tedious and causes minimal reuse of components. 34.5 NGNM Solution 34.5.1 NGNM Framework The Phase 1 of the NGNM solution development starts with creation of a generic NGNM framework. This is the NGNM framework shown in Figure 34.2 without any specialized NMS functions. The NGNM framework suggested in this report supports the following: a. SOA for architecture: The functionalities in the NMS are designed as sepa- rate services with standard interfaces for interaction and an XML file for any customization. There is no hard coding of network element specific informa- tion like table names. New functionalities can be added as separate services without disturbing or making changes in existing functions. For example, the performance module may interact with the fault module but is independent of the implementation of the fault module. With this technique, when open source components like an independent subscriber provisioning functionality is added to the NMS that interacts with fault or performance module, retest- ing of existing functions is not required. SOA leads to smooth integration and functionality rich NMS. Fundamentals of EMS, NMS and OSS/BSS Specialized NMS functions Generic NMS functions MTOSI adapter OSS/J Unified NMS framework Architecture Adaptation components Information model N/W management functions Interface model External applications Figure 34.2 NGNM framework. Advantages of using SOA in NGNM framework: More reuse Reduced effort and risk in implementation with independent services Faster development Ease of