As Network Functions Virtualization (NFV) approaches its third birthday, it continues to gain significant momentum. Driven by the ETSI NFV Industry Specification Group’s transition from requirements to adoption, and collaboration on the Open Reference Platform for NFV (OPNFV), many operators are already progressing towards adoption, largely in conjunction with software-defined networking.

Communications service providers (CSPs) spanning telecommunications, cable, and cloud are currently validating NFV business cases for their individual organizations, leveraging dozens of NFV proofs of concept (PoCs), as are many others outside the public eye. As NFV rapidly evolves, we have observed a repositioning in thinking:

• While operators initially anticipated improved agility as the key benefit for NFV, it is much easier to rationalize cost savings to CFOs, who have been expressing healthy skepticism about the uptake rates for new, NFV-enabled services.
• Transformational adoption of NFV (not surprisingly) is giving way to more pragmatic strategies, where NFV will be deployed one use case at a time.
• Initial PoCs have yielded encouraging results, motivating expanded lab and field trials.

NFV was originally envisioned to virtualize physical network functions (PNFs) required for network operations. Emphasis has since shifted to virtualized services directly serving end-users. One use case receiving a great deal of attention is virtualized customer premises equipment (vCPE). In fact, both “network function as a service” and “virtualization of the home environment” were among the original ETSI NFV vCPE use cases. IHS/Infonetics’ “SDN and NFV Strategies: Global Service Provider Survey” last year “rated business vE-CPE (using NFV for the delivery of services to businesses/enterprises) the #1 use case overall for NFV in 2014–2015.”

Virtualized CPE is another inherently ambiguous NFV and SDN term – others include application, service, and orchestration. Consequently, we propose new syntax to precisely define vCPE.

First is a definition of Open vCPE: A service delivery model where network functions embedded in customer premises equipment are virtualized to improve agility and/or reduce costs.

Network functions may be implemented on either the customer side (in CPE), the provider side, or most typically, on both sides.

Figure 1: vCPE Terminology

Open vCPE is characterized by:

• Broad applicability. vCPE supports both infrastructure- and user-facing use cases.
• Simplified end-user attachment. vCPE simplifies or eliminates CPE altogether.
• Flexible deployment. Virtualized network functions (VNFs) may be implemented either on the customer side or at the service provider facility (see Figure 2).
• Open vCPE supports a wide range of VNFs and complies with relevant NFV and SDN standards and open-source projects.

   Figure 2: Scale-Out Use Cases for NFV

Figure 1 employs the new terminology:

• End-to-End Services delivered by CSPs may comprise a set of service-chained VNFs hosted at the customer-side (CPE) and the provider-side cloud.
• VNFs reside in Virtualization Containers (VCs), which may be implemented in Virtual Machines (VMs), Linux Containers (LXC), or other virtualization technologies. ETSI NFV ISG defines VC as “Partition of a compute node that provides an isolated virtualization computation environment.”
• NanoServices consist of a set of VNFs integrated “as a service” in a single virtualization container.
• Service Chaining is the ability to direct traffic flows from an ordered set of VNFs and/or NanoServices. The ETSI NFV Architectural Framework refers to service chains as service function graphs.
• Service-Chaining may be implemented among VCs (Network-Layer Service Function Chaining) or within a single VC (Application-Layer Service Function Chaining).
• Many end-to-end services will consist of a single NanoService resident on the Customer-side (end-user facilities, such as a home, branch office, etc.), which is a network-layer service chained to one or more NanoServices at the Provider-side (CSP facilities such as a central office, mobile base station, cable head end, etc.).

Number of NFV Containers

Figure 3: vCPE Use Case Classifications: Scale-Up vs. Scale-Out

Because practically any network function may be delivered via NFV and vCPE, there are myriad use cases supported. Figure 3 categorizes the use cases according to how VNFs are deployed:

• Scale-Up use cases – where VNFs are delivered using relatively few (and typically large) VNF instances that support large numbers of end-users. Examples include virtualized evolved packet core (v-EPC) and IP multimedia subsystem (v-IMS) in a mobile network, or broadband remote access servers (BRAS) in fixed networks.
• Scale-Out use cases – where VNFs and NanoServices are instantiated on a large scale to support groups or even individual end-users (as illustrated in Figure 2). Examples include basic connectivity services (e.g., residential broadband) enhanced with open-source security VNF components; mobile business services enhanced with VPN services; or cable customers provided with parental controls.

While there are no hard-and-fast rules governing these vCPE classifications, Scale-Up use cases are optimal for infrastructure VNFs, which are typically large and complex. In contrast, Scale-Out use cases enable granular, user-facing VNFs and/or NanoServices to be delivered to thousands and even millions of end-users.

vCPE is clearly governed by the First Law of Networking: Economics dictates viability.

By simplifying/eliminating hardware, vCPE reduces both capex and opex, while simultaneously driving new revenues by accelerating deployment of a range of value-added services. What can operators achieve if the cost of end-to-end services is low enough? Ultimately, granular service offerings that may be personalized to the needs of individual end-users.

For example, cable operators can offer parental controls only for families. Security services can be tailored to when users are at home or away. Mobile operators can offer VPN and security services adapted to business policies for individual customers, and configured and monitored by the operator based on where individual users are traveling, along with the applications/data they must access.

The key is the ability to maximize the implementation efficiency, which corresponds to how many end-to-end services can be delivered per unit of NFV infrastructure, as illustrated in Figure 2. Higher efficiency also translates to lower costs. Once end-to-end services become low enough, Scale-Out use cases become viable.

The challenge then becomes how to drive costs low enough to scale to the needs of the largest operators. Typically, individual VNFs are instantiated and scaled in one or more VMs, with network-layer services chained together to implement end-to-end services. While this approach works well for Scale-Up use cases, it is prohibitively expensive for Scale-Out use cases, which require low overhead and much more granular slices of the CPU than a VM.

Alternative methods to the “One VNF per VM” model are required to enable operators to address Scale-Out vCPE use cases. Innovative solutions leveraging containers are beginning to emerge, which allow multiple VNFs to be service-chained into personalized NanoServices capable of being deployed to thousands and even millions of subscribers.

Many of the world’s largest and most innovative operators – including AT&T, China Mobile, CableLabs, COLT, Cox Communications, du (UAE), Orange, NTT, Telefónica – are taking the next step and beginning to share their plans for virtualized CPE.

Another proof point is a highly visible, multi-vendor vCPE PoC underway (TMForum Catalyst project), aptly named “Operations Transformation and Simplifications Enabled by vCPE.” It is driven by AT&T, Orange, and Telecom Italia, along with Juniper, Ericsson, Cisco, and Alcatel-Lucent. Efforts to containerize NFV and drive an order-of-magnitude cost reduction for NFV containers will no doubt yield wide-scale deployment.

In the next article we will examine the Scale-Out use cases more closely, as vCPE rapidly evolves.