ommands to the network elements or to generate a trouble ticket and forward it to the concerned net- work operator. Network element itself handling a network trouble: The network element can also be programmed to take actions for trouble conditions. For example, when an application on the network element is upgraded using upgrade soft- ware running on the NE and due to some reason the upgrade fails. In this scenario the upgrade software on the NE can be programmed to fall back on the application being upgraded to its earlier release. The NMS functions that are discussed in this section as part of resource trouble management are: Report resource trouble: It is not necessarily that the customer will be the entity reporting a trouble condition. In most scenarios the customer might only have a service problem and not an actual resource trouble. An NMS that is used by the operator for monitoring resource trouble serves as the best report engine. The operator can use the event logs generated for a network trouble condition to take corrective action or put predefined rules to gener- ate trouble reports whenever a specific trouble trigger a log that gets collected by NMS. Localize resource trouble: Network trouble reported by customer or identified by upper business/service layer needs to be localized. Localization involves identifying the specific element in the network that caused the trouble condi- tion. Only after the trouble condition is localized to the lowest level possible, will it be possible to effectively resolve the issue. Localization is not just lim- ited to identifying the network element that caused the trouble condition. For example, consider the scenario in which the customer reports degradation in quality of service and raises a ticket for the same. Localization starts with identifying the resources allocated from the inventory management system to offer the service. The resources offering the service can then be analyzed to see utilization and KPI (key performance indicator) values. This would lead to