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

Transcriptie

1 owered by TCPDF ( Academiejaar Faculteit Ingenieurswetenschappen en Architectuur Valentin Vaerwyckweg 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

2

3 owered by TCPDF ( Academiejaar Faculteit Ingenieurswetenschappen en Architectuur Valentin Vaerwyckweg 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

4 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

5 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

6 Inhoudsopgave Woord vooraf Abstract Lijst van figuren Lijst van afkortingen iv v x xii 1 Inleiding Structuur van mobiele netwerken Twee soorten services: data en spraak Van een circuit- naar pakketgeschakeld kernnetwerk Doelstelling van de masterproef Structuur van de masterproef EPS architectuur Inleiding De belangrijkste elementen in een LTE netwerk User Equipment (UE) enodeb (enb) Serving GW (S-GW) PDN GW (P-GW) Mobility Management Entity (MME) Home Subscriber Server (HSS) Policy and Charging Rules Function (PCRF) Samenwerking tussen LTE en WCDMA/HSPA Samenwerking tussen LTE en WiFi Spraakgesprekken in 4G netwerken Over The Top (OTT) Circuit Switched Fall Back (CSFB) vi

7 Inhoudsopgave vii 3.3 Voice-over-LTE (VoLTE) en IP Multimedia Subsystem (IMS) Single-Radio Voice Call Continuity (SRVCC) Samenvatting Introductie tot OpenEPC Wat is OpenEPC? OpenEPC architectuur en mogelijkheden De verschillende componenten van OpenEPC Ontplooien van de OpenEPC software Het gebruik van OpenEPC met Virtuele Machines in VMWare Installatie van OpenEPC op fysieke systemen Ontplooien en installeren van OpenEPC op de Virtual Wall Virtual Wall opstellingen Standaard opstelling op de Virtual Wall Toevoegen van een UE Het koppelen van externe UE s aan de Virtual Wall Handover tussen E-UTRAN en UTRAN Handover tussen E-UTRAN en WiFi Fysiek WiFi access point en LTE femtocell Configuratie van de systemen TCP Segmentation Offload (TSO) Interfaces DNS NAT op EPC-Enablers IP-forwarding Routes naar IBCN/test netwerk rc.local IP Connectiviteit in OpenEPC Verbinding maken met een access netwerk Mobility Manager Verbinden zonder Mobility Manager Web GUI Routering GTP tunnel tussen enb en S-GW en tussen S-GW en P-GW GRE tunnel tussen epdg en P-GW Het SGi reference point

8 Inhoudsopgave viii 7 Realiseren van spraakgesprekken met OpenEPC Beschikbare applicaties in OpenEPC HTTP proxy Open IMS Core OTT met behulp van Skype IMS met behulp van Monster IMS client Gebruikersprofielen Policies en QoS in OpenEPC Policy and Charging Control (PCC) Instellen van policies Default bearer policy Youtube policy Problemen Handover van dataverbindingen met OpenEPC Handover van E-UTRAN naar UTRAN en vice versa Handover van E-UTRAN naar WiFi en vice versa Handover met behulp van LTE femtocell en fysiek WiFi AP Handovers zonder onderbreking van de sessie Besluit 66 A Gedetailleerde OpenEPC opstelling 67 B Algemene projectstructuur van OpenEPC 68 C Het gebruik van OpenEPC met Virtuele Machines in VMWare 69 D Installatie van OpenEPC 71 E Bedienen van de componenten in OpenEPC 72 E.1 Configuratie van componenten E.2 Provisioning van componenten E.2.1 Wissen van de data in de databank E.3 Testbed SSH sleutelverdeling F Maken van een extra UE 75 G Configuratiescript van standaard OpenEPC 76 H Configuratiescript van OpenEPC met virtuele Alice en Bob 79

9 Inhoudsopgave ix I Configuratiescript van minimale OpenEPC met externe Alice en Bob 83 J Configuratiescript voor handover tussen enodeb en NodeB 86 K Configuratiescript voor handover tussen enodeb en epdg 89 L OpenEPC interfaces 92 L.1 UEAlice L.2 ANGw L.3 enodeb L.4 EPCEnablers L.5 epdg L.6 PDNGW L.7 nodeb L.8 SGW M OpenEPC DNS 96 N OpenEPC routes naar testnetwerk 97 O Routeertabellen in OpenEPC 98 O.1 UE O.2 enodeb O.3 S-GW O.4 P-GW 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

10 Lijst van figuren 1.1 Verschillende onderdelen van een mobiel netwerk [1] Circuitgeschakeld en pakketgeschakeld domein [2] De verschillende domeinen van de EPS architectuur [3] De belangrijkste elementen in een LTE netwerk [4] Het verschil tussen OTT providers en het IMS [5] IMS [6] VoLTE SRVCC [7] Samenvatting van 3GPP oplossingen [3] OpenEPC situering [8] OpenEPC roadmap [8] High-level OpenEPC architectuur OpenEPC componenten en interfaces [8] ip.access LTE 245F [30] OpenEPC architectuur [9] 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 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] x

11 Lijst van figuren xi 6.6 iphone verbonden met het OpenEPC netwerk via epdg 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 Application Function [10] HTTP proxy [12] HTTP proxy geconfigureerd op de UE Open IMS Core [13] Open IMS Core verbonden met OpenEPC [12] Alice Monster profielen De componenten en interfaces betrokken bij Policy and Charging Control (PCC) [14] PCC architectuur [15, 16] PCC Web GUI Policy regels Default bearer acties Youtube condities Youtube acties A.1 OpenEPC opstelling C.1 Bij opstarten VM E.1 OpenEPC Web GUI R.1 Web GUI

12 Lijst van afkortingen 2G 3G 3GPP 2nd Generation 3rd Generation Third Generation Partnership Project AAA Authentication, Authorization and Accounting AF Application Function AN Access Network AN GW Access Network Gateway ANDSF Access Network Discovery and Selection Function APN Access Point Name AS Application Server BA 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

13 Lijst van afkortingen xiii E-UTRAN 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

14 Lijst van afkortingen 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

15 Lijst van afkortingen xv UMTS UTRAN Universal Mobile Telecommunications System UMTS Terrestrial Radio Access Network VoIP VoLTE Voice Over IP Voice-over-LTE WCDMA WiMAX WLAN Wideband Code Division Multiple Access Worldwide Interoperability for Microwave Access Wireless Local Area Network

16 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

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

18 Hoofdstuk 1. Inleiding 3 pakketten ook zullen aankomen. Het kernnetwerk bij 4G moet daarom zelf zorgen voor de nodige Quality of Service (QoS). Meer informatie over de mogelijkheden om spraak te ondersteunen in een 4G netwerk vind je in hoofdstuk 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]

19 Hoofdstuk 1. Inleiding 4 Het resultaat van de 3GPP SAE (System Architecture Evolution) technische studie [17] is een set standaarden die de evolutie van het pakket kernnetwerk voor GSM/GPRS en UMTS/H- SPA naar een volledige IP-architectuur specifieert. De volledige IP-architectuur laat een gemeenschappelijk kernnetwerk toe voor 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

20 Hoofdstuk 1. Inleiding 5 introductie tot het OpenEPC -software pakket. Hoe de software op de Virtual Wall wordt ontplooid en geïnstalleerd wordt in hoofdstuk 5 behandeld. Hoe een internetconnectie 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.

21 Hoofdstuk 2 EPS architectuur Dit hoofdstuk geeft een schets weer van de EPS architectuur zoals die gedefinieerd is in de 3GPP SAE studie. Eerst wordt de algemene architectuur van het volledige EPS geïntroduceerd, waarna dieper wordt ingegaan op de componenten die meest relevant zijn bij 4G netwerken. 2.1 Inleiding Het EPS bestaat uit de UE, RAN s, bijvoorbeeld E-UTRAN (LTE/4G access netwerk), UTRAN (WCDMA/3G access netwerk), GERAN (GSM/2G access netwerk) en andere non- 3GPP 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

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

23 Hoofdstuk 2. EPS architectuur 8 Figuur 2.2: De belangrijkste elementen in een LTE netwerk [4] De verbindingen tussen de verschillende entiteiten worden reference points of interfaces 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.

24 Hoofdstuk 2. EPS architectuur 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 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 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 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 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.

25 Hoofdstuk 2. EPS architectuur 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 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.

26 Hoofdstuk 2. EPS architectuur 11 Een use case kan als volgt zijn: je hebt een toestel dat LTE en WiFi ondersteunt. Je bent verbonden met het LTE netwerk en begeeft je naar binnen in je huis. Daar staat je WiFi access point. Het toestel kan in deze situatie overschakelen van LTE naar Carrier WiFi. De EPS architectuur bevat features die ervoor zorgen dat de sessie tijdens deze handover behouden blijft. Om dit te realiseren wordt Mobile IP gebruikt.

27 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

28 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

29 Hoofdstuk 3. Spraakgesprekken in 4G netwerken 14 horizontale controlelaag (Call Server Control Function (CSCF) op figuur 3.2) die het access netwerk isoleert van de applicaties. Figuur 3.2: IMS [6] MMTel is dan een op IMS-gebaseerde service voor spraakgesprekken die gestandaardiseerd is door 3GPP [19] (dit is een Application Server zoals te zien op figuur 3.2). MMTel is een oplossing voor spraakgesprekken in gebieden met LTE dekking. MMTel biedt meer mogelijkheden dan circuitgeschakelde spraakgesprekken op 2G/3G netwerken. Zo is het mogelijk om ook video en andere media toe te voegen aan het gesprek 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.

30 Hoofdstuk 3. Spraakgesprekken in 4G netwerken 15 Figuur 3.3: VoLTE SRVCC [7] Om SRVCC te kunnen gebruiken is het IMS nodig. IMS moet gedurende het volledige 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).

31 Hoofdstuk 3. Spraakgesprekken in 4G netwerken 16 Figuur 3.4: Samenvatting van 3GPP oplossingen [3]

32 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

33 Hoofdstuk 4. Introductie tot OpenEPC 18 Figuur 4.1: OpenEPC situering [8] In deze masterproef wordt release 4 van OpenEPC gebruikt. Figuur 4.2 toont een overzicht van de verschillende versies. Figuur 4.2: OpenEPC roadmap [8] De OpenEPC software omvat de basisfunctionaliteiten van het 3GPP EPC. Fraunhofer FO- KUS garandeert niet dat de software aan alle standaarden zoals die door 3GPP zijn gede-

34 Hoofdstuk 4. Introductie tot OpenEPC 19 finieerd voldoet. Het is slechts een prototype implementatie en er kunnen nog fouten in de software voorkomen [15] 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-

35 Hoofdstuk 4. Introductie tot OpenEPC 20 covery and Selection Function (ANDSF) en Offline Charging System (OFCS) zijn minder belangrijk in de context van deze masterproef 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.

36 Hoofdstuk 4. Introductie tot OpenEPC 21 Zowel de virtuele als fysieke componenten zijn weergegeven voor de access netwerken (de gee muleerde enodeb en zijn fysieke equivalent, de ip.access LTE 245F (figuur 4.5) en de gee 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 e e 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 e e n systeem, behalve de SGw en EPC Enablers. De SGw

37 Hoofdstuk 4. Introductie tot OpenEPC 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

38 Hoofdstuk 4. Introductie tot OpenEPC 23 links gelegd naar de aangepaste bestanden in de mappen van OpenEPC. De mappenstructuur is te vinden in bijlage B. Om de leercurve van het OpenEPC pakket te verbeteren is de volledige opstelling 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 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 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

39 Hoofdstuk 4. Introductie tot OpenEPC 24 theorie zou je minder systemen kunnen gebruiken, maar dat zal de configuratie complexer maken. Ook het uit elkaar houden van de verschillende procedures wordt hierdoor moeilijker. Op 8 systemen worden de componenten als volgt verdeeld: 1. P-GW - LMA, PCEF 2. S-GW - MAG, BBERF, MME, MSC, SGSN 3. NodeB - nodeb 4. enodeb - enodeb 5. epdg - MAG, BBERF, radius voor IPSec 6. ANGw - MAG, BBERF, radius voor EAP-AKA 7. EPC Enablers - PCRF, ANDSF, www (Web GUI), DNS, IMS, HTTP proxy, MDF, andere AF, NAT 8. UE - Client Mobilty Manager LMA en MAG worden gebruikt bij Mobile IP. PCEF en BBERF zijn nodig voor de werking van de PCRF. IPSec wordt gebruikt om een beveiligde connectie op te zetten tussen de epdg en de client. Dit laatste hoort zo te zijn volgens de standaarden [22]. Wanneer de 8 systemen verbonden zijn met elkaar kunnen de verschillende systemen geconfigureerd worden. De installatieprocedure en hoe deze componenten gebruikt worden, is te vinden in bijlage D.

40 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

41 Hoofdstuk 5. Ontplooien en installeren van OpenEPC op de Virtual Wall 26 Figuur 5.1: Virtual Wall Standaard opstelling op de Virtual Wall Deze opstelling (figuur 5.2) maakt gebruik van een gee 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).

42 Hoofdstuk 5. Ontplooien en installeren van OpenEPC op de Virtual Wall 27 Figuur 5.2: Standaard OpenEPC op de Virtual Wall 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.

43 Hoofdstuk 5. Ontplooien en installeren van OpenEPC op de Virtual Wall 28 Figuur 5.3: OpenEPC met Alice en Bob Bij het verbinden met bijvoorbeeld de enodeb mag enkel de enodeb het DHCP sollicit bericht van de UE ontvangen. Als niet enkel de enodeb, maar ook de NodeB, epdg en ANGw op hetzelfde LAN segment zitten, dan krijgen ze allemaal dit DHCP bericht en denkt de OpenEPC software dat de UE met alle vier de access netwerken tegelijk wil verbinden. Hierdoor kan bijvoorbeeld een situatie ontstaan waarbij de UE denkt verbonden te zijn met de enodeb, maar OpenEPC routeert alle pakketten via de epdg. Wanneer een client een DHCP sollicit bericht verstuurt, moet dit verzonden worden via de interface waarop hij een IP-adres nodig heeft. Het bericht is gericht naar een multicast adres. Alle DHCP servers van het LAN segment ontvangen dan dit bericht en reageren hierop [25]. Meer details over hoe er een verbinding wordt gemaakt, is te vinden in sectie 6.1 van hoofdstuk

44 Hoofdstuk 5. Ontplooien en installeren van OpenEPC op de Virtual Wall Hoe er een extra client aangemaakt kan worden, wordt beschreven in bijlage F. In bijlage H staat het configuratiescript 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.

45 Hoofdstuk 5. Ontplooien en installeren van OpenEPC op de Virtual Wall 30 Met deze opstelling is het nu mogelijk om portalice en portbob te verbinden met een 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 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

46 Hoofdstuk 5. Ontplooien en installeren van OpenEPC op de Virtual Wall 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 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.

47 Hoofdstuk 5. Ontplooien en installeren van OpenEPC op de Virtual Wall 32 Figuur 5.7: Opstelling voor fysiek WiFi AP en LTE femtocell 5.2 Configuratie van de systemen Om een systeem te configureren wordt het script /opt/openepc/etc/configure system.sh 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.

48 Hoofdstuk 5. Ontplooien en installeren van OpenEPC op de Virtual Wall 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 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.

49 Hoofdstuk 5. Ontplooien en installeren van OpenEPC op de Virtual Wall 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 { ; }; } 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 IP-forwarding IP-forwarding wordt standaard ingeschakeld door de Virtual Wall. Maar omdat OpenEPC routering zelf voor zijn rekening neemt, moet IP-forwarding uitgeschakeld worden. De EPC- Enablers gebruikt wel nog IP-forwarding. echo "0" > / proc / sys / net / ipv4 / conf / all / forwarding 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.

50 Hoofdstuk 5. Ontplooien en installeren van OpenEPC op de Virtual Wall 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.

51 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

52 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) 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:

53 Hoofdstuk 6. IP Connectiviteit in OpenEPC 38 ehcp messaging ehcp daemon Figuur 6.3: Verbinding maken en verbreken met behulp van EHCP [10] De Mobile Access Gateway (MAG) krijgt een request van de UE via het EHCP protocol. De informatie in deze request wordt daarna verder doorgestuurd over een GPRS Tunneling Protocol (GTP) of Proxy Mobile IP (PMIP) interface naar de Local Mobility Anchor (LMA). De LMA zorgt voor het toekennen van een IP adres aan de UE. Het antwoord wordt 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.

54 Hoofdstuk 6. IP Connectiviteit in OpenEPC 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/openep- C/etc/mm.xml. De variabele subcription id stelt het IMSI-nummer ( ) voor. Dit nummer is random gekozen en heeft verder geen betekenis. < Module binaryfile =" modules / mm_andsf / mm_andsf.so" > <![ CDATA [ <MM_ANDSF > <ANDSF url =" tcp :// :10000 " timeout =" 5" /> <UE subscription_ type =" 1" subscription_ id =" " alert_port =" " /> </ MM_ANDSF > ]] >

55 Hoofdstuk 6. IP Connectiviteit in OpenEPC 40 </ Module > Android Mobility Manager Er is ook een Mobility Manager app voor Android. De app werkt niet op alle Android versies [26]. De app werkte niet op het toestel (Samsung Galaxy S3) waarop het getest is tijdens deze masterproef. Figuur 6.5: Android Mobility Manager configuratie [11] Figuur 6.5 toont het instellingenmenu van de Android Mobility Manager. In het IMSI-veld kan het IMSI-nummer van de client opgegeven worden. Indien het veld leeg is wordt het IMSI-nummer van de SIM-kaart gebruikt. Het identificeren van de UE tijdens verbinden DHCPv6 optie 135 in het DHCPv6 sollicit bericht wordt gebruikt om een identificatie van de UE mee te geven. Als UE Alice verbindt heeft optie 135 de waarde

56 Hoofdstuk 6. IP Connectiviteit in OpenEPC hexadecimaal of in ascii. Het getal komt overeen met het IMSI van Alice 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.

57 Hoofdstuk 6. IP Connectiviteit in OpenEPC 42 Figuur 6.6: iphone verbonden met het OpenEPC netwerk via epdg Figuur 6.6 toont de verkregen informatie van DHCP na het verbinden. Na het instellen van de HTTP proxy van de Virtual Wall kan er probleemloos op internet gegaan worden met het toestel. GTP interface tussen de enb en S-GW en tussen de S-GW en P-GW Figuur 6.7: GTP interface Figuur 6.7 toont de berichten die uitgewisseld worden nadat een UE verbinding heeft gemaakt met de enb.

58 Hoofdstuk 6. IP Connectiviteit in OpenEPC 43 PMIP interface tussen de epdg en P-GW Figuur 6.8: PMIP interface Figuur 6.8 toont de berichten die uitgewisseld worden nadat een UE verbinding heeft gemaakt met de epdg 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

59 Hoofdstuk 6. IP Connectiviteit in OpenEPC 44 Figuur 6.10: LMA PDN configuratie Figuur 6.10 toont een lijst van PDN configuraties. Bij het kiezen van de default apn PDN configuratie kunnen DNS configuratie (figuur 6.11), IPv4 range (figuur 6.12) en de gealloceerde adressen (figuur 6.13) bekeken worden. Figuur 6.11: DNS configuratie Figuur 6.12: PDN IPv4 range

60 Hoofdstuk 6. IP Connectiviteit in OpenEPC 45 Figuur 6.13: PDN IPv4 allocaties In de lijst van allocaties op figuur 6.13 komen twee MNI s (Mobile Node Identifiers) voor: IMSI en 99. IMSI spreekt voor zich. De andere worden toegevoegd wanneer er zonder gebruik van de Mobility Manager met het WiFi AP verbinding gemaakt wordt. Een MNI wordt gebruikt bij Mobile IPv6 om iets te kunnen identificeren met iets anders dan een IP-adres [27]. Figuren 6.14 en 6.15 tonen dat de IP-adressen gekend zijn in de MAG en LMA.

61 Hoofdstuk 6. IP Connectiviteit in OpenEPC 46 Figuur 6.14: LMA binding lijst Figuur 6.15: MAG binding lijst

62 Hoofdstuk 6. IP Connectiviteit in OpenEPC 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.

63 Hoofdstuk 6. IP Connectiviteit in OpenEPC 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 GRE tunnel tussen epdg en P-GW Figuur 6.17: GRE tunnel Figuur 6.16 toont aan dat een ping bericht getunneld word met het GRE protocol. 6.3 Het SGi reference point Het SGi reference point wordt gebruikt op de P-GW om verkeer dat voor het Internet bestemd is door te sturen. Het SGi reference point komt overeen met een netwerkinterface van de machine die dienst doet als P-GW. Deze interface wordt gekozen in de configuratie van de P- GW, in het /opt/openepc/etc/pgw.xml bestand. In de routeertabel van de P-GW in bijlage

64 Hoofdstuk 6. IP Connectiviteit in OpenEPC 49 O is te zien dat verkeer, afkomstig van de UE, vezonden wordt via routing extension 2. Deze routing extension wordt geconfigureerd in het xml bestand is de interface waarmee de P-GW is aangesloten op het Net A LAN segment. < Module binaryfile =" modules / routing / routing.so"> <![ CDATA [ < WharfROUTING > < Extension id="1" mod_name =" routing_encap " src_table =" teid " dst_table ="ip" ipv4 =" " ipv6 =" FC00 :1234:2::10 " protocol =" gre " /> < Extension id="2" mod_name =" routing_raw " dst_table ="ip" interface =" net_a " ipv4 =" " ipv6 =" FC00 :1234:1::10 " /> < Extension id="3" mod_name =" routing_gtpu " src_table =" teid " dst_table ="ip" ipv4 =" " ipv6 =" FC00 :1234:2::10 "/> </ WharfROUTING > ]] > </ Module > Deze configuratie dient er enkel voor om op de correcte interface een socket te laten luisteren naar inkomende pakketten van het Net A LAN segment (het internet). De routeertabel van Linux wordt gebruikt om pakketten, afkomstig van de UE, te versturen. Als een pakket niet gerouteerd kan worden met behulp van de routetabel in Linux, krijgt de PGW een foutmelding. ERR : routing_ raw_ send () :385 > Could not send the packet > Network is unreachable

65 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

66 Hoofdstuk 7. Realiseren van spraakgesprekken met OpenEPC 51 Figuur 7.1: Application Function [10] 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.

67 Hoofdstuk 7. Realiseren van spraakgesprekken met OpenEPC 52 Figuur 7.2: HTTP proxy [12] De HTTP proxy is een Squid server [11]. Squid is een veelgebruikte proxyserver. De configuratie heeft enkele aanpassingen als volgt:... # Here is the configuration of the external ACL external_ acl_ type Rx_auth children =1 % SRC % MYADDR % DST / opt / OpenEPC / squid_rx_auth / rx_auth # 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).

68 Hoofdstuk 7. Realiseren van spraakgesprekken met OpenEPC 53 De HTTP proxy kan dan op de UE, in bijvoorbeeld Firefox, gebruikt worden. Figuur 7.3: HTTP proxy geconfigureerd op de UE HTTP proxy van de Virtual Wall De Virtual Wall maakt ook gebruik van een HTTP proxy. De HTTP proxy van OpenEPC moet al het verkeer doorsturen naar de proxy van de Virtual Wall. Om dit te realiseren worden volgende lijnen toegevoegd aan de configuratie (/etc/squid3/squid.conf ). cache_ peer parent never_ direct allow all Als alternatief kan op de client het adres met poort 8080 gebruikt worden als proxy in plaats van de proxy van OpenEPC 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.

69 Hoofdstuk 7. Realiseren van spraakgesprekken met OpenEPC 54 Figuur 7.4: Open IMS Core [13] Er zijn enkele aanpassingen doorgevoerd om beter te kunnen integreren in OpenEPC. Zo wordt de HSS van OpenEPC gebruikt in plaats van die van het Open IMS Core. Er is een extra aangepaste P-CSCF zodat de Open IMS Core kan verbonden worden met de Rx interface van de PCRF in OpenEPC (figuur 7.5). Er zijn dan twee verschillende P-CSCF s beschikbaar, één met en één zonder PCC functionaliteit.

70 Hoofdstuk 7. Realiseren van spraakgesprekken met OpenEPC 55 Figuur 7.5: Open IMS Core verbonden met OpenEPC [12] 7.2 OTT met behulp van Skype Wanneer de UE een IP-adres heeft verkregen van éé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. MON- STER is ontwikkeld door Fraunhofer FOKUS en is één van de applicaties die geïnstalleerd

71 Hoofdstuk 7. Realiseren van spraakgesprekken met OpenEPC 56 wordt op de client (UE) machine. Om de applicatie te gebruiken moet een gebruikersprofiel gedefinieerd zijn. Er zijn gebruikersprofielen voor Alice en Bob beschikbaar 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: : / opt / OpenEPC / bin / MONSTER. Alice.sh

72 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

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

74 Hoofdstuk 8. Policies en QoS in OpenEPC 59 Figuur 8.2: PCC architectuur [15, 16] 8.2 Instellen van policies Policies kunnen ingesteld worden in de Web GUI van OpenEPC (figuur 8.3). Hiervoor selecteer je PCC en daarna PCRF in het menu bovenaan. In het linkermenu vind je dan volgende drie onderdelen: PCRF Policies: hier kunnen de policy regels ingesteld en gegroepeerd worden PCRF Constants: geeft constanten weer die gebruikt worden, deze mogen niet aangepast worden Debugging: geeft de actieve sessies en PCC regels weer

75 Hoofdstuk 8. Policies en QoS in OpenEPC 60 Figuur 8.3: PCC Web GUI Er zijn al enkele policy regels ingesteld in OpenEPC (figuur 8.3). De Default Bearer policy wordt altijd toegepast, IMS Registration en IMS Services worden gebruikt bij het IMS. De regels RadioTvAndalucia en Youtube worden toegepast in combinatie met de HTTP proxy (wanneer er naar of 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.

76 Hoofdstuk 8. Policies en QoS in OpenEPC 61 Figuur 8.4: Policy regels 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 Youtube policy De Youtube policy heeft volgende condities (figuur 8.6) en acties (figuur 8.7).

77 Hoofdstuk 8. Policies en QoS in OpenEPC 62 Figuur 8.6: Youtube condities Figuur 8.7: Youtube acties 8.3 Problemen Bij het testen van policies en het nader onderzoeken van de configuratiebestanden is 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. uealice :~ $ sudo iperf -c u -b 100 m Client connecting to , UDP port 5001 Sending 1470 byte datagrams UDP buffer size : 224 KByte ( default ) [ 3] local port connected with port 5001 [ ID] Interval Transfer Bandwidth [ 3] sec 120 MBytes 101 Mbits / sec [ 3] Sent datagrams

78 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

79 Hoofdstuk 9. Handover van dataverbindingen met OpenEPC 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 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 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 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 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 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 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

80 Hoofdstuk 9. Handover van dataverbindingen met OpenEPC 65 de UE via het nieuwe RAN toekomen. Het zijn dus zeker geen handover zoals die door 3GPP voorgeschreven zijn. Dit kan dus enkel door het feit dat er een Mobility Manager gebruikt wordt door de UE (zie sectie 6.1). < Module binaryfile =" modules / lma / lma.so"> <![ CDATA [ <!-- LMA Parameters - ipv4 - IPv4 address to identify this LMA to the MAGs - ipv6 - IPv6 address to identify this LMA to the MAGs - hash_ size - hash size for the binding cache hash table. default is 32 ( optional ) - seamless - use seamless handovers or not (1 - yes, 0- no). default is 1 ( optional ) --> < WharfLMA ipv4 ="" ipv6 =" fc00 :1234:2::10 " hash_size ="32" seamless ="1"> </ WharfLMA > </ Module > ]] >

81 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

82 Bijlage A Gedetailleerde OpenEPC opstelling Figuur A.1: OpenEPC opstelling 67

83 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

84 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 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 ( ). Alle machines, behalve de machine die client voorstelt, zijn geconfigureerd met een default gateway zodat ze internettoegang hebben via de host machine, bijvoorbeeld voor een update. Voor de client kan je een script gebruiken om de default gateway via de host machine aan of uit te zetten. / opt / OpenEPC / sbin / set_route_default_via_mgmt.sh 69

85 Bijlage C. Het gebruik van OpenEPC met Virtuele Machines in VMWare 70 / opt / OpenEPC / sbin / set_route_default_via_mgmt.sh Manueel kan je dit ook doen als volgt ip route add default via echo " nameserver " > / etc / resolv. conf en om het terug ongedaan te maken ip route del default via Het default wachtwoord voor root is epc op alle systemen. De logingegevens voor de Web GUI ( zijn admin met wachtwoord epc.

86 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/70- persistent-net.rules aan te passen. Dit bestand toont de persistente koppeling tussen MAC adres en interface alias. vim / etc / udev / rules.d/70 - persistent - net. rules De volgende stap tijdens de configuratie is het plaatsen van de /opt/openepc directory op de systemen. Configureren van een systeem gebeurt dan door het script /opt/openepc/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

87 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

88 Bijlage E. Bedienen van de componenten in OpenEPC 73 E.2 Provisioning van componenten De meeste componenten bewaren hun staat in een databank. Een voordeel hiervan is dat de componenten makkelijk kunnen herstart worden bij het herconfigureren of als er fouten optreden. De provisioning interface is beschikbaar op ( of ( (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.

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

90 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 / configure_system_vars.sh janseeuw@uealice :~$ sudo / opt / OpenEPC / etc / configure_system.sh Which node are you configuring? (epc - enablers,pgw,sgw -mme -sgsn, enodeb, nodeb, epdg,angw, client ): client Which UE do you want to configure? ( alice, bob ) [ alice ]: bob The client can be configured on a real system, using real wireless interfaces, or as inside a virtual machine with simulated interfaces. Configuring the client for which kind of setup? ( virtual, physical ) [ virtual ]: For authentication in non -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

91 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

92 Bijlage G. Configuratiescript van standaard OpenEPC 77 set SGW [ $ns node ] tb -set -node -os $SGW SGW set UEAlice [ $ns node ] tb -set -node -os $UEAlice UEALICE # ################################################### # Lans # ################################################### set mgmt [ $ns make - lan " $ANGw $enodeb $EPCEnablers $epdg $nodeb $PDNGW $SGW $UEAlice " 1000 Mb 0.0 ms] set net - a [ $ns make - lan " $EPCEnablers $PDNGW " kb 0.0 ms] set net - b [ $ns make - lan " $ANGw $epdg $PDNGW $SGW " kb 0.0 ms] set net - d [ $ns make - lan " $enodeb $nodeb $SGW " kb 0.0 ms] set net - umts [ $ns duplex - link $nodeb $UEAlice kb 0.0 ms DropTail ] set net - lte [ $ns duplex - link $enodeb $UEAlice kb 0.0 ms DropTail ] set net - wifi [ $ns duplex - link $epdg $UEAlice kb 0.0 ms DropTail ] set net - wimax [ $ns duplex - link $ANGw $UEAlice kb 0.0 ms DropTail ] # Set ip addresses on mgmt interface tb -set -ip - lan ANGw mgmt " " tb -set -ip - lan enodeb mgmt " " tb -set -ip - lan EPCEnablers mgmt " " tb -set -ip - lan epdg mgmt " " tb -set -ip - lan nodeb mgmt " " tb -set -ip - lan PDNGW mgmt " " tb -set -ip - lan SGW mgmt " " tb -set -ip - lan UEAlice mgmt " " # Set ip addresses on net - a lan tb -set -ip - lan EPCEnablers net -a " " tb -set -ip - lan PDNGW net -a " " # Set ip addresses on net - b lan tb -set -ip - lan PDNGW net -b " " tb -set -ip - lan SGW net -b " " tb -set -ip - lan epdg net -b " " tb -set -ip - lan ANGw net -b " " # Set ip addresses on net - c lan tb -set -ip - link epdg net - wifi " " tb -set -ip - link ANGw net - wimax " " tb -set -ip - link nodeb net - umts " " tb -set -ip - link enodeb net - lte " "

93 Bijlage G. Configuratiescript van standaard OpenEPC 78 # this one is from the DHCP range tb -set -ip - link UEAlice net - wifi " " tb -set -ip - link UEAlice net - wimax " " tb -set -ip - link UEAlice net - umts " " tb -set -ip - link UEAlice net - lte " " # Set ip addresses on net - d lan tb -set -ip - lan SGW net -d " " tb -set -ip - lan nodeb net -d " " tb -set -ip - lan enodeb net -d " " # ################################################### # 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 # ###################################################

94 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

95 Bijlage H. Configuratiescript van OpenEPC met virtuele Alice en Bob 80 tb -set -node -os $SGW SGW set UEAlice [ $ns node ] tb -set -node -os $UEAlice UEALICE set UEBob [ $ns node ] tb -set -node -os $UEBob UEBOB # ################################################### # Lans # ################################################### set mgmt [ $ns make - lan " $ANGw $enodeb $EPCEnablers $epdg $nodeb $PDNGW $SGW $UEAlice " 1000 Mb 0.0 ms] set net - a [ $ns make - lan " $EPCEnablers $PDNGW " kb 0.0 ms] set net - b [ $ns make - lan " $ANGw $epdg $PDNGW $SGW " kb 0.0 ms] set net - d [ $ns make - lan " $enodeb $nodeb $SGW " kb 0.0 ms] set net - umts [ $ns make - lan " $nodeb $UEAlice $UEBob " kb 0.0 ms] set net - lte [ $ns make - lan " $enodeb $UEAlice $UEBob " kb 0.0 ms] set net - wifi [ $ns make - lan " $epdg $UEAlice $UEBob " kb 0.0 ms] set net - wimax [ $ns make - lan " $ANGw $UEAlice $UEBob " kb 0.0 ms] # Set ip addresses on mgmt interface tb -set -ip - lan ANGw mgmt " " tb -set -ip - lan enodeb mgmt " " tb -set -ip - lan EPCEnablers mgmt " " tb -set -ip - lan epdg mgmt " " tb -set -ip - lan nodeb mgmt " " tb -set -ip - lan PDNGW mgmt " " tb -set -ip - lan SGW mgmt " " tb -set -ip - lan UEAlice mgmt " " # Set ip addresses on net - a lan tb -set -ip - lan EPCEnablers net -a " " tb -set -ip - lan PDNGW net -a " " # Set ip addresses on net - b lan tb -set -ip - lan PDNGW net -b " " tb -set -ip - lan SGW net -b " " tb -set -ip - lan epdg net -b " " tb -set -ip - lan ANGw net -b " " # Set ip addresses on net - c lan tb -set -ip - lan epdg net - wifi " " tb -set -ip - lan ANGw net - wimax " " tb -set -ip - lan nodeb net - umts " "

96 Bijlage H. Configuratiescript van OpenEPC met virtuele Alice en Bob 81 tb -set -ip - lan enodeb net - lte " " # this one is from the DHCP range tb -set -ip - lan UEAlice net - wifi " " tb -set -ip - lan UEAlice net - wimax " " tb -set -ip - lan UEAlice net - umts " " tb -set -ip - lan UEAlice net - lte " " tb -set -ip - lan UEBob net - wifi " " tb -set -ip - lan UEBob net - wimax " " tb -set -ip - lan UEBob net - umts " " tb -set -ip - lan UEBob net - lte " " # Set ip addresses on net - d lan tb -set -ip - lan SGW net -d " " tb -set -ip - lan nodeb net -d " " tb -set -ip - lan enodeb net -d " " # ################################################### # 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"

97 Bijlage H. Configuratiescript van OpenEPC met virtuele Alice en Bob 82 # ################################################### $ns rtproto Manual $ns run # ###################################################

98 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

99 Bijlage I. Configuratiescript van minimale OpenEPC met externe Alice en Bob 84 $portbob add - desire SWITCHPORT 1 tb - fix - node $portbob storage1b # ################################################### # Lans # ################################################### set mgmt [ $ns make - lan " $enodeb $EPCEnablers $PDNGW $SGW " 1000 Mb 0.0 ms] set net - a [ $ns make - lan " $EPCEnablers $PDNGW " kb 0.0 ms] set net -b [ $ns make - lan " $PDNGW $SGW " kb 0.0 ms] set net -d [ $ns make - lan " $enodeb $SGW " kb 0.0 ms] set net - lte [ $ns make - lan " $enodeb $portalice $portbob " kb 0.0 ms] # Set ip addresses on mgmt interface tb -set -ip - lan enodeb mgmt " " tb -set -ip - lan EPCEnablers mgmt " " tb -set -ip - lan PDNGW mgmt " " tb -set -ip - lan SGW mgmt " " # Set ip addresses on net - a lan tb -set -ip - lan EPCEnablers net -a " " tb -set -ip - lan PDNGW net -a " " # Set ip addresses on net - b lan tb -set -ip - lan PDNGW net -b " " tb -set -ip - lan SGW net -b " " # Set ip addresses on net - lte lan tb -set -ip - lan enodeb net - lte " " tb -set -ip - lan portalice net - lte " " tb -set -ip - lan portbob net - lte " " # Set ip addresses on net - d lan tb -set -ip - lan enodeb net -d " " tb -set -ip - lan enodeb net -d " " # ################################################### # 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"

100 Bijlage I. Configuratiescript van minimale OpenEPC met externe Alice en Bob 85 tb -set -node - startcmd $PDNGW " sudo bash / proj / OpenEPC / ibcn_scripting / swapin / pdngw_swapin.sh" tb -set -node - startcmd $SGW " sudo bash / proj / OpenEPC / ibcn_scripting / swapin / sgw_swapin.sh" # ################################################### $ns rtproto Manual $ns run # ###################################################

101 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

102 Bijlage J. Configuratiescript voor handover tussen enodeb en NodeB 87 set portenodeb [ $ns node ] $portenodeb add - desire SWITCHPORT 1 tb - fix - node $portenodeb storage1b # ################################################### # Lans # ################################################### set mgmt [ $ns make - lan " $nodeb $enodeb $EPCEnablers $PDNGW $SGW " 1000 Mb 0.0 ms] set net - a [ $ns make - lan " $EPCEnablers $PDNGW " kb 0.0 ms] set net -b [ $ns make - lan " $PDNGW $SGW " kb 0.0 ms] set net - d [ $ns make - lan " $nodeb $enodeb $SGW " kb 0.0 ms] set net - lte [ $ns make - lan " $enodeb $portenodeb " kb 0.0 ms] set net - umts [ $ns make - lan " $nodeb $portnodeb " kb 0.0 ms] # Set ip addresses on mgmt interface tb -set -ip - lan enodeb mgmt " " tb -set -ip - lan nodeb mgmt " " tb -set -ip - lan EPCEnablers mgmt " " tb -set -ip - lan PDNGW mgmt " " tb -set -ip - lan SGW mgmt " " # Set ip addresses on net - a lan tb -set -ip - lan EPCEnablers net -a " " tb -set -ip - lan PDNGW net -a " " # Set ip addresses on net - b lan tb -set -ip - lan PDNGW net -b " " tb -set -ip - lan SGW net -b " " # Set ip addresses on net - lte lan tb -set -ip - lan enodeb net - lte " " tb -set -ip - lan portenodeb net - lte " " # Set ip addresses on net - umts lan tb -set -ip - lan nodeb net - umts " " tb -set -ip - lan portnodeb net - umts " " # Set ip addresses on net - d lan tb -set -ip - lan enodeb net -d " " tb -set -ip - lan nodeb net -d " " tb -set -ip - lan SGW net -d " " # ################################################### # Start - up Scripts # ###################################################

103 Bijlage J. Configuratiescript voor handover tussen enodeb en NodeB 88 tb -set -node - startcmd $EPCEnablers " sudo bash / proj / OpenEPC / ibcn_scripting / swapin / epcenablers_swapin.sh" tb -set -node - startcmd $nodeb " sudo bash / proj / OpenEPC / ibcn_scripting / swapin / nodeb_swapin.sh" tb -set -node - startcmd $enodeb " sudo bash / proj / OpenEPC / ibcn_scripting / swapin / enodeb_swapin.sh" tb -set -node - startcmd $PDNGW " sudo bash / proj / OpenEPC / ibcn_scripting / swapin / pdngw_swapin.sh" tb -set -node - startcmd $SGW " sudo bash / proj / OpenEPC / ibcn_scripting / swapin / sgw_swapin.sh" # ################################################### $ns rtproto Manual $ns run # ###################################################

104 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

105 Bijlage K. Configuratiescript voor handover tussen enodeb en epdg 90 tb - fix - node $portenodeb storage1a set portepdg [ $ns node ] $portepdg add - desire SWITCHPORT 1 tb - fix - node $portepdg storage1b # ################################################### # Lans # ################################################### set mgmt [ $ns make - lan " $enodeb $epdg $EPCEnablers $PDNGW $SGW " 1000 Mb 0.0 ms] set net - a [ $ns make - lan " $EPCEnablers $PDNGW " kb 0.0 ms] set net -b [ $ns make - lan " $PDNGW $SGW $epdg " kb 0.0 ms] set net -d [ $ns make - lan " $enodeb $SGW " kb 0.0 ms] set net - lte [ $ns make - lan " $enodeb $portenodeb " kb 0.0 ms] set net - wifi [ $ns make - lan " $epdg $portepdg " kb 0.0 ms] # Set ip addresses on mgmt interface tb -set -ip - lan enodeb mgmt " " tb -set -ip - lan epdg mgmt " " tb -set -ip - lan EPCEnablers mgmt " " tb -set -ip - lan PDNGW mgmt " " tb -set -ip - lan SGW mgmt " " # Set ip addresses on net - a lan tb -set -ip - lan EPCEnablers net -a " " tb -set -ip - lan PDNGW net -a " " # Set ip addresses on net - b lan tb -set -ip - lan PDNGW net -b " " tb -set -ip - lan SGW net -b " " tb -set -ip - lan epdg net -b " " # Set ip addresses on net - lte lan tb -set -ip - lan enodeb net - lte " " tb -set -ip - lan portenodeb net - lte " " # Set ip addresses on net - umts lan tb -set -ip - lan epdg net - wifi " " tb -set -ip - lan portepdg net - wifi " " # Set ip addresses on net - d lan tb -set -ip - lan enodeb net -d " " tb -set -ip - lan SGW net -d " " # ################################################### # Start - up Scripts

106 Bijlage K. Configuratiescript voor handover tussen enodeb en epdg 91 # ################################################### tb -set -node - startcmd $EPCEnablers " sudo bash / proj / OpenEPC / ibcn_scripting / swapin / epcenablers_swapin.sh" tb -set -node - startcmd $enodeb " sudo bash / proj / OpenEPC / ibcn_scripting / swapin / enodeb_swapin.sh" tb -set -node - startcmd $epdg " sudo bash / proj / OpenEPC / ibcn_scripting / swapin / epdg_swapin.sh" tb -set -node - startcmd $PDNGW " sudo bash / proj / OpenEPC / ibcn_scripting / swapin / pdngw_swapin.sh" tb -set -node - startcmd $SGW " sudo bash / proj / OpenEPC / ibcn_scripting / swapin / sgw_swapin.sh" # ################################################### $ns rtproto Manual $ns run # ###################################################

107 Bijlage L OpenEPC interfaces L.1 UEAlice mac_mgmt = / bin / netstat -ie grep -B1 " " head -n1 awk { print $5} mac_net_wifi = / bin / netstat -ie grep -B1 " " head -n1 awk { print $5} mac_net_wimax = / bin / netstat -ie grep -B1 " " head -n1 awk { print $5} mac_net_umts = / bin / netstat -ie grep -B1 " " head -n1 awk { print $5} mac_net_lte = / bin / netstat -ie grep -B1 " " head -n1 awk { print $5} echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_mgmt ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" mgmt " > / etc / udev / rules.d/70 - persistent - net. rules echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_net_wifi ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" an_wifi " >> / etc / udev / rules.d/70 - persistent - net. rules echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_net_wimax ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" an_wimax " >> / etc / udev / rules.d/70 - persistent - net. rules echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_net_umts ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" an_umts " >> / etc / udev / rules.d/70 - persistent - net. rules echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_net_lte ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" an_lte " >> / etc / udev / rules.d/70 - persistent - net. rules L.2 ANGw mac_ mgmt = netstat - ie grep - B1 " " head - n1 awk { print $5 } 92

108 Bijlage L. OpenEPC interfaces 93 mac_net_b = netstat -ie grep -B1 " " head -n1 awk { print $5 } mac_net_c = netstat -ie grep -B1 " " head -n1 awk { print $5 } echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_mgmt ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" mgmt " > / etc / udev / rules.d/70 - persistent - net. rules echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_net_b ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" net_b " >> / etc / udev / rules.d/70 - persistent - net. rules echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_net_c ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" net_c " >> / etc / udev / rules.d/70 - persistent - net. rules L.3 enodeb mac_ mgmt = netstat - ie grep - B1 " " head - n1 awk { print $5 } mac_net_c = netstat -ie grep -B1 " " head -n1 awk { print $5 } mac_net_d = netstat -ie grep -B1 " " head -n1 awk { print $5 } echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_mgmt ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" mgmt " > / etc / udev / rules.d/70 - persistent - net. rules echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_net_c ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" net_c " >> / etc / udev / rules.d/70 - persistent - net. rules echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_net_d ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" net_d " >> / etc / udev / rules.d/70 - persistent - net. rules L.4 EPCEnablers mac_ mgmt = netstat - ie grep - B1 " " head - n1 awk { print $5 } mac_net_a = netstat -ie grep -B1 " " head -n1 awk { print $5 } echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_mgmt ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" mgmt " > / etc / udev / rules.d/70 - persistent - net. rules echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_net_a ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" net_a " >> / etc / udev / rules.d/70 - persistent - net. rules

109 Bijlage L. OpenEPC interfaces 94 L.5 epdg mac_ mgmt = netstat - ie grep - B1 " " head - n1 awk { print $5 } mac_net_b = netstat -ie grep -B1 " " head -n1 awk { print $5 } mac_net_c = netstat -ie grep -B1 " " head -n1 awk { print $5 } echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_mgmt ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" mgmt " > / etc / udev / rules.d/70 - persistent - net. rules echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_net_b ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" net_b " >> / etc / udev / rules.d/70 - persistent - net. rules echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_net_c ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" net_c " >> / etc / udev / rules.d/70 - persistent - net. rules L.6 PDNGW mac_ mgmt = netstat - ie grep - B1 " " head - n1 awk { print $5 } mac_net_a = netstat -ie grep -B1 " " head -n1 awk { print $5 } mac_net_b = netstat -ie grep -B1 " " head -n1 awk { print $5 } echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_mgmt ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" mgmt " > / etc / udev / rules.d/70 - persistent - net. rules echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_net_a ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" net_a " >> / etc / udev / rules.d/70 - persistent - net. rules echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_net_b ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" net_b " >> / etc / udev / rules.d/70 - persistent - net. rules L.7 nodeb mac_ mgmt = netstat - ie grep - B1 " " head - n1 awk { print $5 } mac_net_c = netstat -ie grep -B1 " " head -n1 awk { print $5 } mac_net_d = netstat -ie grep -B1 " " head -n1 awk { print $5 }

110 Bijlage L. OpenEPC interfaces 95 echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_mgmt ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" mgmt " > / etc / udev / rules.d/70 - persistent - net. rules echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_net_c ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" net_c " >> / etc / udev / rules.d/70 - persistent - net. rules echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_net_d ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" net_d " >> / etc / udev / rules.d/70 - persistent - net. rules L.8 SGW mac_ mgmt = netstat - ie grep - B1 " " head - n1 awk { print $5 } mac_net_b = netstat -ie grep -B1 " " head -n1 awk { print $5 } mac_net_d = netstat -ie grep -B1 " " head -n1 awk { print $5 } echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_mgmt ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" mgmt " > / etc / udev / rules.d/70 - persistent - net. rules echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_net_b ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" net_b " >> / etc / udev / rules.d/70 - persistent - net. rules echo SUBSYSTEM =="net ", ACTION =="add ", DRIVERS =="?*", ATTR { address }== " $mac_net_d ", ATTR { dev_id }== "0x0", ATTR { type }== "1", KERNEL =="eth *", NAME =" net_d " >> / etc / udev / rules.d/70 - persistent - net. rules

111 Bijlage M OpenEPC DNS while [ 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 " >> / etc / resolv. conf echo " nameserver " >> / etc / resolv. conf 96

112 Bijlage N OpenEPC routes naar testnetwerk ip route add /24 via dev cat / var / emulab / boot / controlif ip route add /24 via dev cat / var / emulab / boot / controlif ip route add /24 via dev cat / var / emulab / boot / controlif ip route add /24 via dev cat / var / emulab / boot / controlif ip route del default via dev cat / var / emulab / boot / controlif 97

113 Bijlage O Routeertabellen in OpenEPC Deze routeertabellen zijn bekomen na het verbinden met de enodeb. O.1 UE Na het verbinden met LTE in de Mobility Manager GUI krijgt de UE een default gateway via de enodeb. janseeuw@ uealice :~ $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface UG an_lte UH an_lte U mgmt O.2 enodeb De enodeb gebruikt OpenEPC voor de routering. Met het commando screen -r krijg je toegang tot de Wharf console. In deze console bekom je informatie over de routetabel met de commando s routing.print routes en routing.print ext. 1( 3215) 11: 39: 53 NOTI : console_ loop () :465 > enodeb > routing. print_ routes 1( 3215) 11: 39: 53 WARN : routing_ print_ routes () :68 > IPv4 Source Routing : from / 32 teid 0 via ext teid 86 BD3619 1( 3215) 11: 39: 53 WARN : routing_ print_ routes () :96 > IPv4 Destination Routing : to / 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

114 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 : [ ] IPv6 : [ fc00 :1234:3::29] Routing :[ src dst ] Protocol [0] Interface : [ net_c ] Extension [1] Module Name : [ routing_ gtpu ] IPv4 : [ ] 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 / 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 / 32 teid 86 BD3619 via ext 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 : [ ] IPv6 : [ fc00 :1234:4::20] Routing :[ src dst ] Protocol [0] Interface : [] Extension [1] Module Name : [ routing_ gtpu ] IPv4 : [ ] 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

115 Bijlage O. Routeertabellen in OpenEPC 100 1( 1899) 11: 42: 38 WARN : routing_ print_ routes () :68 > IPv4 Source Routing : from / 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 / 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 : [ ] IPv6 : [ fc00 :1234:2::10] Routing :[ src dst ] Protocol [47] Interface : [] Extension [2] Module Name : [ routing_ raw ] IPv4 : [ ] IPv6 : [ fc00 :1234:1::10] Routing :[ src dst ] Protocol [0] Interface : [ net_a ] Extension [3] Module Name : [ routing_ gtpu ] IPv4 : [ ] IPv6 : [ fc00 :1234:2::10] Routing :[ src dst ] Protocol [0] Interface : []

116 Bijlage P Oplossing voor de HTTP proxy van OpenEPC rm -fr / etc / init.d/ squid rm -fr / usr / sbin / squid ln -s / etc / init.d/ squid3 / etc / init.d/ squid ln -s / usr / sbin / squid3 / usr / sbin / squid rm -fr / etc / squid3 / squid. conf ln -s / opt / OpenEPC / etc / squid / squid. conf / etc / squid3 / squid. conf ln -s / etc / squid3 / etc / squid ln -s / var / log / squid3 / var / log / squid ln -s / var / spool / squid3 / var / spool / squid Hierna start je squid3 opnieuw op. janseeuw@ epcenablers :~ $ sudo restart squid3 Om zeker te zijn dat de HTTP proxy verbonden is met de Rx client om te communiceren met de PCRF kan volgend script uitgevoerd worden. janseeuw@epcenablers :~$ sudo / opt / OpenEPC / bin / squid_rx_logs. attach.sh This is just a tail. Stop with Ctrl - C Trying to connect to port Wharf prompt is: [ Squid Rx Client Console >] Starting

117 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 ~ # set_ ip_ config eth1 IP Address Configuration for eth1 method ( d or s for dhcp or static ): s ip address : default route ( IP address or leave blank ): DNS domain ( leave blank if none ): DNS server ( leave blank if none, use if more than one ): subnet mask ( leave blank if not required ): broadcast address ( leave blank if not required ): Hierna moet het IP van de MME ingesteld worden. Pas wanneer de parameter AdminState op 1 staat begint de cell, na heropstarten, met het uitsturen van zijn signaal. ~# sqlite sqlite > update FAPServiceFAPControlLTEGateway set S1SigLinkServerList = ; sqlite > update FAPServiceFAPControlLTE set AdminState =1 De frequenties en frequencieband kunnen ingesteld worden met een script. ~# set_ radio_ params ~# set_ auto_ start 1 Meer informatie is te vinden in [30, 31, 32]. 102

118 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