HIERARCHICKÝ PŘENOS SIGNALIZACE PRO MULTICAST V IP SÍTÍCH HIERARCHICAL FEEDBACK AGGREGATION FOR MULTICAST IN IP NETWORKS

Transkript

1

2 VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ Ústav telekomunikací Ing. Dan Komosný, Ph.D. HIERARCHICKÝ PŘENOS SIGNALIZACE PRO MULTICAST V IP SÍTÍCH HIERARCHICAL FEEDBACK AGGREGATION FOR MULTICAST IN IP NETWORKS TEZE HABILITAČNÍ PRÁCE v oboru TELEINFORMATIKA Brno 2009

3 Klíčová slova: multicast, IP, RTCP, Vivaldi, IPTV Keywords: multicast, IP, RTCP, Vivaldi, IPTV Práce je k dispozici na Vědeckém oddělení děkanátu FEKT VUT v Brně, Údolní 53, Brno, Dan Komosný, 2009 ISBN ISSN

4 OBSAH 1 ÚVOD PŘENOS MULTIMÉDIÍ V IP SÍTÍCH POMOCÍ KOMUNIKACE TYPU MULTICAST Komunikace typu unicast a multicast Druhy přenosu typu multicast Multicast s různými zdroji dat Multicast se specifickým zdrojem dat PŘENOS SIGNALIZACE PRO MULTICAST SE SPECIFICKÝM ZDROJEM DAT Vymezení aktuálního problému s přenosem signalizace Hierarchická agregace NÁVRH PŘENOSU SIGNALIZACE POMOCÍ HIERARCHICKÉ AGREGACE V IPTV Systém IPTV s přenosem signalizace pomocí hierarchické agregace Organizace prvků systému IPTV do signalizačních skupin podle relativní polohy Sestavení stromu pro přenos signalizace pomocí hierarchické signalizace Princip sestavení stromu Definice parametrů metriky pro nalezení signalizačního serveru Protokol TTP pro organizaci stromové struktury ZÁVĚR

5 AUTOR Ing. Dan Komosný, Ph.D. Datum a místo narození: , Hodonín Kontakt: ÚTKO, FEKT, Vysoké učení technické v Brně, Purkyňova 118, , Brno, komosny@feec.vutbr.cz VZDĚLÁNÍ Fakulta elektrotechniky a informatiky, VUT v Brně, obor Elektronika a sdělovací technika Doktorské studium na Fakultě elektrotechniky a komunikačních technologií, VUT v Brně, obor Teleinformatika. PROFESNÍ PRAXE Programátor-analytik, Herman elektronika dosud Odborný asistent, Fakulta elektrotechniky a komunikačních technologií, VUT v Brně. ODBORNÉ ZAMĚŘENÍ síťové operační systémy, komunikace v IP sítích, technologie IPTV, senzorové sítě. 4

6 1 ÚVOD V IP (Internet Protocol) sítích jsou pro přenosy dat používány rozdílné typy komunikace, přičemž mezi základní patří unicast a multicast [1], [2]. Unicast vychází z prvotní myšlenky IP protokolu, která je charakterizována přenosem od jednoho zdroje k jednomu příjemci. Pro různé druhy aplikací však tento typ komunikace vždy nevyhovuje. Příkladem může být přenos sdělovacích médií pomocí sítě Internet (např. vysílání televizních stanic), jelikož je zde požadován přenos od jednoho zdroje k více příjemcům oproti původnímu typu komunikace, kde byl jeden zdroj a jeden příjemce. Pokud by zde byla použita komunikace typu unicast, muselo by být vytvořeno tolik samostatných spojení od zdroje dat, kolik je příjemců. Tato situace by byla přijatelná pouze v případě, kdy je příjemců málo. S jejich rostoucím počtem, který může narůstat až do řádu statisíců, se komunikace typu unicast stává nepoužitelnou z důvodu neúměrných požadavků na síťové prostředky. Tuto situaci řeší komunikace typu multicast, která umožňuje vysílat data pouze jednou s tím, že kopie vyslaných dat 1 jsou doručeny všem příjemcům náležících do předem definované skupiny. S nasazením komunikace typu multicast však přichází větší nároky na režii pro zajištění vlastního přenosu [3]. Například se jedná o problém adresace skupin příjemců z důvodu velmi omezeného adresního prostoru vyčleněného pro tento typ komunikace nebo zajištění směrování dat pouze do směrů 2, kde se nacházejí příjemci náležící k dané skupině. Multicast tedy obecně umožňuje úsporu síťových prostředků pro tyto dva případy: kdy je více zdrojů a více příjemců a kdy je jeden zdroj a více příjemců. Přitom pro první případ je využíván druh komunikace typu multicast označovaný jako ASM (Any Source Multicast) [4] a pro druhý případ je využíván multicast SSM (Source-Specific Multicast) [5], [6] a [7]. Při přenosu ASM musí být síť schopna rozlišovat, kdo je zdroj dat. Pokud příjemce projeví zájem o připojení do již existující skupiny pro komunikaci typu multicast, musí síť určit všechny potenciální zdroje a jejich data dopravit k novému příjemci. Tento mechanizmus vytváří z ASM velmi složitý a obtížně realizovatelný způsob komunikace. Pro nasazení ASM je proto nutno vytvořit složitou strukturu směrování. Tento způsob přenosu je vhodný například pro on-line hry, hlasové a video konference, sdílení elektronických tabulí tj. v případech, kdy se účastníci střídají jako zdroje a příjemci dat. V blízké budoucnosti se předpokládá rozšíření služeb (např. přenos sdělovacích médií pomocí sítě Internet), u kterých bude výhodnější využít multicast SSM. Způsob přenosu SSM je modifikací ASM a lze jej použít pouze v případě, kdy lze definovat zdroj dat, který zůstává vždy stejný. Konkrétním příkladem může být přenos televize pomocí Internetu IPTV (Internet Protocol Television). SSM se vyznačuje relativní protokolovou jednoduchostí a snadnějším směrováním ve srovnání s ASM. Při vysílání typu multicast je potřeba zajistit i přenos signalizace svázané s vlastním přenosem. Tato signalizace je využívána například pro synchronizaci různých datových toků (video a audio), monitorování parametrů přenosu (ztrátovost paketů, kolísání zpoždění při přenosu paketů, atd.) či jako vstupní parametry pro další navazující systémy (korekční algoritmy pro zvýšení spolehlivosti přenosu, vysílání pomocí vrstev pro řešení problému heterogenity příjemců, atd.). U přenosu signalizace však nastává problém, který lze charakterizovat potřebou multimediální data přenášet od jednoho zdroje k více příjemcům a signalizaci přenášet od více příjemců k jednomu zdroji. Velkou nevýhodou SSM je nemožnost komunikace typu multicast v tomto zpětném směru, pomocí které by bylo možno zajistit přenos signalizace od všech příjemců k zdroji dat. Konkrétně se tato nevýhoda projeví při použití protokolových prostředků pro přenos multimédií v IP sítích. 1 Kopie dat vytváří síťové prvky označované jako směrovače. 2 Směrování provádí opět síťové prvky označované jako směrovače. 5

7 Současným základem pro přenos multimédií je protokol RTP/RTCP (Real Time Protocol/Real Time Control Protocol) [8], [9], kde protokol RTP je určen pro přenos multimediálních dat a protokol RTCP je určen pro přenos signalizace svázané s tímto multimediálním přenosem. Jelikož multicast SSM poskytuje pouze jednosměrné spojení zdroje k příjemcům, není možný přenos zpráv protokolu RTCP, který vyžaduje komunikaci mezi všemi stanicemi navzájem (tj. všechny stanice se střídají jako zdroje dat). Současná řešení spočívají v použití komunikace typu unicast pro přenos této signalizace (tedy pro přenos zpráv protokolu RTCP). Tyto metody však řeší celou problematiku jen částečně. Neřeší řadu základních problémů, mezi které patří především optimální využití dostupné přenosové kapacity. Tato vlastnost se výrazně projeví při velkém počtu účastníků, kdy může docházet k zahlcení přenosových prostředků sítě přenosem signalizace a tím způsobit zhoršení parametrů vlastního multimediálního přenosu. Komunikace mezi jedním zdrojem dat a více příjemci má v blízké budoucnosti předpoklady pro prudký rozvoj. U SSM je tedy potřeba nalézt nové způsoby zajištění přenosu signalizace, které by umožnily rapidní redukci komunikace typu unicast ve směru od příjemců ke zdroji a mezi příjemci navzájem. Výzkumu v oblasti SSM je ve světovém měřítku věnována velká pozornost. Aktuální dosažené výsledky výzkumu pro zavedení nových metod do SSM a do současného protokolového vybavení pro přenos multimédií jsou v současné době v procesu standardizace (tzv. Internet Draft) u organizace IETF (Internet Engineering Task Force), viz [10] 3. Tato práce rozvíjí náměty převážně publikované právě v dokumentu [10]. Hlavním cílem této práce je navrhnout optimální způsob přenosu signalizace pro velké počty příjemců tak, aby data této signalizace byla přenesena od všech příjemců ve velmi krátkém čase. Práce je přitom zaměřena na technologii IPTV, u které se takové velké počty příjemců předpokládají. Pro vysílání IPTV je v této práci uvažován přenos pomocí protokolů RTP/RTCP a pomocí komunikace typu multicast SSM [11], [12] a [13]. V současné době je přenos signalizace od koncových zařízení v systémech IPTV řešen na základě výzvy (v určitých případech se ovšem používá i případ komunikace zahájené koncovým zařízením). Samotný přenos je řešen například pomocí protokolu CPEWMP (CPE WAN Management Protocol) [14]. Tento protokol byl primárně navržen pro správu systémů DSL (Digital Subscriber Line). Mezi funkce, které tento protokol poskytuje, spadá například autokonfigurace, upgrade software/firmware a také monitorování stavu a běhu zařízení. Poslední funkci monitorování stavu a běhu zařízení lze právě využít pro přenos signalizace. Tento protokol však neumožňuje přenos signalizace v krátkém čase, což zabraňuje některým navazujícím systémům (např. korekční algoritmy pro zvýšení spolehlivosti přenosu) využívat tuto signalizaci z důvodu její neaktuálnosti. Navrhované řešení popsané v této práci spočívá v několika dílčích částech. Nejprve je navržen způsob přenosu signalizace v systémech IPTV pomocí hierarchické agregace. Po tomto návrhu následuje řešení problému organizace prvků systému IPTV do stromové struktury, která je nutná pro realizaci hierarchické agregace. V této stromové struktuře jsou vytvářeny skupiny příjemců (tzv. signalizační skupiny), které zasílají signalizaci prvku nazvanému signalizační server. Tyto signalizační servery tvoří také signalizační skupiny, které zasílají signalizaci dalšímu signalizačnímu serveru postavenému o úroveň výše v topologii stromu. Výsledkem navrženého řešení organizace příjemců a signalizačních serverů do signalizačních skupin je distribuovaný algoritmus, který je prováděný nezávisle na každém prvku systému IPTV. Tento algoritmus spočívá v tom, že každý takový prvek si vyhodnocuje metriku tvořenou několika zvolenými parametry. Pomocí této vypočtené metriky pak zvolí vhodný signalizační server pro zasílání signalizace. Po teoretické formulaci způsobu přenosu signalizace s přihlédnutím k reálným podmínkám sítě Internet byl dále 3 V době vytvoření této práce se jednalo již o 17. verzi. 6

8 proveden návrh komunikačního protokolu nazvaného TTP (Tree Transmission Protocol). Účelem tohoto protokolu je zajištění přenosu informací mezi prvky IPTV systému pro jejich organizaci do stromové struktury tak, aby byl umožněn přenos signalizace pomocí hierarchické agregace. Při návrhu tohoto protokolu byl kladen důraz na jeho univerzálnost (tj. nezávislost na dalších specifických protokolech pro multimediální přenosy). 2 PŘENOS MULTIMÉDIÍ V IP SÍTÍCH POMOCÍ KOMUNIKACE TYPU MULTICAST V IP sítích známe následující čtyři typy komunikace z pohledu počtu příjemců [15]: Komunikace typu unicast, kde jsou data zasílána pouze jednomu příjemci. Komunikace typu broadcast, kde jsou data zasílány všem stanicím v rámci jedné domény pro všesměrové vysílání (tzv. broadcast domain). Tato doména je tvořena všemi stanicemi a jinými síťovými zařízeními, kterým lze zaslat rámec s cílovou všesměrovou adresou definovanou na linkové vrstvě RM (referenční model) OSI (Open Systems Interconnection) [16]. Tento typ komunikace bývá často využíván pro komunikaci se stanicemi, pro které není známa jejich IP adresa. Příkladem využití této komunikace může být protokol ARP (Address Resolution Protocol) [17]. Komunikace typu multicast, kde jsou data zasílána definované skupině příjemců. Pojem skupina bývá z tohoto důvodu v síťové terminologii často asociována převážně s komunikací typu multicast. Skupina může být tvořena různými prvky, jako například stanice, uživatelé a aplikace. Komunikace typu anycast, kde jdou data zasílána pokud možno jednomu příjemci z předem definované skupiny například tomu, který je nejblíže zdroji. Z pohledu počtu zdrojů můžeme dále komunikaci dělit na jeden zdroj k jednomu příjemci, mnoho zdrojů k jednomu příjemci a mnoho zdrojů k mnoho příjemcům. Pro multimediální přenosy jsou převážně používány multicast a unicast. 2.1 KOMUNIKACE TYPU UNICAST A MULTICAST IP sítě byly původně zaměřeny na způsob komunikace typu unicast. Princip této komunikace je zobrazen na Obr. 1. Unicast vychází z původní myšlenky IP protokolu, kdy spolu komunikují dvě stanice tj. data jsou zaslána jedním zdrojem jednomu příjemci. V současné době však unicast není vhodný pro všechny typy komunikace. Především pro ty, kde je více zdrojů a více příjemců. Příkladem může být audio/video konference, sdílení elektronické tabule a vysílání rozhlasu nebo televize po Internetu. V posledním případě je vyžadována komunikace od jedné stanice k více stanicím (data jsou zaslána jedním zdrojem více příjemcům). Pokud je použita komunikace typu unicast, musí zdroj vyslat data tolikrát, kolik je příjemců. Tato situace může vést ke zbytečnému plýtvání přenosových prostředků sítě (např. šířka pásma) i prostředků zdroje samotného, který musí několikrát vyslat stejná data. Především pro velké počty příjemců se tato situace stává těžce realizovatelnou. Typickým příkladem je IPTV, kde se předpokládají tyto velké počty příjemců. Přitom IPTV je jednou ze služeb, která v současné době zaznamenává velký nárůst. Řešení výše uvedeného problému je multicast. Multicast poskytuje lepší možnost komunikace z pohledu úspory síťových prostředků pro tyto dva případy: více zdrojů a více příjemců, jeden zdroj a více příjemců. 7

9 Obr. 1: Princip komunikace typu unicast Multicast umožňuje vysílat zdroji data pouze jednou s tím, že kopie vyslaných dat jsou doručeny všem přijímačům (viz Obr. 2). Kopie dat se vytváří vždy ve směrovačích umístěných nejblíže k danému příjemci, aby se co nejvíce šetřily přenosové prostředky sítě. Jak již bylo naznačeno, komunikaci typu multicast lze charakterizovat jako zvláštní případ všesměrového vysílání broadcast, kdy kopie paketů jsou zasílány pouze definované skupině příjemců. Pokud má příjemce zájem přijímat data, musí před vlastním příjmem provést přihlášení do této skupiny. Komunikace typu multicast, tak jak ji v současné podobně známe, byla definována v publikaci [18]. Základní principy této komunikace lze shrnout následovně [15]: Pakety přenášené komunikací typu multicast mají stejný formát jako pakety přenášené komunikací typu unicast. Odlišují se pouze v adrese příjemce, kterou je adresa skupiny příjemců. Skupiny příjemců jsou vytvářeny dynamicky, tj. příjemci se mohou kdykoliv do skupiny přihlásit a odhlásit. Do skupiny příjemců může vysílat každý, tj. není nutné, aby zdroj dat byl členem této skupiny. Z pohledu signalizace pro multicast rozlišujeme dvě úrovně: Signalizace pro přihlášení a odhlášení do/ze skupiny. Pro tento účel lze využít protokol IGMP (Internet Group Management Protocol) [19]. Signalizace pro směrování komunikace například pomocí protokolu PIM-SM (Protocol Independent Multicast-Sparse Mode) [20]. Dále lze dělit multicast podle počtu zdrojů dat: s různými zdroji dat (ASM, Any Source Multicast) a se specifickým zdrojem dat (SSM, Source-Specific Multicast). Multicast ASM koresponduje s původním návrhem uvedeným v [18]. Multicast SSM je upravenou (dá se říci i zjednodušenou) verzí ASM. Pro popis SSM se užívá notace (S, G), kde S (Source) představuje 8

10 adresu zdroje dat a G (Group) představuje adresu skupiny příjemců. Pro popis ASM se používá notace (*,G), kde * reprezentuje libovolný zdroj dat. Obr. 2: Princip komunikace typu multicast 2.2 DRUHY PŘENOSU TYPU MULTICAST Multicast s různými zdroji dat Při přenosu ASM (viz Obr. 3) musí být síť schopna rozlišovat zdroj dat. Pokud nový příjemce projeví zájem o připojení do relace, síť musí určit všechny zdroje dat a jejich data dopravit k tomuto příjemci. Tento mechanizmus vytváří z ASM složitý a nesnadno realizovatelný systém, jelikož pro přenosy ASM je nutno vytvořit složitou strukturu směrování. Tento způsob přenosu je vhodný například pro on-line hry, hlasové a video konference, sdílení elektronických tabulí, tj. vždy kdy se některé nebo všechny stanice střídají jako zdroje dat. Nevýhodou ASM je, že přijímač nemá možnost určit, od kterých zdrojů vysílajících do skupiny příjemců chce přijímat data. Tato nevýhoda je umocněna tím, že do skupiny může vysílat kdokoliv Multicast se specifickým zdrojem dat Způsob přenosu typu multicast se specifickým zdrojem dat SSM (viz Obr. 4) je odvozen od ASM a lze jej použít pouze v případě, kdy je přesně definován zdroj dat (např. při příjmu již zmíněného internetového rádia či televize). Případný jiný zdroj vysílající na stejnou adresu typu multicast (tedy ke skupině přijímačů) není přijímán. Toto je zajištěno tak, že do procesu směrování jsou zapojeny dva typy adres: adresa typu multicast (G, adresa skupiny, ze které chce příjemce přijímat data), adresa typu unicast (S, adresa konkrétního zdroje). SSM má výhodu ve své jednoduchosti a v menší realizační náročnosti. Přitom pro každou dvojici (S, G) se udržuje samostatný distribuční strom a přitom tyto distribuční stromy nejsou na sobě nijak 9

11 závislé. Výhodou oproti ASM tedy je, že do jedné skupiny příjemců mohou současně vysílat různé zdroje, ale příjemci si definováním adresy zdroje S vybírají zdroj, od kterého mají zájem data přijímat. Vlastní registrace skupiny je prováděna pomocí protokolu IGMPv3, který právě umožňuje filtrovat data podle zdrojové adresy S. Obr. 3: Multicast s různými zdroji dat 3 PŘENOS SIGNALIZACE PRO MULTICAST SE SPECIFICKÝM ZDROJEM DAT 3.1 VYMEZENÍ AKTUÁLNÍHO PROBLÉMU S PŘENOSEM SIGNALIZACE V současnosti je problémem komunikace typu multicast velký interval zasílání zpráv protokolu RTCP od jednotlivých členů relace. Tyto zprávy poskytují informace například o kvalitě přenosu na straně příjemců a mohou být také dále využívány dalšími navazujícími systémy jako jejich vstupní data. Velké intervaly zasílání zpráv protokolu RTCP vedou ke zpoždění přenosu signalizace v celém systému, a tudíž její zpracování může vést k nesprávné funkci navazujících systémů, jelikož jejich vstupní data jsou časově zastaralá (až několik desítek či stovek sekund). Proto především zprávy SR (Sender Report) 4 a RR (Receiver Report) 5 protokolu RTCP by měly být zasílány v co nejkratších intervalech. Na druhou stranu, příliš krátké intervaly můžou způsobit generování velkého provozu v síti a tím zahltit přidělené přenosové pásmo. Tím může být negativně ovlivněno zasílání zpráv protokolu RTP, které nesou vlastní multimédia (např. se zvětší ztrátovost paketů nebo jejich kolísání zpoždění jitter). Z toho důvodu je používáno pevné rozdělení pásma pro zprávy RTP nesoucí vlastní multimédia a zprávy RTCP nesoucí signalizaci. Konkrétně je 5 % vyhrazeného pásma použito pro zprávy protokolu RTCP a dále 3,75 % vyhrazeného pásma je použito pro zprávy RR a 1,25 % je použito pro zprávy SR. Výše uvedené pravidlo lze zapsat pro multicast SSM dat následovně [9]: interval zasílání (RI, Reporting Interval) zpráv RR od příjemců r RR je určen jako r RR = p n RR r (1) 0,75 B RTCP a pro zprávy SR je interval zasílání od zdroje (při SSM je jen jeden zdroj) r SR určen jako 4 Zprávy nesoucí informace o zdroji dat; jsou přenášeny ve směru od zdroje k příjemci. 5 Zprávy nesoucí informace o příjemci dat; jsou přenášeny ve směru od příjemce ke zdroji. 10

12 p SR r SR =, (2) 0,25 B RTCP kde p RR je velikost zprávy RR, p SR je velikost zprávy SR, n r je počet příjemců a B RTCP je povolená šířka pásma pro přenos zpráv protokolu RTCP. Jak je patrno ze vzorce (2), interval zasílání zpráv SR se podle počtu příjemců nemění. Obr. 4: Multicast se specifickým zdrojem dat Příklad výpočtu intervalů zpráv RR pro celkovou povolenou šířku pásma, kterou označme jako B S, rovnou hodnotám 3, 5 a 7 Mb/s (B RTCP je roven 5 % z této hodnoty) 6 a velikosti zprávy RR rovnou 480 b je zobrazen na Obr. 5. Aby nedocházelo k zahlcení přenosové kapacity pro malé počty příjemců je ve specifikaci protokolů RTP/RTCP definován 5-ti sekundový limit, který je také zobrazen v grafu. Pokud je vypočtená hodnota intervalů zasílání zpráv RR menší než tento limit, je tato zpráva zasílána každých 5 sekund. Důvodem zavedení tohoto limitu bylo zabránit zahlcení sítě zprávami, pokud dojde k výpadkům sítě nebo nekorektnímu chování příjemců. Příkladem může být výpadek části sítě, kdy část členů přenosu nebude po určitou dobu zasílat své zprávy RR. Ostatní členové tedy budou mít nekorektní informace o celkovém počtu členů ve skupině a budou v závislosti na vzorci (1) snižovat interval zasílání signalizace (i na velmi malé hodnoty v závislosti na počtu odpojených členů ). Při pohledu na graf na Obr. 5 je patrno, že s většími počty příjemců se interval zasílání zvětšuje a dosahuje hodnot až řádově desítek minut. Tento problém byl mimo jiné identifikován jako jeden ze tří hlavních problémů protokolů RTP/RTCP [21]. V následující kapitole je popsán známý způsob, kterým lze tento interval zasílání zpráv RR redukovat. 3.2 HIERARCHICKÁ AGREGACE Hierarchická agregace je založena na myšlence, že v síti existují servery pro přenos signalizace (dále signalizační servery), které se označují jako FT (Feedback Target). Na obrázku Obr. 6 je to zvolená stanice ve skupině B. Příjemci přenosu typu multicast jsou rozděleni do skupin, které nazývejme signalizační skupiny. Tyto signalizační skupiny jsou tvořeny i signalizačními servery. Členové těchto skupin posílají signalizaci zvolenému signalizačnímu serveru. Tento signalizační 6 Jedná se o přibližné šířky pásma pro vysílání IPTV. 11

13 server určitým způsobem zpracuje signalizaci a výsledek pak pošle dalšímu nadřazenému signalizačnímu serveru ve zprávě protokolu RTCP označované jako RSI (Receiver Summary Information) [10]. Všechny signalizační servery jsou seřazeny do stromové struktury tak, aby se signalizace postupně dostala až na vrchol stromu, tak jak je zobrazeno na Obr. 7. Signalizační server na vrcholu této stromové struktury je označován jako hlavní signalizační server MFT (Main Feedback Target). Pro tento signalizační server mohou nastat dva případy: pokud je signalizační server totožný se zdrojem dat, dojde k přeposlání zprávy RSI, která nese agregovanou signalizaci od všech příjemců zpět všem příjemcům pomocí komunikace typu multicast, nebo pokud není signalizační server totožný se zdrojem dat, může hlavní signalizační server zprávu RSI poslat zdroji dat za účelem přeposlání ke všem příjemcům. Další možností pro tento případ je, že může hlavní signalizační server poslat tuto zprávu všem příjemcům sám (zde je však nutno u příjemců umožnit příjem dat od hlavního signalizačního serveru). Interval zásílání zpráv RR [s] , ,00 100,00 10,00 1,00 0,10 Interval zasílání zpráv RR (povolená šířka pásma = 7 Mb/s) Interval zasílání zpráv RR (povolená šířka pásma = 5 Mb/s) Interval zasílání zpráv RR (povolená šířka pásma = 3 Mb/s) Interval 5 s 0, Počet příjemců Obr. 5: Interval zasílání zpráv RR protokolu RTCP pro šířky pásma 3, 5 a 7 Mb/s 4 NÁVRH PŘENOSU SIGNALIZACE POMOCÍ HIERARCHICKÉ AGREGACE V IPTV Přehled návrhu přenosu signalizace v IPTV pomocí hierarchické agregace lze charakterizovat následovně: Návrh koncepce systému IPTV umožňujícího přenos signalizace pomocí hierarchické agregace zahrnuje definování jednotlivých částí systému, jejich funkce a principu činnosti. Záměrem je oddělení zdroje dat a hlavního cíle pro přenos signalizace na dva samostatné prvky. Byl zde definován nový prvek nazvaný FTM (Feedback Target Manager). Přitom se předpokládá, že tento prvek má k dispozici množinu signalizačních serverů a je zodpovědný za jejich organizaci ve stromové struktuře, která je vytvářena pro realizaci hierarchické agregace. Signalizační servery mohou být sdíleny mezi více stromy pro přenos signalizace, které jsou svázané s různými vysíláními IPTV. Dalším navrženým prvkem systému je i systém vizualizace stromové struktury a monitorování hodnot hierarchické agregace signalizace. Dílčí výsledky tohoto návrhu byly publikovány autorem v [22], [23], [24], [25], [26] a [27]. 12

14 Obr. 6: Hierarchický algoritmus pro přenos signalizace při komunikaci typu multicast se specifickým zdrojem dat Návrh koncepce sestavení stromu pro realizaci hierarchické agregace v rámci IPTV, který zahrnuje organizaci příjemců a signalizačních serverů do signalizačních skupin. Základní myšlenkou je, že každý prvek se přiřazuje do signalizační skupiny na základě vlastního rozhodnutí. Tím je dosaženo žádané škálovatelnosti systému, jelikož množství informací pro organizaci stromu není závislé na počtu přijímačů. Rozhodování prvků, ke kterému signalizačnímu serveru budou zasílat signalizaci, je prováděno pomocí vyhodnocování definované metriky, která je tvořena třemi faktory vzdáleností k signalizačnímu serveru, vytížení signalizačního serveru a priorita signalizačního serveru. Přitom každý parametr má přidělenu svoji váhu. Při návrhu této metriky byla věnována velká pozornost prvnímu faktoru, tedy vzdálenosti, což je v současné době intenzivně řešená problematika. Vzdálenost mezi stanicemi v Internetu je totiž často určována pomocí hodnoty zpoždění při přenosu paketů mezi těmito stanicemi. Problémem je, jak tuto hodnotu zjistit, aniž by všechny stanice musely provést měření zpoždění paketů při jejich přenosu. Současné řešení nabízí využití umělých souřadnicových systémů pro odhad tohoto zpoždění (např. 2D euklidovský prostor s výškou). Jako vhodná metoda predikce zpoždění přenosu paketů mezi dvěma stanicemi v Internetu pro systém IPTV byla zvolena metoda Vivaldi [28]. Tato metoda pracuje na principu nalezení takových souřadnic ve zvoleném umělém souřadnicovém systému, pro které je predikovaná hodnota zpoždění mezi stanicemi nejpřesnější. Pro nalezení takových souřadnic je využito podobnosti s nalezením minima potencionální energie sítě pružin. Dále byl navržen způsob zajištění omezení velikosti zprávy RSI pomocí násobícího faktoru MF (Multiplicative Factor). Původní výsledky řešení této problematiky byly publikovány autorem v literatuře [29], [30], [31], [32] a [33]. Při návrhu koncepce nového komunikačního protokolu TTP (Tree Transmission Protocol), jehož úkolem je přenos informací svázaných s organizací prvků do stromové struktury pro přenos signalizace pomocí hierarchické agregace, byl kladen velký důraz na jednoduchost a univerzálnost. Především požadavek na univerzálnost nebyl triviálním řešením. Základním předpokladem bylo odloučení protokolu od návaznosti na protokol RTP/RTCP. Dále bylo snahou odloučit protokol od protokolů používaných pro popis a distribuci informací o multimediálních vysíláních, např. protokol SDP (Session Description Protocol). Striktním definováním rozhraní mezi dalšími protokoly lze využít protokol TTP i v jiných aplikacích, jako například pro realizaci hierarchické agregace dat v senzorových sítích [34], [35], [36], 13

15 [37] a [38]. Dílčí výsledky této problematiky byly publikovány autorem v [39], [40], [39], [41], [42] a [43]. Obr. 7: Struktura stromu a popis jeho prvků pro přenos signalizace pomocí hierarchické agregace 4.1 SYSTÉM IPTV S PŘENOSEM SIGNALIZACE POMOCÍ HIERARCHICKÉ AGREGACE V této kapitole je popsána koncepce systému pro přenos IPTV s využitím hierarchické agregace signalizace přenášené od příjemců k hlavnímu signalizačnímu serveru pomocí mezilehlých signalizačních serverů. Při přenosu signalizace můžeme uvažovat dva základní scénáře: vrchol stromu tj. hlavní signalizační server je totožný se zdrojem vysílání IPTV nebo tyto dva prvky jsou oddělené. Vzhledem k předpokladu, že hlavní signalizační server bude vytížen zpracováním informací od velkého počtu příjemců IPTV (desítky či sta tisíců), předpokládejme tyto dva prvky jako oddělené entity. Tuto situaci zobrazuje Obr. 8. Server IPTV vysílá pomocí komunikace typu multicast data televizní stanice přímo příjemcům. Ti jsou rozdělení do signalizačních skupin a posílají signalizaci svému signalizačnímu serveru. Signalizační server posílá agregovanou signalizaci buď dalšímu nadřazenému signalizačnímu serveru nebo přímo hlavnímu signalizačnímu serveru (v závislosti na úrovni stromu). Pro zachování požadavku univerzálnosti navrženého systému předpokládejme, že některá data bude nutno po zpracování poslat všem příjemcům. Úkolem hlavního signalizačního serveru je tedy tyto data přímo vysílat nebo zajistit předání dat serveru IPTV k dalšímu případnému přenosu. Dále definujme novou entitu systému IPTV jejímž cílem je poskytnutí prvkům přenášejících signalizaci informace pro vyhodnocení metriky a nalezení signalizačního serveru, na který budou signalizaci zasílat. Tento prvek nazvěme správce přenosu signalizace. Předpokládejme, že správce přenosu signalizace má k dispozici množinu dedikovaných serverů, které vystupují jako signalizační servery. Ideou je, že tyto servery jsou ve správě poskytovatele IPTV. Vytvoření seznamu dostupných signalizačních serverů a jeho předání správci přenosu signalizace se předpokládá v rámci proprietárního řešení poskytovatele IPTV. Vzhledem k pravděpodobnému omezenému počtu signalizačních serverů se dále předpokládá, že tyto signalizační servery budou sdíleny mezi více stromy pro přenos signalizace svázané s různými vysíláními IPTV 7. Tato myšlenka vychází z úvahy, že jeden poskytovatel IPTV většinou nabízí příjem více televizních stanic, aby poskytovanou službou pokryl co největší okruh zákazníků. Příklad sdílení signalizačních serverů je zobrazen na Obr. 9. Každý strom je na svém vrcholu tvořen 7 Jinak řešeno, jeden signalizační server může vystupovat v různých stromech pro přenos signalizace. 14

16 hlavním signalizačním serverem, u kterého se sdílení nepředpokládá, ale je možné. Vzhledem k předpokládané komunikaci hlavního signalizačního serveru s databází pro archivaci signalizace (popřípadě s dalšími aplikacemi pro zpracování signalizace) je předpokládáno vyšší vytížení tohoto serveru než u signalizačních serverů. Dále v otázce vytížení jednotlivých signalizačních serverů hraje roli úroveň stromu. Se zvyšující se úrovní stromu vytíženost signalizačního serveru roste, jelikož zpracovává signalizaci od většího počtu přijímačů. Na této skutečnosti je také závislý fakt kolika stromy může být signalizační server sdílen, aniž by docházelo k jeho neúměrnému zatěžování. Obr. 8: Přehled systému IPTV s přenosem signalizace pomocí hierarchické agregace Důležitým faktem pro správnou činnost přenosu signalizace pomocí hierarchické agregace je využití protokolu UDP (User Datagram Protocol) i TCP (Transmission Control Protocol). Na nejnižší vrstvě stromu, kde jsou umístěni pouze příjemci, je pro přenos zpráv RR využit nespolehlivý protokol UDP. Je zde preferována jednoduchost a rychlost. Případná ztráta zprávy nesoucího signalizaci od jednoho příjemce nebude mít velké následky na celkové vyhodnocení signalizace. Ve vyšších vrstvách stromu, kde jsou umístěny signalizační servery zasílající signalizaci pomocí zpráv RSI, je využito spolehlivého přenosu protokolu TCP. Zde jednotlivé zprávy nesou signalizaci od celé signalizační skupiny a ztráta této zprávy (především ve vyšších vrstvách stromu) by měla velký dopad na výslednou hodnotu monitorovaných dat. 4.2 ORGANIZACE PRVKŮ SYSTÉMU IPTV DO SIGNALIZAČNÍCH SKUPIN PODLE RELATIVNÍ POLOHY Vhodný způsob organizace příjemců i signalizačních serverů hraje důležitou roli pro výkonnost celého systému. Přitom je zde nutno uvažovat aspekty reálné IP sítě. Při sestavování stromu je vhodné organizovat příjemce a signalizační servery do signalizačních skupin tak, aby byla co nejmenší vzdálenost mezi členy signalizační skupiny a signalizačním serverem, kam členové této skupiny zasílají signalizaci. Organizace signalizačních skupin pomocí co nejmenší vzdálenosti se následně projeví v úspoře přenosových prostředků sítě. Na druhou stranu neorganizované rozdělení prvků do signalizačních skupin může vést ke zbytečným přenosům. Příkladem může být situace, kdy mezi příjemcem a možným signalizačním serverem je pouze jeden směrovač, přesto však příjemce byl náhodně přiřazen do signalizační skupiny a posílá tak signalizaci signalizačnímu serveru přes 15

17 větší počet směrovačů. Dochází tak k plýtvání prostředků směrovačů, zabírání pásma při zbytečných přenosech mezi směrovači a celkové zpoždění přenosu paketů od příjemců k signalizačním serverům narůstá. Tato situace vede k rozdílné komunikaci pro přenos signalizace na aplikační vrstvě RM TCP/IP a pro přenos vlastních dat na úrovni IP protokolu na síťové vrstvě RM TCP/IP. Více informací o problémech rozdílného přenosu na aplikační a na síťové vrstvě lze nalézt v literatuře [44] a [45]. Obr. 9: Prvky zajišťující přenos signalizace pomocí hierarchické agregace v rámci poskytovatele IPTV Intuitivním řešením této situace by byla spolupráce se směrovacími protokoly síťové vrstvy. Toto by však znamenalo komunikaci s každým směrovačem zapojeným v cestě a vzhledem k různým používaným směrovacím protokolům by toto řešení přineslo velkou složitost z důvodu nutné úzké spolupráce se všemi používanými směrovacími protokoly. Tato režie by znamenala další komunikaci zabírající přenosové prostředky sítě. Z tohoto důvodu se pro řešení výše uvedeného problému používají tzv. poziční metody. Pozičních metod existuje celá řada viz například [46], [28], [47], [48], [49] a [50]. Tyto metody jsou centralizované i decentralizované a mohou pracovat na zcela odlišných principech (např. využívají pro zjištění pozice tzv. referenční stanice nebo souřadnicové systémy nebo kombinaci obou). Příklady aplikací profitujících ze znalosti vzdálenosti mezi stanicemi v Internetu jsou BitTorrent [51] a CoDeeN [52]. Zjišťování pozice stanic v Internetu je založeno na měření zpoždění při přenosu paketů. Hodnota zpoždění je obecně závislá na několika faktorech jako například fyzická vzdálenost zdroje a cíle, rychlost přenosu linek v cestě a jejich aktuální zatížení, počet směrovačů mezi zdrojem a cílem a jejich výkonnost a aktuální zatížení. Přitom při měření je vhodné rozlišovat zpoždění jednosměrné a obousměrné. Důvodem je fakt, že při komunikaci v IP sítích nemusí být cesta shodná v obou směrech. Při obousměrné komunikaci může každý ze směrů komunikace procházet přes různé směrovače (v závislosti na použitém směrovacím protokolu) a také pro různé směry komunikace můžou být vyhrazené rozdílné přenosové prostředky (např. pokud směrovače implementují kvalitu služeb (QoS, Quality of Service)). Samotné měření bývá také často ovlivněno aktuálním stavem sítě. Jednou z metod, jak zjistit obousměrné zpoždění při komunikaci v IP sítích, je měření hodnoty RTT (Round-Trip Time) 8 pomocí protokolu ICMP (Internet Control Message Protocol) [54]. Jedná se o protokol síťové vrstvy RM OSI. Protokol ICMP obecně slouží k přenosu signalizace v IP sítích. Přitom tento protokol není typicky využíván přímo síťovými aplikacemi. Příkladem využití protokolu ICMP je ohlašování událostí mezi směrovači a stanicemi. Zpráva protokolu ICMP může 8 Je známo, že čím větší je hodnota RTT, tím dochází ke snižování přenosové rychlosti, viz [53]. 16

18 být zaslána buď cílovou stanicí nebo směrovačem, přes který paket prochází. Pro vyhodnocování hodnoty RTT se používají zprávy protokolu ICMP Timestamp Request a Timestamp Reply. Jak již bylo řečeno, vyhodnocování vzdálenosti mezi stanicemi je přenášeno do uměle vytvořených prostorů. Metody využívající tyto umělé souřadnicové prostory jsou založeny na tom, že pokud stanice i zná souřadnice stanice j, stanice i nemusí provést měření hodnoty RTT ke stanici j, namísto toho hodnota RTT může být odhadnuta pomocí vzdálenosti mezi stanicemi i a j v daném souřadnicovém systému. Pokud by Internet pracoval ideálně (tj. zpoždění při přenosu dat bylo ovlivněno pouze rychlostí šíření signálu po vedeních, všechny stanice by byly navzájem propojeny přímými cestami, použitý směrovací systém byl schopen nalézt všechny tyto přímé spoje, atd.), tak by teoreticky měl vyhovovat klasický souřadnicový systém vyjádřený pomocí zeměpisné šířky a délky. Bohužel tyto ideální podmínky nejsou v Internetu nastoleny (pakety jsou přenášené pomocí několika přímých spojů, jsou zpožďovány při průchodu směrovači, atd.). Dalším významným problémem je, že zpoždění při přenosu paketů jako měřítko vzdálenosti v síti Internet často porušuje trojúhelníkovou nerovnost. Z těchto důvodů nelze použít jednoduchý dvoudimenzionální prostor pro predikci hodnoty RTT mezi stanicemi v Internetu. Pro řešení tohoto problému byly navrženy uměle vytvořené souřadnicové systémy, které se pokouší vyhovět reálným vlastnostem Internetu. Přitom tyto umělé souřadnice nejsou limitovány počtem dimenzí. Zkoumány jsou souřadnicové systémy se standardní euklidovskou funkcí vzdálenosti, ale byly také navrženy další souřadnicové systémy sférické, toroidní, hyperbolické. Metoda Vivaldi [28] 9 je jednou z metod využívající umělé souřadnicové systémy. Tato metoda je zcela decentralizovaná. Z tohoto důvodu je vhodná i pro použití v navrhovaném systému IPTV s přenosem signalizace pomocí hierarchické agregace. 4.3 SESTAVENÍ STROMU PRO PŘENOS SIGNALIZACE POMOCÍ HIERARCHICKÉ SIGNALIZACE Princip sestavení stromu Intuitivně nabízejícím se řešením je, že strom sestaví správce přenosu signalizace a pak předá informace o podobě stromu všem prvkům systému IPTV. Toto předání informací by šlo realizovat pomocí komunikace typu unicast, kdy by správce přenosu signalizace zaslal každému prvku IP adresu a port signalizačního serveru, kterému má tento prvek zasílat signalizaci. Toto řešení je však nevýhodné z hlediska škálovatelnosti, jelikož s rostoucím počtem příjemců roste množství přenášených informací a s každým prvkem se komunikuje zvlášť. Přitom při přenosu informací o změnách podoby stromu je potřeba znovu komunikovat se všemi prvky, kterých se tato změn týká. Další možností, která by částečně eliminovala výše popsaný problém je, že správce přenosu signalizace vytvoří páry, které budou tvořit IP adresa prvku a IP adresa/port signalizačního serveru, ke kterému má prvek zasílat signalizaci. Tyto páry by se pak zaslaly všem prvkům najednou pomocí komunikace typu multicast. Použití těchto párů je však opět nevýhodné z hlediska škálovatelnosti, protože množství přenášených informací roste s počtem příjemců. Z výše uvedených důvodů bylo navrženo nové řešení pomocí metriky. Toto řešení je založeno na následujícím principu: jednotlivé prvky (příjemci i signalizační servery) v pravidelných intervalech vyhodnocují hodnotu metriky pro definovanou množinu signalizační serverů (jedná se o signalizační servery o jednu úroveň výše v hierarchii stromu). Signalizační server, pro který byla vyhodnocena nejmenší hodnota metriky, je zvolen jako cíl pro zasílání signalizace. Metrika je tvořena několika parametry, které mají přiděleny své váhy. Hodnoty těchto vah a vstupní informace pro výpočet 9 Dřívější verze této metody je popsána v [55]. 17

19 jednotlivých parametrů jsou všem prvkům IPTV systému zasílány správcem přenosu signalizace pomocí komunikace typu multicast. Správce přenosu signalizace tak pomocí těchto vstupních parametrů pro výpočet metriky určuje podobu stromové struktury. Důležitou vlastností tohoto řešení je, že každý prvek vyhodnocuje svou metriku nezávisle na ostatních a volí tak samostatně signalizační server pro zasílání signalizace. Jelikož jsou od správce přenosu signalizace přenášeny pouze informace pro výpočet metriky, tak množství přenášených informací není závislé na počtu příjemců, což vyhovuje podmínce škálovatelnosti systému Definice parametrů metriky pro nalezení signalizačního serveru Navržená metrika je tvořena těmito třemi parametry: Vzdálenost mezi prvkem (příjemcem/signalizačním serverem), u kterého se metrika vyhodnocuje, a signalizačním serverem pro zasílání signalizace. Množství signalizace zasílané na signalizační server (slouží k možnosti ovlivnit rovnoměrné rozložení zátěže mezi signalizačními servery). Priorita signalizačního serveru (slouží k možnosti preferovat popřípadě penalizovat vybrané signalizační servery). Vstupní informace pro výpočet této metriky jsou přenášeny od správce přenosu signalizace příjemcům a signalizačních serverům ve zprávě protokolu TTP pomocí komunikace typu multicast. Tyto informace zahrnují váhy jednotlivých parametrů, zvolenou metodu pro vyhodnocování pozice prvků a s ní svázané údaje (např. GNP, Vivaldi), aktuální zátěž signalizačních serverů a jejich prioritu. Pro správnou funkci navrženého systému je tedy nutné splnit předpoklad, že správce přenosu signalizace zná tyto informace týkající se jednotlivých signalizačních serverů. Z tohoto důvodu mu signalizační servery své údaje zasílají periodicky pomocí přenosu typu unicast (opět pomocí zprávy protokolu TTP). Informace pro tento přenos (IP adresa/port signalizačního serveru) jsou zveřejňovány pomocí protokolu pro popis vysílání příkladem může být protokol SDP (Session Description Protocol) [56]. 4.4 PROTOKOL TTP PRO ORGANIZACI STROMOVÉ STRUKTURY Přehled začlenění navrženého protokolu TTP do RM TCP/IP je zobrazen na Obr. 10. Snahou při návrhu bylo nevázat tento protokol na žádnou konkrétní technologii pro přenos multimédií v IP sítích, tedy především protokoly RTP/RTCP. Obr. 10: Návaznost protokolu TTP na další protokoly a jeho začlenění do referenčního modelu TCP/IP Na Obr. 11 jsou zobrazeny typy prvků komunikujících pomocí protokolu TTP a jejich vzájemné vazby. Jak již bylo uvedeno, pro správnou funkci přenosu signalizace pomocí hierarchické agregace 18

20 je vyžadováno, aby měl prvek správce přenosu signalizace k dispozici informace (pozice, vytížení a priorita) od signalizačních serverů. Signalizační servery mu tyto informace zasílají periodicky pomocí komunikace typu unicast. Správce přenosu signalizace tyto údaje zpracuje a v definované časové intervaly výsledek zasílá přenosem typu multicast všem prvkům systému IPTV pro výpočet metriky. Pomocí metriky následně příjemce popř. signalizační server volí svou signalizační skupinu. Dále správce přenosu signalizace pomocí komunikace typu unicast aktivuje resp. deaktivuje signalizační servery pro začlenění do hierarchické agregace signalizace. 5 ZÁVĚR Obr. 11: Přehled činnosti protokolu TTP Tato práce byla primárně zaměřena na studium hierarchické agregace a na návrh jejího možného rozšíření pro přenos signalizace v systémech IPTV s velkým počtem příjemců. Pro přenos vlastního vysílání IPTV je výhodné využít multicast se specifickým zdrojem dat, který poskytuje pouze jednosměrné spojení od zdroje k příjemcům. Tato skutečnost znemožňuje jednotlivým účastníkům používat protokol RTCP, pomocí kterého je přenášena signalizace. Příčina je v tom, že tento protokol pro implementaci některých funkcí vyžaduje přenos signalizace od příjemce ke zdroji a mezi příjemci navzájem. Současné snahy přinášejí řešení v použití komunikace typu unicast pro přenos signalizace (tedy pro protokol RTCP) od jednotlivých příjemců ke zdroji dat, který tuto signalizaci dále přeposílá všem příjemcům pomocí komunikace typu multicast. Hierarchická agregace je jednou z metod, která tuto techniku využívá. Za hlavní výstupy této práce lze považovat návrh způsobu přenosu signalizace pro velké počty příjemců IPTV za využití principu hierarchické agregace. Vlastní řešení práce spočívá nejprve v návrhu koncepce sestavení stromu pro realizaci hierarchické agregace signalizace. Konkrétně byl vypracován nový způsob vytváření stromové struktury, který zahrnuje především organizaci příjemců a signalizačních serverů do signalizačních skupin. Prvky náležící do jedné signalizační skupiny zasílají signalizaci signalizačnímu serveru, který je pro tuto skupinu definován. Pro omezení množství přenášených dat mezi správcem přenosu signalizace (navržený prvek zodpovědný za organizaci stromu) a ostatními prvky systému IPTV je použito sestavení stromu pomocí metriky, kterou si každý prvek vyhodnocuje sám. Důležitým faktorem při sestavování stromu se jeví vzdálenost mezi členy signalizační skupiny a signalizačním serverem pro zasílání signalizace (první parametr navržené metriky). Skutečností je, že mnoho aplikací pracujících s velkým počtem stanic v Internetu může profitovat ze známé pozice 19

21 těchto stanic. Pokud by byl strom organizován z tohoto pohledu náhodně (tj. bez znalosti pozice participujících stanic), docházelo by ke zbytečným přenosům na úrovni přenosových linek a tím k výraznému plýtvání přenosových prostředků. Řešením by byla úzká spolupráce se směrovacími protokoly. Tato varianta by však přinesla velkou složitost implementace z důvodu spolupráce se všemi používanými směrovacími protokoly. Proto bylo zvoleno řešení pomocí pozičních metod, které mají za cíl odhadnout pozici stanic bez nutnosti měření hodnoty RTT mezi všemi stanicemi. Studováno bylo několik metod, které lze v systému IPTV použít algoritmus košů [57], IDMaps [58] [49], GNP [46], [47] a Vivaldi [28]. Poslední jmenovaná se jeví jako nejvhodnější pro použití v navrženém přenosu signalizace pomocí hierarchické agregace. Po teoretické formulaci způsobu komunikace mezi prvky IPTV systému a definovaní způsobu organizace stromu pro přenos signalizace s přihlédnutím k reálným podmínkám v IP sítích, byl proveden návrh nového komunikačního protokolu, který byl nazván TTP. Při jeho koncipování byl kladen velký důraz na jednoduchost a univerzálnost. Základním předpokladem pro zachování univerzálnosti bylo zajištění nezávislosti na protokolu RTP/RTCP. Dále bylo snahou odloučit protokol od protokolů používaných pro popis a distribuci informací o multimediálních vysíláních. Výsledkem je, že protokol TTP lze využít i v jiných aplikacích, například pro realizaci hierarchické agregace v rozsáhlých senzorových sítích. Možné další využití hierarchické agregace v návaznosti na výstupy této práce lze rozdělit do několika kategorií: Spolehlivost přenosu typu multicast. Pro zvýšení spolehlivosti přenosu komunikace typu multicast lze použít metodu dopředné korekce FEC (Forward Error Correction) [59]. Samotná aplikace metody FEC spočívá v tom, že zdroj předpokládá určitou ztrátovost paketů a systematicky vysílá i pakety paritní pro případnou korekci dat. Problémem však je znalost míry ztrátovosti paketů (aby bylo možno zvolit vhodný poměr mezi počtem paritních paketů a mírou zabezpečení spolehlivosti), jelikož se přenosové podmínky v síti Internet často mění. Přitom velký důraz je kladen na skutečnost, že hodnota ztrátovosti musí být v případě změny přenosových podmínek v síti k dispozici co nejrychleji zdroji dat, který podle těchto informací může provádět modifikaci použitého korekčního algoritmu. Pro tento účel lze použít periodický sběr informací od všech příjemců pomocí hierarchické agregace. Heterogenita příjemců. Při velkých počtech příjemců je pravděpodobné, že bude velká variace druhů zařízení a jejich technického vybavení. Samotná zařízení se mohou lišit výkonností procesoru, velikostí a rychlostí paměti, rozlišením obrazovky, atd. Uvážení heterogenity je velmi důležité při nastavení parametrů komunikace typu multicast z důvodu, aby nedocházelo k nežádoucímu omezování slabších příjemců oproti technicky lépe vybaveným popřípadě obráceně. Tato otázka se může především uplatnit v případě mobilních zařízení. Řešením je tzv. vícevrstvé vysílání, kdy každá vrstva nese část informace. Přitom příjemci s kvalitním připojením popřípadě dostatečným technickým vybavením přijímají všechny vrstvy, ostatní příjemci volí počet vrstev podle svých možností. Čím méně vrstev přijímají, tím přijímají méně informací a kvalita při přijmu klesá. Pro implementaci tohoto způsobu se používá například protokol ALC (Asynchronous Layered Coding) [60]. Přenos signalizace od příjemců pomocí hierarchické agregace může poskytnout vstupní informace pro implementaci tohoto algoritmu (např. vhodné rozdělení vrstev). Dohoda o úrovni služeb SLA (Service Level Agreement). Tato dohoda mimo jiné definuje technické metriky používané k popisu úrovně služeb [2]. Pro případ IPTV může být hierarchická agregace využita jako nástroj pro monitorování hodnot těchto technických metrik 20

22 (v podobě statistik) a to ve velmi krátkém čase. Na rychlý sběr informací od koncových zařízeních může navazovat včasné řešení případných problémů. Interaktivní IPTV. Hierarchická agregace nabízí nástroj pro realizaci hned několika typů interaktivních služeb IPTV [61], u kterých je důležité mít odezvy od příjemců k dispozici ke zpracování během několika desítek sekund (v závislosti na jejich počtu). V principu se jedná o přenos informací, které nejsou přímo svázány se signalizací informující o parametrech příjmu či parametrech zařízení. Přenosem těchto informací je možno například přenášet statistiky o akcích uživatelů. Služby, které by mohly být implementovány pomocí rychlého přenosu údajů od uživatelů v podobě statistik jsou například on-line hlasování a on-line distanční vzdělávání. SEZNAM POUŽITÉ LITERATURY [1] KABELOVÁ, A., DOSTÁLEK, L. Velký průvodce protokoly TCP/IP a systémem DNS. Computer Press, ISBN: [2] CHESTERFIELD J., SCHOOLER E. An Extensible RTCP Control Framework for Large Multimedia Distributions. Proceedings of the Second IEEE International Symposium on Network Computing and Applications. IEEE Computer Society, [3] SIMEK, M., KOMOSNY, D., BURGET, R. Implementation and Monitoring of Multicast Operations. Telecomunications and Signal Processing TSP Brno University of Technology, [4] QUINN, B., ALMEROTH, K. IP Multicast Applications: Challenges and Solutions. Internet Engineering Task Force, Request for Comments: [5] HOLBROOK H., CAIN B. Source-Specific Multicast for IP. Internet Engineering Task Force, Request for Comments: [6] SIMEK, M., KOMOSNY, D., BURGET, R. Experiences of Any Source and Source Specific Multicast Implementation in Experimental Network. Mobile and Wireless Communication Networks. Springer Verlag, ISSN: [7] SIMEK, M., KOMOSNY, D., BURGET, R. Analysis and Monitoring of Source Specific Multicast Sessions. Proceedings of the International Conference on Computer Science and Information Technologies. Lviv Polytechnic National University, [8] SCHULZRINNE H., CASNER S., FREDERICK R., JACOBSON V. RTP: A Transport Protocol for Real-Time Applications. Internet Engineering Task Force, Request for Comments: [9] SCHULZRINNE H., CASNER S., FREDERICK R. RTP Profile for Audio and Video Conferences with Minimal Control. Internet Engineering Task Force, Request for Comments: [10] CHESTERFIELD J., SCHOOLER E., OTT J. RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback. Internet Engineering Task Force, Internet Draft, work in progress. [11] BURGET, R., KOMOSNY, D., SIMEK, M. Real-time control protocol and its improvements for Internet Protocol Television. International Transaction on Computer Science and Engineering. Global Engineering, Science, and Technology Society, ISSN: