Studie van voice over IP in 4G netwerken met behulp van OpenEPC

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

Masterproef voorgedragen tot het behalen van het diploma van Master in de industriële wetenschappen: informatica

Jonas ANSEEUW Promotoren: dr. ir. Pieter SIMOENS prof. dr. ir. Ingrid MOERMAN dr. ir. Daan PAREIT Begeleiders: Pieter WILLEMEN Dries NAUDTS

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

Masterproef voorgedragen tot het behalen van het diploma van Master in de industriële wetenschappen: informatica

Jonas ANSEEUW Promotoren: dr. ir. Pieter SIMOENS prof. dr. ir. Ingrid MOERMAN dr. ir. Daan PAREIT Begeleiders: Pieter WILLEMEN Dries NAUDTS

Woord vooraf Als laatstejaarsstudent master in de industriële 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 België 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 mogelijkheden 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 geëmuleerde als fysieke LTE devices.

v

Inhoudsopgave Woord vooraf

iv

Abstract

v

Lijst van figuren

x

Lijst van afkortingen

xii

1 Inleiding 1.1 Structuur van mobiele netwerken . . . 1.2 Twee soorten services: data en spraak 1.3 Van een circuit- naar pakketgeschakeld 1.4 Doelstelling van de masterproef . . . . 1.5 Structuur van de masterproef . . . . .

. . . . .

1 1 2 3 4 4

. . . . . . . . . . .

6 6 7 9 9 9 9 9 10 10 10 10

3 Spraakgesprekken in 4G netwerken 3.1 Over The Top (OTT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Circuit Switched Fall Back (CSFB) . . . . . . . . . . . . . . . . . . . . . . . .

12 12 13

. . . . . . . . . . . . . . . . kernnetwerk . . . . . . . . . . . . . . . .

2 EPS architectuur 2.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 De belangrijkste elementen in een LTE netwerk . . . 2.2.1 User Equipment (UE) . . . . . . . . . . . . . 2.2.2 eNodeB (eNB) . . . . . . . . . . . . . . . . . 2.2.3 Serving GW (S-GW) . . . . . . . . . . . . . . 2.2.4 PDN GW (P-GW) . . . . . . . . . . . . . . . 2.2.5 Mobility Management Entity (MME) . . . . 2.2.6 Home Subscriber Server (HSS) . . . . . . . . 2.2.7 Policy and Charging Rules Function (PCRF) 2.3 Samenwerking tussen LTE en WCDMA/HSPA . . . 2.4 Samenwerking tussen LTE en WiFi . . . . . . . . . .

vi

. . . . .

. . . . . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . .

. . . . . . . . . . .

Inhoudsopgave 3.3 3.4

vii

Voice-over-LTE (VoLTE) en IP Multimedia Subsystem (IMS) . . . . . . . . . 3.3.1 Single-Radio Voice Call Continuity (SRVCC) . . . . . . . . . . . . . . Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Introductie tot OpenEPC 4.1 Wat is OpenEPC? . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 OpenEPC architectuur en mogelijkheden . . . . . . 4.1.2 De verschillende componenten van OpenEPC . . . . 4.2 Ontplooien van de OpenEPC software . . . . . . . . . . . . 4.2.1 Het gebruik van OpenEPC met Virtuele Machines in 4.2.2 Installatie van OpenEPC op fysieke systemen . . . .

. . . . . . . . . . . . . . . . . . . . . . . . VMWare . . . . . .

5 Ontplooien en installeren van OpenEPC op de Virtual Wall 5.1 Virtual Wall opstellingen . . . . . . . . . . . . . . . . . . . . . 5.1.1 Standaard opstelling op de Virtual Wall . . . . . . . . . 5.1.2 Toevoegen van een UE . . . . . . . . . . . . . . . . . . . 5.1.3 Het koppelen van externe UE’s aan de Virtual Wall . . 5.1.4 Handover tussen E-UTRAN en UTRAN . . . . . . . . . 5.1.5 Handover tussen E-UTRAN en WiFi . . . . . . . . . . . 5.1.6 Fysiek WiFi access point en LTE femtocell . . . . . . . 5.2 Configuratie van de systemen . . . . . . . . . . . . . . . . . . . 5.2.1 TCP Segmentation Offload (TSO) . . . . . . . . . . . . 5.2.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.3 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.4 NAT op EPC-Enablers . . . . . . . . . . . . . . . . . . . 5.2.5 IP-forwarding . . . . . . . . . . . . . . . . . . . . . . . . 5.2.6 Routes naar IBCN/test netwerk . . . . . . . . . . . . . 5.2.7 rc.local . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 IP Connectiviteit in OpenEPC 6.1 Verbinding maken met een access netwerk . . . . . 6.1.1 Mobility Manager . . . . . . . . . . . . . . 6.1.2 Verbinden zonder Mobility Manager . . . . 6.1.3 Web GUI . . . . . . . . . . . . . . . . . . . 6.2 Routering . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 GTP tunnel tussen eNB en S-GW en tussen 6.2.2 GRE tunnel tussen ePDG en P-GW . . . . 6.3 Het SGi reference point . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . S-GW . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . en P-GW . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . . . . .

. . . . . . . .

13 14 15

. . . . . .

17 17 19 20 20 23 23

. . . . . . . . . . . . . . .

25 25 26 27 29 30 31 31 32 33 33 34 34 34 34 35

. . . . . . . .

36 37 37 41 43 47 48 48 48

Inhoudsopgave

viii

7 Realiseren van spraakgesprekken met OpenEPC 7.1 Beschikbare applicaties in OpenEPC . . . . . . . . 7.1.1 HTTP proxy . . . . . . . . . . . . . . . . . 7.1.2 Open IMS Core . . . . . . . . . . . . . . . . 7.2 OTT met behulp van Skype . . . . . . . . . . . . . 7.3 IMS met behulp van Monster IMS client . . . . . . 7.3.1 Gebruikersprofielen . . . . . . . . . . . . . .

. . . . . .

50 50 51 53 55 55 56

. . . . .

57 58 59 61 61 62

. . . .

63 64 64 64 64

8 Policies en QoS in OpenEPC 8.1 Policy and Charging Control (PCC) 8.2 Instellen van policies . . . . . . . . . 8.2.1 Default bearer policy . . . . . 8.2.2 Youtube policy . . . . . . . . 8.3 Problemen . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

9 Handover van dataverbindingen met OpenEPC 9.1 Handover van E-UTRAN naar UTRAN en vice versa . . . . . . . . 9.2 Handover van E-UTRAN naar WiFi en vice versa . . . . . . . . . . 9.2.1 Handover met behulp van LTE femtocell en fysiek WiFi AP 9.3 Handovers zonder onderbreking van de sessie . . . . . . . . . . . .

. . . . . .

. . . . .

. . . .

. . . . . .

. . . . .

. . . .

. . . . . .

. . . . .

. . . .

. . . . . .

. . . . .

. . . .

. . . . . .

. . . . .

. . . .

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 E.1 Configuratie van componenten . . . . . . . . E.2 Provisioning van componenten . . . . . . . . E.2.1 Wissen van de data in de databank . . E.3 Testbed SSH sleutelverdeling . . . . . . . . .

72 72 73 74 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 I

ix

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 L.1 UEAlice . . . . . . L.2 ANGw . . . . . . . L.3 eNodeB . . . . . . L.4 EPCEnablers . . . L.5 ePDG . . . . . . . L.6 PDNGW . . . . . L.7 nodeB . . . . . . . L.8 SGW . . . . . . . .

92 92 92 93 93 94 94 94 95

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

M OpenEPC DNS

96

N OpenEPC routes naar testnetwerk

97

O Routeertabellen in OpenEPC O.1 UE . . . . . . . . . . . . . . . O.2 eNodeB . . . . . . . . . . . . O.3 S-GW . . . . . . . . . . . . . O.4 P-GW . . . . . . . . . . . . .

98 98 98 99 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 1.2

Verschillende onderdelen van een mobiel netwerk [1] . . . . . . . . . . . . . . Circuitgeschakeld en pakketgeschakeld domein [2] . . . . . . . . . . . . . . . .

2 3

2.1 2.2

De verschillende domeinen van de EPS architectuur [3] . . . . . . . . . . . . . De belangrijkste elementen in een LTE netwerk [4] . . . . . . . . . . . . . . .

6 8

3.1 3.2 3.3 3.4

Het verschil tussen OTT IMS [6] . . . . . . . . . VoLTE SRVCC [7] . . . Samenvatting van 3GPP

4.1 4.2 4.3 4.4 4.5 4.6

OpenEPC situering [8] . . . . . . . . OpenEPC roadmap [8] . . . . . . . . High-level OpenEPC architectuur . . OpenEPC componenten en interfaces ip.access LTE 245F [30] . . . . . . . OpenEPC architectuur [9] . . . . . .

providers en het IMS [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . oplossingen [3] . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

13 14 15 16

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

18 18 19 20 21 21

5.1 5.2 5.3 5.4 5.5 5.6 5.7

Virtual Wall . . . . . . . . . . . . . . . . . . . . . . . . . Standaard OpenEPC op de Virtual Wall . . . . . . . . . OpenEPC met Alice en Bob . . . . . . . . . . . . . . . . Minimalistische OpenEPC met externe Alice en Bob . . Opstelling voor handover tussen E-UTRAN en UTRAN Opstelling voor handover tussen E-UTRAN en WiFi . . Opstelling voor fysiek WiFi AP en LTE femtocell . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

26 27 28 29 30 31 32

6.1 6.2 6.3 6.4 6.5

Betrokken componenten [10] . . . . . . . . . . . . . . . . . . Architectuur voor connectiviteit in het kernnetwerk [10] . . Verbinding maken en verbreken met behulp van EHCP [10] Mobility Manager GUI verbonden met WiMAX [11] . . . . Android Mobility Manager configuratie [11] . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

36 37 38 39 40

. . . . . . [8] . . . .

x

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

Lijst van figuren

xi

6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13 6.14 6.15 6.16 6.17

iPhone verbonden met het GTP interface . . . . . . . PMIP interface . . . . . . LMA Provisioning . . . . LMA PDN configuratie . DNS configuratie . . . . . PDN IPv4 range . . . . . PDN IPv4 allocaties . . . LMA binding lijst . . . . MAG binding lijst . . . . GTP tunnel . . . . . . . . GRE tunnel . . . . . . . .

ePDG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

42 42 43 43 44 44 44 45 46 46 48 48

7.1 7.2 7.3 7.4 7.5 7.6

Application Function [10] . . . . . . . . . HTTP proxy [12] . . . . . . . . . . . . . . HTTP proxy geconfigureerd op de UE . . Open IMS Core [13] . . . . . . . . . . . . Open IMS Core verbonden met OpenEPC Alice Monster profielen . . . . . . . . . . .

. . . . . . . . . . . . [12] . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

51 52 53 54 55 56

8.1

De componenten en interfaces (PCC) [14] . . . . . . . . . . . PCC architectuur [15, 16] . . . PCC Web GUI . . . . . . . . . Policy regels . . . . . . . . . . . Default bearer acties . . . . . . Youtube condities . . . . . . . Youtube acties . . . . . . . . .

bij Policy and . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58 59 60 61 61 62 62

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

67

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

69

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

73

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

103

8.2 8.3 8.4 8.5 8.6 8.7

OpenEPC netwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

betrokken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

via . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

Charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Lijst van afkortingen 2G 3G 3GPP

2nd Generation 3rd Generation Third Generation Partnership Project

AAA

Authentication, Authorization and Accounting Application Function Access Network Access Network Gateway Access Network Discovery and Selection Function Access Point Name Application Server

AF AN AN GW ANDSF APN AS BA BBERF BSC BTS BU

Binding Acknowledgement Bearer Binding and Event Reporting Function Base Station Controller Base Transceiver Station Binding Update

CN CS CSCF CSFB

Core Network Circuit Switched Call Server Control Function Circuit Switched Fall Back

DHCP DL DNS DSL

Dynamic Host Configuration Protocol Downlink Domain Name System Digital Subscriber Line xii


E-UTRAN

xiii

EDGE EHCP eNB EPC ePDG EPS

Evolved Universal Terrestrial Radio Access Network Enhanced Data rates for GSM Evolution Enhanced DHCP eNodeB Evolved Packet Core Evolved Packet Data Gateway Evolved Packet System

GERAN GGSN GPRS GRE GSM GTP GTP-U GW

GSM EDGE Radio Access Network Gateway GPRS Support Node General Packet Radio Services Internet Protocol Global System for Mobile Communications GPRS Tunneling Protocol GPRS Tunneling Protocol for User Plane Gateway

HSPA HSS

High-Speed Packet Access Home Subscriber Server

I-CSCF IMS IMSI IP IPSec

Interrogating-CSCF IP Multimedia Subsystem International Mobile Subscriber Identity Internet Protocol IP Security

LMA LTE

Local Mobility Anchor Long Term Evolution

MAC MAG MDF MIP MME MMTel MNI MSC

Medium Access Control Mobile Access Gateway Media Delivery Function Mobile IP Mobility Management Entity MultiMedia Telephone Mobile Node Identifier Mobile Switching Centre


xiv

MTU

Maximum Transmission Unit

NAS NAT NIC

Non-Access Stratum Network Address Translation Network Interface Card

OFCS OTT

Offline Charging System Over The Top

P-CSCF P-GW PBA PBU PCC PCEF PCRF PDN PDN GW PMIP PS

Proxy-CSCF PDN GW Proxy Binding Acknowledgement Proxy Binding Update Policy and Charging Control Policy and Charging Enforcement Function Policy and Charging Rules Function Packet Data Network Packet Data Network Gateway Proxy Mobile IP Packet Switched

QoS

Quality of Service

RAN RNC

Radio Access Network Radio Network Controller

S-CSCF S-GW SAE Serving GW SGSN SIM SIP SRVCC

Serving-CSCF Serving GW System Architecture Evolution Serving Gateway Serving GPRS Support Node GSM Subscriber Identitiy Module Session Initiation Protocol Single-Radio Voice Call Continuity

TSO

TCP Segmentation Offload

UE UL

User Equipment Uplink


xv

UMTS UTRAN

Universal Mobile Telecommunications System UMTS Terrestrial Radio Access Network

VoIP VoLTE

Voice Over IP Voice-over-LTE

WCDMA WiMAX

Wideband Code Division Multiple Access Worldwide Interoperability for Microwave Access Wireless Local Area Network

WLAN

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 één 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 zendmasten 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


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 ontstaat van circuit- naar pakketschakeling. GSM (Global System for Mobile Communications) is gebouwd op een circuitgeschakelde infrastructuur die telefonie toelaat op cellulaire netwerken. 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 efficiëntie 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 IPfunctionaliteit 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]


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/HSPA naar een volledige IP-architectuur specifieert. De volledige IP-architectuur laat een gemeenschappelijk kernnetwerk toe voor radiotechnologieën 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 radioaccesstechnologieën (LTE, GSM en WCDMA/HSPA) alsook niet-3GPP radioaccesstechnologieën. 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 geëmuleerd 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 spraakgesprekken. 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 oplossingen voor spraakgesprekken worden toegelicht in hoofdstuk 3. Hoofdstuk 4 geeft een


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 gerealiseerd 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 non3GPP technologieën (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 circuitgeschakeld, 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 diensten (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 multimedia sessies gebaseerd op het SIP (Session Initiation Protocol). Het gebruikt de IPconnectiviteit 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 één-op-één 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.


8

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

De verbindingen tussen de verschillende entiteiten worden reference points of interfaces genoemd. 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 Network en 3GPP PS Core Network). Het IMS domein komt voor als een mogelijk Packet Data Network (PDN). De HSS component is verantwoordelijk voor het beheer van gebruikersdata.


2.2.1

9

User Equipment (UE)

User Equipment is het toestel dat gebruikt wordt door de eindgebruiker om te communiceren. 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 één 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 netwerken 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 één MME. De MME is verantwoordelijk voor het beheer van de verbindingen en sessies in het kernnetwerk (ook wel het control plane genoemd). Locatiegegevens van elke gebruiker worden door de MME bijgehouden en hierdoor kan de beste Serving GW gekozen worden per gebruiker. De MME speelt ook een belangrijke rol bij handovers tussen LTE en 2G/3G netwerken.


2.2.6

10

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 netwerkdekking 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 netwerken. 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 technologieën.


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 één van de belangrijkste diensten die een telecomoperator aanbiedt. Echter, de LTE technologie is geoptimaliseerd voor IP-gebaseerde diensten met een pakketgeschakeld kernnetwerk. Dit zorgt voor problemen om spraakgesprekken te kunnen ondersteunen 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 transport 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 kwaliteit 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 spraakdiensten 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 access 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 Mobile 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 multimediadiensten, zoals video en spraak, gemakkelijker te maken. Dit wordt gerealiseerd door een


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


15

Figuur 3.3: VoLTE SRVCC [7]

Om SRVCC te kunnen gebruiken is het IMS nodig. IMS moet gedurende het volledige gesprek, het gesprek kunnen aanleveren aan het pakketgeschakelde domein en circuitgeschakelde domein. SRVCC bevat daarom ook interactie tussen de MME van de EPC en de MSC Server van het circuitgeschakelde 2G/3G netwerk [20] (figuur 3.3).

3.4

Samenvatting

Dit hoofdstuk wordt nog afgesloten met een samenvattende figuur waarop de belangrijkste oplossingen van de operator te zien zijn (CSFB, VoLTE en SRVCC).


Figuur 3.4: Samenvatting van 3GPP oplossingen [3]

16

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 netwerktechnologieën (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 FOKUS garandeert niet dat de software aan alle standaarden zoals die door 3GPP zijn gede-


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 componenten 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-


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 geëmuleerde 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.


21

Zowel de virtuele als fysieke componenten zijn weergegeven voor de access netwerken (de geëmuleerde eNodeB en zijn fysieke equivalent, de ip.access LTE 245F (figuur 4.5) en de geëmuleerde 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 één of meerdere (vb. DNS/HSS/IMS) componenten voor van OpenEPC. De componenten worden op verschillende systemen ge¨ınstalleerd. De meeste logische blokken vormen ook telkens één systeem, behalve de SGw en EPC Enablers. De SGw


22

bestaat uit de componenten MSC, S-GW, SGSN en MME. EPC Enablers bevat de componenten 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 individuele 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


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 beschikbaar 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 RAMgeheugen 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


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 geconfigureerd 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 één 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 configureerbaar met Emulab. Emulab laat toe om een netwerk topologie te creëren 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 geëmuleerde 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).


27

Figuur 5.2: Standaard OpenEPC op de Virtual Wall

5.1.2

Toevoegen van een UE

De standaardopstelling van OpenEPC beschikt maar over één 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 één 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 één 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.


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


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 één kabel (per UE) gepatched te worden en kan elk toestel met één interface gebruikt worden als UE. Het configuratiebestand van deze opstelling bevindt zich in bijlage I.


30

Met deze opstelling is het nu mogelijk om portAlice en portBob te verbinden met een netwerkinterface van een laptop. Er kunnen twee aparte laptops gebruikt worden of één laptop met twee virtuele machines. Tijdens het uitvoeren van testscenario’s worden zowel twee laptops als één 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 portnodeB en porteNodeB. Dezelfde kabels als bij vorige sectie kunnen nu hergebruikt worden om handovers uit te voeren.Op figuur 5.6 zie je dat er zowel een NodeB als eNodeB is.

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


5.1.5

31

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.


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 gebruikt. 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 telkens opnieuw moeten gebeuren. De DNS server van OpenEPC zal zijn aanvragen moeten doorsturen naar de DNS server van de Virtual Wall en het testnetwerk van IBCN zal ook altijd moeten bereikbaar zijn vanaf de nodes.


5.2.1

33

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-persistentnet.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 definiëren van het experiment kiezen we vaste IP-adressen voor de verschillende interfaces, 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 overeenkomt. Op basis daarvan stellen we dan de interface namen in en rebooten het systeem. Het script is te vinden in bijlage L.


5.2.3

34

DNS

OpenEPC gebruikt een eigen DNS server. Alle componenten moeten deze DNS server gebruiken. 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 EPCEnablers gebruikt wel nog IP-forwarding. echo " 0 " > / proc / sys / net / ipv4 / conf / all / forwarding

5.2.6

Routes naar IBCN/test netwerk

Om toegang te krijgen tot de nodes over SSH is het nodig om routes in te stellen (bijlage N). Om testen uit te voeren kan het wel nodig zijn dat deze routes moeten verwijderd worden.


5.2.7

35

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 één 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 één van de access netwerken wordt de Mobility Manager gebruikt [26]. Deze Mobility Manager is nodig omdat de UE geëmuleerd 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 één van de verschillende AN GW’s wordt gebruikgemaakt van EHCP. Het EHCP protocol is een aangepaste versie van het DHCPv6 protocol ontwikkeld door Fraunhofer FOKUS. Deze aanpassingen zijn nodig om bijvoorbeeld een identificatie van de UE mee te sturen. Er zijn twee modules voor EHCP nodig:


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 teruggestuurd 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 één van de access netwerken te verbinden. De applicatie maakt gebruik van de EHCP modules.


39

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

Eens de client verbonden is met één 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/OpenEPC/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 " > < ANDSF url = " tcp : //19 2.16 8.1.3 1:10 000 " timeout = " 5 " /> < UE subscription_type = " 1 " subscription_id = " 001011234567890 " alert_port = " 10005 " /> ]] >


40

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


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.


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.


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


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 gealloceerde adressen (figuur 6.13) bekeken worden.

Figuur 6.11: DNS configuratie

Figuur 6.12: PDN IPv4 range


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.


Figuur 6.14: LMA binding lijst

Figuur 6.15: MAG binding lijst

46


6.2

47

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 geëncapsuleerde pakketten, decapsuleert, hercapsuleert en forward ze. De routeertabellen van de verschillende componenten zijn te zien in bijlage O. Als de UE verbinding maakt met de ePDG zijn de routeertabellen gelijkaardig, er wordt dan wel niet getunneld met het GTP protocol (tunneling met het GTP protocol wordt enkel gedaan tussen eNodeB, S-GW en P-GW), maar met het GRE protocol.


6.2.1

48

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 PGW, in het /opt/OpenEPC/etc/pgw.xml bestand. In de routeertabel van de P-GW in bijlage


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 " > < 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 " / > ]] >

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


52

Figuur 7.2: HTTP proxy [12]

De HTTP proxy is een Squid server [11]. Squid is een veelgebruikte proxyserver. De configuratie heeft enkele aanpassingen als volgt: ... # Here is the configuration of the external ACL ext ernal_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 : httpproxy@openepc . test external Rx_auth ... # Here we accept the requests which got the OK from the Rx http_access allow sip : httpproxy@openepc . test ... # 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 opgevangen. 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).


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.


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, één met en één zonder PCC functionaliteit.


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 één 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. MONSTER is ontwikkeld door Fraunhofer FOKUS en is één van de applicaties die ge¨ınstalleerd


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.


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


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.


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


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 opgemerkt 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 één bearer gebruikt worden in OpenEPC en dit is de default bearer. Ondersteuning voor dedicated bearers, met gegarandeerde bitrate, voor bijvoorbeeld VoIP is er niet. janseeuw@uealice :~ $ sudo iperf -c 192.168.1.32 -u -b 100 m -----------------------------------------------------------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 getransfereerd 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 technologieën. • Een handover tussen 3GPP en non-3GPP access technologieën. 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 technologieën als tussen 3GPP en non-3GPP access technologieën 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

9.1

64

Handover van E-UTRAN naar UTRAN en vice versa

Voor deze handover wordt de geëmuleerde 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 geëmuleerde 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 geëmuleerd is.

9.2.1

Handover met behulp van LTE femtocell en fysiek WiFi AP

De geëmuleerde 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 " > < WharfLMA ipv4 = " " ipv6 = " fc00 :1234:2::10 " hash_size = " 32 " seamless = " 1 " > ]] >

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 installatie 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 geëvalueerd. 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 componenten etc/...................................configuratiebestanden van alle componenten bind/..........................................DNS (Bind9) server configuratie dhcp/ ................................................ DHCP client configuratie dhcpd/...............................................DHCP server configuratie init/ ............................. configuratiebestanden voor start/stop/restart init.d/ ............ service-achtige wrappers voor bin scripts (start/stop/restart) monster.alice,bob,charlie,etc/..........................client configuraties mysql/..............................................MySQL server configuratie network/.........................................netwerk adapter configuraties sql/ ........................................ databank structuur en data dumps squid/.........................................Squid HTTP proxy configuratie www/.....................................................Web GUI configuratie configure system.sh.....................script om een systeem te configureren *.xml ...................... Wharf configuraties voor de OpenEPC componenten mm gui/ .......................................... de Client Mobility Manager GUI run/ ............................... placeholder voor run-time bestanden en uitvoer sbin/ ................................................... special binaries en scripts ser ims/..............................................Het Open Source IMS Core squid rx auth/...................................................Squid Rx client wharf/ ..................................................... 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 / s e t _ r o u t e _ d e f a u l t _ v i a _ m g m t . sh

69

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

70

/ opt / OpenEPC / sbin / s e t _ r o u t e _ d e f a u l t _ v i a _ m g m t . 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 waarmee geconnecteerd is. Dit kan verwezenlijkt worden door het bestand /etc/udev/rules/70persistent-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/etc/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 dependencies, 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 component. 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

E.2

73

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 opgeslagen 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 categorieën 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 efficiënter verloopt.

Bijlage F

Maken van een extra UE Tijdens de configuratie van een component van OpenEPC worden naast het installeren en configureren 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/configure system vars.sh. Door dit laatstgenoemde bestand te verwijderen, wordt bij het heruitvoeren van het script /opt/OpenEPC/etc/configure system.sh opnieuw gevraagd welke component er ge¨ınstalleerd moet worden. janseeuw@uealice :~ $ sudo rm / opt / OpenEPC / etc / co nfig ure_s yste m_var s . 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 -3 GPP 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 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 " 1000 Mb 0.0 ms ] set net - a [ $ns make - lan " $EPCEnablers $PDNGW " 1000000.0 kb 0.0 ms ] set net - b [ $ns make - lan " $ANGw $ePDG $PDNGW $SGW " 1000000.0 kb 0.0 ms ] set net - d [ $ns make - lan " $eNodeB $nodeB $SGW " 1000000.0 kb 0.0 ms ] set set set set

net - umts [ $ns duplex - link $nodeB $UEAlice 1000000.0 kb 0.0 ms DropTail ] net - lte [ $ns duplex - link $eNodeB $UEAlice 1000000.0 kb 0.0 ms DropTail ] net - wifi [ $ns duplex - link $ePDG $UEAlice 1000000.0 kb 0.0 ms DropTail ] net - wimax [ $ns duplex - link $ANGw $UEAlice 1000000.0 kb 0.0 ms 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 "

77

Bijlage G. Configuratiescript van standaard OpenEPC # this one is from the tb - set - ip - link UEAlice tb - set - ip - link UEAlice tb - set - ip - link UEAlice tb - set - ip - link UEAlice

78

DHCP range net - wifi " 192.168.3.130 " net - wimax " 192.168.3.129 " net - umts " 192.168.3.131 " 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 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 " 1000 Mb 0.0 ms ] set net - a [ $ns make - lan " $EPCEnablers $PDNGW " 1000000.0 kb 0.0 ms ] set net - b [ $ns make - lan " $ANGw $ePDG $PDNGW $SGW " 1000000.0 kb 0.0 ms ] set net - d [ $ns make - lan " $eNodeB $nodeB $SGW " 1000000.0 kb 0.0 ms ] set set set set

net - umts [ $ns make - lan " $nodeB $UEAlice $UEBob " 1000000.0 kb 0.0 ms ] net - lte [ $ns make - lan " $eNodeB $UEAlice $UEBob " 1000000.0 kb 0.0 ms ] net - wifi [ $ns make - lan " $ePDG $UEAlice $UEBob " 1000000.0 kb 0.0 ms ] net - wimax [ $ns make - lan " $ANGw $UEAlice $UEBob " 1000000.0 kb 0.0 ms ]

# 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 "

80

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 tb - set - ip - lan tb - set - ip - lan tb - set - ip - lan tb - set - ip - lan tb - set - ip - lan tb - set - ip - lan tb - set - ip - lan tb - set - ip - lan

from the DHCP range UEAlice net - wifi " 192.168.3.130 " UEAlice net - wimax " 192.168.3.129 " UEAlice net - umts " 192.168.3.131 " UEAlice net - lte " 192.168.3.132 " UEBob net - wifi " 192.168.3.134 " UEBob net - wimax " 192.168.3.133 " UEBob net - umts " 192.168.3.135 " 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 # ################################################### $ns rtproto Manual $ns run # ###################################################

82

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 $portBob add - desire SWITCHPORT 1 tb - fix - node $portBob storage1b # ################################################### # Lans # ################################################### set set set set

mgmt [ $ns make - lan " $eNodeB $EPCEnablers $PDNGW $SGW " 1000 Mb 0.0 ms ] net - a [ $ns make - lan " $EPCEnablers $PDNGW " 1000000.0 kb 0.0 ms ] net - b [ $ns make - lan " $PDNGW $SGW " 1000000.0 kb 0.0 ms ] net - d [ $ns make - lan " $eNodeB $SGW " 1000000.0 kb 0.0 ms ]

set net - lte [ $ns make - lan " $eNodeB $portAlice $portBob " 1000000.0 kb 0.0 ms ] # 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 "

84

Bijlage I. Configuratiescript van minimale OpenEPC met externe Alice en Bob 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 # ###################################################

85

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 set set set

mgmt [ $ns make - lan " $nodeB $eNodeB $EPCEnablers $PDNGW $SGW " 1000 Mb 0.0 ms ] net - a [ $ns make - lan " $EPCEnablers $PDNGW " 1000000.0 kb 0.0 ms ] net - b [ $ns make - lan " $PDNGW $SGW " 1000000.0 kb 0.0 ms ] net - d [ $ns make - lan " $nodeB $eNodeB $SGW " 1000000.0 kb 0.0 ms ]

set net - lte [ $ns make - lan " $eNodeB $porteNodeB " 1000000.0 kb 0.0 ms ] set net - umts [ $ns make - lan " $nodeB $portnodeB " 1000000.0 kb 0.0 ms ] # 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

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 # ###################################################

88

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 set set set

mgmt [ $ns make - lan " $eNodeB $ePDG $EPCEnablers $PDNGW $SGW " 1000 Mb 0.0 ms ] net - a [ $ns make - lan " $EPCEnablers $PDNGW " 1000000.0 kb 0.0 ms ] net - b [ $ns make - lan " $PDNGW $SGW $ePDG " 1000000.0 kb 0.0 ms ] net - d [ $ns make - lan " $eNodeB $SGW " 1000000.0 kb 0.0 ms ]

set net - lte [ $ns make - lan " $eNodeB $porteNodeB " 1000000.0 kb 0.0 ms ] set net - wifi [ $ns make - lan " $ePDG $portePDG " 1000000.0 kb 0.0 ms ] # 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 # ################################################### 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 # ###################################################

91

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 }== " 0 x0 " , 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 }== " 0 x0 " , 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 }== " 0 x0 " , 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 }== " 0 x0 " , 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 }== " 0 x0 " , 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 }== " 0 x0 " , 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 }== " 0 x0 " , 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 }== " 0 x0 " , 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 }== " 0 x0 " , 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 }== " 0 x0 " , 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 }== " 0 x0 " , 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 }== " 0 x0 " , 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 }== " 0 x0 " , ATTR { type }== " 1 " , KERNEL == " eth * " , NAME = " net_a " ’ >> / etc / udev / rules . d /70 - persistent - net . rules


L.5

94

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 }== " 0 x0 " , 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 }== " 0 x0 " , 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 }== " 0 x0 " , 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 }== " 0 x0 " , 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 }== " 0 x0 " , 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 }== " 0 x0 " , 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 }’‘


95

echo ’ SUBSYSTEM == " net " , ACTION == " add " , DRIVERS == " ?* " , ATTR { address }== " ’ $mac_mgmt ’ " , ATTR { dev_id }== " 0 x0 " , 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 }== " 0 x0 " , 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 }== " 0 x0 " , 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 }== " 0 x0 " , 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 }== " 0 x0 " , 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 }== " 0 x0 " , 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 controlif ‘ ip route add 157.193.135.0/24 via 10.2.47.254 controlif ‘ ip route add 157.193.215.0/24 via 10.2.47.254 controlif ‘ ip route add 192.168.126.0/24 via 10.2.47.254 controlif ‘ ip route del default via 10.2.47.254 dev ‘ cat

97

dev ‘ cat / var / emulab / boot / dev ‘ cat / var / emulab / boot / dev ‘ cat / var / emulab / boot / dev ‘ cat / var / emulab / boot / / var / emulab / boot / controlif ‘

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 0.0.0.0 192.168.3.29 192.168.3.29 0.0.0.0 192.168.254.0 0.0.0.0

O.2

Genmask 0.0.0.0 255.255.255.255 255.255.255.0

Flags UG UH U

Metric 10 0 0

Ref 0 0 0

Use 0 0 0

Iface an_lte an_lte mgmt

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 rm ln ln rm ln ln ln ln

- fr / etc / init . d / squid - fr / usr / sbin / squid -s / etc / init . d / squid3 / etc / init . d / squid -s / usr / sbin / squid3 / usr / sbin / squid - fr / etc / squid3 / squid . conf -s / opt / OpenEPC / etc / squid / squid . conf / etc / squid3 / squid . conf -s / etc / squid3 / etc / squid -s / var / log / squid3 / var / log / squid -s / var / spool / squid3 / var / spool / squid

Hierna start je squid3 opnieuw op. j a n s e e u w @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. j a n s e e u w @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 seriële 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. Eén 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 F A P S e r v i c e F A P C o n t r o l L T E G a t e w a y set S1SigLinkServerList =192.168.4.80; sqlite > update FA P Se r vi ce F AP C on tr o lL T E 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: //www.3gpp.org/technologies/keywords-acronyms/100-the-evolved-packet-core

http:

[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 timate winner?” [Online]. Available: volte-or-voip-over-lte-who-is-the-ultimate-winner

LTE – who is the ulhttp://blog.imgtec.com/hellosoft/

[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: //www.unwiredinsight.com/2013/waiting-for-volte

http:

[8] F. FOKUS, “OpenEPC, Open Evolved Packet Core.” [Online]. Available: //www.openepc.net

http:

[9] “OpenEPC Rel. 4 Installation and Use Guide.” [Online]. Available: //extsvnsrv.fokus.fraunhofer.de/cc/ngni/iMinds/wiki/Installation Guide Rel4

https:

[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 Control.” [Online]. Available: https://extsvnsrv.fokus.fraunhofer.de/cc/ngni/iMinds/wiki/ Installation Guide PCC Rel4 [17] “3GPP System Architecture Evolution Specification.” [Online]. Available: //www.3gpp.org/DynaReport/FeatureOrStudyItemFile-320005.htm

http:

[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.”

Studie van voice over IP in 4G netwerken met behulp van OpenEPC

Recommend Documents