Prototip suradnje između davatelja usluge i mrežnog Srebot diplomski 2018.pdf · Kooperativne metode upravljanja QoE-om ... Prvi studijski slučaj su igre zasnovane na računalnom

SVEUČILIŠTE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

DIPLOMSKI RAD br. 1748

Prototip suradnje između davatelja usluge i mrežnog

operatora na temelju razmjene odabranih informacija

Sven Srebot

Zagreb, lipanj 2018.

Sadržaj

Uvod ........................................................................................................................................................ 1

1. Upravljanje iskustvenom kvalitetom korisnika ................................................................................... 3

1.1 Definicija iskustvene kvalitete ....................................................................................................... 3

1.2 Modeliranje QoE-a ........................................................................................................................ 4

1.3 Praćenje QoE-a .............................................................................................................................. 5

1.4 Upravljanje QoE-om ...................................................................................................................... 6

2. Iskustvena kvaliteta (QoE) ................................................................................................................... 9

2.1 QoE za igre zasnovane na računalnom oblaku .............................................................................. 9

2.2 QoE za usluge prilagodljivog strujanja videa ............................................................................... 14

2.2.1 Tehnologija prilagodljivog strujanja DASH ........................................................................... 15

2.2.2 Faktori koji utječu na iskustvenu kvalitetu prilagodljivog strujanja ..................................... 16

3. Kooperativne metode upravljanja QoE-om....................................................................................... 18

3.1 Motivacija mrežnih operatora za suradnju s davateljima usluga ................................................ 19

3.2 Motivacija davatelja usluga za suradnju s mrežnim operatorima ............................................... 20

4. Model prototipa suradnje između davatelja usluge i mrežnog operatora ....................................... 22

5. Implementacija prototipa .................................................................................................................. 24

5.1 Funkcijski zahtjevi ........................................................................................................................ 24

5.2 Tehnička izvedba ......................................................................................................................... 25

5.3 Modul za dostavu mrežnih metrika od ISP-a do OTT-a ............................................................... 28

5.4 Komunikacijski modul klijenta za igranje zasnovano na računalnom oblaku ............................. 29

5.5 QoE optimizacijska funkcija ......................................................................................................... 32

5.5.1 Modul zadužen za komunikaciju s klijentima ....................................................................... 33

5.5.2 Aplikacijsko programsko sučelje ........................................................................................... 33

5.5.3 Optimizacijska funkcija ......................................................................................................... 35

6. Ispitivanje doprinosa prototipa u upravljanju iskustvenom kvalitetom ........................................... 40

6.1 Metodologija testiranja i analiza rezultata izvođenja kod igara zasnovanih na računalnom

oblaku ................................................................................................................................................ 40

6.2 Metodologija testiranja i analiza rezultata testiranja usluge YouTube ....................................... 42

Zaključak ................................................................................................................................................ 47

Literatura ............................................................................................................................................... 48

Sažetak................................................................................................................................................... 52

Summary ............................................................................................................................................... 53

Skraćenice .............................................................................................................................................. 54

Dodatak ................................................................................................................................................. 55

Upute za korištenje programske podrške ......................................................................................... 55

1

Uvod

Internet je globalni sustav međusobno povezanih računalnih mreža koji omogućava

povezivanje uređaja na različitim krajevima svijeta, te razmjenu informacija različitog formata

između tih uređaja. Popularnost i upotrebljivost Interneta čine ga neizbježnim sredstvom u

gotovo svim granama ljudske djelatnosti. Odnedavno je računarska znanost ušla u Zettabyte

eru, što znači da je ukupan IP promet premašio jedan zettabyte (𝑍𝑒𝑡𝑡𝑎𝑏𝑦𝑡𝑒 = 1021 𝐵𝑦𝑡𝑒𝑠)

[1].

Ukupan IP promet 2016. godine iznosio je 96 EB (𝐸𝑥𝑎𝑏𝑦𝑡𝑒 = 1018 𝐵𝑦𝑡𝑒𝑠 ) mjesečno, a do

2021. godine očekuje se rast ukupnog mjesečnog IP prometa na čak 278 EB [1]. Pretpostavka

rasta IP prometa prikazana je na slici (Slika 1).

Slika 1 Pretpostavka rasta mjesečnog IP prometa [1]

Većina tog prometa otpada na Over The Top (OTT) usluge kojima se prenosi video sadržaj, dok

su među najpoznatijim predstavnicima platforme za dostavu video sadržaja YouTube i Netflix

[2].

0

50

100

150

200

250

300

2016 2017 2018 2019 2020 2021

Exab

yte-

a m

jese

čno

Godina

IP promet [Exabyte-a mjesečno]

2

OTT je naziv za usluge koje se pružaju krajnjim korisnicima putem IP mrežne infrastrukture, a

nisu direktno omogućene od strane pružatelja Internet usluga, te stoga oni ne sudjeluju u

raspodjeli profita ostvarenih prodajom usluga [3], [4]. Drugi bitan entitet u Internetu je

pružatelj Internet usluga (engl. Internet Service Provider, ISP) koji je organizacija koja

omogućava usluge za pristup, korištenje i sudjelovanje u Internetu [5]. Jedan od najvećih

izazova za ISP-a je nadzor i upravljanje iskustvenom kvalitetom (engl. Quality of Experience,

QoE ) krajnjeg korisnika [7]. Načini upravljanja iskustvenom kvalitetom tema su ovog rada, te

će u njegovom nastavku biti detaljnije opisani.

Pojam QoE-a, kao i načini upravljanja QoE-om biti će opisani u prvom poglavlju rada. Značenje

QoE-a u specifičnim sustavima igara zasnovanih na strujanju videa i prilagodljivog strujanja

videa biti će opisani u drugom poglavlju ovog rada. Treće poglavlje sadrži opis kooperativnih

metoda upravljanja QoE-om. Četvrto poglavlje opisuje model prototipa suradnje između

davatelja usluge i mrežnog operatora na temelju razmjene odabranih informacija, dok peto

poglavlje opisuje način implementacije takvog sustava za specifičnu uslugu. Šesto poglavlje

opisuje provedena ispitivanja doprinosa prototipa u upravljanju iskustvenom kvalitetom, kao

i rezultate tog ispitivanja. Peto i šesto poglavlje opisuju dva studijska slučaja implementirana i

ispitana u laboratorijskom okruženju, te načine na koji su ona testirana i rezultate testiranja.

Jedan studijski slučaj odnosi se na moguću razmjenu informacija u sustavu igara zasnovanih

na računalnom oblaku (na primjeru usluge Steam), dok je drugi povezan s ispitivanjem rada

usluge prilagodljivog strujanja videa (na primjeru usluge YouTube). Na kraju rada dani su

zaključak i sažetak rada, kao i dodatak koji sadrži upute za konfiguriranje i korištenje prototipa

nastalog u sklopu ovog rada.

3

1. Upravljanje iskustvenom kvalitetom korisnika

Danas postoji mnogo načina na koje su krajnji korisnici uključeni u E2E (engl. End-to-End)

usluge bilo da su posluženi od strane računalnog oblaka, mrežnog operatora ili nekog drugog

izvora, te postoji tendencija očekivanja da cjelokupan sadržaj Interneta bude isporučen u

obliku usluge (engl. Internet of Services, IoS) [28]. Takva očekivanja dovode do potrebe za

prijenosom velike količine podataka putem Interneta, te se radi što učinkovitijeg posluživanja

korisnika Interneta kroz zadnjih nekoliko godina velika pažnja posvećuje istraživanjima unutar

domene QoE.

U cilju istraživanja, praćenja te u konačnici upravljanja iskustvenom kvalitetom krajnjeg

korisnika potrebno je razumjeti što je QoE, koji parametri utječu na QoE i na koji način. Osim

pronalaska parametara koji utječu na iskustvenu kvalitetu korisnika, za izgradnju sustava koji

uspješno upravlja QoE-om potrebno je razviti modele koji preslikavaju taj skup subjektivnih i

objektivnih parametara u QoE. Nakon navedenih aktivnosti moguće je praćenjem poremećaja

QoE-a i njihovog uzroka upravljati QoE-om, te ga zadržati u željenom rasponu.

1.1 Definicija iskustvene kvalitete

QoE je subjektivna metrika koja opisuje stupanj zadovoljstva ili iritiranosti korisnika pri

korištenju neke usluge. Rezultat je ispunjenja očekivanja koje korisnik ima od neke usluge, te

uzima u obzir korisnikovo trenutno raspoloženje i osobnost [7]. Povezana, ali različita, metrika

koja se često koristi prilikom opisivanja kvalitete određenog sustava je kvaliteta usluge (engl.

Quality of Service, QoS) koja se odnosi na determinističke i objektivne parametre vezane za

prijenos podataka putem Interneta kao što su gubitak paketa prilikom prijenosa, kašnjenje, te

propusnost mreže [8].

HTTP (engl. Hypertext Transfer Protocol) je protokol aplikacijske razine čija je glavna namjena

omogućavanje objavljivanja, prezentacije i prijenosa višemedijskog sadržaja putem Interneta

[33]. HTTPS (engl. Hypertext Transfer Protocol Secure) je protokol koji ima istu svrhu kao i

protokol HTTP, no zbog enkripcije koju koristi, pruža puno veću razinu sigurnosti pri prijenosu

4

podataka [34]. Prilikom prijenosa video sadržaja putem protokola HTTP na QoE utječu

parametri poput početnog kašnjenja (engl. Start-up delay), broj zastajkivanja videa (engl.

rebuffering) te kvalitete videa koja je ovisna o rezoluciji i brzini prijenosa. Klijent i OTT najčešće

imaju pristup ovim podacima, te mogu pretpostaviti uzroke smanjenja iskustvene kvalitete,

dok mrežni operatori nemaju pristup tim podacima te se moraju osloniti na mjerenja

provedena u mreži. U slučaju korištenja protokola HTTP većina potrebnih podataka koji

ukazuju na iskustvenu kvalitetu korisnika sustava spremljena je u zaglavljima HTTP paketa, što

je omogućavalo mrežnim operatorima pristup potrebnim podacima. Proteklih godina sve je

više u upotrebi protokol HTTPS, te je mrežnim operatorima pristup potrebnim podacima

ograničen. Postoje različiti načini na koje se pristupa rješavanju ovog problema. Moguće je

pronaći povezanost između mrežnih i klijentskih parametara u sustavu, što se najčešće postiže

uz pomoć strojnog učenja, te je tako moguće otkriti pogoršanja u mreži i na njih pravodobno

reagirati [11]. Također, jedan od načina je postizanje suradnje između OTT-a i ISP-a prilikom

koje bi se razmjenjivanjem određenih informacija postiglo poboljšanje QoE-a [6], [11].

1.2 Modeliranje QoE-a

Za izgradnju sustava koji uspješno upravlja iskustvenom kvalitetom potrebno je pronaći

parametre koji utječu na QoE, te razviti modele koji preslikavaju skup subjektivnih i objektivnih

parametara u QoE. Korištenjem modela moguće je otkriti pogoršanja u mreži, te na njih

pravodobno reagirati. Prilikom modeliranja QoE-a potrebno je predstaviti QoE u ovisnosti o

parametrima koji utječu na kvalitetu sadržaja kojom je klijent poslužen [35].

Praćenje parametara moguće je obaviti na strani korisnika ili na strani mreže ovisno o

specifičnoj usluzi čiji se parametri prate, no neovisno o tome je li praćenje parametara

obavljeno na strani korisnika, ili na strani mreže, točne parametre koje je potrebno prikupiti

za vrijeme praćenja korisničke aktivnosti uvijek određuju QoE modeli napravljeni za uslugu

koja se promatra. Pronalazak povezanosti između mrežnih i klijentskih parametara u sustavu

najčešće se postiže uz pomoć strojnog učenja.

5

U sklopu ovog rada razmatraju se dva različita studijska slučaja za koje je način doživljavanja i

modeliranja QoE-a značajno drugačiji. Prvi studijski slučaj su igre zasnovane na računalnom

oblaku, a drugi prilagodljivo strujanje videa, te će u idućem poglavlju biti detaljnije opisano što

QoE znači za igre zasnovane na računalnom oblaku, a što za usluge prilagodljivog strujanja

videa.

1.3 Praćenje QoE-a

Praćenje i dijagnosticiranje degradacije iskustvene kvalitete prilikom korištenja OTT usluga

prijenosa video sadržaja bitna je aktivnost za pružatelja Internet usluga koji pokušavaju

zadovoljiti visoke zahtjeve korisnika za brzim prijenosom video sadržaja bez zastajkivanja i

kašnjenja. Iako informacije bitne za utvrđivanje QoE-a mogu biti prikupljene na bilo kojoj

poziciji između pružatelja usluge i klijenta (Slika 1.1), najčešće se praćenje parametara odvija

na korisničkoj strani (engl. client-side monitoring) ili na strani mreže (engl. network-centric

monitoring). Prikupljanje podatak i izračun QoE-a na temelju prikupljenih podataka potrebno

je obavljati u stvarnom vremenu (engl. real time), ili što je moguće bliže obavljanju u stvarnom

vremenu [6], [27].

Slika 1.3.1 Informacije bitne za određivanje QoE dostupne na putu razmjene informacija između klijenta i servera [6]

6

Davatelj OTT usluge najčešće provodi praćenje parametara koji utječu na QoE na korisničkoj

ili uslužnoj strani. Takvo praćenje donosi pouzdane i točne podatke koje je korištenjem modela

tada moguće pretvoriti u QoE mjeru. S druge strane, mrežni operator (ISP) procjenjuje QoE

mjerenjima mrežnog prometa. Većina prometa OTT usluga danas je kriptirana, te zbog toga

praćenje performansi koje utječu na QoE predstavlja izazov mrežnim operatorima. Zbog

različitih uređaje koje korisnici upotrebljavaju, različitih operacijskih sustava, te različitih

usluga i protokola koje korisnici prilikom komunikacije upotrebljavaju, predviđanje QoE-a

zasnovano na proučavanju mreže najčešće je iskoristivo samo za specifične scenarije za koje

je praćenje QoE-a namijenjeno [6].

1.4 Upravljanje QoE-om

Načini posluživanja korisnika uslugama Interneta donedavno su bili utemeljeni isključivo na

parametrima QoS-a. U novijoj prošlosti fokus istraživanja i načina rješavanja problema postao

je više usmjeren prema krajnjem korisniku te njegovoj percepciji kvalitete usluge, odnosno

predmet promatranja postao je QoE [10].

Upravljanje QoE-om može se obavljati na dva različita načina (Slika 1.3.1): upravljanje na razini

mreže (engl. network management) i upravljanje na razini aplikacije (engl. application

management). Neovisno o načinu upravljanja QoE-om, njegov cilj je zadržati QoE svakog

korisnika unutar zadovoljavajućih granica raspodjeljujući pritom resurse na efikasan način ili

prilagođavajući uslugu mogućnostima krajnjeg korisnika. Upravljanje na razini mreže je

temeljeno na nadzoru i upravljanju samom mrežom, dok se pri upravljanju na razini aplikacije

kvaliteta i performanse usluge Interneta prilagođavaju na klijentskoj strani kroz korištenu

aplikaciju.

7

Slika 1.4.1 Upravljanje na razini mreže i upravljanje na razini aplikacije [6]

Popularne OTT usluge temeljene na prijenosu videa prilagođavaju uslugu trenutnim uvjetima

u mreži tako što pri promjeni uvjeta u mreži pokreću prilagodbu trenutnim uvjetima, te tako

smanjuju zastajkivanje i kašnjenje prilikom isporuke sadržaja. Upravljanje na razini mreže koje

je temeljeno na QoE-u može uzimati u obzir povratne informacije korisnika o načinu na koji je

poslužen, ili može svoj rad temeljiti isključivo na podacima koji se za vrijeme posluživanja

prikupljaju iz mreže.

Usluge koje su danas popularne i najviše zastupljene u Internetu često zahtijevaju jako brze i

složene izračune koji se izvode u stvarnom vremenu. Takve usluge, koje postavljaju jako visoke

memorijske i procesorske zahtjeve na računalo na kojemu se izvode, najčešće su poslužene

korisniku od strane računalnog oblaka. Izvođenje u oblaku dovodi do velikog smanjenja

zahtjeva na korisničko računalo, ali u isto vrijeme i do visokih zahtjeva na mrežnu

infrastrukturu koja, kako bi zadovoljila visoke zahtjeve korisnika, mora prenijeti iznimno veliku

količinu sadržaja u kratkom vremenu. Prijenos sadržaja usluga, kao što su igranje igara, usluge

zasnovane na razgovoru u stvarnom vremenu, ili gledanje video sadržaja preko Interneta, jako

je osjetljiv na kašnjenje, te kašnjenja u dostavljanju sadržaja koja su veća od 250 ms, kod

velikog broja takvih usluga, u velikoj mjeri smanjuju QoE [12].

Uz tako visoke zahtjeve i malu marginu za pogreške postoji potreba za što efikasnijim načinom

upravljanja QoE-om. Postojeći sustavi koji se koriste u praksi najčešće su bazirani na praćenju

8

određenih parametara na strani poslužitelja, preslikavanja tih parametara u QoE koristeći

modele, te upravljanju mrežnim resursima na temelju tih modela. Drugi pristup je praćenje

parametara na strani klijenta, te upravljanje sustavom na razini aplikacije. Takav način

specifičan je za svaku uslugu, te nije globalno iskoristiv. Oba opisana pristupa potencijalno su

ograničeni i neoptimalni zbog nedostatka razmjene informacija, odnosno komunikacije

između sustava koji sudjeluju u dostavljanju i korištenju podataka [12], [31].

Sustavi u kojima postoji razmjena informacija između različitih entiteta sustava su

kooperativni. Kooperativni sustavi idejno rade tako da prilikom korištenja usluge od strane

klijenta ISP i OTT međusobno komuniciraju. Ta komunikacija se može obavljati u oba smjera,

te može razmjenjivati različite podatke ovisno o potrebi. OTT u takvoj komunikaciji za cilj ima

povećati QoE korisnika, te time povećati kvalitetu svoje usluge, dok ISP za cilj ima što

učinkovitije upravljanje mrežnim resursima.

Kooperativne metode upravljanja iskustvenom kvalitetom, različite varijacije tih metoda, te

načini razmjene informacija i sadržaj razmijenjenih podataka detaljnije su opisani u nastavku

ovog rada.

9

2. Iskustvena kvaliteta (QoE)

Centralna tema ovog rada je upravljanje iskustvenom kvalitetom. U radu je pozornost

posvećena kooperativnim metodama upravljanja iskustvenom kvalitetom, i to specifično u

sustavima za igre zasnovane na računalnom oblaku, te za usluge prilagodljivog strujanja videa.

Kako opis kooperativnih metoda upravljanja iskustvenom kvalitetom bio moguć, potrebno je

definirati QoE, te njegovo značenje u specifičnim uslugama na koje se koncentrira ovaj rad.

Ovo poglavlje sadrži opis načina rada usluge igara zasnovanih na računalnom oblaku, te

značenje QoE-a u sklopu igara zasnovanih na računalnom oblaku, kao i opis usluga

prilagodljivog strujanja videa, te značenje QoE-a u okvirima takvih usluga.

2.1 QoE za igre zasnovane na računalnom oblaku

Računalni oblak (engl. Cloud) je računalni sustav koji na zahtjev omogućava prikladan mrežni

pristup dijeljenim i programirljivim računalnim sredstvima. Računalni oblak nudi pristup obilju

različitih računalnih sredstava i usluga kao što su: prostor za pohranu, poslužitelji, računalne

mreže, te različite aplikacije i usluge. Svako od tih računalnih sredstava i usluga mogu biti

zatraženi ili otpušteni od računalnog oblaka u bilo koje vrijeme uz minimalan napor korisnika,

što uz široku lepezu primjena i jednostavnost korištenja računalnog oblaka čini razloge njegove

popularnosti [14].

Igre zasnovane na računalnom oblaku mogu se podijeliti prema načinu rada i vrsti podataka

koje razmjenjuju na [14]:

• igre zasnovane na strujanju podataka, te

• igre zasnovane na strujanju videa.

Igre zasnovane na strujanju podataka koriste računalni oblak za distribuciju računalnih igara.

Potreba za ovom vrstom igara zasnovanih na računalnom oblaku postoji zato što moderne

računalne igre zauzimaju jako puno računalnog prostora za pohranu podataka, te ih je teško

smjestiti na jedan prijenosni medij za pohranu podataka. Igre zasnovane na strujanju podataka

omogućuju korisniku da već nakon preuzimanja malog dijela računalne igre započnu s njenim

10

igranjem, dok se ostatak igre preuzima u pozadini. Ovakav način igranja još uvijek zahtijeva da

igra (u konačnici) bude na korisnikovom računalu, te da korisnik ima dovoljno sposobno

računalo koje može pokretati potencijalno iznimno grafički i procesorski zahtjevne igre [14].

S druge strane, igre zasnovane na strujanju videa ne zahtijevaju od korisnika preuzimanje igre

prije njenog igranja, kao ni posjedovanje računala visokih performansi za igranje igara. To je

moguće zato što ovaj model sve procesorski zahtjevne matematičke i fizičke izračune, kao i

elemente umjetne inteligencije i konačno stvaranje slike prepušta računalnom oblaku. Tako

generirane slike, odnosno niz slika koje čine video šalje korisniku putem Interneta. Nakon toga

korisnik željenim naredbama utječe na video poslan od strane računalnog oblaka, nakon čega

se te naredbe šalju natrag računalnom oblaku koji ih obrađuje, te ponovno šalje video (u kojem

su sadržane posljedice njegovih naredbi) korisniku, nakon čega se taj proces ponavlja. Naredbe

koje korisnik šalje računalnom oblaku veličinom su zanemarive u odnosu na veličinu videa koji

računalni oblak šalje korisniku. U ovoj komunikaciji se od korisnika zahtijeva jedino

posjedovanje pouzdane Internetske veze te računala po izboru (osobno računalo, tablet ili

mobitel) koje može reproducirati primljeni video sadržaj. Komunikacija između klijenata i

poslužitelja prilikom korištenja igara zasnovanih na strujanju videa prikazana je na slici (Slika

3.1.1).

Osim igara zasnovanih na strujanju podataka i igara zasnovanih na strujanju videa postoje i

drugi pristupi ostvarenju igara zasnovanih na računalnom oblaku koji su srodni igrama

zasnovanim na strujanju videa, ali razlikuju se u raspodjeli posla između računalnog oblaka i

klijentskog računala. Grafičko strujanje (engl. Graphics streaming) ostvaruje se slanjem

grafičkih naredbi prema klijentu, koje se tada izvršavaju na korisničkom računalu. Odgođeno

stvaranje slike (engl. Post-rendering operations) pristup je pri kojem se slika djelomično stvara

na strani računalnog oblaka, ali se dio posla prosljeđuje korisničkom računalu. Oba pristupa

zahtijevaju puno veće performanse korisničkog računala nego igre zasnovane na strujanju

videa, što uz jednostavniju implementaciju igara zasnovanih na strujanju videa čini razloge

zbog kojih su oni najpopularnije i najčešće korišteno rješenje [14].

11

Slika 2.1.1 Komunikacija u sustavu igara zasnovanih na strujanju videa [14]

Ostvarenje visoke kvalitete usluge igranja zasnovanog na strujanju videa je iznimno zahtjevan

zadatak zato što korisnici imaju jako velika očekivanja, te im bilo kakva greška ili kašnjenje pri

igranju može značajno smanjiti iskustvenu kvalitetu. Također, moderne računale igre pri

svome izvođenju troše jako veliku količinu resursa računalnog oblaka, te često zahtijevaju brzo

vrijeme reakcije na određenu situaciju prilikom igranja zbog čega je pravovremena razmjena

informacija između poslužitelja i korisnika esencijalna za ostvarenje kvalitetne usluge. Korisnici

od računalnog oblaka zahtijevaju visoku kvalitetu virtualnih scena igre koje im se šalju, te

istovremeno traže neprimjetno kašnjenje pri reakciji poslužitelja na njihove naredbe.

Kašnjenje pri reakciji poslužitelja na korisničke naredbe odnosi se na vremensku razliku

između trenutka kada korisnik unese naredbu i trenutka kada se korisniku s poslužiteljske

strane vrati slika u koju je ukomponirana njegova naredba. Na kvalitetu virtualne scene koje

dolazi do korisnika utječu razni parametri, među kojima su [14]:

• Broj okvira u sekundi (engl. Frame rate) – video sadržaj stvara se visokom frekvencijom

izmjene slika. Broj okvira je veličina koja opisuje broj slika koje se izmjene u jedinici

vremena pri prikazivanju video sadržaja. Veći broj okvira u sekundi dovodi do veće

kvalitete videa. Broj okvira najčešće se mjeri u jedinici FPS (engl. Frames per second,

FPS).

• Rezolucija (engl. Resolution) – veličina kojom se definira mogućnost razdvajanja sitnih

detalja kojom se opisuje kakvoća slike. Veća rezolucija znači veću kvalitetu. Rezolucija

12

se najčešće mjeri u broju piksela od kojih je sastavljena slika. Utjecaj rezolucije prikazan

je na slici (Slika 3.1.2).

• Brzina video kodiranja (engl. Bitrate) – predstavlja broj bitova koji su obrađeni u jedinici

vremena. Bitrate video sadržaja označava količinu podataka na koju se kodira jedna

sekunda videa. Veći bitrate znači i veću kvalitetu videa, kao i više potrebnog prostora

za pohranu video sadržaja. Prilikom prijenosa video sadržaja putem mreže veći bitrate

za sobom povlači i potrebu za većom propusnosti mreže kako bi video bio ispravno

prenesen. Ako je bitrate videa veći od propusnosti mreže može doći do gubitka ili

kašnjenja pojedinih okvira video sadržaja, što dovodi do smanjenja njegove kvalitete.

Bitrate se mjeri u jedinici bit/s.

Slika 2.1.2 Utjecaj rezolucije slike na njenu kvalitetu (vrijednosti iznad pojedinih slika predstavljaju broj piksela od kojih je slika sastavljena) [14]

U dinamičkom sustavu u kojemu novi zahtjevi za igrom računalnom oblaku mogu pristići u

svakom trenutku, te postojeći zahtjevi mogu biti prekinuti u svakom trenutku, cilj računalnog

oblaka je maksimiziranje korisničkog iskustva. Gomilanjem novih zahtjeva prema računalnom

oblaku bez adekvatne prilagodbe posluživanja, odnosno bez odgovarajuće raspodjele mrežnih

resursa, dovest će do situacije u kojoj će računalni oblak pokušati poslužiti sve zahtjeve uz

maksimalnu kvalitetu videa čak i kada mrežni resursi postanu nedovoljni za posluživanje.

Ovakvo ponašanje dovesti će do opterećenja mreže, te će propusnost mreže postati

nedovoljna za adekvatno posluživanje svih zahtjeva, zbog čega će resursi dodijeljeni trenutno

postojećim igrama biti smanjeni te će se povećati broj izgubljenih i zakašnjelih paketa koji se

šalju. U slučaju daljnjeg pristizanja zahtjeva smanjuje se broj okvira koji se šalje korisnicima

kako bi rezolucija slike ostala zadovoljavajuća. Sve navedene promijene u načinu posluživanja

korisnika prilikom pristizanja velikog broja zahtjeva mogu dovesti do značajnog smanjenja

korisničkog iskustva igranja [14].

13

Posluživanje korisnika videom zadovoljavajuće kvalitete problem je koji je moguće

dekomponirati na tri međusobno povezana problema [14]:

• Mjerenje iskustvene kvalitete – Iskustvena kvaliteta je mjera zadovoljstva korisnika s

određenom uslugom. Mjerenje se provodi nad pojedinačnim korisnikom te se rezultati

subjektivnog zadovoljstva korisnika zbrajaju kako bi se dobila prosječna iskustvena

kvaliteta. Mean opinion score (MOS) je metrika koja kvantificira srednju vrijednost

mišljenja korisnika prilikom ispitivanja određenog testnog scenarija na brojčanoj skali

od 1 do 5. Ovaj način mjerenja kao rezultat daje brojčanu vrijednost zadovoljstva

korisnika određenom komponentom sustava, što omogućava računalnu iskoristivost

dobivenih podataka, koja je nužna pri rješavanju problema raspodjele mrežnih resursa

kod igara zasnovanih na strujanju videa [24]. MOS mjerenje zadovoljstva korisnika

igrama zasnovanim na računalnom oblaku moguće je provesti tako da se ispitanici

pojedinačno podvrgnu igranju igre u kontroliranim uvjetima u kojima je moguće

mijenjanje kvalitete posluživanja (npr. promjena bitrate-a, kašnjenja, rezolucije ili broja

okvira u sekundi). Korisnici igraju igru pri različitim kvalitetama posluživanja i uvjetima

u mreži, te nakon toga bilježe svoje zadovoljstvo iskustva igranja. Subjektivna iskustva

korisnika se nakon toga zbrajaju kako bi se dobila prosječna ocjena iskustvene kvalitete

za različite situacije u mreži.

• Kodiranje videa – Prilagođavanje načina kodiranja video sadržaja resursima koje želimo

dodijeliti pojedinoj sjednici između korisnika i računalnog oblaka procesorski je

zahtjevna operacija koje je ključna pri rješavanju problema raspodjele mrežnih resursa

računalnog oblaka. Ova prilagodba izvodi se upotrebom odgovarajućeg video kodeka,

koji propisuje način i kvalitetu kodiranja video sadržaja u svakoj situaciji u mreži.

• Raspodjela mrežnih resursa – Uz poznate rezultate mjerenja iskustvene kvalitete

korisnika pri različitim uvjetima u mreži, te uz postojeće kodeke koji su sposobni

kodirati video na željenu kvalitetu, moguće je svakom korisniku, ovisno o situaciji u

mreži i zahtjevima korisnika, pridijeliti određenu količinu mrežnih resursa. Ovim

postupkom omogućuje se istovremeno posluživanje velikog broja korisnika bez

znatnog smanjenja njihove iskustvene kvalitete uz čuvanje resursa koji su raspoloživi

računalnom oblaku.

14

Definiranje modela iskustvene kvalitete za svaku igru koja će biti dostupna na računalnom

oblaku važan je korak pri rješavanju problema raspodjele mrežnih resursa zato što promjena

kvalitete posluživanja za različite igre ima različit utjecaj na iskustvenu kvalitetu korisnika.

Primjerice, čak i mala promjena kvalitete posluživanja može jako utjecati na iskustvo igranja

dinamičke, akcijske igre koja zahtjeva puno interakcije s korisnikom, dok s druge strane čak i

velika promjena kvalitete posluživanja može imati zanemariv utjecaj na iskustvenu kvalitetu

igranja statičke, kartaške igre koja rijetko zahtjeva reakciju korisnika [14].

Problem raspodijele mrežnih resursa kod igara zasnovanih na računalnom oblaku, kada više

korisnika simultano koristi iste mrežne resurse, rješava se maksimiziranjem kvalitete igranja

svih korisnika sustava. Ovaj rad koncentrira se na razmjenu podataka između mrežnog

operatora i davatelja usluge s ciljem pomoći u što učinkovitijoj raspodjeli mrežnih resursa. U

nastavku rada opisan je prototip suradnje između davatelja usluge i mrežnog operatora na

temelju podatka o količini raspoloživih mrežnih resursa. Prototip je napravljen na primjeru

sustavu igara zasnovanih na računalnom oblaku tvrtke Steam [15].

2.2 QoE za usluge prilagodljivog strujanja videa

Danas je video sadržaj najzastupljenija vrsta prometa koja se prenosi Internetom. U prošloj

godini je očekivana ukupna količina video sadržaja koji se prenosi Internetom iznosila 52 PB

mjesečno, što čini približno 70% ukupnog prometa u Internetu [18]. Dvije trećine tog prometa

prenesene su raspodijeljenim mrežama za dostavu sadržaja (engl. Content Delivery Network,

CDN), čiji je predstavnik i YouTube [19]. Posljedica velike popularnosti YouTube-a, odnosno

velike količine mrežnog prometa koju on prenosi, je veliki potencijal za zastoje u mreži, te

pogreške u dostavi sadržaja korisniku. Pohrana sadržaja u priručna spremišta (engl. cache) i

pretpreuzimanje (engl. prefetching) YouTube videa pomaže u smanjenju kašnjenja u dostavi

sadržaja klijentu, te smanjenja potrebnih mrežnih resursa pri posluživanju klijenata, no zbog

načina korištenja usluge YouTube pri kojem korisnici u približno 80% slučajeva zahtijevaju

pregled videa samo jednom, učinkovitost tehnika pretpreuzimanja i cache-iranja je

ograničena. To je dovelo do potrebe za razvojem drugih mehanizama za smanjenje količine

YouTube prometa u mreži [20].

15

U današnjem Internetu, najpoznatije usluge za prijenos video sadržaja (npr. Netflix, Hulu,

YouTube) koriste HTTP prijenos preko TCP-a (ili preko protokola QUIC u slučaju usluge

YouTube). Način prijenosa sadržaja pomoću protokola HTTP mijenjao se više puta tokom

godina, te se može podijeliti u tri kategorije. Klasična dostava sadržaja putem protokola HTTP

uključivalo je preuzimanje cijelog sadržaja videa na korisničko računalo prije nego što je video

mogao biti pokrenut. Nakon toga se razvila tehnologija postupnog strujanja kod koje se video

postupno preuzima na klijentsko računalo, ali uz fiksnu kvalitetu i parametre. U novije vrijeme,

sve je češća upotreba dinamičkog prilagodljivog strujanja putem protokola HTTP (engl.

Dynamic Adaptive Streaming over HTTP, DASH), koje omogućava prilagodbu kvalitete struje

videa trenutnim uvjetima u mreži [19], [20].

U sklopu ovog rada provedeno je testiranje usluge YouTube pri različitim načinima

raspodjeljivanja mrežnih resursa među korisnicima usluge. Testiranje uključuje mjerenje

ključnih pokazatelja performansi (engl. Key Performance Indicators, KPI) pri korištenju usluge

YouTube u nekoliko različitih scenarija korištenja usluge. Uz opis načina i rezultata provedenog

testiranja, u nastavku rada pobliže će biti opisan standard video strujanja DASH, te faktori koji

utječu na iskustvenu kvalitetu prilagodljivog video strujanja.

2.2.1 Tehnologija prilagodljivog strujanja DASH

Dinamičko prilagodljivo strujanje preko HTTP-a standard je koji omogućava prilagodbu

kvalitete i parametara strujanja video sadržaja promjenjivim uvjetima u mreži. Prilagodba

kvalitete radi na način da se video podijeli na segmente određene duljine, pri čemu svaki

segment predstavlja određeni vremenski period u ukupnom trajanju videa. U skladu s nastalim

segmentima, cjeloviti sadržaj videa kodira se u više različitih formata, odnosno u više različitih

razina kvalitete, te se pohranjuje na poslužitelju [21].

Pri zahtjevu korisnika za gledanjem određenog videa, korisniku se šalju podaci o poslužitelju

koji mu omogućava pristup sadržaju, te o segmentima u kojima je kodiran video. Datoteka s

opisom sadržaja (engl. Media Presentation Description, MPD) također sadrži opis svih razina

kvalitete u kojima su segmenti pohranjeni uz odgovarajuću brzinu video kodiranja (engl.

16

bitrate) koja je potrebna za reproduciranje segmenta u zapisanoj kvaliteti. Klijent periodički

(svakih 2-10 sekundi) provjerava propusnost, odnosno količinu mrežnih resursa koji su mu na

raspolaganju u tom trenutku, te na temelju tog podatka prilagođava kvalitetu segmenata koju

zahtjeva od poslužitelja u tom trenutku. Klijent prilikom preuzimanja segmenta njima puni

priručni spremnik određene veličine, nakon čega nastavlja preuzimati segmente uz konstanti

nadzor uvjeta u mreži kojima se prilagođava zahtijevanjem segmenata više ili niže kvalitete

ovisno o promjenama koje se odvijaju u mreži. Prilagodljivo strujanje za cilj ima smanjiti

negativne utjecaje u slučaju pogoršanja uvjeta u mreži reagirajući na degradaciju u mreži

zahtijevanjem sadržaja manje kvalitete. Tako se zadržava određeni stupanj popunjenosti

međuspremnika, te se smanjuju negativni utjecaji naglih negativnih promjena u mreži [19],

[20].

Duljina segmenta važan je faktor pri posluživanju sadržaja za prilagodljivo strujanje. Kraći

segmenti često rezultiraju većim brojem promjena zahtijevane razine kvalitete videa na

klijentskoj strani, dok odabir segmenata duljeg trajanja nije pogodan za mreže s čestim

promjenama, kao što su mobilne mreže, zato što se klijent u takvim uvjetima nije sposoban na

vrijeme prilagoditi promjenama nastalim u mreži [20].

2.2.2 Faktori koji utječu na iskustvenu kvalitetu prilagodljivog strujanja

Postoji mnogo faktora koji mogu utjecati na kvalitetu prilagodljivog strujanja. Neki od tih

faktora (postotak gubitka paketa, kašnjenja, vremenska kolebanja, itd.) direktno su povezani

s karakteristikama i stanjem u mreži te zajedno čine skupinu parametara koji čine kvalitetu

usluge (engl. Qoality of Service, QoS) [22]. Takav objektivni pristup analizi kvalitete sustava

zanemaruje ulogu korisnika, te se ne koncentrira na pojedinačnog korisnika i njegovu razinu

zadovoljstva korištenjem usluge. Iako je zadovoljstvo korisnika povezano s QoS-om, ne mora

biti njegova nužna posljedica. Zbog toga se kvaliteta često razmatra i na drugačiji način koji u

svoj centar stavlja korisnika i njegovo iskustvo. Razmatranje kvalitete koje uzima u obzir

subjektivne faktore korisnikovog doživljaja usluge naziva se iskustvenom kvalitetom (engl.

Qoality of Experience, QoE) [19].

17

Početno kašnjenje pri posluživanju video sadržaja, zastajkivanje, te razina kvalitete videa samo

su neki od parametara koji utječu na QoE. Sve parametre koji utječu na QoE jednim imenom

nazivamo ključnim indikatorima performansi (engl. Key Performance Indicators, KPIs) [22].

Prilikom korištenja prilagodljivog strujanja videa dva ključna identifikatora koji utječu na

iskustvenu kvalitetu klijenta, a to su početno kašnjenje i zastajkivanje. Početno kašnjenje pri

korištenju strujanja podataka nije moguće izbjeći zato što je prijenos određene količine

podataka u međuspremnik prije početka reprodukcije nužno. Često se u međuspremnik prije

početka reprodukcije učitava veća količina podataka nego što je to nužno zato što je takav

način rada efikasan u izbjegavanju poteškoća u slučaju kratkotrajnih varijacija unutar mreže.

Pri ostvarenju usluge dinamičkog prilagodljivog strujanja, nužno je naći kompromis između

dugog čekanja prije početka reprodukcije i povećanja rizika od zastajkivanja (engl. stalling) u

slučaju kada je početno punjenje spremnika kratko. Zastajkivanje je kratkotrajni prekid

reprodukcije video sadržaja uzrokovan iscrpljivanjem međuspremnika za reprodukciju. Takav

prekid traje sve dok se u međuspremnik ne učita dovoljna količina podataka za nastavak

reprodukcije [19].

Osim navedenih, postoje brojni indikatori performansi koji utječu na iskustvenu kvalitetu, no

oni neće biti razmatrani u nastavku rada. Opis drugih indikatora, te opširniji opis njihovog

utjecaja moguće je pronaći u [19], [23]. U nastavku rada biti će opisano testiranje usluge

YouTube u različitim uvjetima u mreži, te rezultati testiranja koji su bazirani na nekim od

ključnih identifikatora performansi.

18

3. Kooperativne metode upravljanja QoE-om

Korištenje enkripcije prilikom prijenosa sadržaja između davatelja OTT usluge i klijenta uvelike

otežava mrežnom operatoru, odnosno ISP-u uvid u parametre vezane u performanse usluge,

te samim time otežava i procjenjivanje iskustvene kvalitete korisnika, što utječe na mogućnost

upravljanja QoE-om u negativnom smislu.

Postoje načini na koje mrežni operatori mogu pratiti QoE korisnika i bez razmjene informacija

između ISP-a i OTT-a, no takva rješenja često su vrlo složena, te je potrebno njihovo

neprestano održavanje kako bi ostali funkcionalni. Iako takva rješenja imaju prilično veliku

točnost kojom procjenjuju QoE, ostaje pitanje ostvarive korisnosti koja bi mogla biti postignuta

kada bi postojala komunikacija, odnosno suradnja između ISP-a i OTT-a [11].

Povratna informacija o iskustvu korištenja usluge na strani klijenta može donijeti jako korisne

podatke prilikom donošenja odluka o raspodjeli mrežnih resursa. Također, određene

informacije koje su relevantne za optimalnu raspodjelu resursa dostupne su jedino u mreži.

Kada bi poslužitelj aplikacija imao pristup informacijama povezanima s učinkovitosti mreže to

bi napravilo prostora za poboljšane odluke o prilagođavanju na strani aplikacije, dok bi u isto

vrijeme dostupnost informacija o zahtjevima aplikacije poslužitelju Interneta dalo sposobnost

upravljanja mrežnim resursima uzimajući u obzir korisnika i njegove specifične potrebe. Takva

situacija dovodi do pretpostavke da bi suradnja između određenih entiteta u Internetu dovela

do poboljšanja u kvaliteti sadržaja kojim su klijenti posluženi, te samim time i do povećanja

iskustvene kvalitete kod klijenata [25].

Suradnja između ISP-a i OTT-a koja je usmjerena na QoE može biti podijeljena u nekoliko

kategorija [26]:

• Optimizacija na razini aplikacije – aplikacija prima informacije o performansama

mreže, te na temelju njih odlučuje da li želi prilagoditi svoje parametre i način rada

trenutnim uvjetima ili želi prilagodbu prepustiti mehanizmima na razini mreže.

• Optimizacija na razini mreže – mreža prima podatke o aplikacijama i mrežnim

performansama i odlučuje želi li obaviti prilagodbu na razini mreže, ili proslijediti

aplikaciji informacije o potrebnom načinu prilagodbe.

19

• Policy manager optimizacija – policy manager je entitet u sustavu koji prima

informacije o aplikacijama i performansama mreže, te radi upravljačke odluke koje se

prosljeđuju aplikacijama i mreži. Upravljačke odluke koje policy manager donosi

bazirane su na njegovom globalnom pogledu na sustav.

Većina predloženih načina suradnje između OTT-a i ISP-a bazirane su na razmijeni podataka o

parametrima koji su bitni za QoE u smjeru od OTT-a prema ISP-u. Opisani način suradnje može

biti implementiran na nekoliko različitih načina [11]:

• OTT aktivno šalje informacije ISP-u,

• ISP po potrebi zahtijeva podatke od OTT poslužitelja,

• Informacije se šalju regularnim komunikacijskim kanalima, te mogu biti pasivno

nadzirane.

Za prva dva načina mora biti specificirano aplikacijsko programsko sučelje (engl. Application

programming interface, API) za razmjenu informacija, dok treći način zahtjeva dubinske

promjene načina na koji funkcionira protokol HTTPS.

3.1 Motivacija mrežnih operatora za suradnju s davateljima usluga

S napretkom tehnologije i povećanjem opsega usluga koje Internet nudi lako je moguće uočiti

trend povećanja korisničkih zahtjeva na razinu kvalitete usluge kojom su posluženi. Također,

sve je veća potražnja za sadržajima koji su bogati informacijama, odnosno koji zahtijevaju

prijenos velike količine podataka kada su isporučeni korisniku. Nakon pojave OTT usluga u

Internetu, naročito onih koji nude prijenos video sadržaja, poslužitelji Interneta suočeni su s

iznimno velikim porastom u količini Internet prometa. Budući da su poslužitelji Interneta često

izostavljeni iz zarade koju ostvaruje OTT, njihovi troškovi se povećavaju, a dobitci smanjuju

[12].

Uz želju zadržavanja svojih cijena što nižima, ISP-ovi često odgađaju nadogradnje mreže što

dovodi u pitanje uspjeh isporučivanja usluge klijentu, te može dovesti do gubljenja paketa i

zagušenja prilikom prijenosa podataka koji jako brzo mogu značajno smanjiti QoE. Glavni

20

ciljevi ISP-ova su podrška za što veći opseg usluga, smanjenje troškova, te održavanje

zadovoljstva klijenata u željenim granicama [12].

ISP-ovi koriste različite mehanizme upravljanja mrežom u cilju što učinkovitijeg posluživanja

klijenata. Uvid u mrežne zahtjeve i sposobnosti prilagođavanja OTT usluga moglo bi potpomoći

postojećim mehanizmima u postizanju znatno veće učinkovitosti, a time i većem zadovoljstvu

korisnika sustava. Primjerice, informacije o sposobnostima prilagođavanja OTT-a moguće je

koristiti za raspodjelu mrežnih resursa zasnovanu na QoE-u uslugama koje se istovremeno

natječu za resurse. Nadalje, uvid u pokazatelje performansi na razini aplikacije omogućio bi

ISP-u identificiranje QoE degradacija koje osjete korisnici, te određivanje uzroka tih

degradacija. Informacije o uzrocima degradacija mogu uvelike pomoći učinkovitosti

posluživanja klijenata [12].

Promjene u načinu upravljanja mrežom su tipično spore (tjedni ili mjeseci), dok su promjene

u mrežnim zahtjevima prilično dinamične (minute ili sati), što znači da bi mreže za uspješno

posluživanje klijenata trebale biti što je moguće više reaktivne, uzimajući pritom u obzir vrstu

sadržaja koji se prenosi mrežom, te način dostavljanja usluge klijentu [32].

Mrežni operatori tipično ne žele otkrivati unutarnju topologiju i stanje mreže, no u slučaju

ostvarenja ovakve komunikacije, mogu naplaćivati razmjenu onih informacija koje su voljni

ponuditi. Također, komunikacija bi dovela do povećanja učinkovitosti dostave usluge klijentu.

Koristeći saznanja o sadržaju koji se šalje krajnjim korisnicima, ISP-ovi mogu lakše predvidjeti

mrežne zahtjeve, te im ta informacija omogućava upravljanje mrežnim resursima koje je

zasnovano na QoE-u [12].

3.2 Motivacija davatelja usluga za suradnju s mrežnim operatorima

Različite usluge kojima se korisnici poslužuju od strane različitih davatelja, ili računalnog

oblaka razlikuju se u mrežnim resursima koje od poslužitelja zahtijevaju, te u opterećenju koje

uzrokuju u mreži. Unatoč optimizacijama u mrežnom prometu i prilagodbama na strani

klijenta koje obavljaju pružatelji usluga, dostava podataka od Internet poslužitelja do korisnika

često ne rezultira optimalnim posluživanjem krajnjeg korisnika, odnosno korisnik nije u

mogućnosti maksimalno uživati u sadržaju koji koristi. Jedan od uzroka tome je ograničena

21

količina podataka koju pružatelj usluge ima o trenutnim uvjetima u mreži između poslužitelja

Interneta i korisnika [32].

Budući da imaju pristup podacima na razini aplikacije, informacije o sadržaju kojem korisnik

pristupa, vrsti uređaja koju korisnik koristi, te u nekim slučajevima čak i povratnu informaciju

korisnika o zadovoljstvu uslugom, pružatelji usluga imaju odličan uvid u QoE korisnika, no

nemaju sposobnost upravljanja mrežnim QoS-om, koji ima značajan utjecaj na iskustvenu

kvalitetu korisnika [12].

Primarni razlog zbog kojega pružatelji usluga u Internetu žele sudjelovati u razmjeni

informacija s poslužiteljima Interneta je kako bi dobili uvid u stanje mreže koje mogu koristiti

kako bi prilagodili posluživanje usluge trenutnim uvjetima u mreži. Pružatelji usluga često

pokušavaju mjerenjima na razini mreže utvrditi trenutno stanje u mreži, a isti podaci znatno

veće točnosti već su dostupni ISP-u [12].

22

4. Model prototipa suradnje između davatelja usluge i

mrežnog operatora

Konceptualni prikaz upravljanja mrežom na temelju QoE-a, koji uključuje suradnju između

davatelja usluge i mrežnog operatora nalazi se na slici (Slika 4.1). Na višoj razini apstrakcije,

shema se sastoji od četiriju komponenti:

• Entitet za nadzor QoE-a (engl. QoE monitor),

• Entitet za upravljanje QoE-om (engl. QoE manager),

• Entitet za kontrolu QoE-a (engl. QoE controller) ,

• Entitet za razmjenu podataka između ISP-a i OTT-a (engl. OTT/ISP data exchange

entity).

Uloga entiteta za nadzor QoE-a je prikupljanje relevantnih podataka na temelju kojih se vrši

procjena korisničkog QoE-a, te slanje te informacije prema entitetu za upravljanje QoE-om.

Entitet za upravljanje QoE-om prima procjene QoE-a od entiteta za nadzor QoE-a, kao i

informaciju o trenutnom stanju u mreži od entiteta za kontrolu QoE-a. Na temelju tih

informacija entitet obavlja analizu uzroka degradacija QoE-a, te izvodi optimizacijske

algoritme koji pronalaze potencijalne ispravljajuće akcije koje mogu smanjiti degradacije QoE-

a. Ako postoje ispravljajuće akcije koje je moguće poduzeti, entitet za upravljanje QoE-om ih

javlja entitetu za kontrolu QoE-a, koji pristupa mrežnom upravljačkom sloju, koji provodi

ispravljajuće akcije. Entitet za kontrolu QoE-a može također obavijestiti OTT pružatelja usluge

o provedenim ispravljajućim akcijama pomoću entiteta za razmjenu podataka između ISP-a i

OTT-a [6].

Opisani način upravljanja QoE-om moguće je koristiti za razmjenu odabranih informacija

između davatelja usluge i mrežnog operatora u oba smjera, odnosno za razmjenu podataka

od ISP-a prema OTT-u i od OTT-a prema ISP-u. Na primjeru usluge igara zasnovanih na

mrežnom oblaku, moguća je razmjena informacije o količini dostupnih mrežnih resursa koju

ISP dijeli s OTT-om, uz pomoć koje je moguće napraviti kvalitetniju raspodjelu mrežnih resursa

zasnovanu na QoE-u. Također, na primjeru usluge YouTube, moguća je razmjena podataka u

suprotnom smjeru, pri kojoj se podaci o korisničkom iskustvu korištenja usluge šalju ISP-u, koji

23

nakon toga s jasnijim uvidom u stanje u mreži može napraviti učinkovitiju raspodjelu mrežnih

resursa. Ovi scenariji detaljnije će biti obrađeni u nastavku rada.

Slika 4.1 Konceptualna shema upravljanja mrežom na temelju QoE-a [6]

24

5. Implementacija prototipa

5.1 Funkcijski zahtjevi

Prototip suradnje između davatelja usluge i mrežnog operatora, koji je napravljen u sklopu

ovog rada temelji, se na razmjeni informacija o količini dostupnih mrežnih resursa od strane

ISP-a prema OTT-u. Prototip je napravljen za uslugu igara zasnovanih na mrežnom oblaku.

Zadaće koje bi takav prototip trebao obavljati, odnosno funkcionalni zahtjevi koji su

postavljeni na prototip su:

• Razmjena informacije o količini dostupnih mrežnih resursa koju ISP šalje davatelju

usluge igara zasnovanih na mrežnom oblaku – potrebno je omogućiti prijenos

podatka od ISP-a prema davatelju usluge igara zasnovanih na mrežnom oblaku, kojem

dostupnost te informacije omogućava izvođenje optimizacijskih algoritama, te

poboljšano iskorištavanje dostupnih mrežnih resursa.

• Postojanje optimizacijskog algoritma na strani davatelja usluge igara zasnovanih na

mrežnom oblaku koji uzima u obzir količinu raspoloživih mrežnih resursa – uz

dostupnost podataka o korisnicima, te specifičnoj usluzi koju oni trenutno koriste, te

uz podatak o količini dostupnih mrežnih resursa, moguće je provesti optimizaciju koja

uzima u obzir QoE, te na temelju nje izvršava raspodjelu mrežnih resursa korisnicima.

• Razmjena informacije od strane davatelja usluge prema svakom pojedinačnom

korisniku o količini mrežnih resursa koji su mu pridijeljeni izvođenjem

optimizacijskog algoritma – nakon izvođenja algoritma za raspodjelu mrežnih resursa

davatelj usluge igara zasnovanih na mrežnom oblaku mora javiti svakom klijentu

količinu mrežnih resursa koja mu je pridijeljena.

• Korištenje pridijeljene količine resursa na strani korisnika – nakon primanja podatka

o količini mrežnih resursa koja mu je dodijeljena, korisnik usluge mora ograničiti svoje

korištenje mrežnih resursa na zadanu vrijednost.

U sklopu ovog rada razvijen je prototip suradnje davatelja usluge i mrežnog operatora na

temelju usluge igara zasnovanih na mrežnom oblaku. Na sličan način moguće je napraviti

prototip za usluge prilagodljivog strujanja videa (primjerice YouTube). U takvom prototipu

25

razmjena informacija bila bi u suprotnom smjeru, te bi se razmjenjivala informacija o ključnim

parametrima performansi koje je moguće mjeriti na strani korisnika.

5.2 Tehnička izvedba

Prototip je namijenjen specifično za platformu Steam, koji je klijent tvrtke Valve, a služi za

distribuciju igara, te podržava igranje zasnovano na računalnom oblaku. U normalnom načinu

rada Steam-ove usluge ne postoji razmjena podataka o uvjetima u mreži ili sadržaju koji

korisnik koristi između pružatelja usluge i poslužitelja Interneta. Izgradnja prototipa za cilj ima

pokazati da li komunikacija između ISP-a i OTT-a pri posluživanju igara zasnovanih na

računalnom oblaku utječe na iskustvenu kvalitetu klijenta, te ako da na koji način.

Komunikacija između ISP-a i OTT-a sastoji se u razmijeni podatka o trenutnom stanju mreže,

odnosno o raspoloživim mrežnim resursima koji ISP šalje OTT-u pri promjeni uvjeta u mreži.

Na taj način pružatelj Steam usluge u svakom trenutku ima informaciju o raspoloživim

mrežnim resursima koju dobije od ISP-a, kao i informacije o klijentima te igrama koje oni

trenutno koriste, te pomoću tih informacija može napraviti raspodjelu raspoloživih resursa

klijentima na način da oni budu što zadovoljniji kvalitetom usluge koju koriste.

Prototip se prema ulozi koju obavljaju u sustavu može podijeliti na četiri odvojena entiteta:

• Klijent za igranje temeljeno na računalnom oblaku – entitet u sklopu prototipa koji

predstavlja računalo na kojemu klijent igra računalnu igru koju je odabrao. Entitet se

sastoji od dva modula. Jedan modul je standardni Steam klijent koji se koristi za pristup

usluzi Steam, te igranje igara. Drugi modul ovog entiteta služi za ostvarenje

komunikacije između klijenta za igranje zasnovano na računalnom oblaku i QoE

optimizacijske funkcije, odnosno modula za komunikaciju unutar tog entiteta.

Komunikacija se odvija u pozadini paralelno sa igranjem igre. QoE optimizacijskoj

funkciji se šalju podaci o igri koji klijent trenutno koristi, te od nje prima podatak o

količini mrežnih resursa koja je pridijeljena klijentu za igranje temeljeno na računalnom

oblaku. Pri svakoj promjeni količine resursa koji su dodijeljeni klijentu, on mijenja

postavke svog posluživanja tako da iskoristi samo količinu resursa koja mu je

dodijeljena. Ovaj entitet u paru s QoE optimizacijskom funkcijom sudjeluje u

26

ostvarenju dvaju funkcionalnih zahtjeva koji su postavljeni ovom sustavu. To su zahtjev

o razmjeni informacije o količini mrežnih resursa koji su pridijeljeni korisniku, te

korištenje tog podatka za ograničenje svoje upotrebe mrežnih resursa.

• Steam poslužitelj – entitet na kojem je pohranjena računalna igra. On Steam klijentu

šalje video sadržaj igre, te od njega prima naredbe koje klijent unosi u igru. Također,

na njemu se izvode sve procesorski i memorijski zahtjevne operacije i izračuni, te se na

taj način rasterećuje klijentsko računalo koje ne mora posjedovati komponente

sposobne za pokretanje igara koje postavljaju visoke zahtjeve na računalnu opremu,

nego samo moraju biti sposobna pokretati video sadržaj koji primaju, te imati vezu s

Internetom. Steam poslužitelj ne sudjeluje ni na koji način u ostvarenju suradnje

između ISP-a i OTT-a.

• Entitet unutar ISP-a zadužen za razmjenu informacija – entitet koji se sastoji od dva

modula. Jedan modul je mreža koja omogućuje pristup i sudjelovanje u internetu, dok

je drugi modul zadužen za javljanje podataka o trenutno raspoloživoj količini mrežnih

resursa QoE optimizacijskoj funkciji. Taj modul implementiran je kao jednostavno

sučelje u koje se unosi informacija o količini resursa koji su trenutno dostupni, te se ta

informacija prosljeđuje QoE optimizacijskoj funkciji. Ovaj modul ispunjava funkcijski

zahtjev razmjene informacije o količini dostupnih mrežnih resursa s davateljem usluge.

• QoE optimizacijska funkcija – entitet koji se sastoji od tri modula. Aplikacijsko

programsko sučelje je modul koji obavlja razmjenu podataka između ostala dva

modula ovog entiteta, odnosno između optimizacijske funkcije i modula za

komunikaciju s klijentima. Također, ovaj modul služi za primanje podataka o trenutno

dostupnoj količini mrežnih resursa od entiteta zaduženog za razmjenu informacija

unutar ISP-a. Modul za komunikaciju s klijentima prima od klijenta za igranje zasnovano

na računalnom oblaku podatak o igri koja je trenutno korištena, te na zahtjev šalje

klijentu za igranje zasnovano na računalnom oblaku količinu mrežnih resursa koja mu

je u tom trenutku dodijeljena. Optimizacijska funkcija treći je modul ovog entiteta. Ona

posjeduje modele koji za svaku igru povezuju količinu mrežnih resursa koji su

dodijeljeni klijentu s procjenom iskustvene kvalitete koju će klijent iskusiti, odnosno sa

QoE-om . Na temelju modela, dostupnih informacija o igrama koje klijenti igraju, te

količini dostupnih mrežnih resursa, ovaj entitet izvodi algoritam koji svakom klijentu

pridjeljuje određenu količinu mrežnih resursa na način da klijenti pojedinačno, kao i u

27

zbroju dožive što je moguće bolje iskustvo igranja igre, odnosno što je moguće veći

QoE. QoE optimizacijska funkcija sudjeluje u ispunjavanju triju funkcijskih zahtjeva.

Ispunjava funkcijski zahtjev razmjene informacije o količini dostupnih mrežnih resursa

s davateljem usluge, kao i funkcijski zahtjev o postojanju algoritma raspodjele mrežnih

resursa, te zahtjev o razmjeni informacije s klijentom o količini mrežnih resursa koji su

mu pridijeljeni.

Način na koji su entiteti prototipa međusobno povezani predočen je na slici (Slika 5.2.1).

Slika 5.2.1 Način na koji su povezani entiteti unutar prototipa, i opis informacija koje međusobno razmjenjuju

U nastavku rada pažnja će biti posvećena samo entitetima, odnosno modulima sustava koji

sudjeluju u razmjeni informacija koje su bitne za obavljanje raspodjele mrežnih resursa

28

temeljene na QoE-u. U entitete koji sudjeluju u razmjeni informacija spadaju komunikacijski

modul klijenta za igranje temeljeno na računalnom oblaku, modul za dostavu mrežnih metrika

od ISP-a do OTT-a, te svi moduli QoE optimizacijske funkcije. U nastavku rada biti će opisan

način njihovog rada i specifičnosti implementacije.

5.3 Modul za dostavu mrežnih metrika od ISP-a do OTT-a

Modul za dostavu mrežnih metrika od ISP-a do OTT-a jako je jednostavno izgrađena

komponenta sustava koja se sastoji od jednostavnog grafičkog korisničkog sučelja prikazanog

na slici (Slika 5.3.1). Kroz grafičko sučelje moguće je unijeti širinu prijenosnog pojasa (engl.

bandwidth) koju želimo poslati QoE optimizacijskoj funkciji kao količinu trenutno dostupnih

mrežnih resursa. Slanje unesenog podatka obavlja se pritiskom na tipku „Send“ (tipka zelene

boje na slici).

Slika 5.3.1 Izgled grafičkog korisničkog sučelja ISP entiteta

U pozadini se prilikom pritiska gumba upisani podatak prosljeđuje QoE optimizacijskoj funkciji

kroz aplikacijsko programsko sučelje. Pristupna točka API-ja kojoj je potrebno pristupiti je:

„/api/bandwidth“, a tip poziva je POST. Tijelo HTTP POST metode sadrži samo jedan podatak,

čije je ime „Bandwidth“, a njegova vrijednost je vrijednost koja je upisana u polje grafičkog

sučelja koje nosi isto ime. Ukoliko u polje nije unesena numerička vrijednost, tada se API poziv

neće ni dogoditi. Vrijednost koja se upisuje u polje je vrijednost bandwidth-a izražena u jedinici

29

kbit/s. Budući da je prototip razvijen sa idejom da modul za dostavu mrežnih metrika od ISP-a

do OTT-a i QoE optimizacijska funkcija budu pokrenuti na istom računalu, konfiguriranje

adrese na koju se šalje zahtjev nije moguće.

5.4 Komunikacijski modul klijenta za igranje zasnovano na

računalnom oblaku

Komunikacijski modul klijenta za igranje zasnovano na računalnom oblaku je dio prototipa

suradnje između davatelja usluge i mrežnog operatora koji je zadužen za slanje informacije o

igri koju klijent koristi QoE optimizacijskoj funkciji. Također, on prima informacije o tome koja

količina mrežnih resursa mu je pridijeljena nakon svake raspodjele mrežnih resursa koju

obavlja QoE optimizacijska funkcija, te je tu informaciju dužan koristiti za ograničenje svojih

zahtjeva unutar mreže na zadanu veličinu. Komunikacijski modul klijenta za igranje temeljeno

na računalnom oblaku dužan je komunikacijskom modulu QoE optimizacijske funkcije javiti

svaku promjenu igre na klijentskoj strani, kao i prestanak igranja određene igre.

Opisana komunikacija između komunikacijskog modula klijenta za igranje temeljeno na

računalnom oblaku i QoE optimizacijske funkcije odvija se u pozadini za vrijeme korisnikovog

igranja računalne igre. Za vrijeme svog rada, komunikacijski modul klijenta za igranje

zasnovano na računalnom oblaku obavlja tri različite zadaće tijekom svog izvođenja. Zadaće

koje obavlja komunikacijski modul su: pribavljanje podataka o igri koju klijent trenutno igra,

komunikacija s QoE optimizacijskom funkcijom, te korištenje rezultata raspodjele mrežnih

resursa za ograničenje svog mrežnog prometa.

Pribavljanje podatka o igri koju klijent trenutno igra obavlja se u dva koraka. Prvo se iz lokalne

datoteke imena „loginusers.vdf“, koju kreira usluga Steam na klijentskom računalu, uzima

podatak o SteamId-u klijenta koji trenutno koristi sustav. Izgled datoteke „loginusers.vdf“

prikazan je na slici (Slika 5.4.1). Datoteku uređuje Steam, a sastoji se od popisa korisnika koji

su koristili Steam na tom računalu, te oznakom korisnika koji je zadnji koristio Steam. Na slici

su SteamId vrijednosti podcrtane crvenom bojom, dok je oznaka o zadnjem korisniku koji je

koristio sustav označena zelenom bojom.

30

Slika 5.4.1 Izgled loginusers.vdf datoteke uz istaknute bitne elemente datoteke (SteamId identifikator korisnika označen je crvenom bojom, a oznaka za zadnji korišteni račun označena je

zelenom bojom)

Podatak koji je u ovom koraku potrebno pribaviti je SteamId korisnika koji je zadnji koristio

sustav. Nakon što je taj podatak dostupan, u drugom koraku pristupa se podatku o igri koju

korisnik trenutno igra. Taj podatak dobiva se pristupom SteamAPI usluzi. Pristupna točka

SteamApi usluge kojoj je potrebno pristupiti je „/ISteamUser/GetPlayerSummaries“. To je

pristupna točka kojoj se pristupa slanjem HTTP GET zahtjeva na adresu

https://api.steampowered.com, a vraća podatke o korisniku čiji je identifikator poslan kao

parametar zahtjeva. Kao URL (engl. Uniform Resource Locator) parametre, poziv zahtijeva

SteamApi ključ, te SteamID korisnika koji je pribavljen u prošlom koraku. SteamApi ključ

moguće je korisnicima Steam-a dobiti na zahtjev, te je njegovo posjedovanje nužno za

korištenje SteamApi-a. Nakon obavljanja poziva, prima se odgovor koji je prikazan na slici

(Slika 5.4.2). Podatak o igri koju korisnik trenutno koristi označen je na slici crvenom bojom.

Ukoliko korisnik trenutno ne koristi niti jednu igru, taj podatak je prazan.

31

Slika 5.4.2 Odgovor SteamApi usluge na zahtjev o korisničkim podacima koji joj je upućen

Drugi zadatak komunikacijskog modula klijenta za igranje zasnovano na računalnom oblaku je

razmjena informacija s QoE optimizacijskom funkcijom. Komunikacija se odvija putem

komunikacijskog protokola poznatog pod imenom Websocket. On omogućava komunikaciju

između klijenata i poslužitelja u stvarnom vremenu uspostavljanjem TCP veze između

sudionika komunikacije. Klijent za igranje zasnovano na mrežnom oblaku unutar

konfiguracijske datoteke ima dostupan podatak o IP adresi na kojoj se nalazi Websocket

poslužitelj, te mu šalje podatak o igri koju korisnik igra koji je pribavljen u sklopu već opisanog

prvog zadatka koji obavlja komunikacijski modul klijenta za igranje zasnovano na računalnom

oblaku.

Također, komunikacijski modul nakon svake raspodjelu mrežnih resursa obavljene od strane

QoE optimizacijske funkcije dobiva podatak o količini mrežnih resursa koja je njemu

pridijeljena. Nakon primitka tog podatka, zbog specifičnosti u načinu funkcioniranja usluge

Steam, potrebno je ponovno pokrenuti igru koju klijent igra, te zadati nove parametre o

količini mrežnih resursa koje klijent ima na raspolaganju. Taj postupak je automatiziran.

Prvenstveno se igra gasi, nakon čega se u Stem konzolu upisuje vrijednost dobivenih

parametara, te se igra opet pokreće i klijent može nastaviti igrati igru uz poštivanje ograničenja

količine korištenih mrežnih resursa koja mu je nametnuta.

32

5.5 QoE optimizacijska funkcija

QoE optimizacijska funkcija prototipa suradnje između davatelja usluge i mrežnog operatora

prima informacije od modula za dostavu mrežnih metrika od ISP-a do OTT-a o količini

raspoloživih mrežnih resursa, te prima informacije od komunikacijskih modula klijenata za

igranje zasnovano na računalnom oblaku o tome koje igre oni igraju. Nakon toga uz pomoć

modela koji povezuju količinu pridijeljenih mrežnih resursa s očekivanom iskustvenom

kvalitetom korisnika izvodi algoritam koji dodjeljuje svakom korisniku sustava određenu

količinu mrežnih resursa, te rezultate izvođenja algoritma prosljeđuje klijentima. QoE

optimizacijska funkcija je podijeljena na tri dijela:

• Modul zadužen za komunikaciju s klijentima – komunikacija se odvija pomoću

komunikacijskog protokola Websocket. To je protokol koji uspostavljanjem TCP veze

između klijenta i poslužitelja omogućava njihovu komunikaciju u stvarnom vremenu.

Ovaj modul QoE optimizacijske funkcije ima ulogu websocket poslužitelja, te kao takav

obavlja komunikaciju sa svim klijentima koji s njim ostvare vezu. Komunikacija se

sastoji u primanju informacija o igrama koje igraju korisnici, te slanju informacija o

rezultatima raspodjele mrežnih resursa. Rezultate raspodjele mrežnih resursa ovaj

modul dobiva od drugog modula ovog entiteta, odnosno od aplikacijskog programskog

sučelja.

• Aplikacijsko programsko sučelje – sadrži pristupne točke koje koristi modul zadužen

za komunikaciju kako bi dojavio igre koje korisnici igraju, te pristupne točke koje koristi

modul za dostavu mrežnih metrika od ISP-a do OTT-a kako bi dojavio količinu

raspoloživih mrežnih resursa.

• Optimizacijska funkcija - u sklopu ovog modula implementirana je i logika raspodjele

mrežnih resursa klijentima, odnosno algoritam raspodjele mrežnih resursa na temelju

igara koje klijenti igraju i količine dostupnih mrežnih resursa s ciljem maksimiziranja

iskustvene kvalitete svih korisnika sustava.

Detaljniji opis modula, kao i način njihove implementacije biti će opisan u nastavku rada, dok

će način podešavanja načina rada entiteta, kao i unos parametara koji su mu potrebni biti

opisan u poglavlju Dodatak na kraju rada.

33

5.5.1 Modul zadužen za komunikaciju s klijentima

Modul za komunikaciju s klijentima zaslužan je za primanje podataka o igri koje korisnici

sustava trenutno igraju od komunikacijskih modula klijenata za igranje zasnovano na

računalnom oblaku, te je zadužen za slanje podataka o raspodjeli mrežnih resursa svakom

pojedinom klijentu u ovisnosti o tome koju igru igraju i kakvi su trenutni uvjeti u mreži.

Komunikacija između ovih modula odvija se korištenjem komunikacijskog protokola

Websocket. Websocket uspostavlja TCP vezu između klijenta i poslužitelja, te tako omogućava

njihovu komunikaciju u stvarnom vremenu. Proces komunikacije se odvija tako da

prvenstveno modul prima podatke o korisniku i igri koju igra, te nakon toga prosljeđuje taj

podatak aplikacijskom programskom sučelju. Za razmjenu informacija s drugim modulom,

modul za komunikaciju koristi pristupnu točku „api/clients“ aplikacijskog programskog sučelja

na koju HTTP POST metodom javlja dolazak novog korisnika u sustav, te pristupnu točku

„api/bitrates/{id}“ koja se poziva HTTP GET metodom, koja pribavlja količinu mrežnih resursa

koja je pridijeljena korisniku s identifikatorom koji se šalje kao parametar zahtjeva. Također,

moguć je i odlazak korisnika iz sustava, te se taj događaj javlja korištenjem HTTP POST metode

na pristupnoj točci „api/removeClients“.

Aplikacijsko programsko sučelje nakon primitka podatka o dolasku novog korisnika poziva

modul s algoritmom za raspodjelu mrežnih resursa, te odgovara modulu za komunikaciju s

klijentima s dobivenim vrijednostima. Nakon toga modul za komunikaciju s klijentima putem

websocketa šalje poruke klijentima o tome koja količina mrežnih resursa im je pridijeljena. Taj

proces ponavlja se svaki put kada novi korisnik dođe u sustav, ili postojeći korisnik promijeni

igru koju igra.

5.5.2 Aplikacijsko programsko sučelje

Aplikacijsko programsko sučelje optimizacijske funkcije ima više različitih pristupnih točaka.

Tri pristupne točke sadrže samo HTTP POST metode kojima je moguće pristupiti, dok jedna

pristupna točka sadrži samo HTTP GET metodu. Pristupne točke koje ima aplikacijsko

programsko sučelje su:

34

• /api/bandwidth – pristupna točka koju koristi modul za dostavu mrežnih metrika od

ISP-a do OTT-a. Ima implementiranu samo HTTP POST metodu, korištenjem koje je

moguće pohraniti trenutnu količinu raspoloživih mrežnih resursa koje ISP ima na

raspolaganju za OTT, odnosno sve njegove korisnike. Vrijednost koja se dobije kroz ovu

pristupnu točku je pohranjena u radnu memoriju, te se ni na koji način njena vrijednost

ne zapisuje u trajnu memoriju, niti se pamti povijest promjena ove vrijednosti. Kao

odgovor na poziv HTTP POST metode nad ovom pristupnom točkom pozivatelju se

vraća samo HTTP OK odgovor bez ikakvog sadržaja. Ukoliko se HTTP POST metodom

želi poslati podatak o propusnosti mreže (engl. Bandwidth) u vrijednosti od 1000

kbit/s, tijelo poruke u JSON formatu će izgledati ovako:

{

„Bandwidth“:1000

}.

Propusnost mreže predstavlja količinu podataka koji mogu biti preneseni mrežom u

jedinici vremena [14]. Propusnost se šalje u jedinici kbit/s. Ukoliko je nova vrijednost

propusnosti mreže različita od njene stare vrijednosti, posljedica pozivanja ove metode

je pozivanje algoritma za raspodjelu mrežnih resursa, što u konačnici rezultira

obavještavanjem klijenta o novoj raspodjeli.

• /api/clients – pristupna točka koju poziva modul za komunikaciju s klijentima. Ima

implementiranu samo HTTP POST metodu, korištenjem koje je moguće poslati

informacije o novom klijentu koji je pristupio sustavu, te igri koju on igra ili o promjeni

igre koju igra postojeći korisnik sustava. Vrijednost o klijentu i igri koju on igra koja se

dobije kroz ovu pristupnu točku je pohranjena u radnu memoriju, te se ni na koji način

njena vrijednost ne zapisuje u trajnu memoriju, niti se pamti povijest promjena ove

vrijednosti. Ukoliko je igra koju klijent igra različita od igre koju je klijent prije igrao,

posljedica pozivanja ove metode je pozivanje algoritma za raspodjelu mrežnih resursa,

te se rezultat nove raspodjele šalje pozivatelju u sklopu HTTP OK odgovora, nakon čega

se taj podatak prosljeđuje klijentu. Ukoliko se HTTP POST metodom želi poslati podatak

o novoj igri „Serious Sam 3“ koju korisnik s identifikatorom „1“ igra, tijelo poruke u

JSON formatu će izgledati ovako:

{

„Id“ : “1“,

35

„Game“ : “Serious Sam 3“

}.

• /api/removeClient - pristupna točka koju poziva modul za komunikaciju s klijentima.

Ima implementiranu samo HTTP POST metodu, korištenjem koje je moguće ukloniti

korisnika koji je prestao koristiti sustav. Poziv ove metode uzrokuje uklanjanje

korisnika iz liste trenutnih korisnika sustava koja je pohranjena u radnoj memoriji, te

poziv algoritma za raspodjelu mrežnih resursa, te se nova raspodjela šalje pozivatelju

u sklopu HTTP OK odgovora, nakon čega se nova raspodjela prosljeđuje klijentu.

Ukoliko se HTTP POST metodom želi ukloniti korisnik s identifikatorom „1“ igra, tijelo

poruke u JSON formatu će izgledati ovako:

{

„Id“ : “1“,

}.

• /api/bitrates/{id} – pristupna točka koju poziva modul za komunikaciju s klijentima.

Ima implementiranu samo HTTP GET metodu, korištenjem koje je moguće dobiti

trenutnu količinu mrežnih resursa koja je dostupna klijentu s identifikatorom id, koji je

poslan kao parametar prilikom poziva metode.

5.5.3 Optimizacijska funkcija

U sklopu rada implementirana su dva različita algoritma za raspodjelu mrežnih resursa. Prvi

od njih raspodjeljuje resurse tako da jednostavno podijeli ukupnu količinu resursa na sve

korisnike koji trenutno koriste sustav, tako da svi korisnici dobiju jednaku količinu mrežnih

resursa, te zbog njegove jednostavnosti neće biti dalje opisivan. Drugi algoritam

deterministički je algoritam koji ima nešto složeniji način rada koji će biti opisan u nastavku

rada.

Algoritam prije svog izvođenja priprema podatke o MOS ocjeni za različite kombinacije parova

pridijeljenih brzina video kodiranja i broja okvira u sekundi. Na temelju izračunatih podataka

moguće je za pridijeljenu brzinu video kodiranja brzo odrediti pripadajuću vrijednost MOS

ocjene kvalitete, što uvelike ubrzava rješavanje problema. Cilj rješavanja problema je

36

maksimizirati funkciju cilja koja može poprimiti nekoliko različitih oblika. U nastavku rada biti

će opisan način izračuna MOS ocjena iskustvene kvalitete, te različite funkcije cilja koje koristi

algoritam implementiran u sklopu ovog rada, nakon čega će biti opisani detalji načina rada

algoritma [13].

5.5.3.1 Izračun MOS ocjena iskustvene kvalitete

Za izračun MOS iskustvene kvalitete na temelju parametara video kodiranja, korištena je

kvadratna funkcija [16]:

𝑀𝑂𝑆(𝑔, 𝑓, 𝑏) = 𝛼𝑔,1 ∗ 𝑓 + 𝛼𝑔,2 ∗ 𝑏 + 𝛼𝑔,3 ∗ 𝑓2 + 𝛼𝑔,4 ∗ 𝑏2 + 𝛼𝑔,5 ∗ 𝑓 ∗ 𝑏 + 𝛼𝑔,6 , (1)

gdje koeficienti 𝛼𝑔,1 − 𝛼𝑔,6 predstavljaju parametre modela specifične za svaku pojedinu igru,

𝑏 predstavlja bitrate, odnosno brzinu video kodiranja, dok 𝑓 predstavlja broj okvira u jedinici

vremena. Koeficienti 𝛼𝑔,1 − 𝛼𝑔,6 dobiveni su na temelju testiranja korisnika različite razine

iskustva igranja igara, te su različiti za svaku igru [13].

U implementaciji algoritma razvijenog u sklopu ovog rada, za svaki par vrijednosti bitrate-a i

framerate-a, funkcija MOS iskustvene kvalitete računa se samo jednom prilikom pokretanja

programa, te se rezultati pohranjuju i po potrebi koriste. Pritom se za svaku vrijednost bitrate-

a pohranjuje samo jedna MOS vrijednost, i to za onu vrijednost framerate-a za koju je MOS

vrijednost maksimalna. Na ovaj način smanjuje se vrijeme izvođenja algoritama zbog

smanjene potrebe za višestrukim izračunavanjem iste funkcije [13].

5.5.3.2 Funkcije cilja

Problem raspodijele mrežnih resursa moguće je svesti na problem maksimiziranja iskustvene

kvalitete korisnika sustava. Prilikom toga mogu se koristiti različite funkcije cilja koje

usmjeravaju rješenje tako da po određenom kriteriju bude što kvalitetnije. Algoritam razvijen

u sklopu ovog rada moguće je konfigurirati da teži ispunjenju neke od funkcija cilja [17]:

• Maksimizacija prosjeka MOS ocjena iskustvene kvalitete – uzima u obzir samo prosjek

MOS ocjena svih korisnika sustava ne uzimajući u obzir razliku u MOS ocjenama između

pojedinačnih korisnika [13].

37

• Maksimizacija minimalne MOS ocjene – uzima u obzir MOS ocjenu najnezadovoljnijeg

korisnika sustava, te ju pokušava maksimizirati. Primjerice, u sustavu s četiri korisnika,

neka su dvije različite raspodjele mrežnih resursa dovele do MOS ocjena iskustvene

kvalitete korisnika:

𝑅𝑎𝑠𝑝𝑜𝑑𝑗𝑒𝑙𝑎1 = [5 1 5 1]

𝑅𝑎𝑠𝑝𝑜𝑑𝑗𝑒𝑙𝑎2 = [3 3 3 3]

Prosjek ocjena za obje raspodjele je 3, te bi prva funkcija cilja koja pokušava

maksimizirati prosjek MOS ocjena iskustvene kvalitete vrednovala obje raspodjele

jednako, dok bi druga funkcija cilja favorizirala 𝑅𝑎𝑠𝑝𝑜𝑑𝑗𝑒𝑙𝑢2. Iako obje funkcije daju

isti prosjek MOS ocjena, u 𝑅𝑎𝑠𝑝𝑜𝑑𝑗𝑒𝑙𝑖1 bi pola korisnika sustava bilo u potpunosti

nezadovoljno uslugom, što bi moglo dovesti do njihovog napuštanja sustava, dok u

𝑅𝑎𝑠𝑝𝑜𝑑𝑗𝑒𝑙𝑖2 svaki korisnik ima isti stupanj zadovoljstva uslugom, te se to ne bi desilo.

Za funkciju cilja koja pokušava maksimizirati minimalnu MOS ocjenu kažemo da

zadovoljava kriterij pravednosti (engl. fairness), zato što uzima u obzir zadovoljstvo

svakog korisnika, te vodi rezultate što manjoj razlici između iskustvene kvalitete

pojedinačnih korisnika [13].

5.5.3.3 Način rada algoritma

Egzaktni algoritmi koji se koriste za rješavanje problema raspodjele mrežnih resursa unatoč

svojoj optimalnosti nisu pogodni za rješavanje ovog problema zato što je vrijeme njihovog

izvođenja eksponencijalno ovisno o broju korisnika sustava, te kao takvo nije adekvatno za

sustave koji rade u stvarnom vremenu. Deterministički algoritam koji će biti opisan u nastavku

u svakom svom koraku odabire promjenu raspodjele mrežnih resursa koja će najpozitivnije

utjecati na promjenu funkcije cilja. Algoritam ne jamči optimalnost, no u većini ispitnih

slučajeva će odstupanje rješenja biti u odnosu na optimalno rješenje biti zadovoljavajuće malo

[17].

Algoritam na početku svog izvođenja podrazumijeva već izračunate vrijednosti MOS ocjena za

svaku vrijednost bitrate-a koja igri može biti pridijeljena. Uz pretpostavku da se svakoj igri

može pridijeliti bitrate i framerate s određenim gornjim i donjim granicama, izvođenje

38

algoritma započinje tako da se svakoj igri, ukoliko kapaciteti sustava to dopuštaju, pridijeli

minimalna vrijednost bitrate-a koju igra može imati. Nakon toga se algoritam izvodi u

koracima tako da algoritam u svakom koraku doda minimalnu količinu bitrate-a jednom od

trenutnih korisnika sustava. Korisnik kojemu će se dodati minimalna količina bitrate-a se

odabire tako da se izračuna nova vrijednost funkcije cilja za svaku moguću opciju raspodjele

(odnosno, za dodavanje bitrate-a svakom od korisnika pojedinačno), te se odabire korisnik

kojemu će pridjeljivanje minimalne količine bitrate-a dovesti do najpozitivnije promjene

funkcije cilja. Izvođenje algoritma završava kada su potrošeni svi resursi sustava, odnosno kada

više nije moguće dodati minimalnu količinu bitrate-a nekom od korisnika. Minimalna količina

bitrate-a koja se u svakom koraku dodjeljuje korisnicima određuje se prema granulaciji

sustava, odnosno sposobnosti sustava da u što manjim koracima mijenja vrijednost bitrate-a

kojom poslužuje korisnike. U nastavku je pseudokod koji pobliže opisuje način rada algoritma

[13]:

Pseudokod algoritma raspodjele mrežnih resursa temeljenog na QoE-u [13].

trenutna_raspodjela = pridijeli_svima_minimalan_bitrate()

korak = minimalni_korak_promjene_bitratea

ponavljaj

max_MOS = 0

indeks_promjene = 0

za svaki korisnik u trenutna_raspodjela

trenutna_raspodjela[korisnik] += korak

ako fun_cilja(trenutna_raspodjela[korisnik] > max_MOS

max_MOS = fun_cilja(trenutna_raspodjela[korisnik]

trenutna_raspodjela[korisnik] -= korak

trenutna_raspodjela[index] += korak

dok ukupan_bitrate < propusnost

vrati trenutna_raspodjela

39

Ulazni podaci koji su nužni algoritmu za ispravan rad, te načini konfiguriranja određenih faza

izvođenja algoritma opisani su u poglavlju Dodatak.

40

6. Ispitivanje doprinosa prototipa u upravljanju iskustvenom

kvalitetom

U ovom poglavlju opisani su načini testiranja prototipa suradnje između davatelja usluge i

mrežnog operatora na temelju odabranih informacija, kao i rezultati testiranja. Testiranja su

provedena nad uslugom Steam korištenjem prototipa opisanog u ovom radu, te nad uslugom

YouTube.

6.1 Metodologija testiranja i analiza rezultata izvođenja kod igara

zasnovanih na računalnom oblaku

Rezultati izvođenja prikazani u ovom poglavlju prikazuju izvođenje simulacije raspodjele

mrežnih resursa pri korištenju igara zasnovanih na računalnom oblaku temeljene na modelima

iskustvene kvalitete opisane u [13]. Način rada te simulacije potpuno je isti kao i način rada

prototipa razvijenog u sklopu ovog rada, ali omogućava jednostavnije dobivanje rezultata za

veći broj korisnika sustava nego prototip opisan u ovom radu.

Izvođenje algoritama testirano je za igre Hearthstone (u nastavku HS), te Serious Sam 3 (SS3).

Ulazni parametri koji su korišteni pri izvođenju algoritama preuzeti su iz [16]. Tablica(Tablica

6.1.1) opisuje usporedbu rezultata izvođenja algoritma opisanog u sklopu ovog rada i

jednolikog raspoređivanja za određeni scenarij korištenja sustava. Tablica sadrži tri stupca. U

prvom stupcu naveden trenutak u kojem se u sustavu dogodila promjena, te broj korisnika

igara HS i SS3. Drugi stupac sadrži podatke o vremenu koje je bilo potrebno algoritmu da

napravi raspodjelu mrežnih resursa, kao i prosječnu MOS ocjenu za trenutne korisnike pri

jednolikom raspoređivanju, dok treći stupac sadrži podatke o vremenu koje je bilo potrebno

algoritmu da napravi raspodjelu mrežnih resursa, kao i prosječnu MOS ocjenu za trenutne

korisnike za izvođenje algoritma opisanog u sklopu ovog rada. U zadnjem retku tablice

navedeni su prosječna MOS ocjena, te vrijeme izvođenja algoritma od početka rada sustava

do kraja.

41

Trenutak promjene u sustavu

(s) i broj korisnika igara

Jednoliko raspoređivanje Algoritam opisan u ovom

radu

MOS Vrijeme

(ms) MOS Vrijeme(ms)

Trenutak: 0

Broj korisnika HS: 4

Broj korisnika SS3: 11

4.0091 ≈0 4.0874 2648

Trenutak: 5



4.0441 ≈0 4.4041 1622

Trenutak: 7



3.9350 ≈0 4.0119 3041

Trenutak: 12



3.7267 ≈0 3.7301 207

Trenutak: 22



3.3955 ≈0 3.3971 213

Trenutak: 30



3.4870 ≈0 3.5074 2677

Trenutak: 32



4.0372 ≈0 4.0949 2665

Trenutak: 45



4.0558 ≈0 4.1313 2851

3.8813 ≈0 3.9205 1990

Tablica 6.1.1 Rezultati izvođenja simulacije raspodjele mrežnih resursa pri korištenju igara zasnovanih na računalnom oblaku, koja je opisana u [13]

42

6.2 Metodologija testiranja i analiza rezultata testiranja usluge

YouTube

U sklopu ovog rada provedeno je testiranje usluge YouTube. Testiranje se sastoji od niza

mjerenja čiji je cilj pokazati način ponašanja usluge YouTube kroz mjerenje njenog ponašanja

pri različitim uvjetima u mreži. Klijenti prilikom mjerenja simultano dijele isti mrežni kanal, te

je potrebno ispitati utjecaj njihovog simultanog korištenja resursa na KPI-eve. Mjerenja su

provedena u kontroliranom laboratorijskom okruženju bez vanjskih utjecaja na mrežu.

Slika (Slika 4.3.1) prikazuje sustav u kojemu su obavljena mjerenja. Testiranje uključuje

mjerenje određenih ključnih indikatora performansi prilikom korištenja usluge YouTube na tri

različita uređaja. Prilikom mjerenja su korištena dva Android uređaja (Samsung Galaxy i Sony

Xperia) te jedan uređaj sa IoS operacijskim sustavom (Apple iPhone5S). Ograničenja mrežnih

resursa na željene vrijednosti postignuta su korištenjem uređaja Net.Storm.

Prilikom mjerenja uređaj Net.Storm spojen je na Internetsku mrežu, te za cilj ima ograničiti

njenu propusnost. Na izlaz uređaja Net.Storm spojen je na usmjeritelj koji omogućava

mobilnim uređajima koji sudjeluju u mjerenjima pristup mrežnim resursima putem WiFi-ja.

Slika 4.3.1 Predočenje sustava u kojemu su izvršena mjerenja

43

Mjerenja su izvršena u dva različita scenarija. U prvom scenariju sva tri mobilna uređaja

istovremeno pristupaju istim mrežnim resursima, te se međusobno bore za njih, dok se u

drugom scenariju ukupna propusnost mreže podijeli na tri jednaka dijela, te se svakom

mobitelu omogući pristup trećini ukupnih mrežnih resursa iz prvog scenarija. Mjerenja su

izvršena za propusnosti mreže od 9, 6 i 3 Mbit/s.

Detaljniji opis scenarija, te načina testiranja i obrade rezultata biti će opisan na primjeru za

propusnosti od 9 Mbit/s. U prvom scenariju uređaj Net.Storm namješten je da na svoj izlaz

propušta samo tu količinu mrežnih resursa, dok usmjeritelj omogućava uređajima istovremeni

pristup mrežnim resursima. Mjerenje se provodi za vrijeme izvođenja 5 videa (koji se pokreću

jedan za drugim u sklopu YouTube playlist-a) ukupnog trajanja 11-12 minuta. Prilikom

izvođenja mjerenja uređaji istovremeno pristupaju istim mrežnim resursima, te se za njih

međusobno natječu. Prilikom izvođenja testiranja korištenjem StatsForNerds usluge u sklopu

YouTube-a omogućuje se prikaz ključnih indikatora performansi za vrijeme izvođenja YouTube

videa, te se korištenjem Recordable Free Android aplikacije, odnosno integriranog snimača

zaslona na iPhone uređaju snima zaslon uređaja. Nakon obavljenih mjerenja snimke zaslona

se obrađuju korištenjem aplikacije ViQMon (engl. video quality monitoring tool) koja je

razvijena u suradnji s tvrtkom Ericsson Nikola Tesla. Izlazni podaci nakon završetka obrade

podataka su upravo ključni pokazatelji performansi, čiji su rezultati prikazani u idućem

poglavlju. U sklopu drugog scenarija način bilježenja ključnih indikatora performansi, te način

obrade tih podataka identičan je kao i za prvi scenarij. Jedina razlika je što je propusnost mreže

sada ograničena na 3 Mbit/s prema svakom klijentu pojedinačno, što izbacuje element

kompetitivnosti, odnosno natjecanja za mrežne resurse.

Rezultati provedenog testiranja prikazani su tablicama u nastavku rada. Prva tablica

predstavlja rezultate testiranja pri ograničenju propusnosti mreže na 9 Mbit/s za sva tri

uređaja, te 3 Mbit/s prema svakom uređaju pojedinačno. Druga tablica prikazuje rezultate

izvođenja pri propusnosti mreže od 6 Mbit/s, te 2 Mbit/s za svaki uređaj pojedinačno. Treća

tablica prikazuje rezultate izvođenja za 3 Mbit/s za sva 3 uređaja, te po 1 Mbit/s za svaki uređaj

koji sudjeluje u testiranju. U tablicama su za svaki uređaj, te pri svakom od navedenih uvjeta

u mreži navedeni izmjereno prosječno početno kašnjenje, prosječno trajanje zastajkivanja,

izmjereni bitrate, te prosječna MOS ocjena. U zadnjem retku tablice navedeni su prosječni

rezultati za sva tri uređaja pri određenim uvjetima u mreži.

44

U tablici (Tablica 6.2.1), koja prikazuje rezultate izvođenja pri ograničenju propusnosti na 9

Mbit/s, te 3 Mbit/s za svakog od tri uređaja koji sudjeluju u provođenju testiranja, moguće je

usporedbom rezultata uočiti jako mala odstupanja za dva scenarija u kojima je mjerenje

provedeno. Za oba scenarija MOS ocjena je na svakom uređaju izrazito visoka, te je propusnost

u oba scenarija dovoljna za neometanu funkcioniranje usluge YouTube.

9 Mbit/s zajedno 9 Mbit/s

podijeljeno

iPhone

Prosječno početno kašnjenje (s) 0.000 0.000

Prosječno trajanje zastajkivanja (s) 0.000 0.000

Prosječan bitrate (kbit/s) 1988.116 1963.577

Prosječna MOS ocjena 4.772 4.747

Samsung

Galaxy





Sony

Xperia





Prosjek za

sva tri

uređaja





Tablica 6.2.1 Rezultati provedenog testiranja pri ograničenju propusnosti mreže na 9 Mbit/s (lijevi stupac) za sve korisnike, odnosno 3 Mbit/s za svakog pojedinačnog korisnika (desni stupac).

45

U tablici (Tablica 6.2.2), u kojoj su prikazani rezultati testiranja pri ograničenju propusnosti na

6 Mbit/s, odnosno 2 Mbit/s za svaki uređaj, moguće je usporedbom rezultata testiranja za oba

scenarija uočiti bolje funkcioniranje usluge YouTube u scenariju gdje uređaji dijele mrežne

resurse. Usluga YouTube ponaša se tako da nakon početnog punjenja međuspremnika ostatak

zahtijevanog sadržaja preuzima periodički uz zadržavanje određenog stupnja popunjenosti

međuspremnika [19]. Zbog takvog načina rada, moguće je da sva tri uređaja koja sudjeluju u

testiranju u različitim trenucima ulaze u aktivnu fazu preuzimanja, te je zato percepcija

dostupnosti mrežnih resursa bolja.


podijeljeno

iPhone





Samsung

Galaxy





Sony

Xperia





Prosjek za

sva tri

uređaja






46

U tablici (Tablica 6.2.3), u kojoj su prikazani rezultati testiranja pri ograničenju propusnosti na

3 Mbit/s, odnosno 1 Mbit/s za svaki uređaj, moguće je usporedbom rezultata testiranja za oba

scenarija uočiti bolje funkcioniranje usluge YouTube u scenariju gdje uređaji dijele mrežne

resurse. Razlika u rezultatima znatno je izraženija nego pri izvođenju istih testova uz veću

propusnost mreže.


podijeljeno

iPhone





Samsung

Galaxy





Sony

Xperia





Prosjek za

sva tri

uređaja






47

Zaključak

Većina današnjeg Internet prometa otpada na video sadržaj koji prenose popularne Over The

Top usluge. Prilikom posluživanja korisnika takvih usluga, u svrhu prilagodbe kvalitete sadržaja

kojim se poslužuju klijenti trenutnim uvjetima u mreži, često se provodi nadzor na klijentskoj

strani. Takav način nadzora ne pruža potpuni uvid u stanje u mreži. S druge strane, poslužitelji

Interneta, zbog enkripcije sadržaja koji se prenosi Internetom, nisu u mogućnosti pratiti

iskustvenu kvalitetu koju doživljavaju korisnici zbog nedostatka uvida u indikatore kvalitete na

razini korisničke aplikacije. Uvid u indikatore kvalitete na korisničkoj strani omogućio bi

poslužiteljima Interneta procjenu QoE-a, te samim time i upravljanje mrežnim resursima

bazirano na QoE-u. Rješavanju problema nedostatka potrebnih informacija Internet

poslužitelja o indikatorima kvalitete posluženog sadržaja na strani korisnika i manjku

informacija o trenutnom stanju u mreži kojima ne mogu pristupiti davatelji Over The Top

usluga moguće je pristupiti na dva načina. Jedan od načina na koje se pristupa rješavanju ovog

problema je traženje povezanosti između metrika na razini mreže, i onih na razini aplikacije.

To se često postiže uz pomoć strojnog učenja ili analitičkih modela. Drugi način je postizanje

suradnje između ISP-a i OTT-a u svrhu kvalitetnije raspodjele mrežnih resursa. Suradnja

između ISP-a i OTT-a sastoji se u razmjeni informacija o trenutnom stanju u mreži ili o

indikatorima kvalitete posluživanja na strani korisnika, ovisno o tome je li komunikacija

ostvarena u smjeru od ISP-a prema OTT-u, ili od OTT-a prema ISP-u.

48

Literatura

[1] Cisco, „The Zettabyte Era: Trends and Analysis“ Cisco, Tech. Rep., 2015. [Online].

Available: http://www.cisco.com/c/en/us/solutions/collateral/service-

provider/visual-networking-index-vni/VNI_Hyperconnectivity_WP.pdf. Zadnji pristup:

06.09.2018. godine.

[2] Sieber, Christian, et al. "The cost of aggressive HTTP adaptive streaming: Quantifying

YouTube's redundant traffic." Integrated Network Management (IM), 2015 IFIP/IEEE

International Symposium on. IEEE, 2015

[3] Hossain, Md Motaleb. "A Literature Review of OTT-related Policy and Regulatory

Issues.", 2016. godina.

[4] Dan York: „What is an Over-The-Top (OTT) Application or Service? - A Brief

Explanation“, Dostupno na: http://www.disruptivetelephony.com/2012/07/what-is-

an-over-the-top-ott-application-or-service-a-brief-explanation.html. Zadnji pristup:

25.6.2018. godine.

[5] DiGiorgio, Rinaldo, and Michael S. Bender. "Secure token device access to services

provided by an internet service provider (ISP)." U.S. Patent No. 6,385,729. 7 May 2002.

[6] Irena Oršolić, „Quality of Experience Monitoring and Management of Video Streaming

in Future Networks“. Projekt Q-MANIC, financiran od strane Hrvatske zaklade za

znanost QoMoVid: QoE Monitoring Solutions for Mobile OTT Video Streaming, kojeg

financira tvrtka Ericsson Nikola Tesla.

[7] Sebastian Möller, Patrick Le Callet and Andrew Perkis, editors. 2013. Qualinet White

Paper on Definitions of Quality of Experience. Technical Report Version 1.2. European

Network on Quality of Experience in Multimedia Systems and Services.

[8] Alreshoodi, Mohammed, and John Woods. "Survey on QoE\QoS correlation models for

multimedia services." arXiv preprint arXiv:1306.0221 (2013).

[9] M. Katsarakis, R. Teixeira, M. Papadopouli, and V. Christophides, “Towards a Causal

Analysis of Video QoE from Network and Application QoS,” in Proceedings of ACM

SIGCOMM Workshop on QoE-based Analysis and Management of Data

Communication Networks, Internet-QoE 2016. ACM, 2016, pp. 1–6.

http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/VNI_Hyperconnectivity_WP.pdf

http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/VNI_Hyperconnectivity_WP.pdf

http://www.disruptivetelephony.com/2012/07/what-is-an-over-the-top-ott-application-or-service-a-brief-explanation.html




49

[10] Varela, M., Zwickl, P., Reichl, P., Xie, M., & Schulzrinne, H. (2015, June). From

service level agreements (SLA) to experience level agreements (ELA): The challenges

of selling QoE to the user. In Communication Workshop (ICCW), 2015 IEEE International

Conference on (pp. 1741-1746). IEEE.

[11] Orsolic, I., Pevec, D., Suznjevic, M., & Skorin-Kapov, L.. A machine learning

approach to classifying YouTube QoE based on encrypted network traffic. Multimedia

tools and applications, 76(21), 22267-22301, 2017. godina.

[12] Lea Skorin-Kapov, Maja Matijašević, Martin Varela, Markus Fiedler:

„Cooperative Quality of Experience Management for Interactive Cloud-Based

Multimedia Applications in Mobile Networks„. Tehnički izvještaj X.Y: projekt Q-MANIC,

financiran od strane Hrvatske zaklade za znanost, 2015

[13] Filip Jurčić, Sven Srebot, Dunja Šašić: „Izrada simulacije raspodjele mrežnih

resursa pri korištenju igara zasnovanih na računalnom oblaku temeljene na modelima

iskustvene kvalitete“, FER, 2018.

[14] Srebot Sven. Seminar: „Primjena metaheuristike tabu pretraživanja pri

rješavanju problema raspodjele mrežnih resursa kod igara zasnovanih na računalnom

oblaku“, FER, 2017.

[15] „Steam“ - http://store.steampowered.com/

[16] Slivar, Ivan, Lea Skorin-Kapov, and Mirko Suznjevic. "Cloud gaming QoE models

for deriving video encoding adaptation strategies." Proceedings of the 7th

International Conference on Multimedia Systems. ACM, 2016.

[17] Hua-Jun Hong, Chih-Fan Hsu, Tsung-Han Tsai, Chung-Ying Huang, Kuan-Ta Chen,

Cheng-Hsin Hsu. Enabling Adaptive Cloud Gaming in an Open-Source Cloud Gaming

Platform. IEEE Transactions on Circuits and Systems for Video Technology, Vol. 25,

2015.

[18] Cisco Systems, 2013. Cisco visual networking index: Forecast and methodology,

2012-2017, San Jose, CA, USA: Tech. Rep..

[19] Marko Jurković. Seminar: „Iskustvena Kvaliteta usluge YouTube prilikom

simultanog pristupa više klijenata s dijeljenim mrežnim resursima“, FER, 2017.

http://store.steampowered.com/

50

[20] Krishnappa, D. K., Bhat, D., & Zink, M. (2013, October). DASHing YouTube:

An analysis of using DASH in YouTube video service. In Local Computer Networks

(LCN), 2013 IEEE 38th Conference on (pp. 407-415). IEEE.

[21] Añorga, J., Arrizabalaga, S., Sedano, B., Alonso-Arce, M., & Mendizabal, J.

(2015, July). YouTube’s DASH implementation analysis. In 19th International

Conference on Circuits, Systems, Communications and Computers (CSCC) (pp. 61-66).

[22] Seufert, M., Egger, S., Slanina, M., Zinner, T., Hossfeld, T., & Tran-Gia, P.

(2015). A survey on quality of experience of HTTP adaptive streaming. IEEE

Communications Surveys & Tutorials, 17(1), 469-492.

[23] Hoßfeld, T., Egger, S., Schatz, R., Fiedler, M., Masuch, K., & Lorentzen, C.

(2012, July). Initial delay vs. interruptions: Between the devil and the deep blue sea. In

Quality of Multimedia Experience (QoMEX), 2012.Fourth International Workshop on

(pp. 1-6). IEEE.

[24] International Telecommunication Union - Telecommunications Sector (ITU-T)

Recommendation P.800.1, 2006. Mean Opinion Score (MOS) Terminology. [online]

Preporuka dostupna na: http://www.itu.int/rec/T-REC-P.800.1-200303-S/en

[25] Akamai, “Akamai Inc. SureRoute, ”http://www.akamai.com/dl/

featuresheets/fs_edgesuite_sureroute.pdf.

[26] Schwarzmann, Susanna, Thomas Zinner, and Ognjen Dobrijevic. "Towards a

Framework for Comparing Application-Network Interaction Mechanisms." 28th

International Teletraffic Congress (ITC 28), 2016. Vol. 3. IEEE, 2016.

[27] Zhao, Tiesong, Qian Liu, and Chang Wen Chen. "QoE in video transmission: A

user experience-driven strategy." IEEE Communications Surveys & Tutorials 19.1

(2017): 285-302.

[28] “EU COST Action IC1304 ACROSS: Autonomous Control for a Reliable Internet

of Services,” http://www.cost-across.nl/, 2013-2017.

[29] Varela, Martín, Skorin-Kapov, Lea and Ebrahimi, Touradj. "Quality of Service vs.

Quality of Experience", in "Quality of Experience: Advanced Concepts, Applications and

Methods", T-Labs Series in Telecommunication Services, S. Möller and A. Raake (eds.),

Springer, March 2014, pp. 85-96.

http://www.itu.int/rec/T-REC-P.800.1-200303-S/en

http://www.akamai.com/dl/featuresheets/fs

http://www.akamai.com/dl/featuresheets/fs

51

[30] Varela, Martın, et al. "QoE-defining a user-centric concept for service quality."

Multimedia Quality of Experience (QoE): Current Status and Future Requirements

(2015): 1-5.

[31] Skorin-Kapov, Lea, et al. "Approaches for utility-based QoE-driven optimization

of network resource allocation for multimedia services." Data traffic monitoring and

analysis. Springer Berlin Heidelberg, 2013. 337-358.

[32] Frank, Benjamin, et al. "Collaboration Opportunities for Content Providers and

Network Infrastructures." ACM SIGCOMM ebook on Recent Advances in Networking

1.1 (2013): 305-377.

[33] Fielding, Roy, et al. Hypertext transfer protocol--HTTP/1.1. No. RFC 2616. 1999.

[34] Naylor, David, et al. "The cost of the S in HTTPS." Proceedings of the 10th ACM

International on Conference on emerging Networking Experiments and Technologies.

ACM, 2014.

[35] Wamser, F., Casas, P., Seufert, M., Moldovan, C., Tran-Gia, P., & Hossfeld, T.

Modeling the YouTube Stack: from Packets to User-Perceived Quality.

52

Sažetak

Cilj ovog rada je ispitati doprinos suradnje između davatelja usluge i mrežnog operatora u

korištenju odabranih usluga u Internetu. U sklopu rada opisana je motivacija koju davatelji

usluga i mrežni operatori imaju za postizanje suradnje prilikom upravljanja QoE-om. Navedeni

su postojeći načini funkcioniranja usluga u Internetu, te su opisani načini na koje je moguće

postići suradnju između davatelja usluge i mrežnog operatora prilikom upravljanja QoE-om.

Također, u sklopu rada je kroz prototip suradnje između davatelja usluge i mrežnog operatora

opisan način na koji se njihova suradnja može odvijati.

Ključne riječi: kooperativno upravljanje QoE-om, davatelj usluge, mrežni operator, motivacija,

suradnja

53

Summary

A key goal in the scope of this thesis is to examine the benefits of cooperation between service

providers and network providers in the usage of Internet services. This thesis specifies the

incentives for cooperative QoE management from the perspective of service providers and

network providers. Following an overview of different QoE management mechanisms, this

thesis contains a description of a prototype of QoE centered network management, that

implements a way that cooperation can be achieved.

Key words: cooperative QoE management, service provider, network provider, incentives

54

Skraćenice

QoS Quality of Service Kvaliteta usluge

QoE Quality of Experience Iskustvena kvaliteta

ISP Internet service provider Poslužitelj Interneta

IoS Internet of Service Internet kao usluga

API Application programming interface Aplikacijsko programsko sučelje

FPS Frames per Second Broj okvira u sekundi

CDN Content Delivery Network Mreža za dostavu sadržaja

DASH Dynamic Adaptive Streaming over HTTP Dinamičko prilagodljivo strujanje putem

protokola HTTP

KPI Key Performance Indicators Ključni pokazatelji performansi

MPD Media Presentation Description Datoteka s opisom sadržaja

55

Dodatak

Upute za korištenje programske podrške

Određene parametre korištene prilikom pokretanja prototipa suradnje između davatelja

usluge i mrežnog operatora koji je razvijen u sklopu ovog rada potrebno je zadati prije

njegovog pokretanja, inače njegovo izvođenje nije moguće. Također, moguće je podesiti koji

algoritam će obavljati raspodjelu mrežnih resursa, te način izvođenja samog algoritma

raspodjele mrežnih resursa.

Prije pokretanja komunikacijskog modula klijenta za igranje zasnovano na računalnom oblaku

nužno je putem datoteke „config.txt“ zadati IP adresu na kojoj se nalazi komunikacijski modul

QoE optimizacijske funkcije, odnosno websocket server, te ključ koji se koristi za pristup

SteamApi usluzi. Izgled takve datoteke prikazan je na slici (Slika 1).

Slika 1 Izgled „config.txt“ datoteke koju koristi komunikacijski modul Steam klijent entiteta za zadavanje SteamApi ključa, te IP adrese na kojoj se nalazi websocket server s kojim klijent

komunicira.

U sklopu rada su razvijena dva različita algoritma raspodjele mrežnih resursa. Prvi je

jednostavan, te samo pridijeli svim klijentima jednaku količinu mrežnih resursa, dok je drugi

algoritam složeniji, te svoju raspodjelu temelji na modelima QoE-a. Odabir algoritma koji će

obavljati raspodjelu mrežnih resursa obavlja se promjenom vrijednosti u datoteci imena

„AlgConfig.txt“, te se upisivanjem broja „1“ u nju definira izvođenje algoritma jednake

raspodjela resursa svim klijentima, dok upisivanje broja „2“ dovodi do izvođenja drugog

algoritma prilikom raspodjele resursa. Način izvođenja drugog algoritma moguće je dodatno

podesiti, što je opisano u nastavku teksta.

Izvođenje algoritma za raspodjelu mrežnih resursa koji je dio komunikacijskog modula OTT

entiteta moguće je podesiti putem nekoliko datoteka. U ulazne podatke koje je potrebno

56

zadati algoritmu prije izvođenja spadaju koeficienti koji se koriste pri određivanju MOS

ocjene specifični za svaku igru, te funkcija cilja čijoj maksimizaciji izvođenje algoritma teži.

Izgled datoteke „coefficientConfig.txt“ koja sadrži koeficiente specifične za svaku igru

prikazan je na slici (Slika 2).

Slika 2 Izgled datoteke „coefficientConfig.txt“ koja sadrži podatke o koeficientima potrebnim za izračunavanje MOS ocjena igara koje su dostupne u sustavu.

Redovi datoteke (ima ih onoliko koliko sustav podržava igara) sadržavaju koeficiente

potrebne za izračunavanje MOS ocjena koji su specifični za svaku igru. Koeficienti se u

datoteku zapisuju redoslijedom od 𝛼1 − 𝛼6 prema formuli (1).

Podatak o tome kojoj funkciji cilja se želi težiti prilikom izvođenja algoritma zapisan je u

datoteku „optimizationCriteriaFunction.txt“. Za pravilan rad algoritma potrebno je zadati

samo prvi red datoteke koji određuje indeks funkcije koja se želi koristiti, dok ostali redovi

opisuju koji indeks predstavlja koju funkciju. Primjer ove datoteke prikazan je na slici

(Slika 6.3).

Slika 3 Datoteka „optimizationCriteriaFunction.txt“ koja definira željenu funkciju cilja.

Documents

Prototip suradnje između davatelja usluge i mrežnog Srebot diplomski 2018.pdf · Kooperativne metode upravljanja QoE-om ... Prvi studijski slučaj su igre zasnovane na računalnom