Mérési útmutató a Mobil Hírközlés Laboratórium méréseihez. Heterogén hálózatok együttműködése Vertical Handover mérés

Átírás

1 Mérési útmutató a Mobil Hírközlés Laboratórium méréseihez LXXXIII. Mérés Heterogén hálózatok együttműködése Vertical Handover 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 Összeállította: Szálka Tamás Fülöp Péter Bakonyi Gábor Lendvai Károly PhD hallgató PhD hallgató okleveles mérnök mérnök hallgató Utolsó módosítás: november 20. 1

2 1 Bevezetés A napjainkban érvényesülő fix-mobil konvergencia mellett egyre többféle hozzáférési technológia áll rendelkezésünkre (EDGE Enhanced Data Rates for Global Evolution, GPRS General Packet Radio System, WLAN Wireless LAN) és ezek száma illetve lefedettsége folyamatosan bővül (UMTS Universal Mobile Telecommunication System, WiMAX, Wifi). A felhasználói eszközök, készülékek piacán is tapasztalhatóak a változások. Manapság egy jól felszerelt notebook vagy okostelefon többféle vezeték nélküli interfészel rendelkezik, melyen keresztül kapcsolódhatnak a világhálóhoz. Jogosan merül fel az igény, hogy kihasználva az egyes access technológiák előnyeit, és figyelembe véve hátrányaikat mindig a számunkra legkedvezőbb kapcsolaton keresztül kommunikáljunk. Jelenleg a készülékek arra képesek, hogy egyik, vagy másik interfészükön kapcsolódjanak a világhálóhoz, de ha váltani szeretnénk közöttük, akkor ezt manuálisan kell megtennünk. Képzeljük el, hogy reggel a munkahelyünkre utazunk, és közben a laptopunkon -t olvasunk. Tegyük fel, hogy éppen kétféle hálózat érhető el, GSM és UMTS. Az ek letöltéséhez megfelelő az olcsó, keskenysávú GPRS kapcsolat, így ezt használjuk. A levelek elolvasása után videokonferenciát indítunk, amihez már szélessávú kapcsolat szükséges, így a vertical handover-képes laptopunk átvált a drágább UMTS hálózatra. Ahogy beérünk a munkahelyünkre, ott már WLAN lefedettség is van, ami olcsó és szélessávú, ezért laptopunk lebontja a UMTS kapcsolatot, és WLAN-hoz csatlakozik, ezen folytatjuk a videokonferenciát. Mindeközben a hálózatváltásokból semmit sem vettünk észre, a használt alkalmazások folyamatosan futottak. A mérés célja hogy megismerje a hallgató a hozzáférési hálózatok közötti átjárhatóság problémáját, az IP címváltás során felmerülő nehézségeket, a seamless handover lehetséges megoldásait illetve egy tesztrendszer segítségével a piacon elérhető technológiákat és a kutatásfejlesztés fázisában lévő rendszereket. 2

3 2 Felvetődő problémák Hogy a fenti példa megvalósulhasson gyors, zökkenőmentes vertical handover folyamat szükséges. Ehhez fontos a használt hálózati protokoll, és felhasználói program ismerete, egyes protokollok ugyanis nem tűrik a hálózatváltást, míg mások gond nélkül veszik. Ha például biztonságos kapcsolatot használunk, az IP-cím (Internet Protocol) változása fennakadást okozhat a biztonságos kommunikációban. Más esetekben, például ezés közben (POP3 (Post Office Protocol version 3) protokoll használatakor) semmi gond sincs. Meg kell tehát figyelni, hogy melyik alkalmazásnak milyen sávszélességbeli, szolgáltatásbeli igényei vannak, így dönthetünk, hogy melyik hálózatra kell váltani, illetve azt is szem előtt kell tartani, hogy a futó alkalmazás lehetővé teszi-e egyáltalán a hívásátadást. Az elérhető hálózatok közötti döntéshez rengeteg információ szükséges, tehát méréseket kell végeznie a rendszernek, hogy melyik hálózat milyen sávszélességet vagy szolgáltatásokat biztosít. Fontos, hogy az adatok frissek és pontosak legyenek, de nem terhelhetjük sem a hálózatot, sem az eszközünket túl gyakori vagy hosszadalmas mérésekkel. Láthatjuk tehát, hogy különböző hozzáférési hálózatok közötti hívásátadáskor rendkívül körültekintőnek kell lenünk, a döntéshez mélyrehatóan kell ismernünk az elérhető hálózatokat, a futó alkalmazásokat, sőt, a számlázási időszakokat, tarifákat is. 3 Handover csoportosítása A handover hozzáférési pontok közötti hívásátadást jelent, alapvetően két fajtáját szokás megkülönböztetni, a horizontal handover-t (HH), és a vertical handover-t (VH). HH-ről beszélünk akkor, amikor ugyanazon hálózat két, földrajzilag elkülönülő hozzáférési pontja között történik a váltás. Ez történik például akkor, amikor mobiltelefonnal barangolás közben egy cellából egy másikba lépünk. VH-ről akkor beszélünk, amikor egy helyen egymás fölött párhuzamosn többfajta hozzáférési hálózat érhető el, és ezek között történik a hívásátadás. Fizikailag nem, de hálózati szempontból ekkor is mozgunk. Tehát a későbbiekben ha mobilitás fogalmát használjuk, akkor a heterogén hálózatok közötti átjárást is beleértjük. 3

4 A handovert osztályozhatjuk aszerint is, hogy hol történik a hálózatok közötti döntés. Mobile Controlled Handover-ről (MCHO) beszélünk akkor, amikor a hívásátadást a mobil terminál vezérli, a döntést a mobil terminál hozza. Hátránya, hogy mobil eszközünket bonyolult szoftverrel kell ellátni, előnye, hogy hálózatfüggetlen, nincs szükség támogatottságra a hálózat részéről. A mérés során egy ilyen rendszert ismerhetnek meg a hallgatók. Network Controlled Handover-ről (NCHO) beszélünk, ha a döntést a hálózatnak egy erre a célra létrehozott ügynöke végzi, ekkor nem terheljük a mobil eszközt a döntéshozatallal. 4 Heterogén hálózatok közötti mobilitás A fentebb említettek alapján levonhatjuk a következtetést, miszerint a különböző hozzáférési technológiák egyszerű átjárhatóságának egyik legnagyobb akadálya az Internet Protocol tervezési hiányossága. Az IP cím kettős funkciót lát el. Egyedi azonosítóként szolgál, és helyzetinformációt hordoz. Mobilitás világában, és így a heterogén hálózatok közötti átváltásnál ez a két fogalom nem szerepelhet egy kalap alatt, hiszen ha mozgunk az egyedi azonosítónk nem tudja megmondani hol is vagyunk, ellenben ha helyzetinformációt tudunk nyújtani, nem lehet ez az egyedi azonosítónk. A mobilitással együttjáró IP címváltozás kezelésére különböző OSI rétegekben fejlesztettek ki megoldást. A következő fejezetben a különböző rétegekben kialakítható mobilitás támogatási stratégiákat követjük végig létező, vagy fejlesztés alatt lévő példákkal. Azt követő részben pedig a teljes hálózat szemszögéből vizsgáljuk, csoportosítjuk a megoldásokat. 4.1 Átjárhatóság megvalósítása Az OSI modellben az egyes rétegek elég lazán vannak definiálva, ebből adódóan felmerülhetnek problémák. Például léteznek szolgáltatások melyek több rétegben is megvalósításra kerültek, míg mások pedig egyikben sem. Szolgáltatások, mint például a mobilitás is, nem tartoznak egyértelműen egyik réteghez sem, több helyen is megvalósíthatóak. 4

5 Amit biztosan tudunk hogy az átjárhatóságot megvalósító rendszereknek három alapvető követelményt kellene kielégíteniük: - Átlátszó átvitel : a hálózatok közötti váltás ne okozzon nagy adatvesztést, a váltás ne tartson sokáig és a hosszú távú kapcsolat orientált protokollokat használó programok zavartalanul futhassanak tovább. - Lokáció menedzsment : a heterogén hálózatok között mozgó eszköznek mindvégig elérhetőnek kell lennie egy statikus azonosító segítségével függetlenül attól, hogy helyileg éppen hol van. - Infrastruktúra mentesség : minél jobban a hálózat szélén van a mobilitás megvalósítva, annál kevesebb változtatásra van szükség a jelenlegi hálózatokban Adatkapcsolati réteg A fizikai réteg feletti mobilitáskezelés csupán regionális megoldásként szerepelhet, egy adott alhálózaton belüli szabad mozgást valósíthatunk meg segítségével. Hozzáférési hálózatok közötti átjárásra önmagában teljesen alkalmatlan. Más, magasabb rétegbeli megoldással karöltve azonban gyors, és hatékony megoldások születhetnek, példaként láthatjuk a MIP (Mobile IP) és CIP (Cellular IP) együttműködését. Ezeknek lehetőségeknek a hátránya hogy a globális megvalósítása nehézkes, hálózatban lévő node-ok nagy részét fel kell készíteni a protokollok kezelésére Hálózati réteg A hálózatokban egyre erősebb az IP dominanciája. A jövőbeni fejlődés mindenképpen integrált NGN (Next Generation Networks) IP alapú csomagkapcsolt hálózatok irányába mutat. Másrészről a homokóra alakú protokoll stackmodell alapján az IP egyeduralkodó. Mindezek azt jelentik, hogy a hozzáférési technológiák sokasága egységesen IP alapon működik és fog működni, ebből következően az IP alapon megvalósított handover megoldásoknak nagy jelentősége lesz, tehát a legérdemesebb ebben a rétegben keresni a megoldást az átjárhatóság kérdésére. A vertical handover szempontjából itt a cél úgy megoldani a hálózatváltást és az ezzel járó IP címváltozást, hogy arról a felhasználó és az általa futtatott applikáció a lehető legkevésbé értesüljön. Illetve ha értesül róla, az ne zavarja meg. Magán az eszközön ezt a váltást elrejteni 5

6 csak belső erőforrást igényel. Például egy szoftvermodul, vagy protokoll stack változtatás, amely a váltást kezelve a felhasználói alkalmazás felé állandó IP-címet, vagy állandó új réteget mutat (1. ábra). Nagyobb körültekintést igényel a távoli kommunikációs partner kezelése. Felmerülhet az ötlet, hogy a mobil eszközön futó megoldás funkcionális tükörképét alkalmazzuk. Ez nehezebben megvalósítható, hiszen minden kiszolgáló szoftverét kell kiegészíteni, ugyanakkor nem oldja meg a kapcsolat azonosíthatóságát. A kapcsolat azonosítására azért van szükség, hogy a kiszolgáló tudja, hogy melyik csomag, melyik mobil eszköztől, milyen céllal érkezett. A TCP/IP szokványos kapcsolatazonosítójának része az IP-cím. Ha tehát a handover miatt változik az IP-cím, a kiszolgáló nem tudhatja, hogy még mindig ugyanazzal a mobil eszközzel kommunikál. Erre jó példa a Host Identity Protocol, amit a későbbiekben részletezünk. HTTP, HTTPS, FTP, RTSP,... TCP UDP IP adatkapcsolati réteg fizikai réteg virtuális IP vertical handover démon érvényes IP 1 érvényes IP ábra: IP protokoll-stack lehetséges módosítása A képen jelölt virtuális IP cím az applikációk által látott cím, amelyen keresztül a távoli alkalmazásokkal kommunikálnak.. Az érvényes IP címek a kliens valódi címei, amelyeket az egyes hozzáférési hálózatokhoz való csatlakozáskor kap. A vertical handover démon kezeli az IP címeket és átfordításukat. Másik lehetőség hogy egy állandó címmel rendelkező harmadik entitást (nevezzük későbbiekben szervernek) vonunk be a kommunikációba, amit vagy az otthoni hálózatunkba (pl. Mobile IP) vagy a teljes hálózat egy optimális pontjára helyezünk el. A mozgó készülék valamilyen formában mindig tudajta a harmadik entitással az aktuális elérhetőségét. Természetesen ennek a folyamatnak védetnek kell lennie, különben számtalan visszaélésre adna lehetőséget. Aki a mobil terminállal akar kapcsolatot létesíteni az a szervernek küld, aki továbbít a mobil utolsó ismert címére. Fordított kommunikáció szintén a szerveren keresztül zajlik. A megoldásnak két alapvető hátránya van: 6

7 - A csomagok adott esetben hatalmas utat tesznek meg, mivel oda-vissza is átmennek a szerveren. - Ha a szerverrel történik valami, akkor a mobil állomás elérhetetlenné válik. Ez utóbbi megoldás esetén az alkalmazások egy virtuális IP címen keresztül elrejtve ezzel a valódi interfészeket akarnak kommunikálnak a távoli kommunikációs partnerrel. Azonban ahogy az előbb említettük, a harmadik entitás segítségével tudjuk csak megoldani, hogy egy egységes címen keresztül folyamatosan elérhető legyen a mobil állomás. Így jogosan merül fel a kérdés: hogyan irányítsuk el az adatokat a harmadik entitáshoz? Alapvetően három lehetőség nyílik az IP hálózatokban a feladat elvégzésére, a tunneling, source routing és payload kiterjesztés, vagy egyszerűsített tunneling. Tunneling A tunneling, vagy más néven IP encapsulation, lényege, hogy a szabványos IP csomagot becsomagolja egy újabb IP csomagba. Ezáltal az eredeti csomag elé kerül egy újabb IP fejléc, emiatt csak payload-ként értelmezik a hálózati csomópontok. Így a külső fejléc segítségével eljuttathatjuk a csomagot a klienstől a szerverig, amely levágja a külső IP csomagolást, és megkapja a belső IP csomagot, amit változtatás nélkül továbbküldhet. Mindehhez arra van szükség, hogy a kliens minden interfészén keresztül kiépítsen egy alagutat a szerverhez és fordítva. Ez egy kliens-szerver regisztrációs protokoll segítségével megoldható. Kliens Alkalmazás Handover Kliens Tunnel Handover Szerver Cél állomás 2. ábra: Tunneling 7

8 A megoldás igencsak elegáns, már bejáratott és támogatott szoftverelemekre épül, azonban a vezetéknélküli környezetben oly szűkös sávszélesség miatt a csomagonkénti 20 oktettnyi IP csomagoló fejléc túl nagy overheadet jelent. Ezáltal egy weboldal letöltésénél, ahol sok kis csomagban töltődik le az oldal, a csomagonkénti 20 bájt érezhetően lelassíthatja az átvitelt. Source Routing A source routinggal elérhetjük, hogy a csomagunk teljesen az általunk előre megválasztott útvonalon, és a kívánt routereken, állomásokon keresztül érkezzen meg a célcímre, még akkor is, ha ez az útvonal teljesen eltér az optimálistól. Ekkor az útvonalkijelölés nem a default gateway ismeretei alapján történik. A módszer veszélye a funkcionalitásában rejlik, hiszen ha egy általunk megválasztott csomópont, melyen a csomagot át akarjuk küldeni, meghibásodik, a csomagunk elveszik. A source routing implementálása különböző IPv4 és IPv6 felett. Az IPv4 datagram fejlécében definiálták az opciók mezőt, amelyben a forrás általi forgalomirányítást úgy definiálhatjuk, hogy az opciók mezőben megadunk egy fejlécet a és utána az állomások címét tartalmazó változó hosszúságú törzset. Ebben egymást követően IP címeket kell megadnunk, kezdve a forrás IP-vel, majd a routerek, csomópontok IP címe, melyeken a csomagunkat keresztül akarjuk vezérelni, végül pedig a cél IP. Hátránya hogy a routerek többsége nem támogatja ezt a lehetőséget, így ez csupán elvi lehetőség maradhat. IPv6-ban hasonlóan működik, előnye, hogy beépített lehetőség az IPv6ban, támogatott a routerek által, hátrány, hogy nagy overhead-et eredményez a kiterjesztett címeket nézve is. Payload kiterjesztés, vagy egyszerűsített tunneling A legkisebb overhead-et jelentő megoldás az általunk kidolgozott technika, az IP payload felhasználása. Ugyan ennek a megoldásnak nincs szabványos implementációja, a kedvező overhead-arány miatt mégis optimális lehet. A generált IP csomagot olyan plusz információkkal, és módosításokkal látjuk el, mely a csomagot a szerverhez juttatja, és ott információt nyújt a további feldolgozásához. 8

9 Az eredeti IP csomag két IP címet tartalmaz, a cél IP-t és a forrás IP-t. A rendszerben a kliens csomagjait ellátjuk egy harmadik IP címmel, és szükség esetén egy 2 bájtos kapcsolat azonosítóval is. Az eredeti célcímet a hasznos adat végéhez csatoljuk, és az IP fejlécben szereplő célcímhez a handover szerver címét írjuk. Ezzel elérhetjük hogy érvényes címet kapunk, és az útvonalválasztás során a szerverhez irányítódik a csomag, a hozzászúrt célcím figyelembevétele nélkül. Majd a szerver egyszerűen levágja a plusz terhet a csomagról, beilleszti azt a célcím helyére, a klienst azonosító, szerver interfészhez rendelt címet pedig a forráscím helyére és továbbküldi a tényleges célállomás felé. Visszaféle ugyanez történik fordítva. Kliens Alkalmazás Handover Kliens IP Layer: Handover Szerver Cél állomás 3. ábra: Payload extension Vannak olyan megoldások amelyek ötvözik a protokoll változtatás és harmadik entitás startégiákat. Ilyen például a Mobil Ipv6, amelynél lehetőség van közvetlen küldésre is a HomeAgent-en keresztül lezajlott kezdő kapcsolatfelvétel után. A következő fejezetekben röviden bemutatunk néhány létező megoldást Mobile IP - MIP Ezzel a technológiával más mérés és tárgy keretében már bizonyára találkozott a hallgató, ezért csak röviden írnánk róla: a mobil állomásnak (MN Mobile Node) van egy otthoni ügynöke (HA Home Agent). Ha a mobil állomás az otthoni linkjére csatlakozik, nem számít mobil állomásnak, IP címe az otthoni ügynök címe (HA Home Address). Ha eltávozik onnan és egy másik linkre csatlakozik, keres magának egy távoli ügynököt (FA Foreign 9

10 Agent), nála bejelentkezik, és megadja az otthoni ügynökének az IP címét. A távoli ügynök továbbítja a bejelentkezést az otthoni ügynök felé, majd az megerősítő üzenetet küld vissza az új címre (COA Care of Address). Ezután ha valaki csomagot küld a mobil állomásnak, akkor azt az otthoni címére küldi. Ott az otthoni ügynök becsomagolja, elküldi a távoli ügynöknek, az kicsomagolja és átadja a mobil állomásnak. A csomagolás miatt a kommunikációban résztvevő routerek ugyanúgy működnek, mint hagyományos kommunikáció kiszolgálásakor, a mobilitást kizárólag az otthoni ügynök, a távoli ügynök és a mobil állomás kezeli. A mobil állomás a csomagokat közvetlenül a címzettnek adja fel, tehát a mobil eszköztől a célállomás felé történő adatátvitel opcionálisan, közönséges módon, az otthoni ügynök kihagyásával is történhet (Mobile IPv6 ban ez nem opcionalitás, hanem alapkövetelmény). Az így kialakuló kétirányú kommunikációt háromszögelésnek nevezik. A távoli ügynökre nincs is mindig szükség, DHCP (Dynamic Host Configuration Protocol) protokoll segítségével a mobil állomás egy új linkre csatlakozva magának is kérhet IP címet, majd azzal bejelentkezhet az otthoni ügynökének, és a csomagolást is elvégezheti. Így komolyabb ugyan az elvárás a mobil eszköztől, de leegyszerűsödik a rendszer. A hierarchikus kiegészítés egy adott területen belüli mozgások elfedését használja fel a mobilitás kezelés hatékonyabbé tételéhez, illetve ezt az elvet kiterjesztheti a teljes hierarchikus topológiára Host Identity Protocol HIP HIP külön választja az azonosítási és a helyzetinformáció funkciókat egymástól. Ezzel a protocol stack változtatás csoportba tartozik. Egy új azonosítót, Host Identity-t (HI) vezet be, ami egy nyilvános-titkos kulcspár nyilvános kriptografikus kulcsa. A kulcspár titkos része azonosítja a host-ot a hálózaton. A szeparálás azt is eredményezi, hogy biztonságos úton megoldható a mobilitás és a multihoming. Tehát a HIP-ben azonosítóként a publikus kulcs szolgál. Amennyiben a host birtokolja a titkos kulcsot, ez bizonyítja, hogy valóban birtokolja azt az azonosítót, melyet a nyilvános kulcs reprezentál. A HI-t egy 128bit hosszú Host Identity Tag (HIT) reprezentál, melyet a HI-ból képzünk hash-eléssel. Mivel a HIT 128 bit hosszú, így egyből használható IPv6-os alkalmazásokhoz. 10

11 HIP alkalmazásakor a felsőbb rétegeket, ideértve az alkalmazásokat, nem látják többé az IP címet. Ehelyett HIT-et látják, mint címet. A lokációs információ el van rejtve az új rétegben, a Host Identity rétegben. A felsőbb rétegekből érkező csomagokban a cél cím helyett a HIT szerepel. Az átfordítás az új HI rétegben történik meg. A célcím átváltozik a leképzett IP címmé ugyanúgy, ahogy a forrás HIT átvált a forrás IP címre. Ez a leképzés a HIT és az IP között több módon történhet meg, például egy DNS jellegű szerver segítségével. A mobilitás a következőképpen valósul meg a HIP segítségével. A HIP esetében a lokációs információ és az azonosítás elkülönítésével a csomagok azonosítása és célba juttatása tisztán elkülönül egymástól. A host kap egy csomagot és a feladót a helyes kulcsról azonosítja, majd dekódolja a csomagot. Tehát az azonosítás szempontjából a csomagban található IP címnek nincs jelentősége. A HIP mobil csomópont mozog a hálózatban, változtatja hozzáférésének pontját. Szükségszerűen ezzel megváltozik az IP cím is, erről tájékoztatni kell a kapcsolódó hosztokat egy readdress (REA) csomagban.. Ez az információt az úgynevezett Forwarding Agent-nek (FA) is el lehet küldeni, ez hasonló a home-agent struktúrához. Ebben az esetben a mobil állomás új címe az FA-tól kérhető le. A HIP megoldás nagy előnye hogy beépített a biztonság, viszont a kulcs azonosítás miatt nagy számítási kapacitást igényel Szállítási réteg Mobilitásról a szállítási rétegnek tudnia kell, mivel tradicionálisan ennek a rétegnek a feladata a torlódásvédelem. Ahhoz pedig, hogy a torlódásvédelem hatékony legyen, adatok kellenek a két végpont közötti útról. (A mobilitás akármelyik rétegben legyen megvalósítva, a torlódásvédelemmel ellátott átviteli protokollokon mindenképpen változtatni kell) msctp mobile Stream Control Transmission Protocol Az SCTP protokollt arra tervezték, hogy TCP-t és esetleg még az UDP-t is leváltsa. Hasonlít a TCP-re, de jóval többre képes annál, mint például multistreaming és multihoming támogatása. Éppen a multihoming az az új tulajdonság, ami miatt az SCTP alkalmas lehet mobilitás kezelésére. 11

12 Egy host akkor multihomed, ha több hálózati rétegbeli címmel rendelkezik. Egy transzport protokoll pedig akkor támogatja a multi-homingot, ha egy transzport végponthoz több hálózati rétegbeli címet lehet hozzárendelni. A mobilitás esetében ez úgy van megvalósítva, hogy lehetőség nyílik arra, hogy a végpont megváltoztassa az IP címét miközben a transzport végpontvégpont kapcsolat nem szakad meg. Természetesen ennek dinamikusan kell megtörténnie. Ezért született meg az ADDIP (Dynamic Address Reconfiguration) kiegészítés az SCTP-hez, ami lehetővé teszi, hogy hozzáadjunk, elvegyünk és megváltoztassunk IP címeket egy aktív kapcsolat alatt. Az így kiegészített SCTP-t hívják Mobile SCTP-nek (msctp). Soft handover a következőképpen zajlik le: a mobil állomás adott IP címmel felépíti a SCTP kapcsolatot egy másik állomással, majd úgy dönt, hogy átmegy egy másik hálózatba. Az új hálózatban új IP címet kap. Ezt az új IP címet a mobil hozzáfűzi a már meglévő asszociációhoz és erről a kapcslatban lévő node-ot is értesíti. Ezek után a mobil az új IP címet jelöli meg elsődleges IP címnek és a régi IP címet törli az asszociációból. Ha a kapcsolat felépítése fordítva történik, akkor szükség van valamiféle harmadik entitásra (DNS, vagy agent), aki tudja a mobil eszköz aktuális elérhetőségét. Az SCTP egyik hiányossága, hogy a csomagvesztést torlódásként értelmez, és visszavesz a sebességből. Azaz vezetéknélküli környezetben gyakori csomagvesztés miatt az SCTP nagyon gyenge átvitelre képes csak Viszony réteg Hasonló előnyökkel rendelkezik mint a szállítási rétegbeli mobilitás, de a megvalósítása kevésbé bonyolult. Amennyiben a cím megváltozik, egyszerűen létrehoz egy új transzport kapcsolatot, és a régit megszünteti. Nem sok megoldás létezik a témában, egyik közülük a Pennsylvania-i egyetemen kidolgozott DHARMA (Distributed Home Agent for Robust Mobile Access), mely a MIP megoldás és viszonyréteg előnyeit ötvözi Alkalmazási réteg Az itt működő megoldások lényege hogy egy konkrét használt alkalmazáson belül kezelődik le a mobilitás. Legjellemzőbb példák erre a Session Initiation Protocol (SIP) protokollt használó multimédiás alkalmazások. 12

13 Session Initiation Protocol SIP A SIP egy aplikációs rétegbeli protocol, amit arra használnak hogy multimédiás sessionöket hozzanak létre unicast és multicast felhasználásával. A SIP entitásai a felhasználói ügynökök, a proxy szerverek és az átirányító szerverek. Egy felhasználó egy cím szerű azonosítóval rendelkezik. A SIP jó néhány metódust definiál: - INVITE : Meghív egy felhasználót, vagy felhasználókat egy session-be. Az üzenet törzse tárolja a session leírót, például az SDP-t (Session Description Protocol) felhasználva. A session leíró tartalmazza, hogy a felhasználó milyen címére küldjék a neki szánt streaming adatot, milyen audió, videó kodeket ismer, stb. - ACK: Visszaigazolás az INVITE kérésre. - BYE: Akkor küldik ezt a csomagot, amikor a hívást meg kívánják szakítani. - OPTIONS: Ezzel az üzenettel kérdezik le a szerver képességeit. - CANCEL: Megszakítja a folyamatban lévő kérést. - REGISTER: Regisztráció egy SIP szervernél. - REINVITE: Módosítja felépült kapcsolatát egy adott felhasználóval, például abban az esetben ha megváltozott az IP címe. Minden egyes új SIP tranzakciónak van egy egyedi hívás azonosítója, ami azonosítja a session-t. Ha a session-t módosítani kell, mert például egy új médiát szeretnék hozzáfűzni, akkor ugyanazt a hívás azonosítót használjuk egy inicializáló kérésben. Ezzel azt jelezzük, hogy a létező session-t szeretnénk módosítani. A SIP felhasználói ügynököknek két alapvető funkciója van: várja a bejövő SIP üzeneteket és SIP üzeneteket küld abban az esetben ha valamilyen bejövő üzenetre választ kell adnia. A SIP proxy szerver SIP üzeneteket továbbít domain név alapján. Az átírányító szerver viszont a felhasználó címét adja vissza, ahelyett hogy továbbítaná a SIP üzenetet a felhasználó felé. Mindez lehetővé teszi hogy skálázható rendszereket építhesünk. Mind az átírányító, mind a proxy szerver képes felhasználói regisztrációkat fogadni, amiben a felhasználó aktuális címe van megadva. A címet lehet lokálisan SIP szerveren tárolni, vagy pedig egy dedikált cím szerveren. Így lehetővé válik a mobilitás támogatása. 13

14 Kövessük végig egy SIP hívás lehetséges menetét. A hivó küld egy INVITE üzenetet, ami tartalmaz egy session leírást SDP-ben kifejezve. Az átirányító szerver az üzenetet megkapva konzultál egy cím szerverrel, hogy megtudja hova kell továbbítania a meghívást. Ez a válasz lehet egy újabb átirányító, egy proxy, vagy éppen már a hívott címe. A proxy szerver továbbítja az INVITE kérést a felhasználó felé, az átirányító szerver visszaadja a pontos címét a hívott félnek. Ha az INVITE kérés eléri a célját, akkor egy OK üzenetet kap vissza a kezdeményező fél, amit még egy ACK üzenettel nyugtáz. Ahhoz hogy az IP mobilitás megvalósuljon, abból a feltételezésből indulunk ki, hogy a mobil állomásnak van egy saját otthoni hálózata, ahol van egy SIP szerver, ami minden egyes alkalommal kap egy regisztrációs üzenetet a mobil állomástól, amikor az helyet változtat. Ez a megoldás hasonlít a home agent regisztrációhoz a MIP-nél, azonban fontos észrevenni, hogy itt nincs szükség arra, hogy a mobil állomásnak legyen egy fix IP címe az otthoni hálózatban. Ha a mobil állomás mozog egy session alatt, akkor egy REINVITE üzenetet kell küldenie a másik felhasználónak, akivel kommunikál. Ebben az üzenetben a hívás azonosító megegyezik az eredeti híváséval, az új címet pedig a kapcsolat mezőbe kell elhelyezni. Ebből tudja a másik fél, hogy ezentúl a mobil állomásnak szánt csomagokat erre az új címre kell küldeni. 5 Mobilitáskezelési algoritmusok, stratégiák a hálózatban A mobilitás megvalósításának fiatal történelmében már most sok-sok ismertebb és kevésbé ismert megoldás született, és előreláthatólag születni is fog. Ahhoz hogy egységesen tudjuk kezelni és esetleg összehasonlítani, modellezni a mobilitás menedzsment algoritmusokat, valamilyen szempont szerint érdemes csoportosítani. Attól függően, hogy milyen stratégiát alkalmaznak az egyes megoldások, négy nagy csoportba sorolhatjuk be őket. 1. Centralizált Ennél a struktúránál a mobil állomás mindig küld update üzeneteket egy központi management node-nak az aktuális elérhetőségéről. Mivel ez a központi node mindig tudja a mobil állomás elérhetőségét, ezért képes továbbítani a mobilnak szóló csomagokat (Mobile IP), vagy éppen meg tudja mondani a mobil állomás elérhetőségét (SIP). 14

15 Ezek a rendszerek ilyen szempontból egyszerűek, de nagy hálózati jelzés overhead-et eredményeznek. 2. Hierarchikus A központi, globális management-el ellentétben itt lokális management node-okat alkalmazunk, amik egy jól definiált területen belül kezelik a mobil mozgásást (Hierarchical Mobile IP). Ugyanúgy jelen van egy központi management node is, azonban az ötlet ott rejlik, hogy a helyzet frissitő információkat csak a központi node felé vezető régi út, és az új út metszéséig küldjük, az itt lévő lokális management node-nak. A megoldás előnye, hogy nem terheljük az egész hálózatot, azonban bonyolultabb strutktúrát eredményez, mint az előző. 3. Cellás típusú A mobilitás megoldására léteznek cellás megoldások. Ennek legismertebb típusa a Cellular IP (CIP), aminek alapötlete a GSM-ből jön. A lényege, hogy jól definiált paging területeket hozunk létre, amik több cellát fognak össze. A cellák között átjárás nem okoz IP cím váltást, a handover ilyen esetben alacsonyabb rétegben, általában az adatkapcsolati rétegben valósul meg. 4. Tracking A tracking megoldások lényege, hogy a handover végrehajtásának eredményeképpen megkapott új IP címet közvetlenül a régi hozzáférési csomóponttal közli a mobil, és nem szól feljebb a hierachiában. Így a neki szóló csomagokat az egyes access point-ok igyekeznek a mobil állomás után küldeni. Az azonban érzékelhető, hogy ha a mobil sokszor vált hálózatot, akkor hatalmas kerülőutat tehetnek meg a csomagok. Ennek optimalizálása érdekében, a mobil node x lépés után frissíti a központi agent-et. Több kutatás foglalkozik azzal, hogy meghatározza adott hálózati struktúrához, handover gyakorisághoz és mobilhoz fordulása gyakorisághoz az optimális x értéket. Két alcsoportja létezik ezeknek a megoldásoknak, attól függően hogy a visszaszólás a régi hozzáférési ponthoz hogyan történik meg. Wireless tracking-nek nevezzük, ha még a rádiós 15

16 interfészt, és wired tracking-nek, ha a hozzáférési pontok között levő hálózatot használja a mobil node. Az előbbire ismert példa az LTRACK, az utóbbira a Handoff-Aware Wireless Access Internet Infrastructure (HAWAII). 6 Mérés során használt eszközök (software + hardware) 6.1 Vertical handover megoldása és a tesztrendszer A tesztrendszerben a fejezetben leírt hálózati rétegbeli megoldás került implementálásra az 1. ábrán felüntetett protokoll stack változtatással. A kliens és szerver közötti kapcsolat megvalósítására a harmadik ábrán szemléletett egyszerűsített tunneling szolgál. A 4. és az 5. ábra jól szemlélteti a csomagok útját a klienstől a célállomásig és vissza. Alkalmazás Szállítás (TCP, UDP) Alkalmazás Szállítás (TCP, UDP) Alkalmazás Szállítás (TCP, UDP) Hálózat (IP) Címcsere/hozzáfűzés Csomagirányítás Címcsere Csomagazonosítás Hálózat (IP) Hálózat (IP) Adat kapcs. Adat kapcs. Adatkapcsolat Adatkapcsolat Fizikai Fizikai Fizikai Fizikai Mobil eszköz Handover Szerver Távoli hoszt 4. ábra: A csomagok útja a klienstől a távoli célállomásig Alkalmazás Szállítás (TCP, UDP) Alkalmazás Szállítás (TCP, UDP) Alkalmazás Szállítás (TCP, UDP) Hálózat (IP) Címcsere Csomagazonosítás Címcsere/hozzáfűzés Hálózat (IP) Hálózat (IP) Adat kapcs. Adat kapcs. Adatkapcsolat Adatkapcsolat Fizikai Fizikai Fizikai Fizikai Mobil eszköz Handover Szerver Távoli hoszt 5. ábra: A csomagok útja a távoli célállomástól a kliensig 16

17 A kliensoldali funkcionalitást egy NDIS driver szolgáltatja, amelyről bővebben a részben lesz szó. A szerver oldalon a megoldást a es részben leírt NTMF keretrendszer szolgáltatja. A tanszéki tesztrendszer felépítését, és az IP címek kiosztását az 6. ábra szemlélteti ábra: A tesztrendszer felépítése Jelszókiosztás Laptop(ok): Windows XP - Nincs jelszó Szerver(ek): Unix: Bejelentkezés a grafikus környezetbe: user: vhuser pass: vhuser Bejelentkezés rootként: user: root pass: VHserver 17

18 6.2 Kliens Hálózati beállítások A mobil kliens számítógépeken Windows XP operációs rendszer fut. Az alkalmazások felé mutatott állandó IP cím (virtuális IP cím) megvalósításához szükségünk van egy virtuális hálózati kártyára, amin be tudjuk állítani a kliens virtuális, az Interneten is érvényes címét. A mérés során az OpenVPN projekt virtuális hálózati kártyáját (TAP adapter) használjuk, amely már előre telepítve van mindkét mobil kliensen. A virtuális címek a következők: (mobil kliens B) és (mobil kliens A) (ezeknek a címeknek egyezniük kell a szervernek a tanszéki hálózat felé néző interfészére DHCP-n kiosztott IP címmel, lásd fejezet; A DHCP címkiosztás változása miatt elképzelhető, hogy a szerver nem az itt leírt címet kapja a hálózattól. A TAP adapter mindig azt a címet kapja, amit a szerver kapott DHCP-n!). A TAP adapteren be kell állítani a megfelelő címet ( XXX) a Windows hálózati beállításain keresztül (Vezérlőpult/Hálózati kapcsolatok/tap adapter tulajdonságai/tcp-ip beállítások). Alaphelyzetben a mobil klienseken két aktív hálózati kapcsolat van (egy vezetékes és egy vezeték nélküli), amelyek az 1. mérési feladat elvégzéséhez szükségesek. A virtuális adapter ekkor le van tiltva (Hálózati kapcsolatok ablak/tap adapteren jobb klikk/letiltás)! A további feladatokhoz szükséges a VH környezet beállítása az alaphelyzetből: - a mobil kliens LAN kábelét a szerverek alatt található labor switch-ből át kell rakni a Linksys WLAN routerbe, és a vezetékes hálózati interfészen be kell állítani a (1)51-es lokális címet (a laptopokra rá van írva, hogy milyen címet kell kapniuk!), a DNS és az alapértelmezett átjáró helyét üresen kell hagyni, - CSATLAKOZNI KELL a Linksys WLAN routerhez (vezetéknélküli hálózatok kezelőablakában kiválasztani a WLAN hálózatot + Csatlakozás ), majd a vezeték nélküli hálózati interfészen be kell állítani a (1)52-es címet (a Linksys WLAN router nem oszt címeket DHCP-n keresztül), a DNS és az alapértelmezett átjáró helyét üresen kell hagyni, - engedélyezni kell a TAP adaptert (Hálózati kapcsolatok ablak/tap adapteren jobb klikk/engedélyezés), 18

19 - a TAP adapteren az IP cím mellett a következő beállítások szükségesek: alhálózati maszk = alapértelmezett átjáró = <a TAP adapter IP címe> DNS = ; telepíteni kell a vertical handover drivert (Passthru driver, lásd ben) - a VH menedzsment alkalmazás segítségével el kell indítani a vertical handover szolgáltatást (lásd 6.2.3). Az alaphelyzet visszaállítása, amely a mérés végén kötelező: - be kell zárni a VH menedzsment alkalmazást, - le kell szedni a vertical handover drivert (Hálózati kapcsolatok ablakban tetszőleges hálózati interfész Tulajdonság ablakában ki kell választani a Passthru Driver-t és Uninstall) - a kábelt a Linksys WLAN router-ből átdugni a szerverek alatt található labor switch-be, és a vezetékes hálózati interfészen vissza kell állítani a DHCP használatát (Vezérlőpult/ Hálózati kapcsolatok/ Vezetékes hálózat tulajdonságai/tcp-ip beállítások), - vezeték nélküli hálózati interfészen vissza kell állítani a DHCP használatát (Vezérlőpult/ Hálózati kapcsolatok/ Vezetéknélküli hálózat tulajdonságai/tcp-ip beállítások), majd csatlakozni kell az mcl SSID-jű WLAN-hoz, - le kell tiltani a TAP adaptert (Hálózati kapcsolatok ablak/tap adapteren jobb klikk/letiltás). A mérés során kétféle handovert használunk. Az alaphelyzetben (1. feladat) két élő hálózati kapcsolat közötti hard handovert hajtunk végre, vertical handover támogatás nélkül. A további feladatokban (2.-4.) segítségül hívjuk a tanszéken elkészített vertical handover tesztrendszert, amelyben a hálózatok közötti váltást soft handoverrel valósítjuk meg. Az alaphelyzetben történő váltáshoz két egyszerű DOS batch szkriptet használunk: C:\VHmeres\activate_LAN.bat C:\VHmeres\activate_WLAN.bat 19

20 A szkriptek tanulmányozásával kiderül, hogy egyszerű routing metrika beállítást végeznek. Vagyis a hálózati interfészek (vezetékes és vezetéknélküli) prioritását változtatják meg, az alacsonyabb metrika érték nagyobb prioritást jelent. A legkisebb metrikájú kapcsolatot használja az operációs rendszer a hálózati kommunikációhoz Vertical handover driver A vertical handover tesztrendszer használatához szükséges a mérő laptopon a VH driver telepítése. Ez a driver gondoskodik a soft handoverről Felépítés A 4. és 5. ábrán látható és a fejezetben leírt működés megvalósítására Windows operációs rendszer alatt az adatkapcsolati rétegben elhelyezkedő NDIS (Network Driver Interface Specification) API nyújt lehetőséget. Az NDIS segítségével különböző feladatokat ellátó hálózati driverek készíthetők. A mérésen egy ún. NDIS intermediate drivert használunk, amely beépül a hálózati kártyák drivere és a hálózati protokollok (esetünkben a TCP/IP) közé (7. ábra). 7. ábra: Az NDIS intermediate driver elhelyezkedése a protokoll stack-ben 20