t and the Business Requirement Model. The problem statement defines the scope of the problem and identifies the problem needs or issues, while the requirement model handles an implementation independent description of requirements. The aim of this document is to provide a single common solution to address interoperability between element management and network management layers that involves (see Figure 8.2): Multiple network technologies: Including SONET, SDH DWDM, and ATM Network elements that support multiple technologies Open standards Multivendor EMS and NMS TMF513 is a set of use cases, and static and dynamic UML diagrams that can be used as: Foundation for information and requirement agreement of TMF and other bodies working in this area Definition of requirement agreement and input for information agreement for service providers Development of commercial off the shelf (COTS) products by vendor According to TMF513, adopting MTNM will lead to: Lesser time for service activation Scalable NML-EML interface Reduced effort and time in integration vendor X vendor Y vendor X vendor Y SONET interface interface interface MTNM common interface EMS A EMS B EMS C EMS A EMS B EMS C Figure 8.2 Single solution based on MTNM. MTNM Compliant EMS More options for service providers in choosing products for interoperability Lesser cost to EMS vendors in making their product work with multiple NMS Rapid service delivery Easier to fix faults on a common interface Most of the interface definitions (requirements are use cases) in TMF513 are centered on a basic set of objects that communicate using the EML-NML interface and share a set of common attributes. These objects are (note: there is cross refer- ence between objects in the description below): Alarm severity assignment profile (ASAP): This object represents severities that can be assigned to alarm probable causes. Call: This object represents the association between endpoints in support of a service instance or an infrastructure trail. Connection: This object represents con