a collection: For example, when a call trace appli- cation is implemented, the table to be queried is specified in the code for functional implementation or data collection, rather than specifying it in a standard xml file and reading from the file. 3. Complex information and process flows that are not based on standards: New services like dynamic event handlers and correlators are being developed. Report: NGNM Framework and Adoption Strategy Legacy NMS cannot easily adopt these services as the fault functionality does not isolate "alarm handling by setting specific threshold" from "forced clear- ing of alarm" at implementation. The interactions between these modules are closely coupled making the addition of new services difficult without major rework in code. 4. Nonstandard interfaces for interaction: Proprietary interfaces are being used by legacy NMS, to communicate with the NE/EMS in the southbound inter- face and to OSS in the northbound interface. The communications within the different layers of NMS also use proprietary interfaces. When there is a need to support new NE/EMS/OSS, the complete pipeline in legacy NMS is modified to manage the NE/EMS/OSS. Proprietary interfaces make the NMS very tightly coupled and difficult to maintain. 5. Dependency on management protocols and not based on standard 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 Fig