Retransmissieprotocols met geheugen

Transcriptie

1 Faculteit Toegepaste Wetenschappen Vakgroep Telecommunicatie en Informatieverwerking Voorzitter: prof. dr. ir. H. Bruneel Retransmissieprotocols met geheugen door Danny Boelens Promotor en thesisbegeleider : prof. dr. ir. M. Moeneclaey Afstudeerwerk ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar

2 Dankwoord Graag zou ik deze gelegenheid willen aannemen om iedereen die heeft bijgedragen hetzij rechtstreeks, hetzij onrechtstreeks tot de verwezenlijking van dit eindwerk van harte te bedanken, en in het bijzonder dank ik hierbij: mijn promotor (en tevens thesisbegeleider), prof. dr. ir. M. Moeneclaey, voor het scheppen van de mogelijkheid dit onderzoek te verrichten, voor z n interesse in het verrichtte werk en voor het steeds aanwezig zijn als ik hulp of advies nodig had; mijn ouders en onmiddellijke omgeving, voor hun onvoorwaardelijke morele steun tijdens deze periode; alle medewerkers van de vakgroep Telin, omdat ze steeds bereid waren om hulp te verschaffen; mijn medestudenten Tom De Muer, Tom Kimpe en Pieter Thysebaert, respectievelijk voor het geven van nuttige opmerkingen in verband met een aantal stukken C++ broncode, voor het nalezen van de proefversie van deze scriptie en het opsporen van de tik-en taalfouten, en voor een paar nuttige L A TEX-tips. i

3 Toelating tot bruikleen De auteur geeft de toelating dit afstudeerwerk voor consultatie beschikbaar te stellen en delen van het afstudeerwerk te copië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 dit afstudeerwerk. Danny Boelens 30 augustus 2001 ii

4 Retransmissieprotocols met geheugen door Danny Boelens Afstudeerwerk ingediend tot het behalen van de graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar Universiteit Gent Faculteit Toegepaste Wetenschappen Promotor: prof. dr. ir. M. Moeneclaey Samenvatting Bij een klassiek retransmissieprotocol wordt een frame waarin één of meerdere fouten worden gevonden genegeerd, met een retransmissie tot gevolg. Dat is zonde, want niet alle informatie in een foutief ontvangen frame is waardeloos en retransmissies doen de efficiëntie van het protocol dalen. Daartoe werd de mogelijkheid beschouwd om een vorm van geheugen toe te voegen aan een retransmissieprotocol. De werkwijze van dit geheugen werd uitvoerig besproken, net als een aantal gevolgen die dit geheugen teweegbrengt. Er werd ook simulatiesoftware ontwikkeld waarmee het gebruik van dit geheugen in een retransmissieprotocol kan gesimuleerd worden. Tevens kan de simulatiesoftware het geval simuleren waarin geen geheugen wordt gebruikt. Op die manier kon men de resultaten onderling vergelijken met het oog op het bepalen van de winst die men kan halen door het toevoegen van geheugen. Met behulp van de resultaten van de simulaties kon men verder de efficiëntie berekenen van een aantal retransmissieprotocols en zo de mogelijkheden en de grenzen van het toevoegen van geheugen gaan onderzoeken. Trefwoorden: Retransmissieprotocol, ARQ protocol, geheugen, datacommunicatie. iii

5 Inhoudsopgave 1 Inleiding 1 2 Retransmissieprotocols met geheugen Lineaire blokcodes Bewerkingen met bits Definities en eigenschappen Transmissiefouten Retransmissieprotocols Introductie Enkele onderstellingen Statistiek van het aantal retransmissies Efficiëntie van retransmissieprotocols Een aantal begrippen en notaties Wat bedoelen we met efficiëntie? Het stop-and-wait schema Het go-back-n schema Het selective-repeat schema Geheugen : redder in nood? Motivering De werkwijze Gevolgen Een vereenvoudiging in de simulatieprocedure De simulator Motivering en doel van de simulator De opbouw van de simulator GDataType : algemeen bruikbare datatypes Stringutils : handig werken met strings Configuration : het instellen van parameters Random : genereren van toeval BitString : bitsequenties op hun best SimEngine : de werkmier iv

6 4 Simulatieresultaten Een uitgewerkt voorbeeld van een simulatie Verdere resultaten Besluit 44 6 Suggesties voor uitbreidingen en verder onderzoek 45 A Inhoud van de CD-ROM 47 B StARQ v Bibliografie 55 v

7 Lijst van figuren 2.1 De definitie van de optelling en de vermenigvuldiging van bits Het encodeerproces voor een lineaire blokcode Het binair symmetrisch kanaal Theoretische kans op een foutief frame (30 bits per frame) Het stop-and-wait protocol Het go-back-n protocol (N=5) Het selective-repeat protocol Het combineren van foutief ontvangen codewoorden Een voorbeeld van een configuratie (conceptueel) Het aantal verzonden frames in functie van de bitfoutprobabiliteit Het aantal verzonden frames in functie van de bitfoutprobabiliteit - detail De efficiëntie van een stop-and-wait schema in functie van de bitprobabiliteit 42 B.1 StARQ v0.0 - configuratiescherm B.2 StARQ v0.0 - een ingevuld configuratiescherm B.3 StARQ v0.0 - er ging blijkbaar iets mis B.4 StARQ v0.0 - simulatorscherm B.5 StARQ v0.0 - simulaties gaan niet altijd goed B.6 StARQ v0.0 - bezig met simuleren B.7 StARQ v0.0 - de simulatie werd succesvol beëindigd B.8 StARQ v0.0 - extra functionaliteit in het uitvoerscherm vi

8 Hoofdstuk 1 Inleiding Digitale communicatie is niet meer weg te denken uit onze huidige maatschappij. Iedere seconde wordt wereldwijd een bijna onmenselijke hoeveelheid digitale informatie verstuurd. Om u maar één voorbeeld te geven : zo schatte men bijvoorbeeld de traffiek op de internet backbones in de USA gedurende december 2000 op liefst tot terabyte [1]! Uitgaande van het gemiddelde van bovenstaande waarden, komt dat overeen met bijna 11 gigabyte aan data, per seconde... Helaas is perfectie niet van deze wereld en dus zullen er bij het versturen van digitale gegevens transmissiefouten optreden als gevolg van ruis op het transmissiekanaal. Bij het ontwerp van een (digitaal) communicatiesysteem moet men dus terdege rekening houden met deze mogelijkheid, hetgeen de complexiteit van het communicatiesysteem uiteraard verhoogt. Om deze fouten zo goed en zo kwaad als het kan op te vangen, worden in de praktijk vaak de zogenaamde ARQ protocols (Automatic Repeat Request protocols) of retransmissieprotocols gebruikt 1. Indien een ontvanger vaststelt dat een blok van gegevens (al dan niet gecodeerd) verkeerd werd ontvangen, dan zal deze ontvanger de zender verzoeken het bewuste blok opnieuw te versturen. Men onderscheidt een aantal verschillende retransmissieprotocols, al naargelang de manier waarop men het zenden en het heruitzenden organiseert. In het meest eenvoudige geval zal de ontvanger een foutief ontvangen blok negeren, en de zender net zo lang vragen om het bewuste blok opnieuw door te sturen totdat hij geen fout meer ontdekt in het ontvangen blok 2. Het is duidelijk dat dit een zeer tijdrovende en bandbreedte verspillende zaak kan zijn als er heel vaak fouten optreden. Gelukkig is het meestal zo dat wanneer een blok van gegevens, als gevolg van een transmissiefout, door de ontvanger als waardeloos wordt bestempeld, het blok niet compleet waardeloos is. Dit laat ons toe om geheugen te introduceren in retransmissieprotocols. Dit komt er eigenlijk op neer dat een foutief ontvangen blok niet wordt genegeerd, maar eventueel slechts voor een zekere tijd wordt bijgehouden door de ontvanger. Op die manier hoopt men toch nuttige informatie te halen uit foutief ontvangen blokken van gegevens. Het is duidelijk dat dit het transmissiesysteem complexer maakt. In dit afstudeerwerk zal voornamelijk aandacht worden besteed aan het waarom van geheugen in een retransmissieprotocol en de manier waarop dit geheugen in retransmissieprotocols kan worden aangebracht, vanzelfsprekend vergezeld van een aantal gevolgen. 1 in deze tekst zullen we echter consequent de laatste benaming, retransmissieprotocols, gebruiken 2 dit betekent niet noodzakelijk dat het ontvangen blok daarom geen fouten bevat, zie verder 1

9 Een belangrijk aspect van dit afstudeerwerk bestaat tevens uit de ontwikkeling van een simulator, in software, die toelaat om van een aantal retransmissieprotocols met geheugen de efficiëntie 3 te simuleren. Een belangrijke reden hiervoor is dat het niet altijd eenvoudig is om analytische oplossingen te formuleren die de efficiëntie van zo n retransmissieprotocol beschrijven, zodat men genoodzaakt is zijn toevlucht te zoeken tot het experimenteel verwerven van deze informatie of het ontwikkelen van een simulator. In hoofdstuk 2 wordt ingegaan op het waarom van geheugen in een retransmissieprotocol. Na de invoering van een aantal begrippen, definities en onderstellingen volgt een korte schets van wat retransmissieprotocols inhouden. Vervolgens bespreken we de impact van transmissiefouten op de efficiëntie van een retransmissieprotocol en hoe de invoering van geheugen kan helpen om de efficiëntie te verbeteren. Ook een aantal gevolgen van het gebruik van geheugen in retransmissieprotocols komen aan bod. In hoofdstuk 3 snijden we de ontwikkeling van de simulator aan en alles wat daarmee gepaard gaat. We bespreken het wat en waarom van een simulator en beschrijven in detail de opbouw en werking van onze simulator. In hoofdstuk 4 stellen we vervolgens een aantal resultaten voor die met de simulator werden bereikt. Tenslotte, na een aantal besluiten te geven in hoofdstuk 5 en een aantal uitbreidingen voor te stellen in hoofdstuk 6, ronden we het geheel helemaal af met nog twee bijlages. In de eerste (bijlage A) worden een aantal woorden over de bijgevoegde CD-ROM gezegd. Deze CD-ROM bevat onder meer de complete broncode van de simulator. Bijlage B fungeert als (korte) handleiding bij een grafische gebruikersinterface die rond de simulator is geschreven. Deze staat eveneens op de bijgevoegde CD-ROM. 3 wat precies met efficiëntie van een retransmissieprotocol bedoeld wordt, wordt later uiteengezet 2

10 Hoofdstuk 2 Retransmissieprotocols met geheugen 2.1 Lineaire blokcodes Blokcodes zijn niet altijd lineair, maar over het algemeen zijn de in de praktijk gebruikte blokcodes dat wel. We beperken ons hier dan ook tot lineaire blokcodes Bewerkingen met bits Het werken met blokcodes (en in het bijzonder lineaire blokcodes) vereist de invoering van een aantal bewerkingen op bits. De bewerkingen die van belang zijn voor het vervolg, zijn de optelling en de vermenigvuldiging van bits. Deze zijn gedefinieerd in Figuur 2.1. De bewerkingen komen neer op een modulo-2 optelling en vermenigvuldiging van de natuurlijke getallen 0 en 1. Men kan nagaan dat deze rekenregels de associatieve en commutatieve eigenschap hebben ten opzicht van de optelling en de vermenigvuldiging en de distributieve eigenschap (a + b)c = ac + ab, net zoals de bewerkingen met getallen. Merk wel op dat de optelling geen carry veroorzaakt! Figuur 2.1: De definitie van de optelling en de vermenigvuldiging van bits Het komt ook vaak voor dat twee of meer bitsequenties moeten opgeteld worden. We definiëren de optelling van twee bitsequenties met dezelfde lengte n : het resultaat van deze optelling is de bitsequentie met lengte n waarvan het i-de bit gegeven wordt door de optelling van het i-de bit van term 1 en het i-de bit van term 2 ( bit per bit optellen ). 3

11 Figuur 2.2: Het encodeerproces voor een lineaire blokcode met aanduiding van informatiebits en pariteitsbits Definities en eigenschappen Een lineaire (n,k)-blokcode 1 (soms ook wel pariteitscode genaamd) transformeert informatiewoorden b (i) van k bits (de informatiebits) in codewoorden c (i) van n bits. Is de pariteitscode systematisch dan gebeurt dit zodanig dat de eerste k bits van c (i) gelijk zijn aan de k bits van b (i). De overige n-k bits (de pariteitsbits) van c (i) zijn lineaire combinaties van de k informatiebits. Hierbij stellen b (i) en c (i) repectievelijk het i-de informatiewoord en het corresponderende i-de codewoord voor, i = 1, 2,..., 2 k. Merk op dat er in principe 2 n mogelijkheden zijn met n bits, maar dat slechts 2 k ervan effectief een codewoord zijn. Wanneer we b en c voorstellen met behulp van rijvectoren, dan kunnen we deze schrijven als b = (b 1, b 2,..., b k ) c = (c 1, c 2,..., c k 1, c k, c k+1,..., c n ) en hiervan gebruik makend kunnen we voor de lineaire blokcode dus schrijven : c k+m = c m = b m (m = 1, 2,..., k) k p l,m b l (m = 1, 2,..., n k) l=1 In bovenstaande vergelijking neemt p l,m de (binaire) waarde 0 of 1 aan, afhankelijk van het feit of informatiebit b l een invloed uitoefent op pariteitsbit c k+m (waarde 1) of niet (waarde 0). De bewerkingen in bovenstaande vergelijking zijn bewerkingen op bits. In Figuuur 2.2 is het encodeerproces voor een lineaire blokcode schematisch weergegeven, met aanduiding van informatiebits (I) en pariteitsbits (P). Voor de eenvoud vermelden we nog een aantal definities en eigenschappen die we later nog zullen gebruiken. We beginnen met een paar definities : Het gewicht w(x) van een bitsequentie x wordt gedefinieerd als het aantal posities in x waar een 1-bit optreedt. De Hamming-afstand d(x,y) tussen 2 bitsequenties x en y van gelijke lengte is het aantal posities waarin x en y van elkaar verschillen. 1 hierbij is n > k ondersteld 4

12 De minimale Hamming-afstand d van een code is de kleinste Hamming-afstand d(c (i),c (j) ) tussen 2 codewoorden c (i) en c (j) (i j): d = min d( c (i), c (j) ) i,j=1,2,...,2 k i j En we gaan verder met een paar eigenschappen (zonder bewijs) waarnaar we later nog zullen verwijzen: 1. Het codewoord c (0) bestaande uit allemaal 0-bits is een geldig codewoord voor om het even welke lineaire blokcode Voor een willekeurige bitsequentie x geldt dat x + 0 = x. 3. Voor een willekeurige bitsequentie x geldt dat x + x = Wanneer c (i) en c (j) twee codewoorden zijn die corresponderen met de informatiewoorden b (i) en b (j) (i,j = 1, 2,..., 2 k ), dan is ook de som van beide, c (i) + c (j), een geldig codewoord, namelijk het codewoord dat correspondeert met het informatiewoord b (i) + b (j) Het gewicht w(x) is ook gelijk aan de Hamming-afstand d(x,0) met 0 de nulsequentie; die is een bitsequentie die op elke plaats een 0-bit staan heeft. 6. De Hamming-afstand tussen twee codewoorden c (i) en c (j) is gelijk aan het gewicht van het codewoord c (i) + c (j). 7. Wanneer een lineaire blokcode met minimale Hamming-afstand d gebruikt wordt, kan de ontvanger elk aantal bitfouten tot en met d-1 detecteren. 2.2 Transmissiefouten Het nut om (op het eerste zicht overbodige) bits toe te voegen aan een informatiewoord alvorens het te verzenden komt al snel tot uiting als we even de eigenschappen van een transmissiekanaal bekijken. Er zijn namelijk steeds een aantal factoren die ervoor zorgen dat het signaal dat aan de uitgang van het transmissiekanaal verschijnt verschilt van het signaal dat aan de ingang wordt aangelegd. Een van de belangrijkste is zeker de ruis, maar ook attenuatie, pulsverbreding en overspraak (verschillende transmissiekanalen die elkaar storen) kunnen roet in het eten gooien. Een mogelijk gevolg van deze factoren is dat het signaal dat aan de uitgang komt zo sterk kan verschillen van het signaal dat aan de ingang werd aangelegd, dat de ontvanger foutieve informatie ontvangt. Bij digitale informatieoverdracht betekent dit het omslaan van één of meerdere bits, en dus moet deze mogelijkheid in rekening worden gebracht, bijvoorbeeld door het toevoegen van redundante bits. 2 uiteraard kan het aantal bits in dit codewoord verschillen al naargelang de waarde van n 3 dit is natuurlijk de oorsprong van de benaming lineaire blokcode 5

13 Met behulp van die redundantie kan men, mits deze zorgvuldig te kiezen uiteraard, ervoor zorgen dat de meest voorkomende transmissiefouten op zijn minst kunnen gedetecteerd worden door de ontvanger. In het verdere vervolg van deze scriptie zullen we steeds aannemen dat een ontvanger enkel fouten kan detecteren, maar niet kan corrigeren, tenzij uitdrukkelijk anders vermeld. 2.3 Retransmissieprotocols We zullen nu even kort schetsen wat retransmissieprotocols in het algemeen inhouden. Merk op dat deze beschrijving niet tot doel heeft om volledig te zijn; voor een iets meer diepgaande beschrijving verwijzen we bijvoorbeeld naar [2]. Dit werk is tevens de basis waarop deze korte beschrijving is gebaseerd Introductie Wanneer digitale informatie ( een bericht ) wordt doorgestuurd, dan gebeurt dit zelden in z n geheel. Daarvoor is de omvang van het bericht doorgaans te groot. In plaats daarvan wordt het bericht opgedeeld in meerdere stukken, frames genaamd. Een nadeel hiervan is dat een foutief ontvangen frame doorgaans het volledige bericht zinloos maakt. De zender verstuurt een frame voor de eerste keer, en plaatst dit frame dan in een daartoe voorziene buffer, de retransmissiebuffer. Daar wordt het frame bewaardt voor een eventuele retransmissie. Wanneer de ontvanger het frame ontvangt, gaat deze na of er een transmissiefout is opgetreden 4. Indien geen transmissiefout werd ontdekt, wordt de informatie ter beschikking gesteld van de bestemmeling (of tijdelijk in een ontvangerbuffer bijgehouden, want frames moeten aan de bestemmeling worden afgeleverd in de volgorde waarin ze bij de zender aankwamen) en wordt een positief ontvangstbericht (positive acknowledgement (ACK)) naar de zender gestuurd; na ontvangst van deze ACK zal de zender dit frame uit het retransmissiebuffer verwijderen. Wordt door de ontvanger echter wel een transmissiefout in het frame vastgesteld, dan wordt een negatief ontvangstbericht (negative acknowledgement (NAK)) naar de zender gestuurd; na ontvangst hiervan zal de zender het bewuste frame opnieuw versturen. Het frame blijft nog altijd in de retransmissiebuffer. Aan elk ontvangstbericht is het rangnummer van het frame gekoppeld waarop het bericht slaat, dit omdat de zender zou weten over welk frame het gaaat. Aan elk frame wordt tevens een rangnummer toegekend 5 ; dit maakt het voor de ontvanger mogelijk om ontvangen frames in de juiste volgorde te plaatsen, in de juiste volgorde aan de bestemmeling af te leveren en om te controleren of er geen frames verloren zijn gegaan. Het rangnummer wordt uiteraard toegekend door de zender Enkele onderstellingen We vermeldden al het feit dat met behulp van de pariteitsbits de ontvanger een fout kan detecteren. Maar dit betekent niet dat wanneer de ontvanger in een frame geen fout ontdekt, dat dit frame noodzakelijk foutloos is verzonden. Men zegt dat in zo n geval een niet detecteerbare fout kan optreden. Dit treedt bijvoorbeeld op in het geval wanneer er slechts 1 pariteitsbit wordt gebruikt (bijvoorbeeld even pariteit) en er 2 informatiebits 4 we onderstellen hier dat de ontvanger enkel transmissiefouten kan detecteren, maar niet kan corrigeren 5 verschillende kopieën van eenzelfde frame krijgen hierbij hetzelfde rangnummer 6

14 Figuur 2.3: Het binair symmetrisch kanaal omklappen. Wanneer de ontvanger met behulp van de ontvangen informatiebits de pariteit controleert, zal deze vaststellen dat de berekende pariteitsbit overeenkomt met de ontvangen pariteitsbit, en dus verkeerdelijk denken dat het codewoord correct ontvangen werd. Bij het ontwerp van de simulator verder in deze scriptie zullen we uitgaan van de onderstelling dat deze niet kunnen optreden. Met andere woorden : de ontvanger kan een willekeurig aantal bitfouten detecteren. Dit is niet realistisch, omdat het steeds mogelijk is dat een codewoord door bitfouten in een ander codewoord getransformeerd wordt, ongeacht de gebruikte lineaire blokcode. Als de kans op een niet gedetecteerde fout 6 echter verwaarloosbaar klein is, dan zal dit een voldoend nauwkeurige benadering van de realiteit zijn. Bovendien zorgt deze onderstelling ervoor dat we, zoals we later zullen aantonen, geen specifieke details nodig zullen hebben omtrent de geldige codewoorden van de gebruikte lineaire code. Dit zal de simulator gevoelig vereenvoudigen. In deze scriptie bedoelen we dan met een correct ontvangen frame elk frame waarin de ontvanger geen transmissiefouten detecteert. Verder zullen we onderstellen dat alle bits van een informatiewoord statistisch onafhankelijk zijn en met waarschijnlijkheid 1/2 de waarde 0 of 1 aannemen. Als gevolg hiervan heeft elk codewoord van de gebruikte code dezelfde kans om verzonden te worden. Ook het gebruikte kanaalmodel heeft zijn invloed op transmissiefouten. Er zal, tenzij uitdrukkelijk anders vermeld, steeds gebruik worden gemaakt van een binair symmetrisch kanaal. Dit kanaal wordt gekenmerkt door één parameter, de foutprobabiliteit van het binair symmetrisch kanaal, en wordt hier voorgesteld door p. Dit is aangeduid in figuur 2.3. Verder nemen we aan dat bitfouten op het kanaal statistisch onafhankelijk zijn, zodat het detecteren van een fout in een frame statistisch onafhankelijk is van het detecteren van een fout in een ander frame. Een laatste onderstelling die werd gemaakt heeft te maken met de ontvangstberichten. In realiteit is het ook mogelijk dat een ontvangstbericht verkeerd of zelfs helemaal niet aankomt. We maken de onderstelling dat een ontvangstbericht steeds aankomt en correct wordt ontvangen door de zender. Aangezien een ontvangsbericht veel korter is dan een frame, zal de kans op een transmissiefout in een ontvangstbericht dus vaak verwaarloosbaar klein zijn ten opzichte van de kans op een transmissiefout in een frame. Dit maakt de onderstelling realistisch. 6 zie verder 7

15 2.3.3 Statistiek van het aantal retransmissies We beginnen met het invoeren van een paar notaties: #tr : een toevalsgrootheid die aanduidt hoeveel keer een frame moet verstuurd worden vooraleer de ontvanger het als correct ontvangen beschouwt. #retr : een toevalsgrootheid die het aantal retransmissies voorstelt die nodig zijn om een frame als correct ontvangen te laten beschouwen door de ontvanger. p frame : de waarschijnlijkheid dat de ontvanger een ontvangen frames als foutief beschouwt. Dit is ook de waarschijnlijkheid dat de ontvanger een transmissiefout detecteert in een frame. We noemen dit ook de blokfoutprobabiliteit. Er geldt dat #tr = #retr +1. Gelet op de onderstellingen die gemaakt werden kunnen we stellen dat het aantal vereiste retransmissies van een frame dan gelijk is aan 1, wanneer de eerste transmissie foutief was en de tweede correct was. Het aantal vereist retransmissies zal gelijk zijn aan j als de eerste j transmissies foutief waren en de (j+1)ste transmissie juist is. Hieruit volgt voor de distributie van het aantal retransmissies: P r[#retr = j] = (1 p frame )p j frame j = 0, 1,... (2.1) Het gemiddeld aantal retransmissies kan hieruit berekend worden, en we krijgen: E[#retr] = ip rob[#retr = i] = i=0 i=0 i(1 p frame )p i frame = p frame 1 p frame (2.2) De berekening van p frame zelf kan gebeuren als volgt, waarbij n staat voor het aantal bits in een frame: p frame = 1 P rob[geen transmissiefout] P rob[niet gedetecteerde transmissiefout] = 1 (1 p) n P rob[niet gedetecteerde transmissiefout] Wanneer p 1, dan kan de laatste term worden verwaarloosd (zie bijvoorbeeld [2]). Merk op dat de verwaarlozing van deze term betekent dat de ontvanger elke transmissiefout kan detecteren, hetgeen één van de onderstellingen is. Er komt dan: p frame = 1 (1 p) n (2.3) Een typisch verloop van p frame in functie van p (met n vast) is te vinden in figuur 2.4. Ook het aantal frames dat effectief moet verstuurd worden (noem dit aantal s) vooraleer een opgegeven aantal frames (noem dit aantal f) correct verstuurd zijn kan men in theorie berekenen, tenminste in het geval de ontvanger geen gebruik maakt van enige vorm van geheugen. Het aantal frames dat verzonden zal worden is namelijk gegeven door het aantal dat we willen verzenden, f, vermenigvuldigd met het gemiddeld aantal transmissies per frame: s = f.e[#tr] Gelet op het feit dat #tr = #retr + 1, is dit aantal ook gegeven door 8

16 kans op een foutief frame bitfoutprobabiliteit p Figuur 2.4: Theoretische kans op een foutief frame (30 bits per frame) of nog, gelet op formule 2.2, s = f(1 + E[#retr]) (2.4) s = 2.4 Efficiëntie van retransmissieprotocols Een aantal begrippen en notaties f 1 p frame (2.5) Voorafgaand aan de bespreking van de efficiëntie van een retransmissieprotocol, is het nodig om een aantal begrippen te definiëren en een aantal notaties in te voeren : De round trip delay is de tijd die verloopt tussen het einde van de transmissie van een kopie van een frame en het moment waarop de zender verneemt of de ontvanger het blok correct ontvangen heeft. We noteren deze tijd als T d. De transmissiesnelheid of bitsnelheid stelt het aantal bits voor die per seconde kunnen verstuurd worden via het transmissiekanaal. We stellen deze voor door R b. In het vervolg van dit hoofdstuk zal verder gebruik gemaakt worden van n en k, hetgeen respectievelijk het total aantal bits in een frame voorstelt en het aantal informatiebits in een frame. 9

17 2.4.2 Wat bedoelen we met efficiëntie? We spraken al eerder over de efficiëntie van een retransmissieprotocol, maar gaven nog niet aan wat we daarmee precies bedoelen. De efficiëntie η van een retranmissieprotocol wordt gedefinieerd als (zie [2]) η = nuttige frameduur gemiddelde totale transmissietijd per correct ontvangen frame Met nuttige frameduur bedoelen we de duur van dat gedeelte van het frame dat de informatiebits bevat. Deze wordt dus gegeven door k/r b als k het aantal informatiebits is, en R b de bitsnelheid voorstelt. De rest van het frame bestaat uit overhead bits, waaronder bijvoorbeeld de pariteitsbits, de bits die het framenummer voorstellen, etc. De totale tijd transmissietijd is de som van de tijd die wordt ingenomen door alle verstuurde frames inclusief retransmissies en de tijd dat de zender geen frames verstuurt. We zullen nu een onderscheid maken tussen een aantal verschillende retransmissieprotocols. Op de hier besproken 3 basisschema s bestaan veel varianten, maar daar gaan we niet verder op in Het stop-and-wait schema Dit is veruit het eenvoudigste schema. De zender verstuurt een frame met rangnummer i en wacht dan op een antwoord van de ontvanger ACK of NAK betreffende frame i, vooraleer hij een nieuw frame verstuurt. Afhankelijk van het ontvangstbericht zal de zender het frame met rangnummer i opnieuw sturen (het ontvangstbericht was NAK) of zal hij een nieuw frame met rangnummer i+1 versturen (het ontvangstbericht was ACK). Deze klasse van retransmissieprotocols wordt gekenmerkt door een round trip delay (dode tijd) na het versturen van elk frame. Daarom wordt deze klasse ook wel aangeduid met de term idle request. Zender i T d i i+1 Ontvanger i NAK i ACK correct frame foutief frame Figuur 2.5: Het stop-and-wait protocol De werking van dit protocol is voorgesteld in figuur 2.5. Men toont aan dat de efficiëntie van dit protocol gegeven wordt door: η S&W = k/r b 1 n/r b + T d E[#tr] = k n 1 p frame 1 + s (2.7) 10

18 waarbij de parameter s gegeven is door s = T dr b (2.8) n Merk nog op dat k/r b en n/r b respectievelijk de nuttige duur en de totale duur van een frame voorstellen. Het is duidelijk dat algemeen de efficiëntie nadelig wordt beïnvloedt wanneer foutief ontvangen frames opnieuw verzonden moeten worden, omdat tijdens de retransmissie van een frame geen nieuw frame kan verzonden worden. In het geval van een stop-and-wait protocol is dit zo mogelijk nog erger : er gaat veel tijd verloren doordat de zender staat te wachten. Als gevolg van de dode tijd heeft dit schema dan ook een lage efficiëntie in vergelijking met de andere schema s Het go-back-n schema Bij dit protocol verstuurt de zender continue frames met opeenvolgende rangnummers, totdat een negatief ontvangstbericht (NAK) binnenkomt van een reeds eerder verstuurd frame. Op het moment dat de zender de NAK ontvangt, is deze bezig met het versturen van een frame, waarvan we het rangnummer i+n-1 (N > 1) noemen, terwijl we het rangnummer van het frame waarop de NAK betrekking heeft voorstellen door i. Nadat de zender het frame met rangnummer i+n-1 heeft verstuurd, zal deze onmiddellijk overgaan tot het opnieuw versturen (=retransmissie) van het frame met rangnummer i, waarna hij verdergaat met het verzenden van de frames met rangnummer i+1, i+2,... totdat hij weer een NAK binnenkrijgt. Merk dus op dat ook de frames met rangnummer i+1, i+2,..., i+n-1 een retransmissie ondergaan! De zender gaat als het ware N stappen terug in de tijd 7, omdat de ontvanger zo is opgebouwd dat deze bij het detecteren van een fout in een frame met rangnummer i alle frames met een hoger rangnummer zal negeren totdat hij een correcte kopie meent te hebben van dat frame. Men heeft dat N = 1 + ceil(s), met s gegeven door 2.8. Zender i N-1 i+1 i+2 i+3 i+4 i i+1 i+2 i+3 i+4 i+5 i+6 i+2 Ontvanger i NAK i+1 i+2 i+3 i+4 i i+1 ACK ACK i+2 NAK i+3 i+4 i+5 correct frame genegeerd frame foutief frame Figuur 2.6: Het go-back-n protocol (N=5) De werking van dit protocol is voorgesteld in figuur dit is uiteraard de oorzaak van de benaming go-back-n 11

19 Men toont verder aan dat de efficiëntie van dit protocol gegeven wordt door: η GBN = k/r b n/r b NE[#retr] = k n Het selective-repeat schema 1 p frame 1 + ceil(s).p frame (2.9) In dit geval verstuurt de zender onafgebroken frames. Ondertussen controleert hij de inkomende ontvangstberichten van de ontvanger. Een verwerkt ontvangstbericht met betrekking tot het frame met rangnummer i resulteert in het versturen van een nieuw frame (een frame dat dus voor de eerste keer wordt verstuurd) als het ontvangstbericht ACK was, of in een retransmissie van het frame met rangnummer i als het een NAK betrof. Enkel voor frames waarvoor de zender een NAK binnenkrijgt, zal een retransmissie plaatsvinden. Er gaat dus een minimum aan niet nuttig bestede tijd voorbij, waardoor dit protocol het meest efficiënte is. Zender i i+1 i+2 i+3 i+4 i+5 i+1 i+6 i+7 i+8 i+5 i+1 ACK NAK ACK ACK ACK NAK NAK ACK ACK Ontvanger i i+1 i+2 i+3 i+4 i+5 i+1 i+6 i+7 i+8 i+5 correct frame foutief frame Figuur 2.7: Het selective-repeat protocol De werking is getoond in figuur 2.7. Men toont aan dat de efficiëntie gegeven wordt door: η S R = k/r b n/r b 1 E[#tr] = k n (1 p frame) (2.10) Helaas is het protocol zoals het hier werd beschreven niet praktisch bruikbaar, omwille van het feit dat de ontvanger over een oneindig grote ontvangerbuffer moet beschikken om te garanderen dat geen enkel frame verloren gaat (herinner u dat frames aan de bestemmeling moeten afgeleverd worden in de volgorde waarin ze aan de zender worden aangeboden!). 2.5 Geheugen : redder in nood? Motivering Het toevoegen van een vorm van geheugen aan een retransmissieprotocol spruit voort uit de wens om meer nuttige informatie te halen uit foutief ontvangen data, in de hoop zo het (gemiddeld) aantal retransmissies te reduceren. Dit is bijzonder belangrijk, want het is net het gemiddeld aantal retransmissies wat de efficiëntie van een retransmissieprotocol 12

20 zo beïnvloedt zie hoger. In een gewoon retransmissieprotocol wordt ontvangen data weggegooid wanneer de ontvanger er een fout in detecteert. En in zekere zin is dit verspilzucht. Beschouw als voorbeeld een lineaire (6,3)-blokcode met minimale Hamming-afstand d = 3. De gebruikte code kan dus alle enkelvoudige en dubbele bitfouten detecteren (zie eigenschap 7). Wanneer nu bij de transmissie van een frame een dubbele bitfout optreedt, dan zal de ontvanger deze detecteren, en het foutief ontvangen frame negeren ( weggooien ). Het volledige codewoord, bestaande uit 6 bits, wordt dus genegeerd alhoewel er slechts 2 bits foutief waren. We gooien dus noodgedwongen ook bruikbare informatie weg. Daarom kan het nuttig zijn om een foutief ontvangen frame niet weg te gooien maar eventueel slechts tijdelijk nog even bij te houden in een geheugen. We hopen immers dat fouten op random wijze in de bits terechtkomen, zodat het weinig waarschijnlijk is dat bij (een) eventuele retransmissie(s) de bitfouten op dezelfde posities zullen optreden. Op deze manier kunnen we een aantal foutief ontvangen frames combineren om op die manier een meer betrouwbare beslissing te maken. Uiteraard in de hoop er een bruikbaar frame uit te halen. In de praktijk komt het helaas ook voor dat we een burst van bitfouten krijgen. Deze situatie blijft ook in het geval we geheugen gebruiken een probleem. Omdat een burst van bitfouten vereist dat de ruis niet random is, zullen we deze situatie niet verder beschouwen in deze scriptie De werkwijze Wat betreft het combineren en decoderen van de kopieën van een frame zullen we als volgt te werk gaan: We ontvangen de eerste kopie, en controleren of dit een codewoord is. Indien niet, dan moeten we wachten op een tweede kopie (retransmissie). We ontvangen de tweede kopie, en controleren of dit een codewoord is. Indien niet, dan wordt gekeken of de combinatie van de eerste en de tweede kopie een codewoord oplevert. Is dit ook niet het geval, dan moeten we wachten op de derde kopie.... We ontvangen de i-de kopie, en controleren of dit een codewoord is. Indien niet, dan wordt gekeken of de combinatie van de eerste tot en met de i-de kopie een codewoord oplevert. Is dit ook niet het geval, dan moeten we wachten op de (i+1)-de kopie. Voor het combineren zelf van n kopieën wordt als volgt te werk gegaan. Definieer de betrouwbaarheid van het k-de bit van een frame na ontvangst van de i-de kopie als rel(k, i) = N 1 (k, i) N 0 (k, i) waarbij N 0 (k, i) en N 1 (k, i) aangeven hoeveel maal de k-de bit in de i kopieën respectievelijk gelijk is aan 0 en aan 1. Vanzelfsprekend geldt i = N 0 (k, i) + N 1 (k, i). De combinatie van i kopieën levert dan een woord op waarvan het k-de bit gelijk is aan 1 als rel(k,i) > 0 en gelijk is aan 0 als rel(k,i) < 0. De waarde van rel(k,i) kan recursief worden berekend als 13

21 Figuur 2.8: Het combineren van foutief ontvangen codewoorden rel(k, i) = rel(k, i 1) + (r(k, i) = 1?1 1) waarbij r(k,i) staat voor de k-de bit van de i-de kopie. Verder is gebruik gemaakt van de conditionele uitdrukking a?b c 8, welke op axiomatische manier gedefinieerd kan worden als volgt (zie [8]): 0?b c = c en 1?b c = b. Als alternatief zou de notatie if(r(k,i)=1, 1, -1) gebruikt kunnen worden. Er kan echter een probleem optreden in het geval i even is. Voor sommige waarden van k kan rel(k,i)=0, zodat voor deze bits de waarde in het gecombineerde woord niet bepaald is. We zeggen dat het resultaat van het combineren onbeslist is. In dit geval kiezen we ervoor het onvolledige woord niet te decoderen, en dus te wachten op de volgende kopie. Een alternatieve aanpak zou zijn om na te gaan of er een codewoord bestaat dat, op de onbepaalde posities na, samenvalt met het gecombineerde woord. In figuur 2.8 is een voorbeeld te zien van hoe foutief ontvangen codewoorden worden gecombineerd. Ook is het probleemgeval dat hierboven werd beschreven getoond Gevolgen Ten eerste merken we op dat het gebruik van geheugen zich volledig afspeelt aan de zijde van de ontvanger. De zender hoeft geen wijziging te ondergaan. Uiteraard zorgt het toevoegen van geheugen aan de ontvanger ook weer voor extra complexiteit. Niet alleen het geheugen zelf moet in de ontvanger worden voorzien, maar ook de extra hardware om een aantal frames te kunnen combineren moet worden voorzien. Tevens zal de controlelogica die instaat voor het goed samenwerken van de onderdelen van de ontvanger (ontvangerbuffer, geheugen, versturen van ontvangstberichten, etc) ingewikkelder worden. Extra hardware betekent doorgaans ook een hoger energieverbruik, 8 vergelijk met de conditionele C/C++ expressie (a? b : c) 14

22 net als een extra kost. We krijgen de voordelen van het gebruik van geheugen dus zeker niet gratis. Deze hardware is verder, net als het geheugen overigens, bij voorkeur ook snel. In ieder geval moet het zo zijn dat de ontvanger na het ontvangen van een foutief frame in staat is om eventueel een vrij groot aantal frames te combineren en het resulterende frame (als dat al kan worden samengesteld, zie het probleemgeval hoger) te controleren op fouten binnen een tijd die slechts een fractie is van de round trip delay. In het andere geval zou het bij wijze van spreken eenvoudiger zijn om gewoon een NAK naar de zender te versturen, en te wachten op een retransmissie. Zo eenvoudig is het uiteraard niet, want ook de retransmissie kan foutief worden ontvangen, vooral wanneer p frame eerder groot is. Toch is een snelle verwerking essentieel, want hoe groter de verwerkingstijd van de ontvanger, hoe groter de round trip delay wordt, wat op zijn beurt een negatief effect kan uitoefenen op de efficiëntie van het protocol, in het bijzonder in het geval een stop-andwait schema wordt gebruikt (zie formule 2.7). Wanneer de round trip delay dus (heel) klein is, kan de extra verwerkingstijd ten gevolge van het aanwezig zijn van geheugen, een relatief grote fractie van de round trip delay vormen. Ook hier moet men aandacht aan schenken bij het ontwerp van de ontvanger. Een ander aspect waar wel degelijk rekening moet mee gehouden worden, is de organisatie en de bijhorende grootte van het geheugen. Hoeveel foutief ontvangen versies van één codewoord precies in het geheugen moeten kunnen om een optimum te vinden tussen de kost (en snelheid in mindere mate) van het geheugen en de winst die men ermee kan halen, laten we even buiten beschouwing. Dat hangt namelijk af van een groot aantal factoren, waaronder de kost van het geheugen en het aantal benodigde retransmissies om de frames correct te verzenden (wat op zijn beurt ook weer afhangt van een aantal factoren etc). Wat we niet buiten beschouwing laten, is het feit dat de complexiteit van een retransmissieprotocol een grote invloed heeft op de organisatie van het geheugen. Beschouw daarom terug de 3 basisschema s: Stop-and-wait Dit schema stelt het minste eisen. Slechts één enkel frame wordt verzonden. Eventueel volgen een aantal retransmissies voor dit frame. Pas wanneer het frame correct ontvangen is wordt de transmissie van een volgend frame ingezet. Dit vereist geen ontvangerbuffer voor de tijdelijk opslag van frames, omdat frames zich in de volgorde zullen bevinden waarin ze aan de bestemmeling moeten afgeleverd moeten afgeleverd worden. Wanneer we aan dit schema geheugen toevoegen, dan moet enkel geheugen voorzien worden voor foutief ontvangen versies van dit ene frame. Go-back-N Ook bij dit schema is geen ontvangerbuffer nodig om correct ontvangen frames tijdelijk in op te slaan. Er is namelijk geen herschikking van de ontvangen frames nodig. Ook hier volstaat het dus geheugen te voorzien om foutief ontvangen versies van één enkel frame op te slaan. 15

23 Selective-repeat Anders is het gesteld bij het selective-repeat schema. We vermeldden eerder al dat de ontvanger over een oneindig grote ontvangerbuffer moet beschikken om te garanderen dat geen enkel frame verloren gaat. Als gevolg hiervan moet men in principe ook een oneindig groot geheugen voorzien, want men moet immers in staat zijn foutief ontvangen versies van een oneindig aantal verschillende frames te stockeren. Men kan dus vaststellen dat de vereiste grootte van de ontvangerbuffer rechtstreeks de grootte van het benodigde geheugen beïnvloedt. Tenslotte kan men nog het totale geheugen conceptueel verdelen in een aantal even grote blokken, waarbij ieder blok dienst doet om foutief ontvangen versies op te slaan van één welbepaald frame, of men kan kiezen voor één blok geheugen en geheugen gaan innemen naargelang de noden, onafhankelijk van het frame dat foutief ontvangen is. Het hoeft geen betoog dat de laatste keuze het meest efficiënt omspringt met het aangeboden geheugen, maar ook de meest complexe is om te implementeren. 2.6 Een vereenvoudiging in de simulatieprocedure We vermelden hier nog twee stellingen, met bewijs, die het mogelijk zullen maken de simulatieprocedure 9 gevoelig te vereenvoudigen. Deze werden niet in de literatuur teruggevonden (waarmee ik niet wil zeggen dat deze nooit eerder beschreven kunnen zijn), vandaar de beslissing om deze inclusief bewijs te vermelden. Stelling 2.1 Neem aan dat c (i), c (j) en c (k) drie geldige codewoorden zijn van een lineaire blokcode. Dan geldt : c (i) c (j) c (i) + c (k) c (j) + c (k). Bewijs. Deel 1 : c (i) c (j) = c (i) + c (k) c (j) + c (k). Als c (i) c (j), dan betekent dit dat er minstens 1 positie is waarin de bitsequenties c (i) en c (j) van elkaar verschillen. Noem één van deze posities l (het maakt hierbij geen verschil uit of men nu de bits in een bitsequentie nummert van links naar rechts of omgekeerd, zolang men steeds dezelfde conventie gebruikt), zodat dus geldt dat c (i) l staan c (i) en c (j) l l c (j) l. Hierbij voor de l-de bit in de bitsequentie c (i) respectievelijk c (j). We bekijken verschil- nu de l-de bit in de sommen c (i) + c (k) en c (j) + c (k) 10. Aangezien c (k) l maar twee waarden kan aannemen (0 en 1 namelijk) en c (i) l lend moeten zijn, kunnen we vier gevallen onderscheiden. Geval 1 : c (k) l = 0, c (i) l = 0 en dus c (j) l = 1 en c (j) l Voor de l-de bit van c (i) + c (k) en c (j) + c (k) vinden we zo respectievelijk, gelet op de definitie van de optelling van bits, 0+0 = 0 en 1+0 = 1, zodat deze inderdaad verschillend zijn. Analoog kan men ook in de andere drie gevallen controleren dat de l-de bit van c (i) + c (k) en c (j) + c (k) verschillend zijn. Deze drie resterende gevallen zijn: 9 zie verder 10 merk op dat beide sommen terug een codewoord vormen, zie eigenschap 4 16

24 Geval 2 : c (k) l = 0, c (i) l = 1 en dus c (j) l = 0 Geval 3 : c (k) l = 1, c (i) l = 0 en dus c (j) l = 1 Geval 4 : c (k) l = 1, c (i) l = 1 en dus c (j) l = 0 Conclusie : c (i) l c (j) l = (c (i) + c (k) ) l (c (j) + c (k) ) l en bijgevolg geldt ook dat c (i) c (j) = c (i) + c (k) c (j) + c (k). Deel 2 : c (i) + c (k) c (j) + c (k) = c (i) c (j). Gebruik makend van deel 1 kunnen we schrijven : c (i) + c (k) c (j) + c (k) = c (i) + c (k) + c (k) c (j) + c (k) + c (k). Gelet op het feit dat c (k) + c (k) = 0 (eigenschap 3) herleidt het laatste deel zich tot c (i) c (j). Conclusie : c (i) + c (k) c (j) + c (k) = c (i) c (j). Deel 1 en Deel 2 samen bewijzen de stelling. Stelling 2.2 Beschouw een (n,k) lineaire blokcode, en een codewoord c (i) van deze lineaire blokcode. Beschouw nu de rij natuurlijke getallen A c (i),0, A c (i),1,..., A c (i),n waarin A c (i),j (j = 0, 1,..., n) het aantal verschillende codewoorden c (k) van de beschouwde lineaire blokcode voorstelt, waarvoor geldt dat de Hamming-afstand d(c (i), c (k) ) = j. Er geldt dat deze rij getallen voor elk codewoord van de beschouwde lineaire blokcode dezelfde is, zodat we de rij getallen beter kunnen noteren als A 0, A 1,..., A n. Bewijs. Het is duidelijk dat de rij natuurlijke getallen A c (i),0, A c (i),1,..., A c (i),n behorende bij het codewoord c (i) kan worden opgesteld uitgaande van de rij met de Hamming-afstanden tussen c (i) en alle codewoorden uit de gebruikte lineaire code. Beschouw nu de rij natuurlijke getallen die de Hamming-afstand tussen het codewoord c (i) en het codewoord c (l) (l=1,2,...,2 k ) weergeven. Noemen we voor de eenvoud van notatie d i,l de Hamming-afstand tussen het codewoord c (i) en het codewoord c (l), dan kunnen we deze rij noteren dit als volgt: d i,1, d i,2,..., d i,2 k Gelet op eigenschap 6 kan dit ook worden herschreven als w(c (i) + c (1) ), w(c (i) + c (2) ),..., w(c (i) + c (2k) ) Kies nu willekeurig een codewoord c (j) uit de lineaire code. Gelet op de eigenschappen 2 en 3, samen met de commutativiteit van de optelling van bitsequenties kunnen we dit nogmaals herschrijven tot w(c (j) + c (i) + c (j) + c (1) ), w(c (j) + c (i) + c (j) + c (2) ),..., w(c (j) + c (i) + c (j) + c (2k) ) We passen nu eigenschap 4 toe om te bekomen dat c (i) + c (j) eveneens een codewoord is; noem dit c (s). We krijgen: w(c (j) + c (s) + c (1) ), w(c (j) + c (s) + c (2) ),..., w(c (j) + c (s) + c (2k) ) 17

25 We benadrukken nogmaals dat c (1), c (2),..., c (2k) de 2 k verschillende geldige codewoorden vormen van de gebruikte lineaire blokcode. Aangezien c (1) en c (2) twee verschillende codewoorden zijn, geldt wegens eigenschap 4 en stelling 2.1 dat ook c (s) + c (1) en c (s) + c (2) twee verschillende codewoorden zijn. Op analoge manier zijn ook c (s) + c (2) en c (s) + c (3) verschillende codewoorden, net als c (s) + c (1) en c (s) + c (3), enzovoort. Met andere woorden : de 2 k codewoorden c (s) + c (i) (i=1,2,...,2 k ) zijn eveneens 2 k verschillende geldige codewoorden van de lineaire blokcode, en dus vormen ook zij een opsomming van alle geldige codewoorden. Wanneer we het codewoord c (s) + c (i) (i=1,2,...,2 k ) noteren als c (i ) dan kunnen we dus de rij noteren als of nog als w(c (j) + c (1 ) ), w(c (j) + c (2 ) ),..., w(c (j) + c (2k ) ) d j,1, d j,2,..., d j,2 k We merken op dat dit een rij natuurlijke getallen is die de Hamming-afstanden voorstelt tussen c (j) en alle codewoorden uit de gebruikte lineaire blokcode. Deze rij is dus dezelfde als de rij met Hamming-afstanden tussen tussen c (i) en alle codewoorden (eventueel in een andere volgorde) uit de gebruikte lineaire blokcode waarvan we vertrokken. We besluiten dat ook de rijen A c (i),0, A c (i),1,..., A c (i),n en A c (j),0, A c (j),1,..., A c (j),n dezelfde zijn. Aangezien i en j willekeurig zijn, is deze rij dezelfde voor elk geldig codewoord c (k) uit de lineaire blokcode, en dus kunnen we de rij beter noteren als A 0, A 1,..., A n. Vooral de laatste stelling is interessant. Deze zegt eigenlijk dat indien we een lineaire blokcode gebruiken we vanuit elk geldig codewoord de wolk met andere geldige codewoorden op dezelfde manier zien (met betrekking tot de afstand dan). Wanneer alle codewoorden even waarschijnlijk voorkomen (en dat is een gemaakte veronderstelling) dan laat dit ons toe om een simulatie te beperken tot het verzenden van slechts één willekeurig codewoord, zo vaak als nodig is. Uiteraard nemen we het codewoord bestaande uit 0-bits, omdat dit het ons bijzonder eenvoudig maakt om het aantal bitfouten te bepalen van het ontvangen woord (dit aantal is namelijk het gewicht van het ontvangen woord). Verder kunnen we nog opmerken dat indien de round trip delay T d en de bitsnelheid R b constant worden ondersteld tijdens de transmissie, we voldoende hebben aan E[#retr] om de efficiëntie te bepalen van het retransmissieprotocol (zie de formules 2.7, 2.9 en 2.10). We kunnen besluiten dat het volstaat om door simulatie een statistiek op te bouwen van het aantal retransmissies voor één welbepaald codewoord, namelijk het codewoord bestaande uit 0-bits, om de efficiëntie van een aantal retransmissieprotocols te bepalen, uiteraard enkele veronderstellingen aannemend. 18

26 Hoofdstuk 3 De simulator 3.1 Motivering en doel van de simulator Het ontwikkeling van een simulator komt tegemoet aan de noodzaak om relatief snel een indruk te krijgen van de werking en de prestaties van een systeem. In ons geval is dat systeem een retransmissieprotocol. Een belangrijke reden om tot het ontwikkelen van een simulator over te gaan is vaak dat het niet altijd eenvoudig is om analytische oplossingen te formuleren die de prestaties van het systeem beschrijven, zodat men genoodzaakt is zijn toevlucht te zoeken tot het experimenteel verwerven van deze informatie of het ontwikkelen van een simulator. Wanneer het systeem (eerder) complex is, is experimenteel onderzoek ook niet altijd haalbaar, omwille van de hoge kost die met ermee gepaard kan gaan. Tevens is het zo dat het experimenteel verwerven van data doorgaans beperkt is tot een specifiek systeem, waardoor men vaak meerdere systemen moet bouwen waarop men dan verschillende experimenten kan uitvoeren. Een simulator daarentegen kan misschien ontworpen worden voor een meer algemener systeem, waaruit dan ook gegevens gehaald kunnen worden voor een aantal specifieke varianten. De werking van het simulatieprogramma is bij voorkeur een weerspiegeling van de realiteit. Bijzondere aandacht moet worden besteed aan de keuze van een geschikte random generator om bepaalde stochastische processen te beschrijven, omdat deze in grote mate het realiteitsgehalte bepalen. De doelstelling van ons simulatieprogramma is de analyse van de efficiëntie van een aantal retransmissieprotocols. We wensen in eerste instantie na te gaan wat de waarde van het gemiddeld aantal retransmissies is. Hiermee kunnen we, zoals reeds eerder aangetoond, de efficiëntie bepalen. In tweede instantie verschaft de analyse van het aantal retransmissies ons informatie die kan bijdragen tot het bepalen van de gepaste dimensionering van het geheugen in een ontvanger, voor het geval we gebruik gaan maken van een retransmissieprotocol met geheugen. 3.2 De opbouw van de simulator In deze sectie zullen we beschrijven hoe de simulator (broncode) is opgebouwd. Om vanzelfsprekende redenen zal niet elke regel van de broncode haarfijn uitgelegd worden, maar zullen eerder de ideeën en motiveringen achter de opbouw ervan worden weergeven. 19

27 De volledige broncode, geschreven in C++, is wel beschikbaar op de bijgevoegde CD-ROM; tevens verwijzen we naar Appendix A voor een woordje uitleg hierbij. Er moet ook op gewezen worden dat de hier besproken simulator strikt genomen niet als een programma uitgevoerd is, maar eerder als een collectie functionaliteit. Dit laat toe om op eenvoudige wijze een gebruikersinterface naar wens rond een algemeen bruikbare kern te schrijven, al naargelang de noden van de gebruiker. Het is precies deze kern die hier besproken zal worden. Een aantal voordelen van deze aanpak zijn: De look and feel van de gebruikersinterface kan bijna om het even wat zijn. Van volledig tekstueel tot volledig grafisch. De gebruikersinterface kan quasi onafhankelijk van de kern worden ontwikkeld (en vice versa), met die uitzondering dat de gebruikersinterface natuurlijk de aangeboden functionaliteit van de kern gebruikt, en er dus in zekere mate op afgestemd moet worden. De hier beschreven software kan op een verscheidenheid aan besturingssystemen worden ingezet. Men moet enkel een gebruikersinterface ontwerpen voor het besturingssysteem in kwestie 1. Bovendien bestaan er ook mogelijkheden om bijvoorbeeld een grafische gebruikersinterface te ontwerpen zodat die op verschillende platformen kan worden gebruikt, zie bijvoorbeeld [4]. Helaas werd deze laatste mogelijkheid te laat ontdekt, zodat het niet meer mogelijk was om een grafisch schil rond de kern te ontwikkelen die zou draaien op zowel Windows, Linux als Mac zonder extra inspanning. In de plaats daarvan werd een grafische interface ontwikkeld voor het Windows platform; we verwijzen naar Appendix B voor meer details GDataType : algemeen bruikbare datatypes De bestanden GDataType.h en GDataType.cpp bevatten de definitie en de implementatie van een aantal datatypes en een aantal operaties op deze datatypes. Meestal zijn de gedefinieerde datatypes gewoon bestaande datatypes met een andere naam. De reden hiervoor is tweeledig: Door een aangepaste benaming weet je als programmeur beter waarmee je aan het werk bent. Zo verraadt Int8 in tegenstelling met char meteen dat het over een geheel getal (integer) gaat van 8 bits, en dus is het meteen duidelijk dat een variabele van dit type de waarden 128 tot en met 127 kan aannemen. Het is zo veel eenvoudiger om een andere implementatie te geven aan een datatype. Als om welke reden dan ook besloten wordt om bijvoorbeeld zelf een datatype Int16 te voorzien, dan kan dat door het aanpassen van slechts twee bestanden. Op die manier wordt de nieuwe implementatie verborgen gehouden voor de rest van de broncode, wat een enorm voordeel is. Want wanneer overal short in de broncode zou gebruikt zijn, dan zouden we alle bestanden moeten controleren en short gaan vervangen door Int Men spreekt in de terminologie van softwareontwerp van information hiding en encapsulation. 1 Hierbij gaan we uit van de onderstelling dat er voor het besturingssysteem in kwestie een C++ compiler beschikbaar is om de kern te compileren. Dit zou geen probleem mogen zijn, aangezien voor zowat elk platform wel een C++ compiler beschikbaar is. Alleen al de GNU Compiler Collection (welke onder andere een C++ front-end bevat) is beschikbaar voor vele platformen, zie [3] 20

28 Verder zijn macro s voorzien om het maximum en het minimum van twee getallen 2 te bepalen en om een vlottende komma getal af te ronden. Tenslotte zijn er nog twee routines voorzien om een machtsverheffing te berekenen. De eerste gebruikt een naïve manier om de macht te berekenen, maar deze aanpak is traag gebleken met relatief grote exponenten. Daarom werd een tweede algoritme ontworpen, dat een stuk sneller is bij grotere exponenten. Het algoritme is gebaseerd op het feit dat je ieder natuurlijk getal kunt schrijven als de som van machten van 2. Op die manier kan je de machtsverheffing herleiden naar een produkt dat je met veel minder berekeningen kan uitrekenen. Even een voorbeeld ter illustratie. Laat ons a 45 uitrekenen. Met een naïef algoritme zouden we dit uitrekenen als a.a. }.{{...a.a}. Dit zou 44 vermenigvuldigingen vergen. 45 factoren a Met het tweede algoritme zouden we de machtsverheffing voor het uitrekenen herschrijven: a 45 = a = a 25.a 23.a 22.a 20 = a 32.a 8.a 4.a We merken nu op dat we heel wat bewerkingen kunnen besparen door herhaaldelijk te kwadrateren (dit is natuurlijk de reden waarom de exponent als een som van machten van 2 werd geschreven). Het algoritme zal volgende bewerkingen doen: a 2 = a.a a 4 = a 2.a 2 a 8 = a 4.a 4 a 16 = a 8.a 8 a 32 = a 16.a 16 a 45 = a 32.a 8.a 4.a Dit vergt 1 vermenigvuldiging. Dit vergt 1 vermenigvuldiging. Dit vergt 1 vermenigvuldiging. Dit vergt 1 vermenigvuldiging. Dit vergt 1 vermenigvuldiging. Dit vergt 3 vermenigvuldigingen. In totaal kost de berekening van a 45 ons op deze manier dus slechts 8 vermenigvuldigingen in plaats van 44, een flinke winst. Het algoritme moet wel de exponent als een som van machten van 2 schrijven, moet de opeenvolgende kwadraten uitrekenen, etc. Dit weegt echter niet op tegen de snelheidswinst die men ermee kan halen en zeker niet als de exponent groot is Stringutils : handig werken met strings Over dit stuk van de code kunnen we kort zijn : het is een verzameling van een aantal routines om het werken met strings (string in de betekenis van STL 3 ) eenvoudiger te maken. Het was nooit de bedoeling om een zo volledig mogelijke functionaliteit te implementeren en daarom werden enkel een paar routines die voor de simulator onontbeerlijk zijn, geïmplementeerd. Deze zijn te vinden in de bestanden Stringutils.h en Stringutils.cpp Configuration : het instellen van parameters Een van de belangrijkste eisen die aan een simulator worden gesteld, is dat deze de werkelijkheid zo getrouw mogelijk moet weergeven. Daarom moet het mogelijk zijn om een 2 In principe zijn deze macro s niet beperkt tot getallen, alhoewel getallen het hoofddoel zijn. Elk datatype waarvoor de relationele operator > is gedefinieerd, kan in principe worden gebruikt. 3 STL : the Standard Template Library, een C++ bibliotheek, zie bijvoorbeeld [4] 21

29 aantal verschillende parameters in te stellen en te gebruiken. Het zou immers onmogelijk zijn om voor ieder interessant geval een aparte simulator te schrijven, om nog niet te spreken over de verspilling van tijd en energie die ermee gepaard zou gaan. Ook de simulator die in het kader van dit eindwerk is ontwikkeld, is ontworpen om met parameters om te gaan. Daartoe is een C++ klasse met de naam Configuration in het leven geroepen, die aan een aantal eigenschappen moest voldoen. Met het oog op een eventuele uitbreiding van de simulator om nog meer mogelijkheden te bieden 4, moest aan een aantal bijkomende eigenschappen worden voldaan. De volgende voorwaarden werden aldus opgelegd aan de klasse Configuration : 1. De klasse moet eenvoudig zijn in gebruik, en dus moet het eenvoudig zijn om een parameter en z n waarde toe te voegen of op te vragen. 2. De klasse mag geen beperking hebben op het aantal parameters, noch op de naam van een parameter. Dit uiteraard met het oog op een eventuele uitbreiding van de simulator of het gebruik van de klasse in een andere context. 3. Er mag in principe geen beperking zijn op het datatype van een parameter. Vanzelfsprekend zullen parameters eerder numeriek van aard zijn, maar dan nog hebben we een waaier aan mogelijkheden: natuurlijke getallen, gehele getallen, vlottendekomma getallen, Er moeten mogelijkheden voorzien worden om een configuratie persistent te maken, zodat de gebruiker van de klasse niet iedere keer een lijst met parameters en hun waarde moet instellen, maar deze bijvoorbeeld uit een bestand of database kan halen. Het resultaat heeft alle opgesomde eigenschappen, zoals we later zullen aantonen. Voorwaarde 3 zorgde voor wat problemen bij de implementatie, omdat er in C++ (of STL) geen goede mogelijkheden zijn om een collectie aan te leggen van objecten van een verschillend datatype. Om die reden werd ervoor gekozen om alle waarden voor te stellen met behulp van strings. Het is dan aan de gebruiker van de klasse om zelf expliciet de interpretatie of conversie van een waarde doen. Voor gehele getallen en vlottende-komma getallen kan dit met behulp van de volgende, in C/C++ voorziene, functies (zie bijvoorbeeld [6] en [5]): int atoi(const char* s); /* ASCII to integer */ double atof(const char *s); /* ASCII to floating number */ Er moet dan wel gebruik gemaakt worden van de mogelijkheid om een string als char* ter beschikking te stellen, wat kan door de methode c str() uit te voeren op het stringobject. Wil men een boolean voorstellen, dan kan men zijn toevlucht zoeken tot bijvoorbeeld de stringvoorstellingen true en false. Mocht er nood zijn om parameters in te voeren van een totaal ander datatype, dan volstaat het routines te voorzien om dit datatype om te zetten naar een string en omgekeerd. Parameters van het type string vereisen uiteraard geen conversie. Intern is een configuratie opgebouwd rond een zogenaamde multimap, dit is een structuur die conceptueel data bijhoudt in paren. Ieder paar bestaat uit een sleutel en een 4 een aantal mogelijke uitbreidingen staan beschreven in hoofdstuk 6 22

30 Figuur 3.1: Een voorbeeld van een configuratie (conceptueel) lijst met z n corresponderende waarde(n). Met een sleutel kunnen meerdere waarden geassocieerd worden (en zelfs dubbels zijn toegelaten), vandaar het prefix multi. Omdat informatie toevoegen of ophalen steeds een sleutel vereist, zijn de sleutels alfabetisch gesorteerd om deze operaties sneller te doen verlopen. De waarden die met een welbepaalde sleutel zijn geassocieerd, worden niet gesorteerd en de waarde die het eerst werd ingevuld zal dus ook als eerste in de lijst staan. In het geval van een configuratie is de sleutel de naam van de parameter, een string, en de bijhorende waarde(n) is (zijn), zoals reeds gezegd, ook van het datatype string. Een voorbeeld van een configuratie staat in figuur 3.1. Daar is duidelijk te zien dat alle waarden als string worden bijgehouden, maar dat deze eigenlijk als andere datatypes moeten geinterpreteerd worden. Het gebruik van deze klasse is bewust eenvoudig gehouden. De volgende routines zijn beschikbaar om met parameters te werken: virtual void setvalue( const string, const string ); virtual Int16 getcount( const string ); virtual string & getfirst( const string ); virtual string & getlast( const string ); virtual Int16 getvalues( const string, Stringvector & ); Om een parameter toe te voegen aan de configuratie wordt de functie setvalue gebruikt. Als eerste argument wordt de naam van de parameter opgegeven, als tweede argument zijn waarde. Aangezien een configuratie intern rond een multimap is opgebouwd en een multimap in principe geen limiet heeft op het aantal sleutels en waarden die erin worden opgeslagen (er is altijd een limiet, want niets is oneindig in een computersysteem), heeft onze configuratie in principe geen limiet op het aantal parameters die ze kan bevatten. De waarde van een parameter opvragen wordt doorgaans gedaan met behulp van de functie getfirst, als argument wordt de naam van de parameter opgegeven (een sleutel in de configuratie). Wanneer men twijfelt aan het aantal waarden dat met een parameter is geassocieerd (of wanneer men er geen idee van heeft), kan met dit aantal opvragen met behulp van de functie getcount; deze neemt als argument de naam van 23

31 de parameter waarvan men het aantal waarden wil kennen dat ermee gekoppeld is. De functies getfirst en getlast geven de eerste respectievelijk de laatste waarde terug die met de opgegeven sleutel (naam van een parameter) is geassocieerd. In de meeste gevallen zal met een parameter slechts één waarde gekoppeld zijn en in dit geval geven beide functies dus dezelfde waarde terug. Wil men echter alle waarden weten, dan kan men gebruik maken van getvalues. Deze functie neemt eveneens de naam van de parameter als eerste argument, plaatst het resultaat in het tweede argument van het type Stringvector en geeft als resultaat het aantal waarden terug dat in de Stringvector is geplaatst. Stringvector is gewoon een andere en handigere benaming voor vector<string>. Voor meer informatie over de STL datastructuren vector, multimap en string verwijzen we bijvoorbeeld naar [5] of [7]. Verder is er ook nog aan een vorm van persistentie gedacht. Het gebruik van een databank voor de opslag van een configuratie leek niet nuttig in de huidige context, vandaar dat alleen het werken met bestanden is voorzien. De functies die hierbij worden gebruikt zijn: virtual void LoadFromFile( const string ); virtual void SaveToFile( const string ); Door aan een van bovenstaande functies een string als argument mee te geven dat de naam van een bestand eventueel voorafgegaan door het volledig pad voorstelt, wordt de configuratie respectievelijk naar het bestand weggeschreven of ingeladen uit het bestand. Vanzelfsprekend kan niet zomaar ieder bestand dienst doen als configuratiebestand. Een configuratiebestand moet namelijk voldoet aan een aantal eisen: het bestand moet een ASCII tekstbestand zijn; de eventuele extensie is daarentegen willekeurig. de inhoud van het bestand wordt geïnterpreteerd als een opeenvolging van regels, en iedere regel behoort tot precies één van de volgende categorieën: een blanco regel, dus een regel die uitsluitend bestaat uit zogenaamde witte ruimte in de C/C++ zin (zie bvb [6]). In praktijk zullen dit vooral spaties en tabs zijn. een commentaarregel, dit is een regel die begint met het karakter # en voor de rest willekeurige karakters bevat. een regel met de invoering van een nieuwe sectie. Deze is gekenmerkt door een karakterreeks die tussen de karakters [ en ] staat. een regel die een nieuwe parameter en de bijhorende waarde definieert. Deze is gekenmerkt door het optreden van het karakter = tussen twee strings. De aanhalingstekens die men weleens gebruikt om aan te geven dat het om een string gaat (bijvoorbeeld zoals in dit is een string ) worden hierbij niet gebruikt. Enkele opmerkingen hierbij kunnen bijzonder nuttig zijn : 1. witte ruimte aan het begin van een regel wordt genegeerd. 2. het is niet toegestaan om de bovenstaande types te combineren in een regel. Een regel die een sectie invoert bijvoorbeeld kan niet eindigen met commentaar. 24

32 3. wanneer een regel verwerkt wordt, wordt zijn type bepaald door na te gaan aan welk type deze regel voldoet, dit gebeurt in de volgorde zoals hierboven aangegeven. Dit betekent bijvoorbeeld dat een (deel van een) parameternaam nooit kan bestaan uit een reeks karakters tussen [ en ], omdat de desbetreffende regel zal aanzien worden als de invoering van een sectie, ook al bestaat de regel in kwestie uit twee strings gescheiden door het karakter =. Ook de invoering van een sectie in een regel die begint met het karakter # zal niet doorgaan, deze regel zal immers als een commentaarregel aanzien worden! 4. wanneer een regel gevonden wordt die aan geen van de bovenstaande vier types voldoet, wordt een uitzondering opgeworpen. Hier komen we dadelijk op terug. 5. secties worden op dit moment gewoon genegeerd. Ze kunnen wel van nut zijn voor de menselijke lezer om wat orde te scheppen in een configuratiebestand. Uiteraard is er ook nood aan foutopvang. Het zou kunnen voorkomen dat men een configuratie wil inladen uit een bestand, en dat het opgegeven bestand niet bestaat. Of dat, zoals in de opmerkingen hierboven al aangegeven was, er een ongeldige regel in het configuratiebestand staat. Ook het opvragen van de waarde van een parameter die niet in de configuratie bestaat is zo n geval. Om dit soort van foutopvang te voorzien is een extra klasse met de naam Config Exception voorzien. Intern werkt deze klasse met getallen die een bepaalde soort uitzondering voorstellen. Op het moment van schrijven is de uitvoer van een uitzondering (bijvoorbeeld op het scherm) echter ook beperkt tot dit getal, zodat een foutmelding nogal cryptisch kan overkomen. De soorten uitzonderingen zijn in de broncode als volgt gedefinieerd 5 : #define CE_UNSPECIFIED_ERROR 1 #define CE_FILE_NOT_FOUND 10 #define CE_FILE_NOT_READY 11 #define CE_INVALID_CONFIGFILE 20 #define CE_INVALID_SEMANTICS 30 #define CE_KEY_NOT_FOUND 40 De interpretatie die hieraan gegeven wordt is de volgende : CE UNSPECIFIED ERROR : een niet nader bepaalde uitzondering. CE FILE NOT FOUND : geeft aan dat een bestand niet kon geopend worden om er data uit te lezen. In de praktijk is dit bijna altijd te wijten aan het feit dat het bestand niet gevonden werd, vandaar de naam. CE FILE NOT READY : geeft aan dat een bestand niet klaarstaat om er data naartoe te schrijven. Dit kan bijvoorbeeld optreden wanneer een configuratie naar een bestand moet worden geschreven, maar de schijf is reeds vol, of het medium waarheen men wil schrijven is niet beschrijfbaar (zoals een gewone CD-ROM). CE INVALID CONFIGFILE : geeft aan dat er een ongeldige regel is opgetreden in een configuratiebestand (cfr. supra). 5 het prefix CE duidt aan dat het om een Config Exception gaat 25

33 CE INVALID SEMANTICS : deze uitzondering geeft aan dat de semantiek van een configuratie niet is zoals verwacht. Deze uitzondering wordt dus niet door de functies van de klasse zelf opgeworpen, maar door de gebruiker van de klasse (in casu de functie die de simulatie verzorgt, zie verder). Dit kan bijvoorbeeld optreden als blijkt dat de waarde van een parameter niet fysisch kan, bijvoorbeeld als het aantal bits in een frame negatief zou zijn. CE KEY NOT FOUND : deze uitzondering geeft aan dat een sleutel niet bestaat en treedt op als men de waarde wil opvragen van een parameter die niet bestaat in de configuratie. Tot slot nog dit : Configuration is een klasse, en dat betekent dat er instanties van deze klasse (objecten dus) moeten aangemaakt worden vooraleer men met parameters kan werken. Het feit dat er in principe geen beperking is op het aantal objecten van een klasse krijgen we er gratis bij. Het is dus perfect mogelijk om tegelijkertijd met meerdere configuraties te werken Random : genereren van toeval We zeiden het al eerder : bijzondere aandacht moet geschonken worden aan de keuze van een geschikte random generator. In C/C++ is een random generator aanwezig, die na een initialisatie met de functie srand(... ) kan worden opgeroepen met de functie rand(... ). Er is echter gebleken dat deze random generator helemaal niet zo goed random is, in het bijzonder wanneer relatief weinig random getallen gegenereerd worden. Verder hebben we sterk de indruk dat de behaalde resultaten nog eens afhangen van de C/C++ ontwikkelomgeving ook, al konden we daar geen bewijs voor vinden zonder de werkelijke implementatie van rand(... ) onder ogen te krijgen. Als klein voorbeeldje lieten we de computer 600 keer met een dobbelsteen gooien. We zouden als resultaat moeten krijgen dat elk aantal ogen ongeveer 100 keer is opgetreden. De resultaten waren als volgt : 105, 118, 94, 106, 97, 80. Dat is bezwaarlijk random te noemen. De waarden 80 en 118 schieten er wat bovenuit. Het verschil tussen beide waarden bedraagt niet minder dan 38! Uiteraard besloten we niet alleen uit dit kleine, op zichzelf weinig zeggend voorbeeldje dat de C/C++ random generator niet was wat we zochten, maar deden we wat meer uitgebreide tests waarop we hier niet verder ingaan. Tenslotte vonden we ook in de literatuur aanwijzingen dat de standaard C/C++ random generator verre van ideaal is. Een prachtvoorbeeld hiervan vinden we in [9], en we citeren uit het de originele tekst : be very, very suspicious of a system-supplied rand()... Via [11] vonden we informatie over een random generator (UNIRAN genaamd) die voldoet aan onze eisen voldoende random en toch zo snel mogelijk en we herwerkten vervolgens de broncode die we daar vonden tot de versie die we in onze simulator gebruiken. Uiteraard is de broncode beschikbaar op de bijgevoegde CD-ROM (zie ook appendix A). Voor de volledigheid : de random generator is een zogenaamde prime modulus multiplicative linear congruential generator en is gebaseerd op de formule Z[i] = ( Z[i 1]) mod waarin Z[i] de nieuwe random waarde is en Z[i-1] de vorige random waarde voorstelt. 26

34 Later vonden we nog een pak informatie over random generators terug in [10], maar omdat deze thesis intussen al een eind gevorderd was, besloten we toch maar om geen nieuwe en mogelijks betere maar tragere random generator te implementeren. Wanneer we bij wijze van kleine test met onze random generator 600 keer met een dobbelsteen gooien, krijgen we : 96, 95, 90, 110, 95, 114. Dat is duidelijk al beter. Geen echte uitschieters naar onder. Het verschil tussen de hoogste en de laatste waarde bedraagt maar 24 tegenover de 38 van de C/C++ random generator. We zullen later ook opmerken dat de resultaten van de simulaties in overeenstemming zijn met de theorie, voor zover we dat konden nagaan uiteraard. Ook dit geeft weer dat de random generator die we hier gebruiken voldoet BitString : bitsequenties op hun best Omdat vaak gebruikt zal gemaakt worden van bitsequenties en een aantal operaties hierop, is ook hier een aparte klasse voor voorzien, met de naam BitString. De beschrijving van deze klasse kan echter vrij kort gebeuren. Om te beginnen is het zo dat een Bitstring niet beperkt is met betrekking tot het aantal bits. Met hezelfde gemak werkt men met een Bitstring van 8 bits en een Bitstring van 1024 bits. De enige beperking is het beschikbaar geheugen van de machine. Intern wordt een bit uit de Bitstring voorgesteld door een bit van het geheugen, dat gealloceerd wordt per byte. Dat zorgt voor een voldoend snelle behandeling van Bitstrings, terwijl de overhead aan geheugen minimaal is (in het slechtste geval zijn 7 bits geheugen gealloceerd die niet worden gebruikt, ongeacht de lengte van de Bitstring). De lengte van een Bitstring kan indien nodig dynamisch worden aangepast. Een aantal standaard operaties op bitsequenties zijn voorzien : het testen op gelijkheid of ongelijkheid van twee bitsequenties, het bepalen van de som van twee bitstrings (zie bewerkingen met bits in het vorig hoofdstuk), het opvragen van de lengte van een bitsequentie, het bepalen van het gewicht van de bitsequentie, etc. Ook het opvragen van een zekere bit in de bitsequentie of het instellen van dit bit met de waarde 0 of 1 behoort tot de mogelijkheden. In een Bitstring is de conventie aangenomen dat bits worden genummerd van rechts naar links, te beginnen bij 0. Wanneer we dus de bitsequentie 1000 willen vormen uitgaande van 0000, moeten we dus de derde bit op 1 zetten. Ook kan een Bitstring worden uitgeschreven. Verder is er ook nog een match routine voorzien, die controleert of twee bitsequenties overeenkomen op de posities aangegeven door een masker. Alleen die posities waar in het masker een 1-bit staat worden in rekening gebracht. Dit kan nuttig gebruikt worden: herinner u dat we in hoofdstuk 2 vermeldden dat er een probleem kan optreden bij het combineren van frames als er een even aantal frames gecombineerd moeten worden. We verkozen om in het probleemgeval te wachten op een volgende combinatie om een beslissing te maken. Als alternatieve aanpak stelden we voor om na te gaan of er een codewoord bestaat dat, op de onbepaalde posities na, samenvalt met het gecombineerde woord. Stel dat we weten dat het codewoord er moet uitzien als volgt, op een aantal onbepaalde posities na aangegeven met een? : 1?101? (6 bits dus). We kunnen dan een masker opbouwen om de posities die zeker zijn te controleren op overeenkomsten bij andere codewoorden. Het bijhorende masker bestaat uit 1-bits, behalve op de plaats van een? : Het codewoord 1?101? kunnen we nu met de routine match gaan vergelijken met de andere codewoorden, waarbij het masker wordt meegegeven. Uiteraard moeten de posities 27

35 aangeduid met een? worden ingevuld met een binaire waarde. Dit kan naar keuze met een 0 of 1, want op die posities staat in het masker een 0, zodat deze posities bij het vergelijken toch worden genegeerd. Alle codewoorden die voldoen aan 1?101? zullen bij een match een waarde true weergeven, zodat we weten hoeveel en welke codewoorden nog in aanmerking komen. Tenslotte is er net als bij Configuration een klasse voorzien die gebruikt wordt bij foutopvang, Bitstring error. Want ook bij het werken van Bitstrings kunnen onverwachte situaties zich voordoen. Onder normale omstandigheden komt de gebruiker amper met deze klasse in contact, en we verwijzen dan ook naar de gedocumenteerde broncode voor alle details. Voor meer details in het algemeen en in het bijzonder wat er gebeurt in speciale of onverwachte gevallen 6 verwijzen we eveneens naar de broncode SimEngine : de werkmier Het combineren van foutieve frames Om bruikbare informatie uit foutief ontvangen frames te halen, zullen we tijdens de simulatie foutieve frames combineren tot bruikbare frames of dit althans proberen. We beschreven in hoofdstuk 2 al uitvoerig hoe we het combineren kunnen aanpakken. Voor het combineren van de woorden zelf is de functie Int8 Combine(Bitstring *, vector<bitstring>&) beschikbaar. Een vector die de te combineren woorden (Bitstrings) bevat wordt als argument meegegeven. Het resultaat wordt in het eerste argument, een wijzer ( pointer ) naar een Bitstring, teruggeven. Om het onderscheidt te maken tussen de twee mogelijke gevallen, geeft de functie zelf een geheel getal terug, dat aangeeft of alle bits in het resulterende woord eenduidig bepaald konden worden of niet. Voor de eenvoud zijn in de broncode symbolische namen gedefinieerd voor deze constanten; zij zullen verder nog gebruikt worden: #define COMBINE_SUCCES 0 #define COMBINE_UNDECIDED 1 De eigenlijke simulatie We zullen nu overgaan tot de beschrijving van het eigenlijke simulatieproces. Daarvoor is de functie Int8 Simulate( Configuration &, void (*) (string), void (*)(Float, Float) ); beschikbaar. Als eerste argument wordt een configuratie meegegeven, zodat de simulator over de nodige parameterwaarden kan beschikken. Vervolgens kunnen twee functies als argument meegegeven worden; zij staan in voor respectievelijk de uitvoer en het aanpassen van de vooruitgang van de simulatie. Desgewenst kunnen elk van deze opties achterwege 6 bij wijze van voorbeeld : wat gebeurt er als we willen controleren of twee bitstring overeenkomen ( matchen ) op bepaalde posities, maar het meegegeven masker bevat meer bits dan de bitsequenties?? 28

36 gelaten worden door een NULL als argument mee te geven. De functieoproep resulteert verder in een getal dat als foutcode dient geinterpreteerd te worden (een van 0 verschillend getal geeft een fout aan, 0 geeft een succesvolle simulatie aan). De functie die instaat voor de uitvoer van de simulator neemt een string aan als argument en deze functie zal worden opgeroepen bij iedere uitvoer die de simulator wil produceren. De reden om op deze manier te werken is eenvoudig : de simulator is niet diegene die zich moet bekommeren om wat er met de uitvoer moet gebeuren, dat is namelijk de verantwoordelijkheid van de gebruiker van deze routine. Meestal zal de uitvoer naar het scherm worden gestuurd, maar evengoed kan de gebruiker ervoor opteren om de uitvoer naar een bestand te schrijven (een soort log-bestand zeg maar) of om een combinatie van beide te maken. Zelfs het versturen van de uitvoer via een netwerk behoort tot de mogelijkheden. Verder moet men rekening houden met het feit dat de uitvoer naar het scherm sturen niet altijd op dezelfde manier kan gebeuren. Dit is voornamelijk van belang wanneer de uitvoer in een grafische gebruikersinterface terechtkomt. Met behulp van de hier geschetste methode kan de gebruiker een functie ontwerpen die met de uitvoer beschikbaar gesteld door de simulatieroutine als een string precies doet wat de gebruiker verlangt. Een illustratie hiervan kan in Appendix B worden gevonden. Een andere functie die kan worden meegegeven als argument staat in voor het bijwerken van de gegevens in verband met de vooruitgang van de simulatie. Op die manier kan de gebruiker op de hoogte worden gehouden van de vorderingen van de simulatie, wat uiteraard bijzonder handig is als de simulatie lang kan duren. De meegegeven functie moet twee Float getallen als argument nemen. Beide getallen liggen in [0,1] en stellen een fractie voor die de vooruitgang van de simulatie weergeeft. Het eerste getal geeft aan hoeveel frames van het aantal frames dat moet verzonden worden al succesvol is verzonden (de eigenlijke vooruitgang van de simulatie dus). Het tweede getal geeft de fractie aan van het maximaal aantal frames dat kan vezonden worden dat al is verzonden. Dit laatste is een maatregel die de simulatietijd beperkt, zodat de simulatie steeds eindigt. In hoofdstuk 2 toonden we al aan dat het volstaat om door simulatie een statistiek op te bouwen van het aantal retransmissies voor één welbepaald codewoord, namelijk het codewoord bestaande uit 0-bits. Hieruit kon dan de efficiëntie van een aantal retransmissieprotocols worden bepaald. De simulatie, zoals ze in haar huidige vorm bestaat, beperkt zich dan ook tot het bepalen van het aantal retransmissies van verzonden frames. Dit gebeurt als volgt : Er wordt gecontroleerd of alle benodigde parameters in de configuratie aanwezig zijn 7. Indien dit niet zo is stopt de simulatie en geeft de routine een fout terug. In het andere geval wordt verdergegaan met de simulatie. De waarden van de parameters worden opgehaald en deze worden getest om te zien of ze semantisch wel juist zijn (zo moet bijvoorbeeld een aantal bits per frame positief zijn). In het geval ze niet voldoen wordt een uitzondering opgeworpen, in het andere geval wordt gewoon verdergegaan. Aan de hand van het aantal bits per frame (een parameter die men nu kent) wordt een referentieframe een BitString van gepaste lengte opgebouwd; dit referentieframe is het frame dat steeds verzonden zal worden, in casu het codewoord dat bestaat uit 0-bits. 7 zie verder voor een lijst en beschrijving van deze parameters 29

37 Nu wordt begonnen aan de uitvoering van een lus. Eén van de parameters die de simulatieroutine verwacht is namelijk het aantal frames dat maximaal mag verzonden worden. Dit aantal mag onder geen enkele voorwaarde worden overschreden, omdat op deze manier wordt gegarandeerd dat de simulatie eindigt in een aanvaardbare tijd als deze parameter goed wordt gekozen. Dit kan op het eerste zicht raar lijken, maar beeldt u zich in dat de meegegeven parameters zo zijn dat de kans om aan de ontvanger een foutief frame te ontvangen 99,9 % is. Uit formule 2.5 volgt dan dat het aantal frames dat verzonden moet worden ongeveer 1000 keer het aantal te simuleren frames zal zijn. Wanneer het aantal te simuleren frames groot is, betekent dit een simulatie die heel lang kan duren... De lus wordt in principe even vaak uitgevoerd als het aantal frames dat maximaal mag verstuurd worden, al is de hoop natuurlijk dat de simulatie zal gedaan zijn alvorens dit aantal is bereikt. In de lus wordt als volgt gewerkt : Het aantal bitfouten in het te verzenden frame wordt op 0 gezet. Er wordt een kopie van het referentieframe genomen, het is deze kopie die in gedachten verzonden zal worden. Er worden fouten geïntroduceerd in de kopie op random wijze. Dit stelt het verzenden voor, waardoor bitfouten op random wijze worden ingevoerd. Nu wordt het frame verder behandeld alsof het door de ontvanger zou ontvangen zijn. Eerst wordt ondersteld dat de ontvanger zonder geheugen werkt. Volgende zaken wordt achtereenvolgens gedaan : Er wordt gecontroleerd of het ontvangen frame foutief is of niet 8. Indien het frame foutief is, wordt indien dit nog niet gebeurd zou zijn een vlag gezet dat we een retransmissie wensen. Tevens wordt het aantal foutief ontvangen frames aangepast, net als het aantal retransmissies voor dit frame. Het frame zelf wordt genegeerd en de lusverwerking gaat verder. Indien het een correct ontvangen frame betreft, wordt het aantal correct verzonden frames aangepast. Indien het een retransmissie betrof, wordt het aantal retransmissies voor dit frame bijgehouden voor verder gebruik. Tenslotte wordt een en ander in gereedheid gebracht voor de transmissie van een nieuw frame (conceptueel dan toch, want het is steeds hetzelfde referentieframe dat in gedachten wordt verstuurd). Er wordt dan gecontroleerd of het aantal te simuleren frames nog niet bereikt is. Is dit het geval, dan wordt indien nodig de vooruitgang van de simulatie aangepast en wordt de simulatie beëindigd. Er wordt nu ondersteld dat de ontvanger over geheugen beschikt, en het ontvangen frame wordt nogmaals bekeken. Volgende acties worden hierbij ondernomen: Er wordt gekeken of het aantal te simuleren frames al bereikt is. Indien dit het geval is, wordt een volgende lusiteratie uitgevoerd. In het andere geval, wordt terug een onderscheid gemaakt tussen een foutief ontvangen frame en een correct ontvangen frame. 8 We herinneren eraan dat de ontvanger enkel fouten kan detecteren, maar niet kan corrigeren 30

38 Als het ontvangen frame correct blijkt, dan wordt het aantal correct verzonden frames aangepast. Als het ontvangen frame het gevolg was van een retransmissie, wordt ook het aantal retransmissies voor dit frame bijgehouden voor later gebruik. Tenslotte wordt de buffer met foutief ontvangen frames terug leeg gemaakt, in afwachting van een volgend frame. Een volgende lusiteratie wordt ingezet. Indien het ontvangen frame echter foutief blijkt, wordt het frame in het geheugen opgeslagen. Ook het aantal foutief ontvangen frames wordt aangepast. Vervolgens wordt een onderscheidt gemaakt tussen een retransmissie en een eerste transmissie van een frame. Het geval dat het een eerste transmissie betreft is vrij eenvoudig : het ontvangen frame is foutief, en dus kan het niet aan de bestemmeling worden afgeleverd. Een retransmissie is nodig en een vlag hiervoor wordt gezet. Het andere geval, het geval dat het een retransmissie betrof, is iets ingewikkelder. Aangezien het een retransmissie betrof, zitten nu al minstens 2 foutieve frames in het geheugen. We kunnen dus proberen om de foutieve frames te combineren. Het vervolg hangt af van het resultaat van deze poging tot combinatie. Als het resultaat van het combineren van de foutieve frames blijkt COM- BINE UNDECIDED te zijn, dan betekent dit dat geen bruikbaar frame uit de foutief ontvangen frames kon worden afgeleid. Een volgende retransmissie zal nodig zijn. Indien het resulaat echter COMBINE SUCCES bleek te zijn, dan kon een bruikbaar frame worden afgeleid uit de frames die in het geheugen zaten. Dat betekent echter nog niet dat het resulterende frame ook inderdaad het verzonden frame is. Daarom wordt op het resulterende frame een foutdetectie gedaan. Worden geen fouten ontdekt, dan is het frame inderdaad het verzonden frame. Het aantal correct verzonden frames wordt dan aangepast, het aantal retransmissies voor het betreffende frame worden bijgehouden voor later gebruik, en tenslotte wordt het geheugen terug leeggemaakt. Een nieuw frame zal worden verzonden tijdens de volgende lusiteratie. Als het resulterende frame de foutdetectie niet doorstaat, dan betekent dit dat niet alle informatie van het verzonden frame kan gerecupereerd worden uit de frames die in het geheugen zitten en dus zal een volgende retransmissie nodig zijn. Dit geval wordt echter wel bijgehouden, alsook het aantal bitfouten dat in het resulterende frame aanwezig was. Merk op dat dit laatste doorgaans niet kan in een reële ontvanger, maar onze simulator verzamelt deze informatie toch omdat deze nuttig kan zijn om te controleren hoe goed of hoe slecht het combineren van frames werkt. Indien nodig wordt de vooruitgang van de simulatie bijgewerkt. Een aantal resultaten worden naar de uitvoer geschreven. Herinner u dat dit gebeurt door een meegegeven functie op te roepen, zodat de manier waarop de uitvoer verschijnt als deze al verschijnt afhangt van de meegegeven functie. Indien nodig, worden de gegevens in verband met het aantal retransmissies naar een 31

39 bestand weggeschreven. Analoog worden, indien nodig, de gegevens over het aantal bitfouten in het resultaat van het combineren van foutief ontvangen frames naar een bestand geschreven. Tenslotte geven we ook nog een overzicht van de voor de simulator vereiste parameters, samen met hun betekenis: Bits In Frame : het aantal bits in een frame. Frames To Simulate : het aantal frames dat men wil verzenden. MaxFrames To Simulate : het maximaal aantal frames dat mag verzonden worden. Bit Error Probability : de bitfoutprobabiliteit. Retr Stats : een boolean die aangeeft of de gegevens over het aantal retransmissies naar een bestand moet geschreven worden of niet. Retr Stats File : geeft de bestandsnaam (eventueel voorafgegaan door het volledige pad) aan van het hierboven genoemde bestand. Combine Stats : een boolean die aangeeft of de gegevens over het aantal bitfouten in het resultaat van een combinatie van foutieve frames naar een bestand moet geschreven worden of niet. Combine Stats File : geeft de bestandsnaam (eventueel voorafgegaan door het volledige pad) aan van het hierboven genoemde bestand. 32

40 Hoofdstuk 4 Simulatieresultaten 4.1 Een uitgewerkt voorbeeld van een simulatie We zullen dit hoofdstuk beginnen met een bespreking van een uitgevoerde simulatie, dit om aan te geven hoe de uitvoer van een simulatie moet geinterpreteerd worden. Het gebruikte configuratiebestand had volgende inhoud : # StARQ configuration file # # Please do not edit unless you know what you re doing!! [code] # the number of bits in a single frame Bits_In_Frame = 30 [simulator] # the number of frames to simulate Frames_To_Simulate = # the absolute maximum number of frames to try before succes MaxFrames_To_Simulate = # the bit error probability Bit_Error_Probability = 0.01 # generate statistics about the number of retransmissions?? Retr_Stats = true # generate statistics about the number of errors due to combination?? Combine_Stats = true Er kan opgemerkt worden dat hierin eigenlijk nog twee parameters ontbreken (zie de lijst met vereiste parameters aan het eind van vorig hoofdstuk), maar deze worden nog 33

41 ingesteld door het programma alvorens de simulatie van start gaat. Ze zijn niet relevant voor de rest van het verhaal. Wanneer we het simulatieprogramma laten lopen, en de output met behulp van een aangepaste uitvoerfunctie naar het scherm sturen, verschijnt na verloop van tijd het volgende: <StARQ simulator uitvoer> Bezig met de configuratie te controleren op de nodige keys...ok Simulatieparameters : Aantal bits in een frame : 30 bits Bitfoutprobabiliteit : 0.01 Aantal frames te simuleren : Maximaal aantal frames dat mag verzonden worden : Bezig met simuleren... Simulatie zonder geheugen aantal correct verzonden frames : aantal foutief ontvangen frames : aantal verzonden frames : % foutieve frames : (theoretisch : ) Simulatie met geheugen aantal correct verzonden frames : aantal foutief ontvangen frames : aantal verzonden frames : aantal keer dat de beslissing door combinatie UNDECIDED was : 66820/86420 aantal keer dat door combinatie een verkeerd frame werd geleverd : 4050/19600 % foutieve frames : (theoretisch : ) Gegevens omtrent het aantal retransmissies worden nu naar een met de naam retr_stats.dat geschreven...[ok] bestand Gegevens omtrent de combinatie van frames worden nu naar een bestand met de naam comb_stats.dat geschreven...[ok] </StARQ simulator uitvoer> Hoe moeten we dit nu precies interpreteren? Om te beginnen zien we dat de simulatieroutine een controle deed om te zien of de benodigde parameters in de configuratie aanwezig waren. Vervolgens worden de gebruikte parameterwaarden naar de uitvoer gestuurd, wat bijzonder handig is in het geval resultaten van een veel eerder gedane simulatie worden bekeken. Zo weet men met welke waarden de simulatie toen werd gedaan. Tenslotte volgen een aantal resultaten van de simulatie zelf. 34

42 In een eerste deel wordt een overzicht gegeven van het geval waarbij men onderstelt dat de ontvanger niet over een vorm van geheugen beschikt. Men ziet dat inderdaad frames correct werden verstuurd. Daartoe moest de zender frames versturen; van deze frames kwamen foutief bij de ontvanger aan (dit is goed voor % van de verzonden frames), en vereisten dus een retransmissie (welke natuurlijk ook weer tot een foutief ontvangen frame kon leiden). Uit formule 2.3 halen we dat theoretisch % van de verzonden frames foutief zou aankomen. Het percentage dat effectief foutief aankwam tijdens de simulatie ligt daar akelig dichtbij, een schitterend resultaat dat aangeeft dat onze toevalsgenerator z n werk uitstekend doet wanneer voldoende frames worden gesimuleerd. Wanneer we verder in de uitvoer kijken, merken we op dat een aantal gegevens over het aantal benodigde retransmissies naar een bestand werden geschreven 1 met de naam retr stats.dat. Wanneer we even in dit bestand dat overigens een doodgewoon tekstbestand is gaan kijken, zien we onder andere het volgende staan: Retransmission data [memory=off] [#retr] [#occurences] Dit zijn de gegevens over het aantal retransmissies in het geval de ontvanger werkt zonder geheugen (wat dus aangegeven is door [memory=off]). Wanneer je de som maakt van de getallen uit de rechterkolom, gewogen met de getallen uit de corresponderende linkerkolom, bekom je Dit is precies het aantal foutief ontvangen frames, dus het aantal frames dat minstens één retransmissie nodig had. Zo hadden bijvoorbeeld frames drie retransmissies (of vier transmissies) nodig om correct verstuurd te worden. Merk op dat ook deze gegevens in theorie kunnen voorspeld worden. Neem als voorbeeld het aantal frames dat drie retransmissies nodig heeft. De kans dat een frame precies drie retransmissies nodig heeft, prob[#retr = 3], is, zie formule 2.1, gelijk aan (1 p frame )p 3 frame. p frame is op zijn beurt gegeven door formule 2.3, wat zich in dit geval (zie de simulatieparameters) herleidt tot p frame = 1 (1 0, 01) 30 = 0, Hiermee komt er: prob[#retr = 3] = 0, Gelet op het feit dat er frames moeten verzonden worden, zullen er dus ongeveer frames zijn die drie retransmissies vereisen. De gemeten waarde van komt dus aardig in de buurt. Men kan narekenen dat alle opgemeten waarden minder dan 0,5 % van de theoretisch berekende waarden afwijken, tenminste als we ons beperken tot niet meer dan drie retransmissies. Dat de 1 de reden dat deze gegevens steeds naar een bestand worden geschreven, en niet naar de uitvoer, ligt in het feit dat dit overzicht vrij lang kan worden. Hierdoor zouden de effectieve simulatieresultaten niet meer zichtbaar zijn wanneer alle uitvoer naar het scherm wordt gestuurd. 35

43 afwijkingen groter zijn als we de rijen met meer retransmissies in beschouwing nemen is niet meer dan logisch, omdat deze gevallen veel minder vaak voorkomen. Als zo n geval één keer meer of minder voorkomt tijdens de simulatie, betekent dit al meteen een grote afwijking... Met deze gegevens kan nu het gemiddeld aantal retransmissies, E[#retr], worden berekend. Hierbij mag men wel niet uit het oog verliezen dat de frames die correct werder verstuurd zonder retransmissies moeten meegerekend worden. Aan de bovenstaande tabel moet dus nog een rij worden toegevoegd, namelijk de rij die het aantal optredens van 0 retransmissies vermeld. Het precieze aantal doet eigenlijk niet terzake, omdat in de berekening van E[#retr] dit aantal toch met 0 vermenigvuldigd zal worden enerzijds, en anderzijds omdat de enige andere plaats waar nog van dit aantal gebruik zal gemaakt worden de berekening van het totale aantal frames is, waarvoor 0 of meer retransmissies nodig waren om het correct te verzenden. Dat laatste is natuurlijk gewoon het totaal aantal frames dat correct verzonden is, namelijk We berekenen dan E[#retr] als volgt: E[#retr] = = = = = = i.p rob[#retr = i] i=0 aantal frames die precies i retransmissies vereisten i. aantal frames die 0 of meer retransmissies vereisten i=0 aantal frames die precies i retransmissies vereisten i. totale aantal verzonden frames i=0 aantal frames die precies i retransmissies vereisten i i=0 1 i.(aantal frames die precies i retransmissies vereisten) i=0 1 ( ) = 0, We merken op dat we dit resultaat ook op een andere manier konden bekomen. Het is namelijk zo dat een retransmissie voortkomt uit een foutief ontvangen frame. Het aantal foutief ontvangen frames is dan ook het totale aantal retransmissies (we onderstellen nog steeds dat de ontvanger niet over een vorm van geheugen geschikt). Het gemiddeld aantal retransmissies zou men dus ook kunnen berekenen als de verhouding van het aantal foutief ontvangen frames en het totale aantal correct verstuurde frames. In feite is dit ook wat we in de berekening hierboven doen, zij het dan enigszins verdoken. We kunnen E[#retr] dus ook (korter) berekenen als volgt: aantal foutief ontvangen frames E[#retr] = aantal correct verzonden frames = = 0,

44 Ook dit resultaat is mooi in overeenstemming met wat we in theorie zouden verwachten. Uit formule 2.2 halen we namelijk dat E[#retr] gegeven wordt door 0, = 0, , hetgeen betekent dat de waarde die we vonden door simulatie de theorie goed benadert. In een tweede deel wordt ondersteld dat de ontvanger over geheugen beschikt, en dus kan gebruik maken van de combinatie van foutief ontvangen frames om het aantal retransmissies tot een minimum te beperken. Ook in dit geval zijn de gevraagde frames correct verstuurd, en daarvoor moesten blijkbaar frames worden verstuurd. Merk op dat we met correct verstuurde frames niet bedoelen dat deze frames allemaal correct zijn ontvangen door de ontvanger. We bedoelen hiermee dat deze frames werden verstuurd door de zender en uiteindelijk eventueel na een aantal retransmissies en eventueel na combinatie van foutieve frames door de ontvanger aan de bestemmeling werden doorgegeven. Terloops merken we op dat het toevoegen van een vorm van geheugen aan de ontvanger de efficiëntie nooit kan doen dalen. Immers, in het slechtste geval kan geen nuttige informatie uit de opgeslagen foutieve frames worden gehaald, en herleidt dit geval zich tot het geval waarin geen geheugen werd gebruikt. We benadrukken dat dit in de veronderstelling is dat de ontvanger elk aantal bitfouten kan detecteren, want in de praktijk kan het natuurlijk voorkomen dat het combineren leidt tot een verkeerd codewoord, waardoor de ontvanger onterecht denkt dat hij een correct frame heeft geconstrueerd. De gegevens vermelden ook dat frames foutief ontvangen werden. Ook hier is het percentage foutief ontvangen frames in goede overeenstemming met de theorie. We willen echter de aandacht vestigen op feit dat het verschil in percentage foutief ontvanger frames ( % en % respectievelijk voor de simulatie zonder en met geheugen) niets te maken heeft met het al dan niet aanwezig zijn van een vorm van geheugen. Het minieme verschil is enkel te wijten aan het feit dat een verschillend aantal frames is verstuurd door de zender, waardoor er ook een verschillend aantal foutief bij de ontvanger kunnen aankomen. Uit deze aantallen leiden we af dat = frames correct werden ontvangen. Dit aantal is een stuk minder dan het verwachtte aantal van , hetgeen er dus inderdaad op wijst dat niet alle frames die onder de noemer correct verstuurd vallen ook daadwerkelijk correct worden ontvangen door de ontvanger. Dit wijst erop dat ook door combinatie van foutief ontvangen frames een aantal nuttige frames kon worden geconstrueerd, wat op zijn beurt resulteerde in het uitsparen van een aantal retransmissies. Dit wordt ook bevestigd door het feit dat slechts transmissies nodig waren in plaats van toen geen geheugen werd gebruikt. Als we even verder kijken zien we dat er keer werd geprobeerd om foutieve frames te combineren tot een bruikbaar frame. Het combineren gebeurt uiteraard maar van zodra minstens twee foutieve frames in het geheugen zitten. Hierbij kon keer geen beslissing worden gemaakt (dit is in 77,32 % van de gevallen). Dit is het probleemgeval waarover we het hadden in hoofdstuk 3 toen we de combinatie van foutieve frames bespraken. In het andere geval, dat keer optrad, kon wel een frame worden geconstrueerd. Wanneer we enkel deze laatste gevallen beschouwen, was het geconstrueerde frame keer een foutief frame, maar in de overige gevallen (goed voor 79,34 %) kon de ontvanger geen fout ontdekken in het geconstrueerde frame, en aldus werd het frame in kwestie 37

45 beschouwd als correct ontvangen. Inderdaad, samen met de eerder vermeldde frames die goed werden ontvangen door de ontvanger, werden op deze manier frames aan de bestemmeling afgeleverd. Ook voor deze mode van de ontvanger werden gegevens omtrent het aantal retransmissies bijgehouden. In het eerder vernoemde bestand retr stats.dat vinden we onder andere: Retransmission statistics [memory=on] [#retr] [#occurences] Wordt E[#retr] berekend met deze gegevens, dan bekomen we: totale aantal retransmissies E[#retr] = aantal correct verzonden frames = = 0, Er moet op gewezen worden dat in de bovenstaande berekening niet zonder meer gebruik gemaakt mag worden van het aantal foutief ontvangen frames, zoals we dat hoger wel deden. Wanneer geen geheugen wordt gebruikt, geldt inderdaad dat het totale aantal retransmissies gelijk is aan het aantal foutief ontvangen frames, maar deze stelling gaat niet meer op wanneer geheugen wordt ingezet. Het foutief ontvangen van een frame leidt immers niet noodzakelijk tot een retransmissie. Door het combineren van foutieve frames bestaat immers de mogelijkheid dat een correct frame wordt geconstrueerd, en als resultaat hiervan dat één of meerdere retransmissies worden uitgespaard. Expliciete gegevens over hoeveel geheugen op welk tijdstip wordt gebruikt zijn niet beschikbaar. Dat is ook niet meteen nodig, omdat het aantal benodigde retransmissies een goede indicatie is van het geheugengebruik. Een retransmissie wijst namelijk op een foutief ontvangen frame, en het is precies dat wat in het geheugen wordt opgeslagen. Wanneer de grootte van een frame bekend is, en dat nemen we toch aan, samen met een goede indicatie van het aantal frames dat in het geheugen moet kunnen opgeslagen worden, dan staat niets ons nog in de weg om een geschikte geheugengrootte te bepalen. Tenslotte bemerken we dat de uitvoer nog melding geeft van gegevens over het combineren van frames die naar het bestand comb stats.dat. Een blik in dit bestand overigens ook een tekstbestand levert onder andere volgende informatie op: Combination of frames stats [#errors] [#occurences]

46 Herinner u dat het combineren van foutieve frames twee mogelijkheden bezat afgezien van het optreden van een uitzondering natuurlijk. Alleen het geval waarbij alle bits van het resulterende woord eenduidig konden bepaald worden is op dit ogenblik van belang. In de uitvoer van de simulator vinden we terug dat dit in slechts gevallen van het combineren kon worden gedaan. Niet minder dan keer resulteerde dat in een ongeldig codewoord. De gegevens uit het laatstgenoemde bestand gaan precies over dit laatste geval. Want een ongeldig codewoord als resultaat krijgen is jammer, maar het is minstens even jammer om niet te weten hoe ongeldig het codewoord wel is, met andere woorden, hoeveel bits er fout zijn in het codewoord. In praktijk kun je uiteraard niet weten welk codewoord er gestuurd werd, en bijgevolg kan men doorgaans ook niet achterhalen hoeveel bitfouten er gemaakt zijn als het ontvangen woord geen codewoord blijkt te zijn. Maar in een simulatie ligt dat iets anders: daar kunnen we deze informatie wel achterhalen, en dus werd het ook gedaan. De achterliggende reden is dat in de praktijk in tegenstelling tot onze simulator hier wel gebruik wordt gemaakt van foutcorrigerende codes. Het kan dus nuttig zijn even te kijken hoeveel bitfouten een woord bevat als na combinatie blijkt dat het woord geen codewoord is. Dit met het oog op onderzoek om te controleren of retransmissieprotocols met geheugen nog steeds zo goed presteren als goede foutcorrigerende codes worden gebruikt. Zoals uit de tabel hierboven blijkt gaat het in van de gevallen (99,23 %) om een enkele bitfout. In de resterende 31 gevallen betreft het een dubbele bitfout. Het gebruik van foutcorrigerende codes in plaats van foutdetecterende codes zou dus een extra winst kunnen opleveren. Verder onderzoek drong zich op. In de broncode werd tijdelijk extra code aangebracht die ervoor zorgde dat, in het geval een combinatie een ongeldig codewoord opleverde, alle frames die in de combinatie betrokken waren samen met het resulterende ongeldige codewoord naar een bestand werden geschreven. Omdat dit bestand bij de simulatie van een groot aantal frames, al dan niet in combinatie met een grote bitfoutprobabiliteit, vele tientallen tot zelfs een paar honderd megabyte kan worden, werd deze code later terug verwijderd. In feite werd de betreffende code in commentaar gezet, zodat de liefhebber ze alsnog kan uitcommentariëren en opnieuw kan meecompileren. Bedenk wel dat het bestand in kwestie bijzonder groot kan worden... Het aanvullende onderzoek leverde op dat bij lage waarden van p frame ook de frames die gecombineerd werden vaak maar enkele of dubbele bitfouten vertonen. Het gebruik van foutcorrigerende codes zou hier dus geen extra winst opleveren, omdat foutief ontvangen frames vaak zouden gecorrigeerd kunnen worden, resulterend in een bruikbaar frama, alvorens zou gepoogd worden om foutief ontvangen frames te combineren. Naarmate p frame stijgt, beginnen meer en meer meervoudige bitfouten in de ontvangen frames te sluipen. Twee en drie bitfouten beginnen de regel te worden, maar desondanks blijkt het aantal bitfouten in het resultaat van een combinatie niet meteen mee toe te nemen. Enkele bitfouten zijn nog steeds de regel, dubbele bitfouten komen ook af en toe voor. Een enkele keer gaat het om drie of vier bitfouten. Er treden situaties op waar drie frames met ieder twee of meer bitfouten worden gecombineerd tot een frame met slechts één bitfout. In deze gevallen zou een foutcorrigerende code dus wel zijn voordeel kunnen hebben. We gaan er hier echter niet verder op in. 39

47 4.2 Verdere resultaten We deden een vrij groot aantal simulaties, met de meest uiteenlopende parameters, en kwamen bij de analyse van de verkregen resultaten iedere keer tot de logische conclusie dat veel resultaten gelijkaardig waren omdat de waarde van p frama gelijkaardig was. Het verhogen van de waarde van het aantal bits en tegelijkertijd het verlagen van de bitfoutprobabiliteit (of omgekeerd) werkt elkaar inderdaad tegen, zie formule 2.3. We stellen dan ook slechts een stuk van de resultaten voor, deze geven de typische trend aan van alle resultaten. De resultaten die we hier voorstellen, zijn ook in hun volle glorie terug te vinden op de CD-ROM, samen met een aantal Excel-bestanden waarin we de verwerking van deze resultaten deden. We kozen voor een vaste framelengte van 100 bits. We lieten vervolgens de bitfoutprobabiliteit variëren, en we simuleerden iedere keer frames. Dat komt dus overeen met het doorsturen van ongeveer 12 megabyte (inclusief overheadbits). Figuur 4.1: Het aantal verzonden frames in functie van de bitfoutprobabiliteit ( frames van 100 bit) Vervolgens zetten we het aantal verstuurde frames uit in functie van de bitfoutprobabiliteit. Het resultaat is te zien in figuur 4.1. Wanneer we het geval bekijken waarin geen geheugen werd gebruikt, is het eerste wat ons opvalt het feit dat de opgemeten waarden bijzonder goed overeenkomen met de theoretische waarden. Dit is terug een mooi resultaat. We merken verder op dat het aantal verstuurde frames zeer sterk oploopt naarmate de bitfoutprobabiliteit (en dus p frame ) toeneemt. De curve van het gemiddeld aantal retransmissies, E[#retr], heeft eenzelfde verloop. Uit formule 2.4 halen we immers dat de twee curves, op een schaling en een offset na, dezelfde zijn. Het gemiddeld aantal retransmissies stijgt dus snel, en gelet op de formules 2.7, 2.9 en 2.10 kunnen we zeggen dat de efficiëntie van een retransmissieprotocol snel zal afnemen als het gemiddeld aantal retransmissies 40

48 snel toeneemt, wat ook een logisch resultaat is. Beter is het gesteld met het verloop van het aantal verzonden frames indien geheugen wordt gebruikt. Dit aantal stijgt uiteraard ook naarmate de bitfoutprobabiliteit stijgt, maar beduidend minder snel. De stijging lijkt op het eerste zicht ongeveer lineair, een veelbelovend resultaat. Figuur 4.2: Het aantal verzonden frames in functie van de bitfoutprobabiliteit - detail ( frames van 100 bit) We maakten een grafiek die deze ongeveer lineaire stijging in meer detail zou tonen. De bekomen grafiek is getoond in figuur 4.2. De stijging was niet lineair, maar zelfs minder dan lineair. Voor de duidelijkheid werd met behulp van de kleinste kwadratenmethode de rechte berekend die het beste langs de eerste zeven punten van de curve ging. Deze rechte werd ook in de grafiek voorgesteld. Er is duidelijk te zien dat de curve minder dan lineair stijgt met de bitfoutprobabiliteit. Maar uiteindelijk zijn we niet rechtstreeks geïnteresseerd in het aantal frames dat moet verstuurd worden. We willen weten hoe efficiënt een protocol is. Daarvoor beschouwden we de bekomen resultaten als zijnde de resultaten van een stop-and-wait schema. Als parameters hadden we uiteraard n = 100 (het aantal bits per frame) en verder kozen we vrij willekeurig k = 80, R b = en T d = 0, 008. De bijhorden s-waarde berekenen we met formule 2.8, en dit geeft 4,48. De verkregen efficiëntie is uitgezet in functie van de bitfoutprobabiliteit in figuur 4.3, zowel voor het geval er geheugen werd gebruikt, als voor het geval er geen geheugen werd gebruikt. In het geval er geen geheugen werd gebruikt berekenden we ook de theoretische efficiëntie (zie formule 2.7) en zetten deze eveneens uit. Opnieuw merken we op dat de gemeten waarden zeer goed overeenkomen met de theorie. De beide curven liggen namelijk zo goed als op elkaar. De invloed van het geheugen is ook duidelijk merkbaar. De efficiëntie daalt nog wel naarmate de bitfoutprobabiliteit toeneemt, maar beduidend 41

49 Figuur 4.3: De efficiëntie van een stop-and-wait schema in functie van de bitprobabiliteit minder snel als in het geval zonder geheugen. Wanneer p frame de 80 % overschreidt (de bitfoutprobabiliteit is dan ongeveer 0,016), is de efficiëntie bijna tweemaal hoger in het geval geheugen wordt gebruikt! Merkwaardig genoeg hebben de efficiënties een gelijkaardig verloop wanneer we een go-back-n schema of een selective-repeat schema zouden beschouwen. Dit geeft nogmaals aan hoe belangrijk het is om zo weinig mogelijk retransmissies te hebben. Bij wijze van demonstratie van de mogelijkheden die het toevoegen van geheugen kan teweegbrengen, geven we even een stuk van de inhoud weer van het bestand retr stats.txt dat bekomen werd door simulatie met als bitfoutprobabiliteit 0,002 2 : Retransmission statistics [memory=off] [#retr] [#occurences] het volledige bestand staat op de CD-ROM 42

50 Retransmission statistics [memory=on] [#retr] [#occurences] Het optreden van meer dan 70 (!!) retransmissies is dus geen uitzondering wanneer geen geheugen wordt gebruikt. In het geval geheugen wordt gebruikt, zijn nooit meer dan 12 retransmissies nodig. Dat geeft aan dat de benodigde hoeveelheid geheugen best eens kan meevallen, zodat behalve kostprijs en complexiteit van de hardware niets geheugen in de weg staat... 43

51 Hoofdstuk 5 Besluit Bij een klassiek retransmissieprotocol wordt een frame waarin één of meerdere fouten worden gevonden genegeerd, met een retransmissie tot gevolg. Dat is zonde, want niet alle informatie in een foutief ontvangen frame is noodzakelijk waardeloos en retransmissies doen de efficiëntie van het protocol alleen maar dalen. We hebben een (gedeeltelijke) oplossing voor dit probleem voorgesteld in de vorm van geheugen dat kan worden toegevoegd aan de ontvangerzijde van een transmissiesysteem. Vervolgens hebben we ook met succes software ontwikkeld die ons in staat stelt een idee te krijgen over het aantal retransmissies dat optreedt bij het verzenden van informatie, en dit voor een waaier aan parameterwaarden. Hieruit kon de efficiëntie van een aantal retransmissieprotocols worden gehaald. We hebben opgemerkt dat het toevoegen van geheugen aan een retransmissieprotocol een bijzonder lonende zaak kan zijn, in het bijzonder wanneer het gebruikte transmissiekanaal gekenmerkt is door een hoge bitfoutprobabiliteit. Het benodigde geheugen om goede resultaten te krijgen valt eveneens best mee, zeker gezien de huidige stand van de techniek waardoor relatief grote geheugens vrij goedkoop produceerbaar zijn. Verder onderzoek, in het bijzonder theoretisch van aard, is echter nodig om de theoretische grenzen van geheugen te bepalen en te onderzoeken of geheugen het nog steeds zo schitterend kan doen wanneer foutcorrigerende blokcodes worden gebruikt. 44

52 Hoofdstuk 6 Suggesties voor uitbreidingen en verder onderzoek Een eerste suggestie die we maken heeft te maken met het simuleren zelf. Een van de onderstellingen die we in deze scriptie en bij de ontwikkeling van de simulator maakten was dat de ontvanger elke transmissiefout kon detecteren. Zoals toen vermeld is dat in praktijk helemaal niet het geval. Het zou daarom bijzonder leerrijk kunnen zijn om effectief met een blokcode te kunnen werken. De broncode moet dan zodanig aangepast worden dat de gebruiker kan werken met (lineaire) blokcodes. Op deze manier kan de ontvanger in de simulatie nagaan of het ontvangen woord een codewoord is, in plaats van te controleren of het ontvangen woord hetzelfde woord is als datgene wat verzonden is (in realiteit kan dat laatste uiteraard niet). Dit zou het realiteitsgehalte al gevoelig verbeteren. Eventueel kan men daaarin nog verder gaan, en ook foutcorrectie mee in rekening brengen. Een ander aspect dat hiermee in het bereik komt te liggen is het feit dat we dan aan codewoorden een zekere waarschijnlijkheid van optreden kunnen meegeven. Nu veronderstellen we dat alle codewoorden met dezelfde waarschijnlijkheid optreden, waardoor we ons kunnen beperken om steeds het 0-codewoord te verzenden. In dit geval zouden we een codewoord kunnen kiezen om te verzenden volgens een gegeven kansverdeling. Ook dit schept mogelijkheden om de realiteit beter te gaan benaderen en na te gaan hoe retransmissieprotocols met geheugen zich gedragen wanneer bepaalde codewoorden vaker worden verzonden dan andere. Uiteraard wordt best eens onderzocht of deze uitbreiding wel degelijk voldoende nuttig is om uit te voeren. Een andere uitbreiding die zeker het uitvoeren waard zou kunnen zijn heeft betrekking tot de grafische gebruikersinterface. Momenteel is een programma met een grafische gebruikersinterface beschikbaar voor het Windows platform. Gebruikers van andere besturingssystemen blijven hiermee wat in de kou staan. Er zijn zeker mogelijkheden om een grafische interface te ontwerpen die op verschillende platforms kan worden ingezet (zie bijvoorbeeld [12]). Dat zou een hele vooruitgang kunnen zijn, zeker gelet op het feit dat Linux (om maar één niet-windows platform te noemen) steeds vaker wordt gebruikt. Eventueel kan ook worden overwogen om de broncode over te zetten naar een andere taal, waarbij we dan vooral aan Java denken. Ook daar kunnen we namelijk een en hetzelfde programma op verschillende platforms draaien. Er moet wel worden gewaakt over het feit dat het programma niet teveel aan snelheid mag inboeten. Een bijkomend probleem is dat het herschrijven van de broncode in een andere taal een bijzonder tijdrovende 45

53 zaak is met relatief weinig opbrengst, met als grote gevaar het introduceren van bugs die niet in de originele broncode zaten. Eventueel kan men de simulatorkern behouden, en alleen de interface errond herschrijven. Er moet dan wel worden onderzocht hoe routines geschreven in C++ kunnen worden gebruikt vanuit (bijvoorbeeld) Java broncode. Tot slot, maar daarom zeker niet minder belangrijk, integendeel, kan het ook bijzonder nuttig zijn om het toevoegen van geheugen aan een retransmissieprotocol eens te bekijken vanuit een meer theoretisch standpunt. Waar mogelijk, kan men de bekomen simulatieresultaten dan vergelijken met de theorie. 46

54 Bijlage A Inhoud van de CD-ROM De inhoud van de CD-ROM is als volgt gestructureerd: /Broncode: deze directory bevat alle broncode die voor deze thesis werd ontwikkeld. De directory is verder onderverdeeld in: /Simulator: hier kan men alle C++ broncode vinden van de simulatorkern. Deze broncode is ontwikkeld onder Microsoft Visual C en het verdient aanbeveling om de broncode op het Windows platform, indien mogelijk, ook met deze compiler te compileren. De reden hiervoor is dat er in de directory een kant en klare Visual C++ workspace beschikbaar is. De broncode kan desgewenst ook met een andere C++ compiler worden gecompileerd, maar dan zal de gebruiker wel zelf de voorbereiding moeten doen, of moeten hopen dat de compiler overweg kan met de bijgevoegde makefile. Bij wijze van test werd de broncode ook succesvol gecompileerd met Borland C++ Builder versie 5.0. Met het oog op een compilatie op een Unix of Linux gebaseerd systeem, is een makefile beschikbaar gesteld. Met het commando make all compileert men de broncode en krijgt men een consolegebaseerde applicatie ter beschikking. Deze verwacht één parameter op de commandolijn, namelijk de naam van het bestand (eventueel voorafgegaan door een volledig pad) waarin de te gebruiken configuratie staat. De consolegebaseerde versie voor Windows verwacht dezelfde parameter, maar we raden aan deze niet te gebruiken en in de plaats daarvan de qua gebruiksvriendelijkheid veel beter scorende grafische versie te gebruiken. /Win GUI: hier kan men alle bestanden vinden die nodig zijn om de grafische versie van het simulatieprogramma op te bouwen. Omdat deze versie in Borland C++ Builder 5.0 is ontwikkeld, is een C++ Builder project file bijgevoegd, net als alle benodigde C++ Builder Forms. De broncode hier is wel degelijk afhankelijk van de ontwikkelomgeving, dus een compilatie op een ander platform en/of met een andere ontwikkelomgeving zit er hoogst waarschijnlijk niet in. Merk ook op dat de broncode van de simulatorkern vereist is om de applicatie te kunnen opbouwen. 1 Er is echter gepoogd om alleen standaard C++ code te schrijven, er is dus geen gebruik gemaakt van de MFC (Microsoft Foundation Classes) of andere platform- en/of compilerafhankelijke zaken 47

55 /Applicaties: in deze directory staan reeds gecompileerde versies van de applicaties ter beschikking. Ze kunnen zonder meer onmiddellijk worden uitgevoerd. De directory bevat alleen applicaties voor het Windows platform. Met Windows bedoelen we alle recente versies van Microsoft Windows, waaronder Windows 95/98/Me en Windows NT/2000. De applicaties zijn getest onder Windows 2000 en Windows 95, maar zouden ook op de andere versies probleemloos moeten werken. Mocht dit toch niet het geval zijn, dan kan de gebruiker de broncode altijd zelf compileren. De reden waarom alleen Windows applicaties op de CD-ROM te vinden zijn vind z n oorsprong in het feit dat Linux op de meest verschillende computerarchitecturen kan draaien en omdat er vele Linuxdistributies zijn, zodat de kans eerder klein is dat een applicatie probleemloos draait op het eerste het beste Linuxsysteem. We raden aan om op de desbetreffende distributie en computerarchitectuur de broncode te compileren. Hetzelfde geldt voor een systeem gebaseerd op (een) Unix(variante). /Scriptie: deze bevat de volledige thesistekst, in pdf formaat. /Simulaties: deze directory bevat een aantal bestanden met resultaten die bekomen werden bij de simulaties. Tevens zijn een aantal grafieken en andere berekeningen voor handen. Deze zijn gemaakt met Microsoft Excel De omstandigheden waarin de simulaties werden gedaan staan op de CD-ROM zelf vermeld. 48

56 Bijlage B StARQ v0.0 We vermeldden al in hoofdstuk 3 dat we rond de simulator een grafische gebruikersinterface ontwikkelden voor het Windows platform. Deze bijlage fungeert als (korte) handleiding en beschrijving bij deze grafische interface. Het programma heeft de naam StARQ meegekregen, net zoals de simulatorkern overigens. Wanneer we in deze bijlage over StARQ spreken, dan bedoelen we dus de grafische gebruikersinterface die we hier voorstellen. De volledige broncode van deze grafische gebruikersinterface is eveneens beschikbaar gesteld op de bijgevoegde CD-ROM 1. Deze werd ontwikkeld in Borland C++ Builder 5.0. Merk op dat deze interface enerzijds werd ontwikkeld met het doel om te laten zien hoe men gebruik kan maken van de aangeboden functionaliteit van de simulator, en anderzijds met het doel om gebruiksvriendelijker te zijn dan de originele versie, die een command line applicatie is. We hadden dus nooit de intentie om een complete grafische gebruikersinterface te ontwerpen volgens alle regels van de kunst; daarvoor was het tijdsbestek te klein. Wanneer we het programma opstarten krijgen we het beeld uit figuur B.1. 1 zie ook bijlage A Figuur B.1: StARQ v0.0 - configuratiescherm 49

57 De parameters in het configuratiescherm spreken voor zich, met uitzondering dan misschien van Activeer lusmode. De bedoeling was dat het mogelijk zou zijn een rij waarden op te geven voor één of meerdere parameters, om zo te vermijden dat een simulatie beperkt blijft tot één enkele configuratie. Bij wijze van voorbeeld zou men dan 100:5:250 kunnen invullen als waarde van het aantal bits in een frame, met als bedoeling dat er een simulatie wordt gedaan voor verschillende waarden: een simulatie met de waarde 100, dan een simulatie met de waarde 105 en zo verder, iedere keer de waarde met 5 verhogend, tot en met de waarde 250. Dat vermijdt dat de gebruiker als waarde 100 moet invullen, de simulatie moet starten, een nieuwe waarde moet invullen, terug de simulatie moet starten, etc. De hierboven gebruikte notatie startwaarde : increment : eindwaarde is trouwens overgenomen van Mathlab. Helaas kon deze bijzonder nuttige functionaliteit nog niet worden geimplementeerd, waardoor het uitvoeren van simulaties met verschillende waarden voor een of meerdere parameters dus nog steeds door de gebruiker moet gebeuren. Deze optie wordt op het moment van schrijven dan ook genegeerd door StARQ. Zoals we zien is de configuratie oorspronkelijk leeg 2. We kunnen nu de waarden voor de parameters gaan invullen naar wens, of we kunnen een configuratiebestand inladen. Dat laatste doen we als volgt: Vul de naam in van een bestand (inclusief de extentie!), eventueel voorafgegaan door het volledige pad als het bestand niet in de huidige actieve directory zou staan. Klik op Bestand openen. Als alles goed gaat, wordt het bestand ingeladen, en krijgen we een beeld als dit in figuur B.2. Figuur B.2: StARQ v0.0 - een ingevuld configuratiescherm 2 StARQ bewaart de huidige toestand niet wanneer we het programma afsluiten, en geeft ook geen waarschuwing dat data niet wordt opgeslagen! 50

58 Uiteraard kunnen nu nog bepaalde waarden worden aangepast indien gewenst. Het is namelijk zo dat wanneer de gebruiker de simulatie start, StARQ eerst de meest recente waarden voor de parameters gaat ophalen, en deze waarden doorgeeft aan de simulatiefunctie. Het is dus perfect mogelijk dat, ondanks het feit dat de gebruiker een configuratiebestand ingeladen heeft, de simulatie met totaal andere waarden dan deze in het configuratiebestand gebeurt. Een ingevulde configuratie kan ook worden opgeslagen in een bestand. Hiervoor gaat men als volgt te werk: Vul de naam in van een bestand (inclusief de extentie!), eventueel voorafgegaan door het volledige pad als het bestand niet in de huidige actieve directory moet komen. Merk wel op dat alle directories in het pad moeten bestaan. Deze worden dus niet aangemaakt indien ze nog niet bestaan! Wees ook voorzichtig met de keuze van de bestandsnaam, want een bestaand bestand wordt overschreven... Klik op Bestand opslaan. Uiteraard kan een en ander fout gaan bij het werken met bestanden. Het te openen bestand kan niet bestaan, de directory waarnaar een bestand moet worden geschreven bestaat niet, etc. Wanneer zo n situatie zou optreden wordt door StARQ een foutmelding op het scherm getoond, zoals figuur B.3 laat zien. Figuur B.3: StARQ v0.0 - er ging blijkbaar iets mis... We moeten hierbij opmerken dat het niet StARQ is die het bestand opent, maar een configuratie(object). Wanneer we op de knop Bestand openen klikken, zal StARQ een configuratie(object) verzoeken om zichzelf in te laden vanuit het betreffende bestand, waarna de configuratie op het scherm kan worden getoond. De fout treedt dus op in een configuratie(object), dat dit kenbaar maakt aan z n buitenwereld door een uitzondering op te werpen (zie hoofdstuk 3). StARQ vangt deze uitzondering op, en merkt zo dat er een fout is opgetreden. Daarop wordt de inhoud van deze uitzondering aan de gebruiker getoond in een dialoogvenster zoals in figuur B.3. Dat verklaart de tekst Configuration Exception : 10. Als we in het lijstje in hoofdstuk 3 kijken, zien we inderdaad dat het nummer 10 overeenkomt met het niet kunnen openen van een bestand. StARQ speelt hier dus enkel een rol van tussenpersoon tussen de gebruiker en de simulatiekern. Tot slot merken we op dat de titel van het dialoogvenster, Error, een standaard titel is die we niet kunnen veranderen. De reden is dat we voor het tonen van zulke dialoogvensters gebruik maken van standaard Windows API 3 oproepen, waardoor de titel en de gebruikte taal afhankelijk zijn van het besturingssysteem. In casu dus een engelstalige versie van Windows API : Application Programmers Interface 51

59 Wanneer we het andere tabblad, Simulator, kiezen, krijgen we het beeld uit figuur B.4. Figuur B.4: StARQ v0.0 - simulatorscherm Ook hier is het zo dat StARQ maar een tussenstation is tussen de gebruiker en de simulatorkern. Wanneer we namelijk willen simuleren zonder dat waarden voor de parameters zijn ingevuld, verschijnt het scherm uit figuur B.5. Figuur B.5: StARQ v0.0 - simulaties gaan niet altijd goed... 52

60 Hier zien we duidelijk dat StARQ alleen maar een waarde toont, een waarde die wordt teruggegeven door de opgeroepen functie Simulate(... ) (zie hoofdstuk 3). De reden van de fout wordt door de simulatieroutine zelf naar de uitvoer gestuurd, welke op gepaste manier in StARQ wordt getoond. Het blijkt dat in de gebruikte configuratie een of andere parameter een ongeldige waarde had (Configuration Exception : 30). De twee grijze balkjes boven de Start simulatie knop zullen de vooruitgang tijdens een simulatie weergeven. Het eerste balkje, achter Correct ontvangen frames geeft de vooruitgang van de eigenlijke simulatie weer. Het tweede balkje heeft weer hoeveel frames in totaal verzonden zijn, op een schaal van 0 tot het maximaal toegelaten aantal 4. Bij een normale simulatie zal het eerste balkje dus sneller vooruit gaan dan het tweede. Is dit niet het geval, dan zullen niet alle gewenste frames verstuurd kunnen worden, omdat het maximaal toegelaten aantal frames dat mag verzonden worden al is bereikt vooraleer we alle frames correct verzonden hebben. Dat zal ook in de uitvoer worden weergegeven. Wanneer alle vereisten voor een simulatie voldaan zijn, begint de simulatie te lopen (figuur B.6). Figuur B.6: StARQ v0.0 - bezig met simuleren Het is nuttig op te merken dat StARQ zo is opgebouwd dat er gebruikt wordt gemaakt van meerdere (controle)draden (multithreading). De eigenlijke simulatie wordt in een aparte draad gedaan, zodat de grafische kant van het programma niet tijdelijk wordt geblokkeerd door een simulatie, wat wel het geval zou zijn wanneer alles in dezelfde draad zou gebeuren. Hierdoor blijft het programma reageren op invoer van de gebruiker. Een aangenaam voordeel hiervan is dat gebruiker ondertussen gewoon verder kan werken, hetzij met een andere applicatie, hetzij met StARQ zelf. Het is hierdoor ook perfect mogelijk dat de gebruiker bijvoorbeeld in het configuratievenster een nieuwe configuratie opstelt, 4 dit is een vereiste parameter, zie hoofdstuk 3 53

61 terwijl de simulatie in het simulatorvenster nog aan de gang is. Meerdere simulaties terzelfdertijd starten kan echter niet en de reden waarom we dat niet toelaten is dat de uitvoer van de verschillende simulaties mogelijks door elkaar zou komen te staan, wat bijzonder verwarrend zou kunnen werken. Na afloop van een succesvolle simulatie wordt de gebruiker op de hoogte gebracht door middel van een dialoogvenster zoals in figuur B.7. Figuur B.7: StARQ v0.0 - de simulatie werd succesvol beëindigd De uitvoer van de simulatie staat dan ondertussen in het daartoe voorziene venster, zelfs al was de gebruiker nog bezig in het configuratievenster. Het aantal lijnen uitvoer dat in het venster kan is redelijk beperkt en dus kan het voorkomen dat niet alle uitvoer in het venster past. Ook daar is aan gedacht. In het venster met de simulatoruitvoer zijn namelijk een aantal extra mogelijkheden aanwezig. Door in dit venster met de rechtermuisknop te klikken komen deze te voorschijn in een klein venstertje. Dit is getoond in figuur B.8. Figuur B.8: StARQ v0.0 - extra functionaliteit in het uitvoerscherm Er zijn mogelijkheden om een pagina omhoog te gaan of om een pagina omlaag de gaan, zodat men de uitvoer als het ware bladzijde per bladzijde kan bekijken. Functies die niet van toepassing zijn worden automatisch uitgeschakeld, wat ook op de figuur te zien is. Tenslotte is ook de bijzonder nuttige mogelijkheid toegevoegd om de complete uitvoer (dus niet alleen het huidige scherm) te kopieren naar het klembord, zodat de uitvoer snel ter beschikking kan gesteld worden van andere applicaties zoals uw favoriete tekstverwerker en dergelijke meer... 54