Výsledky výzkumu a další informace nejen
z oblasti přístupových telekomunikačních sítí.
Access server ISSN 1214-9675
Server vznikl za podpory Grantové agentury ČR.
15. ročník
Dnešní datum: 23. 09. 2017  Hlavní stránka | Seznam rubrik | Ke stažení | Odkazy  

Doporučujeme
Knihu o FTTx

Matlab server - on-line výpočty a simulace

E-learning - on-line kurzy

Trainingpoint - školení z oblasti TELCO a ICT

Kontakt
KTT FEL ČVUT
Napište nám

Redakční rada - pokyny pro autory a recenzenty

Copyright

QoS

* Adaptivní řízení QoS pro internetovou telefonii

Vydáno dne 31. 05. 2012 (2929 přečtení)

Článek popisuje adaptivní řízení kvality služby v síti se spoji s proměnnou přenosovou rychlostí a je zaměřen především na hovorové služby se signalizací SIP. Naměřené výsledky ukazují, že použitím adaptivního řízení kvality služby v sítích, kde není možné dopředu odhadnout přenosovou rychlost linek, je možné dosáhnout zlepšení přenosových parametrů hovoru, a to dokonce prediktivním způsobem před zahájením vlastního hovoru účastníků.


Adaptive QoS Control for VoIP - Abstract

This article describes Adaptive QoS control in networks with centralized management. The Article is aimed specially on voice services based on SIP signalization. Adaptive QoS control in central managed network can help voice to pass through congested networks. The results are really remarkable especially on congested links with unpredictable throughput. By analyzing network traffic the application for QoS control can predict incoming RTP stream of voice data and in this case path for voice can be prepared and ready for voice transition just before speech communication begins.

Keywords: Adaptive control;QoS;VoIP


Úvod

Ukazuje se, že rozmach služeb VoIP (Voice over IP) je značně omezen v sítích, kde není zaručená kvalita přenosu hovorových toků. Typickým příkladem jsou bezdrátové sítě standardu 802.11abg, ve kterých se stále používá velké množství zařízení bez podpory nebo jen s minimální podporou metod řízení QoS (Quality of Service). Tyto sítě jsou velmi často náchylné k zahlcení a tudíž i k degradaci hovorové služby pod únosnou úroveň. Do sítě s centrálním řídícím prvkem lze snadno implementovat takové metody, které umožní začlenění prediktivního řízení kvality hovorových služeb na základě hloubkové analýzy zpráv protokolu SIP (Session Initialization Protocol) [3]. Potenciál adaptivního řízení kvality služby v síti je značný. Není potřeba měnit žádná zařízení uvnitř sítě. Řešení se obejde bez podpory QoS na zařízeních uvnitř sítě. Popisované řešení také dokáže výrazně zlepšit podmínky pro přenos hovorových signálů v síti v případě přetížení některého segmentu sítě, a to dokonce prediktivně na základě volby účastnického čísla ještě v době, než dojde k zahájení vlastního hovoru. Toto řešení také dokáže zabezpečit přenos hovorové služby segmentem sítě s neznámou nebo měnící se přenosovou rychlostí.

Sítě lokálních poskytovatelů Internetu

V těchto sítích je stále poměrně běžné nasazení zařízení standardu 802.11abg. Mnoho těchto zařízení ani v dnešní době nepodporuje metody řízení QoS, nebo je podpora metod řízení QoS značně omezená. Zásadní nedostatek těchto sítí je, že dopředu lze jen těžko odhadnout přenosovou rychlost jednotlivých spojů a hlavně v průběhu času dochází ke změnám jejich rychlosti. Přenosová rychlost spojů je často závislá na vnějších přenosových podmínkách např. rušení nebo klimatické podmínky. Podobnému problému čelí i administrátoři firemních sítí v případě, že firmy používají přístup do internetu s negarantovanou šířkou přenosového pásma. Nasazení standardních metod řízení QoS je za takových podmínek značně problematické. Standardní metody řízení QoS se totiž opírají o předem známou přenosovou rychlost spoje. U sítí standardu 802.11abg běžné metody řízení QoS obvykle selhávají až na výjimky, kdy zařízení mají implementovánu podporu řízení QoS na spojové vrstvě.

Standardní metody řízení QoS

Pomocí standardních metod lze ovlivnit, jakým způsobem dojde k řazení paketů do front QoS, jak budou jednotlivé pakety identifikovány a označeny pro další zpracování, jakým způsobem bude předcházeno zahlcení, a v neposlední řadě umožňují řídit šířku přenosového pásma. Pro doručování paketů v síti se používají tři základní modely. Jako základní se používá model Best Effort. Model neupřednostňuje žádnou třídu paketů a pakety se snaží doručit v pořadí jejich příchodu. Dalším modelem je model Integrated Services (IntServ). V případě nasazení modelu IntServ dochází k vyjednávání přenosových parametrů mezi přenosovou soustavou a aplikacemi na základě protokolu RSVP (Resource ReSerVation Protocol). Posledním používaným modelem je model Differentiated Services (DiffServ). Použití modelu DiffServ umožňuje přiřazení různých priorit pro jednotlivé třídy provozu. Model DiffServ se opírá o metody pro identifikaci a značkování paketů. V sítích lokálních poskytovatelů internetu připadá v úvahu především nasazení modelu DiffServ, který oproti modelu IntServ nevyžaduje plnou podporu na straně síťových zařízení a klientských aplikací.

Výhody centralizovaného adaptivního řízení kvality služby v síti

Centralizované adaptivní řízení kvality služby v síti se sice opírá o klasické metody, ale odstraňuje řadu jejich nedostatků. Jelikož standardní metody vycházejí ze známé přenosové rychlosti spoje, při její náhlé změně selhávají. Problém odstraňuje adaptivní řízení toku. Centralizované řízení toku odstraňuje nutnost mít implementované algoritmy řízení toku na všech zařízeních v síti. Začlenění řešení do stávajících sítí je jednoduché a týká se pouze jediného prvku v síti. Protože je popisované řešení zaměřené na hovorové služby v IP sítích, k ovlivnění ostatního provozu dochází pouze v případě aktivní hovorové služby. Rychlost rekonfigurace QoS je dostatečná na to, aby k úpravě kvality přenosové trasy došlo ve většině případů ještě před zahájením vlastního hovoru.

Přenos hlasu v IP sítích

Provozovatelé bezdrátových sítí velmi často narážejí na problémy při implementaci hovorových služeb v sítích standardu 802.11abg. Ukazuje se, že v důsledku zarušení nebo častého přetížení dochází k degradaci hovorových služeb pod únosnou úroveň. V tomto případě je evidentní, že metody, které dokážou uvolnit dostatečnou kapacitu pro přenos hovorových dat, mohou být velmi užitečné. Popisované řešení je zaměřeno na hovorové služby se signalizací SIP. SIP není samostatný protokol, který by zabezpečoval přenos hlasu, ale používá se v kombinaci s dalšími protokoly, jako jsou protokoly SDP (Session Descrition Protocol) [5], RTP (Realtime Transport Protokol) [2] a RTCP (RTP Control Protokol). Výhodou protokolu SIP je snadné ladění aplikace, protože zprávy tohoto protokolu jsou přenášeny v čistě textové formě a jejich obsah je snadno srozumitelný.

Adaptivní řízení QoS

Začleněním adaptivního řízení pravidel QoS do sítě je možné pružně reagovat na konkrétní požadavky přenosu hlasu. Aplikace pro adaptivní řízení monitoruje veškerý provoz v síťovém uzlu a na základě informací získaných z provozu je schopna upravit nastavení pravidel QoS na daném síťovém uzlu tak, aby došlo pokud možno k bezproblémovému přenosu hovorových paketů sítí. Na základě adaptivního řízení lze jednoduše upřednostnit hovorovou službu na úkor ostatního provozu při probíhajícím hovoru a stejně tak jednoduše lze rezervaci pásma po ukončení hovoru zrušit. Jedná se v jistém smyslu o náhradu modelu IntServ modelem DiffServ za předpokladu centrálního řízení provozu v síti. Pomocí analýzy zpráv SIP/SDP je aplikace schopna určit trasu, která bude použita pro přenos hovoru, tuto trasu otestovat a případně provést úpravu pravidel QoS pro daný segment sítě tak, aby došlo ke zlepšení přenosových podmínek pro hovorové služby. Aplikace následně ověřuje, zda došlo k požadovanému zlepšení přenosových podmínek na dané trase, eventuálně aplikuje přísnější pravidla QoS pro podporu hovorové služby. Pokud by se ani opakovaně nepodařilo zlepšit přenosové podmínky, provede aplikace nastavení původních pravidel QoS a informuje technickou podporu o přetrvávajícím problému na dané trase. Analýza zpráv SIP/SDP také slouží k tomu, aby se přesně identifikoval datový tok protokolu RTP, který slouží pro přenos vlastních hovorových dat. Takto nalezenému datovému proudu je na centrálním směrovači upravena hodnota pole DSCP (Differentiated Services Code Point) [4] tak, aby byla zvýšena jeho priorita při přenosu sítí. Pokud jsou po trase hovoru v rámci sítě poskytovatele internetu zařízení, která podporují QoS, dojde tímto způsobem k upřednostnění daného hovoru na těchto zařízeních. K alokaci potřebné šířky pásma vyhrazené pro hovor dochází pomocí částečného omezení šířky přenosového pásma ostatního provozu.

Adaptivní_QoS_01

Obr. 1 Nasazení centrálního řízení QoS

Příklad struktury sítě s centrálním řízením je uveden na obrázku č. 1. Centrální řídící prvek, kterým prochází veškerý síťový provoz, monitoruje výskyt hovorových dat v daném provozu. V tomto případě sleduje zprávy protokolu SIP. Pokud je zjištěn požadavek na hovor zachycením zprávy INVITE, je z této zprávy zjištěn zdroj a cíl hovoru. Pro tuto trasu je v rámci sítě poskytovatele internetu naplánováno otestování protokolem ICMP (Internet Control Message Protocol). Parametry nastavení protokolu ICMP jsou nastaveny tak, abychom napodobili přenos hovoru. Testuje se postupně spoj po spoji ve směru od telefonního přístroje k centrálnímu směrovači. Takto je možné identifikovat problematický spoj, nebo určit trasu jako bezproblémovou pro aktuální přenos hovorové služby. Zároveň aplikace vyhodnocuje provoz protokolu TCP a na základě jeho analýzy aplikuje patřičné úpravy v řízení pomocí QoS metod. U hovorových služeb platí, že pokud dojde k ukončení hovoru, jsou následně provedené změny v nastavení pravidel QoS anulovány.

Metodika testování

Adaptivní_QoS_02

Obr. 2 Trasa přenosu pro ověření návrhu

Testování probíhalo na konci spoje standardu 802.11bg, který byl pro tyto účely začleněn do sítě lokálního poskytovatele internetu. Tento spoj byl nastaven na standard 802.11b a NetBitrate byl nastaven na hodnotu 5.5Mbit. Tato volba nastavení byla provedena, aby bylo dosaženo snadněji stavu zahlcení a nedošlo k přetížení sítě poskytovatele internetu. Pro účely testování bylo vítáno i značné zarušení pásma 2.4GHz, které přiblížilo nasazení v reálných podmínkách typických pro městskou zástavbu. Takto vytvořený a nastavený spoj dosahoval reálné datové propustnosti v rozmezí 3-4 Mbit/s. Při testování byl použit volně dostupný program PING, který využívá protokol ICMP pro testování odezvy paketů v IP sítích. Testování probíhalo tak, že z centrálního směrovače byl spuštěn test spojení na telefonní přístroj. Parametry programu PING byly zvoleny tak, aby alespoň částečně došlo k simulaci probíhajícího hovoru. To znamená, že velikost paketů a četnost jejich odesílání byla nastavena tak, že generovaný provoz byl podobný jednomu hovorovému kanálu s modulací PCM o datovém toku 64 kbit/s. Adaptivní nastavování QoS bylo prováděno tak, aby nedošlo k ovlivnění vlastních testů pomocí programu PING. Záznamy získané z testování trasy mezi telefonním přístrojem a centrálním směrovačem sloužily k vyhodnocení úspěšnosti nasazení adaptivního řízení kvality služby. Testy probíhaly tak, že byl spuštěn program PING a odezvy paketů byly zaznamenávány do souborů. Po 40 vteřinách po spuštění programu PING došlo ke spuštění klienta Bittorent z počítače v místě instalace telefonního přístroje. Tímto způsobem došlo k zatížení bezdrátového spoje, a to až na hranici zahlcení. Následně bylo nutné počkat až do chvíle, kdy se zatížení projevilo na velikosti odezvy paketů testu programu PING. Po uplynutí 80 vteřin od spuštění testu bylo z VoIP telefonního přístroje v místě měření provedena volba účastnického čísla mobilního telefonu v síti O2. Testy byly ukončovány po uplynutí přibližně 200 vteřin od počátku měření, což byla dostatečná doba pro to, aby bylo možné zachytit průběh adaptivního řízení kvality služby v síti a vliv tohoto řízení na kvalitu přenosové trasy.

Naměřené výsledky

Adaptivní_QoS_03

Obr. 3 Zpoždění paketů

Při testování jsme se zaměřili na měření zpoždění a ztrátovosti paketů. Na obrázku č. 3 je zachycen průběh zpoždění paketů. Výpadky paketů v průběhu měření odpovídaly danému přetížení sítě, které je signalizováno značným nárůstem odezvy, viz obrázek č. 3. Po zachycení zprávy INVITE protokolu SIP, která byla vygenerována na samém počátku hovoru, dojde k postupnému otestování přenosové trasy. Na jeden aktivní bod trasy připadá jeden spuštěný test. Vzhledem ke skutečnosti, že rychlost nastavení nových pravidel QoS není odvoditelná z grafu a i reakce síťového provozu na nová nastavení má jisté zpoždění, byla použita odlišná metoda pro měření. S použitím stopek byla měřena doba mezi prvním zazvoněním mobilního telefonu a stavem, kdy došlo k viditelnému snížení odezvy paketů u běžícího testu PING na VoIP telefon. Naměřené časy zachycuje tabulka na obrázku č. 4. Průměrný naměřený čas odpovídá přibližně době potřebné pro tři zazvonění telefonu. Lze tedy předpokládat, že ve většině případů se změny provedené aplikací ke zlepšení kvality přenosové trasy projeví ještě dříve, než bude hovor zahájen. Z grafu je patrné, že došlo ke zlepšení přenosové trasy na úroveň, která téměř odpovídá přenosové trase bez zatížení.

Adaptivní_QoS_04

Obr. 4 Čas od prvního zazvonění telefonu do viditelného zlepšení přenosových parametrů.

Během testování bylo dále zjištěno, že mezi volbou účastnického čísla a zazvoněním telefonu je zpoždění v řádu vteřin. Měření ukázala, že mezi odesláním zprávy INVITE a prvním zazvoněním telefonu uplynulo v průměru přibližně 7 vteřin. Provedená měření zachycuje tabulka na obrázku č. 5. Toto chování se ukázalo jako velmi přínosné pro prediktivní nastavení kvality služby. Aplikace pro adaptivní řízení kvality služby v síti tím získala čas navíc, který je bezezbytku využit na testování přenosové cesty. Celkový čas pro otestování trasy a nastavení pravidel QoS činil v průměru přibližně 14,3 vteřin, z čehož 7 vteřin tvořil čas mezi volbou účastnického čísla a začátkem vyzvánění telefonu a 7,3 vteřiny tvořil čas mezi začátkem vyzvánění telefonu a úpravou kvality přenosové trasy.

Adaptivní_QoS_05

Obr. 5 Čas od odeslání zprávy INVITE do zazvonění telefonu

Možnosti optimalizace

Rychlost vyhodnocení kvality trasy je možné dále zlepšit, a to například zmenšením počtu paketů v testech ICMP. Aplikace během testování standardně odesílala 100 paketů v každém testu s rychlostí 50 pps. Také by bylo možné uvažovat o paralelním testování více bodů trasy zároveň.

Závěr

Měření prokázala výrazné zlepšení přenosových parametrů sítě v případě adaptivní úpravy nastavení pravidel QoS na základě včasné detekce probíhající hovorové služby. Provedená měření nemají pouze teoretický význam, ale ukázalo se, že rychlost úpravy nastavení pravidel QoS pro danou trasu je dostatečná i pro reálné nasazení aplikace v sítích lokálních poskytovatelů internetu všude tam, kde je uplatňováno centrální řízení. V sítích s centrálním řízením se potřebná modifikace sítě pro zavedení adaptivního řízení kvality služby v síti týká pouze jednoho prvku. V případě směrovačů založených na OS Linux není třeba ani jejich výměna. Je evidentní, že začlenění centrálního adaptivního řízení kvality služby v sítích má smysl.

Tento příspěvek vznikl v rámci řešení projektu Studentské grantové soutěže ČVUT v Praze č. SGS10/275/OHK3/3T/13.

Použité zkratky

DiffServ - Differentiated Services
IntServ - Integrated Services
RSVP - Resource ReSerVation Protocol
RTP - Real-time Transport Protocol
RTCP - Real-time Transport Control Protocol
SDP - Session Description protocol
SIP - Session Initiation Protocol
QoS - Quality of Service
VoIP - Voice over IP

Literatura

[1] J.Hlaváček, R. Bešťák (2010) Aktuální problémy řízení kvality služeb v IP telefonii [online] Dostupné z: http://access.fel.cvut.cz/view.php?nazevclanku=aktualni-problemy-rizeni-kvality-sluzeb-v-ip-telefonii&cisloclanku=2010010003
[2] H. Schulzrinne, et al.(2003) RTP: A Transport Protocol for Real-Time Applications [online] Dostupné z: http://www.ietf.org/rfc/rfc3550.txt
[3] J. Rosenberg, et al.(2002) SIP: Session Initiation Protocol verze 2 [online] Dostupné z: http://www.ietf.org/rfc/rfc3261.txt
[4] K. Nichols, et al.(1998) Defnition of the Diferentiated Services Field (DS Field) in the IPv4 and IPv6 Headers [online]. 1998. Dostupné z: http://www.ietf.org/rfc/rfc2474.txt
[5] M. Handley, V. Jacobson (1998) SDP: Session Description Protocol [online] Dostupné z: http://www.ietf.org/rfc/rfc2327.txt



Autor:        O. Vondrouš
Pracoviště: České vysoké učení technické v Praze, FEL

Informační e-mail Vytisknout článek
Projekty a aktuality
01.03.2012: PROJEKT
Výzkum a vývoj nového komunikačního systému s vícekanálovým přístupem a mezivrstvovou spoluprací pro průmyslové aplikace TA02011015

01.01.2012: PROJEKT
Vývoj adaptabilních datových a procesních systémů pro vysokorychlostní, bezpečnou a spolehlivou komunikaci v extrémních podmínkách VG20122014095

09.10.2010: PROJEKT
Výzkum a vývoj datového modulu 10 Gbit/s pro optické a mikrovlnné bezdrátové spoje, FR-TI2/621

09.01.2010: PROJEKT
Sítě s femtobuňkami rozšířené o řízení interference a koordinaci informací pro bezproblémovou konektivitu, FP7-ICT-2009-4 248891

09.11.2008: PROJEKT
Ochrana člověka a techniky před vysokofrekvenčním zářením, FI-IM5/202

20.06.2008: Schválení
Radou pro výzkum a vývoj jako recenzovaný časopis

01.04.2007: PROJEKT
Pokročilá optimalizace návrhu komunikačních systémů pomocí neuronových sítí, GA102/07/1503

01.07.2006: Doplnění sekce pro registrované

12.04.2005: Zavedeno recenzování článků

30.03.2005: Výzkumný záměr
Výzkum perspektivních informačních a komunikačních technologií MSM6840770014

29.11.2004: Přiděleno ISSN

04.11.2004: Spuštění nové podoby Access serveru

18.10.2004: PROJEKT
Optimalizace přenosu dat rychlostí 10 Gbit/s, GA102/04/0773

04.09.2004: PROJEKT
Specifikace kvalitativních kritérií a optimalizace prostředků pro vysokorychlostní přístupové sítě, NPV 1ET300750402

04.06.2004: PROJEKT
Omezující faktory při širokopásmovém přenosu signálu po metalických párech a vzájemná koexistence s dalšími systémy, GA102/03/0434

Web site powered by phpRS PHP Scripting Language MySQL Apache Web Server

NAVRCHOLU.cz

Tento web site byl vytvořen prostřednictvím phpRS - redakčního systému napsaného v PHP jazyce.
Na této stránce použité názvy programových produktů, firem apod. mohou být ochrannými známkami
nebo registrovanými ochrannými známkami příslušných vlastníků.