Optimalisatie van voice calls in 4G...

Academiejaar 2013–2014 Faculteit Ingenieurswetenschappen en Architectuur

Valentin Vaerwyckweg 1 – 9000 Gent

Studie van voice over IP in 4G

netwerken met behulp van OpenEPC

Begeleiders: Pieter WILLEMEN

Dries NAUDTS

Promotoren: dr. ir. Pieter SIMOENS

prof. dr. ir. Ingrid MOERMAN

dr. ir. Daan PAREIT

Jonas ANSEEUW

Masterproef voorgedragen tot het behalen van het diploma van

Master in de industriële wetenschappen: informatica

Powered by TCPDF (www.tcpdf.org)

Woord vooraf

Als laatstejaarsstudent master in de industriele wetenschappen informatica aan Universiteit

Gent heb ik deze scriptie geschreven. Het beschrijft op een gestructureerde wijze wat ik

tijdens mijn masterproef heb gerealiseerd.

Ik wil mijn begeleiders Dries Naudts en Pieter Willemen bedanken die mij telkens begeleid

hebben. Daarnaast wil ik ook mijn interne promotor Pieter Simoens en de externe promotoren

Ingrid Moerman en Daan Pareit bedanke

iv

Abstract

LTE (Long Term Evolution) is de mobiele standaard van de 4e generatie (4G) die momenteel

in Belgie uitgerold wordt door de mobiele netwerkoperatoren (Belgacom, Mobistar, Base) en

is de opvolger van GSM/GPRS/EDGE (2G) en UMTS/HSPA (3G). De netwerkoperatoren

dienen naast de talloze zendmasten ook een kernnetwerk te hebben, waar alle gesprekken

en dataverbindingen correct afgehandeld worden. Om een dergelijk kernnetwerk (de EPC

of Evolved Packet Core) op gewone PC’s te draaien kan er bij de onderzoeksgroep IBCN

gebruikgemaakt worden van het ‘OpenEPC’-software pakket.

Het kernnetwerk EPC biedt voor het eerst in de evolutie van cellulaire netwerken volledige

IP-functionaliteit voor communicatie tussen de verschillende entiteiten. Dit biedt vele moge-

lijkheden voor de optimalisatie van operatornetwerken, maar de huidige implementaties van

EPC en LTE bieden enkel nog maar basisfunctionaliteit aan.

In deze masterproef wordt onderzocht hoe voice over IP gerealiseerd kan worden met behulp

van OpenEPC. Hiervoor moet er eerst een LTE testnetwerk, waarop OpenEPC geınstalleerd

wordt, gebouwd worden. Uiteindelijk is zowel voice over IP via Over The Top providers als

voice over LTE met het IP Multimedia Subsystem (IMS) mogelijk gemaakt.

Er wordt ook onderzocht hoe policies en QoS toegepast worden in OpenEPC. Daarnaast

worden ook handovers getest tussen WiFi en LTE met behulp van zowel geemuleerde als

fysieke LTE devices.

v

Inhoudsopgave

Woord vooraf iv

Abstract v

Lijst van figuren x

Lijst van afkortingen xii

1 Inleiding 1

1.1 Structuur van mobiele netwerken . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Twee soorten services: data en spraak . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Van een circuit- naar pakketgeschakeld kernnetwerk . . . . . . . . . . . . . . 3

1.4 Doelstelling van de masterproef . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.5 Structuur van de masterproef . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 EPS architectuur 6

2.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 De belangrijkste elementen in een LTE netwerk . . . . . . . . . . . . . . . . . 7

2.2.1 User Equipment (UE) . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.2 eNodeB (eNB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.3 Serving GW (S-GW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.4 PDN GW (P-GW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.5 Mobility Management Entity (MME) . . . . . . . . . . . . . . . . . . 9

2.2.6 Home Subscriber Server (HSS) . . . . . . . . . . . . . . . . . . . . . . 10

2.2.7 Policy and Charging Rules Function (PCRF) . . . . . . . . . . . . . . 10

2.3 Samenwerking tussen LTE en WCDMA/HSPA . . . . . . . . . . . . . . . . . 10

2.4 Samenwerking tussen LTE en WiFi . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Spraakgesprekken in 4G netwerken 12

3.1 Over The Top (OTT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Circuit Switched Fall Back (CSFB) . . . . . . . . . . . . . . . . . . . . . . . . 13

vi

Inhoudsopgave vii

3.3 Voice-over-LTE (VoLTE) en IP Multimedia Subsystem (IMS) . . . . . . . . . 13

3.3.1 Single-Radio Voice Call Continuity (SRVCC) . . . . . . . . . . . . . . 14

3.4 Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Introductie tot OpenEPC 17

4.1 Wat is OpenEPC? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1.1 OpenEPC architectuur en mogelijkheden . . . . . . . . . . . . . . . . 19

4.1.2 De verschillende componenten van OpenEPC . . . . . . . . . . . . . . 20

4.2 Ontplooien van de OpenEPC software . . . . . . . . . . . . . . . . . . . . . . 20

4.2.1 Het gebruik van OpenEPC met Virtuele Machines in VMWare . . . . 23

4.2.2 Installatie van OpenEPC op fysieke systemen . . . . . . . . . . . . . . 23

5 Ontplooien en installeren van OpenEPC op de Virtual Wall 25

5.1 Virtual Wall opstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.1.1 Standaard opstelling op de Virtual Wall . . . . . . . . . . . . . . . . . 26

5.1.2 Toevoegen van een UE . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1.3 Het koppelen van externe UE’s aan de Virtual Wall . . . . . . . . . . 29

5.1.4 Handover tussen E-UTRAN en UTRAN . . . . . . . . . . . . . . . . . 30

5.1.5 Handover tussen E-UTRAN en WiFi . . . . . . . . . . . . . . . . . . . 31

5.1.6 Fysiek WiFi access point en LTE femtocell . . . . . . . . . . . . . . . 31

5.2 Configuratie van de systemen . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.2.1 TCP Segmentation Offload (TSO) . . . . . . . . . . . . . . . . . . . . 33

5.2.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.2.3 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.2.4 NAT op EPC-Enablers . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.2.5 IP-forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.2.6 Routes naar IBCN/test netwerk . . . . . . . . . . . . . . . . . . . . . 34

5.2.7 rc.local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6 IP Connectiviteit in OpenEPC 36

6.1 Verbinding maken met een access netwerk . . . . . . . . . . . . . . . . . . . . 37

6.1.1 Mobility Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.1.2 Verbinden zonder Mobility Manager . . . . . . . . . . . . . . . . . . . 41

6.1.3 Web GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.2 Routering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.2.1 GTP tunnel tussen eNB en S-GW en tussen S-GW en P-GW . . . . . 48

6.2.2 GRE tunnel tussen ePDG en P-GW . . . . . . . . . . . . . . . . . . . 48

6.3 Het SGi reference point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Inhoudsopgave viii

7 Realiseren van spraakgesprekken met OpenEPC 50

7.1 Beschikbare applicaties in OpenEPC . . . . . . . . . . . . . . . . . . . . . . . 50

7.1.1 HTTP proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.1.2 Open IMS Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.2 OTT met behulp van Skype . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.3 IMS met behulp van Monster IMS client . . . . . . . . . . . . . . . . . . . . . 55

7.3.1 Gebruikersprofielen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

8 Policies en QoS in OpenEPC 57

8.1 Policy and Charging Control (PCC) . . . . . . . . . . . . . . . . . . . . . . . 58

8.2 Instellen van policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

8.2.1 Default bearer policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

8.2.2 Youtube policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

8.3 Problemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

9 Handover van dataverbindingen met OpenEPC 63

9.1 Handover van E-UTRAN naar UTRAN en vice versa . . . . . . . . . . . . . . 64

9.2 Handover van E-UTRAN naar WiFi en vice versa . . . . . . . . . . . . . . . . 64

9.2.1 Handover met behulp van LTE femtocell en fysiek WiFi AP . . . . . . 64

9.3 Handovers zonder onderbreking van de sessie . . . . . . . . . . . . . . . . . . 64

10 Besluit 66

A Gedetailleerde OpenEPC opstelling 67

B Algemene projectstructuur van OpenEPC 68

C Het gebruik van OpenEPC met Virtuele Machines in VMWare 69

D Installatie van OpenEPC 71

E Bedienen van de componenten in OpenEPC 72

E.1 Configuratie van componenten . . . . . . . . . . . . . . . . . . . . . . . . . . 72

E.2 Provisioning van componenten . . . . . . . . . . . . . . . . . . . . . . . . . . 73

E.2.1 Wissen van de data in de databank . . . . . . . . . . . . . . . . . . . . 74

E.3 Testbed SSH sleutelverdeling . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

F Maken van een extra UE 75

G Configuratiescript van standaard OpenEPC 76

H Configuratiescript van OpenEPC met virtuele Alice en Bob 79

Inhoudsopgave ix

I Configuratiescript van minimale OpenEPC met externe Alice en Bob 83

J Configuratiescript voor handover tussen eNodeB en NodeB 86

K Configuratiescript voor handover tussen eNodeB en ePDG 89

L OpenEPC interfaces 92

L.1 UEAlice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

L.2 ANGw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

L.3 eNodeB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

L.4 EPCEnablers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

L.5 ePDG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

L.6 PDNGW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

L.7 nodeB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

L.8 SGW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

M OpenEPC DNS 96

N OpenEPC routes naar testnetwerk 97

O Routeertabellen in OpenEPC 98

O.1 UE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

O.2 eNodeB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

O.3 S-GW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

O.4 P-GW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

P Oplossing voor de HTTP proxy van OpenEPC 101

Q Configuratie van LTE femtocell 102

R Aanmaken van een gebruiker in OpenEPC 103

Bibliografie 104

Lijst van figuren

1.1 Verschillende onderdelen van een mobiel netwerk [1] . . . . . . . . . . . . . . 2

1.2 Circuitgeschakeld en pakketgeschakeld domein [2] . . . . . . . . . . . . . . . . 3

2.1 De verschillende domeinen van de EPS architectuur [3] . . . . . . . . . . . . . 6

2.2 De belangrijkste elementen in een LTE netwerk [4] . . . . . . . . . . . . . . . 8

3.1 Het verschil tussen OTT providers en het IMS [5] . . . . . . . . . . . . . . . . 13

3.2 IMS [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3 VoLTE SRVCC [7] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4 Samenvatting van 3GPP oplossingen [3] . . . . . . . . . . . . . . . . . . . . . 16

4.1 OpenEPC situering [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2 OpenEPC roadmap [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3 High-level OpenEPC architectuur . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.4 OpenEPC componenten en interfaces [8] . . . . . . . . . . . . . . . . . . . . . 20

4.5 ip.access LTE 245F [30] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.6 OpenEPC architectuur [9] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.1 Virtual Wall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2 Standaard OpenEPC op de Virtual Wall . . . . . . . . . . . . . . . . . . . . . 27

5.3 OpenEPC met Alice en Bob . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.4 Minimalistische OpenEPC met externe Alice en Bob . . . . . . . . . . . . . . 29

5.5 Opstelling voor handover tussen E-UTRAN en UTRAN . . . . . . . . . . . . 30

5.6 Opstelling voor handover tussen E-UTRAN en WiFi . . . . . . . . . . . . . . 31

5.7 Opstelling voor fysiek WiFi AP en LTE femtocell . . . . . . . . . . . . . . . . 32

6.1 Betrokken componenten [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.2 Architectuur voor connectiviteit in het kernnetwerk [10] . . . . . . . . . . . . 37

6.3 Verbinding maken en verbreken met behulp van EHCP [10] . . . . . . . . . . 38

6.4 Mobility Manager GUI verbonden met WiMAX [11] . . . . . . . . . . . . . . 39

6.5 Android Mobility Manager configuratie [11] . . . . . . . . . . . . . . . . . . . 40

x

Lijst van figuren xi

6.6 iPhone verbonden met het OpenEPC netwerk via ePDG . . . . . . . . . . . . 42

6.7 GTP interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.8 PMIP interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.9 LMA Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.10 LMA PDN configuratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.11 DNS configuratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.12 PDN IPv4 range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.13 PDN IPv4 allocaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.14 LMA binding lijst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.15 MAG binding lijst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.16 GTP tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.17 GRE tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7.1 Application Function [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.2 HTTP proxy [12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.3 HTTP proxy geconfigureerd op de UE . . . . . . . . . . . . . . . . . . . . . . 53

7.4 Open IMS Core [13] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.5 Open IMS Core verbonden met OpenEPC [12] . . . . . . . . . . . . . . . . . 55

7.6 Alice Monster profielen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

8.1 De componenten en interfaces betrokken bij Policy and Charging Control

(PCC) [14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

8.2 PCC architectuur [15, 16] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

8.3 PCC Web GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

8.4 Policy regels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

8.5 Default bearer acties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

8.6 Youtube condities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

8.7 Youtube acties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

A.1 OpenEPC opstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

C.1 Bij opstarten VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

E.1 OpenEPC Web GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

R.1 Web GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Lijst van afkortingen

2G 2nd Generation

3G 3rd Generation

3GPP Third Generation Partnership Project

AAA Authentication, Authorization and Accoun-

ting

AF Application Function

AN Access Network

AN GW Access Network Gateway

ANDSF Access Network Discovery and Selection

Function

APN Access Point Name

AS Application Server

BA Binding Acknowledgement

BBERF Bearer Binding and Event Reporting Func-

tion

BSC Base Station Controller

BTS Base Transceiver Station

BU Binding Update

CN Core Network

CS Circuit Switched

CSCF Call Server Control Function

CSFB Circuit Switched Fall Back

DHCP Dynamic Host Configuration Protocol

DL Downlink

DNS Domain Name System

DSL Digital Subscriber Line

xii

Lijst van afkortingen xiii

E-UTRAN Evolved Universal Terrestrial Radio Access

Network

EDGE Enhanced Data rates for GSM Evolution

EHCP Enhanced DHCP

eNB eNodeB

EPC Evolved Packet Core

ePDG Evolved Packet Data Gateway

EPS Evolved Packet System

GERAN GSM EDGE Radio Access Network

GGSN Gateway GPRS Support Node

GPRS General Packet Radio Services

GRE Internet Protocol

GSM Global System for Mobile Communications

GTP GPRS Tunneling Protocol

GTP-U GPRS Tunneling Protocol for User Plane

GW Gateway

HSPA High-Speed Packet Access

HSS Home Subscriber Server

I-CSCF Interrogating-CSCF

IMS IP Multimedia Subsystem

IMSI International Mobile Subscriber Identity

IP Internet Protocol

IPSec IP Security

LMA Local Mobility Anchor

LTE Long Term Evolution

MAC Medium Access Control

MAG Mobile Access Gateway

MDF Media Delivery Function

MIP Mobile IP

MME Mobility Management Entity

MMTel MultiMedia Telephone

MNI Mobile Node Identifier

MSC Mobile Switching Centre

Lijst van afkortingen xiv

MTU Maximum Transmission Unit

NAS Non-Access Stratum

NAT Network Address Translation

NIC Network Interface Card

OFCS Offline Charging System

OTT Over The Top

P-CSCF Proxy-CSCF

P-GW PDN GW

PBA Proxy Binding Acknowledgement

PBU Proxy Binding Update

PCC Policy and Charging Control

PCEF Policy and Charging Enforcement Function

PCRF Policy and Charging Rules Function

PDN Packet Data Network

PDN GW Packet Data Network Gateway

PMIP Proxy Mobile IP

PS Packet Switched

QoS Quality of Service

RAN Radio Access Network

RNC Radio Network Controller

S-CSCF Serving-CSCF

S-GW Serving GW

SAE System Architecture Evolution

Serving GW Serving Gateway

SGSN Serving GPRS Support Node

SIM GSM Subscriber Identitiy Module

SIP Session Initiation Protocol

SRVCC Single-Radio Voice Call Continuity

TSO TCP Segmentation Offload

UE User Equipment

UL Uplink

Lijst van afkortingen xv

UMTS Universal Mobile Telecommunications System

UTRAN UMTS Terrestrial Radio Access Network

VoIP Voice Over IP

VoLTE Voice-over-LTE

WCDMA Wideband Code Division Multiple Access

WiMAX Worldwide Interoperability for Microwave Ac-

cess

WLAN Wireless Local Area Network

Hoofdstuk 1

Inleiding

Dit hoofdstuk schetst de context van deze masterproef. Het bevat een inleiding in de wereld

van mobiele netwerken. De structuur en evolutie naar LTE (Long Term Evolution) en de

nieuwe uitdagingen hierbij komen aan bod. Op het einde van het hoofdstuk worden de

doelstelling en verschillende onderdelen van de masterproef vermeld.

1.1 Structuur van mobiele netwerken

Een mobiel netwerk is een draadloos netwerk verdeeld over landgebieden die men cellen noemt.

Binnen elke cel is ten minste een zendmast. Deze zendmasten zijn onderling verbonden via

vaste netwerken. Het overgrote deel van de weg die de data aflegt, gaat dan ook over deze

vaste netwerken. Enkel het laatste stuk van de weg, tussen de zendmast en het mobiel toestel

is draadloos. Dit is vergelijkbaar met WiFi, waarbij de data ook pas het laatste stukje vanaf

het access point naar de eindgebruiker door de lucht aflegt. Mobiele netwerken verschillen

in een belangrijk opzicht wel van andere netwerken. Zendmasten moeten het signaal aan

elkaar kunnen overdragen. Als dit niet het geval zou zijn, dan zou iemand die zich verplaatst

tijdens het bellen, bijna constant opnieuw moeten bellen omdat hij het dekkingsgebied van

een bepaalde mast uitgaat en het gebied van een andere mast ingaat.

1

Hoofdstuk 1. Inleiding 2

Figuur 1.1: Verschillende onderdelen van een mobiel netwerk [1]

De talloze zendmasten worden het Radio Access Network (RAN) genoemd. Naast deze zend-

masten dient er ook een kernnetwerk te zijn. Dit kernnetwerk zorgt er voor dat alle gesprekken

en dataverbindingen corrrect afgehandeld worden. Het toestel dat verbinding maakt met het

access netwerk, wordt de User Equipment (UE) genoemd. Via het kernnetwerk gaat men

naar een extern netwerk (vb. het internet). De genoemde onderdelen kan je terugvinden op

figuur 1.1.

1.2 Twee soorten services: data en spraak

Er komen twee soorten verkeer voor op een mobiel netwerk: dataverkeer (mobiel internet)

en spraakverkeer (mobiele telefonie). De manier waarop er met dit verkeer moet omgegaan

worden is verschillend. Dataverkeer hoeft namelijk niet zo’n strenge kwaliteitsgaranties te

hebben als spraakverkeer. Bij spraak moet er zo weinig mogelijk vertraging op het verkeer

zitten, moet het verkeer in de juiste volgorde aankomen en mag er liefst zo weinig verloren

gaan tijdens het transporteren. Vooral de vertraging kan een hinderlijke factor zijn als het

om een vloeiend verlopend gesprek gaat. Bij 2G/3G wordt circuitschakeling gebruikt voor

spraakverkeer en pakketschakeling voor dataverkeer. Doordat men circuitschakeling gebruikt,

wordt er voor gezorgd dat het spraakverkeer aan de nodige kwaliteitsgaranties voldoet. Het

circuit wordt opgezet tussen twee eindpunten en enkel deze twee eindpunten sturen data

doorheen dit circuit. Hierdoor is de vertraging minimaal en ook de bandbreedte gegarandeerd.

Zoals reeds vermeld, is 4G volledig IP-gebaseerd. Bij de meeste operatoren ondersteunt

het 4G netwerk daarom enkel nog maar dataverkeer en geen spraakverkeer. Er zijn heel

wat problemen met Voice Over IP (VoIP). IP biedt namelijk geen garantie dat verzonden


pakketten ook zullen aankomen. Het kernnetwerk bij 4G moet daarom zelf zorgen voor

de nodige Quality of Service (QoS). Meer informatie over de mogelijkheden om spraak te

ondersteunen in een 4G netwerk vind je in hoofdstuk 3.

1.3 Van een circuit- naar pakketgeschakeld kernnetwerk

Figuur 1.2 toont dat er later pas dataverkeer getransporteert wordt en dat er een evolutie ont-

staat van circuit- naar pakketschakeling. GSM (Global System for Mobile Communications)

is gebouwd op een circuitgeschakelde infrastructuur die telefonie toelaat op cellulaire netwer-

ken. Dit betekent dat er telkens een circuit wordt opgezet tussen de twee eindpunten. Bij een

circuit krijgt een bepaalde verbinding een vast communicatiekanaal toegewezen gedurende

het gesprek. Naast mobiele telefonie kwam later ook mobiel internet. Vanaf GPRS (General

Packet Radio Services) bestond het kernnetwerk uit twee delen, een pakketgeschakeld en een

circuitgeschakeld deel. Bij pakketschakeling wordt data getransporteerd in pakketten. Dit

biedt meer flexibiliteit en efficientie omdat er geen circuit moet opgezet worden. De eerste

mobiele internetdiensten waren gelimiteerd door de bandbreedte van het radio access netwerk.

Dit is dan verbeterd door de evolutie van RAN’s die hogere bandbreedte kunnen leveren zoals

HSPA (High-Speed Packet Access) en sinds kort door LTE [3].

Bij 2G (GSM/GPRS) en 3G (UMTS/HSPA) bestond het kernnetwerk uit een circuit- en

pakketgeschakeld domein. Bij het ontwerp van 4G, de opvolger van 3G werd beslist om

het IP protocol te gebruiken voor zowel spraak als data. Het kernnetwerk, de EPC (Evolved

Packet Core), biedt dan ook voor het eerst in de evolutie van cellulaire netwerken volledige IP-

functionaliteit voor de communicatie tussen de verschillende entiteiten, waardoor het volledige

pad tussen mobiele toestellen pakketgeschakeld is. Het traditioneel gebruik van circuits om

spraak te transporteren over het netwerk zal moeten vervangen worden door op IP-gebaseerde

oplossingen.

Figuur 1.2: Circuitgeschakeld en pakketgeschakeld domein [2]


Het resultaat van de 3GPP SAE (System Architecture Evolution) technische studie [17] is een

set standaarden die de evolutie van het pakket kernnetwerk voor GSM/GPRS en UMTS/H-

SPA naar een volledige IP-architectuur specifieert. De volledige IP-architectuur laat een

gemeenschappelijk kernnetwerk toe voor radiotechnologieen ontworpen binnen zowel 3GPP

als daarbuiten door andere standaardisatie forums. Dit gemeenschappelijk kernnetwerk heet

de EPC en de volledige architectuur wordt het EPS (Evolved Packet System) genoemd, die

ondersteuning biedt voor 3GPP radioaccesstechnologieen (LTE, GSM en WCDMA/HSPA)

alsook niet-3GPP radioaccesstechnologieen. In hoofdstuk 2 wordt dieper ingegaan op de

structuur en de verschillende componenten van het EPS.

1.4 Doelstelling van de masterproef

Om een dergelijk kernnetwerk (de EPC) te emuleren kan er bij IBCN gebruikgemaakt worden

van het ‘OpenEPC’-software pakket [8]. Met behulp van OpenEPC is het mogelijk om zelf

een volledig geemuleerd 4G-netwerk op te zetten en zeer veel parameters aan te passen. De

doelstelling van deze masterproef is om de aanwezige basisopstelling verder uit te testen en

na te gaan welke verschillende mogelijkheden van VoIP ondersteund worden.

Deze software is recent aangekocht bij IBCN en is dus nog onbekend terrein. De software is ook

slechts een prototype implementatie van de 3GPP EPC en er kunnen nog fouten optreden in de

software [15]. Het is daarom onduidelijk of bepaalde zaken geımplementeerd zijn in OpenEPC

en of dit al of niet volgens de standaarden is. Het testen van sommige functionaliteiten kan

belemmerd worden doordat ze niet volledig worden ondersteund in OpenEPC. Daarnaast is

ook de complexiteit van de software nog onbekend.

Een grote doelstelling van de masterproef is dan ook het ontdekken en verkennen van de

OpenEPC software en het EPS. In eerste fase moet het LTE-testnetwerk volledig gebouwd

worden. Hiervoor zijn een aantal verschillende systemen, interfaces en componenten (o.a.

Linux PC’s) nodig. Dit is een complexe opstelling, waarna hierop dan OpenEPC geınstalleerd

en geconfigureerd wordt.

Wanneer het LTE-testnetwerk operationeel is, moet nagegaan worden wat de verschillende

mogelijkheden ervan zijn tot geavanceerd gebruik. In eerste instantie zal er daarom onderzocht

worden welke functionaliteiten het LTE-testnetwerk momenteel aanbiedt voor spraakgesprek-

ken. Van hetgeen ondersteund wordt zal daarna ook een demo opgezet worden.

1.5 Structuur van de masterproef

In hoofdstuk 2 wordt de architectuur van een 4G netwerk besproken. De verschillende op-

lossingen voor spraakgesprekken worden toegelicht in hoofdstuk 3. Hoofdstuk 4 geeft een


introductie tot het ’OpenEPC’-software pakket. Hoe de software op de Virtual Wall wordt

ontplooid en geınstalleerd wordt in hoofdstuk 5 behandeld. Hoe een internetconnectie gerea-

liseerd wordt tussen een gebruiker en het EPC komt voor in hoofdstuk 6. In hoofdstukken 7,

8, 9 wordt besproken hoe geavanceerde use cases werden getest: spraakgesprekken, policies

en QoS en handovers van dataverbindingen.

Hoofdstuk 2

EPS architectuur

Dit hoofdstuk geeft een schets weer van de EPS architectuur zoals die gedefinieerd is in de

3GPP SAE studie. Eerst wordt de algemene architectuur van het volledige EPS geıntroduceerd,

waarna dieper wordt ingegaan op de componenten die meest relevant zijn bij 4G netwerken.

2.1 Inleiding

Het EPS bestaat uit de UE, RAN’s, bijvoorbeeld E-UTRAN (LTE/4G access netwerk),

UTRAN (WCDMA/3G access netwerk), GERAN (GSM/2G access netwerk) en andere non-

3GPP technologieen (WiMAX, WiFi) en de EPC. Figuur 2.1 toont de verschillende domeinen

die deel uitmaken van het EPS. Het kernnetwerk is verdeeld in meerdere domeinen: een cir-

cuitgeschakeld, pakketgeschakeld en IP Multimedia Subsystem (IMS) domein.

Figuur 2.1: De verschillende domeinen van de EPS architectuur [3]

6

Hoofdstuk 2. EPS architectuur 7

Het circuitgeschakeld domein bestaat uit de onderdelen die nodig zijn voor circuitgeschakelde

diensten (vb. spraak) over GSM en WCDMA.

Hiernaast zorgt het pakketgeschakeld domein voor ondersteuning van pakketgeschakelde dien-

sten (vb. data) over GSM, WCDMA, HSPA, LTE en niet-3GPP access netwerken. Het

pakketgeschakelde domein zorgt ook voor het beheer en toepassen van policies en QoS.

Het IMS domein bestaat uit componenten en functies die ondersteuning bieden voor mul-

timedia sessies gebaseerd op het SIP (Session Initiation Protocol). Het gebruikt de IP-

connectiviteit aangeboden door het pakketgeschakelde domein. Het IMS komt in hoofdstuk

3 uitgebreider aan bod.

In het centrum bevindt zich het domein dat instaat voor het beheer van de gegevens van

gebruikers.

2.2 De belangrijkste elementen in een LTE netwerk

In deze sectie worden de verschillende logische entiteiten in het kernnetwerk toegelicht. Dit

betekent niet noodzakelijk dat bij implementatie op hardware er een een-op-een relatie moet

zijn tussen een systeem en een entiteit van het kernnetwerk. Zo kunnen twee logische entiteiten

gecombineerd worden op hetzelfde systeem om het aantal fysieke systemen te beperken. Ook

de interfaces zijn logische interfaces. Bijvoorbeeld een interface, die twee logische entiteiten

verbindt, kan fysiek gerouteerd worden via het kernnetwerk.

De belangrijkste componenten in EPC (zie figuur 2.2) zijn de Serving Gateway (Serving

GW), Packet Data Network Gateway (PDN GW), de Mobility Management Entity (MME),

Home Subscriber Server (HSS) en de Policy and Charging Rules Function (PCRF). De EPC

is verbonden met externe netwerken, welke ook het IMS kan zijn. Hoewel de componenten

van GERAN (2G) en UTRAN (3G) niet tot de LTE architectuur behoren, zijn deze ook op

de figuur geplaatst.


Figuur 2.2: De belangrijkste elementen in een LTE netwerk [4]

De verbindingen tussen de verschillende entiteiten worden reference points of interfaces ge-

noemd. Reference points in 3GPP hebben meestal een prefix letter. Bij GPRS starten de

meeste namen van reference points met de letter “G”, terwijl bij EPS de meeste namen

beginnen met de letter “S”.

Merk ook op dat de verschillende domeinen die vermeld zijn in de inleiding voorkomen op

figuur 2.2. Zo zijn 2G, 3G en LTE aangeduid als GERAN, UTRAN en Evolved UTRAN

(E-UTRAN). Het circuit- en pakketgeschakelde domein is ook aangeduid (3GPP CS Core Net-

work en 3GPP PS Core Network). Het IMS domein komt voor als een mogelijk Packet Data

Network (PDN). De HSS component is verantwoordelijk voor het beheer van gebruikersdata.


2.2.1 User Equipment (UE)

User Equipment is het toestel dat gebruikt wordt door de eindgebruiker om te communice-

ren. Dit kan een smartphone of laptop met mobiele breedband adapter zijn. De UE maakt

verbinding met de eNodeB.

2.2.2 eNodeB (eNB)

In het LTE radio access netwerk moet er ten minste een eNodeB aanwezig zijn. De eNodeB

is het LTE base station en zorgt voor de draadloze connectie naar de UE.

2.2.3 Serving GW (S-GW)

De Serving GW is verbonden met de eNodeB en zorgt voor het transport van het dataverkeer

van de gebruiker (ook wel data plane of user plane genoemd). De Serving GW is het punt

waar het access netwerk en kernnetwerk verbonden worden. Zoals de naam doet vermoeden

bedient de gateway de UE door inkomende en uitgaande pakketten te routeren. De gateway

buffert ook downlink IP-pakketten, bestemd voor de UE die op dat moment idle zou zijn (vb.

de UE heeft tijdelijk geen connectie ten gevolge van een handover). De Serving GW zorgt

voor intra-LTE mobiliteit (tijdens een handover tussen eNodeB’s) en optioneel ook mobiliteit

tussen GSM/GPRS, WCDMA/HSPA en LTE. De gateway is logisch verbonden met de andere

gateway, de PDN GW.

2.2.4 PDN GW (P-GW)

De PDN GW legt de connectie tussen de EPC en externe IP netwerken. Deze externe net-

werken worden PDN’s genoemd. De PDN GW zorgt voor allocatie van IP adressen, charging,

packet filtering en policing van IP flows. De PDN GW speelt ook een belangrijke rol in het

ondersteunen van QoS. De PDN GW is verbonden met de Serving GW en samen zorgen ze

voor het transport van data van en naar de mobiele toestellen.

2.2.5 Mobility Management Entity (MME)

Alle eNodeB’s zijn verbonden met ten minste een MME. De MME is verantwoordelijk voor

het beheer van de verbindingen en sessies in het kernnetwerk (ook wel het control plane

genoemd). Locatiegegevens van elke gebruiker worden door de MME bijgehouden en hierdoor

kan de beste Serving GW gekozen worden per gebruiker. De MME speelt ook een belangrijke

rol bij handovers tussen LTE en 2G/3G netwerken.


2.2.6 Home Subscriber Server (HSS)

De MME heeft gegevens nodig over de gebruikers die een verbinding proberen te maken met

een LTE RAN. Hiervoor is de MME verbonden met de HSS. De HSS is een databank die de

gebruikersgegevens beheert.

2.2.7 Policy and Charging Rules Function (PCRF)

De PCRF (Policy and Charging Rules Function) maakt deel uit van het concept PCC (Policy

and Charging Control). Het PCC concept is ontworpen om te kunnen beslissen hoe services

behandeld worden in de PDN GW, afhankelijk per gebruiker en per service. De PCRF is

verbonden met de PDN GW en externe applicaties. Externe applicaties kunnen informatie

sturen naar de PCRF met bijvoorbeeld de minimale QoS vereisten. Het is dan de taak van

de PCRF om ervoor te zorgen dat aan de minimale vereisten voldaan wordt. Naast toepassen

van policies op de IP flows, kan ook aan charging worden gedaan. Op deze manier kan de

kost van diensten verrekend worden.

2.3 Samenwerking tussen LTE en WCDMA/HSPA

Een nieuw radio netwerk wordt gradueel in dienst genomen, nog voor er volledige netwerk-

dekking is. Volledige netwerkdekking is trouwens ook maar zelden het geval. Daarom is het

noodzakelijk dat er nog gebruikgemaakt kan worden van oudere, al bestaande radio netwer-

ken. De frequentie die gebruikt wordt voor LTE is 2GHz of hoger. Een hogere frequentie

leidt tot hogere bandbreedte, maar het dekkingsgebied neemt snel af.

Bij LTE is samenwerking met bestaande netwerken die IP ondersteunen zoals WCDMA/HSPA

dus van cruciaal belang. De EPS architectuur heeft hiervoor twee verschillende oplossingen.

Meer informatie is te vinden in [3].

2.4 Samenwerking tussen LTE en WiFi

De EPS architectuur is zo ontworpen dat samenwerking met elke access technologie mogelijk

is. De toegang tot een PDN is onafhankelijk van het type access technologie dat gebruikt

wordt. Het toekennen van een IP aan de UE, subscription management, beveiliging, charging

en policies zijn dus allemaal onafhankelijk van de gebruikte access technologie. Naast deze

algemene access-onafhankelijke features, zorgt de architectuur ook voor samenwerking tussen

de verschillende access technologieen.


Een use case kan als volgt zijn: je hebt een toestel dat LTE en WiFi ondersteunt. Je bent

verbonden met het LTE netwerk en begeeft je naar binnen in je huis. Daar staat je WiFi

access point. Het toestel kan in deze situatie overschakelen van LTE naar Carrier WiFi.

De EPS architectuur bevat features die ervoor zorgen dat de sessie tijdens deze handover

behouden blijft. Om dit te realiseren wordt Mobile IP gebruikt.

Hoofdstuk 3

Spraakgesprekken in 4G netwerken

Spraakgesprekken zijn een van de belangrijkste diensten die een telecomoperator aanbiedt.

Echter, de LTE technologie is geoptimaliseerd voor IP-gebaseerde diensten met een pak-

ketgeschakeld kernnetwerk. Dit zorgt voor problemen om spraakgesprekken te kunnen on-

dersteunen in een 4G netwerk. Er zijn verschillende oplossingen voorgesteld. In volgende

hoofdstukken worden de belangrijkste uitgelegd.

Omdat bij 4G alles IP-gebaseerd is, kunnen OTT (Over The Top) providers zoals Skype hun

diensten aanbieden. De telecomoperator zorgt dan enkel voor de infrastructuur en trans-

port van IP-verkeer. De OTT provider biedt dan zijn diensten aan, gebruikmakend van de

infrastructuur van de telecomoperator. De operator wil natuurlijk liefst zelf spraakdiensten

aanbieden om zo winst hierop te kunnen maken.

Er zijn twee fundamenteel verschillende manieren van hoe een operator spraakgesprekken kan

aanbieden aan zijn LTE gebruikers: door Circuit-Switched Fallback (CSFB) toe te passen of

gebruik te maken van MMTel dat gebaseerd is op het IMS. Deze laatste oplossing wordt ook

wel Voice-over-LTE (VoLTE) genoemd. Het is belangrijk om te weten dat CSFB en VoLTE

elkaar niet uitsluiten, maar samen, naast elkaar, kunnen gebruikt worden. CSFB kan gezien

worden als tijdelijke tussenoplossing tot VoLTE volledig geımplementeerd is.

3.1 Over The Top (OTT)

Bij OTT wordt gebruikgemaakt van dezelfde verbinding die gebruikt wordt voor dataverkeer.

Eigenlijk is dit niets anders dan VoIP bij traditioneel internet. Alle problemen van VoIP zijn

dan ook aanwezig. OTT diensten zijn sterk afhankelijk van de betrouwbaarheid en kwali-

teit van het mobiel netwerk. Als een gebruiker zich verplaatst, kan hij slechtere kwaliteit,

onderbrekingen en wegvallende gesprekken ervaren. IP biedt namelijk geen garanties over

12

Hoofdstuk 3. Spraakgesprekken in 4G netwerken 13

de betrouwbaarheid van de verbinding. Figuur 3.1 toont de vergelijking tussen spraakdien-

sten die door OTT providers worden aangeboden en deze die door de operator zelf worden

aangeboden met behulp van het IMS (sectie 3.3).

Figuur 3.1: Het verschil tussen OTT providers en het IMS [5]

3.2 Circuit Switched Fall Back (CSFB)

Bij CSFB wordt voor de duur van een gesprek de UE overgebracht van het 4G netwerk naar

het 2G/3G netwerk, waar het gesprek circuitgeschakeld wordt. In feite wordt het LTE ac-

cess netwerk helemaal niet gebruikt. Hiervoor moet tijdens het verbinden van de UE met de

eNodeB, de UE zowel geregistreerd worden in het EPS als in het circuitgeschakelde domein

van het 2G/3G netwerk. Dit wordt bekomen door de interactie tussen de MME en de Mo-

bile Switching Centre (MSC) Server. Laatstgenoemde bevindt zich in het circuitgeschakelde

domein.

3.3 Voice-over-LTE (VoLTE) en IP Multimedia Subsystem

(IMS)

Het IMS is een architectuur voor het leveren van multimediadiensten over IP-netwerken [18].

Bestaande netwerken (zowel circuitgeschakeld als pakketgeschakeld) worden ondersteund. Het

IMS is niet bedoeld om applicaties te standaardiseren, maar om de toegang tot multimedia-

diensten, zoals video en spraak, gemakkelijker te maken. Dit wordt gerealiseerd door een


horizontale controlelaag (Call Server Control Function (CSCF) op figuur 3.2) die het access

netwerk isoleert van de applicaties.

Figuur 3.2: IMS [6]

MMTel is dan een op IMS-gebaseerde service voor spraakgesprekken die gestandaardiseerd

is door 3GPP [19] (dit is een Application Server zoals te zien op figuur 3.2). MMTel is een

oplossing voor spraakgesprekken in gebieden met LTE dekking. MMTel biedt meer mogelijk-

heden dan circuitgeschakelde spraakgesprekken op 2G/3G netwerken. Zo is het mogelijk om

ook video en andere media toe te voegen aan het gesprek.

3.3.1 Single-Radio Voice Call Continuity (SRVCC)

SRVCC is ontworpen om een handover te doen van een spraakgesprek tussen een systeem

dat IMS/MMTel ondersteunt en een systeem dat dit niet ondersteunt. Dit kan zijn omdat er

geen LTE dekking is.

SRVCC definieert de procedure die nodig is om een IP-gebaseerde spraakgesprek van het ene

systeem over te brengen naar een ander systeem dat enkel circuitgeschakelde spraakgesprekken

ondersteunt.


Figuur 3.3: VoLTE SRVCC [7]

Om SRVCC te kunnen gebruiken is het IMS nodig. IMS moet gedurende het volledige ge-

sprek, het gesprek kunnen aanleveren aan het pakketgeschakelde domein en circuitgeschakelde

domein. SRVCC bevat daarom ook interactie tussen de MME van de EPC en de MSC Server

van het circuitgeschakelde 2G/3G netwerk [20] (figuur 3.3).

3.4 Samenvatting

Dit hoofdstuk wordt nog afgesloten met een samenvattende figuur waarop de belangrijkste

oplossingen van de operator te zien zijn (CSFB, VoLTE en SRVCC).


Figuur 3.4: Samenvatting van 3GPP oplossingen [3]

Hoofdstuk 4

Introductie tot OpenEPC

Dit hoofdstuk is een eerste kennismaking met de OpenEPC software. Wat OpenEPC is, welke

systemen, componenten en modules er allemaal deel van uitmaken en welke mogelijkheden er

allemaal zijn, komen aan bod in de eerste sectie. De tweede sectie bespreekt hoe de software

geınstalleerd kan worden.

4.1 Wat is OpenEPC?

OpenEPC is een prototype software implementatie van de 3GPP Release 11 EPC, ontwikkeld

door Fraunhofer FOKUS, dat onderzoekers een praktische kijk kan geven op de mogelijkheden

van de Evolved Packet Core. OpenEPC kan geıntegreerd worden met verschillende access

netwerktechnologieen (LTE, 3G, 2G, WiFi,...) en verschillende applicatiedomeinen (OTT,

IMS,...) (zie figuur 4.1). Het is een basisopstelling voor onderzoek en ontwerp van Next

Generation Mobile Network (NGMN) testbeds [8].

17

Hoofdstuk 4. Introductie tot OpenEPC 18

Figuur 4.1: OpenEPC situering [8]

In deze masterproef wordt release 4 van OpenEPC gebruikt. Figuur 4.2 toont een overzicht

van de verschillende versies.

Figuur 4.2: OpenEPC roadmap [8]

De OpenEPC software omvat de basisfunctionaliteiten van het 3GPP EPC. Fraunhofer FO-

KUS garandeert niet dat de software aan alle standaarden zoals die door 3GPP zijn gede-


finieerd voldoet. Het is slechts een prototype implementatie en er kunnen nog fouten in de

software voorkomen [15].

4.1.1 OpenEPC architectuur en mogelijkheden

Op figuur 4.3 zijn de verschillende grote componenten van het OpenEPC te zien. De compo-

nenten S-GW, P-GW, PCRF, HSS en MME kwamen in hoofdstuk 2 al aan bod. De SGSN

en MSC dienen voor het 2G en 3G access netwerk, de ePDG (Evolved Packet Data Gateway)

en AN GW (Access Network Gateway) voor untrusted non-3GPP access (WiFi) en trusted

non-3GPP access (vb. WiMAX). De PDN GW bevat ook de functionaliteit die de Gateway

GPRS Support Node (GGSN) heeft waardoor deze laatstgenoemde kan weggelaten worden

[21]. In OpenEPC komt de GGSN dan ook niet voor.

Figuur 4.3: High-level OpenEPC architectuur

De componenten Authentication, Authorization and Accounting (AAA), Access Network Dis-


covery and Selection Function (ANDSF) en Offline Charging System (OFCS) zijn minder

belangrijk in de context van deze masterproef.

4.1.2 De verschillende componenten van OpenEPC

Een meer gedetailleerd overzicht van de verschillende componenten en interfaces is te zien

op figuur 4.4. Van de componenten NodeB/RNC en eNodeB, die gebruikt worden voor het

3G en 4G RAN, zijn in OpenEPC ook geemuleerde software componenten beschikbaar. Deze

componenten heten NodeB en eNodeB. Hierdoor kan OpenEPC ook gebruikt worden zonder

een fysieke 3G of 4G femtocell aan te sluiten.

Figuur 4.4: OpenEPC componenten en interfaces [8]

4.2 Ontplooien van de OpenEPC software

Door de hoge complexiteit is het OpenEPC project gereleased als een volledig functionele

opstelling die alle nodige configuraties, opstartscripts, mappen,... bevat om meteen te kunnen

gebruiken. Een typische opstelling met alle componenten wordt voorgesteld op figuur 4.6.


Zowel de virtuele als fysieke componenten zijn weergegeven voor de access netwerken (de

geemuleerde eNodeB en zijn fysieke equivalent, de ip.access LTE 245F (figuur 4.5) en de

geemuleerde NodeB en zijn fysieke equivalent, de ip.access nano3G en Iuh-NSS). Voor het 2G

access netwerk is er geen emulatie en zijn er enkel de fysieke ip.access nanoBTS en SoftBSC.

Figuur 4.5: ip.access LTE 245F [30]

Figuur 4.6: OpenEPC architectuur [9]

Elk donkergrijs blok stelt een of meerdere (vb. DNS/HSS/IMS) componenten voor van

OpenEPC. De componenten worden op verschillende systemen geınstalleerd. De meeste lo-

gische blokken vormen ook telkens een systeem, behalve de SGw en EPC Enablers. De SGw


bestaat uit de componenten MSC, S-GW, SGSN en MME. EPC Enablers bevat de componen-

ten PCRF, HSS, AAA Server en ANDSF. De CDF, CGF en BF zijn componenten die zorgen

voor charging (zie het Charging System op figuur 4.4). Verder zijn er nog enkele componenten

die geen verband houden met de 3GPP EPC zoals een DNS server en Apache server (www).

De DNS server dient voor de vertaling van de naamgeving van de verschillende componenten

naar IP adressen. De Apache server stelt een set PHP-pagina’s beschikbaar voor de Web

GUI van OpenEPC. Er zijn drie applicaties beschikbaar in de software van OpenEPC: een

Media Delivery Function (MDF), HTTP proxy en het IMS. Deze kunnen gebruikt worden

voor spraak-, video- en webverkeer. Het gebruik van de HTTP proxy en het IMS wordt nog

besproken in hoofdstuk 7.1.

Al deze systemen moeten met elkaar verbonden worden. We onderscheiden [9]:

• Net A - Operator’s IP backhaul. Dit netwerk verbindt de P-GW en de verschillende

applicaties (MDF, IMS en HTTP proxy) en voorziet in internettoegang.

• Net B - Operator’s access backhaul. Dit netwerk verbindt de access netwerk gateways

(ePDG, S-GW, ...) en de P-GW.

• Net D - GTP netwerk. Dit netwerk verbindt de MME, eNodeB en de S-GW.

• Net E - 2G RAN segment dat de nanoBTS en BSC verbindt.

• Net F - 3G RAN segment dat de nano3G en de Iuh-NSS verbindt.

• AN LTE - 4G access netwerk gesimuleerd door een eNodeB

• AN UMTS - 3G access netwerk gesimuleerd door een NodeB

• AN GSM - 2G access netwerk gesimuleerd door een BTS

• AN WiFi/WiMAX - WiFi access gesimuleerd door een ePDG/ANGw

• Management netwerk - Dit netwerk wordt gebruikt als management netwerk voor indi-

viduele toegang tot verschillende systemen.

Net E, net F en het management netwerk zijn niet op figuur 4.6 te zien.

Een meer gedetailleerde figuur van de opstelling is te vinden in bijlage A.

De software van OpenEPC wordt normaal geplaatst in een map /opt/OpenEPC. Deze locatie

kan aangepast worden in de configuratie, maar Fraunhofer FOKUS raadt aan om zoveel

mogelijk hun mappenstructuur te respecteren om ondersteuning te vergemakkelijken [9]. Als

wijzigingen moeten gebeuren aan bestanden, in bijvoorbeeld Linux, dan worden symbolische


links gelegd naar de aangepaste bestanden in de mappen van OpenEPC. De mappenstructuur

is te vinden in bijlage B.

Om de leercurve van het OpenEPC pakket te verbeteren is de volledige opstelling beschik-

baar als een geınstalleerd en geconfigureerd VMTeam. De verschillende systemen zijn dan

Virtuele Machines om bijvoorbeeld te gebruiken met VMWare. Maar OpenEPC kan ook zelf

geınstalleerd en geconfigureerd worden op fysieke machines.

4.2.1 Het gebruik van OpenEPC met Virtuele Machines in VMWare

Bij het gebruik van zo’n opstelling moet er rekening gehouden worden met het feit dat er 8

VM’s zijn. De host machine moet over voldoende krachtige hardware en voldoende RAM-

geheugen beschikken. Een minimale vereiste is minstens 4 CPU cores en 6GB RAM-geheugen.

Meer informatie over het gebruik van de VM’s is te vinden in bijlage C.

4.2.2 Installatie van OpenEPC op fysieke systemen

OpenEPC is ontworpen voor Linux systemen en gebruikt ook allerhande Linux tools. Het is

aangeraden om Ubuntu-gebaseerde systemen te gebruiken voor de installatie en configuratie

van OpenEPC. Elke andere distributie kan ook worden gebruikt, maar dan moeten de scripts

aangepast worden. Alle software die nodig is voor OpenEPC zal tijdens de configuratiescripts

geınstalleerd en geconfigureerd worden.

Enkele gebruikte tools en bibliotheken in OpenEPC zijn:

• MySQL - voorzien van data en persistentie

• Apache met PHP - Web GUI

• Java SWT - MM GUI

• libxml2 - voor XML operaties

• libgcrypt - voor encryptie en decryptie operaties

• Gstreamer - voor media afhandeling

OpenEPC moet op verschillende fysieke machines geınstalleerd worden. Dit is nodig omdat

het anders vrij moeilijk is om zaken uit te testen en te debuggen. Het is ook makkelijker om

verschillende netwerkadapters te gebruiken en het netwerk op te splitsen.

De P-GW, elke ANGw, ePDG, S-GW, client en de AF’s (IMS, MDF, HTTP proxy) moeten

verschillende systemen zijn. De minimale opstelling heeft wel minstens 8 systemen nodig. In


theorie zou je minder systemen kunnen gebruiken, maar dat zal de configuratie complexer

maken. Ook het uit elkaar houden van de verschillende procedures wordt hierdoor moeilijker.

Op 8 systemen worden de componenten als volgt verdeeld:

1. P-GW - LMA, PCEF

2. S-GW - MAG, BBERF, MME, MSC, SGSN

3. NodeB - nodeB

4. eNodeB - eNodeB

5. ePDG - MAG, BBERF, radius voor IPSec

6. ANGw - MAG, BBERF, radius voor EAP-AKA

7. EPC Enablers - PCRF, ANDSF, www (Web GUI), DNS, IMS, HTTP proxy, MDF,

andere AF, NAT

8. UE - Client Mobilty Manager

LMA en MAG worden gebruikt bij Mobile IP. PCEF en BBERF zijn nodig voor de werking

van de PCRF. IPSec wordt gebruikt om een beveiligde connectie op te zetten tussen de ePDG

en de client. Dit laatste hoort zo te zijn volgens de standaarden [22].

Wanneer de 8 systemen verbonden zijn met elkaar kunnen de verschillende systemen gecon-

figureerd worden. De installatieprocedure en hoe deze componenten gebruikt worden, is te

vinden in bijlage D.

Hoofdstuk 5

Ontplooien en installeren van

OpenEPC op de Virtual Wall

Om OpenEPC te ontplooien wordt de Virtual Wall [23] gebruikt. Een eerste opstelling die

gemaakt wordt is de opstelling die te zien is in bijlage A. Hier wordt verder naar gerefereerd

als de standaard opstelling. Deze standaardopstelling zal verder aangepast en uitgebreid

worden om de verschillende testscenario’s uit te voeren. Omdat deze opstelling maar uit een

UE (Alice) bestaat, wordt een UE (Bob) toegevoegd. Om audio en video te kunnen uittesten

zal het nodig zijn dat de UE’s extern met de Virtual Wall verbonden worden. Er zullen ook

aangepaste configuraties nodig zijn om een WiFi access point of een LTE femtocell aan te

sluiten.

5.1 Virtual Wall opstellingen

De Virtual Wall (figuur 5.1) is een emulatie omgeving die bestaat uit verschillende nodes

die verbonden zijn met een non-blocking VLAN Ethernet switch [24]. De omgeving is confi-

gureerbaar met Emulab. Emulab laat toe om een netwerk topologie te creeren tussen nodes

door middel van VLAN’s op de switch. De Virtual Wall is daarom ook zeer geschikt om er

OpenEPC op te ontplooien [24].

25

Hoofdstuk 5. Ontplooien en installeren van OpenEPC op de Virtual Wall 26

Figuur 5.1: Virtual Wall

5.1.1 Standaard opstelling op de Virtual Wall

Deze opstelling (figuur 5.2) maakt gebruik van een geemuleerde NodeB en eNodeB. In bijlage

G is het configuratiescript te vinden van deze opstelling. De UE (UEAlice) is met zijn vier

interfaces rechtstreeks aangesloten op de access netwerken (nodeB, eNodeB, ANGw en ePDG).


Figuur 5.2: Standaard OpenEPC op de Virtual Wall

5.1.2 Toevoegen van een UE

De standaardopstelling van OpenEPC beschikt maar over een UE. Een opstelling met twee

UE’s is te zien op figuur 5.3. Er wordt per accesstechnologie (3G, 4G, WiFi, WiMAX) een

apart LAN segment gebruikt. Elke UE is dan aangesloten op de vier LAN segmenten. Het is

niet mogelijk om slechts een LAN segment te gebruiken voor zowel 3G, 4G, WiFi als WiMAX.

De UE moet voor elk access netwerk een andere interface hebben en het is niet mogelijk om

een UE met vier interfaces op een LAN segment te configureren op de Virtual Wall. Ook

omdat OpenEPC gebruikmaakt van DHCP om het attachen en de-attachen van een access

netwerk te emuleren, zou dit een correcte werking verstoren.


Figuur 5.3: OpenEPC met Alice en Bob

Bij het verbinden met bijvoorbeeld de eNodeB mag enkel de eNodeB het DHCP sollicit

bericht van de UE ontvangen. Als niet enkel de eNodeB, maar ook de NodeB, ePDG en

ANGw op hetzelfde LAN segment zitten, dan krijgen ze allemaal dit DHCP bericht en denkt

de OpenEPC software dat de UE met alle vier de access netwerken tegelijk wil verbinden.

Hierdoor kan bijvoorbeeld een situatie ontstaan waarbij de UE denkt verbonden te zijn met

de eNodeB, maar OpenEPC routeert alle pakketten via de ePDG. Wanneer een client een

DHCP sollicit bericht verstuurt, moet dit verzonden worden via de interface waarop hij een

IP-adres nodig heeft. Het bericht is gericht naar een multicast adres. Alle DHCP servers van

het LAN segment ontvangen dan dit bericht en reageren hierop [25].

Meer details over hoe er een verbinding wordt gemaakt, is te vinden in sectie 6.1 van hoofdstuk


6. Hoe er een extra client aangemaakt kan worden, wordt beschreven in bijlage F. In bijlage

H staat het configuratiescript.

5.1.3 Het koppelen van externe UE’s aan de Virtual Wall

Om spraak en video te kunnen testen is het nodig dat de UE een externe standalone machine

is en niet een node op de Virtual Wall. De nodes op de Virtual Wall hebben geen audio-kaart

en X-forwarding gebruiken voor video is verre van performant. De Virtual Wall laat gelukkig

toe dat er een externe machine aan de Virtual Wall gekoppeld wordt. In principe wordt een

virtuele node gemapped op een fysieke machine.

Figuur 5.4: Minimalistische OpenEPC met externe Alice en Bob

Een UE is bij de standaard OpenEPC opstelling rechtstreeks aangesloten op de verschillende

access netwerken. Dit impliceert dat er vier ethernet kabels moeten gepatched worden buiten

de Virtual Wall. Aan de kant van de UE moet het toestel dan ook vier netwerkinterfaces

hebben. Omdat hiervoor nogal veel kabels en interfaces nodig zijn, is de opstelling beperkt

tot enkel het gebruik van LTE (figuur 5.4). Dan hoeft er slechts een kabel (per UE) gepatched

te worden en kan elk toestel met een interface gebruikt worden als UE. Het configuratiebestand

van deze opstelling bevindt zich in bijlage I.


Met deze opstelling is het nu mogelijk om portAlice en portBob te verbinden met een netwerk-

interface van een laptop. Er kunnen twee aparte laptops gebruikt worden of een laptop met

twee virtuele machines. Tijdens het uitvoeren van testscenario’s worden zowel twee laptops

als een laptop met twee virtuele machines gebruikt.

5.1.4 Handover tussen E-UTRAN en UTRAN

Om een handover tussen E-UTRAN en UTRAN te kunnen uittesten moet een toestel met

zowel een nodeB als eNodeB kunnen verbinden.

De elementen portAlice en portBob kunnen vervangen worden door de elementen portno-

deB en porteNodeB. Dezelfde kabels als bij vorige sectie kunnen nu hergebruikt worden om

handovers uit te voeren.Op figuur 5.6 zie je dat er zowel een NodeB als eNodeB is.

Figuur 5.5: Opstelling voor handover tussen E-UTRAN en UTRAN


5.1.5 Handover tussen E-UTRAN en WiFi

Met deze opstelling kan een handover tussen E-UTRAN en WiFi getest worden. De opstelling

is gelijkaardig als deze in de sectie hiervoor. Nu is de nodeB vervangen door een ePDG.

Figuur 5.6: Opstelling voor handover tussen E-UTRAN en WiFi

5.1.6 Fysiek WiFi access point en LTE femtocell

In de opstelling op figuur 5.7 is de eNodeB weggenomen. De eNodeB wordt dan vervangen

door een fysieke LTE femtocell. Aan de ePDG wordt een WiFi AP gekoppeld.


Figuur 5.7: Opstelling voor fysiek WiFi AP en LTE femtocell

5.2 Configuratie van de systemen

Om een systeem te configureren wordt het script /opt/OpenEPC/etc/configure system.sh ge-

bruikt. Dit script installeert en configureert alles om het systeem gebruiksklaar te maken.

Omdat de systemen geconfigureerd worden op nodes van de Virtual Wall zullen nog extra

aanpassingen nodig zijn. Zo zal het hernoemen van de interfaces tijdens het inswappen tel-

kens opnieuw moeten gebeuren. De DNS server van OpenEPC zal zijn aanvragen moeten

doorsturen naar de DNS server van de Virtual Wall en het testnetwerk van IBCN zal ook

altijd moeten bereikbaar zijn vanaf de nodes.


5.2.1 TCP Segmentation Offload (TSO)

Sommige TCP/IP operaties worden overgelaten aan de NIC (Network Interface Card) in

plaats van de CPU. Een veel voorkomende operatie is segmentatie. Een pakket dat groter is

dan de MTU van Ethernet, dat 1500 bytes is, wordt dan door de NIC in pakketten van 1500

bytes gesegmenteerd. OpenEPC houdt hier geen rekening mee. Als bijvoorbeeld de P-GW

een pakket van meer dan 1500 bytes moet versturen, treedt een foutmelding op. Het is dus

noodzakelijk dat de software zelf zorgt voor segmentatie. Daarom moet TSO uitgeschakeld

worden.

ERR: routing_raw_send ():385> Could not send packet > message too long

Om TSO uit te schakelen kan ethtool gebruikt worden.

janseeuw@pdngw :~$ sudo ethtool -k net_b

Offload parameters for net_b:

rx -checksumming: on

tx -checksumming: on

scatter -gather: on

tcp -segmentation -offload: off

udp -fragmentation -offload: off

generic -segmentation -offload: on

generic -receive -offload: on

large -receive -offload: off

rx -vlan -offload: on

tx -vlan -offload: on

ntuple -filters: off

receive -hashing: on

for i in rx tx sg tso ufo gso gro lro; do sudo ethtool -K net_b $i off; done

5.2.2 Interfaces

De namen van interfaces worden ingesteld in het bestand /etc/udev/rules/70-persistent-

net.rules. In dat bestand wordt de mapping van MAC-adres naar interface naam vastgelegd.

Bij het opnieuw inswappen van een experiment worden de nodes at random gekozen en zijn

de MAC-adressen van de netwerkkaarten dus steeds anders.

Bij het definieren van het experiment kiezen we vaste IP-adressen voor de verschillende inter-

faces, net zoals op de figuur in bijlage A. Na het inswappen wordt met een script nagegaan

welke netwerkkaart welk IP-adres heeft en dus meteen ook welk MAC-adres hier mee over-

eenkomt. Op basis daarvan stellen we dan de interface namen in en rebooten het systeem.

Het script is te vinden in bijlage L.


5.2.3 DNS

OpenEPC gebruikt een eigen DNS server. Alle componenten moeten deze DNS server gebrui-

ken. Na het inswappen gebruiken ze echter allemaal de DNS server van de Virtual Wall. Een

script (bijlage M) pollt telkens de DNS server van OpenEPC en wanneer die beschikbaar is,

wordt hij ingesteld als DNS server.

DNS aanvragen die niet kunnen beantwoord worden door de DNS server van OpenEPC

kunnen gewoon doorgegeven worden aan de DNS server van de Virtual Wall. Hiervoor wordt

het bestand named.conf aangepast.

options {

forwarders {

10.2.32.1;

};

}

5.2.4 NAT op EPC-Enablers

De EPC-Enablers gebruikt NAT voor internettoegang van de UE. De interface waarop NAT

toegepast moet worden, is na inswappen van het experiment niet altijd dezelfde. Daarom

wordt cat /var/emulab/boot/controlif gebruikt om de controle interface te vinden. De gateway

van de Virtual Wall is namelijk via de controle interface bereikbaar.

/sbin/iptables -P FORWARD ACCEPT

/sbin/iptables --table nat -F

/sbin/iptables --table nat -A POSTROUTING -o ‘cat /var/emulab/boot/controlif ‘

-j MASQUERADE

5.2.5 IP-forwarding

IP-forwarding wordt standaard ingeschakeld door de Virtual Wall. Maar omdat OpenEPC

routering zelf voor zijn rekening neemt, moet IP-forwarding uitgeschakeld worden. De EPC-

Enablers gebruikt wel nog IP-forwarding.

echo "0" > /proc/sys/net/ipv4/conf/all/forwarding

5.2.6 Routes naar IBCN/test netwerk

Om toegang te krijgen tot de nodes over SSH is het nodig om routes in te stellen (bijlage N).

Om testen uit te voeren kan het wel nodig zijn dat deze routes moeten verwijderd worden.


5.2.7 rc.local

De scripts om routes, DNS, IP forwarding en NAT in te stellen, worden aangeroepen vanuit

het bestand /etc/rc.local op elke machine. Dit bestand wordt automatisch uitgevoerd bij

opstarten.

Hoofdstuk 6

IP Connectiviteit in OpenEPC

Een volgende stap is om het volledige pad van UE tot het internet te onderzoeken. Het is

noodzakelijk dat de UE internettoegang heeft om spraakgesprekken te kunnen voeren. De

routering van pakketten wordt gerealiseerd door OpenEPC. De pakketten moeten uiteindelijk

de P-GW verlaten langs het SGi reference point (interface naar IP netwerken).

Figuur 6.1: Betrokken componenten [10]

36

Hoofdstuk 6. IP Connectiviteit in OpenEPC 37

De betrokken componenten en interfaces zijn aangeduid op figuur 6.1. Volgende secties

behandelen stap voor stap de route. Eerst moet de UE kunnen verbinden met een access

netwerk, daarna moet al het verkeer gerouteerd worden langs de PDN-GW om dan uiteindelijk

het kernnetwerk te verlaten langs de SGi interface.

6.1 Verbinding maken met een access netwerk

Figuur 6.2 toont de AN GW (Access Network Gateway) en PDN GW. Er is in OpenEPC een

gezamenlijke PDN GW. De PDN GW heeft een interface naar het Internet, het SGi reference

point. In OpenEPC zijn er meerdere AN GW’s afhankelijk van het type AN.

Figuur 6.2: Architectuur voor connectiviteit in het kernnetwerk [10]

AN GW kan een van volgende zijn:

• S-GW voor trusted 3GPP access (GERAN, UTRAN, E-UTRAN)

• ePDG voor untrusted non-3GPP access (WiFi)

6.1.1 Mobility Manager

De Mobility Manager is een software applicatie ontwikkeld door Fraunhofer FOKUS. De

applicatie zorgt voor de attachment en detachment procedures tijdens een handover. Ook om

een verbinding te maken of te verbreken met een van de access netwerken wordt de Mobility

Manager gebruikt [26]. Deze Mobility Manager is nodig omdat de UE geemuleerd is. De UE

is verbonden via een UTP-kabel met een AN GW. Een WiFi of LTE connectie gebeurt dus

via Ethernet.

Om als UE een verbinding te maken met een van de verschillende AN GW’s wordt gebruik-

gemaakt van EHCP. Het EHCP protocol is een aangepaste versie van het DHCPv6 protocol

ontwikkeld door Fraunhofer FOKUS. Deze aanpassingen zijn nodig om bijvoorbeeld een iden-

tificatie van de UE mee te sturen.

Er zijn twee modules voor EHCP nodig:


• ehcp messaging

• ehcp daemon

Figuur 6.3: Verbinding maken en verbreken met behulp van EHCP [10]

De Mobile Access Gateway (MAG) krijgt een request van de UE via het EHCP protocol.

De informatie in deze request wordt daarna verder doorgestuurd over een GPRS Tunneling

Protocol (GTP) of Proxy Mobile IP (PMIP) interface naar de Local Mobility Anchor (LMA).

De LMA zorgt voor het toekennen van een IP adres aan de UE. Het antwoord wordt terugge-

stuurd naar de UE. Voor elke combinatie van MAG en LMA wordt een tunnel opgezet. Deze

tunnel kan een GRE tunnel of GTP tunnel zijn.

Linux Mobility Manager en Mobility Manager GUI

De Mobility Manager en Mobility Manager GUI zijn geınstalleerd op de client machine (UE)

en zijn nodig om de gebruiker met een van de access netwerken te verbinden. De applicatie

maakt gebruik van de EHCP modules.


Figuur 6.4: Mobility Manager GUI verbonden met WiMAX [11]

Eens de client verbonden is met een van de verschillende access netwerken worden in OpenEPC

de correcte routes in het kernnetwerk geconfigureerd om het IP-verkeer te routeren.

Het International Mobile Subscriber Identity (IMSI) is een unieke identificatie voor een client.

Het IMSI-nummer van de client wordt ingesteld in het configuratie bestand /opt/OpenEP-

C/etc/mm.xml. De variabele subcription id stelt het IMSI-nummer (001011234567890) voor.

Dit nummer is random gekozen en heeft verder geen betekenis.

<Module binaryFile="modules/mm_andsf/mm_andsf.so" >

<![CDATA[

<MM_ANDSF >

<ANDSF

url="tcp ://192.168.1.31:10000"

timeout="5"

/>

<UE

subscription_type="1"

subscription_id="001011234567890"

alert_port="10005"

/>

</MM_ANDSF >

]]>


</Module >

Android Mobility Manager

Er is ook een Mobility Manager app voor Android. De app werkt niet op alle Android versies

[26]. De app werkte niet op het toestel (Samsung Galaxy S3) waarop het getest is tijdens

deze masterproef.

Figuur 6.5: Android Mobility Manager configuratie [11]

Figuur 6.5 toont het instellingenmenu van de Android Mobility Manager. In het IMSI-veld

kan het IMSI-nummer van de client opgegeven worden. Indien het veld leeg is wordt het

IMSI-nummer van de SIM-kaart gebruikt.

Het identificeren van de UE tijdens verbinden

DHCPv6 optie 135 in het DHCPv6 sollicit bericht wordt gebruikt om een identificatie van

de UE mee te geven. Als UE Alice verbindt heeft optie 135 de waarde 30303130313132333


4353637383930 hexadecimaal of 001011234567890 in ascii. Het getal 001011234567890 komt

overeen met het IMSI van Alice.

6.1.2 Verbinden zonder Mobility Manager

Een verbinding maken via LTE

Een LTE femtocell is een klein cellulair basisstation met een laag zendvermogen dat ontworpen

is om in een woonhuis of een klein bedrijf geplaatst te worden.

Om te verbinden met de LTE femtocell wordt een Huawei E398 USB Modem gebruikt. Omdat

er een eigen SIM kaart gebruikt wordt, moet het IMSI nummer ervan geregistreerd worden

in OpenEPC (zie bijlage R) Tijdens het verbinden treedt een probleem op. De Huawei

E398 USB Modem verwacht dat de NAS (Non-Access-Stratum) berichten afkomstig van de

MME beveiligd zijn. OpenEPC beveiligt deze berichten echter niet. De MME stuurt een

onbeveiligde authentication request naar de client. De client antwoordt hierop met een MAC

failure.

Een verbinding maken via WiFi

Het EHCP protocol is backwards compatibel met DHCP. Dit maakt het mogelijk dat elk

toestel verbinding kan maken met het OpenEPC-netwerk. Bij het verbinden met de ePDG via

het WiFi access point, wordt het MAC-adres van het toestel gebruikt als unieke identificatie

in plaats van een IMSI-nummer.


Figuur 6.6: iPhone verbonden met het OpenEPC netwerk via ePDG

Figuur 6.6 toont de verkregen informatie van DHCP na het verbinden. Na het instellen van

de HTTP proxy van de Virtual Wall kan er probleemloos op internet gegaan worden met het

toestel.

GTP interface tussen de eNB en S-GW en tussen de S-GW en P-GW

Figuur 6.7: GTP interface

Figuur 6.7 toont de berichten die uitgewisseld worden nadat een UE verbinding heeft gemaakt

met de eNB.


PMIP interface tussen de ePDG en P-GW

Figuur 6.8: PMIP interface

Figuur 6.8 toont de berichten die uitgewisseld worden nadat een UE verbinding heeft gemaakt

met de ePDG.

6.1.3 Web GUI

Na het tot stand komen van een connectie kan in de Web GUI de toestand van de MAG en

LMA opgevraagd worden.

Figuur 6.9: LMA Provisioning


Figuur 6.10: LMA PDN configuratie

Figuur 6.10 toont een lijst van PDN configuraties. Bij het kiezen van de default apn PDN

configuratie kunnen DNS configuratie (figuur 6.11), IPv4 range (figuur 6.12) en de geallo-

ceerde adressen (figuur 6.13) bekeken worden.

Figuur 6.11: DNS configuratie

Figuur 6.12: PDN IPv4 range


Figuur 6.13: PDN IPv4 allocaties

In de lijst van allocaties op figuur 6.13 komen twee MNI’s (Mobile Node Identifiers) voor:

IMSI en 99. IMSI spreekt voor zich. De andere worden toegevoegd wanneer er zonder gebruik

van de Mobility Manager met het WiFi AP verbinding gemaakt wordt. Een MNI wordt

gebruikt bij Mobile IPv6 om iets te kunnen identificeren met iets anders dan een IP-adres

[27].

Figuren 6.14 en 6.15 tonen dat de IP-adressen gekend zijn in de MAG en LMA.


Figuur 6.14: LMA binding lijst

Figuur 6.15: MAG binding lijst


6.2 Routering

OpenEPC zorgt zelf voor de routering van pakketten via verschillende soorten tunnels. De

Linux routeertabellen worden dus niet altijd geraadpleegd.

In hetgeen volgt wordt ervan uitgegaan dat de UE verbonden is met de eNodeB. Uplink

verkeer zijn pakketten afkomstig van de UE. Downlink verkeer zijn pakketten afkomstig van

het internet. Op de S-GW en P-GW worden pakketten gerouteerd met behulp van OpenEPC.

De routetabellen zijn opgeslaan in de modules van OpenEPC. De pakketten worden door de

P-GW (bij downlink) en eNodeB met behulp van sockets opgenomen door OpenEPC. Het

volledige IP-pakket wordt dus opgenomen. Tussen de eNodeB en S-GW en tussen de S-GW

en P-GW worden de pakketten telkens getunneld met het GTP protocol.

De UE (bij uplink) en P-GW (bij uplink) gebruiken de Linux routeertabellen om pakketten

door te sturen.

Als een UE verbinding maakt met het netwerk zal de eNodeB, S-GW en P-GW de juiste routes

instellen in hun routering modules. De eNodeB en P-GW zullen luisteren naar IP-pakketten

met behulp van raw sockets en zullen dan op basis van de ingestelde routeringsregels het

pakket encapsuleren en verder sturen. De S-GW ontvangt de geencapsuleerde pakketten,

decapsuleert, hercapsuleert en forward ze.

De routeertabellen van de verschillende componenten zijn te zien in bijlage O.

Als de UE verbinding maakt met de ePDG zijn de routeertabellen gelijkaardig, er wordt

dan wel niet getunneld met het GTP protocol (tunneling met het GTP protocol wordt enkel

gedaan tussen eNodeB, S-GW en P-GW), maar met het GRE protocol.


6.2.1 GTP tunnel tussen eNB en S-GW en tussen S-GW en P-GW

Figuur 6.16: GTP tunnel

Figuur 6.16 toont aan dat een ping bericht getunneld word met het GTP protocol.

6.2.2 GRE tunnel tussen ePDG en P-GW

Figuur 6.17: GRE tunnel

Figuur 6.16 toont aan dat een ping bericht getunneld word met het GRE protocol.

6.3 Het SGi reference point

Het SGi reference point wordt gebruikt op de P-GW om verkeer dat voor het Internet bestemd

is door te sturen. Het SGi reference point komt overeen met een netwerkinterface van de

machine die dienst doet als P-GW. Deze interface wordt gekozen in de configuratie van de P-

GW, in het /opt/OpenEPC/etc/pgw.xml bestand. In de routeertabel van de P-GW in bijlage


O is te zien dat verkeer, afkomstig van de UE, vezonden wordt via routing extension 2.

Deze routing extension wordt geconfigureerd in het xml bestand. 192.168.1.10 is de interface

waarmee de P-GW is aangesloten op het Net A LAN segment.

<Module binaryFile="modules/routing/routing.so">

<![CDATA[

<WharfROUTING >

<Extension

id="1"

mod_name="routing_encap"

src_table="teid"

dst_table="ip"

ipv4="192.168.2.10"

ipv6="FC00 :1234:2::10"

protocol="gre" />

<Extension

id="2"

mod_name="routing_raw"

dst_table="ip"

interface="net_a"

ipv4="192.168.1.10"

ipv6="FC00 :1234:1::10"

/>

<Extension

id="3"

mod_name="routing_gtpu"

src_table="teid"

dst_table="ip"

ipv4="192.168.2.10"

ipv6="FC00 :1234:2::10"/>

</WharfROUTING >

]]>

</Module >

Deze configuratie dient er enkel voor om op de correcte interface een socket te laten luisteren

naar inkomende pakketten van het Net A LAN segment (het internet). De routeertabel van

Linux wordt gebruikt om pakketten, afkomstig van de UE, te versturen. Als een pakket

niet gerouteerd kan worden met behulp van de routetabel in Linux, krijgt de PGW een

foutmelding.

ERR: routing_raw_send ():385> Could not send the packet > Network is

unreachable

Hoofdstuk 7

Realiseren van spraakgesprekken

met OpenEPC

Bij OpenEPC zijn enkele applicaties meegeleverd die kunnen gebruikt worden om spraak-

gesprekken te realiseren. Als de UE internettoegang heeft verkregen kan Skype gemakkelijk

gebruikt worden voor Over The Top diensten. Het Open IMS Core maakt VoLTE mogelijk.

7.1 Beschikbare applicaties in OpenEPC

OpenEPC beschikt over drie applicaties die verbonden zijn met het EPC:

• HTTP proxy: wordt gebruikt om HTTP verkeer te kunnen inspecteren en deze te

koppelen aan een sessie om verder op te volgen in het kernnetwerk

• Media Delivery Function (MDF): om video’s te streamen

• Open IMS Core (IMS): een aangepaste Open Source implementatie van de IMS Call

Session Control Functions (CSCF’s)

Deze applicaties worden gebruikt als Application Function (AF) (aangeduid op figuur 7.1).

De HTTP proxy en het Open IMS Core worden in dit hoofdstuk besproken.

50

Hoofdstuk 7. Realiseren van spraakgesprekken met OpenEPC 51

Figuur 7.1: Application Function [10]

7.1.1 HTTP proxy

De HTTP proxy dient om het HTTP-verkeer op te vangen, dit te koppelen aan een sessie per

gebruiker en verder op te volgen in het kernnetwerk.


Figuur 7.2: HTTP proxy [12]

De HTTP proxy is een Squid server [11]. Squid is een veelgebruikte proxyserver. De configu-

ratie heeft enkele aanpassingen als volgt:

...

# Here is the configuration of the external ACL

external_acl_type Rx_auth children =1 %SRC %MYADDR %DST /opt/OpenEPC/

squid_rx_auth/rx_auth 127.0.0.1 10002 192.168.1.42

...

# Here is the definition of one ACL

acl sip:[email protected] external Rx_auth

...

# Here we accept the requests which got the OK from the Rx

http_access allow sip:[email protected]

...

# Here is for denying all other traffic

http_access deny all

...

Deze aanpassingen zorgen ervoor dat de ACL (Access Control List) dynamisch aangepast kan

worden.

Een tekortkoming aan de HTTP Proxy is dat het beeındigen van een sessie niet wordt op-

gevangen. Omdat de sessies niet oneindig lang zouden bestaan, worden deze na een bepaald

tijdsinterval automatisch verwijderd.

De HTTP proxy werkt niet out-of-the-box. Er moeten handmatig nog enkele symbolische

links worden ingesteld (bijlage P).


De HTTP proxy kan dan op de UE, in bijvoorbeeld Firefox, gebruikt worden.

Figuur 7.3: HTTP proxy geconfigureerd op de UE

HTTP proxy van de Virtual Wall

De Virtual Wall maakt ook gebruik van een HTTP proxy. De HTTP proxy van OpenEPC

moet al het verkeer doorsturen naar de proxy van de Virtual Wall. Om dit te realiseren

worden volgende lijnen toegevoegd aan de configuratie (/etc/squid3/squid.conf ).

cache_peer 157.193.215.17 parent 8080 0

never_direct allow all

Als alternatief kan op de client het adres 157.193.215.17 met poort 8080 gebruikt worden als

proxy in plaats van de proxy van OpenEPC.

7.1.2 Open IMS Core

De Open IMS Core [13] is een Open Source implementatie van de IMS Call Session Control

Functions (CSCF’s) en een Home Subscriber Server (HSS), die samen de hoofdelementen

vormen van de IMS architectuur.


Figuur 7.4: Open IMS Core [13]

Er zijn enkele aanpassingen doorgevoerd om beter te kunnen integreren in OpenEPC. Zo

wordt de HSS van OpenEPC gebruikt in plaats van die van het Open IMS Core. Er is

een extra aangepaste P-CSCF zodat de Open IMS Core kan verbonden worden met de Rx

interface van de PCRF in OpenEPC (figuur 7.5). Er zijn dan twee verschillende P-CSCF’s

beschikbaar, een met en een zonder PCC functionaliteit.


Figuur 7.5: Open IMS Core verbonden met OpenEPC [12]

7.2 OTT met behulp van Skype

Wanneer de UE een IP-adres heeft verkregen van een van de access netwerken moet er nog

rekening gehouden worden met volgende zaken vooraleer Skype kan werken. Het gebruik

van de HTTP proxy van OpenEPC is niet verplicht, de proxy van de Virtual Wall kan ook

gebruikt worden.

• NAT moet toegepast worden door de EPC Enablers (zie hoofdstuk 5)

• TCP Segmentation Offloading moet uitgezet worden op alle systemen (zie hoofdstuk 5)

• De juiste proxy moet ingesteld worden in Skype (HTTP proxy van OpenEPC of proxy

van de Virtual Wall)

• Indien de proxy van de Virtual Wall rechtstreeks gebruikt wordt (dus niet via de HTTP

proxy van OpenEPC) dan moeten de routes naar het IBCN/test netwerk verwijderd

worden uit de routeertabel van alle systemen.

7.3 IMS met behulp van Monster IMS client

Om een gesprek die gebruik maakt van het IMS op te zetten kan MONSTER (Multimedia

Open Internet Services and Telecommunication Environment) [28] gebruikt worden. MON-

STER is ontwikkeld door Fraunhofer FOKUS en is een van de applicaties die geınstalleerd


wordt op de client (UE) machine. Om de applicatie te gebruiken moet een gebruikersprofiel

gedefinieerd zijn. Er zijn gebruikersprofielen voor Alice en Bob beschikbaar.

7.3.1 Gebruikersprofielen

Bij het opstarten van de MONSTER client moet een profiel gekozen worden. Figuur 7.6

toont de profielen voor Alice. Er is een profiel met en zonder Policy and Charging Control

(PCC) functionaliteit.

Figuur 7.6: Alice Monster profielen

De MONSTER client met de profielen van Alice kan gestart worden met het commando:

root@uealice: /opt/OpenEPC/bin/MONSTER.Alice.sh

Hoofdstuk 8

Policies en QoS in OpenEPC

Het EPC kan met behulp van PCC (Policy and Charging Control) er voor zorgen dat de

nodige Quality of Service (QoS) bereikt wordt. Er is onderzocht of deze policies kunnen

gebruikt worden om bijvoorbeeld spraakverkeer hogere prioriteit te geven. De latency en

packet loss voor spraakverkeer kunnen hierdoor geminimaliseerd worden. Ook is onderzocht

welke invloed achtergrondverkeer heeft op spraakverkeer. De componenten die hiervoor nodig

zijn, zijn aangeduid op figuur 8.1.

57

Hoofdstuk 8. Policies en QoS in OpenEPC 58

Figuur 8.1: De componenten en interfaces betrokken bij Policy and Charging Control (PCC) [14]

8.1 Policy and Charging Control (PCC)

De PCC architectuur (figuur 8.2) bestaat uit een PCRF, een PCEF en meerdere BBERF’s.

De PDN GW heeft een PCEF en elke AN GW heeft een BBERF. Het Rx reference point

wordt gebruikt door AF’s om QoS vereisten door te geven aan de PCRF. De AF’s werden

besproken in sectie 7.1.


Figuur 8.2: PCC architectuur [15, 16]

8.2 Instellen van policies

Policies kunnen ingesteld worden in de Web GUI van OpenEPC (figuur 8.3). Hiervoor

selecteer je PCC en daarna PCRF in het menu bovenaan. In het linkermenu vind je dan

volgende drie onderdelen:

• PCRF Policies: hier kunnen de policy regels ingesteld en gegroepeerd worden

• PCRF Constants: geeft constanten weer die gebruikt worden, deze mogen niet aangepast

worden

• Debugging: geeft de actieve sessies en PCC regels weer


Figuur 8.3: PCC Web GUI

Er zijn al enkele policy regels ingesteld in OpenEPC (figuur 8.3). De Default Bearer policy

wordt altijd toegepast, IMS Registration en IMS Services worden gebruikt bij het IMS. De

regels RadioTvAndalucia en Youtube worden toegepast in combinatie met de HTTP proxy

(wanneer er naar www.youtube.com of www.radiotelevisionandalucia.es gesurfed wordt). Elke

policy regel bestaat uit een lijst met condities en een lijst van acties die uitgevoerd worden

wanneer aan de condities voldaan is.


Figuur 8.4: Policy regels

8.2.1 Default bearer policy

De Default Bearer policy stelt bijvoorbeeld de maximale bandbreedte in op 64 kbps (figuur

8.5).

Figuur 8.5: Default bearer acties

8.2.2 Youtube policy

De Youtube policy heeft volgende condities (figuur 8.6) en acties (figuur 8.7).


Figuur 8.6: Youtube condities

Figuur 8.7: Youtube acties

8.3 Problemen

Bij het testen van policies en het nader onderzoeken van de configuratiebestanden is opge-

merkt dat de modules voor QoS in commentaar staan. Volgens Fraunhofer FOKUS zijn er

problemen met de modules en kunnen ze daarom niet gebruikt worden. Het toepassen van

de bandbreedtebeperking (zoals ingesteld bij de default bearer) is ook niet geımplementeerd.

Er kan ook maar een bearer gebruikt worden in OpenEPC en dit is de default bearer. On-

dersteuning voor dedicated bearers, met gegarandeerde bitrate, voor bijvoorbeeld VoIP is er

niet.

janseeuw@uealice :~$ sudo iperf -c 192.168.1.32 -u -b 100m

------------------------------------------------------------

Client connecting to 192.168.1.32 , UDP port 5001

Sending 1470 byte datagrams

UDP buffer size: 224 KByte (default)

------------------------------------------------------------

[ 3] local 192.168.3.100 port 60776 connected with 192.168.1.32 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0 -10.0 sec 120 MBytes 101 Mbits/sec

[ 3] Sent 85470 datagrams

Hoofdstuk 9

Handover van dataverbindingen

met OpenEPC

Een handover is het proces waarbij een datasessie naar een wireless terminal wordt getransfe-

reerd van het ene base station naar een ander base station, zonder onderbreking van de sessie

[29].

Er kan een onderscheid gemaakt worden tussen twee soorten handovers:

• Een handover tussen 3GPP access technologieen.

• Een handover tussen 3GPP en non-3GPP access technologieen.

Naast bovengenoemd onderscheid kan er ook nog een onderscheid gemaakt worden tussen een

hard en soft handover:

• Bij een hard handover wordt de verbinding eerst verbroken van het oude RAN. Daarna

wordt pas verbinding gemaakt met het nieuwe RAN.

• Bij een soft handover wordt eerst een verbinding met het nieuwe RAN gemaakt. Pas

daarna wordt de verbinding met het oude RAN verbroken.

Binnen eenzelfde 3GPP access technologie (vb. E-UTRAN) kunnen ook handovers gebeuren.

Meer informatie over handovers is te vinden in [3]. Tijdens deze masterproef worden handovers

tussen zowel 3GPP access technologieen als tussen 3GPP en non-3GPP access technologieen

getest.

De handovers zoals ze door Fraunhofer FOKUS zijn geımplementeerd zijn hard handovers.

De handover gebeurt dus niet zoals de 3GPP procedures het voorschrijven.

63

Hoofdstuk 9. Handover van dataverbindingen met OpenEPC 64

9.1 Handover van E-UTRAN naar UTRAN en vice versa

Voor deze handover wordt de geemuleerde eNodeB en NodeB gebruikt. De opstelling hiervoor

is terug te vinden in sectie 5.1.4. Als client wordt een virtuele machine gebruikt. Hierop

is dan de Mobility Manager geınstalleerd waarmee een handover getriggerd kan worden. De

virtuele machine draait op een laptop met twee ethernet interfaces (een interface naar de

eNodeB en een interface naar de NodeB).

9.2 Handover van E-UTRAN naar WiFi en vice versa

De opstelling van sectie 5.1.5 maakt ook gebruik van een geemuleerde eNodeB. Er wordt

opnieuw een virtuele machine gebruikt als client. De connectie met de ePDG verloopt via een

ethernet kabel, er kan dus gesteld worden dat het WiFi signaal ook geemuleerd is.

9.2.1 Handover met behulp van LTE femtocell en fysiek WiFi AP

De geemuleerde eNodeB moet vervangen worden door een fysieke LTE femtocell. Hiervoor

is de opstelling in sectie 5.1.6 nodig. In plaats van nu rechtstreeks met een UTP-kabel te

verbinden met de ePDG, wordt er een WiFi AP in bridge modus tussen geplaatst. Het WiFi

AP is een D-LINK DAP-1360. Voor LTE femtocell wordt een ip.access LTE Access Point

Model 245F gebruikt. De configuratie van de LTE femtocell is te vinden in bijlage Q.

Tijdens deze masterproef is het niet mogelijk om dit verder te testen. Met behulp van een

LTE dongle was het niet mogelijk om een verbinding te maken met het OpenEPC. Met een

smartphone kan met behulp van de Mobility Manager het IMSI- nummer niet doorgegeven

worden. Een smartphone met LTE ondersteuning is ook niet beschikbaar. Meer informatie

is ook te vinden in sectie 6.1.

9.3 Handovers zonder onderbreking van de sessie

Tijdens de handover is onderzocht of een sessie verbroken wordt of niet. Hiervoor is een Skype

gesprek opgezet en wordt gedurende het gesprek een handover getriggerd. De sessie blijft

behouden en de client merkt helemaal geen verschil tijdens de handover. In het configuratie

bestand /opt/OpenEPC/etc/pgw.xml kan een optie van de LMA module ingesteld worden.

De optie heet seamless en bepaalt of de sessie verbroken mag worden tijdens een handover.

De reden waarom de sessie behouden blijft is omdat het IP-adres van de UE behouden blijft.

OpenEPC zal dan gewoon de routering aanpassen in het kernnetwerk zodat de pakketten naar

Hoofdstuk 9. Handover van dataverbindingen met OpenEPC 65

de UE via het nieuwe RAN toekomen. Het zijn dus zeker geen handover zoals die door 3GPP

voorgeschreven zijn. Dit kan dus enkel door het feit dat er een Mobility Manager gebruikt

wordt door de UE (zie sectie 6.1).

<Module binaryFile="modules/lma/lma.so">

<![CDATA[



<WharfLMA

ipv4=""

ipv6="fc00 :1234:2::10"

hash_size="32"

seamless="1">

</WharfLMA >

]]>

</Module >

Hoofdstuk 10

Besluit

De bedoeling van deze masterproef was om voice over IP mogelijk te maken in het LTE

testnetwerk. Een uitgebreide literatuurstudie was noodzakelijk om de werking van een LTE

netwerk te kunnen begrijpen. De documentatie over OpenEPC was erg beperkt. Het was

nodig om vragen te stellen aan Fraunhofer FOKUS om meer verduidelijking te krijgen over

de werking van bepaalde functionaliteiten. De OpenEPC software is erg complex en de instal-

latie verliep niet zonder problemen. Wanneer het LTE testnetwerk in orde was, konden vlot

spraakgesprekken uitgevoerd worden. Er werden twee pistes bewandeld: Spraakgesprekken

met behulp van een Over The Top provider Skype en Voice over LTE met het IMS.

Er was nog ruimte om enkele andere use case scenario’s te testen. Zo werd de invloed van

een handover van LTE naar WiFi op Voice over IP bekeken. QoS toepassen op Voice over IP

met behulp van policies werd belemmerd doordat het niet volledig geımplementeerd was in

OpenEPC. Het aansluiten van een fysieke LTE femtocell lukte zonder problemen, maar bij

het verbinden waren compatibiliteitsproblemen.

Tijdens deze masterproef is dan ook elke mogelijke use case volledig getest en geevalueerd.

De problemen die hierbij voorkwamen zijn neergeschreven.

66

Bijlage A

Gedetailleerde OpenEPC opstelling

Figuur A.1: OpenEPC opstelling

67

Bijlage B

Algemene projectstructuur van

OpenEPC

/opt/OpenEPC

bin/..........................start, stop, kill, attach scripts voor alle componentenetc/...................................configuratiebestanden van alle componenten

bind/..........................................DNS (Bind9) server configuratiedhcp/................................................DHCP client configuratiedhcpd/...............................................DHCP server configuratieinit/.............................configuratiebestanden voor start/stop/restartinit.d/............ service-achtige wrappers voor bin scripts (start/stop/restart)monster.alice,bob,charlie,etc/..........................client configuratiesmysql/..............................................MySQL server configuratienetwork/.........................................netwerk adapter configuratiessql/........................................databank structuur en data dumpssquid/.........................................Squid HTTP proxy configuratiewww/.....................................................Web GUI configuratieconfigure system.sh.....................script om een systeem te configureren*.xml......................Wharf configuraties voor de OpenEPC componenten

mm gui/..........................................de Client Mobility Manager GUIrun/ ...............................placeholder voor run-time bestanden en uitvoersbin/...................................................special binaries en scriptsser ims/..............................................Het Open Source IMS Coresquid rx auth/...................................................Squid Rx clientwharf/.....................................................Het Wharf framework

68

Bijlage C

Het gebruik van OpenEPC met

Virtuele Machines in VMWare

De opstelling moet uitgepakt worden in een map /opt/vmteam op de host machine. Als

een ander pad noodzakelijk is of als de host machine niet draait op Linux, zijn er scripts

beschikbaar om dit pad aan te passen. Als je een VM voor de eerste keer start en er wordt

gevraagd of deze verplaatst of gekopieerd is, kies je de optie dat hij verplaatst is (zie figuur

C.1). Dit zorgt ervoor dat er geen nieuwe MAC adressen voor de virtuele netwerkkaarten

gegenereerd worden en je /etc/udev/rules/70-persistent-net.rule niet moet aanpassen

op alle guest machines.

Figuur C.1: Bij opstarten VM

De host machine moet een IP adres hebben in de 192.168.254.x range. Dit is het netwerk

waarop de management interfaces van OpenEPC geconfigureerd zijn. Om toegang te hebben

van host naar de guest machines en omgekeerd is het dus best dat de host een correct IP heeft

(192.168.254.2). Alle machines, behalve de machine die client voorstelt, zijn geconfigureerd

met een default gateway zodat ze internettoegang hebben via de host machine, bijvoorbeeld

voor een update. Voor de client kan je een script gebruiken om de default gateway via de

host machine aan of uit te zetten.

/opt/OpenEPC/sbin/set_route_default_via_mgmt.sh

69

Bijlage C. Het gebruik van OpenEPC met Virtuele Machines in VMWare 70

/opt/OpenEPC/sbin/set_route_default_via_mgmt.sh

Manueel kan je dit ook doen als volgt

ip route add default via 192.168.254.2

echo "nameserver 192.168.254.2" > /etc/resolv.conf

en om het terug ongedaan te maken

ip route del default via 192.168.254.2

Het default wachtwoord voor root is epc op alle systemen. De logingegevens voor de Web

GUI (http://www.openepc.test) zijn admin met wachtwoord epc.

Bijlage D

Installatie van OpenEPC

De eerste stap tijdens de configuratie is het hernoemen van de netwerkinterfaces. Dit is nodig

zodat er in de configuratiebestanden correct verwezen kan worden naar de netwerkinterfaces.

Zo wordt eth0, eth1, eth2, ... veranderd naar net a, net b, an lte,..., afhankelijk van wat waar-

mee geconnecteerd is. Dit kan verwezenlijkt worden door het bestand /etc/udev/rules/70-

persistent-net.rules aan te passen. Dit bestand toont de persistente koppeling tussen MAC

adres en interface alias.

vim /etc/udev/rules.d/70- persistent -net.rules

De volgende stap tijdens de configuratie is het plaatsen van de /opt/OpenEPC directory op

de systemen. Configureren van een systeem gebeurt dan door het script /opt/OpenEPC/et-

c/configure system.sh uit te voeren. Dit script vraagt interactief naar welke component je

wilt configureren en met welke parameters dit moet gebeuren. Daarna zorgt het script ervoor

dat alle benodigdheden geınstalleerd en geconfigureerd worden zoals het installeren van de-

pendencies, compileren van bronnen, linken van configuraties, instellen van opstartscripts of

maken van databanken. Na het heropstarten worden de netwerkinterfaces correct benoemd

en starten alle services op. Het systeem zou zich nu moeten gedragen zoals de gekozen com-

ponent.

apt -get install subversion

cd /opt

svn checkout https :// extsvnsrv.fokus.fraunhofer.de/svn/cc/ngni/iMinds/setup/

OpenEPCRel4

cd /opt/OpenEPC/etc

./ configure_system.sh

71

Bijlage E

Bedienen van de componenten in

OpenEPC

De componenten gebruiken de screen utility om de processen in de achtergrond te plaatsen

en om later te kunnen re-attachen. De geschiedenis van alle uitvoer is ook zichtbaar.

Om de lijst van componenten op een systeem te zien gebruik je volgend commando:

root@machine:$ screen -ls

Om te attachen met een component (vb. angw) om zo zijn uitvoer te kunnen zien, te debuggen

of procedures te triggeren, gebruik je het commando:

root@machine:$ screen -r angw

Om te de-attachen zonder dat de component stopt met werken gebruik je de toetsencombinatie

Ctrl-A,D.

Om een component te herstarten gebruik je het commando:

root@machine:$ restart angw

E.1 Configuratie van componenten

Om een component te herconfigureren, pas je de bestanden in /opt/OpenEPC/etc aan. Je

kan nagaan in de /opt/OpenEPC/bin scripts met welke configuraties de componenten gestart

worden.

72

Bijlage E. Bedienen van de componenten in OpenEPC 73

E.2 Provisioning van componenten

De meeste componenten bewaren hun staat in een databank. Een voordeel hiervan is dat

de componenten makkelijk kunnen herstart worden bij het herconfigureren of als er fouten

optreden.

De provisioning interface is beschikbaar op http://www.openepc.test (http://192.168.1.32) of

http://www2.openepc.test (http://192.168.254.32) (zie figuur E.1).

Figuur E.1: OpenEPC Web GUI

Voor de provisioning van componenten zijn een deel PHP pagina’s voorzien die volgende

operaties toelaten:

• Raadplegen van de inhoud van de databanken. Informatie op een eenvoudige manier

tonen en toelaten deze te wijzigen.

• Weergeven van extra debug informatie zoals de interne data van componenten die op-

geslagen zit in de databanken.

Bijlage E. Bedienen van de componenten in OpenEPC 74

• Aanbieden van een eenvoudige interface om events te sturen naar de componenten of

het opvragen van de status van componenten. Dit gebeurt door het verbinden met de

Wharf remote consoles en de live interactie door middel van commando’s.

De eerste 2 categorieen van operaties zijn niet afhankelijk van een draaiend Wharf proces

en kunnen offline gebruikt worden. De derde categorie vereist dat de component draait en

bereikbaar is vanuit de machine die de web interface weergeeft. De Web GUI draait bovenop

een Apache2 platform. Deze wordt verkregen door het uitvoeren van /opt/OpenEPC/etc/-

configure system.sh en het installeren van de WWW component.

E.2.1 Wissen van de data in de databank

De volledige opstelling slaat zijn data in de databank op. Om de data te wissen van vorige

testsessies op het testbed kan het volgende commando gebruikt worden:

root@machine:$ /opt/OpenEPC/sbin/cleanup/cleanup_for_demo.sh

Dit script zal de inhoud van de databanken wissen en de services herstarten.

E.3 Testbed SSH sleutelverdeling

Om het authenticatieproces te vermijden tijdens het verbinden van de ene component naar een

andere component (vb. van EPC Enablers naar PDN GW) is er een script dat de gegenereerde

RSA sleutel verdeelt over alle componenten.

root@machine:$ /opt/OpenEPC/sbin/prepare_system/ssh_keys_prepare.sh

Het resultaat is dat bij het wissen van de databank er nu niet meer telkens om een wachtwoord

zal gevraagd worden zodat de procedure efficienter verloopt.

Bijlage F

Maken van een extra UE

Tijdens de configuratie van een component van OpenEPC worden naast het installeren en con-

figureren van software ook enkele parameters ingesteld. Het installatiescript van OpenEPC

vraagt bij het configureren van een client component naar de naam van de gebruiker (vb.

Alice). Deze parameters worden dan opgeslagen in het bestand /opt/OpenEPC/etc/confi-

gure system vars.sh. Door dit laatstgenoemde bestand te verwijderen, wordt bij het heruit-

voeren van het script /opt/OpenEPC/etc/configure system.sh opnieuw gevraagd welke com-

ponent er geınstalleerd moet worden.

janseeuw@uealice :~$ sudo rm /opt/OpenEPC/etc/configure_system_vars.sh

janseeuw@uealice :~$ sudo /opt/OpenEPC/etc/configure_system.sh

Which node are you configuring? (epc -enablers ,pgw ,sgw -mme -sgsn ,enodeb ,nodeb ,

epdg ,angw ,client): client

Which UE do you want to configure? (alice , bob) [alice]:bob

The client can be configured on a real system , using real wireless interfaces ,

or as inside a virtual machine with simulated interfaces.

Configuring the client for which kind of setup? (virtual , physical) [virtual ]:

For authentication in non -3GPP networks , the client can opt between using EAP -

AKA or EAP -AKA ’ authentication.

Which EAP algorithm to use? (aka , aka_prime) [aka]:

OpenEPC >>> Initial configuration for system epc -client -bob

OpenEPC >>> Linking /opt/OpenEPC/etc/network/interfaces.epc -client -bob /etc/

network/interfaces

...

75

Bijlage G

Configuratiescript van standaard

OpenEPC

####################################################

#

# OpenEPC Wall2 NS File

#

####################################################

set ns [new Simulator]

source tb_compat.tcl

####################################################

# Nodes

####################################################

set ANGw [$ns node]

tb -set -node -os $ANGw ANGW

set eNodeB [$ns node]

tb -set -node -os $eNodeB ENODEB

set EPCEnablers [$ns node]

tb -set -node -os $EPCEnablers EPCENABLERS

set ePDG [$ns node]

tb -set -node -os $ePDG EPDG

set nodeB [$ns node]

tb -set -node -os $nodeB NODEB

set PDNGW [$ns node]

tb -set -node -os $PDNGW PDNGW

76

Bijlage G. Configuratiescript van standaard OpenEPC 77

set SGW [$ns node]

tb -set -node -os $SGW SGW

set UEAlice [$ns node]

tb -set -node -os $UEAlice UEALICE

####################################################

# Lans

####################################################

set mgmt [$ns make -lan "$ANGw $eNodeB $EPCEnablers $ePDG $nodeB $PDNGW $SGW$UEAlice" 1000Mb 0.0ms]

set net -a [$ns make -lan "$EPCEnablers $PDNGW" 1000000.0 kb 0.0ms]

set net -b [$ns make -lan "$ANGw $ePDG $PDNGW $SGW" 1000000.0 kb 0.0ms]

set net -d [$ns make -lan "$eNodeB $nodeB $SGW" 1000000.0 kb 0.0ms]

set net -umts [$ns duplex -link $nodeB $UEAlice 1000000.0 kb 0.0ms DropTail]

set net -lte [$ns duplex -link $eNodeB $UEAlice 1000000.0 kb 0.0ms DropTail]

set net -wifi [$ns duplex -link $ePDG $UEAlice 1000000.0 kb 0.0ms DropTail]

set net -wimax [$ns duplex -link $ANGw $UEAlice 1000000.0 kb 0.0ms DropTail]

# Set ip addresses on mgmt interface

tb -set -ip -lan ANGw mgmt "192.168.254.22"

tb -set -ip -lan eNodeB mgmt "192.168.254.90"

tb -set -ip -lan EPCEnablers mgmt "192.168.254.30"

tb -set -ip -lan ePDG mgmt "192.168.254.21"

tb -set -ip -lan nodeB mgmt "192.168.254.110"

tb -set -ip -lan PDNGW mgmt "192.168.254.10"

tb -set -ip -lan SGW mgmt "192.168.254.20"

tb -set -ip -lan UEAlice mgmt "192.168.254.100"

# Set ip addresses on net -a lan

tb -set -ip -lan EPCEnablers net -a "192.168.1.30"

tb -set -ip -lan PDNGW net -a "192.168.1.10"

# Set ip addresses on net -b lan

tb -set -ip -lan PDNGW net -b "192.168.2.10"

tb -set -ip -lan SGW net -b "192.168.2.20"

tb -set -ip -lan ePDG net -b "192.168.2.21"

tb -set -ip -lan ANGw net -b "192.168.2.22"

# Set ip addresses on net -c lan

tb -set -ip -link ePDG net -wifi "192.168.3.21"

tb -set -ip -link ANGw net -wimax "192.168.3.22"

tb -set -ip -link nodeB net -umts "192.168.3.28"

tb -set -ip -link eNodeB net -lte "192.168.3.29"

Bijlage G. Configuratiescript van standaard OpenEPC 78

# this one is from the DHCP range

tb -set -ip -link UEAlice net -wifi "192.168.3.130"

tb -set -ip -link UEAlice net -wimax "192.168.3.129"

tb -set -ip -link UEAlice net -umts "192.168.3.131"

tb -set -ip -link UEAlice net -lte "192.168.3.132"

# Set ip addresses on net -d lan

tb -set -ip -lan SGW net -d "192.168.4.20"

tb -set -ip -lan nodeB net -d "192.168.4.110"

tb -set -ip -lan eNodeB net -d "192.168.4.90"

####################################################

# Start -up Scripts

####################################################

tb -set -node -startcmd $EPCEnablers "sudo bash /proj/OpenEPC/ibcn_scripting/

swapin/epcenablers_swapin.sh"

tb -set -node -startcmd $ANGw "sudo bash /proj/OpenEPC/ibcn_scripting/swapin/

angw_swapin.sh"

tb -set -node -startcmd $eNodeB "sudo bash /proj/OpenEPC/ibcn_scripting/swapin/

enodeb_swapin.sh"

tb -set -node -startcmd $ePDG "sudo bash /proj/OpenEPC/ibcn_scripting/swapin/

epdg_swapin.sh"

tb -set -node -startcmd $nodeB "sudo bash /proj/OpenEPC/ibcn_scripting/swapin/

nodeb_swapin.sh"

tb -set -node -startcmd $PDNGW "sudo bash /proj/OpenEPC/ibcn_scripting/swapin/

pdngw_swapin.sh"

tb -set -node -startcmd $SGW "sudo bash /proj/OpenEPC/ibcn_scripting/swapin/

sgw_swapin.sh"

tb -set -node -startcmd $UEAlice "sudo bash /proj/OpenEPC/ibcn_scripting/swapin/

uealice_swapin.sh"

####################################################

$ns rtproto Manual

$ns run

####################################################

Bijlage H

Configuratiescript van OpenEPC

met virtuele Alice en Bob

####################################################

#


#

####################################################



####################################################

# Nodes

####################################################

set ANGw [$ns node]

tb -set -node -os $ANGw ANGW


tb -set -node -os $eNodeB ENODEB


tb -set -node -os $EPCEnablers EPCENABLERS

set ePDG [$ns node]





tb -set -node -os $PDNGW PDNGW

set SGW [$ns node]

79

Bijlage H. Configuratiescript van OpenEPC met virtuele Alice en Bob 80

tb -set -node -os $SGW SGW

set UEAlice [$ns node]

tb -set -node -os $UEAlice UEALICE

set UEBob [$ns node]

tb -set -node -os $UEBob UEBOB

####################################################

# Lans

####################################################

set mgmt [$ns make -lan "$ANGw $eNodeB $EPCEnablers $ePDG $nodeB $PDNGW $SGW$UEAlice" 1000Mb 0.0ms]


set net -b [$ns make -lan "$ANGw $ePDG $PDNGW $SGW" 1000000.0 kb 0.0ms]

set net -d [$ns make -lan "$eNodeB $nodeB $SGW" 1000000.0 kb 0.0ms]

set net -umts [$ns make -lan "$nodeB $UEAlice $UEBob" 1000000.0 kb 0.0ms]

set net -lte [$ns make -lan "$eNodeB $UEAlice $UEBob" 1000000.0 kb 0.0ms]

set net -wifi [$ns make -lan "$ePDG $UEAlice $UEBob" 1000000.0 kb 0.0ms]

set net -wimax [$ns make -lan "$ANGw $UEAlice $UEBob" 1000000.0 kb 0.0ms]


tb -set -ip -lan ANGw mgmt "192.168.254.22"







tb -set -ip -lan UEAlice mgmt "192.168.254.100"








tb -set -ip -lan ANGw net -b "192.168.2.22"

# Set ip addresses on net -c lan

tb -set -ip -lan ePDG net -wifi "192.168.3.21"

tb -set -ip -lan ANGw net -wimax "192.168.3.22"

tb -set -ip -lan nodeB net -umts "192.168.3.28"


tb -set -ip -lan eNodeB net -lte "192.168.3.29"

# this one is from the DHCP range

tb -set -ip -lan UEAlice net -wifi "192.168.3.130"

tb -set -ip -lan UEAlice net -wimax "192.168.3.129"

tb -set -ip -lan UEAlice net -umts "192.168.3.131"

tb -set -ip -lan UEAlice net -lte "192.168.3.132"

tb -set -ip -lan UEBob net -wifi "192.168.3.134"

tb -set -ip -lan UEBob net -wimax "192.168.3.133"

tb -set -ip -lan UEBob net -umts "192.168.3.135"

tb -set -ip -lan UEBob net -lte "192.168.3.136"





####################################################

# Start -up Scripts

####################################################



tb -set -node -startcmd $ANGw "sudo bash /proj/OpenEPC/ibcn_scripting/swapin/

angw_swapin.sh"


enodeb_swapin.sh"


epdg_swapin.sh"


nodeb_swapin.sh"


pdngw_swapin.sh"


sgw_swapin.sh"

tb -set -node -startcmd $UEAlice "sudo bash /proj/OpenEPC/ibcn_scripting/swapin/

uealice_swapin.sh"

tb -set -node -startcmd $UEBob "sudo bash /proj/OpenEPC/ibcn_scripting/swapin/

uebob_swapin.sh"


####################################################

$ns rtproto Manual

$ns run

####################################################

Bijlage I

Configuratiescript van minimale

OpenEPC met externe Alice en Bob

####################################################

#


#

####################################################



####################################################

# Nodes

####################################################


tb-set -node -os $eNodeB ENODEB


tb-set -node -os $EPCEnablers EPCENABLERS


tb-set -node -os $PDNGW PDNGW

set SGW [$ns node]

tb-set -node -os $SGW SGW

set portAlice [$ns node]

$portAlice add -desire SWITCHPORT 1

tb-fix -node $portAlice storage1a

set portBob [$ns node]

83

Bijlage I. Configuratiescript van minimale OpenEPC met externe Alice en Bob 84

$portBob add -desire SWITCHPORT 1

tb-fix -node $portBob storage1b

####################################################

# Lans

####################################################

set mgmt [$ns make -lan "$eNodeB $EPCEnablers $PDNGW $SGW" 1000Mb 0.0ms]


set net -b [$ns make -lan "$PDNGW $SGW" 1000000.0 kb 0.0ms]

set net -d [$ns make -lan "$eNodeB $SGW" 1000000.0 kb 0.0ms]

set net -lte [$ns make -lan "$eNodeB $portAlice $portBob" 1000000.0 kb 0.0ms]












# Set ip addresses on net -lte lan


tb -set -ip -lan portAlice net -lte "192.168.3.140"

tb -set -ip -lan portBob net -lte "192.168.3.141"




####################################################

# Start -up Scripts

####################################################




enodeb_swapin.sh"

Bijlage I. Configuratiescript van minimale OpenEPC met externe Alice en Bob 85


pdngw_swapin.sh"


sgw_swapin.sh"

####################################################

$ns rtproto Manual

$ns run

####################################################

Bijlage J

Configuratiescript voor handover

tussen eNodeB en NodeB

####################################################

#


#

####################################################



####################################################

# Nodes

####################################################









set SGW [$ns node]


set portnodeB [$ns node]

$portnodeB add -desire SWITCHPORT 1

tb-fix -node $portnodeB storage1a

86

Bijlage J. Configuratiescript voor handover tussen eNodeB en NodeB 87

set porteNodeB [$ns node]

$porteNodeB add -desire SWITCHPORT 1

tb-fix -node $porteNodeB storage1b

####################################################

# Lans

####################################################

set mgmt [$ns make -lan "$nodeB $eNodeB $EPCEnablers $PDNGW $SGW" 1000Mb 0.0ms]


set net -b [$ns make -lan "$PDNGW $SGW" 1000000.0 kb 0.0ms]

set net -d [$ns make -lan "$nodeB $eNodeB $SGW" 1000000.0 kb 0.0ms]

set net -lte [$ns make -lan "$eNodeB $porteNodeB" 1000000.0 kb 0.0ms]

set net -umts [$ns make -lan "$nodeB $portnodeB" 1000000.0 kb 0.0ms]















tb -set -ip -lan porteNodeB net -lte "192.168.3.140"

# Set ip addresses on net -umts lan

tb -set -ip -lan nodeB net -umts "192.168.3.28"

tb -set -ip -lan portnodeB net -umts "192.168.3.141"





####################################################

# Start -up Scripts

####################################################

Bijlage J. Configuratiescript voor handover tussen eNodeB en NodeB 88




nodeb_swapin.sh"


enodeb_swapin.sh"


pdngw_swapin.sh"


sgw_swapin.sh"

####################################################

$ns rtproto Manual

$ns run

####################################################

Bijlage K

Configuratiescript voor handover

tussen eNodeB en ePDG

####################################################

#


#

#

####################################################



####################################################

# Nodes

####################################################



set ePDG [$ns node]






set SGW [$ns node]


set porteNodeB [$ns node]

$porteNodeB add -desire SWITCHPORT 1

89

Bijlage K. Configuratiescript voor handover tussen eNodeB en ePDG 90

tb-fix -node $porteNodeB storage1a

set portePDG [$ns node]

$portePDG add -desire SWITCHPORT 1

tb-fix -node $portePDG storage1b

####################################################

# Lans

####################################################

set mgmt [$ns make -lan "$eNodeB $ePDG $EPCEnablers $PDNGW $SGW" 1000Mb 0.0ms]


set net -b [$ns make -lan "$PDNGW $SGW $ePDG" 1000000.0 kb 0.0ms]

set net -d [$ns make -lan "$eNodeB $SGW" 1000000.0 kb 0.0ms]

set net -lte [$ns make -lan "$eNodeB $porteNodeB" 1000000.0 kb 0.0ms]

set net -wifi [$ns make -lan "$ePDG $portePDG" 1000000.0 kb 0.0ms]
















tb -set -ip -lan porteNodeB net -lte "192.168.3.140"

# Set ip addresses on net -umts lan

tb -set -ip -lan ePDG net -wifi "192.168.3.21"

tb -set -ip -lan portePDG net -wifi "192.168.3.141"




####################################################

# Start -up Scripts

Bijlage K. Configuratiescript voor handover tussen eNodeB en ePDG 91

####################################################




enodeb_swapin.sh"


epdg_swapin.sh"


pdngw_swapin.sh"


sgw_swapin.sh"

####################################################

$ns rtproto Manual

$ns run

####################################################

Bijlage L

OpenEPC interfaces

L.1 UEAlice

mac_mgmt=‘/bin/netstat -ie | grep -B1 "192.168.254.100" | head -n1 | awk ’{

print $5}’‘mac_net_wifi =‘/bin/netstat -ie | grep -B1 "192.168.3.130" | head -n1 | awk ’{

print $5}’‘mac_net_wimax =‘/bin/netstat -ie | grep -B1 "192.168.3.129" | head -n1 | awk ’{

print $5}’‘mac_net_umts =‘/bin/netstat -ie | grep -B1 "192.168.3.131" | head -n1 | awk ’{

print $5}’‘mac_net_lte =‘/bin/netstat -ie | grep -B1 "192.168.3.132" | head -n1 | awk ’{

print $5}’‘

echo ’SUBSYSTEM =="net", ACTION =="add", DRIVERS =="?*", ATTR{address }=="’

$mac_mgmt ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*", NAME="

mgmt"’ > /etc/udev/rules.d/70-persistent -net.rules


$mac_net_wifi ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*",

NAME="an_wifi"’ >> /etc/udev/rules.d/70-persistent -net.rules


$mac_net_wimax ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*",

NAME="an_wimax"’ >> /etc/udev/rules.d/70-persistent -net.rules


$mac_net_umts ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*",

NAME="an_umts"’ >> /etc/udev/rules.d/70-persistent -net.rules


$mac_net_lte ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*", NAME

="an_lte"’ >> /etc/udev/rules.d/70- persistent -net.rules

L.2 ANGw

mac_mgmt=‘netstat -ie | grep -B1 "192.168.254.22" | head -n1 | awk ’{print $5}’‘

92

Bijlage L. OpenEPC interfaces 93

mac_net_b=‘netstat -ie | grep -B1 "192.168.2.22" | head -n1 | awk ’{print $5}’‘

mac_net_c=‘netstat -ie | grep -B1 "192.168.3.22" | head -n1 | awk ’{print $5}’‘





$mac_net_b ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*", NAME="

net_b"’ >> /etc/udev/rules.d/70- persistent -net.rules


$mac_net_c ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*", NAME="

net_c"’ >> /etc/udev/rules.d/70- persistent -net.rules

L.3 eNodeB



mac_net_d=‘netstat -ie | grep -B1 "192.168.4.90" | head -n1 | awk ’{print $5}’‘








$mac_net_d ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*", NAME="

net_d"’ >> /etc/udev/rules.d/70- persistent -net.rules

L.4 EPCEnablers


mac_net_a=‘netstat -ie | grep -B1 "192.168.1.30" | head -n1 | awk ’{print $5}’‘





$mac_net_a ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*", NAME="

net_a"’ >> /etc/udev/rules.d/70- persistent -net.rules


L.5 ePDG













L.6 PDNGW


mac_net_a=‘netstat -ie | grep -B1 "192.168.1.10" | head -n1 | awk ’{print $5}’‘






$mac_net_a ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*", NAME="

net_a"’ >> /etc/udev/rules.d/70- persistent -net.rules




L.7 nodeB














L.8 SGW













Bijlage M

OpenEPC DNS

while [ ‘dig @192 .168.254.40 boss.wall2.ilabt.iminds.be | grep ’ANSWER SECTION

’ | wc -l‘ != 1 ];

do

echo "dns not working"

sleep 2

done

echo "search wall2.ilabt.iminds.be" > /etc/resolv.conf

echo "nameserver 192.168.254.40" >> /etc/resolv.conf

echo "nameserver 10.2.32.1" >> /etc/resolv.conf

96

Bijlage N

OpenEPC routes naar testnetwerk

ip route add 157.193.214.0/24 via 10.2.47.254 dev ‘cat /var/emulab/boot/

controlif ‘


controlif ‘


controlif ‘


controlif ‘

ip route del default via 10.2.47.254 dev ‘cat /var/emulab/boot/controlif ‘

97

Bijlage O

Routeertabellen in OpenEPC

Deze routeertabellen zijn bekomen na het verbinden met de eNodeB.

O.1 UE

Na het verbinden met LTE in de Mobility Manager GUI krijgt de UE een default gateway

via de eNodeB.

janseeuw@uealice :~$ route -n

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

0.0.0.0 192.168.3.29 0.0.0.0 UG 10 0 0 an_lte

192.168.3.29 0.0.0.0 255.255.255.255 UH 0 0 0 an_lte

192.168.254.0 0.0.0.0 255.255.255.0 U 0 0 0 mgmt

O.2 eNodeB

De eNodeB gebruikt OpenEPC voor de routering. Met het commando screen -r krijg je

toegang tot de Wharf console. In deze console bekom je informatie over de routetabel met de

commando’s routing.print routes en routing.print ext.

1( 3215) 11:39:53 NOTI:console_loop ():465> eNodeB >routing.print_routes

1( 3215) 11:39:53 WARN:routing_print_routes ():68> IPv4 Source Routing:

from 192.168.3.100/32 teid 0 via ext 1 192.168.4.20 teid 86 BD3619

1( 3215) 11:39:53 WARN:routing_print_routes ():96> IPv4 Destination Routing:

to 192.168.3.100/32 teid 15 via ext 0 teid 0 <-- teid rule 15



1( 3215) 11:39:53 WARN:execute_external ():626>

98

Bijlage O. Routeertabellen in OpenEPC 99

1( 1909) 11:39:41 NOTI:console_loop ():465> eNodeB >routing.print_ext

1( 1909) 11:39:41 WARN:execute_external ():626> Routing Extensions

Extension [0] Module Name: [routing_raw] IPv4: [192.168.4.90] IPv6: [fc00

:1234:3::29]

Routing :[src dst] Protocol [0] Interface: [net_c]

Extension [1] Module Name: [routing_gtpu] IPv4: [192.168.4.90] IPv6: []

Routing :[src dst] Protocol [0] Interface: []

O.3 S-GW

Net zoals bij de eNodeB kunnen in de screen van de S-GW de routeertabellen getoond worden.

1( 1875) 12:49:25 NOTI:console_loop ():465> SGw MAG/BBERF Console >routing.

print_routes


from 192.168.3.100/32 teid 86 BD3619 via ext 1 fc00 :1234:2::10 teid 86

BD2291 <-- teid rule 86 BD3619


to 192.168.3.100/32 teid 86 BD3619 via ext 0 192.168.4.90 teid 15 <--

teid rule 86 BD3619

to default via ext 0 teid 0





1( 2098) 11:54:40 NOTI:console_loop ():465> SGw MAG/BBERF Console >routing.

print_ext


Extension [0] Module Name: [routing_gtpu] IPv4: [192.168.4.20] IPv6: [fc00

:1234:4::20]



:1234:2::20]


O.4 P-GW

Net zoals bij de eNodeB kunnen in de screen van de P-GW de routeertabellen getoond worden.

Uitgaande pakketten afkomstig van de UE worden wel gerouteerd met behulp van de Linux

routeertabel. Er moet dus een route beschikbaar zijn anders komt er een foutmelding.

1( 1899) 11:42:37 NOTI:console_loop ():465> PDNGw LMA/PCEF Console >routing.

print_routes

Bijlage O. Routeertabellen in OpenEPC 100


from 192.168.3.100/32 teid 86 BD2291 via ext 2 teid 0 <-- teid rule 86

BD2291


to 192.168.3.100/32 teid 86 BD2291 via ext 3 fc00 :1234:2::20 teid 86

BD3619 <-- teid rule 86 BD2291







Extension [1] Module Name: [routing_encap] IPv4: [192.168.2.10] IPv6: [fc00

:1234:2::10]


Extension [2] Module Name: [routing_raw] IPv4: [192.168.1.10] IPv6: [fc00

:1234:1::10]

Routing :[src dst] Protocol [0] Interface: [net_a]


:1234:2::10]


Bijlage P

Oplossing voor de HTTP proxy van

OpenEPC

rm -fr /etc/init.d/squid

rm -fr /usr/sbin/squid

ln -s /etc/init.d/squid3 /etc/init.d/squid

ln -s /usr/sbin/squid3 /usr/sbin/squid

rm -fr /etc/squid3/squid.conf

ln -s /opt/OpenEPC/etc/squid/squid.conf /etc/squid3/squid.conf

ln -s /etc/squid3 /etc/squid

ln -s /var/log/squid3 /var/log/squid

ln -s /var/spool/squid3 /var/spool/squid

Hierna start je squid3 opnieuw op.

janseeuw@epcenablers :~$ sudo restart squid3

Om zeker te zijn dat de HTTP proxy verbonden is met de Rx client om te communiceren

met de PCRF kan volgend script uitgevoerd worden.

janseeuw@epcenablers :~$ sudo /opt/OpenEPC/bin/squid_rx_logs.attach.sh

This is just a tail. Stop with Ctrl -C

Trying to connect to 127.0.0.1 port 10002

Wharf prompt is: [Squid Rx Client Console >]

Starting ...

...

101

Bijlage Q

Configuratie van LTE femtocell

Toegang tot de cell gebeurt via seriele console. Alle configuratieparamaters worden opgeslaan

in een SQLite databank. Het aanpassen van de parameters gebeurt door rechtstreeks de

databank up te daten met queries. Er zijn enkele scripts beschikbaar waardoor er zelf geen

queries moeten ingevoerd worden.

Een van deze scripts kan gebruikt worden om het IP adres in te stellen. Er wordt gekozen

voor het statisch adres 192.168.4.91.

~ # set_ip_config eth1

IP Address Configuration for eth1

method (d or s for dhcp or static): s

ip address: 192.168.4.91

default route (IP address or leave blank):

DNS domain (leave blank if none):

DNS server (leave blank if none , use if more than one):

subnet mask (leave blank if not required):

broadcast address (leave blank if not required):

Hierna moet het IP van de MME ingesteld worden. Pas wanneer de parameter AdminState

op 1 staat begint de cell, na heropstarten, met het uitsturen van zijn signaal.

~# sqlite

sqlite > update FAPServiceFAPControlLTEGateway set S1SigLinkServerList

=192.168.4.80;

sqlite > update FAPServiceFAPControlLTE set AdminState =1

De frequenties en frequencieband kunnen ingesteld worden met een script.

~# set_radio_params 20959 2950 7 10

~# set_auto_start 1

Meer informatie is te vinden in [30, 31, 32].

102

Bijlage R

Aanmaken van een gebruiker in

OpenEPC

Om als gebruiker geauthoriseerd te worden door OpenEPC moet deze eerst geregistreerd

worden. In de Web GUI kan je makkelijk een gebruiker registreren in OpenEPC (figuur R.1).

Er moeten naast het IMSI nummer nog een geheime sleutel en OP code worden ingegeven.

Figuur R.1: Web GUI

103

Bibliografie

[1] I. Grigorik, High Performance Browser Networking. O’Reilly Media, 2013.

[2] F. Firmin, “3GPP, The Evolved Packet Core.” [Online]. Available: http:

//www.3gpp.org/technologies/keywords-acronyms/100-the-evolved-packet-core

[3] M. Olsson, EPC and 4G packet networks: driving the mobile broadband revolution,

2nd ed. Oxford: Academic Press, 2013.

[4] J. T. J. Penttinen, The LTE/SAE deployment handbook, 1st ed., Chichester, West Sussex

; Hoboken, NJ, 2012.

[5] S. Mudigonda, “VoLTE or VoIP over LTE – who is the ul-

timate winner?” [Online]. Available: http://blog.imgtec.com/hellosoft/

volte-or-voip-over-lte-who-is-the-ultimate-winner

[6] “4G Americas.” [Online]. Available: http://www.4gamericas.org/index.cfm?fuseaction=

page&pageid=1143

[7] A. Brydon, “Still waiting for Voice over LTE.” [Online]. Available: http:

//www.unwiredinsight.com/2013/waiting-for-volte

[8] F. FOKUS, “OpenEPC, Open Evolved Packet Core.” [Online]. Available: http:

//www.openepc.net

[9] “OpenEPC Rel. 4 Installation and Use Guide.” [Online]. Available: https:

//extsvnsrv.fokus.fraunhofer.de/cc/ngni/iMinds/wiki/Installation Guide Rel4

[10] “OpenEPC Core Network Mobility Management presentation.”

[11] “OpenEPC Rel. 4 Showcasing.” [Online]. Available: https://extsvnsrv.fokus.fraunhofer.

de/cc/ngni/iMinds/wiki/Installation Guide Rel4 Showcasing

[12] “OpenEPC Rel. 4 Installation and Use Guide for EPC Enablers.”

[Online]. Available: https://extsvnsrv.fokus.fraunhofer.de/cc/ngni/iMinds/wiki/

Installation Guide Enablers Rel4

104

http://www.3gpp.org/technologies/keywords-acronyms/100-the-evolved-packet-core

http://www.3gpp.org/technologies/keywords-acronyms/100-the-evolved-packet-core

http://blog.imgtec.com/hellosoft/volte-or-voip-over-lte-who-is-the-ultimate-winner

http://blog.imgtec.com/hellosoft/volte-or-voip-over-lte-who-is-the-ultimate-winner

http://www.4gamericas.org/index.cfm?fuseaction=page&pageid=1143

http://www.4gamericas.org/index.cfm?fuseaction=page&pageid=1143

http://www.unwiredinsight.com/2013/waiting-for-volte

http://www.unwiredinsight.com/2013/waiting-for-volte

http://www.openepc.net

http://www.openepc.net

https://extsvnsrv.fokus.fraunhofer.de/cc/ngni/iMinds/wiki/Installation_Guide_Rel4

https://extsvnsrv.fokus.fraunhofer.de/cc/ngni/iMinds/wiki/Installation_Guide_Rel4

https://extsvnsrv.fokus.fraunhofer.de/cc/ngni/iMinds/wiki/Installation_Guide_Rel4_Showcasing

https://extsvnsrv.fokus.fraunhofer.de/cc/ngni/iMinds/wiki/Installation_Guide_Rel4_Showcasing

https://extsvnsrv.fokus.fraunhofer.de/cc/ngni/iMinds/wiki/Installation_Guide_Enablers_Rel4

https://extsvnsrv.fokus.fraunhofer.de/cc/ngni/iMinds/wiki/Installation_Guide_Enablers_Rel4

Bibliografie 105

[13] “The Open Source IMS Core Project.” [Online]. Available: /http://www.openimscore.

org

[14] “OpenEPC Policy and Charging Control presentation.”

[15] “OpenEPC Introduction presentation.”

[16] “OpenEPC Rel. 4 Installation and Use Guide for Policy and Charging Con-

trol.” [Online]. Available: https://extsvnsrv.fokus.fraunhofer.de/cc/ngni/iMinds/wiki/

Installation Guide PCC Rel4

[17] “3GPP System Architecture Evolution Specification.” [Online]. Available: http:

//www.3gpp.org/DynaReport/FeatureOrStudyItemFile-320005.htm

[18] 3GPP, “IP Multimedia Subsystem (IMS); Stage 2,” 3rd Generation Partnership Project

(3GPP), TS 23.228. [Online]. Available: http://www.3gpp.org/ftp/Specs/html-info/

23228.htm

[19] ——, “IMS Multimedia telephony service and supplementary services; Stage

3,” 3rd Generation Partnership Project (3GPP), TS 24.173. [Online]. Available:

http://www.3gpp.org/ftp/Specs/html-info/24173.htm

[20] ——, “3GPP EPS Sv interface (MME to MSC) for SRVCC,” 3rd Generation

Partnership Project (3GPP), TS 29.280. [Online]. Available: http://www.3gpp.org/ftp/

Specs/html-info/29280.htm

[21] ——, “General Packet Radio Service (GPRS) enhancements for Evolved Universal

Terrestrial Radio Access Network (E-UTRAN) access,” 3rd Generation Partnership

Project (3GPP), TS 23.401. [Online]. Available: http://www.3gpp.org/ftp/Specs/

html-info/23401.htm

[22] ——, “Architecture enhancements for non-3GPP accesses,” 3rd Generation Partnership

Project (3GPP), TS 23.402. [Online]. Available: http://www.3gpp.org/ftp/Specs/

html-info/23402.htm

[23] “Virtual Wall 2.” [Online]. Available: https://www.wall2.ilabt.iminds.be

[24] “iLab.t Virtual Wall.” [Online]. Available: http://www.ibcn.intec.ugent.be/content/

ilabt-virtual-wall

[25] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins, and M. Carney, “Dynamic Host

Configuration Protocol for IPv6 (DHCPv6),” Internet Engineering Task Force, RFC

3315. [Online]. Available: http://www.rfc-editor.org/rfc/rfc3315.txt

[26] “OpenEPC Rel. 4 Client Mobility Enabler.” [Online]. Available: https://extsvnsrv.

fokus.fraunhofer.de/cc/ngni/iMinds/wiki/Installation Guide Client Rel4

/http://www.openimscore.org

/http://www.openimscore.org

https://extsvnsrv.fokus.fraunhofer.de/cc/ngni/iMinds/wiki/Installation_Guide_PCC_Rel4

https://extsvnsrv.fokus.fraunhofer.de/cc/ngni/iMinds/wiki/Installation_Guide_PCC_Rel4

http://www.3gpp.org/DynaReport/FeatureOrStudyItemFile-320005.htm

http://www.3gpp.org/DynaReport/FeatureOrStudyItemFile-320005.htm










https://www.wall2.ilabt.iminds.be

http://www.ibcn.intec.ugent.be/content/ilabt-virtual-wall

http://www.ibcn.intec.ugent.be/content/ilabt-virtual-wall

http://www.rfc-editor.org/rfc/rfc3315.txt

https://extsvnsrv.fokus.fraunhofer.de/cc/ngni/iMinds/wiki/Installation_Guide_Client_Rel4

https://extsvnsrv.fokus.fraunhofer.de/cc/ngni/iMinds/wiki/Installation_Guide_Client_Rel4

Bibliografie 106

[27] A. Patel, K. Leung, M. Khalil, H. Akhtar, and K. Chowdhury, “Mobile Node Identifier

Option for Mobile IPv6 (MIPv6),” Internet Engineering Task Force, RFC 4283.

[Online]. Available: http://www.rfc-editor.org/rfc/rfc4283.txt

[28] “MONSTER.” [Online]. Available: http://www.monster-the-client.org

[29] 3GPP, “Handover requirements between UTRAN and GERAN or other radio

systems,” 3rd Generation Partnership Project (3GPP), TS 22.129. [Online]. Available:


[30] “OpenEPC 4G Setup and Configuration presentation.”

[31] Quick Start Manual for LTE, 10th ed., ip.access Ltd, 2014.

[32] LTE AP Release Note for 0.7.14 LTE 51.0, 10th ed., ip.access Ltd, 2014.

[33] M. Olsson, Ed., SAE and the evolved packet core: driving the mobile broadband revolution.

Amsterdam : Boston: Academic Press, 2009.

[34] 3GPP, “Vocabulary for 3GPP Specifications,” 3rd Generation Partnership Project

(3GPP), TR 21.905. [Online]. Available: http://www.3gpp.org/ftp/Specs/html-info/

21905.htm

[35] 3GPP, “Network architecture,” 3rd Generation Partnership Project (3GPP), TS 23.002.

[Online]. Available: http://www.3gpp.org/ftp/Specs/html-info/23002.htm

[36] 3GPP, “Numbering, addressing and identification,” 3rd Generation Partnership Project


23003.htm

[37] 3GPP, “Service requirements for the Internet Protocol (IP) multimedia core network

subsystem (IMS); Stage 1,” 3rd Generation Partnership Project (3GPP), TS 22.228.

[Online]. Available: http://www.3gpp.org/ftp/Specs/html-info/22228.htm

[38] 3GPP, “Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage

3,” 3rd Generation Partnership Project (3GPP), TS 24.301. [Online]. Available:


[39] 3GPP, “Policy and charging control architecture,” 3rd Generation Partnership Project


23203.htm

[40] 3GPP, “Policy and charging control over Gx reference point,” 3rd Generation




http://www.monster-the-client.org













Bibliografie 107

[41] 3GPP, “Policy and charging control signalling flows and Quality of Service (QoS)

parameter mapping,” 3rd Generation Partnership Project (3GPP), TS 29.213. [Online].

Available: http://www.3gpp.org/ftp/Specs/html-info/29213.htm

[42] 3GPP, “Policy and charging control over Rx reference point,” 3rd Generation



[43] 3GPP, “Policy and Charging Control (PCC) over S9 reference point,” 3rd

Generation Partnership Project (3GPP), TS 29.215. [Online]. Available: http:

//www.3gpp.org/ftp/Specs/html-info/29215.htm

[44] B. Aboba, M. Beadles, J. Arkko, and P. Eronen, “The Network Access

Identifier,” Internet Engineering Task Force, RFC 4282. [Online]. Available:


[45] “Emulab Documentation.” [Online]. Available: https://wiki.emulab.net/Emulab/wiki

[46] “OpenEPC Client Mobility Support presentation.”

[47] “OpenEPC Developing presentation.”

[48] “OpenEPC Subscription Management and AAA presentation.”

[49] “OpenEPC Wharf presentation.”

[50] “Using OpenEPC presentation.”







https://wiki.emulab.net/Emulab/wiki

Optimalisatie van voice calls in 4G...

Documents

Transcript of Optimalisatie van voice calls in 4G...