Virtual EPC Overview

STUDENT BOOK
LZT1381721 R3A

LZT1381721 R3A
 Virtual EPC Overview

DISCLAIMER

This book is a training document and contains simplifications.

Therefore, it must not be considered as a specification of the
system.

The contents of this document are subject to revision without

notice due to ongoing progress in methodology, design and
manufacturing.

Ericsson shall have no liability for any error or damage of any kind
resulting from the use of this document.

This document is not intended to replace the technical

documentation that was shipped with your system. Always refer to
that technical documentation during operation and maintenance.

© Ericsson AB 2017

This document was produced by Ericsson.

• The book is to be used for training purposes only and it is

strictly prohibited to copy, reproduce, disclose or distribute it in
any manner without the express written consent from Ericsson.
This Student Book, LZT1381721, R3A supports course number
LZU1082264.

-2 - © Ericsson AB 2017 LZT1381721 R3A

Table of Contents

Table of Contents

1 INTRODUCTION ................................................................................7

1 INTRODUCTION ..............................................................................8

1.1 VEPC - SUPPORTING KEY NETWORK SERVICES .....................8

1.2 OVERVIEW - THE EPC NETWORK ..............................................9

1.3 VIRTUALIZATION ........................................................................10

2 VEPC NETWORK ...........................................................................16

2.1 CLASSICAL IMPLEMENTATIONS............................................... 16

2.2 FROM HARDWARE INTEGRATED TO CLOUD/TELCO DC

DEPLOYMENT .....................................................................................17

2.3 HYBRID NETWORKS ..................................................................17

2.4 VEPC FUNCTIONALITY & FEATURES ....................................... 18

2.5 MAIN VEPC CHALLENGES ........................................................19

3 VIRTUAL EPC ................................................................................25

3.1 VEPC VALUE PACKAGES ..........................................................26

3.2 ONE NETWORK – MULTIPLE INDUSTRIES .............................. 27

3.3 BENEFITS OF ERICSSON’S VEPC ............................................ 27

3.4 VEPC CLOUD SUPPORT ERICSSON AND 3RD PARTY

EXECUTION ENVIRONMENTS ...........................................................28

3.5 OUR NFV OFFERING OPTIONS .................................................29

3.6 THE SPEED CHALLENGE FROM OPPORTUNITY TO

LAUNCHED SOLUTION.......................................................................30

3.7 ERICSSON TTM UNIQUENESS TAKING A HOLISTIC

APPROACH .........................................................................................30

3.8 SERVICE FLEXIBILITY EPC VIRTUAL NETWORK

SERVICES ...........................................................................................31

3.9 SEAMLESS & SECURE INTRODUCTION................................... 31

LZT1381721 R3A © Ericsson AB 2017 -3 -

 Virtual EPC Overview

3.10 VEPC – OPTIMIZED WITH FLEXIBILITY .................................. 32

4 SUMMARY .....................................................................................32

2 VEPC COMPONENTS AND ARCHITECTURE ............................... 33

1 INTRODUCTION ............................................................................34

1.1 ETSI NFV CLOUD REFERENCE ARCHITECTURE .................... 34

1.2 SERVICE MODELS .....................................................................38

1.3 VIRTUAL MACHINES ..................................................................40

1.4 A POD AND ITS SOFTWARE ......................................................40

1.5 HYPERVISOR AND ERICSSON VIRTUAL SWITCH ................... 42

1.6 STORAGE ...................................................................................42

1.7 CEE HIGH AVAILABILITY ...........................................................43

1.8 BACKUP AND RESTORE ............................................................43

2 VIRTUALIZED EPC VNF DESCRIPTIONS ..................................... 43

2.1 VEPC ARCHITECTURE PRINCIPAL ........................................... 43

3 VEPC DEPLOYMENTS ..................................................................53

3.2 HOW TO DEFINE BILL OF MATERIAL FOR VEPC

SCALABLE DEPLOYMENT..................................................................57

3.3 WHAT IS VEPG? .........................................................................58

3.4 WHAT IS VSGSN-MME? .............................................................62

3.5 WHAT IS VSAPC? .......................................................................68

3.6 VWMG .........................................................................................73

4 COMMANDS IN ECM AND CCE ....................................................76

4.1 FUEL............................................................................................76

4.2 CEE .............................................................................................76

4.3 EXAMPLES OF SOME OF THE AVAILABLE COMMANDS:........ 78

5 SUMMARY .....................................................................................80

3 VEPC IMPLEMENTATION............................................................... 83

-4 - © Ericsson AB 2017 LZT1381721 R3A

Table of Contents

1 INTRODUCTION ............................................................................84

1.1 DEPLOYMENT OPTIONS ...........................................................84

1.2 INTERNET OF THINGS ...............................................................86

1.3 DISTRIBUTED MBB ....................................................................90

1.4 VIRTUAL ENTERPRISE ..............................................................97

1.5 MBB VNS ...................................................................................103

1.6 COMMUNICATION .................................................................... 109

2 SUMMARY ...................................................................................113

4 ACRONYMS................................................................................... 115

5 INDEX ............................................................................................ 117

6 TABLE OF FIGURES ..................................................................... 119

LZT1381721 R3A © Ericsson AB 2017 -5 -

 Virtual EPC Overview

Intentionally Blank

-6 - © Ericsson AB 2017 LZT1381721 R3A

Introduction

1 Introduction

Objectives

Upon completion of this chapter, the student will be able to:

› Identity the Evolved Packet Core Network
› Differentiate the vEPC Control Plane and User Plane
› Discuss the vEPC Solution
› Recognize the benefits of vEPC solution

Figure 1-1: Objectives

LZT1381721 R3A © Ericsson AB 2017 -7 -

 Virtual EPC Overview

1 Introduction
Ericsson is industrializing Network Function Virtualization (NFV) for improved
deployment flexibility, built for the most demanding environments. Ericsson
virtual Evolved Packet Core provides tested and validated solutions addressing a
large number of vertical use-cases thereby opening up new operator
opportunities.

Operators are looking for ways to increase capacity, coverage and at the same
time ensure that their businesses KPIs are met. They are demanding a better
environment for innovations to be able to try out and to accelerate the
introduction of new services at a lower total cost of ownership. They want
efficient networks and operations where services can be deployed quickly and
effortlessly while having the tools to deploy and offer new services.

The benefits of Ericsson virtual Evolved Packet Core include all the benefits of
NFV, but with the Ericsson differentiation – a complete end-to-end solution,
meaning virtualization of all Evolved Packet Core components. We support
flexible deployment of a whole range of virtual network services enabled by
vMME, vSGSN, vPGW, vSGW, vGGSN, vPCRF, vDPI, vProbe, vePDG and
vTWAG. We provide full feature compatibility with classical Evolved Packet
Core, maintaining our leadership with best in class compatibility with
surrounding systems from devices and RAN to charging systems and services.
Classical and virtual network nodes will coexist seamlessly in areas such as pool,
geo redundancy and load sharing.

1.1 vEPC - Supporting key network services

MBB vEPC Distributed Enterprise Communication Internet of Things
MBB
› Full support for › Full support for › Dedicated › Full support › Full NB-IoT, Cat-
MBB services local MBB enterprise VoLTE and M & EC-GSM
services instances Wi-Fi calling support
› Hybrid
networks › Auto- › Service › Leading device › Full roaming
configuration automation compatibility
› Scalability /
› Dedicated IoT
VNF › Local breakout › Private LTE › Speed with instance
and local operational
mobility mgmt flexibility

Making new revenue opportunities possible

Figure 1-2: Virtual EPC Network Services

-8 - © Ericsson AB 2017 LZT1381721 R3A

Introduction

The vEPC network services are:

• Internet of Things
• Distributed Mobile Broadband
• Enterprise
• Communication
• Mobile Broadband

1.2 Overview - The EPC Network

SGW (Serving Gateway)
It acts as the mobility anchor for the user plane during inter-eNodeB handovers
and is the Anchor for mobility between LTE and other 3GPP technologies
(terminating S4 interface and relaying the traffic between 2G/3G systems and
PGW).

For idle state UEs, the SGW terminates the downlink data path and triggers
paging via the MME when downlink data arrives for the UE. SGW terminates the
interface towards E-UTRAN and MME.

PGW (PDN Gateway), GGSN (Gateway GPRS support node)

Provides connectivity from the UE to external packet data networks (Internet) by
being the point of exit and entry of traffic for the UE.

It performs policy enforcement, packet filtering for each user, charging support.

PGW act as the anchor for mobility between 3GPP and non-3GPP technologies
like Wi-Fi. PGW terminates the SGi interface towards the PDN.

High amount of Control plane traffic is terminated in SGW as it is related to

idle/active signaling.

PCRF – Policy and Charging Rules Function

OCS – Online Charging System

LZT1381721 R3A © Ericsson AB 2017 -9 -

 Virtual EPC Overview

Figure 1-3: Overview - The EPC Network

1.3 Virtualization
Operators have realized the potential of using new technologies in building and
running their networks. The primary purpose is to reduce costs, and also to
shorten product release cycles to enable quicker roll-out of new services. This has
led to the establishment of Network Functions Virtualization (NFV) and the
formation of the Network Functions Virtualization Industry Specification Group
(NFV ISG) in ETSI.NFV opens for horizontal integration of Network Functions
in operator’s networks. In particular it allows using so called Commercial-off-
the-Shelf (COTS) hardware, where the same hardware can be used across a
multitude of network services. It also allows for large scale and small scale
deployments of those services.

NFV allows a flexible and aligned way to manage many, or possibly all, services
deployed by an operator. Use cases include simple management of initial
deployment, start, stop, scaling and moving applications within its environment,
to adapt to capacity needs and other dynamic aspects of the network.

A key technology in NFV is Virtualization, where one piece of physical hardware

can be instantiated into many virtual instances.

Certain common architectural guidelines are needed to make NFV possible. This
is what the ETSI NFV ISG group is specifying.

- 10 - © Ericsson AB 2017 LZT1381721 R3A

Introduction

1.3.1 Concepts in virtualization

Hardware virtualization is essential, but a Cloud System is needed paying
attention to:

• Automated way to manage virtualized resources.

• Geographic redundancy.
• Isolation of tenants.

App 1 App 2 App 3

OSApplication
OS OS

Hypervisor

› “Hardware virtualization or platform virtualization refers to the creation of a

virtual machine that acts like a real computer with an operating system.
Software executed on these virtual machines is separated from the underlying
hardware resources” –Wikipedia page on Virtualization

Figure 1-4: Hardware Virtualization

In the Picture above the Hypervisor is the software that creates and runs virtual
machines on the host hardware.

vMME is an application which is running using a specific Operating System (OS).

1.3.2 Virtualization and Cloud

Figure 1-5: Virtualization and Cloud

LZT1381721 R3A © Ericsson AB 2017 - 11 -

 Virtual EPC Overview

1.3.3 Benefits of virtualization

› In some respects our functions

are “chained” to the platforms we
have implemented them on
EPG
› Virtualization is a technology that
can help break that tie

› We will however continue to

supply functions integrated with
their HW for a long time to come

Figure 1-6: Benefits of virtualization – Freedom

The benefits of virtualization are:

• The freedom to untie the function to implement from a specific
platform.
• New combinations:
Virtualization enables the creation of new functions
o MSPEPG (MSP+EPG)
• Of new optimizations
o Co-locating HSS with EPG
o SAPC with EPG
• Easier reuse
• More….

- 12 - © Ericsson AB 2017 LZT1381721 R3A

Introduction

1.3.4 Ericsson Cloud System

Enabling the Real-time Cloud:

› - Telecom Grade
› - Real-time optimizations
› - Distributed
› - Cloud manager integration
› - SDN & network services
› - Open environment based on Openstack
› - Both Ericsson & 3rd party hardware

Figure 1-7: Ericsson Cloud System

1.3.5 NFV
What is NFV?

It’s Network Function Virtualization.

• Operator initiated working group formed in the European
Telecommunications Standards Institute (ETSI).
• Goal: Evolving standard IT virtualization technology to
consolidate many network equipment types onto industry
standard high volume servers, switches and storage
• Members include

› Operators like:
AT&T, BT, DT, DoCoMo, FT, Sprint, Verizon

› Equipment suppliers like:

Cisco, Ericsson, Huawei, IBM, Intel, HP, and Oracle

LZT1381721 R3A © Ericsson AB 2017 - 13 -

 Virtual EPC Overview

1.3.5.1 Vision of ISG NFV

Figure 1-8: Vision of ISG NFV

Open source NFV Objectives

• Speed up implementation of NFV
• Create a carrier grade Open Source Ecosystem
• Focus on Open Community which has wide industry support
• Focus on Open Framework to allow the plug and play of
different implementations
• Try to build upon existing Open Source Foundations
• E2E reference implementation for plug-play of functional
components
› Components may be open source (e.g. OpenStack,
CloudStack)
› Components may be proprietary

1.3.5.2 ETSI model of the NFV architecture

The ETSI specified Architectural Framework is shown in Figure below. It

illustrates which building blocks vendors can choose to implement in order to
provide “NFV compatible products”.

- 14 - © Ericsson AB 2017 LZT1381721 R3A

Introduction

OSS-RC
vEPC as one or ECM
more VNFs –
vSGSN-MME,
vEPG, vSAPC,
vWMG

CEE

Figure 1-9: ETSI NFV Ref Architecture Ericsson Product Mapping

The ETSI NFV group has also proposed an NFV Management and Orchestration
(MANO) architecture that addresses the operational lifecycle needs of VNFs as they are
deployed in the cloud. That is the dotted box on the right in the figure. Achieving and
validating interoperability at critical reference points within the MANO-model and
towards the outside is the key focus for the ongoing ETSI work.

1.3.5.3 VMware Cloud

Many operators have the requirement to run their Telco applications in the cloud using
VMware.

Ericsson OSS-RC, ENM

vEPC as one or
more VNFs –
vSGSN-MME,
vEPG, vSAPC,
vWMG

vSphere
(ESXi) vCenter

Figure 1-10: ETSI NFV Ref Architecture VMware vCloud Product Mapping

1.3.5.4 VMware Deployment

vEPC has been validated on VMware in single VNF and vEPC Compact Deployments.
Default format is VMDK for all vEPC VNFs. vEPC has been deployed on VMware using
the OVF files generated by scripts provided by the VNF or by OVF files provided for

LZT1381721 R3A © Ericsson AB 2017 - 15 -

 Virtual EPC Overview

Compact Deployment. vEPC has been validated utilizing the following VMware
components (NFV role within parenthesis):

• vCenter (VIM)

• vSphere (NFVI)

- Hypervisor ESXi
- Virtual Distributed Switch, VDS

2 vEPC Network

2.1 Classical implementations

Figure 1-11: vEPC Architecture Classical implementations

- 16 - © Ericsson AB 2017 LZT1381721 R3A

Introduction

NBI
NC TP LB DB

Platform
NBI
NBI
NC AP/DP FS SC TP LB DB
LB
EBS
TSP -> CBA
SGSN-MME EPG
SAPC
NBI
CP PP
NM
SSR
LB

Figure 1-12: vEPC Architecture Classical implementations

2.2 From Hardware integrated to Cloud/Telco DC deployment

So far, separate VNF per node type

VNF VNF VNF

vSGSN-MME vEPG vSAPC

SAPC
SGSN-MME

EPG

• Integrated SW & HW • SW & HW decoupling

• Limited deployment flexibility • Reduced CAPEX and OPEX
• Fast introduction of new VNFs
• Well proven - High availability! • Better scalability (even automated)
• Rich feature set
Operators’ expectations

Figure 1-13: From Hardware integrated to Cloud/Telco DC deployment

2.3 Hybrid Networks

Both the native and virtual networks co-exist and also can be part of the single
solution.

LZT1381721 R3A © Ericsson AB 2017 - 17 -

 Virtual EPC Overview

› Full support for a mix of SGi Roaming OSS Charging BSS CS HSS/HLR AAA

native and virtualized nodes

Ericsson EPC and vEPC
› Common Ericsson SGSN-MME
pools supported
› Common OSS solution
vMM vPCR
vPCR vBPC
vSGS
› Maintaining full SACC N E FF F
SGSN
functionality with service and MME
integration compatibility SGSN-
MME SAPC EPG vSGS vPG
SGW
N- vSG vPG
WW
vDPI
vDPI
vDPI PGW
MME W
PCRF
› Full external compatibility
with 3GPP interfaces

› Maintained market leading CDMA GSM HSPA LTE Wi-Fi Devices

compatibity with Radio
access and devices

Figure 1-14: Hybrid Networks

Common OSS-RC/ENM Orchestration › Leveraging and protecting

O&M
previous investments in
Native nodes

› Statefull redundancy
EBS/MkVII EBS/MkX EBS/MkX COTS COTS
I Native Native Native Virtual Virtual between native and virtual
SGSN-MMEs

› Functional parity and

interworking is supported
Common pool with during transformation
full interworking
to Cloud
L2/L3 and functional
parity

› Support for large scale

deployments

Figure 1-15: SGSN-MME interworking between Native and Virtual

2.4 vEPC Functionality & Features

General principles

• Same feature set & logic for virtualized and non-virtualized EPC

• No impact on surrounding network nodes

• No impact on EPC-to-device communication

• 3GPP-compliant multivendor support

- 18 - © Ericsson AB 2017 LZT1381721 R3A

Introduction

Datacenter
DataCenter vEPC MBB,
vEPC IoT
Enterprise,
Communication
› Same feature set & logic Existing
for virtualized and non- MBB
Service
virtualized EPC
› No impact on surrounding PCRF
GW
vEPG vSAPC

GW

network nodes GW

› No impact on EPC-to- vSGSN-

MME GW
vEPG
vSAPC
v PCRF

device communication SGSN

-MME
SGSN
-MME

› 3GPP-compliant
multivendor support

Figure 1-16: vEPC Functions

2.5 Main vEPC challenges

The main vEPC challenges are:

• Availability
• Performance
• NW separation
• Security and Integrity
• Cloud Agnostics

LZT1381721 R3A © Ericsson AB 2017 - 19 -

 Virtual EPC Overview

2.5.1 Implementation Main challenge #1 - Availability

› Combination of Application and Cloud system features

› Application & Network

– Pooling, inter-site failovers
– Session replication and failovers
– Load balancing / dispatching App Cluster App Cluster

VM

VM
VM

VM

VM
VM
VM
VM
› Cloud Virtualization Virtualization

– No single-point of failure

Host
Host
Host
Host

Host
Host
Host
Host
– Host supervision
– VM migration (not 15A)
Resource Resource
– Affinity & anti-affinity Cluster Cluster

– Automatic networking

Figure 1-17: Implementation Challenge #1 – Availability

2.5.1.1 High Availability

Inter-VNF redundancy in for example. Active/active or
Network active/standby mode.
Pooling Load sharing Geo Redundancy level Throttling settings limiting VNF failure impact on the
network.

Intra-VNF redundancy for VM failures.

vEPG vSGSN-MME Application aware state replication with 1+1
EPC VNF and n+1 failover schemas.
vSAPC vWMG
SW failures and fast switchovers within VNFs

VM’s VM’s VM deployment with anti-affinity rules and availability

Compute/Storage/ Compute/Storage/
Networking
Execution zones
Networking
Environment Automatic VM restarts/re-allocation
Hypervisor OpenStack hitless upgrade/update
Tenant isolation

Servers vSwitch,ToR, Server restarts and failure detection,

Routers Hardware Fault tolerant storage,
Storage HW NIC/ToR/DC-GW redundancy

Figure 1-18: VEPC – High Availability

Division of Responsibility
The vEPC principles of High Availability are:

• EPC physical application level mechanisms for fast failover between boards/VMs are
kept also in cloud deployments
• Network level redundancy and load sharing can be utilized with a mix of physical and
virtual network functions
• Maintaining existing Stateful failover behavior also in a virtual environment, both intra-
VNF and inter-VNF

- 20 - © Ericsson AB 2017 LZT1381721 R3A

Introduction

The benefits of these principles are:

• No noticeable service impact on end users even in rare outage scenarios.

• Extremely high availability of services to end users and business partners is assured.

Network Level: Geo redundant network level features (like Geo-Redundant Pool) with
inter-site and inter cloud region redundancy; Failures and fast switchovers between sites
(ICR); Load balancing across Sites/cloud regions; Gateway blacklisting; Traffic Storm
Protection; Smart Signaling Throttling and UE signaling Control.

EPC VNF: Intra-VNF redundancy for VM failures; Application aware state replication with
1+1 and NN+1 failover schemas; Software failures and fast switchovers within VNFs. VNF
Resilience and redundancy handling are independent of Hardware failure notifications from
the virtualization and infrastructure layers. Instead, the application components (VMs,
processes, etc.) are supervised by internal VNF logic and recovery actions are triggered
when needed.

Execution Environment: VM deployment with anti-affinity rules; Automatic VM

restarts/reallocation; Tenant isolation;

Hardware: Server restart and failure detection; Fully redundant Hardware infrastructure; No
single point of failure for compute, networking (e.g. NIC/ ToR/ BGW) or storage; Failures
in Hardware and Software appear as lost VM’s to VNFs

2.5.1.2 MME NW-Level Session continuity (Geo-redundant Pool)

Operations Efficiency
High Availability
› Geo-Redundant Pool & Pooling IOT IMS
– Maintains session continuity
– No impact on Radio network, Standard S1
compliant
GW
› Session Continuity, if problem with
– S1
– MME
– S11

› Supports multitude of deployment scenarios MME MME

– Native only
– Virtual only
– Mixed native and virtual deployments

Benefits eNB
Virtually no service impact on end users even
in FULL outage scenarios within a data center

INNOVATION

Figure 1-19: MME NW-Level Session continuity (Geo-redundant Pool)

• During normal operation the MME shall save copies of its UE

contexts in other MME in the pool.

LZT1381721 R3A © Ericsson AB 2017 - 21 -

 Virtual EPC Overview

• When the Serving MME goes down, another MME in the pool
can take over the UE by retrieving the UE context backup from
the Backup MME.
• Re-attach is not needed. The UE’s SIP sessions and other
services are still valid.
• The stored backup of the UE context can be used also at other
failure situations, e.g., S11 link failure and S1 link failure.
• End-2-end feature requiring support in GW

2.5.1.3 MME NW-LEVEL Session continuity (Geo-redundant Pool)

Key message – no re-attach needed if problem with S1 or S11 links.

Also covers a MME failure scenario.

It is possible to replicate from MME to MME (within a pool).

Also possible to divide a pool into” sub-pools” (i.e. a member of one sub-pool
will only replicate to members in the other” sub-pool”)

Replication is always done only from one MME to other MME

› Minor impact on GW
– CPU (below 10%)
– Bandwidth (below 70 Mbit/s at 3.7 MSAU) S11

› Geographical redundancy across multiple

sites. User data
is replicated
MME MME

S1

eNB

Figure 1-20: MME NW-LEVEL Session continuity (Geo-redundant Pool)

- 22 - © Ericsson AB 2017 LZT1381721 R3A

Introduction

2.5.1.4 GW Inter-site redundancy

› Seen as one entity from the rest of the network

Ericsson leadership
› Fast switch-over from active VNF to standby VNF with state persistence
in
– Sub 500ms, depending on network architecture and routing convergence time
mobile/fixed operator
– Support VoLTE service with site failures
networks and
› Can operate over IP network with BGP and BFD for failoverservices

2G vEPG
Charging
Gb System

Iu SGSN- GW
3G Gn,S11
MME
IP
S1-MME IP PCRF
S1-U
LTE
S2a
GW’
Sync protocol over UDP
WiFi/CDMA

Note: P-GW added during 2015

Figure 1-21: Gateway Inter-site redundancy

NOT fully supported in vEPG, check the latest Product CPI.

2.5.2 Implementation Main challenge #2 - Performance

› Low latencies a strict requirement on the cloud system
› Capacity scaling through a combination of Application and Cloud
mechanisms Capacity limitations in OVS.
EVS included in PoC from
› User plane I/O throughput - the main challenge January. Proven ~x15
performance improvements.
›DPDK for packet processing acceleration

VM VM VM VM VM VM
SRIOV DPDK DPDK DPDK vSwitch DPDK DPDK DPDK
Driver Driver Driver Driver Driver Driver

vSwitch
Hypervisor
Hypervisor

SR-IOV enabled NIC NIC

Hardware Hardware

› Bypassing the hypervisor › OVS performance optimizations needed

› Requires specific HW support › Less HW dependencies
› Disables multiple cloud use cases › Supports all cloud use cases

Figure 1-22: Implementation Challenge #2 – Performance

LZT1381721 R3A © Ericsson AB 2017 - 23 -

 Virtual EPC Overview

2.5.3 Implementation Main challenge #3 – Network separation

› It must be possible to separate traffic over different interfaces and

networks
› Separation of large number of PDNs in vEPG – the main challenge

VM VM VM
Driver Driver Driver
vNIC

vNIC
vNIC

vNIC
Hypervisor Hypervisor Hypervisor

NIC NIC NIC

Hardware Hardware Hardware

GRE
... VLAN
... ...
› One VLAN per VNIC › Multiple VLAN per VNIC › Using GRE over LAN
› Max 8 VLAN per VM › Requires non-standard › Separation is done on
additions to OpenStack application level
› Not supported in CEE 15A › Only GRE/IPv4
› A fair amount of configuration

Figure 1-23: Implementation Challenge #3 – Network separation

2.5.4 Implementation Main challenge #4 – Security & Integrity

› Multiple logical networks per VM

– Corporate services O&M LI

– Multiple interfaces from each vEPC node

EPG SGSN-
RAN MME EPG

› Multi-tenancy
MSS, HSS
EPG EPG HLR

› LI, data integrity, DoS...

– TLS planned towards LI-IMS

Figure 1-24: Implementation Challenge #4 – Security & Integrity

- 24 - © Ericsson AB 2017 LZT1381721 R3A

Introduction

2.5.5 Implementation Main challenge #5 – Cloud Agnostic

CMS 1 CMS 2

VM VM VM VM VM VM

Infrastructure Infrastructure
controller 1 controller 2
Hypervisor 1 Hypervisor 2

Hardware 1 Hardware 2

• OpenStack (CEE, Redhat…), VmWare, …

• Management, e.g. OVF extensions
• Networking, e.g. MAC/IP-address assignment, jumbo frames NW separation, …
• Execution, e.g. affinity/anti-affinity, CPU pinning, …

Figure 1-25: Implementation Challenge #5 – Cloud Agnostic

3 Virtual EPC

Figure 1-26: Ericsson vEPC NFV compliant architecture

VNF is a virtualized network function that is a network element deployed in a

virtualized environment for example, vSGSN-MME, vEPG, vSAPC and vWMG.
Those VNFs are part of the vEPC in the Ericsson solution.

LZT1381721 R3A © Ericsson AB 2017 - 25 -

 Virtual EPC Overview

3.1 vEPC value Packages

Secure the Increase
Drive Cost Capture
Smart Device Coverage &
Efficiency New Revenue
Business Capacity
Data User Experience Spectrum Management Network Efficiency Voice & Data Evolution

Voice Performance Capacity Evolution Operations Efficiency New Service Opportunities

Smartphone Efficiency Coverage Expansion Network Mgmt Enhancement Revenue Optimization

This presentation will mainly address these customer needs

Figure 1-27: Virtual EPC

There are four vEPC value Packages:

• Secure the Smart Device Business
• Increase Coverage & Capacity
• Drive Cost Efficiency
• Capture New Revenue

The functions listed below will be part of this presentation.

The driving forces behind vEPC are the market needs and the benefits of NFV.

NFV benefits:
• Speed to business and efficiency.

Market needs, listed below as customer comments:

• “How can I create a better environment for innovations in the
enterprise space?”
• “I need a radically simplified network”
• “Today it can take 6-10 months to introduce new services”
• “MBB in rural areas – yes, but we need to enhance user
experience and reduce the transport costs”

- 26 - © Ericsson AB 2017 LZT1381721 R3A

Introduction

3.2 One network – multiple industries

Figure 1-28: One network – multiple industries

• It avoids industry specific spectrum allocation.

• Connectivity network is available for “all” use cases (avoid
dedicated systems).
• It allows service innovation.
• It is eco-system friendly (standardized key interfaces).

3.3 Benefits of Ericsson’s vEPC

The benefits of Ericsson‘s virtual EPC include all the benefits of NFV, but with
Ericsson differentiation – a complete end-to-end solution, meaning virtualization of all
EPC components with full feature compatibility with classical EPC.

Ericsson has a complete Virtual EPC portfolio commercially available since Q4 2014. It
enables an unprecedented scalability and flexibility from small-scale local deployments
to large-scale datacenter deployments. This means that Virtual EPC can be deployed in
large centralized datacenters but also distributed close to the radio network.

Ericsson provides full feature compatibility with classical EPC. This means Ericsson
will maintain the Evolved Packet Core leadership with best in class compatibility with
surrounding systems from devices and RAN to charging systems and services. Classical
and virtual network nodes will coexist seamlessly in areas such as pool, geo redundancy
and load sharing.

LZT1381721 R3A © Ericsson AB 2017 - 27 -

 Virtual EPC Overview

Providing flexibility &

innovative network
services with fast time
to revenue
› Fast time to service with
virtual network services

› Complete virtual EPC with

extensive cloud support

› Telecom grade KPIs and

characteristics

› Global services
organization

Figure 1-29: Benefits of Ericsson’s vEPC

Building on the market leading EPC applications Ericsson provides smooth, seamless
migration paths with unique features across legacy and virtualized network nodes. The
goal is to support simplified operations and fast time to service for the network services.

Ericsson’s Virtual EPC is supported on Ericson Cloud System but also on

validated 3rd party execution environments.

3.4 vEPC Cloud support Ericsson and 3rd party execution

environments

Ericsson Cloud System - Support Flexibility for additional

execution environments
OSS

3rd party Ericsson

Ericsson applications vEPC Ericsson vEPC
Cloud
3:rd
Manager Virtu
Internet Dist Communication Virtual
al
Of Things MBB Enterprise Party
Common virtual appliances Enter
Cloud
prise
Mgr

Ericsson Cloud Execution Environment

Based on Openstack
Validated on 3:rd party
execution environments
Ericsson & 3rd party hardware
3rd party hardware

Network

Data
Center

Figure 1-30: vEPC Cloud support -Ericsson and 3rd party

- 28 - © Ericsson AB 2017 LZT1381721 R3A

Introduction

3.5 Our NFV Offering Options

Flexibility Pre-integration

Ericsson 3rd party Ericsson 3rd party Ericsson 3rd party

VNF’s vApp VNF’s vApp VNF’s vApp

3rd party Mirantis, ECEE, OPNFV Ericsson & Partner

Cloud System SW VMWare, Redhat, … Cloud System SW

3rd party Dell, HP,… Ericsson & Partner

hardware hardware

VNF Software Validated System Certified System

Main differences between the offerings are on commitments where several

of these can be addressed by advanced System Integration Offerings.
› Performance
› Life Cycle Management
› Customer support

Figure 1-31: Our NFV Offering Options

Figure 1-32: Flexibility in deployment

LZT1381721 R3A © Ericsson AB 2017 - 29 -

 Virtual EPC Overview

3.6 The speed challenge from opportunity to launched solution

(rough scale)

Today 6-10 Months

NFV Few Months

Ericsson
Days
vEPC

Addressing the full challenge

Significant time to service reduction
Figure 1-33: Speed challenge -Opportunity to launch

NFV:
• Over-capacity required.
• Features needs to be available and verified.
• Application (VNF) needs to be available and verified.
• Optimal way of deploying multiple types of application a
multitude of times.

3.7 Ericsson TTM uniqueness taking a holistic approach

Figure 1-34: Ericsson TTM uniqueness taking a holistic approach

- 30 - © Ericsson AB 2017 LZT1381721 R3A

Introduction

3.8 Service flexibility EPC Virtual network services

› Fast Time to service with pre-validated network services

› vEPC introduction where service agility, flexibility, multi-instance and

scaling is most beneficial

› Market leading feature set

› Service awareness and OSS/BSS integration compatibility

Figure 1-35: Service flexibility EPC Virtual network services

3.9 Seamless & Secure Introduction

› Supporting a seamless migration, a
mix of classical and virtualized
nodes:
– - Common Ericsson SGSN-MME
– pools supported
– - Advanced GW selection and traffic
– distribution across virtual and native
– nodes
– - Common OSS solution
– - Maintaining full SACC functionality
– with service and integration
– compatibility

› Full external compatibility with 3GPP

interfaces.

› No impact on Radio access or

devices .

Figure 1-36: Seamless & Secure Introduction

LZT1381721 R3A © Ericsson AB 2017 - 31 -

 Virtual EPC Overview

3.10 vEPC – Optimized with flexibility

› Support for decomposition into well defined functional blocks with full featureset

› EPC control plane

Shared (simplicity) or separated DB (flexibility) for policies.
Shared (performance) or separated mobility (separations of concern) states in
SGSN-MME.

› EPC user plane

› Optimized payload path with single hop providing up to 3X performance.
› Maximized flexibility with multliple VNF traversals and LB, keeping separations
of concern.
› SDN based service chaining for value added services can be combined with
either option.

Figure 1-37: vEPC – Optimized with flexibility

As a summary, vEPC:

• Meets the needs of industry verticals with Virtual EPC

Network services.
• It is the market-leading EPC applications meeting time to
service with unique features and a holistic approach.
• It is the complete cloud offering including leading services
organization.

4 Summary

Upon completion of this chapter, the student should now be

able to :
› Identity the Evolved Packet Core Network
› Differentiate the vEPC Control Plane and User Plane
› Discuss the vEPC Solution
› Recognize the benefits of vEPC solution
Figure 1-38: Summary

- 32 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

2 vEPC Components and Architecture

Objectives

Upon completion of this chapter, the student will be able to:

› Identify the main elements of the Cloud Execution
Environment (CEE)
› Indicate the role of the Ericsson Cloud Manager (ECM)
› List the main steps when adding a VNF into a CEE
› Investigate the architecture of vEPC in cloud solution
› State the vEPC Implementation
› Determine the vEPG architecture in vEPC Network
› Recognize the vSGSN-MME architecture
› Restate the vSAPC architecture in vEPC Network
› Illustrate the vWMG architecture in vEPC Network

Figure 2-1: Objectives

LZT1381721 R3A © Ericsson AB 2017 - 33 -

 Virtual EPC Overview

1 Introduction

1.1 ETSI NFV Cloud Reference Architecture

The ETSI NFV reference architecture is shown below. The local part is provided
by the Ericsson Cloud Execution Environment (CEE) covering the infrastructure,
Orchestration and Management is handled by the Ericsson Cloud Manager
(ECM); EMS functionality is supported by OSS-RC and NFV and provided by
many virtual EPC node functionalities.

OSS-RC
vEPC as ECM
one or
more VNFs
– vSGSN-
MME,
vEPG,
vSAPC,
vWMG

CEE

Figure 2-2: ETSI NFV Ref Architecture Ericsson Product Mapping

1.1.1 Ericsson Cloud Execution Environment (CEE)

The Ericsson Cloud Execution Environment (CEE) product forms the Virtualization
Layer and takes care of Virtual Computing, Virtual Storage and Virtual Network. It also
implements the management entity Virtual Infrastructure Manager(s) (VIM). The VIM is
called CIC in CEE.

CEE uses Mirantis OpenStack which implements the core cloud functionality. Employing
the OpenStack framework exposes an already established set of functionalities for these
basic services.

Key CEE features are:

• Open platforms and interfaces
• OpenStack Icehouse or later release
• Linux Ubuntu host OS
• KVM Hypervisor

- 34 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

• High performance vSwitch (EVS)

• Local Storage
• High availability Cloud Infrastructure
• Fuel framework

Figure 2-3: CEE, CIC, and Openstack

CEE contains the virtualization layer (hypervisors) and virtual switches. It also
provides needed hooks to integrate and orchestrate external physical appliances
such as physical switches, storage arrays, etc.

To manage CEE, the Ericsson Cloud Manager (ECM) provides a high level
orchestration for application- deployment, monitoring and management as well as
for CEE infrastructure planning, fulfillment, assurance and charging. As an
alternative to ECM, the CEE dashboard can be used for low level management
and orchestration.

1.1.1.1 Openstack

OpenStack is a free and open-source software cloud computing software platform. The
technology consists of a series of interrelated projects that control pools of processing,
storage and networking resources throughout a data center - which users manage
through a web-based dashboard, command-line tools, or a RESTful API.

LZT1381721 R3A © Ericsson AB 2017 - 35 -

 Virtual EPC Overview

RESTful API: An API that adheres to the principles of REST does not require the
client to know anything about the structure of the API. Rather, the server needs to
provide whatever information the client needs to interact with the service.

Figure 2-4: Openstack

OpenStack is an open source project that implements part of the ecosystem that is
specified by the NFV ISG. Other parts that are needed to have a full NFV
environment is included in the open source Linux OS.

When configuring the cloud ecosystem each physical host is given a role. An
important role is the Compute Node which handles the execution of VMs.

Network (nick name “Neutron” in OpenStack) provides “network connectivity as

a service” between interface devices managed by other OpenStack services.

Fuel framework is an open source deployment and management tool for

OpenStack. Fuel is not part of the cloud infrastructure. It can be run on a separate
server as any physical application.

Based on OpenStack, CEE provides the following services:

• Virtualization of any x86 workloads

• Virtualization and orchestration of network- topologies and resources

• Ephemeral storage

• Tenant isolation

• Orchestration of tenant resources through a RESTful OpenStack- or EC2

northbound API, or through the CEE dashboard.

• Policy enforcement for placement, usage and security.

• Performance Measurement (PM)

• NTP

- 36 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

• DNS

1.1.1.2 Atlas

The Atlas is the local orchestration available in CEE which is based on

OpenStack components Horizon and Heat.

vCP RAM Disk

› CEE embedded orchestration VM
Us (GB) (GB)
› Must be deployed Atlas 2 4 120
› Runs as a single VM on any
host
› Cost efficient for smaller systems
› Based on OpenStack components
Horizon (Dashboard UI) and Heat
› Custom component - OVFT to
facilitate OVF-based
application orchestration
› Instantiation and
decommissioning of VNFs for a
single data center

Figure 2-5: Atlas

1.1.2 Ericsson Cloud Manager (ECM)

ECM plays the role of Orchestrator and Virtualized Network Function Manager. It also
includes service, virtualized network function and infrastructure description.

Ericsson Cloud Manager enables the creation, orchestration, activation, metering, and
monitoring of services running on virtualized resources, involving elastic IT and
programmable network resources, at consistent levels of quality and security. With
Ericsson Cloud Manager, cloud resources are no longer confined to a single data center,
but rather, are spread throughout the network to help improve both internal operations
and service quality. It manages the creation and instantiation of virtualized network
functions and automates and orchestrates provisioning of the virtual infrastructure.

Its service catalog provides dynamic, model-based service

definition/modification/exposure and drives the orchestration of provisioning
workflows. It allows operators to reuse internal resources or broker ecosystems
involving resources from third parties. Its policy management capabilities enforce rules
for the efficient assignment and use of resources including aspects such as resource pool
allocation and resource affinities. Ericsson Cloud Manager supplements these activities
with accounting, assurance and data analytics functions.

LZT1381721 R3A © Ericsson AB 2017 - 37 -

 Virtual EPC Overview

Ericsson Cloud Manager can interface to any virtualized infrastructure managers (e.g.
hypervisors). It can also interface to physical equipment managers to address specific
scenarios that require direct control of hardware.

With Ericsson Cloud Manager, service providers can gradually turn their networks and
infrastructure into distributed clouds where workload allocation becomes more elastic
and dynamic, without compromising service quality. It lets service providers optimize
any type of resource, virtual and physical, in any combination, and manage them all in a
flexible and proactive way to adapt to new business models.

Operator
› Manages and orchestrates Enterprise, Services Application
VAs, SI & Providers
computing, storage, network Vertical Apps
and applications across data
centers and tenants
› Handles service quality
Ericsson
› Dynamic, model-based External
Business
Cloud
service definition and Logic Manager
Network
provisioning Management
› Enforces end-to-end policies Internet

› Open, hardware- and Virtual

Network
virtualization-independent Data Appliances
Centers
› Built upon proven Telecom
Networks
OSS software
Data Center
Networks

Figure 2-6: Ericsson Cloud Manager

Cloud providers may use Ericsson Cloud Manager to centrally manage infrastructure
that potentially spans many physical data centers that may be geographically diverse.

1.1.3 OSS
OSS/BSS in the ETSI model does not exist in the vEPC solution but instead
physical OSS-RC is used. OSS-RC interfaces directly towards the O&M interface
of the VNFs. OSS-RC is not depending on any special cloud functionality.

1.2 Service Models

There are mainly three service models which are used when delivering cloud
services:

- 38 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

1 Infrastructure as a Service (IaaS) delivers basic infrastructure

elements such as computing, storage and networking functions as a
service. There are a number of sub-categories of IaaS such as Storage
as a Service, Networking as a Service or Firewall as a Service which
also can be delivered separately. Characteristics and components of
IaaS include:
o Utility computing service and billing model
o Automation of administrative tasks
o Dynamic scaling
o Internet and VPN connectivity

2 Platform as a Service (PaaS) is a provision model in which an

organization rents hardware, storage-, and network capacity,
operating systems, middleware and run-time environment over the
Internet. The service delivery model allows the customer to rent
virtualized servers and associated services for running existing
applications or developing and testing new ones.
PaaS has several advantages for developers. With PaaS, run-time
environment and system services are exposed from the PaaS layer
such that features can be changed and upgraded frequently without
impacting the hosted applications. Geographically distributed
development teams can work together on software development
projects. Services can be obtained from diverse sources that cross
international boundaries. Initial and ongoing costs can be reduced by
the use of infrastructure services from a single vendor rather than
maintaining multiple hardware facilities that often perform duplicate
functions or suffer from incompatibility problems. Overall expenses
can also be minimized by unification of programming development
efforts.

3 A provision model, or software distribution model, in which

applications are hosted by a vendor or service provider and made
available to customers over a network, typically the Internet.
Software as a Service (SaaS) is becoming an increasingly prevalent
delivery model as underlying technologies that support Web services
and service-oriented architecture (SOA) mature and new
developmental approaches, such as Ajax, become popular.
Meanwhile, broadband service has become increasingly available to
support user access from more areas around the world. SaaS is
closely related to the Application Service Provider (ASP) and on
demand computing software delivery models.

The ETSI VIM and NFVI implemented by CEE are forming the service model
Infrastructure as a Service (IaaS).

vEPC can be seen as a SaaS.

LZT1381721 R3A © Ericsson AB 2017 - 39 -

 Virtual EPC Overview

1.3 Virtual Machines

A virtual machine (VM) is a tightly isolated software container that can run its
own OS and applications as if it were a physical computer. A VM behaves
exactly like a physical computer and contains its own virtual CPU, RAM, hard
disk and Network Interface Card (vNIC). Multiple VMs can run at the same time
on the same physical host.

1.3.1 VM Affinity and Anti-Affinity Rules

VMs within a VNF may need to run on the same or different physical hardware
(host). The relationships between the virtual and physical machines are controlled
by Ericsson Cloud Manager through its affinity and anti-affinity rules. These
rules are enforced within a single infrastructure zone. VMs that should be run on
the same physical machine have an affinity for one another. VMs that should run
on different physical machines have anti-affinity for one another.

vEPC VNFs use anti-affinity rules due to redundancy and capacity reason unless
deployed in non-redundant models for distributed MBB and Small enterprise
instances.

Other means of ruling how the VMs are distributed is host aggregation, which is
defined and used within OpenStack.

The OVF standard supports affinity and anti-affinity. In OVF anti-affinity is

called availability.

1.4 A POD and its software

Many VNFs can be combined into a VDC (Virtual Data Center). Multiple VNFs
can be combined into a VNS (Virtual Network Service).

A Virtual Data Center is a pool of cloud infrastructure resources designed

specifically for enterprise business needs. Those resources include compute,
memory, storage and bandwidth.

A “Performance Optimized Datacenter” or POD is the cloud computing hardware

or infrastructure that will be seen by a consumer.

The Virtual Appliance (see Host 2 in the Picture below) is typically part of the
infrastructure (NFVI) doing central network or central resource tasks. The
Physical Application is typically the orchestration software.

A hypervisor is the virtualization software that emulates computer hardware

allowing multiple VMs to run on a single physical computer host. Each VM
appears to have the host’s processor, memory, and other resources all to itself.

The hypervisor controls the host processor and resources and allocates what is
needed to each VM operating system, making sure that the VMs cannot disrupt
each other.

- 40 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

Figure 2-7: A generalized logical view of a typical POD with VNF and the CEE
infrastructure

VMs of different types of applications can be combined and deployed

collectively as a VNF. A VNF will have a configuration forming a service or an
application where each VM may have different roles.

1.4.1 Open Virtualization Format (OVF) Files

The Open Virtualization Format (OVF) is an open standard for packaging and
distributing virtual applications for the use in virtual machines.

An OVF package structure consists of a number of files: a descriptor file,

optional manifest and certificate files, optional disk images, and optional resource
files.

DMTF’s Open Virtualization Format (OVF) standard provides the industry with
a standard packaging format for software solutions based on virtual systems.
OVF has been adopted and published by the International Organization for
Standardization (ISO) as ISO 17203.

Typical deliverable for each VNF is:

• OVA container includes both the software image and the OVF
file or scripts that can generate OVF files.
• Scripts for generating an OVA container. Can be part of the
OVA container.

If there is no OVA container, the deliverables are typically file container(s) that
include a script for generating an OVA container.

LZT1381721 R3A © Ericsson AB 2017 - 41 -

 Virtual EPC Overview

Affinity rules are specified in the OVF file. Related to affinity rules are the rules
that dictates how many vCPUs that are allowed on one physical CPU or core.
Over-provisioning is said to occur if the number of vCPU is larger than the
number of physical CPUs/cores on a certain host. This is not recommended for
performance critical subsystems.

ECM through OpenStack Glance administrates the images that form VMs.
Default format is qcow2 for all vEPC VNFs.

1.4.2 Onboarding and Instantiation

Onboarding is the process when a VNF is made known to the Orchestrator and
VNF Manager. The VNF packages are registered in the catalog of NFVO and the
images are uploaded to the VIM.

VNF instantiation refers to the process of identifying and reserving the

virtualized resources required for a VNF, instantiating the VNF and starting the
VDU (Virtual Deployment Unit) associated with each VNF.

1.5 Hypervisor and Ericsson Virtual Switch

Together with the hypervisor the virtual switch dictates very much the network
performance that a VM can get. OpenStack includes a virtual switch called OVS
(Open Virtual Switch), which is not optimized for performance critical systems.
Therefor CEE includes an optimized variant of OVS called EVS (Ericsson
Virtual Switch).

The virtual switch is tightly coupled to the hypervisor, so you cannot change
hypervisor and keep the same virtual switch. Ericsson vEPC is vSwitch agnostic
from functionality point of view but the performance are very dependent on
vSwitch capacity.

1.6 Storage
VIM instances can use two kinds of storage space: ephemeral and persistent.

The data is stored in different locations depending on the storage type: Ephemeral
data is managed by the Compute Node itself. This means that the storage could
be local or remote, depending on the Compute Nodes configuration. Persistent
data however, is normally acquired by requesting it from OpenStack Block
Storage.

Normally, an instance boots on the ephemeral storage and that VM-type may
have assigned additional ephemeral storage as well. What is extremely important
to remember with this type of storage, is that it is tightly bound to the life of that
VM instance which means that if you are decommissioning the instance, the data
is lost.

- 42 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

1.7 CEE High Availability

Figure 2-8: CEE High Availability Network

CEE provides a fully redundant Hardware infrastructure. There is no single point

of failure for networking and storage.

Life cycle control for all infrastructure services is separated from vEPC.

High availability is ensured by CEE HA middleware. This is done by health

check and recovery of services. Service threshold based error escalation leads to
reboot of CEE HA middleware component in error.

1.8 Backup and Restore

vEPC does not make use of the backup and restore mechanisms available in the
cloud ecosystem. The already existing functionality in the VNF is used in the
same way as for the physical nodes providing a more seamless management in
mixed networks with both physical and virtual functionalities.

2 Virtualized EPC Virtual Network Function (VNF)

Descriptions

2.1 vEPC Architecture Principal

The high level architecture shows the implementation of the VNF on the cloud
infrastructure.

LZT1381721 R3A © Ericsson AB 2017 - 43 -

 Virtual EPC Overview

› Consistent virtualization, management and orchestration of all vEPC

VNFs
– Pre- validated with CEE (KVM, OpenStack), VMware and OSS-RC
– Consistent management of Cloud use-cases: instantiation, scale-in/out, PM/FM/CM

Domain
Cloud Mgmt
Mgmt
(NFVO)
(NMS)

EPC Vertical Solutions

EPC VNF 1 EPC VNF 2 EPC VNF 3

VM-1 VM-2 VM-n VM-1 VM-2 VM-1 VM-2 VM-3 VM-4 VM-n

Cloud
Infrastructure
(VIM,
NFVI-SW)
Hypervisor Hypervisor Hypervisor Hypervisor
Hypervisor (NFVI-SW) Hypervisor (NFVI-SW) Hypervisor (NFVI-SW)
(NFVI-SW) (NFVI-SW) (NFVI-SW) (NFVI-SW)

Compute Compute Compute Compute

Compute (NFV-HW) Compute (NFV-HW) Compute (NFV-HW)
(NFV-HW) (NFV-HW) (NFV-HW) (NFV-HW)

Figure 2-9: High Level Architectural

The Main nodes functions are Node Management, Control Plane, User Plane and
Load Balancer.

› Hardware and software redundancy with session resiliency

– All components included both node management, control plane and user
plane functionality
› N+1 redundancy (N+1 VMs running in active mode)
Domain – Maximizes resource utilization
Cloud Mgmt – Guarantees even load sharing at scale-out and scale-in/failure
Mgmt
(NFVO)
(NMS) › VNF scalability behind a single IP-address

CM, 1+1 N+1 N+1 N+1

Netconf Node EPC VNF EPC VNF EPC VNF
PM
FM Management Control plane LB/Routing Userplane

VM VM VM VM VM VM VM VM VM VM

NM NM CP CP LB LB UP UP UP UP
Cloud
Infrastructure
(VIM, NFVI)
Hypervisor Hypervisor Hypervisor Hypervisor Hypervisor Hypervisor
Hypervisor (NFV-SW) Hypervisor (NFV-SW)
(NFV-SW) (NFV-SW) (NFV-SW) (NFV-SW) (NFV-SW) (NFV-SW)
Compute Compute Compute Compute Compute Compute
Compute (NFV-HW) Compute (NFV-HW)
(NFV-HW) (NFV-HW) (NFV-HW) (NFV-HW) (NFV-HW) (NFV-HW)

Switch Switch

Border Border
Router Router

External IP networks

Figure 2-10: High Level Architectural

- 44 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

Node Management VMs

› High availability Node Management logic, including VNF supervision,
O&M handling
› “Automated deployment ready” with support for optional injection of
NM FS DB configuration data upon VNF instantiation
› Always 2 VMs, 1+1 redundancy (active/passive)
› FS VM specific for SGSN-MME and part of Node Management category
› DB VM specific for SAPC and part of Node Management category
UP/CP Processor VMs
› Control plane and user plane. General Processor handles both UP and CP in
one VM.
UP CP GP › Scalable
› Session Resilience
› Geo Redundancy (optional)
Load Balancer VMs
› Virtual “Load Balancers” providing application aware single IP address [v4/v6]
load balancing (inbound) and forwarding (outbound), including support for Session
LB Resilience
› Support for routing with BFD, ECMP, etc.
› Scalable
› Configurable for symmetric and/or asymmetric VM layout

Figure 2-11: High Level Architectural – Main node functions

Interoperability between vEPC and non-virtual, i.e. physical, nodes is of course

possible.

The VNFs are not dependent on a specific controller/orchestrator. However, they

are pre-verified with Ericsson Cloud Manager, ECM, and Ericsson Cloud
Execution Environment, CEE.

LZT1381721 R3A © Ericsson AB 2017 - 45 -

 Virtual EPC Overview

2.1.1 VNF Architecture

Figure 2-12: vEPC VNF

The VMs execute on CEE and are connected to OSS and ECM. Each VNF has its
own routing, load balancer, local O&M – which is identical to the physical O&M
of the NF, and storage.

The VNFs are transparent to the interconnection layer of the physical blades (the
VNFs are agnostic of the IaaS, Infrastructure as a Service).

2.1.2 VNF Networking

All vEPC VNFs are reachable via virtual IP addresses in the same manner as their
corresponding PNFs.

IP networks are separated in the VNF by different methods depending on the VNF:

- vSAPC and vSGSN-MME uses separate vNICs attached to different VLANs in the
infrastructure. There is a maximum of 8 vNICs per VM. The VNFs sends untagged
traffic and the vSwitch tags the packet with the VLAN that has been allocated by
Neutron.

- vEPG and vWMG separates external traffic by using VLAN trunk vNICs, GRE
Tunnels or MPLS

- 46 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

VM VM VM VM VM

Virtual
EPC
NM LB CP/UP/GP CP/UP/GP …
› Typically 2 VNF internal OS OS OS OS OS
vNIC vNIC vNIC vNIC vNIC
networks and 1 external vSwitch vSwitch vSwitch

Infrastructure
Virtualization
Hypervisor Hypervisor Hypervisor …

HW x86 HW x86 HW x86 …

Switch

› VNFs are addressed in PDN

Site
Router
the same way as the
VM VM VM VM VM
corresponding PNFs

Virtual
Combined

EPC
NM UP GP …
LB/CP
OS OS OS OS OS
vNIC vNIC vNIC vNIC vNIC

vSwitch vSwitch vSwitch

…

Infrastructure
Virtualization
Hypervisor Hypervisor Hypervisor

HW x86 HW x86 HW x86 …

Switch

PDN
Site
Router

Figure 2-13: vEPC VNF Networking

o VLAN trunk vNICs

• There is only a single vNIC available per LB VM. The VNFs tags packets
with different tags for different external networks.
• CEE cloud systems include VLAN trunking capabilities. The CEE
infrastructure maps the VNF tagged VLANs to the correct Neutron
virtual network
• In a VMware cloud system, Guest VLAN-tagging is used and this
has to be configured for the port in VDS. The VNF tags are then
switched unmodified in the infrastructure.

o MPLS

• MPLS tunnels are originated in the vFRWD and terminated and

stitched into operator’s VPN backbone. VNF will distribute the traffic
that belongs to different VPN into different MPLS tunnel for egress
traffic, and the traffic will be MPLS over VLAN (if VLAN is used to
separate external VN) in Cloud

Cloud assigned IP address configuration (e.g. DHCP) is not supported. All IP addresses
are statically configured, either by the VNFs themselves or by being present in the OVF
file.

LZT1381721 R3A © Ericsson AB 2017 - 47 -

 Virtual EPC Overview

2.1.3 VM Affinity and Anti-affinity

Each VNF has a set of affinity rules that specifies which VMs of the VNF that
may execute on the same host and which VMs that must execute on different
hosts. This applies to VMs for Node Managers, control plane, user plane, Load
Balancer, Data Base and so on.

2.1.4 Traffic Flow

The traffic flow in a typical vEPC VNF is depicted in the Figure 1-14.

For the EPC-in-a-box deployment the flow is different. From an external source,
only a VIP is known and used to address the VNF. The VIP is not configured on
any particular network interface, but is the IP address used to reach the
application service available on several application VMs. The site router has IP
routes for the VIP addresses where the available LB VMs are next hops. ECMP is
used for load sharing over the available LB VMs. The packet is forwarded on L2
level via the ToR switch, the compute host, the vSwitch, and the vNIC of the LB
VM. The LB VM steers incoming traffic towards one of the application VMs on
which the VIP is available. Steering is done on application protocol identities like
e.g. GTP TEID.VLANs for external communication configured in a cloud region
must also be configured in the site router(s).

VM VM VM VM VM
Virtual
EPC

NM LB CP/UP/GP CP/UP/GP …

OS OS OS OS OS

vNIC vNIC vNIC vNIC vNIC

› ECMP used for load sharing over

available LBs vSwitch
Hypervisor
vSwitch
Hypervisor
vSwitch
Hypervisor
…
Infrastructure
Virtualization

› L2 forwarding via the ToR switch, HW x86 HW x86 HW x86 …

Compute Host, vSwitch, vNIC to LB

› LB steers incoming traffic to app Switch

VMs similarly to PNF

̶ GTP TEID, host routes, Gi slice PDN

Site
Router

routes
› LB part of CP/GP VM in vSGSN- VM VM VM VM VM
Virtual

MME and vSAPC

EPC

Combined
NM UP GP …
LB/CP

̶ Simplified Deployment with OS

vNIC
OS

vNIC
OS

vNIC
OS

vNIC
OS

vNIC

fewer VM types vSwitch vSwitch vSwitch

…

̶ Increased probability that traffic

Hypervisor Hypervisor Hypervisor
Infrastructure
Virtualization

HW x86 HW x86 HW x86 …

ends up on the VM with the user

session
̶ NOTE: SGSN-MME and EPG in
Switch

later releases PDN

Site
Router

Figure 2-14: vEPC VNF Typical Packet Flow

- 48 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

The LB VM receiving an external ingress packet will have to send the packet out
on the internal network to a specific CP/UP/GP VM. The LB function knows
how to do an even distribution among all suitable VMs on all hosts. Packets
sourced from CP/UP/GP VMs also pass LB VMs when egressing the cloud
region.

For vSAPC and SGSN-MME where the LB is on the same VM as the GP, the
traffic flow can be more efficient. There will be an increased chance that traffic
ends up on the VM with the user session. This will reduce the traffic over the
vSwitch.

2.1.5 Network Separation

All vEPC VNFs are reachable via a single IP address per IP network. By IP
network we here typically mean any 3GPP reference point, as S11, S1-U etc.

IP networks are separated using separate vNICs attached to different VLANs in

the infrastructure. There is a maximum of 8 vNICs per VM. In addition to this,
vEPG separates external traffic using GRE tunnels between the VNF and the site
router. The reason for this is the large number of APNs supported in vEPG. The
network separation principles are illustrated in the Figure 2-15

vSAPC, VM
› Traffic is separated over different interfaces vMME Driver
and networks
vNIC vNIC
› vSAPC and vSGSN-MME
Hypervisor
̶ Uses separate vNICs attached to different
VLANs in the infrastructure. NIC
̶ There is a maximum of 8 vNICs per VM. Hardware
̶ The VNFs sends untagged traffic and the
vSwitch tags the packet with the VLAN ...
that has been allocated by Neutron.
› vEPG and vWMG
VM
̶ Separates external traffic by using VLAN vEPG
Driver
trunk vNICs. vWMG
vNIC
̶ There is only a single vNIC available per
LB VM. The VNFs tags packets with Hypervisor Multiple
different tags for different external VLANS per
NIC vNIC
networks.
̶ Other separation methods that could be Hardware
used
› GRE/IPv4 tunnels.
...
› MPLS/BGP
BGW
BGW

Figure 2-15: vEPC Network Separation

2.1.6 High Availability

General principles

The vEPC principles of High Availability are:

LZT1381721 R3A © Ericsson AB 2017 - 49 -

 Virtual EPC Overview

• EPC physical application level mechanisms for fast failover are

kept also in cloud deployments
• Network level redundancy and load sharing can be utilized with
a mix of physical and virtual network functions
• Maintaining existing stateful failover behavior also in a virtual
environment, both intra VNF and Inter-VNF

The benefits of these principles are:

• Virtually no service impact on end users even in extreme
outage scenarios.
• Extremely high availability of services to end users and
business partners is assured.

Figure 2-16: vEPC High Availability Levels

High Availability responsibilities and functions per vEPC level

Network Level: Geo redundant network level features (like Geo-Redundant

Pool) with inter-site and inter POD redundancy. Failures and fast switchovers
between sites (ICR), Load balancing across Sites/PODs. Also Gateway
blacklisting, Traffic Storm Protection, Smart Signaling Throttling and UE
signaling Control.

- 50 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

EPC VNF: Intra VNF redundancy for VM failures. Application aware state
replication with 1+1 and n+1 failover schemas. Software failures and fast
switchovers within VNFs. VNF resilience and redundancy handling are
independent of Hardware failure notifications from the virtualization and
infrastructure layers. Instead, the application components (VMs, processes, etc.)
are supervised by internal VNF logic and recovery actions are triggered when
needed.

Execution Environment: VM deployment with anti-affinity rules, Automatic

VM restarts/re-allocation. OpenStack hitless upgrades, tenant isolation.

Hardware: Server restart and failure detection. Fully redundant Hardware

infrastructure. No single point of failure for compute, networking (e.g.
NIC/ToR/DC-GW) and storage. Failures in Hardware and Software appears as
lost VM’s to VNFs.

2.1.7 O&M
Each VNF instance is managed separately as a Managed Element of its own.

2.1.8 Compute Hardware

Each vEPC VNF can run on partner Hardware in a validated system.

2.1.9 Storage
The VNFs in the vEPC release only uses server- local storage, both ephemeral
and persistent, but no central storage like external SAN storage array.

2.1.10 VNF High Level Use Cases in vEPC

2.1.10.1 Onboarding and Instantiation

Software images and scripts are retrieved from the Software gateway. The scripts
are used to generate an OVF descriptor. The reason for using a script is to enable
adapting the OVF to the particular resource needs in a deployment. Parameters
required for initial O&M connectivity are subsequently specified in a personality
file.

vSAPC has a slightly different procedure: Scripts are also provided to 1) create
the OVA package for initial installation including OVF Descriptor file and
personality file for vSAPC customization during deployment and 2) script to
create the OVF descriptor files for scaling the Control Plane (a maximum of 6
CPs in the cluster).

LZT1381721 R3A © Ericsson AB 2017 - 51 -

 Virtual EPC Overview

2.1.10.2 Scale-Out and Scale-in

The Software packages for the different VNFs retrieved from Software Gateway
contain scripts that generate a particular OVF for scaling of the VNF. The scripts
are configured and executed in an environment with IP connection to ECM. The
exact procedure differs slightly for the different VNFs.

2.1.10.3 Update/Upgrade

Upgrade of the vEPC VNFs is done in the same way as on physical deployment.

2.1.11 Deliverables
Typical deliverables for each VNF are:
• OVA container, includes both the software image and the OVF
file or scripts that can generate OVF files
• Scripts for generating an OVA container. Can be part of the
OVA container

If there is no OVA container deliverable, the deliverables are typically file

container(s) that include a script for generating an OVA container.

- 52 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

3 vEPC Deployments

Ericsson Customer

Download Deploy OVF Flavor /Tenant

package Deploy using REST operation
SW GW Server ECM Admin

Installing
Run the deployment
tool, enable flexibility to
The flavor
customization, pre-
definition and
configure the
tenant operation
environment, generate
on ECM/CEE
OVA and enable ECEE/CI
C
requires the
services;
assistance from
the
Perform the administrator.
configuration on CIC
and vRP through SSH
VNF

Figure 2-17: VNF Deployment ECM/CEE Example

There are different kinds of deployments of vEPC.

› Box
› Virtualization layer used to enable multiple Box Cloud
applications in single server (box)
› No scalability
› No HW redundancy
› Deployment On-premise (typical)

…
› Cloud
› Group of HW resources (servers, storage and
switches) managed (orchestrated) as one pool.
› Deployment in Large data center (typical).
› Applications typically deployed where there is
room.
› Applications can be scaled
› HW redundancy typically achieved with anti-
affinity rules

Figure 2-18: vEPC Deployment Options

LZT1381721 R3A © Ericsson AB 2017 - 53 -

 Virtual EPC Overview

3.1.1 Cloud deployment variants

Variant Description
Single VNF single server - Single server dedicated to single VNF
- No HW redundancy
- Two VNFs required to accomplish HW
redundancy
- Typically not scalable
Single VNF multiple server - Multiple servers dedicated to single VNF
- HW redundant
- Typically scalable
- Efficient HW use when VNF requires whole
servers for capacity reasons.
Multiple VNF multiple - Multiple VNFs sharing HW
servers - HW redundant
- Typically scalable
- Efficient HW use when VNF only requires
small part of each server.

Figure 2-19: Cloud Deployment Variants

3.1.2 vEPC scaling dimensions

 Three different ways to

Vertical scalability (size of VMs)

+vCPUs increase total network capacity

+RAM +VNF  Per VNF scalability vs

multiple VNF benefits
(redundancy, resiliency...)
+Disk needs to be considered
 Box deployment will in future
be possible to scale vertically
and horizontally within limits of
a box

+VMs  Cloud deployment




Currently vertical scaling at
deployment time
Horizontal scaling typically
by creating new VMs on
VNF
new servers
Horizontal scalability (number of VMs)

Figure 2-20: vEPC Scaling Dimensions

- 54 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

3.1.3 Horizontal scalability

› Scalable deployments
̶ Targeting data centers
̶ HW redundant
Non-scalable Scalable
› Non-scalable Deployments Deployments Deployments
̶ No HW redundancy
› EPC-in-a-box
Single VNF
̶ Targeting distributed (on-
Single-server vEPC Compact
EPC-in-a-box Multiple
per VNF Deployment
servers
premise) deployments see
see
3/22109 – HSD 101 100/9
4/22109 – HSD 101 100/9
› VNF Single server Single Server Single Server Multiple Servers
+ +
deployments Servers for NFV-I Servers for NFV-I

̶ vEPG, vSAPC and vSGSN-

MME
̶ Targeting data centers

Figure 2-21: Horizontal scalability

3.1.4 Scalable deployment:

In a scalable deployment the vEPC VNFs are spread over several servers. The
deployment usually includes spare servers in the POD to be used for VNF scale-
out. Included in this deployment is redundant CEE deployment with 3 CIC
servers, redundant traffic switches and redundant control switches. Scalable
deployment is typically used when the vEPC is deployed in an Operators data
center.

Figure 2-22: Scalable vEPC Data Center deployment

LZT1381721 R3A © Ericsson AB 2017 - 55 -

 Virtual EPC Overview

3.1.5 VNF single server deployment:

3.1.5.1 Single VNF single server

In the VNF single server deployment each VNF is deployed on a single server. In
this deployment the CEE is limited to use one CIC server, single traffic switch
and single control switch meaning that in this type of deployment there is no
redundancy. VNF single server deployment is usually used when a minimal
footprint is required.

› Each VNF is deployed on a

single server
› Deployment vSGSN-MME vEPG vSAPC

– Data Center
› ECM or Atlas for orchestration
› Separate servers for cloud
infrastructure is needed 1 server 1 server 1 server

Figure 2-23: Single VNF single server

3.1.5.2 Single VNF Multiple server

› vEPC VNFs are spread

Orchestration
over several servers
dedicated to that particular
VNF vEPG
vEPG
vSGSN-
vSGSN-
MME
vSGSN-
MME
› Redundant cloud vEPG
vEPG
vEPG
vEPG
vSGSN-
MME
vSGSN-
MME
MME
vSGSN-
infrastructure vEPG
vEPG compute vEPG
vEPG
compute vSGSN-
MME
compute MME
vSGSN-
– Redundant infrastructure vEPG compute vEPG compute MME vSGSN-
vSAPC compute vWMG compute vEPG compute MME vSGSN-
management servers compute compute compute MME
compute compute compute
– Redundant traffic switches compute compute
compute
compute
– Redundant control switches compute compute compute
compute compute compute compute

› Each VNF is scalable and

redundant
Switching

Figure 2-24: Single VNF Multiple Servers

- 56 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

Applicable for both deployments are:

• It is recommended to use dedicated servers for VNFs that

require high NW bandwidth due to lack of band width
management in current version of CEE.

Host aggregates function in CEE is used to reserve compute server for vEPG, to
avoid that EPG user plane data traffic can starve out bandwidth resources for
other VNFs.

3.2 How to Define Bill of Material for vEPC Scalable

Deployment
Each VNF is deployed on its own servers.

Figure 2-25: vEPC scalable deployment including ECM and CEE

Figure 2-26: How to Define Bill of Material for vEPC Single Server per VNF
Deployment

LZT1381721 R3A © Ericsson AB 2017 - 57 -

 Virtual EPC Overview

The number of servers per CEE, vEPC VNF and ECM need to be calculated to
get the total number of servers needed for scalable deployment.

The number is = x+a+b+c, plus an extra 2 servers if an ECM instance also shall
be deployed. (Refer figure 1-25)

3.3 What is vEPG?

Figure 2-27: What is a vEPG?

The components of the virtual EPG are deployed as Virtual Machines (VMs) in a
cloud environment. A VM can take the role of a virtual Route-Processor (vRP),
Virtual Forwarder (vFRWD), or a Virtual Service (vSRVC). Figure 2-27 shows
an overview of the EPG in a cloud environment.

3.3.1 vEPG Architecture

The figure shows the high level of deployment of EPG application as NFV on
Cloud infrastructure.

- 58 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

Cloud Mgmt Domain Mgmt Max 20 VMs

(NFVO) (NMS)
CM
PM
FM
etc.
1+1 2-16 2-16 3-16

VM VM VM VM VM VM VM VM VM

NM NM UP UP LB LB CP CP CP
Cloud
Infrastructure
(VIM, NFVI)
Hypervisor Hypervisor Hypervisor Hypervisor Hypervisor
Hypervisors (NFV-SW) Hypervisor Hypervisor

HW (x86) HW (x86) HW (x86) HW (x86) (NFV-HW)

Compute HW (x86) HW (x86) HW (x86)

Sw itch Sw itch

Router Router

External IP netw orks

Figure 2-28: vEPG High Level Architectural Overview

3.3.2 Deployment Variants

While implementing the EPG on cloud can have many variants possible like
Single Server, Multiple Server etc.

Figure 2-29: vEPG Deployment variants

LZT1381721 R3A © Ericsson AB 2017 - 59 -

 Virtual EPC Overview

VM Type Mem (GB) vCPUs Disk (GB)

› Table shows min/max
NM Min: 2 Min: 2 Min: 40
resources for a specific VM Max: 8 Max: 4 Max: 40
type LB Min: 8 Min: 4 Min: 40
̶ CP,UP and LB size can be Max: 8 Max: 16 Max: 40
independently dimensioned CP Min: 8 Min: 4 Min: 40
Max: 64 Max: 32 Max: 40

UP Min: 8 Min: 4 Min: 40

› Picture shows minimum Max: 64 Max: 32 Max: 40
number of VMs for an
application redundant vEPG VM VM VM VM VM

NM NM CP CP CP

› No overcommit of vCPUs VM VM VM VM

UP UP LB LB

Figure 2-30: vEPG 16B Single VNF Multiple Servers

› Small scale footprint

› Acceptance and first customer site VM VM VM VM VM VM VM VM
pilot NM NM CP LB UP UP CP CP
› No overcommit of vCPUs
› Validated Traffic Model Hypervisor
› Up to 50k subscribers HW (x86)

› Up to 1.5 Gbps
› Up to 100 eNodeBs
› Up to 1 RNC VM # Total Total Total
› Validated on CEE Type VMs Mem(G Disk(G vCPU
› Possible to deploy in a Cloud (e.g. a B) B) s
CEE region)* NM 2 16 80 4
CP 3 48 120 18
*An alternative is to use EPC-in-a-box and just
deploy EPG. The EPC-in-a-box has higher UP UP 2 32 80 12
capacity due to usage of CPU pinning. Note
that EPC-in-a-box cannot be deployed in a LB 1 8 40 6
Cloud. Total 8 104 320 40

Figure 2-31: vEPG Deployment Example -Single VNF Single Server

3.3.3 High Availability

To ensure the high availability of the EPG affinity and anti-affinity rules applies.

- 60 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

› VNF application functions

for VM restarts
› Cloud functions for host
restarts
› Anti-affinity rules and
Availability Zones
› VNF failure
› Redundant standby or load
sharing VNF required
› Subscribers need to re-attach vEPG
to active vEPG
› May require optional functions
vSGSN-
on SGSN/MME for optimized MME
operation
vEPG

Figure 2-32: vEPG High Availability

3.3.4 Storage

› vEPG includes application level

fault tolerant storage
› Same application design as used on SSR
platform
› Charging data and other logs are stored
redundantly between VMs and are always
available, even if one VM fails
› VM storage provided through local
disk storage on each server
› Ephemeral storage

Figure 2-33: vEPG Storage

3.3.5 Resilience
For the scalable deployment, a physical host failure will lead to loss of three
VMs, which vEPG treats as a multiple failure. The consequence is that the PGW
part of the vEPG restarts and all PGW and combined PGW and SGW sessions
are lost. SGW sessions survive.

Note that all application resilience functions in the vEPG still apply.

LZT1381721 R3A © Ericsson AB 2017 - 61 -

 Virtual EPC Overview

In the vEPG single server deployment, there is obviously no Hardware

redundancy. If the host is lost or restarts, all sessions and charging data are lost.

Figure 2-34: vEPG resilience functions

3.4 What is vSGSN-MME?

The virtual SGSN-MME is executed in a cloud environment, which consists of
the following components:

• Cloud infrastructure: Ericsson CEE or a third-party cloud infrastructure,

providing Infrastructure as a Service (IaaS), where the virtual SGSN-
MME executes on a cluster of VMs

• Cloud management system: Ericsson ECM, Ericsson CEE, or a third-party

cloud management system, providing management and orchestration of
the virtual resources

• Ericsson Operations Support System for Radio and Core (OSS-RC) or

Ericsson Network Manager (ENM): providing element management of the
Ericsson Physical Network Functions (PNFs) and Virtual Network
Functions (VNFs), and providing a Specific Virtual Network Function
Manager (S-VNFM) for life cycle management of the Ericsson VNFs.
Element management includes, for example, fault management,
configuration management, and performance management. VNF life cycle
management includes, for example, instantiation and scaling.

• Legacy Operations Support System (OSS) and Business Support System

(BSS) of the operator

- 62 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

Figure 2-35: What is vSGSN-MME?

3.4.1 Architecture

High availability  High performance nodes

Cloud Mgmt Domain Mgmt node control and storage – Native (MkX) and Virtual (Cloud)
(NFVO) (NMS)  Pooling of nodes for increased
network capacity and redundancy
CM
PM
FM 1+1 1+1 2-8 4-32
etc

VM VM VM VM VM VM VM VM VM VM

LB LB CP UP CP UP CP UP CP UP
NM NM FS FS
Cloud SS7 SS7 SS7 SS7
Infrastructure SCTP SCTP SCTP SCTP
(VIM, NFVI)
Hyperviso Hyperviso Hyperviso Hyperviso Hyperviso Hyperviso Hyperviso Hyperviso Hyperviso
Hypervisors (NFV-SW)
r r r r r r r r r
HW (x86) HW (x86) HW (x86) HW Compute HW (x86) HW (x86) HW (x86) HW (x86) HW (x86)
(x86) (NFV-HW)

SGSN-MME application aware Switch Switch Multicore VMs

Ericsson load balancing and forwarding Router Router with with co-located
or third party (including support for CP/SS7/SCTP/UP
COTS HW Session Resilience) and Session Resilience
External IP networks

Figure 2-36: vSGSN-MME High Level Architectural

The virtual SGSN-MME is based on the same architecture as the physical SGSN-
MME, including middleware and application SW. This provides a common
feature set for both physical and virtual SGSN-MME. The common application
Software also assures interworking between virtual SGSN-MME, physical
SGSN-MME, and related peer network elements.

LZT1381721 R3A © Ericsson AB 2017 - 63 -

 Virtual EPC Overview

The Software components are distributed and executed on VMs. VMs in the
virtual SGSN-MME correspond to PIUs in the physical SGSN-MME.
VMs can have one of the following roles:

Provides NFS storage and network boot services for all

File Server other VMs in the cluster.
Board (FSB) There is one primary FSB and one secondary FSB for
redundancy.
Performs cluster supervision, Software distribution, and
Node
provides O&M for the virtual SGSN-MME.
Controller
Board (NCB) There is one active NCB and one passive NCB for
redundancy.
Performs SGSN-MME application processing for
General
LTE/WCDMA/GSM control plane and signaling, and
Processor
WCDMA/GSM user plane. Optionally includes integrated
Board (GPB)
vLC functionality.
Provides external connectivity, with application aware
single IP address load balancing (inbound) and forwarding
virtual Line
(outbound), including support for session resilience. The
Card (vLC)
vLC VMs are not present when using GPB VMs with
integrated vLC functionality.

3.4.2 Conceptual View

Storage of initial boot
image, containing
Image entire NDP.
OSS ECM CEE storage

On request from OSS (or ECM), ECS

OSS supports application creates virtual resources, provides initial
management (including boot images and sets up needed
SW upgrade) as usual. connectivity.

DRBD External network(s) .

Virtual SGSN-MME

Block
vLC
vLC
NC

NC
FS

FS

storage …

The VMs in a virtual

SGSN-MME correspond
to the boards in chassis
based deployments Private internal Router
AP/DP

AP/DP

AP/DP

AP/DP

redundant L2 network
.
…
Up to 32 AP/DP/SCTP
instances.

Figure 2-37: Virtual SGSN-MME conceptual view

- 64 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

3.4.3 Deployment Variant

Virtual SGSN-MME supports the following validated deployment types. The
validated deployment types specify, for example, VM sizes, number of VMs, and
distribution of VMs over the available compute hosts.

Multi-host virtual This deployment targets scalability and high capacity, with full
SGSN-MME with Software and Hardware redundancy. The vLC role is deployed
Standalone vLC as vLC VMs separate from the GPB VMs.

Multi-host virtual This deployment targets increased scalability and capacity for
SGSN-MME with payload, with full Software and Hardware redundancy. The vLC
Integrated vLC role is integrated in the GPB VMs.

This deployment targets small footprint with limited capacity.

The deployment has small VM sizes, all collocated on one
compute host.
It supports full Software redundancy including VM redundancy.
Single-host virtual The deployment does not support Hardware redundancy.
SGSN-MME However, network level redundancy can be achieved through a
pair of virtual SGSN-MME instances configured as an SGSN or
MME pool, possibly with geo-redundancy.

› Compact Deployment
– Sharing servers with EPG
and SAPC

› EPC-in-a-box

› Single VNF Multiple Servers

– Whole servers dedicated
to single VNF

› Single VNF Single Server

– Additional servers are
required for cloud
infrastructure control

Figure 2-38: vSGSN-MME Deployment variants

LZT1381721 R3A © Ericsson AB 2017 - 65 -

 Virtual EPC Overview

One VM #VMs Host Mem (GB), Host vCPUs, Host

per Host {Flavor 1, Flavor 2, {Flavor 1, Flavor 2, Disk(GB) VM VM VM VM
Flavor 3} Flavor 3}
FS 2 10-50 4-20 160 NM NM FS FS
NM 2 10-50 4-20 1
LB 2-8 4 4 ( - 64)* 1 Hypervisor Hypervisor Hypervisor Hypervisor
GP 4-32 {30, 40, 50} {12, 16, 20} 1 HW HW HW HW
GPLC 4-32 {40, 50, 60} {16, 20, 24} 1 (x86) (x86) (x86) (x86)

VM VM VM VM VM VM
› One VM per server CP UP CP UP CP UP CP UP
LB LB

› Up to 6 additional LB VMs SS7

SCTP
SS7
SCTP
SS7
SCTP
SS7
SCTP

› Up to 28 additional GP VMs Hyperviso

r
Hyperviso
r
Hyperviso
r
Hyperviso
r
Hyperviso
r
Hyperviso
r

› GP = CP/UP/SS7 VM HW (x86) HW (x86) HW (x86) HW (x86) HW (x86) HW (x86)

Figure 2-39: vSGSN-MME Single VNF Multiple Servers

3.4.4 Storage
All virtual SGSN-MME storage is on the FSB VM root disk, that is, the VM disk
image or the OpenStack Cinder volume that is used to boot the VM. The storage
includes Software data, configuration data, SGSN charging data, and log files.
All non-FSB VMs use only the local VM disk image for booting. Non-FSB VMs
do not write to the local disk; they write to the shared file system provided by the
primary FSB VM.

The virtual SGSN-MME has two FSB VMs acting as file servers; one primary
and one secondary. The primary FSB VM mirrors its disk to the secondary FSB
VM. This means that the virtual SGSN-MME provides storage redundancy when
deployed with local storage. For centralized storage, the cloud system typically
provides back-end storage redundancy. In this case, the FSB redundancy provides
SGSN-MME internal NFS service redundancy.

The virtual SGSN-MME storage capacity is fixed. It is not possible to expand the
delivered storage capacity for the virtual SGSN-MME, by resizing the FSB VM
disk or by adding additional disks. For example, it is not possible to attach an
OpenStack Cinder block storage volume to the FSB VMs.

- 66 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

› vSGSN-MME includes
application level fault
tolerant storage
› Charging data and other
logs are stored redundantly
between FS VMs using
DRBD and are always
available, even if one VM
fails
› VM storage provided
through local disk storage
on each server
› Ephemeral storage

Figure 2-40: vSGSN-MME Storage

3.4.5 Resilience

Figure 2-41: vSGSN-MME resilience functions

LZT1381721 R3A © Ericsson AB 2017 - 67 -

 Virtual EPC Overview

3.5 What is vSAPC?

The SAPC is the Ericsson Multi-Access Policy Management Framework. It
provides policy management for Mobile Broadband Networks, Fixed Broadband
Networks, and Fixed-Mobile Convergence (FMC) Broadband Networks. The
SAPC enables then the applicability of policy control capabilities based on
subscriber and service information. The main enabled policy types are related to
service access control, Quality of Service (QoS) control and charging control.

The SAPC is positioned as the advanced solution for the following business
drivers:

Multi-access. The SAPC 1 release provides policy control for both Fixed
accesses (like PPP or IPoE) and Mobile accesses (like GSM, UTRAN and E-
UTRAN).

Convergence. Users may enter into the Service Network through different type
of accesses, and policy control can manage consistently such users across such
accesses. With such target, the SAPC 1 provides an FMC policy control solution.

Value Added Offerings. Operators are willing to monetize premium services

and obtain more revenues segmenting the subscriber base. The SAPC allows the
Operator to define complex offerings and, simultaneously, control the service
delivery based on subscriber category, accumulated use, service type, and access
conditions.

Network Optimization. Multimedia services are consuming an ever increasing

amount of network resources, and subscribers are increasing their use of these
services. Operators must manage these services while providing them in a cost
effective and reliable way. QoS control ensures that services do not over run the
limited network resources and not degrade existing services, Service Level
Agreements, and premium subscribers. There is a need to maximize the
efficiency of the network from the terminal to the network edge, and the SAPC
can control the corresponding parameters setting the right priorities and QoS to
the different streams that traverse the transport plane. The output is an optimized
network that gives the needed resources based on per subscriber and service
policies. And that enables the implementation of voice optimization services, like
Voice over Long Term Evolution (VoLTE) or Wi-Fi calling.

Smart Traffic Management. Network architecture is evolving towards Software

Defined Network (SDN). Ericsson Service Chaining solution enables operators to
manage traffic in a smart way while keeping the focus on cost-driven network
optimization. For such purpose, the SAPC provides real-time dynamic policy
decisions based on network and subscriber information the SDN-Controller.

The SAPC responds to these challenges by providing an advanced technical

solution characterized by:

Technology Leaders. First to market, the SAPC uses state-of-the-art platform

technologies, focused in providing excellent characteristics measurements.

- 68 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

› vSAPC is the NFV Ericsson Policy

Controller
– Based on standards (3GPP PCRF, BBF
BPCF)
– For all Mobile, Fixed and Converged
deployments
› vSAPC performs
vSAPC – Network Access Control
– QoS Control based on subscribers and
applications
– Usage Quota Management
– Events notification between Application and
Transport network

Figure 2-42: What is vSAPC?

Easy Integration. The SAPC can be easily integrated with any gateway
supporting the standard 3GPP Gx reference point. The SAPC is deployed in
verified in Ericsson end-to-end solutions that requires policy control,
interworking then with the Ericsson Evolved Packet Gateway (EPG), and the
Ericsson Wi-Fi Mobility Gateway (WMG). In addition, the SAPC can be north-
bound integrated with Operation and Maintenance systems through standard
interfaces like Simple Network Management Protocol (SNMP), Network
Configuration Protocol (NETCONF), or Simple Object Access Protocol (SOAP).

High Availability. The SAPC provides a fully redundant node architecture

reaching 5x9's availability.

LZT1381721 R3A © Ericsson AB 2017 - 69 -

 Virtual EPC Overview

3.5.1 vSAPC architecture

Figure 2-43: vSAPC architecture

Cloud Domain
Management Management
(NFVO) (NMS)

CM
PM
FM
1+1 2-34 2 2
etc

VM VM VM VM VM VM VM VM

VR VR VR VR
NM NM GP GP
O&M O&M Traffic Traffic
Cloud
Infrastructure
(VIM, NFVI)

Hypervisor (NFV-SW)

Compute (NFV-HW)

Switch Switch

Router Router

External IP networks

Figure 2-44: vSAPC High Level Architectural Overview

- 70 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

3.5.2 vSAPC deployment variants

› Compact Deployment
– Sharing servers with EPG and
SAPC vSGSN/
MME vEPG vSAPC

Server Server Server Server Server

› EPC-in-a-box Server Server Server Server Server

› Single VNF Multiple vSGSN/

MME
vSAPC vEPG

Servers Server

– Whole servers dedicated to

single VNF
vSAPC

› Single VNF Single Server Server Server Server Server Server

Server Server Server Server Server

vSAPC

Server

Figure 2-45: vSAPC Deployment variants

3.5.2.1 Single VNF multiple server

› Two servers with same VMs

– Redundant x2
– Table shows total resources per VM VM VM VM VM VM VM VM
server NM
VR VR GP GP GP GP GP
O&M Traffic

› Scalable with four CPs on each

server Hypervisor
HW (x86)

– Scale simultaneously on both hosts

for session resilience

› LB embedded as floating on CP VM Type #VMs Total Total Total

Mem(GB) Disk(GB) vCPUs
VMs NM 1 6 40 2
– Max 6 CPs can act as LBs GP 1–17 7–119 - 2–10
VR O&M 1 1 4 2
– LB automatically moved at CP VR Traffic 1 1 4 2
failure Total 4-20 15-127 48 8-16
› VMs of the same type should
not run on the same server.
– Enforced by availability groups

Figure 2-46: vSAPC Single VNF Multiple Servers

LZT1381721 R3A © Ericsson AB 2017 - 71 -

 Virtual EPC Overview

3.5.2.2 Single VNF single server

VM VM VM VM VM
› Two server deployment VR VR CP
NM FS
on one server O&M Traffic
LB

̶ Non-redundant HW
VM VM VM VM VM
̶ Table shows total resources VR VR CP
NM FS
O&M Traffic
LB

Hypervisor

HW (x86)

VM Type #VMs Total Total Total

Mem(GB) Disk(GB) vCPUs
NM 2 12 60 4
CP 2-34 14-238 - 4-68
VR O&M 2 2 8 4
VR Traffic 2 2 8 4
Total 10-40 58-282 122 20-36

Figure 2-47: vSAPC Single Server Deployment

3.5.3 vSAPC resilience

Figure 2-48: vSAPC resilience functions

- 72 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

3.6 vWMG
vWMG is a common mobile network access solution
• for SIM & non-SIM devices
• Supporting trusted and untrusted Wi-Fi networks

vWMG is feature compatible with most of the features of the classical WMG.

Some of the more typical examples where Wi-Fi is/would be used:

• At the hotel while on travel: used for cheaper calling as the
roaming fee is avoided.
• In areas with poor (indoor) coverage, e.g. basement.

3.6.1 Untrusted Wi-Fi Architecture

3GPP 3GPP
Macro
3GPP Network Gx
Micro
SAPC
HSS
3GPP
Pico ESy
SWx

Gy
OCS/
CCN
AAA
DNS
Gz
Serving
-GW Provisi
IEEE DNS
oning
802.11 S2b
PDN-
GW
L2/L3 Connectivity (Public Internet) S6b
SGi
SWu Wi-Fi
AP WMG
IMS
Wi-Fi Network Diameter SWm

SIGNALLING
PAYLOAD

Figure 2-49: Untrusted Wi-Fi Architecture

LZT1381721 R3A © Ericsson AB 2017 - 73 -

 Virtual EPC Overview

3.6.2 Trusted Wi-Fi Architecture

Gx
3GPP
3GPP
Macro SAPC
3GPP
Micro Network ESy HSS
3GPP
Pico Gy

SWx
OCS/
CCN

S5 Gz
AAA
Provisi
Serving PDN- oning
-GW S2a
GW
IEEE
802.11 Service
SGi/Gi
Network
Wi-Fi
AP 3PP’s own Wi-Fi WMG
AC EoGRE/EoIP
protocol
RADIUS STa
Wi-Fi Network

SIGNALLING
PAYLOAD

Figure 2-50: Trusted Wi-Fi Architecture

3.6.3 vWMG High Level Architectural Overview

OSS / NMS

1+1 O&M, VNF

control N+1 LB / Multiple WMG
Routing Instances

Active/Standby Active/Active Active/Standby Active/Standby

VM VM VM VM VM VM VM VM

NM NM Standby Active Active

Standby
LB LB GP GP GP
GP

IPOS IPOS IPOS IPOS IPOS IPOS IPOS IPOS

NFVI

From 1 to n
Servers
1RU Server
From small to large
DC
DC EBS
COTS

Figure 2-51: vWMG High Level Architectural Overview

- 74 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

3.6.4 vWMG maximum configuration

Cloud Mgmt Domain Mgmt
(NFVO) (NMS) Max 20
CM VMs
PM 1+1 1+1 1+1 2-18
FM
etc

VM VM VM VM VM VM
VM VM

Cloud
Infrastructure
NM NM CP UP CP UP

……. CP UP CP UP
LB LB

(VIM, NFVI)
Hyperviso Hyperviso Hyperviso Hyperviso Hyperviso Hyperviso Hyperviso Hyperviso Hyperviso
Hyperviso Hyperviso
Hypervisors (NFV-SW)
r r r rr rr r rr r r
HW (x86) HW (x86) HW (x86) HW Compute HW (x86) HW (x86) HW (x86) HW (x86) HW (x86)
(x86) (NFV-HW

Switch Switch

Router Router

External IP networks

Figure 2-52: vWMG High Level Architecture – Maximum Configuration

3.6.5 Deployment variant

› Single VNF Multiple

Servers
̶ Whole servers dedicated to
single VNF
vWM
G

Server Server
Server Server
Server Server
Server Server

Figure 2-53: vWMG Deployment variants

LZT1381721 R3A © Ericsson AB 2017 - 75 -

 Virtual EPC Overview

3.6.6 vWMG scalable deployment

› Three groups of VM sizes VM VM VM VM VM VM

NM GP LB NM GP LB

› Minimum deployment Hypervisor Hypervisor

̶ 2 NMs, 2GPs and 2LBs

HW (x86) HW (x86)

̶ Either as ePDG or TWAG VM VM VM VM VM VM VM VM

LB GP LB LB GP LB
GP ….. GP
› Maximum deployment Hypervisor Hypervisor Hypervisor Hypervisor

̶ Up to 5 pairs of GPs and 10 LB

HW (x86) HW (x86) HW (x86) HW (x86)

› NMs are deployed as Server 1-2:

NM
# VMs
1
Mem (GB)
8
Disk (GB)
64
vCPUs
4
active/standby, both LBs LB 1 8 40 6
GP 1 42 40 12
and GPs will be active Tot: 3 58 144 22
Server 3-10: # VMs Mem (GB) Disk (GB) vCPUs
› Anti-affinity between VMs LB
GP
1
1
8
42
40
40
6
12
of the same type is Tot: 2 50 80 18

required Example with medium size VMs

Figure 2-54: vWMG Scalable Deployment

4 Commands in ECM and CCE

4.1 Fuel
Fuel is the CEE Installation Server. Fuel is an open source deployment and
management tool for OpenStack which does the automation and management for
you. Fuel in general, is not part of the cloud infrastructure; it can be run on a
separate server as any physical application.

Fuel makes possible that the Openstack controls all VMs. The fuel command
below displays the resources available in the vEPC, such as the so called CIC
(CEE Installation Controller) and other resources called Compute.
[root@vepc02-fuel ~] # fuel node
id | status | name | cluster | ip | mac | roles | pending roles | online
---|----------|------------------|---------|---------------|-------------------|---------------------------|---------------|-------
4 | ready | compute-0-5 | 1 | 192.168.0.23 | b8:ca:3a:6f:5d:34 | compute | | True
6 | discover | Untitled (83:cc) | None | 192.168.0.129 | b8:ca:3a:6d:83:cc | | | False
2 | ready | compute-0-4 | 1 | 192.168.0.21 | b8:ca:3a:6f:61:84 | compute | | True
1 | ready | compute-0-2 | 1 | 192.168.0.20 | b8:ca:3a:6f:66:14 | compute | | True
3 | ready | cic-0-1 |1 | 192.168.0.22 | b8:ca:3a:6f:66:88 | cinder, controller, mongo | | True
5 | ready | compute-0-3 | 1 | 192.168.0.24 | b8:ca:3a:6f:5d:d8 | compute | | True

4.2 CEE
The CEE provides the virtualization control and a management layer based on
OpenStack. OpenStack is a virtualization management system that controls pools
of compute, storage, and networking resources throughout a Data Center.

- 76 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

The following components from OpenStack are used in CEE:

• Object Store (nickname "Swift") allows storing and retrieving
objects (but not to mount directories like a fileserver). In CEE
15B, object store is not available for tenants.
• Image (nickname "Glance") service provides a catalog and
repository for virtual disk images.
• Compute (nickname "Nova") provides virtual servers upon
demand.
• Identity (nickname "Keystone") provides authentication and
authorization for all the OpenStack services.
• Network (nickname "Neutron") provides "network connectivity
as a service" between interface devices managed by other
OpenStack services (most likely Nova).
• Block Storage (nickname "Cinder") provides persistent block
storage to guest VMs.
• Performance measurements support (nickname “ceilometer”)
provides counter and alarm information for charging and
performance monitoring.
• Dashboard (nickname “Horizon”) provides means of managing
a CEE region, is part of Atlas (“Atlas” is an Ericsson improved
version of “Horizon”).
• Orchestration Engine (nickname "Heat") to launch multiple
composite cloud applications based on templates, is part of
Atlas.
• Life cycle manager (nickname “Fuel”) provides means of
managing the infrastructure hardware and software.

When configuring the cloud ecosystem each physical host is given a role. An
important role is the Compute Node which handles the execution of VMs.

Network (nick name “Neutron” in OpenStack) provides “network connectivity as

a service” between interface devices managed by other OpenStack services. In
CEE there are more components, such as glance and nova.

LZT1381721 R3A © Ericsson AB 2017 - 77 -

 Virtual EPC Overview

Figure 2-55: vEPC Data Center

Let’s assume that ssh root@10.20.0.3 provides access to CEE (CIC) (see figure
above). Already in CIC the path /var/log includes information about the available
resources in CIC:

root@node-1:~# cd /var/log

root@node-1:/var/log# ls
…glance neutron nova horizon….

Inside CIC there is access to glance commands, neutron commands and nova
commands. Each of those set of commands accomplish specific tasks.

The CIC (Cloud Infrastructure Controller) server is just a controller. It contains

the OpenStack. VIM. From CEE OpenStack it is possible to run Openstack
resources such as neutron, fuel, and glance.

Glance: Glance is the Openstack instance for image storage. ECM, through
OpenStack Glance, administrates the images that form VMs.

Neutron: Network (nick name “Neutron” in OpenStack) provides “network

connectivity as a service” between interface devices managed by other
OpenStack services.

4.3 Examples of some of the available commands:

4.3.1 Nova commands

The command nova list shows the running VMs:

- 78 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

root@node-1: ~# nova list

| ID | Name | Status | Task State | Power State | Networks

| 17901867-b5aa-4558-ab28-f53bf2971c5a | VM-1123 | ACTIVE | - | Running | VN-

1119-1=30.30.0.2,
10.51.253.44

| 71304b65-13ca-4ec1-a89e-129465cd81d4 | VM-1526 | ACTIVE | - | Running | VN-

1518-1=30.30.2.2; VN-1521-1=30.30.5.2; VN-1517-1=1.1.1.162, 10.51.253.48; VN-
1519-1=30.30.3.2; VN-1522-1=30.30.6.2; VN-1520-
1=30.30.4.2 |

The command nova show displays info about specific VM:

The command nova flavor-list displays the flavor list, meaning the hardware
specific for each type of VM. In ECM will be found the same definitions.

The command nova host-list displays the available hardware resources, such as
Compute.

The command nova hypervisor-stats displays the state of the hypervisors.

The commands nova-manage VM list, displays the VMs and which host it is
running on.

The commands nova shows VM-14570 shows virtual networks of a specific VM.

The command nova host-describe node-2 checks the compute host status (CPU,
memory and disk usage).

4.3.2 Glance commands

The command glance image-list displays the uploaded images:

4.3.3 Neutron commands

The command neutron net-list is used to check networking.

The command neutron net-show VN-22230-1 shows details of a specific

network.

The command neutron net-show displays the VLAN of your network.

The command neutron agent-list displays the network status.

LZT1381721 R3A © Ericsson AB 2017 - 79 -

 Virtual EPC Overview

5 Summary

Upon completion of this chapter, the student should now be

able to:
› Identify the vEPC and its components
› Indicate the main elements of the Cloud Execution
Environment CEE
› List the role of the Ericsson Cloud Manager
› Investigate the main steps when adding a VNF into a CEE
› State the architecture of vEPC in cloud solution
› Determine the vEPC Implementation
› Recognize the vEPG architecture in vEPC Network
› Interpret the vSASN architecture in vEPC Network
› Restate the vSAPC architecture in vEPC Network
› Illustrate the vWMG architecture in vEPC Network
Figure 2-56: Summary

- 80 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Components and Architecture

Intentionally Blank

LZT1381721 R3A © Ericsson AB 2017 - 81 -

vEPC Implementation

3 vEPC Implementation

Objectives

Upon completion of this chapter, the student will be able to:

› Describe the Ericsson's vEPC for Internet of things IoT, meaning the
solution for IoT services which consists of vEPG, vSAPC and
vSGSN-MME VNFs

› Explain the Ericsson's Distributed MBB broadband

› Explain other network services of vEPC Business Solution

Figure 3-1: Objectives

LZT1381721 R3A © Ericsson AB 2017 - 83 -

 Virtual EPC Overview

1 Introduction
Ericsson virtual Evolved Packet Core provides tested and validated solutions
addressing a large number of vertical use-cases. Key initial virtual network
services include:
• Internet of Things
• Distributed Mobile Broadband
• Enterprise
• Communication
• Mobile Broadband

The benefits of Ericsson ‘s virtual EPC include all the benefits of NFV, but with
Ericsson differentiation – a complete end-to-end solution, meaning virtualization
of all EPC components with full feature compatibility with classical EPC.

MBB vEPC Distributed Enterprise Communication Internet of Things

MBB
› Full support for › Full support for › Dedicated › Full support › Full NB-IoT, Cat-
MBB services local MBB enterprise VoLTE and M & EC-GSM
services instances Wi-Fi calling support
› Hybrid
networks › Auto- › Service › Leading device › Full roaming
configuration automation compatibility
› Scalability /
› Dedicated IoT
VNF › Local breakout › Private LTE › Speed with instance
and local operational
mobility mgmt flexibility

Making new revenue opportunities possible

Figure 3-2: Virtual EPC Network Services

1.1 Deployment options

To cater for the different capacity and redundancy needs, several different vEPC
deployments are created. The deployments specify how the VNF VMs are placed
on the hosts, as well as how the networking between the VNFs and the BGW is
set-up.

Two main types of deployments exist:

• EPC-in-a-box

This deployment type can only be one single server/blade/host. Virtualization

technology is used to make it possible to fit multiple vEPC VNFs onto a single
server. This deployment has the following specific properties:

- 84 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Implementation

– No Hardware redundancy

– Limitations in application Software redundancy

– Not scalable (i.e. capacity is limited to what the single server can
handle).

– Cannot be deployed on one server in a Cloud region consisting of

multiple servers (CEE single server configuration is one region
in itself).

• Cloud

In this type of deployment, the vEPC VNFs are deployed in a Cloud (e.g. CEE,
Openstack, VMware, etc.). Cloud can be defined as a pool of resources (compute,
networking, storage, services, etc.) managed as one entity (aka datacenter) and
where resources can be allocated on-demand for a VNF. In general Cloud
deployments are possible to scale.

Compact In-a-box
(MBB, Communication, IoT) (Enterprise, DMBB)
vEPC
SGSN-MME SAPC
2x12 Host

EPG EVR
RAN_int

Signalling_int
Media_int

O&M_int
Routing
Contexts Signalling_int

RAN O&M_int
Trunk vNIC

Media

Signaling
RAN_ext
O Media_ext
&
Signalling_ext
M
Iac O&M_ext
toExt_open

LCT

NIC

“Back-
haul” eNodeB
eNodeB
eNodeB

Figure 3-3: System verified deployment models Providing predictable

performance

Both EPC-in-a-box and Cloud deployments are validated deployments.

• Cloud Deployment

 vEPC Compact Deployment

In this deployment Multiple VNFs share servers in predefined way to provide a

Hardware redundant setup with small Hardware footprint and predictable system
behavior.

 Single VNF

LZT1381721 R3A © Ericsson AB 2017 - 85 -

 Virtual EPC Overview

In this deployment the single VNF has dedicated servers, i.e. servers in a cloud
are dedicated to a single VNF. The two variants of Single VNF are:

o Multiple server (Hardware redundant)

o Single server (non-hardware redundant)

Both the multiple and single server deployments can be scalable. But for some
VNFs the single server deployment is not scalable and some VNFs do not have
any single server deployment.

NOTE: There is no vEPC single server Cloud deployment with multiple VNFs.

Cloud deployments, where VNFs are sharing servers with other non vEPC
applications in the cloud, are not validated. If sharing servers with other
applications, special care must be taken with regards to allocation of server
resources (CPUs, memory, storage IO bandwidth and network IO bandwidth).

1.2 Internet of Things

Gartner definition of Internet of Things (IoT) is:

“The Internet of Things is the network of physical objects that contain embedded
technology to communicate and sense or interact with their internal states or the
external environment” M2M (Machine to Machine) was an earlier term used.
Today M2M is seen as providing the connectivity for devices to enable smart
services. M2M and the smart services together form IoT.

So far, the IoT has developed in two main ways. First, miniaturization, cloud
solutions, faster processing speeds, and use of data analytics have allowed
companies to benefit from real-time data collected from the physical
environment. Second, decreasing component costs and cheaper data collection
methods have altered the cost-benefit model, making IoT solutions feasible for
more actors. Together, these drivers lay the foundation for continued
development of new products and services.

VNS IoT provides operators with support for IoT traffic traversing through the
3GPP Packet Core network.

- 86 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Implementation

1.2.1 IoT is a different business

SMARTPHONES M2M DEVICES

From many devices… …to huge number of devices

From individual behavior … …to synchronized behavior

…
From single known traffic model … …to wide variety of traffic models
…
From tolerant to connectivity … to need robust
failures ... connectivity

From ARPU >$50 per month … …to ARPU <$5 per month

From standard infrastructure …to dedicated infrastructure for

serving all customers… M2M customers only

Based on slide from Telenor Connexion

Figure 3-4: IoT is a different business addressed by Ericsson

1.2.2 Key Vertical segments

TELEMATICS METERING REMOTE MONITORING

Connected cars used for The electricity smartgrids Sensors connected to assets
safety and security, services reports a measurement every are tracked and monitored in
and infotainment. certain period. real-time.
140 M

71 M
40 M 49 M
33 M 25 M

2012 2016 2012 2016 2012 2016

FLEET MANGEMENT SECURITY ATM / POINT OF SALES

Vehicles can be managed Connectivity used for home ATM and POS devices are
and tracked through the path and small business security connected to a centralized
they go. alarms. secure environment.

26 M 37 M
15 M 14 M 9M 17 M

2012 2016 2012 2016 2012 2016

Source: Cellular M2M Connectivity Services (ABI Research, Dec 2011)

Figure 3-5: Key Vertical segments

LZT1381721 R3A © Ericsson AB 2017 - 87 -

 Virtual EPC Overview

1.2.3 Massive IOT E2E offering

INDUSTRY SPECIFIC SOLUTIONS SERVICES

Utilities Transport Public Safety Smart Cities Other Industries Network Design &
SERVICES
Optimization
Network Design &
Optimization
IOT PLATFORM/IOT ACCELERTOR Network Roll-out
Network Roll-out

Customer Support
Customer Support
CORE NETWORKS
Device & App
VerificationDevice & App

OSS-RC/ENM
Virtual EPC / EPC Unified Data Management Verification
Consulting & SI

Consulting & SI
Managed Services
RADIO NETWORKS
Massive IoT RAN (NB-IoT, Cat-M1, EC-GSM-IoT) Managed Services

Figure 3-6: Massive IOT E2E offering

1.2.4 vEPC Base and Value Packages Internet of things

The IoT Base package is mandatory and contains the starting point providing an
optimized VNF deployment model with scalable signaling and limited user plane
for large numbers of low end devices such as sensors and electric meters. The
benefit for the operator is the possibility to enter the IoT market segment in a cost
efficient way and grow on demand. The network is still upgradeable to provide
for advanced functions such as mobility, roaming and full reporting.

• S-KPIs for TCP and EBM event

IoT Extended Analytics
streaming
IoT Analytics • Traffic analysis for detailed analytics
• A set of advanced functionality including
Internet
of Things Advanced IoT VNF detailed event reporting and advanced
policy control
vEPG
vSAPC
High Speed • For high bandwidth devices
vSGSN-MME
High Availability and Pooling • Provides Inter POD failovers and
load-sharing for 24x7 availability
Mobility and Roaming • For moving things
• For operators requiring full EPC
IoT Full EPC overlay
overlay dedicated to IoT business
Base Package • Enables cost efficient and scalable
Internet of Things deployment for low bandwidth
stationary devices

Figure 3-7: vEPC Base and Value Packages Internet of things

- 88 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Implementation

1.2.5 Policy control

fridge.com < 100 <5 21:00 to

Zone 1 MB/month GB/month 0:00 daily
H-PLMN High-Prio Bearer

Music.com <2 < 30 0:00 to

Roaming GB/month GB/month 23:59
Partner High-Prio Bearer working
days

Figure 3-8: Policy Control - Internet of Things

1.2.6 Benefits
› Improved cash flow
› Increased sales hit rate increase
revenues

› Quick response to customers need

› More capacity, functionality

› Reduced Impact on MBB Core Network

through dedicated resources
– Separation of concern
E.g. 3 Months
– Independent scaling of EPC capacity

› Addresses IoT Challenges

E.g. 3 Days
› Support flexible deployment models
› Functionality flexibility

Figure 3-9: Benefits

Win more customers:

• Virtualized environment and Automated Workflow allows fast
pilot setups.
• Easy for an IoT customer to test.
• Pilot easy to convert into commercial contract.
• Increases sales hit rate.

Higher cash flow:

• Faster Order-to-Cash time.
• Customer on-boarded in a few days instead of a few months.
• Automated Workflow.

Lower cost of sales:

LZT1381721 R3A © Ericsson AB 2017 - 89 -

 Virtual EPC Overview

• Reduced manual work in on-boarding deployments.

• Automated Workflow.

Automated TCO:
• Cost efficient and scalable deployment for low bandwidth
stationary devices.
Optional Value Packages to support more advanced IoT needs.

1.3 Distributed MBB

Distributed Mobile Broadband (Distributed MBB) is one of several Virtual
Network Services(VNSs) for vEPC.

1.3.1 Distributed MBB Network Overview

The Distributed Mobile Broadband (DMBB) VNS solution makes it possible to
deploy and operate a virtual packet core anywhere in a cost efficient manner.
Typically, a remote radio network coverage area with poor/expensive backhaul
connection may benefit from this solution.

The DMBB VNS covers a number of aspects of local access, in a small scale
system. Typical is that the operator distributed network is connected to the
operator’s central network via a poor (i.e. limited bandwidth and/or high latency)
backhaul, e.g. satellite or E1 links. The operator distributed network may in its
turn be connected to one or several different types of networks local to the
distributed site.

Figure 3-10: Distributed MBB Network Overview

- 90 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Implementation

In DMBB, the vEPG is in the EPC architecture always a combined SGW and
PGW. vSGSN-MME is optional but recommended to distribute (see chapter 3.3).
The other VNFs are optional depending on the implemented use case. ECM is
also optional and Atlas (part of CEE) is the default orchestrator.

1.3.2 Packaging
The same value packages apply for the vEPC VNFs as for EPC PNFs (Physical
Network Functions). Next section lists the value packages, and specific functions
within the packages, that are required to realize the described use cases. In
addition to the use case specific value packages, the DMBB site will in most
cases have the same level of functionality as the central site.

VNF Base VNF VP Packages

Packages

vEPG
vSGSN-
MME

vSAPC
Figure 3-11: vEPC Value Packages

The Software for DMBB is licensed per VNF and licenses entitles for use in one
virtual instance of that VNF.

vThunder does not have value packages. All functions are included and the
licensing is based on throughput.

200 Mbps 1 Gbps

vThunder

Figure 3-12: vThunder licensing

LZT1381721 R3A © Ericsson AB 2017 - 91 -

 Virtual EPC Overview

1.3.3 Required Node Functions

To enable the vEPC DMBB solution to work in the most efficient way, certain
functionality in the network nodes might be needed. They could be required in
either the VNFs or PNFs. The following chapters specify which these functions
are and some may be Ericsson proprietary. Other vendors may have equal
functions which could fulfil the requirements.

1.3.3.1 SGSN-MME

 Without Distributed SGSN-MME

• VP Signaling Optimization

– Function Gateway Blacklisting

o Used for optimized PDN/PDP connection creation during

distributed vEPG outage.

• VP Network Efficiency

– Function 3G Direct Tunnel (3GDT)

o Mandatory for WCDMA subscribers connected to the

distributed vEPG.

– Function APN Resolve and Redirect

o Sub-function “APN Resolution Functional Extension” is

used by WCDMA subscribers to select the correct GGSN.

o “APN Local Breakout Control” can optionally be used to

control roaming local breakout for LTE subscribers.

– VP Location Based IP Address

o Used for forcing a re-connect of a PDN/PDP connection

when moving between central and distributed locations. An
alternative to achieve this is to use Gx+ Policy and Charging
Control in the EPG.

o VP Location Based IP Address Allocation includes the

function Location Based IP Address Allocation.

• Base Package

– PGW Reselection (LTE only)

- 92 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Implementation

 With Distributed SGSN-MME

• Base Package

– PGW Reselection (LTE only)

• VP Network Efficiency

– Function 3G Direct Tunnel (3GDT)

o Mandatory for WCDMA subscribers connected to the distributed

vEPG.

 EPG

• VP Smart Personalized Broadband

– Function Gx+ Policy and Charging Control (PCC)

o Used for forcing a re-connect of a PDN/PDP connection when

moving between central and distributed locations. A PCRF is
required for policy evaluation based on the user location. An
alternative to achieve this is to use Location Based IP Address
Allocation in the SGSN-MME.

 SAPC

• Base Package

– 3GPP Gx, Basic Policy Control, Default Bearer QoS Control

o Used if forcing a re-connect of a PDN/PDP connection when

moving between central and distributed locations is performed
with the help of SAPC and location-based policies.

– VP Network Efficiency gives the possibility to use an SAPC external

database for subscription data. This allows the integration with
CUDB.

– VP Money aware allows the integration of OCS or MBC (Ericsson

OCS) and vSAPC via the 3GPP Sy and Ericsson Sy interfaces
respectively. This integration allows vSAPC to take policy decisions
(for example QoS or access decisions for a subscriber session) taking
into account OCS/MBC information (usage accumulated in terms of
money or monetary balance in the account as an example).

1.3.4 Deployment
Figure below describes the high level deployment validated in 16Q4. The Traffic
and Control do not necessarily have to connect to the same BGW.

LZT1381721 R3A © Ericsson AB 2017 - 93 -

 Virtual EPC Overview

HDS CRU
EPC-in-a-box

NIC NIC

10G

1G
vFuel
(EPC-in-

NIC
BGW a-box)
Traffic Control
vFuel

NIC
10G
(vThunder)

1G
NIC NIC
Dell 630T
vThunder

Figure 3-13: Validated Deployment

The vEPC EPC-in-a-box Solution Description, has the specifics of how EPC-in-a
box is deployed on a single server CEE and the requirements around that. It also
has more information on how vFuel and Atlas can be used which is valid for both
EPC-in-a-box and vThunder.

vThunder is deployed on a separate server and CEE region. A non-redundant

CEE installation is only supported for single server setups, so a new CEE
installation is required.

It is optional if the servers are connected directly to the BGW or via a switch.

vFuel, needed for CEE installation and recovery, is installed on a low-end device,
e.g. a laptop, and it does not have to be a permanent part of the permanent
installation at the DMBB site.

vFuel must have a dedicated NIC. If vThunder, or perhaps a redundant EPC-in-a-

box, is deployed, the laptop can be configured to alternate the use of the NIC
between the two vFuel if the laptop doesn’t have duel NICs.

After CEE installation for EPC-in-a-box the vFuel can be removed. Before
removing Fuel some configuration of the Box and backup of vFuel must be done.

- 94 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Implementation

1.3.5 Use cases

1.3.5.1 Local Network Connectivity

This use case enhances the user experience by using local network peering. This
is possible thanks to distributing the vEPG. In this case the mobile operator can
offload traffic from the backhaul by routing traffic directly to locally available
internet access or peering partners. The distributed vEPG can provide the same
services to the user as the centrally located PGW/GGSN.

Figure 3-14: Use cases I

The vEPG does not need any application specific configuration to achieve this
use case. It is network configuration in the vEPG and the mobile backbone
routers at the distributed site that need configuring. Scenarios for this use case
range from a remote rural site covered by an operator to company locations such
as oil rigs requesting operators to enhance their mobile broadband for local
services.

LZT1381721 R3A © Ericsson AB 2017 - 95 -

 Virtual EPC Overview

1.3.5.2 Small Local MBB Operator

DMBB’s small footprint offers an attractive MBB introduction for small local
operators requiring MBB. The use case is similar to the LTE Greenfield use case
in VNS MBB but DMBB using EPC-in-a-box provides a price model better
adapted for MBB deployments with a smaller number of subscribers.

The EPC-in-a-box deployment offers a full EPC solution for GSM, WCDMA and
LTE access and 3GPP connectivity to external functions such as HSS/HLR and
voice services.

Note: Since the EPC-in-a-box is non Hardware redundant it is strongly

recommended to setup two EPC-in-a-boxes if ISP is critical. With only one box
upgrades and recoveries might cause unacceptable downtimes.

HSS

vSGSN- OSS/
MME BSS

vSAPC
LTE/3G

Internet
vEPG etc.

Signaling
Ch. Sys Payload

BACKHAUL

DISTR NETWORK
DMBB
Local
Network,
vEPG vThunde
r

W/L

Figure 3-15: Use cases II

- 96 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Implementation

1.3.6 Benefits

• vEPC Distributed Mobile Broadband

› Small optimized solution for best possible end user experience

› Cost efficient cloud orchestration
› Local network peering
› Small local MBB operator
› CGN with vThunder

• Distributed vSGSN-MME
› Lower signaling and payload (GSM) latency
› Increased resilience against backhaul failures
– vSGSN-MME configuration can further reduce HLR/HSS signaling
› Less configuration in:
– Central SGSN-MME
– Central DNS with distributed DNS
› Re-usable configuration between sites

Figure 3-16: Benefits

1.4 Virtual Enterprise

Virtual Enterprise is one of several VNSs for vEPC.

The three factors, Workforce Mobility, “Consumerization” of Enterprise IT and

Business Optimizations are the driving forces that lead the transformation of the
Enterprises into the Mobile Enterprise:

1) Workforce Mobility is the need to be able to work anywhere and anytime. This
means being able to work from a range of devices and access information needed
to do one’s job. A mobile workforce can be mobile within their own premises, in
the office or on the campus, as well as when travelling (to and from the office and
as part of their role).

2) “Consumerization” of Enterprise IT has been driven by factors as the desire of

workers to select their own smart phone and tablet and the desire of IT to control
and lower costs. It includes Bring Your Own device (BYOD) but also Bring Your
Own Application (BYOA) and Bring Your Own Service provider (BYOSP) as
well as multi device operation and sharing of devices between work and personal
lives. IT departments have stopped resisting this trend and are embracing it as
they see the benefits both in increased employee satisfaction and cost certainty
and control.

3) Business Optimization stresses the focus of the CIO and IT department on

adding value to their enterprise. Data available today suggests that IT spends 60-
70% or more of its resources on running networks, rather than their own business
transformation. This opens up an opportunity for enterprises to outsource their
networks to operators and develop their applications making use of the cloud
services away from their premises.

LZT1381721 R3A © Ericsson AB 2017 - 97 -

 Virtual EPC Overview

The16Q2 scope of VNS Enterprise covers the possibility to outsource the mobile
data network to operators and enable mobility for enterprise employees. Efficient
subscriber handling can be done using operator provided business interfaces
towards vSAPC.

1.4.1 Packaging
The VNS Enterprise is built up by one Base package and five VPs. The VPs can
be added to the Enterprise Base package independent of each other.

For 16Q2 Enterprise Base, Tailored Broadband, HA & Pooling, Reporting &
Analytics, Convergence and Enterprise Lawful Intercept are available. The other
VPs are planned for future quarters.

1.4.1.1 Enterprise Base Package

The Enterprise Base Package is mandatory and contains the starting point for the
solution focusing on providing an easy and fast deployment of the VNFs to offer
mobile broadband access.

The benefit for the Enterprises is to reduce the time needed to introduce new
services and to flexibly assign them to their employees according to their own
changing enterprise business policies. The Package Enterprise Base covers
mobile access with some basic Policy and Charging control functionality as well
as basic Reporting capabilities. It provides differentiated QoS and IP access
control per user/employee or groups of users/employees for both Enterprise
services and the internet.

The benefit for the operator is the ability to provide solutions to the Enterprise
market segment in a cost efficient way. More advanced solutions can be offered
with the VPs.

The VNFs may be deployed in the operator’s premises (Data center deployment)
or in the Enterprise premises (distributed deployment).

- 98 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Implementation

Figure 3-17: Packages defined for VNS Enterprise

1.4.1.2 VP Tailored Broadband

The VP Tailored Broadband provides more advanced Enterprise related

functions. These include for example:

• Service level traffic separation (service access, charging and QoS

control)

• Shared data plans (common usage limits shared by several Enterprise

employees)

• Dedicated bearers with guaranteed Quality of Service.

• Content filtering to block forbidden internet content.

• Online charging control using Gy interface

• Auto provisioning

• Integration with MBC/OCS through Ericsson Sy/Sy interface

respectively

• QoS control for Enterprise users

1.4.1.3 VP Convergence

For the scope of16Q2 the VP Convergence adds Wi-Fi and CDMA access. The
connectivity for this access can be from the vEPG to the vWMG in an Ericsson
Network Integrated Wi-Fi solution or to the respective physical Wi-Fi and
CDMA nodes.

LZT1381721 R3A © Ericsson AB 2017 - 99 -

 Virtual EPC Overview

1.4.1.4 VP High Availability & Pooling

VP HA & Pooling is added when the customer has High Availability (HA)
requirements. With the current function set, the virtual core network availability
is increased, but in some failure cases the devices will have to reconnect.

1.4.1.5 VP Reporting & Analytics

VP Reporting & Analytics provides capabilities to extract valuable information

about the end user’s quality of experience, the performance of the network or the
success of the deployed data offers based on the events reported by the VNFs and
generated by activity changes of the mobile subscribers.

Reporting & Analytics mainly refers to EBM (Event Based Monitoring) EDR,
Top URI and vSAPC SOAP notifications. The VP Reporting & Analytics is
applicable to any VNF included from another package.

1.4.1.6 VP Enterprise Lawful Intercept

VP Enterprise Lawful Intercept enables the Enterprise to fulfill requirements

from a national or state security organization to monitor the data traffic of
specific subscribers and terminals. It also allows Law Enforcement Agencies
(LEA) to access data traffic related information about the activities of specific
Enterprise vEPC subscribers and their user data.

This Value Package applies for the vEPG and the vSGSN-MME.

1.4.1.7 Service Aware Charging and Control (SACC)

SACC is a reference business solution where vEPG and vSAPC are central parts.
It can be found in both the product catalog and in the internal CPI. The solution
contains a collection of supporting material including presentations, solution
guidelines, technical descriptions and configuration guidelines.

Many of the topics and use cases for VNS Enterprise are covered by the SACC
solution and it is recommended to be familiar with it; both for getting ideas for
implementation of agreed use cases and new ones for sales.

1.4.2 Data Center Deployment

In a Data Center deployment, the VNFs will be located in a Data Center owned
by the Operator. The VNFs used by the Enterprise will share the cloud resources
with other Operator cloud services.

The Enterprise subscribers will use the existing macro radio network. The
existing PNFs SGSN-MME and SGW are used for handling the mobility and
payload for the different radio accesses. Any access type can be supported and
may include indoor radio at the Enterprise site to improve coverage.

- 100 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Implementation

Depending on requirements the Enterprise could connect LTE radio dots to the
SGW function in the vEPG. This will improve possibilities for location based
policies. Otherwise the Operator SGW and Enterprise PGW will be used.

Figure 3-18: Enterprise Deployment Alternative I

The Enterprise subscribers can be stored either in the vSAPC internal database or
in an external repository, as the CUDB. Note that when the Enterprise requires
real time cost control for Enterprise subscribers and the operator macro network
deploys the Ericsson Online Charging System (OCS), the Enterprise subscribers
could be stored in the Ericsson OCS instead.

1.4.3 Distributed Deployment

Compared to the Data Center deployment, the SGW function of the vEPG is
always included and SGSN-MME can optionally be included.

The main reasons for including the SGSN-MME would be for protecting the
signaling from unauthorized access outside the Enterprise premises and to
minimize the impact, both performance and configuration, on the central MME
and DNS.

Typically, only the MME part of the SGSN-MME will be deployed. LTE radio
dots located at the Enterprise site are connected to the distributed MME and
SGW and using a designated Tracking Area. This will keep the payload and
signaling for the Enterprise users local to the distributed deployment.

LZT1381721 R3A © Ericsson AB 2017 - 101 -

 Virtual EPC Overview

The distributed MME only needs to communicate with the distributed SGW, and
vice versa. Only in case the vMME is not included in the distributed deployment
the vSGW needs to communicate with the operator SGSN-MME.

The SGSN part only needs to be deployed if the Enterprise has 2G/3G access
with a dedicated RNC or BSC.

When the subscriber leaves the premises a handover will be performed to the
Operator’s central MME or SGSN if it is 3G coverage.

Figure 3-19: Enterprise Deployment Alternative II

A designated Tracking Area enables a wide range of policies to apply to

Enterprise subscribers depending on if they are at the Enterprise premises or not.

The Enterprise subscribers can be stored either in the vSAPC internal database or
in an external repository, for example, in an Enterprise directory server.

- 102 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Implementation

1.4.4 Use cases

› Bearer Access and QoS control for Enterprise

› Radio Shielding Policies for indoor LTE radio access
› Local Internet Break-out with Service Differentiation in vEPG
› Fair Usage Limits outside Enterprise Area
› Roaming with Network Lock and Cost control
› Service Differentiation for Enterprise Applications
› Automatic provisioning of Enterprise users in a Shared Instance
› Reporting and Analytics use cases
› Differentiated Mobile services for the Enterprises
› Enhanced Subscription and Policy Control with Enterprise Databases

Figure 3-20: Use Cases

1.5 MBB VNS

Mobile Broad Band is one of several VNSs for vEPC.

MBB VNS provides a virtualized and telecom grade cloud ready, scalable MBB
system with a small footprint and hardware redundancy.

The MBB VNS can seamlessly coexist with the existing physical MBB and
comes with a number of benefits:

• It uses the benefits of the cloud technology, i.e. fast deployment with
instantiation, decommissioning and scaling.

• It is possible to easily handle capacity increase need by scaling

virtualized nodes.

• Node configuration can be adapted to the specific subscriber and network

conditions in which the VNF operates.

• New releases and new features can be tested in a live network by

instantiating new VNFs for a limited set of users. When verified, all
subscribers can be switched to the new VNF and the old one
decommissioned.

1.5.1 Deployment options

MBB VNS also comes with flexible cloud deployment options:

LZT1381721 R3A © Ericsson AB 2017 - 103 -

 Virtual EPC Overview

• (VNFs) in a smart way, i.e. VNFs use shared compute resources.

Figure 3-21: MBB VNS Cloud Deployment Options

For Tier 1 operators it is possible to dedicate compute resources per VNF and
create large scale MBB cloud deployment. For Tier 2 and Tier 3 operators a
combination of small footprint, simple scaling and Hardware redundancy is
achieved by collocating virtualized network functions

It is possible to combine the shared and dedicated resources approach, e.g. using
shared resources for a subset of VNFs and dedicated resources for another subset
of VNFs.

The physical and virtual packet core networks functions are managed in the same
way so existing OSS systems can be used for operating and maintaining also the
VNFs. To harmonize operation and maintenance between the physical and
virtualized packet core domains, OSS-RC/ENM will also collect PM and FM
data from the infrastructure domain (cloud management) per tenant and visualize
relevant information together with the application PM and FM data.

In the long run the requirements for the MBB VNS will be same as for an MBB
system built on physical nodes. In the short term, migration into a cloud MBB is
expected to happen gradually and triggered by certain uses cases (UCs).

1.5.2 Packaging
The same value packaging is applied to both VNFs and PNFs, i.e. same base and
value packages as for PNFs apply to the VNFs. The VNF deliverables are
specific and some exceptions for virtualized offering could exist. Which means it
is possible to select exactly which value packages to purchase per VNF and that
there is no VNS specific value packaging for MBB VNS. By default, Software
for all VNFs part of MBB VNS is included when purchasing MBB VNS. At
deployment time it is up to the customer to decide which VNFs to deploy in a
data center, that is all are optional. If no specific capacity licenses are purchased a
basic trial license is included for all VNFs.

- 104 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Implementation

SGSN-MME EPG SAPC WMG

VNF VP
Packages

VNF Base
Packages

Figure 3-22: MBB Packaging

To ensure acquired capacity licenses match available compute and network

resources, it has to be ensured that proper dimensioning has been performed.
Packet Core Dimensioning and Packet Core Sales support can be contacted for
dimensioning support.

1.5.3 Use cases

The following use cases are relevant for the introduction of MBB VNS.

1.5.3.1 Capacity Growth & Modernization

The vEPC can be used to handle capacity growth for an existing MBB operator.
The vEPC can offload the existing EPC by:

- Dedicating traffic from a geographical area to a vEPC instance.

Default introduction scenario model for break-in vEPC opportunities.

- Load balancing traffic between vEPC and the existing EPC.

Default introduction scenario for existing Ericsson EPC customers and part of
migration into full vEPC longer term.

This is a way to gradually modernize the MBB network.

The vEPC VNFs can be seamlessly integrated with the existing EPC and the
VNFs provide full feature parity with the PNFs with certain exceptions. The
vEPC has full external compatibility with 3GPP interfaces, which ensures no
impact on Radio access and devices.

There are two different scenarios that need to be considered:

LZT1381721 R3A © Ericsson AB 2017 - 105 -

 Virtual EPC Overview

• Operator legacy EPC is Ericsson. In that case, the vEPC is smoothly

integrated and can be seen as an expansion over a new technology of
existing capabilities (purpose is to prevent open contest and other vendor
break-ins).

• Existing EPC is non-Ericsson; in that case the vEPC can be introduced as

an overlay to the operator EPC.

1.5.3.2 Mobile Virtual Network Operator (MVNO)

A MVNO is a virtual operator that manages and distributes a range of mobile

phone services under its trademark(s) by using network services provided by a
host Mobile Network Operator (MNO). The host operator has spare radio
network capacity that the MVNO can make a better business out of.

The MNO has a Radio Access Network (RAN) and a packet core network. The
MNO can make part of its packet core capacity available to one or several
MVNOs as a business deal. The MNO needs to maximize network utilization and
capture new revenue streams.

By dedicating a vEPC for a MVNO it allows for improved separation of concerns

between MNO and MVNO, and MVNO and other MVNOs, i.e.:

• Separated maintenance for nodes

• Unique services per MVNO

• Security

1.5.3.3 LTE Greenfield Operator

A new LTE entrant or Greenfield operator is an operator that lacks the constraints
from a previous network and can choose to deploy the LTE network based on a
vEPC from the beginning.

LTE Greenfield operators can increase their network service, including

GSM/WCDMA, with roaming agreements.

This UC corresponds to initial install of a physical EPC, the difference is that

vSGSN-MME, vEPG and vSAPC are software to be deployed in a cloud
environment.

- 106 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Implementation

1.5.3.4 Network Verification

A vEPC for packet core network verification purposes can be deployed as a

network slice utilizing a live or simulated radio network. The network slice can
be used for testing new features, new software versions, new configuration, etc.
and easily migrated into the live network. This is made possible using for
example vSGSN-MME test functions, DNS for vEPG selection etc. which can
decrease the acceptance period from weeks to days or even hours.

1.5.3.5 VoLTE

The vEPG and vSAPC VNF can be used to create a network slice for VoLTE.
VoLTE has different characteristics than MBB and the expansion of the packet
core network can scale better when separating the two services. The network slice
can improve the quality and reliability of VoLTE through the separation from the
MBB network.

It is also possible to enable VoLTE in an existing vEPC MBB deployment.

1.5.3.6 Wi-Fi Calling

The Ericsson Network Integrated Wi-Fi (ENIW) Solution describes a scenario

called Wi-Fi Calling. The main scenario is for un-trusted Wi-Fi access, but it is
also possible to implement it for Trusted Wi-Fi access. The packet core part of
the solution contains WMG (ePDG) and EPG. If the solution is to be integrated
with VoLTE, SAPC is needed for seamless handover.

vEPC can provide a faster introduction of Wi-Fi Calling. Starting with a network
slice on a small scale for validation it can later expand as needed with the
subscriber growth, with minimum impact on the existing MBB network.

It is also possible to integrate Wi-Fi Calling in an existing vEPC MBB

deployment.

1.5.3.7 Trusted Wi-Fi Access

The Ericsson Network Integrated Wi-Fi (ENIW) Solution describes a scenario for
Trusted Wi-Fi Access. Trusted Wi-Fi access can be added to offload the 3GPP
RAN or provide indoor access where 3GPP RAN is poor. The vEPG and vWMG
can provide a smooth introduction with minimum interference to the existing
MBB network as a network slice. The solution can scale as the number of
subscribers increase.

It is also possible to integrate Trusted Wi-Fi in an existing vEPC MBB

deployment.

LZT1381721 R3A © Ericsson AB 2017 - 107 -

 Virtual EPC Overview

1.5.3.8 SDN Service Chaining Support

vEPC and in particular VNS MBB contains traffic data (subscriber specific,
traffic type and destination specific, flow specific) that can be used as input to
SDN network that can increase the value proposition of vEPC and SDN and their
interworking.

1.5.4 Network slicing

Network slicing is about how subscribers can be partitioned in a MBB network.
The general definition of a network slice is a defined set of network resources,
physical and/or virtual dedicated or shared, providing a (logical) partition of the
network which is used to serve a defined set of devices.

Operator A
Virtual MVNO
MBB

Physical
Geographical
Operator B
Area
MBB
G/W/L/
Wi-Fi

Load-
MBB balancing

Total Subscribers Set

MBB
Set A Set
Set CC

Set B

Figure 3-23: Network slicing

Load balancing is not strictly a network slice. Load balancing can be done on
several levels of the network to offload certain nodes in the network.

The drivers for network slicing are:

• Business expansion by low initial investment

- Given the cloud infrastructure it is much easier to instantiate another

vEPC instance for the business expansion than to set up a new
parallel infrastructure.

- 108 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Implementation

• Low risk or limited impact on legacy

- As the new slice has a dedicated vEPC instance, the slicing provides
resource isolation. Thus introduction of an isolated network slice will
minimize the risk to impact existing operator services.

• Shorter TTM

- The operators are concerned about the time it takes to set up the
network for a new service. Slicing of the network for different
services/operator use cases provides separation of concerns that can
result in a faster setup of a network slice for a certain service as it is
separately managed and with limited impact on other slices.

• Optimized use of resources

- Today the network is supporting many different services but with

new use cases and more diverging requirements there is a need for
optimizing the network for the specific use case. Network slicing
allows to match services to optimized network instances, and it also
allows for a more optimized use of those specific resources

• Allows for individual network statistics

- With service specific network slices, there is a possibility of

collecting network statistics specific for a limited and well defined
group of users of the slice. This is not the key driver for slicing but
rather a benefit that can be a useful tool. The network slicing
mechanisms are the base for how physical systems can coexist with
virtual systems and how gradual migration from physical to virtual
systems can be done.

1.6 Communication
Communication is one of several VNSs for vEPC.

Operators worldwide are currently launching IMS-based voice and video calling
services over LTE and Wi-Fi access.

The Wi-Fi Calling can be performed from SIM based mobile devices or multi-
device. It offers a simple solution for voice and video calls – one that is fully
integrated with modern smartphones and does not require any additional
application. As such, the introduction of Wi-Fi Calling is expected to have an
impact on the use of OTT VoIP solutions, as well as fixed telephony offerings.

The VNS Communication contains the market leading EPC to support end-to-end
VoLTE and Wi-Fi calling solution.

LZT1381721 R3A © Ericsson AB 2017 - 109 -

 Virtual EPC Overview

1.6.1 Packaging
The VNS Communication is built up by one Base package and four Value
Packages (VPs). The VPs can be added to the Communication Base package
independent of each other.

1.6.1.1 Communication Base Package

The Communication Base Package is mandatory and contains the starting point
for the solution focusing on providing an easy and fast deployment of the VNFs
to offer Voice over LTE and Wi-Fi calling services.

› Communication Base Package

vEPC Communication
› Video Calling
Service Continuity Location Services
› Network Assurance and Efficiency
Network Assurance
Video Calling
and Efficiency
› Service Continuity
Communication Base Package

› Location Services

Figure 3-24: vEPC communication packages

The benefit for the operator is to reduce the time needed to introduce new
communication services. In addition, the operator is able to provide the solution
in a cost efficient way.

The Package Communication Base covers mobile access with some basic voice
over LTE functionality as well as basic Wi-Fi calling capabilities. These include
for example:

• VoLTE support

• Online and Offline Charging for Wi-Fi Calls

• Wi-Fi Calling over managed/trusted Wi-Fi networks

• Integration of Secure Entitlement Server

• Entitlement Service Fallback for 3G Users

• Seamless Handover between LTE and Untrusted Wi-Fi

• S2b Interface for Untrusted WLAN and 3GPP Interworking

• Integration with external HSS for Authentication and Authorization

- 110 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Implementation

• Multiple PDN Connection for Untrusted Wi-Fi Access

• Introduction of DSC for Wi-Fi calling

• Wi-Fi calling for multi-device solution

• Emergency Call for Multi-Device

More advanced solutions can be offered with the VPs.

1.6.1.2 VP Service Continuity

The VP Service Continuity provides seamless service continuity between Packet

Switch and Circuit Switch or between Access Pointes when the call is over Wi-
Fi. These include for example:

• Seamless Inter Access Point handover for Wi-Fi Calling with same SSID
and subnet

• SRVCC

• Keeping IMS APN in 2G/3G

1.6.1.3 VP Video Calling

The VP Video Calling enables the operators to run video calls over the LTE or
Wi-Fi access. These include for example:

• Video Call over LTE

• Video Call over Wi-Fi

• Time based charging for video call over Wi-Fi

• Video Call seamless handover between Wi-Fi and LTE

• Offline Charging for Video Call over Wi-Fi

1.6.1.4 Location Services

The VP Location Services makes the location based service and service control
possible. These include for example:

• Wi-Fi Calling restriction when abroad based on in/out home country

• Wi-Fi calling restriction over unmanaged/untrusted Wi-Fi networks

• Wi-Fi Calling charging when abroad based on Device provided location

information

LZT1381721 R3A © Ericsson AB 2017 - 111 -

 Virtual EPC Overview

• Wi-Fi Calling restrictions when abroad based on device provided

location

• ULI Support over Untrusted Wi-Fi

• Wi-Fi Calling restriction when abroad based on Network provided Info

• Wi-Fi Calling Offline Charging when Abroad Based on Network

Provided Information

• Offline Charging for seamless handover between LTE & untrusted Wi-Fi

• Wi-Fi calling restriction when abroad for multi-device

• Offline charging differentiation of Wi-Fi calling for multi-device

• PCC-based Network Provided Location Information

1.6.1.5 VP Network Assurance and Efficiency

The VP Network Assurance and Efficiency improves operators' network analysis

and management capabilities as well as continually enhance network efficiency.
These include for example:

• KPI for Wi-Fi Calling (Phase 1)

• Advanced Troubleshooting for ENIW Solution (Phase 1)

• End to end QoS for Voice over Wi-Fi over Managed Wi-Fi (Phase I)

• Wi-Fi Calling Geo-redundancy

• Geo-redundancy of Wi-Fi calling with DSC Deployment

• Geo-redundancy of Wi-Fi calling for multi-device

• KPI of Wi-Fi calling for multi-device

• Configurable mapping of QoS between EPC and backbone

• EBM Events

• External Policy Database

• Geo-redundancy for Policies

- 112 - © Ericsson AB 2017 LZT1381721 R3A

vEPC Implementation

Base Package Value Package: Location Services

• Online and Offline Charging for Wi-Fi Calls • Wi-Fi Calling restriction when abroad based on in/out home
• Wi-Fi Calling over managed/trusted Wi-Fi networks country
• Integration of Secure Entitlement Server • Wi-Fi calling restriction over unmanaged/untrusted Wi-Fi networks
• Entitlement Service Fall back for 3G Users • Wi-Fi Calling charging when abroad based on Device provided
• VoLTE support location information
• Wi-Fi Calling restrictions when abroad based on device provided
• Seamless Handover between LTE and Untrusted Wi-Fi
location
• S2b Interface for Untrusted WLAN and 3GPP • ULI Support over Untrusted Wi-Fi
Interworking • Wi-Fi Calling restriction when abroad based on Network provided
• Integration with external HSS for Authentication and Information
Authorization • Wi-Fi Calling Offline Charging when Abroad Based on Network
• Multiple PDN Connection for Untrusted Wi-Fi Access Provided Information
• Introduction of DSC for Wi-Fi calling • Offline Charging for seamless handover between LTE and
• Wi-Fi calling for multi-device solution untrusted Wi-Fi
• Emergency Call for multi-device solution • Wi-Fi calling restriction when abroad for multi-device
Value Package: Service Continuity • Offline charging differentiation of Wi-Fi calling for multi-device
• PCC based NPLI
• Seamless Inter Access Point handover for Wi-Fi Calling
with same SSID and subnet Value Package: Network Assurance and
• SRVCC Efficiency
• Keeping IMS APN in 2G/3G • KPI for Wi-Fi Calling (Phase 1)
• Advanced Troubleshooting for ENIW Solution (Phase 1)
Value Package: Video Calling • End to end QoS for Voice over Wi-Fi over Managed Wi-Fi (Phase
I)
• Video Call over Wi-Fi • Wi-Fi Calling Geo-redundancy
• Video Call over LTE • Geo-redundancy of Wi-Fi calling for multi-device
• Time based charging for video call over Wi-Fi • Geo-redundancy of Wi-Fi calling with DSC deployment
• Video Call seamless handover between Wi-Fi and LTE • Geo redundancy for Policies
• Offline Charging for Video Call over Wi-Fi • KPI of Wi-Fi calling for multi-device
• Configurable mapping of QoS between EPC and backbone
• EBM Events
• External Policy Database

Figure 3-25: Market leading full feature set

2 Summary

Upon completion of this chapter, the student should now be

able to:
› Describe the Ericsson's vEPC for Internet of things IoT, meaning the
solution for IoT services which consists of vEPG, vSAPC and vSGSN-
MME VNFs

› Explain the Ericsson's Distributed MBB broadband

› Explain other network services of vEPC Business Solution

Figure 3-26: Summary

LZT1381721 R3A © Ericsson AB 2017 - 113 -

 Virtual EPC Overview

Intentionally Blank

- 114 - © Ericsson AB 2017 LZT1381721 R3A

Acronyms

4 Acronyms

BGW Border GateWay

BPCF Broadband Policy Control Function

CEE Cloud Execution Environment

CIC Controller nodes within a cloud environment

DC Data Center

DMTF Distributed Management Task Force

DPDK Data Plane Development Kit

ECIM Ericsson Common Information Model

ECM Ericsson Cloud Manager

EVS Ericsson Virtual Switch

IoT Internet of Things

KVM Kernel-based Virtual Machine.

LB Load Balancer

MANO MANagement and Orchestration

MBB Mobile BroadBand

MVNO Mobile Virtual Network Operator

NFV Network Function Virtualization

NFVI NFV Infrastructure

NFVO NFV Orchestrator

OVA Open Virtualization Archive

LZT1381721 R3A © Ericsson AB 2017 - 115 -

 Virtual EPC Overview

OVF Open Virtualization Format

OVS Open vSwitch

PCEF Policy and Charging Enforcement Function

PCRF Policy and Charging Rules Function

PNF Physical Network Function

POD Performance Optimized Data center

SAN Storage Area Network

ToR Top of the Rack

VDU Virtual Deployment Unit

VIM Virtualized Infrastructure Manager

VM Virtual Machine

VMM Virtual Machine Manager

VNF Virtual Network Function

VNS Virtual Network Service

- 116 - © Ericsson AB 2017 LZT1381721 R3A

Index

5 Index

A POD and its software, 40 Internet of Things, a Virtual EPC Network

Backup and Restore, 43 Service, 115
Benefits of Ericsson’s vEPC, 27, 28 Introduction, 7, 8, 34, 84, 111
Border GateWay, 21, 84, 93, 94, 115 Kernel-based Virtual Machine, 115
Broadband Policy Control Function, 115 Kernel-based Virtual Machine., 34, 115
CEE, 34, 35, 36, 37, 39, 41, 42, 43, 45, 46, KVM, 115
47, 53, 55, 56, 57, 58, 63, 77, 78, 79, 85, LB, 115
91, 94, 115 Load Balancer, 47, 48, 115
CEE High Availability, 43 Main vEPC challenges, 19
Classical implementations, 16, 17 MANagement and Orchestration, 15, 115
Cloud deployment variants, 54 MANO, 115
Cloud Execution Environment, 34, 35, 36, 37, MBB, 115, 116
39, 41, 42, 43, 45, 46, 47, 53, 55, 56, 57, Mobile BroadBand, 26, 40, 90, 96, 103, 104,
58, 63, 77, 78, 79, 85, 91, 94, 115, 120 105, 107, 108, 115, 121
Commands in ECM and CCE, 77 Mobile Virtual Network Operator, 106, 115
Controller nodes within a cloud environment, MVNO, 115
34, 35, 55, 56, 77, 79, 115, 120 Network Function Virtualization, 8, 10, 13, 14,
Data Center, 17, 51, 115, 119 15, 16, 25, 26, 27, 29, 30, 34, 36, 59, 84,
Data Plane Development Kit, 115 115, 119, 120
Distributed Management Task Force, 41, 115 NFV, 16, 39, 40, 42, 115
Ericsson Cloud Manager, 34, 35, 37, 42, 45, NFV Infrastructure, 16, 39, 40, 115
46, 52, 53, 58, 63, 77, 79, 80, 91, 115, 120 NFV Orchestrator, 42, 115
Ericsson Common Information Model, 115 One network – multiple industries, 27
Ericsson TTM uniqueness taking a holistic Open Virtualization Archive, 41, 52, 115
approach, 30 Open Virtualization Format, 15, 40, 41, 42,
Ericsson Virtual Switch, 35, 42, 115 47, 52, 116
ETSI NFV Cloud Reference Architecture, 34 Open vSwitch, 42, 116
Examples of some of the available Our NFV Offering Options, 29
commands, 79 Overview - The EPC Network, 9, 10
From HW integrated to Cloud/Telco DC PCEF, 116
deployment, 17 PCRF, 116
Fuel, 35, 36, 77, 78, 94 Performance Optimized Data center, 40, 41,
Horizontal scalability, 55 51, 55, 116, 120
How to Define Bill of Material for vEPC Physical Network Function, 116
Scalable Deployment, 57 Policy and Charging Enforcement Function,
Hybrid Networks, 17, 18 116
Hypervisor and Ericsson Virtual Switch, 42 Policy and Charging Rules Function, 9, 93,
Internet of Things, 86, 87, 88, 89, 90, 115, 116
121 Scalable deployment:, 55
Seamless & Secure Introduction, 31

LZT1381721 R3A © Ericsson AB 2017 - 117 -

 Virtual EPC Overview

Service flexibility EPC Virtual network Virtual EPC, 8, 25, 26, 27, 28, 32, 84
services, 31 Virtual Machine, 21, 40, 41, 42, 46, 47, 48,
Service Models, 38 49, 51, 59, 66, 67, 80, 116
Storage, 34, 35, 39, 42, 52, 62, 67, 68, 78, Virtual Machine XE "Virtual Machine"
116 Manager, 116
Storage Area Network, 52, 116 Virtual Machines, 40, 59
Summary, 32, 81, 113 Virtual Network Function, 15, 20, 21, 25, 30,
The Distributed Management Task Force is 40, 41, 42, 43, 46, 47, 48, 49, 50, 51, 52,
an industry standards organization., 115 53, 55, 56, 57, 58, 61, 63, 67, 72, 73, 84,
The speed challenge from opportunity to 85, 86, 88, 91, 100, 103, 104, 107, 116,
launched solution, 30 120
Top of the Rack, 21, 48, 51, 116 Virtual Network Service, 40, 86, 90, 96, 98,
ToR, 116 99, 100, 103, 104, 105, 108, 109, 110, 116,
vEPC – Optimized with flexibility, 32 121
vEPC - Supporting key network services, 8 Virtualization, 10, 11, 12, 13, 34, 36, 41, 84,
vEPC Architecture Principal, 43 115, 116
vEPC Cloud support Ericsson and 3rd party Virtualized EPC VNF Descriptions, 43
execution environments, 28 Virtualized Infrastructure Manager, 16, 34,
vEPC Components and Architecture, 33 39, 42, 79, 116
vEPC Deployments, 53 VNF single server deployment:, 56
vEPC Functionality & Features, 18 vWMG, 25, 46, 74, 75, 76, 77, 99, 107
vEPC Network, 16, 50 What is vEPG?, 59
vEPC scaling dimensions, 54 What is vSAPC?, 69, 70
vEPC value Packages, 26 What is vSGSN-MME?, 63, 64
Virtual Deployment Unit, 42, 116

- 118 - © Ericsson AB 2017 LZT1381721 R3A

Table of Figures

6 Table of Figures

Figure 1-1: Objectives ..................................................................................................................... 7

Figure 1-2: Virtual EPC Network Services ....................................................................................... 8
Figure 1-3: Overview - The EPC Network ..................................................................................... 10
Figure 1-4: Hardware Virtualization ............................................................................................... 11
Figure 1-5: Virtualization and Cloud .............................................................................................. 11
Figure 1-6: Benefits of virtualization – Freedom ............................................................................ 12
Figure 1-7: Ericsson Cloud System ............................................................................................... 13
Figure 1-8: Vision of ISG NFV ....................................................................................................... 14
Figure 1-9: ETSI NFV Ref Architecture Ericsson Product Mapping ............................................... 15
Figure 1-10: ETSI NFV Ref Architecture VMware vCloud Product Mapping .................................. 15
Figure 1-11: vEPC Architecture Classical implementations ........................................................... 16
Figure 1-12: vEPC Architecture Classical implementations ........................................................... 17
Figure 1-13: From Hardware integrated to Cloud/Telco DC deployment ....................................... 17
Figure 1-14: Hybrid Networks........................................................................................................ 18
Figure 1-15: SGSN-MME interworking between Native and Virtual ............................................... 18
Figure 1-16: vEPC Functions ........................................................................................................ 19
Figure 1-17: Implementation Challenge #1 – Availability ............................................................... 20
Figure 1-18: VEPC – High Availability ........................................................................................... 20
Figure 1-19: MME NW-Level Session continuity (Geo-redundant Pool) ........................................ 21
Figure 1-20: MME NW-LEVEL Session continuity (Geo-redundant Pool) ...................................... 22
Figure 1-21: Gateway Inter-site redundancy ................................................................................. 23
Figure 1-22: Implementation Challenge #2 – Performance ........................................................... 23
Figure 1-23: Implementation Challenge #3 – Network separation ................................................. 24
Figure 1-24: Implementation Challenge #4 – Security & Integrity .................................................. 24
Figure 1-25: Implementation Challenge #5 – Cloud Agnostic ........................................................ 25
Figure 1-26: Ericsson vEPC NFV compliant architecture .............................................................. 25
Figure 1-27: Virtual EPC ............................................................................................................... 26
Figure 1-28: One network – multiple industries ............................................................................. 27
Figure 1-29: Benefits of Ericsson’s vEPC ...................................................................................... 28
Figure 1-30: vEPC Cloud support -Ericsson and 3rd party ........................................................... 28
Figure 1-31: Our NFV Offering Options ......................................................................................... 29
Figure 1-32: Flexibility in deployment ............................................................................................ 29
Figure 1-33: Speed challenge -Opportunity to launch ................................................................... 30
Figure 1-34: Ericsson TTM uniqueness taking a holistic approach ................................................ 30
Figure 1-35: Service flexibility EPC Virtual network services ......................................................... 31
Figure 1-36: Seamless & Secure Introduction ............................................................................... 31
Figure 1-37: vEPC – Optimized with flexibility ............................................................................... 32
Figure 1-38: Summary .................................................................................................................. 32

LZT1381721 R3A © Ericsson AB 2017 - 119 -

 Virtual EPC Overview

Figure 2-1: Objectives ................................................................................................................... 33

Figure 2-2: ETSI NFV Ref Architecture Ericsson Product Mapping ............................................... 34
Figure 2-3: CEE, CIC, and Openstack .......................................................................................... 35
Figure 2-4: Openstack .................................................................................................................. 36
Figure 2-5: Atlas ........................................................................................................................... 37
Figure 2-6: Ericsson Cloud Manager ............................................................................................. 38
Figure 2-7: A generalized logical view of a typical POD with VNF and the CEE infrastructure....... 41
Figure 2-8: CEE High Availability Network .................................................................................... 43
Figure 2-9: High Level Architectural .............................................................................................. 44
Figure 2-10: High Level Architectural ............................................................................................ 44
Figure 2-11: High Level Architectural – Main node functions ......................................................... 45
Figure 2-12: vEPC VNF ................................................................................................................ 46
Figure 2-13: vEPC VNF Networking .............................................................................................. 47
Figure 2-14: vEPC VNF Typical Packet Flow ................................................................................ 48
Figure 2-15: vEPC Network Separation ........................................................................................ 49
Figure 2-16: vEPC High Availability Levels ................................................................................... 50
Figure 2-17: VNF Deployment ECM/CEE Example ....................................................................... 53
Figure 2-18: vEPC Deployment Options ....................................................................................... 53
Figure 2-19: Cloud Deployment Variants ...................................................................................... 54
Figure 2-20: vEPC Scaling Dimensions ........................................................................................ 54
Figure 2-21: Horizontal scalability ................................................................................................. 55
Figure 2-22: Scalable vEPC Data Center deployment ................................................................... 55
Figure 2-23: Single VNF single server........................................................................................... 56
Figure 2-24: Single VNF Multiple Servers ..................................................................................... 56
Figure 2-25: vEPC scalable deployment including ECM and CEE ................................................ 57
Figure 2-26: How to Define Bill of Material for vEPC Single Server per VNF Deployment ............. 57
Figure 2-27: What is a vEPG?....................................................................................................... 58
Figure 2-28: vEPG High Level Architectural Overview .................................................................. 59
Figure 2-29: vEPG Deployment variants ....................................................................................... 59
Figure 2-30: vEPG 16B Single VNF Multiple Servers .................................................................... 60
Figure 2-31: vEPG Deployment Example -Single VNF Single Server............................................ 60
Figure 2-32: vEPG High Availability .............................................................................................. 61
Figure 2-33: vEPG Storage ........................................................................................................... 61
Figure 2-34: vEPG resilience functions ......................................................................................... 62
Figure 2-35: What is vSGSN-MME?.............................................................................................. 63
Figure 2-36: vSGSN-MME High Level Architectural ...................................................................... 63
Figure 2-37: Virtual SGSN-MME conceptual view ......................................................................... 64
Figure 2-38: vSGSN-MME Deployment variants ........................................................................... 65
Figure 2-39: vSGSN-MME Single VNF Multiple Servers ............................................................... 66
Figure 2-40: vSGSN-MME Storage ............................................................................................... 67
Figure 2-41: vSGSN-MME resilience functions ............................................................................. 67
Figure 2-42: What is vSAPC? ....................................................................................................... 69
Figure 2-43: vSAPC architecture................................................................................................... 70
Figure 2-44: vSAPC High Level Architectural Overview ................................................................ 70
Figure 2-45: vSAPC Deployment variants ..................................................................................... 71
Figure 2-46: vSAPC Single VNF Multiple Servers ......................................................................... 71
Figure 2-47: vSAPC Single Server Deployment ............................................................................ 72
Figure 2-48: vSAPC resilience functions ....................................................................................... 72
Figure 2-49: Untrusted Wi-Fi Architecture ..................................................................................... 73
Figure 2-50: Trusted Wi-Fi Architecture ........................................................................................ 74
Figure 2-51: vWMG High Level Architectural Overview ................................................................. 74
Figure 2-52: vWMG High Level Architecture – Maximum Configuration ........................................ 75

- 120 - © Ericsson AB 2017 LZT1381721 R3A

 Table of Figures

Figure 2-53: vWMG Deployment variants ..................................................................................... 75

Figure 2-54: vWMG Scalable Deployment .................................................................................... 76
Figure 2-55: vEPC Data Center .................................................................................................... 78
Figure 2-56: Summary .................................................................................................................. 80
Figure 3-1: Objectives ................................................................................................................... 83
Figure 3-2: Virtual EPC Network Services ..................................................................................... 84
Figure 3-3: System verified deployment models Providing predictable performance .................... 85
Figure 3-4: IoT is a different business addressed by Ericsson ...................................................... 87
Figure 3-5: Key Vertical segments ................................................................................................ 87
Figure 3-6: Massive IOT E2E offering ........................................................................................... 88
Figure 3-7: vEPC Base and Value Packages Internet of things ..................................................... 88
Figure 3-8: Policy Control - Internet of Things ............................................................................... 89
Figure 3-9: Benefits....................................................................................................................... 89
Figure 3-10: Distributed MBB Network Overview .......................................................................... 90
Figure 3-11: vEPC Value Packages .............................................................................................. 91
Figure 3-12: vThunder licensing .................................................................................................... 91
Figure 3-13: Validated Deployment ............................................................................................... 94
Figure 3-14: Use cases I ............................................................................................................... 95
Figure 3-15: Use cases II .............................................................................................................. 96
Figure 3-16: Benefits..................................................................................................................... 97
Figure 3-17: Packages defined for VNS Enterprise ....................................................................... 99
Figure 3-18: Enterprise Deployment Alternative I ........................................................................ 101
Figure 3-19: Enterprise Deployment Alternative II ....................................................................... 102
Figure 3-20: Use Cases .............................................................................................................. 103
Figure 3-21: MBB VNS Cloud Deployment Options .................................................................... 104
Figure 3-22: MBB Packaging ...................................................................................................... 105
Figure 3-23: Network slicing ........................................................................................................ 108
Figure 3-24: vEPC communication packages.............................................................................. 110
Figure 3-25: Market leading full feature set ................................................................................. 113
Figure 3-26: Summary ................................................................................................................ 113

LZT1381721 R3A © Ericsson AB 2017 - 121 -