A Virtual SDN-enabled LTE EPC Architecture: a case...

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

11.November.2013

IEEE SDN for Future Networks and Services (SDN4FNS)

Arsany Basta Wolfgang Kellerer

Marco Hoffmann Klaus Hoffmann Ernst-Dieter Schmidt

Technische Universität München, Germany

Nokia Solutions and Networks, Munich, Germany

2

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

3

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]

Deployment platform for network functions

in software

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

Cloud

Computing

4

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 services scaling up/down

• Optimizing network configuration and topology

• Potential for reducing energy consumption

• Potential for a reduced capex and opex cost

5

EPC potential for virtualization?

Data Traffic

eNodeB Signaling

X2

HSS PCRF OCS

S5/S8

S1-MME

MME

S10

S1-U

SGi

S6a

S7Gy

Gx

IP DomainP-GW

S11

S4

S-GWSGSN

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 DomainP-GW

S11

S4

S-GWSGSN

Transport Network

• Control-plane EPC nodes such as MME, HSS, PCRF, etc... impose not much effort to virtualize and migrate to an operator’s cloud

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

6

Study steps

S-GW/P-GW functions analysis

Deployment architectures for the virtual SDN-enabled

S-GW and P-GW

SDN (OpenFlow) realization of derived functions

7

S-GW and P-GW derived functions

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 filtering (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&P-GW) still need further evaluation

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

OpenFlow functions realization

Functions analysis

Deployment architectures

SDN (OF) realization

Functions analysis


8

Charging frameworks

• Module to 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

• Not possible to allocate triggers on switch

• Module to keep track of charging events

and update accordingly

Functions analysis



9

• GTP: IP-tunneling protocol used to encapsulate signaling and data in EPC

GTP matching frameworks

no matching rulesForward * to controller

GTP Module

OF “NE“

Dat

a tr

affi

c

OF Controller

Data Traffic

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

Functions analysis



10

X2

U-Plane Fabric

U-Plane Forwarding

Rules

Control Signaling

Resources Management

Logic

SDN API

Signaling

Data Traffic

SGSN

MME

eNodeB

GTPFiltering

Charging

S/P-GWs Control/Data-plane

Operator’s Cloud

IP PDN

Controller

NE

S1-MME

S11

S1-U

S4-U

S4-C

SGi

S10

Functions deployment possibilities?

1) Full Cloud Migration

still very centralized

All data traffic to cloud

SDN is not fully exploited

+ noticeable cost savings

+ control-plane scalability

+ standard OF switch

Functions analysis



11


2) Control-plane Cloud Migration

S10

X2

eNodeB

Charging U-Plane Fabric

U-Plane Forwarding

Rules

Control Signaling


Logic

SDN API

Signaling

Data Traffic

SGSN

MME

GTP

S/P-GWs Control-plane

IP PDN

Operator’s Cloud

Filtering

S/P-GWs Data-plane

Controller

NE+ / NE with Middlebox

S1-MME

S11

S1-U

S4-U

S4-C

SGi

enhanced OF switch

data overhead between

cloud and transport network

cost savings are reduced

+ control-plane flexibility

+ data-plane scalability

+ on-demand data plane resources

Functions analysis



12


3) Signaling control Cloud Migration

S10

X2

U-Plane Fabric

U-Plane Forwarding

Rules

Control SignalingSignaling

Data TrafficResources

Management Logic

SDN API

SGSN

MME

eNodeB

GTP

Charging

Filtering


Operator’s Cloud

IP PDN



Controller

S1-MME

S11

S1-U

S4-U

S4-C

SGi

cloud migration is minimal

global network view is not

available anymore

+ possible less configuration delay

+ possible less data overhead

+ more resilient to cloud outages

or connection failures

Functions analysis



13


4) Scenario based Cloud Migration

S10

X2

Data Traffic

Classification Filters

U-Plane Fabric

U-Plane Forwarding

Rules

Control Signaling

Signaling


Logic


Logic

SDN API

SGSN

MME

eNodeB

GTP

ChargingFiltering

State Sync Updates

Operator’s Cloud



SDN

AP

I

Controller


IP PDN

Data plane statistics

FilteringCharging

S1-MME

S11

S1-U

S4-U

S4-C

SGi

state sync overhead

orchestration between

functions is needed

additional cost induced

+ possible offloading of certain

EPC operations or service types

+ highest scalability and flexibility

Functions analysis



14

Conclusion and Outlook

Study goals?

• EPC analysis: derive 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

15

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

• Exchanged data overhead

• Observed additional delays

• Cost evaluation

Optimal functions’ splitting solution

considering all given parameters

16

Thank you for your attention

Questions?

A Virtual SDN-enabled LTE EPC Architecture: a case...

Documents

Transcript of A Virtual SDN-enabled LTE EPC Architecture: a case...