Ontwikkeling van een centraal bandbreedte beheersysteem voor internet op de trein

Ontwikkeling van een centraal bandbreedte beheersysteem voor internet op de trein Bram De Valck

Promotor: prof. dr. ir. Ingrid Moerman Begeleiders: Daan Pareit, Nele Gheysens Scriptie ingediend tot het behalen van de academische graad van Burgerlijk elektrotechnisch ingenieur

Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Paul Lagasse Faculteit Ingenieurswetenschappen Academiejaar 2007-2008

VOORWOORD

ii

Voorwoord Het belang van telecommunicatie neemt in onze maatschappij alsmaar toe. Onze eisen in verband met onze bereikbaarheid en de verbindingssnelheden met het internet gaan dan ook in stijgende lijn. In deze evolutie tekent zich echter wel een duidelijke trend af. We willen steeds hogere datasnelheden bij onze frequente steeds snellere verplaatsingen, onafhankelijk van onze geografische positie in het netwerk. Innovaties in mobiele netwerken trachten continu de grenzen van deze drievoudige trade-off te verleggen. Het aanbieden van een breedband internetconnectie voor treinreizigers past ook helemaal binnen deze innovatieve evolutie. Naast de interessante technologische kijk heeft het concept ook een sterke maatschappelijke relevantie. Door de toenemende fileproblematiek maken steeds meer mensen gebruik van het openbaar vervoer en spenderen heel wat tijd op de trein. Als een breedbandige internetconnectie ervoor kan zorgen dat die tijd effeciënter of aangenamer kan worden doorgebracht, zal dit deze evolutie mogelijks nog versterken en versnellen. Uit deze overweging is mijn interesse voor dit thesisonderwerp gegroeid. Deze scriptie is echter niet alleen tot stand gekomen dankzij mijn eigen inzet. Graag zou ik van deze gelegenheid willen gebruik maken om een aantal mensen op de voorgrond te brengen om hen oprecht te bedanken. In de eerste plaats gaat mijn dank uit naar mijn scriptiebegeleiders Daan en Nele. Je kan enkel van puur geluk spreken als je begeleiders telkens weer je mail boordevol vragen binnen de halve dag beantwoorden, je handige tips geven als je het overzicht niet meer ziet en je elk moment mag binnenspringen als het programmeren niet zo vlot verloopt. Daan, zeker jij hebt het de laatste maand hard van me te verduren gekregen maar zelfs tijdens weekends en de laatste uren voor de deadline kon ik op je hulp rekenen. Een heel oprechte ... dank je wel. Ook professor Moerman zou ik willen bedanken voor het gestelde vertrouwen en de vrijgemaakte tijd om een kritisch licht te werpen op mijn voorgestelde oplossingen.

Omdat deze scriptie eveneens kan beschouwd worden als een bekroning van mijn vijfjarige studie tot burgerlijk ingenieur is het ook hier op zijn plaats een bescheiden maar welgemeende dank-je-wel te richten aan mijn ouders. Mama, papa ... zonder al te veel woorden ben ik jullie echt van harte dankbaar voor jullie vertrouwen in mijn kunnen, de nodige aanmoedigingen op de juiste momenten en de kansen en middelen om te doen wat ik nu doe. Ook mijn zussen, Katrien en Marijke, verdienen een bedankinkje voor de leuke omgeving thuis waarin ik me altijd goed voel. En Katrien nog een extra merci’tje voor om je onmiskenbare Groene Boekje-kennis op mijn scriptie los te laten. En als laatste misschien nog een welgemeende merci aan mn naaste vriendenkring. Een opsomming is overbodig... jullie weten maar al te goed wat ik aan wie heb (gehad) om te worden wie ik nu ben. Dank je wel...

Bram De Valck, juni 2008

TOELATING TOT BRUIKLEEN

iv

Toelating tot bruikleen

“De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.”

Bram De Valck, juni 2008

Ontwikkeling van een centraal bandbreedte beheersysteem voor internet op de trein door Bram De Valck Scriptie ingediend tot het behalen van de academische graad van Burgerlijk Ingenieur in de Elektrotechniek: afstudeerrichting Informatie- en Communicatietechnologie Academiejaar 2007–2008 Promotor: Prof. Dr. Ir. I. Moerman Scriptiebegeleiders: Ir. D. Pareit, Ir. N. Gheysens Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie, Voorzitter: Prof. Dr. Ir. P. Lagasse Onderzoeksgroep IBCN, Voorzitter: Prof. Dr. Ir. P. Demeester

Samenvatting In steeds meer situaties, zoals het aanbieden van internet op de trein, wordt een geaggregeerde pakketstroom uitgesplitst over meerdere heterogene verbindingen. De doelstelling van dit werk is de ontwikkeling van een Quality-of-Service beheersysteem die de verdeling van het uitgaande dataverkeer over beschikbare resources (links) op een trein optimaliseert. We ontwerpen hiervoor een component, opgebouwd uit bestaande modules en eigen implementaties. De performantie van deze component wordt nagegaan door uitvoerige testen in een emulatieomgeving.

Trefwoorden Quality of Service, heterogene links, delay, trein

Design of a central bandwidth management system for internet on the train Bram De Valck Supervisor(s): Ingrid Moerman, Daan Pareit, Nele Gheysens Abstract—Offering internet on trains implies that an aggregated packet flow needs to be split up over a set of heterogenous links of different wireless access technologies. In this article we present a Quality-of-Service management system which tries to optimise the distribution of the outgoing traffic over the available resources on the train. Therefore we design a module and verify its performance in an emulation environment. The module effectively provides QoS-measures and performs excellent in almost all scenarios , though additional optimalisations need to be introduced in order to improve the quality of the VoIP-calls. Keywords—Quality of Service, heterogenous links, delay, train

T

Fig. 1. Internal QoS-module composition.

I. I NTRODUCTION

O provide a broadband internet connection on a train, several wireless access technologies are necessary to link the train to the internet. Depending on its position on the traject the train will be able to set up one or more wireless connections to the mainland. Each technology has its typical characteristics regarding to the cost of usage, bandwidth, latency and QoSguarantees, having a different impact on the quality of internet applications experienced by the passengers. In this article we present a Quality-of-Service management system which tries to optimise the distribution of the outgoing traffic over the available resources on the train. By sending the outgoing packets in an intelligent way to the wireless links available on that specific location, taking into account their network properties and the quality requirements of the applications, the quality experienced by the passangers can significantly be improved. The ultimate goal is trying to please as many users as possible as well as possible. The equipment for providing a broadband internet connection on the train consists of a terminal installed on each train and the Central Management System (CMS). The CMS controls the whole network and serves as a proxy for incoming and outgoing connections. The developped QoS modules are part of the gateway on the train terminal and in the CMS. It takes an aggregated data flow which contains packets from all train passengers as input and sends each packet on a specific link. II. A RCHITECTURE The QoS management module is built up out of four building blocks. Figure 1 illustrates the internal composition. 1. The data analyser classifies the packets of the incoming aggregated data flow according to their network requirements in order to give them a separate treatment afterwards. Five QoS classes can be distinguished and the data analyser bases its decision on the source or destination port number. Priority traffic is originating from services with the highest level of priority because of their functionality within the railway system. The interactive class bundles dataflows from real-time applications like

VoIP-calls and videoconferencing with strict delay constraints. Packets for audio- and videostreams contribute to the streaming class with less stringent requirements on delay than the previous class. Best effort traffic mainly consist of HTTP-traffic, but also VPN-connections and chatting messages are part of this class. The least important QoS class is background containing traffic from background services like downloading files and e-mail. 2. Buffers are added to store packets before being allowed by the traffic shaper to be sent. 3. The traffic shapers have the functionality to flatten the bursty data flow in order to avoid a temporal overwhelming of the limited processing power, downstream in the gateway. This task is realised by implementing the Token Bucket algorithm. 4. Once all data flows are conform the specifications a triple decision has to be made: (1)which packet of (2) which QoS class should be sent on (3) which link. Having a important influence on the overall perceived Quality-of-Service of all applications the heterogenous mapping manager carefully implements this task. III. M APPING ALGORITHM Two algorithms are designed to deal with the mapping problem: a raw and a advanced QoS management module. The raw implementation, only developped as a benchmark for the advanced QoS module, is of less importance. A. Raw QoS module The raw implementation takes care no QoS class is assigned to a link with a delay characteristic worse than the class’ delay constraint, unless no such link is available. First, all links are sorted in order of decreasing delay and in case of equal values in order of increasing bandwidth. In the next step, beginning with the most important class priority, the link with the best delay properties available is assigned to this class. If after the assignment some capacitty is left on the link, that link is still in the running for further assignments of the other data flows in the following iteration.

B. Advanced QoS module The algorithm in the advanced QoS module consist of three phases: B.1 Link sorting An identical algorithm for sorting the links as in the raw QoS module is used in this implementation. B.2 Bandwidth reservation The next step calculates the bandwidth a class may reserve on the outgoing links (without taking the delay constraints into account). Based on this bandwidth reservations the troughput rates in the traffic shapers are adjusted. Because of its importance the priority class is treated differently than the other classes. B.2.a priority. In most cases the bandwidth demand of the priority class is unmodified transformed into a reservation, except for the situation when this demand exceeds for more than a predefined precentage of the summed link capacity of all links. If so, the reservation is reduced to this fraction of the total link capacity. B.2.b interactive, streaming, best effort and background. The idea behind the bandwidth reservation of these classes is offering a minimal ensured bandwidth in the case of high load. This minimum fraction of the total link capacity depends on each individual class: interactive (25 %), streaming (25 %), best effort (15 %) and background (5 %). If the actual demand is less than this minimum reservation, the difference adds up to the remaining bandwidth to be mapped. In a next step this unmapped bandwidth is assigned to the classes with a actual demand larger than the predefined minimum reservation. Starting with the interactive class, the shortages of these classes are filled up untill no unmapped bandwidth is left. B.3 Mapping process The mapping process converts the bandwidth reservations into real assignments on the available links. Starting with the class with the most stringent delay constraints (i.d. priority) and the link with the best delay characteristics the algorithm iteratively maps the reservation on the next link in the sorted list. The excess bandwidth of either the link or the flow is their available bandwidth for the next iteration. This mapping process is based on an algorithm developped by Mohanty and Bhuyan [1]. IV. T ESTBED The testbed consists of two machines, representing a passenger and a server, and three machines emulating the network between the train and CMS: train gateway, impairment node (access network) and the CMS gateway. The QoS modules are written in Click Modular Router [2] and run on the train and central gateway. Their performance is verified in two scenarios: 1. a single satellite link 2. a satellite and HSDPA link For each QoS class a typical application is selected: background traffic was generated by iPerf, best effort by HTTP traffic, video was streamed using the EvalVid framework and VoIP-calls were analysed using Opera Voice/Audio Quality Analyser [3]. This way we had objective metrics to compare measurements.

V. R ESULTS A. Single satellite link Evaluating the perceived quality of all applications, the results can be found in table I. The raw QoS module has a similar behaviour to the situation in which no QoS measurements are taken. The reason for this is that the underlying mechanism is for both in this situation is the same. The advanced module on the other hand clearly performs better for the ‘important’ classes (priority, interactive and streaming). As a consequence a quality degradation of the lower classes can be noticed but since worse network characteristics are have less impact on the perceived Quality-of-Service of these classes, this can be justified. TABLE I T HE RAW AND ADVANCED Q O S MODULE IN A SINGLE SATELLITE LINK SITUATION , IN COMPARISON WHEN NO Q O S MEASURES ARE TAKEN

PR

load 250 kbps

IA

60 kbps

ST

677 kbps

BE BA

210 kbps 900 kbps

throughput packet loss PESQ delay throughput packet loss throughput throughput packet loss

no 217 kbps 13 % 2,3 1251 ms 457 kbps 28 % 15 kbps 393 kbps 55 %

raw 211 kbps 15 % 2,3 1260 ms 361 kbps 35 % 15 kbps 535 kbps 39 %

advanced 250 kbps 0% 3,1 456 ms 593 kbps 11 % 13 kbps 79 kbps 78 %

B. Satellite and HSDPA link When evaluating the performance of both modules in a load balancing situation the advanced module leads to better results of all classes except for the VoIP-call: a PESQ-score of 3,3 for the raw module versus only 2,8 for the advanced one. This phenomenon can be explained by taking a closer look to the mapping process. The raw implementation maps all bandwidth reservation on a single link (HSDPA) while the advanced mapping process divides the bandwidth reservation over multiple links (satellite and HSDPA). Since VoIP-calls, and by extension all TCP-connections, care about the correct sequence in which packets arrive and a split of the connection over multiple links with different delay characteristics won’t realise this, a quality degradation and decreased throughput can be noticed. VI. C ONCLUSION The raw implementation is at least as good as the situation in which no QoS-measures are taken. The advanced QoS management modules performs in almost all scenarios even better than the raw variant, though additional optimalisations need to be introduced in order to improve the quality of the VoIP-calls. R EFERENCES [1] Satya R. Mohanty, Laxmi N. Bhuyan On Fair Scheduling in Heterogenous Link Aggregated Services, Computer Communications and Networks, pp. 199-205, 2005. [2] The Click Modular Router Project, http://www.read.cs.ucla.edu/click/ [3] http://www.tkn.tu-berlin.de/research/evalvid/, http://www.opticom.de, http://sourceforge.net/projects/iperf

INHOUDSOPGAVE

viii

Inhoudsopgave Voorwoord

iv

Toelating tot bruikleen

vi

Overzicht

vii

Extended abstract

viii

Inhoudsopgave

x

Gebruikte afkortingen 1 Inleiding 1.1 Internet op de trein . . . . . . . . 1.1.1 Maatschappelijke context . 1.1.2 Marktopportuniteit . . . . 1.2 Probleemstelling . . . . . . . . . 1.3 Doelstelling . . . . . . . . . . . . 1.4 Toepassingsdomeinen . . . . . . . 1.4.1 Linkaggregatie . . . . . . . 1.4.2 Multiprocessors . . . . . . 1.4.3 multi-pad I/O opslag . . . 1.5 Structuur van de scriptie . . . . .

xiii

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

1 1 1 4 5 5 5 5 6 6 7

2 Algemene netwerkarchitectuur 2.1 TR@INS-project . . . . . . . . . . . 2.2 De TR@INS-netwerkarchitectuur . . 2.2.1 Draadloze toegangsnetwerken 2.2.2 Central Management System . 2.2.3 Mobiliteitsbeheermodule . . . 2.3 Het toegangsnetwerk . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

8 8 8 9 10 11 12

. . . . . . . . . .

INHOUDSOPGAVE 3 Interactieomgeving van de QoS-module 3.1 Geaggregeerde pakketstroom . . . . . . . 3.1.1 5 QoS-klassen . . . . . . . . . . . 3.1.2 Gebruikersprofielen . . . . . . . . 3.2 Draadloze technologieën . . . . . . . . . 3.2.1 Satellietcommunicatie . . . . . . 3.2.2 UMTS . . . . . . . . . . . . . . . 3.2.3 HSDPA . . . . . . . . . . . . . . 3.2.4 WiMAX . . . . . . . . . . . . . . 3.2.5 WiFi . . . . . . . . . . . . . . . . 3.2.6 Overzicht . . . . . . . . . . . . . 4 Architectuur van de QoS-module 4.1 Overzicht . . . . . . . . . . . . . . . . . 4.2 Data analyser . . . . . . . . . . . . . . . 4.3 Traffic shaper . . . . . . . . . . . . . . . 4.4 Heterogene link manager . . . . . . . . . 4.4.1 Partitioneringsdetectie algoritme 4.5 Mapping manager . . . . . . . . . . . . . 4.5.1 Generalised Processor Sharing . . 4.5.2 Multi Server Fair Queueing . . . 4.5.3 BestFit . . . . . . . . . . . . . . 4.5.4 Eigen algoritme . . . . . . . . . . 4.5.5 Voorbeeld . . . . . . . . . . . . . 4.6 Pakketscheduler . . . . . . . . . . . . . .

ix

. . . . . . . . . .

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

. . . . . . . . . .

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

. . . . . . . . . .

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

5 Testbed 5.1 Netwerkopstelling . . . . . . . . . . . . . . . . 5.2 Gemodelleerde pakketstroom . . . . . . . . . . 5.3 Applicaties . . . . . . . . . . . . . . . . . . . . 5.3.1 Iperf - background . . . . . . . . . . . 5.3.2 Wget - best effort . . . . . . . . . . . . 5.3.3 EvalVid - streaming . . . . . . . . . . 5.3.4 PESQ-metingen - interactive . . . . . . 5.3.5 Iperf - priority . . . . . . . . . . . . . . 5.3.6 Overzicht van de gebruikte applicaties 5.4 Opbouw van de metingen . . . . . . . . . . . 5.4.1 Testbedscenario’s . . . . . . . . . . . . 5.4.2 Modulaire aanpak . . . . . . . . . . . . 5.4.3 Volgorde van de metingen . . . . . . .

. . . . . . . . . .

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

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

. . . . . . . . . .

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

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

. . . . . . . . . .

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

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

. . . . . . . . . .

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

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

. . . . . . . . . .

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

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

. . . . . . . . . .

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

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

. . . . . . . . . .

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

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

. . . . . . . . . .

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

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

. . . . . . . . . .

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

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

. . . . . . . . . .

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

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

. . . . . . . . . .

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

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

. . . . . . . . . .

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

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

. . . . . . . . . .

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

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

. . . . . . . . . .

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

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

. . . . . . . . . .

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

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

. . . . . . . . . .

13 14 14 17 19 19 19 19 20 20 21

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

22 22 23 24 26 27 28 28 29 30 30 43 46

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

47 47 48 48 49 49 50 50 51 52 52 52 54 57

INHOUDSOPGAVE

x

6 Resultaten 6.1 Enkelvoudige link . . . . . . . . . . . 6.1.1 Ruwe QoS-module . . . . . . 6.1.2 Geavanceerde QoS-module . . 6.2 Load balancing . . . . . . . . . . . . 6.2.1 Ruwe QoS-module . . . . . . 6.2.2 Geavanceerde QoS-module . . 6.3 Migratieproblematiek . . . . . . . . . 6.3.1 Gedegradeerde audiokwaliteit 6.3.2 TCP versus UDP . . . . . . . 6.3.3 Verbeterde aanpak . . . . . .

. . . . . . . . . .

58 58 60 60 61 63 64 65 65 67 69

7 Samenvatting en verder onderzoek 7.1 Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Verder onderzoek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70 70 71

A Code A.1 Click elementen en scripts A.1.1 Click elementen . . A.1.2 Click scripts . . . . A.2 Praktische richtlijnen . . .

74 74 74 75 76

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . .

Bibliografie

77

Lijst van figuren

79

Lijst van tabellen

81

GEBRUIKTE AFKORTINGEN

Gebruikte afkortingen ACK

acknowledgement

AMPS

Advanced Mobile Phone Service

AOL

America Online

BIPT

Belgisch Instituut voor Post en Telecommunicatie

CCTV

Closed Circuit Television

CMS

Central Management System

DECT

Digital Enhanced Cordless Telecommunications

DVB

Digital Video Broadcasting

EDGE

Enhanced Data Rates for GSM Evolution

FIFO

First In First Out

FTP

File Transfer Protocol

GPRS

General Packet Radio Service

GPS

Generalised Processor Sharing

GSM

Global System for Mobile Communications

GSN

GPRS Service Node

HLR

Home Location Register

HDTV

High-Definition Television

HSDPA

High-Speed Downlink Packet Access

HSUPA

High-Speed Uplink Packet Access

HTTP

HyperText Transfer Protocol

HTTPS

HyperText Transfer Protocol Secure

xi

GEBRUIKTE AFKORTINGEN IBBT

Interdisciplinair instituut voor BreedBand Technologie

iDEN

Integrated Digital Enhanced Network

IEEE

Institute of Electrical and Electronics Engineers

IP

Internet Protocol

ISM

Industrial. Scientific. Medical.

ITU

International Telecommunications Union

LAN

Local Area Network

LoS

Line of Sight

MIMO

Multiple Input Multiple Output

MIP

Mobile Internet Protocol

MMORPG

Massively Multiplayer Online Role Playing Game

MOS

Mean Opinion Score

MPEG

Moving Pictures Experts Group

MSC

Mobile Switching Centre

mSCTP

Mobile Stream Control Transport Protocol

MSFQ

Multi Server Fair Queueing

NMBS

Nationale Maatschappij der Belgische Spoorwegen

NMT

Nordic Mobile Telephone

OFDM

Orthogonal Frequency Division Multiplexing

PDC

Personal Digital Communications

PDF

Policy Decision Function

PESQ

Perceptual Evaluation of Speech Quality

PSNR

Peak Signal-to-Noise Ratio

QoS

Quality of Service

RAID

Redundant Array of Independent Disks

RTMP

Real Time Messaging Protocol

RTSP

Real Time Streaming Protocol

RTP

Real Time Protocol

xii

GEBRUIKTE AFKORTINGEN SDTV

Standard-Definition Television

SIP

Session Initiation Protocol

TACS

Total Access Communication System

TCP

Transmission Control Protocol

TLS

Transport Layer Security

TOS

Type of Service

TR@INS

Train IP Network Services

UDP

User Datagram Protocol

UMTS

Universal Mobile Telecommunications System

UTRAN

UMTS Terrestrial Radio Access Network

VoIP

Voice over Internet Protocol

VPN

Virtual Private Network

W-CDMA

Wideband Code Division Multiple Access

WiMAX

Worldwide Interoperability for Microwave Access

xiii

INLEIDING

1

Hoofdstuk 1 Inleiding 1.1 1.1.1

Internet op de trein Maatschappelijke context

Groot aantal treinreizigers Dagelijks maken meer dan 700 000 reizigers gebruik van de Belgische Spoorwegen om hun bestemming te bereiken. Jaar na jaar groeit het aantal pendelaars en brengen dus steeds meer mensen een deel van hun dagelijkse tijd door in een treinrijtuig [1]. De meest populaire tijdverdrijven tijdens een treinreis zijn het lezen van een boek of krant, het luisteren naar muziek, telefoneren en het afhandelen van allerlei zaken voor het werk. [2]. In het licht van de maatschappelijke trend naar een efficiënter en aangenamer tijdgebruik kan een internetconnectie voor vele honderduizenden pendelaars elke dag een meerwaarde zijn voor hun ontspanning, communicatie en werk op de trein.

Overal online Het gebruik van online applicaties en documenten zoals een online raadpleegbare agenda, het opvolgen van beursberichten, de voortdurend beschikbare mailaccount... kent de laatste jaren een sterke groei. De internetgigant Google speelt in op deze trend met zijn online beschikbare Google Apps (zie figuur 1.1).

Figuur 1.1: Enkele Google applicaties.

1.1 Internet op de trein

2

De zakenwereld is in de eerste plaats vragende partij voor een onafgebroken verbinding met het internet. De eerst uitgewerkte oplossingen waren een mix van mobiele smalbandige toegangstechnologieën zoals GSM en GPRS die via hun netwerken een complete dekking van het grondgebied garanderen. Naderhand worden nu ook de snellere -breedbandigeretoegangsnetwerken zoals EDGE, UMTS en HSDPA aangewend om de gebruikerservaring te verbeteren (hogere datasnelheden, stabielere connectie en lagere vertragingstijden). Diverse telecombedrijven zoals Telenet, Proximus en Mobistar trachten hun netwerkoplossing uit te breiden om tegemoet te komen aan de wensen van hun klanten die overal en altijd willen kunnen zijn. Gezien deze service echter een stevige prijskaartje heeft, is hij in de eerste plaats gericht op zakenlui. Bovendien zijn deze oplossingen niet schaalbaar voor een groot aantal gebruikers. Het idee van een onafgebroken connectie met het internet wint echter aan populariteit bij de doorsnee burger. Telecombedrijven bouwen daarom nu continu de dekking en capaciteit van hun netwerk uit om de komende jaren aan de vraag naar mobiel internet te kunnen voldoen.

Figuur 1.2: Mobiele datakaarten van Proximus en Telenet.

Breedbandige connectie Mensen ervaren de wereld rond zich aan de hand van beelden en geluiden, iets wat zich in een gedigitaliseerde wereld vertaalt als video- en audiomateriaal. In de beginjaren van het internet waren websites statische documenten met hoofdzakelijk tekstmateriaal. De trend naar het toevoegen van afbeeldingen, geluidsfragmenten en videoclips zette zich al snel door en dat maakt dat een smalbandige verbinding niet langer volstaat om webpagina’s voldoende snel weer te geven. Bovendien stellen nieuwe internetapplicaties steeds hogere eisen aan hun verbinding met het wereldwijde web. Videoconferencing, gaming, internettelefonie... voor een goede werking hebben deze applicaties nood aan een gegarandeerde minimale bandbreedte en een beperkte vertraging en jitter


3

(de variatie in de vertraging). Breedbandverbindingen zijn met andere woorden een must geworden om de moderne internetgebruiker tevreden te stellen. Binnen een tijdsspanne van enkele jaren zijn de breedbandaanbiedingen in belangrijke mate voordeliger geworden in termen van kostprijs en aangeboden datasnelheden. Volgens een rapport van de ITU [3] bedroeg in juli 2004 de gemiddelde bandbreedte wereldwijd nog ongeveer 256 kbit/s, terwijl die 22 maanden later reeds was toegenomen tot 1,4 Mbit/s. De omgekeerde evolutie speelt zich af in de kostprijs per 100 kbit/s getransfereerde data per maand: over dezelfde periode viel de prijs van ongeveer ¤10 terug op een goede ¤3. Deze tegengestelde evolutie in prijs en beschikbare bandbreedte is weergegeven in figuur 1.3.

Figuur 1.3: Evolutie in de gemiddelde breedbandsnelheden en -prijzen van 133 economieën.

Het idee om de hele dag door verbonden te zijn met het internet via een breedbandverbinding om de tijd productiever of op een aangenamere manier door te brengen, vindt steeds meer ingang bij de vele honderdduizenden dagelijkse treinreizigers. Internetgebruikers hebben nu reeds toegang tot het internet in luchthavens en treinstations via een netwerk van publieke hotspots. Telenet sloot in 2004 een overeenkomst met de NMBS voor de installatie van de publieke access points in verschillende stations. De logische uitbreiding is dan ook het aanbieden van een internetconnectie aan boord. In het beheerscontract tussen de overheid en de NMBS werd alvast het engagement aangegaan om een proefproject hierrond op te starten.


1.1.2

4

Marktopportuniteit

Het aanbieden van een breedbandverbinding met het internet op de trein is geen nieuw idee. Diverse Europese treinmaatschappijen onderzoeken de mogelijkheden voor deze service en in de meeste landen zijn pilootprojecten en zelfs commerciële roll-outs opgestart. Tabel 1.1 [4] lijst een aantal dergelijke projecten op. Ook in België werd de technische haalbaarheid en interesse van treinreizigers en internetgebruikers bekeken. Verschillende studies [2, 5] bevestigen het marktpotentieel voor breedbandinternet op de trein in België. Deze dienst zal waarschijnlijk geen grote populariteit kennen maar een sterk ge¨ınteresseerde nichemarkt biedt ook belangrijke opportuniteiten. startdatum land trial 07/2003 Canada

bedrijf

treinoperator

PointShot / Opti-Fi Icomera

Via Rail

12/2003

VK

02/2005

VK

02/2005

Zweden

Nomad Digital / T-Mobile Icomera

12/2005

Duitsland

T-Systems

08/2006 04/2007

Japan VK

07/2007

VK

Intel / NTT Nomad Digital / T-Mobile Nomad Digital

09/2007

B/F/ NL / D Frankrijk

12/2007

21Net / Siemens / Telenet Orange / Capgemini / Alstom / Eutelsat

toegangstechnologie

1-wegs satelliet CDMA GNER 1-wegs satelliet GPRS/UMTS Southern Railway Pre-WiMAX UMTS/HSDPA SJ 1-wegs satelliet GPRS/UMTS DB UMTS Flash-OFDM Tsukuba Express WiFi Heathrow Express Pre-WiMAX UMTS/HSDPA Virgin Trains Pre-WiMAX UMTS/HSDPA Thalys 2-wegs satelliet Thalys GPRS/UMTS SNCF-TGV Est 2-wegs satelliet

Tabel 1.1: Enkele pilootprojecten en commerciële roll-outs.

1.2 Probleemstelling

1.2

5

Probleemstelling

Om een breedbandige internetconectie op de trein aan te kunnen aanbieden, zijn verschillende draadloze technologieën noodzakelijk om de trein met het internet te verbinden: afhankelijk van zijn locatie (station, platteland ...) zal de trein één of meerdere draadloze verbindingen met het vasteland kunnen opzetten. Elk van deze technologieën heeft andere eigenschappen qua kost, bandbreedte, latentie en QoS-garanties die een verschillende impact zullen hebben op de gebruikerservaring van internetapplicaties zoals websurfing, VoIP, video conferencing...

1.3

Doelstelling

Het doel van de scriptie is de ontwikkeling van een Quality of Service beheersysteem dat de verdeling van het uitgaande dataverkeer over beschikbare resources op een trein optimaliseert. Intelligente sturing van uitgaande datapakketten naar de draadloze technologieën die op die plaats beschikbaar zijn, rekening houdend met hun eigenschappen, hun kostprijs en de kwaliteitseisen van de applicaties, kan de gebruikerservaring van de treinreiziger gevoelig verhogen. Het vooropgestelde doel is trachten zo goed mogelijk aan de behoeften te voldoen van zoveel mogelijk gebruikers.

1.4

Toepassingsdomeinen

Een algemenere formulering van bovenstaande probleemstelling komt in essentie neer op de situatie waarbij concurrerende datastromen -elk met hun specifieke verwerkingseisenwedijveren om verwerking door een beperkt aantal entiteiten. Dergelijke entiteiten kunnen zowel verwerkingseenheden (servers) zijn als transmissielinks. De uitdaging bestaat erin de datastromen te behandelen conform hun kwaliteitseisen en tegelijkertijd de herordening van pakketten binnen één datastroom te minimaliseren. Deze vraagstelling is cruciaal voor applicaties waarbij parallelle communicatiepaden of verwerkingseenheden in het spel zijn. Enkele domeinen waar de multi-server architectuur van toepassing is, worden kort toegelicht.

1.4.1

Linkaggregatie

In datanetwerken worden soms meerdere fysieke verbindingen tussen eenzelfde bron en bestemming gebundeld om het dataverkeer te versturen over de parallelle links. Deze link

1.4 Toepassingsdomeinen

6

aggregatie zorgt naast de toename van beschikbare bandbreedte ook voor een verhoogde betrouwbaarheid van de connectie en de mogelijkheid het verkeer ook te verdelen over de beschikbare links (load balancing). Figuur 1.4 stelt het principe grafisch voor. Diverse ontwikkelaars van netwerkproducten zoals Cisco, 3COM, Adaptec, Hewlett Packard om er enkele te noemen, bieden reeds implementaties aan.

Figuur 1.4: Principe van link aggregatie.

1.4.2

Multiprocessors

Een identieke situatie is terug te vinden in de context van gedistribueerd computing. Rekentaken van een verschillende omvang en prioriteit moeten toegewezen worden door een centrale module aan de verschillende microprocessoren in het netwerk.

1.4.3

multi-pad I/O opslag

In het domein van opslagsystemen wordt een RAID-systeem1 gewoonlijk via meerdere datakanalen verbonden met de host ten behoeve van snelheidswinst en/of beveiliging tegen gegevensverlies. De cruciale vraag is ook hier hoe de data te verzenden over de beschikbare kanalen, rekening houdend met de prioriteit van bepaalde data en specifieke restricties van het opslagsysteem. Redundant Arrays of Independent Disks is de benaming voor een set methodieken voor fysieke dataopslag op harde schijven waarbij de gegevens over meer schijven verdeeld worden, op meer dan 1 schijf worden opgeslagen, of beide. 1

1.5 Structuur van de scriptie

1.5

7

Structuur van de scriptie

Hoofdstuk twee licht de architectuur van het complexe netwerkmodel en zijn belangrijkste componenten toe. In hoofdstuk 3 worden de eigenschappen van de geaggregeerde datastroom bekeken die het QoS-management systeem als input heeft. De inkomende datapakketten kunnen onderverdeeld worden in een aantal QoS-klassen, die elk hun eisen stellen in termen van de typische netwerkparameters (beschikbare bandbreedte, vertraging, variatie op de vertraging...) aan het netwerk waarover ze getransporteerd worden. Verder kunnen een aantal profielen van ingangsdata gedefinieerd worden. Tevens worden de verschillende toegangstechnologiën die de breedbandverbinding met het internet kunnen verzorgen, kort besproken. De kern van deze scriptie is de architectuur en werking van het Quality of Service beheersysteem met een implementatie aan boord van de trein en in het controlecentrum. De interne opbouw van de ontworpen module vormt het onderwerp van hoofdstuk 4. Om de performantie van de ontworpen QoS-management module te valideren, wordt een testbed samengesteld. Hoofdstuk 5 licht de opstelling toe. Vertrekkende van een ruw werkende implementatie wordt de optimale plaatsing van architecturale componenten en parameters afgeleid uit performantiemetingen van de modulaire verbeteringen. Deze materie is het onderwerp van hoofdstuk 6. In een laatste hoofdstuk worden tekortkomingen van de bekomen implementatie toegelicht en geven we enkele suggesties gegeven voor verder onderzoek.

ALGEMENE NETWERKARCHITECTUUR

8

Hoofdstuk 2 Algemene netwerkarchitectuur 2.1

TR@INS-project

Een onderzoeksproject van IBBT1 , het TR@INS-project (Train IP Network Services, 1/04/2006 - 31/03/2008), spitst zich toe op het ontwikkelen van een ge¨ıntegreerde oplossing voor breedbandtoegang voor treinreizigers op de Belgische spoorwegen. De ultieme doelstelling is zowel treinreizigers als treinpersoneel via een continue draadloze internetverbinding zakelijke en entertainment diensten aan te bieden die voldoen aan de noodzakelijke Quality of Service. Het project omvat ook gedetailleerde gebruikersstudies die moeten verzekeren dat de ontwikkelde technologische oplossingen voldoen aan de wensen van de gebruiker. De in deze scriptie ontworpen QoS-management module kan in de TR@INSarchitectuur ingepast worden.

2.2

De TR@INS-netwerkarchitectuur

De TR@INS-netwerkarchitectuur wordt ontwikkeld met het oog op een onafgebroken, voor de treinreiziger transparante, draadloze netwerkverbinding tussen de pendelaar en de breedbanddiensten waar hij gebruik van maakt. De kwaliteit van de verbinding moet intact blijven ook als de reiziger zich verplaatst tussen verschillende rijtuigen en als de trein aan hoge snelheid rijdt. Om deze veeleisende connectie te realiseren, maakt de netwerkoplossing gebruik van verscheidene beschikbare draadloze toegangsnetwerken. Via zachte handovers tussen de heterogene toegangstechnologieën kan een naadloze netwerkverbinding gehandhaafd worden. Figuur 2.1 toont de globale netwerkarchitectuur van het systeem. IBBT, het Interdisciplinair instituut voor BreedBand Technologie, is een onafhankelijke onderzoeksinstelling die in opdracht van de Vlaamse overheid innovatie binnen ICT stimuleert. 1

2.2 De TR@INS-netwerkarchitectuur

9

Figuur 2.1: Fysische netwerkarchitectuur.

2.2.1

Draadloze toegangsnetwerken

Langsheen zijn traject zal de trein verbinding kunnen maken met uiteenlopende toegangstechnologieën. Satellietcommunicatie. De verbinding tussen de satelliet en de trein wijzigt continu. Doordat de trein voortdurend in beweging is, moet de oriëntatie van de antenne voortdurend bijgesteld worden om steeds naar de satelliet gericht te staan. Bovendien belemmeren sommige objecten (hoge gebouwen, tunnels...) de directe verbinding (line of sight) tussen de satelliet en de antenne op de trein. Deze onderbrekingen moeten opgevangen worden door over te schakelen op een ander toegangsnetwerk. Communicatie langs het spoor (trackside). Om andere plaatsen die moeilijk bereikbaar zijn voor satellietsignalen (bijvoorbeeld verstedelijkte gebieden) of om meerdere parallelle verbindingen toe te laten, worden trackside oplossingen uitgedacht. In de eerste plaats worden antennes van reeds aanwezige cellullaire netwerken (UMTS, HSDPA, Mobile WiMAX) in de buurt van de spoorlijn aangewend als toegangstechnologie. Wanneer ook die niet beschikbaar zijn, zal een van deze technologieën daar nog uitgerold moeten worden. Binnen TR@INS werden ook alternatieve, op WiFi gebaseerde, technieken ontwikkeld om eventueel langs het spoor te plaatsen om de voorbijrazende trein dan alsnog van de nodige breedbandconnectie te voorzien.


10

Hotspot in de treinstations. Wanneer de trein eenmaal een station is binnengereden, kan de terminal op de trein verbinding maken met de reeds aanwezige hotspot in dat station.

2.2.2

Central Management System

Het hele netwerk wordt gecoördineerd en gemonitord door het Central Management System (CMS). Zijn belangrijkste taak is het in stand houden van een beveiligde verbinding met de trein via zijn mobiliteitsbeheercomponent. Deze module zet dynamisch transparante IP-tunnels op over de verschillende toegangsnetwerken om de bereikbaarheid van de trein te garanderen, onafhankelijk van diens locatie. Inkomend dataverkeer bedoeld voor een treinreiziger krijgt in de CMS de correcte authenticatie- en routeringsinformatie mee en wordt vervolgens naar de gepaste trein getunneld via de beschikbare connectie(s). In de omgekeerde richting worden de uitgaande datapakketten via een tunnel eerst naar de CMS gerouteerd en van daaruit naar de gepaste bestemming op het internet verzonden. Het ontworpen netwerk valt dus uiteen in twee delen: een vertrouwd (beveiligd) subnetwerk waarbij tunnelling van de datapakketten gebeurt en het publieke internet. Figuur 2.2 illustreert dit tunnelingmechanisme.

Figuur 2.2: IP-tunnel tussen de trein en CMS.


2.2.3

11

Mobiliteitsbeheermodule

Elke terminal op de trein en in de centrale CMS is uitgerust met een mobiliteitsbeheermodule. Functioneel valt deze component uiteen in twee onderdelen: (1) de QoS-module en aggregatie-eenheid op het datavlak die inwerken op respectievelijk de uitgaande en inkomende datastroom en (2) de tunnelmodule op het controlevlak. De interne opbouw van de mobiliteitsbeheermodule en de interactie tussen de verschillende bouwblokken is weergegeven in figuur 2.3.

Figuur 2.3: Interne opbouw van de mobiliteitsbeheermodule en onderlinge interacties van de bouwblokken.

In het controlevlak is de tunnel management module verantwoordelijk voor het opstellen en afbreken van tunnels over de verschillende toegangsnetwerken naar het centrale beheersysteem. Het handover protocol houdt zich bezig met het verzekeren van een connectie tussen de trein en de buitenwereld tijdens een handover. De nodige informatie is daarbij afkomstig van de Policy Decision Function (PDF) die via een continue monitoring de meest geschikte links en tijdstippen voor handover aangeeft. In het datavlak doorloopt inkomend dataverkeer (komend van het lokale netwerk op de trein of van het internet in de CMS) eerst de QoS-management module. Ruwweg wordt het verkeer eerst geanalyseerd en gepartitioneerd in de voorafgedefinieerde QoS-klassen. Rekening

2.3 Het toegangsnetwerk

12

houdend met de QoS-vereisten van deze klassen en de eigenschappen van de uitgaande tunnels (bandbreedte, vertraging...) stuurt de QoS-management module op intelligente wijze datapakketten naar de meest geschikte link. Het optimale design van deze module vormt het onderwerp van deze scriptie. Na transport over de draadloze verbinding(en) worden de verschillende datastromen opnieuw geaggregeerd door de aggregatie-eenheid om via de gateway naar het internet of het lokale treinnetwerk te worden gestuurd.

2.3

Het toegangsnetwerk

De internetconnectie tussen een trein en de CMS op het vasteland kan opgesplitst worden over twee logische netwerken: een toegangsnetwerk en een aggregatienetwerk. Het toegangsnetwerk bundelt alle draadloze interconnectietechnologieën tussen de trein en het vasteland. Het aggegratienetwerk strekt zich uit van gateways van het toegangsnetwerk tot de CMS. Deze scriptie focust op het voorzien van QoS in het toegangsnetwerk (verdeling van de pakketten over de beschikbare links) terwijl ander onderzoek [6, 7, 8] zich toespitst op de concurrerende datastromen in het aggregatienetwerk. Maximale Quality of Service voor de aangeboden multimediadiensten op de trein wordt bekomen wanneer gepaste mechanismen in werking zijn in beide netwerken. Figuur 2.4 illustreert de nodige QoS-voorzieningen op twee niveaus.

Figuur 2.4: QoS-voorziening in het toegangs-en aggregatienetwerk.

INTERACTIEOMGEVING VAN DE QOS-MODULE

13

Hoofdstuk 3 Interactieomgeving van de QoS-module Louter uit praktische overwegingen focussen we voor de rest van de scriptie op de QoSmanagement module in de trein (zie figuur 2.3). De component in de CMS vertoont identiek gedrag en conclusies in het beschouwde geval zijn zonder meer eveneens van toepassing op de QoS-management module in de CMS. Figuur 3.1 situeert de component in zijn werkomgeving.

Figuur 3.1: Situering van de QoS-module.

Internetgebruikers op de trein genereren elk hun datastroom die samengevoegd wordt door de access router tot een geaggregeerde pakketstroom. De blauwdruk van dit verkeer wordt besproken in een eerste deel van dit hoofdstuk 3.1. Na verwerking door de

3.1 Geaggregeerde pakketstroom

14

QoS-module worden de datapakketten verstuurd op de links van de beschikbare toegangsnetwerken. Aangezien de toewijzing van de pakketten naar een bepaalde uitgaande link in belangrijke mate afhangt van de netwerkparameters (bandbreedte, vertraging...) worden de mogelijke technologieën beknopt bekeken in een volgend onderdeel van dit hoofdstuk 3.2.

3.1

Geaggregeerde pakketstroom

De grote diversiteit aan internetapplicaties legt eisen op aan de netwerkverbinding. Voor spraakgerelateerde toepassingen (VoIP, videoconferencing...) zijn lage waarden voor de vertragingstijden van de datapakketten cruciaal. Andere applicaties zoals streaming media eisen een minimale bandbreedte voor een correcte werking. Om een goede gebruikerservaring van elke applicatie te garanderen, wordt dataverkeer afkomstig van veeleisende toepassingen prioritair behandeld ten opzichte van datapakketten met minder strenge netwerkvereisten. Uit praktische overwegingen worden er vijf Quality of Service klassen gedefinieerd die dataverkeer met gelijkaardige netwerkeisen bundelen. Twee belangrijke criteria voor de categorisatie zijn de QoS-netwerkparameters (de nodige bandbreedte, de maximaal toegelaten vertraging, vertragingsvariatie en pakketverlies) en het prioriteitsniveau van de communicatie. In volgorde van de minst naar de meest eisende QoS-klasse worden ze elk kort toegelicht.

3.1.1

5 QoS-klassen

(a) Background Achtergronddiensten zijn applicaties die op de achtergrond lopen van een besturingssysteem. Rechtstreekse interactie van de gebruiker is niet nodig. Typische voorbeelden zijn het downloaden van bestanden en e-mail. Deze applicaties zijn noch gevoelig voor de snelheid noch voor de bandbreedte van de verbinding. Hoe hoger de beschikbare bandbreedte, hoe sneller de bestandsoverdracht zal gebeuren. Alleen wanneer het te lang duurt om emails te verzenden maar vooral om ze te binnen te halen, zal de gebruikerstevredenheid sterk afnemen. Er zijn geen aanbevelingen qua minimale bandbreedte, maximaal toelaatbare vertraging en jitter voor dit type verkeer.


15

(b) Best effort Binnen deze klasse kunnen drie subcategorieën onderscheiden worden. De dienst met het grootste aandeel binnen de best effort-klasse is surfen op het internet. HTTP-verkeer is van nature uit asymmetrisch: slechts een beperkte hoeveelheid informatie wordt naar een server verzonden (uplink) terwijl webpagina’s van de servers aanzienlijk meer informatie (en data) bevatten (downlink). Het bursty karakter van het verkeer maakt ook dat de applicatie flexibel omspringt met de beschikbare bandbreedte en enkel excessief hoge wachttijden storend zijn voor de surfer. VPN-connecties -een tweede toepassing binnen deze klasse- worden aangewend om vanop afstand deel te kunnen uitmaken van een vertrouwd netwerk (met een computer thuis bijvoorbeeld informatie kunnen opvragen van een bedrijfsserver). Controle-informatie over de VPN-verbinding is zeer beperkt maar een connectieverbreking is erg storend: op regelmatige tijdsstippen wordt de connectie gecheckt en bij een storing wordt de VPNverbinding verbroken. Een laatste, zeer populaire applicatie binnen de QoS-klasse is chatting. Chatten opereert met zeer weinig bandbreedte (slechts enkele kilobytes per seconde) en resulteert in symmetrische datastromen. Deze zeer smalbandige dienst functioneert zodra er een netwerkverbinding is opgezet. 200 kbps in downlink en slechts 20 kbps in uplink moet voldoende zijn als bandbreedte. Vertragingstijden en variaties op de vertraging hebben geen invloed op de gebruikerservaring. (c) Streaming Twee grote typevoorbeelden maken deel uit van de QoS-klase streaming: audio- en videostreams. Deze categorie stelt zijn eisen vooral aan een minimale beschikbare bandbreedte. Kleinere vertragingen en vertragingsvariaties zijn eveneens welkom, hoewel buffering een voldoende maatregel kan zijn. Videostreaming vereist meer bandbreedte dan audiostreaming en de benodigde hoeveelheid bandbreedte hangt af van de codec waarmee de beelden geëncodeerd werden. Voor de downlink is een bandbreedte van minimum 1,8 Mbps nodig, voor de uplink amper 50 kbps. Er zijn geen aanbevolen waarden voor de maximale vertraging en jitter.


16

(d) Interactive Beperkte vertragingstijden (maximaal 300 ms end-to-end) en jitter hebben wel een belangrijke impact op internetapplicaties die draaien rond interactiviteit. Ook hier kan buffering aangewend worden in het geval van streamingdiensten maar voor real-time applicaties schiet ook deze oplossing tekort. VoIP-toepassingen (Skype, videoconferencing) en online gaming behoren tot deze klasse die de strengste eisen stelt aan haar netwerkverbinding in termen van QoS-parameters. Voor beide richtingen volstaat een bandbreedte van 700 kbps. De vertraging mag maximaal 300 ms bedragen en jitter 40 ms. (e) Priority De diensten die onder deze categorie vallen, hebben absolute prioriteit over alle andere verkeer gezien hun functionaliteit binnen het spoorwegenstelsel of het TR@INS-netwerk. De communicatie vereist ook een hogere graad van betrouwbaarheid en beveiliging. Het uitwisselen van monitoringinformatie over controlevariabelen in een trein heeft slechts sporadisch nood aan een betrouwbare verbinding (vooral uplink) en consumeert bandbreedte waar nauwelijks mee rekening hoeft gehouden te worden. CCTV -closed circuit television- wordt aangewend om een oogje in het zeil te houden in en buiten treinrijtuigen. De camera’s hebben enkel nood aan een uplinkverbinding om videobeelden naar een controlecentrum op het vasteland te versturen. Er kan geopteerd worden om continu te streamen of slechts op enkel noodzakelijke momenten, wat een belangrijk verschil maakt in de benodige bandbreedte. Communicatie tussen treinpersoneel gebeurt aan de hand van VoIP, waaraan de dezelfde eisen worden gesteld als aan de verbinding bij de interactive QoS-klasse behalve dat deze communicatie voorrang dient te krijgen. De bandbreedte van de downlink hoeft slechts 50 kbps te bedragen terwijl de uplink minimum 700 kpbs verwacht ter beschikking te hebben, 300 ms is de maximaal toegelaten vertraging. Overzicht van de QoS-klassen Onderstaande tabel 3.1 vat de karakteristieke netwerkparameters voor de verschillende QoS-klassen samen.

3.1 Geaggregeerde pakketstroom QoS-klasse

bandbreedte (kbps) bandbreedte (kbps) delay downlink uplink (ms) priority 50 700 300 interactive 700 700 300 streaming 1 800 50 best effort 200 20 background 260 260 -

17 jitter (ms) 40 40 -

Tabel 3.1: Karakteristieke parameters van de verschillende QoS-klassen.

3.1.2

Gebruikersprofielen

Potentiële gebruikers vallen uiteen in twee types: zakenlui en vrijetijdsgebruikers. Het onderscheid wordt gemaakt op basis van hun motivatie voor het gebruik van de breedbandconnectie aan boord. Zakenmensen wensen continu bereikbaar en verbonden te blijven om hun productiviteit te verhogen tijdens het reizen. Vrijetijdsgebruikers daarentegen laten zich eerder leiden door de nieuwe entertainmentmogelijkheden voor een aangenamer verloop van hun treinrit. Beide gebruikersklasses maken meer of minder gebruik van bepaalde internetapplicaties waardoor de gegenereerde datastroom in belangrijke mate kan verschillen. Enkel professionele gebruikers zullen gebruik maken van een VPN-verbinding met het bedrijfsnetwerk en dataverkeer afkomstig van VoIP-calls en videoconferencing zijn in dit gebruikersprofiel prominenter aanwezig. De interesse van vrijetijdsgebruikers gaat vooral uit naar applicaties met een hoge ontspanningsfactor zoals het bekijken of beluisteren van streaming media, online gaming, bloggen en chatten. In tabel 3.2 worden de treinreizigers gecategoriseerd volgens de klasse van het rijtuig waar ze zich in bevinden en het profiel van hun internetverkeer. Tabel 3.3 brengt de interesse voor en gebruik van internetapplicaties in kaart voor beide gebruikersklassen (berekening gebaseerd op een deliverable van het TR@INS-project [2]). Op basis van deze gebruikersinteresses en de blauwdruk van de afzonderlijke pakketstromen van internetapplicaties kunnen profielen van datastromen worden ge¨ıdentificeerd voor diverse scenario’s: elke gebruikersklasse afzonderlijk (zakenlui en vrijetijdsgebruiker), treinreizigers in eerste en tweede klasse en een reële mix zoals de netwerkterminal op de trein moet verwerken. Dit gemodelleerd dataverkeer representeert pakketstromen die door de gebruikers op de trein in de realiteit gegenereerd worden. Ze dienen als input voor de ontwikkelde QoS-management component om de performantie in verschillende scenario’s te beoordelen.


18

RIJTUIGKLASSE eerste klasse 8,55 % tweede klasse 91,34 % GEBRUIKERSPROFIEL zakenlui 17,68 % vrijetijdsbesteder 82,21 % Tabel 3.2: Onderverdeling van de treingebruikers volgens rijtuigklasse en gebruikersprofiel.

BACKGROUND downloading media e-mail BEST EFFORT websurfing reisinformatie opvragen nieuwsflitsen opvragen instant messaging blogging chatting connecteren met bedrijfsnetwerk e-commerce e-banking STREAMING streaming media INTERACTIVE VoIP videoconferencing gaming

zakenlui

vrijetijdsgebruiker

1e klasse

2e klasse

2,65 16,82

12,24 78,21

1,27 8,13

13,63 86,86

16,59 12,57 13,28 8,69 1,07 1,24 17,68 2,72 4,94

77,13 58,41 61,74 40,41 19,05 22,16 32,52 12,6 22,95

8,02 6,08 6,42 4,20 1,72 2 4,30 1,32 2,39

85,68 64,94 68,80 44,85 18,36 21,37 45,94 14,07 25,48

1,13

30,81

2,74

29,23

14,18 5,76 0

7,42 1,14 12,6

1,85 0,59 1,08

19,73 6,30 11,51

Tabel 3.3: Interesse van de treingebruikers voor de verschillende internetapplicaties, uitgedrukt in procenten.

3.2 Draadloze technologieën

3.2

19

Draadloze technologie¨ en

Op het Belgische grondgebied zijn er verschillende draadloze technologieën uitgerold waarmee de trein connectie kan maken met het vasteland. Dit onderdeel licht de mogelijkheden beknopt toe, in appendix ?? worden ze uitgebreider besproken.

3.2.1

Satellietcommunicatie

Een van de diverse toepassingen waarvoor satellieten worden aangewend, is telecommunicatie. Deze satellieten bevinden zich in een geostationaire baan rond de aarde: ze nemen een vaste positie in ten opzichte van het aardoppervlak op 36 000 km hoogte. Een vaste dekking impliceert het voordeel dat er niet tussen meerdere satellieten geschakeld hoeft te worden om het hele traject van een breedbandconnectie te voorzien. De beschikbare bandbreedte per connectie is ook behoorlijk groot. Een belangrijk minpunt is echter dat er een continue rechtstreekse verbinding (line of sight) moet zijn tussen de treinterminal en de satelliet. Door de aanzienlijke afstand die de signalen dienen af te leggen tussen de zender en ontvanger via een satelliet, loopt de vertragingstijd ook al snel op in de honderden milliseconden (typisch 500 ms round-trip time) waardoor een satellietverbinding moeilijk is voor interactieve applicaties.

3.2.2

UMTS

Universal Mobile Telecommunications System (UMTS) is een cellullaire technologie voor mobiele communicatie van de derde generatie (3G). Als opvolger van GSM en GPRS binnen de evolutie van mobiele cellulaire netwerken kunnen er mits de nodige investeringen in het bestaande radiotoegangsnetwerk hogere datasnelheden bekomen worden. Door parallelle verbindingen op te zetten tussen een UMTS-terminal en meerdere basisstations en door zachte handovers kan een grote datathroughput en een naadloze verbinding tijdens de verplaatsing van een gebruiker gerealiseerd worden.

3.2.3

HSDPA

De meest geavanceerde telg binnen de evolutie van mobiele technologieën is HSDPA, HighSpeed Downlink Packet Access. Met minieme opwaarderingen van het bestaande UMTSnetwerk kan deze nieuwe technologie gebruikers hogere datasnelheden (tot 14,4 Mbps) en lagere vertragingstijden (round trip delay van 70 ms) aanbieden.


3.2.4

20

WiMAX

Netwerken van mobiele telecomoperatoren vertrekken van de GSM-standaard met lage bandbreedtes maar een hoge graad van mobiliteit. Datanetwerken daarentegen zijn van in het begin toegespitst op een snelle dataoverdracht maar presteren ondermaats op het vlak van mobiliteit. Vanuit beide benaderingen worden oplossingen ontwikkeld om de klassieke trade-off tussen de verbindingssnelheid en bewegingssnelheid te doorbreken en technologieën die eruit vooruit vloeien, groeien steeds dichter naar elkaar toe. WiMAX -Worldwide Interoperability for Microwave Access- is een specificatie uit de wereld van de datanetwerken, specifieker een certificatielabel voor de IEEE 802.16-standaard. Vertrekkend van een standaard die opereert via line-of-sight verbindingen, worden door continue verbeteringen Quality of Service en mobiliteit nu ook ondersteund in Mobile WiMAX. De theoretische datasnelheden zijn veelbelovend (tot 15 Mbps voor mobiele datatransfers) en ook de vertragingstijden bedragen slechts enkele tientallen milliseconden.

3.2.5

WiFi

Wi-Fi is een certificatielabel (“logo”) voor draadloze datanetwerkproducten, die werken volgens de internationale standaard IEEE 802.11. De IEEE 802.11-standaard wordt voortdurend bijgewerkt en hiervoor worden specifieke werkgroepen opgericht die zich buigen over specifieke ontwikkelingen qua bereik, throughput, veiligheidsmechanismen... De standaard met momenteel de grootste penetratie in de consumentenmarkt is de 802.11g-versie, die volledig achterwaarts compatibel is met vorige versies en beduidend hogere datasnelheden toelaat. De meest recente standaard is de n-versie (802.11n) met verwachte throughput van enkele honderden Mbps. Aangezien het leeuwendeel van de huidig operationele IEEE 802.11-netwerkdevices de g-versie implementeren en de toekomstige IEEE 802.11nstandaard hiermee achterwaarts compatibel is, worden de huidige hotspots het best uitgerust met de g-versie. Wanneer eenmaal 802.11n beschikbaar is, kan geleidelijkaan worden overgeschakeld om een verbinding met een hogere bandbreedte tussen hotspot en trein te kunnen realiseren.


3.2.6

21

Overzicht

Onderstaande tabel 3.4 vat de karakteristieke netwerkparameters voor de verschillende draadloze toegangstechnologieën samen. QoS-klasse satelliet UMTS HSDPA WiMAX WiFi

bandbreedte (kbps) downlink 2 000 384 768 1180 11 000

bandbreedte (kbps) uplink 512 64 320 530 11 000

delay (ms) 240 80 70 22 50

jitter (ms)

Tabel 3.4: Netwerkparameters van de verschillende draadloze toegangstechnologieën, waarbij voor satelliet in de uplink DVB-RCS wordt gebruikt en in de downlink DVB-S2.

ARCHITECTUUR VAN DE QOS-MODULE

22

Hoofdstuk 4 Architectuur van de QoS-module 4.1

Overzicht

De QoS-management module bestaat uit een aantal bouwblokken, die in dit hoofdstuk besproken worden. Figuur 4.1 visualiseert de interne opbouw. De geaggregeerde datastroom, die verkeer van alle treinreizigers en bemanningsleden bundelt, komt de module binnen aan de linkerkant. De QoS-klassen krijgen in het schema een identificatienummer mee (priority - 1, interactive - 2, streaming - 3, best effort - 2, background - 1). Aan de rechterkant van de component bevinden zich de uitgaande links. De niet-beschikbare link wordt in de figuur in stippellijn weergegeven.

Figuur 4.1: Interne opbouw van de QoS-management module.

4.2 Data analyser

4.2

23

Data analyser

Het geaggregeerde dataverkeer dat de QoS-module binnenkomt, wordt door de data analyser ge¨ınspecteerd om de verschillende pakketstromen te identificeren. Figuur 4.2 demonstreert de werking. De twee grote criteria voor de categorisatie van de QoS-klassen waren de QoS-netwerkparameters (de nodige bandbreedte, de maximaal toegelaten vertraging, vertragingsvariatie en pakketverlies) en het prioriteitsniveau van de communicatie. In de data analyser worden dan ook twee mechanismen aangewend om het onderscheid te maken: poortnummers en IP-adressen van bron en bestemming.

Figuur 4.2: Data analyser (classifier).

De QoS-klassen background, best effort, streaming en interactive differentiëren zich van elkaar doordat de applicaties waarvan ze afkomstig zijn verschillende performantieniveaus van het netwerk vereisen. Aangezien internetapplicaties gebruik maken van vaste poortnummers bestaat de meest eenvoudige differentiatie erin de datastroom op basis van bronen bestemmingspoortnummers uit te splitsen. Tabel 4.1 toont welke poortnummers (welke applicaties) toegekend worden aan de verschillende QoS-klassen. Daarnaast bevat de priority-klasse data, afkomstig van verschillende applicaties maar van een beperkt aantal gebruikers, die absolute voorrang moet krijgen op alle andere verkeer. Deze prioriteit kan worden afgedwongen door verkeer van en naar een aantal IPadressen op de trein voorrang te geven. De classificatie zou kunnen gebeuren door de TOS-byte in de IP-header van elk pakket in te vullen. Op die manier kunnen het aggregatie- en corenetwerk ook met eenzelfde

4.3 Traffic shaper INTERACTIVE 3724 5060 5061 6901 STREAMING 554 1935 2979 5004 5005 BEST EFFORT 80 443 531 1863 5050 5190 8080 BACKGROUND alle andere poortnummers ...

24

World of Warcraft MMORPG SIP TCP/UDP TLS over TCP Windows Live Messenger voice RTSP RTMP h263-video RTP RTP HTTP HTTPS AOL instant messenger MSN instant messenger Yahoo! Messenger ICQ and AOL instant messenger HTTP

Tabel 4.1: Toekenning van poortnummers aan QoS-klassen.

classicifatie rekening houden, wat bijdraagt tot een totale end-to-end Quality of Service. In deze scriptie wordt er echter voor gekozen de ToS-byte niet te gebruiken, maar wel de paint-functionaliteit binnen de Click-omgeving. Deze laat toe op een eenvoudige manier pakketten te labelen. Aan elk pakket dat een Click router binnenkomt, wordt ruimte voor annotaties toegekend. Verwerking van de pakketten op basis van deze metadata verloopt veel sneller dan rechtstreekse manipulatie van de pakketten zelf.

4.3

Traffic shaper

Een datastroom heeft dikwijls een bursty karakter, wat betekent dat pakketten in groepen reizen en niet met continu vaste periodes tussen de pakketten. Omdat routers slechts een

4.3 Traffic shaper

25

beperkte verwerkingscapaciteit per tijdseenheid hebben, kan het voordelig zijn de pakketstroom af te vlakken. Op die manier vermijden we temporele piekbelastingen waarbij de capaciteit van de routerelementen niet voldoet en pakketten verloren gaan. Bij traffic shaping gaan dus geen pakketten verloren maar worden ze vertraagd doorgestuurd wanneer de aankomstsnelheid van de pakketten te hoog ligt. Traffic shapers introduceren dus echter wel bijkomende vertraging die voor delay-gevoelige toepassingen (VoIP...) niet gewenst is. Er worden dus geen traffic shapers ge¨ımplementeerd in de datapaden van de QoS-klassen priority en interactive. De streaming-klasse verdraagt ook niet al te veel vertraging maar mits gebruik van een play-out buffer aan de ontvangstzijde die de audio- of videostroom met enige vertraging afspeelt, kan extra delay in het netwerk wel getolereerd worden en is de plaatsing van een traffic shaper mogelijk. Het Click-element BandwidthShaper wordt aangewend om de traffic shaping uit te voeren. Traffic shaping kan worden gerealiseerd op basis van het Token bucket algoritme. De werking wordt schematisch weergegeven in figuur 4.3. Een token bucket wordt opgevuld met een bepaald constant debiet (aantal eenheden per seconde bijvoorbeeld) en heeft een zekere diepte. De eenheden zullen worden gebruikt om de transfer van binnenkomende IPpakketten (met byte-granulariteit) te controleren. Wanneer een pakket binnenloopt met een lengte van 1000 bytes en er zijn 1500 eenheden in de bucket (de huidige opvulhoogte is 1500), dan zal het pakket naar de output van de traffic shaper getransfereerd worden en wordt het aantal tekens in de bucket verminderd met het aantal getransfereerde bytes naar de uitgang (1500-1000). De nieuwe opvulhoogte van de bucket is dus 500 maar de bucket wordt weer opgevuld met een aantal eenheden. Wanneer nu een pakket met een lengte van 2000 bytes arriveert en de bucket bevat slechts 1500 eenheden, dan zal het pakket vertraagd worden (opslag in een buffer) totdat er voldoende eenheden beschikbaar zijn in de bucket om het pakket door te laten. De diepte van de bucket bepaalt de maximale hoeveelheid bytes die in één keer van de input naar de output getransfereerd kunnen worden of met andere woorden de maximale burstgrootte. De opvulsnelheid of het debiet daarentegen legt de gemiddelde bandbreedte vast waarmee data door de traffic shaper heen kan reizen. Policing Naast traffic shaping wordt het Click-element BandwidthShaper in de voorgestelde architectuur ook ingezet om de inkomende datastromen te bewerken tot ze conform een ingestelde specificatie zijn. Pakketten die een datastroom buiten zijn vooropgestelde maximaal toegelaten bandbreedte brengen, gaan verloren. De wachtrij voor het leacky buc-

4.4 Heterogene link manager

26

Figuur 4.3: Token bucket algoritme voor traffic shaping.

ket van het Token bucket-algoritme, weergegeven in figuur 4.3, heeft namelijk een beperkte capaciteit en wanneer pakketten te snel arriveren (bitrate te hoog volgens de specificatie) zal de buffer overlopen. In de datapaden van priority en interactive fungeert de BandwidthShaper enkel als policing module en niet als traffic shaper terwijl in de datapaden van de andere QoS-klassen het Click-element wel beide functies op zich neemt. In de praktijk komt dit echter op hetzelfde neer. In figuur 4.1 kunnen de verschillende traffic shapers ge¨ıdentificeerd worden. Het opvuldebiet van de leaky bucket (de “RATE”-parameter van de BandwidthShaper ) wordt vastgelegd door het algoritme in de mapping manager.

4.4

Heterogene link manager

Wanneer de nodige maatregelen eenmaal getroffen zijn die ervoor zorgen dat de vijf datastromen zich te doen gedragen conform de beschikbare bandbreedtes, moet de beslissing genomen worden (1) welk pakket van (2) welke QoS-klasse verzonden moet worden op (3) welke uitgaande link. Om dit complexe probleem -dat een belangrijke impact heeft op de algemene Quality of Service- aan te pakken, wordt er modulair te werk gegaan. Een eerste bouwblok, de mapping manager, wijst datastromen van QoS-klassen toe aan de uitgaande links. Updates van die toewijzingen gebeuren op aangeven van het partitioneringsdetectiealgoritme. De mapping manager samen met het partitioneringsalgoritme vormen de heterogene link manager. Wanneer de mapping van de vijf datastromen op de uitgaande

4.4 Heterogene link manager

27

links is doorgevoerd, zijn meerdere QoS-klassen toegewezen aan eenzelfde link en/of is een QoS-klasse verdeeld over meerdere uitgaande links (figuur 4.4). In het eerste geval dient een derde component, de pakketscheduler, over de volgorde te beslissen waarmee pakketten van concurrerende datastromen op die ene uitgaande link verstuurd zullen worden.

Figuur 4.4: Meerdere QoS-klassen gemapt op één link en één QoS-klasse toegewezen aan meerdere links.

4.4.1

Partitioneringsdetectie algoritme

De toewijzing van de QoS-klassen aan de links wordt op regelmatige tijdstippen herbekeken. In het ideale scenario vallen die momenten telkens net na de verzending van een pakket op een uitgaande link. De voorwaarde om over te gaan tot partitionering is eenvoudig: wanneer een link inactief wordt, moet nagegaan worden of het stel datastromen niet veranderd is sinds de laatste partitioneringsinstantie. Bij een wijziging moet de linktoewijzing herberekend worden. Ondanks de beschikbaarheid van algoritmen met lage complexiteit voor de sortering en vergelijking van verschillende datastromen is deze aanpak uitgesloten. De check moet namelijk gebeuren elke keer als een pakket verzonden is en de nodige rekencapaciteit is niet voorhanden bij verbindingen met hoge datasnelheden. Mohanty en Bhuyan [9] stellen daarop een eenvoudig maar efficiënt algoritme voor. Het algoritme maakt gebruik van twee wachtrijen: een verdwijningswachtrij (VQ - Vanish Queue) en een aankomstwachtrij (AQ - Arrival Queue) met respectievelijke groottes van N (het aantal uitgaande links) en 1. Wanneer een nieuwe datastroom arriveert, gaat het algoritme eerst na of de datastroom aanwezig is in de VQ. Indien dit het geval is, dan wordt die entry eruit verwijderd (de datastroom verdween slechts tijdelijk). Komt de datastroom nu niet voor in de VQ en is de AQ leeg, dan wordt een entry gemaakt in de AQ. In het andere geval wordt er geen verdere actie ondernomen in het partitioneringsdetectie algoritme.

4.5 Mapping manager

28

Het voorgestelde algoritme stemt de momenten waarop de linktoewijzing moet worden herbekeken af op de veranderingen in de datastromen van de verschillende QoS-klassen. Dit is minder frequent dna na elke verzending van een pakket de toewijzing opnieuw te berekenen. Het aantal en de beschikbaarheid van de uitgaande links worden hierbij impliciet constant verondersteld. In het scenario van een snel bewegende trein waarbij de terminal op de trein voortdurend nieuwe verbindingen opzet met andere toegangsnetwerken, gaat deze veronderstelling niet langer op. De veranderingen in de datastromen zijn dan niet langer doorslaggevend voor de toewijzing van de links, maar wel de wijzigingen in het stel uitgaande links (nieuw beschikbaar of wegvallen). De eigen Click-elementen mapping scheduler raw en mapping scheduler optimal herbekijken enkel de mapping wanneer er links bijkomen of wegvallen. (Deze veranderingen zullen in ons testbed geëmuleerd worden door het oproepen van handlers in de Click code.)

4.5

Mapping manager

De toewijzing van QoS-klassen aan links komt neer op het omzetten van de vraag naar bandbreedte van de individuele QoS-klassen naar effectieve reservaties op de verschillende uitgaande links. De redenering om tot een optimaal algoritme te komen, start bij de ge¨ıdealiseerde situatie van Generalised Processor Sharing (GPS).

4.5.1

Generalised Processor Sharing

Stel dat φi de bandbreedtereservatie is verbonden met datastroom i en B(t) het stel daP tastromen op tijdstip t, dan is φi (t) = φi / j∈B(t) φi de fractie van de totale beschikbare bandbreedte die datastroom i nodig heeft op tijdstip t. GPS is een werkbewaringsdiscipline die als volgt beschreven kan worden: Wi (t, t + τ ) is het aantal getransfereerde bits van datastroom i door het GPS-systeem in het tijdsinterval [t, t + τ ]. Dan verzekert GPS voor om het even welke datastromen i,j dat Wi (t, t + τ ) φi (t) ≥ Wj (t, t + τ ) φj (t) waar is voor het tijdsinterval [t, t + τ ] waarin het stel van datastromen niet veranderd is. Dit is enkel mogelijk als we aannemen dat pakketten oneindig ondeelbaar zijn. In realiteit is het dus niet mogelijk bovenstaande ongelijkheid op elk tijdstip in stand te houden en moeten er inspanningen geleverd worden om het GPS-systeem te benaderen.

4.5 Mapping manager

4.5.2

29

Multi Server Fair Queueing

In het scenario van meerdere parallelle links moet, zoals reeds aangebracht, niet alleen beslist worden in welke volgorde de pakketten verstuurd moeten worden maar eveneens op welke link dat moet gebeuren. Blanquer en Ozden [10] baseren hun oplossing, Multi Server Fair Queueing, op het GPS-systeem. MSFQ selecteert het pakket dat als eerste zou worden verzonden in het geassocieerde GPS-systeem en stuurt het over de link die het eerst opnieuw beschikbaar wordt. Hierbij wordt het QoS-probleem met meerdere parallelle links gereduceerd tot de GPS-situatie met slechts één link waarbij de geaggregeerde linkcapaciteit de som is van de individuele beschikbare uitgaande links. Figuur 4.5 illustreert deze visie.

Figuur 4.5: Systeemmodel (links) en geaggregeerd systeem (rechts).

MSFQ houdt echter onvoldoende rekening met specifieke aspecten verbonden aan parallel beschikbare verbindingen. Variërende pakketgroottes van de datastromen en ongelijke bandbreedtes van de heterogene links kunnen leiden tot een sterke degradatie van de effectieve throughput. Li en Brassil [11] bestudeerden de invloed van een onzorgvuldig mapping en scheduling beleid op de performantie van een TCP-connectie. Ze beschouwden het scenario van twee heterogene links die een geaggregeerde verbinding vormen waarover een TCP-connectie wordt aangelegd. Een belangrijke vaststelling hierbij is dat de effectieve throughput over de geaggregeerde verbinding lager kan zijn dan in het geval waarbij enkel de traagste link gebruikt wordt. Pakket herordening ligt aan de basis van dit probleem. Een voorbeeld ter illustratie: pakket pk is een pakket van maximale lengte van datastroom i. Stel dat pk nu net het volgende geselecteerde pakket is dat het systeem verlaat en dat de enige beschikbare link die is met de laagste datasnelheid (bandbreedte). Korte tijd δ, (δ ≈ 0) nadat deze link is toegewezen als transportmedium voor dit pakket, worden alle andere links inactief en komen een groot

4.5 Mapping manager

30

aantal pakketten van datastroom i aan met minimale pakketlengte. Worden die kleinere pakketten nu via snellere uitgaande links verzonden, dan bestaat er een reële kans dat die later verstuurde pakketten eerder de bestemming bereiken dan dat ene grote pakket. Herordening van pakketten wordt in de hand gewerkt door de migratie van een datastroom. Migratie is een fenomeen waarbij pakketten van eenzelfde logische netwerkverbinding niet alle over eenzelfde link verstuurd worden, maar versreid worden over meerdere parallelle links. De migratiegraad van een datastroom is het aantal links waarover de bandbreedtereservatie van die datastroom verdeeld is. Hoe hoger de migratiegraad, hoe groter de kans op pakketherordening.

4.5.3

BestFit

MSFQ houdt dus geen rekening met de individuele bandbreedtereservatie van de verschillende datastromen en over hoeveel links die reservatie verdeeld is. Mohany en Bhuyan [9] stellen daarom een alternatief algoritme voor: BestFit (met FirstFit als eenvoudigere variant). Het achterliggende idee is het zoeken naar een match tussen de bandbreedtereservatie van de individuele datastromen (vraag) en de effectief beschikbare bandbreedte op de links (aanbod). Deze mapping moet op een zodanige manier gebeuren dat elke individuele stroom een faire behandeling krijgt en zijn bandbreedtereservatie minimaal verdeeld is over de links. Het algoritme tracht datastromen met een grote vraag naar bandbreedte te mappen naar snellere links (met hoge bandbreedtes) aangezien die stromen de sterkste neiging zullen hebben te migreren (en pakketherordening te veroorzaken). BestFit gaat hierbij recursief te werk door telkens de datastroom met de grootste vraag naar bandbreedtereservatie te mappen op de link met de grootste resterende bandbreedte. De overtollige bandbreedte van ofwel de link ofwel de datastroom is diens beschikbare bandbreedte voor de volgende iteratie.

4.5.4

Eigen algoritme

Een algoritme dat de optimale toewijzing van datastromen aan uitgaande links uitvoert, moet goed scoren op de onderstaande vier criteria: 1. De onderlinge hi¨ erarchie van de datastromen (QoS-klassen) moet gewaarborgd blijven. Verkeer van de priority-klasse is belangrijker dan verkeer van de andere QoSklassen en dient dan ook een voorkeursbehandeling te krijgen. 2. Elke QoS-klasse bundelt datapakketten van applicaties met een gelijkaardige maximaal toegestane waarde voor de vertraging. Om de gebruikerstevredenheid te

4.5 Mapping manager

31

maximaliseren moet ervoor gezorgd worden dat datastromen met striktere delayvereisten gemapt worden op links met kleine waarden voor de vertraging. 3. Pakketherordening moet geminimaliseerd worden om de effectieve throughput van connecties over de geaggregeerde verbinding te maximaliseren. Het algoritme dient maateregelen te treffen om het migratieprobleem aan te pakken. 4. Ondanks onderlinge prioriteitsverhoudingen tussen verschillende QoS-klassen blijft het ultieme doel zoveel mogelijk gebruikers zo goed mogelijk tevreden te stellen. Wanneer toewijzing van een hoeveelheid bandbreedte aan een hogere QoSklasse slechts een minieme verbetering van de gebruikerservaring zou impliceren, terwijl toekenning van die bandbreedte aan lagere QoS-klassen een belangrijke verbetering van de tevredenheid zou teweeg brengen, moet er geopteerd worden voor het tweede scenario. Een algoritme dat maximaal scoort op alle criteria tegelijkertijd bestaat echter niet. Op bepaalde punten in de opbouw van het algoritme zullen dus keuzes gemaakt moeten worden die een bepaald criterium ten goede komen maar een ander negatief be¨ınvloeden. Een goede afweging van de mogelijkheden samen met een gefundeerde argumentatie van de gekozen optie is dan ook aan de orde. Het BestFit algoritme neemt beperkingen op de vertraging van de datastromen niet op in zijn beslissing over de toekenning van de bandbreedtereservaties. Binnen de TR@INSomgeving komen de datastromen echter overeen met elk een verschillende QoS-klasse waarbij het niet halen van harde deadlines qua vertraging een belangrijke impact heeft op de gebruikerservaring. Omdat het BestFit-algoritme ondermaats scoort op het delay-criterium kan het niet functioneren binnen de QoS-management module op de trein. Enkele gebruikte principes kunnen echter wel toegepast worden in een nieuw algoritme dat hiervoor speciaal wordt ontworpen. Het nieuwe algoritme bestaat uit drie grote fasen. In een eerste stap worden de uitgaande links gesorteerd volgens twee criteria (vertraging en bandbreedte). Vervolgens vormt men de ogenblikkelijke vraag naar bandbreedte van de verschillende datastromen om naar bandbreedtereservaties op de links. Na afloop van deze stap is echter nog niet bekend op welke uitgaande links de datastromen gemapt zullen worden. Een laatste fase houdt dan de effectieve toekenning in van QoS-klassen aan uitgaande links. In wat volgt worden deze drie fasen grondiger doorgelicht om een duidelijk zicht te krijgen op de aanpak en impact van de gemaakte keuzes.

4.5 Mapping manager

32

A. Sortering uitgaande links De lijst met uitgaande links wordt gesorteerd volgens stijgende latentiewaarde en bij gelijke vertragingswaarde volgens dalende bandbreedte. Na sortering bevinden de links met de kleinste delay zich bovenaan op de lijst en van alle links met de kleinste delays bevindt deze met die grootste bandbreedte zich bovenaan. Een correcte volgorde is belangrijk voor het verdere verloop van het algoritme, wat in de derde fase (4.5.4) toegelicht zal worden. Het stroomdiagram van de sorteringsfase is weergegeven in figuur 4.6.

Figuur 4.6: Stroomdiagram van de sorteringsfase.

B. Bandbreedtereservaties Het doel van deze tweede stap, die voor elke klasse de nodige bandbreedte reserveert, is dat de uiteindelijke bandbreedtereservaties na afloop een canonische partitie vormen die voldoet aan twee voorwaarden: 1. De totale bandbreedte toegekend aan een QoS-klasse op de verschillende links is gelijk aan zijn toegekende bandbreedtereservatie. 2. De som van de bandbreedtes toegekend aan verschillende datastromen op één link is niet groter dan de bandbreedtecapaciteit van die link.

4.5 Mapping manager

33

De canonische eigenschap garandeert dat wanneer het algoritme eindigt, er geen resterende bandbreedte meer is die niet gemapt is. Hieronder wordt uitgelegd hoe de tweede stap in het mappingproces verloopt. Priority-klasse De toekenning van bandbreedte aan de priority-klasse verloopt afzonderlijk van de bandbreedtereservatie voor de andere QoS-klassen. Op die manier krijgt de belangrijkste klasse de voorkeursbehandeling die het verdient: in zowel goede omstandigheden(totale vraag naar bandbreedte is kleiner dan de beschikbare bandbreedte) als slechte (totale vraag naar bandbreedte is groter dan de beschikbare bandbreedte) kan een instelbare minimale bandbreedte verzekerd worden. De pseudocode van dit onderdeel van het algoritme is hieronder weergegeven.

Figuur 4.7 licht de bandbreedtereservatieprocedure voor de priority-klasse toe. Eerst wordt er nagegaan of de totale vraag naar bandbreedte van alle QoS-klassen de totale beschikbare capaciteit aan bandbreedte overstijgt. Bij negatief antwoord zal de vraag naar bandbreedte van de priority-klasse onveranderd worden omgezet in een effectieve reservatie van deze bandbreedte. Deze onveranderde toewijzing van de vraag naar bandbreedte brengt de reservaties van andere klassen immers niet in gevaar. Overstijgt de totale vraag aan bandbreedte echter de totale capaciteit, dan gaat men na of de vraag naar bandbreedte van deze klasse meer dan een opgegeven percentage van de totale beschikbare capaciteit bedraagt. In het gepresenteerde algoritme leggen we dit instelbaar percentage vast op 80%. Een onderbouwde reden voor dit percentage is niet voorhanden maar intu¨ıtief kan aangevoeld

4.5 Mapping manager

34

worden dat priority-verkeer een groot gedeelte van de beschikbare capaciteit mag innemen en dat slechts een kleine fractie dient verdeeld te worden over de minder belangrijke klassen (verkeer van treinreizigers). Bij een overschrijding wordt slechts die voorafgedefinieerde fractie van de beschikbare bandbreedte toegewezen aan de priority-klasse. Dat betekent dat wanneer er onvoldoende capaciteit voorhanden is om aan de vraag van alle QoS-klassen te voldoen, de priority-klasse toch tot 80% van de uitgaande links mag inpalmen. Indien de vraag van de priority-klasse lager is dan de maximale 80% van de uitgaande links, dan wordt ook nu weer enkel de vraag naar bandbreedte ongewijzigd omgezet naar een bandbreedtereservatie.

Figuur 4.7: Verschillende scenario’s bij de bandbreedtereservatie van de priority-klasse.

Interactive, Streaming, Best effort en Background-klasse Het achterliggende idee bij de reservatie van bandbreedte is het garanderen van een minimale bandbreedte voor elke QoS-klasse bij hoge belasting van de links (wanneer de totale vraag naar bandbreedte groter is dan de totale beschikbare capaciteit). Bovenop die minimaal gegarandeerde bandbreedte wordt nog bijkomende bandbreedte toegekend aan de QoS-klassen afhankelijk van de prioriteit van de klasse, de vraag naar extra bandbreedte en het overschot aan niet-toegekende bandbreedte van de links. De toekenning van bandbreedte aan de resterende QoS-klassen(interactive, streaming, best effort en background ) wordt in de volgende paragrafen gedetailleerd besproken en de pseudocode van dit stukje wordt hieronder weergegeven.

4.5 Mapping manager

35

Voor elk van de vier overblijvende QoS-klassen wordt een minimaal gegarandeerd percentage van de totale resterende linkcapaciteit vastgelegd (i.e. de totale linkcapaciteit - de bandbreedte ingenomen door de priority-klasse). In tabel 4.2 kan men deze bijdragen terugvinden. Wanneer de som van de vraag naar bandbreedte voor de verschillende klassen de totale capaciteit overstijgt, betekent dat dat 70 % van de geaggregeerde linkcapaciteit vastgelegd is voor de verschillende datastromen. De overige 30% zal in een latere stap van dit onderdeel nog verdeeld worden. Door deze aanpak garandeert het algoritme een

4.5 Mapping manager

36

minimale prestatie van de QoS-klassen (70 % van de totale linkcapaciteit vastleggen) maar blijft er ruimte en voldoende flexibiliteit om in te spelen op de vraag naar meer bandbreedte van de individuele klassen (overige 30 %). Interactive 25 % Streaming 25 % Best Effort 15 % Background 5 % 70 % Tabel 4.2: Minimaal gegarandeerde percentages voor vier QoS-klassen.

Men gaat nu na wat de minimaal absoluut gegarandeerde bandbreedte is voor elk van de QoS-klassen door de procentuele bijdrages te berekenen van de totale linkcapaciteit. Er moet echter op gelet worden dat die totale beschikbare bandbreedte reeds verminderd is met de gereserveerde bandbreedte voor de priority-klasse. In een volgende stap wordt deze minimale bandbreedte vergeleken met de effectieve vraag naar bandbreedte voor elke klasse. Wanneer de vraag naar bandbreedte van een datastroom kleiner is dan de voorziene minimaal gegarandeerde bandbreedte, hoeft slechts deze vraag naar bandbreedte toegekend te worden als gereserveerde bandbreedte voor deze klasse. Het verschil in bandbreedte tussen de minimale bandbreedtegarantie en de effectieve vraag (zogenaamd overschot) wordt bij de niet-toegekende bandbreedte gevoegd (waar de niet-gemapte 30 % van de totale linkcapaciteit reeds deel van uitmaakt). Als voorbeeld: een klasse heeft 800 kbps als minimaal gegarandeerde bandbreedte maar vraagt slechts 500 kpbs aan als bandbreedtereservatie, wat impliceert dat er een 300 kpbs “overschot” is aan bandbreedte.

-

800 kbps minimaal gegarandeerd 500 kpbs aangevraagd 300 kbps “overschot”

Wanneer deze verschilberekening voor elk van de vier QoS-klassen is afgelopen, bestaat de niet-toegekende bandbreedte uit de som van de overtollige bandbreedtes en de 30 % van de totale linkcapaciteit die niet als minimaal gegarandeerde bandbreedte werd toegekend. Bijvoorbeeld 300 kbps overtollige bandbreedte van klasse 2, 200 kpbs overtollige bandbreedte van klasse 4 samen met 30 % van de totale linkcapaciteit (1100 kbps) geeft 1600 kbps nog toe te kennen bandbreedte.

4.5 Mapping manager

37

300 kbps overschot van klasse 2 200 kpbs overschot van klasse 4 + 600 kbps (30 % van de totale linkcapaciteit) 1100 kbps nog toe te kennen bandbreedte

Dit surplus aan bandbreedte dient verdeeld te worden over de QoS-klassen met een vraag groter dan de minimaal gegarandeerde bandbreedte. Er bestaat enige vrijheid in deze toekenning. Een eerste optie bestaat erin deze bandbreedte evenredig te verdelen volgens het aandeel van de vraag van de individuele klassen in de totale vraag naar bandbreedte van alle klassen samen. Stel dat klassen 1 en 3 een respectievelijke vraag hebben van 1200 kbps en 720 kbps, respectievelijk 30 % en 18 % van de totale gesommeerde vraag en stel dat 30 ) de resterende nog toe te kennen bandbreedte 1100 kbps bedraagt, dan wordt 1100 ∗ ( 30+18 18 kbps toegekend aan klasse 1 en 1100 ∗ ( 30+18 ) kbps aan klasse 3. Dit voorbeeld is hieronder weergegeven in tabelvorm (alle bitrates zijn uitgedrukt in kbps). QoS-klasse

1 2 3 4

vraag minimaal overschot effectief extra naar gegarandeerde toegekende bandbreedte bandbreedte bandbreedte 1200 400 -800 687,5 100 400 300 0 720 240 -480 412,5 80 280 200 0

totale reservatie 1087,5 100 652,5 80

Het voordeel van deze optie is dat er sterk rekening wordt gehouden met de individuele vraag naar bandbreedte van de QoS-klassen. Intu¨ıtief zou men verwachten dat met deze aanpak zoveel mogelijk gebruikers tevreden worden gesteld. Als namelijk veel gebruikers verkeer genereren dat binnen eenzelfde QoS-klasse past, zal deze klasse ook veel bandbreedte toebedeeld krijgen en zal dat grote aantal gebruikers een betere performantie ervaren. Maar de onderlinge prioriteit van de QoS-klassen ten opzichte van elkaar wordt hierdoor wel naar de achtergrond verdrongen. Is de vraag naar bandbreedte van de background -klasse namelijk vele keren groter dan die van de interactive-klasse, dan zal de lagere QoS-klasse meer bandbreedte (en dus voorrang) krijgen hoewel de hogere QoS-klasse een grotere prioriteit heeft. De tweede optie voor de verdeling van het surplus aan bandbreedte respecteert wel de prioriteit. Voor elke QoS-klasse waarvan de vraag groter is dan de minimaal gegarandeerde

4.5 Mapping manager

38

bandbreedte wordt dan nagegaan hoeveel bijbekomende bandbreedte er nodig is bovenop de minimaal gegarandeerde bandbreedte om aan de vraag te voldoen. In hiërarchische volgorde te beginnen met de belangrijkste QoS-klasse wordt het tekort van elke klasse opgevuld met de nog niet toegekend bandbreedte, totdat er geen niet-gereserveerde bandbreedte meer overblijft. Toelichting met hetzelfde voorbeeld als de eerste optie, is hieronder weergegeven (alle bitrates zijn opnieuw uitgedrukt in kbps). QoS-klasse

1 2 3 4

vraag minimaal overschot effectief extra naar gegarandeerde toegekende bandbreedte bandbreedte bandbreedte 1200 400 -800 800 100 400 300 0 720 240 -480 300 80 280 200 0

totale reservatie 1200 100 540 80

Op basis van de bandbreedtereservaties van de verschillende datastromen wordt het opvuldebiet van de token buckets in de traffic shapers ingesteld. Eenmaal voorbij de traffic shapers kan gegarandeerd worden dat er geen pakketten meer verloren gaan in de QoSmanagement module aangezien de inkomende datastroom in de mapping manager zodanig herschaald werd dat al zijn pakketten een plaats vinden in een uitgaande link. C. Effectieve mapping Nu voor elke QoS-klasse geweten is hoeveel bandbreedte ze in totaal mag innemen op de uitgaande links, is een laatste stap het verdelen van die gereserveerde bandbreedte over de beschikbare links. Aan de toewijzing van QoS-klassen aan uitgaande links zijn er vrijheidsgraden gerelateerd die een cruciale impact hebben op de Quality of Service van alle dataverkeer. Een onzorgvuldige mapping kan alle voorgaande maatregelen om de Quality of Service te optimaliseren, volledig kelderen. Het mapping proces dient daarom met de nodige aandacht bestudeerd te worden. Na afloop van deze stap weet elke QoS-klasse op welke uitgaande links zijn datastroom gemapt is. Of vanuit het standpunt van de links bekeken, kan de link achterhalen van welke klassen hij pakketten verstuurt. De pseudocode van het laatste deel van het algoritme is hieronder terug te vinden.

4.5 Mapping manager

39

In een eerste fase van het algoritme (zie onderdeel 4.5.4A) werd de lijst van uitgaande links gesorteerd. Het belangrijkste criterium daarbij was de delay en bij gelijke waarde voor de vertraging werd er gekeken naar de bandbreedte. Na sortering bevinden de links met de kleinste delay en grootste bandbreedte zich bovenaan op de lijst, de links met de grootste delay en kleine bandbreedte bengelen onderaan. Het mappingproces gaat van start door in volgorde van prioriteit, te beginnen met de belangrijkste QoS-klasse (priority), te kijken hoeveel gereserveerde bandbreedte van de klasse nog niet is toegekend aan een uitgaande link. Vervolgens selecteert men de link bovenaan op de lijst die nog resterende bandbreedte heeft (bandbreedte die niet toegekend is aan een bepaalde QoS-klasse). Na toewijzing van de resterende fractie op de link wordt de overtollige bandbreedte van ofwel de link ofwel de datastroom diens beschikbare bandbreedte voor de volgende iteratie. Figuur 4.8 licht de werkwijze toe. De afweging tussen het halen van harde deadlines qua vertraging versus de prioriteit van de QoS-klassen leidt tot de keuze voor een bepaalde aanpak van het mappingproces. In wat

4.5 Mapping manager

40

Figuur 4.8: Mappingproces waarbij de vraag naar bandbreedte groter is dan de resterende bandbreedte op de link (links) of omgekeerd (rechts).

volgt worden de twee gevallen bekeken waar het ene criterium belangrijker wordt geacht dan het andere en uit de conclusies volgt de keuze van één aanpak. In een eerste geval worden de delaybeperkingen van de verschillende QoS-klassen vooropgesteld als belangrijkste criterium. Het respecteren van de delayvereisten van de QoS-klassen betekent dat een bandbreedtereservatie op een link slechts zin heeft wanneer de typische delay van die link kleiner is dan de maximaal toegelaten delay van de QoS-klasse. Fracties gereserveerde bandbreedte van een QoS-klasse mappen op een link die niet voldoet aan de vertragingseisen is dus uit den boze. Aangezien bij de bandbreedtereservatie in de tweede fase van het algoritme geen rekening werd gehouden met delaybeperkingen, moet deze opnieuw worden bekeken. Dit herbekijken houdt twee acties in. Ten eerste moet de gereserveerde fractie bandbreedte van de QoS-klasse die niet op een geschikte link kan worden gemapt, opnieuw vrijgegeven worden zodat die verdeeld kan worden over de QoS-klassen met minder strikte delay-eisen. De redenering voor deze verdeelsleutel kan op dezelfde manier gebeuren als bij de verdeling van het surplus aan bandbreedte in de tweede fase van het algoritme (zie pagina 37). Ten tweede moet de bandbreedtereservatie van de betreffende QoS-klasse en de klassen met striktere delay-eisen herschaald worden zodat de som van de bandbreedtereservaties van die individuele QoS-klassen gelijk is aan de som van de linkcapaciteiten met een maximale delay kleiner dan of gelijk aan die van de beschouwde QoS-klasse. Figuur 4.9 visualiseert deze acties. In het tweede geval, waarbij de prioriteit van de QoS-klassen primeert op de strikte delayeisen van de klassen, wordt er niet meer geraakt aan de bandbreedtereservaties wanneer

4.5 Mapping manager

41

Figuur 4.9: Aanpak van het mappingprobleem met de delaybeperkingen als belangrijkste criterium (eerste geval).

de tweede fase van het algoritme eenmaal is afgelopen. Wanneer een fractie gereserveerde bandbreedte van een QoS-klasse niet anders gemapt kan worden op de link met een latentiewaarde hoger dan toegestaan voor die klasse, dan zal dit ook effectief gebeuren. In figuur 4.10 wordt deze aanpak visueel voorgesteld.

Figuur 4.10: Aanpak van het mappingprobleem met de prioriteit van de QoS-klassen als belangrijkste criterium (tweede geval).

Ondanks het feit dat de deadlines van de delay overschreden zullen worden voor sommige pakketten, zal de algemene gebruikerservaring beter zijn dan wanneer de eerst voorgestelde aanpak wordt gehanteerd. Een voorbeeld ter illustratie: Neem de situatie waarbij er enkel priority- en background -verkeer aanwezig is in de geaggregeerde datastroom. Er zijn ook

4.5 Mapping manager

42

slechts twee uitgaande links beschikbaar waarbij de beste voldoet aan de delayvereisten van de priority-klasse maar de andere niet. Bovendien volstaat de capaciteit van de beste link niet om alle priority-verkeer te transporteren. In het eerste geval zal alle priority-verkeer enkel op de beste link verstuurd worden, hoe beperkt diens bandbreedtecapaciteit ook is. Het aantal pakketten van de priority-klasse dat door de traffic shaper in de mapping manager toegelaten zal worden, zal dus beperkt zijn. Wanneer er call admission control ge¨ımplementeerd is, zullen slechts weinig gesprekken mogelijk zijn, zij het wel met een goede kwaliteit. In het tweede geval worden bij call admission control veel meer calls toegelaten maar moeten die inboeten aan kwaliteit. Aangezien het belangrijker is veel calls toe te laten met een mindere performantie dan een beperkt aantal met een goede kwaliteit (zeker wat de priority-klasse betreft), geniet de tweede aanpak de voorkeur voor implementatie in het algoritme. Het voorbeeld is gevisualiseerd in figuur 4.11.

Figuur 4.11: Illustratie van afweging tussen delaybeperkingen en de prioriteit van de QoSklassen.

De hiërarchische selectie van de QoS-klassen voor de mapping (beginnen met hogere QoSklassen afdalend naar lagere QoS-klassen) in combinatie met de lijst van uitgaande links die in de eerste plaats gesorteerd is volgens delay, garandeert dat (1) de prioriteit van de QoS-klassen gehandhaafd blijft en (2) de delaybeperkingen van de klassen zo goed mogelijk gerespecteerd worden. Door op een tweede niveau van sortering de links met de grootste bandbreedte bovenaan te plaatsen, worden de nodige inspanningen geleverd om de migratie van de datastromen binnen de perken te houden. In de mate van het mogelijke tracht dit derde onderdeel van het algoritme datastromen met een grote vraag naar bandbreedte te mappen naar snellere links (met hoge bandbreedtes) aangezien die stromen de sterkste neiging zullen hebben te migreren (en pakketherordening te veroorzaken). Het relatief groter balng van het delaycriterium ten opzichte van de migratieproblematiek uit zich in

4.5 Mapping manager

43

het feit dat er eerst op delay gesorteerd wordt en pas later volgens bandbreedte.

4.5.5

Voorbeeld

Ter illustratie van het algoritme wordt een specifieke situatie uitgewerkt. In dit scenario bevat de geaggregeerde datastroom verkeer van de 5 QoS-klassen waarvan tabel hieronder links de parameters weergeeft die van belang zijn in het algoritme (maximaal toegelaten delay en ogenblikkelijke vraag naar bandbreedte). De opgegeven waarden zijn echter fictief. Er zijn eveneens een achttal uitgaande verbindingen beschikbaar, waarvan de eigenschappen die van belang zijn in het algoritme opgelijst zijn rechts in onderstaande tabel. Ook deze links zijn louter illustratief bedoeld en vormen geen representatie van bestaande technologieën voor toegangsnetwerken. QoS-klasse PR IA ST BE BA

delay (ms) 200 600 700 800 10000

bandbreedte (kbps) 2000 1400 1100 800 220 7120

ID 1 2 3 4 5 6 7 8

delay (ms) 700 500 100 800 200 1000 100 600

bandbreedte (kbps) 200 700 700 900 800 2000 1000 500 6800

De lijst met uitgaande links dient nu gesorteerd te worden: eerst volgens stijgende waarde voor de delay en bij gelijke vertragingswaarde volgens dalende bandbreedte. Na afloop van dit proces bevinden de links met de kleinste delay en de grootste bandbreedtecapaciteit zich bovenaan in de lijst, de links met grote delay en kleine bandbreedte zijn onderaan terug te vinden. Een correcte sortering ziet eruit als volgt:

4.5 Mapping manager

44 ID 7 3 5 2 8 1 4 6

delay (ms) bandbreedte (kbps) 100 1000 100 700 200 800 500 700 600 500 700 200 800 900 1000 2000

Het reserveren van bandbreedte voor de verschillende QoS-klassen start met de afzonderlijke behandeling van de priority-klasse. De gesommeerde vraag naar bandbreedte bedraagt 7120 kbps maar slechts een totale capaciteit van 6800 kbps is beschikbaar op de uitgaande links. Niet alle pakketten die in QoS-module aankomen, zullen dus op de uitgaande links verstuurd worden. Een tweede stap bij de toekenning van gereserveerde bandbreedte aan deze klasse bestaat erin na te gaan wat de verhouding is van de priorityvraag ten opzichte van de totale linkcapaciteit. Deze blijkt slechts 29 % (2000 kbps/6800 kbps) te bedragen, lager dan de maximaal vooropgestelde 80 %, wat betekent dat de volledige vraag naar bandbreedte van de priority-klasse omgezet wordt in een effectieve reservatie. Er wordt dus 2000 kbps bandbreedte gereserveerd voor priority-verkeer en 4800 kbps blijft over voor de vraag van de andere QoS-klassen. In een volgende stap wordt de bandbreedtereservatie van de overige QoS-klassen (interactive, streaming, best effort en background ) doorgevoerd. Aangezien 2000 kbps gereserveerd werd voor de priority-klasse blijft er nog 4800 kbps van de totale linkcapaciteit over voor de andere klassen. De minimaal gegarandeerde bandbreedtes voor de verschillende QoSklassen komen dan neer op: interactive: 1200 kbps (25 %) streaming: 1200 kbps (25 %) best effort: 720 kbps (15 %) background: 240 kbps (5 %)

Vergelijking van deze minimaal gegarandeerde bandbreedtes met de effectieve vraag naar bandbreedte van elk van de klassen leert dat de streaming- en background -klasse minder

4.5 Mapping manager

45

bandbreedte aanvragen dan dat er voor hen voorzien was. De overtollige bandbreedte, respectievelijk 100 en 20 kbps, kan samen met de 30 % nog niet toegekende bandbreedte (1440 kbps) voor een totaal van 1560 kbps toegekend worden aan de klassen interactive en best effort. Het tekort (verschil tussen de vraag en de minimaal gereserveerde bandbreedte) van deze klassen bedraagt respectievelijk 500 en 1380 kbps. De resterende, nog te mappen bandbreedte wordt in een eerste iteratie aangewend om het tekort van de interactiveklasse op te vullen. Na deze iteratie blijft er nog 1060 (1560-500) kbps over om het tekort aan bandbreedte van de best effort-klasse op te vangen. Deze resterende bandbreedte blijkt jammer genoeg niet te volstaan om het volledige verschil te compenseren. Niet alle pakketten van de best effort-klasse die in de QoS management module arriveren, zullen dus naar een een uitgaande link getransfereerd kunnen worden. Onderstaande tabel visualiseert de bandbreedtereservaties (alle bitrates zijn uitgedrukt in kbps). QoS-klasse

PR IA ST BE BA

vraag minimaal overschot naar gegarandeerde bandbreedte bandbreedte 1700 1100 2100 220

1200 1200 720 240

(-500) 100 (-1380) 20 +1440 (30 %) 1560

effectief extra effectieve toegewezen reservatie bandbreedte 2000 500 1700 1100 1060 1780 220

Toelichting bij de vierde kolom van bovenstaande tabel: de negatieve waarden duiden een tekort aan bandbreedte aan om aan de vraag van die QoS-klasse te kunnen voldoen. Ze mogen niet opgeteld worden bij de resterende nog toe te kennen bandbreedte, vandaar ook de haakjes. Op basis van deze bandbreedtereservaties worden de QoS-klassen dan als laatste stap gemapt op de uitgaande verbindingen. Figuur 4.12 stelt dit proces grafisch voor.

4.6 Pakketscheduler

46

Figuur 4.12: Mappingproces van de beschouwde situatie.

4.6

Pakketscheduler

Pakketten van verschillende QoS-klassen die door de mapping manager naar eenzelfde uitgaande verbinding gestuurd worden, komen in eenzelfde FIFO-wachtrij terecht. Door de traffic policing en de mapping scheduling is gegarandeerd dat pakketten een faire behandeling krijgen volgens hun toegekende bandbreedte op de uitgaande link.

TESTBED

47

Hoofdstuk 5 Testbed 5.1

Netwerkopstelling

Om de performantie van de ontwikkelde Quality of Service module te evalueren, dient een testbed te worden samengesteld dat een realistische treinomgeving reflecteert. Alle machines draaien Linux, behalve de VoIP-clients die onder Windows werken. Figuur 5.1 toont het schema van de opstelling.

Figuur 5.1: Schema van het testbed.

Aan de linkerkant bevinden zich twee machines die elk een laptop van een passagier of mobiele terminal van een bemanningslid representeren. Een aantal applicaties die een

5.2 Gemodelleerde pakketstroom

48

breedbandconnectie vereisen, draaien op deze machines en aan de hand van hun gebruikerservaring zal de performantie van de ontworpen component bepaald worden. We lichten deze applicaties toe in onderdeel 5.3 van dit hoofdstuk. Een switch verbindt de toestellen met de gateway op de trein. Op deze component draait de ontworpen QoS module en zijn er twee netwerkinterfaces naar het vasteland aanwezig. Om de verschillende draadloze technologieën en toegangsnetwerken te emuleren, plaatsen we een instelbare module tussen de trein en de CMS. Die module is gebaseerd op het Click modular router platform en kan aangepast worden om de gewenste connectiescenario’s te emuleren (één link met verschillende eigenschappen of twee paralelle links). Aan de rechterzijde van de opstelling is de instelbare module met de CMS-machine verbonden, die een identieke QoS-management module draait als die op de treingateway. Een switch connecteert de twee machines die als communicatiepartner van de treinreizigers fungeren met de CMS en vat als het ware de hele routering doorheen het internet samen.

5.2

Gemodelleerde pakketstroom

In het onderdeel 3.1.2 van hoofstuk 3 werden gebruikersinteresses afgeleid waarmee samen met de blauwdruk van afzonderlijke pakketstromen van internetapplicaties, profielen van datastromen ge¨ıdentificeerd kunnen worden. Uit praktische overwegingen worden dergelijke kunstmatige datastromen niet geconstrueerd. Het kost namelijk relatief veel moeite om een realistische datastroom te genereren met de juiste verhoudingen van QoS-klassen, representatieve pakketgroottes, interarrivaltijden... Een voldoende representatieve en duidelijk tijdsefficiëntere oplossing bestaat erin gedurende een bepaalde periode alle webverkeer van een aantal gebruikers te loggen, terwijl ze gebruik maken van de typische netwerkapplicaties. Enkel pakketten van de priority QoS-klasse zijn hier van nature niet aanwezig maar dit kan gesimuleerd worden door verkeer van een bepaalde gebruiker te prioritiseren.

5.3

Applicaties

Met elk van de vijf QoS-klassen (background, best effort, streaming, interactive, priority) stemt een applicatie overeen waarmee de QoS management module voor die applicatiecategorie geëvalueerd wordt.

5.3 Applicaties

5.3.1

49

Iperf - background

Om de tevredenheid van de background QoS-klasse na te gaan, wordt er gebruik gemaakt van Iperf. Iperf is in staat een netwerk(connectie) te belasten met TCP- of UDPdatastromen en op basis van meetgegevens de performantie van het netwerk te bepalen. Het is open source software die draait op diverse platformen zoals Linux, UNIX en Windows. Het programma werd ontwikkeld door het National Laboratory for Applied Network Research [12] en het wordt momenteel ondersteund door open source programmeurs op SourceForge.net [13]. Het programma rapporteert de effectieve throughput, de jitter en het pakketverlies van de aanwezige datastromen. Aan de hand van deze netwerkparameters zullen we de tevredenheid van de background -klasse evalueren. De Iperf-client draait op de de server van de opstelling en stuurt pakketten naar de Iperf-server, die zich op de passagier -machine bevindt. Op die manier wordt de download van bestanden via ftp gesimuleerd. In ons referentiescenario sturen we 3 parallelle UDP datastromen vanuit de client met een aangevraagde bandbreedte van respectievelijk 400 kbps, 900 kbps en 1,3 Mbps gedurende 30 seconden.

5.3.2

Wget - best effort

De meest voor de hand liggende applicatie die deel uitmaakt van de best effort-klasse is websurfing. Wget [14] , onderdeel van het GNU-project1 , is een eenvoudig maar krachtig computerprogramma om content van webservers te halen. Het ondersteunt het downloaden van bestanden via HTTP, HTTPS en FTP, de meest gebruikte TCP/IP-gebaseerde protocollen voor webbrowsing. De complete webpagina van De Standaard Online [www.DeStandaard.be] wordt opgeslagen op de server van de opstelling. Dit nieuwsportaal vormt een representatieve weergave van een typisch bezochte website (tekst, afbeeldingen en video). De passagier -machine haalt de webpagina (bestaande uit 57 afzonderlijke objecten) binnen gebruik makend van Wget (zonder te cachen). De belangrijkste parameters zijn hier de throughput en de responsiviteit (tijd om een webpagina te downloaden). 1

een groots project rond de ontwikkeling en het gebruik van vrije software

5.3 Applicaties

5.3.3

50

EvalVid - streaming

EvalVid [15] is een raamwerk voor de kwaliteitsevaluatie van video verstuurd over een reëel of gesimuleerd netwerk. Naast het opmeten van klassieke netwerkparameters van het onderliggende netwerk (zoals pakketverlies, delay ...) is eveneens een subjectieve evaluatie van de ontvangen video mogelijk. EvalVid wordt in onze opstelling dan ook aangewend om de gebruikerservaring van de streaming-klasse in kaart te brengen. Op de server -machine die het videobestand naar de passagier -machine streamt, worden een aantal bestanden gegenereerd opdat de evaluatie zou kunnen plaatsvinden. Het videobestand in ruwe data (yuv-formaat) wordt eerst gecomprimeerd tot een MPEG-4 videostroom en vervolgens samen met een extra track (die een mogelijke verdeling in pakketten voor transport over RTP/UDP beschrijft) in een MP4-container ondergebracht. Daarnaast hebben we ook nood aan een refentiebestand dat de videobeelden bevat zoals die na transport over een foutloos en perfect netwerk ontvangen zou worden, om deze te kunnen vergelijken met de effectief ontvangen video. Door het gecodeerde yuv-videobestand opnieuw te decoderen, wordt een dergelijk referentiebestand bekomen. Na het streamen van de videostroom en het opvangen van de verzonden en ontvangen pakketten, aan respectievelijk zender- en ontvangstzijde, kan op basis van de gegenereerde bestanden de videokwaliteit beoordeeld worden (PSNR2 -waarden en MOS3 -scores). Deze metrieken reiken een objectieve maatstaf aan om de waargenomen videokwaliteit te relateren aan de typische netwerkparameters delay, jitter en pakketverlies. Figuur 5.2 illustreert opeenvolging van acties binnen EvalVid. Voor deze testopstelling wordt gebruik gemaakt van de ‘Akiyo’ videosequentie [16], die via UDP over het netwerk gestreamd wordt. Hoewel de bitrate niet constant wordt verondersteld, zorgt de beperkte beweging van de nieuwslezeres in de videostroom ervoor dat de uitgezonden bitrate slechts minimaal varieert van de gemiddelde waarde van 677 kbps.

5.3.4

PESQ-metingen - interactive

Het interactive applicatie scenario wordt getest door een VoIP-verbinding op te zetten tussen een treinreiziger (“VoIP-client op de trein”) en zijn gesprekspartner op het vasteland, aan de hand van SIP-client X-lite [17]. Vanop deze laatste machine wordt een Peak singal-to-noise ratio (PSNR) is de verhouding van het maximale signaalvermogen en het ruisvermogen dat de betrouwbaarheid van het nuttig signaal aantast. 3 De Mean Opinion Score (MOS) geeft een numerieke indicatie van de waargenomen kwaliteit van media na compressie en/of transmissie 2

5.3 Applicaties

51

Figuur 5.2: Schematische opbouw van het EvalVid-raamwerk.

spraakfragment over de connectie verzonden naar de passagier -machine. De conversatie wordt opgevangen aan de ontvangstzijde en hierop worden PESQ4 -metingen uitgevoerd om de kwaliteit van de verzonden spraak op een objectieve manier te beoordelen. Hiervoor wordt gebruik gemaakt van de OPERA Voice/Audio Quality Analyser van het Duitse bedrijf Opticom [18]. De PESQ-score brengt de kwaliteitsdegradatie ten gevolge van pakketverlies en pakket herordening in rekening. Deze score in combinatie met de gemeten mouth-to-ear vertraging tussen de twee eindpunten moet leiden tot conclusies betreffende de gebruikerservaring over het gesprek.

5.3.5

Iperf - priority

Priority-verkeer bestaat uit communicatie tussen bemanningsleden, videostromen van veiligheidscamera’s en monitoringinformatie. Om een dergelijke typische datastroom te emuleren, is de logische keuze opnieuw het opzetten van een telefoongesprek via VoIP (communicatie tussen treinbegeleiders op verschillende treinen bijvoorbeeld). Uit praktische overwegingen (bijkomende installatie van een SIP-client op de passagier -machine en omslachtige verwerking van de ontvangen spraak) opteren we er echter voor verkeer van een Perceptual Evaluation of Speech Quality is een geavanceerde kwaliteitsstandaard voor audio- en spraakmetingen in telecommunicatie. 4

5.4 Opbouw van de metingen

52

andere applicatie te prioritiseren. De eenvoudigste optie is Iperf waarbij we een datastroom van de server -machine verzenden naar een zelf gekozen poort op de passagier -machine. De data analyser in de QoS-module zal dan alle verkeer gezonden naar die ene poort op de passagier -machine het priority-label toekennen. De Iperf-datastroom uitgezonden naar deze poort moet vanzelfsprekend een betere perfomantie hebben dan die van de backgroundklasse. De aangevraagde bandbreedte van de priority-stroom bedraagt 250 kbps tenzij anders aangegeven bij de metingen.

5.3.6

Overzicht van de gebruikte applicaties

Tabel 5.1 vat de gebruikte applicaties voor de verschillende QoS-klassen en hun belangrijkste parameters samen. applicatie PR Iperf IA X-lite ST EvalVid BE Wget BA Iperf Iperf Iperf

bandbreedte 250 kbps 60 kbps 677 kbps 210 kbps 400 kbps 900 kbps 1300 kbps

TCP / UDP UDP UDP UDP TCP UDP UDP UDP

Tabel 5.1: Samenvatting van de gebruikte applicaties en belangrijke parameters.

5.4 5.4.1

Opbouw van de metingen Testbedscenario’s

Twee scenario’s Om de prestatie van de QoS-management module te valideren, wordt zijn gedrag geëvalueerd in twee scenario’s. De geaggregeerde datastroom die de QoSmodule dient te verwerken, blijft in beide situaties dezelfde maar het stel uitgaande links en hun eigenschappen wijzigen. In een eerste scenario is er slechts één verbinding beschikbaar om na te gaan hoe de QoS-module de beschikbare linkcapaciteit over de vijf klassen verdeelt. Hiervoor opteren we voor een satellietverbinding. Deze connectie wordt gekarakteriseerd door een grote bandbreedte (2 Mbps downlink, 512 kbps uplink) maar heeft


53

tevens een grote waarde voor de latentie (240 ms uplink en 240 ms downlink). Bij de tweede situatie zijn een satellieten HSDPA-verbinding simultaan beschikbaar. Hierdoor kan nagegaan worden hoe de QoS-management module omgaat met belastingverdeling (load balancing) van de datastromen over de beschikbare links. Tabel 5.2 zet de drie scenario’s nog even op een rijtje. satelliet HSDPA bandbreedte uplink 512 kbps 320 kbps bandbreedte downlink 2 Mbps 768 kbps delay uplink 240 ms 70 ms delay downlink 240 ms 70 ms

scenario’s 1. enkel satelliet 2. satelliet en HSDPA

Tabel 5.2: Linkeigenschappen (links) en testbedscenario’s (rechts)

Linksimulatie De machine die de beschikbare verbindingen van toegangsnetwerken simuleert, draait een Click-script om zijn taak te volbrengen. In de vereenvoudigde variant van het script (zonder dump- en print-instructies) laat men een pakket komende van een bepaalde netwerkinterface eerst in een buffer wachten tot het toegestane moment van verzending, vastgelegd door de opgegeven parameters (vertraging en bandbreedte). F romDevice(eth1)− > Queue− > LinkU nqueue(delay, bandbreedte)− > T oDevice(eth3) De grootte van deze wachtrij heeft echter ook een invloed op de ervaren netwerkverbinding voor de verschillende applicaties. Een grote buffer zal niet snel leiden tot pakketverlies maar impliceert wel een grotere delay voor pakketten achteraan in de wachtrij. Opdat de linksimulator een correcte weerspiegeling van de realiteit zou zijn, dient het aantal plaatsen van de wachtrij gedimensioneerd te worden. De bepaling van de buffergroottes is gebaseerd op de tijd die een pakket nodig heeft om doorheen het toegangsnetwerk te reizen. Uitgaande van een 1 seconde transfertijd (wat nog steeds een behoorlijke overschatting is) worden bufferlengtes voor de vier verschillende wachtrijen (satelliet downlink, satelliet uplink, HSDPA downlink, HSDPA uplink) bekomen in tabel 5.3. De berekening van het aantal plaatsen voor de buffer in de downlink van de satellietverbinding verloopt als volgt. Een linkcapaciteit van 2 Mbps betekent dat er per seconde 2 miljoen bits getransfereerd kunnen worden. Willen we slechts 1 seconde wachttijd in de buffer dan mag deze maximaal plaats hebben voor 2 000 000 bits. Uitgaande van de 000 000 maximale lengte van een IP-pakket van 12 000 bits (1500 bytes), levert dat 2 12 = 166 000


54

plaatsen op. satelliet HSDPA

downlink 2 Mbps 166 plaatsen uplink 512 kbps 42 plaatsen downlink 768 kbps 64 plaatsen uplink 320 kbps 26 plaatsen Tabel 5.3: Bufferlengtes

Geen handovers De performantie van de QoS-module wordt niet geëvalueerd tijdens handovers tussen verschillende toegangstechnologieën. Het mobiliteitsprotocol (mIP of mSCTP) treedt in dergelijke situaties in actie en de QoS-module dient dus geen maatregelen te nemen om rekening te houden met die situaties. We gaan uit van een “steady state” situatie om de performantie te evalueren en gebruiken hier dus geen mobiliteitsprotocol. Op die manier kunnen we er zeker van zijn dat we onze ontworpen module uitmeten en niet de prestaties van het mobiliteitsprotocol.

5.4.2

Modulaire aanpak

De prestaties van de geavanceerde QoS-management module in de vier voorgestelde scenario’s wordt vergeleken met de prestaties van twee andere QoS-modules, ontworpen als benchmark, om de performantie van de optimale QoS-module te valideren. De eerste module neemt op geen enkele manier maatregelen om Quality of Service implementeren. De tweede module onderneemt een eerste poging om tegemoet te komen aan de QoS-eisen van de klassen maar doet dit op een “onzorgvuldige” manier. A. Module zonder QoS-mechanismen De module zonder QoS-voorzieningen is niets minder dan een rechtstreekse verbinding tussen input en output. De geaggregeerde datastroom wordt zonder meer op de beschikbare uitgaande link(s) verstuurd zonder rekening te houden met de diversiteit en de overeenkomstige kwaliteitseisen van de pakketten. Figuur 5.3 toont het schema van deze module.


55

Figuur 5.3: Interne opbouw van de module zonder QoS-mechanismen.

B. Ruwe QoS-module De module met een eerste aanzet tot QoS-voorzieningen bestaat uit twee onderdelen. Een eerste component is een data analyser die de geaggrageerde datastroom uitsplitst over de 5 QoS-klassen om hen een verschillende behandeling te kunnen geven. De tweede component is een primitieve heterogene link manager: deze zorgt er enkel voor dat de vijf datastromen gemapt worden op links die aan de delayvereiste van de toegekende klasse voldoen. Door enkel de delayvereiste van een QoS-klasse voorop te stellen als criterium, houdt de module geen rekening met de vraag naar bandbreedte van elk van de datastromen, de onderlinge prioriteit van de klassen, het feit dat een te laat arriverend pakket (overschrijding van de delaydeadline) soms beter is dan helemaal geen... Figuur 5.4 toont de interne opbouw van de ruwe QoS-management module.

Figuur 5.4: Interne opbouw van de module zonder QoS-mechanismen.


56

De pseudocode van het algoritme in de ruwe versie van de mapping manager is hieronder weergegeven. Het sorteert eerst -net zoals de optimale versie- de lijst met uitgaande links eerst volgens oplopende delay en bij gelijke waarde volgens afnemende bandbreedte. In een volgende stap worden per QoS-klasse de uitgaande links geselecteerd die voldoen aan de delayvereisten van die klasse. Beginnend met de belangrijkste QoS-klasse (priority) en de eerste van het lijstje geselecteerde links, wordt er nagegaan of niet-toegekende resterende capaciteit op de uitgaande link groter is dan nul. Bij een positieve bevestiging wordt die klasse toegekend aan de uitgaande link en wordt de resterende capaciteit op de link voor een volgende iteratie verminderd met de vraag naar bandbreedte van die klasse. Indien de niet-toegekende capaciteit op de uitgaande link kleiner is dan nul, gaat men over naar de volgende link in de geselecteerde lijst. Is er op uitgaande links van het geselecteerde lijst geen resterende capaciteit meer voorhanden, dan wordt de link die nog net aan de delayvereisten voldoet (de laatste in de rij) toegekend aan die klasse. Voldoet er helemaal geen uitgaande link aan de delayvereisten van de QoS-klasse (lijst van geselecteerde links is leeg), dan wordt de link met de beste delay-eigenschappen toegekend aan die klasse (bovenste van de lijst met gesorteerde links).


57

C. Geavanceerde QoS-module De werking van de geavanceerde QoS-management module is beschreven in het onderdeel Mapping manager van het hoofdstuk Architectuur van de QoS-module, zie pagina 30.

5.4.3

Volgorde van de metingen

Samengevat zullen in onderstaande volgorde prestatiemetingen van de verschillende QoSmodules uitgevoerd worden: enkelvoudige satellietverbinding HSDPA- en satellietverbinding

ruwe QoS-module geavanceerde QoS-module ruwe QoS-module geavanceerde QoS-module

RESULTATEN

58

Hoofdstuk 6 Resultaten In dit hoofdstuk onderwerpen we de ontwikkelde QoS-management modules aan diverse tests om hun performantie te achterhalen. De tests worden minimaal tweemaal uitgevoerd om onjuiste metingen te identificeren en die bij de resultaten buiten beschouwing te laten.

6.1

Enkelvoudige link

In een eerste set metingen beschouwen we het scenario waarbij er slechts één uitgaande link beschikbaar is, met name een satellietverbinding. Deze connectie wordt getypeerd door een neerwaartse bandbreedte en delay van respectievelijk 2 Mbps en 240 ms. De geaggregeerde datastroom met verkeer van alle applicaties (voor een overzicht zie tabel 5.1) wordt over die ene verbinding gestuurd. De manier waarop de QoS-module de beschikbare linkcapaciteit van die ene link over de vijf QoS-klassen verdeelt, wordt beoordeeld. Onderstaande tabel 6.1 geeft de resultaten van deze metingen weer. De eerste kolom bevat de meetresultaten wanneer er geen QoS-voorzieningen aanwezig zijn. In de tweede en derde kolom zijn de meetgegevens van de applicaties weergegeven bij respectievelijk de ruwe en geavanceerde versie van de QoS-module, wanneer ze allemaal samen (geaggregeerd) over de satellietverbinding verstuurd worden. In de laatste kolom staan de meetresultaten van de applicaties wanneer ze elk afzonderlijk de satellietverbinding tot hun beschikking hebben en er geen ander verkeer aanwezig is. Hierbij meten we dus hun maximale prestaties bij een enkelvoudige satellietverbinding.

6.1 Enkelvoudige link

PR

IA

ST BE

BA

BA

BA

59

GEEN RUW GEAVANCEERD APART throughput 217 kbps 211 kbps 243 kbps 250 kbps jitter 22 ms 21 ms 13 ms 0,011 ms pakketverlies 13 % 15 % 0% 0% duur 30,1 s 30,1 s 30,9 s 30 s MOS 1,92 1,94 3,03 3,08 PESQ 2,3 2,3 3,1 3,2 delay 1251 ms 1260 ms 665 ms 456 ms pakketverlies 27,8 % 35 % 11 % 0% throughput 457 kbps 361 kbps 593 kbps 675 kbps throughput 15 kbps 15 kbps 13 kbps 15 kbps duur 92 s 98 s 133 s 83 s verloop in blok in blok continu continu 400 throughput 274 kbps 230 kbps 56 kbps 400 kbps jitter 12 ms 14 ms 15 ms 0,009 ms pakketverlies 29 % 40 % 65 % 0% duur 31,1 s 30,9 s 74,7 s 30 s 900 throughput 393 kbps 535 kbps 78,9 kbps 900 kbps jitter 7 ms 8 ms 42 ms 0,008 ms pakketverlies 55 % 39 % 78 % 0% duur 30,8 s 30,8 s 74,4 s 30 s 1300 throughput 720 kbps 701 kbps 146 kbps 1300 kbps jitter 7,3 ms 8,2 ms 42 ms 0,01 ms pakketverlies 43 % 45 % 74 % 0% duur 30,1 s 30,8 s 70,8 s 30 s

Tabel 6.1: Resultaten van de ruwe en geavanceerde QoS-module bij een enkelvoudige satellietverbinding.

Legende: ‘apart’ = verkeer van de applicaties wordt afzonderlijk over de link verstuurd, ‘ruw’ = ruwe versie van de QoS-module, ‘geavanceerd’ = geavanceerde versie van de QoSmodule, PR = priority, IA = interactive, ST = streaming, BE = best effort, BA = background

6.1 Enkelvoudige link

60

Toelichting bij de opgemeten parameter ‘verloop’ bij de BE-klasse: ’in blok’ betekent dat de transfer van webcontent pas start nadat alle andere verkeer is weggevallen, ’continu’ betekent daarentegen dat webcontent simultaan met alle andere dataverkeer over de links wordt verzonden. De aanzienlijke delays bij het VoIP-gesprek verdienen enige aandacht: 456 ms vertraging slechts in één richting, zelfs wanneer er enkel voice over de link gestuurd wordt, is significant groter dan de gesimuleerde vertraging van de satellietverbinding (240 ms). Dit is volledig te wijten aan de verwerking van de voice samples: de codec en softwarebuffering doen de vertraging oplopen tot dergelijke hoge waarden. De maximaal toegelaten eenrichtingsvertraging van 150 ms [19] in een telefoongesprek om geen hinder te ondervinden, kan dus zelfs in het beste geval niet gehaald worden.

6.1.1

Ruwe QoS-module

De performantie van de ruwe QoS-module is vergelijkbaar met de module die geen maatregelen neemt voor Quality of Service en heeft dus geen toegevoegde waarde voor de architectuur. De verklaring ligt in het feit dat bij de situatie met slechts één beschikbare link de werking van beide modules identiek is. De ruwe QoS-module splitst namelijk enkel het dataverkeer op in de verschillende klassen maar wijst ze uiteindelijk toch toe aan dezelfde link, wat neerkomt op een rechtstreekse verbinding tussen in- en uitgang.

6.1.2

Geavanceerde QoS-module

De geavanceerde QoS-module heeft wel duidelijk betere prestaties. Voor de belangrijkste klassen priority en interactive liggen de resultaten zelfs dicht in de buurt van wat maximaal kan worden bekomen (‘APART’). Ook de streaming-klasse zet opvallend betere prestaties neer dan wanneer geen QoS-maatregelen worden genomen. De opwaardering van de belangrijkste klassen manifesteert zich wel duidelijk bij de kwaliteitsdegradatie in de lagere QoS-klassen best effort en background. Maar aangezien mindere netwerkprestaties een kleinere impact hebben op de gebruikerservaring in die klassen, is dit te rechtvaardigen. Bij de best effort-klasse kan het verschil in aanpak tussen de ruwe en geavanceerde QoSmanagement module duidelijk opgemerkt worden. In de test met de ruwe QoS module start de transfer van webcontent pas nadat alle andere verkeer is stilgevallen. Het TCP congestion control mechanisme ligt waarschijnlijk aan de basis van deze vaststelling: de andere applicaties overstelpen het netwerk met UDP-datastromen zodat er geen bandbreedte meer

6.2 Load balancing

61

overblijft voor een TCP-stroom. Bij de geavanceerde versie kan echter continu webcontent worden getransfereerd omdat de traffic shapers een minimale bandbreedte garanderen voor dit TCP-verkeer. De throughputs van de datastromen zijn ook mooi in overeenstemming met de opgelegde bitratelimieten van de traffic shapers. De traffic shapers hervormen de datastromen van elke QoS-klasse vóór ze gemapt worden op de uitgaande links (hier slechts één), zie figuur 4.1 voor een overzicht. Onderstaande tabel illustreert deze vaststelling: aangevraagde geshapete bandbreedte bandbreedte PR 250 kbps 250 kbps IA 600 kbps 600 kbps ST 680 kbps 680 kbps BE 200 kbps 200 kbps BA 2600 kbps 272 kbps

effectieve bandbreedte 243 kbps 60 kbps 593 kbps 15 kbps 281 kbps

Voor de background -klasse is bijvoorbeeld eenvoudig na te gaan dat de totale effectieve throughput (56 + 79 + 146 = 281 kbps) ongeveer gelijk is aan de maximale waarde van 272 kbps.

6.2

Load balancing

Om nu ook de performantie van de QoS module te beoordelen wanneer meerdere heterogene links beschikbaar zijn, beschouwen we het scenario waarbij simultaan een satellieten een HSDPA-verbinding aanwezig zijn. De satellietconnectie wordt -zoals voorheen- gekarakteriseerd door een grote bandbreedte (2 Mbps downlink, 512 kbps uplink) maar heeft tevens een grote waarde voor de latentie (240 ms uplink en 240 ms downlink). De HSDPAverbinding heeft een beperktere bandbreedte (768 kbps downlink, 320 kbps uplink) maar de delay is nu heel wat kleiner (70 ms in beide richtingen). De resultaten van deze metingen zijn in onderstaande tabel 6.2 weergegeven. Om de vergelijking te vereenvoudigen met het scenario waarbij slechts een enkelvoudige satellietverbinding beschikbaar is, staan in de eerste twee kolommen de meetresultaten van de vorige test. De meetgegevens van de ruwe en geavanceerde QoS-management module bevinden zich repectievelijk in kolommen drie en vier.

6.2 Load balancing

PR

IA

ST BE

BA

BA

BA

RUW throughput 211 kbps jitter 21 ms pakketverlies 15 % duur 30,1 s MOS 1,94 PESQ 2,3 delay 1260 ms pakketverlies 35 % throughput 361 kbps throughput 15 kbps duur 98 s verloop in blok 400 throughput 230 kbps jitter 14 ms pakketverlies 40 % duur 30,9 s 900 throughput 535 kbps jitter 8 ms pakketverlies 39 % duur 30,8 s 1300 throughput 701 kbps jitter 8,2 ms pakketverlies 45 % duur 30,8 s

62 satelliet GEAVANCEERD 243 kbps 13 ms 0% 30,9 s 3,03 3,1 665 ms 11 % 593 kbps 13 kbps 133 s continu 56 kbps 15 ms 65 % 74,7 s 78,9 kbps 42 ms 78 % 74,4 s 146 kbps 42 ms 74 % 70,8 s

satelliet & HSDPA RUW GEAVANCEERD 250 kbps 241 kbps 4 ms 12,5 ms 0% 0% 30,1 s 31,2 s 3,30 2,59 3,3 2,8 343 ms 488 ms 23 % 9% 525 kbps 589 kbps 14 kbps 14 kbps 173 s 97 s in blok continu 222 kbps 175 kbps 14 ms 67 ms 42 % 37 % 31 s 43 s 801 kbps 486 kbps 10 ms 16 ms 8% 24 % 31 s 41,8 s 570 kbps 402 kbps 8,7 ms 13 ms 55 % 57 % 30,8 s 41,7 s

Tabel 6.2: Resultaten van de ruwe en geavanceerde QoS-module bij een satellieten HSDPAverbinding.

6.2 Load balancing

6.2.1

63

Ruwe QoS-module

In vergelijking met het scenario waarbij slechts één uitgaande (satelliet)verbinding beschikbaar is, haalt de ruwe QoS-module duidelijk betere prestaties. Dit is een vanzelfsprekende vaststelling aangezien zijn resultaten in de vorige test gelijkwaardig waren met een module die helemaal geen QoS-mechanismen implementeert. Het verkeer van de priority-klasse ervaart zelfs als het ware een perfecte verbinding en ook de gebruikerservaring van het VoIP-gesprek en de gestreamde video gaan er sterk op vooruit. Voor QoS-klassen priority en interactive is wegens de delay-eisen enkel de HSDPA-verbinding geschikt terwijl voor de lagere klassen de satellietverbinding volstaat. Dit reflecteert zich dan ook in de mapping, tabel 6.3: HSDPA PR 250 IA 600 ST 0 BE 0 BA 0

satelliet 0 0 680 200 2600

Tabel 6.3: ‘Reservatie’ van bandbreedtes voor de verschillende QoS-klassen bij de ruwe QoS module bij een satellieten HSDPA-verbinding en een priority-bandbreedte van 250 kbps, uitgedrukt in kbps.

De verbeterde mapping van de interactive-klasse manifesteert zich niet alleen in de hogere MOS- en PESQ-scores maar ook in de gemiddelde vertraging. Het VoIP-gesprek werd in het scenario met een enkelvoudige satellietlink nillens willens op deze verbinding gemapt, maar wanneer een bijkomende HSDPA-verbinding (met een beduidend lagere delay) beschikbaar wordt, komen de voice pakketten hierop terecht. De aanzienlijke vertraging bij het VoIPgesprek van meer dan een seconde in het geval van een enkelvoudige satellietverbinding wordt greduceerd tot enkele honderden milliseconden (343 ms) bij een parallelle satellieten HSDPA-verbinding. Er wordt voor 850 kbps bandbreedte gereserveerd op de HSDPA-link terwijl er slechts 768 kbps downlink beschikbaar is. Dit tekort aan capaciteit uit zich echter niet in de prestaties van de betrokken klassen (priority en interactive) omdat het VoIP-gesprek slechts ongeveer 60 kbps effectief nodig heeft aan bandbreedte en de effectieve throughput (250+60=310

6.2 Load balancing

64

kbps) dus kleiner is dan de linkcapaciteit van HSDPA. Bij de satellietverbinding laat deze overbelasting zich wel degelijk voelen in de betrokken klassen (streaming, best effort en background ). Voor een totale vraag naar bandbreedte van de drie klassen samen van 3,5 Mbps (680+200+2600kbps) betekent dat dat er ongeveer 1,5 Mbps aan pakketten verdeeld over de drie QoS-klassen verloren zal gaan. De effectieve throughputs van de betrokken klassen sommeren inderdaad samen tot ongeveer 2 Mbps (2,2 Mbps om precies te zijn).

6.2.2

Geavanceerde QoS-module

Voor de priority-klasse scoort de geavanceerde QoS-module even goed in vergelijking met (1) zijn gedrag in de situatie waarbij slechts een enkelvoudige satellietverbinding beschikbaar is (vorige test) en (2) de performantie van de ruwe QoS-module in de huidige test: een maximale throughput en geen pakketverlies. De videostreaming (streaming) en het downloaden van webcontent (best effort) ervaren zelfs een hogere kwaliteit bij dezelfde vergelijkingen. Ook de throughput en het pakketverlies van de background -transfers gaat erop vooruit vergeleken met de situatie van een enkelvoudige satellietverbinding. De reden hiervoor is dat er door de aanwezigheid van de HSDPA-link nu bijkomend 768 kbps capaciteit beschikbaar is. Die bijkomende bandbreedtecapaciteit van de HSDPA-link wordt nu wel aangewend voor de hogere QoS-klassen (lagere delay dan de satellietverbinding) maar hierdoor komt hun bandbreedtereservatie op de satellietverbinding vrij voor de laagste klassen. De background -klasse is in het scenario van de enkelvoudige satellietlink de enige klasse die lager geshapet (272 kbps) wordt dan zijn aangevraagde bandbreedte (2600 kbps) en die nu dus zal genieten van de extra vrijgekomen bandbreedte. De 272 kbps datasnelheidslimiet in de traffic shaper van de background -klasse wordt dus opgetrokken met 768 kbps en wordt in dit scenario ingesteld op 1040 kbps. De bandbreedtereservaties op de links zijn weergegeven in onderstaande tabel 6.4 en onderbouwen deze redenering. De kwaliteitsdegradatie van het VoIP-gesprek (interactive) ten opzichte van het scenario met een enkelvoudige satellietverbinding én zelfs de huidige situatie met de ruwe QoS module, is echter op zijn minst merkwaardig te noemen. Deze opmerkelijke vaststelling diepen we uit in het volgende onderdeel.

6.3 Migratieproblematiek

65 HSDPA PR 250 IA 518 ST 0 BE 0 BA 0

satelliet 0 82 680 200 1038

Tabel 6.4: Reservatie van bandbreedtes voor de verschillende QoS-klassen bij de geavanceerde QoS module bij een satellieten HSDPA-verbinding en een priority-bandbreedte van 250 kbps, uitgedrukt in kbps.

6.3 6.3.1

Migratieproblematiek Gedegradeerde audiokwaliteit

De achteruitgang van de gesprekskwaliteit ten opzichte van de situatie met een enkelvoudige link voor de geavanceerde QoS-management module is op het eerste gezicht merkwaardig. Het VoIP-gesprek krijgt namelijk eenzelfde totale hoeveelheid bandbreedte toegekend in beide situaties. De betere prestatie van de ruwe QoS-module doet vermoeden dat de mapping van de interactive-klasse bij de ruwe module beter is dan bij de geavanceerde module. Tabel 6.5 vergelijkt de toekenning van bandbreedte op de satellieten HSDPAlink voor beide QoS-modules.

PR IA ST BE BA

RUW HSDPA satelliet 250 0 600 0 0 680 0 200 0 1038

GEAVANCEERD HSDPA satelliet 250 0 518 82 0 680 0 200 0 2600

Tabel 6.5: Vergelijking van de mapping tussen de ruwe en geavanceerde QoS-module, uitgedrukt in kbps.

Uit de mappingtabel kunnen we afleiden dat de ruwe QoS-module alle voice pakketten op de HSDPA-link verstuurt, terwijl bij de geavanceerde QoS-module de meeste pakket-


66

ten eveneens op de HSDPA-link terecht komen maar een kleine fractie ervan ook op de satellietverbinding. Het vermoeden rijst dat de interactive-klasse erg gevoelig is voor het migratieprobleem (zie sectie 4.5.2) en pakketten die te laat arriveren, als verloren bestempelt. Vanuit een theoretisch standpunt bekeken is het ook logisch dat een spraakfragment dat niet in de juiste volgorde aankomt bij de ontvanger (later aankomt dan een spraakfragment dat later verstuurd werd bij de zender) nutteloos geworden informatie bevat. Wanneer het afspeelmoment van een geluid- of spraakfragment (aan de ontvanger) eenmaal voorbij is en het desbetreffende pakket is (nog) niet aangekomen, heeft de informatie in dat pakket namelijk geen nut meer. Dit vermoeden kan gestaafd worden door een volgend experiment. Vergroten we de aangevraagde bandbreedte van de priority-klasse tot 350 kbps, dan blijft er bij de geavanceerde mapping minder bandbreedte op de HSDPA-connectie over om voice pakketten over te sturen en zal er een groter gedeelte van de interactive-klasse op de satellietverbinding gemapt worden. Alle datastromen van andere applicaties blijven ongewijzigd. Tabel 6.6 met mappinggegevens toont de nieuwe verdeling. (a) ruwe QoS module

HSDPA PR 350 IA 600 ST 0 BE 0 BA 0

satelliet 0 0 680 200 938

(b) geavanceerde QoS module

HSDPA PR 350 IA 418 ST 0 BE 0 BA 0

satelliet 0 182 680 200 938

Tabel 6.6: Bandbreedtereservaties voor de verschillende QoS-klassen bij een satellieten HSDPA-verbinding en een priority-bandbreedte van 350 kbps, uitgedrukt in kbps.

Er wordt opnieuw een geaggregeerde pakketstroom over de twee beschikbare links verstuurd en uit de metingen blijkt logischerwijs dat alle applicaties, behalve de priority-klasse, minder goede prestaties halen dan wanneer de aangevraagde bandbreedte van de priorityklasse 250 kbps bedraagt. De reden hiervoor is dat er minder capaciteit op de links overblijft na de toekenning van de volledige vraag naar bandbreedte van de priority-klasse. De resultaten van het VoIP-gesprek hierbij zijn weergegeven in onderstaande tabel 6.7.

6.3 Migratieproblematiek priority: 250 kbps RUW GEAVANCEERD MOS 3,30 2,59 PESQ 3,3 2,8 delay 343 ms 488 ms

67 priority: 350 kbps RUW GEAVANCEERD 2,82 1,76 3 2,2 350 ms 550 ms

Tabel 6.7: Resultaten van de ruwe en geavanceerde QoS-module bij een satellieten HSDPAverbinding, waarbij de priority-bandbreedte 350 kpbs bedraagt.

In het geval van een priority-bandbreedte van 250 kbps bedraagt het verschil in audiokwaliteit 0,71 en 0,5 voor respectievelijk de MOS- en PESQ-score, terwijl bij een priority-bandbreedte van 350 kbps deze verschillen zijn opgelopen tot 1,06 en 0,8. Hieruit kan besloten worden dat hoe dichter de mapping van een VoIP-gesprek is bij een 50 % - 50 % verdeling over twee (heterogene) links, hoe slechter het gesprek wordt ervaren. De testopstelling laat niet toe na ta gaan of de kwaliteit verder afneemt naarmate meer parallelle links ge¨ıntroduceerd worden maar vermoedelijk is dat wel het geval.

6.3.2

TCP versus UDP

Een logische vraag bij uitbreiding is of de migratieproblematiek ook de andere klassen (applicaties) parten speelt. Om dit na te gaan laten we de aangevraagde bandbreedte van de priority-klasse voldoende toenemen zodat de HSDPA-link niet volstaat om de hele datastroom te dragen en er ook een deel van de satellietverbinding ingepalmd moet worden. Aangezien enkel de resultaten van deze klasse nu van belang zijn, sturen we enkel verkeer van deze applicatie over beide links (met andere woorden: geen geaggregeerd verkeer). Mappingtabel 6.8 komt overeen met een 1,5 Mbps datastroom aan priority-verkeer. Enkel de verdeling van het priority-verkeer is van belang maar louter ter illustratie vermelden we eveens de verdeling van de andere QoS-klassen. De keuze voor 1,5 Mbps-datastroom impliceert dat ongeveer de helft (768 kbps) op de HSDPA-link verstuurd wordt en de andere helft (732 kbps) op de satellietverbinding. In een eerste test wordt het dataverkeer -zoals voorheen altijd het geval was bij Iperfvia UDP over beide links naar de ontvanger gestuurd. Uit de meting blijkt dat er amper pakketverlies optreedt (0,21 %) en de effectieve throughput 1,45 Mbps bedraagt. De applicatie maalt er met andere woorden niet om dat de datagrammen niet mooi in volgorde arriveren, maar het is wel van belang óf ze aankomen. Migratie blijkt dus voor Iperf in


68 HSDPA PR 768 IA 0 ST 0 BE 0 BA 0

satelliet 732 600 414 190 63

Tabel 6.8: Reservatie van bandbreedtes voor de verschillende QoS-klassen bij de geavanceerde QoS-module bij een satellieten HSDPA-verbinding en een priority-bandbreedte van 1,5 Mbps, uitgedrukt in kbps.

UDP-mode geen breekpunt te zijn. Wordt dezelfde datastroom nu via TCP verstuurd, dan blijkt er slechts een (maximale) throughput van 490 kbps mogelijk. De ontvanger in een TCP-connectie eist namelijk wel dat de pakketten in volgorde van verzending aankomen. Een dump van de pakketstroom geeft inderdaad aan dat de ontvanger geregeld duplicate acknowledgements genereert, wat betekent dat laat arriverende pakketten (met name die verstuurd zijn over de satellietverbinding) de lege plaatsen opvullen in de gereconstrueerde datastroom aan ontvangerzijde. Figuur 6.1 toont een fractie van deze TCP-stroom. Deze test laat toe te besluiten dat migratie een grote invloed heeft op TCP-connecties.

Figuur 6.1: Dump van de TCP-connectie bij een priority-datastroom van 1,5 Mbps.

Conclusie Op basis van voorgaande tests kan men besluiten dat men bij de classificatie van de pakketten in verschillende QoS-klassen (taak van de data analyser) ook rekening


69

dient te houden met het onderliggende protocol dat voor de applicatie gebruikt wordt om zijn datastroom te transporteren. Bij de TCP-connecties moet de migratie zo klein mogelijk worden gehouden, terwijl dit voor UDP-connectie helemaal niet van belang zou zijn wegens de onbelangrijkheid van de aankomstvolgorde van de pakketten. Er zijn echter geen internetapplicaties te bedenken, gebruik makend van UDP, waarbij de volgorde van aankomst helemaal verwaarloosd kan worden, al is er wel wat speling mogelijk. Bijvoorbeeld als de play-out buffer van een ontvanger van videostreaming voldoende groot is, dan is een pakket dat na een recenter pakket aankomt maar waarvan het afspeelmoment nog niet is verstreken, toch niet nutteloos. De herordening van pakketten en migratie als haar oorzaak zijn dus minder ingrijpend voor de throughput van UDP-verbindingen.

6.3.3

Verbeterde aanpak

In de huidige data analyser en mapping manager wordt resoluut gekozen om applicaties in te delen en te behandelen volgens een vaste volgorde van criteria: eerst de prioriteit van de applicaties onderling (priority versus de anderen), dan de maximaal toelaatbare delay en als laatste de benodigde bandbreedte. Een nieuwe aanpak zou er nog steeds in bestaan eerst belangrijke applicaties prioritair te behandelen maar bij de indeling in klassen en de toekenning van capaciteit aan de klassen eveneens rekening te houden met het onderliggende transportprotocol (TCP versus UDP).

SAMENVATTING EN VERDER ONDERZOEK

70

Hoofdstuk 7 Samenvatting en verder onderzoek 7.1

Samenvatting

Probleemstelling Om een breedbandige internetconectie op de trein aan te bieden zijn verschillende draadloze technologieën noodzakelijk om de trein met het internet te verbinden. Elk van deze technologieën heeft andere eigenschappen qua kost, bandbreedte, latentie en QoS-garanties die een verschillende impact zullen hebben op de gebruikerservaring van internetapplicaties. Doelstelling Het doel van de scriptie is de ontwikkeling van een Quality of Service beheersysteem dat de verdeling van het uitgaande dataverkeer over beschikbare resources op een trein optimaliseert. Intelligente sturing van uitgaande datapakketten naar de draadloze technologieën kan de gebruikerservaring van de treinreiziger gevoelig verhogen. Het vooropgestelde doel is trachten zoveel mogelijk internetgebruikers op de trein zo goed mogelijk tevreden te stellen. Opbouw van de QoS-management module De geavanceerde QoS-management module bestaat uit een aantal componenten. De data analyser splitst de geaggregeerde datastroom uit over vijf QoS-klassen. Elk van deze datastromen wordt door een afzonderlijke traffic shaper hervormd conform berekende limieten voor de datasnelheden. De mapping manager wijst vervolgens de uitgaande pakketten toe aan een beschikbare link volgens een zelf ontwikkeld algoritme. Mappingalgoritme Het algoritme zorgt er in de eerste plaats voor dat de aangevraagde bandbreedte van de priority-klasse bijna in alle scenario’s sowieso gereserveerd wordt op

7.2 Verder onderzoek

71

de uitgaande links. Daarnaast garandeert het algoritme een minimale bandbreedte voor alle andere QoS-klassen. Een eventueel overschot aan niet toegekende capaciteit wordt toegekend aan de QoS-klassen in volgorde van dalende prioriteit (van de interactive naar de background -klasse). Testbed Het testbed bestaat onder andere uit twee machines die een treinreiziger en een server op het vasteland voorstellen. Daartussen bevindt zich het geëmuleerde netwerk bestaande uit een treingateway, een machine die het toegangsnetwerk voorstelt en een CMSgateway. De performantie van de ontwikkelde QoS-managament module wordt nagegaan in twee scenario’s: in een eerste scenario is enkel een satellietverbinding beschikbaar, terwijl in het tweede eveneens een HSDPA-connectie voorhanden is. Meetresultaten Testen wijzen uit dat de ruwe implementatie van een QoS-management systeem minstens even goed presteert als de situatie waarbij er geen QoS-voorzieningen zijn. De performantie van de geavanceerde QoS module is in bijna alle scenario’s zelfs nóg beter dan de ruwe variant, al dienen er bijkomende optimalisaties te gebeuren om de kwaliteit van VoIP-gesprekken te verbeteren.

7.2

Verder onderzoek

Vanzelfsprekend betekent de gepresenteerde QoS-management module geen eindpunt van het onderzoek naar de optimale implementatie. Dit werk geeft een eerste aanzet om de uitgaande datapakketten op een intelligente wijze te versturen over de beschikbare draadloze verbindingen, maar verschillende verbeteringen zijn mogelijk. Een aantal maatregelen waarvan we vermoeden dat ze de gebruikerservaring voor alle treinreizigers kunnen verbeteren, lichten we even toe. Verbeterde data analyser Tot welke QoS-klasse een pakket zal behoren om de overeenkomstige behandeling te krijgen, wordt in de huidige data analyser louter beslist op basis van de applicatie waarvan het pakket afkomstig is. In de praktijk betekent dat selectie op basis van bron- of bestemmingspoortnummer. De classifier houdt dus geen rekening met het belang van het pakket binnen de informatietransfer tussen de communicerende applicaties van de eindpunten. In sommige datastromen zijn bepaalde pakketten belangrijker dan andere omdat ze crucialere of grotere hoeveelheden informatie transferen. Bijvoorbeeld in een MPEG-videostroom bevatten de I-frames veel meer informatie dan de


72

P-frames die op hun beurt belangrijker zijn dan de B-frames. Bij een eenvoudige TCPverbinding spelen ACKs een voorname rol in de connectie. Verzending van de B-frames in een MPEG-videostroom en de ACKs via de snelst beschikbare link (laagste delay) zou de gebruikersevaring significant kunnen verhogen. Een verbetering voor de data analyser zou dus kunnen inhouden dat naast het criterium van de poortnummers, eveneens de inhoud van de datapakketten (content inspection) en het onderliggende transportprotocol (TCP versus UDP) ge¨ınspecteerd wordt om het pakket toe te kennen aan een bepaalde QoS-klasse. Admission control en verbeterde traffic shaping Wanneer de bandbreedtereservatie van een QoS-klasse kleiner is dan de aangevraagde bandbreedte, moeten er pakketten gedropt worden in de traffic shaper. Door deze verwerping op een intelligente manier te realiseren, kan de gebruikerservaring van meer treinreizigers toenemen. Een “admission control” functionaliteit kan overgaan tot het sneller droppen van pakketten afkomstig van een intensieve gebruiker om sporadische gebruikers ook gebruik te laten maken van de internetverbinding (eerlijke verdeling van de bandbreedte over alle passagiers). Zoals reeds aangegeven bij de ‘verbeterde data analyser’ kan men ook overgaan tot eerst het droppen van minder belangrijke pakketten in een datastroom. Enkele studies [20, 21] rapporteren dat pakketverlies van 20 % en 16 %, respectievelijk door het verwerpen van minder belangrijke pakketten en door selectie op basis van de klanken die spraakpakketten transporteren, slechts een minieme degradatie in audiokwaliteit impliceert. Graduele omschakeling bij handover Hoewel overgangssituaties (handovers) niet in beschouwing werden genomen bij het ontwikkelen van de gepresenteerde QoS management module, kan het nuttig zijn er toch rekening mee te houden. De Policy Decision Function (PDF - zie pagina 11) kan een wegvallende verbinding voelen aankomen door het continu in sterkte afnemende signaal. Indien hij de mapping manager in de QoS module hiervan op de hoogte brengt, kan deze de bandbreedtereservatie van de klassen die op deze link gemapt zijn, gradueel laten afnemen en geleidelijkaan de reservaties op de nieuw toegekende verbindingen laten toenemen. Op die manier wordt het mobiliteitsprotocol (mIP of mSCTP) ontlast dat na de QoS module de pakketten effectief tracht te versturen op de toegekende links en zou het eventuele pakketverlies bij de handover ingeperkt kunnen worden. E´ en connectie op ´ e´ en link Eén enkele QoS-klasse bundelt netwerkconnecties van meerdere individuele gebruikers met gelijkaardige netwerkeisen. Wanneer de bandbreedtereser-


73

vatie van die klasse verdeeld is over meerdere uitgaande links, is het met de huidige implementatie mogelijk dat twee willekeurige pakketten van eenzelfde logische netwerkconnectie op afzonderlijke links verstuurd worden. Om het migratieprobleem verder in te perken zou men bij de mapping kunnen rekening houden met de individuele netwerkconnecties binnen eenzelfde datastroom zodat alle pakketten van binnen eenzelfde connectie op dezelfde uitgaande link verstuurd worden. Scheduler Wanneer pakketten van verschilende klassen op eenzelfde link terechtkomen, worden ze in een wachtrij gezet en in volgorde van aankomst bediend (FIFO-discipline). Een mogelijk verstandige keuze zou een pakketscheduler kunnen zijn die nog een zekere prioriteit respecteert tussen de pakketten van verschillende klassen. Er bestaan uiteenlopende schedulermechanismen maar het algoritme van Peha [22], met name Priority Token Bank, blijkt volgens de literatuur de beste prestaties te realiseren. Periodieke mapping De toewijzing van datastromen aan de beschikbare links gebeurt in de huidige versie van QoS management module enkel wanneer de set van uitgaande verbindingen of hun eigenschappen veranderen. Tussen dergelijke tijdstippen in kunnen de aangevraagde bandbreedtes van de verschillende datastromen echter sterk veranderen waardoor de mapping niet meer optimaal zal zijn. Een optimalisatie bestaat erin op periodieke tijdstippen de mapping te herberekenen en niet enkel wanneer de uitgaande verbindingen wijzigen.

CODE

74

Bijlage A Code A.1 A.1.1

Click elementen en scripts Click elementen

In het kader van deze thesis werden onderstaande Click elementen geprogrammeerd: link.hh en link.cc, een C++ -klasse die netwerkverbinding representeert met zijn typische netwerkeigenschappen (bandbreedte, vertraging, pakketverlies...). QoSclass.hh en QoSclass.cc, een C++ -klasse die een individuele QoS-klasse en de bijbehorende datastroom voorstelt. data analyser raw.hh en data analyser raw.cc, verouderd Click element waarop de geavanceerde versie gebaseerd is maar die niet meer gebruikt mag worden data analyser optimal.hh en data analyser optimal.cc, een Click element die de functie van classifier (zie onderdeel 4.2 pagina 23) implementeert. mapping scheduler raw.hh en mapping scheduler raw.cc, een Click element dat functioneert als de ruwe versie van de QoS management module (zie onderdeel 5.4.2, pagina 55). mapping scheduler optimal.hh en mapping scheduler raw.cc, een Click element dat de implementatie van de geavanceerde QoS management module bevat, zoals besproken in onderdeel 4.5.4 op pagina 30.

A.1 Click elementen en scripts

A.1.2

75

Click scripts

De drie machines die de trein (trein gateway), het toegangsnetwerk (access network ) en de CMS (central gateway) representeren in de opstelling, draaien Click Modular Router [24]. Voor elk van de machines werden Click scripts geschreven die de nodige functionaliteit implementeert voor de verschillende scenario’s. Figuur A.1 verduidelijkt welke scripts op welke machine kunnen draaien.

Figuur A.1: Click scripts op de verschillende machines.

noQoS 1 traingateway noQoS 1 centralgateway

scripts zonder QoS-voorzieningen

QoS raw 1 traingateway QoS raw 1 centralgateway

ruwe QoS module op de trein en CMS voor één beschikbare link

QoS raw 2 traingateway QoS raw 2 centralgateway

ruwe QoS module op de trein en CMS voor beide links beschikbaar

QoS optimal 1 traingateway QoS optimal 1 centralgateway

geavanceerde QoS module op de trein en CMS voor één beschikbare link

QoS optimal 2 traingateway QoS optimal 2 centralgateway link emulation zion11 satellite link emulation zion11 HSDPA link emulation zion11

geavanceerde QoS module op de trein en CMS voor beide links beschikbaar satellietverbinding HSDPA-connectie satelliet en HSDPA

A.2 Praktische richtlijnen

A.2

76

Praktische richtlijnen

Bij het gebruik van de Click elementen en scripts moet een aantal praktische richtlijnen in acht worden genomen. In het Click element mapping scheduler optimal wordt er gebruik gemaakt van de voorafgedefinieerde variabele “aantalLinks”. Afhankelijk van het aantal beschikbare links dient deze correct ingesteld te worden (‘1’ of ‘2’ voor onze opstelling van het testbed). Bij het oproepen van de write handler “createLink” van mapping scheduler raw en mapping scheduler optimal moet als resterende bandbreedte (remainingBandwidth) de capaciteit van de verbinding ingevuld worden voor een correct verloop van het algoritme. Het oproepen van dezelfde write handler vereist eveneens opgave van een identificatienummer van de link, het zogenaamde ID. Voor gebruik in onze opstelling dient men ‘0’ in te vullen voor de satellietverbinding en ‘1’ voor de HSDPA-connectie.

BIBLIOGRAFIE

77

Bibliografie [1] NMBS jaarverslag 2006. http://www.b-rail.be/nat/N/assets/downloads/pdf/ compljrverslag-nl.pdf. [2] T. Evens, J. Gysels, D. Schuurman, and G. Verleye. Deliverable 2.2:wp2 van het TR@INS-project “Results of Survey Study of Potential Users”. 2007. [3] Lara Srivastava, Tim Kelly, Chin Yung Lu, and Lucy Yu. Business.digital. Digital.life, ITU Internet Report 2006, pages 69–92, 2006. [4] T. Evens, J. Gysels, D. Schuurman, and G. Verleye. Deliverable 1.1:wp1 van het TR@INS-project “Use Cases”. 2006. [5] CEO Telenet Duco Sickinghe. Telenet at the crossroad of communication, information and entertainment. 2007. [6] Frederic Van Quickenborne. Design and Efficient Management of Aggregation Networks for Fast Moving Users, 2008. [7] Filip De Greve, Frederic Van Quickenborne, Filip De Turck, Ingrid Moerman, and Piet Demeester. Aggregation Network Design for Offering Multimedia Services to Fast Moving Users. In Quality of Service in Multiservice IP Networks, 2005. [8] Filip De Greve, Frederic Van Quickenborne, Filip De Turck, Ingrid Moerman, and Piet Demeester. On the Management of Aggregation Networks with Radiply Moving Traffic Demands. In Intagrated Network Management IX, 2005. [9] Satya R. Mohanty and Laxmi N. Bhuyan. On Fair Scheduling in Heterogeneous Link Aggregated Services. In Computer Communications and Networks, pages 199–205, 2005.

BIBLIOGRAFIE

78

[10] Josep M. Blanquer and Banu Ozden. Fair Queueing for Aggregated Multiple Links. Proceedings of the ACM SIGCOMM 2001 Conference on Applications, Technologies, Architectures and Protocols for Computer Communication, pages 189–198, 2001. [11] Ji Li and Jack Brassil. On the Performance of Traffic Equalisers on Heterogeneous Communication Links. Proceedings of QShine’06 Waterloo CA, 2006. [12] iperf. http://dast.nlanr.net/projects/Iperf/. [13] Sourceforge.net. http://sourceforge.net/projects/iperf/. [14] Wget. http://www.gnu.org/software/wget/. [15] Evalvid. http://www.tkn.tu-berlin.de/research/evalvid/. [16] Akiyo videosequentie. html.

http://www.tkn.tu-berlin.de/research/evalvid/cif.

[17] X-lite van CounterPath. http://www.counterpath.com. [18] Opticom. http://www.opticom.de. [19] Cisco, Understanding Delay in Packet Voice Networks. http://www.cisco.com/ warp/public/788/voip/delay-details.html. [20] N. Yin, S. Li, and T. E. Stern. Congestion Control for Packet Voice by Selective Packet Discarding. IEEE Trans. Commun., 38(5):674–683, May 1990. [21] D. W. Petr, Jr. L. A. DaSilva, , and V. S. Frost. Priority Discarding of Speech in Integrated Packet Networks. IEEE J. Sel. Areas Commun., 7(5):644–656, June 1989. [22] Jon M. Peha. Scheduling and Admission Control for Integrated-Services Networks: The Priority Token Bank. Communications, 1993. ICC 93. Geneva. Technical Program, Conference Record, IEEE International Conference on, 1(1):345–351, May 1993. [23] Wikipedia, the free encyclopedia. http://en.wikipedia.org/. [24] The Click Modular Router Project. http://www.read.cs.ucla.edu/click/. [25] DVB-S2 factsheet. http://www.dvb.org/technology/fact_sheets/DVB-S2% 20Fact%20Sheet.0408.pdf. [26] DVB-RCS factsheet. http://www.dvb.org/technology/fact_sheets/DVB-RCS% 20Fact%20Sheet.0408.pdf.

LIJST VAN FIGUREN

79

Lijst van figuren 1.1 1.2 1.3 1.4

Enkele Google applicaties. . . . . . . . . . . . . . . . . . . . . . . . . . . . Mobiele datakaarten van Proximus en Telenet. . . . . . . . . . . . . . . . . Evolutie in de gemiddelde breedbandsnelheden en -prijzen van 133 economieën. Principe van link aggregatie. . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 2.2 2.3

9 10

2.4

Fysische netwerkarchitectuur. . . . . . . . . . . . . . . . . . . . . . . . . . IP-tunnel tussen de trein en CMS. . . . . . . . . . . . . . . . . . . . . . . . Interne opbouw van de mobiliteitsbeheermodule en onderlinge interacties van de bouwblokken. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . QoS-voorziening in het toegangs-en aggregatienetwerk. . . . . . . . . . . .

3.1

Situering van de QoS-module. . . . . . . . . . . . . . . . . . . . . . . . . .

13

Interne opbouw van de QoS-management module. . . . . . . . . . . . . . . Data analyser (classifier). . . . . . . . . . . . . . . . . . . . . . . . . . . . . Token bucket algoritme voor traffic shaping. . . . . . . . . . . . . . . . . . Meerdere QoS-klassen gemapt op één link en één QoS-klasse toegewezen aan meerdere links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Systeemmodel (links) en geaggregeerd systeem (rechts). . . . . . . . . . . . 4.6 Stroomdiagram van de sorteringsfase. . . . . . . . . . . . . . . . . . . . . . 4.7 Verschillende scenario’s bij de bandbreedtereservatie van de priority-klasse. 4.8 Mappingproces waarbij de vraag naar bandbreedte groter is dan de resterende bandbreedte op de link (links) of omgekeerd (rechts). . . . . . . . . . 4.9 Aanpak van het mappingprobleem met de delaybeperkingen als belangrijkste criterium (eerste geval). . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10 Aanpak van het mappingprobleem met de prioriteit van de QoS-klassen als belangrijkste criterium (tweede geval). . . . . . . . . . . . . . . . . . . . .

22 23 26

4.1 4.2 4.3 4.4

1 2 3 6

11 12

27 29 32 34 40 41 41

LIJST VAN FIGUREN

80

4.11 Illustratie van afweging tussen delaybeperkingen en de prioriteit van de QoSklassen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12 Mappingproces van de beschouwde situatie. . . . . . . . . . . . . . . . . .

42 46

5.1 5.2 5.3 5.4

Schema van het testbed. . . . . . . . . . . . . . . . . . . . Schematische opbouw van het EvalVid-raamwerk. . . . . . Interne opbouw van de module zonder QoS-mechanismen. . Interne opbouw van de module zonder QoS-mechanismen. .

. . . .

47 51 55 55

6.1

Dump van de TCP-connectie bij een priority-datastroom van 1,5 Mbps.

.

68

A.1 Click scripts op de verschillende machines. . . . . . . . . . . . . . . . . . .

75

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

LIJST VAN TABELLEN

81

Lijst van tabellen 1.1

Enkele pilootprojecten en commerciële roll-outs. . . . . . . . . . . . . . . .

4

3.1 3.2

Karakteristieke parameters van de verschillende QoS-klassen. . . . . . . . . Onderverdeling van de treingebruikers volgens rijtuigklasse en gebruikersprofiel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interesse van de treingebruikers voor de verschillende internetapplicaties, uitgedrukt in procenten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Netwerkparameters van de verschillende draadloze toegangstechnologieën, waarbij voor satelliet in de uplink DVB-RCS wordt gebruikt en in de downlink DVB-S2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

21

4.1 4.2

Toekenning van poortnummers aan QoS-klassen. . . . . . . . . . . . . . . . Minimaal gegarandeerde percentages voor vier QoS-klassen. . . . . . . . .

24 36

5.1 5.2 5.3

Samenvatting van de gebruikte applicaties en belangrijke parameters. . . . Linkeigenschappen (links) en testbedscenario’s (rechts) . . . . . . . . . . . Bufferlengtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52 53 54

6.1

Resultaten van de ruwe en geavanceerde QoS-module bij een enkelvoudige satellietverbinding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resultaten van de ruwe en geavanceerde QoS-module bij een satellieten HSDPA-verbinding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ‘Reservatie’ van bandbreedtes voor de verschillende QoS-klassen bij de ruwe QoS module bij een satellieten HSDPA-verbinding en een prioritybandbreedte van 250 kbps, uitgedrukt in kbps. . . . . . . . . . . . . . . . . Reservatie van bandbreedtes voor de verschillende QoS-klassen bij de geavanceerde QoS module bij een satellieten HSDPA-verbinding en een priority-bandbreedte van 250 kbps, uitgedrukt in kbps. . . . . . . . . . . . . .

3.3 3.4

6.2 6.3

6.4

18 18

59 62

63

65

LIJST VAN TABELLEN 6.5 6.6

6.7 6.8

Vergelijking van de mapping tussen de ruwe en geavanceerde QoS-module, uitgedrukt in kbps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bandbreedtereservaties voor de verschillende QoS-klassen bij een satellieten HSDPA-verbinding en een priority-bandbreedte van 350 kbps, uitgedrukt in kbps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resultaten van de ruwe en geavanceerde QoS-module bij een satellieten HSDPA-verbinding, waarbij de priority-bandbreedte 350 kpbs bedraagt. . . Reservatie van bandbreedtes voor de verschillende QoS-klassen bij de geavanceerde QoS-module bij een satellieten HSDPA-verbinding en een priority-bandbreedte van 1,5 Mbps, uitgedrukt in kbps. . . . . . . . . . . . . .

82

65

66 67

68

Ontwikkeling van een centraal bandbreedte beheersysteem voor internet op de trein

Recommend Documents