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



Hasonló dokumentumok
2011. május 19., Budapest IP - MIKRO MOBILITÁS

Hálózati architektúrák laborgyakorlat

Mobil Partner telepítési és használati útmutató

Hálózati réteg. Feladata: a csomag eljusson a célig Több útválasztó Ez a legalacsonyabb rétek, mely a két végpont

állomás két címmel rendelkezik

IP alapú kommunikáció. 5. Előadás Routing 2 Kovács Ákos

V2V - routing. Intelligens közlekedési rendszerek. VITMMA10 Okos város MSc mellékspecializáció. Simon Csaba

Két típusú összeköttetés PVC Permanent Virtual Circuits Szolgáltató hozza létre Operátor manuálisan hozza létre a végpontok között (PVI,PCI)

Multiprotocol encapsulation (RFC1483) - IETF Classical IP over ATM (RFC1577) - IETF LAN Emulation (LANE) - ATM Forum Multiprotocol over ATM (MPOA) -

Kihívások. A jövő kommunikációs hálózatainak legfontosabb képességei:

Windows rendszeradminisztráció és Microsoft szerveralkalmazások támogatása. 3. óra. Kocsis Gergely, Kelenföldi Szilárd

MAC címek (fizikai címek)

AGSMHÁLÓZATA TOVÁBBFEJLESZTÉSE A NAGYOBB

Hálózati réteg. WSN topológia. Útvonalválasztás.

ContractTray program Leírás

DebitTray program Leírás

Hálózati architektúrák és Protokollok PTI 6. Kocsis Gergely

Számítógép hálózatok gyakorlat

Felhasználói kézikönyv - Android kliens

ServiceTray program Leírás

Statikus routing. Hoszt kommunikáció. Router működési vázlata. Hálózatok közötti kommunikáció. (A) Partnerek azonos hálózatban

Mobilitásmenedzsment GSM és UMTS hálózatokban

HASZNÁLATI ÚTMUTATÓ DOLGOZÓK IMPORTÁLÁSA KULCS BÉR PROGRAMBA AZ ONLINE MUNKAIDŐ NYILVÁNTARTÓ RENDSZERBŐL. Budapest, november 08.

Hálózati architektúrák és Protokollok PTI 5. Kocsis Gergely

Az importálás folyamata Felhasználói dokumentáció verzió 2.1.

III. Felzárkóztató mérés SZÉCHENYI ISTVÁN EGYETEM GYŐR TÁVKÖZLÉSI TANSZÉK

Pénzintézetek jelentése a pénzforgalmi jelzőszám változásáról

Kommunikációs rendszerek programozása. Routing Information Protocol (RIP)

OCSP Stapling. Az SSL kapcsolatok sebességének növelése Apache, IIS és NginX szerverek esetén 1(10)

TERC V.I.P. hardverkulcs regisztráció

Adatátviteli rendszerek Mobil IP. Dr. habil Wührl Tibor Óbudai Egyetem, KVK Híradástechnika Intézet

GPRS Remote. GPRS alapú android applikáció távvezérléshez. Kezelési útmutató

FELHASZNÁLÓI ÚTMUTATÓ

Forgalomirányítás, irányító protokollok (segédlet az internet technológiák 1 laborgyakorlathoz) Készítette: Kolluti Tamás RZI3QZ

Az adott eszköz IP címét viszont az adott hálózat üzemeltetői határozzákmeg.

IP - Mobil IP. Hogyan érnek utol a csomagok? Dr. Simon Vilmos. adjunktus BME Hálózati Rendszerek és Szolgáltatások Tanszék svilmos@hit.bme.

A TERC VIP költségvetés-készítő program telepítése, Interneten keresztül, manuálisan

Windows rendszeradminisztráció és Microsoft szerveralkalmazások támogatása. 3. óra. Kocsis Gergely, Supák Zoltán

A Wireshark program használata Capture Analyze Capture Analyze Capture Options Interface

2014 UNIVERSITAS SCIENTIARUM SZEGEDIENSIS UNIVERSITY OF SZEGED


Számítógép hálózatok 3. gyakorlat Packet Tracer alapok M2M Statusreport 1

Algoritmus terv 3. Fejezet: Folyamatok meghatározása

Hálózati Technológiák és Alkalmazások. Vida Rolland, BME TMIT október 29. HSNLab SINCE 1992

SMS küldő központ Leírás

IP anycast. Jákó András BME TIO

Address Resolution Protocol (ARP)

SZAKDOLGOZAT ÓBUDAI EGYETEM. Neumann János Informatikai kar Alba Regia Egyetemi Központ

Invitel levelezés címek esetén

Tájékoztató. Használható segédeszköz: -

FORGALOMIRÁNYÍTÓK. 6. Forgalomirányítás és irányító protokollok CISCO HÁLÓZATI AKADÉMIA PROGRAM IRINYI JÁNOS SZAKKÖZÉPISKOLA

2017 UNIVERSITAS SCIENTIARUM SZEGEDIENSIS UNIVERSITY OF SZEGED

Internet Protokoll 6-os verzió. Varga Tamás

Vodafone Mobile Connect telepítése

Térképek jelentése és elemzése

V2V - Mobilitás és MANET

Hálózati architektúrák és Protokollok GI 8. Kocsis Gergely

Tartalom. Router és routing. A 2. réteg és a 3. réteg működése. Forgalomirányító (router) A forgalomirányító összetevői

Hálózati Technológiák és Alkalmazások. Vida Rolland, BME TMIT november 5. HSNLab SINCE 1992

Hálózati rendszerek adminisztrációja JunOS OS alapokon

WordPress segédlet. Bevezető. Letöltés. Telepítés

Szülői modul. Belépés a TANINFORM rendszerbe. Főoldal

Hálózati architektúrák és Protokollok GI 7. Kocsis Gergely

Mérési útmutató a Mobil infokommunikáció laboratórium 1. méréseihez

VARIO Face 2.0 Felhasználói kézikönyv

IP alapú kommunikáció. 4. Előadás Routing 1 Kovács Ákos

Gyakorló 9. feladat megoldási útmutató

2016 UNIVERSITAS SCIENTIARUM SZEGE- DIENSIS

Department of Software Engineering

Budapest 2002 Xix Software Kft.

e-szignó Online e-kézbesítés Végrehajtási Rendszerekhez

Magyar Nemzeti Bank - Elektronikus Rendszer Hitelesített Adatok Fogadásához ERA. Elektronikus aláírás - felhasználói dokumentáció

Hozzávalók keresése és csatolása

Hálózati Technológiák és Alkalmazások

PLC Versenyfeladat. XIV. Országos Irányítástechnikai Programozó Verseny Budapest, március Összeállította az EvoPro Kft.

Bevezető. PoC kit felépítése. NX appliance. SPAN-Proxy

TÁJÉKOZTATÓ a MicroSigner alapú alkalmazás használatáról

A d m i n i s z t r á c i ó s f e l a d a t o k a I n t e g r á l t K ö n y v t á r i R e n d s z e r b e n

WS-Pro WPX38 MD+ PROGRAMOZÓI KÓDOK ÖSSZESÍTÉSE

Hálózatok. Alapismeretek. A hálózatok célja, építőelemei, alapfogalmak

Útmutató az IP és Routing mérésekben használt Cisco routerek alapszint konfigurációjához i

Routing. Számítógép-hálózatok. Dr. Lencse Gábor. egyetemi docens Széchenyi István Egyetem, Távközlési Tanszék

Routing IPv4 és IPv6 környezetben. Professzionális hálózati feladatok RouterOS-el

MS ACCESS 2010 ADATBÁZIS-KEZELÉS ELMÉLET SZE INFORMATIKAI KÉPZÉS 1

Online adatszolgáltatás beállítása a Számlázás - vevő-szállító nyilvántartás programban (UJVSZ)

Mappák megosztása a GroupWise-ban

Adatbázis-kezelés az Excel 2013-ban

Az ErdaGIS térinformatikai keretrendszer

Feladat kezelő modul

Mobil Internet és a tesztelésére szolgáló infrastruktúra

Kommunikációs rendszerek teljesítőképesség-vizsgálata

A FileZilla program beállítása az első belépés alkalmával

Mobilitás és MANET (II)

Távollét, szabadság szabály létrehozása, kezelése a GroupWise-ban

A számítógép-hálózat egy olyan speciális rendszer, amely a számítógépek egymás közötti kommunikációját biztosítja.

Minőségellenőrzési kérdőív kitöltő program Felhasználói kézikönyv

Hálózati Architektúrák és Protokollok GI BSc. 3. laborgyakorlat

Tartalom jegyzék 1 BEVEZETŐ SZOFTVER ÉS HARDVER KÖVETELMÉNYEK 2 2 TELEPÍTÉS 2 3 KEZELÉS 5

web works hungary Rövid technikai tájékoztató a webhosting szolgáltatásról. (PLESK szerver)

Online adatszolgáltatás beállítása a Kettős könyvelés programban (WUJEGYKE) 79/

Átírás:

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: 2002. november 14.

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. á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. á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. á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ő

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.

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.

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.

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.

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.

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)

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 2000 3. Internet draft (draft-ietf-mobileip-cellularip-00.txt), December, 1999. 4. András G. Valkó: Cellular IP: A New Approach to Internet Host Mobility 5. OMNeT++ homepage, http://www.hit.bme.hu/phd/vargaa/omnetpp.htm 6. IETF homepage, http://www.ietf.org