Technische Universität München

Lehrstuhl für 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

Marco Hoffmann Klaus Hoffmann Ernst-Dieter Schmidt

Technische Universität München, Germany

Nokia Solutions and Networks, Munich, Germany

2

Future network requirements?

Source: Marco Hoffmann, NSN

3

Data Traffic

eNodeB Signaling

X2

HSS PCRF OCS

S5/S8

S1-MME

MME

S10

S1-U

SGi

LTE Evolved Packet Core (EPC)

S6a

S7Gy

Gx

IP DomainP-GW

E-UTRAN

S11

S4

S-GW

UTRAN

SGSNNodeB RNC

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

4

How to change EPC architecture?

Network abstraction and flexible dynamic

programmability

Enabler for cost, energy consumption and space reduction by sharing, isolating and splitting of network functions [1]

Automated platform for network functions

in software

[1] Network Operators, “Network Functions Virtualization“, SDN World Congress, Darmstadt, 2012

Cloud

Computing

5

What do NFV and SDN bring to the mobile core?

Availability of incremental functionality additions to the network

More flexibility in network management and control

More elasticity in adding or removing services

Optimizing network configuration and topology

• Potential to reduce time to market

• Potential for reducing energy consumption

• Potential for a reduced capex and opex cost

NFV

SDN

SDN

NFV +

SDN

NFV +

6

Operator’s Cloud Virtual EPC Components

Data Traffic

eNodeB

SignalingX2

HSS PCRF OCS

S5/S8

S1-MME

MME

S10

S1-U

SGi

S6a

S7Gy

Gx

IP PDNP-GW

S11

S4

S-GWSGSN

Transport Network

EPC potential for virtualization?

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

• Focus of our study is the data-plane coupled EPC nodes: S-GW and P-GW

7

What are the study steps?

Decompose S-GW/P-GW functions

Deployment architectures: decomposed functions between

cloud and transport network

SDN (OpenFlow 1.3) realization of derived functions

8

S-GW / P-GW ANALYSIS

9

S-GW and P-GW Analysis

Control Signaling

Resources Allocation

Logic

Data-plane Forwarding Rules

Data-plane Forwarding

GTP Matching

Charging Packet

Filtering

• 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 ..

10

OPENFLOW REALIZATION OF DERIVED FUNCTIONS

11

Control Signalng

Resources Allocation

Logic

Data-planeForwarding Rules

Data-plane Forwarding

GTP Matching

Charging Packet

Filtering

• Control-related functions can be integrated in an SDN controller

• Forwarding rules and data forwarding are fundamental functions of a basic OF switch

• Packet filters (P-GW) can be provided based on the IP-five tuple [2] starting from OF 1.0

• 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

OpenFlow Realization of Derived Functions

12

Charging (Offline and Online) Frameworks

• Controller collect offline

CDRs based on OF stats

• Optimize OF stats to match

different charging models

OF Switch OF Switch

OF Controller

OF Stats OF Stats

Offline CDR

Data Traffic

a) Offline charging

Counters Counters

OF Switch OF Switch

OF Controller

OF Stats

Charging Event

OF StatsEvent

trigger:Update Rules

Data Traffic

b) Online charging

Counters Counters

• Of switch keeps no data flow state

• No charging events possible on switch

• Controller keeps track of charging events

and update rules accordingly

13

GTP Matching Frameworks

no matching rules

Forward * to controller

GTP Module

OF “NE“

OF Controller

Data Traffic

Dat

a tr

affi

c

Rules from controller:

in: * / out: middlebox

OF Controller

OF “NE“

Data Traffic

GTP

Middlebox

GTP rules

OF Controller

Rules from controller:

GTP matching

GTP HW Customized

OF “NE+“

Data Traffic

OF Controller

Rules from controller:

GTP matching

GTP SW

OF “NE+“

SW platformData Traffic

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

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

payload IP GTP UDP IP

UE EPC

14

DECOMPOSED FUNCTIONS DEPLOYMENT ARCHITECURES

15

Functions deployment possibilities?

1) Full Cloud Migration

limited by cloud domain

all data traffic to cloud

SDN is not fully exploited

+ noticeable cost savings

+ control-plane scalability

+ standard OF switch

IP PDN

Data Traffic

SGSN

eNodeB

Signaling

Operator’s Cloud

X2

S1-MME

MME

S10

S1-U

S4-c

SGiS4-u

SGW-u PGW-u

Charging

U-Plane Fabric

U-Plane Forwarding Rules

Control Signaling

Resources Management

Logic

SDN API

Filtering

GTP

NE

Controller

SGW-cPGW-c

S11

16

Control Signaling

Resources Management

Logic

SDN APIData Traffic

SGSN

eNodeB

Signaling

SGW-c PGW-c

Operator’s Cloud

NE+

X2

S5

S1-MME

MME

S10

S1-U

S4-c

U-Plane Fabric

U-Plane Forwarding

Rules Filtering

SGW-u PGW-u

SGi

S4-c

ChargingGTP

Transport Network

Controller

IP PDN

S11

Functions deployment possibilities?

2) Control-plane Cloud Migration

enhanced OF switch

data overhead between

cloud and transport

cost savings are reduced

+ control-plane scalability

+ data-plane scalability

+ on-demand data plane

17

Functions deployment possibilities?

3) Signaling control Cloud Migration

S10

X2

U-Plane Fabric

U-Plane Forwarding

Rules

Control Signaling

Data Traffic

Resources Management

LogicSGSN

MME

eNodeB

Signaling

GTP

Charging

Filtering

SGW-c PGW-c

Operator’s Cloud

SGW-c PGW-cNE+

S1-MME

S11

S1-U

S4-U

S4-C

SGi

Co

ntr

olle

r

SD

N A

PI

SGW-u PGW-u

IP PDN

Transport Network

cloud migration is minimal

global network view is

not available anymore

+ less configuration delay

+ less data overhead

+ more resilient to

cloud outages

18

Functions deployment possibilities?

4) Scenario based Cloud Migration

S10

X2

Data Traffic

U-Plane Fabric

U-Plane Forwarding

Rules

Resources Management

Logic

SGSN

MME

eNodeB

Signaling

GTP

State Sync Updates

Operator’s Cloud

SGW-c PGW-cSGW-u PGW-u

NE+

SDN

AP

I

SGW-c PGW-c

Charging

S1-MME

S11

S1-U

S4-U

S4-C

SGi

Control Signaling

Co

ntr

olle

r

IP PDN

S4-C

Charging

U-Plane Fabric

U-Plane Forwarding Rules

Control Signaling

Resources Management

Logic

Filtering

GTP

NE

Controller

SDN API

Filtering

S11

SGW-cPGW-c

SGW-uPGW-u

Transport Network

SDN API

state sync overhead

orchestration between

functions is needed

additional cost induced

+ possible offloading of certain

EPC operations or service types

+ highest scalability and flexibility

19

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

20

S-/P-GWcost

end-to-end delay

data overhead

Signaling

Management

Logic

KPI value

Filterin

g

ChargingGTP/

U-Plane Rules/

Fabric

no functions at cloud

all functions at cloud

Outlook

• Performance evaluation and trade-offs:

• Cost evaluation

• Exchanged data overhead

• Observed additional delays

Optimal functions’ splitting solution

considering performance

current EPC architecture Vs virtual SDN-enabled architectures

21

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