Č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.
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í
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 O
2. 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
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í.
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.
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
Adaptivní řízení QoS pro internetovou telefonii
