View
0
Download
0
Category
Preview:
Citation preview
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
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)
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 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 netwerk- en 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 netwerk- en 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)
Distance to XT (i.e. node number)
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)
Distance to XT (i.e. node number)
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
[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
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
Recommended