docTransport strumieni VoD w kanale ATM kategorii CBR
download 
Reklamacja Transkrypt
Transport strumieni VoD w kanale ATM kategorii CBR
Marek Natkaniec, Krzysztof Wajda Katedra Telekomunikacji Akademia Górniczo-Hutnicza, Kraków Transport strumieni VoD w kanale ATM kategorii CBR Operatorzy telekomunikacyjni czyni¹ starania w kierunku realizacji systemu VoD opartego na transmisji strumieni MPEG. Wykorzystanie kategorii ruchowej CBR do transmisji „wybuchowego” ruchu typu MPEG jest skutecznym sposobem realizacji us³ugi VoD. Prostota definiowania parametrów kana³u CBR u³atwia negocjacje parametrów ruchowych pomiêdzy u¿ytkownikiem a operatorem sieci. Odpowiednie wyg³adzenie strumieni daje podobny efekt jak multipleksacja statystyczna strumieni VBR – podniesienie efektywnoœci systemu transportu informacji MPEG. 1. Wprowadzenie Obserwujemy obecnie wzrastaj¹ce zainteresowanie firm telekomunikacyjnych dla przygotowania systemu przesy³ania informacji wideo na ¿¹danie czyli realizacj¹ us³ugi VoD (Video on Demand). Inn¹ powszechnie akceptowan¹ us³ug¹ zwi¹zan¹ z transmisj¹ skompresowanych strumieni wideo jest dystrybucja programów telewizyjnych. Istnieje silna tendencja do implementacji nowych us³ug szerokopasmowych w sieciach zbudowanych z wykorzystaniem najnowszych technik sieciowych, takich jak ATM, w œrodowisku œwiat³owodowym lub miedzianym (techniki xDSL). Dysponuj¹c okreœlonym pasmem dla us³ugi VoD d¹¿ymy do zagwarantowania transmisji jak najwiêkszej liczby strumieni programów bez istotnego pogarszania jakoœci ich transmisji. Najbardziej znanymi i powszechnie u¿ywanymi standardami kodowania wideo jest MPEG w wersji 1 i 2 [1]. Koder MPEG generuje ramki o zmiennych d³ugoœciach u³o¿one w strukturê GOP (Group of Pictures). Metodami zmniejszaj¹cymi zapotrzebowanie na przepustowoœæ przy transmisji strumieni MPEG jest wykorzystanie buforów wyg³adzaj¹cych oraz odpowiednia synchronizacja wzajemna strumieni. W ka¿dym stratnym systemie kodowania istnieje zwi¹zek pomiêdzy prêdkoœci¹ transmisji kodowanych danych a zniekszta³ceniami generowanego sygna³u. Transmisja pojedynczego strumienia wideo w kanale CBR (Constant Bit Rate) wi¹¿e siê z koniecznoœci¹ stosowania bufora wyg³adzaj¹cego gwa³towne zmiany przep³ywnoœci bitowej. Zape³nianie bufora danych jest monitorowane przez tzw. kontroler przep³ywnoœci zabezpieczaj¹cy bufor przed przepe³nieniem lub niedostatecznym wype³nieniem. W tego typu systemach kodowania koder generuje strumieñ bitów, którego szybkoœæ bitowa jest sta³a w przeci¹gu d³ugiego okresu czasu z krótko okresowymi wariacjami ograniczonymi wielkoœci¹ bufora zastosowanego w koderze. Strumieñ bitów wytworzony w ten w³aœnie sposób odnosi siê zwykle do strumienia CBR. Dla odró¿nienia strumieñ bitowy, którego przep³ywnoœæ nie jest sta³a w czasie jest nazywany strumieniem VBR (Variable Bit Rate). Do transmisji strumieni MPEG jest przeznaczona kategoria ruchowa rt-VBR jednak istnieje potrzeba przeanalizowania wp³ywu wykorzystania do tego celu tak¿e innych kategorii ruchowych. Prostota definiowania parametrów kana³u CBR u³atwia negocjacje parametrów ruchowych pomiêdzy u¿ytkownikiem a operatorem sieci. Pozornie trudne jest w tym przypadku osi¹gniêcie du¿ej efektywnoœci transmisji, gdy¿ definiowanie jako podstawowego dla CBR parametru PCR (Peak Cell Rate) oznacza koniecznoœæ zorientowania rezerwacji na wartoœci maksymalne. 2. Wyg³adzanie sygna³u wideo Istnieje potrzeba wyg³adzenia porowatego charakteru strumienia MPEG w celu dostosowania szybkoœci chwilowej do przepustowoœci kana³u transmisyjnego. Zastosowanie elementu poœrednicz¹cego - kontrolera przep³ywnoœci, umo¿liwia regulacjê szybkoœci kodowania przy zachowaniu zadowalaj¹cego poziomu zniekszta³ceñ. Standard MPEG okreœla sk³adniê kodowanego strumienia bitowego oraz mechanizm jego dekodowania [1]. Co wiêcej, standard definiuje istnienie hipotetycznego dekodera zwanego weryfikatorem bufora wideo VBV (Video Buffer Verifier) pokazanego na Rys. 1. Bufor Dekodera Kana³ o danej przep³ywnoœci R BVBV Dekoder Ekran Kana³ o wysokiej przep³ywnoœci Rys. 1. Schemat blokowy weryfikatora bufora wideo. Dzia³anie weryfikatora bufora wideo polega na porównywaniu czy zakodowany strumieñ bitowy bêdzie dekodowalny z przy okreœlonych ograniczeniach na wielkoœæ bufora dekoduj¹cego BVBV i wejœciow¹ przep³ywnoœæ bitow¹ R. Jak pokazano na Rys. 2 wyjœciowa przep³ywnoœæ bitowa kodera wideo mo¿e byæ regulowana przez zmianê poziomu kwantyzacji Q S. Zwiêkszenie QS redukuje wyjœciow¹ przep³ywnoœæ bitow¹, ale tak¿e zmniejsza jakoœæ kompresowanego obrazu. Podobnie, zmniejszenie QS powoduje wzrost zarówno przep³ywnoœci bitowej jak i jakoœci kompresowanego obrazu. Rys. 3 pokazuje krzyw¹ zale¿noœci pomiêdzy przep³ywnoœci¹ bitow¹ oraz poziomem wprowadzanych zniekszta³ceñ. Przy braku zniekszta³ceñ Ÿród³o jest kodowane z entropi¹ równ¹ R. Chocia¿ QS mo¿e byæ u¿ywane do kontroli stopnia przep³ywnoœci i zniekszta³ceñ to jednak kodowanie ze sta³¹ wartoœci¹ QS niekoniecznie oznacza zachowanie sta³ej przep³ywnoœci bitowej lub otrzymanie sta³ej jakoœci obrazu. Oba te czynniki s¹ równie¿ zale¿ne od treœci przekazywanego obrazu. Rozwa¿aj¹c zdolnoœæ percepcji wizualnej cz³owieka zauwa¿amy, ¿e postrzeganie zniekszta³ceñ jest skorelowane z pewnymi w³asnoœciami przestrzennymi obrazu (sekwencji wideo). Kontroler przep³ywnoœci Transformacja Kwantyzacja Kodowanie entropijne Bufor Rys. 2. Schemat blokowy kontroli przep³ywnoœci w typowym systemie kodowania wideo. Rys. 3. Przyk³adowa zale¿noœæ pomiêdzy przep³ywnoœci¹ a zniekszta³ceniami dla transmisji sygna³u wideo. 3. Statystyczna analiza wybranych sekwencji wideo W celu praktycznego zbadania czynników wp³ywaj¹cych na przesy³anie strumieni MPEG w sieci ATM, zrealizowano szereg badañ symulacyjnych. Badania oparte by³y na wykorzystaniu trzech sekwencji filmowych zakodowanych w standardzie MPEG-1. Ka¿da z nich posiada odmienn¹ charakterystykê ruchow¹. •ród³a tych filmów zosta³y zakodowane w Institute of Computer Science na Uniwersytecie w Würzburgu przy pomocy kodera programowego UC Berkeley MPEG-I [9]. Wszystkie sekwencje filmowe posiadaj¹ nastêpuj¹ce parametry: • • • • • • • Czêstotliwoœæ ramek: 25 ramek na sekundê; Ka¿da ramka zawiera jedn¹ porcjê danych; GOP wg. struktury: IBBPBBPBBPBB (12 ramek); Skala kwantyzacji: 10(I), 14(P), 18(B); Poszukiwanie wektora ruchu: logarytmiczne / proste; ramka odniesienia: oryginalna; Wejœcie kodera: 384x288 pikseli z 12 bitow¹ informacj¹ o kolorze; Iloœæ ramek przypadaj¹cych na jedn¹ sekwencjê : 40000 (oko³o 0.5 godziny filmu). Badania dotyczy³y trzech sekwencjach filmowych: • • • lambs – fragment filmu „Milczenie owiec”; race – wyœcig Formu³y 1 Hockenheim/Germany 1994; mr.bean – trzy episody serialu komediowego „Jaœ Fasola”. Poni¿ej w Tabeli 1 zostanie przedstawiona krótka statystyka wybranych filmów. Tabela 2 przedstawia dok³adne statystyki opisowe ramek I, P, B wybranych sekwencji filmowych. Tabela 1. Proste statystyki kodowanych sekwencji Sekwencja Lambs Mr.Bean Race Stopieñ kompresji X:1 363 150 86 Œrednia [bity] 7,312 17,647 30,749 Ramki CoV 1.53 1.17 0.69 Szczyt / Œrednia 18.4 13.0 6.6 Œrednia [bity] 87,634 211,368 369,060 Struktury GOP CoV 0.60 0.50 0.38 Szczyt / Œrednia 5.3 4.1 3.6 Tabela 2. Statystyki opisowe ramek I, P, B. Sekwencja Rodzaj ramki Iloœæ ramek Œrednia d³ugoœæ ramki [bity] Minimalna d³ugoœæ ramki [bity] Maksymalna d³ugoœæ ramki [bity] Odchylenie standardowe [bity] Suma [bajty] I 3334 38023 Lambs P 10000 7436 B 26666 3424 I 3334 75161 Mr.Bean P 10000 18282 B 26666 10214 I 3334 79241 Race P 10000 38200 B 26666 21891 15120 528 288 14272 1720 344 36972 6040 4192 134222 88600 54976 150176 119216 129072 186048 202416 165448 12813 8051 3184 19458 14318 6697 20826 18235 9997 15846407 9295367 11415921 31323423 22852858 34046647 33023820 47750679 72971062 Rys. 4 przedstawia fragment sekwencji IBP ramek filmu Mr. BEAN (4 sekundy trwania zapisu wideo). Mo¿emy zaobserwowaæ tu cyklicznie powtarzaj¹c¹ siê 12 klatkow¹ strukturê GOP (pomiêdzy jasnymi s³upkami), a tak¿e wyraŸne ró¿nice w wielkoœci ró¿nych typów ramek (I,P,B). Charakterystyczna jest tak¿e du¿a zmiennoœæ wielkoœci ramek tego samego typu w czasie. 120000 Ramki I Ramki B Ramki P Wielkoœci ramek [bit] 100000 80000 60000 40000 20000 96 91 86 81 76 71 66 61 56 51 46 41 36 31 26 21 16 11 6 1 0 Numer ramki Rys. 4. Fragment sekwencji IBP ramek filmu „Mr. BEAN”. 4. Wyniki badañ Przeprowadzone badania zosta³y podzielone na dwa etapy. Celem pierwszego etapu by³o okreœlenie jak zmienia siê œrednia i maksymalna zajê toœæ bufora w zale¿noœci od zmiany szybkoœci transmisji w kanale CBR. Zastosowany bufor wyg³adza wybuchow¹ naturê strumienia MPEG, zmniejsza zatem wymagania na szybkoœæ ³¹cza CBR, wprowadza jednoczeœnie niekorzystne opóŸnienie. Druga czêœæ badañ obejmowa³a przeprowadzenie szeregu symulacji zwi¹zanych z multipleksacj¹ 3 lub 5 strumieni ró¿nych sekwencji filmowych MPEG. Celem tych badañ by³o sprawdzenie jak zmienia siê œrednia i maksymalna zajê toœæ bufora przy zadanej prêdkoœci kana³u CBR w przypadkach transmisji strumieni zgodnych oraz przesuniêtych w fazie. 4.1 Wp³yw szybkoœci ³¹cza CBR na wymagan¹ wielkoœæ bufora W celu zasymulowania rzeczywistego Ÿród³a MPEG-I w programie COMNET III stworzono 12 Ÿróde³ informacji tworz¹cych strukturê GOP. Ka¿de z tych Ÿróde³ by³o odpowiedzialne za generowanie ramki odpowiedniego typu (I, P, B) o odpowiedniej wielkoœci. Do tego celu do symulatora zosta³y wprowadzone rozk³ady czê stoœci wystêpowania ramek (histogramy) rzeczywistych fragmentów filmowych. Transmisja wszystkich ramek odbywa³a siê po ³¹czach o odpowiednio dobranych parametrach, tak by jak najwierniej odtworzyæ dzia³anie kodera. Struktura GOP by³a czasowo wyzwalana co 0.5s, natomiast ka¿da z ramek, zaczynaj¹c od ramki startowej – I by³a odpowiedzialna za wyzwalanie kolejnej ramki, tak by na wyjœciu kodera pojawia³a siê struktura: IBBPBBPBBPBB. Wyjœcie kodera posiada³o bufor o zmiennej wielkoœci, do którego do³¹czony by³ kana³ transmisyjny CBR o zadanych parametrach. Powy¿sz¹ sytuacjê przedstawia Rys. 5. Rys. 5. Symulowany model kodera wraz z kana³em w programie COMNET III. Szybkoœæ magistrali kodera zosta³a tak dobrana, by nawet najd³u¿sze ramki I zd¹¿y³y opuœciæ Ÿród³o przed pojawieniem siê nastêpnej w kolejnoœci ramki B. Produkowane obecnie kodery, budowane w oparciu o procesory DSP posiadaj¹ magistrale przesy³aj¹ce dane z prêdkoœci¹ przewy¿szaj¹c¹ 1 Gbit/s. Rozwa¿aj¹c jednak koder wewnêtrzny pracuj¹cy na karcie PCI komputera PC musimy liczyæ siê ze spadkiem prêdkoœci transmisji do oko³o 100 Mbit/s. Szybkoœæ umieszczania informacji w buforze zale¿y wiêc od zastosowanej platformy sprzêtowej. W pierwszej fazie przyjê to transmisjê ramek o sta³ej d³ugoœci, równej 400 oktetów. Wielkoœæ ta by³a wybrana pod k¹tem przysz³ego zastosowania multipleksacji statystycznej w sieci bezprzewodowej zgodnej ze standardem IEEE 802.11 [6]. W tym przypadku kana³ CBR oznacza kana³ o ustalonej i dedykowanej przepustowoœci dla transmisji strumienia MPEG. Sieæ IEEE 802.11 dopuszcza transmisjê ramek o zmiennej d³ugoœci. 800000 100 "LAMBS" 90 700000 80 wielkoœæ bufora [bajty] 70 500000 60 400000 50 40 300000 30 200000 wykorzystanie ³¹cza CBR [%] 600000 20 100000 10 380 370 360 350 340 330 320 310 300 290 280 270 260 250 240 230 220 210 200 190 180 170 160 0 150 0 szybkoœæ transmisji w kanale CBR [kbit/s] œrednia zajêtoœæ bufora maksymalna zajêtoœæ bufora wykorzystanie ³¹cza Rys. 6. Wykres œredniej i maksymalnej zajêtoœci bufora oraz wykorzystania ³¹cza w funkcji szybkoœci transmisji w kanale CBR dla sekwencji „LAMBS”. Z przeprowadzonych wczeœniej badañ wynika, ¿e stosowanie zarówno zbyt krótkich, jak i zbyt d³ugich ramek wp³ywa niekorzystnie na wydajnoœæ sieci. Stosowanie ramek bardzo krótkich prowadzi do niepotrzebnego nadmiaru spowodowanego obecnoœci¹ nag³ówka, co przek³ada siê w wiêkszym opóŸnieniu. Bardzo d³ugie ramki wymagaj¹ stosowania dzielenia ich na krótsze pakiety, co równie¿ wprowadza niekorzystne opóŸnienie. Wielkoœæ bufora zosta³a ograniczona do 1000000 bajtów. Czas symulacji by³ sta³y dla ka¿dej iteracji i wynosi³ 120s. 800000 100 "Mr. BEAN" 700000 90 wielkoœæ bufora [bajty] 70 500000 60 400000 50 300000 40 30 200000 wykorzystanie ³¹cza CBR [%] 80 600000 20 100000 10 800 780 760 740 720 700 680 660 640 620 600 580 560 540 520 500 480 460 440 420 0 400 0 szybkoœæ transmisji w kanale CBR [kbit/s] œrednia zajêtoœæ bufora maksymalna zajêtoœæ bufora wykorzystanie ³¹cza Rys. 7. Wykres œredniej i maksymalnej zajêtoœci bufora oraz wykorzystania ³¹cza w funkcji szybkoœci transmisji w kanale CBR dla sekwencji „Mr. BEAN”. 900000 100 "RACE" 90 800000 wielkoœæ bufora [bajty] 70 600000 60 500000 50 400000 40 300000 30 200000 wykorzystanie ³¹cza CBR [%] 80 700000 20 100000 10 œrednia zajêtoœæ bufora maksymalna zajêtoœæ bufora 1150 1130 1110 1090 1070 1050 1030 szybkoœæ transmisji w kanale CBR [kbit/s] 1010 990 970 950 930 910 890 870 850 830 810 790 770 750 730 0 710 0 wykorzystanie ³¹cza Rys. 8. Wykres œredniej i maksymalnej zajêtoœci bufora oraz wykorzystania ³¹cza w funkcji szybkoœci transmisji w kanale CBR dla sekwencji „RACE”. Druga faza badañ obejmowa³a transmisjê ramek ATM’owych (47 bajtów danych + 6 bajtów nag³ówka, zgodnie z AAL1). W kanale CBR transmitowany by³ 1 strumieñ „Mr. Bean”. Podczas symulacji przyjê to nastêpuj¹ce parametry: CIR=600 kbit/s, granica wybuchowoœci strumienia=160 kbit, przep³ywnoœæ GCRA1=10000 pakietów/s, granica wybuchowoœci GCRA1=1000 pakietów (parametr „granica wybuchowoœci” – burst limit - jest zdefiniowany jako wewnê trzne ustalenie w programie symulacyjnym COMNET i nie jest w³aœciwy dla standardu ATM). Czas symulacji by³ sta³y dla ka¿dej iteracji i wynosi³ 120s. Uzyskane wyniki zosta³y przedstawione na rys. 9. 80000 300 70000 250 200 50000 40000 150 30000 100 opóŸnienie [ms] zajêtoœæ bufora [bajty] 60000 20000 50 0 1000 960 920 880 840 800 760 720 680 640 600 560 520 0 480 10000 szybkoœæ transmisji w kanale CBR [kbps] œrednia zajêtoœæ bufora maksymalna zajêtoœæ bufora opóŸnienie Rys. 9. Wykres œredniej i maksymalnej zajêtoœci bufora oraz opóŸnienie transmisji w funkcji szybkoœci transmisji w kanale ATM-CBR dla sekwencji „Mr. BEAN”. 4.2 Multipleksacja oraz buforowanie strumieni MPEG Do przeprowadzenia wszystkich symulacji zwi¹zanych z multipleksacj¹ i buforowaniem kilku strumieni MPEG wykorzystano ponownie program COMNET III firmy CACI. Struktura pojedynczego strumienia MPEG by³a identyczna jak w przypadku badañ wp³ywu prêdkoœci ³¹cza na wymagan¹ wielkoœæ bufora. 12 Ÿróde³ informacji tworzy³o strukturê GOP. GOP by³o wyzwalane ka¿dorazowo co 0.5 sekundy. Ramka I ka¿dej z sekwencji filmowych rozpoczyna³a wyzwalanie kolejnych ramek (BBPBB...) tego samego GOP. Dodatkowo w przypadkach w których stosowano przesuniêcie fazowe sekwencji filmowych s³u¿y³a ona do wyzwalania kolejnych sekwencji filmowych. I tak np. ramka I pierwszej sekwencji filmowej wyzwala³a ze sta³ym opóŸnieniem ramkê B tego samego GOP oraz ramkê I sekwencji drugiej. W ten sposób wyzwalanie kolejnych Ÿróde³ zosta³o opóŸniane o czas trwania 1 ramki. (por. Rys. 10). I film 1 B B P B B P B B P B B I do kana³u CBR I film 2 B B P B B P B B P B B I B B P B B P B B P B film 3 czas multiplekser Rys. 10. Multipleksacja z przesuniêciem o 1 ramkê trzech filmów o 12-ramkowej strukturze GOP. Przeprowadzone badania podzielono na dwie fazy. W pierwszej fazie symulowano multipleksacjê 3 oraz 5 strumieni MPEG w kanale CBR, przy transmisji ramek o sta³ej d³ugoœci równej 400 oktetów. W odró¿nieniu od modelu poprzedniego wêze³ ONU posiada wiêkszy bufor oraz zapewnia z³o¿enie 3 sygna³ów w jeden strumieñ wprowadzany nastêpnie do kana³u CBR Pierwsza czêœæ symulacji wi¹za³a siê ze z³o¿eniem trzech identycznych strumieni wideo „Mr. BEAN”. Symulowano zarówno równoczesn¹ transmisjê wszystkich filmów, jak i transmisjê z rozsuniêciem czasowym. Czas przesuniêcia transmisji ka¿dej sekwencji odpowiada³ czasowi trwania 1 ramki. Kolejne symulacje ró¿ni³y siê rodzajem zastosowanego materia³u filmowego. Symulowano multipleksacjê trzech ró¿nych strumieni: „LAMBS”, „Mr. BEAN”, „RACE” zarówno bez jak i z przesuniêciem fazowym. Ostatnie badania ró¿ni³y siê liczb¹ multipleksowanych strumieni. Symulowano z³o¿enie 5 sekwencji filmowych „Mr. BEAN” w dwóch przypadkach: bez oraz z przesuniêciem fazowym. We wszystkich trzech przypadkach porównywano œredni¹ oraz maksymaln¹ zajêtoœæ bufora. Czas symulacji by³ sta³y dla ka¿dej iteracji i wynosi³ 120s. Wyniki symulacji zosta³y przedstawione kolejno na Rys. 11, 12, 13. 70000 wielkoœæ bufora [bajty] 60000 50000 40000 30000 20000 10000 2800 2720 2640 2560 2480 2400 2320 2240 2160 2080 2000 1920 1840 1760 1680 1600 1540 1500 1460 1420 0 szybkoœæ transmisji w kanale CBR [kbit/s] œr. zajêtoœæ bufora - brak przesuniêcia fazowego maks. zajêtoœæ bufora - brak przesuniêcia fazowego œr. zajêtoœæ bufora - przesuniêcie faz. o 1 ramkê maks. zajêtoœæ bufora - przesuniêcie faz. o 1 ramkê Rys. 11. Wykres œredniej i maksymalnej zajêtoœci bufora w funkcji szybkoœci transmisji w kanale CBR dla 3 zmultipleksowanych sekwencji „Mr. BEAN” bez przesuniêcia fazowego, oraz z przesuniêciem o 1 ramkê. 90000 80000 wielkoœæ bufora [bajty] 70000 60000 50000 40000 30000 20000 10000 3000 2920 2840 2760 2680 2600 2520 2440 2360 2280 2200 2120 2040 1960 1880 1800 1720 1640 1560 1480 0 prêdkoœæ transmisji w kanale CBR [kbit/s] œr. zajêtoœæ bufora - brak przesuniêcia fazowego maks. zajêtoœæ bufora - brak przesuniêcia fazowego œr. zajêtoœæ bufora - przesuniêcie faz. o 1 ramkê maks. zajêtoœæ bufora - przesuniêcie faz. o 1 ramkê Rys. 12. Wykres œredniej i maksymalnej zajêtoœci bufora w funkcji szybkoœci transmisji w kanale CBR dla 3 zmultipleksowanych sekwencji „LAMBS”, „Mr. BEAN” i „RACE” bez przesuniêcia fazowego, oraz z przesuniêciem o 1 ramkê. 120000 wielkoœæ bufora [bajty] 100000 80000 60000 40000 20000 4500 4400 4300 4200 4100 4000 3900 3800 3700 3600 3500 3400 3300 3200 3100 3000 2900 2800 2700 2650 2600 2550 2500 2450 2400 2350 0 szybkoœæ transmisji w kanale CBR [kbit/s] œr. zajêtoœæ bufora - brak przesuniêcia fazowego maks. zajêtoœæ bufora - brak przesuniêcia fazowego œr. zajêtoœæ bufora - przesuniêcie faz. o 1 ramkê maks. zajêtoœæ bufora - przesuniêcie faz. o 1 ramkê Rys. 13. Wykres œredniej i maksymalnej zajêtoœci bufora w funkcji szybkoœci transmisji w kanale CBR dla 5 zmultipleksowanych sekwencji „Mr. BEAN” bez przesuniêcia fazowego, oraz z przesuniêciem o 1 ramkê. W drugiej fazie przeprowadzono multipleksacjê 5 strumieni MPEG „Mr. BEAN” w kanale ATM-CBR bez przesuniêcia fazowego. Wszystkie parametry symulacji pozosta³y takie jak w przypadku transmisji pojedynczego strumienia w kanale ATM-CBR. Uzyskane wyniki zosta³y przedstawione na Rys. 14. 120000 200 180 160 140 80000 120 60000 100 80 40000 opóŸnienie [ms] wielkoœæ bufora [bajty] 100000 60 40 20000 20 4900 4700 4500 4300 4100 3900 3700 3500 3300 3100 2900 2700 0 2500 0 szybkoœæ transmisji w kanale CBR [kbps] œrednia zajêtoœæ bufora maksymalna zajêtoœæ bufora opóŸnienie Rys. 14. Wykres œredniej i maksymalnej zajêtoœci bufora oraz opóŸnienie w funkcji szybkoœci transmisji w kanale ATM-CBR dla 5 zmultipleksowanych sekwencji „Mr. BEAN”. 5. Podsumowanie Celem badañ by³o okreœlenie jak zmienia siê œrednia i maksymalna zajêtoœæ bufora w zale¿noœci od zmiany szybkoœci transmisji w kanale CBR zarówno dla pojedynczego strumienia jak i dla zmultipleksowanych kilku sekwencji MPEG. Nieznaczne przesuniêcie w fazie transmitowanych strumieni prowadzi do zmniejszenia maksymalnej zajêtoœci bufora, a w rezultacie do zmniejszenia wymaganej przepustowoœci w kanale CBR. Z uwagi na du¿¹ czasoch³onnoœæ przeprowadzanych symulacji ograniczono do piêciu maksymaln¹ liczbê multipleksowanych sekwencji filmowych. Z obserwacji wykresów uzyskanych w pierwszej czêœci badañ mo¿emy wyci¹gn¹æ nastêpuj¹ce wnioski: § Charakterystyczny jest tu punkt przegiêcia na wykresach, tj. wartoœæ szybkoœci transmisji w kanale CBR, przy której nastêpuje gwa³towny spadek œredniej oraz maksymalnej zajêtoœci bufora; § Zbyt du¿e zmniejszenie szybkoœci transmisji w kanale CBR prowadzi do powstania du¿ych opóŸnieñ w przekazie obrazu filmowego (nale¿y pamiê taæ o istnieniu po stronie odbiorczej du¿ego bufora); § W warunkach ograniczonych zasobów sieciowych (ma³a pojemnoœæ kana³u CBR) celowe jest ustawienie punktu pracy systemu w pobli¿u punktu przegiêcia. Prowadzi to powstania niekorzystnego opóŸnienia, pozwala jednak maksymalnie wykorzystaæ mo¿liwoœci zastosowanego ³¹cza (szczególnie istotne w przypadku dzier¿awy ³¹cza, lub te¿ wykorzystywania sieci o bardzo ma³ej przepustowoœci [6]). Druga czêœæ badañ dotyczy³a multipleksacji ró¿nych rodzajów strumieni filmowych: „LAMBS”, „Mr. BEAN”, „RACE”. Otrzymane wykresy pozwalaj¹ na wyci¹gniêcie nastêpuj¹cych wniosków: § Podobnie jak w pierwszej czêœci badañ spadek szybkoœci transmisji w kanale CBR prowadzi do wzrostu œredniej oraz maksymalnej zajêtoœci bufora. Charakterystyczny jest punkt przegiêcia, powy¿ej którego nastêpuje gwa³towny wzrost zajê toœci bufora. Otrzymane wyniki pokazuj¹, ¿e wykorzystanie procentowe ³¹cza CBR powy¿ej punktu przegiêcia wynosi 100% (nasycanie siê bufora); § Œrednia zajêtoœæ bufora dla multipleksacji zarówno 3 tych samych jak i ró¿nych strumieni filmowych jest nieznacznie mniejsza dla transmisji z przesuniêciem fazowym. WyraŸn¹ ró¿nicê widaæ dopiero przy multipleksacji wiêkszej liczby strumieni; § Przy multipleksacji strumieni bez przesuniêcia fazowego (nak³adanie siê w jednej chwili czasowej ramek typu I) niezale¿nie od wzrostu szybkoœci transmisji w kanale CBR obserwujemy sta³y poziom maksymalnej zajêtoœci bufora; § Dla du¿ych prêdkoœci transmisji w kanale CBR przy multipleksacji z przesuniêciem fazowym o jedn¹ ramkê obserwujemy znaczny spadek maksymalnej zajêtoœci bufora (do oko³o 50%). Potwierdza to dotychczasowe rozwa¿ania teoretyczne; § Transmisja wiêkszej liczby strumieni z przesuniêciem fazowym powoduje znaczne uœrednienie ruchu (zmniejsza siê wybuchowoœæ strumienia MPEG). Jest to widoczne w zmniejszaniu siê maksymalnej zajê toœci bufora; Wykorzystanie kategorii ruchowej CBR do transmisji „wybuchowego” ruchu typu MPEG jest skutecznym sposobem realizacji us³ugi VoD. Prostota definiowania parametrów kana³u CBR u³atwia negocjacje parametrów ruchowych pomiêdzy u¿ytkownikiem a operatorem sieci. Pozornie trudne jest w tym przypadku osi¹gniêcie du¿ej efektywnoœci transmisji. W istocie odpowiednie wyg³adzenie strumieni daje podobny efekt jak multipleksacja statystyczna strumieni VBR – podniesienie efektywnoœci systemu transportu informacji MPEG. Literatura [1] ISO-IEC / JTC1 / SC29 / WG11 / N0802. Generic coding of moving pictures and associated audio information: Video, November 1994. MPEG Draft Recommendation ITU-T H.262, ISO / IEC 13818-2 . [2] Krunz M., Tripathi S.: Scene-Based Characterization of VBR MPEG-Compressed Video Traffic. Department of Computer Science, University of Maryland. [3] Kuriacose J., Reininger D.: Source traffic smoothing for VBR MPEG encoders. Princeton, C&C ResearcFh Laboratories. [4] La Corte A., Lombardo A., Pallazo S.: Buffer compensation analysis for synchronization of multimedia services in wireless networks. University of Catania. [5] Lam S., Chow S., Yau D.: An Algorithm for Lossless Smoothing of MPEG Video. University of Texas at Austin. [6] Natkaniec M., Wajda K., Pach A.R.: Transmisja strumienia MPEG-I w sieci standardu IEEE 802.11 Katedra Telekomunikacji AGH, 1998. [7] Pacyna P. Dystrybucja strumieni MPEG w sieciach szerokopasmowych. Sprawozdanie z Projektu Badawczego 456/T11/97/12, 1998. [8] Reininger D.: Variable Bit Rate MPEG Video: Characteristics, Modeling and Multiplexing. C&C Research Laboratories. [9] Rose O.: VBR video traffic. COST242 Closing Seminar, June 4-5, 1996. [10] Rose O.: Discrete-time Analysis of a Finite Buffer with VBR MPEG Video Traffic Input. Report No. 150 University of Würzburg, Institute of Computer Science, 1996. [11] Sen S., Dey J., Kurose J., Stankovic J., Towsley D.: Online smoothing of live video transmissions. University of Massachusetts. [12] Vitter J., Hoang D.: Multiplexing VBR Video Sequence onto a CBR Channel with Lexicographic Optimization. Duke University, Digital Video Systems Inc. [13] Wajda K., Pacyna P. Statystyczne w³aœciwoœci strumienia MPEG i ich wp³yw na realizacjê us³ug multimedialnych. KST’97, Bydgoszcz 1997. [14] ATM Forum, BTD-SAA-AMS-VBRMPEG2-02.02, VBR MPEG-2 - Baseline Text, Anaheim, February 1998.
