Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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)
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
Hoofdstuk 1. Inleiding 3
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]
Hoofdstuk 1. Inleiding 4
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
Hoofdstuk 1. Inleiding 5
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.
Hoofdstuk 2. EPS architectuur 8
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.
Hoofdstuk 2. EPS architectuur 9
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.
Hoofdstuk 2. EPS architectuur 10
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.
Hoofdstuk 2. EPS architectuur 11
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
Hoofdstuk 3. Spraakgesprekken in 4G netwerken 14
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.
Hoofdstuk 3. Spraakgesprekken in 4G netwerken 15
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).
Hoofdstuk 3. Spraakgesprekken in 4G netwerken 16
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-
Hoofdstuk 4. Introductie tot OpenEPC 19
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-
Hoofdstuk 4. Introductie tot OpenEPC 20
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.
Hoofdstuk 4. Introductie tot OpenEPC 21
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
Hoofdstuk 4. Introductie tot OpenEPC 22
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
Hoofdstuk 4. Introductie tot OpenEPC 23
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
Hoofdstuk 4. Introductie tot OpenEPC 24
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).
Hoofdstuk 5. Ontplooien en installeren van OpenEPC op de Virtual Wall 27
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.
Hoofdstuk 5. Ontplooien en installeren van OpenEPC op de Virtual Wall 28
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
Hoofdstuk 5. Ontplooien en installeren van OpenEPC op de Virtual Wall 29
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.
Hoofdstuk 5. Ontplooien en installeren van OpenEPC op de Virtual Wall 30
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
Hoofdstuk 5. Ontplooien en installeren van OpenEPC op de Virtual Wall 31
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.
Hoofdstuk 5. Ontplooien en installeren van OpenEPC op de Virtual Wall 32
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.
Hoofdstuk 5. Ontplooien en installeren van OpenEPC op de Virtual Wall 33
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.
Hoofdstuk 5. Ontplooien en installeren van OpenEPC op de Virtual Wall 34
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.
Hoofdstuk 5. Ontplooien en installeren van OpenEPC op de Virtual Wall 35
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:
Hoofdstuk 6. IP Connectiviteit in OpenEPC 38
• 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.
Hoofdstuk 6. IP Connectiviteit in OpenEPC 39
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 >
]]>
Hoofdstuk 6. IP Connectiviteit in OpenEPC 40
</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
Hoofdstuk 6. IP Connectiviteit in OpenEPC 41
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.
Hoofdstuk 6. IP Connectiviteit in OpenEPC 42
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.
Hoofdstuk 6. IP Connectiviteit in OpenEPC 43
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
Hoofdstuk 6. IP Connectiviteit in OpenEPC 44
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
Hoofdstuk 6. IP Connectiviteit in OpenEPC 45
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.
Hoofdstuk 6. IP Connectiviteit in OpenEPC 46
Figuur 6.14: LMA binding lijst
Figuur 6.15: MAG binding lijst
Hoofdstuk 6. IP Connectiviteit in OpenEPC 47
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.
Hoofdstuk 6. IP Connectiviteit in OpenEPC 48
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
Hoofdstuk 6. IP Connectiviteit in OpenEPC 49
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.
Hoofdstuk 7. Realiseren van spraakgesprekken met OpenEPC 52
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).
Hoofdstuk 7. Realiseren van spraakgesprekken met OpenEPC 53
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.
Hoofdstuk 7. Realiseren van spraakgesprekken met OpenEPC 54
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.
Hoofdstuk 7. Realiseren van spraakgesprekken met OpenEPC 55
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
Hoofdstuk 7. Realiseren van spraakgesprekken met OpenEPC 56
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.
Hoofdstuk 8. Policies en QoS in OpenEPC 59
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
Hoofdstuk 8. Policies en QoS in OpenEPC 60
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.
Hoofdstuk 8. Policies en QoS in OpenEPC 61
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).
Hoofdstuk 8. Policies en QoS in OpenEPC 62
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[
<!--
LMA Parameters
- ipv4 - IPv4 address to identify this LMA to the MAGs
- ipv6 - IPv6 address to identify this LMA to the MAGs
- hash_size - hash size for the binding cache hash table. default is
32 (optional)
- seamless - use seamless handovers or not (1-yes , 0-no). default is
1 (optional)
-->
<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
####################################################
#
# 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
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 -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 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]
# 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 -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"
Bijlage H. Configuratiescript van OpenEPC met virtuele Alice en Bob 81
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"
# 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"
tb -set -node -startcmd $UEBob "sudo bash /proj/OpenEPC/ibcn_scripting/swapin/
uebob_swapin.sh"
Bijlage H. Configuratiescript van OpenEPC met virtuele Alice en Bob 82
####################################################
$ns rtproto Manual
$ns run
####################################################
Bijlage I
Configuratiescript van minimale
OpenEPC met externe Alice en Bob
####################################################
#
# OpenEPC Wall2 NS File
#
####################################################
set ns [new Simulator]
source tb_compat.tcl
####################################################
# Nodes
####################################################
set eNodeB [$ns node]
tb-set -node -os $eNodeB ENODEB
set EPCEnablers [$ns node]
tb-set -node -os $EPCEnablers EPCENABLERS
set PDNGW [$ns node]
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 -a [$ns make -lan "$EPCEnablers $PDNGW" 1000000.0 kb 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 mgmt interface
tb -set -ip -lan eNodeB mgmt "192.168.254.90"
tb -set -ip -lan EPCEnablers mgmt "192.168.254.30"
tb -set -ip -lan PDNGW mgmt "192.168.254.10"
tb -set -ip -lan SGW mgmt "192.168.254.20"
# 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"
# Set ip addresses on net -lte lan
tb -set -ip -lan eNodeB net -lte "192.168.3.29"
tb -set -ip -lan portAlice net -lte "192.168.3.140"
tb -set -ip -lan portBob net -lte "192.168.3.141"
# Set ip addresses on net -d lan
tb -set -ip -lan eNodeB net -d "192.168.4.90"
tb -set -ip -lan eNodeB net -d "192.168.4.20"
####################################################
# Start -up Scripts
####################################################
tb -set -node -startcmd $EPCEnablers "sudo bash /proj/OpenEPC/ibcn_scripting/
swapin/epcenablers_swapin.sh"
tb -set -node -startcmd $eNodeB "sudo bash /proj/OpenEPC/ibcn_scripting/swapin/
enodeb_swapin.sh"
Bijlage I. Configuratiescript van minimale OpenEPC met externe Alice en Bob 85
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"
####################################################
$ns rtproto Manual
$ns run
####################################################
Bijlage J
Configuratiescript voor handover
tussen eNodeB en NodeB
####################################################
#
# OpenEPC Wall2 NS File
#
####################################################
set ns [new Simulator]
source tb_compat.tcl
####################################################
# Nodes
####################################################
set nodeB [$ns node]
tb -set -node -os $nodeB NODEB
set eNodeB [$ns node]
tb-set -node -os $eNodeB ENODEB
set EPCEnablers [$ns node]
tb-set -node -os $EPCEnablers EPCENABLERS
set PDNGW [$ns node]
tb-set -node -os $PDNGW PDNGW
set SGW [$ns node]
tb-set -node -os $SGW SGW
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 -a [$ns make -lan "$EPCEnablers $PDNGW" 1000000.0 kb 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]
# Set ip addresses on mgmt interface
tb -set -ip -lan eNodeB mgmt "192.168.254.90"
tb -set -ip -lan nodeB mgmt "192.168.254.110"
tb -set -ip -lan EPCEnablers mgmt "192.168.254.30"
tb -set -ip -lan PDNGW mgmt "192.168.254.10"
tb -set -ip -lan SGW mgmt "192.168.254.20"
# 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"
# Set ip addresses on net -lte lan
tb -set -ip -lan eNodeB net -lte "192.168.3.29"
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"
# Set ip addresses on net -d lan
tb -set -ip -lan eNodeB net -d "192.168.4.90"
tb -set -ip -lan nodeB net -d "192.168.4.110"
tb -set -ip -lan SGW net -d "192.168.4.20"
####################################################
# Start -up Scripts
####################################################
Bijlage J. Configuratiescript voor handover tussen eNodeB en NodeB 88
tb -set -node -startcmd $EPCEnablers "sudo bash /proj/OpenEPC/ibcn_scripting/
swapin/epcenablers_swapin.sh"
tb -set -node -startcmd $nodeB "sudo bash /proj/OpenEPC/ibcn_scripting/swapin/
nodeb_swapin.sh"
tb -set -node -startcmd $eNodeB "sudo bash /proj/OpenEPC/ibcn_scripting/swapin/
enodeb_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"
####################################################
$ns rtproto Manual
$ns run
####################################################
Bijlage K
Configuratiescript voor handover
tussen eNodeB en ePDG
####################################################
#
# OpenEPC Wall2 NS File
#
#
####################################################
set ns [new Simulator]
source tb_compat.tcl
####################################################
# Nodes
####################################################
set eNodeB [$ns node]
tb-set -node -os $eNodeB ENODEB
set ePDG [$ns node]
tb -set -node -os $ePDG EPDG
set EPCEnablers [$ns node]
tb-set -node -os $EPCEnablers EPCENABLERS
set PDNGW [$ns node]
tb-set -node -os $PDNGW PDNGW
set SGW [$ns node]
tb-set -node -os $SGW SGW
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 -a [$ns make -lan "$EPCEnablers $PDNGW" 1000000.0 kb 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]
# Set ip addresses on mgmt interface
tb -set -ip -lan eNodeB mgmt "192.168.254.90"
tb -set -ip -lan ePDG mgmt "192.168.254.21"
tb -set -ip -lan EPCEnablers mgmt "192.168.254.30"
tb -set -ip -lan PDNGW mgmt "192.168.254.10"
tb -set -ip -lan SGW mgmt "192.168.254.20"
# 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"
# Set ip addresses on net -lte lan
tb -set -ip -lan eNodeB net -lte "192.168.3.29"
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"
# Set ip addresses on net -d lan
tb -set -ip -lan eNodeB net -d "192.168.4.90"
tb -set -ip -lan SGW net -d "192.168.4.20"
####################################################
# Start -up Scripts
Bijlage K. Configuratiescript voor handover tussen eNodeB en ePDG 91
####################################################
tb -set -node -startcmd $EPCEnablers "sudo bash /proj/OpenEPC/ibcn_scripting/
swapin/epcenablers_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 $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"
####################################################
$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
echo ’SUBSYSTEM =="net", ACTION =="add", DRIVERS =="?*", ATTR{address }=="’
$mac_net_wifi ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*",
NAME="an_wifi"’ >> /etc/udev/rules.d/70-persistent -net.rules
echo ’SUBSYSTEM =="net", ACTION =="add", DRIVERS =="?*", ATTR{address }=="’
$mac_net_wimax ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*",
NAME="an_wimax"’ >> /etc/udev/rules.d/70-persistent -net.rules
echo ’SUBSYSTEM =="net", ACTION =="add", DRIVERS =="?*", ATTR{address }=="’
$mac_net_umts ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*",
NAME="an_umts"’ >> /etc/udev/rules.d/70-persistent -net.rules
echo ’SUBSYSTEM =="net", ACTION =="add", DRIVERS =="?*", ATTR{address }=="’
$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}’‘
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
echo ’SUBSYSTEM =="net", ACTION =="add", DRIVERS =="?*", ATTR{address }=="’
$mac_net_b ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*", NAME="
net_b"’ >> /etc/udev/rules.d/70- persistent -net.rules
echo ’SUBSYSTEM =="net", ACTION =="add", DRIVERS =="?*", ATTR{address }=="’
$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_mgmt=‘netstat -ie | grep -B1 "192.168.254.90" | head -n1 | awk ’{print $5}’‘
mac_net_c=‘netstat -ie | grep -B1 "192.168.3.29" | head -n1 | awk ’{print $5}’‘
mac_net_d=‘netstat -ie | grep -B1 "192.168.4.90" | 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
echo ’SUBSYSTEM =="net", ACTION =="add", DRIVERS =="?*", ATTR{address }=="’
$mac_net_c ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*", NAME="
net_c"’ >> /etc/udev/rules.d/70- persistent -net.rules
echo ’SUBSYSTEM =="net", ACTION =="add", DRIVERS =="?*", ATTR{address }=="’
$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_mgmt=‘netstat -ie | grep -B1 "192.168.254.30" | head -n1 | awk ’{print $5}’‘
mac_net_a=‘netstat -ie | grep -B1 "192.168.1.30" | 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
echo ’SUBSYSTEM =="net", ACTION =="add", DRIVERS =="?*", ATTR{address }=="’
$mac_net_a ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*", NAME="
net_a"’ >> /etc/udev/rules.d/70- persistent -net.rules
Bijlage L. OpenEPC interfaces 94
L.5 ePDG
mac_mgmt=‘netstat -ie | grep -B1 "192.168.254.21" | head -n1 | awk ’{print $5}’‘
mac_net_b=‘netstat -ie | grep -B1 "192.168.2.21" | head -n1 | awk ’{print $5}’‘
mac_net_c=‘netstat -ie | grep -B1 "192.168.3.21" | 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
echo ’SUBSYSTEM =="net", ACTION =="add", DRIVERS =="?*", ATTR{address }=="’
$mac_net_b ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*", NAME="
net_b"’ >> /etc/udev/rules.d/70- persistent -net.rules
echo ’SUBSYSTEM =="net", ACTION =="add", DRIVERS =="?*", ATTR{address }=="’
$mac_net_c ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*", NAME="
net_c"’ >> /etc/udev/rules.d/70- persistent -net.rules
L.6 PDNGW
mac_mgmt=‘netstat -ie | grep -B1 "192.168.254.10" | head -n1 | awk ’{print $5}’‘
mac_net_a=‘netstat -ie | grep -B1 "192.168.1.10" | head -n1 | awk ’{print $5}’‘
mac_net_b=‘netstat -ie | grep -B1 "192.168.2.10" | 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
echo ’SUBSYSTEM =="net", ACTION =="add", DRIVERS =="?*", ATTR{address }=="’
$mac_net_a ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*", NAME="
net_a"’ >> /etc/udev/rules.d/70- persistent -net.rules
echo ’SUBSYSTEM =="net", ACTION =="add", DRIVERS =="?*", ATTR{address }=="’
$mac_net_b ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*", NAME="
net_b"’ >> /etc/udev/rules.d/70- persistent -net.rules
L.7 nodeB
mac_mgmt=‘netstat -ie | grep -B1 "192.168.254.110" | head -n1 | awk ’{print $5}’‘
mac_net_c=‘netstat -ie | grep -B1 "192.168.3.28" | head -n1 | awk ’{print $5}’‘
mac_net_d=‘netstat -ie | grep -B1 "192.168.4.110" | head -n1 | awk ’{print $5}’‘
Bijlage L. OpenEPC interfaces 95
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
echo ’SUBSYSTEM =="net", ACTION =="add", DRIVERS =="?*", ATTR{address }=="’
$mac_net_c ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*", NAME="
net_c"’ >> /etc/udev/rules.d/70- persistent -net.rules
echo ’SUBSYSTEM =="net", ACTION =="add", DRIVERS =="?*", ATTR{address }=="’
$mac_net_d ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*", NAME="
net_d"’ >> /etc/udev/rules.d/70- persistent -net.rules
L.8 SGW
mac_mgmt=‘netstat -ie | grep -B1 "192.168.254.20" | head -n1 | awk ’{print $5}’‘
mac_net_b=‘netstat -ie | grep -B1 "192.168.2.20" | head -n1 | awk ’{print $5}’‘
mac_net_d=‘netstat -ie | grep -B1 "192.168.4.20" | 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
echo ’SUBSYSTEM =="net", ACTION =="add", DRIVERS =="?*", ATTR{address }=="’
$mac_net_b ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*", NAME="
net_b"’ >> /etc/udev/rules.d/70- persistent -net.rules
echo ’SUBSYSTEM =="net", ACTION =="add", DRIVERS =="?*", ATTR{address }=="’
$mac_net_d ’", ATTR{dev_id }=="0x0", ATTR{type }=="1", KERNEL =="eth*", NAME="
net_d"’ >> /etc/udev/rules.d/70- persistent -net.rules
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 ‘
ip route add 157.193.135.0/24 via 10.2.47.254 dev ‘cat /var/emulab/boot/
controlif ‘
ip route add 157.193.215.0/24 via 10.2.47.254 dev ‘cat /var/emulab/boot/
controlif ‘
ip route add 192.168.126.0/24 via 10.2.47.254 dev ‘cat /var/emulab/boot/
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:routing_print_routes ():123> IPv6 Source Routing:
1( 3215) 11:39:53 WARN:routing_print_routes ():151> IPv6 Destination Routing:
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
1( 1875) 12:49:26 WARN:routing_print_routes ():68> IPv4 Source Routing:
from 192.168.3.100/32 teid 86 BD3619 via ext 1 fc00 :1234:2::10 teid 86
BD2291 <-- teid rule 86 BD3619
1( 1875) 12:49:26 WARN:routing_print_routes ():96> IPv4 Destination Routing:
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( 1875) 12:49:26 WARN:routing_print_routes ():123> IPv6 Source Routing:
1( 1875) 12:49:26 WARN:routing_print_routes ():151> IPv6 Destination Routing:
to default via ext 0 teid 0
1( 1875) 12:49:26 WARN:execute_external ():626>
1( 2098) 11:54:40 NOTI:console_loop ():465> SGw MAG/BBERF Console >routing.
print_ext
1( 2098) 11:54:40 WARN:execute_external ():626> Routing Extensions
Extension [0] Module Name: [routing_gtpu] IPv4: [192.168.4.20] IPv6: [fc00
:1234:4::20]
Routing :[src dst] Protocol [0] Interface: []
Extension [1] Module Name: [routing_gtpu] IPv4: [192.168.2.20] IPv6: [fc00
:1234:2::20]
Routing :[src dst] Protocol [0] Interface: []
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
1( 1899) 11:42:38 WARN:routing_print_routes ():68> IPv4 Source Routing:
from 192.168.3.100/32 teid 86 BD2291 via ext 2 teid 0 <-- teid rule 86
BD2291
1( 1899) 11:42:38 WARN:routing_print_routes ():96> IPv4 Destination Routing:
to 192.168.3.100/32 teid 86 BD2291 via ext 3 fc00 :1234:2::20 teid 86
BD3619 <-- teid rule 86 BD2291
to default via ext 2 teid 0
1( 1899) 11:42:38 WARN:routing_print_routes ():123> IPv6 Source Routing:
1( 1899) 11:42:38 WARN:routing_print_routes ():151> IPv6 Destination Routing:
to default via ext 2 teid 0
1( 1899) 11:42:38 WARN:execute_external ():626>
1( 1979) 12:08:06 WARN:execute_external ():626> Routing Extensions
Extension [1] Module Name: [routing_encap] IPv4: [192.168.2.10] IPv6: [fc00
:1234:2::10]
Routing :[src dst] Protocol [47] Interface: []
Extension [2] Module Name: [routing_raw] IPv4: [192.168.1.10] IPv6: [fc00
:1234:1::10]
Routing :[src dst] Protocol [0] Interface: [net_a]
Extension [3] Module Name: [routing_gtpu] IPv4: [192.168.2.10] IPv6: [fc00
:1234:2::10]
Routing :[src dst] Protocol [0] Interface: []
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
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
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:
http://www.3gpp.org/ftp/Specs/html-info/22129.htm
[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
(3GPP), TS 23.003. [Online]. Available: http://www.3gpp.org/ftp/Specs/html-info/
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:
http://www.3gpp.org/ftp/Specs/html-info/24301.htm
[39] 3GPP, “Policy and charging control architecture,” 3rd Generation Partnership Project
(3GPP), TS 23.203. [Online]. Available: http://www.3gpp.org/ftp/Specs/html-info/
23203.htm
[40] 3GPP, “Policy and charging control over Gx reference point,” 3rd Generation
Partnership Project (3GPP), TS 29.212. [Online]. Available: http://www.3gpp.org/ftp/
Specs/html-info/29212.htm
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
Partnership Project (3GPP), TS 29.214. [Online]. Available: http://www.3gpp.org/ftp/
Specs/html-info/29214.htm
[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:
http://www.rfc-editor.org/rfc/rfc4282.txt
[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.”