Primjena simulacije u projektovanju telekomunikacijskih mreža i

osiguranju mrežnih QoS parametara u IP mreži

Appliance of simulations in design of telecommunication networks and

provision of QoS parameters in IP network

M.Sc. Alem Čolaković, dipl.ing. saob. i kom.

alem.colakovic@gmail.com

Sažetak
Povjerenje korisnika, koje je preduslov za uspjeh na telekomunikacijskom tržištu, moguće je
ostvariti samo kroz kvalitetne usluge i poslovne procese. Kvalitet usluge zavisi od velikog
broja faktora, meĎu kojima su performanse korisničkih ureĎaja, performanse mreže,
mogućnosti uslužno specifičnih aplikacija itd. U svrhu osiguranja kvaliteta usluge poseban
značaj imaju mehanizami za osiguranje mrežnih QoS (Quality of Service) parametara. Cilj
mreže i usluga treba da bude postizanje željene korisničke percepcije QoE (Quality of
Experience), dok je QoS glavni elemenat za postizanje tog cilja. Za postizanje željenog nivoa
usluge i njegovu provjeru koriste se odreĎene metode, a posebno mjesto zauzima simulacijska
metoda. Ovaj rad ima za cilj da ukaže na značaj ove metode u analiziranju
telekomunikacijskog saobraćaja kroz korištenje mrežnog simulatora NS-2.

Ključne riječi: Simulacije, IP, QoS, QoE, DiffServ, IntServ, MPLS, Saobraćajni inžinjering

Abstract
Users trust, which is a prerequisite for success in the telecommunications market, is possible
to achive only through quality of services and business processes. Quality of service depends
on many factors, including the performance of user devices, network performance, service
capabilities of specific applications, etc. In order to ensure quality of services, very important
role have mechanisms for ensuring network QoS (Quality of Service) parameters. The aim of
the network and services should be achieving the desired customer perception QoE (Quality
of Experience), while the QoS main element for achieving this aim. To achieve the desired
level of service and its verification using certain methods, a special place take simulation
methods. This paper aims to demonstrate the importance of this method in analyzing
telecommunication traffic through the use of the network simulator NS-2.

Key words: Simulation, IP, QoS, QoE, DiffServ, IntServ, MPLS, Traffic Engineering

1
 1. Uvod
Jedan od ključnih problema mreža baziranih na komutaciji paketa i IP (Internet Protocol)
protokolu jeste osiguranje kvaliteta usluga. Internet je dobro osmišljen za prijenos podataka,
ali ne i za usluge realnog vremena poput prijenosa glasa ili videa. Da bi se prevazišao ovaj
problem razvijeni su razni mehanizmi u svrhu osiguranja QoS parametara. IntServ, DiffServ i
MPLS predstavljaju različite implementacije mehanizama za osiguranje QoS-a u mrežama za
prenos podataka, a danas je najzastupljenija arhitektura diferenciranih servisa. Veliku ulogu
ima i saobraćajni inžinjering koji korištenjem analize i modeliranja saobraćaja omogućava
efikasnije iskorištenje mrežnih resursa. Ubrzani razvoj paketskih mreža i rast podatkovnih
usluga prati i uvoĎenje koncepta kvaliteta usluga. Ova tema zahtjeva diskusiju o mnogim
protokolima, teoriji čekanja, signalizaciji, propusnosti i upravljanju resursima, ugovorima o
nivou usluge tzv. SLA (Service Level Agreement), održavanju, itd. Korisnici su sve zahtjevniji
u pogledu cijene i kvaliteta, a da bi se udovoljilo tim zahtjevima neophodno je razvijati
odgovarajuće mehanizme. Broj korisnika telekomunikacijskih usluga raste kao i broj različitih
usluga, te se mora voditi računa o povećanju kapaciteta. Ovo su dva suprostavljena zahtjeva
jer povećanjem broja korisnika teže je pronaći dodatne kapacitete, a postavlja se pitanje kako
poboljšati postojeće performanse uz navedenu poteškoću.

2. Osiguranje ključnih QoS parametara u IP mreži

QoS ima značenje kvaliteta usluga i danas je jedan od najčešće korištenih pojmova u oblasti
telekomunikacija. SLA ugovor obavezuje operatora na osiguranje odreĎenog nivoa kvaliteta
pruženih usluga. Ovim ugovorom se kreira jasna veza izmeĎu korisnika i provajdera
postavljajući granične vrijednosti kvaliteta, uslove korištenja usluge i sl. Na ovaj način
definiše se veza izmeĎu korisničkih i mrežnih zahtjeva čime se stvara mogućnost da mreža
ponudi različite nivoe usluge i poveže ih sa različitim cjenovnim modelima. SLA uključuje i
ne-tehnička pitanja kao i vrednovanje i mogućnosti mreže/ureĎaja. Centralno pitanje jeste koji
su to ključni tehnički parametri koji će obezbijediti zadovoljavajući kvalitet različitih usluga
percipiran od strane korisnika. Odgovor na ovo pitanje pruža preporuka G.1010 prema kojoj
se QoS se definiše na osnovu skupa parametara koji se mogu objektivno izmjeriti. U vezi s
tim, SLS prema [RFC3206] predstavlja ''skup parametara i njihovih vrijednosti koji zajedno
definišu uslugu ponuđenu saobraćaju''. Da bi se postigla željena percepcija korisnika (bez
obzira na apstraktne zahtjeve korisnika) neophodno je postići odgovarajuće vrijednosti QoS
parametara. U mrežne ili uslužno-specifične QoS parametre spadaju: opseg, kašnjenje,

2
varijacija kašnjenja (jitter) i gubitak informacije (segmenta poruke). Pojedini parametri su
različito značajni za različite vrste usluga, pa je u ITU (International Telecommunication
Union) preporuci G1010 dat prikaz zahtjeva pojedinih vrsta saobraćaja (npr. audio, video i sl.)
za pomenutim QoS parametarima.
U cilju garantovanja odreĎenog nivoa usluge kroz osiguranje jednog ili više QoS parametara
razvijeni su različiti mehanizmi i arhitekture za njihovu implementaciju. Da bi se mogao
garantovati odreĎeni QoS u mreži baziranoj na IP protokolu, u jezgrenoj mreži se moraju
koristiti IP QoS mehanizmi. U tu svrhu poseban značaj imaju DiffServ (Differentiated
Services) i IntServ (Integrated Services) arhitekture razvijene od strane IETF (Internet
Engeneering Task Force) organizacije kao standardizirane implementacije mehanizama za
osiguravanje QoS-a u mrežama baziranim na IP protokolu. Mehanizam integriranih usluga
omogućava uspostavljanje striktnog kvaliteta usluge s kraja na kraj i garantovani propusni
opseg. Primjena IntServ arhitekture dodatno opterećuje mrežu saobraćajem korištenjem
RSVP protokola, a uz to postoji i problem skalabilnosti i zbog toga se rijeĎe koriste.
Mehanizam diferenciranih usluga je dosta fleksibilniji, meĎutim nije uvijek dovoljan da bi se
osigurao apsolutni kvalitet usluge s kraja na kraj. MeĎutim, DiffServ je podržan od strane
MPLS tehnologije, tako da je omogućen saobraćajni inžinjerning. Na taj način se ostvaruje
željeni kvalitet usluge sa kraja na kraj (end-to-end).

3. Simulacijska metoda analize saobraćaja

Upravljanje kvalitetom usluga obuhvata planiranje mreže, osiguranje QoS-a, QoS i QoE
monitoring i optimizaciju. Kroz ovo upravljanje neophodno je primjenjivati različite metode
za modeliranje mreža i analizu saobraćaja u mreži. Osnovni faktori kod analize saobraćaja su:
saobraćajno opterećenje, nivo usluge, tip saobraćaja, način uzimanja uzoraka za analizu i
predpostavljeni nivo greški. Svi pristupi proučavanja topologija, karakteristika saobraćaja ili
interakcija meĎu protokolima se mogu svesti na jednu od sljedeće tri grupe (ili pristupa):
matematsko modeliranje, mjerenje na realnim implementacijama, simulacija i emulacija. Ovaj
rad se zadržava u okvirima primjene simulacijske metode dok je u praksi najbolje primjeniti
više različitih metoda da bi se mogli usporediti dobijeni rezultati.
Simulacijske metode su postale nezaobilazne u planiranju mreža i analizi saobraćaja zbog
prednosti koje se ogledaju u mogućnosti obrade velike količine podataka uz promjenu ulaznih
parametara bez troškova. TakoĎer, ove metode omogućavaju provjeru stanja mreže u bilo
kojoj tački kao i da se uraĎeni simulacijski model koristi i kod drugih sličnih problema (sa ili
bez prilagoĎavanja). Smulacijske metode daju mogućnost sistemskog razmatranja problema i

3
kada analitička rješenja nisu dostupna, a eksperiment na instaliranoj mreži je nemoguć ili
nepraktičan. Nedostatak ove metode se ogleda u zanemarivanju pojedinih realnih pojava.

3.1 Odabir simulatora

Kada se definišu karakteristike saobraćajnih zahtjeva i postave ciljevi kvaliteta, slijede brojna
mjerenja i procjene kao što su procjena budućeg saobraćajnog opterećenja, procjena budućeg
dnevnog korištenja pojedine usluge, procjena budućeg saobraćajnog opterećenja u glavnom
saobraćajnom satu itd. Za mjerenja i analizu se mogu koristiti različiti simulacijski alati.
Konvencionalne simulacije u paketski komutiranim mrežama obično podrazumjevaju
upotrebu simulatora sa diskretnim dogaĎajima koji modeliraju prolazak svakog pojedinačnog
paketa kroz mrežu. Svaki dolazak ili odlazak paketa sa mrežnog elementa predstavlja
dogaĎaj. Da bi se dobili pouzdani rezultati potreban je veliki broj simuliranih paketa, odnosno
dugo trajanje simulacije. Gotovo sva poznata okruženja mrežnih simulatora koriste metodu
simulacije sa diskretnim dogaĎajima, a takav je slučaj i sa NS-2 simulatorom.
NS2 (Network Simulator 2) predstavlja veoma raširen alat za projekte simulacija paketskih
mreža i za ispitivanje ponašanja transportnih i mrežnih protokola, AQM tehnika, bežičnih
mreža, itd. Simulator posjeduje veliki broj implementiranih protokola i dostupne
dokumentacije, a besplatan je za korištenje. Ispravnost rezultata simulacije je potvrĎena
upotrebom simulatora u velikom broju dokumenata i naučnih radova. NS-2 radi na principu
liste dogaĎaja, a ugraĎen je u Tcl (Tool Command Language) UNIX sistema. Struktura
simulatora je izvedena u programskom jeziku C++, a može se upravljati i definirati pomoću
Tcl interfejsa. Mrežna topologija se gradi upotrebom triju osnovnih elemenata: čvorišta, veze
i agenata. Čvorišta su pasivni objekti koji služe kao spremnici za agente (objekte) koji aktivno
upravljaju simulacijom. Svako čvorište ima jedinstvenu adresu koja se dodjeljuje automatski.

Analiza rezultata
Simulacija simulacije (trace)

OTcl: Tcl interpreter sa objektno-

Orijentisanom ekstenzijom

Biblioteka simulatora NS2:

Otcl skript:
– Objekti za raspoređivanje događaja
program za – Objekti mrežnih komponenata
simulaciju – Moduli za konfigurisanje mreže NAM: Prikaz
vizuelizacija rezultata
simulacije

Slika 1. Korisnički aspekt procesa simulacije pomoću NS2 simulatora

Rezultati simulacije u NS-2 se postprocesiraju pri čemu se koriste različite skripte za

procesiranje tekstualnih izlaza. Za analizu rezultata simulacije moraju se ekstraktirati
relevantni podaci iz trace datoteka i izvršiti manipulacija nad njima. Ova manipulacija se

4
može izvršiti u bilo kojem programskom jeziku, a postoje i alati prilagoĎeni ovoj namjeni.
Generisanje odgovarajućih grafičkih prikaza na bazi trace datoteke se može obavljati pomoću
nekoliko besplatno dostupnih alata, npr. Xgraph, Gnuplot, TraceGraph.
U ovom radu su korišteni awk i xgraph. Awk omogućava da se izvrše jednostavne operacije na
podatkovnim datotekama, kao što je usrednjavanje vrijednosti za neku kolonu, sumiranje ili
množenje izmeĎu različitih kolona, itd.

4. Postavke simulacije
Cilj simulacija mreža jeste prikupljanje adekvatnih informacija na osnovu kojih se može
planirati i projektovati mreža ili izvršiti optimizacija. U ovom radu je na odabranoj topologiji
mreže i predpostavljenim vrstama saobraćaja pokazan značaj implementacije nekih
mehanizama (DropTail, RED, DiffServ) za osiguranje mrežnih QoS parametara u IP mreži.
Cilj je implementirati adekvatan mehanizam koji omogućava zadovoljenje QoS parametara
(gubici, kašnjenje, jitter) za izabrani tok VoIP i jednosmjernog video saobraćaja prema ITU-T
preporuci G.1010. Dakle, za analizu rezultata korištena je ITU-T preporuka G.1010.
Zadana je topologija prikazana na slici 2, ograničenja kapaciteta i druge postavke simulacije.
Plavom bojom su označeni linkovi preko kojih ide saobraćaj za koji su analizirani rezultati
simulacije. Crvenom bojom je označeno usko grlo u mreži.

S1 S0
S2
S3
7 Mb
7M

S4
7M

7M
b
b

7M b
S5 b D1
7 Mb 7Mb
S6 7Mb

7Mb 3Mb 7Mb 7Mb

S7 7 Mb E1 Core E2 D2
7Mb 7Mb
b
S8 7M b
7M
b
b
7M

7Mb
7M

S9
D3
S10

S11
S12
S13
S14

Slika 2. Testna topologija

Razvoj različitih mehanizama za osiguranje QoS parametara ima cilj zadovoljenje potreba
real-time aplikacija. VoIP je simuliran koristeći UDP protokol sa Pareto raspodjelom, dok je
video simuliran koristeći UDP saobraćaj sa CBR - konstantnom bitskom brzinom. Pored
navedene dvije vrste saobraćaja, simuliran je i FTP saobraćaj preko TCP protokola da bi se
pokazalo kako zagušenje koje unosi ovaj saobraćaj utiče na VoIP i video saobraćaj.

5
Topologiju mreže definišu čvorovi mreže koji su meĎusobno povezani linkovima ograničenog
kapaciteta. Zbog nedostatka dovoljnog kapaciteta dolazi do teškoća u ispunjenju zahtjevanog
nivoa QoS-a. Koriste se različiti mehanizmi da bi se nadomjestio nedostatak kapaciteta (npr.
odreĎeni mehanizmi daju prioritete vrstama saobraćaja koji su osjetljiviji na gubitke).
Kapaciteti linkova su postavjeni na 7Mb, osim kapaciteta uskog grla (3Mb). Kašnjenja
linkova na rubu mreže su postavljena na 15 ms, a izmeĎu rubnih čvorova i čvora u jezgru
mreže kašnjenje je 20 ms. Veličina UDP paketa (sa zaglavljem) za prenos VoIP saobraćaja je
160 B, veličina UDP paketa (sa zaglavljem) za prenos video saobraćaja je 240 B. Veličina
TCP paketa (sa zaglavljem) za prenos podataka je 1040 B. Trajanje simulacije je 60 s.
Postavke za , . Čvorovi

(izvori saobraćaja) su:

S(i) = izvori saobraćaja koji pripadaju klasi telefonskih usluga (prema RFC4594) i
predstavljaju VoIP saobraćaj, a uspostavljaju konekciju sa odredištem D1. Ova klasa je
konfigurisana kao EF PHB u DiffServ arhitekturi.
S(j) = izvori saobraćaja koji pripadaju klasi streaminga multimedije (prema RFC4594).
Ovi izvori simuliraju prijenos videa u jednom smjeru i uspostavljaju konekciju sa
odredištem D2. Klasa je konfigurisana kao AF PHB.
S(k) = izvori podatkovnog saobraćaja koji su simulirani preko TCP izvora preko kojih se
prenosi FTP saobraćaj do odredišta D3.

Prikazana topologija mreže je analizirana posmatrajući različite kapacitete bafera uz

implementaciju mehanizama DropTail, Red i DiffServ. Analiza rezultata je zasnovana na
praćenju osnovnih QoS parametara za dva toka saobraćaja: VoIP saobraćaj (izvor S2, tok 3) i
video saobraćaj (izvor S6, tok 7) i rezultati prikazani u tabelama 2, 3, 4 se odnose na
pomenute tokove saobraćaja.
Tabela 1. Ciljevi i ograničenja QoS parametara prema G.1010.
Vrsta saobraćaja VoIP Video
Gubici <3% PLR <1% PLR
Kašnjenje <150 ms (poželjno) <10 s
Jitter <1 ms -

4.1 Simulacija DropTail mehanizma

DropTail mehanizam se koristi za upravljanje baferima. Scenariji simulacije obuhvataju
različite veličine bafera: 60, 100 i 140. Postavke simulacije za DropTail su:

6
 Obzirom na veličinu TCP paketa (1040 B) i vrijednost proizvoda , u

mreži se u jednom trenutku može nalaziti (TCP)

Inicijalni prozor TCP konekcije koji oglašavaju odredišni čvorovi awnd postavljen je na
120 segmenata, tako da je optimalna veličina bafera na uskom grlu:

Tabela 2. Rezultati simulacije DropTail mehanizma

Vrsta saobraćaja VoIP (tok_3)
Veličina bafera 60 100 140
Br.poslanih/Gubici 1031/33 (3,2%) 1031/29 (2,8%) 1031/30 (2,9%)
Kašnjenje [ms] 133 177 216
Jitter [ms] 0,09 0,1 0,1
Protok [kbps] 60 60 60
Vrsta saobraćaja Video (tok_7)
Veličina bafera 60 100 140
Br.poslanih/Gubici 4578/41 (0,9%) 4578/48 (1,0%) 4578/46 (1,0%)
Kašnjenje [ms] 146 197 245
Jitter [ms] 0,02 0,04 0,04
Protok [kbps] 400 400 399
Vrsta saobraćaja Podaci (tok_11)
Veličina bafera 60 100 140
Br.poslanih/Gubici 1342/51 (3,8%) 1236/42 (3,4%) 1256/37 (2,95%)
Kašnjenje [ms] 113 141 165
Jitter [ms] 7 11 12
Protok [kbps] 406 507 601

VoIP saobraćaj u prvom scenariju analize (veličina bafera je postavljena na 60) koristeći
DropTail na uskom grlu ima nezadovoljavajuću vrijednost QoS parametra u pogledu gubitaka
paketa jer prelazi ciljnu vrijednost od 3%, dok za druga dva scenarija (veličine bafera 100 i
140) ovaj parametar je zadovoljen. Korištenjem grafičkih prikaza vremenskog protoka može
se uočiti da nema gubitaka u prvih 10 sekundi simulacije, jer je do desete sekunde u mreži
prisutan samo VoIP i video saobraćaj. Nakon desete sekunde u mrežu se emituje i FTP
saobraćaj koji unosi zagušenje zbog nedovoljnog kapaciteta linkova. Povećanjem veličine
bafera smanjeni su gubici, ali je povećano srednje kašnjenje, pa za druga dva scenarija nije
zadovoljen parametar kašnjenja. Varijacija kašnjenja je za sve scenarije na zadovoljavajućoj
vrijednosti. Primjetno je da je kašnjenje povećano sa povećanjem veličine bafera jer se paketi
više zadržavaju u baferima i zbog toga prosječno kašnjenje zadovoljava ciljanu vrijednost
samo u prvom scenariju simulacije.

7
Komentar: Na sličan način se može izvršiti analiza za video saobraćaj. Prema postavljenim
ciljnim vrijednostima QoS parametara može se zaključiti da je implementacija DropTail
mehanizma, sa postavljenim ograničenjima, nezadovoljavajuće rješenje.

4.2 Simulacija RED mehanizma

Na uskom grlu mreže je implementiran RED mehanizam, a na ostalim dijelovima DropTail.
Postavke simulacije su iste kao i kod simulacije DropTail mehanizma, uz dodatne postavke
RED mehanizma. Koeficijent usrednjavanja podešen je na vrijednost , a

vjerovatnoća odbacivanja postavljena je na vrijednost maxp = 0.5. Pragovi RED područja su

postavljeni uzimajući u obzir dužine bafera i obzirom na veličinu TCP paketa vrijedi:

; (za QL = 60)

; (za QL = 100)

; (za QL = 140)

Tabela 3. Rezultati simulacije RED mehanizma na uskom grlu

Vrsta saobraćaja VoIP (tok_3)
Veličina bafera 60 100 140
Gubici 1031/42 (4,2%) 907/33 (3,6%) 1051/38 (3,6%)
Kašnjenje 111 135 157
Jitter 0,04 0,08 0,02
Protok 62 57 59
Vrsta saobraćaja Video Video (tok_7)
Veličina bafera 60 100 140
Gubici 4578/163 (3,6%) 4578/186 (4,0%) 4578/170 (3,7%)
Kašnjenje 118 145 168
Jitter 0,03 0,03 0,03
Protok 392 390 391
Vrsta saobraćaja Podaci (tok_11)
Veličina bafera 60 100 140
Br.poslanih/Gubici 1348/54 (4,0%) 1514/49 (3,2%) 1171/53 (4,5%)
Kašnjenje [ms] 98 114 129
Jitter [ms] 6 6 10
Protok [kbps] 428 520 445

Komentar: Analiza za pojedine vrste saobraćaja se može izvršiti na isti način kao što je to
urađeno za DropTail mehanizam. Prema postavljenim ciljnim vrijednostima QoS parametara
može se zaključiti da je implementacija RED mehanizma nezadovoljavajuće rješenje.

8
4.3 Simulacija DiffServ implementacije
Na uskom grlu je implementiran DiffServ model kvaliteta, dok je na ostalim dijelovima
korišten DropTail. Postavke simulacije su iste kao i u predhodnim slučajevima, uz dodatne
postavke DiffServ-a. Diffserv osigurava QoS tako što dijeli saobraćaj u različite
kategorije/klase i što markira svaki paket koji ukazuje o kojoj se kategoriji radi. Diffserv
modul u ns-2 podržava četiri klase saobraćaja, pri čemu svaka od klasa ima tri procedure
odbacivanja paketa. Paketi u jednoj klasi saobraćaja se pohranjuju u odgovarajući fizički RED
- red čekanja, pri čemu on sadrži do tri virtualna reda čekanja (jedan za svaki stepen
odbacivanja paketa). Različiti parametri RED se mogu konfigurisati za virtuelne redove
čekanja, čime se paketi iz jednog viruelnog reda mogu odbacivati češće nego paketi iz
drugog. Diffserv modul u ns-2 ima tri glavne komponente: Policy - pravila su specificirana od
strane mrežnog administratora o nivou usluge, Edge routers - rubni ruteri markiraju pakete sa
CP prema specificiranom pravilu, Core routers - nadgledaju CP paketa i vrši posljeĎivanje.
Veoma važno je napomenuti da se link kod DiffServ-a postavlja kao simplex (u ovom slučaju
dva simplex linka: jedan od Edge rutera prema Core ruteru i jedan u suprotnom smjeru) zbog
činjenice da saobraćaj iz različitih smjerova ima različite karakteristike.
Postavljena su 3 fizička reda čekanja od kojih dva imaju po jednu procedura odbacivanja
paketa (jedan virtuelni red čekanja), dok su za jedan fizički red postavljene dvije procedure
odbacivanja paketa. Postoji mogućnost izbora nekoliko rasporeĎivača za fizičke redove
čekanja: RR (Round Robin), WRR (Weighted Round Robin), PRI (Priority), WIRR (Weighted
Interleaved Round Robin) i sl. Vrsta rasporeĎivača izabrana za simulacije u ovom radu je PRI
koji označava striktne prioritete tako da je VoIP saobraćaju dat najveći prioritet, zatim video
saobraćaju za koje su postavljenje ciljne vrijednosti. Postoje mogućnost odabira jednog od tri
virtualna RED bafera tzv. MRED (Multi RED) u svakom fizičkom redu koji daju mogućnost
različitog ponašanja i različitih odnosa kada su u pitanju redovi čekanja. RIO-D (RIO De-
coupled) je izabran u simulaciji, a vjerovatnoća odbacivanja svakog paketa bazirana je na
veličini vlastitog virtuelnog reda čekanja. Moguće politike koje se pridružuju odreĎenim
konekcijama su: TSW2CM (TSW2CMPolicer), TSW3CM (TSW3CMPolicer), Token Bucket
(TokenBucketPolicer), srTCMPolicer (Single Rate Three Color Marker), trTCMPolicer (Two
Rate Three Color Marker). Pridruživanje parametara politike (npr. brzine) je izvršeno
koristeći preporuke RFC4594. Za tokove od izvora S(i) do odredišta D1 je izabran „Token
Bucket“ koji koristi CIR (Committed Information Rate) - izvršnu brzinu i dvije procedure
odbacivanja i CBS (Committed Burst Size) - izvršnu veličinu bursta i dvije procedure
odbacivanja. Na isti način su postavljeni parametri politike od izvora S(j) do odredišta D2,

9
dok je za konekciju od S(k) prema D3 korištena slična procedura ali sa je postavljen
trTCMPolicer (Two Rate Three Color Marker) koji koristi CIR, CBS, EBS i PBS (Peak Burst
Size) - za izbor tri procedure odbacivanja.

Tabela 4. Rezultati simulacije DiffServ mehanizma na uskom grlu

Vrsta saobraćaja VoIP (tok_3)
Veličina bafera 60 100 140
Br.poslanih/Gubici 832/0 (0,0%) 849/0 (0,0%) 1031/0 (0,0%)
Kašnjenje 72 84 72
Jitter 0,00 0,00 0,00
Protok 62 60 63
Vrsta saobraćaja Video Video (tok_7)
Veličina bafera 60 100 140
Br.poslanih/Gubici 4578/0 (0,0%) 4578/0 (0,0%) 4578/0 (0,0%)
Kašnjenje 76 88 76
Jitter 0,00 0,00 0,00
Protok 396 396 395
Vrsta saobraćaja Podaci Video (tok_11)
Veličina bafera 60 100 140
Br.poslanih/Gubici 1143/50 (4,4%) 1086/29 (2,7%) 1202/28 (2,3%)
Kašnjenje [ms] 188 243 234
Jitter [ms] 17 14 22
Protok [kbps] 509 473 643

Komentar: Prema postavljenim ciljanim vrijednostima QoS parametara može se zaključiti da

je implementacija DiffServ mehanizma u simuliranoj mreži, sa postavljenim ograničenjima,
zadovoljavajuće rješenje koje ispunjava postavljene ciljne vrijednosti QoS parametara.

Usporedna analiza postignutih rezultata simuliranih mehanizama

Za usporednu analizu se mogu koristiti rezultati koji su prikazani u tabelama i grafički prikazi.
U nastavku analize rezultata prvi scenario je korišten kao referentni kod usporedbe rezultata
za različite mehanizme. Na osnovu predhodnih analiza može se zaključiti da jedino
implementacija DiffServ-a, u bilo kojem scenariju simulacije, zadovoljava ciljne vrijednosti
QoS parametara. Sa slike 5 se vidi da VoIP paketi bilježe gubitke kod DropTail (crveni
grafikon) i RED mehanizma (zeleni grafikon), dok nema gubitaka kod DiffServ mehanizma
(plavi grfikon). Razlog je efikasna prioritetizacija saobraćaja. Na sličan način se može
koristiti i grafikoni koji pokazuju odnose gubitaka video i podatkovnih paketa kod
implementacije testiranih mehanizama.

10
Slika 3. Usporedba gubitaka VoIP paketa (dt=DropTail, red=RED i ds=DiffServ -scenario 1)

Na slici 4 su predstavljeni grafikoni koji pokazuju odnose kašnjenja kod implementacije

testiranih mehanizama za VoIP saobraćaj. Sa slike je jasno uočljivo da je kašnjenje kod
implementacije DiffServ mehanizma znatno manje nego kod druga dva mehanizma zbog
efikasne klasifikacije (prioritetizacije) saobraćaja.

Slika 4. Usporedba kašnjenja VoIP paketa (dt=DropTail, red=RED i ds=DiffServ -scenario 1)

Slični grafički prikazi se mogu koristiti kod drugih analiza (npr. usporedbna različitih
scenarija simulacije, analiza jittera za različite mehanizme i sl.). Analizom rezultata primjetno
je znatno povećanje varijacije u kašnjenju kod implementacije RED mehanizma i zbog toga se
RED kao AQM ne preporučuje u preporuci RFC4594 za EF PHB kojoj pripada VoIP
saobraćaj.
Obzirom da je vrijeme simulacije kratko (60 sekundi), predpostavka je da bi pri dužim
periodima posmatranja prosječna varijacija kašnjenja bila znatno manja kod RED mehanizma
u odnosu na DropTail.

11
 5. Zaključak
Telekomunikacije imaju veoma važnu ulogu u današnjem načinu poslovanja i života. Iz tog
razloga su definisani parametri koje je neophodno osigurati da bi se zadovoljili zahtjevi
korisnika. Performanse sistema treba da omoguće ispunjenje postavljenih ciljeva u pogledu
karakteristika saobraćaja. Mrežni QoS parametri predstavljaju mjerljive veličine koje je
potrebno kontinuirano mjeriti da bi se pratilo ispunjenje odreĎenih vrijednosti parametara koje
su definisane preporukama. Razni mehanizmi su razvijeni u svrhu osiguranja mrežnih QoS
parametara u IP mreži. Procesi u telekomunikacijskim mrežama su sve složeniji i mreže se
svakodnevno susreću sa sve većim saobraćajnim opterećenjem. Zbog toga je potrebno
detaljno planiranje i proračuni, kao i kontinuiran monitoring i testiranje radi provjerie nivoa
usluge. U tu svrhu se koriste razne metode, a poseban značaj ima simulacijska metoda.
Prednosti implementacije DiffServa su pokazane rezultatima simulacija koje su izvršene u
radu koristeći NS-2 simulator. Razultati simulacije sa postavljnim željenim vrijednostima za
QoS parametre gubitaka, kašnjenja i varijacije kašnjenja su pokazali da je jedino
implementacija DiffServ-a omogućilo postizanje željenih vrijednosti. DropTail i RED nisu
rezultirali željenim rezultatima, pa se nameće zaključak da je na simuliranom primjeru jedino
moguće rješenje implementacija DiffServ-a. Na sličan način se može izvršiti i analiza
saobraćaja koristeći i druge mehanizme.

Indeks pojmova i skraćenica

AQM (Active Queue Management)
CBQ (Class Based Queuing)
DiffServ (Differentiated Services)
DSCP (Differenciated Services Code Point)
EF (Expedited Forwarding)
IETF (Internet Engeneering Task Force)
IntServ (Integrated Services)
IP (Internet Protocol)
ITU (International Telecommunication Union)
MPLS (Multiprotocol Label Switching)
MRED (Multi RED)
NAM (Network Animator)
PHB (Per Hop Behavior)
QoE (Quality of Experience)

12
QoS-a (Quality of Service)
RED (Random Early Detection)
RFC (Request For Comment)
RIO (RED with In and Out bit)
RIO-C (Rio Coupled)
RIO-D (RIO De-coupled)
RSVP (Resource ReSerVation Protocol)
RTO (Retransmission Timeout)
RTT (Round Trip Time)
SLA (Service Level Agreement)
SLS (Service Level Specification)
TCP (Transmission Control Protocol).
TE (Traffic Engineering)
ToS (Terms of Service)
UDP( User Datagram Protocol)
VoIP (Voice over Internet Protocol)
WF2Q (Worst-Case Fair WFQ),
WFQ (Weighted Fair Queuing)
WRED (Weighted RED)
WRR (Weighted Round Robin)

Literatura

[1] R. Braden (ISI), D. Clark (MIT), and S. Shenker (Xerox PARC): „Integrated Services in
the Internet Architecture: an Overview.“ IETF RFC 1633, June 1994.
[2] J. Babiarz, K. Chan, (Nortel Networks), F. Baker (Cisco Systems): „Configuration
Guidelines for DiffServ Service Classes“, IETF RFC 4594, August 2006.
[3] ITU-T Recommendation G.1000: “Communications Quality of Service: A Framework and
Definitions”, ITU-T 11/2001.
[4] ITU-T Recommendation G.1010 : „End-user multimedia QoS categories“ ITU-T 11/2001.
[5] Kevin Fall, Kannan Varadhan, "The ns Manual – The VINT Project", A collaboration
between researchers at UC Berkeley, LBL, USC/ISI, and Xerox PARC , January 2009.
[6] Ankur Chadda, "Quality of Service testing methodology", B.E., University of Bombay
(Mumbai), India , 1999.
[7] Peter Pieda, Jeremy Ethridge, Mandeep Baines, Farhan Shallwani, "A Network Simulator
Differentiated Services Implementation", Nortel Networks, July 26, 2000.

13