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.