Optimalizace metod pro multimediální aplikace v geodézii v prostředí IP sítí

Transkript

1 Acta Montanstca Slovaca Ročník 12 (2007), mmoradne číslo 3, Optmalzace metod pro multmedální aplkace v geodéz v prostředí IP sítí Mlan Berka 1 Optmzaton of Methods for Geodetc Data for Multcast n IP Networks Ths paper deals wth possbltes of usng RTP and RTPC protocols for defnng dfferent schemes of broadcast multmeda multplex and ways of ts dstrbuton n telecommuncaton networks. The effectveness of dfferent varants of sgnal dstrbuton s compared through ths smulaton experment. Some defned tasks, whch could be eventually solved n ths area, are also presented. A smulaton s appled to theoretcal and real networks and the results on each partcular network could dffer sgnfcantly. Key words: Multcast, uncast, control herarchy, system smulaton, RFC 1350, RFC 1351, optmzaton technques, sgnal dstrbuton, multmeda multplex. Úvod Není daleko doba, kdy poměrně velké množství užvatelů bude moc současně využívat nformace o terénu a objektech na něm v reálném čase. Jednou současnou aplkací, která poskytuje alespoň představu o tom, jak by to v budoucnu mohlo vypadat je Google Earth. Z pohledu geodetckých potřeb je to ovšem dle mého názoru v současné době sce efektní, ale stále pouze dětská hračka. Možná moje představy jsou v této oblast trochu podobné Sc-F, ale promítání změn do map a modelů terénu v reálném čase a jejch získávání také v reálném čase dříve nebo pozděj bude realtou. Dnes považujeme za úspěch stažení souboru prostřednctvím sítě, zítra možná, se budeme pohybovat nad terény v 3D v reálném čase. V této oblast exstují některé docela zajímavé práce např. Toursm nformaton based on vsualsaton of multmeda geodata ReGeo, kolektvu Department Remote Sensng and Landscape Informaton Systéme a Albert-Ludwgs-Unversty Freburg.Brsg., Germany, když daná tématka nějak v roce 200 usnula Současný stav MPEG-1 Standard MPEG byl vyvnut na základě požadavku průmyslu, který potřeboval kvaltní způsob ukládání a získávání audo a vdeo nformací na dgtální záznamová méda (Dgtal Storage Meda DSM). CD-ROM je levný nosč poskytující přenosovou rychlost přblžně 1.2 Mbps. MPEG standard byl vyvíjen s cílem dosáhnout podobnou přenosovou rychlost. "Constraned Parameters btstream" (datový rok s omezeným parametry), jsou podmnožna všech přístupných btových toků, u kterých se očekává, že budou šroce využívány. Jsou omezeny na datovou rychlost až do Mbps. Ncméně je třeba podotknout, že standard není omezen jen touto hodnotou, a že může být použt pro vyšší datové rychlost. Během práce na standardu MPEG vdea byly vyvnuty další dva závažné meznárodní standardy: H.261 od společnost CCITT zaměřený na telekomunkační aplkace a ISO od výboru ISO JPEG zaměřený na kódování obrázků. Základy obou těchto standardů byly začleněny do standardu MPEG Vdea, ale výsledkem další práce výboru byly prvky, které nebyly obsaženy an v jednom z výchozích standardů (H.261 a ISO 10918). Standard MPEG Vdeo defnuje formát pro kompres dgtálního vdea a možnost, jak může být vdeo kódováno a dekódováno. Ačkolv je tento standard flexblní, základní algortmy byly laděny tak, aby dobře pracovaly v datové rychlost od 1 do 1.5 Mbps, př rozlšení okolo 350 x 250 a snímkovací frekvencí mez 2 a 30 snímky. Použtí slova "obraz", jako protklad ke slovu "rám", je záměrné. Kódy MPEG Vdea postupně snímají vyobrazení a nerozpoznávají způsob proplétání. Prokládané místo vdea musí být před kódováním převedeno na neprokládaný formát. Po dekódování může dekóder lbovolně vytvořt pro zobrazení nějaký prokládaný formát. Standard MPEG Vdea je navržen k povolení několka metod, aby sledovaly kódování vdea, které normálně souvsí s VCR: přehrávání, pozastavení obrazu, rychlé převíjení vpřed, rychlé převíjení zpět 1 doc. RNDr. Mlan Berka, CSc., GTS Novera a.s., Výstavště 1, BRNO,, tel.: ,Česká Republka, Mlan.Berka@gtsnovera.cz (Recenzovaná a revdovaná verza dodaná ) 311

2 Mlan Berka: Optmalzace metod pro multmedální aplkace v geodéz v prostředí IP sítí a zpomalené přehrávání. Navíc je možný lbovolný přístup. Schopnost dekóderu realzovat tyto režmy záleží na rozsahu povahy dgtálního paměťového méda, ve kterém je zakódované vdeo uloženo. MPEG vdeo - kompresní technky Vdeo je představováno jako posloupnost jednotlvých obrázků, a každý obraz je považován za dvojrozměrné pole obrazových prvků (pxelů). Barva každého pxelu se skládá ze tří složek: hodnoty Y (jasu) a dvou barevných složek. Komprmace dgtalzovaného vdea je možná díky několka technkám: vzorkování barevné nformace vzhledem k ctlvost ldského zraku, kvantzac, kompenzac pohybu (Moton Compensaton), transformac frekvence pomocí dskrétní kosnové transformace (Dscrete Cosne Transform - DCT), kódování VLC (Varable Length Codng) a obrazové nterpolac. MPEG-2 Defntvní schválení ISO/IEC (MPEG-2 systémy), ISO/IEC (MPEG-2 vdeo) a ISO/IEC (MPEG-2 Audo) jako meznárodních standardů, bylo dáno 29. setkáním ISO/IEC JTC1/SC29/WG11 (MPEG), konaném v Sngapuru v lstopadu 199. MPEG-2 koncepce je podobná jako u MPEG-1, ale zahrnuje zaměření na šrší použtelnost. Základní aplkace je zaměřena na plně dgtální přenos vdea v přenosových rychlostech mez a 9 Mbps. Ncméně bylo zjštěno, že syntaxe MPEG-2 nachází uplatnění také pro aplkace s vyšší vzorkovací frekvencí a btrate (jako např. HDTV). Nejvýraznějším zlepšením, oprot MPEG-1, je přdání syntaxe pro účnné kódování prokládaného vdea (např. kompenzace pohybu pro bloky 16x8, Dual Prme, a další). Mnoho dalších jemných zlepšení (jako např. 10 btová dskrétní kosnová transformace s dvojtou přesností, nelneární kvantzace, tabulky VLC kódování a další) přspívá ke zlepšenému výkonu kódování a to dokonce pro progresvní vdeo. Dalším klíčovým vlastnostm standardu MPEG-2 jsou rozšřtelné dodatky, které umožňují dělení kontnuálního vdeo sgnálu do dvou nebo více kódovaných datových toků, které mohou reprezentovat vdeo s různým rozlšením, kvaltou obrazu nebo snímkovací frekvencí. MPEG- Na rozdíl od *.MPG, žádný souborový formát *.MPEG neexstuje. Tedy otázka: Jak s vytvořím MPEG- soubor? nemá smysl. Lze vytvořt soubor AVI, ve kterém je obraz zkomprmován technkou MPEG-. MPEG- je mnohem varablnější formát pro kompres pohyblvých obrázků, než jakým je MPEG-1. Na rozdíl od MPEG-1 může mít téměř lbovolné rozměry obrazu, počet snímků za sekundu a vzdálenost mez klíčovým snímky (KeyFrame, IFrame). Navíc nemá pouze konstantní datový tok (CBR: constant btrate), ale proměnný datový tok (VBR: varable btrate), což snžuje výslednou velkost vdea. Co však MPEG- nemá, je šroká podpora výrobců stolních DVD/VCD přehrávačů. To znamená že v tuto chvíl pro MPEG- vdeo neexstuje žádný CD standard. Tudíž an není možné říc jaký formát mají mít CD ve formátu MPEG- a tedy je nemožné taková CD ve stolních přístrojích přehrávat, pokud ovšem tyto zařízení nejsou vlastně PC Problémy Z hledska technologe přenosu je třeba říc, že rozumným způsobem pro žvé vysílání je využtí protokolů IP, nad ním protokolu UDP a nad ním pak protokolu RTP/RTPC [3]. Z hledska způsobu dstrbuce sgnálu k odběratelům (klentům) se pak rozlšuje především uncast a multcast. Uncast př vysílání z jednoho zdroje je slně omezen kapactou přenosové trasy. Např. př vysílání se šířkou pásma 2 Mbps pro jednu relac se kapacta spoje u vysílacího serveru př klentech vyšplhá na úctyhodných 2 Gbps, což je běžná kapacta jednoho optckého vlákna. Je třeba s také uvědomt, že pro dgtální kvaltu 2 Mbps není použtelná šířka pásma, ale spíše 10-20x tolk Z tohoto pohledu uncast, který by docela dobře splňoval požadavky na možnost zabezpečení přenosu od vysílače ke klentov, se jeví jako perspektvně nepoužtelný. Protože ke každému klentov jde separátní kanál, není problém tento kanál šfrovat č proudově podepsovat. Přtom podepsování žvého proudového vysílání není zase až tak trvální záležtost (protože př příjmu sgnálu a jeho zobrazení máme vždy k dspozc pouze kousek celé nformace). Je to věc ovšem řeštelná. Problém s omezeným počtem užvatelů je problém zásadní. Exstuje celkem známá cesta, jak z tohoto problému ven. Tou cestou je použtí technologe multcastu, kde z vysílacího serveru jde pouze jeden proud dat a ten se postupně na jednotlvých směrovačích rozvětvuje 312

3 Acta Montanstca Slovaca Ročník 12 (2007), mmoradne číslo 3, ke klentům. Díky této technolog se zátěž páteřní sítě nezvyšuje s narůstajícím počtem klentů. Mohlo by se zdát, že problém je vyřešen. Mmo uncast a multcast exstuje ještě technologe broadcast v této oblast je zajímavá publkace Locaton-Based Geodata Broadcast, kde jsou popsány technologe Terrestral dgtal vdeo broadcast DVB (DVB-T) pro lokalzac pohybujících se objektů. Systém postupného zjemňování mapových podkladů ukazuje následující převzatý obrázek Obr.1. Zjemňování lokalzačních map. Pc.1. Transton to detaled map. Exstují technologe, které umožňují postupné zjemňování přechodu mez jednotlvým měřítky a odpovídající technologe pro přesnost takovýchto dat. Vznkají však některé další problémy (vz [1]): 1. Není možné jednoduše zabezpečt trasu mez serverem a zvláště každým klentem. 2. I pro protokol RTP/RTPC exstují množstevní omezení pro počet klentů, nad kterým se výrazně omezí dostupnost vysílání pro multcast. Toto s ukážeme níže. Pro protokol RTP exstuje také bezpečná varanta a to protokol SRTP (Secure Real-tme Transport Protocol), který je upraven prostřednctvím standardu RFC V tomto případě jde vlastně o zašfrování určté porce dat v rámc paketu defnovaného dle RFC V normě je šfrování defnováno prostřednctvím 128 btových bloků AES-f8. Zpětnou sgnalzac pak provádí analogcky zabezpečený protokol SRTPC. Mandatorně je používán AES-CM pro šfrování, HMAC-SH1 pro ntegrtu a AES-CM pro odvozené klíče. V každém fxním proudu může být klíč použt maxmálně jedenkrát. Master keys mohou být použty napříč streamy. Tímto způsobem je bezpečnost lmtována. Př rychlost např. 200 SRTPC paketů za sekundu je maxmální možná doba streamu as měsíce. Protokol může být použt př ochraně prot opětovnému přehrávání auda nebo vdea. 3. Dalším rozšířením protokolu SRTP je pak protokol ZRTP, který k defnc v normě přdává mechanzmy pro počáteční výměnu klíčů. Produkt, který využívá tuto technolog je např. ZPHONE. Reálně to funguje tak, že pod vlastní VoIP je vnořena vrstva (něco jako SSL PROXY), která zajšťuje bezpečnost. Toto je ovšem řešení spíše pro systémy komunkace jeden s jedním.. Nefunguje rozumný přenos multcastu mez operátory, takže můžeme předpokládat, že dané vysílání uvdíme pouze u svého poskytovatele přpojení, pokud je bude poskytovat. Nějaké celo Internetové multcastové vysílání nebude možné bez další specfkace přenosových technologí a standardů 5. Není rozumně možné ndvduálně zabezpečt přenos sgnálu zvlášť pro každého klenta. Vydání stejného klíče všem klentům není zrovna nejlepší řešení zabezpečení. Na takto zabezpečené sateltním vysílání vyrostl celé generace hackerů a celý průmysl, který se zabývá prolamováním ochrany šfrovaných kanálů Možná řešení Aby dopad multmedálního vysílání zcela neparalyzoval nfrastrukturu, je pochoptelně třeba použít něco jného než uncast. Možná není v sítích mplementováno odpovídající řešení, ale teoretcký problém v této oblast není. Řešením je zde SSM - Specfc Source Multcast, ale pouze v oblast šíření datového obsahu. Exstují však jné problémy. Ty spočívají v samotném protokolu RTP/RTPC, kde dle defnce zpětné odezvy protokolu, kterou se např. poskytují nformace o kvaltě přeneseného sgnálu, vychází, že podle klasckých vzorců dle RFC 1350 a 1351 je nterval reportu přímo úměrný počtu klentů. Např. př dvácích (což pro klascké televzní vysílání není žádné velké číslo) bude tento nterval už 33 mnut. Kromě modulace kvalty však tento protokol může sloužt ke zprostředkování nteraktvní zpětné vazby. Např. Ovlvnění 313

4 Mlan Berka: Optmalzace metod pro multmedální aplkace v geodéz v prostředí IP sítí obsahu streamu, což pro oblast geodeze a mapových nformací může být záležtost zásadního významu. Taková odezva je praktcky nepoužtelná. Exstuje několk možných řešení tohoto problému. Jednou je modfkace šíření sgnálu o koncentrac zpětných vazeb na síťových prvcích. Tato cesta má některá úskalí. Ta spočívají v tom, že síťový prvek by musel řešt řadu úloh, které mu nejsou vlastní, muselo by dojít k mplementac těchto algortmů výrobcem apod. Z krátkodobého hledska se jedná o dostatečně neprůchozí varantu. Druhou varantou je, že rol koncentrátora zpětného toku převezmou někteří klent. V takovém případě, velm zjednodušeně řečeno, vznkne jakás reverzní stuace k technolog CDN. To vyžaduje malou úpravu protokolu, ale teoretcká rychlost odezvy pro klentů klesne z výše uvedených 33 mnut na cca 30 sekund a to je snížení docela podstatné. Pro klentů pak teoretcky klesne z úctyhodných 5 hodn na 50 sekund. Vývoj nárůstu potřeby páteřní kapacty ukazuje následující graf, ze kterého je zřejmé, že př zátěž koncových lnek užvatelů je potřeba růstu kapacty páteře př SSM multcastu mnmální. Rostoucí křvka odpovídá uncastu. kbps Summary BackBone traffc Clents Strategy 1 Strategy 2 Strategy 3 Obr. 2. Růst zátěže sítě. Pc. 2. Accumulaton of network traffcs. Následující dva grafy srovnávají nterval odezvy pro klascké RTP/RTPC s metodou agregace ve dvou herarchckých úrovních. Otázka vhodného počtu úrovní pro optmální odezvu je momentálně otázkou teoretcké analýzy. Z hledska praktcké použtelnost se do klentů jeví počet dvou úrovní dostatečný. Klascké schéma dle RFC 1350, 1351 vypadá následovně: Tab. 1. Odezvy. Tab. 1. Response tmes. Počet klentů Sekund odezvy Mnut odezvy Hodn odezvy 10 0, , , , , , Klascké RTP/RTPC Odezva v s Počet klentů Obr. 3. Závslost odezvy na počtu klentů. Pc. 3. Dependences between clents and the response tme. 31

5 Acta Montanstca Slovaca Ročník 12 (2007), mmoradne číslo 3, Př použtí herarche se stuace dost podstatně vylepší. Následující tabulka ukazuje pouze dvouúrovňovou herarch. V této struktuře se dokonce dá podle požadované odezvy navrhnout potřebná herarche. I v případě, kdy se nesnažíme nějak mnmalzovat dobu odezvy, je vdět, že stuace je rozhodně optmstčtější. Tab. 2. Odezvy př herarch druhé úrovně. Tab. 2. Response tmes n the two level model. Počet klentů Počet uzlů Počet respondentů ve skupně Sekund odezvy , , Stuace je dost podobná technolog CDN, ale jaks v reverzní podobě. Uzly nerozdělují tok dat, ale naopak jej ntegrují. Případně se to dá chápat jako P2P naopak. Herarchcká varanta odezva v s Počet klentů Obr.. Odezvy př herarch druhé úrovně. Pc.. Response tmes n the two level model. Co říc k obsahu tohoto obrázku? Možná jenom to, že an multcast sám o sobě není schopen řešt problém velkého počtu respondentů multmedálního vysílání. Metody, které v této oblast nastupují, v mnohém přpomínají metody řešení problémů s pomocí neuronových sítí [2]. Analytcké řešení Mmo smulace sítí je možné popsat řadu parametrů protokolu RTP/RTPC matematcky [] a dobrat se k podobným výsledků Rychlost. Odezva PočetKlentů = ; VelkostPaketu Z tohoto vzorce pak můžeme bez problémů vyjádřt dobu odezvy a získat hodnotu, která byla uvedena v předchozí tabulce x = ; x=1963 s = 33 mnut; Teoretckým řešením je, jak bylo uvedeno jž výše, použtí herarche. Pro zjednodušení řešení přjmeme některé předpoklady. V podstatě ne všchn klent budou odesílat nformace serveru, ale nformace budou sdružovány po skupnách a budou exstovat specalzovaní klent, kteří nformace budou slučovat a odesílat dále. Budeme předpokládat, že: skupny mají stejný počet členů, odezvy všech skupn a všech klentů jsou stejné, délky všech paketů protokolu RTPC jsou stejné, strom herarche je vyvážený. 315

6 Mlan Berka: Optmalzace metod pro multmedální aplkace v geodéz v prostředí IP sítí V takovém případě bude platt následující vzorec Rychlost PočetKlen tů =. X VelkostPa ketu ; Následně doba odezvy jedné skupny klentů v herarch se dá vyjádřt následujícím způsobem X = PočetKlentů. ; A následně celková doba odezvy ode všech klentů k centrálnímu serveru bude vypadat následovně X =. PočetKlentů. ; Problém tohoto vzorce je ten, že obsahuje parametr, který odpovídá úrovn herarche.možná ust se zjstt, zda exstuje něco, jako je optmální úroveň herarche pro daný fxní počet klentů. Jným slovy je třeba najít hodnotu optmálního a to 0 0 = Arg mn. PočetKlentů. ; Pokud s odmyslíme konstanty, které na hodnotu argumentu mnma nemají vlv, pak vlastně hledáme mnmum parametrcké funkce A řešením je hodnota ( ) f =. n ; ( n) 0 = ln ; Optmální úrovně herarche jsou uvedeny v následující tabulce Počet klentů Tab. 3. Optmální úrovně dle počtu klentů. Tab. 3. Optmal levels of herarchy. Optmální úroveň herarche Docela poučné může být zjštění, jak se s úrovní herarche obecně mění velkost odezvy a zhodnott, zda řízení herarchckých úrovní stojí za přínos v oblast odezvy protokolu. Mnma jsou označeny slně a rozumné hodnoty jsou zvýrazněny šedým pozadím. Mnma jsou totž velm plytká a jejch dosažení bude náročné z hledska řízení celé struktury herarche. Stuace velm přpomíná stuac, která funguje v p2p sítích, ale jaks naopak, zde prostřednctvím takové herarche se nešíří obsah, ale sbírají se zpětné nformace o vysílání od klentů k vysílacímu serveru. Pochoptelně tato stratege je použtelná, ale vyžaduje odpovídající úpravu protokolu RTP/RTPC a specálně vytvořené klenty, z nchž někteří budou plnt rol sumarzačních center. Plánování takových služeb není jednoduché a bude vyžadovat logku podobnou fungování výměnných sítí. Tuto stuac zobrazuje následující tabulka. 316

7 Acta Montanstca Slovaca Ročník 12 (2007), mmoradne číslo 3, Tab.. Mnma a rozumný komproms. Tab.. Mnmum of response tme and a ratonal compromse between the response tme and the levels of herarchy. Herarche/ počet klentů X X X X X Lteratura - References [1] Berka, M. a kol.: Bezpečná počítačová síť, Verlag Dashofer, Praha, 200 (doplněné vydání 2006), 1230 str. [2] Berka, M.: The Optmalzaton of Metods for Multcast n IP Networks, Konference for Management,Economcs and Busness Development n the New European Condtons, Brno, 2006, p [3] Perkns, C.: RTP Audo and Vdeo for the Internet, Addson-Veslay, New York, 2005, 1 str. [] Fletcher, R.: Practcal Methods of Optmzaton, Wley, New York, 1987, 36 str. 317