Ontwerp en implementatie van het toekomstige netwerk voor verpleegoproepsystemen Sebastiaan Mindreau
Promotoren: prof. dr. ir. Piet Demeester, dr. ir. Brecht Vermeulen Begeleider: Sam Lefebvre Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen
Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen Academiejaar 2008-2009
Ontwerp en implementatie van het toekomstige netwerk voor verpleegoproepsystemen Sebastiaan Mindreau
Promotoren: prof. dr. ir. Piet Demeester, dr. ir. Brecht Vermeulen Begeleider: Sam Lefebvre Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen
Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen Academiejaar 2008-2009
Voorwoord Hoe begin je aan een masterproef? Dat loodzware ding dat je in je laatste jaar moet afgeven. Al die verwachtingen, al die struikelblokken, je moet ze allemaal zeer zelfstandig tegemoet. Hoe slaag je erin om de essentie van je onderzoek te tonen zonder met de deur in huis te vallen en tegelijk de lezer niet voor dom te aanzien? Hoe schrijf je een inleiding voor dat werk? Begin je beschrijvend met een lijst van doelstellingen of begin je direct je verhaal te vertellen? Misschien is het beter om even rond de pot te draaien, dat hoort toch zo in inleidingen? 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 diep moet 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 kwelling weliswaar. En ook ik zal mijn verhaal hierin vertellen, wat wetenschappelijker dan in vorige paragrafen, maar niet minder bezield door de materie en de idee¨en die ik erin onderbreng. Want dit is een finaal werk van groot belang voor mijn eigen ontwikkeling, voor het behalen van het diploma, als bewijs van het jarenlange opnemen van informatie en het reproduceren van leerstof. De kers op de taart waarmee ik toon dat ik een waardig ingenieur mag zijn, en zelf nieuwe concepten aan het licht breng of bestaande verenig tot nieuwe semantische gehelen. D´ at is de uitdaging die ik begin dit academiejaar aanging. Het verhaal begint hieronder. E-health is tegenwoordig in volle opmars. Overal verschijnen bedrijven en oplossingen voor de zorgsector, 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 ge¨evalueerd. 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 verpleegoproepsysteem 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 technologie¨en voor het toekomstige verpleegoproepsysteem. 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 cre¨eren. 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 kamernode. 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 verpleegoproepsysteem, 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 (Transmission 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 ervan 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
TCP, UDP
Network Layer
IP
Router
Datalink Layer
Ethernet
Switch
Physical Layer
UTP cable (Unshielded Twisted Pair)
Figuur 1: Het TCP/IP internet model met enkele bijhorende protocols. In deze masterproef zullen de termen applicatielaag, transportlaag, netwerklaag, datalinklaag en fysische 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 bijgevoegde 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 statistischtheoretische fundamenten, Bart Jooris voor zijn hulp bij Ethernet-busstructuren. Dank aan Alexis Rombaut 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 masterproef: 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 kopi¨eren 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 toekomstige netwerk voor verpleegoproepsystemen Sebastiaan Mindreau Promotoren: prof. dr. ir. Piet Demeester, dr. ir. Brecht Vermeulen Begeleider: Sam Lefebvre Vakgroep Informatietechnologie, voorzitter: Dani¨el De Zutter Faculteit Ingenieurswetenschappen, Universiteit Gent Academiejaar 2008-2009
Samenvatting Deze masterproef behandelt het ontwerp en een Proof of Concept van de onderzochte technologie¨en 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 gedefini¨eerd 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 types netwerken (LON en IP) een statistisch model te vinden dat dicht in de buurt komt van de re¨ele 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 ` 30 %. Voor IP wordt een nauwkeurigheid van 75 a ` 90 % bereikt. nauwkeurigheid van slechts 20 a Trefwoorden: maximale onmiddellijke bandbreedte, toekomstige verpleegoproepsysteem, Quality of Service, meerdienstig netwerk.
Design and Implementation of the Future Nursecall Network Sebastiaan Mindreau Supervisor(s): Piet Demeester, Brecht Vermeulen, Sam Lefebvre Abstract— The design and implementation for the future nursecall 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 parameters and the evaluation of the self-created software during my internship at Televic. The future network is built bottom-up. I first present the topology possibilities with Ethernet-based networks. After that the services for the future network are discussed. To finish this part, quality of service (QoS) is introduced specifically for this network’s purpose. Finally comes the proof of concept, showing that the network with QoS is more reliable and has less delay than the network without QoS. Keywords— Maximum immediate bandwidth, Future nursecall system, Quality of Service, Multiservice network.
Figure 1 O VERVIEW OF THE C URRENT N URSECALL S YSTEM .
I NTRODUCTION This master dissertation is performed in cooperation with Televic, provider of nursecall technologies to hospitals and care homes. Their nursecall systems provide intelligent ways of communication between patients and medical staff. Their current nursecall system is getting older though. There are parts of the network that are based on Local Operating Network (LON) technology [1], which is both slow and hard to maintain. This master dissertation focuses on the discussion of their current nursecall systems as well as the evolution towards a future all-IP (Internet Protocol) network. I. T HE C URRENT N URSECALL S YSTEM Figure 1 shows an overview of the current network’s topology. It consists of a number of local centrals, referred to as XT modules, which manage a number of rooms1 . All the rooms managed by the same XT module are connected using a LON bus. All XT modules can communicate with each other and other servers or clients using the backbone IP network. II. N ETWORK PARAMETERS Now that the systems has been quickly introduced, the first phase of this master dissertation can be explained. Using the method of statistical bootstrapping [8] it was possible to create statistical models to model the distribution of packets within one second, where the logging server of the current nursecall system only allows second-precise timestamps. For both data from IP and LON network in the dataset, there is at least one model that approximates —————————————————– 1 In
this extended abstract, the term “room” will be used in stead of the term “node” to indicate the device that is placed in a patient’s room.
the correct maximum immediate bandwidth of the dataset. For the IP data, this is the mean model, with an accuracy of 79%. For the LON data, this is the median model, with an accuracy of 59%. III. C OMPARISON S TUDY Another part of prediction was already performed during my internship at Televic. There I created a tool to predict the packets on the network, given the log messages from the logging server. This master dissertation also validates that tool. The predictions on the LON network are not good, they are only 23 to 30% accurate. The predictions on the IP network are of better quality: 74 to 90%. IV. T HE N EW T OPOLOGY When removing the LON-elements from the current nursecall network, a topology constraint is relieved. This opens new possibilities. There are four different types of topologies possible in the future nursecall system. These topologies are the way that rooms are to be connected to the XT modules. If they are kept in a bus topology, we need little cables, but jeopardize the available bandwidth. When using star topology, there is a much larger cable cost but every room has a large bandwidth towards the XT module. Combining the best of both worlds results in a ring topology, having a redundant link, which is disabled through the Rapid Spanning Tree Protocol (RSTP) [9]. The cable costs are not as high as with star topology and the available bandwidth is higher than in a normal bus topology. Finally there is also an ad-hoc topology possible in which the network may have any topology. This provides the greatest amount of flexibility but adds much uncertainty of assured bandwidth into the network.
V. T HE N EW S ERVICES
4000
Once the topology is in place, new services are to be added to the future nursecall system. A first service is the data service for nursecall messages and control messages. The nursecall service runs on TCP to have assured delivery. The second service is voice communication. This service can be deployed using existing VoIP frameworks, consisting of a control plane on SDP/SIP over TCP and a user plane carrying the audio on RTP/RTCP over UDP [2]. A third service consists of multimedia broadcasting. Both audio and video can be distributed using IP multicast to the different rooms. A fourth service is the background firmware update service. Using the FTP protocol it is possible for rooms to download their firmware updates automatically. The last service is Internet access, which can be provided using standard DHCP/firewall/gateway solutions.
3500
VI. Q UALITY
OF
S ERVICE
Now that the services have been discussed, Quality of Service (QoS) is added. Differentiated Services (DiffServ) combined with VLAN priorities is a sturdy basis for the network to guarantee priorities among the services. The priorities of the services are the same as the order in which they were presented in the previous section, with nursecall being most important [5], [6], [7]. VII. P ROOF
OF
C ONCEPT
All elements have now been discussed to be able to create a working proof of concept. Only nursecall, video broadcast and FTP were implemented, because of time constraints. The proof of concept was done on the Virtual Wall at Ghent University. This is an experiment testbed like Emulab from the University of Utah [4]. Using the Click Modular Router [3] it was possible to create QoS routers and switches for the test environment. The experiment run consisted of 10 rooms, 10 Click switches, 1 Click router, 1 XT module and 1 back-end server. All rooms continuously polled the file server, and received 20 multicast video streams from the same video streaming server. The rooms and XT communicated nursecall messages at a high pace in the meanwhile. The test was run once without QoS and once with QoS. The results are shown in Figures 2 and 3. 4000
Maximum delay, direction: Average delay, direction: Maximum delay, direction: Average delay, direction:
3500
Delay (ms)
3000
Node to XT Node to XT XT to Node XT to Node
2500 2000 1500 1000 500 0 1
2
3
4
5
6
7
8
Distance to XT (i.e. node number)
Figure 2 T EST RESULTS WITHOUT Q O S.
9
10
Maximum delay, direction: Average delay, direction: Maximum delay, direction: Average delay, direction:
Delay (ms)
3000
Node to XT Node to XT XT to Node XT to Node
2500 2000 1500 1000 500 0 1
2
3
4
5
6
7
8
9
10
Distance to XT (i.e. node number)
Figure 3 T EST RESULTS WITH Q O S.
The results are clear: using QoS reduces the maximum message delay by 6 to 17 times. Also, there was no message loss even without QoS. This is probably thanks to TCP. There was no visual degradation of the video streams. This may be accredited to the H.264/AVC video codec. I MPROVEMENTS
AND
F UTURE W ORK
Some of the most important improvements and future work: less simplifications to the statistical models to increase their accuracy, optimization of the packet prediction tool, investigating the influence of RTSP on the available network bandwidth, extending SIP to communicate with existing PSTN-networks, keeping IPv6 compatibility in mind, performing larger tests on the Virtual Wall, using PSNR to calculate video quality. C ONCLUSION The statistical models have decent accuracies when predicting packet distribution within one second. The validation of the prediction tool created during my internship at Televic resulted in a pass for the IP part, but a no-pass for the LON part. The removal of LON from the current nursecall network is best combined using QoS technologies. Tests have shown that the usage of QoS has a positive effect on the delay caused by a flooded network. R EFERENCES [1] Echelon Corporation. LON network and protocols. http: //www.echelon.com/, 01/11/2008. [2] Piet Demeester and Mario Pickavet. Multimedia Networks Course. 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 Local and metropolitan area networks: Medium Access Control (MAC) bridges. 2006. [6] IEEE Computer Society. 802.1p: IEEE Standard for Local 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 Local and metropolitan area networks: Virtual Bridged Local Area Network. 2006. [8] Wikipedia. Bootstrapping (statistics). http://en. wikipedia.org/wiki/Bootstrapping_(statistics), 03/02/2009. [9] Wald Wojdak. Rapid Spanning Tree Protocol: A new solution from 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 re¨ele bandbreedte (Matlab): 1 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
e
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Ringtopologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28 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 Technologie¨en . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 Netwerklaag: Internet Protocol (IP)
. . . . . . . . . . . . . . . . . . . . . . . . .
40 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.2 Data: verpleegoproepen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45 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 ge¨encodeerd 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 netwerkkabelcontact 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
Syst`eme 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 noodzakelijk 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 informatie 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 pati¨ent 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 be¨eindigd. Om de aanwezigheid te be¨eindigen moet opnieuw op de groene knop gedrukt worden. In de volgende hoofdstukken zal expliciet verwezen worden naar specifieke functionaliteit van het systeem. 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 pati¨ent een oproep doet door bijvoorbeeld op een knop te drukken, 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 gebeuren 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 pati¨ent wordt door de behandelende arts en een verantwoordelijke verpleegkundige een schema opgesteld van de nodige medicatie en verzorging. Hieruit worden dagelijkse taken ge¨extraheerd voor elke pati¨ent. Deze taken zijn bijvoorbeeld: wassen van de pati¨ent, medicatie X toedienen, controleren bloeddruk. 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 pati¨ent. 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 parameters op het toekomstige netwerk. In een initi¨ele 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 gedefinieerd 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 uiteraard 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 proc´ed´e te werken dat sterk lijkt op de methode van bootstrapping. 1 Een logbericht kan voorgesteld worden als een rij in een tabel. De tabel heeft velden als datum, tijd, soort oproep, locatie, naam verpleegkundige, . . . 2 De staving van deze voorspelling wordt in het volgende hoofdstuk besproken. 3 Merk 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 het volgende pakket.
9
Bootstrapping is een herbemonsteringsmethode die nieuwe monsterwaarden construeert van een geobserveerde 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 anderzijds 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 overlappende 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 CSVbestanden (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 LON IP
Totaal IFS’s 209 931 173 052
Percentage groter dan 1s 1.71 % 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 4 De pakketten werden verzameld in verschillende bestanden, wegens een aantal onhandige eigenschappen van de software om 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, . . . 5 Deze
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 . (j)
Merk op dat indien er n pakketten per seconde voorspeld worden, en we de monsters IF Si , i ∈ {1, . . . , n}, j ∈ {1, . . . , 1000} noemen, de som van deze monsters kleiner moet zijn dan 1s, of: n X
(j)
IF Si
< 1s, ∀j.
i=1
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 pakket 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. 6 De 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 tekstbestanden 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 worden [19]. Er zijn twee soorten data nodig voor de statistische verwerking: de IFS’s van de pakketten om de modellen 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 resterende 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 differenti¨ele 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 parameters. 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 ´e´en 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 ´e´en piramide opgeslagen voor de mediaan en in avgvarmodel.txt twee piramides, ´e´en voor het gemiddelde en ´e´en 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 gebruik 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 re¨ ele 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 hun gebruik bij de drie verschillende modellen. Een belangrijke stap is om deze modellen te valideren tegenover de re¨ele 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 re¨ele bandbreedte en de gemodelleerde bandbreedte moet uiteraard de re¨ele 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 onmiddellijke bandbreedte. Dit is de maximale onmiddellijke bandbreedte indien de IFS’s gegeven worden door ´e´en van de hierboven opgestelde modellen. Dus in plaats van de re¨ele 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
Tijd in s
Lijst van lengtes in bytes
31679384xxxxxx 31679384xxxxxx 31679384xxxxxx 31679386xxxxxx ...
16 12 16 16
31679384 31679385 31679386 31679387 ...
[16, 12, 16] [] [16] []
(a) Voor discretisatie: matrix
(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 bandbreedte 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 re¨ele 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 2.4.1
Validatie en resultaten 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. 7 Een cell in Matlab is een soort matrix waar elk element van de matrix opnieuw een matrix is, maar zonder dat de dimensies ervan moeten overeenkomen. Een leeg item in een cell of een item met een matrix van 10 × 1 worden allemaal ondersteund door dit 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 re¨ele 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 getallen zijn 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 tijdsverloop:
9360 <Time>11-25T16:33:10,613752 Acknowledged <Source>S/N:001/120 S/N:001/016 Msg_0x01: Code: 0x01, Data: 0x... 30 2 9361 <Time>11-25T16:33:10,614005 Acknowledgment <Source>S/N:001/016 S/N:001/120 12 2
Het eerste pakket is 30 bytes lang en duurt dus op het LON-medium: 30bytes × 8 = 3076µs 78000bits/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 de lage 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 bandbreedtes bij gebruik van een van de drie modellen voor het LON-netwerk. Hieruit blijkt dat het mediaanmodel een goede benadering is voor de re¨ele 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. Re¨eel Mediaanmodel Gemiddeldemodel Gemiddelde en variantiemodel
Venstergrootte 10 × maxtime = 38974µs 38974µs 38974µs 38974µs
Maximale bandbreedte 26,094 kbps 44,336 kbps 132,394 kbps 138,552 kbps
Tabel 2.2: Resultaten van re¨ele 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 bandbreedtes 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. Re¨eel Mediaanmodel Gemiddeldemodel Gemiddelde en variantiemodel
Venstergrootte 50000µs 50000µs 50000µs 50000µs
Maximale bandbreedte 412,160 kbps 137,120 kbps 324,160 kbps 558,560 kbps
Tabel 2.3: Resultaten van re¨ele 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 LONnetwerk is een shared medium en kent dus geen bidirectionaliteit. Het IP-netwerk heeft wel bidirectionaliteit 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 re¨ele 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 pakketten 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
100 Real Bandwidth Median Model
Maximum immediate bandwidth (kbps)
Average Model 80
Average/Variance Model Physical Limit
60
40
20
0 0
100000 200000 300000 400000 500000 600000 700000 800000 900000 1e+006 Window size (µs)
Figuur 2.8: Resultaat van berekeningen van de maximale onmiddellijke bandbreedte voor verschillende waarden voor het schuivende venster (LON).
600 Real Bandwidth Median Model Average Model
Maximum immediate bandwidth (kbps)
500
Average/Variance Model
400
300
200
100
0 0
100000 200000 300000 400000 500000 600000 700000 800000 900000 1e+006 Window size (µs)
Figuur 2.9: Resultaat van berekeningen van de maximale onmiddellijke bandbreedte voor verschillende waarden voor het schuivende venster (IP).
21
Hoofdstuk 3
Vergelijkende studie De tweede stap van deze masterproef is de validatie van de eerder ontwikkelde “StateMachine” software. 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 re¨ele systeem: • Er is slechts 1 type oproep en slechts 1 type aanwezigheid mogelijk. Op het re¨ele systeem zijn verschillende soorten mogelijk zoals: tweede aanwezigheid, sanitaire oproep, assistentie, . . . De reactie op elke oproep in het re¨ele systeem varieert ook sterk van implementatie tot implementatie: 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 re¨ele systeem. Om dit te realiseren is een aantal gegevens nodig: • Logbestanden van de logging server van de te observeren implementatie (Microsoft Access databanken); • 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 oproepachtervolgingsparameters bekend zijn. Op basis van de logbestanden wordt met behulp van de software een voorspelling gedaan van de pakketten 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; 1 Een 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 deze logberichten 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 re¨ele 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 Aantal bytes (absoluut) Aantal bytes (cumulatief) Aantal pakketten (absoluut) Aantal pakketten (cumulatief)
Foutief voorspeld 1362 1362 29 29
Totaal (re¨eel) 1786 1786 42 42
Correctheid 23.74% 23.74% 30.95% 30.95%
Tabel 3.1: Resultaten van de vergelijkende studie tussen de logberichten en LON tegenover de voorspelling op basis van enkel de logberichten. IP Aantal bytes (absoluut) Aantal bytes (cumulatief) Aantal pakketten (absoluut) Aantal pakketten (cumulatief)
Foutief voorspeld 3499 -2027 12 -6
Totaal (re¨eel) 22881 22881 64 64
Correctheid 74.71% 91.14% 81.25% 90.63%
Tabel 3.2: Resultaten van de vergelijkende studie tussen de logberichten en IP tegenover de voorspelling op 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 bandbreedteberekeningen 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 software 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 ` 30%. Voor IP ligt dit correctheid van de software haalt voor het LON-netwerk momenteel slechts 20 a ` 90%. hoger: 75 a 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 re¨ele 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 het netwerk.
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 fundamenteel tegenstrijdige eisen tegenover elkaar te staan: bekabeling in bustopologie en apparatuur die in stertopologie werkt. Op het huidige verpleegoproepsysteem worden alle kamernodes van ´e´en XT module via een bus verbonden. 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 coaxtechnologie 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 topologie¨en voorgesteld en vergeleken. Om de vergelijking op te zetten, bespreek ik eerst de nieuwe elementen in het toekomstige verpleegoproepsysteem. De voorgestelde topologie¨en 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 ´e´en XT module binnen hetzelfde subnet te houden. De XT modules moeten dus het verkeer tussen edgeen 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 update 1 We 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 bekabelingskosten 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 busstructuur. 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. 2 Hubs
cre¨eren ´e´en 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 ´e´en performante switch bijgeplaatst worden. Indien gebruik gemaakt wordt van tussenliggende switches, zijn er meer kabels nodig. Hoe meer tussenliggende 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 sterto3 Hubs 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 stergebaseerde 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 bustopologie¨en 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 Rapid Spanning 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). 4 Uit de grafentheorie: een cykel is een niet-triviaal pad van een knoop naar zichzelf. Dus het pad met nul takken is niet geldig aangezien 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 topologie¨en samen. Hierna worden ze ook besproken: Criterium Weinig kabels Hoge bandbreedte Betrouwbaarheid Lage complexiteit node Geen externe switches
Bustopologie 1 NIC 2 NIC’s X XX
X X
Stertopologie Direct Verdeeld XX XX X X
X X X
Ringtopologie 1 NIC 2 NIC’s X XX X X X 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 kamernode 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 betrouwbaarder 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 topologie¨en 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 onzekerheid 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 realistisch 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 ´r de kamernode. laatste hop v´ oo 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 topologie¨en 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 stertopologie 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 bustopologie¨en en de lagere kost dan bij de besproken stertopologie¨en.
5 IEEE
802.3at (PoE+) probeert om een hoger vermogen te bieden, maar is nog niet gestandaardiseerd [2]. m´et externe switches gewerkt wordt, moeten er hoe dan ook meer kabels getrokken worden.
6 Indien
32
Hoofdstuk 5
Diensten Dit hoofdstuk bespreekt de noodzakelijke en optionele diensten van het toekomstige verpleegoproepsysteem. 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 5.1.1
Data: verpleegoproepen en controleberichten 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 afgesproken 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. 1 Enige
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) Quality 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 applicatielaag 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, tussen XT modules onderling of tussen een XT module en een andere entiteit (verpleegpostsoftware, zorgserver, logging server, . . . ). Een aantal protocols die hieronder besproken worden, maken gebruik van controleberichten die vereist zijn voor de goede werking van het protocol. Ook deze berichten worden met deze dienst (“verpleegoproepberichten 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) audiokanalen 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. 2 De 300 connecties bevatten een 250-tal connecties naar de kamernodes en de connecties naar andere XT modules, externe clients en servers. De 10 connecties per kamernode bevat de connectie naar de XT module en eventueel nog externe clients of servers.
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 stappen vereist: compressie van het geluidssignaal (verlagen van de bandbreedte), toevoegen redundantie (Forward Error Correction (FEC)), interleaving, omvormen tot pakketten, toevoegen van een sequentienummer, . . . 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: sequentienummer, 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 garanderen), 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 Element Stream (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 kamernodes 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 ´e´en 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 LONnetwerk 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 ge¨ updatet 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 3 Firmware
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 effici¨ent 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/wachtwoordcombinatie 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 toegekend 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 gevaarlijk 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 pati¨ent 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; 4 Dit
kan bijvoorbeeld aan de hand van publieke/private sleutels zoals bij SSH logins gebruikt wordt. op dat dit NAT niet vereist is indien met IPv6 gewerkt wordt.
5 Merk
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 verpleegoproepsysteem 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 verpleegoproepsysteem, 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 verpleegoproepsysteem 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 (Classless Inter-Domain Routing). Elk IP-adres in IPv4 maakt gebruik van 4 bytes om het adres te defini¨eren. 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: Subnet masker: Subnet masker (bits): CIDR-notatie:
157 . 193 . 244 . 47 255 . 255 . 255 . 0 11111111.11111111.11111111.00000000 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 verpleegoproepsysteem 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 tevredenheid van de eindgebruikers maximaliseert, terwijl de kosten voor het netwerk geminimaliseerd worden [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 1 2 3 4 5
Dienst Data: oproepen, controleberichten Voice: intercomgesprekken, VoIP Multimedia: audio/videodistributie Firmware updates 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
Technologie¨ en
In deze sectie worden een aantal technologie¨en besproken die QoS verwezenlijken. Niet alle technologie¨en 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 tussen 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 betreft 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 duidelijk 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]. Low Drop Precedence Medium Drop Precedence Hogh Drop Precedence
Klasse 1 AF11 0x001010 (10) AF12 0x001100 (12) AF13 0x001110 (14)
Klasse 2 AF21 0x010010 (18) AF22 0x010100 (20) AF23 0x010110 (22)
Klasse 3 AF31 0x011010 (26) AF32 0x011100 (28) AF33 0x011110 (30)
Klasse 4 AF41 0x100010 (34) AF42 0x100100 (36) AF43 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 1 Best
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 overbodig [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 mapping gevonden 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 of Service 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 besproken, 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 werkende testopstelling.
42
Hoofdstuk 7
Implementatie Dit hoofdstuk bespreekt de implementatie van de testopstelling van het toekomstige verpleegoproepsysteem 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 mogelijkheden. 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 ringtopologie 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 snelheid en effici¨entie 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 commerci¨ele 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 multicast 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 achtergrond44
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 bepaalde 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 functionaliteit 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 gereproduceerd 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 (Secure 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 commerci¨ele 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 basisblokken 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 netwerkstapel 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 gestuurd 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 initi¨ele proces. Deze implementatie van de verpleegoproepdienst is heel eenvoudig gehouden, omdat enkel de dimensionering 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 bijvoorbeeld 162 . Binnen elke XT module worden maximaal 253 kamernodes verondersteld: ´e´en IP-adres 1 Dit kan gezien worden alsof de datalink- en netwerklaag vervangen worden door een eigen implementatie. De andere lagen blijven onveranderd. 2 Uitbreidingen 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. Voorbeelden 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 gelimiteerd 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 noodzakelijk aan elkaar gerelateerd. 3 Respectievelijk
*.*.*.0/24 en *.*.*.255/24.
47
De verpleegoproepberichten worden met DiffServ’s Expedited Forwarding verstuurd, de hoogste prioriteitsklasse van DiffServ. Dit geeft een DiffServ CodePoint met waarde 0x101110 (46).
(a) Voorbeeld van een XT module (commandolijn)
(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 ´e´en 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 elementaire 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-packetaudio). 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 Transport Stream. 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 bepaalt 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 RTPpakketten 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 commandolijnparameter 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 Announcement 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 4 De
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 videostromen. 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 samengevoegd 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 besturingssysteem 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 programmeerbare switch gebruikt om de interconnecties tussen de verschillende nodes te voorzien. Een experiment op de Virtual Wall wordt gedefini¨eerd door een configuratiebestand dat een gelijkaardige 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 netwerkelementen 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 gebruikt 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 interessant 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 kamernodes 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 differenti¨eren, met extra BandwidthShapers 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 Verpleegoproepen Video FTP
Poortnummer(s) 3331, 3332, 3333, 3334 5554, 5555 21, 22
Tabel 7.1: Gebruikte poorten in de testopstelling. Vervolgens wordt het DiffServ CodePoint (DSCP) van de pakketten ingesteld op het betreffende nummer 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 uitgestuurd 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 themazenders. Ze werden ge¨encodeerd 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 poortnummer. 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 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Inhoud VRT Nieuwsuitzending Canvas: Panorama VTM Nieuwsuitzending VT4: reclame VijfTV: trailer National Geographic: trailer Fox: House M.D. trailer Family Guy trailer My Name is Earl trailer Wii Shopping Channel Travel Channel Cartoon Channel BBC One BBC Two Spaanse Televisie Kanaal Z AVS The Matrix DVD trailer MSNBC Nieuwsuitzending Top Gear: 407 km/h
IP multicast adres 224.224.1.1 224.224.1.2 224.224.1.3 224.224.1.4 224.224.1.5 224.224.1.6 224.224.1.7 224.224.1.8 224.224.1.9 224.224.1.10 224.224.1.11 224.224.1.12 224.224.1.13 224.224.1.14 224.224.1.15 224.224.1.16 224.224.1.17 224.224.1.18 224.224.1.19 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 gebruikte multicast adressen zijn 224.224.1.1 - 224.224.1.20.
55
Wegens plaatsgebrek op de cd-rom werden de videofragmenten niet meegeleverd. De videofragmenten 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 besproken 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 midden (b) Kamernode: in het midden de verpleegoproepsoftware, de grafische voorstelling. rechtsboven video, links onderaan de logberichten van de verpleegoproepen 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 (FTPdata) maar een willekeurig nummer boven 1024. Dit gaf problemen bij het differenti¨eren 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 defini¨eren 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 functioneren 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 multicast stroom geabonneerd te worden, moeten tussen de ontvanger en de eerste multicast-router een aantal IGMP berichten uitgewisseld worden. Zolang deze berichten niet uitgewisseld worden, 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 toegevoegd 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 ge¨emuleerd 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 veroorzaken. 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 vertraging. 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 achtergrondproces dat elke minuut de klok op de node synchroniseert met een NTP-server (Network Time Protocol). 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 berichten 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 applicatielaag. 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 ge¨evalueerd 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.
5 In al het voorgaande werd FTP-verkeer gebruikt, maar dit sloeg enkel op poort 21 en 22. In feite was het iperf-verkeer, maar het 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
4000 Maximum delay, direction: Node to XT Average delay, direction: Node to XT
3500
Maximum delay, direction: XT to Node Average delay, direction: XT to Node
3000
Delay (ms)
2500 2000 1500 1000 500 0 1
2
3
4
5
6
7
8
9
10
Distance to XT (i.e. node number)
(a) Scenario 1: geen QoS 4000 Maximum delay, direction: Node to XT Average delay, direction: Node to XT
3500
Maximum delay, direction: XT to Node Average delay, direction: XT to Node
3000
Delay (ms)
2500 2000 1500 1000 500 0 1
2
3
4
5
6
7
8
9
Distance to XT (i.e. node number)
(b) Scenario 2: wel QoS
Figuur 7.10: Resultaten van de tests voor scenario’s 1 en 2.
60
10
7.6
Conclusie
In dit hoofdstuk werd het Proof of Concept van deze masterproef behandeld. De verschillende vereenvoudigingen 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 defini¨eren en te bespreken. Op het einde van hoofdstuk 4 werd een duidelijke vergelijking tussen drie topologie¨en 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 Concept. 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 modellen 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 combinaties van elementen bevatten, hier kan ook mee ge¨experimenteerd 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 Guidelines for 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. LonScannerT M 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 Forwarding PHB 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 Basic Model. 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 the internet. 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 Research (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) Power via Media Dependent Interface (MDI), 2003. [25] IEEE Computer Society. 802.1d: IEEE Standard for Local and metropolitan area networks: Medium Access Control (MAC) bridges. 2006. [26] IEEE Computer Society. 802.1p: IEEE Standard for Local and metropolitan area networks: Medium Access 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: Virtual Bridged Local Area Network. 2006. [28] TechRepublic Staff. Fast Ethernet proves to be popular among respondents as their primary network topology (poll). http://books.techrepublic.com.com/5100-10878_11-1061874.html, 30oktober 2008. [29] IBCN Universiteit Gent. XStreamer, video streaming server. [30] Information Sciences Institute Universiteit van Zuid-Californi¨e. 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 verschillende waarden voor het schuivende venster (LON). . . . . . . . . . . . . . . . . . . . . .
21
2.9 Resultaat van berekeningen van de maximale onmiddellijke bandbreedte voor verschillende 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Schematische voorstelling van het nieuw netwerk.
25
. . . . . . . . . . . . . . . . . . . . .
27
4.2 Bustopologie met twee NIC’s per kamernode. . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Bustopologie met externe switches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27 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 differenti¨eren, 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 re¨ele en gemodelleerde maximale bandbreedtes op het LON-netwerk. . .
19
2.3 Resultaten van re¨ele en gemodelleerde maximale bandbreedtes op het IP-netwerk. . . . .
20
3.1 Resultaten van de vergelijkende studie tussen de logberichten en LON tegenover de voorspelling op basis van enkel de logberichten. . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.2 Resultaten van de vergelijkende studie tussen de logberichten en IP tegenover de voorspelling 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. . . . . . . . . . . . . . . . . . . . 6.2 Overzicht van de AF PHB’s [11].
40
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
7.1 Gebruikte poorten in de testopstelling. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
7.2 Gebruikte IP multicast adressen, poorten en inhoud van de videostromen. . . . . . . . .
55
68
