M-based platforms). Today x86 is best suited to support the upper layer services required, but the architecture can include any future COTS-based solution that can drive down costs or add functionality. The layer above the hardware is the operating system for the uCPE. This will be an open source operating system optimized for running VNFs. This will include functions to allow service activa- tion and management interfaces to the Open Network Automation Platform (ONAP). Virtual Virtual Virtual Virtual Function Function Function Function Virtualization Layer Open Source Operating System COTS Hardware Components FIGURE 10.15 uCPE with VF. Enterprise Networks One of the important benefits of the uCPE is the ability to run multiple VNFs on a single hard- ware platform. In today's customer premise implementation, multiple boxes are needed at premise locations to support different network functions. For example, a site may need a box for the router, another box for a firewall, a third for WANx, etc. With cloud-based virtualization technology in the hypervisor layer, multiple network functions can run on the same hardware, each in its own VM. Longer-term, this can be optimized with network functions running in Linux containers, which will eliminate the hypervisor overhead but maintain application separation. The final piece of the architecture is the ability to orchestrate the uCPE using SDN. The uCPE will have orchestration APIs SO the ONAP platform can orchestrate VNFs on the uCPE. This will include turning up a VNF VM, turning down a VM, and lifecycle management of a VM. As mentioned, one of the key characteristics of the uCPE is to run multiple VFs on a single hard- ware device. Figure 10.16 outlines how a typical customer premise may be set up in today's model and how the uCPE can simplify this with running multiple functions on a single box. In today's premise model, a typical site will have a premise-based router that will have a wide area circuit to a provider's network. The router is a purpose-built box that in