This would mean the user plane nodes would be stressed out; however, it is possible that some control plane network functions are sparingly utilized. Therefore, it is worthwhile to consider the creation of an entity that could monitor the usage of all the resources and manage it efficiently and dynamically such that, on load conditions, resources could be freed up from minimally used network functions and dedicated to resource-intensive network functions. This would help not only save costs by better utilization of the hardware resources and minimizing hardware oversubscription but also result in an improvement in KPIs. An orchestrator is one of the best places to seat such intelligence in the network, as it already has access to life cycle management of all the network functions and can manage to implement this use case with minimal investment. Auto scale-in and scale-out have been implemented widely in the IT industry but they have not yet picked up their pace in the telecom field. There is still some reluctance among operators to put in live traffic on a freshly orchestrated network function. As there is an elaborate acceptance procedure that is followed at the MNO's side before launching any element in production, this is their standard operating procedure. However, if enough confidence can be built in an automated test framework that would run these acceptance tests as soon as a new network function has been spawned, then Introduction to network orchestration this hesitation could be mitigated. Like most things, trust in such elevated-level automation may take some time, but it is inevitable, and just a matter of some trials to be successful. We can see a higher rate of adoption in the coming years, where networks will grow and shrink in terms of usage. Many cloud players already have a pay-per-use model. Cloud providers are strongly growing their presence in the telecom space and this will further push this case. Automatic failure recovery Another classic use case of an intelligent orchestrator is to be abl