CSOMAGKAPCSOLT FORGALOM SZÁMLÁZÁSA UMTS RENDSZERBEN

˝ B UDAPESTI M USZAKI

ÉS

G AZDASÁGTUDOMÁNYI E GYETEM

H ÍRADÁSTECHNIKAI TANSZÉK

C SOMAGKAPCSOLT FORGALOM SZÁMLÁZÁSA UMTS RENDSZERBEN

Ary Bálint Dávid Diplomamunka

2005. május 14.

Alulírott Ary Bálint Dávid, a Budapesti Muszaki ˝ és Gazdaságtudományi Egyetem hallgatója kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, és a diplomatervben csak a megadott forrásokat használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben de átfogalmazva más forrásból átvettem, egyértelmuen, ˝ a forrás megadásával megjelöltem.

Ary Bálint Dávid Budapest 2005. május 14.

Konzulenseimnek szeretném megköszönni, hogy felvállalták munkám irányítását. Tanáraimnak, diáktársaimnak és barátaimnak pedig köszönet a dolgozat átolvasásáért és konstruktív javaslataikért. Név szerint szeretnék köszönetet mondani dr. Imre Sándornak, Debrei Gábornak, Buzsáki Péternek, Soós Balázs Gergelynek és Kalmár-Nagy Andrásnak.

El˝ oszó Jelen dokumentum a Budapesti Muszaki ˝ és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai karának Muszaki ˝ Informatika szakán folytatott tanulmányaim lezárását jelent˝o, a diploma megszerzéséhez szükséges diplomamunka. A diplomamunkához kapcsolódó kutatásokat az egyetem Híradástechnikai tanszékén végeztem, konzulenseim dr. Imre Sándor, Butyka Zsolt és Jursonovics Tamás voltak. A kutatásokban többen vettünk ugyan részt, de a diplomamunka 3. fejezete teljes mértékben a saját eredményeimet mutatja be. Mivel a diplomamunka viszonylag komplex problémát ölel fel, a terjedelmi korlátok miatt az olvasóról telekommunikációs, de legalábbis mérnöki ismereteket tételezek fel. A harmadik generációs mobil hálózatokon keresztül elérhet˝o szolgáltatások alapvet˝oen csomagkapcsolt adatforgalomra alapozottak. Az újgenerációs hálózati koncepciónak megfelel˝oen az el˝ofizet˝o által igényelhet˝o szolgáltatásokat nem csak a hálózatoperátorok, hanem a szabványosított interfészek használatával küls˝o, harmadik felek is nyújthatják. Ezen új körülményeket figyelembe véve a jelenlegi számlázási rendszereket átalakítani, módosítani kell. A jelenleg is elérhet˝o GPRS szolgáltatás is hasonló módon, csomagkapcsolt alapon muködik, ˝ de e szolgáltatás mérése a legtöbb szolgáltatónál (legalábbis pre-paid esetben) nincs tökéletes módon megoldva. Küls˝o felek bevonása esetén azonban a pontos és igazságos számlázás megvalósítása elengedhetetlen követelmény. Jelen diplomamunka összefoglalja és bemutatja az UMTS rendszer szabványosításával foglalkozó 3GPP szervezet által kiadott, számlázással kapcsolatos szabványokat, az elérhet˝o és témával foglalkozó nemzetközi publikációkat, valamint a körvonalazódni látszó technológiai és jogi problémákat. A diplomamunka bemutatja továbbá az általam kidolgozott számlázó rendszer muködését, ˝ amely valós id˝oben, kis (az eddigi megoldásoknál kisebb) hálózati overhead-del képes pontosan számlázni a telekommunikációs hálózat el˝ofizet˝oi által igényelt szolgáltatásokat. A rendszer muködésének ˝ lényege, hogy a valós ideju ˝ (online) számlázást igényl˝o (prepaid, kártyás) felhasználókat a post-paid el˝ofizet˝okhöz hasonló módon számlázzuk, amennyiben az általuk felhasználható pénzösszeg az igényelt szolgáltatáshoz tartozó limit felett van. A számlázás módja a limit elérése után vagy a jelenlegi megoldás(ok)ra válthat át, vagy a hálózati elemek funkcióinak kisebb kiegészítésével 3

4 a hálózat kihasználtsága és a számlázás pontossága tovább növelhet˝o. A diplomamunkában bemutatott modell segítségével igazolom továbbá, hogy a kidolgozott rendszer muköd˝ ˝ oképes, és bizonyos szempontok szerint (hálózati overhead, valósidejuség) ˝ jobb, mint a jelenleg is használt megoldások. A dolgozat végén az általam elkészített szimulációs rendszert ismertetem, és futtatásával, futási eredményeivel támasztom alá a kidolgozott rendszert és az analitikusan kapott értékeket. A számlázó rendszer megalkotása során ügyeltem arra, hogy a rendszer illeszkedjen a vonatkozó szabványokhoz, így gyakorlati alkalmazása nem jelent jelent˝os technológiai nehézséget. A csomagkapcsolt forgalom el˝otérbe kerülése és a küls˝o felek megjelenése miatt célszeru ˝ a diplomamunkában bemutatott megoldást használni minden újgenerációs mobil távközl˝o hálózatban, hiszen jelent˝os többletbevételt eredményezhet a hálózatoperátoroknak, valamint a számlázás min˝oségét is javítja. A diplomamunka a következ˝oképpen épül fel: Az els˝o fejezet bemutatja az UMTS rendszert és az IMS alrendszert, valamint e rendszerek bevezetését motiváló tényez˝oket. Áttekinti a szabványosítás jelenlegi helyzetét és felvázolja a lehetséges üzleti modelleket. Végül mélyebb betekintést enged az UMTS rendszer architektúrális felépítésébe a számlázás szempontjából fontos entitásokra koncentrálva. A második fejezet a vonatkozó szabványosítási szervezetek munkája alapján bemutatja a harmadik generációs mobil telekommunikációs rendszerek számlázásának megvalósítását, a számlázási módokat és igényeket. A második fejezet ezen kívül összefoglalja azon technológiai problémákat is, amelyekbe egy valós ideju ˝ adatszámlázás kialakítása során ütközhetünk. A harmadik fejezet tartalmazza a kidolgozott számlázási modell leírását és annak analitikus vizsgálatát. A modell jóságának megállapításához felvázolunk néhány forgatókönyvet (scenario), és analitikusan megvizsgáljuk a számlázás során keletkez˝o számlázási overhead-et az egyes számlázási módokban. A harmadik fejezet végén bemutatjuk a modell validálásához használt szimulációs környezetet és értelmezzük az azzal kapott eredményeket. A negyedik fejezet összefoglalja a diplomamunka lényeges pontjait, valamint összegzi a modell és a szimuláció eredményeit. A dolgozatban felhasznált rövidítések és irodalmak, a dolgozatban szerepl˝o ábrák és táblázatok, valamint a diplomamunkához kapcsolódó publikációim listája a dokumentum végén található.

Abstract The countless services of the 3rd generation mobile networks are mainly based on packet based communication. With the fulfillment of the new-generation concept, the available services can be offered by the network provider itself, or with the use of the standardized interfaces, these services can be required from 3rd party providers as well. In light of these new circumstances, the billing systems that are currently in use should be modified, extended and revised to be able to keep up with the forthcoming changes. The GPRS services which are available nowadays more or less use the same packet based solution, but the measurement of this service (at least in case of pre-paid users) has not been solved completely by most of the network operators. However, with the presence of 3rd party providers, an accurate and fair charging mechanism is necessary. This thesis work summarizes the related standards of the 3GPP organization which is responsible for the standardization of the UMTS network, the available and related international publications, as well as the technical and legal difficulties. This document further more outlines my elaboration of a novel billing system which is capable of assuring real-time and accurate charging with a relatively low network overhead. The main idea of my solution is that pre-paid users are charged the same way as post-paid users, if their account is above a service specific limit. Whenever their accounts drop below this threshold, the regular, online charging method can be applied, or with a small functional extension of the network elements, the network utilization and the accuracy can be further more enhanced. With the model presented in this thesis work, I verify that the elaborated system operates properly, and in some aspects (network overhead, accuracy, real-timeness), it is better than the currently used solutions. At the end of this thesis work I introduce my simulation environment, and with the outcomes I validate my billing system and the analytic results. When I developed the billing system, an important point was that it must suit the related standards, and so, the adaptation of this model into the current systems should not cause any technical difficulties. With the growing significance of packet based data transmission and together with the appearance of 3rd party providers it is practical to use the method presented in this thesis work in every new-generation mobile telecommunication network, as it may cause considerable extra income for the network providers, and it improves the quality of the charging and accounting as well. 5

Tartalomjegyzék 1. Bevezet˝ o

8

1.1. A szabványosítási folyamat . . . . . . . . . . . . . . . . . . . . . . . . .

10

1.2. Az IP Multimédia alrendszer . . . . . . . . . . . . . . . . . . . . . . . .

11

1.3. Üzleti modellek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

1.3.1. Hálózatoperátor centrikus üzleti modell

. . . . . . . . . . . . .

15

1.3.2. Szolgáltatás aggregáló centrikus üzleti modell . . . . . . . . . .

15

1.3.3. Alkalmazásszolgáltató centrikus üzleti modell . . . . . . . . . .

16

1.3.4. Rejtett hálózatoperátor modell . . . . . . . . . . . . . . . . . . .

17

1.4. Az UMTS rendszer tagolása . . . . . . . . . . . . . . . . . . . . . . . . .

17

1.4.1. Az áramkörkapcsolt alrendszer architektúrája . . . . . . . . . .

19

1.4.2. A csomagkapcsolt alrendszer architektúrája . . . . . . . . . . .

21

1.4.3. Az IM alrendszer architektúrája . . . . . . . . . . . . . . . . . .

21

2. Számlázás UMTS környezetben

24

2.1. Definíciók . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

2.2. A szolgáltatás árának összetev˝oi . . . . . . . . . . . . . . . . . . . . . .

26

2.3. Számlázási információ . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

2.4. Számlázási módok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

2.5. Számlázási igények és elvárások . . . . . . . . . . . . . . . . . . . . . .

30

2.6. A számlázás menete . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

6

TARTALOMJEGYZÉK

7

2.6.1. Az offline számlázás menete . . . . . . . . . . . . . . . . . . . .

35

2.6.2. Az online számlázás menete . . . . . . . . . . . . . . . . . . . .

36

2.6.3. Az IMS alrendszer számlázása . . . . . . . . . . . . . . . . . . .

37

2.6.4. A szolgáltatás árának meghatározása . . . . . . . . . . . . . . .

38

2.7. A számlázás technológiai problémái . . . . . . . . . . . . . . . . . . . .

38

2.7.1. Az adat mérése . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

2.7.2. A min˝oség mérése . . . . . . . . . . . . . . . . . . . . . . . . . .

41

2.7.3. A mobilitásból adódó probléma

. . . . . . . . . . . . . . . . . .

42

2.7.4. A roaming problémája . . . . . . . . . . . . . . . . . . . . . . . .

42

2.7.5. Egyéb problémák . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

3. A kidolgozott modell

46

3.1. A modell muködése ˝ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

3.2. Analitikus megközelítés . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

3.2.1. A mode-switching limit meghatározása . . . . . . . . . . . . . .

50

3.2.2. Valós eset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

3.2.3. A QoS mérése . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

3.2.4. Hálózati overhead számítás . . . . . . . . . . . . . . . . . . . . .

52

3.3. Forgatókönyvek

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

3.3.1. Egyszeru ˝ videó streaming . . . . . . . . . . . . . . . . . . . . . .

53

3.3.2. Videó streaming esemény alapú szolgáltatásokkal kombinálva

57

3.3.3. Több folyam alapú szolgáltatás együttes igénylése . . . . . . .

58

3.3.4. Megszakított folyam alapú szolgáltatás . . . . . . . . . . . . . .

60

3.4. Szimulációs vizsgálat . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

3.4.1. Az objektumok muködése ˝ . . . . . . . . . . . . . . . . . . . . . .

66

3.4.2. A szimulációk kimenetei

. . . . . . . . . . . . . . . . . . . . . .

68

. . . . . . . . . . . . . . . . . . . . .

69

3.4.3. A szimulációk eredményei 4. Összefoglalás

73

1. fejezet

Bevezet˝ o A mobil telefónia, fejl˝odése során, a vezetékes telefóniát jellemz˝o áramkörkapcsolt rendszert˝ol a számítógépes hálózatokat jellemz˝o csomagkapcsolt rendszer felé halad. Az els˝o nagyobb áttörés még az ezredforduló el˝ott, a 2.5 generációt jelent˝o GPRS (General Packet Radio Services) megjelenése volt. A már meglév˝o GSM (Global System for Mobile Communications) hálózatot újabb, a csomag alapú kapcsolatokat kezelni képes elemekkel egészítették ki. A 2001-es évben megindult a harmadik generációs mobil hálózat, az UMTS (Universal Mobile Telecommunication System) koncessziója. A rendszer bevezetésének nagy lendületet adott ugyan a multinacionális telekommunikációs vállalatok hatalmas befektetése, megjelenése mégis csak napjainkban várható. A fejl˝odés – amely nem csak a gerinchálózati elemeket és a bázisállomásokat, hanem a végberendezéseket is érinti – hajtóereje az információs társadalom, mely egyre többet és többet költ információszerzésre. A mobil készülékek egyre korszerubbek ˝ lettek, és egyre több multimédiás szórakozást nyújtanak. Ha legtöbbször a technológiai fejl˝odést nem is a felhasználói igények siettették, az új lehet˝oségeket, új funkciókat egyre szélesebb körben használják. Az UMTS bevezetése a mobil készülékekkel elérhet˝o sávszélesség növekedésével, és az IP (Internet Protocol) alapú adatátvitel megjelenésével jár. A megnövekedett sávszélesség és a mobil IP elterjedésével telefonunk segítségével szinte minden olyan funkciót elérhetünk majd, amit otthoni számítógépünkön már megszoktunk. Megjelenik az IP alapú internetezés, a böngészés, a letöltés általánossá válik. A kommunikációban megjelenhet az amúgy is széles körben kutatott VoIP (Voice over IP) és a videókonferencia. Megjelenhetnek a különféle igény vezérelt (OnDemand) szolgáltatások, és az IPv6-al lehet˝oség lesz multicast üzenetek küldésére. Így lényegesen leegyszerusödik ˝ például a csoportos SMS (Short Message Service) küldése, vagy a Push-To-Talk szolgáltatás [76]. A 2004-es szabványokban megje-

8

˝ 1. FEJEZET. BEVEZETO

9

lent a hely alapú szolgáltatás (LBS – Location Based Services), így saját földrajzi helyzetünkt˝ol függ˝oen tudunk majd különböz˝o tartalmakat elérni. Szignifikáns változás következhet be az adat és a beszéd alapú szolgáltatások terén is. A jelenlegi rendszerrel ellentétben (mivel a felhasználó csak a ténylegesen igényelt adatmennyiségért kell fizessen és nem a kapcsolat id˝otartamáért), az adatkapcsolat állandó, folyamatos (Always On) lehet. Így a különböz˝o üzenetküld˝o (IM – Instant Messaging) szolgáltatások ára lényegesen lecsökkenhet. Mivel az IP címek mindig lokálisak, ezért értelmét veszti a távolság fogalma [27]. Elvileg ugyanazon árért hívhatunk bárkit, függetlenül az illet˝o távolságától és földrajzi helyzetét˝ol. Ennek megvalósulása lényegében két kritérium teljesíthet˝oségét˝ol függ. Az egyik kritérium, hogy a nagyobb távolság nagyobb terjedési késleltetést okoz, több csomóponton keresztül kell az adatcsomagoknak áthaladnia, és így az el˝oírt min˝oségi kritériumokat nehezebb teljesíteni. Másrészt a nagyobb távolságban lév˝o felhasználó valószínuleg ˝ más mobilhálózatot használ, így a szolgáltatás árát a másik, távoli hálózatnak fizetend˝o összeg is befolyásolja. Amennyiben nem kerül többe a min˝oségbiztosítás garantálása, és a hálózatok nem kérnek pénzt a kapcsolat létesítésére, amennyiben csak a hívott fél tartózkodik az o˝ hálózatukban, úgy a fizetend˝o összeg technikailag nem kerül többe, mint egy lokális, helyi hívás. Az UMTS-el elérhet˝o új funkciók és a hozzá kapcsolódó paradigmaváltás el˝osegíti egy helyfüggetlen, globális mobiltársadalom kialakulását. Az új körülményeket figyelembevéve az eddigi számlázási rendszerek szükségszeruen ˝ elavulnak, fejlesztésre szorulnak. Egyel˝ore a mobil készülékekkel elérhet˝o szolgáltatásokat zömében a mobil hálózat üzemeltet˝oje (Network Provider) nyújtja. A nyújtható funkciók és médiumok számának növekedésével azonban várható, hogy a hálózatok üzemeltet˝oinek nem lesz elegend˝o energiája és ideje, hogy újabb és újabb szolgáltatásokat találjanak ki és nyújtsanak, holott ezzel lényeges fölényre tehetnek szert a piaci versenyben. Így – az újgenerációs hálózati koncepciónak megfelel˝oen – a hálózati hozzáférés szolgáltatása és a tartalom szolgáltatása várhatóan szétválik. Ezt a tendenciát el˝osegíti az UMTS hálózat IMS (IP Multimedia Subsystem) alrendszere. A szabványos interface-ek, a hálózatüzemeltet˝o által megvalósítandó szolgáltatási képességek és a nagyfokú flexibilitást lehet˝ové tev˝o SIP (Session Initiation Protocol) alapú kapcsolatvezérlés segítségével az IMS kulcsfontosságú szerepet tölt be az alkalmazás és tartalomszolgáltatók megjelenésében. Az el˝oredefiniált, szabványos interface-ek segítségével könnyen és gyorsan fejleszthet˝oek szolgáltatások és alkalmazások a hálózathoz. Ennek köszönhet˝oen nagyszámú új és hasznos szolgáltatás alakulhat ki. Az eddig használt üzleti modell átalakul, és egy szolgáltatás nyújtása során több üzleti résztvev˝o fog szerepet vállalni. Mivel a küls˝o szolgáltatók gazdaságilag szeparálva vannak a hálózatoperátortól, a pontos és valós ideju ˝ számlázás elengedhetetlen.


10

Az UMTS rádiós átvitelt igényel, így a hálózatoperátoroknak fizetniük kell a frekvencia használatáért. Egy-egy frekvencia használatának megvétele, bérlése hatalmas, több milliárd forintos beruházást igényel. További költségeket jelent, hogy az UMTS a GSM-t˝ol eltér˝o modulációt használ, így a bázisállomásokat is fel kell újítani. Érthet˝o tehát, hogy a szolgáltatók szeretnének minél több bevételhez jutni, hogy beruházásaik megtérüljenek. A felhasználói szektor lényegében már fel van osztva, így újabb felhasználókat csak kedvez˝obb árak és újabb szolgáltatások bevezetésével lehet elcsábítani a többi szolgáltatótól. Az imént említett IMS alrendszer kulcsfontosságú szerepet játszik a harmadik felek megjelenésében, azonban ez az architektúra nem volt része a GSM rendszernek, így annak megvalósítása, bevezetése újabb beruházásokat igényel. Magyarországon az UMTS szolgáltatás nyújtására vonatkozó tendert 2004 végén hirdették ki, és 2005 elejére megválasztották azokat a cégeket, akik a frekvencia használatára és a telekommunikációs szolgáltatás nyújtására jogosultak. A négy tender (A, B, C és D) közül hármat a jelenlegi GSM szolgáltatók (T-Mobile Hungary, Pannon GSM, Vodafone Hungary) szereztek meg, a negyedik jogot egyel˝ore még nem értékesítették.

1.1. A szabványosítási folyamat Minden összetett, multinacionális rendszert, ahol az együttmuködés ˝ elengedhetetlen, szabványosítani kell. Az UMTS rendszer szabványosítását a 3GPP (3rd Generation Partnership Project) szervezet végzi [77]. A szabványosítási folyamat jelenleg is tart, a rendszerbe újabb és újabb funkciók kerülnek, a muködés ˝ pontosítása folyamatosan zajlik. A szabványosítási folyamat több mérföldk˝ore bontható, melyeket Release-eknek neveznek. A fejlesztés és a szabványosítás terén a kiindulópont a GSM/GPRS rendszer volt. A GSM egy áramkörkapcsolt technológiával rendelkez˝o mobil telekommunikációs hálózat, amelyhez a kés˝obbiekben egy csomagkapcsolt hálózatot illesztettek. A számlázás szempontjából a GSM rendszer nem jelentett különösebb kihívást, az egyes kapcsolatokat, szolgáltatásokat id˝o alapon számlázták, még akkor is, ha adatforgalomról volt szó (lásd CSD – Circuit Switched Data). A GPRS rendszer hozzáillesztésével a fejleszt˝ok és kutatók újabb kihívásokkal találták szemben magukat. A szolgáltatás mérését nem tudták centralizált módon megoldani, és a szolgáltatás nyújtásában résztvev˝o elemeknek információt kellett küldeniük a számlázó központba. Csomagkapcsolt esetben maga a szolgáltatás mérése is nehezebb feladat, hiszen az igényelt adatnak és nem a kapcsolat id˝otartamának megfelel˝oen kell elvégezni a számlázást. Mivel a GPRS nem bizonyult lényeges szolgáltatásnak – még manapság is viszonylag kevesen használják –, a pontos


11

számlázás jelenleg sem megoldott: a legtöbb szolgáltató átalánydíjas számlázást alkalmaz, vagy az átvitt, igényelt adatot nagyobb, kilobyte-os egységekben méri. A Release 3 új rádiós technológiát, modulációt vezetett be, amely jóval nagyobb átviteli sebességet biztosít, lehet˝ové téve ezáltal a multimédiás szolgáltatásokat: például a videó-konferencia, vagy a videó-streaming1 . A Release 4 az újgenerációs hálózati koncepciónak megfelel˝oen módosította a szabványokat, megjelent a programvezérelt kapcsolóközpont (SoftSwitch) az áramkörkapcsolt hálózatban. A Release 5 az IP alapú kommunikációra helyezte a hangsúlyt. A Release 6 már a teljesen forgalmat elosztottan, IP alapon képzeli el, és a különféle technológiák (2G, 3G, WLAN) integrálását is céljául tuzte ˝ ki, így beteljesülni látszik az All-IP koncepció megvalósulása2 [66].

1.2. Az IP Multimédia alrendszer Miközben az egy f˝ore es˝o telefonhasználat (MOU – Minutes Of Use) folyamatosan növekszik, a versenyhelyzet miatt az egy f˝ore es˝o, beszéd alapú szolgáltatásokból származó átlagjövedelem (ARPU – Average Revenue Per User) folyamatosan csökken. Azért, hogy bevételeiket növeljék, a hálózatszolgáltatók új lehet˝oségeket, új szolgáltatásokat kívánnak bevezetni [60]. Az IMS az UMTS rendszer opcionális része. A módosított moduláció, és az alap architektúra nagyobb átviteli sebességet, bárhol és bármikor elérhet˝o kommunikációt és személyre szabható szolgáltatásokat biztosít, s˝ot, fels˝obb rétegeket, protokollokat is bevonva a mobil végberendezések és a hálózatok közötti különbségek is eltüntethet˝oek. Az IMS lehet˝oséget ad ezen felül az IP alapú telekommunikációra és multimédiás kapcsolatok egyszeru, ˝ szabványos létrehozására is. Lényegében nem más, mint egy kapcsolatvezérlési réteg a csomagkapcsolt hálózat felett, amely SIP protokollt használ. A SIP segítségével létrehozhatunk, módosíthatunk és megszüntethetünk, akár több komponensu ˝ multimédia kapcsolatokat két vagy több szerepl˝o között. Így az IMS-el lehet˝oség van többek között • telefonálásra, • multimédia szolgáltatások kialakítására, • videókonferencia létrehozására, • interaktív játékokra, • tetsz˝oleges zene és videó lejátszására (streaming), 1a 2A

„streaming” szó a megfelel˝o magyar kifejezés hiányában angolul szerepel a dolgozatban diplomamunka 2. fejezete a Release 5, és a Release 6 jelenleg elérhet˝o dokumentumain alapul


12

• távoli felügyeletre és irányításra, • banki tranzakciók lebonyolítására (mobile banking), • helyfügg˝o szolgáltatások igénylésére, • stb. A nyújtható szolgáltatásoknak egyedül a végberendezés és az elérhet˝o min˝oség (QoS – Quality of Service) szab határt. A GSM/GPRS rendszerben adatforgalom lényegében csak a felhasználó és a mobil hálózat elemei között folyt, felhasználótól felhasználóig nem volt csomagkapcsolt adatforgalom. Az IMS bevezetésével megjelennek a felhasználók közötti valós ideju ˝ csomagkapcsolt szolgáltatások: például a VoIP, Push-To-Talk, vagy a file-csere. Az IMS architektúra vezetéknélküli, UMTS környezetben lett kifejlesztve, de gond nélkül alkalmazható vezetékes környezetben is, el˝osegítve ezzel a vezetékes és vezetéknélküli hálózatok konvergenciáját. Azért, hogy olyan szolgáltatások is implementálhatóak legyenek, amelyek jelenleg nem léteznek, egy flexibilis szolgáltatási keretrendszer szükséges. A szabványok IMS környezetben nem szolgáltatásokat, hanem a szolgáltatások kialakítását lehet˝ové tév˝o szolgáltatási képességeket (Service Capabilities) definiálnak. A nyílt szolgáltatási hozzáférés (OSA – Open Service Access) lehet˝ové teszi, hogy küls˝o alkalmazások férjenek hozzá a különböz˝o hálózati funkciókhoz. Az ezen alkalmazások által elérhet˝o funkciókat SCF-nek (Service Capability Features) nevezik, és az alkalmazás egy szabványosított OSA interface-en keresztül (API – Application Programming Interface) férhet hozzájuk, amely független az operációs rendszert˝ol, és a használt programozási nyelvt˝ol. A számlázáshoz tartozó SCF például lehet˝ové teszi, hogy az alkalmazások lekérdezzék, módosítsák az el˝ofizet˝ok számláját, levonják arról a szolgáltatás árát. A Parlay [78] egy jól dokumentált megvalósítása e nyílt interface-eknek. Az így definiált szolgáltatási képességek két nagy kategóriába sorolhatóak: alapvet˝o telekommunikációs szolgáltatások (Basic Telecommunication Services) és kiegészít˝o szolgáltatások (Supplementary Services). Az els˝o tovább bontható hordozó (Bearer) és telefon (Telephone) szolgáltatásra. A hordozó szolgáltatás az adatátvitelt valósítja meg, így támogatnia kell a valós és nem valós ideju ˝ hangot és beszédet, a file átvitelt és a multimédia alkalmazásokat és így az ezekhez tartozó forgalmi min˝oséget is. A telefon szolgáltatás az alapvet˝o mobil telekommunikációs szolgáltatásokat biztosítja: beszéd, vészhívás, rövid szöveges üzenet. A kiegészít˝o szolgáltatások az alapszolgáltatásokból felépíthet˝o extra szolgáltatások. Mivel tetsz˝oleges számú szolgáltatás elképzelhet˝o, fontos, hogy a felhasználók megtalálják a nekik szánt szolgáltatást, akár külföldön is. Ennek fényében célszeru ˝ egy automatikus szolgáltatás felderítést (Service Discovery) kifejleszteni. Ezzel a szabványos felülettel a küls˝o alkalmazásszolgáltatók szinte tetsz˝oleges alkalmazást, szolgáltatást implementálhatnak, beleértve az alapvet˝o telekommu-


13

nikációs szolgáltatásokat is, ezért a hálózatoperátoroknak nem feltétlenül szükséges e szolgáltatások biztosítása. Amennyiben egy küls˝o fél lehet˝ové teszi az el˝ofizet˝oknek a telefonálást, SMS küldést, és a jelenleg elérhet˝o funkciókat, a hálózatüzemeltet˝oknek elég csak az infrastruktúrát szolgáltatni, mindenféle egyéb szolgáltatás nélkül. A hálózatüzemeltet˝ok választhatnak, hogy továbbra is nyújtják az alapvet˝o telekommunikációs szolgáltatásokat, megpróbálnak lépest tartani a folyamatos és gyors szolgáltatásfejlesztéssel, vagy teljes egészében átalakulnak infrastruktúra szolgáltatóvá (IP Pipe Provider) [59]. A virtuális környezet (VHE – Virtual Home Environment) egy másik fontos hordozhatósági koncepciója a 3G mobil rendszereknek. Az IMS architektúrában használt VHE lehet˝oséget ad a felhasználónak, hogy itt tárolja fontosabb adatait, beállításait, paramétereit, és azokat használja tetsz˝oleges hálózatban és berendezéssel [9]. Összefoglalva az IMS egy olyan vezetékes és vezetéknélküli konvergenciát el˝osegít˝o architektúra, amely a nyújtható szolgáltatások széles skáláját támogatja a SIP által biztosított flexibilitással. A támogatott szolgáltatások körébe tartoznak a tradicionális telefon szolgáltatások és olyan egyéb szolgáltatások, mint az Instant Messaging, a Push-To-Talk, a videó letöltés, multimédiás üzenetküldés és sok más egyéb. Az architektúra számlázás szempontjából fontos elemeit az 1.4.3 fejezet mutatja be.

1.3. Üzleti modellek Egy új rendszer bevezetése során a pontos üzleti modell meghatározása szükségszeru. ˝ Egy többfajta szolgáltatásokat nyújtó telekommunikációs hálózatban több szerepkör létezik, és e szerepl˝ok között a szabványosított kommunikáció elengedhetetlen. UMTS környezetben a következ˝o fontosabb szerepköröket definiálhatjuk: Hálózatoperátor (Network Provider) A hálózatoperátor a mobil telekommunikációs hálózat infrastruktúráját szolgáltatja. Biztosítja a beszéd vagy adattranszportot a hálózat két felhasználója között. Mivel az UMTS szolgáltatók nagy valószínuséggel ˝ a korábbi GSM szolgáltatók közül kerülnek ki, már induláskor rendelkezésükre áll egy muköd˝ ˝ o számlázási és ügyfélnyilvántartó (CRM – Customer Relationship Management) rendszer. Ennek fényében várható, hogy a szolgáltatások számlázását továbbra is a hálózatoperátorok fogják végezni. Feladatuk közé tartozik a valós ideju ˝ számlázás, az ár és kredit kontroll, valamint szabványos interface-ek biztosítása a szolgáltatások nyújtásához és adminisztrálásához.


14

Alkalmazásszolgáltató (Service Provider) Az alkalmazásszolgáltató az UMTS hálózaton, rendszeren keresztül elérhet˝o szolgáltatásokat biztosítja. Felhasználja a hálózatoperátor által biztosított szabványos API-kat, és a tartalomszolgáltatótól kapott adatokat, tartalmat. Az alkalmazásszolgáltató olyan szolgáltatásokat nyújt, amelyek többlet értéket adnak a transzport szolgáltatásokhoz. Tartalomszolgáltató (Content Provider) A tartalmak el˝oállításáért felel˝os szerepl˝o. Olyan szolgáltatásnál lehet különálló szerepkör, ahol a tartalom és az alkalmazás könnyen elszeparálható egymástól – például hírek, id˝ojárás, zene, vagy cseng˝ohang. Szolgáltatás aggregáló A szolgáltatás aggregáló feladata, hogy több alkalmazásszolgáltató szolgáltatását egyesítse, és így egy egységes formában tegye hozzáférhet˝ové – például NetPincér [79]. El˝ ofizet˝ o (Subscriber) Felhasználó, aki a mobil hálózaton keresztül végberendezésével szolgáltatásokhoz és tartalmakhoz fér hozzá. A fent említett szerepkörök jól elkülönített szerepl˝oi az UMTS rendszernek, igaz a hálózati infrastruktúra-, alkalmazás- és tartalomszolgáltató szerepek összeolvadhatnak. Így el˝ofordulhat, hogy mindhárom szerepkört, vagy az infrastruktúra és alkalmazás, vagy az alkalmazás és tartalom szolgáltatás szerepkörét ugyanaz a szerepl˝o tölti be. Az infrastruktúra és a tartalom szolgáltatásának összeolvadása az alkalmazásszolgáltató szerepkör nélkül valószínutlen. ˝ A felhasználó szinte bármelyik szerepl˝ovel kapcsolatban állhat, és egy szolgáltatás igénylése esetén – annak ellenére, hogy a szolgáltatásban az összes szerepl˝o részt vett – csak egy szerepl˝onek szeretné téríteni a szolgáltatás árát. Ez a kiemelt szerepl˝o ezek után elrendezi a többi szolgáltató felé a tartozást. Látható, hogy valószínuleg ˝ nem lesz egy általános, mindenhol, mindenkor alkalmazható üzleti modell, és a piaci el˝ony megszerzése csak nagyfokú flexibilitással érthet˝o el [28]. A szerepl˝oknek rugalmasan kell alkalmazkodniuk az egyes szolgáltatásokhoz, felhasználói csoportokhoz, szokásokhoz, és folyamatosan alakítaniuk, változtatniuk kell az üzleti modellen. Mivel – feltételezésünk szerint – az egyes szolgáltatásokat, illetve tartalmakat egy harmadik fél is nyújthatja, a technológiai nehézségek mellett meg kell birkózni a jogi problémákkal, mivel egymás azonosítása, az el˝ofizet˝ok egyes adatainak kiszolgáltatása, valamint a nyújtott funkciók szolgáltatása ezt megkívánja. Természetesen a felhasználó által fizetett pénzt szét kell osztani a tartalom-, alkalmazásés a hálózatszolgáltató között, így ennek pontos meghatározását is szerz˝odésben kell lerögzíteni. A felhasználó azonban csak egyszer, egy helyen szeretne fizetni (One-Stop-Shopping koncepció), ezért a szolgáltatóknak valamilyen kapcsolatot kell fenntartaniuk, majd rendszeres id˝oközönként (azonosítás után) el kell számolniuk egymással. Egymás számlázása viszonylag könnyen megoldható, de a helyes


15

1.1. ábra. Hálózatoperátor centrikus üzleti modell és igazságos szolgáltatásnyújtáshoz az összes szolgáltatónak tisztában kell lennie a felhasználó pénzügyi helyzetével, hogy megfelel˝o esetben meg tudja tagadni a szolgáltatás, tartalom elérését. A pontos számla kiszolgáltatása azonban az el˝ofizet˝o személyiségi jogai miatt nem lehetséges. Amennyiben egy szolgáltatásnál jelen van egy küls˝o fél is, a szolgáltatás számlázását végezheti a hálózat szolgáltatója vagy a harmadik fél is. Ez alapján a számlázást tekintve több különböz˝o üzleti modellt különböztethetünk meg [30]. A következ˝o alfejezetben felsorolt modellek egyenként is érvényesülhetnek, de tetsz˝oleges kombinációban is el˝ofordulhatnak a küls˝o szolgáltatók és a felhasználói igények függvényében.

1.3.1. Hálózatoperátor centrikus üzleti modell A hálózatoperátor központú üzleti modellben (1.1 ábra) a felhasználó a hálózati operátorral van direkt kapcsolatban. A szolgáltatások árának meghatározását, a kifizetések kezelését és a szolgáltatások meghirdetését is o˝ végzi. A tartalmak vagy a küls˝o szolgáltatóktól egy átjárón keresztül jutnak a mobil hálózatba, vagy maga a hálózatoperátor készíti o˝ ket. Természetesen a hálózati operátor a küls˝o tartalmakért nem, az adott min˝oségért pedig csak a mobil hálózaton belül tud felel˝osséget vállalni. Ez a modell igazodik a legjobban a felhasználói igényekhez, és jelenti a legkisebb problémát az el˝ofizet˝oknek. Ha a tartalmat küls˝o felek biztosítják, a hálózatoperátornak tudnia kell, hogy hogyan, milyen módon végezze a szolgáltatások számlázását.

1.3.2.

Szolgáltatás aggregáló centrikus üzleti modell

A szolgáltatás aggregáló központú üzleti modell (1.2 ábra) esetén a szolgáltatások egy portálon keresztül érhet˝oek el, így a felhasználónak elegend˝o a portál címé-


16

1.2. ábra. Szolgáltatás aggregáló centrikus üzleti modell nek ismerete a szolgáltatások igényléséhez. A kapcsolatot a hálózatoperátorral a portál tulajdonosok – a szolgáltatás aggregálók, és nem az alkalmazás / tartalomszolgáltatók – tartják. A megoldás során a hálózatoperátoroknak kevesebb szolgáltatóval kell megegyezniük, így a felesleges adminisztratív terhekt˝ol is megszabadulnak, ráadásul a megalkotott üzleti modell modulárisabb és könnyebben kezelhet˝o lesz. A modellben a felhasználó els˝osorban a szolgáltatás aggregálóval van kapcsolatban, de fenntarthatja kapcsolatát a hálózatoperátorral is. A tartalmak, szolgáltatások árának meghatározását a portál tulajdonosa végzi és kezeli, viszont a kapcsolat megteremtéséért a felhasználó a hálózatoperátornak fizet. A szolgáltatás aggregálók beszámíthatják a szolgáltatás árába a hozzáférési díjat, így megoldható, hogy a felhasználóknak csak a szolgáltatásért kelljen fizetniük.

1.3.3. Alkalmazásszolgáltató centrikus üzleti modell Az alkalmazásszolgáltató központú üzleti modell (1.3 ábra) hasonló a szolgáltatás aggregáló centrikus üzleti modellhez, de a tartalom aggregáló szerepét a tartalomszolgáltató veszi át. Ez a megoldás els˝osorban egyedi szolgáltatással rendelkez˝o cégek esetén fordulhat el˝o, aki hozzáigazítják szolgáltatásaikat a mobil környezethez. Mivel ebben a modellben nincs szolgáltatás aggregáló szerep, a hálózatoperátornak minden céggel külön kell megegyeznie, így elveszik az el˝oz˝o modellnél bemutatott el˝ony. A megoldás f˝o hátrányai, hogy a tartalomszolgáltatóknak maguknak kell megoldaniuk a számlázás problémáját (amely adott esetben többe kerülhet, mint maga a szolgáltatás), valamint, hogy a felhasználónak minden egyes tartalomszolgáltatóval külön kell elrendeznie a számlát. Ez a megoldás sok tartalomszolgáltató esetén problémát jelenthet. Így ez a modell nyújtja a legnagyobb szabadságot a szolgáltatások körében, de a legnagyobb adminisztratív overhead-et is.


17

1.3. ábra. Alkalmazásszolgáltató centrikus üzleti modell

1.4. ábra. Rejtett hálózatoperátor modell

1.3.4.

Rejtett hálózatoperátor modell

Az 1.4 ábra a rejtett hálózatoperátor modellt szemlélteti. A modell lényege, hogy a felhasználó csak az alkalmazás-, vagy tartalomszolgáltatóval van kapcsolatban. A megoldás akkor alkalmazható, ha az alkalmazás-, vagy tartalomszolgáltatónak igen er˝os felhasználói bázisa, és márkája van. A modellben a küls˝o szolgáltató biztosítja a végkészüléket a felhasználónak, és a hálózatoperátor a küls˝o szolgáltatót terheli a hozzáférés költségéért. A felhasználónak akár nem is kell tudnia a hálózatoperátor személyér˝ol, és csak a küls˝o szolgáltató által meghatározott szolgáltatásokat tudja igénybevenni.

1.4.

Az UMTS rendszer tagolása

Egy telekommunikációs hálózat alapvet˝oen két f˝o részre bontható. A hálózat egyik részét képezik az el˝ofizet˝ok, felhasználók tulajdonában lév˝o végkészülékek (User


18

1.5. ábra. Az UMTS architektúra tagolása Equipment, Mobile Station), másik részét pedig a telekommunikációs szolgáltatásokat lehet˝ové tev˝o infrastruktúra. UMTS környezetben az el˝obbit User Equipment domain-nek, az utóbbit Infrastructure domain-nek nevezik. A User Equipment domain a végberendezésen kívül tartalmazza a USIM domain-t, amely lényegében a SIM (Subscriber Identity Module) kártya. Ez a kártya egyrészr˝ol tartalmazza a felhasználó adatait és lényeges információit, másrészr˝ol a hálózatoperátor beállításait, és esetleges programjait – például extra menüpont a telefon menüjében. Az Infrastructure domain funkcionálisan hozzáfér˝oi hálózat (AN – Access Network) és maghálózat (CN – Core Network) részekre tagolható. Az AN feladata, hogy a megfelel˝o moduláció és átviteli technika segítségével a mobil végberendezés és a CN közötti rádiós kapcsolatot megteremtse. A CN nyújtja az igénybe vehet˝o szolgáltatásokat. Ezen belül helyezkedik el a Serving Network domain (SND) a Home Network domain (HND) és a Transit Network domain (TND). A SND a CN funkcióit reprezentálja, feladata többek között a hívásirányítás (call routing) és az adattovábbítás. Az otthoni, honos hálózat (HND) a felhasználó helyt˝ol független adatait tárolja, és ez a domain végzi el az olyan szükséges adminisztratív tevékenységeket, mint az autentikáció, vagy a számlázás. A TND a SND-ek közötti adatátvitelt valósítja meg. A logikai részeket, domain-eket, valamint azok kapcsolatát az 1.5 ábra mutatja. A CN más felosztásban tovább bontható áramkörkapcsolt (CS – Circuit Switched), csomagkapcsolt (PS – Packet Switched) és IP Multimédia (IM) alrendszerre. A CS alrendszer továbbra is az áramkörkapcsolt szolgáltatásokhoz tartozó kapcsolatokért felel˝os, mivel azonban az UMTS rendszerben mindenfajta kommunikáció IP alapon van elképzelve, e rétegnek egyre kisebb szerep jut a jöv˝o kommunikációs hálózatában. A PS alrendszer a csomag alapú kapcsolatokért felel˝os, erre az alrendszerre épül az IM alrendszer (IMS), amely az IP alapú multimédia és telefon szolgáltatásokért felel˝os [65]. Ugyancsak az IMS felel˝os a szabványos, nyílt interface-ekért, melyeken keresztül küls˝o szolgáltatók kapcsolódhatnak a mobil


19

1.6. ábra. Az áramkörkapcsolt alrendszer architektúrája hálózathoz. A következ˝o alfejezetek az Infrastructure domain számlázás szempontjából fontos elemeit szemléltetik a különböz˝o alrendszerekben. Az egyes muködési ˝ módok leírása, az elemek pontos feladata a 2.6 fejezetben található.

1.4.1. Az áramkörkapcsolt alrendszer architektúrája Az 1.6 ábra az áramkörkapcsolt (CS) alrendszer architektúráját szemlélteti. A rendszer fontosabb elemeit és azok funkciót a következ˝o felsorolás tartalmazza. Mobile Station A felhasználó, el˝ofizet˝o végberendezése. A felhasználó ezzel a készülékkel igényli, küldi és fogadja a hálózat felöl / felé az adatokat. A végberendezés képességei befolyásolják, leszukítik ˝ a hálózat által nyújtható szolgáltatások körét. A készülék általában az el˝ofizet˝o birtokában van. Base Station A vezetékes maghálózat (Core Network) és a rádiós kapcsolattal rendelkez˝o felhasználói végberendezés (Mobile Station) közötti kapcsolatot teremti meg. Az elem a hálózatoperátor birtokában lév˝o Infrastructure domain része.


20

MSC (Mobile Switching Centre) A mobil kapcsolóközpont a CS alhálózat legfontosabb eleme. Feladata többek között a hívásirányítás és az útvonalválasztás. Lényegében ez az elem teremt kapcsolatot a hálózat két távoli berendezése között. GMSC (Gateway Mobile Switching Centre) Egy olyan speciális MSC, amely más mobilhálózatokkal (PLMN), vagy vezetékes telefonhálózatokkal (PSTN) teremt kapcsolatot. Lényegében egy átjáró (gateway) szerepét tölti be, és jelzéskonverziót valósít meg a különböz˝o technológiák között. PLMN (Public Land Mobile Network) Más hálózatoperátor birtokában lév˝o mobil telekommunikációs hálózat. PSTN (Public Switched Telephone Network) Általában más hálózatoperátor birtokában lév˝o vezetékes telekommunikációs hálózat. BS (Billing System) A mobil hálózat számlázóközpontja. Ez az egység kezeli az el˝ofizet˝ok számláját, és a pénzügyi tranzakciókat a felhasználók, küls˝o szolgáltatók és más infrastruktúra szolgáltatók között. OCS (Online Charging System) A valós ideju ˝ (online) számlázás megvalósításáért felel˝os logikai entitás. CTF (Charging Trigger Function) A hozzá kapcsolódó hálózati elem bizonyos eseményeire (lásd 2.3 fejezet) számlázási információk küldését indítja el (trigger-eli). Valós ideju ˝ számlázás esetén az OCF-el tartja a kapcsolatot, és kezeli a szolgáltatásokhoz tartozó ideiglenes számlát. CDF (Charging Detail Function) A számlázási esemény hatására szabványos formába összeállítja és továbbküldi a szolgáltatáshoz tartozó számlázási információt. CGF (Charging Gateway Function) A CDF-t˝ol kapott számlázási információkat összegyujti, ˝ ideiglenes tárolja (buffereli), átalakítja, preprocesszálja, majd továbbküldi a számlázó központnak. OCF (Online Charging Function) Az OCS funkcióját megvalósító logikai entitás. A felhasználó számlájának, és az igényelt szolgáltatás paramétereinek függvényében megfelel˝o mennyiségu ˝ pénzösszeget foglal le a szolgáltatást nyújtó hálózati elem részére. A hálózati elemhez tartozó CTF-el kommunikál. ABMF (Account Balance Management Function) A felhasználó számláját menedzseli az OCS-en belül. RF (Rating Function) Az egyes szolgáltatások árát meghatározó funkció.


21

1.7. ábra. A csomagkapcsolt alrendszer architektúrája

1.4.2.

A csomagkapcsolt alrendszer architektúrája

Az 1.7 ábra a csomagkapcsolt (PS) alrendszer architektúráját szemlélteti. Az alrendszer legtöbb eleme megegyezik az 1.4.1 fejezetben bemutatott architektúra elemeivel. Az eltér˝o elemeket és azok funkciót a következ˝o felsorolás tartalmazza. SGSN (Serving GPRS Support Node) A csomagkapcsolt adat továbbítását kezelni képes hálózati elem. F˝obb funkciói közé tartozik az útvonalválasztás és a csomagtovábbítás, így leginkább egy router funkcióit valósítja meg. GGSN (Gateway GPRS Support Node) Olyan hálózati elem, amely a küls˝o, publikus Internet, és a csomagkapcsolt mobilhálózat közötti kapcsolatot teremti meg.

1.4.3. Az IM alrendszer architektúrája Az 1.8 ábra az IM alrendszer architektúráját szemlélteti. Az alrendszer a csomagkapcsolt alrendszer felett elhelyezked˝o kapcsolatvezérlési réteg, így felhasználja a


22

1.8. ábra. Az IM alrendszer architektúrája PS alrendszer által nyújtott hordozószolgálatot. A csomagkapcsolt illetve áramkörkapcsolt architektúrában nem szerepl˝o elemek leírását a következ˝o felsorolás tartalmazza. CSCF (Call Session Control Function) Az elem a kapcsolatokhoz tartozó végpontok regisztrációját végzi, valamint megoldja a SIP jelzési üzenetek útvonalirányítási feladatát, a megfelel˝o alkalmazásszerver kiválasztását. AS (Application Server) A végfelhasználóknak nyújtott szolgáltatások kialakítását lehet˝ové tev˝o elem. Az AS által biztosított szabványos keretrendszer segítségével könnyen és gyorsan fejleszthet˝oek különböz˝o, más technológiával is együttmuködni ˝ képes alkalmazások és szolgáltatások. MRFC (Media Resource Function Controller) A különböz˝o médiát szolgáltató média szerverekhez kapcsolódva segíti az er˝oforrások vezérlését, hatékony kihasználását és elosztását. MGCF (Media Gateway Control Function) A SIP jelzésekkel és a média gatewayek által használt jelzési protokollokkal együttmuködve ˝ kezeli a média átjárók


23

kiépített kapcsolatait. A reguláris telefonhálózat és a SIP kapcsolatok között valósít meg jelzéskonverziót. BGCF (Breakout Gateway Control Function) A küls˝o hálózatok (PSTN/PLMN) kiválasztását, és a hozzájuk tartozó IP kapcsolatok er˝oforrás-lefoglalását végzi. IMS GWF (IMS Gateway Function) Az OCS által kiadott vezérl˝oüzeneteket konvertálja a SIP alkalmazásszerverek által megérthet˝o vezérl˝oüzenetekké. CCF (Charging Collection Function) IMS környezetben a CGF funkcionalitását látja el.

2. fejezet

Számlázás UMTS környezetben Mint már említettük az UMTS rendszer bevezetése hatalmas beruházási költségekkel jár. A beruházók természetesen szeretnék befektetett pénzüket viszontlátni, ehhez azonban új szolgáltatások, új favorit applikációk (Killer Application) kellenek. A jelenlegi GSM rendszerben a bevételek 90%-át a hang alapú szolgáltatások [27], a fennmaradó rész nagy hányadát pedig az SMS adja. Az UMTS rendszeren valószínuleg ˝ nem lesz meghatározott favorit applikáció, sokkal inkább valószínusíthet˝ ˝ o, hogy a jelenleg is meglév˝o szolgáltatások lesznek jobban használhatóak, népszerubbek ˝ az új környezetnek, multimédiás támogatásnak, és az LBS-nek köszönhet˝oen [27]. A szolgáltatások nyújtása mellett természetesen gondolni kell a szolgáltatás számlázására is. A szolgáltatás ellenértéke bevételt biztosít a szolgáltatónak, és egyfajta forgalmi korlátozásra (Traffic Shaping) is alkalmas. Egy számlázó rendszer installálása és fenntartása azonban hatalmas beruházási (CAPEX - CAPital EXpanditure) és fenntartási (OPEX – OPeration EXpenses) költséget jelent. Ez olyannyira igaz, hogy az ingyenes ISP-k (Internet Service Provider) azért engedhetik meg maguknak, hogy térítésmentesen szolgáltassanak Internet hozzáférést, mert számlázórendszer hiányában a fenntartási költségük elenyész˝o – bevételük a telefonhálózat szolgáltató Internet-csatlakozás utáni bevételének meghatározott százaléka [47]. Egy másik igen fontos, és az eddigieknek viszonylag ellentmondó kritérium az egyszeruség. ˝ A felhasználók körülbelül 73%-a részesíti el˝onyben az átalánydíjas (Flat Rate) számlázást, és a szignifikáns üzleti résztvev˝ok körülbelül fele gondolja úgy, hogy 2010-re a használat alapú (csomag, perc) számlázást mindenhol felváltja az átalánydíjas számlázás [26]. Ennek el˝onye (a felhasználói elégedettség 24

2. FEJEZET. SZÁMLÁZÁS UMTS KÖRNYEZETBEN

25

mellett), hogy jóval könnyebb és áttekinthet˝obb a szolgáltatások számlázása. Az el˝ore vásárolt (pre-paid) kártyás rendszer azonban nem összeegyeztethet˝o ezzel a koncepcióval, így ott továbbra is csak a használat alapú számlázás marad megvalósítható. Mindemellett pre-paid esetben is van lehet˝oség közelíteni a felhasználói elvárásokat, ha a szolgáltatásokat a tartalom, és nem a felhasznált er˝oforrás függvényében számlázzuk. Sokkal érthet˝obb a felhasználók számára, ha például a cseng˝ohangokat, videókat, képeket darabszámra vásárolják, és nem azok mérete, a letöltött byte-ok száma után kell fizetniük [28].

2.1. Definíciók A telekommunikációs és az Internet világban a számlázással kapcsolatos definíciók eltérnek. A különbség abból adódik, hogy az IETF (Internet Engineering Task Force) inkább a protokollokra, még a 3GPP sokkal inkább a hálózati elemek pontos specifikációjára koncentrál. A helyzetet nehezíti, hogy a számlázás során használt definícióknak (charging, accounting, billing) nincsen pontos magyar megfelel˝oje. A telekommunikációs világ értelmezését figyelembe véve a charging díjazásnak, a billing számlázásnak, az accounting pedig levonásnak fordítható. A következ˝okben felsoroljuk a számlázással kapcsolatos fontosabb definíciókat, és a két szervezet által adott értelmezésüket. Charging (3GPP) Azon funkciók összessége, melyek a számlázható eseményhez tartozó információkat összegyujtik, ˝ megformázzák és továbbítják azért, hogy a szolgáltatások használata megállapítható, és a felhasználó számára kiszámlázható legyen. Billing (3GPP) Azon funkciók összessége, melyek az el˝ofizet˝ok részére a számlázási információkból fizetési kötelezettséget jelent˝o számlát készítenek. Accounting (3GPP) Az a procedúra, amely szétosztja a költségeket és bevételeket az üzleti modell szerepl˝oi között. Charging (IETF) Azon funkció, amely meghatározza a nem pénz alapú (Non-Monetary Unit) árat a számlázáshoz a szolgáltatás és felhasználó specifikus tarifákból. Billing (IETF) Az a funkció, amely a díjazás (charging) által meghatározott összegb˝ol valós árat, pénzt (Monetary Unit) határoz meg, és a felhasználó számára egy végleges számlát állít össze. Accounting (IETF) Az a funkció, amely az er˝oforrás-felhasználásokhoz tartozó számlázási adatok kezelését, összegyujtését, ˝ tárolását és továbbítását valósítja meg.


26

Látható, hogy különbségek ugyan vannak, de az IETF által definiált levonás (accounting) megfeleltethet˝o a telekommunikációs világ által definiált díjazásnak (charging). Ugyancsak az IETF díjazása és számlázása (charging, billing) megfeleltethet˝o a 3GPP számlázási definíciójának. A telekommunikációs ipar által használt levonásnak (accounting) nincs megfelel˝oje, mivel e funkció megvalósítása kimutat az IETF szabványosítási tevékenységéb˝ol [44].

2.2. A szolgáltatás árának összetev˝ oi Mivel egy komplexebb szolgáltatás nyújtásában szerepl˝ok egész lánca vehet részt, a szolgáltatás ára több összetev˝ob˝ol áll, melyeket az egyes szerepl˝oknek kell fizetni. A szolgáltatás árának meghatározása leginkább közgazdasági kérdés, és így els˝osorban a felhasználói igények határozzák meg. Az ár kialakítása során azonban két markáns összetev˝ovel mindenképpen számolni kell. Amennyiben a szolgáltatás ára nem emelhet˝o e két összetev˝o ára fölé, úgy a szolgáltatás veszteséges lesz. Az els˝o ilyen összetev˝o a felhasznált tartalom (content) ára, amelyet a szerz˝oi jogok és igények, és nem a technológia határoz meg. A második összetev˝o a transzport szolgáltatás ára, amely a következ˝o összetev˝okb˝ol áll: • fix összeg, amely a hálózati infrastruktúra szolgáltatásából ered, • a hálózathoz való csatlakoztatás ára, • a hálózat növelésének költsége, • egy IP csomag küldésének az ára, • a QoS biztosításának az ára. A több szerepl˝o miatt a számlázás során szét kell tudni választani a tartalom, a szolgáltatás és a transzport szolgáltatás árait, hogy minden szerepl˝o számára igazságos számlázást biztosítsuk, és minden üzleti fél megkapja a neki járó összeget.

2.3. Számlázási információ Egy elosztott, csomagkapcsolt rendszerben a szolgáltatások számlázását csak úgy lehet megoldani, ha a szolgáltatás nyújtásában résztvev˝o elemek (felhasználó, SND, harmadik fél) információkat küldenek a számlázást végz˝o elemnek. E számlázási információkat a mobil telekommunikációs rendszerekben CDR-eknek nevezik. A GSM rendszerben, és a korai UMTS specifikációkban a CDR a Call Detail


27

Record (részletes hívás információ) rövidítése volt, még az újabb szabványokban ehhez a rövidítéshez a Charging Data Record (számlázási információ) feloldás tartozik. A CDR-ek valójában attribútum-érték párok (AVP – Attribute Value Pair) halmaza, amelyek minden lényeges információt tartalmaznak a felhasznált er˝oforrásokról és szolgáltatásokról. A CDR-ek tehát tartalmazzák az adat szemantikájára utaló attribútumokat és a hozzájuk tartozó értékeket. A CDR-ek pontos specifikációja – a felhasználható attribútumok listája – megtalálható a [13], [14], [15] és [16] irodalmakban. Amennyiben e számlázási információk egy küls˝o félt˝ol származnak, úgy meg kell oldani az információk validálását és integritás ellen˝orzését. A flexibilitás érdekében célszeru ˝ az egyes szolgáltatási rétegekhez (tartalom, vezetékes infrastruktúra, rádiós hálózat) külön CDR-eket generálni. Egy országos méretu, ˝ több millió felhasználót tartalmazó hálózatban a számlázási információk feldolgozása hatalmas számítási kapacitást igényel. Ha egy telekommunikációs hálózat 350 millió CDR-t produkál naponta, és egy számlázási információ feldolgozása 1 ms, akkor az egy napi mennyiség feldolgozása több mint 4 napig tartana, amely a legjobb indulattal sem nevezhet˝o valós ideju ˝ muködésnek ˝ [49]. Ráadásul rengeteg olyan hibalehet˝oség adódik (hibás CDR, hiányzó értékek, nem validált forrás) feldolgozás közben, amelyeket rövid id˝o alatt kell tudni kezelni. Mivel a CDR-ek minden információt tartalmaznak a szolgáltatás igénylésér˝ol, felhasználási körük túlmutat a számlázáson. Ennek fényében a CDR-ekben tárolt adatok segítségével lehet˝oség van: • el˝ofizet˝ok számlázására a hálózat és szolgáltatások használatáért, • a fix hálózaton történ˝o adatok és szolgáltatások számlázására a hálózatok üzemeltet˝oi között, • a szolgáltatás-kihasználás analizálására, • igénybe vett szolgáltatások dokumentálására, esetleges reklamációk esetére, • adatbányászati módszerek segítségével különböz˝o összefüggések keresésére, • felhasználói viselkedések analizálására, viselkedési módok meghatározására (subscriber usage patterns), • csalások, visszaélések felderítésére. A CDR-eket a hálózati elemek els˝osorban a szolgáltatás végén küldik, azonban hosszabb szolgáltatás igénylés esetén nagy mennyiségu ˝ érték halmozódhat fel, így egyetlen számlázási információ túl nagy értéket képviselne ahhoz, hogy egy egyszeru ˝ hálózati hiba miatt elveszhessen. Ráadásul az Always On koncepció miatt a szolgáltatás vége fogalom is értelmét veszti. Az ilyen szolgáltatások (Long Calls) számlázásához találták ki, hogy szolgáltatás közben, bizonyos id˝oközönként


28

is lehet számlázási információkat küldeni. Léteznek továbbá olyan szolgáltatások, események, amelyeknél a szolgáltatás számlázása többe kerül, mint maga a szolgáltatás. Erre tipikus példa a napjainkban olyan divatos SMS. Ilyen esetekben a szolgáltatás árába beszámíthatják a számlázás árát, vagy a szolgáltatást – bizonyos alapdíj, el˝ofizetés befizetése után – ingyen biztosíthatják a felhasználóknak [1]. A harmadik generációs mobil rendszerben lehet˝oség lesz egyszerre több szolgáltatást, és egy szolgáltatáshoz több média komponenst igényelni. Az ilyen szolgáltatásoknál a rendszer minden egyes komponenshez külön CDR-t generál, ezeket az információkat a számlázásért felel˝os központban összegezni kell tudni. Mint említettük a számlázási információkat a szolgáltatásban résztvev˝o elemek küldik a számlázó központnak (BS). Az információk küldése más-más interface-en keresztül történik a számlázás módjától függ˝oen (lásd a 2.4 fejezet). A CDR-eket a hálózati elemek meghatározott események hatására küldik. Ilyen események lehetnek például: • meghatározott adatmennyiség, • meghatározott id˝ointervallum, • számlázási feltételek megváltozása, • QoS változás, • tarifaváltozás, • helyváltozás, cellaváltás, • a beszéd (hívás, vészhívás), adat, multimédia kapcsolat lezárása • vagy egyéb, jól definiálható események: SMS vagy MMS küldése és fogadása, CAMEL (Customized Applications for Mobile network Enhanced Logic) szolgáltatások, kiegészít˝o szolgáltatások, LBS szolgáltatások. Részleges CDR-ek kiadására is szükség lehet. Ilyen például a már említett hosszú hívás, ahol a biztonság növelése és az el˝ofeldolgozás megkönnyítése érdekében egy tranzakcióra CDR-ek sorozatát adja ki a rendszer. Szükséges akkor is, ha egy rendszer maximalizálja a CDR-ek méretét, de az átvinni kívánt számlázási információ ezt a mértéket meghaladja, vagy ha a hívás alatt valamilyen változás következik be. Parciális CDR-ek esetén szükséges valamilyen azonosító és sorszám, hogy az összetartozó CDR-eket egyesíteni lehessen. A számlát a hálózat különféle számlázási információkból állítja össze. Az egyes információk két SND, vagy SND és HND között áramlik. A helyes átvitelhez szabványosított interface szükséges. Az átvitel id˝opontjának megválasztása (esemény


29

el˝ott, után, alatt) a két fél közötti megegyezés alapján történik. A számlázásban résztvev˝o elemeknek hitelesíteniük kell egymást, és a kapott információkat, így szükséges, hogy • a HND és az SND azonosítsa egymást, • a HND validálja az SND-t˝ol kapott számlázási információkat, • az SND és a felhasználó azonosítsa egymást, • és az SND validálja a felhasználótól kapott számlázási információkat. A számlázási információk összegyujtésére ˝ az IETF több protokollt is definiált. Ilyen például az SNMP, a TIPHON, a Radius vagy a Diameter [44]. A 3GPP az UMTS rendszerekben a Diameter-t és a GTP’-t (kiterjesztett GPRS Tunnelling Protocol) szabványosította. A Diameter (a Radius protokoll továbbfejlesztett változata) egy kapcsolat alapú AAA (Authentication, Authorization and Accounting) protokoll, melynek f˝o koncepciója a b˝ovíthet˝oség. Az alap Diameter protokoll AVP-k átvitelét, hitelesítést és hibajelzést garantálja, és TCP (Transmission Control Protocol) vagy SCTP (Stream Control Transmission Protocol) felett muködik. ˝ Az alap protokollban átvitelre kerülnek a különféle azonosításhoz szükséges, és az er˝oforrásfelhasználással kapcsolatos információk. A GTP’ protokollt a 3GPP definiálta, TCP vagy UDP (User Datagram Protocol) felett muködik, ˝ és alapvet˝oen a GSNek (GPRS Support Node) és a CGF-ek közötti biztonságos CDR átvitelt valósítja meg. A Diameter protokoll a valós ideju, ˝ a GTP’ a nem valós ideju ˝ számlázás megvalósítására ad jobb teljesítményt (lásd a 2.4 fejezet). A két számlázási mód, valamint a vezetékes és vezetéknélküli hálózatok konvergenciája miatt a Diameter protokoll használata javasolt [65].

2.4. Számlázási módok Mobil telekommunikációs környezetben kétfajta fizetési módot, és kétfajta számlázási módot különböztethetünk meg. A fizetési mód, a szolgáltatás törlesztésének fajtája szerint megkülönböztetünk el˝ore és utólag fizetett (pre-paid és post-paid) fizetési módot, a számlázás id˝obeliségét tekintve pedig valós ideju, ˝ és nem valós 1 ideju ˝ (online és offline) számlázást . Online számlázás esetén a szolgáltatás ára röviddel (1-2 mp) a szolgáltatás igénylése után levonódik a felhasználó számlájáról, még offline esetben ez csak több (3-30 sec) perccel kés˝obb következik be. Post-paid esetben a felhasználó a szolgáltatások igénylése után, általában havi rendszerességgel törleszti a szolgáltatások értékét. A számla kiegyenlítésére jogilag van kötelezve, ráadásul a szolgáltatók ráérnek az általuk megválasztott – például 1 az

angol kifejezés elterjedtsége miatt a továbbiakban az angol megfelel˝ot használom


30

a legkisebb terheléssel rendelkez˝o – id˝oszakban összesíteni a szolgáltatások ellenértékét, összeállítani a számlát. Pre-paid esetben a felhasználó el˝ore vásárolja meg a szolgáltatásokat. Ebben az esetben valós id˝oben kell figyelni a felhasználó számláját, hogy a számla kiürülése esetén azonnal meg lehessen tagadni az adott igényt. A pre-paid számlázás el˝onye, hogy a technológiai problémák és nehézségek leküzdése után a szolgáltatások nyújtásával egyik fél sem vállal kockázatot, hiszen annak kifizetése biztosított. Mivel post-paid számlázás esetén is lehet˝oség van különféle limitek meghatározására, valószínusíthet˝ ˝ o, hogy a post-paid és pre-paid fizetések kezelése egyre inkább összeolvad, és hasonló módon lesznek kezelve. Különbség egyedül abból fog adódni, hogy post-paid esetben megjelenhet negatív összeg az el˝ofizet˝o számláján, míg pre-paid esetben ez nem lehetséges [30]. Ahhoz, hogy ezt a fajta kontrollt biztosítani tudjuk, online számlázás használata szükséges.

2.5. Számlázási igények és elvárások A szabványosítási szervezetek jól körülhatárolják ugyan az UMTS rendszer számlázásának muködését, ˝ a pontos muködés ˝ leírása azonban lehetetlen az eltér˝o igények és a probléma komplexitása miatt. A szabványokban hagyott szabad paraméterek, a nem meghatározott muködési ˝ módok egységesítésére a szabványok különböz˝o irányelveket és elvárásokat támasztanak a megvalósított rendszerrel szemben. Így egy muköd˝ ˝ o UMTS rendszernek a következ˝o szempontoknak kell megfelelnie [5]: • médiumok, szolgáltatások és QoS osztályok külön számlázása, • technológiától független számlázhatóság, • többes-hívásnál minden el˝ofizet˝o számlázhatóságának megvalósítása, • felhasznált hálózati er˝oforrás szerinti számlázás lehet˝osége, • külön elbírálás megvalósításának lehet˝osége egyes esetekben: például service support hívása, • roaming (lásd 2.7.4 fejezet) számlázás átlátszósága, • pre-paid, post-paid számlázási technikák megvalósítása, • körzetek szerinti számlázás lehet˝osége roaming-nál, • az egyes mobil hálózatok között mindkét fél számára csalások kezelésének megoldása,


31

• költségkontrol a számlázott szerepl˝o részére, • a szolgáltatás el˝ott az ár megjelenítése a számlázott fél részére, • részletezett számla minden szolgáltatásnál az el˝ofizet˝o részére, • küls˝o szolgáltatók számlázásának lehet˝osége, • harmadik fél felé történ˝o számlázás lehet˝osége. Ezen túl, az üzleti modell szerepl˝oinek egyéb elvárásai is lehetnek, amelyek szorosan kapcsolódnak a számlázáshoz [36]. A felhasználói elvárások közé a következ˝ok tartoznak: • Egyszeru, ˝ strukturált számlát szeretne kapni. A számlán minden általa igényelt szolgáltatás (telekommunikációs és értéknövelt) érthet˝oen és csoportosítva szerepeljen. • El˝ozetes információt szeretne kapni a szolgáltatások áráról, miel˝ott igénybevenné azokat. • Átlátható tarifastruktúrát szeretne, amelyet el˝ozetesen megvizsgálhat és áttanulmányozhat. A hálózatoperátor els˝osorban bevételeit szeretné növelni, miközben kiadásait a minimumon tartja. Fontos tehát, hogy az új rendszer bevezetése minimális többletköltséggel járjon, illeszkedjen a legtöbb meglév˝o elemhez. Fontos továbbá, hogy a rendszer nyújtotta lehet˝oségeket megfelel˝o módon ki lehessen aknázni. A hálózati infrastruktúra szolgáltatójának többek között a következ˝o elvárásai vannak: • Az adminisztrációs rendszerébe integrálható biztonságos és automatikus díjazási és számlázási rendszer. • Különféle számlázási módszerek és számlázási módok alkalmazása a különféle szolgáltatásokhoz és küls˝o szolgáltatókhoz igazodva. • Minimalizált számlázási overhead. • Igazságos, a hálózati er˝oforrásokat és igényelt szolgáltatásokat huen ˝ tükröz˝o számlázás. • Flexibilis, a különböz˝o üzleti modellekhez alkalmazkodó számlázási rendszer. • Valós ideju ˝ számlázás a csalások megel˝ozésére és az igényelt szolgáltatások monitorozására.


32

Az alkalmazásszolgáltató szeretné minimalizálni az alkalmazás és szolgáltatásfejlesztés árát, majd szeretne minél nagyobb szabadságot élvezni a szolgáltatás adminisztrálásában. Így az alkalmazásszolgáltató elvárásai többek között: • Új szolgáltatások gyors és egyszeru ˝ fejlesztésének lehet˝osége. • A szolgáltatások értékének dinamikus módosítása, új szolgáltatások dinamikus hozzáadása. • A bevételek gyors szétosztása a szolgáltatás nyújtásában résztvev˝o elemek között. • A nyújtott szolgáltatások versenyképes árának biztosítása. Az IP feletti Multimédia szolgáltatások igénybevétele esetén a szolgáltató közvetlenül számlázhatja a felhasználót (Retail Charging), vagy számlázhatja a harmadik felet, akit˝ol az el˝ofizet˝o a szolgáltatást igénybe veszi (Wholesale Charging). Egy UMTS rendszerben igényelhet˝o kapcsolatban kett˝onél több fél, és egynél több médium is létezhet. Az adminisztráció során fel kell készülni, hogy több módon tudjuk számlázni az egyes résztvev˝oket. Az egyes kapcsolatok dinamikusan b˝ovülhetnek új elemekkel, a régi elemek paramétere, min˝osége változhat (akár folyamatosan is: például VBR – Vary Bit Rate). Új elem hozzáadásakor alapesetben az a fél fizet a szolgáltatásért, amelyik hozzáadja az adott médiumot, de minden olyan felet terhelhetünk, akik hálózati er˝oforrást foglalnak le az adott komponensért. A számlázás alapvet˝o feltétele egyrészr˝ol, hogy meghatározzuk a számlázandó felet, aki az adott szolgáltatás költségét megtéríti, valamint hogy rögzítsük a különböz˝o funkciókat, médiumokat és az azokhoz tartozó mérhet˝o mennyiségeket (id˝otartam, adatmennyiség, vagy min˝oség), amit mérni szeretnénk. A szabványok a következ˝o felek számlázását támogatják [5]: • hívó fél fizet (alapeset), • hívott fél fizet (például el˝ofizetett hírmondó szolgáltatás), • harmadik fél fizet (például céges telefonszámla), • fizetés megosztása (különböz˝o számlázási módszerek az egyes résztvev˝oknek). A számlázott fél kilépése esetén támogatott az új számlázandó fél (felek) megválasztása, vagy a résztvev˝o felek kiléptetése a kommunikációból. A különböz˝o számlázandó felek mellett a következ˝o médiumok számlázására kell felkészülni [5]:


33

• beszéd, • hang (valós ideju, ˝ vagy streaming), • videó (valós ideju, ˝ vagy streaming), • adat (letöltés, feltöltés, vagy interaktív tartalom), • üzenetek (SMS, E-mail), • adat-stream (nem meghatározott tartalom), • letöltött, hozzáfért elemek, portálok, szolgáltatások használata, • hely alapú szolgáltatások igénylése. A szabványok lehet˝oséget adnak arra, hogy az egyes felhasználóknak a rendszerben elérhet˝o összes ilyen médiumhoz külön számlájuk legyen. A felhasználó e komponensek mellett egyéb tevékenységeiért is számlázható egy adott kapcsolat során. Letöltés, illetve hozzáférés esetén a felhasználó a letöltött (zene file, videó klip, alkalmazás) és a hozzáfért (id˝ojárás, t˝ozsdei információk) tartalomért fizet. A hely alapú szolgáltatások igénylése esetén a felhasználó a földrajzi helyzetét˝ol függ˝o információkhoz (legközelebbi bankautomata, adott filmhez tartozó mozi keresése a környéken) való hozzáférésért fizet. Biztosítani kell az elektronikus fizetés lehet˝oségét harmadik, küls˝o felek irányába a különböz˝o mobil hálózaton keresztül igényelt szolgáltatásokért és a megvett árukért. Fel kell készülni továbbá, hogy az el˝ofizet˝o portál, vagy bármilyen más weboldal használatért, megnézéséért, vagy azokhoz kapcsolódó eseményekért fizethessen [5]. Az értéknövelt szolgáltatások esetén a felhasznált er˝oforrás-felhasználástól függetlenül kell tudni számlázni.

2.6. A számlázás menete A szolgáltatáskérés kezdete természetesen a felhasználó eszközének (MS – Mobile Station) autentikációjával indul, amely nem feltétlenül egyezik meg a felhasználó autentikációjával. Az azonosítás alapvet˝o feltétele a pontos számlázásnak és nehezebbé teszi a visszaéléseket. Az el˝ofizet˝o otthoni hálózata (HND) felel˝os az el˝ofizet˝o azonosításáért. Miután az azonosítás megtörtént, a HND delegálja az el˝ofizet˝o számlázásának jogát az aktuális SND-nek. Ez a jog tarthat a szolgáltatás végéig, vagy a HND által meghatározott ideig, adatmennyiségig (Charging Session). Utóbbi esetben a meghatározott limit elérése el˝ott – ha az el˝ofizet˝o még nem fejezte be az adott szolgáltatást – a HND-nek újból szükséges engedélyt adnia a további számlázásra. A számlázási információkat a HND gyujti ˝ be az összes kapcsolódó SND-t˝ol, amelyeket a felhasználó


34

használ. A HND-ben lév˝o számlázóközpont ezen információkat meghatározott id˝oközönként, vagy valós id˝oben feldolgozza, a hálózatoperátor és a felhasználó igényeit˝ol függ˝oen [5]. A SND és HND között elképzelhet˝o egy funkcionális elem (Cleaning House) amely a CDR-ek el˝ofeldolgozását végzi: a nem kívánt információk kiszurését, ˝ új információ hozzáadását, vagy pénznemkonverziót. A 2.4 fejezetben bemutattuk, hogy a számlázás id˝obeliségét tekintve megkülönböztetünk online és offline számlázást. A két számlázási mód olyannyira eltér egymástól, hogy a szolgáltatók többsége két külön rendszert alkalmaz a két számlázási mód megvalósítására. Csomagkapcsolt hálózaton alapuló szolgáltatás esetén a kapcsolatot PDP (Packet Data Protocol) kontextusnak nevezik. A kontextus kiépítése az SGSN-t és a GGSN-t érinti. A GGSN egyedi azonosítót rendel a kontextushoz (Charging ID), amit a számlázó rendszerrel és az SGSN-nel is közöl. Az azonosító segítségével az egy szolgáltatáshoz tartozó adatcsomagok azonosíthatóak és számlázhatóak. Ezek után a GGSN kiépíti a kapcsolatot a küls˝o szolgáltatóval. A kapcsolat kiépítés lépései: 1. Azonosítás. Az azonosítás szolgáltató függ˝o, történhet egy egyszerubb, ˝ beépített kihívás alapú protokollal vagy adatbázis (HLR – Home Location Register) és harmadik fél segítségével: például Radius, vagy Diameter szerver. Az utóbbi már kész megoldás, a kihívás alapú azonosításnál biztonságosabb és szabadabban illeszthet˝o a már meglév˝o rendszerekhez. 2. A szolgáltatás beindítható, ha az összes szükséges feltétel teljesül. A szolgáltatás engedélyezésének feltételei között szerepel, hogy a felhasználónak legyen megfelel˝o mennyiségu ˝ összeg a számláján. 3. A kapcsolat paraméterek átadása. Például min˝oségi jellemz˝ok (QoS), vagy egyéb paraméterek. Ezek után már engedélyezhet˝o a kapcsolat a felhasználó végberendezése és a küls˝o szolgáltató között. A hálózat kapcsolata a harmadik féllel az Internet és az IP-s gerinc miatt TCP alapú, a felhasználói eszköz felé rádiós. Az egyes elemeknek a szolgáltatás ideje alatt számlázási feladatokat is el kell látniuk. A GGSN a harmadik félt˝ol kapott adatmennyiséget, min˝oséget naplózhatja, így a hálózatoperátor a küls˝o tartalomszolgáltatók felé is bebiztosítható egy esetleges reklamáció esetére. Ez a naplózás egyszeru ˝ adatokat kell tartalmazzon, hogy a nagy adatmennyiségek ne okozzanak hatalmas terhelést a rendszerben. Az SGSN a szolgáltatott adatmennyiséget, a PS domain-beli er˝oforrás-használatot méri és QoS-t becsül: például a késleltetéseket és azok ingadozását. Az ideérkez˝o szolgáltatás min˝oségi paramétereinél csak rosszabb lehet a felhasználóhoz eljutó adatok min˝oségi paramétere, ezért már lehet, hogy itt megtörténik az alacsonyabb QoS kategóriába


35

történ˝o besorolás – amennyiben definiálható ilyen az adott szolgáltatáshoz – és ezzel lecsökkenthet˝o az MS-t˝ol érkez˝o CDR-ek mennyisége. A bázisállomás gyujti ˝ a nem számlázandó adatokat (például a sérült és dupla csomagokat), és méri a rádiós interface használatát is. A MS méri a szolgáltatott adatmennyiséget és a min˝oségi paramétereket. A valóságos min˝oségi osztály meghatározása csak itt lehetséges a rádiós kapcsolat rosszabb min˝osége miatt. A Release 5-ös szabvány 2004 szeptemberében befagyasztásra került, lezárult, és a Release 6 egyes részei már letölthet˝oek a hivatalos oldalról. Az el˝oz˝o verziókhoz képest a szabvány több újdonságot is tartalmaz, de f˝oleg koncepcionális kérdések kerültek pontosításra. A számlázásban jobban elkülönülnek az egyes rétegek (transport, szolgáltatás, tartalom), így azok számlázása külön-külön is megoldható. A hordozószolgáltatások kib˝ovültek a WLAN-nal (Wireless Local Area Network) is. A számlázás során külön figyelmet szenteltek a folyam alapú szolgáltatások számlázására, melynek segítségével lehet˝oség van különböz˝o adatfolyamok szétválasztására, differenciálására, a fels˝obb protokollok szerint: például videóstreaming, FTP (File Transfer Protocol), VoIP, böngészés. A különböz˝o folyamokhoz különböz˝o számlázási modellek és megoldások hozzárendelése is lehetséges. Erre a szabványok különböz˝o szurési ˝ (filtering) eljárásokat definiálnak [18].

2.6.1. Az offline számlázás menete A pre-paid fizetési mód esetén folyamatosan, szolgáltatás közben, valós id˝oben figyelni kell a felhasználó számláját, hogy a megfelel˝o esetben meg tudjuk tagadni a szolgáltatást, így az offline számlázás – a jelenlegi modellekben – csak post-paid esetben használható. Az 1.4 fejezetben már bemutattuk az UMTS rendszer logikai architektúráját, és a számlázás szempontjából fontosabb logikai entitásokat. A 2.3 fejezetben megemlítettük, hogy egy elosztott, csomagkapcsolt rendszerben a szolgáltatások számlázását úgy lehet megoldani, ha a szolgáltatás nyújtásában résztvev˝o elemek számlázási információkat (CDR) küldenek a számlázóközpontba. A számlázási információkat offline esetben a következ˝o elemek generálhatják [44]: MSC A CS alrendszerben a kapcsolatok kezeléséért felel˝os MSC generál és küld számlázási információkat. Ezen információk tartalmazzák a hívás idejét, a hívó és a hívott fél címét, telefonszámát, a kapcsolat megszakításának okát, és egyéb más, lényeges információkat. GSN A csomagkapcsolt alrendszerben (PS) a különböz˝o GSN-ek (SGSN, GGSN) generálnak számlázási információkat. A CDR-ekben szerepel többek között a használat ideje (a PDP kontextus id˝otartama), a forrás és a felhasználó azonosítója (IP cím, vagy APN - Access Point Name), az átvitt adat mennyisége, különböz˝o er˝oforrás-felhasználási információk (rádiós interface, PS domainbeli er˝oforrások), és különféle QoS információk.


36

CSCF Az IMS alrendszerben az CSCF-ek, az MGCF, az MRFC, a BGCF és az AS generálhat CDR-eket. A számlázás során a felhasználó valamilyen szolgáltatást igényel a hálózattól, vagy a hálózathoz csatlakozott küls˝o felekt˝ol. A szolgáltatás beindítása után a szolgáltatásban résztvev˝o elemek számlázási információkat küldenek a számlázó központba. Csomagkapcsolat esetben e számlázási információk áthaladnak a CGF-en, és azon keresztül jutnak a számlázó központba (BS). A CGF szükséges feladata a CDR-ek begyujtése, ˝ bufferelése és továbbítása a BS-felé. Ezen túlmen˝oen opcionális feladatokat is elláthat azért, hogy leegyszerusítse ˝ a számlázó rendszer feladatát. Ilyen opcionális feladatok a CDR-ek ellen˝orzése, a CDR-ek preprocesszálása, a szükségtelen attribútumok, mez˝ok kihagyása, új attribútumérték párok felvétele és a pénznem konverzió. A számlázási információk alapján a BS kezeli a számlákat és hálózati elemek által küldött min˝oségi paraméterek függvényében korrigálhatja a szolgáltatás árát. A számlázórendszer nagyobb id˝oközönként számlát állít ki a felhasználónak, amely fizetésre kötelezi. A kifizetés után a kapott, átutalt pénzt regisztrálja, majd szétosztja a szolgáltatások nyújtásában résztvev˝o elemek között. A Release 6-ban jobban strukturálva lettek az offline számlázáshoz tartozó hálózati funkciók. A CDR-ek küldését kiváltó eseményeket a szabványokban a CTF kezeli, továbbá e funkció vezérli a CDF-eket is. A CDF a CDR-ek összeállításáért felel˝os logikai funkció, amely az összeállított számlázási információkat a CGF-nek küldi tovább. Ezen extra logikai függvények a legújabb szabványokban külön definiálva vannak, de meglétük és funkciójuk a rendszer helyes muködéséhez ˝ eddig is szükséges volt.

2.6.2. Az online számlázás menete Az online (valós ideju) ˝ számlázás megvalósítása során nem elfogadható, hogy a szolgáltatás értéke csak több perccel az igénylés után vonódik le az el˝ofizet˝o számlájáról. Ezért online számlázás során más megoldást választottak, melynek lényege, hogy a hálózat bizonyos ideig, adatmennyiségig jogot ad a szolgáltatás nyújtására. Ezen jogot – a Release 6-ban leírtaknak megfelel˝oen – az OCF delegálja a szolgáltatást nyújtó hálózati elemnek. Amennyiben a felhasználó folyamatosan szeretné igényelni a szolgáltatást, úgy a delegált szolgáltatás-nyújtási jog lejárta el˝ott a szolgáltatást nyújtó hálózati elemnek újra jogot kell szereznie a szolgáltatás nyújtására. Markáns különbség jelentkezik az esemény alapú, és a kapcsolat alapú szolgáltatások között. Az el˝obbire az SMS, az utóbbira a videókonferencia kitun˝ ˝ o


37

példa. Esemény alapú szolgáltatásnál tudunk fels˝o korlátot mondani a szolgáltatás árára, még kapcsolat alapú szolgáltatások esetén az ár – általában – lineáris függvénye a kapcsolat idejének. A számlázás során tehát megkülönböztetünk kapcsolat alapú (SBC – Session Based Charging) és esemény alapú (EBC – Event Based Charging) számlázást az igényelt szolgáltatás típusától függ˝oen. Az esemény alapú számlázás során alkalmazhatunk egység lefoglalást, amikor az OCF meghatározott ideig, adatmennyiségig, eseményig jogot ad a szolgáltatás nyújtására (ECUR - Event Charging with Unit Reservation), vagy az igényelt szolgáltatás ára azonnal levonódhat a felhasználó számlájáról (IEC - Immediate Event Charging). Kapcsolat alapú szolgáltatásnál csak az egység lefoglalás jöhet szóba (SCUR - Session based Charging with Unit Reservation). Egység lefoglalás esetén a szolgáltatás végeztével, vagy hiba esetén er˝oforrás felszabadítás, naplózás és a fel nem használt összeg visszautalása kell hogy megtörténjen. A Release 6 az online számlázással kapcsolatosan is tartalmaz pontosításokat. Megjelent az OCS, amely az OCF-b˝ol, az RF-b˝ol és az ABMF-b˝ol áll. Az OCF SBCG-b˝ol (Session Based Charging Function) és EBCF-b˝ol (Event Based Charging Function) áll. Ez az entitás tartja a kapcsolatot a CTF-el, és o˝ felel˝os a megfelel˝o mennyiségu ˝ kredit lefoglalásáért, odaítéléséért. A RF a hálózati er˝oforrásfelhasználások értékét határozza meg, az ABMF pedig a felhasználó számlája az OCS-en belül [18].

2.6.3. Az IMS alrendszer számlázása Az IMS alrendszer számlázása egyszerubb, ˝ mint a reguláris csomagkapcsolt alrendszer számlázása, hiszen segítségével központilag kontrollálható, szabványos protokollal rendelkez˝o kapcsolat alapú szolgáltatások megvalósítása lehetséges. Mivel a szolgáltatások kapcsolat alapúak, az offline számlázás megvalósítása nem okoz különösebb gondot. Annak megvalósítása lényegében megegyezik a 2.6.1 fejezetben bemutatott esettel. A különbség csupán, hogy az IMS alrendszerben a CGF funkcióit a CCF látja el. Ez az elem megvalósítja a különböz˝o forgalmi típusok számlázását, és a különböz˝o médiakomponensekhez tartozó CDR-ek korellációját, összekapcsolását, valamint a CDR-ek biztonságos továbbítását és el˝ofeldolgozását [17]. Az IMS alrendszerben nincs definiálva a CTF online számlázáshoz szükséges funkcionalitását ellátó elem – ezzel szemben az offline számlázáshoz létezik ilyen funkció. A szolgáltatások engedélyezését, tiltását és terminálását a SIP alkalmazás szerverek végzik, így megfelel˝o kommunikáció biztosítása szükséges az OCS és ezen alkalmazás szerverek között. E kapcsolatot az IMS Gateway Function (IMS GWF) teremti meg. A számlázási oldalról tekintve az IMS GWF egy online számlázást megvalósító CTF, még az IMS architektúra felöl az IMS GWF egy SIP alkalmazás szerver [18].


38

2.6.4. A szolgáltatás árának meghatározása Egy szolgáltatás árának meghatározása komplex feladat és két nagy logikai lépésre bontható. Els˝oként meg kell határozni a szolgáltatás mennyiségét a szolgáltatás mértékegységének függvényében. Ezt a feladatot a Unit Determination végzi, amely megadja a szolgáltatás pontos, mért mennyiségét. A második, sokkal komplexebb feladat, a szolgáltatás árának meghatározása az el˝ofizet˝o paramétereinek (precedenciák, adható engedmények, stb) figyelembevételével (Rating). Mindkét lépést (Unit Determination, Rating) végrehajtó funkció lehet centralizált (a hálózatoperátor birtokában, hatáskörében lév˝o), vagy elosztott (a küls˝o tartalom, vagy alkalmazásszolgáltatótól által birtokolt)[12].

2.7. A számlázás technológiai problémái A harmadik generációs rendszerekben a nyújtható szolgáltatások köre szinte korlátlan, a számlázás kialakítása során minden szolgáltatás egyéni elbírálást kíván. Az igényelt módszerek változatos skálát mutatnak ugyan, de az egyes szolgáltatásokat csoportosíthatjuk az igényelt kapcsolat módja (áramkörkapcsolt, csomagkapcsolt) és a felhasználó számlázásának id˝obelisége (offline, online) szerint. Ily módon minden szolgáltatást a négy csoport valamelyikébe sorolhatunk, az azonos csoportba tartozók számlázásának módszerei csak kevéssé térnek el egymástól. Áramkörkapcsolt rendszerre legjobb példaként azokat a szolgáltatásokat említhetjük, ahol a felhasználót és a szolgáltatót els˝osorban az adatátvitel id˝otartama érdekli. Ilyen például a konstans min˝oségu ˝ telefonbeszélgetés vagy a videó lejátszás. E szolgáltatások során a felhasználó és a szolgáltató között fix sávszélességu, ˝ permanens csatorna van lefoglalva, így az er˝oforrás-foglalás állandó, ugyanakkor a hasznos adatátvitel – például telefonbeszélgetésnél – messze elmarad az optimálistól. A kihasználatlanságból ered˝o felesleges er˝oforrás-lefoglalásért a felhasználó fizet. Csomagkapcsolt esetben nincsen el˝ore lefoglalt csatorna, így az adatátvitel során minden egyes csomag önálló, a többi csomagtól független úton halad. Ebben az esetben nem foglalunk le felesleges er˝oforrást, ugyanakkor nincs garancia az átviteli sebességre, s˝ot egyes esetekben csomagok el is veszhetnek. A számla kiegyenlítésének id˝obeliségét tekintve az utólagosan fizetett (havidíjas) esetben, ahol a felhasználó nagyobb id˝oközönként rendezi a számláját, a módszer viszonylag egyszeru. ˝ Nem jelent mást, mint megfelel˝o mérési módszert kitalálni az adott szolgáltatáshoz, médiumhoz, majd mérés után a megfelel˝oen eltárolt adatokat, értékeket, egy kés˝obbi id˝oben egyszerre összegyujteni. ˝ Ebben az esetben technikailag nem kell foglalkozni a szabályozással, a felhasználó jogilag van kötelezve a számla kiegyenlítésére. Igaz, a mérési módszer implementálása


39

sem egyszeru ˝ feladat, de mivel ez er˝osen szolgáltatásfügg˝o, minden egyes szolgáltatáshoz egyedileg kell megterveznie és kialakítania a szolgáltatónak. A havidíjas számlázás tehát egyszerunek ˝ mondható, a tapasztalatok szerint azonban jó néhány országban a mobil telekommunikációs hálózatot használó el˝ofizet˝ok nagy része a kártyás, pre-paid típusú szolgáltatásokat részesíti el˝onyben. Ilyen esetben elengedhetetlen a valós ideju ˝ számlázás, mivel limitálnunk kell a szolgáltatást az el˝ore befizetett összegre. A szabványok ezen felül lehet˝oséget adnak arra, hogy a felhasználók havidíjas, utólagosan fizetett esetben is limitálják a szolgáltatásokra költhet˝o pénzösszeget (Limit Control). Ebben az esetben a havidíjas felhasználókat is a kártyás felhasználókhoz hasonlóan kell kezelni, azaz valós id˝oben kell figyelni a számlájukat, hogy a limit túllépést elkerüljük. A vezetékes telefóniában és a GSM alapú mobil rendszerekben a számlázás megvalósítása viszonylag egyszerunek ˝ mondható. Az igényelt szolgáltatás ára, az áramkörkapcsolt rendszer miatt, csak a szolgáltatás igénybevételének idejét˝ol, hosszától függ. A GPRS és UMTS rendszer azonban csomagkapcsolt, így problémát jelent a szolgáltatás min˝oségének és a szolgáltatás mennyiségének mérése. Mind a mennyiség, mind a min˝oség mérése elengedhetetlen, hiszen csak a valóban szolgáltatott min˝oségért és adatmennyiségért van jogunk pénzt kérni. Ezen problémák, mérések megvalósítása amúgy sem egyszeru ˝ feladat, ráadásul pre-paid esetben (online számlázás esetén) mindezt valós id˝oben kellene megoldani. A két alapvet˝oen fontos mérésen (a mennyiség és a min˝oség mérésén) kívül a valós ideju ˝ számlázás megvalósításának még vannak technológiai akadályai. A mobil telekommunikációs rendszerekben az online számlázás már a hálózat hatalmas mérete miatt is igen nehéz feladat, hiszen valós ideju ˝ számlázást kellene megoldani egy országos méretu ˝ hálózatban, ahol már maga a terjedési késleltetés is gátat szab a számlázás valós idejuségének. ˝ Alapesetben a számlázási információk összegzését és a számla kezelését a számlázó központ (BS) látja el. A BS egy központosított, centralizált elem, amelyb˝ol hálózatonként egy található. A számlázó csomagok generálását és a tartalmak, szolgáltatások blokkolását azonban a szolgáltatásokat nyújtó egyéb hálózati elemek végzik. Mivel valós fizikai információáramlásról beszélünk, a számla lekérdezése – annak meghatározására, hogy a felhasználó jogosult-e a szolgáltatás igénybevételére – id˝ot vesz igénybe, így semmiképpen sem beszélhetünk abszolút értelemben real-time rendszerr˝ol.

2.7.1. Az adat mérése Ahhoz, hogy pontosan meg tudjuk mérni az átvitt adat mennyiségét, meg kellene számlálni a rendszeren átfolyó biteket. Ez az átviteli sebesség miatt sem egyszeru ˝ feladat, hiszen az UMTS rendszer a GPRS rendszernél jóval nagyobb átviteli sebességet biztosít, ami több millió felhasználó esetén a Terrabit/sec-es átviteli sebességet is elérheti. Ilyen sebesség mellett az egyes adatcsomagok feldolgozása


40

hatalmas számítási kapacitást igényel a hálózati elemekt˝ol. Az adat mérésének szintén markáns problémája, hogy a pontos adatszámlálás túl nagy overheadet jelentene a rendszernek. Egyszeruen ˝ megfogalmazva N darab felhasznált bit számának pontos átviteléhez legalább logN bit szükséges. Könnyíthetünk mind a számítási kapacitás, mind az overhead problémáján, ha az átvitt bitek helyett az átvitt IP csomagokat számoljuk meg, de ez sem jelent tökéletes megoldást, hiszen az IP hálózatokban a csomagok nem azonos méretuek ˝ [24] [25]. Az átviteli közeg tökéletlenségéb˝ol adódóan ügyelnünk kell az eldobott, sérült adatokra és a csomagduplázásra is. A sérült (esetleg eldobott) adatokat a fels˝obb rétegek hibajavító mechanizmusa (például TCP) újraküldheti. Így a felhasználó hibáján kívül, a hálózat tökéletlensége miatt egyes csomagokat duplán számláznánk, a hálózat hibájából adódó többletköltséget azonban nem terhelhetjük a felhasználóra. Az egyes csomagok a forrástól a célig több úton juthatnak el, a különböz˝o utak pedig különböz˝o terjedési késleltetéseket jelentenek, amely megnehezíti az egy adatfolyamhoz tartozó csomagok helyes felhasználását. Ha az adatok számlázását nem egy darab hálózati entitás végzi (például a végberendezés, vagy a bázisállomás), hanem a hálózati csomópontok (SGSN), akkor az egy adatfolyamhoz tartozó adatok számláját összegezni kell tudni. Ha a szolgáltatáshoz tartozó adatmennyiséget pontosan meg is tudnánk mérni, az nem biztos, hogy egyértelmuen ˝ meghatározná a nyújtott szolgáltatás mennyiséget, hiszen a két érték nem feltétlenül egyezik – két kisebb méretu ˝ cseng˝ohang letöltése nem egyenértéku ˝ egy nagyobb méretu ˝ cseng˝ohang értékével. Így a két mennyiséget valahogy összhangba kell hozni. Ha a szolgáltatáshoz rendelhet˝o adatsebesség, akkor ezen korelláció könnyen meghatározható. Az IP alapú számlázásra már léteznek modellek. E modellek többségének mu˝ ködése azon alapul, hogy egy központi brókert˝ol vett lánc elemeit az IP csomaggal együtt küldjük a hálózatba, ennek hiányában pedig eldobjuk, vagy nem engedjük be azokat. A láncot egy gyökérelemb˝ol generálják egy egyirányú hash függvény segítségével. Az általunk vizsgált modellt [50] els˝osorban azonosításra találták ki, ezért a számlázást támogató része gyengének mondható. Nem támogatott benne például a letöltéshez hasonló szolgáltatás, ahol más fizeti az adatot, és más küldi a hálózatba. Az IP alapú számlázási modellek els˝osorban vezetékes környezetben lettek kifejlesztve, a mobil hálózat rádiós átviteléb˝ol adódó eltér˝o paraméterek – például jóval magasabb hibaarány – és a mobilitásból származó nehézségek miatt nem ültethet˝oek át közvetlenül a mobil hálózatokra. A mobil telekommunikációs rendszerek számlázását a 3GPP bizonyos szinten szabványosította, és ezen IP alapú számlázások sajnos nem kompatibilisek a vonatkozó szabványokkal. Már látható, hogy a legalapvet˝obb szolgáltatás (az adatszolgáltatás) mérése is rendkívül bonyolult, nagy overhead-et igényl˝o feladat. Ráadásul pre-paid esetben mindezt valós id˝oben kellene végrehajtani. A jelenlegi megoldásokban az adatszámlálást a legtöbb szolgáltatónál valamilyen könnyen mérhet˝o egységhez kapcsolják, id˝o alapon és állandó átviteli sebesség szerint számlázzál, átalány-


41

díjban fizettetik, de legalább is nagyobb – például több kilobyte-os – egységekben mérik [49]. Ezen megoldások mellett elképzelhet˝o még néhány modell [52]. Az optimális megoldás természetesen a csomagszámlálás lenne, de ez a már említett nehézségek miatt nehezen megvalósítható. Várt kapacitás becslés esetén a felhasználók adatforgalmát különböz˝o torlódási pontokban – például a hálózat határain – megvizsgálják, majd a felhasznált sávszélességb˝ol becslik a felhasznált adatot. A megoldás problémája, hogy ha az el˝ofizet˝o több szolgáltatást igényel, akkor valahogy szét kell választani az egyes szolgáltatások sávszélességét, valamint hogy a fizetend˝o összeg meghatározása a becslés miatt nem teljesen pontos. A párizsi metró alapú számlázás esetén az adatforgalmakat külön osztályokba sorolják, majd az osztályoknak megfelel˝o forgalomirányítást és számlázást használnak. A modellel biztosítható a prioritás és a QoS, de bonyolult matematikai modellt és automatikus osztály-hozzárendelést igényel a szolgáltatásokhoz. Az igény alapú modell alapötlete, hogy a felhasználók beállíthatják maguknak a médiumokhoz tartozó prioritást (meghatározott prioritás egységeket osztanak szét), és ez alapján biztosítják számukra a megfelel˝o min˝oséget. Az adatszámlálás az el˝oz˝oek valamelyike lehet, lényeg, hogy a szétosztott prioritások arányában súlyozzák a szolgáltatásokért járó összeget. Látható, hogy az adatszámlálásra több modell is rendelkezésre áll, a helyzet mégis nehéznek mondható a modellek bonyolultsága, vagy tökéletlensége miatt. Szerencsére a prospektusok és az Interneten található termékleírások szerint a jelenleg kapható UMTS hálózati elemek gyártói magukra vállalják ezt a feladatot. A piacon már kapható olyan GGSN amely támogatja a tartalomfügg˝o valós ideju, ˝ pre-paid számlázást, az azonosítást, a különböz˝o QoS-eket és valós id˝oben képes a számlák frissítésére [75].

2.7.2. A min˝ oség mérése Az UMTS rendszerekben a beszéden kívül számos más médium is rendelkezésre áll. Az egyes szolgáltatások lehetnek adat, esemény vagy id˝oalapúak. A számlázás így e három mérend˝o mennyiségb˝ol, valamint a szolgáltatás min˝oségéb˝ol tev˝odik össze. Ahhoz hogy a rendszer pontosan tudja elvégezni a szolgáltatás árának meghatározását, tudnia kell, hogy azokat milyen módon kell számlázni, valamint képesnek kell lennie a szolgáltatás min˝oségének mérésére. Ha a szolgáltatást egy küls˝o fél nyújtja, a hálózatoperátor tudtára kell hozni ezeket a paramétereket. A szolgáltatások mérése változatos skálát mutat. Minden egyes szolgáltatásnál külön meg kell határozni azokat a paramétereket, amelyek a szolgáltatás min˝oségét reprezentálják: VoIP kapcsolat esetén ilyen paraméterek például a késleltetés, vagy a bithibaarány. Az IP alapú szolgáltatások esetén e paraméterek megkaphatóak a szolgáltatáshoz tartozó adatfolyam min˝oségéb˝ol. Ily módon a csomagkapcsolt szolgáltatások min˝oségéhez az adatfolyam min˝oségét kell meghatározni,


42

majd abból a szolgáltatásra jellemz˝o módszerrel kiszámolni a valós QoS-t. Nem áramkörkapcsolt rendszerben azonban az adatszolgáltatások min˝oségének mérése nem egyszeru ˝ feladat, hiszen best-effort jellegu ˝ szolgáltatás esetén nincs fix átviteli kapacitás lefoglalva az egyes kapcsolatokhoz. A kapacitásra és a késleltetésre csak a rendszer túlméretezésével, vagy nagy jelzésrendszeru ˝ protokollokkal (MPLS, Intserv, Diffserv) lehet garanciát vállalni. Az új protokollok alkalmazásához azonban ki kellene egészíteni a hálózati csomópontokat a megfelel˝o funkciókkal. A cellaváltásoknál még így is nehéz biztosítani a vállalt min˝oséget. Az objektíven mérhet˝o adatokon kívül lehetnek a szolgáltatásoknak olyan paraméterei, amiket nem tudunk mérni, mégis nagyban befolyásolják a felhasználó szubjektív megítélését. Erre jó példa a videó-streaming, hiszen videó nézés esetén az aktuális tartalom, a cselekmény is befolyásolja az élvezhet˝oséghez szükséges minimális min˝oséget.

2.7.3. A mobilitásból adódó probléma Az All-IP koncepció megvalósulásával a mobil telefon segítségével elérhet˝o funkciók IP alapon lesznek megvalósítva. Az alap koncepció szerint minden végberendezéshez külön IP cím fog tartozni – ami lehet állandó, vagy változhat. A használt mobil készülékek száma természetesen megköveteli az IPv4-nél nagyobb IP címtartományt, ezért érdemes a rendszert az IPv6-ra tervezni. A megoldás természetesen muködhet ˝ IPv4-es megoldásokkal is, amíg az újabb verzió általánossá nem válik. A mobil végberendezés mobilitásából azonban problémák származnak, mivel meg kell oldani a készülékek címének kezelését. Két megoldás látszik kivitelezhet˝onek: a mobil készülék IP címe fix, a hálózati elemek információját frissítjük, vagy a végberendezés IP címét változtatjuk a hely függvényében. Ha a mozgás során fix IP címet használunk, és a hálózatban lév˝o routerek tábláját módosítjuk, akkor a számlázás szempontjából átlátszó lesz a mozgás, de a routerek információfrissítése (update-elése) újabb problémákat vet fel. Amennyiben az IP cím folyamatosan változik, akkor a számlázási információkat kezel˝o egységek információját kell folyamatosan módosítani. Támaszkodhatunk természetesen az IPv6 mobilitáskezelésére is (cellás IP, mobil IP), de a hálózati overhead ezen esetekben is növekszik.

2.7.4. A roaming problémája Roaming-nak az idegen hálózatban – általában külföldön – való mobil telekommunikációs hálózat használatot nevezzük. A hang-alapú, áramkörkapcsolt szolgáltatások pre-paid esetben jelenleg visszahívásos (Call-Back) rendszerrel vannak megvalósítva. Az el˝ofizet˝o tudatja az otthoni hálózatával az általa hívandó számot,


43

az otthoni hálózat pedig létrehozza a kívánt kapcsolatot, és visszahívja a felhasználót. Az adatszolgáltatás megvalósítása kicsivel bonyolultabb. Roamingolt esetben az igényelt adat az Internetr˝ol beléphet az el˝ofizet˝o otthoni hálózatába vagy a meglátogatott hálózatba [40]. Amennyiben az otthoni hálózatban engedjük be az adatot, azt a két mobil hálózat között ki kell cserélni. A megoldás feleslegesen foglalja le a hálózatok er˝oforrásait, de megkönnyíti az adat számlázását. Ha az adat a meglátogatott hálózatban lép be a rendszerbe, akkor a számlázás pontossága a hálózatok egymásnak küldött információitól függ. A hálózatoperátorok jelenleg zömében az els˝o megoldást alkalmazzák, de az ilyen jellegu ˝ pre-paid számlázás nem minden szolgáltatónál támogatott. Alap elvárás roamingolt esetben, hogy a felhasználó ugyanazon paraméterekkel, és ugyanolyan módon legyen számlázva, mint az otthoni hálózatában. Ennek megvalósítására, a hálózatok delegálhatják a számlázási algoritmust a meglátogatott hálózatok részére [1]. A számlázás valós idejusége ˝ és pontossága azonban mindenképpen az idegen hálózat képességeit˝ol, és az otthoni hálózatnak szolgáltatott adatok min˝oségét˝ol függ. Külön problémát vet fel, hogy az otthoni és az idegen hálózat között valamilyen megegyezés kell, hogy a felmerül˝o költségeket el tudják számolni. Mivel N mobil hálózat esetén N (N − 1) megegyezésre lenne szükség, ami hatalmas adminisztratív overhead-et jelentene, ezért a felek között automatikus roaming megegyezés szükséges. Automatikus roaming esetén a feladat olyan hálózatban szolgáltatásokat igénybe venni, akivel nincs direkt megegyezése a honos hálózatnak (HND). A számlázási módszer nem különbözik az átlagos, megegyezés alapján történ˝o roamingtól, az automatizálást egy küls˝o entitás, a Roaming Broker végzi [5]. Az automatikus megegyezéshez kiegészít˝o eljárások is szükségesek, hiszen • Egymás azonosításához egy megbízható harmadik fél szükséges. • valamilyen routing mechanizmusra van szükség, hogy a SND megtalálja a felhasználó HND-jét – szükség van a minimális költségu ˝ út megkeresésére. • A szolgáltatásban résztvev˝o hálózatoknak el kell fogadtatni (egymás felé) a számlázási mechanizmusukat. A szolgáltatók egymás közötti számlázása tömegesen, nagy tételben történik. Ennek pontos menete a szolgáltatók közötti megegyezés kérdése. Minden szolgáltató figyeli a kimen˝o és bemen˝o forgalmát, ebb˝ol pontosan kiszámítható a fizetend˝o összeg. Ez a fajta számlázási információ standardizált TAP (Transfer Account Procedure) formátumban történik [44].


44

2.7.5. Egyéb problémák Offline esetben minél pontosabb képet szeretnénk kapni egy szolgáltatás igénylésér˝ol, a hálózati elemeknek annál sur ˝ ubben ˝ kell számlázási információkat küldeniük a számlázó központba. A sur ˝ u ˝ CDR küldéssel azonban leromlik a hálózat kihasználtsága, n˝o a hálózati overhead. Online esetben, ha nagy mennyiségu ˝ egységet allokálunk a szolgáltatást nyújtó hálózati elemnek, akkor el˝ofordulhat, hogy adott pillanatban a felhasználó nem tud más szolgáltatást elindítani. Ez annak köszönhet˝o, hogy nem lesz elegend˝o felhasználható egység a számláján, még akkor sem, ha az éppen igényelt szolgáltatás nem használja fel az összes számára allokált egységet, és a szolgáltatás végeztével visszautalja a maradékot. Amenynyiben kisebb egységeket foglalunk le, úgy az el˝obbi probléma sokkal kevésbé jelentkezik, de az egység-lefoglaló üzeneteket sokkal sur ˝ ubben ˝ kell küldenünk, így ismét n˝o hálózati overhead. Látható, hogy mind offline, mind online esetben valamiféle kompromisszumra kényszerülünk. Az online eset megoldására a Release 6-os szabványok kezdeti verzióiban megjelent a Credit Pooling [18], amely hathatós megoldást nyújtana több szolgáltatós környezetben. A megoldás tulajdonképpen az algoritmusok, AVP-k és kontrol üzenetek kiterjesztése. Egy nagyobb egységet allokálnak a Credit Pool entitásnak, amely a továbbiakban felel˝os az egységek helyes szétosztásáért a szolgáltatások között [23]. Az UMTS rendszerben az elérhet˝o funkciók miatt rengetek új szolgáltatás lesz elérhet˝o, melyek nagy részét nem is a hálózatoperátor nyújtja. Emiatt elvárható, hogy a szolgáltatás igénylése el˝ott az el˝ofizet˝oknek megjelenjen a szolgáltatás pontos ára, hogy tisztában legyenek a fizetend˝o összeggel. A felhasználónak lehet˝oséget kell adni, hogy felügyelhesse a saját számláját, a szolgáltatásért kiszabott pénzt. A hálózatnak tehát szolgáltatnia kell ezeket az adatokat az el˝ofizet˝oknek. Megoldható kell hogy legyen továbbá, hogy a felhasználók limitálják saját költségeiket. A limit túllépése esetén az el˝ofizet˝onek értesítés küldhet˝o vagy automatikusan letiltható az adott szolgáltatás. Ezt a fajta szolgáltatást az AoC (Advice of Charge) funkciót biztosítja [3] [18]. Az AoC a szolgáltatást nyújtó elemek által biztosított CAI (Charge Advice Information) információt használja fel, hogy megjelenítse a szolgáltatás árát [2]. A küls˝o tartalom- és alkalmazásszolgáltatók megjelenése további problémát okoz, hiszen a rengeteg nyújtható szolgáltatás miatt biztosítani kell a felhasználóknak, hogy megtalálják a számukra értékeset és releváns szolgáltatást. Így fontos, hogy olyan fontos információkhoz is hozzáférjenek, mint például a szolgáltatás pontos leírása és ára. Valószínusíthet˝ ˝ o, hogy a küls˝o felek a szolgáltatások árát dinamikusan szeretnék változtatni, így ezen információ átviteléhez is valamilyen szabványos interface szükséges [44]. Egyes felhasználók kedvezményekre lehetnek jogosultak, mert például valamilyen csoport, egyesület tagjai. Ezen el˝ofizet˝oknek egyes szolgáltatások olcsóbban (eset-


45

leg ingyen) értékesíthet˝oek. A csoport, egyesület tagjai azonban dinamikusan változhatnak, így ezt az információt is folyamatosan ellen˝orizni kell [56] [33]. A 2004-es szabványokban megjelent a Location Based Services, melynek segítségével a felhasználók földrajzi helyzetükt˝ol függ˝o tartalmakhoz férhetnek hozzá. E szolgáltatás bevezetése újabb technológiai nehézségeket vet fel, amikkel a mobil hálózat üzemeltet˝oinek meg kell birkóznia. A számlázás szempontjából e funkció értékesítését szétbonthatjuk egy esemény alapú számlázásra, és a tartalom értékesítésére. Amennyiben a felhasználó igénybe vesz ilyen szolgáltatást, az szétbontható egy fix, esemény alapú szolgáltatásra, valamint a helyszínhez kapcsolódó tartalomra. Néhány egyéb szolgáltatás kezelését – például E-mail küldést, fogadását, szerviz központ hívását, vagy reklám célú szolgáltatások nyújtását – a hálózati operátor külön elbírálhatja.

3. fejezet

A kidolgozott modell Modellünk megalkotásánál els˝odleges cél volt, hogy könnyen illeszthet˝o legyen a jelenleg használt rendszerekhez. A szabványokban mind az offline mind az online számlázás muködését ˝ definiálják, így nem volt cél e módszerek, metódusok módosítása. Modellünket a jelenlegi szabványoknak megfelel˝oen készítettük el, ügyelve arra, hogy minimális extra funkcionalitást vigyünk a rendszerbe. Így a modell helyes muködéséhez ˝ szükséges volt, hogy az a vonatkozó szabványoknak megfeleljen. Általánosan elmondható, hogy a szabványok által biztosított szabad paramétereket helyesen megválasztva tudunk elkészíteni egy optimálisan muköd˝ ˝ o rendszert. Jelen esetben szabad paraméter például a CDR generálását kiváltó adatmennyiség és a kapcsolat id˝otartama, valamint egység lefoglalásnál (Unit Reservation) a lefoglalt egység mérete. Offline számlázásnál minél kisebb mennyiséget / id˝otartamot választunk, annál pontosabb lesz a számlázás, a számlázóközpontnak annál pontosabb képe lesz a felhasználó egyenlegér˝ol, ugyanakkor annál nagyobb lesz a hálózati overhead, a hálózat kihasználhatóságának mértéke csökken, hiszen a számlázó csomagok, egységlefoglaló csomagok egyre sur ˝ ubben ˝ generálódnak. Online számlázás során minél nagyobb egységet foglalunk le az el˝ofizet˝o számlájáról, annál valószínubb, ˝ hogy újabb szolgáltatások igénylése esetén nem lesz elegend˝o szabad egység (pénz) a felhasználó számláján, még akkor sem, ha az el˝ofizet˝o megszakítja, terminálja a szolgáltatást, és a lefoglalt pénz egy része kés˝obb visszakerül a felhasználó számlájára. Ennek fényében online számlázás esetén célszeru ˝ minél kisebb egységet lefoglalni, hogy több szolgáltatást is el lehessen indítani. A kisebb egységek miatt azonban gyakrabban kell új összeget lefoglalni, a hálózati overhead ismét n˝o. Másik szabad paraméter, hogy az egyes szolgáltatásokhoz tartozó számlázási funkciók (CGF, tartalomblokkolás) nincsenek fizikai entitáshoz kötve. Az adatátvitel számlázásáért felel˝os funkció beépíthet˝o a mobil hálózat és a publikus Internet

46

3. FEJEZET. A KIDOLGOZOTT MODELL

47

határán lév˝o átjáróba (GGSN), a mobil hálózat csomópontjaiba (SGSN), a bázisállomásba, vagy akár a felhasználónál lév˝o mobil készülékbe. Harmadik szabad paraméternek tekinthetjük a szolgáltatás mérését. A szabványok nem térnek ki a szolgáltatások mérésének módjára, így például adatátvitelnél becsülhetünk sávszélességet, vagy valójában megpróbálhatjuk megszámolni az átvitt biteket. A pontosabb adatmérés nagyobb számítási kapacitással, és nagyobb hálózati overheaddel jár – látható, hogy itt is valamiféle kompromisszumra kényszerülünk.

3.1. A modell muködése ˝ Modellünk alapötlete, hogy dinamikusan vált az offline és online számlázás között, a felhasználó egyenlegét˝ol függ˝oen. A megoldás során, ha a felhasználónak egy bizonyos – a szolgáltatástól és a hálózat paramétereit˝ol függ˝o – limit felett van a számlája, akkor a számlázás offline módon történik. Ezt a limitet a továbbiakban mode-switching (mód-váltó) limitnek nevezzük. Az offline számlázás el˝onye, hogy sokkal kisebb overhead-del jár, logikusnak tunik ˝ tehát, hogy olyan helyzetekben, ahol a felhasználó nem tudja elkölteni a számláján lév˝o összeget az elkövetkez˝o rövid id˝oben – például több tízezer forint van a számláján – offline számlázást alkalmazzunk online számlázás helyett. A limitet és a CDR küldését kiváltó adat, vagy id˝omennyiséget helyesen megválasztva a felhasználó nem kaphat a kifizetettnél több szolgáltatást, hiszen amennyiben a limit alá csökken a számla, a központ azonnal online számlázásra vált, ahol a pontos és igazságos számlázás biztosított. A modell megalkotása során azzal a feltételezéssel éltünk, hogy a CDR-ekben és az egységlefoglalás üzeneteiben (URM - Unit Reservation Message) többé-kevésbé ugyanazon információk szerepelnek, így a két csomag, üzenet mérete megegyezik. Mivel a rendszer a CDR-eket a szolgáltatás / esemény után küldi, és az nem befolyásolja további szolgáltatások indítását, ezért az offline számlázási információkat elég ritkábban küldeni. Ennek fényében az offline számlázáshoz tartozó overhead sokkal kisebb, mint online esetben. Egy másik egyszeru ˝ ötlettel az online számlázásból adódó többlet overhead tovább csökkenthet˝o. A limit alá érve a felhasználó számlájának teljes összegét delegálhatjuk a szolgáltatást nyújtó hálózati elemnek, így csak egyetlen URM-el kell számolnunk. A korszeru, ˝ több task-os rendszerekben egyszerre több szolgáltatást is igényelhetünk. Ilyenkor alacsony pénzügyi egyenlegnél, több elemnek kellene delegálnunk a számlát. Megoldást jelenthet, ha statisztikai módszerekkel az egyes szolgáltatások között súlyozva szétosztjuk a felhasználó számláját, figyelembe véve a szolgáltatások pénz szükségleteit, tulajdonságait, és a felhasználó eddigi viselkedését. Amennyiben egy szolgáltatást akkor kezdünk el igényelni, amikor egy másik szolgáltatásnak már kiszolgáltattuk a teljes számlát, úgy a számlát vissza kell kérni, és újra elosztani. Ez a funkció nem szerepel a szabványokban, ezért


48

megvalósításához a hálózati elemek funkcionalitását ki kell egészíteni. Ennek az ötletnek az a feltevés ad létjogosultságot, hogy a felhasználók az alacsony számlaegyenleg tudatában (pár száz forint) sokkal kevésbé igényelnek komplexebb szolgáltatásokat. Amennyiben a kiszolgáltatott kredit-eket nem kell visszaigényelni, úgy ez a modell lényegesen jobb eredményeket produkál, mint a szabványokban rögzített másik két megoldás. Mivel az UMTS rendszerben csomag alapú szolgáltatások lesznek, számolnunk kell az elveszett csomagokkal. A csomagok legnagyobb része a rádiós interfaceen veszik el, de természetesen (mint ahogyan a hagyományos Internetnél is) a gerinchálózaton is el˝ofordulhat csomagvesztés vagy sérülés, hibázás. Az elveszett adatok kezelését szintén statisztikai módszerrel tudjuk megoldani. A hálózatszolgáltató hálózatán belül történt csomagvesztések arányát figyelembe véve több csomagot engedhetünk a rendszerbe, így a felhasználó nagy valószínuséggel ˝ megkapja a neki járó csomagszámot. Mivel (mint már említettük) az IP csomagok mérete nem fix, a pontos adatmennyiséget vagy becsülni kell, vagy az IP fejlécekb˝ol pontosan meghatározni (ez viszont nagy számítási kapacitásokat jelent a hálózati elemeknek). Célszeru ˝ a vezetékes és rádiós hálózat határán bufferelést beiktatni, hogy a rádiós közegben megsérült adatokat csak a bázisállomástól kelljen újraküldeni, így nem terheljük feleslegesen a gerinchálózatot. Amennyiben szükséges, a gerinchálózaton bekövetkez˝o hibákat a TCP hibajavító mechanizmusa lekezeli. A csomagvesztéshez, valamint a csomag alapú QoS méréséhez valamilyen megbízható végberendezésre van szükség. Ez lehet a bázisállomás, vagy a protokollt beimplementálhatjuk a mobil végberendezés valamilyen alacsony rétegébe. Az alacsony rétegbe való implementálás fontos, hiszen magasabb, különösen alkalmazási szinten a felhasználó (csalással) módosítani tudja a protokollt. A RealNetworks által kifejlesztett RealMedia formátumú hang-, és videó-streaming az RTP (Real-time Transport Protocol) protokollt használja. A protokoll segítségével egyszeruen ˝ és szabványosan tudjuk megvalósítani a távoli videó lejátszást, ráadásul a protokoll támogatja a min˝oség visszajelzését is. A videó lejátszó program folyamatosan küld statisztikai adatokat a tartalmat szolgáltató egységnek. A megoldás hátránya, hogy a statisztikai adatokat egy alkalmazás szintu ˝ program szolgáltatja. Ha ez a megoldás kerülne használatba, valószínuleg ˝ megjelennének olyan lejátszó software-ek, amelyek megvalósítják a protokollt, de visszajelzett min˝oségként a valós esetnél rosszabbat szolgáltatnának, így az el˝ofizet˝o olcsóbban jutna hozzá a jobb min˝oségu ˝ szolgáltatáshoz (videóhoz). A biztonságos megoldás tehát valamiféle alacsony szintu ˝ protokoll. A mérés lényege, hogy a végpontnak valamilyen információkat kell küldenie a számlázó központnak, mert az csak így szerezhet tudomást a felhasználó által tapasztalt min˝oségr˝ol. A mért elemek nyílván a végberendezés által kapott csomagok lesznek (hiszen más elem mérése csak magasabb szinten lehetséges). Ezekb˝ol lehet majd következtetni a szolgáltatás min˝oségére. A csomagsorozat mérését csúszóablakos módszerrel


49

végezhetjük. Megfelel˝o mennyiségu ˝ csomag beérkezése után az adatsorozaton értelmezhetjük a késleltetést (átlagos késleltetés, maximális késleltetés, jitter), a csomagvesztést, az átviteli kapacitást és egyéb QoS paramétereket. A csomagvesztésnél a csomag újraküldését valamint a jelzéseket fels˝obb protokollokra bízhatjuk. A QoS mérését mindenhol kiválthatjuk a hálózatra vonatkozó statisztikai módszerekkel, de ebben az esetben nem lesz abszolút pontos az eredmény. A modell muködése ˝ egy tetsz˝oleges szolgáltatás igénylésénél a következ˝o lépésekre bontható. 1. A jogosult és autentikált felhasználó szolgáltatást igényel a mobil telekommunikációs hálózaton keresztül. 2. Amennyiben már igényel valamilyen szolgáltatást, és online módon számláz, úgy a 6. pont-tól folytatódik az algoritmus. 3. A rendszer kiszámolja az aktuálisan igényelt összes szolgáltatásra (beleértve a most igényelt szolgáltatást is) a mode-switching limitet. Amennyiben frekventált szolgáltatásokról van szó, ezen adatok rendelkezésre állhatnak, máskülönben lekérdezheti a szolgáltatás paramétereit (CAI) a szolgáltatást nyújtó hálózati elemt˝ol. 4. Ha a felhasználó számlája a mode-switching limit felett van, akkor offline számlázást alkalmaz (5. pont), ha az alatt, akkor online számlázást (6. pont). 5. Offline esetben a mode-switching limitet elraktározza, és amennyiben a felhasználó számlája a limit alá csökken, a rendszer átvált online számlázásra. 6. Online számlázás esetén visszakéri a felhasználó számláját a szolgáltatást nyújtó hálózati elemekt˝ol (amennyiben több igényelt szolgáltatás is van), és az új körülményeknek megfelel˝oen újból szétosztja azt. 7. A továbbiakban online számlázást alkalmaz. 8. Online esetben egy szolgáltatás terminálása esetén a rendszer újból kiszámolja a mode-switching limitet, majd a 4. pont-tól folytatja tovább a mu˝ ködését.

3.2. Analitikus megközelítés A megalkotott modell muködését ˝ a 3.1 fejezetben bemutattuk. A megalkotott modellben néhány paraméter pontosításra vár. Így analitikus megközelítést kíván a mód-váltást kiváltó pénz mennyiség (mode-switching limit) meghatározása, az elveszett adatok kezelése, valamint a QoS mérése. E paramétereket a szolgáltatásokra és a hálózatra jellemz˝o értékek függvényében adjuk meg.


50

Ahhoz, hogy pontosabb és általánosabb szemantikát tudjunk bevezetni, a felhasználó számláját nem pénzben, hanem egységekben, úgynevezett unit-okban definiáljuk. Az egyes szolgáltatások árát ezekben az egységekben mérjük. Az egységekb˝ol a valós pénzösszeg meghatározását átváltásnak (Rating) nevezzük.

3.2.1. A mode-switching limit meghatározása Ahhoz, hogy a megfelel˝o számolásokat el tudjuk végezni, be kell vezetni a unit fogyasztási sebességet (Unit Consumption Speed):

C(T ),

(3.1)

melynek mértékegysége a [unit/sec], jelentése az id˝oegység alatt elfogyasztott unit mennyiség. A fogyasztás sebessége függ az id˝ot˝ol, hiszen a terhelés kiegyenlítése érdekében a hálózatszolgáltatók különböz˝o árakat szabhatnak a szolgáltatásokhoz a nap és a hét különböz˝o id˝oszakaiban. A unit fogyasztási sebességb˝ol az id˝oegység alatt felhasznált pénz (money) és unit a következ˝o képlettel számítható ki:

unit = C(T ) · t,

(3.2)

money = unit · R(T ),

(3.3)

ahol R(T ) a unit és a valós pénz közötti átváltást jelöli. Látható, hogy mind a C(T ), mind az R(T ) függ az id˝ot˝ol. A unit fogyasztási sebesség id˝ofüggését célszeru ˝ a napszakok és a hétvégi / hétközi árkülönbségek meghatározására használni (csúcsid˝oben gyorsabban fogy a rendelkezésre álló egységek száma), míg az R(T ) id˝ofüggése a unit árban kifejezhet˝o értékét tükrözheti. Amennyiben a lekérdezéshez, számlaellen˝orzéshez szükséges id˝ot Tc -vel jelöljük, akkor a delegáláshoz tartozó limit (ideális esetben):

L = C(T ) · Tc .

(3.4)

Ha a számlánkon L-nél több unit van, akkor a számlázás offline módon történik, ellenkez˝o esetben valós ideju, ˝ online számlázást kell alkalmazni. Ha egyszerre több szolgáltatást igényelünk, akkor a limitet az igényelt szolgáltatásokhoz tartozó limitek összegeként határozhatjuk meg:

L=

X

Li .

(3.5)


51

Több szolgáltatás igénylése esetén a unitokat a fogyasztási sebességek arányában oszthatjuk szét a szolgáltatásokat nyújtó hálózati elemek között. A szolgáltatások befejeztével (vagy esemény alapú szolgáltatásokat igényelve) a megmaradt pénzt újra el kell osztani a szolgáltatások között. Amennyiben valamilyen szolgáltatáshoz nem lehet fogyasztási sebességet rendelni (például böngészés esetén), akkor valamilyen statisztikai módszerrel, modellel megbecsülhetjük azt – figyelembe véve a szolgáltatás tulajdonságait és a felhasználó viselkedését.

3.2.2. Valós eset Az ideális esett˝ol eltér˝oen az egyes hálózati eseményeknek (jelzés, lekérdezés) késleltetésük van, ami általános esetben nem is állandó. Ily módon, ha a módváltáshoz tartozó limitet pontosan szeretnénk meghatározni, a 3.4 egyenletet ki kell egészíteni, és számításba kell venni a lekérdezés (Tc ) és a delegálás (Td ) idejét, valamint ezen id˝ok változását (Tcj és Tdj ):

L = C(T ) · (Tc + Tcj + Td + Tdj ).

(3.6)

Amennyiben pontos számlázást szeretnénk, az egyes id˝ok változásánál (Tcj és Tdj ) a változás maximumával kell számolni. Ha a limitet csökkenteni szeretnénk – és ezáltal a hálózati overhead-en javítani – akkor a maximum helyett számolhatunk ennél kevesebb értékkel (például a várható értékkel), ekkor a változás eloszlásának függvényében bekövetkezhet, hogy a felhasználó a kifizetettnél több szolgáltatáshoz jut. Újraosztás esetén az egyes kontrollüzenetek váltását megfelel˝oen kell dokumentálni (id˝obélyeggel ellátni), hogy a mód-váltás ideje alatt igényelt szolgáltatásokat is megfelel˝oen számlázni lehessen.

3.2.3. A QoS mérése A QoS mérését több csomagon értelmezhetjük. Legyen az i-edik csomag küldési ideje ti , fogadási ideje tj . A QoS mérését csúszóablakos módszerrel végezhetjük, azaz mindig az utolsó N darab beérkezett csomagon vizsgálhatjuk. Ebben az esetben a szolgáltatások min˝oségének mér˝oszáma jól igazodik a felhasználó által tapasztalt min˝oséghez. Amennyiben N csomagon értelmezzük a QoS paramétereket az átlagos, a minimális, illetve a maximális késleltetést


52

P (tj − ti ) = , N = min(tj − ti ),

(3.7)

Dmax = max(tj − ti )

(3.9)

Davg Dmin

(3.8)

alakban számolhatjuk ki. A késleltetés jittere a maximális és minimális késleltetés különbsége:

Djitter = Dmax − Dmin .

(3.10)

A csomagvesztés N darab (helyesen) beérkezett, és M darab küldött csomag esetén

Loss =

3.2.4.

N . M

(3.11)

Hálózati overhead számítás

Jelölje ddata a hálózaton átfolyó hasznos adat mennyiségét. Jelölje továbbá a CDR méretét dcdr és a CDR generálását kiváltó adat mennyiségét tcdr . Így a számlázási információk és a hasznos adatmennyiség hányadosa (oof f line ), a következ˝o képlettel számítható ki offline esetben:

Oof f line =

ddata tcdr dcdr

ddata

=

dcdr , tcdr

(3.12)

ha a ddata -hoz, dcdr -hez és a tcdr -hez azonos mértékegységet használunk. Ehhez hasonlóan a számlázó, egység lefoglaló üzenetek (URM) és a hasznos adat hányadosa online esetben (oonline ):

Oonline =

ddata tur

· dur

ddata

=

dur , tur

(3.13)

ahol dur az egység lefoglaló üzenet mérete, és tur a delegált adatmennyiség. Mivel a CDR és a URM többé-kevésbé ugyanazon információkat tartalmazza, azzal a feltételezéssel éltünk, hogy méretük is megegyezik (dur = dcdr ). Mint említettük a rendszer a CDR-eket sokkal ritkábban (körül belül 3-10 percenként) küldi, mint a URM üzeneteket, így tur kisebb, mint tcdr , aminek következtében az online számlázás nagyobb hálózati overhead-et eredményez, mint az offline számlázás:


Oof f line =

dur dcdr < = Oonline . tcdr tur

53

(3.14)

A hasznos adat mennyisége, valamint a számlázási információ és a URM mérete magától érthet˝od˝oen byte-ban értelmezhet˝oek. A tcdr és a tur mennyiségek azonban ett˝ol eltér˝o dimenziójúak is lehetnek. Ahhoz, hogy e számításokat el tudjuk végezni ezen értékeket is byte-ban kell megadnunk. Mivel a szolgáltatás paramétereit általában ismerjük ez nem jelent gondot. Ha például a CDR küldését kiváltó esemény id˝otartam alapú, akkor a jelsebesség (kbit/sec) ismeretében tcdr könnyen megadható byte-ban is. Amennyiben egzakt jelsebesség nem rendelhet˝o a szolgáltatáshoz, úgy valamilyen statisztikai módszert kell alkalmaznunk, hogy a hálózati overhead-et becsülni tudjuk.

3.3.

Forgatókönyvek

Azért, hogy igazoljuk modellünk helyességét felvázolunk néhány forgatókönyvet (scenario). Az egyes forgatókönyvekhez analitikus módon kiszámoljuk és összehasonlítjuk a keletkez˝o hálózati overhead-eket minden számlázási módra. A számítások során a felhasználó számlája minden esetben 4 € -ról indul, és kétfajta, folyam (stream) alapú és esemény (event) alapú, szolgáltatást tud igénybevenni. Az els˝o forgatókönyvnél a felhasználó a számlája kiürüléséig folyamatosan egy folyam alapú szolgáltatást igényel. A második esetben a folyamatos streaming szolgáltatás mellett két esemény alapú szolgáltatás is megjelenik, még a harmadik esetben két másik folyam alapú szolgáltatást is igényel a már meglév˝o mellé. A negyedik forgatókönyvben a felhasználó befejezi a folyam alapú szolgáltatást, igényel egy esemény alapú-, majd ismét elindít egy folyam alapú szolgáltatást. Azért, hogy a számításokat el tudjuk végezni meg kellett határoznunk a szolgáltatások és a hálózat egyes paramétereit. E paraméterek nem feltétlenül egyeznek meg a valós életben létez˝o értékekkel, de meghatározásukkor törekedtünk, hogy lehet˝oség szerint közelítsük azokat. Az esetleges eltérések nem befolyásolják a modell validálását. A meghatározott paramétereket a 3.1 táblázat tartalmazza.

3.3.1. Egyszeru ˝ videó streaming Ebben a forgatókönyvben a felhasználó egy egyszeru ˝ folyam alapú szolgáltatást igényel számlája kiürüléséig. A 3.1 táblázatban szerepl˝o paraméterekkel egyszeru˝ en meghatározható a hálózati overhead mérete offline és online esetben, valamint a mode-switching limit a 3.12, 3.13 és a 3.6 egyenletek segítségével. Jelen esetben:


54

3.1. táblázat. A számításokhoz szükséges paraméterek A szolgáltatás adatai Folyam alapú szolgáltatás adatsebessége Folyam alapú szolgáltatás ára Esemény alapú szolgáltatás mérete Esemény alapú szolgáltatás ára

24576 0,0033333˙ 8192 0,1

bit/sec €/sec bit €

Az offline számlázás adatai Egy CDR mérete A CDR küldését kiváltó adatmennyiség

102400 7372800

bit bit

Az online számlázás adatai Egy UR üzenet mérete Egység visszaszolgáltatási üzenet mérete Allokált adatmennyiség

81920 81920 1474560

bit bit bit

A mode-switching számlázás adatai Számlalekérdezés és mód-váltás ideje (Tc + Tcj + Td + Tdj ) Újraszétosztást indukáló üzenet mérete (re-share)

7,5 8000

min bit

Oof f line = 102400/7372800 = 0, 01388,

(3.15)

Oonline = 81920/1474560 = 0, 05555,

(3.16)

L = 0, 2 · 7, 5 = 1, 5.

(3.17)

Amennyiben a felhasználónak 4 € van a számláján, húsz percnyi videót tud megtekinteni. Ezalatt a hálózat négy CDR-t vagy húsz UR üzenetet generál. Offline számlázás esetén a felhasználó számlája 900 másodperc után – miután a számlázóközpont megkapja a harmadik CDR-t – csökken 1,5 €, vagyis a kritikus érték alá. A mode-switching modellt alkalmazva három CDR és egy UR üzenet generálódik, így a hálózati overhead értéke:

Omode−switch = 0, 01319.

(3.18)

A 3.1 és 3.2 ábra a hálózati overhead mértékét szemlélteti az id˝o függvényében a szolgáltatás igénylés alatt – byte-ban és százalékos értékben. A grafikonok 10 másodperces felbontással készültek1 . A mode-switching modell overhead-je 1 az üzenetek küldésekor a hálózati overhead ugrásszeruen ˝ változik, a grafikonokon ferde vonalak a Microsoft Excel lineáris approximációja miatt keletkeztek


55

3.1. ábra. Az 1. forgatókönyvhöz tartozó hálózati overhead-ek mérete megegyezik az offline modell overhead-jével egészen addig, amíg a felhasználó számlája nem esik 1,5 € alá. A szolgáltatás befejeztével, 1200 másodperc után a mode-switching modell overhead-je kisebb, mint a két másik modell által generált hálózati adminisztrációs forgalom. Így elmondhatjuk, hogy a modell ebben az esetben jobban, gazdaságosabban muködik, ˝ mint az eddigi megoldások. A 3.1 ábrán látható, hogy a módváltás következtében egy újabb, egységlefoglalást megvalósító üzenet kerül elküldésre. Ezáltal a hálózati overhead az offline számlázás által okozott overhead-et rövid ideig meghaladja. Mivel a felhasználó egyetlen szolgáltatást igényel, a szolgáltatás a felhasználó számláján szerepl˝o összes pénzt megkapja, így több üzenet nem kerül átküldésre. A 3.2-es ábra a hálózati overhead arányát szemlélteti a hasznos adathoz képest. Mivel online számlázás esetén az egységlefoglaló üzenet a hasznos adat átvitele el˝ott kerül elküldésre, az online számlázás overhead/hasznos adat aránya kezdetben végtelen nagy. A 3.3-as ábra a felhasználó számláján szabadon felhasználható pénzt mutatja. A grafikonon a három vizsgált modell mellett a valós, ideális eset is szemléltetve van. Jól látható, hogy az offline számlázás a szolgáltatás igénylése után – vagy meghatározott mennyiségu ˝ szolgáltatás igénylése után – vonja le a pénzt a felhasználó egyenlegér˝ol. Így a felhasználónak soha nincs kevesebb felhasználható pénz a számláján mint ideális esetben. Online számlázás esetén a pénz el˝ore le van foglalva, így általában kevesebb (de maximum ugyanannyi) a felhasználható


56

3.2. ábra. Az 1. forgatókönyvhöz tartozó hálózati overhead-ek aránya a hasznos adathoz képest

3.3. ábra. Az 1. forgatókönyvhöz tartozó számla változás


57

pénz, mint ideális esetben. Leolvasható továbbá, hogy a mode-switching modellt alkalmazva a kritikus érték elérése esetén a felhasználó teljes számlája lefoglalásra kerül.

3.3.2. Videó streaming esemény alapú szolgáltatásokkal kombinálva A második forgatókönyvnél a felhasználó folyamatosan igényel egy folyam alapú, közben pedig 630 és 940 másodpercnél egy esemény alapú szolgáltatást. A modeswitching limit a folyam alapú szolgáltatásra 1,5 €, amit offline esetben 900 másodpercnél lép át a felhasználó. Így az els˝o esemény alapú szolgáltatást modeswitching el˝ott, még a másodikat mode-switching után igényli. A felhasználó tényleges (ideális) számlája 1140 másodperc után kiürül, így online és modeswitching esetben a szolgáltatás ekkor befejez˝odik, így ezek után már nem növekszik a hálózati overhead. Offline esetben további 60 másodpercig, az utolsó CDR beérkezéséig tovább folytatódik a szolgáltatás nyújtása. A hálózati overhead hasznos adathoz viszonyított százaléka, a grafikonról leolvasva:

Oof f line = 0, 020821766,

(3.19)

Oonline = 0, 064289889,

(3.20)

Omode−switching = 0, 026585787.

(3.21)

A forgatókönyvben offline esetben 6 CDR, online esetben 22 UR üzenet generálódott. A 3.3.1 fejezetben ismertetett számításhoz képest ez 2 CDR-rel, illetve 2 UR üzenettel többet jelent, ami az esemény alapú szolgáltatás igényléséhez kapcsolódik. A mode-switching modellt alkalmazva a kép sokkal árnyaltabb. Ebben a módban 4 CDR generálódik, majd 1 UR üzenet. A felhasználó ezek után igényli a második esemény alapú szolgáltatást, így szükséges egy újraszétosztást (re-share) indukáló üzenet, amelyet a folyam alapú szolgáltatásból visszamaradt pénz visszautalása követ. Ezután 2 UR üzenet következik: egy az esemény alapú szolgáltatásnak, egy pedig a folyam alapú szolgáltatásnak. Így összesen 4 CDR, 3 UR üzenet, 1 egység visszautaló és 1 re-share üzenet generálódik. A 3.4 és 3.5 ábráról leolvasható a CDR és UR üzenetek küldéséb˝ol származó hálózati overhead. Látható továbbá, hogy a mode-switching modellnél a kritikus id˝oszakban igényelt esemény alapú szolgáltatás szignifikáns overhead-et eredményezett. A 3.7 ábrát megtekintve megfigyelhet˝oek az esemény alapú szolgáltatás által indukált egyenleg változások. Megfigyelhet˝o továbbá, hogy offline számlázás esetén az utolsó CDR küldése után a felhasználó egyenlege negatívvá (−0.2 €ra változik), vagyis több szolgáltatást igényelt, mint amennyit szabadott volna. A


58

3.4. ábra. A 2. forgatókönyvhöz tartozó hálózati overhead-ek mérete másik két számlázási módnál ez a muködésb˝ ˝ ol adódóan nem lehetséges. A negatív egyenleg minden olyan esetben megjelenik, ahol a CDR küldésének ideje nem esik egybe a valós egyenleg kiürülésével, mivel az els˝o forgatókönyvnél ez egybeesett, az offline számlázás nem okozott negatív számlaegyenleget. Látható, hogy ebben a forgatókönyvben a mode-switching modell által generált hálózati overhead meghaladja az offline számlázás hálózati overhead-jét, de még mindig jóval az online mód által generált adminisztratív forgalom alatt marad. Mivel a mode-switching modell az offline számlázással szemben valós idejuséget ˝ biztosít, ezért a nagyobb overhead megbocsátható. Ha egynél jóval több esemény alapú szolgáltatást igényel a felhasználó, akkor el˝ofordulhat, hogy az overhead meghaladja az online számlázás overhead-jét. Annak valószínusége ˝ azonban, hogy a felhasználó számlája kiürülésének közelében egyszerre sok szolgáltatást kívánna igénybevenni viszonylag kicsi2 . Ebben az esetben a mode-switching modell öszszességében jobb teljesítményt mutat.

3.3.3.

Több folyam alapú szolgáltatás együttes igénylése

A forgatókönyvben a felhasználó a folyamatosan igényelt folyam alapú szolgáltatás mellett igényel további két, ugyancsak folyam alapú szolgáltatást. Ez a forgatókönyv könnyen megvalósítható, ha például a felhasználó egy telefonbeszélgetésbe 2a

dolgozat írójának véleménye szerint


59

3.5. ábra. A 2. forgatókönyvhöz tartozó hálózati overhead-ek aránya a hasznos adathoz képest

3.6. ábra. A 2. forgatókönyvhöz tartozó számla változás


60

további két résztvev˝ot hív meg. Az el˝ofizet˝o a második folyam alapú szolgáltatást 160, még a harmadik szolgáltatást 560 másodpercnél igényli. Egy szolgáltatásnál a mode-switching limit 1,5 €, a második szolgáltatás beindításánál pedig a felhasználó számláján 4 € található. Így ekkor még offline módban, CDR-ek átvitelével történik a számlázás. A második szolgáltatással együtt a limit 3 €-ra változik, így a harmadik szolgáltatás már egység lefoglalás után indul. Valós ideju ˝ számlázás esetén a szolgáltatás 640 másodperc után, nem valós ideju ˝ számlázást alkalmazva 770 másodperc után áll le. A hálózati overhead-ek a grafikonról leolvasva:

Oof f line = 0, 01572327,

(3.22)

Oonline = 0, 063888889,

(3.23)


(3.24)

Offline esetben 6 CDR, online esetben 22 UR üzenet generálódik. A mode-switching modellnél a harmadik szolgáltatás igénylése el˝ott 2 CDR és 2 UR üzenet halad át a hálózaton. A harmadik szolgáltatás beindításánál a 2 re-share üzenetet 2 egységfelszabadító és 3 UR üzenet követi. Az overhead-eket szemléltet˝o grafikonokról (3.7 és 3.8 ábra) leolvasható, hogy több szolgáltatás folyamatos igénylésénél egy újabb szolgáltatás beindítása a többi számlázási módhoz képest a mode-switching modellnél – a kritikus értéknél kisebb felhasználói egyenleg esetén – hatalmas hálózati overhead-et eredményez. Jelen forgatókönyvnél modellünk overhead-je az offline és online számlázás overhead-je között van, de extrém esetben (mint ahogy a 3.3.2 fejezetben is) meghaladhatja az online számlázás által generált adminisztrációs üzenetek méretét. A felhasználó számláját reprezentáló grafikonon (3.9 ábra) látható, hogy a második szolgáltatás igénylése után egyik számlázási módnál sem egyezik meg a felhasználó számlája az ideális számlaegyenleggel – kivéve természetesen a kiürült számlát. Ez abból fakad, hogy az egyes szolgáltatásokhoz tartozó CDR-ek, illetve UR üzenetek nem egyszerre generálódnak, így minden id˝opontban van olyan szolgáltatás, ami még nincs kifizetve, illetve amihez tartozik még felhasználható pénzegység. Mivel a CDR generálások ideje nem esik egybe a számla kiürülésével, itt is megjelenik negatív számlaegyenleg.

3.3.4. Megszakított folyam alapú szolgáltatás A forgatókönyvben a felhasználó a folyamatosan igényelt folyam alapú szolgáltatást a 960. másodpercnél megszakítja, majd egy esemény alapú szolgáltatás után ismét elindítja. Az esemény alapú szolgáltatás igénylése a 990. másodpercnél, a folyam alapú szolgáltatás újraindítása az 1030. másodpercnél történik.


61

3.7. ábra. A 3. forgatókönyvhöz tartozó hálózati overhead-ek mérete



62

3.9. ábra. A 3. forgatókönyvhöz tartozó számla változás Ennél az esetnél két id˝ointervallum is el˝ofordul, amikor a felhasználó nem igényel semmilyen szolgáltatást. Mind az els˝o szolgáltatás leállítása, mind az esemény-, mind a második folyam alapú szolgáltatás igénylése a kritikus id˝oszakban, a 900. másodperc után történik, de mivel az esemény alapú szolgáltatás igénylésekor nincs folyamatos szolgáltatás, annak számlázása történhet offline módon – az esemény alapú szolgáltatás mode-switching limit-je kicsi. A számlázási módok overhead-jei a grafikonokhoz tartozó adatokból kiolvasva:

Oof f line = 0, 019679874,

(3.25)

Oonline = 0, 062660211,

(3.26)


(3.27)

Offline esetben 6 CDR, online esetben 21 UR üzenet, és egy egység visszaszolgáltató üzenet, a mode-switching limitet alkalmazva pedig négy CDR, két UR üzenet, és egy egység visszaszolgáltató üzenet generálódik. A 3.10 és 3.11 grafikonokat tekintve látható, hogy amennyiben nincs folyamatos szolgáltatás, a mode-switching modellel kapott overhead nem tér el szignifikánsan az offline számlázáshoz tartozó overhead-t˝ol. A számlát reprezentáló grafikonon (3.12 ábra) pedig megfigyelhet˝o, hogy a felhasználó számlája két id˝ointervallumban – amikor nem igényel semmilyen szolgáltatást – minden számlázási módban megegyezik az ideális számlaértékkel. A mode-switching modellnél megfigyelhet˝o továbbá, hogy az els˝o folyam alapú szolgáltatás befejeztekor a felhasználó számlája felszabadul.


63

3.10. ábra. A 4. forgatókönyvhöz tartozó hálózati overhead-ek mérete



64

3.12. ábra. A 4. forgatókönyvhöz tartozó számla változás

3.4.

Szimulációs vizsgálat

A modell verifikálására elkészítettük a rendszer quantitatív modelljét. A szimulációs környezet megalkotása során ügyeltünk arra, hogy az lehet˝oség szerint illeszkedjen a logikai tervhez, de természetesen magasabb absztrakciós szinten alkottuk meg azt. Azon egységeket, amelyek nem lényegesek, a szimuláció során leegyszerusítettük, ˝ és els˝osorban a modell muködésére ˝ koncentráltunk. A szimulációt objektum orientált környezetben, JAVA nyelven implementáltuk. A programban felhasznált objektumok a valós világ fizikai entitásait modellezik, így a következ˝o osztályokat hoztuk létre: Clock A központosított órát megvalósító osztály. Az MS osztály objektuma ez alapján az óra alapján indítja el a különböz˝o igényeket, valamint az események bekövetkeztét is ez alapján az óra alapján dokumentáljuk. MS A felhasználót, illetve a felhasználó végberendezését modellez˝o osztály. A szolgáltatások igénylését végzi, valamint fogadja a hálózat fel˝ol érkez˝o adatokat. GSN A hálózat csomópontjait (bázisállomás, SGSN, GGSN) megvalósító osztály. Lényegében csak igényeket és adatokat továbbít a megfelel˝o elemnek. AS Az alkalmazásszolgáltatót megvalósító osztály. A felhasználói igények beérkezése után adatot szolgáltat, és a számlázási mód függvényében számlázza a szolgáltatást.


65

3.13. ábra. A szimulált architektúra CGF A CDR-ek továbbítását megvalósító osztály, online számlázás esetén nincs szerepe. Lényegében az AS osztály objektumaitól kapott CDR-eket továbbítja a számlázóközpontnak. BS A számlázórendszert megvalósító osztály. Muködése ˝ a számlázási módtól függ. A szimuláció során a GSN osztályból 3 objektumot (bs, sgsn, ggsn), az AS osztályból 4 objektumot (as1, as2, as3, as4) példányosítottunk. A többi osztálynak egyetlen objektuma van a szimulációban. Az objektumokat, és azok kapcsolatát a 3.13 ábra szemlélteti. Az ábrán az entitásokat az objektumnév:osztálynév konvencióval címkéztük fel. A szimuláció elemeinek leírását b˝ovebben a 3.4.1 fejezet tartalmazza. A szimuláció megvalósítása során nem foglalkoztunk a csomagvesztéssel és az esetleges adathibákkal, újraküldésekkel. Amennyiben a folyam alapú szolgáltatások beszédhez, vagy videó-streaming-hez kapcsolódnak, és az adminisztrációs üzenetek megfelel˝o hibavédelemmel vannak ellátva, úgy ez a feltételezés nem jelent lényegi korlátozást. További egyszerusítés, ˝ hogy a CDR-eket egyszeruen ˝ a kibocsátó entitás azonosítójával és a levonandó pénzösszeggel helyettesítettük. Az alkalmazásszerverek által küldött csomagok mérete nem konstans, a csomagméret meghatározásakor véletlen elemet, értéket (Math.random) is felhasználtunk. A csomagok késleltetésére, minden egyes továbbküldésnél, a JAVA nyelvben implementált várakozást (Thread.sleep) használtuk fel. Elég kis értéket adva a függ-


66

vénynek, a várakozási id˝o elég sztochasztikus képet mutatott. A megírt alkalmazás a kimenetén megjelenítette a mobil készülék (ms objektum) által kapott adatok méretét, valamint az egyes eseményeket és számlázási üzeneteket. Egy példafuttatás kimenetét tartalmazza a 3.4.2-es alfejezet.

3.4.1. Az objektumok muködése ˝ A GSN és CGF osztályok muködése ˝ viszonylag egyszeru. ˝ Az objektumok eseményvezéreltek, és lényegében nincs más feladatuk, mint a hozzájuk érkez˝o üzenetek (adatcsomag, események, CDR-ek), megfelel˝o késleltetés után történ˝o továbbítása. A Clock, MS és AS osztályok a Thread osztályt egészítik, b˝ovítik ki, külön eseményszálon futnak. A Clock osztály lényegében egy, a szimulációs id˝ot mutató attribútumot növel folyamatosan. Az MS osztály a beprogramozott id˝oben (amelyet a Clock osztály objektumától vesz) bizonyos eseményeket indukál, melyek a GSN osztály objektumain keresztül eljutnak az AS osztály megfelel˝o objektumához. Az AS osztály objektuma az esemény hatására adatokat küld – szintén a GSN osztály objektumain keresztül – a mobil készüléknek. A BS osztály eseményvezérelt, feladata a felhasználó számlájának menedzselése, a CDR-ek feldolgozása, valamint az online számlázás megvalósítása. Az AS, valamint a BS osztály muködése ˝ az egyes számlázási módokban eltér, ezeket a következ˝o alfejezetekben részletezzük.

Az offline számlázás megvalósítása Az AS osztály a megfelel˝o igény hatására adatcsomagokat generál. Az adatcsomag méretét az el˝oz˝o adatcsomag küldését˝ol eltelt id˝o, az adási sebesség, valamint egy véletlen érték alapján határozza meg. Az elküldött adatcsomagok méretét folyamatosan összeadja, és amennyiben ez nagyobb, mint a CDR küldését kiváltó érték (lásd 3.1 táblázat), úgy kiszámolja az elküldött adat értékét, és ezt továbbítja a CGF osztály objektumának, majd nullázza az elküldött adat mennyiségét. A folyam alapú szolgáltatás leállításakor szintén kiszámítja az addig (az utolsó nullázás óta) elküldött adat értékét, és továbbítja a CGF objektumán keresztül a számlázóközpontba. Esemény alapú számlázás esetén elküldi a megfelel˝o adatmennyiséget a felhasználónak, és a szolgáltatás árát a CGF objektumának. A számlázóközpont fogadja a CGF objektumától a regisztrált értékeket, és folyamatosan csökkenti ezzel a felhasználó számláját. Amennyiben a számla kiürül (nulla, vagy annál kisebb lesz), úgy leállítja az összes szolgáltatást.


67

Az online számlázás megvalósítása Online számlázás esetén az AS osztály objektumai nyilvántartanak egy bels˝o számlát, ami a számlázóközpont által delegált unit mennyiségét reprezentálja. Folyam alapú szolgáltatás esetén, a küldött adatcsomagok méretét az osztály az el˝oz˝o alfejezetben bemutatott módon számítja ki. Ha a felhasználónak van annyi unit a bels˝o (az AS objektumában nyilvántartott) számláján, amennyibe a csomag küldése kerülne, úgy a csomagot továbbítja a hozzá kapcsolódó GSN objektumnak (ggsn), és az értékét levonja a számláról. Amennyiben nincs ennyi unit a bels˝o számlán, úgy a számlán szerepl˝o összegnek megfelel˝o mennyiségu ˝ adatot küld a felhasználónak, és nullázza a bels˝o számlát. Ha a számla egy meghatározott összeg (0, 02 €) alatt van, úgy újabb összeget (0, 2 €) kér a számlázóközponttól. A szolgáltatás leállításánál a számlán szerepl˝o összeget visszajuttatja a BS objektumának. Esemény alapú szolgáltatásnál az objektumok a szolgáltatás árának megfelel˝o összeget foglalnak le a számlázóközponttól. Amennyiben ez az összeg a rendelkezésükre áll, úgy elküldik a megfelel˝o mennyiségu ˝ adatot a felhasználónak, ha nem, akkor visszautalják a kapott pénzt. A számlázóközpont egységlefoglalás esetén a felhasználó számláját lecsökkenti a kért értékkel – amennyiben van ennyi pénz a számlán, és az értéket elküldi a megfelel˝o alkalmazásszervernek. Ha a felhasználó számláján nincs ennyi pénz, úgy a teljes számlát delegálja az AS objektumának, és nullázza a számlát. Egység visszajuttatás esetén a felhasználó számláját növeli az adott, visszajuttatott értékkel.

A mode-switching modell megvalósítása Mode-switching modellt alkalmazva az AS osztályban mind az offline, mind az online számlázásnak megfelel˝o muködés ˝ meg van valósítva, azzal a módosítással, hogy online számlázás esetén az alkalmazásszolgáltató az összes felhasználható unit-ot megkapja. Az objektumok a bels˝o számla mellett nyilvántartják azt is, hogy offline, vagy online számlázást kell alkalmazni, és a számlázási információk küldését, a bels˝o számla kezelését ennek függvényében végzik. Szolgáltatás indításánál a szolgáltatás paramétereit elküldik a számlázóközpontnak, amely ezek után közli az elemekkel a számlázás módját. Szolgáltatás leállításánál egy utolsó CDR küldése, vagy a bels˝o számlán szerepl˝o összeg visszajuttatása történik meg – szintén a számlázási mód függvényében. Leállításnál szintén közlik a terminálás tényét a számlázóközponttal, hogy az csökkenteni tudja a nyilvántartott modeswitching limitet. Az objektumok ezen felül tartalmazzák az offline-ról online számlázásra, és az online-ról offline számlázásra való áttérést megvalósító függvényeket. Az els˝o esetben a szolgáltatás bels˝o számláját csökkentik az utolsó CDR küldés óta elküldött adat mennyiségének értékével, utóbbi esetben egyszeruen ˝


68

visszajuttatják a lefoglalt összeget. Mindkét esetben a függvények beállítják a számlázási módot jelz˝o attribútumot. Újraosztás kérése esetén a számla 0, 02 € feletti részét visszautalják a számlázóközpontnak. Az esemény alapú szolgáltatás igénylése az el˝oz˝o alfejezetekben bemutatott módon, a számlázás módjától függ˝oen történik. A számlázóközponttal tudatni kell a szolgáltatások beindítását, terminálását, valamint a szolgáltatások paramétereit, a unit fogyasztási sebességet. Szolgáltatás regisztrálásnál a központ növeli a mode-switching limitet (amely kezdetben nulla), és online mód esetén újraosztást (re-share) kér a szolgáltatásokat nyújtó alkalmazásszerverekt˝ol. Offline mód esetén, amennyiben a felhasználó számlája kisebb, mint az újonnan meghatározott limit, úgy az alkalmazásszerverek számlázási módját online-ra állítja. Szolgáltatás leállítása esetén a mode-switching limitet csökkenti, online számlázás esetén pedig újraosztást kér az AS objektumaitól. Az eddigi számlázási mód, a felhasználó számlája, és az új limit függvényében az alkalmazásszerverek számlázási módját a megfelel˝o módra állítja. Az újraosztás után a szolgáltatások paramétereinek (a mód-váltó limit rájuk es˝o hányadának) függvényében szétosztja a felhasználó számláját a szolgáltatásokat nyújtó elemek között. CDR beérkezése esetén a felhasználó számláját a központ csökkenti a megfelel˝o értékkel, és megfelel˝o esetben átváltja online számlázásra az alkalmazásszervereket. Online számlázás, és esemény alapú szolgáltatás igénylése esetén újraosztás kérése, és az új számlaértéknek megfelel˝oen a számla újbóli szétosztása történik.

3.4.2. A szimulációk kimenetei Mivel a dolgozat megírása során összesen 12 szimulációt futtattunk (négy forgatókönyv, három számlázási mód), az összes szimuláció kimenetének bemutatása terjedelmi korlátok miatt nem lehetséges. Példaképpen a harmadik forgatókönyv (több folyam alapú szolgáltatás együttes igénylése) mode-switching számlázással történ˝o futtatási eredményét mutatjuk be. A 3.4.3 fejezet tartalmazza a futtatási eredmények összegzését az összes forgatókönyvre és számlázási módra. Az események leírásánál AS1, AS2 és AS3 rendre az els˝o, a második, illetve a harmadik alkalmazásszervert, illetve az általa nyújtott szolgáltatást jelenti. A példafuttatás kimenetén megjelentek a felhasználónak küldött adatokhoz tartozó eredmények is, ezeket terjedelmi és átláthatósági okokból itt nem közöljük. A 3.4.2 táblázat tartalmazza tehát az egyes események idejét (id˝o), a felhasználó aktuális számlaegyenlegét (számla), valamint az esemény szöveges leírását (esemény). Itt jegyezzük meg, hogy a szimuláció során – a véletlen értékek és a terjedési késleltetés miatt – a felhasználó számlája már az els˝o CDR beérkezése után a két


69

folyam alapú szolgáltatáshoz tartozó 3 €-s limit alá csökken. Emiatt a 3.3.3 fejezetben bemutatott forgatókönyvt˝ol eltér˝oen, már a 299. másodpercnél megtörténik a mód-váltás, így összesen egy CDR generálódik a hálózatban. A többi szimulációs futtatás során a 3.3-as fejezetben kiszámolt mennyiségu ˝ számlázási információ érkezik a számlázóközpontba. A szimulációs futtatás összegzését a 3.4.3 fejezetben megtalálható 3.4.3-ös táblázat „Mode-switching” sorai tartalmazzák.

id˝o 0 0 0 160 160 161 299 299 299 299 560 560 560 561 561 561 561 561

számla 4,0 4,0 4,0 4,0 4,0 4,0 2,99998 2,99998 2,99998 2,99998 0,0 0,0 0,0 0,77223 0,77223 0,77223 0,77223 0,0

3.2. táblázat. A szimuláció egyik kimenete esemény A felhasználó AS1 szolgáltatását igényli A mode-switching limit 1,5 €-ra változik AS1 megkezdi a szolgáltatás nyújtását A felhasználó AS2 szolgáltatását igényli A mode-switching limit 3 €-ra változik AS2 megkezdi a szolgáltatás nyújtását AS1 fel˝ol az els˝o CDR beérkezése a számlázó központba Módváltás indukálása AS1-nek 1,49999 € delegálása AS2-nek 1,49999 € delegálása A felhasználó AS3 szolgáltatását igényli A mode-switching limit 4,5 €-ra változik Újraosztás kérése a két alkalmazásszervert˝ol A visszaérkez˝o unit-ok összegzése AS1-nek 0,25741 € delegálása AS2-nek 0,25741 € delegálása AS3-nek 0,25741 € delegálása AS3 megkezdi a szolgáltatás nyújtását

3.4.3. A szimulációk eredményei A következ˝o fejezetek a szimulációs futtatások eredményeit tartalmazzák. A táblázatok fejlécében terjedelmi okokból csak rövid (angol nyelvu) ˝ utalásokat helyeztünk el. A táblázatok oszlopainak (és így a táblázatokban szerepl˝o értékek) leírása a következ˝o felsorolásban található meg: mode A számlázás módja. Lehet offline, online, vagy mode-switching. stream A folyam alapú szolgáltatások által, a felhasználónak küldött adatok mérete bit-ben. packet A folyam alapú szolgáltatások által, a felhasználónak küldött adatcsomagok darabszáma.


70

time Az utolsó beérkezett adatcsomag ideje (másodpercben). event Az igényelt esemény alapú szolgáltatások darabszáma. stream price A folyam alapú szolgáltatások által küldött összes adat értéke (euroban). event price Az esemény alapú szolgáltatások összértéke (euro-ban). sum price A felhasználó által igényelt összes szolgáltatás összértéke (euro-ban). CDR A szolgáltatások nyújtása során keletkezett CDR-ek darabszáma. URM A szolgáltatások nyújtása során keletkezett egységlefoglaló üzenetek darabszáma. back Az alkalmazásszerverek feleslegessé vált lefoglalt egységeit a számlázóközpontba visszajuttató üzenetek darabszáma. re-share Újraosztást indukáló üzenetek darabszáma. size A számlázási információk összmérete (szükséges adatok a 3.1 táblázatban). percent A számlázási információk hasznos adathoz viszonyított százalékos értéke (szükséges adatok a 3.1 táblázatban).

3.3. táblázat. Az els˝o forgatókönyv szimulációjának eredményei mode stream (bit) packet (pcs) time (sec) event (pcs) Offline 29540461 1100 1217 0 Online 29391618 893 1207 0 Mode-switching 29441595 1006 1204 0 mode Offline Online Mode-switching mode Offline Online Mode-switching

stream price (€) 4,006681451 3,986493327 3,993271891 CDR 4 0 3

URM 0 20 1

event price (€) 0 0 0 back 0 0 0

re-share 0 0 0

sum price (€) 4,006681451 3,986493327 3,993271891 size (bit) 614400 1802240 675840

percent (%) 1,386572809 5,574378382 1,321667525


71

3.4. táblázat. A második forgatókönyv szimulációjának eredményei mode stream (bit) packet (pcs) time (sec) event (pcs) Offline 29516485 985 1217 2 Online 27918400 907 1141 2 Mode-switching 28000700 868 1162 2 mode Offline Online Mode-switching mode Offline Online Mode-switching

stream price (€) 4,003429498 3,786675347 3,797837999 CDR 6 0 4

URM 0 22 3

event price (€) 0,2 0,2 0,2 back 0 0 1

re-share 0 0 1


percent (%) 2,080393882 6,451598122 2,631537243

3.5. táblázat. A harmadik forgatókönyv szimulációjának eredményei mode stream (bit) packet (pcs) time (sec) event (pcs) Offline 38363142 1331 767 0 Online 29147241 1010 658 0 Mode-switching 29564628 970 647 0 mode Offline Online Mode-switching mode Offline Online Mode-switching

stream price (€) 5,203334147 3,953347575 4,00995931 CDR 6 0 1

URM 0 22 5

event price (€) 0 0 0 back 0 0 2

re-share 0 0 2


percent (%) 1,601537225 6,183226742 2,285974983


72

3.6. táblázat. A negyedik forgatókönyv szimulációjának eredményei mode stream (bit) packet (pcs) time (sec) event (pcs) Offline 30671601 935 1335 1 Online 28655565 1076 1241 1 Mode-switching 28706186 908 1249 1 mode Offline Online Mode-switching mode Offline Online Mode-switching

stream price (€) 4,160102132 3,886659749 3,893525662 CDR 6 0 4

URM 0 21 2

event price (€) 0,1 0,1 0,1 back 0 1 1

re-share 0 0 0


percent (%) 2,002621074 6,287521904 2,282340923

4. fejezet

Összefoglalás Dolgozatunkban áttekintettük az UMTS környezetben kialakulni látszó paradigmaváltás motivációit, a rendszerben megvalósítható új szolgáltatásokat és funkciókat. A paradigmaváltás során a szolgáltatások nyújtását a hálózatoperátortól küls˝o tartalomszolgáltatók veszik át, nagyobb és változatosabb skálát biztosítva ezzel az el˝ofizet˝ok részére az elérhet˝o szolgáltatások terén. A küls˝o szolgáltatók megjelenése a piacon több jogi és technológiai problémát vet fel. A hálózatoperátor és a tartalomszolgáltatók között pontos (de a felhasználók személyiségi jogait tiszteletben tartó) megegyezés és szerz˝odés kell, hogy a megfelel˝o pénzügyi tranzakciókat meg tudják valósítani. A jogi problémák mellett meg kell oldani a szolgáltatások mennyiségének és min˝oségének pontos mérését áramkörkapcsolt rendszer helyett csomagkapcsolt, IP alapú környezetben. A dolgozat részletezi a mérés megvalósításának nehézségeit, valamint egy lehetséges modellt ad a felsorolt problémák megoldására. A probléma komplexitását igazolja, hogy a diplomamunkához kapcsolódó kutatásokat az ETIK (Egyetemközi Távközlési és Informatikai Központ), és ipari partnerek támogatták. Az általunk megalkotott modell lényege, hogy a számlázás id˝obeliségét (offline illetve online) dinamikusan változtatja a felhasználó egyenlegének és az igényelt szolgáltatások paramétereinek függvényében. További kiegészítésként online számlázás esetén a teljes felhasználható összeget delegálhatjuk a szolgáltatást nyújtó hálózati elemnek. Több szolgáltatás esetén az összeget a szolgáltatások különböz˝o paramétereinek függvényében oszthatjuk szét. Ezekkel a megoldásokkal a legtöbb el˝ofizet˝o az eddig alkalmazott online számlázásnál kisebb hálózati overhead-del számlázható valós id˝oben. A modell megoldást ad a szolgáltatások mérésének módjára is. Az IP alapú QoS mérés lényege, hogy a beérkezett IP csomagok halmazán értelmezzük a megfelel˝o QoS paramétereket, és e paraméterek segítségével határozzuk meg a szolgáltatás min˝oségét. 73

4. FEJEZET. ÖSSZEFOGLALÁS

74

Dolgozatunk végén a megalkotott modell analitikus elemzését, szimulációját, és annak eredményeit mutattuk be. Az eredmények feldolgozása során az el˝oz˝o fejezetekben látott felvetések, problémák beigazolódtak. Az online számlázás nagy overhead-et, de pontos számlázást biztosít. Offline módszerrel a pontos számlázás nem megoldható, a felhasználó a kifizetettnél jóval több szolgáltatást tud igénybevenni, de a hálózati overhead az online számlázásnál kapott overheadnél lényegesen kisebb. Modellünk alkalmazásával a pontos számlázás az online számlázásnál (általános esetben) jóval kisebb hálózati overhead-del megoldható, igaz, a modell használata a hálózati elemek komplexebb funkcionalitását kívánja meg. Ily módon látható, hogy az optimális megoldás megtalálásának feltétele a megfelel˝o igények pontos felmérése. A valós és optimális rendszer megalkotásához – mint mindig – kompromisszumokra kényszerülünk. Az UMTS rendszer számlázásának kidolgozásához szükséges még az adatfolyam mérésének pontos kidolgozása, és a szolgáltatások min˝oségének származtatása az adatfolyam min˝oségéb˝ol. Ahhoz, hogy ezt pontosan meg tudjuk tenni, meg kell határozni az egyes szolgáltatások és a felhasználók statisztikai paramétereit/viselkedését (például böngészés esetére). A helyes muködés ˝ matematikai igazolásához a modell pontosabb és kiterjedtebb analitikus vizsgálata szükséges. Modellünk gyakorlatban történ˝o megvalósíthatóságához pedig fel kell mérni az elérhet˝o hardware-elemek pontos funkcionalitását. Megoldásra váró feladatok emellett még: • A küls˝o, harmadik felek szolgáltatásnyújtásának megoldása. • A diplomamunkában szerepl˝o modell muködéshez ˝ szükséges protokollok pontos leírása, definiálása. • A csomagkapcsolt, IP alapú adatmérés megvalósítása, amely képes több különböz˝o felhasználót és szolgáltatást kezelni. Megoldja a mobilitásból, csomagvesztésb˝ol, csomagduplázásból adódó problémákat, és lehet˝oleg kis hálózati overhead-et eredményez. • IP alapú min˝oségmérés pontos, részletes kidolgozása. • A CDR-ek számlázáson túli felhasználásának kimerít˝o vizsgálata. • Olyan számlázóközpont muködésének ˝ pontos kidolgozása, amely képes kezelni a különböz˝o számlázási módokat, flexibilis, magas szintu ˝ nyelvel képes a szolgáltatások számlázásának minél szélesebb skáláját biztosítani egy több el˝ofizet˝os és több szolgáltatásos környezetben.

Rövidítések jegyzéke 2G 3G 3GPP AAA ABMF AN AoC API ARPU AS AVP BGCF BS BS CAI CAMEL CAPEX CCF CDF CDR CDR CGF CN CRM CTF CS CSCF CSD Diffserv EBC EBCF ECUR

2nd Generation 3rd Generation 3rd Generation Partnership Project Authentication, Authorization and Accounting Account Balance Management Function Access Network Advice of Charge Application Programming Interface Average Revenue Per User Application Server Attribute Value Pair Breakout Gateway Control Function Base Station Billing System Charge Advice Information Customized Applications for Mobile network Enhanced Logic CAPital EXpanditure Charging Collection Function Charging Detail Function Call Detail Record Charging Data Record Charging Gateway Function Core Network Customer Relationship Management Charging Trigger Function Circuit Switched Call Session Control Function Circuit Switched Data Differentiated Services Event Based Charging Event Based Charging Function Event Charging with Unit Reservation 75

RÖVIDÍTÉSEK JEGYZÉKE ETIK FTP GGSN GMSC GPRS GSM GSN GTP HLR HND IEC IETF IM IM IMS GWF IMS Intserv IP IPv4 IPv6 ISP LBC MGCF MMS MOU MPLS MRFC MS MSC OCF OCS OPEX OSA PDP PLMN PoC PS PSTN PTT QoS Radius RF RTP

Egyetemközi Távközlési és Informatikai Központ File Transfer Protocol Gateway GPRS Support Node Gateway Mobile Switching Centre General Packet Radio Services Global System for Mobile Communications GPRS Support Node GPRS Tunnelling Protocol Home Location Register Home Network domain Immediate Event Charging Internet Engineering Task Force Instant Messaging IP Multimédia IMS Gateway Function IP Multimedia Subsystem Integrated Services Internet Protocol Internet Protocol version 4 Internet Protocol version 6 Internet Service Provider Location Based Services Media Gateway Control Function Multimedia Messaging Service Minutes Of Use Multi Protocol Label Switching Media Resource Function Controller Mobile Station Mobile Switching Centre Online Charging Function Online Charging Centre OPeration EXpenses Open Service Access Packet Data Protocol Public Land Mobile Network Push-To-Talk over Cellular Packet Switched Public Switched Telephone Network Push-To-Talk Quality of Service Remote Authentication Dial In User Service Rating Function Real-time Transport Protocol

76

RÖVIDÍTÉSEK JEGYZÉKE SBC SBCG SCF SCTP SCUR SGSN SIM SIP SMS SND SNMP TAP TCP TIPHON TND UMTS UR URM VBR VHE VoIP WLAN

77

Session Based Charging Session Based Charging Function Service Capability Features Stream Control Transmission Protocol Session based Charging with Unit Reservation Serving GPRS Support Node Subscriber Identity Module Session Initiation Protocol Short Message Service Serving Network domain Simple Network Management Protokol Transfer Account Procedure Transmission Control Protocol Telecommunications and Internet Protocol Harmonization Over Networks Transit Network domain Universal Mobile Telecommunication System Unit Reservation Unit Reservation Message Vary Bit Rate Virtual Home Environment Voice over IP Wireless Local Area Network

Publikációk jegyzéke Jelen fejezet a diplomamunkához kapcsolódó publikációimat sorolja fel. A publikációk letölthet˝oek a http://official.isolation.hu weboldalról. Szerz˝ok Konferencia Szekció Helyezés Cím Dátum Nyelv

: : : : : : :

Ary Bálint Dávid és Debrei Gábor Országos Tudományos Diákköri Konferencia 2005 Kommunikációs hálózatok és szolgáltatások 2. helyezés UMTS rendszerek valós ideju ˝ számlázása 2005 Március Magyar

Szerz˝ok Folyóirat Cím Dátum Nyelv

: : : : :

Ary Bálint Dávid és dr. Imre Sándor Híradástechnika, LX. évfolyam 1. szám, p25-29 Valós ideju ˝ számlázás mobil környezetben 2005 Január Magyar

Szerz˝o Konferencia Szekció Cím Dátum Nyelv

: : : : : :

Ary Bálint Dávid Digital Technologies 2004 Optical and Wireless Technologies Real-time Charging in UMTS Environment 2004 December Angol

Szerz˝ok Konferencia Szekció Helyezés Cím Dátum Nyelv

: : : : : : :

Ary Bálint Dávid és Debrei Gábor BME Tudományos Diákköri Konferencia 2004 Hálózatmenedzsment 1. helyezés UMTS rendszerek valós ideju ˝ számlázása 2004 November Magyar

78

PUBLIKÁCIÓK JEGYZÉKE Szerz˝ok Folyóirat Cím Dátum Nyelv

: : : : :

Ary Bálint Dávid és dr. Imre Sándor Magyar Távközlés, XV. évfolyam 2. szám, p29-32 UMTS rendszerek valós ideju ˝ számlázásának problémái 2004 Július Magyar

79

Táblázatok jegyzéke 3.1. A számításokhoz szükséges paraméterek . . . . . . . . . . . . . . . .

54

3.2. A szimuláció egyik kimenete . . . . . . . . . . . . . . . . . . . . . . . .

69

3.3. Az els˝o forgatókönyv szimulációjának eredményei . . . . . . . . . . .

70

3.4. A második forgatókönyv szimulációjának eredményei . . . . . . . . .

71

3.5. A harmadik forgatókönyv szimulációjának eredményei . . . . . . . .

71

3.6. A negyedik forgatókönyv szimulációjának eredményei . . . . . . . . .

72

80

Ábrák jegyzéke 1.1. Hálózatoperátor centrikus üzleti modell . . . . . . . . . . . . . . . . .

15

1.2. Szolgáltatás aggregáló centrikus üzleti modell . . . . . . . . . . . . .

16

1.3. Alkalmazásszolgáltató centrikus üzleti modell . . . . . . . . . . . . .

17

1.4. Rejtett hálózatoperátor modell . . . . . . . . . . . . . . . . . . . . . . .

17

1.5. Az UMTS architektúra tagolása . . . . . . . . . . . . . . . . . . . . . .

18

1.6. Az áramkörkapcsolt alrendszer architektúrája . . . . . . . . . . . . .

19

1.7. A csomagkapcsolt alrendszer architektúrája . . . . . . . . . . . . . .

21

1.8. Az IM alrendszer architektúrája . . . . . . . . . . . . . . . . . . . . . .

22

3.1. Az 1.forgatókönyvhöz tartozó hálózati overhead-ek mérete . . . . . .

55

3.2. Az 1.forgatókönyvhöz tartozó hálózati overhead-ek aránya a hasznos adathoz képest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

3.3. Az 1.forgatókönyvhöz tartozó számla változás . . . . . . . . . . . . . .

56

3.4. A 2.forgatókönyvhöz tartozó hálózati overhead-ek mérete . . . . . . .

58

3.5. A 2.forgatókönyvhöz tartozó hálózati overhead-ek aránya a hasznos adathoz képest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

3.6. A 2.forgatókönyvhöz tartozó számla változás . . . . . . . . . . . . . .

59


61


61


62

81

ÁBRÁK JEGYZÉKE

82


63


63


64

3.13. A szimulált architektúra . . . . . . . . . . . . . . . . . . . . . . . . . .

65

Irodalomjegyzék [1] ETSI TR 122 924 V3.1.1 (2000-01). Universal Mobile Telecommunications System (UMTS); Service aspects; Charging and Accounting Mechanisms (3G TR 22.924 version 3.1.1 Release 1999). Technical report, 3GPP, 2000. [2] ETSI TS 122 024 V5.0.0 (2002-06). Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Description of Charge Advice Information (CAI) (3GPP TS 22.024 version 5.0.0 Release 5). Technical report, 3GPP, 2002. [3] ETSI TS 122 086 V5.0.0 (2002-06). Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Advice of Charge (AoC) supplementary services; Stage 1 (3GPP TS 22.086 version 5.0.0 Release 5). Technical report, 3GPP, 2002. [4] ETSI TS 122 105 V5.2.0 (2002-06). Universal Mobile Telecommunications System (UMTS); Services & service capabilities (3GPP TS 22.105 version 5.2.0 Release 5). Technical report, 3GPP, 2002. [5] ETSI TS 122 115 V5.3.0 (2003-06). Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Service Aspects Charging and billing (3GPP TS 22.115 version 5.3.0 Release 5). Technical report, 3GPP, 2003. [6] ETSI TS 123 002 V5.12.0 (2003-09). Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Network architecture (3GPP TS 23.002 version 5.12.0 Release 5). Technical report, 3GPP, 2003. [7] ETSI TS 123 078 V5.5.1 (2003-09). Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Customised Applications for Mobile network Enhanced Logic (CAMEL); Stage 2 (3GPP TS 23.078 version 5.5.1 Release 5). Technical report, 3GPP, 2003. [8] ETSI TS 123 101 V4.0.0 (2001-04). Universal Mobile Telecommunications System (UMTS); General UMTS Architecture (3GPP TS 23.101 version 4.0.0 Release 4). Technical report, 3GPP, 2003. 83

IRODALOMJEGYZÉK

84

[9] ETSI TS 123 127 V5.2.0 (2002-06). Universal Mobile Telecommunications System (UMTS); Virtual Home Environment (VHE) / Open Service Access (OSA); Stage 2 (3GPP TS 23.127 version 5.2.0 Release 5). Technical report, 3GPP, 2002. [10] ETSI TS 123 140 V5.8.0 (2003-09). Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Multimedia Messaging Service (MMS); Functional description; Stage 2 (3GPP TS 23.140 version 5.8.0 Release 5). Technical report, 3GPP, 2003. [11] 3G TS 23.228 V1.7.0 (2001-02). 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia (IM) Subsystem – Stage 2 (3G TS 23.228 version 1.7.0). Technical report, 3GPP, 2001. [12] ETSI TS 132 200 V5.7.0 (2004-06). Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Telecommunication management; Charging management; Charging principles (3GPP TS 32.200 version 5.7.0 Release 5). Technical report, 3GPP, 2004. [13] ETSI TS 132 205 V5.4.0 (2003-06). Universal Mobile Telecommunications System (UMTS); Telecommunication management; Charging management; Charging data description for the Circuit Switched (CS) domain (3GPP TS 32.205 version 5.4.0 Release 5). Technical report, 3GPP, 2003. [14] ETSI TS 132 215 V5.4.0 (2003-06). Universal Mobile Telecommunications System (UMTS); Telecommunication management; Charging management; Charging data description for the Packet Switched (PS) domain (3GPP TS 32.215 version 5.4.0 Release 5). Technical report, 3GPP, 2003. [15] ETSI TS 132 225 V5.3.0 (2003-06). Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Telecommunication management; Charging management; Charging data description for the IP Multimedia Subsystem (IMS) (3GPP TS 32.225 version 5.3.0 Release 5). Technical report, 3GPP, 2003. [16] ETSI TS 132 235 V5.4.0 (2003-09). Universal Mobile Telecommunications System (UMTS); Telecommunication management; Charging management; Charging data description for application services (3GPP TS 32.235 version 5.4.0 Release 5). Technical report, 3GPP, 2003. [17] 3GPP TR 23.815 V5.0.0 (2002-03). 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Charging implications of IMS architecture (Release 5). Technical report, 3GPP, 2002. [18] 3GPP TS 32.240 V6.0.0 (2004-09). 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication

IRODALOMJEGYZÉK

85

management; Charging management; Charging architecture and principles (Release 6). Technical report, 3GPP, 2004. [19] 3GPP TS 23.125 V6.2.0 (2004-09). 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Overall high level functionality and architecture impacts of flow based charging; Stage 2 (Release 6). Technical report, 3GPP, 2004. [20] 3GPP TS 32.260 V2.0.0 (2004-12). 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Charging management; IP Multimedia Subsystem (IMS) charging; (Release 6). Technical report, 3GPP, 2004. [21] 3GPP TS 29.198 V3.4.0 (2001-06). 3rd Generation Partnership Project; Technical Specification Group Core Network; Open Service Architecture (OSA) Application Programming Interface (API) – Part 1 (Release 1999). Technical report, 3GPP, 2001. [22] ETSI ES 202 915-12 V1.2.1 (2003-08). Open Service Access (OSA); Application Programming Interface (API); Part 12: Charging SCF (Parlay 4). Technical report, 3GPP, 2003. [23] Harri Hakala, Leena Mattila, Juha-Pekka Koskinen, Marco Stura, and John Loughney. Diameter Credit-Control Application. Technical report, AAA Working Group, 2004. [24] RFC: 0791. Internet Protocol, Darpa Internet Program Protocol Specification. Technical report, Information Sciences Institute, September 1981. [25] RFC: 2460. Internet Protocol Version 6 (IPv6) Specification. Technical report, Network Working Group, December 1998. [26] UMTS Forum Report No 9. The UMTS Third Generation Market – Structuring the Service Revenues Opportunities. Technical report, UMTS Forum, September 2000. [27] UMTS Forum Report No 10. Shaping the Mobile Multimedia Future – An Extended Vision from the UMTS Forum. Technical report, UMTS Forum, September 2000. [28] UMTS Forum Report No 11. Enabling UMTS Third Generation Services and Applications. Technical report, UMTS Forum, October 2000. [29] UMTS Forum Report No 13. The UMTS Third Generation Market – Structuring the Service Revenue Opportunities. Technical report, UMTS Forum, April 2001. [30] UMTS Forum Report No 21. Charging, Billing and Payment Views on 3G Business Models. Technical report, UMTS Forum, 2002.

IRODALOMJEGYZÉK

86

[31] UMTS Forum Report No 27. Strategic Considerations for IMS – the 3G Evolution. Technical report, UMTS Forum, January 2003. [32] M. Koutsopoulou, A. Kaloxylos, and A. Alonistioti. Charging, Accounting and Billing as a Sophisticated and Reconfigurable Discrete Service for next Generation Mobile Networks. In IEEE Semiannual Vehicular Technology Conference (Fall VTC2002), Vancouver, Canada, September 2002. [33] M. Koutsopoulou, C. Farmakis, and E. Gazis. Subscription Management and Charging for Value Added Services in UMTS Networks. In IEEE Semiannual Vehicular Technology Conference (Spring VTC2001), Rhodes, Greece, May 2001. [34] M. Koutsopoulou, N. Alonistioti, E. Gazis, and A. Kaloxylos. Adaptive Charging, Accounting and Billing system for the support of advanced business models for VAS provision in 3G systems. In Invited paper at the IEEE 12th International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC 2001), San Diego, USA, October 2001. [35] M. Koutsopoulou, E. Gazis, and A. Kaloxylos. A novel billing scheme for UMTS networks. In International Symposium on 3rd Generation Infrastructure and Services, Athens, Greece, July 2001. [36] N. Houssos, M. Koutsopoulou, and S. Schaller. A VHE architecture for advanced value-added services provision in 3rd generation mobile communication networks. In Globecom 2000 Workshop on Service Portability and Customer Premises Environments, San Francisco, USA, December 2000. [37] S. Panagiotakis, M. Koutsopoulou, A. Alonistioti, and A. Kaloxylos. Generic Framework for the Provision of Efficient Location-based Charging over Future Mobile Communication Networks. In IEEE 13th International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC 2002), Lisbon, Portugal, September 2002. [38] V. Gazis, M. Koutsopoulou, C. Farmakis, and A. Kaloxylos. A Flexible Charging and Billing Approach for the Emerging UMTS Network Operator Role. In ATS 2001, Seattle, Washington, USA, April 2001. [39] S. Panagiotakis, M. Koutsopoulou, and A. Alonistioti. Advanced Location Information Management Scheme for Supporting Flexible Service Provisioning in Reconfigurable Mobile Networks. In IST Mobile Communication Summit 2002, Thessaloniki, Greece, June 2002. [40] S. Panagiotakis, E. Gazis, M. Koutsopoulou, N. Houssos, Z. Boufidis, and A. Alonistioti. Roaming issues for service provisioning over 3rd Generation mobile networks. In Advanced Technologies, Applications and Market Strategies for 3G (ATAMS), Cracow, Poland, June 2001.

IRODALOMJEGYZÉK

87

[41] N. Alonistioti, E. Gazis, M. Koutsopoulou, N. Houssos, and S. Panagiotakis. An Application platform for downloadable VASs provision to mobile users. In IST Mobile Communication Summit 2000, Galway, Ireland, September 2000. [42] A. Alonistioti, N. Houssos, S. Panagiotakis, M. Koutsopoulou, and V. Gazis. Intelligent architectures enabling flexible service provision and adaptability. In Wireless Design Conference (WDC 2002), London, UK, May 2002. [43] N. Houssos, V. Gazis, S. Panagiotakis, M. Koutsopoulou, and A. Alonistioti. Advanced Business Models and Flexible Service Provision for Reconfigurable Mobile Systems. In SDR Forum Technical Conference 2002 (SDR 2002), San Diego, California, USA, November 2002. [44] Maria Koutsopoulou, Alexandros Kaloxylos, Athanassia Alonistioti, and Lazaros Merakos. Charging, Accounting and Billing Management Schemes in Mobile Telecommunication Networks and the Internet. IEEE Communications Surveys, First Quarter 2004, 6(1), 2004. [45] Zsolt Butyka, Tamás Jursonovics, and Sándor Imre dr. A Real-Time Charging Model for UMTS Mobile Network. In ETIK conference, Budapest, Hungary, 2004. [46] John Cushnie, David Hutchison, and Huw Oliver. Evolution of Charging and Billing models for GSM and Future Mobile Internet Services. In QofIS’2000 Symposium, Berlin, Germany, September 2000. [47] John Cushnie, David Hutchison, and Huw Oliver. Internet Services: Infrastructure for Charging and Billing. In Advanced Internet Charging and QoS Technology (ICQT’01) Workshop WS3 of Infomatik 2001, University of Vienna, Austria, September 2001. [48] P. Pagliusi and C. J. Mitchell. PANA/GSM authentication for Internet access. In SympoTIC ’03, Joint IST Workshop on Mobile Future and Symposium on Trends in Communications, Bratislava, Slovakia, October 2003. [49] Susana Schwartz. Next-Gen Rating: It Will Be Only As Good as the Network. Billing World & OSS Today, February 2003. [50] Hitesh Tewari and Donal O’Mahony. Real-Time Payments for Mobile IP. IEEE Communications Magazine, February 2003. [51] Michael Peirce and Donal O’Mahony. Multi-Party Payments for Mobile Services. Technical report, Trinity College Dublin, Computer Science Department, 1999. [52] John Cushnie. Charging and Billing for Future Mobile Internet Services, September 2000. First Year PhD Research Report.

IRODALOMJEGYZÉK

88

[53] B. Stiller, G. Fankhauser, B. Plattner, and N. Weiler. Charging and accounting for integrated internet services - state of the art, 1998. [54] Lucent Technologies. IP Multimedia Subsystem (IMS) Service Architecture, 2004. Whitepaper. [55] Ericsson. IMS – IP Multimedia Subsystem, October 2004. Whitepaper. [56] Siemens. Convergent Online Charging: Meeting the Needs of Operators for Next Generation Charging, 2003. Whitepaper. [57] Siemens. Siemens IP Multimedia Subsystem (IMS): The Domain for Services, 2004. Whitepaper. [58] 3G Americas. IP Multimedia Subsystem: IMS – Overview and Applications, July 2004. Whitepaper. [59] Alcatel. Network Evolution towards IP Multimedia Subsystem, 2004. Strategy Whitepaper. [60] Motorola. Motorola IP Multimedia Subsystem, February 2004. Whitepaper. [61] Steve Tsang-Kwong-U. 3GPP IMS Architecture Overview, 2004. IMS presentation (capabilities, architecture) on behalf of 3GPP. [62] Cornelia Kappler. UMTS Networks Course Presentation, 2004. TKN TU Berlin. [63] Pierre Salomon. Ericsson Content Based Charging Solutions, 2002. Presentation. [64] Mile Šiki´c. Content and service charging model in the mobile packet networks, 2003. Colloquium presentation. [65] Kati Lehtinen. Analysis of the Charging Protocols in the All IP Network, 2002. Presentation. [66] Lieve Bos. Fixed Mobile Convergence, 2004. Presentation for ICSS16 Conference. [67] TIA-873-007. All-IP Core Network Multimedia Domain, IP Multimedia Subsystem – Charging Architecture, 2003. [68] Hewlett-Packard. Real-time Prepay Billing solution feature guide, 2002. [69] Atos Origin. Managing Content in Real-Time: A New Dynamic in the Market, 2004. [70] Mobile Tech News. Ericsson demonstrates real-time charging of MMS at CeBIT. http://www.mobiletechnews.com/info/2002/03/ 12/120718.html, 2005-01-10, 00:22.

IRODALOMJEGYZÉK

89

[71] VoIP News. Pakistan’s WorldCall Telecom Ltd and Cameroon’s Douala1 select Intec DCP real-time charging technology for billing IP and VoIP services. http://www.voip-news.com/art/3k.html, 2005-01-10, 00:22. [72] 3G.CO.UK. 3G Charging Solutions. http://www.3g.co.uk/PR/October2004/ 8527.htm, 2005-01-10, 00:23. [73] Inc. Funk Software. The Role of RADIUS/AAA in GSM Wireless Data Networks GPRS, EDGE, UMTS. Whitepaper, http://www.funk.com/radius/ Solns/gsm_wp.asp, 2005-01-10, 00:24. [74] Service Level Corporation. Rating Support For Revenue Opportunities With GPRS & UMTS Services. Whitepaper, http://www.servicelevel.net/rating_ matters/GPRS_and_UMTS_rating.htm, 2005-01-10, 00:25. [75] Nortel Networks. The Nortel Networks Gateway GPRS Support Node. http://www.nortelnetworks.com/products/01/gsm_core/ggsn/index.html 2004-04-17 12:04. [76] http://www.nokia.com, 2005-04-17, 23:04. [77] http://www.3gpp.org, 2005-04-17, 23:14. [78] http://www.parlay.org, 2005-04-17, 23:16. [79] http://www.netpincer.hu, 2005-04-17, 23:17. [80] Ary Bálint Dávid és dr. Imre Sándor. UMTS rendszerek valós ideju ˝ számlázásának problémái. Magyar Távközlés, Július 2004. [81] Ary Bálint Dávid és Debrei Gábor. UMTS rendszerek valós ideju ˝ számlázása. In BME Tudományos Diákköri Konferencia: Hálózatmenedzsment szekció, November 2004. 1. helyezés. [82] Bálint Dávid Ary. Real-time charging in UMTS environment. In Digital Technologies 2004, Žilina, Slovakia, December 2004. [83] Ary Bálint Dávid és dr. Imre Sándor. Valós ideju ˝ számlázás mobil környezetben. Híradástechnika, Január 2005. [84] Ary Bálint Dávid és Debrei Gábor. UMTS rendszerek valós ideju ˝ számlázása. In Országos Tudományos Diákköri Konferencia: Kommunikációs hálózatok és szolgáltatások szekció, November 2004. 2. helyezés.

CSOMAGKAPCSOLT FORGALOM SZÁMLÁZÁSA UMTS RENDSZERBEN

Recommend Documents