NAGYSEBESSÉGŰ CELLÁS MOBILHÁLÓZATOK FORGALOM MENEDZSELÉSE PCRF SEGÍTSÉGÉVEL

Átírás

1 Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Híradástechnikai Tanszék Patai Árpád NAGYSEBESSÉGŰ CELLÁS MOBILHÁLÓZATOK FORGALOM MENEDZSELÉSE PCRF SEGÍTSÉGÉVEL KONZULENS Dr. Do Van Tien BUDAPEST, 2013

2 Tartalomjegyzék Összefoglaló... 5 Abstract Bevezetés A mobil világ változásai Felhasználói tendenciák Mobilhálózatok fejlődése Rádiós hozzáférési hálózat különbségei Maghálózat különbségei Jelzésüzenet megváltozása Forgalommenedzsment és számlázás PCRF architektúra Policy Controller (PC) A PC részei Subscriber Data Broker (SDB) Diameter Routing Agent (DRA) Bridgewater Management System (BMS) Hívásfelépítés Csatlakozás reprezentatív felhasználóként (XXL profil) Csatlakozás nem reprezentatív felhasználóként (M profil) Felépült kapcsolat közti sebességszűkítés (XXL/M profil) Site és Geo-redundancia Telephelyen belüli redundancia PCRF (Policy Charging and Rule Function) SDB (Subscriber Data Broker) DRA (Diameter Routing Agent) BMS (Bridgewater Management System) Egyszeres csomópont meghibásodás PCRF meghibásodás SDB meghibásodás DRA meghibásodás Geo - Redundancia (GR)... 33

3 4.3.1 Teljes Site-on belüli PCRF kiesés Teljes Site-on belüli DRA kiesés Teljes Site kiesés Peer-to-peer forgalom szűrése A peer-to-peer forgalom hatása A peer-to-peer forgalom alakulása Lehetséges szolgáltatói reakciók Hálózati struktúra PCRF szabályrendszer kialakítása Service Manager PCRF konfiguráció Elvárt működés specifikálása XXL felhasználó létrehozása XXL felhasználó létrehozása P2P engedélyezéssel Hívás közben történő P2P aktiválás Hívás közben történő P2P deaktiválás Kapcsolat közben történő sávszélesség csökkentés P2P engedélyezéssel Provisioning interfész Provisioning parancsok Megfelelőség vizsgálat XXL felhasználó létrehozása a gyakorlatban XLL felhasználó létrehozása P2P engedélyezéssel a gyakorlatban Hívás közben történő P2P aktiválás a gyakorlatban Hívás közben történő P2P aktiválás a gyakorlatban Kapcsolat közben történő sávszélesség csökkentés P2P engedélyezéssel a gyakorlatban Összegzés, kitekintés Köszönetnyilvánítás Irodalomjegyzék Rövidítésjegyzék Ábrajegyzék Táblázatok... 76

4 HALLGATÓI NYILATKOZAT Alulírott Patai Árpád, szigorló hallgató kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, csak a megadott forrásokat (szakirodalom, eszközök stb.) használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen, a forrás megadásával megjelöltem. Hozzájárulok, hogy a jelen munkám alapadatait (szerző(k), cím, angol és magyar nyelvű tartalmi kivonat, készítés éve, konzulens(ek) neve) a BME VIK nyilvánosan hozzáférhető elektronikus formában, a munka teljes szövegét pedig az egyetem belső hálózatán keresztül (vagy hitelesített felhasználók számára) közzétegye. Kijelentem, hogy a benyújtott munka és annak elektronikus verziója megegyezik. Dékáni engedéllyel titkosított diplomatervek esetén a dolgozat szövege csak 3 év eltelte után válik hozzáférhetővé. Kelt: Budapest, Patai Árpád

5 Összefoglaló Napjainkra a hordozható eszközök a mindennapi életünk részévé váltak. A mobil eszközök elterjedésével, illetve a negyedik generációs mobil hálózatok bemutatásával, rohamosan megnövekedett a rádiós hálózatok forgalma. Az új technológiák feltörekvésével egyre rohamosabban kezdtek terjedni a különböző peer-topeer szolgáltatások (VoIP, torrent alkalmazsok), melyek nem csupán forgalommenedzselési, de jogi szempontból is igen aggályosak egy szolgáltatóra nézve. Többek között ilyen és hasonló problémákra mutatták be a 3GPP tervezői a PCRF-et (Policy Charging and Rule Function), mely egy olyan multifunkcionális eszköz, amely képes egy időben változatos szabályrendszereken keresztül menedzselni a hálózatot, illetve a számlázási feladatokat elvégezni. Dolgozatomban egy olyan rendszert mutatok be, mellyel a szolgáltatók hatékonyan valós időben képesek kiszűrni a peer-to-peer, azon belül a torrent forgalmat, mely által értékes erőforrások, ezzel együtt komoly költségek takaríthatóak meg. Mindemellett az átlag felhasználó javára is válik, hiszen a komoly forgalmat generáló felhasználók nem lopják el előlük a sávszélességet. Munkám során részletesen bemutatom, hogyan épül fel egy ilyen hálózat, hogyan valósítható meg, milyen építőkövei vannak a feladat elvégzéséhez szükséges szabályrendszernek, illetve, hogy milyen interakciókon keresztül megy végbe a szabályozás. Az általam bemutatott megoldás, a felhasználói igényeket is kielégítve képes dinamikusan engedélyezni, vagy szűrni az áthaladó nemkívánatos forgalmat.

6 Abstract Nowadays portable devices form part of our everyday life. Traffic of radio networks raised fast as mobile devices gained ground and the fourth generation mobile networks got introduced. The fast paced spread of peer-to-peer services was enabled by these new technologies becoming more and more common(e.g.: VoIP, torrent applications). Due to the wide accessibility of such services and applications operators are not only facing issues in traffic management but also in the field of law. To address these and some other concerns, the designers of 3GPP introduced PCRF (Policy Charging and Rule Function), a multifunctional tool which is capable of managing the network according to multiple sets of rules simultaneously, and of performing all charging-related tasks. In my thesis I present a system which enables operators to filter effectively and in real time peer-to-peer traffic and in particular, bittorrent traffic within which might yield significant savings in resources and, hence, costs. Moreover it benefits the average user as those generating considerable traffic (by p2p) could not steal their share of bandwidth. In my present work, I will describe what the structure of such a system is like, how it could be realized, what building blocks are needed for a system to perform the task and through which interactions such regulation could be executed. The solution I will present, as well satisfying demands of users, is capable of dynamic permission or filtration of undesirable traffic. 6

7 1 Bevezetés A mobil eszközök elterjedésével, mint a laptopok, okostelefonok és a tabletek, a mai világ felhasználói már teljesen hozzászoktak, hogy pár kattintással bárhol, bármikor hozzáférhetnek olyan tartalmakhoz, mint a WEB 2.0, Mobil TV, VoIP, Video Streaming, vagy akár az online játékok. Ez természetesen a megnövekedett adatforgalom mellett gyorsabb hozzáférést igényel. Emiatt döntött úgy a 3GPP szabványosító csoport, hogy a fenti igényeket figyelembe véve, egy új technológián alapuló szabványt hozzanak létre. A szabvány tervezése során figyelembe kellett venniük, hogy az új technológia kényelmesen együtt tudjon működni, mind a már meglévő korábbi 3GPP (2G/3G különböző kiadásaival), mind a nem 3GPP-s szabványokkal (pl. WiFi). Emellett azt is fontosnak tartották, hogy az új technológia időtálló, könnyen továbbfejleszthető legyen. Innen is ered a neve LTE Long Term Evolution (Hoszzútávú fejlődés). Az új technológiákkal új szolgáltatások is megjelentek. Az új szolgáltatások hatékony menedzselésére, a számlázás egyszerűbbé tételére, illetve a hálózat egyszerűsítésének érdekében fejlesztették ki a PCRF-et. A PCRF, ahogy azt a későbbiekben látni fogjuk, különböző felhasználói csoportokhoz, vagy akár teljesen személyre szabott szolgáltatásokhoz tartozó forgalmat képes kezelni. Ezen felül fontos szerep hárul rá a QoS (Quality of Service) biztosításában is, mint például a túlzott adatforgalom szabályozása. A második fejezetben, először röviden ismertetem az Olvasóval a harmadik és negyedik generációs hálózatok különbségével, hogy közelebb kerüljön az újgenerációs hálózatokhoz. A harmadik és negyedik fejezetben egy széleskörű áttekintést nyújtok a PCRF felépítéséről, működéséről. A működést néhány egyszerű hívásáramláson keresztül mutatom be, majd áttekintést nyújtok, hogy mi történik, ha valamely eszköz, avagy szoftver meghibásodna. Mind a helyi, mind a földrajzi meghibásodást figyelembe véve. Az ötödik fejezetben megvalósítok egy lehetséges peer-to-peer forgalom szűrésére, menedzselésére alkalmas PCRF logikát, melynek kivitelezéséhez felhasználom az eszközhöz tartozó különböző szoftvereket, API-kat. Bemutatom a 7

8 folyamatok közben milyen üzeneteket vezetnek a logika felépítéséhez, irányításához, vázolom az elvárt működési mechanizmust. Végül az elvárt működés igazolásához elvégeztem néhány teszthívást, melynek sikerességéről a bemutatott Wireshark felvételek, logok, adatbázis lekérdezések adnak tanúbizonyságot. 8

9 2 A mobil világ változásai A mobil világ folyamatos mozgásban van, azok a technológiák, melyek ma újdonságnak számítanak, előremutatóak, holnap már elavultak lesznek. Az Olvasó ebben a fejezetben megismeri a jelenlegi, és jövőbéli trendeket, majd egy rövid áttekintést kap a jelen és a jövő technológiáiról. 2.1 Felhasználói tendenciák Az elmúlt pár évben komoly változások álltak be a felhasználói szokásokban. Az okostelefonok, tablet gépek egyre nagyobb térnyerésével a felhasználók készülékeiket már nem csak telefonálásra, hanem egyre inkább adatforgalmazásra is használják. Az utóbbi állítást bizonyítja a Cisco tanulmánya [16], miszerint 2012-ben 70%-kal nőtt a globális mobil adatforgalom használata. Ahogy azt az 1. ábra is mutatja, nem egy egyszeri esetről van szó, 2017-re 13-szorosa lesz az adatforgalom nagysága a 2012-es adatoknak, mely évi átlag 66%-os növekedést jelent. 1. ábra A mobil adatforgalom alakulása között [16] Természetesen ezt a fajta forgalomnövekedési igényt a jelenlegi harmadik generációs hálózatokkal nem lehet kielégíteni, így világszerte a szolgáltatók elkezdték fejleszteni hálózatukat a legújabb generációra, az LTE hálózatokra. A fejlesztéseknek hála, az adatsebesség is jelentősen növekedni fog. Míg jelenleg az átlagos adatsebesség 526 kbps, addig ez 2017-re meghétszereződik és eléri a 3,9 Mbps-os átlagértéket. 9

10 Érdekes adat, hogy egy LTE képes készülék átlagosan 19-szer több adatot forgalmaz egy hónapban, mint egy nem LTE képes, énnél még megdöbbentőbb adat az, hogy jelenleg az összes készülék 0,9%-a LTE képes, amely az összes adatforgalom 14%-át teszi ki re az összes telefon mintegy 10%-a lesz LTE képes, mely az adatforgalom kb. 45%-át fogja kitenni (2. ábra) [16]. 2. ábra Forgalom eloszlás [16] Összegezve a fentieket kijelenthető, hogy a felhasználói igények és szokások elértek arra a pontra, hogy a szolgáltatók már bátran belekezdjenek az új hálózat kiépítésébe, hiszen a felmérések szerint egyre nagyobb az igény az online tartalmak mobil eszközön való eléréséhez. A következő fejezetben röviden bemutatom, a harmadik, illetve a negyedik generációs hálózatok főbb különbségeit, melyben röviden ismertetem a felépítésbeli, rádiós, illetve a protokollbeli különbséget. 2.2 Mobilhálózatok fejlődése Ahogy az az Olvasónak is szembetűnő lesz, az új generációs mobil hálózat az előző verzióhoz képest igen nagy változáson esett át. A tervezés során nem csak a maghálózaton (CN Core Network) és a rádiós interfészen, de még az egyes jelzés protokollokon is változtattak. A következő részben a dokumentum véges terjedelme miatt, csak az UMTS (REL 99) és LTE különbségeit (REL 8) foglalom össze röviden. 10

11 A korábbi mobilhálózatokat két részre lehetett osztani áramkörkapcsolt, melynek feladata a hívások menedzselése volt, és csomagkapcsolt részre, mely az adatforgalomért volt felelős. Az új hálózat teljes egészében csomagkapcsolt, IP alapú. Ez természetesen azt eredményezi, hogy az egész hálózatot újra kellett értelmezni. A tervezés során fontos szempontként szerepelt, hogy a hálózati architektúra minél átláthatóbb legyen, így a negyedik generációs hálózatokban kevesebb, ámbár okosabb entitásokat találunk. Ennek megfelelően mind a rádiós hozzáférési hálózat, mind a maghálózat megváltozott (3. ábra) [1]. 3. ábra Az UMTS és az LTE architektúra változása [4] Rádiós hozzáférési hálózat különbségei Míg korábban a hozzáférési hálózatot UTRAN-nak (Universal Terrestrial Radio Access Network) hívták addig most ezt EUTRAN-nak (Evolved UTRAN). Az UTRAN a mobil eszközön kívül két entitást tartalmazott: A NodeB-t, melynek főbb feladati közé tartozik a teljesítményszabályozás, csatornakódolás, interleaving, illetve az RNC-t (Radio Network Controller), melynek feladati közé tartozik, az alá tartozó bázisállomások vezérlése, a maghálózattal való kapcsolat fenntartása, valamint az általános rádiós erőforrásgazdálkodás megvalósítása. Az UTRAN lecserélése két fő ok miatt vált szükségessé: az egyik, hogy megváltozott a moduláció: a régi WCDMA-t felváltotta a jóval hatékonyabb közeghozzáférést biztosító OFDMA, míg a másik a bázisállomásokba bevitt intelligencia, mely azt eredményezte, hogy nincs többé szükség rádiós vezérlőre, mert azt beépítették az új bázisállomásba, az enodeb-be [3][8]. 11

12 2.2.2 Maghálózat különbségei Az LTE maghálózatát (SAE System Architecture Evolution) két részre bonthatjuk HSS (Home Subscriber Subsystem) és EPC (Evolved Packet Core). A HSS tulajdonképpen a HLR (Home Location Register) továbbfejlesztése, így feladatai közé tartozik a honos felhasználók adatainak, tartózkodási helyének, számlázási információnak tárolása. Míg az EPC további három elemre bontható: mobilitás kezelő egységre, (MME - Mobility Manegement Entity), kiszolgáló átjáróra (S-Gw - Serving Gateway), és adathálózati átjáróra (PDN-Gw /P-Gw/ - Packet Data Network Gateway) [5]. Az MME feladatai, ahogy a neve is mutatja a mobilitás kezelése, útvonalválasztás, paging, előfizető helyének lekérdezése, stb. Az MME csak Control Plane szolgáltatásokat kezel, a User Plane feladatait a Serving Gateway látja el, melynek alapvetően két fő feladata van, biztosítja az enodeb-k közötti kommunikáció során a mobilitást, illetve ő a kapocs a rádiós hozzáférési hálózat és az EPC között. Együtt az MME és a S-Gw funkcióban az SGSN-hez (Serving GPRS Support Node) áll legközelebb. A P-GW tulajdonképpen a kapocs az EPC és a külső 3GPP és nem 3GPP hálózatok között. A P-Gw leginkább a GGSN-nek (Gateway GPRS Support Node) feleltethető meg. Ezt mutatja a 4. ábra [10][2]. 4. ábra 3G és az LTE funkcionális összehasonlítása 12

13 2.2.3 Jelzésüzenet megváltozása Ahogy korábban említettem nem csak a hálózati elemeket, de egyes protokollokat is lecseréltek. Számunkra ezen protokollok közül a Diameter protokoll lesz érdekes. A protokollt 1998-ban fejlesztették ki a RADIUS protokoll kiterjesztéseként, annak hiányosságainak kiküszöbölésére. Ahogy a RADIUS, úgy a Diameter protokoll is az AAA (Authentication, Authorization, Accounting) funkcionalitást valósít meg. A tervezés során növelték a megbízhatóságot, a biztonságot és a rugalmasságot. A Diameter üzenetek parancsokat, és értesítéseket szállítanak a csomópontok között. Minden üzenethez tartozik egy parancskód, mely egyértelműen azonosítja, hogy milyen típusú tartalmat szállít. A Diameter protokoll üzenetpárokból áll, vagyis minden kéréshez tartozik egy válasz üzenet is [6][7]. Számunkra a későbbiekben két fajta üzenet lesz érdekes: CCR/CCA (Credit Control Request/Answer) /Kód: 272/ o CCR-I (CCR Initial) kapcsolódás kezdeményezésekor küldi a kliens a szervernek o CCR-U (CCR Update) állapotváltozáskor kerül küldésre o CCR-T (CCR - Terminate) kapcsolat bontásakor kerül küldésre RAR/RAA (Re Auth Request/Answer) /Kód: 258/ szabály (policy) változáskor kerül elküldésre Forgalommenedzsment és számlázás Az új hálózat egyik legfontosabb kiegészítő eleme a PCRF (Policy Charging and Rule Function). A PCRF segítségével a szolgáltatók új innovatív, értéknövelő szolgáltatások bevezetésére lehetnek képesek, mind a fix-, mind a mobilhálózatokban. Az eszköz lehetővé teszi, hogy felhasználók csoportjához, de akár egyetlen felhasználóhoz is rendelhessünk külön szolgáltatásokat, melyeket különböző módon tudunk paraméterezni. A szolgáltatásokat rendelhetjük elforgalmazott adatokhoz, napszakhoz, alkalmazásokhoz. A mobilhálózatokban a szűkös erőforrások miatt kritikus az átlag előfizetők védelme az ún. heavy userektől. A Cisco jelentése szerint 2012-ben a felhasználók felső 13

14 1%-a birtokolta a teljes adatforgalom 16-18% százalékát, míg a felső 20% az adatforgalom mintegy felét. A felhasználók védelmében az operátorok képesek beavatkozni az ilyen és hasonló tendenciák kialakulásába, ezzel növelve az előfizetői elégedettséget. A különböző QoS (Quality of Service) paraméterek betartásával az operátorok hatékonyan tudják skálázni saját erőforrásaikat, mellyel egyrészről költséget takarítanak meg, másrészről a lehető legjobb kihasználtságot érhetik el. A PCRF támogatja a dinamikus szabályok létrehozását is, mely a szolgáltató portfóliójában értéknövelő szolgáltatásként jelenhet meg [9]. Ilyen szolgáltatás lehet például a szülői felügyelet (Parental Control), peer-to-peer forgalom szűrése, VoIP (Voice over IP) hívások engedélyezése, melyet képes támogatni valós idejű számlázási lehetőségekkel. A számlázási lehetőségek kialakítása közben a tervezők odafigyeltek, hogy a lehető legjobban kielégítsék az előfizetők igényit. Így lehetőség van mind időalapú, mind adat alapú számlázásra, melyet szolgáltatásonként szabályozhatunk. Például idő alapú számlázás stream típusú (pl. video) adatoknál lehet életszerű, míg az adat alapú számlázást többek között alkalmazásokhoz rendelhetjük (Facebok, Twitter, stb.). Összegezve a PCRF-nek három követelménynek kell megfelelnie. Az első, hogy képes legyen kezelni a változatos szabályrendszereket úgy, hogy közben együtt tudjon élni a hálózat növekedésével, mind a növekvő sebesség igénnyel, mind a növekvő felhasználószámmal. Másodszor képesnek kell lennie együtt dolgozni különböző beszállítók különböző eszközeivel. Végül, de nem utolsó sorban flexibilisnek kell lennie, úgy kell kezelnie az új értéknövelő szolgáltatásokat, hogy azok ne rontsák az egész hálózat áteresztő képességét [12]. 14

15 3 PCRF architektúra A PCRF tulajdonképpen nem egy eszköz, hanem egy rendszer mely több eszköz és alkalmazás összessége. A főbb alkotóelemek az 5. ábrán láthatóak, melyeket a következő néhány pontban részletesen bemutatok. A Gw ugyan nem a PCRF része, viszont szervesen kapcsolódik hozzá, hiszen a PCRF által generált szabályokat a Gw tudja értelmezni és alkalmazni. A PCRF alrendszer a következő elemekből épül fel: SPR (felhasználói adatokat tartalmazó adatbázis), BMS (monitorozó eszköz) PCRF (szabályok létrehozásáért felelős rendszer), DRA (diameter üzenetek továbbításáért felelős) Architektúrális szempontból három megközelítést különböztethetünk meg, attól függően, hogy a kvótaméréseket hol végezzük: Heavy: A PCRF a saját beépített kvóta menedzserét használja. Lite: Külső kvóta menedzsert használ, a mi esetünkben ez került megvalósításra. Hybrid: Egyidejűleg jelen a Heavy és a Lite megoldás is [15]. 5. ábra PCRF architektúra [13] 15

16 3.1 Policy Controller (PC) A Policy Controller gyakorlatilag egy statikus és dinamikus információkon alapuló szabályrendszert megvalósító modul, mely hatékonyan képes támogatni az üzleti elvárásokat [15]. Például lehet egy üzleti döntés az, hogy ne engedjük a peer-topeer forgalmat a hálózaton, kivéve akkor, ha az előfizető megvásárolt egy erre jogosító csomagot. Ebben az esetben létrehozhatunk egy szabályrendszert, mely képest ezt támogatni A PC részei A Policy Controller a 6. ábrán látható modulokat tartalmazza. Csak a fontosabb elemeit fogom bemutatni ebben a fejezetben. 6. ábra A PCRF komponensei [15] Szabályértelmező (Rules Engine) A szabályértelmező feladata, hogy valós időben kiértékelje és feldolgozza az eseményekhez tartozó szabályokat. Az Engine meghatározza az adott szolgáltatáshoz tartozó szabályokat, majd azt leküldi a P-GW irányába, hogy az alkalmazni tudja azt [15]. Például, ha a Policy Controller értesül arról, hogy a felhasználó elérte a havi adatforgalom limitet, akkor egy szűkítési szabályt küld az átjáró felé, mely ennek hatására visszaveszi a felhasználóhoz tartozó kapcsolat sávszélességét, egy előre meghatározott értékre. 16

17 Beágyazott adatbázis (Embedded Database) A PCRF egy saját beágyazott (memórián belüli) adatbázissal rendelkezik, melyre azért van szükség, hogy minimálisra szorítsa az akár több tízezer adatbázisírásból, frissítésből adódó teljesítmény csökkenést. Minden PCRF klaszterben található egy helyi másolat az SPR (Subscriber Profile Repository) adatbázisról. Ezt a másolatot a klaszteren belül az összes PCRF tudja olvasni. Az adatbázis a következő adatokat tartalmazza: Házirend szabályokat (Policy Rules): o Szabályokhoz tartozó kritériumokat o Szabályokat o Szabályok paramétereit Felhasználói állapotinformációkat o előfizetői állapotváltozásokat a session idején o a felhasznált adatforgalmat, időt o session jogokat Session állapotinformációkat o Session állapot adatokat, mint például MSISDN, IMSI, IP cím, stb. o aktuális sávszélességet o csatlakozás óta eltelt időt Globális konfigurációs adatbázist (Házirend döntési tárolót, konfigurációs tárolót, SLF index tárolót) Egy PCRF klaszterben mindig van egy elsődleges adatbázis, minden PCRF ezt az adatbázist olvassa, melyről van egy másolat a klaszterben található másik PCRF-en, illetve készül róla egy biztonsági másolat, melyet az egyik georedundáns PCRF tartalmaz, ha van ilyen [15][14]. 17

18 Házirend végrehajtó interfész (Policy Enforcement Point - PEP Interface) A Policy Controller ezen az interfészen keresztül küldi le a végrehajtandó szabályrendszert a házirend végrehajtó eszköznek, mint például a P-GW, DPI, GGSN [15]. Ilyen szabályrendszer lehet: sebesség csökkentés, ha a felhasználó elérte a havi adatforgalom korlátot, szolgáltatás megvonás, ügyfél átirányítása olyan oldalra, ahol új kvótákat tud vásárolni Mérési szolgáltatás (Metrics Service) A PC része, hogy SNMPv2 és SNMPv3 protokollokon keresztül képes folyamatos információval szolgálni a rendszer állapotáról, mint a teljesítőképesség és az áteresztőképesség. Ezt továbbítja a BMS felé, mely ezáltal pontos képet nyújt a rendszer aktuális állapotáról [15] Gx és Gy interfész Gx interfész: A Policy Controller ezen az interfészen keresztül kommunikál a P-GW-el. A Gx interfész szolgál a felhasználókkal kapcsolatos szabályok leküldésére, Diameter protokollon keresztül [11][15]. Gy interfész: A P-GW a Gy interfészen kér további kvótát az IPMS-től, mely az idő, vagy adat alapú mérés alapja. Ha nincs több szabadon felhasználható kvóta az IPMS jelzi ezt a PC-nek [11][15]. 3.2 Subscriber Data Broker (SDB) Az SDB három elemet tartalmaz: Profiladatbázis (Profile Database) SPR Broker (Subscriber Profile Repository) Provisioning szerver 18

19 7. ábra Az SDB komponensei [15] A Profiladatbázis tárolja a felhasználói és bejelentkezési információkat, a szolgáltatás és rendszer információkat. Abban az esetben, ha új felhasználó került az adatbázisba, vagy egy felhasználó adatai módosítva lettek, a PCRF értesül róla az SPR Brokeren keresztül, majd mikor a felhasználó ténylegesen kapcsolódik a hálózathoz, az ügyfélhez tartozó információk bekerülnek a PC beágyazott adatbázisába. A Provisioning szerver fő feladata, hogy interfészt nyújt a felhasználók adatainak módosításához, illetve ténylegesen elvégzi a módosításokat a Profiladatbázisban. [15]. 3.3 Diameter Routing Agent (DRA) Ahogy a neve is mutatja a DRA diameter üzeneteket továbbít két pont között. Jelen esetben a PCEF (GGSN, P-Gw) és a PCRF között. A P-Gw szemszögéből a DRA egy átjátszó a P-Gw és a PCRF-ek egy csoportja között, ezáltal lehetőség nyílik terhelés elosztásra. Például lehetőség van Round Robin, súlyozott Round Robin, avagy saját algoritmus szerinti megvalósításra is. Ezen felül akár azt is megtehetjük, hogy a georedundáns site-ok között úgy osztjuk el a forgalmat, hogy az egyik site-ra a páros, míg a másikra a páratlan hívószámú felhasználókat irányítjuk [13][14]. Miután a DRA meghatározta, melyik irányba szükséges továbbítani az üzeneteket, a fontosabb adatokat (célcím, MSISDN, Session ID) eltárolja a helyi cache-ben. Így legközelebb, mikor jön egy update (CCR-U) vagy egy bontási kérelem (CCR-T), már csupán a Session ID-t 19

20 kell továbbítani, ez alapján is célt érnek az üzenetek. Az inaktív felhasználók egy előre definiált idő után törlődnek a gyorsítótárból [15]. 3.4 Bridgewater Management System (BMS) A BMS felelős a rendszer állapotának nyomonkövetésére. A BMS minden funkcionális elemmel kapcsolatban áll, melyek elküldik SNMP üzenetekben a működésükkel kapcsolatos információkat. A BMS képes ezekből az információkból egy GUI-n (Graphical User Interface) keresztül pontos képet alkotni a rendszer állapotáról az operátoroknak. A felületen nem csak az egyes eszközök, alkalmazások állapota követhető le, de ezen felül statisztikai adatokhoz is hozzáférhetünk, melyről beszédes diagramok is készülnek. Továbbá a BMS feladata összegyűjteni és továbbítani az SNMP trap üzeneteket külső monitorozó alkalmazások felé. 3.5 Hívásfelépítés A korábbi fejezetekben látható volt, milyen részei vannak a PCRF rendszernek és hogyan is illeszkedik a jelenlegi mobilhálózatokba. Ebben a részben arról lesz szó, hogyan is működik a valóságban. Milyen üzenetáramlások szükségesek egy hívás lefolytatásához. A bemutatott működés során a legegyszerűbb esetet mutatom be, mikor a felhasználó nincs beprovisioning-elve, ami azt jelenti, hogy csatlakozáskor mindenki, a megvásárolt csomagtól függetlenül, reprezentatív felhasználóként csatlakozik, vagyis mindenki kezdetben XXL felhasználó lesz. Abban az esetben viszont, ha az ügyfél mégsem az XXL csomagot vásárolta meg, hanem csak az M -eset az IPMS küld egy DT-SOAP PolicyNitifyRequest üzenetet, mellyel értesíti a PCRF-et, hogy küldje le a P- Gw-nek a megfelelő szabályt. Az alábbiakban pontosan bemutatom, hogy hogyan is működik ez a valóságban. 20

21 3.5.1 Csatlakozás reprezentatív felhasználóként (XXL profil) P-GW PCRF SPR IPMS PrePaid 1: Gx CCR-I 2: GetRepUser Profile 3: Return "XXL" 4: Gx CCA-I 5: Gy CCR-I 8: Gy CCA-I 6: Retrieve Qouta/QoS 7: Return Quota/QoS 9: QoS = default XXL Store in the session table 8. ábra PDP aktiválás (XXL profil) [11] 1. A P-Gw küld egy CCR-I üzenetet a PCRF-nek. 2. A PCRF lekérdezi az SPR adatbázisból a reprezentatív profilt. 3. Visszakapja, az alap profilt: XXL. 4. A PCRF leküldi a megfelelő QoS profilt a P-Gw-nek, mely beállítja azt, illetve a PCRF eltárolja a felhasználóhoz kapcsolódó információkat a beágyazott memóriában. 5. A P-Gw küld egy CCR-I üzenetet az IPMS-nek. 6. Az IPMS lekéri a kvóta információkat a számlázási rendszerből. 7. A Számlázási rendszer visszaadja a profil információkat. 8. Az IPMS nyugtázza a CCR-I üzenetet, CCA-I üzenettel. 9. Az IPMS konstatálja, hogy a visszakapott felhasználói profil megegyezik a reprezentatív felhasználó profiljával, így nem küld profilmódosítási üzenetet a PCRF-nek. 21

22 3.5.2 Csatlakozás nem reprezentatív felhasználóként (M profil) P-GW PCRF SPR IPMS PrePaid 1: Gx CCR-I 2: GetRepUser Profile 3: Return "XXL" 4: Gx CCA-I 5: Gy CCR-I 8: Gy CCA-I 10: PolicyNotifyRequest MSISDN, set "M" 6: Retrieve Qouta/QoS 7: Return Quota/QoS 9: QoS = default XXL Store in the session table 12: Gx RAR 11: PolicyNotifyResponse 13: Gx RAA 9. ábra PDP aktiválás (M profil) [11] 1. A P-Gw küld egy CCR-I üzenetet a PCRF-nek. 2. A PCRF lekérdezi az SPR adatbázisból a reprezentatív profilt. 3. Visszakapja, az alap profilt: XXL. 4. A PCRF leküldi a megfelelő QoS profilt a P-Gw-nek, mely beállítja azt, illetve a PCRF eltárolja a felhasználóhoz kapcsolódó információkat a beágyazott memóriában. 5. A P-Gw küld egy CCR-I üzenetet az IPMS-nek. 6. Az IPMS lekéri a kvóta információkat a számlázási rendszerből. 7. A Számlázási rendszer visszaadja a profil információkat. 8. Az IPMS nyugtázza a CCR-I üzenetet, CCA-I üzenettel. 22

23 9. Az IPMS konstatálja, hogy az adatbázisában szereplő felhasználói profil nem egyezik meg a reprezentatív felhasználó profiljával, az IPMS eltárolja ezt az információt és értesíti a PCRF-et. 10. Az IPMS egy Policy Notify Request set&confirm üzenetet küld a megfelelő felhasználói adatokkal (MSISDN, Rule_ID) a PCRF-nek 11. A PCRF Policy Notify Response üzenettel nyugtáz. 12. A PCRF egy RAR üzenetben leküldi a megfelelő szabályt az átjárónak, mely beállítja azt. 13. A Gw nyugtázza az üzenetet Felépült kapcsolat közti sebességszűkítés (XXL/M profil) 10. ábra Sávszélesség szűkítés (XXL/M profil) [11] 1. Az átjáró kvótafrissítési kérelmet küld az IPMS-nek (CCR-U). 2. Az IPMS lekéri a kvóta információkat a számlázási rendszerből. 3. A Számlázási rendszer visszaadja a profil információkat. 4. Az IPMS nyugtázza a frissítés kérést. 23

24 5. Az IPMS meghatározza, hogy a visszakapott profil információ nem egyezik a korábban beállított felhasználói információval ( XXL / M ), szűkíteni kell. 6. Az IPMS egy Policy Notify Request set&confirm üzenetet küld a megfelelő felhasználói adatokkal (MSISDN, Rule_ID) a PCRF-nek 7. A PCRF Policy Notify Response üzenettel nyugtáz. 8. A PCRF egy RAR üzenetben leküldi a megfelelő szabályt az átjárónak, mely beállítja azt. 9. A Gw nyugtázza az üzenetet. 24

25 4 Site és Geo-redundancia 11. ábra Redundancia a Site-ok között [13] A 11. ábrán az áttekinthetőség végett nincs feltüntetve, hogy a BMS minden csomóponttal kapcsolatban van. A zavartalan működés érdekében a rendszer mind a site-on belül, mind pedig a site-ok között (geo) tartalmaz redundanciát. Utóbbi esetben földrajzilag jól elkülönülő, távoli helyekre telepítik a site-okat, így nem csak hardver, vagy szoftver meghibásodás esetén nyújtható üzembiztos szolgáltatás, hanem természeti katasztrófák (földrengés, árvíz), esetleges tűzvész, vagy klíma kiesés esetén sem tapasztalható szolgáltatás kiesés, mely mind felhasználói, mind szolgáltatói oldalról kritikus szempont. Felhasználói oldalról kritikus, hiszen senki sem akar elesni egy hálózati hiba miatt egy esetleges komoly üzlettől, lecsúszni valamely határidős tevékenységről, szolgáltatói oldalról pedig azért, mert egy esetleges leállás komoly presztízs csökkenést okozna, mely súlyos bevételkiesésben lenne mérhető. 25

26 A site-on belüli redundancia azt jelenti, hogy egy telephelyen minden eszközből kettő, vagy több található, így ha bármilyen szoftveres, vagy hardveres probléma merül fel, az egyik kiszolgáló eszközön, a másik át tudja venni annak a feladatát transzparens módon. Ezen kívül további előnye, hogy ebben az esetben megoszthatóak az erőforrások, mellyel több ügyfél, jobb minőségben szolgálható ki, növelhető az eszközök élettartalma. 4.1 Telephelyen belüli redundancia PCRF (Policy Charging and Rule Function) A Policy Controllerek klaszter párokban helyezhetőek el. Egy klaszteren belül a PC szerverek aktív-aktív státuszban működnek, vagyis mindkét eszköz külön-külön kezel hívásokat. Eközben a belső adatbázis adatokat folyamatosan megosztják egymással, ezzel biztosítva az adatbázisok közti konzisztenciát. A szerverek közt periodikusan mennek ún. heartbeat üzenetek, melyek a szerverek állapotát hivatottak ellenőrizni. Ha egy előre definiált időn belül nem érkezik heartbeat, akkor a klaszteren belül a másik szerver átveszi az első feladatát [14]. Policy Controller A Policy Controller A Sessions State Cache Sessions State Cache Gateway / DPI 12. ábra PCRF helyi redundancia [14] Habár a PC-ek aktív-aktív státuszban vannak, egyidejűleg csak egy adatbázist írnak, vagyis a belső adatbázisok aktív-inaktív módban működnek. Természetesen az adatbázisok között folyamatos a szinkronizáció, az adatok konzisztens állapotban tartása végett. Ha az elsődleges belső adatbázis leáll, de a két PC között továbbra is él a kapcsolat (van heartbeat üzenet), akkor mindkét PC átkapcsol a másik belső adatbázisra [14]. 26

27 Policy Controller A Policy Controller Heartbeat Policy Controller A Policy Controller Sessions State Cache Replication Sessions State Cache 13. ábra PCRF helyi redundancia [14] SDB (Subscriber Data Broker) A Policy Controller telepíthető belső vagy külső SPR adatbázissal is, esetünkben az előbbi megoldás került kivitelezésre. Minden SDB egy beágyazott Oracle RDBMS-t tartalmaz. Ha valamelyik adatbázis tartalma megváltozik, akkor az tovább replikálódik a többi adatbázisba, vagyis minden felhasználó összes adata megtalálható minden adatbázisban. 14. ábra Profil adatbázis n-irányú redundanciája [15] A PCRF ún. SPR Brokeren keresztül kapcsolódik az SPR adatbázishoz. Minden PCRF számára van egy elsődleges és egy vagy több másodlagos Broker (helyi és globális renduncia biztosítása végett). És minden Broker csatlakozik az összes adatbázishoz. Ebben az esetben is megtalálható az elsődleges-másodlagos hiearchia. Ha az elsődleges SPR adatbázis megsérül, akkor a Broker átkapcsol a helyi másodlagos adatbázisra, ha minden helyi adatbázis elérhetetlenné válik, akkor a távoli adatbázist fogja használni. Ezt megteheti, hiszen minden SPR (helyi és távoli), ugyanazokat az adatokat tartalmazza. Ha a Broker válik elérhetetlenné, akkor a másodlagos eszköz 27

28 veszi át a szerepét. Természetesen a másodlagos Broker ilyenkor az elsődleges adatbázissal kommunikál. Abban az esetben, mikor az elsődleges Broker vagy adatbázis visszatér, a rendszer visszakapcsol, és a kezdeti konfiguráció szerint folytatja a működését. A folyamat a P-Gw szemszögéből teljesen transzparens módon megy végbe, vagyis a felhasználók kapcsolatai nem sérülnek ilyenkor, számukra zavartalan a böngészési élmény [14]. SDB 1 SDB 2 SDB 3 SDB 4 SPR Broker SPR Broker SPR Broker SPR Broker PC A PC A PC B PC B 15. ábra PCRF SDB redundancia modell [14] DRA (Diameter Routing Agent) A DRA kapcsolatait a 16. ábra mutatja. Minden egyes site-hoz tartozik egy saját P-Gw. Ha valamelyik Gw felmondja a szolgálatot, a másik Gw veszi át a szerepét. Telephelyenként egy, vagy több DRA-ra van szükség a Diameter üzenetek továbbítására. Jelen esetünkben 2-2 darab működik. Minden esetben a DRA-k aktive/standby kapcsolatban állnak. Az aktív eszköz birtokolja a VIP (Virtual IP) címet. Itt fontos kiemelni, hogy ez az aktive/standby kapcsolat csupán a VIP cím birtoklására igaz, vagyis minden eszköz aktívan részt vesz a hívások irányításában. A P-Gw a VIP címen keresztül éri el a klasztert. Klaszteren belül egy belső algoritmus alapján dől el melyik ügynök szolgálja ki a kérést, vagyis az aktív eszköz átadhatja a kiszolgálás lehetőségét a másik ügynöknek, ezzel javítva a terheléselosztást. Egy telephelyen belül a session-ök megosztásra kerülhetnek az ügynökök között, így hiba esetén az egyik eszköz át tudja venni a másik szerepét. Ez viszont nem igaz telephelyek között. Ahogy az a 16. ábrán látható Minden DRA minden PCRF-fel is kapcsolatban van [14]. 28

29 16. ábra DRA redundancia modell [13] BMS (Bridgewater Management System) A Telephelyenként 1-1 BMS található, mely a rendszerről gyűjt SNMP, KPI, log információkat. Mindkét eszköz aktívként működik, vagyis mindkét szerver megkapja az összes SNMP, KPI, log információkat minden PCRF-től és egymástól is. Hiba esetén a megfelelően működő BMS zavartalanul tudja folytatni a munkáját [14]. 17. ábra BMS redundancia modell [14] 29

30 4.2 Egyszeres csomópont meghibásodás PCRF meghibásodás SDB 1 SDB 2 SDB 3 SDB 4 PC A PC A PC B PC B WAN Replication Heartbeat DRA DRA DRA DRA VIP VIP Gateway / DPI Gateway / DPI 18. ábra Site-on belüli PCRF meghibásodás [14] Ha egy telephelyen belül csak egy Policy Controller hibásodik meg, az transzparens a PCEF számára. Hiszen a DRA-nak csupán annyi a dolga, hogy a site-on belüli másik PC-hez irányítsa a kérést, mely ugyanúgy rendelkezik a teljes session és felhasználói adatokkal, mint az elsődleges Policy Controller. Ha a hibás Controller helyreáll, automatikusan frissíti saját adatbázisát [13][14] SDB meghibásodás Ha bármelyik SDB meghibásodik, az teljesen transzparens a Gw számára. A Policy Controller átkapcsol a másodlagos SDB csomópontra. Ugyanez a helyzet, ha az összes csomópont meghibásodik egy telephelyen belül (ez az egyszerűség kedvéért nem látszódik a 19. ábrán). Miután helyreállt a meghibásodott SDB a rendszer visszakapcsol az elsődleges csomópontra [14]. 30

31 SDB 1 SDB 2 SDB 3 SDB 4 PC A PC A PC B PC B WAN Replication Heartbeat DRA DRA DRA DRA VIP VIP Gateway / DPI Gateway / DPI 19. ábra Site-on belüli BMS meghibásodás [14] DRA meghibásodás Egy DRA hiba minimális hatással van az átjáróra. Ha egy DRA meghibásodik a másodlagos DRA veszi át a szerepét, ez azt jelenti, hogy ő fogja birtokolni a VIP címet. Ez a folyamat több másodpercig is eltarthat. Ez idő alatt a Gw a kéréseket a másik telephelyen található DRA-hoz továbbítja (hiszen az elsődleges telephelyen ez időben nem elérhető a VIP cím), mely visszairányítja a kérést az elsődleges telephelyen lévő DRA-k felé. A CCR-U/CCR-T (Credit Connection Request Update / Credit Connection Request Termination) üzenetek nem tartalmazzák az előfizetői azonosítókat (MSISDN vagy IMSI), ezért a másodlagos DRA azt feltételezi, hogy az elsődleges klaszterben megtalálhatóak ezek az adatok. Ebben az esetnem a távoli ügynök visszairányítja az üzenetek a helyi ügynöknek, mely továbbítja azt a megfelelő PCRF felé. Az alábbi ábrán ez az eset kerül szemléltetésre [14][15]. 31

32 20. ábra DRA meghibásodás üzenet áramlása [13] 1-4. A kapcsolat rendben felépül, mikor is a klaszteren belül a VIP-et birtokló DRA meghibásodik, megkezdődik a VIP cím átkapcsolása, melyet a PCEF érzékel. 5. A Gw elküldi a CCR-U üzenetet a távoli site-on lévő DRA2-nek 6. A DRA2 nem találja a felhasználói azonosítót az üzenetben, és mivel a kapcsolat állapotok nem replikálódnak a site-ok között, visszairányítja a CCR-U üzenetet a DRA1-nek. 7. A helyi telephelyen lévő DRA felismeri a session ID-t a CCR-U üzenetben, majd továbbítja a kérést a megfelelő PCRF-nek A helyi telephelyen lévő DRA küld egy válaszüzenetet (Gx CCA Credit Connection Answer) a távoli DRA-nak, mely továbbítja azt az átjáró felé. 32

33 Alternatív lefutási lehetőségek: 6. Ha a helyi DRA nem találja a kapcsolat azonosítót, saját táblájában, akkor DIAMETER_UNABLE_TO_DELIVER hibaüzenettel válaszol. Ha mindkét DRA halott a helyi telephelyen, akkor a távoli DRA DIAMETER_UNABLE_TO_DELIVER hibaüzenettel válaszol a PCEFnek. 4.3 Geo - Redundancia (GR) Teljes Site-on belüli PCRF kiesés SDB 1 SDB 2 SDB 3 SDB 4 PC A PC A PC B PC B WAN Replication Heartbeat DRA DRA DRA DRA VIP VIP Gateway / DPI Gateway / DPI 21. ábra Teljes Site-on belüli PCRF kiesés [15] Amikor egy telephelyen belül az összes PCRF csomópont meghibásodik, akkor a DRA átirányítja a forgalmat, annak egy másik telephelyen lévő (Geo-redundáns GR) párjához. Az ábrán PC A-nak PC B, és vice versa a GR párja. Míg nincs meghibásodás a PC A és a PC B egymástól függetlenül végzi a dolgát, majd, ha a PC B nem érzékeli, egy előre definiált ideig az inter-klaszter heartbeatet, átveszi PC A szerepét. Míg az átkapcsolás nem történik meg, az újonnan érkező üzenetek elutasításra kerülnek. Miután a PC B észrevette, hogy a PC A elérhetetlen elkezdi feldolgozni PC A felé menő kéréseket, ami a gyakorlatban azt jelenti, hogy PC B dolgozza fel az eredetileg PC A-nak szánt CCR-I üzeneteket. Mivel a Diameter session információk 33

34 mindig csak az egyik telephelyen érhetőek el egyszerre és ezeket nem lehet átadni, a CCR-U/CCR-T üzenetekre DIAMETER_UNKNOWN_SESSION_ID-val fog válaszolni a B telephelyen található Controller. Ezeket a kapcsolatokat ilyenkor újra fel kell építeni, hogy a tartalék telephelyen is szerepeljenek a megfelelő információk az adatbázisban, a zavartalan működés érdekében. Ha a PC A újra elérhető, és a felhasználói adatok visszaállításra kerültek, a DRA visszakapcsol az A site-ra, és PC B nem dolgozza fel tovább A ügyfeleinek kéréseit [14][15] Teljes Site-on belüli DRA kiesés Mikor az összes DRA leáll az egyik telephelyen, az átjáró átkapcsol a másik telephelyen lévő geo-redundáns VIP címre. Mivel a Diameter session állapot információk nem replikálódnak a telephelyek között (pl. Gx: CCR-U/T), ezeket a kapcsolatokat újra kell építeni. Az új kapcsolódás során a Gw már a B oldalon található DRA felé fogja irányítani a kapcsolatkérést, ahol a DRA visszairányítja azt az A oldali PCRF-ekhez. Ezt azért teheti meg, az ábrán ugyan nem látszódik a könnyebb áttekinthetőség kedvéért, mert minden DRA minden PCRF-fel össze van kapcsolva [14]. SDB 1 SDB 2 SDB 3 SDB 4 PC A PC A PC B PC B WAN Replication Heartbeat DRA DRA DRA DRA VIP VIP Gateway / DPI Gateway / DPI 22. ábra Teljes Site-on belüli DRA kiesés [14] 34

35 4.3.3 Teljes Site kiesés Abban az esetben, ha az egész A telephelyet valamilyen katasztrófa éri és leáll, akkor a PCEF átkapcsol a B telephely VIP címére. Majd a pontnak megfelelően PC B veszi át PC A felhasználóinak feldolgozását. A katasztrófa helyre állítása után természetesen az átjáró visszakapcsol az A telephelyhez tartozó VIP címre, ezáltal visszakerül a feldolgozás feladata is [14]. SDB 1 SDB 2 SDB 3 SDB 4 PC A PC A PC B PC B WAN Replication Heartbeat DRA DRA DRA DRA VIP VIP Gateway / DPI Gateway / DPI 23. ábra Teljes Site kiesés [14] 35

36 5 Peer-to-peer forgalom szűrése A dolgozat első felében megismerkedtünk a nagysebességű hálózattokkal, mindez hogyan valósul meg szolgáltatói szemszögből, ezen kívül megismerkedtünk a PCRF felépítésével, alapvető működésével, a reprezentatív felhasználó működésével. Innentől azt veszem górcső alá, hogyan rendelhetünk külön szolgáltatásokat akár egyedi felhasználókhoz, de jellemzően felhasználók egy csoportjához, vagyis megismerkedhetünk a Provisioning folyamataival. Mindezt egy saját Use-Case keretein belül mutatom meg. Napjainkban a mobil távközlésben az egyik legnagyobb problémát a szűkös frekvenciatartomány jelenti. Így jogosan merülhet fel az igény szolgáltatói oldalról, hogy a nemkívánatos peer-to-peer forgalmat, mely igen jelentősen terhelheti a hálózatot, szűrni lehessen. Az általam megvalósított koncepció szerint a felhasználó, igény szerint meg tudja vásárolni, le tudja mondani a szolgáltatást, mindezt akár online állapotban is, igazodva ezzel a valós élet igényeihez. A megvalósítás során csupán a PCRF működésére koncentráltam, a PCRF szemszögével nézve a háttérrendszerek működésével nem foglalkozom. A PCRF szemszögéből nézve teljesen mindegy, hogy a felhasználó SMS-ben, vagy az erre a célra kialakított honlapon vásárolja meg a szolgáltatást, csupán az a lényeg, hogy a BSS (Business Support System) rendszerek felöl, melyek a provisioningelést végzik, a megfelelő parancs jöjjön, azokat megfelelően kezelje. Ugyanígy túlmutat a dolgozatomon az, hogy a P2P szűrés milyen módon megy végbe, hiszen ezt a feladatot a P-Gw DPI funkciója végzi, csupán csak azt vizsgálom, hogy a PCRF az elvártnak megfelelő üzeneteket küldi és fogad-e. 5.1 A peer-to-peer forgalom hatása A peer-to-peer forgalom jelentősen terheli a hálózati erőforrásokat, mely nem csak a hálózat életére, de az előfizetők elégedettségére is hatással lehet. Ebben a fejezetben az Olvasó megismerkedhet a peer-to-peer forgalom tendenciáival, illetve bepillantást nyer, hogy miként hat ez a különböző hálózatokra (fix, és mobil). Ezen kívül néhány védekezési lehetőség is ismertetésre kerül. 36

37 5.1.1 A peer-to-peer forgalom alakulása Az első peer-to-peer alkalmazás a Napster volt, mely a 2000-es évek elején volt kifejezetten népszerű a felhasználók körében. A Napster tulajdonképpen egy átmenetet képzett a hagyományos kliens-szerver típusú fájlcserélők (pl. FTP) és a mai peer-to-peer alkalmazások között. Az átmenetet az képezte, hogy ugyan a felhasználók adatait egy központi szerver tárolta, mely segített a kapcsolatok létrehozásában, viszont a tényleges fájlcserét már a kliensgépek végezték egymás között [18]. Miután a zenei szolgáltatók jogi úton elérték, hogy a Napster bezárja kapuit, hamar új megoldások születtek (Kazaa, Direct Connect, Gnutella), de az igazi áttörést a Bittorrent jelentette. A Bittorrent től van jelen az internet világában, és népszerűsége azóta is töretlen. Elterjedtségét az okozza, hogy már nem csak kis fájlok (pl. zenék) megosztására alkalmas, hanem a nagyméretű állományokat is remekül kezeli. A P2P forgalom vizsgálatával több cég is foglalkozik, hiszen hatása igen jelentős a szolgáltatókra, és a teljes hálózatra nézve is. Az alábbi táblázatban a as Ipoque és a as Cisco jelentést foglalom össze [16][19][20]. Protocol P2P (%) 66,41 55,49 29,30 24,70 24,30 Web (%) 24,53 24,95 18,82 18,09 19,31 Streaming (%) 3,91 7,32 50,79 56,32 55,51 1. táblázat Ipogue és Cisco adatok alapján készült forgalomstatisztika A két cég által kapott eredmények nem hasonlíthatóak össze 100%-osan, hiszen különböző eljárással vették górcső alá a hálózati forgalmat. Viszont az jól látszódik a táblázatból, hogy a P2P forgalom kezd visszaszorulni, a feltörekvő az online videózás mellékhatásaként. Viszont azt is kijelenthetjük, hogy még így is jelentősen jelen van a mindennapi életünkben, hiszen a forgalom mintegy negyedét teszi ki jelenleg is. Az eddigiekben a fix hálózatokra jellemző adatokat mutattam be, a mobilhálózatokra, értelemszerűen, más adatok érvényesek. A Cisco legújabb tanulmánya szerint a mobilhálózatok adatforgalmában egyértelműen a felhő alapú video tartalmak viszik a prímet, mely nemhogy csökkenne a jövőre nézve, inkább növekedni látszik. Mindezt teszi a P2P forgalom, és az web forgalom kárára. A jelenlegi 10% környéki P2P forgalom 2017-re 3,5% körüli értékre esik vissza (2. táblázat) [16]. Ez ugyan kevésnek tűnik, de figyelembe véve azt a tényt, hogy rádiós közegről beszélünk, még ez is jelentős hatással lehet a hálózatra. Ezt támasztja alá a Sandivine 2012-es 37

38 tanulmánya is, mely a Cisco riportjához hasonlóan 10% körüli összesített P2P forgalmat mért Európában. Viszont a feltöltés és letöltés aránya meghökkentő: éppen a jóval kisebb sávszélességű feltöltést érinti kritikusan, a feltöltés mintegy 20%-a P2P forgalom [21]. Protocol Class Data (%) 35,43 33,40 31,17 29,13 27,04 24,91 File Sharing (%) 10,46 9,03 7,68 6,34 4,96 3,54 Video (%) 51,44 54,40 57,32 60,31 63,38 66,50 M2M (%) 2,66 3,17 3,82 4,22 4,62 5,05 2. táblázat Cisco mobil adatforgalom eloszlás előrejelzése [16] Mind az Ipoque mind a Cisco tanulmány sokat foglalkozik a forgalom regionális eloszlásával [16][17][19]. Kijelenthető, hogy a Közép- és Kelet-Európai régióra a legjellemzőbb az elosztott fájlcserélés. Ehhez hozzávéve azt a tényt, hogy ebben a régióban az előfizetők jelenleg inkább laptopon használják a mobilinternet előfizetésüket, különösen igaz ez a negyedik generációs hálózatra, illetve a 4G képes eszközök magas ára miatt, ez az állítás a mobileszközöknél is fennáll. Bár a teljességhez szükséges megjegyezzem, a csökkenő tendencia erre a régióra is igaz Lehetséges szolgáltatói reakciók Tolerancia A szolgáltatói reakciók közül a legegyszerűbb lehetőség, ha nem tesznek semmit az előfizetők megzabolázása érdekében. Ez abban az esetben lehet kifizetődő, ha a P2P forgalom elenyésző mértékben van jelen a hálózatban, a felhasználók elégedettségéből származó bevétel fedezi, vagy meghaladja a peer-to-peer forgalomból fakadó költségeket. Ezzel egyenértékű, bár mégis egy árnyalatnyival szigorúbb lehetőség, hogyha a szolgáltató ugyan a hálózatában nem használ semmilyen detektáló, szűrő eljárást, viszont az Általános Szerződési Feltételek (ÁSZF) közt, tiltja annak használatát. Ennek a célja az elrettentés lehet, más kérdés az, hogy ez milyen visszatartó erővel hat. Addig, amíg nem szivárog ki, vagy a felhasználók nem jönnek rá, hogy a szolgáltató semmilyen lépést nem tesz a forgalom szűrésére, addig hatásos módszer lehet. Viszont mindenképpen elrettentő lehet az új ügyfelek számára, akik ennek hatására könnyen más szolgáltatót választhatnak [23]. 38

39 Forgalomanalízis alapú szankciók Egy másfajta megoldás lehet szolgáltatói oldalról, ha valamilyen módon forgalom analízist végeznek, majd az így kapott eredményeket felhasználva, valamilyen szankcióval élnek. Ez a szankció a szolgáltató vérmérsékletétől függően különböző lehet. Talán a legegyszerűbb, ha az azonosított P2P forgalom után valamilyen plusz előfizetési díjat számol fel a szolgáltató. Egy másik hatásos módszer lehet, ha a szolgáltató teljes egészében blokkolja a nem kívánatos forgalmat. Ebbe a családba tartozik az a lehetőség is, ha a forgalom szűrve van, és a káros adatforgalmat valamilyen úton-módon korlátozza. Ez lehet például sávszélesség csökkentés, vagy minőségosztályokba sorolás esetén alacsony prioritás választása. A közös az imént említett esetekben, hogy szolgáltatói oldalon ez befektetéssel jár, hiszen szűrést végző hardver és szoftver elemeket be kell szerezni. Másik probléma ezzel a megoldással, hogy a szolgáltató mindig egy lépés hátrányban lesz az előfizetőkkel szemben, hiszen ha egy alkalmazást kiszűrt az előfizetők átpártolhatnak egy másikra, mely nem szerepel a szolgáltatói adatbázisban. Sőt sok esetben az is elegendő, hogyha az előfizető rendszeresen frissíti az általa használt alkalmazást. Előnye a megoldásnak az, hogy a becsületes felhasználók nem rettennek el a szolgáltatótól [22][23] Chacing Egy egészen eltérő megközelítés, ha a szolgáltató nem szankciókat vezet be a P2P forgalom ellenében, hanem valamilyen úton támogatja azt. Ilyen megoldás, mikor egy caching szervert telepít, mely ideiglenesen eltárolja a leggyakrabban használt tartalmat, és onnan szolgálja ki a kéréseket. Ez azért is előnyös lehet, mert nem csak a peer-to-peer forgalom gyorsítására használható, hanem tetszőleges tartalomra, WEB, video, stb. Hátránya, hogy ez is komoly beruházásokkal jár, illetve jogi problémák is felmerülhetnek a tárolt tartalommal kapcsolatban. Egy másik probléma ezzel a megoldással kapcsolatban, hogy a mobilszolgáltatók problémáját, miszerint a P2P forgalom terheli a drága rádiós erőforrásokat, nem oldja meg [22][23]. 5.2 Hálózati struktúra A vezeték nélküli területen jelenleg több technológia is jelen van, a területi adottságok függvényében. A ritkán lakott vidéki területeken 2,5G (GPRS és EDGE) lefedettség, míg a sűrűn lakott területeken 3G (HSDPA, HSUPA, HSPA+), esetleg néhány nagyvárosban 4G (LTE) érhető el. Ez a felépítésben azt eredményezi, hogy 39