It should be noted that Virtual Packet Core (VPC) is what mobile operators deploy, making VPC an NFV use case. However within VPC mobile operators have more specific use cases depending on what services they provide. Here is the list of some common functions that are becoming candidates for virtualization within the packet core:

Services they sell to their end customers (Enterprise or Non-enterprise) could also be considered use-cases for NFV.

In order to come up with an NFV architecture that will meet all the requirements for virtualizing the mobile packet core, it is imperative that we first understand and capture all the requirements of the mobile services and applications running on the top of the mobile packet core.

Figure 3: Elements of a Mobile Network

The typical mobile operator’s network consists of multiple networks such as Radio Access Network (RAN) Backhaul where the subscribers connect to over the radio, which then gets aggregated to the IP/NGN network to which the mobile packet core is connected to in the regional or national datacenter. This is shown in Figure 3. Common IP services such as DPI, NAT, DNS etc could be dedicated and part of the mobile packet core or a shared infrastructure that the SP is leveraging for other non-mobile services that they may be offering. Figure 4 exposes the components that make up the Evolved Packet Core(EPC).

Figure 4: Evolved Packet Core (EPC) components

The mobile or User Equipment (UE) connects to the network over the eNodeB. The connection terminates on the PDN Gateway (PGW). MME, Home Subscriber Server (HSS) and SGW are other important components in establishing connection and providing subscriber services and make up the evolved packet core. Based on a couple of technical and business factors, we have seen two types of deployments:

The NFV architecture needs to take the above two models into account. In the 2nd case where one or more components may be distributed, the underlying infrastructure design including OpenStack will be impacted. This is referred to as Distributed NFV (D-NFV). If only some 3gpp functions are placed in the regions/edge, we may chose to deploy on compute nodes in that region as long as the latency is below the latency threshold of OpenStack and application control plane. These compute nodes may be integrated with storage and deployed as Hyper Converged Infrastructure (HCI). In some cases, a smaller deployment of OpenStack may be used in these regions. This raises a lot of design questions regarding shared identity (Keystone) and images (Glance).

VPCs may be deployed in many different ways:

VNF vendors tend to bundle combinations of the above services based on functional requirements of operators. These combinations could lead to varying deployment models all the way from the number of VMs to HA, scale, traffic mix and throughput requirements.

Depending on the type of service(s) being deployed the VNFs may be deployed in one of the following ways:

The Internet facing interface of the GGSN (3G gateway) is referred to as “Gi” in 3GPP specifications (Known as “SGi” in 4G/LTE network). This is shown in Figure 5. As the packet leaves the gateway (GGSN/PGW), it no longer has context of the subscriber. It is a pure IP packet. IP services such as DPI, Parental Control, Video Optimization, Web Optimization, URL filtering/enrichment, Firewall and NAT are applied to the IP packets as they leave the mobile network towards the Internet. Since these services reside on the Gi/SGi interface they are commonly referred to as “GILAN” services. These services typically are deployed in some combinations and form a logical chain.

Figure 5: GiLAN Services in mobile core (Source: IETF 87, Walter Haeffner)

Most mobile operators offer some variation of GiLAN services but restrict it to APN granularity rather than subscriber level. This is because traditional GiLAN services required physical connections to form the chain.

Today’s solution uses Software Defined Networking (SDN) to create logical chains between GiLAN elements. The actual application runs in a virtual environment typically on top of OpenStack rather than purpose built appliances. This offers a huge advantage - applications can scale based on demand and conversely shrink. A classic example of this would be when people return from work and turn on their TV or Over The Top (OTP) video (Netflix, Amazon etc). This creates a surge in traffic and creating a demand on GiLAN elements.

From an infrastructure point of view, GiLAN will closely resemble the vEPC VNF. It will have the same requirements of Orchestration, VNF lifecycle management, performance and security. Additionally GiLAN will require:

VoLTE utilizes the IP Multimedia Services (IMS) in the core of the mobile network. IMS is also used by SPs to offer non-mobile voice service including High Definition (HD) Voice, Video Calling, Wi-Fi Calling, Messaging Services etc. IMS consists of several components that traditionally were hardware appliances that got virtualized and deployed in the cloud by NEPs and Telcos. These include:

Figure 6 shows details of the IMS architecture. From a NFV and virtualized IMS point of view, the requirements would be a very similar to vEPC application. There are no special SFC or dynamic grown and shrink requirements. However, attention has to be paid to packet size and latency as this application is primarily used for delivery high quality voice for VoLTE and non-mobile voice and multimedia services.

Figure 6: IMS Architecture (Source: http://ipv6.com/articles/general/IP_IMS.htm)