Business model voor robuuste netwerkopslag van medische gegevens

Transcriptie

1 Faculteit Ingenieurswetenschappen Vakgroep INTEC Voorzitter: Prof. Dr. Ir. P. Lagasse Business model voor robuuste netwerkopslag van medische gegevens door Kurt Verduyn Promotoren: Prof. Dr. Ir. Mario Pickavet, Dr. Ir. Didier Colle Scriptiebegeleider: Jan Van Ooteghem Scriptie ingediend tot het behalen van de academische graad van Burgerlijk Ingenieur in de Computerwetenschappen Academiejaar

2

3 Faculteit Ingenieurswetenschappen Vakgroep INTEC Voorzitter: Prof. Dr. Ir. P. Lagasse Business model voor robuuste netwerkopslag van medische gegevens door Kurt Verduyn Promotoren: Prof. Dr. Ir. Mario Pickavet, Dr. Ir. Didier Colle Scriptiebegeleider: Jan Van Ooteghem Scriptie ingediend tot het behalen van de academische graad van Burgerlijk Ingenieur in de Computerwetenschappen Academiejaar

4 Dankwoord De beslissing om op Erasmus te gaan had zeker zijn negatieve gevolgen voor het schrijven van deze thesis. De aanpassing en de verkenning van de Baskische streek en cultuur, het ontdekken van andere levenswijzen en het leren van de Spaanse taal hadden als gevolg dat het onderzoek voor deze thesis nooit zoals gepland verliep. In de eerste plaats wil ik dan ook mijn begeleider en promotoren bedanken voor het geduld die zij opgebracht hebben voor mij. Speciale dank gaat uit naar Jan Van Ooteghem, die in juli en augustus steeds paraat stond voor een intensieve begeleiding om deze thesis toch tot een goed einde te brengen. De heer Tony Voet wordt ook vriendelijk bedankt vanwege zijn input betreffende digitale medische beeldvorming. Dankzij hem kreeg ik meer zekerheid in mijn gedane schatting en werd deze nog lichtjes aangepast. Verder wil ik zeker nog mijn beste vrienden van Bilbao bedanken voor de goede tijd die we hebben beleefd. En zelfs al zijn deze nu weer ver weg, ze doen mij nog steeds met een glimlach terugdenken aan het voorbije jaar. Vooral de steun op onverwachte momenten gedurende de zomermaanden tot de deadline van deze thesis deed deugd. Ook wil ik van de gelegenheid profiteren om mijn proeflezers te bedanken. Stefanie, Hannelore, mama, Jan, bedankt! Als laatste wil ik mijn ouders bedanken die mij zelfs na zoveel jaren studie nog altijd evenveel steunen in wat ik doe. Zonder jullie morele en financiële steun zou ik nooit zover geraakt zijn als nu! Bedankt! i

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

6 Business model voor robuuste netwerkopslag van medische gegevens door Kurt Verduyn Scriptie ingediend tot het behalen van de academische graad van Burgerlijk Ingenieur in de Computerwetenschappen Academiejaar Promotoren: Prof. Dr. Ir. Mario Pickavet, Dr. Ir. Didier Colle Scriptiebegeleider: Jan Van Ooteghem Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep INTEC Voorzitter: Prof. Dr. Ir. P. Lagasse Samenvatting In deze thesis stellen we het business model op voor de robuuste netwerkopslag van medische data. Er wordt een toekomstvisie opgesteld voor 4 ziekenhuizen die participeren in het project. De jaarlijkse totale opslag per patiënt werd geschat. Hiermee werd de totale opslaghoeveelheid, inclusief back-up, en de netwerktrafiek tussen de locaties berekend. Een netwerkmodel wordt opgesteld om deze trafiek te ondersteunen, evenals de nodige infrastructuur voor de opslagvereisten. Als laatste wordt een economische studie verricht om zodoende de totale kost te berekenen van dit project. Trefwoorden Business model, robuuste netwerkopslag, medische data, economische studie, kostenberekening

7 Business model for robust network storage of medical data Kurt Verduyn Supervisor(s): Jan Van Ooteghem, Mario Pickavet, Didier Colle Abstract In this article we formulate the business model for the robust network storage of medical data. We lay out a prediction for the 4 hospitals that participate in the project. This includes an estimation of the total storage needed, including back-up, and the network traffic between the locations. A network model is defined to support this traffic, as well as the necessary infrastructure to fulfill the storage demands. Eventually an economical study is executed to calculate the total cost of this 5-year project. Keywords Business model, robust network storage, medical data, economical study, cost calculation I. INTRODUCTION THE Internet has known a tremendous growth, which was never anticipated. Especially due to the introduction of broadband at home new applications are being used, that demand more and more bandwidth. We want to be able to have access to our data at any moment, at any place. This is not different in the medical sector. At this moment Electronic Health Records (EHRs) are distributed among many different parties. These include: the family doctor, the hospital, the insurance company, the government and also the patient himself. It would be greatly beneficially if this data would be centralized somehow. In this manner a hospital should not have to ask the family doctor for certain information, but this could be asked directly from the (central) database. If this information is stored in plain text, the total storage is limited in space. But as time goes by, more storage is available at lower prizes, and we want to store more data with a higher quality. Digital scanners were introduced and so was digital medical imaging. The digital scanners continually offered more possibilities, and the total storage per examination rose. Doctors adapted to the change to fully use the new possibilities. No longer did they need to make a selection of the best images to print them, they could easily shoot a lot of images and store them digitally. But not only medical patient data needs to be stored. Also more and more internal and external administration is being produced, processed and stored digitally. The yearly amounts of data storage are big, but for 1 hospital only this is no real problem. Even if legislation demands that this data needs to be stored for a long time, the possibilities to store big amounts of data are numerous. The real problems arise when all parties become involved. Synchronization of the data can not be forgotten, and also offering enough Quality of Service (QoS) has strong demands of the network. To let all parties work together is not an easy job, and for considerable time already this area has been subjected to research. The EHR may already be implemented and used in many ways, but nationwide or internationally there is still a lot of work to be done due to their mutual incompatibilities. Due to the big extent of this subject, without extensive research we would easily be confronted with synchronization and security problems. Because of this even after several years this concept is still far from ready. In this paper we concentrate on connecting 4 hospitals. We estimate the total storage needed, and the total network traffic. The network topology will be defined in accordance with the QoS demands. Also the storage infrastructure will be chosen to fulfill the demands, and in the end we will estimate the total cost. A. Introduction and concepts II. BUSINESS CASE What we are trying to create is a system where all parties have secure access to the EHRs via the Internet nonetheless where and when a patient seeks medical attention. If this is possible in a fast and reliable way, then we will be able to fight personal and common diseases more efficiently. Doctors and nurses will be able to deliver a better and more individual service to the patient. The public health will improve due to the faster reaction possible against epidemics and such. Also personal health will improve because the patient has the possibility to on line check if his health parameters are not excessive. B. Yearly patient data storage To estimate the total amount of storage needed per patient, we take the following types of data into account: general patient data, administration and medical imaging. The first two types can be stored as plain text and therefore will not have a significant influence on the total storage amount. The last type will of course have a bigger influence. We came up with the following estimation for the yearly amount of storage needed per type: general patient data (155 KB), administration (1,55 MB) and medical imaging (82,43 MB). Thus a total of 84,14 MB, without compression. A. Total storage needed III. BUSINESS MODEL The 4 hospitals have been compared in size and number of patients, thus together with the result from II-B the yearly total amount of storage needed can be calculated. In table I we find the total amount of storage needed for the 5-year period of the project. Lossless compression has been applied on the data, with a factor 3:1. In the remainder of this paper all storage will be compressed in the same manner. Due to the characteristics and importance of medical data we have 3 back-ups of the original data. So, in total the data is stored 4 times. If we multiply the total for 2011 of table I,

8 UZ Gent UZ Leuven AZ St-Lucas UZ Antwerpen Total ,97 6,29 2,09 2,77 14, ,12 12,95 4,30 5,71 29, ,46 20,01 6,65 8,82 44, ,00 27,50 9,14 12,12 61, ,76 35,44 11,77 15,61 79,58 TABLE I STORAGE (TB) PER LOCATION we find that our storage infrastructure needs to support more than 318 TB by the end of One of the back-ups is on the same premises as the original data, but on a different place. The other two are distributed to a different hospital in a different city, where 2 separate systems need to be installed as well. Sending the back-up to a different city happens during the night. In each location the two different copies need to be stored separately. Therefore in table II we mention the total amount of data to be stored for each location and per back-up system. Total storage (TB) UZ Gent UZ Leuven AZ St-Lucas UZ Antwerpen ,74 11,35 2,09 9, ,83 23,38 4,30 18, ,28 36,13 6,65 28, ,12 49,64 9,14 39, ,37 63,97 11,77 51,05 TABLE II TOTAL CUMULATIVE STORAGE PER LOCATION, PER BACK-UP SYSTEM, PER B. Network modeling YEAR In order to estimate the total amount of traffic, we estimated for each type of data mentioned in II-B how many times it would be transmitted per year. This estimation depended on the distance between the locations, and the type of data. By doing this for each type of data and total up in the end we were able to consider the hospital size. After this the yearly amount of data to be transferred could be calculated, and eventually the average needed bandwidth. This bandwidth is between 1 and 2 Mbps during daytime and 1,5 and 4,52 Mbps overnight. However, the necessary bandwidth is determined because of QoS demands. Every hospital should be able to transfer 20 medical examinations at the same time, and still be able to receive these within about 1 minute. The bandwidth needed to do this is 51 Mbps. Thus the bandwidth of each link should be 144 Mbps. Until now, we never mentioned the general network topology, this was supposed to be a fully connected graph. But due to the cost of the leased lines we change this topology to the one shown in figure 1. We only connect Sint-Lucas directly to UZ Gent, and no longer to the other locations. But to ensure a high reliability we lease 2 lines. All other locations are connected to minimum 2 other locations, thus ensuring higher reliability. Let s see what happens in a worst-case scenario where each location demands a 50 Mbps download from every other hospital, which is an extremely rare situation, and the link between UZ Antwerpen and UZ Gent fails. Then the link between UZ Leuven and UZ Gent should need to transmit data at a speed of 400 Mbps. Because the line has a maximum speed of 144 Mbps, the examinations will then be received in a time of around 3 min. Fig. 1. The chosen network topology, shown with the yearly amount of data to be transferred at daytime C. Storage infrastructure To ensure enough storage space is available we install a maximum of 2 servers with a maximum of 9,75 TB storage each in every hospital. If more storage is needed we build a SAN, consisting of a Sanrad V-Switch 2000 coupled to one or more Nexsan SATABeasts or SATABoys storage servers. The first installation of storage will be able to fulfill the needs for the first 3 years (period ). The second acquisition happens in 2010 and fulfills the needs until the end of the project (2011). Due to cost erosion (10% yearly for hard drives) prices will have dropped significantly in this 3-year period. D. Economical study We calculated the total cost for this project for the 5-year period. In this calculation the following costs were included: purchase of infrastructure, installation of servers and storage systems, maintenance of servers, electricity, replacement of hard drives, network costs and security costs. In table III we report the expenses made for each year for each type just mentioned. For the installation of the servers we calculate 5% of the purchase cost. For the maintenance of servers this yearly is 10% of the purchase cost. Every year (starting from 2nd year after their first installation) 1/3 of the hard drives is replaced. So after every 3 years all HDs are replaced. Network costs are the biggest expense, almost 3 million. Total security costs are being calculated as 15% of the total price so far, what comes down to available for security spendings. Expenses Total Servers+storage Maintenance Electricity Replacement HDs Network Security Total Discounted NPV TABLE III MULTI YEAR COST ANALYSIS The total cost of the project has first been calculated in a straight-forward manner as the sum of expenses, and equals By discounting the different expenses further in the future with a factor of 15% we can calculate the Net Present Value of the project: When we spread the total cost over all patients, then we come to the estimation of 2,37 per person, for 5 years. Even with the high expenses for our network connections, this is a very reasonable price to pay.

9 Inhoudsopgave Overzicht Extended abstract Inhoudsopgave Verklarende woordenlijst iii iv vi viii 1 Inleiding Probleemstelling Doelstelling Methodologie Verloop van het werk Inhoud van de CD-ROM Content Distribution Networks Inleiding Werking van het Internet Hedendaagse Internettoepassingen Oplossingen voor de huidige Internet-architectuur Overprovisionering en serverparken Quality of Service en Traffic Engineering Multicasten en broadcasten Webcaches Oplossing met CDN-architectuur Diensten En Beveiliging Inleiding Enkele sectoren in detail Media- en entertainment-toepassingen Overheid vi

10 INHOUDSOPGAVE Niet-entertainmentsector Eindgebruikers Beveiliging Enkele diensten in detail Fotogalerijen Outsourcen van data Conclusie Opslag van medische gegevens: business case Concepten en inleiding Privacy en security Patiëntgegevens UZ Gent gegevens Opslag van medische gegevens: business model Totale opslagbenodigdheid Uitbreiding naar meer locaties Totale opslaghoeveelheid Netwerkmodellering Opslaginfrastructuur Economische studie van het project Inkomsten en besparingen Berekening van de totale kostprijs Conclusie 71 A Inhoud CD-ROM 73 Bibliografie 76 Lijst van figuren 79 Lijst van tabellen 80 vii

11 Verklarende woordenlijst CDN Content Distribution Network CAS Content Adressable Storage SAN Storage Area Network NAS Network-Attached Storage PHR Personal Health Record EHR Electronic Health Record PACS Picture Archiving and Communication System PDF Portable Document Format (Adobe) FTP File Transfer Protocol SSH Secure Shell TCP Transmission Control Protocol UDP User Datagram Protocol ISO International Organization for Standardization OSI Open Systems Interconnect SDH Synchronous Digital Hierarchy MPEG Moving Picture Experts Group JPEG Joint Photographic Experts Group IETF Internet Engineering Task Force viii

12 HOOFDSTUK 0. VERKLARENDE WOORDENLIJST QoS Quality of Service Intserv Integrated Services RSVP (Resource) Reservation Protocol Difserv Differentiated Services ISP Internet Service Provider ICP Internet Caching Protocol RPA Replica Placement Algorithm DNS Domain Name System URL Uniform Resource Locator CR Computed Radiography CT/CAT Computed Tomography MR/MRI Magnetic Resonance Imaging US Ultrasoon XA Angiografie kbps Kilobit per seconde SLA Service Level Agreement NHII National Health Information Infrastructure (organisatie VS) NCVHS National Committee on Vital and Health Statistics (organisatie VS) HHS Health and Human Services (organisatie VS) HL7 Health Level 7 HIPAA Health Insurance Portability and Accountability Act PHI Protected Health Information NPV Net Present Value NCW Netto Contante Waarde ix

13 Hoofdstuk 1 Inleiding 1.1 Probleemstelling Momenteel zijn patiëntgegevens gedistribueerd bij verschillende partijen: de huisdokter, de tandarts, de oogarts, de kinesist, het ziekenhuis, de verzekeringsmaatschappij, de regering, en tevens bij de patiënt thuis. Het zou grote voordelen bieden indien we er in slagen om al deze gegevens op een bepaalde manier te centraliseren. Op deze manier zou, wanneer een bepaald ziekenhuis informatie nodig heeft over de patiënt in behandeling, deze informatie niet meer moeten vragen aan de huisarts of een andere belangrijke partij, maar gewoon kunnen opvragen bij de (centrale) databank. Wanneer deze gegevens enkel uit tekst bestaan zijn de problemen nog niet zo groot wegens de beperkte grootte. Maar naarmate de tijd vorderde met stijgende opslagmogelijkheden en dalende prijzen willen we telkens meer informatie opslaan, met een grotere kwaliteit. Digitale scanners kwamen op de markt en de digitale medische beeldvorming was geboren. De digitale scanners bieden ook steeds meer mogelijkheden, waardoor de benodigde opslagruimte per onderzoek stijgt. Dokters veranderen daarbovenop ook hun stijl om volop gebruik te kunnen maken van de digitale evolutie. Zij moeten niet langer een keuze maken van de meest geschikte beelden voor afdruk, maar kunnen simpelweg een hele reeks beelden nemen die toch digitaal opgeslagen worden. Maar niet enkel de medische patiëntendata moet opgeslagen worden. Ook onder andere de interne en externe administratie in al zijn aspecten wordt hoe langer hoe meer volledig digitaal. De jaarlijkse opslagbenodigdheden zijn groot, maar voor 1 ziekenhuis apart is dit zeker niets om ons zorgen over te maken. De mogelijkheden om grote hoeveelheden data 1

14 HOOFDSTUK 1. INLEIDING op te slaan zijn legio. Zelfs wanneer we door de wetgeving deze data voor langdurige tijd moeten opslaan is de oplossing nabij. De echte problemen komen er wanneer alle spelers betrokken dienen te worden. Synchronisatie van de gegevens mag zeker niet uit het oog verloren worden, en ook voor het aanbieden van voldoende Quality of Service wordt er veel geëist van het netwerk. Het laten samenwerken van alle belangrijke spelers in deze sector is dus geen sinecure en reeds enkele jaren is dit een onderwerp waar veel onderzoek op gebeurt. Het elektronisch patiëntendossier mag dan wel al in vele vormen bestaan, op nationaal of internationaal vlak moet nog veel gebeuren doordat deze veelal onderling incompatibel zijn. In verschillende landen werden en worden nog steeds studies uitgevoerd om de verschillende aspecten van deze consolidatie te concretiseren. De enorme reikwijdte zou zonder extensieve studies snel aanleiding geven tot synchronisatie- en beveiligingsproblemen, vandaar dat dit concept na enkele jaren nog steeds in zijn kinderschoenen staat. 1.2 Doelstelling In deze thesis is het concrete doel: Opstellen van een business model voor de robuuste netwerkopslag van medische gegevens. Om dit te verwezenlijken kunnen we dit opsplitsen in volgende te realiseren deelvragen: Wat is de totale grootte van de data die dient opgeslagen te worden (per locatie), rekening houdend met back-up? Welke gevolgen hebben verschillende types medische data met betrekking op het netwerk, en hoe moet het netwerk gemodelleerd worden inzake topologie en bandbreedte? Wat is de toekomstvisie? Wat is de uiteindelijke kostprijs van dit alles? 2

15 HOOFDSTUK 1. INLEIDING 1.3 Methodologie In het huidig hoofdstuk, hoofdstuk 1, wordt de probleemstelling en de doelstelling van deze scriptie vermeld. Eveneens vind u hier een korte beschrijving van de indeling van dit boek. In hoofdstuk 2 worden de problemen van het Internet en reeds onderzochte oplossingen aangehaald. Als laatste sectie van dit hoofdstuk, sectie 2.3, gaan we dieper in op een van de nieuwere oplossingen, namelijk Content Distribution Networks (CDNs). De mogelijke sectoren en bijhorende diensten die voordeel kunnen hebben bij de implementatie van zo n CDN zijn terug te vinden in hoofstuk 3. Hierin worden eveneens verschillende beveiligingsfuncties aangehaald en worden 2 geselecteerde diensten in detail besproken. In hoofdstukken 4 en 5 bespreken we de eigenlijke kern van deze thesis, namelijk de robuuste netwerkopslag van medische gegevens. Het eerste heeft als bedoeling de business case te bespreken. In hoofdstuk 5 gaan we over naar het business model. Hoofdstuk 4 begint met een beschrijving van de gangbare termen en concepten inzake medische opslag. Er wordt eveneens een sectie besteedt om de verschillende aspecten van privacy en security te bespreken die nodig zijn hiervoor. Om een toekomstvisie op te stellen wordt in sectie 4.3 dieper ingegaan op de verschillende soorten gegevens die opgeslagen dienen te worden. In deze sectie bekomen we uiteindelijk een schatting van de totale jaarlijks benodigde opslag per persoon. Om deze schatting te controleren werd contact gelegd met de dienst radiologie van het UZ Gent. Verschillende statistieken en andere gegevens komende uit deze afspraken worden vermeld in sectie 4.4. Hoofdstuk 5 gaat zoals vermeld over het business model. Nadat we in hoofdstuk 4 de totale opslagbenodigdheid per persoon per jaar berekend hebben wordt voor het UZ Gent onder andere de totale opslagbenodigdheid voor het jaar 2006 berekend. Met deze gegevens wordt het project uitgebreid met 3 extra locaties: het Sint-Lucas Gent, het UZ Antwerpen en het UZ Leuven Gasthuisberg. In sectie 5.2 berekenen we voor alle locaties de totale opslaghoeveelheid, en houden we eveneens rekening met back-up. Dit voor een periode van 5 jaar, namelijk 2007 tot Het netwerk wordt gemodelleerd, wat inhoudt dat de netwerktopologie en de bandbreedte van de links wordt vastgelegd. Hierbij houden we rekening met de eisen voor het normale verkeer overdag, het back-up verkeer s nachts en Quality of Service. Als laatste punt in deze sectie wordt de nodige opslaginfrastructuur bepaalt. Het laatste deel van dit hoofdstuk wordt gewijd aan de economische studie van het project. Er wordt algemeen besproken wat de mogelijke besparingen zijn door de digitale opslag van medische gegevens, en we berekenen wat de kostprijs van het project is. Bij 3

16 HOOFDSTUK 1. INLEIDING dit laatste wordt niet alleen rekening gehouden met de aankoop van materiaal, maar ook met kosten voor installatie, onderhoud, elektriciteit, vervanging van de harde schijven en beveiliging. Eveneens worden de netwerkkosten in rekening gebracht. Hoofdstuk 6 tenslotte vat de belangrijkste resultaten en conclusies van dit werk nog eens samen in een apart hoofdstuk. 1.4 Verloop van het werk Het verloop van deze thesis in grote lijnen gedurende het jaar was als volgt: 1. Literatuurstudie: Economische literatuur Content Distribution Network (CDN) Content Adressable Storage (CAS) Storage Area Network (SAN) en Network-Attached Storage (NAS) Sectoren en bijhorende diensten gebaat bij een CDN Beveiliging Medisch patiëntendossier en dergelijke (PHR, EHR, PACS) 2. Modellering van de toekomstvisie voor de totale opslag 3. Modellering van de toekomstvisie voor het netwerk 4. Realisatie van de infrastructuur die voldeed aan de gestelde eisen 5. Kostenberekening van infrastructuur en andere uitgaven 6. Thesisboek samenstellen De bekomen informatie uit stap 1 werd doorheen het boek gebruikt. De modellering voor de totale opslag gebeurt in hoofdstukken 4 en 5. De toekomstvisie voor het netwerk komt aan bod in hoofdstuk 5. Puntjes 4 en 5 zijn eveneens in dit hoofdstuk ondergebracht. Om de kostenberekening te implementeren heb ik gebruik gemaakt van Excel 2002, deze bestanden zijn terug te vinden op de CD-ROM. Het resultaat van stap 6 bent u nu aan het lezen. 4

17 HOOFDSTUK 1. INLEIDING Deze thesistekst werd geschreven in L A TEX, verwerkt met het programma TeXnicCenter [1] van ToolsCenter als editor, en het package MiKTeX [2] werd gebruikt voor de omzetting naar PDF. 1.5 Inhoud van de CD-ROM Het eerste deel van deze thesis bestond zoals gezegd uit een literatuurstudie. Indien de documenten beschikbaar waren voor download, dan zijn deze te vinden op de CD-ROM. Verder zijn ook alle Excel-bestanden te vinden die gebruikt werden om de toekomstvisie uit te werken, evenals de kostenberekening. Ook alle L A TEX-bestanden, figuren en dergelijke om dit thesisboek te schrijven zijn te vinden op de CD-ROM. Voor meer informatie hierover verwijs ik door naar bijlage A. 5

18 Hoofdstuk 2 Content Distribution Networks Content Distribution Networks (CDN) werden als oplossing voorgedragen voor de vele problemen waarmee het huidige internet kampt. De toepassingen waarvoor het internet oorspronkelijk ontwikkeld werd, zijn niet langer meer de enige die de eindgebruiker nuttigt. In de moderne wereld willen we niet langer slechts gebruik maken van het Internet voor e- mail en statische webpagina-toepassingen. Men wil interactieve sites bezoeken, met geluid en/of zelfs met video, zijn eigen weblog maken, lid worden van groepen waar men zijn foto s kan delen, trailers van langverwachte films bekijken, de stand van de verkiezingen live volgen via het Internet, artikels opzoeken in de archieven van krantenpublicaties, reizen boeken zonder daarvoor naar een reisbureau te moeten gaan, spullen ruilen, kopen of verkopen, online games spelen, videoconferenties houden met een bedrijfspartner in Korea, enzovoort. Maar bovendien willen we dat deze toepassingen snel genoeg werken. De tijd waarin we allen met een modem op het internet surften, en men het gewoon was te wachten tot een webpagina geladen was is definitief voorbij. De aansluiting van de particuliere huizen op het breedbandnetwerk bracht een storm van nieuwe toepassingen op gang. Men hoefde niet langer te wachten op het laden van een webpagina, en dus wou de bevolking telkens meer. Het Internet in zijn oorspronkelijke vorm was hier niet aan aangepast, en hierdoor duiken verschillende problemen op, die beschreven worden in de volgende sectie. Talrijke oplossingen werden bedacht en onderzocht, de een al succesvoller dan de ander, een bespreking van de voornaamste volgt in sectie 2.2. Als laatste onderdeel in dit hoofdstuk, sectie 2.3 bespreken we ten slotte een van deze mogelijke oplossingen die vooral een oplossing kan/zal bieden in de fixed content wereld, namelijk CDN s. 6

19 HOOFDSTUK 2. CONTENT DISTRIBUTION NETWORKS 2.1 Inleiding Zoals reeds vermeld was het oorspronkelijke Internet voornamelijk bedoeld voor statische websites en toepassingen. Wat begon als een netwerk van 4 nodes in 1969, het zogenaamde ARPAnet, is ondertussen uitgegroeid tot een wereldwijd netwerk van hosts [3]. De groeitrend in de loop der jaren is te zien in figuur 2.1. Deze exponentiële evolutie was niet verwacht, maar dankzij het schaalbare concept waarop het internet gebaseerd is kon deze groei wel ondersteund worden. De zogenaamde killer toepassingen waarmee het internet in de loop van haar bestaan te maken heeft gehad, mogen zeker gezien worden als belangrijke groei-impulsen. Deze killer toepassingen zijn [4]: het web direct messaging peer-to-peer filesharing Figuur 2.1: De stijging in het aantal hosts sinds

20 HOOFDSTUK 2. CONTENT DISTRIBUTION NETWORKS Hierbij vermelden we dat de eerste 2 toepassingen afkomstig waren uit de wetenschappelijke wereld en feitelijk de hoofdtoepassingen waren waarvoor het Internet ontwikkeld werd. De laatste 2 echter werden door de private wereld ontwikkeld, door enkele jonge entrepeneurs. De exponentiële groei van het Internet heeft niet enkel betrekking op het aantal aangesloten apparaten, maar eveneens op de groei in datatraffiek. Oorspronkelijk waren de verzonden bestanden relatief klein omdat het ging over statische websites of s. Later werden s met bijlagen verzonden, werden websites kleurrijker en bevatten ze meer foto s. Snel stelde iedereen stteds grotere eisen, om zowel meer als grotere bestanden te verzenden of te downloaden. Om aan deze evolutie te voldoen was het enkel nodig om op de rand van het netwerk snellere servers te installeren. In het centrum van het netwerk moesten snellere routers en dikkere datakabels geïnstalleerd worden. Maar met de komst van streaming video en radio, online games, internettelefonie, videoconferencing en dergelijke real-time toepassingen is het belangrijk om de pakketjes eveneens op tijd aan de andere kant van het netwerk te krijgen Werking van het Internet Het Internet is een zogenaamd packet switched network, waarbij de verschillende informatiedelen opgesplitst worden in kleinere pakketjes en daarna verzonden worden. Dit is net de reden waarom het Internet zo schaalbaar is gebleken. Wanneer persoon A, in domein a, iets wil verzenden naar persoon B, in domein b, dan zal A een aantal pakketjes verzenden naar de receptie van zijn domein. Voor de rest hoeft A zich feitelijk van niet veel meer aan te trekken. De receptie van a op zijn beurt zal alles verzenden naar de volgende op de weg richting B. Uiteindelijk komen de pakketjes aan in het domein b, waarna de receptie van dat domein de aangekomen pakketjes levert aan B. Elke schakel in de ketting verzendt het binnengekomen pakket naar de volgende schakel die dichter bij het eindpunt ligt. [4] Client server model Het cliënt server model van het Internet bestaat uit: een cliënt een server een communicatieprotocol 8