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 mogu slobodno da se kreću iz jedne ćelije u drugu, i pri tome prelaze u nadležnost drugog rutera. 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 su u dometu rutera za podršku mobilnosti, dok čvor 3 nije u dometu.

MSR

MH2MH1

MH3

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. 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 mobilnosti MSR, i dva mobilna čvora MH1 i MH2. Šta se dešava kada jedan od fiksnih čvorova želi da pošalje poruku mobilnom čvoru?

MH2

MSRFH1

FH2FH4

FH3

MH1

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 č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 skrivanja mobilnosti od fiksnih čvorova.

MH2

MSRFH1

FH2FH4

FH3

MH1

Slika 4: Indirektni protokoli 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, koji predstavlja deo route request paketa. Tačan format paketa route request nije za sada toliko bitan. Međutim, očigledno je da ovaj paket mora da sadrži barem adresu pošiljaoca, odredišta, kao i neko mesto za skladištenje adresa prikupljenih na putu. Umesto da se bavimo preciznim formatom, za sada ćemo pogledati narednu sliku, koja opisuje rad ovog algoritma.

11

22

33

44

55

66

src

dst

1

1

1,3

1,2

1,3,4

1,3,4

1,3,4,5

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 rute. To je odgovor na rutu (route reply). Dakle, ruta do čvora 6 je sada otkrivena. Međutim, čvor 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. Paket route reply (RREP) generiše odredišni čvor sa ciljem da obavesti izvorišni čvor da je ruta otkrivena.

11

22

33

44

55

66

(1,3,4,6)

(1,3,4,6)(1,3,4,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:

errerr ?

ack ack

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.

RREQn2

n1

route to srcn2

n1

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?

RREP

route to src

n2n1

route to src route to dst

n2n1

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 ažuriraće svoje tabele svežim rutama ka izvorišnom i odredišnom čvoru. Umesto da u ruting tabeli čuvaju celu rutu, čvorovi pamte samo sledeći hop, tj. adresu suseda kome treba da proslede paket da bi on stigao na željeno odredište. Obratite pažnju na sledeću sliku, koja opisuje razliku između algoritama Ad Hoc On-Demand Distance Vector i Dynamic Source Routing:

11

22

33

44

55

66

11

22

33

44

55

66

6: 3,4,6

6: 4,6

6: 6

6: 3

6: 4

6: 6

DSN

AODV

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(dst)=8

DSN=10 DSN=10

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(dst)=12

DSN=10

DSN(dst)=12

DSN=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.

src

dst

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.

dstsrc

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ć

Interfejsni i rutirajući modul Sada ćemo preći na interfejsni i rutirajući modul (IFRM), tj. na hardver na kome se izvršava predloženi protokol. Da bi se obezbedila razmena informacija između mobilnih komponenti sistema, potrebno je dizajnirati brzu i pouzdanu Ad Hoc mrežu, koja je sposobna da se brzo adaptira na promene topologije. Ako uzmemo u obzir domet Bluetooth modula (10 do 100 metara), postaje jasno da ova mreža mora biti realizovana kao multihop Ad Hoc mreža, tj. svaki čvor mora biti sposoban za prosleđivanje poruka. Iz tih razloga potrebno je implementirati adekvatan ruting protokol. Bilo bi idealno kada bi se ovaj protokol mogao implementirati na baseband kontroleru Bluetooth modula, ali pošto za sada ne postoji direktan programski pristup baseband mikroprocesoru, ruting protokol je implementiran u odvojenom hardverskom modulu koji komunicira sa Bluetooth modulom preko serijske (UART) veze, na nivou Host Controller Interface. Osnovne uloge IFRM su: 1. formiranje bežične multihop Ad Hoc mreže 2. održavanje veze 3. rutiranje paketa i otkrivanje rute 4. obezbeđivanje transparentnog interfejsa između Ad Hoc mreže i

bilo kog serijskog (RS-232) uređaja, tako da uređaj ima iluziju da komunicira sa ostatkom sistema koristeći kablovsku vezu

5. obezbeđivanje funkcije PDA Srž IFRM predstavlja Microchip PIC17C756A mikrokontroler, koji je izabran zbog brze RISC arhitekture i zato što ima sve potrebne periferije integrisane na čipu – dva USART modula, WatchDog tajmer, mogućnost In-Circuit serijskog programiranja i 32Kreči ROM memorije na čipu. Zbog čuvanja ruting tabela i FIFO bafera, dodato je još 16 KB eksterne RAM memorije u vidu dva statička 6264 RAM modula.

Takođe, na ploči se nalaze i 32Kreči eksterne FLASH ROM memorije, koja služi da olakša razvoj softvera. U finalnom proizvodu, ova memorija neće biti potrebna pošto će se ceo program nalaziti u ROM memoriji koja se nalazi na čipu.

PIC 17C756Amicrocontoller

CON4serial port 2

External RAM16 KB

(8 Kwords)

External FLASHROM64 KB

(32 Kwords)

CON3serial port 1

to Bluetoothmodule

to host(sensor, PC, etc.)

signalingLEDs

CON2 & CON5I/O ports

to keyboard(optional)

to LCD(optional)

CON6ICSP

Slika 41: Arhitektura IFRM IFRM komunicira sa ostatkom sistema preko dva serijska porta (CON3 i CON4). CON4 se koristi za komunikaciju sa Bluetooth modulom, dok se CON3 koristi za komunikaciju sa hostom (tj. bilo kojim uređajem koji ima RS-232 port, na primer senzori, PC, DSPS…). Oba serijska porta podržavaju hardversku kontrolu toka, imaju RS-232 MAX3225 drajvere, što omogućava brzinu prenosa do 1Mbps. IFRM takođe poseduje dva 8-bitna I/O porta opšte namene (CON2 i CON5) koji se koriste za podešavanje konfiguracije (pomoću džampera), ili za povezivanje LCD ili tastature (kada radi kao PDA). Na IFRM implementiran je modifikovani AODV protokol, uz sledeća ograničenja: 1. Veličina ruting tabele ograničena je na 79 ulaza. 2. Komunikacija u mreži je server-centrična (zvezdasta topologija sa

serverom u centru), tj. komunikacija je moguća od servera ka bilo kom čvoru (senzor, PDA), i od bilo kog čvora ka serveru, ali end-

to-end komunikacija između ostalih čvorova nije moguća (sem u slučaju prosleđivanja paketa).

Razlog za ovo ograničenje jeste želja da se čvorovima koji su priključeni na IFRM obezbedi transparentna mreža. Tako IFRM uvek prosleđuje na server podatke dobijene od čvora. Na taj način eliminiše se potreba za izdvajanem odredišne adrese iz primljenog niza bajtova – podaci se uvek šalju na server, kome je dodeljena jedinstvena adresa sa svim nulama. Zbog toga, na IFRM je moguće povezati bilo koji serijski uređaj, bez obzira na protokol koji koristi. Serijski niz bajtova koji se prima deli se u pakete; svakom paktu se dodeljuje odredišna adresa sve nule i on se šalje preko Ad Hoc mreže na server, koji na višem nivou odlučuje kako da interpretira primljeni niz bajtova. U suprotnom smeru (server-ka-mobilnom čvoru), odredišna adrese određuje se implicitno u softveru, bez ulaska u sadržaj prenošenog niza bajtova. Važno je napomenuti da ovakva šema adresiranja ne predstavlja ograničenje samog protokola – svaki čvor čuva adrese drugih čvorova u svojoj ruting tabeli, jer je to potrebno za komunikaciju server-mobilni čvor.

MH – mobile host (e.g. sensor)

MH

SERVER

MHMH

MHMH

MH

MH

MH

MH

MH

MH

MH

MH

data flow

Slika 42: Zvezdasta mrežna topologija Komentar: Komunikacija u mreži je server-centrična, kako bi se

obezbedila transparentnost mreže svim mobilnim čvorovima.

S obzirom da server može da pošalje poruku bilo kom čvoru, posrednički čvorovi moraju da znaju rutu do tog čvora kako bi mogli da ispravno proslede paket. Jedini razlog za kreiranje ovog ograničenja jeste da rutiranje u smeru mobilni čvor-server bude nezavisno od podataka koji se šalju, tj. kako bi se pojednostavila šema adresiranja. U slučaju potrebe, protokol se lako može rekonfigurisati da podrži end-to-end komunikaciju između bilo koja dva čvora koristeći neku složeniju šemu adresiranja (na primer TCP/IP). Preostala ograničenja su: 1. Izostavljena je end-to-end kontrola toka (postoji samo point-to-

point kontrola na nivou Bluetooth baseband čipa) 2. CRC provera i retransmisija nisu implementirani (pretpostavlja se

da Bluetooth obezbeđuje pouzdan prenos) 3. Sekvenca paketa se ne proverava (pretpostavlja se da paketi stižu u

originalnom redosledu) 4. Ograničenja nastala zbog činjenica da se korišćeni Bluetooth

moduli ne slažu sa Bluetooth V1.1 specifikacijom

Razlog za poslednje ograničenje jeste činjenica da su isporučeni Bluetooth moduli bili u ranoj razvojnoj fazi i da ne poštuju do kraja Bluetooth V1.1 specifikaciju. Najvažnije od svega, ovi moduli ne podržavaju point-to-multipoint komunikaciju, što je osnovno za ovaj projekat. Zato je prilikom dizajna rutera velika pažnja poklonjena obezbeđivanju da on postane potpuno operativan u trenutku kada se na tržištu pojave Bluetooth moduli koji u potpunosti podržavaju specifikaciju. Pošto nije bilo moguće testirati point-to-multipoint mogućnosti Bluetooth modula, uvedene su sledeće pretpostavke:

1. Tokom full-duplex komunikacije nema implicitne promene master-slave.

2. Moguće je vršiti funkcije inquiry i paging novih čvorova tokom aktivne konekcije bez interferencije tekućeg prenosa.

3. Samo master pikoneta može da emituje u tom pikonetu. 4. Čvor može transparentno da bude član više pikoneta (scatternet), tj.

Bluetooth baseband kontroler može da vrši transparentno vremensko multipleksiranje.

5. Moguća je komunikacija sa više od 7 čvorova u jednom pikonetu, a parkiranje se obavlja transparentno od strane baseband kontrolera.

Zbog činjenice da nekoliko HCI komandi koje su veoma važne za projekat (npr. Link Policy Commands) još uvek nisu bile implementirane na Bluetooth modulima, i zbog otkrivanih grešaka u Bluetooth firmwareu, implementirano je više workaround tehnika. Na primer, emitovanje dva uzastopna paketa dovodi do reseta Bluetooth modula. Zato je nakon svakog emitovanog paketa ubacivan jedan lažni point-to-point paket, kako bi se izbegao reset. Takođe, tokom maksimalne brzine full-duplex prenosa, paketi ili delovi paketa počinju da nestaju, pa je uvedena resinhronizacija čim se otkrije da neki bajtovi nedostaju.

Ad-hocnetworkHOST

(e.g. sensor, PC, etc.)

IFRM

BLUETOOTHMODULERouting

Slika 43: Mobilni čvor Komentar: Mobilni čvor je priključen na IFRM preko serijskog

porta. Na drugoj strani IFRM nalazi se Bluetooth modul. Dakle, dovoljno je uključiti čvor u IFRM i on odmah postaje raspoloživ čvor u Ad Hoc mreži.

Na slici 43 prikazana je veza između IFRM i mobilnog čvora.

Sada ćemo razmotriti serversku stranu ruting protokola. Implementacija ruting protokola na severu razlikuje se od implementacije na IFRM, pošto na strani servera ne postoji modul za rutiranje. Rutiranje na serveru vrši softver. Potreban je specijalan mehanizam za određivanje odredišta paketa, pošto se adrese ne određuju na osnovu podataka. Takođe, primljeni paketi se ne prosleđuju RS-232 uređaju (kao u slučaju IFRM); umesto toga, oni se prosleđuju ekspertskom sistemu. Zato je potrebno obezbediti komunikaciju između ekspertskog sistema i Ad Hoc mreže. Izabrani mehanizam su TCP portovi. Za svaki mobilni čvor u mreži na serveru se otvara odgovarajući TCP port, počevši od porta 10000. U mreži sa tri čvora, na serveru bi postojala tri porta - 10001 za prvi čvor, 10002 za drugi i 10003 za treći čvor. Celokupna komunikacija sa mobilnim čvorovima obavlje se preko TCP/IP konekcija na ovim portovima.

SERVER (PC)

Ad-hocnetworkBLUETOOTH

MODULEExpert system

Slika 44: Konekcija na strani servera Komentar: Glavna razlika u odnosu na mobilni čvor je što na

strani servera ne postoji IFRM. Bluetooth modul je povezan direktno sa serverom, a podaci se razmenjuju preko TCP portova.

Na primer, tok podataka na konekciji server:10003 preusmerava se preko Ad Hoc mreže do mobilnog čvora broj 3. Mapiranje između brojeva portova i hardverskih adresa Bluetooth modula je statičko i vrši se putem konfiguracione datoteke.

Da bi bilo koja aplikacija komunicirala sa bilo kojim mobilnim čvorom u mreži, dovoljno je da otvori TCP konekciju na odgovarajućem portu na serveru, i sva dalja komunikacija sa mobilnim čvorom vrši se transparentno, preko Ad Hoc mreže. Sada ćemo razmotriti rad ličnog digitalnog asistenta (PDA). Uloga PDA je da stručnjaki koji nadzire proces obezbedi mobilnost, tako je on/ona slobodan da vrši druge aktivnosti pored običnog nadgledanja ispred servera. PDA može da prima dva tipa poruka: 1. Neki senzori su prijavili nepravilne podatke, ali je ekspertski

sistem uspeo da stabilizuje sistem. Zahteva se potvrda od stručnjaka.

2. Neki senzori su prijavili nepravilne podatke i ekspertski sistem nije uspeo da stabilizuje sistem. Zahteva se daljinska komanda i što brže pristustvo stručnjaka na licu mesta.

Shodno tome, sa PDA se takođe mogu poslati dva tipa poruka: 1. Potvrda primljenog upozorenja. 2. Komanda koja inicira neku akciju u sistemu, zasnovanu na

primljenim podacima. PDA je u potpunosti realizovan pomoću IFRM. On se od senzora razlikuje po tome što se na portu CON2 nalazi tastatura od 16 tastera, a na portu CON5 je LCD ekran. Sve preostale razlike su softverske – pored ruting protokola, postoji deo koji primljene pakete šalje na ekran (umesto na serijski port), a ulazni podaci se primaju sa tastature umesto sa senzora. U ovoj fazi projekta, interno baterijsko napajanje nije projektovano. Sistem za digitalnu obradu signala Sistem za digitalnu obradu signala (DSPS) realizovan je u hardveru, kao primer jednog tipa uređaja koji se može povezati u realizovano okruženje. DSPS je zasnovan na Texas Instruments TMS320LF2407 procesoru za digitalnu obradu signala, koji pripada familiji čipova za upravljanje motorima i obradu signala. Glavna uloga ovog sistema jeste prikupljanje podataka od različitih periferija, njihova obrada u

realnom vremenu i prenošenje na server preko interfejsnog modula i Ad Hoc mreže. Na serveru je raspoloživa dodatna obrada i napredno praćenje. Kod programa nalazi se u internom FLASH EEPROM-u. On se koristi za dekodiranje instrukcija primljenih sa IFRM i analizu spektra analognog ulaza pomoću FFT (brza Furijeova transformacija) [Popovic99].

TITMS320LF2407

ResistorCapacitorDiodeMatrix

CON8:AnalogInputs

CON6:EventManagerA

CON8:Address, Data &Control DSP Bus Signaling

LED

MAX3225 PCA82C250

CON2:RS232

CON3:CAN BUS

CON 9:SynchronousSerial Link

LCD (optional)

PWM

Capture

Timer

SPIInterface

SCIInterface

CAN BUSInterface

Slika 45: Arhitektura DSPS Glavni delovi sistema za obradu signala su: • Texas Instruments DSP TMS320LF2407 • RS232 drajver (MAX3225cpp) • Controller Area Network drajver (PHILIPS PCA82C250) • matrica otpornika-kondenzatora-dioda • signalni LED • razni konektori koji omogućavaju povezivanje DPS sa okruženjem:

DSP BUS ◊ ◊ ◊ ◊

SPI (sinhroni serijski interfejs) za LCD SCI (serijski interfejs) za RS232 CAN interfejs, za industrijsku podršku

Event Manager A ◊ MAX3225cpp je odgovoran za opsluživanje standardne RS232 veze (preko null modem kabla) sa PC računarom, ili sa interfejsnim modulom (integracija u Bluetooth okruženje). Industrijska podrška obezbeđena je upotrebom Philips PCA82C250 CAN drajvera. DSP može da komunicira sa spoljnim svetom i pomoću sinhrone serijske veze (SPI interfejs). Ona se može koristiti za buduće nadogradnje kako bi se na DSP prikačio LCD radi on-line praćenja. Analogni ulazi AD konvertora zaštićeni su diodnom matricom, a postoji i adekvatna otporničko-kondenzatorska mreža koja obezbeđuje konverziju nivoa i filtriranje. Na slici 46 možete videti kako se DSPS povezuje u sistem pomoću IFRM.

DigitalSignal

ProcessingModule

Analog Input

Slika 46: Povezivanje DSPS i IFRM Programski kod koji se nalazi u FLASH memoriji ima dve funkcije. On radi kao interpreter poruka koji analizira podatke koji dolaze sa interfejsnog modula. Kada se komanda (poruka) dekoduje, počinje njeno izvršavanje. Format poslatih i primljenih poruka je isti, i podržava IEEE SCADA specifikaciju. Druga funkcija programa je semplovanje ulaznog analognog napona, kreiranje paketa odbiraka i računanje spektra pomoću FFT. Izračunati spektar se smešta u RAM memoriju na čipu i konstantno se osvežava. Kada preko IFRM pristigne zahtev za spektrom od servera, informacija se šalje iz memorije preko Ad Hoc mreže.

Softverska platforma Softverski deo projekta objedinjuje sve komponente sistema. Program (nazvan Shell) služi za akviciziju podataka, donošenje odluka, obradu signala, alarmiranje, praćenje trenutnog stanja sistema i administraciju baze podataka. Osnovna uloga softvera jeste akvizicija podataka sa senzora i mernih uređaja koji su povezani sa serverom preko Ad Hoc mreže. Kako bi se ova funkcija obavljala sa maksimalnom efikasnošću, raspoloživo je detaljno podešavanje konfiguracije senzora. Moguće je uneti sve relevantne parametre vezane za identifikaciju i analizu podataka.

Slika 47: Shell interfejs za akviziciju i obradu podataka Shell omogućava praćenje izmerenih vrednosti u realnom vremenu, a podaci mogu biti prikazani i u grafičkoj formi. Na taj način se lako može utvrditi vremenska zavisnost između različitih merenja. Svi primljeni podaci smeštaju se u bazu podataka, pa je moguće izvršiti sve analize i unazad u vremenu. Jedan deo sistema nudi pregledanje i izvršavanje upita nad bazom, pa se može uraditi detaljna analiza za bilo koji trenutak u vremenu. Bazi podataka je takođe moguće pristupiti i putem Interneta. Ova osobina otvara niz novih mogućnosti, koje ćemo razmotriti nešto kasnije.

Softver je razvijen pomoću MS Visual Studia i Visual C++. Korišćenje su mogućnosti Microsoft Foundation Classes [Leinecker2000], [Microsoft2001]. Interfejs programa je jednostavan za upotrebu, a veoma komplikovane konfiguracije senzora mogu se postaviti prilično brzo. Testiranje i aktiviranje konfiguracije vrši se jednostavnim pritiskom na taster miša. Bluetooth standard i projektovana Ad Hoc mreža obezbeđuju transparentni sistem za komunikaciju između računara, senzora i drugih mernih uređaja. Otvaranjem odgovarajućeg TCP porta, kreira se socket preko koga se vrši dvosmerna komunikacija sa uređajem. Komunikacija preko socketa koristi TCP, a finalna konekcija između senzora i računara poštuje IEEE SCADA specifikaciju.

Slika 48: Okvir za dijalog New Sensor Setup (konfigurisanje novog senzora) Dodavanje novih uređaja u sistem je veoma jednostavno. Pritiskom na jedno dugme korisnik otvara okvir za dijalog Sensor Setup (slika 48) u kome može da unese tip i ime senzora, adresu i očekivani opseg izmerenih vrednosti. Nakon toga, sistem je spreman da prihvati očitavanja sa novog uređaja.

Ceo sistem je lako proširiv. Pored opisane procedure, dovoljno je uneti novi uređaj u Ad Hoc mrežu, i on će automatski postati dostupan. Dakle, instalacija novog uređaja (uključujući i fizičko postavljanje na željeno mesto) može da traje manje od minuta. Nakon što je sistem ispravno konfigurisan, proces čitanja i beleženja podataka može da počne. Nakon toga moguće je pratiti tekuće vrednosti na grafikonu, ako je potrebno odrediti neku vrstu vremenske zavisnosti, ili u jednostavnom prikazu numeričkih vrednosti.

Slika 49: Prikaz podataka sa senzora Takođe je moguće analizirati i istoriju rada sistema. Pomoću jednostavnih upita, moguće je doviti podatke za bilo koji željeni trenutak u prošlosti. Ova informacija može biti prikazana na grafikonu ili numerički, a prikaz se čak može preusmeriti i na Web stranu. Ako se izabere grafički prikaz, pojavljuje se klizač pomoću koga se korisnik kreće duž vremenske ose. Prikaz podataka u realnom vremenu osvežva se nakon svakog novog primljenog podataka. To znači da je moguće prećenje vremenske zavisnosti u realnom vremenu, sa nepravilnostima koje su jasno označene. Kada vrednost na grafikonu uđe u zabranjenu zonu, aktivira se alarm.

Slika 50: Analiza spektra primljena sa DSPS Baza podataka u kojoj se smeštaju vreme i pročitani podaci sa svakog senzora, realizovana je koristeći MySQL Server. Nakon kreiranja, baza je nezavisna od aplikacije i platforme, i moguće joj je lako pristupiti preko Interneta. Administracija baze vrši se pomoću ODBC sa standardnim klasama i MFC kolekcije. Na taj način sistem je fleksibilan i nezavistan od DBMS koji se koristi. U slučaju prelaska na neki drugi SQL server, sistem će kreirati novu bazu i tabele i nastaviti da radi kao da se ništa nije desilo. Podaci sa senzora se čuvaju u bazi podataka, ali se istovremeno prosleđuju i ekspertskom sistemu na analizu. Zbog ograničenog vremena, a delom i zbog želje da se očuva univerzalna primenljivost celog sistema, projektovan je jednostavan ekspertski sistem za praćenje (kontrolu) sa bazom znanja od nekoliko desetina pravila. Primenjen je algoritam direktnog ulančavanja [Velasevic96]. Na osnovu preduslova (podaci sa senzora) i pravila iz baze znanja, ekspertski sistem donosi odluku da li da pokuša sa autonomnim rešavanjem problema ili da alarmira nadležnu osobu koja nosi PDA. Ovo je samo jednostavan primer. U zavisnosti od stvarne primene, postojeći ekspertski sistem sa svojom bazom znanja bi lako mogao da se integriše u ovaj softver.

Sistemskoj bazi podataka može se pristupiti iz Web klijenta, sa ciljem da se skrati vreme odgovora u kritičnim situacijama. U slučaju uzbune, može se konsultovati stručnjak koji nije na terenu i/ili ne nosi PDA. Sva očitavanja su trenutno raspoloživa, a da bi im se pristupilo dovoljno je imati računar koji ima vezu ka Internetu. Kao što je već rečeno, baza podataka je realizovana upotrebom MySQL Servera. Ovo je besplatan proizvod sa velikom korisničkom populacijom i odličnom dokumentacijom, što su i bili razlozi za izbor ovog sistema za upravljanje bazom podataka (DBMS). Međutim, veliko ograničenje tekuće verzije bilo je to što ne podržava transakcije. Zato se za veće radno optrećenje preporučuje neki drugi DBMS (na primer Microsoft SQL Server ili Oracle). Za komunikaciju sa bazom podataka preko Interneta korišćeni su PHP 4.0.4 i Apache Web Server 1.3.14. Oba proizvoda su besplatna, pouzdana i veoma dobro dokumentovana. PHP se pokazao kao veoma koristan pošto ima ugrađenu podršku za rad sa MySQL bazama podataka [Bakken2001]. Sistem koristi standardnu three-tier arhitekturu za pristup bazi podataka: Web klijent, skript na strani servera i DBMS, što se može videti na slici 51.

web clientserver

PHP script

http request

DBMSsql query

recordset

http reply

Slika 51: Three-tier arhitektura za komunikaciju sa bazom podataka Klijent formuliše upit nad bazom i šalje ga Web serveru u obliku HTTP zahteva. Na serveru, PHP skript prihvata ovaj zahtev i obrađuje ga tako što kreira SQL upit. Ovaj upit se zatim prosleđuje DBMS koji pristupa bazi podataka i uzima slogove. Skript prima skup slogova

(recordset) kao rezultat, formira HTTP odgovor, prosleđuje ga Web serveru koji ga zatim šalje klijentu. Na taj način se vrši dinamičko kreiranja strana na strani klijenta. Bazi podataka može se pristupiti samo uz ispravno korisničko ime i šifru. Neautorizovani korisnici ne mogu da pristupe potencijalno poverljivim podacima (bolnice, elektrane…). Korisnik koji se uspešno prijavi na sistem bira senzore kojima želi da pristupi, a zatim unosi jednostavan upit koji se kasnije pretvara u SQL upit. Moguće je vršiti pretraživanje po vremenu ili vrednosti.

Slika 52: Pristup sistemskoj bazi podataka iz Web klijenta. U zavisnosti od aplikacije, moguće je implementirati bilo koju vrstu pretraživanja (više tabela i atributa i slično). Planirano je da se ovaj jednostavni sistem proširi kako bi se omogućila administracija konfiguracije i rada senzora preko Interneta. Ideja je da se neki delovi sistema kontrolišu preko Web klijenta, tj. da se postigne izvestan stepen Internet automatizacije. Na taj način bi se moglo implementirati potpuno daljinsko upravljanje čime bi se

eliminisalo fizičko prisustvo pored servera na kome se izvršava softver za akviziciju podataka. Testiranje i integracija Testiranje je izvršeno u tri faze: •

• •

odvojeno testiranje komponenti (protokol, modul za rutiranje, softver za akviziciju podataka, baza podataka, dsp senzor) integracija komponenti finalna integracija sistema

Protokol za Ad Hoc multihop rutiranje testiran je pomoću simulatora koji se specijalno za tu svrhu napisan u Javi. Što se tiče tehničke strane samog simulatora, testiran je sa više od 300 mobilnih čvorova (niti). Nisu uočeni nikakvi problemi. Broj čvorova je ograničen brzinom procesora, zbog principa deljenja procesorskog vremena između niti. Što se tiče IFRM i DSPS, prvo su testirani PCB dizajn i napajanje. Zatim su napisani test programi za proveru RS232, signalnih LED-ova i eksterne RAM memorija (IFRM). Nakon ispravljanja nekoliko problema sa WatchDog tajmerom, svi testovi su prošli bez problema. Nakon toga, napisane su adekvatne rutine za komunikaciju sa tastaturom i LCD (za IFRM). Dok su trajali ovi testovi, napisana je serverska verzija ruting protokola koja je testirana u point-to-point vezi između dva računara. Zatim je na isti način testiran i hardverski modul (sa implementiranim ruting protokolom). U svrhu testiranja Shella (softvera za akviziciju podataka), projektovana je simulacija senzora i PDA. Program je simulirao spoljašnje uređaje tako što se povezivao na nekoliko portova i čekao da bude prozvan od strane Shella. Tokom ovih testova, pored otkrivanja i ispravljanja dosta manjih grešaka, postalo je jasno da Windowsov tajmer nije dovoljno precizan kako bi se koristio za merenje ciklusa očitavanja sa senzora. Zato je odlučeno da se takt uzima direktno sa procesora.

Povezivanje sa Internetom testirano je u laboratoriji sa nekoliko desetina računara. Serveru je dodeljena postojeća IP adresa, a prilikom daljih pristupa nije bilo problema. Zatim su Apache Web server i MySQL Server ostavljeni da rade nekoliko dana, i ponovo nisu zabeleženi nikakvi problemi. U prvoj fazi integracije, povezani su softver za akviziciju podataka (Shell) i baza podataka. Nakon toga dodata je mogućnost pristupa bazi podataka putem Interneta. Na kraju je testirana i komunikacija između Shella i interfejsnog modula. Napisan je drajver u ANSI C-u koji je omogućio povezivanje Bluetooth modula sa serverom bez modifikacija Shella. Tako je Bluetooth zauzeo jedan port na serveru i čekao podatke. Drugi Bluetooth modul je povezan sa drugim računarom na isti način. U komunikaciji između modula na serveru i drugog modula nije bilo problema. Nakon toga je na mesto drugog računara postavljen dsp senzor i prenos test podataka je bio uspešan. Na kraju je izvršen test kompletnog sistema. Zbog problema koji su već objašnjeni (Bluetooth moduli koji ne podržavaju do kraja specifikaciju V1.1) modul za rutiranje nije mogao da bude testiran u realnoj situaciji. Međutim, pribegnuto je kompromisnom rešenju, pa je za testiranje celog sistema upotrebljen simulator (koji je originalno bio napisan za testiranje protokola). Simulator je modifikovan tako da prihvati jedan modul za rutiranje na serijskom portu i prepozna ga kao jedan od čvorova u mreži. Na taj način kreirana je Ad Hoc mreža sa 300 čvorova, od kojih je jedan bio IFRM koji se nalazio na serijskom portu. Ovaj test ne može biti ekvivalentan testu u realnim radnim uslovima, ali predstavlja najbolju alternativu do koje se moglo doći u ovim uslovima. Korak napred Cilj projekta bio je da ukaže na mogućnost razvoja bežičnih komunikacija u smeru integracije različitih elektronskih uređaja u

jedinstvenu informacionu mrežu (zasnovanu na Bluetooth okruženju) sa univerzalnim protokolom za razmenu poruka. Međutim, projektovana hardversko/softverska platforma nudi dobru osnovu koja se može koristiti u kritičnim sistemima (kao što su zdravstvene ustanove ili industrija), uz neke modifikacije. Veoma važno je naglasiti otvorenost sistema: bilo koji uređaj koji ima mogućnost serijske komunikacije može se povezati sa projektovanim modulom za rutiranje. Dakle, moguće je kreirati proizvoljne Ad Hoc mreže, a ne samo senzorske mreže za akviziciju podataka. To je demonstrirano projektovanjem ličnog digitalnog asistenta koji komunicira sa serverom preko IFRM. Sledeći korak u ovoj oblasti predstavlja razvoj mikrokontrolera koji će podržavati jezik Java, tj. uvođenje JVM čipova. To će omogućiti izvršavanje protokola za rutiranje na širokom opsegu različitih mobilnih platformi (mobilni telefoni, pda…). Takođe, svakom čvoru se mogu dodati i mogućnosti Web servera. Moguće je predložiti mnoga unapređenja realizovanog sistema: protokol za rutiranje zahteva detaljno proučavanje (analitičko i pomoću simulacija) kako bi se uočili i otklonili nedostaci; interfejsni i rutirajući modul tek treba da se pokaže u realnoj primeni (sa pojavom point-to-multipoint Bluetooth modula); potrebno je uložiti dodatni napor kako bi se softver učinio još otvorenijim i fleksibilnijim; takođe, neophodno je razviti nekoliko klasa senzora za najvažnija merenja; na kraju, potencijalna integracija sa GPS sistemima dovela bi do otvaranja mnogobrojnih mogućnosti za dizajn i primenu. Novi horizonti – umesto zaključka Čemu mogu služiti Ad Hoc mreže? Njihovu potencijalnu upotrebu možemo podeliti u dve glavne kategorije: • •

specifične bežične aplikacije bežični Internet

Specifične bežične aplikacije predstavljaju klasu primene u koju spada projekat opisan u prethodnom delu: to su bežične senzorske mreže. Pomoću razvijene infrastrukture, moguće je napraviti različite bežične proizvode, a primena može biti od industrijske do kućne i zabavne. Evo nekoliko primera: 1. Bolnički sistem za akviziciju podataka. Kritična stvar u većini

bolnica je vreme odziva lekara. U klasičnom okruženju, svaki pacijent je priključen na razne žičane instrumente koji šalju svoje signale nekom centralnom serveru koji zatim obrađuje primljene podatke. U slučaju otkrivanja bilo kakve anomalije, aktivira se alarm, obično u sobi za medicinske sestre. Nakon toga, sestra pokušava da pronađe lekara. Unapređivanje ovakvog sistema pomoću Bluetooth bežične Ad Hoc mreže nudi nekoliko prednosti. Prvo, vreme odgovora bilo bi znatno kraće. Drugo, lekari bi mogli opremljeni PDA uređajem koji bi omogućio slanje daljinskih komandi. Na kraju, neke odluke mogle bi se donositi lokalno, bez aktiviranja alarma.

2. Bežična kontrola saobraćaja. Jedan od glavnih problema u većini gradova jesu saobraćajne gužve i javni prevoz. Upotrebom predložene Ad Hoc tehnologije, svako vozilo javnog prevoza moglo bi biti opremljeno Bluetooth primopredajnikom. Istovetni uređaji mogli bi da budu instalirani na autobuskim stanicama. Tako bi u realnom vremenu bila raspoloživa informacija o tekućoj poziciji svakog vozila i očekivanom vremenu dolaska. Takođe, na mestima u gradu gde se obično javlja najveća saobraćajna gužva, mogli bi se postaviti bežični senzori, koji bi omogućili daljinsko upravljanje saobraćajem.

3. Urbani bežični servisi. Kada se infrastruktura iz prethodnog primera instalira, mogla bi da obezbedi okruženje za mnoge druge primene. Na primer, turista koji posećuje grad mogao bi da dobije Bluetooth slušalice koje bi se automatski povezale u Ad Hoc mrežu i pružile informaciju o tekućoj lokaciji. Naravno, kada se infrastruktura jednom postavi, mogućnosti su beskonačne – sve je stvar dodavanja novih servisa, a ne novog hardvera. Dakle, mogli bi se razviti različiti oblici urbanih servisa – od e-trgovine, do

administrativnih i zabavnih usluga (kupovina, rezervacije, kulturni programi, hitni slučajevi itd.).

4. Bežični vodič za slepe. Nažalost, većina slepih ljudi koji žive u velikim gradovima imaju dosta problema. Kako bismo im olakšali život, mogli bismo razviti sledeći proizvod. Mala Bluetooth kamera postavila bi se na odeću slepe osobe. Ona bi pravila snimke i u realnom vremenu ih preko Ad Hoc mreže prebacivala na centralni server. Na njemu bi se vršilo prepoznavanje oblika, i kada bi scena bila identifikovana, slepoj osobi bi se slalo glasovno uputstvo. Bila bi moguća i upotreba 3D zvuka, čime bi se dobio bolji osećaj prostora.

Međutim, svi navedeni proizvodi su izolovani i koriste sopstvene protokole, šeme i obradu podataka. Bilo bi lepo imati bežične vodiče za slepe, ili napredne bolničke senzore, međutim, prvo moramo približiti bežični svet običnim ljudima. Zatim, kada se populacija privikne na život “bez žice” i računare koji su deo odeće, mogli bismo krenuti ka naprednijim i/ili humanijim primenama. Naravno, ono što je potrebno običnim ljudima jeste bežični Internet. Kako radi današnji Internet? Glavna stvar je slojevita organizacija protokola, koju možete videti na slici 53.

Aplikacija (WWW, Telnet, FTP…) Pouzdani tok

(TCP) Korisnički

datagrami (UDP) Internet (IP)

Mrežni interfejs (Ethernet, Token Ring…)

Slika 53: Konceptualna slojevitost Internet protokola Komentar: Uvođenjem IP protokola iznad mrežnog interfejsa,

Internet može da enkapsulira podatke u IP pakete pre nego što ih pošalje preko postojeće mrežne infrastrukture. Mrežni hardver ne poznaje podatke u IP paketima, već samo zna da je tip informacije koju prenosi IP paket.

Šta možemo učiti da bismo napravili bežični Internet. Postoje dva rešenja: • •

uvođenje bežičnih protokola u sloj mrežnog interfejsa modifikovanje šeme IP adresiranja

Ako usvojimo prvi pristup, trebalo bi napraviti protokol za Ad Hoc rutiranje koji bi mogao da enkapsulira IP pakete, i prenese ih preko Ad Hoc bežične mreže kao da su u pitanju obični podaci. Ideja je veoma jednostavna.

Aplikacija (WWW, Telnet, FTP…) Pouzdani tok

(TCP) Korisnički

datagrami (UDP) Internet (IP)

Mrežni interfejs (Ethernet, Token Ring, Ad Hoc …)

Slika 54: Proširivanje sloja mrežnog interfejsa protokolom za Ad Hoc rutiranje Šta sada radimo? U suštini, sakrivamo mobilnost. Ako ne želimo da radimo tako nešto, moramo da modifikujemo postojeću IP adresnu šemu, kao na slici 55:

Aplikacija (WWW, Telnet, FTP…) Pouzdani tok

(TCP) Korisnički

datagrami (UDP) Internet (IP)

Mrežni interfejs (Ethernet, Token

Ring …)

Ad Hoc

Slika 55: Uvođenje Ad Hoc rutiranja u oba sloja: sloj mrežnog interfejsa i Internet sloj Dakle, treba modifikovati postojeću IP adresnu šemu. Zašto je to važno? Ne možemo slati isti sadržaj nekom serveru i mobilnom telefonu. Dakle, potreban je neki način da se u globalnom Internetu na neki način identifikuju mobilni čvorovi. Takođe, potrebno je razviti mehanizme za kreiranje pristupnih tačaka pomoću mobilnih agenata (MobileIP). Međutim, ta tema izlazi izvan okvira ove priče. Naš cilj ovde je bio da objasnimo osnovnu infrastrukturu koja je potrebna za bežičnu globalnu Ad Hoc mrežu. Preko toga je moguće implementirati postojeću ili modifikovanu TCP/IP adresnu i transportnu šemu, čime se otvara prostor za razvoj bilo kog mobilnog bežičnog servisa.

Reference:

[BTSig200

1]

Bluetooth Core Specification v1.1, Bluetooth SIG, 2001

[Miller2001]

Miller,B.A, Bisdikian,C., “Bluetooth Revealed”, Prentice Hall, 2001

[IETF2001a]

IETF, Manet Group, “Ad Hoc On Demand Distance Vector (AODV) Routing”, 2001

[IETF2001b]

IETF, Manet Group, “The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks”, 2001

[IETF2001c]

IETF, Manet Group, “Temporally-Ordered Routing Algorithm (TORA) Version 1 Functional Specification”, 2001

[IETF2001d]

IETF, Manet Group, “Landmark Routing Protocol (LANMAR) for Large Scale Ad Hoc Networks”, 2001

[Velasevic96]

Velašević,D., Bojić, D., “Zbirka zadataka iz ekspertskih sistema”, Elektrotehnički Fakultet, Beorad, 1996

[Leinecker2000]

R. Leinecker,R., Archer,T., “Visual C++ 6 Biblija”, Mikroknjiga, Beograd, 2000

[Microsoft2001]

Microsoft Corporation, “Microsoft Developer Network Library”

[Popovic99]

Dr Miodrag V Popović, "Digitalna obrada signala", Nauka, Beograd, 1999

[Bakken2001]

Stig Saether Bakken et al., “PHP Manual”, 2001

Sigurnost u Ad Hoc mrežama Sledeće pitanje kojim ćemo se baviti u ovoj seriji jeste pitanje sigurnosti u Ad Hoc mrežama. Glavni atributi sigurnosti su: 1. raspoloživost 2. poverljivost 3. integritet 4. autentikacija 5. neporicanje Razmotrićemo svaki od ovih atributa posebno. Raspoloživost osigurava opstanak mrežnih servisa i pored napada čiji je cilj da se oni ugroze. Takvi napadi mogu biti pokrenuti sa bilo kog sloja Ad Hoc mreže. Na fizičkom sloju i sloju pristupa mediju, zlonamerni korisnik može da ometa komunikaciju na fizičkim kanalima. Na mrežnom sloju, remećenjem rada protokola za rutiranje može se dovesti do raspada mreže. Poverljivost osigurava da se neke informacije nikada ne stave na raspolaganje neautorizovanim entitetima. Curenje poverljivih informacija može imati nesagledive posledice. Veoma je važno primetiti da i informacije o rutiranju u nekim slučajevima moraju biti tretirane kao poverljive. Integritet garantuje da poruka nikada neće biti kompromitovana. Poruka može biti kompromitovana zbog bezazlenih kvarova, kao što su smetnje u radio prenosu, ili zbog zlonamernih napada na mrežu. Autentikacija omogućava da bilo koji čvor utvrdi identitet čvora sa kojim trenutno komunicira. Bez autentikacije, napadač bi mogao da se maskira kao čvor i tako dobije pristup informacijama i resursima, čime bi uticao na rad ostalih čvorova. Neporicanje znači da pošiljalac poruke ne može da porekne da ju je poslao. Neporicanje je veom značajno za otkrivanje i izolaciju kompromitovanih čvorova.

Upotreba bežičnih linkova čini Ad Hoc mrežu veoma pogodnom za napade, od pasivnog prisluškivanja do aktivnog pretvaranja, ponavljanja i ometanja poruka. Prisluškivanje može obezbediti napadaču pristup tajnim informacijama, čime se narušava poverljivost. Aktivni napadi omogućavaju brisanje poruka, ubacivanje pogrešnih poruka, promena poruka, kao i ubacivanje lažnih čvorova u mrežu, čime se narušavaju raspoloživost, integritet, autentikacija i neporicanje. Pri tome ne treba da razmatramo samo napada spolja, već i napade koji su pokrenuti unutar mreže, od strane kompromitovanih čvorova. Da bi osigurale visok stepen preživljavanja, Ad Hoc mreže treba da imaju distribuiranu arhitekturu, bez centralnih entiteta. Bilo kakav centralni entitet dovodi do velike ranjivosti: ako je taj centralni entitet kompromitovan, cela mreža je na udaru. Postoje dva izvora pretnje za ruting protokole: • spoljašnji napadi • kompromitovani čvorovi unutar mreže Prva vrsta napada aktivira se izvan mreže. Ubacivanjem pogrešnih ruting informacija, ponavljanjem zastarelih informacija, ili distorzijom postojećih informacija, napadač može uspešno da particioniše mrežu ili napravi preveliki saobraćaj. Da bi se odbranili od ovakvih napda, čvorovi moraju da štite ruting informacije na isti način na koji štite i podatke, na primer, upotrebom kriptografskih šema kao što je digitalni potpis. Drugi, i znatno ozbiljniji tip napada dolazi od kompromitovanih čvorova, koji mogu da oglašavaju pogrešne ruting informacije ostalim čvorovima. Razmotrićemo problem oglašavanja pogrešnih ruting informacija. Otkrivanje takvih informacija je veoma teško: ako bismo zahtevali da svaki čvor potpiše svoje ruting informacije ne bismo uradili ništa, pošto su kompromitovani čvorovi u stanju da

generišu validne potpise pomoću svojih privatnih ključeva. Umesto toga, trebalo bi da iskoristimo činjenicu da protokoli za Ad Hoc rutiranje moraju da imaju podršku za zastarele ruting informacije, kao deo rada sa mrežnom toplogijom koja se dinamički menja. Kako ćemo to uraditi? Lažne ruting informacije koje generišu kompromitovani čvorovi možemo smatrati zastarelim. Ako ruting protokol podržava višestruke rute, čvorovi se mogu prebaciti na alternativne rute, kada se čini da primarna ruta ne radi. Još jedan način je upotreba tehnike koja se zove diversity coding. Diversity coding koristi višestruke putanje na efikasan način bez retransmisije poruka. Osnovna ideja je da se redundantne informacije prenose dodatnim rutama radi detekcije i ispravljanja grešaka. Čak i kada su neke rute kompromitovane, odredišni čvor može da proveri ispravnost poruka i oporavi ih koristeći redundantne informacije. Naravno, ova tehnika će raditi samo ako algoritam za rutiranje podržava multipath rutiranje. Za zaštitu ruting informacija i podatka možemo koristiti kriptografske šeme, kao što je digitalni potpis. Upotreba takvih šema obično zahteva servis za upravljanje ključevima. Infrastruktura sa javnim ključevima je superiorna u distribuciji ključeva i postizanju integriteta i neporicanja. U arhitekturi sa javnim ključevima, svaki čvor ima par javni/tajni ključ. Javni ključevi mogu biti distribuirani ostalim čvorovima, dok privatni ključevi moraju biti tajni i čuvati se u pojedinačnim čvorovima. Uvodimo entitet od poverenja koji se zove Certification Authority (autortitet koji izdaje sertifikacije – CA) za rad sa ključevima. CA takođe poseduje par javni/tajni ključ, s tim što je njegov javni ključ poznat svakom čvoru u mreži, a njegova uloga je potpisivanje sertifikata kojima se javni ključevi dodeljuju čvorovima. CA mora stalno da bude u mreži kako bi tekuća raspodela ključeva bila raspoloživa, pošto se raspodela može

menjati sa vremenom, a neki čvorovi mogu biti kompromitovani. Iako se nijedan pojedinačan čvor u Ad Hoc mreži ne može smatrati čvorom od poverenja zbog niske fizičke sigurnosti i raspoloživosti, možemo raspodeliti poverenje na skup čvorova. Ako pretpostavimo da bilo kojih t+1 čvorova verovatno neće biti kompromitovano, skupom od poverenja smatraćemo konsenzus od barem t+1 čvorova. Ovo je princip distribuiranog poverenja. Da bismo postigli distribuciju poverenja u servisu za upravljanje ključevima možemo da koristimo kriptografiju praga. Šema kriptografije praga u oznaci (n, t+1) omogućava da n strana deli mogućnost vršenja kriptografske operacije (na primer, kreiranje digitalnog potpisa), tako da je potrebno barem t+1 strana da bi se ta operacija izvršila, dok je nemoguće da t i manje strana izvrše operaciju. Pri tome delimo privatni ključ k servisa na n delova (s1,…sn) i dodeljujemo po jedan deo svakom serveru. Da bi servis potpisao sertifikat, svaki server generiše parcijalni potpis koristeći svoj deo privatnog ključa i šalje parcijalni potpis kombinatoru. Sa t+1 ispravnih parcijalnih potpisa kombinator je u stranju da generiše celokupan potpis. Međutim, kompromitovani serveri ne mogu sami korektno da generišu celokupan potpis, pošto mogu da generišu najviše t parcijalnih potpisa. Kombinator može da bude bilo koji server, a postoji više kombinatora za slučaj da i neki od njih postane kompromitovan. Kombinator proverava validnost izračunatog potpisa pomoću javnog ključa datog servisa. U slučaju da provera ne uspe, kombinator pokušava sa drugim skupom od t+1 parcijalnih potpisa. Ovaj proces se nastavlja sve dok kombinator ne napravi ispravan potpis na osnovu t+1 ispravnih parcijalnih potpisa. Problem sa kriptografijom praga je što ona podrazumeva sinhroni sistem, dok Ad Hoc mreže po prirodi predstavljaju asinhroni sistem (nikada ne možemo znati tačno vreme isporuke ili obrade

poruke). U stvari, svako podrazumevanje sinhroniteta predstavlja ranjivo mesto sistema, pošto napadnuta mreža može postati znatno sporija. Srećom, postoji asinhroni prototip za opisani servis rada sa ključevima, koji je nedavno i implementiran. Na kraju, ponovimo da su Ad Hoc mreže osetljive na različite vrste napada. Moramo da zaštitimo ne samo podatke, već i ruting informacije. Najbolji način zaštite predstavljaju kriptografske šeme i rad sa javnim/tajnim ključevima, zajedno sa distribucijom poverenja. Međutim, implementacija takvih rešenja je složena i nije jeftina. Bluetooth Sada ćemo ukratko dati osnove Bluetooth tehnologije, pošto ona može da obezbedi potencijalnu platformu za realizaciju budućih Ad Hoc mreža, a i stoga što projekat koji će biti opisan na kraju ove serije koristi ovu tehnologiju. Bluetooth tehnologiju razvija tzv. Bluetooth interesna grupa, koju predvode sledeće kompanije: Ericsson, IBM, Intel, Motorola, Nokia i Toshiba. Bluetooth bežična tehnologija koristi se za kreiranje otvorene specifikacije za kratkodometnu bežičnu komunikaciju. Ova tehnologija omogućava korisnicima da veoma laako kreiraju trenutne radio veze između različitih vrsta komunikacionih uređaja. Zasnovan na radio vezi, Bluetooth omogućava brz i siguran prenos glasa i podataka, a radi u globalno raspoloživom opsegu frekvencija što mu daje svetsku kompatibilnost. Bluetooth teži da postane globalni standard za bežično povezivanje [Miller2001].

Tipičan Bluetooth modul možete videti na slici 17. Postoje tri načina za komunikaciju sa modulom: USB port, UART i PCM port. USB i serijska komunikacija se obavljaju preko Host Controller Interfacea. Na slici pored toga možete videti da je glavni deo modula baseband čip. Zatim je tu i regulator napona, dok se na drugoj strani čipa nalaze kristal, radio i antena interfejs, kao i flash memorija.

Slika 17: Tipičan Bluetooth modul Kao što smo već rekli, na čipu postoje tri interfejsa: • USB 1.1. Modul spada u klasu USB uređaja visoke brzine (12

Mbps), i ima punu funkcionalnost USB slavea. • Drugi interfejs je UART. Podržani su siglani Rx, Tx, RTS i

CTS. Maksimalna brzina je 460.8 kbs. • Treći interfejs je PCM. Sinhronizacije je 8 kHz, a PCM takt je

200 kHz-2MHz. Što se tiče interfejsa za antenu, to je antena od 50 oma za Bluetooth ISM propusni opseg. Bluetooth ima tri komunikaciona sloja: base band, link manager i host controller interface. Najvažniji od njih je host controller interface pošto on daje uniformni interfejs za pristup mogućnostima Bluetooth hardvera bez obzira na platformu na

kojoj se koristi. Opis host controller interfacea ne spada u temu ove serije, ali kao primer, dajemo ovu jednostavnu sliku na kojoj možete videti kako Bluetooth host komunicira sa Bluetooth hardverom koristeći raspoloživu fizičku magistralu.

Slika 18: Bluetooth komunikacioni slojevi Komentar: Bluetooth modul komunicira sa hostom preko

HCI drajvera koristeći fizičku magistralu. Bluetooth omogućava uspostavljanje kratkodometne radio veze sa ciljem da se zamene kablovi koji povezuju prenosne i fiksne elektronske uređaje. Ključne osobine su robustnost, jednostavnost, niska potrošnja i niska cena. Bluetooth radi u ISM opsegu na 2.4 GHz. Radi smanjivanja interferencije i slabljenja, koristi primopredajnik koji radi na principu skakanja frekvencija.

Brzina simbola je 1Ms/sec. Veličina prozora na kanalu je 625 ms. Za pun dvosmerni prenos koristi se Time-Division Duplex (TDD) šema. Na kanalu, informacije se razmenjuju u paketima. Svaki paket se prenosi na različitoj frekvenciji. Paket se obično nalazi u jednom prozoru, ali se može proširiti na najviše pet. Bluetooth podržava: • asinhroni kanal za podatke • do tri simultana sinhrona kanala za glas • kanal koji simultano podržava asinhrone podatke i sinhroni

glas Svaki glasovni kanal podržava 64 kb/s sinhroni kanal u svakom smeru. Asinhroni kanal podržava do 723.2 kb/s asimetrično (i 57.6 kb/s u povratnom smeru), ili 433.9 kb/s simetrično. Bluetooth sistem sastoji se od radio jedinice, jedinice za kontrolu veze i jedinice za upravljanje vezom:

Slika 19: Tipičan Bluetooth sistem Komentar: Host je povezan sa Bluetooth radio

primopredajnikom preko link managera i link controllera.

Bluetooth sistem može da omogući point-to-point konekciju (samo dva Bluetooth uređaja), ili point-to-multipoint. U point-to-multipoint vezi, nekoliko Bluetooth uređaja deli isti kanal. Dva ili više uređaja koji dele isti kanal formiraju pikonet. Jedan Bluetooth uređaj ponaša se kao master pikoneta, dok su ostali uređaji slaveovi. U jednom pikonetu može biti aktivno do sedam slave uređaja.

Slika 20: Tipovi konekcija Komentar: Bluetooth može da formira 1-1 master slave

konekcije (a), 1-više pikonet konekcije (b) i scatternet (c).

Pored toga, mnogi slave uređaji mogu da ostanu vezani za mastera u tzv. parkiranom stanju. Parkirani uređaji ne mogu biti aktivni na kanalu, ali ostaju sinhronizovani sa masterom. Master kontroliše pristup kanalu i za aktivne i za parkirane slave uređaje. Više pikoneta čiji se dometi preklapaju formiraju scatternet. Svaki pikonet može da ima samo jednog mastera. Međutim, slaveovi mogu da budu deo više pikonetova, na bazi vremenskog multipleksa. Pored toga, master iz jednog pikoneta može da bude slave u drugom pikonetu. Svaki pikonet ima svoj kanal. Ostale mogućnosti koje podržava Bluetooth tehnologija jesu Link Manager Protocol, Logical Link Control, Service Discovery Protocol, RFCOMM, Telephony Control Protocol i još mnogo toga. Zato Bluetooth može da predstavlja potencijalnu platformu za realizaciju Ad Hoc mreža. Projekat multihop senzorske Ad Hoc mreže – uradi sam…

U poslednjem delu ove serije opisaćemo novu primenu mobilnih komunikacija – bežičnu, senzorsku multihop Ad Hoc mrežu za akviziciju podataka i udaljeno upravljanje. Ovaj projekat realizovan je na Elektrotehničkom fakultetu u Beogradu tokom IEEE međunarodnog takmičenja u dizajnu hardvera (IEEE Computer Society International Design Competition 2001). Cilj ovog projekta bio je kreiranje kompletne hardversko/softverske specifikacije za zamenu i/ili nadogradnju postojećih žičanih sistema za akviziciju podataka i upravljanje procesima. Ideja je zasnovana na očekivanju da će Bluetooth moduli, zbog svojih performansi i cene, postati standardni delovi većine elektronskih sistema: od mobilnih telefona, ličnih digitalnih asistenata, preko jedinica za industrijsku kontrolu, do kućnih uređaja. Međutim, Bluetooth uređaji su radio uređaji kratkog dometa, i kao takvi nisu pogodni za velike mreže. Zbog toga je razvijen multihop Ad Hoc protokol za rutiranje kako bi se povećao domet Bluetooth uređaja tako što je omogućeno rutiranje poruka kroz posredničke Bluetooth čvorove. Zato je razvoj počeo sa sledećom namerom: povezati Bluetooth modul sa mikrokontrolerom koji će izvršavati ruting protokol, čime se formira univerzalna osnova za bežičnu Ad Hoc komunikaciju. Finalni cilj je integracija ruting protokola na osnovni Bluetooth čip, što eliminiše potrebu za dodatnim mikrokontrolerom. Svaki uređaj koji poseduje Bluetooth čip bi tada bio potencijalni čvor u globalnoj Ad Hoc mreži (ili bežičnom Internetu). Osnovne prednosti realizovane Ad Hoc mreže jesu laka instalacija i nadogradnja, skromni zahtevi za postojećom infrastrukturom, niska cena i održavanje, velika fleksibilnost.

Sistemi za akviziciju podataka predstavljaju samo jedan način upotrebe takvog okruženja. Ovaj projekat nudi univerzalnu platformu za bežičnu integraciju bilo kog sistema koji zahteva daljinsko upravljanje i generiše analogne i/ili digitalne signale. Implementacija ovog projekta u takvom sistemu automatski garantuje dve premise: stabilnu i univerzalnu hardversku platformu i pouzdan i lako izmenljiv softver. Jednom instalirani sistem ima mogućnost dinamičke rekonfiguracije i adaptacije novim zahtevima i uslovima rada. Kao što smo već rekli, u ovom projektu je dizajniran otvoreni sistem za akviziciju i obradu podataka zasnovan na bežičnoj Ad Hoc multihop senzorskoj mreži. Mreža je realizovana pomoću Bluetooth modula, dok je ruting protokol implementiran na odvojenom hardverskom modulu (Interfejsni rutirajući modul – IFRM) zasnovanom na mikrokontroleru PIC kompanije Microchip. Da bi se naglasila otvorena arhitektura celog sistema, kao primer senzora dizajniran je sistem za digitalnu obradu signala (DSPS) zasnovan na Texas Instruments procesoru za digitalnu obradu signala, kao i lični digitalni asistent (PDA), koji omogućava brzu on-line kontrolu bilo kog procesa. Kontrola procesa vrši se pomoću softvera za akviziciju podataka (Shell) i ekspertskog sistema za donošenje odluka. Sve relevantne sistemske aktivnosti čuvaju se u bazi podataka kojoj se može pristupiti i preko Interneta. Pregled sistema Pregled sistema možete videti na slici 21. Ukratko ćemo objasniti svaku komponentu pre nego što pređemo na detaljniju analizu.

Web Serverdatabase

AD-HOC network

Webclient

PDADSPS

simulatedsensors IFRM

Bluetooth

IFRMBluetooth

Bluetooth

Slika 21: Pregled sistema Multihop Ad Hoc senzorska mreža i IFRM: Osnovna ideja Ad Hoc mreža, kao što smo već više puta rekli, jeste uspostavljanje komunikacije bez unapred definisane mrežne infrastrukture. Drugim rečima, rutiranje se vrši dinamički, a paketi sa podacima se prenose preko ostalih čvorova koji se ponašaju kao posrednici. Uloga mrežnog podsistema je da obezbedi komunikaciju između ostalih komponenti sistema (server, DSPS, PDA…). Da bi bila skalabilna i fleksibilna, mreža je projektovana kao multihop Ad Hoc bežična mreža, što znači da mobilni čvorovi unutar mreže vrše rutiranje paketa. U skladu sa tim, dizajniran je odgovarajući ruting protokol koji je zatim optimizovan za izvršavanje na mikrokontroleru sa veoma ograničenim resursima. Kako bi se omogućila integracija postojećih uređaja za akviziciju podataka u ovaj sistem, interfejs ka Bluetooth modulu projektovan je tako da tim uređajima da iluziju kao da su i dalje u direktnoj kablovskoj vezi sa serverom. Lični digitalni asistent: Uloga PDA je informiše nadležnu osobu o stanju procesa koji prati. Takođe, PDA omogućava slanje daljinskih komandi u delove sistema. Komunikacija sa ostatkom sistema obavlja se preko interfejsa koji je univerzalan za svaku komponentu koja ima pristup Ad Hoc mreži. Sistem za digitalnu obradu signala: Kao primer senzora koji se može priključiti na ovaj sistem, realizovan je uređaj sa TI DSP čipom za digitalno upravljanje motorima i obradu signala. Osnovna uloga ovog sistema je prikupljanje podataka sa

perifernih uređaja, obrada prikupljenih podataka u realnom vremenu i slanje podataka na server (preko IFRM i Ad Hoc mreže), na kome je obezbeđeno praćenje i eventualna dodatna obrada. Akvizicija podataka i ekspertski sistem: Softver za akviziciju podataka i ekspertski sistem za donošenje odluka nalaze se na serveru. Ako se otkrije bilo kakva nepravilnost u radu, ekspertski sistem pokušava da reši problem slanje kontrolnih komandi u deo sistema koji je izazvao problem. Ako sistem nije u stanju da autonomno reši problem, alarmira se nadležna osoba preko PDA. Ako se ne dobije nikakav odgovor, aktivira se rezervni sistem za slanje poruka. Svaka aktivnost sistema beleži se u bazu podataka. Baza podataka: Sve relevantne aktivnosti sistema beleže se u bazi podataka: primljeni podaci sa senzora, otkrivene nepravilnosti i slično. Bazi podataka je moguće pristupiti i preko Interneta. Ideja je da se obezbedi udaljena dijagnostika i administracija kada stručnjak na licu mesta nije u stanju da samostalno reši problem. Osnovna prednost ove ideje je što nudi univerzalnu i otvorenu platformu koja se može lako implementirati u skoro svakom okruženju uz mala prilagođavanja. Na primer, koristeći ovaj sistem moguće je unaprediti infrastrukturu fabričkih senzora. Postojeći žičani senzori mogu se lako uključiti u novu mrežu, a moguće je dodati i proizvoljan broj bežičnih senzora za svaki proizvodni proces koji se prati. Nadležni inženjer bi bio opremljen PDA uređajem, čime se skraćuje vreme odgovora. Možemo posmatrati nekoliko različitih scenarija upotrebe. Ekspertski sistem otkriva nepravilnost u prilivu podataka i pokušava samostalno da popravi situaciju. Istovremeno, šalje se poruka nadležnoj osobi, koja može ručno da pošalje daljinsku komandu koristeći PDA. Na taj način, regulacija anomalije počela je pre nego što je stručnjak došao na mesto gde se problem javio.

Ako nadležna osoba ne može samostalno da ukloni problem, neko drugi može da pristupi bazi podataka putem Interneta i pomogne stručnjaku koji se nalazi na licu mesta. Moguće je zamisliti mnogo sličnih situacija u različitim institucijama, od bolnica i elektrana do upotrebe na otvorenom prostoru – spasilačke akcije i istraživanje negostoljubivog terena. Glavni problem sa kojim se suočavamo prilikom pokušaja realizacije ovakvog sistema jeste obezbeđivanje kritične brzine podataka i stabilne Ad Hoc mreže. Prvi problem je rešen upotrebom Bluetooh modula, koji obezbeđuju dovoljno brz prenos. Pitanje stabilnosti rešeno je pažljivim projektovanjem i implementacijom protokola za Ad Hoc rutiranje. Testiranje i detaljne simulacije, čiji će rezultati biti prikazani kasnije, pokazali su da ovaj protokol, zajedno sa realizovanom hardverskom i softverskom infrastrukturom, može da radi u ekstremnim uslovima opterećenja, što je i preduslov za eventualnu industrijsku eksploataciju. Sada ćemo detaljnije razmotriti svaki deo sistema. Počećemo sa protokolom za Ad Hoc rutiranje. Protokol za rutiranje S obzirom na kritičnu primenu sistema i ograničene resurse mikrokontrolera na kome se izvršava, protokol sa rutiranje je dizajniran vodeći računa o sledećim stvarima: • brzina • pouzdanost • jednostavnost Kao što ćemo videti, na osnovu intenzivnih simulacija predložena su rešenja za svako od ovih pitanja. Razvoj protokola započet je ispitivanjem postojećih rešenja. Ispitani su sledeći protokoli: Dynamic Source Routing (DSR); Ad Hoc On-demand Distance Vector (ADOV) i Temporally Oriented

Routing Algorithm (TORA) [IETF2001a], [IETF2001b], [IETF2001c], [IETF2001d]. Ispostavilo se da DSR i TORA nisu ispunjavali postavljene zahteve. DSR emituje zahteve za rutom svim susednim čvorovima, ovaj zahtev zatim propagira kroz mrežu i prikuplja adrese svih čvorova kroz koje prolazi. Nedostatak je očigledan: u mrežama sa mnogo čvorova, zahtev za rutom postaje prevelik i mreža je preopterećena. Veliko ograničenje algoritma TORA je potreba za spoljašnjim mehanizmom za merenje vredmena (kao što je GPS). Algoritam AODV nudi prihvatljivo rešenje, iako ne koristi sve mogućnosti Bluetooth tehnologije. Zato je on usvojen kao polazna tačka, a zatim je modifikovan u skladu sa mogućnostima Bluetooth uređaja i specifičnih atributa senzorskih mreža. Algoritam za rutiranje definiše tri tipa poruka: • zahtev za rutom (route request – RREQ) • odgovor na rutu (route reply – RREP) • greška na ruti (route error – RERR)

Na slici 22. možete videti detaljnu strukturu paketa RREQ. On ima šest polja: Hop count, Broadcast ID, Destination Address,

Destination Sequence Number, Source Address i Source Sequence Number.

RREQ: Hop Count BCID Dest

Address DSN Source Address SSN

Hop Count – broj hopova do odredišnog čvora BCID – jedinstveni identifikator za RREQ Destination Address – adresa čvora do koga se zahteva ruta DSN – poslednji poznati DSN Source Address – adresa čvora koji je poslao RREQ SSN – tekući SSN

Slika 22: Format paketa RREQ

Hop Count označava broj hopova do odredišnog čvora. BroadcastID je jedinstveni identifikator svakog RREQ. Destination address je adresa do koje se zahteva ruta. Destination

Sequence Number je poslednji poznati broj sekvence za zahtevano odredište (nula ako nije poznat). Source Address je adresa čvora koji je inicirao otkrivanje rute, dok je Source Sequence Number tekući broj sekvence za datu rutu.

RREP:

Hop Count Destination Address DSN Source

Address Lifetime

Hop Count – broj hopova između odredišta i izvorišta Destination Address – adresa čvora za koga je pronađena ruta DSN – broj sekvence za rutu Source Address –adresa čvora koji je poslao RREQ Lifetime – vreme za koje se ruta smatra validnom

Sada ćemo ispitati strukturu paketa Route Reply. On ima pet polja: Hop Count, Destination Address, Destination Sequence Number, Source Address and Lifetime. Jedino novo polje koje ovde srećemo je Lifetime, koje označava vreme za koje se ruting informacija smatra validnom. Paket Route Error sastoji se od samo tri polja: Destination Count, Unreachable Destination Address and Unreachable Destination Sequence Number. Prvo polje definiše broj nedostupnih čvorova, drugo polje je adresa nedostupnog čvora, dok je treće polje poslednji poznati odredišni broj sekvence uvećan za 1. Slika 33: Format paketa RREP

Slika 34: Format paketa RERR Sada ćemo pokušati da ukratko opišemo rad protokola. Algoritam razlikuje tri tipa čvorova: master, gateway i slave. On koristi ugrađenu mogućnost Bluetooth modula da formiraju pikonet mreže sa maser-slave komunikacijom. Čvorovi koji su članovi dva ili više pikoneta su gateway čvorovi. Celokupna komunikacija obavlja se samo na nivou master-slave. Slave čvorovi šalju pakete masteru svog pikoneta, a master ih zatim šalje na odgovarajući gateway. Ovaj tip prosleđivanja nastavlja se sve dok paket ne stigne u pikonet u kome se nalazi odredišni čvor.

RERR:

DestCount Unreachable Dest Address

Unreachable DSN

DestCount – broj nedostupnih čvorova Unreachable Dest Address – adresa nedostupnog čvora Unreachable DSN – poslednji poznati DSN uvećan za 1

Server (čvor na kome se nalazi ekspertski sistem) komunicira sa svim ostalim čvorovima (senzori, PDA), dok ostali čvorovi šalju svoje podatke samo serveru (što je osobina senzorskih mreža – sam protokol nije ograničen na ovaj tip komunikacije). Posmatrajmo situaciju u mreži koja je prikazana na slici 35. Ovde imamo server M1 i pet drugih master čvorova M0-M5. Možete videti da se u ovom okruženju nalazi šest pikonet mreža. Možemo identifikovati gateway čvorove kao članove dva ili više pikoneta. Ovde su gateway čvorovi 8, 1, 2, 3, 7 i 13. Preostali čvorovi su slave čvorovi. Algoritam radi na sledeći način: tokom inicijalizacije sistema formiraju se pikonet mreže, svaki čvor kreira tabelu suseda (čvorovi u istom pikonetu) i praznu ruting tabelu. Kada čvor želi da pošalje poruku drugom čvoru, on prvo pretražuje tabelu suseda kako bi video da li se odredišni čvor

nalazi u istom pikonetu. Ako jeste, komunikacija se obavlja odmah, preko mastera tog pikoneta. Ako odredišni čvor nije u tabeli suseda, čvor pretražuje svoju ruting tabelu.

10

10

146

9

12

M4

M4

M3

M1 M2M5

M011

11

16

4 515

0

8

133

7

2

master

gateway

plain node

Slika 35: Tipična mrežna topologija Komentar: U komunikaciji učestvuje tri tipa čvorova:

master, slave i gateway. Pikoneti se preklapaju i u njihovom preseku nalaze se gateway čvorovi.

Na slici 36 možete videti kako izgleda jedan ulaz u ruting tabeli. Ruting tabela sadrži sedam polja: Destination Address (adresa odredišnog čvora), Destination Sequence Number, Hop Count, Last Hop Count (broj hopova pre invalidacije rute), Precursors (lista čvorova kojima se vrši prosleđivanje) and Lifetime. Kao što smo već rekli, ako odredišni čvor nije u tabeli suseda, čvor pretražuje svoju ruting tabelu. Ako postoji aktivna ruta do odredišnog čvora, paket se prosleđuje čvoru navedenom u polju Next Hop odgovarajućeg ulaza u ruting tabelu. Ako u ruting tabeli ne postoji ispravan unos za željeno odredište, čvor šalje paket route request (RREQ) koji propagira kroz mrežu, ali ne prostim emitovanjem – sva dalja komunikacija obavlja se isključivo na nivou master-gateway-master.

Slika 36: Ulaz u ruting tabeli Nema potrebe da master emituje RREQ svim slave čvorovima, pošto on ima sve potrebne informacije o njima u svojoj tabeli suseda. Kada RREQ stigne do odredišnog čvora (ili do čvora koji ima validnu rutu do odredišnog čvora), generiše se poruka RREP, koja zatim putuje nazad do čvora koji je izdao RREQ. Istovremeno, svi čvorovi koji se nalaze na putanji paketa RREQ i RREP ažuriraju svoje ruting tabele. Pri slanju RREQ, čvor popunjava polje DSN zadnjom poznatom vrednošću za željeno odredište (na početku nula). Ako se tokom komunikacije desi da se pojavi ulaz u ruting tabelu čija je vrednost veća od ovoga, znači da je ruta neispravna. Kada čvor primi RREQ, proverava da li postoji validna ruta ka odredištu. Ako takva ruta ne postoji, RREQ se šalje dalje, dok se DSN postavlja na veću od vrednosti DSN iz RREQ i DSN iz ulaza u ruting tabeli (ako postoji). U suprotnom, generiše se paket RREP.

Dest Address DSN Hop

Count Last Hop Count

Next Hop Precursors Lifetime

Dest Address – adresa odredišnog čvora DSN – odredišni broj sekvence Hop Count – broj hopova do odredišta Last Hop Count – broj hopova pre invalidacije rute Precursors – lista čvorova kojima se prosleđuje Lifetime – vreme za koje se ruta smatra validnom

Čvor šalje poruku o greški na ruti (RERR) u tri slučaja: • link ne funkcioniše (1) • primljen je paket, ali ne postoji aktivna ruta do odredišta (2) • primljen je paket RERR od susednog čvora

Slučajevi (1) i (2) rešavaju se uvećavanjem vrednosti odgovarajućeg DSN. Ovim je rešen problem dinamičkih promena mrežne topologije. Zatim se RERR prosleđuje dalje, zajedno sa listom nedostupnih čvorova i novom vrednosti DSN.

U trećem slučaju, za svaki nedostupan čvor iz RERR, proverava se da li se izvorišni čvor (Source Address) nalazi u polju Next Hop bilo koje rute ka nedostupnim čvorovima. Ako jeste, zahteva se sledeća procedura: DSN se ažurira, Hop Count se postavlja na beskonačno (čime se poništava ulaz u ruting tabeli), stara vrednost se kopira u Last Hop Count, proverava se polje Precursors, i ako nije prazno RERR se ponovo šalje. Nakon toga ovo polje se briše. Zbog testiranja, pre hardverske implementacije protokola, napisan je simulator u Javi. Početna mrežna topologija se definiše u konfiguracionoj datoteci. Broj čvorova nije ograničen. Za svaki čvor kreira se odvojena nit izvršavanja. Jedan čvor se proglašava za server (na kome se nalazi ekspertski sistem), a nakon toga se poruke i odredišta generišu na slučajan način. Takođe, neki čvorovi prelaze iz jednog pikoneta u drugi, čime se simulira kretanje osobe koja nosi PDA (ili bilo kog drugog mobilnog čvora). Pošto su ruting tabele prazne na početku simulacije, proces otkrivanja ruta i popunjavanja ruting tabela se može lako pratiti. Analiza rada protokola može se izvršiti unosom konfiguracije sa slike 35 i praćenjem procesa otkrivanja ruta. Pretpostavimo da čvor M0 (server) sa slike 35 želi da pošalje poruku čvoru 6. Server pretražuje tabelu suseda i zaključuje da čvor 6 nije u istom pikonetu. Zatim vrši pretraživanje ruting tabele. Pošto su na početku sve ruting tabele prazne, ne postoji ulaz za čvor 6. Zato čvor M0 šalje RREQ svim gateway čvorovima koji su u njegovom dometu. Pošto nije bilo prethodne rute ka čvoru 6, vrednost DSN u RREQ postavlja se na nula. Gateway čvorovi 8 i 1 primaju ovaj RREQ. Dalji proces otkrivanja rute prikazan je na slikama 37 i 38.

Kada se proces otkrivanja rute završi, čvor M0 može da pošalje poruku čvoru 6 preko novoustanovljene rute preko čvora čvora 1. Osnovna stvar koju ovde treba primetiti jeste kako par RREQ/RREP poruka može da dovede do kreiranja mnogo ulaza u ruting tabelama svih čvorova kroz koje ove poruke prolaze.

M4

M3

M1

M2

M0

11

16

4

5

0

8

3

2

1RREQ

RREQ

RREQ

RREQM0 8 0 M0 1 0

M0 M1 0

M0 3,7 0M1 3,7

M0 M1 0

M0 2 0M1 2 0

RREQ

RREQ

RREQ

RREQ

RREP

Slika 37: Otkrivanje rute – propagacija paketa RREQ

M1

M0

4

0

3

1 M0 1 06 3,7 0

M0 M1 0

6 M1 0

6 1 0

RREP

RREP

RREP

Slika 38: Otkrivanje rute – propagacija paketa RREP U ovom slučaju, jedan zahtev za rutom doveo je do kreiranja 11 novih ulaza u ruting tabelama posredničkih čvorova, bez emitovanja RREQ. Ovo je jasna prednost u poređenju sa raznim algoritmima koji koriste emitovanje. Ova prednost postiže se

istovremenim održavanjem tabele suseda, tako da nema potrebe za emitovanjem zahteva za rutom unutar pikoneta. Poznata mrežna topologija ostaje ista, dok se broj konekcija potrebnih za pronalaženje rute smanjuje proporcionalno broju pikoneta i čvorova unutar njih. Na ovom nivou nije moguće ustanoviti analitički model koji može da prikaže kvantitativnu prednost ovakvog pristupa, pošto ne postoje pouzdani podaci o dodatnom vremenu koje se troši na održavanje pikonetova, tj. tabela suseda. Međutim, ako kao parametar prihvatimo broj konekcija potrebnih za otkrivanje rute, dobijamo rezultat prikazan na slici 39. Jasno je da kada u mreži postoji mali broj čvorova, ovaj mehanizam liči na klasično emitovanje, pošto većina pikoneta u stvari predstavlja obične 1-1 veze. Međutim, kako raste broj čvorova (tj. pikonetovi postaju sve naseljeniji), algoritam pokazuje svoje prednosti, pošto prosečan broj konekcija potrebnih za otkrivanje rute počinje da raste znatno sporije.

number of nodes

number of connections

Slika 39: Prosečan broj konekcija potreban za otkrivanje rute Komentar: Kako pikonetovi postaju gušće naseljeni,

procečan broj konekcija potrebnih za uspešno otkrivanje rute počinje da raste sporije.

Još jednom se mora napomenuti da ovi rezultati ne potiču od 100% pouzdanog modela, pošto se pretpostavlja da je vreme potrebno za održavanje pikonetova dosta malo u poređenju sa vremenom potrebnim za slanje poruke.

Bez obzira na sve to, u algoritam je ugrađena tehnika za optimizaciju ulaska novog čvora u pikonet. Ova optimizacija zasnovana je na eliminaciji redundantnih pikonetova. Zašto je tako nešto važno? Prvo, redukcija broja redundantnih pikonetova automatski znači da postoji manji broj konekcija tokom procesa otkrivanja rute. Zatim, Bluetooth tehnologija koristi frequency hopping spread spectrum tehnologiju, a sa povećanjem broja konekcija raste i verovatnoća kolizije na kanalu, što degradira performanse. Generalna ideja je sledeća: kada novi čvor ulazi u pikonet, pri čvor koji ga detektuje otvara konekciju (pikonet) ka dolazećem čvoru. Isti proces se nastavlja se dok i master pikoneta ne otkrije novi čvor. Master zatim ažurira tabelu suseda, i emituje informaciju da je novi čvor ušao u pikonet. Nakon što prime ovu informaciju, svi slave čvorovi koji su već ustanovili vezu sa novim čvorom raskidaju svoje konekcije sa njim. Na taj način su eliminisani redundantni pikonetovi. Ceo proces je prikazan na slici 40.

1

1

1

5 55 55 5

5

2

2

2

3

3

34

4

4

master

master

master

host is entering the piconet host is entering the piconet

master is detectinga new host

slave hosts break connections

Slika 40: Eliminacija redundantnih pikonetova Komentar: Kada novi čvor uđe u pikonet, slave čvorovi

otvaraju nove konekcije. Kada master otkrije novi čvor, on ažurira tabelu suseda, dok slave čvorovi raskidaju svoje konekcije.

Poslednji problem na koji treba obratiti pažnju jeste sinhronizacija. U simulator je uvedena veštačka sinhronizacija, čime se eliminiše potencijalna kolizija. Za sada ne postoji način

da otkrijemo koliko dobro sinhronizacija Bluetooth modula funkcioniše u realnim siutacijama, tj. koliko pikonetova može biti napakovano u ograničenom prostoru. Planira se da dalja unapređenja simulatora uključe potojeće protokole za Ad Hoc rutiranje (DSR, AODV, TORA, LANDMARK…). To bi omogućilo komparativnu analizu koja bi dovela do unapređenja predloženog protokola. Nikola Milanović