Embed Size (px)
DESCRIPTION
IMS
Citation preview
UNIVERZITET U SARAJEVU
ELEKTROTEHNIČKI FAKULTET
ZAVRŠNI RAD DRUGOG CIKLUSA STUDIJA
Mjerenje uticaja signalizacijskog optere ćenja
na kvalitetu korisni čkog iskustva
Mentor: Student:
Doc. dr. sc. Jasmina Baraković Husić Alisa Hebibović, 445/15358
Sarajevo, septembar 2013.
II
Postavka završnog rada
Sažetak:
Pružatelji usluga tradicionalno se fokusiraju na mjerenje i upravljanje kvalitetom usluge
QoS (engl. Quality of Service), a ne kvalitetom iskustva QoE (engl. Quality of
Experience). U današnjem natjecateljskom svijetu multimedijskih usluga, imperativ za
pružatelje usluga je diferencijacija u smislu upravljanja kvalitetom korisničkog iskustva.
Pojam kvalitete iskustva definira se kao sveukupna prihvatljivost aplikacije ili usluge,
subjektivno percipirana od strane krajnjeg korisnika. Različiti su faktori koji utiču na
kvalitetu iskustva koja se pruža korisniku za vrijeme korištenja aplikacije ili usluge. To su
npr. jednostavnost korištenja, vremensko trajanje odziva, dostupnost, korisnikovo
očekivanje i prijašnja iskustva, itd. Iako kvaliteta korisničkog iskustva tradicionalno
podrazumijeva mjerenje medijski-orijentiranih komponenti usluge, porast
signalizacijskog opterećenja uzrokuje potrebu za mjerenjem signalizacijski-orijentiranih
komponenti usluge.
Zadaci završnog rada mogu se sažeti u sljedećem:
Teorijski dio
• Razmotriti različite faktore koji utiču na kvalitetu korisničkog iskustva uz opis
subjektivnih i objektivnih metoda mjerenja metrika kvalitete iskustva za odabrane
tipove usluga;
• Sistematizirati pristupe povezanih istraživanja uticaja različitih faktora na
kvalitetu korisničkog iskustva s posebnim osvrtom na signalizacijsko opterećenje
(analizirati metodološke postupke, ostvarene rezultate i otvorena pitanja);
• Ispitati i utvrditi uticaj signalizacijskog opterećenja na odabrane metrike kvalitete
korisničkog iskustva za razmatrane tipove usluga;
III
Prakti čni dio
• Razviti novu ili unaprijediti postojeću IMS (engl. Internet protocol Multimedia
Subsystem) baziranu klijentsku aplikaciju s mogućnošću izvještavanja o
subjektivnim i objektivnim metrikama kvalitete korisničkog iskustva.
Mentor:
___________________________________
IV
V
Sažetak
Jedan od osnovnih zahtjeva mreža nove generacije NGN (engl. Next Generation
Network) je da omoguće isporuku usluga sa visokom kvalitetom iskustva QoE (engl.
Quality of Experience) za krajnje korisnike. Pružatelji usluga se tradicionalno fokusiraju
na mjerenje i upravljanje kvalitetom usluge QoS (engl. Quality of Service), a ne
kvalitetom iskustva QoE. Na današnjem natjecateljskom tržištu, gdje je konkurencija na
iznimno visokom nivou, imperativ za pružatelje usluge je diferencijacija u smislu
upravljanja kvalitetom korisničkog iskustva. Iako kvaliteta korisničkog iskustva
tradicionalno podrazumjeva mjerenje medijski-orijentiranih komponenti usluge, razvoj
usluga nove generacije za posljedicu ima povećanje signalizacijskog opterećenja što
dovodi do potrebe mjerenja signalizacijski-orijentiranih komponenti usluge i njihovog
uticaja na kvalitetu korisničkog iskustva.
U radu je dat pregled faktora koji utiču na QoE uz opis procedura za mjerenja QoE-a.
Opisane su procedure mjerenja metrika performansi SIP (engl. Session Initiation
Protocol) signalizacije za VoIP (engl. Voice over Internet Protocol) uslugu na način na
koji su opisane u IETF (engl. Internet Engineering Task Force) RFC 6076 dokumentu.
Testiranje je vršeno na Open Source IMS Core platformi uz korištenje UCT (engl.
University of Cape Town) klijenta (sa implementiranim potrebnim funkcionalnostima) i
SIPp generatora saobraćaja koji omogućava da se mjerenje navedenih metrika vrši u što
realnijim uslovima.
Klju čne riječi – IMS; NGN; QoE; QoS; RRD; SDD; SRD;
VI
Summary
One of the main tasks that NGN (Next Generation Network) has is enabling high QoE
(Quality of Experience) for end users. Service providers are traditionally focused on
measuring and managing QoS (Quality of Service), instead of focusing on QoE. An
imperative in market competition for service providers today is QoE aware
differentiation. Although, quality of user experience is traditionally measured through
media-oriented service components, next generation service development has the effect
of signaling traffic increase. This leads to the necessity of measuring signaling
components and their influence on quality of user experience.
This master thesis describes factors affecting QoE and procedures for QoE measurement.
A method of SIP (Session Initiation Protocol) performance metrics measurement for
VoIP (Voice over Internet Protocol) is also described with respect to IETF (Internet
Engineering Task Force) RFC 6076 document. Testing is performed on Open Source
IMS Core platform using UCT (University of Cape Town) with implemented all needed
functionalities and SIPp traffic generator which enables performance metrics
measurement in as realistic conditions as possible.
Key words - IMS; NGN; QoE; QoS; RRD; SDD; SRD;
VII
Sadržaj
Postavka završnog rada ......................................................................................................... II
Sažetak .................................................................................................................................. V
Summary .............................................................................................................................. VI
Popis slika ............................................................................................................................. X
Popis tabela ....................................................................................................................... XIII
Uvod ...................................................................................................................................... 1
1. Mreža nove generacije NGN ......................................................................................... 4
1.1. Arhitektura NGN mreže ........................................................................................ 5
1.2. IP Multimedia Subsystem ...................................................................................... 6
1.2.1. IMS arhitektura .............................................................................................. 7
1.2.2. Funkcionalni elementi IMS arhitekture ......................................................... 8
1.3. Sažetak ................................................................................................................. 10
2. Osiguravanje kvaliteta iskustva u NGN mrežama ....................................................... 11
2.1. Standardizacijska tijela i QoE .............................................................................. 14
2.1.1. ITU-T ........................................................................................................... 14
2.1.2. Broadband Forum ........................................................................................ 15
2.1.3. TeleManagement Forum .............................................................................. 15
2.1.4. ETSI ............................................................................................................. 15
2.2. Mjerenje kvalitete korisničkog iskustva .............................................................. 16
2.2.1. Usporedba metoda QoE mjerenja ................................................................ 17
2.3. Sažetak ................................................................................................................. 20
3. Voice over Internet Protocol ........................................................................................ 21
3.1. Session Initiation Protocol ................................................................................... 22
3.1.1. Signalizacijska procedura procesa registracije korisnika ............................ 22
VIII
3.1.2. Signalizacijske procedure uspostave i prekida sesije .................................. 23
3.2. Real-time Transport Protocol .............................................................................. 25
3.3. Metrike karakteristične za kvalitet VoIP usluga.................................................. 26
3.3.1. Kašnjenje zahtjeva za registraciju ............................................................... 26
3.3.2. Kašnjenje zahtjeva za uspostavu sesije ....................................................... 27
3.3.3. Kašnjenje prekida sesije .............................................................................. 30
3.3.4. Vrijeme trajanja sesije ................................................................................. 30
3.3.5. Kašnjenje i varijacija kašnjenja ................................................................... 32
3.3.6. Gubitak paketa ............................................................................................. 33
3.4. Mjerenje metrika koje utiču na QoE usluge VoIP ............................................... 33
3.4.1. Subjektivne metode mjerenja kvaliteta ........................................................ 33
3.4.2. Objektivne metode mjerenja kvaliteta ......................................................... 34
3.5. Sažetak ................................................................................................................. 36
4. Povezana istraživanja .................................................................................................. 37
4.1. Povezana istraživanja o faktorima koji utiču na QoE .......................................... 37
4.2. Povezana istraživanja o uticaju signalizacijskih procedura i signalizacijskog
opterećenja na QoE .......................................................................................................... 39
4.3. Sažetak ................................................................................................................. 46
5. Model rješenja za unapređenje UCT IMS klijentske aplikacije .................................. 47
5.1. Opis postojećih funkcionalnosti UCT IMS klijentske aplikacije ........................ 47
5.2. Opis vlastitog rješenja ......................................................................................... 49
5.2.1. Neformalni opis ........................................................................................... 49
5.2.2. Formalni opis ............................................................................................... 50
5.3. Implementacija željenih proširenja na UCT IMS klijentskoj aplikaciji .............. 51
5.3.1. MySQL baze podataka ................................................................................ 51
IX
5.3.2. Programski kod ............................................................................................ 53
5.4. Sažetak ................................................................................................................. 68
6. Opis testnog okruženja ................................................................................................ 69
6.1. Open Source IMS Core platforma ....................................................................... 70
6.1.1. Open IMS funkcija za upravljanje sesijom poziva ...................................... 71
6.1.2. FOKUS Home Subscriber Server ................................................................ 73
6.2. SIPp generator saobraćaja ................................................................................... 74
6.3. Opis topologije testne mreže ............................................................................... 75
6.4. Sažetak ................................................................................................................. 76
7. Rezultati i diskusija mjerenja uticaja signalizacijskog opterećenja na QoE ............... 77
7.1. Rezultati mjerenja kašnjenja zahtjeva za registraciju .......................................... 81
7.2. Rezultati mjerenja kašnjenja zahtjeva za uspostavu sesije .................................. 83
7.3. Rezultati mjerenja kašnjenja prekida sesije ......................................................... 88
7.4. Uticaj izmjerenih vrijednosti RRD-a, SRD-a i SDD-a na kvalitetu korisničkog
iskustva ............................................................................................................................ 90
7.5. Sažetak ................................................................................................................. 93
Zaključak ............................................................................................................................. 95
Literatura ............................................................................................................................. 96
Popis skraćenica .................................................................................................................. 99
Prilog A: Instalacija Open Source IMS Core platforme .................................................... 104
Prilog B: Instalacija UCT IMS klijenta ............................................................................. 107
Prilog C: Instalacija SIPp generatora saobraćaja ............................................................... 108
Prilog D: XML skripte ....................................................................................................... 110
Prilog E: Programski kodovi ............................................................................................. 118
X
Popis slika
Sl. 1.1 Arhitektura NGN mreže [3] ...................................................................................... 5
Sl. 1.2 IMS arhitektura [5] .................................................................................................... 8
Sl. 2.1 Uticaj tehničkih i ne-tehničkih aspekata usluge na QoE [15] ................................. 12
Sl. 2.2 Generički pristup za modeliranje mjerenja QoE-a [13] .......................................... 19
Sl. 3.1 Prikaz uspostave VoIP poziva korištenjem SIP i RTP protokola ........................... 21
Sl. 3.2 Signalizacijska procedura procesa registracije korisnika ........................................ 23
Sl. 3.3 Signalizacijska procedura uspostave sesije ............................................................. 24
Sl. 3.4 Signalizacijska procedura procesa prekida sesije.................................................... 25
Sl. 3.5 Metrike performansi VoIP signalizacije koje utiču na kvalitet korisničkog iskustva
............................................................................................................................................. 26
Sl. 3.6 Prikaz kašnjenja zahtjeva za registraciju ................................................................. 27
Sl. 3.7 Prikaz kašnjenja zahtjeva za uspješnu uspostavu sesije bez preusmjeravanja ........ 28
Sl. 3.8 Prikaz kašnjenja zahtjeva za uspješnu uspostavu sesije sa preusmjeravanjem ....... 28
Sl. 3.9 Prikaz kašnjenja zahtjeva pri neuspješnom procesiranju zahtjeva za uspostavu
sesije bez preusmjeravanja .................................................................................................. 29
Sl. 3.10 Prikaz kašnjenja zahtjeva pri neuspješnom procesiranju zahtjeva za uspostavu
sesije sa preusmjeravanja..................................................................................................... 29
Sl. 3.11 Prikaz kašnjenja uspješnog prekida sesije mjerenog na: a) izvorišnom čvoru UA1;
b) odredišnom čvoru UA2 ................................................................................................... 30
Sl. 3.12 Prikaz vremena trajanja uspješne sesije na: a) izvorišnom čvoru UA1; b)
odredišnom čvoru UA2 ....................................................................................................... 31
Sl. 3.13 Prikaz vremena trajanja neuspješne sesije na: a) izvorišnom čvoru UA1; b)
odredišnom čvoru UA2 ....................................................................................................... 32
XI
Sl. 4.1 Rezultati mjerenja i funkcija mapiranja fiLBC(pL) između omjera izgubljenih paketa
i QoE-a za iLBC kodek (iLBC kodek koristi se za VoIP uslugu Skype) [30] ................... 38
Sl. 4.2 Rezultati mjerenja i funkcija mapiranja fG.711(pL) između omjera izgubljenih paketa
i QoE-a za G.711 kodek [30] .............................................................................................. 38
Sl. 4.3 Vrijednosti PDD metrike mjerene pri različitom broju simultanih poziva [35] ..... 40
Sl. 4.4 Razmjena poruka prilikom testiranja SIP proxy servera [37] ................................. 42
Sl. 4.5 RRD i SRD kašnjenja za SIP Proxy sa četiri UDP slušatelja [38] .......................... 43
Sl. 4.6 RRD i SRD kašnjenja za SIP Proxy sa šesnaest UDP slušatelja [38] ..................... 43
Sl. 4.7 MSC dijagram za testiranje XML scenarija [39] .................................................... 44
Sl. 4.8 Vrijednosti RRD-a mjerene pri različitom broju konkurentnih poziva [39] ........... 45
Sl. 4.9 Vrijednosti SRD-a mjerene pri različitom broju konkurentnih poziva [39] ........... 45
Sl. 5.1 Use case dijagram ................................................................................................... 50
Sl. 5.2 Logiranje kao mysql root korisnik i odgovarajući ispis .......................................... 51
Sl. 5.3 Prikaz kreiranih baza podataka ............................................................................... 52
Sl. 5.4 Prikaz sadržaja tabele user u qoe_database bazi podataka ........................... 53
Sl. 5.5 Prikaz GUI-a UCT klijentske aplikacije sa dodanim QoE modulom ..................... 64
Sl. 5.6 Uspostavljen poziv između korisnika Tomy i Mary ............................................... 64
Sl. 5.7 GUI za ocjenjivanje kvaliteta usluge subjektivno percipirane od strane krajnjeg
korisnika .............................................................................................................................. 65
Sl. 5.8 Prikaz GUI-a UCT klijentske aplikacije sa neophodnim podacima u modulu QoE
koji su preuzeti iz qoe_database baze podataka ........................................................... 66
Sl. 5.9 Prikaz tekstualne datoteke u koju se pohranjuju izmjerene vrijednosti za SRD
preuzete iz baze qoe_database pritiskom na button Write Data za korisnika Tomy ........... 67
Sl. 5.10 Prikaz Preferences prozora za unošenje opštih podataka o korisniku .................. 68
Sl. 6.1 Arhitektura Open IMS Core platforme [43] ............................................................ 70
Sl. 6.2 Arhitektura P-CSCF-a [43] .................................................................................... 71
XII
Sl. 6.3 Arhitektura I-CSCF-a [43] ...................................................................................... 72
Sl. 6.4 Arhitektura S-CSCF-a [43] ..................................................................................... 73
Sl. 6.5 Arhitektura FHoSS-a [43] ....................................................................................... 74
Sl. 6.6 Konfiguracija testne mreže...................................................................................... 75
Sl. 7.1 Prikaz generisanog mrežnog opterećenja korištenjem SIPp generatora ................. 78
Sl. 7.2 Prikaz SIP korisnika u FHoSS bazi podataka ......................................................... 79
Sl. 7.3 Izgled GUI-a UCT klijenta sa prikazanom razmjenom poruka prilikom iniciranja
poziva .................................................................................................................................. 79
Sl. 7.4 Izgled GUI-a UCT klijenta sa prikazanom razmjenom poruka prilikom uspostave
poziva .................................................................................................................................. 80
Sl. 7.5 Izgled GUI UCT klijenta sa prikazanom razmjenom poruka prilikom prekida
poziva .................................................................................................................................. 81
Sl. 7.6 Grafički prikaz RRD-a ............................................................................................ 83
Sl. 7.7 Grafički prikaz SRD-a za uspješnu uspostavu sesije .............................................. 85
Sl. 7.8 Prikaz odgovora prilikom generisanja opterećenja od 100 do 130 poziva u sekundi
............................................................................................................................................. 86
Sl. 7.9 Prikaz odgovora prilikom generisanja opterećenja od 140 poziva u sekundi ......... 87
Sl. 7.10 Grafički prikaz SRD-a prilikom neuspješne uspostave sesije ............................... 88
Sl. 7.11 Grafički prikaz vrijednosti SDD-a mjerenih na strani izvornog korisničkog agenta
(Tomy) ................................................................................................................................. 90
Sl. 7.12 Grafički prikaz zavisnosti MOS-a od izmjerenih vrijednosti RRD-a ................... 91
Sl. 7.13 Grafički prikaz MOS-a u zavisnosti od dobivenih rezultata mjerenja za SRD ..... 92
Sl. 7.14 Grafički prikaz MOS-a u zavisnosti od dobivenih rezultata za SDD ................... 92
XIII
Popis tabela
Tabela 7.1 Rezultati RRD-a za različite vrijednosti opterećenja IMS mreže ...................... 82
Tabela 7.2 Vrijednosti SRD-a za uspješne uspostave sesije pri različitom opterećenju IMS
mreže ................................................................................................................................... 84
Tabela 7.3 Vrijednosti SRD-a prilikom neuspješne uspostave sesije za različite vrijednosti
opterećenja IMS mreže ........................................................................................................ 87
Tabela 7.4 Vrijednosti SDD-a mjerene na strani korisničkog agenta (Tomy) pri različitom
opterećenju IMS mreže ........................................................................................................ 89
1
Uvod
U potrazi za novim izvorima prihoda i poboljšanjem konkurentnosti na tržištu, pružatelji
mrežnih usluga nude veliki broj usluga sa dodatnom vrijednošću. Jedan od osnovnih
zahtjeva mreža nove generacije NGN (engl. Next Generation Networks) je da omoguće
isporuku ovih usluga sa visokom kvalitetom iskustva QoE (engl. Quality of Experience) za
krajnje korisnike. Pružatelji usluga tradicionalno se fokusiraju na mjerenje i upravljanje
kvalitetom usluge QoS (engl. Quality of Service), a ne kvalitetom iskustva. U današnjem
natjecateljskom svijetu multimedijskih usluga, imperativ za pružatelje usluga je
diferencijacija u smislu upravljanja kvalitetom korisničkog iskustva. Međunarodna
telekomunikacijska zajednica ITU (engl. International Telecommunication Union) definiše
QoE kao ukupnu prihvatljivost aplikacije ili usluge koju subjektivno percipira krajnji
korisnik. Kvalitet iskustva QoE zapravo predstavlja mjeru koja izražava koliko dobro
usluga zadovoljava očekivanja krajnjeg korisnika, uzimajući pri tome u obzir uticaj
parametara cijelog sistema. Kvalitet iskustva QoE je veoma važan za mrežne operatore,
proizvođače opreme i pružatelje NGN usluga. Njihova sposobnost da mjere QoE i da
koriste podatke o tim mjerenjima je od krucijalne važnosti zbog toga što omogućava da se
sumiraju efekti uticaja mrežnih performansi i parametara okruženja na ukupnu vrijednost
korisničkog zadovoljstva nekom uslugom. Iako kvaliteta korisničkog iskustva
tradicionalno podrazumijeva mjerenje medijski-orijentiranih komponenti usluge, porast
signalizacijskog opterećenja uzrokuje potrebu za mjerenjem signalizacijski-orijentiranih
komponenti usluge. Zaključuje se da je cilj ovog rada da se teoretski razmotre različiti
faktori koji utiču na kvalitetu korisničkog iskustva, sa posebnim osvrtom na signalizacijsko
opterećenje, uz opisivanje subjektivnih i objektivnih metoda za mjerenje metrika
karakterističnih za kvalitetu iskustva određene usluge. U praktičnom dijelu ovog rada
potrebno je razviti novu ili unaprijediti postojeću IMS (engl. Internet protocol Multimedia
Subsystem) baziranu klijentsku aplikaciju s mogućnošću izvještavanja o subjektivnim i
objektivnim metrikama kvalitete korisničkog iskustva. Subjektivne metrike kvalitete
korisničkog iskustva su izražene MOS (engl. Mean Opinion Score) metrikom, a objektivne
metrike su izražene metrikama performansi SIP (engl. Session Initiation Protocol)
signalizacije koje će se mjeriti na Open Source IMS Core testnoj platformi u različitim
2
mrežnim uslovima. Različiti mrežni uslovi se odnose na različite vrijednosti opterećenja
IMS mreže koje se generiše korištenjem SIPp generatora saobraćaja.
Rad se sastoji iz sedam poglavlja te je struktuiran na sljedeći način.
Prvo poglavlje opisuje arhitekturu NGN mreže sa posebnim akcentom na podjelu NGN
funkcija na funkcije servisnog i transportnog stratuma. Dalje, u okviru ovog poglavlja je
opisan IMS podsistem koji, zajedno sa svojim funkcionalnim elementima, predstavlja
osnovnu logičku arhitekturu kontrolne ravni NGN mreže. Sa uvođenjem IMS-a riješena su
pitanja vezana za kvalitet usluge, naplatu i integraciju različitih usluga.
Drugo poglavlje detaljno obrađuje tematiku QoE-a u mrežama nove generacije. Izvršena je
klasifikacija faktora koji utiču na QoE na faktore subjektivne i objektivne prirode. Dalje, u
okviru ovog poglavlja obrađena je i tematika koja se bavi mjerenjem QoE-a. Za što
vjerodostojnije mjerenje QoE-a za neku uslugu potrebno je identificirati sve faktore koji
mogu uticati na QoE, a zatim definirati neko rješenje koje će omogućiti kontinuirano
mjerenje tih faktora. Pronalaženje i razumijevanje glavnih faktora koji utiču na korisnički
percipirani kvalitet usluge, njihove veze i odnose sa komponentama zaduženim za pružanje
usluge predstavlja veliki izazov. Ovaj proces obuhvata sljedeće korake: definisanje tačaka
razgraničenja sesije, dekompozicija sesije usluga i dekompozicija arhitekture usluga.
U trećem poglavlju je izvršena dekompozicija komponenti VoIP (engl. Voice over Internet
Protocol) usluge kako bi se mogle analizirati signalizacijske komponente. Dat je kratak
opis SIP signalizacijskih procedura procesa registracije, uspostave i prekida sesije budući
da će se ove procedure koristiti za mjerenje metrika performansi SIP signalizacije koje su
također opisane u sklopu ovog poglavlja. Metrike koje se analiziraju su: kašnjenje zahtjeva
za registraciju, kašnjenje zahtjeva za uspostavu sesije, kašnjenje prekida sesije i vrijeme
trajanja sesije. Iako je cilj ovog rada da se razmotri uticaj signalizacijskog opterećenja
(signalizacijskih procedura) na kvalitet korisničkog iskustva, u ovom dijelu je ipak dat
kratak osvrt i na osnovne metrike mrežnih parametara (u smislu QoS-a) koje također utiču
na QoE.
Četvrto poglavlje daje pregled povezanih istraživanja o faktorima koji utiču na QoE s
posebnim osvrtom na signalizacijske procedure i njihov uticaj na QoE.
U petom poglavlju su opisane postojeće funkcionalnosti UCT (engl. University of Cape
Town) IMS klijentske aplikacije, te opis dodatnih funkcionalnosti sa kojima se ova
aplikacija želi proširiti. Klijentska aplikacija je proširena funkcionalnostima koje
3
omogućavaju izvještavanje o objektivnim i subjektivnim metrikama kvalitete korisničkog
iskustva. Pored ovih funkcionalnosti UCT IMS klijentska aplikacija je proširena i sa
dodatnim modulom koji omogućava unošenje informacija o spolu i dobnoj skupini
korisnika koji je trenutno aktivan na aplikaciji. Realizacijom ovih funkcionalnosti je
omogućeno da se analizira zavisnost između QoE i QoS parametara. U ovom poglavlju je
prikazana programska izvedba zahtijevanih funkcionalnosti kao i prikaz same aplikacije s
implementiranim funkcionalnostima.
U okviru šestog poglavlja je opisano testno okruženje u kojem će se vršiti potrebna
mjerenja. Prilikom mjerenja je korištena Open Source IMS Core testna platforma koja je
razvijena unutar laboratorija njemačkog Fraunhofer Instituta za otvorene komunikacijske
sisteme, FOKUS (engl. Fraunhofer Institute for Open Communication Systems). Za
simuliranje mrežnog opterećenja korišten je SIPp generator kako bi se omogućilo
analiziranje metrika performansi SIP signalizacije u što realnijim uslovima.
Konačno u sedmom poglavlju se opisuju i prikazuju rezultati mjerenja metrika performansi
SIP signalizacije u različitom mrežnom okruženju koji se razmatraju sa aspekta njihovog
uticaja na kvalitetu korisničkog iskustva.
4
1. Mreža nove generacije NGN
Mreža nove generacije NGN je paketski bazirana mreža koja omogućava pružanje
telekomunikacijskih usluga uz korištenje višestrukih širokopojasnih tehnologija sa
implementiranim mehanizmima kvaliteta usluge QoS. U NGN mreži funkcije vezane za
usluge su neovisne o korištenim transportnim tehnologijama. Mreža nove generacije NGN
omogućava korisnicima neograničen pristup mreži i uslugama, pružajući pri tome podršku
za opštu mobilnost koja će omogućiti konzistentno i sveobuhvatno pružanje usluga
korisnicima [1].
Na osnovu prethodno navedene definicije možemo zaključiti da su paketski prenos,
širokopojasni pristup, mobilnost i kvalitet usluge ključni pojmovi koji označavaju
mreže nove generacije. Pored podrške za mobilnost, NGN mreža također omogućava
konvergenciju između fiksnih i mobilnih mreža, zbog toga je i pojam konvergencije
(objedinjavanja) još jedan od ključnih pojmova koji karakterizira mreže nove generacije.
Osnovni cilj NGN mreža je da kombiniraju najbolje od dva najpoznatija komunikacijska
svijeta, telekomunikacijskih mreža i Interneta. Standardizacijsko tijelo ITU-T (engl. ITU
Telecommunication Standardization Sector) je identificiralo sljedeće fundamentalne
karakteristike NGN mreža [2]:
• Osigurava i kupcu i pružatelju usluga podršku za olakšano pružanje usluga preko
fiksnog i mobilnog širokopojasnog pristupa;
• Omogućava korisnicima da pristupe uslugama sa bilo kojeg mjesta i u bilo koje
vrijeme;
• Olakšava objedinjavanje različitih mrežnih usluga kao što su podaci, glas,
popularne multimedijalne i Internet usluge kao što su Instant Messaging i
Presence;
• Podržava fleksibilne platforme za isporuku usluga.
5
1.1. Arhitektura NGN mreže
Mreža nove generacije NGN predstavlja tijelo ključnih arhitekturalnih promjena u
jezgrenoj i pristupnoj telekomunikacijskoj mreži. Na slici 1.1 je prikazana arhitektura
NGN mreže.
Sl. 1.1 Arhitektura NGN mreže [3]
Funkcije NGN mreže su podijeljene na funkcije servisnog i transportnog sloja.
Razdvajanjem ova dva sloja omogućeno je da usluge budu ponuđene odvojeno i da se
razvijaju samostalno, što predstavlja ključnu karakteristiku NGN koncepta. Razdvajanje je
predstavljeno pomoću dva različita bloka ili stratuma funkcionalnosti [4], koja međusobno
komuniciraju u realnom vremenu.
Stratum transporta NGN arhitekture obuhvata pristupne funkcije koje se odnose na
upravljanje pristupom krajnjeg korisnika na mrežu, kao i pristupne transportne funkcije
koje prenose informacije o pristupnoj mreži [5]. Stratum usluge s druge strane obuhvata
korisničke funkcije koje prenose podatke koji se odnose na uslugu i funkcije koje
kontroliraju i upravljaju mrežne resurse i mrežne usluge kako bi se omogućile korisničke
usluge i aplikacije [4]. Standardizacijsko tijelo ITU-T je u okviru preporuke Y.2012
6
definiralo tri vrste interface-a koji se koriste u NGN mreži [6]: UNI (engl. User-to-
Network Interface) interface za funkcije krajnjih korisnika, NNI (engl. Network-to-
Network Interface) interface za druge mreže i ANI (engl. Application-to-Network Inerface)
interface za aplikacijske usluge trećih strana (engl. third-party).
Veliki dio istraživanja koji se odnosi na arhitekturu NGN mreža bazira se na radu 3GPP-a
(engl. 3rd Generation Partnership Project) za mobilne NGN mreže. Projekt partnerstva za
treću generaciju 3GPP definiše IMS kao logičku arhitekturu za kontrolnu ravan NGN
mreže [7]. Ovakva definicija IMS-a je kasnije usvojena od strane ETSI (engl. European
Telecommunication Standards Institute) i IETF (engl. Internet Engineering Task Force)
standardizacijskih tijela.
1.2. IP Multimedia Subsystem
Multimedijalni podsistem zasnovan na IP protokolu IMS je međunarodni standard nastao u
okviru 3GPP-a. Ovaj podsistem je dizajniran za isporuku IP (engl. Internet Protocol)
multimedijalnih usluga mobilnim pretplatnicima. Multimedijalni podsistem IMS se
definiše kao podsistem baziran na horizontalnoj arhitekturi za pružanje multimedijalnih
usluga. Generalno, IMS predstavlja arhitekturu koja omogućava konvergenciju podataka,
govora, fiksnih i mobilnih mreža. Ona je bazirana na širokoj paleti protokola, koje je
standardizirala radna grupa IETF. Multimedijalni podsistem zasnovan na IP protokolu IMS
kombinira i unapređuje ove protokole kako bi omogućio isporuku usluga u realnom
vremenu [8]. Za iniciranje i upravljanje sesijama IMS podsistem koristi SIP signalizacijski
protokol.
Standardizacijsko tijelo 3GPP2 (engl. 3rd Generation Partnership Project 2) se također
bavi IMS standardizacijom. Dvije IMS mreže definirane od strane 3GPP i 3GPP2
standardizacijskih tijela su slične, ali nisu potpuno iste. Najbitnija sličnost između 3GPP i
3GPP2 IMS podsistema je ta što oni koriste Internet protokole koje je standardizirala radna
grupa IETF [9].
Postoje tri glavna razloga zbog kojih se uvodi IMS [10]:
Kvalitet usluge – kojim je u IMS-u eliminisan nedostatak paketske domene koja
funkcioniše po principu "najboljeg pokušaja" (engl. best effort). Tako se mogu unaprijed
dogovoriti parametri kvaliteta usluge, čime se omogućava da korisnik konzumira uslugu s
predvidivim ponašanjem.
7
Naplata – u okviru IMS-a uvodi novine u pogledu adekvatnog naplaćivanja
multimedijalnih usluga. Prije uvođenja IMS-a, prilikom naplaćivanja usluga, 3G (engl. 3rd
Generation) operatori nisu posjedovali informaciju o tome kojoj usluzi pripadaju podaci
koji se prenose, zbog toga se naplata isključivo izvodila na osnovu količine prenesenih
podataka. Multimedijalni podsistem IMS omogućava operatorima da imaju uvid u to koji
tip usluge korisnik aktivira te da u skladu s tim primjenjuju adekvatne metode
naplaćivanja.
Integracija razli čitih usluga – Kod tradicionalnih mreža s vertikalnom arhitekturom
svaka usluga se uvodi posebno za svaku mrežu. Horizontalna i slojevita arhitektura IMS-a
omogućava zajedničke funkcionalnosti koje omogućavaju korištenje više usluga čime se
smanjuje nepotrebno ponavljanje istih funkcionalnosti u mreži. Osnovna prednost ovog
pristupa je smanjenje troškova i omogućavanje jeftinijih usluga za korisnike. Operatori
više nisu isključivo ograničeni na usluge koje je razvio njihov proizvođač opreme, oni
mogu koristiti usluge trećih strana zahvaljujući standardno definiranim interface-ima
unutar IMS-a.
1.2.1. IMS arhitektura
U generalnoj IMS arhitekturi, 3GPP standardizira funkcije, ali ne i čvorove. Općenito
možemo reći da IMS arhitektura predstavlja skup funkcija povezanih standardiziranim
interface-ima. Arhitekturu IMS-a možemo posmatrati kao skup logičkih funkcija koje
mogu biti podijeljene u tri sloja [9]:
• aplikacijski sloj,
• kontrolni sloj,
• transportni sloj.
Kao dodatni četvrti sloj može se posmatrati sloj uređaja koji korisnicima omogućava
pristup IMS zasnovanim uslugama. Slika 1.2 prikazuje slojevitu IMS arhitekturu. U
nastavku će se opisati osnovni funkcionalni elementi IMS arhitekture.
8
Sl. 1.2 IMS arhitektura [5]
1.2.2. Funkcionalni elementi IMS arhitekture
Osnovni elementi IMS jezgrene arhitekture su CSCF (engl. Call Session/Control Function)
čvor i HSS (engl. Home Subscriber Server) baza podataka. Čvor CSCF je odgovoran za
procesiranje i usmjeravanje SIP signalizacije. Postoje tri različite vrste CSCF-a: P-CSCF
(engl. Proxy CSCF), I-CSCF (engl. Interrogating CSCF) i S-CSCF (engl. Serving CSCF)
[8].
Prvu dodirnu tačku između IMS terminala i IMS mreže predstavlja P-CSCF čvor. Ovaj
čvor predstavlja ulazni/izlazni SIP proxy server kroz koji prolaze zahtjevi koje inicira IMS
terminal i zahtjevi koji su upućeni ka IMS terminalu [11]. Uloga P-CSCF-a je da obezbjedi
sigurnost svih poruka koje se razmjenjuju između korisnika i mreže. Čvor P-CSCF
omogućava funkcije za kompresiju i dekompresiju SIP poruka kao i PDF (engl. Policy
Decision Function). Entitet PDF je odgovoran za autorizaciju resursa i upravljanje
kvalitetom usluge na nivou medija [10]. Čvor I-CSCF predstavlja funkcionalni SIP proxy
server lociran na rubu administrativnih IMS domena. Ovaj čvor ima Diameter interface
prema SLF (engl. Subscriber Location Function) i HSS bazi podataka iz kojih preuzima
informacije o korisničkoj lokaciji i prosljeđuje te informacije na odgovarajuću lokaciju,
obično ka S-CSCF-u. Čvor I-CSCF također ima mogućnost da kodira određene dijelove
9
SIP poruke koji sadrže bitne informacije o domeni kao što je broj servera unutar domene,
njihova DNS (engl. Domain Name Server) imena i kapacitete [11].
Središnji funkcionalni čvor IMS signalizacijske ravni je S-CSCF. Ovaj čvor je odgovoran
za upravljanje registracijskim procesima, donošenje odluka o usmjeravanju i održavanju
sesije, i pohranjivanje profila usluga za svakog korisnika. Kao i I-CSCF čvor i S-CSCF
ima Diameter interface prema HSS bazi podataka iz koje preuzima autentifikacijske
podatke [8]. Čvor S-CSCF provjerava svaku SIP poruku i određuje da li će je proslijediti
jednom ili više aplikacijskih servera koji će poslužiti određenu uslugu krajnjem korisniku.
Čvor HSS predstavlja centralnu bazu podataka u kojoj se smještaju informacije o
pretplatnicima u IMS arhitekturi. U HSS bazu podataka se pohranjuju sve informacije koje
su potrebne za upravljanje korisničkim sesijama i pružanje usluga krajnjim korisnicima.
Informacije koje su smještene unutar HSS baze podataka obuhvataju sigurnosne
informacije, informacije o lokaciji korisnika, informacije o uslugama na koje se korisnik
preplaćuje i informacije o S-CSCF-u dodijeljenom korisniku [11]. Ukoliko u mreži postoji
više od jedne HSS baze podataka, onda je potrebna i SLF baza podataka koja čuva
informacije o korisnicima koji su pridruženi različitim HSS bazama podataka.
Čvor MRF (engl. Media Resource Function) objedinjuje funkcije za obradu toka podataka.
Ove funkcije se dijele na MRFC (engl. Media Resource Function Contoller) i MRFP (engl.
Media Resource Function Processor) funkcije. Funkcionalni dio MRF čvora zadužen za
kontrolu MRFC obavlja upravljanje vezama s više učesnika, tj. omogućava konferencije.
Funkcija MRFC upravlja resursima unutar MRFP-a putem H.248 interface-a na osnovu
naredbi dobivenih od aplikacijskih servera i S-CSCF-a. Čvor MRF predstavlja krajnju
tačku signalizacije u IMS mreži. MRFP igra ulogu distributera prema mreži. Može se
koristiti kao izvor podataka u domaćoj mreži ili za provođenje različitih operacija nad
tokom podatka, npr. reproduciranje ili mješanje više medijskih tokova [10].
Čvor BGCF (engl. Breakout Gateway Control Function) je SIP server koji omogućava
funkcionalnost usmjeravanja na osnovu telefonskih brojeva. Ovaj čvor se koristi samo za
sesije koje inicira IMS terminal. Čvor BGCF na zahtjev S-CSCF-a izabire mrežu i čvor za
interface s PSTN/CS (engl. Circuit-Switched) domenom, ako je ona unutar iste mreže kao i
BGCF čvor ili korištenjem SIP protokola prosljeđuje zahtjev BGCF čvoru koji se nalazi u
drugoj mreži.
10
Čvor MGCF (engl. Media Gateway Control Function) čvor predstavlja interface za IMS
signalizaciju prema mrežama sa starom signalizacijom. Ovaj čvor omogućava kontrolu
glavnih funkcionalnih entiteta medijskog gateway-a korištenjem standardnih interface-a.
Ova kontrola omogućava alokaciju i de-alokaciju medijskog gateway-a kao i modifikaciju
ovih resursa prilikom njihovog korištenja. Čvor MGCF komunicira sa CSCF-om, BGCF
čvorom i CS mrežama [12].
Čvor MGW (engl. Media Gateway) osigurava interaface na nivou nosača informacije, što
znači saradnju između različitih mehanizama transporta kao što su TDM (engl. Time
Division Multiplexing) i IP. Čvor MGW je sposoban da šalje i prima IMS medije preko
RTP (engl. Real-time Transport Protocol) protokola. Ovaj čvor također obavlja
transkodiranje ukoliko dva kraja veze podržavaju različit kodek.
Čvor SGW (engl. Signaling Gateway) se koristi ako nakon tačke međusobne saradnje treba
promijeniti transportnu metodu za signalizaciju u mreži [10].
1.3. Sažetak
Prvo poglavlje opisuje pojam NGN mreže. Paketski prenos, širokopojasni pristup,
mobilnost, kvalitet usluge i konvergencija su ključni pojmovi koji karakteriziraju mreže
nove generacije. Standardizacijsko tijelo ITU-T je sistematiziralo pogodnosti koje pruža
NGN mreža kako krajnjim korisnicima tako i pružateljima usluga. U ovom poglavlju je
ukratko opisana arhitektura NGN mreže sa posebnim akcentom na podjelu NGN funkcija
na funkcije servisnog i transportnog stratuma. Dalje, u okviru ovog poglavlja je opisan
IMS podsistem, zajedno sa svojim funkcionalnim elementima, koji predstavlja osnovnu
logičku arhitekturu kontrolne ravni NGN mreže. Sa uvođenjem IMS-a riješena su pitanja
vezana za kvalitet usluge, naplatu i integraciju različitih usluga. Potencijal slojevite
horizontalne arhitekture IMS-a je u razvoju, integraciji i isporučivanju komunikacijskih
usluga nove generacije. Horizontalnom arhitekturom su omogućene zajedničke
funkcionalnosti kojima se može koristiti više usluga, time je smanjeno nepotrebno
ponavljanje istih funkcionalnosti u mreži. To dovodi do smanjenja troškova operatora i
potencijalno jeftinijih usluga za korisnike. Sa svim svojim prednostima IMS će omogućiti
operatorima da ponude nove, inovativne servise, koje očekuju kako njihovi dioničari tako i
krajnji korisnici.
11
2. Osiguravanje kvaliteta iskustva u NGN mrežama
Mreže nove generacije NGN trebaju omogućiti isporuku usluga sa visokom kvalitetom
iskustva QoE za krajnje korisnike. Pružatelji usluga se tradicionalno fokusiraju na mjerenje
i upravljanje kvalitetom usluge QoS, a ne kvalitetom iskustva. U današnjem
natjecateljskom telekomunikacijskom tržištu imperativ za pružatelje usluga je
diferencijacija u smislu upravljanja kvalitetom korisničkog iskustva. Na takvom tržištu
korisnici imaju veliku mogućnost izbora pružatelja usluga, kao što su bežični, žični i
kablovski operatori [13]. Da bi zadržali postojeće korisnike i razvili takvo okruženje koje
će privući nove korisnike za pružatelje usluga nije dovoljno samo omogućiti isporuku
usluga korisnicima. Oni moraju isporučiti usluge na način koji će omogućiti prihvatljiv
QoE za korisnike, dok ponuđene usluge moraju imati prihvatljivu cijenu.
Kvalitet iskustva QoE se definira kao sveukupna prihvatljivost aplikacije ili usluge koju
subjektivno percipira krajnji korisnik. Koncept kvalitete iskustva se razlikuje od koncepta
kvaliteta usluge koji se fokusira na mjerenje performansi iz mrežne perspektive. Može se
reći da je cilj mreže i općenito usluga ostvarivanje maksimalnog kvaliteta iskustva za
korisnike, dok kvalitet usluge zapravo predstavlja gradivni blok koji će omogućiti
ispunjavanje tog cilja. Kvaliteta iskustva QoE se fokusira na efekte koje percipira krajnji
korisnik, kao što su degradacija audio ili video kvalitete, dok se QoS fokusira na mrežne
parametre, kao što su kašnjenje, varijacija kašnjenja (engl. jitter), gubici, propusni opseg
itd. [13].
Najčešće korištene vremenski bazirane metode za mjerenje QoS-a koriste sistem za
mjerenje performansi koji ekstraktuje mjerene podatke sa mrežnih elemenata ili sa sistema
za upravljanje mrežnim elementima EMS (engl. Element Management System) kako bi
ocijenio performanse različitih elemenata u mreži. Međutim, moguće su situacije gdje će se
na pojedinim elementima u mreži (mrežnim čvorovima) dobiti prihvatljive vrijednosti
QoS-a, međutim, korisnici i dalje mogu dobivati neprihvatljive vrijednosti QoE-a, pa ove
metode ne garantuju prihvatljivu estimaciju QoE-a za pojedine aplikacije, sesije ili
korisnike. Kvaliteta iskustva QoE je direktno povezana sa QoS-om, međutim jedan od
izazova za pružatelje usluga je omogućiti set alata za mapiranje QoS parametara na
mrežnom nivou na QoE parametre na nivou korisnika i usluge i da imaju mogućnost za
njegovo kontrolisanje [13].
12
Kvaliteta iskustva QoE zavisi od velikog broja faktora koji mogu biti subjektivne ili
objektivne prirode. Subjektivni faktori uključuju korisničke emocije, iskustva i očekivanja
i ovi faktori se ne mogu kontrolisati. Objektivni faktori se mogu kontrolisati i oni se sastoje
od tehničkih i ne-tehničkih aspekata usluge [14].
Slika 2.1 prikazuje osnovne tehničke i ne-tehničke aspekte usluge koji utiču na QoE. Loše
performanse objektivnih faktora mogu značajno degradirati kvalitet korisničkog iskustva.
Sl. 2.1 Uticaj tehničkih i ne-tehničkih aspekata usluge na QoE [15]
Pored spomenutih mjerenja performansi na pojedinim mrežnim elementima na osnovu
kojih će se procijeniti QoS parametri koji direktno utiču na QoE, QoE zavisi i od
performansi cijelog sistema uključujući [14]:
• Korisnike – Za usluge sa istim kvalitetom korisnici mogu imati različite vrijednosti
QoE-a. Prvo, korisnici mogu različito prioritizirati uspostavljene sesije. Npr.
rezidencijalni i poslovni korisnici mogu imati različite prioritete za online gaming
usluge i usluge prenosa podataka, respektivno. Drugo, zbog različitih subjektivnih
emocija, iskustava i očekivanja korisnici mogu imati različite subjektivne procjene
za usluge sa istim objektivnim QoS parametrima. Dalje, korisnička prioritetizacija,
njihove emocije, iskustva i očekivanja nisu stabilni i mijenjaju se tokom vremena.
• Aplikacije – NGN mreže omogućavaju široku paletu aplikacija kao što su glasovna
telefonija, podatkovne i multimedijalne aplikacije, interaktivne online igre,
messaging itd. Sve navedene aplikacije imaju različit uticaj na kvalitetu
korisničkog iskustva. Prvo, sa aspekta korisnika, različite aplikacije imaju različit
značaj za različite korisnike. Drugo, ove aplikacije mogu imati različite zahtjeve za
QoS-om. Aplikacije možemo svrstati u tri osnovne kategorije: glas, video i podaci
[14]. Audio i video aplikacije su osjetljive na kašnjenje (ukupno, varijabilno
kašnjenje), a tolerantne su na gubitke (mali gubici uzrokuju povremene smetnje).
13
Za razliku od audia i videa, prenos podataka je osjetljiv na gubitke, a manje je
osjetljiv na kašnjenje.
Svaka od navedenih kategorija obuhvata cijeli niz aplikacija koje imaju različite
zahtjeve za QoS parametrima. Treće, svaka aplikacija može koristiti vlastite
parametre kako bi kvantificirala vrijednost QoS parametara na aplikacijskom nivou.
Rezolucija, brzina, boja i šeme kodiranja su tipični parametri video aplikacija.
Različite performanse QoS parametara na aplikacijskom nivou donose različite
efekte koji utiču na korisnički QoE [14].
• Terminalna oprema – Aplikacije su kompatibilne sa različitim vrstama
terminalnih uređaja. Za video aplikacije se mogu koristiti sljedeći terminalni
uređaji: mobilni telefoni, računari ili TV (engl. Television) uređaji. Svaki od ovih
uređaja je karakteriziran vlastitim medijskim i terminalnim sposobnostima kao što
su: rezolucija, boja, kodiranje, osjetljivost prijemnika itd. Postoje tri načina na koja
terminalna oprema utiče na korisnički QoE. Prvo, posjedovanjem uređaja sa
velikom procesorskom snagom i velikim sposobnostima za pohranu, korisnici koji
imaju snažnije uređaje mogu doživjeti bolju QoE od onih korisnika sa slabijim
uređajima, iako su opskrbljeni sa istom vrijednošću QoS-a. Drugo, kako bi
iskoristili pogodnosti svojih uređaja, korisnici sa snažnijim uređajima mogu
zahtjevati od mreže pružanje većeg QoS-a. Treće, korisnički QoE u velikoj mjeri
ovisi o performansama terminalnih uređaja kao što su potrošnja energije, cijena itd.
Većina navedenih faktora koji utiču na QoE se mijenja tokom vremena i veoma ih je teško
kontrolisati. Subjektivni faktori kao što su korisničke emocije, iskustva i očekivanja su
različiti za svakog korisnika pojedinačno i kao takvi veoma se teško kontroliraju, dodatno,
okruženje u kome se pruža određena usluga također ima veliki uticaj na kvalitetu
korisničkog iskustva.
Objektivni pristup proizilazi iz subjektivnog korisničkog QoE-a korištenjem algoritama ili
formula baziranih na objektivnim parametrima mreže, aplikacija, terminalnih uređaja,
okruženja i korisnika. Ove metode obično modeliraju QoE kao funkciju QoS parametara
mrežnog i aplikacijskog nivoa [14].
14
2.1. Standardizacijska tijela i QoE
Koncept QoE-a se analizira u okviru brojnih standardizacijskih tijela. U ovom djelu će se
dati osvrt na preporuke standardizacijskih tijela koja se bave QoE tematikom.
2.1.1. ITU-T
ITU-T je jedna od vodećih grupa zadužena za definisanje QoS-a i QoE-a. Ovdje će se
navesti neke osnovne ITU-T preporuke vezane za QoE:
• ITU-T G.1010 – u okviru ove ITU-T preporuke definirani su osnovni QoS
parametri, kašnjenje, jitter, gubici, koji direktno utiču na korisnički QoE. Također,
izvršena su određena razmatranja o prihvatljivim vrijednostima ovih parametara za
audio, video i podatkovne aplikacije [13].
• ITU -T G.1030 – ovom preporukom predložen je model za estimaciju performansi
podatkovnih aplikacija preko IP mreže. Ovaj model se sastoji od tri koraka, koja se
sastoje od procjeni performansi: mreže, aplikacija i korisničke percepcije. U trećem
koraku se uvodi ideja korisničkog iskustva (percepcije) [13].
• ITU-T G.1070 – ova preporuka opisuje model proračuna za interaktivne video
aplikacije preko IP mreže. Ovaj model se koristi kao QoE/QoS alat za planiranje na
osnovu kojeg se mogu procijeniti različite varijacije u nekoliko audio/video
parametara koji utiču na QoE. Ovaj model mogu koristiti QoE/QoS planeri, kako bi
se osiguralo da krajnji korisnici budu zadovoljni kvalitetom usluge koju
konzumiraju. Model predviđen ovom preporukom treba da bude fleksibilan alat
koji je u stanju da omogući povratne informacije kako o individualnim kvalitetima,
tako i o ukupnoj kvaliteti. Primjena ove preporuke je ograničena na QoE/QoS
planiranje [16].
• ITU-T P.911 – ova preporuka opisuje ne-interaktivne subjektivne metode za
procjenu ukupnog audio-vizuelnog kvaliteta za multimedijalne aplikacije kao što su
video konferencija, aplikacije za pohranjivanje i pretraživanje pohranjenog
sadržaja, itd. Ove metode se mogu koristiti za nekoliko različitih namjena,
uključujući izbor algoritama, rangiranje audio-vizuelnih performansi sistema i
procjenu nivoa kvalitete za vrijeme audio-vizuelne konekcije. Nakon utvrđivanja
15
interaktivnih aspekata, primjenjuju se metode za testiranje konverzacije opisane u
ITU-T preporuci P.920 [17].
2.1.2. Broadband Forum
Broadband Forum je također zadužen za definisanje QoE-a i njegove veze sa QoS-om.
Fokus istraživanja ovog foruma su triple-play usluge. Broadband Forum definiše QoE na
sličan način na koji je to uradilo ITU-T standardizacijsko tijelo. Cilj ovog
standardizacijskog tijela je da osigura jasan odnos između QoE-a i QoS-a, koji će
omogućiti estimaciju QoE-a za dati set QoS parametara. Na osnovu željene vrijednosti
QoE-a, mogle bi se izračunati potrebne performanse mreže [13].
2.1.3. TeleManagement Forum
TeleManagement Forum (TM Forum) posmatra QoE sa perspektive upravljanja SLA
(engl. Service Level Agreement) ugovorom. TM Forum definira KQI (engl. Key Quality
Indicator) i KPI (engl. Key Performance Indicator) indikatore mjerenja percipirane
kvalitete, a ne performansi mreže. Ključni indikatori kvaliteta KQI se sastoje od KPI, a
KPI se dobivaju na osnovu mjerenja mrežnih performansi [13]. Ključni indikatori
performansi KPI mogu biti: dostupnost usluge (bilo kada), pristupačnost usluzi (u bilo koje
vrijeme), kontinuirana konekcija, vrijeme pristupa, odziv sistema, ukupno kašnjenje,
varijacija kašnjenja itd. [15].
2.1.4. ETSI
Standardizacijsko tijelo ETSI se također bavi definicijom QoE-a, i analiziranjem odnosa
između QoS i QoE parametara. Precizno definisanje faktora koji mogu uticati na QoE
predstavlja osnovu za osiguravanje dobre vrijednosti QoE-a. U okviru ETSI EG 202 843
V1.1.2 preporuke detaljno su predstavljene definicije i metode za procjenu vrijednosti QoS
parametara koji posljedično imaju uticaj na korisnički QoE. Osnovna svrha ovog
dokumenta je da osigura da rezultati mjerenja QoS parametara budu ponovljivi i statistički
validni. Kao takvi, ovi parametri bi se mogli koristiti za procjenu performansi dostavljenih
QoS parametara od strane pružatelja usluga. Ovaj dokument ne definiše QoS parametara za
pojedine telekomunikacijske usluge (ove informacije se mogu pronaći u drugim ETSI
dokumentima, npr. EG 202 057 i EG 202 765). Rezultati prikazani u ovom dokumentu
16
mogu se koristiti za poređenje performansi različitih pružatelja usluga tokom vremena
[18].
2.2. Mjerenje kvalitete korisni čkog iskustva
Jedan od osnovnih izazova NGN mreža je modeliranje usluga na takav način da se
omogući smisleno izvođenje QoE mjerenja. Iako je QoE u osnovi subjektivne prirode,
mora postojati način da se sa QoE-om kvantitativno izrazi korisničko zadovoljstvo vezano
za određenu uslugu koju on konzumira [14]. Subjektivne metode mjerenja QoE-a praktično
mogu generisati prihvatljive vrijednosti, budući da QoE izražava kvalitet usluge kojeg
korisnik subjektivno percipira, a koji se izražava ljudskim osjećanjima kao što su
„odličan“, „dobar“, „prosječan“ i „loš“. Međutim, korisnici rijetko odvajaju svoje vrijeme
na ocjenjivanje određene usluge ukoliko nisu zadovoljni tom istom uslugom, samim tim
oni neće omogućiti nikakve informacije pružatelju usluge na osnovu kojih bi on mogao
zaključiti zbog čega dati korisnik nije zadovoljan uslugom pa neće ni poduzeti preventivne
mjere kako bi poboljšao to stanje.
Zbog navedenih činjenica potrebno je osmisliti metode za mjerenje QoE-a na što realniji
način. U tom pogledu može biti veoma koristan pristup odozgo prema dole (engl. top-
down) [15]:
• identificirati i razumjeti faktore (metrike) koji utiču na korisničku percepciju,
• primjeniti ta znanja za definisanje operativnih zahtjeva,
• osmisliti metodologiju za kontinualno mjerenje identificiranih faktora.
Za potrebe mjerenja QoS parametara mreže predložene su brojne metrike kao što su:
kašnjenje paketa, gubitak paketa, redoslijed paketa i jitter. Ove metrike se često nazivaju
ključnim indikatorima performansi KPI. Razvoj QoE koncepta zahtjeva definisanje novih
metrika koje se nazivaju ključni indikatori kvaliteta KQI [19].
Nakon identificiranja QoE metrika potrebno je ustanoviti očekivanja svih entiteta odnosno
korisnika u posmatranom okruženju. Postojat će onoliko različitih očekivanja koliko ima
korisnika, ali se većina ovih očekivanja može grupisati u sljedeće kategorije:
• Dostupnost usluge – mjera kojom se određuje da li korisnik može koristiti željenu
uslugu;
17
• Odziv usluge – mjera kojom se određuje vrijeme od specifičnog korisničkog
zahtjeva do trenutka kada korisnik dobije odgovor na poslati zahtjev;
• Kvalitet – mjerenje gubitka informacije koje može nastati uslijed gubitka paketa ili
degradacija unesenih za vrijeme kodiranja/dekodiranja medija.
Računarski modeli, za proračun kvalitete glasa, bazirani na najpoznatijoj subjektivnoj
metrici MOS (engl. Mean Opinion Score) su dobro razrađeni i validirani pomoću brojnih
testova koji se nude korisnicima da ocjene kvalitet konzumirane usluge [13]. Metodologija
subjektivnog ocjenjivanja MOS predstavlja brojčana mjerenja koja su korištena za ocjenu
percipirane kvalitete korištene usluge. Izražava se vrijednostima od 1 do 5. Određivanje
jedne MOS ocjene za uslugu koja zavisi od velikog broja faktora koji utiču na cjelokupnu
vrijednost korisničkog QoE-a je veoma teško, osim ukoliko QoE nije pažljivo proučen za
svaki faktor uz povratnu informaciju od velikog broja stvarnih korisnika [13].
2.2.1. Usporedba metoda QoE mjerenja
Analiziranje usluge, identificiranje i razumijevanje faktora koji utiču na QoE može se
efikasno primjeniti za mjerenje promjena u ukupnom korisničkom QoE-u. Promjene u
mreži vezane za alokaciju propusnog opsega, kapacitet opreme ili druge promjene na
komponentama koje su zadužene za pružanje usluge, mogu izazvati promjene QoE-a.
Pored identificiranja i razumjevanja faktora koji utiču na QoE sa aspekta korisnika, veoma
je bitno razumjeti vezu između tih faktora i komponenti koje su zadužene za pružanje
usluga. Ovo će omogućiti praćenje degradiranih QoE vrijednosti do njihovog uzročnika i
što je još bitnije omogućit će verifikaciju ukoliko je optimizacija rezultirala poboljšanjem
QoE-a.
Kako bi se izmjerio QoE za uslugu prenosa glasa može se primjeniti sljedeći pristup.
Naime, može se izvršiti par testova kojim će korisnici ocijeniti kako su zadovoljni datom
uslugom (primjenom MOS metodologije). Dobivene MOS ocjene za ovu uslugu se
statistički agregiraju i upoređuju sa unaprijed definiranim graničnim vrijednostima.
Operatori mogu definirati ključne KQI vrijednosti koje će pokazivati ukupni kvalitet date
usluge. Na primjer, ključna KQI metrika može navesti da prosječna MOS ocjena za uslugu
prenosa glasa, za period mjerenja od jedne sedmice, treba da bude iznad 3.5 za 99.5%
poziva. Tradicionalni kvalitet usluge bi bio izražen u smislu broja poziva koji
zadovoljavaju određeni nivo kvaliteta usluge. Primjena ovakve metodologije mjerenja je
18
moguća ukoliko se radi o jednostavnim uslugama, i ukoliko se mjeri samo jedan faktor koji
utiče na kvalitet usluge. Na primjer, ukoliko se za prethodni primjer navede da se 99.5%
poziva mora uspostaviti sa kašnjenjem manjim od 1s. Međutim, primjena iste metodologije
za ocjenu usluge prenosa glasa za koju se zahtjeva da ispunjava prethodno definisane
vrijednosti za kašnjenje uspostave poziva i kvalitet glasa, neće dati prihvatljive rezultate za
QoE. Za korisničku percepciju kvaliteta usluge oba faktora su važna. Veliko kašnjenje pri
uspostavi poziva ili loš kvalitet glasa će jednako rezultirati lošim QoE-om za korisnika.
Pojava ovih faktora u okviru jedne sesije će rezultirati time da će korisnik potpuno biti
nezadovoljan korištenom uslugom [13].
Kako bi primijenili istu metodologiju za analizu QoE-a za uslugu koja pored prenosa glasa
uključuje prenos slike i videa, pored MOS ocjene za kvalitet glasa potrebno je odrediti i
dodatne faktore koji utiču na kvalitet slike i videa. Pronalaženje i razumijevanje glavnih
faktora koji utiču na korisnički percipirani kvalitet usluge, njihove veze i odnose sa
komponentama zaduženim za pružanje usluge predstavlja veliki izazov. Ovaj proces
obuhvata nekoliko koraka koji će biti opisani u nastavku [13]:
1. Definisanje tačaka razgraničenja sesije – mjerenje QoE-a određene usluge treba
biti izvodivo između tačnih tačaka razgraničenja npr. vrijeme aktiviranja neke
usluge i vrijeme njenog terminiranja. Metrike QoE-a se mogu odnositi samo na
korisničko iskustvo u okviru granica određene sesije. Definisanje tačaka
razgraničenja je veoma jednostavno za neke usluge. Na primjer, VoIP usluga ima
jasne tačke razgraničenja, sesija se uspostavlja kada korisnik digne slušalicu, a
završava kada korisnik spusti slušalicu. Za usluge poput IPTV-a (engl. Internet
Protocol Television) tačke razgraničenja nisu jasne. Korisnik može gledati neki TV
sadržaj tokom dana i može istovremeno mijenjati kanale. Svaki kanal može imati
različit kvalitet. Neki kanali mogu biti isporučeni s visokom kvalitetom HD (engl.
High Definition), a drugi sa standardnom kvalitetom SD (engl. Standard
Definition). Korisnička očekivanja su različita za ove dvije vrste kanala. Jedno od
rješenja je da se sesija ograničava sa vremenom trajanja gledanja nekog kanala. Još
jedna metrika kod IPTV usluge koja utiče na QoE je vrijeme potrebno da se prebaci
s jednog kanala na drugi. Kako NGN usluge postaju složenije to postaje i teže
definisati tačne tačke razgraničenja, međutim, pouzdanost mjerenja QoE-a za
određenu uslugu u velikoj mjeri zavisi od tačnog definisanja tačaka razgraničenja
sesije.
19
2. Dekompozicija sesije usluga – potrebno je razdvojiti sesiju usluga u zasebne,
mjerljive elemente koji mogu uticati na ukupni QoE usluge. Korisnik može
direktno percipirati svaki od tih elemenata. Na primjer, jednostavni VoIP poziv se
može razdvojiti na sljedeće elemente:
• početak usluge – korisnik podiže slušalicu telefona i čeka ton biranja,
• vrijeme uspostave konekcije – korisnik bira brojeve i čeka ton zvonjenja,
• kvalitet glasa – MOS ocjena razgovora,
• vrijeme završetka poziva – korisnik spušta slušalicu i čeka potvrdu.
Elementi usluge mogu biti grupisani u prethodno spomenute kategorije, a to su
dostupnost, upotrebljivost i kvalitet usluge.
Na slici 2.2 je prikazan generički pristup modeliranja mjerenja QoE-a za određenu
uslugu. Ključni indikatori kvaliteta KQI svakog elementa usluge mogu se odrediti
prema kriteriju kojeg je definisao operator kako bi se naglasila važnost mjerenja.
Ovi KQI se zatim normaliziraju i grupišu u kategorije.
Sl. 2.2 Generički pristup za modeliranje mjerenja QoE-a [13]
3. Dekompozicija arhitekture usluga – cilj ovog koraka je analiziranje veze između
funkcionalnih elemenata usluge i arhitekturalnih komponenti usluge. Kod IMS
VoIP aplikacije, kašnjenje prilikom uspostave poziva može biti mjereno na
različitim tačkama arhitekture, npr. na korisničkom uređaju, SBC (engl. Session
Border Controller) čvoru ili na nekom drugom IMS mrežnom elementu. Za usluge
20
koje pored prenosa glasa uključuju prenos slika i videa, svaki od elemenata može
biti uzrok velikih vrijednosti kašnjenja prilikom uspostave poziva. Kada se izmjeri
loš QoE, faktori koji su doprinijeli takvoj vrijednosti se moraju pratiti do izvora
problema, kako bi se mogle primjeniti neke adekvatne korektivne mjere.
2.3. Sažetak
Jedan od osnovnih zahtjeva NGN mreža je omogućavanje isporuke usluga sa visokom QoE
za korisnike. Drugo poglavlje detaljno obrađuje tematiku QoE-a u mrežama nove
generacije. Budući da su brojna istraživanja vezana za mjerenje i upravljanje kvalitetom
usluge QoS, a ne kvalitetom iskustva QoE, ovo poglavlje definiše osnovne razlike i
međuodnose između ova dva pojma. Koncept kvaliteta usluge je izuzetno značajan zbog
obezbjeđivanja adekvatne podrške velikom broju aplikacija. Potrebno je obezbjediti usluge
sa jakim garancijama kvaliteta koji će ispuniti zahtjeve krajnjih korisnika i samim tim
opravdati njihovo povjerenje u pružatelja usluga. Iako je QoS veoma važan za pružatelje
usluga, QoE ima jednako toliku važnost. Smatra se da povećanje performansi QoS
parametara utiče na poboljšanje ukupne QoE za korisnike. Pred povezanosti sa QoS-om, u
ovom poglavlju su navedeni i drugi faktori koji imaju uticaj na QoE, ti faktori obuhvataju
performanse cijelog sistema.
U ovom poglavlju je također dat pregled standardizacijskih tijela koja se bave QoE
tematikom. Dalje, u okviru ovog poglavlja obrađena je i tematika koja se bavi mjerenjem
QoE-a. Za što vjerodostojnije mjerenje QoE-a za neku uslugu potrebno je identificirati sve
faktore koji mogu uticati na QoE, a zatim definirati neko rješenje koje će omogućiti
kontinuirano mjerenje tih faktora. Pronalaženje i razumijevanje glavnih faktora koji utiču
na korisnički percipirani kvalitet usluge, njihove veze i odnose sa komponentama
zaduženim za pružanje usluga predstavlja veliki izazov. Ovaj proces obuhvata sljedeće
korake: definisanje tačaka razgraničenja sesije, dekompozicija sesije usluga i
dekompozicija arhitekture usluga. U sljedećem poglavlju će se opisati VoIP usluga i njene
osnovne komponente.
21
3. Voice over Internet Protocol
Kako je Internet postao univerzalna mreža današnjice, nove Internet kompatibilne
komunikacijske aplikacije su postale dominantne nad aplikacijama tradicionalnih
telefonskih mreža baziranih na komutaciji krugova PSTN. Usluga prenosa glasa preko IP
protokola VoIP je veoma popularna zbog svojih značajnih primjena i jednostavnog
korištenja. Ovi faktori dovode VoIP usluge do sve veće popularnosti i otvaraju vrata prema
istraživačkim područjima, kao što su poboljšanje kvalitete i sama evolucija VoIP usluge
[20]. Sa aspekta uspostave govornog poziva, za razliku od PSTN mreža, VoIP razdvaja
signalizaciju i glas u zasebne pakete za prenos preko IP mreže. Takvi paketi se svrstavaju
u sljedeće tri kategorije: signalizacija, glas, izvještavanje ili praćenje (engl. reporting or
monitoring) [21].
Osnovne komponente VoIP usluge su:
• uspostava sesije,
• prenos medijskog sadržaja,
• raskid sesije.
Za signalizacijske procedure u VoIP-u se koristi SIP protokol, a za prenos medijskog
sadržaja se koristi RTP protokol. Protokol RTP se koristi zajedno sa RTCP (engl. Real-
time Control Protocol) protokolom koji omogućava QoS mehanizme za osiguravanje
kvaliteta prenosa podataka.
Sl. 3.1 Prikaz uspostave VoIP poziva korištenjem SIP i RTP protokola
22
U ovom djelu će se dati osnovni koncepti VoIP usluge, postavljeni u mrežnom kontekstu,
kao što su SIP protokol i multimedijalni podsistem zasnovan na IP protokolu IMS.
3.1. Session Initiation Protocol
Protokol SIP je razvijen u okviru IETF-a kao kontrolni protokol za upravljanje
multimedijalnim sesijama. Osnova uloga SIP protokola je uspostavljanje, održavanje i
prekidanje sesija između dva ili više učesnika u komunikaciji. Protokol SIP je baziran na
HTTP (engl. Hypertext Transport Protocol) transakcijskom modelu zahtjeva i odgovora
(engl. request/response transaction model). Svaka transakcija se sastoji od zahtjeva koji
poziva određenu metodu ili funkciju poslužitelja, te barem jednog odgovora na traženi
zahtjev. Protokol SIP se ne koristi za opis obilježja sesije kao što su tip medija, kodek,
frekvencija uzrokovanja, nego tijelo SIP poruke nosi karakteristike sesije za čije opisivanje
se koristi SDP (engl. Session Description Protocol) protokol [22].
Poruke SIP protokola mogu se prenositi preko UDP (engl. User Datagram Protocol) ili
TCP (engl. Transmission Control Protocol) protokola. Međutim, u većini implementacija
se koristi UDP kao transportni protokol, pri čemu su pouzdane procedure isporuke
obezbijeđene SIP protokolom.
U nastavku će se opisati signalizacijske procedure procesa registracije, uspostave i prekida
sesije koje su potrebne za analizu metrika karakterističnih za signalizaciju.
3.1.1. Signalizacijska procedura procesa registraci je korisnika
Općenito da bi se u IMS arhitekturi mogli prosljeđivati pozivi za korisnika, potrebno je
poznavati lokaciju korisnika. Iz tih razloga mreža zahtjeva da se svi korisnici registruju na
mrežu kada žele obavljati bilo koju aktivnost. U slučaju da se promjeni lokacija korisnika,
isti se ponovo mora registrovati na mrežu kako bi se obnovile informacije o trenutnoj
korisničkoj lokaciji. Proces registracije počinje kada UA (engl. User Agent) čvor pošalje
SIP REGISTER zahtjev P-CSCF čvoru. REGISTER zahtjev može da sadrži identitet
korisnika koji se registruje i naziv domene domaće mreže. Čvor P-CSCF obrađuje
REGISTER zahtjev i koristi ime domaće domene kako bi odredio IP adresu I-CSCF-a.
Čvor I-CSCF šalje zahtjev za autorizacijom HSS bazi podataka, od koje dobiva
informacije potrebne za odabir S-CSCF čvora. Nakon odabira S-CSCF čvora, I-CSCF
23
prosljeđuje REGISTER poruku S-CSCF čvoru. Ukoliko korisnik nije autoriziran za datu
sesiju, S-CSCF zahtjeva autorizacijske podatke od HSS-a i šalje poruku 401 Unauthorized
u okviru poruke odgovora. Korisnički agent generiše odgovor i šalje ponovo REGISTER
poruku koja prolazi istom putanjom kao i prvi put. Čvor S-CSCF provjerava odgovor, i
ukoliko je on ispravan preuzima korisnički profil iz HSS baze podataka i potvrđuje
registraciju slanjem 200 OK poruke [8].
Sl. 3.2 Signalizacijska procedura procesa registracije korisnika
3.1.2. Signalizacijske procedure uspostave i prekid a sesije
Kada korisnik A želi uspostaviti sesiju sa korisnikom B on generiše SIP INVITE zahtjev i
šalje ga P-CSCF-u. Čvor P-CSCF procesira INVITE zahtjev, dekompresuje ga i provjerava
korisnički identitet prije nego što proslijedi zahtjev S-CSCF-u. Čvor S-CSCF zatim
procesira zahtjev, izvršava kontrolu usluge koja može uključivati interakciju sa
aplikacijskim serverima, i eventualno određuje ulaznu tačku domaće mreže korisnika B na
osnovu identiteta korisnika B koji se nalazi u SIP INVITE zahtjevu. Čvor I-CSCF
24
kontaktira HSS bazu podataka kako bi pronašao S-CSCF koji poslužuje korisnika B. Čvor
S-CSCF koji poslužuje korisnika B prosljeđuje INVITE zahtjev korisniku B preko P-
CSCF-a [8]. Nakon toga korisnik B prihvata INVITE zahtjev i šalje 200 OK poruku u
odgovoru koja ukazuje na uspješno uspostavljanje sesije.
Sl. 3.3 Signalizacijska procedura uspostave sesije
Ukoliko bilo koji od korisnika želi da prekine uspostavljenu sesiju on će generisati BYE
poruku. Na primjer, ukoliko korisnik A želi prekinuti sesiju, on generiše BYE poruku i
šalje je P-CSCF čvoru. Poruka BYE se prosljeđuje preko svih mrežnih modula do
korisnika B. Svi CSCF čvorovi treba da otklone sva stanja dijaloga i sve informacije
vezane za uspostavljenu sesiju. Po prijemu BYE poruke, korisnik B odgovara sa 200 OK
porukom. Kada 200 OK poruka dođe do korisnika A, sesija je uspješno prekinuta.
25
Sl. 3.4 Signalizacijska procedura procesa prekida sesije
3.2. Real-time Transport Protocol
Kako bi se omogućio prenos glasa preko IP mreže, prvo je potrebno izvršiti konverziju
analognog signala u digitalni oblik. Postupak konverzije se izvodi pomoću odgovarajućeg
kodeka. Upotrebom kodeka analogni signal na predajnoj strani se kodira u digitalni signal,
koji se na prijemnoj strani ponovo dekodira u analogni oblik. Najčešće korišteni kodeci su
G.711, G.726, G.723.1, i G.729 [23]. Nakon što je uspostavljena veza potrebno je
digitalizirane dijelove govora dostaviti na određenu destinaciju. Za prenos VoIP paketa se
uglavnom koristi RTP protokol. Prema RFC 3550 preporuci, svrha RTP protokola je
„omogućiti end-to-end transportne mrežne funkcije za prenos podataka u stvarnom
vremenu“. Protokol RTP određuje strukturu paketa koji prenose audio ili video zapise. Ovi
paketi pružaju: identifikaciju tipa sadržaja (kodiranje), numerisanje (sekvence brojeve)
paketa i vremenske oznake paketa. Protokol RTP je transportni protokol aplikacijskog
nivoa koji se uglavnom prenosi preko UDP protokola. Potokol RTP ne osigurava nikakve
mehanizme za osiguravanje pravovremenske isporuke podataka ili druge QoS garancije.
Enkapsulaciju RTP paketa vide samo krajnje tačke komunikacije, stoga ne postoji nikakav
poseban tretman RTP paketa na mrežnim čvorovima koji bi osigurao pravovremensku
isporuku paketa [24].
26
Protokol RTCP je kontrolni protokol koji je također definisan u okviru preporuke RFC
3550. Kada se uspostavi RTP sesija između dva host-a, istovremeno se uspostavlja i RTCP
sesija. Svaki učesnik u RTP sesiji periodično šalje RTCP kontrolne pakete svim drugim
učesnicima. Svaki RTCP paket sadrži izvještaj pošiljaoca i/ili primaoca, odnosno statistike
koje su korisne za aplikaciju: broj poslanih paketa, broj izgubljenih paketa, varijacije u
kašnjenju (engl. jitter) itd. [24].
3.3. Metrike karakteristi čne za kvalitet VoIP usluga
Nakon definisanja osnovnih komponenti VoIP usluge i protokola zaduženih za
signalizaciju i prenos podataka, potrebno je identificirati glavne QoS metrike koje se
odnose na kvalitet signalizacije i kvalitet isporuke VoIP poziva. Slika 3.5 prikazuje ključne
metrike karakteristične za signalizacijske komponente VoIP usluge.
Sl. 3.5 Metrike performansi VoIP signalizacije koje utiču na kvalitet korisničkog iskustva
U nastavku će se opisati samo neke od navedenih metrika čije će mjerenje biti izvedeno u
praktičnom dijelu ovog rada.
3.3.1. Kašnjenje zahtjeva za registraciju
Kašnjenje zahtjeva za registraciju RRD (engl. Registration Request Delay) predstavlja
kašnjenje odgovora na REGISTER zahtjev. Ova metrika se mjeri i analizira samo za
27
uspješne REGISTER zahtjeve [25]. Vrijednost RRD metrike je numerička i izražava se u
milisekundama (formula 1):
RRD = vrijeme prijema konačnog odgovora – vrijeme slanja REGISTER zahtjeva (1)
Dakle, RRD metrika se definiše kao vremenski interval koji protekne od trenutka kada UA
pošalje prvi bit REGISTER poruke, do trenutka kada on primi posljednji bit 200 OK
poruke koja označava uspješnu registraciju. Ovaj dijalog uključuje provjeru autentifikacije
prije prijema 200 OK poruke odgovora.
Sl. 3.6 Prikaz kašnjenja zahtjeva za registraciju
3.3.2. Kašnjenje zahtjeva za uspostavu sesije
Kašnjenje zahtjeva za uspostavu sesije SRD (engl. Session Request Delay) opisuje
kašnjenje odgovora na INVITE zahtjev. Ova metrika se mjeri i za uspješne i za neuspješne
procedure uspostave sesije i ta mjerenja se obično povezuju sa iskustvom korisnika [25].
Vrijednost SRD je numerička i izražava se u sekundama (formula 3):
SRD = vrijeme prijema indikativnog odgovora – vrijeme slanja INVITE zahtjeva (3)
U slučaju da je zahtjev uspješno procesiran, SRD se definiše kao vremenski interval od
trenutka slanja prvog bita inicijalne INVITE poruke do trenutka prijema prvog bita poruke
odgovora na taj zahtjev. Slika 3.7 prikazuje razmjenu poruka koja opisuje SRD metriku
prilikom uspješne uspostave sesije bez preusmjeravanja.
28
Sl. 3.7 Prikaz kašnjenja zahtjeva za uspješnu uspostavu sesije bez preusmjeravanja
Slika 3.8 prikazuje razmjenu poruka koja opisuje SRD metriku za uspješnu uspostavu
sesije s preusmjeravanjem.
Sl. 3.8 Prikaz kašnjenja zahtjeva za uspješnu uspostavu sesije sa preusmjeravanjem
Kod neuspješnog procesiranja zahtjeva, SRD metrika se računa kao vremenski interval od
trenutka kada prvi bit inicijalne INVITE poruke koja sadrži potrebne informacije, pošalje
izvorni UA1 čvor, do trenutka kada on primi posljednji bit prvog privremenog odgovora ili
odgovora koji indicira neuspjeh. Neuspjeh je opisan sljedećim klasama odgovora: 4xx
(osim 401, 402 i 407), 5xx i 6xx [25]. Slike 3.9 i 3.10 prikazuju razmjenu poruka koje
29
opisuju SRD metriku prilikom neuspješnog procesiranja zahtjeva za uspostavu sesije, bez
preusmjeravanja i sa preusmjeravanjem.
Sl. 3.9 Prikaz kašnjenja zahtjeva pri neuspješnom procesiranju zahtjeva za uspostavu sesije bez
preusmjeravanja
Sl. 3.10 Prikaz kašnjenja zahtjeva pri neuspješnom procesiranju zahtjeva za uspostavu sesije sa
preusmjeravanja
30
3.3.3. Kašnjenje prekida sesije
Kašnjenje prekida sesije SDD (engl. Session Disconnect Delay) se koristi za detekciju
kvarova ili oštećenja, što dovodi do kašnjenja u terminiranju sesije. Metrika SDD se mjeri i
za uspješno i za neuspješno terminiranje sesije. Međutim, SDD za neuspješno terminiranje
sesije se ne smije kombinovati sa rezultatima za uspješno terminiranje sesije [25]. Izlazne
vrijednosti ove metrike su numeričke i izražavaju se u milisekundama (formula 4):
SDD = vrijeme prijema 2xx poruke – vrijeme slanje BYE poruke (4)
Dakle, SDD se mjeri kao vremenski interval između prvog bita poslane poruke za
terminiranje sesije (BYE) do trenutka prijema posljednjeg bita poruke odgovora 2xx [25].
Na slici 3.11 je prikazana razmjena poruka koja opisuje SDD metriku na izvornom UA1
čvoru i odredišnom UA2 čvoru, prilikom uspješnog prekida sesije.
Sl. 3.11 Prikaz kašnjenja uspješnog prekida sesije mjerenog na: a) izvorišnom čvoru UA1; b)
odredišnom čvoru UA2
3.3.4. Vrijeme trajanja sesije
Vrijeme trajanja sesije SDT (engl. Session Duration Time) se koristi za detekciju problema
koji uzrokuju kratko trajanje sesije (npr. loš kvalitet audio signala). Metrika SDT se mjeri
za uspješne i neuspješne pokušaje terminiranja sesije [25]. Izlazna vrijednost ove metrike
31
je numerička i izražava se u sekundama. Metrika SDT se računa prema sljedećoj formuli
(formula 5):
SDT = vrijeme slanja BYE poruke – vrijeme prijema 200 OK poruke (5)
U slučaju uspješnog završetka sesije, SDT metrika mjerena na izvorišnom UA1 čvoru, se
računa kao vremenski interval koji protekne od trenutka prijema prvog bita 200 OK poruke
odgovora do trenutka prijema posljednjeg bita BYE poruke, koja indicira de je razmjena
poruka završena. U slučaju da se mjerenje vrši na odredišnom UA2 čvoru, SDT metrika se
računa kao vremenski interval koji protekne od trenutka slanja prvog bita 200 OK poruke
odgovora do trenutka slanja posljednjeg bita BYE poruke.
Sl. 3.12 Prikaz vremena trajanja uspješne sesije na: a) izvorišnom čvoru UA1; b) odredišnom
čvoru UA2
U slučaju neuspješno prekinute sesije, SDT metrika koja se mjeri na izvorišnom UA1
čvoru se definiše kao vremenski interval koji protekne od trenutka prijema prvog bita 200
OK poruke odgovora na INVITE zahtjev do trenutka isteka vremenskog brojača F. U
slučaju mjerenja na odredišnom UA2 čvoru, SDT metrika se definiše kao vremenski
interval koji protekne od trenutka slanja posljednjeg bita 200 OK poruke odgovora na
INVITE zahtjev do trenutka isteka vremenskog brojača F.
32
Sl. 3.13 Prikaz vremena trajanja neuspješne sesije na: a) izvorišnom čvoru UA1; b) odredišnom
čvoru UA2
3.3.5. Kašnjenje i varijacija kašnjenja
Ukupno kašnjenje se definiše kao vrijeme potrebno da govorni signal stigne od predajne do
prijemne strane. Ovo kašnjenje predstavlja rezultat VoIP/IP mrežnog procesiranja i
prenosa paketa. Kašnjenje utiče na kvalitet razgovora, međutim pri tome ne utiče na stvarni
zvuk govornog signala. Kašnjenje ne unosi šum i distoziju u kanal za prenos govornog
signala. Kada ukupno kašnjenje dostigne vrijednost od 250 milisekundi, učesnici u
komunikaciji primjećuju efekte izazvane uticajem ovog kašnjenja. Normalna konverzacija
se teško ostvaruje pri vrijednostima kašnjenja od 300 do 500 milisekundi. Međutim, za
VoIP usluge donja granica ukupnog kašnjenja treba biti u opsegu od 50 do 100
milisekundi, zbog operacija korištenog kodeka kao što su paketizacija i kompresija.
Varijacija kašnjenja (engl. jitter) uzrokuje izobličenje govornog signala. Jitter predstavlja
varijaciju u vremenima pristizanja individualnih paketa na odredište. Za podatkovne
mreže, jitter ne predstavlja veliki problem, budući da se dolazni paketi mogu buffer-ovati
na duži vremenski period. Buffer-ovanje omogućava da paketi budu isporučeni u istom
redoslijedu u kojem su generisani. Međutim, za real-time aplikacije kao što je prenos glasa,
jitter može biti tolerisan do određene mjere, ali se za njegovu vrijednost postavljaju strožije
gornje granice. Kada paketi dođu u vremenskom trenutku koji je iznad ove granice, oni se
odbacuju ili se uopšte ne razmatraju. Gubitak paketa direktno utiče na distorziju signala. U
33
VoIP sistemima se zahtjeva implementacija mehanizama za kontrolu i upravljanje gubitaka
paketa u cilju smanjenja negativnih efekata prouzrokovanih gubicima paketa [26].
3.3.6. Gubitak paketa
Protokol IP je po svojoj prirodi nepouzdani mrežni protokol. Ovaj protokol nema nikakve
mehanizme koji osiguravaju isporuku, pouzdanost, kontrolu toka, ili oporavak od grešaka.
Kao rezultat toga, paketi koji se prenose ovim protokolom mogu biti izgubljeni ili
duplicirani. Kada se IP paket koji prenosi digitalizirani govor izgubi, primljeni govorni
signal će biti izobličen. Dva osnovna uzroka gubitaka paketa su oštećenje paketa i
zagušenje na mrežnim čvorovima. Mreže bazirane na IP protokolu zagušenje na čvorovima
rješavaju preusmjeravanjem paketa. Međutim, preusmjeravanje uzrokuje povećavanje
ukupnog kašnjenja i jitter-a [26].
3.4. Mjerenje metrika koje uti ču na QoE usluge VoIP
Kako bi VoIP usluga postala alternativa tradicionalnom prenosu glasa korištenjem PSTN
mreže, ona mora osigurati prihvatljiv nivo kvaliteta govora kojeg percipira krajnji korisnik.
Paketi VoIP usluge koji se prenose preko IP mreže su podložni oštećenjima koja nastaju
usljed kašnjenja i gubitaka. U kontekstu VoIP usluge, najvažnija je konačna procjena
kvaliteta govora koju percipira krajnji korisnik. U cilju procjene ukupnog QoE-a, potrebno
je razmotriti uticaj svih faktora na QoE. Postoje razne metode za mjerenje kvalitete govora
kojeg percipira krajnji korisnik u VoIP sistemu. Ove metode se mogu podijeliti u dvije
osnovne kategorije: subjektivne i objektivne metode mjerenja.
3.4.1. Subjektivne metode mjerenja kvaliteta
Subjektivne metode mjerenja zahtijevaju veliku skupinu korisnika u istom okruženju od
kojih se zahtjeva da ocjene kvalitet percipiranog govora sa određenom ocjenom. Najčešće
korištena subjektivna metoda za mjerenje kvaliteta je MOS. Metoda MOS je
standardizirana u okviru ITU-T preporuke P.800. Ova metoda predstavlja široko
prihvaćeni standard koji se koristi za ocjenjivanje kvalitete govora. Za ocjenjivanje
percipiranog kvaliteta govora, korisnicima je ponuđena skala MOS ocjena od 1 (loš) do 5
(odličan). Na osnovu ocjena dobivenih od svih ispitanika računa se prosječna vrijednost
koja predstavlja stvarni kvalitet prenesenog govora. Broj ispitanika mora biti dovoljno
34
velik kako bi se dobila tačna procjena kvalitete govora. Glavni nedostaci subjektivnih
MOS mjerenja su to što ova mjerenja zahtijevaju specijalizirane metodologije, stručno
osoblje i predstavljaju dugotrajan i skup proces [27].
3.4.2. Objektivne metode mjerenja kvaliteta
Prema definiciji, objektivne metode predstavljaju algoritme ili uređaje koji generišu
kvantitativnu mjeru kvalitete govora [27]. U posljednjih nekoliko godina razvijeni su
brojni algoritmi za predviđanje MOS rezultata. Ovim algoritmima su se eliminisali neki
nedostaci koji su nastali primjenom MOS subjektivne metode za mjerenje kvaliteta.
Razvijeni algoritmi moraju procijeniti da li je određeni govorni signal izobličen. Drugim
riječima, oni porede orginalni testni signal (signal glasa) sa izobličenom verzijom istog
signala. Korištenjem složenih težinskih metoda koje uzimaju u obzir perceptualne,
kognitivne i faktore koji se odnose na fizionomiju ljudskog uha, ovi algoritmi pružaju
kvalitativnu ocjenu koja se često kombinuje sa MOS ocjenama [26].
Objektivne metode za mjerenje kvalitete glasa mogu biti intruzivne i ne-intruzivne. Razlika
između ova dva tipa objektivnih metoda je u tome što su intruzivne metode bazirane na
signalu, a ne-intruzivne na mrežnim parametrima [27].
Najčešće korištena intruzivna metoda je PESQ (engl. Perceptual Evaluation of Speech
Quality), koja je definisana u okviru ITU-T preporuke P-862. Ova metoda uključuje
poređenje uzoraka izvornog orginalnog signala sa uzorcima signala koji prolazi kroz testni
mrežni kanal. Što je izlazni signal sličniji orginalnom signalu to se dodjeljuje veća ocjena
za kvalitet prenesenog signala. Izlaz PESQ metode je PESQ ocjena koja varira u rasponu
od -0,5 do 4,5 [20]. Metoda PESQ nije pogodna za mjerenje kvaliteta razgovora zbog
toga što ne uzima u obzir uticaj mrežnih i sistemskih parametara kao što su ukupno
kašnjenje, echo, smanjenje glasnoće govornog signala itd. Generalno rečeno, intruzivne
metode daju tačne rezultate, međutim, ove metode nisu pogodne za praćenje stvarnog
saobraćaja zbog njihove potrebe za referentnim signalom [27].
Ne-intruzivne metode ne trebaju referentni signal i pogodne su za praćenje stvarnog
saobraćaja. Najpoznatije ne-intruzivne metode su one bazirane na E-modelu, definisanom
u okviru ITU-T preporuke G.107.
E-model je dizajniran za mjerenje kvaliteta kojeg percipira krajnji korisnik, umjesto
kumulativnih efekata za vrijeme trajanja cijelog razgovora. E-model kombinira
35
kumulativne efekte faktora koji utiču na pogoršanje kvaliteta u R faktor koji se koristi za
ocjenu kvalitete prenosa. Ovaj faktor se izražava skalom vrijednosti od 0 do 100. Visoke
vrijednosti R faktora (od 90 do 100) se tumače kao odlična kvaliteta prenosa, dok niže
vrijednosti indiciraju da je kvalitet prenosa loš. R faktor se računa na osnovu sljedeće
formule (formula 6):
R=R0− I s− I d− I e+A (6)
R0 predstavlja SNR (engl. Signal-to-Noise Ratio) odnos, koji uzima u obzir različite izvore
šuma. Is faktor predstavlja kombinaciju svih faktora koji utiču na pogoršanje govornog
signala. Id faktor predstavlja pogoršanja uzrokovana kašnjenjem. Ie faktor predstavlja
pogoršanja uzrokovana malom brzinom korištenog kodeka, gubitkom paketa i slučajnom
distribucijom paketa. Faktor A u formuli (6) se odnosi na stepen učešća korisnika tokom
konverzacije.
E-model ne uzima u obzir samo prenosne statistike (transportno kašnjenje i gubitak
paketa). Ovaj model također razmatra karakteristike glasovne aplikacije kao što su: kvalitet
kodeka, robusnost kodeka u odnosu na gubitak paketa i zakašnjelo odbacivanje paketa
[20].
Hipoteza IQX ima za cilj predstavljanje QoE-a kao funkciju jednog degradacijskog faktora
(npr. omjer gubitaka paketa), koji određuje mrežni QoS. Ova hipoteza izražava QoE kao
eksponencijalnu funkciju degradacije QoS-a (formula 7) [27]:
QoE=α�e− β�QoS+γ (7)
Parametri α, β i γ zavise od vrste korištenog kodeka.
Veoma važno područje istraživanja VoIP operacija i performansi koje se mora testirati
uključuje signalizacijski proces koji omogućava uspostavu, održavanje i prekidanje VoIP
telefonskog poziva. Metrike karakteristične za signalizaciju su opisane u podpoglavlju 3.3.
Podaci dobiveni primjenom ovih metrika se preuzimaju kroz zapise o detaljima poziva
CDR (engl. Call Detail Records). Ukoliko se ove metrike računaju na individualnim
elementima (proxy serverima ili UA čvorovima), tada se na tim elementima mogu dobiti
različite vrijednosti metrika koje su mjerene za iste događaje. Dobiveni podaci se prenose
pomoću jedinstvenog mrežnog protokola za upravljanje SNMP (engl. Simple Network
Management Protocol) te budućih proširenja za upravljanje SIP podatkovnim bazama MIB
(engl. Management Information Base) [25].
36
Analizatori protokola koji mogu isporučiti dekodirani podatkovni tok (engl. stream) se
često koriste za ova testiranja i računanje SIP signalizacijskih metrika (npr. Wireshark).
Pored analizatora protokola za ova testiranja se koriste VoIP testni alati od kojih je
najpoznatiji SIPp generator saobraćaja.
3.5. Sažetak
Treće poglavlje obuhvata opis osnovnih komponenti VoIP usluge i protokola zaduženih za
realizaciju VoIP usluge. U ovom poglavlju dat je kratak opis SIP protokola kao osnovnog
protokola zaduženog za uspostavu i prekid sesije i RTP protokola zaduženog za prenos
digitaliziranih VoIP paketa preko IP mreže. U okviru ovog poglavlja također su opisane
signalizacijske procedure registracije, uspostave i prekida sesije koje su korištene prilikom
mjerenja vrijednosti metrika performansi SIP signalizacije. U dokumentu RFC 6076 kojeg
je objavio IETF definisane su osnovne metrike performansi SIP signalizacije
karakteristične za VoIP uslugu. U okviru ovog poglavlja opisane su samo neke od tih
metrika čije će se mjerenje realizovati u praktičnom dijelu ovog rada. Razmatrane metrike
su: kašnjenje zahtjeva za registraciju, kašnjenje zahtjeva za uspostavu sesije, kašnjenje
prekida sesije i vrijeme trajanja sesije. Pored opisanih metrika karakterističnih za
performanse SIP signalizacije navedene su i metrike karakteristične za prenos VoIP paketa,
a to su: ukupno kašnjenje, varijabilno kašnjenje i gubici paketa. U ovom poglavlju su
opisane i subjektivne i objektivne metode za mjerenje opisanih metrika. Navedene metode
su uglavnom korištene za procjenu mrežnih parametara i njihovog uticaja na QoE. Metode
za mjerenje performansi SIP signalizacije nisu definisane u okviru nekog klasičnog
standardiziranog modela procjene, ove metode se uglavnom zasnivaju na korištenju
određenih alata i analizatora protokola.
37
4. Povezana istraživanja
U ovom poglavlju će se dati pregled istraživačkih radova koji se bave razmatranjem uticaja
različitih faktora na kvalitetu korisničkog iskustva QoE. Poglavlje se sastoji od dva
podpoglavlja. U prvom podpoglavlju će se navesti istraživački radovi koji opisuju uticaje
različitih faktora na QoE, ovi faktori su uglavnom izraženi mrežnim parametrima (u smislu
QoS-a). Drugo podpoglavlje se fokusira na signalizacijske procedure koje utiču na QoE. Sa
objavom RFC 6076 dokumenta počinje intezivno istraživanje ove tematike. Radovi i
rezultati nastali prilikom istraživanja i analiziranja ove tematike će biti opisani u
podpoglavlju 4.2.
4.1. Povezana istraživanja o faktorima koji uti ču na QoE
J. Zhang i N. Ansari su u svom radu [14] klasificirali faktore koji utiču na QoE na
subjektivne i objektivne faktore (tehničke i ne-tehničke prirode). U skladu s tom podjelom
uveli su sljedeću klasifikaciju, QoE ovisan o: korisnicima, aplikacijama i terminalnim
uređajima. Generalno, na QoE ne utiču samo osobine ključnih mrežnih elemenata,
tehnološke performanse u smislu QoS-a, korisničke aktivnosti na datoj tehnologiji,
korisnički stepen zadovoljstva korištene usluge, i njihove namjere da koriste određenu
uslugu su također ključni faktori koji utiču na QoE. J. Baraković, S. Baraković i H. Bajrić
su u svom radu [28] opisali multimedijalni koncept QoE-a. Ovaj koncept razmatra sljedeće
faktore koji utiču na QoE: tehničke performanse, upotrebljivost, subjektivna procjena,
očekivanja i kontekst upotrebe.
P. Brooks i B. Hestnes su se u svom radu [29] fokusirali na razvoj koncepta QoE-a, ističući
zahtjeve za njegovo mjerenje i komunikaciju koja je pogodna za upotrebu u industriji.
Autori prikazuju objašnjenje struktuiranog pristupa za definiranje i mjerenje QoE-a u
odnosu na kvalitet usluge QoS. Razvijeno mjerenje QoE-a uključuje objektivne parametre
korisničkih performansi koji omogućavaju veću valjanost. Autori tvrde da bi globalno QoE
mjerenje trebalo omogućiti industrijskim profesionalcima da porede različite usluge,
proizvode i nivoe kvaliteta usluge. Struktuirani pristup pokazuje da QoE ima četiri
osnovna atributa: stanje komunikacije, opis usluge, tehničke parametre i korisničko
iskustvo.
38
M. Fiedler, T. Hossfeld, i P. Tran-Gia su u svom radu [30] predložili generičku formulu
(IQX hipoteza) u kojoj su QoE i QoS parametri povezani putem eksponencijalne funkcije.
Ova formula povezuje promjene u QoE-u s obzirom na QoS u trenutni nivo QoE-a. Ovaj
rad kvantificira QoS parametre u eksponencijalnu formulu, koja je provjerena na osnovu tri
slučaja upotrebe koja razmatraju različite QoE parametre: kvalitet glasa, korisnička
reakcija na vrijeme preuzimanja, i ograničenje propusnosti.
Sl. 4.1 Rezultati mjerenja i funkcija mapiranja fiLBC(pL) između omjera izgubljenih paketa i QoE-a
za iLBC kodek (iLBC kodek koristi se za VoIP uslugu Skype) [30]
Sl. 4.2 Rezultati mjerenja i funkcija mapiranja fG.711(pL) između omjera izgubljenih paketa i QoE-a
za G.711 kodek [30]
Maria-Dolores Cano i F. Cedan su u svom radu [31] izvršili istraživanje vezano za
subjektivnu procjenu QoE-a za VoIP aplikacije u realnom bežičnom okruženju i
39
diskutovali rezultate dobivenih mjerenja. Skype, Gizmo5, ooVoo, i Damaka su testirane
VoIP aplikacije. Analizirana je razlika između QoE rezultata i procijenjenih parametara
QoS-a za snimljeni video poziv. Rezultati pokazuju da ne postoji tačno podudaranje
između QoE i QoS rezultata. Ta razlika može biti posljedica toga što ukupni QoE ne može
biti procijenjen samo na osnovu efekata nekih QoS parametara ili zbog popularnosti same
VoIP usluge.
4.2. Povezana istraživanja o uticaju signalizacijsk ih
procedura i signalizacijskog optere ćenja na QoE
Većina istraživanja je bazirana na razmatranju uticaja tehnoloških performansi (u smislu
QoS-a) koje utiču na ukupni QoE-a. Relativno novo područje istraživanja predstavlja
razmatranje metrika karakterističnih za signalizaciju i njihovog uticaja na QoE.
Standardizacijsko tijelo IETF je u okviru preporuke [25] definisalo skup metrika za
procjenu performansi SIP signalizacije, koje imaju direktan uticaj na QoE. Nakon objave
ovog rada broj istraživanja vezanih za metrike karakteristične za SIP signalizaciju je naglo
porastao. U nastavku je dat pregled povezanih istraživanja koja se odnose na metrike
karakteristične za signalizaciju.
M. Happenhofer, C. Egger i P. Reichl su u okviru svog rada [32] definisali metrike pod
nazivom kvalitet signalizacije (QoSg) koje se odnose na pojedinačne SIP transakcije. Za
NON-INVITE transakcije definisane su sljedeće QoSg metrike: kašnjenje od korisnika do
korisnika UUD (engl. User to User Delay), kašnjenje procesiranja PD (engl. Processing
Delay) i kašnjenje odgovora RpD (engl. Response Delay). Autori su u okviru svog rada
također definisali i metriku uspješnosti transakcije SR (engl. Success Rate).
A. Brajdić, M. Sužnjević i M. Matijašević su u okviru svog rada [33] omogućili uvid u
proces dobivanja i interpretiranja metrika za procjenu performansi SIP protokola.
Analizirana su četiri tipa metrika SRD, SNT (engl. Session Negotiation Time), SDT, SDD.
Metrike SRD, SDT i SDD su opisane u [25]. Nova definisana metrika, vrijeme za
pregovaranje sesije SNT, predstavlja vrijeme koje protekne između SIP INVITE zahtjeva,
koji inicira procedure pregovaranja, i odgovarajućeg 200 OK odgovora. Metrike
predložene u [25] nisu dovoljne za opisivanje signalizacije koja se odvija za vrijeme
trajanja sesije. Kako bi se precizno procijenio novi proces pregovaranja, koji se koristi za
ažuriranje parametara sesije na oba kraja komunikacije, definisana je SIP metrika pod
40
nazivom kašnjenje ponovnog pregovaranja SNRT (engl. Session Renegotiation Delay).
Metrika SNRT se obično koristi za opisivanje ponovnog procesa pregovaranja koji se
obično inicira slanjem SIP UPDATE ili re-INVITE poruke i terminira se odgovarajućom
200 OK porukom odgovora [33].
H. Fathi, S. Chakraborty i R. Prasad u okviru svog rada [34] su naveli kašnjenje uspostave
sesije SSD (engl. Session Setup Delay) kao najvažniju signalizacijsku metriku. Prilikom
procjenjivanja kvaliteta usluge QoS, uzima se u obzir nekoliko različitih kašnjenja
signalizacijskih procedura: kašnjenje ponovnog biranja PDD (engl. Post-Dial Delay),
kašnjenje prilikom biranja brojeva do prvog „zvonjenja“ DRD (engl. Dial-to-Ring Delay),
kašnjenje prilikom ponovnog „podizanja“ slušalice PPD (engl. Post-Pickup Delay). Autori
su u okviru svog rada definisali SSD kao vremenski interval od trenutka kada je UAC
(engl. User Agent Client) aktivirao iniciranje sesije slanjem SIP INVITE poruke, do
trenutka kada on dobije alarmirajuću poruku („ton zvonjenja“). Ovo vrijeme u prosjeku
iznosi oko 8.5 [s] [34].
A. Alfallah i H. Alkaabey su u okviru svoje master teze [35] ispitivali uticaj veličine
paketa (UDP protokol) na vrijednost PDD-a. Utvrdili su da se za veće vrijednosti veličine
paketa dobiva veća vrijednost PDD metrike. Autori su također izvršili analizu uticaja broja
simultanih poziva na vrijednost PDD metrike. Simulacija je izvršena korištenjem ns-2
(engl. Network Simulator 2) simulatora.
Sl. 4.3 Vrijednosti PDD metrike mjerene pri različitom broju simultanih poziva [35]
41
Generalno, mjerenje uticaja performansi signalizacijskog sistema na QoE-a nije još uvijek
dovoljno istraženo. J. Mongay Batalla, J. Śliwi ński, H. Tarasiuk, i W. Burakowski su u
svom radu [36] ispitivali signalizacijske performanse sistema mreža nove generacije
EuQoS. Razmatrane su glavne procedure u signalizacijskom sistemu kao što je upravljanje
pozivom i prenos signalizacijskih poruka kroz mrežu. Oba ova faktora utiču na vrijednost
kašnjenja uspostave poziva, a tim i posljedično na kvalitet korisničkog iskustva QoE [36].
M. Voznak i J. Rozhon su u svom radu [37] izvršili seriju testova na različitim
platformama korištenjem predložene metodologije za testiranje i vrednovanje SIP
infrastrukture. Usvajanjem RFC 6076 preporuke, konačno su standardizirani najbitniji
parametri za mjerenje. Korištenjem ovih standardiziranih parametara, autori su razvili
sljedeće testne scenarije: registracijski testni scenario i scenario uspostave poziva. Svaki od
ovih scenarija omogućava drugačiji pristup za definisanje ograničenja SIP servera.
Navedeni testni scenariji se mogu koristiti odvojeno, bilo za testiranje posebnih okruženja
ili događaja, ili za simuliranje ponašanja stvarnog VoIP klijenta. U radu su predstavljeni
rezultati testiranja sprovedeni na dvije najčešće korištene platforme za VoIP, Asterisk PBX
(engl. Private Branch Exchange) i Opensips. Testiranje se fokusira na ispitivanju
mogućnosti platformi da obrađuju višestruke, simultane registracijske zahtjeve koji dolaze
u uzastopnim burst-ovima. Ovaj primjer je posebno važan za određivanje načina
reagovanja SIP servera u slučaju kvarova na mreži ili situacije u kojoj se svi klijenti
pokušavaju registrovati u isto vrijeme. Način na koji SIP server odgovara na burst-ove
(koji nose veliko opterećenje) se može odrediti i svi zaključci se izvode analiziranjem
prikupljenih informacija dobivenih iz mjerenja obavljenih na strani klijenta. Mjerenja na
strani servera nisu moguća zbog ograničenja koja postavljaju pružatelji usluga.
Administratori u svrhu analiziranja performansi VoIP infrastrukture mogu koristiti vlastita
rješenja (hardverska ili softverska) ili open-source testne alate. Vlastita rješenja
predstavljaju dobar izbor jer nude razumljive scenarije testiranja. Rezultati dobiveni
primjenom ovog tipa testiranja su veoma razumljivi. Međutim, ova rješenja zahtijevaju
korištenje specijalno dizajniranih hardvera koji se sastoje od specijalnih komponenti kao
što su brzi procesori za digitalnu obradu signala itd. Hardveri sa ovim komponentama su
veoma skupi, također svaki proizvođač koristi vlastitu metodologiju, što rezultira time da
su izlazni rezultati od različitih proizvođača nekompatibilni i ne mogu se porediti. S druge
strane, open-source testni alati omogućavaju korisniku da izabere šta želi da mjeri i kako
želi da sprovede željeno mjerenje.
42
Autori su u svom radu za mjerenja pored parametara definiranih u preporuci RFC 6076,
koristili i parametre specificirane za hardver. Kompletna lista mjerenih parametara
uključuje: iskorištenost procesora, iskorištenost memorije, broj (ne)uspješnih poziva, RRD,
SRD, srednju vrijednost jitter-a i maksimalno kašnjenje RTP paketa.
Za potrebe izvođenja testiranja, simulirana su oba kraja SIP dijaloga kako bi se mogao
testirati glavni dio SIP infrastrukture odnosno SIP server. Ovaj server predstavlja skup
servera koji uvijek uključuje registracijski server (engl. SIP Registrar) i posrednički server
(engl. SIP Proxy) ili B2BUA (engl. Back-to-Back User Agent) server. Pozivi se generišu
korištenjem SIPp testnog alata u ulozi UAC. Ovaj alat se koristi za testiranje i B2BUA i
SIP proxy-a. Slika 4.4 prikazuje SIP poruke i dijaloge na način kako su definirani u XML
(engl. Extensible Markup Language) scenariju za testiranje SIP proxy servera.
Sl. 4.4 Razmjena poruka prilikom testiranja SIP proxy servera [37]
U osnovnoj konfiguraciji SIP proxy servera moguće je mjeriti samo SIP parametre
iskorištenosti, budući da RTP tok ne prolazi kroz SIP proxy samim tim i ne predstavlja
opterećenje za njega. Jedini izlazni rezultati izvršenih mjerenja su sirovi podaci koji
opisuju sposobnost SIP proxy-ja da se nosi sa povećanjem broja poziva generisanih u
43
sekundi. Međutim, sve verzije SER (engl. SIP Express Router) arhitekture dozvoljavaju
korisniku da postavi određen broj podprocesa zaduženih za osluškivanje. Na slikama 4.5 i
4.6 prikazani su rezultati koje su autori dobili za RRD i SRD prilikom testiranja SIP proxy
servera.
Sl. 4.5 RRD i SRD kašnjenja za SIP Proxy sa četiri UDP slušatelja [38]
Sl. 4.6 RRD i SRD kašnjenja za SIP Proxy sa šesnaest UDP slušatelja [38]
44
Sa slike 4.6 se vidi da povećavanje broja generisanih poziva ima negativan uticaj na
ukupne performanse SIP proxy servera. Kašnjenja RRD i SRD su 2 do 3 puta veća kada je
broj UDP slušalaca postavljen na 16.
M. Kulin, T. Kazaz i S. Mrdović u svom radu [39] mjere performanse VoIP sistema sa
sigurnom SIP signalizacijom u odnosu na performanse VoIP sistema sa običnom SIP
signalizacijom. U radu se poredi SIP sa omogućenom autentikacijom preko tri transportna
protokola: UDP, TCP, i TLS (engl. Transport Layer Security). Mjerene su sljedeće
vrijednosti: vršna propusnost konkurentnih poziva, kašnjenje zahtjeva za registraciju RRD,
kašnjenje zahtjeva za uspostavu sesije SRD, iskorištenost procesora i iskorištenost
memorije. Mjerenje je vršeno u testnom okruženju koje se sastoji od Asterisk PBX (engl.
Private Branch Exchange) platforme, nekoliko SIP korisničkih agenata i SIPp generatora
saobraćaja. Ovdje će se prikazati samo rezultati koje su autori dobili prilikom mjerenja
RRD-a i SRD-a. Slika 4.7 prikazuje MSC (engl. Message Sequence Chart) dijagram za
testiranje XML scenarija korištenog za mjerenje navedenih metrika.
Sl. 4.7 MSC dijagram za testiranje XML scenarija [39]
45
Metrika RRD predstavlja mjerenje kašnjenja u odgovoru na UA REGISTER zahtjev.
Metrika SRD predstavlja vremenski interval od trenutka kada izvorišni agent pošalje prvi
bit inicijalne INVITE poruke do trenutka kada on primi posljednji bit prvog privremenog
odgovora (180 Ringing). Navedene metrike su mjerene u skladu sa načinom na koji su
definisane u RFC 6076 dokumentu, i u različitim uslovima. Različiti uslovi
podrazumijevaju različito opterećenje (izraženo u vidu konkurentnih poziva) koje se
generiše korištenjem SIPp generatora saobraćaja. U zavisnosti od korištenog transportnog
protokola preko kojeg je uspostavljena SIP signalizacija, svaki prikazani grafik ima tri
odgovarajuće karakteristične krivulje. Slike 4.8 i 4.9 prikazuju RRD i SRD, respektivno.
Sl. 4.8 Vrijednosti RRD-a mjerene pri različitom broju konkurentnih poziva [39]
Sl. 4.9 Vrijednosti SRD-a mjerene pri različitom broju konkurentnih poziva [39]
Sa slika 4.8 i 4.9 se primjećuje da TLS i TCP sa stajališta RRD-a i SRD-a imaju lošije
performanse od UDP-a zbog vremena potrebnog za uspostavljanje konekcije. Ovi rezultati
se trebaju posmatrati relativno, zato što SIPp-u treba dodatno vrijeme da kreira statistike
46
poziva. Bolji način za prikupljanje relevantnih podataka je snimanje saobraćaja
korištenjem mrežnog analizatora protokola.
4.3. Sažetak
Četvrto poglavlje je podijeljeno u dva dijela. Prvi dio daje pregled literature koja opisuje
faktore koji utiču na QoE. Drugi dio opisuje uticaj signalizacijskih procedura i
signalizacijskog opterećenja na QoE. Cilj ovog poglavlja je da se pokušaju sistematizirati
dosadašnja istraživanja vezana za faktore koji utiču na QoE, sa posebnim naglaskom na
signalizacijsko opterećenje. Budući da je većina istraživačkih radova usmjerena na
mjerenje QoE sa aspekta uticaja mrežnih parametara (u smislu QoS-a), veoma mali broj
istraživačkih radova obrađuje tematiku uticaja signalizacijskog opterećenja na QoE. U
posljednjem dijelu prikazani su rezultati za RRD i SRD kašnjenja mjerena prilikom
testiranja SIP Proxy servera na Opensips i Asterisk platformama.
47
5. Model rješenja za unapre đenje UCT IMS
klijentske aplikacije
Klijent UCT IMS je dizajniran za korištenje u kombinaciji sa Fraunhofer FOKUS Open
IMS Core platformom. Razvijen je u okviru istraživačke grupe Communication Research
Group na Univerzitetu Cape Town u Južnoj Africi. Klijent je razvijen kao besplatna open-
source implementacija 3GPP IMS klijenta, koja se može veoma jednostavno instalirati,
upravljati i mijenjati. Projekat je započeo s ciljem stvaranja fleksibilnog i proširivog koda,
koji će poslužiti kao osnova brojnim istraživačkim i industrijskim stručnjacima da koriste
komunikacijske usluge omogućene pomoću IMS-a [40]. U ovom dijelu će se opisati
postojeće funkcionalnosti UCT IMS klijentske aplikacije i implementacija proširenih
funkcionalnosti.
5.1. Opis postoje ćih funkcionalnosti UCT IMS klijentske
aplikacije
Cilj projekta pod nazivom UCT IMS klijent je da se razvije softver koji je besplatan, kako
u smislu troškova tako i u smislu samog softvera, a koji se može jednostavno instalirati,
upravljati i modificirati od strane istraživača koji žele naučiti više o IMS-u. Korištenje
Linux operativnog sistema i njegovih brojnih dostupnih biblioteka predstavlja logičan
izbor za pokretanje UCT IMS klijentske aplikacije, budući da se sama aplikacija ne može
jednostavno pokrenuti na Windows okruženju i na trenutnim generacijama mobilnih
uređaja. Međutim, ovo ne predstavlja ograničenja za primarnu svrhu UCT IMS klijentske
aplikacije kao alata za testiranje i istraživanje [41].
Za obavljanje različitih funkcionalnosti, UCT IMS klijent koristi nekoliko IETF protokola
kao što su SIP, RTP, XCAP (engl. XML Configuration Access Protocol), MSRP (engl.
Message Session Relay Protocol) i RTSP (engl. Real Time Streaming Protocol) protokol.
Klijent podržava AKA (engl. Authentication and Key Agreement) provjeru autentičnosti, i
pokušava oponašati IMS signalizaciju na što bolji mogući način. Trenutna verzija podržava
sljedeće funkcionalnosti [41]:
48
• Govorne i video sesije – klijent može obavljati govorne i video pozive sa drugim
IMS klijentom tek nakon što se registruje na svoju domaću mrežu. Klijent izdvaja
putanju usluge iz registracijskog procesa i usmjerava poziv na S-CSCF koji se
nalazi u kućnoj mreži. Nakon toga, poziv se usmjerava na odgovarajuću
destinaciju. Klijent podržava µ-law, A-law, GSM (engl. Global System for Mobile
Communications) i MP2 (engl. Moving Picture Experts Group audio layer II) audio
kodek i H.263 video kodek. Moguće je pregovaranje o parametrima medija za
vrijeme trajanja sesije. Naime, korisnik jednostavno odabere željenu vrstu kodeka,
brzinu prenosa, i ponovo šalje zahtjev (re-INVITE) za uspostavu sesije;
• Presence – klijent podržava SIMPLE (engl. SIP for Instant Messaging and
Presence Leveraging Extensions), gdje se SIP mehanizmi pretplate koriste za
pretplatu na status prisutnosti (engl. presence status) drugog korisnika. Kada se
klijent pretplati na događaj korisničke prisutnosti, on dobiva obavještenja prilikom
svake promjene statusa korisnika. Omogućeno je također dobivanje notifikacija o
prisutnosti drugih korisnika;
• Instant Messaging – klijent omogućava dvije vrste IM (engl. Instant Messaging)
koje su trenutno podržane u IMS mrežama, a to su IM u pager modu i IM u
sesijskom modu. Poruke u pager modu se prenose u okviru tijela SIP poruka, a
poruke u sesijskom modu se prenose preko medijske ravni. Ovo je razvijeno na
sličan način kao što IMS razdvaja signalizacijske i medijske (audio, video) sesije.
• Streaming video sadržaja i video na zahtjev VoD (engl. Video on Demand) – klijent
podržava dva moda jednosmjernog gledanja video sadržaja. Klijent uspostavlja
sesiju sa video serverom na isti način kao sa drugim IMS klijentom, dakle slanjem
SIP INVITE poruke. Prilikom uspostavljanja sesije vrši se pregovaranje o
parametrima medija kao što je tip korištenog kodeka itd. Alternativno, klijent može
uspostaviti sesiju korištenjem RTSP protokola. Ovo predstavlja dodatnu
funkcionalnost koja se uglavnom primjenjuje za VoD aplikacije koje omogućavaju
korisnicima da upravljaju dolaznim video sadržajem (pauziranje, ponovna
reprodukcija itd.).
49
5.2. Opis vlastitog rješenja
5.2.1. Neformalni opis
Cilj ovog rada je proširiti UCT IMS klijentsku aplikaciju tako da ima mogućnost
izvještavanja o subjektivnim i objektivnim metrikama kvalitete korisničkog iskustva.
Ocjenjivanje zadovoljstva korisnika je bazirano na dvjema funkcionalnostima koje su
implementirane u okviru jednog pop-up prozora koji se aktivira nakon što se poziv završi.
Prva funkcionalnost je implementirana na način da se korisniku postavi pitanje da li je
zadovoljan kvalitetom obavljenog razgovora. Korisnik ima mogućnost da odgovori sa
“Da” ili “Ne”. Druga funkcionalnost je implementirana na način da će korisnik moći
ocijeniti kvalitet korištene usluge vrijednostima od 1 do 5. Ovi podaci će se upisivati u
određene tabele unutar glavne baze podataka.
Proširenje za izvještavanje o objektivnim metrikama kvalitete korisničkog iskustava je
jednostavno implementirano pomoću modifikacije izvornog koda UCT klijenta. Izvorni
kod UCT klijenta je napisan u C programskom jeziku a njegova modifikacija je izvršena
korištenjem Sublime Text 2.0.2 tekstualnog editora. Kompajliranje modificiranog koda je
urađeno korištenjem komande make koja se unosi u terminal Ubuntu Linux 10.04 LTS
operativnog sistema. U cilju realizacije ovog proširenja potrebno je implementirati
računanje sljedećih metrika performansi SIP signalizacije: kašnjenje zahtjeva za
registraciju RRD, kašnjenje zahtjeva za uspostavu sesije SRD i kašnjenje prekida sesije
SDD. Vrijednosti dobivene računanjem ovih metrika će se unositi u istoimene tabele u
okviru kreirane baze podataka.
Dodatno, da bi se izmjerene vrijednosti pojedinih metrika mogle koristiti u svrhu
statističke analize, UCT klijentska aplikacija će se proširiti modulom koji omogućava
unošenje informacija o spolu i dobnoj skupini korisnika koji je trenutno aktivan na
aplikaciji. Ova informacija je veoma korisna kako bi se ustanovio način na koji određene
skupine ljudske populacije percipiraju kvalitetu određene usluge. Informacija o dobnoj
skupini klasificirana je u pet kategorija: 14 godina ili manje, 15 – 18 godina, 19 – 23
godine, 24 – 40 godina i 41 godina ili više. Ove informacije će se unositi u tabelu user
unutar baze podataka.
50
5.2.2. Formalni opis
Formalni opis vlastitog rješenja će se uraditi uz pomoć Use Case dijagrama. U okviru ovog
dijagrama će se prikazati implementirane funkcionalnosti na UCT IMS klijentskoj
aplikaciji. Dijagram se sastoji od korisničkih funkcionalnosti koje se odnose na uspostavu,
odbijanje i prekid audio ili video poziva. Dodatno, pored ovih prikazane su i
funkcionalnosti koje se odnose na ocjenjivanje kvalitete korisničkog iskustva QoE. Budući
da se samo računanje RRD, SRD i SDD kašnjenja obavlja unutar same aplikacije, te da
korisnik nema uticaja na te vrijednosti, dodata su tri dodatna slučaja korištenja koja
naglašavaju mjesta gdje se računaju RRD, SRD i SDD metrika sa aspekta odvijanja
signalizacijskih procedura prilikom uspostave VoIP poziva. Slika 5.1 prikazuje kreirani
Use case dijagram u okviru kojeg je prikazana interakcija između korisnika i same UCT
IMS klijentske aplikacije.
Sl. 5.1 Use case dijagram
U nastavku će se detaljno opisati implementacija potrebnih funkcionalnosti na UCT
klijentskoj aplikaciji.
51
5.3. Implementacija željenih proširenja na UCT IMS
klijentskoj aplikaciji
U ovom podpoglavlju će se detaljno opisati implementacija odgovarajućih funkcionalnosti
IMS klijentske aplikacije koje su opisane u prethodnom dijelu. Budući da je sve vrijednosti
dobivene realizacijom navedenih funkcionalnosti potrebno unositi u određene tabele u
okviru baze podataka u nastavku je opisan način kreiranja i rada MySQL baze podataka.
5.3.1. MySQL baze podataka
Da bi uopšte radili sa MySQL bazama podataka potrebno se logirati kao MySQL root
korisnik. Slika 5.2 prikazuje jednostavno logiranje na MySQL bazu kroz terminal.
Prilikom logiranja potrebno je unijeti odgovarajući password (u ovom slučaju password je
“root”). U tom slučaju mijenja se početak ispisa u terminal (on je sada mysql>).
Sl. 5.2 Logiranje kao mysql root korisnik i odgovarajući ispis
Prvo je potrebno kreirati osnovnu bazu podataka pod nazivom qoe_database . Za
kreiranje se koristi jednostavna komanda “CREATE DATABASE qoe_database”. U ovoj
bazi će se nalaziti odgovarajuće tabele unutar kojih će se pohranjivati relevantni podaci.
Nakon kreiranja baze podataka moguće je odmah provjeriti da li je određena baza uspješno
52
kreirana. Ukoliko je baza podataka uspješno kreirana prikazat će se zajedno sa svim
ostalim bazama podataka koje već postoje. Slika 5.3 prikazuje postojeće baze podataka,
kao i kreiranu bazu podataka pod nazivom qoe_database .
Sl. 5.3 Prikaz kreiranih baza podataka
Za kreiranje potrebnih tabela unutar baze podataka korišten je mysl-workbench alat. Ovaj
alat omogućava jednostavno kreiranje i modificiranje baza podataka. Iz praktičnih razloga
qoe_database baza je realizirana u vidu šest tabela, a to su: user , rating , mos,
srd , sdd i rdd . U ove tabele će se unositi podaci dobiveni realizacijom potrebnih
funkcionalnosti. Iz praktičnih razloga u nastavku će se prikazati samo dio koda za
realizaciju jedne od navedenih tabela.
Programski kod 1. Kreiranje tabele user unutar qoe_database baze podataka
CREATE TABLE IF NOT EXISTS `qoe_database`.`user` ( `iduser` INT NULL AUTO_INCREMENT , `username` VARCHAR(45) NULL , `age` INT NULL , `gender` INT NULL , PRIMARY KEY (`iduser`) ) ENGINE = InnoDB;
53
Kreirana tabela ima četiri kolone. U prvu kolonu 'iduser ' se unosi identifikacijski broj
korisnika (cjelobrojna vrijednost, INT), koji se automatski povećava za jedan prilikom
registracije novog korisnika. U drugoj koloni 'username ' nalaze se imena registrovanih
korisnika (VARCHAR tip podataka, maksimalna vrijednost 45). U ovom slučaju to su
[email protected], [email protected], [email protected] i [email protected]. U
treću i četvrtu kolonu ('age ' i 'gender ') se unose podaci o dobnoj skupini i spolu
korisnika koji je trenutno aktivan na aplikaciji. Vrijednosti koje se unose u ove tabele su
cjelobrojne vrijednosti (INT), ženskom spolu se dodjeljuje vrijednost 0 a muskom spolu
vrijednost 1 prilikom unosa u bazu podataka. Cijelobrojne vrijednosti koje se dodjeljuju za
odabranu kategoriju godina su sljedeće: 0 (14 godina ili manje), 1 (15 – 18 godina), 2 (19 –
23 godine), 3 (24 – 40 godina) i 4 (41 godina ili više). U tabeli user nalazi se jedan
primarni ključ, a to je iduser . Ovaj ključ služi za povezivanje sa ostalim kreiranim
tabelama. Slika 5.4 prikazuje sadržaj tabele user .
Sl. 5.4 Prikaz sadržaja tabele user u qoe_database bazi podataka
5.3.2. Programski kod
U ovom podpoglavlju će se prikazati programski kodovi za realizaciju potrebnih
funkcionalnosti UCT klijentske aplikacije. Prvi zadatak koji je potrebno riješiti jeste
54
dodavanje novog modula sa nazivom QoE. U nastavku je ukratko opisan način na koji je
implementiran QoE modul. Naime, u izvornom kodu UCT klijenta nalazi se osnovna
main.c datoteka. U okviru ove datoteke se nalaze dvije funkcije zadužene za kreiranje i
prikazivanje grafičkog korisničkog interface-a GUI-a (engl. Graphical User Interface)
UCT klijenta.
Programski kod 2. Funkcije za kreiranje i prikazivanje GUI-a UCT IMS klijenta
imsUA = create_imsUA (); /* funkcija za kreiranje GUI- a UCT klijenta */ gtk_widget_show (imsUA); /* funkcija za prikazi vanje GUI- a UCT klijenta */
Kako bi dodali QoE modul, potrebno je modificirati osnovni GUI UCT klijenta.
Implementacija modula QoE je realizovana u okviru datoteke interface.c . Za
dodavanje QoE modula se koriste "horizontalne kutije" hboxqoe . Cijeli modul je
podijeljen u četiri horizontalne kutije, u okviru ovih kutija definisana su četiri okvira
(user_rating ) za upisivanje podataka karakterističnih za QoE. U prvoj horizontalnoj
kutiji se nalaze dva okvira unutar kojih se upisuju podaci o tome da li je korisnik
zadovoljan uslugom ili ne, dalje upisuje se MOS ocjena kojom je korisnik ocijenio uslugu,
i prosječne vrijednosti za sve navedene slučajeve. Nakon definiranih okvira pod nazivom
'Your ratings' i 'Average ratings' tek se dodaje naziv prve horizontalne kutije 'User ratings'.
U okviru druge horizontalne kutije također su definisana dva okvira za prikazivanje
prosječnih vrijednosti za datog korisnika i prosječnih vrijednosti za sve korisnike pod
nazivom 'Your ratings' i 'Average ratings'. Na kraju je dodat naziv druge horizontalne
kutije 'SIP metric'. U okviru treće horizontalne kutije implementiran je dodatni button 'Get
Data'. Pritiskom na ovaj button preuzimaju se podaci iz odgovarajućih tabela unutar
qoe_database baze podataka i zatim se ispisuju u odgovarajuća polja u okviru
horizontalnih kutija. U okviru četvrte horizontalne kutije implementiran je button 'Write
Data'. Pritiskom na ovaj button ispisuju se podaci iz qoe_database baze podataka za
korisnika koji je trenutno registrovan u odgovarajuće tekstualne datoteke. Na kraju je
dodata nova labela za upisivanje naziva modula QoE. Detaljna implementacija koda za
dodavanje modula QoE nalazi se u Prilogu E Programski kodovi pod nazivom kreiranje
modula QoE.
55
U okviru datoteke interface.c također je dodata funkcija g_signal_connect ()
koja kada se pritisne na button Get Data poziva funkciju on_get_data_clicked ()
koja služi za povezivanje na bazu qoe_database i preuzimanje podataka iz nje.
Prototip funkcije on_get_data clicked () se nalazi u callbacks.h datoteci a
njena implementacija se nalazi u callbacks.c datoteci. Dalje, u interface.c
datoteci je pomoću GLADE_HOOKUP_OBJECT () funkcije omogućeno da se sve labele
dodate u okviru QoE modula posmatraju kao globalne varijable, što omogućava da im se
može pristupiti sa bilo kojeg mjesta u kodu.
Radi lakšeg pristupanja podacima unutar kreirane baze podataka napravljena je XML
datoteka pod nazivom database.xml koja služi da se pokupi konfiguracija kreirane
baze podataka i koja omogućava jednostavno povezivanje na qoe_database bazu
podataka. U okviru ove datoteke nalaze se četiri parametra a to su adresa baze podataka,
naziv, username i password.
Programski kod 3. Kreiranje XML datoteke database.xml
<?xml version="1.0"?> <database_connection> <database-url>127.0.0.1</database-url> <database>qoe_database</database> <database-username>root</database-username> <database-password>root</database-password> </database_connection>
Detaljna implementacija funkcije on_get_data_clicked () se nalazi u datoteci
callbacks.c. Dakle, ova funkcija služi za preuzimanje podataka iz qoe_database
baze podataka kada se pritisne na button Get Data u okviru modula QoE ili prilikom
pritiska na button Write Data.
U cilju omogućavanja ocjenjivanja kvaliteta usluge subjektivno percipirane od strane
krajnjeg korisnika, potrebno je napraviti poseban grafički interfejs koji će omogućiti
korisniku da ocjeni konzumiranu uslugu ocjenom od 1 do 5, dodatno u okviru ovog
interface-a je ponuđena opcija da korisnik može generalno ocijeniti da li je zadovoljan
konzumiranom uslugom jednostavnim odgovorom "Da" ili "Ne" na pitanje "Da li ste
zadovoljni kvalitetom razgovora". Ovaj grafički interface je realizovan u vidu pop-up
prozora koji se pojavljuje nakon sto korisnik prekine uspostavljeni poziv. Podaci o
56
ocjenama se unose u bazu podataka qoe_database . Dalje, u okviru ovog prozora je
ostavljena mogućnost da korisnik uopšte ne ocjeni konzumiranu uslugu, u tom slučaju
vrijednosti u ovom prozoru po default-u ostaju na vrijednosti N/A. Već prethodno je
rečeno da je baza podataka qoe_database realizirana u vidu 6 tabela. Ocjene od 1 do 5
unose se u tabelu 'mos', dok vrijednosti o tome da li je korisnik zadovoljan uslugom ili ne
unose u tabelu 'rating ', pri čemu je odgovoru „Ne“ dodjeljena vrijednost 0, a odgovoru
„Da“ vrijednost 1. Iako se ova ocjenjivanja vrše u okviru istog pop-up prozora, rezultujuće
vrijednosti se unose u različite tabele u okviru baze podataka, razlog je to što korisnik
može da na pitanje da li je zadovoljan kvalitetom razgovora odgovori npr. sa „Da“, a da pri
tome ne izabere ocjenu za datu uslugu. Button-i za odgovore i ocjene su implementirani u
vidu radio button-a. Implementacija grafičkog inteface-a za subjektivno ocjenjivanje
kvaliteta korisničkog iskustva se nalazi u interface.c datoteci. Detaljna
implementacija grafičkog interface-a za subjektivno ocjenjivanje kvaliteta razgovora nalazi
se u Prilogu E Programski kodovi pod nazivom Implementacija GUI-a za subjektivno
ocjenjivanje kvaliteta usluge.
Kako bi omogućili mjerenje objektivnih metrika za ocjenjivanje kvalitete korisničkog
iskustva potrebno je omogućiti računanje kašnjenja zahtjeva za registraciju RRD, kašnjenja
zahtjeva za uspostavu sesije SRD i kašnjenja prekida sesije SDD. Kašnjenje zahtjeva za
registraciju se definiše kao vremenski interval od trenutka slanja prvog bita REGISTER
poruke do trenutka prijema posljednjeg bita 200 OK poruke odgovora na poslati
REGISTER zahtjev. Dakle, za računanje vrijednosti ove metrike potrebno je prvo u
izvornom kodu pronaći sistemsko vrijeme slanja REGISTER poruke. Programski kod 4
prikazuje slanje REGISTER poruke i funkciju koja preuzima to vrijeme i pohranjuje ga u
varijablu start_time .
Programski kod 4. Slanje SIP INVITE poruke i preuzimanje sistemskog vremena
slanja SIP INVITE poruke
/* send register message */
eXosip_lock();
if (eXosip_register_send_register (reg_id, reg) != 0)
{
set_display("Error sending registration");
57
eXosip_unlock ();
return -1;
}
eXosip_unlock ();
// start timer for delay tests
gettimeofday(&start_time, NULL);
sprintf(display, "REGISTER sent to\n%s",pref->pcsc f);
set_display(display);
imsua_set_message_display("REGISTER", 1);
Nakon preuzimanja sistemskog vremena slanja REGISTER poruke potrebno je zabilježiti
trenutak prijema 200 OK poruke na poslati REGISTER zahtjev i pohraniti tu vrijednost u
varijablu end_time . Programski kod 5 prikazuje preuzimanje vremena prijema 200 OK
poruke, njegovo pohranjivanje u varijablu end_time kao i funkciju koja računa razliku
vremena slanja REGISTER poruke i prijema 200 OK poruke i pohranjuje tu vrijednost u
varijablu result . Dalje, ova vrijednost se upisuje u rrd tabelu pozivanjem funkcije
insert_into_rrd () čija se implementacija nalazi u useful_methods.c
datoteci.
Programski kod 5. Računanje RRD metrike
void ims_process_registration_200ok(eXosip_event_t *je)
{
int i;
gettimeofday(&end_time, NULL);
struct timeval result;
timeval_subtract(&result, &end_time, &start_time);
sprintf(display, "Registered with %s",pref->realm) ;
set_display(display);
imsua_append_text_to_display(display);
insert_into_rrd(result);
Analogno kako bi se izračunala vrijednost SRD metrike potrebno je u kodu naći sistemsko
vrijeme slanja SIP INVITE poruke i vrijeme prijema poruke indikativnog odgovora.
Razlika ovih kašnjenja definiše SRD metriku. Za SDD metriku potrebno je pronaći vrijeme
58
slanja BYE poruke i vrijeme prijema 200 OK poruke. Razlika ovih vremena predstavlja
SDD metriku.
U datoteci ims_interface_event_handler.c implementirana je funkcija
ims_call_initiate () . Programski kod 6 prikazuje slanje INVITE poruka kao i
funkcija koja preuzima sistemsko vrijeme slanja INVITE poruke i pohranjuje ga u
varijablu start_time .
Programski kod 6. Slanje SIP INVITE poruke i preuzimanje sistemskog vremena
slanja SIP INVITE poruke
/* send the invite */ eXosip_lock (); int i = eXosip_call_send_initial_invite (invite); eXosip_unlock (); // start timer for delay tests gettimeofday(&start_time, NULL); if (i == 0) set_display("Error sending IMS invite"); else { sprintf(display, "Sent IMS INVITE to\n%s", uri_en try); set_display(display); imsua_set_message_display("INVITE", 1); }
Funkcija gint get_exosip_events() je implementirana u imsUA.c datoteci. Ova
funkcija se poziva svaki put kada se pošalje neka poruka. Dakle, ovom funkcijom se prvo
provjerava da li je poslana neka poruka, ukoliko jeste onda se pristupa njenom
procesiranju.
Programski kod 7. Implementacija funkcije gint get_exosip_events()
gint get_exosip_events(gpointer main_window) { eXosip_event_t *je; char display[500] = ""; eXosip_lock(); eXosip_unlock(); /* Check for eXosip event - timeout after 50ms */ if((je = eXosip_event_wait(0,50)) != NULL) { imsua_display_event_info(je); if (je->type == EXOSIP_CALL_INVITE) { ims_process_incoming_invite(je);
59
} else if (je->type == EXOSIP_CALL_REINVITE) { ims_process_incoming_reinvite(je); } else if (je->type == EXOSIP_CALL_RINGING) { ims_process_18x(je); }
Već je rečeno da se SRD metrika računa za uspješne i neuspješne procedure uspostave
sesije. Kod uspješne uspostave sesije metrika SRD se računa kao razlika vremena prijema
indikativnog odgovora 180 Ringing i vremena slanja INVITE poruke. U datoteci
ims_exosip_event_handler.c nalazi se dio koda koji je zadužen (ukoliko je
primljena poruka 180 Ringing) da zaustavi vremenski brojač, pohrani vrijeme prijema 180
Ringing poruke u varijablu end_time . U okviru ovog dijela programskog koda računa se
razlika vremena prijema 180 Ringing poruke i slanja INVITE poruke. Ova razlika se
pohranjuje u varijablu result , koja se dalje unosi u qoe_database bazu podataka,
konkretno u tabelu srd pomoću funkcije insert_into_srd () , koja je
implementirana u useful_methods.c datoteci.
Programski kod 8. Računanje SRD metrike u slučaju uspješnog procesiranja SIP
INVITE zahtjeva
else if (p_response->status_code == 180) { set_display("Remote Client is ringing..."); // stop timer for delay tests gettimeofday(&end_time, NULL); struct timeval result, temp_start; temp_start = start_time; timeval_subtract(&result, &end_time, &temp_start) ; sprintf(display, "\n\ nCall setup delay: %ld.%03lds", result.tv_sec, result.tv_usec/1000); /* Dodato za QoE */ insert_into_srd(result); /* Kraj dodavanja za QoE */ imsua_append_text_to_display(display); state = REMOTE_RINGING; // osip_thread_create (20000, start_ringing, NULL ); initialiseRingingPipeline(ca); }
60
Kod neuspješnog procesiranja zahtjeva, SRD metrika se računa kao vremenski interval od
trenutka slanja prvog bita inicijalne INVITE poruke do trenutka prijema posljednjeg bita
prvog privremenog odgovora ili odgovora koji indicira neuspjeh. Neuspješna uspostava
sesije je opisana prijemom poruke odgovora iz sljedećih klasa: 4xx (osim 401, 402 i 407),
5xx i 6xx. Implementacija računanja SRD-a uslijed neuspješne uspostave sesije nalazi se u
imsUA.c datoteci. Programski kod 9 prikazuje računanje SRD metrike kod neuspješnog
procesiranja INVITE zahtjeva nastalog zbog greške na klijentu.
Programski kod 9. Računanje SRD kašnjenja uslijed greške na klijentu
else if (je->type == EXOSIP_CALL_REQUESTFAILURE) { set_display("Call released"); /* Dodato za QoE */ if ((je->response)->status_code != 401 && (je->response)->status_code != 402 && (je->response)->s tatus_code != 407){ struct timeval result, temp_start,end_time; gettimeofday(&end_time, NULL); temp_start = start_time; timeval_subtract(&result, &end_time, &temp_start); insert_into_srd(result); } /* Kraj dodavanja za QoE */ }
Programski kod 10 prikazuje računanje SRD metrike uslijed pojave greške na serveru.
Programski kod 10. Računanje SRD kašnjenja uslijed greške na serveru
else if (je->type == EXOSIP_CALL_REQUESTFAILURE) { set_display("Call released"); if ((je->response)->status_code != 401 && (je->response)->status_code != 402 && (je->response)->s tatus_code != 407){ struct timeval result,temp_start,end_time; gettimeofday(&end_time, NULL); temp_start = start_time; timeval_subtract(&result, &end_time, &temp_start); insert_into_srd(result); }
61
Programski kod 11 prikazuje računanje SRD metrike uslijed neuspješne uspostave sesije i
to uslijed prijema poruke odgovora iz klase 6xx (neuspješna sesija zbog globalne greške).
Programski kod 11. Računanje SRD kašnjenja uslijed globalne greške
else if (je->type == EXOSIP_CALL_GLOBALFAILURE) { ims_process_released_call(je); printf("Message type: %d", EXOSIP_CALL_GLOBALFAILURE); /*Dodato za QoE* struct timeval result, temp_start,end_time; gettimeofday(&end_time, NULL); temp_start = start_time; timeval_subtract(&result, &end_time, &temp_start); insert_into_srd(result);
}
Analogno, za računanje SDD metrike, potrebno je u izvornom kodu naći vrijeme slanja
BYE poruke. U datoteci common_interface_event_handler.c se nalazi dio koda
u okviru kojeg je dodano da se vrijeme slanja BYE poruke pohranjuje u varijablu
start_time. Programski kod 12 prikazuje preuzimanje sistemskog vremena slanja
BYE poruke i njegovo pohranjivanje u varijablu start_time.
Programski kod 12. Preuzimanje sistemskog vremena slanja BYE poruke i njegovo
pohranjivanje
else{ imsua_set_message_display("BYE", 1); /** * Dodato za QoE */ gettimeofday(&start_time, NULL); /* Kraj dodavanja za QoE*/ }
Poslije ovoga, ponovo se u funkciji gint get_exosip_events() provjerava koja je
poruka poslana, ukoliko je poslana BYE poruka, kreiran je dio koda pomoću kojeg se
preuzima sistemsko vrijeme prijema 200 OK poruke, zatim se računa razlika između
vremena slanja BYE i vremena prijema 200 OK poruke, ta razlika dalje se upisuje u
62
varijablu result , a onda u tabelu sdd u okviru qoe_database baze podataka
korištenjem funkcije insert_into_sdd ( ). Ove funkcionalnosti su opisane u tabeli
Programski kod 13.
Programski kod 13. Računanje SDD metrike
else if (je->type == EXOSIP_CALL_MESSAGE_ANSWERED) { if (MSG_IS_BYE(je->req uest)){ if(!strcmp(osip_message_get_reason_phrase(je->response),"OK")){ struct timeval result, temp_start,end_time; gettimeofday(&end_time, NULL); temp_start = start_time; timeval_subtract(&result, &end_time, &temp_start); insert_into_sdd(result); } ims_process_released_call(je); } else if (MSG_IS_UPDATE(je->request) || MSG_IS_PR ACK(je->request)) ims_process_2xx(je); }
Poslije prijema 200 OK poruke, oslobađa se poziv pomoću funkcije
ims_process_released_call() , koja je implementirana u
ims_exosip_event_handler.c datoteci. Nakon oslobađanja poziva pojavljuje se
kreirani grafički interface za ocjenjivanje kvaliteta usluge subjektivno percipirane od
strane krajnjeg korisnika.
Nakon što je implementirano proširenje UCT klijentske aplikacije koje omogućava
izvještavanje o objektivnim i subjektivnim metrikama kvalitete korisničkog iskustva,
potrebno je implementirati modul u okviru GUI-a UCT klijenta koji će omogućiti unošenje
informacija o spolu i dobnoj skupini korisnika koji je trenutno aktivan na aplikaciji. U ovu
svrhu je u interface.c datoteci u funkciji create_preferences() implementiran
dio koji omogućava unošenje informacija o spolu i dobnoj skupini korisnika. Također je u
preferences.c i preferences.h datotekama dodana nova funkcija
preferences_get_age_preferences_from_xml_file() . Ova funkcija
učitava podatke iz xml datoteke age.xml koja je kreirana u uctimsclient folderu
63
kako bi se u njoj čuvale informacije o spolu i godinama korisnika koji je trenutno aktivan
na aplikaciji, i ona se poziva u imsUA.c datoteci. Dodatno, u preferences.c datoteci
je dodana funkcija perferences_write_age_preferences_to_xml_file() ,
a koja služi za upisivanje vrijednosti u age.xml datoteku. Znači, prilikom odabira
vrijednosti za dobnu skupinu i spol korisnika u prozoru preferences , odabrane
vrijenosti se upisuju u age.xml datoteku. U useful_methods.c je dodana funkcija
insert_into_user() koja omogućava unošenje informacija o godinama i spolu za
korisnika koji trenutno koristi aplikaciju u tabelu user u qoe_database bazi podataka.
Ova funkcija se poziva u okviru funkcije ims_send_register() kako bi se
omogućilo unošenje korisnika sa odabranim informacijama u bazu prilikom registrovanja.
Detaljna implementacija ovog modula se nalazi u prilogu E Programski kodovi pod
nazivom Implementacija modula za unošenje informacija o spolu i dobnoj skupini
korisnika.
Sa ovim je završeno opisivanje programskog koda koji je neophodan za postizanje željenih
funkcionalnosti unutar UCT IMS klijentske aplikacije.
U nastavku će se prikazati UCT klijentska aplikacija sa implementiranim dodatnim
funkcionalnostima. Slika 5.5 prikazuje izgled GUI UCT IMS klijentske aplikacije sa
implementiranim QoE modulom.
64
Sl. 5.5 Prikaz GUI-a UCT klijentske aplikacije sa dodanim QoE modulom
Slika 5.6 prikazuje uspostavu poziva između korisnika Tomy ([email protected]) i
Mary ([email protected]).
Sl. 5.6 Uspostavljen poziv između korisnika Tomy i Mary
U slučaju da jedan od korisnika prekine uspostavljeni poziv pojavljuje se pop-up prozor
prikazan na slici 5.7 koji služi da korisnik subjektivno ocjeni kvalitetu obavljenog
razgovora.
65
Sl. 5.7 GUI za ocjenjivanje kvaliteta usluge subjektivno percipirane od strane krajnjeg korisnika
Nakon ocjenjivanja konzumirane usluge, jednostavnim pritiskom na button Get Data u
okviru modula QoE, prikazuju se podaci za SRD i SDD kašnjenja i vrijednosti MOS
ocjena. Slika 5.8 prikazuje izgled GUI-a UCT klijenta nakon pritiska na button Get Data.
Pritiskom na button Write Data podaci iz odgovarajućih tabela se ispisuju u tekstualne
datoteke (.txt) koje se spremaju u folderu tmp. Slika 5.9 prikazuje tekstualnu datoteku za
korisnika Tomy u koju se upisuju vrijednosti kašnjenja zahtjeva za uspostavu sesije nakon
pritiska na button Write Data.
66
Sl. 5.8 Prikaz GUI-a UCT klijentske aplikacije sa neophodnim podacima u modulu QoE
koji su preuzeti iz qoe_database baze podataka
67
Sl. 5.9 Prikaz tekstualne datoteke u koju se pohranjuju izmjerene vrijednosti za SRD preuzete iz
baze qoe_database pritiskom na button Write Data za korisnika Tomy
Slika 5.10 prikazuje izgled prozora Preferences u okviru kojeg je omogućeno unošenje
informacija o spolu i dobnoj skupini korisnika koji trenutno koristi aplikaciju, kao i
informacija potrebnih za registraciju korisnika na IMS mrežu.
68
Sl. 5.10 Prikaz Preferences prozora za unošenje opštih podataka o korisniku
5.4. Sažetak
Peto poglavlje opisuje UCT IMS klijentsku aplikaciju, njene postojeće funkcionalnosti, te
navodi specifikaciju zahtjeva za željenim proširenjem aplikacije. U ovom poglavlju dat je
neformalni opis implementiranog rješenja (opisan tekstualno) i formalni opis za koji je
korišten use case dijagram na kome je prikazana interakcija korisnika i UCT IMS
klijentske aplikacije. Dio koji opisuje željeno proširenje klijentske aplikacije koncipiran je
na način da je prvo opisan način kreiranja i rada sa MySQL bazom podataka, budući da se
svi podaci koji se prikupljaju izvođenjem implementiranih funkcionalnosti pohranjuju u
qoe_database bazu podataka. U podpoglavlju 5.3 su opisani i prikazani bitniji dijelovi
koda zaduženi za realizaciju potrebnih funkcionalnosti. Nakon završenog opisivanja
programskog koda prikazan je GUI UCT klijenta sa dodatnim funkcionalnostima.
69
6. Opis testnog okruženja
U ovom poglavlju će se opisati okruženje za izvođenje potrebnih mjerenja. Prethodno
spomenute metrike performansi SIP signalizacije, RRD, SRD i SDD, će se mjeriti na Open
Source IMS Core testnoj platformi. Korištena platforma je razvijena u laboratoriji
Fraunhofer Instituta za otvorene komunikacijske sisteme u Berlinu, FOKUS. Prije samog
opisivanja korištene platforme i neophodnih softverskih alata potrebnih za testiranje, bitno
je spomenuti da su potrebni softverski alati instalirani na laptopu Lenovo sa sljedećim
hardverskim komponentama:
• Procesor Intel T7300 Core 2 Duo (2.0GHz, 800MHz FSB, 4MB Cache),
• Grafička kartica Intel GMA X3100,
• Hard Disk kapaciteta 100GB 7200RPM,
• RAM memorija od 2GB (1GB x 1GB), maksimalno do 4GB,
• OS Ubuntu 10.4 LTS.
Open Source IMS Core testna platforma je instalirana na Acer VERITON M6620G
računaru sa sljedećim hardverskim komponentama:
• Procesor Intel Core i5 3330/3GHz (Quad-Core),
• RAM memorija od 6GB,
• Hard disk kapaciteta 500 GB,
• Grafička kartica Intel HD Graphics 2500,
• OS Ubuntu 12.04 LTS.
Open Source IMS Core platforma je instalirana prema uputama za instalaciju koje su
preuzete sa web stranice [42]. Koraci potrebni za instaliranje Open Source IMS Core
platforme su opisani u prilogu A. Za simuliranje mrežnog opterećenja korišten je SIPp
generator koji će ukratko biti opisan u nastavku ovog rada.
70
6.1. Open Source IMS Core platforma
Open Source IMS Core je open-source implementacija IMS CSCF i HSS servera, koji
zajedno čine bazne elemente svih IMS/NGN arhitektura. Centralne komponente Open
Source IMS Core platforme su P-CSCF, I-CSCF i S-CSCF čvorovi. Ovi čvorovi su
razvijeni u FOKUS-u kao ekstenzije za SER. To je serverski softver pisan u C-u koji se
može ponašati kao SIP registrar, proxy ili redirect server. Budući da osnovne
signalizacijske funkcije IMS-a zahtijevaju informacije iz HSS servera, normalna upotreba
IMS jezgre nije moguća bez toga. Zato je i FHoSS (engl. FOKUS Home Subscriber
Server) dio Open Source IMS Core platforme [42]. Slika 6.1 prikazuje osnovne elemente
Open IMS Core platforme.
Sl. 6.1 Arhitektura Open IMS Core platforme [43]
U nastavku će se ukratko opisati osnovni elementi Open Source IMS Core platforme.
71
6.1.1. Open IMS funkcija za upravljanje sesijom poz iva
Open IMS funkcija za upravljanje sesijom poziva je bazirana na SER ruteru koji može
imati ulogu SIP redirekcijskog, registracijskog ili proxy servera, i sposoban je da upravlja
sa više hiljada poziva u sekundi. Ovaj ruter ima modularnu strukturu koja dozvoljava
dodavanje različitih funkcionalnosti. Svaki CSCF modul je implementiran kao SER
dinamički modul koji dodaje potrebne funkcionalnosti SER-u [43]. S obzirom da su u
okviru prvog poglavlja opisane osnovne karakteristike CSCF-ova, u ovom dijelu će se
opisati osnovne funkcionalnosti CSCF modula baziranih na SER serveru. U trenutnoj
implementaciji Open IMS Core platforme, P-CSCF modul implementira funkciju
aplikacijskog firewall-a u smislu da omogućava samo registrovanim korisnicima da
pristupe IMS mreži. Nakon registracije P-CSCF modul uspostavlja individualne sigurnosne
kanale za svakog korisnika koji se poslužuje. Kako bi pratio registrovane korisnike P-
CSCF modul sadrži interni registar koji mu omogućava održavanje informacija o
korisnicima. Prilikom prijema SIP signalizacijskih zahtjeva ovaj modul generiše
jedinstvene charging vektore, te umeće identifikator mreže i putanja (engl. path) koji su
neophodni za dalje procesiranje SIP poruka. Neke od mogućnosti P-CSCF modula su:
signalizacijski firewall i potvrda identiteta korisnika, zaštita integriteta kod procesa
autentifikacije, podrška za specifična zaglavlja, sinhronizacija lokalnog registra itd [43].
Slika 6.2 prikazuje arhitekturu P-CSCF modula.
Sl. 6.2 Arhitektura P-CSCF-a [43]
72
Modul I-CSCF se ponaša kao proxy server koji ne čuva stanje korisnika. Ovaj modul šalje
upit preko Cx interface-a HSS bazi kroz odgovarajuću Diameter poruku kako bi dobio
potrebnu informaciju za dalji proces rutiranja, te u zavisnosti od odgovora prosljeđuje
poruku prema odgovarajućem S-CSCF modulu (koji opslužuje datog korisnika). Dakle, I-
CSCF modul podržava potrebne Diameter komande za lociranje S-CSCF-a koji je
dodijeljen korisniku, ili za odabir novog S-CSCF-a i provjeru identiteta. U kontekstu
sigurnosti implementira firewall funkcionalnost na način da propušta signalizacijske
poruke samo sa povjerljivih mreža. Neke od mogućnosti I-CSCF modula su: puna podrška
za Cx inerface, odabir S-CSCF-a na osnovu korisničkih sposobnosti, sigurnosna domena
mreže NDS (engl. Network Domain Security), itd. [43]. Slika 6.3 prikazuje arhitekturu I-
CSCF modula.
Sl. 6.3 Arhitektura I-CSCF-a [43]
Implementirani S-CSCF modul također komunicira sa HSS-om korištenjem Diameter
protokola (preko Cx interface-a) kako bi preuzeo autentifikacijski vektor, ažurirao podatke
o registrovanim korisnicima i preuzeo profile korisnika koji su se registrovali za korištenje
određene usluge. Modul S-CSCF omogućava autentifikaciju kroz AKAv1-MD5, AKAv2-
MD5 i MD5 (engl. Message-Digest Algorithm) algoritme [43]. Slika 6.4 prikazuje
arhitekturu S-CSCF modula.
73
Sl. 6.4 Arhitektura S-CSCF-a [43]
6.1.2. FOKUS Home Subscriber Server
Open Source IMS Core platforma bi bila nepotpuna bez HSS servera. FOKUS je razvio
vlastiti prototip HSS-a, FHoSS koji je napisan u Java programskom okruženju. Podaci o
korisniku se čuvaju unutar MySQL (SQL – engl. Structured Query Language) baze
podataka. FHoSS je orijentisan, uglavnom, na konformitet s ne na performanse. On je
konfigurator za bazu podataka i Diameter interface sa CSCF-om i IMS aplikacijskim
slojem. Protokoli i Diameter komande su implementirane u FHoSS od strane FOKUS-ovog
vlastitog Java baziranog Diameter stack-a. Omogućava generisanje autentikacijskih
vektora za autorizaciju korisnika i pruža HTTP bazirani interfejs za lako upravljanje
korisničkim profilima i pohranjivanje korisničkih profila [43]. Slika 6.5 prikazuje
arhitekturu FHoSS baze podataka.
74
Sl. 6.5 Arhitektura FHoSS-a [43]
6.2. SIPp generator saobra ćaja
Za generisanje opterećenja mreže i analizu SIP signalizacijskih metrika korišten je SIPp
generator saobraćaja. Generator saobraćaja SIPp je besplatni open source testni
alat/generator saobraćaja za SIP protokol. Ovaj alat uključuje nekoliko osnovnih SipStone
scenarija korisničkog agenta (UAC i UAS), i omogućava uspostavljanje i prekidanje
višestrukih poziva korištenjem INVITE i BYE metoda. Također, SIPp omogućava čitanje
XML scenario fajlova koji opisuju tokove poziva.
Karakteristike SIPp generatora saobraćaja uključuju podršku za IPv6, TLS, SIP
autentifikaciju, UDP retransmisije, robusnost od grešaka i sl. Ovaj alat karakteriše
dinamični ekran na kojem se prikazuju statistike o pokrenutim procesima (brzina poziva,
statistike vezane za poruke koje se razmjenjuju itd.).
Kako SIPp sadrži sveobuhvatnu dokumentaciju koja je dostupna u HTML (engl.
HyperText Markup Language) ili PDF (engl. Portable Document Format) formatu to ga
čini jednostavnim za korištenje. Ovaj alat se može koristiti za testiranje stvarne SIP opreme
(SIP proxy, B2BUA serveri, SIP medijski serveri itd) [44].
Konfiguracija SIPp-a preuzeta je s web stranice [44], a prikaz instalacije dat je u prilogu C
ovog rada.
75
6.3. Opis topologije testne mreže
U ovom podpoglavlju će se ukratko opisati i prikazati topologija testne mreže koja je
korištena za potrebna testiranja. Korištena su 2 Acer VERITON M6620G računara i laptop
Lenovo čije su hardverske komponente navedene u uvodnom dijelu ovog poglavlja. Slika
6.6 prikazuje konfiguraciju testne mreže. Na računaru sa IP adresom 192.168.1.1 je
instalirana i pokrenuta Open IMS Core platforma. Na drugom računaru sa IP adresom
192.168.1.3 je instaliran UCT IMS klijent. Korištena su dva UCT klijenta kako bi se
pokazao proces uspostavljanja VoIP poziva između ovih klijenata. Drugi UCT IMS klijent
je instaliran na laptopu Lenovo sa IP adresom 192.168.1.2. Dodatno na ovom laptopu je
instaliran SIPp generator saobraćaja pomoću kojeg će se opterećivati IMS mreža.
Sl. 6.6 Konfiguracija testne mreže
76
6.4. Sažetak
Za realizaciju praktičnog dijela rada korištena je Open Source IMS Core platforma.
Najvažniji elementi ove platforme su CSCF moduli koji su implementirani kao
nadogradnja SER serveru, i FHoSS baza podataka koja služi za pohranjivanje svih
korisničkih informacija. Instaliranjem Open Source IMS Core platforme u FHoSS bazi se
već nalaze konfigurisana dva pretplatnika Alice ([email protected]) i Bob (bob@open-
ims.test). Za potrebe mjerenja performansi SIP signalizacijskih metrika u FHoSS bazu su
dodata još dva korisnika Tomy ([email protected]) i Mary ([email protected]).
Za simuliranje mrežnog opterećenja korišten je SIPp generator saobraćaja. Ovim
generatorom se kreira opterećenje u vidu uspostavljanja različitog broja poziva između
korisnika Alice ([email protected]) i Bob ([email protected]). Vrijednosti posmatranih
metrika pri različitom broju uspostavljenih poziva će se prikazati i objasniti u sljedećem
poglavlju.
Na kraju ovog poglavlja prikazana je konfiguracija testne mreže korištene za izvođenje
potrebnih testiranja.
77
7. Rezultati i diskusija mjerenja uticaja
signalizacijskog optere ćenja na QoE
U ovom poglavlju će se prikazati rezultati dobiveni prilikom mjerenja metrika performansi
SIP signalizacije. Zahvaljujući proširenju UCT klijentske aplikacije također je omogućeno
mjerenje MOS-a, te je zabilježena ovisnost između dobivenih rezultata za QoS i QoE
parametre. Mjerene su sljedeće metrike: kašnjenje zahtjeva za registraciju, kašnjenje
zahtjeva za uspostavu sesije i kašnjenje prekida sesije. Navedene metrike su mjerene u
skladu sa načinom opisanim u trećem poglavlju ovog rada i u testnom okruženju koje je
opisano u šestom poglavlju.
Mjerenje je sprovedeno na sljedeći način. Prilikom mjerenja navedenih metrika za SIP
signalizacijske procedure između UCT klijenata simulirano je različito mrežno opterećenje
pomoću SIPp generatora saobraćaja. Kako bi SIPp generator ispravno funkcionisao
potrebne su odgovarajuće XML skripte koje služe za opis različitih signalizacijskih
procedura kao što su registracija korisnika i uspostava veze. Ove skripte se nalaze u
prilogu D ovog rada.
Nakon uspješne instalacije Open Source IMS Core platforme konfigurisana su dva SIP
korisnika Alice ([email protected]) i Bob ([email protected]). Opterećenje je
simulirano na način da se generiše različit broj poziva u sekundi između korisnika Bob i
Alice. Prvo je potrebno pomoću SIPp generatora izvršiti registraciju ovih korisnika. Ovaj
proces se vrši pokretanjem naredbi (I) i (II) u terminalu.
sipp -sf non_em_reg_alice.xml 192.168.1.1:4060 -i 1 91.168.1.2
-p 3061 -m 1 (I)
sipp -sf non_em_reg_bob.xml 192.168.1.1:4060 -i 192 .168.1.2 -
p 3062 -m 1 (II)
Nakon toga u dva odvojena terminala se unose naredbe (III) i (IV).
sipp -sf uas_b2a.xml –r 20 –rd 1000 192.168.1.1:406 0 -i
192.168.1.2 -p 3061 -m 20 (III)
sipp -sf non_em_uac_b2a.xml –r 20 –rd 1000 192.168. 1.1:4060 -
i 192.168.1.2 -p 3062 -m 20 (IV)
78
Unošenjem naredbe (III) u terminal Alice očekuje pozive na portu 3061. Unošenjem
naredbe (IV) u terminal korisnik Bob generiše pozive prema korisniku Alice slanjem SIP
INVITE zahtjeva sa porta 3062 i terminira iste slanjem BYE zahtjeva. Osim toga
pokretanjem ovih naredbi pokreće se petlja kojom se generiše 20 poziva (-r 20 ) u
periodu od 1 [s] (-rd 1000 ), tj. ovom naredbom se generiše 20 poziva sa porta 3062 i na
taj način se simulira opterećenje IMS mreže koje zavisi od broja generisanih poziva u
sekundi. Parametar m u prethodnim naredbama se odnosi na maksimalan broj poziva koji
se generiše. Slika 7.1 prikazuje način generisanja mrežnog opterećenja korištenjem SIPp
generatora.
Sl. 7.1 Prikaz generisanog mrežnog opterećenja korištenjem SIPp generatora
Budući da za opisivanje metrika performansi SIP signalizacije nisu dovoljna samo dva
postojeća korisnika Bob i Alice, dodatno su konfigurisana još dva SIP korisnika Tomy
([email protected]) i Mary ([email protected]). Dodavanje korisnika je izvršeno
kroz GUI FHoSS baze podataka. Nakon uspješne konfiguracije i registracije novih
korisnika, u FHoSS bazi podataka postoje 4 SIP korisnika kao što je prikazano na slici 7.2.
Bazi FHoSS se pristupa preko web stranice http://192.168.1.1:8080 s korisničkim imenom
hssAdmin i password-om hss.
79
Sl. 7.2 Prikaz SIP korisnika u FHoSS bazi podataka
Nakon uspješne registracije dva nova korisnika pokušava se uspostaviti multimedijalna
sesija/poziv između korisnika Tomy i Mary. Korisnički agent Tomy šalje SIP INVITE
poruku korisničkom agentu Mary. Korisnik Mary prihvata poziv, te se uspješno
uspostavlja multimedijalna sesija/poziv između ovih korisnika. Slike 7.3 i 7.4 prikazuju
GUI UCT klijenta sa prikazanom razmjenom poruka koje su karakteristične za proces
iniciranja i prihvatanja poziva.
Sl. 7.3 Izgled GUI-a UCT klijenta sa prikazanom razmjenom poruka prilikom iniciranja poziva
80
Sl. 7.4 Izgled GUI-a UCT klijenta sa prikazanom razmjenom poruka prilikom uspostave poziva
Nakon uspješne uspostave poziva, korisnik Tomy prekida poziv, odnosno korisnički agent
[email protected] generiše BYE zahtjev koji šalje korisničkom agentu mary@open-
ims.test. Poziv je uspješno završen kada korisnički agent [email protected] primi 200
OK poruku na poslati BYE zahtjev. Slika 7.5 prikazuje GUI UCT klijenta sa razmjenjenim
porukama prilikom prekida poziva. Ovako opisani scenariji uspostave i prekida poziva se
najčešće koriste za mjerenje metrika performansi SIP signalizacije.
81
Sl. 7.5 Izgled GUI UCT klijenta sa prikazanom razmjenom poruka prilikom prekida poziva
Metrike performansi SIP signalizacije su mjerene pri različitom opterećenju koje se
generiše korištenjem SIPp generatora (generisanjem različitog broja poziva u sekundi
između korisnika Bob i Alice). U nastavku će se prikazati rezultati mjerenja metrika
performansi SIP signalizacije.
7.1. Rezultati mjerenja kašnjenja zahtjeva za regis traciju
Prilikom mjerenja kašnjenja zahtjeva za registraciju (RRD) korišten je sljedeći scenario.
Pomoću SIPp generatora prvo se izvrši registracija korisnika Alice i Bob unošenjem
naredbi (I) i (II). Nakon toga se unošenjem naredbi (III) i (IV) generiše različit broj poziva
u sekundi između korisnika Bob i Alice. Ovi pozivi predstavljaju opterećenje prilikom
kojeg se UCT klijent sip:[email protected] pokušava uspješno registrovati.
U okviru izvornog koda UCT IMS klijentske aplikacije implementiran je dio za računanje
kašnjenja zahtjeva za registraciju korisnika koji je objašnjen u petom poglavlju. Kašnjenje
zahtjeva za registraciju je mjereno pri različitom opterećenju IMS mreže koje je
predstavljeno brojem generisanih poziva u sekundi. Maksimalni broj opterećenja pri kojem
82
je registracija uspješna iznosi 110 poziva u sekundi. U tabeli 7.1 su prikazane vrijednosti
RRD-a za 12 mjerenja prilikom kojih je proces registracije bio uspješan.
Tabela 7.1 Rezultati RRD-a za različite vrijednosti opterećenja IMS mreže
Broj poziva u
sekundi
RDD
[s] [ms]
0 0.270 270
10 0.346 346
20 0.546 546
30 3.255 3255
40 5.540 5540
50 16.624 16624
60 19.839 19839
70 20.626 20626
80 29.190 29190
90 33.959 33959
100 38.968 38968
110 46.228 46228
Povećanjem vrijednosti RRD-a korisnik postaje nezadovoljniji pošto mora duže čekati
kako bi pristupio IMS mreži i koristio željene usluge. Posmatrajući dobivene rezultate
može se subjektivno zaključiti da korisnik postaje nezadovoljniji kada prilikom 40
generisanih poziva u sekundi on mora čekati 5.540 [s] kako bi pristupio IMS mreži i
koristio željene usluge, što dovodi do smanjenja QoE-a. Sa daljim povećanjem opterećenja
IMS mreže vrijednost QoE nastavlja da opada.
83
Kako se metrika RRD formalno izražava u milisekundama [ms], kako je to navedeno u
trećem poglavlju, na slici 7.6 je dat grafički prikaz vrijednosti kašnjenja zahtjeva za
registraciju izraženih u milisekundama [ms]. Ono što je bitno napomenuti je to da i pored
simuliranog opterećenja IMS mreže, uslovi u kojima su vršena mjerenja nisu jednaki
uslovima koje realni telekomunikacijski sistem može da ponudi svojim korisnicima.
Dodatno, dobiveni rezultati zavise od performansi računarskog sistema na kojem se izvode
mjerenja.
Sl. 7.6 Grafički prikaz RRD-a
Sa slike 7.6 se vidi da nakon opterećenja od 40 generisanih poziva u sekundi vrijednost
RRD-a naglo počinje da raste, i nastavlja da raste sa daljim povećanjem opterećenja sve do
trenutaka kada se registracija više ne može uspješno uspostaviti.
7.2. Rezultati mjerenja kašnjenja zahtjeva za uspos tavu
sesije
Kašnjenje zahtjeva za uspostavu sesije se računa za uspješno i neuspješno procesiranje SIP
INVITE zahtjeva. Analizira se uspostava poziva između dva UCT klijenta Tomy
([email protected]) i Mary ([email protected]) pri različitom opterećenju IMS
mreže. Tabela 7.2 prikazuje dobivene vrijednosti SRD-a pri različitom broju generisanih
poziva u sekundi sa intervalom od 10 poziva.
84
Tabela 7.2 Vrijednosti SRD-a za uspješne uspostave sesije pri različitom opterećenju IMS mreže
Broj poziva u
sekundi
SRD [s]
0 1.001
10 1.085
20 4.547
30 13.436
40 22.667
50 28.676
60 33.745
70 37.277
80 44.059
90 45.442
Analogno kao i kod računanja kašnjenja zahtjeva za registraciju u izvornom kodu UCT
klijenta postoji dio koda za računanje SRD-a. Dijelovi koda unutar kojih se računa SRD
metrika su navedeni u petom poglavlju. Uspješna uspostava sesije računa se od trenutka
kada korisnički agent [email protected] pošalje INVITE zahtjev korisničkom agentu
[email protected] do trenutka kada on primi indikativni odgovor 180 Ringing. Na
osnovu navedenih rezultata primjećujemo da se nakon opterećenja od 20 generisanih
poziva u sekundi vrijednost SRD naglo povećava i nastavlja da približno linearno raste.
Subjektivno se može zaključiti da korisnik postaje nezadovoljniji budući da pri opterećenju
30 poziva on mora čekati oko 13 sekundi da bi uspješno uspostavio poziv, ovo je razlog za
smanjenje QoE-a. Sa daljim povećavanjem opterećenja IMS mreže vrijednost SRD se
povećava i samim tim dolazi do smanjenja korisničkog zadovoljstva korištenom uslugom.
Vrijednosti SRD-a za opterećenje od 20 poziva su prihvatljiva, dok SRD pri većem iznosu
85
opterećenja poprima veliku vrijednost i korisnik postaje poprilično iritiran vremenom koje
mora čekati da koristi željenu uslugu. Slika 7.7 prikazuje grafički prikaz SRD-a za
uspješnu uspostavu sesije pri različitom opterećenju IMS mreže.
Sl. 7.7 Grafički prikaz SRD-a za uspješnu uspostavu sesije
Kao što je već predhodno rečeno, SRD se mjeri i za neuspješno procesiranje SIP INVITE
zahtjeva. Do neuspješnog procesiranja SIP INVITE može doći uslijed različitih problema.
Neuspješna uspostava sesije se indicira prijemom poruke odgovora iz klasa 4xx, 5xx i 6xx.
Dakle, SRD za neuspješnu uspostavu sesije se računa od trenutka slanja SIP INVITE
zahtjeva do trenutka prijema prvog privremenog odgovora koji ukazuje na to da sesija nije
uspješno uspostavljena. Način računanja SRD-a uslijed prijema poruke odgovora iz
navedenih klasa je prikazan programskim kodovima koji su predstavljeni u petom
poglavlju. Tabela 7.3 prikazuje vrijednosti SRD-a za neuspješno procesiranje SIP INVITE
zahtjeva pri različitom opterećenju IMS mreže. Neuspješna uspostava sesije se obično
javlja pri većim opterećenjima IMS mreže. Za opterećenja od 100 do 130 generisanih
poziva u sekundi javlja se greška s porukom Busy Here (for INVITE), odnosno čvorovi
IMS mreže su zauzeti procesiranjem poruka za uspostavljanje poziva koji su generisani
SIPp generatorom, pa se INVITE zahtjev poslat od strane korisničkog agenta tomy@open-
ims.test ne može procesirati (Slika 7.8). Kada se generiše opterećenje od 140 poziva u
sekundi javlja se greška s porukom Session terminated in P-CSCF (for INVITE), odnosno
86
zbog zagušenja P-CSCF čvora generisanim opterećenjem dolazi do neuspješnog
procesiranja SIP INVITE zahtjeva (Slika 7.9).
Sl. 7.8 Prikaz odgovora prilikom generisanja opterećenja od 100 do 130 poziva u sekundi
87
Sl. 7.9 Prikaz odgovora prilikom generisanja opterećenja od 140 poziva u sekundi
U tabeli 7.3 su prikazane vrijednosti SRD-a prilikom neuspješne uspostave sesije za
različite vrijednosti opterećenja IMS mreže.
Tabela 7.3 Vrijednosti SRD-a prilikom neuspješne uspostave sesije za različite vrijednosti
opterećenja IMS mreže
Broj poziva u
sekundi
SRD [s]
100 55.633
110 57.428
120 57.705
130 59.883
140 62.164
88
Na osnovu dobivenih rezultata prikazanih u tabeli 7.3 primjećuje se da vrijednosti SRD-a
prilikom neuspješne uspostave sesije relativno malo variraju, izuzev posljednje vrijednosti
kada se INVITE zahtjev odbija od strane servera zbog velikog zagušenja P-CSCF čvora.
Slika 7.10 prikazuje grafički prikaz SRD-a prilikom neuspješne uspostave sesije pri
različitom opterećenju IMS mreže.
Sl. 7.10 Grafički prikaz SRD-a prilikom neuspješne uspostave sesije
7.3. Rezultati mjerenja kašnjenja prekida sesije
Kašnjenje prekida sesije SDD se računa od trenutka slanja prvog bita BYE poruke do
trenutka prijema posljednjeg bita 200 OK poruke. Vrijednost SDD-a se može mjeriti na
izvorišnom ili na odredišnom korisničkom agentu. Scenario prilikom kojeg se mjeri
vrijednost SDD-a je opisan u nastavku. Nakon registracije korisnika Tomy i Mary na IMS
mrežu, korisnički agent [email protected] šalje SIP INVITE poruku korisničkom agentu
[email protected]. Prijem 200 OK poruke na poslati INVITE zahtjev indicira da je
poziv između korisnika Tomy i Mary uspješno uspostavljen. Za vrijeme trajanja poziva
između ova dva korisnika generišu se različita opterećenja IMS mreže korištenjem SIPp
generatora (generisanjem različitog broja poziva u sekundi). Za vrijeme trajanja ovih
opterećenja korisnički agent [email protected] generiše BYE poruku i šalje je
korisničkom agentu [email protected]. Nakon što korisnik Tomy primi 200 OK poruku
odgovora poziv je uspješno završen. Kod u okviru kojeg je implementirano računanje
89
SDD-a je prikazan u petom poglavlju. Uspješno terminiranje sesije je ostvareno pri
maksimalnom opterećenju od 100 generisanih poziva u sekundi. Za veće iznose
opterećenja korisnički agent [email protected] ne prima 200 OK poruku odgovora na
poslati BYE zahtjev te se vrijednost SDD metrike ne može izračunati. Tabela 7.4 prikazuje
vrijednosti SDD-a mjerenih na strani korisničkog agenta [email protected] pri
različitim vrijednostima opterećenja IMS mreže.
Tabela 7.4 Vrijednosti SDD-a mjerene na strani korisničkog agenta (Tomy) pri različitom
opterećenju IMS mreže
Broj poziva u
sekundi
SDD [ms]
0 0.4115
10 0.48954
20 2000.22381
30 3000.99497
40 15000.77146
50 17000.85443
60 20000.62620
70 21000.66039
80 25000.78136
90 31000.24056
100 32000.42088
Mjerenje na strani odredišnog agenta (Mary) je identično i dobivene vrijednosti se ne
razliku puno od vrijednosti dobivenih za mjerenja na strani izvorišnog agenta (Tomy),
razlika je reda nekoliko milisekundi. Na osnovu toga se može zaključiti da nije bitno da li
90
se vrijednost SDD-a mjeri na strani izvorišnog ili odredišnog korisničkog agenta. Zbog
toga su u ovom dijelu prikazani samo rezultati mjerenja na strani izvorišnog korisničkog
agenta (Tomy). Slika 7.11 prikazuje grafički prikaz kašnjenja prekida sesije mjerenog na
strani izvorišnog agenta.
Sl. 7.11 Grafički prikaz vrijednosti SDD-a mjerenih na strani izvornog korisničkog agenta (Tomy)
7.4. Uticaj izmjerenih vrijednosti RRD-a, SRD-a i S DD-a
na kvalitetu korisni čkog iskustva
U ovom podpoglavlju će se prikazati zavisnost kvaliteta korisničkog iskustva, izraženog
MOS ocjenom, od dobivenih rezultata mjerenja metrika performansi SIP signalizacije,
odnosno zavisnost između QoE i QoS parametara. Na osnovu prikazanih rezultata mjerenja
za RRD, SRD i SDD primjećuje se da pri određenom opterećenju IMS mreže zadovoljstvo
korisnika opada, odnosno smanjuje se QoE. Za pružatelje usluga je veoma bitno da
omoguće korisnicima pristup uslugama u bilo koje vrijeme i sa bilo kojeg mjesta. Na
osnovu prikazanih rezultata mjerenja RRD-a primjećuje se da zadovoljstvo korisnika
opada kada on pri opterećenju IMS mreže od 40 poziva mora čekati 5.540 [s] da bi
pristupio IMS mreži i koristio željene usluge. Za veće vrijednosti opterećenja vrijednost
RRD-a se povećava i to ima za posljedicu značajno smanjenja QoE-a. Slika 7.12 prikazuje
91
način na koji se mijenja MOS sa povećanjem RRD-a koje se javlja pri većem opterećenju
IMS mreže.
Sl. 7.12 Grafički prikaz zavisnosti MOS-a od izmjerenih vrijednosti RRD-a
Sa slike 7.12 se vidi da velike vrijednosti RRD-a, dobivene prilikom generisanja
opterećenja iznad 70 poziva u sekundi, postaju jako iritantne za korisnika koji koristi datu
uslugu. Generalno prihvatljive vrijednosti RRD-a su one dobivene za opterećenja do 40
poziva u sekundi, u tom području se vidi da je korisnik poprilično zadovoljan korištenom
uslugom.
U nastavku će se prikazati grafička zavisnost MOS-a od dobivenih rezultata mjerenja za
SRD i SDD metrike. Naime, prilikom definisanja metrike kašnjenja zahtjeva za uspostavu
sesije rečeno je da se ova metrika najčešće povezuje sa iskustvom krajnjeg korisnika.
Korisnik je veoma osjetljiv kada koristi usluge sa garantovanim QoS-om. Velike
vrijednosti kašnjenja prilikom uspostave i prekida sesije su jako iritantne za krajnjeg
korisnika. Na osnovu prikazanih rezultata mjerenja za SRD primjećujemo da korisnik
postaje nezadovoljniji kada prilikom opterećenja od 30 poziva u sekundi mora da čeka oko
13 sekundi da bi uspostavio poziv. Na osnovu grafičkog prikaza kašnjenja zahtjeva za
uspješnu uspostavu sesije primjećuje se da se vrijednost SRD-a povećava pri većim
iznosima opterećenja IMS mreže. Analogno, vrijednosti dobivene prilikom mjerenja SDD-
a se povećavaju pri većem opterećenju IMS mreže. Ovo za posljedicu ima smanjenje QoE-
a. Na osnovu prikazanih vrijednosti SRD-a i SDD-a primjećuje se da su vrijednosti za
92
SDD znatno manje. Razlog za ovo je što procesiranje BYE poruke na mrežnim čvorovima
traje znatno kraće od procesiranja INVITE poruke. Slike 7.13 i 7.14 prikazuju zavisnost
kvaliteta korisničkog iskustva, izraženu MOS ocjenom, od vrijednosti dobivenih prilikom
mjerenja SRD i SDD metrika performansi SIP signalizacije.
Sl. 7.13 Grafički prikaz MOS-a u zavisnosti od dobivenih rezultata mjerenja za SRD
Sl. 7.14 Grafički prikaz MOS-a u zavisnosti od dobivenih rezultata za SDD
93
Na osnovu prikazanih rezultata može se zaključiti da signalizacijske procedure uspostave i
prekida poziva imaju značajan uticaj na korisnički QoE. Budući da sami proces
signalizacije predstavlja prvu komunikaciju korisnika sa pružateljem usluge, pružatelj
usluga mora obezbjediti da prilikom ovih signalizacijskih procedura zadovoljstvo korisnika
bude na visokom nivou kako bi zadržao korisnike i opravdao njihovo povjerenje. Na
primjer, korisnik postaje jako nezadovoljan ako plaća uslugu sa osiguranim QoS-om a pri
tome mora čekati relativno puno vremena da bi mogao koristiti tu uslugu. Isto tako
nezadovoljstvo korisnika rapidno raste ukoliko kašnjenje prilikom prekida uspostavljene
sesije raste, jer pri tome on i dalje plaća uslugu za koju smatra da je prekinuta. Prikazani
rezultati se razlikuju od rezultata koji bi se dobili u stvarnom okruženju koje pruža neki
telekom operator. Naime, na sve dobivene vrijednosti pored subjektivnih korisničkih
emocija koje su odgovorne za percipiranje kvaliteta korištene usluge u datom trenutku,
veliki uticaj imaju performanse korištene opreme i okruženja u kojem su se izvodila
prethodno objašnjena mjerenja. Prikazani rezultati omogućavaju da se dobije generalni
uvid u to kako signalizacijsko opterećenje utiče na kvalitet korisničkog iskustava. Prilikom
svih mjerenja rezultati su pokazivali da pri većem opterećenju IMS mreže (različitom broju
generisanih poziva u sekundi korištenjem SIPp generatora) dolazi do povećanja vrijednosti
mjerenih metrika performansi SIP signalizacije koje imaju za posljedicu smanjenje QoE-a.
7.5. Sažetak
Sedmo poglavlje prikazuje rezultate mjerenja metrika performansi SIP signalizacije na
osnovu teorijskih postavki opisanih u trećem poglavlju ovog rada i okruženja u kojem se
vrše mjerenja koje je detaljno opisano u šestom poglavlju. Mjerenja ovih metrika su vršena
pri različitom opterećenju IMS mreže koje se generiše korištenjem SIPp generatora
saobraćaja. Dobiveni rezultati su analizirani sa aspekta njihovog uticaja na kvalitetu
korisničkog iskustva. Na osnovu dobivenih rezultata za mjerene metrike može se zaključiti
da sa povećanjem opterećenja IMS mreže dolazi do povećanja kašnjenja koje utiče na
kvalitetu korisničkog iskustva. Odnosno, može se zaključiti da povećanje vrijednosti
mjerenih metrika negativno utiče na zadovoljstvo krajnjeg korisnika koji konzumira
određenu uslugu. Zahvaljujući implementiranim funkcionalnostima na UCT klijentskoj
aplikaciji omogućeno je analiziranje odnosa između QoE-a (izraženog MOS ocjenom) i
QoS-a (metrike performansi SIP signalizacije, RRD, SRD i SDD). Treba naglasiti da na
dobivene vrijednosti kašnjenja za mjerene metrike značajno utiču performanse korištenog
94
sistema za mjerenje kao i subjektivne korisničke emocije koje su odgovorne za percipiranje
kvaliteta korištene usluge u određenom trenutku.
95
Zaklju čak
U ovom završnom radu je opisan uticaj signalizacijskog opterećenja na kvalitetu
korisničkog iskustva. Nakon implementiranja potrebnih funkcionalnosti na UCT IMS
klijentskoj aplikaciji analizirane su i mjerene metrike performansi SIP signalizacije na
način na koji su definisane u RFC 6076 dokumentu. Implementacijom potrebnih
funkcionalnosti na UCT klijentskoj aplikaciji omogućeno je analiziranje zavisnosti između
QoE i QoS parametara. Mjerenje je vršeno na Open Source IMS Core testnoj platformi. U
cilju obezbjeđivanja što realnijih uslova za potrebna mjerenja korišten je SIPp generator
saobraćaja. U radu su sprovedeni različiti scenariji koji se odnose na analiziranje uticaja
signalizacijskog opterećenja na vrijednosti kašnjenja prilikom procedura registracije,
uspostave i prekida multimedijalne sesije/poziva između dva UCT klijenta. Dobiveni
rezultati pokazuju da sa povećanjem generisanog opterećenja dolazi do povećanja
kašnjenja uspostave signalizacijskih procedura što za posljedicu ima povećanje negativnog
efekta na ukupnu kvalitetu korisničkog iskustva. Treba napomenuti da dobiveni rezultati ne
prezentiraju stvarnu situaciju koju bi telekomunikacijski sistem mogao da ponudi svojim
korisnicima. Vrijednosti mjerenih metrika uveliko zavise od performansi korištene opreme
kao i od okruženja u kome su se izvodila potrebna mjerenja.
Budući da opisane signalizacijske procedure predstavljaju prvu komunikaciju korisnika sa
pružateljem usluga, oni moraju obratiti posebnu pažnju na signalizacijske metrike
analizirane u ovom radu kako bi omogućili visok stepen korisničkog zadovoljstva u ovoj
fazi, a koji će posljedično imati uticaj i na povećanje ukupnog korisničkog zadovoljstva
uslugom koju on konzumira.
Sa povećanjem broja i složenosti usluga nove generacije pružatelji usluga se suočavaju sa
velikom količinom signalizacijskog opterećenja koju moraju kontrolirati i upravljati na
prikladan način kako bi obezbijedili prikladan nivo kvaliteta iskustva za krajnje korisnike i
na taj način zadržali određen udio na današnjem kompetitivnom telekomunikacijskom
tržištu. Budući da identificirani problemi povezani sa signalizacijskim procedurama znatno
utiču na smanjenje kvaliteta korisničkog iskustva, rješavanje ovog problema je postalo
fokus trenutnih i budućih istraživačkih aktivnosti.
96
Literatura
[1] ITU-T RECOMMENDATION Y.2001. General Overview of NGN. April 2004.
[2] C. LEE, N. MORITA. Next Generation Network Standards in ITU-T. January 2006.
[3] K. KNIGHT, T. TOWLE, N. MORITA. NGN architecture: generic principle, functional architecture, and its realization. IEEE Communication Magazine, October 2005.
[4] ITU-T RECOMMENDATION Y.2011. General Principles and General Reference Model for Next Generation Networks. October 2004.
[5] R. BLESS, M. RÖHRICHT. End-to-End Quality-of-Service Support in Next Generation Networks with NSIS. Karlsruhe Institute of Technology (KIT) Zirkel 2, D–76128 Karlsruhe, Germany.
[6] ITU-T RECOMMENDATION Y.2012. Functional Requirements and Architecture of the NGN Release 1. September 2006.
[7] I. JENKINS. NGN Control Plane Overload and its Management. Tehnical Report MSF-TR-ARCH-007-FINAL, MultiService Forum, February 2006.
[8] M. POIKSELKÄ, G. MAYER, H. KHARTABIL , A. NIEMI. The IMS: IP Multimedia Concepts and Service. John Wiley & Sons, Ltd, 2006.
[9] R. LJ. CHEN, E. CY. SU, V. SC. SHEN, YI-HONG WANG. (2006, September 12). Introduction to IP Multimedia Subsystem (IMS), Part 1: SOA Parlay X Web services, The Next Generation Network architecture for Telecom industry [Online]. Available: https://www.ibm.com/.
[10] J. BARAKOVIĆ-HUSIĆ. Mrežni multimedijalni servisi. Multimedijalne usluge u novoj generaciji mreža. Univerzitet u Sarajevu, 2012.
[11] M. REZAUL, H. MORSHED, MD. HUMAYUN KABIR. Analysis of IP Multimedia Subsystem for 3G Networks. Master thesis. Blekinge Institute of Technology, December 2009.
[12] ITU-T RECOMMENDATION Y.2021. IMS for Next Generation Networks. September 2006.
[13] H. BATTERAM, G. DAMM , A. MUKHOPADHYAY , L. PHILIPPART, R. ODYSSEOS, C. URRUTIA-VALDES. Delivering Quality of Experience in Multimedia Networks. Bell Labs Technical Journal. 2010; 15(1): 175-194.
[14] J. ZHANG, N. ANSARI. On Assuring End-To-End Qoe in Next Generation Networks: Challenges and a Possible Solution. IEEE Communications Magazine, July 2011; 49(7): 185 –191.
[15] D. SOLDANI, L. MAN, R. CUNY. QoS and QoE Management in UMTS Cellular Systems. John Wiley & Sons, ltd. 2006.
[16] ITU-T RECOMMENDATION G. 1070. Opinion Model for Video-Telephony Application. July 2012.
97
[17] ITU-T RECOMMENDATION P.911. Subjective Audiovisual Quality Assessment Methods for Multimedia Applications. December 1998.
[18] ETSI EG 202 843 V1.1.2. Definitions and Methods for Assessing the QoS parameters of the Customer Relationship Stages other than utilization. July 2011.
[19] A. MORAIS, A. CAVALLI , H. A. TRAN, A. MELLOUK, B. AUGUSTIN, S. HOCEINI, A. CUADRA-SÁNCHEZ, K. BRUNNSTRÖM, A. AURELIUS. Managing Customer Experience through Service Quality Monitoring. Future Network & MobileSummit 2012 Conference Proceedings.
[20] O. OBAFEMI, T. GYIRES, Y. TANG. An Analytic and Experimental Study on the Impact of Jitter Playout Buffer on the E-model in VoIP Quality Measurement. The Tenth International Conference on Networks, 2011.
[21] M. TALK . Finding and Fixing VoIP Call Quality Issues. White paper, WildPackets lnc, 2013.
[22] N. BIONDIĆ, M. VUKUŠIĆ-VASILJEVSKI, L. MEDAK, V. BOLT, V. VRLIKA . Protokol za pokretanje sesije. Ericsson Nikola Tesla REVIJA 18, 1 (2005), 3 – 34.
[23] A. RAAKE . Speech Quality of VoIP. Assessment and Prediction. John Wiley & Sons, Ltd, 2006.
[24] S. MRDOVIĆ, Napredni telekomunikacijski protokoli i mreže nove generacije. Uvodno predavanje. Univerzitet u Sarajevu, 2013.
[25] D. MALAS, A. MORTON. Basic Telephony SIP End – to – End Performance Metrics. Technical Report RFC 6076, Internet Engineering Task Force, January 2011.
[26] D. Hardman. Noise and Voice Quality in VoIP Environments. Technical Marketing Engineer, Agilent Technologies,Colorado Springs, Colorado, USA.
[27] W. CHERIF, A. KSENTINIS, D. NÉGRU, M. Sidibé. A_PSQA: PESQ-like non-intrusive tool for QoE prediction in VoIP services. IEEE Communications Magazine, June 2012: 2124 – 2128.
[28] S. BARAKOVIĆ, J. BARAKOVIĆ, H. BAJRIĆ. QoE Dimensions and QoE Measurement of NGN Services. Proceedings of the 18th Telecommunications Forum, TELFOR 2010, Belgrade, Serbia, 2010.
[29] P. BROOKS, B. HESTNES. (2010, April 1). User measures of Quality of Experience - Why being Objective and Quantitative is Important [Online]. Available: http://www.deepdyve.com.
[30] M. FIEDLER, T. HOßFELD, P. TRAN-GIA . A Generic Quantitative Relationship Between Quality of Experience and Quality of Service. IEEE Communications Magazine, March-April 2010; 24(2): 36 –41.
[31] M. CANO, F. CERDAN. Subjective QoE analysis of VoIP applications in a wireless campus environment. Springer Science+Business Media, LLC, 2010.
[32] M. HAPPENHOFER, C. EGGER, P. REICHL. Quality of Signalling: A New Concept for Evaluating the Performance of Non – INVITE SIP Transactions. Proceedings of the 22nd International Teletraffic Congress (ITC 22), Amsterdam, Netherlands, (2010), 1 - 8.
[33] A. BRAJDIĆ, M. SUZNJEVIĆ, M. MATIJAŠEVIĆ. Measurement of SIP Signaling Performance for Advanced Multimedia Services. Proceedings of the 10th
98
International Conference on Telecommunications ConTEL, Zagreb, Croatia, June (2009), 381-388.
[34] H. FATHI , S.S. CHAKRABORTY, R. PRASAD. Voice over IP in Wireless Heterogeneous Networks. Springer Science Business Media B.V, 2009.
[35] A. ALFALLAH , H. ALKAABEY . Study the Performance of the Use of SIP for Video Conferencing. Master thesis. School of Computing, Blekinge Institute of Technology, Karlskrona, Sweeden, September 2011.
[36] J. M. BATALLA , J. ŚLIWIŃSKI, H. TARASIUK, W. BURAKOWSKI. Impact of Signaling System Performance on QoE in Next Generation Networks. Journal of Telecommunication and Information Technology, April 2009.
[37] M. VOZNAK, J.ROZHON. SIP Infrastructure Performance Testing. In Proceedings of the 9th International Conference on TELECOMMUNICATIONS and INFORMATICS, May 2010:153-158.
[38] M. VOZNAK. Evaluating the Performance of SIP Infrastructure. September 2011.
[39] M. KULIN , T. KAZAZ , S. MRDOVIĆ. SIP Server Security with TLS: Relative Performance Evaluation. Proceedings of the 9th International Conference on Telecommunications BIHTEL, October 2012; 1-6.
[40] D. WAITING , R. GOOD. (2007, Jun 27). University of Cape Town, UTC IMS Client [Online]. Available: http://uctimsclient.berlios.de/.
[41] D. WAITING , R. GOOD, R. SPIERS, N. VENTURA. The UCT IMS Client. IEEE Communications Magazine, April 2009: 1-6.
[42] D. VINGARZAN. (2008, October 23). Open Source IMS Core, [Online]. Available: http://www.openimscore.org/.
[43] Fraunhofer FOKUS homepage. (2006, November 26). [Online]. Available: http://www.fokus.fraunhofer.de/en/fokus/index.html/.
[44] R. GAYRAUD , O. JACQUES. (2013, April 4). SIPp: Wellcome to SIPp [Online]. Available: http://sipp.sourceforge.net/.
99
Popis skra ćenica
3G 3rd Generation treća generacija
3GPP 3rd Generation Partnership Project projekt partnerstva za treću
generaciju
3GPP2 3rd Generation Partnership Project 2 projekat partnerstva za treću
generaciju 2
AKA Authentication and Key Agreement sporazum o autentikaciji i
ključevima
ANI Application-to-Network Inerface Interface za povezivanje aplikacija
sa mrežom
B2BUA Back-to-Back User Agent
BGCF Breakout Gateway Control Function funkcija upravljanja pristupnikom
za prebacivanje veze na posrednika
CDR Call Detail Records zapis o detaljima poziva
CS cicuit-switched komutacija krugova
CSCF Call Session Control Function funkcija za upravljanje sesijom
poziva
DNS Domain Name Server sistem imena domena
DRD Dial-to-Ring Delay kašnjenje prilikom biranja poziva
do prvog „zvonjenja“
EMS Element Management System sistem za upravljanje mrežnim
elementima
ETSI European Telecommunication Standards
Institute
evropski institut za standarde u
području telekomunikacija
FHoSS FOKUS Home Subscriber Server Fokus server domaćih pretplatnika
GSM Global System for Mobile Communications globalni sistem za mobilne
100
komunikacije
GUI Graphical User Interface grafički korisnički interface
HD High Definition visoka rezolucija
HSS Home Subscriber Server domaći pretplatnički server
HTML HyperText Markup Language jezik za kreiranje hipertekstualnih
datoteka
HTTP Hypertext Transport Protocol protokol za slanje hiperteksta
I-CSCF Interrogating CS ispitni CSCF
IETF Internet Engineering Task Force radna skupina za razvoj interneta
IM Instant Messaging trenutna razmjena poruka
IMS IP Multimedia Subsystem multimedijalni podsistem zasnovan
na Internet protokolu
IP Internet Protocol internetski protokol
IPTV Internet Protocol Television televizija bazirana na Internet
protokolu
ITU International Telecommunication Union međunarodna telekomunikacijska
zajednica
KPI Key Performance Indicators ključni indikatori performansi
KQI Key Quality Indicators ključni indikatori kvalitete
MGCF Media Gateway Control Function funkcija upravljanja medijskim
pristupnikom
MGW Media Gateway medijski pristupnik
MIB Management Information Base baza upravljačkih informacija
MOS Mean Opinion Score srednja ocjena korisničke procjene
kvaliteta usluge
MP2 Moving Picture Experts Group audio layer II audio kodek
101
MRF Media Resource Function funkcija medijskih resursa
MRFC Multimedia Resource Function Controller kontroler funkcije multimedijskih
resursa
MRFP Media Resource Function Processor procesor funkcije multimedijskih
resursa
MSRP Message Session Relay Protocol
NDS Network Domain Security sigurnosna domena mreže
NGN Next Generation Network mreža nove generacije
NNI Network-to-Network Interface Interface za povezivanje mreža
ns-2 Network Simulator 2 mrežni simulator 2
PBX Private Branch Exchange privatna telefonska centrala
P-CSCF Proxy CSCF posrednički CSCF
PD Processing Delay kašnjenje obrade
PDD Post-Dial Delay kašnjenje ponovnog biranja
PDF Portable Document Format portabilni format dokumenta
PDF Policy Decision Function funkcija za odlučivanje politika
PESQ Perceptual Evaluation of Speech Quality perceptualna procjena kvalitete
govora
PPD Post-Pickup Delay kašnjenje prilikom ponovnog
„podizanja“ slušalice
PSTN Public Switched Telephone Network javna komutirana
telekomunikacijska mreža
QoE Quality of Experience kvalitet iskustva
QoS Quality of Service kvalitet usluge
RDD Registration Request Delay kašnjenje zahtjeva za registraciju
RpD Response Delay kašnjenje odgovora
102
RTCP Real-time Control Protocol protokol za prenos kontrolnih
podataka u stvarnom vremenu
RTP Real-time Transport Protocol protokol za prenos podataka u
realnom vremenu
RTSP Real Time Streaming Protocol protokol za kontrolu medija koji se
šalje
SBC Session Border Controller kontrolor granica sesije
S-CSCF Serving CSCF poslužujući CSCF
SD Standard Definition standardna rezolucija
SDD Session Disconnect Delay kašnjenje prekida sesije
SDP Session Description Protocol protokol za opisivanje sesije
SDT Session Duration Time vrijeme trajanja sesije
SER SIP Express Router SIP ekspresni ruter
SGW Signalling Gateway signalizacijski pristupnik
SIMPLE
SIP for Instant Messaging and Presence
Leveraging Extension
SIP Session Initiation Protocol protokol za pokretanje sesije
SLA Service Level Agreement ugovor o nivou usluge
SLF Subscriber Location Function funkcija za lociranje pretplatnika
SNMP Simple Network Management Protocol jednostavni mrežni protokol za
upravljanje
SNR Signal-to-Noice Ratio odnos signal-šum
SNRT Session Renegotiation Delay kašnjenje ponovnog pregovaranja
SNT Session Negotiation Time vrijeme za pregovaranje sesije
SQL Structured Query Language jezik za rad s bazama podataka
SR Success Rate omjer uspješnosti
103
SRD Session Request Delay kašnjenje zahtjeva za uspostavu
sesije
SSD Session Setup Delay kašnjenje uspostave SIP sesije
TCP Transmission Control Protocol protokol za kontrolu transmisije
TDM Time Division Multiplexing vremenski bazirano
multipleksiranje
TLS Transport Layer Security sigurnost transportnog sloja
TV Television televizija
UA User Agent korisnički agent
UAC User Agent Client korisnički agent klijenta
UAS User Agent Server korisnički agent servera
UCT University of Cape Town Univerzitet u Cape Town-u
UDP User Datagram Protocol protokol za prenos korisničkih
datagrama
UNI User-to-Network Interface interface za povezivanje korisnika s
mrežom
UUD User to User Delay kašnjenje od korisnika do korisnika
VoD Video on Demand video na zahtjev
VoIP Voice over Internet Protocol prijenos govora preko Internet
protokola
XCAP XML Configuration Access Protocol protokol pristupa konfiguraciji
XML Extensible Markup Language jezik za označavanje
104
Prilog A: Instalacija Open Source IMS Core
platforme
Prilog A opisuje način instaliranja Open Source IMS Core platforme na Linux Ubuntu
12.04 operativnom sistemu. Za ispravnu instalaciju porebno je prvo instalirati sljedeće
pakete i alate:
• GCC3/4, make, JDK 1.5, ant,
• MySQL server,
• bison, flex,
• libxml2 (> 2.6), libmysql (uključujući i dev pakete),
• Linux kernel 2.6 i ipsec alati u slučaju korištenja IPSec sigurnosti,
• Opciono: openssl ukoliko se želi omogućiti TLS sigurnost,
• bind server,
• Web browser.
Ovi paketi i alati mogu se instalirati kroz terminal korištenjem naredbe apt-get install, ili
korištenjem Ubuntu synaptic alata. Nakon instaliranja potrebnih paketa i alata potrebno je
kreirati /opt/OpenIMSCore direktorij i pozicionirati se u njega korištenjem sljedećih
komandi:
mkdir /opt/OpenIMSCore
cd /opt/OpenIMSCore
U kreiranom direktoriju je potrebno napraviti dva nova direktorija ser_ims i FHoSS i
preuzeti kod OpenIMSCore-a sa stranice sljedećim komandama:
mkdir ser_ims
svn checkout
http://svn.berlios.de/svnroot/repos/openimscore/ser _ims/trunk ser_ims
mkdir FHoSS
svn checkout http://svn.berlios.de/svnroot/repos/op enimscore/FHoSS/trunk
FHoSS
105
Nakon preuzimanja izvornog koda potrebno je izvršiti kompajliranje Open IMS Core-a u
direktorijima ser_ims i FHoSS. Kompajliranje se vrši pomoću sljedećih komandi:
• ser_ims
cd ser_ims make install-libs all cd ..
• FHoSS cd FHoSS ant compile ant deploy cd ..
Nakon uspješno izvršenog kompajliranja potrebno je izvršiti upisivanje određenih
podataka u MySQL bazu. Za to se koriste odgovarajuće SQL skripte koje su preuzete
zajedno sa Open IMS Core. Ovo se postiže korištenjem sljedećih komandi iz
/opt/OpenIMSCore/ direktorija:
mysql -u root -p -h localhost < ser_ims/cfg/icscf.s ql mysql -u root -p -h localhost < FHoSS/scripts/hss_d b.sql mysql -u root -p -h localhost < FHoSS/scripts/userd ata.sql
Dalje je potrebno kopirati sve .sh, .cfg i .xml datoteke iz direktorija
/opt/OpenIMSCore/ser_ims/cfg u direktorij /opt/OpenIMSCore, a to se postiže sljedećim
naredbama ukoliko je trenutna pozicija u direktoriju /opt/OpenIMSCore:
cp ser_ims/cfg/*.cfg . cp ser_ims/cfg/*.xml . cp ser_ims/cfg/*.sh . Dalje je potrebno izvršiti konfiguraciju bind DNS servera. Ova modifikacija se sastoji od
mjenjanja sljedećih fajlova:
• gedit /etc/bind/named.conf i dodati sljedeći kod na kraj fajla:
zone "open-ims.test" {
type master;
file "/etc/bind/open-ims.dnszone";
};
• gedit /etc/resolv.conf/ i dodati sljedeći kod:
# Generated by NetworkManager
search open-ims.test
domain open-ims.test
nameserver 192.168.1.1
106
• gedit /etc/hosts i dodati sljedeći kod:
192.168.1.1 localhost
192.168.1.1 open-ims.test mobicents.open-ims.test u e.open-ims.test presence.open-ims.test icscf.open-ims.test scscf.op en-ims.test pcscf.open- ims.test hss.open-ims.test
Nakon što je izvršena konfiguracija DNS servera potrebno je ponovo pokrenuti bind DNS
server sljedećom komandom:
sudo /etc/inid.d/bind9 restart
Zatim je potrebno u svim fajlovima postaviti IP adresu na 192.168.1.1. Ovo se radi tako što
se prebaci u direktoriji /opt/OpenIMSCore i pokrene skripta configurator.sh
cd /opt/OpenIMSCore
./configurator.sh (sada je potrebno konfigurisati s ve potrebne parametre)
Domain Name: open-ims.test
IP Address: 192.168.1.2(uz pretpostavku da je ovo v aša ip adresa)
all
Nakon izvršenih podešavanja Open IMS Core se pokreće sljedećim komandama u
/opt/OpenIMSCore direktoriju:
./pcscf.sh
./icscf.sh
./scscf.sh
sh startup.sh
107
Prilog B: Instalacija UCT IMS klijenta
Prilog B opisuje način instalacije UCT IMS klijenta na Linux Ubuntu 10.04 operativnom
sistemu. Za ispravnu instalaciju potrebno je imati sljedeće pakete:
• libosip2-dev
• libexosip2-dev
• libgtk2.0-dev
• libxml2-dev
• libcurl4-openssl-dev
• libgstreamer0.10-0
• libgstreamer-plugins-base0.10-dev
• gstreamer0.10-plugins-base
• gstreamer0.10-plugins-good
• gstreamer0.10-plugins-bad
• gstreamer0.10-plugins-ugly
• gstreamer0.10-ffmpeg
• libavcodec-unstripped-51
• libvlc-dev
• vlc
Izvorni kod UCT IPTV klijenta se može preuzet sa sljedećeg linka:
http://prdownload.berlios.de/uctimsclient/uctimsclient1.0.13.tar.gz. Nakon raspakivanja
arhive potrebno je u direktoriju UCT IMS klijenta pokrenuti komandu make, a zatim
komandu ./uctimsclient za pokretanje klijenta.
108
Prilog C: Instalacija SIPp generatora saobra ćaja
Generator saobraćaja/poziva SIPp predstavlja testni alat sa za SIP protokol. Instalacija
ovog alata je izvršena na operativnom sistemu Ubuntu 10.04 LTS. Za ispravnu instalaciju
potrebni su određeni instalacioni paketi koji se instaliraju kroz terminal. Instalacija
potrebnih paketa je opisana u nastavku.
• Instalacija OpenSSL-a
Prvo je potrebno preuzeti OpenSSL sa web stranice http://www.openssl.org unošenjem
sljedeće naredbe u terminal:
# wget –m –nd http://www.openssl.org/source/openssl -1.0.0c.tar.gz
Nakon preuzimanja OpenSSL-a potrebno je preuzeti MD5 hash za verifikaciju integriteta
preuzetih datoteka.
# wget http://www.openssl.org/source/openssl-1.0.0c .tar.gz.md5
# md5sum openssl-1.0.0c.tar.gz
# cat openssl-1.0.0c.tar.gz.md5
Posljednje dvije naredbe generišu dva niza alfa – numeričkih karaktera. Ova dva niza
moraju biti identična, čime se indicira da su datoteke ispravno preuzete. Zatim treba
ekstraktovati datoteke iz preuzetog paketa:
# tar –xvzf openssl-1.0.0c.tar.gz
Dalje treba ući u direktorij gdje su datoteke ekstraktovane:
# cd openssl-1.0.0c
Sljedećom naredbom se vrši konfiguracija OpenSSL-a:
# ./config --prefix=/usr/local/openssl--openssldir= /usr/local/openssl
Nakon toga se vrši kompajliranje i instaliranje OpenSSL-a:
# make
# make install
Nakon ispravne instalacije OpenSSL-a, pokreće se naredba:
# apt-get install libssl-dev
109
• Instalacija SIPp-a
U novom terminalu potrebno je unijeti sljedeće naredbe:
# sudo apt-get install ncurses-dev
# sudo apt-get install build essential
Zatim treba preuzeti verziju SIPp-a 3.2 s web stranice: http://sourceforge.net:
# wget –m –nd http://sourceforge.net/projects/sipp/ files/sipp/3.2/sipp.svn.tar.gz
Nakon preuzimanja SIPp-a potrebno je ekstraktovati datoteke iz preuzetog paketa:
# tar –xzf sipp.svn.tar.gz
Treba ući u direktorij gdje su datoteke ekstraktovane:
# cd sipp.svn
Dalje, treba unijeti u terminalu sljedeću naredbu:
# gedit scenario.hpp
Nakon što se otvori ovaj dokument treba dodati liniju # include <limits.h > poslije
# include <sys/socket.h > i sačuvati datoteku.
Da bi omogućili SIPp-u automatsko odgovaranje na OPTIONS poruku, koja se također
često koristi prilikom komuniciranja po protokolu SIP, potrebno je unijeti u terminalu
sljedeću naredbu kako bi modificirali call.cpp datoteku:
# gedit call.cpp
Nakon što se otvori ovaj dokument treba promijeniti:
>> else if (((strcmp(P_recv,“INFO“)==0) || (strcmp(P_ recv,“NOTIFY“)==0))
|| (strcmp(P_recv,“UPDATE“)==0))
u
>> else if (((strcmp(P_recv,“INFO“)==0) || (strcmp(P_ recv,“NOTIFY“)==0))
|| (strcmp(P_recv,“UPDATE“)==0) || (strcmp(P_recv,“ OPTIONS“)==0))
Zatim, treba sačuvati datoteku te u terminal unijeti:
# make ossl
Nakon ovoga, SIPp je uspješno instaliran te je spreman za upotrebu.
110
Prilog D: XML skripte
Prilog D prikazuje skripte potrebne za ispravno funkcionisanje SIPp generatora.
• XML skripta za registraciju korisnika Alice ( non_em_reg_alice.xml)
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="registration">
<send retrans="500">
<![CDATA[
REGISTER sip:open-ims.test SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];br anch=[branch]
Max-Forwards: 20
From: "alice" <sip:[email protected]>;tag=[call_n umber]
To: "alice" <sip:[email protected]>
P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id -3gpp=C359A3913B20E
Call-ID: reg///[call_id]
CSeq: 1 REGISTER
Contact: <sip:alice@[local_ip]:[local_port]>
Expires: 300
Content-Length: 0
User-Agent: Sipp v1.1-TLS, version 20061124
Authorization: Digest username="[email protected] ", realm="open-ims.test"
Supported: path
]]>
</send>
<recv response="401" auth="true" rtd="true">
<action>
<ereg regexp=".*" search_in="hdr" header="Service-R oute" assign_to="1" />
</action
</recv>
<send retrans="500">
<![CDATA[
REGISTER sip:open-ims.test SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];br anch=[branch]
Route: [$1]
Max-Forwards: 20
111
From: "alice" <sip:[email protected]>;tag=[call_n umber]
To: "alice" <sip:[email protected]>
P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id -3gpp=C359A3913B20E
Call-ID: reg///[call_id]
CSeq: 2 REGISTER
Contact: <sip:alice@[local_ip]:[local_port]>
Expires: 300
Content-Length: 0
User-Agent: Sipp v1.1-TLS, version 20061124
[authentication [email protected] passwo rd=alice]
Supported: path
]]>
</send>
<recv response="200">
</recv>
<ResponseTimeRepartition value="10, 20"/>
<CallLengthRepartition value="10"/>
</scenario>
• XML skripta za registraciju korisnika Bob ( non_em_reg_bob.xml)
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="registration">
<send retrans="500">
<![CDATA[
REGISTER sip:open-ims.test SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];br anch=[branch]
Max-Forwards: 20
From: "bob" <sip:[email protected]>;tag=[call_numbe r]
To: "bob" <sip:[email protected]>
P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id -3gpp=C359A3913B20E
Call-ID: reg///[call_id]
CSeq: 1 REGISTER
Contact: <sip:bob@[local_ip]:[local_port]>
Expires: 3600
Content-Length: 0
User-Agent: Sipp v1.1-TLS, version 20061124
Authorization: Digest username="[email protected]", realm="open-ims.test"
Supported: path
112
]]>
</send>
<recv response="401" auth="true" rtd="true">
<action>
<ereg regexp=".*" search_in="hdr" header="Service-R oute" assign_to="1" />
</action>
</recv>
<send retrans="500">
<![CDATA[
REGISTER sip:open-ims.test SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];br anch=[branch]
Route: [$1]
Max-Forwards: 20
From: "bob" <sip:[email protected]>;tag=[call_numbe r]
To: "bob" <sip:[email protected]>
P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id -3gpp=C359A3913B20E
Call-ID: reg///[call_id]
CSeq: 2 REGISTER
Contact: <sip:bob@[local_ip]:[local_port]>
Expires: 3600
Content-Length: 0
User-Agent: Sipp v1.1-TLS, version 20061124
[authentication [email protected] password =bob]
Supported: path
]]>
</send>
<recv response="200">
</recv>
<ResponseTimeRepartition value="10, 20"/>
<CallLengthRepartition value="10"/>
</scenario>
Pokretanjem skripte uas_b2a.xml u terminalu, Alice očekuje pozive na portu 3061 koji
dolaze od korisnika Bob.
• XML skripta uas_b2a.xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="simple IMS session setup, server-si de">
113
<recv request="INVITE">
</recv>
<send>
<![CDATA[
SIP/2.0 180 Ringing
[last_Via:]
[last_Record-Route:]
[last_From:]
[last_To:];tag=[call_number]
[last_Call-ID:]
[last_CSeq:]
Contact: <sip:alice@[local_ip]:[local_port]>
Content-Length: 0
]]>
</send>
<pause milliseconds="2000"/>
<send retrans="500">
<![CDATA[
SIP/2.0 200 OK
[last_Via:]
[last_Record-Route:]
[last_From:]
[last_To:];tag=[call_number]
[last_Call-ID:]
[last_CSeq:]
Contact: <sip:alice@[local_ip]:[local_port]>
Allow: INVITE,REGISTER,ACK,BYE,INFO,REFER,NOTIFY,SU BSCRIBE,MESSAGE,CANCEL
Content-Type: application/sdp
Content-Length: [len]
v=0
o=- 53655765 2353687637 IN IP4 [local_ip]
s=-
c=IN IP4 [media_ip]
t=0 0
m=audio 40000 RTP/AVP 8 0 18
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
]]>
</send>
114
<recv request="ACK" crlf="true">
</recv>
<recv request="BYE">
</recv>
<send>
<![CDATA[
SIP/2.0 200 OK
[last_Via:]
[last_From:]
[last_To:]
[last_Call-ID:]
[last_CSeq:]
Content-Length: 0
]]>
</send>
</scenario>
Pokretanjem skripte non_uac_b2a.xml korisnik Bob generiše pozive prema korisniku Alice
i terminira iste.
• XML skripta non_uac_b2a.xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="Simple IMS Session Setup, client-si de">
<send retrans="500">
<![CDATA[
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];br anch=[branch]
Max-Forwards: 20
Route: <sip:[email protected]:6060;lr>
P-Preferred-Identity: <sip:[email protected]>
Privacy: none
P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id -3gpp=C359A3913B20E
From: <sip:[email protected]>;tag=[call_number]
To: <[email protected]>
Call-ID: [call_id]
CSeq: 10 INVITE
Supported: 100rel, geolocation
Contact: <sip:bob@[local_ip]:[local_port]>
115
User-Agent: Sipp v1.1-TLS, version 20061124
Allow: ACK, BYE, CANCEL, INVITE, REFER, OPTIONS, IN FO, REGISTER, NOTIFY, UPDATE, SUBSCRIBE, PRACK
content-type: multipart/mixed; boundary=abracadabra
Geolocation: <cid:[email protected]>;inserted-by= "[email protected]";used-for-routing,routing-allowed="yes"
Content-Length: [len]
--abracadabra
MIME-Version: 1.0
Content-Type: application/sdp
Content-Transfer-Encoding: 8 bit
v=0
o=user1 53655765 2353687637 IN IP4 [local_ip]
s=-
c=IN IP4 [local_ip]
t=0 0
m=audio 30000 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=sendrec
--abracadabra
MIME-Version: 1.0
Content-Type: application/pidf+xml
Content-ID: [email protected]
Content-Transfer-Encoding: 8bit
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10 "
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10 :civicAddr"
xmlns:gml="urn:opengis:specification:gml:schema -xsd:feature:v3.0"
entity="sip:[email protected]">
<tuple id="234142">
<status>
<gp:geopriv>
<gp:location-info>
<civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicA ddr">
<country>US</country>
<A1>NJ</A1>
<A3>Atlantic City</A3>
<A6>Main st.</A6>
<HNO>1214</HNO>
116
<PC>10027</PC>
</civicAddress>
</gp:location-info>
<gp:method>Manual</gp:method>
</gp:geopriv>
</status>
<contact priority="0.8">sip:[email protected]:5 060</contact>
<timestamp>2005-09-26T15:57:34-04:00</timestamp>
</tuple>
</presence>
--abracadabra--
]]>
</send>
<recv response="100" optional="true">
</recv>
<recv response="180" optional="true">
</recv>
<recv response="403" optional="true" next="1">
</recv>
<recv response="404" optional="true" next="1">
</recv>
<recv response="408" optional="true" next="1">
</recv>
<recv response="200" rrs="true">
</recv>
<send crlf="true">
<![CDATA[
ACK [next_url] SIP/2.0
[last_Via:]
Max-Forwards: 20
[routes]
From: <sip:[email protected]>;tag=[call_number]
[last_To:]
Call-ID: [call_id]
CSeq: 10 ACK
Content-Length: 0
]]>
</send>
<pause milliseconds="5000" crlf="true" />
<send retrans="500">
117
<![CDATA[
BYE sip:[next_url] SIP/2.0
[last_Via:]
Max-Forwards: 20
[routes]
From: <sip:[email protected]>;tag=[call_number]
[last_To:]
Call-ID: [call_id]
CSeq: 11 BYE
Contact: <sip:bob@[local_ip]:[local_port]>
Content-Length: 0
]]>
</send>
<recv response="200" crlf="true" next="2">
</recv>
<label id="1"/>
<send crlf="true">
<![CDATA[
ACK sip:[email protected] SIP/2.0
[last_Via:]
Max-Forwards: 20
From: <sip:[email protected]>;tag=[call_number]
[last_To:]
Call-ID: [call_id]
CSeq: 10 ACK
Content-Length: 0
]]>
</send>
<label id="2"/>
<!-- definition of the response time repartition ta ble (unit is ms) -->
<ResponseTimeRepartition value="10, 20"/>
<!-- definition of the call length repartition tabl e (unit is ms) -->
<CallLengthRepartition value="10"/>
</scenario>
118
Prilog E: Programski kodovi
Prilog E prikazuje programske kodove za implementaciju QoE modula, GUI-a za
subjektivno ocjenjivanje kvaliteta usluge i modula za unošenje informacija o spolu i
dobnoj skupini korisnika u okviru UCT IMS klijentske aplikacije.
• Kreiranje QoE modula
hboxqoe = gtk_hbox_new (FALSE, 0);
gtk_widget_show (hboxqoe);
gtk_container_add (GTK_CONTAINER (IPTV_Advanced), hboxqoe);
frameqoe = gtk_frame_new (NULL);
gtk_widget_show (frameqoe);
gtk_box_pack_start (GTK_BOX (hboxqoe), frameqoe, TRUE, TRUE, 0);
gtk_container_set_border_width (GTK_CONTAINER (fr ameqoe), 8);
alignmentqoe = gtk_alignment_new (0.5, 0.5, 1, 1) ;
gtk_widget_show (alignmentqoe);
gtk_container_add (GTK_CONTAINER (frameqoe), alig nmentqoe);
gtk_alignment_set_padding (GTK_ALIGNMENT (alignme ntqoe), 0, 0, 12, 0);
user_rating = gtk_label_new ("Your ratings:\n\tCo ntent -.-%\n\tNot Content: -.-%\n\tMOS rate: -.-\n\nAverage ratings:\ n\tContent: -.-%\n\tNot Content: -.-%\n\tMOS rate: -.-");
gtk_widget_show (user_rating);
gtk_container_add (GTK_CONTAINER (alignmentqoe), user_rating);
gtk_label_set_use_markup (GTK_LABEL (user_rating) , TRUE);
gtk_label_set_line_wrap (GTK_LABEL (user_rating), TRUE);
gtk_misc_set_alignment (GTK_MISC (user_rating), 0 , 0.02);
user_rating1 = gtk_label_new (_("<b>User Ratings< /b>"));
gtk_widget_show (user_rating1);
gtk_frame_set_label_widget (GTK_FRAME (frameqoe), user_rating1);
gtk_label_set_use_markup (GTK_LABEL (user_rating1 ), TRUE);
frameqoe1 = gtk_frame_new (NULL);
gtk_widget_show (frameqoe1);
gtk_box_pack_start (GTK_BOX (hboxqoe), frameqoe1, TRUE, TRUE, 0);
gtk_container_set_border_width (GTK_CONTAINER (fr ameqoe1), 8);
alignmentqoe1 = gtk_alignment_new (0.5, 0.5, 1, 1 );
gtk_widget_show (alignmentqoe1);
gtk_container_add (GTK_CONTAINER (frameqoe1), ali gnmentqoe1);
gtk_alignment_set_padding (GTK_ALIGNMENT (alignme ntqoe1), 0, 0, 12, 0);
119
user_rating2 = gtk_label_new ("Your ratings:\n\tS RD: -.-\n\tSDD: -.-\n\nAverage ratings:\n\tSRD: -.-\n\tSDD: -.-");
gtk_widget_show (user_rating2);
gtk_container_add (GTK_CONTAINER (alignmentqoe1), user_rating2);
gtk_label_set_use_markup (GTK_LABEL (user_rating2 ), TRUE);
gtk_label_set_line_wrap (GTK_LABEL (user_rating2) , TRUE);
gtk_misc_set_alignment (GTK_MISC (user_rating2), 0, 0.02);
user_rating3 = gtk_label_new (_("<b>SIP metrics</ b>"));
gtk_widget_show (user_rating3);
gtk_frame_set_label_widget (GTK_FRAME (frameqoe1) , user_rating3);
gtk_label_set_use_markup (GTK_LABEL (user_rating3 ), TRUE);
hboxdata = gtk_vbox_new (FALSE, 0);
gtk_widget_show (hboxdata);
gtk_box_pack_start (GTK_BOX (hboxqoe), hboxdata, TRUE, TRUE, 0);
get_data = gtk_button_new ();
gtk_widget_show (get_data);
gtk_box_pack_start (GTK_BOX (hboxdata), get_data, TRUE, TRUE, 0);
gtk_widget_set_size_request (get_data, 30, 30);
alignmentdata = gtk_alignment_new (0.5, 0.5, 0, 0 );
gtk_widget_show (alignmentdata);
gtk_container_add (GTK_CONTAINER (get_data), alig nmentdata);
hboxdata1 = gtk_vbox_new (FALSE, 2);
gtk_widget_show (hboxdata1);
gtk_container_add (GTK_CONTAINER (alignmentdata), hboxdata1);
data_label = gtk_label_new_with_mnemonic (_("Get Data"));
gtk_widget_show (data_label);
gtk_box_pack_start (GTK_BOX (hboxdata1), data_lab el, FALSE, FALSE, 0);
hboxwrite = gtk_vbox_new (FALSE, 0);
gtk_widget_show (hboxwrite);
gtk_box_pack_start (GTK_BOX (hboxqoe), hboxwrite, TRUE, TRUE, 0);
get_write = gtk_button_new ();
gtk_widget_show (get_write);
gtk_box_pack_start (GTK_BOX (hboxwrite), get_writ e, TRUE, TRUE, 0);
gtk_widget_set_size_request (get_write, 30, 30);
alignmentwrite = gtk_alignment_new (0.5, 0.5, 0, 0);
gtk_widget_show (alignmentwrite);
gtk_container_add (GTK_CONTAINER (get_write), ali gnmentwrite);
hboxwrite1 = gtk_vbox_new (FALSE, 2);
gtk_widget_show (hboxwrite1);
gtk_container_add (GTK_CONTAINER (alignmentwrite) , hboxwrite1);
write_label = gtk_label_new_with_mnemonic (_("Wri te Data"));
120
gtk_widget_show (write_label);
gtk_box_pack_start (GTK_BOX (hboxwrite1), write_l abel, FALSE, FALSE, 0);
qoe_label = gtk_label_new( ("QoE"));
gtk_widget_show (qoe_label);
gtk_notebook_set_tab_label (GTK_NOTEBOOK (IPTV_Ad vanced), gtk_notebook_get_nth_page (GTK_NOTEBOOK (IPTV_Advan ced), 8), qoe_label);
/**
*
*Kraj dodavanja novog interfejsa
*
**/
/**
*Dodano za QoE
*/
g_signal_connect ((gpointer) get_data, "clicked",
G_CALLBACK (on_get_data_clicked ),
NULL);
g_signal_connect ((gpointer) get_write, "clicked" ,
G_CALLBACK (on_get_write_clicke d),
NULL);
• Implementacija GUI-a za subjektivno ocjenjivanje kvaliteta usluge
GtkWidget* create_rating(void){
GtkWidget *rating;
GtkWidget *dialog_vbox;
GtkWidget *vbox;
GtkWidget *vbox1;
GtkWidget *vbox2;
GtkWidget *vbox3;
GtkWidget *vbox4;
GtkWidget *vbox5;
GtkWidget *frame;
GtkWidget *alignment;
GtkWidget *hbox;
GtkWidget *rat;
GtkWidget *button;
GtkWidget *button1;
GtkWidget *button2;
GtkWidget *button3;
GtkWidget *button4;
121
GtkWidget *button5;
GtkWidget *button6;
GtkWidget *button7;
GtkWidget *button8;
GtkWidget *ok_button;
GtkWidget *rating_question;
GtkWidget *mos_question;
GtkWidget *separator;
GSList *group_list;
GSList *group_list1;
rating = gtk_dialog_new();
gtk_widget_set_size_request (rating, 500, 400);
gtk_window_set_title (GTK_WINDOW (rating), _("Use r Rating"));
dialog_vbox = GTK_DIALOG (rating)->vbox;
gtk_widget_show (dialog_vbox);
vbox = gtk_vbox_new (FALSE, 0);
gtk_widget_show (vbox);
gtk_box_pack_start (GTK_BOX (dialog_vbox), vbox, TRUE, TRUE, 0);
rat = gtk_label_new ("Call ended\nPlease take a m oment and rate quality of conversation");
gtk_widget_show (rat);
gtk_box_pack_start (GTK_BOX (vbox), rat, TRUE, TR UE, 0);
gtk_widget_set_size_request (rat, 56, -1);
vbox1 = gtk_vbox_new (FALSE, 0);
gtk_container_set_border_width (GTK_CONTAINER (vb ox1), 10);
gtk_box_pack_start (GTK_BOX (vbox), vbox1, TRUE, TRUE, 0);
gtk_widget_show (vbox1);
rating_question = gtk_label_new ("Are you content with quality of conversation?");
gtk_widget_show (rating_question);
gtk_box_pack_start (GTK_BOX (vbox1), rating_quest ion, TRUE, TRUE, 0);
gtk_widget_set_size_request (rating_question, 56, -1);
hbox = gtk_hbox_new (FALSE, 0);
gtk_container_set_border_width (GTK_CONTAINER (hb ox), 10);
gtk_box_pack_start (GTK_BOX (vbox), hbox, TRUE, T RUE, 0);
gtk_widget_show (hbox);
button = gtk_radio_button_new_with_label (NULL, " N/A");
gtk_box_pack_start (GTK_BOX (hbox), button, TRUE, TRUE, 0);
gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON ( button), TRUE);
gtk_widget_show (button);
group_list = gtk_radio_button_get_group (GTK_RADI O_BUTTON (button));
122
button1 = gtk_radio_button_new_with_label(group_l ist, "No");
gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON ( button1), FALSE);
gtk_box_pack_start (GTK_BOX (hbox), button1, TRUE , TRUE, 0);
gtk_widget_show (button1);
button2 = gtk_radio_button_new_with_label_from_wi dget(GTK_RADIO_BUTTON (button1), "Yes");
gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON ( button2), FALSE);
gtk_box_pack_start (GTK_BOX (hbox), button2, TRUE , TRUE, 0);
gtk_widget_show (button2);
vbox1 = gtk_vbox_new (FALSE, 0);
gtk_container_set_border_width (GTK_CONTAINER (vb ox1), 10);
gtk_box_pack_start (GTK_BOX (vbox), vbox1, TRUE, TRUE, 0);
gtk_widget_show (vbox1);
mos_question = gtk_label_new ("Please rate qualit y of your conversation (1=worst...5=best)");
gtk_widget_show (mos_question);
gtk_box_pack_start (GTK_BOX (vbox1), mos_question , TRUE, TRUE, 0);
gtk_widget_set_size_request (mos_question, 56, -1 );
hbox = gtk_hbox_new (FALSE, 0);
gtk_container_set_border_width (GTK_CONTAINER (hb ox), 10);
gtk_box_pack_start (GTK_BOX (vbox), hbox, TRUE, T RUE, 0);
gtk_widget_show (hbox);
button3 = gtk_radio_button_new_with_label (NULL, "N/A");
gtk_box_pack_start (GTK_BOX (hbox), button3, TRUE , TRUE, 0);
gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON ( button3), TRUE);
gtk_widget_show (button3);
group_list1 = gtk_radio_button_group (GTK_RADIO_B UTTON (button3));
button4 = gtk_radio_button_new_with_label(group_l ist1, "1");
gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON ( button4), FALSE);
gtk_box_pack_start (GTK_BOX (hbox), button4, TRUE , TRUE, 0);
gtk_widget_show (button4);
button5 = gtk_radio_button_new_with_label_from_wi dget(GTK_RADIO_BUTTON (button4), "2");
gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON ( button5), FALSE);
gtk_box_pack_start (GTK_BOX (hbox), button5, TRUE , TRUE, 0);
gtk_widget_show (button5);
button6 = gtk_radio_button_new_with_label_from_wi dget(GTK_RADIO_BUTTON (button5), "3");
gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON ( button6), FALSE);
gtk_box_pack_start (GTK_BOX (hbox), button6, TRUE , TRUE, 0);
gtk_widget_show (button6);
123
button7 = gtk_radio_button_new_with_label_from_wi dget(GTK_RADIO_BUTTON (button6), "4");
gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON ( button7), FALSE);
gtk_box_pack_start (GTK_BOX (hbox), button7, TRUE , TRUE, 0);
gtk_widget_show (button7);
button8 = gtk_radio_button_new_with_label_from_wi dget(GTK_RADIO_BUTTON (button7), "5");
gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON ( button8), FALSE);
gtk_box_pack_start (GTK_BOX (hbox), button8, TRUE , TRUE, 0);
gtk_widget_show (button8);
vbox1 = gtk_vbox_new (FALSE, 0);
gtk_container_set_border_width (GTK_CONTAINER (vb ox1), 10);
gtk_box_pack_start (GTK_BOX (vbox), vbox1, TRUE, TRUE, 0);
gtk_widget_show (vbox1);
ok_button = gtk_button_new_from_stock ("gtk-ok");
gtk_widget_show (ok_button);
gtk_dialog_add_action_widget (GTK_DIALOG (rating) , ok_button, GTK_RESPONSE_OK);
GTK_WIDGET_SET_FLAGS (ok_button, GTK_CAN_DEFAULT) ;
gtk_box_pack_start (GTK_BOX (vbox1), ok_button, T RUE, TRUE, 0);
gtk_widget_show (ok_button);
//gtk_widget_show (rating);
g_signal_connect ((gpointer) ok_button, "clicked" ,
G_CALLBACK (close_rating),
NULL);
g_signal_connect ((gpointer) button, "clicked",
G_CALLBACK (na_rating),
NULL);
g_signal_connect ((gpointer) button1, "clicked",
G_CALLBACK (no_rating),
NULL);
g_signal_connect ((gpointer) button2, "clicked",
G_CALLBACK (yes_rating),
NULL);
g_signal_connect ((gpointer) button3, "clicked",
G_CALLBACK (na_mos),
NULL);
g_signal_connect ((gpointer) button4, "clicked",
G_CALLBACK (mos1),
NULL);
g_signal_connect ((gpointer) button5, "clicked",
124
G_CALLBACK (mos2),
NULL);
g_signal_connect ((gpointer) button6, "clicked",
G_CALLBACK (mos3),
NULL);
g_signal_connect ((gpointer) button7, "clicked",
G_CALLBACK (mos4),
NULL);
g_signal_connect ((gpointer) button8, "clicked",
G_CALLBACK (mos5),
NULL);
GLADE_HOOKUP_OBJECT_NO_REF (rating, rating, "rati ng");
return rating;
}
• Implementacija modula za unošenje informacija o spolu i dobnoj skupini
korisnika
GtkWidget *age_question;
GtkWidget *age_text;
GtkWidget *gender_text;
GtkWidget *age_select;
GtkWidget *gender_select;
age_question = gtk_label_new (_("information about yourself"));
gtk_widget_show (age_question);
gtk_table_attach (GTK_TABLE (table9), age_questio n, 1, 2, 0, 1,
(GtkAttachOptions) (GTK_FILL),
(GtkAttachOptions) (0), 0, 0);
gtk_label_set_justify (GTK_LABEL (age_question), GTK_JUSTIFY_RIGHT);
gtk_misc_set_alignment (GTK_MISC (age_question), 0, 0.5);
age_select = gtk_combo_box_new_text ();
gtk_widget_show (age_select);
gtk_table_attach (GTK_TABLE (table9), age_select, 1, 2, 1, 2,
(GtkAttachOptions) (GTK_FILL),
(GtkAttachOptions) (0), 0, 0);
gtk_combo_box_append_text (GTK_COMBO_BOX (age_sel ect), _("14 years or less"));
gtk_combo_box_append_text (GTK_COMBO_BOX (age_sel ect), _("15 - 18 years"));
gtk_combo_box_append_text (GTK_COMBO_BOX (age_sel ect), _("19 - 23 years"));
125
gtk_combo_box_append_text (GTK_COMBO_BOX (age_sel ect), _("24 - 40 years"));
gtk_combo_box_append_text (GTK_COMBO_BOX (age_sel ect), _("41 years or more"));
gender_select = gtk_combo_box_new_text ();
gtk_widget_show (gender_select);
gtk_table_attach (GTK_TABLE (table9), gender_sele ct, 1, 2, 2, 3,
(GtkAttachOptions) (GTK_FILL),
(GtkAttachOptions) (0), 0, 0);
gtk_combo_box_append_text (GTK_COMBO_BOX (gender_ select), _("female"));
gtk_combo_box_append_text (GTK_COMBO_BOX (gender_ select), _("male"));
age_question = gtk_label_new (_("Please fill out so me general"));
gtk_widget_show (age_question);
gtk_table_attach (GTK_TABLE (table9), age_questio n, 0, 1, 0, 1,
(GtkAttachOptions) (GTK_FILL),
(GtkAttachOptions) (0), 0, 0);
gtk_label_set_justify (GTK_LABEL (age_question), GTK_JUSTIFY_RIGHT);
gtk_misc_set_alignment (GTK_MISC (age_question), 0, 0.5);
age_text = gtk_label_new (_("Age:"))
gtk_widget_show (age_text);
gtk_table_attach (GTK_TABLE (table9), age_text, 0 , 1, 1, 2,
(GtkAttachOptions) (GTK_FILL),
(GtkAttachOptions) (0), 0, 0);
gtk_label_set_justify (GTK_LABEL (age_text), GTK_ JUSTIFY_RIGHT);
gtk_misc_set_alignment (GTK_MISC (age_text), 0, 0 .5);
gender_text = gtk_label_new (_("Gender:"));
gtk_widget_show (gender_text);
gtk_table_attach (GTK_TABLE (table9), gender_text , 0, 1, 2, 3,
(GtkAttachOptions) (GTK_FILL),
(GtkAttachOptions) (0), 0, 0);
gtk_label_set_justify (GTK_LABEL (gender_text), G TK_JUSTIFY_RIGHT);
gtk_misc_set_alignment (GTK_MISC (gender_text), 0 , 0.5);
