ective of the multivendor, heterogeneous network, and convergent service environment, the current legacy NMS has the following issues: 1. No clear demarcation between data collection and functional implementa- tion: For example, the data collection process itself implements fault and configuration management functionality for that network element (NE). The net result is when data needs to be collected from an NE that has the same network management protocol; most of the code needs to be rewritten or modified. If data collection is limited to protocol specific information acquir- ing, then this problem would not arise. 2. There is much network specific information hard coded in the functional implementation and data 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