Ryhmälähetys mobiileissa ad hoc -verkoissa · Tekijä: Teijo Venäläinen Yhteystiedot: [email protected] Työn nimi: Ryhmälähetys mobiileissa ad hoc -verkoissa Title in English:

Teijo Venäläinen

Ryhmälähetys mobiileissa ad hoc -verkoissa

Tietotekniikanerikoistyö20. tammikuuta 2006

Jyväskylän yliopisto

Tietotekniikan laitos

Jyväskylä

Tekijä: Teijo VenäläinenYhteystiedot: [email protected]ön nimi: Ryhmälähetys mobiileissa ad hoc -verkoissaTitle in English: Multicast in Mobile Ad Hoc NetworksTyö: Tietotekniikan erikoistyöSivumäärä: 55Tiivistelmä: Ryhmälähetys on tapa lähettää dataa jollekin joukolle kuluttamatta tur-haan tietoliikennekaistaa. Tämä on erityisen tärkeää mobiiliverkoissa, joissa kais-tasta on aina pulaa. Mobiililaitteet voivat muodostaa keskenään ns. mobiilin ad hoc-verkon (MANET) ilman minkään ulkopuolisen laitteen ohjausta. Tällainen verkkovoi toimia siis täysin ilman olemassaolevaa verkkoinfrastruktuuria. MANET:ille onolemassa monia käyttökohteita, kuten esimerkiksi pikainen verkon pystytys kata-strofialueilla, erilaiset sensoriverkot tai matkapuhelinverkon kapasiteetin paranta-minen. Ryhmälähetyksen ja MANET:n yhdistäminen on tällä hetkellä tärkeä tutki-musaihe.English abstract: Multicasting is a bandwidh-efficient way to send data to a speci-fic group. This is especially important in mobile networks where bandwidht is li-mited. Mobile nodes may form a mobile ad hoc -network (MANET) amongst them,without any help from other equipment. This kind of network may function wit-hout any existing network infrastructure. There are many applications for MANET,like emergency networks in catastrophic areas, sensor networks or enhancing cellu-lar network’s capacity. Combining multicast and MANET is a crucial researh issuenowadays.Avainsanat: ryhmälähetys, ad hoc, protokollaKeywords: multicast, ad hoc, protokolla

Sisältö

1 Johdanto 1

2 Ryhmälähetys 22.1 Ryhmälähetysen tarve . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 Multicast reititys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Ryhmien muodostus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.4 Multicast-puut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4.1 Lähdepuut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4.2 Jaetut puut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4.3 Hybridimallit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Mobiilit ad hoc -verkot 93.1 Yleistä ja käyttökohteita . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.1 Solun sisäinen dataliikenne . . . . . . . . . . . . . . . . . . . . 103.1.2 Dataliikenne solun ulkopuolelle . . . . . . . . . . . . . . . . . 11

3.2 Reititys mobiileissa ad hoc -verkoissa . . . . . . . . . . . . . . . . . . 123.2.1 Reitityksen haasteet . . . . . . . . . . . . . . . . . . . . . . . . 123.2.2 Proaktiivinen reititys . . . . . . . . . . . . . . . . . . . . . . . . 143.2.3 Reaktiivinen reititys . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Ryhmälähetys MANET:issa 184.1 Yleistä . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.2 Ryhmien rakenteet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.3 Protokollien perustyypit . . . . . . . . . . . . . . . . . . . . . . . . . . 204.4 CAMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4.1 Reititysinformaatio . . . . . . . . . . . . . . . . . . . . . . . . . 224.4.2 Ryhmään liittyminen ja ryhmästä poistuminen . . . . . . . . . 234.4.3 Topologian muutokset . . . . . . . . . . . . . . . . . . . . . . . 24

4.5 ADMR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.5.1 Pakettien välittäminen . . . . . . . . . . . . . . . . . . . . . . . 274.5.2 Reititysinformaatio . . . . . . . . . . . . . . . . . . . . . . . . . 294.5.3 Lähettäjäksi tuleminen . . . . . . . . . . . . . . . . . . . . . . . 30

i

4.5.4 Ryhmään liittyminen ja ryhmästä poistuminen . . . . . . . . . 304.5.5 Topologian muutokset ja puun korjaustoimenpiteet . . . . . . 31

4.6 MAODV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.6.1 Unicast-toiminto (AODV) . . . . . . . . . . . . . . . . . . . . . 334.6.2 Reititysinformaatio . . . . . . . . . . . . . . . . . . . . . . . . . 354.6.3 Pakettien lähettäminen . . . . . . . . . . . . . . . . . . . . . . . 364.6.4 Ryhmään liittyminen ja ryhmästä poistuminen . . . . . . . . . 364.6.5 Puun korjaus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.6.6 Puiden yhdistäminen . . . . . . . . . . . . . . . . . . . . . . . 40

4.7 ODMRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.7.1 Reititysinformaatio . . . . . . . . . . . . . . . . . . . . . . . . . 414.7.2 Liittyminen ja ryhmälähetys . . . . . . . . . . . . . . . . . . . 414.7.3 Ryhmästä poistuminen ja topologian muutokset . . . . . . . . 43

5 Ryhmälähetysprotokollien vertailua 455.1 Kvalitatiivinen vertailu . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.2 ADMR, MAODV ja ODMRP vertailussa . . . . . . . . . . . . . . . . . 46

5.2.1 Ryhmän koon vaihtelu . . . . . . . . . . . . . . . . . . . . . . . 465.2.2 Lähettäjien lukumäärän vaihtelu . . . . . . . . . . . . . . . . . 47

5.3 CAMP ja ODMRP vertailussa . . . . . . . . . . . . . . . . . . . . . . . 485.3.1 Solmujen nopeuksien vaikutus . . . . . . . . . . . . . . . . . . 485.3.2 Ryhmän koon vaikutus . . . . . . . . . . . . . . . . . . . . . . 495.3.3 Lähettäjien lukumäärän vaikutus . . . . . . . . . . . . . . . . . 49

5.4 Tutkimusten johtopäätöksiä . . . . . . . . . . . . . . . . . . . . . . . . 49

Viitteet 51

ii

1 Johdanto

Nopeiden internet-yhteyksien määrä on kasvanut viime vuosina valtavasti. Samoinmarkkinoille tulee yhä uusia sovelluksia, jotka vaativat nopeaa yhteyttä. Esimerk-kejä näistä ovat esimerkiksi videoneuvottelu, televisio-ohjelmien katsominen ja eri-laiset moninpelit. Kaikkien edellämainittujen sovellusten liikennöinti verkossa nou-dattaa samanlaista kaavaa: lähettäjä välittää dataa jollekin ryhmälle vastaanottajia.Tästä syystä onkin kehitetty ryhmälähetystekniikka, jolla edellä mainitun kaltainenliikennöinti saadaan toteutettua mahdollisimman vähällä vaivalla.

Mobiililaitteet ovat myös nykyään kovassa huudossa, kun ”perinteisen” interne-tin sovelluksista ja palveluista tehdään mobiiliversioita. Laitteille kehitetään jatku-vasti myös täysin uudentyyppisiä sovelluksia, jotka ovat tiukasti kytköksissä mo-biiliuteen.

Mobiili ad hoc-arkkitehtuuri on keino, jolla (yleensä) langattomat laitteet voivatmuodostaa keskenään toimivan verkon. Mobiili ad hoc-verkossa (MANET) kaikkimobiililaitteet (eli solmut) ovat sekä päätelaitteita että reitittimiä. Ryhmälähetyksentoteuttamista MANET:issa ei ole tutkittu vielä kovin paljoa, pääpainon ollessa ta-vallisten yhdeltä yhdelle -protokollien tutkimuksessa. Ryhmälähetysprotokollia ontoki kehitetty, mutta ne eivät ole vielä lähellekään valmiita.

Luku 2 käsittelee ryhmälähetystä. Luvussa esitetään, miksi sitä tarvitaan ja pe-riaatteet sen toteuttamiseksi. Luvussa 3 selvitetään, mikä on mobiili ad hoc -verkkoja miten reititys toteutetaan siinä. Luku 4 esittelee ryhmälähetyksen toteutusta mo-biilissa ad hoc -verkossa. Luvussa esitetään kaksi erilaista ryhmän luomistapaa, sekämuutamia mobiileissa ad hoc -verkoissa toimivien ryhmälähetysprotokollien perus-tyyppejä. Luvun lopuksi tutustutaan hieman tarkemmin neljään erilaiseen ryhmälä-hetysprotokollaan. Viimeiseen lukuun on koottu vertailevien tutkimusten tuloksiaja niiden johtopäätöksiä luvussa 4 esitetyistä protokollista.

1

2 Ryhmälähetys

Ryhmälähetys (engl. multicast) tarkoittaa viestintää tietylle ennaltamäärätylle jou-kolle, joka on yksilöity joukolle yhteisellä osoitteella. Tässä luvussa selvitetään aluk-si, miksi ryhmälähetys on tietyissä tapauksissa tarpeellista. Sen jälkeen vertaillaanryhmälähetyksen eroa normaaliin pakettien lähetystapaan internetissä. Lopuksi tu-tustutaan 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 pa-ketteja. Lähettäjällä ja vastaanottajalla on molemmilla omat IP-osoitteensa, joidenperusteella paketit reititetään perille. Toinen, vähemmän käytetty tapa on lähettäädataa kaikille laitteille (engl. broadcast), erityisellä yleislähetysosoitteella varustetul-la viestillä.

Esimerkiksi ns. nettipeleissä, sekä videoneuvottelussa ja televisio-ohjelmien lä-hetyksessä internetin välityksellä yksi taho (palvelin tai tavallinen tietokone) joutuulähettämään täsmälleen saman datan monelle vastaaottajalle. Perinteisin menetel-min lähetys voitaisiin toteuttaa siten, että sama data lähetettäisiin unicast-menetel-mällä jokaiselle vastaanottajalle erikseen (kuva 2.1). Koska esimerkiksi reaaliaikai-sen videokuvan välitys vaatii melko suurta tiedonsiirtokaistaa, ei tällainen monis-taminen ole toivottavaa.

2

Kuva 2.1: Unicast-lähetys.

Toinen keino olisi välittää videokuva broadcast-menetelmällä (kuva 2.2), jolloindatan 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 syntyyturhaa liikennettä verkossa. Lisäksi broadcast-viestejä ei tietoturva- ja kaistansäästö-syistä juurikaan päästetä aliverkkojen ulkopuolelle, joten edellä mainitut sovelluk-set eivät käytännössä voi lainkaan käyttää yleislähetystä.

Kuva 2.2: Broadcast-lähetys.

Koska edellämainitut menetelmät eivät sovi hyvin datan lähettämiselle vastaa-nottajajoukolle, on ollut tarpeen kehittää menetelmä juuri tätä tilannetta varten. Me-netelmää kutsutaan ryhmälähetykseksi ja sen periaate muistuttaa hieman yleislähe-tystä. Lähettäjän tarvitsee lähettää dataa vain yhteen, ryhmän yksilöivään ryhmä-

3

lähetysosoitteeseen, jolloin vältetään datan monistaminen. Verkko osaa nyt välit-tää datan osoitteen perusteella vain sitä vastaanottaville laitteille, jolloin vältetäänbroadcastin aiheuttama ylimääräinen kuormitus.

2.2 Multicast reititys

Internetiin yhteydessä olevat tietokoneet on jaoteltu eri kokoisiin aliverkkoihin. Täl-lä tavoin saadaan esimerkiksi eri maantieteellisillä alueilla ja eri organisaatioidenlaitteet pidettyä loogisella tasolla erillään. Toinen tärkeä syy aliverkotukseen on ra-jallisen IP-osoiteavaruuden saaminen riittämään yhä kasvaville laitemäärille. Inter-netin arkkitehtuuri koostuukin aliverkoista ja niitä yhdistävistä reitittimistä. Reitit-timien tehtävänä on hallita liikennettä verkossa siten, että periaatteessa kaikki verk-koon kytketyt laitteet pystyvät viestimään toisilleen. Reitittimet pitävät yllä enem-män tai vähemmän reaaliaikaista tietoa verkon topologiasta ja pystyvät siten ohjaa-maan tietoliikennettä lähettäjiltä vastaanottajille.

Kuva 2.3: Ryhmälähetys.

Ryhmälähetyksessä kaistan säästöä saavutetaan muodostamalla lähettäjästä javastaanottajista puumaisen rakenteen omaava joukko. Puun juurena on lähettäjä(täsmällisemmin sanottuna juurisolmu on reititin, jonka liityntään lähettäjä on kyt-ketty) 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 yhteysryhmälähetystä vastaanottaviin solmuihin/laitteisiin. Nämä voivat olla joko suo-rassa yhteydessä vastaanottajiin tai ovat yhteydessä toisiin ryhmälähetykseen osal-

4

listuviin reitittimiin. Solmulla voi olla yksi tai useampi alisolmu. Jokainen reititinmonistaa saamiaan ryhmälähetysviestejä vain niin monta kuin sillä on suoria ali-solmuja. Puumaisella rakenteella saavutetaan oleellista hyötyä: yhdelläkään reitit-timien välisellä linkillä ei esiinny samaa viestiä kahta kertaa, eikä viesti voi saapuasolmulle useampaa kuin yhtä reittiä. Lisäksi reitittimien reitityspäätökset yksinker-taistuvat: jos reitittimellä on alisolmuja, välitetään viesti niille aina. Kuvassa 2.3 onesitetty yksinkertainen multicast-reititystä käyttävä verkko ja siihen liittyvä reititys-puu.

2.3 Ryhmien muodostus

Jotta halukkaille vastaanottajille voitaisiin lähettää dataa ryhmälähetyksenä, on niis-tä ensin koottava ryhmä ja annettava sille osoite. Aloitteen ryhmän luomiseksi tekeese laite, joka haluaa lähettää multicast-paketetteja. Reitittimestä, johon aloitteen teke-vä laite on kytketty, tulee luotavan reitityspuun juurisolmu. Halukkaat vastaanot-tajat lisätään juurisolmun alisolmuiksi. Alisolmujen lisäykseen on olemassa kaksitapaa: ns. datapohjainen (engl. data-driven) ja vastaanottajapohjainen (engl. receiver-driven).

Datapohjaisessa menetelmässä juurisolmu lähettää tasaisin väliajoin ryhmälähe-tysviestejä ns. tulvimismenetelmällä, jolloin kaikki verkon laitteet saavat viestit. Joslaite ei halua vastaanottaa ryhmälähetystä, on sen ilmoitettava siitä erikseen lähim-mälle reitittimelle (solmulle). Reititin harventaa (engl. prune) tällöin itsensä puus-ta, jos yksikään siihen kytketyistä laitteista ei halua vastaanottaa ryhmälähetystä.Harvennuksella estetään turhaa ryhmälähetystä laitteille, jotka eivät sitä vastaano-ta. Datapohjainen menetelmä on käyttökelpoinen, jos suurin osa verkon laitteistahaluaa vastaanottaa ryhmälähetystä. Tällöin ryhmälähetyksen tulvinta koko verk-koon ei tuhlaa liikaa kaistaa.

Vastaanottajapohjaisesti toimiessa jokaisen laitteen tulee ilmoittaa, jos se halu-aa vastaanottaa ryhmälähetystä. Laitteille ei siis ohjata multicast-viestejä ennen kuinlaite on halukkuudestaan erikseen ilmoittanut. Ryhmälähetyspuuta kasvatetaan sol-mu kerrallaan tarpeen mukaan. Puun harvennus on usein ajastimiin perustuvaa,jossa solmu poistetaan, jos siltä ei ole tullut määräajan sisällä ilmoitusta halukkuu-desta vastaanottaa ryhmälähetystä. Laitteiden tuleekin lähettää toistuvasti ilmoi-tus, jotta se pysyy osana multicast-ryhmää. Vastaanottajapohjainen menetelmä so-veltuu paremmin sellaisille verkoille, joissa ryhmälähetystä vastaanottavien reititti-mien osuus on pieni.

Jokaiselle ryhmälle annetaan oma ryhmälähetysosoite, jonka perusteella ryh-

5

mät voidaan erottaa toisistaan. Ryhmän jäsenet käyttävät tätä osoitetta lähettääk-seen ryhmälähetysviestejä ja verkon reitittimet osaavat osoitteen perusteella välit-tää viestit jokaiselle ryhmän jäsenelle. Osoitteeksi valitaan kullekin ryhmälle jokinIP-osoiteavaruuden ryhmälähetysosoitteille varatuista IP-osoitteista.

2.4 Multicast-puut

Ryhmälähetyspuu kuvaa kaikkia linkkiyhteyksiä, joita pitkin ryhmälähetysviestitkulkevat lähettäjältä kaikille vastaanottajille. Solmun (reitittimen) kannalta on sa-ma, millainen alipuu reitittimen lapsisolmujen alla on. Reitittimelle riittää siis vaintieto, että lapsisolmu vastaanottaa ryhmälähetysviestejä, jolloin se lähettää yhdenviestin kutakin lapsisolmuaan kohti. Multicast-ryhmällä voi aina olla joko yksi taiuseampi lähettäjä, sekä yksi tai useampi vastaanottaja. On olemassa kaksi eri tyyp-pistä ratkaisua reitityspuun määrittelemiseksi: lähdepuut (engl. source-based tree) jajaetut puut (engl. group shared trees).

2.4.1 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 mah-dollisia. Tavallisesti edullisin reitti on sellainen, jossa viestin välitys lähettäjältä koh-teisiin vie vähiten aikaa. Jos multicast-ryhmässä on N kappaletta ryhmäviestejä lä-hettäviä laitteita, muodostuu ryhmälähetyspuita myös N kappaletta. Lähdepuume-netelmä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. muis-tin kulutuskseen reitittimillä. Reitittimet saattavat aika ajoin ilmoittaa isäntäsolmul-leen, 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 onesitetty kolme lähettäjää omaavan ryhmän lähdepuu. Solmut ovat kuvan 2.3 reitit-timiä.

2.4.2 Jaetut puut

Jaetussa puussa jokaista ryhmää kohti muodostetaan vain yksi reitityspuu. Verkonreitittimistä valitaan yksi reititin eräänlaiseksi keskukseksi, jonka kautta kaikki ryh-mälähetysviestit kulkevat. Jaetun puun juurena on valittu keskusreititin. Jokainen

6

lähettäjä lähettää ensin viestinsä keskusreitittimelle, joka ohjaa viestit kaikille ryh-män vastaanottajille. Nyt jokaisen verkon reitittimen tarvitsee ylläpitää jokaista ryh-mää kohti tietoa vain yhdestä reitityspuusta, koska viestit ovat lähtöisin aina samal-ta solmulta lähettäjästä riippumatta. Vastaanottajien ilmoittaminen isäntäsolmuil-le hoituu nyt pienemmällä informaatiolla kuin lähdepuumenetelmässä. Haittapuo-lena jaetussa puussa on reitityspuun toiminnan riippuvuus yhdestä solmusta, elikeskusreitittimestä. Verkon liikenne keskittyy yhdelle reitittimelle, jolloin sen yli-kuormittuminen 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ää toisilleen ryhmälähetysviestejä suoraan, vaan ne ”kierrätettävä”keskusreitittimen kautta. Tämä aiheuttaa tietenkin viivettä. Edellämainittuja hait-toja voidaan minimoida huolellisella keskusreitittimen valinnalla ja määrittämällävarallaolevia keskusreitittimiä. Hyvin valittu keskusreititin takaa mahdollisimmantasapuolisen viiveen jokaiselle vastaanottajalle. Kuvassa 2.4 näkyy sama kolmenlähettäjän multicast-ryhmä toteutettuna jaetulla puulla. Solmut ovat kuvan 2.3 rei-tittimiä.

Kuva 2.4: Lähde- ja jaettu puu.

2.4.3 Hybridimallit

Jaettua puuta käyttävä malli, jossa solmujen liittäminen toteutetaan vastaanottaja-pohjaisesti on todettu nykyään parhaimmaksi käytännössä. Joskus ryhmälähetys-liikenteen jakautuminen verkossa voi olla sellaista, että olisi edullisempaa käyttäälähdepuita. Jos esimerkiksi reititin X havaitsee, että se vastaanottaa lähes kaikendatansa samalta lähettäjältä, voidaan solmun ja lähettäjän väliin luoda lähdepuu.

7

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

3 Mobiilit ad hoc -verkot

Termi ad hoc on peräisin latinan kielestä ja tarkoittaa ”tarkoituskohtaista”. Tietotek-niikassa termillä tarkoitetaan sellaista tietoverkkoa, jonka jäsenenä voidaan olla tar-vittaessa vain väliaikaisesti [1]. Jäsenyys voi kestää esimerkiksi verkkoa tarvitsevansovelluksen käynnissäoloajan. Langattomien laitteiden ollessa kyseessä verkon jäse-nyys voi kestää niin kauan kuin laite on viestimiskantaman sisällä ad hoc -verkosta.Ad hoc -verkoille on ominaista, että sen solmut ”järjestäytyvät” verkoksi omatoimi-sesti ilman minkään keskuslaitteen ohjausta. Verkkoon voidaan liittyä ja siitä voi-daan poistua vaivattomasti ja nopeasti. Mobiili ad hoc -verkko (engl. Mobile Ad hocNETwork, MANET) on mobiililaitteista koostuva ad hoc -verkko. Mobiililaitteet ovatuseimmiten langattomia päätelaitteitä, mutta MANET voi sisältää myös langallisia-kin laitteita, kunhan ne vain pystyvät liikkumaan. Tästä eteenpäin käsitellään ni-menomaan 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. Yh-dysvaltain puolustusministeriön organisaation DARPA:n (Defense Advanced Re-search Projects Agency) tuli kehittää armeijan tarpeisiin tietoverkko, joka tulee pys-tyä toimimaan vaativissa taistelukenttäolosuhteissa. Verkon solmut ovat tällöin jokosotilaita tai sotilasajoneuvoja. Solmujen ei voi olettaa pysyvän paikoillaan, ja solmu-jen väliset yhteydet saattavat mennä usein poikki. Verkon tulee myös pystyä toimi-maan ilman kiinteää tietoliikenneverkon infrastruktuuria, koska sitä ei yleensä oleolemassa.

DARPA:n kehittämä arkkitehtuuri on tullut sittemmin julkiseksi, joten sitä onvoitu ryhtyä käyttämään myös muissa sovelluksissa, kuten esimerkiksi pikaiseentietoliikenneverkon luomiseen katastrofialueella. Mobiililaitteiden erittäin nopea yleis-tyminen tuo tilanteita, joissa nopea ja helppo verkon muodostaminen laitteiden kes-ken on tarpeen. Joukko ihmisiä, esimerkiksi kaveriporukka, voi kohdata kaupungil-la ja ryhtyä pelaaman jotain peliä mobiililaitteillansa tai heillä on jokin muu tarvevaihtaa tiedostoja keskenään. Luennolla voidaan tarvittava oppimateriaali lähettääluokan oppilaiden mobiililaitteisiin MANET:n avulla. Erilaiset sensoriverkot ovat

9

tärkeä käyttökohde ad hoc -verkolle. Yksittäisiä sensoreita on yleensä erittäin suurimäärä, eikä niitä kustannussyistä kannata yhdistää kiinteällä kaapelilla tai senso-rien sijainti estää kaapeloinnin täysin. Verkon kykeneminen jokaisen solmunsa au-tomaattiseen konfigurointiin on suuri etu, koska sensoriverkon manuaalinen konfi-gurointi olisi erittäin työlästä.

Nykyisen matkapuhelinverkkojen kapasiteettia pystyttäisiin parantamaan MA-NET:in avulla. Matkapuhelinverkko koostuu useista pienemmistä soluista. Kaikkitietoliikenne solun alueella kulkee sen tukiaseman kautta, riippumatta lähettäjän javastaanottajan sijainnista. Ne voivat sijaita eri soluissa eri mantereilla tai samassasolussa metrin päässä toisistaan. Tukiasema muodostuu pullonkaulaksi, kun mat-kapuhelinten määrä ja tiedonsiirtomäärät solussa lisääntyvät.

Internet-yhteyttä käyttävät sovellukset ovat lisääntyneet matkapuhelimissa vii-me aikoina. Ne kuluttavat matkapuhelimen tiedonsiirtokaistaa yleensä huomatta-vasti enemmän kuin perinteiset puhelut. Seuraavaksi havainnollistetaan kahdellaesimerkillä, miten mobiilia ad hoc -verkkoa hyväksikäyttämällä voidaan soluverk-kojen tukiasemien taakkaa keventää [5].

3.1.1 Solun sisäinen dataliikenne

Otetaan esimerkkinä tilanne, jossa henkilö A haluaa lähettää ottamansa valokuvanB:lle matkapuhelimellaan. Henkilöt ovat töissä samassa rakennuksessa, mutta eivätpääse tapaamaan toisiaan, jotta he voisivat suorittaa tiedonsiirron infrapunalinkil-lä. Niinpä A päättää lähettää kuvan sähköpostin liitetiedostona. Sähköposti siirtyyradiotietä pitkin tukiasemalle, sieltä kiinteää verkkoa pitkin internetiin A:n ja B:nsähköpostipalveluihin. Aikanaan sähköposti saapuu B:lle saman tukiaseman väli-tyksellä (kuva 3.1).

10

Kuva 3.1: Perinteinen solun sisäinen datan siirto.

Jos taas käytettäisiin hyväksi MANET:ia, ei tukiaseman tarvitsisi osallistua em.datan siiroon ollenkaan. A voisi ottaa B:hen yhteyden mobiililaitteiden C ja D väli-tyksellä. Myös tavallisia solunsisäisiä puheluita voitaisiin välittää MANET:n kautta(kuva 3.2).

Kuva 3.2: Datansiirto solun sisällä ad hoc -periaatteella.

3.1.2 Dataliikenne solun ulkopuolelle

Jos mobiililaitteiden tietoliikenne ei kohdistu toisiinsa, vaan esimerkiksi palvelimil-le internetissä, on tilanne hieman erilainen. Nytkin MANET:ista voi olla hyötyä ver-rattuna tilanteeseen, jossa kaikki laitteet liikennöisivät tukiaseman kautta. Nyt voi-daan muodostaa ad hoc -verkko, jossa osa mobiililaitteista toimii ns. pääsypisteinä

11

internetiin (engl. access point). Pääsypisteet toimivat eräänlaisina ylimääräisinä tu-kiasemina, joiden kautta osa soluverkon mobiililaitteista voisi olla yhteydessä in-ternetiin. Tämä vähentäisi ”oikean” tukiaseman kuormitusta. Pääsypisteillä tuleeitsellään olla jokin muu yhteys internetiin kuin soluverkon tukiasema, esimerkiksikiinteä verkkoyhteys. Kannettavat tietokoneet, joissa on langaton tukiasema voisiolla tällainen pääsypiste.

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 tarvitaanjokin reititysprotokolla. Reititysprotokollan tulee pystyä suoriutumaan kahdesta teh-tävästä: reitin löytämisestä ja reitin ylläpitämisestä. Aina kun verkon linkkien tilamuuttuu 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 reitinylläpito kuormittaa tavallisesti verkkoa ylimääräisillä signalointiviesteillä. Kiinteäs-sä verkossa, eli sellaisessa jossa solmut eivät liiku, eikä solmujen välisissä yhteyk-sissä tapahdu useinkaan muutoksia, reitittimet pyrkivät yleensä pitämään itselläänmahdollisimman reaaliaikaista tietoa verkon topologiasta, koska verkon kaista eikuormitu tarvittavista signalointiviesteistä liikaa. Mobiili ad hoc -verkko on kuiten-kin luonteeltaan erilainen kuin kiinteä verkko, joten edellä mainittu toimintatapa eivälttämättä ole siinä paras ratkaisu [3].

3.2.1 Reitityksen haasteet

Nopea ja satunnainen verkon topologian muuttuminen on suurin haaste reitityksel-le MANET:issa. Seuraavassa on lueteltu syitä topologian muutoksiin.

• Solmujen liikkuvuus. Suuri osa mobiilisolmuista on todennäköisesti liikkees-sä, jolloin yhteyksiä naapureihin katkeaa ja samalla uusia yhteyksiä muodos-tuu uusiin naapureihin. Langattomien laitteiden ollessa kyseessä yhteys naa-puriin katkeaa useimmiten laitteen liikuttua pois kantamalta. Solmujen liikku-vuus on vain harvoin täysin satunnaista. Tavallisesti liikkuvuus noudattaa jo-tain tietynlaista mallia. Reititysprotokollan olisi hyvä ottaa liikkuvuuden mallihuomioon, jolloin topologiamuutoksia pystyttäisiin ennakoimaan.

• Solmujen rajallinen käyttöikä. Suurin osa mobiililaitteista saa virtansa akuis-ta, joten laitteet eivät voi olla rajattomiin päällä. Laitteen sammuminen virran

12

loputtua irrottaa myös solmun verkosta. Langaton laite saattaa myös akkujenheikettyä siirtyä säästämään virtaa, jolloin se pienentää lähetystehoaan. Täl-löin kantama pienenee ja solmun yhteys osaan naapureistaan katkeaa. Langat-tomien laitteiden lähettämän datan määrä vaikuttaa merkittävästi sen akkujenkestoon, koska langaton lähetys vie helposti suuren osan virrasta. Nykyisillämobiililaitteilla lähetin ei ole välttämättä suurin tehokuluttaja normaalikäytös-sä, mutta MANET:issa tilanne saattaa muuttua. Laite saattaa sijaita ”keskeisel-lä” paikalla verkossa, jolloin sen kautta kulkee paljon muun verkon liikennet-tä. Myös käytetyn reititysprotokollan reitinhaku ja -ylläpitotoimenpiteet voi-vat kuluttaa laitteen akkuja, etenkin solmujen liikkuvuuden ollessa voimakas-ta.

• Ympäristö ja solun maantieteellinen sijainti. Maantieteelliset esteet ja sää-ilmiöt aiheuttavat hankaluuksia radiotaajuiselle viestinnälle. Signaalit vaime-nevat, hajoavat, sekä heijastuvat esteistä. Tämän johdosta vastaanotetun sig-naalin voimakkuus on lähes aina vain pieni murto-osa lähetetystä. Jo pieni-kin lähettäjän ja vastaanottajan suhteellinen liike saattaa aiheuttaa huomatta-via vaihteluita vastaanotetun signaalin voimakkuudessa, jolloin yhteys saattaapätkiä. Tämä ilmenee langattoman laitteen radiokantaman vaihteluina. Yhteyssaattaa pätkiä myös laitteen ollessa paikallaan, jos laite sijaitsee sopivassa pai-kassa esimerkiksi jonkin häiriösignaaleita tuottavan laitteen lähellä. Voidaanolettaa, että suuri osa mobiileista ad hoc -verkoista sijaitsee urbaaneissa ym-päristöissä. Tällainen ympäristö sisältää runsaasti esteitä ja häiriölähteitä ra-diosignaaleille. Asutusalueella nopeasti liikkuvat solmut ovatkin hankalia ta-pauksia reititysprotokollille.

• Solmujen vaihtuvuus. Ad hoc -verkon ominaisuuksiin kuuluu jo määritelmänperusteella, että siihen liittyminen ja siitä poistuminen on yksinkertaista. Mo-biililaite saattaa liittyä verkkoon vain lähettääkseen yhden pienen tiedoston,jonka jälkeen se irroittautuu verkosta. Tällöin laitetta ei voida käyttää muunverkon liikenteen reititykseen kovin kauaa.

MANET sisältää muitakin uusia haasteita reititykselle verrattuna kiinteään verk-koon:

• Viestien yhteentörmäykset. Langattomat mobiililaitteet lähettävät viestejä broad-cast-tyylisesti, jolloin kaikki laitteet kantaman sisällä kuulevat lähetyksen. Täl-löin vastaanotin ottaa viestin vastaan, vaikka se ei olisikaan osoitettu kysei-selle laitteelle. Kuvitellaan tilanne, jossa solmun kaksi naapuria (A ja B) lähet-

13

tää 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 vastaano-tin ryhtyy vastaanottamaan B:n viestiä. Viestit ovat siis ”törmänneet” solmunkohdalla, eikä solmu nyt kykene vastaanottamaan A:lta tullutta viestiä. Solmuhavaitsee B:ltä tulleen viestin turhaksi heti kehyksen otsikon luettuaan. Mitäenemmän solmulla on naapureita, sitä yleisempiä törmäykset ovat. Tilanne onosin samanlainen kuin Ethernet-verkossa. Törmäykset ovat kuitenkin paljonhaitallisempiä MANET:issa, koska siinä laitteiden tiedonsiirtokaista on hyvinrajoittunut.

• Suuri reittien määrä. Suuresta solmujen määrästä ja niiden broadcast-tyylisestäviestityksestä johtuen verkon solmujen välille syntyy helposti useita reittejä.Jos reititysprotokolla pitää yllä reaaliaikaista tietoa verkon topologiasta, kas-vattavat ylimääräiset reitit reititystaulukoita. Ylimääräisten reittien olemas-saolo voi olla myöskin etu reitityksen kannalta, koska verkko sietää nyt enem-män solmujen liikkeitä. Osa reititysprotokollista käyttääkin tätä hyväkseen.

• Epäsymmetriset linkkiyhteydet. Langattomissa verkoissa ei voida olettaa, et-tä kahden viestivän osapuolen välinen yhteys olisi identtinen molempiin suun-tiin. MANET:issa voi olla monia erilaisia langattomia laitteita, joilla on erivah-vuiset lähetystehot. Lisäksi kahden identtisen laitteen välinen yhteys voi toi-mia vain toiseen suuntaan, jos jompikumpi laite on esimerkiksi jonkin häiriö-lähteen lähellä. Reitti kahden solmun välillä voi kulkea ”menosuuntaan” erisolmujen kautta kuin ”paluusuuntaan”. Useimmat olemassaolevat protokol-lat olettavat kuitenkin, että kaikki verkon linkkiyhteydet ovat symmetrisiä.

• Verkon osittuminen. Topologia saattaa verkossa muuttua siten, että verkko ja-kautuu useisiin pienempiin osiin, joilla ei ole toisiinsa yhteyttä. Solmut voivatliikkua esimerkiksi ryhmissä, jolloin ryhmät saattavat poistua toistensa kan-tamilta. Verkossa saattaa olla myös joitain tärkeitä solmuja, joiden kautta kul-kee kaikki liikenne eri verkon osien välillä. Näiden solmujen pettäminen jakaaverkon. Protokollan tulee pystyä muodostamaan reitit osien välillä heti, kunniiden solmut tulevat taas toistensa kantamille.

3.2.2 Proaktiivinen reititys

Kiinteissä verkoissa yleisimmin käytetty tapa reaaliaikaisen topologiatiedon hank-kimiseen on, että kaikki reitittimet levittävät säännöllisesti reititystietojaan muil-le reitittimille. Tällaista tapaa sanotaan proaktiiviseksi reititykseksi. Topologiatiedot

14

saatuaan reitittimet pyrkivät ”yhteisymmärrykseen” parhaista reiteistä jokaiseltasolmulta mihin tahansa solmuun. Tätä kutsutaan verkon yhtenemiseksi (engl. con-vergence).

Kaksi hieman toisistaan eroavaa tapaa proaktiiviseen reititykseen on kehitetty:etäisyysvektoriin (engl. distance vector) ja linkkien tilaan (engl. link state) perustuvatalgoritmit. Näistä etäisyysvektoriin perustuva on vanhempi, ollen käytössä jo al-kuperäisessä ARPANET:issä. Kiinteissä verkoissa nykyisin yleisessä käytössä olevaOSPF (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 naapu-risolmuilleen. Etäisyydet ilmoitetaan tavallisesti hyppyjen lukumäärinä (engl. hopcount). Kun viesti kulkee yhden linkkiyhteyden yli, kutsutaan sitä yhdeksi hypyk-si. Jos esimerkiksi viesti kulkee lähettäjältä vastaanottajalle kahden muun solmunkautta, tulee hyppyjen lukumääräksi kolme. Reititin saa siis jokaista kohdetta kohtikaikilta naapureiltaan etäisyyden kohteelle. Kun solmu on lähettämässä viestiä koh-teelle, vertaa se saamiaan etäisyystietoja toisiinsa. Solmu lähettää viestin sen naa-purin kautta, joka oli ilmoittanut pienimmän etäisyyden kohteelle. Kun tämä tois-tetaan jokaisella solmulla, kulkee viesti lyhintä reittiä vastaanottajalle. Algoritminheikkouksia ovat hidas verkon yhteneminen, eli algoritmi sietää huonosti muutok-sia verkon topologiassa. Toinen huono puoli on silmukoiden muodostuminen rei-titykseen, koska valitut reitit saattavat perustua vanhentuneisiin etäisyysvektoritie-toihin.

Linkkien tilaan perustuvassa algoritmissa jokainen solmu pitää yllä tietoja link-kiensä tiloista naapurisolmuihin. Solmu lähettää tietonsa kaikille muille verkon sol-muille määräajoin. Jokainen verkon solmu saa siten tiedon koko verkon topologias-ta. Jokainen reititykseen osallistuva reititin laskee paketin saatuaan parhaan reitinkohteelle. Paketti lähetetään kohti vastaanottajaa sitä linkkiä pitkin, joka todettiinparhaaksi. Link state -reititys reagoi nopeammin verkon muutoksiin kuin edellinentapa. Huonona puolena on suurempi laskentatehon tarve reitittimillä ja suurempikaistan 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 parhaitenkiinteälle, melko vähän solmuja sisältävälle verkolle. Vähäinen solmujen määrä onparempi, koska topologiatietojen lähetysviestien lukumäärä kasvaa eksponentiaa-lisesti 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 huomatta-

15

va, että topologiatietoja välitetään tavallisesti vakiomittaisin määräajoin. Tällöin eiole mitään merkitystä, liikkuvatko solmut verkossa vähän vai paljon. Jos liikkuvuuson vähäistä, on osa signalointiviesteistä turhia, koska topologiassa ei ole tapahtunutmuutoksia. Jos taas solmut ovat hyvin liikkuvia, eivät signalointiviestit pysy peräs-sä topologian muutoksissa.

Proaktiivisen reitityksen ehdoton vahvuus on viiveettömyys viestityksen aloitta-misessa. Reitti vastaanottajalle on jo olemassa, joten solmu voi ryhtyä lähettämäändataa välittömästi. Heikkouksia ovat taas reititystaulujen muistin kulutus ja reit-tien laskemiseen kuluva laskentateho solmulla. Proaktiivinen reititys kuluttaa pal-jon kaistaa, koska jokainen solmu ilmoittaa kaikille muille solmuille reititystaulunsatiedot. Mobiilisolmuilla on yleensä käytössä hyvinkin rajoitettu kaista, joten turhiaviestejä on pyrittävä välttämään kaikin keinoin. MANET:issa suositaankin yleisestins. reaktiivista reititystä.

3.2.3 Reaktiivinen reititys

Proaktiivinen reititys on todettu liian raskaaksi tavaksi vähänkin isommissa mobii-leissa ad hoc -verkoissa. Lisäksi verkon yhteneminen ei ole riittävän nopeaa, jottareittitiedot 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 jo-tain dataa on lähetettävänä. Lähettäjä laittaa liikkeelle reitinpyyntöviestin (engl. rou-te request) lähettämällä sen kaikille naapureilleen. Naapurit välittävät pyyntöä edel-leen omille naapureilleen, kunnes reitti kohteelle löytyy. Reitinpyyntöviestiä siis tul-vitaan koko verkolle, kunnes reitti löytyy. Kohteen löydyttyä lähetetään reitin vas-tausviesti (engl. route reply) takaisin lähettäjälle. Nyt reitti tunnetaan ja lähettäjä voialoittaa pakettien lähettämisen.

Reittiä ylläpidetään vain niin kauan kuin sitä tarvitaan. Ylläpitäminen toteute-taan tavallisesti ajastimilla ja reitin pitämisellä muistissa (engl. route caching). Reitinajastin nollataan aina, kun sitä pitkin kulkee viestejä. Jos ajastinta ei nollata jonkintietyn ajan kuluttua, poistetaan reitti muistista. Jos solmujen väliset yhteydet reitil-lä katkeavat, on reitillä suoritettava korjaustoimenpiteitä (engl. route repair tai routere-discovery). Yhteys vastaanottajaan pyritään korjaustoimenpiteillä saamaan uudes-taan siten, että uusi reitti poikkeaisi mahdollisimman vähän vanhasta. Reitinkorjauspyritäänkin suorittamaan niiden solmujen välillä, joiden yhteys toisiinsa on poikki.

Reitityksen tehokkuuteen vaikuttaa kaksi keskeistä tekijää: (1) kuinka usein uu-

16

sia reittejä pyydetään, ja (2) kuinka paljon reiteillä joudutaan tekemään korjaustoi-menpiteitä. 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äämistä, jolloin reittejä ei välttämättä löydetävastaanottajille tai reitit eivät ole hyviä. Mitä enemmän reittejä pidetään muistissa,sitä paremmin selvitään useista reittipyynnöistä. Myös reittipyyntöjen suuntaami-nen kohti vastaanottajaa auttaa vähentämään tulvinnasta johtuvaa kaistan kulutus-ta. Reitin korjaustoimenpiteitä taas joudutaan tekemään usein, jos solmut liikkuvatpaljon. Saman viestimissession aikana voi lähettäjän ja vastaanottajan välinen yh-teys katketa useamman kerran. Lisääntyneet korjausviestit tuovat ylimääräistä lii-kennettä 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 proaktiivi-seen menetelmään verrattuna useimmissa tapauksissa, sekä solmun muistin ja las-kentatehon pienempi kulutus. Nämä ovatkin kriittisiä vaatimuksia MANET:issa.Huonona puolena voidaan pitää reitin etsimisestä aiheutuva viive viestityksen aloit-tamisessa.

17

4 Ryhmälähetys MANET:issa

Kaikenlaisten mobiililaitteiden ja ryhmälähetystä tarvitsevien sovellusten yleistyes-sä on ollut järkevää keskittää tutkimustyötä näiden kahden yhdistämiseksi. Suurinosa nykyisistä kiinteän verkon ryhmälähetyssovelluksista voidaan lähitulevaisuu-dessa siirtää mobiililaitteisiin. Lisäksi mobiilius tuo aivan uusia sovellusmahdolli-suuksia ryhmälähetykselle. Tutkimustyö on keskittynyt viimevuosina lähinnä MA-NET:in unicast-protokollien kehitykseen, multicastin jäädessä vähemmälle huomiol-le. Unicast-protokollia ei ole suunniteltu selviämään ryhmälähetyksestä, eikä niitäkehittäessä olla juurikaan mietitty mahdollista multicast-laajennusta. Kiinteän ver-kon multicast-protokollia ei voida käyttää MANET:issa, koska niitä ei olla suunni-teltu selviämään jatkuvista verkon topologian muutoksista. Ryhmälähetyspuut rik-koutuvat helposti ja niihin pitää tehdä usein muutoksia.

Luvussa kerrotaan aluksi multicast-ryhmien muodostamisesta MANET-ympä-ristössä. Sen jälkeen esitetään muutamia ryhmälähetysprotokollien perustyyppejä.Luvun loppuosassa selvitetään perusteet yhteensä neljästä eri periaatteilla toimivas-ta 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äis-tämättä verkolle ja laitteille lisää kuormitusta.

Periaate MANET:in ryhmälähetykselle on sama kuin kiinteiden verkkojen ta-pauksessa: muodostetaan rajattu ryhmä, jolle voidaan lähettää viestejä ryhmälä-hetysosoittetta käyttäen. Ryhmistä voidaan muodostaa, sekä lähdepuita että jaet-tuja puita (kts. 2.4). MANET on kuitenkin hyvin dynaaminen, eli verkon topo-logia muuttuu usein. Puumaiset rakenteet eivät siksi aina sovellu hyvin MANET-ympäristöön. Sen johdosta osaan protokollista onkin kehitetty toisenlainen mene-telmä, jossa solmuille on olemassa useampia reittejä, joita pitkin ryhmälähetysvies-tit kulkevat. Tätä selvitetään tarkemmin seuraavassa.

18

4.2 Ryhmien rakenteet

Kuten luvussa 2 mainittiin, puumainen rakenne on kaistaa säästävä ratkaisu mul-ticast-ryhmien muodostamiseksi. Viestit kulkevat puuta pitkin siten, että viesti voitulla solmulle vain yhtä reittiä pitkin. Mobiileissa ympäristöissä kaistasta onkinyleensä suuri pula, joten puurakenne tuntuisi periaatteessa hyvältä ratkaisulta MA-NET:iinkin. Mutta vahvuus saattaa kuitenkin helposti kääntyä heikkoudeksi, koskasolmujen väliset linkkiyhteydet ovat MANET:issa epävakaita.

Ryhmälähetyspuussa jokainen puun solmu on kiinnitetty johonkin tiettyyn rei-tittimeen. MANET ympäristössä verkon topologia on kuitenkin jatkuvassa muutok-sessa, jolloin puun solmujen väliset yhteydet katkeilevat. Ryhmälähetysviestit eivätenää saavuta katkeamiskohdan jälkeisiä solmuja. Puu vaatii korjaustoimenpiteitä,joissa solmujen välille yritetään löytää uusi reitti verkosta. Korjaustoimenpiteet vaa-tivat aina ylimääräistä viestitystä, jolloin verkko kuormittuu. Mitä dynaamisempitopologia verkolla on, sitä useammin joudutaan ryhmälähetyspuuta korjaamaan.

Toisenlainen tapa on luopua kaistansäästövaatimuksista topologian muutostensietämisen hyväksi. Ryhmät muodostetaan kokoamalla ryhmän jäsensolmuista jatavallisista solmuista eräänlainen aliverkko (engl. mesh). Jäsensolmujen ja niiden lii-kennettä välittävistä solmuista käytetään myös nimitystä välitysryhmä (engl. forwar-ding group). Aliverkon solmuilla sallitaan useita yhteyksiä toistensa välillä, jotenusein lähettäjien ja vastaanottajien välillä on useita vaihtoehtoisia reittejä. Ryhmä-lähetysviestit tulvitaan aliverkon sisällä, jolloin viesti kulkee jokaisen jäsensolmunkautta. Nyt solmujen välisten yhteyksien katkeamiset eivät haittaa niin paljoa, kos-ka tulvittu viesti saapuu perille todennäköisesti jotain toista reittiä. Tulviminen tuotietysti lisää turhaa kuormitusta verkkoon, koska yksikin ehjä reitti lähettäjältä vas-taanottajalle riittäisi. MANET-ympäristön solmut lähettävät viestinsä kuitenkin jokatapauksessa broadcast-tyyppisesti, jolloin kaikki naapurit kuulevat viestin. Tulvimi-sesta ei siis 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ä eiyleensä tarvitse tehdä.

Nyrkkisääntönä voidaan pitää, että puurakenteet soveltuvat paremmin melkostaattisiin verkkotopologioihin, joissa ne pystyvät tuomaan kaistansäästöä. Ryhmä-lähetysaliverkko pääsee oikeuksiinsa vasta hyvin dynaamisissa verkoissa, joissa vies-tien perillemeno on epävarmempaa. Yksittäisen solmun kannalta rakenteiden tär-kein ero on seuraava: mesh-rakenteessa jokainen ryhmälähetysaliverkon jäsenreiti-tin välittää eteenpäin miltä tahansa reitittimeltä kuulemansa ryhmälähetysviestin.

19

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. 3.2.1). Osittuminenestää ryhmälähetysten perillemenon osalle vastaanottajista, koska lähettäjä voi si-jaita eri osiossa. Kumpikin rakenne kärsii verkon soittumisesta yhtä paljon, koskaosioiden välillä ei ole yhtään reittiä.

4.3 Protokollien perustyypit

Ryhmälähetysprotokollia MANET:iin on olemassa useampia erilaisia, jotka toimi-vat eri periaatteiden mukaan. Edellisen kohdan kahden erilaisen ryhmänmuodos-tusperiaatteen lisäksi multicast-protokollan riippuvuus unicast-protokollasta vaihte-lee. Ryhmälähetysprotokolla voi olla täysin itsenäinen, jolloin se tavalla tai toisel-la löytää reitit kaikille ryhmän jäsenille. Toisaalta prokolla voi tarvita toimiakseenapua joltain tietyltä, tietynlaiselta tai millaiselta tahansa unicast-protokollalta. Lisäk-si joistain unicast-protokollista voi olla kehitetty multicast-versiot. Alla oleva unicast-protokolla voi olla joko reaktiivinen (kts. 3.2.2) tai proaktiivinen (kts. 3.2.3).

Tässä tutkielmassa esitellään ja vertaillaan seuraavia protokollia:

• Core Assisted Mesh Protocol (CAMP) on mesh-rakenteinen protokolla, jokatarvitsee toimiakseen apua proaktiiviselta unicast-protokollalta [6].

20

• Adaptive Demand-Driven Multicast Routing protocol (ADMR) on puumai-seen 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 toimivamesh-rakenteinen protokolla [11].

Ylläolevat protokollat olettavat kaikkien verkon linkkiyhteyksien olevan sym-metrisiä. 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 verk-koympäristössä. Se käyttää aliverkkoa (kts. 4.2) ryhmälähetysviestien välittämi-seen, jolloin saavutetaan parempi liikkuvuuden sieto kuin puumaisella rakenteel-la. CAMP tarvitsee toimiakseen apua unicast-protokollalta, joka tarjoaa sille etäisyy-den 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ähetyksienlähettäjiltä vastaanottajille. Lyhin mahdollinen reitti tarkoittaa sellaista reittiä, jollaon pienin mahdollinen määrä välittäviä solmuja. Tällaisen reitin olemassaolo takaasolmuille mahdollisimman pienen viiveen ryhmälähetyksessä. Lyhimmän reitin ta-kaaminen esitetään tarkemmin kohdassa 4.4.3. Kuva 4.2 esittää multicast-viestienkulun verkossa. Solmun A lähettäessä multicast-viestejä, saavat vastaanottajasolmutB, C, D, E, F ja H lähetyksen useampia reittejä pitkin.

Multicast-ryhmä pidetään koossa ankkurisolmujen (engl. anchor) avulla. Solmuns 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ämi-seksi riittää, että jokainen jäsensolmu pitää yllä tietoa vähintään yhdestä ankkuri-solmustaan. Jokainen ryhmän jäsensolmu tietää mitä solmuja sillä on ankkurinaanja mitkä solmut pitävät sitä ankkurinaan. Kuvassa 4.2 voidaan nähdä, että esimer-kiksi solmu C pitää ankkurinaan solmua G.

21

Kuva 4.2: Mesh-rakenne CAMP-protokollassa.

4.4.1 Reititysinformaatio

Jokainen CAMP-solmu ylläpitää protokollan toiminnan takaamiseksi reititystietoja.Tarvittavat tiedot ovat: reititystaulu (engl. routing table, RT), ryhmän ja keskuksenyhdistä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ä siihenolemassa. Unicast-protokollan tulee siis olla proaktiivinen, koska reititystiedon tuleeolla 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ää ankkurei-naan kullekin ryhmälle.

MRT sisältää tiedon kaikista naapurisolmuista, jotka ovat jonkin ryhmän jäsen-solmuja. Lisäksi ylläpidetään tietoa, mitkä näistä solmuista pitävät kyseistä solmuaankkurinaan ja ovatko ne duplex vai simplex-tyyppisiä. Solmu saa tiedon naapurei-densa ryhmän jäsenyydestä kuulemalla niiden lähetyksiä. Eli aina kun solmu A lä-hettää multicast-viestin eteenpäin, kaikki kantamalla olevat solmut kuulevat sen.Muut solmut päivittävät MRT:nsä tiedolla, että A kuuluu multicast-ryhmään. Tätätietoa ne voivat käyttää tarvittaessa myöhemmin ryhmään liittyäkseen (kts. 4.4.2).

Solmu pitää muistissaan tietyn määrän lähiaikoina välitettyjen pakettien tun-nistetietoja. Tällä saavutetaan kaistansäästöä, koska samaa pakettia ei lähetetä uu-

22

destaan. Lisäksi muistiin tallennetaan jokaiselle paketille sen lähettäneen naapurinosoite. Osoitetietoa käytetään lyhimmän reitin pitämiseksi osana ryhmälähetysali-verkkoa (kts. 4.4.3).

Solmut ilmoittavat toisilleen muutoksista reititystiedoissaan. Ilmoitus lähetetäänpäivitysviestissä (engl. multicast routing update, MRU), joka lähetetään aina, kunMRT tai AT ovat muuttuneet. Tietojenvaihdon tarkoituksena on pitää multicast-ryh-män tiedot ajan tasalla. Kaistan säästämiseksi MRU:t olisi hyvä lähettää unicast-protokollan reititystietojen päivitysten yhteydessä.

4.4.2 Ryhmään liittyminen ja ryhmästä poistuminen

CAMP tukee kahdenlaista tyyppiä multicast-ryhmien jäsenyydelle, simplex ja duplex.Simplex-jäsen voi ainoastaan lähettää viestejä ryhmälle tai välittää viestejä ryhmäl-le 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.

Multicast-ryhmään liittyminen voidaan tehdä kahdella tavalla. Jos solmulla onnaapurina duplex-solmu, niin solmun riittää vain ilmoittautua ryhmän jäseneksi.CAMP olettaa, että ryhmän osoite saadaan selville jonkin muun palvelun (esim.DNS) avulla. Solmu lähettää MRU:n naapurilleen, jossa se ilmoittaa liittyvänsä ryh-mään, joko duplex tai simplex-jäsenenä. Jos alla oleva unicast-protokolla takaa vies-tien perillemenon, naapurisolmu kuittaa liittymisilmoittautumisen takaisin liitty-välle solmulle. Jos taas viestitys ei ole luotettavaa, liittyvä solmu lähettää ilmoit-tautumisia useampia jaksottaisesti. Naapurit saavat tällöin todennäköisesti jossainvaiheessa tiedon uudesta jäsenestä. Liittyvä solmu asettaa naapurin omaksi ankku-rikseen, ja naapurisolmu asettaa itselleen tästä tiedon.

Toinen tapa käyttää hyväkseen multicast-ryhmän keskuksia (engl. core), joita voiryhmä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 al-la oleva unicast-protokolla mahdollistaa liittymisviestin lähetyksen, jos vain jokinreitti keskukseen on olemassa. Liittymisviesti (engl. join request) lähetetään unicas-tina kohti jotain ryhmän keskuksista. Liittymisviesti saapuu ennen pitkää joko kes-kukselle tai jollekin ryhmän jäsensolmulle. Tällöin keskus tai jäsensolmu lähettääkuittausviestin (engl. join acknowledgement) takaisin samaa reittiä unicastina liittyväl-le solmulle. Kaikki liittymis- ja kuittausviestien välittämiseen osallistuneet solmutasettavat tarvittavat ankkuritiedot ja tulevat osaksi ryhmää. Jos yhteyttä yhteenkään

23

keskukseen ei ole, solmu joutuu tulvimaan liittymisviestiä koko verkkoon. Tulvinta-menetelmänä käytetään ns. expanded ring search (ERS) -menetelmää, jossa viestien le-viämistä hallitaan rajoittamalla kunkin viestin hyppyjen lukumäärää. Ensin solmutulvii viestin yhden hypyn päähän, eli kaikille naapureilleen. Seuraavaksi kahdenhypyn päähän jne. Liittymisviesti saavuttaa näin jossain vaiheessa jonkin ryhmänjäsenen, jolloin jäsen kuittaa liittymisen kuten edellä on esitetty. Jos verkko ei tarjoaluotettavaa tiedonsiirtoa, lähetetään liittymisviestejä uudestaan aivan kuten edel-lisessä 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:nyhteydessä, eikä vastaanottanut solmu kuittaa sitä.

4.4.3 Topologian muutokset

CAMP takaa lyhimmän reitin olemassaolon ryhmälähetysaliverkossa. Lyhin reittilähettäjiltä vastaanottajille saadaan selville unicast-protokollan antamasta reititysin-formaatiosta. Lyhimmät reitit merkitään ankkureilla. Topologian muutosten vuoksisolmu saattaa ryhtyä saamaan viestejä muitakin kuin lyhintä reittiä pitkin. Vastaa-nottajasta katsottuna ankkurisolmun ”takana” oleva, lähettäjän ja ankkurisolmunvälinen, verkko on voinut muuttua siten, että ankkureilla merkitty reitti ei ole enäälyhin mahdollinen. Uusi lyhin reitti voi olla osana multicast-ryhmää, mutta se eiole varmaa. Jokainen solmu pitää kirjaa, miltä naapurisolmuilta viestejä on saapu-nut. Kun solmu huomaa, että ankkurilla merkityltä (lyhimmältä) reitiltä on tullutliian 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 naa-purille, 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 kunsolmu 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 pushjoin. Push joinin vastaanotettuaan solmut lähettävät aina push joinin seuraajalleen.Push join pakottaa kaikki reitillä olevat solmut liittymään ryhmään, jolloin uusi lyhinreitti tulee osaksi ryhmälähetysaliverkkoa. Kuvat 4.2 a, b ja c esittävät vastaanotta-jasolmun R toimintaa lyhimmän reitin ylläpitämiseksi. Kuva 4.3 a esittää alkutilan-netta, jossa R on ryhmän vastaanottaja. R käyttää ankkurinaan lähettäjälle S solmua

24

A. Kuvassa 4.3 b solmujen R ja S väliin liikkuu solmu C. Unicast-protokolla havait-see, 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 multicast-ryhmän jä-sen. B lähettää solmulle C push join -viestin, koska C ei ole ryhmän jäsen. SolmultaC eteenpäin lähetetään vain push join -viestejä, aina lähettäjälle saakka. Kaikki sol-mut, jotka saavat push join -viestin, tulevat osaksi ryhmälähetysjoukkoa. Jonkin ajankuluttua välittäjäsolmujen (esimerkiksi solmu A) ryhmälähetysreititystaulut päivit-tyvät ja ne havaitsevat, että mikään solmu ei käytä niitä ankkureinaan. Tällöin nelakkaavat välittämästä ryhmälähetysviestejä. Uusi mesh-rakenne näkyy kuvassa 4.3c.

Kuva 4.3: Lyhimmän reitin takaaminen. (a) Alkutila (vasen ylhäällä). (b) Heartbeatinja push joinin lähetys (oikea ylhäällä). (c) Uusi mesh (vasen alhaalla).

CAMP sietää verkon topologian muutoksia hyvin rakenteensa vuoksi. Ryhmien

25

lähettäjien ja vastaanottajien välillä on yleensä useita reittejä, jolloin reittien katkea-minen ei ole niin suureksi haitaksi kuin puumaisessa rakenteessa. Jos solmu kui-tenkin menettää yhteyden ryhmään, niin se lähettää push joinin naapurilleen, jokasijaitsee lyhimmällä reitillä johonkin keskukseen. Push joinia lähetetään eteenpäin,jolloin kaikki reitillä olevat solmut tulevat osaksi ryhmää. Kuvassa 4.4 a solmunR yhteys ryhmään katkeaa, jolloin se lähettää push join -viestin unicast-protokollanilmoittamalle naapurilleen, joka on lyhimmällä reitillä keskukselle. Kuvassa 4.4 bnä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), eise 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. Verkkosaattaa osittua joskus siten, että ainakin kahdessa osiossa on oma keskus. Keskuksetlä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 raken-netta ryhmälähetysviestien välitykseen. Puu rakennetaan tarpeen mukaan, eli sil-loin kun ryhmälle halutaan lähettää ja ryhmällä on olemassa ainakin yksi vastaa-

26

nottaja. ADMR poikkeaa hieman kohdassa 4.2 mainitusta puumallista. Jokaista lä-hettäjää kohden luodaan oma puunsa, mutta viestit voivat kulkea vastaanottajilleuseita reittejä (puun haaroja) pitkin. Ryhmälähetyksen jäsensolmut voivat siis ottaavastaan muualtakin kuin isäntäsolmulta tulleita ryhmälähetysviestejä. Protokollatakaa, että ryhmälähetysviestit kulkevat lähettäjältä vastaanottajalle lyhintä mah-dollista reittiä. Lyhin reitti tarkoittaa tässäkin yhteydessä pienintä mahdollista hyp-pyjen määrää.

ADMR on täysin riippumaton alla olevasta unicast-protokollasta. ADMR voi siiskäyttää apunaan mitä tahansa unicast-protokollaa tai se voi toimia täysin itsenäises-ti. Vastaanottajien ei tarvitse lähettää nimenomaista viestiä irroittautuakseen puus-ta, vaan puun harvennus toteutetaan ajastimien avulla.

4.5.1 Pakettien välittäminen

Jokainen ryhmälähetyspaketti sisältää ADMR-otsikon, joka sisältää tarpeelliset tie-dot paketin käsittelyä varten. Tärkeimmät tiedot ovat: sekvenssinumero (engl. sequen-ce number), hyppylaskuri (engl. hop count), edellisen hypyn osoite (engl. previous hopaddress) 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äl-le. Edellisen hypyn osoite ilmoittaa kullekin solmulle, miltä naapurilta kukin viestion 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 paket-teja saapuvaksi. Tällä tavoin huomataan puun rikkoutuminen tai ryhmälähetyksenloppuminen. Tämäkin selvitetään tarkemmin myöhemmin.

Normaali pakettien lähetystapa on tulvia niitä ryhmälähetyspuun sisäisesti (engl.tree flood), jolloin vain puuhun kuuluvat solmut lähettävät paketteja eteenpäin. Sol-mu 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 ADMR-otsikkoonedellisen hypyn osoitteeksi oman MAC-osoitteensa.

Multicast-ryhmät voivat sisältää useita lähettäjiä, jolloin ryhmän jäsensolmut vä-littävät eteenpäin kaikkien lähettäjien ryhmälähetyspaketteja. ADMR tukee myöslähettäjäkohtaisia (engl. source specific) ryhmiä (lähdepuita), jolloin ryhmällä on vainyksi lähettäjä ja jäsensolmut välittävät vain sen viestejä. Puuhun kuuluva solmu vas-taanottaa ADMR-paketin miltä tahansa naapurisolmulta, joka on saman ryhmän jasaman lähettäjän jäsensolmu. Näin ollen ADMR:n puurakenne eroaa hieman koh-

27

dassa 4.2 esitetystä puumallista, koska viestit voivat saapua vastaanottajille useam-pia reittejä. Jos puussa on lähellä toisiaan sijaitsevia haaroja (ts. eri haarojen solmutsijaitsevat toistensa kantamilla), alkaa puu muistuttaa jo meshiä. Tällöin ei haittai-si vaikka jotkin puun haarat olisivatkin poikki. Useita lähettäjiä sisältävän ryhmäntapauksessa tulee rakenteesta jo täysimittainen mesh, koska kaikki jäsensolmut välit-tävät kaikkien lähettäjien viestejä. Kuva 4.5 esittää kahta lähdepuuta, joilla molem-milla on vain yksi lähettäjä. Ryhmän X solmut A ja B saavat ryhmälähetysviestejäuseampaa kuin yhtä reittiä. Kuva 4.6 esitää samojen solmujen muodostamaa (yh-tä) ryhmää, jossa on useita lähettäjiä (L1 ja L2). Nyt havaitaan, että huomattavastiuseampi solmu saa multicast-viestejä useampaa reittiä pitkin.

Kuva 4.5: Kaksi lähettäjäkohtaista ADMR-puuta.

28

Kuva 4.6: Lähettäjille yhteinen ADMR-puu.

ADMR voi tarvittaessa siirtyä lähettämään ryhmälähetysviestejä tulvimalla niitäkoko verkkoon (engl. network flood). Tällainen tilanne syntyy tavallisesti, jos solmutovat erittäin liikkuvia. Puurakenne ei pysy koossa, jolloin sitä joudutaan jatkuvas-ti korjaamaan (kts. 4.5.3). Tietyn liikkuvuuden määrän ylittyessä korjaustoimenpi-teiden aiheuttama ylimääräinen liikenne verkossa ylittäisi tulvinnasta aiheutuvan,jolloin on järkevää siirtyä tulvintaan.


Jokaisen puun jäsensolmun tulee pitää muistissaan seuraavia reititystauluja:

• Lähettäjätaulu sisältää kaikkien niiden ryhmien osoitteet, joille solmu on lähet-täjänä. Sisältää lisäksi senhetkisen pakettien lähetysvälin ja lähetettyjen keepalive -pakettien lukumäärän.

• Jäsenyystaulu sisältää merkinnän jokaista ryhmäosoite-lähettäjän osoite -pariakohti, joille solmu on joko vastaanottaja, välittäjä tai molempia. Lisäksi jokaistaparia 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 ADMR-paketin joko puun sisäisellä tai koko verkon tulvinnalla. Jokaiseen solmuunon taulussa liitetty viimeisimmän solmulta saadun paketin sekvenssinumero,jonka avulla estetään samojen pakettien välitys useampaan kertaan. Lisäksi

29

jokaiseen solmuun on liitetty edellisen hypyn osoite (engl. previous hop address),joka on sen naapurin MAC-osoite, jolta paketti on saatu lyhintä reittiä.

4.5.3 Lähettäjäksi tuleminen

Solmu voi ilmoittautua ryhmän lähettäjäksi lähettämällä ensimmäisen ryhmälähe-tyspaketin tulvimalla koko verkon yli. Samalla se merkitsee lähettäjätauluun itsen-sä ryhmän lähettäjäksi. Lähettäjä odottaa seuraavaksi muilta solmuilta ryhmään-liittymis-, eli receiver join -viestejä ja ryhtyy puskuroimaan seuraavia ryhmälähetys-paketteja 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 kaikkihalukkaat vastaanottajat eivät ole pystyneet liittymään ryhmään. Solmuille on myösannettava mahdollisuus liittyä ryhmään myöhemmin. Tämän vuoksi osa ryhmälä-hetysviesteistä lähetetään tietyin väliajoin tulvimalla koko verkkoon. Aluksi vieste-jä lähetetään tiheämmin ja pikkuhiljaa lähetysten väliä harvennetaan aina johonkintiettyyn vakioarvoiseen lähetystiheyteen. Ryhmälähetyspaketteja lähetetään tulvi-malla 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 ver-kolle. Jos lähettäjällä ei ole dataa lähetettävänään, mutta haluaa silti pitää ryhmänkoossa, lähettää se määrätyin väliajoin ns. keep-alive -viestejä puun sisäisellä tulvin-nalla (eli ryhmälähetyksenä). Näitäkin lähetetään aluksi tiheämmin ja lähetysväliäharvennetaan tasaisesti. Jos lähetysväli saavuttaa ennaltamäärätyn arvon, olettavatkaikki ryhmän jäsensolmut lähettäjän lopettaneen lähetyksen. Solmut poistavat täl-löin tiedot reititysinformaatiotauluistaan ja ryhmä poistuu käytöstä.


Solmu voi liittyä haluttuun multicast-ryhmään lähettämällä liittymispyyntö (engl.multicast solicitation) -viestin tulvimalla koko verkkoon. Vastaanottajan osoitteeksiasetetaan halutun ryhmän ryhmäosoite. Jos ryhmä on lähettäjäkohtainen, lisätäänviestiin myös lähettäjän osoite. Tulvittu viesti saapuu aikanaan lähettäjälle hiemaneri 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äsen-

30

solmu reitillä lähettäjälle toimii samoin ja liittymispyyntö välittyy unicastina lähet-täjälle. Näin toimien säästetään kaistaa.

Kun mikä tahansa lähettäjä vastaanottaa liittymisviestin, pitää sen ilmoittaa liit-tyvä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 sol-mu, jonka kautta liittymisviesti on kulkenut lähettäjälle, on tallentanut solmutau-luunsa edellisen hypyn osoitteen. Tämän perusteella solmut voivat ohjata viestinsuoraan takaisin liittyvälle solmulle. Jokainen välittävä solmu liittää nyt myös sol-mutaulussaan lähettäjän osoitteeseen edellisen hypyn osoitteen, jos merkintää ei oleaikaisemmin ollut. Tietoa tarvitaan liittyvän solmun liittymisen vahvistamisviestinvälittämiseen. (2) Lähettäjä voi aikaistaa ryhmän mainostusviestin (kts. 4.5.3) lähe-tystä, jos mainostusviesti on määrä lähettää piakkoin ja liittyviä solmuja on useita.Mainostusviesti saapuu liittyvälle solmulle jotain reittiä (todennäköisesti lyhintä) jasolmu lähettää liittymisen vahvistusviestin samaa reittiä takaisin.

Solmun liittyminen ryhmään viimeistellään liittyvän solmun lähettämällä liitty-misen vahvistamisviestillä (engl. receiver join). Viesti lähetetään aina unicastina lähet-täjälle ja se asettaa kaikki matkalla olevat solmut välittäjiksi kyseiselle ryhmälle. Josliittyviä solmuja on samalla alueella useita, kulkisi useiden solmujen lähettämät liit-tymisen vahvistamisviestit todennäköisesti samojen solmujen kautta. ADMR pyrkiivälttämään turhaa kaistan kulutusta välittämällä eteenpäin korkeintaan kolme sa-maa lähettäjää koskevaa ja samanaikaista receiver joinia. Jos välitettäisiin vain yksiviesti, eikä se menisi perille, ei solmujen liittymiselle tulisi vahvistusta. Sekä lähet-täjä, että liittyvä solmu lähettävät tarvittaessa edellämainittuja viestejä useampaankertaan, mikäli vastausta ei ole määräaikaan mennessä tullut. Liittymisprosessi aloi-tetaan alusta, mikäli vastausta ei uudelleenlähetyksestä huolimatta ole tullut.

4.5.5 Topologian muutokset ja puun korjaustoimenpiteet

ADMR pyrkii pitämään reitin lähettäjältä jokaiselle vastaanottajalle mahdollisim-man lyhyenä. Ryhmälähetysviestit kulkevat puun sisäisen tulvinnan vuoksi lyhin-tä reittiä, koska ensiksi saapunut viesti on todennäköisesti tullut lyhintä reittiä. Jo-kainen jäsensolmu pitää solmutaulussaan tietoa lyhimmistä reiteistä jokaiseen sol-muun, jolta kyseinen solmu on saanut ADMR-kehyksen sisältävän viestin. Jos sa-malta solmulta on tullut viesti useita reittejä pitkin, solmutauluun tallennetaan vainpienimmän hyppyjen lukumäärän sisältävän reitin tiedot. Protokolla ei suorita mi-tään aktiivisia toimenpiteitä lyhimmän reitin takaamiseksi, kuten CAMP. ADMR:ssäjokainen ryhmän jäsensolmu tarkkailee sille saapuneiden ryhmälähetysviestien kul-

31

keman 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äänyttulematta. Molempia viestejähän lähetettiin tunnetuin väliajoin, joten solmut pysty-vät laskemaan, montako viestiä tietyllä aikavälillä pitäisi tulla. Kun solmu A huo-maa yhteytensä lähettäjään katkenneen, ryhtyy se suorittamaan puun korjaustoi-menpiteitä. Tarkoitus on etsiä uusi reitti A:sta ylävirtaan oleville jäsensolmuille. En-sin A lähettää alavirtaan eli alipuulleen korjauksen ilmoitusviestin (engl. repair no-tification). Näin estetään alipuun solmujen ryhtyminen samanaikaisesti omiin kor-jaustoimenpiteisiin. Jokainen alipuun solmu hyväksyy ja välittää edelleen korjauk-sen ilmoitusviestin vain, jos se on tullut solmun solmutaulussa olevasta edellisenhypyn osoitteesta (eli ryhmälähetyspuussa yhtä tasoa ylemmältä solmulta).

Solmu A odottaa korjauksen ilmoitusviestin lähetettyään jonkin aikaa mahdol-lista ylävirrasta tulevaa ilmoitusviestiä. Jos A saa tällaisen viestin, keskeyttää seomat korjaustoimenpiteensä, koska jokin ylävirran solmuista on jo korjaamassa rik-koutunutta puuta. Jos A ei ole saanut ylävirrasta repair notificationia lyhyen ajansisällä, lähettää se uudelleenliittymisviestin (engl. reconnect) tulvimalla muutamansolmun säteelle. Reconnect-viestissä ilmoitetaan sen ryhmän osoite, johon halutaanliittyä uudelleen. Kun jokin solmu B saa uudelleenliittymisviestin, eikä ole saanutkorjauksen ilmoitusviestiä samalle ryhmälle, olettaa B, että A sijaitsee siitä alavir-taan. B lähettää nyt viestin eteenpäin kohti ryhmän lähettäjää (juurisolmua) unicas-tina. 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 uudelleenliitty-misen vastausviestin (engl. reconnect reply) takaisin A:lle. Kaikki reconnect replyn vä-littäneet solmut tulevat ryhmän välittäjäsolmuiksi. Kuva 4.7 esittää solmun A suo-rittamia korjaustoimenpiteitä.

Jos korjaustoimenpiteistä huolimatta A ei saa muodostettua uudelleen yhteyttälähettäjään, yrittää se liittyä ryhmään kohdassa 4.5.4 esitetyllä tavalla. Kun solmujoutuu suorittamaan uudelleenliittymisen riittävän usein määrätyn ajan sisällä, il-moittaa se siitä lähettäjälle. Solmu asettaa seuraavaan receiver join -viestiinsä tiedonyhteysongelmistaan. Lähettäjä siirtyy tulvimaan ryhmälähetysviestejään koko verk-koon riittävän monta ilmoitusta saatuaan. Näin ADMR adaptoituu verkon suureenliikkuvuuteen. Lähettäjä siirtyy takaisin normaaliin puun sisäiseen tulvintaan taasjonkin ajan kuluttua.

32

Kuva 4.7: ADMR-puun korjaustoimenpiteet.

4.6 MAODV

Multicast operation of the Ad-hoc On-demand Distance Vector (MAODV) on laa-jennus AODV:sta (Ad-hoc On-demand Distance Vector), joka mahdollistaa vies-tien lähetyksen ad-hoc -verkossa unicastina. MAODV voi käyttää apunaan, unicast-toiminnon lisäksi AODV:n tarjoamia reititystietoja. Protokolla rakentaa verkon sol-muista on-demand -periaatteella puun ryhmälähetystä varten. Mikä tahansa ryhmänjäsensolmu voi lähettää ryhmälle multicast-viestejä, jotka lähetetään kohdassa 4.2esitetyn puumaisen periaatteen mukaisesti. Protokolla mahdollistaa ryhmälähetyk-sien ohjauksen todennäköisesti lyhintä reittiä lähettäjiltä vastaanottajille.

4.6.1 Unicast-toiminto (AODV)

MAODV-protokolla tarvitsee joidenkin viestiensä lähetykseen unicast-toimintoa, jon-ka AODV sille tarjoaa. AODV:n reitinmuodostus on puhtaasti on-demand -tyyppinen,eli reitti haetaan vain tarvittaessa, jos sitä ei entuudestaan tunneta. Jokainen solmupitää reittejä reititystaulussaan määrätyn ajan, jonka jälkeen reitti poistetaan muis-tista. Jokaiseen reittiin yhdistetään reititystaulussa kasvava sekvenssinumero, jol-la 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 ainatunnistenumeron, joka yhdessä lähettävän solmun IP-osoitteen kanssa yksilöivätviestin. Solmut käyttävät tietoa estääkseen saman viestin lähettämisen useampaankertaan.

Kun solmu tarvitsee reitin kohteelle, lähettää se RREQ:n tulvimalla koko verk-koon. Viesti sisältää lähteen ja kohteen osoitteet, reitityksen hyppylaskurin (joka on

33

alussa nolla), sekä viimeisimmän solmun tunteman sekvenssinumeron kyseisellereitille. Jokainen solmu merkitsee reititystauluunsa määräajaksi sen naapurin osoit-teen, jolta RREQ saapui. Näin jokaisella solmulla on tiedossaan reitti RREQ:n lähet-täneelle solmulle. Seuraavaksi solmu tarkistaa sekvenssinumeroja vertaamalla, on-ko sillä tuoreempaa reittiä kohteelle. Jos on, niin solmu voi se vastata lähettämälläRREP-viestin samaa reittiä takaisin. Muussa tapauksessa solmu lisää hyppylaskuriayhdellä ja lähettää RREQ:n kaikille naapureilleen, jolloin tulvinta jatkuu. Jos solmusaa useampia RREQ-viestejä, niin RREP lähetetään takaisin sitä reittiä pitkin, mil-lä on pienin hyppylaskurin arvo. RREP-viestiin asetetetaan sen lähettäneen solmunetäisyys (hyppyjen lukumääränä) halutusta kohteesta. Etäisyys on nolla, jos RREP:nlähettävä solmu on itse kohde. Jokainen RREP:n välittävä solmu merkitsee muistiinsen naapurin osoitteen, jolta viesti saapui. Näin muodostuu reitti lähteeltä kohteelle.

Jokainen solmu lisää RREP:n edelleenlähetyksen yhteydessä etäisyyden arvoayhdellä. Solmut saavat todennäköisesti useita samalta solmulta lähteneitä RREP-viestejä. Tällöin solmu valitsee edelleenlähetettäväksi sen, jolla on pienin hyppyjenlukumäärän arvo. Lähdesolmu valitsee käytettäväksi reitiksi pienimmän hyppyjenlukumäärän sisältävän reitin. Kaikki solmut, jotka eivät sijaitse käytettävällä reitil-lä, poistavat reittiin liittyvät osoitintietonsa määrätyn ajan kuluttua. Kuvassa ?? asolmulla 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.8 b solmu B on saanut RREQ:n kolmelta eri naapuriltaan. B valitsee ly-himmällä reitillä A:lle sijaitsevan naapurinsa ja lähettää sille RREP-viestin. RREPohjautuu samaa, lyhintä reittiä takaisin solmulle A ja datan lähetys voi alkaa.

Kuva 4.8: Reitinhaku AODV:ssa. (a) RREQ-viestin leviäminen verkossa (vasen). (b)RREP:n lähetys reitin kysyjälle (oikea).

34

Solmujen tulee olla tietoisia naapurisolmuistaan (erityisesti niiden osoitteista),jotta reittejä halutuille solmuille voidaan muodostaa. Jokainen solmu kuulee naa-puriensa lähetykset, jos ne vain ovat kantaman sisällä. Jokaisen käytössä olevan rei-tin solmun on lähetettävä määräajoin ns. hello-viestejä alavirran naapurilleen, josreitillä ei liiku muuta dataa. Alavirran naapuri on kohteen suunnassa oleva naapu-risolmu. Tällä tavoin käytettävä reitti saadaan pidettyä voimassa, vaikka sitä ei het-keen käytettäisikään. Reitin solmut voivat huomata reitin katkenneen kahdella ta-paa: (1) Solmu ei havaitse, että alavirran naapurisolmu lähettäisi edelleen juuri lähe-tettyä datapakettia. (2) Alavirran naapurin lähettämää hello-viestiä ei havaita. Reitinkatkeamisen havaittuaan solmu lähettää omalle ylävirran naapurilleen ilmoituksenkatkeamisesta. Ilmoitus välitetään aina datan lähettäjäsolmulle saakka, jolloin se et-sii uuden reitin kohteeseen [9].


Jokainen solmu ylläpitää reititystauluissaan sekä AODV:n että MAODV:n tarvitse-mia tietoja. AODV tarvitsee jokaisesta reitistä seuraavat tiedot:

• Kohteen IP-osoite.

• Reitin sekvenssinumero.

• Etäisyys kohteeseen hyppyjen lukumääränä.

• 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.

35

4.6.3 Pakettien lähettäminen

MAODV:ssä ryhmälähetyspaketit lähetetään puumaisesti. Jokainen puun jäsensol-mu ylläpitää jokaista ryhmää kohti osoittimia (eli naapurien IP-osoitteet ovat muis-tissa) niihin naapureihinsa, jotka myös ovat puun jäseniä samalle ryhmälle. Kunpuun jäsensolmu saa puun jäsenenä olevalta naapuriltaan viestin, lähettää se senkaikille muille naapureilleen, jotka ovat myös puun jäseniä. Viesti voi saapua jokai-selle solmulle vain yhtä reittiä pitkin. Ryhmälähetysviestit kulkevat vain aktivoitujaryhmälähetysreittiejä pitkin.


MAODV muodostaa verkon solmuista ryhmälähetyspuun. Puu koostuu kahden-laisista solmuista: puun jäsensolmuista ja ryhmän jäsensolmuista. Ryhmän jäsen-solmut 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änjäsenille tai muille puun jäsenille. Puu voi koostua pelkästään ryhmän jäsensolmuis-ta, 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. Mai-nostuts suoritetaan ns. group hello -viestillä, joka lähetetään tulvimalla koko verk-koon. Viestissä on ryhmänjohtajan ja ryhmän IP-osoitteet sekä ryhmän sekvenssi-numero. Näin kaikki verkon solmut saavat tietoonsa ryhmän osoitteen. Sekvens-sinumero on juokseva numero, jota kasvatetaan yhdellä aina kun group hello lähe-tetään. Jokainen solmu tallentaa viestin tiedot muistiinsa. Solmuilla oleva ryhmänsekvenssinumero ilmoittaa, kuinka tuore tieto ryhmän olemassaolosta on. Jos ryh-mänjohtajan mainostusviestejä ei ole saapunut solmulle vähään aikaan (eli yhteysryhmänjohtajaan on poikki), on solmulla oleva ryhmän sekvenssinumero pienempikuin muulla verkolla.

Solmun ei tarvitse liittyä multicast-ryhmään lähettääkseen sille viestejä, vaan sevoi 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 ryh-män IP-osoite. Viestiin asetetaan myös solmun tietämä viimeisin ryhmän sekvens-sinumero. Mikä tahansa solmu, jolla on tuore reitti ryhmään ja jonka tietämä ryh-män sekvenssinumero on vähintään yhtäsuuri kuin RREQ-viestissä oleva, voi vasta-ta RREP-viestillä. Reitti haetaan ja muodostetaan siis samalla tavalla kuin kohdassa4.6.1 on esitetty.

Solmu liittyy ryhmään lähettämällä liittymis-RREQ -viestin unicastina ryhmän-

36

johtajalle, jos johtaja ja reitti sille on tiedossa. Ryhmänjohtaja vastaa RREP:llä, jokalähetetään samaa reittiä pitkin takaisin liittyvälle solmulle. Jos liittyvällä solmulla eiole tiedossaan reittiä ryhmään, lähettää se liittymis-RREQ:n tulvimalla koko verk-koon. Viesti saapuu aikanaan ryhmän jäsensolmulle, joka vastaa RREP:llä, jos sol-mun tuntema ryhmän sekvenssinumero on vähintään yhtäsuuri kuin RREQ:ssa ole-va. Tärkeimmät RREP:n sisältämät tiedot ovat ryhmän sekvenssinumero, ryhmänjohtajan 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 ta-kaisin liittyvälle solmulle kasvattaa sitä yhdellä. Jäsensolmu ei lähetä RREQ:ta enääeteenpäin.

Jokainen RREQ:n tai RREP:n välittänyt solmu asettaa itselleen seuraavan hy-pyn osoittimet, kuten kohdassa 4.6.1 esitettiin. Liittyvälle solmulle voi tulla usei-ta RREP-viestejä, koska RREQ on todennäköisesti kulkeutunut useille eri jäsensol-muille. RREP-viesteistä valitaan se, jolla on pienin etäisyys ryhmän jäseneen. Tämänjälkeen puuhun liittyminen on viimeisteltävä aktivoimalla reitti. Aktivointi suori-tetaan ilmoittamalla valitun reitin solmuille, että ne tulevat osaksi ryhmälähetys-puuta. Ilmoittaminen suoritetaan lähettämällä erityinen reitin aktivointiviesti (engl.multicast activation, MACT) solmulle, jota kautta kulkeva reitti on valittu. Reitin sol-mut ohjaavat MACT:n osoittimiensa avulla aina ryhmän jäsenelle saakka, samaantapaan kuin RREQ:n ja RREP:n yhteydessä. Muut RREQ:ta ja RREP:tä välittäneetsolmut poistavat liittymisprosessin aikana tekemänsä osoittimet ajastimien lautet-tua. Kuva 4.9 a esittää solmun A lähettämän RREQ-viestin tulvintaa verkossa. Ku-vassa 4.9 b näkyy neljä kappaletta ryhmän jäsenten lähettämää RREP-viestiä, kunne kulkevat takaisin solmulle A. Kuvassa 4.9 c solmu A on valinnut lyhimmän reitinryhmään.

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 en-simmäisen liittymispyyntöviestinsä unicastina ryhmän johtajalle, lähetetään seuraa-vat pyynnöt tulvinnalla. Tämä siksi, että unicast-reitti voi olla vanhentunut tai jokinmuu solmu on tullut ryhmän johtajaksi. Jos vastausta ei useampien lähetyskerto-jen jälkeenkään tule, voidaan päätellä, että solmu ei saa yhteyttä ryhmään. Ryhmävoi olla tällöin kokonaan ilman jäseniä tai vaihtoehtoisesti verkko voi olla osittunutniin, että kyseisessä osassa verkkoa ei ole ainuttakaan halutun ryhmän jäsentä. Nytsolmusta itsestään tulee ryhmän johtaja ja se ryhtyy mainostamaan ryhmää muulleverkolle. Muut solmut voivat liittyä tähän ryhmään. Osittumisen tapauksessa voi-daan saman ryhmän kaksi tai useampaa puuta yhdistää jälleen yhdeksi. Yhdistymi-nen selitetään kohdassa 4.6.6.

37

Kuva 4.9: 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 liittynytpuuhun (oikea alhaalla).

38

Solmu voi poistua ryhmälähetyspuusta ainoastaan, jos se on lehtisolmu, eli sil-lä ei ole yhtään jäsensolmua, joiden isäntäsolmu se on. Jos solmu ei ole lehtisol-mu, 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 kysei-sen solmun tiedot reititystaulustaan. Irroittaumis MACT-viestin saatuaan solmustavoi itsestään tulla lehtisolmu. Jos solmu on tähän asti vain välittänyt ryhmälähe-tysviestejä, voi se poistaa itsensäkin puusta samalla menetelmällä. Näin jatketaan,kunnes ryhmälähetystä vastaanottava solmu tai ei-lehtisolmu saavutetaan.

4.6.5 Puun korjaus

Jokainen puun jäsensolmu kuulee kaikki naapurisolmujensa lähetykset. Jos solmuei ole saanut ryhmän jäsensolmuna olevalta naapuriltaan multicast-viestejä tai ter-vehdysviestejä (kts. 4.6.1) määräaikaan mennessä, olettaa se linkin naapuriin ole-van poikki. Tässä tilanteessa katkeamiskohdasta alavirtaan oleva solmu on velvolli-nen korjaamaan katkeama. Solmu lähettää RREQ-viestin tulvimalla sen vain muu-taman solmun etäisyydelle, koska todennäköisesti lähellä sijaitsee solmuja, joidenkautta linkki saadaan jälleen kulkemaan. Viestiin asetetaan ryhmän IP-osoite ja se-kvenssinumero, sekä korjauksen tekevän solmun etäisyys ryhmänjohtajasta. Jokai-nen puun jäsensolmu, jonka tietämä ryhmän sekvenssinumero on vähintää yhtä-suuri kuin viestissä oleva ja jonka etäisyys ryhmänjohtajasta on pienempi kuin vies-tissä voi vastata viestiin. Näin taataan, että korjaava solmu saa tuoreen reitin ryh-mään ja että vastaava solmu todella sijaitsee ylävirtaan korjaavasta solmusta. Vas-tausviesti on RREP ja se lähetetään takaisin samaa reittiä. Reitti aktivoidaan lopultaMACT-viestiä käyttäen (kts. 4.6.4).

Jos korjaava solmu ei saa vastausta, lähettää se korjauksen pyynnön koko verkonkattavana tulvintana. Jos vieläkään vastausta ei kuulu, on verkko todennäköisestiosittunut. Nyt solmun osa ryhmää on ilman johtajaa, joten uusi 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 sepoistaa itsensä puusta lähettämällä MACT-viestin (kts. 4.6.4). Viestin vastaanotta-nut solmu huomaa sen tulleen ryhmäjohtalle johtavasta linkistä, jolloin se päätteleeverkon osittuneen. Solmusta tulee ryhmän johtaja, jos se on ryhmän jäsensolmu. Jostämäkin solmu on vain puun jäsensolmu ja sillä on vain yksi lapsisolmu, voi se-

39

kin 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 puus-ta. Solmu lähettää tässä tapauksessa jollekin lapsisolmuistaan MACT-viestin, jossaon ilmoitus, että vastaanottavan solmun tulee ryhtyä uudeksi ryhmänjohtajaksi. Josvastaanottava solmu ei ole ryhmän jäsen, lähettää se viestin edelleen, kunnes ryh-män jäsensolmu saavutetaan.

Vastavalittu ryhmänjohtaja lähettää erityisen päivitys-group hello -viestin, jolloinkaikki saavutettavissa olevat solmut päivittävät tietonsa uudesta ryhmänjohtajasta.Katkeamiskohdan ylävirran puoleinen solmu voi irrouttautua puusta, jos se ei oleryhmän jäsensolmu, ja jos se katkeamisen vuoksi on jäänyt lehtisolmuksi. Solmuodottaa kuitenkin jonkin aikaa, ennen kuin se irroittautuu, koska korjattu reitti voikulkea sen kautta.

4.6.6 Puiden yhdistäminen

Verkon osittumisen vuoksi syntyneet saman ryhmän useat puut on yhdistettävä he-ti, kun eri osiot saavat jälleen yhteyden toisiinsa. Uusi yhteys osioiden välillä havai-taan, kun jokin puun jäsensolmu vastaanottaa vähintään kahden eri ryhmänjohtajanlähettämän group hello -viestin. Yhdistymisprosessin käynnistää se ryhmän jäsensol-mu, jonka tunteman ryhmänjohtajan IP-osoite on pienempi. Solmu lähettää omalleryhmänjohtajalleen (jolla siis pienempi IP-osoite) unicastina RREQ-viestin, jossa onilmoitus osioiden yhdistämisestä. Ryhmänjohtaja antaa solmulle luvan puiden yh-distämiseen lähettämällä RREP:n. Solmu lähettää nyt vuorostaan toiselle ryhmän-johtajalle unicastina RREQ-viestin, joka sisältää yhdistämisilmoituksen ja uusimmansolmun tunteman ryhmän sekvenssinumeron. Vastaanottavasta ryhmänjohtajastatulee nyt yhdistetyn ryhmän johtaja. Se valitsee viestissä olevasta ja itse ylläpitämäs-tään sekvenssinumerosta suuremman uudeksi sekvenssinumeroksi ja vastaa yhdis-tämisen aloittaneelle solmulle RREP:llä, jolloin puun osat yhdistyvät. Uusi ryhmän-johtaja lähettää päivitys-group hello -viestin, jolloin kaikki puun solmut saavat tiedonuudesta ryhmänjohtajasta.

4.7 ODMRP

ODMRP on mesh-pohjainen, on-demand -periaatteella toimiva ryhmälähetysproto-kolla. Se ei tarvitse avukseen unicast-protokollaa, vaan se pystyy hoitamaan kaikkitarvittavat viestien lähetykset itse. Verkon solmuista kootaan ns. välitysryhmä (kts.4.2), joka koostuu ryhmälähetysviestejä vastaanottavista solmuista sekä niitä yhdis-

40

tävistä välittäjäsolmuista. Mikä tahansa ryhmän jäsensolmu voi toimia ryhmälähe-tysviestien lähettäjänä. Mesh-pohjaisena protokollana ODMRP sietää hyvin nopeas-tikin muuttuvaa verkon topologiaa.


Jokainen ODMRP:tä tukeva solmu tarvitsee seuraavia reititystietotauluja:

• Jäsentaulu: Jokainen ryhmän jäsensolmu tallentaa jokaista ryhmää kohti, jonkajäsen solmu on, kaikkien niiden lähettäjien tunnisteet, joilta solmu haluaa vas-taanottaa 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. Joslähettäjältä ei tule uutta join requestia ennen ajastimen laukeamista, poistetaanmerkintä.

• Reititystaulu: Jokainen verkon solmu, oli se välittäjäsolmu tai ei, merkitsee joinrequestin saatuaan tähän tauluun sen lähettäneen solmun tunnisteen sekä sennaapurisolmun tunnisteen, jonka kautta viesti saapui. Tietoa käytetään liitty-miseviestin ohjaamiseen oikeaan suuntaan.

• Välittäjäryhmätaulu: Jokainen välittäjäsolmu tallentaa jokaisen ryhmän tunnis-teen, jonka välittäjänä solmu toimii. Jokaista ryhmää kohti on ajastin, joka nol-lautuu aina, kun solmu saa ryhmän osoitteella varustetun liittymisviestin.

• Viestien tallennustaulu: Jokainen verkon solmu tallentaa määräajaksi jokaises-ta vastaanotetusta viestistä lähettäjän tunnisteen sekä paketin sekvenssinume-ron. Solmu pystyy näin estämään samojen viestien välittämisen uudelleen. Jo-kainen solmu kasvattaa sekvenssinumeroa yhdellä aina, kun se lähettää minkätahansa viestin.

4.7.2 Liittyminen ja ryhmälähetys

Solmu lähettää määräajoin ryhmäänkutsumisviestiä (engl. join request) tulvimallakoko verkkoon, jos sillä on dataa lähetettävänä ryhmälle. Viestillä on kaksi tarkoi-tusta: se mainostaa ryhmän olemassaoloa verkolle ja se mahdollistaa solmujen liit-tymisen ryhmän jäseniksi. Jokainen solmu tallentaa sen naapurisolmun tunnistetie-dot, jolta join request saapui ensimmäisenä. Näin jokainen solmu oppii, minkä naa-purin kautta lyhin reitti lähettäjälle kulkee. Solmu lähettää viestin edelleen omil-le naapureillensa. Join request varustetaan viestin yksilöivillä tunnistetiedoilla, joten

41

mikään solmu ei välitä myöhemmin tulleita viestejä sen jälkeen, kun ensimmäinenon välitetty. Kuva 4.10 esittää kahden eri lähettäjän join request -viestien kulun ver-kossa. Kuvassa näkyvät ne viestit, jotka tulevat kullekin solmulle ensimmäisenä.Näitä reittejä pitkin voivat kulkea seuraavassa esitetyt liittymisviestit.

Kuva 4.10: Kahden lähettäjän join request -viestien reitit.

Jos solmu haluaa tulla ryhmän jäseneksi, lähettää se join requestin saatuaan liit-tymisviestin (engl. join table) kohti lähettäjää samaa reittiä pitkin, mitä join requestsaapui. Liittymisviesti sisältää seuraavan hypyn (kohti lähettäjää) tunnisteen jokais-ta lähettäjää kohti, jota solmu haluaa kuunnella. Viesti voi siis sisältää maksimis-saan yhtä monta eri naapurisolmun tunnistetta kuin kuunneltavia lähettäjäsolmu-ja kyseisellä vastaanottajasolmulla on. Liittymisviesti kulkeutuu takaisin lähettäjillelyhintä reittiä pitkin. Jokainen reitillä oleva solmu merkitsee itsensä välittäjäksi ky-seiselle ryhmälle. Liittymisviestin tarkoitus onkin vain ilmoittaa jokaiselle solmulle,jonka kautta viesti kulkee, että kyseisen solmun tulee välittää halutun ryhmän vies-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ää jokaisenlä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.11 esittää liitty-misviestien kulun takaisin lähettäjille neljältä eri vastaanottajalta. Kuva 4.12 esittääsyntyneitä reittejä ryhmälähetykselle. Kaikki välittäjäsolmut välittävät molempienlähettäjien multicast-viestejä.

42

Kuva 4.11: Vastaanottajien liittyminen ryhmään.

Kuva 4.12: Muodostunut mesh.

43

4.7.3 Ryhmästä poistuminen ja topologian muutokset

Protokollassa ei käytetä mitään erityistä viestiä ryhmästä poistumiseksi. Ryhmänjäsensolmu lähettää join table -viestiä säännöllisin väliajoin niin kauan, kun se halu-aa 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 pysyyvoimassa taas tietyn ajan. Jos solmu ei saa liittymisviestiä ajastimen laukeamiseenmennessä, poistaa solmu ryhmän merkinnän omista reititystiedoistaan. Solmu lak-kaa tällöin välittämästä ryhmän viestejä. Ryhmän jäsensolmu poistuu ryhmästä yk-sinkertaisesti lakkaamalla lähettämästä join table -viestejä, jolloin sille ei hetken ku-luttua enää välity multicast-lähetyksiä. Vastaanottajasolmu voi myös lakata vastaa-nottamasta jonkin tietyn tai tiettyjen lähettäjien ryhmälähetysviestejä. Tällöin solmupoistaa kyseisen lähettäjän tunnisteen join table -viestistään.

Verkon topologian muutoksista johtuvat yhteyksien katkeamiset eivät aiheutaylimää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änmainostuksen ja sitä seuraavan liittymisviestin lähetyksen jälkeen. Ensimmäiseksisaapunut join request on nyt tullut jotain toista reittiä vastaanottajalle, jolloin vas-taanottaja 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. Josvastaanottaja 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ä.

44

5 Ryhmälähetysprotokollien vertailua

Luvussa tehdään yhteenveto edellä esitettyjen protokollien tärkeimmistä suoritus-kykyyn vaikuttavista ominaisuuksista. Sen jälkeen tarkastellaan suorituskykyana-lyysejä, joissa kyseiset protokollat ovat olleet mukana. Lopuksi kootaan yhteen tut-kimuksissa esiintyneet johtopäätökset ja tulokset.

Kaikkia neljää edellä esitettyä protokollaa ei ole vertailtu keskenään samassa tut-kimuksessa, joten tähän työhön on koostettu tuloksia ja johtopäätöksiä kolmesta eritutkimuksesta [12] [13] [14]. ADMR, ODMRP ja MAODV ovat olleet keskinäisessävertailussa samassa tutkimuksessa [12], joten sitä käytetään pohjana kohdissa 5.2.1ja 5.2.2. CAMP-protokollan tarkastelu on esitetty erillään, koska sitä on vertailtuvain ODMRP:n kanssa [14]. Kaikkien kolmen tutkimuksen johtopäätökset on koot-tu kohtaan 5.4.

5.1 Kvalitatiivinen vertailu

Seuraavaan taulukkoon on koottu edellä esitetyistä protokollista tärkeimpiä suo-rituskykyyn vaikutavia tekijöitä. Mikään protokollista ei muodosta reitityksessäänsilmukoita. Silmukat voisivat pahimmillaan lamauttaa täysin protokollan toimin-nan. Jos protokolla käyttää erityisiä viestejä ryhmästä poistumiseen, voi ryhmäänjäädä ”roikkumaan” sellaisia solmuja, jotka eivät ryhmälähetystä halua vastaanot-taa. Näin käy, jos poistumisviesti ei mene perille.

Taulukko 5.1: Protokollien tärkeimmät ominaisuudet.

Ominaisuus ADMR CAMP MAODV ODMRPRyhmän rakenne puu mesh puu mesh

Sisältää silmukoita ei ei ei eiRiippuvuus unicast-protokollasta ei kyllä ei ei

Jaksottainen tulvinta ei ei kyllä kylläErityinen poistumisviesti ei kyllä kyllä ei

45

5.2 ADMR, MAODV ja ODMRP vertailussa

ODMRP:n, ADMR:n ja MAODV:n keskinäisessä vertailussa tutkimusympäristönäoli verkko, joka koostui 100 mobiililaitteesta (solmusta), jotka sijoitettiin satunnai-sesti 1200x800 metrin kokoiselle alueelle. Solmujen yhteyksien kantama oli 250 m jalinkkiyhteydet olivat symmetrisiä. Maksimilähetysnopeus oli 2 Mbit/s. Solmut liik-kuivat ns. satunnaisen reitin mallin mukaisesti (engl. random waypoint model), jolloinsolmu valitsee satunnaisen kohteen alueen sisällä ja lähtee liikkumaan sitä kohti sa-tunnaisella nopeudella. Kohteeseen saapuessaan solmu odottaa satunnaisen ajan,jonka jälkeen lähtee uuteen satunnaiseen kohteeseen satunnaisella nopeudella. Ko-keissa solmujen nopeus vaihteli välillä [0,20] m/s, ja odotusaika oli 0 ms [12].

Muuttujina olivat ryhmän koko ja lähettäjien lukumäärä. Tutkimuksissa mitat-tiin useita arvoja, ja tähän työhön on koottu niistä osa.

Vastaanottosuhde (engl. receive ratio) tarkoittaa vastaanotettujen pakettien luku-määrän suhdetta määrään, joka pitäisi vastaanottaa. Aina pienempi tai yhtä-suuri kuin yksi.

Ylimääräinen viestitys (engl. overhead) on protokollan tuottamien kontrollipaket-tien lukumäärä.

Viive (engl. delay) tarkoittaa aikaa, joka datapaketilta kuluu kulkea matka lähettä-jältä vastaanottajalle. Viiveen arvoksi on otettu keskiarvo kaikista datapaket-tien kokemista viiveistä.

5.2.1 Ryhmän koon vaihtelu

Protokollien (ODMRP, ADMR ja MAODV) reagointia ryhmälähetysten vastaanot-tajien määrän kasvuun tutkittiin kolmella eri tapauksella, joissa jokaisessa oli yksilähettäjä ja yksi ryhmä. Vastaanottajien määrät olivat 10, 50 ja 99.

– Vastaanottosuhde: Kaikilla protokollilla vastaanotettujen pakettien suhde lä-hetettyihin parani ryhmän kokoa lisättäessä. Jokaisella protokollalla suhde olijo pienimmällä koolla yli 95 %. ODMRP:llä oli keskimäärin paras vastaanot-tosuhde ja MAODV:lla huonoin. Suurimmalla ryhmäkoolla protokollat olivattasaveroisia.

– Ylimääräinen viestitys: MAODV tuotti eniten ylimääräistä viestitystä ja ADMRselvästi vähiten. ADMR:n ja ODMRP:n ylimääräinen viestitys lisääntyi ryh-män koon kasvaessa, mutta MAODV:lla se laski. Suurimmalla ryhmäkoolla

46

MAODV:n overhead oli jo lähellä ODMRP:n arvoja. ODMRP:n käyttämä jak-sottainen ryhmän mainostus ja vastaanottajien vastaukset lisäävät kontrolli-pakettien määrää ryhmän koon kasvaessa. MAODV:ssa pystytään käyttämäänenemmän paikallisia ryhmään liittymis- ja puun korjaustoimenpiteitä, kun puunkoko kasvaa. Siksi ylimääräinen viestitys pienenee.

– Viive: ODMRP:llä lähetyksien viive on pienin ja MAODV:lla selvästi suurin.ODMRP uusi ryhmälähetysrakenteensa jokaisen ryhmän mainostuksen yh-teydessä, jolloin lyhimmät reitit vastaanottajille ovat lähes jatkuvasti käytössä.MAODV:n paikallinen puuhun liittyminen kasvattaa lähettäjien ja vastaanot-tajien välisien reittien pituuksia, jolloin myös viive kasvaa puun koon myö-tä. MAODV:n suurempi kontrollipakettien määrä lisää verkon ruuhkaa (engl.congestion) ja viestien yhteentörmäyksiä, jolloin viive kasvaa.

5.2.2 Lähettäjien lukumäärän vaihtelu

Seuraavaksi ODMRP:n, ADMR:n ja MAODV:n käyttäytymistä tutkittiin, kun ryh-män lähettäjien lukumäärää kasvatettiin. Ryhmien lukumäärä oli yksi ja vastaantot-tajien määrä oli 20. Lähettäjien määrät olivat 1, 5 ja 10.

– Vastaanottosuhde: Jokaisella protokollalla vastaanottosuhde pysyi korkeana.ADMR:n ja MAODV:n vastaanottosuhde pysyi melko samana, mutta ODMRP:lläsuhde laski lähettäjien määrän kasvaessa. ODMRP:n suhde oli alussa korkein,mutta se putosi hieman muita heikommaksi lähettäjien määrän ollessa 10.ODMRP:n suhteen lasku johtuu pitkälti lisääntyvästä overheadista, joka kas-vatta verkon ruuhkaa (kts. seuraava kohta).

– Ylimääräinen viestitys: ADMR:n ja ODMRP:n overhead kasvoi, kun lähettäjienmäärää lisättiin. ADMR:llä arvo oli pienin. ODMRP:llä arvo oli taas suurin,lukuunottamatta yhden lähettäjän tapausta. ODMRP:n ylimääräinen viestityskasvoi lähes lineaarisessa suhteessa lähettäjien määrään nähden. Tämä johtuujokaisen ODMRP:n lähettäjän käyttämistä ryhmän mainostusviesteistä ja suu-resta datapakettien määrästä (ylimääräisiä reittejä vastaanottajille), jotka lisää-vät verkon ruuhkaa. MAODV:ssä vain ryhmänjohtaja mainostaa jaksottaisestiryhmää koko verkolle, joten sen overhead pysyy vakiona lähettäjien lukumää-rästä riippumatta.

– Viive: ADMR:n ja ODMRP:n viive kasvoi lähettäjien määrää lisättäessä, muttaMAODV:llä viive pysyi lähes vakiona. MAODV:lla oli kuitenkin suurin viive,

47

kun taas ODMRP:llä se oli pienin. Syyt ovat samat kuin ryhmän kokoa kasva-tettaessa.

5.3 CAMP ja ODMRP vertailussa

CAMP-protokollaa verrattiin ODMRP:ään muuttelemalla verkon solmujen nopeut-ta, vastaanottajien määrää, sekä ryhmän lähettäjien lukumäärää. Tutkimuksessa käy-tetty verkko koostui 50 kappaleesta liikkuvia solmuja, jotka oli aseteltu satunnaises-ti 1000x1000 metrin kokoiselle alueelle. Radiolinkkien maksimikantama oli tässä-kin 250 m ja linkkiyhteydet olivat symmetrisiä. Maksimaalinen yhteysnopeus oli 2Mbit/s. Solmut liikkuivat satunnaiseen suuntaan, kunnes ”törmäsivät” alueen reu-naan. Solmut kimmahtivat reunasta ja jatkoivat uuteen suuntaan. Testissä CAMPkäytti apunaan WRP (Wireless Routing Protocol) -protokollaa, joka on proaktiivi-nen unicast-protokolla. Mitatut arvot olivat vastaanottosuhde ja overhead, jotka onmolemmat selitetty kohdassa 5.2 [14].

5.3.1 Solmujen nopeuksien vaikutus

Nopeuden vaikutusta testattiin nostamalla solmujen nopeus asteittain nollasta ainanopeuteen 72 km/h. Lähettäjiä oli viisi kappaletta ja vastaanottajia 20.

– Vastaanottosuhde: ODMRP:llä vastaanottosuhde pysyi lähes vakiona, ollennoin 95 %. CAMP:llä suhde oli hieman yli 90 %, kun nopeus oli nolla. Kun no-peutta kasvatettiin, laski suhde erittäin jyrkästi noin 60 prosenttiin. Suhde las-ki hitaasti noin 55 prosenttiin, kun nopeutta kasvatettiin maksimiin. CAMP:nsuhteen lasku johtui alla olevasta WRP:stä, joka ei selviä suuresta liikkuvuu-desta. Toinen syy on CAMP:n muodostaman mesh-rakenteen pienempi kokokuin ODMRP:llä, jolloin ylimääräisiä reittejä vastaanottajille ei synny niin pal-joa.

– Ylimääräinen viestitys: ODMRP:n tuottama ylimääräinen viestitys pysyi va-kiona nopeuden muuttuessa, koska yhteyksien katkeamisista ei seuraa kont-rolliviestien lähetyksiä. CAMP:llä taas overheadin määrä kasvaa, koska WRPlähettää reittien päivitysviestejä aina reittien muuttuessa. Päivitysviestejä lä-hetetään sitä tiheämmin, mitä suurempaa on solmujen liike.

48

5.3.2 Ryhmän koon vaikutus

Ryhmän kokoa muutettiin asteittain viidestä vastaanottajasta neljäänkymmeneen.Lähettäjien lukumäärä oli viisi ja jokainen solmu kulki nopeudella 1 m/s.

– Vastaanottosuhde: ODMRP:llä vastaanottosuhde pysyi noin 95 prosentissa kai-killa ryhmän kooilla. CAMP:ssä taas ryhmän koolla on suuri merkitys. Viidel-lä vastaanottajalla oli suhde vain noin 35 %, ja neljälläkymmenellä suhde oli joyli 80 %.

5.3.3 Lähettäjien lukumäärän vaikutus

Lähettäjien lukumäärää nostettiin asteittain yhdestä kahteenkymmeneen. Ryhmänkoko pidettiin vakiona kahdessakymmenessä. Solmujen nopeus oli myös vakio, 1m/s.

– Vastaanottosuhde: Molemmilla protokollilla suhde paranee lähettäjien lisää-misen myötä. Syynä on kattavamman mesh-rakenteen muodostuminen. Edelläkäsitellyssä tutkimuksessa ODMRP:n vastaanottosuhde laski lähettäjien mää-rän lisääntyessä. Tässä tutkimuksessa ODMRP:stä on käytetty sellaista ver-siota, jossa yhtäaikaisia ryhmän mainostusviestejä pyritään välttämään. Verk-ko ei näin ruuhkadu useiden solmujen mainostusviesteistä, ja siten vastaan-ottosuhde on parempi. ODMRP:llä suhde nousee 90:stä 99:ään prosenttiin jaCAMP:llä 45:stä 70:een prosenttiin.

– Ylimääräinen viestitys: CAMP-protokollalla overhead pysyy lähes vakiona ko-ko ajan ja on oleellisesti pienmpi kuin ODMRP:llä. ODMRP:n overhead kasvaavoimakkaasti lähettäjien lukumäärän lisääntyessä. Vaikka yhtäaikaisia mai-nostusviestejä vältetäänkin, kasvaa kuitenkin viestien lukumäärä.

5.4 Tutkimusten johtopäätöksiä

ADMR, ODMRP ja MAODV omaavat jokainen yleisesti ottaen hyvän vastaanot-tosuhteen, joka on yli 90 %. ADMR oli edellämainituista protokollista pääsääntöi-sesti tehokkain, eli tuotti pienimmän määrän ylimääräistä viestiliikennettä verkos-sa. MAODV tuotti selvästi eniten overheadia ja kärsi myös pisimmästä viiveestä.ODMRP:llä oli viive taas pienin, mutta tuotti paljon kuormaa verkolle. ODMRP:ssädata- ja kontrollipaketteja lähetetään suuri määrä ryhmän koon tai lähettäjien lu-

49

kumäärän kasvaessa. Voidaan päätellä, että ODMRP ei sovellu hyvin suurille mul-ticast-ryhmille, varsinkin jos lähettäjiä on useita.

CAMP-protokolla on yleisesti ottaen ODMRP:tä heikompi kaikissa skenaariois-sa, kun mitataan vastaanottosuhdetta ja overheadia. CAMP osoittaa kuitenkin pa-rempaa skaalautuvuutta ryhmän kokoon ja lähettäjien lukumäärään nähden. Tutki-muksessa ei kuitenkaan käytetty niin suuria ryhmän kokoja, että tämä olisi voitu to-deta. CAMP:n suorituskyky riippuu erittäin paljon sen yhteydessä olevasta unicast-protokollasta. Tämän huomaa, kun verkon solmut ovat hyvin liikkuvia.

Tutkimuksessa [13] esitettiin muutamia yleisiä huomioita protokollien suun-nitteluun. Protokollia tulisi optimoida suurta solmujen liikkuvuutta silmälläpitäen.Linkkiyhteyksien katkeamisiin tulisi reagoida, mutta mahdollisimman pienellä sig-naloinnilla (overheadilla). Huomiota tulee myös kiinnittää protokollan toimintaanympäristössä, jossa solmuja on erittäin paljon pienellä alueella, eli naapurien määräon suuri. Tällöin saattaa esimerkiksi ilmoittautumisia vastaanottavalle solmulle tul-la liikaa yhtäaikaisia liittymispyyntöjä, jolloin protokollan toiminta heikkenee oleel-lisesti. Erittäin tärkeää on erottaa linkkiyhteyden katkeamisesta ja ruuhkasta johtu-vat pakettien häviämiset toisistaan. Jos paketteja häviää ruuhkan vuoksi ja proto-kolla ryhtyy ryhmälähetysrakenteen korjaustoimenpiteisiin, pahenee tilanne enti-sestään toimenpiteistä seuraavien kontrollipakettien lähetyksien vuoksi.

50

Viitteet

[1] Tietotekniikan verkkosanakirja, <URL: http://whatis.techtarget.com/>,18.1.2006.

[2] Olli Alanen, Ryhmälähetysten palvelunlaatu, pro gradu-tutkielma, Tietotekniikanlaitos, Jyväskylän yliopisto, Jyväskylä, 2004.

[3] Amitava Mukherjee, Location Management and Routing in Mobile WirelessNetworks, Artech House, Norwood, MA, USA, 2003.

[4] Carlos de Morais Cordeiro, Hrishikesh Gossain ja Dharma P. Agrawal, Mul-ticast over Wireless Mobile Ad Hoc Networks: Present and Future Directions, IEEENetwork, Tammikuu/Helmikuu 2003.

[5] Hung-Yun Hsieh, Raghupathy Sivakumar, On Using Peer-to-Peer Communicationin Cellular Wireless Data Networks, IEEE Transactions on Mobile Computing, Vol.3, No. 1, tammikuu-maaliskuu 2004.

[6] J.J.Garcia-Luna Aceves, Ewerton L. Madruga, A Multicast Routing Protocol forAd-Hoc Networks, IEEE Proceedings, Volume 2, 21-25 Maaliskuu 1999 s. 784–792.

[7] Jorjeta G. Jetcheva, David B. Johnson, Adaptive Demand-Driven Multicast Routingin Multi-Hop Wireless Ad Hoc Networks, ACM Proceedings, Lokakuu 2001 s. 33–44.

[8] Jorjeta G. Jetcheva, David B. Johnson, The Adaptive Demand-Driven Multicast Rou-ting Protocol for Mobile Ad Hoc Networks (ADMR), IETF MANET Working GroupINTERNET-DRAFT, 13 Heinäkuuta 2001.

[9] Charles E. Perkins, Elizabeth M. Royer, Ad-hoc On-Demand Distance Vector Rou-ting, IEEE Workshop, 25-26 Helmikuuta 1999 s. 90–100.

[10] Elizabeth M. Royer, Charles E. Perkins, Multicast Operation of the Ad-hoc On-Demand Distance Vector Routing Protocol, ACM Proceedings, Elokuu 1999 s. 207–218.

[11] Sung-Ju Lee, Mario Gerla ja Ching-Chuan Chiang, On-Demand Multicast Rou-ting Protocol, IEEE, 21-24 Syyskuuta 1999 s. 1298–1302.

51

[12] Jorjeta G. Jetcheva, David B. Johnson, A Performance Comparison of On-DemandMulticast Routing Protocols for Ad Hoc Networks, School of Computer Science,Computer Science Department, Carnegie Mellon University, Pittsburgh, 15 Jou-lukuuta 2004.

[13] Manoj Pandey, Daniel Zappala, A Scenario-Based Performance Evaluation of Mul-ticast Routing Protocols for Ad Hoc Networks, Sixth IEEE International Symposium,13-16 Kesäkuuta 2005 s. 31–41.

[14] Sung-Ju Lee, William Su, Julian Hsu, Mario Gerla ja Rajive Bagrodia, A Perfor-mance Comparison Study of Ad Hoc Wireless Multicast Protocols, IEEE Proceedings,Volume 2, 26-30 Maaliskuu 2000 s. 565–574.

52

Documents

Ryhmälähetys mobiileissa ad hoc -verkoissa · Tekijä: Teijo Venäläinen Yhteystiedot: [email protected] Työn nimi: Ryhmälähetys mobiileissa ad hoc -verkoissa Title in English: