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.
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.
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).
2. Az IPMS lekéri a kvóta információkat a számlázási rendszerből.
3. A Számlázási rendszer visszaadja a profil információkat.
4. Az IPMS nyugtázza a frissítés kérést.
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
SDB 1 SDB 2 SDB 3 SDB 4
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
SDB 1 SDB 2 SDB 3 SDB 4
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
SDB 1 SDB 2 SDB 3 SDB 4
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
SDB 1 SDB 2 SDB 3 SDB 4
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
SDB 1 SDB 2 SDB 3 SDB 4
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ó
adatbázis bejegyzést.
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.
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.
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.
15. A DRA visszajuttatja az üzenetet a P-Gw-nek és törli a kapcsolathoz tartozó
adatbázis bejegyzést.
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.
8. A Gateway küld egy CCR-I kvótakérést az IPMS-nek a Gy interfészen
keresztül.
9. Az IPMS visszaadja a kvótainformációkat.
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.
4. 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_block szabályt, és
eltávolítja a rule_torrent_enabled-öt.
5. A PCRF elküldi a RAR üzenetet.
6. A DRA továbbítja azt.
52
7. A Gw elvégzi a szükséges módosításokat, majd elküldi nyugtát (RAA).
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
3. 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_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.
4. A PCRF elküldi a RAR üzenetet.
5. A DRA továbbítja azt.
6. A Gw elvégzi a szükséges módosításokat, majd elküldi nyugtát (RAA).
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
<request version="2.0" principal="admin" credentials="MYSECRET">
<target name="UserAPI" operation="createUser">
<parameter>
56
<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>
<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
<request version="2.0" principal="admin" credentials="MYSECRET">
<target name="UserAPI" operation="updateUser">
<parameter>
<user>
<name>36307771894</name>
57
<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>
<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>
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>
</service-component>
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">
<target name="UserAPI" operation="createUser">
<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.
May 2 22:39:38 localhost.localdomain PCRF02_PCRF02: INFO BPCOP(318)
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
SESSION_ID: 0002-diamproxy.pgw0gx-
test.telekom.hu;55705768;70668;5182d7ec-c02
PEP_ID: 50000010
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_TORRENT
USER_IPV4_ADDRESS: 0A05363D
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 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.
May 2 23:35:37 localhost.localdomain PCRF02_PCRF02: INFO BPCOP(303)
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
SESSION_ID: 0001-diamproxy.pgw0gx-
test.telekom.hu;90686630;87571;5182dc28-1302
PEP_ID: 50000100
ORIGIN_HOST: 0001-diamproxy.pgw0gx-test.telekom.hu
ORIGIN_REALM: telekom.hu
PEP_STATUS_ID: 1005
SOURCE_ID: 1
LAST_USED_PEP_PROFILE_NAME: PEP_XXL_TORRENT
USER_IPV4_ADDRESS: 0A05363E
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 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