Technische Universitt Mnchen

Lehrstuhl fr Kommunikationsnetze
Prof. Dr.-Ing. W. Kellerer

A Virtual SDN-enabled LTE EPC Architecture:

a case study for S-/P-Gateways functions

15.November.2013
Treffen der VDE/ITG-Fachgruppe 5.2.4

Arsany Basta
Wolfgang Kellerer Technische Universitt Mnchen, Germany

Marco Hoffmann
Klaus Hoffmann
Ernst-Dieter Schmidt Nokia Solutions and Networks, Munich, Germany
 Future network requirements?

Source: Marco Hoffmann, NSN 2

 Why change the current EPC architecture?

Current EPC built out of monolithic entities on dedicated hardware

Inflexible and lacks dynamic deployment

Induces high cost to setup and maintain

X2 S10

S1- S6a Gx
eNodeB Signaling
MME
MME HSS PCRF OCS

E-UTRAN
Data Traffic S7
S1-U S11 Gy

S5/S8 SGi
NodeB RNC SGSN S-GW P-GW IP Domain
S4
UTRAN
LTE Evolved Packet Core (EPC)

3
 How to change EPC architecture?

Automated platform Network abstraction

for network functions and flexible dynamic
in software programmability
Cloud
Computing

Enabler for cost, energy consumption and space reduction by

sharing, isolating and splitting of network functions [1]

4
[1] Network Operators, Network Functions Virtualization, SDN World Congress, Darmstadt, 2012
 What do NFV and SDN bring to the mobile core?

NFV Availability of incremental functionality additions to the network

SDN More flexibility in network management and control

NFV
+ More elasticity in adding or removing services
SDN
NFV Optimizing network configuration and topology
+
SDN

Potential to reduce time to market

Potential for reducing energy consumption

Potential for a reduced capex and opex cost

5
 EPC potential for virtualization?

Migration to the operators cloud can start with control-plane EPC nodes
such as MME, HSS, PCRF, etc...

Operators
S10 Cloud Virtual EPC Components

S6a Gx
MME HSS PCRF OCS
Gy
X2 S7
Signaling
S1-
MME
eNodeB

Data Traffic
S1-U S11

Transport Network
S5/S8 SGi
SGSN S-GW P-GW IP PDN
S4

Focus of our study is the data-plane coupled EPC nodes: S-GW and P-GW
6
 What are the study steps?

Decompose S-GW/P-GW functions

SDN (OpenFlow 1.3) realization

of derived functions

Deployment architectures:
decomposed functions between
cloud and transport network
7
S-GW / P-GW ANALYSIS

8
 S-GW and P-GW Analysis

The roles of the S-GW and P-GW were observed in fundamental 3GPP
standard scenarios such as UE attach/detach, handover, TA update, etc ..

Resources
Control
Allocation
Signaling
Logic

Data-plane Forwarding Rules

Packet GTP
Charging
Filtering Matching

Data-plane Forwarding

9
OPENFLOW REALIZATION OF
DERIVED FUNCTIONS

10
 OpenFlow Realization of Derived Functions

Control-related functions can be

integrated in an SDN controller
Resources
Control
Allocation
Signalng Forwarding rules and data
Logic
forwarding are fundamental
functions of a basic OF switch
Data-planeForwarding Rules
Packet filters (P-GW) can be
Packet GTP provided based on the IP-five
Charging tuple [2] starting from OF 1.0
Filtering Matching

Data-plane Forwarding Charging (P-GW) and GTP header

matching (S-GW and P-GW) still
need further evaluation

[2] 3GPP TS 23.203, Policy and charging control architecture, 2010 11

 Charging (Offline and Online) Frameworks

Offline Charging
OF Controller OF Controller
CDR Event

OF Stats OF Stats OF Stats OF Stats

Event
trigger:
Update
Counters Counters Counters Counters
Rules
Data Traffic Data Traffic
OF Switch OF Switch OF Switch OF Switch
a) Offline charging b) Online charging

Controller collect offline Of switch keeps no data flow state

CDRs based on OF stats No charging events possible on switch
Optimize OF stats to match Controller keeps track of charging events
different charging models and update rules accordingly
12
 GTP Matching Frameworks
UE EPC

payload IP GTP UDP IP

OF Controller
OF Controller
GTP
Module
GTP rules
Data traffic Middlebox
no matching rules Rules from controller: GTP
Forward * to controller in: * / out: middlebox

Data Traffic Data Traffic

OF NE OF NE

a) Controller handling GTP matching b) Middlebox handling GTP matching

OF Controller OF Controller

Rules from controller: Rules from controller:

GTP matching GTP matching

GTP SW
Data Traffic GTP HW Data Traffic
SW platform
Customized

OF NE+ OF NE+

c) NE+ with customized HW d) NE+ with SW platform 13

DECOMPOSED FUNCTIONS
DEPLOYMENT ARCHITECURES

14
 Functions deployment possibilities?

1) Full Cloud Migration

S10
S11
Control Signaling
Resources SGW-c
Charging
MME Management PGW-c
Logic GTP
Operators
Controller Cloud
S1-MME SDN API
Signaling
X2
U-Plane SGW-u
S1-U Filtering PGW-u
Forwarding Rules
eNodeB Data Traffic
U-Plane Fabric NE
S4-c

S4-u SGi
SGSN IP PDN

+ noticeable cost savings limited by cloud domain

+ control-plane scalability all data traffic to cloud

+ standard OF switch SDN is not fully exploited 15

 Functions deployment possibilities?

2) Control-plane Cloud Migration

+ control-plane scalability
SGW-c PGW-c
+ data-plane scalability
S10 S5
Control
MME
S11
Signaling
Operators
+ on-demand data plane
Cloud
Resources
S1-MME Management
X2 Signaling Logic enhanced OF switch
Controller
eNodeB data overhead between
S1-U
Data Traffic SDN API
Transport
cloud and transport
Network
S4-c
Charging U-Plane cost savings are reduced
Forwarding GTP
SGSN Filtering Rules
S4-c
SGi
U-Plane Fabric IP PDN

SGW-u PGW-u NE+

16
 Functions deployment possibilities?

3) Signaling control Cloud Migration

+ less configuration delay
SGW-c PGW-c
+ less data overhead
S10
Control Operators
S11
Signaling Cloud + more resilient to
MME
cloud outages
S1-MME
Signaling
X2
cloud migration is minimal
eNodeB Transport
S1-U
Network
global network view is
Data Traffic

not available anymore

Controller

Resources U-Plane
SDN API

S4-C
Management Forwarding GTP
SGSN S4-U
Logic Rules
Filtering SGi
U-Plane Fabric IP PDN
Charging
SGW-c PGW-c
NE+
SGW-u PGW-u 17
 Functions deployment possibilities?

4) Scenario based Cloud Migration

Control Signaling
SGW-c PGW-c
+ possible offloading of certain
SGW-c
Resources
S10
Management
Charging PGW-c EPC operations or service types
S11
MME Logic GTP
Operators
Controller
Cloud
+ highest scalability and flexibility
S1-
MME SDN API
Signaling
U-Plane SGW-u
X2 Filtering
Forwarding Rules PGW-u
U-Plane Fabric NE state sync overhead
eNodeB S11
S1-U
Data Traffic
SDN API
State Sync orchestration between
Updates
Transport
S4-C Network
functions is needed
Controller

Control Resources U-Plane

additional cost induced
SDN API

SGSN S4-C
Signaling Management Forwarding
S4-U Logic Rules
Filtering
Charging SGi
U-Plane Fabric IP PDN
GTP
SGW-c PGW-c
NE+ 18
SGW-u PGW-u
 Conclusion

Study goals?

EPC analysis: decompose S-GW and P-GW functions

SDN capabilities to achieve the EPC functionalities

Alternative solutions to enhance OF network elements:

a) Controller-based processing

b) Middlebox-based processing

c) NE+ with HW customized functions

d) NE+ with a programmable SW extension

Deployment possibilities of the EPC nodes and functionalities

Four alternative deployment architectures, between cloud and transport network

Each architecture has its own advantages and limitations

19
 Outlook

Performance evaluation and trade-offs:

current EPC architecture Vs virtual SDN-enabled architectures

Cost evaluation
Optimal functions splitting solution
Exchanged data overhead
considering performance
Observed additional delays

S-/P-GW
cost
data
KPI overhead
value
end-to-end
delay

no functions all functions

at cloud at cloud
t
en g ing P/ s/
ling em rin GT Rule
n a g
na ic Filte arg e 20
Sig Ma Log Ch
Plan bric
U - Fa
 Thank you for your attention

Questions?

A.Basta, W. Kellerer, M. Hoffmann, K. Hoffmann, E.D. Schmidt, A Virtual SDN-enabled LTE EPC:
Architecture: a case study for S-/P-gateways functions, IEEE SDN4FNS, Trento, 2013
21