FORRÁSMODELLEZÉS MULTIMÉDIÁS MOBIL

FORRÁSMODELLEZÉS MULTIMÉDIÁS MOBIL HÁLÓZATOKBAN

TDK dolgozat, 2006

Bánfi Norbert, Műszaki informatikai szak, V. évfolyam Mátyási Csaba, Műszaki informatikai szak, V. évfolyam Varga Roland, Műszaki informatikai szak, V. évfolyam

Konzulensek: Simon Vilmos Dr. Imre Sándor

Budapesti Műszaki és Gazdaságtudományi Egyetem Híradástechnikai Tanszék Mobil Távközlési és Informatikai Laboratórium (MC2L)

Forrásmodellezés multimédiás mobil hálózatokban

TARTALOM

1. 2.

BEVEZETÉS ...................................................................................................................... 1-3 FORRÁSMODELLEK .......................................................................................................... 2-4 2.1 E-MAIL FORRÁSMODELL ..............................................................................................5 2.2 HÁLÓZATI JÁTÉKOK FORRÁSMODELL...........................................................................8 2.2.1 Általános hálózati játék modell...........................................................................9 2.2.2 Egy adott hálózati játék modellezése (Half-Life) .............................................11 2.3 PEER-TO-PEER FORRÁSMODELL ................................................................................12 2.4 VBR VIDEÓK FORRÁSMODELL ...................................................................................19 2.4.1 Markov modell..................................................................................................21 2.4.2 DAR modell ......................................................................................................23 2.4.3 Lognormál modell.............................................................................................25 2.5 VOICE OVER IP FORRÁSMODELL ................................................................................26 2.5.1 Fraktális modell ................................................................................................27 2.5.2 Exponenciális modell........................................................................................29 2.5.3 Exponenciális modell, komfortzaj figyelembevételével...................................31 2.6 WEB FORRÁSMODELL ................................................................................................33 2.6.1 Web forrásmodell egységes objektumokkal .....................................................35 2.6.2 Web forrásmodell megkülönböztetett objektumokkal......................................36 3. SOMOSI (SOURCE MODELING SIMULATOR) ...................................................................37 3.1 A SZIMULÁTOR KERETRENDSZERÉNEK FELÉPÍTÉSE ....................................................38 3.2 A PROGRAM HASZNÁLATA .........................................................................................39 3.3 PARAMÉTER, ÉS MODELLKEZELÉS ..............................................................................40 3.3.1 Fájlból való beolvasás.......................................................................................40 3.3.2 Forrásmodellek megvalósítása..........................................................................40 3.4 BŐVÍTHETŐSÉG ..........................................................................................................42 4. EREDMÉNYEK ....................................................................................................................43 4.1 A szimuláció menete.................................................................................................46 4.2 Az eredmények vizsgálata, értékelés ........................................................................46 5. KITEKINTÉS .......................................................................................................................49 6. FÜGGELÉK .........................................................................................................................50 7. IRODALOM JEGYZÉK ..........................................................................................................51 8. ÁBRAJEGYZÉK ...................................................................................................................52 9. TÁBLÁZATJEGYZÉK ...........................................................................................................53

– 1-2 –


1. BEVEZETÉS A következő generációs mobil hálózatok forgalmának egyre jelentősebb részét a napjainkban is rendkívül népszerű multimédiás szolgáltatások teszik ki. A hálózati erőforrások tervezéséhez modelleznünk kell az egyes mobil felhasználók által generált forgalmat, amit még bonyolít a mobilitás kérdése is. A mobil technológia jelenlegi fejlődési és elterjedési ütemével számolva, a közeljövőben háttérbe szorítja a vezetékes adattovábbító technikákat. A megnövekedett hálózati forgalommal számolva a szolgáltatóknak át kell majd alakítaniuk a jelenlegi rendszereiket, gondosan ügyelve a forgalom modellezésére és a hálózat méretezésére. Figyelembe kell venniük majd a felhasználók forgalomgenerálási szokásait, és annak megfelelően lesz szükség a hálózati architektúrák telepítésére, kapacitásának meghatározására, vagy átkonfigurálásra. Nyílván a szolgáltatók sem szeretnék a hálózataikat állandóan bővíteni, illetve komoly változtatásokat eszközölni rajtuk, csak azért mert nem számoltak előre a különböző felhasználói igényekkel, amelyeket meghatározott minőségi paraméterek betartásával kell tudniuk kiszolgálni. Munkánk során különböző típusú hálózati forgalmat generáló szolgáltatásokhoz illesztettünk forrásmodelleket és olyan szimulátort fejlesztettünk ki, melynek segítségével valósághűen tudjuk modellezni a felhasználók forgalmát a különböző felhasználói szokások figyelembevételével. Többféle felhasználói csoport viselkedését is modelleztük, a szolgáltatások csoportokhoz történő hozzárendelésével. A szimulátor kimenetei bemeneti adatbázisként szolgálhatnak majd további mobil technológiák teszteléséhez, illetve új mobil hálózatok méretezéséhez. Univerzális tesztkörnyezetet igyekeztünk biztosítani, a további fejlesztés, és a hatékony használat érdekében. Szimulátorunk szolgáltatná a tervezendő hálózati forgalmakat, akár különböző modellek alapján is, és rámutatna a hálózat szűk keresztmetszeteire, vagy esetlegesen a többletkapacitásaira. Feldolgoztuk a szakirodalomban található forrásmodelleket a legelterjedtebb mobil hálózati szolgáltatásokra. Figyelembe vettünk egy-egy szolgáltatást, és ezzel kapcsolatban különböző mérési tapasztalatokat, modellezés javaslatokat töltöttünk le az interneten található publikációk közül. A hat szolgáltatás, melyeket vizsgáltunk, és megvalósítottunk, a már napjainkban is elterjedt e-mail, melynek nincs különösen nagy hálózati igénye. A hálózati játékok már igénylik a teljes kapcsolatot futásuk alatt. Jelenleg ez a szolgáltatás még nem igazán elterjedt mobil környezetben. Csakúgy, mint a Peer-To-Peer technológia, ami inkább kísérleti fázisban van napjainkban mobil környezetben, de nagy valószínűséggel egyre többet fogunk hallani róla a közeljövőben. Szórakoztató VBR videók nézése, és a videokonferencia is egyre jellemzőbb, ami akár nagyobb hálózati kapacitást is igényelhet minőségének függvényében. A VoIP számít talán a legfontosabbnak mindezek közül, hiszen sokszor, és sokan használják, és lényegesen hatékonyabb technológia a hagyományos vezetékes áramkörkapcsolt hálózatokhoz képest. A web használata is népszerűnek mondható, és ennek kifejezetten érdekes a modellezése, hiszen különböző felhasználói szokások nagyon eltérő forgalmakat generálhatnak. Megvalósítottunk egy olyan szimulátort, mely mindezen modelleket képes szimulálni, egymástól függetlenül, különböző felhasználószámmal, párhuzamosan egymással mind a szolgáltatások, mind a felhasználók tekintetében. A mobilitást is kezeli, hiszen fontos tulajdonsága a vezeték nélküli hálózatoknak a cellák közti váltás, melynek különböző hatásai lehetnek, mind a hálózatra, mind az adatforgalmazó egységre. Viszont a hangsúlyt természetesen a forgalom generálására fektettük és nem a mobilitás modellezésére. – 1-3 –


A szimulátorunk képes különböző paraméterekkel dolgozni, továbbá különös hangsúlyt fektettünk a későbbi felhasználásra, és a továbbfejlesztési lehetőségekre. Éppen ezért globális megoldásokat használtunk, és a függvényeinket jól elszeparálva futtatjuk, hogy egyértelmű, átlátható interfésszel rendelkezzen, és be lehessen integrálni bármilyen új, vagy már meglévő szolgáltatást.

2. FORRÁSMODELLEK Amikor kiválasztottuk, hogy milyen szolgáltatások forgalmát próbáljuk modellezni, több szempontot vettünk figyelembe. Először is azt vizsgáltuk, hogy melyek a jelenleg népszerű szolgáltatások mobil eszközökre. A jövőre való tekintettel a jelenleg használt vezetékes hálózati szolgáltatások közül is megvizsgáltunk néhányat, mivel minden bizonnyal ezek is el fognak majd széleskörűen terjedni mobil környezeti szolgáltatásként. Így esett a választásunk a következő hat szolgáltatásra, melyeket részletesebben tárgyalunk a továbbiakban. Ezek a szolgáltatások: • • • • • •

E-mail Hálózati játékok Peer-To-Peer VBR Videók VoIP Web

– 2-4 –


2.1 E-MAIL FORRÁSMODELL Az e-mail küldés egy nagyon népszerű szolgáltatás, viszont az általa generált forgalom modellezésével viszonylag keveset foglalkoznak. Pedig kisebb sávszélességű kapcsolatok esetén a webes forgalom jelentős részét képezheti. Ezt szemlélteti az 1. ábra.

1.ábra: A forgalom megoszlása az egyes szolgáltatások között A FUNET modellt a Helsinki Műszaki egyetemen mérések után állították fel. Cauchy eloszlás alapján, α=0.8 β=1.0 paraméterekkel adható meg az e-mailek mérete (2.ábra): ⎧⎪ ⎡ ⎛ x − α ⎞ 2 ⎤ ⎫⎪ ⎟⎟ ⎥ ⎬ f ( x) = ⎨πβ ⎢1 + ⎜⎜ ⎪⎩ ⎣⎢ ⎝ β ⎠ ⎦⎥ ⎪⎭

−1

2.ábra: Az e-mail méretek eloszlása

–5–

(1)


A zöld, a piros, a fekete görbék mind olyan felhasználókhoz tartoznak, akik több mint 5000 e-mailt küldtek. A kék görbét a Würzburgi Egyetemen feladott 34000 e-mail elemzésével kapták meg. A pontos számokat az 1.táblázat tartalmazza: Forrás Felhasználó1 Felhasználó2 Felhasználó3 Mindhárom felhasználó FUNET [Bol99]

Megvizsgált email-ek száma 12110 7026 6787 34671

2. ábrabeli szín Zöld Piros Fekete Kék

Érték

Eltérés

17.6 kB 28.2 kB 30.1 kB 22.7 kB

174.8 kB 234.9 kB 209.6 kB 200.3 kB

1760

Magenta Narancs

2.7 kB 77.9 kB

17.7 kB 337.6 kB

1. táblázat: E-mail méretek mérési és modellbeli értékei Ez alapján jól kivehető, hogy a Funet modell a nagyobb méretű e-maileknél majdnem tökéletesen illeszkedik a mért értékekhez, kicsi levelek esetén azonban valamivel túlbecsüli a levelek méretét. Az ON/OFF folyamatok lényege, hogy amikor a felhasználó használ egy alkalmazást akkor az ON állapotban tartózkodunk, mikor várakozik akkor pedig az OFF állapotban (3. ábra). Egy ilyen ON/OFF modellben az alkalmazások működési idejét véletlen változók segítségével adhatjuk meg. Megújuló folyamatnak nevezünk egy folyamatot, ha ON állapot nagyon rövid ideig tart, az e-mail forgalom tipikusan ilyen.

3.ábra: Egyszerű internetes forgalom felhasználói modellje Ha M db különböző E-mail folyamatot feltételezünk és ha: λi.Email : az i. felhasználó által generált e-mail forgalom, függ a felhasználó szokásaitól, 10-4 e-mail/másodperc értékékkel lehet modellezni. AEmail: véletlen változó az összes felhasználó e-mail közti idejére

E [AEmail ] =

1

(2)

m

∑λ i =1

–6–

i


Kétféle E-mail hozzáférési módot feltételeznek: 1: a felhasználó által készített E-mail, mikor egy felhasználó küld egy vagy több levelet. A felhasználó a szerveren ellenőrzi az új leveleket, nem tölti le őket a saját gépére. 2: hálózat által készített E-mail, a szerver értesíti a felhasználókat az új leveleikről. Egy levelező kliens ellenőrzi folyamatosan, hogy érkeztek-e új levelek. Az érkező e-mailek modellezéséhez egy Poisson eloszlást használunk. λi.Email paraméter a felhasználó viselkedésétől függ, jelenleg 10-4 e-mail/másodperc értéket ajánlunk. Az e-mail forgalom összesítését szemlélteti a 4. ábra.

4.ábra: Aggregált e-mail forgalom

–7–


2.2 HÁLÓZATI JÁTÉKOK FORRÁSMODELL Az Internet 3–4% -át kitevő forgalom [3] a hálózatban játszott játékokból származik. Ezek nagy részét a legnépszerűbb akció programok teszik ki (pl.: Quake, Half–Life, Counter Strike). A többjátékos (multi–player) játékokat 3 kategóriába sorolhatjuk [4]: gyors akció (tipikusan FPS), lassú akció (pl. Diablo) és stratégiai (Starcraft, Age of Empires). A legkritikusabb az FPS kategóriájú játékok kezelése, hiszen valós időben történnek gyors események, ezért nagyon fontos feladat a csomagkésleltetési paraméter biztosítása. Maguk az akciók általában úgy zajlanak, hogy a játékos csatlakozik egy csapathoz, az élete néhány percig tart, majd újjászületik. Ezen időszakaszokban van játék a számára. A játékok által generált forgalom modellezéséhez a kinyert adathalmazt fel kell dolgozni és valamilyen eloszlást kell ráilleszteni, megfelelő paraméterekkel. Majd ezek után az illeszkedésvizsgálattal megállapítani a helyességét. A játék háttere: a szerveren fut központilag a játék, és a klienseknek küldi ki folyamatosan a státuszinformációkat (egy szerverhez több, akár nagyon sok kliens is kapcsolódhat). A kliensek pedig értesítik a szervert saját állapotukról.

5. ábra: A szerver illetve kliens oldal csomag és adatrátája

A fentiekkel magyarázható, hogy a kliensek nagyjából mindig ugyanakkora adatot küldenek. Ezzel szemben a szerver változó mennyiségű, ún. börsztös átvitelt generál, a játék aktuális állása alapján (5.ábra). Két fontos paraméter: • •

A csomagok mérete (mely a szerver esetén erősen függ az aktuális pályától, míg a kliensek részéről független minden paramétertől.) Csomagok közt eltelt idő (mely a szerver esetén állandó, viszont a klienseknél függ a grafikus megjelenítőtől: OpenGL, Software.)

Két különböző modellt ismertetünk: egy általános jellegűt, mely egyedi eloszlást használ [5] illetve egy konkrét játék, bizonyos pályáin való eseményeket leíró modellt, a lognormál eloszlás használatával [6].

–8–


2.2.1 Általános hálózati játék modell Fontos paraméterek a kliens és szerver oldalról: a csomagok nagysága és a köztük eltelt idő, melyeket ugyanazzal a függvénnyel modellezzük. Először a várakozási időt sorsoljuk ki, majd a megfelelő késleltetés után egy csomagot generálunk a függvényünk és a hozzá tartozó megfelelő paraméterek segítségével. Ez a javasolt függvény [5] pedig:

1 − f ( x) = e b

x−a b

e

−e

−

x−a b

.

(3)

Melynek integráltja:

F ( x) = e C

Börsztök közti idő Csomagméret

−

−e

x −a b

Szerver /kliensek száma a = 55, b = 6 A = 120, b = 36

.

(4)

Kliens Determinisztikus: 40 ms a = 80, b = 5.7

2. táblázat: A hálózati játék modellnél használt eloszlások paraméterei

6. ábra: A szerver forgalmának illeszkedése az általunk javasolt modellre

–9–


7.ábra: A kliensek forgalmának illeszkedése az általunk javasolt modellre

A 6. ábra a szerver, míg a 7. ábra a kliensek illeszkedését reprezentálja. Látható, hogy a szerver esetén a függvényünk a hirtelen kiugrásokon kívül jól modellezi a forgalmat. A kliensek esetén nagy eltérést mutat, viszont minél több mintát véve láthatjuk, hogy a várható értékük egyre jobban illeszkedik a javasolt függvényre. A modell hiányosságai: • • •

A játékban lévő esetleges szüneteket nem veszi figyelembe. A farokra nem illeszkedik megfelelően. Elsősorban FPS–re működik.

– 10 –


2.2.2 Egy adott hálózati játék modellezése (Half-Life) A Half–Life típusú játékoknál minden egyes pályához különböző paraméterekkel rendelkező modell szükséges, erre adunk egy modelljavaslatot az irodalom alapján [6]. Szervertől a kliens felé irányuló csomagok közt eltelt időt könnyű modellezni egy olyan hálózatban, ahol a kliensek a szervertől maximum egy „ugrás” távolságra vannak – mivel vagy állandóan 60 ms, vagy 50%–ban 50 ms és 50%–ban 70 ms. Szervertől a kliens felé irányuló csomagok hosszát pályánként külön-külön ábrázolhatjuk, mégpedig lognormál eloszlás szerint. 4 különböző pálya adatai a 3. táblázatban találhatóak:

σ (szórásnégyzet) 0.3102072 0.25086516 0.3723556 0.2415373

μ (középérték) 202.91875 154.15274 129.63025 109.76946

3. táblázat Klienstől a szerver felé irányuló csomagok közt eltelt idő a gép teljesítményétől függ – így az OpenGL–t használók ideje 50%–ban 33 ms és 50%– ban 50 ms. Szoftveres esetben konstans 41 ms–nak vehetjük. Klienstől a szerver felé irányuló csomagok hosszát normál eloszlással lehet modellezni, melynek paraméterei: σ =6.9742849, μ =72.291433.

A modell hiányossága: •

Nem általános, csakis szemléltetésre használható.

– 11 –


2.3 PEER-TO-PEER FORRÁSMODELL A peer-to-peer alkalmazások használata előre nem jósolható sebességgel növekszik, főként a nagy méretű videó/audio fájlok és szoftverek megosztására. Ez a növekedés meglepően sokkal nagyobb sebességű, mint a hagyományos HTTP forgalomé. A P2P forgalom már meghaladja a WWW forgalmat, néhány esetben jelentős mennyiséggel. Így a P2P forgalom gyors növekedése és úgynevezett sávszélesség-éhes tulajdonsága miatt jelentős hatást gyakorol a hálózat teljesítményére.

8.ábra: Egy peer-to-peer hálózat

A tanulmányozott szakirodalom alapján a Query-Cycle Modelt ajánljuk a fájl megosztó peer-to-peer rendszerek (8.ábra) forrásmodellezéséhez. Két részre osztjuk a peer-to-peer forgalmat befolyásoló paramétereket. Az első a tartalmi eloszlás, amihez pontosan meg kell tudnunk mondani a peer kérések mennyiségét és típusát. Valamint modelleznünk kell a peer-ek viselkedését, hogy milyen kérésekre válaszol, a megérkezett letöltési lehetőségek közül melyiket választja ki, illetve mennyi időt tölt a hálózaton. Először a tartalmi eloszlás kérdéseit próbáljuk tisztázni. Ha például kevés peer oszt meg fájlokat, akkor sok peer-t érintenek a kérések a hálózaton, mire találnak érvényes találatot. A 9. ábra a Gnutella program működését szemlélteti, a kérés-válasz mechanizmussal.

– 12 –


9.ábra: A Gnutella program műkődése Az adatmennyiség modellezése: Modellünkben a peer-ek tetszőleges számú fájlt oszthatnak meg. Az egyes i peer-ekhez tartozó Fi fájl megosztást a [8] eredményei alapján javasoljuk, a 10. ábra alapján.

10. ábra: Bal oldali ábra a Gnutella peer-jai által megosztott fájlok számát szemlélteti. A jobb oldali ábra a Napster és a Gnutella peer-jei által megosztott fájlokat hasonlítja össze.

Szükséges ismernünk, hogy modellezzük az egyes fájlokat, amiket az egyes peer-ek kiválasztanak. Ez azért is fontos, mivel később befolyásolja, hogy melyik peer kivel áll kapcsolatban. Megfigyelések szerint [9], egy p2p hálózatban a peer-ek általában a teljes tartalomnak csupán egy része után érdeklődnek. Például egy oktatási domain alól bejelentkező hallgatói gép általában matematikai, kutatási tartalom iránt érdeklődik. Szintén megfigyeltük, hogy sok dokumentum őrző rendszer, mint például a www is, a dokumentumai népszerűségének meghatározásához Zipf eloszlást használ. Ennek megfelelően inicializálásnál az egyes peer-ek kiválasztanak néhány tartalom kategóriát és csak ezekben a tartalom kategóriákban osztanak meg fájlokat. Ezen felül feltételezzük, hogy a fájlok különböző valószínűséggel fordulnak elő egy tartalom kategóriában. Tehát egy peer i kijelöl néhány Ci tartalom kategóriát, ekkor minden tartalom kategóriának egy c ∈ Ci érdeklődési valószínűséget ad. Ebben a modellben tehát az egyes fájlokat fc,r –el jelölve, c tartalom kategóriához tartozik és r a népszerűségi rátája ebben a kategóriában. Tehát n db tartalom kategóriát feltételezünk C={c1,…,cn} Mikor a peer inicializálódik a tartalom kategóriába c ∈ C valószínűséggel, akkor ezt a következőképpen számítjuk:

– 13 –


p (c ) =

1 c

1 ∑i =0 i n

(5)

Elvárjuk, hogy egy peer legalább Cmin tartalom kategóriában érdekelt legyen. Lehetséges, hogy egyes peer-ek nagyobb valószínűséggel érdekeltek egyes kategóriákban, mint a többiek. Egy érdeklődési értéket wci adunk az i peer-nek a c ∈ Ci tartalom kategóriában, ezt az értéket random generáljuk. I peer által a c kategóriában megosztott fájlok hányada: p (c i ) =

∑

wci c '∈C i

wci '

(6)

Az i peer által megosztott fájlok száma, amik a c kategóriában vannak:

Fci = p(c i ) F i

(7)

Feltételezzük továbbá, hogy a csatlakozás után egy peer az érdeklődési kategóriáját nem változtatja meg. Továbbá modellezni szeretnénk az egyes fájlokat a peer-eknél. Minden különböző fájlt egyértelműen lehet azonosítani a {c,r} kettőssel, ahol c a tartalom kategória ahova ez a fájl tartozik, r pedig a tartalom kategórián belüli népszerűség. fc,r megjelöléssel hivatkozunk egy ilyen fájlra. A tartalom kategórián belül vannak népszerűbb és kevésbé népszerű fájlok, ennek a modellezéséhez Zipf eloszlást használunk: 1 (8) p( f c ,r c) = r Fc 1 ∑i =1 i Ennek az egyenletnek a kiértékeléséhez modelleznünk kell a fájlokat az egyes tartalom kategóriában. Fc-vel a c kategórián belüli különböző fájlokat jelöltük. Annak a valószínűsége, hogy f fájl i peer által lett megosztva a c kategóriában beállítja a valószínűségét p(fc,r ⎜c) az fc,r fájlnak a c kategóriában p(fc,r ⎜i)= p(c ⎜i) p(fc,r ⎜c). Különböző fájlok kategórián belüli modellezése: Fca jelőli a c kategóriában a peer által nyilvántartott fájlok számát, ahol a legtöbb fájlt osztja meg a kategóriában. Másik oldalról nézve a dolgokat, ha minden egyes fájl különböző a hálózaton, akkor p(c)F különböző fájl van, ahol F a hálózaton levő összes fájl száma és p(c) azon fájlok hányada amik a c kategóriában helyezkednek el. Az igazság közben valahol csal, így beállítjuk:

Fc = d Fca + (1 − d ) p (c) F

– 14 –

(9)


Ahol d valahol 0 és 1 között elhelyezkedő érték. A vizsgálatok szerint a 0.25-öt javasolják ezen értéknek. Peer viselkedési modell:

Egy másik fontos tényező a peer-to-peer rendszerek vizsgálatánál a peer-ek viselkedésének vizsgálata, értjük itt a hálózaton eltöltött idő vizsgálatát, hogy osztanak ki kéréseket és válaszolnak rájuk. Ezen paraméterek sokféleképpen befolyásolhatják a hálózat működését, például ha nagyon gyakran változik a hálózaton részvevők állapota, az kommunikációs overhead-eket eredményez. Egy p2p hálózatban kiosztanak kéréseket, amikkel érdeklődésüknek megfelelő letölthető fájlokat keresnek. Modellünkben Poisson eloszlás szerint fogunk kéréseket generálni. Minden egyes node-hoz beállítunk egy kérés rátát inicializáláskor a {ratemin, ratemax} intervallumból. Minden kérés körnél, p (# queries == x) =

exp − λ λx x!

(10)

megadja a valószínűségét, hogy egy node kioszt x kérést, ahol λ a node kérés rátája. Modellünkben qc,r kérés reprezentálja a kérést a fc,r fájlra vonatkozólag. Azt mondhatjuk, hogy csak abban a tartalom kategóriában oszt ki kérést egy peer, amiben érdekelt. Annak a valószínűsége, hogy i peer generál egy qc,r kérést adott az érdeklődési fokával: p ( qc , r i ) = p ( c i ) p ( f c , r c )

(11)

Feltételezzük itt, hogy egy peer nem fog olyan fájlt kérni amivel már rendelkezik. Mivel a tudományos cikkek is céloztak rá, hogy a p2p forgalom mérése akár 2 hónapon belül 50%-os növekedést eredményezhet bármilyen internet szolgáltatónál, így úgy gondoltuk, hogy megnézzük egy ezzel foglalkozó cég aktuális eredményeit. A Cachelogic cég eredményei (3. táblázat) látszódnak számunkra a legközelebbinek a valósághoz: A 4 domináns Peer-to-Peer rendszeren továbbított tartalom eloszlása: Audio:

11.34%

Videó:

61.44%

Egyéb tartalmak:

27.22%

Microsoft videó formátum a teljes Peer-to Peer forgalom 46%-át teszi ki. 65%-a a teljes audio forgalomnak MP3 formátumban zajlik.

3. táblázat: Internet peer-to-peer forgalmának tartalom szerinti eloszlása

Ez az analízist a 4 domináns peer-to-peer rendszer, a BitTorrent, eDonkey, FastTrack, Gnutella forgalmára összpontosít, a fájl header dekódolásával állapítja meg, hogy milyen típusú a forgalom (11. ábra).

– 15 –


11.ábra: Cachelogic cég által mért P2P rendszerek Az általunk kidolgozott mobil Peer-to-peer modell:

Jelenleg mobil p2p forgalom modellezésére még nem léteznek modellek, mivel még mobil p2p forgalmat sem használunk. Szimulátorbeli modellünket éppen ezért úgy állítottuk össze, hogy könnyedén pontosítható legyen a bemeneti paraméterek változtatásának segítségével. Mobil p2p modellünk egyedülálló módon 3 különböző eloszlású tartományból épül fel, melyet a 12. ábra szemléltet. A három tartomány pontos kijelölését a küszöbértékek megadásával tehetjük, pillanatnyilag e küszöbértékeket 0.2 és 0.7 értékűre állítottuk.

12. ábra: p2p forgalom alakulása saját modellünkben

Az első tartomány a mobil készülékek közti szöveges, információs dokumentumok átvitelét képviseli, ebben a tartományban a leggyakoribb fájlméret 1 MB körül mozoghat. Erre a Weibull eloszlást ajánljuk, λ = 1 és k = 2 paraméterekkel. A második tartomány az mp3 forgalomra koncentrál, jelen pillanatban azt jósoljuk, hogy ez teszi ki majd a mobil p2p forgalom legjelentősebb részét. Az átlagos fájlméret itt 5.24 MB környékére tehető. Ezen forgalom modellezéséhez szintén Weibull eloszlást használtunk, λ = 5.25 és k = 9.1 paraméterekkel. A harmadik tartomány szemlélteti az mp3 albumok illetve rövid videó jelenetek letöltését. Ebben a fázisban exponenciális eloszlást használtunk, λ = 0,05 paraméterrel.

– 16 –


Hibrid P2P rendszerek

A Peer-to-Peer fájl megosztás az internetes forgalom jelentős részét teszi ki, így a megnövekedett forgalom érdekes jelentős kihívás a hálózati adminisztrátorok számára. Mobil környezetben felmerül néhány probléma, mint például a korlátolt és drága vezeték nélküli forgalom, a felhasználók elérhető, illetve nem elérhető állapotának rendkívül gyors váltakozása, valamint az eszközök limitált kapacitása. Egy példa a Hibrid P2P rendszerekre az eDonkey fájlmegosztó protokoll, ahol index szerverek összegyűjtik és felosztva szolgáltatják a fájlok helyének, népszerűségének, megbízhatóságának tulajdonságait az összes peer-re vonatkoztatva.

13.ábra: A mobil P2P struktúra felépítése

A 13. ábrán látható, hogy az index szerver monitorozza a fájl népszerűségeket, valamint exportálja az összegyűjtött adatokat a cache peer irányába. A cache peer egy speciális peer a hálózatban, ami tárolja a legnépszerűbb fájlokat a hálózatban, ezzel is csökkentve a rendkívül drága vezeték nélküli forgalmat. Így a cache peer a népszerű fájlok listáját az index szervertől fogadja és ezek után eldönti, hogy megtartsa vagy eldobja a tárolt eddigi adatokat. Amennyiben a mobil domain-ben nem találnánk meg a számunkra kívánatos tartalmat, akkor lehetőségünk van a kérést továbbküldeni valamelyik vezetékes hálózatban elhelyezkedő index szervernek. Ennek a tranzakciónak a koordinálását végzi a crawler peer.

Középérték [kB]

Csengő hangok 8.5762

Játékok

Képek

Mp3-audio

37.9288

420.2075

4829.3306

4. táblázat: P2P fájlcserélőknél mért tartalmak méretének átlagértékei

– 17 –


Világosan látszik, hogy az utóbbi két hónapban megjelent cikkek az általunk feltételezett csomagméreteknél kisebb méreteket említenek mobil p2p környezetben. Ezért szimulátorunk beállításait ezekhez az értékekhez igazítjuk. Az 5. táblázatban látható egy általános összefoglalás:

HTTP

Peer-to-Peer

Fájl méretek kicsik, egyes oldalak scripteket A fájl méretek sokkal nagyobbak, 3.5Mb-os 4 perces tartalmaznak (html, css, JavaScript stb.) valamint mp3-tól kezdve a 2GB DivX filmig bármi előfordulhat. grafikákat, amik 250kb-nál ritkán nagyobbak. A flash animációk figyelembe vételével is csak kb 500kb-ra nő az oldal mérete. Az oldalak egy session-ben lesznek továbbítva.

A letöltések megnyitnak sok párhuzamos kapcsolatot.

Egy session néhány másodpercig tart

Session-ök több napig is eltarthatnak.

Megbízható kapcsolatok, a tartalmak a web Megbízhatatlan kapcsolatok, a tartalom egy otthoni szervereken tárolódnak, nagy megbízhatósággal és számítógépen tárolódik, a letöltési sebesség így sebességgel lehet letölteni róluk. tipikusan 56k és 1024k között ingadozhat. Néhány hír portáltól eltekintve a tartalom lassan A felhasználok igényei végett, a legnépszerűbb zenei változik. vagy filmes tartalom gyorsan megváltozhat. http ragaszkodik protokollokhoz.

a

meghatározott

jól

működő A peer-to-peer szolgáltatók egyedisége következtében sokféle zárt protokoll létezik, valamint a nyílt forráskódúak is gyorsan változnak.

HTTP forgalom a 80as porton keresztül történik

A portok széles sávját használják. Mostanában, hogy elkerüljék a detektálást és kijátsszák a a forgalomszabályozó berendezéseket Peer-to-peer szolgáltatók létrehoztak olyan protokollokat amik dinamikusan változtatják a portokat, http forgalomnak is adhatják ki magukat akár a 80as portot használva.

Tükör site-ok kivételével a http egyedi URL-t biztosít a Minden p2p hálózaton lévő tartalom rendelkezik tartalomhoz egyedi hash ID-val. A felhasználok inkább a hash ID helyett névre vagy fájl méretre keresnek rá. Gyakran előfordulhat, hogy átnevezik a fájl és ugyanaz a tartalom több különféle néven is letöltésre kerül. A forgalom aszimmetrikus, a kliens egy kicsi web A forgalom virtuálisan szimmetrikus, mivel ugyanannyi kérést ad és viszonylag nagy adatmennyiséget fogad anyagot küldenek, mint amennyit fogadnak.

5. táblázat: HTTP valamint P2P forgalom összehasonlítása

– 18 –


2.4 VBR VIDEÓK FORRÁSMODELL A VBR (Variable Bit Rate) videó annyiban különbözik, a CBR (Constant Bit Rate) videótól, hogy nem egy állandó sávszélességet foglal le az átviteli közegen, hanem mindig csak annyit, amennyire épp szüksége van, a megjelenítendő kép megjelenítendő bonyolultságától függően. A VBR előnyei, hogy jobb képminőséget és kisebb késleltetést képes produkálni, az ugyanazon erőforrást használó CBR-hez képest. Alapvetően kétféle VBR videót tanulmányoztunk, mégpedig az egy és kétrétegűt. A kétrétegű annyiban tér el az egyrétegűtől, hogy van az alapréteg, amin folyik a jól megszokott egyszerű videó, és van egy felsőbb réteg, aminek kisebb a prioritása, és az alapréteg megfelelő részeit egészíti ki többletinformációval. Modellezés szempontjából nincs nagy különbség e két megoldás között, mivel vagy áramlik a két réteg, vagy helyettük egy, de az nagyobb sávszélességű. Ezért nem is foglalkozunk a továbbiakban a kétrétegű tárgyalásával. VBR videók működése szerint a kereteket (frame-eket) különböző csoportokba sorolhatjuk: • •

I, B és P keretek (I: tömörítetlenül 13.-16. képkockánként) GOP - group of pictures, vagyis képek csoportja IBBPBB vagy IBBPBBPBBPBB melyet a 14. ábra szemléltet:

14. ábra: Különböző típusú kereteket tartalmazó képcsoport

Az I mindig egy teljes képet jelent (tipikusan egy filmben lévő jelenetváltást). A P csak a változásokat tartalmazza, (jeleneteken belül) A B pedig oda-vissza irányú láncolást is tud (keresés könnyítése érdekében).

– 19 –


Mindig I kerettel kezdődik a videó, majd következnek a P (és B) keretek, a következő jelenetváltásig. Mivel a P keretek csak a változást tartalmazzák, ezért a csomagvesztés idővel komoly képminőség romlást, és hibaterjedést eredményezne. Hogy ezt elkerüljék, ezek a csomagok is tartalmaznak I keretnek megfelelő adatokat, melyet több P keret alkot. (Legfeljebb 15 db. P keretenként frissül minden képblokk.) Két témakört vizsgáltunk meg behatóan, az egyik a videokonferencia, és a másik a hagyományos szórakoztató videó [10]. Tulajdonságaik: • •

Videokonferencia: nincsenek B keretek, ritkák a jelenetváltások: DAR modellt ajánljuk Szórakoztató videó: mivel gyakran előfordulhat benne jelenetváltás, ezért a Markov modellt javasoljuk

Ezeken kívül ismertetünk egy egyszerűbben megvalósítható, és könnyebben áttekinthető általános modellt, mely a lognormál eloszlás használatával szimulálja az áramló videó forgalmát [11]. A modellezésünkhöz szükséges eloszlások: Gauss eloszlás: ⎡ 1 ⎤ Pr(a n = k ) = − log 2 ⎢1 − 2 ⎥ ⎣ (k + 1) ⎦

(12)

Lognormál eloszlás:

1

f ( x ) = xσ 2π e

−

−( ln x −μ )2 2 σ2

– 20 –

ha x > 0

(13)


2.4.1 Markov modell A modellben az állapotokat az éppen aktuális keretek hosszai jelentik. Mivel így túl sok állapotunk lenne, ami sem nem praktikus, sem nem takarékos, ezért kis számú ekvivalencia osztályokba soroljuk a kereteket hosszuk alapján, így a modellünk komplexitása kezelhetőbb lesz. A szimulációhoz három dolgot kell meghatároznunk. Először is a klaszterezési algoritmust, mely az állapotok számát határozza meg, majd modellezzük az állapotok közti átmeneteket, végül meghatározzuk a kimenetek bitrátáját az egyes állapotokban. A következő klasszterezési algoritmust használhatjuk: Bevezetjük a centroid fogalmát, melyet a következőképpen definiálunk: 1 nk ( k ) m (k ) = ∑xj nk j =1

(14)

Az egyes klassztereken belüli hibaértéket a nk

c k2 = ∑η 2 ( x (jk ) , m ( k ) )

(15)

j =1

összefüggés adja meg, míg a teljes klasszterezésre a hibafüggvény a: K

E K2 = ∑ c k2

(16)

k =1

1. Vegyünk fel egy tetszőleges kezdeti partíciót (K részre). 2. Hozzunk létre egy új partíciót úgy, hogy minden elemet a hozzá legközelebbi centroidhoz rendelünk. 3. Számítsuk ki az új középpontokat (1) alapján és hibafüggvény értékét (2) és (3) alapján. 4. Ismételjük a 2) és 3) lépéseket, amíg a hibafüggvény értéke csökken. A videokonferenciához K=16, vagy K=18, míg szórakoztató videóhoz K=17 a javasolt [10]. Az állapotok közti átmenetek: Egy K állapotú Markov-lánc átmeneti valószínűség-mátrixának elemei: átmenetek száma i → j − be Pij = átmenetek száma az i − n kívül

(17)

- i,j reprezentálja a K állapotát a modellnek. Az átmenetek legnagyobb részére igaz, hogy minden i esetén, pi -ből {p ii - 1, p ii , p ii - 1} állapotba való lépést hajtanak végre, tehát 90%-ban egy, vagy nulla állapotot lépnek, ami az adatok kiértékelését könnyíti meg számunkra.

– 21 –


Ezt a PK mátrixot információ hiányában konkrét videók elemzésével lehet létrehozni. Az így kapott minták használhatók modellezésre. Kimenetek bitrátája: Miután a mért adatainkat megfelelő klaszterekbe csoportosítottuk, és megvannak az ezen állapotok közti átmenet-valószínűségek is, úgy az állapotokhoz hozzárendelhetjük a klaszterezés során tapasztalt bitráta értékét, melyet az adott állapotokban kell generálni. Ez a modell jól átlátható, viszont nehéz megvalósítani a szükséges statisztikák nélkül, amiket viszont majd elő tudunk állítani a jövőben a videó folyamot keretekre tördelő és számláló programunk segítségével.

– 22 –


2.4.2 DAR modell A bitrátát anélkül próbáljuk megállapítani, hogy pontos, részletes állapotokat hoznánk létre. A múltból következtetünk a jövőre. Ebben az esetben az átmenetek valószínűsége elég kicsi, ami azt jelenti, hogy a bitráta egymást követő értékei közt nincs nagy különbség (tipikusan 1 klaszternyit ugrik). Tehát, mint ahogy már láttuk a szórakoztató videónál, itt jelenetváltás során megugrik a bitráta értéke, úgyhogy rá nem alkalmazható ez a modell. Viszont a videokonferenciánál, ahol nincs hirtelen jelenetváltás, nem szükségesek a B keretek, így tökéletesen alkalmazható ez a modell. Először a P, majd az I keretek ábrázolását mutatjuk meg a [10] alapján. Az elsőrendű AR bitrátája P keretekre: ~ ri (n) = α i ~ r j (n − 1) + g i (n)

(18)

Ahol i=1,…, K jelenti az állapotok halmazát, ~ ri (n) az i-edik állapotban lévő keretráta, melynek a várható értéke 0. Az α i az elsőrendű AR tényező, és a maradék (zaj) tényező a g i : N (0, σ i2 ) , ami egy nulla várható értékű Gauss eloszlás, σ i szórással. Az ARP paramétereket a következő módon lehet megadni:

α=

c rr [1,0] , c rr [1,1]

(19)

és

σ 2 = c rr (0,0) − α c rr (0,1) ,

(20)

ahol c rr ( j , k ) =

N −1 1 ( ∑ r (n + j )r (n + k ) ) N − 1 n =1

(21)

egy módosított kovariancia-függvény, és N jelenti a kiértékelt minták számát. A keretráta a következő összegből áll: ri (n) = mi (1 − α i ) + α i ri (n − 1) + g i (n) ,

(22)

az mi jelenti a becsült értékét az i. állapotnak. Így minél nagyobb az elsőrendű AR tényező (α), annál kisebb az eltérés az előző keretekhez képest. Feltesszük, hogy a rendszer a j állapotban van az (n-1)., és i-ben az n. időpillanatban. Ekkor: ri (n) = mi (1 − α i ) + α i r j (n − 1) + g i (n) ,

i= j

(23a)

ri (n) = mi + g i (n) ,

i= j

(23b)

– 23 –


ahol i,j=1,2,…,K és az α i=0, ami jól közelíti az I keretek állapotát. Ez a modell viszonylag bonyolult, viszont a megvalósítása nem annyira nehéz, és nagyon jól lehet vele modellezni a videokonferencia forgalmát.

– 24 –


2.4.3 Lognormál modell Az I, B és P keretek hosszainak hisztogramjára a legjobban a lognormál eloszlás sűrűségfüggvénye illeszkedik [11], a 6. táblázatból kiolvasható paraméterekkel: Típus I P B

µ 5.1968 3.7380 2.8687

σ 0.2016 0.5961 0.2675

6. táblázat: I,P,B keretek paraméterei

A fenti adatok konkrét mérések eredményei, maximum likelihood módszerrel számított értékek. A lognormál eloszlás sűrűségfüggvénye:

1

f ( x ) = xσ 2π

e

−

− (ln x −μ )2 2σ2

ha x > 0

(24)

Így tehát a modell a következő: • • •

A jelenet hosszát geometriai eloszlás szerint választjuk meg 10,5-ös várható értékkel. A jeleneten belül azonos méretű I keretek követik egymást, melyek hosszát lognormál eloszlás alapján választjuk meg a fenti paraméterekkel. A P és B keretek hosszát is lognormál eloszlás alapján választjuk, de ezek függetlenek egymástól a jeleneten belül is.

Egyszerű és könnyen implementálható modell, viszont nem túl precíz a VBR videó forgalmának leírásában.

– 25 –


2.5 VOICE OVER IP FORRÁSMODELL Napjaink egyik legfontosabb kommunikációs szolgáltatása a beszédátvitel. A VoIP, mint beszédátviteli megoldás számos előnnyel rendelkezik a hagyományos távközlési módszerekhez képest. Kihasználja a csomagkapcsolt hálózatok előnyeit, a minősége pedig nagyjából megegyezik az áramkörkapcsoltéval. Komoly kutatások folynak a hagyományos beszédátvitelű mobil, és a wifi hálózatok közti egyidejű rugalmas forgalom megvalósítására, melynek bevezetése után még nagyobb népszerűségnek örvendhet majd ez a technológia. On-Off modellel lehet modellezni a beszédátvitelt. Ha ki van alakítva egy kapcsolat, akkor a kodekek nem generálnak adatátvitelt, csak beszéd közben, míg mások a kapcsolat ideje alatt állandóan forgalmaznak adatot, mely [12] szerint konstans, a kódolóra vonatkozó érték. Ezért a VAD (Voice Activity Detector) szerepe nem lényegtelen a modellezés szempontjából. Különböző kodekek pl.: G.723, G.729, GSMFR. A VoIP szolgáltatásnál a modellezni kívánt paraméterek: •

Hívások közti idő

•

Beszélgetések ideje (tartási idő)

A hívások közti, és a tartási időket is hagyományosan exponenciális eloszlással szokták modellezni. Bemutatunk egy fraktális modellt [13], mely nagyban eltér a hagyományos beszédmodellezési elméletektől, mivel tartási időnél nem exponenciális, hanem Pareto eloszlást használ. Majd szemléltetünk egy „klasszikus” eljárást, mely exponenciális eloszlásokat használ. Végül az előzőt kiegészítjük, azzal, hogy a konfortzaj által generált forgalmat is figyelembe vesszük.

– 26 –


2.5.1 Fraktális modell A fraktális modell [13] egy érdekes, újszerű megfontolást vet fel, mivel szakítani próbál azzal az elvvel, hogy beszéd esetén mindent exponenciális eloszlással kellene modellezni. Ezzel bonyolítja, mondhatni kiterjeszti ezt a kutatási fejezetet. A hívások közti idő modellezésére exponenciális eloszlást javasol:

⎧λe − λx , ha x ≥ 0 F( x ) = ⎨ ⎩ 0 , ha x < 0 λ = 0,164 –es paraméterrel.

(25)

A tartási időre nem a hagyományos exponenciális, hanem a Pareto eloszlás illeszkedik jobban, mert jelen esetben nem elhanyagolható a farok nehéz tulajdonsága. 1 ⎧ k k ( x m ) − ⎛ ⎞ ⎪⎪1 − ⎜1 − , ha k≠0 ⎟ F( x ) = ⎨ ⎝ s ⎠ x −m ⎪ − ⎪⎩ 1− e s egyébként

Ahol k = -0,39, és s = 69,33.

(26)

Mivel nagy számú, nehézfarkú ON-OFF forrást reprezentálunk, ezért a Pareto eloszlás szuperpozíciója hosszútávon összefüggő, tehát önhasonló forgalmat generál. (József effektus). Def.: Az X(t) folyamat stacionárius növekményű, ha:

{X (t + h) − X (h)} = d {X (t ) − X (0)}, ∀h.

(27)

Legyen Z(t) egy stacionárius növekményű, önhasonló folyamat. Állítás: Minden H(0, 1) értékhez pontosan egy Y Gauss-i folyamat létezik, ami egy Z(t) önhasonló folyamat stacionárius növekménye.

{X } = d {m − H X (m )}, ahol 0,5 ≤ H <1.

(28)

Az ajánlott függvény, mely általánosan modellezi a VoIP forgalmat, felhasználva az Y fraktális Gauss zajt:

X (t ) = m + σZ H (t )

Ahol Z H (t ) jelöli a fraktális Gauss zajt, megfelelő Hurst paraméterrel, és m = 1938.5, σ = 79.635, H= 0.93. – 27 –

(29)


Ez a modell szemmel láthatóan is megfelelően modellezi a G.723 forgalmát (15.ábra):

Mért adat

Az előző modellel szimulált adat

15.ábra: A VoIP forgalmának illeszkedése a modellre

Ennek a modellnek a hátránya, hogy nehéz megvalósítani, és az alapelve nem széleskörűen elterjedt, ezért a továbbiakban a hagyományos exponenciális eloszlású megközelítéssel foglalkozunk majd.

– 28 –


2.5.2 Exponenciális modell Itt is a G.723-as szabványt vizsgáljuk [14]. Általánosan elfogadott modell a hanghívásra, a folytonos idejű, diszkrét állapotú Markov-lánc mely a 16. ábrán látható. A tartási időről feltesszük, hogy exponenciális eloszlású mindkét állapotban.

16. ábra: A VoIP 2 állapotú Markov-lánca

Az általánosságban használt paraméterek:

1

λ

= 0.650 mp., és

1

μ

= 0.352 mp. Ezekre

az értékekre rendszerint a következőképpen hivatkoznak: a hagyományos csomagkapcsolt beszédmodell paraméterei. A 7. táblázatból kiolvashatóak a paraméterek értékei. Egyszerű digitális beszédmodell

Beszéd Csend

1.34 mp 1.67 mp

Hagyományos Csomagkapcsolt csomagkapcsolt hálózati beszédmodell beszédmodell 0.352 7.24 μ =0,7462 μ =2,8409 μ =0,1381 mp mp 0.65 5.69 λ =0,5988 λ =1,5384 λ =0,1757 mp mp

7. táblázat: Különböző beszédmodell paraméterei

Mivel exponenciális eloszlással ábrázoljuk, ezért a Csend állapotból λ valószínűségi változó behelyettesítésével lépünk a Beszéd állapotba, míg a másik irányba μ változóval, ugyanúgy exponenciális eloszlással. A beszélgetések átlagos értéke: 120 másodperc. Az exponenciális eloszlás várható értéke: E [ X ] =

1

λ

A megadott adatokból rendre meg lehet adni a paramétereket. Pl. tartási időre a megfelelő Markov-lánc paraméterei hagyományos csomagkapcsolt beszédmodell esetén λ = 1,53846, és μ = 2,84090 exponenciális eloszlással. A hívások időtartama szintén exponenciális eloszlású, és λ = 0,0083333.

– 29 –


Mivel az aktív beszélgetés, valamint a nyugalmi állapot exponenciálisan fel vannak osztva az 1/β és 1/α átlag időtartamai szerint, ezért egy exponenciális X változó a következő sűrűségfüggvénnyel rendelkezik: ⎧ae − ax x > 0; a > 0 fx(x) = ⎨ ⎩ 0, máskülönben

ahol E[X]=1/a és var[X]=1/a2 Az időnek az a hányada, amikor a hang forrásunk „on” állapotban tartózkodik:

(30)

α α +β

Arra számítunk, hogy átlagosan 30.83%-a az időtartamnak beszélgetés, 61.47%-a pedig néma csendes állapot, ezt az arányt javasolja az ITU-T a beszélgetésekre [16]. Esetünkben az 1/β és az 1/α 1.004s illetve 1.587s. Mikor a hangforrásunk „on” állapotban tartózkodik, akkor fix méretű csomagokat generálunk egy konstans intervallumra. Mikor „off” állapotban vagyunk, akkor nem továbbítottunk csomagokat. A csomagok mérete és a ráta, hogy melyik csomagokat küldjük függ az aktuális hang kódolótól és csomagolási sémától. Xi(t) a pillanatnyi rátája az i hang kapcsolatnak: ⎧ R mikor a forrás aktív Xi(t) = ⎨ ⎩0 mikor a forrás néma Ahol R a hang bit rátája (csomag méret / csomag intervallum)

(31)

Amikor Beszéd állapotban van a Markov-lánc, akkor vagy 6,3 kbit/s os forgalmat generál (nagy adatráta), vagy 5,3 kbit/s-osat (alacsony adatráta), különböző kódolóknak megfelelően.

– 30 –


2.5.3 Exponenciális modell, komfortzaj figyelembevételével Ez a megoldás a komfortzajt is figyelembe veszi modellezéskor [15], de egyébként exponenciális eloszlást használ. A SID kereteket a beszélő oldalon generálhatjuk abban az esetben, ha az inaktív állapotba kerülünk. SID kereteket a kodek DTX algoritmusának segítségével generálhatjuk. Az ilyen működést ON-SID modell szerinti működésnek nevezzük. A SID keretek véletlenszerűen generálódnak. Egy véletlen X változót az egymást követő NoTXN keretekre definiálunk, a néma állapotban két SID keret közt eltelt időtartamhoz. i ≡ Prob ( X=i )

(32)

Ez egy valószínűségi sűrűség függvény, amit próbaképpen definiáltak a különböző komfortzajokra. A SID keretek közti idő a néma állapotban: X+1 ON-SID modell általános képlete:

R = p ⋅ R ON + (1 - p) ⋅ R SID

(33)

Ahol R a bitráta, p a beszélgetés aktivitási tényező, valamint annak a valószínűsége, hogy ON állapotban vagyunk. ON állapotban:

RON =

N fpp ⋅ L ACT + H N fpp ⋅ T

=

L ACT H + T N fpp ⋅ T

(34)

Ahol H az overhead, Nfpp pedig az ACK keretek száma (mely általunk választható). Az átfogó képlet levezetés után: R=

H T

(

p N fpp

+

(1 − p )

∑

∞ i =0

Pi (i + 1)

∞

⋅∑ i =0

Pi N ⎡ fpp ⎤ ⎢ ⎥ ⎢ (i + 1) ⎥

)

Ahol, T a determinisztikus küldések közti idő.

– 31 –

+ p⋅

L ACT T

+

LSID T

(1 − p )

∑

∞ i =0

Pi (i + 1)

(35)


A modell alapján (8.táblázat): Lsid (SID framek száma) P (Activity rate) Ton (mean duration) Toff (Off periods)

G.729 7.69%

AMR 7.58%

G.723 3.59%

0.4559 336

0.4717 1026

0.4697 1490

420

1171

1722

8. táblázat: Különböző protokollok tulajdonságai

Az eredmények a 9. táblázatban találhatóak:

9.táblázat: A modellt igazoló összehasonlítások

Az 8. táblázat szerint látható, hogy a VoIP forrásgenerátorunk majd 3 féle kodeket tud modellezni, többféle csomagmérettel, amelyek tipikusan CBR forgalmat jelentenek az ON állapotban. Látható, hogy a SID frame-ek figyelembe vételével 20-30%-al pontosabb forgalmi modellt kaphatunk, így javasolt az ON-SID modell használata.

– 32 –


2.6 WEB FORRÁSMODELL Többféle módszerrel lehet mérni a web forgalmat, pl. a tcpdump nevű programmal, ami a hálózatban folyó adatokból nyeri ki az információkat, majd erre írunk egy szkriptet, mely a számunkra hasznos információkat nyeri ki: ez a HTML– REDUCE [17]. Vagy egyszerűen egy webszervernek vizsgálgatjuk a log fájlját, és a kliens böngészőjébe is megfelelő loggolót építünk be. Az irodalom alapján a következő általános modelljavaslatra jutottunk: A weblapoknál a fontosabb paraméterek: oldalkérések közti szünet, az objektumok száma, mérete és a felhasználó gondolkodási ideje. Meg lehet különböztetni a kért lap méretének ábrázolását az általa hivatkozott egyéb objektumok méretétől. Ezeket megfelelő hierarchiában való modellezés alapján úgy célszerű végezni, hogy: 1. Valamilyen eloszlás szerint modellezzük az aktuális kérések közti szünetet, mely azt jelenti, hogy éppen hányan nézegetik az aktuális oldalt, vagyis milyen sűrűn kell kiszolgálni a klienseket. 2. Utána a weblapon lévő objektumok számát célszerű megállapítani, ami a letöltött oldallal járó egyéb fájlokat jelenti: pl. képek, hangok, java applikációk, stb. 3. Miután megvan a letöltendő objektumok száma, megállapítjuk a méretüket.

Főobjektummal együtt

Főobjektumot külön a többitől

4. A felhasználó gondolkodási idejét is bele kell számítani, ami azt az időt jelenti, amíg az oldal iránt érdeklődő épp nem tesz semmit két kattintás közt.

– 33 –


A legjellemzőbb eloszlások, melyeket az [17], [18] és [14] is javasol, és a forrásgenerátorunkban majd használni fogunk (Lognormál, Exponenciális, Weibull, Pareto, Gamma):

⎧ [ln( x ) − μ ]2 ⎫ * exp − ⎨ r ⎬ 2 σ * 2π ⎩ 2 *σ ⎭

f log normal ( x) = r

1

f exp onencialis ( x ) = λ * exp − {λx}

μ ⎛x⎞ f weibull ( x) = r * ⎜ r ⎟ σ ⎝σ ⎠

μ −1

⎧⎪ ⎛ x ⎞ μ ⎫⎪ * exp⎨− ⎜ r ⎟ ⎬ ⎪⎩ ⎝ σ ⎠ ⎪⎭

x mk f pareto ( x) = k k +1 , ha x ≥ xm x −

f gamma ( x) = x k −1

λ=

1

σ

(36)

(37)

(38)

(39)

x

θ

e , ha x > 0 θ Γ(k ) k

(40)

Két hasonló megfontolású modellt mutatunk be, melyek közül az egyik nem veszi figyelembe a főobjektum és az általa kért egyéb fájlok mérete közti egyértelmű különbségeket [17]. A másik annyival több, hogy szétválasztja ezeket, és méretüket különbözőképpen számolja [14]. Természetesen mivel eltérő ezen modellek származása, ezért használ más-és más eloszlásokat, a megegyező részekre is.

– 34 –


2.6.1 Web forrásmodell egységes objektumokkal A következő paramétereket kell figyelembe venni a web forgalmának modellezésénél [17]: 1. Kérések közti szünet: Ennek modellezésére használható a Weibull és az exponenciális eloszlás is. Mindkettő ugyanolyan jól közelíti a mért forgalmat. 2. Az objektumok számát (amik a weblap letöltésével járnak együtt) a delta + lognormál eloszlással modellezhetjük. 3. A méretüket is lognormál vagy Weibull eloszlással tudjuk meghatározni, ahol az első jobban illeszkedik a farokra, de a másodikat is alkalmazhatjuk, ha a Pareto (ami kifejezetten jó a farok leírására) eloszlással folytatjuk a megfelelő küszöbtől [18]. 4. A gondolkodási idő sem elhanyagolható, hiszen vannak rutinosabb, rutintalanabb, eltöprengő és gyorsan ugráló felhasználók is. Ennek modellezésére is a lognormál illeszkedik leginkább. Az eloszlásokhoz tartozó paraméterek értékei a 10. táblázatból olvashatók ki.

Kérések közti szünet Objektumok száma Fájlméret Gondolkodási idő

Eloszlás Weibull Exponenciális ( λ = 1.1471 ) 0.5 * δ ( x − 1) + Lognormál Lognormál Lognormál

Középérték 0.9788

Szórásnégyzet 0.8636

1.7448 8.27 2.754

1.0514 2.16 1.566

10. táblázat: A megfelelő eloszlások paraméterei

Érdemes még megemlíteni az oldal letöltési idejének modellezési jelentőségét, mert ha ezt nem vesszük figyelembe, akkor még nagyobb lesz a modellezési hiba a kérések közti szünetben a valós forgalomhoz képest. Az [17] szerint a szimulált forgalom alapján: a figyelembe vétel esetén 13 %, míg ha figyelmen kívül hagyjuk, akkor 16% lesz az eltérés. A letöltési időt egy M/G/1/FIFO–modellel lehet ábrázolni. Ahol: M az emlékezet nélküli, vagy markovi, azaz exponenciális eloszlás; G egy tetszőleges eloszlás; 1 jelzi a kiszolgálók számát, és FIFO a várakozás rendezését modellezi.

– 35 –


2.6.2 Web forrásmodell megkülönböztetett objektumokkal Ez a modell nem veszi figyelembe azt, hogy egy adott oldalt milyen sűrűn látogatnak. Mindössze azt jellemzi, hogy egy weblap letöltése milyen forgalmat generál. Külön veszi a fő– és a külső objektumokat, méghozzá úgy, hogy főnek tekinti azt, amit közvetlenül kérünk le a böngészőnkkel, míg mellékobjektumnak azt nevezi, amire a fő közvetlenül hivatkozik és letöltését kezdeményezi. (képek, java, flash) 1. A nézési idő (amit az előző modellünkben gondolkozási időnek neveztünk): amikor a felhasználó, nem aktív, csak nézi az oldal tartalmát. Ennek modellezésére itt viszont Weibull eloszlást használunk. [s] 2. A külső objektumok száma: azok a fájlok, melyek a weblap letöltésével járhatnak együtt, de nem a főobjektumunk. Ezt Gamma eloszlással szimulálhatjuk. 3. A főobjektum méretét lognormál eloszlással tudjuk meghatározni. [kB] 4. A külső objektumok méretét is lognormál eloszlással tudjuk leírni. [kB] Az eloszlásokhoz tartozó paraméterek értékei a 11. táblázatban szerepelnek.

Nézési idő Külső objektumok száma Főobjektum mérete Külső objektumok mérete

Eloszlás Weibull

Középérték 25

Gamma

7

Szórásnégyzet 8,57 *103 130

Lognormál Lognormál

13 10

625 1,59 *10 4

11. táblázat: A megfelelő eloszlások paraméterei

Így a generálandó adatcsomagok mérete:

S = S Fő +

nKülső

∑S i =0

Külső

(41)

Ahol S Fő jelenti a főobjektum méretét, n Külső a külső objektumok számát és S Külső ezek méretét.

– 36 –


3. SOMOSI (SOURCE MODELING SIMULATOR) - IP szintű forrásmodellezést megvalósító program A fő célunk az volt, hogy egy olyan szimulátort valósítsunk meg, amely az általunk kidolgozott forrásmodelleket képes szimulálni, egymástól függetlenül, lehetővé téve az egyes felhasználok számára, hogy párhuzamosan akár több mobil szolgáltatást is igénybe vegyenek. A mobilitást is kezelni kellett, hiszen fontos tulajdonsága a vezeték nélküli hálózatoknak a cellák közti váltás, melynek különböző hatásai lehetnek, mind a hálózatra, mind az adatforgalmazó egységre. Egy fontos követelmény volt a szimulátorunkkal szemben, hogy képes legyen különböző bemeneti paraméterekkel dolgozni, ami akár új forrásmodellek beiktatását is lehetővé teszi. Egy másik lényeges szempont volt a szimulátor továbbfejleszthetősége is, ugyanis így különböző szimulációs programok számára szolgáltathat bemeneti adatokat adott mobil multimédiás szolgáltatásokat igénybevevő felhasználok IP csomag küldési igényeiről. Megvalósítottuk az előbbiekben ismertetett forrásmodelleket: 1. 2. 3. 4. 5. 6.

Web VoIP Peer-to-peer VBR video Online játékok E-mail

- Web forrásmodell egységes objektumokkal - Exponenciális modell - Az általunk fejlesztett modell - Lognormál modell - Általános hálózati játék modell - Cauchy eloszlású modell

– 37 –


3.1 A SZIMULÁTOR KERETRENDSZERÉNEK FELÉPÍTÉSE A program alapvető működését a keretrendszert megvalósító adatszerkezetek és függvények valósítják meg. Az inicializáló függvény a futtatás elején felépíti a megfelelő adatszerkezetet a memóriába, a fogyasztó függvény pedig minden meghívása alkalmával a következő esemény paramétereit adja vissza egy struktúrában. Az adatszerkezet az inicializáló függvény meghívásakor létrejövő dinamikus tömbökből áll. Ezek a tömbök az egyes felhasználók által generált események következő bekövetkezési időpontjait tartalmazzák az egyes szolgáltatások szerint szétválasztva. Mivel egy felhasználó egy időben többféle szolgáltatást is igénybe vehet, az hogy egy adott felhasználó potenciálisan mely szolgáltatásokat veszi igénybe, egy külön tömbben tárolódik. A felhasználói csoportokat (az általuk igénybe vett szolgáltatásokat) és az egyes csoportok felhasználóinak számát a config fájlban lehet megadni. A megvalósított szolgáltatások alapvetően az ON/OFF modellre épülnek. Minden szolgáltatás szempontjából tehát szükség van egy AKTIVÍTÁS VÉGE, ON ÁLLAPOT KEZDETE, ON ÁLLAPOT VÉGE tömbökre. Ezen tömbök i. eleme az adott esemény következő bekövetkezésének időpontját tartalmazza az i. felhasználó számára. Az inicializáló függvény ezen tömböket létrehozza a memóriában, és az egyes szolgáltatások eloszlásfüggvényei segítségével ki is sorsolja azok tartalmát. Természetesen egy-egy szolgáltatás esetében annyi felhasználó esetében sorsolja csak ki az időbélyegeket, ahány felhasználó az adott szimulációban használni fogja azt a szolgáltatást. Ezek után már futtatható a fogyasztó függvény, mely kikeresi a legkisebb időbélyegű eseményt a tömbökből és lekezeli azt az adott esemény szolgáltatásának tulajdonságai alapján. 1. Ha aktivitás vége történt, akkor kisorsol egy inaktivitási időtartamot, ezt hozzáadja az aktivitás vége időbélyegéhez, és a megfelelő virtuális felhasználó helyére berakja az új időpontot az ON ÁLLAPOT KEZDETE tömbbe. Majd sorsol egy aktivitási időtartamot, amit hozzáad a frissen sorsolt aktivitás kezdete időbélyeghez és belerakja az AKTIVÍTÁS VÉGE tömbbe. Végül sorsol egy ON állapotban maradás időtartamot, hozzáadja az on állapot kezdete időponthoz és belerakja az ON ÁLLAPOT VÉGE tömbbe. A sorsolás eloszlásfüggvénye természetesen minden esetben attól függ, hogy milyen szolgáltatás eseményét kell lekezelni. A függvény által visszaadott struktúrában az aktivitás vége esemény időbélyegét, a felhasználó sorszámát, és az igénybevett szolgáltatás sorszámát találhatjuk. 2. Ha on állapot vége történt, akkor egy off állapotban maradás időtartamot sorsol, és az előbb látott módon frissíti az ON ÁLLAPOT KEZDETE tömböt. Majd egy on állapotban maradási időtartamot is sorsol, és az eddigiekhez hasonlóan módosítja az ON ÁLLAPOT VÉGE tömböt. A visszaadott struktúra az aktivitás vége eseménynél bemutatott paramétereket tartalmazza. 3. Ha on állapot kezdete esemény történt, akkor az on állapot kezdete időpillanathoz hozzáadja egy IP csomag elküldési időtartamát, melyet a config fájlban található MTU és PCR alapján számol ki és ezt az időbélyeget visszaírja az ON ÁLLAPOT KEZDETE tömbbe a megfelelő felhasználó helyére. A visszaadott struktúra tartalmazza az elküldött IP csomag maximális méretét (MTU) és az esemény további paramétereit.

– 38 –


3.2 A PROGRAM HASZNÁLATA A SOMOSI.h állományt be kell tölteni a programba. A futtatás elején meg kell hívni a „void inicializal()” függvényt. Ezután, minden alkalommal, amikor egy következő esemény paramétereire van szükség, meg kell hívni a „struct fogyaszt()” függvényt, mely egy struktúrában visszaadja a kívánt információt A visszaadott struktúra formátuma: struct info //kimenet { double meret; //csomagméret double timestamp; //időbélyeg int mobindex; //melyik mobil int tipus; //milyen tipusu szolgáltatás: 1..6 int esem; //milyen esemény: 0 aktveg, 1 onveg, 2 onkezd };

Azaz lebegőpontos alakban adja vissza a csomagméretet (MTU) bájtban értelmezve, valamint az esemény időbélyegét (másodperc). A fogyasztó függvény többszöri hívása mindig időbélyeg szerinti következő egyetlen eseményt (IP csomag vagy aktivitás vége) adja vissza, és ezeket a többszöri hívás során mindig rendezve, időbélyeg szerint növekvő sorrendben. A három egész típusú változó az adott szolgáltatást igénybe vevő felhasználó azonosítója (sorszáma a populációban); a szolgáltatás azonosítója (1=web, 2=email, 3=VoIP, 4=hálózati játék, 5=VBR, 6=peer-to-peer); valamint az esemény típusa (0=aktivitás vége, 1=utolsó csomag az aktuális ON szakaszban, 2=nem utolsó csomag az ON szakaszban).

– 39 –


3.3 PARAMÉTER, ÉS MODELLKEZELÉS A keretprogram headerfüggvénye (eloszlas.h) két fontos szerepet tölt be: • •

Paraméterek fájlból való beolvasása Forrásmodellek megfelelő eloszlásának megvalósítása

3.3.1 Fájlból való beolvasás Léteznie kell egy config.dat nevű állománynak a futtatható fájlal azonos mappában, mely tartalmazza a megfelelő paramétereket. A függvény globális változókba olvassa ezeket az adatokat, melyek az egyszerűség kedvéért megegyeznek a fájlban található nevekkel. Ezt a műveletet egy load() nevű függvény végzi, mely a fájl formátumnak megfelelően végigmegy azon, és elvégzi a megfelelő olvasásokat. Az alapparaméterek az általunk javasolt forrásmodellek paraméterei. A config.dat fájl formátuma: egy sor jelöli a változó nevét, majd a következő sor az értékét. A felhasználói csoportok definiálása esetén 2 jellemző van, az adott csoport által gyakran igénybevett szolgáltatások illetve a csoportba tartozó mobil felhasználók száma, ezért ott két érték követi a változó nevét. A beolvasott értékek vagy integer, vagy float típusúak. A paraméterek sorrendje tetszőleges, mindössze az értelemszerű kitöltés szükséges, hogy a változó neve alatti sorban kell lennie a változó értékének, különben automatikusan 0 értéket vesz fel. A felhasználói csoportok esetén fontos, hogy 2 sort vár a program bemenetként. A paraméterek listáját lásd a mellékletben (Lista 1.).

3.3.2 Forrásmodellek megvalósítása A következő eloszlásfüggvények lettek megvalósítva: • Exponenciális • Lognormál • Weibull • Poisson • Cauchy • Egyéni, online játékok modellezéséhez használatos eloszlás. Ezeket felhasználva bizonyos forrásmodellek egyedi tulajdonságainak megfelelő függvények megvalósításai is megtalálhatók, melyek a végső, a főprogramban való meghíváshoz használatos függvényeknek segédfüggvényei. Ilyeneket használ a VBR videó és a p2p. A többi esetben egyszerűen közvetlenül a főprogramból lehet meghívni a különböző, értelemszerűen elnevezett eljárásokat. Ezek minden szolgáltatásról visszaadják az aktivitási idejét, az inaktivitás idejét, az aktív állapotban való ON állapotok közti szünetet, és az aktuális csomagméretet kB-ban. A megvalósított forrásmodellek:

– 40 –


Web - Web forrásmodell egységes objektumokkal. A felhasznált paraméterek: Kérések közti szünetre Weibull eloszlást, λ: 0.9788, Objektumok számára lognormál μ: 1.7448, Fájlméretre is lognormál μ: 8.27, Gondolkodási időre szintén lognormál eloszlást μ: 2.754, használunk, és a paramétereit ajánljuk.

k: 0.8636 σ: 1.0514 σ: 2.16 σ: 1.566

VoIP esetén a „klasszikus” exponenciális eloszlást alkalmazzuk a csend, és a beszéd állapotok közti átmenetekre. Csendből a beszédbe valót 1.5384, míg a vissza irányút 2.8409 paraméterrel javasoljuk. VBR Videó esetén a lognormálos megoldást választottuk megvalósítani. A javasolt paramétereink különböző frame-ek esetén: I esetén: μ = 5.1968, σ = 0.2016. P esetén: μ = 3.7380, σ = 0.5961. B esetén: μ = 2.8687, σ = 0.2675. Online játékok - Általános hálózati játék modell. Esetünkben a lefele irányuló forgalmat vizsgáljuk, ezért elegendő csak a kliens viselkedését megvalósítani. Ennek ellenére már a szervert is beillesztettük a kódba, a jövőbeli bővítés megkönnyítése céljából. x−a A kliens paraméterei, a megfelelő eloszlással: x −a 1 − b −e − b Börsztök közti idő: determinisztikusan 40ms. f ( x) = e e b Csomagméret: a = 80, b = 5.7 E-mail esetében a csomagméretre Cauchy, míg a beérkezések közti időre Poisson eloszlást javaslunk λ = 10000 értékkel. A csomagméret paraméterei pedig: α = 0.8, β = 1. Peer-to-peer: Mobil p2p modellünk egyedülálló módon 3 különböző eloszlású tartományból épül fel. A három tartomány pontos kijelölését a küszöbértékek megadásával tehetjük, pillanatnyilag e küszöbértékeket 0.2 és 0.7 értékűre állítottuk. Az első tartományra a Weibull eloszlást ajánljuk λ = 1 és k = 2 paraméterekkel. A második tartomány modellezéséhez szintén Weibull eloszlást használtunk λ = 5.25 és k = 9.1 paraméterekkel. A harmadik tartományra exponenciális eloszlást használtunk λ = 0,05 paraméterrel.

– 41 –


3.4 BŐVÍTHETŐSÉG Ha szeretnénk felvenni újabb szolgáltatást, vagy esetleg egy meglévő szolgáltatáshoz kívánunk másik modellt megvalósítani, akkor könnyedén megtehetjük. Főleg azért is, mert a beolvasandó fájlunk rugalmas az új adatokra, és nem zavarja a működést, egy esetleges régebbi, vagy másik modell változóinak jelenléte. Új paraméter beállításakor, amikor a config fájlba felvesszük, mindössze a már megtárgyalt fájlformátum szintaktikájára kell ügyelnünk, és persze biztosítanunk kell a főprogramba való felvételét. Méghozzá 2 helyen kell ezt megvalósítanunk: először is globális változónak kell felvennünk, majd a fájlbeolvasó modulba kell egy újabb blokkot beilleszteni, melynek a szintaktikája: if (!strcmp(temp,"PARAMÉTERNÉV")) { fscanf (fp, "%f", &PARAMÉTERNÉV); }

A rendelkezésünkre álló eloszlásokat, és szolgáltatások eloszlásait még könnyebben bővíthetjük, hiszen csak egy-egy egyszerű függvényt kell beilleszteni, melyek megfelelő visszatérési értékkel rendelkeznek. A program nagy részében tizedes törtekkel dolgozunk, ezért ügyelnünk kell ennek a kezelésére is. Mivel sok esetben idő dimenzióban és file méretekkel számolunk, amik ritkán egész számok, ezért javasolt minden értéket float típusúra állítani. Ezek alól kivételt képeznek persze a mobszam, capacity, és MTU, melyek a hálózatra vonatkozó konkrét egész értékek.

– 42 –


4. EREDMÉNYEK Mivel az elkészült forrásmodellező (SOMOSI) pusztán egy .h függvénykönyvtár, amely a megadott interfésszel kapcsolódik az őt meghívó program felé, ezért a teszteléshez és az eredmények vizsgálatához készítettünk egy egyszerű programot (demo.cpp), amely elvégzi a szimulációt magát, a forrásmodellezőtől kapott adatok alapján. A program célja a forrásmodell (somosi.h) és egy már létező, a laborban korábban kifejlesztett mobilitási modell egyesítése, illetve a kapott eredmények kiértékelhető formátumú kimenetté alakítása. Azaz a programnak képesnek kell lennie arra, hogy a meglevő mobilitási modell által generált adatok alapján megállapítsa, hogy az adott, éppen csomagot generáló mobil kliens a síkbeli koordinátarendszerben hol tartózkodik, és hogy ez a pont mely cellához tartozik. Ezt rendkívül fontosnak látjuk, hiszen a szimulátorral szemben alapvető elvárásunk, hogy támogassa a későbbi bővítést is, tehát fontos a többcellás rendszer vizsgálatának lehetősége. A forrásmodell program eredményeinek vizsgálatához szükséges továbbá, hogy a kimenetet tudjuk szűrni aszerint, hogy melyik szolgáltatást vizsgáljuk. A program négy bemeneti fájllal dolgozik: • • • •

a mobilitási modell által kiadott mozgási információk, azaz hogy az egyes mobil kliensek az egyes lépésekben hol tartózkodnak (x,y koordinátapár). Ezt a mobilitas.dat nevű fájl tartalmazza. a már ismertetett forrásmodell konfigurációs fájl, hiszen néhány paraméterre szükségünk lesz a cellaszerkezetet leíró fájl (nodes.dat), amely tartalmazza az egyes cellák középpontjainak koordinátáit, illetve a cellák sugarát. a program saját konfigurációs fájlja (democonf.dat), amelyben beállíthatjuk a szimuláció időbeli tényezőit, illetve hogy mely szolgáltatásokra akarjuk szűrni a kimenetet

A program kimenete: A szöveges képernyő nem alkalmas az adatok megjelenítésére azok nagy száma miatt, ezért erre a célra kimeneti fájlokat alkalmaztunk. A kimeneti fájlok a következők: • az összes csomag időbélyeg szerint rendezett listája (lista.out). • aggregált adatok a teljes forgalomról (aggregalt.out) • aggregált adatok cellánként (vector.out)

– 43 –


Lássunk ezekre néhány példát! Egy tipikus lista.out fájl a következőképpen néz ki (17. ábra).

17. ábra: A lista.out kimeneti fájl felépítése

A fájl minden sora egy-egy IP csomag adatait (küldő kliens azonosítója, a cella azonosítója, a kliens síkbeli koordinátái, a csomag időbélyege, mérete, a szolgáltatás típusa, illetve a csomag típusa) tartalmazza. A csomagok időrendben szerepelnek a fájlban. Például: #0 client in cell #6 with coords:(969,995) sending packet: timestamp:1075.784313 size:300.000000 service:1 event:2

Az aggregalt.out fájl minden egyes cellára külön tartalmazza a teljes forgalmat, amely a megadott szimulációs lépésekben, a megadott szolgáltatások használata során keletkezett. Például: Cell #6, services monitored: Web Email VoIP Games VBR p2p 0.000000 - 100.000000 sec: 0 bytes 100.000000 - 200.000000 sec: 0 bytes 200.000000 - 300.000000 sec: 588600 bytes 300.000000 - 400.000000 sec: 478800 bytes 400.000000 - 500.000000 sec: 741900 bytes 500.000000 - 600.000000 sec: 176400 bytes 600.000000 - 700.000000 sec: 0 bytes 700.000000 - 800.000000 sec: 0 bytes 800.000000 - 900.000000 sec: 0 bytes 900.000000 - 1000.000000 sec: 0 bytes

A vector.out fájl pedig csak a numerikus adatokat tartalmazza, tabulátorral elválasztva (18. ábra). Az első oszlopban szerepelnek a szimulációs lépések sorszámai (nulladik, első, második, stb. lépés), a másodikban pedig az adott lépésben keletkezett forgalom. Ez a fájl rendkívül jól használható táblázatkezelők bemeneteként, és az adatsorokból néhány kattintással látványos és jól áttekinthető, a lényeget mégis jól demonstráló diagramok készíthetők.

– 44 –


18. ábra: A vector.out kimeneti fájl felépítése

– 45 –


4.1 A szimuláció menete A program először is beolvassa a bemeneti fájlokat, és eltárolja a szükséges adatokat a memóriába. Ezután folyamatosan hívja a somosi.h program futtat() metódusát, mindig kiolvasva ezzel az időrendben következő IP-csomag adatait a megfelelő struktúra formájában, majd feldolgozza ezeket. Az időbélyegből és a mobilitási modell adataiból megállapítja, hogy az adott csomag küldésekor a felhasználó mely (x,y) síkbeli koordinátákkal rendelkezett. Ezen koordináták és a cellaszerkezetet leíró bemeneti fájlból kiolvasott adatok alapján meghatározza, hogy az adott mobil kliens melyik cellában tartózkodott a csomag küldésekor. Majd, ha szükséges (figyelembe véve az időbeli- és szolgáltatási szűrőket), akkor hozzáadja a csomag méretét az aggregált forgalomhoz. A programban (a konfigurációs fájl segítségével) állíthatók a következő paraméterek: • • • • •

mikor kezdődjön a szimuláció hány szimulációs lépést végezzünk hány másodperc legyen egy szimulációs lépés mikor állítsuk le a szimulációt mely szolgáltatások csomagjait vegyük figyelembe

Ezzel gyakorlatilag lehetővé válik, hogy a folytonos időtengelyen kijelöljük a megfigyelendő szakaszt, és azt több, kisebb lépésre bontva vizsgáljuk.

4.2 Az eredmények vizsgálata, értékelés Több tesztet is futtattunk a forrásmodellek helyességének ellenőrzésére. Ezeket úgy állítottuk be, hogy egyetlen mobil felhasználó viselkedését vizsgálják, egy adott szolgáltatásra szűrve az adatokat. Ezzel lehetőségünk nyílt egy-egy forrásmodell helyességének ellenőrzése. Az E-mail forgalom vizsgálata (19. ábra) során előzetes várakozásunk az volt, hogy a felhasználó viszonylag ritkán, kisméretű fájlokat tölt le. Ez a várakozásunk teljesült is, a modellt megfelelőnek találjuk.

– 46 –


4500

4000

3500

Forgalom (byte)

3000

2500

2000

1500

1000

500

0 1

3

5

7

9

11

13

15

17

19

21

23

25

27

29

31

33

35

37

39

41

43

45

47

49

Idő (*10 sec)

19. ábra: E-mail forgalom

A VoIP forgalom esetén azt vártuk, hogy a beszélgetés időtartama alatt a váltakozó csend/beszéd állapotok miatt nem egyenletes a forgalom, azonban nagyobb szimulációs lépéseket választva (amelyekben ezek aránya közel azonos), egy adott érték körül oszcillál majd, nem túl nagy eltérésekkel. Ez a várakozásunk teljesült is, és alkalmunk nyílt megfigyelni azt is, hogy a cellaváltást is helyesen kezeli a rendszer (20. ábra). 30000

Aggregált forgalom (byte)

25000

20000

15000

10000

5000

0 1

2

3

4

5

6

7

8

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

idő (*10 sec)

20. ábra: VoIP forgalom

– 47 –


A peer-to-peer forgalom esetén azt vártuk, hogy hosszú távon mindhárom fájltípusból (kisméretű dokumentum, közepes méretű audio, nagyméretű video fájlok) tölt majd le a felhasználó, és ez a várakozásunk teljesült is (21. ábra).

8000000

7000000

6000000

Méret (byte)

5000000

4000000

3000000

2000000

1000000

0 1

3

5

7

9

11

13

15

17

19

21

23

25

27

29

31

33

Idő (*10 sec)

21. ábra: Peer-to-peer forgalom

– 48 –

35

37

39

41

43

45

47

49


A Web forgalom (22. ábra) is jól illik az általunk javasolt modellre. 200000 Aggregált forgalom (byte)

180000 160000 140000 120000 100000 80000 60000 40000 20000 0 1

4

7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 Idő (*10 sec)

22. ábra: Web forgalom

Hasonlóan jó eredményeket értünk el a másik két szolgáltatástípusnál (VBR, játékok) is. Vizsgáltuk a rendszert sok, eltérő felhasználói szokásokkal rendelkező felhasználó együttes jelenléte esetén is, hiszen ez lesz alkalmas a teljes hálózatok szimulációjára, illetve ez alapján méretezési döntések meghozására. A kimenetek a várakozásainknak megfelelőek voltak. A fentiekből jól látszik, hogy a forrásmodellek kimenetei jól illeszkednek a megadott modellekre, tehát jól megvalósítják azokat. Célunkat tehát elértük, az implementált forrásmodellek megfelelően működnek.

5. KITEKINTÉS A program elkészítése során ügyeltünk arra, hogy könnyen bővíthető, illetve átalakítható legyen, ha a jövőben új igények merülnek fel. A bemeneti paraméterek változtatásával a program modelljei felhasználhatóak akkor is, ha a felhasználói szokások változnak. A moduláris szerkezetnek köszönthetően új forrásmodellek beillesztése is könnyen megvalósítható. A program fejlesztési lehetőségei között szerepel új forrásmodellek felkutatása és implementálása, a már megvalósított forrásmodellek paramétereinek lehetőség szerinti pontosítása, illetőleg a különböző szolgáltatásokra jellemző, eltérő csomagméretek bevezetése. A SOMOSI program általános forrásmodellező, tehát a jövőben az ismertetett interfésszel bármilyen, ezt felhasználó szimulátorhoz képes kapcsolódni, és annak forgalmi adatokat szolgáltatni. – 49 –


6. FÜGGELÉK Lista 1.: A beolvasandó paraméterek Integer típusú: Float típusú:

mobszam, capacity, MTU; voip_beszed_exp_lambda, voip_csend_exp_mu, voip_aktiv_exp_lambda, voip_inaktiv_exp_lambda, web_exp_lambda, web_weibull_lambda,, web_weibull_k, web_lognormal_file_mu, web_lognormal_file_szigma, web_lognormal_gondolk_mu, web_lognormal_gondolk_szigma, web_lognormal_obj_mu, web_lognormal_obj_szigma, web_aktiv_exp_lamda, web_inaktiv_exp_lamda, email_cauchy_alfa, email_cauchy_beta, email_poisson_lambda, vbr_lognormal_i_mu, vbr_lognormal_i_szigma, vbr_lognormal_p_mu, vbr_lognormal_p_szigma, vbr_lognormal_b_mu, vbr_lognormal_b_szigma, vbr_aktiv_exp_lamda, vbr_inaktiv_exp_lamda, games_szerver_csomag_a, games_szerver_csomag_b, games_kliens_csomag_a, games_kliens_csomag_b, games_szerver_szunet_a, games_szerver_szunet_b, games_kliens_szunet , games_szerver_aktiv_exp_lambda, games_szerver_inaktiv_exp_lambda, games_kliens_aktiv_exp_lambda, games_kliens_inaktiv_exp_lambda, p2p_kuszob1, p2p_kuszob2, p2p_tartomany1_weibull_lambda, p2p_tartomany1_weibull_k, p2p_tartomany2_weibull_lambda, p2p_tartomany2_weibull_k, p2p_tartomany3_exp_lambda;

– 50 –


7. IRODALOM JEGYZÉK [1]

D. Staehle, K. Leibnitz, and P. Tran-Gia, Source Traffic Modeling of Wireless Applications Report No. 261 June 2000

[2]

Anagnostou, M., et. al. A Mulitservice User Descriptive Traffic Source Model, IEEE Transactions on Communications, vol 44, 10, October 1996

[3]

S. McCreary and KC Claffy, Trends in Wide Area IP Traffic Patterns, Tech. Rep., CAIDA, Feb. 2000.

[4]

Borella M.S., Source Models of Network Game Traffic, Networld + Interop’99 Engineer’s Conference, May 1999

[5]

J. Faerber, Network game traffic modelling, Proceedings of the 1st ACM workshop on Network and System Support for games, April 2002

[6]

T. Lang, G.J. Armitage, P. Branch, H. Choo, A Synthetic Traffic Model for Half-Life, Australian Telecommunications Networks & Applications Conference 2003, Melbourne (ATNAC 2003), Australia, December 2003

[7]

Mario T. Schlosser, Tyson E. Condie, and Sepandar D. Kamvar, Simulating a File-Sharing P2P Network, Department of Computer Science Stanford University, Stanford, CA 94305, USA

[8]

S. Saroiu, P. K. Gummadi, and S. D. Gribble, A measurement study of peer-topeer file sharing systems, In Proceedings of Multimedia Computing and Networking 2002 (MMCN ’02), San Jose, CA, USA, January 2002.

[9]

A. Crespo and H. Garcia-Molina, Semantic Overlay Network

[10] Kavitha Chandra, Amy R. Reibman, Modeling one- and two-layer variable bit rate video, IEEE/ACM Trans. Netw. 7(3): 398-413 (1999) [11] Marwan Krunz and Herman Hughes, A Traffic Model for MPEG-Coded VBR Streams [12] Vidács Attila, Hálózati szimulációs technikák, 2004 [13] D. D. Trang, B. Sonkoly, S. Molnár, Fractal Analysis and Modeling of VoIP Traffic, Budapest University of Technology and Economics, Hungary [14] Anne-Gaële Acx, Jukka Henriksson, Bernard Hunt, George T. Karetsos, Elias Tragos, Albena Mihovska, Sofoklis Kyriazakos, Lino Moretti, Juan Lara. IST2003-507581 WINNER D1.3 version 1.0 [15] A. Estepa, R. Estepa, and J. Vozmediano, A New Approach for VoIP Traffic Characterization, IEEE COMMUNICATIONS LETTERS, VOL. 8, NO. 10, OCTOBER 2004

– 51 –


[16] Ronza Skiot, Evalution of Voice over Internet Protokol Voip, Master thesis, Cape Town University, 2002 [17] Maurizio Molina, Paolo Castelli, and Gianluca Foddis, CSELT, Web Traffic Modeling Exploiting TCP Connections’ Temporal Clustering through HTMLREDUCE, 2000 [18] Allen B. Downey, Lognormal and Pareto Distributions in the Internet

8. ÁBRAJEGYZÉK 1.ábra: A forgalom megoszlása az egyes szolgáltatások között 2.ábra: Az e-mail méretek eloszlása 3.ábra: Egyszerű internetes forgalom felhasználói modellje 4.ábra: A bázis állomáson történő e-mail forgalom 5.ábra: A szerver illetve kliens oldal csomag és adatrátája 6. ábra: A szerver forgalmának illeszkedése a modellre 7.ábra: A kliensek forgalmának illeszkedése a modellre 8.ábra: Egy peer-to-peer hálózat 9.ábra: A Gnutella program esetén egy kérés útját szemlélteti 10.ábra: Bal oldali ábra a Gnutella peer-jai által megosztott fájlok számát szemlélteti. A jobb oldali ábra a Napster és a Gnutella peer-jei által megosztott fájlokat hasonlítja össze. 11.ábra: Cachelogic cég által mért P2P rendszerek 12.ábra: p2p forgalom alakulása saját modellünkben 13.ábra: Mobil P2P struktúra felépítése 14. ábra: Különböző típusú kereteket tartalmazó képcsoport 15.ábra: A VoIP forgalmának illeszkedése a modellre 16. ábra: A VoIP 2 állapotú Markov-lánca 17. ábra: A lista.out kimeneti fájl felépítése 18. ábra: A vector.out kimneti fájl felépítése – 52 –


19. ábra: E-mail forgalom 20. ábra: VoIP forgalom 21. ábra: Peer-to-peer forgalom 22. ábra: Web forgalom

9. TÁBLÁZATJEGYZÉK 1.táblázat: E-mail méretek mérési és modellbeli értékei 2. táblázat: A hálózati játék modellnél használt eloszlások paraméterei 3. táblázat: Internet peer-to-peer forgalmának tartalom szerinti eloszlása 4. táblázat: P2P fájlcserélőknél mért tartalmak méretének átlagértékei 5. táblázat: HTTP valamint P2P forgalom összehasonlítása 6. táblázat: I,P,B keretek paraméterei 7. táblázat: Különböző beszédmodell paraméterei 8. táblázat: Különböző protokollok tulajdonságai 9.táblázat: A modellt igazoló összehasonlítások 10. táblázat: A megfelelő eloszlások paraméterei 11. táblázat: A megfelelő eloszlások paraméterei

– 53 –

FORRÁSMODELLEZÉS MULTIMÉDIÁS MOBIL

Recommend Documents