AD HOC MREŽE

Uvod
U poslednjoj deceniji 20. veka, jedna od najatraktivnijih tema u računarstvu i komunikacijama bile su bežične tehnologije. One su privukle
mnoge korisnike, pretrpele su brojne transformacije, uključujući i uvođenje bežičnog Interneta. Naredni korak u evoluciji bežičnih
komunikacija jesu Ad Hoc mreže, koje ne zahtevaju nikakvu mrežnu infrastrukturu osim postojećih mobilnih čvorova. U ovoj seriji
pokušaćemo da objasnimo osnovne ideje vezane za Ad Hoc mreže, zatim ćemo uporediti Ad Hoc mreže sa klasičnim bežičnim mrežama,
objasniti protokole za Ad Hoc rutiranje, pozabaviti se pitanjima sigurnosti, dati uvod u Bluetooth tehnologiju, predstaviti projekat Ad Hoc
senzorske mreže realizovane na Elektrotehničkom fakultetu u Beogradu, a na kraju ćemo napraviti korak ka bežičnom Internetu.

Mobilne mreže
Prvo ćemo se pozabaviti evolucijom mrežnih komunikacija, tj. objasnićemo na koji način Ad Hoc mreže predstavljaju sledeći korak u
razvoju globalnih komunikacija.

Razlikujemo dva osnovna tipa Ad Hoc mreža. To su mreže mobilnih računara kojima rukuju korisnici i bežične senzorske mreže. Prvu grupu
sačinjavaju prenosni računari, mobilni telefoni, lični digitalni asistenti (personal digital assistants – dalje PDA), i slični uređaji kojima rukuju
korisnici, dok se druga grupa sastoji od autonomnih elektronskih senzorskih uređaja.

Međutim, bez obzira na grupu, osnovna karakteristika svake Ad Hoc mreže jeste: uspostavljanje komunikcije između čvorova bez unapred
postojeće mrežne infrastrukture.

Bilo bi mudro da ovde zastanemo za trenutak. Šta je u stvari Ad Hoc mreža? Daćemo vam jedan primer, na osnovu koga ćete moći lakše da
pratite ostatak ove serije.

Pretpostavimo da imamo na raspolaganju neku vrstu uređaja za bežičnu komunikaciju, koji ima ograničen domet. Pretpostavimo dalje da
pomoću tog uređaja želimo da pošaljemo neku informaciju iz jedne kancelarije u zgradi u drugu kancelariju. Koje mogućnosti nam stoje na
raspolaganju?

Prvo, možemo povezati naš bežični uređaj na postojeću žičanu infrastrukturu i zatim koristiti postojeću mrežnu infrastrukturu za transport.
Nedostaci ovakvog pristupa su očigledni: mobilnost je veoma ograničena, a na ovaj način dodajemo još opterećenja na već preopterećene
žičane mreže. Ne treba ni pominjati da protokoli za rutiranje u žičanim mrežama nisu pogodni za bežičnu komunikaciju.

Druga mogućnost je izgradnja mreže baznih stanica pomoću kojih bismo dobili mogućnost celularne komunikacije. Ovo je bolje rešenje, ali
je veoma skupo.

Treći izbor je da pretpostavimo da mnogo elektronskih uređaja oko nas poseduje istu mogućnost bežične komunikacije kao i uređaj kojim
raspolažemo, a zatim da ih koristimo kao posrednike prilikom transporta. Na primer, paket sa našeg uređaja može da skoči (eng. hop) na
mobilni telefon osobe koja prolazi hodnikom ispred naše kancelarije, zatim sa njegovog mobilnog telefona na mrežni laserski štampač koji se
nalazi u susednoj kancelariji, sa štampača na digitalni sat osobe koja radi na spratu ispod, zatim sa digitalnog sata na mašinu za kafu i
konačno, sa mašine za kafu do konačnog odredišta, tj. kancelarije koja se nalazi na susednom spratu.

Slika 1: Osnovna Ad Hoc mrežna arhitektura.

Komentar: Poruka skače sa jednog mobilnog čvora na drugi. Svaki čvor se ponaša kao posrednik i poseduje mogućnost rutiranja
poruka.

To je upravo ono što možete da vidite na slici 1: poruka skače sa jednog mobilnog čvora na drugi sve dok ne stigne do odredišta. Zvučni kao
naučna fantastika? Varate se, tehnologija koja omogućava da se svaki elektronski uređaj ponaša na sličan način već postoji.

Sada ste upoznali osnovnu ideju Ad Hoc mreža. Koje su prednosti ovakvog pristupa mrežnoj komunikaciji? Navešćemo samo nekoliko
(nedostatke ćemo, naravno, ostaviti za kasnije):

 jednostavna instalacija i nadogradnja

 skromni zahtevi za postojećom infrastrukturom
 niska cena i jeftino održavanje
 velika fleksibilnost

Već smo rekli da se Ad Hoc mreže mogu smatrati narednim korakom u evoluciji mrežnih komunikacija. Da bismo bolje razumeli Ad Hoc
mreže, trebalo bi da znamo iz čega su one nastale.
Fiksne računarske mreže imaju mnogo dobrih strana kao što su veoma detaljni i razrađeni koncepti, mehanizmi i infrastuktura; veoma dugo
iskustvo koje je stvarano u proteklim decenijama; kao takve, fiksne računarske mreže predstavljaju korisnu osnovu za razvoj mobilnih mreža.

Međutim, bežična komunikacija ima svoje specifičnosti. Kao što ćemo uskoro videti, korišćenje već razvijenih rešenja nije moguće.
Međutim, kao što je uvek slučaj, projektanti su u početku pokušali da iskoriste modifikacije i adaptacije postojećih mehanizama u
maksimalnoj mogućoj meri. To se pokazalo kao pogrešan prilaz i vremenom se javio veliki broj novih ideja, koje nisu bile opterećene
zastarelim konceptima. Takvi su algoritmi za Ad Hoc rutiranje koje ćemo takođe upoznati u ovoj seriji.

Pre nego što pređemo direktno na srž problema Ad Hoc mreža, prvo ćemo razmotriti mobilne mreže kao celinu, kako bi nam bilo jasnije
zašto baš Ad Hoc mreže zaslužuju posebnu pažnju. Dakle, upoznajmo mobilnu porodicu.

Ne tako davno, mobilne mreže bile su tretirane kao proširenje fiksnih mreža. Tako su se u terminologiji mobilnih mreža, pored mobilnih
čvorova pojavili i fiksni čvorovi i bazne stanice (ili ruteri za podršku mobilnosti).

Da li već osećate da tu nešto nije u redu? Da bi mobilni čvorovi mogli da rade, potrebna nam je velika infrastruktura za podršku, koja je često
znatno komplikovanija od samih mobilnih čvorova. I dok upotreba baznih stanica i fiksnih čvorova ima smisla iz perspektive fiksnih mreža,
mi treba da pokušamo da napustimo ove koncepte. Ono što bismo trebali da uradimo jeste da težimo komplementarnoj, a ne zavisnoj
infrastrukturi. Mobilne mreže treba da rade zajedno sa fiksnim mrežama, umesto da zavise od njih. Međutim, za sada ćemo videti kako rade
klasične mobilne mreže.

Mobilni telefoni su postali deo svakodnevnog života, tako da koncept bazne stanice
skoro nikome nije stran. Svaki ruter za podršku mobilnosti (ili bazna stanica)
pokriva oblast koja je ograničena njegovim dometom. Na taj način se definiše ćelija
– oblast koju pokriva ruter za podršku mobilnosti. U ovakvoj arhitekturi, mobilni
čvor može da komunicira samo sa ruterom za podršku mobilnosti. Mobilni čvorovi MH3
mogu slobodno da se kreću iz jedne ćelije u drugu, i pri tome prelaze u nadležnost
drugog rutera.
MSR
Na sledećoj slici možete videti kako ruter za podršku mobilnosti emituje svim
mobilnim čvorovima u svojoj ćeliji, i kako se formira ćelija. Mobilni čvorovi 1 i 2 MH2
su u dometu rutera za podršku mobilnosti, dok čvor 3 nije u dometu. MH1

Slika 2: Celularna komunikacija

Komentar: Svaki ruter za podršku mobilnosti pokriva oblast koja je ograničena njegovim dometom – ćeliju. Mobilni čvorovi mogu
da komuniciraju samo sa ruterom za podršku mobilnosti.

Možemo reći da ruteri za podršku mobilnosti predstavljaju

mostove između žičane (ili fiksne) mreže i mobilnih čvorova. MH1

Na slici 3 imamo primer tipične mrežne topologije. Možemo

videti fiksni (ili žičani) deo mreže koji se sastoji od fiksnih
čvorova FH1, FH2, FH3 i FH4, zatim je tu ruter za podršku FH3
FH1
mobilnosti MSR, i dva mobilna čvora MH1 i MH2. Šta se dešava MSR
kada jedan od fiksnih čvorova želi da pošalje poruku mobilnom
čvoru? MH2
FH4
FH2

Slika 3: Klasična mobilna mrežna topologija

Komentar: FH1 je izvorišni čvor, a MH2 je odredišni čvor. Mrežna komunikacija podeljena je u dva dela: preko fiksnog i preko
bežičnog dela mreže.

Pretpostavimo da je FH1 izvorišni čvor, a da je MH2 odredišni čvor. Komunikacija između fiksnog čvora i mobilnog čvora može se podeliti
na dva dela:
 Prvi deo predstavlja standardna komunikacija unutar fiksne mreže, od početnog fiksnog čvora do rutera za podršku mobilnosti. Možete
videti da se poruka prenosi preko fiksnog dela postojeće mreže, i da je ruter za podršku mobilnosti samo još jedna adresa u takvoj mreži,
tj. ništa ga ne razlikuje od ostalih fiksnih čvorova. Naravno, pri tome se za ovaj deo komunikacije koristi neki od postojećih transportnih
protokola (to može biti TCP/IP).
 Zatim ruter za podršku mobilnosti emituje poruku svim mobilnim čvorovima u svojoj ćeliji, i onaj koji je adresiran prima poruku. Ovo
je drugi deo mrežne komunikacije – bežična komunikacija između rutera za podršku mobilnosti i mobilnog čvora.

Dakle, dok smo još ovde, hajde da prođemo kroz celu priču još jednom pošto je veoma bitno razumeti kako se vrši ovakva komunikacija,
kako bismo kasnije lakše prešli na Ad Hoc mreže. Mreža ima dva dela: fiksni i mobilni (ili bežični). Ruteri za podršku mobilnosti spajaju ova
dva dela mreže. Mrežna komunikacija takođe je podeljena u dve faze: standardna komunikacija između dva fiksna čvora, od kojih je jedan
početni čvor a drugi je ruter za podršku mobilnosti (koristeći pri tome, na primer, TCP/IP); i bežična komunikacija između rutera za podršku
mobilnosti i mobilnog čvora.

Kada smo to razumeli, možemo detaljnije ispitati ovakvu komunikaciju.

Već smo rekli da su ovakve bežične mreže projektovane tako da zavise od postojeće žičane (tj. fiksne) infrastrukture, što se bilo jasno
vidljivo na slici 3.
Međutim, projektanti se nisu zaustavili na tome:
generalna ideja je sakrivanje mobilnosti od fiksnih MH1
čvorova, tj. posredovanje rutera za podršku mobilnosti
je potpuno transparentno za fiksne čvorove. Fiksni
čvor ne mora da zna da adresira mobilni čvor. U tu
svrhu razvijeni su indirektni protokoli sa ciljem FH3
skrivanja mobilnosti od fiksnih čvorova.
FH1
MSR
MH2
FH4
Slika 4: Indirektni protokoli FH2
Komentar: Posredovanje rutera za podršku
mobilnosti je transparentno. Fiksni deo mreže nije svestan da je adresirani čvor mobilan. Ruter za podršku mobilnosti
skriva tu mobilnost.

Na taj način, poruka se prenosi od fiksnog čvora do mobilnog čvora, a da pri tome fiksni čvor nije ni svestan da je odredišni čvor mobilan.

Zastaćemo ovde za momenat. Ovo očigledno nije ispravan pristup – zašto bismo skrivali mobilnost u okruženju koje zovemo mobilna
mreža? Ovo je stara priča koja se samo ponavlja u novim oblicima – ne možemo samo proširiti postojeće fiksne mreže mobilnim čvorovima i
očekivati da sve savršeno radi, koristeći pri tome mrežne protokole namenjene isključivo žičanoj komunikaciji. Sada smo konačno došli do
srži problema – ono što je potrebno sledećoj generaciji mobilnih mreža nije samo hardver, već novi koncepti i ideje – tj. naredna generacija
protokola za bežično rutiranje.

Sada ćemo ukratko videti koje su karakteristike i ograničenja postojećih tipova bežičnih mreža. Opisana komunikacija je poznata kao one-
hop komunikacija (hop – jedan transfer preko bežičnog linka), tj. ne postoji direktna komunikacija između mobilnih čvorova. Ako dva
mobilna čvora žele da komuniciraju, oni moraju da koriste ruter za podršku mobilnosti i fiksni deo mreže, čak iako se nalaze u istoj ćeliji.
Ovo je veliki nedostatak ovakve arhitekture. Zatim, tu je i pitanje ograničene mobilnosti koja zavisi od postojeće mrežne infrastrukture, pošto
su ruteri za podršku mobilnosti delovi fiksne mreže. Mobilni čvorovi mogu da se kreću samo u oblastima ograničenim dometom ovih rutera i
sopstvenim dometom. Mobilnost je tako ograničena na jedan hop udaljenosti od rutera, tj. mobilni čvor ne može da se udalji od rutera dalje
od dometa njegovog predajnika.

I pored svih navedenih nedostataka, ova generacija mobilnih mreža je veoma važna, pošto nudi polaznu osnovu za dizajn pravih, multihop
bežičnih mreža. Zašto je to važno? Svakako ne sa stanovišta infrastrukture, jer smo već videli da oslanjanje na postojeću infrastrukturu nije
korektan prilaz. Umesto toga, ovakve mreže dovele su do preispitivanja same prirode bežičnih komunikacija, što je otvorilo put ka razvoju
Ad Hoc mreža.

Kao još jedan korak bliže Ad Hoc mrežama, ispitaćemo prirodu bežičnih komunikacija.

Šta možemo zaključiti kada poredimo bežične i žičane linkove:

 bežični linkovi su sporiji, manje pouzdani i podložni gubitku signala zbog šuma i slabljenja
 ograničen propusni opseg
 čest asimetrični kvalitet komunikacije
 mobilni čvorovi su često isključeni iz fiksnih mreža, na kraće ili duže periode (razlozi mogu biti odlazak van dometa, potrošene baterije
i slično)

Sada znamo koje su osobine prosečnih bežičnih linkova, pa se možemo zapitati koje su mogućnosti upotrebe opisanih mobilnih mreža? Prvo
i osnovno, to su bežične lokalne mreže (wireless local area network – WLAN), a zatim i lične mreže (personal area network – PAN). Pored
toga, tu je i mogućnost povezivanja prenosnih računara na postojeće široko upotrebljavane fiksne mreže, kao što je Internet. Sve to je već
realizovano, sa manje ili više uspeha.

Da bismo razumeli prednosti Ad Hoc mreža, prvo moramo naučiti koji su nedostaci i ograničenja klasičnog prilaza mobilnom umrežavanju.
Prvo, potrebna nam je mrežna infrastruktura. Tu spadaju velike investicije u bazne stanice, kao i njihova dugotrajna instalacija. Zatim, zbog
ograničenom dometa, komunikacija se ne može uvek uspostaviti tamo gde je potrebna. Na kraju, održavanje takvih sistema je veoma skupo.

Videli smo šta ovakve mreže mogu da urade, ali šta je to što one NE mogu da urade? U mnogo slučajeva potrebno je uspostaviti mrežnu
komunikaciju čak i kada infrastruktura ne postoji, ili je oštećena. Tipični primeri su spasilačke akcije, zemljotresi, poplave i ratna razaranja.
U takvim slučajevima komunikacija se mora uspostaviti bez prethodne pripreme, tj ad hoc. To nas konačno dovodi do teme ove serije – Ad
Hoc mreža.

Osnovna ideja je već iskazana: ustanoviti mrežnu konekciju bez unapred postojeće mrežne infrastrukture. Pozabavićemo se detaljnije
značenjem ovoga. Naredna slika opisuje prirodu Ad Hoc komunikacije:
Slika 5: Ad Hoc komunikacija

Komentar: Poruka propagira kroz mrežu koristeći čvorove kroz koje prolazi kao switcheve. Dakle, svaki čvor mora imati mogućnost
rutiranja.

Šta možemo videti na prethodnoj slici? Svaki mobilni čvor se tokom komunikacije ponaša kao switch, tj. svaki mobilni čvor poseduje
mogućnost rutiranja. Poruka se efektivno prenosi sa jednog mobilnog čvora na drugi, bez potrebe za ikakvom drugom mrežnom
infrastrukturom.

Šta još možemo ovde primetiti? Pravo, mobilni čvorovi sada mogu da komuniciraju na znatno većim rastojanjima od svojih dometa. To je
moguće zahvaljujući prisustvu drugih mobilnih čvorova koji su u dometu izvorišnog čvora, i koji žele (ili mogu) da pošalju dalje primljeni
paket. Dakle, propagirajući od jednog mobilnog čvora do drugog, paket stiže na svoje odredište.

Zašto se ovo zove multihop komunikacija? Sećate li se prethodnog primera sa ruterima za podršku mobilnosti i mobilnim čvorovima? Tamo
je paket samo jednom mogao da skoči preko bežičnog linka – od rutera za podršku mobilnosti do odredišnog bežičnog čvora, pa smo takvu
arhitekturu zato zvali one-hop mreža. U ovom slučaju, međutim, imamo višestruke bežične skokove, tj. paket prelazi sa jednog mobilnog
čvora na drugi sve dok ne stigne na odredište. Odatle i ime – multihop. Broj bežičnih skokova nije ograničen. (Naravno, ovo u praksi nije
tačno, ali na to pitanje ćemo se vratiti kasnije, kada budemo razmatrali protokole za rutiranje).

U osnovi, ovo je način kako se realizuje multihop bežična komunikacija kroz privremeno formiranu Ad Hoc mrežu.

Rutiranje u Ad Hoc mrežama

Sada imamo dovoljno dobru osnovu da počnemo sa ispitivanjem ključnog pitanja vezanog za Ad Hoc mreže: protokole za rutiranje u
multihop Ad Hoc mrežama.

Kao što smo već rekli, efikasno rutiranje paketa jeste jedno od glavnih pitanja koje treba rešiti u Ad Hoc mrežnoj arhitekturi. U
konvencionalnim mrežama, za rutiranje se najčešće koriste algoritmi tipa distant vector ili link state. Oni podrazumevaju periodično
oglašavanje svih servera sa svrhom ažuriranja ruting tabela.

U nekim slučajevima ti algoritmi su adaptirani za upotrebu u Ad Hoc mrežama, pri čemu se svaki mobilni čvor tretira kao ruter. Dva primera
su Destination Sequenced Distance Vector i Wireless Routing Protocol. Prednost ovakvog pristupa je da je ruta do svakog mobilnog čvora u
mreži uvek poznata.

Međutim, ako bliže pogledamo, uvidećemo da su nedostaci adaptiranih algoritama mnogo značajniji od njihovih prednosti. Prvo, postoji
velika dodatna potrošnja propusnog opsega, pošto se periodične informacije o ažuriranju topologije mreže šalju čak i onda kada u mreži nije
bilo nikakvih promena. Zatim, baterije se brzo prazne pošto se čvorovi redovno bude za primanje i slanje ruting informacija koje nisu uvek
potrebne. Skalabilnost mreže je znatno smanjena. Zašto? Imamo veliku količinu informacija koja propagira kroz mrežu i koja je direktno
zavisna od broja postojećih čvorova u mreži. Što više čvorova imamo – veća količina ruting informacija se redovno emituje i mreža postaje
preopterećena. Zatim, postavlja se pitanje redundantnih ruta pošto imamo veliki broj rutera (setite se, svaki mobilni čvor ponaša se kao
ruter), pa je verovatnoća redundantnih ruta veoma velika. Na kraju, ovakvi sistemi često nisu u stanju da dovoljno brzo odgovore na
dinamičke promene mrežne topologije.

Ovo razmišljanje dovodi nas do klase protokola za rutiranje koji se zovu on-demand protokoli (tj. protokoli na zahtev). Generalna ideja je da
se ne koristi periodično oglašavanje ruta, pošto to preopterećuje mrežu. Umesto toga, ruta se otkriva samo kada je potrebna, tj. na zahtev. Na
taj način, mrežni saobraćaj je smanjen, ali prvo pitanje je koliko efikasan može biti takav algoritam za rutiranje? Koliko dugo traje proces
otkrivanja rute?

Opisaćemo tri algoritma za on-demand rutiranje u Ad Hoc mrežama:

 Dynamic Source Routing (DSR)
 Ad Hoc On-demand Distance Vector (AODV)
 Temporally Oriented Routing Algorithm (TORA)

Svaki od ovih algoritama prilazi problemu iz različitog ugla i koristi različite pretpostavke. Kao takvi, ovi algoritmi nisu univerzalno
primenljivi, pošto njihova upotreba zavisi od tipa Ad Hoc mreže.
Međutim, glavna karakteristika svih pomenutih algoritama je da oni nude poboljšanje performansi u poređenju sa klasičnim algoritmima. To
nije neočekivano, pošto su ovi algoritmi oslobođeni tereta klasičnih ruting algoritama koji su dizajnirani za stacionarna okruženja.

Veoma važno je napomenuti da algoritmi koje ćemo ovde predstavljati jesu samo uzorak iz velikog broja rešenja koja se još uvek razvijaju.
Više informacija možete pronaći na Web lokaciji Internet Engineering Task Force (IETF), na strani posvećenoj MANET GROUP. Takođe, u
poslednjem delu ove serije prikazaćemo originalni algoritam za multihop Ad Hoc mreže koji je razvijen na Elektrotehničkom fakultetu u
Beogradu.

Dynamic Source Routing

Prvi algoritam koji ćemo ovde razmotriti jeste Dynamic Source Routing [IETF2001b]. Ovaj algoritam je baziran na koceptu source routinga.
Šta to znači? Šta je source routing? Source routing je koncept rutiranja u kome pošiljalac obezbeđuje sekvencu čvorova kroz koje će paket
biti poslat. Ove sekvence čuvaju se u ruting kešu. Svaki čvor održava svoj ruting keš. Ruting keš možete zamisliti kao obične ruting tabele.

Šta je glavna karakteristika ovog prikaza? Ruta se određuje dinamički, i samo onda kada je potrebna. Nema periodičnog emitovanja rutera
vezano za ruting informacije. Umesto toga, proces rutiranja odvija se na sledeći način. Kada pošiljalac hoće da pošalje paket, on prvo
proverava svoj ruting keš. Ako u njemu postoji validan ulaz za odredište, paket se šalje koristeći sekvencu čvorova koja se nalazu u ruting
kešu. Setite se da se u ruting kešu čuva cela ruta, tj. skup svih čvorova kroz koje će paket putovati je već poznat. Ako u ruting kešu ne postoji
validna ruta do odredišta, pošiljalac inicira proces otkrivanja rute. Ovo je ključni pojam svih on-demand ruting algoritama. Ako čvor nema
validnu rutu do odredišta, neki vid otkrivanja rute (zavisno od algoritma) se aktivira, obično slanjem paketa route request (zahtev za rutom).
Ovaj paket zatim propagira kroz mrežu tražeći odredišni čvor.

Kao što smo već rekli, proces otkrivanja rute inicira se slanjem route request paketa (RREQ). Ovaj paket propagira kroz mrežu sve dok ne
stigne do odredišnog čvora. Pri tome, route request
uz put prikuplja adrese svih čvorova koje je
posetio. Ovde adrese se čuvaju u route recordu, 5
koji predstavlja deo route request paketa. Tačan 1 3 1,3,4
format paketa route request nije za sada toliko
1,3
1,3,4,5
bitan. Međutim, očigledno je da ovaj paket mora
da sadrži barem adresu pošiljaoca, odredišta, kao i
1
neko mesto za skladištenje adresa prikupljenih na
putu. Umesto da se bavimo preciznim formatom,
src 1,2 4
za sada ćemo pogledati narednu sliku, koja opisuje 1
rad ovog algoritma. 1,3,4 6
2
dst
Slika 6: Dynamic Source Routing

Komentar: Paket route request propagira kroz mrežu, prikupljajući pri tome adrese svih čvorova koje je posetio. Nakon što stigne do
odredišnog čvora, route request sadrži celu rutu izvorišnog do odredišnog čvora.

Zamislimo da čvor 1 želi da pošalje poruku čvoru 6. Pretpostavimo da u ruting kešu čvora 1 ne postoji validna ruta do čvora 6. Dakle, čvor 1
započinje proces otkrivanja rute tako što šalje route request pakete svim čvorovima u svom susedstvu. To su svi čvorovi koji su u njegovom
dometu. U ovom slučaju, paket route request šalje se čvorovima 2 i 3.

Kao što možete videti, u paketu route request nalazi se i adresa pošiljaoca. Zatim svaki čvor emituje RREQ dalje, svojim susedima.

Dakle, čvor 2 šalje RREQ čvoru 3, dok čvor 3 šalje RREQ čvoru 4. Ovde treba obratiti pažnju na dve stvari.

Prvo, zapazite da je jedna ruta između čvorova 1 i 3 poništena. Nema svrhe da čvor 1 šalje poruke čvoru 3 preko čvora 2, kada očigledno
može da šalje poruke direktno čvoru 3. Poništavanje rute je na slici prikazano različitom bojom.

Drugo, obratite pažnju kako RREQ prikuplja informacije o čvorovima kroz koje prolazi. Kao što možete videte, RREQ koji čvor 3 šalje
čvoru 4 sadrži adrese čvorova 1 i 3, tj. putanju kroz koju je RREQ prošao.

Sada čvor 4 prosleđuje RREQ čvorovima 5 i 6. RREQ raste, tj. route record se stalno ažurira i sada sadrži adrese čvorova 1, 3 i 4. Čvor 5
šalje RREQ čvoru 6, ali ova ruta se poništava zbog već pomenutih razloga. Proces otkrivanja rute je sada završen, pošto je paket RREQ
stigao do odredišnog čvora. U ovom slučaju, odredišni čvor
bio je čvor 6. Sada dolazi do druge faze procesa otkrivanja (1,3,4,6) 5 rute.
To je odgovor na rutu (route reply). 3
(1,3,4,6)
Dakle, ruta do čvora 6 je sada otkrivena. Međutim, čvor 1 1 koji
je i započeo ceo proces i dalje nema tu informaciju. Zato sada
mora da se aktivira inverzni proces. To je odgovor na rutu. 4 (1,3,4,6)
Paket route reply (RREP) generiše odredišni čvor sa ciljem da
obavesti izvorišni čvor da je ruta otkrivena.
2 6
Slika 7: Odgovor na rutu

Komentar: Čvor 6 mora da obavesti čvor 1 o validnog ruti koja je pronađena u postopku otkrivanja rute, i to se radi pomoću poruke
route reply.

Kada čvor 1 primi RREP, on zna da može da pošalje poruku čvoru 6 preko čvorova 3 i 4. Međutim, ovde ne smemo prenebregnuti jedno
veoma važno pitanje. Kada čvor 6 može da pošalje paket RREP čvoru 1? Prvo, on pretražuje svoj ruting keš. Ako postoji validna ruta do
čvora 1, RREP se šalje koristeći tu rutu. Međutim, šta se dešava ako u ruting kešu čvora 6 ne postoji aktivna ruta dok čvora 1. Postoje dve
mogućnosti.

Prvo, RREP se može vratiti upotrebom inverzne rute koja je došla u route recordu paketa RREQ. Međutim, tako uvodimo ozbiljna
ograničenja. Kvalitet prenosa tada mora biti isti u oba smera, drugim rečima, bežični linkovi moraju biti apsolutno simetrični. To nažalost
nije tako čest slučaj u mobilnim komunikacijama.

Drugi prilaz je bolji. U njemu odredišni čvor započinje proces otkrivanja rute tako što šalje RREQ sa ciljem da pronađe početni čvor (u ovom
slučaju čvor 1). Ovaj proces zove se inverzno otkrivanje rute. Ovaj mehanizam pruža podršku za asimetrične linkove, što je veoma dobra
strana ovog algoritma. Međutim, inverzno otkrivanje rute nije baš tako jednostavno. Šta se bi se desilo kada bi odredišni čvor samo poslao
paket RREQ sa ciljem da pronađe izvorišni čvor? Ovaj paket bi posle izvesnog vremena došao do izvorišnog čvora. Zatim bi izvorišni čvor
pokušao da pronađe odredišni čvor i da mu pošalje RREP, ali setimo se da on još uvek nema validnu rutu do odredišnog čvora. Dakle,
izvorišni čvor bi prateći ovu logiku morao ponovo da pošalje RREQ. Kao što možete videti, ulazimo u beskonačnu petlju. Mora se pronaći
neki način idenfitikacije prilikom slanja inverznog paketa RREQ. Najlakši metod je uključivanje originalnog paketa RREQ u RREP koji
odredišni čvor šalje izvorišnom. Ovaj metod zove se piggybacking. Kada izvorišni čvor dobije inverzni RREQ, on zna gde da pošalje RREP.

Sada ćemo razmotriti neke aspekte održavanja rute. U ovom algoritmu, održavanje je implementirano kroz mehanizam potvrđivanja
(acknowledgement) i paketa route error (greška na ruti, RERR). Potvrde mogu biti hop-to-hop ili end-to-end. Značenje je očigledno: hop-to-
hop podrazumeva proveru grešaka pri svakom hopu (tj. transferu preko bežičnog linka), dok end-to-end podrazumeva proveru grešaka samo
na strani predaje i prijema. Bliže ćemo pogledati kako funkcioniše hop-to-hop mehanizam potvrde. Proces je prikazan na sledećoj slici:

Slika 8: Hop-to-hop potvrda

Komentar: Svaki čvor čeka na potvrdu (ack). Ako se takva poruka ne primi nakon unapred definisanog vremenskog intervala
(timeout), čvor šalje poruku o greški. Na taj način se može utvrditi tačna lokacija linka koji ne funkcioniše.

Dakle, nakon primanja paketa, svaki čvor šalje potvrdu čvoru od koga je dobio paket. Ovaj čvor, sa druge strane, čeka na potvrdu. Ako se
potvrda primi, ništa se ne dešava. Međutim, ako se potvrda ne primi u definisanom vremenskom intervalu (timeout), čvor koji nije primio
potvrdu šalje paket route error (RERR) izvorišnom čvoru. RERR propagira do izvorišnog čvora, koji po njegovom primanju zna da neki
bežični link više nije funkcionalan. Štaviše, pošto je mehanizam potvrde implementiran hop-to-hop, izvorišni čvor čak tačno zna i koji link
ne radi, pa se ruting keš ažurira u skladu sa tom informacijom. Crveni krst na prethodnoj slici prikazuje upravo to – izvorišni čvor zna tačno
koji čvor je napravio problem. Zatim se može koristiti alternativna ruta (ako postoji), ili se može ponovo pokrenuti proces otkrivanja rute.

Šta se dešava pri upotrebi end-to-end kontrole? Sada ne postoji informacija na kom čvoru je došlo do prekida veze, pa izvorišni čvor može da
pretpostavi samo da je prekinut poslednji link, iako to u ovom primeru nije tako. Međutim, implementacija end-to-end kontrole je lakša i
uvodi manje dodatno opterećenje za mrežu.

Pošto je ovo jedan od najjednostavnijih ruting algoritama, moguće je predložiti mnogo poboljšanja. Ovde ćemo pomenuti samo jedno od
njih. To je rad u tzv. promiskuitetnom režimu prijema. Generalna ideja je da se ruting tabele ažuriraju i prilikom primanja i prenošenja
poruka, zahteva i odgovora koji su namenjeni nekom drugom čvoru, tj. kada se tekući čvor ponaša kao posrednik. Nedostatak ovog prilaza je
veća potrošnja i brže pražnjenje baterija.

Sada ćemo još jednom navesti dobre strane ovog algoritma:

 Veoma laka implementacija.
 Mogućnost rada sa asimetričnim linkovima.
 Pošto nema periodičnog oglašavanja rutera, propusti opseg i energija se štede.
 Nema dodatnog opterećenja mreže u slučajevima kada nema promene topologije.
 Protokol se lako modifikuje tako da podržava višestruke rute do istog odredišta. Na taj način nije potrebno inicirati proces otkrivanja
nove rute svaki put kada dođe do prestanka rada nekog čvora.

Sve ovo zvuči veoma lepo, međutim da li postoje i neki nedostaci ovakvog prilaza? Naravno da postoje, a ovde ćemo navesti samo neke od
njih.

Prvi nedostatak je prouzrokovan samom prirodom source routinga, a to je velika dodatna potrošnja propusnog opsega. Kao što znamo,
propusni opseg predstavlja jedan od najvažnijih resursa u modernim komunikacijama. Međutim, ovaj protokol ne vodi računa o tome.
Problem je što paket RREQ rapidno raste dok propagira kroz mrežu, pošto se u njemu čuvaju adrese svih čvorova kroz koje paket prolazi. To
sa druge strane uzrokuje pojavu potencijalno velikih paketa RREP. Sve to dovodi do dodatnog opterećenja. Zatim, pošto se uz poruku mora
poslati i cela ruta (tj. sekvenca čvorova), moguće je da će ruting informacija biti znatno veća od same korisne poruke. Međutim, to je cena
koju moramo platiti za jednostavnost ovog algoritma.

Drugi problem je skalabilnost, pošto je prihvatljiva veličina mreže ograničena. Koji je razlog tome? Što je mreža veća, više bežičnih transfera
je potrebno za komunikaciju, i na osnovu prethodnog zaključka sledi da će porast veličine poruka u jednom trenutku postati neprihvatljiv za
normalnu komunikaciju.
Na kraju možemo reći da je protokol DSR pogodan za Ad Hoc mreže sa umerenim brojem mobilnih čvorova koji se kreću umerenim
brzinama.

Ad Hoc On-Demand Distance Vector

Sada ćemo upoznati nešto drugačiji pristup Ad Hoc rutiranju [IETF2001a]. Drugi algoritam koji ćemo ovde prikazati zove se Ad Hoc On-
Demand Distance Vector (AODV). Nova ruta se otkriva na način koji je na prvi pogled sličan već opisanom. Izvorišni čvor emituje route
request paket svim susedima kada je potrebno da otkrije rutu do nekog odredišnog čvora. Nakon slanja tog paketa, on čeka na odgovor.
Međutim, svaka sličnost sa algoritmom DSR prestaje na ovom mestu. Stvari sada počinju da se donekle komplikuju.

Ključna stvar u ovom prilazu je paket route request. Ispitaćemo sada bliže njegovu strukturu. Paket route request sastoji se od nekoliko polja.
Detalje ćemo ostaviti za kasnije, a sada ćete se upoznati samo sa osnovnim idejama. Prvo ćemo se baviti poljem Sequence number (broj
sekvence). Šta je broj sekvence, i zašto se uvodi u ovaj algoritam?

Broj sekvence je broj koji svaki čvor generiše za sebe. To je jedinstveni broj. On se uvećava svaki put kada se u dometu tekućeg čvora desi
neka promena, tj. kada se nešto promeni u njegovom susedstvu (na primer, neki čvor ode izvan dometa ili prestane da funkcioniše iz bilo kog
razloga). Očigledno je da se ovaj broj koristi za otkrivanje takvih promena.

Svaki ulaz u ruting tabelu sadrži polje koje se zove Destination Sequence Number (odredišni broj sekvence – DSN). DSN se računa i pamti
za svaku rutu koju tekući čvor poznaje. Kako se koristi DSN? Pre svega, kada čvor želi da pošalje RREQ, on takođe šalje i poslednju poznatu
vrednost za DSN za traženu rutu (ili nulu, ako ruta do tada uopšte nije bila poznata). Zašto se to radi? Na ovo pitanje odgovorićemo nešto
kasnije, ali ćemo prvo morati da uvedemo još neke koncepte. Za sada je dovoljno da zapamtite da je DSN jedinstveni broj koji je povezan sa
svakom rutom koju čvor poznaje, kao i da se taj broj čuva u ruting tabeli. Dakle, minimalni format paketa RREQ je:

RREQ (scr, dest, srcSN, dstSN)

Kao što možete videti, paket RREQ više ne sadrži route record. Nema više informacija o čvorovima kroz koje on prolazi. Umesto toga,
RREQ se u osnovi sastoji samo od nekoliko polja: adresa izvorišnog čvora, izvorišni broj sekvence, adresa odredišnog čvora i odredišni broj
sekvence. Postoje još neka kontrolna polja koja za sada nisu interesantna.

Ovo je ključna razlika između protokola Ad Hoc On-demand Distance Vector i protokola Dynamic Source Routing. I već nailazimo na prvu
i možda najbitniju prednost ovakvog prilaza – pošto se u paketu RREQ ne čuva route record, sam paket je manji i propusni ospeg se čuva.
Međutim, koju cenu moramo da platimo za ovako elegantno rešenje? Uskoro ćemo se vratiti na ovo pitanje.

Umesto da RREQ nosi u sebi celokupnu rutu (unutar route recorda), dešava se sledeće: čvor (posrednik) koji primi paket RREQ dodaje u
svoju ruting tabelu inverznu rutu ka izvorišnom čvoru, tj. ka čvoru koji je započeo proces otkviranja rute slanjem RREQ. To možete videti na
slici 8.

Ovde naš tekući čvor prima RREQ od nekog izvorišnog čvora preko čvora n1. Sada će tekući čvor da napravi rutu do izvorišnog čvora, pošto
zna da ga može dostići preko čvora n1. Svaki put kada tekući čvor želi da pošalje poruku izvorišnom čvoru, dovoljno je da je prosledi čvoru
n1. Ovaj koncept je od najveće važnosti za predloženi tip rutiranja.

n1 RREQ
n2

n1
n2
route to src

Slika 9: Dodavanje inverzne rute ka izvorišnom čvoru

Komentar: Kada tekući čvor primi RREQ od izvorišnog čvora preko nekog posredničkog čvora, on ažurira svju ruting tabelu tako
što dodaje rutu ka izvorišnom čvoru.

Šta se dešava kada čvor primi paket RREP? Koristeći već objašnjeni mehanizam, tekući čvor će sada ustanoviti novu rutu ka odredišnom
čvoru kroz čvor n2. To je krajnje jednostavno: pošto je odredišni čvor mogao da pošalje paket RREP preko čvora n2 do tekućeg čvora, zašto
onda tekući čvor ne bi bio u stanju da pošalje poruku odredišnom čvoru preko čvora n2?

n1
RREP n2
route to src
 n1
n2
route to src route to dst

Slika 10: Dodavanje inverzne rute ka odredišnom čvoru

Komentar: Kada tekući čvor primi RREP od odredišnog čvora preko nekog posredničkog čvora, on ažurira ruting tabelu dodajući
rutu ka odredišnom čvoru.

Sada ćemo jasno naglasiti sledeću činjenicu: jedna od glavnih prednosti ovog algoritma jeste ta što se mrežna toplogija ažurira duž cele
putanje koju prelaze paketi RREQ i RREP, a ne samo u čvorovima koji su
izvorište i odredište. Svaki čvor kroz koji prođu paketi RREQ i RREP D 3
5
ažuriraće svoje tabele svežim rutama ka izvorišnom i odredišnom čvoru. S 1 6: 4,6

Umesto da u ruting tabeli čuvaju celu rutu, čvorovi pamte samo sledeći hop,
N 6: 3,4,6 4
2
tj. adresu suseda kome treba da proslede paket da bi on stigao na željeno 6: 6 6
odredište.
A 3
Obratite pažnju na sledeću sliku, koja opisuje razliku između algoritama Ad 5
O 1 6: 4
Hoc On-Demand Distance Vector i Dynamic Source Routing:
D 6: 3 4
2
V 6: 6 6
Slika 11: Poređenje prilaza rutiranju u algoritmima ADOV i DSR

Komentar: Glavna razlika je u tome što DSR čuva celu rutu (sekvencu), dok AODV pamti samo naredni hop.

Pretpostavimo da čvor 1 treba da pošalje poruku čvoru 6. U slučaju da se primenjuje algoritam Dynamic Source Routing, čvor 1 ima celu
rutu u svom ruting kešu. To možete videti na slici. Čvor 1 zna da, ako želi da pošalje poruku čvoru 6, poruka mora prođe kroz čvorove 3 i 4.
Izvorišni čvor dakle, zna tačnu rutu (tj. sekvencu čvorova) kroz koje paket mora da prođe kako bi stigao do odredišnog čvora. Dakle, čvor 1
šalje poruku čvoru 3, pošto je to prvi čvor u route recordu. Čvor 3 prima paket namenjen čvoru 6, i prosleđuje ga sledećem čvoru koji je
naveden u primljenom route recordu. Proces se dalje nastavlja na identičan način sve dok paket ne stigne do čvora 6.

Šta se dešava ako primenjujemo algoritam Ad Hoc On-demand Distance Vector? Ovde čvor 1 nema celu rutu do odredišnog čvora. Umesto
toga, kao što možete videti, on poznaje samo adresu sledećeg hopa, tj. čvora kome treba da prosledi poruku kako bi ona stigla do čvora 6. U
ovom slučaju, to je čvor 3. Dakle, čvor 1 šalje paket čvoru 3 i ne zna šta će ovaj dalje raditi sa njim. U tome leži sva lepota ovog prilaza.
Možete jasno videti da svaki čvor poznaje samo sledeći hop u celoj ruti, ali da i pored toga paket savršeno tačno dolazi do pravog odredišta:
čvor 1 prosleđuje paket čvoru 3, ovaj ga zatim prosleđuje čvoru 4, koji ga konačno isporučuje odredišnom čvoru 6. Jednostavno i elegantno,
zar ne?

Međutim, da bi ovaj jednostavni mehanizam mogao da funkcioniše, neke stvari se moraju obaviti u pozadini. Dakle, sada ćemo videti šta se
dešava kada RREQ stigne do čvora koji ima rutu do odredišnog čvora.

Prvo se vrši poređenje vrednosti DSN iz paketa RREQ i ruting tabele tekućeg čvora koji je taj paket primio. Ako je DSN iz RREQ veća, to
znači da ruta tekućeg čvora nije dovoljno sveža, i tada on šalje RREQ dalje, i ažurira vrednost DSN u svojoj ruting tabeli.

DSN=10 DSN=10

DSN(dst)=8
Slika 12: Prosleđivanje paketa RREQ

Komentar: Ako tekući čvor nema svežu rutu do odredišta, RREQ se ponovo šalje, a tekući čvor ažurira vrednost DSN u svojoj
ruting tabeli.

U suprotnom, čvor generiše RREP i šalje ga izvorišnom čvoru, zajedno sa izračunatom informacijom o otkrivenoj ruti. Obratite pažnju i na
ažuriranje vrednosti DSN. Nakon ovoga, koncept DSN bi trebao da bude jasan – on se koristi za odgovor na dinamičke promene mrežne
topologije.

Kako se paket RREP vraća početnom (izvorišnom) čvoru? Koristi se inverzna ruta koja je formirana od posrednih čvorova tokom
propagacije paketa RREQ. To možete videti na slici 14.

To je to. RREP je prosleđen izvorišnom čvoru, koji sada može bez problema da pošalje poruku odredišnom čvoru.

Sada ćemo razmotriti održavanje rute u ovom pristupu. Za svaku rutu u ruting tabeli, čvor održava listu susednih čvorova koji koriste tu rutu,
kako bi mogao da ih obavesti o eventualnom prekidu linka na toj ruti. Prekid linka se otkriva odsustvom hello poruka koju svaki čvor mora
da emituje nakon isteka unapred definisanog vremenskog intervala.
 DSN=10

DSN(dst)=12
DSN=12

DSN(dst)=12
Slika 13: Generisanje RREP

Komentar: Kada tekući čvor ima svežu rutu do odredišta, on generiše RREP i šalje ga izvorišnom čvoru, zajedno sa ažuriranom
vrednošću za DSN.

dst

src

Slika 14: Prosleđivanje paketa RREP

Komentar: RREP se prosleđuje preko inverzne rute koju su formirali posredni čvorovi tokom propagacije paketa RREQ.

Ovde srećemo dva nova termina: lista suseda i hello poruke. Pokušajte da ih zapamtite, jer ako preživite do poslednjeg dela ove serije,
videćete da su oni veoma bitni za realizaciju Ad Hoc mreže koja će biti opisana u poslednjem delu.

Sada relativno dobro poznajemo oba protokola – Ad Hoc On-demand Distance Vector i Dynamic Source Routing, pa ćemo pokušati da
uporedimo neke njihove aspekte. Koje su prednosti ADOV u odnosu na DSR?

 Prvo, to je znatno manje dodatno opterećenje mreže, jer su kontrolni paketi i poruke manji.
 Zatim, pri rutiranju se koriste samo dve adrese, umesto cele rute. Ovim je omogućena dobra skalabilnost, pošto veličina paketa ne zavisi
od prečnika mreže.
 AODV podržava multicasting.

Naravno, ništa nije savršeno, pa moramo odustati od nečega kako bismo dobili sve ove lepe stvari. Najvažniji nedostatak ovog pristupa je da
AODV radi samo sa simetričnim linkovima. Zatim, svaki čvor mora da emituje hello poruke čime se uvećava dodatno opterećenje mreže i
smanjuje mogućnost uštede energije u sleep režimu. Takođe, AODV ne nudi mogićnost višestrukih putanja do istog odredišta, tj. postoji
samo jedna ruta do svakog čvora. Dakle, kada neki čvor ode iz dometa ili prestane da funkcioniše, mora se otkriti nova ruta.

Temporally Oriented Routing Algorithm

Sada ćemo upoznati još jedan interesantan algoritam za Ad Hoc rutiranje. To je Temporally Oriented Routing Algorithm – TORA
[IETF2001c].

Ovaj algoritam predlaže potpuno drugačije i u neku ruku interesantno rešenje za problem rutiranja. On je zamišljen kao link-reversal
algoritam. Osnovna ideja je da se mrežna topolgija definiše upotrebom usmerenog acikličnog grafa (UAG). Čvorovi u mreži su prikazani kao
čvorovi grafa sa usmerenim granama koje predstavljaju linkove. Usmerenje linkova realizuje se dodelom visine svakom čvoru. Link je uvek
usmeren od čvora sa većom visinom ka čvoru sa manjom visinom, kao što možete videti na slici 15.
Slika 15: Usmereni ackilični graf

Komentar: Svakom čvoru dodeljuje se visina. Link je uvek usmeren od čvora sa većom visinom ka
čvoru sa manjom visinom.

Koja je generalna ideja ovog algoritma? Odredišni čvor treba da ima najmanju visinu u grafu. Ostalim čvorovima
dodeljuje se sve veća i veća visina i to u redosledu u kome raste njihovo rastojanje od odredišta. Paketi se zatim
mogu slati samo od “viših” ka “nižim” čvorovima, tj. samo “silaznim” linkovima.

Kako se formira usmereni aciklični graf? Njegovo formiranje počinje kada čvor koji nema silaznih linkova želi
da pošalje poruku odredišnom čvoru. Inicijalno, svi čvorovi u grafu imaju neodređenu visinu (posebna vrednost
NULL), sem odredišnog čvora. On ima visinu ZERO (nula), koja se smatra manjom i od NULL. Izvorišni čvor
zatim emituje paket Query (QRY) svojim susedima. Ovaj paket je donekle ekvivalentan paketu RREQ koji smo
već upoznali u prethodnim algoritmima. On propagira kroz mrežu i markira sve čvorove kroz koje prođe kao
“zainteresovane za otkrivanje rute”. To se radi postavljanjem route request flaga svakog čvora.

Kada paket QRY stigne do čvora koji ima barem jedan silazni link, taj čvor emituje paket Update (UPD). Paket
UPD se vraća unazad kroz mrežu i postavlja visine svih čvorova čiji je route request flag setovan, nakon čega ih
resetuje. Svaki dalji čvor dobiće veću visinu od prethodnog u putanji kojom propagira paket UPD. Kao što možete jasno videti na slici 16,
nakon toga postoji jedna silazna ruta između izvorišnog i odredišnog čvora.

dst
src

Slika 16: Formiranje UAG

Komentar: Formira se silazna putanja između izvorišnog i odredišnog čvora.

Važna stvar koju ovde treba primetiti jeste da predloženi mehanizam omogućava formiranje više silaznih putanja koje vode do istog
odredišta. Dakle, ovaj algoritam podržava multipath rutiranje, tj. može postojati više različitih ruta do svakog odredišnog čvora.

Šta se dešava u slučaju prekida linka? Kao što smo videli, ako se primenjuje algoritam Ad Hoc On-demand Distance Vector, ruta se mora
ponovo otkriti, tj. reinicira se proces otkrivanja rute.

Međutim, to ovde nije slučaj. Ako čvor nakon otkaza linka ima barem jednu silaznu putanju, ne vrši se nikakva akcija. U suprotnom, čvor
emituje paket UPD i oporavlja mrežni graf. Veoma je važno primetiti da je oporavak grafa proces koji se vrši u jednom prolazu, sem u
slučajevima particionisanja mreže, kada se graf podeli na dva podgrafa.

Koje su prednosti ovog pristupa u poređenju sa ostalima, koji su već opisani?

 Proces otkrivanja rute je veoma brz.
 Moguće je multipath rutiranje.
 Oporavak grafa je lokalizovan.
 Postoji podrška za multicast, pa je ovo Lightweight Adaptive Multicast algoritam.

Međutim, TORA ima jedan vrlo značajan nedostatak, koji ste možda i sami već primetili – ideja o formiranju grafa zahteva spoljašnji
sinhronizovani mehanizam za merenje vremena, kao što je Global Positioning System (GPS). Ovo komplikuje celu priču, pošto takav
mehanizam znatno poskupljuje celu konfiguraciju.

Drugi nedostatak je da mreži graf postaje sve manje optimalan kako vreme prolazi. Ovo se može rešiti slanjem refresh paketa koji osvežavaju
graf, ali to unosi dodatno opterećenje za mrežu.

Na kraju ćemo još samo reći da je TORA namenjena za velike mreže sa dosta čvorova sa gustom distribucijom. Drugim rečima, ako ništa
drugo ne rešava problem, opremite svaki čvor GPS prijemnikom i implementirajte TORA algoritam.

Pripremio: Nikola Milanović