Robert Chodorek
Katedra Telekomunikacji
Akademia Górniczo-Hutnicza
Al. Mickiewicza 30, 30-059 Kraków

Agnieszka Chodorek
Zakład Telekomunikacji i Fotoniki
Politechnika Świętokrzyska
Al. 1000-lecia Państwa Polskiego 7, 25-314 Kielce

ANALIZA SYMULACYJNA WYDAJNOŚCI PROTOKOŁU RTP

REALIZUJĄCEGO USŁUGĘ MULTIKASTOWĄ TYPU SSM

Streszczenie: W referacie została zaprezentowana analiza
symulacyjna protokołu RTP przeprowadzona w środowis-
ku symulatora zdarzeniowego ns-2. Przeanalizowano
przypadek protokołu RTP realizującego transmisję
multikastową typu SSM.

1. WSTĘP

Multikastowy protokół RTP (Real-time Transport

Protocol) [2] jest, obok TCP i UDP, jednym z
najczęściej stosowanych protokołów transportowych
współczesnego Internetu. Jest on przeznaczony do trans-
misji danych multimedialnych w czasie rzeczywistym.
Jego zastosowania obejmują m.in. interaktywne usługi
audio i (lub) wideo oraz dystrybucję danych audio i (lub)
wideo. Protokół RTP posiada mechanizmy pozwalające
na identyfikację rodzaju przesyłanych danych (audio,
wideo) oraz identyfikację metody kodowania danych
(PCM, ADPCM, MPEG-4 i inne). Obecnie
wykorzystywana jest wersja 2 protokołu RTP,
zdefiniowana w 1996 roku [3] i rozszerzona w lipcu
2003 [2] o nowe algorytmy sterowania transmisją
multimedialną do dużych grup odbiorców.

Protokół RTP samodzielnie nie realizuje wszyst-

kich funkcji warstwy transportowej. Do multipleksacji i
detekcji błędów wykorzystuje protokół UDP, tworząc
wraz z nim stos protokołowy RTP/UDP. Do sterowania
transmisją realizowaną przez protokół RTP służy
protokół RTCP (RTP Control Protocol). Protokół ten
stanowi integralną część specyfikacji RTP i spełnia
cztery podstawowe funkcje: (1) monitorowanie jakości
transmisji danych, (2) identyfikacja źródła informacji,
(3) skalowanie sesji multikastowej, (4) przenoszenie
dodatkowych informacji kontrolnych sesji (funkcja
opcjonalna). Każda transmisja RTP posiada skojarzoną z
nią transmisję RTCP. W systemach konferencyjnych, w
których przesyłanych jest niezależnie kilka rodzajów
mediów (np. audio i wideo), każdy strumień składowy
RTP posiada własny strumień RTCP, co pozwala na
indywidualne sterowanie transmisją każdego strumienia.

Praca naukowa finansowana ze środków Komitetu

Badań Naukowych w latach 2003-2005 jako projekt
badawczy nr 4 T11D 015 24.

W referacie przedstawiono analizę protokołu RTP

przeprowadzoną w środowisku symulacyjnym ns-2.
Rozdział 2 referatu prezentuje model symulacyjny proto-
kołu RTP. Rozdział 3 omawia eksperyment symulacyjny.
Rozdział 4 prezentuje analizę jakości multikastowej
transmisji wideo typu SSM realizowanej z
wykorzystaniem protokołu RTP.

2. MODEL SYMULACYJNY PROTOKOŁU RTP

Rozdział prezentuje symulator ns-2 oraz modele

symulacyjne protokołów RTP i RTCP.

2.1. Symulator ns-2

Dyskretny symulator zdarzeniowy sieci

komputerowych ns-2 [1] został opracowany na
Uniwersytecie w Berkeley w ramach programu VINT.
Dostarcza on narzędzi do symulacji wielu protokołów,
jak np. IP (IPv4, IPv6), TCP, UDP, RTP, HTTP, FTP.
Pozwala na symulację mechanizmów zapewnienia
gwarantowanej jakości usług sieciowych QoS i
zapobiegania przeciążeniom. Symulator ns-2 wspiera
wiele technologii sieciowych, takich jak sieci lokalne,
rozległe, optyczne, bezprzewodowe, itd.

Ns-2 jest symulatorem obiektowym, napisanym w

języku C++ oraz w języku skryptowym Otcl (Object
Tool Command Language) stanowiącym interfejs
programowy użytkownika. Modele symulacyjne zwykle
są budowane z użyciem obu tych języków, przy czym
modele mechanizmów przetwarzania protokołowego
zazwyczaj są pisane w C++. Topologia sieci i parametry
symulacji zazwyczaj są definiowane w języku Otcl,
dlatego klasy C++ znajdują swoje ścisłe
odzwierciedlenie w hierarchii obiektów Otcl.

Modele symulacyjne protokołów warstwy

transportowej są reprezentowane w środowisku ns-2
przez obiekty potomne bazowej klasy Agent. Klasie tej
odpowiada klasa Agent języka Otcl. Klasa Agent
realizuje symulację procesów tworzenia, nadawania i
odbioru pakietów.

2003

Poznañskie Warsztaty Telekomunikacyjne

Poznañ 11-12 grudnia 2003

2.2. Model symulacyjny protokołu RTP

Model symulacyjny protokołu RTP jest w całości

realizowany w oparciu o klasę Agent języka C++ i
odpowiadającą jej klasę Agent języka Otcl. Model ten
jest modelem symetrycznym; część nadawcza (nadajnik
RTP) i odbiorcza (odbiornik RTP) są realizowane jako
jeden wspólny obiekt potomny klasy Agent. Obiekt ten
nosi nazwę RTPAgent, a jego odpowiednikiem w
hierarchii obiektów Otcl jest klasa Agent/RTP. Symet-
ria modelu symulacyjnego wynika z założeń protokołu
RTP: żaden system końcowy nie jest uprzywilejowany, a
każdy z nich może, w dowolnej chwili czasu, pełnić
funkcję zarówno nadajnika, jak i odbiornika.

Tab. 1. Parametry modelu symulacyjnego protokołu RTP

Parametr

Wartość

domyślna

Opis

seqno_

0

numer sekwencyjny

pakietu RTP

interval_

3,75 ms

przedział czasu pomiędzy

generowanymi pakietami

random_

0

załączenie/wyłączenie

randomizacji czasu

pomiędzy kolejnymi

generowanymi pakietami

packetSize_

210

rozmiar (w bajtach)

pakietu RTP

maxpkts_

2

28

maksymalna liczba

generowanych pakietów

Model symulacyjny protokołu RTP posiada szereg

parametrów dziedziczonych po klasie Agent (adres IP
źródła agent_addr_, numer portu źródłowego
agent_port_

, adres IP miejsca przeznaczenia

datagramu dst_addr_, numer portu przeznaczenia
dst_port_

, itd.). Parametry te są wykorzystywane

przez wewnętrzne procesy symulacji. Mogą być one
konfigurowane z poziomu skryptu tcl.

Model symulacyjny protokołu posiada również

parametry specyficzne dla klasy Agent/RTP. Lista tych
parametrów wraz z opisem i wartością domyślną
(początkową dla każdej symulacji) została zamieszczona
w Tab. 1. Parametry specyficzne dla klasy Agent/RTP
są konfigurowalne z poziomu skryptu tcl.

2.3. Model symulacyjny protokołu RTCP

Protokół RTCP dostarcza mechanizmów warstwy

sesji, stąd też w skład modelu symulacyjnego wchodzą
(obok obiektów potomnych klasy Agent) obiekty
potomne bazowej klasy Session. Model symulacyjny
protokołu RTCP jest realizowany dwutorowo:
• mechanizmy przetwarzania protokołowego są

zawarte w klasie RTCPAgent (dziedziczącej po
klasie Agent),

• mechanizmy zarządzania sesją RTP są zawarte w

klasie RTPSession (dziedziczącej po klasie Session).

Klasie RTCPAgent języka C++ odpowiada klasa
Agent/RTCP

języka Otcl, natomiast klasie RTPSession

języka C++ odpowiada klasa Session/RTP. Nazwy
RTPSession i Session/RTP pochodzą od sesji RTP
(nie zaś od warstwy sesji modelu OSI), która to sesja jest
nadzorowana i sterowana przez protokół RTCP. Klasa
Session/RTP

nie zezwala na ustawienie żadnych

parametrów specyficznych dla RTCP. Przegląd
parametrów specyficznych dla klasy Agent/RTCP
został zamieszczony w Tab. 2.

Tab. 2. Parametry modelu symulacyjnego

protokołu RTCP

Parametr

Wartość

domyślna

Opis

seqno_

0

numer sekwencyjny

raportu RTCP

interval_

0

przedział czasu pomiędzy

raportami RTCP

random_

0

załączenie/wyłączenie

randomizacji przedziału

czasu interval_

Model symulacyjny protokołu RTCP jest modelem

symetrycznym. Każdy agent protokołu RTCP może
generować zarówno raporty odbiornika, jak i nadajnika.
Rodzaj wygenerowanego raportu zależy od funkcji, jaką
w danej chwili pełni skojarzony z nią agent RTP.

2.4. Symulacja transmisji RTP

Symulacja transmisji RTP wymaga podłączenia do

węzła (reprezentującego warstwy 1-3 modelu OSI, wraz
z protokołem IP) zarówno modelu protokołu RTP, jak i
protokołu RTCP. Jawne podłączanie obu protokołów
pozwala, w razie potrzeby, na uproszczenie modelu
symulacyjnego transmisji. Analiza ogranicza się
wówczas do zjawisk występujących w protokole RTP, z
pominięciem elementów zarządzania sesją. Takie
podejście znajduje zastosowanie np. w przypadku badań
wydajności protokołu na jednym kierunku transmisji.

W przeciwieństwie do realnego RTP, model

symulacyjny protokołu realizuje multipleksację
przesyłanych strumieni zgodną z UDP. Nie ma zatem
potrzeby stosowania dodatkowych modułów pomiędzy
RTP a węzłem, co znacznie przyspiesza symulację.

Rys. 1 przedstawia fragment przykładowego skryp-

tu symulacyjnego, powołującego dwie nowe instancje
protokołu RTP (rtp1 i rtp2), po czym dołącza je do
(uprzednio utworzonych) węzłów n1 i n2. Metoda
connect

(Rys. 1a) konfiguruje adresację (dokładniej:

numery węzłów docelowych i numery portów
przeznaczenia) systemów końcowych dla transmisji
punkt-punkt. W przykładzie podanym na Rys. 1a,
obydwie stacje są nadajnikami i odbiornikami RTP.

Symulacja transmisji multikastowej (Rys. 1b)

wymaga powołania grupy multikastowej (tu: o adresie
przypisanym do zmiennej grupa) oraz konfigurowania
adresacji systemów nadawczych. Jest to realizowane
poprzez ustawienie parametrów dst_addr_ i
dst_port_

właściwego agenta RTP. W przykładzie

danym na Rys. 1b, obydwie stacje są nadajnikami RTP.

(a)

set rtp1 [new Agent/RTP]
set rtp2 [new Agent/RTP]

$ns attach-agent $n1 $rtp1
$ns attach-agent $n2 $rtp2

$ns connect $rtp1 $rtp2

(b)

set grupa [Node allocaddr]

set rtp1 [new Agent/RTP]
set rtp2 [new Agent/RTP]

$ns attach-agent $n0 $rtp1
$ns attach-agent $n1 $rtp2

$rtp1 set dst_addr_ $grupa
$rtp1 set dst_port_ 0
$rtp2 set dst_addr_ $grupa
$rtp2 set dst_port_ 0

(c)

$ns at 0.5 \

"$n0 join-group $rtp1 $grupa"

$ns at 0.5 \

"$n1 join-group $rtp2 $grupa"

Rys. 1. Powołanie dwóch nowych instancji agentów RTP

i konfiguracja transmisji: a) punkt-punkt (typu unicast),

b) multikastowej, c) uzupełnienie harmonogramu

eksperymentu o dołączenie systemów końcowych do

grupy multikastowej.

Aby odbierać dane rozsyłane na adres grupy

multikastowej, stacje muszą w sposób jawny dołączyć się
do grupy. Rys. 1c przedstawia fragment skryptu języka
tcl, uzupełniającego harmonogram eksperymentu o
dołączenie obydwu stacji do grupy multikastowej (po
czasie 0.5 s, licząc od chwili rozpoczęcia symulacji).

Podłączanie protokołu RTCP realizowane jest w

sposób analogiczny. Należy przy tym pamiętać, iż
(niezgodnie ani z RFC 1889 [3], ani z RFC 3550 [2])
w symulatorze ns-2 obydwa protokoły powinny nadawać
pakiety na adres dwóch różnych grup multikastowych.
Wynika to z ograniczeń modelu węzła multikastowego
zaimplementowanego w symulatorze ns-2.

3. EKSPERYMENT SYMULACYJNY

Wprowadzenie protokołów IGMPv3 i MLDv2

umożliwiło filtrację

źródeł za pomocą filtrów

włączających i wykluczających. Udostępniło tym samym
usługę SSM (ang. Source-Specific Multicast) transmisji
multikastowej, zezwalająca na transmisję od dokładnie
jednego źródła. Usługa ta, której podstawowe założenia
przedstawiono w RFC 3569 [4] z lipca 2003 roku, jest

szczególnie istotna w systemach radia internetowego i
telewizji internetowej, gdzie w sposób naturalny
zabezpiecza przed transmisją pochodzącą od
nieautoryzowanych źródeł (tzw. „spamem”).

B

1

τ

1

R1

R2

odb1



odb2



B

21

, B

22

, …, B

2N

τ

21

,

τ

22

, …,

τ

2N

100 Mb/s

1

µs

nad1



…

odbN



Rys. 2. Topologia wykorzystywana podczas symulacji.

Przedstawiona w referacie analiza symulacyjna

protokołu RTP obejmowała zagadnienia multimedial-
nych połączeń multikastowych typu SSM. Analiza
została przeprowadzona w oparciu o topologię
zamieszczoną na Rys. 2. Topologia ta wykorzystywana
była do testowania połączenia multikastowego typu
SSM, w którym nad1 rozsyła dane do odbiorników odb1,
odb2, …, odbN. W skład analizowanego systemu
wchodzą (Rys. 2): węzeł nadawczy (nad1), dwa węzły
pośredniczące (rutery R1, R2) oraz N węzłów
odbiorczych (odb1, odb2, …, odbN). Węzeł nadawczy
posiada teoretycznie nieskończony bufor (1000
pakietów) i połączony jest z ruterem R1 łączem o
przepustowości 100 Mb/s i opóźnieniu propagacyjnym 1
µs. Pojemności buforów węzłów R1 i R2 są równe 150
pakietów. Ruter R1 połączony jest z następnym w
kolejności systemem R2 łączem o przepustowości B

1

i

opóźnieniu

τ

1

(wartości domyślne tych parametrów:

B

1

= 10 Mb/s,

τ

1

= 2,5 ms). Ruter R2 jest połączony z

i-tym odbiornikiem łączem o przepustowości B

2i

i

opóźnieniu

τ

2i

(wartości domyślne: B

2i

= 10 Mb/s,

τ

2i

= 2,5 ms, i = 1, 2, …N).

Eksperyment zakładał realizację transmisji wideo

MPEG-4 o częstotliwości generowania ramek 25 Hz.
Każda transmisja trwała 5 minut (300 sekund), po czym
następował 500-minutowy okres oczekiwania na
opóźnione pakiety. Transmisja wideo wykorzystywała
rzeczywiste przebiegi ruchu wideo MPEG-4 lub była
modelowana jako ruch o stałej prędkości bitowej (CBR)
2 Mb/s (rozmiar ramki wideo: 10 000 B). Rzeczywiste
przebiegi ruchu MPEG-4 pochodzą z publicznie dostęp-
nych plików [5] o wysokiej jakości obrazu oryginalnego.
Do celów analizy zostały wybrane przebiegi: star – film
„Gwiezdne wojny” (średni rozmiar ramki x

śr

= 1618 B;

maksymalny rozmiar ramki x

max

= 9370 B; odchylenie

standardowe

δ = 1231), vclips – wideoklip (x

śr

= 5333 B;

x

max

= 13568 B;

δ = 1943), cam – film pochodzący z

kamery monitorującej parking (x

śr

= 4539 B;

x

max

= 13535 B;

δ = 2690). Wyrażenia podane w

nawiasach dotyczą próby 7500 ramek (pierwsze 5 minut
materiału filmowego). Charakterystyki statystyki
opisowej opracowane dla całości materiału filmowego
można znaleźć w [5].

4. ANALIZA SYMULACYJNA WYDAJNOŚCI

PROTOKOŁU RTP

Eksperyment symulacyjny miał na celu realizację

badań wpływu zmian parametrów protokołu RTP
(rozmiar pakietu RTP) oraz sieci (przepustowość, opóź-
nienie propagacyjne) na jakość transmisji ruchu wideo
(przepływność, opóźnienie, wariancja opóźnienia,
straty). Zrealizowano badania wydajności połączenia
multikastowego typu SSM realizowanego przez protokół
RTP.

Analiza symulacyjna wydajności połączeń multi-

kastowych RTP została przeprowadzona w łączu nieob-
ciążonym dodatkowym ruchem. Badania obejmowały
szacowanie zmian parametrów jakościowych transmisji
wideo w funkcji długości pakietu RTP, opóźnienia pro-
pagacyjnego oraz przepustowości łącza.

4.1. Badania jakości transmisji wideo przy różnych

długościach pakietu RTP p

Badania jakości transmisji wideo przy różnych

długościach pakietu RTP p prowadzone były dla
domyślnych wartości parametrów B

1

, B

2i

,

τ

1

i

τ

2i

,

i = 1, 2, …, N. System przeanalizowano dla przypadku
N = 1 i N = 5 odbiorników multikastowych. Rozmiar
pakietu p protokołu RTP zmieniany był w zakresie od
100 B do 10 000 B, przy czym największy nacisk
położono na wartości p z zakresu od 100 do 500 bajtów.

Badania wykazały, że w systemie nie występowały

straty pakietów, a uzyskane przebiegi miar jakości
transmisji w funkcji rozmiaru pakietu p pokrywały się
dla każdego z 5 odbiorników multikastowych. Nie
zaobserwowano również różnic pomiędzy wynikami
uzyskanymi dla N = 1

i

N = 5

odbiorników

multikastowych.

Dla analizowanych warunków pracy, system

zachowywał się bardzo stabilnie w całym zakresie zmian
parametru p. Osiągana przepływność (liczona dla danych
przenoszonych przez protokół RTP, z pominięciem
narzutu wnoszonego przez nagłówki), wynikała tylko ze
średniej długości ramki wideo w badanym materiale
filmowym i nie zależała w żadnym stopniu od rozmiaru
pakietu RTP. Ze względu na dużą względną
przepustowość łączy (w stosunku do prędkości bitowej
ruchu wideo), ruch RTCP praktycznie nie wpływał na
przepływność RTP.

Rozmiar pakietów RTP ma wpływ zarówno na

średnie opóźnienie transmisyjne pakietu (Rys. 3), jak i na
wariancję opóźnienia (Rys. 4). Zjawisko to wynika z
niejednorodnego charakteru opóźnienia transmisyjnego,
na które składają się czasy: propagacji, nadawania i
buforowania. Najmniejsze opóźnienia transmisyjne
obserwowane były dla małych pakietów, rzędu 200 (star)
do 300 bajtów (cam), jednakże towarzyszyła im
stosunkowo duża wariancja opóźnienia (CBR: 7.27

⋅10

-6

,

star: 1.15

⋅10

-6

, vclips: 3.922

⋅10

-6

, cam: 7.309

⋅10

-6

). Dla

bardzo małych i dużych pakietów RTP opóźnienia rosną.
W przypadku bardzo małych pakietów, jest to spowodo-
wane głównie wzrostem udziału stałych nagłówków
RTP/UDP/IP w całkowitym rozmiarze pakietu.

0

2000

4000

6000

8000

1 .10

4

0.005

0.01

0.015

0.02

0.025

rozmiar pakietu [B]

opó

źnienie [s]

Rys. 3.Średnie opóźnienie transmisyjne pakietu w funkcji

rozmiaru pakietu p, wyznaczone w odbiorniku odb3

(i = 3) dla ruchu CBR (x) oraz materiałów filmowych:

star (+), vclips ( ), cam (o).

0

2000

4000

6000

8000

1 .10

4

1 .10

5

2 .10

5

rozmiar pakietu [B]

w

a

riancja opó

źnienia [s]

Rys. 4.Wariancja opóźnienia transmisyjnego pakietu w
funkcji rozmiaru pakietu p; oznaczenia – jak na Rys. 3.

Narzut wnoszony przez nagłówki niweluje tutaj

korzyści wynikające z niewielkich wielkości pakietów,
nie usuwa jednakże skutków ubocznych. Bardzo małym
rozmiarom pakietów towarzyszy zatem znaczny wzrost
fluktuacji opóźnienia. Wraz ze wzrostem rozmiaru
pakietu fluktuacje te początkowo maleją, aż do
osiągnięcia minimum (dla ruchu CBR rozmiar pakietu
jest równy wówczas rozmiarowi ramki wideo). Wraz z
dalszym wzrostem p krzywa narasta, osiągając nasycenie
w pobliżu x

max

. Wariancja opóźnienia jest wtedy liniowo

zależna od wariancji ramek wideo.

4.2. Badania jakości transmisji wideo przy różnych

wartościach czasu RTT

Badania jakości transmisji wideo przy różnych

wartościach czasu RTT prowadzone były dla domyślnej
wartości parametru B

1

oraz B

2i

, i = 1, 2, …, N. Rozmiar

pakietu RTP wynosił 200 B. Do analiz przyjęto
nominalną wartość czasu RTT, równą podwojonemu
całkowitemu czasowi propagacji

τ w systemie. Wartość

nominalna stanowi jednocześnie kres dolny
rzeczywistego czasu RTT pakietu znajdującego się w
systemie. System przeanalizowano dla przypadku N = 1 i
N = 5 odbiorników multikastowych, dla których czas

propagacji

τ =1 µs + τ

1

+

τ

21

= … = 1

µs +τ

1

+

τ

2N

zmieniany był w zakresie od 1 ms do 1 s, co dawało
zmiany czasu RTT równe 2

⋅τ.

1 .10

3

0.01

0.1

1

10

5 .10

5

1 .10

6

1.5 .10

6

2 .10

6

czas RTT [s]

przepływ

n

o

ść

[b/s]

Rys. 5. Przepływność protokołu RTP w funkcji czasu

RTT; oznaczenia – jak na Rys. 3.

1 .10

3

0.01

0.1

1

10

1 .10

3

0.01

0.1

10

czas RTT [s]

opó

źnienie [s]

Rys. 6. Średnie opóźnienie transmisyjne pakietu RTP w

funkcji czasu RTT; oznaczenia – jak na Rys. 3.

1 .10

3

0.01

0.1

1

10

1 .10

6

1 .10

5

1 .10

4

czas RTT [s]

w

a

riancja opó

źnienia [s]

Rys. 7. Wariancja opóźnienia transmisyjnego pakietu

RTP w funkcji czasu RTT; oznaczenia – jak na Rys. 3.

Podobnie, jak poprzednio, dla analizowanych

warunków pracy system zachowuje się bardzo stabilnie
w całym zakresie zmian

τ

1

(Rys. 5). Osiągana przepływ-

ność transmisji RTP praktycznie nie zależy od czasu
RTT. Maksymalna zaobserwowana różnica przepływ-
ności, wynikająca z różnicy opóźnienia propagacyjnego
∆τ

1

= 10

3

ms – 1 ms = 999 ms, wyniosła 0.00332 (tj.

0.332%) dla każdego z badanych materiałów filmowych
i jest niezauważalna na wykresie.

Jak można się było spodziewać, średnie opóźnienie

transmisyjne pakietów RTP jest silnie zależne od
wartości czasu RTT (Rys. 6). W przypadku mniejszych
wartości RTT, wyraźnie widoczny jest również wpływ
czasów propagacji i buforowania, co skutkuje stałą
wartością wariancji opóźnienia w dużym zakresie zmian
RTT (Rys. 7). W miarę wzrostu RTT wpływ tych czasów
maleje, dla dużych RTT nawet znacznie. Dzięki temu
wykres średnich opóźnień w funkcji RTT można
wówczas (z dokładnością do kilku procent) przybliżyć
zależnością liniową (o współczynniku kierunkowym
równym 2), a wariancja opóźnienia traci stały charakter i
zaczyna narastać.

Również i w tym przypadku badania wykazały, że

w systemie nie występowały straty pakietów. Uzyskane
przebiegi miar jakości transmisji w funkcji RTT
pokrywały się dla każdego z odbiorników multikasto-
wych, niezależnie, czy należał on do systemu złożonego
z N = 1 czy N = 5 odbiorników.

4.3. Badania jakości transmisji wideo przy różnych

wartościach przepustowości łącza B

2i

Badania transmisji wideo przy różnych wartościach

przepustowości łącza B

2i

prowadzone były dla 200-

bajtowych pakietów RTP, w systemie o parametrach:
B

1

= 100 Mb/s,

τ

1

= 1

µs, τ

2i

= 5 ms, i = 1, 2, …, N.

Podobnie, jak poprzednio, system przeanalizowano dla
przypadku N = 1 i N = 5 odbiorników multikastowych,
pracujących w symetrycznym drzewie dystrybucji, dla
których przepustowości B

2i

były sobie równe i wynosiły

B. Wartość B była zmieniana w zakresie od 100 kb/s do
2700 kb/s, z krokiem 100 kb/s, co umożliwiło stworzenie
„wąskiego gardła”, które nie jest zdolne do przeniesienia
ramki wideo w czasie rzeczywistym.

W badanym systemie wzrost przepustowości łącza

pociąga za sobą proporcjonalny wzrost przepływności
RTP (Rys. 8), co jest spowodowane zmniejszającymi się
stratami pakietów (Rys. 9). Przepływność protokołu RTP
stabilizuje się na poziomie średniej prędkości bitowej
źródła. Dalsze zwiększanie przepustowości łącza nie
wpływa na przepływność protokołu RTP. Przepustowość
graniczna łącza, przy której przepływność protokołu
osiąga maksimum, znajduje się powyżej średniej
prędkości bitowej źródła i w dużej mierze zależy od
parametrów statystycznych ruchu. Przykładowo, dla
ruchu CBR wynosi ona ok. 2.5 Mb/s, co wynika z
prędkości bitowej źródła CBR (2 Mb/s), narzutu
wnoszonego przez nagłówki RTP/UDP/IP (20%) oraz
ruchu RTCP (5%).

Charakterystyka wartości względnej strat pakietów

w funkcji przepustowości łącza (Rys. 9) jest krzywą
nierosnącą, która dla dużych przepustowości stabilizuje
się na poziomie zera. Opadająca część krzywej ma
charakter liniowy dla ruchu CBR oraz dla ruchu o
zmiennej prędkości bitowej (VBR) generowanego na
bazie materiału filmowego o małej dynamice (cam).

W przypadku ruchu VBR generowanego na bazie

materiału filmowego o dużej dynamice (star, vclips),

0

5 .10

5

1 .10

6

1.5 .10

6

2 .10

6

2.5 .10

6

3 .10

6

1 .10

6

2 .10

6

przepustowość [b/s]

przepływ

n

o

ść

[b/s]

Rys. 8. Przepływność protokołu RTP w funkcji

przepustowości łącza; oznaczenia – jak na Rys. 3.

0

5 .10

5

1 .10

6

1.5 .10

6

2 .10

6

2.5 .10

6

3 .10

6

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

przepustowość [b/s]

wz

g

lę

dne straty pakietów

Rys. 9. Względne straty pakietów RTP w funkcji

przepustowości łącza; oznaczenia – jak na Rys. 3.

charakterystyka strat początkowo opada liniowo (do
przepustowości bliskich średniej prędkości bitowej
źródła), a następnie wolniej, długo utrzymując się na
poziomie kilku procent.

Średnie opóźnienie transmisyjne w analizowanym

systemie (Rys. 10), obserwowane dla małych wartości
przepustowości łącza, jest silnie zależne od czasu
buforowania. Gwałtowana zmiana opóźnienia transmi-
syjnego obserwowana dla ruchu CBR i VBR o małej
dynamice obrazu ruchomego (cam) odpowiada punktowi
nieciągłości odcinkowo-liniowej charakterystyki strat.
Dla ruchu VBR o dużej dynamice obrazu ruchomego
(star, vclips) zmiany te są znacznie łagodniejsze.
Spadkowi opóźnienia towarzyszy zwykle spadek
wariancji opóźnienia (Rys. 11), chociaż dla części
materiałów filmowych (cam, vclips) jest obserwowany
wzrost wariancji opóźnienia dla przepustowości łącza
bliskich średniej prędkości bitowej źródła.

5. ZAKOŃCZENIE

Badania jakości wykazały, że multikastowa

transmisja wideo typu SSM, realizowana z
wykorzystaniem protokołu RTP, jest stabilna w szerokim
zakresie zmian rozmiarów pakietów i RTT. Ze względu
na wymaganie niewielkiego opóźnienia, korzystniejsze
jest stosowanie mniejszych pakietów, chociaż bardzo

0

5 .10

5

1 .10

6

1.5 .10

6

2 .10

6

2.5 .10

6

3 .10

6

1 .10

3

0.01

0.1

10

przepustowość [b/s]

opó

źnienie [s]

Rys. 10. Średnie opóźnienie transmisyjne RTP w funkcji

przepustowości łącza; oznaczenia – jak na Rys. 3.

0

5 .10

5

1 .10

6

1.5 .10

6

2 .10

6

2.5 .10

6

3 .10

6

1 .10

5

1 .10

4

1 .10

3

0.01

0.1

przepustowość [b/s]

w

ariancja opó

źnienia [s]

Rys. 11. Wariancja opóźnienia transmisyjnego w funkcji

przepustowości łącza; oznaczenia – jak na Rys. 3.

małe pakiety są niekorzystne ze względu na wzrost
wariancji opóźnienia. Na znaczny wzrost wariancji
opóźnienia wpływają również czasy RTT powyżej
300 ms. Z tych samych powodów należy unikać pracy
systemu na granicy przepustowości gwarantujących
zerowe straty. Nawet, jeżeli w systemie nie występują
straty pakietów lub straty te są niewielkie (rzędu
pojedynczych %), dla niektórych materiałów filmowych
mogą w tym obszarze pracy wystąpić duże fluktuacje
opóźnienia transmisyjnego.

SPIS LITERATURY

[1] K. Fall, K. Vradhan, „The ns Manual”, URL

http://www.isi.edu/nsnam/ns/doc/ns_doc.pdf.

[2] H. Schulzrinne, S. Casner, R. Frederick, V.

Jacobson, „RTP: A Transport Protocol for Real-
Time Applications”, RFC 3550. July 2003.

[3] H. Schulzrinne, S. Casner, R. Frederick, V.

Jacobson, „RTP: A Transport Protocol for Real-
Time Applications”, RFC 1889, January 1996.

[4] S. Bhattacharyya (red.), „An Overview of Source-

Specific Multicast (SSM)”, RFC 3569, July 2003.

[5] F.H.P. Fitzek, M. Reisslein, „MPEG-4 and H.263

Video Traces for Network Performance
Evaluation”, IEEE Network, Vol. 15, No. 6,
November/December 2001.