IP ALAPÚ MOBILITÁS MÉDIAÁTVITELRE GYAKOROLT HATÁSAINAK SZIMULÁCIÓS VIZSGÁLATA ÚJGENERÁCIÓS VEZETÉKNÉLKÜLI HÁLÓZATOKON TDK dolgozat, 2005
Kanizsai Zoltán, Műszaki informatikai szak, V. évfolyam Lakat Gábor, Műszaki informatikai szak, V. évfolyam
KONZULENSEK: Bokor László Jeney Gábor
Budapesti Műszaki és Gazdaságtudományi Egyetem Híradástechnikai Tanszék Mobile Communication and Computing Laboratory, (MC2L)
TARTALOMJEGYZÉK I. II.
Előszó ................................................................................................................................ 1 Újgenerációs vezetéknélküli hálózatok............................................................................ 3
IPv6 - Mobile IPv6 ............................................................................................................................ 5
III. Phoenix FP6 IST-001812 projekt.................................................................................... 7 Architektúra ...................................................................................................................................... 7 Jelzések.......................................................................................................................................................... 8 Alkotóelemek ................................................................................................................................................ 8
IV. Az alap szimulációs lánc („Basic Chain”) .................................................................... 10 Modulok és összekapcsolódásaik ................................................................................................... 10 Formátumok.................................................................................................................................... 11 Multimédia fájlok ........................................................................................................................................ 11 Átmeneti fájlok............................................................................................................................................ 11 Visszacsatolások.......................................................................................................................................... 12
Szimuláció futtatása........................................................................................................................ 12
V.
IP mobilitás szimulátor .................................................................................................. 13 A szimulátor felépítése.................................................................................................................... 13 Mozgásmodellező modul................................................................................................................. 14 Mozgásmodellek.......................................................................................................................................... 14 A modul működése...................................................................................................................................... 20 Konfigurációs fájlok.................................................................................................................................... 20
Kalkulátor modul............................................................................................................................ 21 Szimulátor modul............................................................................................................................ 22 Konfigurációs fájl........................................................................................................................................ 23 A szimuláció folyamata ............................................................................................................................... 23
Végrehajtó modul............................................................................................................................ 24 Konfigurációs fájl........................................................................................................................................ 24 Végrehajtó mechanizmus ............................................................................................................................ 25
VI. Mérések valós fizikai tesztkörnyezetben ........................................................................ 27 Hardver elemek ............................................................................................................................... 28 WLAN eszközök ......................................................................................................................................... 28 Hálózati eszközök........................................................................................................................................ 31 Végberendezések......................................................................................................................................... 31
Szoftver elemek ............................................................................................................................... 32 Operációs rendszer ...................................................................................................................................... 32 Forgalomgenerátor ...................................................................................................................................... 33 Naplózás ...................................................................................................................................................... 33
Tesztesetek (Szkenáriók) ................................................................................................................ 34 Passzív mérések........................................................................................................................................... 34 Aktív mérések.............................................................................................................................................. 35
VII. Szimulációs vizsgálatok a Basic Chain keretrendszerben ............................................ 45 Médiaátvitel ..................................................................................................................................... 45 Optimalizált és hagyományos médiaátvitel ................................................................................................. 45 Cellaváltás hatásai ....................................................................................................................................... 46
Eredmények feldolgozása ............................................................................................................... 47
VIII. Összefoglalás .................................................................................................................. 48 IX. Rövidítések ...................................................................................................................... 50 Irodalomjegyzék....................................................................................................................... 51 Ábrajegyzék.............................................................................................................................. 52 Táblázatjegyzék........................................................................................................................ 52
I. ELŐSZÓ A jövő kommunikációs hálózatainak legfontosabb elemei: átjárhatóság a különböző hálózatok között, mobilitás, szélessávú multimédia szolgáltatások [1]. A cél egy olyan világméretű infokommunikációs hálózat kialakítása, amely biztosítja a különböző hálózatok közti barangolás képességét anélkül, hogy a felhasználó ennek a hatásait bármilyen módon érzékelné (a felhasználó szemszögéből a kommunikáció transzparens). Mivel a mozgó terminálok száma az utóbbi években ugrásszerűen megnőtt, az együttműködő hálózatok egyik legfontosabb képességévé a mozgékonyság hatékony kezelése (mobility management) vált [2]. A heterogén struktúrák közötti átjárhatóság biztosításához szükséges, hogy a hálózatok képesek legyenek egy közös kommunikációs felületen, egymással együttműködve kezelni a mozgó terminálok adatforgalmát [4]. A tervezett közös kommunikációs felületet – az IETF által szabványosított IPv6-ot – azzal a céllal tervezték meg, hogy képes legyen kielégíteni a XXI. századi kommunikáció összes igényét és mintegy lefekteti az all-IP hálózatok [3] alapjait. A protokoll szerves részét képezi a mobilitás kezelés támogatása a Mobile IPv6 révén [5]. A rádiós erőforrások szűkössége miatt az átvitel „szűk keresztmetszete” a rádiós hozzáférési hálózat. Az átvitt adatok minősége nagyban függ az átviteli közeg tulajdonságaitól. A jobb minőség megoldható lenne nagyobb sávszélesség-allokációval, a rendszer azonban nem skálázható, hiszen pazarlóan bánik az erőforrásokkal és csak kevés számú felhasználót képes kiszolgálni egy időben. A Quality of Services (QoS, minőségbiztosítás) nagyon fontos eleme a kommunikációnak, a már említett módszerrel azonban – amellett, hogy rugalmatlan – ez nem biztosítható minden körülmények között. A megoldás a hatékony csatorna- és forráskódolási eljárások (együttes) használatában rejlik. Az informatikában a multimédia kommunikáció napjaink egyik legdinamikusabban fejlődő ágazata. Számos helyen alkalmazzák nagy sikerrel (videokonferencia, videotelefon). Az újgenerációs hálózatok elsődleges célja a multimédia kommunikáció hatékony kezelése, hiszen a felhasználói igények mind ebbe az irányba mutatnak, a piac pedig hatalmas. Nem csoda, ha a világ nagy infokommunikációval foglalkozó cégei, szervezetei kivétel nélkül hatalmas lehetőségeket látnak benne és beindították a fejlesztéseket a témában (szabványok készítése, protokollok, alkalmazások, architektúrák fejlesztése) [6]. Ha multimédia kommunikációról beszélünk, akkor két, vagy több ember közti, különböző médiumokon keresztül történő információcserére gondolunk. A történelemben a távirat megjelenése volt az elektronikus média terjedésének hajnala, ami később elvezetett a telefóniához. A telefónia gyorsan teret hódított, és analógból digitálissá vált. A digitális 1
telefónia korszerűsítette a hangátvitelt, ugyanakkor kiszélesítette a személyi kommunikáció multimédiás lehetőségeit is. Megjelentek a szöveges üzenetek, a képek, napjaink feltörekvő médiája pedig a mozgókép, azaz videó médiafolyam, ami a konvergenciafolyamatok eredményeként hamarosan a legkülönfélébb alkalmazásokban és szolgáltatásokban válik elérhetővé. A mobil multimédia új kommunikációs minőségi szintjének a hétköznapi életbe történő egyre gyorsuló megjelenése a következő változásokat eredményezte, és fogja eredményezni a közeljövőben: •
Az új, multimédiás adatforgalmat kiszolgálni képes, megfelelő paraméterekkel rendelkező újgenerációs hálózatok kiváló minőségű és valós idejű hang, kép és mozgókép továbbítást fogják lehetővé tenni.
•
A hangtovábbítást a hagyományos telefonszolgáltatásokon kívül egyrészt híradáshoz, másrészt különböző audio-adatok gyors letölthetéséhez fogják a használni (voice-mail, Hi-Fi minőségű zenék).
•
Az álló- és mozgóképek továbbításának és vételének lehetősége napjaink mobil eszközeinek nagy szolgáltatási potenciálja: lehetővé válik a mozgóképes híradás, a video-ondemand szolgáltatás, videotelefónia, és minden egyéb, multimédia-adatok közvetítését igénylő szolgáltatás használata. A felsorolt fejlesztések és az azokat kihasználó alkalmazások nagy része a harmadik ge-
nerációs rendszerekben már megjelent. A vezetéknélküli kommunikációs technológiák területén végbemenő fejlődés egyre jobb feltételeket teremtett, a fejlődés azonban nem állhat meg, az ipar már a negyedik generáció felé kacsintgat. Egy működőképes rendszer fejlesztéséhez azonban nem elegendő a technológia – a részrendszereket integrálni kell egy összehangoltan működő egésszé. Bizonyosságot kell szerezni továbbá, hogy a hálózat alkalmas lesz feladata elvégzésére, más szóval tesztelni kell a hálózatot. Egy már létező rendszert tesztelni könnyű, hiszen valós eszközökkel, valós forgalmi jellemzőkkel, valós adatforgalommal dolgozunk. Az azonban, amelyik még nem létezik, csak szimuláció segítségével vizsgálható. A szimuláció eredményei pedig akkor adják a leghitelesebb képet, ha a modell a valósághoz a legközelebb áll. Dolgozatunkban bemutatunk egy IPv6 mobilitás szimulátort, illetve annak működését, valamint a szimulátor segítségével elmezzük az IPv6 alapú mobilitás hatásait a multimédia átvitelre. Bemutatunk továbbá egy létező IPv6 teszthálózatot, amelynek segítségével beható méréseket végeztünk annak érdekében, hogy a szimulátor működése a legkevésbé térjen el a valóságtól.
2
II. ÚJGENERÁCIÓS VEZETÉKNÉLKÜLI HÁLÓZATOK A földi kábelezésű kommunikáción (majd később Internet-hozzáférésen) túl hamar felmerült az igény a fix kapcsolatok kiépítését mellőző adatátvitelre, így a vezetékes távközlési rendszerek egyik mellékágaként megjelent mobil kommunikációs módszerek gyorsan fejlődésnek indulhattak. A rádiós távközlés kezdete az 1890-es évekre nyúlik vissza. Nikola Tesla kutatásai és Guglielmo Marconi kísérletei ebben az évtizedben alapozták meg a vezetéknélküli kommunikáció alapjait. Az első mobil kommunikációt szolgáltató cég az 1940-es évek végén jelent meg az USA-ban, és az 1950-es években Európában. Ezekre az egycellás rendszerekre az erősen behatárolt mobilitás, az alacsony kapacitás, a rossz beszédminőség, és a szolgáltatások szegényessége volt jellemző. A fejlődés a celluláris hálózatok megjelenésekor indult meg igazán. Ezek a rendszerek több nagyságrendbeli ugrást jelentettek a kapacitásban és a mobilitásban, így a tulajdonképpeni használhatóság területén. Megjelenésük az 1970-es évek végére, 1980-as évek elejére tehető. Ezeket a rendszereket soroljuk az első generációs kategóriába, hiszen még csak analóg hangközvetítésre voltak képesek (pl.: Advanced Mobile Phone System (AMPS), Nordic Mobile Telephone (NMT-450)). A következő generáció fejlesztésekor az átvitel minőségének javítását, valamint a rendszer kapacitásának és hatósugarának növelését tűzték ki célul. A nagysebességű DSPáramkörök megjelenése lehetővé tette a digitális beszédtovábbítást, valamint a szolgáltatások körének szélesítését. Napjainkban még a különböző második generációs rendszerek az uralkodóak a mobil kommunikációban, ám az új technológiák térhódítása is egyre jelentősebb, hiszen a fejlődés nem állhatott meg.. A harmadik generáció előtt megérkeztek a 2+, vagy a 2.5 generáció újításai: intelligens hálózatok (Intelligent Network, IN) szolgáltatás a CAMEL segítségével (Customized Application for Mobile Enhanced Logic), fejlett beszédtömörítési eljárások (CODEC-ek), Enhanced Full Rate (EFR), és Adaptive Multirate (AMR), nagysebességű szolgáltatások és új átviteli alapelvek megjelenése a High-Speed Circuit-Switched Data (HSCSD), a General Packet Radio Service (GPRS), valamint az Enhanced Data Rates for GSM Evolution (EDGE) által. A harmadik generáció továbblép a 2.5G megoldásain, és egységes architektúrát biztosít a mobil kommunikációhoz. Ez az egységes architektúra az UMTS (Universal Mobile Terrestial Service), melynek levegő interfésze W-CDMA-t (Wideband-Code Division 3
Multiple Access) használ. Az UMTS alapjaiban támogatja a csomagkapcsolt, IP alapú kommunikációt, és sokkal nagyobb teret nyit az adatorientált átvitelnek. A fenti, generációk fejlődését röviden taglaló rész bemutatja, hogy a mobil kommunikáció fejlődésében nagyjából évtizedenként történt a generációváltás. Az 1970-es években használt első generációs (1G) analóg rendszerek, valamint az 1980-as években elterjedt második generációs (2G) digitális rendszerek egyaránt a hangátvitelre voltak kiélezve, és áramkörkapcsolt megoldások voltak. A 2G lefedettsége országosból világméretűvé, internacionálissá vált, és napjainkban is a második generáció a legelterjedtebb architektúra, annak ellenére, hogy a rádiós interfésze néhány tíz Kbit/sec-nél nagyobb adatátvitelt nem tesz lehetővé. Többek között ezt a problémát hivatottak korrigálni a 2.5G és a 3G bizonyos újításai is. Az IMT-2000 (International Mobile Telecommunication-2000), azaz a harmadik generáció napjainkban kezd elterjedni, és 2 Mbit/sec maximális átviteli sebességre képes, ami a tanulmányok szerint egyre növekvő igényeknek nem tud sokáig megfelelni. Az elkövetkező évtizedekben a társadalom és a gazdaság egyre szorosabb kapcsolatba fog kerülni a digitális adatokkal, a digitális tranzakciókkal, s ez nagymértékben kihat majd a hálózatok igénybevételének jövőbeli alakulására. Szinte minden adat és információ digitális formájúvá válik. Az egyre fejlettebb mobil kommunikációs lehetőségek és a teljes digitalizálódás az emberi akciókat térben és időben függetlenné teszik, bárhol és bármikor végezhetünk tranzakciókat adatainkkal. Az elérhető alkalmazások mai testvéreiknél sokkal nagyobb igényeket támasztanak majd a hálózattal szemben, mind az elérhető sebesség, mind a mobilitás, mind a részrendszerek közti átjárhatóság tekintetében. Mozgókép megjelenítése egy terminál képernyőjén, a beszéd jó minőségű közvetítése távközlési célokból, a jövő különböző szolgáltatásai elképesztő mennyiségű, és garantált minőségű adatforgalmat igényelnek. A nemegyszer igen eltérő részrendszerek közti átjárhatóság biztosítása szintén összetett feladat, a kommunikációs elveket közös alapra kell fektetni. Ezekhez a dolgokhoz hatalmas hálózati teljesítményre, új, átgondolt megoldásokra van szükség. Ebből következik, hogy a jövő azoké az újgenerációs mobil rendszereké, melyek a mobil multimédia kommunikációt kívánják globális szintre emelni. A lehetséges szolgáltatások nagy része már a harmadik generációban elérhető lesz, azonban a felhasználók várhatóan ki fogják nőni a 3G rendszerek által biztosított lehetőségeket. A harmadik generációs architektúra nagyon nehézzé teszi a sávszélesség további növelését, nehezen tudja kezelni az egyre növekvő igényeket a beszédátvitellel kombinált letöltésekre. Az új generációk megjelenése azonban nem csak a rendelkezésre álló sávszélesség növekedését fogja okozni, hanem a rendelkezésre álló szolgáltatások skáláját is szélesíteni fogja, valamint a szolgáltatások QoS 4
kezelését is tökéletesíti majd. A sávszélesség növelése a rendelkezésre álló spektrum minél nagyobb hatásfokú kihasználásával válik lehetővé, ami dinamikus valamint önkonfiguráló technológiák, újrakonfigurálható rendszerek bevezetésével érhető el. A rádiós kommunikáció magas szintű szoftveres vezérlésével (és így bizonyos helyzetekben alternatív kommunikációs módszerekre való áttéréssel) elérhető a spektrum optimális kihasználása. Az újgenerációs mobil végberendezések szinte teljes mértékben platform-függetlenek lesznek, hála az IP alapú kommunikációnak. Intelligens szoftver-ügynökök teszik majd lehetővé, hogy mindig az optimális ár/teljesítmény arány jöjjön létre a környezeti feltételek lehető legjobb alkalmazásának eredményeképpen [1],[2]. A távvezérlő alkalmazások, az adatletöltés, az elektronikus vásárlás, általánosságban a kommunikáció egyszerűbb és olcsóbb lesz. A mobil kommunikáció fejlődése tehát a flexibilis, teljesen QoS-képes, univerzális és multifunkcionális, IP alapú mobil kommunikációs hálózatok kialakulása felé vette az irányt.
IPv6 - Mobile IPv6 Az IPv6 [18] megalkotásakor nem kizárólag az IPv4 hibáit próbálták megszüntetni, hanem új szolgáltatásokat és lehetőségeket is megpróbáltak beépíteni. Ezek az új lehetőségek igyekeznek az IPv6-ot gyorsabbá, robosztusabbá tenni, valamint az új hálózati és felhasználói igényeknek megfeleltetni. A megnövelt címtartomány lehetővé teszi a topológiához jobban illeszkedő címzési és útvonalválasztási megoldások használatát. Az IPv6-ban nem csak az unicast címek használata lett egyszerűbb, hanem a multicast típusú címeké is. A multicast és unicast címeken túl megvalósították az anycast típusú címzést is, mely az interfészek csoportjából egyet képes megcímezni. (A broadcast típusú címzés nem létezik az IPv6-ban, hiszen ennek szerepét a multicast vette át.) Az IPv6-os fejléc struktúrája is egyszerűsödött az IPv4-hez képest. Számos eddig kötelező mező opcionálissá vált, így az IP csomagok feldolgozása nagyban egyszerűsödött. Az opcionális mezők kezelése egyszerűbb és általánosabb lett, biztosítva az IPv6 továbbfejleszthetőségét, és flexibilisebb alkalmazását. Az IPv4-ben alig alkalmazott QoS mezőket eltávolították, szerepüket egy sokkal általánosabb és használhatóbb mechanizmus vette át, mely a „flow” nevet viseli. Az IPv6-ban lehetőséget nyitottak a „virtuális adatcsomag útvonal”-ak kialakítására, így az korlátozott mértékben alkalmas vonalkapcsolt jellegű szolgáltatások biztosítására is. Ez a tulajdonság a multimédia és műsorszóró alkalmazások esetén igen hatékony. Az IPv6 továbbra is tartalmaz prioritás mezőt, ami segítségével a routerek válogathatnak a feldolgozandó csomagok között. 5
(Az ajánlás magában foglalja azt is, hogy a különböző prioritásokhoz milyen típusú forgalmat célszerű rendelni.) Az IPv6 képes hálózati szinten lehetőséget nyújtani titkosítás és hitelesítés alkalmazására is, mely természetesen felsőbb rétegekben alkalmasan kiegészíthető. Fontos tulajdonsága az IPv6-nak, hogy támogatja a mozgó csomópontok kezelését (Mobile IPv6) [5], valamint az egységek automatikus hálózati konfigurálását. Így sokkal hatékonyabban hozhatók létre és tarthatók üzemben a mobil IP rendszerek, valamint a nagyméretű hálózatok. A Mobile IPv6 protokoll segítségével válik kezelhetővé az IP szintű mobilitás: Mobile IPv6 nélkül a mozgó hoszt új IPv6 hálózatba érve nem lenne képes folytatni a kommunikációt. A honi hálózatban létezik egy honi ügynök (Home Agent, HA), amely nyilvántartja a mobil egység aktuális tartózkodási helyét és címét. Minden mobil egységnek van egy otthoni címe (Home Address, HA), amelyen az mindig elérhető. Ha a terminál hálózatot vált, értesíti erről honi ügynökét, aki beregisztrálja a az otthoni címéhez a mobil egység aktuális címét (Care-of Address, CoA). Ha a mobil terminállal más kíván kommunikálni, a küldő az adatot elküldi annak otthoni címére. Mivel a címzett nem tartózkodik ott, ezért a honi ügynök egy alagúton keresztül eljuttatja a neki szánt adatot, amire aztán már válaszolni tud közvetlenül a küldőnek. Ez azonban háromszögeléshez vezethet (1. ábra), ami miatt az útvonal nem optimális. Ezért a kommunikációs partnert is értesítenie kell címének megváltozásáról. Miután ez megtörtént, a kommunikáció a honi ügynök közreműködése nélkül folytatódhat.
1. ábra: Háromszögelés és kivédése a Mobile IPv6-ban
6
III. PHOENIX FP6 IST-001812 PROJEKT Az Európai Unió által támogatott Phoenix FP6 IST-001812 projekt [6] célja egy olyan architektúra kifejlesztése, amely a XXI. századi multimédia kommunikáció igényeit maradéktalanul kielégíti, ugyanakkor a hálózat komplexitása, bonyolultsága nem növekedik drasztikusan, és könnyen átkonfigurálható. Az architektúra alapjául a JSCC/D (Joint Source Channel Coding and Decoding, Egyesített Forrás Csatorna Kódolás és Dekódolás) technológia szolgál. Az eddigi kommunikációs rendszerek moduljai egymástól függetlenül végezték az optimalizálást, a modulok között kommunikáció nem zajlott. A JSCC/D szakít ezzel a megközelítéssel (és egyúttal az OSI modell szemléletével). A modulok együttműködése, kommunikációja a forgalom optimalizálásának hatékony módja; ezáltal a rendszer teljesítményében jelentős javulások figyelhetők meg. Az ötlet már a XX. század végén megszületett, a technológia azonban csak a XXI. század elejére fejlődött olyan mértékben, hogy az elmélet mellett a gyakorlatban is lehetséges legyen a megvalósítása – az egyes alkotóelemek között korábban nem volt egy olyan összetartó erő, amely egy egységbe szervezte volna a komponenseket.
Architektúra Az ábrán a JSCC/D architektúra elemei láthatók (2. ábra).
2. ábra: A JSCC/D-n alapuló hálózati architektúra blokkvázlata
7
Amint az ábrán is látható, egyes blokkok információt cserélnek egymás között. Ezek a jelzések alkotják az információs csatornákat a blokkok között és vezérlési információkat szállítanak az optimalizációt végző vezérlő egységnek (Joint Controller, Egyesített Vezérlő Elem). Az alábbiakban rövid betekintést nyújtunk az architektúra építőelemeibe és ezek öszszekapcsolódási módjaiba.
Jelzések SSI (Source Significance Information, Forrás Fontossági Leíró) A forrás oldali videó kodek küldi a vevő oldali fizikai rétegnek, a médiafolyammal szinkronizálva. A folyam minőségéről nyújt információkat. CSI (Channel State Information, Csatorna Állapot Leíró) A médiafolyammal ellentétes irányú, nem szinkronizált. A vevő oldali demodulátor a forrás oldali videó kodeket tájékoztatja az átviteli csatorna minőségéről. SAI (Source A posteriori Information,Forrás Minőség Leíró ) A vevő oldalon a videó kodek küldi a fizikai rétegbeli vezérlőnek, amelyben tájékoztatja a forráskódolót az átvitel hatékonyságáról. Nem szinkronizált. DRI (Decoder Reliability Information, Dekódoló Megbízhatósági Leíró) A vevő oldali fizikai réteg továbbítja a vevő oldali alkalmazási rétegnek, a médiafolyammal szinkronizálva. A jelzés a videó kodek számára szolgáltat szükséges információkat a médiafolyam visszaállításához. NSI (Network State Information, Hálózati Információk) A jelzés csak az IPv6 hálózat számára szükséges, számos hálózati állapotot leíró paramétert tartalmaz.
Alkotóelemek Joint Controller Az architektúra legfontosabb eleme a Joint Controller. Hatékony működéséhez szükséges, hogy mind az alkalmazási (forráskódolás), mind a fizikai (csatornakódolás) rétegben képes legyen hatni a forgalomra. Ez az oka annak, hogy az architektúra szakít az OSI modellben alkalmazott szemlélettel, vagyis azzal az elvvel, hogy minden réteg független az alatta, illetve felette elhelyezkedő rétegektől. A vezérlő fő feladata a teljes kommunikációs lánc vezérlése, melyet a forrás és a csatorna kódoló/dekódoló, valamint a modulátor/demodulátor blokkok szabályozásával hajt végre. Az adaptív működést az ide beérkező jelzések biztosítják. Source encoder/decoder (Forrás kódoló/dekódoló) A forrás kódolók teljesítménye az utóbbi években látványosan javult, és olyan kódolok láttak napvilágot, amelyek tömörítő képessége nagymértékben növekedett, illetve képesek 8
adaptív működésre is (MPEG-4 AVC, H.264) [9]. Sajnos azonban semmiféle információval nem rendelkeznek az átviteli csatorna jel-zaj viszonyáról (SNR, Signal to Noise Ratio), így önmaguktól nem képesek kiválasztani a hatékony kódolási sémákat, ehhez külső segítségre van szükségük. Titkosítás (Ciphering) Az adatokat megfelelő védelemmel ellátva azok mindvégig rejtettek maradnak illetéktelenek előtt. Továbbá biztosítani kell a letagadhatatlanságot és az adatok sértetlenségét is. Azonban a különböző típusú adatok nem igényelnek egyformán erős védettséget. A titkosító feladata ezen szükséges védelem meghatározása. Channel encoder/decoder (Csatorna kódoló/dekódoló) A csatornakódolás lényege, hogy az átvitt folyamba redundáns elemeket illesztünk, melynek segítségével a megbízhatatlan rádiós átviteli csatornán ellensúlyozzuk a zaj, illetve fading (nem determinisztikus csillapítás) káros hatásait. A kódolók többsége fix kódot használ és nem képes alkalmazkodni a rádiós csatorna folyamatosan változó tulajdonságaihoz, más szóval a csatorna nem idő-invariáns. Léteznek azonban újabb kódolók (AMR, AdaptiveMulti-Rate), amelyek képesek rugalmasan alkalmazkodni az átviteli csatorna adottságaihoz. Ezek a kódolók nagyobb hatékonysággal képesek működni, mint nem adaptív társaik. IPv6 hálózat Szükség van egy olyan rétegre is, amely a vezérlési információkat szállítja. Az IPv6 (és ICMPv6) egy alkalmas protokoll erre a feladatra. Egy IPv6 csomag három részből áll: állandó fejrész (mandatory header), kiegészítő fejrészek (extension headers), adat (payload). Számunkra különösen két kiegészítő fejrész érdekes: a Hop-by-hop, illetve Destination option fejrészek alkalmasak a modulok közötti információcserére. Míg a Hop-by-hop fejrészt minden csomópont feldolgozza (amelyik csomópont nem ismeri fel a fejrészt, az egyszerűen kihagyja), addig a Destination fejrész csak a cél csomópont számára nyújt információkat. A modulok közti jelzésinformációk ezekben a kiegészítő fejrészekben utaznak.
9
IV. AZ ALAP SZIMULÁCIÓS LÁNC („BASIC CHAIN”) A PHOENIX által megtervezett JSCC/D architektúra szimulációja az úgynevezett „Alap szimulációs lánc” vagy „Basic chain” elnevezésű keretrendszer segítségével történik. A keretrendszer tartalmazza az egyes modulokat, azok sorrendjét, valamint összekapcsolási módjukat. A keretrendszert elsősorban Debian/GNU Linux környezetbe tervezték, de egyéb Linux disztribúciókkal is működőképes. A modulok nagyobb részben C, kisebb mértékben C++ és Java nyelven készültek.
Modulok és összekapcsolódásaik Ahogy az egy moduláris rendszertől elvárható, a nagy, elkülönülő feladatokat különálló modulok végzik. A modulok listája alkalmazásuk sorrendjében: •
Application Controller (vezérlő)
•
MPEG-4 Encoder (MPEG-4 kodek)
•
Pre Packetizer (médiafolyam csomagolása, darabolása)
•
Content Ciphering (titkosítás)
•
UDPLite (szállítási réteg)
•
IPv6 Network (hálózati rétegbeli továbbítás)
•
Data Link Layer (közeghozzáférési réteg)
•
Radio Channel (rádiós közegen való továbbítás) A médiaátvitel szimulált hálózaton keresztül történik, amelyet a Basic Chain [10] vezé-
rel . Maga a médiafolyam egy yuv kiterjesztésű videófájl, a szimuláció ezt a médiafájlt darabolja 1 másodperces szeletekre (ha nem elég hosszú a videó, a feldolgozás a videó elejéről kezdődik ismét, így tetszőlegesen hosszú szimuláció futtatható). A szeleteket a keretrendszer egyesével, egymás után küldi a szimulátor bemenetére. Ezeken a szeleteken hajtja végre a szimulációs lánc a megfelelő módosításokat, majd a futtatás után összerakja azokat ismét egy egésszé. Az átvitel során elszenvedett hatásokat ezen a videón lehetséges vizsgálni. A szimuláció során a médiafolyam valójában nem hagyja el a szimulációs környezetet, ehelyett a modulok egymás között fájlok segítségével kommunikálnak. Más szóval a modulok közti kommunikációs csatorna (ami megfelel az OSI rétegek közötti adatáramlásnak) egy speciális fájl (bővebb leírást lásd alább). Miután az egyik modul beolvasta a bemenetére érkező adatokat és azokon végrehajtotta a megadott módosításokat, a végeredményt egy, a bemenettel megegyező formátumú fájlba írja. Minden modulnak képesnek kell lennie értelmezni a fájlt, ezért az értelmező (parser) is egy különálló modulban kapott helyet. Az értel10
mező modul segítségével a többi modul egy egységes interfészen keresztül képes elérni és módosítani a médiafolyamot. A jelzési információk egyrészt a csomagban haladnak (SSI értékek sorozata), valamint átmeneti fájlokban tárolódnak, amelyekhez minden modul hozzáférhet, ha szükséges.
Formátumok Multimédia fájlok Az eredeti és módosított (átvitel utáni) fájl kiterjesztése és típusa egyaránt yuv, mely a MPlayer nevű, több platformra is létező professzionális multimédia lejátszó segítségével tekinthető meg: mplayer -rawvideo on:cif:fps=30 dectot.yuv
Átmeneti fájlok Modulok közti kommunikációs csatorna A szimulációs láncon belüli kommunikációra egy speciális fájlformátum használatos, melynek a kiterjesztése pho. Az ilyen kiterjesztésű fájlok csak átmenetiek, a modulok közötti adatcsatornát hivatottak szimbolizálni. Felépítése is erre utal, ugyanis hálózati csomagokhoz hasonló adategységeket tárol. Minden egyes adategység áll egy fejrészből, illetve egy hasznos teher részből. Az adategység (a továbbiakban csomag) legelső eleme (tulajdonképpen nulladik, hiszen nem része magának a csomagnak) egy időbélyeg, amely a csomag feldolgozási idejét jelöli és szinkronizál a modulok közti aszinkron kommunikációban. A további elemek mindegyikét egy megnevezés előzi meg, amely az adat jelentését adja meg. Ezek az elemek ’[’ és ’]’ zárójelek között helyezkednek el. A fejrész elemei: •
Packet number (csomagsorszám): a csomag sorszámát jelöli.
•
Frame number (képkocka sorszáma): ez a mező jelzi, hogy az adat a videó melyik képkockájához tartozik.
•
Loss flag (elveszett): mivel a valóságban elveszhetnek csomagok, a szimuláció során ezt valamilyen módon jelölni szükséges. Ha a szimulációban – valamiért – a csomag elveszett, az a kimeneti fájlban nem mint hiány jelenik meg, hanem az aktuális modul állítja be ezt az értéket. A „jelzőbit” kifejezés ebben az esetben nem szerencsés, ugyanis számos oka lehet, hogy az adategység elveszett. A különböző számértékek különböző hibákat jelölnek (11: hálózati szinten elveszett, 5: CRC hibás stb).
•
Size (hasznos teher méret): az érték a fejrész mérete nélkül értendő.
•
SSI: A hálózaton átvitt SSI információk sorozata 11
•
IP header size (IP fejrész hossza)
•
IP header (IP fejrész)
•
IP delay (IP késleltetés): a hálózati rétegben a csomagok késleltetését adja meg.
•
Cipher (titkosító kulcs): ezzel a kulccsal titkosítják az adatot.
•
Payload (hasznos teher): a médiafolyam darabjai
Visszacsatolások Mivel a szabályozó körben fontos a visszacsatolás, itt sem maradhat el. A visszacsatolási információk fbk kiterjesztésű fájlokban utaznak, amelyek az alkalmazási, hálózati, illetve fizikai rétegek számára szükségesek és az előző 1 másodperces szelet átviteléről nyújtanak információt.
Szimuláció futtatása A szimuláció futtatásához három shell szkript áll rendelkezésre: •
cleanWorkspace.sh: Eltávolítja az ideiglenes pho és fbk fájlokat.
•
fp6-bc-mpg4.sh: Ez a fájl tartalmazza magát a szimulációs láncot és leírja a modulok sorrendjét. Feladata továbbá az információs csatornák kezelése a modulok között. A szkript egyetlen paramétere az átvitel szimulációjának iterációszáma. Egy iteráció egy másodpercnyi adat küldését és fogadását végzi.
•
run-4dB-adapt_YES.sh: A szkript a lusta informatikusoknak készült, egyszerűen meghívja a szimulációs láncot egy előre megadott paraméterrel. Ez alapértelmezésben 64, de természetesen a fájl szerkesztésével átállítható.
12
V. IP MOBILITÁS SZIMULÁTOR Az IP mobilitás szimulátor modul célja, hogy – kiegészítve az szimulációs láncot – vizsgálni lehessen, milyen változások történnek a médiafolyamban az IP szintű mobilitás kezelés hatására. Az általunk tervezett és implementált új modulnak több fontos követelményt kellett kielégítenie: •
A modulnak illeszkednie kell a már említett Basic Chain keretrendszerbe.
•
A modulnak önmagában is működőképesnek kell lennie a megfelelő bemenetek hatására.
•
Valós Mobil IP hálózatok működését kell tükröznie.
A szimulátor felépítése A szimulátor, melyet C nyelven írtunk, maga is moduláris felépítésű, az egyes részeknek jól elkülöníthető feladatai vannak. Az IPv6 mobilitás modul szerkezete (3. ábra) négy kisebb részre, valamint a közösen használt funkciókra, illetve az egyes almodulokhoz tartozó konfigurációs fájlokra bontható. (A továbbiakban a modul megnevezés jelöli mind a szimulációs láncba tartozó modulokat, mind a mobilitás modul egyes almoduljait. A szövegkörnyezetből egyértelműen kideríthető, mikor melyik jelentése használatos.) A modulok egy-egy, a modulról elnevezett könyvtárban találhatók. A közösen használt fájlok, illetve a konfigurációs fájlok (cfg kiterjesztés) az előbb említett könyvtárakkal egy szinten találhatók.
3. ábra: IPv6 mobilitás szimulátor blokkvázlata
13
Mozgásmodellező modul Egy cellás felépítésű mobil hálózatban a mozgó termináloknak mozgásuk során – bizonyos esetekben cellát (és egyúttal frekvenciasávot) kell váltaniuk. A cellaváltásokat a szakirodalom handover-nek hívja. A mozgásmodellező modul célja különböző mozgásmodellekkel olyan sorozatok generálása, amelyből statisztikai módszerekkel a cellaváltások száma és ideje becsülhető lesz.
Mozgásmodellek Dinamikusan fejlődő világunkban egyre több embernek adódik meg a lehetőség, hogy valamilyen vezeték nélküli hálózatot igénybe vegyen, legyen az mobiltelefon hálózat vagy vezeték nélküli számítógépes hálózat. A felhasználók számának rohamos emelkedésével a nagy forgalmú helyeken (pl. városok) csak úgy maradhat a szolgáltatás szintje állandó, ha csökkentik a cellák méretét, ezért megjelentek a mikro- és pikocellák. A hálózat tervezőinek egyik legfontosabb feladata, hogy az erőforrásokat minél gazdaságosabban osszák szét és a hálózat minél több felhasználót szolgálhasson ki. A felhasználók mozgásának minél pontosabb jóslásával a hálózat kihasználtsága közelít a maximum felé. Ebben a feladatban segítenek a tervezőknek a mozgásmodellek, amelyek a felhasználók mozgásait szimulálják egy valós vagy képzeletbeli területen [11]. A modellek alapvetően háromféleképpen hasznosíthatóak: •
Egy már létező hálózat szimulációja során próbálnak ki új protokollokat és vizsgálják azok hatását a sávszélesség kihasználtságra, stb.
•
Még megvalósítatlan hálózatokban szimulálják a felhasználók mozgásait, hogy a tervezett rendszer hibáit felderítsék
•
Felhasználók számának előrejelzése egy adott cellában és környezetében. A mozgási modellek lehetnek egyediek vagy csoportosak. Az egyediekben minden
egyes felhasználó önállóan, a többiektől függetlenül mozog, míg a csoportosban az egyes felhasználók függenek egymástól (ilyenek például az autók az úton, vagy az utasok a vonaton). Manapság kétféleképpen modellezik a felhasználók mozgását egy hálózat szimulációja során: •
Mozgásnyomvonalakkal (Mobility traces),
•
Matematikai mozgásmodellekkel. A mozgásnyomvonalas modellezés valós méréseken alapul. Egy kiszemelt területen
vizsgálják a felhasználók mozgásait bizonyos ideig, aztán ezekből az adatokból kiszámolnak a felhasználókra jellemző mozgási adatokat, majd ezekkel az adatokkal szimulálják a területen 14
a felhasználókat. Minél több ideig vizsgálják a területet, elvileg annál jobban tudják később modellezni a felhasználók mozgásait. A matematikai mozgásmodelleken alapuló szimulációkhoz nincsen szükség előzetes megfigyelésre, ugyanis a felhasználók valamilyen matematikai mozgás leírás alapján mozognak a területen. Ha jó a modell, akkor megközelítőleg azonos eredményt kell hoznia, mint a mozgásnyomvonalas modellek. Esetünkben egyedi mozgásmodelleket használtunk, hiszen vizsgálódásunk célja a cellaváltások hatásainak megfigyelése egy adott médiafolyamra. Modelljeink között szerepel mozgásnyomvonalas és matematikai mozgásmodell is. A mozgásmodellező modul feladata, hogy bemeneti adatokat szolgáltasson a kalkulátor modulnak, azaz egy kimeneti fájlban meg kell adnia, hogy a felhasználó mozgása során mikor történt cellaváltás. A használt szimulációs terület látható a 4. ábra:
4. ábra: Szimulációs terület
Handoveres vektoros Random Walk modell Ahhoz, hogy a Handover vektoros Random Walk modellt megérthessük meg kell vizsgálnunk annak ősét, a Random Walk (Véletlen Séta) modellt. Matematikailag ezt a modellt még Albert Einstein írta le először 1926-ban. A modell nagyon elterjedt, hiszen nagyon egyszerű és jól használható, hátránya azonban, hogy túl általános. Lényege, hogy a mozgó felhasználók sebességet és irányt választanak maguknak majd elindulnak abba az irányba a választott sebességgel. A sebességet egy [0,Vmax] intervallumból választja, míg az irány a [0,2π] intervallumból kerül ki, mindkettőt egyenletes elosztású valószínűségi változó. Ha megvan az új irány és sebesség, a mobil egy-
15
ség vagy adott ideig halad egy irányba vagy pedig adott út megtételéig (5. ábra). Ha a mobil egység elér a terület határára, onnan „visszapattan”.
s
s
t
s
t t
s s s
t
t
s
t
t
t
Egy előre meghatározott idő (t) letelte után vált sebességet és irányt a mobil terminál (ekkor a nyilak hossza változik)
Egy előre meghatározott távolság (s) megtétele után vált sebességet és irányt a mobil terminál (ekkor a nyilak hossza mindig s hosszúságú).
5. ábra: Handover vektoros Random Walk modell változatai
Mivel a mi célunk a nem a mobil egység pontos helyének meghatározása, hanem a cellaváltások szimulálása, ezért egyszerűsítettem a modellen. A mobil eszköz egyszerre csak egy cellát léphet és cellaközépponttól cellaközéppontig halad. A számunkra szükséges információ csak annyi volt, hogy a terminál áthaladt-e egy cellahatáron, vagy nem. Mivel a Random Walk modell eddig kevéssé közelítette a valóságos mozgást, kiegészítettük egy olyan elemmel, amely lehetővé teszi, hogy valós hálózatokból gyűjtött adatokkal inicializáljuk a rendszer. Ez az elem a handover vektor (6. ábra).
p4
p5 p6
p3 k
p1
p2
h k [i ] = [ p1 , p2 , p3 , p4 , p5 , p6 ] 6. ábra: A handover vektor értelmezése
Minden egyes cellához (a szimulációban 45 cella van) hozzárendelünk egy hét elemű vektort. Az első hat elem azt határozza meg, hogy a lehetséges hat irány közül mekkora való16
színűséggel fog abba az irányba távozni a mobil egység. A hetedik érték a cellában maradás 7
valószínűsége. Mivel valószínűségekről beszélünk, ezért minden cellára igaz, hogy
∑p i =1
i
= 1.
Módosított Markov modell Számos Markov-modell létezik amelyet mozgásmodellezésre használnak, de ezek jó-
részt eléggé bonyolultak. A célunk az volt, hogy minél egyszerűbb modelleket alkalmazzunk. Ezért egy egydimenzós modell két dimenziósra való kiterjesztését használtuk fel [12]. Az egy dimenziós Markov-modell könnyen érthető. Adottak a cellák egy sorban, egymás mellett (egy dimenzióban). Ekkor különböztessünk meg három állapotot: •
„Marad” állapot: S (Stay State)
•
„Jobbra” állapot: R (Right State)
•
„Balra” állapot: L (Left State)
Ha az eszköz Marad állapotban van, akkor a következő döntési lépésnél nem megy sehová, hanem marad a jelenlegi cellájában. Ha Jobbra állapotban van, a következő döntésnél jobbra fog mozdulni. Ha Balra állapotban van, a következő döntésnél balra fog mozdulni. Természetesen minden állapotban más a valószínűsége annak, hogyan jut a terminál a másik két állapotba. Ez a modell nagy előnye, hiszen ha egyszer már Jobbra állapotban van az eszköz, akkor valószínű, hogy továbbra is jobbra fog mozogni, tehát az aktuális döntés függ az előző döntéstől is! 1-p1-p2
S 1-q1-v2
1-q2-v1 p1
q1
L
p2 v1
R
q2
v2
7. ábra: Markov lánc állapotátmenetei
A választott modell az egydimenziós modellt kétdimenziósra kiterjesztve egyszerűsítést végez (8. ábra). Egy cellából egyszerre csak egy Jobbra vagy Balra irányt választunk, majd csak ez után döntünk a lehetséges három cella között.
17
L Osztóvonal
l3 l2
r3 0
l1
r2 r1
R 8. ábra: Egy dimenzós döntés a cellában
Gauss-Markov modell A modell szerint a mobil terminál adott időintervallumonként változtatja sebességét és
irányát a szimuláció során. Az n-edik időintervallumban a sebesség és az irány is függ az (n1). időintervallumban az aktuális sebességtől és iránytól, illetve egy valószínűségi változótól is. Az n-edik időintervallumban a sebesség és az irány kiszámítására a (1.) és (2.) képletek alkalmazhatók: s n = α ⋅ s n −1 + (1 − α) ⋅ s + (1 − α 2 ) ⋅ s x n −1
(1.)
d n = α ⋅ d n −1 + (1 − α) ⋅ d + (1 − α 2 ) ⋅ d x n −1
(2.)
Az sn, illetve dn jelentik az új sebességet és az új irányt az n-edik időintervallumra. Az
s illetve d konstansok reprezentálják a fő irányt és fő sebességet. Utóbbi változó a szimulációs terület különböző részein más és más lehet. Az egyenletek végén szereplő s x n −1 és d x n −1
Gaussi eloszlást követő valószínűségi változók. A modellben szereplő α nulla és egy között vehet fel értékeket. Ezzel a változóval szabályozhatjuk, hogy mozgás mennyire legyen véletlenszerű. Ha például α=0, akkor a folyamat teljesen véletlen, ha pedig α=1, akkor sem a sebesség, sem az irány nem változik az egyes időintervallumok során. Ez a képletből is jól látható. Miután a fenti egyenletekkel meghatároztuk az n. intervallum sebességét és irányát, a következő képletekkel – (3.) és (4.) – meghatározhatjuk a mobil egység új koordinátáit:
x n = x n −1 + s n −1 ⋅ cos d n −1
(3.)
y n = y n −1 + s n −1 ⋅ sin d n −1
(4.)
ahol (xn,yn), illetve (xn-1,yn-1) a mobil terminál x, y koordinátái az n., illetve (n-1). időintervallumban.
18
Annak érdekében, hogy egy szimuláció során ne legyen az eszköz viszonylag hosszú ideig a szimulációs terület határán, ezért a főirány konstanst módosítani kell a terület határán 180 fokkal.
9. ábra: A főirány változása a szimulációs terület szélén
Módosított Határ nélküli szimulációs terület modell A szakirodalom ezt a modellt Boundless Simulation Area modellként (BSAM) ismeri.
Ez a modell az előbbihez nagyon hasonló, csak az új koordináták kiszámításánál és a határkezelésben vannak különbségek. A modellben létezik egy v = ( v, Θ) sebesség vektor, ebben v jelenti a sebességet a Θ szög pedig az aktuális irányt. A lenti paraméterek ∆t időnként frissülnek a következő egyenletek szerint: v( t + ∆t ) = min[max(v(t ) + ∆v,0), Vmax ]
(5.)
Θ(t + ∆t ) = Θ(t ) + ∆Θ
(6.)
x (t + ∆t ) = x (t ) + v(t ) ⋅ cos Θ(t )
(7.)
y(t + ∆t ) = y(t ) + v(t ) ⋅ sin Θ(t )
(8.)
Vmax a maximális sebesség, ∆v a sebességben bekövetkező változást adja meg, értékét a
[− A max ⋅ ∆t, A max ⋅ At ]
intervallumból veheti fel egyenletes eloszlás szerint. Amax az adott
mobil egység maximális gyorsulása. ∆Θ pedig az irány változását adja meg [− α ⋅ ∆t , α ⋅ ∆t ] tartományból egyenletes eloszlással. α jelenti azt a maximális szöget, amivel a mobil terminál megváltoztathatja irányát egy adott időtartományon belül. Ez a modell másképp kezeli azt a helyzetet, amikor a mobil terminál eléri a szimulációs terület határát. Az eddig tárgyalt modellekben a mobil terminál visszafordult. Ebben a modellben
19
viszont ha a felhasználó eléri a terület szélét, úgy folytatja útját, hogy a szemközti oldalon lép be újra a szimulációs területre. Ha az alsó vagy felső oldalon távozik, x koordinátája változatlan marad, ha pedig bal vagy jobb oldalon hagyja el a területet, y koordinátája marad ugyanaz.
A modul működése A program futtatásakor négy parancssori paramétert kell megadni, ellenkező esetben a program hibaüzenettel leáll. A paraméterek sorrendben: •
MinStayTime: az a minimális idő, amíg az egység a cellában marad (ezredmásodpercben)
•
MaxIdleTime: az a maximális érték amíg nem dönt új irányról a program
•
Deterministic: determinisztikusságot meghatározó érték (ha a szám negatív, a program nem determinisztikusan fut, tehát minden futtatáskor más kimenetet ad ugyanazokra a bemenetekre, ha a szám 0 vagy pozití, ezzel a számmal inicializálja a program a véletlenszámgenerátorát
•
HandoverCount: megadja, hogy a kimeneti fájlban egy futtatás alatt hány handover időpontra vagyunk kíváncsiak.
Konfigurációs fájlok A modul négy féle mozgásmodellt implementál, ezért négy konfigurációs fájlra van szüksége, mindegyik fájlban mozgásmodell-specifikus adatok találhatók. Mindegyik kimeneti fájl n darab sort tartalmaz, mindegyik sorban azok az időpillanatok láthatók, amikor cellaváltás történt. Handover vektoros random Walk modell A konfigurációs fájl neve: mm1in.cfg. A fájl tartalmazza az induló cella koordinátáit, a
szimuláció iterációinak számát, valamint a handover vektorokat mindegyik cellához. A generált kimeneti fájl neve: mm1out.txt. Módosított Markov modell A konfigurációs fájl neve: mm2in.cfg. A fájl tartalmazza az induló cella koordinátáit, a
szimuláció iterációinak számát, valamint a Markov lánc átmenetvalószínűségi 9 elemű mátrixát (10. ábra). A generált kimeneti fájl neve: mm2out.txt.
10. ábra: Markov lánc
20
Gauss–Markov modell A konfigurációs fájl neve: mm3in.cfg. A konfigurációs fájlban a következő értékek
adottak: •
sn-1 és dn-1 kezdeti értékei
•
s és d kezdeti értékei ( d változhat a program futása során, s nem lehet nagyobb, mint az R cellasugár)
•
(x n −1 , y n −1 ) kezdeti értékei
•
α
•
R (cellák sugara x,y koordinátarendszerben lévő egységekben, R>5)
•
döntések száma A generált kimeneti fájl neve: mm3out.txt. Ha a mobil egység átlépi a határt, akkor visszakerül a határra és a fő iránya 180 fokkal
módosul. Módosított Határ nélküli szimulációs terület modell A konfigurációs fájl neve: mm4in.cfg. A konfigurációs fájlban a következő értékek
adottak: •
x és y kezdeti értéke
•
iterációs szám, amely a döntések számát jelenti
•
Vmax (nem lehet nagyobb, mint R)
•
∆v maximális és minimális értéke
•
∆θ maximális és minimális értéke
•
R cellasugár
A generált kimeneti fájl neve: mm4out.txt Az első két modell a mozgásnyomvonalas kategória képviselője, tehát a hálózatból előre gyűjtött adatokra van szüksége a működéshez (ezekhez a modellekhez mi generáltunk bemeneti értékeket), míg az utóbbi kettő modell matematikai leírásokkal próbálja szimulálni a mobil egység mozgását, ehhez előzetes mérési adatok nem kellettek.
Kalkulátor modul A kalkulátor modul rendeltetése kettős. Feladata elsősorban a mozgásmodellező modul felől (illetve a mérésekből származó eredményekből) érkező bemenet feldolgozása és kiértékelése, másodsorban a szimulációs modul konfigurációs fájljának feltöltése megfelelő adatokkal.
21
Mivel több helyről szerzi a működéséhez szükséges adatokat, több bemeneti csatornája van. Első bemeneti csatornája a mozgásmodellező által készített bemeneti fájl, melynek egy sora látható itt: 3020,5432,10045,19821,34449…
A számok ezredmásodpercben értendők, a felsorolt időpillanatokban történik meg a cellaváltás. A fájlban minden egyes sor a mozgásmodellező modul egy új futtatásából származik. Ebből az adathalmazból a modul statisztikai módszerekkel előállítja a cellaváltások között eltelt idő várható értékét és szórásnégyzetét. A mérések n eleműek, így n
X=
∑X i =1
n
i
, M (X) = m
(9.)
ahol X i az i. n elemű méréssorozat, X a méréssorozatok statisztikai mintaátlaga, m pedig a mintaátlag várható értéke. A tapasztalati szórásnégyzet kiszámítása a n
2
S
n
=
(X 1 − X) + (X 2 − X) + ... + (X n − X) = n 2
2
2
∑ (X i =1
i
n
− X) 2 (10.)
képlet segítségével történik. A modul másik bemenete méréseink eredményeiből származik. Mivel a mérésekhez felhasznált szoftverek naplófájljaiból a cellaváltásokból származó késleltetés (handover latency), illetve az elküldött csomagok késleltetésének szórásnégyzete és várható értéke kiolvasható, a modulnak nem szükséges nagy számú mérési mintából azokat előállítania. Egyszerűen kiszámolható az adatok várható értéke (jelen esetben az egyforma előfordulási valószínűségek miatt megegyezik az átlaggal), ami bekerül a szimulátor modul konfigurációs fájljába. A várható érték kiszámítása tehát egy egyszerű átlagszámítási művelettel megoldható. Az x helyére a megfelelő tulajdonság behelyettesíthető: n
M(x) =
∑x i =1
n
i
(11.)
Szimulátor modul A szimulátor modul feladata, hogy a valószínűségi változók tulajdonságai (várható érték, szórásnégyzet) által adott értékekből a végrehajtó modul számára konkrét futtatási sorozatot készítsen. A modulnak két bemeneti paramétere van, az első a végrehajtó modul által módosítani kívánt pho fájl, a második pedig egy egész szám, amely inicializálja a
22
véletlenszám-generátort. Ha a szám negatív, a generátor valóban véletlen értékkel indul, míg 0 vagy pozitív szám esetében a kezdőérték maga lesz a megadott szám.
Konfigurációs fájl A konfigurációs fájl (calculator.cfg) hat bemeneti paraméterrel rendelkezik, mindegyik paraméter egy név–érték párból áll. A paraméter neve ’[’ és ’]’ között található. Hibás paraméter esetén a szimuláció hibaüzenettel leáll. A paraméterek értékei mind ezredmásodpercben értendők:
•
DelayMean: Hálózati késleltetés várható értéke. Értéke a mérésekből szárazik.
•
DelaySqrStdDev: Hálózati késleltetés szórásnégyzete. Értéke a mérésekből szárazik.
•
HOLatencyMean: Cellaváltás időtartamának várható értéke. Értéke a mérésekből szárazik.
•
HOLatencySqrStdDev: Cellaváltás időtartamának szórásnégyzete. Értéke a mérésekből szárazik.
•
HOMean: Két cellaváltás között eltelt idő várható értéke. Értékét a kalkulátor modulon keresztül közvetve a mozgásmodellező modultól kapja.
•
HOSqrStdDev: Két cellaváltás között eltelt idő szórásnégyzete. Értékét a kalkulátor modulon keresztül közvetve a mozgásmodellező modultól kapja.
A szimuláció folyamata A futtatási paraméterek előállításában kulcsszerepet játszanak azok a függvények, amelyek valamilyen eloszlás szerint generálnak számokat. A generátor függvények közül az egyenletes, illetve az exponenciális eloszlások a fontosak a számunkra. A handoverek hosszára és a késleltetés nagyságára vonatkozó adatok generálásához egyenletes eloszlás használatos, míg két handover közötti időre vonatkozó adatok exponenciális eloszlásúak lesznek. A kimeneti adatokat a modul sorrendezve írja ki a végrehajtó modul konfigurációs fájljába, melynek részleteit a végrehajtó modulnál tárgyaljuk. A kimeneti fájl természetesen kézzel is módosítható, így bárhol beavatkozhatunk, ha szükséges. Egyenletes eloszlású szám generátor Mivel a rand() függvénynek nem lehetséges megadni a pontos alsó és felső határokat,
ezért az általa generált egyenletes eloszlású számsorozat nem elégíti ki maradéktalanul igényeinket, új függvényt kellett definiálnunk, melynek alapja az egyenletes eloszlásból származó képlet: x = y ⋅ (b − a) + a , ahol y egy véletlenszám [0;1)-ban.
23
Exponenciális eloszlású szám generátor Az exponenciális eloszlású számokhoz is a rand() függvényt használtuk. Képlete a kö-
vetkező: x = −1 / λ ⋅ ln(1 − y ) , ahol y egy véletlenszám [0;1)-ban. A generátor a már említett módon inicializálható. Negatív számok esetén a kimenet véletlenszerűen változik, azonos pozitív bemenetekre viszont ugyanaz lesz minden alkalommal. A determinisztikusság megőrzése érdekében a negatív számok módszeres használata nem ajánlott.
Végrehajtó modul A végrehajtó modul egyetlen feladata a szimulációs láncban a beérkező csomagok módosítása a megadott feltételek mellett. A modul két bemeneti paraméterrel rendelkezik, az első a módosítani kívánt bemeneti fájl, a másik pedig egy eseménysorozatot leíró konfigurációs fájl, amelyben kötött szintaktika szerint adottak az események. A bemeneti fájl a már ismertetett pho kiterjesztésű ideiglenes csatorna fájl.
Konfigurációs fájl A végrehajtó modul konfigurációs fájlja (executor.cfg) két szekciót tartalmaz, az első a forgalom tulajdonságait, a második a handoverek tulajdonságait írja le. A szekció [Szekciónév] illetve [/Szekciónév] között helyezkedik el. Szekción kívüli bármilyen adat hibához vezet, a szimuláció leáll. Minden szekcióban csoportok találhatók, amelyek a szekciótól függően más és más adatokat tartalmaznak. Íme egy csoport a [Transmission] szekcióból: [Start] 1001 [End] 1799 [Delay] 245
Szükségünk volt a „Transmission” fogalom kismértékű átértelmezésére. A modul számára egy „Transmission” két handover között zajlik (illetve indulástól a végéig, vagy egy handoverig). Vagyis a teljes adatforgalom „Transmission”-ök sorozatát jelenti, handoverekkel megszakítva. Továbbá minden számadat ezredmásodpercben értendő. A [Start] jelöli azt az időpillanatot, amikor az adatáramlás elkezdődik, a [Stop] pedig annak befejeződési időpillanatát. A [Delay] paraméter mutatja azt az átlagos késleltetést, amelyet a forgalom ebben az időszakban elszenved. A második szekcióban is csoportok találhatók, amelyek azonban az egyes handoverek jellemzőit írják le. Egy csoport ebből a szekcióból: [Start] 1800 [End] 2250
24
A két paraméter ugyanúgy ezredmásodpercben értendő és pontosan ugyanazt jelentik, mint az első szekció csoportjaiban található azonos nevű paraméterek, azzal a különbséggel, hogy ezek a handover elejére, illetve végére vonatkoznak.
Végrehajtó mechanizmus A modul egy véges automatát (FSM: Finite State Machine) implementál (11. ábra).
11. ábra: Végrehajtó modul véges automatája
A csomagtovábbítást a véges automata végzi. Egészen az adatfolyam (transmission) kezdetéig az automata „idle” állapotban van, miközben méri az eltelt időt. Amint az adatfolyam elindul, az automata állapotot vált, átkerülünk „transmission” állapotba. Az adatok érkezésével együtt telik az idő is. Amikor handover történik, ismét állapotváltás következik, az új állapot a „handover” lesz. Miközben az idő tovább telik, az érkező csomagok elvesznek, egészen a handover végéig (ez a gyakorlatban azt jelenti, hogy a mobil egység sikeresen hozzácsatlakozott az új hálózathoz, megkapta az új címét, és értesítette a honi ügynököt (Home Agent) a hálózat- és ezzel együtt a hálózati cím váltásról). Ha véget ért a handover, az automata ismét állapotot vált és előbb a „handover end”, majd attól függően, hogy folytatódik-e az adatfolyam, „transmission” vagy „idle” állapotba kerül. Az ábrán az is látszik, hogy ha az adatfolyam nem handover után/közben ér véget, akkor is visszatér a kiinduló állapotba. A LOSSFLAG 11-es értéke jelenti, ha egy csomag a cellaváltás közben elveszett. Ezt a dekóder modul valóban elveszettnek kezeli, ami a videó ismételt összerakásánál mint hiány 25
jelentkezik. Az ábrán (12. ábra) egy, a mobilitás szimulátor által generált kimeneti pho fájl egy részlete látszik, melyben négy csomag fejrészének eleje látható. Az ábráról jól látszik, hogy a cellaváltás a negyedik másodperc elején (4031. ezredmásodperc) történt.
12. ábra: Mobilitásból adódó csomagvesztés
26
VI. MÉRÉSEK VALÓS FIZIKAI TESZTKÖRNYEZETBEN Célunk az volt, hogy valós méréseken alapuló adatokkal is futtathassuk a IP mobilitás szimulátorunkat. Ehhez megterveztünk, kiépítettünk és felkonfiguráltunk egy olyan tesztkörnyezetet, amellyel adatokat gyűjthetünk a szimulátor modul részére (pl. handover időtartama különböző típusú adatfolyamok, valamint különböző mozgási szituációk esetén; csomagvesztések, stb.). A rendszert tudatosan a MIPL (Mobile IPv6 for Linux) projekt [13] alapján építettük, melyet a Helsinki Műszaki Egyetemen (Helsinki University of Technology) fejlesztettek. A tesztkörnyezet legfontosabb elemeit mutatja be a 13. ábra.
13. ábra: IPv6 mérési hálózat
A 13. ábra látható, hogy a rendszer a router köré épül fel. Tesztkörnyezetünkben a router szerepét egy négy Ethernet interfésszel rendelkező PC tölti be, melynek eth2 és eth3 interfészeire közvetlenül csatlakozik egy-egy Wireless Access Point (Vezetéknélküli Hozzáférési Pont , továbbiakban AP), valamint az eth1 interfészen közvetve egy harmadik AP egy hub-on keresztül. (A hub tulajdonságaiból következik, hogy a Home Agent (Otthoni Ügynök, továbbiakban HA) segítségével azokat a hálózati csomagokat is tudtuk figyelni, melyeknek a célja nem a HA volt. A hub-ba csatlakozik még két PC, amelyek a HA és a Correspondent Node (Kommunikációs Partner, továbbiakban CN) feladatát látják el. A router negyedik csatolója 27
lehetőséget biztosít a világháló elérésére, de ezt a méréseink során szándékosan nem használtuk, mivel biztosítani akartuk a teszthálózatunk teljes mértékű elkülönítését a külvilágtól. A mobil egység szerepét (Mobile Node, továbbiakban MN) egy notebook tölti be, amellyel barangolni tudtunk a kiépített három tesztcellában és különböző szoftverek segítségével megvizsgálni a handoverek hatásait az adatfolyamra. Említést kell tennünk még egy notebook-ról, a Vizsgáló Egységről (Control Node, CoN), amelynek segítségével adatokat gyűjtöttünk a mobil egységről. Ez a gép nem járul hozzá a Mobile IPv6 tesztrendszerhez, pusztán kisegítő szerepe van. Az okokról később még szót ejtünk.
Hardver elemek WLAN eszközök A Mobil IPv6 tesztkörnyezet felépítéséhez a következő 802.11a/b/g szabványokat implementáló WLAN eszközök álltak rendelkezésünkre: 1. táblázat: a tesztrendszer WLAN eszközei Mennyiség
802.11 WLAN eszköz megnevezése
3 db
Linksys WAP55AG Access Point
1 db
3COM 3CRPAG175 PCMCIA Card
Az eszközök lehetővé teszik, hogy a kialakított hálózatokban gond nélkül barangolhassunk és ezáltal a szükséges méréseket elvégezhessük. Mivel az IEEE 802.11a/b/g szabványainak maradéktalanul eleget tesznek, így más hasonlóan szabványos eszközökkel is kifogástalanul működnek. Mi azonban kizárólag a 802.11a frenkvenciáin alkalmaztuk az eszközöket, az 5,5 GHz-es ISM sávban. Választásunk azért esett a 802.11a szabványra (a b, illetve g szabványok helyett), mert sok olyan eszköz használatos (nem csak a hálózatunk környezetében, hanem számos más helyen is, pl. mikrohullámú sütő, már kiépített WLAN hálózat, Bluetooth stb.), amelyek interferenciát okozhatnak a 2,4 GHz-es ISM sávban. Az ’a’ szabvány által használt 5,5 GHz-es sáv azonban csaknem üres, a teszthálózat környezetében nem találtunk más működő eszközt, amely zavarhatta volna méréseinket. Linksys WAP55AG Access Point Ez az eszköz támogatja a 802.11 a/b/g szabványokat, így a 802.11b szabványú
vezetéknélküli hálózatokban max. 11 Mbps, az 802.11a és 802.11g szabványú hálózatokban pedig max. 54 Mbps adatátviteli sebességet érhet el a fizikai rétegben. Mindhárom AP-nak más-más ESSID-t (Extended Service Set IDentifier, Kibőveített Szolgálati Azonosító) állítottunk be. Ezek rendre: linksys-a-1, linksys-a-2 és linksys-a-3. A linksys-a-1 jelű csatlakozik a 28
hub-on keresztül a routerhez; ez a MN otthoni hálózatához tartozó AP. A MN szabadon mozoghat a három különböző hálózatban, és ha a jelszint drasztikusan lecsökken, hálózatot vált, ilyenkor mindig a legerősebb jelszintű AP-hoz csatlakozik. Méréseink során bizonyos tesztesetekben manuálisan váltottunk a hálózatok között. Az AP-k ezenkívül rendelkeznek még opcionális 152 bites WEP titkosítással, valamint konfigurálhatóak SNMP-vel (Simple Network Management Protocol, Egyszerű Hálózatmenedzsment Protokoll) és egy barátságos webes felhasználói felületen keresztül is menedzselhetők. Képesek MAC-címek szűrésére is, tehát a hálózati hozzáférés is korlátozható. DFS (Dynamic Frequency Scaling, Dinamikus Frekvencia Kalibráció) segítségével az AP mindig képes a lehető „legtisztább” frekvenciatartomány használatára. Ez utóbbi funkciót nem használtuk, az egyes AP-k működési frekvenciáját magunk állítottuk be fix értékekre (linksys-a-1: 5.18GHz, linksys-a-2: 5.20GHz, linksys-a-3: 5.22GHz) [15]. A fontosabb technikai paraméterek: 2. táblázat: Linksys WAP55AG tulajdonságai Megnevezés Vezetékes hálózati interfész
Tulajdonság Ethernet/IEEE 802.3 10/100 Mbps RJ-45 csatlakozó
Vezeték nélküli hálózati interfész
IEEE 802.11 CSMA/CA
Frekvencia sáv
2,4 GHz és 5 GHz ISM
Külső elektromos tápellátás
100 V–250 V, 50–60 Hz, 2,5 A
Bemeneti feszültség
5 V DC
Tömeg
0,4 kg
29
3COM 3CRPAG175 PCMCIA Card Támogatja a 802.11a/b/g szabványokat, így szintén képes 11 és 54 Mbps adatátvitelt biztosí-
tani a munkaállomás és egy AP, vagy pedig egy másik WLAN eszközzel bíró munkaállomás
14. ábra: 3COM 3CRPAG175 és Linksys WAP55AG
között (ad hoc üzemmódban). Az eszköznek megadható, hogy mely SSID-val rendelkező hálózatra csatlakozzon, támogat sokféle titkosítást (WPA – WiFi Protected Access, Védett WiFi Hozzáférés, WEP – Wired Equivalent Privacy (Vezetékessel Megegyező Védelem), AES – Advanced Encryption Standard (Fejlett Titkosítási Szabvány) stb.), fejlett energiagazdálkodása révén nem terheli a munkaállomás telepét és használaton kívül a teljes kikapcsolása is lehetséges. Hogy működésre bírjuk a
PCMCIA WLAN kártyát, szükségünk volt a
MADWiFi (Multiband Atheros Driver for WiFi) nevű eszközmeghajtóra is [14]. A fontosabb technikai paraméterek: 3. táblázat: 3COM 3CRPAG175 tulajdonságai Megnevezés
Tulajdonság
Vezetékes hálózati interfész
PCMCIA Type II 32-bit PC card slot (3,3 V)
Vezeték nélküli hálózati interfész
IEEE 802.11 CSMA/CA
Frekvencia sáv
2,4–2,4835GHz (802.11b/g) 5,150–5,825GHz (802.11a) ISM
Moduláció
DSSS (Direct Sequence Spread Spectrum)
Külső elektromos tápellátás
A PCMCIA csatlakozófelületen
Bemeneti feszültség
3,0–3,6V DC
Tömeg
32 g
30
Hálózati eszközök Hub Méréseink során egy 8+1 portos hub-ot használtunk a otthoni hálózat elemeinek össze-
kapcsolására (HA, CN, router, AP1). Ez az eszköz nem érdemel sok magyarázatot, működése annyiból áll, hogy bármely portjára érkező Ethernet kereteket minden más portjára is továbbít, valamint fizikai jelszint korrekciót (erősítést) végez. Router Feladata három alhálózat között a csomagok továbbítása. A router egy Intel Pentium
MMX 233 MHz processzorral rendelkező PC négy darab 10/100 Mbps Ethernet csatolóval.
Végberendezések Home Agent (Otthoni Ügynök) A HA a Mobil IP hálózat legfontosabb eleme. Minden honi hálózat rendelkezik egy ott-
honi ügynökkel, ahová a mobil egységek beregisztrálják magukat, hogy épp milyen címen érhetők el. Ha a mobil egység egy idegen hálózatba kerül, tájékoztatja az otthoni ügynökét címének megváltozásáról, amely így nyomon tudja követni a mobil terminálokat, hogy épp merre járnak és átirányítja a terminál felé irányuló kapcsolatokat. A HA magja egy Intel Pentium IV 2.8 GHz-es processzor, valamint 1 GB RAM. A gép 10/100 Mbps-os Ethernet csatolóval rendelkezik. Correspondent Node (Kommunikációs Partner) A CN kommunikál a mobil egységgel. A gépet egy AMD Athlon XP 2600+ processzor
hajtja, operatív memóriája 512 MB, egy 10/100 Mbps-os Ethernet csatolóval rendelkezik. Mobile Node (Mobil Egység) Mobil egység amely a CN-tól jövő adatokat fogadja, miközben a hálózatok között mo-
zog. Típusa: HP Omnibook XE2-DC notebook, rendszermagja egy Intel Pentium III 500 MHz-es processzor, 64 MB RAM-mal. Benne található a 3COM WLAN adapter kártya. Mivel a gép korlátozott teljesítményű (viszonylag lassú processzor, kis, 800x600 felbontású képernyő), a teljesítménycsökkenést megelőzendő beszereztünk egy újabb gépet, amely átvesz néhány feladatot a MN-tól. Így került a rendszerbe a Control Node (Vizsgáló Egység). Control Node (Vizsgáló Egység) Feladata, hogy a MN webszerverén keresztül lekérje a mobil egységen futó adatgyűjtő
szkriptek által a feltöltött adatbázisokat (közvetlen vezetékes összeköttetéssel) és azon keresztül a vezetéknélküli interfész hálózati forgalmi jellemzőit leíró grafikonokat lementse. Ezt át 31
kellett helyezni a MN-ról a CoN-ra, ugyanis a MN-nak túl sok feladat jutott. A feladatok ilyen jellegű megosztásával jelentősen javult a helykihasználás a ma már kicsinek számító kijelzőn, illetve jelentős teljesítménybeli növekedést is tapasztaltunk. A CoN feladatát egy FujitsuSiemens Lifebook C1020 látta el.
Szoftver elemek Operációs rendszer Mint már korábban említettük, tudatosan a MIPL implementáció futtatásához szükséges feltételrendszert követtük. Ez magába foglalta az alkalmazható operációs rendszerek halmazát is. Saját MIPv6 rendszerünk megvalósításához a mipv6-1.1-v2.4.26 forrás (kernel patch) mellett döntöttünk, ami – bár nem a legújabb MIPL implementáció – igen kiforrott. A szoftver 2.4.26-os Linux kernelhez készült, a Linux disztribúciók közül választásunk a Debian GNU/Linux disztribúcióra esett, melyet 2.4.26-os kernellel működtetünk. A döntésnek számos oka volt: a Debian/GNU Linuxhoz számos csomag telepíthető, könnyen kezelhető és sokat számított az is, hogy a MIPL projekten dolgozó fejlesztők is ezen a rendszeren fejlesztették a mipv6 szoftvert. Kernel A MN, CN és HA a mipv6-tal bővített 2.4.26-os kernelt futtatja Debian/GNU Linux 3.1
rev0a „Sarge” operációs rendszerrel. A router operációs rendszere a bővítést nem tartalmazó azonos típusú operációs rendszer. Router Advertisement Daemon (radvd) Ahhoz, hogy a router betölthesse a feladatát, router hirdetéseket (Router
Advertisements) kell küldenie a hozzá csatlakozó hálózatokra. Ezt háttérben futó segédprogram segítségével teszi meg, amelynek a neve Router Advertisement Daemon (radvd). A szoftver kulcsszerepet játszik az IPv6 automatikus címkiosztási algoritmusában. A hálózatra kapcsolódó egységek a hirdetés feldolgozásával jutnak a számukra fontos hálózati prefix és a hálózati maszk információhoz. Az automatikus címkonfigurációs algoritmus ezek segítségével beállítja az interfész címét, valamint felépíti a route táblát. NTP Mivel a különböző gépek órája nem járt szinkronban, mindenképp szükségünk volt a
mérések előtt szinkronizálásukra. A megoldást a közismert NTP (Network Time Protocol, Hálózati Időszinkronizációs Protokoll) jelenti. Feltelepítettük az ntpd-t (Network Time Protocol Deamon) a HA-re és az összes többi komponens gépre az ntpdate kliens programot. Szinkronizálás után a gépek órái pontosan a HA gép órájának megfelelően jártak. 32
Forgalomgenerátor D-ITG Támogatja az IPv4-et és IPv6-ot is és változatos karakterisztikájú adatfolyamokat képes
előállítani. Képes konstans vagy változó méretű csomagok küldésére, változó típusú médiaátvitelt szimulálni (pl. VoIP), valamint az általunk használt verzió nyolc fajta eloszlással csomagokat előállítani. Mindezen funkciók gazdagon paraméterezhetőek. Újabb előnye, hogy letölthető hozzá egy Java alapú grafikus felhasználói interfész (Graphical User Interface, GUI) is, amely a paraméterek beállítását hivatott megkönnyíteni. A program egy kliensszerver alapú, elosztottan működő szoftver, szükség van legalább egy küldő és egy vevő oldalra (a két komponens természetesen lehet azonos gépen). Legtöbb mérésünk során a forgalom iránya MN → CN volt. A CN oldalon futott a fogadó komponens (ITGRecv) az alapértelmezett 8999-es UDP porton, amely naplózta a beérkezett forgalom jellemzőit is (csomagvesztés, késleltetés, jitter stb.). A küldő oldalon a gazdagon paraméterezhető küldő (ITGSend) futott.
Naplózás RRDTool A MN-ra feltelepítettünk egy RRDTool nevű programot is, amely képes arra, hogy a
gépen lévő összes hálózati interfész adatforgalmáról adatbázist készítsen, abból grafikonokat generáljon és azokat png formátumban elmentse. A grafikonok több időskálán is lekérdezhetőek (perc, óra, nap, hónap, év felbontásokban) és a mért adatok átlag, maximális, minimális és utolsó értékeiből rajzolódnak ki (pl .felparaméterezhető úgy, hogy egy hetes időskálájú grafikont 2 órás átlagértékekből rajzoljon ki). A program működéséhez szükséges egy Apache webszerver és a hozzá tartozó Perl, illetve CGI modulok [16]. A program konfigurálásához két Perl szkript és két CGI szkript módosítása szükséges. A Perl szkriptek minden egyes futásukkor újabb értékeket írnak be az program RRD adatbázisába (Round Robin Database), amiből például az átlagokat lehet kiszámolni. Ezért, hogy aránylag folyamatosan tudjuk vizsgálni a MN ath0 interfészét (WLAN interfész), írtunk egy egyszerű kis shell szkriptet, ami minden másodpercben lefuttatja a Perl szkriptet. A szkriptek futása során kerül feltöltésre az adatbázis, aminek a tartalma a MN webszerverén a CGI-ket megnyitva, vizualizált formában, grafikonok segítségével kapható meg egy weblapon. A CoN gépnek nem kellett semmilyen különleges szoftver komponens, csak egy web böngészőre volt szüksége. Az operációs rendszerre is csak egy megkötés volt, képes legyen IPv6-on kommunikálni.
33
Ethereal A hálózati forgalom elemzésére használt eszközünk az Ethereal hálózat-analizátor
szoftver volt. A HA-n és a MN-on is futtattunk egy-egy példányt és naplóztuk az egyes átvitelek eseményeit (eltároltuk a csomagokat és a generált naplófájlokat későbbi elemzések céljából). Végezetül el kell mondani, hogy a rendszerben résztvevő minden aktív egység úgy lett beállítva, hogy képes legyen a kommunikáció jellemzőit megőrző különféle naplófájlok készítésére és folyamatos frissítésére, vezetésére a későbbi elemzés érdekében.
Tesztesetek (Szkenáriók) A teszteket/méréseket több esetre lebontva végeztük, úgynevezett szkenáriókat definiáltunk. Egy szkenárió több elemből épül fel: forgalom karakterisztikája, mozgás típusa, forgalom iránya, van-e automatikus AP felderítés. A mérések előtt minden, a kommunikációban résztvevő végberendezés szinkronizált a HA órájához.
Passzív mérések Kétféle mérés típust végeztünk. Az úgynevezett passzív mérések esetében forgalom nélkül vizsgáltuk a hálózatváltásokat, ehhez természetesen nem volt szükség se RRDTool-ra, se D-ITG forgalomgenerátorra, se Correspondent Node-ra. A mérések egyedüli célja az volt, hogy egy alsó becslést adjunk a handover által okozott késleltetésre. Először meghatároztuk azokat a tagokat, amelyek befolyásolhatják, megnövelhetik a cellaváltás idejét: AP keresése, autentikáció, kapcsolódás az AP-hoz, IPv6 késleltetés, Care-of Address regisztrálása a honi ügynöknél, illetve a kommunikációs partnernél (utóbbi csak kommunikáció esetén igaz) [17]. Az autentikáció kivételével (amit nem alkalmaztunk) minden egyes tag növelte a cellaváltáshoz szükséges időt. Ethereal segítségével a Mobile IPv6 csomagok elfogási idejéből megbecsülhető a Mobile IPv6 késleltetése cellaváltás esetén (15. ábra). Egy mérés során többször váltottunk hálózatot. Az eredmények nagyon változóak, egyes esetekben a váltás pár ezredmásodpercig tartott, máskor pedig több másodpercet is igénybe vehetett. A leggyakoribb érték 1 másodpercnél valamivel nagyobb. Ehhez az értékhez kell még hozzáadni a többi réteg késleltetését, ezt azonban ezekkel az eszközökkel nem tudtuk kimérni. A képen látható első oszlop jelenti a csomag sorszámát, második oszlop jelzi a csomag indulási/érkezési idejét.
34
15. ábra: Ethereal kimenete passzív méréskor
Az első kijelölt részben az látható, hogy a váltás villámgyorsan megtörtént, míg a második kiemelt csomagpár között átlagosnak nevezhető 1 másodperc telt el.
Aktív mérések Aktívnak nevezzük azokat a méréseket, amikor a hálózatban a MN és CN gépek kommunikációt folytatnak egymással. Forgalomtípusok Mivel a mérések eredményei alapvetően a multimédia-átvitellel kapcsolatos szimuláci-
ókhoz szükségesek, ezért csak UDP forgalmat vizsgáltunk, ami alkalmas real-time adatok továbbítására (pl. videotelefonálás). Az UDP megbízhatatlan, nem sorrendhelyes átvitelt nyújt a hálózati réteg felett, ezért csomagvesztések még nagyon alacsony hibavalószínűségű hálózatban is előfordulhatnak. Három forgalomtípust különböztettünk meg: 1. VoIP: RTP (Real-time Transfer Protocol), G.711 kodek, egy csomagba két minta kerül 2. UDP forgalom 512 bájtos csomagmérettel, konstans 500 csomag/másodperc küldési sebesség 3. UDP forgalom 512 bájtos csomagmérettel, konstans 400 csomag/másodperc küldési sebesség A 2. típusú forgalom a rendszernek azon maximuma, amelynél normális esetben nem vész el csomag a vezetéknélküli interfészen. Az 1. és 3. típusú forgalomban használt adatsebesség ennél a maximumnál ( 500 ⋅ 512 ⋅ 8 ≈ 2 Mb / s ) alacsonyabb. Forgalom iránya A forgalom a legutolsó szkenárió kivételével mind a MN-tól a CN felé haladt. Az utolsó
szkenárióban a CN töltötte be a küldő szerepét. Mozgás típusok A szkenáriókban négy mozgástípust definiáltunk:
a) Honi és idegen hálózat között mozog. 35
b) A két idegen hálózat között mozog. c) A 3. idegen hálózatból indulva előbb a hazamegy, majd a 2. idegen hálózatba, azután ismét a 3.-ba. d) 3. idegen hálózatból honi hálózatba. Automatikus AP felderítés Ha a MN cellát (és ezzel együtt hálózatot vált), két lehetőség van. Az egyik, ha a MN
tudja, hol keresse az új AP-t. Ebben az esetben nem szükséges felderíteni az AP-t, hanem egyszerűen kapcsolódik hozzá egy adott frekvencián. Második esetben az új AP-t meg kell keresni, ehhez pedig az szükséges, hogy a MN szkennelést végezzen az új cellában. Csak miután megtalálta, akkor kapcsolódhat újra a hálózathoz. Ez értelemszerűen több időt vesz igénybe, ráadásul megbízhatatlan, hiszen még akkor se mindig találja meg az új AP-t, ha a megfelelő frekvenciasávban keres. Mérések Mivel a forgalomgenerátor kliens-szerver alapon működik, a MN-on és a a CN-on is fu-
tattuk egy példányát. A három forgalomtípus generálásához a következő parancsok szükségesek (egyszerre csak az egyik): ITGSend –a 3ffe:ffff:501:100::111 –t 60000 VoIP -x G.711.2 (lásd a) forgalom) ITGSend –a 3ffe:ffff:501:100::111 –t 60000 –C 500 –c 512 (lásd b) forgalom) ITGSend –a 3ffe:ffff:501:100::111 –t 60000 –C 400 –c 512 (lásd c) forgalom)
A -a paraméter segítségével adható meg a célállomás címe, a -t kapcsolót követő szám megadja a futtatás idejét ezredmásodpercben, -C jelenti a küldendő csomagok számát másodpercenként, -c paraméter határozza meg a hasznos teher méretét bájtban. A -x kapcsoló csak VoIP módban működik, segítségével a kodek típusa adható meg. A szoftver vevő oldalán mindöszze egy paraméter pár szükséges, a naplófájl neve: ITGRecv –l
Ahhoz, hogy az RRDTool adatokat gyűjthessen a MN ath0 interfészéről, futtatnunk kellett két Perl-szkriptet. Ezek egyszerre csak egy sort írtak adatbázisukba, így írtunk egy-egy shell-scriptet, amelyek egy másodpercenként lefuttatják a Perl-scripteket. Ezek hívása: ./wlan_1s.sh ./traffic_1s.sh
Az Etherealt grafikus felületen futtattuk, így annak parancssori indítóparaméterei nincsenek. Mért adatok A1 szkenárió): Honi és idegen hálózat között mozog, forgalom VoIP: RTP (Real-time
Transfer Protocol), G.711 kodek, egy csomagba két minta kerül. A cellaváltás során 134
36
csomag veszett el, a maximális késleltetés értéke 1,013 másodperc. (A grafikonok 1 perces felbontásúak, a két jelzővonal között eltelt idő 30 másodperc.)
Jól látható, hogy a cellaváltás folyamán rövid időre leesett a maximális átviteli sávszélesség. Az adatfolyam ábrán látható is az új hálózatba való áttéréshez szükséges plusz adat (zöld szín). A váltás aránylag gyorsan, 2-3 másodperc alatt végbement. A2 szkenárió) Honi és idegen hálózat között mozog, UDP forgalom 512 bájtos cso-
magmérettel, konstans 500 csomag/másodperc adási sebességgel. A cellaváltás során 2408 csomag veszett el, a maximális késleltetés 1,184 másodperc.
37
Nagyobb adatforgalom esetén jól érzékelhető a grafikonokon a hálózati átvitel kiesése. Időtartama 5-6 másodperc. A3 szkenárió) Honi és idegen hálózat között mozog, VoIP: RTP (Real-time Transfer
Protocol), G.711 kodek, egy csomagba két minta kerül. Automatikusan keresi az új Access Pointot. A cellaváltás során 770 csomag veszett el, a maximális késleltetés 0,891 másodperc.
38
39
Hosszabb váltás esetén a MN-nak meg kell keresni az új AP frekvenciáját, ezért a váltás sokkal hosszabb, mint eddig, nagyjából 10 másodperc körüli érték. Jól látszik az is, hogy az adatfolyam megszakadt. A4 szkenárió) Honi és idegen hálózat között mozog, UDP forgalom 512 bájtos cso-
magmérettel, konstans 500 csomag/másodperc adási sebesség. Automatikusan keresi az új Access Pointot. 6285 csomag veszett el, a maximális késleltetés 1,194 másodperc.
40
Remekül látszik, hogy a nagyobb forgalom mellett sokkal tovább tart az átállás egy idegen AP-ra. Az új AP felderítése a frakvenciatartományban majdnem 15 másodpercig tartott! Itt is jól látszik a generált adatforgalom leállása. B3 Szkenárió) A két idegen hálózat között mozog, UDP forgalom 512 bájtos csomag-
mérettel, konstans 400 csomag/másodperc adási sebességgel. Az idegen AP-k közötti váltás itt sem látható igazán, így az átállás idejére nehéz becslést adni. A cellaváltás során mindössze a csomago k 3,74%-a veszett el, ez 897 csomagot jelent, a maximális késleltetés értéke: 1,206 másodperc. C1 Szkenárió) A 3. idegen hálózatból indulva előbb a hazamegy, majd a 2. idegen há-
lózatba, azután ismét a 3.-ba. VoIP RTP (Real-time Transfer Protocol), G.711 kodek, egy csomagba két minta kerül. A három cellaváltás során összesen 488 csomag veszett el, a maximális késleltetés 1,272 másodperc.
41
Ezen az ábrasorozaton jól megfigyelhetőek az egymás utáni AP váltások hatásai. Most jól látszik a két idegen hálózat közötti váltás is. C3 Szkenárió) A 3. idegen hálózatból indulva előbb hazamegy, majd a 2. idegen háló-
zatba, azután ismét a 3.-ba. UDP forgalom 512 bájtos csomagmérettel, konstans 400 csomag/másodperc adási sebesség. A három cellaváltás során 3157 csomag veszett el, a maximális késleltetés értéke 1,591 másodperc.
42
A nagyobb forgalom mellett is szépen kivehetőek az AP váltások hatásai. A forgalmi grafikonon látszanak a cellaváltások kommunikációi (zöld színnel). D1 Szkenárió) 3. idegen hálózatból honi hálózatba, VoIP: RTP (Real-time Transfer
Protocol), G.711 kodek, egy csomagba két minta kerül. A mozgás során 109 csomag veszett el.
A hazatérés aránylag zökkenőmentesen zajlott le, lényegében csak a forgalmi grafikonon látszik az adatsebesség visszaesése.
43
A 16. ábra látható az Ethereal egyik teszt futtatása alkalmával generált kimenete, amelyből jól látszik, mi történik, ha adatforgalom közben cellaváltás történik. A passzív mérésekhez képest négy új üzenet típussal találkozunk: Care-of Test Init, Care-of Test, Home Test Init, Home Test. Ezek az üzenetek arra valók, hogy a kommunikációs felek közül a CN megbizonyosodjon arról, hogy a MN továbbra is elérhető mind az otthoni címén, mind a Care-of Address-en keresztül. Forgalom híján a passzív mérésekből ezek az üzenetváltások hiányoznak.
16. ábra: Ethereal kimenete aktív méréskor
44
VII. SZIMULÁCIÓS VIZSGÁLATOK A BASIC CHAIN KERETRENDSZERBEN Miután a mérések eredményeit feldolgoztuk és beépítettük a IP mobilitás szimulátorunkba, hátra volt még a Basic Chain futtatása. Négy módon futtattuk a szimulációt, mindegyiket 8 másodpercnyi videóval. Az első és második alkalommal a láncban kikapcsoltuk az optimalizációt, a harmadik és negyedik futtatás alkalmával viszont engedélyeztük. Mindkét csoportban az első alkalommal működésbe hoztuk a mobilitás szimulátort, a második alkalommal viszont kikapcsoltuk. Miután mindegyik videó elkészült, összehasonlítottuk a párokat és kielemeztük a mobilitás kezeléséből származó hatásokat.
Médiaátvitel A hagyományos médiaátvitel során (optimalizáció nélkül) a központi vezérlőegység figyelmen kívül hagyja az egyes jelzéseket, a rendszer nem adaptálódik a környezetéhez. Ha az átvitel optimalizált, a videó minőségében jelentős változások tapasztalhatók, a hibák száma lecsökken. A videóból kiragadtunk néhány képkockát, amelyek jól szemléltetik az optimalizáció kedvező hatását, illetve bemutatunk olyan képkockákat is, amelyeken megvizsgálható a mobilitás kezelésének hatása is.
Optimalizált és hagyományos médiaátvitel
17. ábra: Optimalizált és hagyományos médiaátvitel közti különbségek
A bal oldali képen (17. ábra) látható az optimalizált média, jobb oldalon pedig a hagyományos. Jól látható, hogy a jobb oldali képen jóval több a hiba és a zaj, azokon a helyeken a rádiós átviteli csatorna jóval alacsonyabb minőségű átvitelt tudott biztosítani. Ezzel szem-
45
ben az optimalizált átvitelnél sikerült kiküszöbölni a lokális hibák hatásait, a kép jóval tisztább.
18. ábra: Az optimalizált médiaátvitel nagyobb zajtűrő képessége
Az optimalizált média most is a bal oldalon látható (18. ábra), a zajtól azonban nem sikerült maradéktalanul megszabadítani a képkockát. Az azonban jól megfigyelhető, hogy a kép tisztábban kivehető, mint a jobb oldali képen.
Cellaváltás hatásai A következő két kép szemlélteti, milyen változásokat okoz a cellaváltás a médiafolyamban.
19. ábra: Cellaváltás hatásai az optimalizált médiafolyamra
Mindkét képkocka az optimalizál médiafolyamból származik (19. ábra), a bal oldalon azonban láthatók a cellaváltás hatásai. Cellaváltás alatt – mivel a mobil egység nem képes se küldeni, se fogadni – csak üres képkockák láthatók. A bal oldali kép a cellaváltás befejezése utáni időpillanatot szemlélteti. Jobb oldalon ugyanaz a képkocka látható, az előzőhöz képest a
46
különbség csak annyi, hogy a jobb oldali médiafolyam átvitelénél a szimulációs láncban az IPv6 mobilitás szimulátor ki volt kapcsolva. A bal oldali képen látható jelenség magyarázata a következő: az átvitel során az MPEG4 kódoló I, P és B képeket generál a videóból, azokat egymás után fűzi. A P és B típusú keretek azonban nem teljes képet, hanem csak a különbséget tartalmaznak, csak az látszik bennük, hogy mekkora az eltérés egy másik kerethez képest. A bal oldalon látható képen egy ilyen különbség keret látható (a hozzá tartozó I keret elveszett a cellaváltás során). A különböző mozgásmodellek hatásait a szóbeli prezentáció alkalmával mutatjuk be részletesen.
Eredmények feldolgozása A mérések során több fontos következtetésre jutottunk. A Mobile IPv6 nem alkalmas a mikromobilitás hatékony kezelésére, mert túl nagy késleltetést okoznak a cellaváltások, amelyek gyakran több másodpercet is igénybe vehetnek. A protokoll kizárólag makromobilitás kezelésére használható. A médiaátvitel hatékonyságát nagyban megnöveli az optimalizáció, a minőség javulása szemmel is látható. Ennek az ára azonban az volt, hogy a JSCC/D architektúra szakítson az etalon OSI modellel és annak szemléletével. Ugyanakkor bebizonyította, hogy a rétegek együttműködése kedvező hatással van a hálózati adatforgalomra. A legfontosabb tanulság azonban az, hogy az optimailzált átvitel a cellaváltások hatásait nem képes kiküszöbölni, de még enyhíteni sem, hiszen az adatok a cellaváltás alatt ugyanúgy elvesznek, akár optimalizált a folyam, akár nem. Éppen ezért a jövőben legfontosabb célunk olyan cellaváltási módszerek szimulációja (smooth handover), amelyek elfedik a felasználó elől a cellaváltás okozta szolgáltatáskiesést és folyamatos kommunikációt biztosítanak.
47
VIII. ÖSSZEFOGLALÁS A jövő kommunikációs hálózatainak legfontosabb elemei: átjárhatóság a különböző hálózatok között, mobilitás, szélessávú multimédia szolgáltatások. A mérnökök számára új kihívásokat jelentő problémákra nyújt megoldást az IETF IPv6 szabványa, melynek szerves részét képezi a Mobile IPv6 protokoll. Az újgenerációs vezetéknélküli hálózatok fontos paramétere a szolgáltatás minősége. A szolgáltatások
sokféleségéből
adódóan
(multimédia
kommunikáció)
a
hatékony
erőforráskezelés rendkívül fontos szemponttá vált. Ahogy a mobil hálózatok egyre intelligensebbek és sokszínűbbek lettek, ezzel arányosan növekedett a rendszer komplexitása is. A hálózatok konvergenciája az IPv6 globális alkalmazása felé mutat, a mai jövőképek az IP új generációs protokollját nevezik meg, mint a heterogén hálózatok együttműködéséhez szükséges közös interfészt. Az Európai Unió által támogatott Phoenix FP6 IST-001812 projekt célkitűzése egy olyan globális architektúra fejlesztése, amely az újgenerációs vezetéknélküli hálózatokban felmerülő összes problémára megoldást nyújt. Az architektúra alapja a JSCC/D technológia. Az architektúra médiaátviteli képességeit vizsgáló szimulációjához létrehozták a „Basic Chain” névre keresztelt keretrendszert, amely modulárisan bővíthető és segítségével a médiaátvitelt ért hatások egyszerűen megfigyelhetők. Ennek a keretrendszernek a részeként fejleszetettük ki az IPv6 mobilitás szimulátorát, melynek segítségével megfigyelhető, miként hatnak a cellaváltások a médiafolyamra. Szimulátorunk négy almodulból áll, ezek működésük sorrendjében: mozgásmodellező, kalkulátor, szimulátor és végrehajtó modulok. Az IPv6 mobilitás szimulátor modul fejlesztése mellett több mérést is végeztünk egy általunk tervezett, épített és konfigurált vezetéknélküli IPv6 hálózaton, amely segítségével fontos információkat kaptunk a különböző típusú adatátvitelek karakterisztikájáról. Az eredményeket beépítettük a mobilitás szimulátorunkba. A mobilitás szimulátor segítségével többször is (optimalizált, illetve hagyományos átvitel) lefuttattuk a szimulációs láncot, a kapott eredményeket kiértékeltük, majd következtetéseket vontunk le a cellaváltás hatásaival kapcsolatban. Dolgozatunkban felvázoltuk a jövő újgenerációs vezetéknélküli hálózatainak lehetséges jövőképeit, bemutattuk az IPv6 és a Mobile IPv6 protokollok hasznosságát és jelentősségét, bemutattuk az Európai Unió által is támogatott Phoenix projekt célját, és szimulációs módszereit. Részletesen ismertettük az általunk készített, a szimulációs láncba illeszkedő IPv6 mobi48
litás szimulátort, bemutattuk a szimulációhoz szükséges, általunk végzett méréseket egy valós, IPv6 alapú fizikai hálózaton, valamint a szimulátor segítségével elvégeztük azokat a szimulációs méréseket, amelyeből fontos következtetéseket tudtunk levonni a cellaváltás médiaátvitelre gyakorolt hatásaival kapcsolatban. Jövőbeli terveink között szerepel a már kiépített IPv6-os hálózaton további mérések végzése, melyekkel többféle IP feletti mobilitáskezelési protokollt és azok médiaátvitelre gyakorolt hatásait vizsgálhatjuk a létrehozott szimulátor segítségével. Továbbá teveink között szerepel még smooth handover alapú megoldások, valamint a smooth handover és az optimalizált médiafolyam egymásrahatásának vizsgálata és szimulációja.
49
IX. RÖVIDÍTÉSEK 3G – 3rd Generetion 4G – 4th Generation AES - Advanced Encryption Standard AP – Access Point AMPS – Advanced Mobile Phone System AMR - Adaptive-Multi-Rate AVC – Advanced Video Coding BSAM - Boundless Simulation Area Model BSS – Basic Service Set BC – Basic Chain BU – Binding Update CGI – Common Gateway Interface CN – Correspondent Node CoA – Care of Address CoN – Control Node CoT – Care-of Test CoTI – Care-of Test Init CSI – Channel State Information CRC – Cyclic Redundancy Code D-ITG – Distributed Internet Traffic Generator DAD – Duplicate Address Detection DFS – Dynamic Frequency Scaling DHAAD – Dynamic Home Agent Address Discovery DHCPv6 – Dynamic Host Configuration Protocol version 6 DLL – Data Link Layer DRI – Decoder Reliability Information DS – Distribution System ESS – Extended Service Set ESSID – Extended Service Set Identifier FA – Foreign Agent FSM – Finite State Machine GPRS – General Packet Radio System GSM – Global System for Mobile GUI – Graphical User Interface HA – Home Agent Hi-Fi – High Fidelity HO – Handover HoT – Home Test HoTI – Home Test Init ICMP – Internet Control Message Protocol ICMPv6 – Internet Control Message Protocol version 6 IEEE – Institute of Electrical Engineering and Electronics IETF – Internet Engineering Task Force IP – Internet Protokoll
IPv4 – Internet Protocol version 4 IPv6 – Internet Protocol version 6 ISM – Industrial, Scientific, Medical JC – Joint Controller JSCC/D – Joint Source Channel Coding/Decoding LAN – Local Area Network MN – Mobile Node MAC – Medium Access Control MAD Wi-Fi - Multiband Atheros Driver for WiFi MIPv4 – Mobile Internet Protocol version 4 MIPv6 – Mobile Internet Protocol version 6 MIPL – Mobile IPv6 for Linux MPEG – Motion Picture Expert Group NA – Neighbour Advertisement ND – Neighbor Discovery NS – Neighbor Solicitation NSI – Network State Information NTP – Network Time Protocol OSI – Open System Interconnection PC – Personal Computer PSTN – Public Switched Telephone Network QoS – Quality of Service RA – Router Advertisement RADVD – Router Advertisement Deamon RAM – Random Access Memory RFC – Request for Comment RRD – Round Robin Database RTP – Real-time Transfer Protocol SAI - Source A posteriori Information SMS – Short Message Service SNR – Signal to Noise Ratio SNMP – Simple Network Management Protocol SSI - Source Significance Information TCP – Transmission Control Protocol TV - Television UDP – User Datagram Protocol UMTS – Universal Mobile Terrestial Service VCoA – Virtual Care-of-Address VoIP – Voice over IP VoIPv6 – Voice over IPv6 WAP – Wireless Application Protocol WEP – Wired Equivalent Privacy WPA - WiFi Protected Access Wi-Fi – Wireless Fidelity WLAN – Wireless Local Area Network
50
IRODALOMJEGYZÉK [1]
Shingo Ohmori, Yasushi Yamao, Nobuo Nakajima: „The Future Generations of Mobile Communications Based on Broadband Access Technologies”, IEEE Commun. Mag., December 2000., pp. 134–142
[2]
I. F. Akyildiz, J. Xie, S. Mohanty: A Survey of Mobility Management in Next-Generation All-IP-Based Wireless Systems, IEEE Wireless Communications, August 2004
[3]
Joseph P. Macker, Vincent D. Park and M. Scott Corson: „Mobile and wireless internet services: Putting the pieces together”, IEEE Commun. Mag., vol. 39, no. 6, June 2001, pp. 148–155
[4]
C. Politis,, T. Oda, S. Dixit, A. Schieder, H. Y. Lach, M. I. Smirnov, S. Uskela, R. Tafazolli: Cooperative Networks for the Future Wireless World, IEEE Commun. Mag. September 2004, pp 70–79
[5]
D. Johnson, C. Perkins, J. Arkko: Mobility Support in IPv6, IETF, RFC 3775, June 2004
[6]
C. Lamy, M. Martini, M. Chiani, P. Amon, J. Peltola, M. Jurvansuu, G. Panza, L. Hanzo: White Paper for PHOENIX: Optimising multimedia transmission in IP based wireless networks, 2003
[7]
K. Tachikawa: A Perspective on the Evolution of Mobile Communications, IEEE Commun. Mag., October 2003, pp 66–73
[8]
M. Etoh, T. Yoshimura.: Wireless Video Applications in 3G and Beyond, IEEE Wireless Communications, August 2005, pp 66–72
[9]
MPEG Industry Forum – http://www.mpegif.org/
[10] J. Huusko, G. Panza, C. Lamy-Bergot, M. G. Martini, M. Mazzotti, L. Bokor, G. Fehér, M. Majanen, J. Vehkapera, P. Amon, S. Xin Ng: Impact of Network in Joint Optimized Multimedia Transmission [11] T. Camp, J. Boleng, V. Davies: A Survey of Mobility Models, 10 September, 2002 [12] Burulitisz Alexandrosz: Mozgásmodellek alkalmazása mobil hírközlő hálózatokban, diplomaterv, 2003. Budapesti Műszaki és Gazdaságtudományi Egyetem, Híradástechnika Tanszék [13] MIPL Mobile IPv6 for Linux – http://www.mobile-ipv6.org [14] MADWiFi: Multiband Atheros Driver for WiFi Project – http://madwifi.sourceforge.net [15] Linksys – http://www.linksys.com [16] The Apache HTTPD Server Project – http://httpd.apache.org/ [17] A Cabellos-Aparicio, R Serral-Gracia, L. Jakab, J. Domingo-Pascual: Measurement Based Analysis of the Handover in a WLAN MIPv6 Scenario [18] S. Deering, R. Hinden: Internet Protocol Version 6 (IPv6), IETF RFC 2460, December 1998
51
ÁBRAJEGYZÉK 1. ábra: Háromszögelés és kivédése a Mobile IPv6-ban ........................................................................................ 6 2. ábra: A JSCC/D-n alapuló hálózati architektúra blokkvázlata .......................................................................... 7 3. ábra: IPv6 mobilitás szimulátor blokkvázlata................................................................................................... 13 4. ábra: Szimulációs terület .................................................................................................................................. 15 5. ábra: Handover vektoros Random Walk modell változatai............................................................................... 16 6. ábra: A handover vektor értelmezése................................................................................................................ 16 7. ábra: Markov lánc állapotátmenetei................................................................................................................. 17 8. ábra: Egy dimenzós döntés a cellában.............................................................................................................. 18 9. ábra: A főirány változása a szimulációs terület szélén ..................................................................................... 19 10. ábra: Markov lánc .......................................................................................................................................... 20 11. ábra: Végrehajtó modul véges automatája ..................................................................................................... 25 12. ábra: Mobilitásból adódó csomagvesztés ....................................................................................................... 26 13. ábra: IPv6 mérési hálózat............................................................................................................................... 27 14. ábra: 3COM 3CRPAG175 és Linksys WAP55AG........................................................................................... 30 15. ábra: Ethereal kimenete passzív méréskor...................................................................................................... 35 16. ábra: Ethereal kimenete aktív méréskor ......................................................................................................... 44 17. ábra: Optimalizált és hagyományos médiaátvitel közti különbségek .............................................................. 45 18. ábra: Az optimalizált médiaátvitel nagyobb zajtűrő képessége ...................................................................... 46 19. ábra: Cellaváltás hatásai az optimalizált médiafolyamra .............................................................................. 46
TÁBLÁZATJEGYZÉK 1. táblázat: a tesztrendszer WLAN eszközei .......................................................................................................... 28 2. táblázat: Linksys WAP55AG tulajdonságai ...................................................................................................... 29 3. táblázat: 3COM 3CRPAG175 tulajdonságai .................................................................................................... 30
52
