TALLINNA TEHNIKAÜLIKOOL

Raadio- ja sidetehnika instituut

Kõnekvaliteet pakettsidevõrgus Kood: IRT84LT Jarmo Inkinen Töö on tehtud telekommunikatsiooni õppetooli juures Juhendaja Avo Ots Kaitsmine toimub raadio- ja sidetehnika instituudi kaitsmiskomisjonis Autor taotleb tehnikateaduste magistri nimetust Esitatud: .05.2004. Kaitsmine: 02.06.2004.

Tallinn 2004

2

REFERAAT Käesoleva magistritöö eesmärgiks on kirjeldada kvaliteetse kõneedastuse tagamise ja mõõtmise meetodeid IP-põhises pakettsidevõrgus. Kõne kvaliteetseks edastamiseks iseloomustatakse parameetreid, mis kõneedastust mõjutavad ning selgitakse, mille alusel seada kvaliteedikriteeriumid. Välja on toodud, kuidas IP-põhises pakettside-võrgus kõneedastust prioritiseerida ning tutvustatud mudeleid ja meetodeid, mille alusel on võimalik saadud kõnekvaliteeti objektiivsete mõõtmistega hinnata. Magistritöös käsitletud kvaliteedi mõõtmine ja tulemuste interpreteerimine põhineb kogemustel testvõrkudest ja missioonikriitilisest kohtvõrgust - autor viibis praktikal British Telecomis Frankfurdis ja Ipswichis, kvaliteedi mõõtmisi teostati ka Tallinnas asuvas ettevõtte missioonkriitilises võrgus. Kuna selgus, et testitud missioonikriitiline võrk ei vastanud seatud nõuetele, võiks võrgu seadistamisel ja uute testide läbiviimisel juhinduda töös toodud soovitustest. Magistritöös esitatud põhimõtteid võib kasutada ka suuremamahuliste projektide planeerimisel ja realiseerimisel nii koht- kui ka laivõrkudes. Töö maht on 109 lehekülge, sisaldades 38 joonist, 7 tabelit ja 3 lisa. Võtmesõnad: IP telefonisüsteem, QoS, häiringufaktor, MOS, kõnekvaliteedi mõõtmine, kõnekvaliteedi garanteerimine.

3

ABSTRACT The goal of this master’s thesis - Improvement of Speech Quality in Packet-based Networks - is to describe the methods of guaranteeing and measuring voice quality in IP networks. Parameters having an impact on the voice quality have been described and the fundamentals of how to set the quality criteria are discussed. Prioritization of voice quality in packet-based networks is examined and the models and objective methods to measure voice quality are introduced. The master’s thesis relies on the knowledge and experience from test networks as well as mission critical networks, analyzing the aspects of voice quality measurement and interpreting the measured results. The author of this paper visited British Telecom in Frankfurt and spent a three week placement in Ipswich to get the practical experience; the quality was also measured in a mission critical network of a company located in Tallinn. As a result of the investigation it is evident that the mission critical network of the above mentioned company did not meet the requirements that had been set. To improve the situation and to test the network again, the recommendations of the current thesis can be used. The principles of the master’s thesis could also be used for planning and implementing considerably bigger projects embracing local area networks as well as wide area networks. The thesis consists of 109 pages, including 38 figures, 7 tables and 3 annexes. Keywords: IP telephony, QoS, impairment factor, MOS, measuring voice quality, guaranteeing voice quality.

4

EESSÕNA Viimastel aastatel on andmesidevõrgud laienenud väga kiiresti ning mõjutanud kõiki eluvaldkondi. Kohtvõrgud, mis kasutavad Interneti protokolli IP, põhinevad parimal võimalikul teenuste mudelil. Kuid tekkinud on mitmeid rakendusi, mis seavad olemasolevatele võrkudele suuremaid nõudeid – näiteks IP telefon on saanud sagedaseks kõneaineks. Vaatamata IP telefonisüsteemi paljudele eelistele eelkõige lisateenuste näol, ei ole need veel tavalisi PBX-süsteeme välja vahetanud. Tavalise süsteemi all peetakse silmas ahelkommuteeritud telefoniühendusi, IP telefonisüsteemi korral edastatakse pakettidena samas võrgus nii andmeid kui ka kõnet. Viimasel juhul ei piisa aga parimast võimalikust teenusest, vaja on veel paremaid teenuse efektiivsuse tagamise mudeleid – vastasel juhul tekib probleem lõpp-kasutajate vahelise kvaliteedi tagamisega ning tulemuseks on rahulolematud kõneteenuse kasutajad. Sobiva mudeli valimiseks ja kvaliteedi tagamiseks peab teadma, kuidas ja millised parameetrid kõnekvaliteeti häirivad ning vastavalt seatud nõuetele tuleb kõnet võrgus muule liiklusele eelistada. Mingi meetodi alusel tuleks saadud tulemust ka hinnata. Nimetatud küsimustega käesolev magistritöö tegelebki – mis tingimustel oleksid kõnelejad rahul, mida peab selle saavutamiseks tegema ja kuidas kontrollida, et oleme vajaliku saavutanud. Praktilise kogemuse saamiseks on autor katsetanud prioriteetide seadmist ning kõnekvaliteedi hindamist ühe ettevõtte võrgus, käinud visiidil British Telecomi laboris Frankfurdis ja viibinud kolmenädalasel praktikal British Telecom Exact teadus- ja uuringukeskuses Ipswichis. Siinkohal tänan British Telecomi, kes viis mind kokku magistritöö teemaga seotud spetsialistidega, organiseeris praktikakoha ning võimaldas vajalikke testseadmeid kasutada, eriti aga tänud praktikat juhendanud Dr. Cleola van Eijl’i; tööandjat, kes mind vajalike infotehnoloogiliste seadmetega varustas ning võimaldas igapäevase töö kõrvalt magistritööd kirjutada; kolleege, kes mind selles ettevõtmises toetasid ning magistritöö juhendajat Avo Ots’a.

5

SISUKORD Referaat 2 Abstract 3 Eessõna 4 Sisukord 5 Kasutatud lühendid 7 Sissejuhatus 8 1. IP telefoniteenus – eelised, rakendamisega seotud ohud ja probleemid 9 2. Kõnekvaliteedi mõiste 12 3. Kõnekvaliteedi tagamine IP-põhises kommunikatsioonivõrgus 15 3.1. Kvaliteedikriteeriumid kõne toimumiseks pakettsidevõrgus, kvaliteeti

mõjutavad parameetrid 17 3.1.1. Võrgu kvaliteediparameetrid 17 3.1.2. Rakenduse kvaliteediparameetrid 17 3.2 Teenuse efektiivsuse parameetrid 20 3.2.1. Teenuse nõuded enne kõne algatamist 21 3.2.2. Teenuse nõuded algatamise ajal 21 3.2.3. Teenuse nõuded seansi ajal 21 3.2.3.1. Kõne kodeerimine ja käitlemise hilistumine 22 3.2.3.2. Hilistumise varieerumine 23 3.2.3.3. Paketikadu 23 3.2.3.4. Kaja 24 3.2.3.5. Kõnekaadri pakkimine ja puhverdamine 24 3.2.4. Teenuse nõuded peale seansi lõpetamist 25 3.2.5. Lõpp-kasutaja kvaliteeditaju mõjutavad parameetrid 25 3.3. Liikluse vormindamise protsessid QoS tagamiseks 26

3.3.1. Diferentseeritud teenused 26 3.3.1.1. Liikluse klassifitseerimine (classification) 26

3.3.1.2. Liikluse märkimine (marking) 27 3.3.1.3. Liikluse ümbermärkimine (remarking) 33 3.3.1.4. Liikluse silumine (shaping) 33

3.3.1.5. Järjekorra moodustamise strateegiad (queuing) 33 3.3.1.6. Pakettide edastamata jätmine (dropping) 33

3.3.2. MPLS (Multiprotocol Label Switching) 34 3.3.3. Intergreeritud teenused, RSVP (Resource reservation protocol) 35

3.3.4. Prioriteetide seos erinevate meetodite korral 36 3.3.5. Liikluse vormindamise protsessid - kokkuvõte 37

4. Kõnekvaliteedi hindamise meetodid 38 4.1. E-mudel kõnekvaliteedi hindamiseks 42 4.1.1. Häiringud IP telefonisüsteemis ja E-mudel 45 4.1.1.1. Hilistumisest tingitud häiringute arvestamine 45 4.1.1.2. Kajast tingitud häiringute arvestamine 47

6

4.1.1.3. Kõne kompressioonist tingitud häiringute arvestamine 50

4.1.1.4. Paketikadudest tingitud häiringute arvestamine 53 4.2. Cisco häiringufaktorite hindamise meetod ICPIF 56

4.3. PESQ - objektiivne võrdlusel põhinev meetod 59 4.4. IP telefoniteenuse kõnekvaliteedi analüüs 59

4.5. Transmissioonivõrgu planeerimine PESQ ja E-mudel abil 60 5. Kvaliteedi garanteerimine võrguseadmetes 3Com näitel 62 5.1. Tavaline meetod 62 5.2. Edasiarendatud meetod 63 5.3 Switch’i konfigureerimise sammud prioritiseerimise aktiveerimiseks 65 6. Kõnekvaliteedi hindamine missioonikriitilises võrgus 67 6.1. Kõnele esitatavad kvaliteedikriteeriumid 67 6.2. Testimise metodoloogia 67 6.3. Testid kõnekvaliteedi hindamiseks 69

6.3.1. Test 1 69 6.3.2. Test 2 70 6.3.3. Test 3 70 6.3.4. Näide kaja häiringu testimisest 75 6.4. NetIQ Chariot ja E-mudeli kvaliteedihinnangu võrdlus 76 6.5. Kokkuvõte 76 7. Kokkuvõte 78 8. Viiteloetelu 80 Lisa A. E-mudel (ITU-T soovitus G.107) 82 A.1 Erinevate parameetrite tähendusi 82 A.2 Referentsühenduses kasutatavad parameetrid 83 Lisa B. Cisco häiringufaktorite hindamise meetod ICPIF 85 Lisa C. 3Com Superstack 3 Switch 4400 - vaikimisi määratud seadistused 109

7

KASUTATUD LÜHENDID ATM – Asynchronous Transfer Mode / asünkroonne edastusviis; DSCP – Differential Services Code Point / prioritiseerimismeetod; ERL - Echo Return Loss / kaja kadu meediamuunduris või kajakustutajas; ETE – End-to-End / lõpp-kasutajate vaheline; ETSI - European Telecommunication Standard Institute / Euroopa Telekommu-nikatsiooni Standardiinstituut; ICPIF - The Calculated Planning Impairment Factor / häiringufaktor; IKM - (PCM – Pulse Code Modulation ) - impulss- koodmodulatsioon; IP – Internet Protocol / Interneti protokoll; ISO – International Organization for Standardization / Rahvusvaheline Standardi-organisatsioon; ITU – International Telecommunication Uninon / Rahvusvaheline Sideliit; MOS – Mean Opinion Score / keskmine subjektiivne kõnekvaliteedi hinnang; MOS-CQE - Mean Opinion Score, Conversational, Estimated / hinnang subjektiivsele kõnekvaliteedile objektiivse mõõtmismeetodi abil; MPLS – Multiprotocol Lablel Switching / QoS tagamist võimaldav tehnoloogia; OLR – Overall Loudness Rating / summaarne helivaljus sõltuvalt RLR ja SLR parameetritest; OSI - Open Systems Interconnection / avatud süsteemide ühendamise raammudel; PBX – Private Branch Exchange / telefonikeskjaam; PLC – Packet Loss Concealment / paketikao avastamise ja parandamise meetod; PSTN – Public Switched Telephone Network / üldkasutatav telefonivõrk; QoS – Quality of Service / teenuse kvaliteet; RLR – Receive Loudness Rating / vastuvõetud helivaljus muutus; RSVP – Resource Reservation Protocol / ressursi hõivamise protokoll; RTP – Real Time Protocol / reaalajaprotokoll; SLR – Send Loudness Rating / edastatava helivaljuse muutus; STMR – Sidetone Masking Rating / kõrvaltoonide maskeeruvus; TCLw - weighted terminal coupling loss / kaja kadu digitaalse telefoniaparaadi analoogosas; TCP – Transmission Control Protocol / edastusohje protokoll, Interneti standardne edastuskihi protokoll; TELR – Talker Echo Loudness Rating / teatud kajasummutus; TOS, ToS – Type of Service / teenuse tüüp; UDP – User Datagram Protocol / datagrammiprotokoll, Interneti standardne transpordikihi protokoll; VAD – Voice Activity Detection / kõne olemasolu detektor; WEPL – Weighted Echo Path Loss / kõikide võimenduste ja kadude summa; VLAN – Virtual Local Area Network / virtuaalne kohtvõrk; VLAN ID - Virtual Local Area Network Identification / virtuaalse kohtvõrgu identifikaator; VoIP – Voice over IP / kõneedastus üle IP protokolli.

8

SISSEJUHATUS Kõne, andmete ja multimeedia edastamine samas pakettsidevõrgus annab kasutajatele ja ettevõtetele uusi lisavõimalusi, kuid seab ka võrgule suuremaid nõudmisi. Kõnekommunikatsiooni korral on tegemist vahetu suhtlemisega, mistõttu edastuse käigus tekkinud häired avaldavad kõnekvaliteedile suurt mõju. Häiringufaktoreid on mitmeid – pakettsidevõrgus peamiselt hilistumine, paketikadu ja hilistumise varieeruvus. Et häiringute mõju vähendada, peab enne telefoniteenuse rakendamist pakettsidevõrgus valima meetodi, millega kõnet muu liikluse kõrval eelistada, selleks peab aga täpselt teadma, millised on kvaliteetseks edastuseks vajalikud kriteeriumid. Peale võrgu konfigureerimist tuleb testida, kas võrk on valmis edastama kõnet sellise kvaliteediga, mis vastaksid meie poolt seatud tingimustele. Paraku tõstatab see järgmise probleemi, sest subjektiivseid teste kõnekvaliteedi hindamiseks ei ole alati võimalik korrata või on see liiga kulukas – vajame objektiivseid, automatiseeritud protsesse, mis aitaksid hinnata võrgus saavutatavat kõnekvaliteeti juba enne, kui IP telefonisüsteem on paigaldatud ning kasvõi peale väiksegi muudatuse tegemist võrgu konfiguratsioonis või topoloogias. Käesolevas magistritöös selgitatakse esmalt IP telefonisüsteemi mõistet ning süsteemi rakendamisega seotud probleeme ning ohte (p.1). Töö keskendub aga kvaliteediprobleemidele – p.2 selgitab kõnekvaliteedi mõistet ning p.3 selgitab kvaliteedikriteeriumite seadmise põhimõtteid tulenevalt teenuse efektiivsuse parameetritest, tutvustatakse liikluse vormindamise protsesse. Peatükk 4 on kõnekvaliteedi hindamise meetoditest, käsitledes põhjalikumalt E-mudeli ja PESQ tööpõhimõtteid, selgitatakse, kuidas nende abil saab seatud nõuetele vastavust kontrollida ja kuidas mõjutavad erinevad parameetrid kõnekvaliteeti. Kvaliteedi garanteerimist kirjeldab p.5, mille kirjutamisel on kasutatud 3Com seadmeid ja nende konfigureerimise näiteid. Kui soovitud kvaliteedi tagamiseks vajalikud nõuded on välja selgitatud ja tingimuste täitmiseks vajalikud parameetrid leitud, peab enne telefonisüsteemi rakendamist eeldatavat kvaliteeti hindama. Võrgus sünteetilise liikluse tekitamise abil kvaliteedi hindamist kirjeldab p.6, kasutades missioonikriitilises võrgus testimiseks NetIQ Chariot tarkvara. Lisa A selgitab E-mudeli referentsparameetreid. Et autor viibis praktikal British Telecomis Ipswichis ning uuris Cisco marsruuterites kasutatavat kvaliteedi hindamise meetodit ICPIF, on lisas B toodud inglisekeelne aruanne, mis sisaldab meetodi kirjeldust, läbiviidud teste ja mõningaid olulisemaid tähelepanekuid. Lisa C toob ära 3Com seadmete vaikimisi määratud kvaliteedi garanteerimise seadistused.

9

1. IP TELEFONITEENUS – EELISED, RAKENDAMISEGA SEOTUD OHUD JA PROBLEEMID

VoIP (Voice over Internet Protocol) ehk kõneedastus üle Interneti protokolli tähendab reaalaja kõnesignaalide ja sellega seotud juhtinformatsiooni edastamist üle IP pakettsidevõrgu (kas avaliku või privaatvõrgu). IP telefonide ning IP-põhise juurdepääsu-, transpordi- ja kontrollvõrgu kooslust nimetatakse IP-põhiseks telefonisüsteemiks. IP telefoniteenuse eesmärgiks on avatud, paindlik realisatsioon PSTN-tüüpi (Public Switched Telephone Network) teenustest, kasutades IP-põhist juhtinformatsiooni, marsruutimist, protokolli ja liideste tehnoloogiaid. Paketipõhine kõneedastus on tänapäeval kiiresti arenev tehnoloogia ning mitmete prognooside kohaselt hakkab aina enam ja enam välja vahetama seni kasutusel olnud PSTN peal ahelkommutatsiooniga töötavaid tavalisi PBX-süsteeme. Kuna aga IP on saamas põhiliseks protokolliks nii audio, video kui ka andmeside edastamiseks, on mõistlik ehitada nende jaoks ühtne võrk, mistõttu tekib probleem kvaliteedi tagamisega reaalajas edastust nõudvatele rakendustele. Tavalise andmete edastamise puhul (www-leheküljed, e-post jms) ei ole üldjuhul oluline, kas pakett jõuab kohale kaks sekundit hiljem või varem, kuid on ilmselge, et kõne puhul pole see sobilik. Küllap on väga paljudel igapäevast telefoniteenust kasutades kogemusi kõne hilistumiste ja kajadega, mis tekivad mõnikord näiteks üleookeaniliste kaugekõnede korral. Analoogilised hilistumisest, paketikadudest jms tingitud häiringud tekivad, kui kõneside kvaliteeti kommunikatsioonivõrgus ei tagata. Lühidalt öeldes tähendab VoIP telefonikõne muundamist digitaalseks, et seda oleks võimalik transportida arvutivõrkudes, mis annab telefonisidega võrreldes eeliseid. Kui ahelkommutatsiooni puhul luuakse iga kõne tarbeks nn. ahel ning kõneside kvaliteet on tagatud kogu kõne kestel, ei ole see nii aga pakettsidevõrgu korral, kui just ei kasutata emuleeritud ahelaid (nagu näiteks ATM korral). Pakettkommutatsiooni puhul jaotatakse kõne pakettidesse ning saadetakse ükshaaval vastuvõtja poole, mida võib transpordi käigus marsruutida erinevaid teid pidi ning vastavaid meetmeid rakendamata pole edastus garanteeritud. Käesolevas lõputöös ei ürita autor veenda lugejat tavasüsteemi IP telefonisüsteemiks ümber vahetama ning seetõttu ei peatuta töös väga pikalt teemal „miks on IP telefonisüsteem hea“ ning kellel tingimata tasuks süsteemi rakendada. Kuid lühidalt peaks siiski uurima, miks selline tehnoloogia üldse eksisteerib ja edu on saavutanud. Kaks peamist põhjust, mille kasuks IP telefonisüsteemi korral peamiselt räägitakse, on kulude kokkuhoid ja uued teenused. Esimene vastab neist tõele ainult juhul, kui ettevõte geograafiline paiknevus ei piirdu ühe asukohaga ning kasutatakse helistamiseks palju avaliku PSTN teenuseid. Kokkuhoid tuleks sel juhul kõne edastamisel mitte üle avaliku PSTN-i minutimaksu makstes vaid kasutades juba olemasolevat või andmeside jaoks loodavat pakettsidevõrku. Räägitakse ühtsest võrgust või konvergentsist (kõne koos video ja andmesidega).

10

Traditsiooniline PSTN kommuteerimissüsteem on oma olemuselt monoliitne s.t. kõik tema funktsionaalsus on integreeritud ühte võrguelementi. See julgustab tootjaid kasutama tootjapõhiseid liideseid ja protokolle, mistõttu on ka teenuseid raske juurde luua ning võrgu ja süsteemi areng ja laienemine on piiratud. IP-põhise võrgu korral on tegemist avatud, standardiseeritud liideste ja protokollidega. IP-telefonisüsteemide puhul on seatud suund avatuse poole ning „pehmete“ ehk tarkvaraliste rakenduste suunas. Kasutatakse nn. softswitch’e ehk tarkvaral põhinevaid võrguelemente, mis pakuvad kõne kontrollifunktsiooni reaalajalise paketipõhise kõneedastuse korral (RTP üle UDP üle IP –põhised andmevood). „Pehmed“ lahendused ja avatus loovad võimaluse lisada süsteemile lihtsamalt parandusi, lisateenuseid, uusi protokolle jms. Kuid siiski on paljud lahendused tootjapõhised, lisaks on praegu kasutusel ka standardiseeritud protokollide erinevaid versioone, mis omavahel ei pruugi töötada. Olulisteks eelisteks võib pidada ka võrgu hallatavust, konfigureeritavust ja kaugtöö kasutamise võimalust. [4,5] Hallatavus (maintainability) – lihtsus ja kiirus, millega rikke korral funktsionaalsus taastatakse ja ka võime vigu ennetada, põhjuseid diagnoosida, ennetava tegevuste rakendamine. Oluliste parameetritena võib siinjuures välja tuua keskmise parandusaja, vea lokaliseerimise kiiruse, varuseadmetele üleminekuaja ja elementide kuumvahetatavuse toetuse. Konfigureeritavus – kasutajate lisamine, nt kolimise korral muudatuste tegemine, marsruutimine, juurdepääsuõiguste loomine, muud teenused. Kaugtöö kasutamise all on eelkõige silmas peetud võimalust virtuaalse privaatühenduse kaudu näiteks kodust töötades IP-põhist töötelefoni kasutada. Kindlasti tekib süsteemi rakendamisel erinevaid probleeme, kuid vältimatud küsimused IP telefonisüsteemi rakendamisel on töökindlus, käideldavus, turvalisus ja kvaliteet. Töökindlus, käideldavus [4] Töökindlus on funktsionaalüksuse (etteantud otstarbe täitmiseks võimeline riistvara-, tarkvara- või nende ühismoodustis) võime antud tingimustes mingi etteantud ajavahemiku jooksul täita nõutavat funktsiooni. Ehk IP telefonisüsteemi kontekstis telefonide, võrguseadmete ja tarkvara töökindlus. Käideldavus tähendab süsteemi takistuseta kättesaadavust volitatud kasutajale ja nende teovõimet, sõltudes ka keskmisest parandusaja pikkusest rikke korral. Kuna PSTNi peetakse kõrge töökindlusega süsteemiks, peab ka IP telefoniteenus, mis asendab olemasoleva teenuse, olema vähemalt võrdväärse töökindlusega. Turvalisus Turvalisus on süsteemi võime kaitsta oma objektide (ressursside ja informatsiooni) terviklust ja konfidentsiaalsust. Tuleb silmas pidada, et erinevate (andmeside- ja

11

kõneside) võrkude liitmise korral on vale konfiguratsiooniga kohtvõrgus lihtne kõnesid pealt kuulata. Loomulikult pole ka PSTN võrgu puhul see väga keeruline, kuid kommuteerimissõlmedele on ettevõttes juurdepääs siiski üldjuhul piiratud. Arvutivõrgule on aga juurdepääs enamusele arvutiga töötavatest inimestest. Arvuti kui universaalne tööriist on ideaalne vahend õige konfiguratsioonita võrgus võõraste kõnede salvestamiseks. Kvaliteet Kvaliteet on resultaat, mis rahuldab meie poolt eeldatavaid vajadusi ehk toote ja teenuse või protsessi omadus, mida soovitakse saavutada. Kuidas mõistetakse seda kõneteenuse kontekstis, millised on kriteeriumid ja kuidas neid hinnatakse, annavad selgitust järgnevad peatükid. Magistritöö eesmärk ongi viimase probleemi - kvaliteedi – olemuse selgitamine: millised parameetrid kõneteenuse kvaliteeti mõjutavad, milliste võrgujõudluste meetrika väärtuste vahemikus on võimalik saavutada kõrge või vajalik kvaliteet pakettsidevõrgus. Kuidas saab andmevoogusid transportivat võrku efektiivselt kasutada ehk prioritiseerida kõnet muu liikluse hulgas ja milliste meetoditega kontrollida, et saadud tulemus vastab eelnevalt seatud nõuetele. Töö keskendub just kõneseansi ajal kvaliteeti mõjutavate parameetrite uurimisele. Antud tulemusi võib hiljem kasutada ka laiahaardelisemate projektide koostamisel, mis võivad hõlmata ka teisi kvaliteedi tagamise tehnoloogiaid (näiteks Multiprotocol Label Switching, MPLS).

12

2. KÕNEKVALITEEDI MÕISTE Mida tähendab “kõnekvaliteet”? Nagu juba eelmine peatükk kokkuvõtlikult ütles, on kvaliteet üldises mõttes toote, teenuse või protsessi omadus, mida soovitakse sellelt tootelt või teenuselt saada/saavutada ehk resultaat, mis rahuldab meie poolt eeldatavaid vajadusi. Kvaliteedi mõiste on aegade jooksul muutunud, varasemalt on peetud üldlevinud kvaliteedikriteeriumiks kõigest toote omadust täita spetsifikatsiooni nõudeid. Kuid kvaliteet on seotud oskusega luua tooteid, mis on vastavate karakteristikute ja omadustega, mis on täpselt optimeeritud tarbija soovide ja nõuete rahuldamiseks. IP telefoniteenuse kontekstis peavad kõnekvaliteedi hindamiseks olema eelnevalt seatud mingid vajadused – see tähendab kellegi või millegi poolt esitatud nõudmisi. Kust tekivad vajadused ja nõudmised? Nõudmiste allikaid võib olla mitmeid – spetsifikatsioonid, standardid kui ka subjektiivsed tahtmised. Siit tekib küsimus, millised vajadused ja nõudmised kehtivad IP telefoniteenuse ja kõneside jaoks. Peavad ju selleks olema mingid kriteeriumid ning vastavalt ka mõõdetavad parameetrid. Kvaliteedi hindamiseks ja võrdlemiseks tuleb mõõdetavaid parameetreid arvestades ning teatud algoritme kasutades (väärtuste lihtne või kaalutud liitmine, hägune loogika jms) leidma ühe kvaliteeti iseloomustava arvu. Vastavalt Allan Soikoneni magistritööle [26] võib kõnekvaliteedi olemust kirjeldada järgnevalt. „Kõnekvaliteet on keeruline psühho-akustiline fenomen inimese kõnetajumise protsessis. Oma omaduselt on ta subjektiivne, sest iga inimene tajub kõne kvaliteeti erineval viisil. Isegi üheainsa inimese kõne tajumine võib varieeruda sõltuvalt meeleolust, huvidest ja ootustest. Kõnekvaliteet on ainult üks komponent kahesuunalisest kõneleja poolt tajutavast kommunikatsioonikvaliteedist, iseloomustades ainult ühesuunalist kõneülekannet kõnelejast kuulajani. Kõnekvaliteet ei arvesta efekte nagu kaja rääkija poolel või ülekandest tingitud hilistumised. Pigem mõjutavad seda psühholoogilised faktorid: arusaadavus – tajutud vastuvõetav kvaliteet; loomulikkus – kõneleja hääle loomulikkus; helivaljus – absoluutne helivaljuse nivoo kuulaja poolel.“ Joonisel 2.1 on esitatud mõned kõnekvaliteedi parameetrid kommunikatsioonivõrgus:

13

Joonis 2.1. Kõnekvaliteedi aspektid [1,26] Kui vaadelda faktoreid, mis määravad ära kasutaja rahulolu, siis on olemas üksteisega seotud kvaliteedi mõisted, mis mängivad oma rolli hindamise protsessis. „Neist esimene on teenuse omakvaliteet ehk mõõdetud kvaliteet (intrinsic quality of service). Teenuse omakvaliteet saavutatakse järgmise tööga:

- transportvõrgu ja võrguelementide tehnilise disainiga, mis määravad ära läbi võrgu teostatud ühenduse tehnilised karakteristikud;

- võrguelementide ja transportvõrgu õige ja õigeaegne dimensioneerimine, mis tagaks võrgus piisavalt ressursse nõudluse rahuldamiseks.

Teenuse mõõdetud kvaliteet leitakse tavaliselt tema toimingulist jõudlust iseloomustavate parameetrite väärtuste mõõtmisega. Teiseks mõisteks on tajutud teenuse kvaliteet (perceived QoS). Tajutud kvaliteet tuleneb teenuse tegelikust kasutamisest, mille aja jooksul kasutajad kogevad teenuse omakvaliteedi mõju nende kommunikatsioonitegevusele. Mõju sõltub ka konkreetsest keskkonnast ja kliendi ootustest. Ootused on tavaliselt määratud kliendi eelnevate kogemustega analoogsete telekommunikatsiooniteenuste kasutamisel. Teenuse omakvaliteedi ja tajutud teenuse kvaliteedi vahel on oluline erinevus. Kasutaja poolt tajutud kvaliteet on lõppkokkuvõttes see, mis määrab ära, kas kasutaja on teenusega rahul või mitte. Teenuse mõõdetud kvaliteet on suurel määral ära määratud konkreetse võrgu disainiga. Omakvaliteedi määravad ära näiteks sellised parameetrid nagu: kuidas on kõned marsruuditud, kas valitud numbrit transleeritakse või mitte, /---/ milliseid signaliseerimisprotokolle kasutatakse jne. Taolised parameetrid määravad ära sellised näitajad nagu: milline keskmine numbri valimise järgne viide (PDD) on saavutatav mingil marsruudil. Numbri valimise järgne viide ja kõneühenduse loomiseks kuluv aeg on näitajad, mis ei jää kasutajale märkamatuks ja kuuluvad seega tajutava teenuse kvaliteedi kategooriasse. Piiri, millest alates lugeda numbri valimise järgset viidet

14

ning kõneühenduse loomiseks kuluvat aega rahuldavaks või ebarahuldavaks, ei ole. Sellised piirid kujunevad suurel määral tehnoloogilistes võimalustes ja – lahendustest lähtuvalt ning teiselt poolt sõltuvad kasutajate harjumustest ja ootustest.“ [26] Seega, enne kõneteenuse kvaliteedile hinnangu andmist tuleb paika panna kvaliteedikriteeriumid. Et hinnata pakettsidevõrgu valmisolekut kvaliteetse kõneteenuse edastamiseks, peab välja selgitama, millised on parameetrid, mis kõneedastust IP pakettsidevõrgus mõjutavad. Nendele küsimustele toob vastuse peatükk „Kvaliteedikriteeriumid kõne toimumiseks pakettsidevõrgus, kvaliteeti mõjutavad parameetrid“ (p 3.1) ning peatükk „Teenuse efektiivsuse parameetrid“ (p 3.2).

15

3. KÕNEKVALITEEDI TAGAMINE IP-PÕHISES KOMMUNIKATSIOONIVÕRGUS

Interneti Protokoll IP on loodud pakkumaks parimat võimalikku teenust, mis tähendab, et kõiki saadetavaid pakette koheldakse võrdselt. Kui aga võrgupakettide liiklus kasvab, tekivad ummikud ning võrguseadmed võivad mõningad paketid edastamata jätta. Kuid reaalaja multimeedia jaoks (s.h. kõneülekanne) pole selline paketiülekande viis sobilik. Põhjalik selgitus pole vist siinkohal vajalik: näiteks e-posti või failiülekande korral pole mõningane pakettide hilistumine või vales järjekorras saabumine probleem, kuid ilmselt ei saa suurte hilistumiste ja nihete korral rääkida kvaliteetsest kõneülekandest, kui vajatakse reaalajalist edastust. Seega vajame meetodit, millega tagada kõneliiklusele teatud kvaliteet.

QoS rakendustega on võimalik:

� reserveerida kanalimahtu; � hoida ära edastavate andmete kaotamist ja vigastamist võrkudes; � hoida ära ja kontrollida võrgu ummistusi; � piirata viiteid andmete edastamisel; � formeerida võrgu andmevoogusid; � rakendada andmete prioritiseerimist üle võrgu. [23]

Kindlasti ei hoia QoS ära ummistust, vaid lisab ummistatud liidestele intelligentsuse, võimaldades võrguseadmetel järjekordade tekitamise ja pakettide edastamata jätmise kohta otsuseid teha. Vastavalt võrgu oskusele osutada nõutavat lõpp-kasutajate vahelist (edaspidi: ETE ehk end-to-end) teenust teatud hilistumise, paketikao, pakettidevahelise nihke ja edastuskiiruse garanteerimisega, võib teenused jagada kolmeks klassiks. IP põhistes võrkudes on võimalik kasutada kolme erinevat teenuste kategooriat:

� parim võimalik teenus (Best-Eeffort Service); � integreeritud teenus (Integrated Service); � diferentseeritud teenus (Differentiated sevice). [23]

Parim võimalik on lihtne teenuste tagamise mudel, mille kohaselt rakendusprogramm saadab andmeid siis, kui seda vajalikuks peab ja suvalistes kogustes, ilma et võrgule sellest eelnevalt teataks. Võrk edastab saadud andmehulgad hetkel, mil seda võrgu ressursid võimaldavad, seega ilma igasuguse garanteeritud infoedastuskiiruseta. Integreeritud teenused Integreeritud teenused tähendab mitmete teenuste kasutamise mudelit rahuldamaks erinevaid QoS nõudeid. Rakendusprogramm nõuab võrgult teatud tasemel teenust, enne kui alustab andmete edastamist võrku. Nõuet teostatakse spetsiaalset signaliseerimist kasutades, andes ülevaate edastatavatest andmetest ja selle nõuetest kanalimahule ning võrgu viidetele. Rakendusprogramm alustab eelnevalt määratletud andmete edastust alles siis, kui on saanud selleks kinnituse võrgult.

16

Võrk teostab andmete edastusloa otsustamist tuginedes rakendusprogrammilt saadud informatsioonile ja kasutavatele võrguressurssidele. Võrk garanteerib lubatud QoS tagamise seni, kuni rakendusprogramm saadab kokkulepitud andmeid. Võrk teostab edastamist põhinedes antud andmevoole ja kasutades selleks pakettide klassifitseerimist ning intelligentseid järjestusmeetodeid. [21] Integreeritud teenused kasutavad ressursi hõivamise protokolli RSVP (RFC 2205). Meetodi miinusteks on vajadus reserveerimise nõudeid igas seadmes pidevalt uuendada, mis lisab võrgule liiklust, ühtlasi suurendab võrgusõlmede keerukust, et mitmeid reserveerimisi meeles hoida. Kuna seisundi uuendusi tuleb perioodiliselt signaliseerida kõikides marsruuterites, siis voogude mitmekordistumisel pole süsteem paindlik. Ka peavad kõik seadmed toetama RSVP-d ja olema suutelised kvaliteedinõudeid signaliseerima. Seepärast ei ole IP telefonisüsteemi korral meetod sobilik. [8] Diferentseeritud teenused Alternatiivina iga voo teenindamisele võib kõik sarnased vood klassifitseerida ning võimaldada erinevatele klassidele sarnane edastuskvaliteet. Erinevus integreeritud teenustega seisneb selles, et QoS-i nõudev rakendusprogramm ei lepi saatmisprotsessi võrguseadmega eelnevalt kokku. Diferentseeritud teenuste korral üritab võrk edastada andmepakette vajaliku QoS-iga kasutades igast paketist pärinevat sellekohast informatsiooni. Otsustamiseks vajalikku informatsiooni pakettide päistes on mitmeid: saatja või vastuvõtja IP aadress, erinevad prioritiseerimisbitid jm. Sellist laadi teenuseid on hea kasutada kuhjuma kippuvate andmemahtude edastamiseks, kuna kasutatakse küllaltki jämedamoelist andmepakettide klassifitseerimist. IP prioritiseerimine Pakettide edastamist teostavad võrguseadmed saavad järjestamise algoritmides määrata paketi prioriteedi. IP prioritiseerimist võidakse määrata kas võrguseadme poolt eelnevalt määratletud tingimuste alusel või kasutaja lõppseadme poolt. Kasutaja poolt määramine saab toimuda valikuliselt, kuid kui samas eksisteerib ka võrgupoolne IP prioriteedi määramine, siis kasutaja määratud prioriteet kaotab kehtivuse. [21]

Diferentseeritud teenuste ning IP prioritiseerimise põhimõtteid on kirjeldatud peatükis 3.3 „Liikluse vormindamise (conditioning) protsessid QoS tagamiseks“, kvaliteediprotsesside määramist kohtvõrgus peatükis 5 „Kvaliteedi garanteerimine võrguseadmetes 3Com näitel“.

17

3.1 KVALITEEDIKRITEERIUMID KÕNE TOIMUMISEKS PAKETTSIDE-VÕRGUS, KVALITEETI MÕJUTAVAD PARAMEETRID

Kuid millist kvaliteeti on vaja tagada? Selleks peab enne paika panema kõne toimumiseks vajalikud kvaliteedikriteeriumid ja selgitada, mis parameetrid kvaliteeti mõjutavad. Kuna teenuse kvaliteeti mõjutavad nii rakenduse kvaliteet kui ka kommunikatsioonivõrgu kvaliteet, siis vaatleme järgnevalt võrgu ja rakenduse taseme kvaliteediparameetreid, mis mõjutavad kõnesidekvaliteeti pakettisidevõrgus. 3.1.1 Võrgu kvaliteediparameetrid [24] Võrgu QoS lubab defineerida mitmeid erinevatel parameetritel põhinevaid kvaliteedimeetrikaid. Kuid sellised QoS mudelid on üles ehitatud kasutades võrgukeskseid kvaliteediparameetreid (kasutatav ribalaus, hilistumine, paketikadu, hilistumiste varieeruvus). Rakenduste arendajad ja kasutajad vajavad kvaliteedimudeleid, mis vastavad rohkem nende vajadustele ja mida väljendatakse erinevate jõudluse karakteristikutega nagu vastuse aeg päringule, ennustatavus, stabiilne tajutav kvaliteet. Need on meetrikad, mida nimetatakse rakenduse kvaliteediks, kuid mõistet defineerida on raske, sest kvaliteeti mõjutavad tegurid on väga hägused ning sõltuvad eelpool mainitud reaalajaliste rakenduste taksonoomiast. Kõige olulisemad IP võrgu jõudlust iseloomustavad meetrikad ja kõige olulisemad lõppkasutajate rakenduste vahelist kvaliteeti mõjutavad faktorid on järgmised. Ribalaius – määrab ära lõppkasutajate vahelises võrgus rakendusele või andmevoole võimaldatava edastusmahu. Hilistumine – võrguhilistumine tähendab aega, mis kulub võrgul andmete edastamiseks vastuvõtjani. Võrguhilistumine koosneb füüsilisest levikiirusest, käitlemisest tulenevatest hilistumistest ja erinevatest järjekordadest võrguseadmetes. Hilistumiste varieerumine – esineb tavaliselt marsruuterite puhvrite ületäitumisel. Hilistumiste varieeruvuse taluvus on reaalajalise infoedastuse korral madal. Paketikadu – esineb tavaliselt võrgu ülekoormatuse korral. Reaalajaliste andmete korral ei näita paketikao protsent üksi mõju kvaliteedile, oluline on ka paketikao muster. Paketikao muster/periood – paketikadu avaldab suuremat mõju, kui kaotsi lähevad järjestikused paketid. Mida suuremate vahedega ja vähem pakette korraga kaotsi läheb, seda vähem avaldab see mõju kõnekvaliteedile. 3.1.2 Rakenduse kvaliteediparameetrid Rakenduse kasulikkus ehk kasutajale kvaliteetse teenuse osutamine on funktsioon väga paljudest objektiivsetest ja subjektiivsetest faktoritest (ülesande karakteristikud, kasutajate karakteristikud, kasutusolukord jms) ning on väga raskelt defineeritavad. Et

18

paremini mõista, kuidas rakenduse karakteristikud määravad oma kvaliteedinõudeid, üritame eelmainitud faktorite omadusi uurida. Ülesande karakteristikud – kuna tegemist on interaktiivse infoga, siis on see tundlik lõpp-kasutajate vahelisele hilistumisele, hilistumiste erinevusele ja paketikadudele, kuigi on ka veaparandusmeetodeid, mis hilistumise arvelt suudavad kaotsiläinud pakette taastada. Seega tuleb väga suurel määral arvestada võrgu kvaliteediparameetritega [24]. Kasutaja karakteristikud – sõltub kasutaja eeldustest, mis on väga oluline aspekt, sest teatud juhtudel on kasutajad tolerantsed ka väga suurte häiringute suhtes, teises olukorras aga mitte. Kasutaja on rahul, kui võrgult ja rakendustelt saadav kvaliteet vastab tema ootustele ja eeldustele. Need ootused on määratud kogemustega, mis tulenevad sarnaste teenuste kasutamisest erinevates situatsioonides (GSM, PSTN), majanduslikust aspektist (odav, kallis, kohalik või kaugekõne, PSTN, VoIP üle Interneti) või alternatiivsete vahendite puudumisest. Kuna IP telefoniside korral kohtvõrgus on tegemist sisuliselt olemasoleva teenuse asendamisega, oodatakse siiski samaväärset kvaliteeti. Muud faktorid – vanus, rahvus, kuulmisomadused jne. Võrgu QoS meetrikad ei pruugi tingimata kokku langeda rakenduse QoS parameetritega. Kasutaja tajub ainult teenuse kvaliteedi langust ning ei erista, kas põhjus on rakenduse jõudluses või kommunikatsioonivõrgu kvaliteedis. Rakenduse tasemel mõõdetavad jõudluse meetrikad on kirjeldatud alljärgnevalt: Läbilaskevõime – efektiivne ribalaius, mis rakendusele võimaldatakse. Hilistumine – ETE hilistumine rakenduse tasemel. Teenus käideldavus ja jätkusuutlikkus (continuity) – kirjeldab teenuse olemasolu nõuet aktsepteeritud kvaliteediga. Kõige olulisemad faktorid, mis jätkusuutlikkust mõjutavad, on

� info või andmete kadu - kasutaja tasemel ei pruugi info kadu kattuda andmepakettide kaoga võrgu tasemel. Tegemist võib olla näiteks andmete kaoga rakenduse tasemel (signaali terviklikkuse kadu kodeerimise tagajärjel). Seepärast on informatsiooni kadu subjektiivse olemusega. Võib tekkida ka vastupidine olukord, kus andmesidevõrgus esineb kadusid, kuid kasutaja neid ei taju (tolerantsus);

� hilistumiste varieeruvus – teatud piirini saab hilistumise varieeruvust kompenseerida pakettide puhverdamisega vastuvõtja poolel, liialt suur varieeruvus tähendab, et paketid ei pruugi olla enam kasutuskõlblikud. Puhverdamise piir on seotud lisaviidete tekkimisega.

� DoS ja turvalisus – DoS (Denial of Service) põhjustab teenuse katkemise sõltumata transpordi-infrastruktuurist, mis pakub vajalikku QoS. Vajalik rakenduskihi näitaja on ka turvalisus.

Ülalmainitud QoS meetrikaid ei mõjuta üksnes võrgupõhised meetrikad. Faktorid, mis mõjutavad muutusi jõudlusemeetrikates – operatsioonisüsteemi/tarkvara suutmatus

19

rakendust toetada, rakenduste ja protokollikihtide väärkasutus, kasutajakeskkond (vigane riistvara) jne. Paljudel juhtudel suudetakse parameetreid mõõta just rakenduse, mitte võrgukihi tasemel. [24]

20

3.2 TEENUSE EFEKTIIVSUSE PARAMEETRID Peamisteks teenuse efektiivsuse parameetriteks, mida tuleb arvestada, on võrgu käideldavus, valimistooni käideldavus, kõne algatamise protsessi efektiivsus ja algatatud ning lõpetatud kõnede suhe (ebaõnnestunud kõnede määr), ühesuunaline kõne hilistumine, kõnekvaliteet objektiivsete ja subjektiivsete mõõtmistega jne. Kõne töötlemise, ülekande ja kvaliteedi aspekte kirjeldab standard EVS 874:2003. [3] Järgnevalt vaatleme kõneülekande mudelit ning teenuse kvaliteedinõudeid kõne erinevatel etappidel.

Joonis 3.1. Kõneülekande mudel [29] Joonisel 3.1 on toodud ülevaatlik põhimõtteline kõneülekande mudel. Analoogsignaal muundatakse kõigepealt digitaalseks, kodeeritakse ja kõnekaadrid pannakse pakettidesse, mis tähendab UDP kapseldamist RTP pakettidesse ning saadetakse üle IP võrgu teele. Kommunikatsioonivõrgus lisanduvad kommuteerimis-, marsruutimis- ja järjekordadest tingitud hilistumised ning paketikaod. Vastuvõtja poolel toimub dekodeerimine, pakettide lahtikaaderdamine, lahtipakkimine ning reaalajalisuse ja interaktiivsuse säilitamiseks rakendatakse kajakustutust ja hilistumise varieeruvuse kompensatsiooni, mis võib omakorda viiteid suurendada.

21

3.2.1. Teenuse nõuded enne kõne algatamist Enne kõne algatamist on mõõdetavad kaks põhilist parameetrit:

a. valimistooni käideldavus s.t. helistajal on mulje, et teenus on kättesaadav b. võrguressursi ja arvutiressursi käideldavus kõne algatamiseks. See hõlmab

ühtlasi ka informatsiooni kogumist helistaja id osas (nt E.164 telefoninumber, e-posti aadress, URL), info käitlemist, et leida parim võimalik tee RTP/UDP/IP seansi avamiseks ning ühendamaks helistaja helistatavaga.

PSTN puhul on võrgu planeerimisel lähtutud seisukohast, et tõenäosus, et kõik potentsiaalsed helistajad korraga toru tõstavad, on väike. IP võrgu korral võib võrgus liikuda nii andme- video- kui ka audioseansid ning tõenäosus, et võrgu lõppseadme küljes olevale kliendile võib ressursipuuduse korral kõne algatamine ebaõnnestuda, on suur, kui

a. ei planeerita lisaressursse, b. ei reserveerita ressursse või ei diferentseerita ressursi kasutajate prioriteete.

(p.3.3) 3.2.2. Teenuse nõuded kõne algatamise ajal Üks olulisemaid nõudeid kõne algatamise ajal on kõne käitlemise efektiivsus, mis hõlmab endas kahte faktorit:

a. kõne algatamise aeg – (PDD – post dial delay) – mõõdetakse alates viimase numbri valimisest helisemistooni kuulmiseni. IP telefoni korral võib see jääda vahemikku 500ms kuni 10 s, sõltuvalt võrgu ja digitaalse signaali käitlemise ressurssidest,

b. samaaegsete kõnede toimumine ilma ooteajata. Sõltub kõnekeskuse protsessori jõudlusest, mälust, ressursist jne.

Kõne algatamiselt võib tähtsamate numbrite korral (näiteks hädaabi) kasutada numbripõhist prioriteetimist. Vastavalt ITU-T E.721 soovitusele on keskmine vastuvõtusignaali hilistumine helistajale (hetk, kui helistaja saab aru, et helistatav on toru tõstnud ning esimene kõnesignaal jõuab helistajani) 750ms kohalike kõnede, 1,5 s riigisiseste kõnede korral, 2,0 s rahvusvaheliste kõnede korral. PDD 3s kohalike kõnede, 5 s riigisiseste, 8 s rahvusvaheliste kõnede korral. [29] 3.2.3. Teenuse nõuded seansi ajal Kõneliiklus seab võrgule omad kriteeriumid. Isegi kui võrk on häälestatud võimaldamaks kõrget läbilaskevõimet, ei pruugi kõneside kvaliteet olla piisav. Kõne on reaalajaline ning kasutab edastuseks reaalajalist transpordiprotokolli RTP. RTP on seansikihi protokoll, mis omakorda kasutab transpordiks ühenduseta UDP protokolli, mille korral kaotsiläinud pakette uuesti ei saadeta. Interaktiivsed kõned ei talu suuri hilistumisi - mida aktiivsem on vestlus, seda vähem talutakse hilistumist. Kasutajale on olulisteks kvaliteedifaktoriteks lisaks kõne hilistumisele veel kõne selgus, sobiv helivaljus, kaja moonutuste ja müra puudumine. Seetõttu tuleb peale VoIP seansi algatamist pakettidesse jagatud kõne sihtpunkti toimetada ilma signaali rikkumata. Nõuete täitmine on veel olulisema tähtsusega, kui

22

kasutatakse erinevaid lisateenuseid nagu helistaja numbri edastamine, kõnede ootele jätmine, konverentskõnede moodustamine jms. Magistritöö keskendubki seansi ajal esitatavate nõuete uurimisele. 3.2.3.1. Kõne kodeerimine ja käitlemise hilistumine Käitlemise hilistumine hõlmab analoog/digitaal muundamise, kaadrite ja pakettide moodustamise, veaparandusmehhansimide ja kadude kompenseerimise tehnikate kasutamise meetodid. Kuid mainitud protsessid käivitatakse vastuvõtjas vastupidises suunas ning lisandub veelgi viiteid, ka puhverdamisest tingitud hilistumine. Lisaks mainitud konstantsetele viidetele tuleb arvestada ka muutuvate võrgutranspordist tulenevate hilistumistega (pakettide edastamine, marsruutimine, sõltuvalt võrguseadmete jõudlusest, koormatusest jne) ja signaali füüsilise levimisega (piiratud signaali füüsikaliste omadustega). Koodekit kasutatakse kõne kodeerimisel ning dekodeerimisel, teisendades seda digitaalseks ning eristatakse kahte liiki koodekeid: lainekuju koodekid (waveform codecs) ja kõne kompresseerimise koodekid (speeh compression codecs). Lainekuju koodek säilitab sisendsignaali lainekuju ja opereerib väljavõtete (sample) alusel (G.711, G.726). Kõne kompresseerimise koodekid on madala bitikiirusega koodekid, mis töötavad teistsugusel põhimõttel, kasutades kõne kodeerimisel ja kompresseerimisel inimkõne mudeleid, mis baseeruvad sisendväljavõtete kaadrite analüüsil. Edastatakse ainult kõnemudeli parameetrid, mitte lainekuju. Kõne kompresseerimise koodekit nimetatakse ka vokoodriks. Mõned põhiliselt kasutatavatest koodekitest on toodud alljärgnevas tabelis:

�������� ������ ��������������

���������� �������� ��� �

!��������� �������� ��� �

!"���� #$������ ���$��

�%�!�&��� '������ ���$(�!�

�����)� ��#������ ���$#� �

!�&��� *�#������ ���$#� �

Tabel 3.1. ITU-T G.7xx seeria koodekeid [24, 29] Ühesuunalist hilistumist nimetatakse mouth-to-ear (M2E) või end-to-end (ETE) hilistumiseks ning näitab hilistumist hetkeni mil üle loodud ühenduse on vastuvõtja poolel kuulda signaali saatja poolelt. ETE hilistumine peaks jääma ITU-T G.114 kohaselt alla 150 ms. Igal koodek tekitab erineva viite. Üldise reeglina ei tohiks G.711 puhul kodeerimine, pakettide moodustamise jms hilistumine ning kohaliku võrgu edastus kummalgi pool ületada 15% ühesuunalisest koguhilistumisest, mis 150ms hilistumist silmas pidades (joonis 3.1) tähendab maksimaalselt 22,5ms. Transpordivõrgu jaoks jääb seega maksimaalselt 105 ms. Koodeki G.729 korral võib protsent ulatuda isegi kuni 60% (s.h. kodeerimisele ca 15ms), mis jätab transportvõrgu jaoks 60ms. [29]

23

Täpsem analüüs, kuidas kodeerimine ja hilistumine kõnekvaliteeti mõjutavad (p 4.1.1). 3.2.3.2 Hilistumise varieerumine Paketi hilistumise varieerumine tähendab, et saabuvad datagrammid ei saabu õiges järjekorras. Datagrammi saates lisab saatja RTP päisesse ajatempli, mille abil on vastuvõtjas võimalik paketi suhtelist leviaega arvutada. Kui sama kõne korral on erinevatel datagrammidel erinevad edastusajad, siis on tegemist hilistumise varieerumisega. IP telefonid saadavad kõnedatagramme välja konstantselt (G.711 puhul iga 20 ms tagant), vastuvõtja eeldab datagrammide saabumist iga 20 ms tagant. Et varieeruvuse mõju vähendada, kasutatakse telefonides puhverdamist („Kõnekaadri pakkimine ja puhverdamine “, p. 3.2.3.5). [29] Hilistumise mõju kõnekvaliteedile vt p 4.1.1. 3.2.3.3. Paketikadu VoIP kasutab UDP-d, et transportida RTP-sse kapseldatud kõnekaadreid. Paketikadu esineb puhvrite üleummistuste korral kas liigse liikluskoormuse või üheaegsete TCP seansside arvukuse tõttu. Lisaks võib bittide vigasuse tekkimine ülekandel põhjustada UDP- pakettide kao. Kuigi iga RTP datagramm sisaldab järjekorranumbrit, et rakendus suudaks andmekadusid ja vales järjekorras saabunud pakette avastada, ei ole neid pakette ajapuuduse tõttu võimalik enam uuesti saata. Paketikadu ei ole ainult häiriv, ühtlasi võib jääda mulje, et kõne on katkenud.

Et vähendada paketikao mõju IP-kõnesidele, võib kasutada erinevaid meetodeid:

a. nn. mugavusmüra kaotatud pakettide asemel, b. eelmise helisegmendi kordamine, c. kõnesüntees, interpoleerimine, d. biti, kõnekaadri või paketitasemel liiasuse või veaparanduse kasutamine.

Liiasuse kasutamisel jagatakse kõnekaader mitmeks segmendiks, ning edastatakse mitte-järjestikuliselt. Sel juhul on paketid vaja vastuvõtjas esmalt õigesse järjekorda panna, mis tähendab helisignaali rekonstrueerimise aja kasvu, kuid purskelise paketikao tagajärg ei ole enam nii ilmne. Veaparanduse rakendamise korral RTP-s lisatakse igale kaadrile näiteks pool eelmisest ja pool järgmisest kõnekaadrist enne RTP-päisesse kapseldamist. Meetod suurendab küll paketi suurust ja selle hilistumist ning seetõttu nõutakse ka suuremat ribalaiust, kuid on abiks vigase kõnekaadri rekonstrueerimisel vastuvõtja poolel. Täpsem analüüs, kuidas paketikadu ja paketikao avastamise meetodid kõnekvaliteeti mõjutavad, vt p 4.1.1.

24

3.2.3.4. Kaja Kaja all mõistetakse tajutavat helilainete hilistunud peegeldust originaalallikast. Eristada on võimalik kahte tüüpi kajasid: elektrilisi ja akustilisi. Elektriline kaja tekib TDM võrgus meediamuundurites (hybrids), mille ülesanne on teisendada kahejuhtmeline kohalik (local loop) ühendus neljajuhtmeliseks pikamaa ahelate tarvis TDM võrgus. Kuna need muundurid teenindavad mitmeid kohalikke ühendusi, mis on erinevate takistustega, ei suuda muundur ideaalselt toimida. Üle minnes kahejuhtmeliselt neljajuhtmelisele ühendusele peegeldub takistuste sobitamata jätmise tõttu osa energiat tagasi neljajuhtmelise TDM ühenduse poole. Teisel pool olev kasutaja aga kuuleb hilistunult ja summutatult oma häält – ehk kaja. Akustiline kaja esineb, kui kuularist lekivad helilained mikrofoni. See kaja tüüp on sagedane valjuhääldi kasutamisel või kui telefon pole piisava akustilise varjestusega. Akustiline kaja on üldjuhul nii pika viitega, et enamus kajakustutajad ei suuda kaja likvideerida. Kaks peamist omadust põhjustavad tajutava kaja: kaja amplituud ja kaja hilistumine. Et vältida kasutajale tajutavat kaja, peab kogu signaali sumbuvus olema vähemalt -50dB. Kui kaja hilistumine võrgus on väiksem kui 20ms, siis ei suuda kasutajad üldjuhul kaja oma kõnest eraldada. Kaja hilistumise kasvades üle 20ms hakkab kõneleja taustamürana kaja tajuma, eristades oma kõnet ning kaja. Kuna IP võrk ei võimenda TDM võrku minevaid ega sealt saabuvaid signaale, siis peamine põhjus kaja tekkimiseks on hilistumine. IP võrk lisab viiteid, mis toovad välja kaja, mida enne maskeeris väga madal viide. Seega, kaja, mis eksisteeris TDM võrgus, kuid oli märkamatu, kuna kogu hilistumine (roundtrip delay) oli alla 20 ms, tuleb esile IP võrgus. IP telefonisüsteem ei lisa kaja, kuid teeb selle kasutajale tajutavaks. Võrguseade, mis liidestab IP võrgu ning TDM võrgu, peab kaja kompenseerima. [9] 3.2.3.5. Kõnekaadri pakkimine ja puhverdamine Kõnele lisatud RTP, UDP, IP, Etherneti/PPP päised teevad paketi suuremaks (p 4.1.3 tabel 4.1 näide 1 ja näide 2). Kasutada võib päiste kompresseerimist (IETF RFC 2508) või kasutada võimalust, et mitu kõnekaadrit pakitakse kokku enne ühisesse RTP paketti kapseldamist. Miinuseks on selle meetodi korral suurest paketist tingitud hilistumine ja suurem kõneinfo kadu paketikadude korral, mis võib kõnekvaliteeti halvendada. Arvestada tuleb ka maksimaalselt ühte paketti mahtuvate kõnekaadrite arvuga. Pakettide varieeruva hilistumise korral ei saa pakette enam kasutada, kuna need saabuvad vastuvõtjani liiga vara või hilja. Varieeruva hilistumise kompenseerimiseks kasutatakse vastuvõtjas RTP kõnevoogusid moodustavate pakettide puhverdamist. Sisuliselt tekitatakse võrguseadmes tehislik hilistumine saabuvatele pakettidele, et need õiges järjekorras ja konstantse kiirusega väljundisse edastada. Puhver ei tohi olla ei liiga väike ega ka liiga suur (liiga väikse puhvri puhul pole puhverdamisest midagi kasu, aga iga millisekund puhvri suurendamist lisab ka viitele millisekundi, mistõttu

25

kannatab jällegi reaalajalise rakenduse kvaliteet), sõltuvalt teistest lisanduvatest hilistumistest, koodeki tüübist, kõnepaketi suurusest ja kogu süsteemi komplekssusest võib puhvri suurus varieeruda 2…4 kõnepaketi vahel, mis on ekvivalentne 40…80ms hilistumisega 20ms paketi puhul näiteks G.711 või 64 kbit/s IKM kodeeritud kõnesignaali korral. Üldjuhul kasutatakse puhvrit, mis on kahekordne kõnepaketi suurusega ehk G.711 korral 40ms. Teatud tootjate lahenduses on võimalik kasutada ka dünaamilise suurusega hilistumise varieeruvuse kompensatsiooni puhvrit. 3.2.4. Teenuse nõuded peale seansi lõpetamist Kõnedetailide salvestaja CDR (call detail record) salvestab kõne parameetrid ning võimaldab analüüsida, mis juhtus enne kõnet, kõne ajal, pärast kõnet. Kasutada võib seda näiteks arvete genereerimiseks, testimiseks ja liikluse planeerimiseks (traffic engineering), salvestades andmed juba ettemääratud formaadis. Sellise täpse info põhjal on tagantjärgi võimalik välja uurida helistaja number ja sellest ka füüsiline asukoht, kui tegemist on näiteks katkenud hädaabikõnega. 3.2.5. Lõpp-kasutaja kvaliteeditaju mõjutavad parameetrid Kõige kriitilisemad häiringud VoIP teenuse korral on paketikadu, hilistumise varieeruvus, hilistumine, koodekiga seotud häiringud ja kaja.

Joonis 3.2. Kõige kriitilisemad VoIP QoS parameetrid ja nende vaheline seos [30] Oleme leidnud parameetrid, mis mõjutavad kõneteenuse kvaliteeti. Kuidas hinnata joonisel 3.2 toodud häiringute mõju kõnekvaliteedile, uurib 4. peatükk „Kõnekvaliteedi hindamise meetodid“. Järgnevalt on kirjeldatud diferentseeritud teenuste ning IP prioritiseerimise põhimõtteid, mille eesmärgiks on liiklust klassifitseerida ning prioritiseerida, et vähendada kõnele mõjuvaid häiringuid.

26

3.3 LIIKLUSE VORMINDAMISE (CONDITIONING) PROTSESSID QOS TAGAMISEKS 3.3.1 Diferentseeritud teenused Kogu diferentseeritud teenuste abil liikluse vormindamise aluseks on eelnevalt kehtestatud poliitika ehk nõutav teenuse kvaliteet. Et kõnele mõjuvaid häiringuid vähendada (p. 3.2), tuleb liiklus pakettside-põhises võrgus diferentseerida ning kõneliiklust prioritiseerida. Liikluse vormindaja klassifitseerib võrguseadmesse sisenevad paketid eel-defineeritud voogudeks, mõõdab nende vastavuse liikluse parameetritele, otsustab, kas pakett ületab temale etteantud profiili või mitte, märgib prioriteedi või jätab ummistuste tekkimisel edastamata, silub ehk puhverdab, et saavutada vajalik vookiirus ning moodustab väljundjärjekorrad .

Joonis 3.3. QoS mehhanismid [27] 3.3.1.1 Liikluse klassifitseerimine (classification) Klassifitseerimine võimaldab määrata liiklusklassid, mis viiakse kokku spetsiifilise QoS poliitikaga. Võimalused, mille alusel liiklust klassifitseeritakse, on alljärgnevad (näitena on toodud 3Com switch’i klassifitseerimise võimalused):

27

ISO OSI kiht ja protokoll

Kiht 2 – kanalitaseme QoS IEEE 802.1D prioriteet.

Prioritiseeritakse Etherneti kaadrisse lisatud baitide alusel.

Kiht 3 – IP taseme QoS Sihtpunkti IP aadress; Saatja IP aadress; IP protokollid (ICMP, IGMP, RSVP jne); DSCP.

Prioritiseeritakse IP paketis asuva informatsiooni alusel.

Kiht 4 – transpordikihi QoS UDP/TCP saatja ja sihtpunkti port.

Mitmed rakendused kasutavad suhtlemiseks kindlaid TCP või UDP porte. IP paketis pordi numbri abil võib tuvastada, millise rakendusega on tegu. Nimetatakse ka 4. kihi kommuteerimistehnoloogiaks.

Tabel 3.2. Atribuudid, mille alusel saab kommutaatorisse sisenevat liiklust klassifitseerida [7] Tänapäeval suudavad paljud võrguseadmed (ka lõpp-kasutajaid ühendavad seadmed) liiklust klassifitseerida. Tsentraalset haldust võivad pakkuda spetsiaalsed liikluse silujad (traffic shapers), ribalaiuse haldurid (bandwidth managers), mis paigutatakse võrgusõlmedesse, mis ühendavad kokku näiteks kiire kohtvõrgu ja aeglasema andmeedastuskiirusega laivõrguühenduse. 3.3.1.2. Liikluse märkimine (marking) Pärast liikluse identifitseerimist märgitakse paketid ära nii, et võrguseadmed suudaksid erineva liiklusklassiga andmevooge teineteisest eristada. Enne IP (3. kihi) QoS meetodeid eksisteerisid mitmed kanalikihi (2. kihi) QoS meetodid (ATM, Frame Relay ja Etherneti võrkudes). Vaatamata nendele mehhanismidele ei saa saavutada lõppkasutajate vahelist QoS-i, kui pole 3. kihi kvaliteedi tagamise meetodit. Viies vastavusse teise ja kolmanda kihi kvaliteedi märkimise skeemid, on võimalik elimineerida sõltuvust teise kihi tehnoloogiast. Et IP telefonisüsteemi korral kasutatakse kanalikihina üldjuhul Etherneti tehnoloogiat, vaadeldakse alljärgnevalt nii Etherneti QoS kui ka IP QoS märkimisskeeme. Kanalikihi tehnoloogia

Kanalikihi tehnoloogiana kasutatakse Etherneti võrgus IEEE 802.1D, ISO OSI 2. kihi märkimisskeemi. Liikluse teenusklassid defineeritakse IEEE 802.1Q 4-baidises sildis, mida kasutatakse VLAN ID (virtual local area network identification – virtuaalse kohtvõrgu identifikaator) ning IEEE 802.1p prioriteediinformatsiooni edastamiseks (joon 3.4).

28

Joonis 3.4. Prioriteedid Etherneti kaadris [7] DA =Destination Address, sihtpunkti aadress, SA = Source Address, saatja aadress, Type = Protocol Type, protokolli tüüp (IP, ARP jne.), FCS = Frame Check Sequence, väärtus, mis arvutatakse vigade avastamiseks, TPI = Tag Protocol Identifier- signaliseerib VLAN olemasolu, TAG= väli, mis lisatakse standardsele Ehterneti kaadrile VLAN ja prioritiseermisinfo lisamiseks, CFI = Canonical Format Indicator, VID=VLAN identifikaator. Prioriteediväljale 802.1q kaadri lipikus võib omistada väärtusi 000 (0) kuni 111 (7) alljärgnevalt:

IEEE 802.1 p prioriteediklass

IEEE 802.1D liikluse tüüp

0 Parim võimalik (vaikimisi) 1 Taustaliiklus 2 Standard 3 Kriitiline liiklus 4 Voogav multimeedia 5 Interaktiivne meedia

(<100ms hilistumine) 6 Interaktiivne kõne (<10ms hilistumine) 7 Võrguliikluse kontrolliks reserveeritud

Tabel 3.3. IEEE soovitus 802.1p prioriteeditasemete vastavusse viimiseks 802.1D liikluse tüüpidega [7]

Priority CFI VLAN id (VID)

TAG Field

3 bits 1 bit 12 bits

23 = 8 Priority Levels

Standard Ethernet Frame DA SA Data FCS Type

6 bytes 6 bytes 4 bytes 2 bytes 46 - 1500 bytes

1518 Bytes

1522 Bytes DA SA Data FCS TPI

802.1Q Ethernet Frame Type

2 bytes 46 - 1500 bytes 6 bytes 6 bytes 2 bytes 4 bytes

TAG

2 bytes

29

Näide. Liiklust võib 802.1p märkimisskeemi korral prioritiseerida alljärgnevalt: Mitte-VoIP liiklus (parim võimalik teenus e best-effort) 000 (0) VoIP kõneliiklus 101 (5) VoIP kõne algatuse signaliseerimine 011 (3) Vt. tabel 3.5. 802.1D prioritiseerimise piirangud:

� Vajab lisaks 4-baidist silti (tag), mis on Etherneti võrgus valikuline. � Silt on osa IEEE 802.1Q päisest – seega 2. kihil prioritiseerimise

kasutamiseks peab terve võrk kasutama IEEE 802.1Q VLAN sildistamist (tagging).

� Lõppkasutajate vahelise QoS saavutamiseks ka väljapool kohtvõrku on vaja kolmanda kihi prioriteetide seadmist, sest üle marsruuterite edastamisel eemaldatakse 802.1Q lipikud.

Kui kasutatakse uuemaid ja vanemaid võrguseadmeid segamini, võib tekkida kokkusobivuse probleeme, sest vanematel kommutaatoritel ei pruugi olla toetust VLAN-idele (802.1Q). Võrgukihi tehnoloogiad TCP/IP kolmanda kihi prioritiseerimise meetodeid nimetatakse ka IP QoS meetoditeks.

� TOS/IP Precedence märkimisskeem

Igas IP paketis on 1-baidine väli, mida pole siiani üldjuhul kasutatud. See tähendab, et igas IP paketis on üks bait, mille väärtus on null. Üks IP QoS tehnikaid on kasutada seda TOS baiti liiklustüübi märkimiseks. Neli bitti TOS baidist kasutati teenusetüübi määramiseks (RFC 2474), mis tekitasid neli teenusklassi (minimaalne hilistumine, maksimaalne läbilaskevõime, maksimaalne töökindlus, minimaalne rahaline kulu). Lisaks spetsifitseerivad RFC 791 ja RFC 1812 QoS mehhanismi IP precedence (3 bitti), mida marsruuterid interpreteerivad kaheksa erineva teenusklassina. [29]

30

Joonis 3.5. TOS ja IP precedence bitid [29] Meetodi miinused:

- IP precedence skeem lubab spetsifitseerida paketi relatiivse prioriteedi, kuid ei võimalda määrata pakettide edastamata jätmise järjekorda sama prioriteeditaseme korral. Näiteks olukorras, kus nii HTTP kui Telnet on kõrge prioriteediga, kuid ummikute tekkimisel ja pakettide edastamata jätmisel tahetakse ühte neist teisele eelistada, ei ole IP precedence korral seda võimalik määrata. - Kolm bitti piiravad prioriteediklasside arvu kaheksale, millest “Network Control” ja “Internetwork Control” klassid on reserveeritud marsruuterite poolt genereeritavatele pakettidele (marsruutimistabelite uuendused, ICMP teated jms), mistõttu kasutatavaid klasse jääb ainult kuus.

� DiffServ märkimisskeem Diffservi märkimisskeemil (RFC 2474) on kaks peamist komponenti – pakettide märkimine ning PHB (per hop behaviour).

� Pakettide märkimine ToS baidi kuus DSCP bitti lubavad defineerida 26 = 64 erinevat teenuste klassi, kogu välja nimetatakse DS (differentiated services) väljaks ning prioriteedibitte DSCP-ks (Differentiated Services Code Point).

31

Joonis 3.6. DiffServi väli on igas IP paketis [29]

� PHB (per hop behaviour)

Paketid, mis on sama DSCP väärtusega ja saadetakse samas suunas, moodustavad BA (behaviour aggregate). Seega, paketid, mis on pärit erinevatest rakendustest/allikatest, saavad kuuluda samasse BA-sse. PHB viitab ühte BA-sse kuuluvate pakettide ajastamisele, järjekordade moodustamisele, poliitikate loomisele ja vormindamisele võrgu sõlmpunktis vastavalt konfigureeritud SLA-le või poliitikale. Hetkel eksisteerib neli standardset PHB-d.

� Vaikimisi PHB

Vaikimisi on väli prioriteetide seadmiseta tühi ehk „000000“, mille korral võimaldatakse paketile parim võimalik teenus.

� Class-Selector PHB

Et saavutada tagurpidi ühtesobivust IP Precedence meetodiga, määratakse DSCP väärtused kujul xxx000, kus x on kas “1” või “0”. Neid koode nimetatakse class selector codepoint väärtusteks. PHB, mis on seotud class selector codepoint väärtusega, on class selector PHB ning saavutatakse samaväärne edastus kui IP precedence korral. Näide. Pakett DSCP väärtusega “110000” (IP precedence 110) on eelisjärjekorras edastatav võrreldes DSCP “100000” (IP precedence 100). Need PHB-d kindlustavad, et DSCP sõlmpunktid saavad eksisteerida koos IP precedence sõlmedega (tabel 3.4).

� Expedited Forwarding PHB

32

EF PHB on diferentseeritud teenuste võtmekomponent, mille abil saab võimaldada madala paketikao, lühikese hilistumise ja hilistumise varieeruvusega ning garanteeritud ribalaiusega teenuse. EF kasutatakse näiteks IP kõneside ja teiste reaalajalise rakenduste korral. EF saab rakendada kasutades prioriteetset järjekorda ning ühtlasi piirates klassi (BA) edastuskiirust, kuna ummistuste korral ei ole kõikidele pakettidele võimalik kõrgendatud teenust garanteerida. Soovituslik EF DSCP väärtus on “101110” (RFC-2474). Vt. tabel 3.4.

� Assured Forwarding PHB

Antud PHB defineerib meetodi, kuidas BA-dele saab anda erinevaid edastusprioriteete. Afxy PHB võimaldab neli erinevat klassi AF1, AF2, AF3, AF4, millele määratakse kindel liidese ribalaius ja puhver, sõltuvalt SLA-st. Igas klassis on omakorda võimalik määrata kolm tähtsusklassi. Ummiku tekkides ja teatud klassi kuuluvaid pakette on vaja kõrvale visata, siis toimub see tõenäosusega

dP(AFx3)dP(AFx2)dP(AFx1) �� ,

dP(AFxy) - tõenäosus (drop probability), et klassi AFxy paketid jäetakse edastamata, x – klassi tähis {1,2,3,4}, y – mitte-edastuse eelistus {1,2,3}. Seega AFx klassis esitatase DSCP väärtused kujul xyzab0, kus “xyz” määrab ära klassi (001/010/011/100) ja “ab” määrab ära mitte-edastamise järjekorra (RFC-2597). Enamik marsruuteritest saab DiffServi prioriteetidest aru, samas ei tekita meetod lisapäiseid, kuna väli on prioriteetide seadmiseta tühi ehk „000000“. Mitte-edastuse tõenäosus

Klass nr. 1 Klass nr. 2 Klass nr. 3 Klass nr. 4

Madal AF11 001010

AF21 010010

AF31 011010

AF41 100010

Keskmine AF12 001100

AF22 010100

AF 011100

AF42 100100

Kõrge AF13 001110

AF23 010110

AF 011110

AF43 100110

Tabel 3.4. Diffserv AF koodide tabel [8] Klass 4 on AF PHB-de hulgas kõrgeima prioriteediga. Ka rakendusprogrammid ise võivad määrata vajaliku DSCP, kuid seda ei peeta üldjuhul usaldusväärseks. Siiski seadistab väärtuse kommutaator, liikluse siluja või VoIP lüüs näiteks pordi või IP aadressi järgi. [8]

33

3.3.1.3. Liikluse ümbermärkimine (remarking) Kui switchi siseneb pakett, mis nõuab kõrgemat prioriteeti kui talle on reeglitega ette nähtud (või vastupidi), saab prioriteeti ümber märkida. Alternatiivina võib paketid ka kõrvale visata. 3.3.1.4. Liikluse silumine (shaping) Liikluse silumine lubab kontrollida väljuvat liiklust, et kindlustada, et liikluse edastus vastab talle määratud poliitikaga. Ülemäärased paketid puhverdatakse hilisemaks edastamiseks, mille tagajärg on sujuv pakettide edastus. Liikluse silumist on võimalik teha kas liidesele või liiklusklassile vastavalt. Silumine on kasulik, kui

� ühendatakse kokku kiire kohtvõrk ja aeglane laivõrguühendus, � puudub piisav ribalaius või kui � andmeid edastatakse purskeliselt.

3.3.1.5. Järjekorra moodustamise strateegiad (queuing) Järjekorra moodustamisel määratakse, kuidas paketti võrguseadmes edastatakse, konfigureerides väljundjärjekorra planeerijad (queue scheduler). Ummiku tekkides läbivad paketid lisaks riistvaralisele järjekorrale ka tarkvaralise järjekorra, sest riistvaralises järjekorras toimib edastus alati FIFO (first in -first out) põhimõttel, tarkvaraline järjekorra planeerija aga edastab paketid riistvaralisse järjekorda vastavalt QoS nõuetele. Otsustus, milline pakett millisesse tarkvaralisse järjekorda jaotatakse, sõltub klassifitseerimise protsessist. Klassid sõltuvad kasutaja poolt määratud kriteeriumitest ja igal klassil on oma järjekord. Paketid, mis kuuluvad teatud klassi, omavad vastavale klassile määratud ribalaiuse ja järjekorrapiiranguid. Kui vastavasse järjekorda tekib ülemääraseid pakette, jäetakse need edastamata. Tarkvaralise järjekorra tekitamise võimalusi on mitmeid (CB-WFQ (class-based weighted fair queuing) suure ribalaiuse garanteerimiseks, CB-LLQ (class based low latency queuing) madala hilistumise saavutamiseks (VoIP), WRR (weighted round robin). 3.3.1.6. Pakettide edastamata jätmine (dropping) Ummistuste vältimise eesmärgil pakettide edastamata jätmise meetodid on näiteks juhuslik mitte-edastusmeetod RED (random early detection) ja WRED (weighted random early detection), mille korral paketi mitte-edastuse tõenäosusel on erinevad profiilid sõltuvalt paketi prioriteetide seadistusest – mida kõrgem on prioriteet, seda madalam on edastamata jätmise tõenäosus.

34

Diffservi eelised IEEE 802.1D ees: � Ei vajata VLAN lipikuid; � DSCP kasutab paketi IP päist, mida on võimalik edastada ka väljapoole

kohtvõrku (DSCP on kokkusobiv ka IPv4 ToS-iga). Diferentseeritud teenuste puudused:

� Erinevate klasside määramine võrgus nõuab teadmisi rakendustest ja liikluse statistikast erinevatele voogudele;

� QoS ja marsruutimine – üks suuremaid miinuseid nii integreeritud kui ka diferentseeritud teenuste korral on marsruutimise protsessi eraldatus, mis tähendab, et võrgus võib olla vajalik ressurss, kuid RSVP/Diffserv ei suuda neid tuvastada. Suuremates võrkudes on alternatiiviks MPLS ja liikluse planeerimine.

Järeldus. Diferentseeritud teenus märgib kõnekaadri või kõnepaketi relatiivse prioriteedi, mida switchid ja marsruuterid peavad arvestama ning on kõnekvaliteedi garanteerimiseks sobilik meetod. 3.3.2 MPLS (Multiprotocol Label Switching)

MPLS pole ainult QoS tehnoloogia. Pigem on ta QoS-i võimaldav tehnoloogia, mis suunab rakenduste vood ühendusele orienteeritud teedesse ja võimaldab liiklust planeerides vajaliku ribalaiuse garanteerida, liiklust efektiivselt marsruutida ning virtuaalseid privaatvõrke moodustada. Kui paketid sisenevad MPLS võrku, märgitakse nad 4-baidise MPLS lipikuga. MPLS marsruuterid (label switch routers - LSR) suudavad edastada pakette üle võrgu kasutades ainult seda lipikut. Erinevatele lipikutele (ehk erinevatele teenusklassidele) saab konfigureerida võrgus erinevad teed (label switch path - LSP).

Joonis 3.7. IP paketile lisatakse MPLS päis [29] MPLS-i saab kasutada koos DiffServ’iga ning MPLS päiste väärtusi saab määrata vastavalt DSCP väljale. Järeldus. MPLS tekitab IP-liiklusele virtuaalse ahela, kinnitades igale kaadrile 4B, mis kirjeldavad tee järgmise marsruuterini. Sobib kasutamiseks suurte tuumvõrkude korral nii reaalajaliste telefonikõnede kui ka andmeside edastamiseks.

35

3.3.3. Intergreeritud teenused, RSVP (Resource reservation protocol) RSVP reserveerib ressursid üle mitmete marsruuterite, et saavutada vajalik andmeedastuskiirus, hilistumine ja hilistumise varieeruvuse minimeerimine kindla ühenduse jaoks. RSVP töötab hästi, kui tegemist on pikkade seanssidega (näiteks videovoog) ja korraga peab reserveerima vähe ühendusi. Järeldus. VoIP jaoks ei ole RSVP rakendamine üldjuhul sobiv lahendus. [8] 3.3.4. Prioriteetide seos erinevate meetodite korral Seoses autori uuringutega Ipswichis British Telecomis tekkis vajadus erinevate meetodite prioriteedid omavahel vastavusse viia. Kuna võrkude ühendamisel olid kasutusel erinevad tehnoloogiad ja kvaliteedi tagamisel on oluline kõneedastuse eelistamine kogu lõpp-punktide vahelisel teel, siis on oluline mõista, kuidas erinevate meetodite prioriteete on võimalik vastavusse viia teiste kvaliteeti garanteerivate meetoditega. Seetõttu koostas autor tabeli, mis oleks abiks kohtvõrkudes ja laivõrkudes samaväärsete eelistuste seadmisel (tabel 3.5), mis viib kokku IP precedence, IEEE 802.1, DSCP, MPLS märkimisskeemid. Prioriteet kahend- ja kümnendkujul on lisatud vaid arvutuste lihtsustamiseks. Kui erinevate meetodite prioriteetide real pole üks-ühest vastavust, siis teisendatakse vastavalt klassile – DSCP väärtuse 9 võiks pidada teisendamisel samaväärseks MPLS 001 väärtusega.

36

Prioriteet kahendkujul IP preced Klass

IEEE 802.1

prioriteet DSCP DSCP nimi MPLS EXP Kümnend-

kuju Teenus-klass

000 000 000 0 000 0 Be 000 0 Parim

võimalik

000 001 000 0 1 4

000 010 000 0 2 8

000 011 000 0 3 12

000 100 000 0 4 16

000 101 000 0 5 20

000 110 000 0 6 24

000 111 000 0 7 28

001 000 000 1 001 8 001 klass 1 001 32

001 001 000 1 9 36

001 010 000 1 10 AF11 olulisim 40 Kindlustatud

edastus

001 011 000 1 11 44

001 100 000 1 12 AF12 keskmise

tähtsusega 48 Kindlustatud

edastus

001 101 000 1 13 52

001 110 000 1 14 AF13 väikseima

tähtsusega 56 Kindlustatud

edastus

001 111 000 1 15 60

010 000 000 2 010 16 010 klass 2 010 64

010 001 000 2 17 68

010 010 000 2 18 AF21 72 Kindlustatud

edastus

010 011 000 2 19 76

010 100 000 2 20 AF22 80 Kindlustatud

edastus

010 101 000 2 21 84

010 110 000 2 22 AF23 88 Kindlustatud

edastus

010 111 000 2 23 92

011 000 000 3 011 24 011 klass 3 011 96

011 001 000 3 25 100

011 010 000 3 26 AF31 104 Kindlustatud

edastus

011 011 000 3 27 108

011 100 000 3 28 AF32 112 Kindlustatud

edastus

011 101 000 3 29 116

011 110 000 3 30 AF33 120 Kindlustatud

edastus

011 111 000 3 31 124

37

Prioriteet kahendkujul IP

preced Klass

IEEE 802.1

prioriteet DSCP DSCP nimi MPLS EXP Kümnend-

kuju Teenus-klass

100 000 000 4 100 32 100 klass 4 100 128

100 001 000 4 33 132

100 010 000 4 34 AF41 136 Kindlustatud

edastus

100 011 000 4 35 140

100 100 000 4 36 AF42 144 Kindlustatud

edastus

100 101 000 4 37 148

100 110 000 4 38 AF43 152 Kindlustatud

edastus

100 111 000 4 39 156

101 000 000 5 101 40 CS5 101 160

101 001 000 5 41 164

101 010 000 5 42 168

101 011 000 5 43 172

101 100 000 5 44 176

101 101 000 5 45 180

101 110 000 5 46 EF 184 Kiirendatud

edastus

101 111 000 5 47 188

110 000 000 6 110 48 NC1/CS6 110 192 Võrguhaldus

110 001 000 6 49 196

110 010 000 6 50 200

110 011 000 6 51 204

110 100 000 6 52 208

110 101 000 6 53 212

110 110 000 6 54 216

110 111 000 6 55 220

111 000 000 7 111 56 NC2/CS7 111 224 Võrguhaldus

111 001 000 7 57 228

111 010 000 7 58 232

111 011 000 7 59 236

111 100 000 7 60 240

111 101 000 7 61 244

111 110 000 7 62 248

110 111 000 7 63 252

Tabel 3.5. Diffserv DSCP, IP precedence, MPLS vastavusse viimine [6,8,29] 3.3.5. Liikluse vormindamise protsessid - kokkuvõte IP võrgu olemuse tõttu peab lõpp-punktide vahelise teenuse kvaliteedi tagamiseks kasutusele võtma mitte ühe üksiku vaid nn. QoS strateegiate kogumi. Eelpool kirjeldatud sammud ei ole kõik tingimata vajalikud (näiteks liikluse silumine ei ole kohustuslik osa liikluse vormindamise protsessist). Peatükis 5 vaadeldakse, kuidas 3Com seadmetel põhinevas testvõrgus on kvaliteedi garanteerimist võimalik rakendada.

38

4. KÕNEKVALITEEDI HINDAMISE MEETODID Järgnevas peatükis uurime kvaliteedikriteeriume kõne kvaliteetseks edastamiseks IP-põhises pakettsidevõrgus ning kuidas erinevad häiringud kvaliteedihinnangut mõjutavad. Kui kõnet üle IP protokolli ei rakendata peamiselt eesmärgiga kulusid kokku hoida (näiteks kõned üle pikkade distantside, kasutades olemasolevat andmesidevõrku) ning soovitakse asendada olemasolev telefonisüsteem IP telefonisüsteemiga kohtvõrgus, siis peetakse üldjuhul IP telefoniside kvaliteedi alampiiriks PSTN süsteemi kvaliteeti [29], mida nimetatakse üldjuhul kõrgeks (väärtus R>80, joon 4.18 [28]). Kui asendame PSTN kõneside IP-põhise teenusega, ei saa uue süsteemi kvaliteet olla madalam. Enne IP-põhise kõneedastuse rakendamist peab kindel olema, et teenus vastab nõudmistele, mistõttu tuleb:

1. paika panna kriteeriumid, mida tahetakse saavutada. Antud peatukk üritab leida peamised reeglid, mida arvestada transmissiooni planeerimisel, võrgu konfigureerimisel ja mõõtmisel,

2. mõõta, kas teenus vastab nõutud kvaliteedile. Telefoni leiutamise algusaegadest on kõnekvaliteedi testimine olnud subjektiivne: tõstetakse telefonitoru ja hinnatakse kuuldud kõne kvaliteet. Traditsiooniline meetod hindamaks kõneedastuse kvaliteeti pakettsidevõrgus on koguda arvamusi testkasutajatelt. Mida rohkem on testkasutajaid, seda usaldusväärsemad on tulemused. Kõne kvaliteeti hinnatakse väärtusega MOS (Mean Opinion Square ehk hinnangute keskväärtus). MOS (ITU P.800) on peamine subjektiivse kõnekvaliteedi mõõtmise standard, mis seostab häiringutega kõne karakteristikud ja kvaliteedihinnangu, skaala joonis 4.6. Kvaliteeti üle 4,0 peetakse suurepärase kvaliteedi alampiiriks, väärtust alla 3,6 aga üldjuhul paljudele mittesobivaks. Kuid siinjuures tekivad mitmed probleemid: mehed ja naised hindavad kvaliteeti erinevalt [17] ning hinnang sõltub näiteks ka vanusest ja rahvusest; teiseks, võrguparameetreid ning võrgu optimeerimise eesmärgil erinevaid seadistusi muutes pole reaalselt võimalik alati selliseid teste läbi viia (kulukas ja liialt aeganõudev tegevus). Seega oleks vaja automatiseeritud protsesse: hinnata objektiivselt mõõdetavad parameetrid ning teatud algoritmi alusel üle minna subjektiivsetele hinnangutele.

39

Joonis 4.1. Kõnekvaliteedi hindamise meetodid [2,30]

Subjektiivne: hõlmab kasutajapoolset reaalajalist hinnangut nt. eelpool mainitud MOS (ITU P.800). Objektiivne: automatiseeritud hinnangumeetodid, mis jagunevad kaheks alamliigiks: 1. Parameetritel põhinevad mõõtmised transmissiooni hindamiseks nt. ITU-T soovitus G.107, E-mudel. Meetodid, mis tuletavad kvaliteedihinnangu vastavalt mõõdetud võrguparameetritele - joonis 4.2.

Joonis 4.2. Parameetritel põhinev hindamismeetod [30] Eeldatakse, et iga kvaliteedihäiringute klass on seotud mingi kindla häiringufaktoriga. Valem põhineb psühholoogilisel kontseptsioonil: ülekandehäiringud võib transformeerida psühholoogilisteks faktoriteks ning need on aditiivsed. Esmalt arvutatakse baasväärtus Ro, mis põhineb võrgu müral ning keskkonnal saatja ja

40

vastuvõtja poolel. Iga häiringufaktorit iseloomustatakse mingi suurusega, mis arvutatakse maha baasväärtusest. [12]

Joonis 4.3. Näide parameetritel põhineva meetodiga kvaliteedi hindamisest [29] 2. Signaali hindamisel põhinevad meetodid, millel on kaks alaliiki: a. Võrdlusel põhinevad mudelid PSQM (ITU P.861), perceptual speech quality measure, PSQM+, perceptual speech quality measure, PESQ, (ITU P.862), perceptual evaluation of speech quality, PAMS (BT), perceptual analysis measurement system.

Joonis 4.4. Võrdlusel põhinev meetod [30]

PSQM, PESQ ja PAMS saadavad referentssignaali läbi kommunikatsioonivõrgu ning hindavad vastuvõetavat signaali võrreldes seda saadetud signaaliga (joonis 4.4). Arvestades inimkõrva karakteristikuid ja taju hinnatakse eeldatav subjektiivne helikvaliteet (subjektiivset helikvaliteet ongi inimese poolt tajutav kvaliteet). Alguses kasutati nimetatud standardeid ainult koodekite testimiseks, kuid paljud mõõteriistad on neid standardeid IP kõnesüsteemide testimisel rakendanud. Kuna MOS on üldtunnustatud kvaliteedihinnang, võimaldavad kõik hindamisalgoritmid oma tulemuse MOS skaalaga vastavusse viia.

41

b. Absoluutne hinnanguline meetod (näiteks ITU-T soovitus P.561, INMD) Absoluutne hinnangulise meetodi puhul ei ole teadaolevat referentssignaali, käesolevas töös seda meetodit ei uurita (joonis 4.5).

Joonis 4.5. Absoluutne hinnanguline meetod [30] Vaadeldud kõnekvaliteedi hindamise meetoditest kirjeldab magistritöö lähemalt E-mudelit (p. 4.1), varasemas ITU-T standardis G.113 soovitatud meetodit ICPIF, mida uuris autor British Telecomis Ipswichis (p. 4.2 ja lisa B) ja signaali hindamisel põhinevat meetodit PESQ.

42

4.1 E-MUDEL KÕNEKVALITEEDI HINDAMISEKS E-mudel põhineb ITU-T soovitusel G.107, mille abil saab hinnata kasutaja poolt tajutavat kvaliteeti ning eeldatavat rahulolu kitsaribalise (3,1 kHz) kõne edastamisel. Eesmärk ei ole ennustada kasutaja absoluutset rahulolu, vaid pigem modelleerida tundmatute parameetritega ühenduse jõudlust võrreldes seda teadaolevate parameetritega ühendusega.

Joonis 4.6. E-mudeli väljundskaalade võrdlus (ITU-T G.109) [13] E-mudeli väljundiks on skalaar R vahemikust 0 - 100, mida nimetatakse hinnangu faktoriks (rating factor) või R-väärtuseks (joonis 4.6). Oluline on rõhutada E-mudeli objektiivsete tulemuste (R väärtus) ja subjektiivsete hinnangute (MOS) erinevust. Subjektiivse testimise korral jaotab hindaja tajutava kvaliteedi kategooriatesse (nt. viiepunktilisel skaalal suurepärane, hea, keskmine, napp, halb), mille korral võivad MOS hinnangud erineda ka samade tingimuste korral, sõltuvalt eksperimendi ülesehitusest, tingimustest jpm. E-mudeli tulemused arvutatakse kasutades häiringute faktori (impairment factor) meetodit, mis kombineerib kõnekanali häiringud (paketikadu, moonutused, kaja, hilistumine, müra) üldiseks hinnanguks R, mis on objektiivne ja korratav. Kuigi R väärtus on deterministlikult teisendatav MOS väärtusteks (joonis 4.8), on siiski E-mudeli kasutamisel selguse mõttes soovitatav opereerida R-skaalal. E-mudel koosneb mitmest erinevast mudelist, mis seovad spetsiifilised häiringuparameetrid ja nende mõju ETE jõudlusega. Summaarset ETE jõudlust, võttes arvesse kõik faktorid, hinnatakse häiringute faktori meetodit, mis põhineb printsiibil, et ülekandehäiringud saab teisendada psühholoogilisteks faktoriteks ning need faktorid on psühholoogilisel skaalal aditiivsed.

43

Joonis 4.7. E-mudel. [12] Joonise lühendite tähendusi, mis pole tekstis lahti kirjutatud, on selgitatud lisas A. R-väärtuse valem transmissiooni kvaliteedi hindamiseks vastavalt E-mudelile:

AIeIdIsRoR ����� {4.1} Ro – signaal-müra suhe, mis sõltub saate ja vastuvõtu helivaljusest ning ahela ja ruumi mürast; Is – summa kõikidest samaaegsetest kõneülekande häiringutest, nt valjuse tasemetest, kõrvaltoonidest (sidetone, kõneleja enda hääl, taustamüra kõneleja telefonis) ja kvantimismoonutustest; Id – summa hilistunud häiringutest kõnesignaali suhtes ehk häiringud, mis sõltuvad kõneleja ja kuulaja vahelise kõnesignaali hilistumisest:

- häiringud, mida põhjustab absoluutne hilistumine kõnelejast kuulajani (parameetrid p. 4.1.1.1)

- häiringud, mida põhjustavad kõneleja- ja kuulajapoolsed kajad (parameetrid WEPL, TELR, STMR, RLR);

Ie – spetsiaalne häiringufaktor, mis aitab hinnata häiringuid, mida põhjustab kõne kompresseerimine (määratakse subjektiivselt iga koodeki jaoks vastavalt ITU-T soovitusele G.113), paketikadu ja seadmed; A – mitte-tehnilistel parameetritel põhinev faktor, mis parandab R faktorit uute teenuste puhul, arvestades kasutajate suuremat rahulolu ka madalama kvaliteediga teenuse puhul. Eeldatakse, et A faktor on langeva tendentsiga, sest kasutajad harjuvad

44

uue teenusega. IP telefoni puhul võiks arvestada A=0, sest tegemist on siiski olemasoleva teenuse asendamisega (GSM puhul võib võtta A=10, DECT puhul A=5, satelliitlinkide puhul A=20) [12]. Tihti eristatakse subjektiivselt kõnekvaliteedi keskmist hinnangut MOS ning hinnangut objektiivse mõõtmismeetodi alusel, tähistades objektiivse hinnangu näiteks alaindeksiga MOSCQE (Mean opinion score, conversational, estimated) - näiteks vastavalt E-mudelile või PESQ mõõtmisele - või MOS-CQE. R väärtus ja MOSCQE on seotud alljärgnevalt: R<0 MOSCQE=1 R>100 MOSCQE=4,5 {4. 2} 0<R<100 MOSCQE=1+0,035R+7*10-6*R*(R-60)*(100-R) [12]

R and MOSCQE (E-model)

1,00 1,25 1,50 1,75 2,00 2,25 2,50 2,75 3,00 3,25 3,50 3,75 4,00 4,25 4,50 4,75

0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100

R factor value

MO

SC

QE

Joonis 4.8. R faktori ja hinnatud MOS vaheline seos [E-mudeli põhjal, valem 4.2]. Kuna IP-põhise andmesidevõrgu ülekande kvaliteet sõltub pigem dünaamilistest häiringutest kui staatilistest häiringutest nagu TDM korral, on IP telefonisüsteemi üldine kvaliteet hinnatav statistiliselt. Häiringufaktor Ie teeb E-mudelist sobiva tööriista suhtelise kasutaja rahulolu hindamiseks. Kuigi subjektiivse MOS hinnang ulatub 1,0…5,0 (ITU P.800), siis E-mudeli MOSCQE

hinnang on vahemikus 1,0…4,5 [12].

45

Teoreetiline R väärtuse maksimum IP telefonisüsteemi korral on vastavalt ITU-T G.107 standardile 93,2 (varasemas redaktsioonis 94,2), faktori väärtuste määramist on vaadeldud alljärgnevalt. 4.1.1 Häiringud IP telefonisüsteemis ja E-mudel Neli peamist häiringute põhjustajat IP telefonisüsteemis, mida ühtlasi ka E-mudel arvestab, on:

� hilistumine, hilistumiste varieerumine, � kaja, � kõne kompressioon, � paketikadu.

4.1.1.1 Hilistumisest tingitud häiringute arvestamine Kõne summaarne hilistumine kõnelejast kuulajani sõltub IP telefonisüsteemi korral kõne kodeerimise, pakettidesse jagamise, hilistumise varieeruvuse kompensatsiooni hilistumisest (konstantsed) ning transpordi kiirusest ja leviajast (varieeruvad). Siiski, ka hilistumise varieeruvuse kompensatsiooni puhver võib olla varieeriva suurusega [Lisa B] ning seotav transpordi ja leviaja hilistumisega.

Tsum = Ttl + Tkod + Tkad + Thv + Tdek , {4.3} kus Ttl - transpordi ja leviaja hilistumine, Tkod - kõne kodeerimise hilistumine, Tkad - pakettidesse jagamine, Thv – hilistumise varieeruvuse kompensatsiooni hilistumine, Tdek – dekodeerimise hilistumine. Graafik (4.9) selgitab, kui olulist mõju avaldab hilistumine interaktiivsele kõnele. X-teljel on ühesuunaline hilistumine, y-teljel vastav R-väärtus, teised parameetrid on antud juhul fikseeritud vaikimisi parameetritega vastavalt ITU-T soovitusele G.107 E-mudelist. (Referentsühenduse parameetrid on lisas A2.) Ühesuunalist hilistumist kõnelejast kuulajani võib mõõta mitmel moel. Kõige lihtsam lähenemine on mõõta vastuse aeg saatjast vastuvõtjasse ja tagasi (round trip delay) ja jagada tulemus kahega. Kuid selline aproksimatsioon ei ole alati sobiv, sest nii eeldatakse sümmeetrilist hilistumist. RTP kõnevood võivad aga kulgeda erinevaid teid pidi. Peale kellade sünkroniseerimist saab ühesuunalise hilistumise arvutada valemiga

ühesuunaline hilistumine = vastuvõtja ajatempel - saatja ajatempel. Kõige täpsem meetod ühesuunalise hilistumise mõõtmiseks on saatjas ja vastuvõtjas kellad sünkroniseerida. Sünkroniseerimine pole triviaalne protseduur, täpse tulemuse saamiseks peaks kasutama GPS-i (Global Positioning System) ning satelliitide abil aja

46

määrama. Nii saavutatakse täpsus ca 100ns [19], NTP (Network Time Protocol) puhul kohtvõrgus üldjuhul mitte vähem kui 5-10ms [29].

Joonis 4.9. Hilistumise häiring referentsühenduse korral. [28] Joonisel toodud kõver kehtib kajasummutuse 65dB korral (p. 4.1.1.2). Graafikult 4.2 on näha, et kui ühesuunaline hilistumine on suurem kui 175 ms, siis R väärtus hakkab järsult langema. 150 ja 200 ms vahel hakkabki hilistumine kõne dünaamikat oluliselt mõjutama. Vastavalt [28] on tavalise inimestevahelise suhtluse korral kõnelejate vahetumisel 200 ms pikkused pausid. Kui kommunikatsioonikanali hilistumised on võrreldavad tavakõneluse pausidega, kaob ära kõne sünkroonsus. Näiteks mõlemad kõnelejad hakkavad korraga rääkima, kuid ei taju seda viidete tõttu hetkeliselt. Kui kõnelemisel domineerib üks osapool, siis teisel on kõnesse väga raske sekkuda, sest kui paus teise osapooleni jõuab, on domineeriv rääkija juba uut lauset alustanud. Lisaviidete tõttu võivad osapooled interpreteerida hilistumist teise kõneleja eesmärgina otsekoheseid vastuseid mitte anda ning seetõttu seostatakse vastamise kiirust ka aususe, avatuse ja usaldusväärsusega. ITU-T G.114 soovituse kohaselt peaks ühesuunaline hilistumine jääma alla 150 ms, et saavutada MOS väärtus üle 4,0.

Kui datagrammide ülekandeajad sama kõne jooksul varieeruvad, on tegemist hilistumise varieeruvusega. Kui hilistumise varieeruvus ületab 50 ms, hakkab MOS tuntavalt langema [29]. Kasutades koodekit G.711 ning kasutades hilistumise varieeruvuse puhvrit (üldjuhul kahekordne paketi pikkus 2x 20ms) 40ms, ei suuda puhver enam pakette säilitada ning paketid visatakse kõrvale, mille tagajärjel suureneb paketikadu (p 4.1.1.4).

47

4.1.1.2 Kajast tingitud häiringute arvestamine

Kaja tekkimise eelduseks on kolm asjaolu: - analoogosas toimuv leke saate- ja vastuvõtuteedel, - piisav kaja peegeldumise hilistumine, et see häirivana tunduks, - piisav kaja amplituud, et see häirivana tunduks.

IP telefonisüsteemi puhul viitab tajutud kaja tõenäoliselt probleemile vastasrääkija poolel (joonis 4.10), sest kõnesignaali lekkimine saab tekkida vaid analoogahelas – elektriliselt ühelt juhtmelt teisele (ülekostvus - crosstalk) või akustiliselt üle õhu valjuhääldist mikrofoni. Analoogsignaalid võivad peegelduda tagasi ka vastaspool asuvast meediamuundurist. Kõik digitaalsed bitid, mida kantakse füüsilisel kihil üle analoogsignaalina, võivad lekkida. Analoogsignaalid, mis kirjeldavad digitaalseid bitte, taluvad moonutusi suuremal määral, et neid oleks võimalik veel õigesti dekodeerida. Kaja, mis saabub lühikese viivitusega (kuni 25 ms), pole üldjuhul tajutav, sest seda maskeerib füüsiline ja elektriline kõrvalsignaal (sidetone), mis tähendab, et peaaegu iga telefoniseadme puhul lekib osa saatesignaalist kuularisse, nii et on võimalik kuulda end rääkimas. Kuid tegelik kõnesignaal on tekkiva kõrvalsignaaliga võrreldes nii väikse hilistumisega, et seda ei tajuta kajana. [9]

Joonis 4.10. Kajaga telefonikõne [9]

Joonis 4.11. Ahela „saba“ [9] Joonisel 4.11 pole tegemist küll IP telefonisüsteemiga, aga kasutatav VoIP ühendus iseloomustab tekkivat hilistumist kahe kõneleja vahel. Signaali, mis peegeldub tagasi kõneleja (joonis 4.11 „Bob“) poolel asuvatest seadmetest, ei avalda mõju, sest hilistumine on piisavalt väike. Ahela „sabast“

48

peegelduvaid signaale hilistab aga kõnelejate vahel asuv IP-võrk (WAN), mille tõttu Bob tajub kaja. Telefoniseadme peamine ülesanne on muundada helilained elektrilaineteks ja vastupidi. Et hinnata helivaljust kõne ajal, on defineeritud mitmeid parameetreid, et hinnata analoogosas esinevaid kadusid. TELR (talker echo loudness rating) – kajasummutus kõneleja A mikrofonist läbi signaali tee A kuularisse tagasi (dB). Vastavalt [28] peab olema täidetud tingimus

dBTELR 65� .

Joonis 4.12. Referentsühenduse plokkdiagramm [28] Joonis 4.12 kirjeldab kaja liikumist A ja B poolel, alljärgnevad valemid iseloomustavad kaja sumbuvust. TELR (B-pool) = SLR (B-pool) + saatekanali kadu + ERL(A) või TCLw (A-pool) + vastuvõtjakanali kadu + RLR (B-pool). [28] TELR (A-pool) = SLR (A-pool) + saatekanali kadu + ERL(B) TCLw (B-pool) + vastuvõtjakanali kadu + RLR (A-pool). [28] ERL (echo return loss) on kaja kadu meediamuunduris või kajakustutajas, TCLw (weighted terminal coupling loss) digitaalse telefoniaparaadi analoogosas. SLR (send loudness rating ehk helilaine sisendvõimsus mikrofoni suhtena edastatava väljundvõimsusega ahelasse) RLR (receive loudness rating ehk sisendvõimsus ahelast kuularisse suhtena helilainetena väljundvõimsusesse kuularist). [9] Kui TELR väärtust vähendada, siis väheneb ka ühendusele lubatav ETE hilistumine samaväärse kvaliteedi saavutamiseks R skaalal. Nominaalsed väärtused telefonidel on SLR=8dB ja RLR=2dB [28]. Kuna TELR peab olema vähemalt 65dB, et kaja eemaldada, siis telefoni analoogosas ülekantav kaja kadu

TCLw=TELR-SLR-RLR=65-8-2=55dB. [28]

49

Vastavalt ITU-T soovitusele G.168 peab IP telefonide puhul olema TCLw>=52dB, TIA-810-A nõuab miinimumina TCLw>=52dB, kuid võimaluse korral siiski TCLw>=55dB, mis tuleneb ülaltoodud tulemusest [28]. Kui ühesuunaline kaja hilistumine ületab 25ms, hakkab kõneleja kaja tajuma. [28, 9]

Joonis 4.13. E-mudel kajahäiringute ennustamiseks [28] Joonis 4.13 iseloomustab kajakustutuse efekti kõnekvaliteedile. Näiteks kui TELR = 65dB, siis R�90 saavutamiseks võib ühesuunaline hilistumine olla ca 150 ms, kui aga TELR = 45 dB, siis peaks ühesuunaline hilistumine olema alla 25 ms.

Kajakustutaja on kõnelüüsi komponent, mis vähendab kajade valjust, mis on vastuvõtuahelast saateahelasse lekkinud (joonis 4.11). Gradiendimeetodi abil leitakse ennustatavad kajakoefitsiendid ning ennustatav kaja lahutatakse maha saadetavast kõnesignaalist.

Joonis 4.14. Kajakustutaja asukoht võrgus [9] Üldjuhul on minimaalne võimalik ETE hilistumine transmissioonil kaks kuni kolm paketipikkust (millisekundites) - isegi kui paketi edastamise aeg oleks „hetkeline“, kuluks ikka paketi täitmiseks ühe paketi pikkune aeg. Kui tegemist on G.711 koodekiga, saadetakse pakette iga 20ms tagant, mis tähendab, et iga pakett sisaldab 20ms kõneandmeid. Seega, et vähendada ETE hilistumist kaja mõjude vähendamiseks, võib suurendada pakettide väljasaatmise sagedust – näiteks 10

50

millisekundile, kuid see jälle suurendab vajatavat ribalaiust, kuna igale paketile tuleb lisada konstantse suurusega päis. Järeldused - Võrgu hilistumine suurendab kaja tajumist. - IP seadmete lisamine võrku ei lisa kõnele kaja, vaid teeb olemasoleva kaja hilistumise tõttu tajutavaks.

4.1.1.3 Kõne kompressioonist tingitud häiringute arvestamine E-mudeli heaks omaduseks on Ie faktor, mis aitab hinnata häiringuid, mida põhjustavad kõne kompressioon ja paketikadu. Tabel 4.1 toob välja häiringufaktori Ie, mida tuleb vastava koodeki puhul kvaliteediparameetri R arvutamisel aluseks võtta. Igale koodekile vastavad Ie väärtused on spetsifitseeritud ITU-T soovituses G.113. Tuleb aga arvestada, et tegelik nõutav andmeedastuskiirus on aga suurem, kui koodekist väljuv bitivoog. Alljärgnevalt on toodud näiteid, kuidas arvutatakse tabelis 4.1 kahe samaaegse kõnevoo jaoks vajalikkuedastuskiirust. 1Näide Vaatleme lähemalt G.729 edastamiseks vajaliku andmeedastuskiiruse arvutust: Kuna iga datagrammi suurus on 20ms ja sekundis on koodeki väljund kiirusega 8,0 kbit/s, siis iga 20ms tagant tuleb koodekist järelikult (8*1000)/(8*50) = 20 B kõneandmeid. Lisades kõnele päised (RTP – 12B, UDP - 8B, IP – 20B) ning kanalikihi paketi päised (Etherneti puhul 18B), lisandub igale paketile 58 B päiseid. Seega on iga 20ms tagant vaja edastada 20+58=78B. Sekundis on vajalik summaarne andmeedastuskiirus ühes suunas seega 78*8*1000*50=31,2 kbit/s. Kahesuunalise kõne jaoks vajatakse aga 2*31,2=62,4 kbit/s.

2Näide Analoogselt arvutame G.711 edastamiseks vajaliku andmeedastuskiiruse: Kuna iga datagrammi suurus on 20ms ja sekundis on koodeki väljundi kiirusega 64 kbit/s, siis iga 20 ms tagant väljastatakse koodekist järelikult

51

64kbit/s=xB/20ms 64*1000*20/1000=1280bit=160B kõneandmeid. Lisades kõnele päised (RTP – 12B, UDP - 8B, IP – 20B) ning kanalikihi paketi päised (Etherneti puhul 18B), lisandub igale paketile 58 B päiseid.: Paketi suurus, mis on iga 20ms tagant vaja edastada - 160+12+8+18+20=218B. Ühes sekundis vajalik summaarne andmeedastuskiirus ühes suunas: 218*8*1000*1000/20=87,2 kbit/s. Kahesuunalise kõne jaoks vajatakse aga 2*87,2=174,4 kbit/s.

52

Tabe

l 4.1

. Ie

fakt

orid

eri

neva

te k

oode

kide

puh

ul [2

8, 2

9]

Koo

deki

tüüp

St

anda

rd

Koo

deki

V

älju

nd

Dat

agra

mm

i su

urus

Pa

ketti

de

moo

dust

amis

e hi

listu

min

e

2 vo

o ed

astu

skiir

us

Hili

stum

ise

kom

pens

eeri

mis

e pu

hver

Ie

väär

tus

Teo

reet

iline

m

aksi

maa

lne

MO

S PC

M,

Lain

ekuj

u ko

odek

G.7

11A

64

,0 k

bit/s

20

ms

1,0

ms

(2) 17

4,0

kbit/

s 2

data

gram

mi

(40m

s)

0 4,

40

AD

PCM

, La

inek

uju

kood

ek

G.7

26-3

2 32

,0 k

bit/s

20

ms

1,0

ms

110,

40 k

bit/s

2

data

gram

mi

(40m

s)

7 4,

22

CS-

AC

ELP

, K

õne

kom

pres

-si

ooni

koo

dek

G.7

29

8,0

kbit/

s 20

ms

25 m

s (1

) 62,4

0 kb

it/s

2 da

tagr

amm

i (4

0ms)

10

4,

07

MP-

MLQ

G

.723

.1

6,3

kbit/

s 30

ms

67,5

ms

43,7

3 kb

it/s

2 da

tagr

amm

i (6

0ms)

15

3,

87

AC

ELP

G

.723

.1

5,3

kbit/

s 30

ms

67,5

ms

41,6

0 kb

it/s

2 da

tagr

amm

i (6

0ms)

19

3,

69

53

Joonis 4.15. Kõnekompressiooni häiring [28] Joonisel 4.15 on toodud R kõverjooned kasutades koodekeid G.711, G.729A ja G.723.1 (6.3 kbit/s). Kuna kõne kompressiooniga koodekid G.729A ja G.723.1 omavad kõrgemaid Ie väärtusi, siis lubatav ühesuunaline hilistumine on sama R väärtuse saavutamiseks väiksem.

4.1.1.4 Paketikadudest tingitud häiringute arvestamine

Reaalaja protokolli RTP pakettide kaotsiminekuks on kaks peamist põhjust: liikluse ülekoormus, mille tagajärjel visatakse garanteerimata kvaliteediga võrgus paketid kõrvale ning pakettide hilistumise varieeruvus, mille tagajärjel pole võimalik kõiki pakette puhvris hoida. Inimkõrv ei taju juhuslikult kaduma läinud mõningate datagrammide kadu. Kuid purskeline paketikadu omab juba mõju tajutud kvaliteedile. Seega, kvaliteeti mõjutab paketikao kõrval ka kadude jaotus (juhuslik või purskeline) ning kõnekaadrite arv paketi kohta (kui palju kõneinfot oli kaotsiläinud paketis). Alljärgnev tabel toob välja häiringufaktori Ie, mida tuleb sõltuvalt koodekist ja paketikadudest kvaliteediparameetri R arvutamisel aluseks võtta.

54

Tabel 4.2. Häiringufaktor Ie paketikadude korral kasutades G.711, G.729A + VAD, G.732.1 + VAD koodekeid. [28] Sõltuvalt paketikadude suurusest protsentides valitakse esimesest tulbast tekkinud paketikaod ning vastavalt kasutatud koodekile leiame Ie faktori. Teine tulp iseloomustab Ie faktoreid kasutades koodekit G.711 ilma paketikao varjamise meetodita PLC (packet loss concealment, G.711 PLC meetod ANSI T1.521), järgmised kaks tulpa koos sama koodekit koos PLC-ga. PLC meetodi puhul on omakorda välja toodud häiringufaktorid nii juhusliku kui ka purskelise paketikao puhul. Kasutades G.711 koodekit, kukub hilistumist mitte arvestades maksimaalne võimalik R väärtus 1% paketikao puhul 94 punktilt 69 punktile. PLC lisab 5 ms hilistumist, kuid suudab „parandada“ kuni 40 ms kaotatud kõnet. Kuna üldjuhul esineb paketikadu purskeliselt, mitte harvaesinevate lühikeste kadudena, siis on paketikao mõjul oluline erinevus ka sõltuvalt kasutatavast koodekist, kuna ühes paketis on erineval määral kõneinfot. Vaadeldes joonist 5.9, peaks ideaalne graafik olema horisontaalne joon mööda x-telge, mille korral paketikao suurenemine ei suurenda häiringuid. Koodek G.711 ilma paketikao varjamise meetodita on paketikadudele kõige tundlikum, ka graafik on ideaalsele olukorrale peaaegu vastupidine, mille korral juba paketikadu üle 1% avaldab kõnekvaliteedile tuntavat mõju.

55

Joonis 4.16. Paketikao mõju parameetrile Ie. [28] Paketikadu peaks G.711 korral jääma alla 0,5%, et saavutada MOS väärtus üle 4,0. [28]

56

4.2 CISCO HÄIRINGUFAKTORITE HINDAMISE MEETOD ICPIF ICPIF (The Calculated Planning Impairment Factor) on objektiivne parameetritel põhinev kõnekvaliteedi hindamise meetod. Kuna magistritöö autor viibis töö kirjutamise ajal kolm nädalat British Telecom Exact teadus- ja uuringukeskuses Ipswich’is ning uuris Cisco häiringufaktorite hindamise meetodit ICPIF, valmis seal aruanne meetodi uurimistulemuste kohta, mis on ära toodud lisas B.

57

4.3 PESQ - OBJEKTIIVNE VÕRDLUSEL PÕHINEV MEETOD 1990ndate aastate lõpus hindas ITU viite erinevat kvaliteedi mõõtmise meetodit ning neist valiti edukaimad – PSQM99 ja PAMS, mis kombineeriti koos uute lisafunktsioonidega aastal 2001 uueks standardiks P.862 – PESQ. PESQ standard on ühesuunalise kitsaribalise kõnekvaliteedi mõõtmiseks. Testimiseks saab kasutada nii tehislikke kui ka loomulikke signaale ning meetodit võib kasutada koodekite hindamiseks ning võrgu testimiseks. PESQ on edu saavutanud nii lainekuju kui ka kõnekompressiooni koodekite puhul alljärgnevate mõõtetulemustega:

� ülekandekanali vead, � ülekandekanali poolt lisatav müra, � paketikadu, � koodekite transkodeerimise häiringud, � kõnesignaali moonutused. [30]

PESQ ei saa kasutada alljärgnevate mõõtmiste jaoks:

� hilistumine, � signaali vastuvõtu tase ja süsteemi koguvõimendus, � sisendsigaalis sisalduv müra, � koodekid <4kbit/s, � kuulaja kaja ja kõrvalsignaal (sidetone), � helitaseme kõikumine. [30]

Joonis 4.17. PESQ struktuur [25]

58

PESQ mõõdab ühesuunalist kõnekvaliteeti – signaal saadetakse läbi testsüsteemi ning võrreldakse seda vastuvõtjas sisend- ehk referentssignaaliga. Algoritmi võib kirjeldada järgmiste etappidena: [25, 30]

1. Eelprotsess: referentssignaal ja degradeerunud signaal viiakse samale võimsusele, et neid paremini võrrelda. Tase vastab subjektiivsetes testides kasutatavale normaalsele kuulmistasemele. Sisendfilter. PESQ modelleerib ja filtreerib signaali reaalsele telefoniseadmele ja võrgule vastavalt. Eksisteeriv muutuv hilistumine elimineeritakse, et signaalid oleksid võrreldavad.

2. Auditoorne transformeerimine: auditoorse transformeerimisega kaasatakse inimese taju, arvestades inimkõrva kuulmisega – tajumuslik sagedus ja helitugevus ning signaalist eemaldatakse osad, mida inimene ei taju. Tulemuseks saadakse signaali tajumuslik esitus, kirjeldatuna aja ja sagedusega, nimetatakse “aistingupinnaks” (sensation surface).

3. Häiringu protsess: kuuldav erinevus referents- ja degradeerunud signaali vahel

esitatakse aistingupindade erinevusena, mida nimetatakse “veapinnaks”. Peale pindade erinevuse hindamist arvutatakse:

o absoluutne (sümmeetriline) häiring – absoluutse kuuldava vea mõõt o aditiivne (asümmeetriline) häiring - absoluutse kuuldava vea mõõt, mille

korral kuuldav viga on referentssignaaliga võrreldes suur, tulemusena saadakse absoluutne ja aditiivne häiringufaktor.

4. Viimase protsessina kombineeritakse lineaarselt mõlemad häiringufaktorid, et

arvutada korreleeruv subjektiivne kvaliteedihinnang.

PESQ objektiivse meetodi hinnangu ja subjektiivse hinnangu kokkulangevust saab mõõta korrelatsioonikoefitsiendiga. Kasutades Pearsoni valemit, sai ITU erinevate testide käigus keskmiseks korreleeruvuseks 0,935. Nende testide käigus oli absoluutne viga alla 0,25 MOS (+-0,25 punkti 5-punkti skaalal) 72,3% juhtudest ning alla 0,5 MOS (+-0,5 punkti 5-punkti skaalal) 91,1% juhtudest. [15a] PESQ täpseim meetod objektiivsete võrdlusel põhinevate standardite hulgas. [8, 15a] PESQ meetodi negatiivseks küljeks on tulemused, mida on teatud tingimustes raske interpreteerida. Mudel hindab mõjusid, mis tulenevad näiteks ühesuunalise moonutuse ja müra häiringutest, kuid jätab arvesse võtmata kahesuunalise interaktsiooni efektid nagu kaja, helivaljus ja hilistumine. Seetõttu võib saavutada kõrge hinnanguga tulemuse, kuid helikvaliteet võib siiski olla halb. Meetod ei aita ka tuvastada probleemi allikat. Siiski on PESQ kasutatav kõne arusaadavuse ja loomulikkuse hindamiseks ning seda on võimalik kombineerida näiteks parameetritel põhineva meetodiga (E-mudel) - p. 4.5 „Transmissioonivõrgu planeerimine PESQ ja E-mudeli abil“.

59

4.4. IP TELEFONITEENUSE KÕNEKVALITEEDI ANALÜÜS Joonis 1 iseloomustas kõnekvaliteedi kategooriaid vastavalt ITU-T G.109 soovitusele. Vastavalt TIA/EIA/TSB 116 soovitusele võiks IP telefonisüsteemi korral ülalpool R=50 taset määratud kvaliteedikategooriad koondada viielt kategoorialt kolmele – kõrge (high), keskmine (medium), madal (low) ja kõik alla R=50 mitte-soovitav (not recommended).

Joonis 4.18. IP telefonisüsteemi kõnekvaliteedi soovituslikud kategooriad [28] Hilistumisest sõltuv kvaliteet nelja kvaliteedikategooria korral on toodud joonisel 4.19.

60

Joonis 4.19. Kõnekvaliteedi klassid referentsühenduse korral sõltuvana ühesuunalisest hilistumisest [28] 4.5 Transmissioonivõrgu planeerimine PESQ ja E-mudel abil Signaal-müra häiringufaktor Ro ning Is on funktsioonid mitmetest parameetritest, mis ei sõltu pakette edastavast IP-võrgust. ITU-T G.107 soovitab planeerimiseks kasutada vaikimisi väärtuseid (tabel A.1 lisas A Referentsühendustes kasutatavaid parameetreid), kui teatud parameetrid pole täpselt teada või on eesmärk uurida teiste parameetrite mõju kõnekvaliteedile. Lisaks võib eeldada, et kajakustutajad on olemas ja töötavad korralikult (s.t. eeldame, et kaja puudub – kontrollimiseks sooritatakse eraldi testid - näide p.6.3.4 „Näide kaja häiringu testimisest“). Valides Ro väärtuse vastavalt G.107 soovitusele ning eeldades, et faktor Is=0 ja eelisefaktor A=0, siis saame:

ed IIR ��� 2,93 {4.4}

Ie väärtuse (hindab häiringuid, mida põhjustab kõne kompresseerimine, paketikadu ja seadmed) võib valemisse leida näiteks PESQ testi abil, mille korral saadetakse läbi võrgu kõnesignaal ja saadakse info kõneselguse kohta. Kuna PESQ väljundiks on hinnang MOS-skaalal, saab R-faktori leida alljärgneva valemi abil:

))3

cos(2268(320 �

��� hR , kus

61

)202500111396090352215,675018566(2arctan31 2

CQECQECQE MOSMOSMOSh �����

ja

)arctan(xy

, kui x � 0

�),(2arctan yx

)arctan(x

y�

�� , kui x < 0.

[12] Id väärtuse (kõneleja ja kuulaja vaheline kõnesignaali hilistumine) võib leida eraldi testidega, mõõtes varieeruvaid hilistumised ning arvestades ka konstantsete hilistumistega (p. 4.1.1.1). Kombineerides PESQ ning E-mudeli koos eeltoodud valemiga, saame erinevaid võrguparameetreid ja konfiguratsiooni muutes hinnata, millistel tingimustel suudame saavutada vajaliku R väärtuse.

62

5. KVALITEEDI GARANTEERIMINE VÕRGUSEADMETES 3COM NÄITEL Liikluse prioritiseerimine switchides võimaldab tagada võrgu QoS, kuna kõrgemaprioriteediline liiklus (kõne, võrguhaldus) edastatakse minimaalse hilistumisega. Liiklust kontrollitakse reeglitega, mis defineerivad erinevad liikluse tüübid ning määravad kindlaks, kuidas erinevaid klasse tuleb switche läbides kohelda – näiteks kas prioritiseerida või kõrvale lükata. Liikluse prioritiseerimist switchis võib rakendada kahe faktori alusel:

� lõppkasutaja arvuti poolt küsitud teenuse tase – lõppkasutaja määrab ära iga liiklusvoo prioriteedi, vastuvõetud liiklus edastatakse switchis vastavas järjekorras sõltuvalt prioriteedist,

� switchi sisendliiklusele määratav teenuse tase – sõltuvalt konfiguratsioonist prioritiseeritakse liiklus etteantud parameetrite alusel.

3Com seadmed toetavad prioritiseerimiseks kahte meetodit: tavaline (basic) ja edasiarendatud (advandced). 5.1 TAVALINE PRIORITISEERIMISE MEETOD Tavaline meetod prioritiseerib liiklust vastavalt 2. kihi informatsioonile IEEE 802.1D kaadris ning antakse üle sobivale liikluse järjekorrale vastavalt IEEE 802.1p poolt määratud teenuse tasemele. Teenuse tase on märgistatud IEEE 802.1Q 4-baidises lipikus. Seetõttu on 802.1p liikluse prioriteete võimalik kasutada vaid võrgus, mis toetab ja on konfigureeritud kasutama VLAN-e ja VLAN lipikuid (p. 3.3.1.2).

Joonis 5.1. IEEE 802.1p prioriteeditasemed ja soovituslikud IEEE 802.1D liikluse tüübid [7]

63

1. Switchi saabuval paketil võib 802.1p lipik olla ja võib ka mitte olla. Kui ei ole, siis antakse talle vaikimisi 802.1p prioriteet 0. Paketi võib ka kõrvale visata või uue 802.1p prioriteediga märkida. 2. Kuna 802.1p prioriteeditasemed on fikseeritud liiklusklassidega (joonis 5.1), edastatakse paketid vastavasse järjekorda. Kui pakett on järjekorra ette jõudnud, vaadatakse, kas väljundport on sellise VLAN-i jaoks sildistatud. Kui on, siis lisatakse laiendatud 802.1D päisele uus 802.1p lipik. 802.1D standard määrab kindlaks kaheksa erinevat prioriteeditaset (0 kuni 7), mida seostatakse vastava liiklustüübiga. Näitena toodud 802.1p liiklusklassi edastus õigesse järjekorda (joonis 5.1) on fikseeritud ning tootjapõhine, erinedes mõnevõrra IEEE soovitusest [7]. Joonis 5.1 näitab, kuidas liikluse toimub liiklus prioritiseerimine 2. kihil. Switchi sisendpordis kontrollitakse IEEE 802.1D liikluse prioriteeti ning prioritiseeritakse vastavalt IEEE 802.1p väärtusele ehk teenuse tasemele. Vastavalt 802.1p väärtusele edastatakse liiklus väljundjärjekorda. 5.2 EDASIARENDATUD MEETOD Edasiarendatud prioritiseerimise puhul on võimalik liiklust klassifitseerida paketi atribuutide põhjal, mis pärinevad erinevatelt ISO OSI kihtidelt (vt p 3.3.1.1 tabel 3.2). Switch suudab vaadata teise, kolmanda, ja neljanda kihi atribuute, et sisenevat liiklust identifitseerida. Paljud rakendused ei ole QoS-teadlikud ja ei küsi saadetavate pakettidega vajalikku teenuse taset. Seepärast peab switch kasutama oma reegleid, et liiklust klassifitseerida ja märkida. Kui siseneval liiklusel aga on juba määratud prioriteet DSCP või 802.1D näol, saab olemasolevaid prioriteete kasutada või ümber muuta.

1. Switchi sisendpordis identifitseeritakse klassifitseerimismeetodi alusel liikluse (ISO OSI teisel, kolmandal või neljandal kihil) klass. Kõige tavapärasemad klassifitseerimismeetodid on DSCP, TCP/UDP pordid, IP aadressid ja 802.1D prioriteet.

2. Siseneva paketi klassifikatsiooni võrreldakse switchis ettemääratud klassidega ning vastavuse korral kinnitatakse konfigureeritud teenuse tase.

3. Vajaduse korral märgitakse üle 802.1p silt, kui paketil oli 802.1p silt ning DSCP väärtus IP paketis.

64

Joonis 5.2.. Liikluse prioritiseerimine ja märkimine edasiarendatud meetodi korral [7]

4. Vastavalt prioriteedile saadetakse paketid vastavasse väljundjärjekorda. a. Kui pakett vastab klassifitseerimisel konfigureeritud teenusetasemele ning

nõuab DSCP või 802.1p sildi muutmist, siis muudetakse paketis eelnevalt konfigureeritud DSCP ja/või 802.1p prioriteet.

b. Kui peale 802.1p sildi teisi klassifikaatoreid ei ole, saadetakse pakett edasi esialgse prioriteedi sildiga. Kui siseneval paketil puudub ka 802.1p silt, lisatakse vaikimisi 802.1p silt(väärtusega 0).

Järjekordade moodustamine Pakettide prioriteetimist switchis lubavad moodustatavad liikluse järjekorrad, igal liiklusklassil on temale vastav järjekord. Kõrgema prioriteediga liiklus saadetakse läbi switchi ilma madalama klassi liikluse mõjutusteta. Igal väljundpordil on oma järjekordade kogum, mis tähendab, et ummistuste tekkimine ühes pordis ei mõjuta teisi porte. 3Com switchid kasutavad WRR (weighted round robin) järjekordade moodustamise tehnikat. [7] Liikluse silumine 3Com SS3 switch 4400 lubab liiklust väljundpordis siluda, et vähendada ummistusi võrgus. Väljundliiklust saab seadistada kahe põhilise parameetri alusel:

- liikluse keskmine väljundkiirus (Mbit/s), - maksimaalne purske suurus (kbit/s).

65

5.3 SWITCH’I KONFIGUREERIMISE SAMMUD PRIORITISEERMISE AKTIVEERIMISEKS 1. Liikluse klassifitseerimine. Tekitatakse klassifitseerija, mille alusel liiklus

identifitseeritakse – klassifitseerida võib ISO OSI erinevate kihtide informatsiooni põhjal (tabel 3.2). Switch grupeerib klassifitseeritud liikluse, et edastada see vastavalt teenuse tasemele. Väljundis määrab liikluse järjekorra märgitud 802.1p silt. Vaikimisi on defineeritud viis klassifitseerijat (lisa C, tabel C.1).

Klassifitseerijaid saab lisada käskudega: trafficManagement/qos/classifier/create - enter classifier number

- enter classifier name - enter classifier type (ipAddr, ipProtocol, ipPort, dscp, etherType) - edasi sisestada andmed sõltuvalt valikust.

2. Teenuse tasemed. Määratakse igale liiklusklassile teenuse tase. Liiklust võib vastavalt

sellele kas kõrvale visata või seada 802.1D prioriteete vastavalt DSCP prioriteedile. Switch’is on eel-defineeritud kuus teenuse taset (lisa C, tabel C.2).

Teenuse tasemeid saab lisada käskudega: trafficManagement/qos/serviceLevel/create - enter service level number - enter service level name - enter 802.1D priority [0..7] - enter DiffServ code point (0-63, EF, AF11-AF43, no change )

3. QoS profiili tekitamine. QoS profiil võib koosneda mitmest reeglist, mis defineerivad, kuidas teatud liiklust edastada. QoS profiiliga seotakse klassifitseerijad teenuse tasemega. Profiiliga määratakse ühtlasi ka liikluse siluja kasutamine.

Profiile saab tekitada käskudega: trafficManagement/qos/profile/create - enter profile number - enter profile name trafficManagement/qos/profile/addClassifier - select classifier number

- enter service level number trafficManagement/qos/profile/addShaper

- select profile number - select shaper number

4. Peale QoS profiili tekitamist tuleb profiil pordi või portidega siduda. Käsk: trafficManagement/qos/profile/assign

66

Näiteks võib tekitada alljärgnevad reeglid (klassifitseerijad ja teenuse tasemed vastavalt lisas C toodud tabelitele C.1 ja C.2):

1. SNMP haldus – võrgukriitiline teenuse tase (network critical), 2. videovoog – videorakenduse teenus tase (video application service level), 3. e-post – parim võimalik teenuse tase (best effort), 4. kõne (VoIP) – kõneteenuse tase (voice service level).

Antud sammud on võimalik läbi viia kas tekstipõhiselt terminaliprogrammi kaudu või spetsiaalse veebipõhise haldustarkvara abil. Antud reeglite seadistamist katsetati väiksema missioonikriitilisusega võrgus 3Com 3 switch’idel. Meelespea switchide konfigureerimisel

� QoS nõuab toetust kõikidelt lõpp-punktide vahele jäävatelt switch’idelt. � Kõik seadmed peavad olema konfigureeritud samamoodi. Erinevuste korral võib

liiklus ühes seadmes olla prioritiseeritud, teises mitte. � Hub’e ei tohiks kasutada, nendega ei ole võimalik prioriteete seada. � Liiklus tuleb klassifitseerida kohe peale kõne- ja andmevoogude võrku sisenemist

– s.t. esimeses switch’is. � Liiklus märgitakse vastavalt klassifitseerimise tulemusele ning märkimist tuleks

teha ainult üks kord. � Kuna DSCP kasutab IP paketi välja, on DSCP-d võimalik kasutada ainult IP

pakettides.

67

6. KÕNEKVALITEEDI HINDAMINE MISSIOONIRIITILISES VÕRGUS Käesolevas peatükis on esitatud kõnekvaliteedi mõõtmistulemused töötavas missioonikriitilises võrgus, millel soovitakse tulevikus kasutusele võtta IP telefonisüsteem. Eesmärk on kontrollida, kas võrk vastab kõnesideks vajalikele kvaliteedikriteeriumitele ning kui ei vasta, siis tegema ettepaneku, mida peaks ette võtma, et kõneside kvaliteet vastaks nõuetele. Kuna IP telefonisüsteemi rakendamise korral on sisuliselt tegemist olemasoleva telefoniteenuse vahetamisega uue vastu, ei saa lubada kõnekvaliteedi langust, mistõttu seatavaks minimaalseks MOS väärtuseks on antud juhul 4,0 (p. 4.1 joon. 4.6). 6.1 ESITATAVAD KVALITEEDIKRITEERIUMID Seatud kvaliteedi saavutamiseks (MOS�4,0) on vaja täita alljärgnevad tingimused: 1. Lõppkasutajate vaheline ühesuunaline koguhilistumine peab jääma alla 150 ms (ITU-T G.114). [p. 4.1.1.1] 2. Hilistumise varieeruvus peab jääma alla 40ms, kui see ületab 50 ms, hakkab MOS tuntavalt langema. [p. 4.1.1.1] 3. Vastavalt ITU-T soovitusele G.168 peab IP telefonide puhul olema TCLw>=52dB, TIA-810-A nõuab miinimumina TCLw>=52dB, kuid võimaluse korral siiski TCLw>=55dB [28]. Praegusel juhul jäävad antud parameetrid testimata, sest kõneliiklus simuleeritakse ning telefone ei kasutata. Eeldatakse, et hiljem installeeritavad telefonid vastavad esitatud nõuetele. [p. 4.1.1.2] 4. Kui ühesuunaline kaja hilistumine ületab 25ms, hakkab kõneleja kaja tajuma. Antud juhul pole kaja tekkimine võimalik – akustilist kaja ei saa tekkida telefoniaparaatide puudumise tõttu, elektrilist kaja ei saa tekkida, kuna testitavas võrgus liigub kõne ainult kohtvõrgus ja pakettidena. Eeldatakse, et pakettsidevõrgu ühendamisel PSTN võrguga kasutatakse kajakustutajaid ning nende korrasolekuks viiakse läbi eraldi testid. [p. 4.1.1.2] 5. Eeldades, et kasutatakse koodekit G.711 ilma PLC meetodita, peab paketikadu võrgus jääma alla 0,5%. [p. 4.1.1.4] 6.2 Testimise metodoloogia Testitavaks võrguks oli ettevõttes kasutatav TCP/IP põhine Etherneti kohtvõrk, mille kõneside kvaliteedi hindamiseks simuleeriti võrgus kõnesid ning mõõdeti saadud parameetreid ning leiti häiringufaktorid. Hindamiseks kasutati tarkvara NetIQ Chariot ver. 4, magistritöö autorile anti NetIQ-st kasutamiseks tarkvara koos kuuajalise

68

laborilitsentsiga. NetIQ Chariot testmeetod kasutab kõnekvaliteedi hindamiseks E-mudelit ning on seega parameetritel põhinev meetod (joonis 4.1). Testvõrgu ja testseadmete põhimõtteline ülesehitus on toodud joonisel 6.1:

Joonis 6.1 Kasutatud testvõrgu põhimõtteline ülesehitus Teatud aja vältel edastati kahe lõpp-punkti (endpoint, seade B ja C) vahel kõnevoogusid parameetritega: - koodek G.711A (64 kbit/s); - hilistumiste erinevuste kompenseerimise puhver: staatiline, 40 ms; - QoS meetodeid võrgus pole rakendatud s.t. kõneside ei olnud prioritiseeritud; - paketikao avastamise ega veaparanduse meetodeid ei kasutatud; - tagasiside lõpp-punktidelt iga 3 sekundi tagant (timing record, edaspidi „väljavõte“); - testid olid ühesuunalised, korraga simuleeriti kas 10 või 20 ühepoolset kõnevoogu; - lõpp-punktide vaheline sünkroniseerimine toimus NTP serveri abil. Chariot mõõdab hilistumise varieeruvust kahe meetodi alusel: RFC 1889 hilistumise varieeruvus [edaspidi „RFC hilistumise varieeruvus“] arvutatakse vastavalt spetsifikatsioonile RFC 1889 (uuem versioon RFC 3550) [10,11], mis on pakettide saabumise aegade erinevuse statistiline varieeruvus, mida arvutatakse paketipaaride kohta. RFC meetodi korral mõõdetakse hilistumine iga väljavõtte korral. Teine meetod on täpsem, näidates pakettide saabumise aegade erinevust kõikide pakettide vahel

69

[edaspidi „hilistumise varieeruvus“], tulemus raporteeritakse küll iga väljavõtte kohta, kuid mõõdetakse iga paketi korral. [29] Lõpp-punktide vahelist tegevust juhtis seade A. Lisaliikluse tekitamiseks kasutati seadmeid D ja E. Telefonijaama statistika abil on vaja leida kõnede arv, kestvuse, sihtpunktid jms, et oleks võimalik hinnata, mis juhtuks, kui kõik kohalikud kliendid kasutaksid kõneedastuseks olemasolevat kohtvõrku. Testimine aitab leida nn. pudelikaelad ehk jõudluse poolest nõrgad seadmed või madala andmeedastusega võrgulülid, mis tuleks enne kohtvõrgus IP telefoniteenuse käivitamist optimeerimise eesmärgil ümber konfigureerida või suurema jõudlusega seadmete vastu välja vahetada. Testimise käigus simuleeritud ühesuunaliste kõnede arv 10 või 20 moodustab tegelikust maksimaalsest kasutusvajadusest vaid osa, kuid on esialgseks võrgu hindamiseks sobilik. Antud seadistus (erinevad arvutid liikluse tekitamiseks, erinevad lõpp-seadmed kõne vahendamiseks ning eraldi juhtarvuti) annab objektiivsema tulemuse, sest ka vaid kahe arvuti abil on võimalik liiklust tekitada, simuleeritud kõneliiklust vahendada ning juhtida, kuid siis võib kõnekvaliteeti mõjutada juba mõni arvuti parameeter (vähene protsessori jõudlus, mälu, võrgukaardi edastuskiirus). Alljärgnevalt on arvukate testide hulgast välja valitud vaid kolm testi, mis iseloomustavad kõige paremini saadavaid kvaliteedihinnanguid sõltuvalt võrgukoormusest. Esimene test on tehtud võrguliikluse poolest rahulikul ajal ilma lisaliikluseta, teine test on läbi viidud väikese võrguliikluse ajal ning kolmanda puhul on tekitatud lisaliiklust. 6.3 TESTID KÕNEKVALITEEDI HINDAMISEKS 6.3.1 Test 1 Test viidi läbi õhtul kell 20:03:24- 20:05:55 (2 min 31s), kui kohtvõrgu koormus oli minimaalne, lisaliiklust ei tekitatud. Ühepoolsete kõnevoogude arv: 20. Kõned algatati arvutis C ning vastuvõtjaks oli arvuti B. Võrgupoolne hilistumine (one way delay) jäi testi vältel alla 1 ms ja summaarne ühesuunaline hilistumine (end-to-end delay) ligikaudu 41 ms (hõlmab ka pakettidesse jagamise ja hilistumiste erinevuste kompenseerimise puhvrist tulenevaid viiteid). Pakettidevaheline hilistumise varieeruvus (jitter) RFC 1889 mõõtmise kohaselt oli maksimaalselt 1 ms, hilistumise varieeruvus maksimaalselt 31 ms. Paketikadu ei esinenud. Kõnekvaliteedi hinnanguteks saadi kogu testi vältel kõikide kõnede jaoks R=91,96 ehk MOS=4,38, mis on suurepärane tulemus (p.4, joonis 4.18), sest häiringufaktorid ei ületanud lubatud piire. Järeldus. Testi tulemus vastas nõuetele.

70

6.3.2 Test 2 Test viidi läbi päeval kell 12:04:49-12:34:50 (30 min 1s), kui kohtvõrgu koormus oli väike, lisaliiklust ei tekitatud. Kõned algatati arvutis C ning vastuvõtjaks oli arvuti B. Võrgupoolne hilistumine (one way delay) oli testi vältel maksimaalselt 8 ms, summaarne ühesuunaline hilistumine (end-to-end delay) keskmiselt 41 ms. Pakettidevaheline hilistumine varieeruvus (jitter) RFC 1889 mõõtmise kohaselt oli minimaalselt 0ms, maksimaalselt 13 ms ning keskmiselt 0,139ms, hilistumine varieeruvus maksimaalselt 42ms, kuid jäi siiski enamasti lubatud vahemikku (kuni 40 ms). Paketikadu esines purskeliselt ning kaduma läks keskmiselt 0,024 protsenti pakettidest kõne kohta. Kuna paketikaod esinesid purskeliselt, läks kaotsi järjestikku üks või kaks datagrammi. Kõikide kõnede keskmine kõnekvaliteet oli testi ajal R=91,46 ehk MOS=4,36, kuid kõikide kõnede minimaalseim kõnekvaliteet kogu testi vältel oli MOS=1,88, maksimaalseim 4,38. Lühiajalise madala kvaliteedihinnangu põhjuseks testi tulemustes oli väljavõtete sagedus 3 sekundit, mille korral ka üks kaotsiläinud pakett põhjustas suure kaoprotsendi (3 sekundi jooksul edastatakse G.711 korral 3x50=150 datagrammi (p. 4 tabel 4.1), mis annab ühe paketi kadumisel paketikaoks 0,667%), kuid üldjuhul see siiski niivõrd suurt mõju ei avalda. Järeldus. Üldjuhul oli kõnekvaliteet suurepärane, kuid kohati tekitasid hilistumise varieeruvus ja paketikadu minimaalse häiringu. 6.3.3 Test 3 Test viidi läbi õhtul kell 20:33:31 - 20:36:02 (2 min 31s), kui kohtvõrgu koormus oli minimaalne, tekitati lisaliiklus. Ühepoolsete kõnevoogude arv: 10. Kõned algatati arvutis C ning vastuvõtjaks oli arvuti B. Lisaliikluse tekitamiseks saadeti testpakette kümne ping käsu abil seadmest D kõnepakettide teel asuvasse võrguseadmesse (asub joonisel 6.1 kohtvõrgu „pilves“) koormusega 10 x 15 000 baiti, mis tekitab Etherneti võrgus maksimaalse suurusega paketid (standardne kaader 1518B, joonis 3.4) summaarse edastuskiirusega 1,144 Mbit/s. Kõik testvõrgus asuvad liidesed olid kiirusega minimalselt 100 Mbit/s. Võrgupoolne ühesuunaline hilistumine (one way delay) oli testi vältel maksimaalselt 8ms, keskmiselt 4ms (joonis 6.2), summaarne ühesuunaline hilistumine (end-to-end delay) ligikaudu 45 ms.

71

Joonis 6.2. Ühesuunaline hilistumine. Pakettidevaheline hilistumise varieeruvus (jitter) RFC 1889 mõõtmise kohaselt oli minimaalselt 1ms, maksimaalselt 7 ms ning keskmiselt 3,802ms (joonis 6.3), hilistumine varieeruvus maksimaalselt 95 ms, ületades enamuse testi ajast puhvri maksimaalse mahu (40 ms) - joonis 6.4. Hilistumise varieeruvuse tõttu läks summaarselt kaotsi 597 paketti, mis on protsentuaalselt 0,796% (kokku 10 kõnet * 150 sekundit * 50 paketti/sekundis ehk 75.000 paketti).

Joonis 6.3. Hilistumise varieeruvus RFC 1889 mõõtmise kohaselt

72

Joonis 6.4. Hilistumise varieeruvus. Joonise 6.5 histogramm iseloomustab testi käigus esinenud erinevate hilistumiste osakaalu.

Joonis 6.5. Hilistumise varieeruvuse histogramm. Paketikadu esines purskeliselt teisel minutil ning võrgus läks summaarselt kaduma 0,032

73

protsenti pakettidest: viie kõne korral summaarselt 0,027 ja viie kõne korral 0,040 protsenti pakettidest. Kuid paketikadu esines purskeliselt ja kaduma läks järjest vastavalt 2 ja 3 paketti, mis ajaliselt vastab 40ms ja 60ms kõneandmetele, avaldades kõnekvaliteedile mõju. Joonis 6.6 näitab hetke, mil esines purskeline paketikadu ning ühe väljavõtte kohta esines kuni 2-protsendiline paketikadu. Väljavõtted saadeti juhtarvutisse iga 3 sekundi tagant, G.711 koodeki korral saadetakse 50 paketti sekundis, kolme sekundi jooksul 150 paketti. Maksimaalne 2-protsendiline paketikadu tähendab kolm kadumaläinud paketti ühe väljavõtte kohta.

Joonis 6.6. Paketikadu, mida põhjustab hilistumise varieeruvus. Joonise 6.7 histogramm iseloomustab testi käigus esinenud järjestikuste paketikadude osakaalu.

74

Joonis 6.7. Järjestikku kaotsiläinud pakettide histogramm. Joonis 6.8 näitab hetke, mil esines järjestikune paketikadu.

Joonis 6.8. Maksimaalselt järjestikku kaotsiläinud paketid.

75

Kõikide kõnede keskmine kõnekvaliteet oli testi ajal R=74,90 ehk MOS=3,73 (kõikide kõnede minimaalseim kõnekvaliteet kogu testi vältel oli MOS=2,05, maksimaalseim 4,38).

Joonis 6.9. MOS hinnang. Järeldus. Testi tulemusel saadud kõnekvaliteedi hinnang ei vastanud esitatud nõuetele, põhjuseks eelkõige hilistumise varieeruvusest tõttu puhvri ületäituvusest tulenev paketikadu. 6.3.4. Näide kaja häiringu testimisest Kuna pakettsidevõrk ei ole kajade allikaks ning eeldasime, et kajakustutajad on telefonisüsteemis olemas ja töötavad, ei ole käesolevas töös kaja mõõtmise meetodeid põhjalikumalt kirjeldatud. Alljärgnevalt vaatleme siiski lühidalt võimalust, kuidas kaja olemasolul häiringu mõju hinnata. Testide läbiviimiseks külastas autor British Telecomi Frankfurdis, kus oli kasutada seade Agilent VQT, millega oli võimalik läbi viia PESQ kõneselguse teste. Režiimis Echo-PACE saadeti üle võrgu vastuvõtjale signaal A ning salvestati peegeldunud signaal Apeegel.. Kuna signaal edastati ühesuunaliselt, siis iga signaal, mis vastuvõtjasse tagasi saabus, oli elektriline kaja, mis vastaspoolelt tagasi peegeldus. Peegeldunud signaal Apeegel salvestati ja liideti saadetud signaaliga A, saadi uus signaal (A+ Apeegel). Kaja häiringu hindamiseks võrreldi PESQ meetodiga saadetud signaali A ning (A+ Apeegel) erinevust ning tekkinud häiringuid.

76

6.4 NETIQ CHARIOT JA E-MUDELI KVALITEEDIHINNANGU VÕRDLUS Võrdleme Chariot’i poolt leitud kõnekvaliteedi hinnangut E-mudeli teoreetilise kvaliteediga. Juhuslikult valitud võrdluseks kasutame p.6.3.3. test 3 väljavõtet hetkel 1min 33s, mis vastab 31. väljavõttele. 31. väljavõtte parameetrid on alljärgnevad: - paketikadu – 3 paketti ehk 2% (3 paketti 150-st), - hilistumise varieeruvus 70 ms, - hilistumise varieeruvuse puhvri ületäituvusest tingitud paketikadu – 3 paketti ehk 2%, - ühesuunaline hilistumine 4 ms. Chariot raporteerib 31. väljavõtte kõnekvaliteedi hinnanguks R=43,45 ehk MOS=2,24. Kui võtta aluseks E-mudeli soovituse G.107 ning kasutame valemit [punkt 4.1]

AIeIdIsRoR ����� ,

kuid valime Ro väärtuse vastavalt G.107 soovitusele ning eeldame, et faktor Is=0 ning eelisefaktor A=0, siis saame kasutada lihtsustatud mudelit:

ed IIR ��� 2,93 . Kuna kajad puuduvad (vt. testimise metodoloogia), siis on ainsaks faktoriks, mis parameetrit Id suurendab, kõneleja ja kuulaja vaheline kõnesignaali hilistumine, mis jääb lubatud piiridesse, kuid lubatud piiri ületab paketikadu võrgus– 3 paketti ning hilistumise varieeruvus – 70ms, mis põhjustab lisaks 3 paketi kadumise. Kokku kaob seega 31. väljavõtte ajal 6 paketti 150-st ehk 4 protsenti. Vastavalt [28] tekitab see häiringufaktori

50�eI , seega

2,435002,93 ����R ehk vastavalt valemile 4.2 punktis 4.1

MOS � 2,2.

Järeldus. NetIQ Charioti kõnekvaliteedi hinnang põhineb E-mudelil ning seda kinnitab ka teostatud kontrollarvutus. 6.5 KÕNEKVALITEEDI MÕÕTMISTULEMUSTE KOKKUVÕTE Väikese võrguliikluse puhul on kohtvõrgus edastatava kõnede kvaliteet nõuetele vastav, kuid viimane test näitab häiringute tekkimise võimalikkust võrgukoormuse kasvades. Võrgus tekitati koormus, mis on eksperthinnangu kohaselt tõenäoline võrgus esinev

77

liiklus. Kuna ka kõneliiklus oli minimaalne ning ühesuunaline, võib järeldada, et kohtvõrk ei ole esitatud nõuete korral suurema koormusega võrguliikluse ajal IP kõnesideks sobilik. Ettevõttele on kohtvõrgu seadistamiseks esitatud soovitused teatud seadmete uuendamiseks, sest erinevaid võrgulülisid testides selgus jõudluse poolest nõrku seadmeid. Konfidentsiaalsuse tõttu neid käesolevas magistritöös ei ole loetletud. Peale kitsaskohtade likvideerimist peaks võrgusõlmedes seadma kõnele prioriteedid vastavalt peatükis 6 kirjeldatud meetoditega. Peale prioriteetide seadmist tuleks läbi viia uued testid. Uus testimise käigus tuleb testida kõik kõnesideks tarvitatavad võrgulülid ning ka võrguliikluse tippaegade ajal kvaliteedihinnangute saamiseks on soovitav testide pikkust ning testimise aega muuta vastavalt võrguliikluse statistikale (sõltuvalt ettevõtte tööst kujuneb tihti võrguliikluse koormuse ligikaudne mudel – millisel päeval ja ajal esinevad kõige tõenäolisemalt tipud, millal on võrguliiklus minimaalne). Telefonijaama kõnestatistikat kasutades konfigureerida simulatsioon maksimaalse korraga esinevate kõnede arvuga.

78

7. KOKKUVÕTE Magistritöös uuritud kvaliteedikriteeriumite seadmine, kõnepakettide prioritiseerimine ja erinevate meetoditega kõnekvaliteeti mõjutavate parameetrite mõõtmine põhinevad nii missioonikriitilises kui ka vähem missioonikriitilises koht- ja laivõrgus teostatud testimistel ning konfigureerimistel. Töö eesmärgiks on selgitada, kuidas oleks võimalik kõnet IP-põhises pakettsidevõrgus kvaliteetselt edastada. Selleks leitakse esmalt, kuidas seada kõnele kvaliteedikriteeriumid. Kuna IP telefoniteenus kohtvõrgus asendab oma olemuselt olemasoleva kõneteenuse, ei saa uue teenuse kõnekvaliteet olla madalam ning seatavaks kvaliteedipiiriks võiks üldjuhul olla MOS hinnang minimaalselt 4,0. Kui kriteeriumid seatud, peab arvestama faktoreid, mis pakettsidevõrgus kõnekvaliteeti kahjustavad. Peamised faktorid on paketikadu, hilistumine ja hilistumise varieeruvus, mis kõik peaksid jääma lubatud vahemikesse. Rakendama peaks kvaliteedi tagamise meetodeid ning kõikides lõpp-punktide vahele jäävates seadmetes kõnesidet muule liiklusele eelistama. Vastavalt võimalusele ja võrgule valitakse sobiv prioritiseerimise meetod. See on aga võimalik ainult juhul, kui kogu võrk on administraatori kontrolli all või kui teenusepakkuja pakub liikluse prioritiseerimist; üle Interneti ei ole võimalik kvaliteeti garanteerida. Katsed näitasid, et ummikute tekkimisel võib esialgu näiliselt suurepärase kvaliteediga kõnesidet tagav edastusvõrk osutuda kõnele mittesobivaks. Töös uuritakse, kuidas mõõta ja hinnata võrguparameetrite vastavust seatud nõuetele. Kvaliteet on subjektiivne faktor, mida ei ole võimalik otseselt mõõta, kuid eeldatavat kvaliteeti saab objektiivsete mõõtmistulemuste abil hinnata. Käsitlemist leiavad parameetritel põhinevad meetodid E-mudel ja ICPIF ning võrdlusel põhinev meetod PESQ. Mõõtmisi peab teostama kasutades koormusi, mida tekitaks reaalne rakendatav telefonisüsteem. Oluline on mõista, et koodeki väljundkiirus ei näita veel tekkivat võrguliiklust, mahtude kalkuleerimisel on vaja arvestada ka erineva kihtide paketipäistega. Meetodeid võib mõõtmistel ka kombineerida, näiteks PESQ tulemust E-mudelis ühe häiringufaktorina kasutada. E-mudeli hinnangu R või MOS-CQE abil saab kvaliteeti iseloomustava arvu, mis arvestab paketikadu, hilistumist, hilistumise varieeruvust ja koodekitest tulenevaid häiringuid. Kuid E-mudeli valemi parameetreid kasutades saab lokaliseerida ka kõnekvaliteedi langust põhjustava faktori. Süstemaatiliste testimistega on võimalik leida jõudluse poolest nõrgad seadmed, võrgu kitsaskohad vms kvaliteeti halvendavad võrgusegmendid või sõlmed. Tulemuste interpreteerimine on mõõtmistulemuste juures väga oluline samm. Testimise tulemusena annavad programmid suurel hulgal andmeid, jooniseid ja tabeleid, mille õigeks tõlgendamiseks ja järelduste tegemiseks peab magistritöös kirjeldatud teooriaga väga hästi kursis olema. Kvaliteedihinnangute korral peab meeles pidama, et kõnekvaliteedi langus võib olla põhjustatud korraga ka mitmest häiringust. Paketikadude

79

korral ei saa arvestada ainult paketikao protsendiga, mille keskmine näitaja võib jääda lubatud piiresse. Väljavõtete tabelit uurides võib selguda, et teatud hetkedel läheb kaduma mitmeid pakette järjest ning seega ületab lubatud piirid. Seetõttu ei piisa vaid seadme poolt väljastatud keskmise kvaliteedihinnangu teadvustamisest. Pakettsidevõrk ei ole kajade allikaks, aga kui IP telefonisüsteemi rakendamisel ühendatakse pakettsidevõrk kokku PSTN-võrguga, tuleb kasutada kajakustutajat ning selle korrasolekuks läbi viia eraldi testid. Magistritöö selgitab põhjalikult, mis on kaja tekkimise põhjuseks ja kuidas see kõnekvaliteedile mõju avaldab. Et autoril oli võimalus erinevates võrkudes testimisi läbi viia, tehislikult häiringuid tekitada ja sellest tulenevalt kvaliteedihinnangute muutusi jälgida, põhineb käesolev töö suurel määral praktilistel katsetustel. Magistritöö kirjutamise käigus omandas autor nii teoreetilisi teadmisi kui praktilisi kogemusi, ühtlasi tutvus vastava ala spetsialistidega, kes oma tarkust jagasid. Valminud tööd saab juhendava abimaterjalina kasutada IP-põhiste kommunikatsiooni-võrkude planeerimisel ja kvaliteeditestide läbiviimisel.

80

8. VIITELOETELU [1] Ascom. Technical White Paper Series, Speech Quality and its objective evaluation with PACE. 1998. [2] ETSI EG 201 377-3 V1.1.1. Speech Processing, Transmission and Quality Aspects (STQ); Specification and measurement of speech transmission quality; Part 3: Non-intrusive objective measurement methods applicable to networks and links with classes of services. 03/2004. [3] EVS 874:2003. Kõne töötlemise, ülekande ja kvaliteedi aspektid (STQ). Teenuse kvaliteedi parameetrite määratlused ja mõõtmine. ONP kõneside direktiiviga 98/10/EÜ nõutud kõnesideteenuse parameetrid. 2003. [4] EVS-ISO/IEC 2382-14:1999 Infotehnoloogia sõnastik. Osa 14: Töökindlus, hooldatavus ja käideldavus. [5] Hanson, V. Infosüsteemide turve 1. Turvarisk. Tln., Küberneetika AS, 1997, 125 lk. [6] http://itresearch.forbes.com/detail/RES/1042572934_765.html Extreme Networks Metro Technology Guides. Tech guide. Extreme Networks, 2002. [7] http://www.3com.com 3Com Switch 4400 Implementation Guide. 2004. [8] http://www.cisco.com DiffServ – The Scalable End-to-End QoS Model. White Paper. Cisco, 2001. [9] http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/voipsol/ea_isd.pdf Echo Analysis for Voice over IP. Cisco, 2002. [10] http://www.faqs.org/rfcs/rfc1889.html RFC 1889 - RTP: A Transport Protocol for Real-Time Applications. 1996. [11] ftp://ftp.rfc-editor.org/in-notes/rfc3550.txt RFC 3550 - RTP A Transport Protocol for Real-Time Applications. 2003. [12] http://www.itu.int ITU-T soovitus G.107, The E-Model, a computational model for use in transmission planning, 03/2003, 2003.

[13] http://www.itu.int. ITU-T soovitus G.109 Definition of categories of speech transmission quality, 09/99. 1999.

[14] http://www.itu.int. ITU-T soovitus G.113, Transmission impairments due to speech processing 05/2002.

81

[15] http://www.itu.int ITU-T soovitus G.168, Digital network echo cancellers. 2002.

[15a] http://www.itu.int ITU-T soovitus P.862. PESQ – Perceptual Evaluation of Speech Quality. [16] http://www.netiq.com. User Guide for Chariot. Understanding Jitter Measurements. 2004. [17] http://www.nwc.com/1011/1011colwillis.html Willis, D. Measuring Voice Quality: Listening by the Numbers. 1999. [18] http://www.qosforum.com [19] http://www.symmetricom.com/media/pdf/documents/ds-ts-3000.pdf [20] http://www.whatis.com

[21] Inkinen, J. Integreeritud Magistraalvõrk. Bakalaureusetöö. Tallinn, 2004. [22] Khasnabish, B. Implementing voice over IP. Wiley, 2003. [23] Kobin, R. Ettevõtte integreeritud kommunikatsioonivõrk, bakalaureusetöö, Tln. 2000. [24] Miras, D. A Survey on Network QoS Needs of Advanced Internet Applications. Internet 2 workgroup. 2002 [25] Psytechnics. PESQ: An Introduction. White Paper. 2001 [26] Soikonen, A. Kõneteenuse kvaliteedi hindamine ja jälgimine GSM võrgus, magistritöö. Tln, 2003. [27] Stallings, W. High Speed Networks and Internets, Second Edition. 2002. [28] TIA/EIA TSB 116 03/2001. Telecommunication Systems Bulletin. Telecommunications. IP Telephony Equipment. Voice Quality Recommendations for IP Telephony. 2001. [29] Walker J., Hicks, T. NetIQ. VoIP Implementation and Management. 2002. [30] Werner, H. Quality of Service in IP Telephony – an End to End Perspective, master’s thesis project, Chalmers University of Technology. 2003.

82

LISA A E-MUDEL, ITU-T SOOVITUS G.107 (03/2003) A.1 ERINEVATE PARAMEETRITE TÄHENDUSI The factor R0 is defined as the basic signal-to-noise ratio, estimated at the virtual centre, the 0dB reference point. The R0 factor is dependent on the following metrics: No The No is the power addition of different noise sources (estimated at the

reference point). (dBm) Nc Nc is the sum of all circuit noise powers, all referred to the reference

point. (dBm) Nos Nos is the equivalent circuit noise at the reference point, caused by the

room noise Ps at the send side. (dBm) Nor Nor is the equivalent circuit noise at the reference caused by the room

noise Pr at the receive side. (dBm) Pre Pre is the “effective room noise” measured at the reference caused by the

enhancement of Pr by the listener’s sidetone path (in dBm) Ps Ps is the room noise at the send side Pr Pr is the room noise at the receiver side OLR OLR represents the overall loudness rating SLR SLR is the sender loudness rating RLR RLR stands for the receiver loudness rating Nfo Nfo represents the “noise floor” at the receiving side Nfor Nfor is usually set to the constant value of –64 dBmp The factor Is is the sum of all impairments that occur more or less simultaneously with the voice transmission. The simultaneous impairment factor is divided into three subdivisions: Iolr Iolr represents the decrease in quality due to too-low values of OLR, also

called excessive loudness. Ist Ist is the impairment caused by non-optimum sidetone effects. Iq Iq represents the impairment caused by quantizing distortion. In this formula, qdu means the number of quantizing distortion units for the whole connection between send side and receive side. If an Ie value is calculated for a piece of equipment, the qdu value for this equipment should not be used. Id is the delay impairment factor that can be divided into three parts: Id = Idte + Idle +Idd 1. Idte is an estimation of the impairments due to talker echo 2. Idle corresponds to impairments caused by listener echo. 3. Idd represents the impairment caused by an absolute delay, Ta that is too long. Ta can become too long even when using perfect echo canceling.

83

The delay impairment factors are in turn dependent on the following metrics: Ta Ta is the absolute delay Tr Tr signifies the roundtrip delay in a 4-wire loop T T represents the mean one-way delay of the echo path WEPL WEPL symbolizes the weighted echo path loss TELR TELR is the talker echo loudness rating STMR STMR stands for the sidetone making rating RLR RLR, which is the receiver loudness rating The Ie parameter represents the equipment impairment and is the most complex of all parameters in the E-model. The Ie factor was earlier represented by tabulated values depending on the codec used and introducing different amounts of degradations. The factor has today been improved to also include packet loss degradations, which has resulted in the Ie,eff factor defined by the following formula:

Ie Ie is the equipment impairment factor. Bpl Bpl is called the packet-loss robustness factor, which depends on the

used codec. Ie,eff Ie,eff represents the packet loss dependent effective equipment

impairment factor, derived from the value of Ie depending on codec and at zero packet loss.

Ppl Ppl is the packet loss probability. The parameter A is called the advantage factor or the expectation factor and can be used to correlate the result from the formula according to non-technical parameters. For instance, customer expectations or requirements can affect the perceived transmission quality. The combination of different impairments can also have a smaller impact than what is assumed by adding them together. The A factor can include factors like these into the calculations to achieve a better quality prediction but is however not recommended for usage when measuring IP connections. The recommended advantage factor value is 0 for VoIP measurements and the resulting formula therefore becomes: R = Ro – Is – Id – Ie,eff [12]

84

A.2 REFERENTSÜHENDUSES KASUTATAVAD PARAMEETRID Tabel A.2 iseloomustab suurusi, mida kasutatakse E-mudeli referentsühenduses.

Tabel A.2. Vaikimisi väärtused, mida E-mudeli väärtuse R arvutamisel aluseks võetakse [12]

85

LISA B

CISCO HÄIRINGUFAKTORITE HINDAMISE MEETOD ICPIF

BRITISH TELECOM’ILE KIRJUTATUD ARUANNE TESTIMISTULEMUS-TEST

86

British Telecom

Cisco Service Assurance Agent VoIP UDP operations

Jarmo Inkinen

Ipswich 2004

87

Introduction

This report is written to recapitulate the testing and observations of the Cisco SAA (Service Assurance Agent) VoIP UDP operations.

The first part of the report explains the essence and operating principles of the Cisco SAA, the second part explains the test methodology and displays the measurement results and the last part counts the observations made by the author during the tests.

88

PART I What is SAA Cisco IOS® Service Assurance Agent (SAA) is an embedded network performance measurement and diagnostics tool that uses active monitoring. Active monitoring is the generation of traffic in a reliable and predictable manner to measure network performance. Cisco IOS SAA actively sends data across the network to measure performance between any two network locations or across multiple network paths. It simulates Voice over IP (VoIP) codecs and collects network performance information in real time, including response time, one-way latency, jitter, packet loss and voice quality scoring. It also provides the mechanism to monitor performance for different classes of traffic over the same connection. The aim is to measure the network's ability to support voice traffic and Quality of Service (QoS) prior to a VoIP deployment and, as well as to measure and troubleshoot new technologies, such as VoIP, after the deployment.

Cisco IOS SAA measures performance by sending one or more packets to a destination IP device or a Cisco router. These are echoed back to the sender, which is similar to PING functionality. Cisco IOS SAA uses the timestamp information to calculate performance metrics such as jitter, latency, and response time, packet loss, MOS, and ICPIF Voice Quality scores.

A destination router that is running Cisco IOS Software can be configured as a Cisco IOS SAA Responder, which processes measurement packets and provides detail timestamp information. The responder has intimate knowledge of Cisco IOS Software processing, so it can send information about the destination router's processing delay back to the source. This delay is removed during calculation to further improve accuracy.

VoIP networks frequently include QoS class-based performance. Cisco IOS SAA can be configured to monitor per-class traffic over the same link by setting the Diff-Serv Code Point (DSCP) bits. Cisco IOS SAA provides a proactive notification feature with SNMP traps. Each measurement operation can monitor against a pre-set performance threshold. [3] The ability to simulate voice codecs and calculate MOS and ICPIF voice scores is an additional feature to the SAA jitter probe that was introduced in IOS 12.3(4)T.

89

Measurement Capability Key Applications

UDP Jitter for VoIP

� Round-trip delay, one-way delay, one-way jitter, one-way packet loss

� VoIP Codec simulation G.711 ulaw, G.711 alaw and G.729a.

� MOS and ICPIF Voice quality scoring capability

� One-way delay requires time synchronization between the SAA source and target routers.

Most common operations for networks that carry voice traffic, such as IP backbones

Table 1 Cisco IOS SAA Operations and Applications: UDP jitter for VoIP [3]

Mean Opinion Scores (MOS) The quality of transmitted speech is a subjective response of the listener. Each codec used for transmission of Voice over IP provides a certain level of quality. A common benchmark used to determine the quality of sound produced by specific codecs is MOS. With MOS, a wide range of listeners have judged the quality of voice samples sent using particular codecs, on a scale of 1 (poor quality) to 5 (excellent quality). The opinion scores are averaged to provide the mean for each sample. Table 2 shows MOS ratings and the corresponding description of quality for each value. As the MOS ratings for codecs and other transmission impairments are known, an estimated MOS can be computed and displayed based on measured impairments. This estimated value is designated as MOS-CQE (Mean Opinion Score; Conversational Quality, Estimated) by the ITU in order to distinguish it from objective or subjective MOS values (ITU-T recommendation P.800: “Recommendation regarding methods for the subjective determination of transmission quality”).

Table 2. MOS Ratings [5]

90

Voice Performance Monitoring Using SAA SAA provides a Jitter monitoring operation, which consists of UDP probe packets sent across the network from an origin device to a specific destination (called the operational target). This synthetic traffic is used to record the amount of jitter for the connection, as well as the round-trip time, per-direction packet loss, and one way delay time (one way latency). The latter requires time synchronization (NTP or GPS) between the SAA source and target routers. Codec Simulation Within SAA The SAA Jitter operation computes statistics by sending n UDP packets, each of size s, sent t milliseconds apart, from a given source router to a given target router, at a given frequency f. The target router must be running the SAA Responder in order to process the probe operations. To generate MOS and ICPIF (discussed later in “The Calculated Planning Impairment Factor (ICPIF)”) scores, you specify the codec type used for the connection when configuring the Jitter operation. Based on the type of codec you configure for the operation, the number of packets (n), the size of each payload (s), the inter-packet time interval (t), and the operational frequency (f) will be auto-configured with default values. Table 3 shows the default parameters that are configured for the operation by codec. For example, if you configure the Jitter operation to use the characteristics for the g711ulaw codec, by default a probe operation will be sent once a minute (f). Each probe operation would consist of 1000 packets (n), with each packet containing 180 bytes of synthetic data (s), sent 20 milliseconds apart (t).

Table 3 Default Jitter Operation Parameters by Codec [5]

Simulating a Voice Call The explanation, how to set up a jitter probe, is explained in Part III under Test Methodology, Synthetic voice call set-up.

91

Jitter Calculations in Cisco SAA Delay Jitter Probes

Jitter is the variance in one-way latency and is calculated based on sending and receiving time stamps of consecutive packets sent out.

Time Stamp Sender Responder

T1 send pkt1

T2 recv pkt1

T3 send back reply for pkt1

T4 recv reply for pkt1

T5 send pkt2

T6 recv pkt2

T7 send back reply for pkt2

T8 recv reply for pkt2

Table 4. Jitter calculation [4]

For packet 1 and packet 2 above, use the following source and destination calculations.

� Jitter from source to destination (JitterSD) = (T6-T2) - (T5-T1)

� Jitter from destination to source (JitterDS) = (T8-T4) - (T7-T3)

Jitter is calculated using time stamps of every two consecutive packets. For example:

Router1 send packet1 T1 = 0 Router2 receives packet1 T2 = 20 ms Router2 sends back packet1 T3 = 40 ms Router1 receives packet1 response T4 = 60 ms Router1 sends packet2 T5 = 60 ms Router2 receives packet2 T6 = 82 ms Router2 sends back packet2 T7 = 104 ms

92

Router1 receives packet2 response T8 = 126 ms Jitter from source to destination (JitterSD) = (T6-T2) - (T5-T1) Jitter from source to destination (JitterSD) = (82 ms - 20 ms) - (60 ms - 0 ms) = 2 ms positive jitter SD Jitter from destination to source (JitterDS) = (T8-T4) - (T7-T3) Jitter from destination to source (JitterDS) = (126 ms - 60 ms) - (10 4ms - 40 ms) = 2 ms positive jitter DS [4] The Calculated Planning Impairment Factor (ICPIF) The ICPIF originated in the 1996 version of ITU-T recommendation G.113, “Transmission impairments”. ICPIF (calculated planning impairment factor) attempts to quantify, for comparison and planning purposes, the key impairments to voice quality that are encountered in the network. The ICPIF is the sum of measured impairment factors (total impairments, or Itot) minus a user-defined access Advantage Factor (A) that is intended to represent the user’s expectations, based on how the call was placed (for example, a mobile call versus a land-line call). In its expanded form, the full formula is expressed as:

Icpif = Io + Iq + Idte + Idd + Ie – A [3] • Io represents impairments caused by non-optimal loudness rating, • Iq represents impairments caused by PCM quantizing distortion, • Idte represents impairments caused by talker echo, • Idd represents impairments caused by one way transmission times (one way delay), • Ie represents impairments caused by equipment effects, such as the type of codec used for the call and packet loss, and • A represents an access Advantage Factor (also called the user Expectation Factor) that compensates for the fact that users may accept some degradation in quality in return for ease of access. ICPIF values are expressed in a typical range of 5 (very low impairment) to 55 (very high impairment). ICPIF values numerically less than 20 are generally considered “adequate.” While intended to be an objective measure of voice quality, the ICPIF value is also used to predict the subjective effect of combinations of impairments. Table 5, taken from G.113 (02/96), shows how sample ICPIF values are expected to correspond to subjective quality judgement. Note The latest version of the ITU-T G.113 Recommendation (2001), no longer includes the ICPIF model. Instead, it refers implementers to G.107: “The Impairment Factor method, used by the E-model of ITU-T G.107, is now recommended. [1, 2] The full E-Model (also called the ITU-T Transmission Rating Model), expressed as R = Ro - Is - Id – Ie + A, provides the potential for more accurate measurements of call quality by refining the definitions of impairment factors. Though the ICPIF shares terms for impairments with the E-Model, the two models should not be confused. [3]

93

Table 5. Quality Levels as a Function of Total Impairment Factor ICPIF [1,3] The SAA VoIP UDP Operation feature takes advantage of observed correspondences between the ICPIF, transmission rating factor R, and MOS values, but does not yet support the E-Model. SAA uses a simplified ICPIF formula. Because packet delay and packet loss can be measured by SAA, the full ICPIF formula, Icpif = Io + Iq + Idte + Idd + Ie – A, is simplified by assuming the values of Io, Iq, and Idte are zero, resulting in the following formula:

Total Impairment Factor (Icpif) = Delay Impairment Factor (Idd) + Equipment Impairment Factor (Ie) – Expectation/Advantage Factor (A) [3]

This means that the ICPIF value is computed by adding a Delay Impairment Factor, which is based on a measurement of delayed packets, and an Equipment Impairment Factor, which is based on a measurement of lost packets. From this sum of the total impairments measured in the network, an impairment variable (the Expectation Factor) is subtracted to yield the ICPIF. This is the same formula used by Cisco Gateways to calculate the ICPIF for received VoIP data streams. 6 The Delay Impairment Factor The Delay Impairment Factor (Idd) is a number based on the measured one way delay. In this context, one way delay is a combination of the OneWay Transmission Delay, as measured by the SAA operation, combined with the static values (as defined in the ITU standards) for the Codec Delay, the Look Ahead Delay, and the Digital Signal Processing (DSP) Delay. Table 6 shows sample correspondences between the measured One Way Transmission Delay and Delay Impairment Factor values. The Equipment Impairment Factor

94

The Equipment Impairment Factor (Ie) is a number based on the amount of measured packet loss. The amount of measured packet loss, expressed as a percentage of total number of packets sent, corresponds an Equipment Impairment Factor that is defined by codec. Table 7 shows sample correspondences between the packet loss measured by SAA and Equipment Impairment Factor values.

Table 6. Sample Correspondence of Measured Delay to ICPIF Delay Impairment [3]

Sample Correspondence of Measured Delay to ICPIF Delay Impairment

0 0 310

1520

2530

3540

-10

0

10

20

30

40

50

0 50 100

150

200

250

300

350

400

450

500

550

600

650

700

750

800

Delay (ms)

ICP

IF

Figure 1 . Sample Correspondence of Measured Delay to ICPIF Delay Impairment according to the Cisco documentation. Note. Compare with test 2.

95

Table 7. Sample Correspondence of Measured Packet Loss to ICPIF Equipment Impairment [3]

Sample Correspondence of Measured Packet Loss to ICPIF Eqiupment Impairment (PCM G.711)

05

101520253035

0% 1% 2% 3% 4% 5% 6% 7% 8%

Packet Loss (%)

ICP

IF

Figure 2. Sample Correspondence of Measured Packet Loss to ICPIF Equipment Impairment (codec PCM G.711) according to the Cisco documentation. Note. Compare with test 4.

96

Sample Correspondence of Measured Packet Loss to ICPIF Eqiupment Impairment (CS-ACELP G.729A)

0

10

20

30

40

50

0% 1% 2% 3% 4% 5% 6% 7% 8%

Packet Loss (%)

ICP

IF

7 Figure 3. Sample Correspondence of Measured Packet Loss to ICPIF Equipment Impairment (codec CS-ACELP G.729A) according to the Cisco documentation. Note. Compare with test 5. The SAA MOS Value SAA uses an observed correspondence between ICPIF and MOS values to estimate an MOS value. Usage of the abbreviation MOS within the context of this feature should be taken to represent the MOS-CQE (Mean Opinion Score; Conversational Quality, Estimated). The E model, as defined in G.107 (03/2003) [2], predicts the subjective quality that is experienced by an average listener by combining the impairment caused by transmission parameters (such as loss and delay) into a single rating, the transmission rating factor R (the R Factor). This rating, expressed in a scale of 0 (worst) to 100 (best) can be used to predict subjective user reactions, such as the MOS. Specifically, the MOS can be obtained from the R Factor with a converting formula. Conversely, a modified inverted form can be used to calculate R Factors from MOS values. There is also a relationship between the ICPIF value and the R Factor. SAA takes advantage of this correspondence by deriving the approximate MOS score from an estimated R Factor, which, in turn, is derived from the ICPIF score. Table 9 shows the resulting MOS values that will be generated for corresponding ICPIF values. [3]

97

Table 8. Advantage Factor Recommended Maximum Values [3]

Table 9. Correspondence of ICPIF Values to MOS Values [3] Note. According to Cisco documentation, SAA will always express the estimated MOS value as a whole number in the range of 1 to 5, with 5 being the best quality. A MOS value of 0 (zero) indicates that MOS data could not be generated for the operation. But the tests show, that this is not true, actual ICPIF-to-MOS mapping uses finer granularity that Cisco documentation suggests. (See Part II, Test “The relationship between ICPIF and MOS”)

98

PART II THE TESTS Hardware, software and the set-up of the test bed 1 Cisco 2621, IOS 12.3(6)T and Cisco 1720, IOS 12.3(7)T. The routers were connected via 2Mbps serial interface with frame relay encapsulation, the bandwidth was limited in most of the tests. The method used for generating traffic was synthetic (probes and ping). Hardware, software and the set-up of the test bed 2 Cisco 2621, IOS 12.3(6)T and Cisco 1720, IOS 12.3(7)T. The routers were connected via 2Mbps serial interface with frame relay encapsulation, the bandwidth was limited in most of the tests. In addition to synthetic traffic, Cisco Call Manager Express v 3.0 and two Cisco 7960 IP phones were used. Test methodology Synthetic voice call set-up:

� Send the request to RTP/UDP port number 16000. � Send 172 byte packets (160 payload + 12 byte RTP header size) + 32 bytes (IP 20

bytes + UDP 8 bytes + 4 bytes frame relay encapsulation header). � Send 1000 packets for each frequency cycle. � Send every packet 20 milliseconds apart (this results in a frequency cycle of 20

seconds). Sleep 0 seconds before starting the next frequency cycle. � These parameters result in a constant stream of 64 kbps.

The following configuration was used for synthetic voice call set-up:

rtr 1 type jitter dest-ipaadr [address] dest-port [port] codec [g711a, g711u, g.729] ! the number of packets [default n=1000] codec numpackets [n] ! the size of each payload [default s=172] codec-size [s] ! inter-packet time interval [default t=20ms] codec-interval [t] ! the operational frequency [default f=60] frequency [f] rtr schedule 1 life forever start-time now For creating delays:

99

Limited bandwidth on the serial link was used and additional traffic on the link was created for variable delays (the rtr operation was initiated for creating a constant traffic and ping command with different packet sizes (32 – 5000 bytes) was initiated to result in variable delays). For creating packet loss: Limited bandwidth on the serial link was used, additional traffic on the link was created (ping command with different packet sizes (32 – 5000 bytes)), and limited packet length queue in the router was implemented. The following configuration was used to force packets to drop in the queue, without delaying the voice packets: policy-map test_loss class class_default bandwidth [bandwidth-in-kbps] queue-limit [number-of-packets] interface [serialint] max-reserved-bandwidth 100 service-policy output test_loss tx-ring-limit 1 The number of the probe packets varied between 10, 100 and 1000 packets during all the tests, but as no significant change in MOS scores was observed, the different results are not displayed here. An example of the set-up which results in high jitter values on the IP telephones: Set-up of test bed used: 2. Bandwidth limitation: 96 kbit/s UDP jitter operation: rtr 1 type jitter dest-ipaadr [address] dest-port 14385 num-packets 30 interval 5 frequency 5 rtr schedule 1 life forever start-time now In parallel with the rtr operation, a phone call with the IP telephones was established. Maximum jitter as seen on the Cisco 7960 display: 879 ms, the average jitter was floating between 200 and 400 ms. As the documentation concerning the calculation of the impairment factor ICPIF and mapping it to the MOS-CQE was not precise (compare figure “Test 1” below with Table 9), the first tests show the ICPIF and MOS-CQE values according to the delay and packet loss.

100

Test 1. The relationship between MOS and ICPIF During the first test random impairments were created to acquire different ICPIF scores and to find the relationship between the MOS-CQE and ICPIF values. Set-up of test bed used: 1.

ICPIF and MOS (Cisco)

5,0

4,66

4,33

4,03,9

3,83,7

3,63,5

3,43,3

3,23,1

3,02,9

2,82,7

2,62,5

2,42,3

2,22,1

21,9

1,81,7

1,61,5

1,41,3

1,21,1

1,0 1,01,01,31,51,82,02,32,52,83,03,33,53,84,04,34,54,85,0

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

ICPIF impairment

MO

S

Figure 4. Test 1 Main conclusion of the test: actual ICPIF-to-MOS mapping uses finer granularity than Cisco documentation suggests.

101

Test 2. The impact of delay on MOS for G.711A. To be compared with table 6, figure 1. Set-up of test bed used: 1. Bandwidth: 148 kbps Codec: ITU-T G.711A Impairment: delay

G.711 ICPIF MOS

11,21,41,61,8

22,22,42,62,8

33,23,43,63,8

44,24,44,64,8

5

0 20 40 60 80 100

120

140

160

180

200

220

240

260

280

300

320

340

360

380

400

420

440

460

480

500

520

540

One-way delay (ms)

MO

S

Figure 5. Test 2 Note 1. The exact results of the measurements, including RTT, calculated one-way delay, ICPIF, MOS and packet loss values can be found in the excel spreadsheet document ICPIF tests on sheet “G.711 MOS_delay”. Note 2. No synchronisation of the clocks was used during this test, the one-way delay is calculated from the RTT values as half of the RTT, assuming that the channel is symmetrical.

102

Test 3. The impact of delay on MOS for G.729. To be compared with table 6, table 7. Set-up of test bed used: 1. Bandwidth: 148 kbps Codec: ITU-T G.729 Impairment: delay

G.729 ICPIF MOS

1,9

3,2 3,13,3

2,4

2,7

3,3

11,21,41,61,8

22,22,42,62,8

33,23,43,63,8

44,24,44,64,8

5

0 10 20 30 40 50 60 70 80 90 100

110

120

130

140

150

160

170

180

190

200

210

220

230

240

250

260

270

280

290

300

One-way delay (ms)

MO

S

Figure 6. Test 3 Note 1. The exact results of the measurements, including RTT, calculated one-way delay, ICPIF, MOS and packet loss values can be found in the excel spreadsheet document ICPIF tests on sheet “G.729 MOS_delay”. Note 2. No synchronisation of the clocks was used during this test, the one-way delay is calculated from the RTT values as half of the RTT, assuming that the channel is symmetrical. Note 3. ICPIF calculation includes a codec-dependent equipment impairment factor, this test shows that under ideal conditions (no delay, no packet loss) the factor is such that for codec G.729 the maximum MOS is 3.3 (ICPIF=10). Please read the Observation no 4.

103

Test 4. Impact of packet loss on MOS for G.711 To be compared with table 7, figure 2. Set-up of test bed used: 1. Bandwidth: 192 kbps Codec: ITU-T G.711A Impairment: packet loss Queuing delay: 2 to 5 packets

G.711 ICPIF MOS

2,5

1,31,31,0

3,5

5,0

1,1

1,01,21,41,61,82,02,22,42,62,83,03,23,43,63,84,04,24,44,64,85,0

00,

5 11,

5 22,

5 33,

5 44,

5 55,

5 66,

5 77,

5 88,

5 99,

5 1010

,5 1111

,5 1212

,5 1313

,5 14

Packet loss %

MO

S

Figure 7. Test 4 Note 1. The exact results of the measurements, including RTT, calculated one-way delay, ICPIF, MOS and packet loss values can be found in the excel spreadsheet document ICPIF tests on sheet “G.711 MOS_loss”. Note 2. No synchronisation of the clocks was used during this test, the one-way delay is calculated from the RTT values as half of the RTT, assuming that the channel is symmetrical. Note 3. Comparing the results with test no 2, it is clear that the only impairment in test 4 was the packet loss. The highest one-way delay in this test was ca 126 ms, adding nothing to the ISCPIF impairment value.

104

Test 5. Impact of packet loss on MOS for G.729 To be compared with table 7, figure 3. Set-up of test bed used: 1. Bandwidth: 192 kbps Codec: ITU-T G.729 Impairment: packet loss Queuing delay: 2 to 5 packets

G.729 ICPIF MOS

1,01,0

1,8

3,3

2,8

2,3

3,3

1

1,2

1,4

1,6

1,8

2

2,2

2,4

2,6

2,8

3

3,2

3,4

3,6

3,8

4

4,2

4,4

4,6

4,8

5

00,

20,

40,

60,

8 11,

21,

41,

61,

8 22,

22,

42,

62,

8 33,

23,

43,

63,

8 44,

24,

44,

64,

8 55,

25,

45,

65,

8 66,

26,

46,

66,

8 77,

2Packet loss %

MO

S

Figure 8. Test 5 Note 1. The exact results of the measurements, including RTT, calculated one-way delay, ICPIF, MOS and packet loss values can be found in the excel spreadsheet document ICPIF tests on sheet “G.729 MOS_loss”. Note 2. No synchronisation of the clocks was used during this test, the one-way delay is calculated from the RTT values as half of the RTT, assuming that the channel is symmetrical. Note 3. Comparing the results with test no 3, it is clear that the only impairment in test 4 was the packet loss. The highest one-way delay in this test was ca 40 ms, adding nothing to the ISCPIF impairment value.

105

PART III The most important observations TEST SET-UP 1 Observation 1 After changing a parameter in the router’s configuration (packet queue length, bandwidth etc), it is strongly recommended to restart the RTR-s (“type jitter codec” or “type jitter” operation number): rtr restart 1 rtr restart 2 … etc. The router does not always display correct results in voice scores (ICPIF and MOS) after some parameters have been changed, although the packet loss, delay and jitter values are correct. Restart the operation to ensure correct results. Observation 2 The mapping between the ICPIF and MOS values in Cisco documentation (e.g. “Service Assurance Agent (SAA) VoIP UDP Operation”) is not correct. The real results are different from the documented values. Attention! Compare: “Correspondence of ICPIF Values to MOS Values” and Figure “Test 1”. Observation 3 When calculating the ICPIF and MOS values, the Cisco SAA type jitter codec operation does not take into account all the impairments that occur on the service level (e.g. it calculates the impairments introduced by the G.729 codec, but has no possibility to consider the delays due to a static jitter buffer). Although the jitter buffer may be dynamic and may not have a significant impact on the delay, it may not be the case with all VoIP systems that may have a constant jitter buffer of 40 ms. (For example the static jitter buffer of 40ms in a telephony adds a delay of 40ms, although there might not be any jitter at all.) Conclusion: although the MOS score may be very high in the SAA tests, it may not be so high for the end users in the implemented system because of the additional impairments introduced on the application level (e.g. delays due to a static jitter buffer). All additional impairments have to be added separately. ICPIF full formula (section “The Calculated

106

Planning Impairment factor (ICPIF)”) and corresponding ICPIF impairment values should be used to calculate the final ICPIF impairments. Observation 4 The maximum possible quality score for the G.729 codec seems to be unreasonably low and the quality score for the G.711 is above expected value. Although the MOS scores from different measurement methods can not be directly compared they still can be used for relative comparisons. Comparing the theoretical maximum results for G.711A and G.729 according to the E-model and Cisco SAA codec operations:

Codec/score

Theoretical max MOS score (E-model, ITU-T G.107)

Max MOS score with Cisco SAA, based on ICPIF

G.711A 4.40 5.0 G.729 4.07 3.3

Table 10. Maximum MOS scores according to E-model and Cisco SAA According to the E-model, the maximum quality of the codec G.729 is 92,5% of G.711A, but according to the Cisco SAA it is only 66% of G.711A. Conclusion: further investigation needed to clarify the theoretical maximum score of the G.729 codec. Although according to the newest ITU-T G.113 recommendation the E-model (ITU-T recommendation G.107) impairment factor calculations should be used instead of the ICPIF method. Assuming the propriety of the newer standard we can claim that the MOS score reported by the SAA probes is higher than the theoretical maximum score for G.711 and the maximum score for G.729 is too low. So the scores should be used for relative assessment only – i.e. as a deviation from the maximum possible score.

107

TEST SET-UP 2 The Cisco telephone displays network statistics for an active call: Press the i button twice quickly during an active call to view network statistics about the active call.

� RxType—Type of voice stream received (RTP streaming audio) (G.729, G.711 u-law, G.711 A-law,).

� RxSize—Size of voice packets (ms) in the receiving voice stream (RTP streaming audio). � RxCnt—Number of RTP voice packets received since voice stream was opened. � TxType—Type of voice stream transmitted (RTP streaming audio) (G.729, G.711 u-law, G.711 A-

law). � TxSize—Size of voice packets (ms) in the transmitting voice stream. � TxCnt—Number of RTP voice packets transmitted since voice stream was opened. � Avg Jtr—Estimated average RTP packet jitter (dynamic delay a packet encounters when going

through the network) observed since the receiving voice stream was opened. � Max Jtr—Maximum jitter observed since the receiving voice stream was opened. � RxDisc—Number of RTP packets in the receiving voice stream that have been discarded (bad

packets, too late, and so on). � RxLost—Missing RTP packets (lost in transit).

Observation 5 The jitter buffer of the Cisco telephones is - according to the Cisco documentation - adaptive (i.e. dynamic) and up to 1 second in length. According to the observations the jitter buffer seems to be dynamic (correspondence in the results of the live statistics in the IP telephone: average jitter and packets discarded due to the jitter buffer). What is not known is the adaption time of the dynamic jitter buffer. Conclusion: further investigation needed to discover the adaption time of the dynamic jitter buffer in Cisco IP telephones. Observation 6 When interpreting the measurement results, it is important to know that Cisco IP telephones calculate separately the packets lost due to the network (RxLost) and packets discarded in the phone due to the jitter buffer (RxDisc), nevertheless, the Cisco SAA type jitter codec operation displays separately the number of packets that arrived late (PacketLateArrival), but includes this number under the “inbound” lost packets count (LostDS). The timeout value for the PacketLateArrival can be configured, the default value is 5000 ms. Conclusion: when interpreting the results, be aware of the differences in the packet loss counts of the IP telephones and the synthetic traffic.

108

References 1. ITU-T recommendation G.113, www.itu.int 2. ITU-T recommendation G.107, www.itu.int 3. Cisco Service Assurance Agent (SAA) VoIP UDP Operation http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00801d3a94.html 4. Cisco, Measuring Delay, Jitter, and Packet Loss with Cisco IOS SAA and RTTMON http://www.cisco.com/warp/public/126/saa.html 5. Cisco CallManager Express 3.0 System Administrator’s Guide http://www.cisco.com/en/US/products/sw/iosswrel/ps5012/products_feature_guide_book09186a00801812e4.html

109

LISA C 3COM SUPERSTACK 3 SWITCH 4400 - VAIKIMISI MÄÄRATUD SEADISTU-SED

Tabel C.1. Vaikimisi määratud liikluse klassifitseerijad (3Com Superstack 3 Switch 4400) [7]

Tabel C.2. Eel-defineeritud teenuse tasemed (3Com Superstack 3 Switch 4400) [7]