esiliency include 1. Availability 2. Defect count 3. DPM 4. Completion rates 5. Latency Measurements must capture the transactions offered, successfully completed, and unsuccessful or defective transactions. Classification of defective transactions may include transactions that do not complete within a time bound. For time-based availability measurements, the health of the VNF can be determined with heart beats or light weight active probes that the VNF responds to. A controller mechanism is needed to determine how often probes should be sent, and how many unanswered probes determine whether the VNF is unavailable. In addition, a controller mechanism is needed to determine frequency and number of acknowledged probes required to decide up state of the VNF. The ONAP data collection and analytics engine provides the mechanism for reporting VF reli- ability KPIs. In addition, other operations support systems may retrieve data from common data stores provided by ONAP. 16.10 VNF SCALING MEASUREMENTS One of the key benefits from adopting NFV is its capability to adapt to variable workload by scaling its underlying cloud resources. VNF scaling is accomplished horizontally or vertically [18]. Horizontal scaling, referred to as scaling out/in, adds a new set of resources (virtual serv- ers, storages, and network bandwidth) or removes a set of existing resources, to adapt to the workload changes. On the other hand, vertical scaling, referred to as scaling up/down, increases or decreases the amount of resources assigned to existing virtual instances, for example, allocat- ing more/less physical CPUs or memory, to a virtual machine that is already running. Despite these two mechanisms to accomplish VNF scaling, most cloud providers support only horizontal Building the Network of the Future scaling as the vertical scaling is not supported by most common operating systems without rebooting [19]. 16.10.1 NFV SERVICE AUTO-SCALING Auto-scaling aims to dynamically adapt cloud resources to varying workload in an automated fash- ion.