Ontwerp en implementatie van het toekomstig netwerk voor...

Sebastiaan Mindreau

netwerk voor verpleegoproepsystemenOntwerp en implementatie van het toekomstige

Academiejaar 2008-2009Faculteit IngenieurswetenschappenVoorzitter: prof. dr. ir. Daniël De ZutterVakgroep Informatietechnologie

Master in de ingenieurswetenschappen: computerwetenschappen Masterproef ingediend tot het behalen van de academische graad van

Begeleider: Sam LefebvrePromotoren: prof. dr. ir. Piet Demeester, dr. ir. Brecht Vermeulen

Voorwoord

Hoe begin je aan een masterproef? Dat loodzware ding dat je in je laatste jaar moet afgeven. Al dieverwachtingen, al die struikelblokken, je moet ze allemaal zeer zelfstandig tegemoet. Hoe slaag je erin omde essentie van je onderzoek te tonen zonder met de deur in huis te vallen en tegelijk de lezer niet voor domte aanzien?

Hoe schrijf je een inleiding voor dat werk? Begin je beschrijvend met een lijst van doelstellingen of begin jedirect je verhaal te vertellen? Misschien is het beter om even rond de pot te draaien, dat hoort toch zo ininleidingen? Of kom je direct tot je punt en is de inleiding slechts 2 regels lang?

Hoe verdedig je een masterproef? Hoe nauwgezet verfijn je je masterproef? Hoe goed moet hij zijn? Hoe diepmoet het onderzoek gaan opdat je verdediging meevalt? Of ben je dan te ver van het onderwerp geweken?

Al deze vragen zijn een kwelling voor de student. En zo heb ik het ook ervaren, een zeer educatieve kwellingweliswaar. En ook ik zal mijn verhaal hierin vertellen, wat wetenschappelijker dan in vorige paragrafen,maar niet minder bezield door de materie en de ideeen die ik erin onderbreng. Want dit is een finaalwerk van groot belang voor mijn eigen ontwikkeling, voor het behalen van het diploma, als bewijs van hetjarenlange opnemen van informatie en het reproduceren van leerstof. De kers op de taart waarmee ik toondat ik een waardig ingenieur mag zijn, en zelf nieuwe concepten aan het licht breng of bestaande verenig totnieuwe semantische gehelen. Dat is de uitdaging die ik begin dit academiejaar aanging. Het verhaal beginthieronder.

E-health is tegenwoordig in volle opmars. Overal verschijnen bedrijven en oplossingen voor de zorgsec-

tor, ziekenhuissector, enzovoort. De vergrijzing van de bevolking is een veel aangehaald argument. En

dat is een goed argument, de vergrijzing zorgt voor een grotere druk op ons zorgsysteem en voor een

hogere eis aan zorg voor ouderen.

In deze masterproef probeer ik daar onrechtstreeks tot bij te dragen. Ouderen komen veel in contact met

verpleegoproepsystemen, hetzij in ziekenhuizen hetzij in rust- en verzorgingstehuizen (RVT’s). Personen

die hulp nodig hebben in dergelijke situatie hangen volledig af van dat verpleegoproepsysteem.

Televic is een bedrijf dat onder andere oplossingen voor deze ziekenhuis- en zorgsector ontwikkelt.

Een van hun belangrijke oplossingen is hun verpleegoproepsysteem Axio i-Tec. Dit systeem is echter

gedeeltelijk verouderd. Het bevat namelijk nog veel onderdelen op basis van LON-technologie (Local

Operating Network). Deze technologie is traag en verouderd en weinig onderhoudbaar.

Indien deze technologie vervangen zou worden door Ethernet-technologie waarbovenop het Internet

Protocol (IP) werkt, zouden een aantal zeer interessante voordelen uitgebuit kunnen worden:

• Gestandaardiseerde apparatuur: overal te verkrijgen op de markt, zeer stabiel, veel ervaring;

• Homogeniteit in het netwerk: eenvoudiger te beheren, gemakkelijker te vervangen;

• Performantie: een sneller netwerk zorgt er ook voor dat de capaciteit van het netwerk verhoogd

kan worden. Hierdoor is het ook mogelijk om nieuwe diensten aan te bieden zoals video en Voice

over IP (VoIP).

Deze masterproef behandelt het ontwerp van een dergelijk toekomstige verpleegoproepsysteem.

Vooreerst wordt het huidige verpleegoproepsysteem besproken, zodat de belangrijkste karakteristieken

en nomenclatuur gebruikt kunnen worden. Daarna worden een aantal parameters van dat netwerk

bepaald aan de hand van een statistisch model. Dit model kan dan verder aangewend worden om

voorspellingen te doen voor wat betreft het bandbreedtegebruik op het huidige netwerk.

De voorspelling begon echter reeds op mijn stage bij Televic. Toen schreef ik een programma dat

voorspellingen deed van het netwerk, op basis van logberichten. De kwaliteit van dit programma wordt

ook in deze masterproef geevalueerd.

Daarna volgt het meer vernieuwende werk. Het nieuwe systeem wordt bottom-up besproken. Eerst

wordt besproken hoe het netwerk fysisch in elkaar gepast wordt. In tegenstelling tot het huidige ver-

pleegoproepsysteem zijn er meerdere mogelijkheden om de elementen met elkaar te verbinden.

Hierna worden de diensten besproken op het nieuwe verpleegoproepsysteem. Sommige diensten zijn

nieuw, anderen werden in een nieuw kleedje gestoken. Daarbij aansluitend wordt een belangrijke stap

gezet, namelijk de invoering van Quality of Service (QoS).

Na deze ontwerpfase wordt de implementatiefase besproken. Er werd een Proof of Concept uitgewerkt,

een demo als het ware, van een aantal van de nieuwe technologieen voor het toekomstige verpleegop-

roepsysteem. Samen met de conclusies sluit dit de masterproef af.

Gebruikte naamgeving

In deze masterproef worden een aantal termen herhaaldelijk gebruikt. Sommige van die termen kunnen

wat verwarring creeren. Daarom volgen hier een aantal definities.

Node vs Kamernode: de term “node” kan in verschillende contexten anders geınterpreteerd worden.

In het verpleegoproepsysteem bijvoorbeeld wordt dit gebruikt om een toestel in een kamer voor

te stellen, terwijl dit op de Virtual Wall een generieke machine is.

Een node op het verpleegoproepsysteem zal in deze tekst altijd aangeduid worden met kamer-

node. Elke andere betekenis kan uit de context afgeleid worden, zoals bijvoorbeeld bij de Virtual

Wall. De term node wordt echter wel behouden in afbeeldingen om ze niet te overladen.

Huidige vs Toekomstige verpleegoproepsysteem: wanneer gesproken wordt over het huidige ver-

pleegoproepsysteem, wordt gerefereerd aan de huidige versie van het verpleegoproepsysteem van

Televic, dat niet enkel uit IP-technologie bestaat. Het “toekomstige” verpleegoproepsysteem duidt

op een netwerk met meer IP-elementen en waar het LON-gedeelte volledig uit verwijderd is.

Dataset: onder dataset wordt verstaan een hoeveelheid data die op een bepaald netwerk opgevangen

werden (captured), ook wel een dump genaamd.

Definities en gebruikte symbolen

Het TCP/IP-model

In “Multimedianetwerken” en voorgaande cursussen werd gebruik gemaakt van een beknoptere versie

van het OSI-model (Open Systems Interconnection), namelijk het TCP/IP-model voor het internet (Trans-mission Control Protocol/Internet Protocol) [8, 13]. Dit model beschrijft de 5 lagen die boven elkaar

beschouwd worden, zoals in Figuur 1. Op die figuur staat links de gestandaardiseerde laag en rechts er-

van de protocols die op die laag gebruikt worden. Helemaal rechts staan ook Router en Switch vermeld

om aan te duiden op welke laag deze elementen werken.

Application Layer

Transport Layer

Network Layer

Datalink Layer

Physical Layer

TCP, UDP

IP

Ethernet

UTP cable(Unshielded Twisted Pair)

Switch

Router

Figuur 1: Het TCP/IP internet model met enkele bijhorende protocols.

In deze masterproef zullen de termen applicatielaag, transportlaag, netwerklaag, datalinklaag en fysi-

sche laag vaak gebruikt worden. Daarom worden ze hier heel kort besproken.

De fysische laag is de kabel waarop nullen en enen kunnen geplaatst worden. Hier komt ook modulatie

en detectie van pas.

De datalinklaag zorgt voor de basisadressering aan de hand van MAC-adressen. Een switch is een

element dat enkel maar weet heeft van MAC adressen en op de datalinklaag werkt.

De netwerklaag biedt een flexibelere routering aan de hand van IP-adressen. Een router werkt op de

netwerklaag en maakt gebruik van complexe routeringstabellen om pakketten op hun bestemming te

brengen.

De transportlaag zorgt ervoor dat, in het geval van TCP, pakketten gegarandeerd en in de juiste volgorde

toekomen. Dit is een belangrijke dienst die ook pakketten opnieuw verzendt indien ze niet correct op

hun bestemming toekwamen.

Tenslotte is er de applicatielaag waar een hele waaier van applicaties op aangeboden worden.

Elke laag kan slechts communiceren met de laag eronder en erboven, op een aantal uitzonderingen na.

Een pakket begint onderaan de fysische laag als het van het netwerk komt en wordt naar boven toe

geduwd. Een pakket dat uit de applicatielaag komt wordt naar beneden - naar het netwerk - geduwd.

Indien dit teken in de tekst voorkomt wil dit zeggen dat er meer informatie te vinden is op de bijge-

voegde cd-rom. De precieze locatie en aanwijzingen worden naast dit teken weergegeven.

Hier wordt expliciet informatie over Quality of Service (QoS) gegeven.

Dit symbool geeft specifieke IP-adresconfiguratie aan voor de testopstelling.

In dit soort blok wordt werk voor de toekomst besproken.

Cd-rom

Aan deze masterproef werd een cd-rom gehecht. Deze cd-rom bevat:

• de uitvoerbare code van de besproken software in deze masterproef;

• de testresultaten van alle tests, voor zover deze gepubliceerd mogen worden;

• een website met meer informatie over de gebruikte code;

• een digitale versie van deze masterproef.

Het gebruik van de cd-rom is eenvoudig. De Autorun zorgt ervoor dat de dynamische website opstart,

inclusief zoekfunctionaliteit. Deze functionaliteit werkt enkel onder Windows. Er staat verder meer

informatie over de cd-rom in het bestand README.txt.

Dankwoord

Om te beginnen wil ik mijn begeleider Sam Lefebvre bedanken. Hij was er steeds om me te helpen met

herlezen van teksten, raad voor een experiment of gewoon om eens over de masterproef te praten. Ook

Brecht Vermeulen wil ik hiervoor bedanken, ook voor het meer technische luik naar de implementatie

en de tests toe.

Ik wil graag Televic en in het bijzonder Bastian Piepers bedanken voor de aangename communicatie

over het onderwerp en de blijvende vraag naar nieuwe elementen, zodat ik ook steeds geprikkeld bleef

om verder te werken.

Volgende personen wens ik te bedanken voor hun speciale bijdragen: Robby Caspeele voor de statistisch-

theoretische fundamenten, Bart Jooris voor zijn hulp bij Ethernet-busstructuren. Dank aan Alexis Rom-

baut voor de hulp tijdens het configureren van XStreamer. Eddy Hebblinckx dank ik voor de vriendelijke

hulp bij het uitlenen uit de vakgroepbibliotheek. Ik dank ook de TestLab en Virtual Wall admins voor

hun hulp tijdens technische frustraties.

Uiteraard dank ik ook graag de proeflezers en -lezeressen voor het lezen en verbeteren van mijn mas-

terproef: Marie-Rose Hallaert, Ina Leijman, Gustavo Mindreau, Bastian Piepers en Eva Verbiest.

Toelating tot bruikleen

De auteur geeft de toelating deze masterproef voor consultatie beschikbaar te stellen en delen van de

masterproef te kopieren 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 masterproef.

2 juni 2009,

Sebastiaan Mindreau

Ontwerp en implementatie van het toekomstigenetwerk voor verpleegoproepsystemen

Sebastiaan Mindreau

Promotoren: prof. dr. ir. Piet Demeester, dr. ir. Brecht Vermeulen

Begeleider: Sam Lefebvre

Vakgroep Informatietechnologie, voorzitter: Daniel De Zutter

Faculteit Ingenieurswetenschappen, Universiteit Gent

Academiejaar 2008-2009

Samenvatting

Deze masterproef behandelt het ontwerp en een Proof of Concept van de onderzochte technologieen

voor het uitbreiden van het netwerk voor verpleegoproepsystemen van Televic. Drie diensten werden

geselecteerd ter evaluatie van het systeem: verpleegoproepen, videodistributie en achtergrondverkeer.

De drie diensten werden geımplementeerd. Er werden twee scenario’s gedefinieerd om het nieuwe

systeem te testen, met Quality of Service (QoS)-elementen in het netwerk en zonder QoS-elementen in

het netwerk. Het doel van deze test is om na te gaan of het netwerk voldoende QoS kan bieden voor

alle applicaties.

Uit de testen blijkt dat er een duidelijke verbetering van het netwerk is indien QoS toegepast wordt. De

maximale vertraging op berichten wordt namelijk 10 keer kleiner indien gebruik gemaakt wordt van

QoS.

Er werd ook onderzoek gedaan naar netwerkparameters voor het huidige netwerk. Er voor beide ty-

pes netwerken (LON en IP) een statistisch model te vinden dat dicht in de buurt komt van de reele

bandbreedte, zolang het beschouwde schuivende venster niet te klein is.

De validatie van de StateMachine software uit mijn stage levert voor LON slechte resultaten op: een

nauwkeurigheid van slechts 20 a 30 %. Voor IP wordt een nauwkeurigheid van 75 a 90 % bereikt.

Trefwoorden: maximale onmiddellijke bandbreedte, toekomstige verpleegoproepsysteem, Quality of

Service, meerdienstig netwerk.

Design and Implementationof the Future Nursecall Network

Sebastiaan Mindreau

Supervisor(s): Piet Demeester, Brecht Vermeulen, Sam Lefebvre

Abstract—The design and implementation for the futurenursecall network is handled in a few distinct steps. First,there is the discussion of the current nursecall network.That also includes the definition of network parametersand the evaluation of the self-created software during myinternship at Televic.

The future network is built bottom-up. I first present thetopology possibilities with Ethernet-based networks. Af-ter that the services for the future network are discussed.To finish this part, quality of service (QoS) is introducedspecifically for this network’s purpose.

Finally comes the proof of concept, showing that the net-work with QoS is more reliable and has less delay than thenetwork without QoS.

Keywords—Maximum immediate bandwidth, Future nur-secall system, Quality of Service, Multiservice network.

INTRODUCTION

This master dissertation is performed in cooperationwith Televic, provider of nursecall technologies to hospi-tals and care homes. Their nursecall systems provide in-telligent ways of communication between patients andmedical staff.

Their current nursecall system is getting olderthough. There are parts of the network that are basedon Local Operating Network (LON) technology [1],which is both slow and hard to maintain.

This master dissertation focuses on the discussion oftheir current nursecall systems as well as the evolutiontowards a future all-IP (Internet Protocol) network.

I. THE CURRENT NURSECALL SYSTEM

Figure 1 shows an overview of the current network’stopology. It consists of a number of local centrals, re-ferred to as XT modules, which manage a number ofrooms1. All the rooms managed by the same XT mod-ule are connected using a LON bus. All XT modulescan communicate with each other and other servers orclients using the backbone IP network.

II. NETWORK PARAMETERS

Now that the systems has been quickly introduced,the first phase of this master dissertation can be ex-plained.

Using the method of statistical bootstrapping [8] itwas possible to create statistical models to model thedistribution of packets within one second, where thelogging server of the current nursecall system only al-lows second-precise timestamps.

For both data from IP and LON network in thedataset, there is at least one model that approximates

—————————————————–1In this extended abstract, the term “room” will be used in

stead of the term “node” to indicate the device that is placed ina patient’s room.

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�

��

�

�

��

�

�

��

�

�

��

�

�

��

�

�

��

�

��

��

Figure 1OVERVIEW OF THE CURRENT NURSECALL SYSTEM.

the correct maximum immediate bandwidth of thedataset. For the IP data, this is the mean model, withan accuracy of 79%. For the LON data, this is the me-dian model, with an accuracy of 59%.

III. COMPARISON STUDY

Another part of prediction was already performedduring my internship at Televic. There I created a tool topredict the packets on the network, given the log mes-sages from the logging server. This master dissertationalso validates that tool.

The predictions on the LON network are not good,they are only 23 to 30% accurate. The predictions onthe IP network are of better quality: 74 to 90%.

IV. THE NEW TOPOLOGY

When removing the LON-elements from the currentnursecall network, a topology constraint is relieved.This opens new possibilities. There are four differenttypes of topologies possible in the future nursecall sys-tem. These topologies are the way that rooms are to beconnected to the XT modules.

If they are kept in a bus topology, we need little ca-bles, but jeopardize the available bandwidth. When us-ing star topology, there is a much larger cable cost butevery room has a large bandwidth towards the XT mod-ule. Combining the best of both worlds results in a ringtopology, having a redundant link, which is disabledthrough the Rapid Spanning Tree Protocol (RSTP) [9].The cable costs are not as high as with star topologyand the available bandwidth is higher than in a normalbus topology. Finally there is also an ad-hoc topologypossible in which the network may have any topology.This provides the greatest amount of flexibility but addsmuch uncertainty of assured bandwidth into the net-work.

V. THE NEW SERVICES

Once the topology is in place, new services are to beadded to the future nursecall system.

A first service is the data service for nursecall mes-sages and control messages. The nursecall service runson TCP to have assured delivery. The second serviceis voice communication. This service can be deployedusing existing VoIP frameworks, consisting of a controlplane on SDP/SIP over TCP and a user plane carryingthe audio on RTP/RTCP over UDP [2].

A third service consists of multimedia broadcasting.Both audio and video can be distributed using IP mul-ticast to the different rooms. A fourth service is thebackground firmware update service. Using the FTPprotocol it is possible for rooms to download theirfirmware updates automatically. The last service is In-ternet access, which can be provided using standardDHCP/firewall/gateway solutions.

VI. QUALITY OF SERVICE

Now that the services have been discussed, Qualityof Service (QoS) is added. Differentiated Services (Diff-Serv) combined with VLAN priorities is a sturdy basis forthe network to guarantee priorities among the services.The priorities of the services are the same as the orderin which they were presented in the previous section,with nursecall being most important [5], [6], [7].

VII. PROOF OF CONCEPT

All elements have now been discussed to be able tocreate a working proof of concept. Only nursecall, videobroadcast and FTP were implemented, because of timeconstraints.

The proof of concept was done on the Virtual Wallat Ghent University. This is an experiment testbed likeEmulab from the University of Utah [4]. Using the ClickModular Router [3] it was possible to create QoS routersand switches for the test environment.

The experiment run consisted of 10 rooms, 10 Clickswitches, 1 Click router, 1 XT module and 1 back-endserver. All rooms continuously polled the file server,and received 20 multicast video streams from the samevideo streaming server. The rooms and XT communi-cated nursecall messages at a high pace in the mean-while. The test was run once without QoS and oncewith QoS. The results are shown in Figures 2 and 3.

0

500

1000

1500

2000

2500

3000

3500

4000

1 2 3 4 5 6 7 8 9 10

Del

ay(m

s)

Distance to XT (i.e. node number)

Maximum delay, direction: Node to XTAverage delay, direction: Node to XT

Maximum delay, direction: XT to NodeAverage delay, direction: XT to Node

Figure 2TEST RESULTS WITHOUT QOS.

0

500

1000

1500

2000

2500

3000

3500

4000

1 2 3 4 5 6 7 8 9 10

Del

ay(m

s)


Maximum delay, direction: Node to XTAverage delay, direction: Node to XT

Maximum delay, direction: XT to NodeAverage delay, direction: XT to Node

Figure 3TEST RESULTS WITH QOS.

The results are clear: using QoS reduces the maxi-mum message delay by 6 to 17 times. Also, there was nomessage loss even without QoS. This is probably thanksto TCP. There was no visual degradation of the videostreams. This may be accredited to the H.264/AVCvideo codec.

IMPROVEMENTS AND FUTURE WORK

Some of the most important improvements and futurework: less simplifications to the statistical models to in-crease their accuracy, optimization of the packet pre-diction tool, investigating the influence of RTSP on theavailable network bandwidth, extending SIP to commu-nicate with existing PSTN-networks, keeping IPv6 com-patibility in mind, performing larger tests on the VirtualWall, using PSNR to calculate video quality.

CONCLUSION

The statistical models have decent accuracies whenpredicting packet distribution within one second.

The validation of the prediction tool created duringmy internship at Televic resulted in a pass for the IPpart, but a no-pass for the LON part.

The removal of LON from the current nursecall net-work is best combined using QoS technologies. Testshave shown that the usage of QoS has a positive effecton the delay caused by a flooded network.

REFERENCES

[1] Echelon Corporation. LON network and protocols. http://www.echelon.com/, 01/11/2008.

[2] Piet Demeester and Mario Pickavet. Multimedia NetworksCourse. Ghent University, 2008.

[3] Eddie Kohler. The Click Modular Router. February 2001.http://read.cs.ucla.edu/click/, 19/05/2009.

[4] University of Utah. Emulab, Network Emulation Testbed.http://www.emulab.net, 06/05/2009.

[5] IEEE Computer Society. 802.1d: IEEE Standard for Lo-cal and metropolitan area networks: Medium Access Control(MAC) bridges. 2006.

[6] IEEE Computer Society. 802.1p: IEEE Standard for Lo-cal and metropolitan area networks: Medium Access Control(MAC) bridges, annex G: “User priorities and traffic classes”.2006.

[7] IEEE Computer Society. 802.1q: IEEE Standard for Localand metropolitan area networks: Virtual Bridged Local AreaNetwork. 2006.

[8] Wikipedia. Bootstrapping (statistics). http://en.wikipedia.org/wiki/Bootstrapping_(statistics),03/02/2009.

[9] Wald Wojdak. Rapid Spanning Tree Protocol: A new solutionfrom an old technology, volume March 2003.

Inhoudsopgave

Inhoudsopgave 1

Tabel van afkortingen en begrippen 3

1 Het huidige verpleegoproepsysteem 7

2 Netwerkparameters 9

2.1 Van logbericht tot statistisch model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Werkwijze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.1 Conversie naar tekstbestanden (Java) . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.2 Inlezen data en modellen (Matlab) . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.3 Opstellen van de modellen (Matlab) . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.4 Berekenen van de reele bandbreedte (Matlab): 1e stap van validatie . . . . . . . 15

2.3.5 Berekenen van gemodelleerde bandbreedte (Matlab): 2e stap van validatie . . . . 16

2.3.6 Praktisch gebruik van de modellen . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 Validatie en resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4.1 Onnauwkeurigheden en CRC-fouten . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4.2 Validatie LON-modellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4.3 Validatie IP-modellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.5 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Vergelijkende studie 22

3.1 Opzet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Problemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 Topologie 26

4.1 Entiteiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2 Bustopologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3 Stertopologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.4 Ringtopologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.5 Ad-hoc topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.6 Voeding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.7 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

1

5 Diensten 33

5.1 Data: verpleegoproepen en controleberichten . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1.1 Applicatielaag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1.2 Transportlaag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.2 Voice: intercomgesprekken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.2.1 Control Plane: SDP en SIP over TCP . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.2.2 User Plane: RTP en RTCP over UDP . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2.3 Entiteiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.3 Multimedia broadcasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.4 Firmware updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.5 Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.6 Beveiliging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.7 Netwerklaag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.8 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6 Quality of Service 40

6.1 Technologieen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.1.1 Netwerklaag: Internet Protocol (IP) . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.1.2 Datalinklaag: Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.2 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7 Implementatie 43

7.1 Vereenvoudigingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.2 Implementatie per dienst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.2.1 Basiswerking: Debian Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.2.2 Data: verpleegoproepen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.2.3 Video: XStreamer en VLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7.2.4 Firmware updates: File Transfer Protocol (FTP) . . . . . . . . . . . . . . . . . . . 50

7.3 Testopstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.3.1 Virtual Wall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.3.2 Topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.3.3 Configuratie van de nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.3.4 Problemen op de Virtual Wall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

7.4 Definitie van testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.5 Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.6 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Nawoord 62

Bibliografie 64

Lijst van figuren 66

Lijst van tabellen 68

2

Tabel van afkortingen en begrippen

ACK Acknowledgement

AF Assured Forwarding

ARP Address Resolution Protocol

AVC Advanced Video Coding

BBC British Broadcasting Corporation

BE Best Effort

Bitrate Snelheid waarmee data verstuurd kan worden of geencodeerd wordt.

BW BandWidth

CIDR Classless Inter-Domain Routing

Client Een computer die gebruik maakt van de diensten van andere computers

CRC Cyclic Redundancy Check, een manier om fouten in berichten op te sporen

CSMA/CD Carrier Sense Multiple Access with Collision Detection

CSV Comma-Separated Values

DAST The Distributed Applications Support Team

DHCP Dynamic Host Configuration Protocol

DiffServ Differentiated Services

DSCP DiffServ CodePoint

DTE Data Terminal Equipment

DVD Digital Versatile Disc

EF Expedited Forwarding

Emulatie Duplicatie van een systeem door implementatie op een ander systeem, maar met behoud

van dezelfde functionaliteit

FEC Forward Error Correction

FQDN Fully-Qualified Domain Name

FTP File Transfer Protocol

3

Gbps Gigabit per seconde = 1.000.000.000 bit per seconde

i.e. Latijn voor id est, betekent “dat is”, “dat wil zeggen”

I/O Input / Output

IANA International Assigned Numbers Authority

IDE Integrated Development Environment

IEEE Institute of Electrical and Electronics Engineers

IFS Inter Frame Start time, tijd tussen het begin van een pakket en het begin van het volgende

pakket

IGMP Internet Group Management Protocol

Interface Algemene term die een soort netwerkconnectie aanduidt, bijvoorbeeld een netwerkkabel-

contact op een switch

IntServ Integrated Services

IP Internet Protocol

iperf IP PERFormance, een programma om de doorvoercapaciteit van een netwerk te meten

IPG Inter-Packet Gap

IPv4 IP version 4

IPv6 IP version 6

ITU The International Telecommunication Union

ITU-T The Telecommunication Standardization Sector, deel van ITU

kbps Kilobit per seconde = 1000 bit per seconde

LAN Local Area Network

LED Light-Emitting Diode

LON Local Operating Network

LSP Label-Switched Path

MAC Medium Access Control

Mapping Bij gebrek aan een goede vertaling wordt mapping gebruikt om de afbeelding van een

verzameling op een andere aan te duiden

Mbps Megabit per seconde = 1000.000 bit per seconde

MDI Media Dependent Interface

MP3 MPEG-1 audio Layer 3

MPEG Moving Picture Experts Group

MPLS Multi-Protocol Label Switching

4

NAT Network Address Translation

NIC Network Interface Card

NLANR The National Laboratory for Applied Network Research

NS The Network Simulator

NTP Network Time Protocol

OSI Open Systems Interconnection

PC Personal Computer

PD Powered Device

PES MPEG-2 Primary Element Stream

PHB Per Hop Behaviour

PoE Power over Ethernet

PSE Power Sourcing Equipment

PSNR Peak Signal-to-Noise Ratio

PSTN Public Switched Telephone Network

QoS Quality of Service

RSTP Rapid Spanning Tree Protocol

RSVP Resource ReSerVation Protocol

RTCP RTP Control Protocol

RTP Real-time Transport Protocol

RVT Rust- en VerzorgingsTehuis

SDP Session Description Protocol

Server Een computer die diensten aanbiedt aan andere computers

SI Systeme International

SIP Session Initiation Protocol

SQL Structured Query Language

SSL Secure Socket Layer

STP Spanning Tree Protocol

SW SoftWare

TCP Transmission Control Protocol

TCP/IP Transmission Control Protocol / Internet Protocol

TLS Transport Layer Security

5

TS MPEG-2 Transport Stream

UA User Agent

us Andere schrijfwijze voor µs, microseconde

UTP Unshielded Twisted Pair

VLAN Virtual Local Area Network

VLC Betekende vroeger VideoLAN Client, nu geen betekenis meer

VoIP Voice over IP

VRT Vlaamse Radio- en Televisieomroep

VT4 Vlaamse Televisie 4

VTM Vlaamse Televisie Maatschappij

W Watt, SI-eenheid van vermogen

Wireshark Wireshark, Network Protocol Analyzer [4]

XML eXtensible Markup Language

XT module Beheert meerdere kamernodes

6

Hoofdstuk 1

Het huidige verpleegoproepsysteem

Deze masterproef behandelt het ontwerp van het toekomstige verpleegoproepsysteem, waarin diverse

nieuwe diensten aangeboden worden op een modern IP-netwerk.

Vooraleer het huidige systeem geanalyseerd of het nieuwe systeem besproken kan worden, is het nood-

zakelijk om het huidige systeem voor te stellen. Dit komt aan bod in dit hoofdstuk.

Overzicht

Het huidige verpleegoproepsysteem van Televic is een gedecentraliseerd systeem.

Dit wil zeggen dat alle kamers in het systeem worden opgesplitst in groepen van maximaal 100 kamers.

Elk van deze groepen heeft een centrale, die voortaan XT module genoemd wordt. De XT module wordt

verbonden met de kamers via een Local Operating Network (LON) databus [5]. Elke kamer bevat een

kamernode op deze databus. De snelheid van deze bus bedraagt ongeveer 78 kbps. De kamernodes

bevatten een aantal ingangen en uitgangen, die corresponderen met drukknoppen, lampjes, . . .

Deze ingangen en uitgangen worden met de kamernode verbonden via een eigen (proprietary) systeem.

Alle signalen van ingangen van de kamernode worden in de (intelligente) kamernode omgezet naar een

bericht. Dit bericht wordt vervolgens naar de XT module gestuurd. Deze XT module bevat genoeg infor-

matie om het bericht te verwerken en om er gepast op te reageren. Zo kunnen berichten teruggestuurd

worden vanuit de XT module naar de kamernodes om bijvoorbeeld uitgangen aan te sturen.

Meerdere XT modules worden verbonden via een IP-netwerk. Op ditzelfde IP-netwerk kunnen ook een

aantal extra clients en servers toegevoegd worden, bijvoorbeeld: verpleegpostsoftware, beheersoftware

en een logging server. Er is een maximum van 16 XT modules.

Wanneer een patient een oproep wil maken drukt hij/zij op de rode knop. De verpleegkundige wordt

hiervan op de hoogte gebracht. De verpleegkundige komt in de kamer en drukt op de groene knop om

aan te geven dat er aanwezigheid is in de kamer. De oproep is dan beeindigd. Om de aanwezigheid te

beeindigen moet opnieuw op de groene knop gedrukt worden.

In de volgende hoofdstukken zal expliciet verwezen worden naar specifieke functionaliteit van het sys-

teem. Hieronder worden de belangrijkste functies besproken:

Overzichtsbord of LED-paneel: dit bord toont alle aanwezigheden/oproepen van alle kamers van een

bepaalde dienst.

(Op)roepachtervolging: wanneer een patient een oproep doet door bijvoorbeeld op een knop te druk-

ken, wordt steeds een verpleegkundige op de hoogte gebracht. Wanneer deze verpleegkundige

echter in een andere kamer aanwezig is, is het niet mogelijk om bijvoorbeeld het overzichtsbord

7

in te observeren. Daarom wordt oproepachtervolging gebruikt. Bij oproepachtervolging is een

verpleegkundige aangemeld als “aanwezig” in een kamer. Alle oproepen die in een andere gebeu-

ren terwijl de verpleegkundige aanwezig is in die kamer, worden op die kamernode getoond aan

de hand van een scherm op de node en/of een pieptoon.

Zorgserver: om een volledigere oplossing te bieden voor ziekenhuizen en rusthuizen is het mogelijk

om ook zorgregistratie te voorzien op het verpleegoproepsysteem. Voor elke patient wordt door

de behandelende arts en een verantwoordelijke verpleegkundige een schema opgesteld van de

nodige medicatie en verzorging. Hieruit worden dagelijkse taken geextraheerd voor elke patient.

Deze taken zijn bijvoorbeeld: wassen van de patient, medicatie X toedienen, controleren bloed-

druk. Deze taken kunnen ingevoerd worden in een “zorgserver”, die dan communiceert met elke

kamernode om er de taken op weer te geven, en die de verpleegkundige toelaat om bepaalde

taken als “afgewerkt” aan te duiden in het systeem. Dit kan allemaal terwijl de verpleegkundige

nog aanwezig is in de kamer van de patient.

Figuur 1.1 geeft een overzicht van de topologie van het huidige verpleegoproepsysteem.

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�

��

�

�

��

�

�

��

�

�

��

�

�

��

�

�

��

�

��

��

Figuur 1.1: Overzicht van de topologie van het huidige verpleegoproepsysteem.

8

Hoofdstuk 2

Netwerkparameters

Het eerste doel van deze masterproef is om een aantal netwerkparameters te bepalen op het huidige

netwerk. Hierop kan vervolgens een gefundeerde voorspelling gemaakt worden van de benodigde pa-

rameters op het toekomstige netwerk.

In een initiele fase werd gedacht aan klassieke parameters als delay, jitter, aantal pieken, breedte en

hoogte van de pieken, . . .

De invoergegevens voor de parameterbepaling zijn echter van zeer discrete aard. De logberichten1

hebben namelijk een tijdsnauwkeurigheid van slechts 1 seconde. Hierdoor zijn de hiervoor genoemde

begrippen niet bruikbaar.

De traditionele parameters kunnen dus niet aangewend worden, maar toch moet er een maat gedefini-

eerd worden om de belasting op het netwerk aan te kunnen geven.

Dit hoofdstuk bespreekt een discrete versie van de parameter “netwerkbelasting”. Deze parameter heet

voortaan “maximale onmiddellijke bandbreedte” en geeft een indicatie van de maximale belasting op

het netwerk.

2.1 Van logbericht tot statistisch model

Gegeven de logberichten kan aan de hand van de StateMachine software [21] voorspeld worden2 welke

pakketten per seconde op het netwerk geplaatst werden.

Om een idee te hebben van de piekbandbreedte of algemene belasting van het netwerk, moet er uiter-

aard informatie beschikbaar zijn over wat binnen de grenzen van 1s gebeurt. De precieze informatie

kan niet meer achterhaald worden, wegens de te grote granulariteit van de logberichten.

Om toch binnen de grenzen van 1s te treden, wordt gebruik gemaakt van een statistisch model. Dit

model moet bepalen wat de Inter Frame Start times (IFS) zijn van de voorspelde pakketten3. Een IFS

is de tijd tussen het begin van een pakket en het begin van het volgende pakket, zie Figuur 2.1. Deze

tijd kan bij benadering enkel bepaald worden indien we kennis hebben van de distributie van de tijden

tussen twee pakketten binnen 1 seconde. Wegens de beperkte omvang van deze masterproef werd

gekozen om geen gesloten gedaante te zoeken voor deze distributie. In plaats van een gesloten gedaante

wordt geopteerd om via een procede te werken dat sterk lijkt op de methode van bootstrapping.

1Een logbericht kan voorgesteld worden als een rij in een tabel. De tabel heeft velden als datum, tijd, soort oproep, locatie,naam verpleegkundige, . . .

2De staving van deze voorspelling wordt in het volgende hoofdstuk besproken.3Merk op dat deze definitie zowel in afkorting als betekenis afwijkt van de gangbare Inter-Packet Gap (IPG), die de tijd tussen

twee pakketten beschouwt. In deze context beschouwen we echter de tijd van het begin van een pakket tot het begin van hetvolgende pakket.

9

Bootstrapping is een herbemonsteringsmethode die nieuwe monsterwaarden construeert van een geob-

serveerde dataset, door het nemen van willekeurige monsters uit de oorspronkelijke dataset [34].

��

��

�

Figuur 2.1: Verschil tussen de klassieke IPG en de gebruikte IFS.

Het verkeer bestaat enerzijds uit pakketten met korte IFS van bij elkaar horende transacties en ander-

zijds pakketten met een veel langere IFS tussen twee transacties die geısoleerd zijn. Hierdoor wordt een

histogram van de IFS’s verwacht met bij benadering twee grote pieken: een voor de kleine en een voor

de grote IFS’s.

2.2 Werkwijze

Om de bootstrappingstechniek, zoals hierboven beschreven, uit te voeren wordt een dataset gebruikt die

bekomen werd uit een bestaande implementatie van het huidige verpleegoproepsysteem. Deze dataset

werd bekomen door alle pakketten op zowel een LON-netwerk als het IP-netwerk te verzamelen. Er

werd ongeveer 18 uur verzameld op het LON-netwerk en ongeveer 3 dagen op het IP-netwerk.

De pakketten op het IP-netwerk moeten eerst gefilterd worden om enkel pakketten te beschouwen die

met zekerheid van het verpleegoproepsysteem komen. De eenvoudigste manier om dit te filteren is door

te filteren op basis van de IP-adressen van de XT modules, omdat alle pakketten afkomstig zijn van een

XT module of ervoor bestemd zijn. Op het LON-netwerk moet niet gefilterd worden omdat daar alle

pakketten van het verpleegoproepsysteem afkomstig zijn.

Vervolgens worden deze pakketten samengebracht4 en gesorteerd en worden duplicaten van overlap-

pende bestanden verwijderd. De software die hiervoor werd gebruikt, werd tijdens deze masterproef

geprogrammeerd in Java en verwerkt XML-bestanden (Extensible Markup Language) voor LON en CSV-

bestanden (Comma-Separated Values) voor IP. Het resultaat hiervan is een lijst met de tijdsmarkeringen

van de waargenomen pakketten.

In deze lijst worden nu de IFS’s berekend tussen de opeenvolgende pakketten. Enkel deze IFS’s worden

verder verwerkt. In deze lijst van IFS’s bevinden zich nog waarden die groter zijn dan 1s, van pakketten

die dus verder dan 1s van elkaar verwijderd waren. Deze mogen verwijderd worden. Er wordt namelijk

binnen de grenzen van 1s gezocht naar de verdeling van IFS’s, dus IFS’s groter dan 1s zijn niet relevant.

Beide lijsten van IFS’s bevatten een rudimentaire verdeling van de IFS’s binnen 1s.

Tabel 2.1 toont de hoeveelheid IFS’s die groter zijn dan 1s voor beide gemeten datasets.

Dataset Totaal IFS’s Percentage groter dan 1sLON 209 931 1.71 %

IP 173 052 26.68 %

Tabel 2.1: Overzicht van de IFS’s van beide datasets.

Gegeven een aantal pakketten dat binnen 1s op het netwerk verwacht worden, is het nu de bedoeling

om de IFS’s tussen die pakketten te voorspellen. De IFS’s hangen echter af van het aantal pakketten dat

per seconde verwacht wordt aangezien bij 30 pakketten de IFS’s niet erg groot zullen zijn in vergelijking

4De pakketten werden verzameld in verschillende bestanden, wegens een aantal onhandige eigenschappen van de softwareom de pakketten te verzamelen.

10

met de IFS’s in het geval er slechts 1 pakket verwacht wordt. Dus moet het model per aantal pakketten

per seconde een verdeling van de IFS’s berekenen. Met andere woorden, er moet een model bestaan

dat de verdeling van de IFS’s geeft als er 1 pakket is, als er 2 pakketten zijn, enzovoort. Stellen we een

blokschema op dan zouden deze verdelingen per aantal berichten per seconde de rijen voorstellen in

Figuur 2.2.

��

��

� � � ��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

��

�

��

Figuur 2.2: Schematische voorstelling van de te berekenen verdelingen.

Er kan een maximale waarde gekozen worden voor het aantal pakketten per seconde, maar dit is geen

beperking, het model kan opnieuw berekend worden voor een hoger aantal pakketten.

Om nu dit model te bepalen worden per rij in het blokschema 1000 monsters genomen uit de dataset

voor zowel LON als IP5, dus 1000 monsters voor 1 pakket, 2000 monsters voor 2 pakketten, . . .

5Deze werkwijze moet voor LON en IP apart beschouwd worden, en moet dus tweemaal doorlopen worden. Voor de eenvoud

11

Een monster in rij n van het blokschema komt overeen met een mogelijke verdeling van n pakketten

binnen 1s. Dit monster bevat dus n IFS’s6.

Merk op dat indien er n pakketten per seconde voorspeld worden, en we de monsters IFS(j)i , i ∈

{1, . . . , n}, j ∈ {1, . . . , 1000} noemen, de som van deze monsters kleiner moet zijn dan 1s, of:

n∑i=1

IFS(j)i < 1s,∀j.

De som van alle IFS’s van een monster moet kleiner zijn dan 1 omdat anders een pakket over de grens

van 1 seconde gaat. Een belangrijke opmerking hierbij is dat, indien de pakketten erg groot zijn of het

medium erg traag is en er dus veel tijd in beslag genomen wordt voor elk pakket, de som van de IFS’s

en de tijden dat pakketten op het netwerk aanwezig zijn ook groter kan zijn dan 1. Dat komt dan niet

door de som van de IFS’s maar door de lange tijd dat een pakket op het netwerk aanwezig is. In de

modellen wordt hier echter geen rekening mee gehouden om deze beschouwing eenvoudig te houden.

Indien een monster niet voldoet aan de eis dat de som van zijn IFS’s kleiner is dan 1s, dan wordt een

nieuw monster genomen totdat wel aan deze voorwaarde voldaan is.

Het is ook mogelijk om het model rekening te laten houden met het aantal pakketten per seconde

inclusief de grootte van de pakketten. De grootte van de modellen neemt hierdoor echter wel zeer

sterk toe, maar biedt een betere benadering van de realiteit. Hier is echter ook een veel grotere

dataset voor nodig om de modellen te trainen. Dit kan in de toekomst nog onderzocht worden.

Uit deze monsters wordt telkens de mediaan, het gemiddelde en de variantie genomen. Dus voor 1 pak-

ket wordt de mediaan, het gemiddelde en de variantie van 1000 monsters genomen, voor 2 pakketten

wordt de mediaan, het gemiddelde en de variantie van de eerste 1000 en de mediaan, het gemiddelde

en de variantie van de tweede 1000 monsters genomen, . . .

Op basis van deze parameters worden drie soorten modellen opgesteld: een model dat enkel gebruik

maakt van de mediaan als representatieve waarde voor de 1000 monsters, een model dat enkel gebruik

maakt van het gemiddelde van deze waarden en een model dat gebruik maakt van het gemiddelde en

de variantie om een representatieve waarde te berekenen. Uiteraard heeft elk soort model een aantal

instanties voor de verschillende rijen uit het blokschema.

Het model dat gebruik maakt van het gemiddelde en de variantie wordt hier slechts bij wijze van

illustratie opgenomen en moet verder onderzocht worden naar geldigheid.

wordt hier telkens slechts 1 netwerk tegelijk beschouwd.6De keuze om 1000 monsters te nemen is willekeurig. Een kleinere of grotere waarde kan ook gebruikt worden. Voor de

eenvoud wordt 1000 gekozen.

12

Figuur 2.3 illustreert de beschreven werkwijze.

��

��

�

��

��

�

�

�

�

��

��

��

��

Figuur 2.3: Werkwijze bij het opstellen van de modellen voor de IFS’s (histogram slechts ter illustratie).

13

2.3 Implementatie

Deze sectie behandelt de implementatie voor het bouwen en het gebruiken van de statistische modellen.

Het merendeel van deze implementatie gebeurde in Matlab.

Meer uitleg over de code staat op de website op de bijgevoegde cd-rom.

De code voor alle Matlab functies is terug te vinden op de cd-rom onder thesis/matlab.

2.3.1 Conversie naar tekstbestanden (Java)

De eerste stap in het proces is het inlezen van de gemeten pakketten op de netwerken.

Het is niet mogelijk om in Matlab .pcap bestanden in te lezen, en het is gemakkelijker om tekstbe-

standen te lezen dan .xml bestanden. Daarom worden de datasets omgezet naar tekstbestanden. Beide

NetBeans projecten IPConverter en LONConverter werden ontwikkeld voor deze masterproef om de ruwe

datasets om te zetten naar eenvoudige tekstbestanden. Daarna kan deze data in Matlab ingelezen wor-

den [19].

Er zijn twee soorten data nodig voor de statistische verwerking: de IFS’s van de pakketten om de model-

len op te stellen en de meer gedetailleerde data om de modellen te valideren. Deze meer gedetailleerde

data bevatten de oorspronkelijke tijdsaanduidingen en groottes van de pakketten.

Deze informatie wordt in twee soorten bestanden geplaatst: diff.txt en data.txt. De bestanden

hebben volgend formaat:

diff.txt:

diff_time_us_1_2

diff_time_us_2_3

...

en

data.txt:

fraction_s_1 fractions_us_1 length_1

fraction_s_2 fractions_us_2 length_2

...

Hierbij is diff time us x y de tijd tussen het begin van pakket x en het begin van pakket y.

fraction s x is het seconde-gedeelte waarop pakket x ontvangen werd en fraction us x het reste-

rende gedeelte van de tijd. length x geeft de lengte van pakket x aan in bytes.

De conversies naar de bestanden diff.txt en data.txt moeten gedaan worden voor zowel LON als IP.

De datasets worden strikt gescheiden bij de verwerking van de gegevens, aangezien het om verschillende

protocols en media gaat.

De code van beide projecten staat op de cd-rom onder thesis/java/IPConverter en

thesis/java/LONConverter.

2.3.2 Inlezen data en modellen (Matlab)

Eens de datasets omgezet zijn naar tekstbestanden kunnen ze ingelezen worden in Matlab. Dit gebeurt

door middel van 4 functies:

14

• readLONdiff en readLONdata: leest de bestanden diff.txt en data.txt voor de LON data die

in de vorige stap gegenereerd werden en plaatst ze in een geschikte datastructuur om er later

verdere bewerkingen op te doen;

• readIPdiff en readIPdata: leest de bestanden diff.txt en data.txt voor de IP data die in de

vorige stap gegenereerd werden en plaatst ze in een geschikte datastructuur om er later verdere

bewerkingen op te doen.

De omzetting van tekstbestand naar datastructuur in Matlab is triviaal: de data uit de bestanden worden

in matrixvorm geplaatst.

Ook de modellen die in sectie 2.3.3 opgebouwd zullen worden, moeten ingelezen worden tijdens

het validatie- of het gebruiksproces. Hiervoor zijn 2 functies voorzien, namelijk readLONModels en

readIPModels.

2.3.3 Opstellen van de modellen (Matlab)

Eens de differentiele gegevens beschikbaar zijn, kan de verwerking beginnen. Het doel van deze stap is

om op basis van deze gegevens een model op te bouwen.

De functie buildModels stelt alle modellen op voor zowel LON als IP en verwacht geen parame-

ters. Voor LON en IP worden drie modellen weggeschreven naar de bestanden medianmodel.txt en

avgvarmodel.txt.

Beide bestanden bevatten piramides van data. Met piramides van data wordt bedoeld dat de eerste lijn

een waarde bevat, de tweede lijn twee waarden, . . . tot 100 lijnen. Lijn 101 in avgvarmodel.txt bevat

de eerste lijn voor de variantiewaarde.

In medianmodel.txt wordt dus een piramide opgeslagen voor de mediaan en in avgvarmodel.txt twee

piramides, een voor het gemiddelde en een voor de variantie.

Deze waarden zijn de parameters voor de IFS’s die het model berekent. Dus een waarde van bijvoorbeeld

13507 op de eerste lijn van medianmodel.txt betekent:

indien er slechts 1 pakket optreedt binnen de grenzen van een seconde, dan is 13507 de

mediaan van 1000 monsterwaarden van IFS’s tussen het begin van die seconde en het begin

van het pakket

of dus het aantal µs dat het begintijdstip van dat pakket verwijderd is van het begin van de

seconde.

Als bijvoorbeeld op de tweede lijn in medianmodel.txt de waarden 5322 en 59938 staan betekent dit:

indien er binnen de grenzen van 1 seconde twee pakketten verstuurd werden, dan wordt

de begintijd van het eerste pakket gemodelleerd op 5322µs en de begintijd van het tweede

pakket op 5322 + 59938 = 65260µs. Deze tijdstippen zijn relatief ten opzichte van het begin

van de beschouwde seconde.

Hoewel in deze sectie sprake was van 3 modellen worden slechts 2 bestanden gegenereerd. Het bestand

avgvarmodel.txt kan namelijk gebruikt worden door zowel het gemiddeldemodel als het model dat ge-

bruik maakt van het gemiddelde en de variantie. Enkel het mediaanmodel gebruikt medianmodel.txt.

Zie Figuur 2.4 voor een grafische weergave hiervan.

2.3.4 Berekenen van de reele bandbreedte (Matlab): 1e stap van validatie

De vooraf opgestelde modellen vormen de basis voor het voorspellen van de IFS’s tussen pakketten

binnen een seconde indien de tijdsaanduiding van de pakketten niet voldoende precies is.

15

��

��

��

��

Figuur 2.4: Schematische voorstelling van bestanden medianmodel.txt en avgvarmodel.txt en hungebruik bij de drie verschillende modellen.

Een belangrijke stap is om deze modellen te valideren tegenover de reele data. Het spreekt voor zich

dat de gemodelleerde data niet de oorspronkelijke tijdsaanduidingen opleveren. Maar het moet wel

mogelijk zijn om de maximale onmiddellijke bandbreedte zo goed mogelijk te benaderen.

Om uitspraak te doen over de benadering tussen de reele bandbreedte en de gemodelleerde bandbreedte

moet uiteraard de reele piekbandbreedte berekend kunnen worden. Dit werd geımplementeerd in de

functie getMaxBandwidth. Deze functie verwacht 3 parameters. De eerste parameter is de data zelf,

geformatteerd zoals uitgelezen uit een databestand: (tijd, lengte) paren in matrixvorm. De tweede

parameter is de bandbreedte van het medium waarop deze data beschouwd worden. Dit is noodzakelijk

om te weten of een pakket de voorziene begrenzing van 1 seconde niet overschrijdt. Indien dit toch

gebeurt kan een fractie van dat pakket gebruikt worden om de rest van die seconde te vullen. De laatste

parameter geeft de grootte van het venster aan dat over de data geschoven wordt ter bepaling van de

piekbandbreedte.

Het is niet zinvol om een waarde voor het venster te kiezen die kleiner is dan de maximale duur van

een pakket op het netwerk. Anders is de piekbandbreedte steeds de beschikbare bandbreedte op het

medium. Dit levert geen nieuwe informatie op en is dus niet gewenst.

Als het venster bijvoorbeeld 50µs lang is en het langste pakket zich 60µs op het medium bevindt, dan

vult dit langste pakket het venster volledig. Dan wordt een bandbreedte berekend die gelijk is aan de

lijnsnelheid van het medium.

Een richtlijn voor LON voor de venstergrootte is de maximale duur van een pakket maal 10. Voor IP

geeft dit een onmogelijke rekentijd, aangezien de dataset voor IP meerdere dagen beslaat en pakketten

op IP erg kort op het medium verschijnen. Voor IP wordt gekozen voor een venstergrootte van 50ms.De berekening van de maximale onmiddellijke bandbreedte gebeurt nu door het venster te schuiven over

de dataset en telkens binnen dat venster de onmiddellijke bandbreedte te berekenen. Het maximum

van alle onmiddellijke bandbreedtes van elk venster wordt dan gebruikt als maximale onmiddellijke

bandbreedte.

2.3.5 Berekenen van gemodelleerde bandbreedte (Matlab): 2e stap van validatie

Het enige dat nog overblijft voor de validatie is de berekening van de gemodelleerde maximale onmid-

dellijke bandbreedte. Dit is de maximale onmiddellijke bandbreedte indien de IFS’s gegeven worden

door een van de hierboven opgestelde modellen. Dus in plaats van de reele IFS’s te gebruiken, worden

de IFS’s gebruikt die berekend werden door een van bovenstaande modellen.

16

Concreet wordt eerst de originele dataset gediscretiseerd. Dit gebeurt in de functie discretizeDataset.

De tijdsaanduidingen in microseconden van de oorspronkelijke dataset worden weggelaten. Enkel de

tijdsaanduidingen per seconde en de lengte van de pakketten blijven over. Dit komt overeen met de

data die uit de logberichten gehaald kunnen worden.

Vervolgens worden per seconde de pakketten in een aparte matrix geplaatst. Deze matrices worden

in een Matlab-cell7 geplaatst. Elke rij in de cell stelt een seconde voor. In de eerste kolom wordt de

tijdsaanduiding in seconden geplaatst en in de tweede kolom worden de pakketten die binnen deze

seconde starten geplaatst. De tweede kolom bevat dus telkens opeenvolgingen van pakketgroottes.

De volgorde van deze pakketgroottes en aldus de volgorde van de eigenlijke pakketten blijven wel

behouden, het is enkel de precisie binnen de seconde die weggelaten wordt. Figuur 2.5 geeft een

schematisch overzicht van de cell datastructuur.

Tijd in µs Lengte

31679384xxxxxx 1631679384xxxxxx 1231679384xxxxxx 1631679386xxxxxx 16...

(a) Voor discretisatie: matrix

Tijd in s Lijst van lengtes in bytes

31679384 [16, 12, 16]31679385 []31679386 [16]31679387 []...

(b) Na discretisatie: Matlab cell

Figuur 2.5: Voorbeeld van een Matlab cell die door discretizeDataset wordt gegenereerd.

Vervolgens worden via de functie calculateModelledData de data gemodelleerd zoals in vorige sectie

uitgelegd werd: binnen elke seconde wordt het aantal pakketten geteld. Dit aantal wordt opgezocht

in het model en voor elk pakket wordt een nieuwe tijdswaarde berekend, tot op 1µs nauwkeurig. Dit

model kan zowel het mediaan-, het gemiddelde- of het gemiddelde- en variantiegebaseerde model zijn.

Deze nieuwe data kunnen nu aan de functie getMaxBandwidth gegeven worden om de maximale band-

breedte te berekenen.

De resultaten van deze validatie worden in de volgende sectie besproken.

2.3.6 Praktisch gebruik van de modellen

Om de modellen te gebruiken in de praktijk, wanneer men dus beschikt over een discrete dataset,

volstaat het om deze dataset door de functie calculateModelledData te voeren en aan de functie

getMaxBandwidth door te geven.

Voor de validatie wordt concreet gewerkt met de functies datasetMaxBW en datasetModelMaxBW. De

eerste functie voert de stappen uit 2.3.4 uit om de reele bandbreedte te berekenen. De tweede functie

bundelt de stappen uit 2.3.5 om de gemodelleerde bandbreedte te berekenen.

Beide functies leveren zeer leesbare resultaten op, zie Figuur 2.6.

2.4 Validatie en resultaten

2.4.1 Onnauwkeurigheden en CRC-fouten

Bij de metingen op het LON-netwerk zijn een aantal problemen opgetreden. Deze paragraaf beschrijft

de problemen en de manier waarop ze aangepakt werden.

7Een cell in Matlab is een soort matrix waar elk element van de matrix opnieuw een matrix is, maar zonder dat de dimensieservan moeten overeenkomen. Een leeg item in een cell of een item met een matrix van 10× 1 worden allemaal ondersteund doordit datatype.

17

Starting LON calculation of maximum bandwidth...

Maximum bandwidth on LON (real): 26094 (window 38974).

Starting IP calculation of maximum bandwidth...

Maximum bandwidth on IP (real): 412160 (window 50000).(a) datasetMaxBW: berekening maximale reele bandbreedte

Starting LON calculation of maximum bandwidth...

LON max bandwidth (window 38974 us, line rate 78000 Bps):

Median model: 44336

Avg model: 132394

AvgVar model: 129726

Starting IP calculation of maximum bandwidth...

IP max bandwidth (window 50000 us, line rate 100000000 Bps):

Median model: 137120

Avg model: 324160

AvgVar model: 324160(b) datasetModelMaxBW: berekening maximale gemodelleerde bandbreedte

Figuur 2.6: Uitvoer van de functies datasetMaxBW en datasetModelMaxBW, alle onbenoemde getallenzijn uitgedrukt in kbps.

Onnauwkeurigheden

De tijdsaanduidingen van de beschikbare data op het LON-netwerk zijn onnauwkeurig. Een voorbeeld

hiervan is volgend extract uit een XML-bestand (LON). Zie Figuur 2.7 voor een gedetailleerd tijdsver-

loop:

<PACKET>

<Num>9360</Num>

<Time>11-25T16:33:10,613752</Time>

<Attr />

<Type>Acknowledged</Type>

<Source>S/N:001/120</Source>

<Destination>S/N:001/016</Destination>

<Data>Msg_0x01: Code: 0x01, Data: 0x... </Data>

<Length>30</Length>

<TX>2</TX>

</PACKET>

<PACKET>

<Num>9361</Num>

<Time>11-25T16:33:10,614005</Time>

<Attr />

<Type>Acknowledgment</Type>

<Source>S/N:001/016</Source>

<Destination>S/N:001/120</Destination>

<Data />

<Length>12</Length>

<TX>2</TX>

</PACKET>

Het eerste pakket is 30 bytes lang en duurt dus op het LON-medium:

30bytes× 878000bits/s

= 3076µs

Het volgende pakket is echter reeds na 253µs op het netwerk te zien. Hier is een onnauwkeurigheid

opgetreden bij het meten. Om dit op te lossen wordt voor de berekening van de maximale bandbreedte

gekozen voor een langer schuivende venster. Zo worden de onnauwkeurigheden uitgemiddeld.

18

��

�

��

��

��

��

��

��

��

��

Figuur 2.7: Gedetailleerd tijdsverloop van twee pakketten op het LON-netwerk ter illustratie van delage nauwkeurigheid van de LON-metingen.

CRC-fouten

Een CRC-fout (Cyclic Redundancy Check) doet zich voor op het LON-netwerk indien een pakket niet goed

ontvangen wordt door de bestemmeling. Dit kan twee oorzaken hebben: een te belast netwerk of een

te ruisgevoelige drager.

Het aantal CRC-fouten mag op een netwerk met LON-technologie niet meer bedragen dan 4% [6]. Het

aantal CRC-fouten in de dataset bedraagt 43538 op 209932 pakketten, of dus ongeveer 21%. Dit heeft

een negatieve invloed op het opstellen van de modellen aangezien er door de CRC-fouten 21% verhoogd

verkeer is op het netwerk.

2.4.2 Validatie LON-modellen

Tabel 2.2 geeft de werkelijke maximale onmiddellijke bandbreedte en de maximale onmiddellijke band-

breedtes bij gebruik van een van de drie modellen voor het LON-netwerk. Hieruit blijkt dat het mediaan-

model een goede benadering is voor de reele maximale onmiddellijke bandbreedte met een correctheid

van 59%. De andere modellen leveren slechte resultaten op. Er moeten echter nog veel meer gegevens

beschikbaar zijn om hierover een juiste conclusie te kunnen trekken. maxtime duidt op de duurtijd van

het langste pakket.

Merk op dat de waarden voor het model dat gebruik maakt van het gemiddelde en de variantie bij elke

berekening anders zijn, in tegenstelling tot de andere modellen. Dit komt omdat gewerkt wordt met

willekeurige waarden uit een distributie met gegeven parameters.

Venstergrootte Maximale bandbreedteReeel 10×maxtime = 38974µs 26,094 kbpsMediaanmodel 38974µs 44,336 kbpsGemiddeldemodel 38974µs 132,394 kbpsGemiddelde en variantiemodel 38974µs 138,552 kbps

Tabel 2.2: Resultaten van reele en gemodelleerde maximale bandbreedtes op het LON-netwerk.

De berekende maximale onmiddellijke bandbreedte is echter zeer gevoelig voor veranderingen aan de

grootte van het schuivende venster. Figuur 2.8 (op het einde van dit hoofdstuk) toont de berekende

maximale onmiddellijke bandbreedte voor verschillende groottes van het schuivende venster voor LON.

2.4.3 Validatie IP-modellen

Tabel 2.3 geeft de werkelijke maximale onmiddellijke bandbreedte en de maximale onmiddellijke band-

breedtes wanneer gebruik gemaakt wordt van een van de drie modellen voor het IP-netwerk. Voor

IP blijkt dat het gemiddeldemodel de beste resultaten geeft met een correctheid van 79%. De andere

19

modellen geven minder goede resultaten. Ook hier zijn meer gegevens nodig om juiste conclusies te

kunnen trekken.

Venstergrootte Maximale bandbreedteReeel 50000µs 412,160 kbpsMediaanmodel 50000µs 137,120 kbpsGemiddeldemodel 50000µs 324,160 kbpsGemiddelde en variantiemodel 50000µs 558,560 kbps

Tabel 2.3: Resultaten van reele en gemodelleerde maximale bandbreedtes op het IP-netwerk.

Figuur 2.9 (op het einde van dit hoofdstuk) toont de berekende maximale onmiddellijke bandbreedte

voor verschillende groottes van het schuivende venster voor IP.

Achteraf gezien is de berekening van de bandbreedtes voor het IP-netwerk niet correct. Het LON-

netwerk is een shared medium en kent dus geen bidirectionaliteit. Het IP-netwerk heeft wel bidirecti-

onaliteit maar dat werd in de berekening niet weerspiegeld. Hiervoor is echter ook een betere kennis

nodig van de exacte topologie van de geobserveerde implementatie. Hier moet in de toekomst op gelet

worden.

2.5 Conclusie

De eerste resultaten van de validatie van de opgebouwde statistische modellen tonen aan dat er voor

zowel LON als IP een model te vinden is dat vrij goed aansluit bij de reele maximale onmiddellijke

bandbreedte. Er moeten echter veel meer data beschikbaar zijn om de modellen correct te kunnen

valideren.

Het opstellen van de statistische modellen had als doel om, gegeven een aantal voorspelde pakket-

ten per seconde, een idee te geven van de distributie van die pakketten binnen de seconde en er een

performantiemaat bij te plaatsen, namelijk de maximale onmiddellijke bandbreedte.

Het volgende hoofdstuk bespreekt de validatie van de software die de voorspelling doet van logbericht

naar aantal pakketten per seconde.

20

0

20

40

60

80

100

0 100000 200000 300000 400000 500000 600000 700000 800000 900000 1e+006

Max

imum

imm

edia

teba

ndw

idth

(kbp

s)

Window size (µs)

Real Bandwidth

Median Model

Average Model

Average/Variance Model

Physical Limit

Figuur 2.8: Resultaat van berekeningen van de maximale onmiddellijke bandbreedte voor verschillendewaarden voor het schuivende venster (LON).

0

100

200

300

400

500

600

0 100000 200000 300000 400000 500000 600000 700000 800000 900000 1e+006

Max

imum

imm

edia

teba

ndw

idth

(kbp

s)

Window size (µs)

Real Bandwidth

Median Model

Average Model

Average/Variance Model

Figuur 2.9: Resultaat van berekeningen van de maximale onmiddellijke bandbreedte voor verschillendewaarden voor het schuivende venster (IP).

21

Hoofdstuk 3

Vergelijkende studie

De tweede stap van deze masterproef is de validatie van de eerder ontwikkelde “StateMachine” soft-

ware. Deze software werd ontwikkeld tijdens de stage die vooraf ging aan deze masterproef. Deze

software neemt een aantal logbestanden van de logging server als invoer en geeft een voorspelling plus

visualisatie van het verkeer dat hierdoor veroorzaakt werd op IP en LON [21].

De software heeft een belangrijke vereenvoudiging ten opzichte van het reele systeem:

• Er is slechts 1 type oproep en slechts 1 type aanwezigheid mogelijk. Op het reele systeem zijn

verschillende soorten mogelijk zoals: tweede aanwezigheid, sanitaire oproep, assistentie, . . . De

reactie op elke oproep in het reele systeem varieert ook sterk van implementatie tot implementa-

tie: in bepaalde ziekenhuizen wordt een sanitaire oproep ook met oproepachtervolging ingesteld

terwijl dit in andere ziekenhuizen niet het geval is.

Met andere woorden: de fijne configuratie-instellingen worden niet door de software ondersteund.

Ze worden vertaald naar zeer rudimentaire instellingen.

3.1 Opzet

Het doel van deze studie is om de de software te valideren. Concreet vertaalt dit zich naar de berekening

van een correctheidspercentage van de software ten opzichte van het reele systeem.

Om dit te realiseren is een aantal gegevens nodig:

• Logbestanden van de logging server van de te observeren implementatie (Microsoft Access data-

banken);

• Wireshark dataset van de berichten die over IP verstuurd worden;

• LonScanner dataset van de berichten die over LON verstuurd worden;

• Configuratie van het systeem (Microsoft SQL databank).

Al deze gegevens werden door Televic ter beschikking gesteld voor deze masterproef. Er werden logging

bestanden van 6 dagen voorzien, IP datasets van 3 dagen, LON datasets van 2 dagen van slechts 1 van de

twee LON-netwerken (zie Figuur 3.1) en de recentste instellingen van de geobserveerde implementatie.

Deze gegevens zijn afkomstig van een rust-en verzorgingstehuis (RVT) in Vlaanderen.

Per logbericht moet er gezocht worden naar de bijhorende pakketten op IP en LON. Hiervoor werden

de IPConverter en LONConverter uit de statistische verwerking (zie sectie 2.3.1) uitgebreid zodat de

uitvoer van die programma’s meer gedetailleerde informatie bevat over de inhoud van de pakketten.

Hiervoor wordt dezelfde werkwijze gebruikt als in 2.3.1, maar met extra parameter “translate”.

22

De configuratie van het systeem wordt op een PC ingeladen in de conversiesoftware om de verschillende

kamernodes en de systeemparameters te declareren voor de software (zie ook sectie 3.5 in [21]). De

conversiesoftware moet namelijk op de hoogte zijn van alle kamernodes zodat de juiste oproepachter-

volgingsparameters bekend zijn.

Op basis van de logbestanden wordt met behulp van de software een voorspelling gedaan van de pak-

ketten op IP en LON. Deze voorspelling wordt dan getoetst aan de werkelijke pakketten.

Figuur 3.1 toont schematisch de opbouw van het netwerk van de geobserveerde implementatie.

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Figuur 3.1: Topologie van het netwerk van de geobserveerde implementatie.

3.2 Problemen

De exacte opstelling van de meet-PC’s op de geobserveerde implementatie is niet gekend. Er zijn echter

nog problemen die de vergelijkende studie bemoeilijken:

• De klokken op de PC’s nabij de geobserveerde implementatie weken af van elkaar. Zo was er een

verschil van een halve minuut tussen de logberichten en de PC waarop LonScanner actief was en

een uur tussen de logberichten en de PC waarop Wireshark actief was.

De relatieve tijdsverschillen werden bepaald door de inhoud van de pakketten te vergelijken. Zo

kwamen pakketten voor dezelfde kamer steeds op hetzelfde relatieve tijdstip voor.

Een manier om dit probleem in de toekomst te verhelpen is het gebruik van een Network Time

Protocol (NTP) server, waardoor de klokken op de pc’s automatisch gesynchroniseerd worden;

• Alle logging berichten zijn beschikbaar via Access databanken, maar de IP-pakketten met daarin

de logberichten afkomstig van de tweede XT module zijn niet zichtbaar1.

Hier is geen oplossing voor, de berichten op het tweede LON-netwerk worden dus genegeerd,

aangezien er ook geen LON-metingen zijn voor dat netwerk;

• In sectie 2.4.1 werd reeds vermeld dat het LON-netwerk erg veel CRC-fouten bevat. Dit bemoeilijkt

de vergelijkende studie ook omdat ongeveer 21% van de berichten dubbel voorkomen. Dit kan

uiteraard geen fout van de voorspelling zijn, maar eigen aan de beschouwde implementatie. Deze

afwijkingen worden dus niet opgenomen in de studie aangezien dit externe factoren zijn die de

software niet kan benaderen;1Een logbericht is niks meer dan een XT module die een IP bericht naar de logging server stuurt om op te nemen in het logboek.

De logberichten komen dus wel degelijk toe op de logging server. De logberichten zijn beschikbaar, maar de pakketten die dezelogberichten veroorzaken op IP worden voor de tweede XT module niet teruggevonden.

23

• Sommige berichten worden niet teruggevonden op het netwerk. Dit kan zijn door CRC-fouten.

Deze onnauwkeurigheid kan ook door de software niet benaderd worden. Dit komt echter niet

vaak voor, maar wordt wel in rekening gebracht in de vergelijkende studie;

• Wegens het erg intensieve karakter van de studie en het eerder laattijdig beschikbaar zijn van de

data werd slechts een half uur aan voorspelling gevalideerd. Hierdoor is de representativiteit van

de studie laag.

3.3 Resultaten

De gedetailleerde analyse mag niet vrijgegeven worden omdat ze te veel informatie over de werking

van het systeem bevat. De belangrijkste conclusies volgen hieronder.

Tabellen 3.1 en 3.2 tonen de resultaten van de vergelijkende studie. Er wordt een verschil gemaakt

tussen het absolute en het cumulatieve verschil tussen de voorspelde en de reele situatie. Het absolute

verschil gaat ervan uit dat elke byte die verkeerd voorspeld werd verkeerd was, terwijl het cumulatieve

verschil een byte teveel en een byte te weinig als een nuloperatie beschouwt. De resultaten voor LON

en IP worden ook apart behandeld.

Een positieve waarde in de kolom “Foutief voorspeld” betekent dat de software te veel verkeer geschat

heeft. Een negatieve waarde betekent dat de software te weinig verkeer geschat heeft.

LON Foutief voorspeld Totaal (reeel) CorrectheidAantal bytes (absoluut) 1362 1786 23.74%Aantal bytes (cumulatief) 1362 1786 23.74%Aantal pakketten (absoluut) 29 42 30.95%Aantal pakketten (cumulatief) 29 42 30.95%

Tabel 3.1: Resultaten van de vergelijkende studie tussen de logberichten en LON tegenover de voorspel-ling op basis van enkel de logberichten.

IP Foutief voorspeld Totaal (reeel) CorrectheidAantal bytes (absoluut) 3499 22881 74.71%Aantal bytes (cumulatief) -2027 22881 91.14%Aantal pakketten (absoluut) 12 64 81.25%Aantal pakketten (cumulatief) -6 64 90.63%

Tabel 3.2: Resultaten van de vergelijkende studie tussen de logberichten en IP tegenover de voorspellingop basis van enkel de logberichten.

Uit de tabellen blijkt dat de voorspelling voor LON slecht tot zeer slecht is. Dit komt waarschijnlijk

door een foutieve voorspelling van de software wat betreft oproepachtervolging. Er worden namelijk

vaak pakketten te veel voorspeld (positieve waarden in de tabel). Dit kan te wijten zijn aan de grote

hoeveelheid CRC-fouten.

De foutieve voorspelling kan ook veroorzaakt zijn door de inherente gebreken aan de software: sommige

oproepen worden niet herkend en ook niet geregistreerd. Zo kan een ander soort afmelding van een

verpleegkundige niet herkend worden en lijkt het voor de software alsof die verpleegkundige nog lang

aanwezig is in die kamer.

De voorspelling voor het IP-netwerk is van betere kwaliteit. In tegenstelling tot LON is de voorspelling

op het IP-netwerk iets eenvoudiger en zijn er minder foutief voorspelde berichten. Voor bandbreedtebe-

rekeningen is het cumulatieve aantal bytes de interessantste waarde en levert tevens de beste kwaliteit,

namelijk 91.14%.

24

Deze studie moet verder gezet worden om meer betrouwbare resultaten te verkrijgen. Er moeten ook

andere implementaties beschouwd worden. Het is ook erg belangrijk dat de configuratie van de soft-

ware goed gebeurt. Indien bijvoorbeeld in de configuratie vermeld staat dat er twee instanties van de

verpleegpostsoftware actief zijn, en dit in het oorspronkelijke netwerk niet zo was, zal er veel extra

verkeer zijn op IP en zal de voorspelling uiteraard nog minder correct zijn.

3.4 Conclusie

Deze validatie had als doel om de betrouwbaarheid van de StateMachine software te onderzoeken. De

correctheid van de software haalt voor het LON-netwerk momenteel slechts 20 a 30%. Voor IP ligt dit

hoger: 75 a 90%.

Indien de software nog bijgeschaafd wordt en het geobserveerde netwerk minder fouten bevat zal het

mogelijk zijn om via de conversiesoftware op betrouwbare wijze over te gaan van logberichten naar

pakketten. Deze pakketten kunnen vervolgens aan het statistisch model uit hoofdstuk 2 doorgegeven

worden om een voorspelde belasting van het netwerk te bepalen.

De totale correctheid van het conversieproces StateMachine + Modellen kan dan opnieuw gevalideerd

worden op basis van de reele belasting op het netwerk en de voorspelde belasting op het netwerk. Dit

is een werk voor de toekomst.

Figuur 3.2 toont het volledige conversieproces.

��

��

��

��

��

Figuur 3.2: Overzicht van het totale conversieproces ter bepaling van de voorspelde belasting op hetnetwerk.

25

Hoofdstuk 4

Topologie

In de vorige hoofdstukken werd enkel maar gesproken over het huidige verpleegoproepsysteem. Vanaf

dit hoofdstuk wordt het toekomstige verpleegoproepsysteem besproken.

Bij de introductie van IP-technologie tussen de XT module en de kamernodes komen twee fundamen-

teel tegenstrijdige eisen tegenover elkaar te staan: bekabeling in bustopologie en apparatuur die in

stertopologie werkt.

Op het huidige verpleegoproepsysteem worden alle kamernodes van een XT module via een bus ver-

bonden. Er zijn 4 LON-interfaces op een XT module (zoals ook op Figuur 1.1 reeds te zien was) en alle

data worden op alle interfaces verstuurd. De bekabeling gebeurt dus ook in bus, wat de hoeveelheid en

de lengte van de interconnectie reduceert.

Anderzijds is alle moderne Ethernet1-apparatuur gebaseerd op stertopologie. De verouderde coax-

technologie was een fysieke busstructuur, maar werd vervangen door Unshielded Twisted Pair (UTP),

zodat de throughput verhoogd kon worden, door niet meer op een shared medium te werken. Hier is de

maturiteit van de technologie een groot voordeel.

In dit hoofdstuk worden een aantal topologieen voorgesteld en vergeleken. Om de vergelijking op te zet-

ten, bespreek ik eerst de nieuwe elementen in het toekomstige verpleegoproepsysteem. De voorgestelde

topologieen zijn allemaal bruikbaar in het toekomstige verpleegoproepsysteem.

4.1 Entiteiten

De huidige structuur waarin kamernodes met een XT module verbonden worden, en die XT modules

onderling verbonden worden, blijft behouden. Nu heeft de XT module geen LON interfaces meer, maar

slechts 1 core IP- en 1 edge IP-interface. De core interface wordt verbonden met een backbone IP-netwerk

waar alle XT modules op verbonden zijn (vergelijk met de huidige IP-interface). De edge interface wordt

verbonden met de kamernodes via een welbepaalde topologie.

Aangezien aan elke kamernode nu ook een IP-adres toegekend wordt, volstaat 1 subnet niet meer om

alle kamernodes en XT modules een IP-adres te geven. Er wordt voor gekozen om alle kamernodes op

een XT module binnen hetzelfde subnet te houden. De XT modules moeten dus het verkeer tussen edge-

en core-netwerk kunnen routen.

Figuur 4.1 geeft een schematisch overzicht van de zonet besproken aanpak.

Uiteraard kunnen extra clients en servers aan het backbone IP-netwerk aangesloten worden om extra

functies te voorzien, bijvoorbeeld: verpleegpostsoftware, logging server, multimedia server en update1We beschouwen hier enkel Ethernet datalinktechnologie omdat dit de meest gebruikte standaard is voor LANs (Local Area

Network), omdat de apparatuur hierdoor goedkoper is en omdat IP en Ethernet vaak samen geımplementeerd worden [17, 28].

26

��

��

��

��

��

��

��

��

��

��

��

��

��

Figuur 4.1: Schematische voorstelling van het nieuw netwerk.

server. Dit komt later nog uitvoerig aan bod bij de bespreking van de verschillende nieuwe diensten in

hoofdstuk 5.

4.2 Bustopologie

Wanneer kamernodes in bus met de XT module verbonden worden, kunnen heel wat bekabelingskos-

ten uitgespaard worden. Echter, de Ethernetapparatuur werkt in fysieke stertopologie. Deze sectie

bespreekt een aantal manieren om de inherente stertopologie toch aan te wenden in een fysieke bus-

structuur.

In een eerste mogelijke implementatie heeft elke kamernode 2 Network Interface Cards (NICs). Dit komt

neer op het emuleren van een switch2 binnen de kamernode zelf, zie Figuur 4.2.

Een binnenkomend pakket wordt ofwel doorgestuurd naar de applicatie, ofwel doorgestuurd naar de

andere interface, afhankelijk van de bestemming van het pakket.

��

��

�

�

��

�

� ��

�

��

��

Figuur 4.2: Bustopologie met twee NIC’s per kamernode.

Een tweede mogelijke implementatie maakt gebruik van reeds bestaande elementen: elke kamernode

wordt voorzien van een externe switch en heeft nu nog slechts 1 NIC die rechtstreeks met de externe

switch verbonden is. De functionaliteit is dezelfde als bij twee NIC’s, maar nu hoeft de kamernode zelf

geen switchfunctionaliteit te voorzien, zie Figuur 4.3.2Hubs creeren een groot collision domain en zijn niet aangewezen.

27

��

��

��

Figuur 4.3: Bustopologie met externe switches.

De implementatie met extra switches zorgt voor een verhoogde kost aan apparatuur, maar de kamernode

hoeft dan zelf geen switch-element te bevatten.

4.3 Stertopologie

Hier kunnen we onderscheid maken tussen twee varianten:

• Direct: stertopologie waar elke kamernode een rechtstreekse kabel heeft naar de XT module (zie

Figuur 4.4);

• Verdeeld: stertopologie met tussenliggende switches3 (zie Figuur 4.5).

��

��

��

��

��

Figuur 4.4: Stertopologie: elke kamernode is rechtstreeks verbonden met een XT module.

Indien een stertopologie met rechtstreekse kabels gebruikt wordt, is er per kamernode slechts 1 kabel

nodig, maar zijn de kabels variabel van lengte. Dit is niet handig in gebruik omdat kabels op deze

manier moeilijker opnieuw gebruikt kunnen worden. Ook is het niet mogelijk om een XT module van

honderden NIC’s te voorzien. Hier moet dus een performante switch bijgeplaatst worden.

Indien gebruik gemaakt wordt van tussenliggende switches, zijn er meer kabels nodig. Hoe meer tus-

senliggende switches er gebruikt worden, hoe dichter deze topologie aanleunt bij de bustopologie met

externe switches.

4.4 Ringtopologie

Een hybride oplossing voor de topologie bestaat erin om de voordelen van de bustopologie, namelijk

minder bekabeling, te combineren met de verhoogde bandbreedte en betrouwbaarheid van de sterto-3Hubs zijn niet aangewezen, aangezien er dan meer botsingen zijn omdat alle kamernodes zich dan in hetzelfde collision

domain bevinden [17].

28

��

��

��

��

��

Figuur 4.5: Stertopologie met tussenliggende switches.

pologie. Een extra redundante kabel verbindt de XT module met de laatste kamernode op de bus.

De bekomen ringtopologie wordt echter niet ondersteund door Ethernet. Ethernet is namelijk een ster-

gebaseerde netwerktechnologie. Indien een cykel4 voorkomt in het netwerk, dan worden pakketten

nodeloos gedupliceerd en komt het netwerk in een onstabiele toestand terecht [17].

Het Spanning Tree Protocol (STP - IEEE 802.1D [25]) biedt hiervoor een oplossing. Het netwerk bepaalt

autonoom een opspannende boom door een aantal interfaces uit te schakelen. Figuur 4.6 toont hoe deze

techniek kan toegepast worden op de hier beschouwde ringtopologie. Hoe de kamernodes verbonden

zijn in het netwerk, via externe switches of met 2 NIC’s zoals bij de bustoplogie, maakt hierbij niet uit.

In het geval van externe switches worden een aantal poorten op de switches uitgeschakeld, terwijl bij

kamernodes met 2 NIC’s een aantal NIC’s uitgeschakeld worden.

Het netwerk werkt, na de verkiezing van de af te sluiten netwerklink, alsof het een boomstructuur was

zonder de extra, redundante link. Deze link bewijst zijn nut als ergens anders in de twee overblijvende

bussen een link faalt. In dat geval probeert STP de eerder verkozen link terug beschikbaar te maken. Zo

is het netwerk dat in essentie met twee bustopologieen werkt, bestand tegen het uitvallen van 1 link.

Dit kan zowel een kabelbreuk zijn als het niet-functioneren van een switch. Deze niet-functionerende

switch kan zowel een externe switch zijn als een kamernode zelf, afhankelijk van de keuze om externe

switches te gebruiken of kamernodes met 2 NIC’s te gebruiken.

De convergentie van selectie van de uit te schakelen link is vrij traag met RTP: orde van 30 s. Het RapidSpanning Tree Protocol (RSTP) is een verbetering op STP die de tijd bij herverkiezing aanzienlijk verlaagt

tot minder dan een seconde [37].

��

��

��

��

��

��

Figuur 4.6: Ringtoplogie met Spanning Tree Protocol (STP).

4Uit de grafentheorie: een cykel is een niet-triviaal pad van een knoop naar zichzelf. Dus het pad met nul takken is niet geldigaangezien het triviaal is [35].

29

Het loont de moeite om in de toekomst te onderzoeken wat de invloed is van het gebruik van RTSP

op de nog beschikbare bandbreedte op het medium.

Zoals Figuur 4.6 reeds toont, zijn er veel manieren om de ring te splitsen. Deze splitsing heeft echter

wel een belangrijke invloed op de bandbreedte van de overblijvende bussen. Indien de ring bijvoorbeeld

onderbroken wordt door het uitschakelen van een van de interfaces op de XT module (niet getoond op

de figuur), dan is het resultaat de klassieke bustopologie met een redundante link.

De ring kan optimaal gesplitst worden door precies in het midden van de oorspronkelijke bus te splitsen,

met op elke resulterende bus evenveel kamernodes naar de XT module toe (zoals getoond op de figuur).

Bij een oneven aantal kamernodes wordt net naast het midden gesplitst, aangezien het midden precies

op een kamernode valt.

Bij een optimale splitsing wordt het netwerk bij benadering in twee bussen verdeeld, elk met evenveel

bandbreedte als de oorspronkelijke bus. Zo kan de bandbreedte van de oorspronkelijke bustopologie

verdubbeld worden. De optimale splitsing in een ringnetwerk behoort echter niet tot een standaard en

valt dus buiten het kader van deze masterproef.

Tabel 4.1 vat de voor- en nadelen van de verschillende topologieen samen. Hierna worden ze ook

besproken:

Bustopologie Stertopologie RingtopologieCriterium 1 NIC 2 NIC’s Direct Verdeeld 1 NIC 2 NIC’s

Weinig kabels X XX X XXHoge bandbreedte XX X X XBetrouwbaarheid XX X X X

Lage complexiteit node X X X XGeen externe switches X X X

Tabel 4.1: Vergelijking van bus-, ster- en ringtopologie: theoretisch (X= positief).

• Bekabeling: de stertopologie vraagt de hoogste hoeveelheid kabels. Dit komt omdat elke kamer-

node een directe verbinding heeft met de XT module. Bij bus- en ringtopologie zijn er aanzienlijk

minder kabels nodig. Indien een externe switch gebruikt wordt bij bus- of ringtopologie en er 1

NIC gebruikt wordt, moet er per kamernode een extra kabel naar de externe switches voorzien

worden;

• Bandbreedte: directe stertopologie voorziet de meeste bandbreedte naar de kamernodes omdat

elke kamernode een eigen link heeft aan bijvoorbeeld 100 Mbps. De verdeelde stertopologie

moet deze bandbreedte delen over een aantal kamernodes. De ringtopologie verdeelt de totale

beschikbare bandbreedte over ongeveer de helft van de kamernodes en de bustopologie verdeelt

de totale bandbreedte over alle kamernodes;

• Betrouwbaarheid: hangt volledig samen met bandbreedte. Hoe meer bandbreedte, hoe betrouw-

baarder het netwerk kan werken. Maar ook hoe meer kabels, hoe betrouwbaarder het netwerk.

Zo is het mogelijk dat een kabelbreuk slechts een heel beperkt aantal kamernodes beınvloedt;

• Complexiteit kamernodes: overal waar met 1 NIC en dus met een externe switch gewerkt wordt, is

de complexiteit van de kamernodes lager doordat intern geen (snelle) switchfunctionaliteit moet

geımplementeerd worden;

• Externe switches brengen een meerkost met zich mee, en het ontbreken van externe switches heeft

dus een positief effect op de kostprijs.

30

4.5 Ad-hoc topologie

Deze topologie wordt hier enkel vermeld ter volledigheid en omdat dit een aantal voordelen biedt qua

beheer.

In een ad-hoc topologie wordt een willekeurige bekabeling tussen kamernodes, XT modules en extra

clients en servers toegelaten. Hierdoor kunnen bijvoorbeeld alle servers en XT modules in een veilige

omgeving geplaatst worden, bijvoorbeeld in de kelder van een gebouw, en moeten enkel de kamernodes

en clients op de afdelingen aanwezig zijn. Qua beheer is dit veel eenvoudiger dan de gedistribueerde

topologieen uit vorige paragrafen. Figuur 4.7 toont een voorbeeld van een ad-hoc topologie voor het

toekomstige verpleegoproepsysteem.

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Figuur 4.7: Ad-hoc topologie toegepast op het toekomstige verpleegoproepsysteem.

Een groot nadeel zijn de aanpassingen die in de software moeten gebeuren. Alle kamernodes moeten

een dynamisch IP-adres toegewezen krijgen. De installatie van nieuwe nodes kan niet meer automatisch

gebeuren omdat een node niet weet tot welke XT module hij moet behoren en dus niet weet waar te

registreren.

Ook de theoretische evaluatie van het netwerk wat betreft bandbreedtegebruik is veel moeilijker. Het is

namelijk mogelijk dat het netwerk mooi uitgebalanceerd is en er geen bottlenecks in voorkomen. Maar

het is eveneens mogelijk dat alle diensten gebruik moeten maken van een bepaalde netwerklink, die

misschien zwaar overbelast wordt tijdens piekmomenten.

Deze oplossing biedt de grootste flexibiliteit wat betreft plaatsing van de apparatuur, maar zal verder

niet beschouwd worden wegens de verhoogde complexiteit van de gebruikte entiteiten en de onzeker-

heid of Quality of Service wel gegarandeerd kan worden, zie hoofdstuk 6. Er is ook een Duitse norm die

eist dat het communicatiepad voor de verpleegoproepen specifiek moet zijn, wat niet mogelijk is met

een willekeurig netwerk [23].

In de toekomst kan deze topologie nog verder uitgedacht worden, al moeten de voor- en nadelen goed

afgewogen worden.

4.6 Voeding

In het huidige verpleegoproepsysteem wordt de voeding op het LON-netwerk voorzien door een extra

stroomkabel die ook afgetakt wordt naar elke kamernode [23]. De bekabeling moet echter tot een

31

minimum beperkt worden, zodat alternatieve manieren moeten bestudeerd worden om de kamernodes

te voeden.

Power over Ethernet (PoE) is een technologie die in 2003 gestandaardiseerd werd door IEEE [24]. Twee

paren van de reeds gebruikte UTP-kabel worden gebruikt om voeding naar het Powered Device (PD) te

brengen [12].

Aangezien een Power Sourcing Equipment (PSE) maximaal 15.4 W kan leveren [24]5, is het niet realis-

tisch om PoE te beschouwen in de eerder besproken bustopologie zonder externe switches6. Dit kan

opgelost worden door de kamernode bijvoorbeeld te voeden met netstroom in de kamer.

Wat de stertoplogie betreft is dit een zeer interessante manier om energie te verdelen. In het geval dat

elke kamernode rechtstreeks verbonden is met de XT module, kan de PSE in de XT module ingebouwd

zijn (Endpoint PSE). Een andere mogelijkheid is om op elke kabel van de XT module naar een kamernode

een Midspan PSE te plaatsen, die de kabel van gelijkspanning voorziet, zonder de data te wijzigen [24].

Indien tussenliggende switches gebruikt worden, kunnen deze eventueel optreden als Endpoint PSE, als

laatste hop voor de kamernode.

Bij de ringtopologie zijn dezelfde problemen als bij de bustopologie van toepassing.

De keuze van voedingstype zal afhangen van de beschouwde locatie, de gebruikte netwerktopologie en

het beschikbare budget.

4.7 Conclusie

In dit hoofdstuk werden vier verschillende topologieen besproken: bus, ring, ster en ad-hoc. In Tabel 4.1

worden de voor- en nadelen van elke topologie vergeleken (behalve ad-hoc). De exacte keuze van

topologie hangt echter af van de concrete locatie waar het systeem moet geplaatst worden, alsook de

grootte van het systeem (bandbreedte, kostprijs).

Daarna werd kort besproken hoe Power over Ethernet (PoE) kan gebruikt worden. Ook daar hangt het

af van situatie tot situatie welke voedingsarchitectuur het best geschikt is.

Indien het budget groot genoeg is en de infrastructuur veel bekabeling toelaat is de verdeelde stertopo-

logie met een klein aantal tussenliggende switches de meest interessante topologie. Indien het budget

een limiterende factor is, geniet de ringtopologie de voorkeur wegens de verbetering ten opzichte van

de besproken bustopologieen en de lagere kost dan bij de besproken stertopologieen.

5IEEE 802.3at (PoE+) probeert om een hoger vermogen te bieden, maar is nog niet gestandaardiseerd [2].6Indien met externe switches gewerkt wordt, moeten er hoe dan ook meer kabels getrokken worden.

32

Hoofdstuk 5

Diensten

Dit hoofdstuk bespreekt de noodzakelijke en optionele diensten van het toekomstige verpleegoproep-

systeem. Elke dienst heeft zeer specifieke eisen voor het netwerk en er moet voor elke dienst een

protocol (-suite) gekozen worden. Hieronder worden de diensten besproken. Voor elke dienst wordt

een overweging gemaakt wat betreft protocols.

Quality of Service komt aan bod in het volgende hoofdstuk.

Het vorige hoofdstuk duidde reeds op de algemene netwerktopologie, waar gebruik gemaakt wordt van

IP en Ethernet bovenop een UTP-kabel. In dit hoofdstuk moeten dus enkel nog de applicatielaag en de

transportlaag gedefinieerd worden en moeten de netwerken datalinklaag enkel nog verfijnd worden.

5.1 Data: verpleegoproepen en controleberichten

5.1.1 Applicatielaag

Het protocol dat gebruikt zal worden in het toekomstige verpleegoproepsysteem op de applicatielaag

moet sterk gelijken op het protocol dat in het huidige systeem gebruikt wordt. Zo blijven de XT modules

verantwoordelijk voor hun kamernodes en kunnen kamernodes (wat betreft verpleegoproepen) enkel

maar communiceren met de XT module1. De XT module bevat genoeg logica om de berichten zelfstandig

af te handelen en eventueel door te sturen naar andere XT modules of andere computers (client/server).

De kamernodes worden nog steeds aangestuurd door de XT module, en indien de core IP-link uit zou

vallen, werkt het systeem nog steeds binnen de afdelingen die op deze XT module gedefinieerd zijn.

5.1.2 Transportlaag

Deze dienst moet absoluut garanderen dat de verzonden berichten toekomen, en dat ze toekomen met

een zo kort mogelijke vertraging. Pakketverlies is niet toegelaten, vertraging moet tot een minimum

beperkt worden en de pakketten moeten in de juiste volgorde (in-order) toekomen.

Hiervoor wordt best het Transmission Control Protocol (TCP) gebruikt. Bij TCP wordt tussen beide

communicerende partijen een connectie opgezet (3-way handshake) waarin een aantal parameters af-

gesproken worden om het netwerk niet te overbelasten (congestion control), pakketten in de juiste

volgorde af te leveren (sequence numbers) en niet sneller te sturen dan de ontvanger kan ontvangen

(flow control) [17].

Voor elk bericht wordt een nieuwe connectie opgezet. Dit kan een belangrijke vertraging veroorzaken

indien het netwerk zwaar belast is.1Enige uitzondering hierop kan de zorgserver zijn, waar de kamernode interactief data van opvraagt.

33

Hiervoor zijn drie oplossingen mogelijk: ofwel biedt de onderliggende laag (Internet Protocol, IP) Qua-

lity of Service en krijgen deze pakketten steeds voorrang (zie volgend hoofdstuk), ofwel wordt een

eenvoudiger protocol gebruikt zoals het User Datagram Protocol (UDP). Hierbij moet dan wel op de ap-

plicatielaag extra moeite gedaan worden om de nodige garanties zoals hierboven besproken te kunnen

waarborgen. Een derde mogelijkheid bestaat erin om de TCP connectie steeds open te laten. Indien het

gaat om een klein aantal connecties is dit geen probleem. Maar vanaf een bepaald aantal connecties

kan de kamernode problemen ondervinden om de status van al deze verbindingen bij te houden. In het

verpleegoproepsysteem zullen echter nooit meer dan ongeveer 300 connecties tegelijk openstaan per

XT module en niet meer dan 10 per kamernode2.

Verpleegoproepberichten worden verstuurd tussen een kamernode en zijn beherende XT module, tus-

sen XT modules onderling of tussen een XT module en een andere entiteit (verpleegpostsoftware, zorg-

server, logging server, . . . ).

Een aantal protocols die hieronder besproken worden, maken gebruik van controleberichten die ver-

eist zijn voor de goede werking van het protocol. Ook deze berichten worden met deze dienst (“ver-

pleegoproepberichten en controleberichten”) verstuurd. Voorbeelden van dit soort controleberichten

zijn: Internet Group Management Protocol (IGMP) membership berichten, FTP controleberichten, . . .

Wanneer een dienst een specifiek controlebericht gebruikt, zal dit steeds verstuurd worden met de dienst

voor controleberichten.

5.2 Voice: intercomgesprekken

Nu de basiswerking van het systeem reeds voorzien is, kan het intercomsysteem opgezet worden. Net

zoals in het huidige systeem en de courante Voice over IP (VoIP) systemen, kunnen we een onderscheid

maken tussen control plane en user plane.

De control plane voorziet in call setup en call teardown: het opzetten en afbreken van gesprekken. Deze

berichten worden best verzonden met de Data-dienst zoals hierboven beschreven (deze berichten vallen

dus ook onder controleberichten).

De user plane bevat de eigenlijke gesprekken, en moet dus een aantal bidirectionele (full-duplex) audio-

kanalen ondersteunen.

Aangezien beide planes een verschillende aanpak vereisen, worden ze hierna apart behandeld.

5.2.1 Control Plane: SDP en SIP over TCP

Voor de control plane worden het Session Description Protocol (SDP) en het Session Initiation Protocol

(SIP) gebruikt.

SDP definieert een sessie. Een sessie kan opgevat worden als een gesprek in deze context. SDP is

echter slechts een formaat om een sessie te beschrijven, en kan door meerdere onderliggende protocols

getransporteerd worden. In deze context zal gebruik gemaakt worden van SIP om het gesprek op te

zetten [8].

SIP is een protocol op de applicatielaag dat toelaat om multimediasessies op te zetten, af te breken en

te wijzigen. Het wordt best in combinatie met een authenticatiemechanisme gebruikt om beveiliging te

garanderen.

2De 300 connecties bevatten een 250-tal connecties naar de kamernodes en de connecties naar andere XT modules, externeclients en servers. De 10 connecties per kamernode bevat de connectie naar de XT module en eventueel nog externe clients ofservers.

34

In een later stadium kan SIP samenwerken met het bestaande PSTN netwerk (indien gewenst), om

ook uitgaande oproepen te ondersteunen [8].

SIP wordt zowel gebruikt tussen gesprekspartners (hierna user agents genoemd) als tussen user agent

en SIP server. De SIP server is (binnen zijn domein) verantwoordelijk voor het bijhouden van de locatie

van gebruikers (in deze context is geen mobility voorzien voor de kamers) en voor het opzetten van

gesprekken tussen de user agents.Er werd gekozen voor TCP om SDP en SIP te transporteren omdat zowel SDP als SIP geen tijdskritische

informatie dragen maar wel correct moet overgebracht worden.

5.2.2 User Plane: RTP en RTCP over UDP

Op de user plane wordt het audiosignaal getransporteerd in full-duplex. Hiervoor zijn een aantal stap-

pen vereist: compressie van het geluidssignaal (verlagen van de bandbreedte), toevoegen redundantie

(Forward Error Correction (FEC)), interleaving, omvormen tot pakketten, toevoegen van een sequentie-

nummer, . . .

Hierna kan het signaal over UDP verstuurd worden. UDP wordt hier gebruikt omdat een laattijdig

bericht geen waarde meer heeft, dus als een bericht verloren gaat, hoeven we geen retransmissie te

hebben, aangezien het dan geen nuttige informatie meer bevat (te laat).

Er wordt een extra header toegevoegd tussen UDP en de gespreksdata, een Real-time Transport Protocol

(RTP) header. Er worden (minstens) 128 bits per pakket toegevoegd met onder andere: sequentienum-

mer, tijdsinformatie en connectie-identificatie.

Eventueel kan een extra protocol ingezet worden, het RTP Control Protocol (RTCP), dat een extra

communicatiekanaal voorziet tussen beide communicerende partijen. Zo kan bijvoorbeeld feedback

voorzien worden over de kwaliteit van het signaal.

Het gebruik van een de-jitter buffer (om aan de ontvangstzijde dezelfde snelheid van afspelen te garan-

deren), echo cancelation (om het comfort van het gesprek te verhogen) en packet concealment (om verlies

van pakketten te compenseren) wordt ook voorzien om de kwaliteit zo hoog mogelijk te houden [8].

5.2.3 Entiteiten

In deze VoIP-implementatie is er voor elke kamernode in een kamer een user agent (UA) aanwezig. Er

is een SIP-server aanwezig in het core IP-netwerk die de gesprekken tussen kamernodes kan beheren.

5.3 Multimedia broadcasting

Een derde dienst is multimedia broadcasting. Zowel audio (bv. radio) als video (bv. televisie) kunnen

naar de kamers (i.e. kamernodes) gedistribueerd worden. In deze sectie zullen zowel video als audio

op dezelfde manier behandeld worden, het enige belangrijke verschil ertussen is de bitrate. Er wordt

verondersteld dat twintig videostromen en tien audiokanalen gedistribueerd worden.

Er zijn een aantal mogelijkheden om de video- en audiodistributie te voorzien. Vaak wordt gebruik

gemaakt van RTP over UDP. In de RTP-pakketten zit dan een MPEG-2 Transport Stream (TS). In die TS

zitten twee elementaire stromen vervat, een voor audio en een voor video (MPEG-2 Primary ElementStream (PES)). Voor de audiodistributie kan dan bijvoorbeeld enkel de audio in een TS geplaatst worden

en verzonden worden over RTP/UDP.

Er wordt gebruik gemaakt van de MPEG-4 Part 10 - H.264/AVC codec voor de videocodering. Deze

codec wordt gekozen omdat het een nieuwe opkomende standaard is en een veel hogere kwaliteit aan

35

lagere bandbreedte toelaat dan zijn voorgangers. Als Level 2.2 van deze codec gebruikt wordt, dan is

de bitrate niet hoger dan 4 Mbit/s (Main Profile). Dit kan aan een resolutie van 720x576 aan 25 frames

per seconde [36].

Om deze videostroom te versturen over het netwerk hebben we 4 elementen nodig:

• Videobronnen: dit kunnen live uitzendingen zijn van de kabel of geprogrammeerde films;

• Videodistributieserver: deze server wordt aangesloten op het core IP-netwerk en ondersteunt het

Real-time Transport Protocol (RTP);

• Videospelers: software op de kamernodes om videostromen af te spelen (uiteraard enkel op ka-

mernodes met een scherm);

• IP multicast: zodat we een videostroom slechts 1 keer over het netwerk moeten sturen, ook al

vragen veel kamernodes deze videostroom op.

IP multicast zorgt ervoor dat het netwerk niet meer belast wordt (door videostromen) dan de bitrate van

een videostroom maal het aantal videostromen dat door het ziekenhuis of rusthuis aangeboden wordt.

Zo is er in deze beschouwing een maximale bitrate van 40 Mbit/s voorzien voor video. De gemiddelde

bitrate van een videostroom bedraagt dus 2 Mbit/s.

Een typische audiostroom kan via MPEG-1 Layer 3 (MP3) aan 128 kbit/s gecodeerd worden. Alle

audiokanalen samen zouden dus niet meer dan 1.28 Mbit/s in beslag nemen.

Ook hier zijn audiobronnen, een audiodistributieserver, audiospelers en IP multicast vereist.

Algemene oproep

Een belangrijke toepassing van audio broadcasting is de algemene oproep. Een algemene oproep is een

manier om een ingesproken boodschap naar alle kamers te verspreiden, of naar specifieke kamers.

5.4 Firmware updates

Het huidige verpleegoproepsysteem is moeilijk te onderhouden wat firmware3 betreft. Een nieuwe

update installeren op alle kamernodes in een systeem is een erg tijdrovend werk, omdat op het LON-

netwerk niet genoeg bandbreedte aanwezig is om een firmware update (op afstand) uit te voeren.

Op het IP-netwerk hebben we een veel grotere bandbreedte ter beschikking. Het is dus wenselijk om een

manier te voorzien om firmware updates te installeren over het netwerk. Dit kan door controleberichten

te sturen naar de kamernode die geupdatet moet worden, en de kamernode vervolgens zelf het bestand

te laten downloaden van een lokale File Transfer Protocol (FTP)-server. De kamernode kan dan de update

uitvoeren. Het kan ook anders: de node kan ook periodiek een vraag sturen naar de update server om

te weten te komen of er een nieuwe update beschikbaar is.

Belangrijk is dat de functionaliteit van de kamernode tijdens de update niet verloren mag gaan. De

kamernode moet dus in staat zijn om de update te installeren zonder dat de verpleegoproepberichten

genegeerd worden. Dit kan door de software modulair op te bouwen en bijvoorbeeld alle modules in

tweevoud te hebben: een production module en een backup module. De backup modules kunnen tijdens

de eerste fase van een updateproces vervangen worden. In een tweede fase wordt het backupsysteem

ingeschakeld, waardoor de kamernode direct (met alle modules tegelijk) de nieuwe code gebruikt.

Vervolgens kunnen de production modules overschreven worden met de nieuwe update en tenslotte

3Firmware is een term die verscheidene (vaak) kleine programma’s bundelt die in een ingebed systeem gebruikt worden.

36

kan weer overgeschakeld worden naar de production modules. Deze aanpak vergt wel dubbel zoveel

geheugen en een efficient omschakelmechanisme voor de modules.

De grootte van een update heeft een belangrijke invloed op de belasting van het netwerk. Aangezien

FTP werkt bovenop TCP, kunnen we ervan uitgaan dat er congestion control toegepast wordt, en zal de

download vertraagd worden indien het netwerk overbelast geraakt (zie ook volgend hoofdstuk, Quality

of Service).

Het is ook belangrijk dat de updates achterwaarts compatibel zijn zodat de updates van de kamernodes

niet tegelijk hoeft te gebeuren en de XT module steeds met de kamernodes kan blijven communiceren,

al is het misschien met een beperkte set van commando’s.

5.5 Internet

Of het nu een kamernode is of de computer op de verpleegpost, in sommige situaties kan het handig of

bevorderend zijn om internettoegang in de buurt te hebben. Ook standaard internet moet beschikbaar

zijn op het nieuwe verpleegoproepsysteem.

Het ziekenhuis kan beslissen om aan iedereen internet aan te bieden, of om er een betaalde dienst

van te maken. Indien het een gratis dienst is, is de netwerkarchitectuur vrij eenvoudig. Indien er

echter een authenticatiemechanisme moet voorzien worden, kan van een gebruikersnaam/wachtwoord-

combinatie gebrui gemaakt worden of zelfs van biometrische hulpmiddelen. Er moet dan enkel een

manier gevonden worden waardoor de client op de verpleegpost deze inlogprocedure niet nodig heeft4.

De basisentiteiten op het netwerk zijn:

• Internet gateway: router naar het publieke netwerk, eventueel voorzien van een Web portal [18]

voor authenticatie. Aan elke kamernode wordt (na inloggen op de web portal) een periode toege-

kend waarop de kamernode toegang heeft tot het internet. Na deze periode wordt de kamernode

opnieuw afgeschermd van het internet;

• Firewall (met Network Address Translation (NAT)5): om slechts een aantal kamernodes te laten

communiceren met de buitenwereld (en de web portal goed te laten functioneren). Het is gevaar-

lijk om een kamernode direct op het internet te plaatsen, dus moeten de firewall-regels zo strikt

mogelijk geımplementeerd worden;

• Web browser: de kamernode moet met een moderne web browser uitgerust zijn (waarvoor ook

updates moeten voorzien worden);

• Optioneel: intranet webserver met informatie voor de patient over het ziekenhuis, bijvoorbeeld:

dagmenu, speciale activiteiten, brandoefening.

Merk op dat vreemde computers niet toegelaten worden op het netwerk, maar bijvoorbeeld computers

op de verpleegpost wel, dus is een Dynamic Host Configuration Protocol (DHCP) server aangewezen.

5.6 Beveiliging

Beveiliging op het netwerk bestaat uit twee luiken:

• Enerzijds moet de gegevensoverdracht voor kritieke applicaties betrouwbaar en geheim gebeuren.

Hier is er nood aan authenticatie en indien gewenst encryptie;

4Dit kan bijvoorbeeld aan de hand van publieke/private sleutels zoals bij SSH logins gebruikt wordt.5Merk op dat dit NAT niet vereist is indien met IPv6 gewerkt wordt.

37

• Scheiding van netwerken. Indien reeds een IP-netwerk aanwezig is in het ziekenhuis zal dit hoogst

waarschijnlijk hergebruikt worden. Om ervoor te zorgen dat het toekomstige verpleegoproepsys-

teem geen problemen ondervindt van het slecht functioneren van het huidige netwerk, kan ervoor

gekozen worden om een aparte VLAN te voorzien voor alle berichten van het verpleegoproepsys-

teem, inclusief andere diensten (video, voice, . . . ) [25, 26, 27].

Dankzij authenticatie wordt elk bericht voorzien van een digitale handtekening van de verzender. Elke

ontvanger kan dan controleren of het bericht oorspronkelijk wel van de verzender kwam en of de

inhoud ervan niet gewijzigd werd. Authenticatie is nodig voor alle verpleegoproepberichten. Dit kan

in de applicatie zelf ingebouwd worden door gebruik te maken van hashfuncties in combinatie met

publieke of geheime sleutels.

Encryptie zorgt ervoor dat de inhoud van elk bericht onleesbaar gemaakt wordt voor onbevoegden.

Encryptie kan bovenop de zonet aangehaalde authenticatie geplaatst worden door de data zelf ook te

versleutelen. Ook dit kan weer met publieke of geheime sleutels.

Combinatie van verschillende technieken kan een nog veiligere oplossing bieden maar valt buiten het

bestek van deze masterproef.

Het gebruik van VLAN’s biedt niet noodzakelijk een goede oplossing. Alle switches en routers op het

netwerk moeten namelijk rekening houden met de VLAN’s en ook met de prioriteiten van de pakketten

van het verpleegoproepsysteem. Indien dit niet gebeurt kan het reeds bestaande netwerk het nieuwe

verpleegoproepsysteem totaal overstemmen. Hierdoor kan de functionaliteit van het verpleegoproep-

systeem niet gegarandeerd worden.

5.7 Netwerklaag

Bovenstaande besprekingen waren voornamelijk gefocust op de applicatie- en de transportlaag. De

onderliggende netwerklaag wordt verzorgd door het Internet Protocol (IP). Dit protocol zorgt voor de

correcte routering van pakketten. Er wordt in deze masterproef gebruik gemaakt van IPv4 (IP version

4). De lezer is uiteraard vrij om zelf de extrapolatie naar IPv6 te maken, maar aangezien deze standaard

nog niet echt ingeburgerd is in edge-netwerken, leek het me beter om hier niet dieper op in te gaan.

Voor de toekomst is het wel interessant om IPv6 compatibiliteit in het achterhoofd te houden.

In de volgende hoofdstukken zal gebruik gemaakt worden van de zogenaamde CIDR-notatie (ClasslessInter-Domain Routing). Elk IP-adres in IPv4 maakt gebruik van 4 bytes om het adres te definieren. Bij

elk adres hoort ook een subnet masker zodat duidelijk is op welk subnetwerk het adres zich bevindt.

Doorgaans wordt dit gespecificeerd met nogmaals 4 bytes met bijvoorbeeld 255.255.255.0 als vaak

voorkomend geval om het subnet aan te geven waarbij de eerste 3 bytes van het IP-adres gelijk zijn.

Een andere en beknoptere notatie is de CIDR-notatie. In plaats van gebruik te maken van 4 bytes om

aan te geven welke bits tot het subnet behoren en welke bits tot het adres, wordt gewoon het aantal

subnetbits na een “/” geschreven. Figuur 5.1 geeft hiervan een voorbeeld.

IP-adres: 157 . 193 . 244 . 47Subnet masker: 255 . 255 . 255 . 0Subnet masker (bits): 11111111.11111111.11111111.00000000CIDR-notatie: 157 . 193 . 244 . 47 / 24

Figuur 5.1: Voorbeeld van CIDR-notatie.

38

5.8 Conclusie

In dit hoofdstuk werden de verschillende diensten besproken die op het toekomstige verpleegoproep-

systeem gebruikt kunnen worden. De verpleegoproepberichten maken gebruik van een eigen protocol

bovenop TCP, de intercomgesprekken worden met SIP en SDP over TCP en RTP en RTCP over UDP

verstuurd. De multimediadistributie gebeurt met IP multicast naar de kamernodes. De distributie van

video gebeurt in RTP pakketten over UDP, gecodeerd met de H.264/AVC codec. De audiodistributie

wordt ook in RTP pakketten over UDP verstuurd, gecodeerd in MP3. Firmware updates worden door

het FTP protocol verzorgd. Internettoegang werd ook besproken en bevat meerdere elementen die

moeten samenwerken zoals een internet gateway en een firewall.

Er werden ook beveiligingsaspecten besproken. Zo worden de verpleegoproepberichten en firmware

updates best beveiligd door middel van authenticatie en encryptie. Het hoofdstuk werd afgesloten met

een korte noot over de netwerklaag.

Nu de nieuwe diensten besproken zijn wordt het tijd om het netwerk extra garanties te laten bieden

voor de diensten. Het volgende hoofdstuk behandelt Quality of Service.

39

Hoofdstuk 6

Quality of Service

Quality of Service (QoS) is een algemene term die slaat op het optimalisatieprobleem dat de tevreden-

heid van de eindgebruikers maximaliseert, terwijl de kosten voor het netwerk geminimaliseerd wor-

den [9].

In het kader van verpleegoproepsystemen is QoS nodig om verschillende soorten verkeer (bijvoorbeeld

oproepen, video, internet) van elkaar te scheiden en prioriteiten aan toe te kennen, zodat bijvoorbeeld

een intercomgesprek voorrang krijgt op een firmware update als het netwerk zwaar belast is. Tabel 6.1

geeft een volledige rangschikking van de nodige prioriteiten voor de verschillende diensten die op het

netwerk uitgerold kunnen worden.

Prioriteit Dienst1 Data: oproepen, controleberichten2 Voice: intercomgesprekken, VoIP3 Multimedia: audio/videodistributie4 Firmware updates5 Internet: websites bezoeken

Tabel 6.1: Overzicht van de verschillende diensten met hun prioriteit op het verpleegoproepsysteem.De hoogste prioriteit wordt toegekend aan nummer 1.

6.1 Technologieen

In deze sectie worden een aantal technologieen besproken die QoS verwezenlijken. Niet alle technolo-

gieen zijn geschikt voor het verpleegoproepsysteem.

6.1.1 Netwerklaag: Internet Protocol (IP)

IP is het meest gebruikte protocol op de netwerklaag. Onderliggende protocols kunnen verschillen tus-

sen verzender en ontvanger, dus wordt IP vaak als het laagste gemeenschappelijke protocol beschouwd.

Het is namelijk eenvoudiger om de QoS van IP op de onderliggende lagen te mappen (indien nodig),

dan om op de datalinklaag QoS door te geven van de ene link naar de volgende link, door een switch

heen.

De QoS die aangeboden wordt door IP is echter impliciet afhankelijk van de onderliggende lagen, waar

in sectie 6.1.2 aandacht aan besteed zal worden [9].

Hieronder worden een aantal QoS-ondersteunende architecturen besproken.

40

IntServ/RSVP

Integrated Services (IntServ) werkt op basis van flows. Elke flow word geklasseerd aan de hand van

5 parameters: IP-adres van verzender en ontvanger, TCP/UDP-poort van verzender en ontvanger en

het gebruikte protocol (TCP of UDP). Vanuit deze classificatie wordt scheduling gestuurd. Voor elke

flow moeten resources voorzien worden, anders wordt een flow niet toegelaten tot het netwerk. Deze

voorziening gebeurt met het Resource ReSerVation Protocol (RSVP) [9]. Deze resources kunnen gezien

worden als een hoeveelheid bandbreedte op het netwerk of bijvoorbeeld een tijdslot waarin pakketten

verstuurd mogen worden.

Aangezien IntServ gebruik maakt van een zeer fijne classificatie op basis van flows, is de schaalbaarheid

van dit systeem beperkt. Dit soort complexe classificatie is niet vereist in het verpleegoproepsysteem.

DiffServ

Differentiated Services (DiffServ) is eenvoudiger dan IntServ, maar biedt nog steeds garanties wat be-

treft QoS. Het is nog steeds beter dan Best Effort (BE)1.

Waar bij IntServ gewerkt wordt met flows, wordt hier met een klein aantal klassen gewerkt. Deze klassen

worden aangeduid in de IP header (zowel IPv4 als IPv6) door het Differentiated Services CodePoint(DSCP) veld. Er worden geen expliciete berichten verstuurd (dynamisch) om bepaalde flows toe te laten

over een pad, maar er wordt gebruik gemaakt van Per Hop Behaviours (PHBs). Deze PHB’s zijn regels

in elke router tussen verzender en ontvanger, die - gebaseerd op het DSCP veld - de binnenkomende

pakketten klasseren en vervolgens in een prioriteitssysteem plaatsen. De pakketten worden vervolgens

met QoS naar de volgende hop (router) verstuurd [9].

DiffServ heeft twee types van PHB’s: Expedited Forwarding (EF) en Assured Forwarding (AF). EF zorgt

voor een lage delay, jitter en pakketverlies met een gegarandeerde bandbreedte. AF PHB zorgt ervoor

dat iets minder strenge eisen ook gehaald worden, en definieert 4 klassen AF1x tot AF4x, met daarin 3

drop precedence levels (AFx1 tot AFx3). Binnen een AF klasse, is de kans dat een pakket uit AFx1 gedropt

wordt kleiner dan de kans dat een pakket uit AFx2 gedropt wordt (analoog voor AFx3).

Dit systeem is aangewezen bij het toekomstige verpleegoproepsysteem, aangezien er een aantal duide-

lijk afgelijnde klassen van verkeer kunnen gedefinieerd worden aan de hand van Tabel 6.1.

Tabel 6.2 toont de verschillende AF klassen met hun drop precendence levels en hun DSCP waarden. Voor

EF is het DSCP gelijk aan 46 (0x101110) [7].

Klasse 1 Klasse 2 Klasse 3 Klasse 4Low Drop Precedence AF11 AF21 AF31 AF41

0x001010 (10) 0x010010 (18) 0x011010 (26) 0x100010 (34)Medium Drop Precedence AF12 AF22 AF32 AF42

0x001100 (12) 0x010100 (20) 0x011100 (28) 0x100100 (36)Hogh Drop Precedence AF13 AF23 AF33 AF43

0x001110 (14) 0x010110 (22) 0x011110 (30) 0x100110 (38)

Tabel 6.2: Overzicht van de AF PHB’s [11].

MPLS

Multi-Protocol Label Switching (MPLS) voorziet nieuwe forwarding regels, die niet gebaseerd zijn op

IP-adres, maar op basis van MPLS-labels. Afhankelijk van het label kan een pakket op een andere link

verstuurd worden richting ontvanger. Echter, in het verpleegoproepsysteem is telkens slechts 1 pad

1Best Effort moet hier gezien worden zoals gedefinieerd in “Deploying IP and MPLS QoS for Multiservice Networks” [9].

41

te vinden tussen verzender en ontvanger, dus het opzetten van Label-Switched Paths (LSPs) is overbo-

dig [9].

6.1.2 Datalinklaag: Ethernet

De standaarden IEEE 802.1D, 802.1P en 802.1Q bieden QoS op de datalinklaag. Deze standaarden

introduceren VLAN’s [25, 27] en VLAN-prioriteiten [26]. Elk Ethernetframe krijgt (naast de VLAN ID)

een 3-bit user priority veld. Dit veld geeft aan wat de prioriteit van het frame is. Hierdoor kan in een

DiffServ domein ook op laag 2 QoS geboden worden, op vergelijkbare wijze als DiffServ.

De verschillende prioriteiten op de datalinklaag zijn minder talrijk, er zijn namelijk slechts 8 niveau’s

mogelijk. Het zijn er veel meer op de netwerklaag voor DiffServ. Er moet dus een geschikte mappinggevonden worden tussen beide QoS-architecturen.

Merk op dat het belangrijk is om ook QoS op de datalinklaag te voorzien. Daar waar QoS-routers

steeds op de netwerklaag werken, zijn switches slechts actief op de datalinklaag. Dus in tussenliggende

switches kan DiffServ geen QoS garanderen. Een veilige oplossing hiervoor is om VLAN-prioriteiten

te gebruiken die zo goed mogelijk overeenkomen met de reeds aanwezige DiffServ-klassen. Hierdoor

wordt in QoS-switches ook voorrang gegeven aan de verpleegoproepberichten.

6.2 Conclusie

In dit korte hoofdstuk werden de verschillende mogelijkheden besproken om het netwerk Quality ofService te laten bieden aan de diensten uit vorig hoofdstuk.

Op de netwerklaag wordt gekozen voor een DiffServ-architectuur. Op de datalinklaag kan gebruik

gemaakt worden van VLAN-prioriteiten. Het is nodig om ook op de datalinklaag QoS aan te bieden

omdat ook in de tussenliggende switches de diensten prioritair verwerkt moeten worden.

Nu zijn alle elementen voor een testimplementatie aanwezig: de topologie werd in hoofdstuk 4 be-

sproken, daarna werden de nieuwe diensten in hoofdstuk 5 besproken en in dit hoofdstuk werd QpS

behandeld.

Het volgende en laatste hoofdstuk bespreekt hoe deze elementen samengebracht werden tot een wer-

kende testopstelling.

42

Hoofdstuk 7

Implementatie

Dit hoofdstuk bespreekt de implementatie van de testopstelling van het toekomstige verpleegoproep-

systeem met de nieuwe diensten. Er worden daarna tests gedefinieerd om te evalueren of het netwerk

daadwerkelijk QoS kan ondersteunen.

7.1 Vereenvoudigingen

Het toekomstige verpleegoproepsysteem is een systeem met heel veel diensten en nieuwe mogelijkhe-

den. Te veel om in een testopstelling onder te brengen. Deze sectie bespreekt de vereenvoudigingen die

toegepast werden.

Enkel Video en FTP: de introductie van nieuwe diensten is een tijdrovende taak. Daarom wordt deze

masterproef beperkt tot de introductie van video- en bestandsverkeer. Gesprekken implementeren

met Voice over IP is een vrij complexe zaak en kan moeilijk getest worden, terwijl video veel

gemakkelijker getest kan worden. Dit komt omdat het gebruik van microfoons en luidsprekers in

een schaalbare testomgeving eerder moeilijk is. Het gebruik van beeldschermen is eenvoudiger.

Internettoegang kan vrij snel geımplementeerd worden maar wordt toch niet beschouwd omdat

de bandbreedte voor dit soort verkeer eerder laag is. Firmware updates implementeren vraagt een

aanpak met strengere eisen waardoor het veel meer tijd zou vragen om te implementeren, maar

het verkeer dat ze veroorzaken op het netwerk is heel eenvoudig te emuleren, door via het FTP

protocol vanop een server gegevens op te vragen. Dit genereert een indicatieve belasting op het

netwerk.

Switch-functionaliteit: in hoofdstuk 4 werden een aantal mogelijkheden voor bus-, ster- en ringtopo-

logie in detail besproken. In de bus- en ringtopologie worden de kamernodes in serie met elkaar

verbonden met of zonder externe switches, dus met 1 of 2 NIC’s.

De switchfunctionaliteit inbouwen in de software is niet enkel tijdrovend maar zal nooit de snel-

heid en efficientie bereiken die een externe switch kan bereiken. Om de tests zo representatief

mogelijk te maken is het beter om in de testopstellingen steeds gebruik te maken van externe

switches. Dit verlaagt de tijd om de software te ontwikkelen en verhoogt de tijd die beschikbaar

is voor evaluatie. Dit zorgt er tevens voor dat de tests representatiever worden.

De switch-functionaliteit kan in een commerciele toepassing in de kamernode ingebouwd worden,

dus met 2 NIC’s per kamernode.

43

Multicast snooping: in hoofdstuk 5 werd bij de dienst Multimedia Broadcasting gebruik gemaakt van

IP multicast om alle videostromen maximaal 1 keer over een netwerksegment te sturen. Via mul-

ticast snooping kan elke multicast switch bepalen of de stroom verder moet gestuurd worden en,

indien er meerdere interfaces zijn, op welke interfaces die stroom al dan niet moet doorgestuurd

worden.

Beschouw het voorbeeld in Figuur 7.1. Elke multicast snooping-switch moet een lijst bijhouden

van de kamernodes die op elke multicastgroep geabonneerd zijn. De switch kan dit doen door alle

IGMP berichten af te luisteren op de netwerklaag. Enkel indien een interface een route naar een

geabonneerde kamernode bevat, moet een multicast pakket voor die multicast groep doorgestuurd

worden. Indien er op een interface geen kamernodes meer zijn die de videostroom wensen te

ontvangen, kunnen de netwerklinks minder belast worden door die multicastpakketten niet door

te sturen.

Multicast snooping wordt hier niet geımplementeerd omdat het te veel tijd in beslag neemt om

te implementeren en kan als verbetering op het toekomstige systeem beschouwd worden. In

plaats hiervan wordt het eenvoudige geval beschouwd waarbij multicast zonder snooping gebruikt

wordt. Dit komt overeen met een gewone broadcast op het netwerk.

��

��

��

��

��

��

��

(a) Unicast

��

��

��

��

��

��

��

(b) Multicast zonder snooping

��

��

��

��

��

��

��

(c) Multicast met snooping

Figuur 7.1: Voorbeeld: multicast snooping.

Algemene oproep: de algemene oproep is een manier om een bericht via audio broadcasting over het

netwerk naar de kamers te verspreiden. Dit kan geımplementeerd worden door een achtergrond-

44

proces dat luistert op een specifieke poort voor de algemene oproep. De implementatie hiervan is

vrij eenvoudig, maar het is in de testomgevingen niet eenvoudig om dit te testen, aangezien hier

microfoons en luidsprekers voor nodig zijn. Daarom wordt het hier achterwege gelaten.

Een implementatie hiervan zou gebruik maken van RTP over UDP zoals bij de videodistributie,

waarbij nu enkel een audiostroom gedistribueerd wordt.

Dynamische prioriteiten/DiffServ: een verbetering op de statische definitie van de prioriteit in de

gebruikte DiffServ-configuratie zou er uit kunnen bestaan om dynamisch de prioriteiten van be-

paalde diensten in te stellen. Dit zou zowel automatisch als manueel kunnen gebeuren. Zo kan ’s

nachts bijvoorbeeld de prioriteit van firmware-updates (FTP) hoger gezet worden dan de prioriteit

van video.

Het dynamisch aanpassen van het systeem zou dan met de hoogste prioriteit gebeuren, samen

met de verpleegoproepen, zodat de aanpassing direct over het netwerk verstuurd wordt. Er wordt

voor gekozen om deze functionaliteit niet te voorzien omdat de ontwikkeling van dit soort functi-

onaliteit veel tijd kost.

Beveiliging: migratie naar IP betekent openheid en compatibiliteit met de huidige standaarden. Dit

brengt echter grote beveiligingsrisico’s met zich mee. Zo kunnen pakketten onderschept en gere-

produceerd worden. Authenticatie en encryptie van de berichten is cruciaal om de veiligheid van

het systeem en de informatie die over het systeem verstuurd wordt te garanderen. Dit vergt echter

veel tijd om te implementeren, en is niet nodig voor een Proof of Concept.

Een mogelijke implementatie zou kunnen zijn om bidirectionele encryptie bovenop SSL/TLS (Se-cure Socket Layer / Transport Layer Security) te voorzien. SSL/TLS zorgt dan voor de authenticatie.

Videogesprekken: om videogesprekken te ondersteunen moet een raamwerk, gelijkaardig aan dat van

Voice over IP, opgezet worden. Dit vergt behoorlijk veel tijd en valt bijgevolg buiten het bestek

van deze masterproef. Om toch het netwerkaspect van videogesprekken te ondersteunen kunnen

bijvoorbeeld videostromen tussen twee clients opgezet worden. Op het netwerk maakt dit geen

verschil uit, behalve de afwezigheid van call set-up berichten.

Wegens tijdsgebrek wordt enkel broadcast video behandeld.

Geen DHCP: hoewel DHCP een gemakkelijke manier is om IP-adressen en netwerkconfiguratie door te

geven aan nieuwe kamernodes, wordt in de testopstelling steeds gewerkt met statische IP-adressen

omdat dit gemakkelijker is om mee te werken en in kleinere omgevingen toch weinig nut heeft.

7.2 Implementatie per dienst

Deze sectie bespreekt de implementatie van de beschouwde diensten op het toekomstige netwerk. Hier

wordt de implementatie van drie diensten in detail besproken: data, video en firmware updates.

7.2.1 Basiswerking: Debian Linux

De implementatie van de verschillende diensten moet op een zo compact mogelijk apparaat gebeuren,

bij voorkeur op een ingebed systeem. Wegens de beperkte schaalbaarheid van een testopstelling met

ingebedde systemen, werd ervoor gekozen om de verschillende entiteiten te implementeren op pc’s met

45

een Linux besturingssysteem. Door gebruik te maken van een open source besturingssysteem kan de

netwerkstapel overgenomen worden1, wat niet kan in commerciele software zoals Microsoft Windows.

In deze paragraaf werd reeds gesproken over het overnemen van de netwerkstapel. Hoewel dit mogelijk

is binnen Linux zelf door de kernel te wijzigen, werd ervoor gekozen om de netwerkstapel aan te passen

door gebruik te maken van de Click Modular Router, kortweg Click [15]. Click is een modulaire router

die bovenop Linux draait. Door gebruik te maken van Click kunnen binnenkomende pakketten zeer

flexibel en snel verwerkt worden. Click configuraties kunnen gebouwd worden met eenvoudige basis-

blokken om zo een complexe configuratie te verkrijgen. Deze configuratie zorgt dan voor de uitvoering

van het specifiek gewenste gedrag.

Door gebruik te maken van een reeds bestaand besturingssysteem en een goed configureerbare net-

werkstapel werd mede de correcte werking van het systeem gegarandeerd en kan er meer tijd besteed

worden aan de implementatie van de diensten zelf.

7.2.2 Data: verpleegoproepen

De verpleegoproepdienst werd in Java geımplementeerd.

Naar analogie met het huidige verpleegoproepsysteem worden twee types apparatuur gedefinieerd: de

XT module en de intelligente kamernode. De XT modules zijn minimaal aanwezig op het netwerk

en regelen een aantal parameters van de kamernodes alsook de communicatie tussen verschillende

afdelingen, die elk door een XT module worden beheerd. De kamernodes zijn autonoom maar werken

slechts volledig in het gehele systeem indien ze afhangen van een XT module.

Bij het opstarten van een kamernode worden volgende acties ondernomen:

Ontdekking XT module: wanneer het besturingssysteem opgestart is, wordt een IP-adres toegewezen

aan deze machine via DHCP of werd reeds een statisch IP-adres toegekend. Vanuit Java kan de

gateway niet opgevraagd worden in de kamernode. Hiervoor wordt een discover bericht gestuurd

op het huidige subnet van de kamernode. De XT module antwoordt hierop en geeft zijn IP-adres

aan de kamernode. Dit wordt slechts 1 maal uitgevoerd per kamernode.

Merk op dat hier verondersteld wordt dat de XT module de DHCP-server is, wat niet steeds het

geval hoeft te zijn. Dit systeem werkt ook als de XT module niet de gateway is voor de kamernodes.

Registratie bij een XT module: indien de kamernode reeds geregistreerd was, wordt geen extra actie

ondernomen. Indien de kamernode nog niet geregistreerd was, wordt een registratiebericht ge-

stuurd naar de gateway. De XT module geeft de kamernode een naam en een nummer. Dit proces

wordt net als ontdekking slechts 1 keer uitgevoerd.

Figuur 7.2 toont dit initiele proces.

Deze implementatie van de verpleegoproepdienst is heel eenvoudig gehouden, omdat enkel de dimen-

sionering van het netwerk echt van belang is. De specifieke functionaliteit kan later verfijnd worden.

Zowel de XT modules als de kamernodes hebben een configuratiebestand. Voor een kamernode bevat dit

bestand de gateway, het nummer en de naam van de kamernode, zodat de kamernode ook werkt indien

er geen connectiviteit is met de XT module en om herhaaldelijke registratie te vermijden. Voor een XT

module bevat het configuratiebestand het nummer van de XT module en de verschillende tabellen die

bijhouden welke kamernodes geregistreerd zijn, inclusief naam, nummer en IP-adres.

De nummering van de kamernodes gebeurt als volgt: elke XT module heeft een nummer van 1 tot bij-

voorbeeld 162. Binnen elke XT module worden maximaal 253 kamernodes verondersteld: een IP-adres1Dit kan gezien worden alsof de datalink- en netwerklaag vervangen worden door een eigen implementatie. De andere lagen

blijven onveranderd.2Uitbreidingen met meer dan 16 XT modules zijn ook realiseerbaar.

46

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Figuur 7.2: Opstartproces van een node.

wordt voorbehouden voor de XT module. De netwerken broadcastadressen3 kunnen niet gebruikt

worden. Om 253 adressen te ondersteunen wordt per XT module gebruikt gemaakt van een getal van 3

cijfers. Het volledige kamernodenummer wordt dan gevormd door de 3 cijfers vooraf te laten gaan door

het nummer van de XT module. Zo is een kamernodenummer steeds uniek binnen een systeem. Voor-

beelden van kamernodenummers: 1001 - XT module 1, kamernode 1; 5032 - XT module 5, kamernode

32; 10243 - XT module 10, kamernode 243.

Merk op dat de mapping van nummers op IP-adressen niet bindend is. Er zijn meer nummers dan

IP-adressen en het is mogelijk dat nummers groter dan 253 gebruikt worden. Het aantal IP-adressen

limiteert het aantal nummers, maar niet het bereik van die nummers. Het bereik wordt namelijk gelimi-

teerd tot 999 nummers: 3 cijfers zonder nummer 000. Het is dus perfect mogelijk dat kamernode 2031

IP-adres 192.168.2.31 heeft, maar het kan ook zijn dat het IP-adres 192.168.10.47 is. Er wordt dus op

applicatieniveau abstractie gemaakt van het IP-adres.

Er werd naast een XT module en een kamernode ook een beperkte beheersoftware geımplementeerd.

Deze software kan bij een XT module opvragen wat zijn beheerde kamernodes zijn, inclusief naam en

nummer. Ook kunnen het nummer en de naam gewijzigd worden per kamernode.

Figuur 7.3 toont een voorbeeld van een XT module en een kamernode. De voorbeelden zijn niet nood-

zakelijk aan elkaar gerelateerd.

3Respectievelijk *.*.*.0/24 en *.*.*.255/24.

47

De verpleegoproepberichten worden met DiffServ’s Expedited Forwarding verstuurd, de hoogste prio-

riteitsklasse van DiffServ. Dit geeft een DiffServ CodePoint met waarde 0x101110 (46).

(a) Voorbeeld van een XT module (command-olijn)

(b) Voorbeeld van een kamernode

(c) Voorbeeld van een XT module (grafisch)

Figuur 7.3: Screenshots van de ontwikkelde software voor de verpleegoproepdienst.

De details van implementatie kunnen worden teruggevonden op de website op de cd-rom.

De code bevindt zich onder thesis/java/Node, thesis/java/XT, thesis/java/ConfigTool en

thesis/java/Common.

7.2.3 Video: XStreamer en VLC

Bij broadcast video wordt vanuit 1 centrale videoserver een videostroom verstuurd naar een IP multicast

adres.

Om meerdere videostromen te verzenden wordt gebruik gemaakt van verschillende multicastadressen.

Elke videostroom wordt op 1 multicast adres uitgezonden. Elke kamernode kan dan op een multicast

adres geabonneerd zijn, terwijl de andere stromen hier dan niet toekomen indien de tussenliggende

routers en switches multicast snooping zouden toepassen, zie ook 7.1.

De videostromen worden met DiffServ’s Assured Forwarding klasse 2, drop level 1 (AF21) verstuurd. De

prioriteit van deze berichten is lager dan die van de verpleegoproepberichten. Dit geeft een DiffServ

CodePoint met waarde 0x10010 (18).

Video Streamer

De verzender wordt geımplementeerd met de XStreamer video-streamingserver [29]. XStreamer werd

ontwikkeld binnen de Universiteit Gent. Gelijkaardig aan de Click router, werkt XStreamer met elemen-

taire blokken die via een grafische interface of rechtstreeks in het XML-bestand geconfigureerd kunnen

worden.

48

Voor dit specifieke doel moet enkel een lokale videostroom verstuurd worden over het netwerk. Dit

gebeurt hier via RTP-pakketten in UDP-pakketten. Hiervoor wordt een configuratiebestand gebruikt, zie

Figuur 7.4.

De ffmpeg-reader leest het videobestand in, met als bestandsnaam de tweede commandolijnparameter4.

De audio- en videostromen worden naar aparte packetizers verstuurd (pes-packet-video en pes-packet-audio). PES staat voor MPEG-2 Primary Elementary Stream. Dit is de specificatie voor het MPEG-2

communicatieprotocol. Deze packetizers zetten de binnenkomende stromen om in pakketten. Deze

pakketten worden vervolgens samengebracht in een ts-multiplexer. TS staat hier voor MPEG-2 TransportStream. De pakketten die de ts-multiplexer genereert, bevatten zowel audio als video, en in elk pakket

zijn de audio en video gesynchroniseerd.

Hierna worden de pakketten van de transport stream aan de basic-scheduler doorgegeven. Deze be-

paalt de vertraging en de snelheid van verzenden, zodat de video even lang doorgestuurd wordt als hij

duurt. Tenslotte wordt deze stroom doorgestuurd naar de rtp-transmitter die de volledige stroom in RTP-

pakketten plaatst en doorstuurt naar het opgegeven IP-adres en de opgegeven poort. De verzendpoort

wordt door de vierde commandolijnparameter gegeven en de ontvanger wordt als derde commando-

lijnparameter opgegeven, bijvoorbeeld 244.244.1.16:5554. Hierbij is de ontvangstpoort 5554. Merk

op dat als ontvangstpoort steeds 5554 gekozen wordt. Dit moet een even poort zijn. Poort 5555 zal

gebruikt worden door RTCP (Real-Time Control Protocol) om feedback te geven over de kwaliteit van

het ontvangen signaal.

Op de bijgevoegde cd-rom staat meer uitleg over de configuratie van de XStreamer en staat tevens

meer informatie over de elementaire blokken.

IP Multicast

Klasse D IP-adressen worden gebruikt voor multicast bestemmingen. Ze worden gekenmerkt door de

eerste 3 bits die gelijk zijn aan 0x111. Het International Assigned Numbers Authority (IANA) regelt de

toekenning van de verschillende IP multicast adressen [3]. Er wordt gekozen voor het 224.224.1.0/24

subnet aangezien dit niet gereserveerd wordt.

Merk op dat XStreamer meerdere videostromen tegelijk kan versturen door meerdere videobestanden

in te lezen, en naar verschillende unicast- of multicastadressen te versturen. Dit zal gebruikt worden

voor het aanbieden van meerdere videokanalen.

In plaats van met statische multicastadressen te werken is het ook mogelijk om via het Session Announ-cement Protocol (SAP) informatie over multicastsessies over het netwerk te verspreiden [10].

Video Client

Om de video te bekijken op de kamernode wordt gebruik gemaakt van de VLC mediaspeler [33], een

populaire mediaspeler die bovendien gratis verkrijgbaar is. Ook de broncode is vrij beschikbaar. Voor

een unicaststroom kan VLC vanop de commandolijn opgeroepen worden met het volgende commando:

vlc rtp://@:5554

Om een multicaststroom te bekijken wordt volgend commando gebruikt:

vlc rtp://@244.244.1.16:5554

4De eerste commandolijnparameter is het configuratiebestand voor XStreamer.

49

Figuur 7.4: XStreamer configuratie voor het distribueren van een lokaal videobestand.

7.2.4 Firmware updates: File Transfer Protocol (FTP)

Firmware updates worden steeds uitgevoerd op een kamernode. Echter, de bestanden die de kamernode

nodig heeft om een update te doen, moeten op het netwerk beschikbaar zijn. Hiervoor wordt een update

server gebruikt. Deze server is eigenlijk gewoon een FTP-server die een aantal bestanden bevat. Deze

bestanden zijn bijvoorbeeld genummerd op versie van de firmware van de kamernode. De kamernode

kan om de zoveel tijd controleren wat de laatste nieuwe versie is op de server.

Indien een versie gedetecteerd wordt die hoger is dan de reeds geınstalleerde versie, kan het bestand

gedownload worden van de FTP server en kan de update lokaal uitgevoerd worden.

Deze functionaliteit voorzien kost veel tijd en heeft weinig bijdrage tot het toekomstige netwerk zelf.

Het verkeer dat op het netwerk gebracht wordt is belangrijker. Dus in plaats van de firmware updates

volledig te implementeren, zullen de kamernodes continu bestanden downloaden van de update server,

om het netwerk goed te belasten.

De server wordt geımplementeerd door een FTP daemon zoals vsftpd en de kamernode kan gebruik

maken van bijvoorbeeld wget.

De dienst firmware updates maakt gebruik van DiffServ’s Assured Forwarding klasse 3, drop level 1

(AF31). De prioriteit van deze berichten is lager dan die van de verpleegoproepberichten en video-

stromen. Dit geeft een DiffServ CodePoint met waarde 0x011010 (26).

50

7.3 Testopstelling

In de vorige sectie werden alle gebruikte diensten in detail besproken. In deze sectie worden ze sa-

mengevoegd om een testopstelling te vormen. Deze testopstelling geldt als Proof of Concept voor deze

masterproef.

7.3.1 Virtual Wall

De Universiteit Gent beschikt over een Virtual Wall, gebaseerd op Emulab van de universiteit van

Utah [31]. De Virtual Wall is een onderzoeksomgeving waarin een 100-tal pc’s ter beschikking gesteld

worden. Deze pc’s worden voortaan nodes genoemd.

Op elke node kan op automatische wijze een disk image gekopieerd worden. Zo kan een besturingssys-

teem op zeer korte tijd in gebruik genomen worden. De netwerkverbindingen worden ook automatisch

aangepast aan de topologie van de gewenste testopstelling. Er wordt een hoogperformante program-

meerbare switch gebruikt om de interconnecties tussen de verschillende nodes te voorzien.

Een experiment op de Virtual Wall wordt gedefinieerd door een configuratiebestand dat een gelijkaar-

dige syntax heeft als bij The Network Simulator (NS) [30]. Dit bestand bevat zowel de configuratie van

de nodes als de configuratie van het netwerk waarmee de nodes verbonden zijn.

Een emulatie op de Virtual Wall kan dus gebruikt worden om een groot aantal fysische machines met

elkaar te laten interageren zonder de lange installatieprocedure te moeten doorlopen. Ook de net-

werkelementen moeten niet manueel geconfigureerd worden. Dit wordt door de beheersoftware op de

Virtual Wall verzorgd.

Elke node op de Virtual Wall heeft een netwerkkaart die enkel gebruikt wordt om communicatie te

hebben met het internet of voor het opzetten van netwerkshares. Deze interface mag uiteraard niet

gebruikt worden door de testopstelling om data of video naartoe te sturen die eigen is aan de testen.

Aangepaste routeringstabellen in de XT module en kamernodes volstaan hiervoor. Maar in de Click

router en switches moet in het configuratiebestand expliciet ingevuld worden welke interfaces ge-

bruikt moeten worden. Voor de router moeten zelfs IP-adres, subnet en MAC (Medium Access Control)adres expliciet ingevuld worden. Hiervoor werden extra Linux scripts geschreven die nader toegelicht

worden op de website en onder thesis/linux.

7.3.2 Topologie

Figuur 7.5 toont de topologie zoals ze door de Virtual Wall gevisualiseerd wordt. De namen onder de

nodes zijn de namen van de machines. Aangevuld met .10linktest.smindreau.wall.test vormt dit

een Fully Qualified Domain Name (FQDN) binnen het testlab.

Deze topologie is een directe implementatie van de topologie voorgesteld in Figuur 4.3. Uit Tabel 4.1

bleek reeds dat de bustopologie de laagste bandbreedtemogelijkheden biedt. Daarom is het ook interes-

sant om deze topologie te testen: hoe minder beschikbare bandbreedte hoe meer de limieten van het

netwerk kunnen afgetast worden.

Aangezien het in Click moeilijk is om de pakketten van de applicatielaag te capteren, werd gekozen om

een externe Click router te gebruiken, in plaats van de XT module zelf te laten routeren. Deze externe

router wordt door de node clickrouter op Figuur 7.5 voorgesteld.

Helemaal rechts bevindt zich de server. Deze server verstuurt de videostromen en bevat de FTP server.

Er zijn 10 nodes (i.e. kamers) en 1 XT module aanwezig. De interconnectiestructuur is een bus. De

tussenliggende clickswitches zorgen voor het doorgeven van pakketten tot aan het einde van de bus.

51

Figuur 7.5: Topologie van het experiment “10linktest” op de Virtual Wall.

De clickrouter zorgt dat het subnet van de server enerzijds en het subnet van alle andere nodes met

elkaar kunnen communiceren. Alle zwarte lijnen met gele eindpunten zijn netwerklinks. Deze kunnen

standaard 1Gbps snelheden aan. De interfaces worden echter ingesteld om slechts op 100Mbps uit te

zenden. Dit geeft een realistischer beeld omdat in de realiteit waarschijnlijk geen gigabitnetwerken

zullen gebruikt worden.

Figuur 7.6 toont een foto van de Virtual Wall waar deze testopstelling op actief was. Enkel de kamer-

nodes en de XT module worden op een scherm getoond. Op de figuur is de XT module op de tweede

kolom onderaan te zien. Alle andere schermen met blauwe achtergrond tonen de 10 kamernodes.

Figuur 7.6: Foto van de Virtual Wall met experiment “10linktest”, met 11 gebruikte schermen.

52

7.3.3 Configuratie van de nodes

Alle Linux shell scripts kunnen teruggevonden worden op de cd-rom onder thesis/linux. Ze worden

tevens in detail toegelicht op de website.

Click Router/Switches

Op basis van de voorbeeldrouterconfiguratie uit [16] werd de configuratie voor de router gebouwd. Een

variant hierop vervangt de wachtlijnen bij uitgaande poorten door een QoS blok, zie Figuur 7.7. Zo kan

een router snel geconfigureerd worden om al dan niet QoS te ondersteunen. Merk op dat deze figuur

enkel het QoS blok toont en niet de algemene routerblokken. Daarvoor wordt verwezen naar [16].

Figuur 7.7: Click-elementen die samen een subset van de DiffServ QoS klassen differentieren, met extraBandwidthShapers zodat er gegarandeerde vooruitgang is voor FTP en Other.

De Click switches zijn gebouwd rond het reeds bestaande EtherSwitch element. Figuur 7.8 geeft hiervan

de implementatie met 3 poorten. De variant met QoS gebruikt eveneens de constructie uit Figuur 7.7

in plaats van de reeds aanwezige wachtlijnen.

53

Figuur 7.8: Volledige Click switch configuratie met 3 poorten, geen QoS.

Het QoS-element werkt als volgt: alle inkomende pakketten worden geklasseerd op basis van hun type.

IP pakketten worden verder verwerkt, maar ARP (Address Resolution Protocol) pakketten worden direct

naar de wachtlijn met de hoogste prioriteit doorgestuurd omdat deze pakketten niet geklasseerd moeten

worden, ze moeten steeds voorrang krijgen op alle pakketten. De IP-pakketten worden van hun Ethernet

header ontdaan en door IPClassifier gescheiden op poortnummer. De poorten die gebruikt worden staan

in Tabel 7.1.

Dienst Poortnummer(s)Verpleegoproepen 3331, 3332, 3333, 3334Video 5554, 5555FTP 21, 22

Tabel 7.1: Gebruikte poorten in de testopstelling.

Vervolgens wordt het DiffServ CodePoint (DSCP) van de pakketten ingesteld op het betreffende num-

mer dat overeenkomt met de waarden die in paragraaf 7.2 besproken werden. Deze conversie van

poortnummer naar DSCP zou eigenlijk slechts eenmalig moeten gebeuren, wanneer een pakket uitge-

stuurd wordt door een kamernode, maar er werd gekozen om dit overal te doen, om homogeniteit te

behouden.

Vervolgens worden alle pakketten in wachtlijnen geplaatst. De wachtlijnen voor video en FTP worden

(uitgaand) begrensd tot respectievelijk 40 en 20 Mbps. De PrioSched zal vervolgens steeds uit wachtlijn

0 (meest linkse) een pakket opvragen. Dit gaat door totdat er geen pakketten meer zijn in wachtlijn

0. Dan wordt wachtlijn 1 aangedaan die slechts een doorvoer van 40 Mbps zal aanbieden, waardoor

wachtlijn 2 aangedaan kan worden, enzovoort.

Deze implementatie van een QoS element kan op vele manieren gewijzigd worden, er zijn veel mogelijke

alternatieven voor prioriteitsschedulers. Er werd hier gekozen voor een eenvoudige implementatie.

Meer informatie over de precieze werking van de elementaire blokken kan op de website van Click

teruggevonden worden [14].

Het IP-adres van de Click router is voor het core netwerk 192.168.10.2 en voor het edge netwerk

192.168.11.1. De click switches hebben uiteraard geen IP-adres nodig.

Server

De server biedt twee diensten aan: een data-dienst en een videodistributiedienst.

54

Voor de data-dienst werd oorspronkelijk gekozen voor FTP. Het leek echter nuttiger om het programma

iperf (IP pERFormance) hiervoor te gebruiken omdat op die manier voor elke datastroom achteraf

gerapporteerd wordt hoeveel de gemiddelde bandbreedte bedroeg [22]. Iperf probeert te achterhalen

wat de maximale bandbreedte op het medium is. Ook is er geen I/O (input/output) meer naar de

harde schijf, waardoor de data sneller aangeleverd kunnen worden aan het netwerk. De gebruikte

commando’s zijn voor de server:

iperf -s -p 21

en voor de client (100 seconden lang):

iperf -c $SERVER_ADDRESS -p 21 -t 100

Om de click router en switches te kunnen hergebruiken wordt iperf op poort 21 geınstalleerd zodat het

lijkt alsof dit een FTP stroom is, hoewel iperf een ander protocol dan FTP gebruikt.

De videodistributie wordt door XStreamer verzorgd. Er werden twintig videofragmenten uitgekozen om

op het netwerk te verzenden. Deze zijn representatief voor lokale, nationale, internationale en thema-

zenders. Ze werden geencodeerd met de MPEG-4 Part 10 Advanced Video Coding / ITU-T H.264 codec

aan gemiddeld 1.2 Mbps. De transcodering naar dit nieuwe formaat gebeurde met FFmpeg [1] via

een zelfgeschreven frontend buiten deze masterproef [20]. De fragmenten worden tegelijk uitgestuurd

vanop de server door twintig instanties van de XStreamer server uit te voeren, elk vanaf een ander poort-

nummer. Tabel 7.2 geeft een overzicht van de gebruikte IP multicast adressen, samen met de inhoud

van het videokanaal. De poorten van waarop verstuurd wordt beginnen bij 5000 en worden telkens

met 2 vermeerderd, dus kanaal 1 wordt op poort 5000 uitgestuurd, kanaal 2 op poort 5002, enzovoort.

Aangezien RTP met even/oneven poortparen werkt moet steeds vanop een even poort verstuurd en

ontvangen worden. De bestemmingspoort is steeds 5554.

Logisch kanaal Inhoud IP multicast adres1 VRT Nieuwsuitzending 224.224.1.12 Canvas: Panorama 224.224.1.23 VTM Nieuwsuitzending 224.224.1.34 VT4: reclame 224.224.1.45 VijfTV: trailer 224.224.1.56 National Geographic: trailer 224.224.1.67 Fox: House M.D. trailer 224.224.1.78 Family Guy trailer 224.224.1.89 My Name is Earl trailer 224.224.1.9

10 Wii Shopping Channel 224.224.1.1011 Travel Channel 224.224.1.1112 Cartoon Channel 224.224.1.1213 BBC One 224.224.1.1314 BBC Two 224.224.1.1415 Spaanse Televisie 224.224.1.1516 Kanaal Z 224.224.1.1617 AVS 224.224.1.1718 The Matrix DVD trailer 224.224.1.1819 MSNBC Nieuwsuitzending 224.224.1.1920 Top Gear: 407 km/h 224.224.1.20

Tabel 7.2: Gebruikte IP multicast adressen, poorten en inhoud van de videostromen.

Het eerder vermelde $SERVER ADDRESS is het IP-adres van de server, namelijk 192.168.10.1. De ge-

bruikte multicast adressen zijn 224.224.1.1 - 224.224.1.20.

55

Wegens plaatsgebrek op de cd-rom werden de videofragmenten niet meegeleverd. De videofragmen-

ten zijn echter allemaal afkomstig van Youtube en kunnen dus vrij bekeken worden.

Kamernodes en XT module

De kamernodes en XT module bestaan hoofdzakelijk uit de Java-programma’s die in sectie 7.2.2 bespro-

ken werden. Op de kamernodes is echter ook een video streaming client aanwezig, VLC Media Player en

de iperf-client. Figuur 7.9 toont foto’s van de XT module en kamernodes in actie.

Voor de Virtual Wall werden de XT module en kamernodes licht uitgebreid om automatisch te kunnen

werken. De kamernodes zorgen ervoor dat er per seconde minstens 1 keer op een willekeurige knop

gedrukt werd. Hierdoor is het niet nodig om manueel het netwerk aan te sturen.

De XT module krijgt er een grafische interface bij zoals reeds in Figuur 7.3 te zien was. Hierdoor is het

makkelijker om te beoordelen of alle nodes al dan niet goed werken.

(a) XT module: linksboven de logberichten, in het middende grafische voorstelling.

(b) Kamernode: in het midden de verpleegoproepsoftware,rechtsboven video, links onderaan de logberichten van deverpleegoproepen en rechts onderaan de iperf-client.

Figuur 7.9: Foto’s van de XT module (links) en een kamernode (rechts) in werking.

De nodes hebben vaste IP-adressen vanaf 192.168.11.11. Het IP-adres van de XT module is

192.168.11.2.

7.3.4 Problemen op de Virtual Wall

Een aantal struikelblokken bij de implementatie op de Virtual Wall worden hieronder besproken.

FTP poorten: op de Virtual Wall worden virtuele verbindingen gelegd tussen de nodes door gebruik

te maken van VLAN’s (Virtual Local Area Network). Wanneer echter een FTP-stroom door zo een

VLAN ging, bleek er toch wat fout te gaan. Het poortnummer van de server was niet 20 (FTP-

data) maar een willekeurig nummer boven 1024. Dit gaf problemen bij het differentieren van

datastromen in het QoS-blok van de router en switches.

Dit werd opgelost door gebruik te maken van iperf in plaats van FTP. De poortnummers werden

niet meer veranderd. De reden hiervoor is me niet bekend.

56

Linktest: op de Virtual Wall is het mogelijk om vooraf een “linktest” uit te voeren om te garanderen dat

de virtuele links (VLANs) wel degelijk goed verbonden zijn en aan een correcte snelheid pakketten

doorlaten. Het is namelijk mogelijk om een hoeveelheid verlies of vertraging te definieren op elke

link. Aangezien er echter gebruik gemaakt wordt van een Click router en switches is de linktest

niet geldig, aangezien de Click switches eigenlijk geen IP-adres hebben. Standaard wordt hier dan

ook aangeraden om geen linktest te doen.

Naarmate de experimenten vorderden, bleken echter vreemde problemen op te treden. Sommige

kamernodes konden geen video bekijken, geen verbinding maken met de XT module en ook iperf

werkte er niet. Alle Click switches werkten nochtans wel. Om dit verder te onderzoeken werd een

aangepast experiment gemaakt, waarin op elke link een ander IP subnet gekozen werd. Vervolgens

kon de linktest wel uitgevoerd worden.

De linktest gaf meermaals fouten op een aantal links die geen pakketten konden versturen. Door

iteratief verwijderen van een aantal nodes kon een testopstelling met 10 kamers (23 nodes) dan

toch gerealiseerd worden. Ook hiervoor kan ik geen reden bedenken behalve het niet goed func-

tioneren van een aantal nodes.

Multicast/IGMP: voor de XT module en elke kamernode werd de routeringstabel grondig aangepast.

Er is namelijk een extra subnet: het core subnet waar de server zich bevindt. Bovendien moet

de server in de routeringstabel een regel hebben voor de multicast berichten, anders worden

deze over het controlenetwerk van de Virtual Wall verspreid en niet over het netwerk binnen de

testopstelling. Wanneer dan video verstuurd wordt op het netwerk, wordt dit via de Click router

en Click switches overgebracht tot aan de verschillende kamers. Maar op die kamers kon de

videostroom niet afgespeeld worden, hoewel de videoberichten daadwerkelijk toekwamen op de

kamernodes.

Het probleem was dat voor IP multicast het IGMP protocol gebruikt wordt. Om op een multi-

cast stroom geabonneerd te worden, moeten tussen de ontvanger en de eerste multicast-router

een aantal IGMP berichten uitgewisseld worden. Zolang deze berichten niet uitgewisseld wor-

den, weet de node niet dat hij de berichten voor het multicastadres mag aanvaarden, en de node

negeert ze dus. Er moest dus ook op elke kamernode een extra regel in de routeringstabel toege-

voegd worden voor IP multicastroute.

Het aantal nodes is beperkt omdat het veel tijd vraagt om specifieke nodes te isoleren. In de toekomst

worden best nog grotere testen uitgevoerd met meer dan 40 kamers, terwijl nu slechts 10 kamers

geemuleerd werden.

7.4 Definitie van testen

Het systeem werd nu volledig beschreven en het is nu mogelijk om op deze testopstelling een aantal

tests uit te voeren.

Er wordt 1 test uitgevoerd op de zonet besproken testopstelling op de Virtual Wall. De test bestaat erin

om het verschil te zoeken tussen de volgende scenario’s:

Scenario 1: bepalen van vertraging en pakketverlies zonder QoS

Scenario 2: bepalen van vertraging en pakketverlies met QoS

57

In beide scenario’s wordt het netwerk zo veel mogelijk belast, door alle videostromen naar alle nodes te

verzenden in multicast (zonder snooping) en alle nodes tegelijk continu iperf-verkeer te laten veroor-

zaken. Dit is een onrealistische situatie, maar geeft een goede indicatie van het slechtste geval waarin

het netwerk kan terechtkomen. Dit slechtste geval moet hoe dan ook binnen de perken gehouden

worden.

Theoretisch wordt verwacht dat scenario 1 een hoger pakketverlies en/of hogere vertraging van de

berichten zal hebben voor de verpleegoproepen. Ook de videostromen kunnen hinder ondervinden van

de grote hoeveelheid achtergrondverkeer.

Om het verlies en de vertraging te berekenen werden de applicaties voor verpleegoproepen uitgebreid.

Elk bericht dat op het netwerk geplaatst wordt, wordt voorzien van een tijdswaarde. Bij ontvangst van

dit bericht wordt er nog een tijdswaarde aan toegevoegd zodat de vertraging berekend kan worden.

Elke kamernode en de XT module houden dus een lijst bij met alle ontvangen berichten en hun vertra-

ging. Deze lijst wordt naar een bestand weggeschreven zodat dit na de test nog beschikbaar is.

Een belangrijk probleem hierbij is de correctheid van de tijdswaarde. Het is belangrijk dat alle nodes

steeds een goed gesynchroniseerde klok hebben. Hiervoor werd elke node uitgerust met een achter-

grondproces dat elke minuut de klok op de node synchroniseert met een NTP-server (Network TimeProtocol).

Om het berichtverlies te berekenen wordt aan elk bericht ook een sequentienummer toegevoegd. Dit

nummer is voor elk bericht verschillend, maar het nummer is niet uniek in de test. Daarom wordt ook

het IP-adres van de verzender gebruikt om een uniek paar te vormen. De informatie op de XT module

kan dan achteraf gebruikt worden om te bepalen of er berichtverlies is opgetreden.

Merk op dat hier gesproken wordt over berichtverlies en niet pakketverlies alsook vertraging van berich-

ten eerder dan vertraging van pakketten. Het gaat hier om vertraging en verlies op de applicatielaag.

Dus het kan zijn dat een bericht veel vertraging heeft omdat er onderliggend op IP-niveau bijvoorbeeld

pakketverlies is opgetreden. Maar de notie van Quality of Service is enkel van belang voor de appli-

catielaag. Het verlies van een TCP-pakket is dus niet zo erg aangezien TCP ervoor zal zorgen dat het

opnieuw verzonden wordt. Er treedt slechts een probleem op indien een bericht verloren gaat op de

applicatielaag of de vertraging wegens pakketverlies op een onderliggende laag te hoog wordt. Het is

dus in deze context erg belangrijk om een verschil te maken tussen QoS op applicatieniveau en QoS op

netwerkniveau.

Uitgebreidere testen

Vorige twee testen beschouwen enkel maar het verlies den de vertraging op de verpleegoproepberichten

en het FTP-verkeer5.

Een uitbreiding naar de toekomst kan zijn om ook de kwaliteit van het ontvangen videosignaal te

meten. Zowel het effectieve pakketverlies als de kwaliteit van het ontvangen beeld ten opzichte van

het verzonden beeld kan dan geevalueerd worden. Een maat die hier zeer goed geschikt voor is is de

Peak Signal-to-Noise Ratio (PSNR) [32].

Ook het pakketverlies, eerder dan enkel het berichtverlies van de verpleegoproepberichten, kan zeer

interessante informatie opleveren wat betreft het aantal herverzendingen op het netwerk.

5In al het voorgaande werd FTP-verkeer gebruikt, maar dit sloeg enkel op poort 21 en 22. In feite was het iperf-verkeer, maarhet gaat hem hier om de bandbreedte, niet de specifieke protocols.

58

7.5 Resultaten

De resultaten duiden er direct op dat er een onderscheid moet gemaakt worden tussen beide richtingen

wat betreft vertraging. Dus de resultaten voor de richting “Kamernodes naar XT” en de resultaten voor

de richting “XT naar Kamernodes” worden apart behandeld.

Scenario 1 werd een kleine 2 uur lang uitgevoerd. Scenario 2 werd een uur lang uitgevoerd.

Figuur 7.10 toont de testresultaten voor de vertraging van de verpleegoproepberichten. Nergens trad

berichtverlies op. Er is een klein foutje opgetreden tijdens scenario 1 waardoor kamernode 8 geen

berichten heeft gestuurd naar de XT module of er een probleem was qua registratie. Dit kan kleine

afwijkingen in de resultaten opleveren.

De volgende conclusies kunnen hieruit getrokken worden:

• De vertragingen voor beide richtingen zijn duidelijk verschillend tussen scenario 1 (geen QoS)

en scenario 2 (wel QoS). Het is duidelijk dat de introductie van QoS in het netwerk aanleiding

geeft tot veel lagere maximale vertragingstijden. Hiermee is de belangrijkste doelstelling van deze

Proof of Concept bereikt, namelijk het garanderen van lage vertragingstijden voor de belangrijkste

diensten;

• Er is geen relatie tussen de afstand van de kamernode tot de XT module en de vertraging die door

het netwerk veroorzaakt wordt;

• In het scenario zonder QoS valt op dat de maximale vertraging van de XT module naar de nodes

groter is dan de maximale vertraging van de nodes naar de XT module. Dit komt omdat in de

richting “XT module naar Kamernodes” er reeds heel wat iperf- en videoverkeer is. In de andere

richting zijn daar enkel wat controleberichten terug te vinden omdat iperf niet ingesteld is om

bidirectionele stress testen uit te voeren.

• De gemiddelde vertragingstijden voor het netwerk met QoS liggen steeds onder 150ms en de

maximale vertragingstijden onder 170ms.

De totale gebruikte bandbreedte voor iperf is een stuk lager in het geval van QoS. De QoS-blokken in

de Click switches en router hebben effectief de bandbreedte van 75 naar 19 Mbps kunnen herleiden.

Er is geen zichtbaar kwaliteitsverlies op de videostromen te merken.

Ook hier moeten meer testen ondernomen worden om nog beter in te kunnen schatten of het QoS

netwerk voldoende presteert voor de doeleinden van het verpleegoproepsysteem.

Het kan ook interessant zijn om het Click QoS element zonder BandwidthShapers te construeren.

Op die manier kan het netwerk misschien geoptimaliseerd worden door het achtergrondverkeer een

eerlijk deel te geven van de beschikbare bandbreedte.

De ruwe testresultaten kunnen teruggevonden worden onder thesis/tests/20090505* samen met

een aantal videofragmenten ter demonstratie. Het bestand thesis/tests/Results.xlsx bevat de

testresultaten in compactere vorm.

59

0

500

1000

1500

2000

2500

3000

3500

4000

1 2 3 4 5 6 7 8 9 10

Del

ay(m

s)


Maximum delay, direction: Node to XT

Average delay, direction: Node to XT

Maximum delay, direction: XT to Node

Average delay, direction: XT to Node

(a) Scenario 1: geen QoS

0

500

1000

1500

2000

2500

3000

3500

4000

1 2 3 4 5 6 7 8 9 10

Del

ay(m

s)


Maximum delay, direction: Node to XT

Average delay, direction: Node to XT

Maximum delay, direction: XT to Node

Average delay, direction: XT to Node

(b) Scenario 2: wel QoS

Figuur 7.10: Resultaten van de tests voor scenario’s 1 en 2.

60

7.6 Conclusie

In dit hoofdstuk werd het Proof of Concept van deze masterproef behandeld. De verschillende vereenvou-

digingen werden eerst besproken, waarna veel aandacht besteed werd aan de werkelijke implementatie

van de diensten. De Virtual Wall en de praktische problemen erop werden hier ook besproken.

Daarna werden een aantal scenario’s gedefinieerd en getest. De resultaten zijn erg gunstig: bij gebruik

van QoS is het mogelijk om de vertraging op berichten te reduceren tot 170ms, terwijl dit oploopt tot

meer dan 3s indien geen QoS gebruikt wordt.

61

Nawoord

In deze masterproef werden een aantal erg verschillende onderwerpen besproken.

Het huidige verpleegoproepsysteem van Televic werd eerst behandeld waarna via statistische modellen

een nieuwe netwerkparameter ontwikkeld werd: een discrete maximale onmiddellijke bandbreedte. De

beschouwde statistische modellen zijn reeds bruikbaar maar moeten nog verder verfijnd worden.

Verder op het voorspellend pad werd de reeds ontwikkelde StateMachine software gevalideerd. De

voorspellingen op het LON-netwerk vielen erg tegen, maar de voorspellingen op het IP-netwerk waren

wel van goede kwaliteit.

Daarna werd het toekomstige verpleegoproepsysteem behandeld. De topologie was een eerste stap om

de laagste lagen van het netwerk te definieren en te bespreken. Op het einde van hoofdstuk 4 werd een

duidelijke vergelijking tussen drie topologieen behandeld: ster-, bus- en ringtopologie.

De nieuwe diensten werden daarna geıntroduceerd.

Net daarbij aansluitend werd Quality of Service behandeld. Dit is het belangrijkste concept in deze

masterproef, niettegenstaande dit een kort hoofdstuk is. Het is dankzij Quality of Service dat het netwerk

betrouwbaar genoemd kan worden.

Tenslotte werd in hoofdstuk 7 de implementatie van de testopstelling besproken voor het Proof of Con-cept. De Virtual Wall en de implementatie werden er tevens besproken. De testresultaten zijn zeer

gunstig: het netwerk zonder QoS presteert in het slechtste geval meer dan tienmaal slechter dan het

netwerk met QoS.

Er is nog wat ruimte voor verbetering bij de behandelde onderwerpen. Zo kunnen de statistische mo-

dellen uit hoofdstuk 2 nog verfijnd en onderzocht worden naar geldigheid. De berekeningen voor het

IP-netwerk moeten ook overgedaan worden met meer kennis over de topologie. De validatie van beide

conversiestappen StateMachine en de statistische modellen kan dan ook bepaald worden.

In hoofdstuk 4 werd aangehaald dat het de moeite kan lonen om de invloed van RSTP op de beschikbare

bandbreedte te bestuderen. Nog in dat hoofdstuk kan de ad-hoc topologie verder bestudeerd worden.

Hoofdstuk 5 duidde reeds op de mogelijkheid om SIP te laten communiceren met een PSTN-netwerk.

IPv6 moet in de toekomst ook ondersteund worden.

Tenslotte kunnen de testen uit het laatste hoofdstuk uitgebreid worden naar een grotere hoeveelheid

nodes en kunnen er meer testscenario’s bedacht worden. Het Click QoS element kan ook andere com-

binaties van elementen bevatten, hier kan ook mee geexperimenteerd worden.

Deze masterproef bevat alle elementen die ik graag in mijn masterproef had gezien. De nodige kennis

om deze masterproef tot een goed einde te brengen heb ik dan ook uit mijn gehele opleiding kunnen

halen.

Zo ben ik heel veel met communicatienetwerken in contact gekomen en heb ik een groot stuk functionele

analyse mogen uitvoeren van de eisen van de virtuele klant, Televic. Ik mocht zelf aan de slag om de

nieuwe diensten te implementeren, en heb met de Virtual Wall mogen werken. Ik heb ook continuıteit

mogen geven aan mijn stage bij Televic door de software die ik toen ontwikkeld heb te valideren. Ik

62

heb zeer veel moeten opzoeken en onderzoeken over de manier waarop ik statistische modellen kon

opstellen. Ik heb mijn Linux-skills nog eens kunnen aanscherpen, om de automatisatie van de tests op

de Virtual Wall tot een goed einde te brengen.

De afwisseling die ik terugvond in deze masterproef is dan ook echt de afwisseling waar ik later naar

op zoek ben. Op deze manier heeft mijn masterproef me erg veel bijgebracht en erg gemotiveerd om

duidelijk mijn toekomstperspectieven uit te lijnen en kracht bij te zetten.

63

Bibliografie

[1] FFmpeg. http://www.ffmpeg.org/, 7 mei 2009.

[2] 802.3at Task Force. 802.3at: DTE Power Enhancements. http://www.ieee802.org/3/at/, 30

oktober 2008.

[3] Z. Albanna, K. Almeroth, D. Meyer, and M. Schipper. Request for Comment 3171: IANA Guidelinesfor IPv4 Multicast Address Assignments. Augustus 2001. http://tools.ietf.org/html/rfc3171,

27 maart 2009.

[4] Gerald Combs. Wireshark Network Protocol Analyzer. http://www.wireshark.org, 26 mei 2009.

[5] Echelon Corporation. LON network and protocols. http://www.echelon.com/, 1 november 2008.

[6] Echelon Corporation. LonScannerTM Protocol Analyzer User’s Guide.

[7] B. Davie, A. Charny, J.C.R. Bennett, K. Benson, J.Y. Le Boudec, W. Courtney, S. Davari, V. Firoiu,

and D. Stiliadis. Request for Comment 2598: An Expedited Forwarding PHB (Per-Hop Behaviour).

Maart 2002. http://tools.ietf.org/html/rfc2598, 26 mei 2009.

[8] Piet Demeester and Mario Pickavet. Multimedia Networks Course. Universiteit Gent, 2008.

[9] John Evans and Clarence Filsfils. Deploying IP and MPLS QoS for Multiservice Networks. Morgan

Kauffman, 2007. ISBN 0-12370-549-5.

[10] M. Handley, C. Perkins, and E. Whelan. Request for Comment 2974: Session Announcement Protocol(SAP). Oktober 2000. http://tools.ietf.org/html/rfc2974, 19 mei 2009.

[11] J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski. Request for Comment 2597: Assured ForwardingPHB Group. Juni 1999. http://tools.ietf.org/html/rfc2597, 26 mei 2009.

[12] Avaya Inc. A Practical Guide to Power Over Ethernet (PoE). October 2006. http://support.avaya.

com/elmodocs2/C360/PoE_Avaya_R1_1.pdf, 30 oktober 2008.

[13] ISO/IEC. Information Technology - Open Systems Interconnection - Basic Reference Model: The BasicModel. 1996. http://standards.iso.org/ittf/PubliclyAvailableStandards/s020269_ISO_

IEC_7498-1_1994(E).zip, 17 mei 2009.

[14] Eddie Kohler. Click Element Documentation. http://read.cs.ucla.edu/click/elements, 7 mei

2009.

[15] Eddie Kohler. The Click Modular Router. Februari 2001. http://read.cs.ucla.edu/click/, 19

mei 2009.

[16] Eddie Kohler. The Click Modular Router, figuur 5.1: An IP router configuration, p. 64. Februari

2001.

64

http://www.ffmpeg.org/

http://www.ieee802.org/3/at/

http://tools.ietf.org/html/rfc3171

http://www.wireshark.org

http://www.echelon.com/




http://support.avaya.com/elmodocs2/C360/PoE_Avaya_R1_1.pdf

http://support.avaya.com/elmodocs2/C360/PoE_Avaya_R1_1.pdf

http://standards.iso.org/ittf/PubliclyAvailableStandards/s020269_ISO_IEC_7498-1_1994(E).zip

http://standards.iso.org/ittf/PubliclyAvailableStandards/s020269_ISO_IEC_7498-1_1994(E).zip

http://read.cs.ucla.edu/click/elements

http://read.cs.ucla.edu/click/

[17] James F. Kurose and Keith W. Ross. Computer Networking: a top-down approach featuring theinternet. Pearson/Addison Wesley, Boston, 2005. ISBN 0-321-26976-4.

[18] Jardar Leira. WEB Portals. 2005. http://forskningsnett.uninett.no/wlan/webportal.html.

[19] Sun Microsystems. NetBeans Integrated Development Environment (IDE). http://www.netbeans.

org, 26 mei 2009.

[20] Sebastiaan Mindreau. JFmpeg, a Java frontend for FFmpeg (alpha). http://sourceforge.net/

projects/jfmpeg/, 7 mei 2009.

[21] Sebastiaan Mindreau. StateMachine softwaretool. Televic.

[22] The Distributed Applications Support Team (DAST) National Laboratory for Applied Network Re-

search (NLANR). Iperf. http://iperf.sourceforge.net, 7 mei 2009.

[23] Bastian Piepers. Schriftelijke communicatie. 25 mei 2009.

[24] IEEE Computer Society. 802.3af: Carrier Sense Multiple Access with Collision Detection (CSMA/CD)access method and physical layer specifications, clause 33: Data Terminal Equipment (DTE) Powervia Media Dependent Interface (MDI), 2003.

[25] IEEE Computer Society. 802.1d: IEEE Standard for Local and metropolitan area networks: MediumAccess Control (MAC) bridges. 2006.

[26] IEEE Computer Society. 802.1p: IEEE Standard for Local and metropolitan area networks: MediumAccess Control (MAC) bridges, annex G: “User priorities and traffic classes”. 2006.

[27] IEEE Computer Society. 802.1q: IEEE Standard for Local and metropolitan area networks: VirtualBridged Local Area Network. 2006.

[28] TechRepublic Staff. Fast Ethernet proves to be popular among respondents as their primary networktopology (poll). http://books.techrepublic.com.com/5100-10878_11-1061874.html, 30okto-

ber 2008.

[29] IBCN Universiteit Gent. XStreamer, video streaming server.

[30] Information Sciences Institute Universiteit van Zuid-Californie. The Network Simulator. http:

//www.isi.edu/nsnam/ns/, 6 mei 2009.

[31] Universiteit van Utah. Emulab, Network Emulation Testbed. http://www.emulab.net, 6 mei 2009.

[32] Rik Vandewalle. Cursus Multimedia. Universiteit Gent, 2007.

[33] VideoLAN. VLC Multimedia player. http://www.videolan.org, 19 februari 2009.

[34] Wikipedia. Bootstrapping (statistics). http://en.wikipedia.org/wiki/Bootstrapping_

(statistics), 3 februari 2009.

[35] Wikipedia. Cycle (graph theory). http://en.wikipedia.org/wiki/Cycle_(graph_theory), 17

mei 2009.

[36] Wikipedia. H.264/MPEG-4 AVC. http://en.wikipedia.org/wiki/H.264#Levels.

[37] Wald Wojdak. Rapid Spanning Tree Protocol: A new solution from an old technology, volume Maart

2003.

65

http://forskningsnett.uninett.no/wlan/webportal.html

http://www.netbeans.org

http://www.netbeans.org

http://sourceforge.net/projects/jfmpeg/

http://sourceforge.net/projects/jfmpeg/

http://iperf.sourceforge.net

http://books.techrepublic.com.com/5100-10878_11-1061874.html

http://www.isi.edu/nsnam/ns/

http://www.isi.edu/nsnam/ns/

http://www.emulab.net

http://www.videolan.org

http://en.wikipedia.org/wiki/Bootstrapping_(statistics)

http://en.wikipedia.org/wiki/Bootstrapping_(statistics)

http://en.wikipedia.org/wiki/Cycle_(graph_theory)

http://en.wikipedia.org/wiki/H.264#Levels

Lijst van figuren

1 Het TCP/IP internet model met enkele bijhorende protocols. . . . . . . . . . . . . . . . . 6

1.1 Overzicht van de topologie van het huidige verpleegoproepsysteem. . . . . . . . . . . . . 8

2.1 Verschil tussen de klassieke IPG en de gebruikte IFS. . . . . . . . . . . . . . . . . . . . . 10

2.2 Schematische voorstelling van de te berekenen verdelingen. . . . . . . . . . . . . . . . . 11

2.3 Werkwijze bij het opstellen van de modellen voor de IFS’s (histogram slechts ter illustratie). 13

2.4 Schematische voorstelling van bestanden medianmodel.txt en avgvarmodel.txt en hun

gebruik bij de drie verschillende modellen. . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5 Voorbeeld van een Matlab cell die door discretizeDataset wordt gegenereerd. . . . . . 17

2.6 Uitvoer van de functies datasetMaxBW en datasetModelMaxBW, alle onbenoemde getallen

zijn uitgedrukt in kbps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.7 Gedetailleerd tijdsverloop van twee pakketten op het LON-netwerk ter illustratie van de

lage nauwkeurigheid van de LON-metingen. . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.8 Resultaat van berekeningen van de maximale onmiddellijke bandbreedte voor verschil-

lende waarden voor het schuivende venster (LON). . . . . . . . . . . . . . . . . . . . . . 21

2.9 Resultaat van berekeningen van de maximale onmiddellijke bandbreedte voor verschil-

lende waarden voor het schuivende venster (IP). . . . . . . . . . . . . . . . . . . . . . . 21

3.1 Topologie van het netwerk van de geobserveerde implementatie. . . . . . . . . . . . . . 23

3.2 Overzicht van het totale conversieproces ter bepaling van de voorspelde belasting op het

netwerk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1 Schematische voorstelling van het nieuw netwerk. . . . . . . . . . . . . . . . . . . . . . 27

4.2 Bustopologie met twee NIC’s per kamernode. . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3 Bustopologie met externe switches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.4 Stertopologie: elke kamernode is rechtstreeks verbonden met een XT module. . . . . . . 28

4.5 Stertopologie met tussenliggende switches. . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.6 Ringtoplogie met Spanning Tree Protocol (STP). . . . . . . . . . . . . . . . . . . . . . . . 29

4.7 Ad-hoc topologie toegepast op het toekomstige verpleegoproepsysteem. . . . . . . . . . 31

5.1 Voorbeeld van CIDR-notatie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7.1 Voorbeeld: multicast snooping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.2 Opstartproces van een node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7.3 Screenshots van de ontwikkelde software voor de verpleegoproepdienst. . . . . . . . . . 48

7.4 XStreamer configuratie voor het distribueren van een lokaal videobestand. . . . . . . . . 50

7.5 Topologie van het experiment “10linktest” op de Virtual Wall. . . . . . . . . . . . . . . . 52

7.6 Foto van de Virtual Wall met experiment “10linktest”, met 11 gebruikte schermen. . . . . 52

66

7.7 Click-elementen die samen een subset van de DiffServ QoS klassen differentieren, met

extra BandwidthShapers zodat er gegarandeerde vooruitgang is voor FTP en Other. . . . 53

7.8 Volledige Click switch configuratie met 3 poorten, geen QoS. . . . . . . . . . . . . . . . . 54

7.9 Foto’s van de XT module (links) en een kamernode (rechts) in werking. . . . . . . . . . . 56

7.10 Resultaten van de tests voor scenario’s 1 en 2. . . . . . . . . . . . . . . . . . . . . . . . . 60

67

Lijst van tabellen

2.1 Overzicht van de IFS’s van beide datasets. . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Resultaten van reele en gemodelleerde maximale bandbreedtes op het LON-netwerk. . . 19

2.3 Resultaten van reele en gemodelleerde maximale bandbreedtes op het IP-netwerk. . . . . 20

3.1 Resultaten van de vergelijkende studie tussen de logberichten en LON tegenover de voor-

spelling op basis van enkel de logberichten. . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Resultaten van de vergelijkende studie tussen de logberichten en IP tegenover de voor-

spelling op basis van enkel de logberichten. . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1 Vergelijking van bus-, ster- en ringtopologie: theoretisch (X= positief). . . . . . . . . . 30

6.1 Overzicht van de verschillende diensten met hun prioriteit op het verpleegoproepsysteem.

De hoogste prioriteit wordt toegekend aan nummer 1. . . . . . . . . . . . . . . . . . . . 40

6.2 Overzicht van de AF PHB’s [11]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.1 Gebruikte poorten in de testopstelling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.2 Gebruikte IP multicast adressen, poorten en inhoud van de videostromen. . . . . . . . . 55

68

Ontwerp en implementatie van het toekomstig netwerk voor...

Documents

Transcript of Ontwerp en implementatie van het toekomstig netwerk voor...