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ás-
kezelé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ím-
vá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, helyzet-
frissí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 helyzet-
nyilvá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.2.1. 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ás-
kezelé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 MN-
nak 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 alap-
specifiká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ás-
kezeléssel kapcsolatos tulajdonságait.

2.2.2. 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.2.3. H O S T I D E N T I T Y P R OT O C O L (HIP) – 3.5. 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.2.4. 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 multi-
homing 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 ADDIP-
vel 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 multi-
homing 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.2.5. 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ás-
kezelő 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.2.6. Ö 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.3.1. 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ő ID-
hez 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 cross-
over 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.3.2. 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 care-
of 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-by-
hop_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.3.3. 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 IPv6-
ban 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 MAP-
nak. 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.3.4. 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 MN-
oknak 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.3.5. 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.3.6. 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.3.7. 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.3.8. 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 PCS-
1900 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 2.generá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 km-
né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 all-
IP 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 802.11, 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.