Ryhmälähetys mobiileissa ad hoc -verkoissa

Transkriptio

1 Teijo Venäläinen Ryhmälähetys mobiileissa ad hoc -verkoissa Tietotekniikan pro gradu -tutkielma 8. elokuuta 2006 Jyväskylän yliopisto Tietotekniikan laitos Jyväskylä

2 Tekijä: Teijo Venäläinen Yhteystiedot: Työn nimi: Ryhmälähetys mobiileissa ad hoc -verkoissa Title in English: Multicast in Mobile Ad Hoc Networks Työ: Tietotekniikan pro gradu -tutkielma Sivumäärä: 68 Tiivistelmä: Ryhmälähetys on tapa lähettää dataa jollekin joukolle kuluttamatta turhaan tietoliikennekaistaa. Tämä on erityisen tärkeää mobiiliverkoissa, joissa siirtotien kaistasta on aina pulaa. Mobiililaitteet voivat muodostaa keskenään ns. mobiilin ad hoc -verkon (MANET) ilman minkään ulkopuolisen laitteen ohjausta. Tällainen verkko pystyy toimimaan ilman olemassaolevaa verkkoinfrastruktuuria. MANET:ille on olemassa monia käyttökohteita, kuten esimerkiksi pikainen verkon pystytys katastrofialueilla, erilaiset sensoriverkot tai matkapuhelinverkon kapasiteetin parantaminen. Ryhmälähetyksen ja MANET:n yhdistäminen on tällä hetkellä tärkeä tutkimusaihe. English abstract: Multicasting is a bandwidth-efficient way to send data to a specific group. This is especially important in mobile networks where bandwidht is limited. Mobile nodes may form a mobile ad hoc -network (MANET) amongst them, without any help from other equipment. This kind of network may function without any existing network infrastructure. There are many applications for MANET, like emergency networks in catastrophic areas, sensor networks or enhancing cellular network s capacity. Combining multicast and MANET together is nowadays a crucial researh issue. Avainsanat: ryhmälähetys, ad hoc, protokolla, ADMR, CAMP, MAODV, ODMRP Keywords: multicast, ad hoc, protocol, ADMR, CAMP, MAODV, ODMRP

3 Sanasto Ad hoc Tietotekniikassa termillä tarkoitetaan sellaista tietoverkkoa, jonka jäsenenä voidaan olla tarvittaessa vain väliaikaisesti [1]. Ad hoc -verkko pystyy luomaan itse reitityksen ilman ulkopuolista apua. ADMR On lyhenne nimestä Adaptive Demand-Driven Multicast Routing Protocol. ADMR on puumaiseen rakenteeseen perustuva, itsenäisesti toimiva ryhmälähetysprotokolla mobiileihin ad hoc -verkkoihin. AODV On lyhenne nimestä Ad-hoc On-Demand Distance Vector Routing. AODV on reaktiivinen unicastprotokolla mobiileihin ad hoc -verkkoihin. Levitysviesti, engl. Datan lähetystapa, jossa yksi lähettäjä lähettää kaikille broadcast muille verkon laitteille. CAMP On lyhenne nimestä Core Assisted Mesh Protocol. CAMP on mesh-rakenteeseen perustuva mobiilien ad hoc -verkkojen ryhmälähetysprotokolla, joka tarvitsee toimiakseen apua proaktiiviselta unicast-protokollalta. DARPA On lyhenne sanoista Defense Advanced Research Projects Agency. DARPA on Yhdysvaltain hallituksen rahoittama järjestö, jonka tehtävänä on kehittää uutta teknologiaa sotilaskäyttöön. DARPA kehitti mm. internetin edeltäjän ARPANET:in. CBR On lyhenne sanoista Constant Bit Rate. CBR tarkoittaa tietoliikenteessä tasaista datan siirtonopeutta. Debian On yksi Linuxin levitysversioista. Debian-hankkeen tarkoituksena on ollut luoda vapaaehtoisvoimin täysin vapaa käyttöjärjestelmä. Duplex Tarkoittaa kommunikaatiota, jossa signaali kulkee yhteyden osapuolten välillä molempiin suuntiin. Internet On kehitetty ARPANET:in pohjalta. Internet on hyvin suuri joukko tietojenkäsittelylaitteita, jotka ovat yhteydessä toisiinsa joko fyysisesti tai langattomasti. i

4 IP-TV On lyhenne sanoista Internet Protocol TV. Tarkoittaa TV-kuvan tai videosignaalin lähettämis- ja vastaanottamisteknologiaa Internetistä. Jaettu puu On ryhmälähetyksessä käytetty ryhmän rakenne, jossa muodostetaan vain yksi ryhmälähetyspuu. Kaikki lähetetty data kulkee yhden tai useamman määrätyn keskussolmun kautta. Laajakaista Tarkoittaa myös kotiin saatavaa internet-yhteyttä, jonka nopeus on tavallisesti vähintään 256 kbit/s. Lähdepuu On ryhmälähetyksessä käytetty ryhmän rakenne, jossa jokaiselle lähettäjälle luodaan oma ryhmälähetyspuu. Lähettäjä on puun juurisolmu. Linux On Unixin tapainen käyttöjärjestelmän ydin, jonka kehitystyö aloitettiin 90-luvun alussa. Linuxilla tarkoitetaan tavallisesti kokonaista käyttöjärjestelmää tai levitysversiota, joka sisältää käyttöjärjestelmän lisäksi myös sovelluksia. Linux on vapaa ohjelmisto, joten kuka tahansa voi tehdä siihen muutoksia. MANET On lyhenne sanoista Mobile Ad hoc NETwork. MANET on mobiililaitteista koostuva ad hoc -verkko. MAODV On lyhenne nimestä Multicast Operation of the Adhoc On-Demand Distance Vector Routing. MAODV on puumaiseen rakenteeseen perustuva MANET protokolla, joka on ryhmälähetyksiin soveltuva laajennus AODV:stä. Mesh Tarkoittaa tässä tutkielmassa rakennetta, joka koostuu joukosta toisiinsa yhdistettyjä solmuja. Solmuilla on useita reittejä toisiinsa, jolloin rakenne on eräänlainen verkko. Mesh-rakenne sisältää silmukoita, toisin kuin puurakenne. Mobiililaite Tietotekniikassa mobiililaitteella tarkoitetaan laitetta, jolla pystyy suorittamaan tietojen käsittelyä ja joka voi liikkua paikasta toiseen. Käytetään myös termiä mobiili tietojenkäsittelylaite. ii

5 Monarch -projekti On lyhenne sanoista MObile Networking ARCHitectures. Monarch on yhdysvaltalaisen Riceyliopiston projekti, joka tutkii ja kehittää mobiililaitteiden verkkoprotokollia. MPEG On lyhenne sanoista Moving Picture Experts Group. MPEG on kuvan ja äänen pakkaamiseen kehitetty standardi. MPEG-4 on uusin versio standarista. Ns-2 On lyhenne nimestä Network Simulator 2. Ns-2 on tietoliikenteen verkkosimulaattori, jonka koodi on vapaasti saatavilla. Simulaattoria käytetään niin tavallisen kuin langattomankin verkon protokollien simulointiin. Ryhmälähetys, engl. multicast Tarkoittaa viestimistä jollekin tietylle, rajatulle ryhmälle. ODMRP On lyhenne nimestä On-Demand Multicast Routing Protocol. ODMRP on mesh-rakenteeseen perustuva, itsenäisesti toimiva ryhmälähetysprotokolla MANETympäristöön. Proaktiivinen reititysprotokolla Protokolla, joka pyrkii ylläpitämään reaaliaikaista tietoa reiteistä verkossa. Puu, puumainen rakenne On tietorakenne, joka koostuu solmuista ja niitä yhdistävistä kaarista. Solmut jakaantuvat kahteen ryhmään: isäntä- ja lapsisolmuihin. Isäntäsolmulla voi olla useita lapsisolmuja, jotka ovat yhdistetty siihen, mutta lapsisolmut eivät ole yhdistetty toisiinsa. Puun juurisolmu ei ole minkään muun solmun lapsisolmu. Puu ei sisällä silmukoita, eli jokaiseen solmuun on olemassa täsmälleen yksi reitti. Reaktiivinen reititysprotokollvittaessa. Protokolla, joka etsii reitin kohteeseen vasta reittiä tar- Reititin Ohjaa tietoliikennettä verkossa viestivien osapuolten välillä. Simplex Tarkoittaa kommunikaatiota, jossa signaali kulkee yhteyden osapuolten välillä vain toiseen suuntaan. iii

6 Solmu Suoratoisto, engl. streaming TCP/IP Topologia Unicast Unix VoD VoIP Ydin, engl. kernel Tietotekniikassa termiä käytetään kuvaamaan tietoverkon laitetta, joka on jonkin tiedonsiirtomedian välityksellä yhteydessä toisiin solmuihin. Tässä tutkielmassa on solmun synonyymeinä käytetty myös mobiililaitetta ja reititintä. Tarkoittaa tiedonsiirtotapaa, jossa tiedoston sisältöä aletaan esittää käyttäjälle ennen kuin koko tiedosto on tullut perille. Suoratoistoa käytetään tavallisesti videokuvan katsomiseen tai äänen kuunteluun internetin avulla. DARPA:n kehittämä joukko protokollia (protokollapino), joita Internetin laitteet käyttävät viestimiseen. Kuvaa verkon solmujen yhteyksiä toisiinsa, verkon muotoa. Eli mitkä solmut ovat yhteydessä mihinkin solmuihin. On yhdeltä-yhdelle viestimista. Unicast on tavallisin viestimismuoto verkon laitteiden välillä Internetissä. On laitteistoriippumaton käyttöjärjestelmä, jonka kehitystyö aloitettiin 60-luvun lopulla. Unix on laajalti käytössä esimerkiksi palvelinkoneissa internetissä. On lyhenne sanoista Video on Demand. Tarkoittaa videodatan vastaanottamista tietoliikenneverkon välityksellä tarpeen mukaan. On lyhenne sanoista Voice over Internet Protocol. Tarkoittaa äänen (tavallisesti puheen) reaaliaikaista välitystä internetin välityksellä. On tietokoneen käyttöjärjestelmän keskus, joka mahdollistaa käyttöjärjestelmän muiden osien toiminnan. iv

7 Sisältö Sanasto i 1 Johdanto Tutkimusongelma Aiempia tutkimuksia Tutkielman rakenne Ryhmälähetys Ryhmälähetysen tarve Ryhmälähetyksen reititys Ryhmien muodostus Ryhmälähetyspuut Lähdepuut Jaetut puut Hybridimallit Mobiilit ad hoc -verkot Yleistä ja käyttökohteita Solun sisäinen dataliikenne Dataliikenne solun ulkopuolelle Reititys mobiileissa ad hoc -verkoissa Reitityksen haasteet Proaktiivinen reititys Reaktiivinen reititys Ryhmälähetys MANET:issa Yleistä Ryhmien rakenteet Protokollien perustyypit CAMP Reititysinformaatio Ryhmään liittyminen ja ryhmästä poistuminen Topologian muutokset v

8 4.5 ADMR Pakettien välittäminen Reititysinformaatio Lähettäjäksi tuleminen Ryhmään liittyminen ja ryhmästä poistuminen Topologian muutokset ja puun korjaustoimenpiteet MAODV Unicast-toiminto (AODV) Reititysinformaatio Pakettien lähettäminen Ryhmään liittyminen ja ryhmästä poistuminen Puun korjaus Puiden yhdistäminen ODMRP Reititysinformaatio Liittyminen ja ryhmälähetys Ryhmästä poistuminen ja topologian muutokset Ryhmälähetysprotokollien vertailua Kvalitatiivinen vertailu Simulaatioympäristö Solmujen liikkumisskenaariot Kommunikaatioskenaariot Mitattavat arvot Protokollavalintojen perustelut Vaatimukset suorituskyvystä Protokollien vertailu Tulokset Ryhmän koon vaihtelu Ryhmien määrän vaihtelu Johtopäätökset Yhteenveto 59 Viitteet 60 vi

9 1 Johdanto Nopeiden internet-yhteyksien määrä on kasvanut viime vuosina valtavasti. Samoin markkinoille tulee yhä uusia sovelluksia, jotka vaativat nopeaa yhteyttä. Esimerkkejä näistä ovat esimerkiksi videoneuvottelu, televisio-ohjelmien katsominen ja erilaiset moninpelit. Kaikkien edellämainittujen sovellusten liikennöinti verkossa noudattaa samanlaista kaavaa: lähettäjä välittää dataa jollekin ryhmälle vastaanottajia. Tästä syystä onkin kehitetty ryhmälähetystekniikka, jolla edellä mainitun kaltainen liikennöinti saadaan toteutettua mahdollisimman vähällä vaivalla. Mobiililaitteet ovat myös nykyään kasvattaneet suosiotaan, kun perinteisen internetin sovelluksista ja palveluista tehdään mobiiliversioita. Laitteille kehitetään jatkuvasti myös täysin uudentyyppisiä sovelluksia, jotka on kehitetty nimenomaan niille. Mobiili ad hoc-arkkitehtuuri on keino, jolla (yleensä) langattomat laitteet voivat muodostaa keskenään toimivan verkon. Mobiilissa ad hoc -verkossa (MANET) kaikki mobiililaitteet (eli solmut) ovat sekä päätelaitteita että reitittimiä. Ryhmälähetyksen toteuttamista MANET:issa ei ole tutkittu vielä kovin paljoa, pääpainon ollessa tavallisten yhdeltä yhdelle -protokollien tutkimuksessa. Ryhmälähetysprotokollia on toki kehitetty, mutta on vielä paljon kehitettävää. 1.1 Tutkimusongelma Palveluiden laadun hallinta laajakaistaverkoissa (Palhala) -hanke Jyväskylän yliopiston Tietotekniikan laitoksella [19] on kehittänyt palveluita laajakaistaisten IPverkkojen asiakkaiden käyttöön. Palveluihin kuuluu mm. VoIP (engl. Voice over Internet Protocol), VoD (engl. Video on Demand) ja IP-TV (engl. Internet Protocol Television). Palveluissa datan lähetys saadaan toteutettua käyttämällä ryhmälähetystekniikkaa, joka on tietoliikennekaistaa säästävä tapa lähettää dataa yhdeltä taholta monelle vastaanottajalle. Palhala-hankkeessa haluttiin lisäksi selvittää kehitettyjen palveluiden laajentamismahdollisuuksia mobiililaitteisiin. Tästä seurasi tarve tälle pro gradu -tutkielmalle. Tässä tutkielmassa halutaan selvittää olemassaolevien ryhmälähetysprotokollien soveltuvuus IP-TV -datan lähetykseen mobiilissa ad hoc -verkossa. Tarkoituksena ei ole antaa vastausta kaikkien kehitettyjen ryhmälähetysprotokollien soveltuvuudesta, 1

10 vaan valita muutama toimintaperiaatteeltaan toisistaan poikkeava protokolla ja tutkia niitä. Valitut protokollat ovat: Core Assisted Mesh Protocol (CAMP) [6], Adaptive Demand-Driven Multicast Routing Protocol (ADMR) [7] [8], Multicast Operation of the Ad-hoc On-Demand Distance Vector Routing (MAODV) [10] ja On-Demand Multicast Routing Protocol (ODMRP) [11]. Soveltuvuutta selvitetään simuloimalla IP-TV -liikennettä ns-2 -verkkosimulaattorilla [16] ja simuloimalla protokollien toimintaa. Tutkittavista protokollista karsitaan kaksi simuloitavaksi. Karsinta perustuu muiden vertailevien tutkimusten tuloksiin. 1.2 Aiempia tutkimuksia Valittujen protokollien reitityksen suorituskykyä on arvioitu dokumenteissa [6] [7] [10] [11] ja näitä protokollia on vertailtu keskenään tutkimuksissa [12] [13] [14]. Kaikkia neljää tässä tutkielmassa esiintyvää protokollaa ei ole vertailtu samassa tutkimuksessa keskenään, joten simulointiin valittavat protokollat karsitaan tietojen perusteella, jotka on saatu yhdistelemällä vertailevien tutkimusten tuloksia. Edellä mainituissa tutkimuksissa protokollien toimintaa ja suorituskykyä on selvitetty käyttämällä pientä dataliikennemäärää, joka ei vastaa todellisen verkon liikennettä. Tutkimusten päätarkoitus on ollut vertailla protokollien reitityskykyä, eikä niinkään niiden soveltuvuutta jonkin sovelluksen tarpeisiin. Tässä tutkielmassa on tarkoitus selvittää protokollien soveltuvuutta tietylle sovellukselle (IP-TV), joten tarve uudelle vertailevalle tutkimukselle on perusteltu. 1.3 Tutkielman rakenne Luku 2 käsittelee ryhmälähetystä. Luvussa esitetään, miksi sitä tarvitaan ja periaatteet sen toteuttamiseksi. Luvussa 3 selvitetään, mikä on mobiili ad hoc -verkko ja miten reititys toteutetaan siinä. Luku 4 esittelee ryhmälähetyksen toteutusta mobiilissa ad hoc -verkossa. Luvussa esitetään kaksi erilaista ryhmän luomistapaa, sekä muutamia mobiileissa ad hoc -verkoissa toimivien ryhmälähetysprotokollien perustyyppejä. Luvun lopuksi tutustutaan hieman tarkemmin neljään erilaiseen ryhmälähetysprotokollaan. Viimeisessä luvussa esitetään tuloksia ja johtopäätöksiä kahden ryhmälähetysprotokollan kokeellisesta vertailusta keskenään. 2

11 2 Ryhmälähetys Ryhmälähetys (engl. multicast) tarkoittaa viestintää tietylle ennaltamäärätylle joukolle, joka on yksilöity joukolle yhteisellä osoitteella. Tässä luvussa selvitetään aluksi, miksi ryhmälähetys on tietyissä tapauksissa tarpeellista. Sen jälkeen vertaillaan ryhmälähetyksen eroa normaaliin pakettien lähetystapaan internetissä. Lopuksi tutustutaan pintapuolisesti ryhmien muodostamiseen ja ryhmälähetyspuihin [2]. 2.1 Ryhmälähetysen tarve Suurin osa TCP/IP-protokollapinoa käyttävästä tietoliikenteestä on yhdeltä yhdelle (engl. unicast)-liikennettä. Siinä yksi lähettäjä lähettää yhdelle vastaanottajalle paketteja. Lähettäjällä ja vastaanottajalla on molemmilla omat IP-osoitteensa, joiden perusteella paketit reititetään perille. Toinen, vähemmän käytetty tapa on lähettää dataa kaikille laitteille (engl. broadcast) erityisellä yleislähetysosoitteella varustetulla viestillä. Tällaista viestiä kutsutaan levitysviestiksi. Esimerkiksi ns. nettipeleissä, sekä videoneuvotteluissa ja televisio-ohjelmien lähetyksessä internetin välityksellä yksi taho (palvelin tai tavallinen tietokone) joutuu lähettämään täsmälleen saman datan monelle vastaanottajalle. Perinteisin menetelmin lähetys voitaisiin toteuttaa siten, että sama data lähetettäisiin unicast-menetelmällä jokaiselle vastaanottajalle erikseen (kuva 2.1). Koska esimerkiksi reaaliaikaisen videokuvan välitys vaatii melko suurta tiedonsiirtokaistaa, ei tällainen monistaminen ole toivottavaa. Toinen keino olisi välittää videokuva levitysviestinä (kuva 2.2), jolloin datan lähettäjän ei tarvitse tehdä monistusta. Nyt videokuva välittyy koko verkolle. Kaikki laitteet eivät kuitenkaan välttämättä halua vastaanottaa dataa, jolloin syntyy turhaa liikennettä verkossa. Lisäksi levitysviestejä ei tietoturva- ja kaistansäästösyistä juurikaan päästetä aliverkkojen ulkopuolelle, joten edellä mainitut sovellukset eivät käytännössä voi lainkaan käyttää yleislähetystä. Koska unicast ja levitysvistit eivät sovi hyvin datan lähettämiseen vastaanottajajoukolle, on ollut tarpeen kehittää menetelmä juuri tätä tilannetta varten. Menetelmää kutsutaan ryhmälähetykseksi ja sen periaate muistuttaa hieman yleislähetystä. Lähettäjän tarvitsee lähettää dataa vain yhteen, ryhmän yksilöivään ryhmälähetysosoitteeseen, jolloin vältetään datan monistaminen. Verkko osaa nyt osoitteen pe- 3

12 Kuva 2.1: Unicast-lähetys. Kuva 2.2: Lähetys levitysviestinä. rusteella välittää dataa vain sellaisille laitteille, jotka sitä tarvitsevat. Näin vältetään ylimääräistä kuormitusta. 2.2 Ryhmälähetyksen reititys Internetiin yhteydessä olevat tietokoneet on jaoteltu eri kokoisiin aliverkkoihin. Tällä tavoin saadaan esimerkiksi eri maantieteellisillä alueilla ja eri organisaatioiden laitteet pidettyä loogisella tasolla erillään. Toinen tärkeä syy aliverkotukseen on rajallisen IP-osoiteavaruuden saaminen riittämään yhä kasvaville laitemäärille. Internetin arkkitehtuuri koostuukin aliverkoista ja niitä yhdistävistä reitittimistä. Reitit- 4

13 timien tehtävänä on hallita liikennettä verkossa siten, että periaatteessa kaikki verkkoon kytketyt laitteet pystyvät viestimään toisilleen. Reitittimet pitävät yllä enemmän tai vähemmän reaaliaikaista tietoa verkon topologiasta ja pystyvät siten ohjaamaan tietoliikennettä lähettäjiltä vastaanottajille. Kuva 2.3: Ryhmälähetys. Ryhmälähetyksessä kaistan säästöä saavutetaan muodostamalla lähettäjästä ja vastaanottajista joukko, jolla on puumainen rakenne. Puun juurena on lähettäjä (täsmällisemmin sanottuna juurisolmu on reititin, jonka liityntään lähettäjä on kytketty) ja alisolmuina ovat muut ryhmälähetykseen osallistuvat reitittimet. On tärkeää huomioida, että kaikki verkon reitittimet eivät välttämättä tue ryhmälähetystä, eivätkä siten voi olla osallisena reitityspuussa, vaikka niillä olisikin muuten yhteys ryhmälähetystä vastaanottaviin solmuihin/laitteisiin. Nämä voivat olla joko suorassa yhteydessä vastaanottajiin tai ovat yhteydessä toisiin ryhmälähetykseen osallistuviin reitittimiin. Solmulla voi olla yksi tai useampi alisolmu. Jokainen reititin monistaa saamiaan ryhmälähetysviestejä vain niin monta kuin sillä on suoria alisolmuja. Puumaisella rakenteella saavutetaan näin oleellista hyötyä: yhdelläkään reitittimien välisellä linkillä ei esiinny samaa viestiä kahta kertaa, eikä viesti voi saapua solmulle useampaa kuin yhtä reittiä. Tämän seurauksena verkossa liikkuu täsmälleen tarvittava määrä viestejä, jotta kaikki vastaanootajat saava niille kuuluvat ryhmälähetysviestit. Lisäksi reitittimien reitityspäätökset yksinkertaistuvat: jos reitittimellä on alisolmuja, välitetään viesti niille aina. Kuvassa 2.3 on esitetty yksinkertainen ryhmälähetysreititystä käyttävä verkko ja siihen liittyvä reitityspuu. 5

14 2.3 Ryhmien muodostus Jotta halukkaille vastaanottajille voitaisiin lähettää dataa ryhmälähetyksenä, on niistä ensin koottava ryhmä ja annettava sille osoite. Aloitteen ryhmän luomiseksi tekee se laite, joka haluaa lähettää ryhmälähetyspaketetteja. Reitittimestä, johon aloitteen tekevä laite on kytketty, tulee luotavan reitityspuun juurisolmu. Halukkaat vastaanottajat lisätään juurisolmun alisolmuiksi. Alisolmujen lisäykseen on olemassa kaksi tapaa: ns. datapohjainen (engl. data-driven) ja vastaanottajapohjainen (engl. receiver-driven). Datapohjaisessa menetelmässä juurisolmu lähettää tasaisin väliajoin ryhmälähetysviestejä ns. tulvimismenetelmällä, jolloin kaikki verkon laitteet saavat viestit. Jos laite ei halua vastaanottaa ryhmälähetystä, on sen ilmoitettava siitä erikseen lähimmälle reitittimelle (solmulle). Reititin harventaa (engl. prune) tällöin itsensä puusta, jos yksikään siihen kytketyistä laitteista ei halua vastaanottaa ryhmälähetystä. Harvennuksella estetään turhaa ryhmälähetystä laitteille, jotka eivät sitä vastaanota. Datapohjainen menetelmä on käyttökelpoinen, jos suurin osa verkon laitteista haluaa vastaanottaa ryhmälähetystä. Tällöin ryhmälähetyksen tulvinta koko verkkoon ei tuhlaa liikaa kaistaa. Vastaanottajapohjaisessa menetelmässä jokaisen laitteen tulee ilmoittaa, jos se haluaa vastaanottaa ryhmälähetystä. Laitteille ei siis ohjata ryhmälähetysviestejä ennen kuin laite on halukkuudestaan erikseen ilmoittanut. Ryhmälähetyspuuta kasvatetaan solmu kerrallaan tarpeen mukaan. Puun harvennus on usein ajastimiin perustuvaa, jossa solmu poistetaan, jos siltä ei ole tullut määräajan sisällä ilmoitusta halukkuudesta vastaanottaa ryhmälähetystä. Laitteiden tuleekin lähettää toistuvasti ilmoitus pysyäkseen osana ryhmälähetystä vastaanottavaa ryhmää. Vastaanottajapohjainen menetelmä soveltuu paremmin sellaisille verkoille, joissa ryhmälähetystä vastaanottavien reitittimien osuus on pieni. Jokaiselle ryhmälle annetaan oma ryhmälähetysosoite, jonka perusteella ryhmät voidaan erottaa toisistaan. Ryhmän jäsenet käyttävät tätä osoitetta lähettääkseen ryhmälähetysviestejä ja verkon reitittimet osaavat osoitteen perusteella välittää viestit jokaiselle ryhmän jäsenelle. Osoitteeksi valitaan kullekin ryhmälle jokin IP-osoiteavaruuden ryhmälähetysosoitteille varatuista IP-osoitteista. 2.4 Ryhmälähetyspuut Ryhmälähetyspuu kuvaa kaikkia linkkiyhteyksiä, joita pitkin ryhmälähetysviestit kulkevat lähettäjältä kaikille vastaanottajille. Solmun (reitittimen) kannalta on sa- 6

15 ma, millainen alipuu reitittimen lapsisolmujen alla on. Reitittimelle riittää siis vain tieto, että lapsisolmu vastaanottaa ryhmälähetysviestejä, jolloin se lähettää yhden viestin kutakin lapsisolmuaan kohti. Ryhmällä voi aina olla joko yksi tai useampi lähettäjä sekä yksi tai useampi vastaanottaja. On olemassa kaksi eri tyyppistä ratkaisua reitityspuun määrittelemiseksi: lähdepuut (engl. source-based tree) ja jaetut puut (engl. group shared trees) Lähdepuut Tässä ratkaisussa jokaiselle ryhmän lähettäjälle muodostetaan oma reitityspuunsa, jossa lähettäjä on juurena. Reitit lähettäjältä vastaanottajille ovat edullisimpia mahdollisia. Tavallisesti edullisin reitti on sellainen, jossa viestin välitys lähettäjältä kohteisiin vie vähiten aikaa. Jos ryhmässä on N kappaletta ryhmäviestejä lähettäviä laitteita, muodostuu ryhmälähetyspuita myös N kappaletta. Lähdepuumenetelmän heikkous piilee juuri tässä, koska jokainen ryhmälähetysreititin pitää yllä reititystietoja jokaisen ryhmän jokaisesta reitityspuusta. Tämän vuoksi ylläpidettävä reititystieto kasvaa helposti hyvin suureksi, joka vaikuttaa suoraan mm. muistin kulutukseen reitittimillä. Reitittimet saattavat aika ajoin ilmoittaa isäntäsolmulleen, minkä kaikkien ryhmän lähettäjien viestejä se vastaanottaa. Tämä tietää lisää ylimääräistä liikennettä, varsinkin jos ryhmillä on useita lähettäjiä. Kuvassa 2.4 on esitetty kolme reititintä sisältävän ryhmän lähdepuu, jossa A on lähettäjä. Solmut ovat kuvan 2.3 reitittimiä Jaetut puut Jaetussa puussa jokaista ryhmää kohti muodostetaan vain yksi reitityspuu. Verkon reitittimistä valitaan yksi reititin eräänlaiseksi keskukseksi, jonka kautta kaikki ryhmälähetysviestit kulkevat. Jaetun puun juurena on valittu keskusreititin. Jokainen lähettäjä lähettää ensin viestinsä keskusreitittimelle, joka ohjaa viestit kaikille ryhmän vastaanottajille. Nyt jokaisen verkon reitittimen tarvitsee kutakin ryhmää kohti tietoa vain yhdestä reitityspuusta, koska viestit ovat lähtöisin aina samalta solmulta lähettäjästä riippumatta. Vastaanottajien ilmoittaminen isäntäsolmuille hoituu nyt pienemmällä informaatiolla kuin lähdepuumenetelmässä. Haittapuolena jaetussa puussa on reitityspuun toiminnan riippuvuus yhdestä solmusta, eli keskusreitittimestä. Verkon liikenne keskittyy yhdelle reitittimelle, jolloin sen ylikuormittuminen tai vaikkapa vikaantuminen pahimmillaan lamaannuttaa ryhmäviestien levityksen. Toinen heikkous jaetulla puulla on ei-optimaaliset reitit lähettäjiltä vastaanottajille. Esimerkiksi toistensa naapurina olevat reitittimet eivät välttämättä voi lähettää 7

16 toisilleen ryhmälähetysviestejä suoraan, vaan viestit on kierrätettävä keskusreitittimen kautta. Tämä aiheuttaa tietenkin viivettä. Edellämainittuja haittoja voidaan minimoida huolellisella keskusreitittimen valinnalla ja määrittämällä varallaolevia keskusreitittimiä. Hyvin valittu keskusreititin takaa mahdollisimman tasapuolisen viiveen jokaiselle vastaanottajalle. Kuvassa 2.4 näkyy sama kolmen lähettäjän ryhmä toteutettuna jaetulla puulla. Solmut ovat kuvan 2.3 reitittimiä. Kuva 2.4: Lähde- ja jaettu puu Hybridimallit Jaettua puuta käyttävä malli, jossa solmujen liittäminen toteutetaan vastaanottajapohjaisesti on todettu nykyään käytännössä parhaimmaksi. Joskus ryhmälähetysliikenteen jakautuminen verkossa voi olla sellaista, että olisi edullisempaa käyttää lähdepuita. Jos esimerkiksi reititin X havaitsee, että se vastaanottaa lähes kaiken datansa samalta lähettäjältä, voidaan solmun ja lähettäjän väliin luoda lähdepuu. Puun juurisolmuna on tällöin lähettäjä ja muina solmuina ovat solmun X ja lähettäjän välillä olevat reitittimet. Tällöin dataa ei tarvitse kierrättää keskussolmun kautta, jolloin viestityksen viive pienenee ja kaistaa säästyy. 8

17 3 Mobiilit ad hoc -verkot Termi ad hoc on peräisin latinan kielestä ja tarkoittaa tarkoituskohtaista. Tietotekniikassa termillä tarkoitetaan sellaista tietoverkkoa, jonka jäsenenä voidaan olla tarvittaessa vain väliaikaisesti [1]. Jäsenyys voi kestää esimerkiksi verkkoa tarvitsevan sovelluksen käynnissäoloajan. Langattomien laitteiden ollessa kyseessä verkon jäsenyys voi kestää niin kauan kuin laite on viestimiskantaman sisällä ad hoc -verkosta. Ad hoc -verkoille on ominaista, että niiden solmut järjestäytyvät verkoksi omatoimisesti ilman minkään keskuslaitteen ohjausta. Verkkoon voidaan liittyä ja siitä voidaan poistua vaivattomasti ja nopeasti. Mobiili ad hoc -verkko (engl. Mobile Ad hoc NETwork, MANET) on mobiililaitteista koostuva ad hoc -verkko. MANET:issa kaikki verkon solmut toimivat myös reitittiminä normaalin viestien lähetyksen ja vastaanottamisen lisäksi. Tutkielman loppuosassa reititintä, mobiililaitetta ja solmua käytetään tarkoittamaan samaa asiaa. Mobiililaitteet ovat useimmiten langattomia päätelaitteitä, mutta MANET voi sisältää myös langallisiakin laitteita, kunhan ne vain pystyvät liikkumaan. Tästä eteenpäin käsitellään nimenomaan mobiileja ad hoc -verkkoja. Ensin selvitetään MANET:in historiaa, sekä nykysiä ja tulevia käyttökohteita. Sen jälkeen tutustutaan reititykseen MANET:issa. 3.1 Yleistä ja käyttökohteita Mobiili ad hoc -verkkoarkkitehtuuri on alunperin kehitetty sotilastarkoituksiin. Yhdysvaltain puolustusministeriön organisaation DARPA:n (Defense Advanced Research Projects Agency) tuli kehittää armeijan tarpeisiin tietoverkko, jonka tulee pystyä toimimaan vaativissa taistelukenttäolosuhteissa. Verkon solmut ovat tällöin joko sotilaita tai sotilasajoneuvoja. Solmujen ei voi olettaa pysyvän paikoillaan, ja niiden väliset yhteydet saattavat mennä usein poikki. Verkon tulee myös pystyä toimimaan ilman kiinteää tietoliikenneverkon infrastruktuuria, koska sitä ei yleensä ole taistelukentällä olemassa. DARPA:n kehittämä arkkitehtuuri on tullut sittemmin julkiseksi, joten sitä on voitu ryhtyä käyttämään myös muissa sovelluksissa, kuten esimerkiksi pikaiseen tietoliikenneverkon luomiseen katastrofialueella. Mobiililaitteiden erittäin nopea yleistyminen tuo tilanteita, joissa nopea ja helppo verkon muodostaminen laitteiden kesken on tarpeen. Joukko ihmisiä, esimerkiksi kaveriporukka, voi kohdata kau- 9

18 pungilla ja ryhtyä pelaaman jotain peliä mobiililaitteillansa tai heillä on jokin muu tarve vaihtaa tiedostoja keskenään. Luennolla voidaan tarvittava oppimateriaali lähettää luentosalissa oppilaiden mobiililaitteisiin MANET:n avulla. Erilaiset sensoriverkot ovat tärkeä käyttökohde ad hoc -verkolle. Yksittäisiä sensoreita on yleensä erittäin suuri määrä, eikä niitä kustannussyistä kannata yhdistää kiinteällä kaapelilla tai sensorien sijainti estää kaapeloinnin täysin. Verkon kykeneminen jokaisen solmunsa automaattiseen konfigurointiin on suuri etu, koska sensoriverkon manuaalinen konfigurointi olisi erittäin työlästä. Nykyisten matkapuhelinverkkojen kapasiteettia pystyttäisiin parantamaan MANET:in avulla. Matkapuhelinverkko koostuu useista pienemmistä soluista. Kaikki tietoliikenne solun alueella kulkee solun tukiaseman kautta, riippumatta lähettäjän ja vastaanottajan sijainnista. Ne voivat sijaita eri soluissa eri mantereilla tai samassa solussa metrin päässä toisistaan. Tukiasema muodostuu pullonkaulaksi, kun matkapuhelinten määrä ja tiedonsiirtomäärät solussa lisääntyvät. Internet-yhteyttä käyttävät sovellukset ovat lisääntyneet matkapuhelimissa viime aikoina. Ne kuluttavat matkapuhelimen tiedonsiirtokaistaa yleensä huomattavasti enemmän kuin tavalliset puhelut. Seuraavaksi havainnollistetaan kahdella esimerkillä, miten mobiilia ad hoc -verkkoa hyväksikäyttämällä voidaan soluverkkojen tukiasemien taakkaa keventää [5] Solun sisäinen dataliikenne Otetaan esimerkkinä tilanne, jossa henkilö A haluaa lähettää ottamansa valokuvan B:lle matkapuhelimellaan. Henkilöt ovat töissä samassa rakennuksessa, mutta eivät pääse tapaamaan toisiaan, jotta he voisivat suorittaa tiedonsiirron infrapunalinkillä. Niinpä A päättää lähettää kuvan sähköpostin liitetiedostona. Sähköposti siirtyy radiotietä pitkin tukiasemalle, sieltä kiinteää verkkoa pitkin internetiin A:n ja B:n sähköpostipalveluihin. Aikanaan sähköposti saapuu B:lle saman tukiaseman välityksellä (kuva 3.1). Jos taas käytettäisiin hyväksi MANET:ia, ei tukiaseman tarvitsisi osallistua em. datan siirtoon ollenkaan. A voisi ottaa B:hen yhteyden mobiililaitteiden C ja D välityksellä. Myös tavallisia solunsisäisiä puheluita voitaisiin välittää MANET:n kautta (kuva 3.2) Dataliikenne solun ulkopuolelle Jos mobiililaitteiden tietoliikenne ei kohdistu toisiinsa, vaan esimerkiksi palvelimille internetissä, on tilanne hieman erilainen. Nytkin MANET:ista voi olla hyötyä ver- 10

19 Kuva 3.1: Perinteinen solun sisäinen datan siirto. Kuva 3.2: Datansiirto solun sisällä ad hoc -periaatteella. rattuna tilanteeseen, jossa kaikki laitteet liikennöisivät tukiaseman kautta. Nyt voidaan muodostaa ad hoc -verkko, jossa osa mobiililaitteista toimii ns. pääsypisteinä internetiin (engl. access point). Pääsypisteet toimivat eräänlaisina ylimääräisinä tukiasemina, joiden kautta osa soluverkon mobiililaitteista voisi olla yhteydessä internetiin. Tämä vähentäisi varsinaisen tukiaseman kuormitusta. Pääsypisteillä tulee itsellään olla jokin muu yhteys internetiin kuin soluverkon tukiasema, esimerkiksi kiinteä verkkoyhteys. Kannettavat tietokoneet, joissa on langaton tukiasema voisivat olla tällaisia pääsypisteitä. 11

20 3.2 Reititys mobiileissa ad hoc -verkoissa Jotta datan lähettäminen verkon yli onnistuisi, on jokaisen reitittimen pystyttävä ohjaamaan datapaketit kohti haluttua vastaanottajaa. Tämän takaamiseksi tarvitaan jokin reititysprotokolla. Reititysprotokollan tulee pystyä suoriutumaan kahdesta tehtävästä: reitin löytämisestä ja reitin ylläpitämisestä. Aina kun verkon linkkien tila muuttuu lähettäjän ja vastaanottajan välillä, on mahdollisesti etsittävä uusi reitti. Reitin löytäminen aiheuttaa aina jonkinasteisen viiveen viestityksen alussa, ja reitin ylläpito kuormittaa tavallisesti verkkoa ylimääräisillä signalointiviesteillä. Kiinteässä verkossa, eli sellaisessa jossa solmut eivät liiku, eikä solmujen välisissä yhteyksissä tapahdu useinkaan muutoksia, reitittimet pyrkivät yleensä pitämään itsellään mahdollisimman reaaliaikaista tietoa verkon topologiasta, koska verkon kaista ei kuormitu tarvittavista signalointiviesteistä liikaa. Mobiili ad hoc -verkko on kuitenkin luonteeltaan erilainen kuin kiinteä verkko, joten edellä mainittu toimintatapa ei välttämättä ole siinä paras ratkaisu [3]. Kuvassa 3.3 on esitetty yksinkertainen useamman mobiililaitteen välinen yhteys ja käytetty reitti. Laitteella A ei ole suoraa yhteyttä laitteeseen B, koska A ja B eivät sijaitse toistensa kantamilla. Niinpä laitteet muodostavat yhteyden kulkemaan C:n, D:n ja E:n kautta. E C D Kuva 3.3: Yksinkertainen ad hoc -reititys Reitityksen haasteet Nopea ja satunnainen verkon topologian muuttuminen on suurin haaste reititykselle MANET:issa. Seuraavassa on lueteltu syitä topologian muutoksiin. Solmujen liikkuvuus. Suuri osa mobiilisolmuista on todennäköisesti liikkees- 12

21 sä, jolloin yhteyksiä naapureihin katkeaa ja samalla uusia yhteyksiä muodostuu uusiin naapureihin. Langattomien laitteiden ollessa kyseessä yhteys naapuriin katkeaa useimmiten laitteen liikuttua pois kantamalta. Solmujen liikkuvuus on vain harvoin täysin satunnaista. Tavallisesti liikkuvuus noudattaa jotain tietynlaista mallia. Reititysprotokollan olisi hyvä ottaa liikkuvuuden malli huomioon, jolloin topologiamuutoksia pystyttäisiin ennakoimaan. Solmujen rajallinen käyttöaika. Suurin osa mobiililaitteista saa virtansa akuista, joten laitteet eivät voi olla rajattomiin päällä. Laitteen sammuminen virran loputtua irrottaa myös solmun verkosta. Langaton laite saattaa myös akkujen heikettyä siirtyä säästämään virtaa, jolloin se pienentää lähetystehoaan. Tällöin kantama pienenee ja solmun yhteys osaan sen naapureista katkeaa. Langattomien laitteiden lähettämän datan määrä vaikuttaa merkittävästi sen akkujen kestoon, koska langaton lähetys vie helposti suuren osan virrasta. Nykyisillä mobiililaitteilla lähetin ei ole välttämättä suurin tehokuluttaja normaalikäytössä, mutta MANET:issa tilanne saattaa muuttua. Laite saattaa sijaita keskeisellä paikalla verkossa, jolloin sen kautta kulkee paljon muun verkon liikennettä. Myös käytetyn reititysprotokollan reitinhaku ja -ylläpitotoimenpiteet voivat kuluttaa laitteen akkuja, etenkin solmujen liikkuvuuden ollessa voimakasta. Ympäristö ja solun maantieteellinen sijainti. Maantieteelliset esteet ja sääilmiöt aiheuttavat hankaluuksia radiotaajuiselle viestinnälle. Tämän johdosta vastaanotetun signaalin voimakkuus on lähes aina vain pieni murto-osa lähetetystä. Jo pienikin lähettäjän ja vastaanottajan suhteellinen liike saattaa aiheuttaa huomattavia vaihteluita vastaanotetun signaalin voimakkuudessa, jolloin yhteys saattaa pätkiä. Tämä ilmenee langattoman laitteen radiokantaman vaihteluina. Yhteys saattaa pätkiä myös laitteen ollessa paikallaan, jos laite sijaitsee sopivassa paikassa esimerkiksi jonkin häiriösignaaleita tuottavan laitteen lähellä. Voidaan olettaa, että suuri osa mobiileista ad hoc -verkoista sijaitsee urbaaneissa ympäristöissä. Tällainen ympäristö sisältää runsaasti esteitä ja häiriölähteitä radiosignaaleille. Asutusalueella nopeasti liikkuvat solmut ovatkin hankalia tapauksia reititysprotokollille. Solmujen vaihtuvuus. Ad hoc -verkon ominaisuuksiin kuuluu jo määritelmän perusteella, että siihen liittyminen ja siitä poistuminen on yksinkertaista. Mobiililaite saattaa liittyä verkkoon vain lähettääkseen yhden pienen tiedoston, jonka jälkeen se irroittautuu verkosta. Tällöin laitetta ei voida käyttää muun verkon liikenteen reititykseen kovin kauaa. 13

22 MANET sisältää muitakin uusia haasteita reititykselle verrattuna kiinteään verkkoon: Viestien yhteentörmäykset. Langattomat mobiililaitteet lähettävät dataa ikäänkuin levitysviestinä, koska kaikki laitteet kantaman sisällä kuulevat lähetyksen. Tällöin vastaanotin ottaa viestin vastaan, vaikka se ei olisikaan osoitettu kyseiselle laitteelle. Kuvitellaan tilanne, jossa solmun kaksi naapuria (A ja B) lähettää viestin yhtäaikaisesti. A osoittaa viestinsä solmulle, kun taas B ei. B:n lähetys saapuu solmulle hieman ennen A:n lähetystä, jolloin solmun vastaanotin ryhtyy vastaanottamaan B:n viestiä. Viestit ovat siis törmänneet solmun kohdalla, eikä solmu nyt kykene vastaanottamaan A:lta tullutta viestiä. Solmu havaitsee B:ltä tulleen viestin turhaksi heti kehyksen otsikon luettuaan. Mitä enemmän solmulla on naapureita, sitä yleisempiä törmäykset ovat. Törmäykset solmulla lisääntyvät myös, jos sen kautta kulkee paljon verkon muihin osiin menevää liikennettä. Tällöin solmu muodostaa helposti pullonkaulan verkkoliikenteelle. Tilanne on osin samanlainen kuin Ethernet-verkossa. Törmäykset ovat kuitenkin paljon haitallisempiä MANET:issa, koska siinä laitteiden tiedonsiirtokaista on tavallisesti hyvin rajoittunut. Suuri reittien määrä. Suuresta solmujen määrästä ja niiden levitysviesti-tyylisestä viestityksestä johtuen verkon solmujen välille syntyy helposti useita reittejä. Jos reititysprotokolla pitää yllä reaaliaikaista tietoa verkon topologiasta, kasvattavat ylimääräiset reitit reititystaulukoita. Ylimääräisten reittien olemassaolo voi olla myöskin etu reitityksen kannalta, koska reititys sietää nyt enemmän topologian muutoksia. Osa reititysprotokollista käyttääkin tätä hyväkseen. Epäsymmetriset linkkiyhteydet. Langattomissa verkoissa ei voida olettaa, että kahden viestivän osapuolen välinen yhteys olisi identtinen molempiin suuntiin. MANET:issa voi olla monia erilaisia langattomia laitteita, joilla on erivahvuiset lähetystehot. Lisäksi kahden identtisen laitteen välinen yhteys voi toimia vain toiseen suuntaan, jos jompikumpi laite on esimerkiksi jonkin häiriölähteen lähellä. Reitti kahden solmun välillä voi kulkea menosuuntaan eri solmujen kautta kuin paluusuuntaan. Useimmat olemassaolevat protokollat olettavat kuitenkin, että kaikki verkon linkkiyhteydet ovat symmetrisiä. Verkon osittuminen. Topologia saattaa verkossa muuttua siten, että verkko jakautuu useisiin pienempiin osiin, joilla ei ole toisiinsa yhteyttä. Solmut voivat 14

23 liikkua esimerkiksi ryhmissä, jolloin ryhmät saattavat poistua toistensa kantamilta. Verkossa saattaa olla myös joitain tärkeitä solmuja, joiden kautta kulkee kaikki liikenne eri verkon osien välillä. Näiden solmujen pettäminen jakaa verkon. Protokollan tulee pystyä muodostamaan jälleen reitit osien välille heti, kun niiden solmut tulevat taas toistensa kantamille Proaktiivinen reititys Kiinteissä verkoissa yleisimmin käytetty tapa reaaliaikaisen topologiatiedon hankkimiseen on, että kaikki reitittimet levittävät säännöllisesti reititystietojaan muille reitittimille. Tällaista tapaa sanotaan proaktiiviseksi reititykseksi. Topologiatiedot saatuaan reitittimet pyrkivät yhteisymmärrykseen parhaista reiteistä jokaiselta solmulta mihin tahansa muuhun solmuun. Tätä kutsutaan verkon yhtenemiseksi (engl. convergence). Kaksi hieman toisistaan eroavaa tapaa proaktiiviseen reititykseen on kehitetty: etäisyysvektoriin (engl. distance vector) ja linkkien tilaan (engl. link state) perustuvat algoritmit. Näistä etäisyysvektoriin perustuva on vanhempi, se oli käytössä jo alkuperäisessä ARPANET:issä. Kiinteissä verkoissa nykyisin yleisessä käytössä oleva OSPF (Open Shortest Path First) reititysprotokolla käyttää link state -algoritmia. Etäisyysvektoriin perustuvassa algoritmissa solmu ylläpitää tietoja etäisyyksistä kaikkiin verkon solmuihin. Näitä tietoja solmu lähettää määräajoin kaikille naapurisolmuilleen. Etäisyydet ilmoitetaan tavallisesti hyppyjen lukumäärinä (engl. hop count). Kun viesti kulkee yhden linkkiyhteyden yli, kutsutaan sitä yhdeksi hypyksi. Jos esimerkiksi viesti kulkee lähettäjältä vastaanottajalle kahden muun solmun kautta, tulee hyppyjen lukumääräksi kolme. Reititin saa siis jokaista kohdetta kohti kaikilta naapureiltaan etäisyyden kohteelle. Kun solmu on lähettämässä viestiä kohteelle, vertaa se saamiaan etäisyystietoja toisiinsa. Solmu lähettää viestin sen naapurin kautta, joka oli ilmoittanut pienimmän etäisyyden kohteelle. Kun tämä toistetaan jokaisella solmulla, kulkee viesti lyhintä reittiä vastaanottajalle. Algoritmin heikkouksia ovat hidas verkon yhteneminen, eli algoritmi sietää huonosti muutoksia verkon topologiassa. Toinen huono puoli on silmukoiden muodostuminen reititykseen, koska valitut reitit saattavat perustua vanhentuneisiin tietoihin etäisyysvektoreista. Linkkien tilaan perustuvassa algoritmissa jokainen solmu pitää yllä tietoja linkkiensä tiloista naapurisolmuihin. Solmu lähettää tietonsa kaikille muille verkon solmuille määräajoin. Jokainen verkon solmu saa siten tiedon koko verkon topologiasta. Jokainen reititykseen osallistuva reititin laskee paketin saatuaan parhaan reitin 15

24 kohteelle. Paketti lähetetään kohti vastaanottajaa sitä linkkiä pitkin, joka todettiin parhaaksi. Link state -reititys reagoi nopeammin verkon muutoksiin kuin edellinen tapa. Huonona puolena on suurempi laskentatehon tarve reitittimillä ja suurempi kaistan kulutus, koska jokainen solmu mainostaa linkkiensä tilaa koko verkolle. MANET:iin on kehitetty mainituin periaattein toimivia protokollia, kuten DSDV (Highly Dynamic Destination-Sequenced Distance Vector Routing Protocol) ja OLSR (Optimized Link State Routing Protocol). Proaktiivinen reititys soveltuu parhaiten kiinteälle, melko vähän solmuja sisältävälle verkolle. Vähäinen solmujen määrä on parempi, koska topologiatietojen lähetysviestien lukumäärä kasvaa eksponentiaalisesti solmujen määrään nähden. MANET on taas tyypiltään lähes päinvastainen se saattaa sisältää runsaasti jatkuvassa liikkeessä olevia solmuja. On huomattava, että topologiatietoja välitetään tavallisesti vakiomittaisin määräajoin. Tällöin ei ole mitään merkitystä, liikkuvatko solmut verkossa vähän vai paljon. Jos liikkuvuus on vähäistä, on osa signalointiviesteistä turhia, koska topologiassa ei ole tapahtunut muutoksia. Jos taas solmut ovat hyvin liikkuvia, eivät signalointiviestit pysy mukana topologian muutoksissa. Proaktiivisen reitityksen ehdoton vahvuus on viiveettömyys viestityksen aloittamisessa. Reitti vastaanottajalle on jo olemassa, joten solmu voi ryhtyä lähettämään dataa välittömästi. Heikkouksia ovat taas reititystaulujen muistin kulutus ja reittien laskemiseen kuluva laskentateho solmulla. Proaktiivinen reititys kuluttaa paljon kaistaa, koska jokainen solmu ilmoittaa kaikille naapureilleen tai koko verkolle reititystaulunsa tiedot. Mobiilisolmuilla on yleensä käytössä hyvinkin rajoitettu kaista, joten turhia viestejä on pyrittävä välttämään kaikin keinoin. MANET:issa suositaankin yleisesti ns. reaktiivista reititystä Reaktiivinen reititys Proaktiivinen reititys on todettu liian raskaaksi tavaksi vähänkin isommissa mobiileissa ad hoc -verkoissa. Lisäksi verkon yhteneminen ei ole riittävän nopeaa, jotta reittitiedot pysyisivät ajan tasalla vähänkin suuremmalla solmujen liikkuvuudella. Useissa reititysprotokollissa onkin luovuttu reaaliaikaisen topologiatiedon ylläpitämisestä. Reaktiivisessa reitityksessä reitti kohteelle etsitään vain tarvittaessa, eli kun jotain dataa on lähetettävänä. Lähettäjä laittaa liikkeelle reitinpyyntöviestin (engl. route request) lähettämällä sen kaikille naapureilleen. Naapurit välittävät pyyntöä edelleen omille naapureilleen, kunnes reitti kohteelle löytyy. Reitinpyyntöviestiä siis tulvitaan koko verkolle, kunnes reitti löytyy. Kohteen löydyttyä lähetetään reitin 16

25 vastausviesti (engl. route reply) takaisin lähettäjälle. Nyt reitti tunnetaan ja lähettäjä voi aloittaa pakettien lähettämisen. Reittiä ylläpidetään vain niin kauan kuin sitä tarvitaan. Ylläpitäminen toteutetaan tavallisesti ajastimilla ja reitin pitämisellä muistissa (engl. route caching). Reitin ajastin nollataan aina, kun sitä pitkin kulkee viestejä. Jos ajastinta ei nollata jonkin tietyn ajan kuluttua, poistetaan reitti muistista. Jos solmujen väliset yhteydet reitillä katkeavat, on reitillä suoritettava korjaustoimenpiteitä (engl. route repair tai route re-discovery). Yhteys vastaanottajaan pyritään korjaustoimenpiteillä saamaan uudestaan siten, että uusi reitti poikkeaisi mahdollisimman vähän vanhasta. Reitinkorjaus pyritäänkin suorittamaan niiden solmujen välillä, joiden yhteys toisiinsa on poikki. Reitityksen tehokkuuteen vaikuttaa kaksi keskeistä tekijää: (1) kuinka usein uusia reittejä pyydetään, ja (2) kuinka paljon reiteillä joudutaan tekemään korjaustoimenpiteitä. Jos verkon solmut lähettävät usein dataa, liikkuu verkossa paljon yhtäaikaisia reitinpyytöviestejä, koska jokainen pyyntöviesti tulvitaan koko verkon yli. Tällöin tapahtuu paljon viestien törmäämisiä, jolloin reittejä ei välttämättä löydetä vastaanottajille tai reitit ovat turhan pitkiä. Mitä enemmän reittejä pidetään muistissa, sitä paremmin selvitään useista reittipyynnöistä. Myös reittipyyntöjen suuntaaminen kohti vastaanottajaa auttaa vähentämään tulvinnasta johtuvaa kaistan kulutusta. Reitin korjaustoimenpiteitä taas joudutaan tekemään usein, jos solmut liikkuvat paljon. Saman viestimissession aikana voi lähettäjän ja vastaanottajan välinen yhteys katketa useammankin kerran. Lisääntyneet korjausviestit tuovat ylimääräistä liikennettä verkkoon. Parhaiten reaktiivinen reititys pärjää, kun uusia reittipyyntöjä tulee verkossa melko harvoin ja solmut eivät liiku paljoa. Reaktiivisen reitityksen hyviä puolia ovat pienempi kaistan kulutus proaktiiviseen menetelmään verrattuna useimmissa tapauksissa, sekä solmun muistin ja laskentatehon pienempi kulutus. Nämä ovatkin kriittisiä vaatimuksia MANET:issa. Huonona puolena voidaan pitää reitin etsimisestä aiheutuva viive viestityksen aloittamisessa. 17

26 4 Ryhmälähetys MANET:issa Kaikenlaisten mobiililaitteiden ja ryhmälähetystä tarvitsevien sovellusten yleistyessä on ollut järkevää keskittää tutkimustyötä mobiilien ad hoc -verkkojen ja ryhmälähetyksen yhdistämiseksi. Suurin osa nykyisistä kiinteän verkon ryhmälähetyssovelluksista voidaan lähitulevaisuudessa siirtää mobiililaitteisiin. Lisäksi mobiilius tuo aivan uusia sovellusmahdollisuuksia ryhmälähetykselle. Tutkimustyö on keskittynyt viime vuosina lähinnä MANET:in unicast-protokollien kehitykseen, ryhmälähetyksen jäädessä vähemmälle huomiolle. Unicast-protokollia ei ole suunniteltu selviämään ryhmälähetyksestä, eikä niitä kehittäessä olla juurikaan mietitty mahdollista laajennusta sitä varten. Kiinteän verkon ryhmälähetysprotokollia ei voida käyttää MANET:issa, koska niitä ei olla suunniteltu selviämään jatkuvista verkon topologian muutoksista. Ryhmälähetyspuut rikkoutuvat helposti ja niihin pitää tehdä usein muutoksia. Luvussa kerrotaan aluksi ryhmien muodostamisesta MANET-ympäristössä ryhmälähetystä varten. Sen jälkeen esitetään muutamia ryhmälähetysprotokollien perustyyppejä. Luvun loppuosassa selvitetään perusteet yhteensä neljästä eri periaatteilla toimivasta protokollasta. 4.1 Yleistä Ryhmälähetys ja reititys vaativat kumpikin toimiakseen tietoliikenneprotokollan. Protokollan toiminta kuormittaa aina verkkoa ja sen laitteita. Kun mobiiliin ad hoc -verkkoon lisätään unicast-reitityksen lisäksi tuki ryhmälähetyksille, seuraa siitä väistämättä verkolle ja laitteille lisää kuormitusta. Periaate MANET:in ryhmälähetykselle on sama kuin kiinteiden verkkojen tapauksessa: muodostetaan rajattu ryhmä, jolle voidaan lähettää viestejä ryhmälähetysosoittetta käyttäen. Ryhmistä voidaan muodostaa sekä lähdepuita että jaettuja puita (kts. 2.4). MANET on kuitenkin hyvin dynaaminen, eli verkon topologia muuttuu usein. Puumaiset rakenteet eivät siksi aina sovellu hyvin MANETympäristöön. Sen johdosta osaan protokollista onkin kehitetty toisenlainen menetelmä, jossa solmuille on olemassa useampia reittejä, joita pitkin ryhmälähetysviestit kulkevat. Tätä selvitetään tarkemmin seuraavassa. 18

27 4.2 Ryhmien rakenteet Kuten luvussa 2 mainittiin, puumainen rakenne on kaistaa säästävä ratkaisu ryhmien muodostamiseksi. Viestit kulkevat puuta pitkin siten, että viesti voi tulla solmulle vain yhtä reittiä pitkin. Mobiileissa ympäristöissä kaistasta onkin yleensä suuri pula, joten puurakenne tuntuisi periaatteessa hyvältä ratkaisulta MANET:iinkin. Vahvuus saattaa kuitenkin helposti kääntyä heikkoudeksi, koska solmujen väliset linkkiyhteydet ovat MANET:issa epävakaita. Ryhmälähetyspuussa jokainen puun solmu on kiinnitetty johonkin tiettyyn reitittimeen. MANET ympäristössä verkon topologia on kuitenkin jatkuvassa muutoksessa, jolloin puun solmujen väliset yhteydet katkeilevat. Ryhmälähetysviestit eivät enää saavuta katkeamiskohdan jälkeisiä solmuja. Puu vaatii korjaustoimenpiteitä, joissa solmujen välille yritetään löytää uusi reitti verkosta. Korjaustoimenpiteet vaativat aina ylimääräistä viestitystä, jolloin verkko kuormittuu. Mitä dynaamisempi topologia verkolla on, sitä useammin joudutaan ryhmälähetyspuuta korjaamaan. Toisenlainen tapa on luopua kaistansäästövaatimuksista topologian muutosten sietämisen hyväksi. Ryhmät muodostetaan kokoamalla ryhmän jäsensolmuista ja tavallisista solmuista eräänlainen aliverkko tai joukko (engl. mesh). Jäsensolmujen ja niiden liikennettä välittävistä solmuista käytetään myös nimitystä välitysryhmä (engl. forwarding group). Aliverkon solmuilla sallitaan useita yhteyksiä toistensa välillä, joten usein lähettäjien ja vastaanottajien välillä on useita vaihtoehtoisia reittejä. Ryhmälähetysviestit tulvitaan aliverkon sisällä, jolloin viesti kulkee jokaisen jäsensolmun kautta. Nyt solmujen välisten yhteyksien katkeamiset eivät haittaa niin paljoa, koska tulvittu viesti saapuu perille todennäköisesti jotain toista reittiä. Tulviminen tuo tietysti lisää turhaa kuormitusta verkkoon, koska yksikin ehjä reitti lähettäjältä vastaanottajalle riittäisi. MANET-ympäristössä kaikki kantamalla olevat solmut kuitenkin kuulevat lähetetyn viestin, joten tulvimisesta ei aiheudu viestiä lähettäessä yksittäiselle solmulle ylimääräistä kuormaa, koska viestiä ei tarvitse monistaa useita kappaleita. Lisäksi ylimääräinen viestitys maksaa itseään takaisin, koska puurakenteille tyypillisiä korjaustoimenpiteitä ei yleensä tarvitse tehdä. Nyrkkisääntönä voidaan pitää, että puurakenteet soveltuvat paremmin melko staattisiin verkkotopologioihin, joissa ne pystyvät tuomaan kaistansäästöä. Ryhmälähetysaliverkko pääsee oikeuksiinsa vasta hyvin dynaamisissa verkoissa, joissa viestien perillemeno on epävarmempaa. Yksittäisen solmun kannalta rakenteiden tärkein ero on seuraava: mesh-rakenteessa jokainen ryhmälähetysaliverkon jäsenreititin välittää eteenpäin miltä tahansa reitittimeltä kuulemansa saman ryhmän ryhmälähetysviestin. 19

28 Puussa viesti välitetään vain, jos se on tullut isäntäsolmulta. Kuva 4.1 esittää puu- ja mesh-rakennetta samanlaisissa verkoissa. Kuva 4.1: Ryhmien rakenteet. Vasemmalla on puurakenne ja oikealla mesh. Topologian muutokset voivat osittaa MANET-verkon (kts ). Osittuminen estää ryhmälähetysten perillemenon osalle vastaanottajista, koska lähettäjä voi sijaita eri osiossa. Kumpikin rakenne kärsii verkon osittumisesta yhtä paljon, koska osioiden välillä ei ole yhtään reittiä. 4.3 Protokollien perustyypit Ryhmälähetysprotokollia MANET:iin on olemassa useampia erilaisia, jotka toimivat eri periaatteiden mukaan. Edellisen kohdan kahden erilaisen ryhmänmuodostusperiaatteen lisäksi ryhmälähetysprotokollan riippuvuus unicast-protokollasta vaihtelee. Ryhmälähetysprotokolla voi olla täysin itsenäinen, jolloin se tavalla tai toisella löytää reitit kaikille ryhmän jäsenille. Toisaalta prokolla voi tarvita toimiakseen apua joltain tietyltä, tietynlaiselta tai millaiselta tahansa unicast-protokollalta. Lisäksi joistain unicast-protokollista voi olla kehitetty ryhmälähetysversiot. Alla oleva unicast-protokolla voi olla joko reaktiivinen (kts ) tai proaktiivinen (kts ). Tässä tutkielmassa esitellään ja vertaillaan seuraavia protokollia: Core Assisted Mesh Protocol (CAMP) on mesh-rakenteinen protokolla, joka tarvitsee toimiakseen apua proaktiiviselta unicast-protokollalta [6]. 20

29 Adaptive Demand-Driven Multicast Routing Protocol (ADMR) on puumaiseen raketeeseen perustuva protokolla, joka toimii itsenäisesti [7] [8]. Multicast Operation of the Ad-hoc On-Demand Distance Vector Routing (MAODV) on puurakennetta käyttävä ryhmälähetysversio AODV-protokollasta. AODV on reaktiivinen protokolla [10]. On-Demand Multicast Routing Protocol (ODMRP) on itsenäisesti toimiva mesh-rakenteinen protokolla [11]. Ylläolevat protokollat olettavat kaikkien verkon linkkiyhteyksien olevan symmetrisiä. Protokolliin on kehitelty parannuksia, jotka toimivat myös asymmetrisillä yhteyksillä. Niitä ei kuitenkaan käsitellä tässä työssä. 4.4 CAMP Core Assisted Mesh Protocol on suunniteltu toimimaan erittäin dynaamisessa verkkoympäristössä. Se käyttää aliverkkoa (kts. 4.2) ryhmälähetysviestien välittämiseen, jolloin saavutetaan parempi liikkuvuuden sieto kuin puumaisella rakenteella. CAMP tarvitsee toimiakseen apua unicast-protokollalta, joka tarjoaa sille etäisyyden jokaiseen verkon solmuun rajallisessa ajassa. Näin CAMP voi taata, että ryhmälähetysjoukko (mesh) pitää sisällään lyhimmät mahdolliset reitit ryhmälähetyksien lähettäjiltä vastaanottajille. Lyhin mahdollinen reitti tarkoittaa sellaista reittiä, jolla on pienin mahdollinen määrä välittäviä solmuja. Tällaisen reitin olemassaolo takaa solmuille mahdollisimman pienen viiveen ryhmälähetyksessä. Lyhimmän reitin takaaminen esitetään tarkemmin kohdassa Kuva 4.2 esittää ryhmälähetysviestien kulun verkossa. Solmun A lähettäessä viestejä, saavat vastaanottajasolmut B, C, D, E, F ja H lähetyksen useampia reittejä pitkin. Ryhmä pidetään koossa ankkurisolmujen (engl. anchor) avulla. Solmun s ankkuri ryhmälle g on sellainen s:n naapurisolmu, joka on seuraava hyppy (engl. next hop) lyhimmällä reitillä jollekin ryhmän g lähettäjistä. Ryhmän koossapitämiseksi riittää, että jokainen jäsensolmu pitää yllä tietoa vähintään yhdestä ankkurisolmustaan. Jokainen ryhmän jäsensolmu tietää mitä solmuja sillä on ankkurinaan ja mitkä solmut pitävät sitä ankkurinaan. Kuvassa 4.2 voidaan nähdä, että esimerkiksi solmu C pitää ankkurinaan solmua G. 21

30 Kuva 4.2: Mesh-rakenne CAMP-protokollassa Reititysinformaatio Jokainen CAMP-solmu ylläpitää protokollan toiminnan takaamiseksi reititystietoja. Tarvittavat tiedot ovat: reititystaulu (engl. routing table, RT), ryhmän ja keskuksen yhdistävä taulu (engl. core-to-group address mapping table, CAM), ankkuritaulu (engl. anchor table, AT), ryhmälähetysreititystaulu (engl. multicast routing table, MRT), sekä välitettyjen pakettien muisti (engl. packet forwarding cache). Reititystaulu kootaan alla olevan unicast-protokollan antamien tietojen pohjalta. Solmu saa etäisyyden jokaiseen kohdesolmuun verkossa ja tiedon onko reittiä siihen olemassa. Unicast-protokollan tulee siis olla proaktiivinen, koska reititystiedon tulee olla ajan tasalla. CAM sisältää osoitteen jokaisen ryhmän jokaiselle keskukselle. Solmu käyttää tietoa ryhmiin liittyäkseen. AT:sta selviää, minkä kaikkien ryhmien jäsen solmu on. Lisäksi taulussa on lueteltu, mitä naapurisolmuja kyseinen solmu käyttää ankkureinaan kullekin ryhmälle. MRT sisältää tiedon kaikista naapurisolmuista, jotka ovat jonkin ryhmän jäsensolmuja. Lisäksi ylläpidetään tietoa, mitkä näistä solmuista pitävät kyseistä solmua ankkurinaan ja ovatko ne duplex vai simplex-tyyppisiä. Solmu saa tiedon naapureidensa ryhmän jäsenyydestä kuulemalla niiden lähetyksiä. Eli aina kun solmu A lähettää ryhmälähetysviestin eteenpäin, kaikki kantamalla olevat solmut kuulevat sen. Muut solmut päivittävät MRT:nsä tiedolla, että A kuuluu ryhmään. Tätä tietoa ne voivat käyttää tarvittaessa myöhemmin ryhmään liittyäkseen (kts ). Solmu pitää muistissaan tietyn määrän lähiaikoina välitettyjen pakettien tunnistetietoja. Tällä saavutetaan kaistansäästöä, koska samaa pakettia ei lähetetä uu- 22

31 destaan. Lisäksi muistiin tallennetaan jokaiselle paketille sen lähettäneen naapurin osoite. Osoitetietoa käytetään lyhimmän reitin pitämiseksi osana ryhmälähetysaliverkkoa (kts ). Solmut ilmoittavat toisilleen muutoksista reititystiedoissaan. Ilmoitus lähetetään päivitysviestissä (engl. multicast routing update, MRU), joka lähetetään aina, kun MRT tai AT ovat muuttuneet. Tietojenvaihdon tarkoituksena on pitää ryhmän tiedot ajan tasalla. Kaistan säästämiseksi MRU:t olisi hyvä lähettää unicast-protokollan reititystietojen päivitysten yhteydessä sisällyttämällä ne protokollan paketteihin Ryhmään liittyminen ja ryhmästä poistuminen CAMP tukee kahdenlaista tyyppiä ryhmien jäsenyydelle, simplex ja duplex. Simplexjäsen voi ainoastaan lähettää viestejä ryhmälle tai välittää viestejä ryhmälle päin. Se ei vastaanota eikä välitä ryhmältä tulleita viestejä. Duplex-tyyppinen jäsen voi lähettää ryhmälähetysviestejä ja myös vastaanottaa niitä. Lisäksi se välittää viestejä normaalisti kumpaankin suuntaan. Ryhmään liittyminen voidaan tehdä kahdella tavalla. Jos solmulla on naapurina duplex-solmu, niin solmun riittää vain ilmoittautua ryhmän jäseneksi. CAMP olettaa, että ryhmän osoite saadaan selville jonkin muun palvelun avulla. Solmu lähettää MRU:n naapurilleen, jossa se ilmoittaa liittyvänsä ryhmään, joko duplex tai simplex-jäsenenä. Jos alla oleva unicast-protokolla takaa viestien perillemenon, naapurisolmu kuittaa liittymisilmoittautumisen takaisin liittyvälle solmulle. Jos taas viestitys ei ole luotettavaa, liittyvä solmu lähettää ilmoittautumisia useampia jaksottaisesti. Naapurit saavat tällöin todennäköisesti jossain vaiheessa tiedon uudesta jäsenestä. Liittyvä solmu asettaa naapurin omaksi ankkurikseen, ja naapurisolmu asettaa itselleen tästä tiedon. Toinen tapa on käyttää hyväkseen ryhmän keskuksia (engl. core), joita voi ryhmässä olla useita. Tällainen menettely tulee kyseeseen silloin, kun liittyvällä solmulla ei ole naapureina ryhmään kuuluvia solmuja tai naapurit ovat simplex-tyyppisiä. CAMP olettaa, että liittyvä solmu tuntee keskusten osoitteet, jolloin alla oleva unicast-protokolla mahdollistaa liittymisviestin lähetyksen, jos vain jokin reitti keskukseen on olemassa. Liittymisviesti (engl. join request) lähetetään unicastina kohti jotain ryhmän keskuksista. Liittymisviesti saapuu ennen pitkää joko keskukselle tai jollekin ryhmän jäsensolmulle. Tällöin keskus tai jäsensolmu lähettää kuittausviestin (engl. join acknowledgement) takaisin samaa reittiä unicastina liittyvälle solmulle. Kaikki liittymis- ja kuittausviestien välittämiseen osallistuneet solmut asettavat tarvittavat ankkuritiedot ja tulevat osaksi ryhmää. Jos yhteyttä yhteenkään keskukseen 23

32 ei ole, solmu joutuu tulvimaan liittymisviestiä koko verkkoon. Tulvintamenetelmänä käytetään ns. expanded ring search (ERS) -menetelmää, jossa viestien leviämistä hallitaan rajoittamalla kunkin viestin hyppyjen lukumäärää. Ensin solmu tulvii viestin yhden hypyn päähän, eli kaikille naapureilleen. Seuraavaksi kahden hypyn päähän jne. Liittymisviesti saavuttaa näin jossain vaiheessa jonkin ryhmän jäsenen, jolloin jäsen kuittaa liittymisen kuten edellä on esitetty. Jos verkko ei tarjoa luotettavaa tiedonsiirtoa, lähetetään liittymisviestejä uudestaan aivan kuten edellisessä tavassa. Keskusten käytöllä saadaan kaistan kulutusta ryhmään liityttäessä pienennettyä, koska liittymisviestejä ei yleensä tarvitse tulvia koko verkolle. Solmu voi poistua ryhmästä vain jos mikään solmu ei käytä sitä ankkurinaan. Tällöin solmu lähettää naapureilleen poistumisilmoituksen (engl. quit notification), jolloin naapurit päivittävät reititystietonsa. Poistumisilmoitus lähetetään aina MRU:n yhteydessä, eikä vastaanottanut solmu kuittaa sitä Topologian muutokset CAMP takaa lyhimmän reitin olemassaolon ryhmälähetysaliverkossa. Lyhin reitti lähettäjiltä vastaanottajille saadaan selville unicast-protokollan antamasta reititysinformaatiosta. Lyhimmät reitit merkitään ankkureilla. Topologian muutosten vuoksi solmu saattaa ryhtyä saamaan viestejä muitakin kuin lyhintä reittiä pitkin. Vastaanottajasta katsottuna ankkurisolmun takana oleva, lähettäjän ja ankkurisolmun välinen, verkko on voinut muuttua siten, että ankkureilla merkitty reitti ei ole enää lyhin mahdollinen. Uusi lyhin reitti voi olla osana ryhmää, mutta se ei ole varmaa. Jokainen solmu pitää kirjaa, miltä naapurisolmuilta viestejä on saapunut. Kun solmu huomaa, että ankkurilla merkityltä (lyhimmältä) reitiltä on tullut liian vähän viestejä muihin reitteihin nähden, lähettää se ns. heartbeat- tai push join-viestin. Molemmat viestit lähetetään unicast-protokollalta saadun tiedon perusteella naapurille, joka on uudella lyhimmällä reitillä. Jos naapuri on ryhmän jäsensolmu, lähetetään heartbeat. Jos taas naapuri ei kuulu ryhmään, lähetetään push join. Aina kun solmu vastaanottaa heartbeatin tehdään seuraavaa: jos solmun seuraaja lyhimmällä reitillä lähettäjälle on jäsensolmu, lähetetään heartbeat. Jos ei, niin lähetetään push join. Push joinin vastaanotettuaan solmut lähettävät aina push joinin seuraajalleen. Viesti pakottaa kaikki reitillä olevat solmut liittymään ryhmään, jolloin uusi lyhin reitti tulee osaksi ryhmälähetysaliverkkoa. Kuvat 4.3 a, b ja c esittävät vastaanottajasolmun R toimintaa lyhimmän reitin ylläpitämiseksi. Kuva 4.3 a esittää alkutilannetta, jossa R on ryhmän vastaanottaja. R käyttää ankkurinaan lähettäjälle S solmua A. Kuvassa 4.3 b solmujen R ja S väliin liikkuu solmu C. Unicast-protokolla 24

33 havaitsee, että R:n ja S:n välillä olisi olemassa lyhempi reitti, joka kulkee solmun C kautta. R lähettää heartbeatin kohti lähettäjää S, koska R:n naapuri B on ryhmän jäsen. B lähettää solmulle C push join -viestin, koska C ei ole ryhmän jäsen. Solmulta C eteenpäin lähetetään vain push join -viestejä, aina lähettäjälle saakka. Kaikki solmut, jotka saavat push join -viestin, tulevat osaksi ryhmälähetysjoukkoa. Jonkin ajan kuluttua välittäjäsolmujen (esimerkiksi solmu A) ryhmälähetysreititystaulut päivittyvät ja ne havaitsevat, että mikään solmu ei käytä niitä ankkureinaan. Tällöin ne lakkaavat välittämästä ryhmälähetysviestejä. Uusi mesh-rakenne näkyy kuvassa 4.3 c. Kuva 4.3: Lyhimmän reitin takaaminen. (a) Alkutila (vasen ylhäällä). (b) Heartbeatin ja push joinin lähetys (oikea ylhäällä). (c) Uusi mesh (vasen alhaalla). 25

34 CAMP sietää verkon topologian muutoksia hyvin rakenteensa vuoksi. Ryhmien lähettäjien ja vastaanottajien välillä on yleensä useita reittejä, jolloin reittien katkeaminen ei ole niin suureksi haitaksi kuin puumaisessa rakenteessa. Jos solmu kuitenkin menettää yhteyden ryhmään, niin se lähettää push joinin naapurilleen, joka sijaitsee lyhimmällä reitillä johonkin keskukseen. Push joinia lähetetään eteenpäin, jolloin kaikki reitillä olevat solmut tulevat osaksi ryhmää. Kuvassa 4.4 a solmun R yhteys ryhmään katkeaa, jolloin se lähettää push join -viestin unicast-protokollan ilmoittamalle naapurilleen, joka on lyhimmällä reitillä keskukselle. Kuvassa 4.4 b näkyy uusi, korjattu ryhmälähetysaliverkko. Kuva 4.4: Rakenteen korjaus. (a) Push joinin lähetys. (b) Korjattu mesh. Vaikka verkon osittuminen haittaa ryhmälähetysten perillemenoa (kts. 4.2), ei se estä uusien jäsenien liittymistä verkkoon. Useiden keskusten käyttö pienentää todennäköisyyttä tilanteelle, jossa liittyvällä solmulla ei ole yhteyttä keskukseen. Jos yhteyttä ei kuitenkaan ole, voi solmu silti liittyä ERS-menetelmällä verkkoon. Solmut pyrkivät saamaan uudelleen yhteyden keskukseen lähettämällä push join -viestin keskukselle heti, kun unicast -prokollan mukaan reitti on olemassa. Verkko saattaa osittua joskus siten, että ainakin kahdessa osiossa on oma keskus. Keskukset lähettävät aika ajoin unicastina toisilleen core explicit join (CEJ) -viestejä. Nämä liittävät reitillä olevat solmut ryhmään, aivan kuten push join. CEJ-viesteillä taataan, että omia keskuksiaan sisältävät osiot yhdistyvät. 4.5 ADMR Adaptive Demand-Driven Multicast Routing -protokolla käyttää puumaista rakennetta ryhmälähetysviestien välitykseen. Puu rakennetaan tarpeen mukaan, eli sil- 26

35 loin kun ryhmälle halutaan lähettää ja ryhmällä on olemassa ainakin yksi vastaanottaja. ADMR poikkeaa hieman kohdassa 4.2 mainitusta puumallista. Jokaista lähettäjää kohden luodaan oma puunsa, mutta viestit voivat kulkea vastaanottajille useita reittejä (puun haaroja) pitkin. Ryhmälähetyksen jäsensolmut voivat siis ottaa vastaan muualtakin kuin isäntäsolmulta tulleita ryhmälähetysviestejä. Protokolla takaa, että ryhmälähetysviestit kulkevat lähettäjältä vastaanottajalle lyhintä mahdollista reittiä. Lyhin reitti tarkoittaa tässäkin yhteydessä pienintä mahdollista hyppyjen määrää. ADMR on täysin riippumaton alla olevasta unicast-protokollasta. ADMR voi siis käyttää apunaan mitä tahansa unicast-protokollaa tai se voi toimia täysin itsenäisesti. Vastaanottajien ei tarvitse lähettää nimenomaista viestiä irroittautuakseen puusta, vaan puun harvennus toteutetaan ajastimien avulla Pakettien välittäminen Jokainen ryhmälähetyspaketti sisältää ADMR-otsikon, joka sisältää tarpeelliset tiedot paketin käsittelyä varten. Tärkeimmät tiedot ovat: sekvenssinumero (engl. sequence number), hyppylaskuri (engl. hop count), edellisen hypyn osoite (engl. previous hop address) ja pakettien lähetysväli (engl. inter-packet time). Sekvenssinumerolla varmistetaan, että yksikään solmu ei välitä samaa viestiä useampaan kertaan. Hyppylaskuria tarvitaan määrittämään lyhin reitti lähettäjälle. Edellisen hypyn osoite ilmoittaa kullekin solmulle, miltä naapurilta kukin viesti on tullut. Tietoa tarvitaan ADMR:n käyttämään unicast-reititykseen, josta lisää myöhemmin. Pakettien lähetysväli ilmoittaa, kuinka usein lähettäjältä odotetaan paketteja saapuvaksi. Tällä tavoin huomataan puun rikkoutuminen tai ryhmälähetyksen loppuminen. Tämä selvitetään tarkemmin myöhemmin. Ryhmälähetys toteutetaan tulvimalla datapaketteja ryhmälähetyspuun sisäisesti (engl. tree flood), jolloin vain puuhun kuuluvat solmut lähettävät paketteja eteenpäin. Solmu voi kuulua ryhmälähetyspuuhun olemalla vastaanottaja, välittäjä tai molempia. Vastaanottaja hyväksyy paketin ja antaa sen protokollapinon ylemmälle kerrokselle. Välittäjä taas lähettää paketin eteenpäin naapureilleen ja asettaa ADMRotsikkoon edellisen hypyn osoitteeksi oman MAC-osoitteensa. ADMR tukee perinteistä ryhmälähetysmallia, jossa vastaanottaja voi vastaanottaa ryhmälähetystä miltä tahansa ryhmän lähettäjältä. Protokolla tukee myös lähettäjäkohtaisia (engl. source specific) ryhmiä, joissa solmut voivat halutessaan vastaanottaa ryhmälähetystä vain tietyiltä ryhmän lähettäjiltä. ADMR muodostaa jokaiselle lähettäjälle oman ryhmälähetyspuun, jossa lähettäjä on juurisolmuna (lähdepuu). 27

36 Ryhmälähetyspuuhun kuuluva solmu vastaanottaa ADMR-paketin miltä tahansa samaan puuhun kuuluvalta naapurisolmulta. Näin ollen ADMR:n puurakenne eroaa hieman kohdassa 4.2 esitetystä puumallista, koska viestit voivat saapua vastaanottajille useampia reittejä. Jos puussa on lähellä toisiaan sijaitsevia haaroja (ts. eri haarojen solmut sijaitsevat toistensa kantamilla), alkaa puu muistuttaa jo meshiä. Tällöin ei haittaisi vaikka jotkin puun haarat olisivatkin poikki. Kuva 4.5 esittää yhden ryhmän kahta puuta. Ryhmällä on kaksi lähettäjää: L1 ja L2. Solmu A vastaanottaa lähetystä sekä L1:ltä että L2:lta. Solmu B vastaanottaa vain L1:n lähetystä ja solmu C vain L2:n lähetystä. Koska solmut A ja B sijaitsevat L1:n ryhmälähetyspuun lähekkäisissä haaroissa, voi B saada L1:n lähettämää dataa useampaa reittiä pitkin. Kuva 4.5: Kaksi ADMR-puuta. ADMR voi tarvittaessa siirtyä lähettämään ryhmälähetysviestejä tulvimalla niitä koko verkkoon (engl. network flood). Tällainen tilanne syntyy tavallisesti, jos solmut ovat erittäin liikkuvia. Puurakenne ei pysy koossa, jolloin sitä joudutaan jatkuvasti korjaamaan (kts ). Tietyn liikkuvuuden määrän ylittyessä korjaustoimenpiteiden aiheuttama ylimääräinen liikenne verkossa ylittäisi tulvinnasta aiheutuvan, jolloin on järkevää siirtyä tulvintaan. 28

37 4.5.2 Reititysinformaatio Jokaisen puun jäsensolmun tulee pitää muistissaan seuraavia reititystauluja: Lähettäjätaulu sisältää kaikkien niiden ryhmien osoitteet, joille solmu on lähettäjänä. Sisältää lisäksi senhetkisen pakettien lähetysvälin ja lähetettyjen keep alive -pakettien lukumäärän. Jäsenyystaulu sisältää merkinnän jokaista ryhmäosoite-lähettäjän osoite -paria kohti, joille solmu on joko vastaanottaja, välittäjä tai molempia. Lisäksi jokaista paria kohti on tieto pakettien senhetkisestä lähetysvälistä ja saatujen keep alive -pakettien lukumääristä. Solmutaulu sisältää jokaisen solmun osoitteen, jolta solmu on saanut ADMRpaketin joko puun sisäisellä tai koko verkon tulvinnalla. Jokaiseen solmuun on taulussa liitetty viimeisimmän solmulta saadun paketin sekvenssinumero, jonka avulla estetään samojen pakettien välitys useampaan kertaan. Lisäksi jokaiseen solmuun on liitetty edellisen hypyn osoite (engl. previous hop address), joka on sen naapurin MAC-osoite, jolta paketti on saatu lyhintä reittiä Lähettäjäksi tuleminen Solmu voi ilmoittautua ryhmän lähettäjäksi lähettämällä ensimmäisen ryhmälähetyspaketin tulvimalla koko verkon yli. Samalla se merkitsee lähettäjätauluun itsensä ryhmän lähettäjäksi. Lähettäjä odottaa seuraavaksi muilta solmuilta ryhmäänliittymis-, eli receiver join -viestejä ja ryhtyy puskuroimaan seuraavia ryhmälähetyspaketteja lähetettäväksi myöhemmin. Kun yksikin liittymisviesti on vastaanotettu, ryhdytään lähetettämään puskuroituja viestejä vastaanottajille. On mahdollista, että osa liittymisviesteistä ei ole saapunut perille, jolloin kaikki halukkaat vastaanottajat eivät ole pystyneet liittymään ryhmään. Solmuille on myös annettava mahdollisuus liittyä ryhmään myöhemmin. Tämän vuoksi osa ryhmälähetysviesteistä lähetetään tietyin väliajoin tulvimalla koko verkkoon. Aluksi viestejä lähetetään tiheämmin ja pikkuhiljaa lähetysten väliä harvennetaan aina johonkin tiettyyn vakioarvoiseen lähetystiheyteen. Ryhmälähetyspaketteja lähetetään tulvimalla koko verkkoon niin kauan kuin yhdelläkin ryhmän lähettäjällä on viestejä lähetettävänään. Tällainen tulvinta siis mainostaa ryhmän olemassaoloa muulle verkolle. Jos lähettäjällä ei ole dataa lähetettävänään, mutta haluaa silti pitää ryhmän koossa, lähettää se määrätyin väliajoin ns. keep-alive -viestejä puun sisäisellä tulvinnalla (eli ryhmälähetyksenä). Näitäkin lähetetään aluksi tiheämmin ja lähetysväliä 29

38 harvennetaan tasaisesti. Jos lähetysväli saavuttaa ennaltamäärätyn arvon, olettavat kaikki ryhmän jäsensolmut lähettäjän lopettaneen lähetyksen. Solmut poistavat tällöin tiedot reititysinformaatiotauluistaan ja ryhmä poistuu käytöstä Ryhmään liittyminen ja ryhmästä poistuminen Solmu voi liittyä haluttuun ryhmään lähettämällä liittymispyyntö (engl. multicast solicitation) -viestin tulvimalla koko verkkoon. Vastaanottajan osoitteeksi asetetaan halutun ryhmän ryhmäosoite. Jos ryhmä on lähettäjäkohtainen, lisätään viestiin myös lähettäjän osoite. Tulvittu viesti saapuu aikanaan lähettäjälle hieman eri tavoin, riippuen onko ryhmä lähettäjäkohtainen vai ei. Jos ryhmä ei ole lähettäjäkohtainen, saapuu tulvittu viesti aikanaan kaikille lähettäjille. Lähettäjäkohtaisessa tapauksessa taas ensimmäinen ryhmän jäsensolmu (paitsi lähettäjä), jolle multicast solicitation saapuu, ohjaa sen unicastina lähettäjälle. Ohjaavan solmun tulee olla ryhmän välittäjä, jolloin sillä on solmutaulussaan tieto, minkä naapurin kautta lähettäjälle välitettävät viestit pitää lähettää. Jokainen jäsensolmu reitillä lähettäjälle toimii samoin ja liittymispyyntö välittyy unicastina lähettäjälle. Näin toimien säästetään kaistaa. Kun mikä tahansa lähettäjä vastaanottaa liittymisviestin, pitää sen ilmoittaa liittyvälle solmulle olevansa aktiivinen lähettäjä. Tämän se voi tehdä kahdella tapaa: (1) Lähettäjä lähettää keep-alive -viestin unicastina liittyvälle solmulle. Jokainen solmu, jonka kautta liittymisviesti on kulkenut lähettäjälle, on tallentanut solmutauluunsa edellisen hypyn osoitteen. Tämän perusteella solmut voivat ohjata viestin suoraan takaisin liittyvälle solmulle. Jokainen välittävä solmu liittää nyt myös solmutaulussaan lähettäjän osoitteeseen edellisen hypyn osoitteen, jos merkintää ei ole aikaisemmin ollut. Tietoa tarvitaan liittyvän solmun liittymisen vahvistamisviestin välittämiseen. (2) Lähettäjä voi aikaistaa ryhmän mainostusviestin (kts ) lähetystä, jos mainostusviesti on määrä lähettää piakkoin ja liittyviä solmuja on useita. Mainostusviesti saapuu liittyvälle solmulle jotain reittiä (todennäköisesti lyhintä) ja solmu lähettää liittymisen vahvistusviestin samaa reittiä takaisin. Solmun liittyminen ryhmään viimeistellään liittyvän solmun lähettämällä liittymisen vahvistamisviestillä (engl. receiver join). Viesti lähetetään aina unicastina lähettäjälle ja se asettaa kaikki matkalla olevat solmut välittäjiksi kyseiselle ryhmälle. Jos liittyviä solmuja on samalla alueella useita, kulkisi useiden solmujen lähettämät liittymisen vahvistamisviestit todennäköisesti samojen solmujen kautta. ADMR pyrkii välttämään turhaa kaistan kulutusta välittämällä eteenpäin korkeintaan kolme samaa lähettäjää koskevaa ja samanaikaista receiver joinia. Jos välitettäisiin vain yksi 30

39 viesti, eikä se menisi perille, ei solmujen liittymiselle tulisi vahvistusta. Sekä lähettäjä, että liittyvä solmu lähettävät tarvittaessa edellämainittuja viestejä useampaan kertaan, mikäli vastausta ei ole määräaikaan mennessä saapunut. Liittymisprosessi aloitetaan alusta, mikäli vastausta ei uudelleenlähetyksestä huolimatta ole tullut Topologian muutokset ja puun korjaustoimenpiteet ADMR pyrkii pitämään reitin lähettäjältä jokaiselle vastaanottajalle mahdollisimman lyhyenä. Ryhmälähetysviestit kulkevat puun sisäisessä tulvinnassa lyhintä reittiä, koska ensiksi saapunut viesti on todennäköisesti tullut lyhintä reittiä. Jokainen jäsensolmu pitää solmutaulussaan tietoa lyhimmistä reiteistä jokaiseen solmuun, jolta kyseinen solmu on saanut ADMR-kehyksen sisältävän viestin. Jos samalta solmulta on tullut viesti useita reittejä pitkin, tallennetaan solmutauluun vain pienimmän hyppyjen lukumäärän sisältävän reitin tiedot. Protokolla ei suorita mitään aktiivisia toimenpiteitä lyhimmän reitin takaamiseksi, kuten CAMP. ADMR:ssä jokainen ryhmän jäsensolmu tarkkailee sille saapuneiden ryhmälähetysviestien kulkeman reitin pituutta ADMR-kehyksen hyppyjen lukumäärä -kentän avulla. Jokainen ryhmän jäsensolmu havaitsee yhteyden ryhmään olevan poikki, kun tietty määrä odotettuja ryhmälähetysdatapaketteja tai ryhmän keep-aliveja on jäänyt tulematta. Molempia viestejähän lähetettiin tunnetuin väliajoin, joten solmut pystyvät laskemaan, montako viestiä tietyllä aikavälillä pitäisi tulla. Kun solmu A huomaa yhteytensä lähettäjään katkenneen, ryhtyy se suorittamaan puun korjaustoimenpiteitä. Tarkoitus on etsiä uusi reitti A:sta ylävirtaan oleville jäsensolmuille. Ensin A lähettää alavirtaan eli alipuulleen korjauksen ilmoitusviestin (engl. repair notification). Näin estetään alipuun solmujen ryhtyminen samanaikaisesti omiin korjaustoimenpiteisiin. Jokainen alipuun solmu hyväksyy ja välittää edelleen korjauksen ilmoitusviestin vain, jos se on tullut solmun solmutaulussa olevasta edellisen hypyn osoitteesta (eli ryhmälähetyspuussa yhtä tasoa ylemmältä solmulta). Solmu A odottaa korjauksen ilmoitusviestin lähetettyään jonkin aikaa mahdollista ylävirrasta tulevaa ilmoitusviestiä. Jos A saa tällaisen viestin, keskeyttää se omat korjaustoimenpiteensä, koska jokin ylävirran solmuista on jo korjaamassa rikkoutunutta puuta. Jos A ei ole saanut ylävirrasta repair notificationia lyhyen ajan sisällä, lähettää se uudelleenliittymisviestin (engl. reconnect) tulvimalla muutaman solmun säteelle. Reconnect-viestissä ilmoitetaan sen ryhmän osoite, johon halutaan liittyä uudelleen. Kun jokin solmu B saa uudelleenliittymisviestin, eikä ole saanut korjauksen ilmoitusviestiä samalle ryhmälle, olettaa B että A sijaitsee siitä alavirtaan. B lähettää nyt viestin eteenpäin kohti ryhmän lähettäjää (juurisolmua) 31

40 unicastina. Jos taas B sijaitseekin A:sta alavirtaan, saapuu reconnect-viesti takaisin A:lle. Solmu A hylkää kaikki alavirrasta saapuneet uudelleenliittymisviestit. Jos reconnect-viesti saapuu ryhmän lähettäjälle, vastaa se lähettämällä unicastina uudelleenliittymisen vastausviestin (engl. reconnect reply) takaisin A:lle. Kaikki reconnect replyn välittäneet solmut tulevat ryhmän välittäjäsolmuiksi. Kuva 4.6 esittää solmun A suorittamia korjaustoimenpiteitä. Kuva 4.6: ADMR-puun korjaustoimenpiteet. Jos korjaustoimenpiteistä huolimatta A ei saa muodostettua uudelleen yhteyttä lähettäjään, yrittää se liittyä ryhmään kohdassa esitetyllä tavalla. Kun solmu joutuu suorittamaan uudelleenliittymisen riittävän usein määrätyn ajan sisällä, ilmoittaa se siitä lähettäjälle. Solmu asettaa seuraavaan receiver join -viestiinsä tiedon yhteysongelmistaan. Lähettäjä siirtyy tulvimaan ryhmälähetysviestejään koko verkkoon riittävän monta ilmoitusta saatuaan. Näin ADMR adaptoituu verkon solmujen suureen liikkuvuuteen. Lähettäjä siirtyy takaisin normaaliin puun sisäiseen tulvintaan taas jonkin ajan kuluttua. 4.6 MAODV Multicast Operation of the Ad-hoc On-Demand Distance Vector (MAODV) on laajennus AODV:sta (Ad-hoc On-Demand Distance Vector). AODV mahdollistaa viestien lähetyksen ad-hoc -verkossa unicastina. MAODV voi käyttää apunaan, unicasttoiminnon lisäksi AODV:n tarjoamia reititystietoja. Protokolla rakentaa verkon solmuista on-demand -periaatteella puun ryhmälähetystä varten. Mikä tahansa ryhmän jäsensolmu voi lähettää ryhmälle ryhmälähetysviestejä, jotka lähetetään kohdassa 4.2 esitetyn puumaisen periaatteen mukaisesti. Protokolla mahdollistaa ryhmälähetyksien ohjauksen todennäköisesti lyhintä reittiä lähettäjiltä vastaanottajille. 32

41 4.6.1 Unicast-toiminto (AODV) MAODV-protokolla tarvitsee joidenkin viestiensä lähetykseen unicast-toimintoa, jonka AODV [9] sille tarjoaa. AODV:n reitinmuodostus on puhtaasti on-demand -tyyppinen, eli reitti haetaan vain tarvittaessa, jos sitä ei entuudestaan tunneta. Jokainen solmu pitää reittejä reititystaulussaan määrätyn ajan, jonka jälkeen niitä poistetaan muistista. Jokaiseen reittiin yhdistetään reititystaulussa kasvava sekvenssinumero, jolla ilmaistaan reitin tuoreus. Reitinmuodostuksessa käytetään kahta viestityyppiä. Solmu kysyy uutta reittiä RREQ (route request) -viestillä, johon tulee vastata RREP (route reply) -viestillä, jos reitti on olemassa. Molemmat viestityypit sisältävät aina tunnistenumeron, joka yhdessä lähettävän solmun IP-osoitteen kanssa yksilöi viestin. Solmut käyttävät tietoa estääkseen saman viestin lähettämisen useampaan kertaan. Kun solmu tarvitsee reitin kohteelle, lähettää se RREQ:n tulvimalla koko verkkoon. Viesti sisältää lähteen ja kohteen osoitteet, reitityksen hyppylaskurin (joka on alussa nolla), sekä viimeisimmän solmun tunteman sekvenssinumeron kyseiselle reitille. Jokainen solmu merkitsee reititystauluunsa määräajaksi sen naapurin osoitteen, jolta RREQ saapui. Näin jokaisella solmulla on tiedossaan reitti RREQ:n lähettäneelle solmulle. Seuraavaksi solmu tarkistaa sekvenssinumeroja vertaamalla, onko sillä tuoreempaa reittiä kohteelle. Jos on, niin solmu voi vastata lähettämällä RREP-viestin samaa reittiä takaisin. Muussa tapauksessa solmu lisää hyppylaskuria yhdellä ja lähettää RREQ:n kaikille naapureilleen, jolloin tulvinta jatkuu. Jos solmu saa useampia RREQ-viestejä, niin RREP lähetetään takaisin sitä reittiä pitkin, millä on pienin hyppylaskurin arvo. RREP-viestiin asetetetaan sen lähettäneen solmun etäisyys (hyppyjen lukumääränä) halutusta kohteesta. Etäisyys on nolla, jos RREP:n lähettävä solmu on itse kohde. Jokainen RREP:n välittävä solmu merkitsee muistiin sen naapurin osoitteen, jolta viesti saapui. Näin muodostuu reitti lähteeltä kohteelle. Jokainen solmu lisää RREP:n edelleenlähetyksen yhteydessä etäisyyden arvoa yhdellä. Solmut saavat todennäköisesti useita samalta solmulta lähteneitä RREPviestejä. Tällöin solmu valitsee edelleenlähetettäväksi sen, jolla on pienin hyppyjen lukumäärän arvo. Lähdesolmu valitsee käytettäväksi reitiksi pienimmän hyppyjen lukumäärän sisältävän reitin. Kaikki solmut, jotka eivät sijaitse käytettävällä reitillä, poistavat reittiin liittyvät osoitintietonsa määrätyn ajan kuluttua. Kuvassa 4.7 a solmulla A (lähdesolmu) on dataa lähetettävänä solmulle B, mutta sillä ei ole reittiä B:lle. A lähettää RREQ-viestin tulvimalla koko verkkoon, jolloin se saavuttaa B:n. Kuvassa 4.7 b solmu B on saanut RREQ:n kolmelta eri naapuriltaan. 33

42 B valitsee lyhimmällä reitillä A:lle sijaitsevan naapurinsa ja lähettää sille RREPviestin. RREP ohjautuu samaa, lyhintä reittiä takaisin solmulle A ja datan lähetys voi alkaa. Kuva 4.7: Reitinhaku AODV:ssa. (a) RREQ-viestin leviäminen verkossa (vasen). (b) RREP:n lähetys reitin kysyjälle (oikea). Solmujen tulee olla tietoisia naapurisolmuistaan (erityisesti niiden osoitteista), jotta reittejä halutuille solmuille voidaan muodostaa. Jokainen solmu kuulee naapuriensa lähetykset, jos ne vain ovat kantaman sisällä. Jokaisen käytössä olevan reitin solmun on lähetettävä määräajoin ns. hello-viestejä alavirran naapurilleen, jos reitillä ei liiku muuta dataa. Alavirran naapuri on kohteen suunnassa oleva naapurisolmu. Tällä tavoin käytettävä reitti saadaan pidettyä voimassa, vaikka sitä ei hetkeen käytettäisikään. Reitin solmut voivat huomata reitin katkenneen kahdella tapaa: (1) Solmu ei havaitse, että alavirran naapurisolmu lähettäisi edelleen juuri lähetettyä datapakettia. (2) Alavirran naapurin lähettämää hello-viestiä ei havaita. Reitin katkeamisen havaittuaan solmu lähettää omalle ylävirran naapurilleen ilmoituksen katkeamisesta. Ilmoitus välitetään aina datan lähettäjäsolmulle saakka, jolloin se etsii uuden reitin kohteeseen Reititysinformaatio Jokainen solmu ylläpitää reititystauluissaan sekä AODV:n että MAODV:n tarvitsemia tietoja. AODV tarvitsee jokaisesta reitistä seuraavat tiedot: Kohteen IP-osoite. Reitin sekvenssinumero. Etäisyys kohteeseen hyppyjen lukumääränä. 34

43 Seuraavan hypyn osoitin (naapurin IP-osoite). Ajastin reitille. Jokainen puun jäsensolmu (myös ryhmän jäsensolmu) ylläpitää jokaista ryhmää kohti, johon se kuuluu, seuraavia tietoja: Ryhmän IP-osoite. Ryhmänjohtajan IP-osoite (tämä ei aina ole tiedossa). Ryhmän sekvenssinumero. Etäisyys ryhmänjohtajaan hyppyjen lukumääränä. Seuraavien hyppyjen osoittimet (naapurien IP-osoitteet). Ajastin puulle Pakettien lähettäminen MAODV:ssä ryhmälähetyspaketit lähetetään puumaisesti. Jokainen puun jäsensolmu ylläpitää jokaista ryhmää kohti osoittimia (eli naapurien IP-osoitteet ovat muistissa) niihin naapureihinsa, jotka myös ovat puun jäseniä samalle ryhmälle. Kun puun jäsensolmu saa puun jäsenenä olevalta naapuriltaan viestin, lähettää se sen kaikille muille naapureilleen, jotka ovat myös puun jäseniä. Viesti voi saapua jokaiselle solmulle vain yhtä reittiä pitkin. Ryhmälähetysviestit kulkevat vain aktivoituja (kts ) ryhmälähetysreittejä pitkin Ryhmään liittyminen ja ryhmästä poistuminen MAODV muodostaa verkon solmuista ryhmälähetyspuun. Puu koostuu kahdenlaisista solmuista: puun jäsensolmuista ja ryhmän jäsensolmuista. Ryhmän jäsensolmut vastaanottavat ryhmälähetysviestejä, sekä tarpeen tullen välittävät viestejä edelleen. Puun jäsensolmujen tehtävä on vain välittää ryhmälähetysviestejä ryhmän jäsenille tai muille puun jäsenille. Puu voi koostua pelkästään ryhmän jäsensolmuista, jos ne vain ovat sopivasti toistensa kantamilla. Puun juurena on ns. ryhmänjohtaja-solmu. Se on muuten tavallinen ryhmän jäsensolmu, paitsi sillä on erityinen tehtävänä mainostaa ryhmän olemassaoloa. Mainostus suoritetaan ns. group hello -viestillä, joka lähetetään tulvimalla koko verkkoon. Viestissä on ryhmänjohtajan ja ryhmän IP-osoitteet sekä ryhmän sekvenssi- 35

44 numero. Näin kaikki verkon solmut saavat tietoonsa ryhmän osoitteen. Sekvenssinumero on juokseva numero, jota kasvatetaan yhdellä aina kun group hello lähetetään. Jokainen solmu tallentaa viestin tiedot muistiinsa. Solmuilla oleva ryhmän sekvenssinumero ilmoittaa, kuinka tuore tieto ryhmän olemassaolosta on. Jos ryhmänjohtajan mainostusviestejä ei ole saapunut solmulle vähään aikaan (eli yhteys ryhmänjohtajaan on poikki), on solmulla oleva ryhmän sekvenssinumero pienempi kuin muulla verkolla. Solmun ei tarvitse liittyä ryhmään lähettääkseen sille viestejä, vaan se voi lähettää ne lähimmälle halutun ryhmän jäsensolmulle. Jos solmulla ei ole reittiä ryhmään, on reitti haettava käyttäen RREQ-viestiä, jossa kohdeosoitteena on ryhmän IP-osoite. Viestiin asetetaan myös solmun tietämä viimeisin ryhmän sekvenssinumero. Mikä tahansa solmu, jolla on tuore reitti ryhmään ja jonka tietämä ryhmän sekvenssinumero on vähintään yhtä suuri kuin RREQ-viestissä oleva, voi vastata RREP-viestillä. Reitti haetaan ja muodostetaan siis samalla tavalla kuin kohdassa on esitetty. Solmu liittyy ryhmään lähettämällä liittymis-rreq -viestin unicastina ryhmänjohtajalle, jos johtaja ja reitti sille on tiedossa. Ryhmänjohtaja vastaa RREP:llä, joka lähetetään samaa reittiä pitkin takaisin liittyvälle solmulle. Jos liittyvällä solmulla ei ole tiedossaan reittiä ryhmään, lähettää se liittymis-rreq:n tulvimalla koko verkkoon. Viesti saapuu aikanaan ryhmän jäsensolmulle, joka vastaa RREP:llä, jos solmun tuntema ryhmän sekvenssinumero on vähintään yhtäsuuri kuin RREQ:ssa oleva. Tärkeimmät RREP:n sisältämät tiedot ovat ryhmän sekvenssinumero, ryhmän johtajan IP-osoite ja etäisyysarvo lähimpään ryhmän jäseneen hyppyjen lukumääränä. Etäisyysarvo alustetaan nollaksi ja jokainen solmu, joka välittää RREP:n takaisin liittyvälle solmulle kasvattaa sitä yhdellä. Ryhmän jäsensolmu ei lähetä RREQ:ta enää eteenpäin. Jokainen RREQ:n tai RREP:n välittänyt solmu asettaa itselleen seuraavan hypyn osoittimet, kuten kohdassa esitettiin. Liittyvälle solmulle voi tulla useita RREP-viestejä, koska RREQ on todennäköisesti kulkeutunut useille eri jäsensolmuille. RREP-viesteistä valitaan se, jolla on pienin etäisyys ryhmän jäseneen. Tämän jälkeen puuhun liittyminen on viimeisteltävä aktivoimalla reitti. Aktivointi suoritetaan ilmoittamalla valitun reitin solmuille, että ne tulevat osaksi ryhmälähetyspuuta. Ilmoittaminen suoritetaan lähettämällä erityinen reitin aktivointiviesti (engl. multicast activation, MACT) solmulle, jota kautta kulkeva reitti on valittu. Reitin solmut ohjaavat MACT:n osoittimiensa avulla aina ryhmän jäsenelle saakka, samaan tapaan kuin RREQ:n ja RREP:n yhteydessä. Muut RREQ:ta ja RREP:tä välittäneet solmut poistavat liittymisprosessin aikana tekemänsä osoittimet ajastimien lauet- 36

45 tua. Kuva 4.8 a esittää solmun A lähettämän RREQ-viestin tulvintaa verkossa. Kuvassa 4.8 b näkyy neljä kappaletta ryhmän jäsenten lähettämää RREP-viestiä, kun ne kulkevat takaisin solmulle A. Kuvassa 4.8 c solmu A on valinnut lyhimmän reitin ryhmään. Kuva 4.8: Ryhmään liittyminen MAODV:ssa. (a) RREQ-viestin leviäminen verkossa (vasen ylhäällä). (b) RREP:n lähetys liittyjälle (vasen alhaalla). (c) Solmu on liittynyt puuhun (oikea alhaalla). Jos liittyvä solmu ei saa vastausta lähettämäänsä liittymispyyntöviestiin määräaikaan mennessä, lähetetään pyyntöviesti uudestaan. Jos solmu oli lähettänyt ensimmäisen liittymispyyntöviestinsä unicastina ryhmän johtajalle, lähetetään seuraavat pyynnöt tulvinnalla. Tämä siksi, että unicast-reitti voi olla vanhentunut tai jokin muu solmu on tullut ryhmän johtajaksi. Jos vastausta ei useampien lähetyskertojen jälkeenkään tule, voidaan päätellä, että solmu ei saa yhteyttä ryhmään. Ryhmä 37

46 voi olla tällöin kokonaan ilman jäseniä tai vaihtoehtoisesti verkko voi olla osittunut niin, että kyseisessä osassa verkkoa ei ole ainuttakaan halutun ryhmän jäsentä. Nyt solmusta itsestään tulee ryhmän johtaja ja se ryhtyy mainostamaan ryhmää muulle verkolle. Muut solmut voivat liittyä tähän ryhmään. Osittumisen tapauksessa voidaan saman ryhmän kaksi tai useampaa puuta yhdistää jälleen yhdeksi. Yhdistyminen selitetään kohdassa Solmu voi poistua ryhmälähetyspuusta ainoastaan, jos se on lehtisolmu, eli sillä ei ole yhteyttä yhteenkään jäsensolmuun, joiden isäntäsolmu se on. Jos solmu ei ole lehtisolmu, tulee sen jatkaa ryhmälähetyviestien välittämistä, vaikka se itse ei niitä enää tarvitsisikaan. Solmu poistuu ryhmälähetyspuusta lähettämällä MACT-viestin ylävirtaan isäntäsolmulleen, joka sisältää poistumisilmoituksen ja kyseisen ryhmän IP-osoitteen. Isäntäsolmu on solmu, joka sijaitsee puussa yhden hypyn etäisyydellä ylävirtaan. Kun solmu saa alavirrasta irrottautumis-mact -viestin, se poistaa kyseisen solmun tiedot reititystaulustaan. Irroittaumis-MACT -viestin saatuaan solmusta voi itsestään tulla lehtisolmu. Jos solmu on tähän asti vain välittänyt ryhmälähetysviestejä, voi se poistaa itsensäkin puusta samalla menetelmällä. Näin jatketaan, kunnes ryhmälähetystä vastaanottava solmu tai ei-lehtisolmu saavutetaan Puun korjaus Jokainen puun jäsensolmu kuulee kaikki naapurisolmujensa lähetykset. Jos solmu ei ole saanut ryhmän jäsensolmuna olevalta naapuriltaan ryhmälähetysviestejä tai tervehdysviestejä (kts ) määräaikaan mennessä, olettaa se linkin naapuriin olevan poikki. Tässä tilanteessa katkeamiskohdasta alavirtaan oleva solmu on velvollinen korjaamaan katkeama. Solmu lähettää RREQ-viestin tulvimalla sen vain muutaman solmun etäisyydelle, koska todennäköisesti lähellä sijaitsee solmuja, joiden kautta linkki saadaan jälleen kulkemaan. Viestiin asetetaan ryhmän IP-osoite ja sekvenssinumero, sekä korjauksen tekevän solmun etäisyys ryhmänjohtajasta. Jokainen puun jäsensolmu, jonka tietämä ryhmän sekvenssinumero on vähintään yhtä suuri kuin viestissä oleva ja jonka etäisyys ryhmänjohtajasta on pienempi kuin viestissä, voi vastata RREQ-viestiin. Näin taataan, että korjaava solmu saa tuoreen reitin ryhmään ja että vastaava solmu todella sijaitsee ylävirtaan korjaavasta solmusta. Vastausviesti on RREP ja se lähetetään takaisin samaa reittiä. Reitti aktivoidaan lopulta MACT-viestiä käyttäen (kts ). Jos korjaava solmu ei saa vastausta, lähettää se korjauksen pyynnön koko verkon kattavana tulvintana. Jos vieläkään vastausta ei kuulu, on verkko todennäköisesti osittunut. Nyt ryhmän osa, jossa solmu sijaitsee, on ilman johtajaa, joten uusi 38

47 johtaja on valittava. Jos korjaava solmu on ryhmän jäsensolmu, tulee siitä uusi ryhmänjohtaja. Jos solmu on vain puun jäsensolmu ja lisäksi sillä on vain yksi lapsisolmu, voi se poistaa itsensä puusta lähettämällä MACT-viestin (kts ). Viestin vastaanottanut solmu huomaa sen tulleen ryhmäjohtalle johtavasta linkistä, jolloin se päättelee verkon osittuneen. Tästä solmusta tulee ryhmän johtaja, jos se on ryhmän jäsensolmu. Jos tämäkin solmu on vain puun jäsensolmu ja sillä on vain yksi lapsisolmu, voi sekin poistaa itsensä puusta. Tätä jatketaan, kunnes ryhmän jäsensolmu saavutetaan. Jos puun jäsensolmulla on useampia lapsisolmuja, ei se voi poistaa itseään puusta. Solmu lähettää tässä tapauksessa jollekin lapsisolmuistaan MACT-viestin, jossa on ilmoitus, että vastaanottavan solmun tulee ryhtyä uudeksi ryhmänjohtajaksi. Jos vastaanottava solmu ei ole ryhmän jäsen, lähettää se viestin edelleen, kunnes ryhmän jäsensolmu saavutetaan. Vastavalittu ryhmänjohtaja lähettää erityisen päivitys-group hello -viestin, jolloin kaikki saavutettavissa olevat solmut päivittävät tietonsa uudesta ryhmänjohtajasta. Katkeamiskohdan ylävirran puoleinen solmu voi irrouttautua puusta, jos se ei ole ryhmän jäsensolmu, ja jos se katkeamisen vuoksi on jäänyt lehtisolmuksi. Solmu odottaa kuitenkin jonkin aikaa, ennen kuin se irroittautuu, koska korjattu reitti voi kulkea sen kautta Puiden yhdistäminen Verkon osittumisen vuoksi syntyneet saman ryhmän useat puut on yhdistettävä heti, kun eri osiot saavat jälleen yhteyden toisiinsa. Uusi yhteys osioiden välillä havaitaan, kun jokin puun jäsensolmu vastaanottaa vähintään kahden eri ryhmänjohtajan lähettämän group hello -viestin. Yhdistymisprosessin käynnistää se ryhmän jäsensolmu, jonka tunteman ryhmänjohtajan IP-osoite on pienempi. Solmu lähettää omalle ryhmänjohtajalleen (jolla on siis pienempi IP-osoite) unicastina RREQviestin, jossa on ilmoitus osioiden yhdistämisestä. Ryhmänjohtaja antaa solmulle luvan puiden yhdistämiseen lähettämällä RREP:n. Solmu lähettää nyt vuorostaan toiselle ryhmänjohtajalle unicastina RREQ-viestin, joka sisältää yhdistämisilmoituksen ja uusimman solmun tunteman ryhmän sekvenssinumeron. Vastaanottavasta ryhmänjohtajasta tulee nyt yhdistetyn ryhmän johtaja. Se valitsee viestissä olevasta ja itse ylläpitämästään sekvenssinumerosta suuremman uudeksi sekvenssinumeroksi ja vastaa yhdistämisen aloittaneelle solmulle RREP:llä, jolloin puun osat yhdistyvät. Uusi ryhmänjohtaja lähettää päivitys-group hello -viestin, jolloin kaikki puun solmut saavat tiedon uudesta ryhmänjohtajasta. 39

48 4.7 ODMRP ODMRP on mesh-pohjainen, on-demand -periaatteella toimiva ryhmälähetysprotokolla. Se ei tarvitse avukseen unicast-protokollaa, vaan se pystyy hoitamaan kaikki tarvittavat viestien lähetykset itse. Verkon solmuista kootaan ns. välitysryhmä (kts. 4.2), joka koostuu ryhmälähetysviestejä vastaanottavista solmuista sekä niitä yhdistävistä välittäjäsolmuista. Mikä tahansa ryhmän jäsensolmu voi toimia ryhmälähetysviestien lähettäjänä. Mesh-pohjaisena protokollana ODMRP sietää hyvin nopeastikin muuttuvaa verkon topologiaa Reititysinformaatio Jokainen ODMRP:tä tukeva solmu tarvitsee seuraavia reititystietotauluja: Jäsentaulu: Jokainen ryhmän jäsensolmu tallentaa jokaista ryhmää kohti, jonka jäsen solmu on, kaikkien niiden lähettäjien tunnisteet, joilta solmu haluaa vastaanottaa ryhmälähetyksiä. Jos esimerkiksi solmu kuuluu kahteen ryhmään, joista molemmista se vastaanottaa kolmen eri lähettäjän lähetyksiä, tulee jäsentauluun yhteensä kuusi merkintää. Jokaista merkintää kohti on ajastin. Jos lähettäjältä ei tule uutta join requestia ennen ajastimen laukeamista, poistetaan merkintä. Reititystaulu: Jokainen verkon solmu, oli se välittäjäsolmu tai ei, merkitsee join requestin saatuaan tähän tauluun sen lähettäneen solmun tunnisteen sekä sen naapurisolmun tunnisteen, jonka kautta viesti saapui. Tietoa käytetään liittymiseviestin ohjaamiseen oikeaan suuntaan. Välittäjäryhmätaulu: Jokainen välittäjäsolmu tallentaa jokaisen ryhmän tunnisteen, jonka välittäjänä solmu toimii. Jokaista ryhmää kohti on ajastin, joka nollautuu aina solmun saatua ryhmän osoitteella varustetun liittymisviestin. Viestien tallennustaulu: Jokainen verkon solmu tallentaa määräajaksi jokaisesta vastaanotetusta viestistä lähettäjän tunnisteen sekä paketin sekvenssinumeron. Solmu pystyy näin estämään samojen viestien välittämisen uudelleen. Jokainen solmu kasvattaa sekvenssinumeroa yhdellä aina, kun se lähettää minkä tahansa viestin. 40

49 4.7.2 Liittyminen ja ryhmälähetys Solmu lähettää määräajoin ryhmäänkutsumisviestiä (engl. join request) tulvimalla koko verkkoon, jos sillä on dataa lähetettävänä ryhmälle. Viestillä on kaksi tarkoitusta: se mainostaa ryhmän olemassaoloa verkolle ja se mahdollistaa solmujen liittymisen ryhmän jäseniksi. Jokainen solmu tallentaa sen naapurisolmun tunnistetiedot, jolta join request saapui ensimmäisenä. Näin jokainen solmu oppii, minkä naapurin kautta lyhin reitti lähettäjälle kulkee. Solmu lähettää viestin edelleen omille naapureillensa. Join request varustetaan viestin yksilöivillä tunnistetiedoilla, joten mikään solmu ei välitä myöhemmin tulleita viestejä sen jälkeen, kun ensimmäinen on välitetty. Kuva 4.9 esittää kahden eri lähettäjän join request -viestien kulun verkossa. Kuvassa näkyvät ne viestit, jotka tulevat kullekin solmulle ensimmäisenä. Näitä reittejä pitkin voivat kulkea seuraavassa esitetyt liittymisviestit. Kuva 4.9: Kahden lähettäjän join request -viestien reitit. Jos solmu haluaa tulla ryhmän jäseneksi, lähettää se join requestin saatuaan liittymisviestin (engl. join table) kohti lähettäjää samaa reittiä pitkin, mitä join request saapui. Liittymisviesti sisältää seuraavan hypyn (kohti lähettäjää) tunnisteen jokaista lähettäjää kohti, jota solmu haluaa kuunnella. Viesti voi siis sisältää maksimissaan yhtä monta eri naapurisolmun tunnistetta kuin kuunneltavia lähettäjäsolmuja kyseisellä vastaanottajasolmulla on. Liittymisviesti kulkeutuu takaisin lähettäjille lyhintä reittiä pitkin. Jokainen reitillä oleva solmu merkitsee itsensä välittäjäksi kyseiselle ryhmälle. Liittymisviestin tarkoitus onkin vain ilmoittaa jokaiselle solmulle, jonka kautta viesti kulkee, että kyseisen solmun tulee välittää halutun ryhmän vies- 41

50 tejä. Jos reitillä oleva solmu ei itse halua vastaanottaa ryhmälähetyksiä, tulee siitä vain välittäjäsolmu. Jokainen ryhmälähetysviestejä välittävä solmu välittää jokaisen lähettäjän viestejä ryhmälle. Näin saman solmun kautta voi kulkea useampien lähettäjien viestejä, jolloin ylimääräisiä lähetysreittejä syntyy. Kuva 4.10 esittää liittymisviestien kulun takaisin lähettäjille neljältä eri vastaanottajalta. Kuva 4.11 esittää syntyneitä reittejä ryhmälähetykselle. Kaikki välittäjäsolmut välittävät molempien lähettäjien ryhmälähetysviestejä. Kuva 4.10: Vastaanottajien liittyminen ryhmään. Kuva 4.11: Muodostunut mesh. 42

51 4.7.3 Ryhmästä poistuminen ja topologian muutokset Protokollassa ei käytetä mitään erityistä viestiä ryhmästä poistumiseksi. Ryhmän jäsensolmu lähettää join table -viestiä säännöllisin väliajoin niin kauan, kun se haluaa olla ryhmän jäsen. Jokaisella välittäjäsolmulla on ajastin jokaista ryhmää kohti. Aina liittymisviestin saatuaan nollaa välittäjäsolmu ajastimen, jolloin reitti pysyy voimassa taas tietyn ajan. Jos solmu ei saa liittymisviestiä ajastimen laukeamiseen mennessä, poistaa solmu ryhmän merkinnän omista reititystiedoistaan. Solmu lakkaa tällöin välittämästä ryhmän viestejä. Ryhmän jäsensolmu poistuu ryhmästä yksinkertaisesti lakkaamalla lähettämästä join table -viestejä, jolloin sille ei hetken kuluttua enää välity ryhmälähetyksiä. Vastaanottajasolmu voi myös lakata vastaanottamasta jonkin tietyn tai tiettyjen lähettäjien ryhmälähetysviestejä. Tällöin solmu poistaa kyseisen lähettäjän tunnisteen join table -viestistään. Verkon topologian muutoksista johtuvat yhteyksien katkeamiset eivät aiheuta ylimääräisiä toimia ODMRP:ssä. Jos lyhin reitti vastaanottajalta lähettäjälle katkeaa, saapuvat ryhmälähetysviestit todennäköisesti jotain toista reittiä. Jos muita reittejä ei kuitenkaan ole ryhmälähetyksen käytössä, korjaantuu tilanne seuraavan ryhmän mainostuksen ja sitä seuraavan liittymisviestin lähetyksen jälkeen. Ensimmäiseksi saapunut join request on nyt tullut jotain toista reittiä vastaanottajalle, jolloin vastaanottaja huomaa lyhimmän reitin katkenneen. Liittymisviesti lähetetään nyt tätä uutta reittiä pitkin kohti lähettäjää, jolloin sillä reitillä olevat solmut tulevat välittäjäsolmuiksi (jos eivät ennestään jo ole) aivan kuten edellisessä kohdassa esitettiin. Jos vastaanottaja ei saa ollenkaan ryhmäänkutsumisviestiä jollekin ryhmälle, on ryhmä joko lakkautettu tai verkko on osittunut. Tällöin ei suoriteta mitään toimenpiteitä, vaan odotetaan verkon yhdistymistä. 43

52 5 Ryhmälähetysprotokollien vertailua Tutkielman tarkoitus on selvittää olemassaolevien ryhmälähetysprotokollien soveltuvuus IP-TV -datan lähetykseen mobiilissa ad hoc -verkossa. Kaikkia neljää edellisessä luvussa esitettyä protokollaa ei vertailla keskenään, vaan niistä on valittu kaksi IP-TV:n tarpeisiin todennäköisesti parhaiten soveltuvaa. Valitut protokollat ovat: ADMR ja ODMRP. Karsinta perustui jo tehtyjen vertailevien tutkimusten tulosten tarkasteluun. Näitä tutkimuksia ei voida käyttää suoraan määrittämään protokollien soveltuvuutta IP-TV -sovelluksille, koska niissä on keskitytty vain reitityksen toiminnan tarkasteluun pienellä dataliikennemäärällä, joka ei vastaa millään lailla todellista IP-TV -liikennettä. Valittujen protokollien suorituskykyä mitataan simuloimalla ns-2 -verkkosimulaattorissa IP-TV -liikennettä ja protokollien toimintaa. Luvussa tehdään yhteenveto edellä esitettyjen protokollien tärkeimmistä suorituskykyyn vaikuttavista ominaisuuksista. Sen jälkeen esitellään simulointiympäristö, sekä käytetyt liikkumis- ja kommunikaatioskenaariot. Seuraavaksi perustellaan vertailtavien protokollien valinta. Luvun loppuosa koostuu tuloksien esittelystä ja testien johtopäätöksistä. 5.1 Kvalitatiivinen vertailu Seuraavaan taulukkoon on koottu edellä esitetyistä protokollista tärkeimpiä suorituskykyyn vaikutavia tekijöitä. Mikään protokollista ei muodosta reitityksessään silmukoita. Silmukat voisivat pahimmillaan lamauttaa täysin protokollan toiminnan. Jos protokolla käyttää erityisiä viestejä ryhmästä poistumiseen, voi ryhmään jäädä roikkumaan sellaisia solmuja, jotka eivät ryhmälähetystä halua vastaanottaa. Näin käy, jos poistumisviesti ei mene perille. 44

53 Taulukko 5.1: Protokollien tärkeimmät ominaisuudet. Ominaisuus ADMR CAMP MAODV ODMRP Ryhmän rakenne puu mesh puu mesh Sisältää silmukoita ei ei ei ei Riippuvuus unicast-protokollasta ei kyllä ei ei Jaksottainen tulvinta ei ei kyllä kyllä Erityinen poistumisviesti ei kyllä kyllä ei 5.2 Simulaatioympäristö Simuloinnissa käytetään samaa testiympäristöä kuin mitä ADMR -protokollan määrittelevässä dokumentissa [7] on käytetty. Muutamia muutoksia jouduttiin tekemään, jotta haluttua dataliikennettä pystytään simuloimaan. Tutkittavat protokollat on toteutettu osaksi ns-2 (network simulator 2) -verkkosimulaattoria [16]. Ns-2 on avoimen lähdekoodin simulaattori, jota voidaan käyttää useiden eri verkkoprotokollien simulointiin sekä langattomassa että perinteisessä verkossa. Käytetty versio on Houstonin Rice-yliopiston Monarch-projektin laajentama ns-2.1b8 [17]. Langaton siirtomedia perustuu Lucent Technologies -yhtiön WaveLAN tuotteeseen [18], joka tarjoaa 2 Mbit/s tiedonsiirtonopeuden ja ympärisäteilevän radiolinkin kantama on 250 metriä. Ns-2 on asennettu tietokoneeseen, jossa on Linux-ytimeen perustuva Debiankäyttöjärjestemä (versio 3.1, sarge ). Jokainen simulaation ajo kestää 300 sekuntia. Ajot toistetaan kukin kymmenen kertaa kymmenellä eri liikumisskenaariotiedostolla. 5.3 Solmujen liikkumisskenaariot Simuloitava verkko koostuu 100 mobiililaitteesta, jotka ovat reitityssolmuja. Solmut on sijoitettu satunnaisesti (satunnaisuus noudattaa tasaista jakaumaa) 1200x800 metrin laajuiselle alueelle. Jokainen solmu liikkuu satunnaisen reittipisteen (engl. random waypoint) -mallin [15] mukaisesti. Jokainen solmu liikkuu kohti satunnaista kohdetta alueella satunnaisella nopeudella, joka on välillä [0, maksiminopeus]. Kohteen saavutettuaan solmu odottaa ennaltamääritellyn ajan paikallaan, jonka jälkeen se valitsee uuden satunnaisen kohteen ja lähtee liikkeelle sitä kohti. Simulaatiossa käytetty paikaallaanodotusaika on nolla ja maksiminopeus on 20 m/s. Solmujen nopeudet voivat olla siis melko suuria, joten protokollien tulisi sietää hyvin mobiliteet- 45

54 tia. Liikkumismallissa käytetty satunnaisuus noudattaa tasaista jakaumaa. Satunnaisen reittipisteen mallia on käytetty useissa ad hoc -protokollien testauksissa, joten siksi malli on valittu tähänkin tutkimukseen. Solmujen liikkeet tallennetaan liikkumisskenaariotiedostoihin. Kun skenaariot on luotu, eivät solmujen liikkeet niissä enää muutu, joten samalla skenaariotiedostolla ajetut simulaatiot ovat solmujen liikkeiden kannalta aina identtisiä. 5.4 Kommunikaatioskenaariot Simulaation tarkoituksena on testata ADMR:n ja ODMRP:n soveltuvuutta IP-TV -tyyppisen datan välitykseen ryhmälähetyksenä mobiilissa ad hoc -verkossa. Jokaisen ryhmän oletetaan sisältävän yhden TV-kanavan. Jokaista kanavaa kohden on verkossa yksi lähettäjäsolmu, joten millään ryhmällä ei ole enempää kuin yksi lähettäjä (source). Mikään lähettäjä ei voi lähettää enempää kuin yhtä kanavaa. Lähettäjäsolmut ryhtyvät lähettämään dataa heti simulaation alussa ja jatkavat sitä simulaation loppuun asti. Vastaanottajat voivat kuulua simulaation aikana useampiin eri ryhmiin, sekä samaan ryhmään useamman kerran. Ryhmien vastaanottajasolmut valitsevat ryhmänsä, ryhmään liittymisajankohdan, sekä ryhmässä viipymisajan satunnaisesti. Satunnaisuus noudattaa tasaista jakaumaa. Solmujen ryhmän jäsenenäoloaika on aina välillä [1, 60] sekuntia. Solmujen ryhmään liittymis- ja ryhmästä poistumisajankohdat tallennetaan kommunikaatioskenaarioihin. Solmut ottavat samalla skenaariotiedostolla täsmälleen samalla tavalla yhteyksiä ryhmiin jokaisella simulaation ajokerralla. Merkinnällä RxLxV tarkoitetaan ryhmien (R), lähettäjien (L) ja vastaanottajien (V) jakautumista kommunikaatioskenaariossa. Skenaariot jakautuvat kahteen pääryhmään: Ryhmien määrän vaihtelu. Tällä pyritään tutkimaan kanavien määrän vaikutusta protokollien suorituskykyyn. Testaus suoritetaan kolmella eri skenaariolla: 1x1x20, 2x1x20 ja 4x1x20. Ryhmän koon vaihtelu. Tällä tutkitaan vastaanottajien lukumäärän vaikutusta protokollien suorituskykyyn. Tässä käytetään neljään eri skenaariota: 1x1x10, 1x1x20, 1x1x40 ja 1x1x80. Jokaisessa kommunikaatioskenaariossa käytetään kahta eri datan lähetysnopeutta. IP-TV:n mukaista liikennettä pyritään mallintamaan käyttämällä kuvan 5.1 mukaista liikennettä. Mittauksissa käytetty videodataa simuloiva tiedosto oli luotu enkoodaamalla videodataa MPEG-4 -standardin mukaisesti. Enkoodattua videodataa 46

55 Kuva 5.1: Pakettien lähetysnopeudet. lähetettiin verkkoon nopeudella 8 kbit/s [20]. Kuvassa näkyy verkkoon lähetettävän datan määrä yhden, kahden ja neljän IP-TV -kanavan tapauksessa. Nähdään että verkkoon lähetettävän datan määrä on suoraan verrannollinen kanavien lukumäärään. Kaikki simulaation ajot suoritetaan vertailun vuoksi myös käyttäen hyvin pientä datan lähetysnopeutta, jossa lähetetään 64 tavun kokoisia paketteja neljä kertaa sekunnissa, lähetysnopeuden ollessa tällöin 256 tavua sekunnissa. Tätä vakionopeuksista lähetystapaa kutsutaan CBR (engl. Constant Bit Rate) -lähetykseksi. Vastaavaa lähetysnopeutta on käytetty useissa ad hoc -protokollien vertailuissa, joissa on keskitytty pelkästään protokollien reitityskykyyn, eikä niiden soveltuvuutta minkään sovelluksen tarpeisiin. 5.5 Mitattavat arvot Protokollien suorituskykyä mitataan seuraavilla arvoilla: Vastaanottosuhde on solmun vastaanottamien datapakettien suhde sille lähetettyihin. Suhde on aina pienempi tai yhtä suuri kuin yksi. Tuloksissa ilmoitettu vastaanottosuhde on kaikkien solmujen vastaanottosuhteiden keskiarvo. Ylimääräinen viestitys paketetteina on lähetettyjen ja edelleenlähetettyjen kontrollipakettien lukumäärän suhde lähetettyihin ja edelleenlähetettyihin datapakettien määrään. Ylimääräinen viestitys tavuina on muuten sama kuin edellinen, mutta nyt tar- 47

56 kastellaan lähetettyjen ja edelleenlähetettyjen tavujen määrää. Päästä-päähän -viive tarkoittaa aikaa, joka kuluu datapaketin kulkuun lähettäjältä vastaanottajalle. Tuloksissa on ilmoitettu kaikkien pakettien keskimääräinen viive kaikille vastaanottajille. Ryhmään liittymisviive on aika, joka kuluu solmulta liittyä ryhmään. Kun solmu on halunnut liittyä ryhmään, kuluu aikaa liittymisviiveen verran ennenkuin solmu saa ensimmäisen sille tarkoitetun datapaketin. 5.6 Protokollavalintojen perustelut Kaikkia neljää edellisessä luvussa käsiteltyä protokollaa ei ole vertailtu keskenään samassa tutkimuksessa. Protokollien suorituskyvyistä on voitu kuitenkin muodostaa suuntaa-antava kuva vertailemalla useampaa tutkimusta, joissa suurin osa näistä protokollista on esiintynyt [12] [13] [14] Vaatimukset suorituskyvystä IP-TV -tyyppinen data tuo testattaville protokollille tiettyjä erityisvaatimuksia. Tiedonsiirto on suoratoistoa (engl. streaming), eli reaaliaikaista. Pakettien mahdollisimman varma perillemeno on erityisen tärkeää, jotta TV-kuvassa ei esiintyisi paljoa katkoja. Datapakettien perillemenoon kuluva aika lähettäjältä vastaanottajille, eli päästä-päähän -viive ei saa kasvaa liian suureksi. Ryhmäänliittymisviive riippuu paljolti päästä-päähän -viiveestä. Käyttäjä huomaa liittymisviiveen esimerkiksi selatessaan kanavia läpi ja olisi hyvä, jos viive pysyisi kohtuullisen pienenä. Hyvä liikkuvuuden sieto on kaikille sovelluksien kannalta toivottava ominaisuus reititysprotokollalta, joten sitä on painotettu eniten tutkittavien protokollien valinnassa Protokollien vertailu Tärkeimät protokollien valintoihin vaikuttaneet tutkimukset ovat ADMR:n, ODMRP:n ja MAODV:n keskinäiset vertailut [12] sekä ODMRP:n ja CAMP:n vertailu [14]. Tutkimuksessa [12] käytettiin samanlaista satunnaisen reittipisteen -mallia liikkumisskenaarioille kuin tässäkin tutkimuksessa. Alueen koko, solmujen maksiminopeus ja paikallaanodotusaika ovat myös kaikki samoja kuin tässä tutkimuksessa. ADMR ja ODMRP olivat melko tasaväkisiä kaikissa käytetyissä kommunikaatioske- 48

57 naarioissa. MAODV:n suorituskyky havaittiin selkeästi heikoimmaksi. MAODV:llä oli selvästi suurin viive lähes kaikissa tapauksissa. Vastaanottosuhde oli MAODV:llä lähes yhtä hyvä kuin ADMR:llä ja ODMRP:llä suurimmassa osassa skenaarioista, mutta ryhmien lukumäärän suurentaminen heikensi MAODV:llä vastaanottasuhdetta selkeästi muita enemmän. Koska tässä tutkimuksessa painotetaan hyvää vastaanottasuhdetta erityisesti useitä ryhmälähetysryhmiä sisältävässä verkossa, ei MAODV:ta otettu mukaan protokollien vertailuun. ADMR:ää ja ODMRP:tä suurempi viive paketeille vaikutti myös valintaan. CAMP:n suorituskyky osoittautui selvästi heikommaksi kuin ODMRP:n niiden keskinäisessä vertailussa. Tutkimuksessa tarkkailtiin myös solmujen liikkumisnopeuden vaikutusta protokollaan. Solmujen nopeuksia kasvatettiin nollasta 20 metriin sekunnissa. CAMP:n pakettien vastaanottosuhde oli nollaa lukuunottamatta kaikilla nopeuksilla ODMRP:n vastaavaa heikompi, ja CAMP:n vastaanottosuhde heikkeni oleellisesti nopeuksien kasvaessa. Pääasiallisena syynä tähän on CAMP:n tarvitseman proaktiivisen unicast -protokollan heikko suorituskyky, kun verkon topologia muuttuu usein ODMRP:n vastaanottosuhde pysyi lähes ennallaan kaikilla käytetyillä nopeuksilla. Huono mobiliteetin sieto oli suurin syy CAMP:n jättämiseen pois verrattavien protokollien joukosta. 5.7 Tulokset Seuraavaan on koottu mitattavien arvojen keskiarvot, kun jokainen kommunikaatioskenaario on ajettu simulaattorilla kymmenen kertaa, kymmenellä eri liikkumisskenaariolla. Ensin vaihdellaan ryhmän kokoa, jonka jälkeen muuttujana on ryhmien määrä Ryhmän koon vaihtelu Pienellä liikennemäärällä datapakettien vastaanottosuhde (kuva 5.2) on molemmilla protokollilla erittäin hyvä kaikissa skenaarioissa. Ryhmän koon suurentaminen parantaa molemmilla protokollilla vastaanottosuhdetta. Pienellä ryhmän koolla ADMR:n vastaanottosuhde on hieman heikompi kuin ODMRP:n, mutta ero tasoittuu ryhmän koon kasvaessa. Molemmilla protokollilla paketit voivat saapua useita reittejä vastaanottajille, joten suurempi ryhmän koko lisää myös reittien määrää ja siten parantaa vastaanottosuhdetta. ODMRP muodostaa jo vähäiselläkin solmujen määrällä ADMR:ää enemmän reittejä vastaanottajille, joten sillä on hyvä vastaanottosuhde pienilläkin ryhmillä. 49

58 Videoliikenne heikentää kummallakin protokollalla kaikissa skenaarioissa hieman vastaanottosuhdetta verrattuna CBR-liikenteeseen. ODMRP suoriutuu jälleen hieman ADMR:ää paremmin, erityisesti pienimmällä ja suurimmalla ryhmän koolla. Ryhmän koon kasvu parantaa tässäkin tapauksessa vastaanottosuhdetta. Kuitenkin suurimmalla ryhmällä ADMR:n suorituskyky heikkenee. Syynä tähän saattaa olla lisääntynyt kontrolliliikenteen määrä verkossa. Kuva 5.2: Datapakettien vastaanottosuhde. CBR-liikenteellä molempien protokollien datapakettien kokema viive (kuva 5.3) on hyvin pieni. ODMRP:llä se on lähes vakio kaikilla skenaarioilla, koska protokolla pyrkii lähettämään datan lyhintä mahdollista reittiä. ADMR:llä viive laskee ryhmän kasvaessa. ADMR:n muodostama ryhmälähetyspuu sijaitsee solmun liittymishetkellä lyhimmällä mahdollisella reitillä lähettäjältä, mutta ajan kuluessa reitin solmut saattavat liikkua siten, että reitti pidentyy. Suurella ryhmän koolla vastaanottajasolmulle on olemassa useampia reittejä, joten viestit saapuvat sille lyhintä reittiä suuremmalla todennäköisyydellä kuin pienen ryhmän tapauksessa. Suuremmalla lähetysnopeudella molemmilla protokollilla viive kasvaa selvästi. Verkon korkeampi kuormitus lisää langattomalla siirtotiellä tapahtuvien lähetysten määrää. Solmut joutuvat törmäyksen mahdollisuutta vähentääkseen odottamaan kauemmin, ennenkuin ne voivat itse lähettää dataa eteenpäin. Viestien käsittely solmulla vie aikaa, ja mitä enemmän solmulle tulee viestejä käsiteltäväksi, sitä kauemmin niiden edelleenlähettäminen kestää. Videodatan lähetyksessä voidaan jo 50

59 Kuva 5.3: Datapakettien viive. havaita selviä eroja protokollien välillä. ODMRP:llä viive on yli viisinkertainen pieneen lähetysnopeuteen verrattuna, mutta se pysyy kuitenkin lähes vakiona, vaikka ryhmän kokoa kasvatetaan. ADMR:llä viive kasvaa jo eksponentiaalisesti, kun ryhmän koko ylittää 20 vastaanottajaa. ADMR:n suorituskykyä heikentää verkon kontrolliviestien määrän huomattava lisääntyminen suuremmalla ryhmän koolla, joka kasvattaa verkon kuormitusta entisestään. Solmujen ryhmään liittymiseen kuluva viive (kuva 5.4) noudattaa hyvin samankaltaista mallia CBR-liikenteellä kuin datapakettien kokeman viiven tapauksessa. ADMR:n liittymisviive laskee ryhmän koon kasvaessa ja ODMRP:n liittymisviive pysyy lähes vakiona, kuitenkin hieman laskien. Viiveen pienenemiseen on pääasiassa syynä parantunut vastaanottosuhde paketeille, jolloin liittymispyynnöt saapuvat todennäköisemmin perille ilman niiden uudelleenlähettämisiä. Kun ryhmän koko kasvaa ADMR:ssä, kasvaa myös todennäköisyys, että liittyvän solmun lähellä on solmu, jolla on tiedossaan reitti lähettäjälle. Tällöin ryhmään liittyminen nopeutuu, kun liittymisviesti voidaan lähettää unicastina (kts ). ODMRP:llä viive on suurempi, koska siinä solmu voi liittyä ryhmään vasta jaksottaisen ryhmän mainostusviestin saatuaan (kts ). Mainostusviesti on asetettu tässä simulaatiossa lähetettäväksi kolmen sekunnin välein, josta seuraa keskimäärin vähintään puolentoista sekunnin viive ryhmään liittymiselle jokaisella solmulla. Videoliikenteellä voidaan havaita pienoisena yllätyksenä, että suuremmalla liikenteen määrällä ei ole juuri mitään vaikutusta ODMRP:n liittymisviiveeseen. 51

60 Kuva 5.4: Ryhmäänliittymisviive. ADMR:n tapauksessa taas liittymisviive kasvaa edellisessä kohdassa (datapakettien viive) esitetyistä syistä johtuen ryhmän koon kasvaessa. Toinen syy protokollien suorituskykyjen eroavaisuuksiin on ryhmään liittymisen suoritustavassa. ODMRP:ssä liittymiseen riittää vain yksi vastaanottajan lähettämä viesti. ADMR:ssä liittyminen on kolmivaiheinen (kts ), jossa lähettäjä lähettää yhden ja vastaanottaja kaksi viestiä. Selvästi pakettien viiveet hidastavat ADMR:n liittymisprosessia ODMRP:tä enemmän. CBR-liikenteellä ODMRP:ssä lähetettyjen ja edelleenlähetettyjen kontrollipakettien suhde datapaketteihin (kuva 5.5) laskee, kun ryhmän kokoa kasvatetaan. ODMRP:ssä verkon topologian muutokset eivät vaikuta millään lailla kontrolliviestien määrään, joten niiden määrä pysyy nytkin vakiona. Ryhmän koon kasvattaminen lisää ainoastaan edelleenlähetettyjen datapakettien määrää. ADMR:ssä ylimääräinen viestitys vähenee aluksi, mutta kasvaa suuremmalla ryhmän koolla. Kasvun syynä on todennäköisesti lisääntyneet reitinkorjaustoimenpiteet, koska solmuja on enemmän. Videodatalla ODMRP:n ylimääräinen viestitys noudattaa samaa kaava kuin CBRliikenteellä. Nyt suuremmasta lähetysnopeudesta johtuen datapaketteja on vielä enemmän suhteessa kontrollipaketteihin. ADMR:n ylimääräinen viestitys on pienellä ryhmällä samasta syystä myös pienempi kuin CBR-liikenteellä, mutta suurimmalla ryhmän koolla se on jo selkeästi suurempi. Suuremmasta datan lähetysnopeudesta johtuen viestien törmäykset lisääntyvät. Solmut voivat tällöin olettaa vir- 52

61 Kuva 5.5: Ylimääräinen viestitys paketteina. Kuva 5.6: Ylimääräinen viestitys tavuina. heellisesti, että yhteys lähettäjään on poikki, jolloin ne ryhtyvät tarpeettomiin puun korjaustoimenpiteisiin. Mitä enemmän ryhmässä on solmuja, sitä enemmän kontrolliviestitystä lisääviä turhia korjaustoimenpiteitä suoritetaan. Ylimääräinen viestitys tavuina (kuva 5.6) noudattaa suurinpiirtein samaa kaavaa kuin pakettien tapauksessa. Kontrollipakettien koot ovat yleensä vain murto- 53

62 osa verrattuna datapaketteihin. ADMR käyttää tässä simulaatiossa ryhmän mainostukseen vanhentuneita datapaketteja sellaisenaan, eikä esimerkiksi datapaketteja ilman hyötykuormaa. Ryhmän mainostusviestien paketit ovat nyt siis turhan isoja ja aiheuttavat tarpeetonta verkon kuormitusta. ADMR voi tarvittaessa käyttää mainostukseen datapaketteja ilman hyötykuormaa, mutta sellaista toimintoa ei ole tähän simulaatioon mallinnettu. ODMRP:n käyttämät kontrolliviestit ovat kaikki minimaalisen pieniä, joten tavuina laskettuna kontrolliviesteihin kuluu mitättömän vähän verkon resursseja Ryhmien määrän vaihtelu Kuva 5.7: Datapakettien vastaanottosuhde. Pienellä lähetysnopeudella protokollat olivat lähes tasavertaisia ja niiden vastaanottosuhde (kuva 5.7) pysyi hyvin korkeana kaikilla kolmella skenaariolla. Suhde kuitenkin laski tasaisesti molemmilla, mikä johtui useamman lähettäjän tuomasta lisääntyneestä liikenteestä. Videodatan lähetyksessä molempien protokollien vastaanottosuhde laski hyvin voimakkaasti ryhmien määrää lisättäessä. Syynä tähän on lisääntynyt lähetettävän datan määrä. On kuitenkin yllättävää, miten paljon lisääntynyt datan määrä heikentää vastaanottosuhdetta molemmilla protokollilla. Neljän ryhmän tapauksessa yhdelle solmulle voi tulla enintään 4x8 kilotavua sekunnissa dataa käsiteltäväksi, mikä on vain kahdeksasosa solmun maksimitiedonsiirtonopeudesta! ADMR suoriutui ODMRP:tä heikommin kaikissa skenaarioissa. Syynä 54

63 Kuva 5.8: Datapakettien viive. on todennäköisesti kontrolliviestien moninkertainen määrä verrattuna ODMRP:hen sekä paketteina että tavuina. CBR-liikenteellä datapakettien viiveet (kuva 5.8) pysyivät lähes vakioina. ADMR:n viive oli kuitenkin selvästi suurempi. Videodatalla taas viiveet nousivat molemmilla eksponentiaalisesti, ADMR:llä vielä kertaluokkaa voimakkaammin kuin ODMRP:llä. Pääsyynä tähän lienevät samat kuin kohdassa viiveille esitetyt seikat: solmujen pyrkimys välttämään törmäyksiä ja pakettien prosessointiviive solmuilla, sekä ADMR:n tapauksessa lisääntynyt kontrolliviestien määrä. Useamman ryhmän tapauksessa solmuilla saattaa olla monta naapuria, joiden radiolähettimen kantamalla solmu on. Solmu saattaa kuulla esimerkiksi neljän eri ryhmän datalähetykset lähes yhtäaikaisesti useilta naapurisolmuiltaan. Solmu joutuu siten mahdollisesti odottamaan hyvinkin kauan lähetysvuoroaan. Mitä tiheämmässä lähettävät solmut sijaitsevat alueella, sitä suurempi viive paketeilla on. Pienellä datamäärällä ODMRP:n ryhmäänliittymisviive (kuva 5.9) pieneni hieman ryhmien määrää kasvatettaessa, ollen kuitenkin lähes vakio, noin puolitoista sekuntia. Syy on sama kuin kohdan ryhmäänliittymisviiveeseen, eli kolmen sekunnin välein tehtävä ryhmän mainostus. ADMR:llä havaittiin odotusten vastaisesti viiveen pieneminen ryhmien määrän kasvaessa. Viiveen pieneneminen on järkeenkäypää ryhmien koon kasvaessa, mutta useamman samankokoisen ryhmän lisääminen verkkoon pitäisi päinvastoin kasvattaa viivettä. Syytä ADMR:n liittymisviiveen pienenemiseen ei löydetty. 55

64 Kuva 5.9: Ryhmäänliittymisviive. Videodatan tapauksessa ODMRP:n viive oli ADMR:ää pienempi, kun ryhmien määrää lisättiin. Viive ei kuitenkaan enää pienentynyt myös videodatalla (vrt ), vaan oli neljän ryhmän tapauksessa jopa suurempi. Kasvanut verkon kuormitus aiheutti ruuhkaa solmuilla ja sitä myötä viive kasvoi. ADMR:llä viive kasvoi osin samasta syystä, mutta lisäksi kolmivaiheinen liittymisprosessi kasvatti sitä. CBR-liikenteellä ylimääräinen viestitys (kuva 5.10) pysyi lähes vakiona molemmilla protokollilla. Kontrollipakettien määrä kasvoi ODMRP:llä, koska ryhmiä oli useampia mainostettavana, mutta samalla kasvoi myös datapakettien määrä. ADMR:llä kontrollipakettien määrä kasvoi myös samassa suhteessa datapaketteihin nähden. Videodatalla ODMRP:n lähettämien kontrollipakettien määrä ryhmää kohden pysyy edelleen vakiona. Ylimääräisen viestityksen pienoinen kasvu neljän ryhmän tapauksessa johtunee datapakettien huonommasta vastaanottosuhteesta. Verkossa liikkuu nyt siis suhteessa hieman enemmän kontrolli- kuin datapaketteja. ADMR joutuu lähettämään noin kolminkertaisen määrän kontrollipaketteja, kun ryhmien määrä kaksinkertaistetaan. Ero ODMRP:hen on siis merkittävä. Kontrollipakettien lähetysten lisääntymisen aiheuttaa törmäysten määrän kasvu, kuten kohdassa on selitetty. Useampi ryhmä lisää vielä verkon kuormitusta, joka kasvattaa lähetettävien kontrollipakettien määrää entisestään. Tavuina laskettuna ylimääräisen viestityksen määrä (kuva 5.11) oli protokollilla melkein samanlainen kuin paketteina laskettuna. ODMRP:n kontrollipakettien koot 56