notification. Details of AVC and SC are handled in the "SD1-2_AVC_SC_Notifications" document. Document on performance parameters: The names to be used to identify some of the performance parameters are discussed in the "SD1-28_PerformanceParameters document. The parameters to be monitored include average/maximum/minimum bit rate errors in an interval, count of received or transmitted cells/lost cells/misin- serted cells, and count of cells discarded due to congestion/protocol errors/HEC violation. Probable causes: An alarm notification usually contains the probable reason for the generation of the alarm. There are a set of fields required in an alarm notifica- tion, one of them being the probable cause of the alarm. "SD1-33_ProbableCauses" document includes some standard causes that can be used in the probable cause alarm field. It should be noted that TMF is not the only standardizing body involved in defining such standards. From FCAPS perspective the fields required in an alarm for a specific network are also defined by 3GPP. Some of these details will be covered in the next chapter. The remaining supporting documents are for defining modes of operation, per- formance management file formats, traffic parameters, and SO forth. Using UML, TMF 608 also gives the class diagrams to be used with the interface objects. The class diagram helps in converting the UML models to program code. Some of the attributes in EMS Class are: "name": To represent the name of the EMS object "emsVersion": To have version control for installation and upgrade of new features "additionalInfo": For information that cannot be captured in the standard set of attributes defined by TMF for EMS and will be more vendor specific. Some of the functions of EMS class are: getAllEMSSystemActiveAlarms() Get the active alarm list from the EMS getAllTopLevelSubnetworks(): Get details on the Subnetworks from the EMS getAllTopLevelTopologicalLinks(): Get Link information from EMS getAllTrafficDescriptors(): Get the traffic descriptors from EMS 8.5 MTNM 