Informatika | Hálózatok » Simon-Nováczki - Mobilitás kezelés vezetéknélküli hálózatokban

Mobilitás kezelés vezetéknélküli hálózatokban Írta: Simon Vilmos és Nováczki Szabolcs Mobil Távközlési és Informatikai Laboratórium 1. A mobilitás kezelésének alapelvei A vezetéknélküli hozzáférést biztosító hálózatok az elmúlt évtizedben olyan széles körben elterjedtek, hogy manapság már a felhasználók egy jelentős hányada e hálózatok szolgáltatásait veszi igénybe. Ezért a szolgáltatók − felismerve a vezetéknélküli kommunikációban rejlő lehetőségeket − arra törekednek, hogy a mobil felhasználók számára is minőségi szolgáltatásokat nyújtsanak. Ennek egyik elengedhetetlen feltétele olyan mobilitás kezelő eljárások kifejlesztése, melyek zavartalan összeköttetést biztosítanak a felhasználók mozgása miatt bekövetkező változások hatásainak kezelése közben is. Sok, egymástól merőben eltérő megközelítést használó megoldás született, mely többé-kevésbé biztosítja a mobilitás

transzparens kezelését. Bár ezek a módszerek részleteikben különböznek, mégis találhatunk olyan közös tulajdonságokat, melyeket felismerve meghatározhatók a mobilitás kezelésének alapelvei. A mobilitás kezelése alapvetően két feladat megvalósítását jelenti (1. ábra) Egyrészt szükség van a folyamatosan mozgó mobil csomópontok helyzetének követésére, másrészt meg kell oldani az ún. hívásátadás (handover) kezelését, azaz a felhasználók kapcsolatainak karbantartását, miközben a hálózat egyik kapcsolódási pontjától egy másikhoz vándorolnak. Az előbbit helyzet-nyilvántartásnak (Location Management), az utóbbit pedig hívásátadáskezelésnek (Handover Management) hívjuk. 1. ábra A mobilitás kezelés felosztása A helyzet-nyilvántartásnak két feladatot kell megoldania. A mobil csomópontok követését, azaz a helyzet-frissítést (Location Update), valamint ezen mobil egységek megkeresését (paging), amikor nekik

címzett adatok átvitelére van szükség. A keresésre azért lehet szükség, mert a helyzet-frissítés nem feltétlenül követi teljesen pontosan a mobilok mozgását, ezért az éppen nem kommunikáló csomópontokat meg kell találni, ha üzeneteket akarunk nekik továbbítani. Erről a későbbiekben részletesen lesz szó Egy cellás hálózatban a hívásátadások két típusát különböztetjük meg, az egyik akkor következik be, amikor a felhasználó nem hagyja el egy adott cella lefedettségi területét, de megváltoztatja az eddig használt rádiós csatornát, ezáltal csökkentve csatornák közötti interferenciát. Ezeket a cellán belüli handovereket valamilyen második (link) réteg béli protokoll kezeli. Sokkal több figyelmet érdemel az a szituáció, amikor egy mobil csomópont cellák között vándorol. Bár ebben az esetben is elengedhetetlen a link réteg támogatása, önmagában ez nem elég a probléma megoldásához. Ennek oka, hogy a

cellaváltáskor általában megváltozik a csomópont IP címe. Ez viszont befolyásolja a hálózati réteg működését, amit már nem lehet a link rétegben megoldani. Szükség van valamelyik felsőbb réteg támogatására is. Kézenfekvő megoldás, ha a hálózati réteget használjuk az ilyen típusú handoverek kezelésére, de erre a feladatra szinte bármelyik felsőbb réteg alkalmas lehet. Bármelyik rétegben is oldjuk meg a cellák közötti handoverek kezelését egy további fontos tulajdonságra érdemes tekintettel lenni: A vezetéknélküli hálózatok általában földrajzilag nagy területeket fednek le, mely további alhálózatokra, tartományokra (domain) osztható. Ahogy a 2 ábran is látható, egy ilyen hálózatban a hívásátadás (handover) két alapvető módon valósulhat meg. 2. ábra Handover-típusok Az egyik az intra-domain handover, ami egy jól definiált területen (ún.: mikromobilitási domainen) 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 mozog a mobil csomópont. Ezt inter-domain handovernek nevezünk Ezt már valamilyen makromobilitási protokoll kezeli. A mikromobilitás algoritmusainak egy fontos célja, hogy minél gyorsabban próbálják lebonyolítani az intra-domain handovereket, ezzel növelve az elérhető teljesítményt, a hálózat kihasználásának hatásfokát, és minimalizálva a felhasználói adatfolyamok megszakításának időtartamát. Ezek azonban általában nem skálázható megoldások, így csak korlátozott számú felhasználó kezelésére képesek. Erre nyújtanak megoldást a makromobilitás kezelő protokollok, melyek a felhasználók számától függő, skálázható megoldást adnak. Ezek azonban nem képesek olyan gyorsan kezelni a cellaváltásokat, mint a mikromobilitási protokollok. Ezért a mobil csomópontok kezelését általában olyan hierarchikus

módszerekkel oldják meg, melyekben együtt alkalmazzák a makro-, és a mikromobilitás kezelő protokollokat. Így ezek egymást kiegészítve, hatékony megoldást nyújtanak a felhasználói mobilitásra. A mikromobilitási protokollok gyorsasága a cellaváltások lokális kezelésében rejlik. A felhasználók domainen belüli mozgását elfedik a makromobilitási protokoll elől, tehát nincs szükség annak bevonására minden cellaváltásnál. A regisztrációs és a jelzési üzenetek − megvalósítástól függően − legfeljebb a domain gyökér routeréig kell eljutniuk, a gyökér router pedig ezeket már gyorsan fel tudja dolgozni. Tehát a gyorsaság a kis terület, a limitált számú felhasználó, és a makromobilitási protokoll kihagyásának következménye. Bár a fenti alapkoncepciókat mindegyik protokoll figyelembe veszi, azok megoldására azonban eltérő módszereket adnak, ezért a mikromobilitási protokoll tervezeteket működésük és

alapgondolatuk szerint néhány nagy csoportba lehet szervezni: ƒ Proxy Agent Architectures (PAA): Hierarchikus szervezésű, ügynök alapú gyorsítás. Ezek a megoldások az adott makromobilitási protokoll ötletét terjesztik ki többszintű, hierarchikusan szervezett mobil ágensek használatával. A rendszer célja az ágensek működésének gyorsítása. A mobil terminál a hierarchia legalsó szintjén elhelyezkedő helyi ágensnél regisztrálja magát. Minden ágens a felette elhelyezkedő ágensnél regisztrálja a mobil terminált, egészen addig, amíg a regisztráció el nem jut a domain gyökér csomópontjáig. Ebben a rendszerben, a terminál mozgása során bekövetkező IP címváltozásokat kezelő üzenetek nem terhelik az egész hálózatot, hanem lokálisan, az adott domainen belül történik a kezelésük. Ebbe a csoportba tartozik például a Hierarchical Mobile IPv6 (HMIPv6), és a Regional Registration (RegRegv6), de mint ahogy később látni fogjuk, a

HIP protokollt kiegészítő, általam tervezett megoldás is ezen a koncepción alapul. ƒ Locally Enhanced Routing Schemes (LERS): Ezek a megoldások a mikromobilitási domainen belül egy módosított routing algoritmust használnak és tipikusan a hálózati rétegben, az IP (IPv4 vagy IPv6) protokollt kiegészítve működnek. Ezen a csoportot tovább oszthatjuk, az alkalmazott routing protokoll szerint: o Az ún. Per Host Forwarding megoldások egy domainen belül speciális útvonal-nyilvántartási protokollt használnak, hogy létrehozzanak a mobil csomópontokra vonatkozó, adott idő után elévülő (soft-state) bejegyzéseket az útvonalválasztók routing tábláiban. Mivel a bejegyzések idővel elévülnek, periodikus frissítés szükséges. A domain egy gateway router (GW) segítségével kapcsolódik a vezetékes internethez, és kívülről egy alhálózatnak látszik. A GW végzi el a protokoll konverziót az IP, és az alkalmazott mikromobilitás

protokoll között. E csoportba tartozik a két legismertebb mikromobilitás protokoll, a Cellular IP (CIP) és a HAWAII. o A Mobile Ad-hoc Network (MANET) alapú rendszerek tipikusan valamilyen mobilitás kezeléssel kiegészített ad-hoc routing protokollt (Ad-hoc On-demand Distance Vector – AODV, Dynamic Source Routing – DSR) használnak a mikromobilitás kezelésére. o A multicast alapú megoldások valamilyen multicast módszert alkalmazva keresik meg a mobil csomópontokat a hálózatban. A mikromobilitási protokolloknak, szintén a mikromobilitási domainen belüli működésük alapján, de az előzőektől részben eltérő szempontokat figyelembe véve, további két csoportosítása képzelhető el: ƒ Proaktív vagy reaktív: Egy proaktív protokoll esetén a hálózat mindig ismeri a mobil csomópont tartózkodási helyét. Ezt folyamatosan küldött, helyzetfrissítő üzenetekkel érik el Ezzel ellentétben, egy reaktív protokoll esetén a mobil

csomópontot meg kell keresni (paging alkalmazása), mikor adatot szeretnénk hozzá eljuttatni. Ezt broadcast (üzenetszórást) vagy multicast üzenetek kiküldésével lehetséges. A proaktív protokoll a sok frissítő üzenet miatt nagy adatforgalommal terheli a hálózatot, de azonnal irányítani tudja a beérkező adatot a megcímzett mobil felhasználó felé. A reaktív protokoll viszont szinte alig, vagy egyáltalán nem terheli a hálózatot jelzés üzenetekkel, amikor nincs adatforgalom, viszont nagyméretű – broadcast vagy multicast – keresést igényel az adatátvitel kezdetekor. Vannak olyan megoldások, amelyek a proaktív és reaktív előnyeit egyesítve, azok hátrányait kiküszöbölve működnek. E protokollok proaktív módon viselkednek az aktív mobil csomópontok kezelését illetően, és a reaktív tulajdonságokat mutatnak, amikor a tétlen készülékek helyzetének nyilvántartásáról van szó. ƒ Gateway centrikus vagy hop-by-hop. A gateway

centrikus tulajdonság azt jelenti, hogy a gateway router pontosan tudja, hol helyezkedik el a mobil felhasználó, és így közvetlenül hozzá küldi a csomagokat. Hop-by-hop esetben mindig csak azt tudják a routerek, hogy a velük kapcsolatban lévő routerek közül melyiknek kell küldeni egy adott mobil csomópontnak címzett csomagot. Az előzőeket összefoglalva, a 3. ábra mutatja néhány mikromobilitási protokoll besorolását. Ez az ábra a dolgozat egy későbbi fejezetében is előfordul, kiegészülve az általam javasolt HIP alapú mikromobilitás kezelő megoldás beillesztésével. 3. ábra A mikromobilitási protokollok csoportosítása Látható, hogy a mobilitás kezelése igencsak összetett probléma. Nagy sok szempont figyelembevételére van szükség, melyek együttes teljesítése nem is megoldható. 2. Mobilitás kezelés a TCP/IP stack különböző rétegeiben 2.1 Melyik rétegben kezeljük a mobilitást? A mobilitás kezelése a TCP/IP stack

különböző rétegeiben lehetséges. Ugyan minden megközelítés alapvető feltétele egy, az adatkapcsolati (link) rétegben működő megoldás, de ez önmagában nem segít sem a felsőbb rétegek kapcsolatainak fenntartásában, sem a helyzetnyilvántartásban, ha a mobilcsomópontok különböző adminisztráció alá tartozó hálózatrészek között mozognak. A hálózati rétegben működő megoldások bár hatékonyak a fenti problémák megoldásában, mégis számos korlátja van gyakorlati alkalmazásuknak. Ezen hátrányok kiküszöbölhetők, ha a mobilitás kezelését egy felsőbb rétegre bízzuk. Ígéretesek a szállítási, a viszony és az alkalmazás réteg béli megoldások annak ellenére, hogy alkalmazásuk feltétele olyan, jól működő protokollok módosítása, mint például a Transmission Control Protocol (TCP). 2.2 Makromobilitás-kezelő protokollok Ebben a fejezetben néhány makromobilitás kezelő protokoll kerül bemutatásra. Meg vannak

különböztetve aszerint is hogy melyik rétegben oldják meg a mobilitás kezelését. 2.21 M O B I L IP – HÁLÓZATI RÉTEG Az IP protokoll 4-es verziójának (IPv4) tervezésekor egyáltalán nem gondoltak a mobilitás kezelésére. Azonban, mivel még napjainkban is az IPv4 az egyik legelterjedtebb hálózati protokoll, szükség volt úgy kiegészíteni az alap-specifikációt, hogy képes legyen az egyre szélesebb körben elterjedő mobil csomópontok (Mobile Node, MN) kezelésére. Ezért fejlesztették ki az IPv4 számára a Mobil IP-ként emlegetett kiegészítést, mely már képes a mobilitás kezelésére. Az IPv4 alap-specifikációját több tulajdonsága is korlátozta a mobilitás kezelésében, azonban a legfontosabb ezek közül a protokollban használt hierarchikus címzési rendszer, melyben az IP címeknek kettős szerep jutott. Egyrészt globális azonosítóként szolgálnak a hálózathoz kapcsolódó csomópontok megkülönböztetésére, másrészt

meghatározzák a hozzájuk rendelt csomópontok helyzetét a hálózatban. E két funkció egymásnak ellentmondó feltételeket támaszt, ha egyszerre akarunk egyszerű útvonalválsztást (routing) és mobilitáskezelést megvalósítani. A Mobil IP ezt a problémát úgy oldja meg, hogy lehetőséget ad egy MN-nak, hogy két IP címet használjon. Egyet a csomópont azonosítására (otthoni cím, Home Address), egy másikat pedig arra, hogy a mobil csomópontnak szánt csomagok eljuthassanak rendeltetési helyükre, tehát útvonalválasztásra (közvetett cím, Care-of-Address). Az otthoni cím egy olyan, viszonylag hosszú életű IP cím, amely az otthoni hálózatában (Home Network) azonosítja a mobil csomópontot. A MN ezt a címet használja az általa küldött IP datagrammok forrás-címeként. Ha a MN elhagyja az otthoni hálózatát, akkor kap egy közvetett IP címet, amely a MN aktuális kapcsolódási pontját adja meg. A működéshez a két IP címen kívül

szükség van két speciális hálózati entitásra is. Az egyik az otthoni ügynök (Home Agent, HA). Ez egy olyan router a MN otthoni hálózatában, amely továbbítja a MNnak küldött csomagokat a MN aktuális kapcsolódási helyére, azaz az aktuális közvetett címre, valamint karbantartja a MN két IP címe közötti összerendelést. A másik szükséges hálózati entitás az ún. idegen ügynök (Foreign Agent), amely egy router a MN által meglátogatott (idegen) hálózatban, és azért felelős, hogy az otthoni ügynökkel együttműködve eljuttassa a MN-nak küldött csomagokat a megfelelő helyre az idegen hálózaton belül. A protokoll működése, melynek főbb lépéseit a 4. ábra mutatja, röviden a következő A különböző ügynökök ügynök-hirdetési üzenetekkel (Agent Advertisement) ismertetik magukat a saját hálózatukban lévő többi csomóponttal. Ha egy MN kap egy ilyen üzenetet, akkor az alapján el tudja dönteni, hogy az otthoni vagy egy

idegen hálózatban tartózkodik-e. Ha az otthoni hálózatban van, akkor működése nem különbözik az IP protokoll alap-specifikációjában leírtaktól. Abban az esetben, ha a MN egy idegen hálózatban van, akkor szerez egy megfelelő közvetett (ideiglenes) címet, melyet aztán jelez az otthoni ügynökének, továbbá jelez e cím minden egyes megváltozásakor. A MN-nak küldött csomagokat (1) az otthoni hálózatban az otthoni ügynök elfogja, és egy un. IP alagút (tunnel) segítségével továbbítja a MN aktuális közvetett címére (2, 3). A MN által küldött csomagok (4, 5) rendszerint a protokoll alapspecifikációjában leírtak szerint továbbítódnak, azaz nem az otthoni ügynökön keresztül, hanem közvetlenül a kommunikációs partnerek (Correspondent Node, CN) felé. 4. ábra A Mobil IP és a háromszög probléma Bár a fent leírt mechanizmus megvalósítja a célt, azaz a mobil csomópontok kezelését, mégsem hatékony, mert az ún. háromszög

probléma kialakulásához vezet Az 4 ábra narancsszínű nyilai jelzik, hogy a MN és a CN között csak az egyik irányban közvetlen a kommunikáció. A CN a MN-nak címzett csomagjait először mindig az otthoni ügynöknek küldi és nem közvetlenül a MN-nak. Ez a hálózati erőforrások kedvezőtlen kihasználásához vezet. Ilyen kedvezőtlen hatások többek között, hogy nő a hálózat terhelése és a csomagok kézbesítéséhez szükséges idő, különösen akkor, ha CN közel helyezkedik el a MN-hoz. Ezen egy újabb kiegészítéssel, az ún. útvonal optimalizálással (route optimization) lehetett javítani Ennek lényege, hogy a MN kommunikációs partnerei is naprakész információval rendelkeznek a MN aktuális közvetett címéről, így a MN-nak szánt csomagok közvetlenül küldhetők, az otthoni ügynök kihagyásával. A megoldás hátránya, hogy változtatásokat kell végrehajtani az IP protokoll alap-specifikációja szerint működő, nem mobil

kommunikációs partnerekben is. Az eddigiekből látható, hogy az IPv4 és kiegészítéseként a Mobil IP protokoll képes a mobil csomópontok kezelésére, azonban a technika fejlődésével az IPv4 egyre több hiányossága került felszínre: olyan új funkciók váltak szükségessé, amelyek az IPv4 bevezetésekor még értelemszerűen fel sem merültek. A fő probléma, hogy a szabadon kiosztható IP címek előbb, vagy utóbb elfogynak, és így már nem lehet további csomópontokat az IP hálózatokhoz csatlakoztatni. Az IPv4 további hátránya, hogy címzési rendszeréből következően a routerek-nek több ezer bejegyzést tartalmazó routing táblákat kell fenntartaniuk, ezzel növelve a torlódás és csomagvesztés lehetőségét. Többek között ez vezetett egy új Internet Protokoll, az IPv6 létrejöttéhez. Az új protokoll kifejlesztésénél már a kezdetektől figyelembe vettek számos, korábban lényegtelennek tartott paramétert és szolgáltatást,

amiket a protokoll integráns részévé tettek (többek között a mobilitás kezelését), és ami legalább ennyire fontos, számos szükségtelen funkciót kiiktattak. A következő alfejezet mutatja be az IPv6 legfontosabb mobilitáskezeléssel kapcsolatos tulajdonságait 2.22 M O B I L IP V 6 (MIP V 6) – HÁLÓZATI RÉTEG A Mobil IP IPv6-os és IPv4-es megvalósítása közt sok közös tulajdonság van, de nem teljesen egyeznek meg. Míg az IPv4 külön UDP csomagokat használ a regisztrációhoz, addig az IPv6 a jelzésrendszert az IP fejléc kiterjesztésébe integrálva tartalmazza. Az IPv6 esetén a mobil csomópont címe egyszerűen előállítható: elég hozzá ismerni az idegen hálózat címét és az eszközünk MAC címét. Ezen kívül, az IPv6-ban a címtár betelése miatt sem kell aggódni, mivel ez a protokoll 128 bites címeket használ, szemben az IPv4 32 bites címeivel. Az IPv6 esetén nincs szükség idegen ügynökre sem, mivel a Care-of-Address (idegen

hálózatban használt ideiglenes cím) mindig a mobil csomóponthoz kapcsolódik. További nagyon fontos tulajdonság, hogy a MIPv6-ban nem jelenik meg a MIP-ben tapasztalható háromszög probléma, mivel a protokoll lehetőséget ad arra, hogy a mobil csomópontok ne csak az Otthoni Ügynökükkel, hanem kommunikációs partnereikkel is közölhessék aktuális kötéseiket (binding). A mobilitás kezelését segíti néhány ICMPv6 (Internet Control Message Protocol az IPv6 számára) üzenet is. Ilyen a Router Advertisement (router hirdetés), Router Solicitation (router kérés), Address Auto-configuration (cím automatikus konfiguráció), Neighbour Discovery (szomszéd felderítés). Egy mobil eszköz mozgása során több különböző hálózatban megfordulhat. A hálózatot a router hirdetésekben lévő hálózati azonosító alapján azonosítja Ha a mobil eszköz nem akar várni a soron következő router hirdetésre, maga is kezdhet router felderítő üzenetet,

amiben megkéri a környező routereket, hogy kezdjenek el hirdetni. A hálózaton lévő routerek közül a mobil csomópont kiválaszt egyet, és egészen addig őt tartja alapértelmezettnek, amíg elérhető. Az ideiglenes címet az idegen hálózatban kétféleképpen lehet kérni. Az egyik a stateful címkonfiguráció, ilyenkor a címet egy Dynamic Host Configuration Protocol (DHCP) szervertől kapjuk. A másik a stateless címkonfiguráció, ilyenkor a címet a routerektől kapott hálózat címből (prefix) és egy egyedi azonosítóból állítjuk elő. Ha egy idegen hálózatban tartózkodunk, a nekünk küldött üzeneteket az otthoni ügynöknek kell megkapnia. Ehhez több, a Mobile IPv6-ban megvalósított üzenetet létezik Ilyen a Binding Update (Kötési Frissítés) üzenet, ami tartalmazza az idegen hálózatban tartózkodó mobil egységünk új ideiglenes címét. Ezt el kell juttatni az otthoni ügynöknek és az összes olyan csomópontnak, akivel épp

kommunikálunk. Ha egy csomópont egy MN-tal akar kommunikálni, először az otthoni IP címünkre küld csomagot, amit az otthoni ügynökünk kap meg. Miután az otthoni ügynökünk ismeri a MN ideiglenes címét, (hisz erről folyamatosan értesíti) a MN után küldi ezt a csomagot. Miután ez a csomag tartalmazza az eredeti küldő címét, a MN-nak lehetősége van arra, hogy egy Binding Update üzenettel értesítse partnerét az új ideiglenes címről. Ezután a partner már közvetlenül tud vele kommunikálni. Ha a MN bármikor átlép a kommunikáció során egy másik idegen hálózatba, ahol azonnal új ideiglenes címet kap. Ekkor egy Binding Update üzenetben értesíti a kommunikációs partnert erről az új címről, így nem szűnik meg a kapcsolat. Amikor a MN visszatér az otthoni hálózatba, értesítenie kell az otthoni ügynököt, hogy ne kapja el ezután a neki szóló üzeneteket, hisz ilyenkor újra az eredeti IP címével kommunikál. A következő

fontos üzenet a Binding Acknowledgement, ami a csomópontok válasza a Binding Update üzenetre. Ez lehet elfogadás, de lehet elutasítás is Minden Binding Update üzenet tartalmaz egy időkorlátot is, ami jelzi, hogy meddig lesz még használható az ideiglenes cím. Ha ez lejár, újabb Binding Update üzenet kell, mert a velünk kommunikáló csomópontok lejártnak veszik az ideiglenes címünket. Ha közeleg a cím lejárásának az ideje, egy Binding Request üzenettel új Binding Update üzenetet kérhetnek a velünk kommunikáló csomópontok. 2.23 H O S T I D E N T I T Y P R OT O C O L (HIP) – 35 RÉTEG A Host Identity Protocol legfontosabb tulajdonsága, hogy szétválasztja az IP címek kettős funkcióját, azonban emellett hatékonyan oldja meg a biztonságos kommunikáció és a mobilitás-kezelés feladatait is. A HIP protokollban a csomópontok azonosítása az ún állomás-azonosítók (Host Identifier, HI) feladata, melyek változatlanok a csomópontok

mozgásától függetlenül. Tehát − habár a hálózatváltások során az IP cím megváltozik − a HI változatlan marad. Minden olyan csomópont, amely a HIP protokollt alkalmazza, rendelkezik egy aszimmetrikus kulcs-párral, melynek publikus része a csomóponthoz rendelt HI. A HI-k e tulajdonsága teszi lehetővé, hogy a HIP protokoll a csomópontok azonosításán túl, erős biztonsági kapcsolat létrehozására is alkalmas legyen két, egymással kommunikáló csomópont között. A protokoll segítségével létrehozható egy IPsec alapú biztonsági összerendelés (Security Association). Ehhez azonban szükség volt egy olyan mechanizmus beépítésére, amellyel a kapcsolat felépítéséhez szükséges paramétereket a kommunikálni kívánó csomópontok megoszthatják egymással. Ez az ún alap-kulcscsere (Base Exchange, BE) mechanizmus. Az eddigiekből viszont nem derül ki, hogy miért van szükség egy új internet architektúra bevezetésére. Ha azonban

végiggondoljuk a jelenlegi rendszer működését, világossá válik a változás szükségessége. A jelenlegi Internet a csomagokat annak a csomópontnak továbbítja, amelyet a csomag IP fejlécében jelzett cél IP cím azonosít. A HIP protokoll használatával azonban a csomópontokat a hozzájuk rendelt HI azonosítja. A csomagok irányítása továbbra is az IP címek által hordozott információ alapján történik, de amikor megérkeznek rendeltetési helyükre, akkor a kezelésük már a megfelelő HI-k alapján megy végbe. Ez a tulajdonság mutatja meg a leginkább, hogy a kommunikáló végpontokban a TCP/IP stack átalakításra szorul, mégis további megfontolások szükségesek, mielőtt rátérnénk az új stack ismertetésére. 2.24 S T R E A M C O N T R O L T R A N S M I S S I O N P R O T O C O L (SCTP) – TRANSZPORT RÉTEG A Stream Control Transmission Protocol egy, az IETF által kifejlesztett transzport protokoll. Azért tervezték, hogy leváltson olyan

ma működő protokollokat, mint a TCP és az UDP. Az SCTP a TCP-hez hasonlóan megbízható kapcsolatok létrehozását teszi lehetővé, de további szolgáltatásokat is nyújt. A legfontosabbak ezek közül a multi-sreaming és a multihoming funkciók megjelenése Az utóbbi lehetőség teszi a protokollt alkalmassá a mobilitás kezelésére anélkül, hogy speciális hálózati elemek (Home Agent, Foreign Agent) telepítésére lenne szükség. A multi-homing tulajdonság azt jelenti, hogy egy csomópont több aktív IP címmel rendelkezhet párhuzamosan. Ez egy transzport protokoll szemszögéből azt jelenti, hogy képes egy csomóponthoz több transzport réteg-béli cím hozzárendelésére. Ezt az SCTP támogatja, továbbá a protokoll lehetőséget ad az IP címek megváltoztatására is úgy, hogy ez ne befolyásolja a már létező kapcsolatokat. Az SCTP-ből azonban hiányzott az a funkció, ami az IP címek megváltozásából adódó konfigurációs változásokat

dinamikusan kezelné. Ezt a hiányosságot pótolja a Dynamic Address Reconfiguration (ADDIP) nevet viselő kiegészítés, amely arra ad lehetőséget, hogy a protokoll aktív kommunikáció közben változtassa meg a kapcsolathoz tartozó IP címet, esetleg töröljön, vagy hozzáadjon további címeket. Az ADDIPvel kiegészített protokollt nevezik mobil SCTP-nek (mSCTP) és transzparensen handover kezelést tesz lehetővé az IP hálózatok között mozgó mobil csomópontok számára. Amikor két csomópont kiépít egy SCTP kapcsolatot, akkor legalább egy, de multihoming szituációban akár több transzport réteg-béli címet (IP cím – port párok) definiálnak. Ezek a címek adják az adatfolyamok végpontjait. Az SCTP minden IP címet úgy kezel, mint egy adott csomópont különböző elérési útvonalait. Egy SCTP kapcsolat a lehetséges IP címek közül kiválaszt egyet, amely az elsődleges kommunikációs útvonalat azonosítja. Ez a cím változtatható meg

tetszőlegesen és dinamikusan az mSCTP-vel, az ADDIP kiegészítést használva. 2.25 S E S S I O N I N I T I A T I O N P R O T O C O L (SIP) – ALKALMAZÁSI RÉTEG A SIP protokoll napjaink egyre szélesebb körben alkalmazott protokollja multimédiás és telefon alkalmazások jelzésüzeneteinek szállítására az Interneten. A protokoll mobilitáskezelő kiegészítése ugyanezeket a szolgáltatásokat teszi elérhetővé vezetéknélküli környezetben működő mobil állomások számára. A megoldás egyaránt támogatja a valósidejű és nem valósidejű kommunikációt folytató alkalmazások működésének zavartalanságát mobil csomópontok részére. A SIP mobilitás kezelés nem foglalkozik az egyes cellák közötti handoverek kezelésével, azt a link rétegre bízza. A domainek és az alhálózatok közötti váltások karbantartása a SIP feladata. A SIP a felhasználókat és a közöttük létrejövő kapcsolatokat egyaránt egyedi azonosítókkal látja el.

A SIP csomópontoknak lehetősége van arra, hogy azonosítójukat egy speciális hálózati entitásánál (SIP proxy szerver) regisztrálják. A többi SIP felhasználó ezen a szerveren keresztül veheti fel a kapcsolatot egy mobilcsomóponttal. A proxy szerver lényegében egy IPv6 home agent az alkalmazási rétegben. A csomópontok IP cím változáskor frissítik a proxy szervernél tett regisztrációjukat, és ugyanezt megtehetik kommunikációs partnereikkel is. 2.26 Ö S S Z E F O G L A L Á S Látható, hogy a globális mobilitás kezelése a TCP/IP protokoll stack szinte bármelyik rétegében megoldható. Mivel mindegyik megoldás mutat előnyös és hátrányos tulajdonságot, ezért még nem eldöntött kérdés, hogy a jövő hálózataiban melyik megoldást fogják alkalmazni a globális mobilitás kezelésére. 2.3 Mikromobilitás-kezelő protokollok Ebben a fejezetben néhány fontosabb mikromobilitás kezelő protokoll bemutatásával szeretném

érzékeltetni, hogy a lokális mobilitás kezelés megoldására milyen sok különböző mechanizmus alkalmas. Ezek a protokollok általában a hálózati rétegben működnek, és az IPv4 vagy az IPv6 protokollokat egészítik ki lokális mobilitás kezelő funkcióval. 2.31 C E L L U L A R IP (CIP) A Cellular IP (CIP) protokoll egy Internet Engineering Task Force (IETF) előterjesztés, amelyet a Columbia egyetem és az Ericsson kutatói közösen fejlesztettek ki. Működéséhez, a mobil csomópontoknak a Mobil IP támogatása mellett implementálniuk kell a CIP protokollt is. A CIP egy vezeték nélküli IP hozzáférési hálózatot ír le, amely gyorsan mozgó mobil készülékek kiszolgálására alkalmas. Ez a szolgáltatás csak egy földrajzilag korlátozott méretű területen érhető el. Minden egyes aktívan kommunikáló mobil készülék, minden egyes handovert követően köteles értesíteni a hálózatot egy frissítési üzenet (Route Update) elküldésével. A

korlátozott méretű terület ellenére adódhat olyan helyzet a gyakori handovereknek köszönhetően, amikor a hálózat terhelése kritikussá válik a sok jelzésüzenet miatt. Az így keletkező forgalomtöbblet kezelése jelentős problémát okoz Ezért a CIP rendszerben a mobil csomópont csak akkor köteles mozgásáról információt küldeni, ha éppen aktív működési állapotban van. Amennyiben inaktív állapotban van, akkor nem kell minden egyes handover tényét jeleznie a hálózatnak, azonban ebben az esetben a helyzete csak közelítőleg határozható meg, a ritkább jelzések miatt. Tétlen készülék esetében a hívás létrehozása a készülék megkeresésével kezdődik (paging), amely meghatározott számú cellát (Paging Area) foglal magában. Ez teszi lehetővé, hogy a CIP hálózatok az ilyen passzív összeköttetésekkel képesek túlterhelés nélkül igen nagyszámú mobil csomópont kezelésére. Egy CIP hálózat (CIP domain) fa struktúra

szerint épül fel (5. ábra) A bázisállomások helyezkednek el a leveleken, a routerek képezik a közbenső csomópontokat és a gateway-ben futnak össze az ágak. A bázisállomás rádiós interfészen keresztül vezeték nélküli hozzáférési pontot biztosít a mobil csomópontok számára. A CIP hálózat a gateway routeren keresztül csatlakozik az Internethez. Egy ilyen domainben a megjelenő mobilok otthoni ügynöküknél Care-of-Address-ként a gateway IP címét fogják regisztrálni. A CIP domainen belül pedig az otthoni címükkel azonosíthatók. A CIP és a Mobil IP együttműködését szemlélteti az 5 ábra A cellás IP hálózatban a gateway a szomszédossági kapcsolatok feltérképezése végett ún. Beacon Broadcast üzeneteket küld az alatta elhelyezkedő bázisállomások felé A bázisállomások rögzítik, hogy mely interfészen keresztül kapták a jelet, és ezen interfész felé fogják továbbítani az uplink (felfelé menő) csomagokat a gateway

irányába. Ugyanilyen módon a bázisállomások is kibocsátanak Beacon Broadcast jeleket. Ezek alapján a végberendezések (mobil csomópontok) is regisztrálják az éppen hozzájuk tartozó állomást. A CIP két párhuzamos cache rendszert használ (Routing Cache és Paging Cache). Mindkettő a csomópontok elhelyezkedésével kapcsolatos információkat tárolja. A két rendszer alapvetően hasonló módon működik. Kombinálva használatukat, hatékonyabban oldható meg a routing és a handover, mintha csak egy cache-t használna a hálózat. Minden egyes router fenntart egy Routing Cache-t. Ha egy Routing Cache-t fenntartó router valamelyik interfészén adatcsomagot fogad, akkor tárolja a saját Routing Cache-ében a forrás hoszt IP címét és az interfész azonosítóját, amelyen a csomag érkezett. Ezt a rendszer által specifikált ideig tárolja. Amennyiben ugyanattól a csomóponttól és ugyanazon az interfészen keresztül újabb adatcsomag érkezik, a

tárolási idő újraindul. Folyamatos adatcsomag küldés esetén, a csomópont és a gateway közötti bázisállomásokban érvényesek maradnak a routing cache bejegyzések. Így egy ún Soft-State Route (aktuális útvonal, amely idővel elévül) képződik a mobil végberendezés és a gateway között. Amikor a mobil készülék bázisállomást vált, akkor a már meglévő bejegyzéseket az új útvonalon haladó uplink csomagok alakítják ki. 5. ábra A CIP és a Mobil IP együttműködése Az éppen inaktív mobil készülékek, melyek se nem küldenek, se nem fogadnak adatot, de szeretnének elérhetőek maradni az esetlegesen beérkező csomagok számára, hagyják, hogy elévüljenek a routerekben tárolt Routing Cache bejegyzéseik, és egy funkciójában más ún. Paging Cache-ben rögzítik azokat. Ez már hosszabb route-timeout idővel rendelkezik, mint a Routing Cache, és nem szükséges, hogy minden csomópont implementálja azt. Ezután a mobil terminálnak

címzett csomagok a Paging Cache tartalma szerint szállítódnak. Az adatforgalmat pillanatnyilag lebonyolító aktív csomópont mozgását a hálózatban követni kell bázisról-bázisra, hogy azonnal, keresés nélkül képesek legyünk a felé irányuló forgalmat továbbítani. Az aktív csomópontnak kötelessége jelezni a hálózatnak minden egyes bázisállomás váltást. Az inaktív csomópont mozgását követni nem szükséges, mert ezzel, felesleges jelzésekkel árasztanánk el a hálózatot. A handovert mindig a mobil csomópont kezdeményezi egy útvonal-frissítő (Route Update) üzenettel, amelyet az új bázisállomásnak küld. Ezután ez az üzenet a már ismertetett hop-by-hop módon eljut a gateway routerhez, és útközben újrakonfigurálja a routing bejegyzéseket azokban a csomópontokban, amelyeken áthalad. A mobil csomópont és a gateway router közötti régi és új útvonal fentről lefelé haladva az ún. cross-over csomópontig azonos, majd

kettéválik. A régi úton lévő csomópontokban lévő bejegyzések, frissítési üzenet hiányában, törlődnek. A CIP kétféle handovert definiál: az ún. hard és soft handovert Mindkét mechanizmust olyan készülékek számára fejlesztették ki, amelyek egyszerre csak egy bázisállomással (BS) képesek kapcsolatban lenni. A különbség közöttük a BS váltás módjában van. Hard handover esetén a MN azonnal átvált a régi BS-ről az új BS-re. A MN a következőképpen ismeri fel, hogy handovert kell kezdeményeznie. A BS-ek speciális üzenetekben hirdetik azonosítóikat (ID). E jeleket a MN-ok veszik és megnézik, hogy az aktuálisan vett ID megegyezik-e az előzőleg vettel. Ha egy MN eltérést tapasztal az előző IDhez képest, akkor egy új BS hatókörébe ért, tehát fel kell vele vennie a kapcsolatot Soft handover esetén a MN, miután érzékeli az új BS jelenlétét, egy pillanatra átkapcsol arra, és küld neki egy útvonal-frissítő

üzenetet, melyben egy jelzőbittel jelzi, hogy soft handovert hajt végre, majd visszakapcsol a régi BS-re, és tovább figyeli a beérkező csomagokat. Az új BS uplink szomszédja felé továbbítja a frissítő üzenetet, amely a crossover csomópont alatt, minden csomópontban új routing bejegyzést indukál A cross-over node-ban egy plusz bejegyzés készül, aminek következtében a csomagok duplikálódnak, és mindkét útvonalra továbbítódnak. Egy meghatározott idő múlva a mobil csomópont ténylegesen átlép az új BS hatósugarába. Ekkor a mobil egy második útvonal frissítő üzenettel jelzi az új BS-nek a soft handover befejezését. Ez a frissítő üzenet állítja le a cross-over csomópontban a csomagok duplikálását és törli a plusz bejegyzést. Ezt követően a cross-over csomópont már csak az új BS felé továbbítja a csomagokat. Amennyiben az új BS-hez vezető út jóval hosszabb, mint a régihez vezető volt, vagy sok időt vesz igénybe az

átkapcsolás, akkor néhány csomag elveszhet. Ezért az új útvonalon haladó csomagok késleltetve kerülnek továbbításra. Ez azt eredményezheti, hogy a mobil csomópont bizonyos csomagokat kétszer kap meg, ami viszont még mindig jobb, mintha csomagvesztés történne. Hard handover esetén mindazon csomagok elvesznek, amelyek a cross-over csomópont routing cache-ének átkonfigurálásáig érkeznek. Ilyen típusú handover esetén a MN azonnal átkapcsol az új BS-re és elkezdődik az útvonal frissítő üzenet uplink irányba történő vándorlása, azaz az új útvonal kialakulása. Amíg ez az üzenet eljut a cross-over csomópontig, és a routing bejegyzés átjavítása megtörténik, addig a mobil csomópont számára érkező csomagok a régi útvonalon haladnak tovább és feldolgozás hiányában elvesznek. Soft handover esetén csak azok a csomagok vesznek el, amelyek az idő alatt érkeznek, amíg a mobil csomópont elküldi első útvonal frissítő

üzenetét az új BS-nek. 2.32 HAWAII Az előző fejezetben részletesebben bemutattam a CIP mikromobilitási protokollt. Ebben a részben a HAWAII (Handoff-Aware Wireless Access Internet Infrastructure) protokollról lesz szó, amit a Lucent Bell Lab kutatói fejlesztettek ki. Működése sok tekintetben hasonlít a CIP-re. A HAWAII is a harmadik (hálózati) rétegben működik, és a routing algoritmuson módosít a mobilitás lokális támogatása érdekében. A routerekben lokálisan érvényes speciális útvonal nyilvántartást vezet, ezzel biztosítja, hogy egy földrajzilag körülhatárolt területen (domainen) belüli cellaváltás esetén ne kelljen egészen a home agent-ig visszajelezni a handovert, illetve az új ideiglenes címet (Care-of-Address). A CIP-hez hasonlóan itt is soft-state módon tárolódnak a routerekben az információk, tehát ha nem frissítik őket, akkor egy bizonyos idő eltelte után törlődnek a rendszerből. Ez ugyanazokat a célokat

szolgálja, mint a CIP esetében. Így nem kell a beírt adatokat törölni, ha a mobil megváltoztatja helyzetét. A hasonlóságok mellett azonban meg kell említeni két lényeges különbséget is. Az algoritmus nem igényli, hogy a mobil csomópontban megváltoztassuk a programokat, elég, ha a Mobil IP protokollt ismeri. Ebben az esetben nem fontos hogy a hálózat gráfja fa legyen Az általános hasonlóságok és különbségek után nézzük meg részletesebben a HAWAII protokoll céljait, felépítését, üzeneteit és handover eljárásait. A HAWAII a Mobil IP-t kiegészítve működik, így a domainek közti (inter-domain) mozgást, tehát a makro mobilitást a Mobil IP kezeli. A HAWAII-ban a mobil hoszt megtartja a hálózati címét, mialatt a domainen belül mozog. A home agent nem értesül a terminál mozgásáról ezen a területen belül; ő úgy érzékeli, mintha nem is történne változás. A protokoll hátránya, hogy a hierarchikus felépítés

következtében az üzenetek egy részének el kell jutnia a domain root router-hez, ennek kapacitása viszont véges, így korlátozza a felhasználók számát a domainen belül. Mint már említetem, az alapvető gondolat az, hogy a protokoll használatakor hierarchikus szintekre osztják a hálózatot, és ezzel élesen elkülönül a makro, illetve a mikromobilitás kezelése. Ezt a 6 ábra szemlélteti 6. ábra A HAWAII hierarchikus szerkezete A HAWAII felosztja a hálózatot domainek hierarchiájára. Minden egyes domainben a gateway routert Domain Root Router-nek nevezik. Valamennyi hosztnak rendelkeznie kell egy IP címmel és egy home domainnel. Ha a mobil terminál a home domainen belül mozog, akkor megtartja az IP címét. A mobil hosztnak szánt csomagok először a domain root routert érik el, ami az adott domain alhálózati címével rendelkezik, aztán egy speciális dinamikusan felépített útvonalon továbbítódnak a csomagok a mobil terminálhoz. Ha a mobil

hoszt elhagyja a home domaint és átmegy egy másik területre (foreign domain), akkor a hagyományos Mobil IP mechanizmusok lépnek életbe. Ha a foreign domain is HAWAII alapú, akkor a mobil hoszt kap tőle egy ún. Co-located Care-of-Address címet Innentől kezdve a mobilnak szánt csomagok a home agent-en keresztül átvándorolnak a careof address-nek megfelelő domain-be. Mialatt a mobil hoszt mozog a foreign domainen belül, változás nélkül megtartja az új címét, és az összeköttetést dinamikusan felépített útvonalakkal tartják fönn. A protokoll 3 fajta üzenetet használ az útvonal felépítésére és frissítésére: a power up, az update és a refresh üzeneteket. Ezek a bázisállomás és a routerek közötti kommunikációt segítik elő. A mobil hoszt és a bázisállomás között a hagyományos Mobil IP üzeneteket használják. Amikor a mobil terminál először csatlakozik fel és kapcsolódik egy domainhez, akkor küld egy mobil IP registration

request üzenetet a megfelelő bázisállomásnak. A bázisállomás pedig küld egy HAWAII path setup power up üzenetet a domain root routernek (hop-by-hop elv alkalmazásával). A bázisállomás és a domain root router közti útvonalon lévő összes router módosítja a routing táblájában az adott mobilra vonatkozó bejegyzését. Végül a domain root router küld egy nyugtát a bázisállomásnak, a bázisállomás pedig közöl egy mobil IP registration választ a mobil hosztnak. Mivel a mobil hoszt mozog a domainen belül, ezért a kapcsolat fenntartásához a HAWAII path setup update üzeneteket használja. Céljuk a routing táblák módosítása a mobil hoszt számára kiválasztott routerekben a domainen belül. Így a csomagok, melyek beérkeznek a domain root routerhez, minimális megszakítási idővel érhetik el a mobil terminált. A routerekben az információk soft-state módon tárolódnak. A frissítés érdekében a mobil hoszt periodikusan küldi a path

refresh üzenetet a bázisállomásnak. A bázisállomás és a köztes routerek a sorban - szintén azonos időközönként - küldenek egy aggregate hop-byhop refresh üzenetet a domain root routernek. Ahogy azt később látni fogjuk ez a három path setup üzenet csak bizonyos szempontok alapján kiválasztott routerekhez kell, hogy eljusson a domainen belül. Ennek eredményeként a jelzési forgalom nagyon kicsi Az előbbiekben bemutattam, mire szolgál a HAWAII protokoll három üzenete. Most nézzük mi a helyzet akkor, ha a mobil ún. standby állapotban van Ez azt jelenti, hogy nem küld adatokat, de nincs kikapcsolva. Egy mobil hosztnak standby állapotban csak azt kell jeleznie a hálózat felé, ha az egyik paging area-ból átmegy egy másikba; a paging area-n belüli handovereket nem jelzi. Ha standby állapotban lévő mobilhoz egy adatcsomagot kell továbbítani, akkor a hálózatnak meg kell őt keresnie, mielőtt továbbítaná a csomagot. Ez a paging eljárás

utasítja a mobilt, hogy azonnal kapcsoljon aktív állapotba, és így legyen alkalmas a csomag fogadására. A HAWAII paging támogatásának használatához a mobil hosztnak képesnek kell lennie a saját paging area-jának azonosítására, és a paging kérések detektálására. Az azonosításra egy tipikus lehetőség, hogy a bázisállomás periodikusan küld egy ún. beacon jelet egy broadcast csatornán, így a mobil hallgatva ezt a csatornát könnyen észlelheti a váltást. A bázisállomás paging kérése pedig több különböző csatornán küldhető, amit a mobil hosztok hallgatnak. A paging area-n belüli címzést a HAWAII-ban multicast-al oldották meg. A protokoll alapvető tulajdonságai után nézzük meg, hogyan történik a handoverek kezelése. Tekintsük azt az esetet, amikor a mobil hoszt és domain root router között már megtörtént a power up üzenetváltás. Feltételezhető, hogy a bázisállomások IP routing funkcióval rendelkeznek. A

következőkben bemutatom a HAWAII-ban definiált 4 útvonal felépítő eljárást arra az esetre, amikor a mobil hoszt mozgása következtében bázisállomást vált. Az érthetőség kedvéért a fa topológiát vizsgáljuk, de meg kell említeni, hogy ez nem követelménye a HAWAII-nak. Tehát bármilyen általános topológia esetén is működnek ezek az eljárások. Definiálnunk kell az ún cross-over router-t Ez handover esetén ahhoz a csomóponthoz tartozó router, ahol a domain root router felé vezető úton a régi illetve az új útvonal elágazik. A négy útvonal felépítő eljárás, két csoportba osztható: ƒ Forwarding Path Setup: Ha a csomagok a régi bázisállomástól közvetlenül jutnak el az újhoz, és csak utána jut el a cross-over routerhez ƒ Non-Forwarding Path Setup: Ha a csomagok a régi bázisállomástól előbb a cross-over router felé mennek, és csak utána jutnak el az új bázisállomáshoz Az ötlet, hogy a handover alatt a

csomagok átvándoroljanak a két bázisállomás között, nem újdonság, ez már a mobil ATM hálózatoknál is felmerült. A HAWAII megalkotói két továbbító eljárást dolgoztak ki. Az egyik szabványos IP routing táblákkal dolgozik, és felülírja a mobil terminálhoz tartozó bejegyzést, a másik eljárásban kiterjesztik az IP routing táblát. Az előbbit Multiple Stream Forwarding (MSF) eljárásnak, az utóbbit Single Stream Forwarding (SSF) eljárásnak hívjuk. Ezen eljárások részletes működése megtalálható a Hiba! A hivatkozási forrás nem található.-ban, így most ezek ismertetésétől eltekintek 2.33 H I E R A R C H I K U S M O B I L IP V 6 A Mobil IPv6 hasonlóan kezeli egy mobil hoszt helyi (hálózaton belüli) és globális (hálózatok közötti) mobilitását. Ez a megközelítés nem skálázható, mert nagyszámú mobil hoszt esetén a keletkező jelzésmennyiség túlterhelheti a hálózatot. A Hierarchikus Mobil IPv6 Hiba! A hivatkozási

forrás nem található. a Mobil IPv6 kiterjesztése. Célja a domainen belüli jelzésmennyiség csökkentése, továbbá a handover felgyorsítása. Alapötlete a domainek hierarchikus architektúrába szervezése A helyi handovereket így domainen belül gyorsabban lehet kezelni, elkerülve a felesleges jelzéseket és csökkentve a csomagvesztést. A hierarchia tetején lévő mobil ügynök ellátja a mobilt regionális közvetett címmel (Regional Care-of-Address - RCoA). Az otthoni ügynök és a kommunikációs felek csak a közvetett címet ismerik, amely változatlan marad, amíg a mobil eszköz domainen belül változtatja a szolgálat-elérési pontját. A HMIPv6 a következő új fogalmakat vezeti be: ƒ Access Router (AR): A mobil eszköz alapbeállítás szerinti routere az adott domainen belül. Az AR gyűjti össze a mobil eszköz kimenő forgalmát ƒ Mobility Anchor Point (MAP): A Mobility Anchor Point egy router a mobil eszköz által meglátogatott domainben,

mely a nála regisztrált mobilok számára helyi otthoni ügynökként viselkedik. ƒ HMIPv6-ot támogató mobil eszköz: Egy mobil eszköz, amely képes a HMIPv6 felismerésére és támogatására, azaz képes az access routertől küldött MAP opció kezelésére és regisztráció küldésére. ƒ On-link care-of address (LCoA): Az on-link care–of address a Mobil IPv6ban megszabott hagyományos care-of address (közvetett cím), mely a router prefixből és a mobil eszköz azonosítójából tevődik össze. Nem azonos a helyi közvetett címmel. ƒ Helyi közvetett cím (RCoA): A helyi közvetett cím egy alternatív közvetett cím, amit a mobil eszköz a domainen belül használ. A MAP interfészek egyikéhez tartozik, vagy a MAP prefixéből autokonfigurációval hozza létre a mobil eszköz. ƒ Helyi Binding Update: A mobil eszköz MAP-nak küldött Helyi Binding Update üzenettel összerendeli a megfelelő RCoA és LCoA címeket. A HMIPv6-ban a hálózati

domain hierarchikus struktúrát alkot. A hierarchia legalján AR-ek (access router, hozzáférési pont) találhatók, felettük HMIPv6 protokollt támogató routerek és a MAP-ok (Mobility Anchor Point) helyezkednek el. A MAP a hierarchia tetszőleges szintjén elhelyezkedhet. A MAP a helyi otthoni ügynök szerepét betöltve lehetővé teszi a jelzések lokalizálását a domainre, ami gyorsabb handovert és kisebb csomagvesztést tesz lehetővé. Így a HMIPv6 képes a MIPv6 teljesítményének növelésére és tökéletesebb handovereket tesz lehetővé. A MAP megkapja a domainben tartózkodó mobil eszköznek címzett adatcsomagokat, beágyazza őket, majd továbbítja a mobil eszköz aktuális címére. Amennyiben a mobil eszköz címe megváltozik, az új címet csak a helyi MAP-nál kell regisztrálnia. Eközben a globális címe (RCoA, Regional Care-of-Address), amit az otthoni ügynök és a kommunikációs partnerek ismernek, változatlan marad. 7. ábra A HMIPv6

rendszer Amikor a mobil eszköz belép egy idegen hálózatba, lekéri a MAP globális címét router advertisement üzenet segítségével és eltárolja az AR-ekbe. Amennyiben a mobil eszköz ugyanazon MAP domainjében mozog, ugyanazt a címet tartalmazó router advertisement üzenetet kapja egy másik alhálózatba belépve. A cím esetleges megváltozása jelzi a mobilnak, hogy belépett egy másik domainbe, ezért Binding Update frissítő üzeneteket küld az otthoni ügynökének és a kommunikációs partnereinek, majd regisztrálja magát az adott MAP-nál. A regisztráció során elküldi otthoni címét és LCoA (On-link CoA) címét. A HMIPv6 a következő funkciókkal bővíti ki a Mobil IPv6-ot: ƒ Helyi Binding Update (BU): A HMIPv6 a Mobil IPv6 által használt BU üzenetet egy további egybites flaggel bővíti ki, annak jelzésére, hogy a binding-ot a MAP-nál való regisztráláshoz kívánják használni. ƒ On-link care-of address (LCoA) teszt opció

(OCOT): Ez egy nyugtázó üzenet. Használata opcionális és a MAP-ban lehet konfigurálni. Használatát a MAP-nak és a mobil eszköznek is támogatnia kell. ƒ Neighbour discovery kiterjesztés - MAP opció: A MAP opció a neighbour discovery router üzeneteinek egy kiterjesztése, mely segítségével értesítik a hálózatba érkező mobil eszközöket a MAP jelenlétéről. A MAP globális IP címének prefixe 64 Ezt a prefixet használja a mobil eszköz az RCoA előállításához. Mivel a MAP domain minden routere ugyanazt a MAP opciót használja, az opciók megváltozása azt jelzi, hogy a mobil hoszt új domainbe lépett be. Ebben az esetben a mobil hosztnak regisztrálnia kell magát az új MAP-nál és értesíteni az otthoni ügynökét és a kommunikációs partnereit az új RCoA címéről. Az AR-ek is használják a MAP opcióban hordozott információkat. Ennek használatával határozzák meg, hogy melyik MAP-nak küldjenek üzeneteket. HMIPv6 használata

esetén a mobil eszköz két címmel rendelkezik, egy RCoA-val és egy LCoA címmel. Az RCoA-t állapotmentes módon hozza létre a mobil a MAP opcióban kapott interfész-azonosítóból, és az alhálózati prefixből. A protokoll használatához csak a mobil eszköz implementációjának módosítására van szükség a HA és a kommunikáció partnerének beállításai változatlanok. Amikor a mobil új domainbe érkezik állapotmentes autokonfigurációt használ az új LCoA létrehozásához. Az RCoA-t is létrehozza a MAP prefixéből a már említett módon Az RCoA létrehozása után Helyi Binding Update üzenetet küld a MAP-hoz LCoA forráscímmel és RCoA otthoni cím opcióval. Ennek hatására a MAP eltárolja az LCoA-RCoA bejegyzést A MAP, mint otthoni ügynök, Duplicate Address Detection-t (cím egyediség ellenőrzést) hajt végre a mobil eszköz RCoA címén, és nyugtát küld a BU üzenetre. Ez a nyugta a művelet sikerességét mutatja, ellenkező esetben pedig

a megfelelő hibakódot tartalmazza. A MAP használhatja az OCOT opciót is a nyugtában. Ebben az esetben a mobil eszköznek egy OCOT opciót használó nyugtát kell visszaküldenie a MAP-nak, megnövelve az opció sorszámát eggyel. Az opció segítségével a MAP ellenőrizheti, hogy a mobil eszköz tényleg az általa ismert linken tartózkodik. A MAP-nál való regisztrációt követően a mobil eszköznek regisztrálnia kell új RCoA címét az otthoni ügynökénél, egy a megfelelő RCoA-otthoni cím párost tartalmazó Binding Update üzenettel. A Home Address opció tartalmazza az otthoni címet, a forráscím mező, vagy az alternatív-CoA opció, pedig az RCoA-t. A mobil eszköz hasonló BU-t küldhet a kommunikáció partnereinek is. A MAP opció I flag-ének használata esetén a mobil eszköz az RCoA-n kívül más forráscímet is megadhat, P flag használatakor a forráscím csak az RCoA lehet. Amennyiben a mobil eszköz az RCoA-t használja forráscímként, az

alternatív CoA opció használata nem szükséges. A mobil alagutazással továbbítja kimenő csomagjait a MAPnak A forráscím a külső fejrészben a mobil LCoA címe, a célcím pedig a MAP címe A mobil eszköznek meg kell várnia a MAP nyugtáját az elküldött BU üzenetre, mielőtt regisztrálná magát az otthoni ügynöknél. A Binding Update-ekben az otthoni ügynököknek és a kommunikációs partnereknek küldött élettartam nem lehet nagyobb, mint a MAP-nál történő regisztráció élettartama. A MAP-ok közötti handover felgyorsítása érdekében a mobil eszköz helyi BU-kat küldhet a korábbi MAP-oknak az új LCoA címével. Ezek után a csomagokat a MAP az új LCoA címre továbbítja majd. A MAP a mobil eszköz otthoni ügynökétől és kommunikáció partnerétől a mobil RCoA címére küldött csomagokat a mobil LCoA címére továbbítja alagutazással. Amikor a mobil eszköz domainen belül mozog új LCoA címét csak a MAP-jánál kell regisztrálnia,

az RCoA közben változatlan. A mobil az RCoA helyett az LCoA-t tartalmazó BU üzenetet küldhet a kommunikációs partnerének, amennyiben egyazon linkhez csatlakoznak. Így a csomagok a kommunikációs partnertől közvetlenül juthatnak el a mobil eszközhöz. A MAP opciót a P illetve I flag beállításával használva a mobil eszköz LCoA címét elrejthetjük a MAP domainen kívül tartózkodók elől. Ilyenkor a mobil eszköz a kommunikációs partnernek és otthoni ügynöknek küldött BU üzenetekben az RCoA címét használja forráscímként. Továbbá a kimenő csomagokban szereplő forráscímnek is az RCoA cím fog szerepelni. 2.34 R E G I O N Á LI S REGISZTRÁCIÓ – R E G -R E G V 6 Az előző részben részletesen ismertetett HMIPv6 protokollhoz hasonlóan a RegRegv6 Hiba! A hivatkozási forrás nem található. protokoll is egy alternatív MIPv6 kiterjesztés a jelzési késleltetések csökkentése érdekében. A protokoll alapötlete megegyezik a HMIPv6

alapelvével. Nevezetesen, a RegRegv6 is definiál egy mobilitás kezelő ügynököt, mely ideiglenes címmel látja el az oda látogató mobilt, a cím változatlan marad mindaddig, amíg a MN az adott alhálózatban tartózkodik. A protokoll az alábbi funkcionális entitásokat és címeket definiálja: ƒ Regional-aware Router: olyan router, amely támogatja a RegRegv6 protokollt. ƒ Regional Mobility Agent: ez tulajdonképpen egy szoftver modul a Regional-aware routerben, amely a RegRegv6 protokollt implementálja. ƒ Cross-over Router: az a router, ahol a mobil terminál előző AR- éhez vezető út metszi az új AR-hez vezető utat. Ez az egyetlen router a domainen belül, amelyben a mobil helyzetére vonatkozó információnak frissülnie kell a mozgás során. Bármelyik Regional-aware router betöltheti a Crossover router szerepét. ƒ Gateway Router: egy router, amely tartalmazza a GMA modult, és kontrollálja a mobil eszközöknek kiutalt RCoA címeket. A fizikai

hierarchia tetszőleges szintjén elhelyezkedhet. ƒ Gateway Mobility Agent (GMA): szoftver modul, mely a RegRegv6 protokollt implementálja a Gateway Router-ben. ƒ Local care-of address (LCoA): ugyanaz, mint HMIPv6 esetében. ƒ Regional care-of address (RCoA): ugyanaz, mint HMIPv6 esetében. ƒ Regional Binding Cache: egy speciális tár a Regional-aware routerek-ben, amely a mobil helyzetére vonatkozó információk tárolására szolgál. A tároló bejegyzései a következő információkat tartalmazzák: otthoni cím, idegen cím, élettartam, jelző bitek, biztonsági adatok. Egy RegRegv6 alhálózat hierarchikus felépítésű, és a hierarchia egyes szintjein regionális regisztrációra képes routerek találhatók. A RegRegv6 alhálózatban minden esetben van egy GMA, amely a hierarchia csúcsán helyezkedik el. Hasonlóképpen a HMIPv6-nál látottakhoz a MN-ok a hierarchia legalsó szintjén elhelyezkedő AR-ekhez csatlakoznak. A 8 ábra egy példa RegRegv6

alhálózatot szemléltet. Ennél a protokollnál is minden MN két ideiglenes címmel rendelkezik. A MN az aktuális AR-étől egy LCoA címet, míg a GMA-tól egy RCoA címet kap. A kiterjesztés célja egyrészt az alhálózaton kívülre küldött BU üzenetek számának minimalizálása, másrészt a lokális regisztrációs üzenetek minél gyorsabban történő végrehajtása. A protokoll garantálja, hogy a csomagokat a hierarchián belül optimális útvonalon továbbítják. 8. ábra A RegRegv6 protokoll működése A protokoll egy járulékos flag-et vezet be a router hirdetési üzenetben, amely azt jelzi, hogy az adott alhálózat képes-e kezelni a regionális regisztrációt, vagy sem. Amikor a MN egy új AR-hez csatlakozik, elsőként meg kell tudnia a meglátogatott alhálózat azonosítóját, hiszen ezen információ alapján dönti el, vajon új alhálózatba érkezett (inter-domain handovert hajtott végre) vagy sem. A MN az ún router felderítési (router

discovery) mechanizmust használja a meglátogatott RegRegv6 alhálózat azonosítására, valamint a routerek képességeinek feltérképezésére. A mechanizmus használata a MIPv6-ban definiált router hirdetési üzenetek kiterjesztését igényli. Az alhálózat azonosításához szükség van egy új opcióra, az ún. módosított prefix információ opcióra (Modified Prefix Information Option) Az alhálózat azonosítása a következőképpen történik: a MN elküld egy csomagot, amelynek célcíme egy speciális anycast cím, a „visited domain routers”. A cím definiálásához a router hirdetési üzenet további kiegészítésére van szükség. Az új kiterjesztés egy vagy több, a MNoknak kiosztható RCoA cím tárolására szolgál (Ez a Regional CoA kiterjesztés) Az anycast cím a regionális CoA kiterjesztésben meghatározott prefixből és 0-ás hoszt címből áll. Az így létrehozott üzenetet az anycast csoport legközelebbi routere kapja meg, amely

válaszának módosított prefix információ opciójában megadja az aktuális alhálózat azonosítóját. A kapott azonosítót a MN eltárolja, így lehetővé válik számára, hogy a későbbi mozgások során detektálja az alhálózat-váltásokat. A környező routerek feltérképezése után a MN a HMIPv6-nál látottakkal megegyező módon generál egy új LCoA címet (elsődleges CoA). Ezután megindul a lokális regisztráció folyamata, a MN-nak ugyanis regisztráltatnia kell magát a mobilitás kezelő ügynöknél. A MN a már említett regionális CoA kiterjesztésből kiolvassa az RCoA címet, amit egy regionális BU üzenetben elküld a „visited domain routers” anycast címre. Az üzenetet elsőként az AR veszi és felveszi a bejegyzést (otthoni cím-LCoA) a tárolójába. Ezután az AR a saját címét tartalmazó fejrésszel becsomagolja az üzenetet és továbbküldi a hierarchiában felette álló regionális routernek (RR). Az RR felveszi a regionális

BC-be (a regionális BC egy járulékos flag-et használ a regionális bejegyzések jelzésére) az (otthoni cím, küldő forráscíme) címpárt tartalmazó bejegyzést. A küldő forráscíme jelen esetben az AR címe A folyamat hasonló módon folytatódik mindaddig, amíg az üzenet meg nem érkezik a GMA-t implementáló Gateway Routerbe, amely többek között az RCoA címek kiosztását is vezérli. A GMA tehát nem ismeri közvetlenül a MN aktuális LCoA címét, csak azt tudja melyik router jelenti a következő állomást a MN felé vezető úton. A kötés felvétele után a GMA nyugtázó üzenetet (Binding Acknowledgement) küld a MN-nak. A MN a sikeres BA üzenet vétele után regisztrálja magát az otthoni ügynökénél és a kommunikációs partnereinél az új RCoA címével. Egy regisztrált MN-nek címzett csomag célba juttatása a következőképpen történik: a GMA kicsomagolja a csomagot, és az eredeti fejrészből meghatározza a MN otthoni címét, majd

kiveszi az otthoni cím párját képező CoA-t, amely egy egyel alatta lévő hierarchiaszinten elhelyezkedő router címe. Végül a GMA becsomagolja a továbbítandó csomagot a kiolvasott CoA címmel. Minden router a fenti folyamatot ismétli, így vándorol a csomag lépésről-lépésre lefelé a hierarchiában, amíg eléri a címzett MN-ot. A protokoll működése a csomagtovábbítás módjától eltekintve hasonlít a HMIPv6 protokoll működéséhez. A RegRegv6 protokoll igazi újdonsága alhálózaton belüli handover esetén mutatkozik meg. Amikor a MN egy adott alhálózat másik AR-éhez csatlakozik, a lokális regisztrációs fázis eltér a fent említettől. A router felderítés és az LCoA címgenerálás után ugyanis a MN egy Previous Access Route nevű opcióval kiegészített regionális BU üzenetet küld el. Ez az új RegRegv6-ban definiált opció a MN előző AR-ét határozza meg az IP címével. Minden regionális router nyilvántartja a leszármazottait,

vagyis azokat a routereket, amelyeknek ő az őse, így minden router, amelyik megkapja a regionális BU üzenetet, el tudja dönteni, hogy az előbb említett opcióban megadott AR a leszármazottja-e vagy sem. Ha igen, akkor ez a router tölti be a Crossover Router szerepét A BU üzenet csak a Crossover Routerig halad felfelé a hierarchiában, ez az egyetlen router a domainen belül, amelyben a mobil helyzetére vonatkozó információnak frissülnie kell. Összefoglalva, a CR mechanizmus egy nagyon hatékony módja az alhálózaton belüli jelzési terhelés csökkentésének. Abban az esetben azonban, ha a MN alhálózatok közötti hívásátadást hajt végre, a CR minden esetben a hierarchia csúcsán álló GMA lesz. A RegRegv6 protokoll az alap MIPv6 protokollt a következő kiterjesztésekkel egészíti ki: ƒ Router hirdetési üzenet (Router Advertisement): az alap MIPv6 router hirdetési üzenetét egyrészt egy I jelzőbittel egészítették ki. Ez a bit jelzi azt,

hogy a router egy regional-aware router. Az üzenet tartalmazza továbbá a módosított prefix információ opciót (Modified Prefix Information Option) az alhálózat azonosítására. Az üzenet többi mezője azonos a MIPv6-ban definiáltakkal. ƒ Regionális CoA kiterjesztés (Regional CoA extension): az előbb említett hirdetési üzenetet egészíti ki ez a kiterjesztés. A GMA által közzétett RCoA címek hirdetésére való, a kiterjesztésben felsorolt IP címek közül választja ki a MN az RCoA címét. A fontosabb mezők a következők: ƒ Lifetime: azt az időtartamot határozza meg, amíg az RCoA címek érvényesek az alhálózatban. ƒ Prefix length: ennek a mezőnek az alhálózati azonosító lekérdezésekor van szerepe. A mező azt határozza meg, milyen hosszú az alhálózati azonosító prefix része. Mint ismeretes, az azonosító hoszt részét nullára kell állítani. ƒ Regional Care-of Address: a meghirdetett globális cím. ƒ Regionális

Binding Update (Regional BU): a regionális BU két dologban különbözik a MIPV6 BU üzenetétől. Egyrészt kiegészítették egy új jelzőbittel (I), amely az üzenet regionális voltát jelöli. Az I flag beállításával kéri a MN az alhálózat routereit, hogy a RegRegv6 protokoll szerint továbbítsák a csomagokat. A másik kiegészítés a „Previous Access Router” alopció. ƒ Előző AR alopció (Previous Access Router): a hálózat ezt az alopciót a Crossover Router meghatározásához használja. A MN az AR-ek IP címét a router hirdetési üzenet forráscíméből deríti ki. A megismert címet minden esetben eltárolja, hogy felhasználhassa az alopció létrehozásánál. A RegRegv6 és a MIPv6 különbségeinek bemutatása során fontosnak tartom összefoglalni azokat a követelményeket, amelyeknek az egyes entitásoknak meg kell felelniük. A regionális routerek feladata többek között a speciális router hirdetési üzenetek szórása, a

regionális BC karbantartása, illetve a csomagok továbbítása a RegRegv6 protokollnak megfelelően. A MN-ok feladatát képezi a router hirdetési üzenetek feldolgozása, és a regionális BU üzenetek küldése. A routereken és a MN-okon kívüli entitások működése megegyezik a MIPv6-ban leírtakkal. 2.35 TMIP Az eddig ismertetett összes mobilitás kezelő protokollhoz szükséges, hogy a mobil terminálok a mobilitásra felkészített protokoll stack-et használjanak, mivel a mobil terminál az, ami a hálózatot vizsgálja és dönt a cellaváltások esetében. Ehhez viszont speciális IP jelzés szükséges. Az eddig kialakult protokoll stack-et viszont nagyon költséges lenne, az összes mobil terminálnál lecserélni, gondoljunk csak a mobil végberendezések különböző operációs rendszereire. Az IP rétegben működő jelzések szükségességét viszont megszüntethetjük egy a második rétegben működő cellaváltási protokollal. Ezen elvből alakult ki a

Terminal Independent Mobility for IP protokoll (TIMIP) Hiba! A hivatkozási forrás nem található. A TIMIP hálózatnak ismernie kell a terminálokat, ezért a hálózat regisztrálja azokat. Az ún Access Network Gateway (ANG) tárolja az információkat a hálózatban található összes terminálról: MAC cím, IP cím, MIP esetén az otthoni ügynök IP címe, hitelesítési adatok. Ezen információk továbbítódnak az AP-k felé, így ők tudják az újonnan érkezett terminálok IP címét és MAC címét. Amikor egy mobil terminál csatalakozik a hálózathoz, először egy routing út alakul ki az AP-k hierarchiájában. A mobil egység egy második rétegbeli csatlakozást hajt végre a TMIP domainben lévő AP-hez. Ennek során az AP-hez eljut a mobil eszköz MAC címe, ami alapján az ANG-től küldött adatbázisból kikeresi a hozzá tartozó IP címet. Az AP routing táblája ezek után a talált IP címmel fog frissülni. Az új AP egy routing update üzenetet küld

a második szinten található Access Routernek (AR), amire az AR egy RoutingUpdateAck üzenetet küld vissza és frissíti a routing tábláját. A bejegyzés a Routing Update üzenet küldőjére mutat, tehát az AP-re. A Routing Update és RoutingUpdateAck üzenetek felfutnak a router hierarchián és elérik az ANG-t. Ezzel egy útvonal jön létre az ANG és mobil egység között. Ez hasonlít a CIP és a HAWAII protokollok működéséhez Az üzenetek tartalmaznak egy időbélyeget, amit az AP generál. Az időbélyeg az adatokkal szintén frissítésre kerül A hálózatban az AP-k helyi óráit a Network Time Protocol (NTP) segítségével szinkronizálják. Az időbélyeg lejártával az AR egy ICMP echo üzenetet küld a mobil egység felé. Ha a mobil nem válaszol adott időn belül, akkor a routing bejegyzés törlődik. A cellaváltás az AP-k között hasonlóan jön létre. Amikor felépül egy új út az AR-eken keresztül, akkor ezek törlik a mobil egységhez

tartozó régi bejegyzésüket. 2.36 T E L E MIP A TeleMIP egyensúlyt próbál létrehozni a frissítések késési problémája, és a komplex, kétszintű hierarchiát használó menedzsment szerkezetek között. Kijelöl egy új (üzemeltetési) node-ot, a Mobility Agent-et, amely a hálózati hierarchia egy magasabb pontján helyezkedik el, mint az alhálózat alapú Foreign Agent és a mobil egységet ellátja egy globális Care-of-Address-el, amely az egész domain-ben érvényes. A TeleMIP nem menedzseli a domain-ek közti mobilitást forrás-specifikus útvonalakkal, de egy másodlagos helyi hatáskörű Care-of-Address-t használ, amely csak a domainben érvényes. 2.37 AODV (A D - H O C O N - D E M A N D D I S T A N C E V E C T O R ) Ebben a protokollban nincs hierarchia az egyes csomópontok között. Ha egy csomópont csomagot akar küldeni egy másik állomásnak, egy broadcast üzenetet küld a hálózatba. Azon csomópontok, amelyek ezt veszik, és ismerik a keresett

állomás pozícióját (például a csomópont szomszédai, vagy a cella bázisállomása), válaszolnak. Amikor megjönnek a válaszok, a csomópont kiválaszt egy útvonalat, és azon kommunikál a célállomással. A közbenső csomópontok csak annyit tudnak, hogy nekik merre kell továbbítani a csomagokat (a teljes útvonalat nem ismerik). 2.38 DSR (D Y N A M I C S O U R C E R O U T I N G ) Ez egy AODV-hez hasonló protokoll. A felfedezés itt is broadcast üzenetekkel történik A keresést elindító állomás minden egyes adatcsomagban elküldi a teljes útvonalat. Ebből eredően a közbenső állomások nemcsak azt tudják, hogy merre kell továbbítani a csomagot, hanem az egész útvonalat ismerik. Hiba esetén a küldő állomásnak kell észrevennie, hogy a kapcsolat megszakadt. 3. Mobilitás kezelés a jelenlegi mobil hálózati technológiákban 3.1 Mobilitás kezelés WLAN-okban A WLAN-beli mobilitás kezelést a Mobil IP oldja meg a klasszikus Otthoni

ügynök alkalmazásával és Care-off cím kiosztásával. 3.2 Mobilitás kezelés a 2. generációs mobil hálózatokban A második generációs mobil hálózatokban a mobilitás kezelést két nemzetközi szabvány támogatja: az Electronic/Telecommunications Industry Associations Interim Standard 41 (EIA/TIA IS-41), amit az Egyesült Államokban az AMPS és IS-54/IS-136 hálózatokra alkalmaznak, illetve a GSM Mobile Application Part (MAP) amit a GSM, DCS-1800 és PCS1900 hálózatokra használnak. Mindkét esetben a hívásátadás és helyzetnyilvántartás is az SS7 jelzésrendszert használja. Ismeretes, hogy a 2generációs hálózatok szolgáltatási területét cellákkal fedik le, és egy meghatározott földrajzi vagy logikai terület kezeléséért a Mobil Kapcsoló Központ (MSC) a felelős. A helyzetnyilvántartást a helyadatokat tároló adatbázisokkal oldották meg, a Home Location Register-el (HLR) illetve a Visitor Location Register-el (VLR). Minden MSC-ben

van egy VLR, ami átmeneti információkat tárol az adott területre, míg a HLR-ek hierarchikusan magasabb szintű adatbázisok, amelyek állandó jellegű információkat tartalmaznak minden egyes mobil terminálra. Így minden egyes terminálra van egy bejegyzés egy HLR-ben, ami tartalmaz egy linket is ahhoz a VLR-hez, amelyik arra a területre az illetékes, ahol épp a mobil terminál tartózkodik. Amikor a mobil terminál cellát vált, akkor előfordulhat, hogy egy olyan cellába kerül éppen, amelyhez már egy másik VLR tartozik. Ebben az esetben frissítenie kell a HLR-ben tárolt információt, vagyis a terminál küld egy update üzenetet, ami a bázisállomáson és az MSC-n keresztül eljut a hozzá rendelt VLR-hez. A VLR leellenőrzi a helyi bejegyzéseit, ha a terminál Mobil Azonosító Száma (Mobile Identification Number, MIN) már szerepel ezekben, akkor nincs szükség semmilyen változtatásra sem, ugyanis akkor a terminál nem váltott Location Area-t.

Ellenkező esetben a terminál MIN azonosítóját eltárolja a helyi bejegyzésekhez, és egy új update üzenetet küld a HLR-nek. Válaszként a HLR azonosítja mobil terminált, és küld egy pozitív regisztrációs nyugtát az új VLR-nek. Ezen felül a HLR küldhet egy regisztráció érvénytelenítő üzenetet is a régi VLR-nek, vagy egy periodikus mechanizmus automatikusan frissíti a VLR adatbázist és törli a lejárt idejű bejegyzéseket. Minden esetben ha új kapcsolat inicializálódik, a VLR végignézi a helyi bejegyzéseit a hívott mobil terminál után kutatva. Ha a hívó és a hívott fél is ugyanazon a szolgáltatási területen található, akkor a hívás közvetlenül a terminálhoz lesz irányítva. Ellenkező esetben a hívó fél VLR-je egy helyzeti információ kérést intéz a HLR-hez. A HLR visszaigazolja ,hogy a terminál tényleg ezen a területen található és egy route kérés üzenetet küld. Ez az üzenet a területet kiszolgáló MSC-hez

kerül a VLR közbenjárásával, ami egy átmeneti helyi bejegyzés számot (Temporary Local Directory Number, TLDN) allokál az adott terminálhoz. Ez a TLDN lesz visszaküldve a HLR-hez, majd továbbítva a hívó VLR-hez. Az SS7 jelzésrendszert használva egy útvonal kerül kialakításra az MSC-n keresztül, és egy paging illetve riasztási üzenetet kap a hívott mobil terminál. Ha a terminál VLR-t vált a kapcsolat ideje alatt, az összes lépésre ismétlésre kerül, jelentősen növelve ezáltal a jelzésforgalmat, különösen ha a terminál távol van a HLR-től. Ez ösztönözte a kiterjedt kutatásokat az elosztott és hierarchikus HLR-ek témakörében. 3.3 Mobilitás kezelés műholdas hálózatokban A távközlési célra használt műholdakat három nagy csoportba lehet sorolni: a geostacionárius pályán mozgó műholdak (GEO), a közepes pályán mozgó műholdak (Medium-Earth Orbital, MEO) és az alacsony pályán mozgó műholdak (Low-Earth Orbital, LEO).

A GEO típusú műholdak mintegy 30-40 ezer km magasságban helyezkednek el, sebességük szinte megegyezik a Földével, így a Földről úgy látjuk ezeket, mintha állnának. Továbbá abból kifolyólag, hogy ilyen nagy távolságra vannak a Föld felületétől, a GEO műholdak nagy lefedési területtel rendelkeznek, a Föld felületének közel 1/3-át fedik le, a 75 déli szélességi foktól a 75 északi szélességi fokig. E két tulajdonság együttes megléte (állandó pozició illetve nagy lefedettség) biztosítja hogy minimum három GEO műholddal majdnem elérhetjük a globális lefedettséget. E okból kifolyólag már hosszú ideje alkalmazzák a műholdak ezen típusát a műholdas távközlésben. Nagyon nagy segédeszközök a műholdas TV műsorszórásban, hiszen a parabolaantennáinkat nem kell állandóan állítgatni, azt egy pontra beállítva állandóan ugyanabból az irányból foghatjuk a műhold jelét. Ugyancsak nagy segítségünkre voltak

kezdetek óta a GEO műholdak a nemzetközi telefonbeszélgetések lebonyolításában. A MEO típusú műholdak mintegy 7-12 ezer km magasságban helyezkednek el és a Földhöz képest más szögsebességgel forognak. A keringési idejük 6 óra körül van, míg egy földi megfigyelő maximum pár óráig láthatja a horziont felett. A MEO műholdak és a Föld közötti kisebb távolság miatt a műholdas terminálok (így pl. a telefonkészülékek és az ahhoz tartozó antennák) mérete is kisebb lehet, mint a magasabb pályán (pl. GEO rendszerek) mozgó műholdakkal kommunikáló távközlési rendszerek esetében, így a jövő azt sugallja hogy a mobil távközlés rohamos elterjedése indokolni fogja a LEO és MEO rendszerű műholdak nagyobb volumenű elterjedését. Mindig meghatározható, hogy hány műhold szükséges egy távközlési szolgáltatás zökkenőmentes kiszolgálásához. A pályamagasság csökkenésével mindig jelentősen csökken a besugározható

terület nagysága, MEO rendszerű műholdas konstellációnál általában elegendő 6-20 műhold rendszerbe állítása a Föld teljes lefedettségének biztosításához. Elsődleges példáként olyan rendszerekre, amelyek MEO műholdakat használnak, a Navistar Global Positioning System (GPS) emelhető ki. A LEO típusú műholdak mintegy 700-1600 km magasságban helyezkednek el. 700 kmnél alacsonyabbra már nincs lehetőség a műholdat állítani, mert a légellenállás lejjebb már olyan nagy mértékű, hogy külön üzemanyagra lenne szükség a műhold pályán tartásához. Így a LEO műholdak csupán 20 percig figyelhetőek meg a láthatáron, viszont hosszú ideig utána nem láhtatóak. Ez elfogadható egy tárol-továbbít (store-and-forward) típusú távközlési hálózat esetén, de nem alkalmas interaktív kommunikációra. Az előnye viszont a LEO műholdas rendszereknek, hogy nagyon kedvező végpont-végpont késletetést lehet elérni velük, illetve kisebb

az energiafogyasztás a mobil terminál és a műhold esetében is. Viszont a globális lefedettséghez és az elérhetőség növeléséhez sok műholdra van szükség, így például az IRIDIUM rendszer 66 műholddal működik 6 keringési pályán, 780 km magassában, 100 perces keringési idővel. A mobilitás kezelés GEO hálózatoknál hasonló mint a második generációs rendszerekben. Viszont a MEO és LEO hálózatokban nemcsak a terminál mozgását kell figyelembe vennünk, hanem a műhold mozgását is. Annak érdekében, hogy pontosabban meg lehessen állapítani a terminál tartózkodási helyét, egy adott műhold lefedési területét kis méretű cellákra osztják, ún. pontnyalábokra (spot-beam) GEO hálózatokban nem túl gyakran kerül sor handoverre, viszont a LEO hálózatokban annál gyakrabban, ezért fontos kérdésként kell ott kezelni. Mivel a terminálok és a műholdak is változtatják a pozíciójukat, ezért beszélhetünk spotbeam és műhold

handoverről is. A spotbeam mérete kicsi, így míg műhold handoverre nagyjából minden 10 percben kerül sor, spotbeam handoverre áltagosan 38 másodpercenként. A spotbeam váltás egy műholdon belül történik, a kapcsolat fenntarthatósága a műhold erőforrásaitól és adot spotbeamen keletkező hálózati forgalomtól függ. Ahhoz, hogy földi beavatkozás nélkül támogatni tudjuk a műhold váltást, műholdak közötti linkekre van szükség (Intersatellite Links, ISLs). Ezek a linkek végződtetik a hívásokat egyik LEO műholdtól a másikig, amelyek egy keringési (intraplane) illetve különböző keringési pályán mozognak (interplane). Mindkét esetben a jelzés többletterhelés és a késleltetés olyan jelentős tényezők, amelyeket minimalizálni kell. A LEO műhold handovernek fontos sajátossága, hogy az esetek többségében a műholdak keringése miatt kerül sor, nem a terminálok mozgása miatt, így a legjobb megoldás az összes kapcsolatot egy

csoportban átirányítani a szomszédos műholdra, minimalizálva az az időt, ami a legjobb ISL kiválasztásához szükséges minden egyes kapcsolatra. A műhold handover legegyszerűbb kezelése, ha új kapcsolatot létesítünk minden egyes handover pillanatában. Ennél szofisztikáltabb megoldások is használatosak, például az út meghosszabítás (route augmentation), amikor az eredeti kapcsolatot kibővítjük egy hoppal a következő műholdig, illetve a részleges kapcsolat újrairányítás, amikor csak a módosított részét a kapcsolatnak helyettesítjük és irányítjuk át. 3.4 Mobilitás kezelés a következő generációs vezetéknélküli hálózatokban A következő generációs mobil hálózatokkal szembeni elvárás, hogy a szolgáltatások sokkal szélesebb körét tudják nyújtani a felhasználóknak, a ma létező hálózatoktól olyan tényezőkben térnek majd el, mint a globális konvergencia kérdése, vagy az interoperabilitás illetve a

mobilitás kérdéskörének kezelése. Továbba az IP támogatás, olyan új interaktív multimédiás szolgáltásokat fog majd lehetővé tenni, mint a video telefonálás, video konferencia és a mobil Internet. Viszont az allIP mobil hálózat elv alkalmazása fokozatosan fog történni, nem egy hirtelen tollvonással Míg a forgalmazók majd az új jövedelmző IP szolgáltatásokat fogják hirdetni, addig a hagyományos távközlési szolgáltatók (posta, telefon, PTTs) majd arra törekszenek, hogy maximalizálják a bevételüket a már kiépített hálózatukon. Ennek eredményeképpen a vezetéknélküli hálózat lehet egy hierarchikus cella struktúrát mutat majd. Így például az „otthoni cellában” a lefedettséget az Access Pointok fogják majd biztosítani, magánházakban, irodákban illetve nyilvános hot-spot helyszíneken (repülőtér, vonatállomás, konferencia központ). Itt lehet majd számítani az IEEE 80211, HIPERLAN, Bluetooth technológiák

alkalmazására. Illetve a pikocellákban is AP-okat lehet majd használni, kombinálva a GSM-el vagy a DECT-el. A vízszintes mobilitást, olyan mobil terminálok számára, amelyek különböző sebességgel mozognak mikro- illetve makrocellákban, majd a második illetve második generációs túli mobil rendszerek fogják majd biztosítani (GSM, HSCSD, GPRS, EDGE, CDPD, IS-95, CDMA). A műholdas cellákban alkalmazzák majd a GEO, MEO illetve LEO műholdak és földi állomások rendszerét. Ahhoz, hogy támogatni tudjuk a horizontális és vertikális roaming-ot is egy ilyen összetett környezetben, elsősorban a fizikai rétegben kell biztosítani az összekapcsolhatóságot. Ezért több módusú vagy adaptív terminálokban kell gondolkodnunk, így például olyan terminálok kerülnek majd forgalomba, amelyekben van WLAN (pl. IEEE 802.11b), cellás (GSM/GPRS) vagy műholdas interfész A globális roaming-hoz viszont olyan mobilitás kezelés szükséges, amely

integrálja magában a különböző hálózatok megoldásait. Mivel az IP a legszélesebb körben elfogadott protokoll, ezért az IP alapú mobilitás lesz majd preferálva. Ha a WLAN, 2G, 3G és a műholdas hálózatokat tekintjük, akkor is látható, hogy mindegyik rádiós hozzáférési mód különböző bázisállomásokkal és rádiós vezérlő csomópontokkal rendelkezik, amit egy közös gerinchálózatba lehet összefogni egy Service Support Node-on (SSN) keresztül. Cellás hálózat esetén ez lehetne egy MSC+, illetve WLAN esetén egy IP L1/L2 kapcsoló. Ez az SSN biztosíthatná a VLR illetve a FA funkcionalitást is, együttműködve egy HLR+ vagy otthoni előfizetői szerverrel (Home Subscriber Server). Ez a HSS tartalmazná a felhasználói profilokat, és kapcsolatban állna az AAA szerverrel (hitelesítés, engedélyezés, számlázás). Nagyon fontos az együttműködési lehetőség az áramkörkapcsolt és a csomagkapcsolt hálózatok között, így az all-IP

gerinchálózatnak mindkét átvitelt támogatnia kell. A nyilvános távbeszélő hálózatokhoz (PSTN/ISDN) és az Internethez való kapcsolódást az Interworking function (IWF) egységek, illetve a gateway-ek, tűzfalak és a Gateway Support Node-ok (GSN) fogják bíztosítani. Mivel ez az architektúra a már meglévő hálózatok és berendezések további fejlesztésével fog megvalósulni, ezért a horizontális roaming-ot egy különleges hálózati roaming mechanizmus fogja majd megoldani. Így például a GPRS hálózatokban bonyolított IP forgalom roamingolásához a GSM Szövetség a GPRS Roaming Exchange (GRX) architektúrát javasolja, amely majd szállítja a forgalmat a mobil szolgáltatók hálózati között. A vertikális roaming esetében viszont a terminálnak aktívabb szerepet kell játszania, és neki kell kezdeményezni a roaming mechanizmust. Egy WLAN cellából indulva, a terminálnak az aktiválódása után egy érvényes IP címet kell igényelnie.

Ez lehet egy előre kiosztott IP cím, vagy valószínűbb eset az, hogy egy DHCP/DNS szerver által dinamikusan allokált IP cím. Az adott hot spot-ért felelős mobilitási szerver illetve az AP a terminált egy központi vagy elosztott RADIUS/AAA szerveren keresztül hitelesíti. A felhasználó hitelesítése és engedélyezése egy MAC/jelszó vagy SIM kártya segítségével történhet. A RADIUS+ szerver kommunikál a VLR-el és a HLR+ szerverekkel és összerendeli a hot-spot felhasználót a cellás adatbázis bejegyzésével, így a felhasználó majd egy egységes számlát fog majd kapni minden szolgáltatásért. Ezen felül egy virtuális magánhálózatot (Virtual Private Network) is létre lehet hozni egy magasabb rétegbeli prokollon keresztül (IPSec, L2TP), és a mobil terminál így hozzáférhet például vállalati intranethez. Amikor a mobil terminál a hot-spoton kívül mozog, akkor kezdeményeznie kell a vertikális roaming műveletet és egy soft handover

lesz aktiválva a GSM, UMTS vagy műholdas rendszer felé. A mobil hálózat közbenső csomópontjai (node B, RNC az UMTS-ben, BSC, BTS a GSM-ben, FES a műholdas rendszereknél) transzparensek (átlátszóak) a mobil Internet forgalom átvitele előtt, mivel csak a fizikai rétegben ellenőrzik a rádiós erőforrásokat és a handover döntéseket. A terminál az IP rétegben található mobilitási szerverekkel kommunikál, és egy új hitelesítési/engedélyezési indul meg. Amikor a fizikai rétegben kiépül a kapcsolat, utána a Mobil IP különböző kiterjesztései kerülnek alkalmazásra, hogy a kapcsolat zavartalan maradjon