e to recover from failure. The failure can be of various types; it could be a faulty piece of hardware or software, for instance. The orchestrator should be able to detect the type of issue and then take appropriate corrective action. For example, if there is an issue with the software, then moving the network function to a different server will be of no use. Similarly, if the hardware is faulty, then rolling back a software version wouldn't help. As an orchestrator has a view of the whole network, it can correlate a fault across the network and root cause the failure to a large extent and then take appropriate action. As an example, if there is a sudden KPI dip in a region and, at the same time, there is a critical hardware alarm in the same region, it could be easily correlated to the timestamp of the issue, and appropriate action (such as moving the particular element out of rotation from production and diverting the traffic to a healthy node) can be taken. There is enough room for flexibility as to what action needs to be taken in each scenario, and the MNO can customize each action at its own discretion. Congestion control by configuration management This is another feature that can be best adopted by an orchestrator with the overall network view. Congestion is a frequently occurring condition in a mobile network. It is a sudden rush of traffic or number of connections that causes general delays in the network and dips the KPIs drastically. One way to address this issue is, as we discussed earlier, by auto-scaling, but it is not always feasible to find resources in extreme load conditions. Hence, the best way to deal with a situation like that is to optimize the usage of the existing allocated resources. In a mobile network, there are a lot of value-added services that run on network functions. While this might improve some aspects of business, these are not mandatory to run for a network to perform well. Such services can be identified by the network orchestrator in congested nodes and stopped temporarily S