Mérési útmutató a Mobil Hírközlés Laboratórium II (VIHI4381) méréseihez. V. mérés. Mobil IP - CIP OMNeT++ szimulációs mérés

Átírás

1 Mérési útmutató a Mobil Hírközlés Laboratórium II (VIHI4381) méréseihez V. mérés Mobil IP - CIP OMNeT++ szimulációs mérés Mérés helye: Híradástechnikai Tanszék Mobil Távközlési és Informatikai Laboratórium (MC 2 L) I.B.113. Összeállította: Szabó Sándor PhD hallgató Rózsás Balázs PhD hallgató Kiefer Tamás Tilk Gergely Utolsó módosítás: november 14.

2 A mikromobilitás elve A mikromobilitás protokollok a mobil IP alatti hierarchiaszinten helyezkednek el. Egy jól definiált, kisebb területen biztosítanak mobilitáskezelést, ellentétben a mobil IP-vel, ami a teljes hálózatban való mobilitást támogatja (makromobilitás). Ezt a hierarchikus rétegződést mutatja az 1. ábra. 1. ábra. Domain alapú vezeték nélküli hálózat és a mobil IP Ahogy az ábrán is látható két alapvető handover (cellaváltás) típust különböztetünk meg. Az egyik az intra-domain handover, ami egy jól definiált területen belüli cellaváltásokra vonatkozik. Ezt kezelik a mikromobilitás protokolljai. Makromobilitásról pedig akkor beszélünk, ha két domain között mozgunk. Ezt inter-domain handovernek nevezzük, ami már a mobil IP hatáskörébe tartozik. A mikromobilitás algoritmusainak célja, hogy minél gyorsabban bonyolítsák le az intra-domain handovereket, és ezzel növeljék az elérhető teljesítményt, a hálózat kihasználtságát, és minimalizálják a felhasználó adatfolyamában fellépő megszakadások idejét. Cellás IP A Cellás IP (Cellular IP CIP) egy IETF (Internet Engineering Task Force) előterjesztés, amelyet a Columbia egyetem és az Ericsson kutatói fejlesztettek ki. A működéséhez a mobil hosztoknak a mobil IP támogatása mellett támogatnia kell a CIP protokollját is. A CIP hálózatmodellje a 3. ábrán látható. A hálózatot egy gateway router köti az Internethez, a hálózat CIP routerekből épül fel, amelyek lehetnek egyben bázisállomások is. Feladatuk a csomagok továbbítása, illetve a mobilok helyének nyilvántartása. A CIP routerek topológiailag fát alkotnak, mindegyikhez egyértelműen megadható egy uplink neighbour (fölötte álló szomszéd), amely közvetlenül fölötte helyezkedik el a getaway router felé, és egyben az Internet felé vezető úton. Egy routerhez több downlink neighbour (a fában alatta álló szomszéd) is kapcsolódhat. Ezt a szerkezetet vagy a hálózat tervezésénél kell meghatározni, vagy egy kiválasztó algoritmus segítségével lehet kialakítani (akár on-line módon). A bázisállomások a rádiós interfészen a mobilok felé történő kommunikációért felelősek. Minden bázisállomás egy routerhez tartozik. A mobil hosztok a cellákban mozognak, és az adott cella bázisállomásával képesek kommunikálni, esetleg a cellahatár közelében a szomszédos cella bázisállomásával is.

3 3. ábra. A CIP hálózat felépítése Bekapcsolása után a mobil hoszt beregisztrálja magát a hálózatba. A regisztrációnak az a szerepe, hogy a hálózat tudja, hogy merre kell a mobilnak szóló csomagokat továbbítani (a fa melyik ágán tartózkodik a mobil hoszt). A regisztrációt a route-update nevű üzenettel lehet elvégezni, amely a mobil hoszttól a gateway routerig továbbítódik routerről routerre a fa hoszthoz vezető ága mentén. A közben érintett routerek mindegyike bejegyzi az általa nyilvántartott ún. route cache-be a mobil pozícióját. Ez a táblázat (mobil hoszt, interfész) párokat tartalmaz, amelyek jelentése az, hogy egy adott IP címre szóló csomagot a routernek melyik interfésze felé kell továbbküldenie (lefele történő továbbítás esetén). Miután a frissítési üzenet elért a gateway routerig, a hálózatban található routerek közül a mobil felé vezető útvonalon találhatók ismerik a mobil hoszt helyét, így képesek neki csomagot továbbítani. A routerekben tárolt információ soft-state (egy bizonyos idő után elévül, és törlődik), azaz a mobilnak periodikusan frissítenie kell azt, különben törlődik a táblákból. Ennek előnye, hogy ha valamiért elérhetetlenné válik a mobil, akkor sem marad meg a hozzá tartozó bejegyzés lefoglalt erőforrásként, hanem felszabadul erre vonatkozó explicit kérés nélkül. A CIP-ben a frissítés automatikusan megtörténik egy egyszerű adatcsomag küldése esetén is, illetve természetesen egy újabb route-update üzenet küldése esetén is. A frissítést 3 másodpercenként el kell végezni. Amennyiben a mobil hoszt nem akar kommunikálni, de elérhető akar maradni, akkor nincs szükség a routerekben a táblák állandó frissítésére, hanem helyette az úgynevezett paging cache-be kell bejegyeztetniük a helyüket. Ekkor a mobil hoszt állapotát idle (tétlen) állapotnak nevezzük, ellentétben az aktív állapottal, amikor ténylegesen kommunikációt folytat egy másik hoszttal. A paging lényege, hogy a bázisállomásokhoz tartozó celláknál nagyobb területet lefedő paging területekre osztjuk a CIP domain-t, ezáltal csökkenve az ilyen területek közti váltások számát. Ezek a területek több, szomszédos bázisállomás cellái által lefedett területek. A paging cache táblák abban térnek el a route cache-től, hogy nincs szükség minden routerben tárolni őket, valamint hosszabb az elévülési idejük (a nagyobb területeknek megfelelően). A paging táblát a hálózati routerek ugyanúgy használják, mint a routing táblát. A paging területek kijelölésére egy példa látható a 4. ábrán.

4 4. ábra. Paging area-k cellás rendszerekben Egy idle mobil hosztnak szóló, uplink oldalról beérkező csomag rendeltetési helye alapján a paging táblából kikeresik, hogy melyik downlink interfészen kell azt továbbküldeni. Azokban a routerekben, ahol nincs paging tábla, minden lehetséges downlink irányba továbbítani kell a csomagot (broadcast). Azok a területek, ahová ez az elárasztás (flooding) történik, tulajdonképpen maguk a paging area-k. Az idle állapotú mobil hoszt csomag fogadása esetén rögtön egy route-update üzenetet kell, hogy küldjön, hogy minél hamarább egyetlen útvonalat terheljenek a neki szóló csomagok. A route cache, illetve a paging cache összehasonlítása az 1. táblázatban látható. Tulajdonság Paging cache Route cache Frissíti Minden mobiltól kapott csomag Paging-update kivételével minden mobiltól kapott csomag Hatáskör Idle/aktív mobilokra Csak az aktívakra Cél Paging csomagok továbbítása Mobilnak címzett csomagok továbbítása Időskála Mobilitás Csomag 1. táblázat. A paging és route cache összehasonlítása Egy másik feladat a mobil hosztok helyének felderítése mellett a mozgás során ennek követése. Ehhez a mobiloknak minden handover (cellaváltás) esetén értesíteniük kell a hálózatot. Ez idle állapot esetén kevésbé lényeges, mivel a paging területek nagyobbak a celláknál, így ritkábban történik váltás ezek között. A mobil IP hálózatokban a hosztok IP címe fix (pontosabban van egy fix IP címük), amelyet egy, az otthoni hálózatában található nem mobil hoszt (home agent) fordít át a mobil hoszt ideiglenes IP címére (care-of-address). A CIP-ben hoszt alapú routing történik, ami azt jelenti, hogy a routerek által tárolt cache táblákban az egyes hosztokhoz tartoznak a bejegyzések. Ez lehetővé teszi, hogy a mobil IPben a mobilhoz tartozó care-of-address a gateway router IP címe legyen, mivel onnantól a router már továbbítani képes a csomagot a mobilnak. (A gateway router látja el a mobil IPv4- beli foreign agent szerepét 5. ábra.) Tehát a mobil IP protokoll az otthoni hálózattól a gateway routerig tart, onnantól a mobil hosztig pedig a CIP protokoll működik, így valósul meg a kétszintű mobilitás kezelés. A CIP lokálisan működő routing algoritmusával lefed egy nagyobb területet, így nincs szükség minden egyes cellaváltásnál a home agent-ig visszajelezni a handover tényét, mert az a CIP hálózatrészben lekezelődik (intra-domain handover). A mobil IP-beli handoverhez szükséges frissítés csak a CIP hálózatok közti váltásnál (inter-domain handover) szükséges.

5 5. ábra. A CIP és a mobil IP együttműködése A handovert a CIP-ben mindig a mobil hoszt kezdeményezi egy route-update üzenet küldésével az új bázisállomásnak. Ez az üzenet a korábban leírt módon eljut a gateway routerig, és közben frissíti a soft-state bejegyzéseket a táblákban, vagy újakat hoz létre a nem átlapolódó részeken. Kétféle handovert különböztethetünk meg a CIP protokollban: a hard, illetve semi-soft handovert. Mindkettő esetében feltételezhető, hogy a mobil hoszt egyszerre csak egy bázisállomással képes kommunikálni a rádiós interfészén keresztül. A különbség a bázisállomások közti átkapcsolás módjában van. A hard handovernél a mobil hoszt egyszer átkapcsol az új bázisállomáshoz, és utána ott is marad. Semi-soft esetben a mobil csak annyi időre kapcsol át először az új bázisállomáshoz, hogy elküldjön egy route-update üzenetet azzal megjelölve, hogy ez egy semi-soft handoveres üzenet. Ezek után visszakapcsol még a korábbi bázisállomáshoz. Az új bázisállomásnak küldött üzenet végighalad a gateway routerig, és felfrissíti a bejegyzéseket, vagy újakat hoz létre. Abban a csomópontban, ahol a fában találkozik az új és a korábban használt útvonal (ez a csomópont az ún. crossover node), egyelőre nem törlődik a korábbi bejegyzés sem. Ez a csomópont duplikálni fogja a mobilnak szóló csomagokat, és mindkét irányba (a korábbi és új pozíció felé egyaránt) továbbítja azokat. A mobil a handover tényleges lezajlása után ismét egy route-update üzenetet küld, ami megszünteti ezt a duplikálást. Hard handovernél természetesen az egyszeri átkapcsolás miatt a crossover nodeban történő frissítés előtt odaérő csomagok el fognak veszni, mivel azokat a korábbi helyre irányítja a router. Semi-soft handovernél azok a csomagok veszhetnek el, amelyek az új bázisállomásnak való route-update üzenet küldése alatt érkeznek a régi bázisállomáshoz. Mindkét esetben kevesebb azonban az elveszett csomagok száma, mint az egyszerű mobil IPs megoldásnál, ami egy hard handover. Ekkor egyetlen váltás történik a bázisállomások között, a mobil nem hallgat már vissza a korábbi cellába. A másik előnye a Cellás IP-nek, hogy ezek a handoverek jóval rövidebb ideig tartanak, mint a mobil IP-ben. A routerek működése a CIP-ben némileg eltér a hagyományos IP routingtól. Az uplink irányt a hálózatmenedzsmentből eredően minden router ismeri, esetleg egy legrövidebb utat kereső algoritmus segítségével is felderíthető. Ha downlink irányból érkezik egy csomag, akkor ez alapján a router frissíti az adott mobilhoz tartozó routing és paging cache bejegyzést egyaránt. Ez alól kivétel a paging-update üzenet, amely csak az utóbbit frissíti. Az egyszerű adatcsomagok csak a soft-state bejegyzések idejét frissítik, de nem változtatják azokat. Egy cache bejegyzés (routing vagy paging) a következő mezőkből épül fel: (IP cím, interface, MAC cím, elévülési idő, időbélyeg). Az időbélyeg a legutóbbi frissítést eredményező csomag időbélyege. Az IP cím a mobilt, a MAC, illetve interfész cím pedig a router egyik lefele menő

6 interfészét azonosítja. Downlink irányba történő routing esetén elsőként a route cache alapján kikeresett irányba továbbítódik a csomag, ha abban nincs megfelelő (az adott mobilnak szóló, nem elévült)) bejegyzés, akkor a paging cache-ben található megfelelő bejegyzés dönt. Ha ebben sincs a rendeletetési címnek megfelelő - nem elévült - bejegyzés, vagy az adott routerben nincs paging cache, akkor broadcastolja az üzenetet az összes downlink szomszédjának. Biztonsági problémák is felmerülnek a CIP hálózatban. Például az eddigiek alapján könnyedén megvalósítható lenne, hogy egy mobil helyett route-update üzeneteket küldve a neki szóló csomagokat valaki más kapja meg, hallgassa le. Ennek kivédésére a CIP protokoll lehetőséget nyújt. Minden CIP hálózatnak van egy titkos hálózati kulcsa, amelyet a routerek ismernek, de a mobilok nem. A mobilok hálózatba lépéskor regisztrálják és azonosítják magukat. Ez a gateway router feladata, amely ezután egy PID-et (Personal Identification) generál a hálózat kulcsa és a mobil IP címe alapján. Csak a vezérlési üzeneteket védik ezzel a titkosítással. Minden CIP hálózatnak van egy egyedi azonosítója (CIP network indentifier). Ezt a bázisállomás által periodikusan adott beacon jelek is tartalmazzák. A mobil hosztok ezen jelek alapján határozzák meg a legközelebbi bázisállomást. Tehát a mobil a hálózati azonosítónak megváltozásából veheti észre, hogy egy másik CIP hálózatba került. Ebben az esetben mobil IP-s regisztrációra van szükség a home agent-nél. A beacon jel ezen kívül a Gateway router IP-címét is tartalmazza. A CIP hálózatok közti váltásnál a mobil autentikálja magát a Gateway-nél az első paging-update üzenettel, majd ha ez sikeres volt, akkor a home agent felé elkezdheti a mobil IP szerinti regisztrációt, amiben a care-of-address a Gateway IP címe lesz. (Esetleg a Gateway router is elvégezheti ezt). Minden paging területhez tartozik egy (az adott CIP hálózaton belül egyedi) azonosító. A beacon jel ezt is tartalmazza, így az idle állapotú mobilok felismerhetik, kell-e küldeniük paging-update-t. Erre a paging tábla bejegyzés elévülése miatt is szükség lehet. A handovert tehát a mobil hosztnak kell jeleznie, ő indítja a folyamatot egy route-update csomag küldésével. A CIP hálózaton belüli cellaváltás ténye a crossover node felett nem észlelhető, csak alatta frissülnek a cache bejegyzések. Idle állapot esetén csak paging terület váltásánál kell jeleznie a mobil hosztnak, energiát takarítva meg ezzel. Az idle állapotú mobilok helyét tehát a paging táblák határozzák meg. Az ebben tárolt információ akkor kerül felhasználásra az ilyen táblával rendelkező routerben, ha nincs bejegyzés a route cache-ben az adott mobilhoz. A paging cache a route cache-el együtt kerül frissítésre, illetve paging-update üzenet érkezésekor. Ha van egy routerben paging cache, és csomag érkezik egy olyan mobilnak, akinek nincs bejegyzése, akkor a csomag eldobásra kerül. Ekkor célszerű a feladó állomást egy ICMP (Internet Control Message Protocol) csomagban értesíteni erről. Ha egy idle mobil hoszt csomagot kap, aktívvá válik, route-update üzenetet küld. Route cache minden CIP csomópontban van, ezeket mindegyik, mobiltól kapott csomag frissíti/létrehozza, kivéve a paging-update vagy paging-teardown. A mobil hoszt IP címét az adott dowlink interfészhez rendelik a táblákban lévő bejegyzések (entry), a mobil irányába ezek alapján jut el a csomag. A route cache-ben lévő bejegyzést akkor kell frissíteni, ha az előre megadott route-updtate-time lejár, vagy cellaváltás van. A CIP hálózat csomópontjai (bázisállomás, routerek) minden, mobiltól származó IP csomagot a legrövidebb úton (a fában felfelé), hop-by-hop módon továbbítanak a Gateway router-hez, függetlenül a csomagban lévő rendeltetési címtől. Ezek a csomópontok nem végeznek felfelé routing funkciókat. Az egyetlen uplink szomszédjuk vagy a hálózat menedzsment, vagy valamilyen algoritmus segítségével határozható meg.

7 Az OMNeT++ alapú CIP szimulátor A laborgyakorlat során a CIP protokoll teljesítményének és működésének szimulációs vizsgálatára az MCL laborban kifejlesztett CIP szimulátor programot használjuk. A mikromobilitás hálózat szerkesztését egy Java alapú környezetszerkesztő program segíti. Ez a fejezet a szimulátor és a szerkesztő program felépítését és kezelését ismerteti. Mielőtt megismerkednénk a szimulátorral, röviden bemutatjuk az OMNeT++ rendszert, amelyben a szimulátor íródott. Az OMNeT++ diszkrét események szimulációjához nyújt hasznos keretrendszert. Az OMNeT++ alapú szimulátornak két fő összetevője van: A hálózat topológiáját, bizonyos paramétereit az erre a célra szolgáló NED (NEtwork Description) nyelv segítségével írja le, míg az egyes objektumok működését C++ nyelven valósítja meg az OMNeT++ által nyújtott könyvtárak segítségével. Ezen objektumok közötti viszony (a topológia) adható meg a NED-ben. A fordítás során a NED kódból szintén C++ kód generálódik, majd végül C++ fordító segítségével keletkezik a futtatható állomány. Az OMNeT++ lehetőséget nyújt a hálózatleíró NED állományok grafikus szerkesztésére is a GNED programmal. A Cellás IP szimuláció elsősorban a protokollt leíró IETF draftot veszi alapul, hat osztályt valósít meg, amelyek példányai a NED-ben felhasználhatóak. További három osztály szükséges a CIP-beli funkciók megvalósításához, valamint a CIP domain-t is összetett modulként valósítja meg, ami szintén egy újabb osztályként jelentkezik a végső C++ kódban, valamint egy további osztályt használ az inicializálási feladatok ellátására. A szimuláció a CIP protokoll, illetve a CIP domain implementálása mellett tartalmaz egy Internetet modellező hosztot, valamint mobilokat, illetve az ezek mozgását kezelő rádiós interfészt. A következőkben röviden ismertetjük a CIP domain-ben megtalálható objektumokat: CIP node A csomagok továbbítására szolgál a fa topológiájú hálózatban. Route cache-t mindig tartalmaz, de használhat paging cahce-t is. A csomagok kezelése a következőképpen zajlik: Downlink irányból érkező csomag: Frissíti a route cache-t és a paging cache-t majd a csomópont az uplink szomszédja felé továbbküldi. A frissítésekhez a csomagból felhasznált információk: típus, forrás IP címe, port (interfész) száma. A paging-update csak paging cache-t frissíti (vagy hozza létre benne a bejegyzést, ha még nem volt, a route-update mindkettőt. Frissítés azonban csak akkor történik, ha a csomagban lévő időbélyeg frissebb a bejegyzésben találhatónál. Az két update, illetve a paging-teardown üzeneteknél autentikáció is történik. Ez utóbbinál a már meglévő bejegyzések törlésre kerülnek. A regular IP csomag (azaz egyszerű adatcsomag) csak frissít mindkettőben, de nem változtatja meg a bejegyzéseket. Ha nincs hozzá (a forráscímhez) tartozó bejegyzés, akkor a csomag eldobásra kerül. Egy bejegyzés a következő mezőkből áll: A mobil hoszt (otthoni) IP címe, Interfész (downlink irány), MAC cím (downlink irány), Elévülési időpont, Időbélyeg (a frissítést okozó csomagbeli timestamp mező értéke) Uplink irányból érkező csomag: A rendeltetési cím alapján az adott csomópont eldönti, hogy van-e route cache bejegyzés. Ha van, akkor a bejegyzésben tárolt irányba küldi tovább a csomagot. Ha nincs, és paging cache bejegyzés (vagy már paging cache) sincs, akkor minden downlink interfészén keresztül elküldi (broadcast). Ha van paging cache bejegyzés, akkor az abban megadott irányba továbbítja a csomagot. Ha van paging cache, de nincs bejegyzés ehhez a mobilhoz, akkor a csomagot eldobja.

8 Bázisállomás, rádiós hozzáférési pont (CIPBS) A csomagok rádióhullámokon keresztüli átviteléért felelős, a csomagokat változatlanul továbbítja. Ezen kívül még egy funkciója van: adott időközönként beacon jeleket sugároz, amelyek alapján a mobilok eldönthetik, hogy melyik bázisállomással kommunikálnak. Rádiós átvitel modellezése (CIPAir) A bázisállomások, illetve a mobilok aktuális pozícióját lekérdezi, és a bejövő csomagot az adott sugáron belüli objektumoknak továbbítja. Gateway router Három részből áll: controller, packet filter, CIP node. Az alulról érkező csomag a CIP node-on amely hasonlóan működik a többi CIP routerhez keresztül átjut a filterbe. Ha a rendeltetési cím a Gateway, akkor átkerül a controllerbe. Ott, ha a csomagbeli control field üres, akkor eldobja a csomagot, különben feldolgozza. Ha nem Gateway volt a címzett, akkor a csomag az Internetre kerül. (Ilyen működésnél az azonos CIP hálózatban lévő mobilok is a home agent-en keresztül kommunikálnak. A filter ezt ellenőrizheti, és ha valamelyik cacheban talál megfelelő bejegyzést, akkor egyszerűen visszafordítja a csomagot). Az Internetről érkező csomagok esetén, ha mobil IP-s csomagról van szó, akkor kibontásra kerül (decapsulated), és továbbhalad a mobil terminál felé. Ha nem mobil IP-s a csomag, akkor a mobilnak ez az otthoni hálózata. Ha nincs foreign registration bejegyzése (azaz otthon van), akkor a csomag változatlanul megy a downlink irányba. Ha nincs az otthoni hálózatában a mobil, akkor a csomag visszakerül az Internetre, a gateway - mint home agent - elküldi a mobilnak a csomagot. Mobil hosztok A mobil hoszt két állapotban lehet: idle vagy aktív. Idle állapotból aktívba kerül, ha kapott egy csomagot, vagy éppen küldeni akar. Az átmenethez route-update-t kell küldenie. Ezzel egyidőben egy timert (időzítőt) is indít a route-update-time értékéről lefele, valamint egy másikat, ami az aktív állapot megszűntetéséhez szükséges. Ha ez lejár úgy, hogy nem küldött közben semmit, akkor újra route-update szükséges. Minden elküldött IP csomag alaphelyzetbe állítja vissza a timert. Aktív állapotból akkor kerül vissza idle-be, ha egy ideje már nem kapott és nem küldött semmit. Ez szintén egy timer lejártakor történik meg (amit csomag küldésekor/érkezésekor alaphelyzetbe állít vissza). Ha aktív állapotban handover történik, vagy új bázisállomáshoz kerül (pl.: rádiós hiba után), akkor ismételten route-update üzenetet kell küldenie, és ekkor is visszaállítja a fent említett timert. Idle állapotban periodikusan paging-update üzeneteket küld (paging update time időközönként), vagy paging terület váltásánál. Ennek elévülését is egy timer-rel figyeli, amit szintén alaphelyzetbe állít minden csomagküldés. Az egyszerű hard handover mellett (amikor a mobil egyszeri átkapcsolással vált a két cella közt) egy másik módszert is támogat a CIP, a semisoft handovert. Ekkor amobil az új bázisállomás fele a route-update csomagban az S flaget 1-re állítja, majd a réginél figyel tovább. A crossover node, amikor megkapja az S=1-es jelzésű csomagot, létrehoz még egy bejegyzést, és egyszerre két bejegyzést is nyilvántart, megduplázza a csomagokat a régebbi bejegyzés elévüléséig. Ha a handover ténylegesen is megtörtént, újabb route-update következik S=0-val. Ez törli a crossover node-beli duplázódást, ha még nem évült el a régebbi bejegyzés. A szimulátorban a mobilok véletlenszerűen mozognak, és véletlenszerűen kezdeményeznek hívásokat.

9 Internet modellezése (INHost) Az Internet hoszt véletlenszerűen hívásokat kezdeményez a mobilok felé, illetve fogadja azok hívásait. Egy, a grafikus tervező felülettel létrehozott minta CIP domain a 6. ábrán látható, két paging területtel. Az OMNeT++ GNED grafikus editorában megjelenítve a hálózat felépítése a 7. ábrán látható. 6. ábra. Egy megvalósított CIP domain 7. ábra. A megvalósított teszthálózat. A jobb felső ablakban a cipdom objektum (azaz a CIP domain) látható kifejtve.

10 Az IP Mikromobilitás szimulátorra illesztett grafikus tervezőkörnyezet kezelése A program futtatása a simgui könyvtárban a java Main parancs beírásával lehetséges. A tervezőmező megjelenése után van módunk bázisállomások elhelyezésére és ezek tulajdonságainak beállítására (a falak és mobilok elhelyezése a mérési feladatok szempontjából lényegtelenek). Lehetőség van a bázisállomások tulajdonságainak utólagos módosítására is a jobb egérgomb lenyomásával. A router fa építésére szolgáló külön ablakot az Eszközök menüpontból érhetjük el. Az új ablakban az előző ablakból csak a bázisállomások és celláik kerülnek át. A routerek elhelyezése nagyban hasonlít a bázisállomások lerakásához azzal a különbséggel, hogy itt nem kell előre megadnunk a router tulajdonságait. Jobb egérgombbal az adott routerre kattintva, egy előugró menüben kiválaszthatjuk a router tulajdonságai menüpontot. Itt utólag módosíthatjuk a kiválasztott routerhez rendelt gyerek csomópontokat, melyek routerek és bázisállomások is lehetnek, illetve megadhatjuk, hogy az adott router rendelkezzen-e paging cache-el. Fontos megemlíteni, hogy két router összekötésénél minden esetben az lesz a szülő, más néven uplink neighbour, amelyiktől a kapcsolatot létesítjük (első kattintás). Megjelenítéskor a kapcsolatot jelképező piros vonal szülőhöz közelebbi felén egy piros pont jelenik meg. A GATEWAY keresése funkciógomb megnyomásával a program megkeresi a kialakított router fa gyökér-routerét. Erre a NED állományba való kiíratásnál van szükség, ugyanis a program a gateway routertől kezdve rekurzív algoritmussal írja ki a routerek kapcsolatait a ned file-ba. Tehát minden esetben el kell végeztetni a gateway keresést mentés előtt. Egy másik fontos kritérium, hogy a felépített router fában a gateway és a bázisállomások közt legalább még egy routernek kell lennie. Ellenkező esetben a kiírt NED file hibás lesz. A Routerfa építése nevű ablak bezárásával a router fa egy vektorban tárolódik, így az nem vész el, bármikor újra előhívható. A mentéssel természetesen a router fa is kiíródik a megadott szöveges (txt) vagy NED állományba. Mentéskor a teljes file-nevet meg kell adni, kiterjesztéssel együtt. (Ellenkező esetben nem lesz kiterjesztés.) A paging területek megjelenítésével ( Eszközök menüpont alatt) ellenőrizhetjük, hogy megfelelően csoportosítottuk-e a rádiós cellákat. Az azonos paging azonosítóval rendelkező rádiós celláknak egymás mellett kell lenniük. A létrehozott topológiát célszerű először txt-be menteni, mivel a grafikus program ebből képes visszaolvasni. A NED formátumot a CIP szimulátor fordításakor használjuk. Mérési feladatok Hozzon létre egy CIP domain-t a JAVA-s (java.exe Main) Sim Gui-ban az előző részben leírtak alapján. A bázisállomásokat a szerkesztőmező bal alsó sarkába helyezze el. A bázisállomások száma legyen például 6, erre építsen fel a gateway-en kívül legalább még egy szintet tartalmazó router fát. Ne felejtse el a gateway keresése funkciót! A létrehozott domaint mentse le NED-be. Szöveges állományban szintén érdemes elmenteni, mivel utólag ebből lehet visszatölteni a megszerkesztett domaint szükség esetén. Ezek után megvan a domainnek egy olyan leírása, amit a szimulátorban felhasználhatunk az alábbiakban leírt módon. Az előbb elkészített NED-el írja felül a szimulátor könyvtárában (omnetcip) található cipdomain.ned-et (nem az omnetcip.ned-et), illetve az omnetpp.ini-ben módosítsa a bázisállomások számát a megtervezett domain-nek megfelelően (theomnetcip.numbss értékét). Ezzel a szimuláció forráskódjába illesztettük a megtervezett domaint. Ezek után újra kell fordítani a szimulációt. Microsoft Visual C++ -ban omnetcip2011.sln megnyitása, pl.

11 open workspace-el. Ezután újrafordítjuk a teljes projektet (clean+build), majd elindíthatjuk a generált omnetcip2011.exe-t. Futtatáskor az OMNeT++ TkEnv nevű grafikus környezetébe kerülünk, ahol többek közt lehetőség van a szimuláció lépésenkénti (F4), folyamatos (F5), gyors (F6), és express (F7) futtatására. Futás közben megfigyelhetjük a Cellás IP protokoll működését. Az alább található mérési feladatoknál a router fa felépítése is látható lesz, amennyiben kettőt kattintunk a cipdom nevű objektumra. A routerek megjelenítési koordinátáit a SimGui-ból veszi a szimuláció. A bázisállomások megjelenítése fix magasságban, sorban történik (lásd 7. ábra). A szimuláció a futtatás végén a kimenet az a.txt nevű állományba írja, mindig hozzáfűződik az újabb futtatás kimenete a korábbiakhoz. Ezért a mérés elején célszerű törölni az állományt, hogy ne könnyebben azonosíthatóak legyenek a futtatások. Ebbe az állományba tetszőleges szöveg beleírható, a szimuláció csak hozzáfűzi az újabb eredményeket. A hozzáfűzött adatok (3 sorban): egy elválasztó sor némi magyarázattal, a csomagok összes késleltetése, a csomagok száma, a csomagok átlagos késleltetése (az előző kettő hányadosa), valamint a szimulációban történt handoverek száma. Az alábbi mérések során mindig ezekből az adatokból kell következtetéseket levonni. Miután a fentebb leírtak alapján már megismerkedett a mérés eszközeivel, végezze el az alábbi méréseket, majd elemezze a kapott eredményeket! A részfeladatok után megadott nevek az előre elkészített példa domain-ek nevei, amelyek a simgui\pl alkönyvtárban érhetőek el. Ezek felhasználásával kell megvizsgálni a feladatokban leírt kérdéseket. (Azaz felülírni a szimulátor cipdomain.ned állományát, omnetpp.ini-ben módosítani a bázisállomások számát, ha változott, újrafuttatni, az a.txt nevű file-hoz hozzáfűzött 3 sorból pedig következtetéseket levonni.) 1. Vizsgálja meg a router fa magasságának hatását a router-update üzenetekre, és az átlagos késleltetésre. A bázisállomások száma 12, a rádiós cellák sugara 150, a teszthálózat paging területeinek száma 4. A router fa szintjeinek száma pedig sorban a) 2 (sim11) b) 3 (sim12) c) 4 (sim13) 2. Figyelje meg a paging területek számának növelése által okozott változásokat a handoverek és a route-update üzenetek számában. A bázisállomások száma 12, sugaruk 100. A router fa szintjeinek száma itt állandó, mivel már nem annak a hatását vizsgáljuk. A paging területek száma sorban a) 2 (sim24) b) 3 (sim23) c) 4 (sim22) d) 6 (sim21)

12 3. Vizsgálja meg a változó rádiós cellaméret hatásait. (A router fa magassága itt sem változik.) a) A bázisállomások száma 4, rádiós cellák sugara 200 (sim31) b) A bázisállomások száma 9, rádiós cellák sugara 150 (sim32) c) A bázisállomások száma 17, rádiós cellák sugara 110 (sim33) Ellenőrző kérdések Mi az összefüggés a makro- illetve a mikromobilitás közt? Mi a különbség a CIP protokollban használható kétféle handover technika között? Mire használható a paging area? Mik az alkalmazásának előnyei? Hasonlítsa össze a route és a paging cache tárolókat! Írja le egy cellaváltás menetét CIP hálózatban! Hogyan történik az útvonalválasztás uplink és downlink irányban? Melyik a kakukktojás? a/ mikromobilitás b/ kakukktojás c/ mikromobilitás d/ mikromobilitás Irodalomjegyzék 1. Csaba Keszei, Jukka Manner, Zoltán Turányi, András Valkó: Mobility Management and Qos in Brain Networks 2. Bernd Gloss, Christian Hauser: The IP Micromobility Approach, EUNICE Internet draft (draft-ietf-mobileip-cellularip-00.txt), December, András G. Valkó: Cellular IP: A New Approach to Internet Host Mobility 5. OMNeT++ homepage, 6. IETF homepage,