NAGYSEBESSÉGŰ CELLÁS MOBILHÁLÓZATOK …zfaigl/QoS/doc/freePCRF/Nagysebessegu-cellas... · sikerességér ől a bemutatott Wireshark felvételek, logok, adatbázis lekérdezések

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

Tartalomjegyzék

Összefoglaló ..................................................................................................................... 5

Abstract ............................................................................................................................ 6

1 Bevezetés ....................................................................................................................... 7

2 A mobil világ változásai ............................................................................................... 9

2.1 Felhasználói tendenciák .......................................................................................... 9

2.2 Mobilhálózatok fejlődése ...................................................................................... 10

2.2.1 Rádiós hozzáférési hálózat különbségei ........................................................ 11

2.2.2 Maghálózat különbségei ................................................................................ 12

2.2.3 Jelzésüzenet megváltozása ............................................................................. 13

2.2.4 Forgalommenedzsment és számlázás ............................................................ 13

3 PCRF architektúra .................................................................................................... 15

3.1 Policy Controller (PC) .......................................................................................... 16

3.1.1 A PC részei .................................................................................................... 16

3.2 Subscriber Data Broker (SDB) ............................................................................. 18

3.3 Diameter Routing Agent (DRA) ........................................................................... 19

3.4 Bridgewater Management System (BMS) ............................................................ 20

3.5 Hívásfelépítés ........................................................................................................ 20

3.5.1 Csatlakozás reprezentatív felhasználóként (XXL profil)............................... 21

3.5.2 Csatlakozás nem reprezentatív felhasználóként (M profil) ........................... 22

3.5.3 Felépült kapcsolat közti sebességszűkítés (XXL/M profil) ........................... 23

4 Site és Geo-redundancia ............................................................................................ 25

4.1 Telephelyen belüli redundancia ............................................................................ 26

4.1.1 PCRF (Policy Charging and Rule Function) ................................................. 26

4.1.2 SDB (Subscriber Data Broker) ...................................................................... 27

4.1.3 DRA (Diameter Routing Agent) .................................................................... 28

4.1.4 BMS (Bridgewater Management System) ..................................................... 29

4.2 Egyszeres csomópont meghibásodás .................................................................... 30

4.2.1 PCRF meghibásodás ...................................................................................... 30

4.2.2 SDB meghibásodás ........................................................................................ 30

4.2.3 DRA meghibásodás ....................................................................................... 31

4.3 Geo - Redundancia (GR) ...................................................................................... 33

4.3.1 Teljes Site-on belüli PCRF kiesés ................................................................. 33

4.3.2 Teljes Site-on belüli DRA kiesés ................................................................... 34

4.3.3 Teljes Site kiesés ............................................................................................ 35

5 Peer-to-peer forgalom szűrése .................................................................................. 36

5.1 A peer-to-peer forgalom hatása ............................................................................ 36

5.1.1 A peer-to-peer forgalom alakulása ................................................................ 37

5.1.2 Lehetséges szolgáltatói reakciók ................................................................... 38

5.2 Hálózati struktúra .................................................................................................. 39

5.3 PCRF szabályrendszer kialakítása ........................................................................ 41

5.3.1 Service Manager ............................................................................................ 41

5.3.2 PCRF konfiguráció ........................................................................................ 43

5.4 Elvárt működés specifikálása ................................................................................ 45

5.4.1 XXL felhasználó létrehozása ......................................................................... 45

5.4.2 XXL felhasználó létrehozása P2P engedélyezéssel ....................................... 47

5.4.3 Hívás közben történő P2P aktiválás............................................................... 49

5.4.4 Hívás közben történő P2P deaktiválás ........................................................... 51

5.4.5 Kapcsolat közben történő sávszélesség csökkentés P2P engedélyezéssel ..... 52

5.5 Provisioning interfész ........................................................................................... 53

5.5.1 Provisioning parancsok .................................................................................. 53

6 Megfelelőség vizsgálat ................................................................................................ 58

6.1 XXL felhasználó létrehozása a gyakorlatban ....................................................... 58

6.2 XLL felhasználó létrehozása P2P engedélyezéssel a gyakorlatban ...................... 61

6.3 Hívás közben történő P2P aktiválás a gyakorlatban ............................................. 63

6.4 Hívás közben történő P2P aktiválás a gyakorlatban ............................................. 64

6.5 Kapcsolat közben történő sávszélesség csökkentés P2P engedélyezéssel a

gyakorlatban ................................................................................................................ 65

7 Összegzés, kitekintés .................................................................................................. 68

Köszönetnyilvánítás ...................................................................................................... 69

Irodalomjegyzék ............................................................................................................ 70

Rövidítésjegyzék ............................................................................................................ 72

Ábrajegyzék ................................................................................................................... 74

Táblázatok ..................................................................................................................... 76

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, 2013. 05. 26.

...……………………………………………. Patai Árpád

Ö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-to-

peer 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.

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

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.

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 2012-2017 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.

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. 2017-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 2012-2017 [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.

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]

2.2.1 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].

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

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

2.2.4 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ő

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].

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]

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-to-

peer 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.

3.1.1 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]

3.1.1.1 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.

17

3.1.1.2 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 geo-

redundáns PCRF tartalmaz, ha van ilyen [15][14].

18

3.1.1.3 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.

3.1.1.4 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].

3.1.1.5 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

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 geo-

redundá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

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.

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.

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

6: Retrieve

Qouta/QoS

7: Return

Quota/QoS

9: QoS = default XXL

Store in the session

table10: PolicyNotifyRequest

MSISDN, set "M"

11: PolicyNotifyResponse

12: Gx RAR

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.



8. Az IPMS nyugtázza a CCR-I üzenetet, CCA-I üzenettel.

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.

3.5.3 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).



4. Az IPMS nyugtázza a frissítés kérést.

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.

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ő.

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

4.1.1 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].

PolicyController A

Sessions

State

Cache

PolicyController A

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].

27

Policy

Controller A

Sessions

State

Cache

Policy

Controller A

Sessions

State

Cache

Policy

Controller

Policy

Controller

Heartbeat

Replication

13. ábra PCRF helyi redundancia [14]

4.1.2 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

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]

4.1.3 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].

29

16. ábra DRA redundancia modell [13]

4.1.4 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]

30

4.2 Egyszeres csomópont meghibásodás

4.2.1 PCRF meghibásodás

Gateway / DPI

WAN Replication

DRADRA

Heartbeat


PC A PC A

DRADRA

PC B PC B

VIP

Gateway / DPI

VIP

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].

4.2.2 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].

31

Gateway / DPI

WAN Replication

DRADRA

Heartbeat


PC A PC A

DRADRA

PC B PC B

VIP

Gateway / DPI

VIP

19. ábra Site-on belüli BMS meghibásodás [14]

4.2.3 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].

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.

8-10. 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é.

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 PCEF-

nek.

4.3 Geo - Redundancia (GR)

4.3.1 Teljes Site-on belüli PCRF kiesés

Gateway / DPI

WAN Replication

DRADRA

Heartbeat


PC A PC A

DRADRA

PC B PC B

VIP

Gateway / DPI

VIP

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

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].

4.3.2 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].

Gateway / DPI

WAN Replication

DRADRA

Heartbeat


PC A PC A

DRADRA

PC B PC B

VIP

Gateway / DPI

VIP

22. ábra Teljes Site-on belüli DRA kiesés [14]

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 3.3.1 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].

Gateway / DPI

WAN Replication

DRADRA

Heartbeat


PC A PC A

DRADRA

PC B PC B

VIP

Gateway / DPI

VIP

23. ábra Teljes Site kiesés [14]

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.

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 2004-

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 2007-

2008-as Ipoque és a 2011-2013-as Cisco jelentést foglalom össze [16][19][20].

Protocol 2007 2008 2011 2012 2013

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 2007-2008 Ipogue és 2011-2013 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

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 2012 2013 2014 2015 2016 2017

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 2012-2017 [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.

5.1.2 Lehetséges szolgáltatói reakciók

5.1.2.1 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].

39

5.1.2.2 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].

5.1.2.3 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

40

egyszerre vannak jelen a fenti technológiák kiszolgáló csomagkapcsolt eszközei a

hálózatban, ahogy az a 24. ábrán látható.

24. ábra A Magyar Telekom hálózata[11]

A 3G-re előfizető felhasználók csupán a 2G/3G hálózatokat, míg az LTE

szolgáltatásra előfizetők elérhetik mind a 2G/3G és a 4G hálózatokat is. Erre

természetesen a lefedettségi korlátok miatt van szükség. Az új technológia felhasználóit

a P-GW, míg a régi technológia ügyfeleit az SGSN szolgálja ki. A tervek szerint a

későbbiekben az új P-GW átveszi majd az SGSN és GGSN szerepkörét is, vagyis

minden felhasználó ezen az átjárón keresztül éri majd el a világhálót [11].

Jelenleg két számlázási rendszer működik egymás mellett, a PostPaid rendszer

mely főként a számlák előállításáért felelős, illetve emellett működik egy PrePaid

(Online) rendszer, mely folyamatosan nyilvántartja az összes adatfelhasználóra a

leforgalmazott adatmennyiséget. Ezen két rendszer fogja megszemélyesíteni a

Provisioning alrendszert. A felhasználható adatforgalom kvóták alapján van

szabályozva, a QM (Quota Manager) által. Ha egy felhasználó leforgalmazta az általa

felhasználható adatmennyiséget, az IPMS sávszűkítést küld a GGSN felé 3G esetén,

41

míg 4G estén a PC-nek (Policy Controller) küldi azt. Ekkor a PC egy RAR üzenettel

értesíti a P-Gw-t, mely beállítja a szabálynak megfelelő sávszélességet.

A szürkével ábrázolt terület a PCRF alrendszer. A PCRF ugyan nem az EPC

része, de szorosan kapcsolódik hozzá. A 3GPP erősen ajánlja annak használatát. A

PCRF egyidejűleg nyújt szolgáltatásokat, mind vezeték nélküli, mind vezetékes

hálózatokban, mely egy olyan szolgáltatónak, mint a Magyar Telekom, ahol mindkét

terület képviselteti magát nélkülözhetetlen.

5.3 PCRF szabályrendszer kialakítása

Alapvetően a SPR adatbázist háromféleképpen tölthetjük fel. Egy GUI-val

rendelkező programon keresztül manuálisan (Service Manager), Provosioning API-t

használó XML parancsokkal keresztül, vagy a Provisioning interfészen keresztül szintén

XML utasításokat használva. Az első két említett alkalmazás az üzemeltetőknek,

fejlesztőknek nyújt hatalmas segítséget. Még a harmadik alkalmazás az automatizált

Provisioning során használható kiválóan. Személy szerint a megvalósítás közben a

Service Managert és az API-t használtam. A Service Manager-t a logika

megvalósításához, míg az API-t a Provisioning szimulálására.

5.3.1 Service Manager

A Service Manager a következő lényeges részekből tevődik össze:

• Organization • Domain

• User • User Profile Set • Service Component

• PCC Rules • PEP Profile

• Service Mapping

Ezen kívül, természetesen rengeteg más lehetőséget is tartalmaz, de ennek

részletezése túl mutat eme dokumentum keretein.

Organization:

Az Organization határozza meg, hogy mely szervezeti egységhez szeretnénk a

felhasználókat hozzárendelni. A legmagasabb szintű szervezeti egység a Root

Organization. Minden új szervezeti egységet csak ez alá rendelhetünk, hierarchikusan.

42

Domain:

Minden szervezeti egységhez kötelezően kell tartoznia egy Domain-nek, viszont

egy Domain több szervezeti egységhez is tartozhat. Egy Domain-en belül minden

felhasználónak egyedinek kell lennie.

User:

A felhasználók, melyekhez egyedi szolgáltatások tartoznak. Dolgozatomban a

felhasználókat az MSISDN számukkal fogom azonosítani.

User Profile Set:

Meghatározza a szolgáltatásokat és azok jellemzőit egy adott felhasználói

csoportra. Segítségével meghatározható, hogy mely felhasználó, mely szolgáltatásokhoz

férhetnek hozzá.

Service Component:

A Service Component-ek a felhasználókhoz vannak rendelve. A SC-eken

keresztül tudunk a felhasználókhoz szolgáltatásokat rendelni.

PCC Rules:

A PCC Rules tartalmazza a szabály elnevezéseket, melyeket végül a PCRF

elküld a P-Gw számára. A Gw ezeket a szabályokat tudja értelmezni, és az értelmezett

szabályokon keresztül állítja be az adott session-höz a megfelelő QoS értékeket.

PEP Profile:

A PEP Profilokat tulajdonképpen a szabályok csoportosítására használhatjuk.

Használatával egyidejűleg több szabály rendelhető össze.

43

Service Mapping:

A Service Mapping funkción keresztül tudjuk összekapcsolni a Service

Component-eket és a PEP profilokat. Vagyis tulajdonképpen itt mondjuk meg, hogy az

adott SC-ek együttállása esetén a PCRF milyen szabályokat küldjön a Gateway felé.

Ezzel a lehetőséggel, gyakorlatilag tetszőlegesen bonyolult üzleti logika megvalósítható.

5.3.2 PCRF konfiguráció

Az előzőekben látható volt, milyen elemeket kell tartalmaznia a PCRF

konfigurációnak, hogy egy konkrét feladatot meg tudjunk valósítani. A feladatom során

az alábbi összetevőket, azonosítókat fogom alkalmazni.

A környezet kialakításához használatos azonosítókat a 3. táblázat mutatja. A

Root Organization alá a Telekom kerül, míg ez alá a MagyarTelekom alszervezeti

egység (25. ábra). Ez jól mutatja a vállalti szerveződést. Domain névnek a telekom.hu-

ra esett a választás. Míg a Service Component-eket a Diploma Profile Set-hez fogom

rendelni.

Service Manager Konfiguráció

Organization név Telekom

Suborganization név MagyarTelekom

Domain név telekom.hu

Profile Set Diploma

3. táblázat Service Manager Konfiguráció

25. ábra Vállalati kialakítás

A választott feladathoz az 4. táblázatban szereplő Service Component-ekre lesz

szükség. Vagyis szükség lesz egy SC_XXL komponensre, mely az internet

adatforgalom sebességét és leforgalmazható adatmennyiség nagyságát szimbolizálja. Az

XXL csomag a legnagyobb választható csomag. Ennek mintájára létrehozható XL, M, S

stb. csomag is mely mind más-más sebességet, adatforgalmat tartalmazhat.

Dolgozatomban csupán egyetlen internet szolgáltatást szimbolizáló csomagot

44

alkalmazok, hiszen egyetlen csomag is elegendő a működés bemutatására. A csomagban

foglalt sebességet és adatforgalmat nem specifikálom, mivel egyrészt ez az üzleti döntés

részét képezi, másrészt tetszőlegesen konfigurálható mindkét érték a Gatewayben. Ezen

kívül szükség lesz még egy SC_TORRENT nevezetű komponensre, mely azt mutatja

meg, hogy a felhasználó megvásárolta-e a torrent forgalomengedélyező szolgáltatást,

vagy sem, illetve szükségem lesz még egy PROFILE_ID_10 nevezetű komponensre,

mely akkor kerül alkalmazásra, ha a felhasználó elforgalmazta a csomagjához tartozó

adatforgalom keretet.

Elérhető Service Components

SC_XXL

SC_TORRENT

PROFILE_ID_10

4. táblázat Elérhető szoláltatás komponensek

Az 5. táblázat a Service Mapping kapcsolatokat mutatja meg, vagyis ebben a

táblázatban látható, hogy mely komponensek együttállása milyen szabályokat von maga

után. A negyedik és az ötödik oszlop tartalmazza, hogy mely PEP Profilhoz, mely

szabályok tartoznak. Jelen esetben minden profilhoz két szabály lett rendelve.

Service Component, PEP Profile és PCC Rule kapcsolatok

Típus DT-SOAP Profile ID Service Components PEP PROFILE PCC Rules

XXL_SSD + TORRENT 10 SC_XXL, PROFILE_ID_10, SC_TORRENT PEP_XXL_SSD_TORRENT

rule_ssd, rule_torrent_enabled

XXL _SSD 10 SC_XXL, PROFILE_ID_10 PEP_XXL_SSD rule_ssd, rule_torrent_block

XXL + TORRENT SC_XXL, SC_TORRENT PEP_XXL_TORRENT rule_xxl, rule_torrent_enabled

XXL SC_XXL PEP_XXL rule_xxl, rule_torrent_block

5. táblázat Service Mapping kapcsolatok

A táblázatot böngészve még a DT-SOAP oszlop tartalma lehet idegen. Ebben az

oszlopban az szerepel, hogy szűkítés esetén az IPMS-nek milyen azonosítót kell

leküldenie a PCRF számára, ezzel összhangban lett elnevezve a komponens neve.

Fontos megemlíteni még azt, hogy a mapping során alkalmazott algoritmus az

első illeszkedés alapján történik. Így a listában szereplő profilok sorrendje kötött, hiszen

ellenkező esetben nem az elvártak szerint működne a megvalósított logika. Például

tegyük fel, hogy a PEP_XXL profil megelőzi a másik három profilt. Ez azt jelentené,

45

hogy a felhasználóhoz hiába van hozzárendelve egyidejűleg más komponens is az

SC_XXL mellett, abból kifolyólag, hogy minden profil tartalmazza az SC_XXL

komponenst mindig a PEP_XXL profilhoz tartozó szabályok jutnának érvényre.

5.4 Elvárt működés specifikálása

5.4.1 XXL felhasználó létrehozása

Az első esetben az látható, hogyan kerül létrehozásra egy felhasználó, ha csupán

egy internet szolgáltatása van. A csomag megvásárlása esetén a felhasználó végig megy

a Provisioning folyamaton, ekkor bekerül az adatbázisba. Ezután képes lesz csatlakozni

a hálózathoz. Csatlakozáskor a felhasználó megkapja az XXL profilhoz tartozó

szabályokat. Alap esetben a P2P forgalom tiltva van a felhasználó számára.

26. ábra XXL felhasználó létrehozása

46

1. A Provisioning (OSS/BSS) küld egy createUser kérést a Provservernek, a

felhasználó MSISDN számával, a ProfileSet azonosítójával és az adott

felhasználói profillal (SC_XXL).

2. A Provserver nyugtázza a kérést a User ID-val.

3. A P-Gw küld egy inicializáló üzenetet a DRA-nak.

4. A DRA továbbítja a megfelelő PCRF-nek.

5. A PCRF megnézi, hogy a felhasználó szerepel-e a gyorsítótárban (PDC), ha

nem, akkor az SPR brókeren keresztül lekérdezi a felhasználó adatait az

MSISDN szám felhasználásával.

6. A lekérdezés kimeneteleként az SPR bróker visszaadja a felhasználó profilját, ha

nem találja a felhasználót az adatbázisban, akkor a Reprezantatív felhasználónak

megfelelő profillal tér vissza.

7. A PCRF meghatározza az aktuális állapotnak megfelelő szabályokat (szükség

esetén torrent engedélyezés, sávszélesség szűkítés, stb. ) Majd generál egy CCA-

I üzenetet a megfelelő paraméterekkel, ezek után a felhasználó adatait eltárolja a

gyorsítótárban. A fenti konkrét esetben a CCA-I üzenet a rule_xxl és a

rule_torrent_block szabályokat tartalmazza, hiszen XXL felhasználóként

(SC_XXL) lett létrehozva.

8. A PCRF elküldi a DRA-nak az inicializáló üzenetre a válaszát a megfelelő

szabályokkal.

9. A DRA továbbküldi azt a P-Gw-nek, eközben létrehoz egy bejegyzést a

gyorsítótárban az adott kapcsolathoz, így a klaszteren belül minden DRA-nak

lesz információja a kapcsolatról.

10. A Gateway küld egy CCR-I kvótakérést az IPMS-nek a Gy interfészen

keresztül.

11. Az IPMS visszaadja a kvótainformációkat.

12. A kapcsolat befejeztével a P-Gw kezdeményezi a kapcsolat bontását egy CCR-T

üzeneten keresztül. A bontási okként TERMINATION_REQUEST van

megjelölve, mely a szabályos bontási kérést jelenti.

13. A DRA továbbítja az üzenetet a PCRF felé.

14. A PCRF nyugtázza azt egy CCA-T üzenetben és törli a kapcsolathoz tartozó

adatbázis bejegyzést.

47

15. A DRA visszajuttatja az üzenetet a P-Gw-nek és törli a kapcsolathoz tartozó


5.4.2 XXL felhasználó létrehozása P2P engedélyezéssel

A 6.3.1 pontban szereplő példával szemben most az internet szolgáltatás

mellé P2P szolgáltatás is jár, vagyis engedélyezve van a P2P forgalom. Ebben az

esetben a Provisioning során mind az XXL, mind a TORRENT szolgáltatás felkerült

a felhasználó neve mellé.

27. ábra XLL felhasználó létrehozása torrent engedélyezéssel

48

1. A Provisioning (OSS/BSS) küld egy createUser kérést a Provservernek, a

felhasználó MSISDN számával és az adott felhasználói profillal (SC_XXL,

SC_TORRENT)

2. A Provserver nyugtázza a kérést a User ID-val.

3. A P-Gw küld egy inicializáló üzenetet a DRA-nak.

4. A DRA továbbítja a megfelelő PCRF-nek.

5. A PCRF megnézi, hogy a felhasználó szerepel-e a gyorsítótárban , ha nem,

akkor az SPR brókeren keresztül lekérdezi a felhasználó adatait az MSISDN

szám felhasználásával.

6. A lekérdezés kimeneteleként az SPR bróker visszaadja a felhasználó profilját, ha

nem találja a felhasználót az adatbázisban, akkor a Reprezantatív felhasználónak

megfelelő profillal tér vissza.

7. A PCRF meghatározza az aktuális szabályokat, majd generál egy CCA-I

üzenetet a megfelelő paraméterekkel, ezek után a felhasználó adatait eltárolja a

gyorsítótárban. A fenti konkrét esetben a CCA-I üzenet a rule_xxl és a

rule_torrent_enabled.

8. A PCRF elküldi a DRA-nak az inicializáló üzenetre a válaszát a megfelelő

szabályokkal.

9. A DRA továbbküldi azt a P-Gw-nek, eközben létrehoz egy bejegyzést a

gyorsítótárban az adott kapcsolathoz, így a klaszteren belül minden DRA-nak

lesz információja a kapcsolatról.


keresztül.


12. A kapcsolat befejeztével a P-Gw kezdeményezi a kapcsolat bontását egy CCR-T

üzeneten keresztül.

13. A DRA továbbítja az üzenetet a PCRF felé.

14. A PCRF nyugtázza azt egy CCA-T üzenetben és törli a kapcsolathoz tartozó


15. A DRA visszajuttatja az üzenetet a P-Gw-nek és törli a kapcsolathoz tartozó


49

5.4.3 Hívás közben történő P2P aktiválás

Ebben az esetben azt mutatom be, hogyan működik az, ha a felhasználó

használat közben aktiválja a torrent csomagját. Az előző két esettel ellentétben itt már a

felhasználó szerepel az adatbázisban, ezért nem create, hanem update parancsot

használunk.

28. ábra Hívás közben történő torrent aktiválás

1. A P-Gw küld egy CCR-I üzenetet a DRA-nak.

2. A DRA továbbítja azt a PCRF-nek.

50

3. A PCRF megnézi, hogy a felhasználó szerepel-e a gyorsítótárban , ha nem,

akkor az SPR brókeren keresztül lekérdezi a felhasználó adatait az MSISDN

szám felhasználásával.

4. Az SPR bróker visszaadja a megfelelő profilt.

5. A PCRF meghatározza a szabályokat (rule_xxl, rule_torrent_block) és

generál egy Gx CCA-I válaszüzenetet.

6. A PCRF elküldi a generált üzenetet a DRA-nak.

7. A DRA továbbítja a CCA-I üzenetet a Gatewaynek.


keresztül.


10. A Provisioning (OSS/BSS) küld egy updateUser kérést a Provservernek, a

felhasználó MSISDN számával,és az adott felhasználói profillal (SC_XXL,

SC_TORRENT)

11. A Provserver nyugtázza a kérést.

12. A Provserver küld egy accountChange értesítést a PCRF-nek. Az

SC_TORRENT Service Component hozzáadásra kerül a Service Component

listához.

13. A PCRF meghatározza a küldendő szabályokat a kapott információ alapján,

majd leküldi azokat a P-Gw-nek. A PCRF csak a különbséget küldi el a

RAR üzenetben. Ebben a konkrét esetben ez azt jelenti, hogy a rule_xxl már

telepítve van, így azt nem küldi le, csupán installálja a rule_torrent_enabled

szabályt, és eltávolítja a rule_torrent_block-ot.

14. A PCRF elküldi a RAR üzenetet.

15. A DRA továbbítja azt.

16. A Gw elvégzi a szükséges módosításokat, majd elküldi nyugtát (RAA).

17. A DRA továbbítja a PCRF-nek.

51

5.4.4 Hívás közben történő P2P deaktiválás

Most annak az esetnek a szekvencia diagramja látható, ha a felhasználó

lemondja használat közben a P2P szolgáltatást. Az előző esettel megegyezően itt is

update parancsot használunk.

29. ábra Hívás közben történő torrent deaktiválás

1. A Provisioning küld egy updateUser kérést az Provserver-nek, melyben kéri az

SC_ TORRENT service component törlését.

2. A Provszerver nyugtázza a kérést.

3. A Provserver küld egy accountChange értesítést a PCRF-nek. Az

SC_TORRENT Service Component törlésre kerül a kiválasztott Service

Component listából.


majd leküldi azokat a P-Gw-nek. A PCRF csak a különbséget küldi el a RAR

üzenetben. Ebben a konkrét esetben ez azt jelenti, hogy a rule_xxl már telepítve

van, így azt nem küldi le, csupán installálja a rule_torrent_block szabályt, és

eltávolítja a rule_torrent_enabled-öt.



52


8. A DRA továbbítja a PCRF-nek.

5.4.5 Kapcsolat közben történő sávszélesség csökkentés P2P

engedélyezéssel

Végül azt mutatom be, hogyan történik a sávszélesség csökkentés. Ebben az

esetben használat közben a felhasználó eléri a havi adatforgalmi limitet, ekkor az

IPMS jelzi a PCRF számára, hogy csökkentenie kell, a PCRF ennek hatására leküldi

a Gateway számára a megfelelő szabályokat.

30. ábra Kapcsolat közben történő sávszélesség csökkentés torrent engedélyezéssel

1. Az IPMS küld egy Set&Confirm üzenetet a PCRF-nek a felhasználó MSISDN

számával, illetve a szűkítés azonosítójával (PROFILE_ID_10)

2. A PCRF nyugtázza a kérést

53


majd leküldi azokat a P-Gw-nek. A PCRF csak a különbséget küldi el a RAR

üzenetben. Ebben a konkrét esetben ez azt jelenti, hogy a rule_torrent_enabled

már telepítve van, így azt nem küldi le, csupán installálja a rule_ssd szabályt, és

eltávolítja a rule_xxl-t.




7. A DRA továbbítja a PCRF-nek

5.5 Provisioning interfész

Ahogy azt már korábban a említettem, a PCRF rendelkezik egy Provisioning

interfésszel, melyen keresztül a számlázási rendszerek regisztrálni tudják a PCRF

számára a felhasználókon esett változásokat. Az interfész XML parancsokat vár, képes

kezelni.

Dolgozatomban én is ezen XML parancsokat fogom használni egy API-n

keresztül, hiszen így tudom a leghitelesebben bemutatni a valós működét. Megtehetném

azt is, hogy a Service Manager-en keresztül manuálisan Provisioning-elem az általam

létrehozott felhasználót, viszont eme működés távol áll a valóságtól.

5.5.1 Provisioning parancsok

A Provisioning parancsoknak jól definiált formájuk van. Minden parancs a 6.

táblázatban szereplő utasítástag-ekkel kell kezdődnie.

Leíró K/O Alkalmazott Tag-ek Leírás

Version K <request> XML API verzió

Principal K <request> A Provisioning szerverhez kapcsolódó felhasználó név

Credentials K <request> Az ehhez tartozó jelszó

Name K <request>

Használandó API library neve <target>

Operation K <request>

Használandó művelet neve <target >

User API parameters K

<parameter> <user> A használandó paraméterek

6. táblázat Kötelező utasítás tag-ek

54

A második oszlop tartalmazza, hogy az adott leíró kötelező vagy opcionális. Jól

látható, hogy ezen paramétereket minden XML parancsnak tartalmaznia kell.

Alapvetően két library-t fogok használni:

• createUser

• updateUser

5.5.1.1 XXL felhasználó létrehozása

Ahogy az 5.4.1 és 5.4.2 pontban látható, ahhoz, hogy a felhasználó használni

tudja a megvásárolt szolgáltatásokat, először létre kell hozni az adatbázisban. A

létrehozáshoz a 7. táblázatban lévő kötelező és opcionális paramétereket szükséges

megadni. Dolgozatomban az opcionális paramétereket nem használom.

Leíró K/O Alkalmazott Tag-ek Leírás

Name K <name> Felhasználó név

Login-name K <login-name> Bejelntkezési név

Password K <password>

Jelszó <value>

Organization K <organization>

A felhasználóhoz rendelt szervezeti egység <qualified-name>

Domain K <domain>

A felhasználó tartománya <name>

Profile-Set K <profile-set>

A felhasználóhoz tartozó profil halmaz <qualified-name>

service-component O <service-component> <qualified-name>

Kiválasztott szolgáltatás komponens

Title O <user-information-profile> Felhasználói információ

first-name O <user-information-profile> Felhasználói információ

Initial O <user-information-profile> Felhasználói információ

last-name O <user-information-profile> Felhasználói információ

address O <user-information-profile> Felhasználói információ

city O <user-information-profile> Felhasználói információ

Province O <user-information-profile> Felhasználói információ

postal-code O <user-information-profile> Felhasználói információ

Country O <user-information-profile> Felhasználói információ

phone-number-day O <user-information-profile> Felhasználói információ

phone-number-evening O <user-information-profile> Felhasználói információ

email-address O <user-information-profile> Felhasználói információ

7. táblázat Create User Provisioning parancs, kötelező és opcionális tag-ek

Amint az látható, a felhasználó létrehozása során kötelező megadni felhasználó

és bejelentkezési nevet, mely nálam minden esetben az MSISDN szám lesz, a szervezeti

egységet, melyhez a felhasználó tartozni fog, a tartományt, és a felhasználói profil

halmazt (User Profile Set - UPS), viszont a szolgáltatás komponenst nem kötelező

55

megadni. Ez azért lehetséges, mert az UPS létrehozása során definiálni kell egy

alapértelmezett szolgáltatás komponenst, mely automatikusan hozzárendelődik a

felhasználóhoz, ha nem adunk meg szolgáltatás komponenst. Esetünkben ez az

SC_XXL profil lesz. Ezen kívül még számos felhasználóhoz tartozó adatot

megadhatunk. Ennek megfelelően munkám során az alábbi parancsot fogom a

felhasználó létrehozására használni.

Felhasználó létrehozása

<request version="2.0" principal="admin" credentials="MYSECRET">

<target name="UserAPI" operation="createUser">

<parameter>

<user>

<name>36307771894</name>

<login-name>36307771894</login-name>

<password><value>null</value></password>

<organization>

<qualified-name>/Telekom/MagyarTelekom</qualified-name>

</organization>

<domain>

<name>telekom.hu</name>

</domain>

<profile-set>

<qualified-name>/Diploma</qualified-name>

</profile-set>

</user>

</parameter>

</target>

</request>

8. táblázat Felhasználó létrehozása

5.5.1.2 XXL felhasználó létrehozása P2P engedélyezéssel

Az előző ponthoz képest, ebben az esetben szükség van a <service-component> tag-

re, hiszen nem csupán az alapértelmezett komponenst szeretnénk hozzáadni a

felhasználóhoz. Ennek alapján a kiemelt kódrészlettel egészül ki az előző parancs.

Felhasználó létrehozása torrent engedélyezéssel



<parameter>

56

<user>

<name>36307771894</name>



<organization>


</organization>

<domain>


</domain>

<profile-set>


<data-subscription-profile>

<selected-service-components is-inherited="false">

<service-component>

<qualified-name>SC_XXL</qualified-name>

</service-component>

<service-component>

<qualified-name>SC_TORRENT</qualified-name>

</service-component> </selected-service-components>

</data-subscription-profile>

</profile-set>

</user>

</parameter>

</target>

</request>

9. táblázat Felhasználó létrehozása P2P engelyéllyel

A <selected-service-components is-inherited="false"> sor azt adja meg, hogy az

öröklött szolgáltatás komponens felülírható. Ennek hiányában nem lehetnénk képesek

lecserélni az alapértelmezett komponenst.

5.5.1.3 Hívás közben történő P2P aktiválás

Az aktiválás során már szerepel a felhasználó az adatbázisban, így csupán csak

módosítani kell az adatait az adatbázisban. A módisítás nagyon hasonlóan történik, mint

az 5.5.1.2 pontban látható létrehozás, csupán a felhasznált library más.

Hívás közben történő torrent aktiválás


<target name="UserAPI" operation="updateUser">

<parameter>

<user>

<name>36307771894</name>

57



<organization>


</organization>

<domain>


</domain>

<profile-set>


<data-subscription-profile>

<selected-service-components is-inherited="false">

<service-component>

<qualified-name>SC_XXL</qualified-name>


<service-component>

<qualified-name>SC_TORRENT</qualified-name> </service-component> </selected-service-components>

</data-subscription-profile>

</profile-set>

</user>

</parameter>

</target>

</request>

10. táblázat Hívás közben történő torrent aktiválás

5.5.1.4 Hívás közben történő P2P deaktiválás

A deaktiválás során azt kell megadni, hogy mely szolgáltatás komponenst

szeretnénk törölni. Jelen esetben ez a komponens az SC_TORRENT lesz.

Természetesen itt is az update library-t kell használnunk. A szolgáltatás deaktiváláshoz

a következő sort kell a megfelelő helyre beilleszteni, ahol delete="true" attributum

jelenti a komponens törlését.

<service-component delete="true">

<qualified-name>SC_TORRENT</qualified-name>


5.5.1.5 Kapcsolat közben történő sávszélesség csökkentés P2P engedélyezéssel

A sávszélesség csökkentéshez nincs szükség provisioning parancsra. Ekkor az

IPMS utasítja a PCRF-et, hogy állítsa be a sávszélesség csökkentést. Erről bővebben az

6.5 fejezetben lesz szó.

58

6 Megfelelőség vizsgálat

Az előző fejezetben bemutattam a hogyan működik a peer-to-peer szűrés,

milyen építőkövekből áll össze, hogyan működnek együtt a különböző eszközök. Ebben

a fejezetben azt mutatom be, hogy a megtervezett szcenárió működőképes, az

előzetesen bemutatott elvárásoknak megfelel.

Az 6.1-es pontban részletesen bemutatom a működést, melyet logokkal,

képekkel és Wireshark adatokkal is alátámasztok. A további pontokban, az érdeklődés

fenntartása végett, csupán a helyes működés igazolásához elengedhetetlen adatokat

osztom meg.

6.1 XXL felhasználó létrehozása a gyakorlatban

A helyesség igazolásához a 26. ábrán látható folyamatokon fogok végigmenni.

Ahogy az ábrán látszódik a folyamat a felhasználó Provisioning-jával kezdődik. Ekkor

Az IPMS küld egy DT-SOAP parancsot (8. táblázat), majd a sikeresség jegyében a az

SPR szerver visszaadja a felhasználónak az adatbázisban használatos egyedi

azonosítóját (226128) egy XML utasításban.

<response version="2.0">


<result>

<user>

<id>226128</id>

</user>

</result>

</target>

</response>

A Service Manager-ben lekérdezve a felhasználót, látható, hogy az SC_XXL

profil beállításra került. Az is megfigyelhető, hogy az „Override inherited selected

service component” mező inaktív, mely azt jelenti, hogy a felhasználó a Diploma UPS-

hez tartozó alapszolgáltatást kapta meg, mely az SC_XXL.

59

31. ábra XXL felhasználó létrehozása (Service Manager)

Miután a felhasználó bekerült az adatbázisba, már képes felcsatlakozni. A

csatlakozás után meg kell kapnia a PEP_XXL Pep profilt, mely azt eredményezi, hogy a

P-Gw-ben a rule_xxl, rule_torrent_block dinamikus szabály lesz beállítva, hiszen

alaphelyzetben nem engedélyezett a P2P forgalom. A csatlakozással egy időben a

felhasználó adatai bekerülnek a Session táblába is. A csatlakozás a PCRF log-jában egy

START utasítással kezdődik.

May 2 22:37:13 localhost.localdomain PCRF02_PCRF02: INFO BPCOP(303)

policy pull on START for

[email protected]?PCRFGx=PCRFGx&APN_ID=t1(IP=10.5.54.60,

Session=0002-diamproxy.pgw0gx-test.telekom.hu;95684363;130836;5182ce79-

1402) successfully sent to Primary PCEF(0002-diamproxy.pgw0gx-

[email protected]) using policy([Profile="PEP_XXL" pcc

rules=rule_xxl,rule_torrent_block])

A Session táblából kiolvashatók olyan információk, mint a session azonosító

(5182ce79-1402), a domain (telekom.hu), MSISDN szám (36307771894), az aktuálisan

használt PEP profil (PEP_XXL), a használt APN neve (t1), és végül, de nem utolsó

sorban a csatlakozás és az utolsó módosítás ideje (2013-05-02 20:37:13.082000 2013-

05-02 20:37:13.082000)

60

PDC_ID: 1002

SESSION_ID: 0002-diamproxy.pgw0gx-

test.telekom.hu;95684363;130836;5182ce79

-1402

PEP_ID: 50000009

ORIGIN_HOST: 0002-diamproxy.pgw0gx-test.telekom.hu

ORIGIN_REALM: telekom.hu

PEP_STATUS_ID: <NULL>

SOURCE_ID: 1

LAST_USED_PEP_PROFILE_NAME: PEP_XXL

USER_IPV4_ADDRESS: 0A05363C

USER_IPV6_EXPANDED_PREFIX_ADDR: <NULL>

USER_IPV6_PREFIX_LENGTH: <NULL>

SUBSCRIPTION_ID_AVP: 0:36307771894

CALLED_STATION_ID: t1

EVENT_TRIGGERS: ,PLMN_CHANGE:1

INVALID_PCC_RULES: <NULL>

CREATED: 2013-05-02 20:37:13.082000

LASTMOD: 2013-05-02 20:37:13.082000

CONFLICT_RESOLUTION_TIMESTAMP: 5182CE7900014126

A Wireshark képen (32. ábra) látható, ahogy a CCR-I válaszüzenetbe a PCRF02

leküldi a szabályt a DRA02, majd utóbbinak a feladata továbbítani a szabályokat a P-

Gw felé.

32. ábra Charging Rule Install (rule_xxl, rule_torrent_block)

61

Majd végül a felhasználó bontja a kapcsolatot, ekkor a Gateway küld egy CCR-

T üzenetet a DRA0 (VIP) felé mely elküldi a bontási kérelmet a PCRF-nek. A PCRF

törli a felhasználót a Session táblából, beírja a kapcsolat bontását a messages.log

fájlban, ahol a bontást egy STOP üzenet fémjelez, majd visszaküld a DRA02 felé egy

CCA-T DIAMETER_SUCCESS üzenetet. Ezzel végül az elvártnak megfelelően

lezárult a kapcsolat.


policy pull on STOP for [email protected]?PCRFGx=PCRFGx&APN_ID=t1

from Primary PCEF([email protected]) was

successfully processed

33. ábra Bontás a PCRF02 és a DRA02 között

6.2 XLL felhasználó létrehozása P2P engedélyezéssel a

gyakorlatban

A felhasználó létrehozása során ismét a nulláról indulunk, vagyis a felhasználó

továbbra sem szerepel az adatbázisban. Viszont az előző esethez képest, most a

felhasználó rendelkezik P2P forgalom használati joggal. Provisioning során most a 9.

táblázatban szereplő parancsot kell használnunk, más szavakkal élve, az IPMS a 9.

táblázatban szereplő parancsot küldené a PCRF-nek.

A 34. ábráról leolvasható, hogy a parancs megfelelően lefutott, mind az

SC_XXL, mind pedig az SC_TORRENT komponens felkerült a felhasználóhoz. Az is

leolvasható, hogy most a „Override inherited selected service component” mező aktív,

vagyis nem a Diploma UPS-hez tartozó komponens került fel a felhasználó neve mellé.

62

34. ábra XXL felhasználó Torrent engedélyezéssel

Csatlakozás után látható, hogy a megfelelő PEP_XXL_TORRENT profil került

fel, illetve az is megfigyelhető, hogy csatlakozás után nem történt módosítás (Created,

Lastmod) mező.

PDC_ID: 2003


test.telekom.hu;55705768;70668;5182d7ec-c02

PEP_ID: 50000010



PEP_STATUS_ID: <NULL>

SOURCE_ID: 1

LAST_USED_PEP_PROFILE_NAME: PEP_XXL_TORRENT

USER_IPV4_ADDRESS: 0A05363D







CREATED: 2013-05-02 21:17:32.701000

LASTMOD: 2013-05-02 21:17:32.701000

CONFLICT_RESOLUTION_TIMESTAMP: 5182D7EC000AB61C

63

Már csak az a kérdés, hogy a megfelelő szabályok (rule_xxl,

rule_torrent_enabled) lettek-e leküldve a Gateway felé. Természetes a válasz igen,

ennek az igazolására az 35. ábra szolgál.

35. ábra Charging Rule Install (rule_xxl, rule_torrent_enabled)

6.3 Hívás közben történő P2P aktiválás a gyakorlatban

Az 5.4.3 pontban szereplő ábra szerint a felhasználó már az adatbázisban van.

Csatlakozáskor a PEP_XXL profilt kapja meg, melynek hatásaként a peer-to-peer

forgalom blokkolva van.


policy pull on START for

[email protected]?PCRFGx=PCRFGx&APN_ID=t1(IP=10.5.54.62,

Session=0001-diamproxy.pgw0gx-test.telekom.hu;90686630;87571;5182dc28-

1302) successfully sent to Primary PCEF(0001-diamproxy.pgw0gx-

[email protected]) using policy([Profile="PEP_XXL" pcc

rules=rule_xxl,rule_torrent_block])

Majd úgy dönt, hogy szeretne valamit letölteni P2P forgalmon keresztül, akkor

küld egy SMS-t a Provisioning rendszernek, vagy az erre a célra kialakított honlapon

megvásárolja az igényelt szolgáltatást, melynek hatására a Provisioning rendszer a 8.

táblázatban látható update üzenetet küldi. A PCRF session táblájában megjelenik a

változás:

64

PDC_ID: 1003


test.telekom.hu;90686630;87571;5182dc28-1302

PEP_ID: 50000100



PEP_STATUS_ID: 1005

SOURCE_ID: 1

LAST_USED_PEP_PROFILE_NAME: PEP_XXL_TORRENT

USER_IPV4_ADDRESS: 0A05363E







CREATED: 2013-05-02 21:35:37.056000

LASTMOD: 2013-05-02 21:37:00.200000

CONFLICT_RESOLUTION_TIMESTAMP: 5182DC7C00030FB0

Az update üzenet hatására a PCRF küld egy RAR üzenetet, melyben törli a

rule_torrent_block szabályt és installálja a rule_torrent_enabled szabályt. A képen

kékkel megjelölve látszódik az eltávolítandó szabály, míg fehérrel a telepítendő.

36. ábra Charging Rule Remove&Install (remove: rule_torrent_block, install:

rule_torrent_enabled)

6.4 Hívás közben történő P2P aktiválás a gyakorlatban

Ez az eset nagyon hasonlóan megy végbe az előzőhöz. Két különbség mégis

van. A provisioning rendszer az 5.5.1.4 pontban bemutatott kiegészítéssel küldi a 8.

65

táblázatban bemutatott UPDATE parancsot, illetve az eltávolítandó szabály a

rule_torrent_enabled, míg a telepítendő a rule_torrent_block lesz.

37. ábra Charging Rule Remove&Install (remove: rule_torrent_enabled, install:

rule_torrent_block)

6.5 Kapcsolat közben történő sávszélesség csökkentés P2P

engedélyezéssel a gyakorlatban

Sávszélesség szűkítésre akkor van szükség, ha a felhasználó leforgalmazta a

rendelkezésére álló adatmennyiséget. Ahogy fogy az adatmennyiség, a Gateway időről-

időre az IPMS-hez, vagyis egészen pontosan a Kvóta Menedzserhez fordul újabb adag

kvótáért. Abban az esetben, ha végleg elfogyott a kvóta az IPMS küld egy Policy Notify

üzenetet a PCRF-nek a megfelelő azonosítóval, mely ennek hatására aktiválja a

megfelelő szolgáltatás komponenst és elküldi a szűkítéshez szükséges szabályt a P-Gw-

nek.

Az IPMS szimulálására SoapUI nevezetű alkalmazást fogom használni, melynek

a segítségével képes leszek Policy Notify üzeneteket küldeni. A programnak két

funkcióját fogom használni, a lekérdezést és az üzenetküldést. A lekérdezéshez az

MSISDN számra és a domain névre van szükség.

66

38. ábra DT-SOAP lekérdezés

Amint azt a 38. ábra is mutatja a felhasználó torrent engedélyezéssel létesített

kapcsolatot, ez a kiinduló helyzet. Az állapot megváltoztatásához a 39. árán látható

kérést kell küldeni.

39. ábra Policy Notify kérés

A kéréshez szükség van az aktuális IP címre, meg kell mondani, hogy milyen

műveletet szeretnénk végezni, ez tipikusan komponens hozzáadása, vagy törlése szokott

lenni, melyet az <action> mezőben adhatunk meg. A hozzáadáshoz a 4-es action kódot

kell alkalmazni (set&confirm), míg a törlésért az 5-ös kód (remove) a felelős. Az action

kód és az IP cím mellett szükséges még a <ProfileID> megadása is. Az ID mindig

megegyezik a szolgáltatás komponens nevében lévő számmal (PROFILE_ID_10).

Ennek megfelelően a set&confirm parancs küldése után a felhasználó állapota

67

PEP_XXL_SSD_TORRENT lett (40. ábra), mely a szűkített állapotot jelenti. Ezzel

bizonyítva, hogy minden eset az elvártnak megfelelően működik.

40. ábra PEP_XXL_SSD_TORRENT

68

7 Összegzés, kitekintés

A dolgozatban megvalósított rendszer a kitűzött céloknak megfelelően hatékonyan

képes támogatni a peer-to-peer forgalom elleni harcot. A bemutatott modell rugalmas,

könnyen továbbfejleszthető, és mindemellett egyszerűen integrálható a már meglévő

szolgáltatások mellé.

A jövőbeni módosítása több irányban is történhet:

• A legfontosabb, hogy a meglévő szolgáltatás palettát árnyaljuk, vagyis a

jelenlegi szolgáltatás mellé kidolgozzunk egy szolgáltatáscsaládot, igazodva

a felhasználók sávszélesség igényéhez és pénztárcájához.

• Ezen kívül hozzáadhatunk roaming logikát is, így külföldön más szabályok

vonatkozhatnak ránk. Például külföldön nem szükséges a forgalomszűrés,

abban az esetben sem, ha nem rendelkezik az előfizető P2P engedélyezéssel.

• Végül a jelenlegi logikát apró változtatásokkal átültethetjük VoIP szűrésre

is, hiszen a fő különbség csupán a szűrt csomagok típusában van, ezt viszont

az átjáró DPI funkciója végzi.

69

Köszönetnyilvánítás

Ez úton szeretnék köszönetet mondani Murányi Jánosnak, aki a kritikus

helyzetekben mindig hasznos tanácsokkal látott el munkám során, Törőcsik Péternek,

akihez bátran fordulhattam a legapróbb kérdésemmel is, Németh Istvánnak a Gateway

konfigurációhoz, és végül, de nem utolsó sorban az NGMNIO osztálynak, hogy

használhattam teszthálózatukat.

70

Irodalomjegyzék

[1] Erik Dahlman, Stefan Parkvall, Johan Skold: 4G: LTE/LTE-Advanced for Mobile Broadband, ISBN: 978-0123854896, May 2011

[2] Erik Dahlman, Stefan Parkvall, Johan Skold and Per Beming: 3G Evolution: HSPA and LTE for Mobile Broadband, Second Edition, ISBN: 978-0123745385, 2008

[3] 3GPP LTE: http://www.3gpp.org/LTE (2012 december)

[4] Long Term Evolution (LTE) - http://www.eventhelix.com/lte/lte-tutorials.htm (2012 december)

[5] Top 10 Considerations for a Successful Evolved Packet Core (EPC) Deployment http://www.cisco.com/en/US/prod/collateral/wireless/ps11035/ps11047/ps11072/white_paper_c11-609202_ns1076_Networking_Solutions_White_Paper.html (2012 december)

[6] RFC3588 Diameter Base Protocol - http://www.faqs.org/rfcs/rfc3588.html (2012 december)

[7] RFC 2989 - Criteria for Evaluating AAA Protocols for Network Acc - http://www.faqs.org/rfcs/rfc2989.html (2012 december)

[8] David Wisely: IP for 4G, ISBN: 978-0-470-51016-2, January 2009

[9] Technical Specification Group Services and System Aspects; Policy and charging control architecture - http://www.3gpp.org/ftp/Specs/html-info/23203.htm (2012 december)

[10] General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access http://www.3gpp.org/ftp/Specs/html-info/23401.htm (2012 december)

[11] DTAG Magyar Telekom: HLD v1.08, March 2012

[12] Amdocs - Policy Controller: http://www.amdocs.com/Products/network-control/multi-access-control-plane/Pages/amdocs-policy-controller.aspx (2012 december)

[13] DTAG Magyar Telekom: LLD v1.0, June 2012

[14] Bridgewater Systems: Policy Controller Redundancy and Scalability Architecture

[15] DT PCRF: System Design

71

[16] Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2012–2017 - http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-520862.html, 2013 május

[17] Cisco Visual Networking Index: Forecast and Methodology, 2011-2016 - http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-481360_ns827_Networking_Solutions_White_Paper.html

[18] Stefan Saroiu, Krishna P. Gummadi, Steven D. Gribble: Measuring and analyzing the characteristics of Napster and Gnutella hosts, Multimedia Systems, Vol 9, 2003, pp. 170-184

[19] Ipoque Internet Studies. http://www.ipoque.com/resources/internet-studies 2013 május

[20] Klaus Mochalski Hendrik Schulze, Internet Study 2008/2009, 2009

[21] Sandivine, Global Internet Phenomena Report, 2012

[22] Jessie Hui Wang, Chungang Wang, Jiahai Yang, Changqing An: A study on key strategies in P2P file sharing systems and ISPs’ P2P traffic management, Peer-to-Peer Networking and Applications, Vol 4, 2011, pp. 410-419

[23] Anttoni Halme: Peer-to-peer Traffic: Impact on ISPs and Evaluation of Traffic Management Tools, Helsinki University of Technolog, 2005

72

Rövidítésjegyzék

2G Second generation 3G Third Generation 3GPP 3rd Generation Partnership Project 4G fourth generation AAA Authentication, Authorization, Accounting APN Access Point Name ÁSZF Általános Szerződési Feltételek BMS Bridgewater Management System BSS Business Support System CCR/CCA Credit Control Request/Answer CN Core Network DPI Deep Packet Inspection DRA Diameter Routing Agent DT-SOAP Deutsche Telekom - Simple Object Access Protocol EDGE Enhanced Data Rates for GPRS Evolution EUTRAN Evolved UTRAN FTP File Transfer Protocol GGSN Gateway GPRS Support Node GPRS General Packet Radio Service GUI Graphical User Interface HLR Home Location Register HSDPA High-Speed Downlink Packet Access HSPA High-Speed Packet Acces HSS Home Subscriber Subsystem HSUPA High-Speed Uplink Packet Access IMSI International Mobile Subscriber Identity IP Internet Protocol IPMS IP Mobility Mode Selection KPI Key Performance Indicator LTE Long Term Evolution MME Mobility Manegement Entity MSISDN Mobile Station International Subscriber Directory Number OFDMA Orthogonal Frequency-Division Multiple Access OSS operation support system P2P Peer-to-peer PC Policy Controller PCEF Policy and Charging Enforcement Function PCRF Policy and Charging Rule Function PDC Policy Decision Cache

73

PDN-Gw/P-Gw Packet Data Network Gateway PEP Policy Enforcement Point QM Quota Manager QoS Quality of Service RAR/RAA Re – Auth Request/Answer REL Release RNC Radio Network Controller SAE System Architecture Evolution SC Service Component SDB Subscriber Data Broker SGSN Serving GPRS Support Node S-Gw Serving Gateway SM Service Management SMS Short Message Service SNMP Simple Network Management Protocol SPR Subscriber Profile Repository UMTS Universal Mobile Telecommunications System

UPS User Profile Set UTRAN Universal Terrestrial Radio Access Network VIP Virtual IP VoIP Voice over IP WCDMA Wideband Code Division Multiple Access XML eXtensible Markup Language

74

Ábrajegyzék

1. ÁBRA A MOBIL ADATFORGALOM ALAKULÁSA 2012-2017 KÖZÖTT []....................................................................... 9

2. ÁBRA FORGALOM ELOSZLÁS 2012-2017 ......................................................................................................... 10

3. ÁBRA AZ UMTS ÉS AZ LTE ARCHITEKTÚRA VÁLTOZÁSA [4] .................................................................................. 11

4. ÁBRA 3G ÉS AZ LTE FUNKCIONÁLIS ÖSSZEHASONLÍTÁSA ...................................................................................... 12

5. ÁBRA PCRF ARCHITEKTÚRA [13] .................................................................................................................... 15

6. ÁBRA A PCRF KOMPONENSEI [15] ................................................................................................................. 16

7. ÁBRA AZ SDB KOMPONENSEI [15] ................................................................................................................. 19

8. ÁBRA PDP AKTIVÁLÁS (XXL PROFIL) [11] ........................................................................................................ 21

9. ÁBRA PDP AKTIVÁLÁS (M PROFIL) [11] ........................................................................................................... 22

10. ÁBRA SÁVSZÉLESSÉG SZŰKÍTÉS (XXL/M PROFIL) [11] ....................................................................................... 23

11. ÁBRA REDUNDANCIA A SITE-OK KÖZÖTT [13] ................................................................................................. 25

12. ÁBRA PCRF HELYI REDUNDANCIA [14] .......................................................................................................... 26

13. ÁBRA PCRF HELYI REDUNDANCIA [14] .......................................................................................................... 27

14. ÁBRA PROFIL ADATBÁZIS N-IRÁNYÚ REDUNDANCIÁJA [15] ................................................................................. 27

15. ÁBRA PCRF – SDB REDUNDANCIA MODELL [14]............................................................................................. 28

16. ÁBRA DRA REDUNDANCIA MODELL [13] ........................................................................................................ 29

17. ÁBRA BMS REDUNDANCIA MODELL [14] ....................................................................................................... 29

18. ÁBRA SITE-ON BELÜLI PCRF MEGHIBÁSODÁS [14] ........................................................................................... 30

19. ÁBRA SITE-ON BELÜLI BMS MEGHIBÁSODÁS [14] ............................................................................................ 31

20. ÁBRA DRA MEGHIBÁSODÁS ÜZENET ÁRAMLÁSA [13] ....................................................................................... 32

21. ÁBRA TELJES SITE-ON BELÜLI PCRF KIESÉS [15] .............................................................................................. 33

22. ÁBRA TELJES SITE-ON BELÜLI DRA KIESÉS [14] ............................................................................................... 34

23. ÁBRA TELJES SITE KIESÉS [14] ...................................................................................................................... 35

24. ÁBRA A MAGYAR TELEKOM HÁLÓZATA[11] ................................................................................................... 40

25. ÁBRA VÁLLALATI KIALAKÍTÁS ........................................................................................................................ 43

26. ÁBRA XXL FELHASZNÁLÓ LÉTREHOZÁSA ......................................................................................................... 45

27. ÁBRA XLL FELHASZNÁLÓ LÉTREHOZÁSA TORRENT ENGEDÉLYEZÉSSEL .................................................................... 47

28. ÁBRA HÍVÁS KÖZBEN TÖRTÉNŐ TORRENT AKTIVÁLÁS ......................................................................................... 49

29. ÁBRA HÍVÁS KÖZBEN TÖRTÉNŐ TORRENT DEAKTIVÁLÁS ..................................................................................... 51

30. ÁBRA KAPCSOLAT KÖZBEN TÖRTÉNŐ SÁVSZÉLESSÉG CSÖKKENTÉS TORRENT ENGEDÉLYEZÉSSEL ................................... 52

31. ÁBRA XXL FELHASZNÁLÓ LÉTREHOZÁSA (SERVICE MANAGER) ............................................................................ 59

32. ÁBRA CHARGING RULE INSTALL (RULE_XXL, RULE_TORRENT_BLOCK)................................................................... 60

33. ÁBRA BONTÁS A PCRF02 ÉS A DRA02 KÖZÖTT .............................................................................................. 61

34. ÁBRA XXL FELHASZNÁLÓ TORRENT ENGEDÉLYEZÉSSEL ....................................................................................... 62

35. ÁBRA CHARGING RULE INSTALL (RULE_XXL, RULE_TORRENT_ENABLED) ............................................................... 63

75

36. ÁBRA CHARGING RULE REMOVE&INSTALL (REMOVE: RULE_TORRENT_BLOCK, INSTALL: RULE_TORRENT_ENABLED) ..... 64

37. ÁBRA CHARGING RULE REMOVE&INSTALL (REMOVE: RULE_TORRENT_ENABLED, INSTALL: RULE_TORRENT_BLOCK) ..... 65

38. ÁBRA DT-SOAP LEKÉRDEZÉS ....................................................................................................................... 66

39. ÁBRA POLICY NOTIFY KÉRÉS ......................................................................................................................... 66

40. ÁBRA PEP_XXL_SSD_TORRENT .............................................................................................................. 67

76

Táblázatjegyzék

1. TÁBLÁZAT 2007-2008 IPOGUE ÉS 2011-2013 CISCO ADATOK ALAPJÁN KÉSZÜLT FORGALOMSTATISZTIKA ................... 37

2. TÁBLÁZAT CISCO MOBIL ADATFORGALOM ELOSZLÁS ELŐREJELZÉSE 2012-2017 [16] ............................................... 38

3. TÁBLÁZAT SERVICE MANAGER KONFIGURÁCIÓ .................................................................................................. 43

4. TÁBLÁZAT ELÉRHETŐ SZOLÁLTATÁS KOMPONENSEK ............................................................................................ 44

5. TÁBLÁZAT SERVICE MAPPING KAPCSOLATOK ..................................................................................................... 44

6. TÁBLÁZAT KÖTELEZŐ UTASÍTÁS TAG-EK ............................................................................................................ 53

7. TÁBLÁZAT CREATE USER PROVISIONING PARANCS, KÖTELEZŐ ÉS OPCIONÁLIS TAG-EK ................................................ 54

8. TÁBLÁZAT FELHASZNÁLÓ LÉTREHOZÁSA ............................................................................................................ 55

9. TÁBLÁZAT FELHASZNÁLÓ LÉTREHOZÁSA P2P ENGELYÉLLYEL ................................................................................. 56

10. TÁBLÁZAT HÍVÁS KÖZBEN TÖRTÉNŐ TORRENT AKTIVÁLÁS ................................................................................... 57

Documents

NAGYSEBESSÉGŰ CELLÁS MOBILHÁLÓZATOK …zfaigl/QoS/doc/freePCRF/Nagysebessegu-cellas... · sikerességér ől a bemutatott Wireshark felvételek, logok, adatbázis lekérdezések