allow the enterprise customer to benefit from pay-as-you-grow business models and avoid provisioning for peak traffic. Flexibility: The vCPE platform should support subscriber-based, application-based, device-based, and operator-specific policies simultaneously. Moreover, adding or removing new NFs should be easily manageable by the network operator, without requiring physical presence of technicians on the site or having the enterprise customers involved. It should also be possible to accurately moni- tor and reroute network traffic as defined by policy. The platform should allow NFs to be implemented, deployed, and managed by operators, enterprises, or third-party software vendors. Efficiency: The vCPE should provide the tight NF service-level agree- ments (SLAs) on performance or availability, identical to the SLAs offered with dedicated services. For example, the SLA may specify the average delay, bandwidth, and the availability for all the services provided to one customer. To support the SLA compliance, the plat- form should closely monitor the performance for each customer and dynamically adapt the resources to meet the SLAs. Scalability: The vCPE framework should support a large number of rules and scale as the number of subscribers/applications/traffic volume grows. The ability to offer a per-customer selection of NFs could potentially lead to the creation of new offerings and hence new ways for operators to monetize their networks. Reliability: The vCPE framework should abide by NFV reliability requirements. Service availability as defined by NFV refers to the end-to-end service availability that includes all the elements in the end-to-end service (VNFs and infrastructure components) with the exception of the end-user terminal. Openness: The final issue is ensuring that the vCPE framework should be capable of accommodating a wide range of NFs in a nonintrusive manner. The vCPE should support open-source-based and standard solutions as much as possible. 5 SDN and NFV in 5G 5.4.2 Design In the vCPE archit